From xen-devel-bounces@lists.xen.org Mon Dec 01 01:32:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 01:32:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvFq3-0007nT-Op; Mon, 01 Dec 2014 01:31: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 1XvFq2-0007nO-FA
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 01:31:42 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	47/81-15461-DF4CB745; Mon, 01 Dec 2014 01:31:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417397499!5135662!1
X-Originating-IP: [66.165.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 27911 invoked from network); 1 Dec 2014 01:31:40 -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 Dec 2014 01:31:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,489,1413244800"; d="scan'208";a="198249703"
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 20:31: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 1XvFpx-0008PV-8g;
	Mon, 01 Dec 2014 01:31:37 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvFpx-0008Su-1t;
	Mon, 01 Dec 2014 01:31:37 +0000
Date: Mon, 1 Dec 2014 01:31:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31947-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] 31947: 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 31947 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31947/

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 31855

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 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                                          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=db12451decf7dfe0f083564183e135f2095228b9
+ . 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 db12451decf7dfe0f083564183e135f2095228b9
+ branch=qemu-mainline
+ revision=db12451decf7dfe0f083564183e135f2095228b9
+ . 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 db12451decf7dfe0f083564183e135f2095228b9:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   ca60281..db12451  db12451decf7dfe0f083564183e135f2095228b9 -> 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 Dec 01 01:32:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 01:32:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvFq3-0007nT-Op; Mon, 01 Dec 2014 01:31: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 1XvFq2-0007nO-FA
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 01:31:42 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	47/81-15461-DF4CB745; Mon, 01 Dec 2014 01:31:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417397499!5135662!1
X-Originating-IP: [66.165.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 27911 invoked from network); 1 Dec 2014 01:31:40 -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 Dec 2014 01:31:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,489,1413244800"; d="scan'208";a="198249703"
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 20:31: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 1XvFpx-0008PV-8g;
	Mon, 01 Dec 2014 01:31:37 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvFpx-0008Su-1t;
	Mon, 01 Dec 2014 01:31:37 +0000
Date: Mon, 1 Dec 2014 01:31:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31947-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] 31947: 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 31947 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31947/

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 31855

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 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                                          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=db12451decf7dfe0f083564183e135f2095228b9
+ . 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 db12451decf7dfe0f083564183e135f2095228b9
+ branch=qemu-mainline
+ revision=db12451decf7dfe0f083564183e135f2095228b9
+ . 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 db12451decf7dfe0f083564183e135f2095228b9:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   ca60281..db12451  db12451decf7dfe0f083564183e135f2095228b9 -> 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 Dec 01 02:32:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 02:32:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvGmf-0007GM-BJ; Mon, 01 Dec 2014 02:32: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 1XvGmc-0006mX-TF
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 02:32:15 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	5D/88-31453-E23DB745; Mon, 01 Dec 2014 02:32:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417401131!11242152!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9951 invoked from network); 1 Dec 2014 02:32: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;
	1 Dec 2014 02:32:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,489,1413244800"; d="scan'208";a="198257057"
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 21:32: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 1XvGmX-0000G0-NA;
	Mon, 01 Dec 2014 02:32:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvGmX-0003Hk-EL;
	Mon, 01 Dec 2014 02:32:09 +0000
Date: Mon, 1 Dec 2014 02:32:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31941-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] 31941: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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 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                                 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 Mon Dec 01 02:32:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 02:32:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvGmf-0007GM-BJ; Mon, 01 Dec 2014 02:32: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 1XvGmc-0006mX-TF
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 02:32:15 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	5D/88-31453-E23DB745; Mon, 01 Dec 2014 02:32:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417401131!11242152!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9951 invoked from network); 1 Dec 2014 02:32: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;
	1 Dec 2014 02:32:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,489,1413244800"; d="scan'208";a="198257057"
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 21:32: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 1XvGmX-0000G0-NA;
	Mon, 01 Dec 2014 02:32:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvGmX-0003Hk-EL;
	Mon, 01 Dec 2014 02:32:09 +0000
Date: Mon, 1 Dec 2014 02:32:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31941-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] 31941: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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 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                                 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 Mon Dec 01 03:35:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 03:35:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvHl0-00083U-P3; Mon, 01 Dec 2014 03:34:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dennis.yxun@gmail.com>) id 1XvHkz-00083P-5B
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 03:34:37 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	0B/FC-03145-CC1EB745; Mon, 01 Dec 2014 03:34:36 +0000
X-Env-Sender: dennis.yxun@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417404872!12052149!1
X-Originating-IP: [209.85.214.182]
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 30538 invoked from network); 1 Dec 2014 03:34:33 -0000
Received: from mail-ob0-f182.google.com (HELO mail-ob0-f182.google.com)
	(209.85.214.182)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 03:34:33 -0000
Received: by mail-ob0-f182.google.com with SMTP id wo20so95176obc.41
	for <xen-devel@lists.xen.org>; Sun, 30 Nov 2014 19:34:32 -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=7u1Wp1d41JTenPimkLtgYve0OBOw3Nz/6vVDWUp0w1I=;
	b=UDJpGH8ggsPr+UGL/ymKBM2jdDk8jtHygFkfGrgsx69e2rdqvuC2xF9SVjZG1ksh1T
	clf9KQPnQOkzE7y/6ZOT3DLfFfN1mGvhU4T/ifnASLTN4Iamt5d8nBiaNeqccY+CHyi+
	gu7rbjYV38ltoK1wFYVHzDFVBtmuSRddj4Tns3e3H23WHRBC3Y7V9xjtqg4p+ZMnW7Bk
	2J82XwyMdRzbGrmeaGD4z1UcGpE0L+TEUfp74oj7isCp/RBeRUXIuHKK5dXDIHPnGNSZ
	QFrOh/B5PYZysgRw/mLKSoFAj7kmobxPLpF6PqOAJ3Od0+7l2EjNxJ8ybyUfxZY+BxBP
	O8XA==
MIME-Version: 1.0
X-Received: by 10.202.201.77 with SMTP id z74mr31884801oif.70.1417404872658;
	Sun, 30 Nov 2014 19:34:32 -0800 (PST)
Received: by 10.202.227.78 with HTTP; Sun, 30 Nov 2014 19:34:32 -0800 (PST)
In-Reply-To: <1415621371.28370.15.camel@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>
	<5460A51E.9050401@web2web.at>
	<1415621371.28370.15.camel@citrix.com>
Date: Mon, 1 Dec 2014 11:34:32 +0800
Message-ID: <CAF1ZMEc=Qsrw1QPzABMAFU5n1t_JZ2nRQFQ+T8xYnxqsGX4=og@mail.gmail.com>
From: "Dennis Lan (dlan)" <dennis.yxun@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
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 Mon, Nov 10, 2014 at 8:09 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 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.
>
Hi Ian
 what we found now is, the Gentoo's hardened toolchain, turn CFLAGS
-fstack-check on by default, with this flag and compile gcc will
result xl segfault (actually with libgcc_s.so)
 we have a patch to force gcc build libgcc(only this part) code with
-fstack-check=no, make the segfault gone
 more info can be found at https://bugs.gentoo.org/show_bug.cgi?id=528690

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

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 03:35:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 03:35:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvHl0-00083U-P3; Mon, 01 Dec 2014 03:34:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dennis.yxun@gmail.com>) id 1XvHkz-00083P-5B
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 03:34:37 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	0B/FC-03145-CC1EB745; Mon, 01 Dec 2014 03:34:36 +0000
X-Env-Sender: dennis.yxun@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417404872!12052149!1
X-Originating-IP: [209.85.214.182]
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 30538 invoked from network); 1 Dec 2014 03:34:33 -0000
Received: from mail-ob0-f182.google.com (HELO mail-ob0-f182.google.com)
	(209.85.214.182)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 03:34:33 -0000
Received: by mail-ob0-f182.google.com with SMTP id wo20so95176obc.41
	for <xen-devel@lists.xen.org>; Sun, 30 Nov 2014 19:34:32 -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=7u1Wp1d41JTenPimkLtgYve0OBOw3Nz/6vVDWUp0w1I=;
	b=UDJpGH8ggsPr+UGL/ymKBM2jdDk8jtHygFkfGrgsx69e2rdqvuC2xF9SVjZG1ksh1T
	clf9KQPnQOkzE7y/6ZOT3DLfFfN1mGvhU4T/ifnASLTN4Iamt5d8nBiaNeqccY+CHyi+
	gu7rbjYV38ltoK1wFYVHzDFVBtmuSRddj4Tns3e3H23WHRBC3Y7V9xjtqg4p+ZMnW7Bk
	2J82XwyMdRzbGrmeaGD4z1UcGpE0L+TEUfp74oj7isCp/RBeRUXIuHKK5dXDIHPnGNSZ
	QFrOh/B5PYZysgRw/mLKSoFAj7kmobxPLpF6PqOAJ3Od0+7l2EjNxJ8ybyUfxZY+BxBP
	O8XA==
MIME-Version: 1.0
X-Received: by 10.202.201.77 with SMTP id z74mr31884801oif.70.1417404872658;
	Sun, 30 Nov 2014 19:34:32 -0800 (PST)
Received: by 10.202.227.78 with HTTP; Sun, 30 Nov 2014 19:34:32 -0800 (PST)
In-Reply-To: <1415621371.28370.15.camel@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>
	<5460A51E.9050401@web2web.at>
	<1415621371.28370.15.camel@citrix.com>
Date: Mon, 1 Dec 2014 11:34:32 +0800
Message-ID: <CAF1ZMEc=Qsrw1QPzABMAFU5n1t_JZ2nRQFQ+T8xYnxqsGX4=og@mail.gmail.com>
From: "Dennis Lan (dlan)" <dennis.yxun@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
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 Mon, Nov 10, 2014 at 8:09 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 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.
>
Hi Ian
 what we found now is, the Gentoo's hardened toolchain, turn CFLAGS
-fstack-check on by default, with this flag and compile gcc will
result xl segfault (actually with libgcc_s.so)
 we have a patch to force gcc build libgcc(only this part) code with
-fstack-check=no, make the segfault gone
 more info can be found at https://bugs.gentoo.org/show_bug.cgi?id=528690

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

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 05:22:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 05:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvJQO-0000lE-9X; Mon, 01 Dec 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 1XvJQM-0000l9-Jz
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 05:21:26 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	CC/90-25276-6DAFB745; Mon, 01 Dec 2014 05:21:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417411284!12484586!1
X-Originating-IP: [66.165.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 28069 invoked from network); 1 Dec 2014 05:21:25 -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;
	1 Dec 2014 05:21:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,491,1413244800"; d="scan'208";a="197952929"
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, 1 Dec 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 1XvJQI-00014y-An;
	Mon, 01 Dec 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 1XvJQI-0006eA-26;
	Mon, 01 Dec 2014 05:21:22 +0000
Date: Mon, 1 Dec 2014 05:21:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31954-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] 31954: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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           4 xen-install                 fail pass in 31922
 test-amd64-i386-xl-credit2    9 guest-start                 fail pass in 31922
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail in 31922 pass in 31954

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-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-qemut-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-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 31922 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                                   fail    
 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 Dec 01 05:22:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 05:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvJQO-0000lE-9X; Mon, 01 Dec 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 1XvJQM-0000l9-Jz
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 05:21:26 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	CC/90-25276-6DAFB745; Mon, 01 Dec 2014 05:21:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417411284!12484586!1
X-Originating-IP: [66.165.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 28069 invoked from network); 1 Dec 2014 05:21:25 -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;
	1 Dec 2014 05:21:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,491,1413244800"; d="scan'208";a="197952929"
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, 1 Dec 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 1XvJQI-00014y-An;
	Mon, 01 Dec 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 1XvJQI-0006eA-26;
	Mon, 01 Dec 2014 05:21:22 +0000
Date: Mon, 1 Dec 2014 05:21:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31954-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] 31954: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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           4 xen-install                 fail pass in 31922
 test-amd64-i386-xl-credit2    9 guest-start                 fail pass in 31922
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail in 31922 pass in 31954

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-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-qemut-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-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 31922 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                                   fail    
 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 Dec 01 05:27:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 05:27:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvJWO-0000uz-6k; Mon, 01 Dec 2014 05:27:40 +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 1XvJWM-0000uu-JX
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 05:27:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	14/F3-09842-94CFB745; Mon, 01 Dec 2014 05:27:37 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417411654!12401720!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4325 invoked from network); 1 Dec 2014 05:27:34 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-21.messagelabs.com with SMTP;
	1 Dec 2014 05:27:34 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 30 Nov 2014 21:27:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,491,1413270000"; d="scan'208";a="616431407"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by orsmga001.jf.intel.com with ESMTP; 30 Nov 2014 21:27:32 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 1 Dec 2014 13:27:31 +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; Mon, 1 Dec 2014 13:27:23 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Pang, LongtaoX"
	<longtaox.pang@intel.com>
Thread-Topic: [OSSTEST PATCH 0/4] Introduction of the patches.
Thread-Index: AQHQCt9U51nJAt0eAUmNV0lPb//vxJx1cScAgASO5SA=
Date: Mon, 1 Dec 2014 05:27:23 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A723E1@SHSMSX103.ccr.corp.intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
	<21624.27112.826272.933990@mariner.uk.xensource.com>
In-Reply-To: <21624.27112.826272.933990@mariner.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: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, "Zheng,
	Di" <di.zheng@intel.com>,
	"xen-devel@lists.xen.org" <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


> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Friday, November 28, 2014 8:26 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; Ian.Campbell@citrix.com; wei.liu2@citrix.com;
> Hu, Robert; Zheng, Di
> Subject: Re: [OSSTEST PATCH 0/4] Introduction of the patches.
> 
> 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.
Hi Ian, thanks for your support and glad getting your attention on this.
We're new to osstest, and didn't find much documentation on its framework. 
So might violate some design and/or convention of it. We will modify as we get more conception of it.
> 
> 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.
Agree with you we shall reuse existing ts-* if possible. Actually I had thought of this approach but later I 
defeated myself because I thought ts-* shall compromise itself as a whole test case and better not to touch them.
Now I see that ts- is more like components to constitute a test case (my current understanding is your job == test cases).
If we had some documentation illustrating the your hierarchy of design, we should have less misunderstanding.
> 
> 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.
OK, we're going to do this, try to use ts-debian-hvm-install to fulfill the step of L1 dom0; 
use ts-xen-install to fulfil next step of constructing the normal guest to a L1 Xen environment.
We will probably changes some of ts-debian-hvm-install and ts-xen-install to fulfill our test case. 
e.g., we may use some different configuration for L1, we will parameterize some configurations which now is hard-coded.
> 
> 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 ?
We'll refine these parts to re-use existing things as much as possible. 
> 
> 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 Dec 01 05:27:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 05:27:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvJWO-0000uz-6k; Mon, 01 Dec 2014 05:27:40 +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 1XvJWM-0000uu-JX
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 05:27:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	14/F3-09842-94CFB745; Mon, 01 Dec 2014 05:27:37 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417411654!12401720!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4325 invoked from network); 1 Dec 2014 05:27:34 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-21.messagelabs.com with SMTP;
	1 Dec 2014 05:27:34 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 30 Nov 2014 21:27:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,491,1413270000"; d="scan'208";a="616431407"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by orsmga001.jf.intel.com with ESMTP; 30 Nov 2014 21:27:32 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 1 Dec 2014 13:27:31 +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; Mon, 1 Dec 2014 13:27:23 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Pang, LongtaoX"
	<longtaox.pang@intel.com>
Thread-Topic: [OSSTEST PATCH 0/4] Introduction of the patches.
Thread-Index: AQHQCt9U51nJAt0eAUmNV0lPb//vxJx1cScAgASO5SA=
Date: Mon, 1 Dec 2014 05:27:23 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31A723E1@SHSMSX103.ccr.corp.intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
	<21624.27112.826272.933990@mariner.uk.xensource.com>
In-Reply-To: <21624.27112.826272.933990@mariner.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: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, "Zheng,
	Di" <di.zheng@intel.com>,
	"xen-devel@lists.xen.org" <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


> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Friday, November 28, 2014 8:26 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; Ian.Campbell@citrix.com; wei.liu2@citrix.com;
> Hu, Robert; Zheng, Di
> Subject: Re: [OSSTEST PATCH 0/4] Introduction of the patches.
> 
> 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.
Hi Ian, thanks for your support and glad getting your attention on this.
We're new to osstest, and didn't find much documentation on its framework. 
So might violate some design and/or convention of it. We will modify as we get more conception of it.
> 
> 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.
Agree with you we shall reuse existing ts-* if possible. Actually I had thought of this approach but later I 
defeated myself because I thought ts-* shall compromise itself as a whole test case and better not to touch them.
Now I see that ts- is more like components to constitute a test case (my current understanding is your job == test cases).
If we had some documentation illustrating the your hierarchy of design, we should have less misunderstanding.
> 
> 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.
OK, we're going to do this, try to use ts-debian-hvm-install to fulfill the step of L1 dom0; 
use ts-xen-install to fulfil next step of constructing the normal guest to a L1 Xen environment.
We will probably changes some of ts-debian-hvm-install and ts-xen-install to fulfill our test case. 
e.g., we may use some different configuration for L1, we will parameterize some configurations which now is hard-coded.
> 
> 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 ?
We'll refine these parts to re-use existing things as much as possible. 
> 
> 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 Dec 01 07:53:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 07:53:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvLmZ-0001uu-1L; Mon, 01 Dec 2014 07:52:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eswierk@skyportsystems.com>) id 1XuwzA-0002LZ-6x
	for xen-devel@lists.xenproject.org; Sun, 30 Nov 2014 05:23:52 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	08/4F-22777-7E9AA745; Sun, 30 Nov 2014 05:23:51 +0000
X-Env-Sender: eswierk@skyportsystems.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417325029!11166765!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.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14483 invoked from network); 30 Nov 2014 05:23:50 -0000
Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com)
	(209.85.220.41)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 05:23:50 -0000
Received: by mail-pa0-f41.google.com with SMTP id rd3so8972119pab.14
	for <xen-devel@lists.xenproject.org>;
	Sat, 29 Nov 2014 21:23: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:from:to:cc:subject:date:message-id;
	bh=RwVwc9fAXSLQw9LCD+5OOD0GqsZUsbx0AJXpZEQclDE=;
	b=bt0BWU0NBAKl1MDIaHR9HuzBYc2xGGzhyOO1vCHhzozV87pGhhSe8GAl63X/s8q3Xk
	hCIZ7xInnzjNdjW8JaWhqDGVSETKFPSXMhzIl/vRwhnQBA0sAooC5lJ4OLbeYkV/dVGg
	70I4bY5FdVPgfu6/SbdGr9PvyI1RHA+6UyWDZMrlSCxc6+bMR7fEGjY8laV4rZXRoeFW
	JTL5rrSGcJtp2BfKLr5DcSoncgloLRreu7w+TWlVhHtPZjIiI5haNUhNC5GjxsCGy/oo
	r16gLfRH46kNkCMJ4iEqKVBjLu9sPiUJd9XSYaN+DMBXJMKjwkT8yxqnTX0FidJHN2Rl
	9Vqw==
X-Gm-Message-State: ALoCoQm+ZRV1v91D54ZJWTPkq3qf66caf67pDDyhqdbdArsvE5J68ERrAUPY5YZvYdpIu+gfZmTz
X-Received: by 10.70.138.104 with SMTP id qp8mr86027775pdb.99.1417325028983;
	Sat, 29 Nov 2014 21:23:48 -0800 (PST)
Received: from fido2.skyportsystems.com (gateway.skyportsystems.com.
	[74.93.0.69])
	by mx.google.com with ESMTPSA id y3sm13893180pbt.44.2014.11.29.21.23.47
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Sat, 29 Nov 2014 21:23:48 -0800 (PST)
From: Ed Swierk <eswierk@skyportsystems.com>
To: xen-devel@lists.xenproject.org
Date: Sat, 29 Nov 2014 21:23:35 -0800
Message-Id: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
X-Mailer: git-send-email 1.9.1
X-Mailman-Approved-At: Mon, 01 Dec 2014 07:52:29 +0000
Cc: eswierk@skyportsystems.com
Subject: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with bison
	3.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

- Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
  parameter
- Change deprecated %name-prefix= to %name-prefix

Tested against bison 2.4.1 and 3.0.2.

Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
---
 tools/libxl/libxlu_cfg_y.y | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
index aa9f787..5acd438 100644
--- a/tools/libxl/libxlu_cfg_y.y
+++ b/tools/libxl/libxlu_cfg_y.y
@@ -17,7 +17,7 @@
  */
 
 %{
-#define YYLEX_PARAM ctx->scanner
+#define ctx_scanner ctx->scanner
 #include "libxlu_cfg_i.h"
 #include "libxlu_cfg_l.h"
 %}
@@ -31,9 +31,9 @@
 %pure-parser
 %defines
 %error-verbose
-%name-prefix="xlu__cfg_yy"
+%name-prefix "xlu__cfg_yy"
 %parse-param { CfgParseContext *ctx }
-%lex-param { void *scanner }
+%lex-param { ctx_scanner }
 
 %token <string>                IDENT STRING NUMBER NEWLINE
 %type <string>            atom
-- 
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 Dec 01 07:53:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 07:53:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvLmZ-0001uu-1L; Mon, 01 Dec 2014 07:52:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eswierk@skyportsystems.com>) id 1XuwzA-0002LZ-6x
	for xen-devel@lists.xenproject.org; Sun, 30 Nov 2014 05:23:52 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	08/4F-22777-7E9AA745; Sun, 30 Nov 2014 05:23:51 +0000
X-Env-Sender: eswierk@skyportsystems.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417325029!11166765!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.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14483 invoked from network); 30 Nov 2014 05:23:50 -0000
Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com)
	(209.85.220.41)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2014 05:23:50 -0000
Received: by mail-pa0-f41.google.com with SMTP id rd3so8972119pab.14
	for <xen-devel@lists.xenproject.org>;
	Sat, 29 Nov 2014 21:23: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:from:to:cc:subject:date:message-id;
	bh=RwVwc9fAXSLQw9LCD+5OOD0GqsZUsbx0AJXpZEQclDE=;
	b=bt0BWU0NBAKl1MDIaHR9HuzBYc2xGGzhyOO1vCHhzozV87pGhhSe8GAl63X/s8q3Xk
	hCIZ7xInnzjNdjW8JaWhqDGVSETKFPSXMhzIl/vRwhnQBA0sAooC5lJ4OLbeYkV/dVGg
	70I4bY5FdVPgfu6/SbdGr9PvyI1RHA+6UyWDZMrlSCxc6+bMR7fEGjY8laV4rZXRoeFW
	JTL5rrSGcJtp2BfKLr5DcSoncgloLRreu7w+TWlVhHtPZjIiI5haNUhNC5GjxsCGy/oo
	r16gLfRH46kNkCMJ4iEqKVBjLu9sPiUJd9XSYaN+DMBXJMKjwkT8yxqnTX0FidJHN2Rl
	9Vqw==
X-Gm-Message-State: ALoCoQm+ZRV1v91D54ZJWTPkq3qf66caf67pDDyhqdbdArsvE5J68ERrAUPY5YZvYdpIu+gfZmTz
X-Received: by 10.70.138.104 with SMTP id qp8mr86027775pdb.99.1417325028983;
	Sat, 29 Nov 2014 21:23:48 -0800 (PST)
Received: from fido2.skyportsystems.com (gateway.skyportsystems.com.
	[74.93.0.69])
	by mx.google.com with ESMTPSA id y3sm13893180pbt.44.2014.11.29.21.23.47
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Sat, 29 Nov 2014 21:23:48 -0800 (PST)
From: Ed Swierk <eswierk@skyportsystems.com>
To: xen-devel@lists.xenproject.org
Date: Sat, 29 Nov 2014 21:23:35 -0800
Message-Id: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
X-Mailer: git-send-email 1.9.1
X-Mailman-Approved-At: Mon, 01 Dec 2014 07:52:29 +0000
Cc: eswierk@skyportsystems.com
Subject: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with bison
	3.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

- Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
  parameter
- Change deprecated %name-prefix= to %name-prefix

Tested against bison 2.4.1 and 3.0.2.

Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
---
 tools/libxl/libxlu_cfg_y.y | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
index aa9f787..5acd438 100644
--- a/tools/libxl/libxlu_cfg_y.y
+++ b/tools/libxl/libxlu_cfg_y.y
@@ -17,7 +17,7 @@
  */
 
 %{
-#define YYLEX_PARAM ctx->scanner
+#define ctx_scanner ctx->scanner
 #include "libxlu_cfg_i.h"
 #include "libxlu_cfg_l.h"
 %}
@@ -31,9 +31,9 @@
 %pure-parser
 %defines
 %error-verbose
-%name-prefix="xlu__cfg_yy"
+%name-prefix "xlu__cfg_yy"
 %parse-param { CfgParseContext *ctx }
-%lex-param { void *scanner }
+%lex-param { ctx_scanner }
 
 %token <string>                IDENT STRING NUMBER NEWLINE
 %type <string>            atom
-- 
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 Dec 01 08:21:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 08: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 1XvMEi-0002ay-Lh; Mon, 01 Dec 2014 08:21:36 +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 1XvMEg-0002at-RH
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 08:21:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B0/EA-09842-E052C745; Mon, 01 Dec 2014 08:21:34 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417422092!12514172!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 4541 invoked from network); 1 Dec 2014 08:21:33 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 08:21:33 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 01:21:31 -0700
Message-Id: <547CBFB80200006600040E25@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 01:21:28 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: <Ian.Campbell@citrix.com>,<konrad.wilk@oracle.com>
References: <1417154122-23669-1-git-send-email-cyliu@suse.com>
	<1417176083.23604.20.camel@citrix.com>
In-Reply-To: <1417176083.23604.20.camel@citrix.com>
Mime-Version: 1.0
Content-Length: 3267
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] =?utf-8?b?562U5aSN77yaIFJlOiBbUEFUQ0hdIG1pc3Npbmcg?=
 =?utf-8?q?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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cgo+Pj4gSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT4gMjAxNC0xMS0yOCDk
uIvljYggMjA6MDEgPj4+IApPbiBGcmksIDIwMTQtMTEtMjggYXQgMTM6NTUgKzA4MDAsIENodW55
YW4gTGl1IHdyb3RlOiAKPj4gRm91bmQgYnkgU3RlZmFubywgdGhpcyBjaHVuayBvZiB0aGUgcGF0
Y2ggd2FzIG5ldmVyIGFwcGxpZWQgdG8gCj4+IHhlbi11bnN0YWJsZSAoY29tbWl0IDExZGZmYTIz
NTllOGEyNjI5NDkwYzE0YzAyOWM3YzdjNzc3YjNlNDcpLCAKPj4gc2VlIGh0dHA6Ly9tYXJjLmlu
Zm8vP2w9cWVtdS1kZXZlbCZtPTE0MDQ3MTQ5MzQyNTM1MyZ3PTIuIAo+Cj4gSG93IHN0cmFuZ2Us
ICJnaXQgYW0iIHVzdWFsbHkgbWFrZXMgaXQgcHJldHR5IGRpZmZpY3VsdCB0byBtaXNzIGh1bmtz
LiAKPiBTb3JyeSBhYm91dCB0aGlzLiAKCj4+IFNpZ25lZC1vZmYtYnk6IENodW55YW4gTGl1IDxj
eWxpdUBzdXNlLmNvbT4gCgo+IEFja2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBj
aXRyaXguY29tPiAKCj4gSSdtIGFmcmFpZCB0aGF0IGRlc3BpdGUgdGhlIGNpcmN1bXN0YW5jZXMg
dGhpcyBzdGlsbCBuZWVkcyBhIHJlbGVhc2UgYWNrIAo+IGZyb20gS29ucmFkLiBPYnZpb3VzbHkg
dGhlIHVwc2lkZSBpcyBmaXhpbmcgYSBwYXJ0aWFsbHkgaW1wbGVtZW50ZWQgCj4gZmVhdHVyZSwg
YnV0IEknbSBub3Qgc3VyZSB3aGF0IHRoZSBkb3duc2lkZXMgYXJlLiAKPgo+IEhhcyB0aGlzIGJl
ZW4gdGVzdGVkIHdpdGggc3R1YmRvbXMsIGluY2x1ZGluZyB3aGVuIHRoaXMgZmVhdHVyZSBpcyBu
b3QgCj4gdXNlZD8gTXkgYmlnZ2VzdCBjb25jZXJuIGlzIHRoYXQgYmVjYXVzZSB0aGlzIGZ1bmN0
aW9uIGlzIGFsc28gdXNlZCB0byAKPiBidWlsZCB0aGUgY29tbWFuZCBsaW5lIGZvciB0aGUgc3R1
YmRvbSBhbmQgdGhlIHN0dWJkb20gaXMgUFYgYW5kIGhlbmNlIAo+IGhhcyBhdCBsZWFzdCBhIC0+
a2VybmVsIHNldHRpbmcgdGhlbiB0aGlzIG5ldyBjb2RlIG1pZ2h0IGJyZWFrIHRoYXQgdXNlIAo+
IGNhc2UsIGJ5IGFkZGluZyB0aGVzZSBvcHRpb25zIHdoZW4gdGhleSBhcmUgbm90IHdhbnRlZC4g
VGhpcyBwYXRoIGlzIGFsbCAKPiBhIGJpdCB0YW5nbGVkIHNvIEknbSBub3QgMTAwJSBzdXJlIGlm
IHRob3NlIGZpZWxkcyBhcmUgYWN0dWFsbHkgc2V0IG9yIAo+IG5vdC4KCgoKJy1rZXJuZWwnIGlz
IG9ubHkgYWRkZWQgdG8gcWVtdSBjb21tYW5kIGxpbmUgdW5kZXIgSFZNIGNhc2UuIFBWIHdvdWxk
Cgpub3QgYmUgYWZmZWN0ZWQuIEFuZCBvbmx5IGFkZGVkIHdoZW4gZGV2aWNlIG1vZGVsIGlzIHVw
c3RyZWFtIHFlbXUsIGJ1dAoKbm90IG9sZCBxZW11LXhlbi4gQWJvdXQgc3R1YmRvbSwgdGVzdGVk
IGJlZm9yZSwgd2hlbiBzdHViZG9tIGlzIHVzaW5nCgpvbGQgcWVtdS14ZW4sIHdvdWxkIG5vdCBi
ZSBhZmZlY3RlZC4KCj4KPj4gLS0tIAo+PiB0b29scy9saWJ4bC9saWJ4bF9kbS5jIHwgOSArKysr
KysrKysgCj4+IDEgZmlsZSBjaGFuZ2VkLCA5IGluc2VydGlvbnMoKykgCj4+IAo+PiBkaWZmIC0t
Z2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RtLmMgCj4+
IGluZGV4IDNlMTkxYzMuLmIyNWI1NzQgMTAwNjQ0IAo+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4
bF9kbS5jIAo+PiArKysgYi90b29scy9saWJ4bC9saWJ4bF9kbS5jIAo+PiBAQCAtNTI3LDYgKzUy
NywxNSBAQCBzdGF0aWMgY2hhciAqKiBsaWJ4bF9fYnVpbGRfZGV2aWNlX21vZGVsX2FyZ3NfbmV3
KGxpYnhsX19nYyAqZ2MsIAo+PiBpZiAoYl9pbmZvLT50eXBlID09IExJQlhMX0RPTUFJTl9UWVBF
X0hWTSkgeyAKPj4gaW50IGlvZW11X25pY3MgPSAwOyAKPj4gCj4+ICsgaWYgKGJfaW5mby0+a2Vy
bmVsKSAKPj4gKyBmbGV4YXJyYXlfdmFwcGVuZChkbV9hcmdzLCAiLWtlcm5lbCIsIGJfaW5mby0+
a2VybmVsLCBOVUxMKTsgCj4+ICsgCj4+ICsgaWYgKGJfaW5mby0+cmFtZGlzaykgCj4+ICsgZmxl
eGFycmF5X3ZhcHBlbmQoZG1fYXJncywgIi1pbml0cmQiLCBiX2luZm8tPnJhbWRpc2ssIE5VTEwp
OyAKPj4gKyAKPj4gKyBpZiAoYl9pbmZvLT5jbWRsaW5lKSAKPj4gKyBmbGV4YXJyYXlfdmFwcGVu
ZChkbV9hcmdzLCAiLWFwcGVuZCIsIGJfaW5mby0+Y21kbGluZSwgTlVMTCk7IAo+PiArIAo+PiBp
ZiAoYl9pbmZvLT51Lmh2bS5zZXJpYWwgfHwgYl9pbmZvLT51Lmh2bS5zZXJpYWxfbGlzdCkgeyAK
Pj4gaWYgKCBiX2luZm8tPnUuaHZtLnNlcmlhbCAmJiBiX2luZm8tPnUuaHZtLnNlcmlhbF9saXN0
ICkgCj4+IHsKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 01 08:21:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 08: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 1XvMEi-0002ay-Lh; Mon, 01 Dec 2014 08:21:36 +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 1XvMEg-0002at-RH
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 08:21:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B0/EA-09842-E052C745; Mon, 01 Dec 2014 08:21:34 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417422092!12514172!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 4541 invoked from network); 1 Dec 2014 08:21:33 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 08:21:33 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 01:21:31 -0700
Message-Id: <547CBFB80200006600040E25@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 01:21:28 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: <Ian.Campbell@citrix.com>,<konrad.wilk@oracle.com>
References: <1417154122-23669-1-git-send-email-cyliu@suse.com>
	<1417176083.23604.20.camel@citrix.com>
In-Reply-To: <1417176083.23604.20.camel@citrix.com>
Mime-Version: 1.0
Content-Length: 3267
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] =?utf-8?b?562U5aSN77yaIFJlOiBbUEFUQ0hdIG1pc3Npbmcg?=
 =?utf-8?q?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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cgo+Pj4gSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT4gMjAxNC0xMS0yOCDk
uIvljYggMjA6MDEgPj4+IApPbiBGcmksIDIwMTQtMTEtMjggYXQgMTM6NTUgKzA4MDAsIENodW55
YW4gTGl1IHdyb3RlOiAKPj4gRm91bmQgYnkgU3RlZmFubywgdGhpcyBjaHVuayBvZiB0aGUgcGF0
Y2ggd2FzIG5ldmVyIGFwcGxpZWQgdG8gCj4+IHhlbi11bnN0YWJsZSAoY29tbWl0IDExZGZmYTIz
NTllOGEyNjI5NDkwYzE0YzAyOWM3YzdjNzc3YjNlNDcpLCAKPj4gc2VlIGh0dHA6Ly9tYXJjLmlu
Zm8vP2w9cWVtdS1kZXZlbCZtPTE0MDQ3MTQ5MzQyNTM1MyZ3PTIuIAo+Cj4gSG93IHN0cmFuZ2Us
ICJnaXQgYW0iIHVzdWFsbHkgbWFrZXMgaXQgcHJldHR5IGRpZmZpY3VsdCB0byBtaXNzIGh1bmtz
LiAKPiBTb3JyeSBhYm91dCB0aGlzLiAKCj4+IFNpZ25lZC1vZmYtYnk6IENodW55YW4gTGl1IDxj
eWxpdUBzdXNlLmNvbT4gCgo+IEFja2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBj
aXRyaXguY29tPiAKCj4gSSdtIGFmcmFpZCB0aGF0IGRlc3BpdGUgdGhlIGNpcmN1bXN0YW5jZXMg
dGhpcyBzdGlsbCBuZWVkcyBhIHJlbGVhc2UgYWNrIAo+IGZyb20gS29ucmFkLiBPYnZpb3VzbHkg
dGhlIHVwc2lkZSBpcyBmaXhpbmcgYSBwYXJ0aWFsbHkgaW1wbGVtZW50ZWQgCj4gZmVhdHVyZSwg
YnV0IEknbSBub3Qgc3VyZSB3aGF0IHRoZSBkb3duc2lkZXMgYXJlLiAKPgo+IEhhcyB0aGlzIGJl
ZW4gdGVzdGVkIHdpdGggc3R1YmRvbXMsIGluY2x1ZGluZyB3aGVuIHRoaXMgZmVhdHVyZSBpcyBu
b3QgCj4gdXNlZD8gTXkgYmlnZ2VzdCBjb25jZXJuIGlzIHRoYXQgYmVjYXVzZSB0aGlzIGZ1bmN0
aW9uIGlzIGFsc28gdXNlZCB0byAKPiBidWlsZCB0aGUgY29tbWFuZCBsaW5lIGZvciB0aGUgc3R1
YmRvbSBhbmQgdGhlIHN0dWJkb20gaXMgUFYgYW5kIGhlbmNlIAo+IGhhcyBhdCBsZWFzdCBhIC0+
a2VybmVsIHNldHRpbmcgdGhlbiB0aGlzIG5ldyBjb2RlIG1pZ2h0IGJyZWFrIHRoYXQgdXNlIAo+
IGNhc2UsIGJ5IGFkZGluZyB0aGVzZSBvcHRpb25zIHdoZW4gdGhleSBhcmUgbm90IHdhbnRlZC4g
VGhpcyBwYXRoIGlzIGFsbCAKPiBhIGJpdCB0YW5nbGVkIHNvIEknbSBub3QgMTAwJSBzdXJlIGlm
IHRob3NlIGZpZWxkcyBhcmUgYWN0dWFsbHkgc2V0IG9yIAo+IG5vdC4KCgoKJy1rZXJuZWwnIGlz
IG9ubHkgYWRkZWQgdG8gcWVtdSBjb21tYW5kIGxpbmUgdW5kZXIgSFZNIGNhc2UuIFBWIHdvdWxk
Cgpub3QgYmUgYWZmZWN0ZWQuIEFuZCBvbmx5IGFkZGVkIHdoZW4gZGV2aWNlIG1vZGVsIGlzIHVw
c3RyZWFtIHFlbXUsIGJ1dAoKbm90IG9sZCBxZW11LXhlbi4gQWJvdXQgc3R1YmRvbSwgdGVzdGVk
IGJlZm9yZSwgd2hlbiBzdHViZG9tIGlzIHVzaW5nCgpvbGQgcWVtdS14ZW4sIHdvdWxkIG5vdCBi
ZSBhZmZlY3RlZC4KCj4KPj4gLS0tIAo+PiB0b29scy9saWJ4bC9saWJ4bF9kbS5jIHwgOSArKysr
KysrKysgCj4+IDEgZmlsZSBjaGFuZ2VkLCA5IGluc2VydGlvbnMoKykgCj4+IAo+PiBkaWZmIC0t
Z2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RtLmMgCj4+
IGluZGV4IDNlMTkxYzMuLmIyNWI1NzQgMTAwNjQ0IAo+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4
bF9kbS5jIAo+PiArKysgYi90b29scy9saWJ4bC9saWJ4bF9kbS5jIAo+PiBAQCAtNTI3LDYgKzUy
NywxNSBAQCBzdGF0aWMgY2hhciAqKiBsaWJ4bF9fYnVpbGRfZGV2aWNlX21vZGVsX2FyZ3NfbmV3
KGxpYnhsX19nYyAqZ2MsIAo+PiBpZiAoYl9pbmZvLT50eXBlID09IExJQlhMX0RPTUFJTl9UWVBF
X0hWTSkgeyAKPj4gaW50IGlvZW11X25pY3MgPSAwOyAKPj4gCj4+ICsgaWYgKGJfaW5mby0+a2Vy
bmVsKSAKPj4gKyBmbGV4YXJyYXlfdmFwcGVuZChkbV9hcmdzLCAiLWtlcm5lbCIsIGJfaW5mby0+
a2VybmVsLCBOVUxMKTsgCj4+ICsgCj4+ICsgaWYgKGJfaW5mby0+cmFtZGlzaykgCj4+ICsgZmxl
eGFycmF5X3ZhcHBlbmQoZG1fYXJncywgIi1pbml0cmQiLCBiX2luZm8tPnJhbWRpc2ssIE5VTEwp
OyAKPj4gKyAKPj4gKyBpZiAoYl9pbmZvLT5jbWRsaW5lKSAKPj4gKyBmbGV4YXJyYXlfdmFwcGVu
ZChkbV9hcmdzLCAiLWFwcGVuZCIsIGJfaW5mby0+Y21kbGluZSwgTlVMTCk7IAo+PiArIAo+PiBp
ZiAoYl9pbmZvLT51Lmh2bS5zZXJpYWwgfHwgYl9pbmZvLT51Lmh2bS5zZXJpYWxfbGlzdCkgeyAK
Pj4gaWYgKCBiX2luZm8tPnUuaHZtLnNlcmlhbCAmJiBiX2luZm8tPnUuaHZtLnNlcmlhbF9saXN0
ICkgCj4+IHsKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 01 08:51:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 08:51:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvMhL-0002qI-BQ; Mon, 01 Dec 2014 08:51:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XvMhJ-0002qA-Os
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 08:51:09 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	43/51-11581-DFB2C745; Mon, 01 Dec 2014 08:51:09 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417423863!10049839!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 8896 invoked from network); 1 Dec 2014 08:51:04 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-206.messagelabs.com with SMTP;
	1 Dec 2014 08:51:04 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 01 Dec 2014 00:51:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="616510456"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga001.jf.intel.com with ESMTP; 01 Dec 2014 00:50:59 -0800
Message-ID: <547C2BAF.6010004@linux.intel.com>
Date: Mon, 01 Dec 2014 16:49:51 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.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: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
In-Reply-To: <54785525020000780004B588@mail.emea.novell.com>
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-Transfer-Encoding: 7bit
Content-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/28/2014 5:57 PM, Jan Beulich wrote:
>>>> 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?
Thanks for your comments, Jan.
The indentation here is to make sure the
((p2mt == p2m_ram_ro) || (p2mt == p2m_mmio_write_dm)) are grouped 
together. But I am not sure if this is correct according to xen coding 
style. I may have misunderstood your previous comments on Sep 3, which 
said "the indentation would need adjustment" in reply to "[Xen-devel] 
[PATCH v3 1/2] x86: add p2m_mmio_write_dm"

>
> 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.
>
Thanks Jan.
To my understanding, pages with p2m_ram_ro are not supposed to be 
modified by guest. So in __hvm_copy(), when p2m type of a page is 
p2m_ram_rom, no copy will occur.
However, to our usage, we just wanna this page to be write protected, so 
that our device model can be triggered to do some emulation. The content 
written to this page is supposed not to be dropped. This way, if 
sequentially a read operation is performed by guest to this page, the 
guest will still see its anticipated value.

Maybe I need to update my commit message to explain this more clearly. :)

>> @@ -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?
>
Well, previsouly, I wished to differenciate the HVMMEM_ram_ro and the 
newly added HVMMEM_mmio_write_dm in the 
HVMOP_get_mem_type/HVMOP_set_mem_type hypercall. I'd rather think of 
this new type as write protected than read only.
But I'll take a look, to see if this can be added to P2M_RO_TYPES. Thanks.

Yu

> 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 Dec 01 08:51:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 08:51:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvMhL-0002qI-BQ; Mon, 01 Dec 2014 08:51:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XvMhJ-0002qA-Os
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 08:51:09 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	43/51-11581-DFB2C745; Mon, 01 Dec 2014 08:51:09 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417423863!10049839!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 8896 invoked from network); 1 Dec 2014 08:51:04 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-206.messagelabs.com with SMTP;
	1 Dec 2014 08:51:04 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 01 Dec 2014 00:51:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="616510456"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga001.jf.intel.com with ESMTP; 01 Dec 2014 00:50:59 -0800
Message-ID: <547C2BAF.6010004@linux.intel.com>
Date: Mon, 01 Dec 2014 16:49:51 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.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: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
In-Reply-To: <54785525020000780004B588@mail.emea.novell.com>
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-Transfer-Encoding: 7bit
Content-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/28/2014 5:57 PM, Jan Beulich wrote:
>>>> 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?
Thanks for your comments, Jan.
The indentation here is to make sure the
((p2mt == p2m_ram_ro) || (p2mt == p2m_mmio_write_dm)) are grouped 
together. But I am not sure if this is correct according to xen coding 
style. I may have misunderstood your previous comments on Sep 3, which 
said "the indentation would need adjustment" in reply to "[Xen-devel] 
[PATCH v3 1/2] x86: add p2m_mmio_write_dm"

>
> 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.
>
Thanks Jan.
To my understanding, pages with p2m_ram_ro are not supposed to be 
modified by guest. So in __hvm_copy(), when p2m type of a page is 
p2m_ram_rom, no copy will occur.
However, to our usage, we just wanna this page to be write protected, so 
that our device model can be triggered to do some emulation. The content 
written to this page is supposed not to be dropped. This way, if 
sequentially a read operation is performed by guest to this page, the 
guest will still see its anticipated value.

Maybe I need to update my commit message to explain this more clearly. :)

>> @@ -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?
>
Well, previsouly, I wished to differenciate the HVMMEM_ram_ro and the 
newly added HVMMEM_mmio_write_dm in the 
HVMOP_get_mem_type/HVMOP_set_mem_type hypercall. I'd rather think of 
this new type as write protected than read only.
But I'll take a look, to see if this can be added to P2M_RO_TYPES. Thanks.

Yu

> 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 Dec 01 08:56:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 08:56:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvMlp-00032V-6K; Mon, 01 Dec 2014 08:55:49 +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 1XvMln-00032P-Pu
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 08:55:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BC/24-09842-31D2C745; Mon, 01 Dec 2014 08:55:47 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417424146!12504225!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21849 invoked from network); 1 Dec 2014 08:55:46 -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;
	1 Dec 2014 08:55:46 -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 1XvMlj-0007vI-GI; Mon, 01 Dec 2014 08:55:43 +0000
Message-ID: <547C2CFC.7060908@canonical.com>
Date: Mon, 01 Dec 2014 09:55:24 +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@citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	David Vrabel <david.vrabel@citrix.com>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>
In-Reply-To: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3967042879536571651=="
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)
--===============3967042879536571651==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="s150fMuQq0LSLSF52s9aqbJl7oRUV2dRv"

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

On 11.08.2014 19:32, Zoltan Kiss wrote:
> There is a long known problem with the netfront/netback interface: if t=
he guest
> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 rin=
g slots,
> it gets dropped. The reason is that netback maps these slots to a frag =
in the
> frags array, which is limited by size. Having so many slots can occur s=
ince
> compound pages were introduced, as the ring protocol slice them up into=

> individual (non-compound) page aligned slots. The theoretical worst cas=
e
> scenario looks like this (note, skbs are limited to 64 Kb here):
> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page bound=
ary,
> using 2 slots
> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are =
at the
> end and the beginning of a page, therefore they use 3 * 15 =3D 45 slots=

> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 slots=

> Although I don't think this 51 slots skb can really happen, we need a s=
olution
> which can deal with every scenario. In real life there is only a few sl=
ots
> overdue, but usually it causes the TCP stream to be blocked, as the ret=
ry will
> most likely have the same buffer layout.
> This patch solves this problem by linearizing the packet. This is not t=
he
> fastest way, and it can fail much easier as it tries to allocate a big =
linear
> area for the whole packet, but probably easier by an order of magnitude=
 than
> anything else. Probably this code path is not touched very frequently a=
nyway.
>=20
> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Paul Durrant <paul.durrant@citrix.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: xen-devel@lists.xenproject.org

This does not seem to be marked explicitly as stable. Has someone already=
 asked
David Miller to put it on his stable queue? IMO it qualifies quite well a=
nd the
actual change should be simple to pick/backport.

-Stefan

>=20
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 055222b..23359ae 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -628,9 +628,10 @@ static int xennet_start_xmit(struct sk_buff *skb, =
struct net_device *dev)
>  	slots =3D DIV_ROUND_UP(offset + len, PAGE_SIZE) +
>  		xennet_count_skb_frag_slots(skb);
>  	if (unlikely(slots > MAX_SKB_FRAGS + 1)) {
> -		net_alert_ratelimited(
> -			"xennet: skb rides the rocket: %d slots\n", slots);
> -		goto drop;
> +		net_dbg_ratelimited("xennet: skb rides the rocket: %d slots, %d byte=
s\n",
> +				    slots, skb->len);
> +		if (skb_linearize(skb))
> +			goto drop;
>  	}
> =20
>  	spin_lock_irqsave(&queue->tx_lock, flags);
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--s150fMuQq0LSLSF52s9aqbJl7oRUV2dRv
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

iQIcBAEBCgAGBQJUfC0OAAoJEOhnXe7L7s6jxHEQALgipbF0gVIGN6YUt6utLg5b
QJ8obUcc1Ixkj8sjx3zzngSS2uViTjjLRKGg7LSEDxFkflvcytjPgImqv/xKOE5r
s7teGzYSy1E6qFgoTCHXy80wgWhrFP26Y5AjmFa4x+nFMAiMFE/BEFHj82XC9sZ1
vhtYugM9HsJwUhh4qWYPLltZyGWIzOgVzs3X1R/pE1VL8kMaLvlgNqZUHUv51bOo
zSmUOqzbqnPxWw4E8tLxVwL3e9QckjJ+8YFGK7ozW3xM4lmgKrya7JMUOB3EnrFQ
aZ1pvnnfXZUO1ScelgFNaxEg9cCVhzxdaM91RrbRb64p0DD6ToqZDkCLcOJKezzg
qz/gj4QqmXFE7ZlOe5HV0nSHFeIb6hnObO7Yi2D35nIceTaDtRRmB8Z2659b3Gex
F9jtoJ1kejrFaSQMoEnywDMyyn+oL0KvhDcIZOd9uzuZ2Nva8+Xpabc1Ihml7vUo
DYg6em1xyrjnf3TznDX+eC1ZyE1IPtZLacDFcAahFSBjhW/seYBqUnEFyccEDofu
OyMqwoC9R6E+Xj04VYZUOLaXMP7EMAnzuMHZpLrlwDXL8+791hFF6QG417KzYM2B
0++nkvypnif2QVdakursAzcM+IEbSEpoys0QvRjOEVnPwoSkWptqLXWRfpW4hsv4
O+GqOZhH4RVSE4cYcrl1
=Ec0I
-----END PGP SIGNATURE-----

--s150fMuQq0LSLSF52s9aqbJl7oRUV2dRv--


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

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

--===============3967042879536571651==--


From xen-devel-bounces@lists.xen.org Mon Dec 01 08:56:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 08:56:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvMlp-00032V-6K; Mon, 01 Dec 2014 08:55:49 +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 1XvMln-00032P-Pu
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 08:55:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BC/24-09842-31D2C745; Mon, 01 Dec 2014 08:55:47 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417424146!12504225!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21849 invoked from network); 1 Dec 2014 08:55:46 -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;
	1 Dec 2014 08:55:46 -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 1XvMlj-0007vI-GI; Mon, 01 Dec 2014 08:55:43 +0000
Message-ID: <547C2CFC.7060908@canonical.com>
Date: Mon, 01 Dec 2014 09:55:24 +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@citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	David Vrabel <david.vrabel@citrix.com>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>
In-Reply-To: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3967042879536571651=="
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)
--===============3967042879536571651==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="s150fMuQq0LSLSF52s9aqbJl7oRUV2dRv"

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

On 11.08.2014 19:32, Zoltan Kiss wrote:
> There is a long known problem with the netfront/netback interface: if t=
he guest
> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 rin=
g slots,
> it gets dropped. The reason is that netback maps these slots to a frag =
in the
> frags array, which is limited by size. Having so many slots can occur s=
ince
> compound pages were introduced, as the ring protocol slice them up into=

> individual (non-compound) page aligned slots. The theoretical worst cas=
e
> scenario looks like this (note, skbs are limited to 64 Kb here):
> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page bound=
ary,
> using 2 slots
> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are =
at the
> end and the beginning of a page, therefore they use 3 * 15 =3D 45 slots=

> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 slots=

> Although I don't think this 51 slots skb can really happen, we need a s=
olution
> which can deal with every scenario. In real life there is only a few sl=
ots
> overdue, but usually it causes the TCP stream to be blocked, as the ret=
ry will
> most likely have the same buffer layout.
> This patch solves this problem by linearizing the packet. This is not t=
he
> fastest way, and it can fail much easier as it tries to allocate a big =
linear
> area for the whole packet, but probably easier by an order of magnitude=
 than
> anything else. Probably this code path is not touched very frequently a=
nyway.
>=20
> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Paul Durrant <paul.durrant@citrix.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: xen-devel@lists.xenproject.org

This does not seem to be marked explicitly as stable. Has someone already=
 asked
David Miller to put it on his stable queue? IMO it qualifies quite well a=
nd the
actual change should be simple to pick/backport.

-Stefan

>=20
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 055222b..23359ae 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -628,9 +628,10 @@ static int xennet_start_xmit(struct sk_buff *skb, =
struct net_device *dev)
>  	slots =3D DIV_ROUND_UP(offset + len, PAGE_SIZE) +
>  		xennet_count_skb_frag_slots(skb);
>  	if (unlikely(slots > MAX_SKB_FRAGS + 1)) {
> -		net_alert_ratelimited(
> -			"xennet: skb rides the rocket: %d slots\n", slots);
> -		goto drop;
> +		net_dbg_ratelimited("xennet: skb rides the rocket: %d slots, %d byte=
s\n",
> +				    slots, skb->len);
> +		if (skb_linearize(skb))
> +			goto drop;
>  	}
> =20
>  	spin_lock_irqsave(&queue->tx_lock, flags);
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--s150fMuQq0LSLSF52s9aqbJl7oRUV2dRv
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

iQIcBAEBCgAGBQJUfC0OAAoJEOhnXe7L7s6jxHEQALgipbF0gVIGN6YUt6utLg5b
QJ8obUcc1Ixkj8sjx3zzngSS2uViTjjLRKGg7LSEDxFkflvcytjPgImqv/xKOE5r
s7teGzYSy1E6qFgoTCHXy80wgWhrFP26Y5AjmFa4x+nFMAiMFE/BEFHj82XC9sZ1
vhtYugM9HsJwUhh4qWYPLltZyGWIzOgVzs3X1R/pE1VL8kMaLvlgNqZUHUv51bOo
zSmUOqzbqnPxWw4E8tLxVwL3e9QckjJ+8YFGK7ozW3xM4lmgKrya7JMUOB3EnrFQ
aZ1pvnnfXZUO1ScelgFNaxEg9cCVhzxdaM91RrbRb64p0DD6ToqZDkCLcOJKezzg
qz/gj4QqmXFE7ZlOe5HV0nSHFeIb6hnObO7Yi2D35nIceTaDtRRmB8Z2659b3Gex
F9jtoJ1kejrFaSQMoEnywDMyyn+oL0KvhDcIZOd9uzuZ2Nva8+Xpabc1Ihml7vUo
DYg6em1xyrjnf3TznDX+eC1ZyE1IPtZLacDFcAahFSBjhW/seYBqUnEFyccEDofu
OyMqwoC9R6E+Xj04VYZUOLaXMP7EMAnzuMHZpLrlwDXL8+791hFF6QG417KzYM2B
0++nkvypnif2QVdakursAzcM+IEbSEpoys0QvRjOEVnPwoSkWptqLXWRfpW4hsv4
O+GqOZhH4RVSE4cYcrl1
=Ec0I
-----END PGP SIGNATURE-----

--s150fMuQq0LSLSF52s9aqbJl7oRUV2dRv--


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

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

--===============3967042879536571651==--


From xen-devel-bounces@lists.xen.org Mon Dec 01 09:21:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNAh-0003Ii-Cj; Mon, 01 Dec 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 <Ian.Campbell@citrix.com>) id 1XvNAg-0003Id-19
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:21:30 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	C2/CD-08051-9133C745; Mon, 01 Dec 2014 09:21:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417425687!12134160!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 536 invoked from network); 1 Dec 2014 09:21: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;
	1 Dec 2014 09:21:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,492,1413244800"; d="scan'208";a="198317501"
Message-ID: <1417425684.23604.70.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Mon, 1 Dec 2014 09:21:24 +0000
In-Reply-To: <547CBFB80200006600040E25@soto.provo.novell.com>
References: <1417154122-23669-1-git-send-email-cyliu@suse.com>
	<1417176083.23604.20.camel@citrix.com>
	<547CBFB80200006600040E25@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
Content-Length: 2477
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] =?utf-8?b?562U5aSN77yaIFJlOiBbUEFUQ0hdIG1pc3Npbmcg?=
 =?utf-8?q?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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDE0LTEyLTAxIGF0IDAxOjIxIC0wNzAwLCBDaHVuIFlhbiBMaXUgd3JvdGU6Cj4g
Cj4gPj4+IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+IDIwMTQtMTEtMjgg
5LiL5Y2IIDIwOjAxID4+PiAKPiBPbiBGcmksIDIwMTQtMTEtMjggYXQgMTM6NTUgKzA4MDAsIENo
dW55YW4gTGl1IHdyb3RlOiAKPiA+PiBGb3VuZCBieSBTdGVmYW5vLCB0aGlzIGNodW5rIG9mIHRo
ZSBwYXRjaCB3YXMgbmV2ZXIgYXBwbGllZCB0byAKPiA+PiB4ZW4tdW5zdGFibGUgKGNvbW1pdCAx
MWRmZmEyMzU5ZThhMjYyOTQ5MGMxNGMwMjljN2M3Yzc3N2IzZTQ3KSwgCj4gPj4gc2VlIGh0dHA6
Ly9tYXJjLmluZm8vP2w9cWVtdS1kZXZlbCZtPTE0MDQ3MTQ5MzQyNTM1MyZ3PTIuIAo+ID4KPiA+
IEhvdyBzdHJhbmdlLCAiZ2l0IGFtIiB1c3VhbGx5IG1ha2VzIGl0IHByZXR0eSBkaWZmaWN1bHQg
dG8gbWlzcyBodW5rcy4gCj4gPiBTb3JyeSBhYm91dCB0aGlzLiAKPiAKPiA+PiBTaWduZWQtb2Zm
LWJ5OiBDaHVueWFuIExpdSA8Y3lsaXVAc3VzZS5jb20+IAo+IAo+ID4gQWNrZWQtYnk6IElhbiBD
YW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+IAo+IAo+ID4gSSdtIGFmcmFpZCB0aGF0
IGRlc3BpdGUgdGhlIGNpcmN1bXN0YW5jZXMgdGhpcyBzdGlsbCBuZWVkcyBhIHJlbGVhc2UgYWNr
IAo+ID4gZnJvbSBLb25yYWQuIE9idmlvdXNseSB0aGUgdXBzaWRlIGlzIGZpeGluZyBhIHBhcnRp
YWxseSBpbXBsZW1lbnRlZCAKPiA+IGZlYXR1cmUsIGJ1dCBJJ20gbm90IHN1cmUgd2hhdCB0aGUg
ZG93bnNpZGVzIGFyZS4gCj4gPgo+ID4gSGFzIHRoaXMgYmVlbiB0ZXN0ZWQgd2l0aCBzdHViZG9t
cywgaW5jbHVkaW5nIHdoZW4gdGhpcyBmZWF0dXJlIGlzIG5vdCAKPiA+IHVzZWQ/IE15IGJpZ2dl
c3QgY29uY2VybiBpcyB0aGF0IGJlY2F1c2UgdGhpcyBmdW5jdGlvbiBpcyBhbHNvIHVzZWQgdG8g
Cj4gPiBidWlsZCB0aGUgY29tbWFuZCBsaW5lIGZvciB0aGUgc3R1YmRvbSBhbmQgdGhlIHN0dWJk
b20gaXMgUFYgYW5kIGhlbmNlIAo+ID4gaGFzIGF0IGxlYXN0IGEgLT5rZXJuZWwgc2V0dGluZyB0
aGVuIHRoaXMgbmV3IGNvZGUgbWlnaHQgYnJlYWsgdGhhdCB1c2UgCj4gPiBjYXNlLCBieSBhZGRp
bmcgdGhlc2Ugb3B0aW9ucyB3aGVuIHRoZXkgYXJlIG5vdCB3YW50ZWQuIFRoaXMgcGF0aCBpcyBh
bGwgCj4gPiBhIGJpdCB0YW5nbGVkIHNvIEknbSBub3QgMTAwJSBzdXJlIGlmIHRob3NlIGZpZWxk
cyBhcmUgYWN0dWFsbHkgc2V0IG9yIAo+ID4gbm90Lgo+IAo+IAo+IAo+ICcta2VybmVsJyBpcyBv
bmx5IGFkZGVkIHRvIHFlbXUgY29tbWFuZCBsaW5lIHVuZGVyIEhWTSBjYXNlLiBQViB3b3VsZAo+
IAo+IG5vdCBiZSBhZmZlY3RlZC4gQW5kIG9ubHkgYWRkZWQgd2hlbiBkZXZpY2UgbW9kZWwgaXMg
dXBzdHJlYW0gcWVtdSwgYnV0Cj4gCj4gbm90IG9sZCBxZW11LXhlbi4gQWJvdXQgc3R1YmRvbSwg
dGVzdGVkIGJlZm9yZSwgd2hlbiBzdHViZG9tIGlzIHVzaW5nCgo+IG9sZCBxZW11LXhlbiwgd291
bGQgbm90IGJlIGFmZmVjdGVkLgoKQWggeWVzLCBJJ2QgZm9yZ290dGVuIHdlIGRpZG4ndCBoYXZl
IHVwc3RyZWFtIHN0dWJkb20geWV0LCBvYnZpb3VzbHkgYW55Cmlzc3VlcyBoZXJlIHdpbGwgYmVj
b21lIGFwcGFyZW50IHdoZW5ldmVyIHRoYXQgZ2V0cyBpbXBsZW1lbnRlZC4KCklhbi4KCgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:21:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNAh-0003Ii-Cj; Mon, 01 Dec 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 <Ian.Campbell@citrix.com>) id 1XvNAg-0003Id-19
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:21:30 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	C2/CD-08051-9133C745; Mon, 01 Dec 2014 09:21:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417425687!12134160!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 536 invoked from network); 1 Dec 2014 09:21: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;
	1 Dec 2014 09:21:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,492,1413244800"; d="scan'208";a="198317501"
Message-ID: <1417425684.23604.70.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Mon, 1 Dec 2014 09:21:24 +0000
In-Reply-To: <547CBFB80200006600040E25@soto.provo.novell.com>
References: <1417154122-23669-1-git-send-email-cyliu@suse.com>
	<1417176083.23604.20.camel@citrix.com>
	<547CBFB80200006600040E25@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
Content-Length: 2477
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] =?utf-8?b?562U5aSN77yaIFJlOiBbUEFUQ0hdIG1pc3Npbmcg?=
 =?utf-8?q?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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDE0LTEyLTAxIGF0IDAxOjIxIC0wNzAwLCBDaHVuIFlhbiBMaXUgd3JvdGU6Cj4g
Cj4gPj4+IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+IDIwMTQtMTEtMjgg
5LiL5Y2IIDIwOjAxID4+PiAKPiBPbiBGcmksIDIwMTQtMTEtMjggYXQgMTM6NTUgKzA4MDAsIENo
dW55YW4gTGl1IHdyb3RlOiAKPiA+PiBGb3VuZCBieSBTdGVmYW5vLCB0aGlzIGNodW5rIG9mIHRo
ZSBwYXRjaCB3YXMgbmV2ZXIgYXBwbGllZCB0byAKPiA+PiB4ZW4tdW5zdGFibGUgKGNvbW1pdCAx
MWRmZmEyMzU5ZThhMjYyOTQ5MGMxNGMwMjljN2M3Yzc3N2IzZTQ3KSwgCj4gPj4gc2VlIGh0dHA6
Ly9tYXJjLmluZm8vP2w9cWVtdS1kZXZlbCZtPTE0MDQ3MTQ5MzQyNTM1MyZ3PTIuIAo+ID4KPiA+
IEhvdyBzdHJhbmdlLCAiZ2l0IGFtIiB1c3VhbGx5IG1ha2VzIGl0IHByZXR0eSBkaWZmaWN1bHQg
dG8gbWlzcyBodW5rcy4gCj4gPiBTb3JyeSBhYm91dCB0aGlzLiAKPiAKPiA+PiBTaWduZWQtb2Zm
LWJ5OiBDaHVueWFuIExpdSA8Y3lsaXVAc3VzZS5jb20+IAo+IAo+ID4gQWNrZWQtYnk6IElhbiBD
YW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+IAo+IAo+ID4gSSdtIGFmcmFpZCB0aGF0
IGRlc3BpdGUgdGhlIGNpcmN1bXN0YW5jZXMgdGhpcyBzdGlsbCBuZWVkcyBhIHJlbGVhc2UgYWNr
IAo+ID4gZnJvbSBLb25yYWQuIE9idmlvdXNseSB0aGUgdXBzaWRlIGlzIGZpeGluZyBhIHBhcnRp
YWxseSBpbXBsZW1lbnRlZCAKPiA+IGZlYXR1cmUsIGJ1dCBJJ20gbm90IHN1cmUgd2hhdCB0aGUg
ZG93bnNpZGVzIGFyZS4gCj4gPgo+ID4gSGFzIHRoaXMgYmVlbiB0ZXN0ZWQgd2l0aCBzdHViZG9t
cywgaW5jbHVkaW5nIHdoZW4gdGhpcyBmZWF0dXJlIGlzIG5vdCAKPiA+IHVzZWQ/IE15IGJpZ2dl
c3QgY29uY2VybiBpcyB0aGF0IGJlY2F1c2UgdGhpcyBmdW5jdGlvbiBpcyBhbHNvIHVzZWQgdG8g
Cj4gPiBidWlsZCB0aGUgY29tbWFuZCBsaW5lIGZvciB0aGUgc3R1YmRvbSBhbmQgdGhlIHN0dWJk
b20gaXMgUFYgYW5kIGhlbmNlIAo+ID4gaGFzIGF0IGxlYXN0IGEgLT5rZXJuZWwgc2V0dGluZyB0
aGVuIHRoaXMgbmV3IGNvZGUgbWlnaHQgYnJlYWsgdGhhdCB1c2UgCj4gPiBjYXNlLCBieSBhZGRp
bmcgdGhlc2Ugb3B0aW9ucyB3aGVuIHRoZXkgYXJlIG5vdCB3YW50ZWQuIFRoaXMgcGF0aCBpcyBh
bGwgCj4gPiBhIGJpdCB0YW5nbGVkIHNvIEknbSBub3QgMTAwJSBzdXJlIGlmIHRob3NlIGZpZWxk
cyBhcmUgYWN0dWFsbHkgc2V0IG9yIAo+ID4gbm90Lgo+IAo+IAo+IAo+ICcta2VybmVsJyBpcyBv
bmx5IGFkZGVkIHRvIHFlbXUgY29tbWFuZCBsaW5lIHVuZGVyIEhWTSBjYXNlLiBQViB3b3VsZAo+
IAo+IG5vdCBiZSBhZmZlY3RlZC4gQW5kIG9ubHkgYWRkZWQgd2hlbiBkZXZpY2UgbW9kZWwgaXMg
dXBzdHJlYW0gcWVtdSwgYnV0Cj4gCj4gbm90IG9sZCBxZW11LXhlbi4gQWJvdXQgc3R1YmRvbSwg
dGVzdGVkIGJlZm9yZSwgd2hlbiBzdHViZG9tIGlzIHVzaW5nCgo+IG9sZCBxZW11LXhlbiwgd291
bGQgbm90IGJlIGFmZmVjdGVkLgoKQWggeWVzLCBJJ2QgZm9yZ290dGVuIHdlIGRpZG4ndCBoYXZl
IHVwc3RyZWFtIHN0dWJkb20geWV0LCBvYnZpb3VzbHkgYW55Cmlzc3VlcyBoZXJlIHdpbGwgYmVj
b21lIGFwcGFyZW50IHdoZW5ldmVyIHRoYXQgZ2V0cyBpbXBsZW1lbnRlZC4KCklhbi4KCgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:29:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:29:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNIJ-0003UC-NZ; Mon, 01 Dec 2014 09:29:23 +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 1XvNIJ-0003Tt-0f
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 09:29:23 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	5C/6B-07724-FE43C745; Mon, 01 Dec 2014 09:29:19 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417426159!14893139!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 26505 invoked from network); 1 Dec 2014 09:29:19 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 09:29:19 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id D320FACDE;
	Mon,  1 Dec 2014 09:29:17 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org
Date: Mon,  1 Dec 2014 10:29:13 +0100
Message-Id: <1417426153-12893-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417426153-12893-1-git-send-email-jgross@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [Patch V2] 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, the root of the page table root and a p2m generation count.
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.

Right now XENFEAT_virtual_p2m will not be set. This will change when
the Xen tools support the virtual mapped p2m list.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/include/public/arch-x86/xen.h | 22 +++++++++++++++++++++-
 xen/include/public/features.h     |  3 +++
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index f35804b..14d3090 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -224,7 +224,27 @@ 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 three fields are valid if pfn_to_mfn_frame_list_list contains
+     * ~0UL.
+     * p2m_vaddr holds the virtual address of the linear p2m list. All entries
+     * in the range [0...max_pfn[ are accessible via this pointer.
+     * p2m_cr3 is the root of the address space where p2m_vaddr is valid.
+     * p2m_cr3 is in the same format as a cr3 value in the vcpu register state
+     * and holds the folded machine frame number (via xen_pfn_to_cr3) of a
+     * L3 or L4 page table.
+     * p2m_generation will be incremented by the guest before and after each
+     * change of the mappings of the p2m list. p2m_generation starts at 0 and
+     * a value with the least significant bit set indicates that a mapping
+     * update is in progress. This allows guest external software (e.g. in Dom0)
+     * to verify that read mappings are consistent and whether they have changed
+     * since the last check.
+     * Modifying a p2m element in the linear p2m list is allowed via an atomic
+     * write only.
+     */
+    unsigned long p2m_vaddr;       /* virtual address of the p2m list */
+    unsigned long p2m_cr3;         /* cr3 value of the p2m address space */
+    unsigned long p2m_generation;  /* generation count of p2m mapping */
 };
 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 Mon Dec 01 09:29:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:29:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNII-0003Tz-Bl; Mon, 01 Dec 2014 09:29: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 1XvNIG-0003Tu-S1
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 09:29:20 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	D4/D7-14214-FE43C745; Mon, 01 Dec 2014 09:29:19 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417426159!14163313!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 1089 invoked from network); 1 Dec 2014 09:29:19 -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; 1 Dec 2014 09:29:19 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A553FAC54;
	Mon,  1 Dec 2014 09:29:17 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org
Date: Mon,  1 Dec 2014 10:29:12 +0100
Message-Id: <1417426153-12893-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] 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.

Changes in V2:
- add new structure member p2m_generation in arch_shared_info
- rename structure member referencing the p2m address space to p2m_cr3
- add some comments
- removed patches 2-4 as overriding missing XENFEAT_virtual_p2m will be
  done via kernel parameter (patch 2 will be resent after Xen 4.5 is out)


Juergen Gross (1):
  expand x86 arch_shared_info to support linear p2m list

 xen/include/public/arch-x86/xen.h | 22 +++++++++++++++++++++-
 xen/include/public/features.h     |  3 +++
 2 files changed, 24 insertions(+), 1 deletion(-)

-- 
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 Mon Dec 01 09:29:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:29:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNIJ-0003UC-NZ; Mon, 01 Dec 2014 09:29:23 +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 1XvNIJ-0003Tt-0f
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 09:29:23 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	5C/6B-07724-FE43C745; Mon, 01 Dec 2014 09:29:19 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417426159!14893139!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 26505 invoked from network); 1 Dec 2014 09:29:19 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 09:29:19 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id D320FACDE;
	Mon,  1 Dec 2014 09:29:17 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org
Date: Mon,  1 Dec 2014 10:29:13 +0100
Message-Id: <1417426153-12893-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417426153-12893-1-git-send-email-jgross@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [Patch V2] 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, the root of the page table root and a p2m generation count.
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.

Right now XENFEAT_virtual_p2m will not be set. This will change when
the Xen tools support the virtual mapped p2m list.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/include/public/arch-x86/xen.h | 22 +++++++++++++++++++++-
 xen/include/public/features.h     |  3 +++
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index f35804b..14d3090 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -224,7 +224,27 @@ 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 three fields are valid if pfn_to_mfn_frame_list_list contains
+     * ~0UL.
+     * p2m_vaddr holds the virtual address of the linear p2m list. All entries
+     * in the range [0...max_pfn[ are accessible via this pointer.
+     * p2m_cr3 is the root of the address space where p2m_vaddr is valid.
+     * p2m_cr3 is in the same format as a cr3 value in the vcpu register state
+     * and holds the folded machine frame number (via xen_pfn_to_cr3) of a
+     * L3 or L4 page table.
+     * p2m_generation will be incremented by the guest before and after each
+     * change of the mappings of the p2m list. p2m_generation starts at 0 and
+     * a value with the least significant bit set indicates that a mapping
+     * update is in progress. This allows guest external software (e.g. in Dom0)
+     * to verify that read mappings are consistent and whether they have changed
+     * since the last check.
+     * Modifying a p2m element in the linear p2m list is allowed via an atomic
+     * write only.
+     */
+    unsigned long p2m_vaddr;       /* virtual address of the p2m list */
+    unsigned long p2m_cr3;         /* cr3 value of the p2m address space */
+    unsigned long p2m_generation;  /* generation count of p2m mapping */
 };
 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 Mon Dec 01 09:29:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:29:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNII-0003Tz-Bl; Mon, 01 Dec 2014 09:29: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 1XvNIG-0003Tu-S1
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 09:29:20 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	D4/D7-14214-FE43C745; Mon, 01 Dec 2014 09:29:19 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417426159!14163313!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 1089 invoked from network); 1 Dec 2014 09:29:19 -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; 1 Dec 2014 09:29:19 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A553FAC54;
	Mon,  1 Dec 2014 09:29:17 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org
Date: Mon,  1 Dec 2014 10:29:12 +0100
Message-Id: <1417426153-12893-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] 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.

Changes in V2:
- add new structure member p2m_generation in arch_shared_info
- rename structure member referencing the p2m address space to p2m_cr3
- add some comments
- removed patches 2-4 as overriding missing XENFEAT_virtual_p2m will be
  done via kernel parameter (patch 2 will be resent after Xen 4.5 is out)


Juergen Gross (1):
  expand x86 arch_shared_info to support linear p2m list

 xen/include/public/arch-x86/xen.h | 22 +++++++++++++++++++++-
 xen/include/public/features.h     |  3 +++
 2 files changed, 24 insertions(+), 1 deletion(-)

-- 
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 Mon Dec 01 09:30:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJD-0003c7-AL; Mon, 01 Dec 2014 09:30:19 +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 1XvNJC-0003bt-8Z
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:18 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	38/8F-02576-9253C745; Mon, 01 Dec 2014 09:30:17 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417426214!12143593!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 4506 invoked from network); 1 Dec 2014 09:30:15 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-27.messagelabs.com with SMTP;
	1 Dec 2014 09:30:15 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2014 01:27:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646100947"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:08 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:18 +0800
Message-Id: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 00/17] xen: RMRR fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

v8:

A brief summary:

* Rebased on the latest
* We skip creating p2m table associated to RMRR range as Jan and Tim commented
  And especially, this is identified to setting these tables as INVALID since
  as you know all p2m tables already are initialized as INVALID. Actually I also
  tried to reset them as INVALID again, everything is still fine but some
  warning logs show we're resetting these Already-Invalided p2m entries so just
  keep skipping these entries.
* Add something into mem_access to skip these RMRR ranges to make sure we're in
  the same page.
* Provide a new approach to control if
    1. we want to check/reserve all RMRR ranges
    2. Or just some RMRR ranges specific to those devices we want to PT
  This brings a new parameter to enable/disable this, and new domCTL to
  get SBDF associated to those PT devices.
* Add a new check point in mem_hole_alloc() since we may use this to allocate
  some ranges living in runtime cycle, like igd_opregion_pgbase.
* Some code itself improvements/corrections.

The details:

0001-tools-hvmloader-link-errno.h-from-xen-internal.patch

This is a new patch but Acked by Jan.

0002-introduce-XEN_DOMCTL_set_rdm.patch

This is a new patch to introduce that parameter and domCTL. Please refer
to the patch head description.

0003-introduce-XENMEM_reserved_device_memory_map.patch

This is slightly rebased to make sure all codes should be
in PT case, and this is from Jan and Acked by Kevin. To me, I just
rebase on the latest.

0004-update-the-existing-hypercall-to-support-XEN_DOMCTL_.patch

This is a new patch since after we introduce that parameter and
domCTL, we need to rework that existing hypercall from #4 patch.

Most should be discussed between Jan and me, but I changed something
slightly again since I found we were missing some scenarios, like
the hypercall caller don't know construct how much buffers to carry
forward all necessary entries at first, and additionally, we also
need to expose a return value from iommu ops as some caller expects.

So I have to ask Jan take a look at this again. And maybe we can
squash this into #4 eventually.

0005-tools-libxc-introduce-hypercall-for-xc_reserved_devi.patch
0006-tools-libxc-check-if-modules-space-is-overlapping-wi.patch
0007-hvmloader-util-get-reserved-device-memory-maps.patch

Just rebase and cleanup.

0008-hvmloader-mmio-reconcile-guest-mmio-with-reserved-de.patch

Just rebase and cleanup, and some code corrections as Jan comments.

0009-hvmloader-ram-check-if-guest-memory-is-out-of-reserv.patch

Just rebase and cleanup, and some code improvements.

0010-hvmloader-mem_hole_alloc-skip-any-overlap-with-reser.patch

This is a new used to address igd_opregion_pgbase as Yang mentioned
to me.

0011-xen-x86-p2m-reject-populating-for-reserved-device-me.patch

Refactor some codes to handle such a case. Note please refer to
a description above.

0012-xen-x86-ept-handle-reserved-device-memory-in-ept_han.patch

Just improve comments.

0013-xen-mem_access-don-t-allow-accessing-reserved-device.patch

This is a new to sync mem_access after our action in memory populating.

0014-xen-x86-p2m-introduce-set_identity_p2m_entry.patch
0015-xen-vtd-create-RMRR-mapping.patch
0016-xen-vtd-group-assigned-device-with-RMRR.patch

There's nothing to change.

0017-xen-vtd-re-enable-USB-device-assignment-if-enable-pc.patch

Just rebase.


How to reproduce this issu:

* In shared-ept case with Xen.
* Target owns RMRR.
* Do IGD passthrough with Windows guest OS: gfx_passthru=1 pci=["00:02.0"]
* Please use qemu-xen-traditional.

My test machine is BDW with Windows 7.

v7:

This series of patches try to reconcile those remaining problems but
just post as RFC to ask for any comments to refine everything.

The current whole scheme is as follows:

1. Reconcile guest mmio with RMRR in pci_setup
2. Reconcile guest RAM with RMRR in e820 table

Then in theory guest wouldn't access any RMRR range.

3. Just initialize all RMRR ranges as p2m_access_n in p2m table:
    gfn:mfn:p2m_access_n

Here I think we shouldn't set 1:1 to expose RMRR to guest if guest
may never have a device assignment. It can prevent from leaking RMRR.

4. We reset those mappings as 1:1:p2m_mmio_direct:p2m_ram_rw once we
have a device assignment.

5. Before we take real device assignment, any access to RMRR may issue
ept_handle_violation because of p2m_access_n. Then we just call
update_guest_eip() to return.

6. After a device assignment, guest may maliciously access RMRR ranges
although we already reserve in e820 table. In the worst-case scenario
just that device can't work well. But this behavior should be same as
native so I think we shouldn't do anything here.

7. Its not necessary to introduce any flag in ept_set_entry.

First of all, hypervisor/dom0 should be trusted. Any user should make
sure they never override any valid RMRR tables without any check. So
our original set_identity_p2m_entry() tries to set as follows:

 - gfn space unoccupied -> insert mapping; success.
 - gfn space already occupied by 1:1 RMRR mapping -> do nothing; success.
 - gfn space already occupied by other mapping -> fail.

Now in our case we add a rule:
 - if p2m_access_n is set we also set this mapping.

Another reason is that ept_set_entry is called in many scenarios to
support its own management, I think we shouldn't corrupt this mechanism
and its also difficult to cover all points.

8. We need to take a consideration grouping all devices that have same
RMRR range to make sure they're just assigned to one VM.

----------------------------------------------------------------
Jan Beulich (1):
      introduce XENMEM_reserved_device_memory_map

Tiejun Chen (16):
      tools/hvmloader: link errno.h from xen internal
      introduce XEN_DOMCTL_set_rdm
      update the existing hypercall to support XEN_DOMCTL_set_rdm
      tools/libxc: introduce hypercall for xc_reserved_device_memory_map
      tools/libxc: check if modules space is overlapping with reserved device memory
      hvmloader/util: get reserved device memory maps
      hvmloader/mmio: reconcile guest mmio with reserved device memory
      hvmloader/ram: check if guest memory is out of reserved device memory maps
      hvmloader/mem_hole_alloc: skip any overlap with reserved device memory
      xen/x86/p2m: reject populating for reserved device memory mapping
      xen/x86/ept: handle reserved device memory in ept_handle_violation
      xen/mem_access: don't allow accessing reserved device memory
      xen/x86/p2m: introduce set_identity_p2m_entry
      xen:vtd: create RMRR mapping
      xen/vtd: group assigned device with RMRR
      xen/vtd: re-enable USB device assignment if enable pci_force

 .gitignore                           |   1 +
 docs/man/xl.cfg.pod.5                |   6 ++++++
 docs/misc/vtd.txt                    |  15 ++++++++++++++
 tools/firmware/hvmloader/Makefile    |   7 ++++++-
 tools/firmware/hvmloader/e820.c      | 168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tools/firmware/hvmloader/pci.c       |  54 +++++++++++++++++++++++++++++++++++++++++++++++++-
 tools/firmware/hvmloader/util.c      |  90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 tools/firmware/hvmloader/util.h      |   4 ++++
 tools/libxc/include/xenctrl.h        |  11 +++++++++++
 tools/libxc/xc_domain.c              |  58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_hvm_build_x86.c       |  94 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------
 tools/libxl/libxl_create.c           |   3 +++
 tools/libxl/libxl_dm.c               |  47 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h         |   4 ++++
 tools/libxl/libxl_types.idl          |   2 ++
 tools/libxl/libxlu_pci.c             |   2 ++
 tools/libxl/xl_cmdimpl.c             |  10 ++++++++++
 xen/arch/x86/hvm/vmx/vmx.c           |  18 +++++++++++++++++
 xen/arch/x86/mm/p2m.c                |  87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 xen/common/compat/memory.c           |  97 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 xen/common/mem_access.c              |  41 ++++++++++++++++++++++++++++++++++++++
 xen/common/memory.c                  |  94 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 xen/drivers/passthrough/iommu.c      |  10 ++++++++++
 xen/drivers/passthrough/pci.c        |  39 ++++++++++++++++++++++++++++++++++++
 xen/drivers/passthrough/vtd/dmar.c   |  69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 xen/drivers/passthrough/vtd/dmar.h   |   3 +++
 xen/drivers/passthrough/vtd/extern.h |   1 +
 xen/drivers/passthrough/vtd/iommu.c  |  94 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
 xen/drivers/passthrough/vtd/utils.c  |  18 +++++++++++++++++
 xen/include/asm-x86/hvm/domain.h     |   4 ++++
 xen/include/asm-x86/p2m.h            |  13 ++++++++++++
 xen/include/public/domctl.h          |  21 ++++++++++++++++++++
 xen/include/public/memory.h          |  29 ++++++++++++++++++++++++++-
 xen/include/xen/iommu.h              |   4 ++++
 xen/include/xen/pci.h                |   2 ++
 xen/include/xlat.lst                 |   3 ++-
 xen/xsm/flask/hooks.c                |   1 +
 37 files changed, 1187 insertions(+), 37 deletions(-)

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 Dec 01 09:30:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJD-0003c7-AL; Mon, 01 Dec 2014 09:30:19 +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 1XvNJC-0003bt-8Z
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:18 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	38/8F-02576-9253C745; Mon, 01 Dec 2014 09:30:17 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417426214!12143593!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 4506 invoked from network); 1 Dec 2014 09:30:15 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-27.messagelabs.com with SMTP;
	1 Dec 2014 09:30:15 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2014 01:27:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646100947"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:08 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:18 +0800
Message-Id: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 00/17] xen: RMRR fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

v8:

A brief summary:

* Rebased on the latest
* We skip creating p2m table associated to RMRR range as Jan and Tim commented
  And especially, this is identified to setting these tables as INVALID since
  as you know all p2m tables already are initialized as INVALID. Actually I also
  tried to reset them as INVALID again, everything is still fine but some
  warning logs show we're resetting these Already-Invalided p2m entries so just
  keep skipping these entries.
* Add something into mem_access to skip these RMRR ranges to make sure we're in
  the same page.
* Provide a new approach to control if
    1. we want to check/reserve all RMRR ranges
    2. Or just some RMRR ranges specific to those devices we want to PT
  This brings a new parameter to enable/disable this, and new domCTL to
  get SBDF associated to those PT devices.
* Add a new check point in mem_hole_alloc() since we may use this to allocate
  some ranges living in runtime cycle, like igd_opregion_pgbase.
* Some code itself improvements/corrections.

The details:

0001-tools-hvmloader-link-errno.h-from-xen-internal.patch

This is a new patch but Acked by Jan.

0002-introduce-XEN_DOMCTL_set_rdm.patch

This is a new patch to introduce that parameter and domCTL. Please refer
to the patch head description.

0003-introduce-XENMEM_reserved_device_memory_map.patch

This is slightly rebased to make sure all codes should be
in PT case, and this is from Jan and Acked by Kevin. To me, I just
rebase on the latest.

0004-update-the-existing-hypercall-to-support-XEN_DOMCTL_.patch

This is a new patch since after we introduce that parameter and
domCTL, we need to rework that existing hypercall from #4 patch.

Most should be discussed between Jan and me, but I changed something
slightly again since I found we were missing some scenarios, like
the hypercall caller don't know construct how much buffers to carry
forward all necessary entries at first, and additionally, we also
need to expose a return value from iommu ops as some caller expects.

So I have to ask Jan take a look at this again. And maybe we can
squash this into #4 eventually.

0005-tools-libxc-introduce-hypercall-for-xc_reserved_devi.patch
0006-tools-libxc-check-if-modules-space-is-overlapping-wi.patch
0007-hvmloader-util-get-reserved-device-memory-maps.patch

Just rebase and cleanup.

0008-hvmloader-mmio-reconcile-guest-mmio-with-reserved-de.patch

Just rebase and cleanup, and some code corrections as Jan comments.

0009-hvmloader-ram-check-if-guest-memory-is-out-of-reserv.patch

Just rebase and cleanup, and some code improvements.

0010-hvmloader-mem_hole_alloc-skip-any-overlap-with-reser.patch

This is a new used to address igd_opregion_pgbase as Yang mentioned
to me.

0011-xen-x86-p2m-reject-populating-for-reserved-device-me.patch

Refactor some codes to handle such a case. Note please refer to
a description above.

0012-xen-x86-ept-handle-reserved-device-memory-in-ept_han.patch

Just improve comments.

0013-xen-mem_access-don-t-allow-accessing-reserved-device.patch

This is a new to sync mem_access after our action in memory populating.

0014-xen-x86-p2m-introduce-set_identity_p2m_entry.patch
0015-xen-vtd-create-RMRR-mapping.patch
0016-xen-vtd-group-assigned-device-with-RMRR.patch

There's nothing to change.

0017-xen-vtd-re-enable-USB-device-assignment-if-enable-pc.patch

Just rebase.


How to reproduce this issu:

* In shared-ept case with Xen.
* Target owns RMRR.
* Do IGD passthrough with Windows guest OS: gfx_passthru=1 pci=["00:02.0"]
* Please use qemu-xen-traditional.

My test machine is BDW with Windows 7.

v7:

This series of patches try to reconcile those remaining problems but
just post as RFC to ask for any comments to refine everything.

The current whole scheme is as follows:

1. Reconcile guest mmio with RMRR in pci_setup
2. Reconcile guest RAM with RMRR in e820 table

Then in theory guest wouldn't access any RMRR range.

3. Just initialize all RMRR ranges as p2m_access_n in p2m table:
    gfn:mfn:p2m_access_n

Here I think we shouldn't set 1:1 to expose RMRR to guest if guest
may never have a device assignment. It can prevent from leaking RMRR.

4. We reset those mappings as 1:1:p2m_mmio_direct:p2m_ram_rw once we
have a device assignment.

5. Before we take real device assignment, any access to RMRR may issue
ept_handle_violation because of p2m_access_n. Then we just call
update_guest_eip() to return.

6. After a device assignment, guest may maliciously access RMRR ranges
although we already reserve in e820 table. In the worst-case scenario
just that device can't work well. But this behavior should be same as
native so I think we shouldn't do anything here.

7. Its not necessary to introduce any flag in ept_set_entry.

First of all, hypervisor/dom0 should be trusted. Any user should make
sure they never override any valid RMRR tables without any check. So
our original set_identity_p2m_entry() tries to set as follows:

 - gfn space unoccupied -> insert mapping; success.
 - gfn space already occupied by 1:1 RMRR mapping -> do nothing; success.
 - gfn space already occupied by other mapping -> fail.

Now in our case we add a rule:
 - if p2m_access_n is set we also set this mapping.

Another reason is that ept_set_entry is called in many scenarios to
support its own management, I think we shouldn't corrupt this mechanism
and its also difficult to cover all points.

8. We need to take a consideration grouping all devices that have same
RMRR range to make sure they're just assigned to one VM.

----------------------------------------------------------------
Jan Beulich (1):
      introduce XENMEM_reserved_device_memory_map

Tiejun Chen (16):
      tools/hvmloader: link errno.h from xen internal
      introduce XEN_DOMCTL_set_rdm
      update the existing hypercall to support XEN_DOMCTL_set_rdm
      tools/libxc: introduce hypercall for xc_reserved_device_memory_map
      tools/libxc: check if modules space is overlapping with reserved device memory
      hvmloader/util: get reserved device memory maps
      hvmloader/mmio: reconcile guest mmio with reserved device memory
      hvmloader/ram: check if guest memory is out of reserved device memory maps
      hvmloader/mem_hole_alloc: skip any overlap with reserved device memory
      xen/x86/p2m: reject populating for reserved device memory mapping
      xen/x86/ept: handle reserved device memory in ept_handle_violation
      xen/mem_access: don't allow accessing reserved device memory
      xen/x86/p2m: introduce set_identity_p2m_entry
      xen:vtd: create RMRR mapping
      xen/vtd: group assigned device with RMRR
      xen/vtd: re-enable USB device assignment if enable pci_force

 .gitignore                           |   1 +
 docs/man/xl.cfg.pod.5                |   6 ++++++
 docs/misc/vtd.txt                    |  15 ++++++++++++++
 tools/firmware/hvmloader/Makefile    |   7 ++++++-
 tools/firmware/hvmloader/e820.c      | 168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tools/firmware/hvmloader/pci.c       |  54 +++++++++++++++++++++++++++++++++++++++++++++++++-
 tools/firmware/hvmloader/util.c      |  90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 tools/firmware/hvmloader/util.h      |   4 ++++
 tools/libxc/include/xenctrl.h        |  11 +++++++++++
 tools/libxc/xc_domain.c              |  58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_hvm_build_x86.c       |  94 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------
 tools/libxl/libxl_create.c           |   3 +++
 tools/libxl/libxl_dm.c               |  47 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h         |   4 ++++
 tools/libxl/libxl_types.idl          |   2 ++
 tools/libxl/libxlu_pci.c             |   2 ++
 tools/libxl/xl_cmdimpl.c             |  10 ++++++++++
 xen/arch/x86/hvm/vmx/vmx.c           |  18 +++++++++++++++++
 xen/arch/x86/mm/p2m.c                |  87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 xen/common/compat/memory.c           |  97 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 xen/common/mem_access.c              |  41 ++++++++++++++++++++++++++++++++++++++
 xen/common/memory.c                  |  94 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 xen/drivers/passthrough/iommu.c      |  10 ++++++++++
 xen/drivers/passthrough/pci.c        |  39 ++++++++++++++++++++++++++++++++++++
 xen/drivers/passthrough/vtd/dmar.c   |  69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 xen/drivers/passthrough/vtd/dmar.h   |   3 +++
 xen/drivers/passthrough/vtd/extern.h |   1 +
 xen/drivers/passthrough/vtd/iommu.c  |  94 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
 xen/drivers/passthrough/vtd/utils.c  |  18 +++++++++++++++++
 xen/include/asm-x86/hvm/domain.h     |   4 ++++
 xen/include/asm-x86/p2m.h            |  13 ++++++++++++
 xen/include/public/domctl.h          |  21 ++++++++++++++++++++
 xen/include/public/memory.h          |  29 ++++++++++++++++++++++++++-
 xen/include/xen/iommu.h              |   4 ++++
 xen/include/xen/pci.h                |   2 ++
 xen/include/xlat.lst                 |   3 ++-
 xen/xsm/flask/hooks.c                |   1 +
 37 files changed, 1187 insertions(+), 37 deletions(-)

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 Dec 01 09:30:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJH-0003dQ-Vw; Mon, 01 Dec 2014 09:30:23 +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 1XvNJF-0003cF-B9
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:21 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	8C/7F-02699-B253C745; Mon, 01 Dec 2014 09:30:19 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417426214!12143593!2
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 5446 invoked from network); 1 Dec 2014 09:30:19 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-27.messagelabs.com with SMTP;
	1 Dec 2014 09:30:19 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2014 01:27:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646100985"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:14 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:19 +0800
Message-Id: <1417425875-9634-2-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 01/17] 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.

Acked-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 .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 Mon Dec 01 09:30:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJH-0003dQ-Vw; Mon, 01 Dec 2014 09:30:23 +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 1XvNJF-0003cF-B9
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:21 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	8C/7F-02699-B253C745; Mon, 01 Dec 2014 09:30:19 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417426214!12143593!2
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 5446 invoked from network); 1 Dec 2014 09:30:19 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-27.messagelabs.com with SMTP;
	1 Dec 2014 09:30:19 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2014 01:27:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646100985"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:14 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:19 +0800
Message-Id: <1417425875-9634-2-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 01/17] 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.

Acked-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 .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 Mon Dec 01 09:30:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNJK-0003es-Me; Mon, 01 Dec 2014 09:30: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 1XvNJJ-0003dy-83
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:25 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	5F/AE-02953-0353C745; Mon, 01 Dec 2014 09:30:24 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417426214!12143593!3
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 6046 invoked from network); 1 Dec 2014 09:30:21 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-27.messagelabs.com with SMTP;
	1 Dec 2014 09:30:21 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2014 01:27:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101011"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:18 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:20 +0800
Message-Id: <1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This should be based on a new parameter globally, 'pci_rdmforce'.

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 this domctl provides an approach to control how to populate
reserved device memory by tools.

Note we always post a message to user about this once we owns
RMRR.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 docs/man/xl.cfg.pod.5              |  6 +++++
 docs/misc/vtd.txt                  | 15 ++++++++++++
 tools/libxc/include/xenctrl.h      |  6 +++++
 tools/libxc/xc_domain.c            | 28 +++++++++++++++++++++++
 tools/libxl/libxl_create.c         |  3 +++
 tools/libxl/libxl_dm.c             | 47 ++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h       |  4 ++++
 tools/libxl/libxl_types.idl        |  2 ++
 tools/libxl/libxlu_pci.c           |  2 ++
 tools/libxl/xl_cmdimpl.c           | 10 ++++++++
 xen/drivers/passthrough/pci.c      | 39 +++++++++++++++++++++++++++++++
 xen/drivers/passthrough/vtd/dmar.c |  8 +++++++
 xen/include/asm-x86/hvm/domain.h   |  4 ++++
 xen/include/public/domctl.h        | 21 +++++++++++++++++
 xen/xsm/flask/hooks.c              |  1 +
 15 files changed, 196 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 622ea53..9adc41e 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -645,6 +645,12 @@ dom0 without confirmation.  Please use with care.
 D0-D3hot power management states for the PCI device. False (0) by
 default.
 
+=item B<rdmforce=BOOLEAN>
+
+(HVM/x86 only) Specifies that the VM would force to check and try to
+reserve all reserved device memory, like RMRR, associated to the PCI
+device. False (0) by default.
+
 =back
 
 =back
diff --git a/docs/misc/vtd.txt b/docs/misc/vtd.txt
index 9af0e99..23544d5 100644
--- a/docs/misc/vtd.txt
+++ b/docs/misc/vtd.txt
@@ -111,6 +111,21 @@ in the config file:
 To override for a specific device:
 	pci = [ '01:00.0,msitranslate=0', '03:00.0' ]
 
+RDM, 'reserved device memory', for PCI Device Passthrough
+---------------------------------------------------------
+
+The BIOS controls some devices in terms of some reginos of memory used for
+these devices. This kind of region should be reserved before creating a VM
+to make sure they are not occupied by RAM/MMIO to conflict, and also we can
+create necessary IOMMU table successfully.
+
+To enable this globally, add "pci_rdmforce" in the config file:
+
+	pci_rdmforce = 1         (default is 0)
+
+Or just enable for a specific device:
+	pci = [ '01:00.0,rdmforce=1', '03:00.0' ]
+
 
 Caveat on Conventional PCI Device Passthrough
 ---------------------------------------------
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..84012fe 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2038,6 +2038,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 b864872..7fd43e9 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1633,6 +1633,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_t)domid;
+    domctl.u.set_rdm.flags = 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/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1198225..c615686 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -862,6 +862,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..e50587d 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -90,6 +90,53 @@ 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;
+    uint32_t rdmforce = 0;
+
+    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].devfn = PCI_DEVFN(d_config->pcidevs[i].dev,
+                                             d_config->pcidevs[i].func);
+                pcidevs[i].bus = d_config->pcidevs[i].bus;
+                pcidevs[i].seg = d_config->pcidevs[i].domain;
+                pcidevs[i].flags = d_config->pcidevs[i].rdmforce &
+                                   PCI_DEV_RDM_CHECK;
+            }
+        }
+        else
+        {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                               "Can't allocate for pcidevs.");
+            return -1;
+        }
+    }
+    rdmforce = libxl_defbool_val(d_config->b_info.rdmforce) ? 1 : 0;
+
+    /* Nothing to do. */
+    if ( !rdmforce && !d_config->num_pcidevs )
+        return 0;
+
+    ret = xc_domain_device_setrdm(ctx->xch, dm_domid,
+                                  (uint32_t)d_config->num_pcidevs,
+                                  rdmforce,
+                                  pcidevs);
+    if ( d_config->num_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 a38f695..be397a6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1477,6 +1477,10 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_disks, libxl_device_disk *disks,
         int nr_channels, libxl_device_channel *channels);
 
+_hidden int libxl__domain_device_setrdm(libxl__gc *gc,
+                                        libxl_domain_config *info,
+                                        uint32_t domid);
+
 /*
  * This function will cause the whole libxl process to hang
  * if the device model does not respond.  It is deprecated.
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..0076a32 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),
+    ("rdmforce",         libxl_defbool),
     ("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 0e754e7..9c23733 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -919,6 +919,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 +1700,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,6 +1723,7 @@ 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++;
         }
@@ -1726,6 +1731,11 @@ skip_vfb:
             libxl_defbool_set(&b_info->u.pv.e820_host, true);
     }
 
+    if ((c_info->type == LIBXL_DOMAIN_TYPE_HVM) && pci_rdmforce)
+        libxl_defbool_set(&b_info->rdmforce, true);
+    else
+        libxl_defbool_set(&b_info->rdmforce, false);
+
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
     case 0:
         {
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..ae924ad 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -34,6 +34,7 @@
 #include <xen/tasklet.h>
 #include <xsm/xsm.h>
 #include <asm/msi.h>
+#include <xen/stdbool.h>
 
 struct pci_seg {
     struct list_head alldevs_list;
@@ -1553,6 +1554,44 @@ 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 = NULL;
+        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
+
+        if ( d == NULL )
+            return -ESRCH;
+
+        d->arch.hvm_domain.pci_force =
+                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;
+        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;
+        d->arch.hvm_domain.pcidevs = NULL;
+
+        if ( xdsr->num_pcidevs )
+        {
+            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
+                                    xdsr->num_pcidevs);
+            if ( pcidevs == NULL )
+            {
+                rcu_unlock_domain(d);
+                return -ENOMEM;
+            }
+
+            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
+                                 xdsr->num_pcidevs*sizeof(*pcidevs)) )
+            {
+                xfree(pcidevs);
+                rcu_unlock_domain(d);
+                return -EFAULT;
+            }
+        }
+
+        d->arch.hvm_domain.pcidevs = pcidevs;
+        rcu_unlock_domain(d);
+    }
+        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 1152c3a..5e41e7a 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
                         "  RMRR region: base_addr %"PRIx64
                         " end_address %"PRIx64"\n",
                         rmrru->base_address, rmrru->end_address);
+            /*
+             * TODO: we may provide a precise paramter just to reserve
+             * RMRR range specific to one device.
+             */
+            dprintk(XENLOG_WARNING VTDPREFIX,
+                    "So please set pci_rdmforce to reserve these ranges"
+                    " if you need such a device in hotplug case.\n");
+
             acpi_register_rmrr_unit(rmrru);
         }
     }
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index 2757c7f..38530e5 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;
 
+    bool_t                  pci_force;
+    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 57e2ed7..ba8970d 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -508,6 +508,25 @@ struct xen_domctl_get_device_group {
 typedef struct xen_domctl_get_device_group xen_domctl_get_device_group_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_get_device_group_t);
 
+/* Currently just one bit to indicate force to check Reserved Device Memory. */
+#define PCI_DEV_RDM_CHECK   0x1
+struct xen_guest_pcidev_info {
+    uint16_t    seg;
+    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);
+
 /* Pass-through interrupts: bind real irq -> hvm devfn. */
 /* XEN_DOMCTL_bind_pt_irq */
 /* XEN_DOMCTL_unbind_pt_irq */
@@ -1070,6 +1089,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_setvnumainfo                  74
 #define XEN_DOMCTL_psr_cmt_op                    75
 #define XEN_DOMCTL_arm_configure_domain          76
+#define XEN_DOMCTL_set_rdm                       77
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1135,6 +1155,7 @@ struct xen_domctl {
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         struct xen_domctl_vnuma             vnuma;
         struct xen_domctl_psr_cmt_op        psr_cmt_op;
+        struct xen_domctl_set_rdm           set_rdm;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d48463f..5a760e2 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -592,6 +592,7 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_test_assign_device:
     case XEN_DOMCTL_assign_device:
     case XEN_DOMCTL_deassign_device:
+    case XEN_DOMCTL_set_rdm:
 #endif
         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 Dec 01 09:30:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNJK-0003es-Me; Mon, 01 Dec 2014 09:30: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 1XvNJJ-0003dy-83
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:25 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	5F/AE-02953-0353C745; Mon, 01 Dec 2014 09:30:24 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417426214!12143593!3
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 6046 invoked from network); 1 Dec 2014 09:30:21 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-27.messagelabs.com with SMTP;
	1 Dec 2014 09:30:21 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 01 Dec 2014 01:27:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101011"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:18 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:20 +0800
Message-Id: <1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This should be based on a new parameter globally, 'pci_rdmforce'.

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 this domctl provides an approach to control how to populate
reserved device memory by tools.

Note we always post a message to user about this once we owns
RMRR.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 docs/man/xl.cfg.pod.5              |  6 +++++
 docs/misc/vtd.txt                  | 15 ++++++++++++
 tools/libxc/include/xenctrl.h      |  6 +++++
 tools/libxc/xc_domain.c            | 28 +++++++++++++++++++++++
 tools/libxl/libxl_create.c         |  3 +++
 tools/libxl/libxl_dm.c             | 47 ++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h       |  4 ++++
 tools/libxl/libxl_types.idl        |  2 ++
 tools/libxl/libxlu_pci.c           |  2 ++
 tools/libxl/xl_cmdimpl.c           | 10 ++++++++
 xen/drivers/passthrough/pci.c      | 39 +++++++++++++++++++++++++++++++
 xen/drivers/passthrough/vtd/dmar.c |  8 +++++++
 xen/include/asm-x86/hvm/domain.h   |  4 ++++
 xen/include/public/domctl.h        | 21 +++++++++++++++++
 xen/xsm/flask/hooks.c              |  1 +
 15 files changed, 196 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 622ea53..9adc41e 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -645,6 +645,12 @@ dom0 without confirmation.  Please use with care.
 D0-D3hot power management states for the PCI device. False (0) by
 default.
 
+=item B<rdmforce=BOOLEAN>
+
+(HVM/x86 only) Specifies that the VM would force to check and try to
+reserve all reserved device memory, like RMRR, associated to the PCI
+device. False (0) by default.
+
 =back
 
 =back
diff --git a/docs/misc/vtd.txt b/docs/misc/vtd.txt
index 9af0e99..23544d5 100644
--- a/docs/misc/vtd.txt
+++ b/docs/misc/vtd.txt
@@ -111,6 +111,21 @@ in the config file:
 To override for a specific device:
 	pci = [ '01:00.0,msitranslate=0', '03:00.0' ]
 
+RDM, 'reserved device memory', for PCI Device Passthrough
+---------------------------------------------------------
+
+The BIOS controls some devices in terms of some reginos of memory used for
+these devices. This kind of region should be reserved before creating a VM
+to make sure they are not occupied by RAM/MMIO to conflict, and also we can
+create necessary IOMMU table successfully.
+
+To enable this globally, add "pci_rdmforce" in the config file:
+
+	pci_rdmforce = 1         (default is 0)
+
+Or just enable for a specific device:
+	pci = [ '01:00.0,rdmforce=1', '03:00.0' ]
+
 
 Caveat on Conventional PCI Device Passthrough
 ---------------------------------------------
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..84012fe 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2038,6 +2038,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 b864872..7fd43e9 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1633,6 +1633,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_t)domid;
+    domctl.u.set_rdm.flags = 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/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1198225..c615686 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -862,6 +862,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..e50587d 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -90,6 +90,53 @@ 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;
+    uint32_t rdmforce = 0;
+
+    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].devfn = PCI_DEVFN(d_config->pcidevs[i].dev,
+                                             d_config->pcidevs[i].func);
+                pcidevs[i].bus = d_config->pcidevs[i].bus;
+                pcidevs[i].seg = d_config->pcidevs[i].domain;
+                pcidevs[i].flags = d_config->pcidevs[i].rdmforce &
+                                   PCI_DEV_RDM_CHECK;
+            }
+        }
+        else
+        {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                               "Can't allocate for pcidevs.");
+            return -1;
+        }
+    }
+    rdmforce = libxl_defbool_val(d_config->b_info.rdmforce) ? 1 : 0;
+
+    /* Nothing to do. */
+    if ( !rdmforce && !d_config->num_pcidevs )
+        return 0;
+
+    ret = xc_domain_device_setrdm(ctx->xch, dm_domid,
+                                  (uint32_t)d_config->num_pcidevs,
+                                  rdmforce,
+                                  pcidevs);
+    if ( d_config->num_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 a38f695..be397a6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1477,6 +1477,10 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_disks, libxl_device_disk *disks,
         int nr_channels, libxl_device_channel *channels);
 
+_hidden int libxl__domain_device_setrdm(libxl__gc *gc,
+                                        libxl_domain_config *info,
+                                        uint32_t domid);
+
 /*
  * This function will cause the whole libxl process to hang
  * if the device model does not respond.  It is deprecated.
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..0076a32 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),
+    ("rdmforce",         libxl_defbool),
     ("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 0e754e7..9c23733 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -919,6 +919,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 +1700,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,6 +1723,7 @@ 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++;
         }
@@ -1726,6 +1731,11 @@ skip_vfb:
             libxl_defbool_set(&b_info->u.pv.e820_host, true);
     }
 
+    if ((c_info->type == LIBXL_DOMAIN_TYPE_HVM) && pci_rdmforce)
+        libxl_defbool_set(&b_info->rdmforce, true);
+    else
+        libxl_defbool_set(&b_info->rdmforce, false);
+
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
     case 0:
         {
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..ae924ad 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -34,6 +34,7 @@
 #include <xen/tasklet.h>
 #include <xsm/xsm.h>
 #include <asm/msi.h>
+#include <xen/stdbool.h>
 
 struct pci_seg {
     struct list_head alldevs_list;
@@ -1553,6 +1554,44 @@ 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 = NULL;
+        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
+
+        if ( d == NULL )
+            return -ESRCH;
+
+        d->arch.hvm_domain.pci_force =
+                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;
+        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;
+        d->arch.hvm_domain.pcidevs = NULL;
+
+        if ( xdsr->num_pcidevs )
+        {
+            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
+                                    xdsr->num_pcidevs);
+            if ( pcidevs == NULL )
+            {
+                rcu_unlock_domain(d);
+                return -ENOMEM;
+            }
+
+            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
+                                 xdsr->num_pcidevs*sizeof(*pcidevs)) )
+            {
+                xfree(pcidevs);
+                rcu_unlock_domain(d);
+                return -EFAULT;
+            }
+        }
+
+        d->arch.hvm_domain.pcidevs = pcidevs;
+        rcu_unlock_domain(d);
+    }
+        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 1152c3a..5e41e7a 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
                         "  RMRR region: base_addr %"PRIx64
                         " end_address %"PRIx64"\n",
                         rmrru->base_address, rmrru->end_address);
+            /*
+             * TODO: we may provide a precise paramter just to reserve
+             * RMRR range specific to one device.
+             */
+            dprintk(XENLOG_WARNING VTDPREFIX,
+                    "So please set pci_rdmforce to reserve these ranges"
+                    " if you need such a device in hotplug case.\n");
+
             acpi_register_rmrr_unit(rmrru);
         }
     }
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index 2757c7f..38530e5 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;
 
+    bool_t                  pci_force;
+    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 57e2ed7..ba8970d 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -508,6 +508,25 @@ struct xen_domctl_get_device_group {
 typedef struct xen_domctl_get_device_group xen_domctl_get_device_group_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_get_device_group_t);
 
+/* Currently just one bit to indicate force to check Reserved Device Memory. */
+#define PCI_DEV_RDM_CHECK   0x1
+struct xen_guest_pcidev_info {
+    uint16_t    seg;
+    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);
+
 /* Pass-through interrupts: bind real irq -> hvm devfn. */
 /* XEN_DOMCTL_bind_pt_irq */
 /* XEN_DOMCTL_unbind_pt_irq */
@@ -1070,6 +1089,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_setvnumainfo                  74
 #define XEN_DOMCTL_psr_cmt_op                    75
 #define XEN_DOMCTL_arm_configure_domain          76
+#define XEN_DOMCTL_set_rdm                       77
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1135,6 +1155,7 @@ struct xen_domctl {
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         struct xen_domctl_vnuma             vnuma;
         struct xen_domctl_psr_cmt_op        psr_cmt_op;
+        struct xen_domctl_set_rdm           set_rdm;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d48463f..5a760e2 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -592,6 +592,7 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_test_assign_device:
     case XEN_DOMCTL_assign_device:
     case XEN_DOMCTL_deassign_device:
+    case XEN_DOMCTL_set_rdm:
 #endif
         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 Dec 01 09:30:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNJP-0003hQ-5o; Mon, 01 Dec 2014 09:30: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 1XvNJN-0003gY-Ho
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:29 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	95/4A-05632-4353C745; Mon, 01 Dec 2014 09:30:28 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!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 3129 invoked from network); 1 Dec 2014 09:30:27 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:27 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101046"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:21 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:21 +0800
Message-Id: <1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 03/17] introduce
	XENMEM_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jan Beulich <jbeulich@suse.com>

This is a prerequisite for punching holes into HVM and PVH guests' P2M
to allow passing through devices that are associated with (on VT-d)
RMRRs.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
---
 xen/common/compat/memory.c           | 54 ++++++++++++++++++++++++++++++++++++
 xen/common/memory.c                  | 51 ++++++++++++++++++++++++++++++++++
 xen/drivers/passthrough/iommu.c      | 10 +++++++
 xen/drivers/passthrough/vtd/dmar.c   | 17 ++++++++++++
 xen/drivers/passthrough/vtd/extern.h |  1 +
 xen/drivers/passthrough/vtd/iommu.c  |  1 +
 xen/include/public/memory.h          | 24 +++++++++++++++-
 xen/include/xen/iommu.h              |  4 +++
 xen/include/xlat.lst                 |  3 +-
 9 files changed, 163 insertions(+), 2 deletions(-)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 06c90be..60512fa 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -16,6 +16,37 @@ CHECK_TYPE(domid);
 
 CHECK_mem_access_op;
 
+#ifdef HAS_PASSTHROUGH
+struct get_reserved_device_memory {
+    struct compat_reserved_device_memory_map map;
+    unsigned int used_entries;
+};
+
+static int get_reserved_device_memory(xen_pfn_t start,
+                                      xen_ulong_t nr, void *ctxt)
+{
+    struct get_reserved_device_memory *grdm = ctxt;
+
+    if ( grdm->used_entries < grdm->map.nr_entries )
+    {
+        struct compat_reserved_device_memory rdm = {
+            .start_pfn = start, .nr_pages = nr
+        };
+
+        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;
+    }
+
+    ++grdm->used_entries;
+
+    return 0;
+}
+#endif
+
 int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
 {
     int split, op = cmd & MEMOP_CMD_MASK;
@@ -273,6 +304,29 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
             break;
         }
 
+#ifdef HAS_PASSTHROUGH
+        case XENMEM_reserved_device_memory_map:
+        {
+            struct get_reserved_device_memory grdm;
+
+            if ( copy_from_guest(&grdm.map, compat, 1) ||
+                 !compat_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
+                return -EFAULT;
+
+            grdm.used_entries = 0;
+            rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
+                                                  &grdm);
+
+            if ( !rc && grdm.map.nr_entries < grdm.used_entries )
+                rc = -ENOBUFS;
+            grdm.map.nr_entries = grdm.used_entries;
+            if ( __copy_to_guest(compat, &grdm.map, 1) )
+                rc = -EFAULT;
+
+            return rc;
+        }
+#endif
+
         default:
             return compat_arch_memory_op(cmd, compat);
         }
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 9f21bd3..4788acc 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -692,6 +692,34 @@ out:
     return rc;
 }
 
+#ifdef HAS_PASSTHROUGH
+struct get_reserved_device_memory {
+    struct xen_reserved_device_memory_map map;
+    unsigned int used_entries;
+};
+
+static int get_reserved_device_memory(xen_pfn_t start,
+                                      xen_ulong_t nr, void *ctxt)
+{
+    struct get_reserved_device_memory *grdm = ctxt;
+
+    if ( grdm->used_entries < grdm->map.nr_entries )
+    {
+        struct xen_reserved_device_memory rdm = {
+            .start_pfn = start, .nr_pages = nr
+        };
+
+        if ( __copy_to_guest_offset(grdm->map.buffer, grdm->used_entries,
+                                    &rdm, 1) )
+            return -EFAULT;
+    }
+
+    ++grdm->used_entries;
+
+    return 0;
+}
+#endif
+
 long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d;
@@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         break;
     }
 
+#ifdef HAS_PASSTHROUGH
+    case XENMEM_reserved_device_memory_map:
+    {
+        struct get_reserved_device_memory grdm;
+
+        if ( copy_from_guest(&grdm.map, arg, 1) ||
+             !guest_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
+            return -EFAULT;
+
+        grdm.used_entries = 0;
+        rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
+                                              &grdm);
+
+        if ( !rc && grdm.map.nr_entries < grdm.used_entries )
+            rc = -ENOBUFS;
+        grdm.map.nr_entries = grdm.used_entries;
+        if ( __copy_to_guest(arg, &grdm.map, 1) )
+            rc = -EFAULT;
+
+        break;
+    }
+#endif
+
     default:
         rc = arch_memory_op(cmd, arg);
         break;
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index cc12735..7c17e8d 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -344,6 +344,16 @@ void iommu_crash_shutdown(void)
     iommu_enabled = iommu_intremap = 0;
 }
 
+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);
+}
+
 bool_t iommu_has_feature(struct domain *d, enum iommu_feature feature)
 {
     const struct hvm_iommu *hd = domain_hvm_iommu(d);
diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
index 5e41e7a..86cfad3 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -901,3 +901,20 @@ int platform_supports_x2apic(void)
     unsigned int mask = ACPI_DMAR_INTR_REMAP | ACPI_DMAR_X2APIC_OPT_OUT;
     return cpu_has_x2apic && ((dmar_flags & mask) == ACPI_DMAR_INTR_REMAP);
 }
+
+int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
+{
+    struct acpi_rmrr_unit *rmrr;
+    int rc = 0;
+
+    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;
+    }
+
+    return rc;
+}
diff --git a/xen/drivers/passthrough/vtd/extern.h b/xen/drivers/passthrough/vtd/extern.h
index 5524dba..f9ee9b0 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -75,6 +75,7 @@ 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);
 
 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/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index 19d8165..a38f201 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2491,6 +2491,7 @@ const struct iommu_ops intel_iommu_ops = {
     .crash_shutdown = vtd_crash_shutdown,
     .iotlb_flush = intel_iommu_iotlb_flush,
     .iotlb_flush_all = intel_iommu_iotlb_flush_all,
+    .get_reserved_device_memory = intel_iommu_get_reserved_device_memory,
     .dump_p2m_table = vtd_dump_p2m_table,
 };
 
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 595f953..cee4535 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -572,7 +572,29 @@ struct xen_vnuma_topology_info {
 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 */
+/*
+ * For legacy reasons, some devices must be configured with special memory
+ * regions to function correctly.  The guest must avoid using any of these
+ * regions.
+ */
+#define XENMEM_reserved_device_memory_map   27
+struct xen_reserved_device_memory {
+    xen_pfn_t start_pfn;
+    xen_ulong_t nr_pages;
+};
+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 {
+    /* IN/OUT */
+    unsigned int nr_entries;
+    /* OUT */
+    XEN_GUEST_HANDLE(xen_reserved_device_memory_t) buffer;
+};
+typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t;
+DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t);
+
+/* Next available subop number is 28 */
 
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 8eb764a..409f6f8 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -120,6 +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);
+
 struct iommu_ops {
     int (*init)(struct domain *d);
     void (*hwdom_init)(struct domain *d);
@@ -156,12 +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 *);
     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 *);
 
 void iommu_share_p2m_table(struct domain *d);
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 41b3e35..42229fd 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -61,9 +61,10 @@
 !	memory_exchange			memory.h
 !	memory_map			memory.h
 !	memory_reservation		memory.h
-?	mem_access_op		memory.h
+?	mem_access_op			memory.h
 !	pod_target			memory.h
 !	remove_from_physmap		memory.h
+!	reserved_device_memory_map	memory.h
 ?	physdev_eoi			physdev.h
 ?	physdev_get_free_pirq		physdev.h
 ?	physdev_irq			physdev.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 Dec 01 09:30:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNJP-0003hQ-5o; Mon, 01 Dec 2014 09:30: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 1XvNJN-0003gY-Ho
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:29 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	95/4A-05632-4353C745; Mon, 01 Dec 2014 09:30:28 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!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 3129 invoked from network); 1 Dec 2014 09:30:27 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:27 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101046"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:21 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:21 +0800
Message-Id: <1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 03/17] introduce
	XENMEM_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jan Beulich <jbeulich@suse.com>

This is a prerequisite for punching holes into HVM and PVH guests' P2M
to allow passing through devices that are associated with (on VT-d)
RMRRs.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
---
 xen/common/compat/memory.c           | 54 ++++++++++++++++++++++++++++++++++++
 xen/common/memory.c                  | 51 ++++++++++++++++++++++++++++++++++
 xen/drivers/passthrough/iommu.c      | 10 +++++++
 xen/drivers/passthrough/vtd/dmar.c   | 17 ++++++++++++
 xen/drivers/passthrough/vtd/extern.h |  1 +
 xen/drivers/passthrough/vtd/iommu.c  |  1 +
 xen/include/public/memory.h          | 24 +++++++++++++++-
 xen/include/xen/iommu.h              |  4 +++
 xen/include/xlat.lst                 |  3 +-
 9 files changed, 163 insertions(+), 2 deletions(-)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 06c90be..60512fa 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -16,6 +16,37 @@ CHECK_TYPE(domid);
 
 CHECK_mem_access_op;
 
+#ifdef HAS_PASSTHROUGH
+struct get_reserved_device_memory {
+    struct compat_reserved_device_memory_map map;
+    unsigned int used_entries;
+};
+
+static int get_reserved_device_memory(xen_pfn_t start,
+                                      xen_ulong_t nr, void *ctxt)
+{
+    struct get_reserved_device_memory *grdm = ctxt;
+
+    if ( grdm->used_entries < grdm->map.nr_entries )
+    {
+        struct compat_reserved_device_memory rdm = {
+            .start_pfn = start, .nr_pages = nr
+        };
+
+        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;
+    }
+
+    ++grdm->used_entries;
+
+    return 0;
+}
+#endif
+
 int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
 {
     int split, op = cmd & MEMOP_CMD_MASK;
@@ -273,6 +304,29 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
             break;
         }
 
+#ifdef HAS_PASSTHROUGH
+        case XENMEM_reserved_device_memory_map:
+        {
+            struct get_reserved_device_memory grdm;
+
+            if ( copy_from_guest(&grdm.map, compat, 1) ||
+                 !compat_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
+                return -EFAULT;
+
+            grdm.used_entries = 0;
+            rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
+                                                  &grdm);
+
+            if ( !rc && grdm.map.nr_entries < grdm.used_entries )
+                rc = -ENOBUFS;
+            grdm.map.nr_entries = grdm.used_entries;
+            if ( __copy_to_guest(compat, &grdm.map, 1) )
+                rc = -EFAULT;
+
+            return rc;
+        }
+#endif
+
         default:
             return compat_arch_memory_op(cmd, compat);
         }
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 9f21bd3..4788acc 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -692,6 +692,34 @@ out:
     return rc;
 }
 
+#ifdef HAS_PASSTHROUGH
+struct get_reserved_device_memory {
+    struct xen_reserved_device_memory_map map;
+    unsigned int used_entries;
+};
+
+static int get_reserved_device_memory(xen_pfn_t start,
+                                      xen_ulong_t nr, void *ctxt)
+{
+    struct get_reserved_device_memory *grdm = ctxt;
+
+    if ( grdm->used_entries < grdm->map.nr_entries )
+    {
+        struct xen_reserved_device_memory rdm = {
+            .start_pfn = start, .nr_pages = nr
+        };
+
+        if ( __copy_to_guest_offset(grdm->map.buffer, grdm->used_entries,
+                                    &rdm, 1) )
+            return -EFAULT;
+    }
+
+    ++grdm->used_entries;
+
+    return 0;
+}
+#endif
+
 long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d;
@@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         break;
     }
 
+#ifdef HAS_PASSTHROUGH
+    case XENMEM_reserved_device_memory_map:
+    {
+        struct get_reserved_device_memory grdm;
+
+        if ( copy_from_guest(&grdm.map, arg, 1) ||
+             !guest_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
+            return -EFAULT;
+
+        grdm.used_entries = 0;
+        rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
+                                              &grdm);
+
+        if ( !rc && grdm.map.nr_entries < grdm.used_entries )
+            rc = -ENOBUFS;
+        grdm.map.nr_entries = grdm.used_entries;
+        if ( __copy_to_guest(arg, &grdm.map, 1) )
+            rc = -EFAULT;
+
+        break;
+    }
+#endif
+
     default:
         rc = arch_memory_op(cmd, arg);
         break;
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index cc12735..7c17e8d 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -344,6 +344,16 @@ void iommu_crash_shutdown(void)
     iommu_enabled = iommu_intremap = 0;
 }
 
+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);
+}
+
 bool_t iommu_has_feature(struct domain *d, enum iommu_feature feature)
 {
     const struct hvm_iommu *hd = domain_hvm_iommu(d);
diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
index 5e41e7a..86cfad3 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -901,3 +901,20 @@ int platform_supports_x2apic(void)
     unsigned int mask = ACPI_DMAR_INTR_REMAP | ACPI_DMAR_X2APIC_OPT_OUT;
     return cpu_has_x2apic && ((dmar_flags & mask) == ACPI_DMAR_INTR_REMAP);
 }
+
+int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
+{
+    struct acpi_rmrr_unit *rmrr;
+    int rc = 0;
+
+    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;
+    }
+
+    return rc;
+}
diff --git a/xen/drivers/passthrough/vtd/extern.h b/xen/drivers/passthrough/vtd/extern.h
index 5524dba..f9ee9b0 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -75,6 +75,7 @@ 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);
 
 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/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index 19d8165..a38f201 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2491,6 +2491,7 @@ const struct iommu_ops intel_iommu_ops = {
     .crash_shutdown = vtd_crash_shutdown,
     .iotlb_flush = intel_iommu_iotlb_flush,
     .iotlb_flush_all = intel_iommu_iotlb_flush_all,
+    .get_reserved_device_memory = intel_iommu_get_reserved_device_memory,
     .dump_p2m_table = vtd_dump_p2m_table,
 };
 
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 595f953..cee4535 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -572,7 +572,29 @@ struct xen_vnuma_topology_info {
 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 */
+/*
+ * For legacy reasons, some devices must be configured with special memory
+ * regions to function correctly.  The guest must avoid using any of these
+ * regions.
+ */
+#define XENMEM_reserved_device_memory_map   27
+struct xen_reserved_device_memory {
+    xen_pfn_t start_pfn;
+    xen_ulong_t nr_pages;
+};
+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 {
+    /* IN/OUT */
+    unsigned int nr_entries;
+    /* OUT */
+    XEN_GUEST_HANDLE(xen_reserved_device_memory_t) buffer;
+};
+typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t;
+DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t);
+
+/* Next available subop number is 28 */
 
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 8eb764a..409f6f8 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -120,6 +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);
+
 struct iommu_ops {
     int (*init)(struct domain *d);
     void (*hwdom_init)(struct domain *d);
@@ -156,12 +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 *);
     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 *);
 
 void iommu_share_p2m_table(struct domain *d);
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 41b3e35..42229fd 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -61,9 +61,10 @@
 !	memory_exchange			memory.h
 !	memory_map			memory.h
 !	memory_reservation		memory.h
-?	mem_access_op		memory.h
+?	mem_access_op			memory.h
 !	pod_target			memory.h
 !	remove_from_physmap		memory.h
+!	reserved_device_memory_map	memory.h
 ?	physdev_eoi			physdev.h
 ?	physdev_get_free_pirq		physdev.h
 ?	physdev_irq			physdev.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 Dec 01 09:30:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNJU-0003lI-Qg; Mon, 01 Dec 2014 09:30:36 +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 1XvNJS-0003jf-N0
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:34 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	62/67-18267-A353C745; Mon, 01 Dec 2014 09:30:34 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!2
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 4338 invoked from network); 1 Dec 2014 09:30:32 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:32 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101077"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:26 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:22 +0800
Message-Id: <1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
	support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

After we intend to expost that hypercall explicitly based on
XEN_DOMCTL_set_rdm, we need this rebase. I hope we can squash
this into that previous patch once Jan Ack this.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/common/compat/memory.c         | 75 ++++++++++++++++++++++++++++++--------
 xen/common/memory.c                | 71 +++++++++++++++++++++++++++++-------
 xen/drivers/passthrough/vtd/dmar.c | 32 ++++++++++++----
 xen/include/public/memory.h        |  5 +++
 xen/include/xen/iommu.h            |  2 +-
 xen/include/xen/pci.h              |  2 +
 6 files changed, 148 insertions(+), 39 deletions(-)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 60512fa..e6a256e 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -22,27 +22,66 @@ 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;
+    unsigned int i;
+    u32 sbdf;
+    struct compat_reserved_device_memory rdm = {
+        .start_pfn = start, .nr_pages = nr
+    };
 
-    if ( grdm->used_entries < grdm->map.nr_entries )
-    {
-        struct compat_reserved_device_memory rdm = {
-            .start_pfn = start, .nr_pages = nr
-        };
+    if ( rdm.start_pfn != start || rdm.nr_pages != nr )
+        return -ERANGE;
 
-        if ( rdm.start_pfn != start || rdm.nr_pages != nr )
-            return -ERANGE;
+    d = rcu_lock_domain_by_any_id(grdm->map.domid);
+    if ( d == NULL )
+        return -ESRCH;
 
-        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
-                                     &rdm, 1) )
-            return -EFAULT;
+    if ( d )
+    {
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( grdm->used_entries < grdm->map.nr_entries )
+            {
+                if ( __copy_to_compat_offset(grdm->map.buffer,
+                                             grdm->used_entries,
+                                             &rdm, 1) )
+                {
+                    rcu_unlock_domain(d);
+                    return -EFAULT;
+                }
+            }
+            ++grdm->used_entries;
+        }
+        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 ( grdm->used_entries < grdm->map.nr_entries )
+                    {
+                        if ( __copy_to_compat_offset(grdm->map.buffer,
+                                                     grdm->used_entries,
+                                                     &rdm, 1) )
+                        {
+                            rcu_unlock_domain(d);
+                            return -EFAULT;
+                        }
+                    }
+                    ++grdm->used_entries;
+                }
+            }
+        }
     }
 
-    ++grdm->used_entries;
-
+    rcu_unlock_domain(d);
     return 0;
 }
 #endif
@@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
 
             if ( !rc && grdm.map.nr_entries < grdm.used_entries )
                 rc = -ENOBUFS;
+
             grdm.map.nr_entries = grdm.used_entries;
-            if ( __copy_to_guest(compat, &grdm.map, 1) )
-                rc = -EFAULT;
+            if ( grdm.map.nr_entries )
+            {
+                if ( __copy_to_guest(compat, &grdm.map, 1) )
+                    rc = -EFAULT;
+            }
 
             return rc;
         }
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 4788acc..9ce82b1 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -698,24 +698,63 @@ 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;
+    unsigned int i;
+    u32 sbdf;
+    struct xen_reserved_device_memory rdm = {
+        .start_pfn = start, .nr_pages = nr
+    };
 
-    if ( grdm->used_entries < grdm->map.nr_entries )
-    {
-        struct xen_reserved_device_memory rdm = {
-            .start_pfn = start, .nr_pages = nr
-        };
+    d = rcu_lock_domain_by_any_id(grdm->map.domid);
+    if ( d == NULL )
+        return -ESRCH;
 
-        if ( __copy_to_guest_offset(grdm->map.buffer, grdm->used_entries,
-                                    &rdm, 1) )
-            return -EFAULT;
+    if ( d )
+    {
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( grdm->used_entries < grdm->map.nr_entries )
+            {
+                if ( __copy_to_guest_offset(grdm->map.buffer,
+                                            grdm->used_entries,
+                                            &rdm, 1) )
+                {
+                    rcu_unlock_domain(d);
+                    return -EFAULT;
+                }
+            }
+            ++grdm->used_entries;
+        }
+        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 ( grdm->used_entries < grdm->map.nr_entries )
+                    {
+                        if ( __copy_to_guest_offset(grdm->map.buffer,
+                                                    grdm->used_entries,
+                                                    &rdm, 1) )
+                        {
+                            rcu_unlock_domain(d);
+                            return -EFAULT;
+                        }
+                    }
+                    ++grdm->used_entries;
+                }
+            }
+        }
     }
 
-    ++grdm->used_entries;
-
+    rcu_unlock_domain(d);
     return 0;
 }
 #endif
@@ -1144,9 +1183,13 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
         if ( !rc && grdm.map.nr_entries < grdm.used_entries )
             rc = -ENOBUFS;
+
         grdm.map.nr_entries = grdm.used_entries;
-        if ( __copy_to_guest(arg, &grdm.map, 1) )
-            rc = -EFAULT;
+        if ( grdm.map.nr_entries )
+        {
+            if ( __copy_to_guest(arg, &grdm.map, 1) )
+                rc = -EFAULT;
+        }
 
         break;
     }
diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
index 86cfad3..c5bc8d6 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
 
 int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
 {
-    struct acpi_rmrr_unit *rmrr;
+    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
     int rc = 0;
+    unsigned 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 ( 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;
+
+            /* Just go next. */
+            if ( !rc )
+                rmrr_cur = rmrr;
+
+            /* Now just return specific to user requirement. */
+            if ( rc > 0 )
+                return rc;
+        }
     }
 
-    return rc;
+    return 0;
 }
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index cee4535..0d0544e 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -586,6 +586,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..8fc6d6d 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, u32 id, 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 5f295f3..d34205f 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;
-- 
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 Dec 01 09:30:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNJU-0003lI-Qg; Mon, 01 Dec 2014 09:30:36 +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 1XvNJS-0003jf-N0
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:34 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	62/67-18267-A353C745; Mon, 01 Dec 2014 09:30:34 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!2
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 4338 invoked from network); 1 Dec 2014 09:30:32 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:32 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101077"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:26 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:22 +0800
Message-Id: <1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
	support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

After we intend to expost that hypercall explicitly based on
XEN_DOMCTL_set_rdm, we need this rebase. I hope we can squash
this into that previous patch once Jan Ack this.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/common/compat/memory.c         | 75 ++++++++++++++++++++++++++++++--------
 xen/common/memory.c                | 71 +++++++++++++++++++++++++++++-------
 xen/drivers/passthrough/vtd/dmar.c | 32 ++++++++++++----
 xen/include/public/memory.h        |  5 +++
 xen/include/xen/iommu.h            |  2 +-
 xen/include/xen/pci.h              |  2 +
 6 files changed, 148 insertions(+), 39 deletions(-)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 60512fa..e6a256e 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -22,27 +22,66 @@ 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;
+    unsigned int i;
+    u32 sbdf;
+    struct compat_reserved_device_memory rdm = {
+        .start_pfn = start, .nr_pages = nr
+    };
 
-    if ( grdm->used_entries < grdm->map.nr_entries )
-    {
-        struct compat_reserved_device_memory rdm = {
-            .start_pfn = start, .nr_pages = nr
-        };
+    if ( rdm.start_pfn != start || rdm.nr_pages != nr )
+        return -ERANGE;
 
-        if ( rdm.start_pfn != start || rdm.nr_pages != nr )
-            return -ERANGE;
+    d = rcu_lock_domain_by_any_id(grdm->map.domid);
+    if ( d == NULL )
+        return -ESRCH;
 
-        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
-                                     &rdm, 1) )
-            return -EFAULT;
+    if ( d )
+    {
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( grdm->used_entries < grdm->map.nr_entries )
+            {
+                if ( __copy_to_compat_offset(grdm->map.buffer,
+                                             grdm->used_entries,
+                                             &rdm, 1) )
+                {
+                    rcu_unlock_domain(d);
+                    return -EFAULT;
+                }
+            }
+            ++grdm->used_entries;
+        }
+        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 ( grdm->used_entries < grdm->map.nr_entries )
+                    {
+                        if ( __copy_to_compat_offset(grdm->map.buffer,
+                                                     grdm->used_entries,
+                                                     &rdm, 1) )
+                        {
+                            rcu_unlock_domain(d);
+                            return -EFAULT;
+                        }
+                    }
+                    ++grdm->used_entries;
+                }
+            }
+        }
     }
 
-    ++grdm->used_entries;
-
+    rcu_unlock_domain(d);
     return 0;
 }
 #endif
@@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
 
             if ( !rc && grdm.map.nr_entries < grdm.used_entries )
                 rc = -ENOBUFS;
+
             grdm.map.nr_entries = grdm.used_entries;
-            if ( __copy_to_guest(compat, &grdm.map, 1) )
-                rc = -EFAULT;
+            if ( grdm.map.nr_entries )
+            {
+                if ( __copy_to_guest(compat, &grdm.map, 1) )
+                    rc = -EFAULT;
+            }
 
             return rc;
         }
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 4788acc..9ce82b1 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -698,24 +698,63 @@ 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;
+    unsigned int i;
+    u32 sbdf;
+    struct xen_reserved_device_memory rdm = {
+        .start_pfn = start, .nr_pages = nr
+    };
 
-    if ( grdm->used_entries < grdm->map.nr_entries )
-    {
-        struct xen_reserved_device_memory rdm = {
-            .start_pfn = start, .nr_pages = nr
-        };
+    d = rcu_lock_domain_by_any_id(grdm->map.domid);
+    if ( d == NULL )
+        return -ESRCH;
 
-        if ( __copy_to_guest_offset(grdm->map.buffer, grdm->used_entries,
-                                    &rdm, 1) )
-            return -EFAULT;
+    if ( d )
+    {
+        if ( d->arch.hvm_domain.pci_force )
+        {
+            if ( grdm->used_entries < grdm->map.nr_entries )
+            {
+                if ( __copy_to_guest_offset(grdm->map.buffer,
+                                            grdm->used_entries,
+                                            &rdm, 1) )
+                {
+                    rcu_unlock_domain(d);
+                    return -EFAULT;
+                }
+            }
+            ++grdm->used_entries;
+        }
+        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 ( grdm->used_entries < grdm->map.nr_entries )
+                    {
+                        if ( __copy_to_guest_offset(grdm->map.buffer,
+                                                    grdm->used_entries,
+                                                    &rdm, 1) )
+                        {
+                            rcu_unlock_domain(d);
+                            return -EFAULT;
+                        }
+                    }
+                    ++grdm->used_entries;
+                }
+            }
+        }
     }
 
-    ++grdm->used_entries;
-
+    rcu_unlock_domain(d);
     return 0;
 }
 #endif
@@ -1144,9 +1183,13 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
         if ( !rc && grdm.map.nr_entries < grdm.used_entries )
             rc = -ENOBUFS;
+
         grdm.map.nr_entries = grdm.used_entries;
-        if ( __copy_to_guest(arg, &grdm.map, 1) )
-            rc = -EFAULT;
+        if ( grdm.map.nr_entries )
+        {
+            if ( __copy_to_guest(arg, &grdm.map, 1) )
+                rc = -EFAULT;
+        }
 
         break;
     }
diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
index 86cfad3..c5bc8d6 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
 
 int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
 {
-    struct acpi_rmrr_unit *rmrr;
+    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
     int rc = 0;
+    unsigned 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 ( 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;
+
+            /* Just go next. */
+            if ( !rc )
+                rmrr_cur = rmrr;
+
+            /* Now just return specific to user requirement. */
+            if ( rc > 0 )
+                return rc;
+        }
     }
 
-    return rc;
+    return 0;
 }
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index cee4535..0d0544e 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -586,6 +586,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..8fc6d6d 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, u32 id, 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 5f295f3..d34205f 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;
-- 
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 Dec 01 09:30:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNJV-0003lc-8h; Mon, 01 Dec 2014 09:30:37 +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 1XvNJU-0003kY-74
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:36 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	EC/F6-09284-B353C745; Mon, 01 Dec 2014 09:30:35 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!3
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 4663 invoked from network); 1 Dec 2014 09:30:34 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:34 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101101"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:30 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:23 +0800
Message-Id: <1417425875-9634-6-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 05/17] tools/libxc: introduce hypercall for
	xc_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will introduce that hypercall xc_reserved_device_memory_map
approach to libxc.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 tools/libxc/include/xenctrl.h |  5 +++++
 tools/libxc/xc_domain.c       | 30 ++++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 84012fe..a3aeac3 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1294,6 +1294,11 @@ int xc_domain_set_memory_map(xc_interface *xch,
 int xc_get_machine_memory_map(xc_interface *xch,
                               struct e820entry entries[],
                               uint32_t max_entries);
+
+int xc_reserved_device_memory_map(xc_interface *xch,
+                                  uint32_t dom,
+                                  struct xen_reserved_device_memory entries[],
+                                  uint32_t *max_entries);
 #endif
 int xc_domain_set_time_offset(xc_interface *xch,
                               uint32_t domid,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 7fd43e9..09fd988 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -679,6 +679,36 @@ int xc_domain_set_memory_map(xc_interface *xch,
 
     return rc;
 }
+
+int xc_reserved_device_memory_map(xc_interface *xch,
+                                  uint32_t domid,
+                                  struct xen_reserved_device_memory entries[],
+                                  uint32_t *max_entries)
+{
+    int rc;
+    struct xen_reserved_device_memory_map xrdmmap = {
+        .domid = domid,
+        .nr_entries = *max_entries
+    };
+    DECLARE_HYPERCALL_BOUNCE(entries,
+                             sizeof(struct xen_reserved_device_memory) *
+                             *max_entries, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+    if ( xc_hypercall_bounce_pre(xch, entries) )
+        return -1;
+
+    set_xen_guest_handle(xrdmmap.buffer, entries);
+
+    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
+                      &xrdmmap, sizeof(xrdmmap));
+
+    xc_hypercall_bounce_post(xch, entries);
+
+    *max_entries = xrdmmap.nr_entries;
+
+    return rc ? rc : xrdmmap.nr_entries;
+}
+
 int xc_get_machine_memory_map(xc_interface *xch,
                               struct e820entry entries[],
                               uint32_t max_entries)
-- 
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 Dec 01 09:30:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNJV-0003lc-8h; Mon, 01 Dec 2014 09:30:37 +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 1XvNJU-0003kY-74
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:36 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	EC/F6-09284-B353C745; Mon, 01 Dec 2014 09:30:35 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!3
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 4663 invoked from network); 1 Dec 2014 09:30:34 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:34 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101101"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:30 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:23 +0800
Message-Id: <1417425875-9634-6-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 05/17] tools/libxc: introduce hypercall for
	xc_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will introduce that hypercall xc_reserved_device_memory_map
approach to libxc.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 tools/libxc/include/xenctrl.h |  5 +++++
 tools/libxc/xc_domain.c       | 30 ++++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 84012fe..a3aeac3 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1294,6 +1294,11 @@ int xc_domain_set_memory_map(xc_interface *xch,
 int xc_get_machine_memory_map(xc_interface *xch,
                               struct e820entry entries[],
                               uint32_t max_entries);
+
+int xc_reserved_device_memory_map(xc_interface *xch,
+                                  uint32_t dom,
+                                  struct xen_reserved_device_memory entries[],
+                                  uint32_t *max_entries);
 #endif
 int xc_domain_set_time_offset(xc_interface *xch,
                               uint32_t domid,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 7fd43e9..09fd988 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -679,6 +679,36 @@ int xc_domain_set_memory_map(xc_interface *xch,
 
     return rc;
 }
+
+int xc_reserved_device_memory_map(xc_interface *xch,
+                                  uint32_t domid,
+                                  struct xen_reserved_device_memory entries[],
+                                  uint32_t *max_entries)
+{
+    int rc;
+    struct xen_reserved_device_memory_map xrdmmap = {
+        .domid = domid,
+        .nr_entries = *max_entries
+    };
+    DECLARE_HYPERCALL_BOUNCE(entries,
+                             sizeof(struct xen_reserved_device_memory) *
+                             *max_entries, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+    if ( xc_hypercall_bounce_pre(xch, entries) )
+        return -1;
+
+    set_xen_guest_handle(xrdmmap.buffer, entries);
+
+    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
+                      &xrdmmap, sizeof(xrdmmap));
+
+    xc_hypercall_bounce_post(xch, entries);
+
+    *max_entries = xrdmmap.nr_entries;
+
+    return rc ? rc : xrdmmap.nr_entries;
+}
+
 int xc_get_machine_memory_map(xc_interface *xch,
                               struct e820entry entries[],
                               uint32_t max_entries)
-- 
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 Dec 01 09:30:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNJY-0003oP-CO; Mon, 01 Dec 2014 09:30: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 1XvNJW-0003mS-7j
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:38 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	86/38-25727-D353C745; Mon, 01 Dec 2014 09:30:37 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!4
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 5020 invoked from network); 1 Dec 2014 09:30:36 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:36 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101123"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:33 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:24 +0800
Message-Id: <1417425875-9634-7-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 06/17] tools/libxc: check if modules space
	is overlapping with reserved device 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

In case of reserved device memory overlapping with ram, it also probably
overlap with modules space so we need to check these reserved device
memory as well.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 tools/libxc/xc_hvm_build_x86.c | 94 +++++++++++++++++++++++++++++++++++-------
 1 file changed, 79 insertions(+), 15 deletions(-)

diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index c81a25b..ddcf06d 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -54,9 +54,82 @@
 
 #define VGA_HOLE_SIZE (0x20)
 
+/*
+ * Check whether there exists mmio hole in the specified memory range.
+ * Returns 1 if exists, else returns 0.
+ */
+static int check_mmio_hole(uint64_t start, uint64_t memsize,
+                           uint64_t mmio_start, uint64_t mmio_size)
+{
+    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
+        return 0;
+    else
+        return 1;
+}
+
+/* Getting all reserved device memory map info. */
+static struct xen_reserved_device_memory
+*xc_get_reserved_device_memory_map(xc_interface *xch, unsigned int nr_entries,
+                                   uint32_t dom)
+{
+    struct xen_reserved_device_memory *xrdm = NULL;
+    int rc = xc_reserved_device_memory_map(xch, dom, xrdm, &nr_entries);
+
+    if ( rc < 0 )
+    {
+        if ( errno == ENOBUFS )
+        {
+            if ( (xrdm = malloc(nr_entries *
+                                sizeof(xen_reserved_device_memory_t))) == NULL )
+            {
+                PERROR("Could not allocate memory.");
+                return 0;
+            }
+            rc = xc_reserved_device_memory_map(xch, dom, xrdm, &nr_entries);
+            if ( rc )
+            {
+                PERROR("Could not get reserved device memory maps.");
+                free(xrdm);
+                return 0;
+            }
+        }
+        else
+            PERROR("Could not get reserved device memory maps.");
+    }
+
+    return xrdm;
+}
+
+static int xc_check_modules_space(xc_interface *xch, uint64_t *mstart_out,
+                                  uint64_t *mend_out, uint32_t dom)
+{
+    unsigned int i = 0, nr_entries = 0;
+    uint64_t rdm_start = 0, rdm_end = 0;
+    struct xen_reserved_device_memory *rdm_map =
+                        xc_get_reserved_device_memory_map(xch, nr_entries, dom);
+
+    for ( i = 0; i < nr_entries; i++ )
+    {
+        rdm_start = (uint64_t)rdm_map[i].start_pfn << XC_PAGE_SHIFT;
+        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << XC_PAGE_SHIFT);
+
+        /* Just use check_mmio_hole() to check modules ranges. */
+        if ( check_mmio_hole(rdm_start,
+                             rdm_end - rdm_start,
+                             *mstart_out, *mend_out) )
+            return -1;
+    }
+    
+    free(rdm_map);
+
+    return 0;
+}
+
 static int modules_init(struct xc_hvm_build_args *args,
                         uint64_t vend, struct elf_binary *elf,
-                        uint64_t *mstart_out, uint64_t *mend_out)
+                        uint64_t *mstart_out, uint64_t *mend_out,
+                        xc_interface *xch,
+                        uint32_t dom)
 {
 #define MODULE_ALIGN 1UL << 7
 #define MB_ALIGN     1UL << 20
@@ -80,6 +153,10 @@ static int modules_init(struct xc_hvm_build_args *args,
     if ( *mend_out > vend )    
         return -1;
 
+    /* Is it overlapping with reserved device memory? */
+    if ( xc_check_modules_space(xch, mstart_out, mend_out, dom) )
+        return -1;
+
     if ( args->acpi_module.length != 0 )
         args->acpi_module.guest_addr_out = *mstart_out;
     if ( args->smbios_module.length != 0 )
@@ -226,19 +303,6 @@ static int loadmodules(xc_interface *xch,
     return rc;
 }
 
-/*
- * Check whether there exists mmio hole in the specified memory range.
- * Returns 1 if exists, else returns 0.
- */
-static int check_mmio_hole(uint64_t start, uint64_t memsize,
-                           uint64_t mmio_start, uint64_t mmio_size)
-{
-    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
-        return 0;
-    else
-        return 1;
-}
-
 static int setup_guest(xc_interface *xch,
                        uint32_t dom, struct xc_hvm_build_args *args,
                        char *image, unsigned long image_size)
@@ -282,7 +346,7 @@ static int setup_guest(xc_interface *xch,
         goto error_out;
     }
 
-    if ( modules_init(args, v_end, &elf, &m_start, &m_end) != 0 )
+    if ( modules_init(args, v_end, &elf, &m_start, &m_end, xch, dom) != 0 )
     {
         ERROR("Insufficient space to load modules.");
         goto error_out;
-- 
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 Dec 01 09:30:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNJY-0003oP-CO; Mon, 01 Dec 2014 09:30: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 1XvNJW-0003mS-7j
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:38 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	86/38-25727-D353C745; Mon, 01 Dec 2014 09:30:37 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!4
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 5020 invoked from network); 1 Dec 2014 09:30:36 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:36 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101123"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:33 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:24 +0800
Message-Id: <1417425875-9634-7-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 06/17] tools/libxc: check if modules space
	is overlapping with reserved device 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

In case of reserved device memory overlapping with ram, it also probably
overlap with modules space so we need to check these reserved device
memory as well.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 tools/libxc/xc_hvm_build_x86.c | 94 +++++++++++++++++++++++++++++++++++-------
 1 file changed, 79 insertions(+), 15 deletions(-)

diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index c81a25b..ddcf06d 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -54,9 +54,82 @@
 
 #define VGA_HOLE_SIZE (0x20)
 
+/*
+ * Check whether there exists mmio hole in the specified memory range.
+ * Returns 1 if exists, else returns 0.
+ */
+static int check_mmio_hole(uint64_t start, uint64_t memsize,
+                           uint64_t mmio_start, uint64_t mmio_size)
+{
+    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
+        return 0;
+    else
+        return 1;
+}
+
+/* Getting all reserved device memory map info. */
+static struct xen_reserved_device_memory
+*xc_get_reserved_device_memory_map(xc_interface *xch, unsigned int nr_entries,
+                                   uint32_t dom)
+{
+    struct xen_reserved_device_memory *xrdm = NULL;
+    int rc = xc_reserved_device_memory_map(xch, dom, xrdm, &nr_entries);
+
+    if ( rc < 0 )
+    {
+        if ( errno == ENOBUFS )
+        {
+            if ( (xrdm = malloc(nr_entries *
+                                sizeof(xen_reserved_device_memory_t))) == NULL )
+            {
+                PERROR("Could not allocate memory.");
+                return 0;
+            }
+            rc = xc_reserved_device_memory_map(xch, dom, xrdm, &nr_entries);
+            if ( rc )
+            {
+                PERROR("Could not get reserved device memory maps.");
+                free(xrdm);
+                return 0;
+            }
+        }
+        else
+            PERROR("Could not get reserved device memory maps.");
+    }
+
+    return xrdm;
+}
+
+static int xc_check_modules_space(xc_interface *xch, uint64_t *mstart_out,
+                                  uint64_t *mend_out, uint32_t dom)
+{
+    unsigned int i = 0, nr_entries = 0;
+    uint64_t rdm_start = 0, rdm_end = 0;
+    struct xen_reserved_device_memory *rdm_map =
+                        xc_get_reserved_device_memory_map(xch, nr_entries, dom);
+
+    for ( i = 0; i < nr_entries; i++ )
+    {
+        rdm_start = (uint64_t)rdm_map[i].start_pfn << XC_PAGE_SHIFT;
+        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << XC_PAGE_SHIFT);
+
+        /* Just use check_mmio_hole() to check modules ranges. */
+        if ( check_mmio_hole(rdm_start,
+                             rdm_end - rdm_start,
+                             *mstart_out, *mend_out) )
+            return -1;
+    }
+    
+    free(rdm_map);
+
+    return 0;
+}
+
 static int modules_init(struct xc_hvm_build_args *args,
                         uint64_t vend, struct elf_binary *elf,
-                        uint64_t *mstart_out, uint64_t *mend_out)
+                        uint64_t *mstart_out, uint64_t *mend_out,
+                        xc_interface *xch,
+                        uint32_t dom)
 {
 #define MODULE_ALIGN 1UL << 7
 #define MB_ALIGN     1UL << 20
@@ -80,6 +153,10 @@ static int modules_init(struct xc_hvm_build_args *args,
     if ( *mend_out > vend )    
         return -1;
 
+    /* Is it overlapping with reserved device memory? */
+    if ( xc_check_modules_space(xch, mstart_out, mend_out, dom) )
+        return -1;
+
     if ( args->acpi_module.length != 0 )
         args->acpi_module.guest_addr_out = *mstart_out;
     if ( args->smbios_module.length != 0 )
@@ -226,19 +303,6 @@ static int loadmodules(xc_interface *xch,
     return rc;
 }
 
-/*
- * Check whether there exists mmio hole in the specified memory range.
- * Returns 1 if exists, else returns 0.
- */
-static int check_mmio_hole(uint64_t start, uint64_t memsize,
-                           uint64_t mmio_start, uint64_t mmio_size)
-{
-    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
-        return 0;
-    else
-        return 1;
-}
-
 static int setup_guest(xc_interface *xch,
                        uint32_t dom, struct xc_hvm_build_args *args,
                        char *image, unsigned long image_size)
@@ -282,7 +346,7 @@ static int setup_guest(xc_interface *xch,
         goto error_out;
     }
 
-    if ( modules_init(args, v_end, &elf, &m_start, &m_end) != 0 )
+    if ( modules_init(args, v_end, &elf, &m_start, &m_end, xch, dom) != 0 )
     {
         ERROR("Insufficient space to load modules.");
         goto error_out;
-- 
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 Dec 01 09:30:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJZ-0003q3-T3; Mon, 01 Dec 2014 09:30:41 +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 1XvNJY-0003oA-HT
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:40 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	4C/27-09284-F353C745; Mon, 01 Dec 2014 09:30:39 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!5
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 5417 invoked from network); 1 Dec 2014 09:30:39 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:39 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101158"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:36 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:25 +0800
Message-Id: <1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 07/17] 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need to use reserved device memory maps with multiple times, so
provide just one common function should be friend.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 tools/firmware/hvmloader/util.c | 59 +++++++++++++++++++++++++++++++++++++++++
 tools/firmware/hvmloader/util.h |  2 ++
 2 files changed, 61 insertions(+)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 80d822f..dd81fb6 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -22,11 +22,14 @@
 #include "config.h"
 #include "hypercall.h"
 #include "ctype.h"
+#include "errno.h"
 #include <stdint.h>
 #include <xen/xen.h>
 #include <xen/memory.h>
 #include <xen/sched.h>
 
+struct xen_reserved_device_memory *rdm_map;
+
 void wrmsr(uint32_t idx, uint64_t v)
 {
     asm volatile (
@@ -828,6 +831,62 @@ int hpet_exists(unsigned long hpet_base)
     return ((hpet_id >> 16) == 0x8086);
 }
 
+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 = {
+        .domid = DOMID_SELF,
+        .nr_entries = *max_entries
+    };
+
+    set_xen_guest_handle(xrdmmap.buffer, entries);
+
+    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map, &xrdmmap);
+    *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)
+{
+    static unsigned int nr_entries = 0;
+    int rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
+
+    if ( rc == -ENOBUFS )
+    {
+        rdm_map = mem_alloc(nr_entries*sizeof(struct xen_reserved_device_memory),
+                            0);
+        if ( rdm_map )
+        {
+            rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
+            if ( rc )
+            {
+                printf("Could not get reserved dev memory info on domain");
+                return 0;
+            }
+        }
+        else
+        {
+            printf("No space to get reserved dev memory maps!\n");
+            return 0;
+        }
+    }
+    else if ( rc )
+    {
+        printf("Could not get reserved dev memory info on domain");
+        return 0;
+    }
+
+    return nr_entries;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index a70e4aa..e4f1851 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -241,6 +241,8 @@ int build_e820_table(struct e820entry *e820,
                      unsigned int bios_image_base);
 void dump_e820_table(struct e820entry *e820, unsigned int nr);
 
+unsigned int hvm_get_reserved_device_memory_map(void);
+
 #ifndef NDEBUG
 void perform_tests(void);
 #else
-- 
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 Dec 01 09:30:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJZ-0003q3-T3; Mon, 01 Dec 2014 09:30:41 +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 1XvNJY-0003oA-HT
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:40 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	4C/27-09284-F353C745; Mon, 01 Dec 2014 09:30:39 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!5
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 5417 invoked from network); 1 Dec 2014 09:30:39 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:39 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101158"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:36 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:25 +0800
Message-Id: <1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 07/17] 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need to use reserved device memory maps with multiple times, so
provide just one common function should be friend.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 tools/firmware/hvmloader/util.c | 59 +++++++++++++++++++++++++++++++++++++++++
 tools/firmware/hvmloader/util.h |  2 ++
 2 files changed, 61 insertions(+)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 80d822f..dd81fb6 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -22,11 +22,14 @@
 #include "config.h"
 #include "hypercall.h"
 #include "ctype.h"
+#include "errno.h"
 #include <stdint.h>
 #include <xen/xen.h>
 #include <xen/memory.h>
 #include <xen/sched.h>
 
+struct xen_reserved_device_memory *rdm_map;
+
 void wrmsr(uint32_t idx, uint64_t v)
 {
     asm volatile (
@@ -828,6 +831,62 @@ int hpet_exists(unsigned long hpet_base)
     return ((hpet_id >> 16) == 0x8086);
 }
 
+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 = {
+        .domid = DOMID_SELF,
+        .nr_entries = *max_entries
+    };
+
+    set_xen_guest_handle(xrdmmap.buffer, entries);
+
+    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map, &xrdmmap);
+    *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)
+{
+    static unsigned int nr_entries = 0;
+    int rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
+
+    if ( rc == -ENOBUFS )
+    {
+        rdm_map = mem_alloc(nr_entries*sizeof(struct xen_reserved_device_memory),
+                            0);
+        if ( rdm_map )
+        {
+            rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
+            if ( rc )
+            {
+                printf("Could not get reserved dev memory info on domain");
+                return 0;
+            }
+        }
+        else
+        {
+            printf("No space to get reserved dev memory maps!\n");
+            return 0;
+        }
+    }
+    else if ( rc )
+    {
+        printf("Could not get reserved dev memory info on domain");
+        return 0;
+    }
+
+    return nr_entries;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index a70e4aa..e4f1851 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -241,6 +241,8 @@ int build_e820_table(struct e820entry *e820,
                      unsigned int bios_image_base);
 void dump_e820_table(struct e820entry *e820, unsigned int nr);
 
+unsigned int hvm_get_reserved_device_memory_map(void);
+
 #ifndef NDEBUG
 void perform_tests(void);
 #else
-- 
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 Dec 01 09:30:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJd-0003tV-Ej; Mon, 01 Dec 2014 09:30:45 +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 1XvNJb-0003rk-RC
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:44 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	A5/57-09284-3453C745; Mon, 01 Dec 2014 09:30:43 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!6
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 5786 invoked from network); 1 Dec 2014 09:30:42 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:42 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101176"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:38 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:26 +0800
Message-Id: <1417425875-9634-9-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 08/17] hvmloader/mmio: reconcile guest mmio
	with reserved device 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

We need to make sure all mmio allocation don't overlap
any rdm, reserved device memory. Here we just skip
all reserved device memory range in mmio space.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 tools/firmware/hvmloader/pci.c  | 54 ++++++++++++++++++++++++++++++++++++++++-
 tools/firmware/hvmloader/util.c |  9 +++++++
 tools/firmware/hvmloader/util.h |  2 ++
 3 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 4e8d803..fc22ab3 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -38,6 +38,30 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+static unsigned int need_skip_rmrr;
+extern struct xen_reserved_device_memory *rdm_map;
+
+static unsigned int
+check_reserved_device_memory_map(uint64_t mmio_base, uint64_t mmio_max)
+{
+    uint32_t i;
+    uint64_t rdm_start, rdm_end;
+    unsigned int nr_rdm_entries = hvm_get_reserved_device_memory_map();
+
+    for ( i = 0; i < nr_rdm_entries; i++ )
+    {
+        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
+        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << PAGE_SHIFT);
+        if ( check_rdm_hole_conflict(mmio_base, mmio_max - mmio_base,
+                                     rdm_start, rdm_end - rdm_start) )
+        {
+            need_skip_rmrr++;
+        }
+    }
+
+    return nr_rdm_entries;
+}
+
 void pci_setup(void)
 {
     uint8_t is_64bar, using_64bar, bar64_relocate = 0;
@@ -59,8 +83,10 @@ void pci_setup(void)
         uint32_t bar_reg;
         uint64_t bar_sz;
     } *bars = (struct bars *)scratch_start;
-    unsigned int i, nr_bars = 0;
+    unsigned int i, j, nr_bars = 0;
     uint64_t mmio_hole_size = 0;
+    unsigned int nr_rdm_entries;
+    uint64_t rdm_start, rdm_end;
 
     const char *s;
     /*
@@ -338,6 +364,14 @@ void pci_setup(void)
     io_resource.base = 0xc000;
     io_resource.max = 0x10000;
 
+    /* Check low mmio range. */
+    nr_rdm_entries = check_reserved_device_memory_map(mem_resource.base,
+                                                      mem_resource.max);
+    /* Check high mmio range. */
+    if ( nr_rdm_entries )
+        nr_rdm_entries = check_reserved_device_memory_map(high_mem_resource.base,
+                                                          high_mem_resource.max);
+
     /* Assign iomem and ioport resources in descending order of size. */
     for ( i = 0; i < nr_bars; i++ )
     {
@@ -393,8 +427,26 @@ void pci_setup(void)
         }
 
         base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
+ reallocate_mmio:
         bar_data |= (uint32_t)base;
         bar_data_upper = (uint32_t)(base >> 32);
+
+        if ( need_skip_rmrr )
+        {
+            for ( j = 0; j < nr_rdm_entries; j++ )
+            {
+                rdm_start = (uint64_t)rdm_map[j].start_pfn << PAGE_SHIFT;
+                rdm_end = rdm_start + ((uint64_t)rdm_map[j].nr_pages << PAGE_SHIFT);
+                if ( check_rdm_hole_conflict(base, bar_sz,
+                                             rdm_start, rdm_end - rdm_start) )
+                {
+                    base = (rdm_end  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
+                    need_skip_rmrr--;
+                    goto reallocate_mmio;
+                }
+            }
+        }
+
         base += bar_sz;
 
         if ( (base < resource->base) || (base > resource->max) )
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index dd81fb6..8767897 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -887,6 +887,15 @@ unsigned int hvm_get_reserved_device_memory_map(void)
     return nr_entries;
 }
 
+int check_rdm_hole_conflict(uint64_t start, uint64_t size,
+                            uint64_t rdm_start, uint64_t rdm_size)
+{
+    if ( start + size <= rdm_start || start >= rdm_start + rdm_size )
+        return 0;
+    else
+        return 1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index e4f1851..9b02f95 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -242,6 +242,8 @@ int build_e820_table(struct e820entry *e820,
 void dump_e820_table(struct e820entry *e820, unsigned int nr);
 
 unsigned int hvm_get_reserved_device_memory_map(void);
+int check_rdm_hole_conflict(uint64_t start, uint64_t size,
+                            uint64_t rdm_start, uint64_t rdm_size);
 
 #ifndef NDEBUG
 void perform_tests(void);
-- 
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 Dec 01 09:30:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJd-0003tV-Ej; Mon, 01 Dec 2014 09:30:45 +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 1XvNJb-0003rk-RC
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:44 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	A5/57-09284-3453C745; Mon, 01 Dec 2014 09:30:43 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!6
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 5786 invoked from network); 1 Dec 2014 09:30:42 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:42 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101176"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:38 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:26 +0800
Message-Id: <1417425875-9634-9-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 08/17] hvmloader/mmio: reconcile guest mmio
	with reserved device 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

We need to make sure all mmio allocation don't overlap
any rdm, reserved device memory. Here we just skip
all reserved device memory range in mmio space.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 tools/firmware/hvmloader/pci.c  | 54 ++++++++++++++++++++++++++++++++++++++++-
 tools/firmware/hvmloader/util.c |  9 +++++++
 tools/firmware/hvmloader/util.h |  2 ++
 3 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 4e8d803..fc22ab3 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -38,6 +38,30 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+static unsigned int need_skip_rmrr;
+extern struct xen_reserved_device_memory *rdm_map;
+
+static unsigned int
+check_reserved_device_memory_map(uint64_t mmio_base, uint64_t mmio_max)
+{
+    uint32_t i;
+    uint64_t rdm_start, rdm_end;
+    unsigned int nr_rdm_entries = hvm_get_reserved_device_memory_map();
+
+    for ( i = 0; i < nr_rdm_entries; i++ )
+    {
+        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
+        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << PAGE_SHIFT);
+        if ( check_rdm_hole_conflict(mmio_base, mmio_max - mmio_base,
+                                     rdm_start, rdm_end - rdm_start) )
+        {
+            need_skip_rmrr++;
+        }
+    }
+
+    return nr_rdm_entries;
+}
+
 void pci_setup(void)
 {
     uint8_t is_64bar, using_64bar, bar64_relocate = 0;
@@ -59,8 +83,10 @@ void pci_setup(void)
         uint32_t bar_reg;
         uint64_t bar_sz;
     } *bars = (struct bars *)scratch_start;
-    unsigned int i, nr_bars = 0;
+    unsigned int i, j, nr_bars = 0;
     uint64_t mmio_hole_size = 0;
+    unsigned int nr_rdm_entries;
+    uint64_t rdm_start, rdm_end;
 
     const char *s;
     /*
@@ -338,6 +364,14 @@ void pci_setup(void)
     io_resource.base = 0xc000;
     io_resource.max = 0x10000;
 
+    /* Check low mmio range. */
+    nr_rdm_entries = check_reserved_device_memory_map(mem_resource.base,
+                                                      mem_resource.max);
+    /* Check high mmio range. */
+    if ( nr_rdm_entries )
+        nr_rdm_entries = check_reserved_device_memory_map(high_mem_resource.base,
+                                                          high_mem_resource.max);
+
     /* Assign iomem and ioport resources in descending order of size. */
     for ( i = 0; i < nr_bars; i++ )
     {
@@ -393,8 +427,26 @@ void pci_setup(void)
         }
 
         base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
+ reallocate_mmio:
         bar_data |= (uint32_t)base;
         bar_data_upper = (uint32_t)(base >> 32);
+
+        if ( need_skip_rmrr )
+        {
+            for ( j = 0; j < nr_rdm_entries; j++ )
+            {
+                rdm_start = (uint64_t)rdm_map[j].start_pfn << PAGE_SHIFT;
+                rdm_end = rdm_start + ((uint64_t)rdm_map[j].nr_pages << PAGE_SHIFT);
+                if ( check_rdm_hole_conflict(base, bar_sz,
+                                             rdm_start, rdm_end - rdm_start) )
+                {
+                    base = (rdm_end  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
+                    need_skip_rmrr--;
+                    goto reallocate_mmio;
+                }
+            }
+        }
+
         base += bar_sz;
 
         if ( (base < resource->base) || (base > resource->max) )
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index dd81fb6..8767897 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -887,6 +887,15 @@ unsigned int hvm_get_reserved_device_memory_map(void)
     return nr_entries;
 }
 
+int check_rdm_hole_conflict(uint64_t start, uint64_t size,
+                            uint64_t rdm_start, uint64_t rdm_size)
+{
+    if ( start + size <= rdm_start || start >= rdm_start + rdm_size )
+        return 0;
+    else
+        return 1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index e4f1851..9b02f95 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -242,6 +242,8 @@ int build_e820_table(struct e820entry *e820,
 void dump_e820_table(struct e820entry *e820, unsigned int nr);
 
 unsigned int hvm_get_reserved_device_memory_map(void);
+int check_rdm_hole_conflict(uint64_t start, uint64_t size,
+                            uint64_t rdm_start, uint64_t rdm_size);
 
 #ifndef NDEBUG
 void perform_tests(void);
-- 
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 Dec 01 09:30:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJg-0003wp-4X; Mon, 01 Dec 2014 09:30:48 +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 1XvNJe-0003uj-Mn
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:46 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	01/87-09284-6453C745; Mon, 01 Dec 2014 09:30:46 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!7
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 6166 invoked from network); 1 Dec 2014 09:30:44 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:44 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101199"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:41 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:27 +0800
Message-Id: <1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 09/17] 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>
MIME-Version: 1.0
Content-Type: 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 check to reserve all reserved device memory maps in e820
to avoid any potential guest memory conflict.

Currently, if we can't insert RDM entries directly, we may need to handle
several ranges as follows:
a. Fixed Ranges --> BUG()
 lowmem_reserved_base-0xA0000: reserved by BIOS implementation,
 BIOS region,
 RESERVED_MEMBASE ~ 0x100000000,
b. RAM or RAM:Hole -> Try to reserve

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 tools/firmware/hvmloader/e820.c | 168 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 168 insertions(+)

diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 2e05e93..ef87e41 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -22,6 +22,7 @@
 
 #include "config.h"
 #include "util.h"
+#include <xen/memory.h>
 
 void dump_e820_table(struct e820entry *e820, unsigned int nr)
 {
@@ -68,12 +69,173 @@ void dump_e820_table(struct e820entry *e820, unsigned int nr)
     }
 }
 
+extern struct xen_reserved_device_memory *rdm_map;
+static unsigned int construct_rdm_e820_maps(unsigned int next_e820_entry_index,
+                                            uint32_t nr_map,
+                                            struct xen_reserved_device_memory *map,
+                                            struct e820entry *e820,
+                                            unsigned int lowmem_reserved_base,
+                                            unsigned int bios_image_base)
+{
+    unsigned int i, j, sum_nr;
+    uint64_t start, end, next_start, rdm_start, rdm_end;
+    uint32_t type;
+    int err = 0;
+
+    for ( i = 0; i < nr_map; i++ )
+    {
+        rdm_start = (uint64_t)map[i].start_pfn << PAGE_SHIFT;
+        rdm_end = rdm_start + ((uint64_t)map[i].nr_pages << PAGE_SHIFT);
+
+        for ( j = 0; j < next_e820_entry_index - 1; j++ )
+        {
+            sum_nr = next_e820_entry_index + nr_map;
+            start = e820[j].addr;
+            end = e820[j].addr + e820[j].size;
+            type = e820[j].type;
+            next_start = e820[j+1].addr;
+
+            if ( rdm_start >= start && rdm_start <= end )
+            {
+                /*
+                 * lowmem_reserved_base-0xA0000: reserved by BIOS
+                 * implementation.
+                 * Or BIOS region.
+                 */
+                if ( (lowmem_reserved_base < 0xA0000 &&
+                        start == lowmem_reserved_base) ||
+                     start == bios_image_base )
+                {
+                    err = -1;
+                    break;
+                }
+            }
+
+            /* Just amid those remaining e820 entries. */
+            if ( (rdm_start > end) && (rdm_end < next_start) )
+            {
+                memmove(&e820[j+2], &e820[j+1],
+                        (sum_nr - j - 1) * sizeof(struct e820entry));
+
+                /* Then fill RMRR into that entry. */
+                e820[j+1].addr = rdm_start;
+                e820[j+1].size = rdm_end - rdm_start;
+                e820[j+1].type = E820_RESERVED;
+                next_e820_entry_index++;
+                continue;
+            }
+
+            /* Already at the end. */
+            if ( (rdm_start > end) && !next_start )
+            {
+                e820[next_e820_entry_index].addr = rdm_start;
+                e820[next_e820_entry_index].size = rdm_end - rdm_start;
+                e820[next_e820_entry_index].type = E820_RESERVED;
+                next_e820_entry_index++;
+                continue;
+            }
+
+            if ( type == E820_RAM )
+            {
+                /* If coincide with one RAM range. */
+                if ( rdm_start == start && rdm_end == end)
+                {
+                    e820[j].type = E820_RESERVED;
+                    continue;
+                }
+
+                /* If we're just aligned with start of one RAM range. */
+                if ( rdm_start == start && rdm_end < end )
+                {
+                    memmove(&e820[j+1], &e820[j],
+                            (sum_nr - j) * sizeof(struct e820entry));
+
+                    e820[j+1].addr = rdm_end;
+                    e820[j+1].size = e820[j].addr + e820[j].size - rdm_end;
+                    e820[j+1].type = E820_RAM;
+                    next_e820_entry_index++;
+
+                    e820[j].addr = rdm_start;
+                    e820[j].size = rdm_end - rdm_start;
+                    e820[j].type = E820_RESERVED;
+                    continue;
+                }
+
+                /* If we're just aligned with end of one RAM range. */
+                if ( rdm_start > start && rdm_end == end )
+                {
+                    memmove(&e820[j+1], &e820[j],
+                            (sum_nr - j) * sizeof(struct e820entry));
+
+                    e820[j].size = rdm_start - e820[j].addr;
+                    e820[j].type = E820_RAM;
+
+                    e820[j+1].addr = rdm_start;
+                    e820[j+1].size = rdm_end - rdm_start;
+                    e820[j+1].type = E820_RESERVED;
+                    next_e820_entry_index++;
+                    continue;
+                }
+
+                /* If we're just in of one RAM range */
+                if ( rdm_start > start && rdm_end < end )
+                {
+                    memmove(&e820[j+2], &e820[j],
+                            (sum_nr - j) * sizeof(struct e820entry));
+
+                    e820[j+2].addr = rdm_end;
+                    e820[j+2].size = e820[j].addr + e820[j].size - rdm_end;
+                    e820[j+2].type = E820_RAM;
+                    next_e820_entry_index++;
+
+                    e820[j+1].addr = rdm_start;
+                    e820[j+1].size = rdm_end - rdm_start;
+                    e820[j+1].type = E820_RESERVED;
+                    next_e820_entry_index++;
+
+                    e820[j].size = rdm_start - e820[j].addr;
+                    e820[j].type = E820_RAM;
+                    continue;
+                }
+
+                /* If we're going last RAM:Hole range */
+                if ( end < next_start && rdm_start > start &&
+                     rdm_end < next_start )
+                {
+                    memmove(&e820[j+1], &e820[j],
+                            (sum_nr - j) * sizeof(struct e820entry));
+
+                    e820[j].size = rdm_start - e820[j].addr;
+                    e820[j].type = E820_RAM;
+
+                    e820[j+1].addr = rdm_start;
+                    e820[j+1].size = rdm_end - rdm_start;
+                    e820[j+1].type = E820_RESERVED;
+                    next_e820_entry_index++;
+                    continue;
+                }
+            }
+        }
+    }
+
+    /* These overlap may issue guest can't work well. */
+    if ( err )
+    {
+        printf("Guest can't work with some reserved device memory overlap!\n");
+        BUG();
+    }
+
+    /* Fine to construct RDM mappings into e820. */
+    return next_e820_entry_index;
+}
+
 /* Create an E820 table based on memory parameters provided in hvm_info. */
 int build_e820_table(struct e820entry *e820,
                      unsigned int lowmem_reserved_base,
                      unsigned int bios_image_base)
 {
     unsigned int nr = 0;
+    unsigned int nr_entries = 0;
 
     if ( !lowmem_reserved_base )
             lowmem_reserved_base = 0xA0000;
@@ -169,6 +331,12 @@ int build_e820_table(struct e820entry *e820,
         nr++;
     }
 
+    nr_entries = hvm_get_reserved_device_memory_map();
+    if ( nr_entries )
+        nr = construct_rdm_e820_maps(nr, nr_entries, rdm_map, e820,
+                                     lowmem_reserved_base,
+                                     bios_image_base);
+
     return nr;
 }
 
-- 
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 Dec 01 09:30:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJg-0003wp-4X; Mon, 01 Dec 2014 09:30:48 +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 1XvNJe-0003uj-Mn
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:46 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	01/87-09284-6453C745; Mon, 01 Dec 2014 09:30:46 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!7
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 6166 invoked from network); 1 Dec 2014 09:30:44 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:44 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101199"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:41 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:27 +0800
Message-Id: <1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 09/17] 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>
MIME-Version: 1.0
Content-Type: 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 check to reserve all reserved device memory maps in e820
to avoid any potential guest memory conflict.

Currently, if we can't insert RDM entries directly, we may need to handle
several ranges as follows:
a. Fixed Ranges --> BUG()
 lowmem_reserved_base-0xA0000: reserved by BIOS implementation,
 BIOS region,
 RESERVED_MEMBASE ~ 0x100000000,
b. RAM or RAM:Hole -> Try to reserve

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 tools/firmware/hvmloader/e820.c | 168 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 168 insertions(+)

diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 2e05e93..ef87e41 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -22,6 +22,7 @@
 
 #include "config.h"
 #include "util.h"
+#include <xen/memory.h>
 
 void dump_e820_table(struct e820entry *e820, unsigned int nr)
 {
@@ -68,12 +69,173 @@ void dump_e820_table(struct e820entry *e820, unsigned int nr)
     }
 }
 
+extern struct xen_reserved_device_memory *rdm_map;
+static unsigned int construct_rdm_e820_maps(unsigned int next_e820_entry_index,
+                                            uint32_t nr_map,
+                                            struct xen_reserved_device_memory *map,
+                                            struct e820entry *e820,
+                                            unsigned int lowmem_reserved_base,
+                                            unsigned int bios_image_base)
+{
+    unsigned int i, j, sum_nr;
+    uint64_t start, end, next_start, rdm_start, rdm_end;
+    uint32_t type;
+    int err = 0;
+
+    for ( i = 0; i < nr_map; i++ )
+    {
+        rdm_start = (uint64_t)map[i].start_pfn << PAGE_SHIFT;
+        rdm_end = rdm_start + ((uint64_t)map[i].nr_pages << PAGE_SHIFT);
+
+        for ( j = 0; j < next_e820_entry_index - 1; j++ )
+        {
+            sum_nr = next_e820_entry_index + nr_map;
+            start = e820[j].addr;
+            end = e820[j].addr + e820[j].size;
+            type = e820[j].type;
+            next_start = e820[j+1].addr;
+
+            if ( rdm_start >= start && rdm_start <= end )
+            {
+                /*
+                 * lowmem_reserved_base-0xA0000: reserved by BIOS
+                 * implementation.
+                 * Or BIOS region.
+                 */
+                if ( (lowmem_reserved_base < 0xA0000 &&
+                        start == lowmem_reserved_base) ||
+                     start == bios_image_base )
+                {
+                    err = -1;
+                    break;
+                }
+            }
+
+            /* Just amid those remaining e820 entries. */
+            if ( (rdm_start > end) && (rdm_end < next_start) )
+            {
+                memmove(&e820[j+2], &e820[j+1],
+                        (sum_nr - j - 1) * sizeof(struct e820entry));
+
+                /* Then fill RMRR into that entry. */
+                e820[j+1].addr = rdm_start;
+                e820[j+1].size = rdm_end - rdm_start;
+                e820[j+1].type = E820_RESERVED;
+                next_e820_entry_index++;
+                continue;
+            }
+
+            /* Already at the end. */
+            if ( (rdm_start > end) && !next_start )
+            {
+                e820[next_e820_entry_index].addr = rdm_start;
+                e820[next_e820_entry_index].size = rdm_end - rdm_start;
+                e820[next_e820_entry_index].type = E820_RESERVED;
+                next_e820_entry_index++;
+                continue;
+            }
+
+            if ( type == E820_RAM )
+            {
+                /* If coincide with one RAM range. */
+                if ( rdm_start == start && rdm_end == end)
+                {
+                    e820[j].type = E820_RESERVED;
+                    continue;
+                }
+
+                /* If we're just aligned with start of one RAM range. */
+                if ( rdm_start == start && rdm_end < end )
+                {
+                    memmove(&e820[j+1], &e820[j],
+                            (sum_nr - j) * sizeof(struct e820entry));
+
+                    e820[j+1].addr = rdm_end;
+                    e820[j+1].size = e820[j].addr + e820[j].size - rdm_end;
+                    e820[j+1].type = E820_RAM;
+                    next_e820_entry_index++;
+
+                    e820[j].addr = rdm_start;
+                    e820[j].size = rdm_end - rdm_start;
+                    e820[j].type = E820_RESERVED;
+                    continue;
+                }
+
+                /* If we're just aligned with end of one RAM range. */
+                if ( rdm_start > start && rdm_end == end )
+                {
+                    memmove(&e820[j+1], &e820[j],
+                            (sum_nr - j) * sizeof(struct e820entry));
+
+                    e820[j].size = rdm_start - e820[j].addr;
+                    e820[j].type = E820_RAM;
+
+                    e820[j+1].addr = rdm_start;
+                    e820[j+1].size = rdm_end - rdm_start;
+                    e820[j+1].type = E820_RESERVED;
+                    next_e820_entry_index++;
+                    continue;
+                }
+
+                /* If we're just in of one RAM range */
+                if ( rdm_start > start && rdm_end < end )
+                {
+                    memmove(&e820[j+2], &e820[j],
+                            (sum_nr - j) * sizeof(struct e820entry));
+
+                    e820[j+2].addr = rdm_end;
+                    e820[j+2].size = e820[j].addr + e820[j].size - rdm_end;
+                    e820[j+2].type = E820_RAM;
+                    next_e820_entry_index++;
+
+                    e820[j+1].addr = rdm_start;
+                    e820[j+1].size = rdm_end - rdm_start;
+                    e820[j+1].type = E820_RESERVED;
+                    next_e820_entry_index++;
+
+                    e820[j].size = rdm_start - e820[j].addr;
+                    e820[j].type = E820_RAM;
+                    continue;
+                }
+
+                /* If we're going last RAM:Hole range */
+                if ( end < next_start && rdm_start > start &&
+                     rdm_end < next_start )
+                {
+                    memmove(&e820[j+1], &e820[j],
+                            (sum_nr - j) * sizeof(struct e820entry));
+
+                    e820[j].size = rdm_start - e820[j].addr;
+                    e820[j].type = E820_RAM;
+
+                    e820[j+1].addr = rdm_start;
+                    e820[j+1].size = rdm_end - rdm_start;
+                    e820[j+1].type = E820_RESERVED;
+                    next_e820_entry_index++;
+                    continue;
+                }
+            }
+        }
+    }
+
+    /* These overlap may issue guest can't work well. */
+    if ( err )
+    {
+        printf("Guest can't work with some reserved device memory overlap!\n");
+        BUG();
+    }
+
+    /* Fine to construct RDM mappings into e820. */
+    return next_e820_entry_index;
+}
+
 /* Create an E820 table based on memory parameters provided in hvm_info. */
 int build_e820_table(struct e820entry *e820,
                      unsigned int lowmem_reserved_base,
                      unsigned int bios_image_base)
 {
     unsigned int nr = 0;
+    unsigned int nr_entries = 0;
 
     if ( !lowmem_reserved_base )
             lowmem_reserved_base = 0xA0000;
@@ -169,6 +331,12 @@ int build_e820_table(struct e820entry *e820,
         nr++;
     }
 
+    nr_entries = hvm_get_reserved_device_memory_map();
+    if ( nr_entries )
+        nr = construct_rdm_e820_maps(nr, nr_entries, rdm_map, e820,
+                                     lowmem_reserved_base,
+                                     bios_image_base);
+
     return nr;
 }
 
-- 
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 Dec 01 09:30:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJi-0003zT-KF; Mon, 01 Dec 2014 09:30:50 +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 1XvNJg-0003wx-Oi
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:48 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	45/9F-17694-8453C745; Mon, 01 Dec 2014 09:30:48 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!8
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 6555 invoked from network); 1 Dec 2014 09:30:47 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:47 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101219"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:44 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:28 +0800
Message-Id: <1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip any
	overlap with reserved device 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

In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
to allocate some memory to use in runtime cycle, so we alsoe need to
make sure all reserved device memory don't overlap such a region.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 tools/firmware/hvmloader/util.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 8767897..f3723c7 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -416,9 +416,29 @@ static uint32_t alloc_down = RESERVED_MEMORY_DYNAMIC_END;
 
 xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
 {
+    unsigned int i, num = hvm_get_reserved_device_memory_map();
+    uint64_t rdm_start, rdm_end;
+    uint32_t alloc_start, alloc_end;
+
     alloc_down -= nr_mfns << PAGE_SHIFT;
+    alloc_start = alloc_down;
+    alloc_end = alloc_start + (nr_mfns << PAGE_SHIFT);
+    for ( i = 0; i < num; i++ )
+    {
+        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
+        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << PAGE_SHIFT);
+        if ( check_rdm_hole_conflict((uint64_t)alloc_start,
+                                     (uint64_t)alloc_end,
+                                     rdm_start, rdm_end - rdm_start) )
+        {
+            alloc_end = rdm_start;
+            alloc_start = alloc_end - (nr_mfns << PAGE_SHIFT);
+            BUG_ON(alloc_up >= alloc_start);
+        }
+    }
+
     BUG_ON(alloc_up >= alloc_down);
-    return alloc_down >> PAGE_SHIFT;
+    return alloc_start >> PAGE_SHIFT;
 }
 
 void *mem_alloc(uint32_t size, uint32_t align)
-- 
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 Dec 01 09:30:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJi-0003zT-KF; Mon, 01 Dec 2014 09:30:50 +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 1XvNJg-0003wx-Oi
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:48 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	45/9F-17694-8453C745; Mon, 01 Dec 2014 09:30:48 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!8
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 6555 invoked from network); 1 Dec 2014 09:30:47 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:47 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101219"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:44 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:28 +0800
Message-Id: <1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip any
	overlap with reserved device 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

In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
to allocate some memory to use in runtime cycle, so we alsoe need to
make sure all reserved device memory don't overlap such a region.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 tools/firmware/hvmloader/util.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 8767897..f3723c7 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -416,9 +416,29 @@ static uint32_t alloc_down = RESERVED_MEMORY_DYNAMIC_END;
 
 xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
 {
+    unsigned int i, num = hvm_get_reserved_device_memory_map();
+    uint64_t rdm_start, rdm_end;
+    uint32_t alloc_start, alloc_end;
+
     alloc_down -= nr_mfns << PAGE_SHIFT;
+    alloc_start = alloc_down;
+    alloc_end = alloc_start + (nr_mfns << PAGE_SHIFT);
+    for ( i = 0; i < num; i++ )
+    {
+        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
+        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << PAGE_SHIFT);
+        if ( check_rdm_hole_conflict((uint64_t)alloc_start,
+                                     (uint64_t)alloc_end,
+                                     rdm_start, rdm_end - rdm_start) )
+        {
+            alloc_end = rdm_start;
+            alloc_start = alloc_end - (nr_mfns << PAGE_SHIFT);
+            BUG_ON(alloc_up >= alloc_start);
+        }
+    }
+
     BUG_ON(alloc_up >= alloc_down);
-    return alloc_down >> PAGE_SHIFT;
+    return alloc_start >> PAGE_SHIFT;
 }
 
 void *mem_alloc(uint32_t size, uint32_t align)
-- 
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 Dec 01 09:30:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJl-00042i-1o; Mon, 01 Dec 2014 09:30:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XvNJj-00040k-W6
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:52 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	02/CB-17958-B453C745; Mon, 01 Dec 2014 09:30:51 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!9
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 6880 invoked from network); 1 Dec 2014 09:30:50 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:50 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101242"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:47 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:29 +0800
Message-Id: <1417425875-9634-12-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 11/17] xen/x86/p2m: reject populating 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>
MIME-Version: 1.0
Content-Type: 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 reject to populate reserved device memory mapping, and
then make sure all reserved device memory can't be accessed by any
!iommu approach.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/arch/x86/mm/p2m.c     | 59 +++++++++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h |  9 ++++++++
 2 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index efa49dd..607ecd0 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -556,6 +556,40 @@ guest_physmap_remove_page(struct domain *d, unsigned long gfn,
     gfn_unlock(p2m, gfn, page_order);
 }
 
+/* Check if we are accessing rdm. */
+int p2m_check_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
+                                     u32 id, void *ctxt)
+{
+    xen_pfn_t end = start + nr;
+    unsigned int i;
+    u32 sbdf;
+    struct p2m_get_reserved_device_memory *pgrdm = ctxt;
+    struct domain *d = pgrdm->domain;
+
+    if ( d->arch.hvm_domain.pci_force )
+    {
+        if ( pgrdm->gfn >= start && pgrdm->gfn < end )
+            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 ( pgrdm->gfn >= start && pgrdm->gfn < end )
+                    return 1;
+            }
+        }
+    }
+
+    return 0;
+}
+
 int
 guest_physmap_add_entry(struct domain *d, unsigned long gfn,
                         unsigned long mfn, unsigned int page_order, 
@@ -568,6 +602,7 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
     mfn_t omfn;
     int pod_count = 0;
     int rc = 0;
+    struct p2m_get_reserved_device_memory pgrdm;
 
     if ( !paging_mode_translate(d) )
     {
@@ -686,8 +721,28 @@ 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);
+        pgrdm.gfn = gfn;
+        pgrdm.domain = d;
+        if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )
+        {
+            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                                  &pgrdm);
+            /* We always avoid populating reserved device memory. */
+            if ( rc == 1 )
+            {
+                rc = -EBUSY;
+                goto out;
+            }
+            else if ( rc < 0 )
+            {
+                printk(XENLOG_G_WARNING
+                       "Can't check reserved device memory for Dom%d.\n",
+                       d->domain_id);
+                goto out;
+            }
+        }
+
+        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, p2m->default_access);
         if ( rc )
             goto out; /* Failed to update p2m, bail without updating m2p. */
 
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 5f7fe71..99f7fb7 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -709,6 +709,15 @@ static inline unsigned int p2m_get_iommu_flags(p2m_type_t p2mt)
     return flags;
 }
 
+struct p2m_get_reserved_device_memory {
+    unsigned long gfn;
+    struct domain *domain;
+};
+
+/* Check if we are accessing rdm. */
+extern int p2m_check_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
+                                            u32 id, void *ctxt);
+
 #endif /* _XEN_P2M_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 Dec 01 09:30:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJl-00042i-1o; Mon, 01 Dec 2014 09:30:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tiejun.chen@intel.com>) id 1XvNJj-00040k-W6
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:52 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	02/CB-17958-B453C745; Mon, 01 Dec 2014 09:30:51 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!9
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 6880 invoked from network); 1 Dec 2014 09:30:50 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:50 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101242"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:47 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:29 +0800
Message-Id: <1417425875-9634-12-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 11/17] xen/x86/p2m: reject populating 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>
MIME-Version: 1.0
Content-Type: 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 reject to populate reserved device memory mapping, and
then make sure all reserved device memory can't be accessed by any
!iommu approach.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/arch/x86/mm/p2m.c     | 59 +++++++++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h |  9 ++++++++
 2 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index efa49dd..607ecd0 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -556,6 +556,40 @@ guest_physmap_remove_page(struct domain *d, unsigned long gfn,
     gfn_unlock(p2m, gfn, page_order);
 }
 
+/* Check if we are accessing rdm. */
+int p2m_check_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
+                                     u32 id, void *ctxt)
+{
+    xen_pfn_t end = start + nr;
+    unsigned int i;
+    u32 sbdf;
+    struct p2m_get_reserved_device_memory *pgrdm = ctxt;
+    struct domain *d = pgrdm->domain;
+
+    if ( d->arch.hvm_domain.pci_force )
+    {
+        if ( pgrdm->gfn >= start && pgrdm->gfn < end )
+            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 ( pgrdm->gfn >= start && pgrdm->gfn < end )
+                    return 1;
+            }
+        }
+    }
+
+    return 0;
+}
+
 int
 guest_physmap_add_entry(struct domain *d, unsigned long gfn,
                         unsigned long mfn, unsigned int page_order, 
@@ -568,6 +602,7 @@ guest_physmap_add_entry(struct domain *d, unsigned long gfn,
     mfn_t omfn;
     int pod_count = 0;
     int rc = 0;
+    struct p2m_get_reserved_device_memory pgrdm;
 
     if ( !paging_mode_translate(d) )
     {
@@ -686,8 +721,28 @@ 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);
+        pgrdm.gfn = gfn;
+        pgrdm.domain = d;
+        if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )
+        {
+            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                                  &pgrdm);
+            /* We always avoid populating reserved device memory. */
+            if ( rc == 1 )
+            {
+                rc = -EBUSY;
+                goto out;
+            }
+            else if ( rc < 0 )
+            {
+                printk(XENLOG_G_WARNING
+                       "Can't check reserved device memory for Dom%d.\n",
+                       d->domain_id);
+                goto out;
+            }
+        }
+
+        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, p2m->default_access);
         if ( rc )
             goto out; /* Failed to update p2m, bail without updating m2p. */
 
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 5f7fe71..99f7fb7 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -709,6 +709,15 @@ static inline unsigned int p2m_get_iommu_flags(p2m_type_t p2mt)
     return flags;
 }
 
+struct p2m_get_reserved_device_memory {
+    unsigned long gfn;
+    struct domain *domain;
+};
+
+/* Check if we are accessing rdm. */
+extern int p2m_check_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
+                                            u32 id, void *ctxt);
+
 #endif /* _XEN_P2M_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 Dec 01 09:30:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNJo-00046r-Fr; Mon, 01 Dec 2014 09:30: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 1XvNJm-00044k-Tv
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:55 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	43/E0-23865-E453C745; Mon, 01 Dec 2014 09:30:54 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!10
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 7281 invoked from network); 1 Dec 2014 09:30:53 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:53 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101278"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:49 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:30 +0800
Message-Id: <1417425875-9634-13-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 12/17] xen/x86/ept: handle reserved device
	memory in ept_handle_violation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 always reserve these ranges since we never allow any stuff to
poke them.

But in theory some untrusted VM can maliciously access them. So we
need to intercept this approach. But we just don't want to leak
anything or introduce any side affect since other OSs may touch them
by careless behavior, so its enough to have a lightweight way, and
it shouldn't be same as those broken pages which cause domain crush.

So we just need to return with next eip then let VM/OS itself handle
such a scenario as its own logic.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/arch/x86/hvm/vmx/vmx.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2907afa..3ee884a 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2403,6 +2403,7 @@ static void ept_handle_violation(unsigned long qualification, paddr_t gpa)
     p2m_type_t p2mt;
     int ret;
     struct domain *d = current->domain;
+    struct p2m_get_reserved_device_memory pgrdm;
 
     /*
      * We treat all write violations also as read violations.
@@ -2438,6 +2439,23 @@ static void ept_handle_violation(unsigned long qualification, paddr_t gpa)
         __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
     }
 
+    /* This means some untrusted VM can maliciously access reserved
+     * device memory. But we just don't want to leak anything or
+     * introduce any side affect since other OSs may touch them by
+     * careless behavior, so its enough to have a lightweight way.
+     * Here we just need to return with next eip then let VM/OS itself
+     * handle such a scenario as its own logic.
+     */
+    pgrdm.gfn = gfn;
+    pgrdm.domain = d;
+    ret = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                           &pgrdm);
+    if ( ret )
+    {
+        update_guest_eip();
+        return;
+    }
+
     if ( qualification & EPT_GLA_VALID )
     {
         __vmread(GUEST_LINEAR_ADDRESS, &gla);
-- 
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 Dec 01 09:30:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNJo-00046r-Fr; Mon, 01 Dec 2014 09:30: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 1XvNJm-00044k-Tv
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:55 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	43/E0-23865-E453C745; Mon, 01 Dec 2014 09:30:54 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!10
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 7281 invoked from network); 1 Dec 2014 09:30:53 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:53 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101278"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:49 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:30 +0800
Message-Id: <1417425875-9634-13-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 12/17] xen/x86/ept: handle reserved device
	memory in ept_handle_violation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 always reserve these ranges since we never allow any stuff to
poke them.

But in theory some untrusted VM can maliciously access them. So we
need to intercept this approach. But we just don't want to leak
anything or introduce any side affect since other OSs may touch them
by careless behavior, so its enough to have a lightweight way, and
it shouldn't be same as those broken pages which cause domain crush.

So we just need to return with next eip then let VM/OS itself handle
such a scenario as its own logic.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/arch/x86/hvm/vmx/vmx.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2907afa..3ee884a 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2403,6 +2403,7 @@ static void ept_handle_violation(unsigned long qualification, paddr_t gpa)
     p2m_type_t p2mt;
     int ret;
     struct domain *d = current->domain;
+    struct p2m_get_reserved_device_memory pgrdm;
 
     /*
      * We treat all write violations also as read violations.
@@ -2438,6 +2439,23 @@ static void ept_handle_violation(unsigned long qualification, paddr_t gpa)
         __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
     }
 
+    /* This means some untrusted VM can maliciously access reserved
+     * device memory. But we just don't want to leak anything or
+     * introduce any side affect since other OSs may touch them by
+     * careless behavior, so its enough to have a lightweight way.
+     * Here we just need to return with next eip then let VM/OS itself
+     * handle such a scenario as its own logic.
+     */
+    pgrdm.gfn = gfn;
+    pgrdm.domain = d;
+    ret = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                           &pgrdm);
+    if ( ret )
+    {
+        update_guest_eip();
+        return;
+    }
+
     if ( qualification & EPT_GLA_VALID )
     {
         __vmread(GUEST_LINEAR_ADDRESS, &gla);
-- 
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 Dec 01 09:30:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJq-00049C-3A; Mon, 01 Dec 2014 09:30:58 +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 1XvNJp-00047j-C4
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:57 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	10/0F-24859-0553C745; Mon, 01 Dec 2014 09:30:56 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!11
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 7619 invoked from network); 1 Dec 2014 09:30:55 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:55 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101317"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:52 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:31 +0800
Message-Id: <1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 13/17] xen/mem_access: don't allow accessing
	reserved device 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

We can't expost those reserved device memory in case of mem_access
since any access may corrupt device usage.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/common/mem_access.c | 41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index 6c2724b..72a807a 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)
     }
 }
 
+/* We can't expose reserved device memory. */
+static int mem_access_check_rdm(struct domain *d, uint64_aligned_t start,
+                                uint32_t nr)
+{
+    uint32_t i;
+    struct p2m_get_reserved_device_memory pgrdm;
+    int rc = 0;
+
+    if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )
+    {
+        for ( i = 0; i < nr; i++ )
+        {
+            pgrdm.gfn = start + i;
+            pgrdm.domain = d;
+            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                                  &pgrdm);
+            if ( rc < 0 )
+            {
+                printk(XENLOG_WARNING
+                       "Domain %d can't check reserved device memory.\n",
+                       d->domain_id);
+                return rc;
+            }
+
+            if ( rc == 1 )
+            {
+                printk(XENLOG_WARNING
+                       "Domain %d: we shouldn't mem_access reserved device memory.\n",
+                       d->domain_id);
+                return rc;
+            }
+        }
+    }
+
+    return rc;
+}
+
 int mem_access_memop(unsigned long cmd,
                      XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg)
 {
@@ -99,6 +136,10 @@ int mem_access_memop(unsigned long cmd,
               ((mao.pfn + mao.nr - 1) > domain_get_maximum_gpfn(d))) )
             break;
 
+        rc =  mem_access_check_rdm(d, mao.pfn, mao.nr);
+        if ( rc == 1 )
+            break;
+
         rc = p2m_set_mem_access(d, mao.pfn, mao.nr, start_iter,
                                 MEMOP_CMD_MASK, mao.access);
         if ( rc > 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 Dec 01 09:30:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:30:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJq-00049C-3A; Mon, 01 Dec 2014 09:30:58 +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 1XvNJp-00047j-C4
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:30:57 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	10/0F-24859-0553C745; Mon, 01 Dec 2014 09:30:56 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!11
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 7619 invoked from network); 1 Dec 2014 09:30:55 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:55 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101317"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:52 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:31 +0800
Message-Id: <1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 13/17] xen/mem_access: don't allow accessing
	reserved device 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

We can't expost those reserved device memory in case of mem_access
since any access may corrupt device usage.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/common/mem_access.c | 41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index 6c2724b..72a807a 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)
     }
 }
 
+/* We can't expose reserved device memory. */
+static int mem_access_check_rdm(struct domain *d, uint64_aligned_t start,
+                                uint32_t nr)
+{
+    uint32_t i;
+    struct p2m_get_reserved_device_memory pgrdm;
+    int rc = 0;
+
+    if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )
+    {
+        for ( i = 0; i < nr; i++ )
+        {
+            pgrdm.gfn = start + i;
+            pgrdm.domain = d;
+            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                                  &pgrdm);
+            if ( rc < 0 )
+            {
+                printk(XENLOG_WARNING
+                       "Domain %d can't check reserved device memory.\n",
+                       d->domain_id);
+                return rc;
+            }
+
+            if ( rc == 1 )
+            {
+                printk(XENLOG_WARNING
+                       "Domain %d: we shouldn't mem_access reserved device memory.\n",
+                       d->domain_id);
+                return rc;
+            }
+        }
+    }
+
+    return rc;
+}
+
 int mem_access_memop(unsigned long cmd,
                      XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg)
 {
@@ -99,6 +136,10 @@ int mem_access_memop(unsigned long cmd,
               ((mao.pfn + mao.nr - 1) > domain_get_maximum_gpfn(d))) )
             break;
 
+        rc =  mem_access_check_rdm(d, mao.pfn, mao.nr);
+        if ( rc == 1 )
+            break;
+
         rc = p2m_set_mem_access(d, mao.pfn, mao.nr, start_iter,
                                 MEMOP_CMD_MASK, mao.access);
         if ( rc > 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 Dec 01 09:31:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:31:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJt-0004Dy-IG; Mon, 01 Dec 2014 09:31:01 +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 1XvNJs-0004Bi-CC
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:31:00 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	A8/EC-25547-3553C745; Mon, 01 Dec 2014 09:30:59 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!12
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 8106 invoked from network); 1 Dec 2014 09:30:58 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:58 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101347"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:55 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:32 +0800
Message-Id: <1417425875-9634-15-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 14/17] xen/x86/p2m: introduce
	set_identity_p2m_entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will create RMRR mapping as follows:

If gfn space unoccupied, we just set that. If
space already occupy by 1:1 RMRR mapping do thing. Others
should be failed.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/arch/x86/mm/p2m.c     | 28 ++++++++++++++++++++++++++++
 xen/include/asm-x86/p2m.h |  4 ++++
 2 files changed, 32 insertions(+)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 607ecd0..c415521 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -913,6 +913,34 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
     return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct);
 }
 
+int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
+                           p2m_access_t p2ma)
+{
+    p2m_type_t p2mt;
+    p2m_access_t a;
+    mfn_t mfn;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int ret = -EBUSY;
+
+    gfn_lock(p2m, gfn, 0);
+
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
+
+    if ( !mfn_valid(mfn) )
+        ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct,
+                            p2ma);
+    else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
+        ret = 0;
+    else
+        printk(XENLOG_G_WARNING
+               "Cannot identity map d%d:%lx, already mapped to %lx.\n",
+               d->domain_id, gfn, mfn_x(mfn));
+
+    gfn_unlock(p2m, gfn, 0);
+
+    return ret;
+}
+
 /* Returns: 0 for success, -errno for failure */
 int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
 {
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 99f7fb7..26cf0cc 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -509,6 +509,10 @@ int p2m_is_logdirty_range(struct p2m_domain *, unsigned long start,
 int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
 int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
 
+/* Set identity addresses in the p2m table (for pass-through) */
+int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
+                           p2m_access_t p2ma);
+
 /* Add foreign mapping to the guest's p2m table. */
 int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
                     unsigned long gpfn, domid_t foreign_domid);
-- 
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 Dec 01 09:31:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:31:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJt-0004Dy-IG; Mon, 01 Dec 2014 09:31:01 +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 1XvNJs-0004Bi-CC
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:31:00 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	A8/EC-25547-3553C745; Mon, 01 Dec 2014 09:30:59 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!12
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 8106 invoked from network); 1 Dec 2014 09:30:58 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:30:58 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101347"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:55 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:32 +0800
Message-Id: <1417425875-9634-15-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 14/17] xen/x86/p2m: introduce
	set_identity_p2m_entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will create RMRR mapping as follows:

If gfn space unoccupied, we just set that. If
space already occupy by 1:1 RMRR mapping do thing. Others
should be failed.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/arch/x86/mm/p2m.c     | 28 ++++++++++++++++++++++++++++
 xen/include/asm-x86/p2m.h |  4 ++++
 2 files changed, 32 insertions(+)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 607ecd0..c415521 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -913,6 +913,34 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
     return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct);
 }
 
+int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
+                           p2m_access_t p2ma)
+{
+    p2m_type_t p2mt;
+    p2m_access_t a;
+    mfn_t mfn;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int ret = -EBUSY;
+
+    gfn_lock(p2m, gfn, 0);
+
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
+
+    if ( !mfn_valid(mfn) )
+        ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct,
+                            p2ma);
+    else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
+        ret = 0;
+    else
+        printk(XENLOG_G_WARNING
+               "Cannot identity map d%d:%lx, already mapped to %lx.\n",
+               d->domain_id, gfn, mfn_x(mfn));
+
+    gfn_unlock(p2m, gfn, 0);
+
+    return ret;
+}
+
 /* Returns: 0 for success, -errno for failure */
 int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
 {
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 99f7fb7..26cf0cc 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -509,6 +509,10 @@ int p2m_is_logdirty_range(struct p2m_domain *, unsigned long start,
 int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
 int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
 
+/* Set identity addresses in the p2m table (for pass-through) */
+int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
+                           p2m_access_t p2ma);
+
 /* Add foreign mapping to the guest's p2m table. */
 int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
                     unsigned long gpfn, domid_t foreign_domid);
-- 
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 Dec 01 09:31:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:31:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJx-0004J3-C9; Mon, 01 Dec 2014 09:31: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 1XvNJv-0004FE-0z
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:31:03 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	4F/59-25727-6553C745; Mon, 01 Dec 2014 09:31:02 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!13
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 9062 invoked from network); 1 Dec 2014 09:31:01 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:31:01 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101377"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:58 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:33 +0800
Message-Id: <1417425875-9634-16-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 15/17] xen:vtd: create RMRR 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

intel_iommu_map_page() does nothing if VT-d shares EPT page table.
So rmrr_identity_mapping() never create RMRR mapping but in some
cases like some GFX drivers it still need to access RMRR.

Here we will create those RMRR mappings even in shared EPT case.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/drivers/passthrough/vtd/iommu.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index a38f201..a54c6eb 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1856,10 +1856,15 @@ static int rmrr_identity_mapping(struct domain *d, bool_t map,
 
     while ( base_pfn < end_pfn )
     {
-        int err = intel_iommu_map_page(d, base_pfn, base_pfn,
-                                       IOMMUF_readable|IOMMUF_writable);
-
-        if ( err )
+        int err = 0;
+        if ( iommu_use_hap_pt(d) )
+        {
+            ASSERT(!iommu_passthrough || !is_hardware_domain(d));
+            if ( (err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw)) )
+                return err;
+        }
+        else if ( (err = intel_iommu_map_page(d, base_pfn, base_pfn,
+					      IOMMUF_readable|IOMMUF_writable)) )
             return err;
         base_pfn++;
     }
-- 
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 Dec 01 09:31:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:31:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNJx-0004J3-C9; Mon, 01 Dec 2014 09:31: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 1XvNJv-0004FE-0z
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:31:03 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	4F/59-25727-6553C745; Mon, 01 Dec 2014 09:31:02 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!13
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 9062 invoked from network); 1 Dec 2014 09:31:01 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:31:01 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101377"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:30:58 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:33 +0800
Message-Id: <1417425875-9634-16-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 15/17] xen:vtd: create RMRR 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

intel_iommu_map_page() does nothing if VT-d shares EPT page table.
So rmrr_identity_mapping() never create RMRR mapping but in some
cases like some GFX drivers it still need to access RMRR.

Here we will create those RMRR mappings even in shared EPT case.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/drivers/passthrough/vtd/iommu.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index a38f201..a54c6eb 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1856,10 +1856,15 @@ static int rmrr_identity_mapping(struct domain *d, bool_t map,
 
     while ( base_pfn < end_pfn )
     {
-        int err = intel_iommu_map_page(d, base_pfn, base_pfn,
-                                       IOMMUF_readable|IOMMUF_writable);
-
-        if ( err )
+        int err = 0;
+        if ( iommu_use_hap_pt(d) )
+        {
+            ASSERT(!iommu_passthrough || !is_hardware_domain(d));
+            if ( (err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw)) )
+                return err;
+        }
+        else if ( (err = intel_iommu_map_page(d, base_pfn, base_pfn,
+					      IOMMUF_readable|IOMMUF_writable)) )
             return err;
         base_pfn++;
     }
-- 
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 Dec 01 09:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 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 1XvNJz-0004Mj-Tn; Mon, 01 Dec 2014 09:31:07 +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 1XvNJy-0004Jq-8q
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:31:06 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	D3/68-09284-9553C745; Mon, 01 Dec 2014 09:31:05 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!14
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 9522 invoked from network); 1 Dec 2014 09:31:04 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:31:04 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101424"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:31:01 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:34 +0800
Message-Id: <1417425875-9634-17-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 16/17] xen/vtd: group assigned device with
	RMRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sometimes different devices may share RMRR range so in this
case we shouldn't assign these devices into different VMs
since they may have potential leakage even damage between VMs.

So we need to group all devices as RMRR range to make sure they
are just assigned into the same VM.

Here we introduce two field, gid and domid, in struct,
acpi_rmrr_unit:
 gid: indicate which group this device owns. "0" is invalid so
      just start from "1".
 domid: indicate which domain this device owns currently. Firstly
        the hardware domain should own it.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/drivers/passthrough/vtd/dmar.c  | 28 ++++++++++++++-
 xen/drivers/passthrough/vtd/dmar.h  |  2 ++
 xen/drivers/passthrough/vtd/iommu.c | 68 +++++++++++++++++++++++++++++++++----
 3 files changed, 91 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
index c5bc8d6..8d3406f 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -572,10 +572,11 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
 {
     struct acpi_dmar_reserved_memory *rmrr =
         container_of(header, struct acpi_dmar_reserved_memory, header);
-    struct acpi_rmrr_unit *rmrru;
+    struct acpi_rmrr_unit *rmrru, *cur_rmrr;
     void *dev_scope_start, *dev_scope_end;
     u64 base_addr = rmrr->base_address, end_addr = rmrr->end_address;
     int ret;
+    static unsigned int group_id = 0;
 
     if ( (ret = acpi_dmar_check_length(header, sizeof(*rmrr))) != 0 )
         return ret;
@@ -611,6 +612,8 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
     rmrru->base_address = base_addr;
     rmrru->end_address = end_addr;
     rmrru->segment = rmrr->segment;
+    /* "0" is an invalid group id. */
+    rmrru->gid = 0;
 
     dev_scope_start = (void *)(rmrr + 1);
     dev_scope_end   = ((void *)rmrr) + header->length;
@@ -682,7 +685,30 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
                     "So please set pci_rdmforce to reserve these ranges"
                     " if you need such a device in hotplug case.\n");
 
+            list_for_each_entry(cur_rmrr, &acpi_rmrr_units, list)
+            {
+                /*
+                 * Any same or overlap range mean they should be
+                 * at same group.
+                 */
+                if ( ((base_addr >= cur_rmrr->base_address) &&
+                     (end_addr <= cur_rmrr->end_address)) ||
+                     ((base_addr <= cur_rmrr->base_address) &&
+                     (end_addr >= cur_rmrr->end_address)) )
+                {
+                    rmrru->gid = cur_rmrr->gid;
+                    continue;
+                }
+            }
+
             acpi_register_rmrr_unit(rmrru);
+
+            /* Allocate group id from gid:1. */
+            if ( !rmrru->gid )
+            {
+                group_id++;
+                rmrru->gid = group_id;
+            }
         }
     }
 
diff --git a/xen/drivers/passthrough/vtd/dmar.h b/xen/drivers/passthrough/vtd/dmar.h
index af1feef..a57c0d4 100644
--- a/xen/drivers/passthrough/vtd/dmar.h
+++ b/xen/drivers/passthrough/vtd/dmar.h
@@ -76,6 +76,8 @@ struct acpi_rmrr_unit {
     u64    end_address;
     u16    segment;
     u8     allow_all:1;
+    int    gid;
+    domid_t    domid;
 };
 
 struct acpi_atsr_unit {
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index a54c6eb..ba40209 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1882,9 +1882,9 @@ static int rmrr_identity_mapping(struct domain *d, bool_t map,
 
 static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
 {
-    struct acpi_rmrr_unit *rmrr;
-    u16 bdf;
-    int ret, i;
+    struct acpi_rmrr_unit *rmrr, *g_rmrr;
+    u16 bdf, g_bdf;
+    int ret, i, j;
 
     ASSERT(spin_is_locked(&pcidevs_lock));
 
@@ -1905,6 +1905,32 @@ static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
              PCI_BUS(bdf) == pdev->bus &&
              PCI_DEVFN2(bdf) == devfn )
         {
+            if ( rmrr->domid == hardware_domain->domain_id )
+            {
+                for_each_rmrr_device ( g_rmrr, g_bdf, j )
+                {
+                    if ( g_rmrr->gid == rmrr->gid )
+                    {
+                        if ( g_rmrr->domid == hardware_domain->domain_id )
+                            g_rmrr->domid = pdev->domain->domain_id;
+                        else if ( g_rmrr->domid != pdev->domain->domain_id )
+                        {
+                            rmrr->domid = g_rmrr->domid;
+                            continue;
+                        }
+                    }
+                }
+            }
+
+            if ( rmrr->domid != pdev->domain->domain_id )
+            {
+                domain_context_unmap(pdev->domain, devfn, pdev);
+                dprintk(XENLOG_ERR VTDPREFIX, "d%d: this is a group device owned by d%d\n",
+                        pdev->domain->domain_id, rmrr->domid);
+                rmrr->domid = 0;
+                return -EINVAL;
+            }
+
             ret = rmrr_identity_mapping(pdev->domain, 1, rmrr);
             if ( ret )
                 dprintk(XENLOG_ERR VTDPREFIX, "d%d: RMRR mapping failed\n",
@@ -1946,6 +1972,8 @@ static int intel_iommu_remove_device(u8 devfn, struct pci_dev *pdev)
              PCI_DEVFN2(bdf) != devfn )
             continue;
 
+        /* Just release to hardware domain. */
+        rmrr->domid = hardware_domain->domain_id;
         rmrr_identity_mapping(pdev->domain, 0, rmrr);
     }
 
@@ -2104,6 +2132,8 @@ static void __hwdom_init setup_hwdom_rmrr(struct domain *d)
     spin_lock(&pcidevs_lock);
     for_each_rmrr_device ( rmrr, bdf, i )
     {
+        /* hwdom should own all devices at first. */
+        rmrr->domid = d->domain_id;
         ret = rmrr_identity_mapping(d, 1, rmrr);
         if ( ret )
             dprintk(XENLOG_ERR VTDPREFIX,
@@ -2273,9 +2303,9 @@ static int reassign_device_ownership(
 static int intel_iommu_assign_device(
     struct domain *d, u8 devfn, struct pci_dev *pdev)
 {
-    struct acpi_rmrr_unit *rmrr;
-    int ret = 0, i;
-    u16 bdf, seg;
+    struct acpi_rmrr_unit *rmrr, *g_rmrr;
+    int ret = 0, i, j;
+    u16 bdf, seg, g_bdf;
     u8 bus;
 
     if ( list_empty(&acpi_drhd_units) )
@@ -2300,6 +2330,32 @@ static int intel_iommu_assign_device(
              PCI_BUS(bdf) == bus &&
              PCI_DEVFN2(bdf) == devfn )
         {
+            if ( rmrr->domid == hardware_domain->domain_id )
+            {
+                for_each_rmrr_device ( g_rmrr, g_bdf, j )
+                {
+                    if ( g_rmrr->gid == rmrr->gid )
+                    {
+                        if ( g_rmrr->domid == hardware_domain->domain_id )
+                            g_rmrr->domid = pdev->domain->domain_id;
+                        else if ( g_rmrr->domid != pdev->domain->domain_id )
+                        {
+                            rmrr->domid = g_rmrr->domid;
+                            continue;
+                        }
+                    }
+                }
+            }
+
+            if ( rmrr->domid != pdev->domain->domain_id )
+            {
+                domain_context_unmap(pdev->domain, devfn, pdev);
+                dprintk(XENLOG_ERR VTDPREFIX, "d%d: this is a group device owned by d%d\n",
+                        pdev->domain->domain_id, rmrr->domid);
+                rmrr->domid = 0;
+                return -EINVAL;
+            }
+
             ret = rmrr_identity_mapping(d, 1, rmrr);
             if ( ret )
             {
-- 
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 Dec 01 09:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 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 1XvNJz-0004Mj-Tn; Mon, 01 Dec 2014 09:31:07 +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 1XvNJy-0004Jq-8q
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:31:06 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	D3/68-09284-9553C745; Mon, 01 Dec 2014 09:31:05 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!14
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 9522 invoked from network); 1 Dec 2014 09:31:04 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:31:04 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101424"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:31:01 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:34 +0800
Message-Id: <1417425875-9634-17-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 16/17] xen/vtd: group assigned device with
	RMRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sometimes different devices may share RMRR range so in this
case we shouldn't assign these devices into different VMs
since they may have potential leakage even damage between VMs.

So we need to group all devices as RMRR range to make sure they
are just assigned into the same VM.

Here we introduce two field, gid and domid, in struct,
acpi_rmrr_unit:
 gid: indicate which group this device owns. "0" is invalid so
      just start from "1".
 domid: indicate which domain this device owns currently. Firstly
        the hardware domain should own it.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/drivers/passthrough/vtd/dmar.c  | 28 ++++++++++++++-
 xen/drivers/passthrough/vtd/dmar.h  |  2 ++
 xen/drivers/passthrough/vtd/iommu.c | 68 +++++++++++++++++++++++++++++++++----
 3 files changed, 91 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
index c5bc8d6..8d3406f 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -572,10 +572,11 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
 {
     struct acpi_dmar_reserved_memory *rmrr =
         container_of(header, struct acpi_dmar_reserved_memory, header);
-    struct acpi_rmrr_unit *rmrru;
+    struct acpi_rmrr_unit *rmrru, *cur_rmrr;
     void *dev_scope_start, *dev_scope_end;
     u64 base_addr = rmrr->base_address, end_addr = rmrr->end_address;
     int ret;
+    static unsigned int group_id = 0;
 
     if ( (ret = acpi_dmar_check_length(header, sizeof(*rmrr))) != 0 )
         return ret;
@@ -611,6 +612,8 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
     rmrru->base_address = base_addr;
     rmrru->end_address = end_addr;
     rmrru->segment = rmrr->segment;
+    /* "0" is an invalid group id. */
+    rmrru->gid = 0;
 
     dev_scope_start = (void *)(rmrr + 1);
     dev_scope_end   = ((void *)rmrr) + header->length;
@@ -682,7 +685,30 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
                     "So please set pci_rdmforce to reserve these ranges"
                     " if you need such a device in hotplug case.\n");
 
+            list_for_each_entry(cur_rmrr, &acpi_rmrr_units, list)
+            {
+                /*
+                 * Any same or overlap range mean they should be
+                 * at same group.
+                 */
+                if ( ((base_addr >= cur_rmrr->base_address) &&
+                     (end_addr <= cur_rmrr->end_address)) ||
+                     ((base_addr <= cur_rmrr->base_address) &&
+                     (end_addr >= cur_rmrr->end_address)) )
+                {
+                    rmrru->gid = cur_rmrr->gid;
+                    continue;
+                }
+            }
+
             acpi_register_rmrr_unit(rmrru);
+
+            /* Allocate group id from gid:1. */
+            if ( !rmrru->gid )
+            {
+                group_id++;
+                rmrru->gid = group_id;
+            }
         }
     }
 
diff --git a/xen/drivers/passthrough/vtd/dmar.h b/xen/drivers/passthrough/vtd/dmar.h
index af1feef..a57c0d4 100644
--- a/xen/drivers/passthrough/vtd/dmar.h
+++ b/xen/drivers/passthrough/vtd/dmar.h
@@ -76,6 +76,8 @@ struct acpi_rmrr_unit {
     u64    end_address;
     u16    segment;
     u8     allow_all:1;
+    int    gid;
+    domid_t    domid;
 };
 
 struct acpi_atsr_unit {
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index a54c6eb..ba40209 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1882,9 +1882,9 @@ static int rmrr_identity_mapping(struct domain *d, bool_t map,
 
 static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
 {
-    struct acpi_rmrr_unit *rmrr;
-    u16 bdf;
-    int ret, i;
+    struct acpi_rmrr_unit *rmrr, *g_rmrr;
+    u16 bdf, g_bdf;
+    int ret, i, j;
 
     ASSERT(spin_is_locked(&pcidevs_lock));
 
@@ -1905,6 +1905,32 @@ static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
              PCI_BUS(bdf) == pdev->bus &&
              PCI_DEVFN2(bdf) == devfn )
         {
+            if ( rmrr->domid == hardware_domain->domain_id )
+            {
+                for_each_rmrr_device ( g_rmrr, g_bdf, j )
+                {
+                    if ( g_rmrr->gid == rmrr->gid )
+                    {
+                        if ( g_rmrr->domid == hardware_domain->domain_id )
+                            g_rmrr->domid = pdev->domain->domain_id;
+                        else if ( g_rmrr->domid != pdev->domain->domain_id )
+                        {
+                            rmrr->domid = g_rmrr->domid;
+                            continue;
+                        }
+                    }
+                }
+            }
+
+            if ( rmrr->domid != pdev->domain->domain_id )
+            {
+                domain_context_unmap(pdev->domain, devfn, pdev);
+                dprintk(XENLOG_ERR VTDPREFIX, "d%d: this is a group device owned by d%d\n",
+                        pdev->domain->domain_id, rmrr->domid);
+                rmrr->domid = 0;
+                return -EINVAL;
+            }
+
             ret = rmrr_identity_mapping(pdev->domain, 1, rmrr);
             if ( ret )
                 dprintk(XENLOG_ERR VTDPREFIX, "d%d: RMRR mapping failed\n",
@@ -1946,6 +1972,8 @@ static int intel_iommu_remove_device(u8 devfn, struct pci_dev *pdev)
              PCI_DEVFN2(bdf) != devfn )
             continue;
 
+        /* Just release to hardware domain. */
+        rmrr->domid = hardware_domain->domain_id;
         rmrr_identity_mapping(pdev->domain, 0, rmrr);
     }
 
@@ -2104,6 +2132,8 @@ static void __hwdom_init setup_hwdom_rmrr(struct domain *d)
     spin_lock(&pcidevs_lock);
     for_each_rmrr_device ( rmrr, bdf, i )
     {
+        /* hwdom should own all devices at first. */
+        rmrr->domid = d->domain_id;
         ret = rmrr_identity_mapping(d, 1, rmrr);
         if ( ret )
             dprintk(XENLOG_ERR VTDPREFIX,
@@ -2273,9 +2303,9 @@ static int reassign_device_ownership(
 static int intel_iommu_assign_device(
     struct domain *d, u8 devfn, struct pci_dev *pdev)
 {
-    struct acpi_rmrr_unit *rmrr;
-    int ret = 0, i;
-    u16 bdf, seg;
+    struct acpi_rmrr_unit *rmrr, *g_rmrr;
+    int ret = 0, i, j;
+    u16 bdf, seg, g_bdf;
     u8 bus;
 
     if ( list_empty(&acpi_drhd_units) )
@@ -2300,6 +2330,32 @@ static int intel_iommu_assign_device(
              PCI_BUS(bdf) == bus &&
              PCI_DEVFN2(bdf) == devfn )
         {
+            if ( rmrr->domid == hardware_domain->domain_id )
+            {
+                for_each_rmrr_device ( g_rmrr, g_bdf, j )
+                {
+                    if ( g_rmrr->gid == rmrr->gid )
+                    {
+                        if ( g_rmrr->domid == hardware_domain->domain_id )
+                            g_rmrr->domid = pdev->domain->domain_id;
+                        else if ( g_rmrr->domid != pdev->domain->domain_id )
+                        {
+                            rmrr->domid = g_rmrr->domid;
+                            continue;
+                        }
+                    }
+                }
+            }
+
+            if ( rmrr->domid != pdev->domain->domain_id )
+            {
+                domain_context_unmap(pdev->domain, devfn, pdev);
+                dprintk(XENLOG_ERR VTDPREFIX, "d%d: this is a group device owned by d%d\n",
+                        pdev->domain->domain_id, rmrr->domid);
+                rmrr->domid = 0;
+                return -EINVAL;
+            }
+
             ret = rmrr_identity_mapping(d, 1, rmrr);
             if ( ret )
             {
-- 
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 Dec 01 09:31:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNK2-0004QR-Fx; Mon, 01 Dec 2014 09:31:10 +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 1XvNK0-0004Ns-Vr
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:31:09 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	35/71-16982-C553C745; Mon, 01 Dec 2014 09:31:08 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!15
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 9779 invoked from network); 1 Dec 2014 09:31:07 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:31:07 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101453"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:31:03 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:35 +0800
Message-Id: <1417425875-9634-18-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 17/17] xen/vtd: re-enable USB device
	assignment if enable pci_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

Before we refine RMRR mechanism, USB RMRR may conflict with guest bios
region so we always ignore USB RMRR. Now this can be gone when we enable
pci_force to check/reserve RMRR.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/drivers/passthrough/vtd/dmar.h  |  1 +
 xen/drivers/passthrough/vtd/iommu.c | 12 ++++++++----
 xen/drivers/passthrough/vtd/utils.c | 18 ++++++++++++++++++
 3 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/dmar.h b/xen/drivers/passthrough/vtd/dmar.h
index a57c0d4..832dc32 100644
--- a/xen/drivers/passthrough/vtd/dmar.h
+++ b/xen/drivers/passthrough/vtd/dmar.h
@@ -132,6 +132,7 @@ do {                                                \
 int vtd_hw_check(void);
 void disable_pmr(struct iommu *iommu);
 int is_usb_device(u16 seg, u8 bus, u8 devfn);
+int is_reserve_device_memory(struct domain *d, u8 bus, u8 devfn);
 int is_igd_drhd(struct acpi_drhd_unit *drhd);
 
 #endif /* _DMAR_H_ */
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index ba40209..1f1ceb7 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2264,9 +2264,11 @@ static int reassign_device_ownership(
      * remove it from the hardware domain, because BIOS may use RMRR at
      * booting time. Also account for the special casing of USB below (in
      * intel_iommu_assign_device()).
+     * But if we already check to reserve RMRR, this should be fine.
      */
     if ( !is_hardware_domain(source) &&
-         !is_usb_device(pdev->seg, pdev->bus, pdev->devfn) )
+         !is_usb_device(pdev->seg, pdev->bus, pdev->devfn) &&
+         !is_reserve_device_memory(source, pdev->bus, pdev->devfn) )
     {
         const struct acpi_rmrr_unit *rmrr;
         u16 bdf;
@@ -2315,12 +2317,14 @@ static int intel_iommu_assign_device(
     if ( ret )
         return ret;
 
-    /* FIXME: Because USB RMRR conflicts with guest bios region,
-     * ignore USB RMRR temporarily.
+    /*
+     * Because USB RMRR conflicts with guest bios region,
+     * ignore USB RMRR temporarily in case of non-reserving-RMRR.
      */
     seg = pdev->seg;
     bus = pdev->bus;
-    if ( is_usb_device(seg, bus, pdev->devfn) )
+    if ( is_usb_device(seg, bus, pdev->devfn) &&
+         !is_reserve_device_memory(d, bus, pdev->devfn) )
         return 0;
 
     /* Setup rmrr identity mapping */
diff --git a/xen/drivers/passthrough/vtd/utils.c b/xen/drivers/passthrough/vtd/utils.c
index a33564b..1045ac1 100644
--- a/xen/drivers/passthrough/vtd/utils.c
+++ b/xen/drivers/passthrough/vtd/utils.c
@@ -36,6 +36,24 @@ int is_usb_device(u16 seg, u8 bus, u8 devfn)
     return (class == 0xc03);
 }
 
+int is_reserve_device_memory(struct domain *d, u8 bus, u8 devfn)
+{
+    int i = 0;
+
+    if ( d->arch.hvm_domain.pci_force == PCI_DEV_RDM_CHECK )
+        return 1;
+
+    for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
+    {
+        if ( d->arch.hvm_domain.pcidevs[i].bus == bus &&
+             d->arch.hvm_domain.pcidevs[i].devfn == devfn &&
+             d->arch.hvm_domain.pcidevs[i].flags == PCI_DEV_RDM_CHECK )
+        return 1;
+    }
+
+    return 0;
+}
+
 /* Disable vt-d protected memory registers. */
 void disable_pmr(struct iommu *iommu)
 {
-- 
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 Dec 01 09:31:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNK2-0004QR-Fx; Mon, 01 Dec 2014 09:31:10 +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 1XvNK0-0004Ns-Vr
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:31:09 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	35/71-16982-C553C745; Mon, 01 Dec 2014 09:31:08 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417426226!12467740!15
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 9779 invoked from network); 1 Dec 2014 09:31:07 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	1 Dec 2014 09:31:07 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 01:27:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; d="scan'208";a="646101453"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga002.jf.intel.com with ESMTP; 01 Dec 2014 01:31:03 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: jbeulich@suse.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com, kevin.tian@intel.com, tim@xen.org,
	yang.z.zhang@intel.com
Date: Mon,  1 Dec 2014 17:24:35 +0800
Message-Id: <1417425875-9634-18-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [v8][PATCH 17/17] xen/vtd: re-enable USB device
	assignment if enable pci_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

Before we refine RMRR mechanism, USB RMRR may conflict with guest bios
region so we always ignore USB RMRR. Now this can be gone when we enable
pci_force to check/reserve RMRR.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 xen/drivers/passthrough/vtd/dmar.h  |  1 +
 xen/drivers/passthrough/vtd/iommu.c | 12 ++++++++----
 xen/drivers/passthrough/vtd/utils.c | 18 ++++++++++++++++++
 3 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/dmar.h b/xen/drivers/passthrough/vtd/dmar.h
index a57c0d4..832dc32 100644
--- a/xen/drivers/passthrough/vtd/dmar.h
+++ b/xen/drivers/passthrough/vtd/dmar.h
@@ -132,6 +132,7 @@ do {                                                \
 int vtd_hw_check(void);
 void disable_pmr(struct iommu *iommu);
 int is_usb_device(u16 seg, u8 bus, u8 devfn);
+int is_reserve_device_memory(struct domain *d, u8 bus, u8 devfn);
 int is_igd_drhd(struct acpi_drhd_unit *drhd);
 
 #endif /* _DMAR_H_ */
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index ba40209..1f1ceb7 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2264,9 +2264,11 @@ static int reassign_device_ownership(
      * remove it from the hardware domain, because BIOS may use RMRR at
      * booting time. Also account for the special casing of USB below (in
      * intel_iommu_assign_device()).
+     * But if we already check to reserve RMRR, this should be fine.
      */
     if ( !is_hardware_domain(source) &&
-         !is_usb_device(pdev->seg, pdev->bus, pdev->devfn) )
+         !is_usb_device(pdev->seg, pdev->bus, pdev->devfn) &&
+         !is_reserve_device_memory(source, pdev->bus, pdev->devfn) )
     {
         const struct acpi_rmrr_unit *rmrr;
         u16 bdf;
@@ -2315,12 +2317,14 @@ static int intel_iommu_assign_device(
     if ( ret )
         return ret;
 
-    /* FIXME: Because USB RMRR conflicts with guest bios region,
-     * ignore USB RMRR temporarily.
+    /*
+     * Because USB RMRR conflicts with guest bios region,
+     * ignore USB RMRR temporarily in case of non-reserving-RMRR.
      */
     seg = pdev->seg;
     bus = pdev->bus;
-    if ( is_usb_device(seg, bus, pdev->devfn) )
+    if ( is_usb_device(seg, bus, pdev->devfn) &&
+         !is_reserve_device_memory(d, bus, pdev->devfn) )
         return 0;
 
     /* Setup rmrr identity mapping */
diff --git a/xen/drivers/passthrough/vtd/utils.c b/xen/drivers/passthrough/vtd/utils.c
index a33564b..1045ac1 100644
--- a/xen/drivers/passthrough/vtd/utils.c
+++ b/xen/drivers/passthrough/vtd/utils.c
@@ -36,6 +36,24 @@ int is_usb_device(u16 seg, u8 bus, u8 devfn)
     return (class == 0xc03);
 }
 
+int is_reserve_device_memory(struct domain *d, u8 bus, u8 devfn)
+{
+    int i = 0;
+
+    if ( d->arch.hvm_domain.pci_force == PCI_DEV_RDM_CHECK )
+        return 1;
+
+    for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
+    {
+        if ( d->arch.hvm_domain.pcidevs[i].bus == bus &&
+             d->arch.hvm_domain.pcidevs[i].devfn == devfn &&
+             d->arch.hvm_domain.pcidevs[i].flags == PCI_DEV_RDM_CHECK )
+        return 1;
+    }
+
+    return 0;
+}
+
 /* Disable vt-d protected memory registers. */
 void disable_pmr(struct iommu *iommu)
 {
-- 
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 Dec 01 09:32:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNLK-0005UR-8d; Mon, 01 Dec 2014 09:32: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 1XvNLI-0005TV-RN
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:32:28 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	A9/6F-05632-CA53C745; Mon, 01 Dec 2014 09:32:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417426344!14956598!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 6639 invoked from network); 1 Dec 2014 09:32: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;
	1 Dec 2014 09:32:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,492,1413244800"; d="scan'208";a="198319999"
Message-ID: <1417426343.23604.72.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Date: Mon, 1 Dec 2014 09:32:23 +0000
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A723E1@SHSMSX103.ccr.corp.intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
	<21624.27112.826272.933990@mariner.uk.xensource.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A723E1@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.liu2@citrix.com" <wei.liu2@citrix.com>, "Pang,
	LongtaoX" <longtaox.pang@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Zheng, Di" <di.zheng@intel.com>,
	"xen-devel@lists.xen.org" <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

On Mon, 2014-12-01 at 05:27 +0000, Hu, Robert wrote:
> > 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.
> Agree with you we shall reuse existing ts-* if possible. Actually I had thought of this approach but later I 
> defeated myself because I thought ts-* shall compromise itself as a whole test case and better not to touch them.
> Now I see that ts- is more like components to constitute a test case (my current understanding is your job == test cases).

Have you seen the README at the top-level of osstest.git? It starts with
a terminology section, which includes defining what a job is: a sequence
of test steps, which could also be called a test case. The ts-* prefix
stands for test step BTW.

There is certainly scope for improving the docs though so please do ask
if anything is unclear and we can improve the docs.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:32:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNLK-0005UR-8d; Mon, 01 Dec 2014 09:32: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 1XvNLI-0005TV-RN
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:32:28 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	A9/6F-05632-CA53C745; Mon, 01 Dec 2014 09:32:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417426344!14956598!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 6639 invoked from network); 1 Dec 2014 09:32: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;
	1 Dec 2014 09:32:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,492,1413244800"; d="scan'208";a="198319999"
Message-ID: <1417426343.23604.72.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hu, Robert" <robert.hu@intel.com>
Date: Mon, 1 Dec 2014 09:32:23 +0000
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31A723E1@SHSMSX103.ccr.corp.intel.com>
References: <1417160727-3100-1-git-send-email-longtaox.pang@intel.com>
	<21624.27112.826272.933990@mariner.uk.xensource.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A723E1@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.liu2@citrix.com" <wei.liu2@citrix.com>, "Pang,
	LongtaoX" <longtaox.pang@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Zheng, Di" <di.zheng@intel.com>,
	"xen-devel@lists.xen.org" <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

On Mon, 2014-12-01 at 05:27 +0000, Hu, Robert wrote:
> > 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.
> Agree with you we shall reuse existing ts-* if possible. Actually I had thought of this approach but later I 
> defeated myself because I thought ts-* shall compromise itself as a whole test case and better not to touch them.
> Now I see that ts- is more like components to constitute a test case (my current understanding is your job == test cases).

Have you seen the README at the top-level of osstest.git? It starts with
a terminology section, which includes defining what a job is: a sequence
of test steps, which could also be called a test case. The ts-* prefix
stands for test step BTW.

There is certainly scope for improving the docs though so please do ask
if anything is unclear and we can improve the docs.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:32:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNLQ-0005XG-Ll; Mon, 01 Dec 2014 09:32: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 1XvNLO-0005Vm-Cf
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:32:34 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	79/12-11581-1B53C745; Mon, 01 Dec 2014 09:32:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417426351!14225807!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26488 invoked from network); 1 Dec 2014 09:32:31 -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; 1 Dec 2014 09:32:31 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 09:32:30 +0000
Message-Id: <547C43BA020000780004B9BE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 09:32:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zhang Yu" <yu.c.zhang@linux.intel.com>,<tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
In-Reply-To: <547C2BAF.6010004@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, 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 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
> On 11/28/2014 5:57 PM, Jan Beulich wrote:
>>>>> 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?
> Thanks for your comments, Jan.
> The indentation here is to make sure the
> ((p2mt == p2m_ram_ro) || (p2mt == p2m_mmio_write_dm)) are grouped 
> together. But I am not sure if this is correct according to xen coding 
> style. I may have misunderstood your previous comments on Sep 3, which 
> said "the indentation would need adjustment" in reply to "[Xen-devel] 
> [PATCH v3 1/2] x86: add p2m_mmio_write_dm"

Getting the alignment right is needed, but no via using hard tabs.

>> 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.
>>
> Thanks Jan.
> To my understanding, pages with p2m_ram_ro are not supposed to be 
> modified by guest. So in __hvm_copy(), when p2m type of a page is 
> p2m_ram_rom, no copy will occur.
> However, to our usage, we just wanna this page to be write protected, so 
> that our device model can be triggered to do some emulation. The content 
> written to this page is supposed not to be dropped. This way, if 
> sequentially a read operation is performed by guest to this page, the 
> guest will still see its anticipated value.

__hvm_copy() is only a helper function, and doesn't write to
mmio_dm space either; instead its (indirect) callers would invoke
hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
returns. The question hence is about the apparent inconsistency
resulting from writes to ram_ro being dropped here but getting
passed to the DM by hvm_hap_nested_page_fault(). Tim - is
that really intentional?

> Maybe I need to update my commit message to explain this more clearly. :)

At the very least, yes.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:32:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNLQ-0005XG-Ll; Mon, 01 Dec 2014 09:32: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 1XvNLO-0005Vm-Cf
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:32:34 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	79/12-11581-1B53C745; Mon, 01 Dec 2014 09:32:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417426351!14225807!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26488 invoked from network); 1 Dec 2014 09:32:31 -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; 1 Dec 2014 09:32:31 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 09:32:30 +0000
Message-Id: <547C43BA020000780004B9BE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 09:32:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zhang Yu" <yu.c.zhang@linux.intel.com>,<tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
In-Reply-To: <547C2BAF.6010004@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, 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 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
> On 11/28/2014 5:57 PM, Jan Beulich wrote:
>>>>> 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?
> Thanks for your comments, Jan.
> The indentation here is to make sure the
> ((p2mt == p2m_ram_ro) || (p2mt == p2m_mmio_write_dm)) are grouped 
> together. But I am not sure if this is correct according to xen coding 
> style. I may have misunderstood your previous comments on Sep 3, which 
> said "the indentation would need adjustment" in reply to "[Xen-devel] 
> [PATCH v3 1/2] x86: add p2m_mmio_write_dm"

Getting the alignment right is needed, but no via using hard tabs.

>> 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.
>>
> Thanks Jan.
> To my understanding, pages with p2m_ram_ro are not supposed to be 
> modified by guest. So in __hvm_copy(), when p2m type of a page is 
> p2m_ram_rom, no copy will occur.
> However, to our usage, we just wanna this page to be write protected, so 
> that our device model can be triggered to do some emulation. The content 
> written to this page is supposed not to be dropped. This way, if 
> sequentially a read operation is performed by guest to this page, the 
> guest will still see its anticipated value.

__hvm_copy() is only a helper function, and doesn't write to
mmio_dm space either; instead its (indirect) callers would invoke
hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
returns. The question hence is about the apparent inconsistency
resulting from writes to ram_ro being dropped here but getting
passed to the DM by hvm_hap_nested_page_fault(). Tim - is
that really intentional?

> Maybe I need to update my commit message to explain this more clearly. :)

At the very least, yes.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:35:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:35:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNNe-0006Nj-7t; Mon, 01 Dec 2014 09:34: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 1XvNNc-0006NJ-0J
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:34:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8E/EC-15461-B363C745; Mon, 01 Dec 2014 09:34:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417426489!12479054!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 2024 invoked from network); 1 Dec 2014 09:34:50 -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;
	1 Dec 2014 09:34:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,492,1413244800"; d="scan'208";a="198320622"
Message-ID: <1417426487.23604.74.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 1 Dec 2014 09:34:47 +0000
In-Reply-To: <1417384485-20874-1-git-send-email-wei.liu2@citrix.com>
References: <1417384485-20874-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: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [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

On Sun, 2014-11-30 at 21:54 +0000, Wei Liu wrote:
> 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);

I think you should un-const the declaration (in both cases) rather than
adding casts.

> +        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;
>  }
>  



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:35:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:35:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNNe-0006Nj-7t; Mon, 01 Dec 2014 09:34: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 1XvNNc-0006NJ-0J
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:34:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8E/EC-15461-B363C745; Mon, 01 Dec 2014 09:34:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417426489!12479054!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 2024 invoked from network); 1 Dec 2014 09:34:50 -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;
	1 Dec 2014 09:34:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,492,1413244800"; d="scan'208";a="198320622"
Message-ID: <1417426487.23604.74.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 1 Dec 2014 09:34:47 +0000
In-Reply-To: <1417384485-20874-1-git-send-email-wei.liu2@citrix.com>
References: <1417384485-20874-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: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [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

On Sun, 2014-11-30 at 21:54 +0000, Wei Liu wrote:
> 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);

I think you should un-const the declaration (in both cases) rather than
adding casts.

> +        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;
>  }
>  



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:39:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:39:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNRZ-0006c8-37; Mon, 01 Dec 2014 09: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 1XvNRX-0006c3-SC
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:38:55 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	C5/CC-02954-F273C745; Mon, 01 Dec 2014 09:38:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417426733!12145052!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 7634 invoked from network); 1 Dec 2014 09:38: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;
	1 Dec 2014 09:38:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,492,1413244800"; d="scan'208";a="198321437"
Message-ID: <1417426731.23604.76.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Dennis Lan (dlan)" <dennis.yxun@gmail.com>
Date: Mon, 1 Dec 2014 09:38:51 +0000
In-Reply-To: <CAF1ZMEc=Qsrw1QPzABMAFU5n1t_JZ2nRQFQ+T8xYnxqsGX4=og@mail.gmail.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> <5460A51E.9050401@web2web.at>
	<1415621371.28370.15.camel@citrix.com>
	<CAF1ZMEc=Qsrw1QPzABMAFU5n1t_JZ2nRQFQ+T8xYnxqsGX4=og@mail.gmail.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 Mon, 2014-12-01 at 11:34 +0800, Dennis Lan (dlan) wrote:
> On Mon, Nov 10, 2014 at 8:09 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 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.
> >
> Hi Ian
>  what we found now is, the Gentoo's hardened toolchain, turn CFLAGS
> -fstack-check on by default, with this flag and compile gcc will
> result xl segfault (actually with libgcc_s.so)
>  we have a patch to force gcc build libgcc(only this part) code with
> -fstack-check=no, make the segfault gone
>  more info can be found at https://bugs.gentoo.org/show_bug.cgi?id=528690

Excellent, thanks for letting us know.

Just to be sure: This isn't (so far as anyone knows) the result of any
coding/build-system problem in Xen, right?

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:39:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:39:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNRZ-0006c8-37; Mon, 01 Dec 2014 09: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 1XvNRX-0006c3-SC
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:38:55 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	C5/CC-02954-F273C745; Mon, 01 Dec 2014 09:38:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417426733!12145052!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 7634 invoked from network); 1 Dec 2014 09:38: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;
	1 Dec 2014 09:38:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,492,1413244800"; d="scan'208";a="198321437"
Message-ID: <1417426731.23604.76.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Dennis Lan (dlan)" <dennis.yxun@gmail.com>
Date: Mon, 1 Dec 2014 09:38:51 +0000
In-Reply-To: <CAF1ZMEc=Qsrw1QPzABMAFU5n1t_JZ2nRQFQ+T8xYnxqsGX4=og@mail.gmail.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> <5460A51E.9050401@web2web.at>
	<1415621371.28370.15.camel@citrix.com>
	<CAF1ZMEc=Qsrw1QPzABMAFU5n1t_JZ2nRQFQ+T8xYnxqsGX4=og@mail.gmail.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 Mon, 2014-12-01 at 11:34 +0800, Dennis Lan (dlan) wrote:
> On Mon, Nov 10, 2014 at 8:09 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 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.
> >
> Hi Ian
>  what we found now is, the Gentoo's hardened toolchain, turn CFLAGS
> -fstack-check on by default, with this flag and compile gcc will
> result xl segfault (actually with libgcc_s.so)
>  we have a patch to force gcc build libgcc(only this part) code with
> -fstack-check=no, make the segfault gone
>  more info can be found at https://bugs.gentoo.org/show_bug.cgi?id=528690

Excellent, thanks for letting us know.

Just to be sure: This isn't (so far as anyone knows) the result of any
coding/build-system problem in Xen, right?

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:42:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:42:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNUr-0006n5-Md; Mon, 01 Dec 2014 09:42: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 1XvNUq-0006mz-1s
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 09:42:20 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	91/74-27623-BF73C745; Mon, 01 Dec 2014 09:42:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417426934!14918012!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18609 invoked from network); 1 Dec 2014 09:42:16 -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;
	1 Dec 2014 09:42:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,492,1413244800"; d="scan'208";a="197996722"
Message-ID: <1417426933.23604.77.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ed Swierk <eswierk@skyportsystems.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 09:42:13 +0000
In-Reply-To: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.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] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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 Sat, 2014-11-29 at 21:23 -0800, Ed Swierk wrote:
> - Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
>   parameter
> - Change deprecated %name-prefix= to %name-prefix
> 
> Tested against bison 2.4.1 and 3.0.2.
> 
> Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>

Copying Ian J who is the bison guy among the toolstack maintainers.

> ---
>  tools/libxl/libxlu_cfg_y.y | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
> index aa9f787..5acd438 100644
> --- a/tools/libxl/libxlu_cfg_y.y
> +++ b/tools/libxl/libxlu_cfg_y.y
> @@ -17,7 +17,7 @@
>   */
>  
>  %{
> -#define YYLEX_PARAM ctx->scanner
> +#define ctx_scanner ctx->scanner
>  #include "libxlu_cfg_i.h"
>  #include "libxlu_cfg_l.h"
>  %}
> @@ -31,9 +31,9 @@
>  %pure-parser
>  %defines
>  %error-verbose
> -%name-prefix="xlu__cfg_yy"
> +%name-prefix "xlu__cfg_yy"
>  %parse-param { CfgParseContext *ctx }
> -%lex-param { void *scanner }
> +%lex-param { ctx_scanner }
>  
>  %token <string>                IDENT STRING NUMBER NEWLINE
>  %type <string>            atom



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:42:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:42:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNUr-0006n5-Md; Mon, 01 Dec 2014 09:42: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 1XvNUq-0006mz-1s
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 09:42:20 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	91/74-27623-BF73C745; Mon, 01 Dec 2014 09:42:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417426934!14918012!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18609 invoked from network); 1 Dec 2014 09:42:16 -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;
	1 Dec 2014 09:42:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,492,1413244800"; d="scan'208";a="197996722"
Message-ID: <1417426933.23604.77.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ed Swierk <eswierk@skyportsystems.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 09:42:13 +0000
In-Reply-To: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.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] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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 Sat, 2014-11-29 at 21:23 -0800, Ed Swierk wrote:
> - Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
>   parameter
> - Change deprecated %name-prefix= to %name-prefix
> 
> Tested against bison 2.4.1 and 3.0.2.
> 
> Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>

Copying Ian J who is the bison guy among the toolstack maintainers.

> ---
>  tools/libxl/libxlu_cfg_y.y | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
> index aa9f787..5acd438 100644
> --- a/tools/libxl/libxlu_cfg_y.y
> +++ b/tools/libxl/libxlu_cfg_y.y
> @@ -17,7 +17,7 @@
>   */
>  
>  %{
> -#define YYLEX_PARAM ctx->scanner
> +#define ctx_scanner ctx->scanner
>  #include "libxlu_cfg_i.h"
>  #include "libxlu_cfg_l.h"
>  %}
> @@ -31,9 +31,9 @@
>  %pure-parser
>  %defines
>  %error-verbose
> -%name-prefix="xlu__cfg_yy"
> +%name-prefix "xlu__cfg_yy"
>  %parse-param { CfgParseContext *ctx }
> -%lex-param { void *scanner }
> +%lex-param { ctx_scanner }
>  
>  %token <string>                IDENT STRING NUMBER NEWLINE
>  %type <string>            atom



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:49:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNbD-0006zX-GH; Mon, 01 Dec 2014 09:48:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alukardd@alukardd.org>) id 1XvNbC-0006zS-In
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:48:54 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	AB/FA-23865-5893C745; Mon, 01 Dec 2014 09:48:53 +0000
X-Env-Sender: alukardd@alukardd.org
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417427332!12474087!1
X-Originating-IP: [188.134.93.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 13738 invoked from network); 1 Dec 2014 09:48:53 -0000
Received: from alukardd.org (HELO alukardd.org) (188.134.93.171)
	by server-14.tower-31.messagelabs.com with AES128-SHA encrypted SMTP;
	1 Dec 2014 09:48:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alukardd.org;
	s=mail; 
	h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version;
	bh=7NH7/bbv24jpDZrrJUSj+e+aJ8JmI4cR0YalDLYc+8k=; 
	b=RGYq2JLBA+gX1bT5xI/ihAJKeagFN1X+HhesIRQfCTArdTy/jI7hxnjG97nq7VlY/xqhnebz/4ojZNoIOB+uF/KCo93nNNWUMG0ZX+3ji+Ht+OZm9sdgIo9/ASfTui9fpHvV2gQD7JW52JP/y4s+9+dyCAzoQqV0vuTpyjh+0Yg=;
Received: from alukardd.org ([172.17.0.101]:55810 helo=mail.alukardd.org)
	by alukardd.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
	(Exim 4.84) (envelope-from <alukardd@alukardd.org>)
	id 1XvNb8-0004Oz-GM
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:48:52 +0300
MIME-Version: 1.0
Date: Mon, 01 Dec 2014 12:48:50 +0300
From: Alexey <alukardd@alukardd.org>
To: Xen-devel@lists.xen.org
Message-ID: <e2a4f20c920a491592cef78dd006da8a@alukardd.org>
X-Sender: alukardd@alukardd.org
User-Agent: Alukardd Webmail
Subject: [Xen-devel] null domains | xen4.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, all!

We are once again faced with the null-domains problem.
At this moment we have xen node with 49 null-domains and if I create new 
domain and shutdown it I w'll get a new one null-domain.

All blkback and netback kernel process are exists. There is no qemu 
process running.
I can't delete any vif or stop disk, which was used by dead domain.

How we can prevent appearance of null-domains?
How we can unlock resources of existing null-domains?


# xl info
host                   : xen23
release                : 3.10-3-amd64
version                : #1 SMP Debian 
3.10.55-1+0~20140927201537.42+wheezy~1.gbp4678fd (
machine                : x86_64
nr_cpus                : 16
max_cpu_id             : 23
nr_nodes               : 2
cores_per_socket       : 4
threads_per_core       : 2
cpu_mhz                : 2266
hw_caps                : 
bfebfbff:28100800:00000000:00003b00:009ce3bd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 131063
free_memory            : 124512
sharing_freed_memory   : 0
sharing_used_memory    : 0
outstanding_claims     : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 4
xen_extra              : .2-pre
xen_version            : 4.4.2-pre
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          :
xen_commandline        : tmem=1 loglvl=all noreboot dom0_mem=5120M 
dom0_vcpus_pin console=vga vga=current
cc_compiler            : gcc (Debian 4.7.2-5) 4.7.2
xend_config_format     : 4

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:49:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNbD-0006zX-GH; Mon, 01 Dec 2014 09:48:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alukardd@alukardd.org>) id 1XvNbC-0006zS-In
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:48:54 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	AB/FA-23865-5893C745; Mon, 01 Dec 2014 09:48:53 +0000
X-Env-Sender: alukardd@alukardd.org
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417427332!12474087!1
X-Originating-IP: [188.134.93.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 13738 invoked from network); 1 Dec 2014 09:48:53 -0000
Received: from alukardd.org (HELO alukardd.org) (188.134.93.171)
	by server-14.tower-31.messagelabs.com with AES128-SHA encrypted SMTP;
	1 Dec 2014 09:48:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alukardd.org;
	s=mail; 
	h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version;
	bh=7NH7/bbv24jpDZrrJUSj+e+aJ8JmI4cR0YalDLYc+8k=; 
	b=RGYq2JLBA+gX1bT5xI/ihAJKeagFN1X+HhesIRQfCTArdTy/jI7hxnjG97nq7VlY/xqhnebz/4ojZNoIOB+uF/KCo93nNNWUMG0ZX+3ji+Ht+OZm9sdgIo9/ASfTui9fpHvV2gQD7JW52JP/y4s+9+dyCAzoQqV0vuTpyjh+0Yg=;
Received: from alukardd.org ([172.17.0.101]:55810 helo=mail.alukardd.org)
	by alukardd.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
	(Exim 4.84) (envelope-from <alukardd@alukardd.org>)
	id 1XvNb8-0004Oz-GM
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:48:52 +0300
MIME-Version: 1.0
Date: Mon, 01 Dec 2014 12:48:50 +0300
From: Alexey <alukardd@alukardd.org>
To: Xen-devel@lists.xen.org
Message-ID: <e2a4f20c920a491592cef78dd006da8a@alukardd.org>
X-Sender: alukardd@alukardd.org
User-Agent: Alukardd Webmail
Subject: [Xen-devel] null domains | xen4.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, all!

We are once again faced with the null-domains problem.
At this moment we have xen node with 49 null-domains and if I create new 
domain and shutdown it I w'll get a new one null-domain.

All blkback and netback kernel process are exists. There is no qemu 
process running.
I can't delete any vif or stop disk, which was used by dead domain.

How we can prevent appearance of null-domains?
How we can unlock resources of existing null-domains?


# xl info
host                   : xen23
release                : 3.10-3-amd64
version                : #1 SMP Debian 
3.10.55-1+0~20140927201537.42+wheezy~1.gbp4678fd (
machine                : x86_64
nr_cpus                : 16
max_cpu_id             : 23
nr_nodes               : 2
cores_per_socket       : 4
threads_per_core       : 2
cpu_mhz                : 2266
hw_caps                : 
bfebfbff:28100800:00000000:00003b00:009ce3bd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 131063
free_memory            : 124512
sharing_freed_memory   : 0
sharing_used_memory    : 0
outstanding_claims     : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 4
xen_extra              : .2-pre
xen_version            : 4.4.2-pre
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          :
xen_commandline        : tmem=1 loglvl=all noreboot dom0_mem=5120M 
dom0_vcpus_pin console=vga vga=current
cc_compiler            : gcc (Debian 4.7.2-5) 4.7.2
xend_config_format     : 4

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:59:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNlL-0007TG-Nx; Mon, 01 Dec 2014 09:59:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvNlK-0007T9-AU
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:59:22 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7E/1C-09842-9FB3C745; Mon, 01 Dec 2014 09:59:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417427960!12525359!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 31024 invoked from network); 1 Dec 2014 09:59:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 09:59:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="197999976"
Message-ID: <1417427958.27655.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alexey <alukardd@alukardd.org>
Date: Mon, 1 Dec 2014 09:59:18 +0000
In-Reply-To: <e2a4f20c920a491592cef78dd006da8a@alukardd.org>
References: <e2a4f20c920a491592cef78dd006da8a@alukardd.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
Subject: Re: [Xen-devel] null domains | xen4.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-12-01 at 12:48 +0300, Alexey wrote:
> Hi, all!
> 
> We are once again faced with the null-domains problem.
> At this moment we have xen node with 49 null-domains and if I create new 
> domain and shutdown it I w'll get a new one null-domain.
> 
> All blkback and netback kernel process are exists. There is no qemu 
> process running.
> I can't delete any vif or stop disk, which was used by dead domain.

What do you mean here, does a vif or disk still exist for the dead
domain then?

> How we can prevent appearance of null-domains?
> How we can unlock resources of existing null-domains?

A null domain remains when a page owned by that domain is still
referenced from somewhere. The output of the 'q' debug key sometimes
exposes the source of such references. ("xl debug-key q" will send that,
the result appears in "xl dmesg", alternatively Ctrl-A three times on
the serial console then 'q').

> # xl info
> host                   : xen23
> release                : 3.10-3-amd64

Any chance you could try a newer dom0 kernel?

> xen_commandline        : tmem=1 loglvl=all noreboot dom0_mem=5120M 
> dom0_vcpus_pin console=vga vga=current

Are you able to reproduce when tmem is not enabled?

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 09:59:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 09: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 1XvNlL-0007TG-Nx; Mon, 01 Dec 2014 09:59:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvNlK-0007T9-AU
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 09:59:22 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7E/1C-09842-9FB3C745; Mon, 01 Dec 2014 09:59:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417427960!12525359!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 31024 invoked from network); 1 Dec 2014 09:59:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 09:59:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="197999976"
Message-ID: <1417427958.27655.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alexey <alukardd@alukardd.org>
Date: Mon, 1 Dec 2014 09:59:18 +0000
In-Reply-To: <e2a4f20c920a491592cef78dd006da8a@alukardd.org>
References: <e2a4f20c920a491592cef78dd006da8a@alukardd.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
Subject: Re: [Xen-devel] null domains | xen4.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-12-01 at 12:48 +0300, Alexey wrote:
> Hi, all!
> 
> We are once again faced with the null-domains problem.
> At this moment we have xen node with 49 null-domains and if I create new 
> domain and shutdown it I w'll get a new one null-domain.
> 
> All blkback and netback kernel process are exists. There is no qemu 
> process running.
> I can't delete any vif or stop disk, which was used by dead domain.

What do you mean here, does a vif or disk still exist for the dead
domain then?

> How we can prevent appearance of null-domains?
> How we can unlock resources of existing null-domains?

A null domain remains when a page owned by that domain is still
referenced from somewhere. The output of the 'q' debug key sometimes
exposes the source of such references. ("xl debug-key q" will send that,
the result appears in "xl dmesg", alternatively Ctrl-A three times on
the serial console then 'q').

> # xl info
> host                   : xen23
> release                : 3.10-3-amd64

Any chance you could try a newer dom0 kernel?

> xen_commandline        : tmem=1 loglvl=all noreboot dom0_mem=5120M 
> dom0_vcpus_pin console=vga vga=current

Are you able to reproduce when tmem is not enabled?

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 10:10:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:10:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNvn-0008EX-3p; Mon, 01 Dec 2014 10:10:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvNvm-0008ES-1w
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 10:10:10 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	B8/7C-17735-18E3C745; Mon, 01 Dec 2014 10:10:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417428607!11200789!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18485 invoked from network); 1 Dec 2014 10:10: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;
	1 Dec 2014 10:10:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198003013"
Received: from ukmail1.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, 1 Dec 2014 05:10: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 1XvNvi-0004VZ-12;
	Mon, 01 Dec 2014 10:10:06 +0000
Date: Mon, 1 Dec 2014 10:10:06 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201101005.GA19896@zion.uk.xensource.com>
References: <1417384485-20874-1-git-send-email-wei.liu2@citrix.com>
	<1417426487.23604.74.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417426487.23604.74.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
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] 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

On Mon, Dec 01, 2014 at 09:34:47AM +0000, Ian Campbell wrote:
> On Sun, 2014-11-30 at 21:54 +0000, Wei Liu wrote:
> > 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);
> 
> I think you should un-const the declaration (in both cases) rather than
> adding casts.
> 

Is it OK to change the declaration of a public API?

Wei.

> > +        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;
> >  }
> >  
> 

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 10:10:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:10:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvNvn-0008EX-3p; Mon, 01 Dec 2014 10:10:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvNvm-0008ES-1w
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 10:10:10 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	B8/7C-17735-18E3C745; Mon, 01 Dec 2014 10:10:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417428607!11200789!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18485 invoked from network); 1 Dec 2014 10:10: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;
	1 Dec 2014 10:10:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198003013"
Received: from ukmail1.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, 1 Dec 2014 05:10: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 1XvNvi-0004VZ-12;
	Mon, 01 Dec 2014 10:10:06 +0000
Date: Mon, 1 Dec 2014 10:10:06 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201101005.GA19896@zion.uk.xensource.com>
References: <1417384485-20874-1-git-send-email-wei.liu2@citrix.com>
	<1417426487.23604.74.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417426487.23604.74.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
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] 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

On Mon, Dec 01, 2014 at 09:34:47AM +0000, Ian Campbell wrote:
> On Sun, 2014-11-30 at 21:54 +0000, Wei Liu wrote:
> > 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);
> 
> I think you should un-const the declaration (in both cases) rather than
> adding casts.
> 

Is it OK to change the declaration of a public API?

Wei.

> > +        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;
> >  }
> >  
> 

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 10:15:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvO15-0000II-SO; Mon, 01 Dec 2014 10:15:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XvO14-0000ID-6g
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 10:15:38 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	5C/82-02957-9CF3C745; Mon, 01 Dec 2014 10:15:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417428936!12152411!1
X-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 1555 invoked from network); 1 Dec 2014 10:15:36 -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; 1 Dec 2014 10:15:36 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 10:15:36 +0000
Message-Id: <547C4DD6020000780004BA83@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 10:15:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>
	<1417426153-12893-2-git-send-email-jgross@suse.com>
In-Reply-To: <1417426153-12893-2-git-send-email-jgross@suse.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, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [Patch V2] 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 01.12.14 at 10:29, <JGross@suse.com> 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, the root of the page table root and a p2m generation count.
> 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.
> 
> Right now XENFEAT_virtual_p2m will not be set. This will change when
> the Xen tools support the virtual mapped p2m list.

This seems wrong: XENFEAT_* only reflect hypervisor capabilities.
I.e. the availability of the new functionality may need to be
advertised another way - xenstore perhaps?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 10:15:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvO15-0000II-SO; Mon, 01 Dec 2014 10:15:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XvO14-0000ID-6g
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 10:15:38 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	5C/82-02957-9CF3C745; Mon, 01 Dec 2014 10:15:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417428936!12152411!1
X-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 1555 invoked from network); 1 Dec 2014 10:15:36 -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; 1 Dec 2014 10:15:36 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 10:15:36 +0000
Message-Id: <547C4DD6020000780004BA83@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 10:15:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>
	<1417426153-12893-2-git-send-email-jgross@suse.com>
In-Reply-To: <1417426153-12893-2-git-send-email-jgross@suse.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, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [Patch V2] 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 01.12.14 at 10:29, <JGross@suse.com> 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, the root of the page table root and a p2m generation count.
> 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.
> 
> Right now XENFEAT_virtual_p2m will not be set. This will change when
> the Xen tools support the virtual mapped p2m list.

This seems wrong: XENFEAT_* only reflect hypervisor capabilities.
I.e. the availability of the new functionality may need to be
advertised another way - xenstore perhaps?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 10:22:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvO77-0000RF-Lz; Mon, 01 Dec 2014 10:21: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 1XvO75-0000Qy-OV
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 10:21:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	01/3C-25276-E314C745; Mon, 01 Dec 2014 10:21:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417429308!12550466!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 5929 invoked from network); 1 Dec 2014 10:21: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;
	1 Dec 2014 10:21:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198007099"
Message-ID: <1417429306.27655.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 1 Dec 2014 10:21:46 +0000
In-Reply-To: <20141201101005.GA19896@zion.uk.xensource.com>
References: <1417384485-20874-1-git-send-email-wei.liu2@citrix.com>
	<1417426487.23604.74.camel@citrix.com>
	<20141201101005.GA19896@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 <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [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

On Mon, 2014-12-01 at 10:10 +0000, Wei Liu wrote:
> On Mon, Dec 01, 2014 at 09:34:47AM +0000, Ian Campbell wrote:
> > On Sun, 2014-11-30 at 21:54 +0000, Wei Liu wrote:
> > > 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);
> > 
> > I think you should un-const the declaration (in both cases) rather than
> > adding casts.
> > 
> 
> Is it OK to change the declaration of a public API?

Oh god, libxl_basename returns a dynamically allocated string as a
const. That's a bit mad... At least it is clearly documented as being a
strdup'd thing!

I think we may need to use LIBXL_API_VERSION here to conditionally
include the const. We've done that before see
LIBXL_HAVE_NONCONST_EVENT_OCCURS_EVENT_ARG.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 10:22:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvO77-0000RF-Lz; Mon, 01 Dec 2014 10:21: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 1XvO75-0000Qy-OV
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 10:21:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	01/3C-25276-E314C745; Mon, 01 Dec 2014 10:21:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417429308!12550466!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 5929 invoked from network); 1 Dec 2014 10:21: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;
	1 Dec 2014 10:21:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198007099"
Message-ID: <1417429306.27655.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 1 Dec 2014 10:21:46 +0000
In-Reply-To: <20141201101005.GA19896@zion.uk.xensource.com>
References: <1417384485-20874-1-git-send-email-wei.liu2@citrix.com>
	<1417426487.23604.74.camel@citrix.com>
	<20141201101005.GA19896@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 <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [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

On Mon, 2014-12-01 at 10:10 +0000, Wei Liu wrote:
> On Mon, Dec 01, 2014 at 09:34:47AM +0000, Ian Campbell wrote:
> > On Sun, 2014-11-30 at 21:54 +0000, Wei Liu wrote:
> > > 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);
> > 
> > I think you should un-const the declaration (in both cases) rather than
> > adding casts.
> > 
> 
> Is it OK to change the declaration of a public API?

Oh god, libxl_basename returns a dynamically allocated string as a
const. That's a bit mad... At least it is clearly documented as being a
strdup'd thing!

I think we may need to use LIBXL_API_VERSION here to conditionally
include the const. We've done that before see
LIBXL_HAVE_NONCONST_EVENT_OCCURS_EVENT_ARG.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 10:30:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:30:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvOEi-0000jk-Mm; Mon, 01 Dec 2014 10:29:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <libo.zhu@intel.com>) id 1XvMT8-0002nC-Tj
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 08:36:31 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AA/92-09842-E882C745; Mon, 01 Dec 2014 08:36:30 +0000
X-Env-Sender: libo.zhu@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417422986!12470033!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30587 invoked from network); 1 Dec 2014 08:36:26 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-15.tower-21.messagelabs.com with SMTP;
	1 Dec 2014 08:36:26 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 01 Dec 2014 00:29:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; 
	d="scan'208,217";a="630638712"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by fmsmga001.fm.intel.com with ESMTP; 01 Dec 2014 00:36:00 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 1 Dec 2014 16:33:34 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Mon, 1 Dec 2014 16:33:31 +0800
From: "Zhu, Libo" <libo.zhu@intel.com>
To: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>,
	"'intel-gfx@lists.freedesktop.org'" <intel-gfx@lists.freedesktop.org>, 
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Thread-Topic: [Intel-gfx] 2014-Q3 release of  XenGT - a Mediated Graphics
	Passthrough Solution from Intel
Thread-Index: AdAIU5b+cid7MTe4Ta6oWVvHy6BFxQ==
Date: Mon, 1 Dec 2014 08:33:30 +0000
Message-ID: <26A47C02D5B26643A21178CE46F576F539662C@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 01 Dec 2014 10:29:43 +0000
Cc: "Tian, Kevin" <kevin.tian@intel.com>, "White,
	Michael L" <michael.l.white@intel.com>, "Dong, 
	Eddie" <eddie.dong@intel.com>, "Li, Susie" <susie.li@intel.com>,
	"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>,
	"Downs, Mike" <mike.downs@intel.com>, "Wang,
	Hongbo" <hongbo.wang@intel.com>
Subject: [Xen-devel] [Intel-gfx] 2014-Q3 release of XenGT - a Mediated
 Graphics Passthrough Solution from Intel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0809822841889117213=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0809822841889117213==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_26A47C02D5B26643A21178CE46F576F539662CSHSMSX101ccrcorpi_"

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

Hi all,



We're pleased to announce a public release to Intel Graphics Virtualization=
 Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a comple=
te vGPU solution with mediated pass-through, supported today on 4th generat=
ion Intel Core(TM) processors with Intel Graphics processors. A virtual GPU=
 instance is maintained for each VM, with part of performance critical reso=
urces directly assigned. The capability of running native graphics driver i=
nside a VM, without hypervisor intervention in performance critical paths, =
achieves a good balance among performance, feature, and sharing capability.=
 Though we only support Xen on Intel Processor Graphics so far, the core lo=
gic can be easily ported to other hypervisors.



The news of this update:



                - kernel update from 3.11.6 to 3.14.1

- We plan to integrate Intel GVT-g as a feature in i915 driver. That effort=
 is still under review, not included in this update yet

                - Next update will be around early Jan, 2015



This update consists of:

                - Windows HVM support with driver version 15.33.3910

                - Stability fixes, e.g. stabilize GPU, the GPU hang occurre=
nce rate becomes rare now

                - Hardware Media Acceleration for Decoding/Encoding/Transco=
ding, VC1, H264 etc. format supporting

                - Display enhancements, e.g. DP type is supported for virtu=
al PORT

                - Display port capability virtualization: with this feature=
, dom0 manager could freely assign virtual DDI ports to VM, not necessary t=
o check whether the corresponding physical DDI ports are available





Please refer to the new setup guide, which provides step-to-step details ab=
out building/configuring/running Intel GVT-g:



                https://github.com/01org/XenGT-Preview-kernel/blob/master/X=
enGT_Setup_Guide.pdf





The new source codes are available at the updated github repos:



                Linux: https://github.com/01org/XenGT-Preview-kernel.git

                Xen: https://github.com/01org/XenGT-Preview-xen.git

                Qemu: https://github.com/01org/XenGT-Preview-qemu.git



More information about Intel GVT-g background, architecture, etc can be fou=
nd at:



                https://www.usenix.org/conference/atc14/technical-sessions/=
presentation/tian

                http://events.linuxfoundation.org/sites/events/files/slides=
/XenGT-Xen%20Summit-v7_0.pdf

                https://01.org/xen/blogs/srclarkx/2013/graphics-virtualizat=
ion-xengt



The previous update can be found here:



               http://lists.xen.org/archives/html/xen-devel/2014-07/msg0324=
8.html



Appreciate your comments!


Best regards.
LiboZhu
Tel: +86-21-6116 7988
MP: +86-134-8204-6855
Mail: libo.zhu@intel.com<mailto:libo.zhu@intel.com>


--_000_26A47C02D5B26643A21178CE46F576F539662CSHSMSX101ccrcorpi_
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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;
	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"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Hi all,<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">We're pleased to announce a public release to Int=
el Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT=
). Intel GVT-g is a complete vGPU solution with mediated pass-through, supp=
orted today on 4th generation Intel
 Core(TM) processors with Intel Graphics processors. A virtual GPU instance=
 is maintained for each VM, with part of performance critical resources dir=
ectly assigned. The capability of running native graphics driver inside a V=
M, without hypervisor intervention
 in performance critical paths, achieves a good balance among performance, =
feature, and sharing capability. Though we only support Xen on Intel Proces=
sor Graphics so far, the core logic can be easily ported to other hyperviso=
rs.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">The news of this update:<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - kernel update from 3.11.6 to 3.=
14.1<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"text-indent:.5in">- We plan to integrate=
 Intel GVT-g as a feature in i915 driver. That effort is still under review=
, not included in this update yet<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Next update will be around earl=
y Jan, 2015<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">This update consists of:<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Windows HVM support with driver=
 version 15.33.3910<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Stability fixes, e.g. stabilize=
 GPU, the GPU hang occurrence rate becomes rare now<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Hardware Media Acceleration for=
 Decoding/Encoding/Transcoding, VC1, H264 etc. format supporting<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Display enhancements, e.g. DP t=
ype is supported for virtual PORT<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Display port capability virtual=
ization: with this feature, dom0 manager could freely assign virtual DDI po=
rts to VM, not necessary to check whether the corresponding physical DDI po=
rts are available<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Please refer to the new setup guide, which provid=
es step-to-step details about building/configuring/running Intel GVT-g:<o:p=
></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"https://github.com/01o=
rg/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide.pdf">
https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide=
.pdf</a>
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">The new source codes are available at the updated=
 github repos:<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Linux: <a href=3D"https://github.=
com/01org/XenGT-Preview-kernel.git">
https://github.com/01org/XenGT-Preview-kernel.git</a><o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Xen: <a href=3D"https://github.co=
m/01org/XenGT-Preview-xen.git">
https://github.com/01org/XenGT-Preview-xen.git</a><o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Qemu: <a href=3D"https://github.c=
om/01org/XenGT-Preview-qemu.git">
https://github.com/01org/XenGT-Preview-qemu.git</a><o:p></o:p></p>
<p class=3D"MsoPlainText"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoPlainText">More information about Intel GVT-g background, ar=
chitecture, etc can be found at:<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"https://www.usenix.org=
/conference/atc14/technical-sessions/presentation/tian">
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tia=
n</a><o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"http://events.linuxfou=
ndation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf">
http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Sum=
mit-v7_0.pdf</a><o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"https://01.org/xen/blo=
gs/srclarkx/2013/graphics-virtualization-xengt">
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt</a><o:=
p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">The previous update can be found here:<o:p></o:p>=
</p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"http://lists.xen.org/ar=
chives/html/xen-devel/2014-07/msg03248.html">http://lists.xen.org/archives/=
html/xen-devel/2014-07/msg03248.html</a>
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Appreciate your comments!<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><i><span style=3D"color:#00B050">Best regards.<o:p><=
/o:p></span></i></p>
<p class=3D"MsoNormal"><i><span style=3D"color:#00B050">LiboZhu<o:p></o:p><=
/span></i></p>
<p class=3D"MsoNormal"><span style=3D"color:#00B050">Tel: &#43;86-21-6116 7=
988<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#00B050">MP: &#43;86-134-8204-6=
855<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#00B050">Mail:</span> <a href=
=3D"mailto:libo.zhu@intel.com">
libo.zhu@intel.com</a><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_26A47C02D5B26643A21178CE46F576F539662CSHSMSX101ccrcorpi_--


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

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

--===============0809822841889117213==--


From xen-devel-bounces@lists.xen.org Mon Dec 01 10:30:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:30:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvOEi-0000jk-Mm; Mon, 01 Dec 2014 10:29:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <libo.zhu@intel.com>) id 1XvMT8-0002nC-Tj
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 08:36:31 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AA/92-09842-E882C745; Mon, 01 Dec 2014 08:36:30 +0000
X-Env-Sender: libo.zhu@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417422986!12470033!1
X-Originating-IP: [192.55.52.115]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30587 invoked from network); 1 Dec 2014 08:36:26 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-15.tower-21.messagelabs.com with SMTP;
	1 Dec 2014 08:36:26 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 01 Dec 2014 00:29:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,492,1413270000"; 
	d="scan'208,217";a="630638712"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by fmsmga001.fm.intel.com with ESMTP; 01 Dec 2014 00:36:00 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 1 Dec 2014 16:33:34 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Mon, 1 Dec 2014 16:33:31 +0800
From: "Zhu, Libo" <libo.zhu@intel.com>
To: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>,
	"'intel-gfx@lists.freedesktop.org'" <intel-gfx@lists.freedesktop.org>, 
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Thread-Topic: [Intel-gfx] 2014-Q3 release of  XenGT - a Mediated Graphics
	Passthrough Solution from Intel
Thread-Index: AdAIU5b+cid7MTe4Ta6oWVvHy6BFxQ==
Date: Mon, 1 Dec 2014 08:33:30 +0000
Message-ID: <26A47C02D5B26643A21178CE46F576F539662C@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 01 Dec 2014 10:29:43 +0000
Cc: "Tian, Kevin" <kevin.tian@intel.com>, "White,
	Michael L" <michael.l.white@intel.com>, "Dong, 
	Eddie" <eddie.dong@intel.com>, "Li, Susie" <susie.li@intel.com>,
	"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>,
	"Downs, Mike" <mike.downs@intel.com>, "Wang,
	Hongbo" <hongbo.wang@intel.com>
Subject: [Xen-devel] [Intel-gfx] 2014-Q3 release of XenGT - a Mediated
 Graphics Passthrough Solution from Intel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0809822841889117213=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0809822841889117213==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_26A47C02D5B26643A21178CE46F576F539662CSHSMSX101ccrcorpi_"

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

Hi all,



We're pleased to announce a public release to Intel Graphics Virtualization=
 Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a comple=
te vGPU solution with mediated pass-through, supported today on 4th generat=
ion Intel Core(TM) processors with Intel Graphics processors. A virtual GPU=
 instance is maintained for each VM, with part of performance critical reso=
urces directly assigned. The capability of running native graphics driver i=
nside a VM, without hypervisor intervention in performance critical paths, =
achieves a good balance among performance, feature, and sharing capability.=
 Though we only support Xen on Intel Processor Graphics so far, the core lo=
gic can be easily ported to other hypervisors.



The news of this update:



                - kernel update from 3.11.6 to 3.14.1

- We plan to integrate Intel GVT-g as a feature in i915 driver. That effort=
 is still under review, not included in this update yet

                - Next update will be around early Jan, 2015



This update consists of:

                - Windows HVM support with driver version 15.33.3910

                - Stability fixes, e.g. stabilize GPU, the GPU hang occurre=
nce rate becomes rare now

                - Hardware Media Acceleration for Decoding/Encoding/Transco=
ding, VC1, H264 etc. format supporting

                - Display enhancements, e.g. DP type is supported for virtu=
al PORT

                - Display port capability virtualization: with this feature=
, dom0 manager could freely assign virtual DDI ports to VM, not necessary t=
o check whether the corresponding physical DDI ports are available





Please refer to the new setup guide, which provides step-to-step details ab=
out building/configuring/running Intel GVT-g:



                https://github.com/01org/XenGT-Preview-kernel/blob/master/X=
enGT_Setup_Guide.pdf





The new source codes are available at the updated github repos:



                Linux: https://github.com/01org/XenGT-Preview-kernel.git

                Xen: https://github.com/01org/XenGT-Preview-xen.git

                Qemu: https://github.com/01org/XenGT-Preview-qemu.git



More information about Intel GVT-g background, architecture, etc can be fou=
nd at:



                https://www.usenix.org/conference/atc14/technical-sessions/=
presentation/tian

                http://events.linuxfoundation.org/sites/events/files/slides=
/XenGT-Xen%20Summit-v7_0.pdf

                https://01.org/xen/blogs/srclarkx/2013/graphics-virtualizat=
ion-xengt



The previous update can be found here:



               http://lists.xen.org/archives/html/xen-devel/2014-07/msg0324=
8.html



Appreciate your comments!


Best regards.
LiboZhu
Tel: +86-21-6116 7988
MP: +86-134-8204-6855
Mail: libo.zhu@intel.com<mailto:libo.zhu@intel.com>


--_000_26A47C02D5B26643A21178CE46F576F539662CSHSMSX101ccrcorpi_
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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;
	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"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Hi all,<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">We're pleased to announce a public release to Int=
el Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT=
). Intel GVT-g is a complete vGPU solution with mediated pass-through, supp=
orted today on 4th generation Intel
 Core(TM) processors with Intel Graphics processors. A virtual GPU instance=
 is maintained for each VM, with part of performance critical resources dir=
ectly assigned. The capability of running native graphics driver inside a V=
M, without hypervisor intervention
 in performance critical paths, achieves a good balance among performance, =
feature, and sharing capability. Though we only support Xen on Intel Proces=
sor Graphics so far, the core logic can be easily ported to other hyperviso=
rs.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">The news of this update:<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - kernel update from 3.11.6 to 3.=
14.1<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"text-indent:.5in">- We plan to integrate=
 Intel GVT-g as a feature in i915 driver. That effort is still under review=
, not included in this update yet<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Next update will be around earl=
y Jan, 2015<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">This update consists of:<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Windows HVM support with driver=
 version 15.33.3910<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Stability fixes, e.g. stabilize=
 GPU, the GPU hang occurrence rate becomes rare now<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Hardware Media Acceleration for=
 Decoding/Encoding/Transcoding, VC1, H264 etc. format supporting<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Display enhancements, e.g. DP t=
ype is supported for virtual PORT<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Display port capability virtual=
ization: with this feature, dom0 manager could freely assign virtual DDI po=
rts to VM, not necessary to check whether the corresponding physical DDI po=
rts are available<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Please refer to the new setup guide, which provid=
es step-to-step details about building/configuring/running Intel GVT-g:<o:p=
></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"https://github.com/01o=
rg/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide.pdf">
https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide=
.pdf</a>
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">The new source codes are available at the updated=
 github repos:<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Linux: <a href=3D"https://github.=
com/01org/XenGT-Preview-kernel.git">
https://github.com/01org/XenGT-Preview-kernel.git</a><o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Xen: <a href=3D"https://github.co=
m/01org/XenGT-Preview-xen.git">
https://github.com/01org/XenGT-Preview-xen.git</a><o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Qemu: <a href=3D"https://github.c=
om/01org/XenGT-Preview-qemu.git">
https://github.com/01org/XenGT-Preview-qemu.git</a><o:p></o:p></p>
<p class=3D"MsoPlainText"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoPlainText">More information about Intel GVT-g background, ar=
chitecture, etc can be found at:<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"https://www.usenix.org=
/conference/atc14/technical-sessions/presentation/tian">
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tia=
n</a><o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"http://events.linuxfou=
ndation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf">
http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Sum=
mit-v7_0.pdf</a><o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"https://01.org/xen/blo=
gs/srclarkx/2013/graphics-virtualization-xengt">
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt</a><o:=
p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">The previous update can be found here:<o:p></o:p>=
</p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"http://lists.xen.org/ar=
chives/html/xen-devel/2014-07/msg03248.html">http://lists.xen.org/archives/=
html/xen-devel/2014-07/msg03248.html</a>
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Appreciate your comments!<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><i><span style=3D"color:#00B050">Best regards.<o:p><=
/o:p></span></i></p>
<p class=3D"MsoNormal"><i><span style=3D"color:#00B050">LiboZhu<o:p></o:p><=
/span></i></p>
<p class=3D"MsoNormal"><span style=3D"color:#00B050">Tel: &#43;86-21-6116 7=
988<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#00B050">MP: &#43;86-134-8204-6=
855<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#00B050">Mail:</span> <a href=
=3D"mailto:libo.zhu@intel.com">
libo.zhu@intel.com</a><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_26A47C02D5B26643A21178CE46F576F539662CSHSMSX101ccrcorpi_--


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

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

--===============0809822841889117213==--


From xen-devel-bounces@lists.xen.org Mon Dec 01 10:30:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:30:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvOFc-0000o9-At; Mon, 01 Dec 2014 10:30:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XvOFb-0000o0-C2
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 10:30:39 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	AE/C3-22777-E434C745; Mon, 01 Dec 2014 10:30:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417429837!10752423!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 7571 invoked from network); 1 Dec 2014 10:30:38 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 10:30:38 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XvOFA-000Iic-Kj; Mon, 01 Dec 2014 10:30:12 +0000
Date: Mon, 1 Dec 2014 11:30:12 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141201103012.GA69236@deinos.phlegethon.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C43BA020000780004B9BE@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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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

At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
> >>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
> > On 11/28/2014 5:57 PM, Jan Beulich wrote:
> >>>>> 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?
> > Thanks for your comments, Jan.
> > The indentation here is to make sure the
> > ((p2mt == p2m_ram_ro) || (p2mt == p2m_mmio_write_dm)) are grouped 
> > together. But I am not sure if this is correct according to xen coding 
> > style. I may have misunderstood your previous comments on Sep 3, which 
> > said "the indentation would need adjustment" in reply to "[Xen-devel] 
> > [PATCH v3 1/2] x86: add p2m_mmio_write_dm"
> 
> Getting the alignment right is needed, but no via using hard tabs.
> 
> >> 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.
> >>
> > Thanks Jan.
> > To my understanding, pages with p2m_ram_ro are not supposed to be 
> > modified by guest. So in __hvm_copy(), when p2m type of a page is 
> > p2m_ram_rom, no copy will occur.
> > However, to our usage, we just wanna this page to be write protected, so 
> > that our device model can be triggered to do some emulation. The content 
> > written to this page is supposed not to be dropped. This way, if 
> > sequentially a read operation is performed by guest to this page, the 
> > guest will still see its anticipated value.
> 
> __hvm_copy() is only a helper function, and doesn't write to
> mmio_dm space either; instead its (indirect) callers would invoke
> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
> returns. The question hence is about the apparent inconsistency
> resulting from writes to ram_ro being dropped here but getting
> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
> that really intentional?

No - and AFAICT it shouldn't be happening.  It _is_ how it was
implemented originally, because it involved fewer moving parts and
didn't need to be efficient (and after all, writes to entirely missing
addresses go to the device model too).

But the code was later updated to log and discard writes to read-only
memory (see 4d8aa29 from Trolle Selander).

Early version of p2m_ram_ro were documented in the internal headers as
sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
has always said that writes are discarded.

During this bit of archaeology I realised that either this new type
should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
just p2m_ram_ro and p2m_grant_map_ro.

Cheers,

Tim.

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 10:30:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:30:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvOFc-0000o9-At; Mon, 01 Dec 2014 10:30:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XvOFb-0000o0-C2
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 10:30:39 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	AE/C3-22777-E434C745; Mon, 01 Dec 2014 10:30:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417429837!10752423!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 7571 invoked from network); 1 Dec 2014 10:30:38 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 10:30:38 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XvOFA-000Iic-Kj; Mon, 01 Dec 2014 10:30:12 +0000
Date: Mon, 1 Dec 2014 11:30:12 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141201103012.GA69236@deinos.phlegethon.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C43BA020000780004B9BE@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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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

At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
> >>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
> > On 11/28/2014 5:57 PM, Jan Beulich wrote:
> >>>>> 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?
> > Thanks for your comments, Jan.
> > The indentation here is to make sure the
> > ((p2mt == p2m_ram_ro) || (p2mt == p2m_mmio_write_dm)) are grouped 
> > together. But I am not sure if this is correct according to xen coding 
> > style. I may have misunderstood your previous comments on Sep 3, which 
> > said "the indentation would need adjustment" in reply to "[Xen-devel] 
> > [PATCH v3 1/2] x86: add p2m_mmio_write_dm"
> 
> Getting the alignment right is needed, but no via using hard tabs.
> 
> >> 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.
> >>
> > Thanks Jan.
> > To my understanding, pages with p2m_ram_ro are not supposed to be 
> > modified by guest. So in __hvm_copy(), when p2m type of a page is 
> > p2m_ram_rom, no copy will occur.
> > However, to our usage, we just wanna this page to be write protected, so 
> > that our device model can be triggered to do some emulation. The content 
> > written to this page is supposed not to be dropped. This way, if 
> > sequentially a read operation is performed by guest to this page, the 
> > guest will still see its anticipated value.
> 
> __hvm_copy() is only a helper function, and doesn't write to
> mmio_dm space either; instead its (indirect) callers would invoke
> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
> returns. The question hence is about the apparent inconsistency
> resulting from writes to ram_ro being dropped here but getting
> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
> that really intentional?

No - and AFAICT it shouldn't be happening.  It _is_ how it was
implemented originally, because it involved fewer moving parts and
didn't need to be efficient (and after all, writes to entirely missing
addresses go to the device model too).

But the code was later updated to log and discard writes to read-only
memory (see 4d8aa29 from Trolle Selander).

Early version of p2m_ram_ro were documented in the internal headers as
sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
has always said that writes are discarded.

During this bit of archaeology I realised that either this new type
should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
just p2m_ram_ro and p2m_grant_map_ro.

Cheers,

Tim.

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 10:40:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10: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 1XvOOs-00018U-Cj; Mon, 01 Dec 2014 10:40:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <euan.harris@citrix.com>) id 1XvOOq-00018P-Is
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 10:40:12 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	F2/F8-25727-B854C745; Mon, 01 Dec 2014 10:40:11 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417430409!14858005!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19142 invoked from network); 1 Dec 2014 10:40:10 -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;
	1 Dec 2014 10:40:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="27304628"
From: Euan Harris <euan.harris@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 10:39:44 +0000
Message-ID: <1417430384-26220-1-git-send-email-euan.harris@citrix.com>
X-Mailer: git-send-email 1.7.1
MIME-Version: 1.0
X-DLP: AMS1
Cc: Euan Harris <euan.harris@citrix.com>, Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl/Makefile: Don't optimize debug builds;
	add macro debugging 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

libxl debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk.   Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library.   Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.

Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations.   This is useful as libxl uses many
non-trivial macros.

Signed-off-by: Euan Harris <euan.harris@citrix.com>
---
 tools/libxl/Makefile |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index df08c8a..26d8679 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -15,6 +15,12 @@ CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
 	-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
+ifeq ($(debug),y)
+# Disable optimizations and debugging information for macros
+CFLAGS += -O0 -g3
+endif
+
+
 ifeq ($(CONFIG_Linux),y)
 LIBUUID_LIBS += -luuid
 endif
-- 
1.7.1


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 10:40:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10: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 1XvOOs-00018U-Cj; Mon, 01 Dec 2014 10:40:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <euan.harris@citrix.com>) id 1XvOOq-00018P-Is
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 10:40:12 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	F2/F8-25727-B854C745; Mon, 01 Dec 2014 10:40:11 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417430409!14858005!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19142 invoked from network); 1 Dec 2014 10:40:10 -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;
	1 Dec 2014 10:40:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="27304628"
From: Euan Harris <euan.harris@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 10:39:44 +0000
Message-ID: <1417430384-26220-1-git-send-email-euan.harris@citrix.com>
X-Mailer: git-send-email 1.7.1
MIME-Version: 1.0
X-DLP: AMS1
Cc: Euan Harris <euan.harris@citrix.com>, Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl/Makefile: Don't optimize debug builds;
	add macro debugging 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

libxl debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk.   Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library.   Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.

Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations.   This is useful as libxl uses many
non-trivial macros.

Signed-off-by: Euan Harris <euan.harris@citrix.com>
---
 tools/libxl/Makefile |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index df08c8a..26d8679 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -15,6 +15,12 @@ CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
 	-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
+ifeq ($(debug),y)
+# Disable optimizations and debugging information for macros
+CFLAGS += -O0 -g3
+endif
+
+
 ifeq ($(CONFIG_Linux),y)
 LIBUUID_LIBS += -luuid
 endif
-- 
1.7.1


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 10:48:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:48:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvOWQ-0001M1-Nl; Mon, 01 Dec 2014 10:48:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <euan.harris@citrix.com>) id 1XvOWQ-0001Lw-3w
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 10:48:02 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	19/04-24124-1674C745; Mon, 01 Dec 2014 10:48:01 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417430880!5370461!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3188 invoked from network); 1 Dec 2014 10:48:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 10:48:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="27304919"
From: Euan Harris <euan.harris@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 10:47:33 +0000
Message-ID: <1417430853-26347-1-git-send-email-euan.harris@citrix.com>
X-Mailer: git-send-email 1.7.1
MIME-Version: 1.0
X-DLP: AMS1
Cc: Euan Harris <euan.harris@citrix.com>, Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: libxl_domain_info: fix typo in error
	message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Euan Harris <euan.harris@citrix.com>
---
 tools/libxl/libxl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f84f7c2..c50c323 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -674,7 +674,7 @@ int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo *info_r,
 
     ret = xc_domain_getinfolist(ctx->xch, domid, 1, &xcinfo);
     if (ret<0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
         return ERROR_FAIL;
     }
     if (ret==0 || xcinfo.domain != domid) return ERROR_INVAL;
-- 
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 Dec 01 10:48:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:48:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvOWQ-0001M1-Nl; Mon, 01 Dec 2014 10:48:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <euan.harris@citrix.com>) id 1XvOWQ-0001Lw-3w
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 10:48:02 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	19/04-24124-1674C745; Mon, 01 Dec 2014 10:48:01 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417430880!5370461!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3188 invoked from network); 1 Dec 2014 10:48:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 10:48:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="27304919"
From: Euan Harris <euan.harris@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 10:47:33 +0000
Message-ID: <1417430853-26347-1-git-send-email-euan.harris@citrix.com>
X-Mailer: git-send-email 1.7.1
MIME-Version: 1.0
X-DLP: AMS1
Cc: Euan Harris <euan.harris@citrix.com>, Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: libxl_domain_info: fix typo in error
	message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Euan Harris <euan.harris@citrix.com>
---
 tools/libxl/libxl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f84f7c2..c50c323 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -674,7 +674,7 @@ int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo *info_r,
 
     ret = xc_domain_getinfolist(ctx->xch, domid, 1, &xcinfo);
     if (ret<0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
         return ERROR_FAIL;
     }
     if (ret==0 || xcinfo.domain != domid) return ERROR_INVAL;
-- 
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 Dec 01 10:54:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:54:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvOcT-0001WR-II; Mon, 01 Dec 2014 10:54:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alukardd@alukardd.org>) id 1XvOcR-0001WM-T7
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 10:54:16 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	77/7E-17735-7D84C745; Mon, 01 Dec 2014 10:54:15 +0000
X-Env-Sender: alukardd@alukardd.org
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417431249!11214650!1
X-Originating-IP: [188.134.93.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 21476 invoked from network); 1 Dec 2014 10:54:10 -0000
Received: from alukardd.org (HELO alukardd.org) (188.134.93.171)
	by server-9.tower-31.messagelabs.com with AES128-SHA encrypted SMTP;
	1 Dec 2014 10:54:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alukardd.org;
	s=mail; 
	h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Type:MIME-Version;
	bh=hnyoUfjmm3GiK9GDxKBdPvdypECDjSb9tCw6jc9Op8A=; 
	b=SmTK86YfVX07fs8fomvMvJl7wzy2Soff/fX5tika+gvEr9UIhxZY/UTK9dsojvRRxVAkLRT/HGcEAwHzwcU7Ihi4pTA44geBGRxH2UqFPzgJwIAERNJ/WQtX5jfCyQ3S+7JGto5To4Gc1gCjpNFMVlyrWR9MOemCfnzaW2GmT+Y=;
Received: from alukardd.org ([172.17.0.101]:55931 helo=mail.alukardd.org)
	by alukardd.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
	(Exim 4.84) (envelope-from <alukardd@alukardd.org>)
	id 1XvOcC-0004XG-Tw; Mon, 01 Dec 2014 13:54:09 +0300
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="=_21384d086a51899f8848c4bc3f5019a6"
Date: Mon, 01 Dec 2014 13:54:00 +0300
From: Alexey <alukardd@alukardd.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417427958.27655.1.camel@citrix.com>
References: <e2a4f20c920a491592cef78dd006da8a@alukardd.org>
	<1417427958.27655.1.camel@citrix.com>
Message-ID: <2a9dd806b9991d506ae274ff67fe5821@alukardd.org>
X-Sender: alukardd@alukardd.org
User-Agent: Alukardd Webmail
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] null domains | xen4.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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--=_21384d086a51899f8848c4bc3f5019a6
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

xl list two domains for example:
(null)                                      67     0     8     --pssd  
135229.6
(null)                                      69     0     4     --ps-d    
4172.2

vif67.0 still exist in my dom0 and i can't "ip link delete" it.
Attached block device marked as busy also.

We try to use the last 3.10 kernel, now new nodes use 3.10.61 kernel, 
but this node on which I can experiment was booted with 3.10.55 kernel.
I attach xl-dmesg after 'q' trigger.

We will discuss tmem with colleagues.

On 2014-12-01 12:59, Ian Campbell wrote:
> On Mon, 2014-12-01 at 12:48 +0300, Alexey wrote:
>> Hi, all!
>> 
>> We are once again faced with the null-domains problem.
>> At this moment we have xen node with 49 null-domains and if I create 
>> new
>> domain and shutdown it I w'll get a new one null-domain.
>> 
>> All blkback and netback kernel process are exists. There is no qemu
>> process running.
>> I can't delete any vif or stop disk, which was used by dead domain.
> 
> What do you mean here, does a vif or disk still exist for the dead
> domain then?
> 
>> How we can prevent appearance of null-domains?
>> How we can unlock resources of existing null-domains?
> 
> A null domain remains when a page owned by that domain is still
> referenced from somewhere. The output of the 'q' debug key sometimes
> exposes the source of such references. ("xl debug-key q" will send 
> that,
> the result appears in "xl dmesg", alternatively Ctrl-A three times on
> the serial console then 'q').
> 
>> # xl info
>> host                   : xen23
>> release                : 3.10-3-amd64
> 
> Any chance you could try a newer dom0 kernel?
> 
>> xen_commandline        : tmem=1 loglvl=all noreboot dom0_mem=5120M
>> dom0_vcpus_pin console=vga vga=current
> 
> Are you able to reproduce when tmem is not enabled?
> 
> Ian.
--=_21384d086a51899f8848c4bc3f5019a6
Content-Transfer-Encoding: base64
Content-Type: text/plain;
 name=xl-dmesg
Content-Disposition: attachment;
 filename=xl-dmesg;
 size=104837

KFhFTikgJ3EnIHByZXNzZWQgLT4gZHVtcGluZyBkb21haW4gaW5mbyAobm93PTB4MzFCOUY6NDY5
QjkyN0YpCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAwOgooWEVOKSAgICAg
cmVmY250PTMgZHlpbmc9MCBwYXVzZV9jb3VudD0wCihYRU4pICAgICBucl9wYWdlcz0xMzEwNzIw
IHhlbmhlYXBfcGFnZXM9NiBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9
ezExLTEyfSBtYXhfcGFnZXM9NDI5NDk2NzI5NQooWEVOKSAgICAgaGFuZGxlPTAwMDAwMDAwLTAw
MDAtMDAwMC0wMDAwLTAwMDAwMDAwMDAwMCB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFuZ2Vz
ZXRzIGJlbG9uZ2luZyB0byBkb21haW4gMDoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyAwLTFmLCAy
Mi0zZiwgNDQtNjAsIDYyLTlmLCBhMi04MDcsIDgwYy1jZmIsIGQwMC1mZmZmIH0KKFhFTikgICAg
IEludGVycnVwdHMgeyAxLTY1IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyAwLWZlZGZmLCBmZWYw
MC1mZmZmZmZmZmZmZmZmZmZmIH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21h
aW4gMDoKKFhFTikgICAgIERvbVBhZ2UgbGlzdCB0b28gbG9uZyB0byBkaXNwbGF5CihYRU4pICAg
ICBYZW5QYWdlIDAwMDAwMDAwMDFmZWZmYmI6IGNhZj1jMDAwMDAwMDAwMDAwMDAyLCB0YWY9NzQw
MDAwMDAwMDAwMDAwMgooWEVOKSAgICAgWGVuUGFnZSAwMDAwMDAwMDAxZmVmZmJhOiBjYWY9YzAw
MDAwMDAwMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIFhlblBhZ2UgMDAw
MDAwMDAwMWZlZmZiOTogY2FmPWMwMDAwMDAwMDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAx
CihYRU4pICAgICBYZW5QYWdlIDAwMDAwMDAwMDFmZWZmYjg6IGNhZj1jMDAwMDAwMDAwMDAwMDAx
LCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgWGVuUGFnZSAwMDAwMDAwMDAwMGJmNTBj
OiBjYWY9YzAwMDAwMDAwMDAwMDAwMiwgdGFmPTc0MDAwMDAwMDAwMDAwMDIKKFhFTikgICAgIFhl
blBhZ2UgMDAwMDAwMDAwMWZjNGZjNDogY2FmPWMwMDAwMDAwMDAwMDAwMDIsIHRhZj03NDAwMDAw
MDAwMDAwMDAyCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiAwOiBbMC0xXQooWEVOKSBW
Q1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAwOgooWEVOKSAgICAgVkNQ
VTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAw
MCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MH0KKFhFTikgICAgIHBhdXNlX2NvdW50PTAg
cGF1c2VfZmxhZ3M9MQooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUx
OiBDUFUxIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezF9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBh
dXNlX2ZsYWdzPTEKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjog
Q1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRp
cnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXsyfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVz
ZV9mbGFncz0xCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQ
VTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0
eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTAgcGF1c2Vf
ZmxhZ3M9MQooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU0OiBDUFU0
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezR9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2Zs
YWdzPTEKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNTogQ1BVNSBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXs1fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFn
cz0xCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTY6IENQVTYgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17Nn0KKFhFTikgICAgIHBhdXNlX2NvdW50PTAgcGF1c2VfZmxhZ3M9
MQooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU3OiBDUFU3IFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezd9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTEK
KFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVODogQ1BVOCBbaGFzPUZd
IHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30g
Y3B1X2FmZmluaXR5PXs4fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFncz0xCihY
RU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTk6IENQVTkgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17OX0KKFhFTikgICAgIHBhdXNlX2NvdW50PTAgcGF1c2VfZmxhZ3M9MQooWEVO
KSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxMDogQ1BVMTAgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MTB9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTEKKFhF
TikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTE6IENQVTExIFtoYXM9VF0g
cG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17MTF9
IGNwdV9hZmZpbml0eT17MTF9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTAK
KFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTI6IENQVTEyIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
MTJ9IGNwdV9hZmZpbml0eT17MTJ9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdz
PTEKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTM6IENQVTEzIFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezEzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFn
cz0xCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE0OiBDUFUxNCBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXsxNH0KKFhFTikgICAgIHBhdXNlX2NvdW50PTAgcGF1c2VfZmxh
Z3M9MQooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxNTogQ1BVMTUg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MTV9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2Zs
YWdzPTEKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRp
b24gZm9yIGRvbWFpbiAxOgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0z
CihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBwYWdl
ZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTEzMTMyOAooWEVOKSAgICAgaGFuZGxl
PTY1ZGFhNmFmLTQ1MDQtNGY3Mi05NWJlLTg4ZjI0MTUxMzExNiB2bV9hc3Npc3Q9MDAwMDAwMGQK
KFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gMToKKFhFTikgICAgIEkvTyBQb3J0
cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0K
KFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gMToKKFhFTikgICAgIERvbVBh
Z2UgMDAwMDAwMDAwMTBhZWVjYzogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQoo
WEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxMGE3ZjkyOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAw
MDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDEwYTdlYzU6IGNhZj0wMDAw
MDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWlu
IDE6IFsxXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAx
OgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwg
dXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikg
ICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGlt
ZXIKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDI6CihYRU4pICAgICByZWZj
bnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9w
YWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFn
ZXM9MzE0NTk4NAooWEVOKSAgICAgaGFuZGxlPWFhMWY2OTY5LWQyNTktNDQyYS05MTVlLWNhMDI3
YWNhZmMwMiB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBk
b21haW4gMjoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsg
fQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0
byBkb21haW4gMjoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMGJiNmMxMDogY2FmPTAwMDAw
MDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwYmI2
MmRkOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdl
IDAwMDAwMDAwMDBiYjVlMTM6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhF
TikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDI6IFswXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9u
IGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAyOgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxh
Z3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU0OiBDUFU0IFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNTogQ1BVNSBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9m
bGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTY6IENQVTYg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU3OiBDUFU3
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3Jt
YXRpb24gZm9yIGRvbWFpbiA0OgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3Vu
dD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBw
YWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTEwNDg4MzIKKFhFTikgICAgIGhh
bmRsZT03NWU0NTEwNi0wNmFjLTQxYTgtYjI5ZS0xNGY0OGJiMDdiMmUgdm1fYXNzaXN0PTAwMDAw
MDA0CihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDQ6CihYRU4pICAgICBJL08g
UG9ydHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkg
eyB9CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDQ6CihYRU4pICAgICBE
b21QYWdlIDAwMDAwMDAwMDBjMmI3ZTY6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAw
MDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMGMyYWEwMzogY2FmPTAwMDAwMDAxLCB0YWY9
NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwY2I4Mzk3OiBjYWY9
MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRv
bWFpbiA0OiBbMF0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21h
aW4gNDoKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDEsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihY
RU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIDEwMCBIeiBwZXJp
b2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9Mgoo
WEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBW
Q1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9
IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291
bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlv
ZCAxMCBtcykKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBw
ZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZv
ciBkb21haW4gNjoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVO
KSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFn
ZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0xMDQ4ODMyCihYRU4pICAgICBoYW5kbGU9MjJk
NGMxOTktYWYyYy00ZDg2LTg3Y2QtYmJlY2NkNTdjMjM4IHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVO
KSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiA2OgooWEVOKSAgICAgSS9PIFBvcnRzICB7
IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVO
KSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiA2OgooWEVOKSAgICAgRG9tUGFnZSAw
MDAwMDAwMDAwZGJmZjE1OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4p
ICAgICBEb21QYWdlIDAwMDAwMDAwMDBkYjU2NTg6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAw
MDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMGRiNTY0YTogY2FmPTAwMDAwMDAx
LCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gNjog
WzBdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDY6CihY
RU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNh
bGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAg
cGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgoo
WEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBj
YWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAg
IHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIK
KFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVw
Y2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAg
ICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVy
CihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1l
cgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gNzoKKFhFTikgICAgIHJlZmNu
dD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3Bh
Z2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdl
cz0xMDQ4ODMyCihYRU4pICAgICBoYW5kbGU9ZjQ1MjFlODAtNTFiYS00NjFmLTliMDgtYmFmNGQ5
NTBhNWNhIHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRv
bWFpbiA3OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9
CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRv
IGRvbWFpbiA3OgooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwZWJmZGI2OiBjYWY9MDAwMDAw
MDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDBlYmZk
YjU6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2Ug
MDAwMDAwMDAwMGViNTY1YzogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVO
KSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gNzogWzBdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24g
YW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDc6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZd
IHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30g
Y3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0w
CihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTQ6IENQVTQgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxh
Z3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU1OiBDUFU1IFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNjogQ1BVNiBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9m
bGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTc6IENQVTcg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgR2VuZXJhbCBpbmZvcm1h
dGlvbiBmb3IgZG9tYWluIDk6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50
PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBh
Z2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9MzE0NTk4NAooWEVOKSAgICAgaGFu
ZGxlPTNhZmYxNGQzLTNlN2ItNGQ3YS1hZjM3LTZhYzJlZGE2OGMyZSB2bV9hc3Npc3Q9MDAwMDAw
MDQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gOToKKFhFTikgICAgIEkvTyBQ
b3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7
IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gOToKKFhFTikgICAgIERv
bVBhZ2UgMDAwMDAwMDAwMTQyN2QxYjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAw
MQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxNDk2NmNhOiBjYWY9MDAwMDAwMDEsIHRhZj03
NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDBmYTQ5ODM6IGNhZj0w
MDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9t
YWluIDk6IFswLTFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9t
YWluIDk6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAxLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQoo
WEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICAxMDAgSHogcGVy
aW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0g
cG9sbD0wIHVwY2FsbF9wZW5kID0gMDEsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBj
cHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAK
KFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAg
VkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sg
PSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2Nv
dW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJp
b2QgMTAgbXMpCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAxLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICAxMDAgSHog
cGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFU0OiBDUFU0IFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDEsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAg
ICAgVkNQVTU6IENQVTUgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMSwgdXBjYWxsX21h
c2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChw
ZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNjogQ1BVNiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxf
cGVuZCA9IDAxLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXsw
LTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICAxMDAg
SHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFU3OiBDUFU3IFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDEsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTAKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVO
KSAgICAgVkNQVTg6IENQVTggW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMSwgdXBjYWxs
X21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBh
dXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVy
IChwZXJpb2QgMTAgbXMpCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAxMDoK
KFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFn
ZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9j
cHVzPXt9IG1heF9wYWdlcz0yMDk3NDA4CihYRU4pICAgICBoYW5kbGU9Nzk3ZTNkNmMtYTU2YS00
NGU0LTk0MTctMjAyYjI5YjJiMzMzIHZtX2Fzc2lzdD0wMDAwMDAwNAooWEVOKSBSYW5nZXNldHMg
YmVsb25naW5nIHRvIGRvbWFpbiAxMDoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAg
ICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBh
Z2VzIGJlbG9uZ2luZyB0byBkb21haW4gMTA6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDBm
ODc0ZTU6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBh
Z2UgMDAwMDAwMDAwMGY4NzRlNDogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQoo
WEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwZmUwMzUyOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAw
MDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiAxMDogWzBdCihYRU4p
IFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDEwOgooWEVOKSAgICAg
VkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMSwgdXBjYWxsX21hc2sg
PSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2Nv
dW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJp
b2QgMTAgbXMpCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHog
cGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAg
ICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21h
c2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChw
ZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxf
cGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXsw
LTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAg
SHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFU1OiBDUFU1IFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVO
KSAgICAgVkNQVTY6IENQVTYgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxs
X21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBh
dXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVy
IChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNzogQ1BVNyBbaGFzPUZdIHBvbGw9MCB1cGNh
bGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5
PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAx
MDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgR2VuZXJhbCBpbmZvcm1h
dGlvbiBmb3IgZG9tYWluIDExOgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3Vu
dD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBw
YWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTUyNDU0NAooWEVOKSAgICAgaGFu
ZGxlPTIwMzgxNmRmLWViZGEtNGU1NS04YWE5LTRhZmIzZGUzNzU1MyB2bV9hc3Npc3Q9MDAwMDAw
MDQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gMTE6CihYRU4pICAgICBJL08g
UG9ydHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkg
eyB9CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDExOgooWEVOKSAgICAg
RG9tUGFnZSAwMDAwMDAwMDAxNDYwNDdiOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAw
MDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDE0ZDcxM2U6IGNhZj0wMDAwMDAwMSwgdGFm
PTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTQyMjIzNDogY2Fm
PTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBk
b21haW4gMTE6IFsxXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRv
bWFpbiAxMToKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDEsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIDEwMCBIeiBw
ZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAg
ICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFz
ayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2Vf
Y291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBl
cmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w
ZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAt
MjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBI
eiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9u
IGZvciBkb21haW4gMTI6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIK
KFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2Vk
X3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9NTI0NTQ0CihYRU4pICAgICBoYW5kbGU9
NzUzN2M3YzAtODEyMS00N2M3LTkwZGYtOTg5MWJmYzZlN2Y2IHZtX2Fzc2lzdD0wMDAwMDAwZgoo
WEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiAxMjoKKFhFTikgICAgIEkvTyBQb3J0
cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0K
KFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gMTI6CihYRU4pICAgICBEb21Q
YWdlIDAwMDAwMDAwMDE1MjVkZDY6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEK
KFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTQ2YzM0YjogY2FmPTAwMDAwMDAxLCB0YWY9NzQw
MDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxNDZiZDljOiBjYWY9MDAw
MDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFp
biAxMjogWzFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWlu
IDEyOgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAw
MSwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhF
TikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlv
ZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihY
RU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZD
UFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9k
IDEwIG1zKQooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBl
cmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9y
IGRvbWFpbiAxNjoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVO
KSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFn
ZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz01MjQ1NDQKKFhFTikgICAgIGhhbmRsZT1mN2Jk
MDliYS01ZDE5LTRlOTQtODI4My1iZDIyMTc0ZjdiZWEgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4p
IFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDE2OgooWEVOKSAgICAgSS9PIFBvcnRzICB7
IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVO
KSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiAxNjoKKFhFTikgICAgIERvbVBhZ2Ug
MDAwMDAwMDAwMTQ0MjI2YjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVO
KSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxNjZmMzM2OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAw
MDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDE2Njg3Zjg6IGNhZj0wMDAwMDAw
MSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDE2
OiBbMV0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gMTY6
CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1l
cgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwg
dXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikg
ICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGlt
ZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAs
IHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4p
ICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRp
bWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAw
LCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVO
KSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0
aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gMTc6CihYRU4pICAgICBy
ZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVh
cF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhf
cGFnZXM9NTI0NTQ0CihYRU4pICAgICBoYW5kbGU9NjI2NWNhZWEtM2YyYi00YmFiLTg3ZGEtZjA0
ZGU3MTM1NDJlIHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRv
IGRvbWFpbiAxNzoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRz
IHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2lu
ZyB0byBkb21haW4gMTc6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDA0Y2NmMjU6IGNhZj0w
MDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAw
MDRlZTM2NDogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9t
UGFnZSAwMDAwMDAwMDAwNDgyOWFmOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAx
CihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiAxNzogWzBdCihYRU4pIFZDUFUgaW5mb3Jt
YXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDE3OgooWEVOKSAgICAgVkNQVTA6IENQVTAg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUx
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BV
MiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5
X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVz
ZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQ
VTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0
eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1
c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgR2VuZXJhbCBpbmZv
cm1hdGlvbiBmb3IgZG9tYWluIDE5OgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9j
b3VudD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9
MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTIwOTc0MDgKKFhFTikgICAg
IGhhbmRsZT0xZTgyYmFlMS0yMjJlLTRiOTAtYmMxZi1mNGI1MDEyZWMzNjAgdm1fYXNzaXN0PTAw
MDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDE5OgooWEVOKSAgICAg
SS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVt
b3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiAxOToKKFhFTikg
ICAgIERvbVBhZ2UgMDAwMDAwMDAwMTZlNWUyNTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAw
MDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxNmNmYzY2OiBjYWY9MDAwMDAwMDEs
IHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDE2Y2ZjM2E6
IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBm
b3IgZG9tYWluIDE5OiBbMC0xXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3Mg
Zm9yIGRvbWFpbiAxOToKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2Fs
bF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9
ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5v
IHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNh
bGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5
PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBO
byBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBj
YWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0
eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAg
Tm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVw
Y2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5p
dHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAg
IE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZdIHBvbGw9MCB1
cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmlu
aXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAg
ICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTU6IENQVTUgW2hhcz1GXSBwb2xsPTAg
dXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZp
bml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAg
ICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU2OiBDUFU2IFtoYXM9Rl0gcG9sbD0w
IHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZm
aW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikg
ICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNzogQ1BVNyBbaGFzPUZdIHBvbGw9
MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2Fm
ZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4p
ICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTg6IENQVTggW2hhcz1GXSBwb2xs
PTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9h
ZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVO
KSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU5OiBDUFU5IFtoYXM9Rl0gcG9s
bD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVf
YWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhF
TikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRv
bWFpbiAyMDoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAg
ICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9
MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz01MjQ1NDQKKFhFTikgICAgIGhhbmRsZT1iZDI0ZDNl
My1kNjg2LTRjZjMtYWMzMi0yMDQzMmZjZWJlMjMgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJh
bmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDIwOgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0K
KFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBN
ZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiAyMDoKKFhFTikgICAgIERvbVBhZ2UgMDAw
MDAwMDAwMTZmMDY4NjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAg
ICAgRG9tUGFnZSAwMDAwMDAwMDAxNzZlZDI4OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAw
MDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDE3NjhlNWU6IGNhZj0wMDAwMDAwMSwg
dGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDIwOiBb
MV0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gMjA6CihY
RU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNh
bGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAg
cGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgoo
WEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBj
YWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAg
IHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIK
KFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVw
Y2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAg
ICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVy
CihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1l
cgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gMjE6CihYRU4pICAgICByZWZj
bnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9w
YWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFn
ZXM9NTI0NTQ0CihYRU4pICAgICBoYW5kbGU9NDUyOGEzYzAtMmQxMi00MTI4LWIzNzktZjliYTkx
N2M0ZGM1IHZtX2Fzc2lzdD0wMDAwMDAwNAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRv
bWFpbiAyMToKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsg
fQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0
byBkb21haW4gMjE6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDA1NzhhNTQ6IGNhZj0wMDAw
MDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDU3
ODUwZTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFn
ZSAwMDAwMDAwMDAwNTc3MGM2OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihY
RU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiAyMTogWzBdCihYRU4pIFZDUFUgaW5mb3JtYXRp
b24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDIxOgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMSwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxh
Z3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4p
ICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxf
bWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1
c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIg
KHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2Fs
bF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9
ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEw
MCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAgVkNQVTM6IENQVTMg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihY
RU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAyMjoKKFhFTikgICAgIHJlZmNudD0x
IGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2Vz
PTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz01
MjQ1NDQKKFhFTikgICAgIGhhbmRsZT0wYTNmZTRhNS04ZDVkLTQ0NzYtODQ0YS1mOGVmY2JiODNl
OTQgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWlu
IDIyOgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihY
RU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRv
bWFpbiAyMjoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTdmMTAzZTogY2FmPTAwMDAwMDAx
LCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxN2U4OTdk
OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAw
MDAwMDAwMDE3ZTg5NDk6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikg
Tk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDIyOiBbMV0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBh
bmQgY2FsbGJhY2tzIGZvciBkb21haW4gMjI6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZd
IHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30g
Y3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0w
CihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9u
IGZvciBkb21haW4gMjM6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIK
KFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2Vk
X3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9MTA0ODgzMgooWEVOKSAgICAgaGFuZGxl
PWQ4OTFmNzIwLTJhNTUtNGE5NC1hYTNhLTlhNDIyNDRlYWM1MCB2bV9hc3Npc3Q9MDAwMDAwMGQK
KFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gMjM6CihYRU4pICAgICBJL08gUG9y
dHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9
CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDIzOgooWEVOKSAgICAgRG9t
UGFnZSAwMDAwMDAwMDAwNWZlYWMxOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAx
CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDA1ZmVhYzA6IGNhZj0wMDAwMDAwMSwgdGFmPTc0
MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDVmNjRhOTogY2FmPTAw
MDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21h
aW4gMjM6IFswXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFp
biAyMzoKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihY
RU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGlj
IHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQoo
WEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2Rp
YyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9k
aWMgdGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlv
ZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJp
b2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTU6IENQVTUgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3Bl
bmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0y
M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVy
aW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU2OiBDUFU2IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w
ZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAt
MjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBl
cmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAyNToKKFhF
TikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9
MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVz
PXt9IG1heF9wYWdlcz0yNjI0MDAKKFhFTikgICAgIGhhbmRsZT0wNzEzY2QxNi00Yjg3LTQzZGUt
YTYzZi1hMWU3MWIzOWZlNjcgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxv
bmdpbmcgdG8gZG9tYWluIDI1OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIElu
dGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMg
YmVsb25naW5nIHRvIGRvbWFpbiAyNToKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTg3MDQ3
MTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAw
MDAwMDAwMDAxODZmNDJjOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4p
ICAgICBEb21QYWdlIDAwMDAwMDAwMDE4Njk4Yjc6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAw
MDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDI1OiBbMV0KKFhFTikgVkNQ
VSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gMjU6CihYRU4pICAgICBWQ1BV
MDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAw
IGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9
MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQ
VTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAw
MCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50
PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZD
UFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBW
Q1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9
IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291
bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5l
cmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gMjY6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0y
IHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJl
ZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9MjYyNDAwCihY
RU4pICAgICBoYW5kbGU9M2JlYTJhNWQtMTg4ZC00ZDQ0LWI0MWItODY0Y2VlNTE3Y2JhIHZtX2Fz
c2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiAyNjoKKFhF
TikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAg
SS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gMjY6
CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDA2M2UwNTI6IGNhZj0wMDAwMDAwMSwgdGFmPTc0
MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDYzNTc2MTogY2FmPTAw
MDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAw
NjM1NmE1OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZm
aW5pdHkgZm9yIGRvbWFpbiAyNjogWzBdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxi
YWNrcyBmb3IgZG9tYWluIDI2OgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAg
dXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZp
bml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAg
ICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9sbD0w
IHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZm
aW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikg
ICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9
MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2Fm
ZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4p
ICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xs
PTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9h
ZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVO
KSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9t
YWluIDI4OgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0yCihYRU4pICAg
ICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0w
IGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTI2MjQwMAooWEVOKSAgICAgaGFuZGxlPThlNTM2M2Fh
LWJlNDEtNDg5MC04NzUwLWIxZThkMjJmOGIzYSB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFu
Z2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gMjg6CihYRU4pICAgICBJL08gUG9ydHMgIHsgfQoo
WEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4pIE1l
bW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDI4OgooWEVOKSAgICAgRG9tUGFnZSAwMDAw
MDAwMDAwNjdkZDU4OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAg
ICBEb21QYWdlIDAwMDAwMDAwMDA2N2RkNTQ6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAw
MDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDY3ZGQwZjogY2FmPTAwMDAwMDAxLCB0
YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gMjg6IFsw
XQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAyODoKKFhF
TikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2Fs
bF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBw
YXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihY
RU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNh
bGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAg
cGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgoo
WEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBj
YWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAg
IHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIK
KFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVw
Y2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAg
ICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVy
CihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAyOToKKFhFTikgICAgIHJlZmNu
dD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3Bh
Z2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdl
cz0zOTM0NzIKKFhFTikgICAgIGhhbmRsZT1kMDQ4NGM5Yi1iZWY0LTQ5MDctOTk0MC0wM2MyODY5
NGM1MDQgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9t
YWluIDI5OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9
CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRv
IGRvbWFpbiAyOToKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDY1YTJmNTogY2FmPTAwMDAw
MDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwNjU5
ZjI0OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdl
IDAwMDAwMDAwMDE4NGJlNmQ6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhF
TikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDI5OiBbMC0xXQooWEVOKSBWQ1BVIGluZm9ybWF0
aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAyOToKKFhFTikgICAgIFZDUFUwOiBDUFUwIFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9m
bGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUz
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNDogQ1BV
NCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5
X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVz
ZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTU6IENQ
VTUgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0
eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1
c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU2OiBD
UFU2IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGly
dHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBh
dXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNzog
Q1BVNyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRp
cnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBw
YXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTg6
IENQVTggW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBk
aXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEg
cGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU5
OiBDUFU5IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0x
IHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BV
MTA6IENQVTEwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBW
Q1BVMTE6IENQVTExIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNr
ID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9j
b3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAg
ICBWQ1BVMTI6IENQVTEyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9t
YXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVz
ZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4p
ICAgICBWQ1BVMTM6IENQVTEzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2Fs
bF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBw
YXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihY
RU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAzMDoKKFhFTikgICAgIHJlZmNudD0x
IGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2Vz
PTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0y
NjI0MDAKKFhFTikgICAgIGhhbmRsZT0wZGQyZjBhMC1jM2UyLTRhNTgtYmVjZS1hMDIxZGQ2ZmEw
YTAgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWlu
IDMwOgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihY
RU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRv
bWFpbiAzMDoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTg0MGNlYzogY2FmPTAwMDAwMDAx
LCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxOGQ5NTBi
OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAw
MDAwMDAwMDE4ZDk1MDA6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikg
Tk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDMwOiBbMV0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBh
bmQgY2FsbGJhY2tzIGZvciBkb21haW4gMzA6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZd
IHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30g
Y3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0w
CihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9u
IGZvciBkb21haW4gMzE6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIK
KFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2Vk
X3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9MjA5NzQwOAooWEVOKSAgICAgaGFuZGxl
PTUyMWJiZjAzLWM0ZmUtNGE0Yi1hMTEyLTFkOTQ1YzdjMmM5MCB2bV9hc3Npc3Q9MDAwMDAwMGQK
KFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gMzE6CihYRU4pICAgICBJL08gUG9y
dHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9
CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDMxOgooWEVOKSAgICAgRG9t
UGFnZSAwMDAwMDAwMDAxOTliYmExOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAx
CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDE5OWJhZTE6IGNhZj0wMDAwMDAwMSwgdGFmPTc0
MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTk5YmFlMDogY2FmPTAw
MDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21h
aW4gMzE6IFsxXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFp
biAzMToKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihY
RU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGlj
IHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQoo
WEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2Rp
YyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9k
aWMgdGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlv
ZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJp
b2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTU6IENQVTUgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3Bl
bmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0y
M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVy
aW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU2OiBDUFU2IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w
ZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAt
MjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBl
cmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAzMjoKKFhF
TikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9
MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVz
PXt9IG1heF9wYWdlcz0yNjI0MDAKKFhFTikgICAgIGhhbmRsZT01MTU1N2ZkMC1mYTMxLTQ0YTIt
OTU2My1kNzk0M2NiOWM3MTkgdm1fYXNzaXN0PTAwMDAwMDBmCihYRU4pIFJhbmdlc2V0cyBiZWxv
bmdpbmcgdG8gZG9tYWluIDMyOgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIElu
dGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMg
YmVsb25naW5nIHRvIGRvbWFpbiAzMjoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDZhMzE0
OTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAw
MDAwMDAwMDAwNmEzMGYzOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4p
ICAgICBEb21QYWdlIDAwMDAwMDAwMDA2YTMwZDY6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAw
MDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDMyOiBbMF0KKFhFTikgVkNQ
VSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gMzI6CihYRU4pICAgICBWQ1BV
MDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAxLCB1cGNhbGxfbWFzayA9IDAx
IGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9
MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAx
MCBtcykKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihY
RU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJp
b2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9Mgoo
WEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBW
Q1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9
IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291
bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlv
ZCAxMCBtcykKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDM1OgooWEVOKSAg
ICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhl
bmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30g
bWF4X3BhZ2VzPTI2MjQwMAooWEVOKSAgICAgaGFuZGxlPWUyOGU1OGZkLWQ5MzctNGZiZC1iYzZk
LWE1ZDY1YWQ0MDU4ZSB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2lu
ZyB0byBkb21haW4gMzU6CihYRU4pICAgICBJL08gUG9ydHMgIHsgfQooWEVOKSAgICAgSW50ZXJy
dXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxv
bmdpbmcgdG8gZG9tYWluIDM1OgooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwNzFjYzE1OiBj
YWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAw
MDAwMDA3MWNiOTE6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAg
IERvbVBhZ2UgMDAwMDAwMDAwMDcxNjQyMTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAw
MDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gMzU6IFswXQooWEVOKSBWQ1BVIGlu
Zm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAzNToKKFhFTikgICAgIFZDUFUwOiBD
UFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGly
dHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBh
dXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTog
Q1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRp
cnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBw
YXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTI6
IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBk
aXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEg
cGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUz
OiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0x
IHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwg
aW5mb3JtYXRpb24gZm9yIGRvbWFpbiAzNjoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1
c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3Bh
Z2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0yNjI0MDAKKFhFTikg
ICAgIGhhbmRsZT00YzA4YjdhMy1iNTU2LTRhNmEtOTFjMi01ZWQzNGIzZmE1NmYgdm1fYXNzaXN0
PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDM2OgooWEVOKSAg
ICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08g
TWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiAzNjoKKFhF
TikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTlkNWNhNTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAw
MDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxOWQ1YjA0OiBjYWY9MDAwMDAw
MDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDE5ZmEy
NWE6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0
eSBmb3IgZG9tYWluIDM2OiBbMV0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tz
IGZvciBkb21haW4gMzY6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNh
bGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5
PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBO
byBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBj
YWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0
eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAg
Tm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVw
Y2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5p
dHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAg
IE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1
cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmlu
aXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAg
ICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4g
Mzc6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5y
X3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGly
dHlfY3B1cz17fSBtYXhfcGFnZXM9MjYyNDAwCihYRU4pICAgICBoYW5kbGU9ODBkYjgyMTQtZmE2
My00MWRmLWE1ODItYWQ4OTYyZmY1NzJiIHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNl
dHMgYmVsb25naW5nIHRvIGRvbWFpbiAzNzoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4p
ICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5
IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gMzc6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAw
MDE5ZjZmZjQ6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERv
bVBhZ2UgMDAwMDAwMDAwMWEyY2E5YTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAw
MQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxYTJjYTk5OiBjYWY9MDAwMDAwMDEsIHRhZj03
NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiAzNzogWzFdCihY
RU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDM3OgooWEVOKSAg
ICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21h
c2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikg
ICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9t
YXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVz
ZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4p
ICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxf
bWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1
c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVO
KSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxs
X21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBh
dXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhF
TikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDM4OgooWEVOKSAgICAgcmVmY250PTEg
ZHlpbmc9MiBwYXVzZV9jb3VudD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9
MCBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTI2
MjQwMAooWEVOKSAgICAgaGFuZGxlPWFiN2FhNWIzLTAzMTEtNDUyNC05YTJiLWNjZGY0ZTY5OGRk
MyB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4g
Mzg6CihYRU4pICAgICBJL08gUG9ydHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhF
TikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9t
YWluIDM4OgooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxYTE2NDE0OiBjYWY9MDAwMDAwMDEs
IHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDFhMGM2Zjg6
IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAw
MDAwMDAwMWEwNDY5YTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBO
T0RFIGFmZmluaXR5IGZvciBkb21haW4gMzg6IFswLTFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24g
YW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDM4OgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxh
Z3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU0OiBDUFU0IFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNTogQ1BVNSBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9m
bGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTY6IENQVTYg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU3OiBDUFU3
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVODogQ1BV
OCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5
X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVz
ZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTk6IENQ
VTkgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0
eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1
c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxMDog
Q1BVMTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBk
aXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEg
cGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUx
MTogQ1BVMTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAw
MCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50
PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZD
UFUxMjogQ1BVMTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sg
PSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2Nv
dW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAg
IFZDUFUxMzogQ1BVMTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21h
c2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikg
R2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDQ0OgooWEVOKSAgICAgcmVmY250PTEgZHlp
bmc9MiBwYXVzZV9jb3VudD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBz
aGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTI2MjQw
MAooWEVOKSAgICAgaGFuZGxlPTkzOGM0YWFiLWI2ZGMtNGExOC1hMWIzLTQ3MzUwMmEzYTgwYiB2
bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gNDQ6
CihYRU4pICAgICBJL08gUG9ydHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikg
ICAgIEkvTyBNZW1vcnkgeyB9CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWlu
IDQ0OgooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwN2Q5YjZjOiBjYWY9MDAwMDAwMDEsIHRh
Zj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDA3ZDg0MzY6IGNh
Zj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAw
MDAwMDdkODQzNDogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RF
IGFmZmluaXR5IGZvciBkb21haW4gNDQ6IFswXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBj
YWxsYmFja3MgZm9yIGRvbWFpbiA0NDoKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9s
bD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVf
YWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhF
TikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihY
RU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAoo
WEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3Ig
ZG9tYWluIDQ1OgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0yCihYRU4p
ICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdl
cz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTEzMTMyOAooWEVOKSAgICAgaGFuZGxlPTg1NmIy
OTI5LWRiNTAtNDI5ZC05NjVmLTU5MTMyODY4ZjhjNiB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikg
UmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gNDU6CihYRU4pICAgICBJL08gUG9ydHMgIHsg
fQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4p
IE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDQ1OgooWEVOKSAgICAgRG9tUGFnZSAw
MDAwMDAwMDAxYTVjNzIwOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4p
ICAgICBEb21QYWdlIDAwMDAwMDAwMDFiMDFiNWM6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAw
MDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWIwMWI1YjogY2FmPTAwMDAwMDAx
LCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gNDU6
IFsxXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiA0NToK
KFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVw
Y2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAg
ICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVy
CihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1l
cgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwg
dXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikg
ICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGlt
ZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAs
IHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4p
ICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRp
bWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiA0NjoKKFhFTikgICAgIHJl
ZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFw
X3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9w
YWdlcz0zOTM0NzIKKFhFTikgICAgIGhhbmRsZT01MDJiOTUxMC1jMmU5LTQ4N2QtYTYxYi1iMjll
ZTYwYjk4NTYgdm1fYXNzaXN0PTAwMDAwMDA0CihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8g
ZG9tYWluIDQ2OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMg
eyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5n
IHRvIGRvbWFpbiA0NjoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWIxMjRmMjogY2FmPTAw
MDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAx
YjExZWQxOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21Q
YWdlIDAwMDAwMDAwMDA3YzRhOGQ6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEK
KFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDQ2OiBbMC0xXQooWEVOKSBWQ1BVIGluZm9y
bWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiA0NjoKKFhFTikgICAgIFZDUFUwOiBDUFUw
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDEsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTAKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQoo
WEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBj
YWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAg
IHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRp
bWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1
cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmlu
aXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAg
ICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUzOiBD
UFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGly
dHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBh
dXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1z
KQooWEVOKSAgICAgVkNQVTQ6IENQVTQgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwg
dXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikg
ICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGlj
IHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNTogQ1BVNSBbaGFzPUZdIHBvbGw9
MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2Fm
ZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4p
ICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFU2
OiBDUFU2IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0x
IHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEw
IG1zKQooWEVOKSAgICAgVkNQVTc6IENQVTcgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAw
MCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhF
TikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlv
ZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVODogQ1BVOCBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihY
RU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZD
UFU5OiBDUFU5IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9k
IDEwIG1zKQooWEVOKSAgICAgVkNQVTEwOiBDUFUxMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHog
cGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUxMTogQ1BVMTEgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxh
Z3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4p
ICAgICBWQ1BVMTI6IENQVTEyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDEsIHVwY2Fs
bF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBw
YXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1l
ciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAgVkNQVTEzOiBDUFUxMyBbaGFzPUZdIHBvbGw9MCB1
cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmlu
aXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAg
ICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgR2VuZXJhbCBpbmZv
cm1hdGlvbiBmb3IgZG9tYWluIDQ3OgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9j
b3VudD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9
MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTEzMTMyOAooWEVOKSAgICAg
aGFuZGxlPTQ1Njg5OTg1LTAxNGEtNGVhMC04ODZlLWE3N2U3ZDAwYzIwOSB2bV9hc3Npc3Q9MDAw
MDAwMGQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gNDc6CihYRU4pICAgICBJ
L08gUG9ydHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1v
cnkgeyB9CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDQ3OgooWEVOKSAg
ICAgRG9tUGFnZSAwMDAwMDAwMDAwN2JkOWY0OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAw
MDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDA3YmU3ODk6IGNhZj0wMDAwMDAwMSwg
dGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDdiZTc4ODog
Y2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZv
ciBkb21haW4gNDc6IFswXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9y
IGRvbWFpbiA0NzoKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w
ZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAt
MjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBl
cmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxf
cGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXsw
LTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBw
ZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxs
X3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17
MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8g
cGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2Fs
bF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9
ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5v
IHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiA0ODoK
KFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFn
ZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9j
cHVzPXt9IG1heF9wYWdlcz0xMzEzMjgKKFhFTikgICAgIGhhbmRsZT04N2U2Y2U5ZC03NGMwLTRl
YzItYjFjMS01NTNkNWYxNjdhYzEgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBi
ZWxvbmdpbmcgdG8gZG9tYWluIDQ4OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAg
IEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFn
ZXMgYmVsb25naW5nIHRvIGRvbWFpbiA0ODoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWIy
MGIwYjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFn
ZSAwMDAwMDAwMDAxYjIwYjBhOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihY
RU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDFhZmIzZmQ6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAw
MDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDQ4OiBbMV0KKFhFTikg
VkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gNDg6CihYRU4pICAgICBW
Q1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9
IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291
bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAg
VkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sg
PSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2Nv
dW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAg
IFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNr
ID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9j
b3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAg
ICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFz
ayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2Vf
Y291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBH
ZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gNTA6CihYRU4pICAgICByZWZjbnQ9MSBkeWlu
Zz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNo
YXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9NTI0NTQ0
CihYRU4pICAgICBoYW5kbGU9OWZjZGQ2NTAtM2IwMS00YjYxLTg4OWItMDViMWQzZDExZTQ1IHZt
X2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiA1MDoK
KFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAg
ICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4g
NTA6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDFhODhkNDc6IGNhZj0wMDAwMDAwMSwgdGFm
PTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWE4OGQ0NjogY2Fm
PTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAw
MDAxYTlmNDg4OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUg
YWZmaW5pdHkgZm9yIGRvbWFpbiA1MDogWzFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNh
bGxiYWNrcyBmb3IgZG9tYWluIDUwOgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xs
PTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9h
ZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVO
KSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9s
bD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVf
YWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhF
TikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihY
RU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAoo
WEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU0OiBDUFU0IFtoYXM9Rl0g
cG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBj
cHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAK
KFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9y
IGRvbWFpbiA1MToKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVO
KSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFn
ZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0yNjI0MDAKKFhFTikgICAgIGhhbmRsZT0xNDMx
YTE0OC1iNjk2LTQ0Y2ItOTJmYS01YTJkYjVjMDBlMjIgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4p
IFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDUxOgooWEVOKSAgICAgSS9PIFBvcnRzICB7
IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVO
KSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiA1MToKKFhFTikgICAgIERvbVBhZ2Ug
MDAwMDAwMDAwMWE5YzQ0MjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVO
KSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwMjIzMWI4OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAw
MDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDAyMjFkYzU6IGNhZj0wMDAwMDAw
MSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDUx
OiBbMC0xXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiA1
MToKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAs
IHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4p
ICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRp
bWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAw
LCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVO
KSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0
aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAw
MCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhF
TikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMg
dGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihY
RU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGlj
IHRpbWVyCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQoo
WEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2Rp
YyB0aW1lcgooWEVOKSAgICAgVkNQVTU6IENQVTUgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9k
aWMgdGltZXIKKFhFTikgICAgIFZDUFU2OiBDUFU2IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlv
ZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNzogQ1BVNyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJp
b2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTg6IENQVTggW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3Bl
bmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0y
M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVy
aW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU5OiBDUFU5IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w
ZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAt
MjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBl
cmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTA6IENQVTEwIFtoYXM9Rl0gcG9sbD0wIHVwY2Fs
bF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9
ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5v
IHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTE6IENQVTExIFtoYXM9Rl0gcG9sbD0wIHVw
Y2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5p
dHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAg
IE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTI6IENQVTEyIFtoYXM9Rl0gcG9sbD0w
IHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZm
aW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikg
ICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTM6IENQVTEzIFtoYXM9Rl0gcG9s
bD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVf
YWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhF
TikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRv
bWFpbiA1NDoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAg
ICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9
MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0yNjI0MDAKKFhFTikgICAgIGhhbmRsZT1kMTkzMGU5
MS04NWU1LTRhNDEtYjM0NS01NzUxY2MxN2IxMzIgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJh
bmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDU0OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0K
KFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBN
ZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiA1NDoKKFhFTikgICAgIERvbVBhZ2UgMDAw
MDAwMDAwMDIxZjM3YzogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAg
ICAgRG9tUGFnZSAwMDAwMDAwMDAwMjFjODg1OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAw
MDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDAyMDhhNDI6IGNhZj0wMDAwMDAwMSwg
dGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDU0OiBb
MF0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gNTQ6CihY
RU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNh
bGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAg
cGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgoo
WEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBj
YWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAg
IHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIK
KFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVw
Y2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAg
ICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVy
CihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiA1NToKKFhFTikgICAgIHJlZmNu
dD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3Bh
Z2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdl
cz0xMzEzMjgKKFhFTikgICAgIGhhbmRsZT0yMjUzNzViNC1kODAwLTRjYTEtYmU3Ni1jYmVkZDI1
MmQ0Y2Mgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9t
YWluIDU1OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9
CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRv
IGRvbWFpbiA1NToKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDIwOTNhYTogY2FmPTAwMDAw
MDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwMjU5
ODk2OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdl
IDAwMDAwMDAwMDAyNTk4OTU6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhF
TikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDU1OiBbMF0KKFhFTikgVkNQVSBpbmZvcm1hdGlv
biBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gNTU6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxh
Z3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9m
bGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0
aW9uIGZvciBkb21haW4gNTc6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50
PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBh
Z2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9MTMxMzI4CihYRU4pICAgICBoYW5k
bGU9MTI1Mzk4MDEtNjliZC00NzU4LWE5ODgtYmZhMDc3MjViMGFkIHZtX2Fzc2lzdD0wMDAwMDAw
ZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiA1NzoKKFhFTikgICAgIEkvTyBQ
b3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7
IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gNTc6CihYRU4pICAgICBE
b21QYWdlIDAwMDAwMDAwMDFjMzUxYjk6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAw
MDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWMzNGZlOTogY2FmPTAwMDAwMDAxLCB0YWY9
NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxYzI3N2I1OiBjYWY9
MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRv
bWFpbiA1NzogWzFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9t
YWluIDU3OgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9k
aWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlv
ZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJp
b2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3Bl
bmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0y
M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVy
aW9kaWMgdGltZXIKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDU4OgooWEVO
KSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0yCihYRU4pICAgICBucl9wYWdlcz0z
IHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9
e30gbWF4X3BhZ2VzPTEzMTMyOAooWEVOKSAgICAgaGFuZGxlPWQzOGQ0NmFhLTc3ZGUtNDZlMy05
ZWZlLTE2MzI1NzIzMzVmMyB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFuZ2VzZXRzIGJlbG9u
Z2luZyB0byBkb21haW4gNTg6CihYRU4pICAgICBJL08gUG9ydHMgIHsgfQooWEVOKSAgICAgSW50
ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4pIE1lbW9yeSBwYWdlcyBi
ZWxvbmdpbmcgdG8gZG9tYWluIDU4OgooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwMmIzNjhl
OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAw
MDAwMDAwMDAyNDlmMTk6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikg
ICAgIERvbVBhZ2UgMDAwMDAwMDAwMDI0OWYxODogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAw
MDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gNTg6IFswXQooWEVOKSBWQ1BV
IGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiA1ODoKKFhFTikgICAgIFZDUFUw
OiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0x
IHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BV
MTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAw
IGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9
MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQ
VTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAw
MCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50
PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZD
UFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVy
YWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiA2NDoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIg
cGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVk
X3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0xMDQ4ODMyCihY
RU4pICAgICBoYW5kbGU9ZTU5NmI4MmQtMjk3Yy00NjIzLTk3NWItYWRkNGY1YWMyMTAzIHZtX2Fz
c2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiA2NDoKKFhF
TikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAg
SS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gNjQ6
CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDFjMjNjZjE6IGNhZj0wMDAwMDAwMSwgdGFmPTc0
MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWM1ODY2NTogY2FmPTAw
MDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAx
YzU4NjY0OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZm
aW5pdHkgZm9yIGRvbWFpbiA2NDogWzFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxi
YWNrcyBmb3IgZG9tYWluIDY0OgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAg
dXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZp
bml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAg
ICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9sbD0w
IHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZm
aW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikg
ICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9
MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2Fm
ZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4p
ICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xs
PTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9h
ZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVO
KSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU0OiBDUFU0IFtoYXM9Rl0gcG9s
bD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVf
YWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhF
TikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNTogQ1BVNSBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihY
RU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTY6IENQVTYgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAoo
WEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3Ig
ZG9tYWluIDY1OgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0yCihYRU4p
ICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdl
cz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTI2MjQwMAooWEVOKSAgICAgaGFuZGxlPTBjMmVi
ZjVhLTk2ZjUtNGFjOS1iYzIwLWEyY2M4YmZjZDk3NiB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikg
UmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gNjU6CihYRU4pICAgICBJL08gUG9ydHMgIHsg
fQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4p
IE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDY1OgooWEVOKSAgICAgRG9tUGFnZSAw
MDAwMDAwMDAwN2FkZGE0OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4p
ICAgICBEb21QYWdlIDAwMDAwMDAwMDA2ZTdiNjg6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAw
MDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDZlN2I2NzogY2FmPTAwMDAwMDAx
LCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gNjU6
IFswXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiA2NToK
KFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVw
Y2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAg
ICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVy
CihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1l
cgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwg
dXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikg
ICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGlt
ZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAs
IHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4p
ICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRp
bWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiA2NzoKKFhFTikgICAgIHJl
ZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFw
X3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9w
YWdlcz0yMDk3NDA4CihYRU4pICAgICBoYW5kbGU9NDMzMDBiODgtZDI4MS00YjRlLTg1NzgtYjcx
OTE0MDYyMjM4IHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRv
IGRvbWFpbiA2NzoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRz
IHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2lu
ZyB0byBkb21haW4gNjc6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDEyOWRiMTU6IGNhZj0w
MDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAw
MTI5Y2I4NjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9t
UGFnZSAwMDAwMDAwMDAxMjljYjg1OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAx
CihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiA2NzogWzFdCihYRU4pIFZDUFUgaW5mb3Jt
YXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDY3OgooWEVOKSAgICAgVkNQVTA6IENQVTAg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUx
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BV
MiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5
X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVz
ZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQ
VTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0
eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1
c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU0OiBD
UFU0IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGly
dHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBh
dXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNTog
Q1BVNSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRp
cnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBw
YXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTY6
IENQVTYgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBk
aXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEg
cGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU3
OiBDUFU3IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0x
IHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwg
aW5mb3JtYXRpb24gZm9yIGRvbWFpbiA2OToKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1
c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3Bh
Z2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0yNjI0MDAKKFhFTikg
ICAgIGhhbmRsZT0yOTZlZDg2Yi0zNGQ5LTQyZWUtYWY5Zi01MWZhMGNhZjU3NWIgdm1fYXNzaXN0
PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDY5OgooWEVOKSAg
ICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08g
TWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiA2OToKKFhF
TikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWM2ZWI0NDogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAw
MDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxMmNiNWQwOiBjYWY9MDAwMDAw
MDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDEyY2I1
Y2Y6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0
eSBmb3IgZG9tYWluIDY5OiBbMV0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tz
IGZvciBkb21haW4gNjk6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNh
bGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5
PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBO
byBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBj
YWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0
eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAg
Tm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVw
Y2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5p
dHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTEKKFhFTikgICAg
IE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1
cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmlu
aXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAg
ICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4g
NzE6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5y
X3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGly
dHlfY3B1cz17fSBtYXhfcGFnZXM9MTk2ODY0CihYRU4pICAgICBoYW5kbGU9MWE3NTAwZTgtZjA3
ZS00MzM1LThlZWUtNjM2YWI5NDBkODQyIHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNl
dHMgYmVsb25naW5nIHRvIGRvbWFpbiA3MToKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4p
ICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5
IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gNzE6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAw
MDA3OGZlZTE6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERv
bVBhZ2UgMDAwMDAwMDAwMDdmNTk0NDogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAw
MQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwMmEwYzQ5OiBjYWY9MDAwMDAwMDEsIHRhZj03
NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiA3MTogWzBdCihY
RU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDcxOgooWEVOKSAg
ICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21h
c2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikg
ICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9t
YXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVz
ZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4p
IEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiA3MjoKKFhFTikgICAgIHJlZmNudD0xIGR5
aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAg
c2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz03ODY2
ODgKKFhFTikgICAgIGhhbmRsZT0yMWFhYzBmOS0zMmM1LTQ3YmItYjBhNS0zYWQ2Yzk0YWFmOTIg
dm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDcy
OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4p
ICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFp
biA3MjoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMGY0ZWYzMjogY2FmPTAwMDAwMDAxLCB0
YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwMmU4ZWJjOiBj
YWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAw
MDAwMDAyZThlYmI6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9E
RSBhZmZpbml0eSBmb3IgZG9tYWluIDcyOiBbMF0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQg
Y2FsbGJhY2tzIGZvciBkb21haW4gNzI6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihY
RU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAoo
WEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0g
cG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBj
cHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAK
KFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZd
IHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30g
Y3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0w
CihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTQ6IENQVTQgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU1OiBDUFU1IFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24g
Zm9yIGRvbWFpbiA3MzoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9Mgoo
WEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRf
cGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0yMDk3NDA4CihYRU4pICAgICBoYW5kbGU9
NzE4NzRlMDAtMTI5ZS00YTQ5LWExNGUtYmVkODNkYzNjNDNhIHZtX2Fzc2lzdD0wMDAwMDAwNAoo
WEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiA3MzoKKFhFTikgICAgIEkvTyBQb3J0
cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0K
KFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gNzM6CihYRU4pICAgICBEb21Q
YWdlIDAwMDAwMDAwMDExOTM2YTU6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEK
KFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTE5MzY3ZDogY2FmPTAwMDAwMDAxLCB0YWY9NzQw
MDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxMTkyMGQ5OiBjYWY9MDAw
MDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFp
biA3MzogWzFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWlu
IDczOgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAw
MSwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhF
TikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlv
ZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihY
RU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZD
UFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9k
IDEwIG1zKQooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBl
cmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZd
IHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30g
Y3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0y
CihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAg
IFZDUFU1OiBDUFU1IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNr
ID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9j
b3VudD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVy
aW9kIDEwIG1zKQooWEVOKSAgICAgVkNQVTY6IENQVTYgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3Bl
bmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0y
M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6
IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNzogQ1BVNyBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0yCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikg
R2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDc4OgooWEVOKSAgICAgcmVmY250PTEgZHlp
bmc9MiBwYXVzZV9jb3VudD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBz
aGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTIwOTc0
MDgKKFhFTikgICAgIGhhbmRsZT1hYzVlMmIwNi03ODk4LTRjMzgtODEwMi0zMjY0NWI5YjZmZjMg
dm1fYXNzaXN0PTAwMDAwMDA0CihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDc4
OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4p
ICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFp
biA3ODoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWQ0ZDk3MTogY2FmPTAwMDAwMDAxLCB0
YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwMzk0ZGIxOiBj
YWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAw
MDAwMDFkNGNmNTA6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9E
RSBhZmZpbml0eSBmb3IgZG9tYWluIDc4OiBbMC0xXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFu
ZCBjYWxsYmFja3MgZm9yIGRvbWFpbiA3ODoKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0g
cG9sbD0wIHVwY2FsbF9wZW5kID0gMDEsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBj
cHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAK
KFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAg
VkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sg
PSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2Nv
dW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJp
b2QgMTAgbXMpCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHog
cGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAg
ICAgVkNQVTQ6IENQVTQgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21h
c2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChw
ZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNTogQ1BVNSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxf
cGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXsw
LTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAg
SHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFU2OiBDUFU2IFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVO
KSAgICAgVkNQVTc6IENQVTcgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxs
X21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBh
dXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVy
IChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVODogQ1BVOCBbaGFzPUZdIHBvbGw9MCB1cGNh
bGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5
PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAx
MDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFU5OiBDUFU5
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQoo
WEVOKSAgICAgVkNQVTEwOiBDUFUxMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMg
dGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUxMTogQ1BVMTEgW2hhcz1GXSBwb2xs
PTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9h
ZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVO
KSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BV
MTI6IENQVTEyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9k
IDEwIG1zKQooWEVOKSAgICAgVkNQVTEzOiBDUFUxMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHog
cGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBm
b3IgZG9tYWluIDgwOgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0yCihY
RU4pICAgICBucl9wYWdlcz0zNSB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRf
cGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0xMDQ4ODMyCihYRU4pICAgICBoYW5kbGU9
NmNkOTE2ODQtZGM1OC00MGQ2LTg5MTItNTk1ZjkwODdkNjhhIHZtX2Fzc2lzdD0wMDAwMDAwZAoo
WEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiA4MDoKKFhFTikgICAgIEkvTyBQb3J0
cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0K
KFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gODA6CihYRU4pICAgICBEb21Q
YWdlIGxpc3QgdG9vIGxvbmcgdG8gZGlzcGxheQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21h
aW4gODA6IFsxXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFp
biA4MDoKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihY
RU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGlj
IHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQoo
WEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2Rp
YyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTAgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9k
aWMgdGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlv
ZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJp
b2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTU6IENQVTUgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3Bl
bmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0y
M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTAgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVy
aW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU2OiBDUFU2IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w
ZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAt
MjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBl
cmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNzogQ1BVNyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxf
cGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXsw
LTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBw
ZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gODE6CihY
RU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2Vz
PTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1
cz17fSBtYXhfcGFnZXM9MjYyNDAwCihYRU4pICAgICBoYW5kbGU9OTAwNmVmZDQtMDRmOC00M2Ex
LTg2YTctMjMwYTIyYTY5YWVmIHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVs
b25naW5nIHRvIGRvbWFpbiA4MToKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJ
bnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2Vz
IGJlbG9uZ2luZyB0byBkb21haW4gODE6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDBlZDNk
MTI6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2Ug
MDAwMDAwMDAwMDY5MDRmYjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVO
KSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxMjFhNDI3OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAw
MDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiA4MTogWzAtMV0KKFhFTikg
VkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gODE6CihYRU4pICAgICBW
Q1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9
IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291
bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAg
VkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sg
PSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2Nv
dW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAg
IFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNr
ID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9j
b3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAg
ICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFz
ayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2Vf
Y291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAg
ICAgVkNQVTQ6IENQVTQgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21h
c2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikg
ICAgIFZDUFU1OiBDUFU1IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9t
YXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVz
ZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4p
ICAgICBWQ1BVNjogQ1BVNiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxf
bWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1
c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVO
KSAgICAgVkNQVTc6IENQVTcgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxs
X21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBh
dXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhF
TikgICAgIFZDUFU4OiBDUFU4IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2Fs
bF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBw
YXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihY
RU4pICAgICBWQ1BVOTogQ1BVOSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNh
bGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAg
cGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgoo
WEVOKSAgICAgVkNQVTEwOiBDUFUxMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1l
cgooWEVOKSAgICAgVkNQVTExOiBDUFUxMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAw
LCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVO
KSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0
aW1lcgooWEVOKSAgICAgVkNQVTEyOiBDUFUxMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQoo
WEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2Rp
YyB0aW1lcgooWEVOKSAgICAgVkNQVTEzOiBDUFUxMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJp
b2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gODI6CihYRU4p
ICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMg
eGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17
fSBtYXhfcGFnZXM9MTMxMzI4CihYRU4pICAgICBoYW5kbGU9YjgwZmI2OTgtY2ViNC00ZTY5LWE3
NzEtMTMxMmI0YjhkZTU3IHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25n
aW5nIHRvIGRvbWFpbiA4MjoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRl
cnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJl
bG9uZ2luZyB0byBkb21haW4gODI6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDBlOTM0N2Q6
IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAw
MDAwMDAwMDc2NTRkZDogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAg
ICAgRG9tUGFnZSAwMDAwMDAwMDAwNDRjYmEyOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAw
MDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiA4MjogWzBdCihYRU4pIFZDUFUg
aW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDgyOgooWEVOKSAgICAgVkNQVTA6
IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBk
aXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEg
cGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUx
OiBDUFUxIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0x
IHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BV
MjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAw
IGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9
MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQ
VTM6IENQVTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAw
MCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50
PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgTm90aWZ5
aW5nIGd1ZXN0IDA6MCAodmlycSAxLCBwb3J0IDQpCihYRU4pIE5vdGlmeWluZyBndWVzdCAwOjEg
KHZpcnEgMSwgcG9ydCAxMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDA6MiAodmlycSAxLCBwb3J0
IDE2KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMDozICh2aXJxIDEsIHBvcnQgMjIpCihYRU4pIE5v
dGlmeWluZyBndWVzdCAwOjQgKHZpcnEgMSwgcG9ydCAyOCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0
IDA6NSAodmlycSAxLCBwb3J0IDM0KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMDo2ICh2aXJxIDEs
IHBvcnQgNDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAwOjcgKHZpcnEgMSwgcG9ydCA0NikKKFhF
TikgTm90aWZ5aW5nIGd1ZXN0IDA6OCAodmlycSAxLCBwb3J0IDUyKQooWEVOKSBOb3RpZnlpbmcg
Z3Vlc3QgMDo5ICh2aXJxIDEsIHBvcnQgNTgpCihYRU4pIE5vdGlmeWluZyBndWVzdCAwOjEwICh2
aXJxIDEsIHBvcnQgNjQpCihYRU4pIE5vdGlmeWluZyBndWVzdCAwOjExICh2aXJxIDEsIHBvcnQg
NzApCihYRU4pIE5vdGlmeWluZyBndWVzdCAwOjEyICh2aXJxIDEsIHBvcnQgNzYpCihYRU4pIE5v
dGlmeWluZyBndWVzdCAwOjEzICh2aXJxIDEsIHBvcnQgODIpCihYRU4pIE5vdGlmeWluZyBndWVz
dCAwOjE0ICh2aXJxIDEsIHBvcnQgODgpCihYRU4pIE5vdGlmeWluZyBndWVzdCAwOjE1ICh2aXJx
IDEsIHBvcnQgOTQpCihYRU4pIE5vdGlmeWluZyBndWVzdCAxOjAgKHZpcnEgMSwgcG9ydCAwKQoo
WEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDI6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyOjIgKHZp
cnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjozICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI6NCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWlu
ZyBndWVzdCAyOjUgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjo2ICh2
aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI6NyAodmlycSAxLCBwb3J0IDAp
CihYRU4pIE5vdGlmeWluZyBndWVzdCA0OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgNDoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDQ6MiAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA0OjMgKHZpcnEgMSwgcG9ydCAw
KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5
aW5nIGd1ZXN0IDY6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA2OjIg
KHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjozICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDc6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlm
eWluZyBndWVzdCA3OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzoy
ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDc6MyAodmlycSAxLCBwb3J0
IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3OjQgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgNzo1ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDc6
NiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3OjcgKHZpcnEgMSwgcG9y
dCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgOTowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90
aWZ5aW5nIGd1ZXN0IDk6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA5
OjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgOTozICh2aXJxIDEsIHBv
cnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDk6NCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5v
dGlmeWluZyBndWVzdCA5OjUgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3Qg
OTo2ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDk6NyAodmlycSAxLCBw
b3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA5OjggKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBO
b3RpZnlpbmcgZ3Vlc3QgMTA6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVz
dCAxMDoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDEwOjIgKHZpcnEg
MSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTA6MyAodmlycSAxLCBwb3J0IDApCihY
RU4pIE5vdGlmeWluZyBndWVzdCAxMDo0ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDEwOjUgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTA6NiAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAxMDo3ICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDExOjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgMTE6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAx
MToyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDExOjMgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTI6MCAodmlycSAxLCBwb3J0IDApCihYRU4p
IE5vdGlmeWluZyBndWVzdCAxMjoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1
ZXN0IDEyOjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTI6MyAodmly
cSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAxNjowICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDE2OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgMTY6MiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAxNjoz
ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDE3OjAgKHZpcnEgMSwgcG9y
dCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTc6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5v
dGlmeWluZyBndWVzdCAxNzoyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0
IDE3OjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTk6MCAodmlycSAx
LCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAxOToxICh2aXJxIDEsIHBvcnQgMCkKKFhF
TikgTm90aWZ5aW5nIGd1ZXN0IDE5OjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcg
Z3Vlc3QgMTk6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAxOTo0ICh2
aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDE5OjUgKHZpcnEgMSwgcG9ydCAw
KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTk6NiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlm
eWluZyBndWVzdCAxOTo3ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDE5
OjggKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTk6OSAodmlycSAxLCBw
b3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyMDowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikg
Tm90aWZ5aW5nIGd1ZXN0IDIwOjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vl
c3QgMjA6MiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyMDozICh2aXJx
IDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDIxOjAgKHZpcnEgMSwgcG9ydCAwKQoo
WEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjE6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWlu
ZyBndWVzdCAyMToyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDIxOjMg
KHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjI6MCAodmlycSAxLCBwb3J0
IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyMjoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90
aWZ5aW5nIGd1ZXN0IDIyOjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3Qg
MjI6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyMzowICh2aXJxIDEs
IHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDIzOjEgKHZpcnEgMSwgcG9ydCAwKQooWEVO
KSBOb3RpZnlpbmcgZ3Vlc3QgMjM6MiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBn
dWVzdCAyMzozICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDIzOjQgKHZp
cnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjM6NSAodmlycSAxLCBwb3J0IDAp
CihYRU4pIE5vdGlmeWluZyBndWVzdCAyMzo2ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5
aW5nIGd1ZXN0IDI1OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjU6
MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyNToyICh2aXJxIDEsIHBv
cnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI1OjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBO
b3RpZnlpbmcgZ3Vlc3QgMjY6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVz
dCAyNjoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI2OjIgKHZpcnEg
MSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjY6MyAodmlycSAxLCBwb3J0IDApCihY
RU4pIE5vdGlmeWluZyBndWVzdCAyODowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDI4OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjg6MiAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyODozICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI5OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgMjk6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAy
OToyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI5OjMgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjk6NCAodmlycSAxLCBwb3J0IDApCihYRU4p
IE5vdGlmeWluZyBndWVzdCAyOTo1ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1
ZXN0IDI5OjYgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjk6NyAodmly
cSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyOTo4ICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI5OjkgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgMjk6MTAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjk6
MTEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjk6MTIgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjk6MTMgKHZpcnEgMSwgcG9ydCAwKQooWEVO
KSBOb3RpZnlpbmcgZ3Vlc3QgMzA6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBn
dWVzdCAzMDoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDMwOjIgKHZp
cnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzA6MyAodmlycSAxLCBwb3J0IDAp
CihYRU4pIE5vdGlmeWluZyBndWVzdCAzMTowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5
aW5nIGd1ZXN0IDMxOjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzE6
MiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzMTozICh2aXJxIDEsIHBv
cnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDMxOjQgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBO
b3RpZnlpbmcgZ3Vlc3QgMzE6NSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVz
dCAzMTo2ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDMyOjAgKHZpcnEg
MSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzI6MSAodmlycSAxLCBwb3J0IDApCihY
RU4pIE5vdGlmeWluZyBndWVzdCAzMjoyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDMyOjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzU6MCAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzNToxICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDM1OjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgMzU6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAz
NjowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDM2OjEgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzY6MiAodmlycSAxLCBwb3J0IDApCihYRU4p
IE5vdGlmeWluZyBndWVzdCAzNjozICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1
ZXN0IDM3OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzc6MSAodmly
cSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzNzoyICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDM3OjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgMzg6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzODox
ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDM4OjIgKHZpcnEgMSwgcG9y
dCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzg6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5v
dGlmeWluZyBndWVzdCAzODo0ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0
IDM4OjUgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzg6NiAodmlycSAx
LCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzODo3ICh2aXJxIDEsIHBvcnQgMCkKKFhF
TikgTm90aWZ5aW5nIGd1ZXN0IDM4OjggKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcg
Z3Vlc3QgMzg6OSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzODoxMCAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzODoxMSAodmlycSAxLCBwb3J0
IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzODoxMiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5v
dGlmeWluZyBndWVzdCAzODoxMyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVz
dCA0NDowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDQ0OjEgKHZpcnEg
MSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDQ6MiAodmlycSAxLCBwb3J0IDApCihY
RU4pIE5vdGlmeWluZyBndWVzdCA0NTowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDQ1OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDU6MiAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA0NTozICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDQ2OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgNDY6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA0
NjoyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDQ2OjMgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDY6NCAodmlycSAxLCBwb3J0IDApCihYRU4p
IE5vdGlmeWluZyBndWVzdCA0Njo1ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1
ZXN0IDQ2OjYgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDY6NyAodmly
cSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA0Njo4ICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDQ2OjkgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgNDY6MTAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDY6
MTEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDY6MTIgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDY6MTMgKHZpcnEgMSwgcG9ydCAwKQooWEVO
KSBOb3RpZnlpbmcgZ3Vlc3QgNDc6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBn
dWVzdCA0NzoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDQ3OjIgKHZp
cnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDc6MyAodmlycSAxLCBwb3J0IDAp
CihYRU4pIE5vdGlmeWluZyBndWVzdCA0ODowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5
aW5nIGd1ZXN0IDQ4OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDg6
MiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA0ODozICh2aXJxIDEsIHBv
cnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUwOjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBO
b3RpZnlpbmcgZ3Vlc3QgNTA6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVz
dCA1MDoyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUwOjMgKHZpcnEg
MSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNTA6NCAodmlycSAxLCBwb3J0IDApCihY
RU4pIE5vdGlmeWluZyBndWVzdCA1MTowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDUxOjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNTE6MiAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA1MTozICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUxOjQgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgNTE6NSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA1
MTo2ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUxOjcgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNTE6OCAodmlycSAxLCBwb3J0IDApCihYRU4p
IE5vdGlmeWluZyBndWVzdCA1MTo5ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1
ZXN0IDUxOjEwICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUxOjExICh2
aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUxOjEyICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUxOjEzICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90
aWZ5aW5nIGd1ZXN0IDU0OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3Qg
NTQ6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA1NDoyICh2aXJxIDEs
IHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDU1OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVO
KSBOb3RpZnlpbmcgZ3Vlc3QgNTU6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBn
dWVzdCA1NToyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDU1OjMgKHZp
cnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNTc6MCAodmlycSAxLCBwb3J0IDAp
CihYRU4pIE5vdGlmeWluZyBndWVzdCA1NzoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5
aW5nIGd1ZXN0IDU3OjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNTc6
MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA1ODowICh2aXJxIDEsIHBv
cnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDU4OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBO
b3RpZnlpbmcgZ3Vlc3QgNTg6MiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVz
dCA1ODozICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDY0OjAgKHZpcnEg
MSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjQ6MSAodmlycSAxLCBwb3J0IDApCihY
RU4pIE5vdGlmeWluZyBndWVzdCA2NDoyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDY0OjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjQ6NCAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA2NDo1ICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDY0OjYgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgNjU6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA2
NToxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDY1OjIgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjU6MyAodmlycSAxLCBwb3J0IDApCihYRU4p
IE5vdGlmeWluZyBndWVzdCA2NzowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1
ZXN0IDY3OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjc6MiAodmly
cSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA2NzozICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDY3OjQgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgNjc6NSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA2Nzo2
ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDY3OjcgKHZpcnEgMSwgcG9y
dCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjk6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5v
dGlmeWluZyBndWVzdCA2OToxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0
IDY5OjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjk6MyAodmlycSAx
LCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3MTowICh2aXJxIDEsIHBvcnQgMCkKKFhF
TikgTm90aWZ5aW5nIGd1ZXN0IDcxOjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcg
Z3Vlc3QgNzI6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3MjoxICh2
aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDcyOjIgKHZpcnEgMSwgcG9ydCAw
KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzI6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlm
eWluZyBndWVzdCA3Mjo0ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDcy
OjUgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzM6MCAodmlycSAxLCBw
b3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3MzoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikg
Tm90aWZ5aW5nIGd1ZXN0IDczOjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vl
c3QgNzM6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3Mzo0ICh2aXJx
IDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDczOjUgKHZpcnEgMSwgcG9ydCAwKQoo
WEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzM6NiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWlu
ZyBndWVzdCA3Mzo3ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDc4OjAg
KHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzg6MSAodmlycSAxLCBwb3J0
IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3ODoyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90
aWZ5aW5nIGd1ZXN0IDc4OjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3Qg
Nzg6NCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3ODo1ICh2aXJxIDEs
IHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDc4OjYgKHZpcnEgMSwgcG9ydCAwKQooWEVO
KSBOb3RpZnlpbmcgZ3Vlc3QgNzg6NyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBn
dWVzdCA3ODo4ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDc4OjkgKHZp
cnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzg6MTAgKHZpcnEgMSwgcG9ydCAw
KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzg6MTEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgNzg6MTIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3Qg
Nzg6MTMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODA6MCAodmlycSAx
LCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA4MDoxICh2aXJxIDEsIHBvcnQgMCkKKFhF
TikgTm90aWZ5aW5nIGd1ZXN0IDgwOjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcg
Z3Vlc3QgODA6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA4MDo0ICh2
aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDgwOjUgKHZpcnEgMSwgcG9ydCAw
KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODA6NiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlm
eWluZyBndWVzdCA4MDo3ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDgx
OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODE6MSAodmlycSAxLCBw
b3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA4MToyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikg
Tm90aWZ5aW5nIGd1ZXN0IDgxOjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vl
c3QgODE6NCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA4MTo1ICh2aXJx
IDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDgxOjYgKHZpcnEgMSwgcG9ydCAwKQoo
WEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODE6NyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWlu
ZyBndWVzdCA4MTo4ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDgxOjkg
KHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODE6MTAgKHZpcnEgMSwgcG9y
dCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODE6MTEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBO
b3RpZnlpbmcgZ3Vlc3QgODE6MTIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vl
c3QgODE6MTMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODI6MCAodmly
cSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA4MjoxICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDgyOjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgODI6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIFNoYXJlZCBmcmFtZXMgMCAtLSBT
YXZlZCBmcmFtZXMgMAo=
--=_21384d086a51899f8848c4bc3f5019a6
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=_21384d086a51899f8848c4bc3f5019a6--



From xen-devel-bounces@lists.xen.org Mon Dec 01 10:54:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 10:54:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvOcT-0001WR-II; Mon, 01 Dec 2014 10:54:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alukardd@alukardd.org>) id 1XvOcR-0001WM-T7
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 10:54:16 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	77/7E-17735-7D84C745; Mon, 01 Dec 2014 10:54:15 +0000
X-Env-Sender: alukardd@alukardd.org
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417431249!11214650!1
X-Originating-IP: [188.134.93.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 21476 invoked from network); 1 Dec 2014 10:54:10 -0000
Received: from alukardd.org (HELO alukardd.org) (188.134.93.171)
	by server-9.tower-31.messagelabs.com with AES128-SHA encrypted SMTP;
	1 Dec 2014 10:54:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alukardd.org;
	s=mail; 
	h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Type:MIME-Version;
	bh=hnyoUfjmm3GiK9GDxKBdPvdypECDjSb9tCw6jc9Op8A=; 
	b=SmTK86YfVX07fs8fomvMvJl7wzy2Soff/fX5tika+gvEr9UIhxZY/UTK9dsojvRRxVAkLRT/HGcEAwHzwcU7Ihi4pTA44geBGRxH2UqFPzgJwIAERNJ/WQtX5jfCyQ3S+7JGto5To4Gc1gCjpNFMVlyrWR9MOemCfnzaW2GmT+Y=;
Received: from alukardd.org ([172.17.0.101]:55931 helo=mail.alukardd.org)
	by alukardd.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
	(Exim 4.84) (envelope-from <alukardd@alukardd.org>)
	id 1XvOcC-0004XG-Tw; Mon, 01 Dec 2014 13:54:09 +0300
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="=_21384d086a51899f8848c4bc3f5019a6"
Date: Mon, 01 Dec 2014 13:54:00 +0300
From: Alexey <alukardd@alukardd.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417427958.27655.1.camel@citrix.com>
References: <e2a4f20c920a491592cef78dd006da8a@alukardd.org>
	<1417427958.27655.1.camel@citrix.com>
Message-ID: <2a9dd806b9991d506ae274ff67fe5821@alukardd.org>
X-Sender: alukardd@alukardd.org
User-Agent: Alukardd Webmail
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] null domains | xen4.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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--=_21384d086a51899f8848c4bc3f5019a6
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

xl list two domains for example:
(null)                                      67     0     8     --pssd  
135229.6
(null)                                      69     0     4     --ps-d    
4172.2

vif67.0 still exist in my dom0 and i can't "ip link delete" it.
Attached block device marked as busy also.

We try to use the last 3.10 kernel, now new nodes use 3.10.61 kernel, 
but this node on which I can experiment was booted with 3.10.55 kernel.
I attach xl-dmesg after 'q' trigger.

We will discuss tmem with colleagues.

On 2014-12-01 12:59, Ian Campbell wrote:
> On Mon, 2014-12-01 at 12:48 +0300, Alexey wrote:
>> Hi, all!
>> 
>> We are once again faced with the null-domains problem.
>> At this moment we have xen node with 49 null-domains and if I create 
>> new
>> domain and shutdown it I w'll get a new one null-domain.
>> 
>> All blkback and netback kernel process are exists. There is no qemu
>> process running.
>> I can't delete any vif or stop disk, which was used by dead domain.
> 
> What do you mean here, does a vif or disk still exist for the dead
> domain then?
> 
>> How we can prevent appearance of null-domains?
>> How we can unlock resources of existing null-domains?
> 
> A null domain remains when a page owned by that domain is still
> referenced from somewhere. The output of the 'q' debug key sometimes
> exposes the source of such references. ("xl debug-key q" will send 
> that,
> the result appears in "xl dmesg", alternatively Ctrl-A three times on
> the serial console then 'q').
> 
>> # xl info
>> host                   : xen23
>> release                : 3.10-3-amd64
> 
> Any chance you could try a newer dom0 kernel?
> 
>> xen_commandline        : tmem=1 loglvl=all noreboot dom0_mem=5120M
>> dom0_vcpus_pin console=vga vga=current
> 
> Are you able to reproduce when tmem is not enabled?
> 
> Ian.
--=_21384d086a51899f8848c4bc3f5019a6
Content-Transfer-Encoding: base64
Content-Type: text/plain;
 name=xl-dmesg
Content-Disposition: attachment;
 filename=xl-dmesg;
 size=104837

KFhFTikgJ3EnIHByZXNzZWQgLT4gZHVtcGluZyBkb21haW4gaW5mbyAobm93PTB4MzFCOUY6NDY5
QjkyN0YpCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAwOgooWEVOKSAgICAg
cmVmY250PTMgZHlpbmc9MCBwYXVzZV9jb3VudD0wCihYRU4pICAgICBucl9wYWdlcz0xMzEwNzIw
IHhlbmhlYXBfcGFnZXM9NiBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9
ezExLTEyfSBtYXhfcGFnZXM9NDI5NDk2NzI5NQooWEVOKSAgICAgaGFuZGxlPTAwMDAwMDAwLTAw
MDAtMDAwMC0wMDAwLTAwMDAwMDAwMDAwMCB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFuZ2Vz
ZXRzIGJlbG9uZ2luZyB0byBkb21haW4gMDoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyAwLTFmLCAy
Mi0zZiwgNDQtNjAsIDYyLTlmLCBhMi04MDcsIDgwYy1jZmIsIGQwMC1mZmZmIH0KKFhFTikgICAg
IEludGVycnVwdHMgeyAxLTY1IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyAwLWZlZGZmLCBmZWYw
MC1mZmZmZmZmZmZmZmZmZmZmIH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21h
aW4gMDoKKFhFTikgICAgIERvbVBhZ2UgbGlzdCB0b28gbG9uZyB0byBkaXNwbGF5CihYRU4pICAg
ICBYZW5QYWdlIDAwMDAwMDAwMDFmZWZmYmI6IGNhZj1jMDAwMDAwMDAwMDAwMDAyLCB0YWY9NzQw
MDAwMDAwMDAwMDAwMgooWEVOKSAgICAgWGVuUGFnZSAwMDAwMDAwMDAxZmVmZmJhOiBjYWY9YzAw
MDAwMDAwMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIFhlblBhZ2UgMDAw
MDAwMDAwMWZlZmZiOTogY2FmPWMwMDAwMDAwMDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAx
CihYRU4pICAgICBYZW5QYWdlIDAwMDAwMDAwMDFmZWZmYjg6IGNhZj1jMDAwMDAwMDAwMDAwMDAx
LCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgWGVuUGFnZSAwMDAwMDAwMDAwMGJmNTBj
OiBjYWY9YzAwMDAwMDAwMDAwMDAwMiwgdGFmPTc0MDAwMDAwMDAwMDAwMDIKKFhFTikgICAgIFhl
blBhZ2UgMDAwMDAwMDAwMWZjNGZjNDogY2FmPWMwMDAwMDAwMDAwMDAwMDIsIHRhZj03NDAwMDAw
MDAwMDAwMDAyCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiAwOiBbMC0xXQooWEVOKSBW
Q1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAwOgooWEVOKSAgICAgVkNQ
VTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAw
MCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MH0KKFhFTikgICAgIHBhdXNlX2NvdW50PTAg
cGF1c2VfZmxhZ3M9MQooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUx
OiBDUFUxIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezF9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBh
dXNlX2ZsYWdzPTEKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjog
Q1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRp
cnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXsyfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVz
ZV9mbGFncz0xCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQ
VTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0
eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTAgcGF1c2Vf
ZmxhZ3M9MQooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU0OiBDUFU0
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezR9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2Zs
YWdzPTEKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNTogQ1BVNSBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXs1fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFn
cz0xCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTY6IENQVTYgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17Nn0KKFhFTikgICAgIHBhdXNlX2NvdW50PTAgcGF1c2VfZmxhZ3M9
MQooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU3OiBDUFU3IFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezd9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTEK
KFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVODogQ1BVOCBbaGFzPUZd
IHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30g
Y3B1X2FmZmluaXR5PXs4fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFncz0xCihY
RU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTk6IENQVTkgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17OX0KKFhFTikgICAgIHBhdXNlX2NvdW50PTAgcGF1c2VfZmxhZ3M9MQooWEVO
KSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxMDogQ1BVMTAgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MTB9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTEKKFhF
TikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTE6IENQVTExIFtoYXM9VF0g
cG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17MTF9
IGNwdV9hZmZpbml0eT17MTF9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTAK
KFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTI6IENQVTEyIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
MTJ9IGNwdV9hZmZpbml0eT17MTJ9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdz
PTEKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTM6IENQVTEzIFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezEzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFn
cz0xCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE0OiBDUFUxNCBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXsxNH0KKFhFTikgICAgIHBhdXNlX2NvdW50PTAgcGF1c2VfZmxh
Z3M9MQooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxNTogQ1BVMTUg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MTV9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2Zs
YWdzPTEKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRp
b24gZm9yIGRvbWFpbiAxOgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0z
CihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBwYWdl
ZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTEzMTMyOAooWEVOKSAgICAgaGFuZGxl
PTY1ZGFhNmFmLTQ1MDQtNGY3Mi05NWJlLTg4ZjI0MTUxMzExNiB2bV9hc3Npc3Q9MDAwMDAwMGQK
KFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gMToKKFhFTikgICAgIEkvTyBQb3J0
cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0K
KFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gMToKKFhFTikgICAgIERvbVBh
Z2UgMDAwMDAwMDAwMTBhZWVjYzogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQoo
WEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxMGE3ZjkyOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAw
MDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDEwYTdlYzU6IGNhZj0wMDAw
MDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWlu
IDE6IFsxXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAx
OgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwg
dXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikg
ICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGlt
ZXIKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDI6CihYRU4pICAgICByZWZj
bnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9w
YWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFn
ZXM9MzE0NTk4NAooWEVOKSAgICAgaGFuZGxlPWFhMWY2OTY5LWQyNTktNDQyYS05MTVlLWNhMDI3
YWNhZmMwMiB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBk
b21haW4gMjoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsg
fQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0
byBkb21haW4gMjoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMGJiNmMxMDogY2FmPTAwMDAw
MDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwYmI2
MmRkOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdl
IDAwMDAwMDAwMDBiYjVlMTM6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhF
TikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDI6IFswXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9u
IGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAyOgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxh
Z3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU0OiBDUFU0IFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNTogQ1BVNSBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9m
bGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTY6IENQVTYg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU3OiBDUFU3
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3Jt
YXRpb24gZm9yIGRvbWFpbiA0OgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3Vu
dD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBw
YWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTEwNDg4MzIKKFhFTikgICAgIGhh
bmRsZT03NWU0NTEwNi0wNmFjLTQxYTgtYjI5ZS0xNGY0OGJiMDdiMmUgdm1fYXNzaXN0PTAwMDAw
MDA0CihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDQ6CihYRU4pICAgICBJL08g
UG9ydHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkg
eyB9CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDQ6CihYRU4pICAgICBE
b21QYWdlIDAwMDAwMDAwMDBjMmI3ZTY6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAw
MDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMGMyYWEwMzogY2FmPTAwMDAwMDAxLCB0YWY9
NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwY2I4Mzk3OiBjYWY9
MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRv
bWFpbiA0OiBbMF0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21h
aW4gNDoKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDEsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihY
RU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIDEwMCBIeiBwZXJp
b2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9Mgoo
WEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBW
Q1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9
IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291
bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlv
ZCAxMCBtcykKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBw
ZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZv
ciBkb21haW4gNjoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVO
KSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFn
ZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0xMDQ4ODMyCihYRU4pICAgICBoYW5kbGU9MjJk
NGMxOTktYWYyYy00ZDg2LTg3Y2QtYmJlY2NkNTdjMjM4IHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVO
KSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiA2OgooWEVOKSAgICAgSS9PIFBvcnRzICB7
IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVO
KSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiA2OgooWEVOKSAgICAgRG9tUGFnZSAw
MDAwMDAwMDAwZGJmZjE1OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4p
ICAgICBEb21QYWdlIDAwMDAwMDAwMDBkYjU2NTg6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAw
MDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMGRiNTY0YTogY2FmPTAwMDAwMDAx
LCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gNjog
WzBdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDY6CihY
RU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNh
bGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAg
cGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgoo
WEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBj
YWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAg
IHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIK
KFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVw
Y2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAg
ICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVy
CihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1l
cgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gNzoKKFhFTikgICAgIHJlZmNu
dD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3Bh
Z2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdl
cz0xMDQ4ODMyCihYRU4pICAgICBoYW5kbGU9ZjQ1MjFlODAtNTFiYS00NjFmLTliMDgtYmFmNGQ5
NTBhNWNhIHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRv
bWFpbiA3OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9
CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRv
IGRvbWFpbiA3OgooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwZWJmZGI2OiBjYWY9MDAwMDAw
MDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDBlYmZk
YjU6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2Ug
MDAwMDAwMDAwMGViNTY1YzogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVO
KSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gNzogWzBdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24g
YW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDc6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZd
IHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30g
Y3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0w
CihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTQ6IENQVTQgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxh
Z3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU1OiBDUFU1IFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNjogQ1BVNiBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9m
bGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTc6IENQVTcg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgR2VuZXJhbCBpbmZvcm1h
dGlvbiBmb3IgZG9tYWluIDk6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50
PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBh
Z2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9MzE0NTk4NAooWEVOKSAgICAgaGFu
ZGxlPTNhZmYxNGQzLTNlN2ItNGQ3YS1hZjM3LTZhYzJlZGE2OGMyZSB2bV9hc3Npc3Q9MDAwMDAw
MDQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gOToKKFhFTikgICAgIEkvTyBQ
b3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7
IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gOToKKFhFTikgICAgIERv
bVBhZ2UgMDAwMDAwMDAwMTQyN2QxYjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAw
MQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxNDk2NmNhOiBjYWY9MDAwMDAwMDEsIHRhZj03
NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDBmYTQ5ODM6IGNhZj0w
MDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9t
YWluIDk6IFswLTFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9t
YWluIDk6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAxLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQoo
WEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICAxMDAgSHogcGVy
aW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0g
cG9sbD0wIHVwY2FsbF9wZW5kID0gMDEsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBj
cHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAK
KFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAg
VkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sg
PSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2Nv
dW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJp
b2QgMTAgbXMpCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAxLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICAxMDAgSHog
cGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFU0OiBDUFU0IFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDEsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAg
ICAgVkNQVTU6IENQVTUgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMSwgdXBjYWxsX21h
c2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChw
ZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNjogQ1BVNiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxf
cGVuZCA9IDAxLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXsw
LTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICAxMDAg
SHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFU3OiBDUFU3IFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDEsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTAKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVO
KSAgICAgVkNQVTg6IENQVTggW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMSwgdXBjYWxs
X21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBh
dXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVy
IChwZXJpb2QgMTAgbXMpCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAxMDoK
KFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFn
ZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9j
cHVzPXt9IG1heF9wYWdlcz0yMDk3NDA4CihYRU4pICAgICBoYW5kbGU9Nzk3ZTNkNmMtYTU2YS00
NGU0LTk0MTctMjAyYjI5YjJiMzMzIHZtX2Fzc2lzdD0wMDAwMDAwNAooWEVOKSBSYW5nZXNldHMg
YmVsb25naW5nIHRvIGRvbWFpbiAxMDoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAg
ICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBh
Z2VzIGJlbG9uZ2luZyB0byBkb21haW4gMTA6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDBm
ODc0ZTU6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBh
Z2UgMDAwMDAwMDAwMGY4NzRlNDogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQoo
WEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwZmUwMzUyOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAw
MDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiAxMDogWzBdCihYRU4p
IFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDEwOgooWEVOKSAgICAg
VkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMSwgdXBjYWxsX21hc2sg
PSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2Nv
dW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJp
b2QgMTAgbXMpCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHog
cGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAg
ICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21h
c2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChw
ZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxf
cGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXsw
LTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAg
SHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFU1OiBDUFU1IFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVO
KSAgICAgVkNQVTY6IENQVTYgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxs
X21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBh
dXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVy
IChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNzogQ1BVNyBbaGFzPUZdIHBvbGw9MCB1cGNh
bGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5
PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAx
MDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgR2VuZXJhbCBpbmZvcm1h
dGlvbiBmb3IgZG9tYWluIDExOgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3Vu
dD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBw
YWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTUyNDU0NAooWEVOKSAgICAgaGFu
ZGxlPTIwMzgxNmRmLWViZGEtNGU1NS04YWE5LTRhZmIzZGUzNzU1MyB2bV9hc3Npc3Q9MDAwMDAw
MDQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gMTE6CihYRU4pICAgICBJL08g
UG9ydHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkg
eyB9CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDExOgooWEVOKSAgICAg
RG9tUGFnZSAwMDAwMDAwMDAxNDYwNDdiOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAw
MDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDE0ZDcxM2U6IGNhZj0wMDAwMDAwMSwgdGFm
PTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTQyMjIzNDogY2Fm
PTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBk
b21haW4gMTE6IFsxXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRv
bWFpbiAxMToKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDEsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIDEwMCBIeiBw
ZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAg
ICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFz
ayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2Vf
Y291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBl
cmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w
ZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAt
MjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBI
eiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9u
IGZvciBkb21haW4gMTI6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIK
KFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2Vk
X3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9NTI0NTQ0CihYRU4pICAgICBoYW5kbGU9
NzUzN2M3YzAtODEyMS00N2M3LTkwZGYtOTg5MWJmYzZlN2Y2IHZtX2Fzc2lzdD0wMDAwMDAwZgoo
WEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiAxMjoKKFhFTikgICAgIEkvTyBQb3J0
cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0K
KFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gMTI6CihYRU4pICAgICBEb21Q
YWdlIDAwMDAwMDAwMDE1MjVkZDY6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEK
KFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTQ2YzM0YjogY2FmPTAwMDAwMDAxLCB0YWY9NzQw
MDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxNDZiZDljOiBjYWY9MDAw
MDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFp
biAxMjogWzFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWlu
IDEyOgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAw
MSwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhF
TikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlv
ZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihY
RU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZD
UFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9k
IDEwIG1zKQooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBl
cmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9y
IGRvbWFpbiAxNjoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVO
KSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFn
ZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz01MjQ1NDQKKFhFTikgICAgIGhhbmRsZT1mN2Jk
MDliYS01ZDE5LTRlOTQtODI4My1iZDIyMTc0ZjdiZWEgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4p
IFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDE2OgooWEVOKSAgICAgSS9PIFBvcnRzICB7
IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVO
KSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiAxNjoKKFhFTikgICAgIERvbVBhZ2Ug
MDAwMDAwMDAwMTQ0MjI2YjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVO
KSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxNjZmMzM2OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAw
MDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDE2Njg3Zjg6IGNhZj0wMDAwMDAw
MSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDE2
OiBbMV0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gMTY6
CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1l
cgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwg
dXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikg
ICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGlt
ZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAs
IHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4p
ICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRp
bWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAw
LCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVO
KSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0
aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gMTc6CihYRU4pICAgICBy
ZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVh
cF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhf
cGFnZXM9NTI0NTQ0CihYRU4pICAgICBoYW5kbGU9NjI2NWNhZWEtM2YyYi00YmFiLTg3ZGEtZjA0
ZGU3MTM1NDJlIHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRv
IGRvbWFpbiAxNzoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRz
IHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2lu
ZyB0byBkb21haW4gMTc6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDA0Y2NmMjU6IGNhZj0w
MDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAw
MDRlZTM2NDogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9t
UGFnZSAwMDAwMDAwMDAwNDgyOWFmOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAx
CihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiAxNzogWzBdCihYRU4pIFZDUFUgaW5mb3Jt
YXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDE3OgooWEVOKSAgICAgVkNQVTA6IENQVTAg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUx
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BV
MiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5
X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVz
ZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQ
VTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0
eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1
c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgR2VuZXJhbCBpbmZv
cm1hdGlvbiBmb3IgZG9tYWluIDE5OgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9j
b3VudD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9
MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTIwOTc0MDgKKFhFTikgICAg
IGhhbmRsZT0xZTgyYmFlMS0yMjJlLTRiOTAtYmMxZi1mNGI1MDEyZWMzNjAgdm1fYXNzaXN0PTAw
MDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDE5OgooWEVOKSAgICAg
SS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVt
b3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiAxOToKKFhFTikg
ICAgIERvbVBhZ2UgMDAwMDAwMDAwMTZlNWUyNTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAw
MDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxNmNmYzY2OiBjYWY9MDAwMDAwMDEs
IHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDE2Y2ZjM2E6
IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBm
b3IgZG9tYWluIDE5OiBbMC0xXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3Mg
Zm9yIGRvbWFpbiAxOToKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2Fs
bF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9
ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5v
IHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNh
bGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5
PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBO
byBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBj
YWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0
eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAg
Tm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVw
Y2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5p
dHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAg
IE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZdIHBvbGw9MCB1
cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmlu
aXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAg
ICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTU6IENQVTUgW2hhcz1GXSBwb2xsPTAg
dXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZp
bml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAg
ICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU2OiBDUFU2IFtoYXM9Rl0gcG9sbD0w
IHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZm
aW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikg
ICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNzogQ1BVNyBbaGFzPUZdIHBvbGw9
MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2Fm
ZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4p
ICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTg6IENQVTggW2hhcz1GXSBwb2xs
PTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9h
ZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVO
KSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU5OiBDUFU5IFtoYXM9Rl0gcG9s
bD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVf
YWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhF
TikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRv
bWFpbiAyMDoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAg
ICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9
MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz01MjQ1NDQKKFhFTikgICAgIGhhbmRsZT1iZDI0ZDNl
My1kNjg2LTRjZjMtYWMzMi0yMDQzMmZjZWJlMjMgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJh
bmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDIwOgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0K
KFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBN
ZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiAyMDoKKFhFTikgICAgIERvbVBhZ2UgMDAw
MDAwMDAwMTZmMDY4NjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAg
ICAgRG9tUGFnZSAwMDAwMDAwMDAxNzZlZDI4OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAw
MDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDE3NjhlNWU6IGNhZj0wMDAwMDAwMSwg
dGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDIwOiBb
MV0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gMjA6CihY
RU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNh
bGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAg
cGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgoo
WEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBj
YWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAg
IHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIK
KFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVw
Y2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAg
ICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVy
CihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1l
cgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gMjE6CihYRU4pICAgICByZWZj
bnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9w
YWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFn
ZXM9NTI0NTQ0CihYRU4pICAgICBoYW5kbGU9NDUyOGEzYzAtMmQxMi00MTI4LWIzNzktZjliYTkx
N2M0ZGM1IHZtX2Fzc2lzdD0wMDAwMDAwNAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRv
bWFpbiAyMToKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsg
fQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0
byBkb21haW4gMjE6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDA1NzhhNTQ6IGNhZj0wMDAw
MDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDU3
ODUwZTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFn
ZSAwMDAwMDAwMDAwNTc3MGM2OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihY
RU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiAyMTogWzBdCihYRU4pIFZDUFUgaW5mb3JtYXRp
b24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDIxOgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMSwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxh
Z3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4p
ICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxf
bWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1
c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIg
KHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2Fs
bF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9
ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEw
MCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAgVkNQVTM6IENQVTMg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihY
RU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAyMjoKKFhFTikgICAgIHJlZmNudD0x
IGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2Vz
PTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz01
MjQ1NDQKKFhFTikgICAgIGhhbmRsZT0wYTNmZTRhNS04ZDVkLTQ0NzYtODQ0YS1mOGVmY2JiODNl
OTQgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWlu
IDIyOgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihY
RU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRv
bWFpbiAyMjoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTdmMTAzZTogY2FmPTAwMDAwMDAx
LCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxN2U4OTdk
OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAw
MDAwMDAwMDE3ZTg5NDk6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikg
Tk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDIyOiBbMV0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBh
bmQgY2FsbGJhY2tzIGZvciBkb21haW4gMjI6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZd
IHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30g
Y3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0w
CihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9u
IGZvciBkb21haW4gMjM6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIK
KFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2Vk
X3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9MTA0ODgzMgooWEVOKSAgICAgaGFuZGxl
PWQ4OTFmNzIwLTJhNTUtNGE5NC1hYTNhLTlhNDIyNDRlYWM1MCB2bV9hc3Npc3Q9MDAwMDAwMGQK
KFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gMjM6CihYRU4pICAgICBJL08gUG9y
dHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9
CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDIzOgooWEVOKSAgICAgRG9t
UGFnZSAwMDAwMDAwMDAwNWZlYWMxOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAx
CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDA1ZmVhYzA6IGNhZj0wMDAwMDAwMSwgdGFmPTc0
MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDVmNjRhOTogY2FmPTAw
MDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21h
aW4gMjM6IFswXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFp
biAyMzoKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihY
RU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGlj
IHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQoo
WEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2Rp
YyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9k
aWMgdGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlv
ZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJp
b2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTU6IENQVTUgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3Bl
bmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0y
M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVy
aW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU2OiBDUFU2IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w
ZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAt
MjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBl
cmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAyNToKKFhF
TikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9
MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVz
PXt9IG1heF9wYWdlcz0yNjI0MDAKKFhFTikgICAgIGhhbmRsZT0wNzEzY2QxNi00Yjg3LTQzZGUt
YTYzZi1hMWU3MWIzOWZlNjcgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxv
bmdpbmcgdG8gZG9tYWluIDI1OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIElu
dGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMg
YmVsb25naW5nIHRvIGRvbWFpbiAyNToKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTg3MDQ3
MTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAw
MDAwMDAwMDAxODZmNDJjOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4p
ICAgICBEb21QYWdlIDAwMDAwMDAwMDE4Njk4Yjc6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAw
MDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDI1OiBbMV0KKFhFTikgVkNQ
VSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gMjU6CihYRU4pICAgICBWQ1BV
MDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAw
IGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9
MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQ
VTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAw
MCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50
PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZD
UFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBW
Q1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9
IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291
bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5l
cmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gMjY6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0y
IHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJl
ZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9MjYyNDAwCihY
RU4pICAgICBoYW5kbGU9M2JlYTJhNWQtMTg4ZC00ZDQ0LWI0MWItODY0Y2VlNTE3Y2JhIHZtX2Fz
c2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiAyNjoKKFhF
TikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAg
SS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gMjY6
CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDA2M2UwNTI6IGNhZj0wMDAwMDAwMSwgdGFmPTc0
MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDYzNTc2MTogY2FmPTAw
MDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAw
NjM1NmE1OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZm
aW5pdHkgZm9yIGRvbWFpbiAyNjogWzBdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxi
YWNrcyBmb3IgZG9tYWluIDI2OgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAg
dXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZp
bml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAg
ICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9sbD0w
IHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZm
aW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikg
ICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9
MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2Fm
ZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4p
ICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xs
PTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9h
ZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVO
KSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9t
YWluIDI4OgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0yCihYRU4pICAg
ICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0w
IGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTI2MjQwMAooWEVOKSAgICAgaGFuZGxlPThlNTM2M2Fh
LWJlNDEtNDg5MC04NzUwLWIxZThkMjJmOGIzYSB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFu
Z2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gMjg6CihYRU4pICAgICBJL08gUG9ydHMgIHsgfQoo
WEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4pIE1l
bW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDI4OgooWEVOKSAgICAgRG9tUGFnZSAwMDAw
MDAwMDAwNjdkZDU4OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAg
ICBEb21QYWdlIDAwMDAwMDAwMDA2N2RkNTQ6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAw
MDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDY3ZGQwZjogY2FmPTAwMDAwMDAxLCB0
YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gMjg6IFsw
XQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAyODoKKFhF
TikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2Fs
bF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBw
YXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihY
RU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNh
bGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAg
cGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgoo
WEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBj
YWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAg
IHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIK
KFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVw
Y2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAg
ICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVy
CihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAyOToKKFhFTikgICAgIHJlZmNu
dD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3Bh
Z2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdl
cz0zOTM0NzIKKFhFTikgICAgIGhhbmRsZT1kMDQ4NGM5Yi1iZWY0LTQ5MDctOTk0MC0wM2MyODY5
NGM1MDQgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9t
YWluIDI5OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9
CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRv
IGRvbWFpbiAyOToKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDY1YTJmNTogY2FmPTAwMDAw
MDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwNjU5
ZjI0OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdl
IDAwMDAwMDAwMDE4NGJlNmQ6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhF
TikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDI5OiBbMC0xXQooWEVOKSBWQ1BVIGluZm9ybWF0
aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAyOToKKFhFTikgICAgIFZDUFUwOiBDUFUwIFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9m
bGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUz
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNDogQ1BV
NCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5
X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVz
ZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTU6IENQ
VTUgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0
eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1
c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU2OiBD
UFU2IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGly
dHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBh
dXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNzog
Q1BVNyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRp
cnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBw
YXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTg6
IENQVTggW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBk
aXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEg
cGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU5
OiBDUFU5IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0x
IHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BV
MTA6IENQVTEwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBW
Q1BVMTE6IENQVTExIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNr
ID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9j
b3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAg
ICBWQ1BVMTI6IENQVTEyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9t
YXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVz
ZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4p
ICAgICBWQ1BVMTM6IENQVTEzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2Fs
bF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBw
YXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihY
RU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAzMDoKKFhFTikgICAgIHJlZmNudD0x
IGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2Vz
PTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0y
NjI0MDAKKFhFTikgICAgIGhhbmRsZT0wZGQyZjBhMC1jM2UyLTRhNTgtYmVjZS1hMDIxZGQ2ZmEw
YTAgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWlu
IDMwOgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihY
RU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRv
bWFpbiAzMDoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTg0MGNlYzogY2FmPTAwMDAwMDAx
LCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxOGQ5NTBi
OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAw
MDAwMDAwMDE4ZDk1MDA6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikg
Tk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDMwOiBbMV0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBh
bmQgY2FsbGJhY2tzIGZvciBkb21haW4gMzA6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZd
IHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30g
Y3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0w
CihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9u
IGZvciBkb21haW4gMzE6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIK
KFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2Vk
X3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9MjA5NzQwOAooWEVOKSAgICAgaGFuZGxl
PTUyMWJiZjAzLWM0ZmUtNGE0Yi1hMTEyLTFkOTQ1YzdjMmM5MCB2bV9hc3Npc3Q9MDAwMDAwMGQK
KFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gMzE6CihYRU4pICAgICBJL08gUG9y
dHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9
CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDMxOgooWEVOKSAgICAgRG9t
UGFnZSAwMDAwMDAwMDAxOTliYmExOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAx
CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDE5OWJhZTE6IGNhZj0wMDAwMDAwMSwgdGFmPTc0
MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTk5YmFlMDogY2FmPTAw
MDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21h
aW4gMzE6IFsxXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFp
biAzMToKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihY
RU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGlj
IHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQoo
WEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2Rp
YyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9k
aWMgdGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlv
ZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJp
b2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTU6IENQVTUgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3Bl
bmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0y
M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVy
aW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU2OiBDUFU2IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w
ZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAt
MjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBl
cmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAzMjoKKFhF
TikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9
MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVz
PXt9IG1heF9wYWdlcz0yNjI0MDAKKFhFTikgICAgIGhhbmRsZT01MTU1N2ZkMC1mYTMxLTQ0YTIt
OTU2My1kNzk0M2NiOWM3MTkgdm1fYXNzaXN0PTAwMDAwMDBmCihYRU4pIFJhbmdlc2V0cyBiZWxv
bmdpbmcgdG8gZG9tYWluIDMyOgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIElu
dGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMg
YmVsb25naW5nIHRvIGRvbWFpbiAzMjoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDZhMzE0
OTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAw
MDAwMDAwMDAwNmEzMGYzOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4p
ICAgICBEb21QYWdlIDAwMDAwMDAwMDA2YTMwZDY6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAw
MDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDMyOiBbMF0KKFhFTikgVkNQ
VSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gMzI6CihYRU4pICAgICBWQ1BV
MDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAxLCB1cGNhbGxfbWFzayA9IDAx
IGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9
MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAx
MCBtcykKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihY
RU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJp
b2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9Mgoo
WEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBW
Q1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9
IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291
bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlv
ZCAxMCBtcykKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDM1OgooWEVOKSAg
ICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhl
bmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30g
bWF4X3BhZ2VzPTI2MjQwMAooWEVOKSAgICAgaGFuZGxlPWUyOGU1OGZkLWQ5MzctNGZiZC1iYzZk
LWE1ZDY1YWQ0MDU4ZSB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2lu
ZyB0byBkb21haW4gMzU6CihYRU4pICAgICBJL08gUG9ydHMgIHsgfQooWEVOKSAgICAgSW50ZXJy
dXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxv
bmdpbmcgdG8gZG9tYWluIDM1OgooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwNzFjYzE1OiBj
YWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAw
MDAwMDA3MWNiOTE6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAg
IERvbVBhZ2UgMDAwMDAwMDAwMDcxNjQyMTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAw
MDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gMzU6IFswXQooWEVOKSBWQ1BVIGlu
Zm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAzNToKKFhFTikgICAgIFZDUFUwOiBD
UFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGly
dHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBh
dXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTog
Q1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRp
cnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBw
YXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTI6
IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBk
aXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEg
cGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUz
OiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0x
IHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwg
aW5mb3JtYXRpb24gZm9yIGRvbWFpbiAzNjoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1
c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3Bh
Z2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0yNjI0MDAKKFhFTikg
ICAgIGhhbmRsZT00YzA4YjdhMy1iNTU2LTRhNmEtOTFjMi01ZWQzNGIzZmE1NmYgdm1fYXNzaXN0
PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDM2OgooWEVOKSAg
ICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08g
TWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiAzNjoKKFhF
TikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTlkNWNhNTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAw
MDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxOWQ1YjA0OiBjYWY9MDAwMDAw
MDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDE5ZmEy
NWE6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0
eSBmb3IgZG9tYWluIDM2OiBbMV0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tz
IGZvciBkb21haW4gMzY6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNh
bGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5
PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBO
byBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBj
YWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0
eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAg
Tm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVw
Y2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5p
dHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAg
IE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1
cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmlu
aXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAg
ICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4g
Mzc6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5y
X3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGly
dHlfY3B1cz17fSBtYXhfcGFnZXM9MjYyNDAwCihYRU4pICAgICBoYW5kbGU9ODBkYjgyMTQtZmE2
My00MWRmLWE1ODItYWQ4OTYyZmY1NzJiIHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNl
dHMgYmVsb25naW5nIHRvIGRvbWFpbiAzNzoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4p
ICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5
IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gMzc6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAw
MDE5ZjZmZjQ6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERv
bVBhZ2UgMDAwMDAwMDAwMWEyY2E5YTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAw
MQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxYTJjYTk5OiBjYWY9MDAwMDAwMDEsIHRhZj03
NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiAzNzogWzFdCihY
RU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDM3OgooWEVOKSAg
ICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21h
c2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikg
ICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9t
YXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVz
ZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4p
ICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxf
bWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1
c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVO
KSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxs
X21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBh
dXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhF
TikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDM4OgooWEVOKSAgICAgcmVmY250PTEg
ZHlpbmc9MiBwYXVzZV9jb3VudD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9
MCBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTI2
MjQwMAooWEVOKSAgICAgaGFuZGxlPWFiN2FhNWIzLTAzMTEtNDUyNC05YTJiLWNjZGY0ZTY5OGRk
MyB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4g
Mzg6CihYRU4pICAgICBJL08gUG9ydHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhF
TikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9t
YWluIDM4OgooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxYTE2NDE0OiBjYWY9MDAwMDAwMDEs
IHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDFhMGM2Zjg6
IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAw
MDAwMDAwMWEwNDY5YTogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBO
T0RFIGFmZmluaXR5IGZvciBkb21haW4gMzg6IFswLTFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24g
YW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDM4OgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxh
Z3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU0OiBDUFU0IFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNTogQ1BVNSBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9m
bGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTY6IENQVTYg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU3OiBDUFU3
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVODogQ1BV
OCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5
X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVz
ZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTk6IENQ
VTkgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0
eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1
c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxMDog
Q1BVMTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBk
aXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEg
cGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUx
MTogQ1BVMTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAw
MCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50
PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZD
UFUxMjogQ1BVMTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sg
PSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2Nv
dW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAg
IFZDUFUxMzogQ1BVMTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21h
c2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikg
R2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDQ0OgooWEVOKSAgICAgcmVmY250PTEgZHlp
bmc9MiBwYXVzZV9jb3VudD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBz
aGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTI2MjQw
MAooWEVOKSAgICAgaGFuZGxlPTkzOGM0YWFiLWI2ZGMtNGExOC1hMWIzLTQ3MzUwMmEzYTgwYiB2
bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gNDQ6
CihYRU4pICAgICBJL08gUG9ydHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikg
ICAgIEkvTyBNZW1vcnkgeyB9CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWlu
IDQ0OgooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwN2Q5YjZjOiBjYWY9MDAwMDAwMDEsIHRh
Zj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDA3ZDg0MzY6IGNh
Zj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAw
MDAwMDdkODQzNDogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RF
IGFmZmluaXR5IGZvciBkb21haW4gNDQ6IFswXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBj
YWxsYmFja3MgZm9yIGRvbWFpbiA0NDoKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9s
bD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVf
YWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhF
TikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihY
RU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAoo
WEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3Ig
ZG9tYWluIDQ1OgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0yCihYRU4p
ICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdl
cz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTEzMTMyOAooWEVOKSAgICAgaGFuZGxlPTg1NmIy
OTI5LWRiNTAtNDI5ZC05NjVmLTU5MTMyODY4ZjhjNiB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikg
UmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gNDU6CihYRU4pICAgICBJL08gUG9ydHMgIHsg
fQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4p
IE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDQ1OgooWEVOKSAgICAgRG9tUGFnZSAw
MDAwMDAwMDAxYTVjNzIwOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4p
ICAgICBEb21QYWdlIDAwMDAwMDAwMDFiMDFiNWM6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAw
MDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWIwMWI1YjogY2FmPTAwMDAwMDAx
LCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gNDU6
IFsxXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiA0NToK
KFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVw
Y2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAg
ICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVy
CihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1l
cgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwg
dXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikg
ICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGlt
ZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAs
IHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4p
ICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRp
bWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiA0NjoKKFhFTikgICAgIHJl
ZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFw
X3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9w
YWdlcz0zOTM0NzIKKFhFTikgICAgIGhhbmRsZT01MDJiOTUxMC1jMmU5LTQ4N2QtYTYxYi1iMjll
ZTYwYjk4NTYgdm1fYXNzaXN0PTAwMDAwMDA0CihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8g
ZG9tYWluIDQ2OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMg
eyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5n
IHRvIGRvbWFpbiA0NjoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWIxMjRmMjogY2FmPTAw
MDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAx
YjExZWQxOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21Q
YWdlIDAwMDAwMDAwMDA3YzRhOGQ6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEK
KFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDQ2OiBbMC0xXQooWEVOKSBWQ1BVIGluZm9y
bWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiA0NjoKKFhFTikgICAgIFZDUFUwOiBDUFUw
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDEsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTAKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQoo
WEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBj
YWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAg
IHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRp
bWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1
cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmlu
aXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAg
ICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUzOiBD
UFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGly
dHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBh
dXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1z
KQooWEVOKSAgICAgVkNQVTQ6IENQVTQgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwg
dXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikg
ICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGlj
IHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNTogQ1BVNSBbaGFzPUZdIHBvbGw9
MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2Fm
ZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4p
ICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFU2
OiBDUFU2IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0x
IHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEw
IG1zKQooWEVOKSAgICAgVkNQVTc6IENQVTcgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAw
MCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhF
TikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlv
ZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVODogQ1BVOCBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihY
RU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZD
UFU5OiBDUFU5IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9k
IDEwIG1zKQooWEVOKSAgICAgVkNQVTEwOiBDUFUxMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHog
cGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUxMTogQ1BVMTEgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxh
Z3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4p
ICAgICBWQ1BVMTI6IENQVTEyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDEsIHVwY2Fs
bF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBw
YXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1l
ciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAgVkNQVTEzOiBDUFUxMyBbaGFzPUZdIHBvbGw9MCB1
cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmlu
aXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAg
ICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgR2VuZXJhbCBpbmZv
cm1hdGlvbiBmb3IgZG9tYWluIDQ3OgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9j
b3VudD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9
MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTEzMTMyOAooWEVOKSAgICAg
aGFuZGxlPTQ1Njg5OTg1LTAxNGEtNGVhMC04ODZlLWE3N2U3ZDAwYzIwOSB2bV9hc3Npc3Q9MDAw
MDAwMGQKKFhFTikgUmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gNDc6CihYRU4pICAgICBJ
L08gUG9ydHMgIHsgfQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1v
cnkgeyB9CihYRU4pIE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDQ3OgooWEVOKSAg
ICAgRG9tUGFnZSAwMDAwMDAwMDAwN2JkOWY0OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAw
MDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDA3YmU3ODk6IGNhZj0wMDAwMDAwMSwg
dGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDdiZTc4ODog
Y2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZv
ciBkb21haW4gNDc6IFswXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9y
IGRvbWFpbiA0NzoKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w
ZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAt
MjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBl
cmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxf
cGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXsw
LTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBw
ZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxs
X3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17
MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8g
cGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2Fs
bF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9
ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5v
IHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiA0ODoK
KFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFn
ZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9j
cHVzPXt9IG1heF9wYWdlcz0xMzEzMjgKKFhFTikgICAgIGhhbmRsZT04N2U2Y2U5ZC03NGMwLTRl
YzItYjFjMS01NTNkNWYxNjdhYzEgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBi
ZWxvbmdpbmcgdG8gZG9tYWluIDQ4OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAg
IEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFn
ZXMgYmVsb25naW5nIHRvIGRvbWFpbiA0ODoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWIy
MGIwYjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFn
ZSAwMDAwMDAwMDAxYjIwYjBhOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihY
RU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDFhZmIzZmQ6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAw
MDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDQ4OiBbMV0KKFhFTikg
VkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gNDg6CihYRU4pICAgICBW
Q1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9
IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291
bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAg
VkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sg
PSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2Nv
dW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAg
IFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNr
ID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9j
b3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAg
ICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFz
ayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2Vf
Y291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBH
ZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gNTA6CihYRU4pICAgICByZWZjbnQ9MSBkeWlu
Zz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNo
YXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9NTI0NTQ0
CihYRU4pICAgICBoYW5kbGU9OWZjZGQ2NTAtM2IwMS00YjYxLTg4OWItMDViMWQzZDExZTQ1IHZt
X2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiA1MDoK
KFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAg
ICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4g
NTA6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDFhODhkNDc6IGNhZj0wMDAwMDAwMSwgdGFm
PTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWE4OGQ0NjogY2Fm
PTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAw
MDAxYTlmNDg4OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUg
YWZmaW5pdHkgZm9yIGRvbWFpbiA1MDogWzFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNh
bGxiYWNrcyBmb3IgZG9tYWluIDUwOgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xs
PTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9h
ZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVO
KSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9s
bD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVf
YWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhF
TikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihY
RU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAoo
WEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU0OiBDUFU0IFtoYXM9Rl0g
cG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBj
cHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAK
KFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9y
IGRvbWFpbiA1MToKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVO
KSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFn
ZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0yNjI0MDAKKFhFTikgICAgIGhhbmRsZT0xNDMx
YTE0OC1iNjk2LTQ0Y2ItOTJmYS01YTJkYjVjMDBlMjIgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4p
IFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDUxOgooWEVOKSAgICAgSS9PIFBvcnRzICB7
IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVO
KSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiA1MToKKFhFTikgICAgIERvbVBhZ2Ug
MDAwMDAwMDAwMWE5YzQ0MjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVO
KSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwMjIzMWI4OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAw
MDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDAyMjFkYzU6IGNhZj0wMDAwMDAw
MSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDUx
OiBbMC0xXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiA1
MToKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAs
IHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4p
ICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRp
bWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAw
LCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVO
KSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0
aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAw
MCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhF
TikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMg
dGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihY
RU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGlj
IHRpbWVyCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQoo
WEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2Rp
YyB0aW1lcgooWEVOKSAgICAgVkNQVTU6IENQVTUgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9k
aWMgdGltZXIKKFhFTikgICAgIFZDUFU2OiBDUFU2IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlv
ZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNzogQ1BVNyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJp
b2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTg6IENQVTggW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3Bl
bmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0y
M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVy
aW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU5OiBDUFU5IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w
ZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAt
MjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBl
cmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTA6IENQVTEwIFtoYXM9Rl0gcG9sbD0wIHVwY2Fs
bF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9
ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5v
IHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTE6IENQVTExIFtoYXM9Rl0gcG9sbD0wIHVw
Y2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5p
dHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAg
IE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTI6IENQVTEyIFtoYXM9Rl0gcG9sbD0w
IHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZm
aW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikg
ICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMTM6IENQVTEzIFtoYXM9Rl0gcG9s
bD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVf
YWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhF
TikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRv
bWFpbiA1NDoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAg
ICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9
MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0yNjI0MDAKKFhFTikgICAgIGhhbmRsZT1kMTkzMGU5
MS04NWU1LTRhNDEtYjM0NS01NzUxY2MxN2IxMzIgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJh
bmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDU0OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0K
KFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBN
ZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiA1NDoKKFhFTikgICAgIERvbVBhZ2UgMDAw
MDAwMDAwMDIxZjM3YzogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAg
ICAgRG9tUGFnZSAwMDAwMDAwMDAwMjFjODg1OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAw
MDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDAyMDhhNDI6IGNhZj0wMDAwMDAwMSwg
dGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDU0OiBb
MF0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gNTQ6CihY
RU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNh
bGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAg
cGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgoo
WEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBj
YWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAg
IHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIK
KFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVw
Y2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAg
ICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVy
CihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiA1NToKKFhFTikgICAgIHJlZmNu
dD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3Bh
Z2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdl
cz0xMzEzMjgKKFhFTikgICAgIGhhbmRsZT0yMjUzNzViNC1kODAwLTRjYTEtYmU3Ni1jYmVkZDI1
MmQ0Y2Mgdm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9t
YWluIDU1OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9
CihYRU4pICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRv
IGRvbWFpbiA1NToKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDIwOTNhYTogY2FmPTAwMDAw
MDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwMjU5
ODk2OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdl
IDAwMDAwMDAwMDAyNTk4OTU6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhF
TikgTk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDU1OiBbMF0KKFhFTikgVkNQVSBpbmZvcm1hdGlv
biBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gNTU6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hh
cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVz
PXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxh
Z3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBb
aGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2Nw
dXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9m
bGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0
aW9uIGZvciBkb21haW4gNTc6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50
PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBh
Z2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9MTMxMzI4CihYRU4pICAgICBoYW5k
bGU9MTI1Mzk4MDEtNjliZC00NzU4LWE5ODgtYmZhMDc3MjViMGFkIHZtX2Fzc2lzdD0wMDAwMDAw
ZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiA1NzoKKFhFTikgICAgIEkvTyBQ
b3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7
IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gNTc6CihYRU4pICAgICBE
b21QYWdlIDAwMDAwMDAwMDFjMzUxYjk6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAw
MDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWMzNGZlOTogY2FmPTAwMDAwMDAxLCB0YWY9
NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxYzI3N2I1OiBjYWY9
MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRv
bWFpbiA1NzogWzFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9t
YWluIDU3OgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9k
aWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlv
ZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJp
b2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3Bl
bmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0y
M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVy
aW9kaWMgdGltZXIKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDU4OgooWEVO
KSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0yCihYRU4pICAgICBucl9wYWdlcz0z
IHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9
e30gbWF4X3BhZ2VzPTEzMTMyOAooWEVOKSAgICAgaGFuZGxlPWQzOGQ0NmFhLTc3ZGUtNDZlMy05
ZWZlLTE2MzI1NzIzMzVmMyB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikgUmFuZ2VzZXRzIGJlbG9u
Z2luZyB0byBkb21haW4gNTg6CihYRU4pICAgICBJL08gUG9ydHMgIHsgfQooWEVOKSAgICAgSW50
ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4pIE1lbW9yeSBwYWdlcyBi
ZWxvbmdpbmcgdG8gZG9tYWluIDU4OgooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwMmIzNjhl
OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAw
MDAwMDAwMDAyNDlmMTk6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikg
ICAgIERvbVBhZ2UgMDAwMDAwMDAwMDI0OWYxODogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAw
MDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gNTg6IFswXQooWEVOKSBWQ1BV
IGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiA1ODoKKFhFTikgICAgIFZDUFUw
OiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0x
IHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BV
MTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAw
IGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9
MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQ
VTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAw
MCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50
PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZD
UFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVy
YWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiA2NDoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIg
cGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVk
X3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0xMDQ4ODMyCihY
RU4pICAgICBoYW5kbGU9ZTU5NmI4MmQtMjk3Yy00NjIzLTk3NWItYWRkNGY1YWMyMTAzIHZtX2Fz
c2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiA2NDoKKFhF
TikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAg
SS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gNjQ6
CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDFjMjNjZjE6IGNhZj0wMDAwMDAwMSwgdGFmPTc0
MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWM1ODY2NTogY2FmPTAw
MDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAx
YzU4NjY0OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZm
aW5pdHkgZm9yIGRvbWFpbiA2NDogWzFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxi
YWNrcyBmb3IgZG9tYWluIDY0OgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAg
dXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZp
bml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAg
ICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9sbD0w
IHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZm
aW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikg
ICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9
MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2Fm
ZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4p
ICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xs
PTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9h
ZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVO
KSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU0OiBDUFU0IFtoYXM9Rl0gcG9s
bD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVf
YWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhF
TikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNTogQ1BVNSBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihY
RU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTY6IENQVTYgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAoo
WEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBmb3Ig
ZG9tYWluIDY1OgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0yCihYRU4p
ICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBzaGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdl
cz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTI2MjQwMAooWEVOKSAgICAgaGFuZGxlPTBjMmVi
ZjVhLTk2ZjUtNGFjOS1iYzIwLWEyY2M4YmZjZDk3NiB2bV9hc3Npc3Q9MDAwMDAwMGQKKFhFTikg
UmFuZ2VzZXRzIGJlbG9uZ2luZyB0byBkb21haW4gNjU6CihYRU4pICAgICBJL08gUG9ydHMgIHsg
fQooWEVOKSAgICAgSW50ZXJydXB0cyB7IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4p
IE1lbW9yeSBwYWdlcyBiZWxvbmdpbmcgdG8gZG9tYWluIDY1OgooWEVOKSAgICAgRG9tUGFnZSAw
MDAwMDAwMDAwN2FkZGE0OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4p
ICAgICBEb21QYWdlIDAwMDAwMDAwMDA2ZTdiNjg6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAw
MDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMDZlN2I2NzogY2FmPTAwMDAwMDAx
LCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21haW4gNjU6
IFswXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiA2NToK
KFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVw
Y2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAg
ICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVy
CihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1l
cgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwg
dXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikg
ICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGlt
ZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAs
IHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4p
ICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRp
bWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiA2NzoKKFhFTikgICAgIHJl
ZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFw
X3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9w
YWdlcz0yMDk3NDA4CihYRU4pICAgICBoYW5kbGU9NDMzMDBiODgtZDI4MS00YjRlLTg1NzgtYjcx
OTE0MDYyMjM4IHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRv
IGRvbWFpbiA2NzoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRz
IHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2lu
ZyB0byBkb21haW4gNjc6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDEyOWRiMTU6IGNhZj0w
MDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAw
MTI5Y2I4NjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9t
UGFnZSAwMDAwMDAwMDAxMjljYjg1OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAx
CihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiA2NzogWzFdCihYRU4pIFZDUFUgaW5mb3Jt
YXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDY3OgooWEVOKSAgICAgVkNQVTA6IENQVTAg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9j
cHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2Vf
ZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUxOiBDUFUx
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMjogQ1BV
MiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5
X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVz
ZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTM6IENQ
VTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0
eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1
c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU0OiBD
UFU0IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGly
dHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBh
dXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNTog
Q1BVNSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRp
cnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBw
YXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTY6
IENQVTYgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBk
aXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEg
cGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU3
OiBDUFU3IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0x
IHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwg
aW5mb3JtYXRpb24gZm9yIGRvbWFpbiA2OToKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1
c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3Bh
Z2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0yNjI0MDAKKFhFTikg
ICAgIGhhbmRsZT0yOTZlZDg2Yi0zNGQ5LTQyZWUtYWY5Zi01MWZhMGNhZjU3NWIgdm1fYXNzaXN0
PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDY5OgooWEVOKSAg
ICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4pICAgICBJL08g
TWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiA2OToKKFhF
TikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWM2ZWI0NDogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAw
MDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxMmNiNWQwOiBjYWY9MDAwMDAw
MDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDEyY2I1
Y2Y6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9ERSBhZmZpbml0
eSBmb3IgZG9tYWluIDY5OiBbMV0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tz
IGZvciBkb21haW4gNjk6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNh
bGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5
PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBO
byBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBj
YWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0
eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAg
Tm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVw
Y2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5p
dHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTEKKFhFTikgICAg
IE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1
cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmlu
aXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAg
ICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4g
NzE6CihYRU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5y
X3BhZ2VzPTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGly
dHlfY3B1cz17fSBtYXhfcGFnZXM9MTk2ODY0CihYRU4pICAgICBoYW5kbGU9MWE3NTAwZTgtZjA3
ZS00MzM1LThlZWUtNjM2YWI5NDBkODQyIHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNl
dHMgYmVsb25naW5nIHRvIGRvbWFpbiA3MToKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4p
ICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5
IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gNzE6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAw
MDA3OGZlZTE6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERv
bVBhZ2UgMDAwMDAwMDAwMDdmNTk0NDogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAw
MQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwMmEwYzQ5OiBjYWY9MDAwMDAwMDEsIHRhZj03
NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiA3MTogWzBdCihY
RU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDcxOgooWEVOKSAg
ICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21h
c2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikg
ICAgIFZDUFUxOiBDUFUxIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9t
YXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVz
ZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4p
IEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiA3MjoKKFhFTikgICAgIHJlZmNudD0xIGR5
aW5nPTIgcGF1c2VfY291bnQ9MgooWEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAg
c2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz03ODY2
ODgKKFhFTikgICAgIGhhbmRsZT0yMWFhYzBmOS0zMmM1LTQ3YmItYjBhNS0zYWQ2Yzk0YWFmOTIg
dm1fYXNzaXN0PTAwMDAwMDBkCihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDcy
OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4p
ICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFp
biA3MjoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMGY0ZWYzMjogY2FmPTAwMDAwMDAxLCB0
YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwMmU4ZWJjOiBj
YWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAw
MDAwMDAyZThlYmI6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9E
RSBhZmZpbml0eSBmb3IgZG9tYWluIDcyOiBbMF0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQg
Y2FsbGJhY2tzIGZvciBkb21haW4gNzI6CihYRU4pICAgICBWQ1BVMDogQ1BVMCBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihY
RU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTE6IENQVTEgW2hhcz1GXSBw
b2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNw
dV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAoo
WEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUyOiBDUFUyIFtoYXM9Rl0g
cG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBj
cHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAK
KFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVMzogQ1BVMyBbaGFzPUZd
IHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30g
Y3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0w
CihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTQ6IENQVTQgW2hhcz1G
XSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9
IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9
MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU1OiBDUFU1IFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24g
Zm9yIGRvbWFpbiA3MzoKKFhFTikgICAgIHJlZmNudD0xIGR5aW5nPTIgcGF1c2VfY291bnQ9Mgoo
WEVOKSAgICAgbnJfcGFnZXM9MyB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRf
cGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0yMDk3NDA4CihYRU4pICAgICBoYW5kbGU9
NzE4NzRlMDAtMTI5ZS00YTQ5LWExNGUtYmVkODNkYzNjNDNhIHZtX2Fzc2lzdD0wMDAwMDAwNAoo
WEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiA3MzoKKFhFTikgICAgIEkvTyBQb3J0
cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0K
KFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gNzM6CihYRU4pICAgICBEb21Q
YWdlIDAwMDAwMDAwMDExOTM2YTU6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEK
KFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMTE5MzY3ZDogY2FmPTAwMDAwMDAxLCB0YWY9NzQw
MDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxMTkyMGQ5OiBjYWY9MDAw
MDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFp
biA3MzogWzFdCihYRU4pIFZDUFUgaW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWlu
IDczOgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAw
MSwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhF
TikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgMTAwIEh6IHBlcmlv
ZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBv
bGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1
X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihY
RU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZD
UFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9k
IDEwIG1zKQooWEVOKSAgICAgVkNQVTM6IENQVTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBl
cmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZd
IHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30g
Y3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0y
CihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAg
IFZDUFU1OiBDUFU1IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNr
ID0gMDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9j
b3VudD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVy
aW9kIDEwIG1zKQooWEVOKSAgICAgVkNQVTY6IENQVTYgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3Bl
bmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0y
M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6
IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNzogQ1BVNyBbaGFz
PUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9
e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFn
cz0yCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikg
R2VuZXJhbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDc4OgooWEVOKSAgICAgcmVmY250PTEgZHlp
bmc9MiBwYXVzZV9jb3VudD0yCihYRU4pICAgICBucl9wYWdlcz0zIHhlbmhlYXBfcGFnZXM9MCBz
aGFyZWRfcGFnZXM9MCBwYWdlZF9wYWdlcz0wIGRpcnR5X2NwdXM9e30gbWF4X3BhZ2VzPTIwOTc0
MDgKKFhFTikgICAgIGhhbmRsZT1hYzVlMmIwNi03ODk4LTRjMzgtODEwMi0zMjY0NWI5YjZmZjMg
dm1fYXNzaXN0PTAwMDAwMDA0CihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWluIDc4
OgooWEVOKSAgICAgSS9PIFBvcnRzICB7IH0KKFhFTikgICAgIEludGVycnVwdHMgeyB9CihYRU4p
ICAgICBJL08gTWVtb3J5IHsgfQooWEVOKSBNZW1vcnkgcGFnZXMgYmVsb25naW5nIHRvIGRvbWFp
biA3ODoKKFhFTikgICAgIERvbVBhZ2UgMDAwMDAwMDAwMWQ0ZDk3MTogY2FmPTAwMDAwMDAxLCB0
YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAgICAgRG9tUGFnZSAwMDAwMDAwMDAwMzk0ZGIxOiBj
YWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAwMDAwMDAxCihYRU4pICAgICBEb21QYWdlIDAwMDAw
MDAwMDFkNGNmNTA6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgTk9E
RSBhZmZpbml0eSBmb3IgZG9tYWluIDc4OiBbMC0xXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFu
ZCBjYWxsYmFja3MgZm9yIGRvbWFpbiA3ODoKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0g
cG9sbD0wIHVwY2FsbF9wZW5kID0gMDEsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17fSBj
cHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAK
KFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAgICAg
VkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sg
PSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2Nv
dW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJp
b2QgMTAgbXMpCihYRU4pICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHog
cGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9
Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1cz17
fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdz
PTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVOKSAg
ICAgVkNQVTQ6IENQVTQgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21h
c2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChw
ZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVNTogQ1BVNSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxf
cGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXsw
LTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAg
SHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFU2OiBDUFU2IFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlfY3B1
cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNlX2Zs
YWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQooWEVO
KSAgICAgVkNQVTc6IENQVTcgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxs
X21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBh
dXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVOKSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVy
IChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BVODogQ1BVOCBbaGFzPUZdIHBvbGw9MCB1cGNh
bGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5
PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAx
MDAgSHogcGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFU5OiBDUFU5
IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDEgZGlydHlf
Y3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0xIHBhdXNl
X2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9kIDEwIG1zKQoo
WEVOKSAgICAgVkNQVTEwOiBDUFUxMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHogcGVyaW9kaWMg
dGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgICAgIFZDUFUxMTogQ1BVMTEgW2hhcz1GXSBwb2xs
PTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMSBkaXJ0eV9jcHVzPXt9IGNwdV9h
ZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MgooWEVO
KSAgICAgMTAwIEh6IHBlcmlvZGljIHRpbWVyIChwZXJpb2QgMTAgbXMpCihYRU4pICAgICBWQ1BV
MTI6IENQVTEyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0g
MDEgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3Vu
dD0xIHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIDEwMCBIeiBwZXJpb2RpYyB0aW1lciAocGVyaW9k
IDEwIG1zKQooWEVOKSAgICAgVkNQVTEzOiBDUFUxMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAxIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0yCihYRU4pICAgICAxMDAgSHog
cGVyaW9kaWMgdGltZXIgKHBlcmlvZCAxMCBtcykKKFhFTikgR2VuZXJhbCBpbmZvcm1hdGlvbiBm
b3IgZG9tYWluIDgwOgooWEVOKSAgICAgcmVmY250PTEgZHlpbmc9MiBwYXVzZV9jb3VudD0yCihY
RU4pICAgICBucl9wYWdlcz0zNSB4ZW5oZWFwX3BhZ2VzPTAgc2hhcmVkX3BhZ2VzPTAgcGFnZWRf
cGFnZXM9MCBkaXJ0eV9jcHVzPXt9IG1heF9wYWdlcz0xMDQ4ODMyCihYRU4pICAgICBoYW5kbGU9
NmNkOTE2ODQtZGM1OC00MGQ2LTg5MTItNTk1ZjkwODdkNjhhIHZtX2Fzc2lzdD0wMDAwMDAwZAoo
WEVOKSBSYW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiA4MDoKKFhFTikgICAgIEkvTyBQb3J0
cyAgeyB9CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0K
KFhFTikgTWVtb3J5IHBhZ2VzIGJlbG9uZ2luZyB0byBkb21haW4gODA6CihYRU4pICAgICBEb21Q
YWdlIGxpc3QgdG9vIGxvbmcgdG8gZGlzcGxheQooWEVOKSBOT0RFIGFmZmluaXR5IGZvciBkb21h
aW4gODA6IFsxXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9uIGFuZCBjYWxsYmFja3MgZm9yIGRvbWFp
biA4MDoKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihY
RU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGlj
IHRpbWVyCihYRU4pICAgICBWQ1BVMTogQ1BVMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQoo
WEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2Rp
YyB0aW1lcgooWEVOKSAgICAgVkNQVTI6IENQVTIgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQg
PSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30K
KFhFTikgICAgIHBhdXNlX2NvdW50PTAgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9k
aWMgdGltZXIKKFhFTikgICAgIFZDUFUzOiBDUFUzIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9
CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlv
ZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNDogQ1BVNCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJp
b2RpYyB0aW1lcgooWEVOKSAgICAgVkNQVTU6IENQVTUgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3Bl
bmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0y
M30KKFhFTikgICAgIHBhdXNlX2NvdW50PTAgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVy
aW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFU2OiBDUFU2IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w
ZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAt
MjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBl
cmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BVNzogQ1BVNyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxf
cGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXsw
LTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBw
ZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gODE6CihY
RU4pICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2Vz
PTMgeGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1
cz17fSBtYXhfcGFnZXM9MjYyNDAwCihYRU4pICAgICBoYW5kbGU9OTAwNmVmZDQtMDRmOC00M2Ex
LTg2YTctMjMwYTIyYTY5YWVmIHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVs
b25naW5nIHRvIGRvbWFpbiA4MToKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJ
bnRlcnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2Vz
IGJlbG9uZ2luZyB0byBkb21haW4gODE6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDBlZDNk
MTI6IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2Ug
MDAwMDAwMDAwMDY5MDRmYjogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVO
KSAgICAgRG9tUGFnZSAwMDAwMDAwMDAxMjFhNDI3OiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAw
MDAwMDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiA4MTogWzAtMV0KKFhFTikg
VkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gODE6CihYRU4pICAgICBW
Q1BVMDogQ1BVMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9
IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291
bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAg
VkNQVTE6IENQVTEgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sg
PSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2Nv
dW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAg
IFZDUFUyOiBDUFUyIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNr
ID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9j
b3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAg
ICBWQ1BVMzogQ1BVMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFz
ayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2Vf
Y291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAg
ICAgVkNQVTQ6IENQVTQgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21h
c2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNl
X2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikg
ICAgIFZDUFU1OiBDUFU1IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9t
YXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVz
ZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4p
ICAgICBWQ1BVNjogQ1BVNiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxf
bWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1
c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVO
KSAgICAgVkNQVTc6IENQVTcgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxs
X21hc2sgPSAwMCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBh
dXNlX2NvdW50PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhF
TikgICAgIFZDUFU4OiBDUFU4IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2Fs
bF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBw
YXVzZV9jb3VudD0xIHBhdXNlX2ZsYWdzPTAKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihY
RU4pICAgICBWQ1BVOTogQ1BVOSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNh
bGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAg
cGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgoo
WEVOKSAgICAgVkNQVTEwOiBDUFUxMCBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1
cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAg
ICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1l
cgooWEVOKSAgICAgVkNQVTExOiBDUFUxMSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAw
LCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVO
KSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0
aW1lcgooWEVOKSAgICAgVkNQVTEyOiBDUFUxMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQoo
WEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2Rp
YyB0aW1lcgooWEVOKSAgICAgVkNQVTEzOiBDUFUxMyBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVu
ZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIz
fQooWEVOKSAgICAgcGF1c2VfY291bnQ9MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJp
b2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9uIGZvciBkb21haW4gODI6CihYRU4p
ICAgICByZWZjbnQ9MSBkeWluZz0yIHBhdXNlX2NvdW50PTIKKFhFTikgICAgIG5yX3BhZ2VzPTMg
eGVuaGVhcF9wYWdlcz0wIHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17
fSBtYXhfcGFnZXM9MTMxMzI4CihYRU4pICAgICBoYW5kbGU9YjgwZmI2OTgtY2ViNC00ZTY5LWE3
NzEtMTMxMmI0YjhkZTU3IHZtX2Fzc2lzdD0wMDAwMDAwZAooWEVOKSBSYW5nZXNldHMgYmVsb25n
aW5nIHRvIGRvbWFpbiA4MjoKKFhFTikgICAgIEkvTyBQb3J0cyAgeyB9CihYRU4pICAgICBJbnRl
cnJ1cHRzIHsgfQooWEVOKSAgICAgSS9PIE1lbW9yeSB7IH0KKFhFTikgTWVtb3J5IHBhZ2VzIGJl
bG9uZ2luZyB0byBkb21haW4gODI6CihYRU4pICAgICBEb21QYWdlIDAwMDAwMDAwMDBlOTM0N2Q6
IGNhZj0wMDAwMDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDEKKFhFTikgICAgIERvbVBhZ2UgMDAw
MDAwMDAwMDc2NTRkZDogY2FmPTAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQooWEVOKSAg
ICAgRG9tUGFnZSAwMDAwMDAwMDAwNDRjYmEyOiBjYWY9MDAwMDAwMDEsIHRhZj03NDAwMDAwMDAw
MDAwMDAxCihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRvbWFpbiA4MjogWzBdCihYRU4pIFZDUFUg
aW5mb3JtYXRpb24gYW5kIGNhbGxiYWNrcyBmb3IgZG9tYWluIDgyOgooWEVOKSAgICAgVkNQVTA6
IENQVTAgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBk
aXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50PTEg
cGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgICAgIFZDUFUx
OiBDUFUxIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAg
ZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtMjN9CihYRU4pICAgICBwYXVzZV9jb3VudD0x
IHBhdXNlX2ZsYWdzPTIKKFhFTikgICAgIE5vIHBlcmlvZGljIHRpbWVyCihYRU4pICAgICBWQ1BV
MjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAw
IGRpcnR5X2NwdXM9e30gY3B1X2FmZmluaXR5PXswLTIzfQooWEVOKSAgICAgcGF1c2VfY291bnQ9
MSBwYXVzZV9mbGFncz0wCihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSAgICAgVkNQ
VTM6IENQVTMgW2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAw
MCBkaXJ0eV9jcHVzPXt9IGNwdV9hZmZpbml0eT17MC0yM30KKFhFTikgICAgIHBhdXNlX2NvdW50
PTEgcGF1c2VfZmxhZ3M9MAooWEVOKSAgICAgTm8gcGVyaW9kaWMgdGltZXIKKFhFTikgTm90aWZ5
aW5nIGd1ZXN0IDA6MCAodmlycSAxLCBwb3J0IDQpCihYRU4pIE5vdGlmeWluZyBndWVzdCAwOjEg
KHZpcnEgMSwgcG9ydCAxMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDA6MiAodmlycSAxLCBwb3J0
IDE2KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMDozICh2aXJxIDEsIHBvcnQgMjIpCihYRU4pIE5v
dGlmeWluZyBndWVzdCAwOjQgKHZpcnEgMSwgcG9ydCAyOCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0
IDA6NSAodmlycSAxLCBwb3J0IDM0KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMDo2ICh2aXJxIDEs
IHBvcnQgNDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAwOjcgKHZpcnEgMSwgcG9ydCA0NikKKFhF
TikgTm90aWZ5aW5nIGd1ZXN0IDA6OCAodmlycSAxLCBwb3J0IDUyKQooWEVOKSBOb3RpZnlpbmcg
Z3Vlc3QgMDo5ICh2aXJxIDEsIHBvcnQgNTgpCihYRU4pIE5vdGlmeWluZyBndWVzdCAwOjEwICh2
aXJxIDEsIHBvcnQgNjQpCihYRU4pIE5vdGlmeWluZyBndWVzdCAwOjExICh2aXJxIDEsIHBvcnQg
NzApCihYRU4pIE5vdGlmeWluZyBndWVzdCAwOjEyICh2aXJxIDEsIHBvcnQgNzYpCihYRU4pIE5v
dGlmeWluZyBndWVzdCAwOjEzICh2aXJxIDEsIHBvcnQgODIpCihYRU4pIE5vdGlmeWluZyBndWVz
dCAwOjE0ICh2aXJxIDEsIHBvcnQgODgpCihYRU4pIE5vdGlmeWluZyBndWVzdCAwOjE1ICh2aXJx
IDEsIHBvcnQgOTQpCihYRU4pIE5vdGlmeWluZyBndWVzdCAxOjAgKHZpcnEgMSwgcG9ydCAwKQoo
WEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDI6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyOjIgKHZp
cnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjozICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI6NCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWlu
ZyBndWVzdCAyOjUgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjo2ICh2
aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI6NyAodmlycSAxLCBwb3J0IDAp
CihYRU4pIE5vdGlmeWluZyBndWVzdCA0OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgNDoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDQ6MiAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA0OjMgKHZpcnEgMSwgcG9ydCAw
KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5
aW5nIGd1ZXN0IDY6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA2OjIg
KHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjozICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDc6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlm
eWluZyBndWVzdCA3OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzoy
ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDc6MyAodmlycSAxLCBwb3J0
IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3OjQgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgNzo1ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDc6
NiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3OjcgKHZpcnEgMSwgcG9y
dCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgOTowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90
aWZ5aW5nIGd1ZXN0IDk6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA5
OjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgOTozICh2aXJxIDEsIHBv
cnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDk6NCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5v
dGlmeWluZyBndWVzdCA5OjUgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3Qg
OTo2ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDk6NyAodmlycSAxLCBw
b3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA5OjggKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBO
b3RpZnlpbmcgZ3Vlc3QgMTA6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVz
dCAxMDoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDEwOjIgKHZpcnEg
MSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTA6MyAodmlycSAxLCBwb3J0IDApCihY
RU4pIE5vdGlmeWluZyBndWVzdCAxMDo0ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDEwOjUgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTA6NiAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAxMDo3ICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDExOjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgMTE6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAx
MToyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDExOjMgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTI6MCAodmlycSAxLCBwb3J0IDApCihYRU4p
IE5vdGlmeWluZyBndWVzdCAxMjoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1
ZXN0IDEyOjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTI6MyAodmly
cSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAxNjowICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDE2OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgMTY6MiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAxNjoz
ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDE3OjAgKHZpcnEgMSwgcG9y
dCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTc6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5v
dGlmeWluZyBndWVzdCAxNzoyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0
IDE3OjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTk6MCAodmlycSAx
LCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAxOToxICh2aXJxIDEsIHBvcnQgMCkKKFhF
TikgTm90aWZ5aW5nIGd1ZXN0IDE5OjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcg
Z3Vlc3QgMTk6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAxOTo0ICh2
aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDE5OjUgKHZpcnEgMSwgcG9ydCAw
KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTk6NiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlm
eWluZyBndWVzdCAxOTo3ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDE5
OjggKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMTk6OSAodmlycSAxLCBw
b3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyMDowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikg
Tm90aWZ5aW5nIGd1ZXN0IDIwOjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vl
c3QgMjA6MiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyMDozICh2aXJx
IDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDIxOjAgKHZpcnEgMSwgcG9ydCAwKQoo
WEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjE6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWlu
ZyBndWVzdCAyMToyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDIxOjMg
KHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjI6MCAodmlycSAxLCBwb3J0
IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyMjoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90
aWZ5aW5nIGd1ZXN0IDIyOjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3Qg
MjI6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyMzowICh2aXJxIDEs
IHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDIzOjEgKHZpcnEgMSwgcG9ydCAwKQooWEVO
KSBOb3RpZnlpbmcgZ3Vlc3QgMjM6MiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBn
dWVzdCAyMzozICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDIzOjQgKHZp
cnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjM6NSAodmlycSAxLCBwb3J0IDAp
CihYRU4pIE5vdGlmeWluZyBndWVzdCAyMzo2ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5
aW5nIGd1ZXN0IDI1OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjU6
MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyNToyICh2aXJxIDEsIHBv
cnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI1OjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBO
b3RpZnlpbmcgZ3Vlc3QgMjY6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVz
dCAyNjoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI2OjIgKHZpcnEg
MSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjY6MyAodmlycSAxLCBwb3J0IDApCihY
RU4pIE5vdGlmeWluZyBndWVzdCAyODowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDI4OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjg6MiAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyODozICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI5OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgMjk6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAy
OToyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI5OjMgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjk6NCAodmlycSAxLCBwb3J0IDApCihYRU4p
IE5vdGlmeWluZyBndWVzdCAyOTo1ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1
ZXN0IDI5OjYgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjk6NyAodmly
cSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAyOTo4ICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDI5OjkgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgMjk6MTAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjk6
MTEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjk6MTIgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMjk6MTMgKHZpcnEgMSwgcG9ydCAwKQooWEVO
KSBOb3RpZnlpbmcgZ3Vlc3QgMzA6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBn
dWVzdCAzMDoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDMwOjIgKHZp
cnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzA6MyAodmlycSAxLCBwb3J0IDAp
CihYRU4pIE5vdGlmeWluZyBndWVzdCAzMTowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5
aW5nIGd1ZXN0IDMxOjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzE6
MiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzMTozICh2aXJxIDEsIHBv
cnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDMxOjQgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBO
b3RpZnlpbmcgZ3Vlc3QgMzE6NSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVz
dCAzMTo2ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDMyOjAgKHZpcnEg
MSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzI6MSAodmlycSAxLCBwb3J0IDApCihY
RU4pIE5vdGlmeWluZyBndWVzdCAzMjoyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDMyOjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzU6MCAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzNToxICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDM1OjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgMzU6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAz
NjowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDM2OjEgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzY6MiAodmlycSAxLCBwb3J0IDApCihYRU4p
IE5vdGlmeWluZyBndWVzdCAzNjozICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1
ZXN0IDM3OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzc6MSAodmly
cSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzNzoyICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDM3OjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgMzg6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzODox
ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDM4OjIgKHZpcnEgMSwgcG9y
dCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzg6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5v
dGlmeWluZyBndWVzdCAzODo0ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0
IDM4OjUgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgMzg6NiAodmlycSAx
LCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzODo3ICh2aXJxIDEsIHBvcnQgMCkKKFhF
TikgTm90aWZ5aW5nIGd1ZXN0IDM4OjggKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcg
Z3Vlc3QgMzg6OSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzODoxMCAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzODoxMSAodmlycSAxLCBwb3J0
IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCAzODoxMiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5v
dGlmeWluZyBndWVzdCAzODoxMyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVz
dCA0NDowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDQ0OjEgKHZpcnEg
MSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDQ6MiAodmlycSAxLCBwb3J0IDApCihY
RU4pIE5vdGlmeWluZyBndWVzdCA0NTowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDQ1OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDU6MiAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA0NTozICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDQ2OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgNDY6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA0
NjoyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDQ2OjMgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDY6NCAodmlycSAxLCBwb3J0IDApCihYRU4p
IE5vdGlmeWluZyBndWVzdCA0Njo1ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1
ZXN0IDQ2OjYgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDY6NyAodmly
cSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA0Njo4ICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDQ2OjkgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgNDY6MTAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDY6
MTEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDY6MTIgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDY6MTMgKHZpcnEgMSwgcG9ydCAwKQooWEVO
KSBOb3RpZnlpbmcgZ3Vlc3QgNDc6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBn
dWVzdCA0NzoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDQ3OjIgKHZp
cnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDc6MyAodmlycSAxLCBwb3J0IDAp
CihYRU4pIE5vdGlmeWluZyBndWVzdCA0ODowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5
aW5nIGd1ZXN0IDQ4OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNDg6
MiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA0ODozICh2aXJxIDEsIHBv
cnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUwOjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBO
b3RpZnlpbmcgZ3Vlc3QgNTA6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVz
dCA1MDoyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUwOjMgKHZpcnEg
MSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNTA6NCAodmlycSAxLCBwb3J0IDApCihY
RU4pIE5vdGlmeWluZyBndWVzdCA1MTowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDUxOjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNTE6MiAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA1MTozICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUxOjQgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgNTE6NSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA1
MTo2ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUxOjcgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNTE6OCAodmlycSAxLCBwb3J0IDApCihYRU4p
IE5vdGlmeWluZyBndWVzdCA1MTo5ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1
ZXN0IDUxOjEwICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUxOjExICh2
aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUxOjEyICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDUxOjEzICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90
aWZ5aW5nIGd1ZXN0IDU0OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3Qg
NTQ6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA1NDoyICh2aXJxIDEs
IHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDU1OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVO
KSBOb3RpZnlpbmcgZ3Vlc3QgNTU6MSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBn
dWVzdCA1NToyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDU1OjMgKHZp
cnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNTc6MCAodmlycSAxLCBwb3J0IDAp
CihYRU4pIE5vdGlmeWluZyBndWVzdCA1NzoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5
aW5nIGd1ZXN0IDU3OjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNTc6
MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA1ODowICh2aXJxIDEsIHBv
cnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDU4OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBO
b3RpZnlpbmcgZ3Vlc3QgNTg6MiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVz
dCA1ODozICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDY0OjAgKHZpcnEg
MSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjQ6MSAodmlycSAxLCBwb3J0IDApCihY
RU4pIE5vdGlmeWluZyBndWVzdCA2NDoyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5n
IGd1ZXN0IDY0OjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjQ6NCAo
dmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA2NDo1ICh2aXJxIDEsIHBvcnQg
MCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDY0OjYgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgNjU6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA2
NToxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDY1OjIgKHZpcnEgMSwg
cG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjU6MyAodmlycSAxLCBwb3J0IDApCihYRU4p
IE5vdGlmeWluZyBndWVzdCA2NzowICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1
ZXN0IDY3OjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjc6MiAodmly
cSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA2NzozICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDY3OjQgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgNjc6NSAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA2Nzo2
ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDY3OjcgKHZpcnEgMSwgcG9y
dCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjk6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5v
dGlmeWluZyBndWVzdCA2OToxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0
IDY5OjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNjk6MyAodmlycSAx
LCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3MTowICh2aXJxIDEsIHBvcnQgMCkKKFhF
TikgTm90aWZ5aW5nIGd1ZXN0IDcxOjEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcg
Z3Vlc3QgNzI6MCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3MjoxICh2
aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDcyOjIgKHZpcnEgMSwgcG9ydCAw
KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzI6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlm
eWluZyBndWVzdCA3Mjo0ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDcy
OjUgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzM6MCAodmlycSAxLCBw
b3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3MzoxICh2aXJxIDEsIHBvcnQgMCkKKFhFTikg
Tm90aWZ5aW5nIGd1ZXN0IDczOjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vl
c3QgNzM6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3Mzo0ICh2aXJx
IDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDczOjUgKHZpcnEgMSwgcG9ydCAwKQoo
WEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzM6NiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWlu
ZyBndWVzdCA3Mzo3ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDc4OjAg
KHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzg6MSAodmlycSAxLCBwb3J0
IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3ODoyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90
aWZ5aW5nIGd1ZXN0IDc4OjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3Qg
Nzg6NCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA3ODo1ICh2aXJxIDEs
IHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDc4OjYgKHZpcnEgMSwgcG9ydCAwKQooWEVO
KSBOb3RpZnlpbmcgZ3Vlc3QgNzg6NyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBn
dWVzdCA3ODo4ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDc4OjkgKHZp
cnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzg6MTAgKHZpcnEgMSwgcG9ydCAw
KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgNzg6MTEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3Rp
ZnlpbmcgZ3Vlc3QgNzg6MTIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3Qg
Nzg6MTMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODA6MCAodmlycSAx
LCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA4MDoxICh2aXJxIDEsIHBvcnQgMCkKKFhF
TikgTm90aWZ5aW5nIGd1ZXN0IDgwOjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcg
Z3Vlc3QgODA6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA4MDo0ICh2
aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDgwOjUgKHZpcnEgMSwgcG9ydCAw
KQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODA6NiAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlm
eWluZyBndWVzdCA4MDo3ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDgx
OjAgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODE6MSAodmlycSAxLCBw
b3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA4MToyICh2aXJxIDEsIHBvcnQgMCkKKFhFTikg
Tm90aWZ5aW5nIGd1ZXN0IDgxOjMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vl
c3QgODE6NCAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA4MTo1ICh2aXJx
IDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDgxOjYgKHZpcnEgMSwgcG9ydCAwKQoo
WEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODE6NyAodmlycSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWlu
ZyBndWVzdCA4MTo4ICh2aXJxIDEsIHBvcnQgMCkKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDgxOjkg
KHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODE6MTAgKHZpcnEgMSwgcG9y
dCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODE6MTEgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBO
b3RpZnlpbmcgZ3Vlc3QgODE6MTIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vl
c3QgODE6MTMgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlpbmcgZ3Vlc3QgODI6MCAodmly
cSAxLCBwb3J0IDApCihYRU4pIE5vdGlmeWluZyBndWVzdCA4MjoxICh2aXJxIDEsIHBvcnQgMCkK
KFhFTikgTm90aWZ5aW5nIGd1ZXN0IDgyOjIgKHZpcnEgMSwgcG9ydCAwKQooWEVOKSBOb3RpZnlp
bmcgZ3Vlc3QgODI6MyAodmlycSAxLCBwb3J0IDApCihYRU4pIFNoYXJlZCBmcmFtZXMgMCAtLSBT
YXZlZCBmcmFtZXMgMAo=
--=_21384d086a51899f8848c4bc3f5019a6
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=_21384d086a51899f8848c4bc3f5019a6--



From xen-devel-bounces@lists.xen.org Mon Dec 01 11:00:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11: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 1XvOiB-0001l0-KZ; Mon, 01 Dec 2014 11:00: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 1XvOi9-0001ku-ES
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:00:09 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	BE/7C-17694-83A4C745; Mon, 01 Dec 2014 11:00:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417431606!14984245!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4130 invoked from network); 1 Dec 2014 11:00:08 -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;
	1 Dec 2014 11:00:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198344681"
Message-ID: <1417431605.29138.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alexey <alukardd@alukardd.org>
Date: Mon, 1 Dec 2014 11:00:05 +0000
In-Reply-To: <2a9dd806b9991d506ae274ff67fe5821@alukardd.org>
References: <e2a4f20c920a491592cef78dd006da8a@alukardd.org>
	<1417427958.27655.1.camel@citrix.com>
	<2a9dd806b9991d506ae274ff67fe5821@alukardd.org>
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] null domains | xen4.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-12-01 at 13:54 +0300, Alexey wrote:
> xl list two domains for example:
> (null)                                      67     0     8     --pssd  
> 135229.6
> (null)                                      69     0     4     --ps-d    
> 4172.2
> 
> vif67.0 still exist in my dom0 and i can't "ip link delete" it.
> Attached block device marked as busy also.

What does "xenstore-ls -fp" say? Are the backend xenstore nodes still
present?

> We try to use the last 3.10 kernel, now new nodes use 3.10.61 kernel, 
> but this node on which I can experiment was booted with 3.10.55 kernel.

I meant something newer than 3.10, not just the latest 3.10.

> I attach xl-dmesg after 'q' trigger.

Thanks, seems like each domain has three leaked pages, e.g.:

(XEN) Memory pages belonging to domain 4:
(XEN)     DomPage 0000000000c2b7e6: caf=00000001, taf=7400000000000001
(XEN)     DomPage 0000000000c2aa03: caf=00000001, taf=7400000000000001
(XEN)     DomPage 0000000000cb8397: caf=00000001, taf=7400000000000001

If the vifX.Y device is still in existence then there's a pretty good
chance it's holding a page, likewise any disk backends etc.

Are there any messages in the dom0 dmesg around the time of the guest
supposedly shutting down? How about logs under /var/log/xen.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:00:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11: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 1XvOiB-0001l0-KZ; Mon, 01 Dec 2014 11:00: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 1XvOi9-0001ku-ES
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:00:09 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	BE/7C-17694-83A4C745; Mon, 01 Dec 2014 11:00:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417431606!14984245!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4130 invoked from network); 1 Dec 2014 11:00:08 -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;
	1 Dec 2014 11:00:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198344681"
Message-ID: <1417431605.29138.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alexey <alukardd@alukardd.org>
Date: Mon, 1 Dec 2014 11:00:05 +0000
In-Reply-To: <2a9dd806b9991d506ae274ff67fe5821@alukardd.org>
References: <e2a4f20c920a491592cef78dd006da8a@alukardd.org>
	<1417427958.27655.1.camel@citrix.com>
	<2a9dd806b9991d506ae274ff67fe5821@alukardd.org>
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] null domains | xen4.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-12-01 at 13:54 +0300, Alexey wrote:
> xl list two domains for example:
> (null)                                      67     0     8     --pssd  
> 135229.6
> (null)                                      69     0     4     --ps-d    
> 4172.2
> 
> vif67.0 still exist in my dom0 and i can't "ip link delete" it.
> Attached block device marked as busy also.

What does "xenstore-ls -fp" say? Are the backend xenstore nodes still
present?

> We try to use the last 3.10 kernel, now new nodes use 3.10.61 kernel, 
> but this node on which I can experiment was booted with 3.10.55 kernel.

I meant something newer than 3.10, not just the latest 3.10.

> I attach xl-dmesg after 'q' trigger.

Thanks, seems like each domain has three leaked pages, e.g.:

(XEN) Memory pages belonging to domain 4:
(XEN)     DomPage 0000000000c2b7e6: caf=00000001, taf=7400000000000001
(XEN)     DomPage 0000000000c2aa03: caf=00000001, taf=7400000000000001
(XEN)     DomPage 0000000000cb8397: caf=00000001, taf=7400000000000001

If the vifX.Y device is still in existence then there's a pretty good
chance it's holding a page, likewise any disk backends etc.

Are there any messages in the dom0 dmesg around the time of the guest
supposedly shutting down? How about logs under /var/log/xen.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:01:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11: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 1XvOjQ-0001pF-2Z; Mon, 01 Dec 2014 11:01:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XvOjO-0001p9-Su
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 11:01:26 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	66/CF-03145-68A4C745; Mon, 01 Dec 2014 11:01:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417431684!12150167!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28616 invoked from network); 1 Dec 2014 11:01: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;
	1 Dec 2014 11:01:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198344998"
Message-ID: <547C4A7E.6020207@citrix.com>
Date: Mon, 1 Dec 2014 11:01:18 +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: Juergen Gross <jgross@suse.com>, 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> <5477FECF.2060404@suse.com>
In-Reply-To: <5477FECF.2060404@suse.com>
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, 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 28/11/14 04:49, Juergen Gross wrote:
> On 11/27/2014 07:50 PM, Andrew Cooper wrote:
>> 
>> 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.

I dropped it because it copy-and-paste a bunch of otherwise generic x86
assembler and looked unlikely to get an x86 maintainer ack.  If you
think otherwise, feel free to pick it up and run with it.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:01:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11: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 1XvOjQ-0001pF-2Z; Mon, 01 Dec 2014 11:01:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XvOjO-0001p9-Su
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 11:01:26 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	66/CF-03145-68A4C745; Mon, 01 Dec 2014 11:01:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417431684!12150167!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28616 invoked from network); 1 Dec 2014 11:01: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;
	1 Dec 2014 11:01:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198344998"
Message-ID: <547C4A7E.6020207@citrix.com>
Date: Mon, 1 Dec 2014 11:01:18 +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: Juergen Gross <jgross@suse.com>, 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> <5477FECF.2060404@suse.com>
In-Reply-To: <5477FECF.2060404@suse.com>
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, 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 28/11/14 04:49, Juergen Gross wrote:
> On 11/27/2014 07:50 PM, Andrew Cooper wrote:
>> 
>> 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.

I dropped it because it copy-and-paste a bunch of otherwise generic x86
assembler and looked unlikely to get an x86 maintainer ack.  If you
think otherwise, feel free to pick it up and run with it.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:12:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11: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 1XvOtS-00029F-8g; Mon, 01 Dec 2014 11:11:50 +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 1XvOtQ-000290-Cs
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 11:11:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A2/C3-09842-3FC4C745; Mon, 01 Dec 2014 11:11:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417432305!12521510!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 18051 invoked from network); 1 Dec 2014 11:11:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 11:11:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198021575"
Message-ID: <547C4CEF.1010603@citrix.com>
Date: Mon, 1 Dec 2014 11:11:43 +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: "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>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	kvm@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	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 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
[...]
>>> --- 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

As Juergen points out, this does nothing.  You need to schedule while in
the middle of the hypercall.

Remember that Xen's hypercall preemption only preempts the hypercall to
run interrupts in the guest.

>>>
>>>   	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...

No.  My patch added a schedule point in the middle of a hypercall on the
return from an interrupt (e.g., the timer interrupt).

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:12:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11: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 1XvOtS-00029F-8g; Mon, 01 Dec 2014 11:11:50 +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 1XvOtQ-000290-Cs
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 11:11:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A2/C3-09842-3FC4C745; Mon, 01 Dec 2014 11:11:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417432305!12521510!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 18051 invoked from network); 1 Dec 2014 11:11:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 11:11:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198021575"
Message-ID: <547C4CEF.1010603@citrix.com>
Date: Mon, 1 Dec 2014 11:11:43 +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: "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>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	kvm@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	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 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
[...]
>>> --- 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

As Juergen points out, this does nothing.  You need to schedule while in
the middle of the hypercall.

Remember that Xen's hypercall preemption only preempts the hypercall to
run interrupts in the guest.

>>>
>>>   	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...

No.  My patch added a schedule point in the middle of a hypercall on the
return from an interrupt (e.g., the timer interrupt).

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:15:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvOxH-0002Kg-TO; Mon, 01 Dec 2014 11:15:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvOxG-0002KZ-6O
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:15:46 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	30/84-15461-1ED4C745; Mon, 01 Dec 2014 11:15:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417432543!12550282!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 3130 invoked from network); 1 Dec 2014 11:15:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 11:15:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198022588"
Message-ID: <1417432541.29138.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>
Date: Mon, 1 Dec 2014 11:15:41 +0000
In-Reply-To: <1417430853-26347-1-git-send-email-euan.harris@citrix.com>
References: <1417430853-26347-1-git-send-email-euan.harris@citrix.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] libxl: libxl_domain_info: fix typo in error
 message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-01 at 10:47 +0000, Euan Harris wrote:
> Signed-off-by: Euan Harris <euan.harris@citrix.com>

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

This is so trivial as to not need a release ack IMHO, I'll apply next
time I'm doing such things unless someone beats me to it...

> ---
>  tools/libxl/libxl.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f84f7c2..c50c323 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -674,7 +674,7 @@ int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo *info_r,
>  
>      ret = xc_domain_getinfolist(ctx->xch, domid, 1, &xcinfo);
>      if (ret<0) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
>          return ERROR_FAIL;
>      }
>      if (ret==0 || xcinfo.domain != domid) return ERROR_INVAL;



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:15:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvOxH-0002Kg-TO; Mon, 01 Dec 2014 11:15:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvOxG-0002KZ-6O
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:15:46 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	30/84-15461-1ED4C745; Mon, 01 Dec 2014 11:15:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417432543!12550282!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 3130 invoked from network); 1 Dec 2014 11:15:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 11:15:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198022588"
Message-ID: <1417432541.29138.8.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>
Date: Mon, 1 Dec 2014 11:15:41 +0000
In-Reply-To: <1417430853-26347-1-git-send-email-euan.harris@citrix.com>
References: <1417430853-26347-1-git-send-email-euan.harris@citrix.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] libxl: libxl_domain_info: fix typo in error
 message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-01 at 10:47 +0000, Euan Harris wrote:
> Signed-off-by: Euan Harris <euan.harris@citrix.com>

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

This is so trivial as to not need a release ack IMHO, I'll apply next
time I'm doing such things unless someone beats me to it...

> ---
>  tools/libxl/libxl.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f84f7c2..c50c323 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -674,7 +674,7 @@ int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo *info_r,
>  
>      ret = xc_domain_getinfolist(ctx->xch, domid, 1, &xcinfo);
>      if (ret<0) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
>          return ERROR_FAIL;
>      }
>      if (ret==0 || xcinfo.domain != domid) return ERROR_INVAL;



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:17:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvOyi-0002Qg-CL; Mon, 01 Dec 2014 11:17: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 1XvOyg-0002QW-Th
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:17:15 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	B6/FC-25547-63E4C745; Mon, 01 Dec 2014 11:17:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417432630!10532253!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26315 invoked from network); 1 Dec 2014 11:17:10 -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; 1 Dec 2014 11:17:10 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 11:17:09 +0000
Message-Id: <547C5C43020000780004BAFD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 11:17:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
In-Reply-To: <20141201103012.GA69236@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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 01.12.14 at 11:30, <tim@xen.org> wrote:
> At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
>> >>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
>> > To my understanding, pages with p2m_ram_ro are not supposed to be 
>> > modified by guest. So in __hvm_copy(), when p2m type of a page is 
>> > p2m_ram_rom, no copy will occur.
>> > However, to our usage, we just wanna this page to be write protected, so 
>> > that our device model can be triggered to do some emulation. The content 
>> > written to this page is supposed not to be dropped. This way, if 
>> > sequentially a read operation is performed by guest to this page, the 
>> > guest will still see its anticipated value.
>> 
>> __hvm_copy() is only a helper function, and doesn't write to
>> mmio_dm space either; instead its (indirect) callers would invoke
>> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
>> returns. The question hence is about the apparent inconsistency
>> resulting from writes to ram_ro being dropped here but getting
>> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
>> that really intentional?
> 
> No - and AFAICT it shouldn't be happening.  It _is_ how it was
> implemented originally, because it involved fewer moving parts and
> didn't need to be efficient (and after all, writes to entirely missing
> addresses go to the device model too).
> 
> But the code was later updated to log and discard writes to read-only
> memory (see 4d8aa29 from Trolle Selander).
> 
> Early version of p2m_ram_ro were documented in the internal headers as
> sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
> has always said that writes are discarded.

Hmm, so which way do you recommend resolving the inconsistency
then - match what the public interface says or what the apparent
original intention for the internal type was? Presumably we need to
follow the public interface mandated model, and hence require the
new type to be introduced.

> During this bit of archaeology I realised that either this new type
> should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
> class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
> for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
> just p2m_ram_ro and p2m_grant_map_ro.

And I suppose in that latter case the new type could be made part
of 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 Mon Dec 01 11:17:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvOyi-0002Qg-CL; Mon, 01 Dec 2014 11:17: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 1XvOyg-0002QW-Th
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:17:15 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	B6/FC-25547-63E4C745; Mon, 01 Dec 2014 11:17:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417432630!10532253!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26315 invoked from network); 1 Dec 2014 11:17:10 -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; 1 Dec 2014 11:17:10 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 11:17:09 +0000
Message-Id: <547C5C43020000780004BAFD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 11:17:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
In-Reply-To: <20141201103012.GA69236@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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 01.12.14 at 11:30, <tim@xen.org> wrote:
> At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
>> >>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
>> > To my understanding, pages with p2m_ram_ro are not supposed to be 
>> > modified by guest. So in __hvm_copy(), when p2m type of a page is 
>> > p2m_ram_rom, no copy will occur.
>> > However, to our usage, we just wanna this page to be write protected, so 
>> > that our device model can be triggered to do some emulation. The content 
>> > written to this page is supposed not to be dropped. This way, if 
>> > sequentially a read operation is performed by guest to this page, the 
>> > guest will still see its anticipated value.
>> 
>> __hvm_copy() is only a helper function, and doesn't write to
>> mmio_dm space either; instead its (indirect) callers would invoke
>> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
>> returns. The question hence is about the apparent inconsistency
>> resulting from writes to ram_ro being dropped here but getting
>> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
>> that really intentional?
> 
> No - and AFAICT it shouldn't be happening.  It _is_ how it was
> implemented originally, because it involved fewer moving parts and
> didn't need to be efficient (and after all, writes to entirely missing
> addresses go to the device model too).
> 
> But the code was later updated to log and discard writes to read-only
> memory (see 4d8aa29 from Trolle Selander).
> 
> Early version of p2m_ram_ro were documented in the internal headers as
> sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
> has always said that writes are discarded.

Hmm, so which way do you recommend resolving the inconsistency
then - match what the public interface says or what the apparent
original intention for the internal type was? Presumably we need to
follow the public interface mandated model, and hence require the
new type to be introduced.

> During this bit of archaeology I realised that either this new type
> should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
> class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
> for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
> just p2m_ram_ro and p2m_grant_map_ro.

And I suppose in that latter case the new type could be made part
of 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 Mon Dec 01 11:19:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvP17-0002ZF-Tc; Mon, 01 Dec 2014 11:19:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XvP16-0002Z9-EC
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 11:19:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BE/54-09842-FCE4C745; Mon, 01 Dec 2014 11:19:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417432782!12512607!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 28523 invoked from network); 1 Dec 2014 11:19:43 -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;
	1 Dec 2014 11:19:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198023605"
Message-ID: <547C4ECB.7070702@citrix.com>
Date: Mon, 1 Dec 2014 11:19:39 +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>, Juergen Gross <JGross@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>
	<1417426153-12893-2-git-send-email-jgross@suse.com>
	<547C4DD6020000780004BA83@mail.emea.novell.com>
In-Reply-To: <547C4DD6020000780004BA83@mail.emea.novell.com>
X-DLP: MIA2
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 V2] 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 01/12/14 10:15, Jan Beulich wrote:
>>>> On 01.12.14 at 10:29, <JGross@suse.com> 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, the root of the page table root and a p2m generation count.
>> 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.
>>
>> Right now XENFEAT_virtual_p2m will not be set. This will change when
>> the Xen tools support the virtual mapped p2m list.
> 
> This seems wrong: XENFEAT_* only reflect hypervisor capabilities.
> I.e. the availability of the new functionality may need to be
> advertised another way - xenstore perhaps?

Xenstore doesn't work for dom0.

Shouldn't this be something the guest kernel reports using a ELF note bit?

When building a domain (either in Xen for dom0 or in the tools), the
builder may provide a linear p2m iff supported by the guest kernel and
then (and only then) can it provide a guest with > 512 GiB.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:19:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvP17-0002ZF-Tc; Mon, 01 Dec 2014 11:19:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XvP16-0002Z9-EC
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 11:19:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BE/54-09842-FCE4C745; Mon, 01 Dec 2014 11:19:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417432782!12512607!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 28523 invoked from network); 1 Dec 2014 11:19:43 -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;
	1 Dec 2014 11:19:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198023605"
Message-ID: <547C4ECB.7070702@citrix.com>
Date: Mon, 1 Dec 2014 11:19:39 +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>, Juergen Gross <JGross@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>
	<1417426153-12893-2-git-send-email-jgross@suse.com>
	<547C4DD6020000780004BA83@mail.emea.novell.com>
In-Reply-To: <547C4DD6020000780004BA83@mail.emea.novell.com>
X-DLP: MIA2
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 V2] 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 01/12/14 10:15, Jan Beulich wrote:
>>>> On 01.12.14 at 10:29, <JGross@suse.com> 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, the root of the page table root and a p2m generation count.
>> 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.
>>
>> Right now XENFEAT_virtual_p2m will not be set. This will change when
>> the Xen tools support the virtual mapped p2m list.
> 
> This seems wrong: XENFEAT_* only reflect hypervisor capabilities.
> I.e. the availability of the new functionality may need to be
> advertised another way - xenstore perhaps?

Xenstore doesn't work for dom0.

Shouldn't this be something the guest kernel reports using a ELF note bit?

When building a domain (either in Xen for dom0 or in the tools), the
builder may provide a linear p2m iff supported by the guest kernel and
then (and only then) can it provide a guest with > 512 GiB.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:27:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:27:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvP8B-0002pA-Qk; Mon, 01 Dec 2014 11:27: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 1XvP89-0002p5-SX
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:27:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	58/4A-15461-5805C745; Mon, 01 Dec 2014 11:27:01 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417433220!4512278!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14447 invoked from network); 1 Dec 2014 11:27:00 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 11:27:00 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so13601721wgh.26
	for <xen-devel@lists.xen.org>; Mon, 01 Dec 2014 03:27:00 -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=ahPkJ8U8f8+g0DM00xvuWM/Npmommic90KJIc3CltsY=;
	b=X3O51tzrrgGC2p3V1/0WREBXrr64XnkmyBP0g1c3/OhMumOLA6y0LuA65veWJkx7nA
	tmJHi/1DASVlDpjPdoF85c2aRy5Dw7AkarDynXlt2WalFus1m4ylXzYos/Z1T4mNcGjM
	8TRmoELoIV8Pk2glKtxEuedeGfMrYs5gv8UaCPYOsQTVzlE2j8xT+wbFjF82G41kJMni
	ew6JcSm4VA/SYeZrq/xGBLyPP+8LOi/ePnbdZDnN9oo3VzVbnMMsO4VRv9SDGbTfK6DV
	k10Nd9a4BhTGqh/B1shMI2NSgiXszwY2zVVipDpjzxbYoWOt+UozrJcTkwaEVgDoiY9y
	q9cg==
MIME-Version: 1.0
X-Received: by 10.180.76.211 with SMTP id m19mr27833091wiw.73.1417433220566;
	Mon, 01 Dec 2014 03:27:00 -0800 (PST)
Received: by 10.194.44.2 with HTTP; Mon, 1 Dec 2014 03:27:00 -0800 (PST)
In-Reply-To: <1dba4f1.45dd7.149eafa167d.Coremail.hanyandong@iie.ac.cn>
References: <1dba4f1.45dd7.149eafa167d.Coremail.hanyandong@iie.ac.cn>
Date: Mon, 1 Dec 2014 11:27:00 +0000
X-Google-Sender-Auth: lMZEqVu9hczhR485NOPLO1tJGiw
Message-ID: <CAFLBxZaO3WwNBv7rS7P4kD0Boz2saV+krvU9gnX5U2_=xPvTbw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: hanyandong <hanyandong@iie.ac.cn>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
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: text/plain; 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 7:21 AM, hanyandong <hanyandong@iie.ac.cn> 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?

Fundamentally, you need to get the data from Xen out onto the disk.  A
few things to try:

* Make the in-Xen memory buffers larger, using the -S option.

This will help if the problem is just that your Xen traces are too
"bursty" or if dom0 doesn't get run often enough.  But if Xen is
simply generating traces faster than you can write to stable storage,
it's not going to work.

Note also that once you've run xentrace once, you can no longer resize
the buffers; you have to reboot your host.

* Reduce the volume of your traces.  You can use the "-e" option to
narrow down what kind of trace records you get -- make sure that you
only trace the records you want.  This will reduce the number of lost
records.

* Increase the speed of your disk.  SSD or RAID are of course options;
another would be to use a tmpfs or a ramdisk (although I haven't tried
this).

* If you only need data from a few seconds in the past, and you can
detect the condition you're trying to look at, you can use the "-M"
option.  This will copy trace records into a circular buffer in
xentrace's memory, and dump it to a file when xentrace exits.  This is
useful for example if you're trying to debug a crash, and you can tell
when the crash happens and send xentrace a SIGINT.

Good luck. :-)

 -George

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:27:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:27:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvP8B-0002pA-Qk; Mon, 01 Dec 2014 11:27: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 1XvP89-0002p5-SX
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:27:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	58/4A-15461-5805C745; Mon, 01 Dec 2014 11:27:01 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417433220!4512278!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14447 invoked from network); 1 Dec 2014 11:27:00 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 11:27:00 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so13601721wgh.26
	for <xen-devel@lists.xen.org>; Mon, 01 Dec 2014 03:27:00 -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=ahPkJ8U8f8+g0DM00xvuWM/Npmommic90KJIc3CltsY=;
	b=X3O51tzrrgGC2p3V1/0WREBXrr64XnkmyBP0g1c3/OhMumOLA6y0LuA65veWJkx7nA
	tmJHi/1DASVlDpjPdoF85c2aRy5Dw7AkarDynXlt2WalFus1m4ylXzYos/Z1T4mNcGjM
	8TRmoELoIV8Pk2glKtxEuedeGfMrYs5gv8UaCPYOsQTVzlE2j8xT+wbFjF82G41kJMni
	ew6JcSm4VA/SYeZrq/xGBLyPP+8LOi/ePnbdZDnN9oo3VzVbnMMsO4VRv9SDGbTfK6DV
	k10Nd9a4BhTGqh/B1shMI2NSgiXszwY2zVVipDpjzxbYoWOt+UozrJcTkwaEVgDoiY9y
	q9cg==
MIME-Version: 1.0
X-Received: by 10.180.76.211 with SMTP id m19mr27833091wiw.73.1417433220566;
	Mon, 01 Dec 2014 03:27:00 -0800 (PST)
Received: by 10.194.44.2 with HTTP; Mon, 1 Dec 2014 03:27:00 -0800 (PST)
In-Reply-To: <1dba4f1.45dd7.149eafa167d.Coremail.hanyandong@iie.ac.cn>
References: <1dba4f1.45dd7.149eafa167d.Coremail.hanyandong@iie.ac.cn>
Date: Mon, 1 Dec 2014 11:27:00 +0000
X-Google-Sender-Auth: lMZEqVu9hczhR485NOPLO1tJGiw
Message-ID: <CAFLBxZaO3WwNBv7rS7P4kD0Boz2saV+krvU9gnX5U2_=xPvTbw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: hanyandong <hanyandong@iie.ac.cn>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
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: text/plain; 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 7:21 AM, hanyandong <hanyandong@iie.ac.cn> 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?

Fundamentally, you need to get the data from Xen out onto the disk.  A
few things to try:

* Make the in-Xen memory buffers larger, using the -S option.

This will help if the problem is just that your Xen traces are too
"bursty" or if dom0 doesn't get run often enough.  But if Xen is
simply generating traces faster than you can write to stable storage,
it's not going to work.

Note also that once you've run xentrace once, you can no longer resize
the buffers; you have to reboot your host.

* Reduce the volume of your traces.  You can use the "-e" option to
narrow down what kind of trace records you get -- make sure that you
only trace the records you want.  This will reduce the number of lost
records.

* Increase the speed of your disk.  SSD or RAID are of course options;
another would be to use a tmpfs or a ramdisk (although I haven't tried
this).

* If you only need data from a few seconds in the past, and you can
detect the condition you're trying to look at, you can use the "-M"
option.  This will copy trace records into a circular buffer in
xentrace's memory, and dump it to a file when xentrace exits.  This is
useful for example if you're trying to debug a crash, and you can tell
when the crash happens and send xentrace a SIGINT.

Good luck. :-)

 -George

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:27:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:27:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvP8t-0002rn-7t; Mon, 01 Dec 2014 11:27:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alukardd@alukardd.org>) id 1XvP8r-0002rd-J0
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:27:45 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	EA/B9-26652-0B05C745; Mon, 01 Dec 2014 11:27:44 +0000
X-Env-Sender: alukardd@alukardd.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417433263!10786778!1
X-Originating-IP: [188.134.93.171]
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 2564 invoked from network); 1 Dec 2014 11:27:44 -0000
Received: from alukardd.org (HELO alukardd.org) (188.134.93.171)
	by server-12.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	1 Dec 2014 11:27:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alukardd.org;
	s=mail; 
	h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version;
	bh=/0oV8yo1Q98ANxKLbF6JvT2NsMQsDwp4Auk9oPrvQXU=; 
	b=YzaODHFqWCtmiJEV8teve8E4qwcWt8JrW5o13c6nDD7x/oP+Ha3q2Rn0oU3YgxqFmN0I1jrL7uRnKzrXN76xZM9RBsTJT7PxwRPpb1LVI7UXYf9jb65ljXANuhlARFs6unUZLscK3eW8cQROFWqR0NqKws82+KTYquGbblWXBEU=;
Received: from alukardd.org ([172.17.0.101]:55992 helo=mail.alukardd.org)
	by alukardd.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
	(Exim 4.84) (envelope-from <alukardd@alukardd.org>)
	id 1XvP8n-0004bs-Hs; Mon, 01 Dec 2014 14:27:43 +0300
MIME-Version: 1.0
Date: Mon, 01 Dec 2014 14:27:41 +0300
From: Alexey <alukardd@alukardd.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417431605.29138.5.camel@citrix.com>
References: <e2a4f20c920a491592cef78dd006da8a@alukardd.org>
	<1417427958.27655.1.camel@citrix.com>
	<2a9dd806b9991d506ae274ff67fe5821@alukardd.org>
	<1417431605.29138.5.camel@citrix.com>
Message-ID: <17132772b93b3131881dbca4848c947d@alukardd.org>
X-Sender: alukardd@alukardd.org
User-Agent: Alukardd Webmail
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] null domains | xen4.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> What does "xenstore-ls -fp" say?
# xenstore-ls -fp
/tool = ""   (n0)
/tool/xenstored = ""   (n0)
/local = ""   (n0)
/local/domain = ""   (n0)
/local/domain/0 = ""   (n0)
/local/domain/0/name = "Domain-0"   (n0)
/local/domain/0/domid = "0"   (n0)
/local/domain/0/libxl = ""   (n0)
/local/domain/0/libxl/disable_udev = "1"   (n0)
/local/domain/0/device-model = ""   (n0)
/vm = ""   (n0)
/libxl = ""   (n0)

> I meant something newer than 3.10, not just the latest 3.10.
I think it's a problem. We can't deliberately create a null-domain and 
we can't use kernel other then 3.10 in production.

> Thanks, seems like each domain has three leaked pages, e.g.:
> 
> (XEN) Memory pages belonging to domain 4:
> (XEN)     DomPage 0000000000c2b7e6: caf=00000001, taf=7400000000000001
> (XEN)     DomPage 0000000000c2aa03: caf=00000001, taf=7400000000000001
> (XEN)     DomPage 0000000000cb8397: caf=00000001, taf=7400000000000001
> 
> If the vifX.Y device is still in existence then there's a pretty good
> chance it's holding a page, likewise any disk backends etc.
I can't delete vif as I said before.

> Are there any messages in the dom0 dmesg around the time of the guest
> supposedly shutting down? How about logs under /var/log/xen.
Logs doesn't contains any usefull information.

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:27:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:27:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvP8t-0002rn-7t; Mon, 01 Dec 2014 11:27:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alukardd@alukardd.org>) id 1XvP8r-0002rd-J0
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:27:45 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	EA/B9-26652-0B05C745; Mon, 01 Dec 2014 11:27:44 +0000
X-Env-Sender: alukardd@alukardd.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417433263!10786778!1
X-Originating-IP: [188.134.93.171]
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 2564 invoked from network); 1 Dec 2014 11:27:44 -0000
Received: from alukardd.org (HELO alukardd.org) (188.134.93.171)
	by server-12.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	1 Dec 2014 11:27:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alukardd.org;
	s=mail; 
	h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version;
	bh=/0oV8yo1Q98ANxKLbF6JvT2NsMQsDwp4Auk9oPrvQXU=; 
	b=YzaODHFqWCtmiJEV8teve8E4qwcWt8JrW5o13c6nDD7x/oP+Ha3q2Rn0oU3YgxqFmN0I1jrL7uRnKzrXN76xZM9RBsTJT7PxwRPpb1LVI7UXYf9jb65ljXANuhlARFs6unUZLscK3eW8cQROFWqR0NqKws82+KTYquGbblWXBEU=;
Received: from alukardd.org ([172.17.0.101]:55992 helo=mail.alukardd.org)
	by alukardd.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
	(Exim 4.84) (envelope-from <alukardd@alukardd.org>)
	id 1XvP8n-0004bs-Hs; Mon, 01 Dec 2014 14:27:43 +0300
MIME-Version: 1.0
Date: Mon, 01 Dec 2014 14:27:41 +0300
From: Alexey <alukardd@alukardd.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417431605.29138.5.camel@citrix.com>
References: <e2a4f20c920a491592cef78dd006da8a@alukardd.org>
	<1417427958.27655.1.camel@citrix.com>
	<2a9dd806b9991d506ae274ff67fe5821@alukardd.org>
	<1417431605.29138.5.camel@citrix.com>
Message-ID: <17132772b93b3131881dbca4848c947d@alukardd.org>
X-Sender: alukardd@alukardd.org
User-Agent: Alukardd Webmail
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] null domains | xen4.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> What does "xenstore-ls -fp" say?
# xenstore-ls -fp
/tool = ""   (n0)
/tool/xenstored = ""   (n0)
/local = ""   (n0)
/local/domain = ""   (n0)
/local/domain/0 = ""   (n0)
/local/domain/0/name = "Domain-0"   (n0)
/local/domain/0/domid = "0"   (n0)
/local/domain/0/libxl = ""   (n0)
/local/domain/0/libxl/disable_udev = "1"   (n0)
/local/domain/0/device-model = ""   (n0)
/vm = ""   (n0)
/libxl = ""   (n0)

> I meant something newer than 3.10, not just the latest 3.10.
I think it's a problem. We can't deliberately create a null-domain and 
we can't use kernel other then 3.10 in production.

> Thanks, seems like each domain has three leaked pages, e.g.:
> 
> (XEN) Memory pages belonging to domain 4:
> (XEN)     DomPage 0000000000c2b7e6: caf=00000001, taf=7400000000000001
> (XEN)     DomPage 0000000000c2aa03: caf=00000001, taf=7400000000000001
> (XEN)     DomPage 0000000000cb8397: caf=00000001, taf=7400000000000001
> 
> If the vifX.Y device is still in existence then there's a pretty good
> chance it's holding a page, likewise any disk backends etc.
I can't delete vif as I said before.

> Are there any messages in the dom0 dmesg around the time of the guest
> supposedly shutting down? How about logs under /var/log/xen.
Logs doesn't contains any usefull information.

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:29:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:29:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPAk-00033J-TM; Mon, 01 Dec 2014 11:29: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 1XvPAk-00033D-1d
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 11:29:42 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	0D/40-17735-5215C745; Mon, 01 Dec 2014 11:29:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417433380!10536056!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9806 invoked from network); 1 Dec 2014 11:29:40 -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; 1 Dec 2014 11:29:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 11:29:40 +0000
Message-Id: <547C5F31020000780004BB1F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 11:29:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>, "Juergen Gross" <JGross@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>
	<1417426153-12893-2-git-send-email-jgross@suse.com>
	<547C4DD6020000780004BA83@mail.emea.novell.com>
	<547C4ECB.7070702@citrix.com>
In-Reply-To: <547C4ECB.7070702@citrix.com>
Mime-Version: 1.0
Content-Length: 3117
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 V2] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDAxLjEyLjE0IGF0IDEyOjE5LCA8ZGF2aWQudnJhYmVsQGNpdHJpeC5jb20+IHdyb3Rl
Ogo+IE9uIDAxLzEyLzE0IDEwOjE1LCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4gT24gMDEuMTIu
MTQgYXQgMTA6MjksIDxKR3Jvc3NAc3VzZS5jb20+IHdyb3RlOgo+Pj4gVGhlIHg4NiBzdHJ1Y3Qg
YXJjaF9zaGFyZWRfaW5mbyBmaWVsZCBwZm5fdG9fbWZuX2ZyYW1lX2xpc3RfbGlzdAo+Pj4gY3Vy
cmVudGx5IGNvbnRhaW5zIHRoZSBtZm4gb2YgdGhlIHRvcCBsZXZlbCBwYWdlIGZyYW1lIG9mIHRo
ZSAzIGxldmVsCj4+PiBwMm0gdHJlZSwgd2hpY2ggaXMgdXNlZCBieSB0aGUgWGVuIHRvb2xzIGR1
cmluZyBzYXZpbmcgYW5kIHJlc3RvcmluZwo+Pj4gKGFuZCBsaXZlIG1pZ3JhdGlvbikgb2YgcHYg
ZG9tYWlucyBhbmQgZm9yIGNyYXNoIGR1bXAgYW5hbHlzaXMuIFdpdGgKPj4+IHRocmVlIGxldmVs
cyBvZiB0aGUgcDJtIHRyZWUgaXQgaXMgcG9zc2libGUgdG8gc3VwcG9ydCB1cCB0byA1MTIgR0Ig
b2YKPj4+IFJBTSBmb3IgYSA2NCBiaXQgcHYgZG9tYWluLgo+Pj4KPj4+IEEgMzIgYml0IHB2IGRv
bWFpbiBjYW4gc3VwcG9ydCBtb3JlLCBhcyBlYWNoIG1lbW9yeSBwYWdlIGNhbiBob2xkIDEwMjQK
Pj4+IGluc3RlYWQgb2YgNTEyIGVudHJpZXMsIGxlYWRpbmcgdG8gYSBsaW1pdCBvZiA0IFRCLgo+
Pj4KPj4+IFRvIGJlIGFibGUgdG8gc3VwcG9ydCBtb3JlIFJBTSBvbiB4ODYtNjQgc3dpdGNoIHRv
IGEgdmlydHVhbCBtYXBwZWQKPj4+IHAybSBsaXN0Lgo+Pj4KPj4+IFRoaXMgcGF0Y2ggZXhwYW5k
cyBzdHJ1Y3QgYXJjaF9zaGFyZWRfaW5mbyB3aXRoIGEgbmV3IHAybSBsaXN0IHZpcnR1YWwKPj4+
IGFkZHJlc3MsIHRoZSByb290IG9mIHRoZSBwYWdlIHRhYmxlIHJvb3QgYW5kIGEgcDJtIGdlbmVy
YXRpb24gY291bnQuCj4+PiBUaGUgbmV3IGluZm9ybWF0aW9uIGlzIGluZGljYXRlZCBieSB0aGUg
ZG9tYWluIHRvIGJlIHZhbGlkIGJ5IHN0b3JpbmcKPj4+IH4wVUwgaW50byBwZm5fdG9fbWZuX2Zy
YW1lX2xpc3RfbGlzdC4gVGhlIGh5cGVydmlzb3IgaW5kaWNhdGVzCj4+PiB1c2FiaWxpdHkgb2Yg
dGhpcyBmZWF0dXJlIGJ5IGEgbmV3IGZsYWcgWEVORkVBVF92aXJ0dWFsX3AybS4KPj4+Cj4+PiBS
aWdodCBub3cgWEVORkVBVF92aXJ0dWFsX3AybSB3aWxsIG5vdCBiZSBzZXQuIFRoaXMgd2lsbCBj
aGFuZ2Ugd2hlbgo+Pj4gdGhlIFhlbiB0b29scyBzdXBwb3J0IHRoZSB2aXJ0dWFsIG1hcHBlZCBw
Mm0gbGlzdC4KPj4gCj4+IFRoaXMgc2VlbXMgd3Jvbmc6IFhFTkZFQVRfKiBvbmx5IHJlZmxlY3Qg
aHlwZXJ2aXNvciBjYXBhYmlsaXRpZXMuCj4+IEkuZS4gdGhlIGF2YWlsYWJpbGl0eSBvZiB0aGUg
bmV3IGZ1bmN0aW9uYWxpdHkgbWF5IG5lZWQgdG8gYmUKPj4gYWR2ZXJ0aXNlZCBhbm90aGVyIHdh
eSAtIHhlbnN0b3JlIHBlcmhhcHM/Cj4gCj4gWGVuc3RvcmUgZG9lc24ndCB3b3JrIGZvciBkb20w
Lgo+IAo+IFNob3VsZG4ndCB0aGlzIGJlIHNvbWV0aGluZyB0aGUgZ3Vlc3Qga2VybmVsIHJlcG9y
dHMgdXNpbmcgYSBFTEYgbm90ZSBiaXQ/Cj4gCj4gV2hlbiBidWlsZGluZyBhIGRvbWFpbiAoZWl0
aGVyIGluIFhlbiBmb3IgZG9tMCBvciBpbiB0aGUgdG9vbHMpLCB0aGUKPiBidWlsZGVyIG1heSBw
cm92aWRlIGEgbGluZWFyIHAybSBpZmYgc3VwcG9ydGVkIGJ5IHRoZSBndWVzdCBrZXJuZWwgYW5k
Cj4gdGhlbiAoYW5kIG9ubHkgdGhlbikgY2FuIGl0IHByb3ZpZGUgYSBndWVzdCB3aXRoID4gNTEy
IEdpQi4KClllcywgc3VyZWx5IHRoaXMgZmxhZyBjb3VsZCBhY3QgYXMgYSBrZXJuZWwgY2FwYWJp
bGl0eSBpbmRpY2F0b3IgKHZpYQp0aGUgWEVOX0VMRk5PVEVfU1VQUE9SVEVEX0ZFQVRVUkVTIG5v
dGUpLCBsaWtlIGUuZy4KWEVORkVBVF9kb20wIGFscmVhZHkgZG9lcy4gSsO8cmdlbidzIGZpbmFs
IHN0YXRlbWVudCwgaG93ZXZlciwKc3VnZ2VzdGVkIHRvIG1lIHRoYXQgdGhpcyBpcyBtZWFudCB0
byBiZSBvbmx5IGNvbnN1bWVkIGJ5IGtlcm5lbHMuCk90b2ggdGhlIFAyTSBwcm92aWRlZCBieSBi
b3RoIERvbTAgYW5kIERvbVUgYnVpbGRlcnMgaGF2ZSBhbHdheXMKYmVlbiBsaW5lYXIgYW55d2F5
OyBpdCdzIHRoZSBwdi1vcHMga2VybmVsIHRoYXQgY29uc3RydWN0cyBhIHRyZWUgYXMKcmVwbGFj
ZW1lbnQuCgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:29:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:29:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPAk-00033J-TM; Mon, 01 Dec 2014 11:29: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 1XvPAk-00033D-1d
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 11:29:42 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	0D/40-17735-5215C745; Mon, 01 Dec 2014 11:29:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417433380!10536056!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9806 invoked from network); 1 Dec 2014 11:29:40 -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; 1 Dec 2014 11:29:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 11:29:40 +0000
Message-Id: <547C5F31020000780004BB1F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 11:29:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>, "Juergen Gross" <JGross@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>
	<1417426153-12893-2-git-send-email-jgross@suse.com>
	<547C4DD6020000780004BA83@mail.emea.novell.com>
	<547C4ECB.7070702@citrix.com>
In-Reply-To: <547C4ECB.7070702@citrix.com>
Mime-Version: 1.0
Content-Length: 3117
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 V2] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDAxLjEyLjE0IGF0IDEyOjE5LCA8ZGF2aWQudnJhYmVsQGNpdHJpeC5jb20+IHdyb3Rl
Ogo+IE9uIDAxLzEyLzE0IDEwOjE1LCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4gT24gMDEuMTIu
MTQgYXQgMTA6MjksIDxKR3Jvc3NAc3VzZS5jb20+IHdyb3RlOgo+Pj4gVGhlIHg4NiBzdHJ1Y3Qg
YXJjaF9zaGFyZWRfaW5mbyBmaWVsZCBwZm5fdG9fbWZuX2ZyYW1lX2xpc3RfbGlzdAo+Pj4gY3Vy
cmVudGx5IGNvbnRhaW5zIHRoZSBtZm4gb2YgdGhlIHRvcCBsZXZlbCBwYWdlIGZyYW1lIG9mIHRo
ZSAzIGxldmVsCj4+PiBwMm0gdHJlZSwgd2hpY2ggaXMgdXNlZCBieSB0aGUgWGVuIHRvb2xzIGR1
cmluZyBzYXZpbmcgYW5kIHJlc3RvcmluZwo+Pj4gKGFuZCBsaXZlIG1pZ3JhdGlvbikgb2YgcHYg
ZG9tYWlucyBhbmQgZm9yIGNyYXNoIGR1bXAgYW5hbHlzaXMuIFdpdGgKPj4+IHRocmVlIGxldmVs
cyBvZiB0aGUgcDJtIHRyZWUgaXQgaXMgcG9zc2libGUgdG8gc3VwcG9ydCB1cCB0byA1MTIgR0Ig
b2YKPj4+IFJBTSBmb3IgYSA2NCBiaXQgcHYgZG9tYWluLgo+Pj4KPj4+IEEgMzIgYml0IHB2IGRv
bWFpbiBjYW4gc3VwcG9ydCBtb3JlLCBhcyBlYWNoIG1lbW9yeSBwYWdlIGNhbiBob2xkIDEwMjQK
Pj4+IGluc3RlYWQgb2YgNTEyIGVudHJpZXMsIGxlYWRpbmcgdG8gYSBsaW1pdCBvZiA0IFRCLgo+
Pj4KPj4+IFRvIGJlIGFibGUgdG8gc3VwcG9ydCBtb3JlIFJBTSBvbiB4ODYtNjQgc3dpdGNoIHRv
IGEgdmlydHVhbCBtYXBwZWQKPj4+IHAybSBsaXN0Lgo+Pj4KPj4+IFRoaXMgcGF0Y2ggZXhwYW5k
cyBzdHJ1Y3QgYXJjaF9zaGFyZWRfaW5mbyB3aXRoIGEgbmV3IHAybSBsaXN0IHZpcnR1YWwKPj4+
IGFkZHJlc3MsIHRoZSByb290IG9mIHRoZSBwYWdlIHRhYmxlIHJvb3QgYW5kIGEgcDJtIGdlbmVy
YXRpb24gY291bnQuCj4+PiBUaGUgbmV3IGluZm9ybWF0aW9uIGlzIGluZGljYXRlZCBieSB0aGUg
ZG9tYWluIHRvIGJlIHZhbGlkIGJ5IHN0b3JpbmcKPj4+IH4wVUwgaW50byBwZm5fdG9fbWZuX2Zy
YW1lX2xpc3RfbGlzdC4gVGhlIGh5cGVydmlzb3IgaW5kaWNhdGVzCj4+PiB1c2FiaWxpdHkgb2Yg
dGhpcyBmZWF0dXJlIGJ5IGEgbmV3IGZsYWcgWEVORkVBVF92aXJ0dWFsX3AybS4KPj4+Cj4+PiBS
aWdodCBub3cgWEVORkVBVF92aXJ0dWFsX3AybSB3aWxsIG5vdCBiZSBzZXQuIFRoaXMgd2lsbCBj
aGFuZ2Ugd2hlbgo+Pj4gdGhlIFhlbiB0b29scyBzdXBwb3J0IHRoZSB2aXJ0dWFsIG1hcHBlZCBw
Mm0gbGlzdC4KPj4gCj4+IFRoaXMgc2VlbXMgd3Jvbmc6IFhFTkZFQVRfKiBvbmx5IHJlZmxlY3Qg
aHlwZXJ2aXNvciBjYXBhYmlsaXRpZXMuCj4+IEkuZS4gdGhlIGF2YWlsYWJpbGl0eSBvZiB0aGUg
bmV3IGZ1bmN0aW9uYWxpdHkgbWF5IG5lZWQgdG8gYmUKPj4gYWR2ZXJ0aXNlZCBhbm90aGVyIHdh
eSAtIHhlbnN0b3JlIHBlcmhhcHM/Cj4gCj4gWGVuc3RvcmUgZG9lc24ndCB3b3JrIGZvciBkb20w
Lgo+IAo+IFNob3VsZG4ndCB0aGlzIGJlIHNvbWV0aGluZyB0aGUgZ3Vlc3Qga2VybmVsIHJlcG9y
dHMgdXNpbmcgYSBFTEYgbm90ZSBiaXQ/Cj4gCj4gV2hlbiBidWlsZGluZyBhIGRvbWFpbiAoZWl0
aGVyIGluIFhlbiBmb3IgZG9tMCBvciBpbiB0aGUgdG9vbHMpLCB0aGUKPiBidWlsZGVyIG1heSBw
cm92aWRlIGEgbGluZWFyIHAybSBpZmYgc3VwcG9ydGVkIGJ5IHRoZSBndWVzdCBrZXJuZWwgYW5k
Cj4gdGhlbiAoYW5kIG9ubHkgdGhlbikgY2FuIGl0IHByb3ZpZGUgYSBndWVzdCB3aXRoID4gNTEy
IEdpQi4KClllcywgc3VyZWx5IHRoaXMgZmxhZyBjb3VsZCBhY3QgYXMgYSBrZXJuZWwgY2FwYWJp
bGl0eSBpbmRpY2F0b3IgKHZpYQp0aGUgWEVOX0VMRk5PVEVfU1VQUE9SVEVEX0ZFQVRVUkVTIG5v
dGUpLCBsaWtlIGUuZy4KWEVORkVBVF9kb20wIGFscmVhZHkgZG9lcy4gSsO8cmdlbidzIGZpbmFs
IHN0YXRlbWVudCwgaG93ZXZlciwKc3VnZ2VzdGVkIHRvIG1lIHRoYXQgdGhpcyBpcyBtZWFudCB0
byBiZSBvbmx5IGNvbnN1bWVkIGJ5IGtlcm5lbHMuCk90b2ggdGhlIFAyTSBwcm92aWRlZCBieSBi
b3RoIERvbTAgYW5kIERvbVUgYnVpbGRlcnMgaGF2ZSBhbHdheXMKYmVlbiBsaW5lYXIgYW55d2F5
OyBpdCdzIHRoZSBwdi1vcHMga2VybmVsIHRoYXQgY29uc3RydWN0cyBhIHRyZWUgYXMKcmVwbGFj
ZW1lbnQuCgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:31:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:31:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPCJ-0003Cn-PI; Mon, 01 Dec 2014 11:31: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 1XvPCH-0003CM-U9
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:31:18 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	48/F8-17958-5815C745; Mon, 01 Dec 2014 11:31:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417433474!14895849!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 699 invoked from network); 1 Dec 2014 11:31:16 -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;
	1 Dec 2014 11:31:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198352249"
Received: from ukmail1.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, 1 Dec 2014 06:31:13 -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 1XvPCD-00081Z-JG;
	Mon, 01 Dec 2014 11:31:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 11:31:12 +0000
Message-ID: <1417433473-17272-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@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 v2 for-4.5 1/2] libxl: un-constify return value
	of libxl_basename
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The string returned is malloc'ed but marked as "const".

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.h       |   10 ++++++++++
 tools/libxl/libxl_utils.c |    5 ++++-
 tools/libxl/libxl_utils.h |    6 +++++-
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 41d6e8d..291c190 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -478,6 +478,16 @@ typedef struct libxl__ctx libxl_ctx;
 #endif
 
 /*
+ * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
+ *
+ * The return value of libxl_basename is malloc'ed but the erroneously
+ * marked as "const" in releases before 4.5.
+ */
+#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
+#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
+#endif
+
+/*
  * LIBXL_HAVE_PHYSINFO_OUTSTANDING_PAGES
  *
  * If this is defined, libxl_physinfo structure will contain an uint64 field
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 3e1ba17..22119fc 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -19,7 +19,10 @@
 
 #include "libxl_internal.h"
 
-const char *libxl_basename(const char *name)
+#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
+const
+#endif
+char *libxl_basename(const char *name)
 {
     const char *filename;
     if (name == NULL)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 117b229..8277eb9 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -18,7 +18,11 @@
 
 #include "libxl.h"
 
-const char *libxl_basename(const char *name); /* returns string from strdup */
+#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
+const
+#endif
+char *libxl_basename(const char *name); /* returns string from strdup */
+
 unsigned long libxl_get_required_shadow_memory(unsigned long maxmem_kb, unsigned int smp_cpus);
 int libxl_name_to_domid(libxl_ctx *ctx, const char *name, uint32_t *domid);
 int libxl_domain_qualifier_to_domid(libxl_ctx *ctx, const char *name, 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 Mon Dec 01 11:31:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:31:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPCI-0003CU-CN; Mon, 01 Dec 2014 11:31: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 1XvPCG-0003CE-VF
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:31:17 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	A1/2B-17694-4815C745; Mon, 01 Dec 2014 11:31:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417433474!14895849!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 583 invoked from network); 1 Dec 2014 11:31:15 -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;
	1 Dec 2014 11:31:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198352248"
Received: from ukmail1.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, 1 Dec 2014 06:31:13 -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 1XvPCD-00081Z-HJ;
	Mon, 01 Dec 2014 11:31:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 11:31:11 +0000
Message-ID: <1417433473-17272-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 v2 for-4.5 0/2] xl/libxl: fix API and 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

Return value of libxl_basename was erroneously marked as "const". This
series removes that "const" and fixes two memory leaks in xl.

I think these fixes should be included in 4.5, given that they fix real
issues and are very straight foward to reason about.

Wei.

Wei Liu (2):
  libxl: un-constify return value of libxl_basename
  xl: fix two memory leaks

 tools/libxl/libxl.h       |   10 ++++++++++
 tools/libxl/libxl_utils.c |    5 ++++-
 tools/libxl/libxl_utils.h |    6 +++++-
 tools/libxl/xl_cmdimpl.c  |    8 ++++++--
 4 files changed, 25 insertions(+), 4 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 Mon Dec 01 11:31:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:31:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPCK-0003Cz-5o; Mon, 01 Dec 2014 11:31: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 1XvPCI-0003CO-Gw
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:31:18 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	C5/37-28296-5815C745; Mon, 01 Dec 2014 11:31:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417433474!14895849!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 816 invoked from network); 1 Dec 2014 11:31: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;
	1 Dec 2014 11:31:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198352250"
Received: from ukmail1.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, 1 Dec 2014 06:31:13 -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 1XvPCD-00081Z-Jz;
	Mon, 01 Dec 2014 11:31:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 11:31:13 +0000
Message-ID: <1417433473-17272-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@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 v2 for-4.5 2/2] 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

Free strings returned by libxl_basename 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 |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0e754e7..fe3034f 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;
+    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,15 @@ 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(basename);
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
@@ -7023,7 +7026,7 @@ int main_cpupoolcreate(int argc, char **argv)
     int config_len = 0;
     XLU_Config *config;
     const char *buf;
-    const char *name;
+    char *name = NULL;
     uint32_t poolid;
     libxl_scheduler sched = 0;
     XLU_ConfigList *cpus;
@@ -7197,6 +7200,7 @@ int main_cpupoolcreate(int argc, char **argv)
 out_cfg:
     xlu_cfg_destroy(config);
 out:
+    free(name);
     free(config_data);
     return rc;
 }
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:31:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:31:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPCI-0003CU-CN; Mon, 01 Dec 2014 11:31: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 1XvPCG-0003CE-VF
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:31:17 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	A1/2B-17694-4815C745; Mon, 01 Dec 2014 11:31:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417433474!14895849!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 583 invoked from network); 1 Dec 2014 11:31:15 -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;
	1 Dec 2014 11:31:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198352248"
Received: from ukmail1.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, 1 Dec 2014 06:31:13 -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 1XvPCD-00081Z-HJ;
	Mon, 01 Dec 2014 11:31:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 11:31:11 +0000
Message-ID: <1417433473-17272-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 v2 for-4.5 0/2] xl/libxl: fix API and 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

Return value of libxl_basename was erroneously marked as "const". This
series removes that "const" and fixes two memory leaks in xl.

I think these fixes should be included in 4.5, given that they fix real
issues and are very straight foward to reason about.

Wei.

Wei Liu (2):
  libxl: un-constify return value of libxl_basename
  xl: fix two memory leaks

 tools/libxl/libxl.h       |   10 ++++++++++
 tools/libxl/libxl_utils.c |    5 ++++-
 tools/libxl/libxl_utils.h |    6 +++++-
 tools/libxl/xl_cmdimpl.c  |    8 ++++++--
 4 files changed, 25 insertions(+), 4 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 Mon Dec 01 11:31:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:31:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPCJ-0003Cn-PI; Mon, 01 Dec 2014 11:31: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 1XvPCH-0003CM-U9
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:31:18 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	48/F8-17958-5815C745; Mon, 01 Dec 2014 11:31:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417433474!14895849!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 699 invoked from network); 1 Dec 2014 11:31:16 -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;
	1 Dec 2014 11:31:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198352249"
Received: from ukmail1.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, 1 Dec 2014 06:31:13 -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 1XvPCD-00081Z-JG;
	Mon, 01 Dec 2014 11:31:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 11:31:12 +0000
Message-ID: <1417433473-17272-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@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 v2 for-4.5 1/2] libxl: un-constify return value
	of libxl_basename
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The string returned is malloc'ed but marked as "const".

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.h       |   10 ++++++++++
 tools/libxl/libxl_utils.c |    5 ++++-
 tools/libxl/libxl_utils.h |    6 +++++-
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 41d6e8d..291c190 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -478,6 +478,16 @@ typedef struct libxl__ctx libxl_ctx;
 #endif
 
 /*
+ * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
+ *
+ * The return value of libxl_basename is malloc'ed but the erroneously
+ * marked as "const" in releases before 4.5.
+ */
+#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
+#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
+#endif
+
+/*
  * LIBXL_HAVE_PHYSINFO_OUTSTANDING_PAGES
  *
  * If this is defined, libxl_physinfo structure will contain an uint64 field
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 3e1ba17..22119fc 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -19,7 +19,10 @@
 
 #include "libxl_internal.h"
 
-const char *libxl_basename(const char *name)
+#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
+const
+#endif
+char *libxl_basename(const char *name)
 {
     const char *filename;
     if (name == NULL)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 117b229..8277eb9 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -18,7 +18,11 @@
 
 #include "libxl.h"
 
-const char *libxl_basename(const char *name); /* returns string from strdup */
+#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
+const
+#endif
+char *libxl_basename(const char *name); /* returns string from strdup */
+
 unsigned long libxl_get_required_shadow_memory(unsigned long maxmem_kb, unsigned int smp_cpus);
 int libxl_name_to_domid(libxl_ctx *ctx, const char *name, uint32_t *domid);
 int libxl_domain_qualifier_to_domid(libxl_ctx *ctx, const char *name, 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 Mon Dec 01 11:31:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:31:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPCK-0003Cz-5o; Mon, 01 Dec 2014 11:31: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 1XvPCI-0003CO-Gw
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:31:18 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	C5/37-28296-5815C745; Mon, 01 Dec 2014 11:31:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417433474!14895849!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 816 invoked from network); 1 Dec 2014 11:31: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;
	1 Dec 2014 11:31:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198352250"
Received: from ukmail1.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, 1 Dec 2014 06:31:13 -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 1XvPCD-00081Z-Jz;
	Mon, 01 Dec 2014 11:31:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 11:31:13 +0000
Message-ID: <1417433473-17272-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@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 v2 for-4.5 2/2] 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

Free strings returned by libxl_basename 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 |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0e754e7..fe3034f 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;
+    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,15 @@ 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(basename);
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
@@ -7023,7 +7026,7 @@ int main_cpupoolcreate(int argc, char **argv)
     int config_len = 0;
     XLU_Config *config;
     const char *buf;
-    const char *name;
+    char *name = NULL;
     uint32_t poolid;
     libxl_scheduler sched = 0;
     XLU_ConfigList *cpus;
@@ -7197,6 +7200,7 @@ int main_cpupoolcreate(int argc, char **argv)
 out_cfg:
     xlu_cfg_destroy(config);
 out:
+    free(name);
     free(config_data);
     return rc;
 }
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:32:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11: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 1XvPDP-0003WC-Kf; Mon, 01 Dec 2014 11:32:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XvPDO-0003W1-EZ
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 11:32:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D6/16-15461-9C15C745; Mon, 01 Dec 2014 11:32:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417433544!12516386!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 27528 invoked from network); 1 Dec 2014 11:32:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 11:32:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198352434"
Message-ID: <547C51AD.8070904@citrix.com>
Date: Mon, 1 Dec 2014 11:31:57 +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: 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>, <andrew.cooper3@citrix.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [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>
Content-Type: text/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:53, 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.

What are the results of the testing I asked for?

If Konrad or Boris are happy with this series I think it can go into 3.19.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:32:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11: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 1XvPDP-0003WC-Kf; Mon, 01 Dec 2014 11:32:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XvPDO-0003W1-EZ
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 11:32:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D6/16-15461-9C15C745; Mon, 01 Dec 2014 11:32:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417433544!12516386!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 27528 invoked from network); 1 Dec 2014 11:32:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 11:32:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198352434"
Message-ID: <547C51AD.8070904@citrix.com>
Date: Mon, 1 Dec 2014 11:31:57 +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: 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>, <andrew.cooper3@citrix.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [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>
Content-Type: text/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:53, 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.

What are the results of the testing I asked for?

If Konrad or Boris are happy with this series I think it can go into 3.19.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:40:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPKx-0003tc-Ix; Mon, 01 Dec 2014 11:40: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 1XvPKw-0003tX-0K
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:40:14 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	C9/FC-27785-D935C745; Mon, 01 Dec 2014 11:40:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417434011!12175043!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 19417 invoked from network); 1 Dec 2014 11:40: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;
	1 Dec 2014 11:40:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198028077"
Message-ID: <1417434009.29138.13.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 1 Dec 2014 11:40:09 +0000
In-Reply-To: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
References: <1417433473-17272-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: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 0/2] xl/libxl: fix API and 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

On Mon, 2014-12-01 at 11:31 +0000, Wei Liu wrote:
> Return value of libxl_basename was erroneously marked as "const". This
> series removes that "const" and fixes two memory leaks in xl.
> 
> I think these fixes should be included in 4.5, given that they fix real
> issues and are very straight foward to reason about.

Agreed. Both patches:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

I've added the CCs to this intro mail...

Did you by any chance look for other const char * return values?

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:40:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPKx-0003tc-Ix; Mon, 01 Dec 2014 11:40: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 1XvPKw-0003tX-0K
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:40:14 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	C9/FC-27785-D935C745; Mon, 01 Dec 2014 11:40:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417434011!12175043!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 19417 invoked from network); 1 Dec 2014 11:40: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;
	1 Dec 2014 11:40:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198028077"
Message-ID: <1417434009.29138.13.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 1 Dec 2014 11:40:09 +0000
In-Reply-To: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
References: <1417433473-17272-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: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 0/2] xl/libxl: fix API and 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

On Mon, 2014-12-01 at 11:31 +0000, Wei Liu wrote:
> Return value of libxl_basename was erroneously marked as "const". This
> series removes that "const" and fixes two memory leaks in xl.
> 
> I think these fixes should be included in 4.5, given that they fix real
> issues and are very straight foward to reason about.

Agreed. Both patches:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

I've added the CCs to this intro mail...

Did you by any chance look for other const char * return values?

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:43:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 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 1XvPNv-00042T-AT; Mon, 01 Dec 2014 11:43: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 1XvPNu-00042M-Hv
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:43:18 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	73/AA-02957-5545C745; Mon, 01 Dec 2014 11:43:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417434195!12169108!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25278 invoked from network); 1 Dec 2014 11:43:16 -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;
	1 Dec 2014 11:43:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198354541"
Message-ID: <1417434193.29138.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>
Date: Mon, 1 Dec 2014 11:43:13 +0000
In-Reply-To: <1417430384-26220-1-git-send-email-euan.harris@citrix.com>
References: <1417430384-26220-1-git-send-email-euan.harris@citrix.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] libxl/Makefile: Don't optimize debug builds;
 add macro debugging 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, 2014-12-01 at 10:39 +0000, Euan Harris wrote:
> libxl debug builds are built with optimization level -O1, inherited from
> the CFLAGS definition in StdGNU.mk.   Optimizations confuse the debugger,
> and the comment justifying -O1 in StdGNU.mk should not apply for a
> userspace library.   Disable optimization by appending -O0 to CFLAGS,
> which overrides the -O1 flag specified earlier.

I think if this argument applies (I see no reason to disagree) then it
should apply to the whole of tools/* or at least to tools/lib* and not
just to libxl. IOW this probably belongs at a higher level somewhere.

> Also specify -g3, to add macro debugging information which allows
> gdb to expand macro invocations.   This is useful as libxl uses many
> non-trivial macros.

Useful, I'd never heard of this. Do you know which version of gcc
introduced it? (AKA do we need to make it part of configure.ac to check
availability or not).

Not sure if you were proposing this change for 4.5 or not.

> 
> Signed-off-by: Euan Harris <euan.harris@citrix.com>
> ---
>  tools/libxl/Makefile |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index df08c8a..26d8679 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -15,6 +15,12 @@ CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
>  	-Wno-declaration-after-statement -Wformat-nonliteral
>  CFLAGS += -I. -fPIC
>  
> +ifeq ($(debug),y)
> +# Disable optimizations and debugging information for macros
> +CFLAGS += -O0 -g3
> +endif
> +
> +
>  ifeq ($(CONFIG_Linux),y)
>  LIBUUID_LIBS += -luuid
>  endif



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:43:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 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 1XvPNv-00042T-AT; Mon, 01 Dec 2014 11:43: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 1XvPNu-00042M-Hv
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:43:18 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	73/AA-02957-5545C745; Mon, 01 Dec 2014 11:43:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417434195!12169108!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25278 invoked from network); 1 Dec 2014 11:43:16 -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;
	1 Dec 2014 11:43:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198354541"
Message-ID: <1417434193.29138.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>
Date: Mon, 1 Dec 2014 11:43:13 +0000
In-Reply-To: <1417430384-26220-1-git-send-email-euan.harris@citrix.com>
References: <1417430384-26220-1-git-send-email-euan.harris@citrix.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] libxl/Makefile: Don't optimize debug builds;
 add macro debugging 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, 2014-12-01 at 10:39 +0000, Euan Harris wrote:
> libxl debug builds are built with optimization level -O1, inherited from
> the CFLAGS definition in StdGNU.mk.   Optimizations confuse the debugger,
> and the comment justifying -O1 in StdGNU.mk should not apply for a
> userspace library.   Disable optimization by appending -O0 to CFLAGS,
> which overrides the -O1 flag specified earlier.

I think if this argument applies (I see no reason to disagree) then it
should apply to the whole of tools/* or at least to tools/lib* and not
just to libxl. IOW this probably belongs at a higher level somewhere.

> Also specify -g3, to add macro debugging information which allows
> gdb to expand macro invocations.   This is useful as libxl uses many
> non-trivial macros.

Useful, I'd never heard of this. Do you know which version of gcc
introduced it? (AKA do we need to make it part of configure.ac to check
availability or not).

Not sure if you were proposing this change for 4.5 or not.

> 
> Signed-off-by: Euan Harris <euan.harris@citrix.com>
> ---
>  tools/libxl/Makefile |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index df08c8a..26d8679 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -15,6 +15,12 @@ CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
>  	-Wno-declaration-after-statement -Wformat-nonliteral
>  CFLAGS += -I. -fPIC
>  
> +ifeq ($(debug),y)
> +# Disable optimizations and debugging information for macros
> +CFLAGS += -O0 -g3
> +endif
> +
> +
>  ifeq ($(CONFIG_Linux),y)
>  LIBUUID_LIBS += -luuid
>  endif



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:51:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPVB-0004DS-7N; Mon, 01 Dec 2014 11:50: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 1XvPV9-0004DN-F0
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:50:47 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	22/4A-03145-6165C745; Mon, 01 Dec 2014 11:50:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417434645!12140747!1
X-Originating-IP: [66.165.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 10928 invoked from network); 1 Dec 2014 11:50:46 -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;
	1 Dec 2014 11:50:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198356489"
Received: from ukmail1.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, 1 Dec 2014 06:50: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 1XvPV6-0000PR-6N;
	Mon, 01 Dec 2014 11:50:44 +0000
Date: Mon, 1 Dec 2014 11:50:44 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201115044.GA19889@zion.uk.xensource.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<1417434009.29138.13.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417434009.29138.13.camel@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>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 0/2] xl/libxl: fix API and 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

On Mon, Dec 01, 2014 at 11:40:09AM +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 11:31 +0000, Wei Liu wrote:
> > Return value of libxl_basename was erroneously marked as "const". This
> > series removes that "const" and fixes two memory leaks in xl.
> > 
> > I think these fixes should be included in 4.5, given that they fix real
> > issues and are very straight foward to reason about.
> 
> Agreed. Both patches:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I've added the CCs to this intro mail...
> 
> Did you by any chance look for other const char * return values?
> 

I've looked at other public API headers. I didn't spot other obvious
problems with regard to const char * return values.

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 Dec 01 11:51:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPVB-0004DS-7N; Mon, 01 Dec 2014 11:50: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 1XvPV9-0004DN-F0
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:50:47 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	22/4A-03145-6165C745; Mon, 01 Dec 2014 11:50:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417434645!12140747!1
X-Originating-IP: [66.165.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 10928 invoked from network); 1 Dec 2014 11:50:46 -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;
	1 Dec 2014 11:50:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198356489"
Received: from ukmail1.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, 1 Dec 2014 06:50: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 1XvPV6-0000PR-6N;
	Mon, 01 Dec 2014 11:50:44 +0000
Date: Mon, 1 Dec 2014 11:50:44 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201115044.GA19889@zion.uk.xensource.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<1417434009.29138.13.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417434009.29138.13.camel@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>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 0/2] xl/libxl: fix API and 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

On Mon, Dec 01, 2014 at 11:40:09AM +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 11:31 +0000, Wei Liu wrote:
> > Return value of libxl_basename was erroneously marked as "const". This
> > series removes that "const" and fixes two memory leaks in xl.
> > 
> > I think these fixes should be included in 4.5, given that they fix real
> > issues and are very straight foward to reason about.
> 
> Agreed. Both patches:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I've added the CCs to this intro mail...
> 
> Did you by any chance look for other const char * return values?
> 

I've looked at other public API headers. I didn't spot other obvious
problems with regard to const char * return values.

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 Dec 01 11:51:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:51:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPVi-0004Fo-KZ; Mon, 01 Dec 2014 11:51: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 1XvPVh-0004FZ-49
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:51:21 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	DB/EE-17735-8365C745; Mon, 01 Dec 2014 11:51:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417434678!14964257!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20410 invoked from network); 1 Dec 2014 11:51:19 -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;
	1 Dec 2014 11:51:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198356619"
Message-ID: <1417434675.29138.17.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 1 Dec 2014 11:51:15 +0000
In-Reply-To: <20141201115044.GA19889@zion.uk.xensource.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<1417434009.29138.13.camel@citrix.com>
	<20141201115044.GA19889@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 <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 0/2] xl/libxl: fix API and 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

On Mon, 2014-12-01 at 11:50 +0000, Wei Liu wrote:
> On Mon, Dec 01, 2014 at 11:40:09AM +0000, Ian Campbell wrote:
> > On Mon, 2014-12-01 at 11:31 +0000, Wei Liu wrote:
> > > Return value of libxl_basename was erroneously marked as "const". This
> > > series removes that "const" and fixes two memory leaks in xl.
> > > 
> > > I think these fixes should be included in 4.5, given that they fix real
> > > issues and are very straight foward to reason about.
> > 
> > Agreed. Both patches:
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > I've added the CCs to this intro mail...
> > 
> > Did you by any chance look for other const char * return values?
> > 
> 
> I've looked at other public API headers. I didn't spot other obvious
> problems with regard to const char * return values.

Super, thanks!



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:51:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:51:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPVi-0004Fo-KZ; Mon, 01 Dec 2014 11:51: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 1XvPVh-0004FZ-49
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:51:21 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	DB/EE-17735-8365C745; Mon, 01 Dec 2014 11:51:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417434678!14964257!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20410 invoked from network); 1 Dec 2014 11:51:19 -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;
	1 Dec 2014 11:51:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198356619"
Message-ID: <1417434675.29138.17.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 1 Dec 2014 11:51:15 +0000
In-Reply-To: <20141201115044.GA19889@zion.uk.xensource.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<1417434009.29138.13.camel@citrix.com>
	<20141201115044.GA19889@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 <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 0/2] xl/libxl: fix API and 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

On Mon, 2014-12-01 at 11:50 +0000, Wei Liu wrote:
> On Mon, Dec 01, 2014 at 11:40:09AM +0000, Ian Campbell wrote:
> > On Mon, 2014-12-01 at 11:31 +0000, Wei Liu wrote:
> > > Return value of libxl_basename was erroneously marked as "const". This
> > > series removes that "const" and fixes two memory leaks in xl.
> > > 
> > > I think these fixes should be included in 4.5, given that they fix real
> > > issues and are very straight foward to reason about.
> > 
> > Agreed. Both patches:
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > I've added the CCs to this intro mail...
> > 
> > Did you by any chance look for other const char * return values?
> > 
> 
> I've looked at other public API headers. I didn't spot other obvious
> problems with regard to const char * return values.

Super, thanks!



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:52:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPWl-0004Rh-8F; Mon, 01 Dec 2014 11:52: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 1XvPWk-0004RJ-As
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 11:52:26 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	20/CD-03145-9765C745; Mon, 01 Dec 2014 11:52:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417434742!12152140!1
X-Originating-IP: [66.165.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 15795 invoked from network); 1 Dec 2014 11:52:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 11:52:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198356845"
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, 1 Dec 2014 06:52: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 1XvPWQ-0002zm-GS;
	Mon, 01 Dec 2014 11:52:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvPWQ-0007d1-AI;
	Mon, 01 Dec 2014 11:52:06 +0000
Date: Mon, 1 Dec 2014 11:52:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31960-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] 31960: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

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-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                7a5a4f978750756755dc839014e13d1b088ccc8e
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
700 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 30710 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 Dec 01 11:52:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPWl-0004Rh-8F; Mon, 01 Dec 2014 11:52: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 1XvPWk-0004RJ-As
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 11:52:26 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	20/CD-03145-9765C745; Mon, 01 Dec 2014 11:52:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417434742!12152140!1
X-Originating-IP: [66.165.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 15795 invoked from network); 1 Dec 2014 11:52:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 11:52:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198356845"
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, 1 Dec 2014 06:52: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 1XvPWQ-0002zm-GS;
	Mon, 01 Dec 2014 11:52:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvPWQ-0007d1-AI;
	Mon, 01 Dec 2014 11:52:06 +0000
Date: Mon, 1 Dec 2014 11:52:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31960-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] 31960: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

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-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                7a5a4f978750756755dc839014e13d1b088ccc8e
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
700 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 30710 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 Dec 01 11:55:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPZu-0004jy-Rc; Mon, 01 Dec 2014 11:55:42 +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 1XvPZt-0004jo-3U
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:55:41 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1A/D3-15461-C375C745; Mon, 01 Dec 2014 11:55:40 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417434939!12523210!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18609 invoked from network); 1 Dec 2014 11:55:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 11:55:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="27307411"
Date: Mon, 1 Dec 2014 11:55:21 +0000
From: Euan Harris <euan.harris@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201115521.GB3731@citrix.com>
References: <1417430384-26220-1-git-send-email-euan.harris@citrix.com>
	<1417434193.29138.14.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417434193.29138.14.camel@citrix.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
X-DLP: AMS1
Cc: Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl/Makefile: Don't optimize debug builds;
 add macro debugging 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, Dec 01, 2014 at 11:43:13AM +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 10:39 +0000, Euan Harris wrote:
> > libxl debug builds are built with optimization level -O1, inherited from
> > the CFLAGS definition in StdGNU.mk.   Optimizations confuse the debugger,
> > and the comment justifying -O1 in StdGNU.mk should not apply for a
> > userspace library.   Disable optimization by appending -O0 to CFLAGS,
> > which overrides the -O1 flag specified earlier.
> 
> I think if this argument applies (I see no reason to disagree) then it
> should apply to the whole of tools/* or at least to tools/lib* and not
> just to libxl. IOW this probably belongs at a higher level somewhere.

Ok, I'll submit a new patch putting it in tools/Rules.mk

> > Also specify -g3, to add macro debugging information which allows
> > gdb to expand macro invocations.   This is useful as libxl uses many
> > non-trivial macros.
> 
> Useful, I'd never heard of this. Do you know which version of gcc
> introduced it? (AKA do we need to make it part of configure.ac to check
> availability or not).

It's documented in GCC 2.95.3 [1], which is as far back as the online
manuals go.

[1] https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC9

> Not sure if you were proposing this change for 4.5 or not.

It would be nice to have, but I was assuming that 4.5 was more or less
closed by now.

Thanks,
Euan

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 11:55:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 11:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPZu-0004jy-Rc; Mon, 01 Dec 2014 11:55:42 +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 1XvPZt-0004jo-3U
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 11:55:41 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1A/D3-15461-C375C745; Mon, 01 Dec 2014 11:55:40 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417434939!12523210!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18609 invoked from network); 1 Dec 2014 11:55:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 11:55:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="27307411"
Date: Mon, 1 Dec 2014 11:55:21 +0000
From: Euan Harris <euan.harris@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201115521.GB3731@citrix.com>
References: <1417430384-26220-1-git-send-email-euan.harris@citrix.com>
	<1417434193.29138.14.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417434193.29138.14.camel@citrix.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
X-DLP: AMS1
Cc: Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl/Makefile: Don't optimize debug builds;
 add macro debugging 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, Dec 01, 2014 at 11:43:13AM +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 10:39 +0000, Euan Harris wrote:
> > libxl debug builds are built with optimization level -O1, inherited from
> > the CFLAGS definition in StdGNU.mk.   Optimizations confuse the debugger,
> > and the comment justifying -O1 in StdGNU.mk should not apply for a
> > userspace library.   Disable optimization by appending -O0 to CFLAGS,
> > which overrides the -O1 flag specified earlier.
> 
> I think if this argument applies (I see no reason to disagree) then it
> should apply to the whole of tools/* or at least to tools/lib* and not
> just to libxl. IOW this probably belongs at a higher level somewhere.

Ok, I'll submit a new patch putting it in tools/Rules.mk

> > Also specify -g3, to add macro debugging information which allows
> > gdb to expand macro invocations.   This is useful as libxl uses many
> > non-trivial macros.
> 
> Useful, I'd never heard of this. Do you know which version of gcc
> introduced it? (AKA do we need to make it part of configure.ac to check
> availability or not).

It's documented in GCC 2.95.3 [1], which is as far back as the online
manuals go.

[1] https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC9

> Not sure if you were proposing this change for 4.5 or not.

It would be nice to have, but I was assuming that 4.5 was more or less
closed by now.

Thanks,
Euan

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:13:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvPr3-0005CY-Pe; Mon, 01 Dec 2014 12:13:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XvPr2-0005CQ-E3
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:13:24 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	B5/B0-05632-36B5C745; Mon, 01 Dec 2014 12:13:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417436002!14970718!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 32399 invoked from network); 1 Dec 2014 12:13:23 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 12:13:23 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XvPqe-000KPE-19; Mon, 01 Dec 2014 12:13:00 +0000
Date: Mon, 1 Dec 2014 13:13:00 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141201121300.GB69236@deinos.phlegethon.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C5C43020000780004BAFD@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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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

At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
> >>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
> > At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
> >> >>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
> >> > To my understanding, pages with p2m_ram_ro are not supposed to be 
> >> > modified by guest. So in __hvm_copy(), when p2m type of a page is 
> >> > p2m_ram_rom, no copy will occur.
> >> > However, to our usage, we just wanna this page to be write protected, so 
> >> > that our device model can be triggered to do some emulation. The content 
> >> > written to this page is supposed not to be dropped. This way, if 
> >> > sequentially a read operation is performed by guest to this page, the 
> >> > guest will still see its anticipated value.
> >> 
> >> __hvm_copy() is only a helper function, and doesn't write to
> >> mmio_dm space either; instead its (indirect) callers would invoke
> >> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
> >> returns. The question hence is about the apparent inconsistency
> >> resulting from writes to ram_ro being dropped here but getting
> >> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
> >> that really intentional?
> > 
> > No - and AFAICT it shouldn't be happening.  It _is_ how it was
> > implemented originally, because it involved fewer moving parts and
> > didn't need to be efficient (and after all, writes to entirely missing
> > addresses go to the device model too).
> > 
> > But the code was later updated to log and discard writes to read-only
> > memory (see 4d8aa29 from Trolle Selander).
> > 
> > Early version of p2m_ram_ro were documented in the internal headers as
> > sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
> > has always said that writes are discarded.
> 
> Hmm, so which way do you recommend resolving the inconsistency
> then - match what the public interface says or what the apparent
> original intention for the internal type was? Presumably we need to
> follow the public interface mandated model, and hence require the
> new type to be introduced.

Sorry, I was unclear -- there isn't an inconsistency; both internal
and public headers currently say that writes are discarded and AFAICT
that is what the code does.

But yes, we ought to follow the established hypercall interface, and
so we need the new type.

> > During this bit of archaeology I realised that either this new type
> > should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
> > class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
> > for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
> > just p2m_ram_ro and p2m_grant_map_ro.
> 
> And I suppose in that latter case the new type could be made part
> of P2M_RO_TYPES()?

Yes indeed, as P2M_RO_TYPES is defined as "must have the _PAGE_RW bit
clear in their PTEs".

Cheers,

Tim.

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:13:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvPqZ-00059y-Ct; Mon, 01 Dec 2014 12:12: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 1XvPqX-00059n-Ej
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:12:53 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C1/BD-02696-44B5C745; Mon, 01 Dec 2014 12:12:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417435970!12184476!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 8683 invoked from network); 1 Dec 2014 12:12:52 -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;
	1 Dec 2014 12:12:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198036059"
Message-ID: <1417435968.29138.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>
Date: Mon, 1 Dec 2014 12:12:48 +0000
In-Reply-To: <20141201115521.GB3731@citrix.com>
References: <1417430384-26220-1-git-send-email-euan.harris@citrix.com>
	<1417434193.29138.14.camel@citrix.com>
	<20141201115521.GB3731@citrix.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] libxl/Makefile: Don't optimize debug builds;
 add macro debugging 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, 2014-12-01 at 11:55 +0000, Euan Harris wrote:
> On Mon, Dec 01, 2014 at 11:43:13AM +0000, Ian Campbell wrote:
> > On Mon, 2014-12-01 at 10:39 +0000, Euan Harris wrote:
> > > libxl debug builds are built with optimization level -O1, inherited from
> > > the CFLAGS definition in StdGNU.mk.   Optimizations confuse the debugger,
> > > and the comment justifying -O1 in StdGNU.mk should not apply for a
> > > userspace library.   Disable optimization by appending -O0 to CFLAGS,
> > > which overrides the -O1 flag specified earlier.
> > 
> > I think if this argument applies (I see no reason to disagree) then it
> > should apply to the whole of tools/* or at least to tools/lib* and not
> > just to libxl. IOW this probably belongs at a higher level somewhere.
> 
> Ok, I'll submit a new patch putting it in tools/Rules.mk

Thanks.

> > > Also specify -g3, to add macro debugging information which allows
> > > gdb to expand macro invocations.   This is useful as libxl uses many
> > > non-trivial macros.
> > 
> > Useful, I'd never heard of this. Do you know which version of gcc
> > introduced it? (AKA do we need to make it part of configure.ac to check
> > availability or not).
> 
> It's documented in GCC 2.95.3 [1], which is as far back as the online
> manuals go.
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC9

OK, I'm pretty sure that's (way....) before our cut-off. Thanks.

> > Not sure if you were proposing this change for 4.5 or not.
> 
> It would be nice to have, but I was assuming that 4.5 was more or less
> closed by now.

Exceptions can be asked/argued for. I'd be a bit wary of something like
this since the knock-on effects might be a bit subtle. Completely fine
during a dev window though.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:13:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvPqZ-00059y-Ct; Mon, 01 Dec 2014 12:12: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 1XvPqX-00059n-Ej
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:12:53 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C1/BD-02696-44B5C745; Mon, 01 Dec 2014 12:12:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417435970!12184476!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 8683 invoked from network); 1 Dec 2014 12:12:52 -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;
	1 Dec 2014 12:12:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198036059"
Message-ID: <1417435968.29138.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>
Date: Mon, 1 Dec 2014 12:12:48 +0000
In-Reply-To: <20141201115521.GB3731@citrix.com>
References: <1417430384-26220-1-git-send-email-euan.harris@citrix.com>
	<1417434193.29138.14.camel@citrix.com>
	<20141201115521.GB3731@citrix.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] libxl/Makefile: Don't optimize debug builds;
 add macro debugging 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, 2014-12-01 at 11:55 +0000, Euan Harris wrote:
> On Mon, Dec 01, 2014 at 11:43:13AM +0000, Ian Campbell wrote:
> > On Mon, 2014-12-01 at 10:39 +0000, Euan Harris wrote:
> > > libxl debug builds are built with optimization level -O1, inherited from
> > > the CFLAGS definition in StdGNU.mk.   Optimizations confuse the debugger,
> > > and the comment justifying -O1 in StdGNU.mk should not apply for a
> > > userspace library.   Disable optimization by appending -O0 to CFLAGS,
> > > which overrides the -O1 flag specified earlier.
> > 
> > I think if this argument applies (I see no reason to disagree) then it
> > should apply to the whole of tools/* or at least to tools/lib* and not
> > just to libxl. IOW this probably belongs at a higher level somewhere.
> 
> Ok, I'll submit a new patch putting it in tools/Rules.mk

Thanks.

> > > Also specify -g3, to add macro debugging information which allows
> > > gdb to expand macro invocations.   This is useful as libxl uses many
> > > non-trivial macros.
> > 
> > Useful, I'd never heard of this. Do you know which version of gcc
> > introduced it? (AKA do we need to make it part of configure.ac to check
> > availability or not).
> 
> It's documented in GCC 2.95.3 [1], which is as far back as the online
> manuals go.
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC9

OK, I'm pretty sure that's (way....) before our cut-off. Thanks.

> > Not sure if you were proposing this change for 4.5 or not.
> 
> It would be nice to have, but I was assuming that 4.5 was more or less
> closed by now.

Exceptions can be asked/argued for. I'd be a bit wary of something like
this since the knock-on effects might be a bit subtle. Completely fine
during a dev window though.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:13:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvPr3-0005CY-Pe; Mon, 01 Dec 2014 12:13:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XvPr2-0005CQ-E3
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:13:24 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	B5/B0-05632-36B5C745; Mon, 01 Dec 2014 12:13:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417436002!14970718!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 32399 invoked from network); 1 Dec 2014 12:13:23 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 12:13:23 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XvPqe-000KPE-19; Mon, 01 Dec 2014 12:13:00 +0000
Date: Mon, 1 Dec 2014 13:13:00 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141201121300.GB69236@deinos.phlegethon.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C5C43020000780004BAFD@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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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

At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
> >>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
> > At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
> >> >>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
> >> > To my understanding, pages with p2m_ram_ro are not supposed to be 
> >> > modified by guest. So in __hvm_copy(), when p2m type of a page is 
> >> > p2m_ram_rom, no copy will occur.
> >> > However, to our usage, we just wanna this page to be write protected, so 
> >> > that our device model can be triggered to do some emulation. The content 
> >> > written to this page is supposed not to be dropped. This way, if 
> >> > sequentially a read operation is performed by guest to this page, the 
> >> > guest will still see its anticipated value.
> >> 
> >> __hvm_copy() is only a helper function, and doesn't write to
> >> mmio_dm space either; instead its (indirect) callers would invoke
> >> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
> >> returns. The question hence is about the apparent inconsistency
> >> resulting from writes to ram_ro being dropped here but getting
> >> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
> >> that really intentional?
> > 
> > No - and AFAICT it shouldn't be happening.  It _is_ how it was
> > implemented originally, because it involved fewer moving parts and
> > didn't need to be efficient (and after all, writes to entirely missing
> > addresses go to the device model too).
> > 
> > But the code was later updated to log and discard writes to read-only
> > memory (see 4d8aa29 from Trolle Selander).
> > 
> > Early version of p2m_ram_ro were documented in the internal headers as
> > sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
> > has always said that writes are discarded.
> 
> Hmm, so which way do you recommend resolving the inconsistency
> then - match what the public interface says or what the apparent
> original intention for the internal type was? Presumably we need to
> follow the public interface mandated model, and hence require the
> new type to be introduced.

Sorry, I was unclear -- there isn't an inconsistency; both internal
and public headers currently say that writes are discarded and AFAICT
that is what the code does.

But yes, we ought to follow the established hypercall interface, and
so we need the new type.

> > During this bit of archaeology I realised that either this new type
> > should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
> > class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
> > for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
> > just p2m_ram_ro and p2m_grant_map_ro.
> 
> And I suppose in that latter case the new type could be made part
> of P2M_RO_TYPES()?

Yes indeed, as P2M_RO_TYPES is defined as "must have the _PAGE_RW bit
clear in their PTEs".

Cheers,

Tim.

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:20:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:20:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPxQ-0005UV-PK; Mon, 01 Dec 2014 12:20:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvPxP-0005UG-NT
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 12:19:59 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	7E/1D-08051-EEC5C745; Mon, 01 Dec 2014 12:19:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417436396!8844356!1
X-Originating-IP: [66.165.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 32049 invoked from network); 1 Dec 2014 12:19:57 -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;
	1 Dec 2014 12:19:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198037855"
Received: from ukmail1.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, 1 Dec 2014 07:19: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 1XvPxL-0001ft-BG;
	Mon, 01 Dec 2014 12:19:55 +0000
Date: Mon, 1 Dec 2014 12:19:55 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201121955.GB19889@zion.uk.xensource.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417426933.23604.77.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, Ed Swierk <eswierk@skyportsystems.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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 Mon, Dec 01, 2014 at 09:42:13AM +0000, Ian Campbell wrote:
> On Sat, 2014-11-29 at 21:23 -0800, Ed Swierk wrote:
> > - Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
> >   parameter
> > - Change deprecated %name-prefix= to %name-prefix
> > 
> > Tested against bison 2.4.1 and 3.0.2.
> > 
> > Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
> 
> Copying Ian J who is the bison guy among the toolstack maintainers.
> 

FWIW I can confirm that libxlu_cfg_y.y won't build in Debian Jessie
(bison 3.0.2) as is. And this patch fixes the problem for me.

Wei.

> > ---
> >  tools/libxl/libxlu_cfg_y.y | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
> > index aa9f787..5acd438 100644
> > --- a/tools/libxl/libxlu_cfg_y.y
> > +++ b/tools/libxl/libxlu_cfg_y.y
> > @@ -17,7 +17,7 @@
> >   */
> >  
> >  %{
> > -#define YYLEX_PARAM ctx->scanner
> > +#define ctx_scanner ctx->scanner
> >  #include "libxlu_cfg_i.h"
> >  #include "libxlu_cfg_l.h"
> >  %}
> > @@ -31,9 +31,9 @@
> >  %pure-parser
> >  %defines
> >  %error-verbose
> > -%name-prefix="xlu__cfg_yy"
> > +%name-prefix "xlu__cfg_yy"
> >  %parse-param { CfgParseContext *ctx }
> > -%lex-param { void *scanner }
> > +%lex-param { ctx_scanner }
> >  
> >  %token <string>                IDENT STRING NUMBER NEWLINE
> >  %type <string>            atom
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 01 12:20:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:20:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvPxQ-0005UV-PK; Mon, 01 Dec 2014 12:20:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvPxP-0005UG-NT
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 12:19:59 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	7E/1D-08051-EEC5C745; Mon, 01 Dec 2014 12:19:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417436396!8844356!1
X-Originating-IP: [66.165.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 32049 invoked from network); 1 Dec 2014 12:19:57 -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;
	1 Dec 2014 12:19:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198037855"
Received: from ukmail1.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, 1 Dec 2014 07:19: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 1XvPxL-0001ft-BG;
	Mon, 01 Dec 2014 12:19:55 +0000
Date: Mon, 1 Dec 2014 12:19:55 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201121955.GB19889@zion.uk.xensource.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417426933.23604.77.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, Ed Swierk <eswierk@skyportsystems.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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 Mon, Dec 01, 2014 at 09:42:13AM +0000, Ian Campbell wrote:
> On Sat, 2014-11-29 at 21:23 -0800, Ed Swierk wrote:
> > - Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
> >   parameter
> > - Change deprecated %name-prefix= to %name-prefix
> > 
> > Tested against bison 2.4.1 and 3.0.2.
> > 
> > Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
> 
> Copying Ian J who is the bison guy among the toolstack maintainers.
> 

FWIW I can confirm that libxlu_cfg_y.y won't build in Debian Jessie
(bison 3.0.2) as is. And this patch fixes the problem for me.

Wei.

> > ---
> >  tools/libxl/libxlu_cfg_y.y | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
> > index aa9f787..5acd438 100644
> > --- a/tools/libxl/libxlu_cfg_y.y
> > +++ b/tools/libxl/libxlu_cfg_y.y
> > @@ -17,7 +17,7 @@
> >   */
> >  
> >  %{
> > -#define YYLEX_PARAM ctx->scanner
> > +#define ctx_scanner ctx->scanner
> >  #include "libxlu_cfg_i.h"
> >  #include "libxlu_cfg_l.h"
> >  %}
> > @@ -31,9 +31,9 @@
> >  %pure-parser
> >  %defines
> >  %error-verbose
> > -%name-prefix="xlu__cfg_yy"
> > +%name-prefix "xlu__cfg_yy"
> >  %parse-param { CfgParseContext *ctx }
> > -%lex-param { void *scanner }
> > +%lex-param { ctx_scanner }
> >  
> >  %token <string>                IDENT STRING NUMBER NEWLINE
> >  %type <string>            atom
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 01 12:31:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:31:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQ8F-0006BW-1u; Mon, 01 Dec 2014 12:31: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 1XvQ8D-0006BO-6i
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:31:09 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	76/6F-11581-C8F5C745; Mon, 01 Dec 2014 12:31:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417437067!10797790!1
X-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 1097 invoked from network); 1 Dec 2014 12:31:07 -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; 1 Dec 2014 12:31:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 12:31:07 +0000
Message-Id: <547C6D98020000780004BB9D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 12:31:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
In-Reply-To: <20141201121300.GB69236@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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 01.12.14 at 13:13, <tim@xen.org> wrote:
> At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>> >>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>> > At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
>> >> >>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
>> >> > To my understanding, pages with p2m_ram_ro are not supposed to be 
>> >> > modified by guest. So in __hvm_copy(), when p2m type of a page is 
>> >> > p2m_ram_rom, no copy will occur.
>> >> > However, to our usage, we just wanna this page to be write protected, so 
>> >> > that our device model can be triggered to do some emulation. The content 
>> >> > written to this page is supposed not to be dropped. This way, if 
>> >> > sequentially a read operation is performed by guest to this page, the 
>> >> > guest will still see its anticipated value.
>> >> 
>> >> __hvm_copy() is only a helper function, and doesn't write to
>> >> mmio_dm space either; instead its (indirect) callers would invoke
>> >> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
>> >> returns. The question hence is about the apparent inconsistency
>> >> resulting from writes to ram_ro being dropped here but getting
>> >> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
>> >> that really intentional?
>> > 
>> > No - and AFAICT it shouldn't be happening.  It _is_ how it was
>> > implemented originally, because it involved fewer moving parts and
>> > didn't need to be efficient (and after all, writes to entirely missing
>> > addresses go to the device model too).
>> > 
>> > But the code was later updated to log and discard writes to read-only
>> > memory (see 4d8aa29 from Trolle Selander).
>> > 
>> > Early version of p2m_ram_ro were documented in the internal headers as
>> > sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
>> > has always said that writes are discarded.
>> 
>> Hmm, so which way do you recommend resolving the inconsistency
>> then - match what the public interface says or what the apparent
>> original intention for the internal type was? Presumably we need to
>> follow the public interface mandated model, and hence require the
>> new type to be introduced.
> 
> Sorry, I was unclear -- there isn't an inconsistency; both internal
> and public headers currently say that writes are discarded and AFAICT
> that is what the code does.

Not for hvm_hap_nested_page_fault() afaict - the forwarding to
DM there contradicts the "writes are discarded" model that other
code paths follow.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:31:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:31:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQ8F-0006BW-1u; Mon, 01 Dec 2014 12:31: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 1XvQ8D-0006BO-6i
	for Xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:31:09 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	76/6F-11581-C8F5C745; Mon, 01 Dec 2014 12:31:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417437067!10797790!1
X-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 1097 invoked from network); 1 Dec 2014 12:31:07 -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; 1 Dec 2014 12:31:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 12:31:07 +0000
Message-Id: <547C6D98020000780004BB9D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 12:31:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
In-Reply-To: <20141201121300.GB69236@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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 01.12.14 at 13:13, <tim@xen.org> wrote:
> At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>> >>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>> > At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
>> >> >>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
>> >> > To my understanding, pages with p2m_ram_ro are not supposed to be 
>> >> > modified by guest. So in __hvm_copy(), when p2m type of a page is 
>> >> > p2m_ram_rom, no copy will occur.
>> >> > However, to our usage, we just wanna this page to be write protected, so 
>> >> > that our device model can be triggered to do some emulation. The content 
>> >> > written to this page is supposed not to be dropped. This way, if 
>> >> > sequentially a read operation is performed by guest to this page, the 
>> >> > guest will still see its anticipated value.
>> >> 
>> >> __hvm_copy() is only a helper function, and doesn't write to
>> >> mmio_dm space either; instead its (indirect) callers would invoke
>> >> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
>> >> returns. The question hence is about the apparent inconsistency
>> >> resulting from writes to ram_ro being dropped here but getting
>> >> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
>> >> that really intentional?
>> > 
>> > No - and AFAICT it shouldn't be happening.  It _is_ how it was
>> > implemented originally, because it involved fewer moving parts and
>> > didn't need to be efficient (and after all, writes to entirely missing
>> > addresses go to the device model too).
>> > 
>> > But the code was later updated to log and discard writes to read-only
>> > memory (see 4d8aa29 from Trolle Selander).
>> > 
>> > Early version of p2m_ram_ro were documented in the internal headers as
>> > sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
>> > has always said that writes are discarded.
>> 
>> Hmm, so which way do you recommend resolving the inconsistency
>> then - match what the public interface says or what the apparent
>> original intention for the internal type was? Presumably we need to
>> follow the public interface mandated model, and hence require the
>> new type to be introduced.
> 
> Sorry, I was unclear -- there isn't an inconsistency; both internal
> and public headers currently say that writes are discarded and AFAICT
> that is what the code does.

Not for hvm_hap_nested_page_fault() afaict - the forwarding to
DM there contradicts the "writes are discarded" model that other
code paths follow.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:54:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQUc-0006gk-4w; Mon, 01 Dec 2014 12:54:18 +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 1XvQUa-0006gf-FD
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 12:54:16 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	1B/EA-08051-7F46C745; Mon, 01 Dec 2014 12:54:15 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417438455!12199155!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 29824 invoked from network); 1 Dec 2014 12:54:15 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 12:54:15 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 2EBA4AB09;
	Mon,  1 Dec 2014 12:54:13 +0000 (UTC)
Message-ID: <547C64F3.9050005@suse.com>
Date: Mon, 01 Dec 2014 13:54: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: 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, andrew.cooper3@citrix.com
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
	<547C51AD.8070904@citrix.com>
In-Reply-To: <547C51AD.8070904@citrix.com>
Subject: Re: [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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/01/2014 12:31 PM, David Vrabel wrote:
> On 28/11/14 10:53, 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.
>
> What are the results of the testing I asked for?

You asked for those replying to the patch introducing the linear
mapping. So I added the description of the tested scenarios in the
patch description of that patch.

> If Konrad or Boris are happy with this series I think it can go into 3.19.

Great, thanks!


Juergen


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:54:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQUc-0006gk-4w; Mon, 01 Dec 2014 12:54:18 +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 1XvQUa-0006gf-FD
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 12:54:16 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	1B/EA-08051-7F46C745; Mon, 01 Dec 2014 12:54:15 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417438455!12199155!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 29824 invoked from network); 1 Dec 2014 12:54:15 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 12:54:15 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 2EBA4AB09;
	Mon,  1 Dec 2014 12:54:13 +0000 (UTC)
Message-ID: <547C64F3.9050005@suse.com>
Date: Mon, 01 Dec 2014 13:54: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: 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, andrew.cooper3@citrix.com
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
	<547C51AD.8070904@citrix.com>
In-Reply-To: <547C51AD.8070904@citrix.com>
Subject: Re: [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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/01/2014 12:31 PM, David Vrabel wrote:
> On 28/11/14 10:53, 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.
>
> What are the results of the testing I asked for?

You asked for those replying to the patch introducing the linear
mapping. So I added the description of the tested scenarios in the
patch description of that patch.

> If Konrad or Boris are happy with this series I think it can go into 3.19.

Great, thanks!


Juergen


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:56:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQWX-0006mJ-LO; Mon, 01 Dec 2014 12:56: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 1XvQWW-0006mC-1j
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:56:16 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	78/52-22737-F656C745; Mon, 01 Dec 2014 12:56:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417438573!6691237!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 10798 invoked from network); 1 Dec 2014 12:56:14 -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;
	1 Dec 2014 12:56:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198045944"
Message-ID: <1417438571.29138.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:56:11 +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/19] add distro domU testing flight
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

The following series adds a new flight type intended to test distro domU
support, i.e. running distro installers and kernels on top of current
Xen to ensure things work. I intend for the flight to be run on a weekly
basis, and I've scheduled it here to run at the weekend when in theory
things might be quieter.

I've initially just done Debian PV domU support since Debian is what I
know, but I hope others will add other distros as time goes on.

The series introduces support for running the Debian Installer in a PV
domU booting from netboot (PXE-ish) and netinst (ISO media) and adding
jobs to test all of those for Squeeze onwards up to Sid and the
daily/weekly builds (CDs are built daily, DVDs weekly).

The flight is a bit unusual since distro installer builds are not really
versioned in a way which is useful to osstest, so instead each flight
will be compared against the previous run only.

Compared with the previous version I've addressed the review comments
and I've also reworked the cr-daily-branch changes after discussion with
Ian. I've run this a few times in play mode on the production system and
things are looking pretty good. See
http://www.chiark.greenend.org.uk/~xensrcts/logs/31967/ for the latest
results.

Most tests passed modulo a few host install failures and the fact that
Debian Jessie+Sid don't install right now for tedious Debian reasons
(the nightlies are OK though, so these will be fixed next time d-i is
uploaded). The armhf failures should be addressed by the patch at the
end of the series.

The exception to that good news is that sg-report-flight
--that-flight=NNN MMM doesn't seem to be considering failures in MMM
regressions vs NNN. e.g. test-amd64-i386-i386-daily-netboot-pvgrub
should appear as a regression from 31961 to 31964 but isn't. I'm going
to have a poke around that.

The new Debian install functionality here also gives us the opportunity
to test pygrub and pvgrub, so a couple of jobs are added to the regular
tests using installer images versioned via TftpDiVersion in the usual
way. This requires an early patch "mg-debian-installer-update: grab Xen
PV domU capable images too" to go in and a patch to update TftpDiVersion
to a refreshed version to be inserted before "Test pygrub and pvgrub on
the regular flights" is committed.

I've also pushed a branch:

The following changes since commit 9fa3df2d9838f2aecb0d0cb6d1a565d824828d65:

  cs-adjust-flight: runvar-perlop: Do not report non-changes (2014-11-17 17:32:11 +0000)

are available in the git repository at:

  git://xenbits.xen.org/people/ianc/osstest.git distro-flight-v3

for you to fetch changes up to aa67780314f5d9c88858dddde0c6f2b6b149d697:

  Debian: Handle lack of bootloader support in d-i on ARM. (2014-12-01 12:43:08 +0000)

----------------------------------------------------------------
Ian Campbell (19):
      TestSupport: Add helper to fetch a URL on a host
      TestSupport: Add helper to wait for a guest to shutdown
      TestSupport: allow overring of on_* in prepareguest_part_xencfg
      TestSupport: allow caller of prepareguest_part_xencfg to specify viftype
      create_webfile: Support use with guests as well as hosts.
      Debian: refactor code to add preseed commands to the preseed file
      Debian: refactor preseeding of .ssh directories
      Debian: ensure preseed base comment remains at actual end of base.
      Debian: Refactor installation of overlays, so it can be used for guests too
      Debian: add preseed_create_guest helper
      make-flight: Handle $BUILD_LVEXTEND_MAX in mfi-common:create_build_jobs()
      distros: add support for installing Debian PV guests via d-i, flight and jobs
      distros: support booting Debian PV (d-i installed) guests with pvgrub.
      distros: Support pvgrub for Wheezy too.
      distros: support PV guest install from Debian netinst media.
      Test pygrub and pvgrub on the regular flights
      distros: add branch infrastructure
      distros: Run a flight over the weekend.
      Debian: Handle lack of bootloader support in d-i on ARM.

 Osstest.pm             |   7 ++
 Osstest/Debian.pm      | 247 +++++++++++++++++++++++++++++++++++--------------
 Osstest/TestSupport.pm |  47 ++++++++--
 cr-daily-branch        |  39 ++++++--
 cri-common             |   1 +
 crontab                |   1 +
 make-distros-flight    | 140 ++++++++++++++++++++++++++++
 make-flight            |  43 ++++++++-
 mfi-common             |   4 +
 sg-run-job             |  11 +++
 ts-debian-di-install   | 236 ++++++++++++++++++++++++++++++++++++++++++++++
 ts-debian-hvm-install  |   8 +-
 12 files changed, 689 insertions(+), 95 deletions(-)
 create mode 100755 make-distros-flight
 create mode 100755 ts-debian-di-install



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:56:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQWX-0006mJ-LO; Mon, 01 Dec 2014 12:56: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 1XvQWW-0006mC-1j
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:56:16 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	78/52-22737-F656C745; Mon, 01 Dec 2014 12:56:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417438573!6691237!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 10798 invoked from network); 1 Dec 2014 12:56:14 -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;
	1 Dec 2014 12:56:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198045944"
Message-ID: <1417438571.29138.22.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:56:11 +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/19] add distro domU testing flight
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

The following series adds a new flight type intended to test distro domU
support, i.e. running distro installers and kernels on top of current
Xen to ensure things work. I intend for the flight to be run on a weekly
basis, and I've scheduled it here to run at the weekend when in theory
things might be quieter.

I've initially just done Debian PV domU support since Debian is what I
know, but I hope others will add other distros as time goes on.

The series introduces support for running the Debian Installer in a PV
domU booting from netboot (PXE-ish) and netinst (ISO media) and adding
jobs to test all of those for Squeeze onwards up to Sid and the
daily/weekly builds (CDs are built daily, DVDs weekly).

The flight is a bit unusual since distro installer builds are not really
versioned in a way which is useful to osstest, so instead each flight
will be compared against the previous run only.

Compared with the previous version I've addressed the review comments
and I've also reworked the cr-daily-branch changes after discussion with
Ian. I've run this a few times in play mode on the production system and
things are looking pretty good. See
http://www.chiark.greenend.org.uk/~xensrcts/logs/31967/ for the latest
results.

Most tests passed modulo a few host install failures and the fact that
Debian Jessie+Sid don't install right now for tedious Debian reasons
(the nightlies are OK though, so these will be fixed next time d-i is
uploaded). The armhf failures should be addressed by the patch at the
end of the series.

The exception to that good news is that sg-report-flight
--that-flight=NNN MMM doesn't seem to be considering failures in MMM
regressions vs NNN. e.g. test-amd64-i386-i386-daily-netboot-pvgrub
should appear as a regression from 31961 to 31964 but isn't. I'm going
to have a poke around that.

The new Debian install functionality here also gives us the opportunity
to test pygrub and pvgrub, so a couple of jobs are added to the regular
tests using installer images versioned via TftpDiVersion in the usual
way. This requires an early patch "mg-debian-installer-update: grab Xen
PV domU capable images too" to go in and a patch to update TftpDiVersion
to a refreshed version to be inserted before "Test pygrub and pvgrub on
the regular flights" is committed.

I've also pushed a branch:

The following changes since commit 9fa3df2d9838f2aecb0d0cb6d1a565d824828d65:

  cs-adjust-flight: runvar-perlop: Do not report non-changes (2014-11-17 17:32:11 +0000)

are available in the git repository at:

  git://xenbits.xen.org/people/ianc/osstest.git distro-flight-v3

for you to fetch changes up to aa67780314f5d9c88858dddde0c6f2b6b149d697:

  Debian: Handle lack of bootloader support in d-i on ARM. (2014-12-01 12:43:08 +0000)

----------------------------------------------------------------
Ian Campbell (19):
      TestSupport: Add helper to fetch a URL on a host
      TestSupport: Add helper to wait for a guest to shutdown
      TestSupport: allow overring of on_* in prepareguest_part_xencfg
      TestSupport: allow caller of prepareguest_part_xencfg to specify viftype
      create_webfile: Support use with guests as well as hosts.
      Debian: refactor code to add preseed commands to the preseed file
      Debian: refactor preseeding of .ssh directories
      Debian: ensure preseed base comment remains at actual end of base.
      Debian: Refactor installation of overlays, so it can be used for guests too
      Debian: add preseed_create_guest helper
      make-flight: Handle $BUILD_LVEXTEND_MAX in mfi-common:create_build_jobs()
      distros: add support for installing Debian PV guests via d-i, flight and jobs
      distros: support booting Debian PV (d-i installed) guests with pvgrub.
      distros: Support pvgrub for Wheezy too.
      distros: support PV guest install from Debian netinst media.
      Test pygrub and pvgrub on the regular flights
      distros: add branch infrastructure
      distros: Run a flight over the weekend.
      Debian: Handle lack of bootloader support in d-i on ARM.

 Osstest.pm             |   7 ++
 Osstest/Debian.pm      | 247 +++++++++++++++++++++++++++++++++++--------------
 Osstest/TestSupport.pm |  47 ++++++++--
 cr-daily-branch        |  39 ++++++--
 cri-common             |   1 +
 crontab                |   1 +
 make-distros-flight    | 140 ++++++++++++++++++++++++++++
 make-flight            |  43 ++++++++-
 mfi-common             |   4 +
 sg-run-job             |  11 +++
 ts-debian-di-install   | 236 ++++++++++++++++++++++++++++++++++++++++++++++
 ts-debian-hvm-install  |   8 +-
 12 files changed, 689 insertions(+), 95 deletions(-)
 create mode 100755 make-distros-flight
 create mode 100755 ts-debian-di-install



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:57:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:57:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQXV-0006rZ-3L; Mon, 01 Dec 2014 12:57:17 +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 1XvQXT-0006rN-SZ
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:16 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	B5/2B-02697-BA56C745; Mon, 01 Dec 2014 12:57:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417438634!10793138!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13244 invoked from network); 1 Dec 2014 12:57:14 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 12:57:14 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417438634; l=1052;
	s=domk; d=aepfle.de;
	h=Content-Disposition:Content-Type:MIME-Version:Subject:To:From:Date;
	bh=lym5u7ENXPgtOl8mLbHIJn152OU=;
	b=d3tEhKlncaJ0P3dsqUZmaAgpX9gg19pOIyZHiqX4XWNY9kw+7YgxPxlcAsERF7+O1sH
	+hxXKp6nol0yzsCjxaotFq6yVbQiRFtB/oUjAsu849GR8pMYA2L468+vtDNAuCizC0odn
	Jj66PhNMrhdBSaM0PgB/4JekmFLd4uWWJDA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJxKkze/KnV3DKbeZ4a
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([89.204.135.68])
	by smtp.strato.de (RZmta 36.2 DYNA|AUTH)
	with ESMTPSA id z01389qB1CvEXA1
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate) for <xen-devel@lists.xen.org>;
	Mon, 1 Dec 2014 13:57:14 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id CF95B5016D; Mon,  1 Dec 2014 13:57:12 +0100 (CET)
Date: Mon, 1 Dec 2014 13:57:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20141201125712.GA21576@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Subject: [Xen-devel] xl pci-attach silently fails the first 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


I tried to attach a PCI device (IGB Virtual Function) to a HVM guest. 
To actually get it assigned its required to run
pci-attach/pci-detach/pci-attach because it does not show up right away.
Did anyone noticed this bug already, is there a fix? There is no error
reported in dom0 dmesg, xl dmesg or qemu logfiles.

My domU.cfg looks like this:
name="domU"
memory=512
builder="hvm"
vif=['',]
disk=[ 'file:/SLE-12-Server-DVD-x86_64-GM-DVD1.iso,hda:cdrom' ]
serial="pty"

# xl pci-assignable-add 01:10.0
# xl pci-assignable-list
0000:01:10.0
# xl create -f domU.cfg
# xl console domU
## lspci gives just emulated PCI devices
## detach from domU console
# xl pci-attach domU 0000:01:10.0
# xl pci-list domU
Vdev Device
04.0 0000:01:10.0

# xl console domU
## lspci gives just emulated PCI devices
## detach from domU console
# xl pci-detach domU 0000:01:10.0
# xl pci-attach domU 0000:01:10.0
# xl pci-list domU
Vdev Device
04.0 0000:01:10.0
# xl console domU
## lspci shows now also the assigned host device


Olaf

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:57:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:57:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQXV-0006rZ-3L; Mon, 01 Dec 2014 12:57:17 +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 1XvQXT-0006rN-SZ
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:16 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	B5/2B-02697-BA56C745; Mon, 01 Dec 2014 12:57:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417438634!10793138!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13244 invoked from network); 1 Dec 2014 12:57:14 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 12:57:14 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417438634; l=1052;
	s=domk; d=aepfle.de;
	h=Content-Disposition:Content-Type:MIME-Version:Subject:To:From:Date;
	bh=lym5u7ENXPgtOl8mLbHIJn152OU=;
	b=d3tEhKlncaJ0P3dsqUZmaAgpX9gg19pOIyZHiqX4XWNY9kw+7YgxPxlcAsERF7+O1sH
	+hxXKp6nol0yzsCjxaotFq6yVbQiRFtB/oUjAsu849GR8pMYA2L468+vtDNAuCizC0odn
	Jj66PhNMrhdBSaM0PgB/4JekmFLd4uWWJDA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJxKkze/KnV3DKbeZ4a
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([89.204.135.68])
	by smtp.strato.de (RZmta 36.2 DYNA|AUTH)
	with ESMTPSA id z01389qB1CvEXA1
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate) for <xen-devel@lists.xen.org>;
	Mon, 1 Dec 2014 13:57:14 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id CF95B5016D; Mon,  1 Dec 2014 13:57:12 +0100 (CET)
Date: Mon, 1 Dec 2014 13:57:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20141201125712.GA21576@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Subject: [Xen-devel] xl pci-attach silently fails the first 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


I tried to attach a PCI device (IGB Virtual Function) to a HVM guest. 
To actually get it assigned its required to run
pci-attach/pci-detach/pci-attach because it does not show up right away.
Did anyone noticed this bug already, is there a fix? There is no error
reported in dom0 dmesg, xl dmesg or qemu logfiles.

My domU.cfg looks like this:
name="domU"
memory=512
builder="hvm"
vif=['',]
disk=[ 'file:/SLE-12-Server-DVD-x86_64-GM-DVD1.iso,hda:cdrom' ]
serial="pty"

# xl pci-assignable-add 01:10.0
# xl pci-assignable-list
0000:01:10.0
# xl create -f domU.cfg
# xl console domU
## lspci gives just emulated PCI devices
## detach from domU console
# xl pci-attach domU 0000:01:10.0
# xl pci-list domU
Vdev Device
04.0 0000:01:10.0

# xl console domU
## lspci gives just emulated PCI devices
## detach from domU console
# xl pci-detach domU 0000:01:10.0
# xl pci-attach domU 0000:01:10.0
# xl pci-list domU
Vdev Device
04.0 0000:01:10.0
# xl console domU
## lspci shows now also the assigned host device


Olaf

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQXv-0006yd-2o; Mon, 01 Dec 2014 12:57:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQXu-0006yI-6Y
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:42 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6C/55-09842-5C56C745; Mon, 01 Dec 2014 12:57:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2984 invoked from network); 1 Dec 2014 12:57:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:57:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046137"
Received: from ukmail1.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, 1 Dec 2014 07:57:39 -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 1XvQXq-0002Q4-3r;
	Mon, 01 Dec 2014 12:57:39 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:19 +0000
Message-ID: <1417438656-15451-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 02/19] TestSupport: Add helper to
	wait for a guest to 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

Refactor the guts of guest_await_reboot into a helper and use for both
shutdown and reboot handling.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Refactor common code with guest_await_reboot.
---
 Osstest/TestSupport.pm | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 477ad18..c0325c4 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -93,7 +93,8 @@ BEGIN {
                       guest_umount_lv guest_await guest_await_dhcp_tcp
                       guest_checkrunning guest_check_ip guest_find_ether
                       guest_find_domid guest_check_up guest_check_up_quick
-                      guest_get_state guest_await_reboot guest_destroy
+                      guest_get_state guest_await_reboot
+                      guest_await_shutdown guest_destroy
                       guest_vncsnapshot_begin guest_vncsnapshot_stash
 		      guest_check_remus_ok guest_editconfig
                       host_involves_pcipassthrough host_get_pcipassthrough_devs
@@ -1278,17 +1279,28 @@ sub report_once ($$$) {
     $ho->{$k}= $msg;
 }
 
-sub guest_await_reboot ($$$) {
-    my ($ho,$gho, $timeout) = @_;
-    poll_loop($timeout, 30, "await reboot request from $gho->{Guest}", sub {
+sub guest_await_state ($$$$$) {
+    my ($ho,$gho, $what,$wait_st,$timeout) = @_;
+
+    poll_loop($timeout, 30, "await $what request from $gho->{Guest}", sub {
         my $st= guest_get_state($ho,$gho);
-        return undef if $st eq 'sr';
+        return undef if $st eq $wait_st;
         fail("guest unexpectedly shutdown; state is '$st'")
             if $st =~ m/^s/ || $st eq '';
-        return "guest state is $st";
+        return "guest state is \"$st\"";
     });
 }
 
+sub guest_await_reboot ($$$) {
+    my ($ho,$gho, $timeout) = @_;
+    return guest_await_state($ho,$gho, "reboot", "sr", $timeout);
+}
+
+sub guest_await_shutdown ($$$) {
+    my ($ho,$gho, $timeout) = @_;
+    return guest_await_state($ho,$gho, "shutdown", "s", $timeout);
+}
+
 sub guest_destroy ($$) {
     my ($ho,$gho) = @_;
     target_cmd_root($ho, toolstack()->{Command}." destroy $gho->{Name}", 40);
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY1-00073o-G3; Mon, 01 Dec 2014 12:57: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 1XvQXz-00071b-MN
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:47 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	5B/36-02702-BC56C745; Mon, 01 Dec 2014 12:57:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417438661!12199427!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23196 invoked from network); 1 Dec 2014 12:57:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:57:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372219"
Received: from ukmail1.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, 1 Dec 2014 07:57:45 -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 1XvQXw-0002QN-Bn;
	Mon, 01 Dec 2014 12:57:45 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:44 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:25 +0000
Message-ID: <1417438656-15451-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 08/19] Debian: ensure preseed base
	comment remains at actual end of base.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 it a separate stanza. This is to help avoid people
accidentally adding stuff after it, such as in the following patches.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: New patch
---
 Osstest/Debian.pm | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index bdbe2f3..c985913 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -550,11 +550,14 @@ d-i apt-setup/contrib boolean false
 d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, wget, $extra_packages
 
 $xopts{ExtraPreseed}
+END
 
+    $preseed .= <<END;
 ### END OF DEBIAN PRESEED BASE
-
 END
-}          
+
+    return $preseed;
+}
 
 sub preseed_create ($$;@) {
     my ($ho, $sfx, %xopts) = @_;
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQXx-000703-Q3; Mon, 01 Dec 2014 12:57: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 1XvQXv-0006yu-SL
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:43 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	E6/62-02712-7C56C745; Mon, 01 Dec 2014 12:57:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417438661!12199427!1
X-Originating-IP: [66.165.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 22572 invoked from network); 1 Dec 2014 12:57:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:57:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372201"
Received: from ukmail1.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, 1 Dec 2014 07:57:40 -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 1XvQXr-0002Q7-59;
	Mon, 01 Dec 2014 12:57:40 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:39 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:20 +0000
Message-ID: <1417438656-15451-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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/19] TestSupport: allow overring of
	on_* in prepareguest_part_xencfg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 only on_reboot can be overridden

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index c0325c4..3074568 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1457,6 +1457,8 @@ sub prepareguest_part_lvmdisk ($$$) {
 sub prepareguest_part_xencfg ($$$$$) {
     my ($ho, $gho, $ram_mb, $xopts, $cfgrest) = @_;
     my $onreboot= $xopts->{OnReboot} || 'restart';
+    my $onpoweroff= $xopts->{OnPowerOff} || 'destroy';
+    my $oncrash= $xopts->{OnCrash} || 'preserve';
     my $vcpus= guest_var($gho, 'vcpus', $xopts->{DefVcpus} || 2);
     my $xoptcfg= $xopts->{ExtraConfig};
     $xoptcfg='' unless defined $xoptcfg;
@@ -1465,9 +1467,9 @@ name        = '$gho->{Name}'
 memory = ${ram_mb}
 vif         = [ 'type=ioemu,mac=$gho->{Ether}' ]
 #
-on_poweroff = 'destroy'
+on_poweroff = '$onpoweroff'
 on_reboot   = '$onreboot'
-on_crash    = 'preserve'
+on_crash    = '$oncrash'
 #
 vcpus = $vcpus
 #
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQXx-0006zk-Ej; Mon, 01 Dec 2014 12:57:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQXv-0006yq-Lf
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8F/AA-15461-7C56C745; Mon, 01 Dec 2014 12:57:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3188 invoked from network); 1 Dec 2014 12:57:42 -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;
	1 Dec 2014 12:57:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046140"
Received: from ukmail1.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, 1 Dec 2014 07:57: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 1XvQXs-0002QA-6S;
	Mon, 01 Dec 2014 12:57:41 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:40 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:21 +0000
Message-ID: <1417438656-15451-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 04/19] TestSupport: allow caller of
	prepareguest_part_xencfg to specify viftype
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
--
v3: Use CamelCase for xopts, use the correct condition
---
 Osstest/TestSupport.pm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 3074568..5edb2fd 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1460,12 +1460,13 @@ sub prepareguest_part_xencfg ($$$$$) {
     my $onpoweroff= $xopts->{OnPowerOff} || 'destroy';
     my $oncrash= $xopts->{OnCrash} || 'preserve';
     my $vcpus= guest_var($gho, 'vcpus', $xopts->{DefVcpus} || 2);
+    my $viftype= $xopts->{VifType} ? "type=$xopts->{VifType}," : "";
     my $xoptcfg= $xopts->{ExtraConfig};
     $xoptcfg='' unless defined $xoptcfg;
     my $xencfg= <<END;
 name        = '$gho->{Name}'
 memory = ${ram_mb}
-vif         = [ 'type=ioemu,mac=$gho->{Ether}' ]
+vif         = [ '${viftype}mac=$gho->{Ether}' ]
 #
 on_poweroff = '$onpoweroff'
 on_reboot   = '$onreboot'
@@ -1560,6 +1561,7 @@ END
         $cfg .= "bios='$bios'\n";
     }
 
+    $xopts{VifType} ||= "ioemu";
     my $cfgpath= prepareguest_part_xencfg($ho, $gho, $ram_mb, \%xopts, $cfg);
     target_cmd_root($ho, <<END);
         (echo $passwd; echo $passwd) | vncpasswd $gho->{Guest}.vncpw
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY1-000733-16; Mon, 01 Dec 2014 12:57: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 1XvQXz-00071L-AB
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:47 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	9C/11-03145-AC56C745; Mon, 01 Dec 2014 12:57:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417438661!12199427!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 22987 invoked from network); 1 Dec 2014 12:57:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:57:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372214"
Received: from ukmail1.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, 1 Dec 2014 07:57:43 -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 1XvQXu-0002QH-8y;
	Mon, 01 Dec 2014 12:57:43 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:42 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:23 +0000
Message-ID: <1417438656-15451-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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/19] Debian: refactor code to add
	preseed commands to the preseed 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

Call it from ts-debian-hvm-install.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: New patch
---
 Osstest/Debian.pm     | 16 +++++++++++-----
 ts-debian-hvm-install |  3 +++
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 89cd205..d1adb02 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -35,7 +35,7 @@ BEGIN {
                       %preseed_cmds
                       preseed_base
                       preseed_create
-                      preseed_hook_command preseed_hook_installscript
+                      preseed_hook_command preseed_hook_installscript preseed_hook_cmds
                       di_installcmdline_core
                       );
     %EXPORT_TAGS = ( );
@@ -726,10 +726,7 @@ d-i partman-auto/expert_recipe string					\\
 
 END
 
-    foreach my $di_key (keys %preseed_cmds) {
-        $preseed_file .= "d-i preseed/$di_key string ".
-            (join ' && ', @{ $preseed_cmds{$di_key} }). "\n";
-    }
+    $preseed_file .= preseed_hook_cmds();
 
     if ($ho->{Flags}{'no-di-kernel'}) {
 	$preseed_file .= <<END;
@@ -773,4 +770,13 @@ chmod +x '$installer_pathname'
 END
 }
 
+sub preseed_hook_cmds () {
+    my $preseed;
+    foreach my $di_key (keys %preseed_cmds) {
+        $preseed .= "d-i preseed/$di_key string ".
+            (join ' && ', @{ $preseed_cmds{$di_key} }). "\n";
+    }
+    return $preseed;
+}
+
 1;
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 37eade2..878083f 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -80,6 +80,9 @@ d-i preseed/late_command string \\
         in-target mkdir -p /root/.ssh; \\
         in-target sh -c "echo -e '$authkeys'> /root/.ssh/authorized_keys";
 END
+
+    $preseed_file .= preseed_hook_cmds();
+
     return $preseed_file;
 }
 
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQXx-0006zk-Ej; Mon, 01 Dec 2014 12:57:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQXv-0006yq-Lf
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8F/AA-15461-7C56C745; Mon, 01 Dec 2014 12:57:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3188 invoked from network); 1 Dec 2014 12:57:42 -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;
	1 Dec 2014 12:57:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046140"
Received: from ukmail1.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, 1 Dec 2014 07:57: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 1XvQXs-0002QA-6S;
	Mon, 01 Dec 2014 12:57:41 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:40 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:21 +0000
Message-ID: <1417438656-15451-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 04/19] TestSupport: allow caller of
	prepareguest_part_xencfg to specify viftype
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
--
v3: Use CamelCase for xopts, use the correct condition
---
 Osstest/TestSupport.pm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 3074568..5edb2fd 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1460,12 +1460,13 @@ sub prepareguest_part_xencfg ($$$$$) {
     my $onpoweroff= $xopts->{OnPowerOff} || 'destroy';
     my $oncrash= $xopts->{OnCrash} || 'preserve';
     my $vcpus= guest_var($gho, 'vcpus', $xopts->{DefVcpus} || 2);
+    my $viftype= $xopts->{VifType} ? "type=$xopts->{VifType}," : "";
     my $xoptcfg= $xopts->{ExtraConfig};
     $xoptcfg='' unless defined $xoptcfg;
     my $xencfg= <<END;
 name        = '$gho->{Name}'
 memory = ${ram_mb}
-vif         = [ 'type=ioemu,mac=$gho->{Ether}' ]
+vif         = [ '${viftype}mac=$gho->{Ether}' ]
 #
 on_poweroff = '$onpoweroff'
 on_reboot   = '$onreboot'
@@ -1560,6 +1561,7 @@ END
         $cfg .= "bios='$bios'\n";
     }
 
+    $xopts{VifType} ||= "ioemu";
     my $cfgpath= prepareguest_part_xencfg($ho, $gho, $ram_mb, \%xopts, $cfg);
     target_cmd_root($ho, <<END);
         (echo $passwd; echo $passwd) | vncpasswd $gho->{Guest}.vncpw
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY1-000733-16; Mon, 01 Dec 2014 12:57: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 1XvQXz-00071L-AB
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:47 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	9C/11-03145-AC56C745; Mon, 01 Dec 2014 12:57:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417438661!12199427!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 22987 invoked from network); 1 Dec 2014 12:57:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:57:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372214"
Received: from ukmail1.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, 1 Dec 2014 07:57:43 -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 1XvQXu-0002QH-8y;
	Mon, 01 Dec 2014 12:57:43 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:42 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:23 +0000
Message-ID: <1417438656-15451-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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/19] Debian: refactor code to add
	preseed commands to the preseed 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

Call it from ts-debian-hvm-install.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: New patch
---
 Osstest/Debian.pm     | 16 +++++++++++-----
 ts-debian-hvm-install |  3 +++
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 89cd205..d1adb02 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -35,7 +35,7 @@ BEGIN {
                       %preseed_cmds
                       preseed_base
                       preseed_create
-                      preseed_hook_command preseed_hook_installscript
+                      preseed_hook_command preseed_hook_installscript preseed_hook_cmds
                       di_installcmdline_core
                       );
     %EXPORT_TAGS = ( );
@@ -726,10 +726,7 @@ d-i partman-auto/expert_recipe string					\\
 
 END
 
-    foreach my $di_key (keys %preseed_cmds) {
-        $preseed_file .= "d-i preseed/$di_key string ".
-            (join ' && ', @{ $preseed_cmds{$di_key} }). "\n";
-    }
+    $preseed_file .= preseed_hook_cmds();
 
     if ($ho->{Flags}{'no-di-kernel'}) {
 	$preseed_file .= <<END;
@@ -773,4 +770,13 @@ chmod +x '$installer_pathname'
 END
 }
 
+sub preseed_hook_cmds () {
+    my $preseed;
+    foreach my $di_key (keys %preseed_cmds) {
+        $preseed .= "d-i preseed/$di_key string ".
+            (join ' && ', @{ $preseed_cmds{$di_key} }). "\n";
+    }
+    return $preseed;
+}
+
 1;
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 37eade2..878083f 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -80,6 +80,9 @@ d-i preseed/late_command string \\
         in-target mkdir -p /root/.ssh; \\
         in-target sh -c "echo -e '$authkeys'> /root/.ssh/authorized_keys";
 END
+
+    $preseed_file .= preseed_hook_cmds();
+
     return $preseed_file;
 }
 
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY1-00073o-G3; Mon, 01 Dec 2014 12:57: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 1XvQXz-00071b-MN
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:47 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	5B/36-02702-BC56C745; Mon, 01 Dec 2014 12:57:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417438661!12199427!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23196 invoked from network); 1 Dec 2014 12:57:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:57:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372219"
Received: from ukmail1.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, 1 Dec 2014 07:57:45 -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 1XvQXw-0002QN-Bn;
	Mon, 01 Dec 2014 12:57:45 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:44 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:25 +0000
Message-ID: <1417438656-15451-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 08/19] Debian: ensure preseed base
	comment remains at actual end of base.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 it a separate stanza. This is to help avoid people
accidentally adding stuff after it, such as in the following patches.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: New patch
---
 Osstest/Debian.pm | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index bdbe2f3..c985913 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -550,11 +550,14 @@ d-i apt-setup/contrib boolean false
 d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, wget, $extra_packages
 
 $xopts{ExtraPreseed}
+END
 
+    $preseed .= <<END;
 ### END OF DEBIAN PRESEED BASE
-
 END
-}          
+
+    return $preseed;
+}
 
 sub preseed_create ($$;@) {
     my ($ho, $sfx, %xopts) = @_;
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY2-00075s-T9; Mon, 01 Dec 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 <Ian.Campbell@citrix.com>) id 1XvQY0-00072K-N6
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	38/DA-15461-CC56C745; Mon, 01 Dec 2014 12:57:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4251 invoked from network); 1 Dec 2014 12:57:47 -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;
	1 Dec 2014 12:57:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046152"
Received: from ukmail1.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, 1 Dec 2014 07:57:46 -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 1XvQXx-0002QQ-DI;
	Mon, 01 Dec 2014 12:57:46 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:45 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:26 +0000
Message-ID: <1417438656-15451-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 09/19] Debian: Refactor installation
	of overlays, so it can be used for guests too
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
---
v3: New patch
---
 Osstest/Debian.pm | 57 ++++++++++++++++++++++++++++---------------------------
 1 file changed, 29 insertions(+), 28 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c985913..8ec4a3b 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -36,7 +36,9 @@ BEGIN {
                       preseed_base
                       preseed_create
                       preseed_ssh
-                      preseed_hook_command preseed_hook_installscript preseed_hook_cmds
+                      preseed_hook_command preseed_hook_installscript
+                      preseed_hook_overlay
+                      preseed_hook_cmds
                       di_installcmdline_core
                       );
     %EXPORT_TAGS = ( );
@@ -565,26 +567,6 @@ sub preseed_create ($$;@) {
     my $disk= $xopts{DiskDevice} || '/dev/sda';
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
-    my $overlays= '';
-    my $create_overlay= sub {
-        my ($srcdir, $tfilename) = @_;
-        my $url= create_webfile($ho, "$tfilename$sfx", sub {
-            my ($fh) = @_;
-            contents_make_cpio($fh, 'ustar', $srcdir);
-        });
-        $overlays .= <<END;
-wget -O overlay.tar '$url'
-cd /target
-tar xf \$r/overlay.tar
-cd \$r
-rm overlay.tar
-
-END
-    };
-
-    $create_overlay->('overlay',        'overlay.tar');
-    $create_overlay->($c{OverlayLocal}, 'overlay-local.tar');
-
     preseed_hook_installscript($ho, $sfx,
           '/lib/partman/init.d', '000override-parted-devices', <<END);
 #!/bin/sh
@@ -630,19 +612,14 @@ true
 END
 
     preseed_ssh($ho, $sfx);
+    preseed_hook_overlay($ho, $sfx, 'overlay', 'overlay.tar');
+    preseed_hook_overlay($ho, $sfx, $c{OverlayLocal}, 'overlay-local.tar');
 
     preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
 set -ex
 
-r=/target/root
-cd \$r
-
 echo FANCYTTY=0 >> /target/etc/lsb-base-logging.sh
-
-$overlays
-
-echo latecmd done.
 END
 
     foreach my $kp (keys %{ $ho->{Flags} }) {
@@ -788,6 +765,30 @@ chmod +x '$installer_pathname'
 END
 }
 
+sub preseed_hook_overlay ($$$$) {
+    my ($ho, $sfx, $srcdir, $tfilename) = @_;
+    my $url= create_webfile($ho, "$tfilename$sfx", sub {
+        my ($fh) = @_;
+        contents_make_cpio($fh, 'ustar', $srcdir);
+    });
+    preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+r=/target/root
+cd \$r
+
+umask 022
+
+wget -O overlay.tar '$url'
+cd /target
+tar xf \$r/overlay.tar
+cd \$r
+rm overlay.tar
+
+END
+}
+
 sub preseed_hook_cmds () {
     my $preseed;
     foreach my $di_key (keys %preseed_cmds) {
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQXy-00070R-6A; Mon, 01 Dec 2014 12:57: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 1XvQXw-0006zA-Dh
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	54/BA-15461-7C56C745; Mon, 01 Dec 2014 12:57:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3367 invoked from network); 1 Dec 2014 12:57: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;
	1 Dec 2014 12:57:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046145"
Received: from ukmail1.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, 1 Dec 2014 07:57:42 -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 1XvQXt-0002QD-7c;
	Mon, 01 Dec 2014 12:57:42 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:41 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:22 +0000
Message-ID: <1417438656-15451-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 05/19] create_webfile: Support use
	with guests as well as 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

In particular make the path unique by ensuring it includes the host
and guest name in the guest case.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: New patch
---
 Osstest/TestSupport.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 5edb2fd..2f23fd4 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1932,6 +1932,8 @@ sub await_webspace_fetch_byleaf ($$$$$) {
 sub create_webfile ($$$) {
     my ($ho, $tail, $contents) = @_; # $contents as for file_link_contents
     my $wf_rhs= $ho->{Name}."_".$tail;
+    # $ho->{Host} is set if $ho is a guest.
+    $wf_rhs= $ho->{Host}->{Name}."_${wf_rhs}" if $ho->{Host};
     my $wf_common= $c{WebspaceCommon}.$wf_rhs;
     my $wf_url= $c{WebspaceUrl}.$wf_common;
     my $wf_file= $c{WebspaceFile}.$wf_common;
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQXu-0006yR-Md; Mon, 01 Dec 2014 12:57:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQXt-0006y5-Ea
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:41 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FA/AA-25276-4C56C745; Mon, 01 Dec 2014 12:57:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!1
X-Originating-IP: [66.165.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 2910 invoked from network); 1 Dec 2014 12:57:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:57:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046134"
Received: from ukmail1.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, 1 Dec 2014 07:57:38 -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 1XvQXp-0002Q1-2M;
	Mon, 01 Dec 2014 12:57:38 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:37 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:18 +0000
Message-ID: <1417438656-15451-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 01/19] TestSupport: Add helper to
	fetch a URL on a host
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Make sure wget is installed
---
 Osstest/Debian.pm      | 2 +-
 Osstest/TestSupport.pm | 8 ++++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..89cd205 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, ethtool, $extra_packages
+d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, wget, $extra_packages
 
 $xopts{ExtraPreseed}
 
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 46b6720..477ad18 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -55,6 +55,7 @@ BEGIN {
                       target_putfilecontents_stash
 		      target_putfilecontents_root_stash
                       target_put_guest_image target_editfile
+                      target_fetchurl
                       target_editfile_root target_file_exists
                       target_run_apt
                       target_install_packages target_install_packages_norec
@@ -1472,6 +1473,13 @@ END
     return $cfgpath;
 }
 
+sub target_fetchurl($$$;$) {
+    my ($ho, $url, $path, $timeo) = @_;
+    $timeo ||= 2000;
+    target_cmd_root($ho, "wget --progress=dot:mega -O $path $url", $timeo);
+}
+
+
 sub target_put_guest_image ($$$) {
     my ($ho, $gho, $default) = @_;
     my $specimage = $r{"$gho->{Guest}_image"};
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY0-00072V-K5; Mon, 01 Dec 2014 12:57:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQXy-00070e-Op
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:46 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	56/DA-25276-AC56C745; Mon, 01 Dec 2014 12:57:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3624 invoked from network); 1 Dec 2014 12:57: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;
	1 Dec 2014 12:57:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046149"
Received: from ukmail1.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, 1 Dec 2014 07:57:44 -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 1XvQXv-0002QK-AM;
	Mon, 01 Dec 2014 12:57:44 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:43 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:24 +0000
Message-ID: <1417438656-15451-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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/19] Debian: refactor preseeding of
	.ssh directories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Causes known_hosts to be consistently created as well as ~osstest/.ssh
to be consistently populated (it previsouly wasn't for HVM guests).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: New patch
---
 Osstest/Debian.pm     | 99 +++++++++++++++++++++++++++++----------------------
 ts-debian-hvm-install |  5 ++-
 2 files changed, 59 insertions(+), 45 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index d1adb02..bdbe2f3 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -35,6 +35,7 @@ BEGIN {
                       %preseed_cmds
                       preseed_base
                       preseed_create
+                      preseed_ssh
                       preseed_hook_command preseed_hook_installscript preseed_hook_cmds
                       di_installcmdline_core
                       );
@@ -427,6 +428,60 @@ sub di_installcmdline_core ($$;@) {
     return @cl;
 }
 
+sub preseed_ssh ($$) {
+    my ($ho,$sfx) = @_;
+
+    my $authkeys_url= create_webfile($ho, "authkeys$sfx", authorized_keys());
+
+    my $hostkeyfile= "$c{OverlayLocal}/etc/ssh/ssh_host_rsa_key.pub";
+    my $hostkey= get_filecontents($hostkeyfile);
+    chomp($hostkey); $hostkey.="\n";
+    my $knownhosts= '';
+
+    my $hostsq= $dbh_tests->prepare(<<END);
+        SELECT val FROM runvars
+         WHERE flight=? AND name LIKE '%host'
+         GROUP BY val
+END
+    $hostsq->execute($flight);
+    while (my ($node) = $hostsq->fetchrow_array()) {
+        my $longname= "$node.$c{TestHostDomain}";
+        my (@hostent)= gethostbyname($longname);
+        if (!@hostent) {
+            logm("skipping host key for nonexistent host $longname");
+            next;
+        }
+        my $specs= join ',', $longname, $node, map {
+            join '.', unpack 'W4', $_;
+        } @hostent[4..$#hostent];
+        logm("adding host key for $specs");
+        $knownhosts.= "$specs ".$hostkey;
+    }
+    $hostsq->finish();
+
+    $knownhosts.= "localhost,127.0.0.1 ".$hostkey;
+    my $knownhosts_url= create_webfile($ho, "known_hosts$sfx", $knownhosts);
+
+    preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+r=/target/root
+cd \$r
+
+umask 022
+mkdir .ssh
+wget -O .ssh/authorized_keys '$authkeys_url'
+wget -O .ssh/known_hosts     '$knownhosts_url'
+
+u=osstest
+h=/home/\$u
+mkdir /target\$h/.ssh
+cp .ssh/authorized_keys /target\$h/.ssh
+chroot /target chown -R \$u.\$u \$h/.ssh
+END
+}
+
 sub preseed_base ($$;@) {
     my ($suite,$extra_packages,%xopts) = @_;
 
@@ -504,40 +559,9 @@ END
 sub preseed_create ($$;@) {
     my ($ho, $sfx, %xopts) = @_;
 
-    my $authkeys_url= create_webfile($ho, "authkeys$sfx", authorized_keys());
-
-    my $hostkeyfile= "$c{OverlayLocal}/etc/ssh/ssh_host_rsa_key.pub";
-    my $hostkey= get_filecontents($hostkeyfile);
-    chomp($hostkey); $hostkey.="\n";
-    my $knownhosts= '';
-
     my $disk= $xopts{DiskDevice} || '/dev/sda';
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
-    my $hostsq= $dbh_tests->prepare(<<END);
-        SELECT val FROM runvars
-         WHERE flight=? AND name LIKE '%host'
-         GROUP BY val
-END
-    $hostsq->execute($flight);
-    while (my ($node) = $hostsq->fetchrow_array()) {
-        my $longname= "$node.$c{TestHostDomain}";
-        my (@hostent)= gethostbyname($longname);
-        if (!@hostent) {
-            logm("skipping host key for nonexistent host $longname");
-            next;
-        }
-        my $specs= join ',', $longname, $node, map {
-            join '.', unpack 'W4', $_;
-        } @hostent[4..$#hostent];
-        logm("adding host key for $specs");
-        $knownhosts.= "$specs ".$hostkey;
-    }
-    $hostsq->finish();
-
-    $knownhosts.= "localhost,127.0.0.1 ".$hostkey;
-    my $knownhosts_url= create_webfile($ho, "known_hosts$sfx", $knownhosts);
-
     my $overlays= '';
     my $create_overlay= sub {
         my ($srcdir, $tfilename) = @_;
@@ -602,6 +626,8 @@ ls -l /dev/sd*
 true
 END
 
+    preseed_ssh($ho, $sfx);
+
     preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
 set -ex
@@ -609,17 +635,6 @@ set -ex
 r=/target/root
 cd \$r
 
-umask 022
-mkdir .ssh
-wget -O .ssh/authorized_keys '$authkeys_url'
-wget -O .ssh/known_hosts     '$knownhosts_url'
-
-u=osstest
-h=/home/\$u
-mkdir /target\$h/.ssh
-cp .ssh/authorized_keys /target\$h/.ssh
-chroot /target chown -R \$u.\$u \$h/.ssh
-
 echo FANCYTTY=0 >> /target/etc/lsb-base-logging.sh
 
 $overlays
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 878083f..d2bb6f8 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -47,7 +47,6 @@ 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
@@ -77,10 +76,10 @@ 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
 
+    preseed_ssh($ho,'');
+
     $preseed_file .= preseed_hook_cmds();
 
     return $preseed_file;
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQXu-0006yR-Md; Mon, 01 Dec 2014 12:57:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQXt-0006y5-Ea
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:41 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FA/AA-25276-4C56C745; Mon, 01 Dec 2014 12:57:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!1
X-Originating-IP: [66.165.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 2910 invoked from network); 1 Dec 2014 12:57:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:57:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046134"
Received: from ukmail1.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, 1 Dec 2014 07:57:38 -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 1XvQXp-0002Q1-2M;
	Mon, 01 Dec 2014 12:57:38 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:37 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:18 +0000
Message-ID: <1417438656-15451-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 01/19] TestSupport: Add helper to
	fetch a URL on a host
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Make sure wget is installed
---
 Osstest/Debian.pm      | 2 +-
 Osstest/TestSupport.pm | 8 ++++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..89cd205 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, ethtool, $extra_packages
+d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, wget, $extra_packages
 
 $xopts{ExtraPreseed}
 
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 46b6720..477ad18 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -55,6 +55,7 @@ BEGIN {
                       target_putfilecontents_stash
 		      target_putfilecontents_root_stash
                       target_put_guest_image target_editfile
+                      target_fetchurl
                       target_editfile_root target_file_exists
                       target_run_apt
                       target_install_packages target_install_packages_norec
@@ -1472,6 +1473,13 @@ END
     return $cfgpath;
 }
 
+sub target_fetchurl($$$;$) {
+    my ($ho, $url, $path, $timeo) = @_;
+    $timeo ||= 2000;
+    target_cmd_root($ho, "wget --progress=dot:mega -O $path $url", $timeo);
+}
+
+
 sub target_put_guest_image ($$$) {
     my ($ho, $gho, $default) = @_;
     my $specimage = $r{"$gho->{Guest}_image"};
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQXy-00070R-6A; Mon, 01 Dec 2014 12:57: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 1XvQXw-0006zA-Dh
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	54/BA-15461-7C56C745; Mon, 01 Dec 2014 12:57:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3367 invoked from network); 1 Dec 2014 12:57: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;
	1 Dec 2014 12:57:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046145"
Received: from ukmail1.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, 1 Dec 2014 07:57:42 -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 1XvQXt-0002QD-7c;
	Mon, 01 Dec 2014 12:57:42 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:41 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:22 +0000
Message-ID: <1417438656-15451-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 05/19] create_webfile: Support use
	with guests as well as 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

In particular make the path unique by ensuring it includes the host
and guest name in the guest case.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: New patch
---
 Osstest/TestSupport.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 5edb2fd..2f23fd4 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1932,6 +1932,8 @@ sub await_webspace_fetch_byleaf ($$$$$) {
 sub create_webfile ($$$) {
     my ($ho, $tail, $contents) = @_; # $contents as for file_link_contents
     my $wf_rhs= $ho->{Name}."_".$tail;
+    # $ho->{Host} is set if $ho is a guest.
+    $wf_rhs= $ho->{Host}->{Name}."_${wf_rhs}" if $ho->{Host};
     my $wf_common= $c{WebspaceCommon}.$wf_rhs;
     my $wf_url= $c{WebspaceUrl}.$wf_common;
     my $wf_file= $c{WebspaceFile}.$wf_common;
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQXv-0006yd-2o; Mon, 01 Dec 2014 12:57:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQXu-0006yI-6Y
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:42 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6C/55-09842-5C56C745; Mon, 01 Dec 2014 12:57:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2984 invoked from network); 1 Dec 2014 12:57:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:57:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046137"
Received: from ukmail1.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, 1 Dec 2014 07:57:39 -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 1XvQXq-0002Q4-3r;
	Mon, 01 Dec 2014 12:57:39 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:19 +0000
Message-ID: <1417438656-15451-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 02/19] TestSupport: Add helper to
	wait for a guest to 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

Refactor the guts of guest_await_reboot into a helper and use for both
shutdown and reboot handling.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Refactor common code with guest_await_reboot.
---
 Osstest/TestSupport.pm | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 477ad18..c0325c4 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -93,7 +93,8 @@ BEGIN {
                       guest_umount_lv guest_await guest_await_dhcp_tcp
                       guest_checkrunning guest_check_ip guest_find_ether
                       guest_find_domid guest_check_up guest_check_up_quick
-                      guest_get_state guest_await_reboot guest_destroy
+                      guest_get_state guest_await_reboot
+                      guest_await_shutdown guest_destroy
                       guest_vncsnapshot_begin guest_vncsnapshot_stash
 		      guest_check_remus_ok guest_editconfig
                       host_involves_pcipassthrough host_get_pcipassthrough_devs
@@ -1278,17 +1279,28 @@ sub report_once ($$$) {
     $ho->{$k}= $msg;
 }
 
-sub guest_await_reboot ($$$) {
-    my ($ho,$gho, $timeout) = @_;
-    poll_loop($timeout, 30, "await reboot request from $gho->{Guest}", sub {
+sub guest_await_state ($$$$$) {
+    my ($ho,$gho, $what,$wait_st,$timeout) = @_;
+
+    poll_loop($timeout, 30, "await $what request from $gho->{Guest}", sub {
         my $st= guest_get_state($ho,$gho);
-        return undef if $st eq 'sr';
+        return undef if $st eq $wait_st;
         fail("guest unexpectedly shutdown; state is '$st'")
             if $st =~ m/^s/ || $st eq '';
-        return "guest state is $st";
+        return "guest state is \"$st\"";
     });
 }
 
+sub guest_await_reboot ($$$) {
+    my ($ho,$gho, $timeout) = @_;
+    return guest_await_state($ho,$gho, "reboot", "sr", $timeout);
+}
+
+sub guest_await_shutdown ($$$) {
+    my ($ho,$gho, $timeout) = @_;
+    return guest_await_state($ho,$gho, "shutdown", "s", $timeout);
+}
+
 sub guest_destroy ($$) {
     my ($ho,$gho) = @_;
     target_cmd_root($ho, toolstack()->{Command}." destroy $gho->{Name}", 40);
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY0-00072V-K5; Mon, 01 Dec 2014 12:57:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQXy-00070e-Op
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:46 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	56/DA-25276-AC56C745; Mon, 01 Dec 2014 12:57:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3624 invoked from network); 1 Dec 2014 12:57: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;
	1 Dec 2014 12:57:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046149"
Received: from ukmail1.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, 1 Dec 2014 07:57:44 -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 1XvQXv-0002QK-AM;
	Mon, 01 Dec 2014 12:57:44 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:43 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:24 +0000
Message-ID: <1417438656-15451-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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/19] Debian: refactor preseeding of
	.ssh directories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Causes known_hosts to be consistently created as well as ~osstest/.ssh
to be consistently populated (it previsouly wasn't for HVM guests).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: New patch
---
 Osstest/Debian.pm     | 99 +++++++++++++++++++++++++++++----------------------
 ts-debian-hvm-install |  5 ++-
 2 files changed, 59 insertions(+), 45 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index d1adb02..bdbe2f3 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -35,6 +35,7 @@ BEGIN {
                       %preseed_cmds
                       preseed_base
                       preseed_create
+                      preseed_ssh
                       preseed_hook_command preseed_hook_installscript preseed_hook_cmds
                       di_installcmdline_core
                       );
@@ -427,6 +428,60 @@ sub di_installcmdline_core ($$;@) {
     return @cl;
 }
 
+sub preseed_ssh ($$) {
+    my ($ho,$sfx) = @_;
+
+    my $authkeys_url= create_webfile($ho, "authkeys$sfx", authorized_keys());
+
+    my $hostkeyfile= "$c{OverlayLocal}/etc/ssh/ssh_host_rsa_key.pub";
+    my $hostkey= get_filecontents($hostkeyfile);
+    chomp($hostkey); $hostkey.="\n";
+    my $knownhosts= '';
+
+    my $hostsq= $dbh_tests->prepare(<<END);
+        SELECT val FROM runvars
+         WHERE flight=? AND name LIKE '%host'
+         GROUP BY val
+END
+    $hostsq->execute($flight);
+    while (my ($node) = $hostsq->fetchrow_array()) {
+        my $longname= "$node.$c{TestHostDomain}";
+        my (@hostent)= gethostbyname($longname);
+        if (!@hostent) {
+            logm("skipping host key for nonexistent host $longname");
+            next;
+        }
+        my $specs= join ',', $longname, $node, map {
+            join '.', unpack 'W4', $_;
+        } @hostent[4..$#hostent];
+        logm("adding host key for $specs");
+        $knownhosts.= "$specs ".$hostkey;
+    }
+    $hostsq->finish();
+
+    $knownhosts.= "localhost,127.0.0.1 ".$hostkey;
+    my $knownhosts_url= create_webfile($ho, "known_hosts$sfx", $knownhosts);
+
+    preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+r=/target/root
+cd \$r
+
+umask 022
+mkdir .ssh
+wget -O .ssh/authorized_keys '$authkeys_url'
+wget -O .ssh/known_hosts     '$knownhosts_url'
+
+u=osstest
+h=/home/\$u
+mkdir /target\$h/.ssh
+cp .ssh/authorized_keys /target\$h/.ssh
+chroot /target chown -R \$u.\$u \$h/.ssh
+END
+}
+
 sub preseed_base ($$;@) {
     my ($suite,$extra_packages,%xopts) = @_;
 
@@ -504,40 +559,9 @@ END
 sub preseed_create ($$;@) {
     my ($ho, $sfx, %xopts) = @_;
 
-    my $authkeys_url= create_webfile($ho, "authkeys$sfx", authorized_keys());
-
-    my $hostkeyfile= "$c{OverlayLocal}/etc/ssh/ssh_host_rsa_key.pub";
-    my $hostkey= get_filecontents($hostkeyfile);
-    chomp($hostkey); $hostkey.="\n";
-    my $knownhosts= '';
-
     my $disk= $xopts{DiskDevice} || '/dev/sda';
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
-    my $hostsq= $dbh_tests->prepare(<<END);
-        SELECT val FROM runvars
-         WHERE flight=? AND name LIKE '%host'
-         GROUP BY val
-END
-    $hostsq->execute($flight);
-    while (my ($node) = $hostsq->fetchrow_array()) {
-        my $longname= "$node.$c{TestHostDomain}";
-        my (@hostent)= gethostbyname($longname);
-        if (!@hostent) {
-            logm("skipping host key for nonexistent host $longname");
-            next;
-        }
-        my $specs= join ',', $longname, $node, map {
-            join '.', unpack 'W4', $_;
-        } @hostent[4..$#hostent];
-        logm("adding host key for $specs");
-        $knownhosts.= "$specs ".$hostkey;
-    }
-    $hostsq->finish();
-
-    $knownhosts.= "localhost,127.0.0.1 ".$hostkey;
-    my $knownhosts_url= create_webfile($ho, "known_hosts$sfx", $knownhosts);
-
     my $overlays= '';
     my $create_overlay= sub {
         my ($srcdir, $tfilename) = @_;
@@ -602,6 +626,8 @@ ls -l /dev/sd*
 true
 END
 
+    preseed_ssh($ho, $sfx);
+
     preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
 set -ex
@@ -609,17 +635,6 @@ set -ex
 r=/target/root
 cd \$r
 
-umask 022
-mkdir .ssh
-wget -O .ssh/authorized_keys '$authkeys_url'
-wget -O .ssh/known_hosts     '$knownhosts_url'
-
-u=osstest
-h=/home/\$u
-mkdir /target\$h/.ssh
-cp .ssh/authorized_keys /target\$h/.ssh
-chroot /target chown -R \$u.\$u \$h/.ssh
-
 echo FANCYTTY=0 >> /target/etc/lsb-base-logging.sh
 
 $overlays
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 878083f..d2bb6f8 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -47,7 +47,6 @@ 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
@@ -77,10 +76,10 @@ 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
 
+    preseed_ssh($ho,'');
+
     $preseed_file .= preseed_hook_cmds();
 
     return $preseed_file;
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQXx-000703-Q3; Mon, 01 Dec 2014 12:57: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 1XvQXv-0006yu-SL
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:43 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	E6/62-02712-7C56C745; Mon, 01 Dec 2014 12:57:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417438661!12199427!1
X-Originating-IP: [66.165.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 22572 invoked from network); 1 Dec 2014 12:57:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:57:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372201"
Received: from ukmail1.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, 1 Dec 2014 07:57:40 -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 1XvQXr-0002Q7-59;
	Mon, 01 Dec 2014 12:57:40 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:39 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:20 +0000
Message-ID: <1417438656-15451-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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/19] TestSupport: allow overring of
	on_* in prepareguest_part_xencfg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 only on_reboot can be overridden

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index c0325c4..3074568 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1457,6 +1457,8 @@ sub prepareguest_part_lvmdisk ($$$) {
 sub prepareguest_part_xencfg ($$$$$) {
     my ($ho, $gho, $ram_mb, $xopts, $cfgrest) = @_;
     my $onreboot= $xopts->{OnReboot} || 'restart';
+    my $onpoweroff= $xopts->{OnPowerOff} || 'destroy';
+    my $oncrash= $xopts->{OnCrash} || 'preserve';
     my $vcpus= guest_var($gho, 'vcpus', $xopts->{DefVcpus} || 2);
     my $xoptcfg= $xopts->{ExtraConfig};
     $xoptcfg='' unless defined $xoptcfg;
@@ -1465,9 +1467,9 @@ name        = '$gho->{Name}'
 memory = ${ram_mb}
 vif         = [ 'type=ioemu,mac=$gho->{Ether}' ]
 #
-on_poweroff = 'destroy'
+on_poweroff = '$onpoweroff'
 on_reboot   = '$onreboot'
-on_crash    = 'preserve'
+on_crash    = '$oncrash'
 #
 vcpus = $vcpus
 #
-- 
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 Mon Dec 01 12:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY2-00075s-T9; Mon, 01 Dec 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 <Ian.Campbell@citrix.com>) id 1XvQY0-00072K-N6
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	38/DA-15461-CC56C745; Mon, 01 Dec 2014 12:57:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4251 invoked from network); 1 Dec 2014 12:57:47 -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;
	1 Dec 2014 12:57:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046152"
Received: from ukmail1.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, 1 Dec 2014 07:57:46 -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 1XvQXx-0002QQ-DI;
	Mon, 01 Dec 2014 12:57:46 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:45 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:26 +0000
Message-ID: <1417438656-15451-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 09/19] Debian: Refactor installation
	of overlays, so it can be used for guests too
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
---
v3: New patch
---
 Osstest/Debian.pm | 57 ++++++++++++++++++++++++++++---------------------------
 1 file changed, 29 insertions(+), 28 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c985913..8ec4a3b 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -36,7 +36,9 @@ BEGIN {
                       preseed_base
                       preseed_create
                       preseed_ssh
-                      preseed_hook_command preseed_hook_installscript preseed_hook_cmds
+                      preseed_hook_command preseed_hook_installscript
+                      preseed_hook_overlay
+                      preseed_hook_cmds
                       di_installcmdline_core
                       );
     %EXPORT_TAGS = ( );
@@ -565,26 +567,6 @@ sub preseed_create ($$;@) {
     my $disk= $xopts{DiskDevice} || '/dev/sda';
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
-    my $overlays= '';
-    my $create_overlay= sub {
-        my ($srcdir, $tfilename) = @_;
-        my $url= create_webfile($ho, "$tfilename$sfx", sub {
-            my ($fh) = @_;
-            contents_make_cpio($fh, 'ustar', $srcdir);
-        });
-        $overlays .= <<END;
-wget -O overlay.tar '$url'
-cd /target
-tar xf \$r/overlay.tar
-cd \$r
-rm overlay.tar
-
-END
-    };
-
-    $create_overlay->('overlay',        'overlay.tar');
-    $create_overlay->($c{OverlayLocal}, 'overlay-local.tar');
-
     preseed_hook_installscript($ho, $sfx,
           '/lib/partman/init.d', '000override-parted-devices', <<END);
 #!/bin/sh
@@ -630,19 +612,14 @@ true
 END
 
     preseed_ssh($ho, $sfx);
+    preseed_hook_overlay($ho, $sfx, 'overlay', 'overlay.tar');
+    preseed_hook_overlay($ho, $sfx, $c{OverlayLocal}, 'overlay-local.tar');
 
     preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
 set -ex
 
-r=/target/root
-cd \$r
-
 echo FANCYTTY=0 >> /target/etc/lsb-base-logging.sh
-
-$overlays
-
-echo latecmd done.
 END
 
     foreach my $kp (keys %{ $ho->{Flags} }) {
@@ -788,6 +765,30 @@ chmod +x '$installer_pathname'
 END
 }
 
+sub preseed_hook_overlay ($$$$) {
+    my ($ho, $sfx, $srcdir, $tfilename) = @_;
+    my $url= create_webfile($ho, "$tfilename$sfx", sub {
+        my ($fh) = @_;
+        contents_make_cpio($fh, 'ustar', $srcdir);
+    });
+    preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+r=/target/root
+cd \$r
+
+umask 022
+
+wget -O overlay.tar '$url'
+cd /target
+tar xf \$r/overlay.tar
+cd \$r
+rm overlay.tar
+
+END
+}
+
 sub preseed_hook_cmds () {
     my $preseed;
     foreach my $di_key (keys %preseed_cmds) {
-- 
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 Mon Dec 01 12:57:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY4-00078z-5x; Mon, 01 Dec 2014 12:57: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 1XvQY2-00074A-5T
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:50 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	14/20-02699-DC56C745; Mon, 01 Dec 2014 12:57:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417438661!12199427!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23449 invoked from network); 1 Dec 2014 12:57: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;
	1 Dec 2014 12:57:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372232"
Received: from ukmail1.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, 1 Dec 2014 07:57: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 1XvQXy-0002QT-EU;
	Mon, 01 Dec 2014 12:57:47 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:27 +0000
Message-ID: <1417438656-15451-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 10/19] Debian: add
	preseed_create_guest helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Creates a preseed file suitable for use in a PV guest

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Handle $xopts{ExtraPreseed} undefined in preseed_base
---
 Osstest/Debian.pm | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8ec4a3b..c4afde1 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -35,6 +35,7 @@ BEGIN {
                       %preseed_cmds
                       preseed_base
                       preseed_create
+                      preseed_create_guest
                       preseed_ssh
                       preseed_hook_command preseed_hook_installscript
                       preseed_hook_overlay
@@ -487,6 +488,9 @@ END
 sub preseed_base ($$;@) {
     my ($suite,$extra_packages,%xopts) = @_;
 
+    $extra_packages ||= '';
+    $xopts{ExtraPreseed} ||= '';
+
     return <<"END";
 d-i mirror/suite string $suite
 
@@ -561,6 +565,31 @@ END
     return $preseed;
 }
 
+sub preseed_create_guest ($$;@) {
+    my ($ho, $sfx, %xopts) = @_;
+
+    my $suite= $xopts{Suite} || $c{DebianSuite};
+
+    my $extra_packages;
+
+    my $preseed_file= preseed_base($suite, $extra_packages, %xopts);
+    $preseed_file.= (<<END);
+d-i     partman-auto/method             string regular
+d-i     partman-auto/choose_recipe \\
+                select All files in one partition (recommended for new users)
+
+d-i     grub-installer/bootdev          string /dev/xvda
+
+END
+
+    preseed_ssh($ho, $sfx);
+    preseed_hook_overlay($ho, $sfx, $c{OverlayLocal}, 'overlay-local.tar');
+
+    $preseed_file .= preseed_hook_cmds();
+
+    return create_webfile($ho, "preseed$sfx", $preseed_file);
+}
+
 sub preseed_create ($$;@) {
     my ($ho, $sfx, %xopts) = @_;
 
-- 
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 Mon Dec 01 12:57:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY4-00078z-5x; Mon, 01 Dec 2014 12:57: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 1XvQY2-00074A-5T
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:50 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	14/20-02699-DC56C745; Mon, 01 Dec 2014 12:57:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417438661!12199427!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23449 invoked from network); 1 Dec 2014 12:57: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;
	1 Dec 2014 12:57:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372232"
Received: from ukmail1.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, 1 Dec 2014 07:57: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 1XvQXy-0002QT-EU;
	Mon, 01 Dec 2014 12:57:47 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:27 +0000
Message-ID: <1417438656-15451-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 10/19] Debian: add
	preseed_create_guest helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Creates a preseed file suitable for use in a PV guest

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Handle $xopts{ExtraPreseed} undefined in preseed_base
---
 Osstest/Debian.pm | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8ec4a3b..c4afde1 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -35,6 +35,7 @@ BEGIN {
                       %preseed_cmds
                       preseed_base
                       preseed_create
+                      preseed_create_guest
                       preseed_ssh
                       preseed_hook_command preseed_hook_installscript
                       preseed_hook_overlay
@@ -487,6 +488,9 @@ END
 sub preseed_base ($$;@) {
     my ($suite,$extra_packages,%xopts) = @_;
 
+    $extra_packages ||= '';
+    $xopts{ExtraPreseed} ||= '';
+
     return <<"END";
 d-i mirror/suite string $suite
 
@@ -561,6 +565,31 @@ END
     return $preseed;
 }
 
+sub preseed_create_guest ($$;@) {
+    my ($ho, $sfx, %xopts) = @_;
+
+    my $suite= $xopts{Suite} || $c{DebianSuite};
+
+    my $extra_packages;
+
+    my $preseed_file= preseed_base($suite, $extra_packages, %xopts);
+    $preseed_file.= (<<END);
+d-i     partman-auto/method             string regular
+d-i     partman-auto/choose_recipe \\
+                select All files in one partition (recommended for new users)
+
+d-i     grub-installer/bootdev          string /dev/xvda
+
+END
+
+    preseed_ssh($ho, $sfx);
+    preseed_hook_overlay($ho, $sfx, $c{OverlayLocal}, 'overlay-local.tar');
+
+    $preseed_file .= preseed_hook_cmds();
+
+    return create_webfile($ho, "preseed$sfx", $preseed_file);
+}
+
 sub preseed_create ($$;@) {
     my ($ho, $sfx, %xopts) = @_;
 
-- 
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 Mon Dec 01 12:57:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY4-0007A4-Ql; Mon, 01 Dec 2014 12: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.Campbell@citrix.com>) id 1XvQY2-000750-Ou
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	26/A5-09842-EC56C745; Mon, 01 Dec 2014 12:57:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4838 invoked from network); 1 Dec 2014 12:57:49 -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;
	1 Dec 2014 12:57:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046164"
Received: from ukmail1.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, 1 Dec 2014 07:57:48 -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 1XvQXz-0002QX-Fs;
	Mon, 01 Dec 2014 12:57:48 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:28 +0000
Message-ID: <1417438656-15451-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 11/19] make-flight: Handle
	$BUILD_LVEXTEND_MAX in mfi-common:create_build_jobs()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
---
v3: New patch
---
 make-flight | 4 ----
 mfi-common  | 4 ++++
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/make-flight b/make-flight
index 9963a46..b641683 100755
--- a/make-flight
+++ b/make-flight
@@ -35,10 +35,6 @@ defguestsuite=`getconfig GuestDebianSuite`
 
 if [ x$buildflight = x ]; then
 
-  if [ "x$BUILD_LVEXTEND_MAX" != x ]; then
-     BUILD_RUNVARS+=" build_lvextend_max=$BUILD_LVEXTEND_MAX "
-  fi
-
   create_build_jobs
 
 else
diff --git a/mfi-common b/mfi-common
index 5c4f5d5..86901fe 100644
--- a/mfi-common
+++ b/mfi-common
@@ -50,6 +50,10 @@ create_build_jobs () {
   local enable_ovmf
   local build_hostflags
 
+  if [ "x$BUILD_LVEXTEND_MAX" != x ]; then
+     BUILD_RUNVARS+=" build_lvextend_max=$BUILD_LVEXTEND_MAX "
+  fi
+
   for arch in ${BUILD_ARCHES- i386 amd64 armhf }; do
 
     if [ "x$arch" = xdisable ]; then continue; fi
-- 
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 Mon Dec 01 12:57:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY4-0007A4-Ql; Mon, 01 Dec 2014 12: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.Campbell@citrix.com>) id 1XvQY2-000750-Ou
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	26/A5-09842-EC56C745; Mon, 01 Dec 2014 12:57:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4838 invoked from network); 1 Dec 2014 12:57:49 -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;
	1 Dec 2014 12:57:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046164"
Received: from ukmail1.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, 1 Dec 2014 07:57:48 -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 1XvQXz-0002QX-Fs;
	Mon, 01 Dec 2014 12:57:48 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:28 +0000
Message-ID: <1417438656-15451-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 11/19] make-flight: Handle
	$BUILD_LVEXTEND_MAX in mfi-common:create_build_jobs()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
---
v3: New patch
---
 make-flight | 4 ----
 mfi-common  | 4 ++++
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/make-flight b/make-flight
index 9963a46..b641683 100755
--- a/make-flight
+++ b/make-flight
@@ -35,10 +35,6 @@ defguestsuite=`getconfig GuestDebianSuite`
 
 if [ x$buildflight = x ]; then
 
-  if [ "x$BUILD_LVEXTEND_MAX" != x ]; then
-     BUILD_RUNVARS+=" build_lvextend_max=$BUILD_LVEXTEND_MAX "
-  fi
-
   create_build_jobs
 
 else
diff --git a/mfi-common b/mfi-common
index 5c4f5d5..86901fe 100644
--- a/mfi-common
+++ b/mfi-common
@@ -50,6 +50,10 @@ create_build_jobs () {
   local enable_ovmf
   local build_hostflags
 
+  if [ "x$BUILD_LVEXTEND_MAX" != x ]; then
+     BUILD_RUNVARS+=" build_lvextend_max=$BUILD_LVEXTEND_MAX "
+  fi
+
   for arch in ${BUILD_ARCHES- i386 amd64 armhf }; do
 
     if [ "x$arch" = xdisable ]; then continue; fi
-- 
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 Mon Dec 01 12:57:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY7-0007EZ-G8; Mon, 01 Dec 2014 12:57:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQY5-00079v-3j
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0D/0B-25276-0D56C745; Mon, 01 Dec 2014 12:57:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!9
X-Originating-IP: [66.165.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 5042 invoked from network); 1 Dec 2014 12:57:51 -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;
	1 Dec 2014 12:57:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046173"
Received: from ukmail1.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, 1 Dec 2014 07:57:49 -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 1XvQY0-0002Qa-H7;
	Mon, 01 Dec 2014 12:57:49 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:48 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:29 +0000
Message-ID: <1417438656-15451-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 12/19] distros: add support for
	installing Debian PV guests via d-i, flight and jobs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch introduces ts-debian-di-install which can install Debian
from a netboot (PXE) debian installer image. By default it installs
from the d-i image used by osstest (using the special Xen PV guest
enabled flavour where necessary) but it can also install the current
release versions from Squeeze onwards (up to and including Sid) and
the d-i daily builds. This is controlled by runvars {Guest}_diver =
osstest|current and {Guest}_dist = squeeze|...|sid.  The resulting
guests boot the distro kernel using pygrub (pvgrub will follow).

The distros flights differ substantially from the existing flights.
Introduce make-distros-flight using the functionality previously
refactored into mfi-common. The new flight tests all versions of
Debian from Squeeze onward as an amd64, i386 and armhf guests (armhf
from Jessie onwards only) using the usual smoke tests.

Test names are suffixed -pygrub pending the addition of pvgrub
variants in a future commit.

Add the new cases to sg-run-job

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: $BUILD_LVEXTEND_MAX now handled in mfi-common
    Consolidate setting of ruvars
    Include $flight and $job in tmpdir name
    Use Osstest::Debian::di_installcmdline_core
    Document the usage of get_host_property on a guest object
    Correct ARM netboot paths
    Include bootloader in test name
       Should include -pv too?
    console= repetition for Jessie onwards.
    Wait for up to an hour for the install. I'd seen timeouts right at
    the end of the install with the previous value
---
 Osstest/TestSupport.pm |   3 +
 make-distros-flight    |  98 ++++++++++++++++++++++++++++
 sg-run-job             |  11 ++++
 ts-debian-di-install   | 170 +++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 282 insertions(+)
 create mode 100755 make-distros-flight
 create mode 100755 ts-debian-di-install

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 2f23fd4..c1ecd8d 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -861,8 +861,11 @@ sub propname_massage ($) {
     return $prop;
 }
 
+# It is fine to call this on a guest object too, in which case it will
+# always return $defval.
 sub get_host_property ($$;$) {
     my ($ho, $prop, $defval) = @_;
+    return $defval unless $ho->{Properties};
     my $val = $ho->{Properties}{propname_massage($prop)};
     return defined($val) ? $val : $defval;
 }
diff --git a/make-distros-flight b/make-distros-flight
new file mode 100755
index 0000000..5067342
--- /dev/null
+++ b/make-distros-flight
@@ -0,0 +1,98 @@
+#!/bin/bash
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 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
+
+branch=$1
+xenbranch=$2
+blessing=$3
+buildflight=$4
+
+flight=`./cs-flight-create $blessing $branch`
+
+. cri-common
+. ap-common
+. mfi-common
+
+defsuite=`getconfig DebianSuite`
+defguestsuite=`getconfig GuestDebianSuite`
+
+if [ x$buildflight = x ]; then
+
+  WANT_XEND=false REVISION_LINUX_OLD=disable
+
+  create_build_jobs
+
+else
+
+  bfi=$buildflight.
+
+fi
+
+job_create_test_filter_callback () {
+  if [ "$xenarch" = "i386" ]; then return 1; fi
+  return 0
+}
+
+test_matrix_branch_filter_callback () {
+    :
+}
+
+test_do_one_netboot () {
+  job_create_test                                               \
+   test-$xenarch$kern-$dom0arch-$domU-$dist-netboot-pygrub      \
+    test-debian-di xl $xenarch $dom0arch                        \
+      kernbuildjob=${bfi}build-$dom0arch-$kernbuild             \
+      debian_arch=$domU                                         \
+      debian_dist=$dist                                         \
+      debian_method=netboot                                     \
+      debian_diver=current                                      \
+      all_hostflags=$most_hostflags
+}
+
+test_matrix_do_one () {
+  case ${xenarch} in
+  amd64) domUarches="amd64 i386";;
+  armhf) domUarches="armhf";;
+  esac
+
+  for domU in $domUarches ; do
+    for dist in squeeze wheezy jessie sid daily ; do
+      case ${domU}_${dist} in
+      armhf_squeeze) continue;; # No armhf in Squeeze
+      armhf_wheezy) continue;; # No armhf guest support in Wheezy
+      *) ;;
+      esac
+
+      test_do_one_netboot
+
+    done
+
+  done
+}
+
+test_matrix_iterate
+
+echo $flight
+
+# Local variables:
+# mode: sh
+# sh-basic-offset: 2
+# indent-tabs-mode: nil
+# End:
diff --git a/sg-run-job b/sg-run-job
index 2cf810a..9943ee4 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -247,6 +247,17 @@ proc run-job/test-debian {} {
     test-guest debian
 }
 
+proc install-guest-debian-di {} {
+    run-ts . = ts-debian-di-install
+    run-ts . = ts-guest-start + debian
+}
+
+proc need-hosts/test-debian-di {} { return host }
+proc run-job/test-debian-di {} {
+    install-guest-debian-di
+    test-guest debian
+}
+
 proc need-hosts/test-freebsd {} { return host }
 proc run-job/test-freebsd {} {
     run-ts . = ts-freebsd-install
diff --git a/ts-debian-di-install b/ts-debian-di-install
new file mode 100755
index 0000000..edccf52
--- /dev/null
+++ b/ts-debian-di-install
@@ -0,0 +1,170 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::Debian;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+$gn ||= 'debian';
+
+our $ho= selecthost($whhost);
+
+our $ram_mb=    512;
+our $disk_mb= 10000;
+
+our $guesthost= "$gn.guest.osstest";
+our $gho;
+
+sub prep () {
+    target_install_packages_norec($ho, qw(lvm2));
+
+    $gho= prepareguest($ho, $gn, $guesthost, 22,
+                       $disk_mb, 40);
+
+    prepareguest_part_lvmdisk($ho, $gho, $disk_mb);
+
+    target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
+}
+
+sub setup_netboot($$$)
+{
+    my ($didir, $arch, $suite) = @_;
+
+    my $di_ver= $r{"$gho->{Guest}_diver"} || "osstest";
+
+    my ($kernel,$initrd);
+
+    if ( $di_ver eq "osstest" ) {
+	my $di_path = $c{TftpPath}.'/'.$ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'.$c{TftpDiVersion}.'-'.$ho->{Suite};
+
+	$kernel = "$di_path/vmlinuz-xen";
+	$initrd = "$di_path/initrd.gz-xen";
+
+	target_putfile_root($ho, 60, $kernel, "$didir/kernel_${suite}_${arch}");
+	target_putfile_root($ho, 60, $initrd, "$didir/initrd_${suite}_${arch}");
+
+    } else {
+	my $mirror = "http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath}";
+
+	my $di_url = $suite eq "daily" ?
+	    "http://d-i.debian.org/daily-images/$arch/daily/netboot" :
+	    "$mirror/dists/$suite/main/installer-$arch/$di_ver/images/netboot";
+
+	$di_url .= "/xen" if $arch =~ m/amd64|i386/;
+	$di_url .= "/debian-installer/arm64" if $arch =~ /arm64/;
+
+	$kernel = "$di_url/vmlinuz";
+	$initrd = "$di_url/initrd.gz";
+
+	target_fetchurl($ho, $kernel, "$didir/kernel_${suite}_${arch}");
+	target_fetchurl($ho, $initrd, "$didir/initrd_${suite}_${arch}");
+    }
+
+    store_runvar("$gho->{Guest}_netboot_kernel", $kernel);
+    store_runvar("$gho->{Guest}_netboot_initrd", $initrd);
+
+    return <<END;
+kernel      = "$didir/kernel_${suite}_${arch}"
+ramdisk     = "$didir/initrd_${suite}_${arch}"
+END
+}
+sub ginstall () {
+    my $arch= $r{"$gho->{Guest}_arch"};
+    my $method= $r{"$gho->{Guest}_method"};
+
+    my $tmpdir= "/root/$flight-$job-di";
+    target_cmd_root($ho, <<END);
+rm -rf $tmpdir
+mkdir $tmpdir
+END
+
+    my ($method_cfg, $ps_url, $extra_disk);
+
+    if ( $method eq "netboot" )
+    {
+	my $suite= $r{"$gho->{Guest}_dist"};
+	logm("$method $suite/$arch");
+
+	$method_cfg = setup_netboot($tmpdir, $arch, $suite);
+
+	$suite = "sid" if $suite eq "daily";
+
+	$ps_url = preseed_create_guest($gho, '', Suite=>$suite);
+
+	$extra_disk = "";
+    }
+    else
+    {
+	die "$method";
+    }
+
+    my @cmdline = ();
+    push @cmdline, "debian-installer/exit/always_halt=true";
+    push @cmdline, "domain=$c{TestHostDomain}";
+    push @cmdline, "console=hvc0";
+    push @cmdline, di_installcmdline_core($gho, $ps_url);
+    push @cmdline, "--";
+    # See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007 for
+    # why this is repeated.
+    push @cmdline, "console=hvc0";
+
+    my $cmdline = join(" ", @cmdline);
+
+    my %install_xopts = (
+	OnPowerOff => "preserve"
+    );
+
+    prepareguest_part_xencfg($ho, $gho, $ram_mb, \%install_xopts, <<END);
+$method_cfg
+extra       = "$cmdline"
+#
+disk        = [
+            $extra_disk 'phy:$gho->{Lvdev},xvda,w'
+            ]
+END
+
+    my $cmd= toolstack()->{Command}." create ".
+        $r{ $gho->{Guest}.'_'. toolstack()->{CfgPathVar} };
+    target_cmd_root($ho, $cmd, 300);
+
+    guest_checkrunning($ho, $gho) or die "$gho->{Name} not running";
+
+    guest_await_shutdown($ho,$gho,3600);
+    guest_destroy($ho,$gho);
+
+    my $blcfg = <<END;
+bootloader = "pygrub"
+END
+
+    prepareguest_part_xencfg($ho, $gho, $ram_mb, {}, <<END);
+$blcfg
+#
+disk        = [
+            'phy:$gho->{Lvdev},xvda,w'
+            ]
+END
+    return;
+}
+
+prep();
+ginstall();
-- 
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 Mon Dec 01 12:57:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQY7-0007EZ-G8; Mon, 01 Dec 2014 12:57:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQY5-00079v-3j
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0D/0B-25276-0D56C745; Mon, 01 Dec 2014 12:57:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!9
X-Originating-IP: [66.165.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 5042 invoked from network); 1 Dec 2014 12:57:51 -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;
	1 Dec 2014 12:57:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046173"
Received: from ukmail1.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, 1 Dec 2014 07:57:49 -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 1XvQY0-0002Qa-H7;
	Mon, 01 Dec 2014 12:57:49 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:48 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:29 +0000
Message-ID: <1417438656-15451-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 12/19] distros: add support for
	installing Debian PV guests via d-i, flight and jobs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch introduces ts-debian-di-install which can install Debian
from a netboot (PXE) debian installer image. By default it installs
from the d-i image used by osstest (using the special Xen PV guest
enabled flavour where necessary) but it can also install the current
release versions from Squeeze onwards (up to and including Sid) and
the d-i daily builds. This is controlled by runvars {Guest}_diver =
osstest|current and {Guest}_dist = squeeze|...|sid.  The resulting
guests boot the distro kernel using pygrub (pvgrub will follow).

The distros flights differ substantially from the existing flights.
Introduce make-distros-flight using the functionality previously
refactored into mfi-common. The new flight tests all versions of
Debian from Squeeze onward as an amd64, i386 and armhf guests (armhf
from Jessie onwards only) using the usual smoke tests.

Test names are suffixed -pygrub pending the addition of pvgrub
variants in a future commit.

Add the new cases to sg-run-job

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: $BUILD_LVEXTEND_MAX now handled in mfi-common
    Consolidate setting of ruvars
    Include $flight and $job in tmpdir name
    Use Osstest::Debian::di_installcmdline_core
    Document the usage of get_host_property on a guest object
    Correct ARM netboot paths
    Include bootloader in test name
       Should include -pv too?
    console= repetition for Jessie onwards.
    Wait for up to an hour for the install. I'd seen timeouts right at
    the end of the install with the previous value
---
 Osstest/TestSupport.pm |   3 +
 make-distros-flight    |  98 ++++++++++++++++++++++++++++
 sg-run-job             |  11 ++++
 ts-debian-di-install   | 170 +++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 282 insertions(+)
 create mode 100755 make-distros-flight
 create mode 100755 ts-debian-di-install

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 2f23fd4..c1ecd8d 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -861,8 +861,11 @@ sub propname_massage ($) {
     return $prop;
 }
 
+# It is fine to call this on a guest object too, in which case it will
+# always return $defval.
 sub get_host_property ($$;$) {
     my ($ho, $prop, $defval) = @_;
+    return $defval unless $ho->{Properties};
     my $val = $ho->{Properties}{propname_massage($prop)};
     return defined($val) ? $val : $defval;
 }
diff --git a/make-distros-flight b/make-distros-flight
new file mode 100755
index 0000000..5067342
--- /dev/null
+++ b/make-distros-flight
@@ -0,0 +1,98 @@
+#!/bin/bash
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 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
+
+branch=$1
+xenbranch=$2
+blessing=$3
+buildflight=$4
+
+flight=`./cs-flight-create $blessing $branch`
+
+. cri-common
+. ap-common
+. mfi-common
+
+defsuite=`getconfig DebianSuite`
+defguestsuite=`getconfig GuestDebianSuite`
+
+if [ x$buildflight = x ]; then
+
+  WANT_XEND=false REVISION_LINUX_OLD=disable
+
+  create_build_jobs
+
+else
+
+  bfi=$buildflight.
+
+fi
+
+job_create_test_filter_callback () {
+  if [ "$xenarch" = "i386" ]; then return 1; fi
+  return 0
+}
+
+test_matrix_branch_filter_callback () {
+    :
+}
+
+test_do_one_netboot () {
+  job_create_test                                               \
+   test-$xenarch$kern-$dom0arch-$domU-$dist-netboot-pygrub      \
+    test-debian-di xl $xenarch $dom0arch                        \
+      kernbuildjob=${bfi}build-$dom0arch-$kernbuild             \
+      debian_arch=$domU                                         \
+      debian_dist=$dist                                         \
+      debian_method=netboot                                     \
+      debian_diver=current                                      \
+      all_hostflags=$most_hostflags
+}
+
+test_matrix_do_one () {
+  case ${xenarch} in
+  amd64) domUarches="amd64 i386";;
+  armhf) domUarches="armhf";;
+  esac
+
+  for domU in $domUarches ; do
+    for dist in squeeze wheezy jessie sid daily ; do
+      case ${domU}_${dist} in
+      armhf_squeeze) continue;; # No armhf in Squeeze
+      armhf_wheezy) continue;; # No armhf guest support in Wheezy
+      *) ;;
+      esac
+
+      test_do_one_netboot
+
+    done
+
+  done
+}
+
+test_matrix_iterate
+
+echo $flight
+
+# Local variables:
+# mode: sh
+# sh-basic-offset: 2
+# indent-tabs-mode: nil
+# End:
diff --git a/sg-run-job b/sg-run-job
index 2cf810a..9943ee4 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -247,6 +247,17 @@ proc run-job/test-debian {} {
     test-guest debian
 }
 
+proc install-guest-debian-di {} {
+    run-ts . = ts-debian-di-install
+    run-ts . = ts-guest-start + debian
+}
+
+proc need-hosts/test-debian-di {} { return host }
+proc run-job/test-debian-di {} {
+    install-guest-debian-di
+    test-guest debian
+}
+
 proc need-hosts/test-freebsd {} { return host }
 proc run-job/test-freebsd {} {
     run-ts . = ts-freebsd-install
diff --git a/ts-debian-di-install b/ts-debian-di-install
new file mode 100755
index 0000000..edccf52
--- /dev/null
+++ b/ts-debian-di-install
@@ -0,0 +1,170 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::Debian;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+$gn ||= 'debian';
+
+our $ho= selecthost($whhost);
+
+our $ram_mb=    512;
+our $disk_mb= 10000;
+
+our $guesthost= "$gn.guest.osstest";
+our $gho;
+
+sub prep () {
+    target_install_packages_norec($ho, qw(lvm2));
+
+    $gho= prepareguest($ho, $gn, $guesthost, 22,
+                       $disk_mb, 40);
+
+    prepareguest_part_lvmdisk($ho, $gho, $disk_mb);
+
+    target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
+}
+
+sub setup_netboot($$$)
+{
+    my ($didir, $arch, $suite) = @_;
+
+    my $di_ver= $r{"$gho->{Guest}_diver"} || "osstest";
+
+    my ($kernel,$initrd);
+
+    if ( $di_ver eq "osstest" ) {
+	my $di_path = $c{TftpPath}.'/'.$ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'.$c{TftpDiVersion}.'-'.$ho->{Suite};
+
+	$kernel = "$di_path/vmlinuz-xen";
+	$initrd = "$di_path/initrd.gz-xen";
+
+	target_putfile_root($ho, 60, $kernel, "$didir/kernel_${suite}_${arch}");
+	target_putfile_root($ho, 60, $initrd, "$didir/initrd_${suite}_${arch}");
+
+    } else {
+	my $mirror = "http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath}";
+
+	my $di_url = $suite eq "daily" ?
+	    "http://d-i.debian.org/daily-images/$arch/daily/netboot" :
+	    "$mirror/dists/$suite/main/installer-$arch/$di_ver/images/netboot";
+
+	$di_url .= "/xen" if $arch =~ m/amd64|i386/;
+	$di_url .= "/debian-installer/arm64" if $arch =~ /arm64/;
+
+	$kernel = "$di_url/vmlinuz";
+	$initrd = "$di_url/initrd.gz";
+
+	target_fetchurl($ho, $kernel, "$didir/kernel_${suite}_${arch}");
+	target_fetchurl($ho, $initrd, "$didir/initrd_${suite}_${arch}");
+    }
+
+    store_runvar("$gho->{Guest}_netboot_kernel", $kernel);
+    store_runvar("$gho->{Guest}_netboot_initrd", $initrd);
+
+    return <<END;
+kernel      = "$didir/kernel_${suite}_${arch}"
+ramdisk     = "$didir/initrd_${suite}_${arch}"
+END
+}
+sub ginstall () {
+    my $arch= $r{"$gho->{Guest}_arch"};
+    my $method= $r{"$gho->{Guest}_method"};
+
+    my $tmpdir= "/root/$flight-$job-di";
+    target_cmd_root($ho, <<END);
+rm -rf $tmpdir
+mkdir $tmpdir
+END
+
+    my ($method_cfg, $ps_url, $extra_disk);
+
+    if ( $method eq "netboot" )
+    {
+	my $suite= $r{"$gho->{Guest}_dist"};
+	logm("$method $suite/$arch");
+
+	$method_cfg = setup_netboot($tmpdir, $arch, $suite);
+
+	$suite = "sid" if $suite eq "daily";
+
+	$ps_url = preseed_create_guest($gho, '', Suite=>$suite);
+
+	$extra_disk = "";
+    }
+    else
+    {
+	die "$method";
+    }
+
+    my @cmdline = ();
+    push @cmdline, "debian-installer/exit/always_halt=true";
+    push @cmdline, "domain=$c{TestHostDomain}";
+    push @cmdline, "console=hvc0";
+    push @cmdline, di_installcmdline_core($gho, $ps_url);
+    push @cmdline, "--";
+    # See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007 for
+    # why this is repeated.
+    push @cmdline, "console=hvc0";
+
+    my $cmdline = join(" ", @cmdline);
+
+    my %install_xopts = (
+	OnPowerOff => "preserve"
+    );
+
+    prepareguest_part_xencfg($ho, $gho, $ram_mb, \%install_xopts, <<END);
+$method_cfg
+extra       = "$cmdline"
+#
+disk        = [
+            $extra_disk 'phy:$gho->{Lvdev},xvda,w'
+            ]
+END
+
+    my $cmd= toolstack()->{Command}." create ".
+        $r{ $gho->{Guest}.'_'. toolstack()->{CfgPathVar} };
+    target_cmd_root($ho, $cmd, 300);
+
+    guest_checkrunning($ho, $gho) or die "$gho->{Name} not running";
+
+    guest_await_shutdown($ho,$gho,3600);
+    guest_destroy($ho,$gho);
+
+    my $blcfg = <<END;
+bootloader = "pygrub"
+END
+
+    prepareguest_part_xencfg($ho, $gho, $ram_mb, {}, <<END);
+$blcfg
+#
+disk        = [
+            'phy:$gho->{Lvdev},xvda,w'
+            ]
+END
+    return;
+}
+
+prep();
+ginstall();
-- 
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 Mon Dec 01 12:57:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:57:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQY8-0007FW-3A; Mon, 01 Dec 2014 12:57: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 1XvQY6-0007Bj-04
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:54 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	00/1B-25276-0D56C745; Mon, 01 Dec 2014 12:57:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!10
X-Originating-IP: [66.165.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 5198 invoked from network); 1 Dec 2014 12:57:52 -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;
	1 Dec 2014 12:57:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046178"
Received: from ukmail1.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, 1 Dec 2014 07:57:50 -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 1XvQY1-0002Qd-IY;
	Mon, 01 Dec 2014 12:57:50 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:30 +0000
Message-ID: <1417438656-15451-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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/19] distros: support booting
	Debian PV (d-i installed) guests with pvgrub.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This requires the use of the pv-grub-menu package which is in Jessie
onwards.  (it is in wheezy-backports which is the subject of a
subsequent flight).

The bootloader to use is specified via a runvar {Guest}_bootloader.

Adjust make-distros-flight to use pvgrub for some subset of i386 and
amd64 guests to get coverage.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Define and use arch_debian2xen and arch_xen2debian
    Avoid pv-grub-x86_64.gz on i386 dom0, we don't built it there.
    Fiddle with py vs pv grub stripy a bit.
---
 Osstest.pm           |  7 +++++++
 Osstest/Debian.pm    |  2 +-
 make-distros-flight  | 21 ++++++++++++++++++++-
 ts-debian-di-install | 11 +++++++++--
 4 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/Osstest.pm b/Osstest.pm
index fc9698b..31088ba 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -36,6 +36,7 @@ BEGIN {
                       db_begin_work
                       ensuredir get_filecontents_core_quiet system_checked
                       nonempty visible_undef show_abs_time
+                      %arch_debian2xen %arch_xen2debian
                       );
     %EXPORT_TAGS = ( );
 
@@ -47,6 +48,12 @@ our $mjobdb;
 
 our $dbh_tests;
 
+our %arch_debian2xen = qw(i386 x86_32
+			  amd64 x86_64
+			  armhf armhf);
+our %arch_xen2debian;
+$arch_xen2debian{$arch_debian2xen{$_}} = $_ foreach keys %arch_debian2xen;
+
 #---------- static default config settings ----------
 
 our %c = qw(
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c4afde1..a15768f 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -570,7 +570,7 @@ sub preseed_create_guest ($$;@) {
 
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
-    my $extra_packages;
+    my $extra_packages = "pv-grub-menu" if $xopts{PvMenuLst};
 
     my $preseed_file= preseed_base($suite, $extra_packages, %xopts);
     $preseed_file.= (<<END);
diff --git a/make-distros-flight b/make-distros-flight
index 5067342..80df21b 100755
--- a/make-distros-flight
+++ b/make-distros-flight
@@ -55,14 +55,33 @@ test_matrix_branch_filter_callback () {
 }
 
 test_do_one_netboot () {
+  stripy bootloader pvgrub pygrub \
+    "$xenarch" "amd64" \
+    "$dom0arch" "i386" \
+    "$domU" "amd64" \
+    "$dist" "sid"
+
+  case ${dom0arch}_${domU}_${dist} in
+    arm*_arm*_*) bootloader="pygrub";; # no pvgrub for arm
+
+    # Needs a menu.lst, not present in Squeeze+ due to switch to grub2,
+    # workedaround in Jessie+ with pv-grub-menu package.
+    *_squeeze) bootloader="pygrub";;
+    *_wheezy) bootloader="pygrub";;
+
+    # pv-grub-x86_64.gz is not built by 32-bit dom0 userspace build.
+    i386_amd64_*) bootloader="pygrub";;
+  esac
+
   job_create_test                                               \
-   test-$xenarch$kern-$dom0arch-$domU-$dist-netboot-pygrub      \
+   test-$xenarch$kern-$dom0arch-$domU-$dist-netboot-$bootloader \
     test-debian-di xl $xenarch $dom0arch                        \
       kernbuildjob=${bfi}build-$dom0arch-$kernbuild             \
       debian_arch=$domU                                         \
       debian_dist=$dist                                         \
       debian_method=netboot                                     \
       debian_diver=current                                      \
+      debian_bootloader=$bootloader                             \
       all_hostflags=$most_hostflags
 }
 
diff --git a/ts-debian-di-install b/ts-debian-di-install
index edccf52..f3fe4cf 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -93,6 +93,8 @@ sub ginstall () {
     my $method= $r{"$gho->{Guest}_method"};
 
     my $tmpdir= "/root/$flight-$job-di";
+    my $bl= $r{"$gho->{Guest}_bootloader"};
+
     target_cmd_root($ho, <<END);
 rm -rf $tmpdir
 mkdir $tmpdir
@@ -109,7 +111,7 @@ END
 
 	$suite = "sid" if $suite eq "daily";
 
-	$ps_url = preseed_create_guest($gho, '', Suite=>$suite);
+	$ps_url = preseed_create_guest($gho, '', Suite=>$suite, PvMenuLst=>($bl eq "pvgrub"));
 
 	$extra_disk = "";
     }
@@ -152,7 +154,12 @@ END
     guest_await_shutdown($ho,$gho,3600);
     guest_destroy($ho,$gho);
 
-    my $blcfg = <<END;
+    my $xenarch = $arch_debian2xen{$arch};
+    my $pvgrub = "/usr/local/lib/xen/boot/pv-grub-$xenarch.gz";
+    my $blcfg = $bl eq "pvgrub" ? <<END : <<END;
+kernel = "$pvgrub"
+extra = "(hd0,0)/boot/grub/menu.lst"
+END
 bootloader = "pygrub"
 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 Mon Dec 01 12:57:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:57:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQY8-0007FW-3A; Mon, 01 Dec 2014 12:57: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 1XvQY6-0007Bj-04
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:54 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	00/1B-25276-0D56C745; Mon, 01 Dec 2014 12:57:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417438659!12228738!10
X-Originating-IP: [66.165.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 5198 invoked from network); 1 Dec 2014 12:57:52 -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;
	1 Dec 2014 12:57:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046178"
Received: from ukmail1.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, 1 Dec 2014 07:57:50 -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 1XvQY1-0002Qd-IY;
	Mon, 01 Dec 2014 12:57:50 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:30 +0000
Message-ID: <1417438656-15451-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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/19] distros: support booting
	Debian PV (d-i installed) guests with pvgrub.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This requires the use of the pv-grub-menu package which is in Jessie
onwards.  (it is in wheezy-backports which is the subject of a
subsequent flight).

The bootloader to use is specified via a runvar {Guest}_bootloader.

Adjust make-distros-flight to use pvgrub for some subset of i386 and
amd64 guests to get coverage.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Define and use arch_debian2xen and arch_xen2debian
    Avoid pv-grub-x86_64.gz on i386 dom0, we don't built it there.
    Fiddle with py vs pv grub stripy a bit.
---
 Osstest.pm           |  7 +++++++
 Osstest/Debian.pm    |  2 +-
 make-distros-flight  | 21 ++++++++++++++++++++-
 ts-debian-di-install | 11 +++++++++--
 4 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/Osstest.pm b/Osstest.pm
index fc9698b..31088ba 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -36,6 +36,7 @@ BEGIN {
                       db_begin_work
                       ensuredir get_filecontents_core_quiet system_checked
                       nonempty visible_undef show_abs_time
+                      %arch_debian2xen %arch_xen2debian
                       );
     %EXPORT_TAGS = ( );
 
@@ -47,6 +48,12 @@ our $mjobdb;
 
 our $dbh_tests;
 
+our %arch_debian2xen = qw(i386 x86_32
+			  amd64 x86_64
+			  armhf armhf);
+our %arch_xen2debian;
+$arch_xen2debian{$arch_debian2xen{$_}} = $_ foreach keys %arch_debian2xen;
+
 #---------- static default config settings ----------
 
 our %c = qw(
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c4afde1..a15768f 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -570,7 +570,7 @@ sub preseed_create_guest ($$;@) {
 
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
-    my $extra_packages;
+    my $extra_packages = "pv-grub-menu" if $xopts{PvMenuLst};
 
     my $preseed_file= preseed_base($suite, $extra_packages, %xopts);
     $preseed_file.= (<<END);
diff --git a/make-distros-flight b/make-distros-flight
index 5067342..80df21b 100755
--- a/make-distros-flight
+++ b/make-distros-flight
@@ -55,14 +55,33 @@ test_matrix_branch_filter_callback () {
 }
 
 test_do_one_netboot () {
+  stripy bootloader pvgrub pygrub \
+    "$xenarch" "amd64" \
+    "$dom0arch" "i386" \
+    "$domU" "amd64" \
+    "$dist" "sid"
+
+  case ${dom0arch}_${domU}_${dist} in
+    arm*_arm*_*) bootloader="pygrub";; # no pvgrub for arm
+
+    # Needs a menu.lst, not present in Squeeze+ due to switch to grub2,
+    # workedaround in Jessie+ with pv-grub-menu package.
+    *_squeeze) bootloader="pygrub";;
+    *_wheezy) bootloader="pygrub";;
+
+    # pv-grub-x86_64.gz is not built by 32-bit dom0 userspace build.
+    i386_amd64_*) bootloader="pygrub";;
+  esac
+
   job_create_test                                               \
-   test-$xenarch$kern-$dom0arch-$domU-$dist-netboot-pygrub      \
+   test-$xenarch$kern-$dom0arch-$domU-$dist-netboot-$bootloader \
     test-debian-di xl $xenarch $dom0arch                        \
       kernbuildjob=${bfi}build-$dom0arch-$kernbuild             \
       debian_arch=$domU                                         \
       debian_dist=$dist                                         \
       debian_method=netboot                                     \
       debian_diver=current                                      \
+      debian_bootloader=$bootloader                             \
       all_hostflags=$most_hostflags
 }
 
diff --git a/ts-debian-di-install b/ts-debian-di-install
index edccf52..f3fe4cf 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -93,6 +93,8 @@ sub ginstall () {
     my $method= $r{"$gho->{Guest}_method"};
 
     my $tmpdir= "/root/$flight-$job-di";
+    my $bl= $r{"$gho->{Guest}_bootloader"};
+
     target_cmd_root($ho, <<END);
 rm -rf $tmpdir
 mkdir $tmpdir
@@ -109,7 +111,7 @@ END
 
 	$suite = "sid" if $suite eq "daily";
 
-	$ps_url = preseed_create_guest($gho, '', Suite=>$suite);
+	$ps_url = preseed_create_guest($gho, '', Suite=>$suite, PvMenuLst=>($bl eq "pvgrub"));
 
 	$extra_disk = "";
     }
@@ -152,7 +154,12 @@ END
     guest_await_shutdown($ho,$gho,3600);
     guest_destroy($ho,$gho);
 
-    my $blcfg = <<END;
+    my $xenarch = $arch_debian2xen{$arch};
+    my $pvgrub = "/usr/local/lib/xen/boot/pv-grub-$xenarch.gz";
+    my $blcfg = $bl eq "pvgrub" ? <<END : <<END;
+kernel = "$pvgrub"
+extra = "(hd0,0)/boot/grub/menu.lst"
+END
 bootloader = "pygrub"
 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 Mon Dec 01 12:57:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:57:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQY9-0007JK-Sd; Mon, 01 Dec 2014 12:57: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 1XvQY8-0007G4-Nv
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	86/3B-15461-4D56C745; Mon, 01 Dec 2014 12:57:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417438674!12553736!1
X-Originating-IP: [66.165.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 14218 invoked from network); 1 Dec 2014 12:57:55 -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;
	1 Dec 2014 12:57:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046187"
Received: from ukmail1.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, 1 Dec 2014 07:57:51 -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 1XvQY2-0002Qg-K1;
	Mon, 01 Dec 2014 12:57:51 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:31 +0000
Message-ID: <1417438656-15451-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 14/19] distros: Support pvgrub for
	Wheezy too.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This requires us to install pv-grub-menu from backports, which we do
using a late_command.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3:
  - Remove spurious () from <<(END) (and the prexisting "" too)
  - Remove $xopts{EnableBackports} and automatically handle the need to add
    backports in preseed_base.
  - Install via late_command not apt-setup, since the former has
    issues, hence subject drops "attempt to..."
---
 Osstest/Debian.pm   | 46 ++++++++++++++++++++++++++++++++++++++++++++--
 make-distros-flight |  4 ++--
 2 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index a15768f..dc01be5 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -491,7 +491,7 @@ sub preseed_base ($$;@) {
     $extra_packages ||= '';
     $xopts{ExtraPreseed} ||= '';
 
-    return <<"END";
+    my $preseed= <<END;
 d-i mirror/suite string $suite
 
 d-i debian-installer/locale string en_GB
@@ -558,6 +558,17 @@ d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, wget, $extra_pa
 $xopts{ExtraPreseed}
 END
 
+    # deb http://ftp.debian.org/debian/ wheezy-backports main
+    $preseed .= <<END if $extra_packages =~ m#\b/$suite-backports\b#;
+d-i apt-setup/local0/repository string \\
+    http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} $suite-backports main
+d-i apt-setup/local0/comment string $suite backports
+END
+# Jessie onwards...
+#    $preseed .= <<END if $extra_packages =~ m#\b/$suite-backports\b#;
+#d-i apt-setup/services-select multiselect security, updates, backports
+#END
+
     $preseed .= <<END;
 ### END OF DEBIAN PRESEED BASE
 END
@@ -570,7 +581,38 @@ sub preseed_create_guest ($$;@) {
 
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
-    my $extra_packages = "pv-grub-menu" if $xopts{PvMenuLst};
+    my $extra_packages = "";
+    if ($xopts{PvMenuLst}) {
+        if ($suite =~ m/wheezy/) {
+            # pv-grub-menu/wheezy-backports + using apt-setup to add
+            # backports results in iproute, ifupdown and
+            # isc-dhcp-client getting removed because tasksel's
+            # invocation of apt-get install somehow decides the
+            # iproute2 from wheezy-backports is a thing it wants to
+            # install. So instead lets fake it with a late command...
+            #
+	    # This also has the bonus of working round an issue with
+	    # 1.2.1~bpo70+1 which created an invalid menu.lst using
+            # "root(/dev/xvda,0)" which pvgrub cannot parse because
+            # the Grub device.map isn't present at pkgsel/include time
+            # but it is by late_command time. This was fixed by
+            # version 1.3 which is in Jessie onwards.
+            preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+(
+    echo
+    echo \\\# $suite backports
+    echo deb http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} $suite-backports main
+) >> /target/etc/apt/sources.list
+in-target apt-get update
+in-target apt-get install -y -t wheezy-backports pv-grub-menu
+END
+        } else {
+            $extra_packages = "pv-grub-menu";
+        }
+    }
 
     my $preseed_file= preseed_base($suite, $extra_packages, %xopts);
     $preseed_file.= (<<END);
diff --git a/make-distros-flight b/make-distros-flight
index 80df21b..97df89a 100755
--- a/make-distros-flight
+++ b/make-distros-flight
@@ -65,9 +65,9 @@ test_do_one_netboot () {
     arm*_arm*_*) bootloader="pygrub";; # no pvgrub for arm
 
     # Needs a menu.lst, not present in Squeeze+ due to switch to grub2,
-    # workedaround in Jessie+ with pv-grub-menu package.
+    # workedaround in Wheezy+ with pv-grub-menu package (backports in Wheezy,
+    # in Jessie+ main).
     *_squeeze) bootloader="pygrub";;
-    *_wheezy) bootloader="pygrub";;
 
     # pv-grub-x86_64.gz is not built by 32-bit dom0 userspace build.
     i386_amd64_*) bootloader="pygrub";;
-- 
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 Mon Dec 01 12:57:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:57:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQY9-0007JK-Sd; Mon, 01 Dec 2014 12:57: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 1XvQY8-0007G4-Nv
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	86/3B-15461-4D56C745; Mon, 01 Dec 2014 12:57:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417438674!12553736!1
X-Originating-IP: [66.165.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 14218 invoked from network); 1 Dec 2014 12:57:55 -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;
	1 Dec 2014 12:57:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046187"
Received: from ukmail1.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, 1 Dec 2014 07:57:51 -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 1XvQY2-0002Qg-K1;
	Mon, 01 Dec 2014 12:57:51 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:31 +0000
Message-ID: <1417438656-15451-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 14/19] distros: Support pvgrub for
	Wheezy too.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This requires us to install pv-grub-menu from backports, which we do
using a late_command.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3:
  - Remove spurious () from <<(END) (and the prexisting "" too)
  - Remove $xopts{EnableBackports} and automatically handle the need to add
    backports in preseed_base.
  - Install via late_command not apt-setup, since the former has
    issues, hence subject drops "attempt to..."
---
 Osstest/Debian.pm   | 46 ++++++++++++++++++++++++++++++++++++++++++++--
 make-distros-flight |  4 ++--
 2 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index a15768f..dc01be5 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -491,7 +491,7 @@ sub preseed_base ($$;@) {
     $extra_packages ||= '';
     $xopts{ExtraPreseed} ||= '';
 
-    return <<"END";
+    my $preseed= <<END;
 d-i mirror/suite string $suite
 
 d-i debian-installer/locale string en_GB
@@ -558,6 +558,17 @@ d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, wget, $extra_pa
 $xopts{ExtraPreseed}
 END
 
+    # deb http://ftp.debian.org/debian/ wheezy-backports main
+    $preseed .= <<END if $extra_packages =~ m#\b/$suite-backports\b#;
+d-i apt-setup/local0/repository string \\
+    http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} $suite-backports main
+d-i apt-setup/local0/comment string $suite backports
+END
+# Jessie onwards...
+#    $preseed .= <<END if $extra_packages =~ m#\b/$suite-backports\b#;
+#d-i apt-setup/services-select multiselect security, updates, backports
+#END
+
     $preseed .= <<END;
 ### END OF DEBIAN PRESEED BASE
 END
@@ -570,7 +581,38 @@ sub preseed_create_guest ($$;@) {
 
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
-    my $extra_packages = "pv-grub-menu" if $xopts{PvMenuLst};
+    my $extra_packages = "";
+    if ($xopts{PvMenuLst}) {
+        if ($suite =~ m/wheezy/) {
+            # pv-grub-menu/wheezy-backports + using apt-setup to add
+            # backports results in iproute, ifupdown and
+            # isc-dhcp-client getting removed because tasksel's
+            # invocation of apt-get install somehow decides the
+            # iproute2 from wheezy-backports is a thing it wants to
+            # install. So instead lets fake it with a late command...
+            #
+	    # This also has the bonus of working round an issue with
+	    # 1.2.1~bpo70+1 which created an invalid menu.lst using
+            # "root(/dev/xvda,0)" which pvgrub cannot parse because
+            # the Grub device.map isn't present at pkgsel/include time
+            # but it is by late_command time. This was fixed by
+            # version 1.3 which is in Jessie onwards.
+            preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+(
+    echo
+    echo \\\# $suite backports
+    echo deb http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} $suite-backports main
+) >> /target/etc/apt/sources.list
+in-target apt-get update
+in-target apt-get install -y -t wheezy-backports pv-grub-menu
+END
+        } else {
+            $extra_packages = "pv-grub-menu";
+        }
+    }
 
     my $preseed_file= preseed_base($suite, $extra_packages, %xopts);
     $preseed_file.= (<<END);
diff --git a/make-distros-flight b/make-distros-flight
index 80df21b..97df89a 100755
--- a/make-distros-flight
+++ b/make-distros-flight
@@ -65,9 +65,9 @@ test_do_one_netboot () {
     arm*_arm*_*) bootloader="pygrub";; # no pvgrub for arm
 
     # Needs a menu.lst, not present in Squeeze+ due to switch to grub2,
-    # workedaround in Jessie+ with pv-grub-menu package.
+    # workedaround in Wheezy+ with pv-grub-menu package (backports in Wheezy,
+    # in Jessie+ main).
     *_squeeze) bootloader="pygrub";;
-    *_wheezy) bootloader="pygrub";;
 
     # pv-grub-x86_64.gz is not built by 32-bit dom0 userspace build.
     i386_amd64_*) bootloader="pygrub";;
-- 
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 Mon Dec 01 12:57:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:57:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQYA-0007L9-Nd; Mon, 01 Dec 2014 12:57:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQY9-0007HA-7Z
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AD/D5-09842-4D56C745; Mon, 01 Dec 2014 12:57:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417438674!12601809!1
X-Originating-IP: [66.165.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 6749 invoked from network); 1 Dec 2014 12:57:55 -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;
	1 Dec 2014 12:57:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372269"
Received: from ukmail1.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, 1 Dec 2014 07:57:55 -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 1XvQY5-0002Qq-P5;
	Mon, 01 Dec 2014 12:57:54 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:34 +0000
Message-ID: <1417438656-15451-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 17/19] distros: add branch
	infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since the distro nightlies are not version controlled we cannot use
the usual mechanisms for detecting regressions. Special case things
appropriately. We use an OLD_REVISION of "flight-NNN" to signify that
the old revision is another flight and not a tree revision.

A grep over $NEW_REVISION needed adjusting since NEW_REVISION is empty
in this mode, leading to "grep <filename>" which hangs waiting for
stdin.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3:
  Handle within cr-daily-branch, since ap-fetch-version* don't make sense for
  a branch such as this.
---
 cr-daily-branch | 39 ++++++++++++++++++++++++++++++---------
 cri-common      |  1 +
 2 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/cr-daily-branch b/cr-daily-branch
index d00ecbb..5e8e51e 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -68,24 +68,36 @@ fetch_version () {
 	printf '%s\n' "$fetch_version_result"
 }
 
-treeurl=`./ap-print-url $branch`
+case $branch in
+    distros)
+	treeurl=none;;
+    *)
+	treeurl=`./ap-print-url $branch`;;
+esac
 
 force_baseline=false
 skipidentical=true
 wantpush=$OSSTEST_PUSH
 
-if [ "x$OLD_REVISION" = x ]; then
-        OLD_REVISION="`./ap-fetch-version-old $branch`"
-        export OLD_REVISION
-fi
-
 check_tested () {
 	./sg-check-tested --debug --branch=$branch \
 	  --blessings=${DAILY_BRANCH_TESTED_BLESSING:-$OSSTEST_BLESSING} \
 	  "$@"
 }
 
-if [ "x$OSSTEST_NO_BASELINE" != xy ] ; then
+if [ "x$OLD_REVISION" = x ]; then
+    case $branch in
+	distros)
+	    OSSTEST_NO_BASELINE=y
+	    OLD_REVISION=flight-`check_tested`
+	    ;;
+	*) OLD_REVISION="`./ap-fetch-version-old $branch`";;
+    esac
+    export OLD_REVISION
+fi
+
+
+if [ "x$OSSTEST_NO_BASELINE" != xy ]; then
 	testedflight=`check_tested --revision-$tree="$OLD_REVISION"`
 
 	if [ "x$testedflight" = x ]; then
@@ -217,6 +229,11 @@ if [ "x$OLD_REVISION" = xdetermine-late ]; then
 	OLD_REVISION="`./ap-fetch-version-baseline-late $branch $NEW_REVISION`"
 fi
 
+case $branch in
+distros) makeflight=./make-distros-flight ;;
+*)       makeflight=./make-flight ;;
+esac
+
 if [ "x$NEW_REVISION" = "x$OLD_REVISION" ]; then
         wantpush=false
 	for checkbranch in x $BRANCHES_ALWAYS; do
@@ -231,7 +248,7 @@ if [ "x$NEW_REVISION" = "x$OLD_REVISION" ]; then
 fi
 
 $DAILY_BRANCH_PREMAKE_HOOK
-flight=`./make-flight $branch $xenbranch $OSSTEST_BLESSING "$@"`
+flight=`$makeflight $branch $xenbranch $OSSTEST_BLESSING "$@"`
 $DAILY_BRANCH_POSTMAKE_HOOK
 
 heading=tmp/$flight.heading-info
@@ -251,6 +268,10 @@ fi
 revlog=tmp/$flight.revision-log
 
 case "$NEW_REVISION/$OLD_REVISION" in
+/flight-[0-9]*)
+	echo >&2 "SGR COMPARISON AGAINST ${OLD_REVISION}"
+	sgr_args+=" --that-flight=${OLD_REVISION#flight-}"
+	;;
 */*[^0-9a-f]* | *[^0-9a-f]*/*)
         echo >&2 "NO SGR COMPARISON badchar $NEW_REVISION/$OLD_REVISION"
         ;;
@@ -309,7 +330,7 @@ start_email $flight $branch "$sgr_args" "$subject_prefix"
 push=false
 if grep '^tolerable$' $mrof >/dev/null 2>&1; then push=$wantpush; fi
 if test -f $branch.force; then push=$OSSTEST_PUSH; fi
-if grep -xF $NEW_REVISION $branch.force-rev; then push=$OSSTEST_PUSH; fi
+if test -n "$NEW_REVISION" && grep -xF $NEW_REVISION $branch.force-rev; then push=$OSSTEST_PUSH; fi
 if test -f $branch.block; then push=false; fi
 
 if test -e $mrof && test -e $tree_bisect && ! grep '^broken' $mrof; then
diff --git a/cri-common b/cri-common
index 06a8d67..e107cd7 100644
--- a/cri-common
+++ b/cri-common
@@ -71,6 +71,7 @@ select_xenbranch () {
 	libvirt)		tree=libvirt;	xenbranch=xen-unstable ;;
 	rumpuserxen)	      tree=rumpuserxen; xenbranch=xen-unstable ;;
 	seabios)		tree=seabios;	xenbranch=xen-unstable ;;
+	distros)		tree=none;	xenbranch=xen-unstable ;;
 	osstest)		tree=osstest;	xenbranch=xen-unstable ;;
 	esac
 	if [ "x$tree" = xlinux ]; 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 Mon Dec 01 12:57:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:57:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQYA-0007L9-Nd; Mon, 01 Dec 2014 12:57:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQY9-0007HA-7Z
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AD/D5-09842-4D56C745; Mon, 01 Dec 2014 12:57:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417438674!12601809!1
X-Originating-IP: [66.165.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 6749 invoked from network); 1 Dec 2014 12:57:55 -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;
	1 Dec 2014 12:57:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372269"
Received: from ukmail1.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, 1 Dec 2014 07:57:55 -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 1XvQY5-0002Qq-P5;
	Mon, 01 Dec 2014 12:57:54 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:34 +0000
Message-ID: <1417438656-15451-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 17/19] distros: add branch
	infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since the distro nightlies are not version controlled we cannot use
the usual mechanisms for detecting regressions. Special case things
appropriately. We use an OLD_REVISION of "flight-NNN" to signify that
the old revision is another flight and not a tree revision.

A grep over $NEW_REVISION needed adjusting since NEW_REVISION is empty
in this mode, leading to "grep <filename>" which hangs waiting for
stdin.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3:
  Handle within cr-daily-branch, since ap-fetch-version* don't make sense for
  a branch such as this.
---
 cr-daily-branch | 39 ++++++++++++++++++++++++++++++---------
 cri-common      |  1 +
 2 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/cr-daily-branch b/cr-daily-branch
index d00ecbb..5e8e51e 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -68,24 +68,36 @@ fetch_version () {
 	printf '%s\n' "$fetch_version_result"
 }
 
-treeurl=`./ap-print-url $branch`
+case $branch in
+    distros)
+	treeurl=none;;
+    *)
+	treeurl=`./ap-print-url $branch`;;
+esac
 
 force_baseline=false
 skipidentical=true
 wantpush=$OSSTEST_PUSH
 
-if [ "x$OLD_REVISION" = x ]; then
-        OLD_REVISION="`./ap-fetch-version-old $branch`"
-        export OLD_REVISION
-fi
-
 check_tested () {
 	./sg-check-tested --debug --branch=$branch \
 	  --blessings=${DAILY_BRANCH_TESTED_BLESSING:-$OSSTEST_BLESSING} \
 	  "$@"
 }
 
-if [ "x$OSSTEST_NO_BASELINE" != xy ] ; then
+if [ "x$OLD_REVISION" = x ]; then
+    case $branch in
+	distros)
+	    OSSTEST_NO_BASELINE=y
+	    OLD_REVISION=flight-`check_tested`
+	    ;;
+	*) OLD_REVISION="`./ap-fetch-version-old $branch`";;
+    esac
+    export OLD_REVISION
+fi
+
+
+if [ "x$OSSTEST_NO_BASELINE" != xy ]; then
 	testedflight=`check_tested --revision-$tree="$OLD_REVISION"`
 
 	if [ "x$testedflight" = x ]; then
@@ -217,6 +229,11 @@ if [ "x$OLD_REVISION" = xdetermine-late ]; then
 	OLD_REVISION="`./ap-fetch-version-baseline-late $branch $NEW_REVISION`"
 fi
 
+case $branch in
+distros) makeflight=./make-distros-flight ;;
+*)       makeflight=./make-flight ;;
+esac
+
 if [ "x$NEW_REVISION" = "x$OLD_REVISION" ]; then
         wantpush=false
 	for checkbranch in x $BRANCHES_ALWAYS; do
@@ -231,7 +248,7 @@ if [ "x$NEW_REVISION" = "x$OLD_REVISION" ]; then
 fi
 
 $DAILY_BRANCH_PREMAKE_HOOK
-flight=`./make-flight $branch $xenbranch $OSSTEST_BLESSING "$@"`
+flight=`$makeflight $branch $xenbranch $OSSTEST_BLESSING "$@"`
 $DAILY_BRANCH_POSTMAKE_HOOK
 
 heading=tmp/$flight.heading-info
@@ -251,6 +268,10 @@ fi
 revlog=tmp/$flight.revision-log
 
 case "$NEW_REVISION/$OLD_REVISION" in
+/flight-[0-9]*)
+	echo >&2 "SGR COMPARISON AGAINST ${OLD_REVISION}"
+	sgr_args+=" --that-flight=${OLD_REVISION#flight-}"
+	;;
 */*[^0-9a-f]* | *[^0-9a-f]*/*)
         echo >&2 "NO SGR COMPARISON badchar $NEW_REVISION/$OLD_REVISION"
         ;;
@@ -309,7 +330,7 @@ start_email $flight $branch "$sgr_args" "$subject_prefix"
 push=false
 if grep '^tolerable$' $mrof >/dev/null 2>&1; then push=$wantpush; fi
 if test -f $branch.force; then push=$OSSTEST_PUSH; fi
-if grep -xF $NEW_REVISION $branch.force-rev; then push=$OSSTEST_PUSH; fi
+if test -n "$NEW_REVISION" && grep -xF $NEW_REVISION $branch.force-rev; then push=$OSSTEST_PUSH; fi
 if test -f $branch.block; then push=false; fi
 
 if test -e $mrof && test -e $tree_bisect && ! grep '^broken' $mrof; then
diff --git a/cri-common b/cri-common
index 06a8d67..e107cd7 100644
--- a/cri-common
+++ b/cri-common
@@ -71,6 +71,7 @@ select_xenbranch () {
 	libvirt)		tree=libvirt;	xenbranch=xen-unstable ;;
 	rumpuserxen)	      tree=rumpuserxen; xenbranch=xen-unstable ;;
 	seabios)		tree=seabios;	xenbranch=xen-unstable ;;
+	distros)		tree=none;	xenbranch=xen-unstable ;;
 	osstest)		tree=osstest;	xenbranch=xen-unstable ;;
 	esac
 	if [ "x$tree" = xlinux ]; 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 Mon Dec 01 12:57:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:57:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQYB-0007Mp-Gm; Mon, 01 Dec 2014 12:57: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 1XvQY9-0007Hc-CY
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:57 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	18/21-02576-4D56C745; Mon, 01 Dec 2014 12:57:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417438674!6768210!1
X-Originating-IP: [66.165.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 14442 invoked from network); 1 Dec 2014 12:57:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:57:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372258"
Received: from ukmail1.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, 1 Dec 2014 07:57:53 -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 1XvQY3-0002Qj-LQ;
	Mon, 01 Dec 2014 12:57:52 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:32 +0000
Message-ID: <1417438656-15451-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 15/19] distros: support PV guest
	install from Debian netinst media.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The netinst media are iso images containing a base Debian install and
some (image size dependent) additional tasks.

On x86 the "multiarch" iso flavour contains a Xen capable kernel for
both i386 and amd64 so use that.

This adds support for two classes of ISO, the CD sized ones which are
built nightly and the DVD sized ones which are built weekly.

The images are downloaded using jigdo which sources the majority of
the data from a local Debian mirror, for this reason I have not
worried about the fact that the i386 and amd64 tests are downloading
the same thing (adding a specific download job would require finding
up to 4GB of scratch space for each flight).

The ISOs booted using pygrub which can extract the kernel and initrd
from a ISO image. The resulting guests are also booted with pygrub
since the pv-grub-menu package is not available on the ISO images and
we have pvgrub coverage from the netboot tests.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3:
  - Indent jigdo-lite script line to improve readability
  - Wrap bootloader_args
  - Fetch URL on target, to get a timeout. Use wget since that is arranged to
    be present.
  - include bootloader in test name.
---
 Osstest/Debian.pm    |  7 +++++--
 make-distros-flight  | 23 +++++++++++++++++++++
 ts-debian-di-install | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index dc01be5..25cacd2 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -492,8 +492,6 @@ sub preseed_base ($$;@) {
     $xopts{ExtraPreseed} ||= '';
 
     my $preseed= <<END;
-d-i mirror/suite string $suite
-
 d-i debian-installer/locale string en_GB
 d-i console-keymaps-at/keymap select gb
 d-i keyboard-configuration/xkb-keymap string en_GB
@@ -558,6 +556,11 @@ d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, wget, $extra_pa
 $xopts{ExtraPreseed}
 END
 
+    # For CDROM the suite is part of the image
+    $preseed .= <<END unless $xopts{CDROM};
+d-i mirror/suite string $suite
+END
+
     # deb http://ftp.debian.org/debian/ wheezy-backports main
     $preseed .= <<END if $extra_packages =~ m#\b/$suite-backports\b#;
 d-i apt-setup/local0/repository string \\
diff --git a/make-distros-flight b/make-distros-flight
index 97df89a..e3ec8f7 100755
--- a/make-distros-flight
+++ b/make-distros-flight
@@ -85,6 +85,20 @@ test_do_one_netboot () {
       all_hostflags=$most_hostflags
 }
 
+test_do_one_netinst () {
+  # Always pygrub since no pv-grub-menu on CD
+  job_create_test                                               \
+   test-$xenarch$kern-$dom0arch-$domU-$cd-netinst-pygrub        \
+    test-debian-di xl $xenarch $dom0arch                        \
+      kernbuildjob=${bfi}build-$dom0arch-$kernbuild             \
+      debian_arch=$domU                                         \
+      debian_cd=$cd                                             \
+      debian_method=netinst                                     \
+      debian_bootloader=pygrub                                  \
+      all_hostflags=$most_hostflags
+
+}
+
 test_matrix_do_one () {
   case ${xenarch} in
   amd64) domUarches="amd64 i386";;
@@ -103,6 +117,15 @@ test_matrix_do_one () {
 
     done
 
+    for cd in current weekly ; do
+      case ${domU}_${dist} in
+      armhf_*) continue;; # No iso targets for armhf
+      *) ;;
+      esac
+
+      test_do_one_netinst
+
+    done
   done
 }
 
diff --git a/ts-debian-di-install b/ts-debian-di-install
index f3fe4cf..3878f93 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -46,6 +46,53 @@ sub prep () {
     target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
 }
 
+sub setup_netinst($$$)
+{
+    my ($didir, $arch, $cd) = @_;
+    my %arch_props = (
+	amd64 => { PathArch => "multi-arch", FileArch => "amd64-i386", IsoPath => "/install.amd/xen" },
+	i386  => { PathArch => "multi-arch", FileArch => "amd64-i386", IsoPath => "/install.386/xen" },
+	armhf => { PathArch => "armhf",      FileArch => "armhf",      IsoPath => "/install.armhf" }
+    );
+    my $props = $arch_props{$arch} or die "Unknown arch $arch";
+
+    target_install_packages($ho, qw(jigdo-file));
+
+    my $baseurl = $cd eq "current" ?
+      "http://cdimage.debian.org/debian-cd/current/$props->{PathArch}/jigdo-cd" :
+      "http://cdimage.debian.org/cdimage/weekly-builds/$props->{PathArch}/jigdo-cd";
+
+    my $filebase;
+
+    # Use the MD5SUMs file as an index
+    logm("Fetch index from $baseurl/MD5SUMS");
+    my $idx = target_cmd_output_root($ho, "wget --quiet -O - $baseurl/MD5SUMS");
+    foreach (split /\n/, $idx) {
+	m/^[0-9a-f]{32}  (debian-.*-$props->{FileArch}-netinst)\.iso$/ or next;
+	$filebase = $1;
+	last;
+    }
+
+    die unless $filebase;
+
+    logm("Downloading $baseurl/$filebase.jigdo");
+    # Jigdo seems to use /etc/apt/sources.list or something, so this
+    # just works using the already configured mirror without
+    # additional configuration, which is good because there doesn't
+    # seem to be any support for such things, at least in Squeeze.
+    my $netinst_jigdo = "$baseurl/$filebase.jigdo";
+    target_cmd_root($ho, <<END, 3600);
+        cd $didir && jigdo-lite --noask $netinst_jigdo
+END
+    store_runvar("$gho->{Guest}_netinst_jigdo", $netinst_jigdo);
+
+    return (<<END, "\"file:$didir/$filebase.iso,xvdd:cdrom,r\",");
+bootloader = "pygrub"
+bootloader_args = ["--kernel=$props->{IsoPath}/vmlinuz",
+                   "--ramdisk=$props->{IsoPath}/initrd.gz"]
+END
+}
+
 sub setup_netboot($$$)
 {
     my ($didir, $arch, $suite) = @_;
@@ -115,6 +162,16 @@ END
 
 	$extra_disk = "";
     }
+    elsif ($method eq "netinst" )
+    {
+	my $cd = $r{"$gho->{Guest}_cd"};
+
+	logm("$method $cd/$arch");
+
+	($method_cfg,$extra_disk) = setup_netinst($tmpdir, $arch, $cd);
+
+	$ps_url = preseed_create_guest($gho, '', CDROM=>1);
+    }
     else
     {
 	die "$method";
-- 
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 Mon Dec 01 12:57:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:57:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQYB-0007Mp-Gm; Mon, 01 Dec 2014 12:57: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 1XvQY9-0007Hc-CY
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:57 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	18/21-02576-4D56C745; Mon, 01 Dec 2014 12:57:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417438674!6768210!1
X-Originating-IP: [66.165.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 14442 invoked from network); 1 Dec 2014 12:57:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:57:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372258"
Received: from ukmail1.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, 1 Dec 2014 07:57:53 -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 1XvQY3-0002Qj-LQ;
	Mon, 01 Dec 2014 12:57:52 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:32 +0000
Message-ID: <1417438656-15451-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 15/19] distros: support PV guest
	install from Debian netinst media.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The netinst media are iso images containing a base Debian install and
some (image size dependent) additional tasks.

On x86 the "multiarch" iso flavour contains a Xen capable kernel for
both i386 and amd64 so use that.

This adds support for two classes of ISO, the CD sized ones which are
built nightly and the DVD sized ones which are built weekly.

The images are downloaded using jigdo which sources the majority of
the data from a local Debian mirror, for this reason I have not
worried about the fact that the i386 and amd64 tests are downloading
the same thing (adding a specific download job would require finding
up to 4GB of scratch space for each flight).

The ISOs booted using pygrub which can extract the kernel and initrd
from a ISO image. The resulting guests are also booted with pygrub
since the pv-grub-menu package is not available on the ISO images and
we have pvgrub coverage from the netboot tests.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3:
  - Indent jigdo-lite script line to improve readability
  - Wrap bootloader_args
  - Fetch URL on target, to get a timeout. Use wget since that is arranged to
    be present.
  - include bootloader in test name.
---
 Osstest/Debian.pm    |  7 +++++--
 make-distros-flight  | 23 +++++++++++++++++++++
 ts-debian-di-install | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index dc01be5..25cacd2 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -492,8 +492,6 @@ sub preseed_base ($$;@) {
     $xopts{ExtraPreseed} ||= '';
 
     my $preseed= <<END;
-d-i mirror/suite string $suite
-
 d-i debian-installer/locale string en_GB
 d-i console-keymaps-at/keymap select gb
 d-i keyboard-configuration/xkb-keymap string en_GB
@@ -558,6 +556,11 @@ d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, wget, $extra_pa
 $xopts{ExtraPreseed}
 END
 
+    # For CDROM the suite is part of the image
+    $preseed .= <<END unless $xopts{CDROM};
+d-i mirror/suite string $suite
+END
+
     # deb http://ftp.debian.org/debian/ wheezy-backports main
     $preseed .= <<END if $extra_packages =~ m#\b/$suite-backports\b#;
 d-i apt-setup/local0/repository string \\
diff --git a/make-distros-flight b/make-distros-flight
index 97df89a..e3ec8f7 100755
--- a/make-distros-flight
+++ b/make-distros-flight
@@ -85,6 +85,20 @@ test_do_one_netboot () {
       all_hostflags=$most_hostflags
 }
 
+test_do_one_netinst () {
+  # Always pygrub since no pv-grub-menu on CD
+  job_create_test                                               \
+   test-$xenarch$kern-$dom0arch-$domU-$cd-netinst-pygrub        \
+    test-debian-di xl $xenarch $dom0arch                        \
+      kernbuildjob=${bfi}build-$dom0arch-$kernbuild             \
+      debian_arch=$domU                                         \
+      debian_cd=$cd                                             \
+      debian_method=netinst                                     \
+      debian_bootloader=pygrub                                  \
+      all_hostflags=$most_hostflags
+
+}
+
 test_matrix_do_one () {
   case ${xenarch} in
   amd64) domUarches="amd64 i386";;
@@ -103,6 +117,15 @@ test_matrix_do_one () {
 
     done
 
+    for cd in current weekly ; do
+      case ${domU}_${dist} in
+      armhf_*) continue;; # No iso targets for armhf
+      *) ;;
+      esac
+
+      test_do_one_netinst
+
+    done
   done
 }
 
diff --git a/ts-debian-di-install b/ts-debian-di-install
index f3fe4cf..3878f93 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -46,6 +46,53 @@ sub prep () {
     target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
 }
 
+sub setup_netinst($$$)
+{
+    my ($didir, $arch, $cd) = @_;
+    my %arch_props = (
+	amd64 => { PathArch => "multi-arch", FileArch => "amd64-i386", IsoPath => "/install.amd/xen" },
+	i386  => { PathArch => "multi-arch", FileArch => "amd64-i386", IsoPath => "/install.386/xen" },
+	armhf => { PathArch => "armhf",      FileArch => "armhf",      IsoPath => "/install.armhf" }
+    );
+    my $props = $arch_props{$arch} or die "Unknown arch $arch";
+
+    target_install_packages($ho, qw(jigdo-file));
+
+    my $baseurl = $cd eq "current" ?
+      "http://cdimage.debian.org/debian-cd/current/$props->{PathArch}/jigdo-cd" :
+      "http://cdimage.debian.org/cdimage/weekly-builds/$props->{PathArch}/jigdo-cd";
+
+    my $filebase;
+
+    # Use the MD5SUMs file as an index
+    logm("Fetch index from $baseurl/MD5SUMS");
+    my $idx = target_cmd_output_root($ho, "wget --quiet -O - $baseurl/MD5SUMS");
+    foreach (split /\n/, $idx) {
+	m/^[0-9a-f]{32}  (debian-.*-$props->{FileArch}-netinst)\.iso$/ or next;
+	$filebase = $1;
+	last;
+    }
+
+    die unless $filebase;
+
+    logm("Downloading $baseurl/$filebase.jigdo");
+    # Jigdo seems to use /etc/apt/sources.list or something, so this
+    # just works using the already configured mirror without
+    # additional configuration, which is good because there doesn't
+    # seem to be any support for such things, at least in Squeeze.
+    my $netinst_jigdo = "$baseurl/$filebase.jigdo";
+    target_cmd_root($ho, <<END, 3600);
+        cd $didir && jigdo-lite --noask $netinst_jigdo
+END
+    store_runvar("$gho->{Guest}_netinst_jigdo", $netinst_jigdo);
+
+    return (<<END, "\"file:$didir/$filebase.iso,xvdd:cdrom,r\",");
+bootloader = "pygrub"
+bootloader_args = ["--kernel=$props->{IsoPath}/vmlinuz",
+                   "--ramdisk=$props->{IsoPath}/initrd.gz"]
+END
+}
+
 sub setup_netboot($$$)
 {
     my ($didir, $arch, $suite) = @_;
@@ -115,6 +162,16 @@ END
 
 	$extra_disk = "";
     }
+    elsif ($method eq "netinst" )
+    {
+	my $cd = $r{"$gho->{Guest}_cd"};
+
+	logm("$method $cd/$arch");
+
+	($method_cfg,$extra_disk) = setup_netinst($tmpdir, $arch, $cd);
+
+	$ps_url = preseed_create_guest($gho, '', CDROM=>1);
+    }
     else
     {
 	die "$method";
-- 
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 Mon Dec 01 12:58:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:58:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQYC-0007Ob-7m; Mon, 01 Dec 2014 12:58:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQY9-0007I9-KK
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4D/3B-15461-4D56C745; Mon, 01 Dec 2014 12:57:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417438674!12553736!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14330 invoked from network); 1 Dec 2014 12:57:56 -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;
	1 Dec 2014 12:57:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046198"
Received: from ukmail1.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, 1 Dec 2014 07:57:54 -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 1XvQY4-0002Qn-N1;
	Mon, 01 Dec 2014 12:57:53 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:33 +0000
Message-ID: <1417438656-15451-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 16/19] Test pygrub and pvgrub on the
	regular flights
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 we now have the ability to test these drop one of each of
pygrub, pvgrub-32 and pvgrub-64 into the standard flights. Omitting
the {Guest}_diver runvar causes ts-debian-di-install to use the d-i
images in the location configured via TftpDiVersion, so they are
Version Controlled along with the d-i version used for the host.

This adds three new jobs:
test-amd64-amd64-amd64-pvgrub:
    all_hostflags             arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
    arch                      amd64
    buildjob                  build-amd64
    debian_arch               amd64
    debian_bootloader         pvgrub
    debian_dist               wheezy
    debian_method             netboot
    kernbuildjob              build-amd64-pvops
    kernkind                  pvops
    toolstack                 xl
    xenbuildjob               build-amd64
test-amd64-amd64-i386-pvgrub:
    all_hostflags             arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
    arch                      amd64
    buildjob                  build-amd64
    debian_arch               i386
    debian_bootloader         pvgrub
    debian_dist               wheezy
    debian_method             netboot
    kernbuildjob              build-amd64-pvops
    kernkind                  pvops
    toolstack                 xl
    xenbuildjob               build-amd64
test-amd64-amd64-pygrub:
    all_hostflags             arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
    arch                      amd64
    buildjob                  build-amd64
    debian_arch               amd64
    debian_bootloader         pygrub
    debian_dist               wheezy
    debian_method             netboot
    kernbuildjob              build-amd64-pvops
    kernkind                  pvops
    toolstack                 xl
    xenbuildjob               build-amd64

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: added runvar details
---
 make-flight | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/make-flight b/make-flight
index b641683..3e3c513 100755
--- a/make-flight
+++ b/make-flight
@@ -277,6 +277,42 @@ do_passthrough_tests () {
   done
 }
 
+do_pygrub_tests () {
+  if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
+    return
+  fi
+
+  job_create_test test-$xenarch$kern-$dom0arch-pygrub   \
+    test-debian-di xl $xenarch $dom0arch                \
+      debian_arch=amd64                                 \
+      debian_dist=$guestsuite                           \
+      debian_method=netboot                             \
+      debian_bootloader=pygrub                          \
+      all_hostflags=$most_hostflags
+}
+
+do_pvgrub_tests () {
+  if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
+    return
+  fi
+
+  job_create_test test-$xenarch$kern-$dom0arch-amd64-pvgrub     \
+    test-debian-di xl $xenarch $dom0arch                        \
+      debian_arch=amd64                                         \
+      debian_dist=$guestsuite                                   \
+      debian_method=netboot                                     \
+      debian_bootloader=pvgrub                                  \
+      all_hostflags=$most_hostflags                             \
+
+  job_create_test test-$xenarch$kern-$dom0arch-i386-pvgrub      \
+    test-debian-di xl $xenarch $dom0arch                        \
+      debian_arch=i386                                          \
+      debian_dist=$guestsuite                                   \
+      debian_method=netboot                                     \
+      debian_bootloader=pvgrub                                  \
+      all_hostflags=$most_hostflags
+}
+
 test_matrix_do_one () {
 
   # Basic PV Linux test with xl
@@ -361,6 +397,9 @@ test_matrix_do_one () {
   fi
 
   do_passthrough_tests
+
+  do_pygrub_tests
+  do_pvgrub_tests
 }
 
 test_matrix_iterate
-- 
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 Mon Dec 01 12:58:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:58:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQYC-0007Ob-7m; Mon, 01 Dec 2014 12:58:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvQY9-0007I9-KK
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4D/3B-15461-4D56C745; Mon, 01 Dec 2014 12:57:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417438674!12553736!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14330 invoked from network); 1 Dec 2014 12:57:56 -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;
	1 Dec 2014 12:57:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046198"
Received: from ukmail1.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, 1 Dec 2014 07:57:54 -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 1XvQY4-0002Qn-N1;
	Mon, 01 Dec 2014 12:57:53 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:33 +0000
Message-ID: <1417438656-15451-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 16/19] Test pygrub and pvgrub on the
	regular flights
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 we now have the ability to test these drop one of each of
pygrub, pvgrub-32 and pvgrub-64 into the standard flights. Omitting
the {Guest}_diver runvar causes ts-debian-di-install to use the d-i
images in the location configured via TftpDiVersion, so they are
Version Controlled along with the d-i version used for the host.

This adds three new jobs:
test-amd64-amd64-amd64-pvgrub:
    all_hostflags             arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
    arch                      amd64
    buildjob                  build-amd64
    debian_arch               amd64
    debian_bootloader         pvgrub
    debian_dist               wheezy
    debian_method             netboot
    kernbuildjob              build-amd64-pvops
    kernkind                  pvops
    toolstack                 xl
    xenbuildjob               build-amd64
test-amd64-amd64-i386-pvgrub:
    all_hostflags             arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
    arch                      amd64
    buildjob                  build-amd64
    debian_arch               i386
    debian_bootloader         pvgrub
    debian_dist               wheezy
    debian_method             netboot
    kernbuildjob              build-amd64-pvops
    kernkind                  pvops
    toolstack                 xl
    xenbuildjob               build-amd64
test-amd64-amd64-pygrub:
    all_hostflags             arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
    arch                      amd64
    buildjob                  build-amd64
    debian_arch               amd64
    debian_bootloader         pygrub
    debian_dist               wheezy
    debian_method             netboot
    kernbuildjob              build-amd64-pvops
    kernkind                  pvops
    toolstack                 xl
    xenbuildjob               build-amd64

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: added runvar details
---
 make-flight | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/make-flight b/make-flight
index b641683..3e3c513 100755
--- a/make-flight
+++ b/make-flight
@@ -277,6 +277,42 @@ do_passthrough_tests () {
   done
 }
 
+do_pygrub_tests () {
+  if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
+    return
+  fi
+
+  job_create_test test-$xenarch$kern-$dom0arch-pygrub   \
+    test-debian-di xl $xenarch $dom0arch                \
+      debian_arch=amd64                                 \
+      debian_dist=$guestsuite                           \
+      debian_method=netboot                             \
+      debian_bootloader=pygrub                          \
+      all_hostflags=$most_hostflags
+}
+
+do_pvgrub_tests () {
+  if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
+    return
+  fi
+
+  job_create_test test-$xenarch$kern-$dom0arch-amd64-pvgrub     \
+    test-debian-di xl $xenarch $dom0arch                        \
+      debian_arch=amd64                                         \
+      debian_dist=$guestsuite                                   \
+      debian_method=netboot                                     \
+      debian_bootloader=pvgrub                                  \
+      all_hostflags=$most_hostflags                             \
+
+  job_create_test test-$xenarch$kern-$dom0arch-i386-pvgrub      \
+    test-debian-di xl $xenarch $dom0arch                        \
+      debian_arch=i386                                          \
+      debian_dist=$guestsuite                                   \
+      debian_method=netboot                                     \
+      debian_bootloader=pvgrub                                  \
+      all_hostflags=$most_hostflags
+}
+
 test_matrix_do_one () {
 
   # Basic PV Linux test with xl
@@ -361,6 +397,9 @@ test_matrix_do_one () {
   fi
 
   do_passthrough_tests
+
+  do_pygrub_tests
+  do_pvgrub_tests
 }
 
 test_matrix_iterate
-- 
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 Mon Dec 01 12:58:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQYC-0007Q5-TW; Mon, 01 Dec 2014 12:58: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 1XvQYB-0007Lc-Eq
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:59 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	DC/89-27623-6D56C745; Mon, 01 Dec 2014 12:57:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417438676!14847008!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26118 invoked from network); 1 Dec 2014 12:57:58 -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;
	1 Dec 2014 12:57:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372278"
Received: from ukmail1.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, 1 Dec 2014 07:57:56 -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 1XvQY6-0002Qt-Qd;
	Mon, 01 Dec 2014 12:57:55 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:35 +0000
Message-ID: <1417438656-15451-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 18/19] distros: Run a flight over the
	weekend.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Once a week should be sufficient for this test. It involves quite a
large number of jobs so schedule it to start early on Saturday so it
can run over the weekend when, in theory, things should be quieter.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 crontab | 1 +
 1 file changed, 1 insertion(+)

diff --git a/crontab b/crontab
index 5dc8675..1917ec4 100644
--- a/crontab
+++ b/crontab
@@ -6,5 +6,6 @@ MAILTO=ian.jackson@citrix.com,ian.campbell@eu.citrix.com
 18		9	* * 1,3,5	cd testing.git && BRANCHES=linux-next		./cr-for-branches branches -w "./cr-daily-branch --real"
 18		4	* * *		cd testing.git && BRANCHES='linux-linus linux-mingo-tip-master linux-3.0 libvirt rumpuserxen' ./cr-for-branches branches -w "./cr-daily-branch --real"
 6-59/15   	*	* * *		cd testing.git && EXTRA_BRANCHES='linux-linus linux-3.0 rumpuserxen libvirt' ./cr-for-branches bisects -w "./cr-try-bisect --real"
+46		7	* * 6		cd testing.git && BRANCHES=distros		./cr-for-branches branches -w "./cr-daily-branch --real"
 #8-59/5		*	* * *		cd bisects/adhoc.git &&	with-lock-ex -q data-tree-lock bash -c "./cr-try-bisect-adhoc; exit $?"
 3		4	* * *		savelog -c28 testing.git/tmp/cr-for-branches.log >/dev/null
-- 
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 Mon Dec 01 12:58:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12: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 1XvQYC-0007Q5-TW; Mon, 01 Dec 2014 12:58: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 1XvQYB-0007Lc-Eq
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:57:59 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	DC/89-27623-6D56C745; Mon, 01 Dec 2014 12:57:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417438676!14847008!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26118 invoked from network); 1 Dec 2014 12:57:58 -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;
	1 Dec 2014 12:57:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198372278"
Received: from ukmail1.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, 1 Dec 2014 07:57:56 -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 1XvQY6-0002Qt-Qd;
	Mon, 01 Dec 2014 12:57:55 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:35 +0000
Message-ID: <1417438656-15451-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 18/19] distros: Run a flight over the
	weekend.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Once a week should be sufficient for this test. It involves quite a
large number of jobs so schedule it to start early on Saturday so it
can run over the weekend when, in theory, things should be quieter.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 crontab | 1 +
 1 file changed, 1 insertion(+)

diff --git a/crontab b/crontab
index 5dc8675..1917ec4 100644
--- a/crontab
+++ b/crontab
@@ -6,5 +6,6 @@ MAILTO=ian.jackson@citrix.com,ian.campbell@eu.citrix.com
 18		9	* * 1,3,5	cd testing.git && BRANCHES=linux-next		./cr-for-branches branches -w "./cr-daily-branch --real"
 18		4	* * *		cd testing.git && BRANCHES='linux-linus linux-mingo-tip-master linux-3.0 libvirt rumpuserxen' ./cr-for-branches branches -w "./cr-daily-branch --real"
 6-59/15   	*	* * *		cd testing.git && EXTRA_BRANCHES='linux-linus linux-3.0 rumpuserxen libvirt' ./cr-for-branches bisects -w "./cr-try-bisect --real"
+46		7	* * 6		cd testing.git && BRANCHES=distros		./cr-for-branches branches -w "./cr-daily-branch --real"
 #8-59/5		*	* * *		cd bisects/adhoc.git &&	with-lock-ex -q data-tree-lock bash -c "./cr-try-bisect-adhoc; exit $?"
 3		4	* * *		savelog -c28 testing.git/tmp/cr-for-branches.log >/dev/null
-- 
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 Mon Dec 01 12:58:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:58:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQYm-0008B4-N5; Mon, 01 Dec 2014 12:58: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 1XvQYk-00088P-NE
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:58:34 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	4C/3C-29352-9F56C745; Mon, 01 Dec 2014 12:58:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417438711!10793466!1
X-Originating-IP: [66.165.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 28024 invoked from network); 1 Dec 2014 12:58:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:58:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046226"
Received: from ukmail1.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, 1 Dec 2014 07:57:57 -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 1XvQY7-0002Qw-Rx;
	Mon, 01 Dec 2014 12:57:56 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:55 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:36 +0000
Message-ID: <1417438656-15451-19-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 19/19] Debian: Handle lack of
	bootloader support in d-i on ARM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Debian doesn't currently know what bootloader to install in a Xen
guest on ARM. We install pv-grub-menu above which actually does what
we need, but the installer doesn't treat that as a "bootloader".

Most ARM platforms end up installing a u-boot boot.scr, based on a
platform whitelist. This doesn't seem appropriate for us. Grub is not
available for arm32. For arm64 we will eventually end up with in-guest
UEFI and therefore grub-efi and things will work normally. I'm not
sure what the answer is going to be for arm32.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: New
---
 Osstest/Debian.pm    | 12 ++++++++++--
 ts-debian-di-install |  6 ++++--
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 25cacd2..9bb0a59 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -579,8 +579,8 @@ END
     return $preseed;
 }
 
-sub preseed_create_guest ($$;@) {
-    my ($ho, $sfx, %xopts) = @_;
+sub preseed_create_guest ($$$;@) {
+    my ($ho, $arch, $sfx, %xopts) = @_;
 
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
@@ -627,6 +627,14 @@ d-i     grub-installer/bootdev          string /dev/xvda
 
 END
 
+    # Debian doesn't currently know what bootloader to install in a
+    # Xen guest on ARM. We install pv-grub-menu above which actually
+    # does what we need, but the installer doesn't treat that as a
+    # "bootloader".
+    $preseed_file.= (<<END) if $arch =~ /^arm/ and $suite =~ /wheezy|jessie/;
+d-i     nobootloader/confirmation_common note
+END
+
     preseed_ssh($ho, $sfx);
     preseed_hook_overlay($ho, $sfx, $c{OverlayLocal}, 'overlay-local.tar');
 
diff --git a/ts-debian-di-install b/ts-debian-di-install
index 3878f93..c93b9ec 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -158,7 +158,9 @@ END
 
 	$suite = "sid" if $suite eq "daily";
 
-	$ps_url = preseed_create_guest($gho, '', Suite=>$suite, PvMenuLst=>($bl eq "pvgrub"));
+	$ps_url = preseed_create_guest($gho, $arch, '',
+				       Suite=>$suite,
+				       PvMenuLst=>($bl eq "pvgrub"));
 
 	$extra_disk = "";
     }
@@ -170,7 +172,7 @@ END
 
 	($method_cfg,$extra_disk) = setup_netinst($tmpdir, $arch, $cd);
 
-	$ps_url = preseed_create_guest($gho, '', CDROM=>1);
+	$ps_url = preseed_create_guest($gho, $arch, '', CDROM=>1);
     }
     else
     {
-- 
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 Mon Dec 01 12:58:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 12:58:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQYm-0008B4-N5; Mon, 01 Dec 2014 12:58: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 1XvQYk-00088P-NE
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 12:58:34 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	4C/3C-29352-9F56C745; Mon, 01 Dec 2014 12:58:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417438711!10793466!1
X-Originating-IP: [66.165.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 28024 invoked from network); 1 Dec 2014 12:58:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 12:58:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198046226"
Received: from ukmail1.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, 1 Dec 2014 07:57:57 -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 1XvQY7-0002Qw-Rx;
	Mon, 01 Dec 2014 12:57:56 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 01 Dec
	2014 12:57:55 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 12:57:36 +0000
Message-ID: <1417438656-15451-19-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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 19/19] Debian: Handle lack of
	bootloader support in d-i on ARM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Debian doesn't currently know what bootloader to install in a Xen
guest on ARM. We install pv-grub-menu above which actually does what
we need, but the installer doesn't treat that as a "bootloader".

Most ARM platforms end up installing a u-boot boot.scr, based on a
platform whitelist. This doesn't seem appropriate for us. Grub is not
available for arm32. For arm64 we will eventually end up with in-guest
UEFI and therefore grub-efi and things will work normally. I'm not
sure what the answer is going to be for arm32.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: New
---
 Osstest/Debian.pm    | 12 ++++++++++--
 ts-debian-di-install |  6 ++++--
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 25cacd2..9bb0a59 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -579,8 +579,8 @@ END
     return $preseed;
 }
 
-sub preseed_create_guest ($$;@) {
-    my ($ho, $sfx, %xopts) = @_;
+sub preseed_create_guest ($$$;@) {
+    my ($ho, $arch, $sfx, %xopts) = @_;
 
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
@@ -627,6 +627,14 @@ d-i     grub-installer/bootdev          string /dev/xvda
 
 END
 
+    # Debian doesn't currently know what bootloader to install in a
+    # Xen guest on ARM. We install pv-grub-menu above which actually
+    # does what we need, but the installer doesn't treat that as a
+    # "bootloader".
+    $preseed_file.= (<<END) if $arch =~ /^arm/ and $suite =~ /wheezy|jessie/;
+d-i     nobootloader/confirmation_common note
+END
+
     preseed_ssh($ho, $sfx);
     preseed_hook_overlay($ho, $sfx, $c{OverlayLocal}, 'overlay-local.tar');
 
diff --git a/ts-debian-di-install b/ts-debian-di-install
index 3878f93..c93b9ec 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -158,7 +158,9 @@ END
 
 	$suite = "sid" if $suite eq "daily";
 
-	$ps_url = preseed_create_guest($gho, '', Suite=>$suite, PvMenuLst=>($bl eq "pvgrub"));
+	$ps_url = preseed_create_guest($gho, $arch, '',
+				       Suite=>$suite,
+				       PvMenuLst=>($bl eq "pvgrub"));
 
 	$extra_disk = "";
     }
@@ -170,7 +172,7 @@ END
 
 	($method_cfg,$extra_disk) = setup_netinst($tmpdir, $arch, $cd);
 
-	$ps_url = preseed_create_guest($gho, '', CDROM=>1);
+	$ps_url = preseed_create_guest($gho, $arch, '', CDROM=>1);
     }
     else
     {
-- 
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 Mon Dec 01 13:01:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13: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 1XvQbW-00013q-7C; Mon, 01 Dec 2014 13:01:26 +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 1XvQbV-00013V-7H
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:01:25 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	62/D3-02696-4A66C745; Mon, 01 Dec 2014 13:01:24 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417438879!8856580!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3028 invoked from network); 1 Dec 2014 13:01:21 -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; 1 Dec 2014 13:01: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 sB1D1HeG003370
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 1 Dec 2014 08:01:17 -0500
Received: from vitty.brq.redhat.com (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 sB1D1EbC021862; Mon, 1 Dec 2014 08:01:15 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon,  1 Dec 2014 14:01:13 +0100
Message-Id: <1417438873-2082-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
References: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
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>,
	Laszlo Ersek <lersek@redhat.com>
Subject: [Xen-devel] [PATCH RESEND] 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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>
Reviewed-by: Laszlo Ersek <lersek@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;
 		}
 
-- 
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 Dec 01 13:01:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13: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 1XvQbW-00013q-7C; Mon, 01 Dec 2014 13:01:26 +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 1XvQbV-00013V-7H
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:01:25 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	62/D3-02696-4A66C745; Mon, 01 Dec 2014 13:01:24 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417438879!8856580!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3028 invoked from network); 1 Dec 2014 13:01:21 -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; 1 Dec 2014 13:01: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 sB1D1HeG003370
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 1 Dec 2014 08:01:17 -0500
Received: from vitty.brq.redhat.com (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 sB1D1EbC021862; Mon, 1 Dec 2014 08:01:15 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon,  1 Dec 2014 14:01:13 +0100
Message-Id: <1417438873-2082-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
References: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
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>,
	Laszlo Ersek <lersek@redhat.com>
Subject: [Xen-devel] [PATCH RESEND] 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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>
Reviewed-by: Laszlo Ersek <lersek@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;
 		}
 
-- 
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 Dec 01 13:11:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:11:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQlG-0001XA-Md; Mon, 01 Dec 2014 13:11: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 1XvQlF-0001X0-Vo
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:11:30 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	32/8A-02698-1096C745; Mon, 01 Dec 2014 13:11:29 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417439486!12204080!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 10703 invoked from network); 1 Dec 2014 13:11:27 -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; 1 Dec 2014 13:11:27 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 52652AD71;
	Mon,  1 Dec 2014 13:11:26 +0000 (UTC)
Message-ID: <547C68FD.60000@suse.com>
Date: Mon, 01 Dec 2014 14:11: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: Jan Beulich <JBeulich@suse.com>, 
 David Vrabel <david.vrabel@citrix.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>	
	<1417426153-12893-2-git-send-email-jgross@suse.com>	
	<547C4DD6020000780004BA83@mail.emea.novell.com>	
	<547C4ECB.7070702@citrix.com> <547C5F31020000780004BB1F@suse.com>
In-Reply-To: <547C5F31020000780004BB1F@suse.com>
Content-Length: 4260
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 V2] 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: 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

T24gMTIvMDEvMjAxNCAxMjoyOSBQTSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4gT24gMDEuMTIu
MTQgYXQgMTI6MTksIDxkYXZpZC52cmFiZWxAY2l0cml4LmNvbT4gd3JvdGU6Cj4+IE9uIDAxLzEy
LzE0IDEwOjE1LCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+IE9uIDAxLjEyLjE0IGF0IDEwOjI5
LCA8Skdyb3NzQHN1c2UuY29tPiB3cm90ZToKPj4+PiBUaGUgeDg2IHN0cnVjdCBhcmNoX3NoYXJl
ZF9pbmZvIGZpZWxkIHBmbl90b19tZm5fZnJhbWVfbGlzdF9saXN0Cj4+Pj4gY3VycmVudGx5IGNv
bnRhaW5zIHRoZSBtZm4gb2YgdGhlIHRvcCBsZXZlbCBwYWdlIGZyYW1lIG9mIHRoZSAzIGxldmVs
Cj4+Pj4gcDJtIHRyZWUsIHdoaWNoIGlzIHVzZWQgYnkgdGhlIFhlbiB0b29scyBkdXJpbmcgc2F2
aW5nIGFuZCByZXN0b3JpbmcKPj4+PiAoYW5kIGxpdmUgbWlncmF0aW9uKSBvZiBwdiBkb21haW5z
IGFuZCBmb3IgY3Jhc2ggZHVtcCBhbmFseXNpcy4gV2l0aAo+Pj4+IHRocmVlIGxldmVscyBvZiB0
aGUgcDJtIHRyZWUgaXQgaXMgcG9zc2libGUgdG8gc3VwcG9ydCB1cCB0byA1MTIgR0Igb2YKPj4+
PiBSQU0gZm9yIGEgNjQgYml0IHB2IGRvbWFpbi4KPj4+Pgo+Pj4+IEEgMzIgYml0IHB2IGRvbWFp
biBjYW4gc3VwcG9ydCBtb3JlLCBhcyBlYWNoIG1lbW9yeSBwYWdlIGNhbiBob2xkIDEwMjQKPj4+
PiBpbnN0ZWFkIG9mIDUxMiBlbnRyaWVzLCBsZWFkaW5nIHRvIGEgbGltaXQgb2YgNCBUQi4KPj4+
Pgo+Pj4+IFRvIGJlIGFibGUgdG8gc3VwcG9ydCBtb3JlIFJBTSBvbiB4ODYtNjQgc3dpdGNoIHRv
IGEgdmlydHVhbCBtYXBwZWQKPj4+PiBwMm0gbGlzdC4KPj4+Pgo+Pj4+IFRoaXMgcGF0Y2ggZXhw
YW5kcyBzdHJ1Y3QgYXJjaF9zaGFyZWRfaW5mbyB3aXRoIGEgbmV3IHAybSBsaXN0IHZpcnR1YWwK
Pj4+PiBhZGRyZXNzLCB0aGUgcm9vdCBvZiB0aGUgcGFnZSB0YWJsZSByb290IGFuZCBhIHAybSBn
ZW5lcmF0aW9uIGNvdW50Lgo+Pj4+IFRoZSBuZXcgaW5mb3JtYXRpb24gaXMgaW5kaWNhdGVkIGJ5
IHRoZSBkb21haW4gdG8gYmUgdmFsaWQgYnkgc3RvcmluZwo+Pj4+IH4wVUwgaW50byBwZm5fdG9f
bWZuX2ZyYW1lX2xpc3RfbGlzdC4gVGhlIGh5cGVydmlzb3IgaW5kaWNhdGVzCj4+Pj4gdXNhYmls
aXR5IG9mIHRoaXMgZmVhdHVyZSBieSBhIG5ldyBmbGFnIFhFTkZFQVRfdmlydHVhbF9wMm0uCj4+
Pj4KPj4+PiBSaWdodCBub3cgWEVORkVBVF92aXJ0dWFsX3AybSB3aWxsIG5vdCBiZSBzZXQuIFRo
aXMgd2lsbCBjaGFuZ2Ugd2hlbgo+Pj4+IHRoZSBYZW4gdG9vbHMgc3VwcG9ydCB0aGUgdmlydHVh
bCBtYXBwZWQgcDJtIGxpc3QuCj4+Pgo+Pj4gVGhpcyBzZWVtcyB3cm9uZzogWEVORkVBVF8qIG9u
bHkgcmVmbGVjdCBoeXBlcnZpc29yIGNhcGFiaWxpdGllcy4KPj4+IEkuZS4gdGhlIGF2YWlsYWJp
bGl0eSBvZiB0aGUgbmV3IGZ1bmN0aW9uYWxpdHkgbWF5IG5lZWQgdG8gYmUKPj4+IGFkdmVydGlz
ZWQgYW5vdGhlciB3YXkgLSB4ZW5zdG9yZSBwZXJoYXBzPwo+Pgo+PiBYZW5zdG9yZSBkb2Vzbid0
IHdvcmsgZm9yIGRvbTAuCj4+Cj4+IFNob3VsZG4ndCB0aGlzIGJlIHNvbWV0aGluZyB0aGUgZ3Vl
c3Qga2VybmVsIHJlcG9ydHMgdXNpbmcgYSBFTEYgbm90ZSBiaXQ/Cj4+Cj4+IFdoZW4gYnVpbGRp
bmcgYSBkb21haW4gKGVpdGhlciBpbiBYZW4gZm9yIGRvbTAgb3IgaW4gdGhlIHRvb2xzKSwgdGhl
Cj4+IGJ1aWxkZXIgbWF5IHByb3ZpZGUgYSBsaW5lYXIgcDJtIGlmZiBzdXBwb3J0ZWQgYnkgdGhl
IGd1ZXN0IGtlcm5lbCBhbmQKPj4gdGhlbiAoYW5kIG9ubHkgdGhlbikgY2FuIGl0IHByb3ZpZGUg
YSBndWVzdCB3aXRoID4gNTEyIEdpQi4KPgo+IFllcywgc3VyZWx5IHRoaXMgZmxhZyBjb3VsZCBh
Y3QgYXMgYSBrZXJuZWwgY2FwYWJpbGl0eSBpbmRpY2F0b3IgKHZpYQo+IHRoZSBYRU5fRUxGTk9U
RV9TVVBQT1JURURfRkVBVFVSRVMgbm90ZSksIGxpa2UgZS5nLgo+IFhFTkZFQVRfZG9tMCBhbHJl
YWR5IGRvZXMuIErDvHJnZW4ncyBmaW5hbCBzdGF0ZW1lbnQsIGhvd2V2ZXIsCj4gc3VnZ2VzdGVk
IHRvIG1lIHRoYXQgdGhpcyBpcyBtZWFudCB0byBiZSBvbmx5IGNvbnN1bWVkIGJ5IGtlcm5lbHMu
CgpZZXMuIFRoZSBwMm0gbGlzdCBidWlsdCBieSB0aGUgZG9tYWluIGJ1aWxkZXIgaXMgYWxyZWFk
eSBsaW5lYXIuIEl0IG1heQpqdXN0IGJlIHRvIHNtYWxsIHRvIGhvbGQgYWxsIGVudHJpZXMgcmVx
dWlyZWQgZS5nLiBmb3IgRG9tMC4KCkl0J3MgWGVuLXRvb2xzIGFuZCBrZHVtcCB3aGljaCBoYXZl
IHRvIGRlYWwgd2l0aCB0aGUgbGluZWFyIHAybSBsaXN0LgpTbyB0aGUgZ3Vlc3Qga2VybmVsIGhh
cyB0byBiZSB0b2xkIGlmIGl0IGlzIGFsbG93ZWQgdG8gcHJlc2VudCB0aGUKbGluZWFyIGxpc3Qg
aW5zdGVhZCBvZiB0aGUgMy1sZXZlbCB0cmVlIGF0IHBmbl90b19tZm5fZnJhbWVfbGlzdF9saXN0
LgoKQXMgdGhpcyBpcyB0cnVlIGZvciBEb20wIGFzIHdlbGwsIHRoaXMgaW5mb3JtYXRpb24gbXVz
dCBiZSBnaXZlbiBieSB0aGUKaHlwZXJ2aXNvci4KCkknbSBhd2FyZSB0aGF0IFhFTkZFQVRfKiBp
cyBvbmx5IHVzZWQgZm9yIGh5cGVydmlzb3IgY2FwYWJpbGl0aWVzIHVwIHRvCm5vdy4gQXMgdGhl
IFhlbiB0b29scyBhcmUgdGlnaHRseSBjb3VwbGVkIHRvIHRoZSBoeXBlcnZpc29yIEkgZG9uJ3Qg
c2VlCndoeSB0aGUgZmVhdHVyZXMgY2FuJ3QgZXhwcmVzcyB0aGUgY2FwYWJpbGl0eSBvZiB0aGUg
Y29tcGxldGUgWGVuCmluc3RhbGxhdGlvbiBpbnN0ZWFkLiBXb3VsZCB5b3UgcHJlZmVyIGludHJv
ZHVjaW5nIGFub3RoZXIgbGVhZiBmb3IKdGhhdCBwdXJwb3NlIChzdWJtYXAuaWR4ID09IDEpID8K
Cj4gT3RvaCB0aGUgUDJNIHByb3ZpZGVkIGJ5IGJvdGggRG9tMCBhbmQgRG9tVSBidWlsZGVycyBo
YXZlIGFsd2F5cwo+IGJlZW4gbGluZWFyIGFueXdheTsgaXQncyB0aGUgcHYtb3BzIGtlcm5lbCB0
aGF0IGNvbnN0cnVjdHMgYSB0cmVlIGFzCj4gcmVwbGFjZW1lbnQuCgpDb3JyZWN0LgoKCkp1ZXJn
ZW4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:11:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:11:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQl5-0001WR-AS; Mon, 01 Dec 2014 13:11:19 +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 1XvQl3-0001WM-7T
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 13:11:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	69/24-09842-4F86C745; Mon, 01 Dec 2014 13:11:16 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417439474!5274983!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 32322 invoked from network); 1 Dec 2014 13:11:15 -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;
	1 Dec 2014 13:11:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198051678"
Message-ID: <547C68F0.5080004@citrix.com>
Date: Mon, 1 Dec 2014 13:11:12 +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: Zhuan Chen <zhuanchen@gmail.com>, <xen-devel@lists.xen.org>, Daniel Kiper
	<daniel.kiper@oracle.com>
References: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
In-Reply-To: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
X-DLP: MIA1
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.

You may want to look at using another bootloader (such as grub 2) to
chainload Xen.

Daniel Kiper has the necessary patches to Xen to make this work
(although I've only tried it with 64-bit grub 2).

David


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:11:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:11:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQlG-0001XA-Md; Mon, 01 Dec 2014 13:11: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 1XvQlF-0001X0-Vo
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:11:30 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	32/8A-02698-1096C745; Mon, 01 Dec 2014 13:11:29 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417439486!12204080!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 10703 invoked from network); 1 Dec 2014 13:11:27 -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; 1 Dec 2014 13:11:27 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 52652AD71;
	Mon,  1 Dec 2014 13:11:26 +0000 (UTC)
Message-ID: <547C68FD.60000@suse.com>
Date: Mon, 01 Dec 2014 14:11: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: Jan Beulich <JBeulich@suse.com>, 
 David Vrabel <david.vrabel@citrix.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>	
	<1417426153-12893-2-git-send-email-jgross@suse.com>	
	<547C4DD6020000780004BA83@mail.emea.novell.com>	
	<547C4ECB.7070702@citrix.com> <547C5F31020000780004BB1F@suse.com>
In-Reply-To: <547C5F31020000780004BB1F@suse.com>
Content-Length: 4260
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 V2] 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: 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

T24gMTIvMDEvMjAxNCAxMjoyOSBQTSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4gT24gMDEuMTIu
MTQgYXQgMTI6MTksIDxkYXZpZC52cmFiZWxAY2l0cml4LmNvbT4gd3JvdGU6Cj4+IE9uIDAxLzEy
LzE0IDEwOjE1LCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+IE9uIDAxLjEyLjE0IGF0IDEwOjI5
LCA8Skdyb3NzQHN1c2UuY29tPiB3cm90ZToKPj4+PiBUaGUgeDg2IHN0cnVjdCBhcmNoX3NoYXJl
ZF9pbmZvIGZpZWxkIHBmbl90b19tZm5fZnJhbWVfbGlzdF9saXN0Cj4+Pj4gY3VycmVudGx5IGNv
bnRhaW5zIHRoZSBtZm4gb2YgdGhlIHRvcCBsZXZlbCBwYWdlIGZyYW1lIG9mIHRoZSAzIGxldmVs
Cj4+Pj4gcDJtIHRyZWUsIHdoaWNoIGlzIHVzZWQgYnkgdGhlIFhlbiB0b29scyBkdXJpbmcgc2F2
aW5nIGFuZCByZXN0b3JpbmcKPj4+PiAoYW5kIGxpdmUgbWlncmF0aW9uKSBvZiBwdiBkb21haW5z
IGFuZCBmb3IgY3Jhc2ggZHVtcCBhbmFseXNpcy4gV2l0aAo+Pj4+IHRocmVlIGxldmVscyBvZiB0
aGUgcDJtIHRyZWUgaXQgaXMgcG9zc2libGUgdG8gc3VwcG9ydCB1cCB0byA1MTIgR0Igb2YKPj4+
PiBSQU0gZm9yIGEgNjQgYml0IHB2IGRvbWFpbi4KPj4+Pgo+Pj4+IEEgMzIgYml0IHB2IGRvbWFp
biBjYW4gc3VwcG9ydCBtb3JlLCBhcyBlYWNoIG1lbW9yeSBwYWdlIGNhbiBob2xkIDEwMjQKPj4+
PiBpbnN0ZWFkIG9mIDUxMiBlbnRyaWVzLCBsZWFkaW5nIHRvIGEgbGltaXQgb2YgNCBUQi4KPj4+
Pgo+Pj4+IFRvIGJlIGFibGUgdG8gc3VwcG9ydCBtb3JlIFJBTSBvbiB4ODYtNjQgc3dpdGNoIHRv
IGEgdmlydHVhbCBtYXBwZWQKPj4+PiBwMm0gbGlzdC4KPj4+Pgo+Pj4+IFRoaXMgcGF0Y2ggZXhw
YW5kcyBzdHJ1Y3QgYXJjaF9zaGFyZWRfaW5mbyB3aXRoIGEgbmV3IHAybSBsaXN0IHZpcnR1YWwK
Pj4+PiBhZGRyZXNzLCB0aGUgcm9vdCBvZiB0aGUgcGFnZSB0YWJsZSByb290IGFuZCBhIHAybSBn
ZW5lcmF0aW9uIGNvdW50Lgo+Pj4+IFRoZSBuZXcgaW5mb3JtYXRpb24gaXMgaW5kaWNhdGVkIGJ5
IHRoZSBkb21haW4gdG8gYmUgdmFsaWQgYnkgc3RvcmluZwo+Pj4+IH4wVUwgaW50byBwZm5fdG9f
bWZuX2ZyYW1lX2xpc3RfbGlzdC4gVGhlIGh5cGVydmlzb3IgaW5kaWNhdGVzCj4+Pj4gdXNhYmls
aXR5IG9mIHRoaXMgZmVhdHVyZSBieSBhIG5ldyBmbGFnIFhFTkZFQVRfdmlydHVhbF9wMm0uCj4+
Pj4KPj4+PiBSaWdodCBub3cgWEVORkVBVF92aXJ0dWFsX3AybSB3aWxsIG5vdCBiZSBzZXQuIFRo
aXMgd2lsbCBjaGFuZ2Ugd2hlbgo+Pj4+IHRoZSBYZW4gdG9vbHMgc3VwcG9ydCB0aGUgdmlydHVh
bCBtYXBwZWQgcDJtIGxpc3QuCj4+Pgo+Pj4gVGhpcyBzZWVtcyB3cm9uZzogWEVORkVBVF8qIG9u
bHkgcmVmbGVjdCBoeXBlcnZpc29yIGNhcGFiaWxpdGllcy4KPj4+IEkuZS4gdGhlIGF2YWlsYWJp
bGl0eSBvZiB0aGUgbmV3IGZ1bmN0aW9uYWxpdHkgbWF5IG5lZWQgdG8gYmUKPj4+IGFkdmVydGlz
ZWQgYW5vdGhlciB3YXkgLSB4ZW5zdG9yZSBwZXJoYXBzPwo+Pgo+PiBYZW5zdG9yZSBkb2Vzbid0
IHdvcmsgZm9yIGRvbTAuCj4+Cj4+IFNob3VsZG4ndCB0aGlzIGJlIHNvbWV0aGluZyB0aGUgZ3Vl
c3Qga2VybmVsIHJlcG9ydHMgdXNpbmcgYSBFTEYgbm90ZSBiaXQ/Cj4+Cj4+IFdoZW4gYnVpbGRp
bmcgYSBkb21haW4gKGVpdGhlciBpbiBYZW4gZm9yIGRvbTAgb3IgaW4gdGhlIHRvb2xzKSwgdGhl
Cj4+IGJ1aWxkZXIgbWF5IHByb3ZpZGUgYSBsaW5lYXIgcDJtIGlmZiBzdXBwb3J0ZWQgYnkgdGhl
IGd1ZXN0IGtlcm5lbCBhbmQKPj4gdGhlbiAoYW5kIG9ubHkgdGhlbikgY2FuIGl0IHByb3ZpZGUg
YSBndWVzdCB3aXRoID4gNTEyIEdpQi4KPgo+IFllcywgc3VyZWx5IHRoaXMgZmxhZyBjb3VsZCBh
Y3QgYXMgYSBrZXJuZWwgY2FwYWJpbGl0eSBpbmRpY2F0b3IgKHZpYQo+IHRoZSBYRU5fRUxGTk9U
RV9TVVBQT1JURURfRkVBVFVSRVMgbm90ZSksIGxpa2UgZS5nLgo+IFhFTkZFQVRfZG9tMCBhbHJl
YWR5IGRvZXMuIErDvHJnZW4ncyBmaW5hbCBzdGF0ZW1lbnQsIGhvd2V2ZXIsCj4gc3VnZ2VzdGVk
IHRvIG1lIHRoYXQgdGhpcyBpcyBtZWFudCB0byBiZSBvbmx5IGNvbnN1bWVkIGJ5IGtlcm5lbHMu
CgpZZXMuIFRoZSBwMm0gbGlzdCBidWlsdCBieSB0aGUgZG9tYWluIGJ1aWxkZXIgaXMgYWxyZWFk
eSBsaW5lYXIuIEl0IG1heQpqdXN0IGJlIHRvIHNtYWxsIHRvIGhvbGQgYWxsIGVudHJpZXMgcmVx
dWlyZWQgZS5nLiBmb3IgRG9tMC4KCkl0J3MgWGVuLXRvb2xzIGFuZCBrZHVtcCB3aGljaCBoYXZl
IHRvIGRlYWwgd2l0aCB0aGUgbGluZWFyIHAybSBsaXN0LgpTbyB0aGUgZ3Vlc3Qga2VybmVsIGhh
cyB0byBiZSB0b2xkIGlmIGl0IGlzIGFsbG93ZWQgdG8gcHJlc2VudCB0aGUKbGluZWFyIGxpc3Qg
aW5zdGVhZCBvZiB0aGUgMy1sZXZlbCB0cmVlIGF0IHBmbl90b19tZm5fZnJhbWVfbGlzdF9saXN0
LgoKQXMgdGhpcyBpcyB0cnVlIGZvciBEb20wIGFzIHdlbGwsIHRoaXMgaW5mb3JtYXRpb24gbXVz
dCBiZSBnaXZlbiBieSB0aGUKaHlwZXJ2aXNvci4KCkknbSBhd2FyZSB0aGF0IFhFTkZFQVRfKiBp
cyBvbmx5IHVzZWQgZm9yIGh5cGVydmlzb3IgY2FwYWJpbGl0aWVzIHVwIHRvCm5vdy4gQXMgdGhl
IFhlbiB0b29scyBhcmUgdGlnaHRseSBjb3VwbGVkIHRvIHRoZSBoeXBlcnZpc29yIEkgZG9uJ3Qg
c2VlCndoeSB0aGUgZmVhdHVyZXMgY2FuJ3QgZXhwcmVzcyB0aGUgY2FwYWJpbGl0eSBvZiB0aGUg
Y29tcGxldGUgWGVuCmluc3RhbGxhdGlvbiBpbnN0ZWFkLiBXb3VsZCB5b3UgcHJlZmVyIGludHJv
ZHVjaW5nIGFub3RoZXIgbGVhZiBmb3IKdGhhdCBwdXJwb3NlIChzdWJtYXAuaWR4ID09IDEpID8K
Cj4gT3RvaCB0aGUgUDJNIHByb3ZpZGVkIGJ5IGJvdGggRG9tMCBhbmQgRG9tVSBidWlsZGVycyBo
YXZlIGFsd2F5cwo+IGJlZW4gbGluZWFyIGFueXdheTsgaXQncyB0aGUgcHYtb3BzIGtlcm5lbCB0
aGF0IGNvbnN0cnVjdHMgYSB0cmVlIGFzCj4gcmVwbGFjZW1lbnQuCgpDb3JyZWN0LgoKCkp1ZXJn
ZW4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:11:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:11:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQl5-0001WR-AS; Mon, 01 Dec 2014 13:11:19 +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 1XvQl3-0001WM-7T
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 13:11:17 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	69/24-09842-4F86C745; Mon, 01 Dec 2014 13:11:16 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417439474!5274983!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 32322 invoked from network); 1 Dec 2014 13:11:15 -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;
	1 Dec 2014 13:11:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198051678"
Message-ID: <547C68F0.5080004@citrix.com>
Date: Mon, 1 Dec 2014 13:11:12 +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: Zhuan Chen <zhuanchen@gmail.com>, <xen-devel@lists.xen.org>, Daniel Kiper
	<daniel.kiper@oracle.com>
References: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
In-Reply-To: <CAGG8cjVOoYjBmmjjBUHVxjO0autOWE_GoHamuaC+=6rQVBs5kQ@mail.gmail.com>
X-DLP: MIA1
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.

You may want to look at using another bootloader (such as grub 2) to
chainload Xen.

Daniel Kiper has the necessary patches to Xen to make this work
(although I've only tried it with 64-bit grub 2).

David


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:24:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:24:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQxg-0001wI-0K; Mon, 01 Dec 2014 13:24: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 1XvQxf-0001wD-4k
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 13:24:19 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	5C/71-07724-20C6C745; Mon, 01 Dec 2014 13:24:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417440256!14987135!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24642 invoked from network); 1 Dec 2014 13:24:17 -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;
	1 Dec 2014 13:24:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198056034"
Message-ID: <1417440246.29138.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 13:24:06 +0000
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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/19] add distro domU testing
 flight
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-01 at 12:56 +0000, Ian Campbell wrote:
> The exception to that good news is that sg-report-flight
> --that-flight=NNN MMM doesn't seem to be considering failures in MMM
> regressions vs NNN. e.g. test-amd64-i386-i386-daily-netboot-pvgrub
> should appear as a regression from 31961 to 31964 but isn't. I'm going
> to have a poke around that.

This turned out to be as easy as passing --blessings=play to
sg-report-flight (the default is ["real", "real-bisect"]), which
produced the output below (previously everything was "Tests which did
not succeed, but are not blocking")

I have a feeling this is deliberate and that only real+bisects are
supposed to be considered here on purpose.

If not then I think the right answer is just to add this to sgr_args in
the relevant case:
        --blessings=${DAILY_BRANCH_TESTED_BLESSING:-$OSSTEST_BLESSING}

Ian.

------

31964: regressions - FAIL

flight 31964 distros play [play]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31964/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-i386-current-netinst-pygrub  5 xen-boot   fail REGR. vs. 31961
 test-amd64-i386-i386-daily-netboot-pvgrub 7 debian-di-install fail REGR. vs. 31961
 test-amd64-i386-i386-jessie-netboot-pvgrub  5 xen-boot    fail REGR. vs. 31961

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-i386-weekly-netinst-pygrub 7 debian-di-install fail like 31961

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-i386-sid-netboot-pvgrub  7 debian-di-install  fail never pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub 7 debian-di-install fail never pass
 test-armhf-armhf-armhf-sid-netboot-pygrub  7 debian-di-install fail never pass
 test-amd64-i386-i386-sid-netboot-pygrub  7 debian-di-install   fail never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 7 debian-di-install fail never pass
 test-armhf-armhf-armhf-daily-netboot-pygrub 7 debian-di-install fail never pass
 test-amd64-amd64-i386-jessie-netboot-pygrub 7 debian-di-install fail never pass
 test-amd64-amd64-amd64-sid-netboot-pygrub  7 debian-di-install fail never pass
 test-amd64-i386-amd64-jessie-netboot-pygrub 7 debian-di-install fail never pass
 test-amd64-i386-amd64-sid-netboot-pygrub  7 debian-di-install  fail never pass

baseline version:
 flight               31961

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-amd64-daily-netboot-pvgrub                  pass    
 test-amd64-i386-i386-daily-netboot-pvgrub                    fail    
 test-amd64-amd64-amd64-jessie-netboot-pvgrub                 fail    
 test-amd64-i386-i386-jessie-netboot-pvgrub                   fail    
 test-amd64-amd64-i386-sid-netboot-pvgrub                     fail    
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub                 pass    
 test-amd64-i386-i386-wheezy-netboot-pvgrub                   pass    
 test-amd64-i386-amd64-daily-netboot-pygrub                   pass    
 test-armhf-armhf-armhf-daily-netboot-pygrub                  fail    
 test-amd64-amd64-i386-daily-netboot-pygrub                   pass    
 test-amd64-i386-amd64-jessie-netboot-pygrub                  fail    
 test-armhf-armhf-armhf-jessie-netboot-pygrub                 fail    
 test-amd64-amd64-i386-jessie-netboot-pygrub                  fail    
 test-amd64-amd64-amd64-sid-netboot-pygrub                    fail    
 test-amd64-i386-amd64-sid-netboot-pygrub                     fail    
 test-armhf-armhf-armhf-sid-netboot-pygrub                    fail    
 test-amd64-i386-i386-sid-netboot-pygrub                      fail    
 test-amd64-amd64-amd64-squeeze-netboot-pygrub                pass    
 test-amd64-i386-amd64-squeeze-netboot-pygrub                 pass    
 test-amd64-amd64-i386-squeeze-netboot-pygrub                 pass    
 test-amd64-i386-i386-squeeze-netboot-pygrub                  pass    
 test-amd64-i386-amd64-wheezy-netboot-pygrub                  pass    
 test-amd64-amd64-i386-wheezy-netboot-pygrub                  pass    
 test-amd64-amd64-amd64-current-netinst-pygrub                pass    
 test-amd64-i386-amd64-current-netinst-pygrub                 pass    
 test-amd64-amd64-i386-current-netinst-pygrub                 pass    
 test-amd64-i386-i386-current-netinst-pygrub                  fail    
 test-amd64-amd64-amd64-weekly-netinst-pygrub                 pass    
 test-amd64-i386-amd64-weekly-netinst-pygrub                  pass    
 test-amd64-amd64-i386-weekly-netinst-pygrub                  pass    
 test-amd64-i386-i386-weekly-netinst-pygrub                   fail    


------------------------------------------------------------
sg-report-flight on kazak.uk.xensource.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Dec 01 13:24:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:24:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvQxg-0001wI-0K; Mon, 01 Dec 2014 13:24: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 1XvQxf-0001wD-4k
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 13:24:19 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	5C/71-07724-20C6C745; Mon, 01 Dec 2014 13:24:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417440256!14987135!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24642 invoked from network); 1 Dec 2014 13:24:17 -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;
	1 Dec 2014 13:24:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198056034"
Message-ID: <1417440246.29138.26.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 1 Dec 2014 13:24:06 +0000
In-Reply-To: <1417438571.29138.22.camel@citrix.com>
References: <1417438571.29138.22.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/19] add distro domU testing
 flight
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-01 at 12:56 +0000, Ian Campbell wrote:
> The exception to that good news is that sg-report-flight
> --that-flight=NNN MMM doesn't seem to be considering failures in MMM
> regressions vs NNN. e.g. test-amd64-i386-i386-daily-netboot-pvgrub
> should appear as a regression from 31961 to 31964 but isn't. I'm going
> to have a poke around that.

This turned out to be as easy as passing --blessings=play to
sg-report-flight (the default is ["real", "real-bisect"]), which
produced the output below (previously everything was "Tests which did
not succeed, but are not blocking")

I have a feeling this is deliberate and that only real+bisects are
supposed to be considered here on purpose.

If not then I think the right answer is just to add this to sgr_args in
the relevant case:
        --blessings=${DAILY_BRANCH_TESTED_BLESSING:-$OSSTEST_BLESSING}

Ian.

------

31964: regressions - FAIL

flight 31964 distros play [play]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31964/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-i386-current-netinst-pygrub  5 xen-boot   fail REGR. vs. 31961
 test-amd64-i386-i386-daily-netboot-pvgrub 7 debian-di-install fail REGR. vs. 31961
 test-amd64-i386-i386-jessie-netboot-pvgrub  5 xen-boot    fail REGR. vs. 31961

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-i386-weekly-netinst-pygrub 7 debian-di-install fail like 31961

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-i386-sid-netboot-pvgrub  7 debian-di-install  fail never pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub 7 debian-di-install fail never pass
 test-armhf-armhf-armhf-sid-netboot-pygrub  7 debian-di-install fail never pass
 test-amd64-i386-i386-sid-netboot-pygrub  7 debian-di-install   fail never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 7 debian-di-install fail never pass
 test-armhf-armhf-armhf-daily-netboot-pygrub 7 debian-di-install fail never pass
 test-amd64-amd64-i386-jessie-netboot-pygrub 7 debian-di-install fail never pass
 test-amd64-amd64-amd64-sid-netboot-pygrub  7 debian-di-install fail never pass
 test-amd64-i386-amd64-jessie-netboot-pygrub 7 debian-di-install fail never pass
 test-amd64-i386-amd64-sid-netboot-pygrub  7 debian-di-install  fail never pass

baseline version:
 flight               31961

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-amd64-daily-netboot-pvgrub                  pass    
 test-amd64-i386-i386-daily-netboot-pvgrub                    fail    
 test-amd64-amd64-amd64-jessie-netboot-pvgrub                 fail    
 test-amd64-i386-i386-jessie-netboot-pvgrub                   fail    
 test-amd64-amd64-i386-sid-netboot-pvgrub                     fail    
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub                 pass    
 test-amd64-i386-i386-wheezy-netboot-pvgrub                   pass    
 test-amd64-i386-amd64-daily-netboot-pygrub                   pass    
 test-armhf-armhf-armhf-daily-netboot-pygrub                  fail    
 test-amd64-amd64-i386-daily-netboot-pygrub                   pass    
 test-amd64-i386-amd64-jessie-netboot-pygrub                  fail    
 test-armhf-armhf-armhf-jessie-netboot-pygrub                 fail    
 test-amd64-amd64-i386-jessie-netboot-pygrub                  fail    
 test-amd64-amd64-amd64-sid-netboot-pygrub                    fail    
 test-amd64-i386-amd64-sid-netboot-pygrub                     fail    
 test-armhf-armhf-armhf-sid-netboot-pygrub                    fail    
 test-amd64-i386-i386-sid-netboot-pygrub                      fail    
 test-amd64-amd64-amd64-squeeze-netboot-pygrub                pass    
 test-amd64-i386-amd64-squeeze-netboot-pygrub                 pass    
 test-amd64-amd64-i386-squeeze-netboot-pygrub                 pass    
 test-amd64-i386-i386-squeeze-netboot-pygrub                  pass    
 test-amd64-i386-amd64-wheezy-netboot-pygrub                  pass    
 test-amd64-amd64-i386-wheezy-netboot-pygrub                  pass    
 test-amd64-amd64-amd64-current-netinst-pygrub                pass    
 test-amd64-i386-amd64-current-netinst-pygrub                 pass    
 test-amd64-amd64-i386-current-netinst-pygrub                 pass    
 test-amd64-i386-i386-current-netinst-pygrub                  fail    
 test-amd64-amd64-amd64-weekly-netinst-pygrub                 pass    
 test-amd64-i386-amd64-weekly-netinst-pygrub                  pass    
 test-amd64-amd64-i386-weekly-netinst-pygrub                  pass    
 test-amd64-i386-i386-weekly-netinst-pygrub                   fail    


------------------------------------------------------------
sg-report-flight on kazak.uk.xensource.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Dec 01 13:27:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:27:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvR18-00023h-KD; Mon, 01 Dec 2014 13:27:54 +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 1XvR17-00023a-Id
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:27:53 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A1/91-08051-8DC6C745; Mon, 01 Dec 2014 13:27:52 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417440470!12207041!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 18080 invoked from network); 1 Dec 2014 13:27:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 13:27:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198382904"
Message-ID: <547C6CC4.9070605@citrix.com>
Date: Mon, 1 Dec 2014 13:27: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: David Miller <davem@davemloft.net>, <seth.forshee@canonical.com>
References: <1416968904-70874-1-git-send-email-seth.forshee@canonical.com>
	<20141126.122812.223757363894961994.davem@davemloft.net>
In-Reply-To: <20141126.122812.223757363894961994.davem@davemloft.net>
X-DLP: MIA1
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 26/11/14 17:28, 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?

Sorry for the delay, I've been on holiday.

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

Thanks.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:27:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:27:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvR18-00023h-KD; Mon, 01 Dec 2014 13:27:54 +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 1XvR17-00023a-Id
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:27:53 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A1/91-08051-8DC6C745; Mon, 01 Dec 2014 13:27:52 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417440470!12207041!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 18080 invoked from network); 1 Dec 2014 13:27:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 13:27:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="198382904"
Message-ID: <547C6CC4.9070605@citrix.com>
Date: Mon, 1 Dec 2014 13:27: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: David Miller <davem@davemloft.net>, <seth.forshee@canonical.com>
References: <1416968904-70874-1-git-send-email-seth.forshee@canonical.com>
	<20141126.122812.223757363894961994.davem@davemloft.net>
In-Reply-To: <20141126.122812.223757363894961994.davem@davemloft.net>
X-DLP: MIA1
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 26/11/14 17:28, 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?

Sorry for the delay, I've been on holiday.

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

Thanks.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:33:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvR5t-0002H5-BF; Mon, 01 Dec 2014 13:32:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XvR5r-0002Gq-Ro
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:32:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	78/10-09842-FFD6C745; Mon, 01 Dec 2014 13:32:47 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417440766!12564750!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 3270 invoked from network); 1 Dec 2014 13:32:46 -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; 1 Dec 2014 13:32:46 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 2252DAB09;
	Mon,  1 Dec 2014 13:32:45 +0000 (UTC)
Date: Mon, 1 Dec 2014 14:32:45 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141201133245.GA25677@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> <5477FECF.2060404@suse.com>
	<547C4A7E.6020207@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C4A7E.6020207@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, "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	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 Mon, Dec 01, 2014 at 11:01:18AM +0000, David Vrabel wrote:
> On 28/11/14 04:49, Juergen Gross wrote:
> > On 11/27/2014 07:50 PM, Andrew Cooper wrote:
> >> 
> >> 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.
> 
> I dropped it because it copy-and-paste a bunch of otherwise generic x86
> assembler and looked unlikely to get an x86 maintainer ack.  If you
> think otherwise, feel free to pick it up and run with it.

I was trying to run with it, but my biggest gripe with this was
the use of preempt_schedule_irq(), but we can review that on the
other thread.

  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:33:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvR5t-0002HO-Up; Mon, 01 Dec 2014 13:32:49 +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 1XvR5s-0002Gw-9I
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 13:32:48 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	38/AE-25547-FFD6C745; Mon, 01 Dec 2014 13:32:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417440766!12545182!1
X-Originating-IP: [81.169.146.163]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10926 invoked from network); 1 Dec 2014 13:32:46 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 13:32:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417440766; l=2759;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:To:From:Date;
	bh=VrOD3tDcvllZtGY9d0LCl6Dvkdg=;
	b=Y8FUVwOH4STJnkGfhddMtxX2jChNEEY2yV55VMt4CNy7Jo/Id7J/G7UQgOC3US8fdKj
	SOw6w7MgovWcIgty5s/6EC0RPAk9LFS43xnm3AZ4mJ8b33NzIPFcjHzv0z7hRDe7rWeAn
	alkfeJ45kLG+dqzxmTExY6ucPS5Mo1YUHts=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJxKkze/KnV3DKbeZ4a
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([89.204.135.68])
	by smtp.strato.de (RZmta 36.2 DYNA|AUTH)
	with ESMTPSA id Z07573qB1DWkaL9
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate) for <xen-devel@lists.xen.org>;
	Mon, 1 Dec 2014 14:32:46 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id BF8845016D; Mon,  1 Dec 2014 14:32:44 +0100 (CET)
Date: Mon, 1 Dec 2014 14:32:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20141201133244.GA24600@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141201125712.GA21576@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, Olaf Hering wrote:

> # xl pci-assignable-add 01:10.0
> # xl pci-assignable-list
> 0000:01:10.0
> # xl create -f domU.cfg
> # xl console domU
> ## lspci gives just emulated PCI devices

ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev ff)

> ## detach from domU console
> # xl pci-attach domU 0000:01:10.0
> # xl pci-list domU
> Vdev Device
> 04.0 0000:01:10.0
> 
> # xl console domU
> ## lspci gives just emulated PCI devices

ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 01)

> ## detach from domU console
> # xl pci-detach domU 0000:01:10.0
Now lspci shows that the emulated network card is gone.
ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446

> # xl pci-attach domU 0000:01:10.0
> # xl pci-list domU
> Vdev Device
> 04.0 0000:01:10.0
> # xl console domU
> ## lspci shows now also the assigned host device


So the actual bug is that the very first time after pci-attach the guests
"00:04.0" PCI device is (most likely) replaced with the host PCI device. Just
the guest does not notice that "00:04.0" was actually already gone after unplug.

I wonder why the unplug code in xen_platform.c does just a qdev_free() instead
of a real pci-detach kind of thing. I'm sure this could be done at least for
emulated network cards.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:33:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvR5t-0002HO-Up; Mon, 01 Dec 2014 13:32:49 +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 1XvR5s-0002Gw-9I
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 13:32:48 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	38/AE-25547-FFD6C745; Mon, 01 Dec 2014 13:32:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417440766!12545182!1
X-Originating-IP: [81.169.146.163]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10926 invoked from network); 1 Dec 2014 13:32:46 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 13:32:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417440766; l=2759;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:To:From:Date;
	bh=VrOD3tDcvllZtGY9d0LCl6Dvkdg=;
	b=Y8FUVwOH4STJnkGfhddMtxX2jChNEEY2yV55VMt4CNy7Jo/Id7J/G7UQgOC3US8fdKj
	SOw6w7MgovWcIgty5s/6EC0RPAk9LFS43xnm3AZ4mJ8b33NzIPFcjHzv0z7hRDe7rWeAn
	alkfeJ45kLG+dqzxmTExY6ucPS5Mo1YUHts=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJxKkze/KnV3DKbeZ4a
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([89.204.135.68])
	by smtp.strato.de (RZmta 36.2 DYNA|AUTH)
	with ESMTPSA id Z07573qB1DWkaL9
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate) for <xen-devel@lists.xen.org>;
	Mon, 1 Dec 2014 14:32:46 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id BF8845016D; Mon,  1 Dec 2014 14:32:44 +0100 (CET)
Date: Mon, 1 Dec 2014 14:32:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20141201133244.GA24600@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141201125712.GA21576@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, Olaf Hering wrote:

> # xl pci-assignable-add 01:10.0
> # xl pci-assignable-list
> 0000:01:10.0
> # xl create -f domU.cfg
> # xl console domU
> ## lspci gives just emulated PCI devices

ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev ff)

> ## detach from domU console
> # xl pci-attach domU 0000:01:10.0
> # xl pci-list domU
> Vdev Device
> 04.0 0000:01:10.0
> 
> # xl console domU
> ## lspci gives just emulated PCI devices

ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 01)

> ## detach from domU console
> # xl pci-detach domU 0000:01:10.0
Now lspci shows that the emulated network card is gone.
ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446

> # xl pci-attach domU 0000:01:10.0
> # xl pci-list domU
> Vdev Device
> 04.0 0000:01:10.0
> # xl console domU
> ## lspci shows now also the assigned host device


So the actual bug is that the very first time after pci-attach the guests
"00:04.0" PCI device is (most likely) replaced with the host PCI device. Just
the guest does not notice that "00:04.0" was actually already gone after unplug.

I wonder why the unplug code in xen_platform.c does just a qdev_free() instead
of a real pci-detach kind of thing. I'm sure this could be done at least for
emulated network cards.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:33:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvR5t-0002H5-BF; Mon, 01 Dec 2014 13:32:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XvR5r-0002Gq-Ro
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:32:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	78/10-09842-FFD6C745; Mon, 01 Dec 2014 13:32:47 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417440766!12564750!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 3270 invoked from network); 1 Dec 2014 13:32:46 -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; 1 Dec 2014 13:32:46 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 2252DAB09;
	Mon,  1 Dec 2014 13:32:45 +0000 (UTC)
Date: Mon, 1 Dec 2014 14:32:45 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141201133245.GA25677@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> <5477FECF.2060404@suse.com>
	<547C4A7E.6020207@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C4A7E.6020207@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, "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	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 Mon, Dec 01, 2014 at 11:01:18AM +0000, David Vrabel wrote:
> On 28/11/14 04:49, Juergen Gross wrote:
> > On 11/27/2014 07:50 PM, Andrew Cooper wrote:
> >> 
> >> 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.
> 
> I dropped it because it copy-and-paste a bunch of otherwise generic x86
> assembler and looked unlikely to get an x86 maintainer ack.  If you
> think otherwise, feel free to pick it up and run with it.

I was trying to run with it, but my biggest gripe with this was
the use of preempt_schedule_irq(), but we can review that on the
other thread.

  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:33:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:33:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvR6H-0002Me-DQ; Mon, 01 Dec 2014 13:33:13 +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 1XvR6G-0002MJ-3y
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 13:33:12 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	05/A0-14727-71E6C745; Mon, 01 Dec 2014 13:33:11 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417440789!10867523!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4189 invoked from network); 1 Dec 2014 13:33:10 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 13:33: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=1417440790; x=1448976790;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=YSqU/8DKwkINq3L6dqMhDX5VkNLOi7PrAtp1xYof0qQ=;
	b=VLxRyaujSlMJivaUrw+JH+ouJEw6bqdKGOy/OqcT558U7tHnphwV9Z0o
	Q0CFqi7jvwIPLrBgB8O4tI50C/bNN8Q5lpKhk8gGWgaFNL3sMd9Z/J+U9
	xAhttGT3g9RHoT5o4DIeeoYvFhHlCZ9NFUZ89It2+LstDQRsS3DNkEedI 8=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 01 Dec 2014 13:33:08 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="917674816"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.110.212])
	by fldsmtpi01.verizon.com with ESMTP; 01 Dec 2014 13:33:06 +0000
Message-ID: <547C6E12.50502@terremark.com>
Date: Mon, 01 Dec 2014 08:33:06 -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>
	<54768F7F.2030602@terremark.com>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
Cc: xen-devel@lists.xensource.com, "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, qemu-devel@nongnu.org,
	Don Slutz <dslutz@verizon.com>
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/27/14 05:48, Stefano Stabellini wrote:
> 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?

Yes.

> 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.
>

Works fine in both claim modes and with PoD used (maxmem > memory).  Do
not know how to test with tmem.  I do not see how it would be worse then 
current
code that does not auto increase.  I.E. even without a xen change, I 
think something
like this could be done.


>> 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.

Ok.  I did find the 32 it is VGA_HOLE_SIZE.  So here is what I have 
which includes
a lot of extra printf.


--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -67,6 +67,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t 
*shared_page, int vcpu)
  #endif

  #define BUFFER_IO_MAX_DELAY  100
+#define VGA_HOLE_SIZE (0x20)

  typedef struct XenPhysmap {
      hwaddr start_addr;
@@ -219,6 +220,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t 
size, MemoryRegion *mr)
      xen_pfn_t *pfn_list;
      int i;
      xc_dominfo_t info;
+    unsigned long max_pages, free_pages, real_free;
+    long need_pages;
+    uint64_t tot_pages, pod_cache_pages, pod_entries;
+
+    trace_xen_ram_alloc(ram_addr, size, mr->name);

      if (runstate_check(RUN_STATE_INMIGRATE)) {
          /* RAM already populated in Xen */
@@ -232,13 +238,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t 
size, MemoryRegion *mr)
          return;
      }

-    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
-            " bytes (%ld Kib) of ram at "RAM_ADDR_FMT
-            " mr.name=%s\n",
-            __func__, size, (long)(size>>10), ram_addr, mr->name);
-
-    trace_xen_ram_alloc(ram_addr, size);
-
      nr_pfn = size >> TARGET_PAGE_BITS;
      pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);

@@ -246,11 +245,38 @@ 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) {
+    if ((xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) ||
+       (info.domid != xen_domid)) {
          hw_error("xc_domain_getinfo failed");
      }
-    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;
+    real_free = free_pages;
+    if (free_pages > VGA_HOLE_SIZE) {
+        free_pages -= VGA_HOLE_SIZE;
+    } else {
+        free_pages = 0;
+    }
+    need_pages = nr_pfn - free_pages;
+    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
+            " bytes (%ld KiB) of ram at "RAM_ADDR_FMT
+            " mp=%ld fp=%ld nr=%ld need=%ld mr.name=%s\n",
+            __func__, size, (long)(size>>10), ram_addr,
+           max_pages, free_pages, nr_pfn, need_pages,
+            mr->name);
+    if (xc_domain_get_pod_target(xen_xc, xen_domid, &tot_pages,
+                                 &pod_cache_pages, &pod_entries) >= 0) {
+        unsigned long populated = tot_pages - pod_cache_pages;
+        long delta_tot = tot_pages - info.nr_pages;
+
+        fprintf(stderr, "%s: PoD pop=%ld tot=%ld(%ld) cnt=%ld ent=%ld 
nop=%ld free=%ld\n",
+                __func__, populated, (long)tot_pages, delta_tot,
+                (long)pod_cache_pages, (long)pod_entries,
+               (long)info.nr_outstanding_pages, real_free);
+    }
+    if ((free_pages < nr_pfn) &&
+       (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
+                            (need_pages * 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)) {


Note: I already had a trace_xen_ram_alloc, here is the delta in 
trace-events (which
has others not yet sent):



diff --git a/trace-events b/trace-events
index eaeecd5..a58fc11 100644
--- a/trace-events
+++ b/trace-events
@@ -908,7 +908,7 @@ pvscsi_tx_rings_ppn(const char* label, uint64_t ppn) 
"%s page: %"PRIx64""
  pvscsi_tx_rings_num_pages(const char* label, uint32_t num) "Number of 
%s pages: %u"

  # xen-all.c
-xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: 
%#lx, size %#lx"
+xen_ram_alloc(unsigned long ram_addr, unsigned long size, const char* 
mr_name) "requested: %#lx size %#lx mr->name=%s"
  xen_client_set_memory(uint64_t start_addr, unsigned long size, bool 
log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
  handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df, 
uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, 
uint32_t size) "I/O=%p type=%d dir=%d df=%d ptr=%d port=%#"PRIx64" 
data=%#"PRIx64" count=%d size=%d"
  handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t 
data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t 
size) "I/O=%p read type=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" 
count=%d size=%d"


    -Don Slutz

>
>>     -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 Mon Dec 01 13:33:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:33:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvR6H-0002Me-DQ; Mon, 01 Dec 2014 13:33:13 +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 1XvR6G-0002MJ-3y
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 13:33:12 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	05/A0-14727-71E6C745; Mon, 01 Dec 2014 13:33:11 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417440789!10867523!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4189 invoked from network); 1 Dec 2014 13:33:10 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 13:33: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=1417440790; x=1448976790;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=YSqU/8DKwkINq3L6dqMhDX5VkNLOi7PrAtp1xYof0qQ=;
	b=VLxRyaujSlMJivaUrw+JH+ouJEw6bqdKGOy/OqcT558U7tHnphwV9Z0o
	Q0CFqi7jvwIPLrBgB8O4tI50C/bNN8Q5lpKhk8gGWgaFNL3sMd9Z/J+U9
	xAhttGT3g9RHoT5o4DIeeoYvFhHlCZ9NFUZ89It2+LstDQRsS3DNkEedI 8=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 01 Dec 2014 13:33:08 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,493,1413244800"; d="scan'208";a="917674816"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.110.212])
	by fldsmtpi01.verizon.com with ESMTP; 01 Dec 2014 13:33:06 +0000
Message-ID: <547C6E12.50502@terremark.com>
Date: Mon, 01 Dec 2014 08:33:06 -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>
	<54768F7F.2030602@terremark.com>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
Cc: xen-devel@lists.xensource.com, "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, qemu-devel@nongnu.org,
	Don Slutz <dslutz@verizon.com>
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/27/14 05:48, Stefano Stabellini wrote:
> 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?

Yes.

> 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.
>

Works fine in both claim modes and with PoD used (maxmem > memory).  Do
not know how to test with tmem.  I do not see how it would be worse then 
current
code that does not auto increase.  I.E. even without a xen change, I 
think something
like this could be done.


>> 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.

Ok.  I did find the 32 it is VGA_HOLE_SIZE.  So here is what I have 
which includes
a lot of extra printf.


--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -67,6 +67,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t 
*shared_page, int vcpu)
  #endif

  #define BUFFER_IO_MAX_DELAY  100
+#define VGA_HOLE_SIZE (0x20)

  typedef struct XenPhysmap {
      hwaddr start_addr;
@@ -219,6 +220,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t 
size, MemoryRegion *mr)
      xen_pfn_t *pfn_list;
      int i;
      xc_dominfo_t info;
+    unsigned long max_pages, free_pages, real_free;
+    long need_pages;
+    uint64_t tot_pages, pod_cache_pages, pod_entries;
+
+    trace_xen_ram_alloc(ram_addr, size, mr->name);

      if (runstate_check(RUN_STATE_INMIGRATE)) {
          /* RAM already populated in Xen */
@@ -232,13 +238,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t 
size, MemoryRegion *mr)
          return;
      }

-    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
-            " bytes (%ld Kib) of ram at "RAM_ADDR_FMT
-            " mr.name=%s\n",
-            __func__, size, (long)(size>>10), ram_addr, mr->name);
-
-    trace_xen_ram_alloc(ram_addr, size);
-
      nr_pfn = size >> TARGET_PAGE_BITS;
      pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);

@@ -246,11 +245,38 @@ 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) {
+    if ((xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) ||
+       (info.domid != xen_domid)) {
          hw_error("xc_domain_getinfo failed");
      }
-    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;
+    real_free = free_pages;
+    if (free_pages > VGA_HOLE_SIZE) {
+        free_pages -= VGA_HOLE_SIZE;
+    } else {
+        free_pages = 0;
+    }
+    need_pages = nr_pfn - free_pages;
+    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
+            " bytes (%ld KiB) of ram at "RAM_ADDR_FMT
+            " mp=%ld fp=%ld nr=%ld need=%ld mr.name=%s\n",
+            __func__, size, (long)(size>>10), ram_addr,
+           max_pages, free_pages, nr_pfn, need_pages,
+            mr->name);
+    if (xc_domain_get_pod_target(xen_xc, xen_domid, &tot_pages,
+                                 &pod_cache_pages, &pod_entries) >= 0) {
+        unsigned long populated = tot_pages - pod_cache_pages;
+        long delta_tot = tot_pages - info.nr_pages;
+
+        fprintf(stderr, "%s: PoD pop=%ld tot=%ld(%ld) cnt=%ld ent=%ld 
nop=%ld free=%ld\n",
+                __func__, populated, (long)tot_pages, delta_tot,
+                (long)pod_cache_pages, (long)pod_entries,
+               (long)info.nr_outstanding_pages, real_free);
+    }
+    if ((free_pages < nr_pfn) &&
+       (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
+                            (need_pages * 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)) {


Note: I already had a trace_xen_ram_alloc, here is the delta in 
trace-events (which
has others not yet sent):



diff --git a/trace-events b/trace-events
index eaeecd5..a58fc11 100644
--- a/trace-events
+++ b/trace-events
@@ -908,7 +908,7 @@ pvscsi_tx_rings_ppn(const char* label, uint64_t ppn) 
"%s page: %"PRIx64""
  pvscsi_tx_rings_num_pages(const char* label, uint32_t num) "Number of 
%s pages: %u"

  # xen-all.c
-xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: 
%#lx, size %#lx"
+xen_ram_alloc(unsigned long ram_addr, unsigned long size, const char* 
mr_name) "requested: %#lx size %#lx mr->name=%s"
  xen_client_set_memory(uint64_t start_addr, unsigned long size, bool 
log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
  handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df, 
uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, 
uint32_t size) "I/O=%p type=%d dir=%d df=%d ptr=%d port=%#"PRIx64" 
data=%#"PRIx64" count=%d size=%d"
  handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t 
data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t 
size) "I/O=%p read type=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" 
count=%d size=%d"


    -Don Slutz

>
>>     -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 Mon Dec 01 13:37:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13: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 1XvRA0-0002ph-1g; Mon, 01 Dec 2014 13:37:04 +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 1XvR9y-0002pc-V2
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:37:03 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	D7/AF-02702-DFE6C745; Mon, 01 Dec 2014 13:37:01 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417441019!12217009!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 22435 invoked from network); 1 Dec 2014 13:37:00 -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;
	1 Dec 2014 13:37:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198060225"
Message-ID: <547C6EF6.8020604@citrix.com>
Date: Mon, 1 Dec 2014 13:36:54 +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: Stefan Bader <stefan.bader@canonical.com>, Zoltan Kiss
	<zoltan.kiss@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, David Vrabel
	<david.vrabel@citrix.com>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>
	<547C2CFC.7060908@canonical.com>
In-Reply-To: <547C2CFC.7060908@canonical.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 01/12/14 08:55, Stefan Bader wrote:
> On 11.08.2014 19:32, Zoltan Kiss wrote:
>> There is a long known problem with the netfront/netback interface: if the guest
>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
>> it gets dropped. The reason is that netback maps these slots to a frag in the
>> frags array, which is limited by size. Having so many slots can occur since
>> compound pages were introduced, as the ring protocol slice them up into
>> individual (non-compound) page aligned slots. The theoretical worst case
>> scenario looks like this (note, skbs are limited to 64 Kb here):
>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
>> using 2 slots
>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
>> end and the beginning of a page, therefore they use 3 * 15 = 45 slots
>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
>> Although I don't think this 51 slots skb can really happen, we need a solution
>> which can deal with every scenario. In real life there is only a few slots
>> overdue, but usually it causes the TCP stream to be blocked, as the retry will
>> most likely have the same buffer layout.
>> This patch solves this problem by linearizing the packet. This is not the
>> fastest way, and it can fail much easier as it tries to allocate a big linear
>> area for the whole packet, but probably easier by an order of magnitude than
>> anything else. Probably this code path is not touched very frequently anyway.
>>
>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>> Cc: Wei Liu <wei.liu2@citrix.com>
>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>> Cc: Paul Durrant <paul.durrant@citrix.com>
>> Cc: netdev@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: xen-devel@lists.xenproject.org
> 
> This does not seem to be marked explicitly as stable. Has someone already asked
> David Miller to put it on his stable queue? IMO it qualifies quite well and the
> actual change should be simple to pick/backport.

I think it's a candidate, yes.

Can you expand on the user visible impact of the bug this patch fixes?
I think it results in certain types of traffic not working (because the
domU always generates skb's with the problematic frag layout), but I
can't remember the details.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:37:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13: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 1XvRA0-0002ph-1g; Mon, 01 Dec 2014 13:37:04 +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 1XvR9y-0002pc-V2
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:37:03 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	D7/AF-02702-DFE6C745; Mon, 01 Dec 2014 13:37:01 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417441019!12217009!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 22435 invoked from network); 1 Dec 2014 13:37:00 -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;
	1 Dec 2014 13:37:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198060225"
Message-ID: <547C6EF6.8020604@citrix.com>
Date: Mon, 1 Dec 2014 13:36:54 +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: Stefan Bader <stefan.bader@canonical.com>, Zoltan Kiss
	<zoltan.kiss@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, David Vrabel
	<david.vrabel@citrix.com>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>
	<547C2CFC.7060908@canonical.com>
In-Reply-To: <547C2CFC.7060908@canonical.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 01/12/14 08:55, Stefan Bader wrote:
> On 11.08.2014 19:32, Zoltan Kiss wrote:
>> There is a long known problem with the netfront/netback interface: if the guest
>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
>> it gets dropped. The reason is that netback maps these slots to a frag in the
>> frags array, which is limited by size. Having so many slots can occur since
>> compound pages were introduced, as the ring protocol slice them up into
>> individual (non-compound) page aligned slots. The theoretical worst case
>> scenario looks like this (note, skbs are limited to 64 Kb here):
>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
>> using 2 slots
>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
>> end and the beginning of a page, therefore they use 3 * 15 = 45 slots
>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
>> Although I don't think this 51 slots skb can really happen, we need a solution
>> which can deal with every scenario. In real life there is only a few slots
>> overdue, but usually it causes the TCP stream to be blocked, as the retry will
>> most likely have the same buffer layout.
>> This patch solves this problem by linearizing the packet. This is not the
>> fastest way, and it can fail much easier as it tries to allocate a big linear
>> area for the whole packet, but probably easier by an order of magnitude than
>> anything else. Probably this code path is not touched very frequently anyway.
>>
>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>> Cc: Wei Liu <wei.liu2@citrix.com>
>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>> Cc: Paul Durrant <paul.durrant@citrix.com>
>> Cc: netdev@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: xen-devel@lists.xenproject.org
> 
> This does not seem to be marked explicitly as stable. Has someone already asked
> David Miller to put it on his stable queue? IMO it qualifies quite well and the
> actual change should be simple to pick/backport.

I think it's a candidate, yes.

Can you expand on the user visible impact of the bug this patch fixes?
I think it results in certain types of traffic not working (because the
domU always generates skb's with the problematic frag layout), but I
can't remember the details.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:37:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13: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 1XvRA9-0002r4-Dh; Mon, 01 Dec 2014 13:37:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XvRA8-0002qo-Gd
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:37:12 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4A/B8-09842-70F6C745; Mon, 01 Dec 2014 13:37:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417441031!12241136!1
X-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 11526 invoked from network); 1 Dec 2014 13:37:11 -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; 1 Dec 2014 13:37:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 13:37:10 +0000
Message-Id: <547C7D13020000780004BC3D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 13:37:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>
	<1417426153-12893-2-git-send-email-jgross@suse.com>
	<547C4DD6020000780004BA83@mail.emea.novell.com>
	<547C4ECB.7070702@citrix.com> <547C5F31020000780004BB1F@suse.com>
	<547C68FD.60000@suse.com>
In-Reply-To: <547C68FD.60000@suse.com>
Mime-Version: 1.0
Content-Length: 4908
Content-Disposition: inline
Cc: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [Patch V2] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDAxLjEyLjE0IGF0IDE0OjExLCA8Skdyb3NzQHN1c2UuY29tPiB3cm90ZToKPiBPbiAx
Mi8wMS8yMDE0IDEyOjI5IFBNLCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4gT24gMDEuMTIuMTQg
YXQgMTI6MTksIDxkYXZpZC52cmFiZWxAY2l0cml4LmNvbT4gd3JvdGU6Cj4+PiBPbiAwMS8xMi8x
NCAxMDoxNSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4+Pj4gT24gMDEuMTIuMTQgYXQgMTA6Mjks
IDxKR3Jvc3NAc3VzZS5jb20+IHdyb3RlOgo+Pj4+PiBUaGUgeDg2IHN0cnVjdCBhcmNoX3NoYXJl
ZF9pbmZvIGZpZWxkIHBmbl90b19tZm5fZnJhbWVfbGlzdF9saXN0Cj4+Pj4+IGN1cnJlbnRseSBj
b250YWlucyB0aGUgbWZuIG9mIHRoZSB0b3AgbGV2ZWwgcGFnZSBmcmFtZSBvZiB0aGUgMyBsZXZl
bAo+Pj4+PiBwMm0gdHJlZSwgd2hpY2ggaXMgdXNlZCBieSB0aGUgWGVuIHRvb2xzIGR1cmluZyBz
YXZpbmcgYW5kIHJlc3RvcmluZwo+Pj4+PiAoYW5kIGxpdmUgbWlncmF0aW9uKSBvZiBwdiBkb21h
aW5zIGFuZCBmb3IgY3Jhc2ggZHVtcCBhbmFseXNpcy4gV2l0aAo+Pj4+PiB0aHJlZSBsZXZlbHMg
b2YgdGhlIHAybSB0cmVlIGl0IGlzIHBvc3NpYmxlIHRvIHN1cHBvcnQgdXAgdG8gNTEyIEdCIG9m
Cj4+Pj4+IFJBTSBmb3IgYSA2NCBiaXQgcHYgZG9tYWluLgo+Pj4+Pgo+Pj4+PiBBIDMyIGJpdCBw
diBkb21haW4gY2FuIHN1cHBvcnQgbW9yZSwgYXMgZWFjaCBtZW1vcnkgcGFnZSBjYW4gaG9sZCAx
MDI0Cj4+Pj4+IGluc3RlYWQgb2YgNTEyIGVudHJpZXMsIGxlYWRpbmcgdG8gYSBsaW1pdCBvZiA0
IFRCLgo+Pj4+Pgo+Pj4+PiBUbyBiZSBhYmxlIHRvIHN1cHBvcnQgbW9yZSBSQU0gb24geDg2LTY0
IHN3aXRjaCB0byBhIHZpcnR1YWwgbWFwcGVkCj4+Pj4+IHAybSBsaXN0Lgo+Pj4+Pgo+Pj4+PiBU
aGlzIHBhdGNoIGV4cGFuZHMgc3RydWN0IGFyY2hfc2hhcmVkX2luZm8gd2l0aCBhIG5ldyBwMm0g
bGlzdCB2aXJ0dWFsCj4+Pj4+IGFkZHJlc3MsIHRoZSByb290IG9mIHRoZSBwYWdlIHRhYmxlIHJv
b3QgYW5kIGEgcDJtIGdlbmVyYXRpb24gY291bnQuCj4+Pj4+IFRoZSBuZXcgaW5mb3JtYXRpb24g
aXMgaW5kaWNhdGVkIGJ5IHRoZSBkb21haW4gdG8gYmUgdmFsaWQgYnkgc3RvcmluZwo+Pj4+PiB+
MFVMIGludG8gcGZuX3RvX21mbl9mcmFtZV9saXN0X2xpc3QuIFRoZSBoeXBlcnZpc29yIGluZGlj
YXRlcwo+Pj4+PiB1c2FiaWxpdHkgb2YgdGhpcyBmZWF0dXJlIGJ5IGEgbmV3IGZsYWcgWEVORkVB
VF92aXJ0dWFsX3AybS4KPj4+Pj4KPj4+Pj4gUmlnaHQgbm93IFhFTkZFQVRfdmlydHVhbF9wMm0g
d2lsbCBub3QgYmUgc2V0LiBUaGlzIHdpbGwgY2hhbmdlIHdoZW4KPj4+Pj4gdGhlIFhlbiB0b29s
cyBzdXBwb3J0IHRoZSB2aXJ0dWFsIG1hcHBlZCBwMm0gbGlzdC4KPj4+Pgo+Pj4+IFRoaXMgc2Vl
bXMgd3Jvbmc6IFhFTkZFQVRfKiBvbmx5IHJlZmxlY3QgaHlwZXJ2aXNvciBjYXBhYmlsaXRpZXMu
Cj4+Pj4gSS5lLiB0aGUgYXZhaWxhYmlsaXR5IG9mIHRoZSBuZXcgZnVuY3Rpb25hbGl0eSBtYXkg
bmVlZCB0byBiZQo+Pj4+IGFkdmVydGlzZWQgYW5vdGhlciB3YXkgLSB4ZW5zdG9yZSBwZXJoYXBz
Pwo+Pj4KPj4+IFhlbnN0b3JlIGRvZXNuJ3Qgd29yayBmb3IgZG9tMC4KPj4+Cj4+PiBTaG91bGRu
J3QgdGhpcyBiZSBzb21ldGhpbmcgdGhlIGd1ZXN0IGtlcm5lbCByZXBvcnRzIHVzaW5nIGEgRUxG
IG5vdGUgYml0Pwo+Pj4KPj4+IFdoZW4gYnVpbGRpbmcgYSBkb21haW4gKGVpdGhlciBpbiBYZW4g
Zm9yIGRvbTAgb3IgaW4gdGhlIHRvb2xzKSwgdGhlCj4+PiBidWlsZGVyIG1heSBwcm92aWRlIGEg
bGluZWFyIHAybSBpZmYgc3VwcG9ydGVkIGJ5IHRoZSBndWVzdCBrZXJuZWwgYW5kCj4+PiB0aGVu
IChhbmQgb25seSB0aGVuKSBjYW4gaXQgcHJvdmlkZSBhIGd1ZXN0IHdpdGggPiA1MTIgR2lCLgo+
Pgo+PiBZZXMsIHN1cmVseSB0aGlzIGZsYWcgY291bGQgYWN0IGFzIGEga2VybmVsIGNhcGFiaWxp
dHkgaW5kaWNhdG9yICh2aWEKPj4gdGhlIFhFTl9FTEZOT1RFX1NVUFBPUlRFRF9GRUFUVVJFUyBu
b3RlKSwgbGlrZSBlLmcuCj4+IFhFTkZFQVRfZG9tMCBhbHJlYWR5IGRvZXMuIErDvHJnZW4ncyBm
aW5hbCBzdGF0ZW1lbnQsIGhvd2V2ZXIsCj4+IHN1Z2dlc3RlZCB0byBtZSB0aGF0IHRoaXMgaXMg
bWVhbnQgdG8gYmUgb25seSBjb25zdW1lZCBieSBrZXJuZWxzLgo+IAo+IFllcy4gVGhlIHAybSBs
aXN0IGJ1aWx0IGJ5IHRoZSBkb21haW4gYnVpbGRlciBpcyBhbHJlYWR5IGxpbmVhci4gSXQgbWF5
Cj4ganVzdCBiZSB0byBzbWFsbCB0byBob2xkIGFsbCBlbnRyaWVzIHJlcXVpcmVkIGUuZy4gZm9y
IERvbTAuCj4gCj4gSXQncyBYZW4tdG9vbHMgYW5kIGtkdW1wIHdoaWNoIGhhdmUgdG8gZGVhbCB3
aXRoIHRoZSBsaW5lYXIgcDJtIGxpc3QuCj4gU28gdGhlIGd1ZXN0IGtlcm5lbCBoYXMgdG8gYmUg
dG9sZCBpZiBpdCBpcyBhbGxvd2VkIHRvIHByZXNlbnQgdGhlCj4gbGluZWFyIGxpc3QgaW5zdGVh
ZCBvZiB0aGUgMy1sZXZlbCB0cmVlIGF0IHBmbl90b19tZm5fZnJhbWVfbGlzdF9saXN0Lgo+IAo+
IEFzIHRoaXMgaXMgdHJ1ZSBmb3IgRG9tMCBhcyB3ZWxsLCB0aGlzIGluZm9ybWF0aW9uIG11c3Qg
YmUgZ2l2ZW4gYnkgdGhlCj4gaHlwZXJ2aXNvci4KPiAKPiBJJ20gYXdhcmUgdGhhdCBYRU5GRUFU
XyogaXMgb25seSB1c2VkIGZvciBoeXBlcnZpc29yIGNhcGFiaWxpdGllcyB1cCB0bwo+IG5vdy4g
QXMgdGhlIFhlbiB0b29scyBhcmUgdGlnaHRseSBjb3VwbGVkIHRvIHRoZSBoeXBlcnZpc29yIEkg
ZG9uJ3Qgc2VlCj4gd2h5IHRoZSBmZWF0dXJlcyBjYW4ndCBleHByZXNzIHRoZSBjYXBhYmlsaXR5
IG9mIHRoZSBjb21wbGV0ZSBYZW4KPiBpbnN0YWxsYXRpb24gaW5zdGVhZC4gV291bGQgeW91IHBy
ZWZlciBpbnRyb2R1Y2luZyBhbm90aGVyIGxlYWYgZm9yCj4gdGhhdCBwdXJwb3NlIChzdWJtYXAu
aWR4ID09IDEpID8KClRoYXQgd291bGRuJ3QgY2hhbmdlIHRoZSBvZGQgc2l0dWF0aW9uIG9mIHJl
cG9ydGluZyBhIGNhcGFiaWxpdHkgb2YKYW5vdGhlciBjb21wb25lbnQuIFRoYXQncyBldmVuIG1v
cmUgb2YgYSBwcm9ibGVtIGZvciB0aGUgRG9tMApjYXNlLCB3aGVyZSB0aGUgYWZmZWN0ZWQgdG9v
bCAoa2R1bXApIGlzbid0IGV2ZW4gdW5kZXIgb3VyIGNvbnRyb2wKKGFuZCBzaG91bGRuJ3QgYmUp
LgoKQnV0IGluIHRoZSBlbmQgLSB3aGF0J3Mgd3Jvbmcgd2l0aCBhbHdheXMgKG9yIGNvbmRpdGlv
bmFsbHkgdXBvbiBhCkNPTkZJR18qIG9wdGlvbiBhbmQvb3IgY29tbWFuZCBsaW5lIHBhcmFtZXRl
ciBhbmQvb3IgbWVtb3J5CnNpemUpIGZpbGxpbmcgYm90aCB0aGUgb2xkIGFuZCBuZXcgc2hhcmVk
IGluZm8gZmllbGRzPyBBIGNhcGFibGUgdG9vbApjYW4gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIG5l
dyBvbmUgaXMgdmFsaWQsIGFuZCBhbiBpbmNhcGFibGUgdG9vbAp3b24ndCB3b3JrIG9uIGh1Z2Ug
bWVtb3J5IGNvbmZpZ3MgYW55d2F5LgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:37:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13: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 1XvRA9-0002r4-Dh; Mon, 01 Dec 2014 13:37:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XvRA8-0002qo-Gd
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:37:12 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4A/B8-09842-70F6C745; Mon, 01 Dec 2014 13:37:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417441031!12241136!1
X-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 11526 invoked from network); 1 Dec 2014 13:37:11 -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; 1 Dec 2014 13:37:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 13:37:10 +0000
Message-Id: <547C7D13020000780004BC3D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 13:37:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>
	<1417426153-12893-2-git-send-email-jgross@suse.com>
	<547C4DD6020000780004BA83@mail.emea.novell.com>
	<547C4ECB.7070702@citrix.com> <547C5F31020000780004BB1F@suse.com>
	<547C68FD.60000@suse.com>
In-Reply-To: <547C68FD.60000@suse.com>
Mime-Version: 1.0
Content-Length: 4908
Content-Disposition: inline
Cc: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [Patch V2] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDAxLjEyLjE0IGF0IDE0OjExLCA8Skdyb3NzQHN1c2UuY29tPiB3cm90ZToKPiBPbiAx
Mi8wMS8yMDE0IDEyOjI5IFBNLCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4gT24gMDEuMTIuMTQg
YXQgMTI6MTksIDxkYXZpZC52cmFiZWxAY2l0cml4LmNvbT4gd3JvdGU6Cj4+PiBPbiAwMS8xMi8x
NCAxMDoxNSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4+Pj4gT24gMDEuMTIuMTQgYXQgMTA6Mjks
IDxKR3Jvc3NAc3VzZS5jb20+IHdyb3RlOgo+Pj4+PiBUaGUgeDg2IHN0cnVjdCBhcmNoX3NoYXJl
ZF9pbmZvIGZpZWxkIHBmbl90b19tZm5fZnJhbWVfbGlzdF9saXN0Cj4+Pj4+IGN1cnJlbnRseSBj
b250YWlucyB0aGUgbWZuIG9mIHRoZSB0b3AgbGV2ZWwgcGFnZSBmcmFtZSBvZiB0aGUgMyBsZXZl
bAo+Pj4+PiBwMm0gdHJlZSwgd2hpY2ggaXMgdXNlZCBieSB0aGUgWGVuIHRvb2xzIGR1cmluZyBz
YXZpbmcgYW5kIHJlc3RvcmluZwo+Pj4+PiAoYW5kIGxpdmUgbWlncmF0aW9uKSBvZiBwdiBkb21h
aW5zIGFuZCBmb3IgY3Jhc2ggZHVtcCBhbmFseXNpcy4gV2l0aAo+Pj4+PiB0aHJlZSBsZXZlbHMg
b2YgdGhlIHAybSB0cmVlIGl0IGlzIHBvc3NpYmxlIHRvIHN1cHBvcnQgdXAgdG8gNTEyIEdCIG9m
Cj4+Pj4+IFJBTSBmb3IgYSA2NCBiaXQgcHYgZG9tYWluLgo+Pj4+Pgo+Pj4+PiBBIDMyIGJpdCBw
diBkb21haW4gY2FuIHN1cHBvcnQgbW9yZSwgYXMgZWFjaCBtZW1vcnkgcGFnZSBjYW4gaG9sZCAx
MDI0Cj4+Pj4+IGluc3RlYWQgb2YgNTEyIGVudHJpZXMsIGxlYWRpbmcgdG8gYSBsaW1pdCBvZiA0
IFRCLgo+Pj4+Pgo+Pj4+PiBUbyBiZSBhYmxlIHRvIHN1cHBvcnQgbW9yZSBSQU0gb24geDg2LTY0
IHN3aXRjaCB0byBhIHZpcnR1YWwgbWFwcGVkCj4+Pj4+IHAybSBsaXN0Lgo+Pj4+Pgo+Pj4+PiBU
aGlzIHBhdGNoIGV4cGFuZHMgc3RydWN0IGFyY2hfc2hhcmVkX2luZm8gd2l0aCBhIG5ldyBwMm0g
bGlzdCB2aXJ0dWFsCj4+Pj4+IGFkZHJlc3MsIHRoZSByb290IG9mIHRoZSBwYWdlIHRhYmxlIHJv
b3QgYW5kIGEgcDJtIGdlbmVyYXRpb24gY291bnQuCj4+Pj4+IFRoZSBuZXcgaW5mb3JtYXRpb24g
aXMgaW5kaWNhdGVkIGJ5IHRoZSBkb21haW4gdG8gYmUgdmFsaWQgYnkgc3RvcmluZwo+Pj4+PiB+
MFVMIGludG8gcGZuX3RvX21mbl9mcmFtZV9saXN0X2xpc3QuIFRoZSBoeXBlcnZpc29yIGluZGlj
YXRlcwo+Pj4+PiB1c2FiaWxpdHkgb2YgdGhpcyBmZWF0dXJlIGJ5IGEgbmV3IGZsYWcgWEVORkVB
VF92aXJ0dWFsX3AybS4KPj4+Pj4KPj4+Pj4gUmlnaHQgbm93IFhFTkZFQVRfdmlydHVhbF9wMm0g
d2lsbCBub3QgYmUgc2V0LiBUaGlzIHdpbGwgY2hhbmdlIHdoZW4KPj4+Pj4gdGhlIFhlbiB0b29s
cyBzdXBwb3J0IHRoZSB2aXJ0dWFsIG1hcHBlZCBwMm0gbGlzdC4KPj4+Pgo+Pj4+IFRoaXMgc2Vl
bXMgd3Jvbmc6IFhFTkZFQVRfKiBvbmx5IHJlZmxlY3QgaHlwZXJ2aXNvciBjYXBhYmlsaXRpZXMu
Cj4+Pj4gSS5lLiB0aGUgYXZhaWxhYmlsaXR5IG9mIHRoZSBuZXcgZnVuY3Rpb25hbGl0eSBtYXkg
bmVlZCB0byBiZQo+Pj4+IGFkdmVydGlzZWQgYW5vdGhlciB3YXkgLSB4ZW5zdG9yZSBwZXJoYXBz
Pwo+Pj4KPj4+IFhlbnN0b3JlIGRvZXNuJ3Qgd29yayBmb3IgZG9tMC4KPj4+Cj4+PiBTaG91bGRu
J3QgdGhpcyBiZSBzb21ldGhpbmcgdGhlIGd1ZXN0IGtlcm5lbCByZXBvcnRzIHVzaW5nIGEgRUxG
IG5vdGUgYml0Pwo+Pj4KPj4+IFdoZW4gYnVpbGRpbmcgYSBkb21haW4gKGVpdGhlciBpbiBYZW4g
Zm9yIGRvbTAgb3IgaW4gdGhlIHRvb2xzKSwgdGhlCj4+PiBidWlsZGVyIG1heSBwcm92aWRlIGEg
bGluZWFyIHAybSBpZmYgc3VwcG9ydGVkIGJ5IHRoZSBndWVzdCBrZXJuZWwgYW5kCj4+PiB0aGVu
IChhbmQgb25seSB0aGVuKSBjYW4gaXQgcHJvdmlkZSBhIGd1ZXN0IHdpdGggPiA1MTIgR2lCLgo+
Pgo+PiBZZXMsIHN1cmVseSB0aGlzIGZsYWcgY291bGQgYWN0IGFzIGEga2VybmVsIGNhcGFiaWxp
dHkgaW5kaWNhdG9yICh2aWEKPj4gdGhlIFhFTl9FTEZOT1RFX1NVUFBPUlRFRF9GRUFUVVJFUyBu
b3RlKSwgbGlrZSBlLmcuCj4+IFhFTkZFQVRfZG9tMCBhbHJlYWR5IGRvZXMuIErDvHJnZW4ncyBm
aW5hbCBzdGF0ZW1lbnQsIGhvd2V2ZXIsCj4+IHN1Z2dlc3RlZCB0byBtZSB0aGF0IHRoaXMgaXMg
bWVhbnQgdG8gYmUgb25seSBjb25zdW1lZCBieSBrZXJuZWxzLgo+IAo+IFllcy4gVGhlIHAybSBs
aXN0IGJ1aWx0IGJ5IHRoZSBkb21haW4gYnVpbGRlciBpcyBhbHJlYWR5IGxpbmVhci4gSXQgbWF5
Cj4ganVzdCBiZSB0byBzbWFsbCB0byBob2xkIGFsbCBlbnRyaWVzIHJlcXVpcmVkIGUuZy4gZm9y
IERvbTAuCj4gCj4gSXQncyBYZW4tdG9vbHMgYW5kIGtkdW1wIHdoaWNoIGhhdmUgdG8gZGVhbCB3
aXRoIHRoZSBsaW5lYXIgcDJtIGxpc3QuCj4gU28gdGhlIGd1ZXN0IGtlcm5lbCBoYXMgdG8gYmUg
dG9sZCBpZiBpdCBpcyBhbGxvd2VkIHRvIHByZXNlbnQgdGhlCj4gbGluZWFyIGxpc3QgaW5zdGVh
ZCBvZiB0aGUgMy1sZXZlbCB0cmVlIGF0IHBmbl90b19tZm5fZnJhbWVfbGlzdF9saXN0Lgo+IAo+
IEFzIHRoaXMgaXMgdHJ1ZSBmb3IgRG9tMCBhcyB3ZWxsLCB0aGlzIGluZm9ybWF0aW9uIG11c3Qg
YmUgZ2l2ZW4gYnkgdGhlCj4gaHlwZXJ2aXNvci4KPiAKPiBJJ20gYXdhcmUgdGhhdCBYRU5GRUFU
XyogaXMgb25seSB1c2VkIGZvciBoeXBlcnZpc29yIGNhcGFiaWxpdGllcyB1cCB0bwo+IG5vdy4g
QXMgdGhlIFhlbiB0b29scyBhcmUgdGlnaHRseSBjb3VwbGVkIHRvIHRoZSBoeXBlcnZpc29yIEkg
ZG9uJ3Qgc2VlCj4gd2h5IHRoZSBmZWF0dXJlcyBjYW4ndCBleHByZXNzIHRoZSBjYXBhYmlsaXR5
IG9mIHRoZSBjb21wbGV0ZSBYZW4KPiBpbnN0YWxsYXRpb24gaW5zdGVhZC4gV291bGQgeW91IHBy
ZWZlciBpbnRyb2R1Y2luZyBhbm90aGVyIGxlYWYgZm9yCj4gdGhhdCBwdXJwb3NlIChzdWJtYXAu
aWR4ID09IDEpID8KClRoYXQgd291bGRuJ3QgY2hhbmdlIHRoZSBvZGQgc2l0dWF0aW9uIG9mIHJl
cG9ydGluZyBhIGNhcGFiaWxpdHkgb2YKYW5vdGhlciBjb21wb25lbnQuIFRoYXQncyBldmVuIG1v
cmUgb2YgYSBwcm9ibGVtIGZvciB0aGUgRG9tMApjYXNlLCB3aGVyZSB0aGUgYWZmZWN0ZWQgdG9v
bCAoa2R1bXApIGlzbid0IGV2ZW4gdW5kZXIgb3VyIGNvbnRyb2wKKGFuZCBzaG91bGRuJ3QgYmUp
LgoKQnV0IGluIHRoZSBlbmQgLSB3aGF0J3Mgd3Jvbmcgd2l0aCBhbHdheXMgKG9yIGNvbmRpdGlv
bmFsbHkgdXBvbiBhCkNPTkZJR18qIG9wdGlvbiBhbmQvb3IgY29tbWFuZCBsaW5lIHBhcmFtZXRl
ciBhbmQvb3IgbWVtb3J5CnNpemUpIGZpbGxpbmcgYm90aCB0aGUgb2xkIGFuZCBuZXcgc2hhcmVk
IGluZm8gZmllbGRzPyBBIGNhcGFibGUgdG9vbApjYW4gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIG5l
dyBvbmUgaXMgdmFsaWQsIGFuZCBhbiBpbmNhcGFibGUgdG9vbAp3b24ndCB3b3JrIG9uIGh1Z2Ug
bWVtb3J5IGNvbmZpZ3MgYW55d2F5LgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:42:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:42:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRF2-0003Gi-5j; Mon, 01 Dec 2014 13:42:16 +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 1XvRF0-0003Gd-Gn
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 13:42:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	00/F1-25276-5307C745; Mon, 01 Dec 2014 13:42:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417441333!12567385!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17121 invoked from network); 1 Dec 2014 13:42:13 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 13:42:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417441333; l=272;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:To:From:Date;
	bh=YjrR5trVKyxx3Fjlhc5+VXEwIF4=;
	b=v5gIbQkN6Va+Yu8PPnthAACS6o4o2vYTCekujtmpwg+8OPWZn1zNR2LQaB63J4noRKS
	G7PUprOz0CWST/G5EbYxN6QJaWBqRmx2d0bcUrObWgxIRVTO+GIHQVbSGJn4ITXaU7II9
	v1yhoyBVuk6x1QzYnUbmQzym04d09DYNviE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJxKkze/KnV3DKbeZ4a
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([89.204.135.68])
	by smtp.strato.de (RZmta 36.2 DYNA|AUTH)
	with ESMTPSA id u02923qB1DgDbgd
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate) for <xen-devel@lists.xen.org>;
	Mon, 1 Dec 2014 14:42:13 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 00D3C5016D; Mon,  1 Dec 2014 14:42:11 +0100 (CET)
Date: Mon, 1 Dec 2014 14:42:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20141201134211.GA25822@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141201133244.GA24600@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, Olaf Hering wrote:

> > # xl pci-attach domU 0000:01:10.0

"xl pci-attach -h" mentions [Virtual Slot], but the code does not seem
to handle an additional parameter, pciattach() ignores *vs.

What is the "Virtual Slot", why is it ignored?


Olaf

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:42:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:42:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRF2-0003Gi-5j; Mon, 01 Dec 2014 13:42:16 +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 1XvRF0-0003Gd-Gn
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 13:42:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	00/F1-25276-5307C745; Mon, 01 Dec 2014 13:42:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417441333!12567385!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17121 invoked from network); 1 Dec 2014 13:42:13 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 13:42:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417441333; l=272;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:To:From:Date;
	bh=YjrR5trVKyxx3Fjlhc5+VXEwIF4=;
	b=v5gIbQkN6Va+Yu8PPnthAACS6o4o2vYTCekujtmpwg+8OPWZn1zNR2LQaB63J4noRKS
	G7PUprOz0CWST/G5EbYxN6QJaWBqRmx2d0bcUrObWgxIRVTO+GIHQVbSGJn4ITXaU7II9
	v1yhoyBVuk6x1QzYnUbmQzym04d09DYNviE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJxKkze/KnV3DKbeZ4a
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([89.204.135.68])
	by smtp.strato.de (RZmta 36.2 DYNA|AUTH)
	with ESMTPSA id u02923qB1DgDbgd
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate) for <xen-devel@lists.xen.org>;
	Mon, 1 Dec 2014 14:42:13 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 00D3C5016D; Mon,  1 Dec 2014 14:42:11 +0100 (CET)
Date: Mon, 1 Dec 2014 14:42:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20141201134211.GA25822@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141201133244.GA24600@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, Olaf Hering wrote:

> > # xl pci-attach domU 0000:01:10.0

"xl pci-attach -h" mentions [Virtual Slot], but the code does not seem
to handle an additional parameter, pciattach() ignores *vs.

What is the "Virtual Slot", why is it ignored?


Olaf

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:53:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:53:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRP5-0003cs-Eb; Mon, 01 Dec 2014 13:52:39 +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 1XvRP3-0003bN-Oo
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 13:52:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C7/13-15461-5A27C745; Mon, 01 Dec 2014 13:52:37 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417441956!12586696!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18367 invoked from network); 1 Dec 2014 13:52:36 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 13:52:36 -0000
Received: by mail-wi0-f178.google.com with SMTP id hi2so17375658wib.11
	for <xen-devel@lists.xensource.com>;
	Mon, 01 Dec 2014 05:52: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:content-type:content-transfer-encoding;
	bh=aSkE38OyPD+VFq/WfCAYM6BtzuzKFyt2PNCIF0Ie5+0=;
	b=bJDU5iusmpFk3mYS7aZ8+62DlzsN93QVZJTd2Xci8fnnSR2AXSIxu1JYhN+VTymmSU
	0D0oWDYhqojsgKbcJjUxI7L/aqyLqUA3hhCNLlIU9LxsbNJGglW/SiOmUR61DDX8qESn
	l5BptZIze80wqK2L7d9wADi1n/26x99XvzqW9Wh7l9nNaLMP7UxvONh/blzbSHjDBIAD
	UUOGeFDe2+r21kc0EC74cZops07LJn0cOXsAdGAtz6LztW8jZmzO2Z7c8diYqcxMT7pS
	UlUhQOEfyFz+Muo+h+hQjHSR188qcI5J0756+W98PDhKiAXmRBxECdT9nMnOdhZgyZVe
	Sk1w==
X-Gm-Message-State: ALoCoQm+dwt8U08xJSJ+98+3YcoOgj6uq7LHLMvnTlglZ3bpiapUat7FLrUel5nUyN4sC6xvcLBf
X-Received: by 10.180.37.142 with SMTP id y14mr48611890wij.47.1417441956346;
	Mon, 01 Dec 2014 05:52:36 -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
	wz5sm27676516wjc.29.2014.12.01.05.52.34 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 01 Dec 2014 05:52:35 -0800 (PST)
Message-ID: <547C72CC.6050406@m2r.biz>
Date: Mon, 01 Dec 2014 14:53:16 +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: spice-devel@lists.freedesktop.org, 
	xen-devel <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Alon Levy <alevy@redhat.com>, gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] xorg crash on Fedora 21 xen hvm domUs with qxl (log
 with 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 my latest test with xen 4.5 and qemu 2.2 (from git) linux hvm domU 
(Fedora 21) has no more crashed without any useful information in log 
but was crashed only xorg on start:

> [    20.653] (EE)
> [    20.653] (EE) Backtrace:
> [    20.668] (EE) 0: /usr/libexec/Xorg.bin (OsLookupColor+0x119) 
> [0x59bf79]
> [    20.669] (EE) 1: /lib64/libc.so.6 (__restore_rt+0x0) [0x7fbba151a94f]
> [    20.669] (EE) 2: /lib64/libpixman-1.so.0 
> (_pixman_internal_only_get_implementation+0x2ce2b) [0x7fbba26d249b]
> [    20.670] (EE) 3: /lib64/libpixman-1.so.0 
> (_pixman_internal_only_get_implementation+0x2cf79) [0x7fbba26d2899]
> [    20.670] (EE) 4: /lib64/libpixman-1.so.0 
> (pixman_image_composite32+0x451) [0x7fbba261d711]
> [    20.670] (EE) 5: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
> (_init+0x47d0) [0x7fbb9c687d20]
> [    20.670] (EE) 6: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
> (_init+0x48df) [0x7fbb9c687e9f]
> [    20.671] (EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
> (_init+0xfa3a) [0x7fbb9c69e1aa]
> [    20.671] (EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
> (_init+0x1937d) [0x7fbb9c6b142d]
> [    20.671] (EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
> (_init+0x12c47) [0x7fbb9c6a4587]
> [    20.671] (EE) 10: /usr/libexec/Xorg.bin 
> (DamageRegionAppend+0x18b5) [0x5212e5]
> [    20.671] (EE) 11: /usr/libexec/Xorg.bin (miPaintWindow+0x1f6) 
> [0x579c16]
> [    20.671] (EE) 12: /usr/libexec/Xorg.bin (miWindowExposures+0x18f) 
> [0x57a4ef]
> [    20.672] (EE) 13: /usr/libexec/Xorg.bin 
> (miHandleValidateExposures+0x68) [0x590108]
> [    20.672] (EE) 14: /usr/libexec/Xorg.bin (MapWindow+0x18a) [0x4656fa]
> [    20.672] (EE) 15: /usr/libexec/Xorg.bin (ProcBadRequest+0x5f5) 
> [0x433d85]
> [    20.672] (EE) 16: /usr/libexec/Xorg.bin (SendErrorToClient+0x2f7) 
> [0x439027]
> [    20.672] (EE) 17: /usr/libexec/Xorg.bin (remove_fs_handlers+0x416) 
> [0x43d186]
> [    20.673] (EE) 18: /lib64/libc.so.6 (__libc_start_main+0xf0) 
> [0x7fbba1505fe0]
> [    20.673] (EE) 19: /usr/libexec/Xorg.bin (_start+0x29) [0x42761e]
> [    20.673] (EE) 20: ? (?+0x29) [0x29]
> [    20.673] (EE)
> [    20.673] (EE) Segmentation fault at address 0x7fbb9c67a000
> [    20.673] (EE)
> Fatal server error:
> [    20.673] (EE) Caught signal 11 (Segmentation fault). Server aborting
> [    20.673] (EE)
> [    20.673] (EE)

Full xorg log in attachment.
Can someone help me to solve this problem please?

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 Dec 01 13:53:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:53:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRP5-0003cs-Eb; Mon, 01 Dec 2014 13:52:39 +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 1XvRP3-0003bN-Oo
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 13:52:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C7/13-15461-5A27C745; Mon, 01 Dec 2014 13:52:37 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417441956!12586696!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18367 invoked from network); 1 Dec 2014 13:52:36 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 13:52:36 -0000
Received: by mail-wi0-f178.google.com with SMTP id hi2so17375658wib.11
	for <xen-devel@lists.xensource.com>;
	Mon, 01 Dec 2014 05:52: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:content-type:content-transfer-encoding;
	bh=aSkE38OyPD+VFq/WfCAYM6BtzuzKFyt2PNCIF0Ie5+0=;
	b=bJDU5iusmpFk3mYS7aZ8+62DlzsN93QVZJTd2Xci8fnnSR2AXSIxu1JYhN+VTymmSU
	0D0oWDYhqojsgKbcJjUxI7L/aqyLqUA3hhCNLlIU9LxsbNJGglW/SiOmUR61DDX8qESn
	l5BptZIze80wqK2L7d9wADi1n/26x99XvzqW9Wh7l9nNaLMP7UxvONh/blzbSHjDBIAD
	UUOGeFDe2+r21kc0EC74cZops07LJn0cOXsAdGAtz6LztW8jZmzO2Z7c8diYqcxMT7pS
	UlUhQOEfyFz+Muo+h+hQjHSR188qcI5J0756+W98PDhKiAXmRBxECdT9nMnOdhZgyZVe
	Sk1w==
X-Gm-Message-State: ALoCoQm+dwt8U08xJSJ+98+3YcoOgj6uq7LHLMvnTlglZ3bpiapUat7FLrUel5nUyN4sC6xvcLBf
X-Received: by 10.180.37.142 with SMTP id y14mr48611890wij.47.1417441956346;
	Mon, 01 Dec 2014 05:52:36 -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
	wz5sm27676516wjc.29.2014.12.01.05.52.34 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 01 Dec 2014 05:52:35 -0800 (PST)
Message-ID: <547C72CC.6050406@m2r.biz>
Date: Mon, 01 Dec 2014 14:53:16 +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: spice-devel@lists.freedesktop.org, 
	xen-devel <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Alon Levy <alevy@redhat.com>, gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] xorg crash on Fedora 21 xen hvm domUs with qxl (log
 with 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 my latest test with xen 4.5 and qemu 2.2 (from git) linux hvm domU 
(Fedora 21) has no more crashed without any useful information in log 
but was crashed only xorg on start:

> [    20.653] (EE)
> [    20.653] (EE) Backtrace:
> [    20.668] (EE) 0: /usr/libexec/Xorg.bin (OsLookupColor+0x119) 
> [0x59bf79]
> [    20.669] (EE) 1: /lib64/libc.so.6 (__restore_rt+0x0) [0x7fbba151a94f]
> [    20.669] (EE) 2: /lib64/libpixman-1.so.0 
> (_pixman_internal_only_get_implementation+0x2ce2b) [0x7fbba26d249b]
> [    20.670] (EE) 3: /lib64/libpixman-1.so.0 
> (_pixman_internal_only_get_implementation+0x2cf79) [0x7fbba26d2899]
> [    20.670] (EE) 4: /lib64/libpixman-1.so.0 
> (pixman_image_composite32+0x451) [0x7fbba261d711]
> [    20.670] (EE) 5: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
> (_init+0x47d0) [0x7fbb9c687d20]
> [    20.670] (EE) 6: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
> (_init+0x48df) [0x7fbb9c687e9f]
> [    20.671] (EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
> (_init+0xfa3a) [0x7fbb9c69e1aa]
> [    20.671] (EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
> (_init+0x1937d) [0x7fbb9c6b142d]
> [    20.671] (EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
> (_init+0x12c47) [0x7fbb9c6a4587]
> [    20.671] (EE) 10: /usr/libexec/Xorg.bin 
> (DamageRegionAppend+0x18b5) [0x5212e5]
> [    20.671] (EE) 11: /usr/libexec/Xorg.bin (miPaintWindow+0x1f6) 
> [0x579c16]
> [    20.671] (EE) 12: /usr/libexec/Xorg.bin (miWindowExposures+0x18f) 
> [0x57a4ef]
> [    20.672] (EE) 13: /usr/libexec/Xorg.bin 
> (miHandleValidateExposures+0x68) [0x590108]
> [    20.672] (EE) 14: /usr/libexec/Xorg.bin (MapWindow+0x18a) [0x4656fa]
> [    20.672] (EE) 15: /usr/libexec/Xorg.bin (ProcBadRequest+0x5f5) 
> [0x433d85]
> [    20.672] (EE) 16: /usr/libexec/Xorg.bin (SendErrorToClient+0x2f7) 
> [0x439027]
> [    20.672] (EE) 17: /usr/libexec/Xorg.bin (remove_fs_handlers+0x416) 
> [0x43d186]
> [    20.673] (EE) 18: /lib64/libc.so.6 (__libc_start_main+0xf0) 
> [0x7fbba1505fe0]
> [    20.673] (EE) 19: /usr/libexec/Xorg.bin (_start+0x29) [0x42761e]
> [    20.673] (EE) 20: ? (?+0x29) [0x29]
> [    20.673] (EE)
> [    20.673] (EE) Segmentation fault at address 0x7fbb9c67a000
> [    20.673] (EE)
> Fatal server error:
> [    20.673] (EE) Caught signal 11 (Segmentation fault). Server aborting
> [    20.673] (EE)
> [    20.673] (EE)

Full xorg log in attachment.
Can someone help me to solve this problem please?

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 Dec 01 13:57:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13: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 1XvRTO-0003oo-5a; Mon, 01 Dec 2014 13:57:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XvRTM-0003oi-VB
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 13:57:05 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B3/A3-27584-0B37C745; Mon, 01 Dec 2014 13:57:04 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417442223!10809590!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26512 invoked from network); 1 Dec 2014 13:57:03 -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; 1 Dec 2014 13:57:03 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:51769 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 1XvRQj-0000Kh-55; Mon, 01 Dec 2014 14:54:21 +0100
Date: Mon, 1 Dec 2014 14:57:02 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1299044479.20141201145702@eikelenboom.it>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141201134211.GA25822@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201134211.GA25822@aepfle.de>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first 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


Monday, December 1, 2014, 2:42:11 PM, you wrote:

> On Mon, Dec 01, Olaf Hering wrote:

>> > # xl pci-attach domU 0000:01:10.0

> "xl pci-attach -h" mentions [Virtual Slot], but the code does not seem
> to handle an additional parameter, pciattach() ignores *vs.

> What is the "Virtual Slot", why is it ignored?

Hmm the wiki also still mentions it: http://wiki.xen.org/wiki/Xen_PCI_Passthrough

It was the ability with xend + qemu-trad to be able to specify the slot to 
use in the guest for the pci device.

See docs/misc/vtd.txt .. that seems it has never been updated :-)

(together with passing through a multifunction devices as multifunction inside 
the guest this hasn't got implemented in neither libxl and qemu-xen.)

--
Sander

>From docs/misc/vtd.txt: 

VTd device hotplug:
-------------------

2 virtual PCI slots (6~7) are reserved in HVM guest to support VTd hotplug. If you have more VTd devices, only 2 of them can support hotplug. Usage is simple:

 1. List the VTd device by dom. You can see a VTd device 0:2:0.0 is inserted in the HVM domain's PCI slot 6. '''lspci''' inside the guest should see the same.

        [root@vt-vtd ~]# xm pci-list HVMDomainVtd
        VSlt domain   bus   slot   func
        0x6    0x0  0x02   0x00    0x0

 2. Detach the device from the guest by the physical BDF. Then HVM guest will receive a virtual PCI hot removal event to detach the physical device

        [root@vt-vtd ~]# xm pci-detach HVMDomainVtd 0:2:0.0

 3. Attach a PCI device to the guest by the physical BDF and desired virtual slot(optional). Following command would insert the physical device into guest's virtual slot 7

        [root@vt-vtd ~]# xm pci-attach HVMDomainVtd 0:2:0.0 7

    To specify options for the device, use -o or --options=. Following command would disable MSI-INTx translation for the device

        [root@vt-vtd ~]# xm pci-attach -o msitranslate=0 0:2:0.0 7






> Olaf




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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:57:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13: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 1XvRTO-0003oo-5a; Mon, 01 Dec 2014 13:57:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XvRTM-0003oi-VB
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 13:57:05 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B3/A3-27584-0B37C745; Mon, 01 Dec 2014 13:57:04 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417442223!10809590!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26512 invoked from network); 1 Dec 2014 13:57:03 -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; 1 Dec 2014 13:57:03 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:51769 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 1XvRQj-0000Kh-55; Mon, 01 Dec 2014 14:54:21 +0100
Date: Mon, 1 Dec 2014 14:57:02 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1299044479.20141201145702@eikelenboom.it>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141201134211.GA25822@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201134211.GA25822@aepfle.de>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first 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


Monday, December 1, 2014, 2:42:11 PM, you wrote:

> On Mon, Dec 01, Olaf Hering wrote:

>> > # xl pci-attach domU 0000:01:10.0

> "xl pci-attach -h" mentions [Virtual Slot], but the code does not seem
> to handle an additional parameter, pciattach() ignores *vs.

> What is the "Virtual Slot", why is it ignored?

Hmm the wiki also still mentions it: http://wiki.xen.org/wiki/Xen_PCI_Passthrough

It was the ability with xend + qemu-trad to be able to specify the slot to 
use in the guest for the pci device.

See docs/misc/vtd.txt .. that seems it has never been updated :-)

(together with passing through a multifunction devices as multifunction inside 
the guest this hasn't got implemented in neither libxl and qemu-xen.)

--
Sander

>From docs/misc/vtd.txt: 

VTd device hotplug:
-------------------

2 virtual PCI slots (6~7) are reserved in HVM guest to support VTd hotplug. If you have more VTd devices, only 2 of them can support hotplug. Usage is simple:

 1. List the VTd device by dom. You can see a VTd device 0:2:0.0 is inserted in the HVM domain's PCI slot 6. '''lspci''' inside the guest should see the same.

        [root@vt-vtd ~]# xm pci-list HVMDomainVtd
        VSlt domain   bus   slot   func
        0x6    0x0  0x02   0x00    0x0

 2. Detach the device from the guest by the physical BDF. Then HVM guest will receive a virtual PCI hot removal event to detach the physical device

        [root@vt-vtd ~]# xm pci-detach HVMDomainVtd 0:2:0.0

 3. Attach a PCI device to the guest by the physical BDF and desired virtual slot(optional). Following command would insert the physical device into guest's virtual slot 7

        [root@vt-vtd ~]# xm pci-attach HVMDomainVtd 0:2:0.0 7

    To specify options for the device, use -o or --options=. Following command would disable MSI-INTx translation for the device

        [root@vt-vtd ~]# xm pci-attach -o msitranslate=0 0:2:0.0 7






> Olaf




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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:59:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:59:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRVU-0003vN-MB; Mon, 01 Dec 2014 13:59:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XvRVS-0003vI-VB
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:59:15 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	90/09-27584-2347C745; Mon, 01 Dec 2014 13:59:14 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417442353!7477612!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15854 invoked from network); 1 Dec 2014 13:59:13 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 13:59:13 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so17423055wiw.10
	for <xen-devel@lists.xenproject.org>;
	Mon, 01 Dec 2014 05:59: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=YkgahIHaOsntqxhLQAzdW/qMS6Jgv/8rvQNey+apCmI=;
	b=lh8hQR8S8cL3zz33HbGqyL6/uWr1TZLtqWuZ4MsC8v/wqvfHiJLoTNfjxufonnNfMr
	QP19A3zFg27MQrpXdgu+Hwqj86qVqVD055YXro3AXPOCTetWOdBiMlo423wH3VM+qhS/
	WAMJ2YUPaNH5TEbGepTCJ6BTU3L1dqqrNF95ha3orXxqrZqJdmHlY/h3USppTCGkC5rx
	SslKpr0aO+XZAIZyE6iPdJCALHv05BvjU+n1qjB/3Osz5ZO/pCmZGUIWutLwtzdsgwAr
	ScCLj+gpj5l1R2RbUDeSTQa8WlRW3xTbZlju8GnHy9F/W43W1YRYMQtbCuLL4kabCWZi
	nGZQ==
X-Gm-Message-State: ALoCoQnL3y0HTM7XxeAtU4oO4bKGh80IIkclkInnzM4YKQdZN5uUvXmFzvnJ+JWu7qvUmQxAtAQm
X-Received: by 10.180.95.37 with SMTP id dh5mr84872314wib.64.1417442353182;
	Mon, 01 Dec 2014 05:59:13 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id ej10sm2876444wib.1.2014.12.01.05.59.11
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 01 Dec 2014 05:59:12 -0800 (PST)
Message-ID: <547C742E.6060801@linaro.org>
Date: Mon, 01 Dec 2014 13:59:10 +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>, 
	Stefan Bader <stefan.bader@canonical.com>,
	Zoltan Kiss <zoltan.kiss@citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>	<547C2CFC.7060908@canonical.com>
	<547C6EF6.8020604@citrix.com>
In-Reply-To: <547C6EF6.8020604@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 01/12/14 13:36, David Vrabel wrote:
> On 01/12/14 08:55, Stefan Bader wrote:
>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>> There is a long known problem with the netfront/netback interface: if the guest
>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
>>> it gets dropped. The reason is that netback maps these slots to a frag in the
>>> frags array, which is limited by size. Having so many slots can occur since
>>> compound pages were introduced, as the ring protocol slice them up into
>>> individual (non-compound) page aligned slots. The theoretical worst case
>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
>>> using 2 slots
>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
>>> end and the beginning of a page, therefore they use 3 * 15 = 45 slots
>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
>>> Although I don't think this 51 slots skb can really happen, we need a solution
>>> which can deal with every scenario. In real life there is only a few slots
>>> overdue, but usually it causes the TCP stream to be blocked, as the retry will
>>> most likely have the same buffer layout.
>>> This patch solves this problem by linearizing the packet. This is not the
>>> fastest way, and it can fail much easier as it tries to allocate a big linear
>>> area for the whole packet, but probably easier by an order of magnitude than
>>> anything else. Probably this code path is not touched very frequently anyway.
>>>
>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>> Cc: netdev@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Cc: xen-devel@lists.xenproject.org
>>
>> This does not seem to be marked explicitly as stable. Has someone already asked
>> David Miller to put it on his stable queue? IMO it qualifies quite well and the
>> actual change should be simple to pick/backport.
>
> I think it's a candidate, yes.
>
> Can you expand on the user visible impact of the bug this patch fixes?
> I think it results in certain types of traffic not working (because the
> domU always generates skb's with the problematic frag layout), but I
> can't remember the details.

Yes, this line in the comment talks about it: "In real life there is 
only a few slots overdue, but usually it causes the TCP stream to be 
blocked, as the retry will most likely have the same buffer layout."
Maybe we can add what kind of traffic triggered this so far, AFAIK NFS 
was one of them, and Stefan had an another use case. But my memories are 
blur about this.

Zoli

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 13:59:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 13:59:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRVU-0003vN-MB; Mon, 01 Dec 2014 13:59:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XvRVS-0003vI-VB
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 13:59:15 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	90/09-27584-2347C745; Mon, 01 Dec 2014 13:59:14 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417442353!7477612!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15854 invoked from network); 1 Dec 2014 13:59:13 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 13:59:13 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so17423055wiw.10
	for <xen-devel@lists.xenproject.org>;
	Mon, 01 Dec 2014 05:59: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=YkgahIHaOsntqxhLQAzdW/qMS6Jgv/8rvQNey+apCmI=;
	b=lh8hQR8S8cL3zz33HbGqyL6/uWr1TZLtqWuZ4MsC8v/wqvfHiJLoTNfjxufonnNfMr
	QP19A3zFg27MQrpXdgu+Hwqj86qVqVD055YXro3AXPOCTetWOdBiMlo423wH3VM+qhS/
	WAMJ2YUPaNH5TEbGepTCJ6BTU3L1dqqrNF95ha3orXxqrZqJdmHlY/h3USppTCGkC5rx
	SslKpr0aO+XZAIZyE6iPdJCALHv05BvjU+n1qjB/3Osz5ZO/pCmZGUIWutLwtzdsgwAr
	ScCLj+gpj5l1R2RbUDeSTQa8WlRW3xTbZlju8GnHy9F/W43W1YRYMQtbCuLL4kabCWZi
	nGZQ==
X-Gm-Message-State: ALoCoQnL3y0HTM7XxeAtU4oO4bKGh80IIkclkInnzM4YKQdZN5uUvXmFzvnJ+JWu7qvUmQxAtAQm
X-Received: by 10.180.95.37 with SMTP id dh5mr84872314wib.64.1417442353182;
	Mon, 01 Dec 2014 05:59:13 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id ej10sm2876444wib.1.2014.12.01.05.59.11
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 01 Dec 2014 05:59:12 -0800 (PST)
Message-ID: <547C742E.6060801@linaro.org>
Date: Mon, 01 Dec 2014 13:59:10 +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>, 
	Stefan Bader <stefan.bader@canonical.com>,
	Zoltan Kiss <zoltan.kiss@citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>	<547C2CFC.7060908@canonical.com>
	<547C6EF6.8020604@citrix.com>
In-Reply-To: <547C6EF6.8020604@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 01/12/14 13:36, David Vrabel wrote:
> On 01/12/14 08:55, Stefan Bader wrote:
>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>> There is a long known problem with the netfront/netback interface: if the guest
>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
>>> it gets dropped. The reason is that netback maps these slots to a frag in the
>>> frags array, which is limited by size. Having so many slots can occur since
>>> compound pages were introduced, as the ring protocol slice them up into
>>> individual (non-compound) page aligned slots. The theoretical worst case
>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
>>> using 2 slots
>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
>>> end and the beginning of a page, therefore they use 3 * 15 = 45 slots
>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
>>> Although I don't think this 51 slots skb can really happen, we need a solution
>>> which can deal with every scenario. In real life there is only a few slots
>>> overdue, but usually it causes the TCP stream to be blocked, as the retry will
>>> most likely have the same buffer layout.
>>> This patch solves this problem by linearizing the packet. This is not the
>>> fastest way, and it can fail much easier as it tries to allocate a big linear
>>> area for the whole packet, but probably easier by an order of magnitude than
>>> anything else. Probably this code path is not touched very frequently anyway.
>>>
>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>> Cc: netdev@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Cc: xen-devel@lists.xenproject.org
>>
>> This does not seem to be marked explicitly as stable. Has someone already asked
>> David Miller to put it on his stable queue? IMO it qualifies quite well and the
>> actual change should be simple to pick/backport.
>
> I think it's a candidate, yes.
>
> Can you expand on the user visible impact of the bug this patch fixes?
> I think it results in certain types of traffic not working (because the
> domU always generates skb's with the problematic frag layout), but I
> can't remember the details.

Yes, this line in the comment talks about it: "In real life there is 
only a few slots overdue, but usually it causes the TCP stream to be 
blocked, as the retry will most likely have the same buffer layout."
Maybe we can add what kind of traffic triggered this so far, AFAIK NFS 
was one of them, and Stefan had an another use case. But my memories are 
blur about this.

Zoli

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:14:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:14:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRjV-0004Kz-6f; Mon, 01 Dec 2014 14:13:45 +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 1XvRjT-0004Kr-BG
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 14:13:43 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	6D/C3-02696-6977C745; Mon, 01 Dec 2014 14:13:42 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417443221!12229563!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5178 invoked from network); 1 Dec 2014 14:13:41 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	1 Dec 2014 14:13:41 -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 1XvRjO-0007az-Ns; Mon, 01 Dec 2014 14:13:38 +0000
Message-ID: <547C7791.3090206@canonical.com>
Date: Mon, 01 Dec 2014 15:13:37 +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>, 
	David Vrabel <david.vrabel@citrix.com>,
	Zoltan Kiss <zoltan.kiss@citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>	<547C2CFC.7060908@canonical.com>
	<547C6EF6.8020604@citrix.com> <547C742E.6060801@linaro.org>
In-Reply-To: <547C742E.6060801@linaro.org>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3352691566862968440=="
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)
--===============3352691566862968440==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="CfN5ETO1kIBvIu4GSFgCuofkmW9bBCxxT"

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

On 01.12.2014 14:59, Zoltan Kiss wrote:
>=20
>=20
> On 01/12/14 13:36, David Vrabel wrote:
>> On 01/12/14 08:55, Stefan Bader wrote:
>>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>>> There is a long known problem with the netfront/netback interface: i=
f the guest
>>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 =
ring slots,
>>>> it gets dropped. The reason is that netback maps these slots to a fr=
ag in the
>>>> frags array, which is limited by size. Having so many slots can occu=
r since
>>>> compound pages were introduced, as the ring protocol slice them up i=
nto
>>>> individual (non-compound) page aligned slots. The theoretical worst =
case
>>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page bo=
undary,
>>>> using 2 slots
>>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes a=
re at the
>>>> end and the beginning of a page, therefore they use 3 * 15 =3D 45 sl=
ots
>>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 sl=
ots
>>>> Although I don't think this 51 slots skb can really happen, we need =
a solution
>>>> which can deal with every scenario. In real life there is only a few=
 slots
>>>> overdue, but usually it causes the TCP stream to be blocked, as the =
retry will
>>>> most likely have the same buffer layout.
>>>> This patch solves this problem by linearizing the packet. This is no=
t the
>>>> fastest way, and it can fail much easier as it tries to allocate a b=
ig linear
>>>> area for the whole packet, but probably easier by an order of magnit=
ude than
>>>> anything else. Probably this code path is not touched very frequentl=
y anyway.
>>>>
>>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>>> Cc: netdev@vger.kernel.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Cc: xen-devel@lists.xenproject.org
>>>
>>> This does not seem to be marked explicitly as stable. Has someone alr=
eady asked
>>> David Miller to put it on his stable queue? IMO it qualifies quite we=
ll and the
>>> actual change should be simple to pick/backport.
>>
>> I think it's a candidate, yes.
>>
>> Can you expand on the user visible impact of the bug this patch fixes?=

>> I think it results in certain types of traffic not working (because th=
e
>> domU always generates skb's with the problematic frag layout), but I
>> can't remember the details.
>=20
> Yes, this line in the comment talks about it: "In real life there is on=
ly a few
> slots overdue, but usually it causes the TCP stream to be blocked, as t=
he retry
> will most likely have the same buffer layout."
> Maybe we can add what kind of traffic triggered this so far, AFAIK NFS =
was one
> of them, and Stefan had an another use case. But my memories are blur a=
bout this.

We had some report about some web-app hitting packet losses. I suspect th=
at also
was streaming something. For a easy trigger we found redis-benchmark (par=
t of
the redis keyserver) with a larger (iirc 1kB) payload would trigger the
fragmentation/exceeding pages to happen. Though I think it did not fail b=
ut
showed a performance drop instead (from memory which also suffers from lo=
osing
detail).

-Stefan
>=20
> Zoli



--CfN5ETO1kIBvIu4GSFgCuofkmW9bBCxxT
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

iQIcBAEBCgAGBQJUfHeRAAoJEOhnXe7L7s6j6z8P/1+ExBbkBFehdN9vJK8WF8CG
2GpL4Ib5/MxoN3L7J5Lj7jXgPn5zAuK402phk4YbOWrTfhUjQZ3UMrEHc1GRpP5Q
dfaSKwSSDAHSuMv5NCvpPK0CrhvxbODNV7V3qU1n3zSSNoY4dHEB1AChVC3qHkxq
ox/LypqTBNRZbc+HO8gcWWHYRLMDwrKpsXiWQiwuKctbZzgJD/mvZC1O5kVHwmoX
FT8xFh8zoxYdzXbWfULcCHhFbdePldfrPCzH22CNy/clau7TCHlHk85IVt91zrHG
KWB8oBhl6bshjngRklZfbK3i1Vr5JcyI9kPziGDlDWV5BJylEDDVahqu2MIt1nxN
+Zi9S5VIq/aGvdajT6wnVBr19vGHF2aY7nI3N3QFMjXVraX1fMB0VGggCFFwaGgU
g4S9RpchwUXehV/3XUAQHYQqHCUeGVoV4hCkWtDzLN6xPlH8u0ozzfJwhpw6r57e
7rqy8nFPY/tW7IbIb82Qoiedwh1D7XWR0T3IZSeXOsZ0SfWaaA3NRK4hdjWSPGPT
MbkNK7kGjrEK7DVkfI27xmjOqJmVXP4KwClF7qRZsZlWUV4bMdDtWiRAitnoatsT
RTqQBk6fNcwu8NL6xQ8QMVecfRtQ6cFQ4IAvOkbQwapqWbnJkebHfkVmHsx5Blqe
8cPN8fjESBKigfsRbv+6
=st42
-----END PGP SIGNATURE-----

--CfN5ETO1kIBvIu4GSFgCuofkmW9bBCxxT--


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

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

--===============3352691566862968440==--


From xen-devel-bounces@lists.xen.org Mon Dec 01 14:14:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:14:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRjV-0004Kz-6f; Mon, 01 Dec 2014 14:13:45 +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 1XvRjT-0004Kr-BG
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 14:13:43 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	6D/C3-02696-6977C745; Mon, 01 Dec 2014 14:13:42 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417443221!12229563!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5178 invoked from network); 1 Dec 2014 14:13:41 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	1 Dec 2014 14:13:41 -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 1XvRjO-0007az-Ns; Mon, 01 Dec 2014 14:13:38 +0000
Message-ID: <547C7791.3090206@canonical.com>
Date: Mon, 01 Dec 2014 15:13:37 +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>, 
	David Vrabel <david.vrabel@citrix.com>,
	Zoltan Kiss <zoltan.kiss@citrix.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>	<547C2CFC.7060908@canonical.com>
	<547C6EF6.8020604@citrix.com> <547C742E.6060801@linaro.org>
In-Reply-To: <547C742E.6060801@linaro.org>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3352691566862968440=="
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)
--===============3352691566862968440==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="CfN5ETO1kIBvIu4GSFgCuofkmW9bBCxxT"

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

On 01.12.2014 14:59, Zoltan Kiss wrote:
>=20
>=20
> On 01/12/14 13:36, David Vrabel wrote:
>> On 01/12/14 08:55, Stefan Bader wrote:
>>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>>> There is a long known problem with the netfront/netback interface: i=
f the guest
>>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 =
ring slots,
>>>> it gets dropped. The reason is that netback maps these slots to a fr=
ag in the
>>>> frags array, which is limited by size. Having so many slots can occu=
r since
>>>> compound pages were introduced, as the ring protocol slice them up i=
nto
>>>> individual (non-compound) page aligned slots. The theoretical worst =
case
>>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page bo=
undary,
>>>> using 2 slots
>>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes a=
re at the
>>>> end and the beginning of a page, therefore they use 3 * 15 =3D 45 sl=
ots
>>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 sl=
ots
>>>> Although I don't think this 51 slots skb can really happen, we need =
a solution
>>>> which can deal with every scenario. In real life there is only a few=
 slots
>>>> overdue, but usually it causes the TCP stream to be blocked, as the =
retry will
>>>> most likely have the same buffer layout.
>>>> This patch solves this problem by linearizing the packet. This is no=
t the
>>>> fastest way, and it can fail much easier as it tries to allocate a b=
ig linear
>>>> area for the whole packet, but probably easier by an order of magnit=
ude than
>>>> anything else. Probably this code path is not touched very frequentl=
y anyway.
>>>>
>>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>>> Cc: netdev@vger.kernel.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Cc: xen-devel@lists.xenproject.org
>>>
>>> This does not seem to be marked explicitly as stable. Has someone alr=
eady asked
>>> David Miller to put it on his stable queue? IMO it qualifies quite we=
ll and the
>>> actual change should be simple to pick/backport.
>>
>> I think it's a candidate, yes.
>>
>> Can you expand on the user visible impact of the bug this patch fixes?=

>> I think it results in certain types of traffic not working (because th=
e
>> domU always generates skb's with the problematic frag layout), but I
>> can't remember the details.
>=20
> Yes, this line in the comment talks about it: "In real life there is on=
ly a few
> slots overdue, but usually it causes the TCP stream to be blocked, as t=
he retry
> will most likely have the same buffer layout."
> Maybe we can add what kind of traffic triggered this so far, AFAIK NFS =
was one
> of them, and Stefan had an another use case. But my memories are blur a=
bout this.

We had some report about some web-app hitting packet losses. I suspect th=
at also
was streaming something. For a easy trigger we found redis-benchmark (par=
t of
the redis keyserver) with a larger (iirc 1kB) payload would trigger the
fragmentation/exceeding pages to happen. Though I think it did not fail b=
ut
showed a performance drop instead (from memory which also suffers from lo=
osing
detail).

-Stefan
>=20
> Zoli



--CfN5ETO1kIBvIu4GSFgCuofkmW9bBCxxT
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

iQIcBAEBCgAGBQJUfHeRAAoJEOhnXe7L7s6j6z8P/1+ExBbkBFehdN9vJK8WF8CG
2GpL4Ib5/MxoN3L7J5Lj7jXgPn5zAuK402phk4YbOWrTfhUjQZ3UMrEHc1GRpP5Q
dfaSKwSSDAHSuMv5NCvpPK0CrhvxbODNV7V3qU1n3zSSNoY4dHEB1AChVC3qHkxq
ox/LypqTBNRZbc+HO8gcWWHYRLMDwrKpsXiWQiwuKctbZzgJD/mvZC1O5kVHwmoX
FT8xFh8zoxYdzXbWfULcCHhFbdePldfrPCzH22CNy/clau7TCHlHk85IVt91zrHG
KWB8oBhl6bshjngRklZfbK3i1Vr5JcyI9kPziGDlDWV5BJylEDDVahqu2MIt1nxN
+Zi9S5VIq/aGvdajT6wnVBr19vGHF2aY7nI3N3QFMjXVraX1fMB0VGggCFFwaGgU
g4S9RpchwUXehV/3XUAQHYQqHCUeGVoV4hCkWtDzLN6xPlH8u0ozzfJwhpw6r57e
7rqy8nFPY/tW7IbIb82Qoiedwh1D7XWR0T3IZSeXOsZ0SfWaaA3NRK4hdjWSPGPT
MbkNK7kGjrEK7DVkfI27xmjOqJmVXP4KwClF7qRZsZlWUV4bMdDtWiRAitnoatsT
RTqQBk6fNcwu8NL6xQ8QMVecfRtQ6cFQ4IAvOkbQwapqWbnJkebHfkVmHsx5Blqe
8cPN8fjESBKigfsRbv+6
=st42
-----END PGP SIGNATURE-----

--CfN5ETO1kIBvIu4GSFgCuofkmW9bBCxxT--


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

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

--===============3352691566862968440==--


From xen-devel-bounces@lists.xen.org Mon Dec 01 14:15:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:15:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRkk-0004Pd-Mf; Mon, 01 Dec 2014 14:15:02 +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 1XvRkj-0004PV-72
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 14:15:01 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	4A/7B-27785-4E77C745; Mon, 01 Dec 2014 14:15:00 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417443298!7569761!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 27694 invoked from network); 1 Dec 2014 14:14:59 -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 Dec 2014 14:14:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198075466"
Message-ID: <547C77E0.5060607@citrix.com>
Date: Mon, 1 Dec 2014 14:14:56 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	<xen-devel@lists.xenproject.org>, <linux-kernel@vger.kernel.org>,
	<linux-pci@vger.kernel.org>, <bhelgaas@google.com>, <linux@eikelenboom.it>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
	<1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
X-DLP: MIA1
Subject: Re: [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>
Content-Type: text/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 22:17, Konrad Rzeszutek Wilk wrote:
> 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");

Why dev_info when...

> @@ -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");

... this one is dev_warn?

> +	else {
> +		__pci_reset_function_locked(dev);

I think the reset should always be attempted regardless of whether the
correct state was loaded or not.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:15:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:15:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRkk-0004Pd-Mf; Mon, 01 Dec 2014 14:15:02 +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 1XvRkj-0004PV-72
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 14:15:01 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	4A/7B-27785-4E77C745; Mon, 01 Dec 2014 14:15:00 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417443298!7569761!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 27694 invoked from network); 1 Dec 2014 14:14:59 -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 Dec 2014 14:14:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198075466"
Message-ID: <547C77E0.5060607@citrix.com>
Date: Mon, 1 Dec 2014 14:14:56 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	<xen-devel@lists.xenproject.org>, <linux-kernel@vger.kernel.org>,
	<linux-pci@vger.kernel.org>, <bhelgaas@google.com>, <linux@eikelenboom.it>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
	<1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
X-DLP: MIA1
Subject: Re: [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>
Content-Type: text/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 22:17, Konrad Rzeszutek Wilk wrote:
> 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");

Why dev_info when...

> @@ -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");

... this one is dev_warn?

> +	else {
> +		__pci_reset_function_locked(dev);

I think the reset should always be attempted regardless of whether the
correct state was loaded or not.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:21:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRr5-0004jf-Ik; Mon, 01 Dec 2014 14:21:35 +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 1XvRr4-0004ja-EU
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:21:34 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4D/6F-25276-D697C745; Mon, 01 Dec 2014 14:21:33 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417443692!12570372!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24495 invoked from network); 1 Dec 2014 14:21:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 14:21:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="27313405"
From: Euan Harris <euan.harris@citrix.com>
To: <Ian.Campbell@citrix.com>
Date: Mon, 1 Dec 2014 14:21:05 +0000
Message-ID: <1417443665-30809-1-git-send-email-euan.harris@citrix.com>
X-Mailer: git-send-email 1.7.1
In-Reply-To: <1417435968.29138.19.camel@citrix.com>
References: <1417435968.29138.19.camel@citrix.com>
MIME-Version: 1.0
X-DLP: AMS1
Cc: Euan Harris <euan.harris@citrix.com>, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2] tools/Rules.mk: Don't optimize debug builds;
	add macro debugging 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

Tools debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk.   Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library.   Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.

Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations.   This is useful as libxl uses many
non-trivial macros.

Signed-off-by: Euan Harris <euan.harris@citrix.com>

Changes since v1:
  * moved flag override to tools/Rules.mk so it affects all tools
---
 tools/Rules.mk |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 87a56dc..7ef1ce5 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -54,6 +54,11 @@ CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN)
 LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan
 SHLIB_libxenvchan  = -Wl,-rpath-link=$(XEN_LIBVCHAN)
 
+ifeq ($(debug),y)
+# Disable optimizations and debugging information for macros
+CFLAGS += -O0 -g3
+endif
+
 LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
 
 ifeq ($(LIBXL_BLKTAP),y)
-- 
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 Dec 01 14:21:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRr5-0004jf-Ik; Mon, 01 Dec 2014 14:21:35 +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 1XvRr4-0004ja-EU
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:21:34 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4D/6F-25276-D697C745; Mon, 01 Dec 2014 14:21:33 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417443692!12570372!1
X-Originating-IP: [185.25.65.24]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24495 invoked from network); 1 Dec 2014 14:21:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 14:21:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="27313405"
From: Euan Harris <euan.harris@citrix.com>
To: <Ian.Campbell@citrix.com>
Date: Mon, 1 Dec 2014 14:21:05 +0000
Message-ID: <1417443665-30809-1-git-send-email-euan.harris@citrix.com>
X-Mailer: git-send-email 1.7.1
In-Reply-To: <1417435968.29138.19.camel@citrix.com>
References: <1417435968.29138.19.camel@citrix.com>
MIME-Version: 1.0
X-DLP: AMS1
Cc: Euan Harris <euan.harris@citrix.com>, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2] tools/Rules.mk: Don't optimize debug builds;
	add macro debugging 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

Tools debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk.   Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library.   Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.

Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations.   This is useful as libxl uses many
non-trivial macros.

Signed-off-by: Euan Harris <euan.harris@citrix.com>

Changes since v1:
  * moved flag override to tools/Rules.mk so it affects all tools
---
 tools/Rules.mk |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 87a56dc..7ef1ce5 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -54,6 +54,11 @@ CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN)
 LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan
 SHLIB_libxenvchan  = -Wl,-rpath-link=$(XEN_LIBVCHAN)
 
+ifeq ($(debug),y)
+# Disable optimizations and debugging information for macros
+CFLAGS += -O0 -g3
+endif
+
 LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
 
 ifeq ($(LIBXL_BLKTAP),y)
-- 
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 Dec 01 14:24:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14: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 1XvRtP-0004zu-8v; Mon, 01 Dec 2014 14:23:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XvRtO-0004zo-21
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 14:23:58 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	AD/91-01660-DF97C745; Mon, 01 Dec 2014 14:23:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417443834!10820257!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 4591 invoked from network); 1 Dec 2014 14:23:56 -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;
	1 Dec 2014 14:23:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198404655"
Message-ID: <547C79C0.4010608@citrix.com>
Date: Mon, 1 Dec 2014 14:22:56 +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: Anthony Wright <anthony@overnetdata.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <5478926A.80503@overnetdata.com>
In-Reply-To: <5478926A.80503@overnetdata.com>
X-DLP: MIA2
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/14 15:19, Anthony Wright wrote:
> 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

The guest's frontend driver isn't putting valid requests onto the ring
(it crosses a page boundary) so this is a frontend bug.

What guest are you running?

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:24:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14: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 1XvRtP-0004zu-8v; Mon, 01 Dec 2014 14:23:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XvRtO-0004zo-21
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 14:23:58 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	AD/91-01660-DF97C745; Mon, 01 Dec 2014 14:23:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417443834!10820257!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 4591 invoked from network); 1 Dec 2014 14:23:56 -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;
	1 Dec 2014 14:23:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198404655"
Message-ID: <547C79C0.4010608@citrix.com>
Date: Mon, 1 Dec 2014 14:22:56 +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: Anthony Wright <anthony@overnetdata.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <5478926A.80503@overnetdata.com>
In-Reply-To: <5478926A.80503@overnetdata.com>
X-DLP: MIA2
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/14 15:19, Anthony Wright wrote:
> 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

The guest's frontend driver isn't putting valid requests onto the ring
(it crosses a page boundary) so this is a frontend bug.

What guest are you running?

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:27:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:27:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRwp-00059l-SQ; Mon, 01 Dec 2014 14:27:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <euan.harris@citrix.com>) id 1XvRwp-00059f-EP
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:27:31 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	E0/D1-22777-2DA7C745; Mon, 01 Dec 2014 14:27:30 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417444049!10885762!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28743 invoked from network); 1 Dec 2014 14:27:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 14:27:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="27313681"
From: Euan Harris <euan.harris@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 14:27:06 +0000
Message-ID: <1417444026-31044-1-git-send-email-euan.harris@citrix.com>
X-Mailer: git-send-email 1.7.1
MIME-Version: 1.0
X-DLP: AMS1
Cc: Euan Harris <euan.harris@citrix.com>, Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: Don't derefence null new_name pointer in
	libxl_domain_rename()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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() unconditionally dereferences its new_name
parameter, to check whether it is an empty string.   Add a check to
avoid a segfault if new_name is null.

Signed-off-by: Euan Harris <euan.harris@citrix.com>
---
 tools/libxl/libxl.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f84f7c2..6e84b5d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -385,6 +385,13 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
         }
     }
 
+    if (!new_name) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                        "new domain name not specified");
+        rc = ERROR_INVAL;
+        goto x_rc;
+    }
+
     if (new_name[0]) {
         /* nonempty names must be unique */
         uint32_t domid_e;
-- 
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 Dec 01 14:27:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:27:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvRwp-00059l-SQ; Mon, 01 Dec 2014 14:27:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <euan.harris@citrix.com>) id 1XvRwp-00059f-EP
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:27:31 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	E0/D1-22777-2DA7C745; Mon, 01 Dec 2014 14:27:30 +0000
X-Env-Sender: euan.harris@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417444049!10885762!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28743 invoked from network); 1 Dec 2014 14:27:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 14:27:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="27313681"
From: Euan Harris <euan.harris@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 14:27:06 +0000
Message-ID: <1417444026-31044-1-git-send-email-euan.harris@citrix.com>
X-Mailer: git-send-email 1.7.1
MIME-Version: 1.0
X-DLP: AMS1
Cc: Euan Harris <euan.harris@citrix.com>, Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl: Don't derefence null new_name pointer in
	libxl_domain_rename()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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() unconditionally dereferences its new_name
parameter, to check whether it is an empty string.   Add a check to
avoid a segfault if new_name is null.

Signed-off-by: Euan Harris <euan.harris@citrix.com>
---
 tools/libxl/libxl.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f84f7c2..6e84b5d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -385,6 +385,13 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
         }
     }
 
+    if (!new_name) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                        "new domain name not specified");
+        rc = ERROR_INVAL;
+        goto x_rc;
+    }
+
     if (new_name[0]) {
         /* nonempty names must be unique */
         uint32_t domid_e;
-- 
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 Dec 01 14:33:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14: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 1XvS2J-0005SF-NJ; Mon, 01 Dec 2014 14:33:11 +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 1XvS2I-0005S9-Cm
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 14:33:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	1B/EA-09842-52C7C745; Mon, 01 Dec 2014 14:33:09 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417444388!12575114!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 5242 invoked from network); 1 Dec 2014 14:33:08 -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; 1 Dec 2014 14:33:08 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id CC209ACF9;
	Mon,  1 Dec 2014 14:33:07 +0000 (UTC)
Message-ID: <547C7C22.4020601@suse.com>
Date: Mon, 01 Dec 2014 15:33: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: Jan Beulich <JBeulich@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>	
	<1417426153-12893-2-git-send-email-jgross@suse.com>	
	<547C4DD6020000780004BA83@mail.emea.novell.com>	
	<547C4ECB.7070702@citrix.com>
	<547C5F31020000780004BB1F@suse.com>	 <547C68FD.60000@suse.com>
	<547C7D13020000780004BC3D@suse.com>
In-Reply-To: <547C7D13020000780004BC3D@suse.com>
Content-Length: 5561
Cc: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [Patch V2] 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: 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

T24gMTIvMDEvMjAxNCAwMjozNyBQTSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4gT24gMDEuMTIu
MTQgYXQgMTQ6MTEsIDxKR3Jvc3NAc3VzZS5jb20+IHdyb3RlOgo+PiBPbiAxMi8wMS8yMDE0IDEy
OjI5IFBNLCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+IE9uIDAxLjEyLjE0IGF0IDEyOjE5LCA8
ZGF2aWQudnJhYmVsQGNpdHJpeC5jb20+IHdyb3RlOgo+Pj4+IE9uIDAxLzEyLzE0IDEwOjE1LCBK
YW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+Pj4gT24gMDEuMTIuMTQgYXQgMTA6MjksIDxKR3Jvc3NA
c3VzZS5jb20+IHdyb3RlOgo+Pj4+Pj4gVGhlIHg4NiBzdHJ1Y3QgYXJjaF9zaGFyZWRfaW5mbyBm
aWVsZCBwZm5fdG9fbWZuX2ZyYW1lX2xpc3RfbGlzdAo+Pj4+Pj4gY3VycmVudGx5IGNvbnRhaW5z
IHRoZSBtZm4gb2YgdGhlIHRvcCBsZXZlbCBwYWdlIGZyYW1lIG9mIHRoZSAzIGxldmVsCj4+Pj4+
PiBwMm0gdHJlZSwgd2hpY2ggaXMgdXNlZCBieSB0aGUgWGVuIHRvb2xzIGR1cmluZyBzYXZpbmcg
YW5kIHJlc3RvcmluZwo+Pj4+Pj4gKGFuZCBsaXZlIG1pZ3JhdGlvbikgb2YgcHYgZG9tYWlucyBh
bmQgZm9yIGNyYXNoIGR1bXAgYW5hbHlzaXMuIFdpdGgKPj4+Pj4+IHRocmVlIGxldmVscyBvZiB0
aGUgcDJtIHRyZWUgaXQgaXMgcG9zc2libGUgdG8gc3VwcG9ydCB1cCB0byA1MTIgR0Igb2YKPj4+
Pj4+IFJBTSBmb3IgYSA2NCBiaXQgcHYgZG9tYWluLgo+Pj4+Pj4KPj4+Pj4+IEEgMzIgYml0IHB2
IGRvbWFpbiBjYW4gc3VwcG9ydCBtb3JlLCBhcyBlYWNoIG1lbW9yeSBwYWdlIGNhbiBob2xkIDEw
MjQKPj4+Pj4+IGluc3RlYWQgb2YgNTEyIGVudHJpZXMsIGxlYWRpbmcgdG8gYSBsaW1pdCBvZiA0
IFRCLgo+Pj4+Pj4KPj4+Pj4+IFRvIGJlIGFibGUgdG8gc3VwcG9ydCBtb3JlIFJBTSBvbiB4ODYt
NjQgc3dpdGNoIHRvIGEgdmlydHVhbCBtYXBwZWQKPj4+Pj4+IHAybSBsaXN0Lgo+Pj4+Pj4KPj4+
Pj4+IFRoaXMgcGF0Y2ggZXhwYW5kcyBzdHJ1Y3QgYXJjaF9zaGFyZWRfaW5mbyB3aXRoIGEgbmV3
IHAybSBsaXN0IHZpcnR1YWwKPj4+Pj4+IGFkZHJlc3MsIHRoZSByb290IG9mIHRoZSBwYWdlIHRh
YmxlIHJvb3QgYW5kIGEgcDJtIGdlbmVyYXRpb24gY291bnQuCj4+Pj4+PiBUaGUgbmV3IGluZm9y
bWF0aW9uIGlzIGluZGljYXRlZCBieSB0aGUgZG9tYWluIHRvIGJlIHZhbGlkIGJ5IHN0b3JpbmcK
Pj4+Pj4+IH4wVUwgaW50byBwZm5fdG9fbWZuX2ZyYW1lX2xpc3RfbGlzdC4gVGhlIGh5cGVydmlz
b3IgaW5kaWNhdGVzCj4+Pj4+PiB1c2FiaWxpdHkgb2YgdGhpcyBmZWF0dXJlIGJ5IGEgbmV3IGZs
YWcgWEVORkVBVF92aXJ0dWFsX3AybS4KPj4+Pj4+Cj4+Pj4+PiBSaWdodCBub3cgWEVORkVBVF92
aXJ0dWFsX3AybSB3aWxsIG5vdCBiZSBzZXQuIFRoaXMgd2lsbCBjaGFuZ2Ugd2hlbgo+Pj4+Pj4g
dGhlIFhlbiB0b29scyBzdXBwb3J0IHRoZSB2aXJ0dWFsIG1hcHBlZCBwMm0gbGlzdC4KPj4+Pj4K
Pj4+Pj4gVGhpcyBzZWVtcyB3cm9uZzogWEVORkVBVF8qIG9ubHkgcmVmbGVjdCBoeXBlcnZpc29y
IGNhcGFiaWxpdGllcy4KPj4+Pj4gSS5lLiB0aGUgYXZhaWxhYmlsaXR5IG9mIHRoZSBuZXcgZnVu
Y3Rpb25hbGl0eSBtYXkgbmVlZCB0byBiZQo+Pj4+PiBhZHZlcnRpc2VkIGFub3RoZXIgd2F5IC0g
eGVuc3RvcmUgcGVyaGFwcz8KPj4+Pgo+Pj4+IFhlbnN0b3JlIGRvZXNuJ3Qgd29yayBmb3IgZG9t
MC4KPj4+Pgo+Pj4+IFNob3VsZG4ndCB0aGlzIGJlIHNvbWV0aGluZyB0aGUgZ3Vlc3Qga2VybmVs
IHJlcG9ydHMgdXNpbmcgYSBFTEYgbm90ZSBiaXQ/Cj4+Pj4KPj4+PiBXaGVuIGJ1aWxkaW5nIGEg
ZG9tYWluIChlaXRoZXIgaW4gWGVuIGZvciBkb20wIG9yIGluIHRoZSB0b29scyksIHRoZQo+Pj4+
IGJ1aWxkZXIgbWF5IHByb3ZpZGUgYSBsaW5lYXIgcDJtIGlmZiBzdXBwb3J0ZWQgYnkgdGhlIGd1
ZXN0IGtlcm5lbCBhbmQKPj4+PiB0aGVuIChhbmQgb25seSB0aGVuKSBjYW4gaXQgcHJvdmlkZSBh
IGd1ZXN0IHdpdGggPiA1MTIgR2lCLgo+Pj4KPj4+IFllcywgc3VyZWx5IHRoaXMgZmxhZyBjb3Vs
ZCBhY3QgYXMgYSBrZXJuZWwgY2FwYWJpbGl0eSBpbmRpY2F0b3IgKHZpYQo+Pj4gdGhlIFhFTl9F
TEZOT1RFX1NVUFBPUlRFRF9GRUFUVVJFUyBub3RlKSwgbGlrZSBlLmcuCj4+PiBYRU5GRUFUX2Rv
bTAgYWxyZWFkeSBkb2VzLiBKw7xyZ2VuJ3MgZmluYWwgc3RhdGVtZW50LCBob3dldmVyLAo+Pj4g
c3VnZ2VzdGVkIHRvIG1lIHRoYXQgdGhpcyBpcyBtZWFudCB0byBiZSBvbmx5IGNvbnN1bWVkIGJ5
IGtlcm5lbHMuCj4+Cj4+IFllcy4gVGhlIHAybSBsaXN0IGJ1aWx0IGJ5IHRoZSBkb21haW4gYnVp
bGRlciBpcyBhbHJlYWR5IGxpbmVhci4gSXQgbWF5Cj4+IGp1c3QgYmUgdG8gc21hbGwgdG8gaG9s
ZCBhbGwgZW50cmllcyByZXF1aXJlZCBlLmcuIGZvciBEb20wLgo+Pgo+PiBJdCdzIFhlbi10b29s
cyBhbmQga2R1bXAgd2hpY2ggaGF2ZSB0byBkZWFsIHdpdGggdGhlIGxpbmVhciBwMm0gbGlzdC4K
Pj4gU28gdGhlIGd1ZXN0IGtlcm5lbCBoYXMgdG8gYmUgdG9sZCBpZiBpdCBpcyBhbGxvd2VkIHRv
IHByZXNlbnQgdGhlCj4+IGxpbmVhciBsaXN0IGluc3RlYWQgb2YgdGhlIDMtbGV2ZWwgdHJlZSBh
dCBwZm5fdG9fbWZuX2ZyYW1lX2xpc3RfbGlzdC4KPj4KPj4gQXMgdGhpcyBpcyB0cnVlIGZvciBE
b20wIGFzIHdlbGwsIHRoaXMgaW5mb3JtYXRpb24gbXVzdCBiZSBnaXZlbiBieSB0aGUKPj4gaHlw
ZXJ2aXNvci4KPj4KPj4gSSdtIGF3YXJlIHRoYXQgWEVORkVBVF8qIGlzIG9ubHkgdXNlZCBmb3Ig
aHlwZXJ2aXNvciBjYXBhYmlsaXRpZXMgdXAgdG8KPj4gbm93LiBBcyB0aGUgWGVuIHRvb2xzIGFy
ZSB0aWdodGx5IGNvdXBsZWQgdG8gdGhlIGh5cGVydmlzb3IgSSBkb24ndCBzZWUKPj4gd2h5IHRo
ZSBmZWF0dXJlcyBjYW4ndCBleHByZXNzIHRoZSBjYXBhYmlsaXR5IG9mIHRoZSBjb21wbGV0ZSBY
ZW4KPj4gaW5zdGFsbGF0aW9uIGluc3RlYWQuIFdvdWxkIHlvdSBwcmVmZXIgaW50cm9kdWNpbmcg
YW5vdGhlciBsZWFmIGZvcgo+PiB0aGF0IHB1cnBvc2UgKHN1Ym1hcC5pZHggPT0gMSkgPwo+Cj4g
VGhhdCB3b3VsZG4ndCBjaGFuZ2UgdGhlIG9kZCBzaXR1YXRpb24gb2YgcmVwb3J0aW5nIGEgY2Fw
YWJpbGl0eSBvZgo+IGFub3RoZXIgY29tcG9uZW50LiBUaGF0J3MgZXZlbiBtb3JlIG9mIGEgcHJv
YmxlbSBmb3IgdGhlIERvbTAKPiBjYXNlLCB3aGVyZSB0aGUgYWZmZWN0ZWQgdG9vbCAoa2R1bXAp
IGlzbid0IGV2ZW4gdW5kZXIgb3VyIGNvbnRyb2wKPiAoYW5kIHNob3VsZG4ndCBiZSkuCj4KPiBC
dXQgaW4gdGhlIGVuZCAtIHdoYXQncyB3cm9uZyB3aXRoIGFsd2F5cyAob3IgY29uZGl0aW9uYWxs
eSB1cG9uIGEKPiBDT05GSUdfKiBvcHRpb24gYW5kL29yIGNvbW1hbmQgbGluZSBwYXJhbWV0ZXIg
YW5kL29yIG1lbW9yeQo+IHNpemUpIGZpbGxpbmcgYm90aCB0aGUgb2xkIGFuZCBuZXcgc2hhcmVk
IGluZm8gZmllbGRzPyBBIGNhcGFibGUgdG9vbAo+IGNhbiBkZXRlcm1pbmUgd2hldGhlciB0aGUg
bmV3IG9uZSBpcyB2YWxpZCwgYW5kIGFuIGluY2FwYWJsZSB0b29sCj4gd29uJ3Qgd29yayBvbiBo
dWdlIG1lbW9yeSBjb25maWdzIGFueXdheS4KCk9rYXksIGJ1dCB0aGlzIHdvdWxkIHJlcXVpcmUg
YW5vdGhlciB3YXkgb2YgcmVwb3J0aW5nIHRoZSB2YWxpZGl0eSBvZgp0aGUgbGluZWFyIHAybSBs
aXN0IGFuY2hvciwgYXMgc2V0dGluZyBwZm5fdG9fbWZuX2ZyYW1lX2xpc3RfbGlzdCB0bwphbiBp
bnZhbGlkIHZhbHVlIGlzIG5vIGxvbmdlciBhbiBvcHRpb24gdGhlbi4KCkFzIHRoZSBzaGFyZWQg
aW5mbyBwYWdlIGlzIGFsd2F5cyB6ZXJvZWQgd2hlbiB0aGUgZG9tYWluIGlzIGJ1aWx0IHdlCmNv
dWxkIHVzZSBhIHZhbHVlIGRpZmZlcmVudCBmcm9tIDAgb2YgZS5nLiB0aGUgcDJtX2dlbmVyYXRp
b24gbWVtYmVyCmFzIGFuIGluZGljYXRvciBmb3IgdGhlIHZhbGlkaXR5LgoKCkp1ZXJnZW4KCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:33:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14: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 1XvS2J-0005SF-NJ; Mon, 01 Dec 2014 14:33:11 +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 1XvS2I-0005S9-Cm
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 14:33:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	1B/EA-09842-52C7C745; Mon, 01 Dec 2014 14:33:09 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417444388!12575114!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 5242 invoked from network); 1 Dec 2014 14:33:08 -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; 1 Dec 2014 14:33:08 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id CC209ACF9;
	Mon,  1 Dec 2014 14:33:07 +0000 (UTC)
Message-ID: <547C7C22.4020601@suse.com>
Date: Mon, 01 Dec 2014 15:33: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: Jan Beulich <JBeulich@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>	
	<1417426153-12893-2-git-send-email-jgross@suse.com>	
	<547C4DD6020000780004BA83@mail.emea.novell.com>	
	<547C4ECB.7070702@citrix.com>
	<547C5F31020000780004BB1F@suse.com>	 <547C68FD.60000@suse.com>
	<547C7D13020000780004BC3D@suse.com>
In-Reply-To: <547C7D13020000780004BC3D@suse.com>
Content-Length: 5561
Cc: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [Patch V2] 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: 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

T24gMTIvMDEvMjAxNCAwMjozNyBQTSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4gT24gMDEuMTIu
MTQgYXQgMTQ6MTEsIDxKR3Jvc3NAc3VzZS5jb20+IHdyb3RlOgo+PiBPbiAxMi8wMS8yMDE0IDEy
OjI5IFBNLCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+IE9uIDAxLjEyLjE0IGF0IDEyOjE5LCA8
ZGF2aWQudnJhYmVsQGNpdHJpeC5jb20+IHdyb3RlOgo+Pj4+IE9uIDAxLzEyLzE0IDEwOjE1LCBK
YW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+Pj4gT24gMDEuMTIuMTQgYXQgMTA6MjksIDxKR3Jvc3NA
c3VzZS5jb20+IHdyb3RlOgo+Pj4+Pj4gVGhlIHg4NiBzdHJ1Y3QgYXJjaF9zaGFyZWRfaW5mbyBm
aWVsZCBwZm5fdG9fbWZuX2ZyYW1lX2xpc3RfbGlzdAo+Pj4+Pj4gY3VycmVudGx5IGNvbnRhaW5z
IHRoZSBtZm4gb2YgdGhlIHRvcCBsZXZlbCBwYWdlIGZyYW1lIG9mIHRoZSAzIGxldmVsCj4+Pj4+
PiBwMm0gdHJlZSwgd2hpY2ggaXMgdXNlZCBieSB0aGUgWGVuIHRvb2xzIGR1cmluZyBzYXZpbmcg
YW5kIHJlc3RvcmluZwo+Pj4+Pj4gKGFuZCBsaXZlIG1pZ3JhdGlvbikgb2YgcHYgZG9tYWlucyBh
bmQgZm9yIGNyYXNoIGR1bXAgYW5hbHlzaXMuIFdpdGgKPj4+Pj4+IHRocmVlIGxldmVscyBvZiB0
aGUgcDJtIHRyZWUgaXQgaXMgcG9zc2libGUgdG8gc3VwcG9ydCB1cCB0byA1MTIgR0Igb2YKPj4+
Pj4+IFJBTSBmb3IgYSA2NCBiaXQgcHYgZG9tYWluLgo+Pj4+Pj4KPj4+Pj4+IEEgMzIgYml0IHB2
IGRvbWFpbiBjYW4gc3VwcG9ydCBtb3JlLCBhcyBlYWNoIG1lbW9yeSBwYWdlIGNhbiBob2xkIDEw
MjQKPj4+Pj4+IGluc3RlYWQgb2YgNTEyIGVudHJpZXMsIGxlYWRpbmcgdG8gYSBsaW1pdCBvZiA0
IFRCLgo+Pj4+Pj4KPj4+Pj4+IFRvIGJlIGFibGUgdG8gc3VwcG9ydCBtb3JlIFJBTSBvbiB4ODYt
NjQgc3dpdGNoIHRvIGEgdmlydHVhbCBtYXBwZWQKPj4+Pj4+IHAybSBsaXN0Lgo+Pj4+Pj4KPj4+
Pj4+IFRoaXMgcGF0Y2ggZXhwYW5kcyBzdHJ1Y3QgYXJjaF9zaGFyZWRfaW5mbyB3aXRoIGEgbmV3
IHAybSBsaXN0IHZpcnR1YWwKPj4+Pj4+IGFkZHJlc3MsIHRoZSByb290IG9mIHRoZSBwYWdlIHRh
YmxlIHJvb3QgYW5kIGEgcDJtIGdlbmVyYXRpb24gY291bnQuCj4+Pj4+PiBUaGUgbmV3IGluZm9y
bWF0aW9uIGlzIGluZGljYXRlZCBieSB0aGUgZG9tYWluIHRvIGJlIHZhbGlkIGJ5IHN0b3JpbmcK
Pj4+Pj4+IH4wVUwgaW50byBwZm5fdG9fbWZuX2ZyYW1lX2xpc3RfbGlzdC4gVGhlIGh5cGVydmlz
b3IgaW5kaWNhdGVzCj4+Pj4+PiB1c2FiaWxpdHkgb2YgdGhpcyBmZWF0dXJlIGJ5IGEgbmV3IGZs
YWcgWEVORkVBVF92aXJ0dWFsX3AybS4KPj4+Pj4+Cj4+Pj4+PiBSaWdodCBub3cgWEVORkVBVF92
aXJ0dWFsX3AybSB3aWxsIG5vdCBiZSBzZXQuIFRoaXMgd2lsbCBjaGFuZ2Ugd2hlbgo+Pj4+Pj4g
dGhlIFhlbiB0b29scyBzdXBwb3J0IHRoZSB2aXJ0dWFsIG1hcHBlZCBwMm0gbGlzdC4KPj4+Pj4K
Pj4+Pj4gVGhpcyBzZWVtcyB3cm9uZzogWEVORkVBVF8qIG9ubHkgcmVmbGVjdCBoeXBlcnZpc29y
IGNhcGFiaWxpdGllcy4KPj4+Pj4gSS5lLiB0aGUgYXZhaWxhYmlsaXR5IG9mIHRoZSBuZXcgZnVu
Y3Rpb25hbGl0eSBtYXkgbmVlZCB0byBiZQo+Pj4+PiBhZHZlcnRpc2VkIGFub3RoZXIgd2F5IC0g
eGVuc3RvcmUgcGVyaGFwcz8KPj4+Pgo+Pj4+IFhlbnN0b3JlIGRvZXNuJ3Qgd29yayBmb3IgZG9t
MC4KPj4+Pgo+Pj4+IFNob3VsZG4ndCB0aGlzIGJlIHNvbWV0aGluZyB0aGUgZ3Vlc3Qga2VybmVs
IHJlcG9ydHMgdXNpbmcgYSBFTEYgbm90ZSBiaXQ/Cj4+Pj4KPj4+PiBXaGVuIGJ1aWxkaW5nIGEg
ZG9tYWluIChlaXRoZXIgaW4gWGVuIGZvciBkb20wIG9yIGluIHRoZSB0b29scyksIHRoZQo+Pj4+
IGJ1aWxkZXIgbWF5IHByb3ZpZGUgYSBsaW5lYXIgcDJtIGlmZiBzdXBwb3J0ZWQgYnkgdGhlIGd1
ZXN0IGtlcm5lbCBhbmQKPj4+PiB0aGVuIChhbmQgb25seSB0aGVuKSBjYW4gaXQgcHJvdmlkZSBh
IGd1ZXN0IHdpdGggPiA1MTIgR2lCLgo+Pj4KPj4+IFllcywgc3VyZWx5IHRoaXMgZmxhZyBjb3Vs
ZCBhY3QgYXMgYSBrZXJuZWwgY2FwYWJpbGl0eSBpbmRpY2F0b3IgKHZpYQo+Pj4gdGhlIFhFTl9F
TEZOT1RFX1NVUFBPUlRFRF9GRUFUVVJFUyBub3RlKSwgbGlrZSBlLmcuCj4+PiBYRU5GRUFUX2Rv
bTAgYWxyZWFkeSBkb2VzLiBKw7xyZ2VuJ3MgZmluYWwgc3RhdGVtZW50LCBob3dldmVyLAo+Pj4g
c3VnZ2VzdGVkIHRvIG1lIHRoYXQgdGhpcyBpcyBtZWFudCB0byBiZSBvbmx5IGNvbnN1bWVkIGJ5
IGtlcm5lbHMuCj4+Cj4+IFllcy4gVGhlIHAybSBsaXN0IGJ1aWx0IGJ5IHRoZSBkb21haW4gYnVp
bGRlciBpcyBhbHJlYWR5IGxpbmVhci4gSXQgbWF5Cj4+IGp1c3QgYmUgdG8gc21hbGwgdG8gaG9s
ZCBhbGwgZW50cmllcyByZXF1aXJlZCBlLmcuIGZvciBEb20wLgo+Pgo+PiBJdCdzIFhlbi10b29s
cyBhbmQga2R1bXAgd2hpY2ggaGF2ZSB0byBkZWFsIHdpdGggdGhlIGxpbmVhciBwMm0gbGlzdC4K
Pj4gU28gdGhlIGd1ZXN0IGtlcm5lbCBoYXMgdG8gYmUgdG9sZCBpZiBpdCBpcyBhbGxvd2VkIHRv
IHByZXNlbnQgdGhlCj4+IGxpbmVhciBsaXN0IGluc3RlYWQgb2YgdGhlIDMtbGV2ZWwgdHJlZSBh
dCBwZm5fdG9fbWZuX2ZyYW1lX2xpc3RfbGlzdC4KPj4KPj4gQXMgdGhpcyBpcyB0cnVlIGZvciBE
b20wIGFzIHdlbGwsIHRoaXMgaW5mb3JtYXRpb24gbXVzdCBiZSBnaXZlbiBieSB0aGUKPj4gaHlw
ZXJ2aXNvci4KPj4KPj4gSSdtIGF3YXJlIHRoYXQgWEVORkVBVF8qIGlzIG9ubHkgdXNlZCBmb3Ig
aHlwZXJ2aXNvciBjYXBhYmlsaXRpZXMgdXAgdG8KPj4gbm93LiBBcyB0aGUgWGVuIHRvb2xzIGFy
ZSB0aWdodGx5IGNvdXBsZWQgdG8gdGhlIGh5cGVydmlzb3IgSSBkb24ndCBzZWUKPj4gd2h5IHRo
ZSBmZWF0dXJlcyBjYW4ndCBleHByZXNzIHRoZSBjYXBhYmlsaXR5IG9mIHRoZSBjb21wbGV0ZSBY
ZW4KPj4gaW5zdGFsbGF0aW9uIGluc3RlYWQuIFdvdWxkIHlvdSBwcmVmZXIgaW50cm9kdWNpbmcg
YW5vdGhlciBsZWFmIGZvcgo+PiB0aGF0IHB1cnBvc2UgKHN1Ym1hcC5pZHggPT0gMSkgPwo+Cj4g
VGhhdCB3b3VsZG4ndCBjaGFuZ2UgdGhlIG9kZCBzaXR1YXRpb24gb2YgcmVwb3J0aW5nIGEgY2Fw
YWJpbGl0eSBvZgo+IGFub3RoZXIgY29tcG9uZW50LiBUaGF0J3MgZXZlbiBtb3JlIG9mIGEgcHJv
YmxlbSBmb3IgdGhlIERvbTAKPiBjYXNlLCB3aGVyZSB0aGUgYWZmZWN0ZWQgdG9vbCAoa2R1bXAp
IGlzbid0IGV2ZW4gdW5kZXIgb3VyIGNvbnRyb2wKPiAoYW5kIHNob3VsZG4ndCBiZSkuCj4KPiBC
dXQgaW4gdGhlIGVuZCAtIHdoYXQncyB3cm9uZyB3aXRoIGFsd2F5cyAob3IgY29uZGl0aW9uYWxs
eSB1cG9uIGEKPiBDT05GSUdfKiBvcHRpb24gYW5kL29yIGNvbW1hbmQgbGluZSBwYXJhbWV0ZXIg
YW5kL29yIG1lbW9yeQo+IHNpemUpIGZpbGxpbmcgYm90aCB0aGUgb2xkIGFuZCBuZXcgc2hhcmVk
IGluZm8gZmllbGRzPyBBIGNhcGFibGUgdG9vbAo+IGNhbiBkZXRlcm1pbmUgd2hldGhlciB0aGUg
bmV3IG9uZSBpcyB2YWxpZCwgYW5kIGFuIGluY2FwYWJsZSB0b29sCj4gd29uJ3Qgd29yayBvbiBo
dWdlIG1lbW9yeSBjb25maWdzIGFueXdheS4KCk9rYXksIGJ1dCB0aGlzIHdvdWxkIHJlcXVpcmUg
YW5vdGhlciB3YXkgb2YgcmVwb3J0aW5nIHRoZSB2YWxpZGl0eSBvZgp0aGUgbGluZWFyIHAybSBs
aXN0IGFuY2hvciwgYXMgc2V0dGluZyBwZm5fdG9fbWZuX2ZyYW1lX2xpc3RfbGlzdCB0bwphbiBp
bnZhbGlkIHZhbHVlIGlzIG5vIGxvbmdlciBhbiBvcHRpb24gdGhlbi4KCkFzIHRoZSBzaGFyZWQg
aW5mbyBwYWdlIGlzIGFsd2F5cyB6ZXJvZWQgd2hlbiB0aGUgZG9tYWluIGlzIGJ1aWx0IHdlCmNv
dWxkIHVzZSBhIHZhbHVlIGRpZmZlcmVudCBmcm9tIDAgb2YgZS5nLiB0aGUgcDJtX2dlbmVyYXRp
b24gbWVtYmVyCmFzIGFuIGluZGljYXRvciBmb3IgdGhlIHZhbGlkaXR5LgoKCkp1ZXJnZW4KCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:34:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:34:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvS3K-0005WL-57; Mon, 01 Dec 2014 14:34:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XvS3I-0005WD-LX
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:34:12 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	36/D1-02954-36C7C745; Mon, 01 Dec 2014 14:34:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417444450!12237758!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17750 invoked from network); 1 Dec 2014 14:34:11 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 14:34:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417444450; l=621;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=cnHcshQmN456ELumCsrBPZnFrbs=;
	b=f4CMcqjQwV43CMlomwIsU7gajzxwZ+7Vskw7lljFma8PwTw0SdN9ZdwDr9QRgV1mOhk
	wPVtC3ecjX1xOkgt2HWp8yZNZxaehDXTwcB5SFZrhvgGyHxXM71qC+XTAeYLb73slk1my
	9q7cox00I957K4oEpSLj1It1kNxvjpK3Qig=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJxKkze/KnV3DKbeZ4a
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([89.204.135.68])
	by smtp.strato.de (RZmta 36.2 DYNA|AUTH)
	with ESMTPSA id v0026cqB1EYAYJW
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 1 Dec 2014 15:34:10 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 706CA5016D; Mon,  1 Dec 2014 15:34:09 +0100 (CET)
Date: Mon, 1 Dec 2014 15:34:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141201143409.GA3669@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201134211.GA25822@aepfle.de>
	<1299044479.20141201145702@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1299044479.20141201145702@eikelenboom.it>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, Sander Eikelenboom wrote:

> Hmm the wiki also still mentions it: http://wiki.xen.org/wiki/Xen_PCI_Passthrough
> 
> It was the ability with xend + qemu-trad to be able to specify the slot to 
> use in the guest for the pci device.
> 
> See docs/misc/vtd.txt .. that seems it has never been updated :-)
> 
> (together with passing through a multifunction devices as multifunction inside 
> the guest this hasn't got implemented in neither libxl and qemu-xen.)

So this looks like we a lost feature in libxl. Not sure if that would
actually be a workaround for the double pci-attach bug.


Olaf

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:34:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:34:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvS3K-0005WL-57; Mon, 01 Dec 2014 14:34:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XvS3I-0005WD-LX
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:34:12 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	36/D1-02954-36C7C745; Mon, 01 Dec 2014 14:34:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417444450!12237758!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17750 invoked from network); 1 Dec 2014 14:34:11 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 14:34:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417444450; l=621;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=cnHcshQmN456ELumCsrBPZnFrbs=;
	b=f4CMcqjQwV43CMlomwIsU7gajzxwZ+7Vskw7lljFma8PwTw0SdN9ZdwDr9QRgV1mOhk
	wPVtC3ecjX1xOkgt2HWp8yZNZxaehDXTwcB5SFZrhvgGyHxXM71qC+XTAeYLb73slk1my
	9q7cox00I957K4oEpSLj1It1kNxvjpK3Qig=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJxKkze/KnV3DKbeZ4a
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([89.204.135.68])
	by smtp.strato.de (RZmta 36.2 DYNA|AUTH)
	with ESMTPSA id v0026cqB1EYAYJW
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 1 Dec 2014 15:34:10 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 706CA5016D; Mon,  1 Dec 2014 15:34:09 +0100 (CET)
Date: Mon, 1 Dec 2014 15:34:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141201143409.GA3669@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201134211.GA25822@aepfle.de>
	<1299044479.20141201145702@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1299044479.20141201145702@eikelenboom.it>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, Sander Eikelenboom wrote:

> Hmm the wiki also still mentions it: http://wiki.xen.org/wiki/Xen_PCI_Passthrough
> 
> It was the ability with xend + qemu-trad to be able to specify the slot to 
> use in the guest for the pci device.
> 
> See docs/misc/vtd.txt .. that seems it has never been updated :-)
> 
> (together with passing through a multifunction devices as multifunction inside 
> the guest this hasn't got implemented in neither libxl and qemu-xen.)

So this looks like we a lost feature in libxl. Not sure if that would
actually be a workaround for the double pci-attach bug.


Olaf

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:37:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14: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 1XvS6Y-0005i3-NJ; Mon, 01 Dec 2014 14:37:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.haxby@oracle.com>) id 1XvS6X-0005hv-VI
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:37:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A5/F6-09842-D2D7C745; Mon, 01 Dec 2014 14:37:33 +0000
X-Env-Sender: john.haxby@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417444652!12633170!1
X-Originating-IP: [144.24.20.228]
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 17046 invoked from network); 1 Dec 2014 14:37:32 -0000
Received: from ukc1-proxy-mwg03-o.oracle.com (HELO sheep.uk.oracle.com)
	(144.24.20.228)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 14:37:32 -0000
Received: from sheep.uk.oracle.com (localhost [127.0.0.1])
	by sheep.uk.oracle.com (8.14.8/8.14.8) with ESMTP id sB1EbVEn020760
	for <xen-devel@lists.xen.org>; Mon, 1 Dec 2014 14:37:31 GMT
Received: (from jch@localhost)
	by sheep.uk.oracle.com (8.14.8/8.14.8/Submit) id sB1EbUNt020759
	for xen-devel@lists.xen.org; Mon, 1 Dec 2014 14:37:30 GMT
X-Authentication-Warning: sheep.uk.oracle.com: jch set sender to
	john.haxby@oracle.com using -f
From: John Haxby <john.haxby@oracle.com>
To: xen-devel@lists.xen.org
Date: Mon,  1 Dec 2014 14:37:24 +0000
Message-Id: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
X-Mailer: git-send-email 1.9.3
Subject: [Xen-devel] Two miscellenous xen-detect 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

I needed xen-detect this morning so as usual I pulled it from git and it
didn't work and it threw a compilation warning.   Thinking the problem
was the strict-aliasing warning (patch 1) I fixed that and ... it still
didn't work.  Well, that's not entirely true, it was just
over-enthusiastically claiming everything except dom0 was hvm.  Patch 2
reverses the order of the pv and hvm checks which works on everything I've
tried it with.

jch

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:37:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14: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 1XvS6a-0005iK-2i; Mon, 01 Dec 2014 14:37:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.haxby@oracle.com>) id 1XvS6Y-0005i1-RB
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:37:34 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	B4/EB-27785-E2D7C745; Mon, 01 Dec 2014 14:37:34 +0000
X-Env-Sender: john.haxby@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417444653!12231136!1
X-Originating-IP: [144.24.20.228]
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 32067 invoked from network); 1 Dec 2014 14:37:33 -0000
Received: from ukc1-proxy-mwg03-o.oracle.com (HELO sheep.uk.oracle.com)
	(144.24.20.228)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 14:37:33 -0000
Received: from sheep.uk.oracle.com (localhost [127.0.0.1])
	by sheep.uk.oracle.com (8.14.8/8.14.8) with ESMTP id sB1EbVxp020764
	for <xen-devel@lists.xen.org>; Mon, 1 Dec 2014 14:37:31 GMT
Received: (from jch@localhost)
	by sheep.uk.oracle.com (8.14.8/8.14.8/Submit) id sB1EbVuf020763
	for xen-devel@lists.xen.org; Mon, 1 Dec 2014 14:37:31 GMT
X-Authentication-Warning: sheep.uk.oracle.com: jch set sender to
	john.haxby@oracle.com using -f
From: John Haxby <john.haxby@oracle.com>
To: xen-devel@lists.xen.org
Date: Mon,  1 Dec 2014 14:37:25 +0000
Message-Id: <1417444646-20636-2-git-send-email-john.haxby@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
MIME-Version: 1.0
Content-Length: 2464
Subject: [Xen-devel] [PATCH 1/2] xen-detect: fix strict-aliasing compilation
	warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

V2l0aCBnY2MgNC44LjMsIGNvbXBpbGluZyB4ZW4tZGV0ZWN0IGdpdmVzIGEgY29tcGlsYXRpb24g
d2FybmluZyBpZgp5b3UncmUgb3B0aW1pc2luZzoKCiQgY2MgLVdhbGwgLU9zIHhlbi1kZXRlY3Qu
Ywp4ZW4tZGV0ZWN0LmM6IEluIGZ1bmN0aW9uIOKAmGNoZWNrX2Zvcl94ZW7igJk6Cnhlbi1kZXRl
Y3QuYzo2NTo5OiB3YXJuaW5nOiBkZXJlZmVyZW5jaW5nIHR5cGUtcHVubmVkIHBvaW50ZXIgd2ls
bCBicmVhawpzdHJpY3QtYWxpYXNpbmcgcnVsZXMgWy1Xc3RyaWN0LWFsaWFzaW5nXQogICAgICAg
ICAqKHVpbnQzMl90ICopKHNpZ25hdHVyZSArIDApID0gcmVnc1sxXTsKICAgICAgICAgXgoKU2ln
bmVkLW9mZi1ieTogSm9obiBIYXhieSA8am9obi5oYXhieUBvcmFjbGUuY29tPgotLS0KIHRvb2xz
L21pc2MveGVuLWRldGVjdC5jIHwgMjEgKysrKysrKysrKy0tLS0tLS0tLS0tCiAxIGZpbGUgY2hh
bmdlZCwgMTAgaW5zZXJ0aW9ucygrKSwgMTEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvdG9v
bHMvbWlzYy94ZW4tZGV0ZWN0LmMgYi90b29scy9taXNjL3hlbi1kZXRlY3QuYwppbmRleCA3ODdi
NWRhLi4xOWM2NmQxIDEwMDY0NAotLS0gYS90b29scy9taXNjL3hlbi1kZXRlY3QuYworKysgYi90
b29scy9taXNjL3hlbi1kZXRlY3QuYwpAQCAtNTQsMjggKzU0LDI3IEBAIHN0YXRpYyB2b2lkIGNw
dWlkKHVpbnQzMl90IGlkeCwgdWludDMyX3QgKnJlZ3MsIGludCBwdl9jb250ZXh0KQogCiBzdGF0
aWMgaW50IGNoZWNrX2Zvcl94ZW4oaW50IHB2X2NvbnRleHQpCiB7Ci0gICAgdWludDMyX3QgcmVn
c1s0XTsKLSAgICBjaGFyIHNpZ25hdHVyZVsxM107CisgICAgdW5pb24KKyAgICB7CisgICAgICAg
IHVpbnQzMl90IHJlZ3NbNF07CisgICAgICAgIGNoYXIgc2lnbmF0dXJlWzE3XTsKKyAgICB9IHU7
CiAgICAgdWludDMyX3QgYmFzZTsKIAogICAgIGZvciAoIGJhc2UgPSAweDQwMDAwMDAwOyBiYXNl
IDwgMHg0MDAxMDAwMDsgYmFzZSArPSAweDEwMCApCiAgICAgewotICAgICAgICBjcHVpZChiYXNl
LCByZWdzLCBwdl9jb250ZXh0KTsKLQotICAgICAgICAqKHVpbnQzMl90ICopKHNpZ25hdHVyZSAr
IDApID0gcmVnc1sxXTsKLSAgICAgICAgKih1aW50MzJfdCAqKShzaWduYXR1cmUgKyA0KSA9IHJl
Z3NbMl07Ci0gICAgICAgICoodWludDMyX3QgKikoc2lnbmF0dXJlICsgOCkgPSByZWdzWzNdOwot
ICAgICAgICBzaWduYXR1cmVbMTJdID0gJ1wwJzsKKyAgICAgICAgY3B1aWQoYmFzZSwgdS5yZWdz
LCBwdl9jb250ZXh0KTsKKyAgICAgICAgdS5zaWduYXR1cmVbMTZdID0gJ1wwJzsKIAotICAgICAg
ICBpZiAoICFzdHJjbXAoIlhlblZNTVhlblZNTSIsIHNpZ25hdHVyZSkgJiYgKHJlZ3NbMF0gPj0g
KGJhc2UgKyAyKSkgKQorICAgICAgICBpZiAoICFzdHJjbXAoIlhlblZNTVhlblZNTSIsIHUuc2ln
bmF0dXJlKzQpICYmICh1LnJlZ3NbMF0gPj0gKGJhc2UgKyAyKSkgKQogICAgICAgICAgICAgZ290
byBmb3VuZDsKICAgICB9CiAKICAgICByZXR1cm4gMDsKIAogIGZvdW5kOgotICAgIGNwdWlkKGJh
c2UgKyAxLCByZWdzLCBwdl9jb250ZXh0KTsKLSAgICByZXR1cm4gcmVnc1swXTsKKyAgICBjcHVp
ZChiYXNlICsgMSwgdS5yZWdzLCBwdl9jb250ZXh0KTsKKyAgICByZXR1cm4gdS5yZWdzWzBdOwog
fQogCiBzdGF0aWMgam1wX2J1ZiBzaWdpbGxfam1wOwotLSAKMS45LjMKCgpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:37:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14: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 1XvS6Y-0005i3-NJ; Mon, 01 Dec 2014 14:37:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.haxby@oracle.com>) id 1XvS6X-0005hv-VI
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:37:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A5/F6-09842-D2D7C745; Mon, 01 Dec 2014 14:37:33 +0000
X-Env-Sender: john.haxby@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417444652!12633170!1
X-Originating-IP: [144.24.20.228]
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 17046 invoked from network); 1 Dec 2014 14:37:32 -0000
Received: from ukc1-proxy-mwg03-o.oracle.com (HELO sheep.uk.oracle.com)
	(144.24.20.228)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 14:37:32 -0000
Received: from sheep.uk.oracle.com (localhost [127.0.0.1])
	by sheep.uk.oracle.com (8.14.8/8.14.8) with ESMTP id sB1EbVEn020760
	for <xen-devel@lists.xen.org>; Mon, 1 Dec 2014 14:37:31 GMT
Received: (from jch@localhost)
	by sheep.uk.oracle.com (8.14.8/8.14.8/Submit) id sB1EbUNt020759
	for xen-devel@lists.xen.org; Mon, 1 Dec 2014 14:37:30 GMT
X-Authentication-Warning: sheep.uk.oracle.com: jch set sender to
	john.haxby@oracle.com using -f
From: John Haxby <john.haxby@oracle.com>
To: xen-devel@lists.xen.org
Date: Mon,  1 Dec 2014 14:37:24 +0000
Message-Id: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
X-Mailer: git-send-email 1.9.3
Subject: [Xen-devel] Two miscellenous xen-detect 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

I needed xen-detect this morning so as usual I pulled it from git and it
didn't work and it threw a compilation warning.   Thinking the problem
was the strict-aliasing warning (patch 1) I fixed that and ... it still
didn't work.  Well, that's not entirely true, it was just
over-enthusiastically claiming everything except dom0 was hvm.  Patch 2
reverses the order of the pv and hvm checks which works on everything I've
tried it with.

jch

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:37:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14: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 1XvS6a-0005iK-2i; Mon, 01 Dec 2014 14:37:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.haxby@oracle.com>) id 1XvS6Y-0005i1-RB
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:37:34 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	B4/EB-27785-E2D7C745; Mon, 01 Dec 2014 14:37:34 +0000
X-Env-Sender: john.haxby@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417444653!12231136!1
X-Originating-IP: [144.24.20.228]
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 32067 invoked from network); 1 Dec 2014 14:37:33 -0000
Received: from ukc1-proxy-mwg03-o.oracle.com (HELO sheep.uk.oracle.com)
	(144.24.20.228)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 14:37:33 -0000
Received: from sheep.uk.oracle.com (localhost [127.0.0.1])
	by sheep.uk.oracle.com (8.14.8/8.14.8) with ESMTP id sB1EbVxp020764
	for <xen-devel@lists.xen.org>; Mon, 1 Dec 2014 14:37:31 GMT
Received: (from jch@localhost)
	by sheep.uk.oracle.com (8.14.8/8.14.8/Submit) id sB1EbVuf020763
	for xen-devel@lists.xen.org; Mon, 1 Dec 2014 14:37:31 GMT
X-Authentication-Warning: sheep.uk.oracle.com: jch set sender to
	john.haxby@oracle.com using -f
From: John Haxby <john.haxby@oracle.com>
To: xen-devel@lists.xen.org
Date: Mon,  1 Dec 2014 14:37:25 +0000
Message-Id: <1417444646-20636-2-git-send-email-john.haxby@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
MIME-Version: 1.0
Content-Length: 2464
Subject: [Xen-devel] [PATCH 1/2] xen-detect: fix strict-aliasing compilation
	warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

V2l0aCBnY2MgNC44LjMsIGNvbXBpbGluZyB4ZW4tZGV0ZWN0IGdpdmVzIGEgY29tcGlsYXRpb24g
d2FybmluZyBpZgp5b3UncmUgb3B0aW1pc2luZzoKCiQgY2MgLVdhbGwgLU9zIHhlbi1kZXRlY3Qu
Ywp4ZW4tZGV0ZWN0LmM6IEluIGZ1bmN0aW9uIOKAmGNoZWNrX2Zvcl94ZW7igJk6Cnhlbi1kZXRl
Y3QuYzo2NTo5OiB3YXJuaW5nOiBkZXJlZmVyZW5jaW5nIHR5cGUtcHVubmVkIHBvaW50ZXIgd2ls
bCBicmVhawpzdHJpY3QtYWxpYXNpbmcgcnVsZXMgWy1Xc3RyaWN0LWFsaWFzaW5nXQogICAgICAg
ICAqKHVpbnQzMl90ICopKHNpZ25hdHVyZSArIDApID0gcmVnc1sxXTsKICAgICAgICAgXgoKU2ln
bmVkLW9mZi1ieTogSm9obiBIYXhieSA8am9obi5oYXhieUBvcmFjbGUuY29tPgotLS0KIHRvb2xz
L21pc2MveGVuLWRldGVjdC5jIHwgMjEgKysrKysrKysrKy0tLS0tLS0tLS0tCiAxIGZpbGUgY2hh
bmdlZCwgMTAgaW5zZXJ0aW9ucygrKSwgMTEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvdG9v
bHMvbWlzYy94ZW4tZGV0ZWN0LmMgYi90b29scy9taXNjL3hlbi1kZXRlY3QuYwppbmRleCA3ODdi
NWRhLi4xOWM2NmQxIDEwMDY0NAotLS0gYS90b29scy9taXNjL3hlbi1kZXRlY3QuYworKysgYi90
b29scy9taXNjL3hlbi1kZXRlY3QuYwpAQCAtNTQsMjggKzU0LDI3IEBAIHN0YXRpYyB2b2lkIGNw
dWlkKHVpbnQzMl90IGlkeCwgdWludDMyX3QgKnJlZ3MsIGludCBwdl9jb250ZXh0KQogCiBzdGF0
aWMgaW50IGNoZWNrX2Zvcl94ZW4oaW50IHB2X2NvbnRleHQpCiB7Ci0gICAgdWludDMyX3QgcmVn
c1s0XTsKLSAgICBjaGFyIHNpZ25hdHVyZVsxM107CisgICAgdW5pb24KKyAgICB7CisgICAgICAg
IHVpbnQzMl90IHJlZ3NbNF07CisgICAgICAgIGNoYXIgc2lnbmF0dXJlWzE3XTsKKyAgICB9IHU7
CiAgICAgdWludDMyX3QgYmFzZTsKIAogICAgIGZvciAoIGJhc2UgPSAweDQwMDAwMDAwOyBiYXNl
IDwgMHg0MDAxMDAwMDsgYmFzZSArPSAweDEwMCApCiAgICAgewotICAgICAgICBjcHVpZChiYXNl
LCByZWdzLCBwdl9jb250ZXh0KTsKLQotICAgICAgICAqKHVpbnQzMl90ICopKHNpZ25hdHVyZSAr
IDApID0gcmVnc1sxXTsKLSAgICAgICAgKih1aW50MzJfdCAqKShzaWduYXR1cmUgKyA0KSA9IHJl
Z3NbMl07Ci0gICAgICAgICoodWludDMyX3QgKikoc2lnbmF0dXJlICsgOCkgPSByZWdzWzNdOwot
ICAgICAgICBzaWduYXR1cmVbMTJdID0gJ1wwJzsKKyAgICAgICAgY3B1aWQoYmFzZSwgdS5yZWdz
LCBwdl9jb250ZXh0KTsKKyAgICAgICAgdS5zaWduYXR1cmVbMTZdID0gJ1wwJzsKIAotICAgICAg
ICBpZiAoICFzdHJjbXAoIlhlblZNTVhlblZNTSIsIHNpZ25hdHVyZSkgJiYgKHJlZ3NbMF0gPj0g
KGJhc2UgKyAyKSkgKQorICAgICAgICBpZiAoICFzdHJjbXAoIlhlblZNTVhlblZNTSIsIHUuc2ln
bmF0dXJlKzQpICYmICh1LnJlZ3NbMF0gPj0gKGJhc2UgKyAyKSkgKQogICAgICAgICAgICAgZ290
byBmb3VuZDsKICAgICB9CiAKICAgICByZXR1cm4gMDsKIAogIGZvdW5kOgotICAgIGNwdWlkKGJh
c2UgKyAxLCByZWdzLCBwdl9jb250ZXh0KTsKLSAgICByZXR1cm4gcmVnc1swXTsKKyAgICBjcHVp
ZChiYXNlICsgMSwgdS5yZWdzLCBwdl9jb250ZXh0KTsKKyAgICByZXR1cm4gdS5yZWdzWzBdOwog
fQogCiBzdGF0aWMgam1wX2J1ZiBzaWdpbGxfam1wOwotLSAKMS45LjMKCgpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:37:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvS6c-0005jg-F8; Mon, 01 Dec 2014 14:37:38 +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 1XvS6b-0005il-88
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:37:37 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	64/16-02697-03D7C745; Mon, 01 Dec 2014 14:37:36 +0000
X-Env-Sender: john.haxby@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417444652!6723511!1
X-Originating-IP: [144.24.20.228]
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 12001 invoked from network); 1 Dec 2014 14:37:33 -0000
Received: from ukc1-proxy-mwg03-o.oracle.com (HELO sheep.uk.oracle.com)
	(144.24.20.228)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2014 14:37:33 -0000
Received: from sheep.uk.oracle.com (localhost [127.0.0.1])
	by sheep.uk.oracle.com (8.14.8/8.14.8) with ESMTP id sB1EbVOw020768
	for <xen-devel@lists.xen.org>; Mon, 1 Dec 2014 14:37:31 GMT
Received: (from jch@localhost)
	by sheep.uk.oracle.com (8.14.8/8.14.8/Submit) id sB1EbVLO020767
	for xen-devel@lists.xen.org; Mon, 1 Dec 2014 14:37:31 GMT
X-Authentication-Warning: sheep.uk.oracle.com: jch set sender to
	john.haxby@oracle.com using -f
From: John Haxby <john.haxby@oracle.com>
To: xen-devel@lists.xen.org
Date: Mon,  1 Dec 2014 14:37:26 +0000
Message-Id: <1417444646-20636-3-git-send-email-john.haxby@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] xen-detect: check for XEN_PV before XEN_HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At some stage, the cpuid instruction used to detect a xen hvm domain
also started working in a pv domain so pv domains were being identified
as hvm (dom0 excepted).  Change the order so that pv is tested for
first.

Signed-off-by: John Haxby <john.haxby@oracle.com>
---
 tools/misc/xen-detect.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/misc/xen-detect.c b/tools/misc/xen-detect.c
index 19c66d1..c8fccf9 100644
--- a/tools/misc/xen-detect.c
+++ b/tools/misc/xen-detect.c
@@ -132,15 +132,10 @@ int main(int argc, char **argv)
         }
     }
 
-    /* Check for execution in HVM context. */
-    detected = XEN_HVM;
-    if ( (version = check_for_xen(0)) != 0 )
-        goto out;
-
     /*
      * Set up a signal handler to test the paravirtualised CPUID instruction.
      * If executed outside Xen PV context, the extended opcode will fault, we
-     * will longjmp via the signal handler, and print "Not running on Xen".
+     * will longjmp via the signal handler, then check for HVM.
      */
     detected = XEN_PV;
     if ( !setjmp(sigill_jmp)
@@ -148,6 +143,11 @@ int main(int argc, char **argv)
          && ((version = check_for_xen(1)) != 0) )
         goto out;
 
+    /* Check for execution in HVM context. */
+    detected = XEN_HVM;
+    if ( (version = check_for_xen(0)) != 0 )
+        goto out;
+
     detected = XEN_NONE;
 
  out:
-- 
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 Dec 01 14:37:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvS6c-0005jg-F8; Mon, 01 Dec 2014 14:37:38 +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 1XvS6b-0005il-88
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:37:37 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	64/16-02697-03D7C745; Mon, 01 Dec 2014 14:37:36 +0000
X-Env-Sender: john.haxby@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417444652!6723511!1
X-Originating-IP: [144.24.20.228]
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 12001 invoked from network); 1 Dec 2014 14:37:33 -0000
Received: from ukc1-proxy-mwg03-o.oracle.com (HELO sheep.uk.oracle.com)
	(144.24.20.228)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Dec 2014 14:37:33 -0000
Received: from sheep.uk.oracle.com (localhost [127.0.0.1])
	by sheep.uk.oracle.com (8.14.8/8.14.8) with ESMTP id sB1EbVOw020768
	for <xen-devel@lists.xen.org>; Mon, 1 Dec 2014 14:37:31 GMT
Received: (from jch@localhost)
	by sheep.uk.oracle.com (8.14.8/8.14.8/Submit) id sB1EbVLO020767
	for xen-devel@lists.xen.org; Mon, 1 Dec 2014 14:37:31 GMT
X-Authentication-Warning: sheep.uk.oracle.com: jch set sender to
	john.haxby@oracle.com using -f
From: John Haxby <john.haxby@oracle.com>
To: xen-devel@lists.xen.org
Date: Mon,  1 Dec 2014 14:37:26 +0000
Message-Id: <1417444646-20636-3-git-send-email-john.haxby@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] xen-detect: check for XEN_PV before XEN_HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At some stage, the cpuid instruction used to detect a xen hvm domain
also started working in a pv domain so pv domains were being identified
as hvm (dom0 excepted).  Change the order so that pv is tested for
first.

Signed-off-by: John Haxby <john.haxby@oracle.com>
---
 tools/misc/xen-detect.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/misc/xen-detect.c b/tools/misc/xen-detect.c
index 19c66d1..c8fccf9 100644
--- a/tools/misc/xen-detect.c
+++ b/tools/misc/xen-detect.c
@@ -132,15 +132,10 @@ int main(int argc, char **argv)
         }
     }
 
-    /* Check for execution in HVM context. */
-    detected = XEN_HVM;
-    if ( (version = check_for_xen(0)) != 0 )
-        goto out;
-
     /*
      * Set up a signal handler to test the paravirtualised CPUID instruction.
      * If executed outside Xen PV context, the extended opcode will fault, we
-     * will longjmp via the signal handler, and print "Not running on Xen".
+     * will longjmp via the signal handler, then check for HVM.
      */
     detected = XEN_PV;
     if ( !setjmp(sigill_jmp)
@@ -148,6 +143,11 @@ int main(int argc, char **argv)
          && ((version = check_for_xen(1)) != 0) )
         goto out;
 
+    /* Check for execution in HVM context. */
+    detected = XEN_HVM;
+    if ( (version = check_for_xen(0)) != 0 )
+        goto out;
+
     detected = XEN_NONE;
 
  out:
-- 
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 Dec 01 14:39:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:39:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvS8V-0005yb-VH; Mon, 01 Dec 2014 14:39:35 +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 1XvS8U-0005yU-6g
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:39:34 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	AD/2E-28865-5AD7C745; Mon, 01 Dec 2014 14:39:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417444770!7493261!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 27429 invoked from network); 1 Dec 2014 14:39:32 -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;
	1 Dec 2014 14:39:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198410947"
Message-ID: <547C7D5F.3090009@citrix.com>
Date: Mon, 1 Dec 2014 14:38:23 +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: 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>
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>,
	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 20/11/14 18:28, Andrew Cooper wrote:
> 
> 1) Freeze the guests p2m during live migrate
> 2) Deep p2m dirty tracking
> 3) Eagerly check for p2m structure changes.
> 4) Request p2m structure change updates from the guest

> Proposed solution:  A combination of 2, 3 and 4.

Option 5: don't change anything.  PV guests and toolstacks are
well-behaved and ensure that p2m updates do not occur during domain save.

We have never supported migrating non-cooperative PV guests.

I'd be more interested fixing this for HVM guests.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:39:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:39:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvS8V-0005yb-VH; Mon, 01 Dec 2014 14:39:35 +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 1XvS8U-0005yU-6g
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:39:34 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	AD/2E-28865-5AD7C745; Mon, 01 Dec 2014 14:39:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417444770!7493261!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 27429 invoked from network); 1 Dec 2014 14:39:32 -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;
	1 Dec 2014 14:39:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198410947"
Message-ID: <547C7D5F.3090009@citrix.com>
Date: Mon, 1 Dec 2014 14:38:23 +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: 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>
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>,
	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 20/11/14 18:28, Andrew Cooper wrote:
> 
> 1) Freeze the guests p2m during live migrate
> 2) Deep p2m dirty tracking
> 3) Eagerly check for p2m structure changes.
> 4) Request p2m structure change updates from the guest

> Proposed solution:  A combination of 2, 3 and 4.

Option 5: don't change anything.  PV guests and toolstacks are
well-behaved and ensure that p2m updates do not occur during domain save.

We have never supported migrating non-cooperative PV guests.

I'd be more interested fixing this for HVM guests.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:39:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvS8q-000613-Ad; Mon, 01 Dec 2014 14:39: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 1XvS8p-00060l-2E
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:39:55 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F7/C4-25276-ABD7C745; Mon, 01 Dec 2014 14:39:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417444792!12614983!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 32040 invoked from network); 1 Dec 2014 14:39: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;
	1 Dec 2014 14:39:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198085783"
Message-ID: <1417444788.29138.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 1 Dec 2014 14:39:48 +0000
In-Reply-To: <20141201143409.GA3669@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de> <20141201134211.GA25822@aepfle.de>
	<1299044479.20141201145702@eikelenboom.it>
	<20141201143409.GA3669@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-01 at 15:34 +0100, Olaf Hering wrote:
> On Mon, Dec 01, Sander Eikelenboom wrote:
> 
> > Hmm the wiki also still mentions it: http://wiki.xen.org/wiki/Xen_PCI_Passthrough
> > 
> > It was the ability with xend + qemu-trad to be able to specify the slot to 
> > use in the guest for the pci device.
> > 
> > See docs/misc/vtd.txt .. that seems it has never been updated :-)
> > 
> > (together with passing through a multifunction devices as multifunction inside 
> > the guest this hasn't got implemented in neither libxl and qemu-xen.)
> 
> So this looks like we a lost feature in libxl.

See http://bugs.xenproject.org/xen/bug/22 (I think that's what that is)

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:39:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvS8q-000613-Ad; Mon, 01 Dec 2014 14:39: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 1XvS8p-00060l-2E
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:39:55 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F7/C4-25276-ABD7C745; Mon, 01 Dec 2014 14:39:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417444792!12614983!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 32040 invoked from network); 1 Dec 2014 14:39: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;
	1 Dec 2014 14:39:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198085783"
Message-ID: <1417444788.29138.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 1 Dec 2014 14:39:48 +0000
In-Reply-To: <20141201143409.GA3669@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de> <20141201134211.GA25822@aepfle.de>
	<1299044479.20141201145702@eikelenboom.it>
	<20141201143409.GA3669@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-01 at 15:34 +0100, Olaf Hering wrote:
> On Mon, Dec 01, Sander Eikelenboom wrote:
> 
> > Hmm the wiki also still mentions it: http://wiki.xen.org/wiki/Xen_PCI_Passthrough
> > 
> > It was the ability with xend + qemu-trad to be able to specify the slot to 
> > use in the guest for the pci device.
> > 
> > See docs/misc/vtd.txt .. that seems it has never been updated :-)
> > 
> > (together with passing through a multifunction devices as multifunction inside 
> > the guest this hasn't got implemented in neither libxl and qemu-xen.)
> 
> So this looks like we a lost feature in libxl.

See http://bugs.xenproject.org/xen/bug/22 (I think that's what that is)

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:42:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:42:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSBU-0006M7-2e; Mon, 01 Dec 2014 14:42:40 +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 1XvSBS-0006Lx-AV
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 14:42:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7B/BA-25276-D5E7C745; Mon, 01 Dec 2014 14:42:37 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417444956!12578782!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 25156 invoked from network); 1 Dec 2014 14:42:37 -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; 1 Dec 2014 14:42:37 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DF775AB09;
	Mon,  1 Dec 2014 14:42:34 +0000 (UTC)
Message-ID: <547C7E59.9040408@suse.com>
Date: Mon, 01 Dec 2014 15:42: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: "Luis R. Rodriguez" <mcgrof@suse.com>, 
	David Vrabel <david.vrabel@citrix.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> <5477FECF.2060404@suse.com>
	<547C4A7E.6020207@citrix.com>
	<20141201133245.GA25677@wotan.suse.de>
In-Reply-To: <20141201133245.GA25677@wotan.suse.de>
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>,
	Andrew Cooper <andrew.cooper3@citrix.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, 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 12/01/2014 02:32 PM, Luis R. Rodriguez wrote:
> On Mon, Dec 01, 2014 at 11:01:18AM +0000, David Vrabel wrote:
>> On 28/11/14 04:49, Juergen Gross wrote:
>>> On 11/27/2014 07:50 PM, Andrew Cooper wrote:
>>>>
>>>> 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.
>>
>> I dropped it because it copy-and-paste a bunch of otherwise generic x86
>> assembler and looked unlikely to get an x86 maintainer ack.  If you
>> think otherwise, feel free to pick it up and run with it.
>
> I was trying to run with it, but my biggest gripe with this was
> the use of preempt_schedule_irq(), but we can review that on the
> other thread.

I think this can be handled completely inside xen_evtchn_do_upcall().

xen_preemptible_hcall_begin() (possibly with another name) could take
the pointer of a function as parameter which is used as continuation
point after an asynchronous interrupt in the critical section.
Parameter for that function would be the exception frame of the
original interrupt to be able to continue at the interrupted position
after e.g. calling schedule().


Juergen

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:42:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:42:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSBU-0006M7-2e; Mon, 01 Dec 2014 14:42:40 +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 1XvSBS-0006Lx-AV
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 14:42:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7B/BA-25276-D5E7C745; Mon, 01 Dec 2014 14:42:37 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417444956!12578782!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 25156 invoked from network); 1 Dec 2014 14:42:37 -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; 1 Dec 2014 14:42:37 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DF775AB09;
	Mon,  1 Dec 2014 14:42:34 +0000 (UTC)
Message-ID: <547C7E59.9040408@suse.com>
Date: Mon, 01 Dec 2014 15:42: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: "Luis R. Rodriguez" <mcgrof@suse.com>, 
	David Vrabel <david.vrabel@citrix.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> <5477FECF.2060404@suse.com>
	<547C4A7E.6020207@citrix.com>
	<20141201133245.GA25677@wotan.suse.de>
In-Reply-To: <20141201133245.GA25677@wotan.suse.de>
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>,
	Andrew Cooper <andrew.cooper3@citrix.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, 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 12/01/2014 02:32 PM, Luis R. Rodriguez wrote:
> On Mon, Dec 01, 2014 at 11:01:18AM +0000, David Vrabel wrote:
>> On 28/11/14 04:49, Juergen Gross wrote:
>>> On 11/27/2014 07:50 PM, Andrew Cooper wrote:
>>>>
>>>> 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.
>>
>> I dropped it because it copy-and-paste a bunch of otherwise generic x86
>> assembler and looked unlikely to get an x86 maintainer ack.  If you
>> think otherwise, feel free to pick it up and run with it.
>
> I was trying to run with it, but my biggest gripe with this was
> the use of preempt_schedule_irq(), but we can review that on the
> other thread.

I think this can be handled completely inside xen_evtchn_do_upcall().

xen_preemptible_hcall_begin() (possibly with another name) could take
the pointer of a function as parameter which is used as continuation
point after an asynchronous interrupt in the critical section.
Parameter for that function would be the exception frame of the
original interrupt to be able to continue at the interrupted position
after e.g. calling schedule().


Juergen

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:45:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:45:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSEL-0006db-Ku; Mon, 01 Dec 2014 14:45: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 1XvSEJ-0006dU-VE
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 14:45:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F0/98-15461-F0F7C745; Mon, 01 Dec 2014 14:45:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417445131!12620344!1
X-Originating-IP: [66.165.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 6151 invoked from network); 1 Dec 2014 14:45:34 -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;
	1 Dec 2014 14:45:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198413544"
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, 1 Dec 2014 09:45: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 1XvSEE-0004Ju-AH;
	Mon, 01 Dec 2014 14:45:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvSEE-0002Y2-4H;
	Mon, 01 Dec 2014 14:45:30 +0000
Date: Mon, 1 Dec 2014 14:45:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31965-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] 31965: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  5 xen-boot                   fail pass in 31934
 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail in 31934 pass in 31965

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-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-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
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31934 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 Mon Dec 01 14:45:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:45:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSEL-0006db-Ku; Mon, 01 Dec 2014 14:45: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 1XvSEJ-0006dU-VE
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 14:45:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F0/98-15461-F0F7C745; Mon, 01 Dec 2014 14:45:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417445131!12620344!1
X-Originating-IP: [66.165.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 6151 invoked from network); 1 Dec 2014 14:45:34 -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;
	1 Dec 2014 14:45:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198413544"
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, 1 Dec 2014 09:45: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 1XvSEE-0004Ju-AH;
	Mon, 01 Dec 2014 14:45:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvSEE-0002Y2-4H;
	Mon, 01 Dec 2014 14:45:30 +0000
Date: Mon, 1 Dec 2014 14:45:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31965-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] 31965: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  5 xen-boot                   fail pass in 31934
 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail in 31934 pass in 31965

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-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-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
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31934 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 Mon Dec 01 14:46:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14: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 1XvSF6-0006hO-19; Mon, 01 Dec 2014 14:46:24 +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 1XvSF5-0006hG-JB
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:46:23 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	32/2C-07724-E3F7C745; Mon, 01 Dec 2014 14:46:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417445182!15035957!1
X-Originating-IP: [81.169.146.163]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11242 invoked from network); 1 Dec 2014 14:46:22 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 14:46:22 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417445182; l=811;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=GEjlUJk2cCpu+5TmAQEWFB57ZAQ=;
	b=n0KHdC4PWBWdKZF1bebJhku3A1FsZwrtlXmYiVS9L1fvU9TfgaPAYvWQny3n67rl3TB
	Crk/fdpc2RksE7OD94zRJxP0D7yd7SOG7Jo/tIH8HiESbmPBzhPa1HqceUSACkAAprtXP
	7NuTVZNj92sST3RZ+0AHOMjJldDJXdaY62o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJxKkze/KnV3DKbeZ4a
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([89.204.135.68])
	by smtp.strato.de (RZmta 36.2 DYNA|AUTH)
	with ESMTPSA id w02c0eqB1EkMZmj
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 1 Dec 2014 15:46:22 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A1D805016D; Mon,  1 Dec 2014 15:46:20 +0100 (CET)
Date: Mon, 1 Dec 2014 15:46:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201144620.GA6805@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201134211.GA25822@aepfle.de>
	<1299044479.20141201145702@eikelenboom.it>
	<20141201143409.GA3669@aepfle.de>
	<1417444788.29138.30.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417444788.29138.30.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, Ian Campbell wrote:

> On Mon, 2014-12-01 at 15:34 +0100, Olaf Hering wrote:
> > On Mon, Dec 01, Sander Eikelenboom wrote:
> > > Hmm the wiki also still mentions it: http://wiki.xen.org/wiki/Xen_PCI_Passthrough
> > > 
> > > It was the ability with xend + qemu-trad to be able to specify the slot to 
> > > use in the guest for the pci device.
> > > 
> > > See docs/misc/vtd.txt .. that seems it has never been updated :-)
> > > 
> > > (together with passing through a multifunction devices as multifunction inside 
> > > the guest this hasn't got implemented in neither libxl and qemu-xen.)
> > So this looks like we a lost feature in libxl.
> See http://bugs.xenproject.org/xen/bug/22 (I think that's what that is)

Yes, the virtual function part is covered by #22. Thanks.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:46:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14: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 1XvSF6-0006hO-19; Mon, 01 Dec 2014 14:46:24 +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 1XvSF5-0006hG-JB
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:46:23 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	32/2C-07724-E3F7C745; Mon, 01 Dec 2014 14:46:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417445182!15035957!1
X-Originating-IP: [81.169.146.163]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11242 invoked from network); 1 Dec 2014 14:46:22 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 14:46:22 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417445182; l=811;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=GEjlUJk2cCpu+5TmAQEWFB57ZAQ=;
	b=n0KHdC4PWBWdKZF1bebJhku3A1FsZwrtlXmYiVS9L1fvU9TfgaPAYvWQny3n67rl3TB
	Crk/fdpc2RksE7OD94zRJxP0D7yd7SOG7Jo/tIH8HiESbmPBzhPa1HqceUSACkAAprtXP
	7NuTVZNj92sST3RZ+0AHOMjJldDJXdaY62o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJxKkze/KnV3DKbeZ4a
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([89.204.135.68])
	by smtp.strato.de (RZmta 36.2 DYNA|AUTH)
	with ESMTPSA id w02c0eqB1EkMZmj
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 1 Dec 2014 15:46:22 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A1D805016D; Mon,  1 Dec 2014 15:46:20 +0100 (CET)
Date: Mon, 1 Dec 2014 15:46:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201144620.GA6805@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201134211.GA25822@aepfle.de>
	<1299044479.20141201145702@eikelenboom.it>
	<20141201143409.GA3669@aepfle.de>
	<1417444788.29138.30.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417444788.29138.30.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, Ian Campbell wrote:

> On Mon, 2014-12-01 at 15:34 +0100, Olaf Hering wrote:
> > On Mon, Dec 01, Sander Eikelenboom wrote:
> > > Hmm the wiki also still mentions it: http://wiki.xen.org/wiki/Xen_PCI_Passthrough
> > > 
> > > It was the ability with xend + qemu-trad to be able to specify the slot to 
> > > use in the guest for the pci device.
> > > 
> > > See docs/misc/vtd.txt .. that seems it has never been updated :-)
> > > 
> > > (together with passing through a multifunction devices as multifunction inside 
> > > the guest this hasn't got implemented in neither libxl and qemu-xen.)
> > So this looks like we a lost feature in libxl.
> See http://bugs.xenproject.org/xen/bug/22 (I think that's what that is)

Yes, the virtual function part is covered by #22. Thanks.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:47:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:47:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSFh-0006m0-Tb; Mon, 01 Dec 2014 14:47:01 +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 1XvSFg-0006lq-27
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:47:00 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	81/C0-05632-36F7C745; Mon, 01 Dec 2014 14:46:59 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417445218!14992831!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 28701 invoked from network); 1 Dec 2014 14:46:58 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 1 Dec 2014 14:46:58 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52217 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 1XvSD2-0004HZ-2F; Mon, 01 Dec 2014 15:44:16 +0100
Date: Mon, 1 Dec 2014 15:46:58 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <805308753.20141201154658@eikelenboom.it>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141201143409.GA3669@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201134211.GA25822@aepfle.de>
	<1299044479.20141201145702@eikelenboom.it>
	<20141201143409.GA3669@aepfle.de>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first 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


Monday, December 1, 2014, 3:34:09 PM, you wrote:

> On Mon, Dec 01, Sander Eikelenboom wrote:

>> Hmm the wiki also still mentions it: http://wiki.xen.org/wiki/Xen_PCI_Passthrough
>> 
>> It was the ability with xend + qemu-trad to be able to specify the slot to 
>> use in the guest for the pci device.
>> 
>> See docs/misc/vtd.txt .. that seems it has never been updated :-)
>> 
>> (together with passing through a multifunction devices as multifunction inside 
>> the guest this hasn't got implemented in neither libxl and qemu-xen.)

> So this looks like we a lost feature in libxl. 

Yes, they are on the bug list though for quite some time :-).
see http://bugs.xenproject.org/xen/bug/22
Although the multifuction part missing is only slightly noted there.

(a fix would need a part libxl and for HVM's at least part qemu-xen 
(since qemu-xen doesn't have the option implemented that qemu-trad
has for the slot and multifunction assignment))

> actually be a workaround for the double pci-attach bug.
Don't know about that bug.

--
Sander
> Olaf



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:47:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:47:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSFh-0006m0-Tb; Mon, 01 Dec 2014 14:47:01 +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 1XvSFg-0006lq-27
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:47:00 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	81/C0-05632-36F7C745; Mon, 01 Dec 2014 14:46:59 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417445218!14992831!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 28701 invoked from network); 1 Dec 2014 14:46:58 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 1 Dec 2014 14:46:58 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52217 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 1XvSD2-0004HZ-2F; Mon, 01 Dec 2014 15:44:16 +0100
Date: Mon, 1 Dec 2014 15:46:58 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <805308753.20141201154658@eikelenboom.it>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141201143409.GA3669@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201134211.GA25822@aepfle.de>
	<1299044479.20141201145702@eikelenboom.it>
	<20141201143409.GA3669@aepfle.de>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first 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


Monday, December 1, 2014, 3:34:09 PM, you wrote:

> On Mon, Dec 01, Sander Eikelenboom wrote:

>> Hmm the wiki also still mentions it: http://wiki.xen.org/wiki/Xen_PCI_Passthrough
>> 
>> It was the ability with xend + qemu-trad to be able to specify the slot to 
>> use in the guest for the pci device.
>> 
>> See docs/misc/vtd.txt .. that seems it has never been updated :-)
>> 
>> (together with passing through a multifunction devices as multifunction inside 
>> the guest this hasn't got implemented in neither libxl and qemu-xen.)

> So this looks like we a lost feature in libxl. 

Yes, they are on the bug list though for quite some time :-).
see http://bugs.xenproject.org/xen/bug/22
Although the multifuction part missing is only slightly noted there.

(a fix would need a part libxl and for HVM's at least part qemu-xen 
(since qemu-xen doesn't have the option implemented that qemu-trad
has for the slot and multifunction assignment))

> actually be a workaround for the double pci-attach bug.
Don't know about that bug.

--
Sander
> Olaf



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:51:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSJh-00070v-J3; Mon, 01 Dec 2014 14:51: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 1XvSJg-00070o-Ol
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:51:08 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	EC/FB-28296-C508C745; Mon, 01 Dec 2014 14:51:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417445461!15023232!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31982 invoked from network); 1 Dec 2014 14:51:04 -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;
	1 Dec 2014 14:51:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198415940"
Message-ID: <1417445456.29138.33.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Mon, 1 Dec 2014 14:50:56 +0000
In-Reply-To: <1417444026-31044-1-git-send-email-euan.harris@citrix.com>
References: <1417444026-31044-1-git-send-email-euan.harris@citrix.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] libxl: Don't derefence null new_name
 pointer in libxl_domain_rename()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-01 at 14:27 +0000, Euan Harris wrote:
> libxl__domain_rename() unconditionally dereferences its new_name
> parameter, to check whether it is an empty string.   Add a check to
> avoid a segfault if new_name is null.
> 
> Signed-off-by: Euan Harris <euan.harris@citrix.com>

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

I think this is a good fix to have for 4.5, Konrad CCd.

> ---
>  tools/libxl/libxl.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f84f7c2..6e84b5d 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -385,6 +385,13 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>          }
>      }
>  
> +    if (!new_name) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                        "new domain name not specified");
> +        rc = ERROR_INVAL;
> +        goto x_rc;
> +    }
> +
>      if (new_name[0]) {
>          /* nonempty names must be unique */
>          uint32_t domid_e;



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 14:51:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 14:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSJh-00070v-J3; Mon, 01 Dec 2014 14:51: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 1XvSJg-00070o-Ol
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 14:51:08 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	EC/FB-28296-C508C745; Mon, 01 Dec 2014 14:51:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417445461!15023232!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31982 invoked from network); 1 Dec 2014 14:51:04 -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;
	1 Dec 2014 14:51:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198415940"
Message-ID: <1417445456.29138.33.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Mon, 1 Dec 2014 14:50:56 +0000
In-Reply-To: <1417444026-31044-1-git-send-email-euan.harris@citrix.com>
References: <1417444026-31044-1-git-send-email-euan.harris@citrix.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] libxl: Don't derefence null new_name
 pointer in libxl_domain_rename()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-01 at 14:27 +0000, Euan Harris wrote:
> libxl__domain_rename() unconditionally dereferences its new_name
> parameter, to check whether it is an empty string.   Add a check to
> avoid a segfault if new_name is null.
> 
> Signed-off-by: Euan Harris <euan.harris@citrix.com>

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

I think this is a good fix to have for 4.5, Konrad CCd.

> ---
>  tools/libxl/libxl.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f84f7c2..6e84b5d 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -385,6 +385,13 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>          }
>      }
>  
> +    if (!new_name) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                        "new domain name not specified");
> +        rc = ERROR_INVAL;
> +        goto x_rc;
> +    }
> +
>      if (new_name[0]) {
>          /* nonempty names must be unique */
>          uint32_t domid_e;



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

From xen-devel-bounces@lists.xen.org Mon Dec 01 15:06:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvSXy-0007WE-1j; Mon, 01 Dec 2014 15:05:54 +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 1XvSXw-0007W9-HG
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 15:05:52 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	C8/A0-02699-FC38C745; Mon, 01 Dec 2014 15:05:51 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417446351!12226423!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 8423 invoked from network); 1 Dec 2014 15:05:51 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 15:05:51 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id CEA42AC24;
	Mon,  1 Dec 2014 15:05:47 +0000 (UTC)
Date: Mon, 1 Dec 2014 16:05:46 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141201150546.GC25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C4CEF.1010603@citrix.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Juergen Gross <jgross@suse.com>, x86@kernel.org, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Oleg Nesterov <oleg@redhat.com>, linux-kernel@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>, Joerg Roedel <jroedel@suse.de>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
> [...]
> >>> --- 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
> 
> As Juergen points out, this does nothing.  You need to schedule while in
> the middle of the hypercall.
> 
> Remember that Xen's hypercall preemption only preempts the hypercall to
> run interrupts in the guest.

How is it ensured that when the kernel preempts on this code path on
CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?

> >>>
> >>>   	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...
> 
> No.  My patch added a schedule point in the middle of a hypercall on the
> return from an interrupt (e.g., the timer interrupt).

OK that provides much better context and given that I do see the above hunk as
pointless. I was completely misrepresenting what the callback was for. Now --
just to address my issues with the use of preempt_schedule_irq(). If the above
is addressed that I think should address most of my concerns, if we can figure
out a way to not deal with it to be arch specific that'd be neat, and if we
could not have to ifdef around stuff even better.

  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 15:06:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvSXy-0007WE-1j; Mon, 01 Dec 2014 15:05:54 +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 1XvSXw-0007W9-HG
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 15:05:52 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	C8/A0-02699-FC38C745; Mon, 01 Dec 2014 15:05:51 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417446351!12226423!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 8423 invoked from network); 1 Dec 2014 15:05:51 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 15:05:51 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id CEA42AC24;
	Mon,  1 Dec 2014 15:05:47 +0000 (UTC)
Date: Mon, 1 Dec 2014 16:05:46 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141201150546.GC25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C4CEF.1010603@citrix.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Juergen Gross <jgross@suse.com>, x86@kernel.org, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Oleg Nesterov <oleg@redhat.com>, linux-kernel@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>, Joerg Roedel <jroedel@suse.de>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
> [...]
> >>> --- 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
> 
> As Juergen points out, this does nothing.  You need to schedule while in
> the middle of the hypercall.
> 
> Remember that Xen's hypercall preemption only preempts the hypercall to
> run interrupts in the guest.

How is it ensured that when the kernel preempts on this code path on
CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?

> >>>
> >>>   	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...
> 
> No.  My patch added a schedule point in the middle of a hypercall on the
> return from an interrupt (e.g., the timer interrupt).

OK that provides much better context and given that I do see the above hunk as
pointless. I was completely misrepresenting what the callback was for. Now --
just to address my issues with the use of preempt_schedule_irq(). If the above
is addressed that I think should address most of my concerns, if we can figure
out a way to not deal with it to be arch specific that'd be neat, and if we
could not have to ifdef around stuff even better.

  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 15:19:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:19:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSkG-0007qP-GS; Mon, 01 Dec 2014 15:18: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 1XvSkE-0007qK-Pi
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 15:18:34 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	3E/83-24124-AC68C745; Mon, 01 Dec 2014 15:18:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417447109!10876840!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 2683 invoked from network); 1 Dec 2014 15:18:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 15:18:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198102890"
Message-ID: <547C86BF.2040705@citrix.com>
Date: Mon, 1 Dec 2014 15:18:23 +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: "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>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
In-Reply-To: <20141201150546.GC25677@wotan.suse.de>
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>, x86@kernel.org, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Oleg Nesterov <oleg@redhat.com>, linux-kernel@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>, Joerg Roedel <jroedel@suse.de>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 01/12/14 15:05, Luis R. Rodriguez wrote:
> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
>> [...]
>>>>> --- 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
>>
>> As Juergen points out, this does nothing.  You need to schedule while in
>> the middle of the hypercall.
>>
>> Remember that Xen's hypercall preemption only preempts the hypercall to
>> run interrupts in the guest.
> 
> How is it ensured that when the kernel preempts on this code path on
> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?

Sorry, I really didn't describe this very well.

If a hypercall needs a continuation, Xen returns to the guest with the
IP set to the hypercall instruction, and on the way back to the guest
Xen may schedule a different VCPU or it will do any upcalls (as per normal).

The guest is free to return from the upcall to the original task
(continuing the hypercall) or to a different one.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 15:19:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:19:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSkG-0007qP-GS; Mon, 01 Dec 2014 15:18: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 1XvSkE-0007qK-Pi
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 15:18:34 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	3E/83-24124-AC68C745; Mon, 01 Dec 2014 15:18:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417447109!10876840!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 2683 invoked from network); 1 Dec 2014 15:18:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 15:18:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198102890"
Message-ID: <547C86BF.2040705@citrix.com>
Date: Mon, 1 Dec 2014 15:18:23 +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: "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>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
In-Reply-To: <20141201150546.GC25677@wotan.suse.de>
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>, x86@kernel.org, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Oleg Nesterov <oleg@redhat.com>, linux-kernel@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>, Joerg Roedel <jroedel@suse.de>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 01/12/14 15:05, Luis R. Rodriguez wrote:
> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
>> [...]
>>>>> --- 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
>>
>> As Juergen points out, this does nothing.  You need to schedule while in
>> the middle of the hypercall.
>>
>> Remember that Xen's hypercall preemption only preempts the hypercall to
>> run interrupts in the guest.
> 
> How is it ensured that when the kernel preempts on this code path on
> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?

Sorry, I really didn't describe this very well.

If a hypercall needs a continuation, Xen returns to the guest with the
IP set to the hypercall instruction, and on the way back to the guest
Xen may schedule a different VCPU or it will do any upcalls (as per normal).

The guest is free to return from the upcall to the original task
(continuing the hypercall) or to a different one.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzE-0008KW-NY; Mon, 01 Dec 2014 15:34:04 +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 1XvSzD-0008Jx-3Z
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:03 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	FE/B8-02696-A6A8C745; Mon, 01 Dec 2014 15:34:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11794 invoked from network); 1 Dec 2014 15:34:01 -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;
	1 Dec 2014 15:34:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435598"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-6d;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:25 +0000
Message-ID: <1417448023-27311-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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>
---
Changes in v2:
1. Use unsigned int for loop vars.
2. Use strlcpy.
3. Properly align output.
---
 xen/arch/x86/numa.c |   47 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 628a40a..3bbc975 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -363,10 +363,13 @@ EXPORT_SYMBOL(node_data);
 static void dump_numa(unsigned char key)
 {
     s_time_t now = NOW();
-    int i;
+    unsigned int i, j, n;
+    int err;
     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 +411,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, "%3u",
+                    vnuma->vnode_to_pnode[i]);
+            if ( err < 0 || vnuma->vnode_to_pnode[i] == NUMA_NO_NODE )
+                strlcpy(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("%16"PRIu64" MB: %#016"PRIx64" - %#016"PRIx64"\n",
+                           mem >> 20,
+                           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("%3d\n", j);
+                    else if ( !(n % 8) && n != 0 )
+                        printk("%17d ", j);
+                    else
+                        printk("%3d ", 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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzE-0008K9-01; Mon, 01 Dec 2014 15:34:04 +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 1XvSzB-0008Jl-Ub
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:02 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	F0/D2-02953-96A8C745; Mon, 01 Dec 2014 15:34:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!1
X-Originating-IP: [66.165.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 11522 invoked from network); 1 Dec 2014 15:33: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;
	1 Dec 2014 15:33:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435596"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-5j;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:24 +0000
Message-ID: <1417448023-27311-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>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 is version 2 of this series.

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/hypervisor 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-v2

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], [30,10] ]

For example output of guest NUMA information, please look at [1].

Wei.

[0] <20141111173606.GC21312@zion.uk.xensource.com>
[1] <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>

Changes in v2:
1. Make vnuma_vdistances mandatory.
2. Use nested list to specify distances among nodes.
3. Hvmloader uses hypercall to retrieve vNUMA information.
4. Fix some problems spotted by Jan.

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
  xen: handle XENMEMF_get_vnumainfo in compat_memory_op
  hvmloader: retrieve vNUMA information from hypervisor
  hvmloader: construct SRAT
  hvmloader: construct SLIT
  libxc: allocate memory with vNUMA information for HVM guest
  libxl: build, check and pass vNUMA info to Xen for HVM guest
  libxl: disallow memory relocation when vNUMA is enabled
  libxlutil: nested list support
  xl: vNUMA support

 docs/man/xl.cfg.pod.5                   |   39 ++++++
 tools/firmware/hvmloader/Makefile       |    2 +-
 tools/firmware/hvmloader/acpi/acpi2_0.h |   61 +++++++++
 tools/firmware/hvmloader/acpi/build.c   |  109 +++++++++++++++
 tools/firmware/hvmloader/hvmloader.c    |    3 +
 tools/firmware/hvmloader/vnuma.c        |   84 ++++++++++++
 tools/firmware/hvmloader/vnuma.h        |   56 ++++++++
 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_dm.c                  |    6 +-
 tools/libxl/libxl_dom.c                 |   99 ++++++++++++++
 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/libxlu_cfg.c                |  180 ++++++++++++++----------
 tools/libxl/libxlu_cfg_i.h              |   15 +-
 tools/libxl/libxlu_cfg_y.c              |  110 +++++++--------
 tools/libxl/libxlu_cfg_y.h              |    2 +-
 tools/libxl/libxlu_cfg_y.y              |   19 ++-
 tools/libxl/libxlu_internal.h           |   24 +++-
 tools/libxl/libxlutil.h                 |   11 +-
 tools/libxl/xl_cmdimpl.c                |  147 ++++++++++++++++++++
 xen/arch/x86/numa.c                     |   47 ++++++-
 xen/common/compat/memory.c              |   38 ++++++
 xen/common/kernel.c                     |    1 +
 xen/common/memory.c                     |   58 +++++++-
 xen/include/public/features.h           |    3 +
 xen/include/public/memory.h             |    2 +
 xen/include/xlat.lst                    |    2 +
 37 files changed, 1568 insertions(+), 262 deletions(-)
 create mode 100644 tools/firmware/hvmloader/vnuma.c
 create mode 100644 tools/firmware/hvmloader/vnuma.h
 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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzG-0008LT-6R; Mon, 01 Dec 2014 15:34: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 1XvSzE-0008KM-TJ
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:05 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	4C/4E-05632-C6A8C745; Mon, 01 Dec 2014 15:34:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417448038!14953077!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 21579 invoked from network); 1 Dec 2014 15:34: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;
	1 Dec 2014 15:34:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435610"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-GH;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:33 +0000
Message-ID: <1417448023-27311-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 88da7ba..1678715 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 d92376d..b8d9268 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;
+    xen_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..2018afc 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];
+    xen_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(xen_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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzE-0008KK-CX; Mon, 01 Dec 2014 15:34:04 +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 1XvSzB-0008Jm-Vw
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:02 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	F4/24-02698-96A8C745; Mon, 01 Dec 2014 15:34:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!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 11676 invoked from network); 1 Dec 2014 15:34:00 -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;
	1 Dec 2014 15:34:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435600"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-8i;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:26 +0000
Message-ID: <1417448023-27311-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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>
---
Changes in v2:
1. Return start_extent when vnode translation fails.
2. Expose new feature bit to guest.
3. Fix typo in comment.
---
 xen/common/kernel.c           |    1 +
 xen/common/memory.c           |   58 ++++++++++++++++++++++++++++++++++++++---
 xen/include/public/features.h |    3 +++
 xen/include/public/memory.h   |    2 ++
 4 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index d23c422..9f97f68 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -302,6 +302,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         {
         case 0:
             fi.submap = 0;
+            fi.submap |= (1U << XENFEAT_memory_op_vnode_supported);
             if ( VM_ASSIST(d, VMASST_TYPE_pae_extended_cr3) )
                 fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb);
             if ( paging_mode_translate(current->domain) )
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 9f21bd3..f78c403 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 start_extent;
+        }
+
         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..2110b04 100644
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -99,6 +99,9 @@
 #define XENFEAT_grant_map_identity        12
  */
 
+/* Guest 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 595f953..2b5206b 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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzF-0008Kr-F7; Mon, 01 Dec 2014 15:34: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 1XvSzE-0008K8-3J
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:04 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	20/7D-03148-B6A8C745; Mon, 01 Dec 2014 15:34:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11963 invoked from network); 1 Dec 2014 15:34:02 -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;
	1 Dec 2014 15:34:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435604"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-Cr;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:29 +0000
Message-ID: <1417448023-27311-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzF-0008Kf-2T; Mon, 01 Dec 2014 15:34: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 1XvSzD-0008Jy-F7
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:03 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	31/66-02957-A6A8C745; Mon, 01 Dec 2014 15:34:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11880 invoked from network); 1 Dec 2014 15:34:02 -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;
	1 Dec 2014 15:34:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435602"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-Bz;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:28 +0000
Message-ID: <1417448023-27311-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzG-0008Lo-PT; Mon, 01 Dec 2014 15:34:06 +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 1XvSzF-0008KX-42
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:05 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	54/8C-02712-C6A8C745; Mon, 01 Dec 2014 15:34:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12032 invoked from network); 1 Dec 2014 15:34:03 -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;
	1 Dec 2014 15:34:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435606"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-FR;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:32 +0000
Message-ID: <1417448023-27311-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzE-0008KW-NY; Mon, 01 Dec 2014 15:34:04 +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 1XvSzD-0008Jx-3Z
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:03 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	FE/B8-02696-A6A8C745; Mon, 01 Dec 2014 15:34:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11794 invoked from network); 1 Dec 2014 15:34:01 -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;
	1 Dec 2014 15:34:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435598"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-6d;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:25 +0000
Message-ID: <1417448023-27311-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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>
---
Changes in v2:
1. Use unsigned int for loop vars.
2. Use strlcpy.
3. Properly align output.
---
 xen/arch/x86/numa.c |   47 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 628a40a..3bbc975 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -363,10 +363,13 @@ EXPORT_SYMBOL(node_data);
 static void dump_numa(unsigned char key)
 {
     s_time_t now = NOW();
-    int i;
+    unsigned int i, j, n;
+    int err;
     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 +411,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, "%3u",
+                    vnuma->vnode_to_pnode[i]);
+            if ( err < 0 || vnuma->vnode_to_pnode[i] == NUMA_NO_NODE )
+                strlcpy(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("%16"PRIu64" MB: %#016"PRIx64" - %#016"PRIx64"\n",
+                           mem >> 20,
+                           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("%3d\n", j);
+                    else if ( !(n % 8) && n != 0 )
+                        printk("%17d ", j);
+                    else
+                        printk("%3d ", 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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzG-0008LT-6R; Mon, 01 Dec 2014 15:34: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 1XvSzE-0008KM-TJ
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:05 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	4C/4E-05632-C6A8C745; Mon, 01 Dec 2014 15:34:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417448038!14953077!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 21579 invoked from network); 1 Dec 2014 15:34: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;
	1 Dec 2014 15:34:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435610"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-GH;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:33 +0000
Message-ID: <1417448023-27311-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 88da7ba..1678715 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 d92376d..b8d9268 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;
+    xen_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..2018afc 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];
+    xen_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(xen_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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzH-0008Lx-4W; Mon, 01 Dec 2014 15:34:07 +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 1XvSzF-0008Kc-ER
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:05 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	0B/66-02957-C6A8C745; Mon, 01 Dec 2014 15:34:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!7
X-Originating-IP: [66.165.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 12096 invoked from network); 1 Dec 2014 15:34:04 -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;
	1 Dec 2014 15:34:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435605"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-Dj;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:30 +0000
Message-ID: <1417448023-27311-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 a38f695..6632459 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;
+
+    xen_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 Mon Dec 01 15:34:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvSzH-0008MD-HL; Mon, 01 Dec 2014 15:34: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 1XvSzF-0008Kh-JH
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:05 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	81/D3-07724-C6A8C745; Mon, 01 Dec 2014 15:34:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417448038!14953077!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 21705 invoked from network); 1 Dec 2014 15:34: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;
	1 Dec 2014 15:34:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435609"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-EZ;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:31 +0000
Message-ID: <1417448023-27311-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 6632459..88da7ba 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..d92376d
--- /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 xen_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(xen_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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzE-0008K9-01; Mon, 01 Dec 2014 15:34:04 +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 1XvSzB-0008Jl-Ub
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:02 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	F0/D2-02953-96A8C745; Mon, 01 Dec 2014 15:34:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!1
X-Originating-IP: [66.165.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 11522 invoked from network); 1 Dec 2014 15:33: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;
	1 Dec 2014 15:33:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435596"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-5j;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:24 +0000
Message-ID: <1417448023-27311-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>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 is version 2 of this series.

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/hypervisor 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-v2

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], [30,10] ]

For example output of guest NUMA information, please look at [1].

Wei.

[0] <20141111173606.GC21312@zion.uk.xensource.com>
[1] <1416582421-10789-1-git-send-email-wei.liu2@citrix.com>

Changes in v2:
1. Make vnuma_vdistances mandatory.
2. Use nested list to specify distances among nodes.
3. Hvmloader uses hypercall to retrieve vNUMA information.
4. Fix some problems spotted by Jan.

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
  xen: handle XENMEMF_get_vnumainfo in compat_memory_op
  hvmloader: retrieve vNUMA information from hypervisor
  hvmloader: construct SRAT
  hvmloader: construct SLIT
  libxc: allocate memory with vNUMA information for HVM guest
  libxl: build, check and pass vNUMA info to Xen for HVM guest
  libxl: disallow memory relocation when vNUMA is enabled
  libxlutil: nested list support
  xl: vNUMA support

 docs/man/xl.cfg.pod.5                   |   39 ++++++
 tools/firmware/hvmloader/Makefile       |    2 +-
 tools/firmware/hvmloader/acpi/acpi2_0.h |   61 +++++++++
 tools/firmware/hvmloader/acpi/build.c   |  109 +++++++++++++++
 tools/firmware/hvmloader/hvmloader.c    |    3 +
 tools/firmware/hvmloader/vnuma.c        |   84 ++++++++++++
 tools/firmware/hvmloader/vnuma.h        |   56 ++++++++
 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_dm.c                  |    6 +-
 tools/libxl/libxl_dom.c                 |   99 ++++++++++++++
 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/libxlu_cfg.c                |  180 ++++++++++++++----------
 tools/libxl/libxlu_cfg_i.h              |   15 +-
 tools/libxl/libxlu_cfg_y.c              |  110 +++++++--------
 tools/libxl/libxlu_cfg_y.h              |    2 +-
 tools/libxl/libxlu_cfg_y.y              |   19 ++-
 tools/libxl/libxlu_internal.h           |   24 +++-
 tools/libxl/libxlutil.h                 |   11 +-
 tools/libxl/xl_cmdimpl.c                |  147 ++++++++++++++++++++
 xen/arch/x86/numa.c                     |   47 ++++++-
 xen/common/compat/memory.c              |   38 ++++++
 xen/common/kernel.c                     |    1 +
 xen/common/memory.c                     |   58 +++++++-
 xen/include/public/features.h           |    3 +
 xen/include/public/memory.h             |    2 +
 xen/include/xlat.lst                    |    2 +
 37 files changed, 1568 insertions(+), 262 deletions(-)
 create mode 100644 tools/firmware/hvmloader/vnuma.c
 create mode 100644 tools/firmware/hvmloader/vnuma.h
 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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzG-0008Lo-PT; Mon, 01 Dec 2014 15:34:06 +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 1XvSzF-0008KX-42
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:05 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	54/8C-02712-C6A8C745; Mon, 01 Dec 2014 15:34:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12032 invoked from network); 1 Dec 2014 15:34:03 -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;
	1 Dec 2014 15:34:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435606"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-FR;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:32 +0000
Message-ID: <1417448023-27311-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzF-0008Kf-2T; Mon, 01 Dec 2014 15:34: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 1XvSzD-0008Jy-F7
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:03 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	31/66-02957-A6A8C745; Mon, 01 Dec 2014 15:34:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11880 invoked from network); 1 Dec 2014 15:34:02 -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;
	1 Dec 2014 15:34:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435602"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-Bz;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:28 +0000
Message-ID: <1417448023-27311-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 Mon Dec 01 15:34:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvSzH-0008MD-HL; Mon, 01 Dec 2014 15:34: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 1XvSzF-0008Kh-JH
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:05 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	81/D3-07724-C6A8C745; Mon, 01 Dec 2014 15:34:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417448038!14953077!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 21705 invoked from network); 1 Dec 2014 15:34: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;
	1 Dec 2014 15:34:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435609"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-EZ;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:31 +0000
Message-ID: <1417448023-27311-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 6632459..88da7ba 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..d92376d
--- /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 xen_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(xen_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 Mon Dec 01 15:34:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvSzF-0008L6-Ql; Mon, 01 Dec 2014 15:34:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvSzE-0008K7-5a
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:04 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	21/2A-26858-B6A8C745; Mon, 01 Dec 2014 15:34:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417448038!14953077!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21449 invoked from network); 1 Dec 2014 15:34:02 -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;
	1 Dec 2014 15:34:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435601"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-B5;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:27 +0000
Message-ID: <1417448023-27311-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 07d7224..577a017 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -167,6 +167,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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzE-0008KK-CX; Mon, 01 Dec 2014 15:34:04 +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 1XvSzB-0008Jm-Vw
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:02 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	F4/24-02698-96A8C745; Mon, 01 Dec 2014 15:34:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!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 11676 invoked from network); 1 Dec 2014 15:34:00 -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;
	1 Dec 2014 15:34:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435600"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-8i;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:26 +0000
Message-ID: <1417448023-27311-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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>
---
Changes in v2:
1. Return start_extent when vnode translation fails.
2. Expose new feature bit to guest.
3. Fix typo in comment.
---
 xen/common/kernel.c           |    1 +
 xen/common/memory.c           |   58 ++++++++++++++++++++++++++++++++++++++---
 xen/include/public/features.h |    3 +++
 xen/include/public/memory.h   |    2 ++
 4 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index d23c422..9f97f68 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -302,6 +302,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         {
         case 0:
             fi.submap = 0;
+            fi.submap |= (1U << XENFEAT_memory_op_vnode_supported);
             if ( VM_ASSIST(d, VMASST_TYPE_pae_extended_cr3) )
                 fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb);
             if ( paging_mode_translate(current->domain) )
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 9f21bd3..f78c403 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 start_extent;
+        }
+
         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..2110b04 100644
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -99,6 +99,9 @@
 #define XENFEAT_grant_map_identity        12
  */
 
+/* Guest 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 595f953..2b5206b 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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzF-0008Kr-F7; Mon, 01 Dec 2014 15:34: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 1XvSzE-0008K8-3J
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:04 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	20/7D-03148-B6A8C745; Mon, 01 Dec 2014 15:34:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11963 invoked from network); 1 Dec 2014 15:34:02 -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;
	1 Dec 2014 15:34:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435604"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-Cr;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:29 +0000
Message-ID: <1417448023-27311-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 Mon Dec 01 15:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvSzH-0008Lx-4W; Mon, 01 Dec 2014 15:34:07 +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 1XvSzF-0008Kc-ER
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:05 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	0B/66-02957-C6A8C745; Mon, 01 Dec 2014 15:34:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417448037!12212880!7
X-Originating-IP: [66.165.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 12096 invoked from network); 1 Dec 2014 15:34:04 -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;
	1 Dec 2014 15:34:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435605"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-Dj;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:30 +0000
Message-ID: <1417448023-27311-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 a38f695..6632459 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;
+
+    xen_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 Mon Dec 01 15:34:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvSzF-0008L6-Ql; Mon, 01 Dec 2014 15:34:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvSzE-0008K7-5a
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:34:04 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	21/2A-26858-B6A8C745; Mon, 01 Dec 2014 15:34:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417448038!14953077!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21449 invoked from network); 1 Dec 2014 15:34:02 -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;
	1 Dec 2014 15:34:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198435601"
Received: from ukmail1.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, 1 Dec 2014 10:33: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 1XvSyt-0005TR-B5;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:27 +0000
Message-ID: <1417448023-27311-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 07d7224..577a017 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -167,6 +167,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 Mon Dec 01 15:37:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvT2c-0000u6-I4; Mon, 01 Dec 2014 15:37:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XvT2b-0000tt-V5
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 15:37:34 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5A/FE-25276-D3B8C745; Mon, 01 Dec 2014 15:37:33 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417448248!12635859!1
X-Originating-IP: [66.165.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 18014 invoked from network); 1 Dec 2014 15:37:32 -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;
	1 Dec 2014 15:37:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198111630"
Received: from ukmail1.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, 1 Dec 2014 10:37: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 1XvT2L-0005Y4-BU;
	Mon, 01 Dec 2014 15:37:17 +0000
Date: Mon, 1 Dec 2014 15:37:07 +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: <547C6E12.50502@terremark.com>
Message-ID: <alpine.DEB.2.02.1412011528540.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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@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 Mon, 1 Dec 2014, Don Slutz wrote:
> On 11/27/14 05:48, Stefano Stabellini wrote:
> > 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?
> 
> Yes.
> 
> > 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.
> > 
> 
> Works fine in both claim modes and with PoD used (maxmem > memory).  Do
> not know how to test with tmem.  I do not see how it would be worse then
> current
> code that does not auto increase.  I.E. even without a xen change, I think
> something
> like this could be done.

OK, good to know. I am OK with increasing maxmem only if it is strictly
necessary.


> 
> > > 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.
> 
> Ok.  I did find the 32 it is VGA_HOLE_SIZE.  So here is what I have which
> includes
> a lot of extra printf.

In QEMU I would prefer not to assume that libxl increased maxmem for the
vga hole. I would rather call xc_domain_setmaxmem twice for the vga hole
than tie QEMU to a particular maxmem allocation scheme in libxl.

In libxl I would like to avoid increasing mamxem for anything QEMU will
allocate later, that includes rom and vga vram. I am not sure how to
make that work with older QEMU versions that don't call
xc_domain_setmaxmem by themselves yet though. Maybe we could check the
specific QEMU version in libxl and decide based on that. Or we could
export a feature flag in QEMU.



> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -67,6 +67,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t
> *shared_page, int vcpu)
>  #endif
> 
>  #define BUFFER_IO_MAX_DELAY  100
> +#define VGA_HOLE_SIZE (0x20)
> 
>  typedef struct XenPhysmap {
>      hwaddr start_addr;
> @@ -219,6 +220,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
> MemoryRegion *mr)
>      xen_pfn_t *pfn_list;
>      int i;
>      xc_dominfo_t info;
> +    unsigned long max_pages, free_pages, real_free;
> +    long need_pages;
> +    uint64_t tot_pages, pod_cache_pages, pod_entries;
> +
> +    trace_xen_ram_alloc(ram_addr, size, mr->name);
> 
>      if (runstate_check(RUN_STATE_INMIGRATE)) {
>          /* RAM already populated in Xen */
> @@ -232,13 +238,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
> MemoryRegion *mr)
>          return;
>      }
> 
> -    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
> -            " bytes (%ld Kib) of ram at "RAM_ADDR_FMT
> -            " mr.name=%s\n",
> -            __func__, size, (long)(size>>10), ram_addr, mr->name);
> -
> -    trace_xen_ram_alloc(ram_addr, size);
> -
>      nr_pfn = size >> TARGET_PAGE_BITS;
>      pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
> 
> @@ -246,11 +245,38 @@ 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) {
> +    if ((xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) ||
> +       (info.domid != xen_domid)) {
>          hw_error("xc_domain_getinfo failed");
>      }
> -    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;
> +    real_free = free_pages;
> +    if (free_pages > VGA_HOLE_SIZE) {
> +        free_pages -= VGA_HOLE_SIZE;
> +    } else {
> +        free_pages = 0;
> +    }
> +    need_pages = nr_pfn - free_pages;
> +    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
> +            " bytes (%ld KiB) of ram at "RAM_ADDR_FMT
> +            " mp=%ld fp=%ld nr=%ld need=%ld mr.name=%s\n",
> +            __func__, size, (long)(size>>10), ram_addr,
> +           max_pages, free_pages, nr_pfn, need_pages,
> +            mr->name);
> +    if (xc_domain_get_pod_target(xen_xc, xen_domid, &tot_pages,
> +                                 &pod_cache_pages, &pod_entries) >= 0) {
> +        unsigned long populated = tot_pages - pod_cache_pages;
> +        long delta_tot = tot_pages - info.nr_pages;
> +
> +        fprintf(stderr, "%s: PoD pop=%ld tot=%ld(%ld) cnt=%ld ent=%ld nop=%ld
> free=%ld\n",
> +                __func__, populated, (long)tot_pages, delta_tot,
> +                (long)pod_cache_pages, (long)pod_entries,
> +               (long)info.nr_outstanding_pages, real_free);
> +    }

What is the purpose of calling xc_domain_get_pod_target here? It doesn't
look like is affecting the parameters passed to xc_domain_setmaxmem.


> +    if ((free_pages < nr_pfn) &&
> +       (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> +                            (need_pages * 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)) {
> 
> 
> Note: I already had a trace_xen_ram_alloc, here is the delta in trace-events
> (which
> has others not yet sent):
> 
> 
> 
> diff --git a/trace-events b/trace-events
> index eaeecd5..a58fc11 100644
> --- a/trace-events
> +++ b/trace-events
> @@ -908,7 +908,7 @@ pvscsi_tx_rings_ppn(const char* label, uint64_t ppn) "%s
> page: %"PRIx64""
>  pvscsi_tx_rings_num_pages(const char* label, uint32_t num) "Number of %s
> pages: %u"
> 
>  # xen-all.c
> -xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: %#lx,
> size %#lx"
> +xen_ram_alloc(unsigned long ram_addr, unsigned long size, const char*
> mr_name) "requested: %#lx size %#lx mr->name=%s"
>  xen_client_set_memory(uint64_t start_addr, unsigned long size, bool
> log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
>  handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df, uint32_t
> data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
> "I/O=%p type=%d dir=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d
> size=%d"
>  handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t
> data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
> "I/O=%p read type=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d
> size=%d"
> 
> 
>    -Don Slutz
> 
> > 
> > >     -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 Mon Dec 01 15:37:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvT2c-0000u6-I4; Mon, 01 Dec 2014 15:37:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XvT2b-0000tt-V5
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 15:37:34 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5A/FE-25276-D3B8C745; Mon, 01 Dec 2014 15:37:33 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417448248!12635859!1
X-Originating-IP: [66.165.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 18014 invoked from network); 1 Dec 2014 15:37:32 -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;
	1 Dec 2014 15:37:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198111630"
Received: from ukmail1.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, 1 Dec 2014 10:37: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 1XvT2L-0005Y4-BU;
	Mon, 01 Dec 2014 15:37:17 +0000
Date: Mon, 1 Dec 2014 15:37:07 +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: <547C6E12.50502@terremark.com>
Message-ID: <alpine.DEB.2.02.1412011528540.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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@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 Mon, 1 Dec 2014, Don Slutz wrote:
> On 11/27/14 05:48, Stefano Stabellini wrote:
> > 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?
> 
> Yes.
> 
> > 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.
> > 
> 
> Works fine in both claim modes and with PoD used (maxmem > memory).  Do
> not know how to test with tmem.  I do not see how it would be worse then
> current
> code that does not auto increase.  I.E. even without a xen change, I think
> something
> like this could be done.

OK, good to know. I am OK with increasing maxmem only if it is strictly
necessary.


> 
> > > 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.
> 
> Ok.  I did find the 32 it is VGA_HOLE_SIZE.  So here is what I have which
> includes
> a lot of extra printf.

In QEMU I would prefer not to assume that libxl increased maxmem for the
vga hole. I would rather call xc_domain_setmaxmem twice for the vga hole
than tie QEMU to a particular maxmem allocation scheme in libxl.

In libxl I would like to avoid increasing mamxem for anything QEMU will
allocate later, that includes rom and vga vram. I am not sure how to
make that work with older QEMU versions that don't call
xc_domain_setmaxmem by themselves yet though. Maybe we could check the
specific QEMU version in libxl and decide based on that. Or we could
export a feature flag in QEMU.



> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -67,6 +67,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t
> *shared_page, int vcpu)
>  #endif
> 
>  #define BUFFER_IO_MAX_DELAY  100
> +#define VGA_HOLE_SIZE (0x20)
> 
>  typedef struct XenPhysmap {
>      hwaddr start_addr;
> @@ -219,6 +220,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
> MemoryRegion *mr)
>      xen_pfn_t *pfn_list;
>      int i;
>      xc_dominfo_t info;
> +    unsigned long max_pages, free_pages, real_free;
> +    long need_pages;
> +    uint64_t tot_pages, pod_cache_pages, pod_entries;
> +
> +    trace_xen_ram_alloc(ram_addr, size, mr->name);
> 
>      if (runstate_check(RUN_STATE_INMIGRATE)) {
>          /* RAM already populated in Xen */
> @@ -232,13 +238,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
> MemoryRegion *mr)
>          return;
>      }
> 
> -    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
> -            " bytes (%ld Kib) of ram at "RAM_ADDR_FMT
> -            " mr.name=%s\n",
> -            __func__, size, (long)(size>>10), ram_addr, mr->name);
> -
> -    trace_xen_ram_alloc(ram_addr, size);
> -
>      nr_pfn = size >> TARGET_PAGE_BITS;
>      pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
> 
> @@ -246,11 +245,38 @@ 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) {
> +    if ((xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) ||
> +       (info.domid != xen_domid)) {
>          hw_error("xc_domain_getinfo failed");
>      }
> -    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;
> +    real_free = free_pages;
> +    if (free_pages > VGA_HOLE_SIZE) {
> +        free_pages -= VGA_HOLE_SIZE;
> +    } else {
> +        free_pages = 0;
> +    }
> +    need_pages = nr_pfn - free_pages;
> +    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
> +            " bytes (%ld KiB) of ram at "RAM_ADDR_FMT
> +            " mp=%ld fp=%ld nr=%ld need=%ld mr.name=%s\n",
> +            __func__, size, (long)(size>>10), ram_addr,
> +           max_pages, free_pages, nr_pfn, need_pages,
> +            mr->name);
> +    if (xc_domain_get_pod_target(xen_xc, xen_domid, &tot_pages,
> +                                 &pod_cache_pages, &pod_entries) >= 0) {
> +        unsigned long populated = tot_pages - pod_cache_pages;
> +        long delta_tot = tot_pages - info.nr_pages;
> +
> +        fprintf(stderr, "%s: PoD pop=%ld tot=%ld(%ld) cnt=%ld ent=%ld nop=%ld
> free=%ld\n",
> +                __func__, populated, (long)tot_pages, delta_tot,
> +                (long)pod_cache_pages, (long)pod_entries,
> +               (long)info.nr_outstanding_pages, real_free);
> +    }

What is the purpose of calling xc_domain_get_pod_target here? It doesn't
look like is affecting the parameters passed to xc_domain_setmaxmem.


> +    if ((free_pages < nr_pfn) &&
> +       (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> +                            (need_pages * 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)) {
> 
> 
> Note: I already had a trace_xen_ram_alloc, here is the delta in trace-events
> (which
> has others not yet sent):
> 
> 
> 
> diff --git a/trace-events b/trace-events
> index eaeecd5..a58fc11 100644
> --- a/trace-events
> +++ b/trace-events
> @@ -908,7 +908,7 @@ pvscsi_tx_rings_ppn(const char* label, uint64_t ppn) "%s
> page: %"PRIx64""
>  pvscsi_tx_rings_num_pages(const char* label, uint32_t num) "Number of %s
> pages: %u"
> 
>  # xen-all.c
> -xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: %#lx,
> size %#lx"
> +xen_ram_alloc(unsigned long ram_addr, unsigned long size, const char*
> mr_name) "requested: %#lx size %#lx mr->name=%s"
>  xen_client_set_memory(uint64_t start_addr, unsigned long size, bool
> log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
>  handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df, uint32_t
> data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
> "I/O=%p type=%d dir=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d
> size=%d"
>  handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t
> data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
> "I/O=%p read type=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d
> size=%d"
> 
> 
>    -Don Slutz
> 
> > 
> > >     -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 Mon Dec 01 15:45:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:45:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTA5-0001XL-F8; Mon, 01 Dec 2014 15:45:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1XvTA4-0001XG-54
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 15:45:16 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	2A/B8-02696-B0D8C745; Mon, 01 Dec 2014 15:45:15 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417448711!12238403!1
X-Originating-IP: [209.85.215.47]
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 10385 invoked from network); 1 Dec 2014 15:45:11 -0000
Received: from mail-la0-f47.google.com (HELO mail-la0-f47.google.com)
	(209.85.215.47)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 15:45:11 -0000
Received: by mail-la0-f47.google.com with SMTP id hz20so8728960lab.20
	for <xen-devel@lists.xenproject.org>;
	Mon, 01 Dec 2014 07:45:11 -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=V6RLTfzaPhBklhKWXGqeRSCOxKNVPqMlEsII7d5oUCw=;
	b=nDPMk4XBtvF6TeB4UYMIJrZC/9O226RonoZNHRu8o/wJiCEjvzFwkYlTCToMXPZBNR
	Y+d4+RvRrUcaRntNnudiB41CywiNts/VDT2X7kk13gRZT3i/tKOf3xYnmYf4+YGgw7of
	sHRsC1NOvEC8CSzdTtWsoDeW4nxIKFpOhCnwyvIBD3Amc0Eic9mD+6VNLodI6R4bfJ5T
	EBVn1U/UXnhWHcNkqkJXTZHPiixdHbf/AZQyAmVO5ARSsmGzOkJLlI/n8UDwkKJpPGq9
	YUPD3bXMOCxq4Ux29OR/hYfzOsQJWUmu95BWzP3JutOgr0gjuNzGKzwmCeK0OQeuBCZc
	AmTg==
X-Received: by 10.112.166.101 with SMTP id zf5mr59498946lbb.42.1417448710920; 
	Mon, 01 Dec 2014 07:45:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.20.70 with HTTP; Mon, 1 Dec 2014 07:44:50 -0800 (PST)
In-Reply-To: <547C86BF.2040705@citrix.com>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com> <20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
Date: Mon, 1 Dec 2014 10:44:50 -0500
X-Google-Sender-Auth: CzGAbo1oTtTvGZJX7F4TQh0xGao
Message-ID: <CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Juergen Gross <jgross@suse.com>, Joerg Roedel <jroedel@suse.de>,
	kvm@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	x86@kernel.org, Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@suse.de>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 01/12/14 15:05, Luis R. Rodriguez wrote:
>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
>>> [...]
>>>>>> --- 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
>>>
>>> As Juergen points out, this does nothing.  You need to schedule while in
>>> the middle of the hypercall.
>>>
>>> Remember that Xen's hypercall preemption only preempts the hypercall to
>>> run interrupts in the guest.
>>
>> How is it ensured that when the kernel preempts on this code path on
>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
>
> Sorry, I really didn't describe this very well.
>
> If a hypercall needs a continuation, Xen returns to the guest with the
> IP set to the hypercall instruction, and on the way back to the guest
> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
>
> The guest is free to return from the upcall to the original task
> (continuing the hypercall) or to a different one.

OK so that addresses what Xen will do when using continuation and
hypercall preemption, my concern here was that using
preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
hypercall on the return from an interrupt (e.g., the timer interrupt)
would still let the kernel preempt to tasks other than those related
to Xen.

My gripe was that if this was being done it'd be a bit abusive of the
API even if its safe.

  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 15:45:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:45:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTA5-0001XL-F8; Mon, 01 Dec 2014 15:45:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1XvTA4-0001XG-54
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 15:45:16 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	2A/B8-02696-B0D8C745; Mon, 01 Dec 2014 15:45:15 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417448711!12238403!1
X-Originating-IP: [209.85.215.47]
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 10385 invoked from network); 1 Dec 2014 15:45:11 -0000
Received: from mail-la0-f47.google.com (HELO mail-la0-f47.google.com)
	(209.85.215.47)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 15:45:11 -0000
Received: by mail-la0-f47.google.com with SMTP id hz20so8728960lab.20
	for <xen-devel@lists.xenproject.org>;
	Mon, 01 Dec 2014 07:45:11 -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=V6RLTfzaPhBklhKWXGqeRSCOxKNVPqMlEsII7d5oUCw=;
	b=nDPMk4XBtvF6TeB4UYMIJrZC/9O226RonoZNHRu8o/wJiCEjvzFwkYlTCToMXPZBNR
	Y+d4+RvRrUcaRntNnudiB41CywiNts/VDT2X7kk13gRZT3i/tKOf3xYnmYf4+YGgw7of
	sHRsC1NOvEC8CSzdTtWsoDeW4nxIKFpOhCnwyvIBD3Amc0Eic9mD+6VNLodI6R4bfJ5T
	EBVn1U/UXnhWHcNkqkJXTZHPiixdHbf/AZQyAmVO5ARSsmGzOkJLlI/n8UDwkKJpPGq9
	YUPD3bXMOCxq4Ux29OR/hYfzOsQJWUmu95BWzP3JutOgr0gjuNzGKzwmCeK0OQeuBCZc
	AmTg==
X-Received: by 10.112.166.101 with SMTP id zf5mr59498946lbb.42.1417448710920; 
	Mon, 01 Dec 2014 07:45:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.20.70 with HTTP; Mon, 1 Dec 2014 07:44:50 -0800 (PST)
In-Reply-To: <547C86BF.2040705@citrix.com>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com> <20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
Date: Mon, 1 Dec 2014 10:44:50 -0500
X-Google-Sender-Auth: CzGAbo1oTtTvGZJX7F4TQh0xGao
Message-ID: <CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Juergen Gross <jgross@suse.com>, Joerg Roedel <jroedel@suse.de>,
	kvm@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	x86@kernel.org, Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@suse.de>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 01/12/14 15:05, Luis R. Rodriguez wrote:
>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
>>> [...]
>>>>>> --- 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
>>>
>>> As Juergen points out, this does nothing.  You need to schedule while in
>>> the middle of the hypercall.
>>>
>>> Remember that Xen's hypercall preemption only preempts the hypercall to
>>> run interrupts in the guest.
>>
>> How is it ensured that when the kernel preempts on this code path on
>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
>
> Sorry, I really didn't describe this very well.
>
> If a hypercall needs a continuation, Xen returns to the guest with the
> IP set to the hypercall instruction, and on the way back to the guest
> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
>
> The guest is free to return from the upcall to the original task
> (continuing the hypercall) or to a different one.

OK so that addresses what Xen will do when using continuation and
hypercall preemption, my concern here was that using
preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
hypercall on the return from an interrupt (e.g., the timer interrupt)
would still let the kernel preempt to tasks other than those related
to Xen.

My gripe was that if this was being done it'd be a bit abusive of the
API even if its safe.

  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 15:48:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvTCn-0001de-4D; Mon, 01 Dec 2014 15:48:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1XvTCl-0001dW-Nx
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 15:48:03 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	9B/E6-22737-3BD8C745; Mon, 01 Dec 2014 15:48:03 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417448882!7985779!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 9000 invoked from network); 1 Dec 2014 15:48:02 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-16.tower-206.messagelabs.com with SMTP;
	1 Dec 2014 15:48:02 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 304BC1640E7;
	Mon,  1 Dec 2014 15:47:38 +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 WkxZeRKeqCYt; Mon,  1 Dec 2014 15:47:32 +0000 (GMT)
Received: from zimbra.overnetdata.com (zimbra.overnetdata.com [192.168.1.204])
	by zimbra.overnetdata.com (Postfix) with ESMTP id B4437161B92;
	Mon,  1 Dec 2014 15:47:32 +0000 (GMT)
Date: Mon, 1 Dec 2014 15:47:32 +0000 (GMT)
From: Anthony Wright <anthony@overnetdata.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <13856190.12.1417448852473.JavaMail.root@zimbra.overnetdata.com>
In-Reply-To: <547C79C0.4010608@citrix.com>
MIME-Version: 1.0
X-Originating-IP: [192.168.1.31]
X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661)
Cc: 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/14 15:19, Anthony Wright wrote:
> > 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
> 
> The guest's frontend driver isn't putting valid requests onto the ring
> (it crosses a page boundary) so this is a frontend bug.
> 
> What guest are you running?

We're running a custom built 64 bit para-virtualised DomU with a stock Linux 3.17.3 downloaded from kernel.org. The problem only started happening when we upgraded the DomU Linux kernel from 3.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 Dec 01 15:48:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvTCn-0001de-4D; Mon, 01 Dec 2014 15:48:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1XvTCl-0001dW-Nx
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 15:48:03 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	9B/E6-22737-3BD8C745; Mon, 01 Dec 2014 15:48:03 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417448882!7985779!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 9000 invoked from network); 1 Dec 2014 15:48:02 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-16.tower-206.messagelabs.com with SMTP;
	1 Dec 2014 15:48:02 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 304BC1640E7;
	Mon,  1 Dec 2014 15:47:38 +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 WkxZeRKeqCYt; Mon,  1 Dec 2014 15:47:32 +0000 (GMT)
Received: from zimbra.overnetdata.com (zimbra.overnetdata.com [192.168.1.204])
	by zimbra.overnetdata.com (Postfix) with ESMTP id B4437161B92;
	Mon,  1 Dec 2014 15:47:32 +0000 (GMT)
Date: Mon, 1 Dec 2014 15:47:32 +0000 (GMT)
From: Anthony Wright <anthony@overnetdata.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <13856190.12.1417448852473.JavaMail.root@zimbra.overnetdata.com>
In-Reply-To: <547C79C0.4010608@citrix.com>
MIME-Version: 1.0
X-Originating-IP: [192.168.1.31]
X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661)
Cc: 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/14 15:19, Anthony Wright wrote:
> > 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
> 
> The guest's frontend driver isn't putting valid requests onto the ring
> (it crosses a page boundary) so this is a frontend bug.
> 
> What guest are you running?

We're running a custom built 64 bit para-virtualised DomU with a stock Linux 3.17.3 downloaded from kernel.org. The problem only started happening when we upgraded the DomU Linux kernel from 3.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 Dec 01 15:50:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvTFI-0001mr-Sx; Mon, 01 Dec 2014 15:50:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XvTFH-0001mg-Gs
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 15:50:39 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	7A/36-22777-E4E8C745; Mon, 01 Dec 2014 15:50:38 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417449038!10888125!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 29461 invoked from network); 1 Dec 2014 15:50:38 -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; 1 Dec 2014 15:50:38 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id EC7E3ABCA;
	Mon,  1 Dec 2014 15:50:36 +0000 (UTC)
Date: Mon, 1 Dec 2014 16:50:36 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141201155036.GD25677@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> <5477FECF.2060404@suse.com>
	<547C4A7E.6020207@citrix.com>
	<20141201133245.GA25677@wotan.suse.de> <547C7E59.9040408@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C7E59.9040408@suse.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@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>, Ingo Molnar <mingo@kernel.org>
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 Mon, Dec 01, 2014 at 03:42:33PM +0100, Juergen Gross wrote:
> On 12/01/2014 02:32 PM, Luis R. Rodriguez wrote:
>> On Mon, Dec 01, 2014 at 11:01:18AM +0000, David Vrabel wrote:
>>> On 28/11/14 04:49, Juergen Gross wrote:
>>>> On 11/27/2014 07:50 PM, Andrew Cooper wrote:
>>>>>
>>>>> 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.
>>>
>>> I dropped it because it copy-and-paste a bunch of otherwise generic x86
>>> assembler and looked unlikely to get an x86 maintainer ack.  If you
>>> think otherwise, feel free to pick it up and run with it.
>>
>> I was trying to run with it, but my biggest gripe with this was
>> the use of preempt_schedule_irq(), but we can review that on the
>> other thread.

So much for the other thread :)

> I think this can be handled completely inside xen_evtchn_do_upcall().
>
> xen_preemptible_hcall_begin() (possibly with another name) could take
> the pointer of a function as parameter which is used as continuation
> point after an asynchronous interrupt in the critical section.

Oh so we'd only preempt to one specific task?

> Parameter for that function would be the exception frame of the
> original interrupt to be able to continue at the interrupted position
> after e.g. calling schedule().

Interesting... if reasonable I wonder if this should be generalized.
Are there other CONFIG_PREEMPT=n use cases for such excemptions?

  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 15:50:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvTFI-0001mr-Sx; Mon, 01 Dec 2014 15:50:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XvTFH-0001mg-Gs
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 15:50:39 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	7A/36-22777-E4E8C745; Mon, 01 Dec 2014 15:50:38 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417449038!10888125!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 29461 invoked from network); 1 Dec 2014 15:50:38 -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; 1 Dec 2014 15:50:38 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id EC7E3ABCA;
	Mon,  1 Dec 2014 15:50:36 +0000 (UTC)
Date: Mon, 1 Dec 2014 16:50:36 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141201155036.GD25677@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> <5477FECF.2060404@suse.com>
	<547C4A7E.6020207@citrix.com>
	<20141201133245.GA25677@wotan.suse.de> <547C7E59.9040408@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C7E59.9040408@suse.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@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>, Ingo Molnar <mingo@kernel.org>
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 Mon, Dec 01, 2014 at 03:42:33PM +0100, Juergen Gross wrote:
> On 12/01/2014 02:32 PM, Luis R. Rodriguez wrote:
>> On Mon, Dec 01, 2014 at 11:01:18AM +0000, David Vrabel wrote:
>>> On 28/11/14 04:49, Juergen Gross wrote:
>>>> On 11/27/2014 07:50 PM, Andrew Cooper wrote:
>>>>>
>>>>> 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.
>>>
>>> I dropped it because it copy-and-paste a bunch of otherwise generic x86
>>> assembler and looked unlikely to get an x86 maintainer ack.  If you
>>> think otherwise, feel free to pick it up and run with it.
>>
>> I was trying to run with it, but my biggest gripe with this was
>> the use of preempt_schedule_irq(), but we can review that on the
>> other thread.

So much for the other thread :)

> I think this can be handled completely inside xen_evtchn_do_upcall().
>
> xen_preemptible_hcall_begin() (possibly with another name) could take
> the pointer of a function as parameter which is used as continuation
> point after an asynchronous interrupt in the critical section.

Oh so we'd only preempt to one specific task?

> Parameter for that function would be the exception frame of the
> original interrupt to be able to continue at the interrupted position
> after e.g. calling schedule().

Interesting... if reasonable I wonder if this should be generalized.
Are there other CONFIG_PREEMPT=n use cases for such excemptions?

  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 15:54:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:54:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTJ3-0002Ak-Hr; Mon, 01 Dec 2014 15:54:33 +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 1XvTJ2-0002AZ-07
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 15:54:32 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D1/D2-15461-73F8C745; Mon, 01 Dec 2014 15:54:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417449269!12603220!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 16740 invoked from network); 1 Dec 2014 15:54:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 15:54:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198444920"
Message-ID: <547C8F30.1010306@citrix.com>
Date: Mon, 1 Dec 2014 15:54:24 +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: "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>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
In-Reply-To: <CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
X-DLP: MIA1
Cc: Juergen Gross <jgross@suse.com>, Joerg Roedel <jroedel@suse.de>,
	kvm@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	x86@kernel.org, Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@suse.de>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 01/12/14 15:44, Luis R. Rodriguez wrote:
> On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 01/12/14 15:05, Luis R. Rodriguez wrote:
>>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
>>>> [...]
>>>>>>> --- 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
>>>>
>>>> As Juergen points out, this does nothing.  You need to schedule while in
>>>> the middle of the hypercall.
>>>>
>>>> Remember that Xen's hypercall preemption only preempts the hypercall to
>>>> run interrupts in the guest.
>>>
>>> How is it ensured that when the kernel preempts on this code path on
>>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
>>
>> Sorry, I really didn't describe this very well.
>>
>> If a hypercall needs a continuation, Xen returns to the guest with the
>> IP set to the hypercall instruction, and on the way back to the guest
>> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
>>
>> The guest is free to return from the upcall to the original task
>> (continuing the hypercall) or to a different one.
> 
> OK so that addresses what Xen will do when using continuation and
> hypercall preemption, my concern here was that using
> preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
> hypercall on the return from an interrupt (e.g., the timer interrupt)
> would still let the kernel preempt to tasks other than those related
> to Xen.

Um.  Why would that be a problem?  We do want to switch to any task the
Linux scheduler thinks is best.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 15:54:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:54:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTJ3-0002Ak-Hr; Mon, 01 Dec 2014 15:54:33 +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 1XvTJ2-0002AZ-07
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 15:54:32 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D1/D2-15461-73F8C745; Mon, 01 Dec 2014 15:54:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417449269!12603220!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 16740 invoked from network); 1 Dec 2014 15:54:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 15:54:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198444920"
Message-ID: <547C8F30.1010306@citrix.com>
Date: Mon, 1 Dec 2014 15:54:24 +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: "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>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
In-Reply-To: <CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
X-DLP: MIA1
Cc: Juergen Gross <jgross@suse.com>, Joerg Roedel <jroedel@suse.de>,
	kvm@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	x86@kernel.org, Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@suse.de>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 01/12/14 15:44, Luis R. Rodriguez wrote:
> On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 01/12/14 15:05, Luis R. Rodriguez wrote:
>>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
>>>> [...]
>>>>>>> --- 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
>>>>
>>>> As Juergen points out, this does nothing.  You need to schedule while in
>>>> the middle of the hypercall.
>>>>
>>>> Remember that Xen's hypercall preemption only preempts the hypercall to
>>>> run interrupts in the guest.
>>>
>>> How is it ensured that when the kernel preempts on this code path on
>>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
>>
>> Sorry, I really didn't describe this very well.
>>
>> If a hypercall needs a continuation, Xen returns to the guest with the
>> IP set to the hypercall instruction, and on the way back to the guest
>> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
>>
>> The guest is free to return from the upcall to the original task
>> (continuing the hypercall) or to a different one.
> 
> OK so that addresses what Xen will do when using continuation and
> hypercall preemption, my concern here was that using
> preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
> hypercall on the return from an interrupt (e.g., the timer interrupt)
> would still let the kernel preempt to tasks other than those related
> to Xen.

Um.  Why would that be a problem?  We do want to switch to any task the
Linux scheduler thinks is best.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKR-0002Km-R8; Mon, 01 Dec 2014 15:55: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 1XvTKR-0002KM-B8
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:55:59 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	F0/72-26652-E8F8C745; Mon, 01 Dec 2014 15:55:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417449348!10848645!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9854 invoked from network); 1 Dec 2014 15:55:56 -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;
	1 Dec 2014 15:55:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198119887"
Received: from ukmail1.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, 1 Dec 2014 10:55:55 -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 1XvSyt-0005TR-H9;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:34 +0000
Message-ID: <1417448023-27311-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 Mon Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKT-0002LU-8U; Mon, 01 Dec 2014 15:56:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvTKR-0002Kb-S2
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:56:00 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	18/C0-31453-F8F8C745; Mon, 01 Dec 2014 15:55:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417449353!5461859!1
X-Originating-IP: [66.165.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 26851 invoked from network); 1 Dec 2014 15:55:58 -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;
	1 Dec 2014 15:55:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198119903"
Received: from ukmail1.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, 1 Dec 2014 10:55:57 -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 1XvSyt-0005TR-Lv;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:38 +0000
Message-ID: <1417448023-27311-15-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 14/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>
---
Changes in v2:
1. Adapt to new vNUMA retrieval routine.
2. Move SLIT very late in secondary table build.
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |    8 +++++++
 tools/firmware/hvmloader/acpi/build.c   |   40 ++++++++++++++++++++++++++++++-
 2 files changed, 47 insertions(+), 1 deletion(-)

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 917b2c9..51c737e 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 = nr_vnodes * nr_vnodes;
+    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] = vdistance[i];
+
+    slit->localities = nr_vnodes;
+
+    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;
@@ -407,7 +440,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         }
     }
 
-    /* SRAT */
+    /* SRAT and SLIT */
     if ( nr_vnodes > 0 )
     {
         srat = construct_srat();
@@ -415,6 +448,11 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
             table_ptrs[nr_tables++] = (unsigned long)srat;
         else
             printf("Failed to build SRAT, skipping...\n");
+        slit = construct_slit();
+        if (srat)
+            table_ptrs[nr_tables++] = (unsigned long)slit;
+        else
+            printf("Failed to build SLIT, skipping...\n");
     }
 
     /* Load any additional tables passed through. */
-- 
1.7.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 Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKT-0002LU-8U; Mon, 01 Dec 2014 15:56:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvTKR-0002Kb-S2
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:56:00 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	18/C0-31453-F8F8C745; Mon, 01 Dec 2014 15:55:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417449353!5461859!1
X-Originating-IP: [66.165.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 26851 invoked from network); 1 Dec 2014 15:55:58 -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;
	1 Dec 2014 15:55:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198119903"
Received: from ukmail1.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, 1 Dec 2014 10:55:57 -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 1XvSyt-0005TR-Lv;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:38 +0000
Message-ID: <1417448023-27311-15-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 14/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>
---
Changes in v2:
1. Adapt to new vNUMA retrieval routine.
2. Move SLIT very late in secondary table build.
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |    8 +++++++
 tools/firmware/hvmloader/acpi/build.c   |   40 ++++++++++++++++++++++++++++++-
 2 files changed, 47 insertions(+), 1 deletion(-)

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 917b2c9..51c737e 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 = nr_vnodes * nr_vnodes;
+    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] = vdistance[i];
+
+    slit->localities = nr_vnodes;
+
+    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;
@@ -407,7 +440,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         }
     }
 
-    /* SRAT */
+    /* SRAT and SLIT */
     if ( nr_vnodes > 0 )
     {
         srat = construct_srat();
@@ -415,6 +448,11 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
             table_ptrs[nr_tables++] = (unsigned long)srat;
         else
             printf("Failed to build SRAT, skipping...\n");
+        slit = construct_slit();
+        if (srat)
+            table_ptrs[nr_tables++] = (unsigned long)slit;
+        else
+            printf("Failed to build SLIT, skipping...\n");
     }
 
     /* Load any additional tables passed through. */
-- 
1.7.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 Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKR-0002Km-R8; Mon, 01 Dec 2014 15:55: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 1XvTKR-0002KM-B8
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:55:59 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	F0/72-26652-E8F8C745; Mon, 01 Dec 2014 15:55:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417449348!10848645!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9854 invoked from network); 1 Dec 2014 15:55:56 -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;
	1 Dec 2014 15:55:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198119887"
Received: from ukmail1.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, 1 Dec 2014 10:55:55 -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 1XvSyt-0005TR-H9;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:34 +0000
Message-ID: <1417448023-27311-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 Mon Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKO-0002JO-8x; Mon, 01 Dec 2014 15:55:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvTKM-0002Ie-RL
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:55:55 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	75/01-22777-A8F8C745; Mon, 01 Dec 2014 15:55:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417449348!10848645!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9374 invoked from network); 1 Dec 2014 15:55: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;
	1 Dec 2014 15:55:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198119843"
Received: from ukmail1.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, 1 Dec 2014 10:55:50 -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 1XvSyt-0005TR-Mn;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:39 +0000
Message-ID: <1417448023-27311-16-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 Mon Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKM-0002Ik-GS; Mon, 01 Dec 2014 15:55: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 1XvTKK-0002IC-LC
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:55:52 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	0D/23-11581-78F8C745; Mon, 01 Dec 2014 15:55:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417449348!10848645!1
X-Originating-IP: [66.165.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 9253 invoked from network); 1 Dec 2014 15:55:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 15:55:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198119764"
Received: from ukmail1.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, 1 Dec 2014 10:55: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 1XvSyt-0005TR-Pk;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:41 +0000
Message-ID: <1417448023-27311-18-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 17/19] libxl: 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

Disallow 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 relocating low memory to high
memory gives us a sub-optimal configuration.

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>
---
 tools/libxl/libxl_dm.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..8631343 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1345,13 +1345,15 @@ void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss)
                         libxl__sprintf(gc, "%s/hvmloader/bios", path),
                         "%s", libxl_bios_type_to_string(b_info->u.hvm.bios));
         /* Disable relocating memory to make the MMIO hole larger
-         * unless we're running qemu-traditional */
+         * unless we're running qemu-traditional and vNUMA is not
+         * configured. */
         libxl__xs_write(gc, XBT_NULL,
                         libxl__sprintf(gc,
                                        "%s/hvmloader/allow-memory-relocate",
                                        path),
                         "%d",
-                        b_info->device_model_version==LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL);
+                        b_info->device_model_version==LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
+                        !b_info->num_vnuma_nodes);
         free(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 Mon Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKO-0002JO-8x; Mon, 01 Dec 2014 15:55:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvTKM-0002Ie-RL
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:55:55 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	75/01-22777-A8F8C745; Mon, 01 Dec 2014 15:55:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417449348!10848645!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9374 invoked from network); 1 Dec 2014 15:55: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;
	1 Dec 2014 15:55:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198119843"
Received: from ukmail1.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, 1 Dec 2014 10:55:50 -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 1XvSyt-0005TR-Mn;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:39 +0000
Message-ID: <1417448023-27311-16-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 Mon Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKa-0002Pb-Mp; Mon, 01 Dec 2014 15:56: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 1XvTKZ-0002OS-Cy
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:56:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	54/75-15461-59F8C745; Mon, 01 Dec 2014 15:56:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417449361!12613050!1
X-Originating-IP: [66.165.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 25143 invoked from network); 1 Dec 2014 15:56:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 15:56:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198119921"
Received: from ukmail1.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, 1 Dec 2014 10:56:00 -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 1XvSyt-0005TR-Jq;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:37 +0000
Message-ID: <1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 13/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>
---
Changes in v2:
1. Remove explicit zero initializers.
2. Adapt to new vNUMA retrieval routine.
3. Move SRAT very late in secondary table build.
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |   53 +++++++++++++++++++++++
 tools/firmware/hvmloader/acpi/build.c   |   71 +++++++++++++++++++++++++++++++
 2 files changed, 124 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..917b2c9 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -23,6 +23,7 @@
 #include "ssdt_pm.h"
 #include "../config.h"
 #include "../util.h"
+#include "../vnuma.h"
 #include <xen/hvm/hvm_xs_strings.h>
 #include <xen/hvm/params.h>
 
@@ -203,6 +204,65 @@ 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) * 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   = vcpu_to_vnode[i];
+        processor->apic_id  = LAPIC_ID(i);
+        processor->flags    = ACPI_LOCAL_APIC_AFFIN_ENABLED;
+        processor++;
+    }
+
+    memory = (struct acpi_20_srat_memory *)processor;
+    for ( i = 0; i < nr_vmemranges; i++ )
+    {
+        mem = vmemrange[i].end - vmemrange[i].start;
+        memset(memory, 0, sizeof(*memory));
+        memory->type          = ACPI_MEMORY_AFFINITY;
+        memory->length        = sizeof(*memory);
+        memory->domain        = vmemrange[i].nid;
+        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
+        memory->base_address  = vmemrange[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;
@@ -346,6 +407,16 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         }
     }
 
+    /* SRAT */
+    if ( nr_vnodes > 0 )
+    {
+        srat = construct_srat();
+        if (srat)
+            table_ptrs[nr_tables++] = (unsigned long)srat;
+        else
+            printf("Failed to build SRAT, skipping...\n");
+    }
+
     /* Load any additional tables passed through. */
     nr_tables += construct_passthrough_tables(table_ptrs, nr_tables);
 
-- 
1.7.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 Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKM-0002Is-S6; Mon, 01 Dec 2014 15:55: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 1XvTKL-0002IP-AI
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:55:53 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	80/25-25714-88F8C745; Mon, 01 Dec 2014 15:55:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417449346!10887326!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 16514 invoked from network); 1 Dec 2014 15:55: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;
	1 Dec 2014 15:55:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198445549"
Received: from ukmail1.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, 1 Dec 2014 10:55:47 -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 1XvSyt-0005TR-J3;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:36 +0000
Message-ID: <1417448023-27311-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 12/19] hvmloader: retrieve vNUMA information
	from 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

Hvmloader issues XENMEM_get_vnumainfo hypercall and stores the
information retrieved in scratch space for later use.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 tools/firmware/hvmloader/Makefile    |    2 +-
 tools/firmware/hvmloader/hvmloader.c |    3 ++
 tools/firmware/hvmloader/vnuma.c     |   84 ++++++++++++++++++++++++++++++++++
 tools/firmware/hvmloader/vnuma.h     |   56 +++++++++++++++++++++++
 4 files changed, 144 insertions(+), 1 deletion(-)
 create mode 100644 tools/firmware/hvmloader/vnuma.c
 create mode 100644 tools/firmware/hvmloader/vnuma.h

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 46a79c5..a5af34b 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -29,7 +29,7 @@ LOADADDR = 0x100000
 CFLAGS += $(CFLAGS_xeninclude)
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
-OBJS += smp.o cacheattr.o xenbus.o
+OBJS += smp.o cacheattr.o xenbus.o vnuma.o
 OBJS += e820.o pci.o pir.o ctype.o
 OBJS += hvm_param.o
 ifeq ($(debug),y)
diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index 7b0da38..2aa2f76 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -26,6 +26,7 @@
 #include "pci_regs.h"
 #include "apic_regs.h"
 #include "acpi/acpi2_0.h"
+#include "vnuma.h"
 #include <xen/version.h>
 #include <xen/hvm/params.h>
 
@@ -261,6 +262,8 @@ int main(void)
 
     init_hypercalls();
 
+    init_vnuma_info();
+
     xenbus_setup();
 
     bios = detect_bios();
diff --git a/tools/firmware/hvmloader/vnuma.c b/tools/firmware/hvmloader/vnuma.c
new file mode 100644
index 0000000..cd26f4f
--- /dev/null
+++ b/tools/firmware/hvmloader/vnuma.c
@@ -0,0 +1,84 @@
+/*
+ * vnuma.c: obtain vNUMA information from hypervisor
+ *
+ * Copyright (c) 2014 Wei Liu, Citrix Systems (R&D) Ltd.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL AUTHOR 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 "util.h"
+#include "hypercall.h"
+#include "vnuma.h"
+#include <errno.h>
+
+unsigned int nr_vnodes, nr_vmemranges;
+unsigned int *vcpu_to_vnode, *vdistance;
+xen_vmemrange_t *vmemrange;
+
+void init_vnuma_info(void)
+{
+    int rc, retry = 0;
+    struct xen_vnuma_topology_info vnuma_topo = {
+        .domid = DOMID_SELF,
+    };
+
+    vcpu_to_vnode = scratch_alloc(sizeof(uint32_t) * hvm_info->nr_vcpus, 0);
+    vdistance = scratch_alloc(sizeof(uint32_t) * MAX_VDISTANCE, 0);
+    vmemrange = scratch_alloc(sizeof(xen_vmemrange_t) * MAX_VMEMRANGES, 0);
+
+    vnuma_topo.nr_vnodes = MAX_VNODES;
+    vnuma_topo.nr_vcpus = hvm_info->nr_vcpus;
+    vnuma_topo.nr_vmemranges = MAX_VMEMRANGES;
+
+    set_xen_guest_handle(vnuma_topo.vdistance.h, vdistance);
+    set_xen_guest_handle(vnuma_topo.vcpu_to_vnode.h, vcpu_to_vnode);
+    set_xen_guest_handle(vnuma_topo.vmemrange.h, vmemrange);
+
+    rc = hypercall_memory_op(XENMEM_get_vnumainfo, &vnuma_topo);
+    while ( rc == -EAGAIN && retry < 10 )
+    {
+        rc = hypercall_memory_op(XENMEM_get_vnumainfo, &vnuma_topo);
+        retry++;
+    }
+    if ( rc < 0 )
+    {
+        printf("Failed to retrieve vNUMA information, rc = %d\n", rc);
+        goto out;
+    }
+
+    nr_vnodes = vnuma_topo.nr_vnodes;
+    nr_vmemranges = vnuma_topo.nr_vmemranges;
+
+out:
+    return;
+}
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/firmware/hvmloader/vnuma.h b/tools/firmware/hvmloader/vnuma.h
new file mode 100644
index 0000000..0779b83
--- /dev/null
+++ b/tools/firmware/hvmloader/vnuma.h
@@ -0,0 +1,56 @@
+/******************************************************************************
+ * vnuma.h
+ *
+ * Copyright (c) 2014, Wei Liu
+ *
+ * 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 __HVMLOADER_VNUMA_H__
+#define __HVMLOADER_VNUMA_H__
+
+#include <xen/memory.h>
+
+#define MAX_VNODES     64
+#define MAX_VDISTANCE  (MAX_VNODES * MAX_VNODES)
+#define MAX_VMEMRANGES (MAX_VNODES * 2)
+
+extern unsigned int nr_vnodes, nr_vmemranges;
+extern unsigned int *vcpu_to_vnode, *vdistance;
+extern xen_vmemrange_t *vmemrange;
+
+void init_vnuma_info(void);
+
+#endif /* __HVMLOADER_VNUMA_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 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 Mon Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKM-0002Ia-5L; Mon, 01 Dec 2014 15:55: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 1XvTKK-0002IA-8S
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:55:52 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	2D/E0-22777-78F8C745; Mon, 01 Dec 2014 15:55:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417449346!10887326!1
X-Originating-IP: [66.165.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 15081 invoked from network); 1 Dec 2014 15:55:50 -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;
	1 Dec 2014 15:55:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198445510"
Received: from ukmail1.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, 1 Dec 2014 10:55: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 1XvSyt-0005TR-Nf;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:40 +0000
Message-ID: <1417448023-27311-17-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 1198225..11b20d2 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -845,6 +845,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 1678715..13c05c4 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 b8d9268..08a7639 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;
+    xen_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(xen_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 Mon Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKM-0002Ik-GS; Mon, 01 Dec 2014 15:55: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 1XvTKK-0002IC-LC
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:55:52 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	0D/23-11581-78F8C745; Mon, 01 Dec 2014 15:55:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417449348!10848645!1
X-Originating-IP: [66.165.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 9253 invoked from network); 1 Dec 2014 15:55:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 15:55:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198119764"
Received: from ukmail1.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, 1 Dec 2014 10:55: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 1XvSyt-0005TR-Pk;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:41 +0000
Message-ID: <1417448023-27311-18-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 17/19] libxl: 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

Disallow 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 relocating low memory to high
memory gives us a sub-optimal configuration.

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>
---
 tools/libxl/libxl_dm.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..8631343 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1345,13 +1345,15 @@ void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss)
                         libxl__sprintf(gc, "%s/hvmloader/bios", path),
                         "%s", libxl_bios_type_to_string(b_info->u.hvm.bios));
         /* Disable relocating memory to make the MMIO hole larger
-         * unless we're running qemu-traditional */
+         * unless we're running qemu-traditional and vNUMA is not
+         * configured. */
         libxl__xs_write(gc, XBT_NULL,
                         libxl__sprintf(gc,
                                        "%s/hvmloader/allow-memory-relocate",
                                        path),
                         "%d",
-                        b_info->device_model_version==LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL);
+                        b_info->device_model_version==LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
+                        !b_info->num_vnuma_nodes);
         free(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 Mon Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKM-0002Is-S6; Mon, 01 Dec 2014 15:55: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 1XvTKL-0002IP-AI
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:55:53 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	80/25-25714-88F8C745; Mon, 01 Dec 2014 15:55:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417449346!10887326!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 16514 invoked from network); 1 Dec 2014 15:55: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;
	1 Dec 2014 15:55:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198445549"
Received: from ukmail1.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, 1 Dec 2014 10:55:47 -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 1XvSyt-0005TR-J3;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:36 +0000
Message-ID: <1417448023-27311-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 12/19] hvmloader: retrieve vNUMA information
	from 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

Hvmloader issues XENMEM_get_vnumainfo hypercall and stores the
information retrieved in scratch space for later use.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 tools/firmware/hvmloader/Makefile    |    2 +-
 tools/firmware/hvmloader/hvmloader.c |    3 ++
 tools/firmware/hvmloader/vnuma.c     |   84 ++++++++++++++++++++++++++++++++++
 tools/firmware/hvmloader/vnuma.h     |   56 +++++++++++++++++++++++
 4 files changed, 144 insertions(+), 1 deletion(-)
 create mode 100644 tools/firmware/hvmloader/vnuma.c
 create mode 100644 tools/firmware/hvmloader/vnuma.h

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 46a79c5..a5af34b 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -29,7 +29,7 @@ LOADADDR = 0x100000
 CFLAGS += $(CFLAGS_xeninclude)
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
-OBJS += smp.o cacheattr.o xenbus.o
+OBJS += smp.o cacheattr.o xenbus.o vnuma.o
 OBJS += e820.o pci.o pir.o ctype.o
 OBJS += hvm_param.o
 ifeq ($(debug),y)
diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index 7b0da38..2aa2f76 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -26,6 +26,7 @@
 #include "pci_regs.h"
 #include "apic_regs.h"
 #include "acpi/acpi2_0.h"
+#include "vnuma.h"
 #include <xen/version.h>
 #include <xen/hvm/params.h>
 
@@ -261,6 +262,8 @@ int main(void)
 
     init_hypercalls();
 
+    init_vnuma_info();
+
     xenbus_setup();
 
     bios = detect_bios();
diff --git a/tools/firmware/hvmloader/vnuma.c b/tools/firmware/hvmloader/vnuma.c
new file mode 100644
index 0000000..cd26f4f
--- /dev/null
+++ b/tools/firmware/hvmloader/vnuma.c
@@ -0,0 +1,84 @@
+/*
+ * vnuma.c: obtain vNUMA information from hypervisor
+ *
+ * Copyright (c) 2014 Wei Liu, Citrix Systems (R&D) Ltd.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL AUTHOR 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 "util.h"
+#include "hypercall.h"
+#include "vnuma.h"
+#include <errno.h>
+
+unsigned int nr_vnodes, nr_vmemranges;
+unsigned int *vcpu_to_vnode, *vdistance;
+xen_vmemrange_t *vmemrange;
+
+void init_vnuma_info(void)
+{
+    int rc, retry = 0;
+    struct xen_vnuma_topology_info vnuma_topo = {
+        .domid = DOMID_SELF,
+    };
+
+    vcpu_to_vnode = scratch_alloc(sizeof(uint32_t) * hvm_info->nr_vcpus, 0);
+    vdistance = scratch_alloc(sizeof(uint32_t) * MAX_VDISTANCE, 0);
+    vmemrange = scratch_alloc(sizeof(xen_vmemrange_t) * MAX_VMEMRANGES, 0);
+
+    vnuma_topo.nr_vnodes = MAX_VNODES;
+    vnuma_topo.nr_vcpus = hvm_info->nr_vcpus;
+    vnuma_topo.nr_vmemranges = MAX_VMEMRANGES;
+
+    set_xen_guest_handle(vnuma_topo.vdistance.h, vdistance);
+    set_xen_guest_handle(vnuma_topo.vcpu_to_vnode.h, vcpu_to_vnode);
+    set_xen_guest_handle(vnuma_topo.vmemrange.h, vmemrange);
+
+    rc = hypercall_memory_op(XENMEM_get_vnumainfo, &vnuma_topo);
+    while ( rc == -EAGAIN && retry < 10 )
+    {
+        rc = hypercall_memory_op(XENMEM_get_vnumainfo, &vnuma_topo);
+        retry++;
+    }
+    if ( rc < 0 )
+    {
+        printf("Failed to retrieve vNUMA information, rc = %d\n", rc);
+        goto out;
+    }
+
+    nr_vnodes = vnuma_topo.nr_vnodes;
+    nr_vmemranges = vnuma_topo.nr_vmemranges;
+
+out:
+    return;
+}
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/firmware/hvmloader/vnuma.h b/tools/firmware/hvmloader/vnuma.h
new file mode 100644
index 0000000..0779b83
--- /dev/null
+++ b/tools/firmware/hvmloader/vnuma.h
@@ -0,0 +1,56 @@
+/******************************************************************************
+ * vnuma.h
+ *
+ * Copyright (c) 2014, Wei Liu
+ *
+ * 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 __HVMLOADER_VNUMA_H__
+#define __HVMLOADER_VNUMA_H__
+
+#include <xen/memory.h>
+
+#define MAX_VNODES     64
+#define MAX_VDISTANCE  (MAX_VNODES * MAX_VNODES)
+#define MAX_VMEMRANGES (MAX_VNODES * 2)
+
+extern unsigned int nr_vnodes, nr_vmemranges;
+extern unsigned int *vcpu_to_vnode, *vdistance;
+extern xen_vmemrange_t *vmemrange;
+
+void init_vnuma_info(void);
+
+#endif /* __HVMLOADER_VNUMA_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 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 Mon Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKa-0002Pb-Mp; Mon, 01 Dec 2014 15:56: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 1XvTKZ-0002OS-Cy
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:56:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	54/75-15461-59F8C745; Mon, 01 Dec 2014 15:56:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417449361!12613050!1
X-Originating-IP: [66.165.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 25143 invoked from network); 1 Dec 2014 15:56:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 15:56:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198119921"
Received: from ukmail1.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, 1 Dec 2014 10:56:00 -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 1XvSyt-0005TR-Jq;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:37 +0000
Message-ID: <1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 13/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>
---
Changes in v2:
1. Remove explicit zero initializers.
2. Adapt to new vNUMA retrieval routine.
3. Move SRAT very late in secondary table build.
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |   53 +++++++++++++++++++++++
 tools/firmware/hvmloader/acpi/build.c   |   71 +++++++++++++++++++++++++++++++
 2 files changed, 124 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..917b2c9 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -23,6 +23,7 @@
 #include "ssdt_pm.h"
 #include "../config.h"
 #include "../util.h"
+#include "../vnuma.h"
 #include <xen/hvm/hvm_xs_strings.h>
 #include <xen/hvm/params.h>
 
@@ -203,6 +204,65 @@ 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) * 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   = vcpu_to_vnode[i];
+        processor->apic_id  = LAPIC_ID(i);
+        processor->flags    = ACPI_LOCAL_APIC_AFFIN_ENABLED;
+        processor++;
+    }
+
+    memory = (struct acpi_20_srat_memory *)processor;
+    for ( i = 0; i < nr_vmemranges; i++ )
+    {
+        mem = vmemrange[i].end - vmemrange[i].start;
+        memset(memory, 0, sizeof(*memory));
+        memory->type          = ACPI_MEMORY_AFFINITY;
+        memory->length        = sizeof(*memory);
+        memory->domain        = vmemrange[i].nid;
+        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
+        memory->base_address  = vmemrange[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;
@@ -346,6 +407,16 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         }
     }
 
+    /* SRAT */
+    if ( nr_vnodes > 0 )
+    {
+        srat = construct_srat();
+        if (srat)
+            table_ptrs[nr_tables++] = (unsigned long)srat;
+        else
+            printf("Failed to build SRAT, skipping...\n");
+    }
+
     /* Load any additional tables passed through. */
     nr_tables += construct_passthrough_tables(table_ptrs, nr_tables);
 
-- 
1.7.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 Dec 01 15:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKM-0002Ia-5L; Mon, 01 Dec 2014 15:55: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 1XvTKK-0002IA-8S
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:55:52 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	2D/E0-22777-78F8C745; Mon, 01 Dec 2014 15:55:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417449346!10887326!1
X-Originating-IP: [66.165.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 15081 invoked from network); 1 Dec 2014 15:55:50 -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;
	1 Dec 2014 15:55:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198445510"
Received: from ukmail1.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, 1 Dec 2014 10:55: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 1XvSyt-0005TR-Nf;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:40 +0000
Message-ID: <1417448023-27311-17-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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 1198225..11b20d2 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -845,6 +845,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 1678715..13c05c4 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 b8d9268..08a7639 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;
+    xen_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(xen_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 Mon Dec 01 15:56:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKf-0002Tr-40; Mon, 01 Dec 2014 15:56:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvTKe-0002TE-Hp
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:56:12 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	F4/A1-22777-B9F8C745; Mon, 01 Dec 2014 15:56:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417449366!10913023!1
X-Originating-IP: [66.165.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 4726 invoked from network); 1 Dec 2014 15:56:10 -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;
	1 Dec 2014 15:56:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198445696"
Received: from ukmail1.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, 1 Dec 2014 10:56:03 -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 1XvSyt-0005TR-RP;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:43 +0000
Message-ID: <1417448023-27311-20-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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>
---
Changes in v2:
1. Make vnuma_vdistances mandatory.
2. Use nested list to specify vdistances.
3. Update documentation.
---
 docs/man/xl.cfg.pod.5    |   39 ++++++++++++
 tools/libxl/xl_cmdimpl.c |  147 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 186 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 622ea53..e9af221 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -266,6 +266,45 @@ 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_vdistance=[ [NUMBER, ..., NUMBER], [NUMBER, ..., NUMBER], ... ]>
+
+Two dimensional list to specify distances among nodes.
+
+The number of elements in the first dimension list equals the number of virtual
+nodes. Each element in position B<i> is a list that specifies the distances
+from node B<i> to other nodes.
+
+For example, for a guest with 2 virtual nodes, user can specify:
+
+  vnuma_vdistance = [ [10, 20], [20, 10] ]
+
+=back
+
 =head3 Event Actions
 
 =over 4
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0e754e7..19996ed 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -904,6 +904,151 @@ 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, j;
+    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 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);
+    }
+
+    if (!xlu_cfg_get_list(config, "vnuma_vdistances", &vnuma_vdistances,
+                          &num_vnuma_vdistances, 1)) {
+        if (num_vnuma_vdistances != num_vnuma_memory) {
+            fprintf(stderr, "xl: Required %d sub-lists in vnuma_vdistances but provided %d\n",
+                    num_vnuma_memory, num_vnuma_vdistances);
+            exit(1);
+        }
+
+        for (i = 0; i < num_vnuma_vdistances; i++) {
+            const XLU_ConfigValue *tmp;
+            const XLU_ConfigList *sublist;
+
+            tmp = xlu_cfg_get_listitem2(vnuma_vdistances, i);
+            if (xlu_cfg_value_type(tmp) != XLU_LIST) {
+                fprintf(stderr, "xl: Expecting list in vnuma_vdistance\n");
+                exit(1);
+            }
+            sublist = xlu_cfg_value_get_list(tmp);
+            for (j = 0;
+                 (buf = xlu_cfg_get_listitem(sublist, j)) != NULL;
+                 j++) {
+                val = strtoul(buf, &ep, 10);
+                if (ep == buf) {
+                    fprintf(stderr, "xl: Invalid argument parsing vdistances map: %s\n", buf);
+                    exit(1);
+                }
+
+                b_info->vnuma_nodes[i].distances[j] = val;
+            }
+        }
+
+    } else {
+        fprintf(stderr, "xl: No vnuma_vdistances specified.\n");
+        exit(1);
+    }
+}
+
 static void parse_config_data(const char *config_source,
                               const char *config_data,
                               int config_len,
@@ -1093,6 +1238,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 Mon Dec 01 15:56:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKf-0002Tr-40; Mon, 01 Dec 2014 15:56:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvTKe-0002TE-Hp
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:56:12 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	F4/A1-22777-B9F8C745; Mon, 01 Dec 2014 15:56:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417449366!10913023!1
X-Originating-IP: [66.165.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 4726 invoked from network); 1 Dec 2014 15:56:10 -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;
	1 Dec 2014 15:56:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198445696"
Received: from ukmail1.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, 1 Dec 2014 10:56:03 -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 1XvSyt-0005TR-RP;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:43 +0000
Message-ID: <1417448023-27311-20-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 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>
---
Changes in v2:
1. Make vnuma_vdistances mandatory.
2. Use nested list to specify vdistances.
3. Update documentation.
---
 docs/man/xl.cfg.pod.5    |   39 ++++++++++++
 tools/libxl/xl_cmdimpl.c |  147 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 186 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 622ea53..e9af221 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -266,6 +266,45 @@ 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_vdistance=[ [NUMBER, ..., NUMBER], [NUMBER, ..., NUMBER], ... ]>
+
+Two dimensional list to specify distances among nodes.
+
+The number of elements in the first dimension list equals the number of virtual
+nodes. Each element in position B<i> is a list that specifies the distances
+from node B<i> to other nodes.
+
+For example, for a guest with 2 virtual nodes, user can specify:
+
+  vnuma_vdistance = [ [10, 20], [20, 10] ]
+
+=back
+
 =head3 Event Actions
 
 =over 4
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0e754e7..19996ed 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -904,6 +904,151 @@ 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, j;
+    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 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);
+    }
+
+    if (!xlu_cfg_get_list(config, "vnuma_vdistances", &vnuma_vdistances,
+                          &num_vnuma_vdistances, 1)) {
+        if (num_vnuma_vdistances != num_vnuma_memory) {
+            fprintf(stderr, "xl: Required %d sub-lists in vnuma_vdistances but provided %d\n",
+                    num_vnuma_memory, num_vnuma_vdistances);
+            exit(1);
+        }
+
+        for (i = 0; i < num_vnuma_vdistances; i++) {
+            const XLU_ConfigValue *tmp;
+            const XLU_ConfigList *sublist;
+
+            tmp = xlu_cfg_get_listitem2(vnuma_vdistances, i);
+            if (xlu_cfg_value_type(tmp) != XLU_LIST) {
+                fprintf(stderr, "xl: Expecting list in vnuma_vdistance\n");
+                exit(1);
+            }
+            sublist = xlu_cfg_value_get_list(tmp);
+            for (j = 0;
+                 (buf = xlu_cfg_get_listitem(sublist, j)) != NULL;
+                 j++) {
+                val = strtoul(buf, &ep, 10);
+                if (ep == buf) {
+                    fprintf(stderr, "xl: Invalid argument parsing vdistances map: %s\n", buf);
+                    exit(1);
+                }
+
+                b_info->vnuma_nodes[i].distances[j] = val;
+            }
+        }
+
+    } else {
+        fprintf(stderr, "xl: No vnuma_vdistances specified.\n");
+        exit(1);
+    }
+}
+
 static void parse_config_data(const char *config_source,
                               const char *config_data,
                               int config_len,
@@ -1093,6 +1238,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 Mon Dec 01 15:56:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvTKh-0002Wu-Po; Mon, 01 Dec 2014 15:56:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvTKg-0002Ul-37
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:56:14 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	10/E7-24124-D9F8C745; Mon, 01 Dec 2014 15:56:13 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417449366!10913023!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 4868 invoked from network); 1 Dec 2014 15:56:12 -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;
	1 Dec 2014 15:56:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198445729"
Received: from ukmail1.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, 1 Dec 2014 10:56:05 -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 1XvSyt-0005TR-QW;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:42 +0000
Message-ID: <1417448023-27311-19-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 18/19] libxlutil: nested list support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 with three major changes:
1. Rework internal representation of setting.
2. Extend grammar of parser.
3. Introduce new APIs.

New APIs introduced:
1. xlu_cfg_value_type
2. xlu_cfg_value_get_string
3. xlu_cfg_value_get_list
4. xlu_cfg_get_listitem2

Previous APIs work as before.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxlu_cfg.c      |  180 +++++++++++++++++++++++++----------------
 tools/libxl/libxlu_cfg_i.h    |   15 +++-
 tools/libxl/libxlu_cfg_y.c    |  110 +++++++++++--------------
 tools/libxl/libxlu_cfg_y.h    |    2 +-
 tools/libxl/libxlu_cfg_y.y    |   19 +++--
 tools/libxl/libxlu_internal.h |   24 ++++--
 tools/libxl/libxlutil.h       |   11 ++-
 7 files changed, 208 insertions(+), 153 deletions(-)

diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index 22adcb0..db26c34 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -132,13 +132,9 @@ int xlu_cfg_readdata(XLU_Config *cfg, const char *data, int length) {
 }
 
 void xlu__cfg_set_free(XLU_ConfigSetting *set) {
-    int i;
-
     if (!set) return;
+    xlu__cfg_value_free(set->value);
     free(set->name);
-    for (i=0; i<set->nvalues; i++)
-        free(set->values[i]);
-    free(set->values);
     free(set);
 }
 
@@ -173,7 +169,7 @@ static int find_atom(const XLU_Config *cfg, const char *n,
     set= find(cfg,n);
     if (!set) return ESRCH;
 
-    if (set->avalues!=1) {
+    if (set->value->type!=XLU_STRING) {
         if (!dont_warn)
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' is"
@@ -185,13 +181,30 @@ static int find_atom(const XLU_Config *cfg, const char *n,
     return 0;
 }
 
+enum XLU_ConfigValueType xlu_cfg_value_type(const XLU_ConfigValue *value)
+{
+    return value->type;
+}
+
+const char *xlu_cfg_value_get_string(const XLU_ConfigValue *value)
+{
+    assert(value->type == XLU_STRING);
+    return value->u.string;
+}
+
+const XLU_ConfigList *xlu_cfg_value_get_list(const XLU_ConfigValue *value)
+{
+    assert(value->type == XLU_LIST);
+    return &value->u.list;
+}
+
 int xlu_cfg_get_string(const XLU_Config *cfg, const char *n,
                        const char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
     e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
-    *value_r= set->values[0];
+    *value_r= set->value->u.string;
     return 0;
 }
 
@@ -202,7 +215,7 @@ int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
 
     e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     free(*value_r);
-    *value_r= strdup(set->values[0]);
+    *value_r= strdup(set->value->u.string);
     return 0;
 }
 
@@ -214,7 +227,7 @@ int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
     char *ep;
 
     e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
-    errno= 0; l= strtol(set->values[0], &ep, 0);
+    errno= 0; l= strtol(set->value->u.string, &ep, 0);
     e= errno;
     if (errno) {
         e= errno;
@@ -226,7 +239,7 @@ int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
                     cfg->config_source, set->lineno, n, strerror(e));
         return e;
     }
-    if (*ep || ep==set->values[0]) {
+    if (*ep || ep==set->value->u.string) {
         if (!dont_warn)
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' is not a valid number\n",
@@ -253,7 +266,7 @@ int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
     XLU_ConfigSetting *set;
     set= find(cfg,n);  if (!set) return ESRCH;
-    if (set->avalues==1) {
+    if (set->value->type!=XLU_LIST) {
         if (!dont_warn) {
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' is a single value"
@@ -262,8 +275,8 @@ int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
         }
         return EINVAL;
     }
-    if (list_r) *list_r= set;
-    if (entries_r) *entries_r= set->nvalues;
+    if (list_r) *list_r= &set->value->u.list;
+    if (entries_r) *entries_r= set->value->u.list.nvalues;
     return 0;
 }
 
@@ -290,72 +303,29 @@ int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
     return 0;
 }
 
-const char *xlu_cfg_get_listitem(const XLU_ConfigList *set, int entry) {
-    if (entry < 0 || entry >= set->nvalues) return 0;
-    return set->values[entry];
+const char *xlu_cfg_get_listitem(const XLU_ConfigList *list, int entry) {
+    if (entry < 0 || entry >= list->nvalues) return 0;
+    if (list->values[entry]->type != XLU_STRING) return 0;
+    return list->values[entry]->u.string;
 }
 
-
-XLU_ConfigSetting *xlu__cfg_set_mk(CfgParseContext *ctx,
-                                   int alloc, char *atom) {
-    XLU_ConfigSetting *set= 0;
-
-    if (ctx->err) goto x;
-    assert(!!alloc == !!atom);
-
-    set= malloc(sizeof(*set));
-    if (!set) goto xe;
-
-    set->name= 0; /* tbd */
-    set->avalues= alloc;
-
-    if (!alloc) {
-        set->nvalues= 0;
-        set->values= 0;
-    } else {
-        set->values= malloc(sizeof(*set->values) * alloc);
-        if (!set->values) goto xe;
-
-        set->nvalues= 1;
-        set->values[0]= atom;
-    }
-    return set;
-
- xe:
-    ctx->err= errno;
- x:
-    free(set);
-    free(atom);
-    return 0;
-}
-
-void xlu__cfg_set_add(CfgParseContext *ctx, XLU_ConfigSetting *set,
-                      char *atom) {
-    if (ctx->err) return;
-
-    assert(atom);
-
-    if (set->nvalues >= set->avalues) {
-        int new_avalues;
-        char **new_values;
-
-        if (set->avalues > INT_MAX / 100) { ctx->err= ERANGE; return; }
-        new_avalues= set->avalues * 4;
-        new_values= realloc(set->values,
-                            sizeof(*new_values) * new_avalues);
-        if (!new_values) { ctx->err= errno; free(atom); return; }
-        set->values= new_values;
-        set->avalues= new_avalues;
-    }
-    set->values[set->nvalues++]= atom;
+const XLU_ConfigValue *xlu_cfg_get_listitem2(const XLU_ConfigList *list,
+                                             int entry)
+{
+    if (entry < 0 || entry >= list->nvalues) return NULL;
+    return list->values[entry];
 }
 
 void xlu__cfg_set_store(CfgParseContext *ctx, char *name,
-                        XLU_ConfigSetting *set, int lineno) {
+                        XLU_ConfigValue *val, int lineno) {
+    XLU_ConfigSetting *set;
     if (ctx->err) return;
 
     assert(name);
+    set = malloc(sizeof(*set));
+    assert(set);
     set->name= name;
+    set->value = val;
     set->lineno= lineno;
     set->next= ctx->cfg->settings;
     ctx->cfg->settings= set;
@@ -473,6 +443,76 @@ void xlu__cfg_yyerror(YYLTYPE *loc, CfgParseContext *ctx, char const *msg) {
     if (!ctx->err) ctx->err= EINVAL;
 }
 
+XLU_ConfigValue *xlu__cfg_make_string(CfgParseContext *ctx,
+                                      char *src)
+{
+    XLU_ConfigValue *ret;
+
+    ret = malloc(sizeof(*ret));
+    assert(ret);
+    ret->type = XLU_STRING;
+    ret->u.string = src;
+
+    return ret;
+}
+
+XLU_ConfigValue *xlu__cfg_make_list(CfgParseContext *ctx,
+                                    XLU_ConfigValue *val)
+{
+    XLU_ConfigValue *ret;
+
+    ret = malloc(sizeof(*ret));
+    assert(ret);
+    ret->type = XLU_LIST;
+    ret->u.list.nvalues = 1;
+    ret->u.list.values = malloc(sizeof(*ret->u.list.values));
+    ret->u.list.values[0] = val;
+
+    return ret;
+}
+
+XLU_ConfigValue *xlu__cfg_list_append(CfgParseContext *ctx,
+                                      XLU_ConfigValue *list,
+                                      XLU_ConfigValue *val)
+{
+    XLU_ConfigValue **new_val;
+
+    assert(list->type == XLU_LIST);
+
+    new_val = realloc(list->u.list.values,
+                      sizeof(*new_val) * (list->u.list.nvalues+1));
+    if (!new_val) {
+        ctx->err = errno;
+        xlu__cfg_value_free(val);
+        return list;
+    }
+
+    list->u.list.values = new_val;
+    list->u.list.values[list->u.list.nvalues] = val;
+    list->u.list.nvalues++;
+
+    return list;
+}
+
+void xlu__cfg_value_free(XLU_ConfigValue *val)
+{
+    int i;
+
+    if (!val) return;
+
+    switch (val->type) {
+    case XLU_STRING:
+        free(val->u.string);
+        break;
+    case XLU_LIST:
+        for (i = 0; i < val->u.list.nvalues; i++) {
+            xlu__cfg_value_free(val->u.list.values[i]);
+        }
+        free(val->u.list.values);
+    }
+    free(val);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxlu_cfg_i.h b/tools/libxl/libxlu_cfg_i.h
index 54d033c..89cef9a 100644
--- a/tools/libxl/libxlu_cfg_i.h
+++ b/tools/libxl/libxlu_cfg_i.h
@@ -23,10 +23,8 @@
 #include "libxlu_cfg_y.h"
 
 void xlu__cfg_set_free(XLU_ConfigSetting *set);
-XLU_ConfigSetting *xlu__cfg_set_mk(CfgParseContext*, int alloc, char *atom);
-void xlu__cfg_set_add(CfgParseContext*, XLU_ConfigSetting *set, char *atom);
 void xlu__cfg_set_store(CfgParseContext*, char *name,
-                        XLU_ConfigSetting *set, int lineno);
+                        XLU_ConfigValue *val, int lineno);
 
 char *xlu__cfgl_strdup(CfgParseContext*, const char *src);
 char *xlu__cfgl_dequote(CfgParseContext*, const char *src);
@@ -36,7 +34,18 @@ void xlu__cfgl_lexicalerror(CfgParseContext*, char const *msg);
 
 void xlu__cfgl_likely_python(CfgParseContext *ctx);
 
+XLU_ConfigValue *xlu__cfg_make_string(CfgParseContext*, char *src);
 
+XLU_ConfigValue *xlu__cfg_make_list(CfgParseContext*,
+                                    XLU_ConfigValue *val);
+
+
+
+XLU_ConfigValue *xlu__cfg_list_append(CfgParseContext *ctx,
+                                      XLU_ConfigValue *list,
+                                      XLU_ConfigValue *val);
+
+void xlu__cfg_value_free(struct XLU_ConfigValue *val);
 
 /* Why oh why does bison not declare this in its autogenerated .h ? */
 int xlu__cfg_yyparse(CfgParseContext *ctx);
diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c
index 4437e05..0a035ef 100644
--- a/tools/libxl/libxlu_cfg_y.c
+++ b/tools/libxl/libxlu_cfg_y.c
@@ -126,7 +126,7 @@ typedef union YYSTYPE
 #line 25 "libxlu_cfg_y.y"
 
   char *string;
-  XLU_ConfigSetting *setting;
+  XLU_ConfigValue *value;
 
 
 
@@ -377,14 +377,14 @@ union yyalloc
 /* YYFINAL -- State number of the termination state.  */
 #define YYFINAL  3
 /* YYLAST -- Last index in YYTABLE.  */
-#define YYLAST   24
+#define YYLAST   26
 
 /* YYNTOKENS -- Number of terminals.  */
 #define YYNTOKENS  12
 /* YYNNTS -- Number of nonterminals.  */
 #define YYNNTS  11
 /* YYNRULES -- Number of rules.  */
-#define YYNRULES  22
+#define YYNRULES  21
 /* YYNRULES -- Number of states.  */
 #define YYNSTATES  30
 
@@ -433,8 +433,8 @@ static const yytype_uint8 yytranslate[] =
 static const yytype_uint8 yyprhs[] =
 {
        0,     0,     3,     5,     8,     9,    12,    15,    17,    20,
-      24,    26,    28,    30,    35,    37,    39,    40,    42,    46,
-      49,    55,    56
+      24,    26,    28,    30,    32,    34,    36,    41,    42,    45,
+      51,    52
 };
 
 /* YYRHS -- A `-1'-separated list of the rules' RHS.  */
@@ -443,17 +443,17 @@ static const yytype_int8 yyrhs[] =
       13,     0,    -1,    14,    -1,    14,    16,    -1,    -1,    14,
       15,    -1,    16,    17,    -1,    17,    -1,     1,     6,    -1,
        3,     7,    18,    -1,     6,    -1,     8,    -1,    19,    -1,
-       9,    22,    20,    10,    -1,     4,    -1,     5,    -1,    -1,
-      21,    -1,    21,    11,    22,    -1,    19,    22,    -1,    21,
-      11,    22,    19,    22,    -1,    -1,    22,     6,    -1
+      20,    -1,     4,    -1,     5,    -1,     9,    22,    21,    10,
+      -1,    -1,    18,    22,    -1,    21,    11,    22,    18,    22,
+      -1,    -1,    22,     6,    -1
 };
 
 /* YYRLINE[YYN] -- source line where rule number YYN was defined.  */
 static const yytype_uint8 yyrline[] =
 {
        0,    47,    47,    48,    50,    51,    53,    54,    55,    57,
-      59,    60,    62,    63,    65,    66,    68,    69,    70,    72,
-      73,    75,    77
+      59,    60,    62,    63,    65,    66,    68,    70,    71,    72,
+      74,    76
 };
 #endif
 
@@ -464,7 +464,7 @@ static const char *const yytname[] =
 {
   "$end", "error", "$undefined", "IDENT", "STRING", "NUMBER", "NEWLINE",
   "'='", "';'", "'['", "']'", "','", "$accept", "file", "stmts", "stmt",
-  "assignment", "endstmt", "value", "atom", "valuelist", "values", "nlok", 0
+  "assignment", "endstmt", "value", "atom", "list", "values", "nlok", 0
 };
 #endif
 
@@ -482,16 +482,16 @@ static const yytype_uint16 yytoknum[] =
 static const yytype_uint8 yyr1[] =
 {
        0,    12,    13,    13,    14,    14,    15,    15,    15,    16,
-      17,    17,    18,    18,    19,    19,    20,    20,    20,    21,
-      21,    22,    22
+      17,    17,    18,    18,    19,    19,    20,    21,    21,    21,
+      22,    22
 };
 
 /* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN.  */
 static const yytype_uint8 yyr2[] =
 {
        0,     2,     1,     2,     0,     2,     2,     1,     2,     3,
-       1,     1,     1,     4,     1,     1,     0,     1,     3,     2,
-       5,     0,     2
+       1,     1,     1,     1,     1,     1,     4,     0,     2,     5,
+       0,     2
 };
 
 /* YYDEFACT[STATE-NAME] -- Default reduction number in state STATE-NUM.
@@ -500,32 +500,32 @@ static const yytype_uint8 yyr2[] =
 static const yytype_uint8 yydefact[] =
 {
        4,     0,     0,     1,     0,     0,    10,    11,     5,     3,
-       7,     8,     0,     6,    14,    15,    21,     9,    12,    16,
-      22,    21,     0,    17,    19,    13,    21,    18,    21,    20
+       7,     8,     0,     6,    14,    15,    20,     9,    12,    13,
+      17,    21,    20,     0,    18,    16,    20,     0,    20,    19
 };
 
 /* YYDEFGOTO[NTERM-NUM].  */
 static const yytype_int8 yydefgoto[] =
 {
-      -1,     1,     2,     8,     9,    10,    17,    18,    22,    23,
-      19
+      -1,     1,     2,     8,     9,    10,    17,    18,    19,    23,
+      20
 };
 
 /* YYPACT[STATE-NUM] -- Index in YYTABLE of the portion describing
    STATE-NUM.  */
-#define YYPACT_NINF -18
+#define YYPACT_NINF -19
 static const yytype_int8 yypact[] =
 {
-     -18,     4,     0,   -18,    -1,     6,   -18,   -18,   -18,     3,
-     -18,   -18,    11,   -18,   -18,   -18,   -18,   -18,   -18,    13,
-     -18,   -18,    12,    10,    17,   -18,   -18,    13,   -18,    17
+     -19,    20,     0,   -19,    15,    16,   -19,   -19,   -19,     4,
+     -19,   -19,    13,   -19,   -19,   -19,   -19,   -19,   -19,   -19,
+      10,   -19,   -19,    -6,    18,   -19,   -19,    10,   -19,    18
 };
 
 /* YYPGOTO[NTERM-NUM].  */
 static const yytype_int8 yypgoto[] =
 {
-     -18,   -18,   -18,   -18,   -18,    15,   -18,   -17,   -18,   -18,
-     -14
+     -19,   -19,   -19,   -19,   -19,    17,   -18,   -19,   -19,   -19,
+     -15
 };
 
 /* YYTABLE[YYPACT[STATE-NUM]].  What to do in state STATE-NUM.  If
@@ -534,22 +534,22 @@ static const yytype_int8 yypgoto[] =
 #define YYTABLE_NINF -3
 static const yytype_int8 yytable[] =
 {
-      -2,     4,    21,     5,     3,    11,     6,    24,     7,     6,
-      28,     7,    27,    12,    29,    14,    15,    14,    15,    20,
-      16,    26,    25,    20,    13
+      -2,     4,    22,     5,    25,    26,     6,    24,     7,    28,
+       6,    27,     7,    29,    14,    15,    21,    14,    15,    16,
+       3,    11,    16,    12,    21,     0,    13
 };
 
 #define yypact_value_is_default(yystate) \
-  ((yystate) == (-18))
+  ((yystate) == (-19))
 
 #define yytable_value_is_error(yytable_value) \
   YYID (0)
 
-static const yytype_uint8 yycheck[] =
+static const yytype_int8 yycheck[] =
 {
-       0,     1,    19,     3,     0,     6,     6,    21,     8,     6,
-      27,     8,    26,     7,    28,     4,     5,     4,     5,     6,
-       9,    11,    10,     6,     9
+       0,     1,    20,     3,    10,    11,     6,    22,     8,    27,
+       6,    26,     8,    28,     4,     5,     6,     4,     5,     9,
+       0,     6,     9,     7,     6,    -1,     9
 };
 
 /* YYSTOS[STATE-NUM] -- The (internal number of the) accessing
@@ -557,8 +557,8 @@ static const yytype_uint8 yycheck[] =
 static const yytype_uint8 yystos[] =
 {
        0,    13,    14,     0,     1,     3,     6,     8,    15,    16,
-      17,     6,     7,    17,     4,     5,     9,    18,    19,    22,
-       6,    19,    20,    21,    22,    10,    11,    22,    19,    22
+      17,     6,     7,    17,     4,     5,     9,    18,    19,    20,
+      22,     6,    18,    21,    22,    10,    11,    22,    18,    22
 };
 
 #define yyerrok		(yyerrstatus = 0)
@@ -1148,7 +1148,7 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
 
 /* Line 1391 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
-	{ xlu__cfg_set_free((yyvaluep->setting)); };
+	{ xlu__cfg_value_free((yyvaluep->value)); };
 
 /* Line 1391 of yacc.c  */
 #line 1155 "libxlu_cfg_y.c"
@@ -1162,11 +1162,11 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
 /* Line 1391 of yacc.c  */
 #line 1164 "libxlu_cfg_y.c"
 	break;
-      case 20: /* "valuelist" */
+      case 20: /* "list" */
 
 /* Line 1391 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
-	{ xlu__cfg_set_free((yyvaluep->setting)); };
+	{ xlu__cfg_value_free((yyvaluep->value)); };
 
 /* Line 1391 of yacc.c  */
 #line 1173 "libxlu_cfg_y.c"
@@ -1175,7 +1175,7 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
 
 /* Line 1391 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
-	{ xlu__cfg_set_free((yyvaluep->setting)); };
+	{ xlu__cfg_value_free((yyvaluep->value)); };
 
 /* Line 1391 of yacc.c  */
 #line 1182 "libxlu_cfg_y.c"
@@ -1508,21 +1508,14 @@ yyreduce:
 
 /* Line 1806 of yacc.c  */
 #line 57 "libxlu_cfg_y.y"
-    { xlu__cfg_set_store(ctx,(yyvsp[(1) - (3)].string),(yyvsp[(3) - (3)].setting),(yylsp[(3) - (3)]).first_line); }
+    { xlu__cfg_set_store(ctx,(yyvsp[(1) - (3)].string),(yyvsp[(3) - (3)].value),(yylsp[(3) - (3)]).first_line); }
     break;
 
   case 12:
 
 /* Line 1806 of yacc.c  */
 #line 62 "libxlu_cfg_y.y"
-    { (yyval.setting)= xlu__cfg_set_mk(ctx,1,(yyvsp[(1) - (1)].string)); }
-    break;
-
-  case 13:
-
-/* Line 1806 of yacc.c  */
-#line 63 "libxlu_cfg_y.y"
-    { (yyval.setting)= (yyvsp[(3) - (4)].setting); }
+    { (yyval.value)= xlu__cfg_make_string(ctx,(yyvsp[(1) - (1)].string)); }
     break;
 
   case 14:
@@ -1543,41 +1536,34 @@ yyreduce:
 
 /* Line 1806 of yacc.c  */
 #line 68 "libxlu_cfg_y.y"
-    { (yyval.setting)= xlu__cfg_set_mk(ctx,0,0); }
+    { (yyval.value)= (yyvsp[(3) - (4)].value); }
     break;
 
   case 17:
 
 /* Line 1806 of yacc.c  */
-#line 69 "libxlu_cfg_y.y"
-    { (yyval.setting)= (yyvsp[(1) - (1)].setting); }
+#line 70 "libxlu_cfg_y.y"
+    { (yyval.value)= xlu__cfg_make_list(ctx,NULL); }
     break;
 
   case 18:
 
 /* Line 1806 of yacc.c  */
-#line 70 "libxlu_cfg_y.y"
-    { (yyval.setting)= (yyvsp[(1) - (3)].setting); }
+#line 71 "libxlu_cfg_y.y"
+    { (yyval.value)= xlu__cfg_make_list(ctx,(yyvsp[(1) - (2)].value)); }
     break;
 
   case 19:
 
 /* Line 1806 of yacc.c  */
 #line 72 "libxlu_cfg_y.y"
-    { (yyval.setting)= xlu__cfg_set_mk(ctx,2,(yyvsp[(1) - (2)].string)); }
-    break;
-
-  case 20:
-
-/* Line 1806 of yacc.c  */
-#line 73 "libxlu_cfg_y.y"
-    { xlu__cfg_set_add(ctx,(yyvsp[(1) - (5)].setting),(yyvsp[(4) - (5)].string)); (yyval.setting)= (yyvsp[(1) - (5)].setting); }
+    { xlu__cfg_list_append(ctx,(yyvsp[(1) - (5)].value),(yyvsp[(4) - (5)].value)); (yyval.value)= (yyvsp[(1) - (5)].value);}
     break;
 
 
 
 /* Line 1806 of yacc.c  */
-#line 1581 "libxlu_cfg_y.c"
+#line 1567 "libxlu_cfg_y.c"
       default: break;
     }
   /* User semantic actions sometimes alter yychar, and that requires
diff --git a/tools/libxl/libxlu_cfg_y.h b/tools/libxl/libxlu_cfg_y.h
index d7dfaf2..37e8213 100644
--- a/tools/libxl/libxlu_cfg_y.h
+++ b/tools/libxl/libxlu_cfg_y.h
@@ -54,7 +54,7 @@ typedef union YYSTYPE
 #line 25 "libxlu_cfg_y.y"
 
   char *string;
-  XLU_ConfigSetting *setting;
+  XLU_ConfigValue *value;
 
 
 
diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
index aa9f787..bd4156e 100644
--- a/tools/libxl/libxlu_cfg_y.y
+++ b/tools/libxl/libxlu_cfg_y.y
@@ -24,7 +24,7 @@
 
 %union {
   char *string;
-  XLU_ConfigSetting *setting;
+  XLU_ConfigValue *value;
 }
 
 %locations
@@ -39,8 +39,8 @@
 %type <string>            atom
 %destructor { free($$); } atom IDENT STRING NUMBER
 
-%type <setting>                         value valuelist values
-%destructor { xlu__cfg_set_free($$); }  value valuelist values
+%type <value>                         value list values
+%destructor { xlu__cfg_value_free($$); }  value list values
 
 %%
 
@@ -59,18 +59,17 @@ assignment: IDENT '=' value { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
 endstmt: NEWLINE
  |      ';'
 
-value:  atom                         { $$= xlu__cfg_set_mk(ctx,1,$1); }
- |      '[' nlok valuelist ']'       { $$= $3; }
+value:  atom                         { $$= xlu__cfg_make_string(ctx,$1); }
+ |      list
 
 atom:   STRING                   { $$= $1; }
  |      NUMBER                   { $$= $1; }
 
-valuelist: /* empty */           { $$= xlu__cfg_set_mk(ctx,0,0); }
- |      values                  { $$= $1; }
- |      values ',' nlok         { $$= $1; }
+list:   '[' nlok values ']'      { $$= $3; }
 
-values: atom nlok                  { $$= xlu__cfg_set_mk(ctx,2,$1); }
- |      values ',' nlok atom nlok  { xlu__cfg_set_add(ctx,$1,$4); $$= $1; }
+values: /* empty */                { $$= xlu__cfg_make_list(ctx,NULL); }
+ |      value nlok                 { $$= xlu__cfg_make_list(ctx,$1); }
+ |      values ',' nlok value nlok { xlu__cfg_list_append(ctx,$1,$4); $$= $1;}
 
 nlok:
         /* nothing */
diff --git a/tools/libxl/libxlu_internal.h b/tools/libxl/libxlu_internal.h
index 7579158..66eec28 100644
--- a/tools/libxl/libxlu_internal.h
+++ b/tools/libxl/libxlu_internal.h
@@ -23,17 +23,29 @@
 #include <assert.h>
 #include <regex.h>
 
-#define XLU_ConfigList XLU_ConfigSetting
-
 #include "libxlutil.h"
 
-struct XLU_ConfigSetting { /* transparent */
+typedef struct XLU_ConfigValue XLU_ConfigValue;
+
+typedef struct XLU_ConfigList {
+    int nvalues;
+    XLU_ConfigValue **values;
+} XLU_ConfigList;
+
+typedef struct XLU_ConfigValue {
+    enum XLU_ConfigValueType type;
+    union {
+        char *string;
+        XLU_ConfigList list;
+    } u;
+} XLU_ConfigValue;
+
+typedef struct XLU_ConfigSetting { /* transparent */
     struct XLU_ConfigSetting *next;
     char *name;
-    int nvalues, avalues; /* lists have avalues>1 */
-    char **values;
+    struct XLU_ConfigValue *value;
     int lineno;
-};
+} XLU_ConfigSetting;
 
 struct XLU_Config {
     XLU_ConfigSetting *settings;
diff --git a/tools/libxl/libxlutil.h b/tools/libxl/libxlutil.h
index 0333e55..37d9549 100644
--- a/tools/libxl/libxlutil.h
+++ b/tools/libxl/libxlutil.h
@@ -23,6 +23,15 @@
 /* Unless otherwise stated, all functions return an errno value. */
 typedef struct XLU_Config XLU_Config;
 typedef struct XLU_ConfigList XLU_ConfigList;
+typedef struct XLU_ConfigValue XLU_ConfigValue;
+enum XLU_ConfigValueType {
+    XLU_STRING,
+    XLU_LIST,
+};
+
+enum XLU_ConfigValueType xlu_cfg_value_type(const XLU_ConfigValue *value);
+const char *xlu_cfg_value_get_string(const XLU_ConfigValue *value);
+const XLU_ConfigList *xlu_cfg_value_get_list(const XLU_ConfigValue *value);
 
 XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename);
   /* 0 means we got ENOMEM. */
@@ -65,7 +74,7 @@ int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
 const char *xlu_cfg_get_listitem(const XLU_ConfigList*, int entry);
   /* xlu_cfg_get_listitem cannot fail, except that if entry is
    * out of range it returns 0 (not setting errno) */
-
+const XLU_ConfigValue *xlu_cfg_get_listitem2(const XLU_ConfigList*, int entry);
 
 /*
  * Disk specification parsing.
-- 
1.7.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 Dec 01 15:56:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15: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 1XvTKh-0002Wu-Po; Mon, 01 Dec 2014 15:56:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvTKg-0002Ul-37
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:56:14 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	10/E7-24124-D9F8C745; Mon, 01 Dec 2014 15:56:13 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417449366!10913023!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 4868 invoked from network); 1 Dec 2014 15:56:12 -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;
	1 Dec 2014 15:56:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198445729"
Received: from ukmail1.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, 1 Dec 2014 10:56:05 -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 1XvSyt-0005TR-QW;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:42 +0000
Message-ID: <1417448023-27311-19-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 18/19] libxlutil: nested list support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 with three major changes:
1. Rework internal representation of setting.
2. Extend grammar of parser.
3. Introduce new APIs.

New APIs introduced:
1. xlu_cfg_value_type
2. xlu_cfg_value_get_string
3. xlu_cfg_value_get_list
4. xlu_cfg_get_listitem2

Previous APIs work as before.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxlu_cfg.c      |  180 +++++++++++++++++++++++++----------------
 tools/libxl/libxlu_cfg_i.h    |   15 +++-
 tools/libxl/libxlu_cfg_y.c    |  110 +++++++++++--------------
 tools/libxl/libxlu_cfg_y.h    |    2 +-
 tools/libxl/libxlu_cfg_y.y    |   19 +++--
 tools/libxl/libxlu_internal.h |   24 ++++--
 tools/libxl/libxlutil.h       |   11 ++-
 7 files changed, 208 insertions(+), 153 deletions(-)

diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index 22adcb0..db26c34 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -132,13 +132,9 @@ int xlu_cfg_readdata(XLU_Config *cfg, const char *data, int length) {
 }
 
 void xlu__cfg_set_free(XLU_ConfigSetting *set) {
-    int i;
-
     if (!set) return;
+    xlu__cfg_value_free(set->value);
     free(set->name);
-    for (i=0; i<set->nvalues; i++)
-        free(set->values[i]);
-    free(set->values);
     free(set);
 }
 
@@ -173,7 +169,7 @@ static int find_atom(const XLU_Config *cfg, const char *n,
     set= find(cfg,n);
     if (!set) return ESRCH;
 
-    if (set->avalues!=1) {
+    if (set->value->type!=XLU_STRING) {
         if (!dont_warn)
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' is"
@@ -185,13 +181,30 @@ static int find_atom(const XLU_Config *cfg, const char *n,
     return 0;
 }
 
+enum XLU_ConfigValueType xlu_cfg_value_type(const XLU_ConfigValue *value)
+{
+    return value->type;
+}
+
+const char *xlu_cfg_value_get_string(const XLU_ConfigValue *value)
+{
+    assert(value->type == XLU_STRING);
+    return value->u.string;
+}
+
+const XLU_ConfigList *xlu_cfg_value_get_list(const XLU_ConfigValue *value)
+{
+    assert(value->type == XLU_LIST);
+    return &value->u.list;
+}
+
 int xlu_cfg_get_string(const XLU_Config *cfg, const char *n,
                        const char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
     e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
-    *value_r= set->values[0];
+    *value_r= set->value->u.string;
     return 0;
 }
 
@@ -202,7 +215,7 @@ int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
 
     e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     free(*value_r);
-    *value_r= strdup(set->values[0]);
+    *value_r= strdup(set->value->u.string);
     return 0;
 }
 
@@ -214,7 +227,7 @@ int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
     char *ep;
 
     e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
-    errno= 0; l= strtol(set->values[0], &ep, 0);
+    errno= 0; l= strtol(set->value->u.string, &ep, 0);
     e= errno;
     if (errno) {
         e= errno;
@@ -226,7 +239,7 @@ int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
                     cfg->config_source, set->lineno, n, strerror(e));
         return e;
     }
-    if (*ep || ep==set->values[0]) {
+    if (*ep || ep==set->value->u.string) {
         if (!dont_warn)
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' is not a valid number\n",
@@ -253,7 +266,7 @@ int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
     XLU_ConfigSetting *set;
     set= find(cfg,n);  if (!set) return ESRCH;
-    if (set->avalues==1) {
+    if (set->value->type!=XLU_LIST) {
         if (!dont_warn) {
             fprintf(cfg->report,
                     "%s:%d: warning: parameter `%s' is a single value"
@@ -262,8 +275,8 @@ int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
         }
         return EINVAL;
     }
-    if (list_r) *list_r= set;
-    if (entries_r) *entries_r= set->nvalues;
+    if (list_r) *list_r= &set->value->u.list;
+    if (entries_r) *entries_r= set->value->u.list.nvalues;
     return 0;
 }
 
@@ -290,72 +303,29 @@ int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
     return 0;
 }
 
-const char *xlu_cfg_get_listitem(const XLU_ConfigList *set, int entry) {
-    if (entry < 0 || entry >= set->nvalues) return 0;
-    return set->values[entry];
+const char *xlu_cfg_get_listitem(const XLU_ConfigList *list, int entry) {
+    if (entry < 0 || entry >= list->nvalues) return 0;
+    if (list->values[entry]->type != XLU_STRING) return 0;
+    return list->values[entry]->u.string;
 }
 
-
-XLU_ConfigSetting *xlu__cfg_set_mk(CfgParseContext *ctx,
-                                   int alloc, char *atom) {
-    XLU_ConfigSetting *set= 0;
-
-    if (ctx->err) goto x;
-    assert(!!alloc == !!atom);
-
-    set= malloc(sizeof(*set));
-    if (!set) goto xe;
-
-    set->name= 0; /* tbd */
-    set->avalues= alloc;
-
-    if (!alloc) {
-        set->nvalues= 0;
-        set->values= 0;
-    } else {
-        set->values= malloc(sizeof(*set->values) * alloc);
-        if (!set->values) goto xe;
-
-        set->nvalues= 1;
-        set->values[0]= atom;
-    }
-    return set;
-
- xe:
-    ctx->err= errno;
- x:
-    free(set);
-    free(atom);
-    return 0;
-}
-
-void xlu__cfg_set_add(CfgParseContext *ctx, XLU_ConfigSetting *set,
-                      char *atom) {
-    if (ctx->err) return;
-
-    assert(atom);
-
-    if (set->nvalues >= set->avalues) {
-        int new_avalues;
-        char **new_values;
-
-        if (set->avalues > INT_MAX / 100) { ctx->err= ERANGE; return; }
-        new_avalues= set->avalues * 4;
-        new_values= realloc(set->values,
-                            sizeof(*new_values) * new_avalues);
-        if (!new_values) { ctx->err= errno; free(atom); return; }
-        set->values= new_values;
-        set->avalues= new_avalues;
-    }
-    set->values[set->nvalues++]= atom;
+const XLU_ConfigValue *xlu_cfg_get_listitem2(const XLU_ConfigList *list,
+                                             int entry)
+{
+    if (entry < 0 || entry >= list->nvalues) return NULL;
+    return list->values[entry];
 }
 
 void xlu__cfg_set_store(CfgParseContext *ctx, char *name,
-                        XLU_ConfigSetting *set, int lineno) {
+                        XLU_ConfigValue *val, int lineno) {
+    XLU_ConfigSetting *set;
     if (ctx->err) return;
 
     assert(name);
+    set = malloc(sizeof(*set));
+    assert(set);
     set->name= name;
+    set->value = val;
     set->lineno= lineno;
     set->next= ctx->cfg->settings;
     ctx->cfg->settings= set;
@@ -473,6 +443,76 @@ void xlu__cfg_yyerror(YYLTYPE *loc, CfgParseContext *ctx, char const *msg) {
     if (!ctx->err) ctx->err= EINVAL;
 }
 
+XLU_ConfigValue *xlu__cfg_make_string(CfgParseContext *ctx,
+                                      char *src)
+{
+    XLU_ConfigValue *ret;
+
+    ret = malloc(sizeof(*ret));
+    assert(ret);
+    ret->type = XLU_STRING;
+    ret->u.string = src;
+
+    return ret;
+}
+
+XLU_ConfigValue *xlu__cfg_make_list(CfgParseContext *ctx,
+                                    XLU_ConfigValue *val)
+{
+    XLU_ConfigValue *ret;
+
+    ret = malloc(sizeof(*ret));
+    assert(ret);
+    ret->type = XLU_LIST;
+    ret->u.list.nvalues = 1;
+    ret->u.list.values = malloc(sizeof(*ret->u.list.values));
+    ret->u.list.values[0] = val;
+
+    return ret;
+}
+
+XLU_ConfigValue *xlu__cfg_list_append(CfgParseContext *ctx,
+                                      XLU_ConfigValue *list,
+                                      XLU_ConfigValue *val)
+{
+    XLU_ConfigValue **new_val;
+
+    assert(list->type == XLU_LIST);
+
+    new_val = realloc(list->u.list.values,
+                      sizeof(*new_val) * (list->u.list.nvalues+1));
+    if (!new_val) {
+        ctx->err = errno;
+        xlu__cfg_value_free(val);
+        return list;
+    }
+
+    list->u.list.values = new_val;
+    list->u.list.values[list->u.list.nvalues] = val;
+    list->u.list.nvalues++;
+
+    return list;
+}
+
+void xlu__cfg_value_free(XLU_ConfigValue *val)
+{
+    int i;
+
+    if (!val) return;
+
+    switch (val->type) {
+    case XLU_STRING:
+        free(val->u.string);
+        break;
+    case XLU_LIST:
+        for (i = 0; i < val->u.list.nvalues; i++) {
+            xlu__cfg_value_free(val->u.list.values[i]);
+        }
+        free(val->u.list.values);
+    }
+    free(val);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxlu_cfg_i.h b/tools/libxl/libxlu_cfg_i.h
index 54d033c..89cef9a 100644
--- a/tools/libxl/libxlu_cfg_i.h
+++ b/tools/libxl/libxlu_cfg_i.h
@@ -23,10 +23,8 @@
 #include "libxlu_cfg_y.h"
 
 void xlu__cfg_set_free(XLU_ConfigSetting *set);
-XLU_ConfigSetting *xlu__cfg_set_mk(CfgParseContext*, int alloc, char *atom);
-void xlu__cfg_set_add(CfgParseContext*, XLU_ConfigSetting *set, char *atom);
 void xlu__cfg_set_store(CfgParseContext*, char *name,
-                        XLU_ConfigSetting *set, int lineno);
+                        XLU_ConfigValue *val, int lineno);
 
 char *xlu__cfgl_strdup(CfgParseContext*, const char *src);
 char *xlu__cfgl_dequote(CfgParseContext*, const char *src);
@@ -36,7 +34,18 @@ void xlu__cfgl_lexicalerror(CfgParseContext*, char const *msg);
 
 void xlu__cfgl_likely_python(CfgParseContext *ctx);
 
+XLU_ConfigValue *xlu__cfg_make_string(CfgParseContext*, char *src);
 
+XLU_ConfigValue *xlu__cfg_make_list(CfgParseContext*,
+                                    XLU_ConfigValue *val);
+
+
+
+XLU_ConfigValue *xlu__cfg_list_append(CfgParseContext *ctx,
+                                      XLU_ConfigValue *list,
+                                      XLU_ConfigValue *val);
+
+void xlu__cfg_value_free(struct XLU_ConfigValue *val);
 
 /* Why oh why does bison not declare this in its autogenerated .h ? */
 int xlu__cfg_yyparse(CfgParseContext *ctx);
diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c
index 4437e05..0a035ef 100644
--- a/tools/libxl/libxlu_cfg_y.c
+++ b/tools/libxl/libxlu_cfg_y.c
@@ -126,7 +126,7 @@ typedef union YYSTYPE
 #line 25 "libxlu_cfg_y.y"
 
   char *string;
-  XLU_ConfigSetting *setting;
+  XLU_ConfigValue *value;
 
 
 
@@ -377,14 +377,14 @@ union yyalloc
 /* YYFINAL -- State number of the termination state.  */
 #define YYFINAL  3
 /* YYLAST -- Last index in YYTABLE.  */
-#define YYLAST   24
+#define YYLAST   26
 
 /* YYNTOKENS -- Number of terminals.  */
 #define YYNTOKENS  12
 /* YYNNTS -- Number of nonterminals.  */
 #define YYNNTS  11
 /* YYNRULES -- Number of rules.  */
-#define YYNRULES  22
+#define YYNRULES  21
 /* YYNRULES -- Number of states.  */
 #define YYNSTATES  30
 
@@ -433,8 +433,8 @@ static const yytype_uint8 yytranslate[] =
 static const yytype_uint8 yyprhs[] =
 {
        0,     0,     3,     5,     8,     9,    12,    15,    17,    20,
-      24,    26,    28,    30,    35,    37,    39,    40,    42,    46,
-      49,    55,    56
+      24,    26,    28,    30,    32,    34,    36,    41,    42,    45,
+      51,    52
 };
 
 /* YYRHS -- A `-1'-separated list of the rules' RHS.  */
@@ -443,17 +443,17 @@ static const yytype_int8 yyrhs[] =
       13,     0,    -1,    14,    -1,    14,    16,    -1,    -1,    14,
       15,    -1,    16,    17,    -1,    17,    -1,     1,     6,    -1,
        3,     7,    18,    -1,     6,    -1,     8,    -1,    19,    -1,
-       9,    22,    20,    10,    -1,     4,    -1,     5,    -1,    -1,
-      21,    -1,    21,    11,    22,    -1,    19,    22,    -1,    21,
-      11,    22,    19,    22,    -1,    -1,    22,     6,    -1
+      20,    -1,     4,    -1,     5,    -1,     9,    22,    21,    10,
+      -1,    -1,    18,    22,    -1,    21,    11,    22,    18,    22,
+      -1,    -1,    22,     6,    -1
 };
 
 /* YYRLINE[YYN] -- source line where rule number YYN was defined.  */
 static const yytype_uint8 yyrline[] =
 {
        0,    47,    47,    48,    50,    51,    53,    54,    55,    57,
-      59,    60,    62,    63,    65,    66,    68,    69,    70,    72,
-      73,    75,    77
+      59,    60,    62,    63,    65,    66,    68,    70,    71,    72,
+      74,    76
 };
 #endif
 
@@ -464,7 +464,7 @@ static const char *const yytname[] =
 {
   "$end", "error", "$undefined", "IDENT", "STRING", "NUMBER", "NEWLINE",
   "'='", "';'", "'['", "']'", "','", "$accept", "file", "stmts", "stmt",
-  "assignment", "endstmt", "value", "atom", "valuelist", "values", "nlok", 0
+  "assignment", "endstmt", "value", "atom", "list", "values", "nlok", 0
 };
 #endif
 
@@ -482,16 +482,16 @@ static const yytype_uint16 yytoknum[] =
 static const yytype_uint8 yyr1[] =
 {
        0,    12,    13,    13,    14,    14,    15,    15,    15,    16,
-      17,    17,    18,    18,    19,    19,    20,    20,    20,    21,
-      21,    22,    22
+      17,    17,    18,    18,    19,    19,    20,    21,    21,    21,
+      22,    22
 };
 
 /* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN.  */
 static const yytype_uint8 yyr2[] =
 {
        0,     2,     1,     2,     0,     2,     2,     1,     2,     3,
-       1,     1,     1,     4,     1,     1,     0,     1,     3,     2,
-       5,     0,     2
+       1,     1,     1,     1,     1,     1,     4,     0,     2,     5,
+       0,     2
 };
 
 /* YYDEFACT[STATE-NAME] -- Default reduction number in state STATE-NUM.
@@ -500,32 +500,32 @@ static const yytype_uint8 yyr2[] =
 static const yytype_uint8 yydefact[] =
 {
        4,     0,     0,     1,     0,     0,    10,    11,     5,     3,
-       7,     8,     0,     6,    14,    15,    21,     9,    12,    16,
-      22,    21,     0,    17,    19,    13,    21,    18,    21,    20
+       7,     8,     0,     6,    14,    15,    20,     9,    12,    13,
+      17,    21,    20,     0,    18,    16,    20,     0,    20,    19
 };
 
 /* YYDEFGOTO[NTERM-NUM].  */
 static const yytype_int8 yydefgoto[] =
 {
-      -1,     1,     2,     8,     9,    10,    17,    18,    22,    23,
-      19
+      -1,     1,     2,     8,     9,    10,    17,    18,    19,    23,
+      20
 };
 
 /* YYPACT[STATE-NUM] -- Index in YYTABLE of the portion describing
    STATE-NUM.  */
-#define YYPACT_NINF -18
+#define YYPACT_NINF -19
 static const yytype_int8 yypact[] =
 {
-     -18,     4,     0,   -18,    -1,     6,   -18,   -18,   -18,     3,
-     -18,   -18,    11,   -18,   -18,   -18,   -18,   -18,   -18,    13,
-     -18,   -18,    12,    10,    17,   -18,   -18,    13,   -18,    17
+     -19,    20,     0,   -19,    15,    16,   -19,   -19,   -19,     4,
+     -19,   -19,    13,   -19,   -19,   -19,   -19,   -19,   -19,   -19,
+      10,   -19,   -19,    -6,    18,   -19,   -19,    10,   -19,    18
 };
 
 /* YYPGOTO[NTERM-NUM].  */
 static const yytype_int8 yypgoto[] =
 {
-     -18,   -18,   -18,   -18,   -18,    15,   -18,   -17,   -18,   -18,
-     -14
+     -19,   -19,   -19,   -19,   -19,    17,   -18,   -19,   -19,   -19,
+     -15
 };
 
 /* YYTABLE[YYPACT[STATE-NUM]].  What to do in state STATE-NUM.  If
@@ -534,22 +534,22 @@ static const yytype_int8 yypgoto[] =
 #define YYTABLE_NINF -3
 static const yytype_int8 yytable[] =
 {
-      -2,     4,    21,     5,     3,    11,     6,    24,     7,     6,
-      28,     7,    27,    12,    29,    14,    15,    14,    15,    20,
-      16,    26,    25,    20,    13
+      -2,     4,    22,     5,    25,    26,     6,    24,     7,    28,
+       6,    27,     7,    29,    14,    15,    21,    14,    15,    16,
+       3,    11,    16,    12,    21,     0,    13
 };
 
 #define yypact_value_is_default(yystate) \
-  ((yystate) == (-18))
+  ((yystate) == (-19))
 
 #define yytable_value_is_error(yytable_value) \
   YYID (0)
 
-static const yytype_uint8 yycheck[] =
+static const yytype_int8 yycheck[] =
 {
-       0,     1,    19,     3,     0,     6,     6,    21,     8,     6,
-      27,     8,    26,     7,    28,     4,     5,     4,     5,     6,
-       9,    11,    10,     6,     9
+       0,     1,    20,     3,    10,    11,     6,    22,     8,    27,
+       6,    26,     8,    28,     4,     5,     6,     4,     5,     9,
+       0,     6,     9,     7,     6,    -1,     9
 };
 
 /* YYSTOS[STATE-NUM] -- The (internal number of the) accessing
@@ -557,8 +557,8 @@ static const yytype_uint8 yycheck[] =
 static const yytype_uint8 yystos[] =
 {
        0,    13,    14,     0,     1,     3,     6,     8,    15,    16,
-      17,     6,     7,    17,     4,     5,     9,    18,    19,    22,
-       6,    19,    20,    21,    22,    10,    11,    22,    19,    22
+      17,     6,     7,    17,     4,     5,     9,    18,    19,    20,
+      22,     6,    18,    21,    22,    10,    11,    22,    18,    22
 };
 
 #define yyerrok		(yyerrstatus = 0)
@@ -1148,7 +1148,7 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
 
 /* Line 1391 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
-	{ xlu__cfg_set_free((yyvaluep->setting)); };
+	{ xlu__cfg_value_free((yyvaluep->value)); };
 
 /* Line 1391 of yacc.c  */
 #line 1155 "libxlu_cfg_y.c"
@@ -1162,11 +1162,11 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
 /* Line 1391 of yacc.c  */
 #line 1164 "libxlu_cfg_y.c"
 	break;
-      case 20: /* "valuelist" */
+      case 20: /* "list" */
 
 /* Line 1391 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
-	{ xlu__cfg_set_free((yyvaluep->setting)); };
+	{ xlu__cfg_value_free((yyvaluep->value)); };
 
 /* Line 1391 of yacc.c  */
 #line 1173 "libxlu_cfg_y.c"
@@ -1175,7 +1175,7 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
 
 /* Line 1391 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
-	{ xlu__cfg_set_free((yyvaluep->setting)); };
+	{ xlu__cfg_value_free((yyvaluep->value)); };
 
 /* Line 1391 of yacc.c  */
 #line 1182 "libxlu_cfg_y.c"
@@ -1508,21 +1508,14 @@ yyreduce:
 
 /* Line 1806 of yacc.c  */
 #line 57 "libxlu_cfg_y.y"
-    { xlu__cfg_set_store(ctx,(yyvsp[(1) - (3)].string),(yyvsp[(3) - (3)].setting),(yylsp[(3) - (3)]).first_line); }
+    { xlu__cfg_set_store(ctx,(yyvsp[(1) - (3)].string),(yyvsp[(3) - (3)].value),(yylsp[(3) - (3)]).first_line); }
     break;
 
   case 12:
 
 /* Line 1806 of yacc.c  */
 #line 62 "libxlu_cfg_y.y"
-    { (yyval.setting)= xlu__cfg_set_mk(ctx,1,(yyvsp[(1) - (1)].string)); }
-    break;
-
-  case 13:
-
-/* Line 1806 of yacc.c  */
-#line 63 "libxlu_cfg_y.y"
-    { (yyval.setting)= (yyvsp[(3) - (4)].setting); }
+    { (yyval.value)= xlu__cfg_make_string(ctx,(yyvsp[(1) - (1)].string)); }
     break;
 
   case 14:
@@ -1543,41 +1536,34 @@ yyreduce:
 
 /* Line 1806 of yacc.c  */
 #line 68 "libxlu_cfg_y.y"
-    { (yyval.setting)= xlu__cfg_set_mk(ctx,0,0); }
+    { (yyval.value)= (yyvsp[(3) - (4)].value); }
     break;
 
   case 17:
 
 /* Line 1806 of yacc.c  */
-#line 69 "libxlu_cfg_y.y"
-    { (yyval.setting)= (yyvsp[(1) - (1)].setting); }
+#line 70 "libxlu_cfg_y.y"
+    { (yyval.value)= xlu__cfg_make_list(ctx,NULL); }
     break;
 
   case 18:
 
 /* Line 1806 of yacc.c  */
-#line 70 "libxlu_cfg_y.y"
-    { (yyval.setting)= (yyvsp[(1) - (3)].setting); }
+#line 71 "libxlu_cfg_y.y"
+    { (yyval.value)= xlu__cfg_make_list(ctx,(yyvsp[(1) - (2)].value)); }
     break;
 
   case 19:
 
 /* Line 1806 of yacc.c  */
 #line 72 "libxlu_cfg_y.y"
-    { (yyval.setting)= xlu__cfg_set_mk(ctx,2,(yyvsp[(1) - (2)].string)); }
-    break;
-
-  case 20:
-
-/* Line 1806 of yacc.c  */
-#line 73 "libxlu_cfg_y.y"
-    { xlu__cfg_set_add(ctx,(yyvsp[(1) - (5)].setting),(yyvsp[(4) - (5)].string)); (yyval.setting)= (yyvsp[(1) - (5)].setting); }
+    { xlu__cfg_list_append(ctx,(yyvsp[(1) - (5)].value),(yyvsp[(4) - (5)].value)); (yyval.value)= (yyvsp[(1) - (5)].value);}
     break;
 
 
 
 /* Line 1806 of yacc.c  */
-#line 1581 "libxlu_cfg_y.c"
+#line 1567 "libxlu_cfg_y.c"
       default: break;
     }
   /* User semantic actions sometimes alter yychar, and that requires
diff --git a/tools/libxl/libxlu_cfg_y.h b/tools/libxl/libxlu_cfg_y.h
index d7dfaf2..37e8213 100644
--- a/tools/libxl/libxlu_cfg_y.h
+++ b/tools/libxl/libxlu_cfg_y.h
@@ -54,7 +54,7 @@ typedef union YYSTYPE
 #line 25 "libxlu_cfg_y.y"
 
   char *string;
-  XLU_ConfigSetting *setting;
+  XLU_ConfigValue *value;
 
 
 
diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
index aa9f787..bd4156e 100644
--- a/tools/libxl/libxlu_cfg_y.y
+++ b/tools/libxl/libxlu_cfg_y.y
@@ -24,7 +24,7 @@
 
 %union {
   char *string;
-  XLU_ConfigSetting *setting;
+  XLU_ConfigValue *value;
 }
 
 %locations
@@ -39,8 +39,8 @@
 %type <string>            atom
 %destructor { free($$); } atom IDENT STRING NUMBER
 
-%type <setting>                         value valuelist values
-%destructor { xlu__cfg_set_free($$); }  value valuelist values
+%type <value>                         value list values
+%destructor { xlu__cfg_value_free($$); }  value list values
 
 %%
 
@@ -59,18 +59,17 @@ assignment: IDENT '=' value { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
 endstmt: NEWLINE
  |      ';'
 
-value:  atom                         { $$= xlu__cfg_set_mk(ctx,1,$1); }
- |      '[' nlok valuelist ']'       { $$= $3; }
+value:  atom                         { $$= xlu__cfg_make_string(ctx,$1); }
+ |      list
 
 atom:   STRING                   { $$= $1; }
  |      NUMBER                   { $$= $1; }
 
-valuelist: /* empty */           { $$= xlu__cfg_set_mk(ctx,0,0); }
- |      values                  { $$= $1; }
- |      values ',' nlok         { $$= $1; }
+list:   '[' nlok values ']'      { $$= $3; }
 
-values: atom nlok                  { $$= xlu__cfg_set_mk(ctx,2,$1); }
- |      values ',' nlok atom nlok  { xlu__cfg_set_add(ctx,$1,$4); $$= $1; }
+values: /* empty */                { $$= xlu__cfg_make_list(ctx,NULL); }
+ |      value nlok                 { $$= xlu__cfg_make_list(ctx,$1); }
+ |      values ',' nlok value nlok { xlu__cfg_list_append(ctx,$1,$4); $$= $1;}
 
 nlok:
         /* nothing */
diff --git a/tools/libxl/libxlu_internal.h b/tools/libxl/libxlu_internal.h
index 7579158..66eec28 100644
--- a/tools/libxl/libxlu_internal.h
+++ b/tools/libxl/libxlu_internal.h
@@ -23,17 +23,29 @@
 #include <assert.h>
 #include <regex.h>
 
-#define XLU_ConfigList XLU_ConfigSetting
-
 #include "libxlutil.h"
 
-struct XLU_ConfigSetting { /* transparent */
+typedef struct XLU_ConfigValue XLU_ConfigValue;
+
+typedef struct XLU_ConfigList {
+    int nvalues;
+    XLU_ConfigValue **values;
+} XLU_ConfigList;
+
+typedef struct XLU_ConfigValue {
+    enum XLU_ConfigValueType type;
+    union {
+        char *string;
+        XLU_ConfigList list;
+    } u;
+} XLU_ConfigValue;
+
+typedef struct XLU_ConfigSetting { /* transparent */
     struct XLU_ConfigSetting *next;
     char *name;
-    int nvalues, avalues; /* lists have avalues>1 */
-    char **values;
+    struct XLU_ConfigValue *value;
     int lineno;
-};
+} XLU_ConfigSetting;
 
 struct XLU_Config {
     XLU_ConfigSetting *settings;
diff --git a/tools/libxl/libxlutil.h b/tools/libxl/libxlutil.h
index 0333e55..37d9549 100644
--- a/tools/libxl/libxlutil.h
+++ b/tools/libxl/libxlutil.h
@@ -23,6 +23,15 @@
 /* Unless otherwise stated, all functions return an errno value. */
 typedef struct XLU_Config XLU_Config;
 typedef struct XLU_ConfigList XLU_ConfigList;
+typedef struct XLU_ConfigValue XLU_ConfigValue;
+enum XLU_ConfigValueType {
+    XLU_STRING,
+    XLU_LIST,
+};
+
+enum XLU_ConfigValueType xlu_cfg_value_type(const XLU_ConfigValue *value);
+const char *xlu_cfg_value_get_string(const XLU_ConfigValue *value);
+const XLU_ConfigList *xlu_cfg_value_get_list(const XLU_ConfigValue *value);
 
 XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename);
   /* 0 means we got ENOMEM. */
@@ -65,7 +74,7 @@ int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
 const char *xlu_cfg_get_listitem(const XLU_ConfigList*, int entry);
   /* xlu_cfg_get_listitem cannot fail, except that if entry is
    * out of range it returns 0 (not setting errno) */
-
+const XLU_ConfigValue *xlu_cfg_get_listitem2(const XLU_ConfigList*, int entry);
 
 /*
  * Disk specification parsing.
-- 
1.7.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 Dec 01 15:56:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKl-0002aP-Ce; Mon, 01 Dec 2014 15:56: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 1XvTKk-0002ZJ-AC
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:56:18 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	40/60-07724-1AF8C745; Mon, 01 Dec 2014 15:56:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417449374!10623500!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18726 invoked from network); 1 Dec 2014 15:56: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;
	1 Dec 2014 15:56:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198120073"
Received: from ukmail1.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, 1 Dec 2014 10:56:13 -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 1XvSyt-0005TR-IF;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:35 +0000
Message-ID: <1417448023-27311-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	Jan Beulich <jbeulich@suse.com>, boris.ostrovsky@oracle.com,
	ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 11/19] xen: handle XENMEMF_get_vnumainfo in
	compat_memory_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/common/compat/memory.c |   38 ++++++++++++++++++++++++++++++++++++++
 xen/include/xlat.lst       |    2 ++
 2 files changed, 40 insertions(+)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 06c90be..58cb847 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -15,6 +15,7 @@ CHECK_TYPE(domid);
 #undef xen_domid_t
 
 CHECK_mem_access_op;
+CHECK_vmemrange;
 
 int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
 {
@@ -32,12 +33,14 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
             struct xen_add_to_physmap *atp;
             struct xen_add_to_physmap_batch *atpb;
             struct xen_remove_from_physmap *xrfp;
+            struct xen_vnuma_topology_info *vnuma;
         } nat;
         union {
             struct compat_memory_reservation rsrv;
             struct compat_memory_exchange xchg;
             struct compat_add_to_physmap atp;
             struct compat_add_to_physmap_batch atpb;
+            struct compat_vnuma_topology_info vnuma;
         } cmp;
 
         set_xen_guest_handle(nat.hnd, COMPAT_ARG_XLAT_VIRT_BASE);
@@ -273,6 +276,33 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
             break;
         }
 
+        case XENMEM_get_vnumainfo:
+	{
+            enum XLAT_vnuma_topology_info_vdistance vdistance =
+                XLAT_vnuma_topology_info_vdistance_h;
+            enum XLAT_vnuma_topology_info_vcpu_to_vnode vcpu_to_vnode =
+                XLAT_vnuma_topology_info_vcpu_to_vnode_h;
+            enum XLAT_vnuma_topology_info_vmemrange vmemrange =
+                XLAT_vnuma_topology_info_vmemrange_h;
+
+            if ( copy_from_guest(&cmp.vnuma, compat, 1) )
+                return -EFAULT;
+
+#define XLAT_vnuma_topology_info_HNDL_vdistance_h(_d_, _s_)		\
+            guest_from_compat_handle((_d_)->vdistance.h, (_s_)->vdistance.h)
+#define XLAT_vnuma_topology_info_HNDL_vcpu_to_vnode_h(_d_, _s_)		\
+            guest_from_compat_handle((_d_)->vcpu_to_vnode.h, (_s_)->vcpu_to_vnode.h)
+#define XLAT_vnuma_topology_info_HNDL_vmemrange_h(_d_, _s_)		\
+            guest_from_compat_handle((_d_)->vmemrange.h, (_s_)->vmemrange.h)
+
+            XLAT_vnuma_topology_info(nat.vnuma, &cmp.vnuma);
+
+#undef XLAT_vnuma_topology_info_HNDL_vdistance_h
+#undef XLAT_vnuma_topology_info_HNDL_vcpu_to_vnode_h
+#undef XLAT_vnuma_topology_info_HNDL_vmemrange_h
+            break;
+	}
+
         default:
             return compat_arch_memory_op(cmd, compat);
         }
@@ -398,6 +428,14 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
         case XENMEM_remove_from_physmap:
             break;
 
+        case XENMEM_get_vnumainfo:
+            cmp.vnuma.nr_vnodes = nat.vnuma->nr_vnodes;
+            cmp.vnuma.nr_vcpus = nat.vnuma->nr_vcpus;
+            cmp.vnuma.nr_vmemranges = nat.vnuma->nr_vmemranges;
+            if ( __copy_to_guest(compat, &cmp.vnuma, 1) )
+                rc = -EFAULT;
+            break;
+
         default:
             domain_crash(current->domain);
             split = 0;
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 41b3e35..9c9fd9a 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -64,6 +64,8 @@
 ?	mem_access_op		memory.h
 !	pod_target			memory.h
 !	remove_from_physmap		memory.h
+?	vmemrange			memory.h
+!	vnuma_topology_info		memory.h
 ?	physdev_eoi			physdev.h
 ?	physdev_get_free_pirq		physdev.h
 ?	physdev_irq			physdev.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 Dec 01 15:56:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 15:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTKl-0002aP-Ce; Mon, 01 Dec 2014 15:56: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 1XvTKk-0002ZJ-AC
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 15:56:18 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	40/60-07724-1AF8C745; Mon, 01 Dec 2014 15:56:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417449374!10623500!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18726 invoked from network); 1 Dec 2014 15:56: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;
	1 Dec 2014 15:56:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198120073"
Received: from ukmail1.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, 1 Dec 2014 10:56:13 -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 1XvSyt-0005TR-IF;
	Mon, 01 Dec 2014 15:33:43 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 1 Dec 2014 15:33:35 +0000
Message-ID: <1417448023-27311-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	Jan Beulich <jbeulich@suse.com>, boris.ostrovsky@oracle.com,
	ufimtseva@gmail.com
Subject: [Xen-devel] [PATCH v2 11/19] xen: handle XENMEMF_get_vnumainfo in
	compat_memory_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/common/compat/memory.c |   38 ++++++++++++++++++++++++++++++++++++++
 xen/include/xlat.lst       |    2 ++
 2 files changed, 40 insertions(+)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 06c90be..58cb847 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -15,6 +15,7 @@ CHECK_TYPE(domid);
 #undef xen_domid_t
 
 CHECK_mem_access_op;
+CHECK_vmemrange;
 
 int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
 {
@@ -32,12 +33,14 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
             struct xen_add_to_physmap *atp;
             struct xen_add_to_physmap_batch *atpb;
             struct xen_remove_from_physmap *xrfp;
+            struct xen_vnuma_topology_info *vnuma;
         } nat;
         union {
             struct compat_memory_reservation rsrv;
             struct compat_memory_exchange xchg;
             struct compat_add_to_physmap atp;
             struct compat_add_to_physmap_batch atpb;
+            struct compat_vnuma_topology_info vnuma;
         } cmp;
 
         set_xen_guest_handle(nat.hnd, COMPAT_ARG_XLAT_VIRT_BASE);
@@ -273,6 +276,33 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
             break;
         }
 
+        case XENMEM_get_vnumainfo:
+	{
+            enum XLAT_vnuma_topology_info_vdistance vdistance =
+                XLAT_vnuma_topology_info_vdistance_h;
+            enum XLAT_vnuma_topology_info_vcpu_to_vnode vcpu_to_vnode =
+                XLAT_vnuma_topology_info_vcpu_to_vnode_h;
+            enum XLAT_vnuma_topology_info_vmemrange vmemrange =
+                XLAT_vnuma_topology_info_vmemrange_h;
+
+            if ( copy_from_guest(&cmp.vnuma, compat, 1) )
+                return -EFAULT;
+
+#define XLAT_vnuma_topology_info_HNDL_vdistance_h(_d_, _s_)		\
+            guest_from_compat_handle((_d_)->vdistance.h, (_s_)->vdistance.h)
+#define XLAT_vnuma_topology_info_HNDL_vcpu_to_vnode_h(_d_, _s_)		\
+            guest_from_compat_handle((_d_)->vcpu_to_vnode.h, (_s_)->vcpu_to_vnode.h)
+#define XLAT_vnuma_topology_info_HNDL_vmemrange_h(_d_, _s_)		\
+            guest_from_compat_handle((_d_)->vmemrange.h, (_s_)->vmemrange.h)
+
+            XLAT_vnuma_topology_info(nat.vnuma, &cmp.vnuma);
+
+#undef XLAT_vnuma_topology_info_HNDL_vdistance_h
+#undef XLAT_vnuma_topology_info_HNDL_vcpu_to_vnode_h
+#undef XLAT_vnuma_topology_info_HNDL_vmemrange_h
+            break;
+	}
+
         default:
             return compat_arch_memory_op(cmd, compat);
         }
@@ -398,6 +428,14 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
         case XENMEM_remove_from_physmap:
             break;
 
+        case XENMEM_get_vnumainfo:
+            cmp.vnuma.nr_vnodes = nat.vnuma->nr_vnodes;
+            cmp.vnuma.nr_vcpus = nat.vnuma->nr_vcpus;
+            cmp.vnuma.nr_vmemranges = nat.vnuma->nr_vmemranges;
+            if ( __copy_to_guest(compat, &cmp.vnuma, 1) )
+                rc = -EFAULT;
+            break;
+
         default:
             domain_crash(current->domain);
             split = 0;
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 41b3e35..9c9fd9a 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -64,6 +64,8 @@
 ?	mem_access_op		memory.h
 !	pod_target			memory.h
 !	remove_from_physmap		memory.h
+?	vmemrange			memory.h
+!	vnuma_topology_info		memory.h
 ?	physdev_eoi			physdev.h
 ?	physdev_get_free_pirq		physdev.h
 ?	physdev_irq			physdev.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 Dec 01 16:19:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 16:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTgr-0004eZ-OB; Mon, 01 Dec 2014 16:19:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XvTgq-0004eU-3h
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 16:19:08 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	7D/28-22737-BF49C745; Mon, 01 Dec 2014 16:19:07 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417450746!10918942!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 22103 invoked from network); 1 Dec 2014 16:19:06 -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; 1 Dec 2014 16:19:06 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0A5FBACEC;
	Mon,  1 Dec 2014 16:19:06 +0000 (UTC)
Date: Mon, 1 Dec 2014 17:19:05 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141201161905.GH25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C8F30.1010306@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, Peter Zijlstra <peterz@infradead.org>,
	x86@kernel.org, Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@suse.de>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 Mon, Dec 01, 2014 at 03:54:24PM +0000, David Vrabel wrote:
> On 01/12/14 15:44, Luis R. Rodriguez wrote:
> > On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> >> On 01/12/14 15:05, Luis R. Rodriguez wrote:
> >>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
> >>>> [...]
> >>>>>>> --- 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
> >>>>
> >>>> As Juergen points out, this does nothing.  You need to schedule while in
> >>>> the middle of the hypercall.
> >>>>
> >>>> Remember that Xen's hypercall preemption only preempts the hypercall to
> >>>> run interrupts in the guest.
> >>>
> >>> How is it ensured that when the kernel preempts on this code path on
> >>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
> >>
> >> Sorry, I really didn't describe this very well.
> >>
> >> If a hypercall needs a continuation, Xen returns to the guest with the
> >> IP set to the hypercall instruction, and on the way back to the guest
> >> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
> >>
> >> The guest is free to return from the upcall to the original task
> >> (continuing the hypercall) or to a different one.
> > 
> > OK so that addresses what Xen will do when using continuation and
> > hypercall preemption, my concern here was that using
> > preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
> > hypercall on the return from an interrupt (e.g., the timer interrupt)
> > would still let the kernel preempt to tasks other than those related
> > to Xen.
> 
> Um.  Why would that be a problem?  We do want to switch to any task the
> Linux scheduler thinks is best.

Its safe but -- it technically is doing kernel preemption, unless we want
to adjust the definition of CONFIG_PREEMPT=n to exclude hypercalls. This
was my original concern with the use of preempt_schedule_irq() to do this.
I am afraid of setting precedents without being clear or wider review and
acceptance.

  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 16:19:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 16:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvTgr-0004eZ-OB; Mon, 01 Dec 2014 16:19:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XvTgq-0004eU-3h
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 16:19:08 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	7D/28-22737-BF49C745; Mon, 01 Dec 2014 16:19:07 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417450746!10918942!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 22103 invoked from network); 1 Dec 2014 16:19:06 -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; 1 Dec 2014 16:19:06 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0A5FBACEC;
	Mon,  1 Dec 2014 16:19:06 +0000 (UTC)
Date: Mon, 1 Dec 2014 17:19:05 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141201161905.GH25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C8F30.1010306@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, Peter Zijlstra <peterz@infradead.org>,
	x86@kernel.org, Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@suse.de>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 Mon, Dec 01, 2014 at 03:54:24PM +0000, David Vrabel wrote:
> On 01/12/14 15:44, Luis R. Rodriguez wrote:
> > On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> >> On 01/12/14 15:05, Luis R. Rodriguez wrote:
> >>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
> >>>> [...]
> >>>>>>> --- 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
> >>>>
> >>>> As Juergen points out, this does nothing.  You need to schedule while in
> >>>> the middle of the hypercall.
> >>>>
> >>>> Remember that Xen's hypercall preemption only preempts the hypercall to
> >>>> run interrupts in the guest.
> >>>
> >>> How is it ensured that when the kernel preempts on this code path on
> >>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
> >>
> >> Sorry, I really didn't describe this very well.
> >>
> >> If a hypercall needs a continuation, Xen returns to the guest with the
> >> IP set to the hypercall instruction, and on the way back to the guest
> >> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
> >>
> >> The guest is free to return from the upcall to the original task
> >> (continuing the hypercall) or to a different one.
> > 
> > OK so that addresses what Xen will do when using continuation and
> > hypercall preemption, my concern here was that using
> > preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
> > hypercall on the return from an interrupt (e.g., the timer interrupt)
> > would still let the kernel preempt to tasks other than those related
> > to Xen.
> 
> Um.  Why would that be a problem?  We do want to switch to any task the
> Linux scheduler thinks is best.

Its safe but -- it technically is doing kernel preemption, unless we want
to adjust the definition of CONFIG_PREEMPT=n to exclude hypercalls. This
was my original concern with the use of preempt_schedule_irq() to do this.
I am afraid of setting precedents without being clear or wider review and
acceptance.

  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 16:28:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 16: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 1XvTpY-00053j-OG; Mon, 01 Dec 2014 16:28: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 1XvTpW-00053b-Hg
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 16:28:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EF/F0-09842-5179C745; Mon, 01 Dec 2014 16:28:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417451285!9209569!1
X-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 16701 invoked from network); 1 Dec 2014 16:28:05 -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; 1 Dec 2014 16:28:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 16:28:04 +0000
Message-Id: <547CA522020000780004BDEE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 16:28:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>
	<1417426153-12893-2-git-send-email-jgross@suse.com>
	<547C4DD6020000780004BA83@mail.emea.novell.com>
	<547C4ECB.7070702@citrix.com> <547C5F31020000780004BB1F@suse.com>
	<547C68FD.60000@suse.com> <547C7D13020000780004BC3D@suse.com>
	<547C7C22.4020601@suse.com>
In-Reply-To: <547C7C22.4020601@suse.com>
Mime-Version: 1.0
Content-Length: 5840
Content-Disposition: inline
Cc: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [Patch V2] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDAxLjEyLjE0IGF0IDE1OjMzLCA8Skdyb3NzQHN1c2UuY29tPiB3cm90ZToKPiBPbiAx
Mi8wMS8yMDE0IDAyOjM3IFBNLCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4gT24gMDEuMTIuMTQg
YXQgMTQ6MTEsIDxKR3Jvc3NAc3VzZS5jb20+IHdyb3RlOgo+Pj4gT24gMTIvMDEvMjAxNCAxMjoy
OSBQTSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4+Pj4gT24gMDEuMTIuMTQgYXQgMTI6MTksIDxk
YXZpZC52cmFiZWxAY2l0cml4LmNvbT4gd3JvdGU6Cj4+Pj4+IE9uIDAxLzEyLzE0IDEwOjE1LCBK
YW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+Pj4+IE9uIDAxLjEyLjE0IGF0IDEwOjI5LCA8Skdyb3Nz
QHN1c2UuY29tPiB3cm90ZToKPj4+Pj4+PiBUaGUgeDg2IHN0cnVjdCBhcmNoX3NoYXJlZF9pbmZv
IGZpZWxkIHBmbl90b19tZm5fZnJhbWVfbGlzdF9saXN0Cj4+Pj4+Pj4gY3VycmVudGx5IGNvbnRh
aW5zIHRoZSBtZm4gb2YgdGhlIHRvcCBsZXZlbCBwYWdlIGZyYW1lIG9mIHRoZSAzIGxldmVsCj4+
Pj4+Pj4gcDJtIHRyZWUsIHdoaWNoIGlzIHVzZWQgYnkgdGhlIFhlbiB0b29scyBkdXJpbmcgc2F2
aW5nIGFuZCByZXN0b3JpbmcKPj4+Pj4+PiAoYW5kIGxpdmUgbWlncmF0aW9uKSBvZiBwdiBkb21h
aW5zIGFuZCBmb3IgY3Jhc2ggZHVtcCBhbmFseXNpcy4gV2l0aAo+Pj4+Pj4+IHRocmVlIGxldmVs
cyBvZiB0aGUgcDJtIHRyZWUgaXQgaXMgcG9zc2libGUgdG8gc3VwcG9ydCB1cCB0byA1MTIgR0Ig
b2YKPj4+Pj4+PiBSQU0gZm9yIGEgNjQgYml0IHB2IGRvbWFpbi4KPj4+Pj4+Pgo+Pj4+Pj4+IEEg
MzIgYml0IHB2IGRvbWFpbiBjYW4gc3VwcG9ydCBtb3JlLCBhcyBlYWNoIG1lbW9yeSBwYWdlIGNh
biBob2xkIDEwMjQKPj4+Pj4+PiBpbnN0ZWFkIG9mIDUxMiBlbnRyaWVzLCBsZWFkaW5nIHRvIGEg
bGltaXQgb2YgNCBUQi4KPj4+Pj4+Pgo+Pj4+Pj4+IFRvIGJlIGFibGUgdG8gc3VwcG9ydCBtb3Jl
IFJBTSBvbiB4ODYtNjQgc3dpdGNoIHRvIGEgdmlydHVhbCBtYXBwZWQKPj4+Pj4+PiBwMm0gbGlz
dC4KPj4+Pj4+Pgo+Pj4+Pj4+IFRoaXMgcGF0Y2ggZXhwYW5kcyBzdHJ1Y3QgYXJjaF9zaGFyZWRf
aW5mbyB3aXRoIGEgbmV3IHAybSBsaXN0IHZpcnR1YWwKPj4+Pj4+PiBhZGRyZXNzLCB0aGUgcm9v
dCBvZiB0aGUgcGFnZSB0YWJsZSByb290IGFuZCBhIHAybSBnZW5lcmF0aW9uIGNvdW50Lgo+Pj4+
Pj4+IFRoZSBuZXcgaW5mb3JtYXRpb24gaXMgaW5kaWNhdGVkIGJ5IHRoZSBkb21haW4gdG8gYmUg
dmFsaWQgYnkgc3RvcmluZwo+Pj4+Pj4+IH4wVUwgaW50byBwZm5fdG9fbWZuX2ZyYW1lX2xpc3Rf
bGlzdC4gVGhlIGh5cGVydmlzb3IgaW5kaWNhdGVzCj4+Pj4+Pj4gdXNhYmlsaXR5IG9mIHRoaXMg
ZmVhdHVyZSBieSBhIG5ldyBmbGFnIFhFTkZFQVRfdmlydHVhbF9wMm0uCj4+Pj4+Pj4KPj4+Pj4+
PiBSaWdodCBub3cgWEVORkVBVF92aXJ0dWFsX3AybSB3aWxsIG5vdCBiZSBzZXQuIFRoaXMgd2ls
bCBjaGFuZ2Ugd2hlbgo+Pj4+Pj4+IHRoZSBYZW4gdG9vbHMgc3VwcG9ydCB0aGUgdmlydHVhbCBt
YXBwZWQgcDJtIGxpc3QuCj4+Pj4+Pgo+Pj4+Pj4gVGhpcyBzZWVtcyB3cm9uZzogWEVORkVBVF8q
IG9ubHkgcmVmbGVjdCBoeXBlcnZpc29yIGNhcGFiaWxpdGllcy4KPj4+Pj4+IEkuZS4gdGhlIGF2
YWlsYWJpbGl0eSBvZiB0aGUgbmV3IGZ1bmN0aW9uYWxpdHkgbWF5IG5lZWQgdG8gYmUKPj4+Pj4+
IGFkdmVydGlzZWQgYW5vdGhlciB3YXkgLSB4ZW5zdG9yZSBwZXJoYXBzPwo+Pj4+Pgo+Pj4+PiBY
ZW5zdG9yZSBkb2Vzbid0IHdvcmsgZm9yIGRvbTAuCj4+Pj4+Cj4+Pj4+IFNob3VsZG4ndCB0aGlz
IGJlIHNvbWV0aGluZyB0aGUgZ3Vlc3Qga2VybmVsIHJlcG9ydHMgdXNpbmcgYSBFTEYgbm90ZSBi
aXQ/Cj4+Pj4+Cj4+Pj4+IFdoZW4gYnVpbGRpbmcgYSBkb21haW4gKGVpdGhlciBpbiBYZW4gZm9y
IGRvbTAgb3IgaW4gdGhlIHRvb2xzKSwgdGhlCj4+Pj4+IGJ1aWxkZXIgbWF5IHByb3ZpZGUgYSBs
aW5lYXIgcDJtIGlmZiBzdXBwb3J0ZWQgYnkgdGhlIGd1ZXN0IGtlcm5lbCBhbmQKPj4+Pj4gdGhl
biAoYW5kIG9ubHkgdGhlbikgY2FuIGl0IHByb3ZpZGUgYSBndWVzdCB3aXRoID4gNTEyIEdpQi4K
Pj4+Pgo+Pj4+IFllcywgc3VyZWx5IHRoaXMgZmxhZyBjb3VsZCBhY3QgYXMgYSBrZXJuZWwgY2Fw
YWJpbGl0eSBpbmRpY2F0b3IgKHZpYQo+Pj4+IHRoZSBYRU5fRUxGTk9URV9TVVBQT1JURURfRkVB
VFVSRVMgbm90ZSksIGxpa2UgZS5nLgo+Pj4+IFhFTkZFQVRfZG9tMCBhbHJlYWR5IGRvZXMuIErD
vHJnZW4ncyBmaW5hbCBzdGF0ZW1lbnQsIGhvd2V2ZXIsCj4+Pj4gc3VnZ2VzdGVkIHRvIG1lIHRo
YXQgdGhpcyBpcyBtZWFudCB0byBiZSBvbmx5IGNvbnN1bWVkIGJ5IGtlcm5lbHMuCj4+Pgo+Pj4g
WWVzLiBUaGUgcDJtIGxpc3QgYnVpbHQgYnkgdGhlIGRvbWFpbiBidWlsZGVyIGlzIGFscmVhZHkg
bGluZWFyLiBJdCBtYXkKPj4+IGp1c3QgYmUgdG8gc21hbGwgdG8gaG9sZCBhbGwgZW50cmllcyBy
ZXF1aXJlZCBlLmcuIGZvciBEb20wLgo+Pj4KPj4+IEl0J3MgWGVuLXRvb2xzIGFuZCBrZHVtcCB3
aGljaCBoYXZlIHRvIGRlYWwgd2l0aCB0aGUgbGluZWFyIHAybSBsaXN0Lgo+Pj4gU28gdGhlIGd1
ZXN0IGtlcm5lbCBoYXMgdG8gYmUgdG9sZCBpZiBpdCBpcyBhbGxvd2VkIHRvIHByZXNlbnQgdGhl
Cj4+PiBsaW5lYXIgbGlzdCBpbnN0ZWFkIG9mIHRoZSAzLWxldmVsIHRyZWUgYXQgcGZuX3RvX21m
bl9mcmFtZV9saXN0X2xpc3QuCj4+Pgo+Pj4gQXMgdGhpcyBpcyB0cnVlIGZvciBEb20wIGFzIHdl
bGwsIHRoaXMgaW5mb3JtYXRpb24gbXVzdCBiZSBnaXZlbiBieSB0aGUKPj4+IGh5cGVydmlzb3Iu
Cj4+Pgo+Pj4gSSdtIGF3YXJlIHRoYXQgWEVORkVBVF8qIGlzIG9ubHkgdXNlZCBmb3IgaHlwZXJ2
aXNvciBjYXBhYmlsaXRpZXMgdXAgdG8KPj4+IG5vdy4gQXMgdGhlIFhlbiB0b29scyBhcmUgdGln
aHRseSBjb3VwbGVkIHRvIHRoZSBoeXBlcnZpc29yIEkgZG9uJ3Qgc2VlCj4+PiB3aHkgdGhlIGZl
YXR1cmVzIGNhbid0IGV4cHJlc3MgdGhlIGNhcGFiaWxpdHkgb2YgdGhlIGNvbXBsZXRlIFhlbgo+
Pj4gaW5zdGFsbGF0aW9uIGluc3RlYWQuIFdvdWxkIHlvdSBwcmVmZXIgaW50cm9kdWNpbmcgYW5v
dGhlciBsZWFmIGZvcgo+Pj4gdGhhdCBwdXJwb3NlIChzdWJtYXAuaWR4ID09IDEpID8KPj4KPj4g
VGhhdCB3b3VsZG4ndCBjaGFuZ2UgdGhlIG9kZCBzaXR1YXRpb24gb2YgcmVwb3J0aW5nIGEgY2Fw
YWJpbGl0eSBvZgo+PiBhbm90aGVyIGNvbXBvbmVudC4gVGhhdCdzIGV2ZW4gbW9yZSBvZiBhIHBy
b2JsZW0gZm9yIHRoZSBEb20wCj4+IGNhc2UsIHdoZXJlIHRoZSBhZmZlY3RlZCB0b29sIChrZHVt
cCkgaXNuJ3QgZXZlbiB1bmRlciBvdXIgY29udHJvbAo+PiAoYW5kIHNob3VsZG4ndCBiZSkuCj4+
Cj4+IEJ1dCBpbiB0aGUgZW5kIC0gd2hhdCdzIHdyb25nIHdpdGggYWx3YXlzIChvciBjb25kaXRp
b25hbGx5IHVwb24gYQo+PiBDT05GSUdfKiBvcHRpb24gYW5kL29yIGNvbW1hbmQgbGluZSBwYXJh
bWV0ZXIgYW5kL29yIG1lbW9yeQo+PiBzaXplKSBmaWxsaW5nIGJvdGggdGhlIG9sZCBhbmQgbmV3
IHNoYXJlZCBpbmZvIGZpZWxkcz8gQSBjYXBhYmxlIHRvb2wKPj4gY2FuIGRldGVybWluZSB3aGV0
aGVyIHRoZSBuZXcgb25lIGlzIHZhbGlkLCBhbmQgYW4gaW5jYXBhYmxlIHRvb2wKPj4gd29uJ3Qg
d29yayBvbiBodWdlIG1lbW9yeSBjb25maWdzIGFueXdheS4KPiAKPiBPa2F5LCBidXQgdGhpcyB3
b3VsZCByZXF1aXJlIGFub3RoZXIgd2F5IG9mIHJlcG9ydGluZyB0aGUgdmFsaWRpdHkgb2YKPiB0
aGUgbGluZWFyIHAybSBsaXN0IGFuY2hvciwgYXMgc2V0dGluZyBwZm5fdG9fbWZuX2ZyYW1lX2xp
c3RfbGlzdCB0bwo+IGFuIGludmFsaWQgdmFsdWUgaXMgbm8gbG9uZ2VyIGFuIG9wdGlvbiB0aGVu
Lgo+IAo+IEFzIHRoZSBzaGFyZWQgaW5mbyBwYWdlIGlzIGFsd2F5cyB6ZXJvZWQgd2hlbiB0aGUg
ZG9tYWluIGlzIGJ1aWx0IHdlCj4gY291bGQgdXNlIGEgdmFsdWUgZGlmZmVyZW50IGZyb20gMCBv
ZiBlLmcuIHRoZSBwMm1fZ2VuZXJhdGlvbiBtZW1iZXIKPiBhcyBhbiBpbmRpY2F0b3IgZm9yIHRo
ZSB2YWxpZGl0eS4KCldvdWxkbid0IGJvdGggb2YgdGhlIG90aGVyIG5ldyBmaWVsZHMgYmUgZ3Vh
cmFudGVlZCBub24temVybwp3aGVuIHVzZWQ/CgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 01 16:28:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 16: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 1XvTpY-00053j-OG; Mon, 01 Dec 2014 16:28: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 1XvTpW-00053b-Hg
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 16:28:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EF/F0-09842-5179C745; Mon, 01 Dec 2014 16:28:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417451285!9209569!1
X-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 16701 invoked from network); 1 Dec 2014 16:28:05 -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; 1 Dec 2014 16:28:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 01 Dec 2014 16:28:04 +0000
Message-Id: <547CA522020000780004BDEE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 01 Dec 2014 16:28:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <JGross@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>
	<1417426153-12893-2-git-send-email-jgross@suse.com>
	<547C4DD6020000780004BA83@mail.emea.novell.com>
	<547C4ECB.7070702@citrix.com> <547C5F31020000780004BB1F@suse.com>
	<547C68FD.60000@suse.com> <547C7D13020000780004BC3D@suse.com>
	<547C7C22.4020601@suse.com>
In-Reply-To: <547C7C22.4020601@suse.com>
Mime-Version: 1.0
Content-Length: 5840
Content-Disposition: inline
Cc: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [Patch V2] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDAxLjEyLjE0IGF0IDE1OjMzLCA8Skdyb3NzQHN1c2UuY29tPiB3cm90ZToKPiBPbiAx
Mi8wMS8yMDE0IDAyOjM3IFBNLCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4gT24gMDEuMTIuMTQg
YXQgMTQ6MTEsIDxKR3Jvc3NAc3VzZS5jb20+IHdyb3RlOgo+Pj4gT24gMTIvMDEvMjAxNCAxMjoy
OSBQTSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4+Pj4gT24gMDEuMTIuMTQgYXQgMTI6MTksIDxk
YXZpZC52cmFiZWxAY2l0cml4LmNvbT4gd3JvdGU6Cj4+Pj4+IE9uIDAxLzEyLzE0IDEwOjE1LCBK
YW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+Pj4+IE9uIDAxLjEyLjE0IGF0IDEwOjI5LCA8Skdyb3Nz
QHN1c2UuY29tPiB3cm90ZToKPj4+Pj4+PiBUaGUgeDg2IHN0cnVjdCBhcmNoX3NoYXJlZF9pbmZv
IGZpZWxkIHBmbl90b19tZm5fZnJhbWVfbGlzdF9saXN0Cj4+Pj4+Pj4gY3VycmVudGx5IGNvbnRh
aW5zIHRoZSBtZm4gb2YgdGhlIHRvcCBsZXZlbCBwYWdlIGZyYW1lIG9mIHRoZSAzIGxldmVsCj4+
Pj4+Pj4gcDJtIHRyZWUsIHdoaWNoIGlzIHVzZWQgYnkgdGhlIFhlbiB0b29scyBkdXJpbmcgc2F2
aW5nIGFuZCByZXN0b3JpbmcKPj4+Pj4+PiAoYW5kIGxpdmUgbWlncmF0aW9uKSBvZiBwdiBkb21h
aW5zIGFuZCBmb3IgY3Jhc2ggZHVtcCBhbmFseXNpcy4gV2l0aAo+Pj4+Pj4+IHRocmVlIGxldmVs
cyBvZiB0aGUgcDJtIHRyZWUgaXQgaXMgcG9zc2libGUgdG8gc3VwcG9ydCB1cCB0byA1MTIgR0Ig
b2YKPj4+Pj4+PiBSQU0gZm9yIGEgNjQgYml0IHB2IGRvbWFpbi4KPj4+Pj4+Pgo+Pj4+Pj4+IEEg
MzIgYml0IHB2IGRvbWFpbiBjYW4gc3VwcG9ydCBtb3JlLCBhcyBlYWNoIG1lbW9yeSBwYWdlIGNh
biBob2xkIDEwMjQKPj4+Pj4+PiBpbnN0ZWFkIG9mIDUxMiBlbnRyaWVzLCBsZWFkaW5nIHRvIGEg
bGltaXQgb2YgNCBUQi4KPj4+Pj4+Pgo+Pj4+Pj4+IFRvIGJlIGFibGUgdG8gc3VwcG9ydCBtb3Jl
IFJBTSBvbiB4ODYtNjQgc3dpdGNoIHRvIGEgdmlydHVhbCBtYXBwZWQKPj4+Pj4+PiBwMm0gbGlz
dC4KPj4+Pj4+Pgo+Pj4+Pj4+IFRoaXMgcGF0Y2ggZXhwYW5kcyBzdHJ1Y3QgYXJjaF9zaGFyZWRf
aW5mbyB3aXRoIGEgbmV3IHAybSBsaXN0IHZpcnR1YWwKPj4+Pj4+PiBhZGRyZXNzLCB0aGUgcm9v
dCBvZiB0aGUgcGFnZSB0YWJsZSByb290IGFuZCBhIHAybSBnZW5lcmF0aW9uIGNvdW50Lgo+Pj4+
Pj4+IFRoZSBuZXcgaW5mb3JtYXRpb24gaXMgaW5kaWNhdGVkIGJ5IHRoZSBkb21haW4gdG8gYmUg
dmFsaWQgYnkgc3RvcmluZwo+Pj4+Pj4+IH4wVUwgaW50byBwZm5fdG9fbWZuX2ZyYW1lX2xpc3Rf
bGlzdC4gVGhlIGh5cGVydmlzb3IgaW5kaWNhdGVzCj4+Pj4+Pj4gdXNhYmlsaXR5IG9mIHRoaXMg
ZmVhdHVyZSBieSBhIG5ldyBmbGFnIFhFTkZFQVRfdmlydHVhbF9wMm0uCj4+Pj4+Pj4KPj4+Pj4+
PiBSaWdodCBub3cgWEVORkVBVF92aXJ0dWFsX3AybSB3aWxsIG5vdCBiZSBzZXQuIFRoaXMgd2ls
bCBjaGFuZ2Ugd2hlbgo+Pj4+Pj4+IHRoZSBYZW4gdG9vbHMgc3VwcG9ydCB0aGUgdmlydHVhbCBt
YXBwZWQgcDJtIGxpc3QuCj4+Pj4+Pgo+Pj4+Pj4gVGhpcyBzZWVtcyB3cm9uZzogWEVORkVBVF8q
IG9ubHkgcmVmbGVjdCBoeXBlcnZpc29yIGNhcGFiaWxpdGllcy4KPj4+Pj4+IEkuZS4gdGhlIGF2
YWlsYWJpbGl0eSBvZiB0aGUgbmV3IGZ1bmN0aW9uYWxpdHkgbWF5IG5lZWQgdG8gYmUKPj4+Pj4+
IGFkdmVydGlzZWQgYW5vdGhlciB3YXkgLSB4ZW5zdG9yZSBwZXJoYXBzPwo+Pj4+Pgo+Pj4+PiBY
ZW5zdG9yZSBkb2Vzbid0IHdvcmsgZm9yIGRvbTAuCj4+Pj4+Cj4+Pj4+IFNob3VsZG4ndCB0aGlz
IGJlIHNvbWV0aGluZyB0aGUgZ3Vlc3Qga2VybmVsIHJlcG9ydHMgdXNpbmcgYSBFTEYgbm90ZSBi
aXQ/Cj4+Pj4+Cj4+Pj4+IFdoZW4gYnVpbGRpbmcgYSBkb21haW4gKGVpdGhlciBpbiBYZW4gZm9y
IGRvbTAgb3IgaW4gdGhlIHRvb2xzKSwgdGhlCj4+Pj4+IGJ1aWxkZXIgbWF5IHByb3ZpZGUgYSBs
aW5lYXIgcDJtIGlmZiBzdXBwb3J0ZWQgYnkgdGhlIGd1ZXN0IGtlcm5lbCBhbmQKPj4+Pj4gdGhl
biAoYW5kIG9ubHkgdGhlbikgY2FuIGl0IHByb3ZpZGUgYSBndWVzdCB3aXRoID4gNTEyIEdpQi4K
Pj4+Pgo+Pj4+IFllcywgc3VyZWx5IHRoaXMgZmxhZyBjb3VsZCBhY3QgYXMgYSBrZXJuZWwgY2Fw
YWJpbGl0eSBpbmRpY2F0b3IgKHZpYQo+Pj4+IHRoZSBYRU5fRUxGTk9URV9TVVBQT1JURURfRkVB
VFVSRVMgbm90ZSksIGxpa2UgZS5nLgo+Pj4+IFhFTkZFQVRfZG9tMCBhbHJlYWR5IGRvZXMuIErD
vHJnZW4ncyBmaW5hbCBzdGF0ZW1lbnQsIGhvd2V2ZXIsCj4+Pj4gc3VnZ2VzdGVkIHRvIG1lIHRo
YXQgdGhpcyBpcyBtZWFudCB0byBiZSBvbmx5IGNvbnN1bWVkIGJ5IGtlcm5lbHMuCj4+Pgo+Pj4g
WWVzLiBUaGUgcDJtIGxpc3QgYnVpbHQgYnkgdGhlIGRvbWFpbiBidWlsZGVyIGlzIGFscmVhZHkg
bGluZWFyLiBJdCBtYXkKPj4+IGp1c3QgYmUgdG8gc21hbGwgdG8gaG9sZCBhbGwgZW50cmllcyBy
ZXF1aXJlZCBlLmcuIGZvciBEb20wLgo+Pj4KPj4+IEl0J3MgWGVuLXRvb2xzIGFuZCBrZHVtcCB3
aGljaCBoYXZlIHRvIGRlYWwgd2l0aCB0aGUgbGluZWFyIHAybSBsaXN0Lgo+Pj4gU28gdGhlIGd1
ZXN0IGtlcm5lbCBoYXMgdG8gYmUgdG9sZCBpZiBpdCBpcyBhbGxvd2VkIHRvIHByZXNlbnQgdGhl
Cj4+PiBsaW5lYXIgbGlzdCBpbnN0ZWFkIG9mIHRoZSAzLWxldmVsIHRyZWUgYXQgcGZuX3RvX21m
bl9mcmFtZV9saXN0X2xpc3QuCj4+Pgo+Pj4gQXMgdGhpcyBpcyB0cnVlIGZvciBEb20wIGFzIHdl
bGwsIHRoaXMgaW5mb3JtYXRpb24gbXVzdCBiZSBnaXZlbiBieSB0aGUKPj4+IGh5cGVydmlzb3Iu
Cj4+Pgo+Pj4gSSdtIGF3YXJlIHRoYXQgWEVORkVBVF8qIGlzIG9ubHkgdXNlZCBmb3IgaHlwZXJ2
aXNvciBjYXBhYmlsaXRpZXMgdXAgdG8KPj4+IG5vdy4gQXMgdGhlIFhlbiB0b29scyBhcmUgdGln
aHRseSBjb3VwbGVkIHRvIHRoZSBoeXBlcnZpc29yIEkgZG9uJ3Qgc2VlCj4+PiB3aHkgdGhlIGZl
YXR1cmVzIGNhbid0IGV4cHJlc3MgdGhlIGNhcGFiaWxpdHkgb2YgdGhlIGNvbXBsZXRlIFhlbgo+
Pj4gaW5zdGFsbGF0aW9uIGluc3RlYWQuIFdvdWxkIHlvdSBwcmVmZXIgaW50cm9kdWNpbmcgYW5v
dGhlciBsZWFmIGZvcgo+Pj4gdGhhdCBwdXJwb3NlIChzdWJtYXAuaWR4ID09IDEpID8KPj4KPj4g
VGhhdCB3b3VsZG4ndCBjaGFuZ2UgdGhlIG9kZCBzaXR1YXRpb24gb2YgcmVwb3J0aW5nIGEgY2Fw
YWJpbGl0eSBvZgo+PiBhbm90aGVyIGNvbXBvbmVudC4gVGhhdCdzIGV2ZW4gbW9yZSBvZiBhIHBy
b2JsZW0gZm9yIHRoZSBEb20wCj4+IGNhc2UsIHdoZXJlIHRoZSBhZmZlY3RlZCB0b29sIChrZHVt
cCkgaXNuJ3QgZXZlbiB1bmRlciBvdXIgY29udHJvbAo+PiAoYW5kIHNob3VsZG4ndCBiZSkuCj4+
Cj4+IEJ1dCBpbiB0aGUgZW5kIC0gd2hhdCdzIHdyb25nIHdpdGggYWx3YXlzIChvciBjb25kaXRp
b25hbGx5IHVwb24gYQo+PiBDT05GSUdfKiBvcHRpb24gYW5kL29yIGNvbW1hbmQgbGluZSBwYXJh
bWV0ZXIgYW5kL29yIG1lbW9yeQo+PiBzaXplKSBmaWxsaW5nIGJvdGggdGhlIG9sZCBhbmQgbmV3
IHNoYXJlZCBpbmZvIGZpZWxkcz8gQSBjYXBhYmxlIHRvb2wKPj4gY2FuIGRldGVybWluZSB3aGV0
aGVyIHRoZSBuZXcgb25lIGlzIHZhbGlkLCBhbmQgYW4gaW5jYXBhYmxlIHRvb2wKPj4gd29uJ3Qg
d29yayBvbiBodWdlIG1lbW9yeSBjb25maWdzIGFueXdheS4KPiAKPiBPa2F5LCBidXQgdGhpcyB3
b3VsZCByZXF1aXJlIGFub3RoZXIgd2F5IG9mIHJlcG9ydGluZyB0aGUgdmFsaWRpdHkgb2YKPiB0
aGUgbGluZWFyIHAybSBsaXN0IGFuY2hvciwgYXMgc2V0dGluZyBwZm5fdG9fbWZuX2ZyYW1lX2xp
c3RfbGlzdCB0bwo+IGFuIGludmFsaWQgdmFsdWUgaXMgbm8gbG9uZ2VyIGFuIG9wdGlvbiB0aGVu
Lgo+IAo+IEFzIHRoZSBzaGFyZWQgaW5mbyBwYWdlIGlzIGFsd2F5cyB6ZXJvZWQgd2hlbiB0aGUg
ZG9tYWluIGlzIGJ1aWx0IHdlCj4gY291bGQgdXNlIGEgdmFsdWUgZGlmZmVyZW50IGZyb20gMCBv
ZiBlLmcuIHRoZSBwMm1fZ2VuZXJhdGlvbiBtZW1iZXIKPiBhcyBhbiBpbmRpY2F0b3IgZm9yIHRo
ZSB2YWxpZGl0eS4KCldvdWxkbid0IGJvdGggb2YgdGhlIG90aGVyIG5ldyBmaWVsZHMgYmUgZ3Vh
cmFudGVlZCBub24temVybwp3aGVuIHVzZWQ/CgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 01 16:39:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 16:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvU0A-0005Qb-Tu; Mon, 01 Dec 2014 16:39:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XvU09-0005QW-SG
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 16:39:06 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	C2/59-05632-9A99C745; Mon, 01 Dec 2014 16:39:05 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417451944!15057217!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 10371 invoked from network); 1 Dec 2014 16:39:04 -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; 1 Dec 2014 16:39:04 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 5D030ACEC;
	Mon,  1 Dec 2014 16:39:03 +0000 (UTC)
Message-ID: <547C99A6.7040607@suse.com>
Date: Mon, 01 Dec 2014 17:39:02 +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: Jan Beulich <JBeulich@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>	<1417426153-12893-2-git-send-email-jgross@suse.com>	<547C4DD6020000780004BA83@mail.emea.novell.com>	<547C4ECB.7070702@citrix.com>
	<547C5F31020000780004BB1F@suse.com>	<547C68FD.60000@suse.com>
	<547C7D13020000780004BC3D@suse.com>	<547C7C22.4020601@suse.com>
	<547CA522020000780004BDEE@mail.emea.novell.com>
In-Reply-To: <547CA522020000780004BDEE@mail.emea.novell.com>
Content-Length: 6237
Cc: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [Patch V2] 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: 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

T24gMTIvMDEvMjAxNCAwNToyOCBQTSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4gT24gMDEuMTIu
MTQgYXQgMTU6MzMsIDxKR3Jvc3NAc3VzZS5jb20+IHdyb3RlOgo+PiBPbiAxMi8wMS8yMDE0IDAy
OjM3IFBNLCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+IE9uIDAxLjEyLjE0IGF0IDE0OjExLCA8
Skdyb3NzQHN1c2UuY29tPiB3cm90ZToKPj4+PiBPbiAxMi8wMS8yMDE0IDEyOjI5IFBNLCBKYW4g
QmV1bGljaCB3cm90ZToKPj4+Pj4+Pj4gT24gMDEuMTIuMTQgYXQgMTI6MTksIDxkYXZpZC52cmFi
ZWxAY2l0cml4LmNvbT4gd3JvdGU6Cj4+Pj4+PiBPbiAwMS8xMi8xNCAxMDoxNSwgSmFuIEJldWxp
Y2ggd3JvdGU6Cj4+Pj4+Pj4+Pj4gT24gMDEuMTIuMTQgYXQgMTA6MjksIDxKR3Jvc3NAc3VzZS5j
b20+IHdyb3RlOgo+Pj4+Pj4+PiBUaGUgeDg2IHN0cnVjdCBhcmNoX3NoYXJlZF9pbmZvIGZpZWxk
IHBmbl90b19tZm5fZnJhbWVfbGlzdF9saXN0Cj4+Pj4+Pj4+IGN1cnJlbnRseSBjb250YWlucyB0
aGUgbWZuIG9mIHRoZSB0b3AgbGV2ZWwgcGFnZSBmcmFtZSBvZiB0aGUgMyBsZXZlbAo+Pj4+Pj4+
PiBwMm0gdHJlZSwgd2hpY2ggaXMgdXNlZCBieSB0aGUgWGVuIHRvb2xzIGR1cmluZyBzYXZpbmcg
YW5kIHJlc3RvcmluZwo+Pj4+Pj4+PiAoYW5kIGxpdmUgbWlncmF0aW9uKSBvZiBwdiBkb21haW5z
IGFuZCBmb3IgY3Jhc2ggZHVtcCBhbmFseXNpcy4gV2l0aAo+Pj4+Pj4+PiB0aHJlZSBsZXZlbHMg
b2YgdGhlIHAybSB0cmVlIGl0IGlzIHBvc3NpYmxlIHRvIHN1cHBvcnQgdXAgdG8gNTEyIEdCIG9m
Cj4+Pj4+Pj4+IFJBTSBmb3IgYSA2NCBiaXQgcHYgZG9tYWluLgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBB
IDMyIGJpdCBwdiBkb21haW4gY2FuIHN1cHBvcnQgbW9yZSwgYXMgZWFjaCBtZW1vcnkgcGFnZSBj
YW4gaG9sZCAxMDI0Cj4+Pj4+Pj4+IGluc3RlYWQgb2YgNTEyIGVudHJpZXMsIGxlYWRpbmcgdG8g
YSBsaW1pdCBvZiA0IFRCLgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBUbyBiZSBhYmxlIHRvIHN1cHBvcnQg
bW9yZSBSQU0gb24geDg2LTY0IHN3aXRjaCB0byBhIHZpcnR1YWwgbWFwcGVkCj4+Pj4+Pj4+IHAy
bSBsaXN0Lgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBUaGlzIHBhdGNoIGV4cGFuZHMgc3RydWN0IGFyY2hf
c2hhcmVkX2luZm8gd2l0aCBhIG5ldyBwMm0gbGlzdCB2aXJ0dWFsCj4+Pj4+Pj4+IGFkZHJlc3Ms
IHRoZSByb290IG9mIHRoZSBwYWdlIHRhYmxlIHJvb3QgYW5kIGEgcDJtIGdlbmVyYXRpb24gY291
bnQuCj4+Pj4+Pj4+IFRoZSBuZXcgaW5mb3JtYXRpb24gaXMgaW5kaWNhdGVkIGJ5IHRoZSBkb21h
aW4gdG8gYmUgdmFsaWQgYnkgc3RvcmluZwo+Pj4+Pj4+PiB+MFVMIGludG8gcGZuX3RvX21mbl9m
cmFtZV9saXN0X2xpc3QuIFRoZSBoeXBlcnZpc29yIGluZGljYXRlcwo+Pj4+Pj4+PiB1c2FiaWxp
dHkgb2YgdGhpcyBmZWF0dXJlIGJ5IGEgbmV3IGZsYWcgWEVORkVBVF92aXJ0dWFsX3AybS4KPj4+
Pj4+Pj4KPj4+Pj4+Pj4gUmlnaHQgbm93IFhFTkZFQVRfdmlydHVhbF9wMm0gd2lsbCBub3QgYmUg
c2V0LiBUaGlzIHdpbGwgY2hhbmdlIHdoZW4KPj4+Pj4+Pj4gdGhlIFhlbiB0b29scyBzdXBwb3J0
IHRoZSB2aXJ0dWFsIG1hcHBlZCBwMm0gbGlzdC4KPj4+Pj4+Pgo+Pj4+Pj4+IFRoaXMgc2VlbXMg
d3Jvbmc6IFhFTkZFQVRfKiBvbmx5IHJlZmxlY3QgaHlwZXJ2aXNvciBjYXBhYmlsaXRpZXMuCj4+
Pj4+Pj4gSS5lLiB0aGUgYXZhaWxhYmlsaXR5IG9mIHRoZSBuZXcgZnVuY3Rpb25hbGl0eSBtYXkg
bmVlZCB0byBiZQo+Pj4+Pj4+IGFkdmVydGlzZWQgYW5vdGhlciB3YXkgLSB4ZW5zdG9yZSBwZXJo
YXBzPwo+Pj4+Pj4KPj4+Pj4+IFhlbnN0b3JlIGRvZXNuJ3Qgd29yayBmb3IgZG9tMC4KPj4+Pj4+
Cj4+Pj4+PiBTaG91bGRuJ3QgdGhpcyBiZSBzb21ldGhpbmcgdGhlIGd1ZXN0IGtlcm5lbCByZXBv
cnRzIHVzaW5nIGEgRUxGIG5vdGUgYml0Pwo+Pj4+Pj4KPj4+Pj4+IFdoZW4gYnVpbGRpbmcgYSBk
b21haW4gKGVpdGhlciBpbiBYZW4gZm9yIGRvbTAgb3IgaW4gdGhlIHRvb2xzKSwgdGhlCj4+Pj4+
PiBidWlsZGVyIG1heSBwcm92aWRlIGEgbGluZWFyIHAybSBpZmYgc3VwcG9ydGVkIGJ5IHRoZSBn
dWVzdCBrZXJuZWwgYW5kCj4+Pj4+PiB0aGVuIChhbmQgb25seSB0aGVuKSBjYW4gaXQgcHJvdmlk
ZSBhIGd1ZXN0IHdpdGggPiA1MTIgR2lCLgo+Pj4+Pgo+Pj4+PiBZZXMsIHN1cmVseSB0aGlzIGZs
YWcgY291bGQgYWN0IGFzIGEga2VybmVsIGNhcGFiaWxpdHkgaW5kaWNhdG9yICh2aWEKPj4+Pj4g
dGhlIFhFTl9FTEZOT1RFX1NVUFBPUlRFRF9GRUFUVVJFUyBub3RlKSwgbGlrZSBlLmcuCj4+Pj4+
IFhFTkZFQVRfZG9tMCBhbHJlYWR5IGRvZXMuIErDvHJnZW4ncyBmaW5hbCBzdGF0ZW1lbnQsIGhv
d2V2ZXIsCj4+Pj4+IHN1Z2dlc3RlZCB0byBtZSB0aGF0IHRoaXMgaXMgbWVhbnQgdG8gYmUgb25s
eSBjb25zdW1lZCBieSBrZXJuZWxzLgo+Pj4+Cj4+Pj4gWWVzLiBUaGUgcDJtIGxpc3QgYnVpbHQg
YnkgdGhlIGRvbWFpbiBidWlsZGVyIGlzIGFscmVhZHkgbGluZWFyLiBJdCBtYXkKPj4+PiBqdXN0
IGJlIHRvIHNtYWxsIHRvIGhvbGQgYWxsIGVudHJpZXMgcmVxdWlyZWQgZS5nLiBmb3IgRG9tMC4K
Pj4+Pgo+Pj4+IEl0J3MgWGVuLXRvb2xzIGFuZCBrZHVtcCB3aGljaCBoYXZlIHRvIGRlYWwgd2l0
aCB0aGUgbGluZWFyIHAybSBsaXN0Lgo+Pj4+IFNvIHRoZSBndWVzdCBrZXJuZWwgaGFzIHRvIGJl
IHRvbGQgaWYgaXQgaXMgYWxsb3dlZCB0byBwcmVzZW50IHRoZQo+Pj4+IGxpbmVhciBsaXN0IGlu
c3RlYWQgb2YgdGhlIDMtbGV2ZWwgdHJlZSBhdCBwZm5fdG9fbWZuX2ZyYW1lX2xpc3RfbGlzdC4K
Pj4+Pgo+Pj4+IEFzIHRoaXMgaXMgdHJ1ZSBmb3IgRG9tMCBhcyB3ZWxsLCB0aGlzIGluZm9ybWF0
aW9uIG11c3QgYmUgZ2l2ZW4gYnkgdGhlCj4+Pj4gaHlwZXJ2aXNvci4KPj4+Pgo+Pj4+IEknbSBh
d2FyZSB0aGF0IFhFTkZFQVRfKiBpcyBvbmx5IHVzZWQgZm9yIGh5cGVydmlzb3IgY2FwYWJpbGl0
aWVzIHVwIHRvCj4+Pj4gbm93LiBBcyB0aGUgWGVuIHRvb2xzIGFyZSB0aWdodGx5IGNvdXBsZWQg
dG8gdGhlIGh5cGVydmlzb3IgSSBkb24ndCBzZWUKPj4+PiB3aHkgdGhlIGZlYXR1cmVzIGNhbid0
IGV4cHJlc3MgdGhlIGNhcGFiaWxpdHkgb2YgdGhlIGNvbXBsZXRlIFhlbgo+Pj4+IGluc3RhbGxh
dGlvbiBpbnN0ZWFkLiBXb3VsZCB5b3UgcHJlZmVyIGludHJvZHVjaW5nIGFub3RoZXIgbGVhZiBm
b3IKPj4+PiB0aGF0IHB1cnBvc2UgKHN1Ym1hcC5pZHggPT0gMSkgPwo+Pj4KPj4+IFRoYXQgd291
bGRuJ3QgY2hhbmdlIHRoZSBvZGQgc2l0dWF0aW9uIG9mIHJlcG9ydGluZyBhIGNhcGFiaWxpdHkg
b2YKPj4+IGFub3RoZXIgY29tcG9uZW50LiBUaGF0J3MgZXZlbiBtb3JlIG9mIGEgcHJvYmxlbSBm
b3IgdGhlIERvbTAKPj4+IGNhc2UsIHdoZXJlIHRoZSBhZmZlY3RlZCB0b29sIChrZHVtcCkgaXNu
J3QgZXZlbiB1bmRlciBvdXIgY29udHJvbAo+Pj4gKGFuZCBzaG91bGRuJ3QgYmUpLgo+Pj4KPj4+
IEJ1dCBpbiB0aGUgZW5kIC0gd2hhdCdzIHdyb25nIHdpdGggYWx3YXlzIChvciBjb25kaXRpb25h
bGx5IHVwb24gYQo+Pj4gQ09ORklHXyogb3B0aW9uIGFuZC9vciBjb21tYW5kIGxpbmUgcGFyYW1l
dGVyIGFuZC9vciBtZW1vcnkKPj4+IHNpemUpIGZpbGxpbmcgYm90aCB0aGUgb2xkIGFuZCBuZXcg
c2hhcmVkIGluZm8gZmllbGRzPyBBIGNhcGFibGUgdG9vbAo+Pj4gY2FuIGRldGVybWluZSB3aGV0
aGVyIHRoZSBuZXcgb25lIGlzIHZhbGlkLCBhbmQgYW4gaW5jYXBhYmxlIHRvb2wKPj4+IHdvbid0
IHdvcmsgb24gaHVnZSBtZW1vcnkgY29uZmlncyBhbnl3YXkuCj4+Cj4+IE9rYXksIGJ1dCB0aGlz
IHdvdWxkIHJlcXVpcmUgYW5vdGhlciB3YXkgb2YgcmVwb3J0aW5nIHRoZSB2YWxpZGl0eSBvZgo+
PiB0aGUgbGluZWFyIHAybSBsaXN0IGFuY2hvciwgYXMgc2V0dGluZyBwZm5fdG9fbWZuX2ZyYW1l
X2xpc3RfbGlzdCB0bwo+PiBhbiBpbnZhbGlkIHZhbHVlIGlzIG5vIGxvbmdlciBhbiBvcHRpb24g
dGhlbi4KPj4KPj4gQXMgdGhlIHNoYXJlZCBpbmZvIHBhZ2UgaXMgYWx3YXlzIHplcm9lZCB3aGVu
IHRoZSBkb21haW4gaXMgYnVpbHQgd2UKPj4gY291bGQgdXNlIGEgdmFsdWUgZGlmZmVyZW50IGZy
b20gMCBvZiBlLmcuIHRoZSBwMm1fZ2VuZXJhdGlvbiBtZW1iZXIKPj4gYXMgYW4gaW5kaWNhdG9y
IGZvciB0aGUgdmFsaWRpdHkuCj4KPiBXb3VsZG4ndCBib3RoIG9mIHRoZSBvdGhlciBuZXcgZmll
bGRzIGJlIGd1YXJhbnRlZWQgbm9uLXplcm8KPiB3aGVuIHVzZWQ/CgpwMm1fY3IzIHllcywgSSBz
dXBwb3NlIChtZm4gMCBpcyBuZXZlciBwYXJ0IG9mIGEgZ3Vlc3QpLiBJJ20gbm90IHN1cmUKYWJv
dXQgcDJtX3ZhZGRyLiBBIHBhcmF2aXJ0dWFsaXplZCBPUyBjb3VsZCBjaG9vc2UgdG8gcHV0IHRo
ZSBwMm0gbGlzdAphdCB2aXJ0dWFsIGFkZHJlc3MgMC4KCkp1ZXJnZW4KCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 01 16:39:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 16:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvU0A-0005Qb-Tu; Mon, 01 Dec 2014 16:39:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1XvU09-0005QW-SG
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 16:39:06 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	C2/59-05632-9A99C745; Mon, 01 Dec 2014 16:39:05 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417451944!15057217!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 10371 invoked from network); 1 Dec 2014 16:39:04 -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; 1 Dec 2014 16:39:04 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 5D030ACEC;
	Mon,  1 Dec 2014 16:39:03 +0000 (UTC)
Message-ID: <547C99A6.7040607@suse.com>
Date: Mon, 01 Dec 2014 17:39:02 +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: Jan Beulich <JBeulich@suse.com>
References: <1417426153-12893-1-git-send-email-jgross@suse.com>	<1417426153-12893-2-git-send-email-jgross@suse.com>	<547C4DD6020000780004BA83@mail.emea.novell.com>	<547C4ECB.7070702@citrix.com>
	<547C5F31020000780004BB1F@suse.com>	<547C68FD.60000@suse.com>
	<547C7D13020000780004BC3D@suse.com>	<547C7C22.4020601@suse.com>
	<547CA522020000780004BDEE@mail.emea.novell.com>
In-Reply-To: <547CA522020000780004BDEE@mail.emea.novell.com>
Content-Length: 6237
Cc: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [Patch V2] 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: 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

T24gMTIvMDEvMjAxNCAwNToyOCBQTSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4gT24gMDEuMTIu
MTQgYXQgMTU6MzMsIDxKR3Jvc3NAc3VzZS5jb20+IHdyb3RlOgo+PiBPbiAxMi8wMS8yMDE0IDAy
OjM3IFBNLCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+IE9uIDAxLjEyLjE0IGF0IDE0OjExLCA8
Skdyb3NzQHN1c2UuY29tPiB3cm90ZToKPj4+PiBPbiAxMi8wMS8yMDE0IDEyOjI5IFBNLCBKYW4g
QmV1bGljaCB3cm90ZToKPj4+Pj4+Pj4gT24gMDEuMTIuMTQgYXQgMTI6MTksIDxkYXZpZC52cmFi
ZWxAY2l0cml4LmNvbT4gd3JvdGU6Cj4+Pj4+PiBPbiAwMS8xMi8xNCAxMDoxNSwgSmFuIEJldWxp
Y2ggd3JvdGU6Cj4+Pj4+Pj4+Pj4gT24gMDEuMTIuMTQgYXQgMTA6MjksIDxKR3Jvc3NAc3VzZS5j
b20+IHdyb3RlOgo+Pj4+Pj4+PiBUaGUgeDg2IHN0cnVjdCBhcmNoX3NoYXJlZF9pbmZvIGZpZWxk
IHBmbl90b19tZm5fZnJhbWVfbGlzdF9saXN0Cj4+Pj4+Pj4+IGN1cnJlbnRseSBjb250YWlucyB0
aGUgbWZuIG9mIHRoZSB0b3AgbGV2ZWwgcGFnZSBmcmFtZSBvZiB0aGUgMyBsZXZlbAo+Pj4+Pj4+
PiBwMm0gdHJlZSwgd2hpY2ggaXMgdXNlZCBieSB0aGUgWGVuIHRvb2xzIGR1cmluZyBzYXZpbmcg
YW5kIHJlc3RvcmluZwo+Pj4+Pj4+PiAoYW5kIGxpdmUgbWlncmF0aW9uKSBvZiBwdiBkb21haW5z
IGFuZCBmb3IgY3Jhc2ggZHVtcCBhbmFseXNpcy4gV2l0aAo+Pj4+Pj4+PiB0aHJlZSBsZXZlbHMg
b2YgdGhlIHAybSB0cmVlIGl0IGlzIHBvc3NpYmxlIHRvIHN1cHBvcnQgdXAgdG8gNTEyIEdCIG9m
Cj4+Pj4+Pj4+IFJBTSBmb3IgYSA2NCBiaXQgcHYgZG9tYWluLgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBB
IDMyIGJpdCBwdiBkb21haW4gY2FuIHN1cHBvcnQgbW9yZSwgYXMgZWFjaCBtZW1vcnkgcGFnZSBj
YW4gaG9sZCAxMDI0Cj4+Pj4+Pj4+IGluc3RlYWQgb2YgNTEyIGVudHJpZXMsIGxlYWRpbmcgdG8g
YSBsaW1pdCBvZiA0IFRCLgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBUbyBiZSBhYmxlIHRvIHN1cHBvcnQg
bW9yZSBSQU0gb24geDg2LTY0IHN3aXRjaCB0byBhIHZpcnR1YWwgbWFwcGVkCj4+Pj4+Pj4+IHAy
bSBsaXN0Lgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBUaGlzIHBhdGNoIGV4cGFuZHMgc3RydWN0IGFyY2hf
c2hhcmVkX2luZm8gd2l0aCBhIG5ldyBwMm0gbGlzdCB2aXJ0dWFsCj4+Pj4+Pj4+IGFkZHJlc3Ms
IHRoZSByb290IG9mIHRoZSBwYWdlIHRhYmxlIHJvb3QgYW5kIGEgcDJtIGdlbmVyYXRpb24gY291
bnQuCj4+Pj4+Pj4+IFRoZSBuZXcgaW5mb3JtYXRpb24gaXMgaW5kaWNhdGVkIGJ5IHRoZSBkb21h
aW4gdG8gYmUgdmFsaWQgYnkgc3RvcmluZwo+Pj4+Pj4+PiB+MFVMIGludG8gcGZuX3RvX21mbl9m
cmFtZV9saXN0X2xpc3QuIFRoZSBoeXBlcnZpc29yIGluZGljYXRlcwo+Pj4+Pj4+PiB1c2FiaWxp
dHkgb2YgdGhpcyBmZWF0dXJlIGJ5IGEgbmV3IGZsYWcgWEVORkVBVF92aXJ0dWFsX3AybS4KPj4+
Pj4+Pj4KPj4+Pj4+Pj4gUmlnaHQgbm93IFhFTkZFQVRfdmlydHVhbF9wMm0gd2lsbCBub3QgYmUg
c2V0LiBUaGlzIHdpbGwgY2hhbmdlIHdoZW4KPj4+Pj4+Pj4gdGhlIFhlbiB0b29scyBzdXBwb3J0
IHRoZSB2aXJ0dWFsIG1hcHBlZCBwMm0gbGlzdC4KPj4+Pj4+Pgo+Pj4+Pj4+IFRoaXMgc2VlbXMg
d3Jvbmc6IFhFTkZFQVRfKiBvbmx5IHJlZmxlY3QgaHlwZXJ2aXNvciBjYXBhYmlsaXRpZXMuCj4+
Pj4+Pj4gSS5lLiB0aGUgYXZhaWxhYmlsaXR5IG9mIHRoZSBuZXcgZnVuY3Rpb25hbGl0eSBtYXkg
bmVlZCB0byBiZQo+Pj4+Pj4+IGFkdmVydGlzZWQgYW5vdGhlciB3YXkgLSB4ZW5zdG9yZSBwZXJo
YXBzPwo+Pj4+Pj4KPj4+Pj4+IFhlbnN0b3JlIGRvZXNuJ3Qgd29yayBmb3IgZG9tMC4KPj4+Pj4+
Cj4+Pj4+PiBTaG91bGRuJ3QgdGhpcyBiZSBzb21ldGhpbmcgdGhlIGd1ZXN0IGtlcm5lbCByZXBv
cnRzIHVzaW5nIGEgRUxGIG5vdGUgYml0Pwo+Pj4+Pj4KPj4+Pj4+IFdoZW4gYnVpbGRpbmcgYSBk
b21haW4gKGVpdGhlciBpbiBYZW4gZm9yIGRvbTAgb3IgaW4gdGhlIHRvb2xzKSwgdGhlCj4+Pj4+
PiBidWlsZGVyIG1heSBwcm92aWRlIGEgbGluZWFyIHAybSBpZmYgc3VwcG9ydGVkIGJ5IHRoZSBn
dWVzdCBrZXJuZWwgYW5kCj4+Pj4+PiB0aGVuIChhbmQgb25seSB0aGVuKSBjYW4gaXQgcHJvdmlk
ZSBhIGd1ZXN0IHdpdGggPiA1MTIgR2lCLgo+Pj4+Pgo+Pj4+PiBZZXMsIHN1cmVseSB0aGlzIGZs
YWcgY291bGQgYWN0IGFzIGEga2VybmVsIGNhcGFiaWxpdHkgaW5kaWNhdG9yICh2aWEKPj4+Pj4g
dGhlIFhFTl9FTEZOT1RFX1NVUFBPUlRFRF9GRUFUVVJFUyBub3RlKSwgbGlrZSBlLmcuCj4+Pj4+
IFhFTkZFQVRfZG9tMCBhbHJlYWR5IGRvZXMuIErDvHJnZW4ncyBmaW5hbCBzdGF0ZW1lbnQsIGhv
d2V2ZXIsCj4+Pj4+IHN1Z2dlc3RlZCB0byBtZSB0aGF0IHRoaXMgaXMgbWVhbnQgdG8gYmUgb25s
eSBjb25zdW1lZCBieSBrZXJuZWxzLgo+Pj4+Cj4+Pj4gWWVzLiBUaGUgcDJtIGxpc3QgYnVpbHQg
YnkgdGhlIGRvbWFpbiBidWlsZGVyIGlzIGFscmVhZHkgbGluZWFyLiBJdCBtYXkKPj4+PiBqdXN0
IGJlIHRvIHNtYWxsIHRvIGhvbGQgYWxsIGVudHJpZXMgcmVxdWlyZWQgZS5nLiBmb3IgRG9tMC4K
Pj4+Pgo+Pj4+IEl0J3MgWGVuLXRvb2xzIGFuZCBrZHVtcCB3aGljaCBoYXZlIHRvIGRlYWwgd2l0
aCB0aGUgbGluZWFyIHAybSBsaXN0Lgo+Pj4+IFNvIHRoZSBndWVzdCBrZXJuZWwgaGFzIHRvIGJl
IHRvbGQgaWYgaXQgaXMgYWxsb3dlZCB0byBwcmVzZW50IHRoZQo+Pj4+IGxpbmVhciBsaXN0IGlu
c3RlYWQgb2YgdGhlIDMtbGV2ZWwgdHJlZSBhdCBwZm5fdG9fbWZuX2ZyYW1lX2xpc3RfbGlzdC4K
Pj4+Pgo+Pj4+IEFzIHRoaXMgaXMgdHJ1ZSBmb3IgRG9tMCBhcyB3ZWxsLCB0aGlzIGluZm9ybWF0
aW9uIG11c3QgYmUgZ2l2ZW4gYnkgdGhlCj4+Pj4gaHlwZXJ2aXNvci4KPj4+Pgo+Pj4+IEknbSBh
d2FyZSB0aGF0IFhFTkZFQVRfKiBpcyBvbmx5IHVzZWQgZm9yIGh5cGVydmlzb3IgY2FwYWJpbGl0
aWVzIHVwIHRvCj4+Pj4gbm93LiBBcyB0aGUgWGVuIHRvb2xzIGFyZSB0aWdodGx5IGNvdXBsZWQg
dG8gdGhlIGh5cGVydmlzb3IgSSBkb24ndCBzZWUKPj4+PiB3aHkgdGhlIGZlYXR1cmVzIGNhbid0
IGV4cHJlc3MgdGhlIGNhcGFiaWxpdHkgb2YgdGhlIGNvbXBsZXRlIFhlbgo+Pj4+IGluc3RhbGxh
dGlvbiBpbnN0ZWFkLiBXb3VsZCB5b3UgcHJlZmVyIGludHJvZHVjaW5nIGFub3RoZXIgbGVhZiBm
b3IKPj4+PiB0aGF0IHB1cnBvc2UgKHN1Ym1hcC5pZHggPT0gMSkgPwo+Pj4KPj4+IFRoYXQgd291
bGRuJ3QgY2hhbmdlIHRoZSBvZGQgc2l0dWF0aW9uIG9mIHJlcG9ydGluZyBhIGNhcGFiaWxpdHkg
b2YKPj4+IGFub3RoZXIgY29tcG9uZW50LiBUaGF0J3MgZXZlbiBtb3JlIG9mIGEgcHJvYmxlbSBm
b3IgdGhlIERvbTAKPj4+IGNhc2UsIHdoZXJlIHRoZSBhZmZlY3RlZCB0b29sIChrZHVtcCkgaXNu
J3QgZXZlbiB1bmRlciBvdXIgY29udHJvbAo+Pj4gKGFuZCBzaG91bGRuJ3QgYmUpLgo+Pj4KPj4+
IEJ1dCBpbiB0aGUgZW5kIC0gd2hhdCdzIHdyb25nIHdpdGggYWx3YXlzIChvciBjb25kaXRpb25h
bGx5IHVwb24gYQo+Pj4gQ09ORklHXyogb3B0aW9uIGFuZC9vciBjb21tYW5kIGxpbmUgcGFyYW1l
dGVyIGFuZC9vciBtZW1vcnkKPj4+IHNpemUpIGZpbGxpbmcgYm90aCB0aGUgb2xkIGFuZCBuZXcg
c2hhcmVkIGluZm8gZmllbGRzPyBBIGNhcGFibGUgdG9vbAo+Pj4gY2FuIGRldGVybWluZSB3aGV0
aGVyIHRoZSBuZXcgb25lIGlzIHZhbGlkLCBhbmQgYW4gaW5jYXBhYmxlIHRvb2wKPj4+IHdvbid0
IHdvcmsgb24gaHVnZSBtZW1vcnkgY29uZmlncyBhbnl3YXkuCj4+Cj4+IE9rYXksIGJ1dCB0aGlz
IHdvdWxkIHJlcXVpcmUgYW5vdGhlciB3YXkgb2YgcmVwb3J0aW5nIHRoZSB2YWxpZGl0eSBvZgo+
PiB0aGUgbGluZWFyIHAybSBsaXN0IGFuY2hvciwgYXMgc2V0dGluZyBwZm5fdG9fbWZuX2ZyYW1l
X2xpc3RfbGlzdCB0bwo+PiBhbiBpbnZhbGlkIHZhbHVlIGlzIG5vIGxvbmdlciBhbiBvcHRpb24g
dGhlbi4KPj4KPj4gQXMgdGhlIHNoYXJlZCBpbmZvIHBhZ2UgaXMgYWx3YXlzIHplcm9lZCB3aGVu
IHRoZSBkb21haW4gaXMgYnVpbHQgd2UKPj4gY291bGQgdXNlIGEgdmFsdWUgZGlmZmVyZW50IGZy
b20gMCBvZiBlLmcuIHRoZSBwMm1fZ2VuZXJhdGlvbiBtZW1iZXIKPj4gYXMgYW4gaW5kaWNhdG9y
IGZvciB0aGUgdmFsaWRpdHkuCj4KPiBXb3VsZG4ndCBib3RoIG9mIHRoZSBvdGhlciBuZXcgZmll
bGRzIGJlIGd1YXJhbnRlZWQgbm9uLXplcm8KPiB3aGVuIHVzZWQ/CgpwMm1fY3IzIHllcywgSSBz
dXBwb3NlIChtZm4gMCBpcyBuZXZlciBwYXJ0IG9mIGEgZ3Vlc3QpLiBJJ20gbm90IHN1cmUKYWJv
dXQgcDJtX3ZhZGRyLiBBIHBhcmF2aXJ0dWFsaXplZCBPUyBjb3VsZCBjaG9vc2UgdG8gcHV0IHRo
ZSBwMm0gbGlzdAphdCB2aXJ0dWFsIGFkZHJlc3MgMC4KCkp1ZXJnZW4KCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 01 16:59:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 16: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 1XvUJ8-0006OI-Nb; Mon, 01 Dec 2014 16:58: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 1XvUJ7-0006OD-GM
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 16:58:41 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	0C/FA-17735-04E9C745; Mon, 01 Dec 2014 16:58:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417453117!15062240!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19230 invoked from network); 1 Dec 2014 16:58:40 -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 Dec 2014 16:58:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198147918"
Message-ID: <547C9E38.10505@citrix.com>
Date: Mon, 1 Dec 2014 16:58: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: David Vrabel <david.vrabel@citrix.com>, Xen-devel List
	<xen-devel@lists.xen.org>
References: <546E32BB.8090909@citrix.com> <547C7D5F.3090009@citrix.com>
In-Reply-To: <547C7D5F.3090009@citrix.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>, 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 01/12/14 14:38, David Vrabel wrote:
> On 20/11/14 18:28, Andrew Cooper wrote:
>> 1) Freeze the guests p2m during live migrate
>> 2) Deep p2m dirty tracking
>> 3) Eagerly check for p2m structure changes.
>> 4) Request p2m structure change updates from the guest
>> Proposed solution:  A combination of 2, 3 and 4.
> Option 5: don't change anything.  PV guests and toolstacks are
> well-behaved and ensure that p2m updates do not occur during domain save.

We are currently relying on this is true, knowing full well that it
isn't in practice.  Guest balloon drivers will happily balloon if told
to do so by the toolstack at the same point that the domain is going
down for migrate.

Even at the moment, if the toolstack observes the intermediate actions
of a grant being unmapped, the migration will either be aborted, or VM
corruption will occur on the far side.

>
> We have never supported migrating non-cooperative PV guests.

We will never be in the position to migrate a non-cooperative PV domain,
as the final action it needs to do is stuff an MFN in %rdx, to be
replaced on the far side.

>
> I'd be more interested fixing this for HVM guests.

Agreed, and the HVM case is easier to fix.  I am fairly certain the HVM
side can be fixed with a few extra paging_mark_dirty() for p2m updates
in Xen alone. The PV case is however a timebomb waiting to happen.

~Andrew


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 16:59:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 16: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 1XvUJ8-0006OI-Nb; Mon, 01 Dec 2014 16:58: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 1XvUJ7-0006OD-GM
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 16:58:41 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	0C/FA-17735-04E9C745; Mon, 01 Dec 2014 16:58:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417453117!15062240!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19230 invoked from network); 1 Dec 2014 16:58:40 -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 Dec 2014 16:58:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208";a="198147918"
Message-ID: <547C9E38.10505@citrix.com>
Date: Mon, 1 Dec 2014 16:58: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: David Vrabel <david.vrabel@citrix.com>, Xen-devel List
	<xen-devel@lists.xen.org>
References: <546E32BB.8090909@citrix.com> <547C7D5F.3090009@citrix.com>
In-Reply-To: <547C7D5F.3090009@citrix.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>, 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 01/12/14 14:38, David Vrabel wrote:
> On 20/11/14 18:28, Andrew Cooper wrote:
>> 1) Freeze the guests p2m during live migrate
>> 2) Deep p2m dirty tracking
>> 3) Eagerly check for p2m structure changes.
>> 4) Request p2m structure change updates from the guest
>> Proposed solution:  A combination of 2, 3 and 4.
> Option 5: don't change anything.  PV guests and toolstacks are
> well-behaved and ensure that p2m updates do not occur during domain save.

We are currently relying on this is true, knowing full well that it
isn't in practice.  Guest balloon drivers will happily balloon if told
to do so by the toolstack at the same point that the domain is going
down for migrate.

Even at the moment, if the toolstack observes the intermediate actions
of a grant being unmapped, the migration will either be aborted, or VM
corruption will occur on the far side.

>
> We have never supported migrating non-cooperative PV guests.

We will never be in the position to migrate a non-cooperative PV domain,
as the final action it needs to do is stuff an MFN in %rdx, to be
replaced on the far side.

>
> I'd be more interested fixing this for HVM guests.

Agreed, and the HVM case is easier to fix.  I am fairly certain the HVM
side can be fixed with a few extra paging_mark_dirty() for p2m updates
in Xen alone. The PV case is however a timebomb waiting to happen.

~Andrew


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 17:08:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 17:08:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvUS4-0006nE-QW; Mon, 01 Dec 2014 17:07:56 +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 1XvUS2-0006n9-Ka
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 17:07:54 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	35/C9-07724-960AC745; Mon, 01 Dec 2014 17:07:53 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417453673!15002114!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 26425 invoked from network); 1 Dec 2014 17:07:53 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 17:07:53 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 50793AC7D;
	Mon,  1 Dec 2014 17:07:50 +0000 (UTC)
Message-ID: <547CA064.5080106@suse.com>
Date: Mon, 01 Dec 2014 18:07:48 +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@suse.com>, 
	David Vrabel <david.vrabel@citrix.com>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
In-Reply-To: <20141201161905.GH25677@wotan.suse.de>
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@suse.de>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 12/01/2014 05:19 PM, Luis R. Rodriguez wrote:
> On Mon, Dec 01, 2014 at 03:54:24PM +0000, David Vrabel wrote:
>> On 01/12/14 15:44, Luis R. Rodriguez wrote:
>>> On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>> On 01/12/14 15:05, Luis R. Rodriguez wrote:
>>>>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
>>>>>> [...]
>>>>>>>>> --- 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
>>>>>>
>>>>>> As Juergen points out, this does nothing.  You need to schedule while in
>>>>>> the middle of the hypercall.
>>>>>>
>>>>>> Remember that Xen's hypercall preemption only preempts the hypercall to
>>>>>> run interrupts in the guest.
>>>>>
>>>>> How is it ensured that when the kernel preempts on this code path on
>>>>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
>>>>
>>>> Sorry, I really didn't describe this very well.
>>>>
>>>> If a hypercall needs a continuation, Xen returns to the guest with the
>>>> IP set to the hypercall instruction, and on the way back to the guest
>>>> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
>>>>
>>>> The guest is free to return from the upcall to the original task
>>>> (continuing the hypercall) or to a different one.
>>>
>>> OK so that addresses what Xen will do when using continuation and
>>> hypercall preemption, my concern here was that using
>>> preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
>>> hypercall on the return from an interrupt (e.g., the timer interrupt)
>>> would still let the kernel preempt to tasks other than those related
>>> to Xen.
>>
>> Um.  Why would that be a problem?  We do want to switch to any task the
>> Linux scheduler thinks is best.
>
> Its safe but -- it technically is doing kernel preemption, unless we want
> to adjust the definition of CONFIG_PREEMPT=n to exclude hypercalls. This
> was my original concern with the use of preempt_schedule_irq() to do this.
> I am afraid of setting precedents without being clear or wider review and
> acceptance.

I wonder whether it would be more acceptable to add (or completely
switch to) another preemption model: PREEMPT_SWITCHABLE. This would be
similar to CONFIG_PREEMPT, but the "normal" value of __preempt_count
would be settable via kernel parameter (default 2):

0: preempt
1: preempt_voluntary
2: preempt_none

The kernel would run with preemption enabled. cond_sched() would
reschedule if __preempt_count <= 1. And in case of long running kernel
activities (like the hypercall case or other stuff requiring schedule()
calls to avoid hangups) we would just set __preempt_count to 0 during
these periods and restore the old value afterwards.

This would be a rather intrusive but clean change IMO.

Any thoughts?


Juergen

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 17:08:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 17:08:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvUS4-0006nE-QW; Mon, 01 Dec 2014 17:07:56 +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 1XvUS2-0006n9-Ka
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 17:07:54 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	35/C9-07724-960AC745; Mon, 01 Dec 2014 17:07:53 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417453673!15002114!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 26425 invoked from network); 1 Dec 2014 17:07:53 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 17:07:53 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 50793AC7D;
	Mon,  1 Dec 2014 17:07:50 +0000 (UTC)
Message-ID: <547CA064.5080106@suse.com>
Date: Mon, 01 Dec 2014 18:07:48 +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@suse.com>, 
	David Vrabel <david.vrabel@citrix.com>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
In-Reply-To: <20141201161905.GH25677@wotan.suse.de>
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@suse.de>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 12/01/2014 05:19 PM, Luis R. Rodriguez wrote:
> On Mon, Dec 01, 2014 at 03:54:24PM +0000, David Vrabel wrote:
>> On 01/12/14 15:44, Luis R. Rodriguez wrote:
>>> On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>> On 01/12/14 15:05, Luis R. Rodriguez wrote:
>>>>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
>>>>>> [...]
>>>>>>>>> --- 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
>>>>>>
>>>>>> As Juergen points out, this does nothing.  You need to schedule while in
>>>>>> the middle of the hypercall.
>>>>>>
>>>>>> Remember that Xen's hypercall preemption only preempts the hypercall to
>>>>>> run interrupts in the guest.
>>>>>
>>>>> How is it ensured that when the kernel preempts on this code path on
>>>>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
>>>>
>>>> Sorry, I really didn't describe this very well.
>>>>
>>>> If a hypercall needs a continuation, Xen returns to the guest with the
>>>> IP set to the hypercall instruction, and on the way back to the guest
>>>> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
>>>>
>>>> The guest is free to return from the upcall to the original task
>>>> (continuing the hypercall) or to a different one.
>>>
>>> OK so that addresses what Xen will do when using continuation and
>>> hypercall preemption, my concern here was that using
>>> preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
>>> hypercall on the return from an interrupt (e.g., the timer interrupt)
>>> would still let the kernel preempt to tasks other than those related
>>> to Xen.
>>
>> Um.  Why would that be a problem?  We do want to switch to any task the
>> Linux scheduler thinks is best.
>
> Its safe but -- it technically is doing kernel preemption, unless we want
> to adjust the definition of CONFIG_PREEMPT=n to exclude hypercalls. This
> was my original concern with the use of preempt_schedule_irq() to do this.
> I am afraid of setting precedents without being clear or wider review and
> acceptance.

I wonder whether it would be more acceptable to add (or completely
switch to) another preemption model: PREEMPT_SWITCHABLE. This would be
similar to CONFIG_PREEMPT, but the "normal" value of __preempt_count
would be settable via kernel parameter (default 2):

0: preempt
1: preempt_voluntary
2: preempt_none

The kernel would run with preemption enabled. cond_sched() would
reschedule if __preempt_count <= 1. And in case of long running kernel
activities (like the hypercall case or other stuff requiring schedule()
calls to avoid hangups) we would just set __preempt_count to 0 during
these periods and restore the old value afterwards.

This would be a rather intrusive but clean change IMO.

Any thoughts?


Juergen

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 17:17:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 17:17:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvUae-00074i-S4; Mon, 01 Dec 2014 17:16: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 1XvUad-00074d-O7
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 17:16:47 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	C1/9F-24859-F72AC745; Mon, 01 Dec 2014 17:16:47 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417454204!14928795!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3477 invoked from network); 1 Dec 2014 17:16:46 -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;
	1 Dec 2014 17:16:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,495,1413244800"; d="scan'208";a="198155829"
Message-ID: <547CA220.9070604@citrix.com>
Date: Mon, 1 Dec 2014 17:15: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: John Haxby <john.haxby@oracle.com>, <xen-devel@lists.xen.org>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
	<1417444646-20636-2-git-send-email-john.haxby@oracle.com>
In-Reply-To: <1417444646-20636-2-git-send-email-john.haxby@oracle.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 1/2] xen-detect: fix strict-aliasing
 compilation warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDEvMTIvMTQgMTQ6MzcsIEpvaG4gSGF4Ynkgd3JvdGU6Cj4gV2l0aCBnY2MgNC44LjMsIGNv
bXBpbGluZyB4ZW4tZGV0ZWN0IGdpdmVzIGEgY29tcGlsYXRpb24gd2FybmluZyBpZgo+IHlvdSdy
ZSBvcHRpbWlzaW5nOgo+Cj4gJCBjYyAtV2FsbCAtT3MgeGVuLWRldGVjdC5jCj4geGVuLWRldGVj
dC5jOiBJbiBmdW5jdGlvbiDigJhjaGVja19mb3JfeGVu4oCZOgo+IHhlbi1kZXRlY3QuYzo2NTo5
OiB3YXJuaW5nOiBkZXJlZmVyZW5jaW5nIHR5cGUtcHVubmVkIHBvaW50ZXIgd2lsbCBicmVhawo+
IHN0cmljdC1hbGlhc2luZyBydWxlcyBbLVdzdHJpY3QtYWxpYXNpbmddCj4gICAgICAgICAgKih1
aW50MzJfdCAqKShzaWduYXR1cmUgKyAwKSA9IHJlZ3NbMV07Cj4gICAgICAgICAgXgo+Cj4gU2ln
bmVkLW9mZi1ieTogSm9obiBIYXhieSA8am9obi5oYXhieUBvcmFjbGUuY29tPgoKV2h5IGFyZSB5
b3UgY29tcGlsaW5nIHdpdGhvdXQgdGhlIENGTEFHUyBmcm9tIHRoZSBYZW4gYnVpbGQgc3lzdGVt
PwoKV2UgZXhwbGljaXRseSBkaXNhYmxlIHN0cmljdCBhbGlhcyBvcHRpbWlzYXRpb25zLCBiZWNh
dXNlIG9wdGltaXNhdGlvbnMKYmFzZWQgdXBvbiB0aGUgYWxpYXNpbmcgcnVsZXMgaW4gQyBpcyBt
YWQuICBFdmVuIHdoZW4geW91IGVsaW1pbmF0ZSBhbGwKdGhlIHdhcm5pbmdzLCB0aGVyZSBhcmUg
c3RpbGwgc3VidGxlIGJ1Z3MgYmVjYXVzZSB0aGUgY29tcGlsZXIgaXMgZnJlZQp0byBhc3N1bWUg
YSBsb3QgbW9yZSB0aGFuIGEgcHJvZ3JhbW1lciB3b3VsZCB0eXBpY2FsbHkgZGVlbSByZWFzb25h
YmxlLgoKfkFuZHJldwoKPiAtLS0KPiAgdG9vbHMvbWlzYy94ZW4tZGV0ZWN0LmMgfCAyMSArKysr
KysrKysrLS0tLS0tLS0tLS0KPiAgMSBmaWxlIGNoYW5nZWQsIDEwIGluc2VydGlvbnMoKyksIDEx
IGRlbGV0aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL3Rvb2xzL21pc2MveGVuLWRldGVjdC5jIGIv
dG9vbHMvbWlzYy94ZW4tZGV0ZWN0LmMKPiBpbmRleCA3ODdiNWRhLi4xOWM2NmQxIDEwMDY0NAo+
IC0tLSBhL3Rvb2xzL21pc2MveGVuLWRldGVjdC5jCj4gKysrIGIvdG9vbHMvbWlzYy94ZW4tZGV0
ZWN0LmMKPiBAQCAtNTQsMjggKzU0LDI3IEBAIHN0YXRpYyB2b2lkIGNwdWlkKHVpbnQzMl90IGlk
eCwgdWludDMyX3QgKnJlZ3MsIGludCBwdl9jb250ZXh0KQo+ICAKPiAgc3RhdGljIGludCBjaGVj
a19mb3JfeGVuKGludCBwdl9jb250ZXh0KQo+ICB7Cj4gLSAgICB1aW50MzJfdCByZWdzWzRdOwo+
IC0gICAgY2hhciBzaWduYXR1cmVbMTNdOwo+ICsgICAgdW5pb24KPiArICAgIHsKPiArICAgICAg
ICB1aW50MzJfdCByZWdzWzRdOwo+ICsgICAgICAgIGNoYXIgc2lnbmF0dXJlWzE3XTsKPiArICAg
IH0gdTsKPiAgICAgIHVpbnQzMl90IGJhc2U7Cj4gIAo+ICAgICAgZm9yICggYmFzZSA9IDB4NDAw
MDAwMDA7IGJhc2UgPCAweDQwMDEwMDAwOyBiYXNlICs9IDB4MTAwICkKPiAgICAgIHsKPiAtICAg
ICAgICBjcHVpZChiYXNlLCByZWdzLCBwdl9jb250ZXh0KTsKPiAtCj4gLSAgICAgICAgKih1aW50
MzJfdCAqKShzaWduYXR1cmUgKyAwKSA9IHJlZ3NbMV07Cj4gLSAgICAgICAgKih1aW50MzJfdCAq
KShzaWduYXR1cmUgKyA0KSA9IHJlZ3NbMl07Cj4gLSAgICAgICAgKih1aW50MzJfdCAqKShzaWdu
YXR1cmUgKyA4KSA9IHJlZ3NbM107Cj4gLSAgICAgICAgc2lnbmF0dXJlWzEyXSA9ICdcMCc7Cj4g
KyAgICAgICAgY3B1aWQoYmFzZSwgdS5yZWdzLCBwdl9jb250ZXh0KTsKPiArICAgICAgICB1LnNp
Z25hdHVyZVsxNl0gPSAnXDAnOwo+ICAKPiAtICAgICAgICBpZiAoICFzdHJjbXAoIlhlblZNTVhl
blZNTSIsIHNpZ25hdHVyZSkgJiYgKHJlZ3NbMF0gPj0gKGJhc2UgKyAyKSkgKQo+ICsgICAgICAg
IGlmICggIXN0cmNtcCgiWGVuVk1NWGVuVk1NIiwgdS5zaWduYXR1cmUrNCkgJiYgKHUucmVnc1sw
XSA+PSAoYmFzZSArIDIpKSApCj4gICAgICAgICAgICAgIGdvdG8gZm91bmQ7Cj4gICAgICB9Cj4g
IAo+ICAgICAgcmV0dXJuIDA7Cj4gIAo+ICAgZm91bmQ6Cj4gLSAgICBjcHVpZChiYXNlICsgMSwg
cmVncywgcHZfY29udGV4dCk7Cj4gLSAgICByZXR1cm4gcmVnc1swXTsKPiArICAgIGNwdWlkKGJh
c2UgKyAxLCB1LnJlZ3MsIHB2X2NvbnRleHQpOwo+ICsgICAgcmV0dXJuIHUucmVnc1swXTsKPiAg
fQo+ICAKPiAgc3RhdGljIGptcF9idWYgc2lnaWxsX2ptcDsKCgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 01 17:17:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 17:17:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvUae-00074i-S4; Mon, 01 Dec 2014 17:16: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 1XvUad-00074d-O7
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 17:16:47 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	C1/9F-24859-F72AC745; Mon, 01 Dec 2014 17:16:47 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417454204!14928795!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3477 invoked from network); 1 Dec 2014 17:16:46 -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;
	1 Dec 2014 17:16:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,495,1413244800"; d="scan'208";a="198155829"
Message-ID: <547CA220.9070604@citrix.com>
Date: Mon, 1 Dec 2014 17:15: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: John Haxby <john.haxby@oracle.com>, <xen-devel@lists.xen.org>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
	<1417444646-20636-2-git-send-email-john.haxby@oracle.com>
In-Reply-To: <1417444646-20636-2-git-send-email-john.haxby@oracle.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 1/2] xen-detect: fix strict-aliasing
 compilation warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDEvMTIvMTQgMTQ6MzcsIEpvaG4gSGF4Ynkgd3JvdGU6Cj4gV2l0aCBnY2MgNC44LjMsIGNv
bXBpbGluZyB4ZW4tZGV0ZWN0IGdpdmVzIGEgY29tcGlsYXRpb24gd2FybmluZyBpZgo+IHlvdSdy
ZSBvcHRpbWlzaW5nOgo+Cj4gJCBjYyAtV2FsbCAtT3MgeGVuLWRldGVjdC5jCj4geGVuLWRldGVj
dC5jOiBJbiBmdW5jdGlvbiDigJhjaGVja19mb3JfeGVu4oCZOgo+IHhlbi1kZXRlY3QuYzo2NTo5
OiB3YXJuaW5nOiBkZXJlZmVyZW5jaW5nIHR5cGUtcHVubmVkIHBvaW50ZXIgd2lsbCBicmVhawo+
IHN0cmljdC1hbGlhc2luZyBydWxlcyBbLVdzdHJpY3QtYWxpYXNpbmddCj4gICAgICAgICAgKih1
aW50MzJfdCAqKShzaWduYXR1cmUgKyAwKSA9IHJlZ3NbMV07Cj4gICAgICAgICAgXgo+Cj4gU2ln
bmVkLW9mZi1ieTogSm9obiBIYXhieSA8am9obi5oYXhieUBvcmFjbGUuY29tPgoKV2h5IGFyZSB5
b3UgY29tcGlsaW5nIHdpdGhvdXQgdGhlIENGTEFHUyBmcm9tIHRoZSBYZW4gYnVpbGQgc3lzdGVt
PwoKV2UgZXhwbGljaXRseSBkaXNhYmxlIHN0cmljdCBhbGlhcyBvcHRpbWlzYXRpb25zLCBiZWNh
dXNlIG9wdGltaXNhdGlvbnMKYmFzZWQgdXBvbiB0aGUgYWxpYXNpbmcgcnVsZXMgaW4gQyBpcyBt
YWQuICBFdmVuIHdoZW4geW91IGVsaW1pbmF0ZSBhbGwKdGhlIHdhcm5pbmdzLCB0aGVyZSBhcmUg
c3RpbGwgc3VidGxlIGJ1Z3MgYmVjYXVzZSB0aGUgY29tcGlsZXIgaXMgZnJlZQp0byBhc3N1bWUg
YSBsb3QgbW9yZSB0aGFuIGEgcHJvZ3JhbW1lciB3b3VsZCB0eXBpY2FsbHkgZGVlbSByZWFzb25h
YmxlLgoKfkFuZHJldwoKPiAtLS0KPiAgdG9vbHMvbWlzYy94ZW4tZGV0ZWN0LmMgfCAyMSArKysr
KysrKysrLS0tLS0tLS0tLS0KPiAgMSBmaWxlIGNoYW5nZWQsIDEwIGluc2VydGlvbnMoKyksIDEx
IGRlbGV0aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL3Rvb2xzL21pc2MveGVuLWRldGVjdC5jIGIv
dG9vbHMvbWlzYy94ZW4tZGV0ZWN0LmMKPiBpbmRleCA3ODdiNWRhLi4xOWM2NmQxIDEwMDY0NAo+
IC0tLSBhL3Rvb2xzL21pc2MveGVuLWRldGVjdC5jCj4gKysrIGIvdG9vbHMvbWlzYy94ZW4tZGV0
ZWN0LmMKPiBAQCAtNTQsMjggKzU0LDI3IEBAIHN0YXRpYyB2b2lkIGNwdWlkKHVpbnQzMl90IGlk
eCwgdWludDMyX3QgKnJlZ3MsIGludCBwdl9jb250ZXh0KQo+ICAKPiAgc3RhdGljIGludCBjaGVj
a19mb3JfeGVuKGludCBwdl9jb250ZXh0KQo+ICB7Cj4gLSAgICB1aW50MzJfdCByZWdzWzRdOwo+
IC0gICAgY2hhciBzaWduYXR1cmVbMTNdOwo+ICsgICAgdW5pb24KPiArICAgIHsKPiArICAgICAg
ICB1aW50MzJfdCByZWdzWzRdOwo+ICsgICAgICAgIGNoYXIgc2lnbmF0dXJlWzE3XTsKPiArICAg
IH0gdTsKPiAgICAgIHVpbnQzMl90IGJhc2U7Cj4gIAo+ICAgICAgZm9yICggYmFzZSA9IDB4NDAw
MDAwMDA7IGJhc2UgPCAweDQwMDEwMDAwOyBiYXNlICs9IDB4MTAwICkKPiAgICAgIHsKPiAtICAg
ICAgICBjcHVpZChiYXNlLCByZWdzLCBwdl9jb250ZXh0KTsKPiAtCj4gLSAgICAgICAgKih1aW50
MzJfdCAqKShzaWduYXR1cmUgKyAwKSA9IHJlZ3NbMV07Cj4gLSAgICAgICAgKih1aW50MzJfdCAq
KShzaWduYXR1cmUgKyA0KSA9IHJlZ3NbMl07Cj4gLSAgICAgICAgKih1aW50MzJfdCAqKShzaWdu
YXR1cmUgKyA4KSA9IHJlZ3NbM107Cj4gLSAgICAgICAgc2lnbmF0dXJlWzEyXSA9ICdcMCc7Cj4g
KyAgICAgICAgY3B1aWQoYmFzZSwgdS5yZWdzLCBwdl9jb250ZXh0KTsKPiArICAgICAgICB1LnNp
Z25hdHVyZVsxNl0gPSAnXDAnOwo+ICAKPiAtICAgICAgICBpZiAoICFzdHJjbXAoIlhlblZNTVhl
blZNTSIsIHNpZ25hdHVyZSkgJiYgKHJlZ3NbMF0gPj0gKGJhc2UgKyAyKSkgKQo+ICsgICAgICAg
IGlmICggIXN0cmNtcCgiWGVuVk1NWGVuVk1NIiwgdS5zaWduYXR1cmUrNCkgJiYgKHUucmVnc1sw
XSA+PSAoYmFzZSArIDIpKSApCj4gICAgICAgICAgICAgIGdvdG8gZm91bmQ7Cj4gICAgICB9Cj4g
IAo+ICAgICAgcmV0dXJuIDA7Cj4gIAo+ICAgZm91bmQ6Cj4gLSAgICBjcHVpZChiYXNlICsgMSwg
cmVncywgcHZfY29udGV4dCk7Cj4gLSAgICByZXR1cm4gcmVnc1swXTsKPiArICAgIGNwdWlkKGJh
c2UgKyAxLCB1LnJlZ3MsIHB2X2NvbnRleHQpOwo+ICsgICAgcmV0dXJuIHUucmVnc1swXTsKPiAg
fQo+ICAKPiAgc3RhdGljIGptcF9idWYgc2lnaWxsX2ptcDsKCgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 01 17:53:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 17:53:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvV9C-0007lE-41; Mon, 01 Dec 2014 17:52:30 +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 1XvV9A-0007l9-Am
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 17:52:28 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	41/01-17735-BDAAC745; Mon, 01 Dec 2014 17:52:27 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417456346!15125902!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 3171 invoked from network); 1 Dec 2014 17:52:26 -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; 1 Dec 2014 17:52:26 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 510FAAB09;
	Mon,  1 Dec 2014 17:52:25 +0000 (UTC)
Date: Mon, 1 Dec 2014 18:52:24 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141201175224.GJ25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de> <547CA064.5080106@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547CA064.5080106@suse.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@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>, Ingo Molnar <mingo@kernel.org>
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 Mon, Dec 01, 2014 at 06:07:48PM +0100, Juergen Gross wrote:
> On 12/01/2014 05:19 PM, Luis R. Rodriguez wrote:
>> On Mon, Dec 01, 2014 at 03:54:24PM +0000, David Vrabel wrote:
>>> On 01/12/14 15:44, Luis R. Rodriguez wrote:
>>>> On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>> On 01/12/14 15:05, Luis R. Rodriguez wrote:
>>>>>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
>>>>>>> [...]
>>>>>>>>>> --- 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
>>>>>>>
>>>>>>> As Juergen points out, this does nothing.  You need to schedule while in
>>>>>>> the middle of the hypercall.
>>>>>>>
>>>>>>> Remember that Xen's hypercall preemption only preempts the hypercall to
>>>>>>> run interrupts in the guest.
>>>>>>
>>>>>> How is it ensured that when the kernel preempts on this code path on
>>>>>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
>>>>>
>>>>> Sorry, I really didn't describe this very well.
>>>>>
>>>>> If a hypercall needs a continuation, Xen returns to the guest with the
>>>>> IP set to the hypercall instruction, and on the way back to the guest
>>>>> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
>>>>>
>>>>> The guest is free to return from the upcall to the original task
>>>>> (continuing the hypercall) or to a different one.
>>>>
>>>> OK so that addresses what Xen will do when using continuation and
>>>> hypercall preemption, my concern here was that using
>>>> preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
>>>> hypercall on the return from an interrupt (e.g., the timer interrupt)
>>>> would still let the kernel preempt to tasks other than those related
>>>> to Xen.
>>>
>>> Um.  Why would that be a problem?  We do want to switch to any task the
>>> Linux scheduler thinks is best.
>>
>> Its safe but -- it technically is doing kernel preemption, unless we want
>> to adjust the definition of CONFIG_PREEMPT=n to exclude hypercalls. This
>> was my original concern with the use of preempt_schedule_irq() to do this.
>> I am afraid of setting precedents without being clear or wider review and
>> acceptance.
>
> I wonder whether it would be more acceptable to add (or completely
> switch to) another preemption model: PREEMPT_SWITCHABLE. This would be
> similar to CONFIG_PREEMPT, but the "normal" value of __preempt_count
> would be settable via kernel parameter (default 2):
>
> 0: preempt
> 1: preempt_voluntary
> 2: preempt_none
>
> The kernel would run with preemption enabled. cond_sched() would
> reschedule if __preempt_count <= 1. And in case of long running kernel
> activities (like the hypercall case or other stuff requiring schedule()
> calls to avoid hangups) we would just set __preempt_count to 0 during
> these periods and restore the old value afterwards.
>
> This would be a rather intrusive but clean change IMO.
>
> Any thoughts?

I like the idea of dynamically changing at run time the preemption model and
personally find this reasonable, however I am not certain if this would
introduce a series of issues hard to address. Thoughts by others who linger
deep in the cold lonely scheduler caves ?

  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 17:53:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 17:53:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvV9C-0007lE-41; Mon, 01 Dec 2014 17:52:30 +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 1XvV9A-0007l9-Am
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 17:52:28 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	41/01-17735-BDAAC745; Mon, 01 Dec 2014 17:52:27 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417456346!15125902!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 3171 invoked from network); 1 Dec 2014 17:52:26 -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; 1 Dec 2014 17:52:26 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 510FAAB09;
	Mon,  1 Dec 2014 17:52:25 +0000 (UTC)
Date: Mon, 1 Dec 2014 18:52:24 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141201175224.GJ25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de> <547CA064.5080106@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547CA064.5080106@suse.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dbueso@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>, Ingo Molnar <mingo@kernel.org>
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 Mon, Dec 01, 2014 at 06:07:48PM +0100, Juergen Gross wrote:
> On 12/01/2014 05:19 PM, Luis R. Rodriguez wrote:
>> On Mon, Dec 01, 2014 at 03:54:24PM +0000, David Vrabel wrote:
>>> On 01/12/14 15:44, Luis R. Rodriguez wrote:
>>>> On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>> On 01/12/14 15:05, Luis R. Rodriguez wrote:
>>>>>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
>>>>>>> [...]
>>>>>>>>>> --- 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
>>>>>>>
>>>>>>> As Juergen points out, this does nothing.  You need to schedule while in
>>>>>>> the middle of the hypercall.
>>>>>>>
>>>>>>> Remember that Xen's hypercall preemption only preempts the hypercall to
>>>>>>> run interrupts in the guest.
>>>>>>
>>>>>> How is it ensured that when the kernel preempts on this code path on
>>>>>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
>>>>>
>>>>> Sorry, I really didn't describe this very well.
>>>>>
>>>>> If a hypercall needs a continuation, Xen returns to the guest with the
>>>>> IP set to the hypercall instruction, and on the way back to the guest
>>>>> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
>>>>>
>>>>> The guest is free to return from the upcall to the original task
>>>>> (continuing the hypercall) or to a different one.
>>>>
>>>> OK so that addresses what Xen will do when using continuation and
>>>> hypercall preemption, my concern here was that using
>>>> preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
>>>> hypercall on the return from an interrupt (e.g., the timer interrupt)
>>>> would still let the kernel preempt to tasks other than those related
>>>> to Xen.
>>>
>>> Um.  Why would that be a problem?  We do want to switch to any task the
>>> Linux scheduler thinks is best.
>>
>> Its safe but -- it technically is doing kernel preemption, unless we want
>> to adjust the definition of CONFIG_PREEMPT=n to exclude hypercalls. This
>> was my original concern with the use of preempt_schedule_irq() to do this.
>> I am afraid of setting precedents without being clear or wider review and
>> acceptance.
>
> I wonder whether it would be more acceptable to add (or completely
> switch to) another preemption model: PREEMPT_SWITCHABLE. This would be
> similar to CONFIG_PREEMPT, but the "normal" value of __preempt_count
> would be settable via kernel parameter (default 2):
>
> 0: preempt
> 1: preempt_voluntary
> 2: preempt_none
>
> The kernel would run with preemption enabled. cond_sched() would
> reschedule if __preempt_count <= 1. And in case of long running kernel
> activities (like the hypercall case or other stuff requiring schedule()
> calls to avoid hangups) we would just set __preempt_count to 0 during
> these periods and restore the old value afterwards.
>
> This would be a rather intrusive but clean change IMO.
>
> Any thoughts?

I like the idea of dynamically changing at run time the preemption model and
personally find this reasonable, however I am not certain if this would
introduce a series of issues hard to address. Thoughts by others who linger
deep in the cold lonely scheduler caves ?

  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 18:17:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 18: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 1XvVWY-0008LY-7d; Mon, 01 Dec 2014 18:16: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 1XvVWV-0008LT-W4
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 18:16:36 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	82/EB-31453-380BC745; Mon, 01 Dec 2014 18:16:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417457793!10896175!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 20214 invoked from network); 1 Dec 2014 18:16:34 -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;
	1 Dec 2014 18:16:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,495,1413244800"; d="scan'208";a="198507072"
Message-ID: <547CB07C.1050507@citrix.com>
Date: Mon, 1 Dec 2014 18:16:28 +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: "Luis R. Rodriguez" <mcgrof@suse.com>, David Vrabel
	<david.vrabel@citrix.com>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>	<5476C66F.5040308@suse.com>
	<20141127183616.GV25677@wotan.suse.de>	<547C4CEF.1010603@citrix.com>	<20141201150546.GC25677@wotan.suse.de>	<547C86BF.2040705@citrix.com>	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
In-Reply-To: <20141201161905.GH25677@wotan.suse.de>
X-DLP: MIA1
Cc: Juergen Gross <jgross@suse.com>, Joerg Roedel <jroedel@suse.de>,
	kvm@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 01/12/14 16:19, Luis R. Rodriguez wrote:
> On Mon, Dec 01, 2014 at 03:54:24PM +0000, David Vrabel wrote:
>> On 01/12/14 15:44, Luis R. Rodriguez wrote:
>>> On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>> On 01/12/14 15:05, Luis R. Rodriguez wrote:
>>>>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
>>>>>> [...]
>>>>>>>>> --- 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
>>>>>>
>>>>>> As Juergen points out, this does nothing.  You need to schedule while in
>>>>>> the middle of the hypercall.
>>>>>>
>>>>>> Remember that Xen's hypercall preemption only preempts the hypercall to
>>>>>> run interrupts in the guest.
>>>>>
>>>>> How is it ensured that when the kernel preempts on this code path on
>>>>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
>>>>
>>>> Sorry, I really didn't describe this very well.
>>>>
>>>> If a hypercall needs a continuation, Xen returns to the guest with the
>>>> IP set to the hypercall instruction, and on the way back to the guest
>>>> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
>>>>
>>>> The guest is free to return from the upcall to the original task
>>>> (continuing the hypercall) or to a different one.
>>>
>>> OK so that addresses what Xen will do when using continuation and
>>> hypercall preemption, my concern here was that using
>>> preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
>>> hypercall on the return from an interrupt (e.g., the timer interrupt)
>>> would still let the kernel preempt to tasks other than those related
>>> to Xen.
>>
>> Um.  Why would that be a problem?  We do want to switch to any task the
>> Linux scheduler thinks is best.
> 
> Its safe but -- it technically is doing kernel preemption, unless we want
> to adjust the definition of CONFIG_PREEMPT=n to exclude hypercalls. This
> was my original concern with the use of preempt_schedule_irq() to do this.
> I am afraid of setting precedents without being clear or wider review and
> acceptance.

It's voluntary preemption at a well defined point.  It's no different to
a cond_resched() call.

Note that we're not trying to fix this for the non-voluntary-preempt
kernels.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 18:17:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 18: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 1XvVWY-0008LY-7d; Mon, 01 Dec 2014 18:16: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 1XvVWV-0008LT-W4
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 18:16:36 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	82/EB-31453-380BC745; Mon, 01 Dec 2014 18:16:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417457793!10896175!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 20214 invoked from network); 1 Dec 2014 18:16:34 -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;
	1 Dec 2014 18:16:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,495,1413244800"; d="scan'208";a="198507072"
Message-ID: <547CB07C.1050507@citrix.com>
Date: Mon, 1 Dec 2014 18:16:28 +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: "Luis R. Rodriguez" <mcgrof@suse.com>, David Vrabel
	<david.vrabel@citrix.com>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>	<5476C66F.5040308@suse.com>
	<20141127183616.GV25677@wotan.suse.de>	<547C4CEF.1010603@citrix.com>	<20141201150546.GC25677@wotan.suse.de>	<547C86BF.2040705@citrix.com>	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
In-Reply-To: <20141201161905.GH25677@wotan.suse.de>
X-DLP: MIA1
Cc: Juergen Gross <jgross@suse.com>, Joerg Roedel <jroedel@suse.de>,
	kvm@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 01/12/14 16:19, Luis R. Rodriguez wrote:
> On Mon, Dec 01, 2014 at 03:54:24PM +0000, David Vrabel wrote:
>> On 01/12/14 15:44, Luis R. Rodriguez wrote:
>>> On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>> On 01/12/14 15:05, Luis R. Rodriguez wrote:
>>>>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
>>>>>> [...]
>>>>>>>>> --- 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
>>>>>>
>>>>>> As Juergen points out, this does nothing.  You need to schedule while in
>>>>>> the middle of the hypercall.
>>>>>>
>>>>>> Remember that Xen's hypercall preemption only preempts the hypercall to
>>>>>> run interrupts in the guest.
>>>>>
>>>>> How is it ensured that when the kernel preempts on this code path on
>>>>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
>>>>
>>>> Sorry, I really didn't describe this very well.
>>>>
>>>> If a hypercall needs a continuation, Xen returns to the guest with the
>>>> IP set to the hypercall instruction, and on the way back to the guest
>>>> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
>>>>
>>>> The guest is free to return from the upcall to the original task
>>>> (continuing the hypercall) or to a different one.
>>>
>>> OK so that addresses what Xen will do when using continuation and
>>> hypercall preemption, my concern here was that using
>>> preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
>>> hypercall on the return from an interrupt (e.g., the timer interrupt)
>>> would still let the kernel preempt to tasks other than those related
>>> to Xen.
>>
>> Um.  Why would that be a problem?  We do want to switch to any task the
>> Linux scheduler thinks is best.
> 
> Its safe but -- it technically is doing kernel preemption, unless we want
> to adjust the definition of CONFIG_PREEMPT=n to exclude hypercalls. This
> was my original concern with the use of preempt_schedule_irq() to do this.
> I am afraid of setting precedents without being clear or wider review and
> acceptance.

It's voluntary preemption at a well defined point.  It's no different to
a cond_resched() call.

Note that we're not trying to fix this for the non-voluntary-preempt
kernels.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 18:17:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 18:17:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvVX4-0008NT-Kk; Mon, 01 Dec 2014 18:17:10 +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 1XvVX3-0008NJ-Li
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 18:17:09 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	10/65-02702-5A0BC745; Mon, 01 Dec 2014 18:17:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417457826!12260608!1
X-Originating-IP: [66.165.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 10810 invoked from network); 1 Dec 2014 18:17:08 -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;
	1 Dec 2014 18:17:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,495,1413244800"; d="scan'208";a="198507341"
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, 1 Dec 2014 13:17: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 1XvVWy-0005Kx-Ir;
	Mon, 01 Dec 2014 18:17:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvVWy-000406-BU;
	Mon, 01 Dec 2014 18:17:04 +0000
Date: Mon, 1 Dec 2014 18:17:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31963-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] 31963: 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 31963 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31963/

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 31932

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                  188336bb86d0992a2a034ece5f39eccc5d10f337

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 18:17:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 18:17:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvVX4-0008NT-Kk; Mon, 01 Dec 2014 18:17:10 +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 1XvVX3-0008NJ-Li
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 18:17:09 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	10/65-02702-5A0BC745; Mon, 01 Dec 2014 18:17:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417457826!12260608!1
X-Originating-IP: [66.165.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 10810 invoked from network); 1 Dec 2014 18:17:08 -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;
	1 Dec 2014 18:17:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,495,1413244800"; d="scan'208";a="198507341"
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, 1 Dec 2014 13:17: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 1XvVWy-0005Kx-Ir;
	Mon, 01 Dec 2014 18:17:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvVWy-000406-BU;
	Mon, 01 Dec 2014 18:17:04 +0000
Date: Mon, 1 Dec 2014 18:17:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31963-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] 31963: 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 31963 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31963/

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 31932

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                  188336bb86d0992a2a034ece5f39eccc5d10f337

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 18:17:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 18: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 1XvVXM-0008QY-0y; Mon, 01 Dec 2014 18:17:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XvVXK-0008QF-Qb
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 18:17:26 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	A8/49-03148-6B0BC745; Mon, 01 Dec 2014 18:17:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417457843!12293508!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 24444 invoked from network); 1 Dec 2014 18:17:25 -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;
	1 Dec 2014 18:17:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,495,1413244800"; d="scan'208";a="198183088"
Message-ID: <547CB0AF.6010901@citrix.com>
Date: Mon, 1 Dec 2014 18:17:19 +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: David Vrabel <david.vrabel@citrix.com>, Anthony Wright
	<anthony@overnetdata.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <5478926A.80503@overnetdata.com> <547C79C0.4010608@citrix.com>
In-Reply-To: <547C79C0.4010608@citrix.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.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 01/12/14 14:22, David Vrabel wrote:
> On 28/11/14 15:19, Anthony Wright wrote:
>> 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
> 
> The guest's frontend driver isn't putting valid requests onto the ring
> (it crosses a page boundary) so this is a frontend bug.

This VIF protocol is weird.  The first slot contains a txreq with a size
for the total length of the packet, subsequent slots have sizes for that
fragment only.

netback then has to calculate how long the first slot is, by subtracting
all the size from the following slots.

So something has gone wrong but it's not obvious what it is.  Any chance
you can dump the ring state when it happens?

> What guest are you running?

Sorry, I missed that you said 3.17.3 for the domU as well.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 18:17:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 18: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 1XvVXM-0008QY-0y; Mon, 01 Dec 2014 18:17:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XvVXK-0008QF-Qb
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 18:17:26 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	A8/49-03148-6B0BC745; Mon, 01 Dec 2014 18:17:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417457843!12293508!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 24444 invoked from network); 1 Dec 2014 18:17:25 -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;
	1 Dec 2014 18:17:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,495,1413244800"; d="scan'208";a="198183088"
Message-ID: <547CB0AF.6010901@citrix.com>
Date: Mon, 1 Dec 2014 18:17:19 +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: David Vrabel <david.vrabel@citrix.com>, Anthony Wright
	<anthony@overnetdata.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <5478926A.80503@overnetdata.com> <547C79C0.4010608@citrix.com>
In-Reply-To: <547C79C0.4010608@citrix.com>
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.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 01/12/14 14:22, David Vrabel wrote:
> On 28/11/14 15:19, Anthony Wright wrote:
>> 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
> 
> The guest's frontend driver isn't putting valid requests onto the ring
> (it crosses a page boundary) so this is a frontend bug.

This VIF protocol is weird.  The first slot contains a txreq with a size
for the total length of the packet, subsequent slots have sizes for that
fragment only.

netback then has to calculate how long the first slot is, by subtracting
all the size from the following slots.

So something has gone wrong but it's not obvious what it is.  Any chance
you can dump the ring state when it happens?

> What guest are you running?

Sorry, I missed that you said 3.17.3 for the domU as well.

David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 18:46:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 18: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 1XvVyj-0000jd-1S; Mon, 01 Dec 2014 18:45:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.haxby@oracle.com>) id 1XvVyh-0000jW-4N
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 18:45:43 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8B/31-25276-657BC745; Mon, 01 Dec 2014 18:45:42 +0000
X-Env-Sender: john.haxby@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417459540!9237312!1
X-Originating-IP: [156.151.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 13245 invoked from network); 1 Dec 2014 18:45:41 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 18:45: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 sB1IjVn6025145
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 18:45:33 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
	sB1IjVnI009173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 18:45:31 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
	sB1IjUCu006857; Mon, 1 Dec 2014 18:45:30 GMT
Received: from bramley.thehaxbys.plus.com (/80.229.30.222)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 10:45:30 -0800
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: John Haxby <john.haxby@oracle.com>
In-Reply-To: <547CA220.9070604@citrix.com>
Date: Mon, 1 Dec 2014 18:45:29 +0000
Message-Id: <309AAB3D-A4EE-485C-BE09-AAC4192E7F27@oracle.com>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
	<1417444646-20636-2-git-send-email-john.haxby@oracle.com>
	<547CA220.9070604@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
X-Mailer: Apple Mail (2.1993)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] xen-detect: fix strict-aliasing
	compilation warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6812033347405497337=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6812033347405497337==
Content-Type: multipart/alternative; boundary="Apple-Mail=_557D9E7E-2C39-43AF-84EA-9847A5350089"


--Apple-Mail=_557D9E7E-2C39-43AF-84EA-9847A5350089
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 1 Dec 2014, at 17:15, Andrew Cooper <andrew.cooper3@citrix.com> =
wrote:
>=20
> On 01/12/14 14:37, John Haxby wrote:
>> With gcc 4.8.3, compiling xen-detect gives a compilation warning if
>> you're optimising:
>>=20
>> $ cc -Wall -Os xen-detect.c
>> xen-detect.c: In function =E2=80=98check_for_xen=E2=80=99:
>> xen-detect.c:65:9: warning: dereferencing type-punned pointer will =
break
>> strict-aliasing rules [-Wstrict-aliasing]
>>         *(uint32_t *)(signature + 0) =3D regs[1];
>>         ^
>>=20
>> Signed-off-by: John Haxby <john.haxby@oracle.com =
<mailto:john.haxby@oracle.com>>
>=20
> Why are you compiling without the CFLAGS from the Xen build system?
>=20
> We explicitly disable strict alias optimisations, because =
optimisations
> based upon the aliasing rules in C is mad.  Even when you eliminate =
all
> the warnings, there are still subtle bugs because the compiler is free
> to assume a lot more than a programmer would typically deem =
reasonable.


I wasn=E2=80=99t building the whole system, I just wanted xen-detect so =
I pulled it out and compiled it; I usually use "-Wall -Os=E2=80=9D =
because the combination finds problems I might otherwise overlook.   The =
patch also removes three lines of code :) but you can take it or leave =
it as you choose.   The other patch =E2=80=94 reversing the code of pv =
and hvm checking =E2=80=94 was the real problem.

jch=

--Apple-Mail=_557D9E7E-2C39-43AF-84EA-9847A5350089
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 1 Dec 2014, at 17:15, Andrew Cooper &lt;<a =
href=3D"mailto:andrew.cooper3@citrix.com" =
class=3D"">andrew.cooper3@citrix.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><span =
style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">On 01/12/14 14:37, John Haxby =
wrote:</span><br style=3D"font-family: Menlo-Regular; font-size: 11px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""><blockquote type=3D"cite" style=3D"font-family: =
Menlo-Regular; font-size: 11px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D"">With gcc 4.8.3, =
compiling xen-detect gives a compilation warning if<br class=3D"">you're =
optimising:<br class=3D""><br class=3D"">$ cc -Wall -Os xen-detect.c<br =
class=3D"">xen-detect.c: In function =E2=80=98check_for_xen=E2=80=99:<br =
class=3D"">xen-detect.c:65:9: warning: dereferencing type-punned pointer =
will break<br class=3D"">strict-aliasing rules [-Wstrict-aliasing]<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*(uint32_t =
*)(signature + 0) =3D regs[1];<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;^<br =
class=3D""><br class=3D"">Signed-off-by: John Haxby &lt;<a =
href=3D"mailto:john.haxby@oracle.com" =
class=3D"">john.haxby@oracle.com</a>&gt;<br class=3D""></blockquote><br =
style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span=
 style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">Why are you compiling without =
the CFLAGS from the Xen build system?</span><br style=3D"font-family: =
Menlo-Regular; font-size: 11px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D""><br style=3D"font-family:=
 Menlo-Regular; font-size: 11px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D""><span =
style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">We explicitly disable strict =
alias optimisations, because optimisations</span><br style=3D"font-family:=
 Menlo-Regular; font-size: 11px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D""><span =
style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">based upon the aliasing rules in =
C is mad. &nbsp;Even when you eliminate all</span><br =
style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span=
 style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">the warnings, there are still =
subtle bugs because the compiler is free</span><br style=3D"font-family: =
Menlo-Regular; font-size: 11px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D""><span =
style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">to assume a lot more than a =
programmer would typically deem =
reasonable.</span></div></blockquote></div><br class=3D""><div =
class=3D""><br class=3D""></div><div class=3D"">I wasn=E2=80=99t =
building the whole system, I just wanted xen-detect so I pulled it out =
and compiled it; I usually use "-Wall -Os=E2=80=9D because the =
combination finds problems I might otherwise overlook. &nbsp; The patch =
also removes three lines of code :) but you can take it or leave it as =
you choose. &nbsp; The other patch =E2=80=94 reversing the code of pv =
and hvm checking =E2=80=94 was the real problem.</div><div class=3D""><br =
class=3D""></div><div class=3D"">jch</div></body></html>=

--Apple-Mail=_557D9E7E-2C39-43AF-84EA-9847A5350089--


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

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

--===============6812033347405497337==--


From xen-devel-bounces@lists.xen.org Mon Dec 01 18:46:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 18: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 1XvVyj-0000jd-1S; Mon, 01 Dec 2014 18:45:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.haxby@oracle.com>) id 1XvVyh-0000jW-4N
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 18:45:43 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8B/31-25276-657BC745; Mon, 01 Dec 2014 18:45:42 +0000
X-Env-Sender: john.haxby@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417459540!9237312!1
X-Originating-IP: [156.151.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 13245 invoked from network); 1 Dec 2014 18:45:41 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 18:45: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 sB1IjVn6025145
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 18:45:33 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
	sB1IjVnI009173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 18:45:31 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
	sB1IjUCu006857; Mon, 1 Dec 2014 18:45:30 GMT
Received: from bramley.thehaxbys.plus.com (/80.229.30.222)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 10:45:30 -0800
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: John Haxby <john.haxby@oracle.com>
In-Reply-To: <547CA220.9070604@citrix.com>
Date: Mon, 1 Dec 2014 18:45:29 +0000
Message-Id: <309AAB3D-A4EE-485C-BE09-AAC4192E7F27@oracle.com>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
	<1417444646-20636-2-git-send-email-john.haxby@oracle.com>
	<547CA220.9070604@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
X-Mailer: Apple Mail (2.1993)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] xen-detect: fix strict-aliasing
	compilation warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6812033347405497337=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6812033347405497337==
Content-Type: multipart/alternative; boundary="Apple-Mail=_557D9E7E-2C39-43AF-84EA-9847A5350089"


--Apple-Mail=_557D9E7E-2C39-43AF-84EA-9847A5350089
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 1 Dec 2014, at 17:15, Andrew Cooper <andrew.cooper3@citrix.com> =
wrote:
>=20
> On 01/12/14 14:37, John Haxby wrote:
>> With gcc 4.8.3, compiling xen-detect gives a compilation warning if
>> you're optimising:
>>=20
>> $ cc -Wall -Os xen-detect.c
>> xen-detect.c: In function =E2=80=98check_for_xen=E2=80=99:
>> xen-detect.c:65:9: warning: dereferencing type-punned pointer will =
break
>> strict-aliasing rules [-Wstrict-aliasing]
>>         *(uint32_t *)(signature + 0) =3D regs[1];
>>         ^
>>=20
>> Signed-off-by: John Haxby <john.haxby@oracle.com =
<mailto:john.haxby@oracle.com>>
>=20
> Why are you compiling without the CFLAGS from the Xen build system?
>=20
> We explicitly disable strict alias optimisations, because =
optimisations
> based upon the aliasing rules in C is mad.  Even when you eliminate =
all
> the warnings, there are still subtle bugs because the compiler is free
> to assume a lot more than a programmer would typically deem =
reasonable.


I wasn=E2=80=99t building the whole system, I just wanted xen-detect so =
I pulled it out and compiled it; I usually use "-Wall -Os=E2=80=9D =
because the combination finds problems I might otherwise overlook.   The =
patch also removes three lines of code :) but you can take it or leave =
it as you choose.   The other patch =E2=80=94 reversing the code of pv =
and hvm checking =E2=80=94 was the real problem.

jch=

--Apple-Mail=_557D9E7E-2C39-43AF-84EA-9847A5350089
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 1 Dec 2014, at 17:15, Andrew Cooper &lt;<a =
href=3D"mailto:andrew.cooper3@citrix.com" =
class=3D"">andrew.cooper3@citrix.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><span =
style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">On 01/12/14 14:37, John Haxby =
wrote:</span><br style=3D"font-family: Menlo-Regular; font-size: 11px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""><blockquote type=3D"cite" style=3D"font-family: =
Menlo-Regular; font-size: 11px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D"">With gcc 4.8.3, =
compiling xen-detect gives a compilation warning if<br class=3D"">you're =
optimising:<br class=3D""><br class=3D"">$ cc -Wall -Os xen-detect.c<br =
class=3D"">xen-detect.c: In function =E2=80=98check_for_xen=E2=80=99:<br =
class=3D"">xen-detect.c:65:9: warning: dereferencing type-punned pointer =
will break<br class=3D"">strict-aliasing rules [-Wstrict-aliasing]<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*(uint32_t =
*)(signature + 0) =3D regs[1];<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;^<br =
class=3D""><br class=3D"">Signed-off-by: John Haxby &lt;<a =
href=3D"mailto:john.haxby@oracle.com" =
class=3D"">john.haxby@oracle.com</a>&gt;<br class=3D""></blockquote><br =
style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span=
 style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">Why are you compiling without =
the CFLAGS from the Xen build system?</span><br style=3D"font-family: =
Menlo-Regular; font-size: 11px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D""><br style=3D"font-family:=
 Menlo-Regular; font-size: 11px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D""><span =
style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">We explicitly disable strict =
alias optimisations, because optimisations</span><br style=3D"font-family:=
 Menlo-Regular; font-size: 11px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D""><span =
style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">based upon the aliasing rules in =
C is mad. &nbsp;Even when you eliminate all</span><br =
style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span=
 style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">the warnings, there are still =
subtle bugs because the compiler is free</span><br style=3D"font-family: =
Menlo-Regular; font-size: 11px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D""><span =
style=3D"font-family: Menlo-Regular; font-size: 11px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">to assume a lot more than a =
programmer would typically deem =
reasonable.</span></div></blockquote></div><br class=3D""><div =
class=3D""><br class=3D""></div><div class=3D"">I wasn=E2=80=99t =
building the whole system, I just wanted xen-detect so I pulled it out =
and compiled it; I usually use "-Wall -Os=E2=80=9D because the =
combination finds problems I might otherwise overlook. &nbsp; The patch =
also removes three lines of code :) but you can take it or leave it as =
you choose. &nbsp; The other patch =E2=80=94 reversing the code of pv =
and hvm checking =E2=80=94 was the real problem.</div><div class=3D""><br =
class=3D""></div><div class=3D"">jch</div></body></html>=

--Apple-Mail=_557D9E7E-2C39-43AF-84EA-9847A5350089--


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

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

--===============6812033347405497337==--


From xen-devel-bounces@lists.xen.org Mon Dec 01 19:11:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 19: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 1XvWNX-0001Dz-PT; Mon, 01 Dec 2014 19:11: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 1XvWNW-0001Du-4h
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 19:11:22 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	DA/1B-02696-95DBC745; Mon, 01 Dec 2014 19:11:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417461077!12198858!1
X-Originating-IP: [66.165.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 2817 invoked from network); 1 Dec 2014 19:11:20 -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;
	1 Dec 2014 19:11:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,495,1413244800"; d="scan'208";a="198206109"
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, 1 Dec 2014 14:10:36 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XvWMm-0005aX-4h;
	Mon, 01 Dec 2014 19:10:36 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvWMl-0005ii-UT;
	Mon, 01 Dec 2014 19:10:35 +0000
Date: Mon, 1 Dec 2014 19:10:35 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31970-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] 31970: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 31900

version targeted for testing:
 rumpuserxen          24624847a5c074be81feb11f64fae54f6e702f83
baseline version:
 rumpuserxen          6dac8499151377c6e5eb57b5bf1fff7b62776ca5

------------------------------------------------------------
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                             fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 24624847a5c074be81feb11f64fae54f6e702f83
Author: Antti Kantee <pooka@iki.fi>
Date:   Sun Nov 30 23:21:08 2014 +0000

    pull in latest src-netbsd

commit 51181f220394681b78bbf525673ccee44c4b01b5
Author: Antti Kantee <pooka@iki.fi>
Date:   Sun Nov 30 23:03:45 2014 +0000

    pull in latest buildrump.sh

commit 71f3866ce0f0e935df43b2b270c6a3f741e07f57
Author: Antti Kantee <pooka@iki.fi>
Date:   Sun Nov 30 22:57:09 2014 +0000

    pull in latest buildrump.sh

commit 66203d7869af7ae3ed9e73c5aa82b70a16c0a280
Author: Antti Kantee <pooka@iki.fi>
Date:   Sun Nov 30 22:51:18 2014 +0000

    Overriding probe of RUMP_CURLWP is no longer necessary in -k builds

commit d053b98b3e9763cf28ca43e66a492ea58257c74a
Author: Antti Kantee <pooka@iki.fi>
Date:   Sun Nov 30 22:51:06 2014 +0000

    pull in new buildrump.sh

commit 56f86ecd280b276e1119926a582b540e57d03189
Author: Antti Kantee <pooka@iki.fi>
Date:   Wed Nov 26 16:57:11 2014 +0000

    put the "standard" demo routines in a subdirectory

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 19:11:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 19: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 1XvWNX-0001Dz-PT; Mon, 01 Dec 2014 19:11: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 1XvWNW-0001Du-4h
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 19:11:22 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	DA/1B-02696-95DBC745; Mon, 01 Dec 2014 19:11:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417461077!12198858!1
X-Originating-IP: [66.165.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 2817 invoked from network); 1 Dec 2014 19:11:20 -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;
	1 Dec 2014 19:11:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,495,1413244800"; d="scan'208";a="198206109"
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, 1 Dec 2014 14:10:36 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XvWMm-0005aX-4h;
	Mon, 01 Dec 2014 19:10:36 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvWMl-0005ii-UT;
	Mon, 01 Dec 2014 19:10:35 +0000
Date: Mon, 1 Dec 2014 19:10:35 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-31970-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] 31970: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 31900

version targeted for testing:
 rumpuserxen          24624847a5c074be81feb11f64fae54f6e702f83
baseline version:
 rumpuserxen          6dac8499151377c6e5eb57b5bf1fff7b62776ca5

------------------------------------------------------------
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                             fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 24624847a5c074be81feb11f64fae54f6e702f83
Author: Antti Kantee <pooka@iki.fi>
Date:   Sun Nov 30 23:21:08 2014 +0000

    pull in latest src-netbsd

commit 51181f220394681b78bbf525673ccee44c4b01b5
Author: Antti Kantee <pooka@iki.fi>
Date:   Sun Nov 30 23:03:45 2014 +0000

    pull in latest buildrump.sh

commit 71f3866ce0f0e935df43b2b270c6a3f741e07f57
Author: Antti Kantee <pooka@iki.fi>
Date:   Sun Nov 30 22:57:09 2014 +0000

    pull in latest buildrump.sh

commit 66203d7869af7ae3ed9e73c5aa82b70a16c0a280
Author: Antti Kantee <pooka@iki.fi>
Date:   Sun Nov 30 22:51:18 2014 +0000

    Overriding probe of RUMP_CURLWP is no longer necessary in -k builds

commit d053b98b3e9763cf28ca43e66a492ea58257c74a
Author: Antti Kantee <pooka@iki.fi>
Date:   Sun Nov 30 22:51:06 2014 +0000

    pull in new buildrump.sh

commit 56f86ecd280b276e1119926a582b540e57d03189
Author: Antti Kantee <pooka@iki.fi>
Date:   Wed Nov 26 16:57:11 2014 +0000

    put the "standard" demo routines in a subdirectory

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 19:23:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 19:23:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvWYz-0001dg-17; Mon, 01 Dec 2014 19:23: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 1XvWYx-0001db-MA
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 19:23:11 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	96/E6-16982-E10CC745; Mon, 01 Dec 2014 19:23:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417461786!15118052!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29082 invoked from network); 1 Dec 2014 19:23:09 -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;
	1 Dec 2014 19:23:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,495,1413244800"; d="scan'208";a="198535917"
Received: from ukmail1.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, 1 Dec 2014 14:23: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 1XvWYr-0002PD-9s;
	Mon, 01 Dec 2014 19:23:05 +0000
Date: Mon, 1 Dec 2014 19:22:55 +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: <1868834068.20141128184004@eikelenboom.it>
Message-ID: <alpine.DEB.2.02.1412011852390.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>, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH for-4.5] call xc_domain_irq_permission before
 xc_domain_irq_permission
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xc_physdev_unmap_pirq might revoke the permission to map the irq from
the domain causing the following xc_domain_irq_permission call to fail
and return error (domain_pirq_to_irq returns 0).

Call xc_domain_irq_permission first to prevent this from happening
(xc_physdev_unmap_pirq calls irq_deny_access, that doesn't fail if the
permission is already removed).

This is a simple bug fix and I think should go in 4.5.

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..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 Mon Dec 01 19:23:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 19:23:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvWYz-0001dg-17; Mon, 01 Dec 2014 19:23: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 1XvWYx-0001db-MA
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 19:23:11 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	96/E6-16982-E10CC745; Mon, 01 Dec 2014 19:23:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417461786!15118052!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29082 invoked from network); 1 Dec 2014 19:23:09 -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;
	1 Dec 2014 19:23:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,495,1413244800"; d="scan'208";a="198535917"
Received: from ukmail1.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, 1 Dec 2014 14:23: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 1XvWYr-0002PD-9s;
	Mon, 01 Dec 2014 19:23:05 +0000
Date: Mon, 1 Dec 2014 19:22:55 +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: <1868834068.20141128184004@eikelenboom.it>
Message-ID: <alpine.DEB.2.02.1412011852390.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>, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH for-4.5] call xc_domain_irq_permission before
 xc_domain_irq_permission
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xc_physdev_unmap_pirq might revoke the permission to map the irq from
the domain causing the following xc_domain_irq_permission call to fail
and return error (domain_pirq_to_irq returns 0).

Call xc_domain_irq_permission first to prevent this from happening
(xc_physdev_unmap_pirq calls irq_deny_access, that doesn't fail if the
permission is already removed).

This is a simple bug fix and I think should go in 4.5.

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..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 Mon Dec 01 20:10:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 20:10:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvXIO-0002U7-5K; Mon, 01 Dec 2014 20:10:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vianom@gmail.com>) id 1XvXIM-0002Tz-OR
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 20:10:06 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	F3/CB-27584-D1BCC745; Mon, 01 Dec 2014 20:10:05 +0000
X-Env-Sender: vianom@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417464605!10930607!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=2.3 required=7.0 tests=HTML_60_70,
	HTML_IMAGE_ONLY_04,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11190 invoked from network); 1 Dec 2014 20:10:05 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 20:10:05 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so15240052wgg.0
	for <xen-devel@lists.xen.org>; Mon, 01 Dec 2014 12:10:05 -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=VjywlaaWGLjkInByoxHZCf7nLE91n17ZLC1LJ6c3Hs4=;
	b=KV8O26yhz3bVpJ6AvaY6MOZx5lidbPsf+lekpLmTKGUQpZsXlnrpaKRHIp48fY3Ndp
	smIsMi9AanY5F3QH7yj/wYvpA72r8298N9MHulqtcpKsQLIO+tOOfBhAgLP/PRvcj6CE
	+4+wIEgo4MEzJ84nimsi6fivezsjGsrWM0fA0UPHbGtVyoDwOazs9w3uAZctTz6lVdlo
	9mdqbsmoiyZAbkix8NhAMyCkeSiKZ+KR3RKHrIj67PLMFmatP07ugxztCtrDy8fX2qRo
	1UYILT+lY/X+/HE+eWvJLM4O4d3+sELlfLGH2xanueQBRnEGpCA372GIOUFGH6Rx+EMv
	z/9Q==
MIME-Version: 1.0
X-Received: by 10.194.90.244 with SMTP id bz20mr97762309wjb.125.1417464605114; 
	Mon, 01 Dec 2014 12:10:05 -0800 (PST)
Received: by 10.216.35.1 with HTTP; Mon, 1 Dec 2014 12:10:05 -0800 (PST)
Date: Mon, 1 Dec 2014 21:10:05 +0100
Message-ID: <CAE9jt3-MmniP=DdOqtjmE3TmnhGW=qrdtV0uwnL49-FZMm2nMQ@mail.gmail.com>
From: leon zawodowiec <vianom@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Time dilation in XEN 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8073194034006076464=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8073194034006076464==
Content-Type: multipart/alternative; boundary=047d7bfd090a45066a05092d3211

--047d7bfd090a45066a05092d3211
Content-Type: text/plain; charset=UTF-8

Hello, is it possible to implement time dilation in XEN 4.2 without
modyfing kernel(also hints are welcome)? Thank you for replies.

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

<div dir=3D"ltr">Hello, is it possible to implement time dilation in XEN 4.=
2 without modyfing kernel(also hints are welcome)? Thank you for replies.<i=
mg src=3D"http://t.signaledue.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7=
sKj6v4LN9-W2zqh2z3N1NYTVdD-D81pctGFW5wMh8b1k1H6H0?si=3D6102418673106944&amp=
;pi=3De0d109d5-af93-43e1-c1cd-574eeb41a0d1" width=3D"1" height=3D"1" style=
=3D"display:none"></div>

--047d7bfd090a45066a05092d3211--


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

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

--===============8073194034006076464==--


From xen-devel-bounces@lists.xen.org Mon Dec 01 20:10:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 20:10:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvXIO-0002U7-5K; Mon, 01 Dec 2014 20:10:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vianom@gmail.com>) id 1XvXIM-0002Tz-OR
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 20:10:06 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	F3/CB-27584-D1BCC745; Mon, 01 Dec 2014 20:10:05 +0000
X-Env-Sender: vianom@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417464605!10930607!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=2.3 required=7.0 tests=HTML_60_70,
	HTML_IMAGE_ONLY_04,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11190 invoked from network); 1 Dec 2014 20:10:05 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 20:10:05 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so15240052wgg.0
	for <xen-devel@lists.xen.org>; Mon, 01 Dec 2014 12:10:05 -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=VjywlaaWGLjkInByoxHZCf7nLE91n17ZLC1LJ6c3Hs4=;
	b=KV8O26yhz3bVpJ6AvaY6MOZx5lidbPsf+lekpLmTKGUQpZsXlnrpaKRHIp48fY3Ndp
	smIsMi9AanY5F3QH7yj/wYvpA72r8298N9MHulqtcpKsQLIO+tOOfBhAgLP/PRvcj6CE
	+4+wIEgo4MEzJ84nimsi6fivezsjGsrWM0fA0UPHbGtVyoDwOazs9w3uAZctTz6lVdlo
	9mdqbsmoiyZAbkix8NhAMyCkeSiKZ+KR3RKHrIj67PLMFmatP07ugxztCtrDy8fX2qRo
	1UYILT+lY/X+/HE+eWvJLM4O4d3+sELlfLGH2xanueQBRnEGpCA372GIOUFGH6Rx+EMv
	z/9Q==
MIME-Version: 1.0
X-Received: by 10.194.90.244 with SMTP id bz20mr97762309wjb.125.1417464605114; 
	Mon, 01 Dec 2014 12:10:05 -0800 (PST)
Received: by 10.216.35.1 with HTTP; Mon, 1 Dec 2014 12:10:05 -0800 (PST)
Date: Mon, 1 Dec 2014 21:10:05 +0100
Message-ID: <CAE9jt3-MmniP=DdOqtjmE3TmnhGW=qrdtV0uwnL49-FZMm2nMQ@mail.gmail.com>
From: leon zawodowiec <vianom@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Time dilation in XEN 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8073194034006076464=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8073194034006076464==
Content-Type: multipart/alternative; boundary=047d7bfd090a45066a05092d3211

--047d7bfd090a45066a05092d3211
Content-Type: text/plain; charset=UTF-8

Hello, is it possible to implement time dilation in XEN 4.2 without
modyfing kernel(also hints are welcome)? Thank you for replies.

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

<div dir=3D"ltr">Hello, is it possible to implement time dilation in XEN 4.=
2 without modyfing kernel(also hints are welcome)? Thank you for replies.<i=
mg src=3D"http://t.signaledue.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7=
sKj6v4LN9-W2zqh2z3N1NYTVdD-D81pctGFW5wMh8b1k1H6H0?si=3D6102418673106944&amp=
;pi=3De0d109d5-af93-43e1-c1cd-574eeb41a0d1" width=3D"1" height=3D"1" style=
=3D"display:none"></div>

--047d7bfd090a45066a05092d3211--


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

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

--===============8073194034006076464==--


From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ91-0004jJ-JF; Mon, 01 Dec 2014 22:08:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ90-0004iP-J2
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:34 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	E6/A5-22819-1E6EC745; Mon, 01 Dec 2014 22:08:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417471712!10968138!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9743 invoked from network); 1 Dec 2014 22:08:33 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 22:08: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 sB1M8MPF020458
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:23 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
	sB1M8LpD028552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:22 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
	sB1M8LIQ019472; Mon, 1 Dec 2014 22:08:21 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:20 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 54E0511A684; Mon,  1 Dec 2014 10:33:36 -0500 (EST)
Date: Mon, 1 Dec 2014 10:33:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andy Lutomirski <luto@amacapital.net>
Message-ID: <20141201153336.GB3180@laptop.dumpdata.com>
References: <cover.1414516558.git.luto@amacapital.net>
	<6b0c9b0fc128de68634c730a5b1a80e1d085ad02.1414516558.git.luto@amacapital.net>
	<20141028174629.GA2150@jtriplet-mobl1>
	<CALCETrUihPeKODJqi3tMYwyWYhML1Z=gr4wrVK5VnaFo=KGVJA@mail.gmail.com>
	<20141029200016.GK3424@laptop.dumpdata.com>
	<CALCETrW+f8S9fNrui_J34q3Ve4jwA=neGe-tYZ_Lbp+ML3LiRw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALCETrW+f8S9fNrui_J34q3Ve4jwA=neGe-tYZ_Lbp+ML3LiRw@mail.gmail.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" <xen-devel@lists.xenproject.org>,
	X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Josh Triplett <josh@joshtriplett.org>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/3] x86_64,
	vsyscall: Make vsyscall emulation 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>
Content-Type: text/plain; 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 02:30:29PM -0700, Andy Lutomirski wrote:
> On Oct 29, 2014 1:00 PM, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:
> >
> > On Tue, Oct 28, 2014 at 11:09:53AM -0700, Andy Lutomirski wrote:
> > > On Tue, Oct 28, 2014 at 10:57 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> > > > On Tue, Oct 28, 2014 at 10:22:28AM -0700, Andy Lutomirski wrote:
> > > >> This adds CONFIG_X86_VSYSCALL_EMULATION, guarded by CONFIG_EXPERT.
> > > >> Turning it off completely disables vsyscall emulation, saving ~3.5k
> > > >> for vsyscall_64.c, 4k for vsyscall_emu_64.S (the fake vsyscall
> > > >> page), some tiny amount of core mm code that supports a gate area,
> > > >> and possibly 4k for a wasted pagetable.  The latter is because the
> > > >> vsyscall addresses are misaligned and fit poorly in the fixmap.
> > > >>
> > > >> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> > > >
> > > > One minor nit below, but with or without that change,
> > > > Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> > > >
> > > >> --- a/arch/x86/xen/mmu.c
> > > >> +++ b/arch/x86/xen/mmu.c
> > > >> @@ -1456,11 +1456,13 @@ static int xen_pgd_alloc(struct mm_struct *mm)
> > > >>               user_pgd = (pgd_t *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
> > > >>               page->private = (unsigned long)user_pgd;
> > > >>
> > > >> +#ifdef CONFIG_X86_VSYSCALL_EMULATION
> > > >>               if (user_pgd != NULL) {
> > > >>                       user_pgd[pgd_index(VSYSCALL_ADDR)] =
> > > >>                               __pgd(__pa(level3_user_vsyscall) | _PAGE_TABLE);
> > > >>                       ret = 0;
> > > >>               }
> > > >> +#endif
> > > >
> > > > Could you instead make the if use IS_ENABLED?
> > > >
> > > >                 if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION) && user_pgd != NULL)
> > > >
> > > > That has the advantage of ensuring that the code continues to compile.
> > > > (Given that you haven't removed level3_user_vsyscall, that should work.)
> > >
> > > I need the ret = 0, I think, so I'll resend.
> > >
> > > I think I'd rather use #ifdef here, since I think it would be great if
> > > the Xen people could clean this up further.  With this change, under
> > > some configurations, there should be no user-accessible kernel
> > > addresses at all.  (Also, is there some PV mechanism

What about the vsyscall time stamp (aka kvm-clock). That is not
really VSYSCALL emulation based but normal code?

> > > that I'm not thinking of that will break with this change?  I know
> > > I've tripped over Xen pagetable and fixmap oddities before.)
> >
> > Not that I know of. The vsyscall is the only one that I know of that
> > does this.
> 
> There's kvm-clock, too, but that may never co-exist with Xen.

It will eventually.
> 
> I tagged v2 here:
> 
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/tag/?id=optional-vsyscall-emulation-v2
> 
> and I'll send it out in a bit.
> 
> --Andy
> 
> >
> > Do you have a full patchset somewhere for testing?
> > >
> > > --Andy

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8y-0004h9-Oh; Mon, 01 Dec 2014 22:08:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ8x-0004gK-1M
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:31 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	BD/85-09284-ED6EC745; Mon, 01 Dec 2014 22:08:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417471708!15121907!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15022 invoked from network); 1 Dec 2014 22:08:29 -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; 1 Dec 2014 22:08: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 sB1M8QxD020492
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08: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
	sB1M8PHu028712
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:26 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
	sB1M8PLB019681; Mon, 1 Dec 2014 22:08:25 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:25 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4B6C111AA97; Mon,  1 Dec 2014 16:54:16 -0500 (EST)
Date: Mon, 1 Dec 2014 16:54:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141201215416.GF24289@laptop.dumpdata.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417433473-17272-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 v2 for-4.5 0/2] xl/libxl: fix API and 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

On Mon, Dec 01, 2014 at 11:31:11AM +0000, Wei Liu wrote:
> Return value of libxl_basename was erroneously marked as "const". This
> series removes that "const" and fixes two memory leaks in xl.
> 
> I think these fixes should be included in 4.5, given that they fix real
> issues and are very straight foward to reason about.

Thank you for catching those!

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Wei.
> 
> Wei Liu (2):
>   libxl: un-constify return value of libxl_basename
>   xl: fix two memory leaks
> 
>  tools/libxl/libxl.h       |   10 ++++++++++
>  tools/libxl/libxl_utils.c |    5 ++++-
>  tools/libxl/libxl_utils.h |    6 +++++-
>  tools/libxl/xl_cmdimpl.c  |    8 ++++++--
>  4 files changed, 25 insertions(+), 4 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 Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8o-0004eJ-Cc; Mon, 01 Dec 2014 22:08: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 1XvZ8m-0004e8-G7
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:20 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	02/42-24859-3D6EC745; Mon, 01 Dec 2014 22:08:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417471697!14971316!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2378 invoked from network); 1 Dec 2014 22:08:19 -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; 1 Dec 2014 22:08: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 sB1M8Aws014628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:11 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
	sB1M89nA027973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:10 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
	sB1M89b6018761; Mon, 1 Dec 2014 22:08:09 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0726211AAD0; Mon,  1 Dec 2014 17:02:42 -0500 (EST)
Date: Mon, 1 Dec 2014 17:02:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201220242.GI24289@laptop.dumpdata.com>
References: <1417444026-31044-1-git-send-email-euan.harris@citrix.com>
	<1417445456.29138.33.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417445456.29138.33.camel@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, Euan Harris <euan.harris@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Don't derefence null new_name
 pointer in libxl_domain_rename()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 02:50:56PM +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 14:27 +0000, Euan Harris wrote:
> > libxl__domain_rename() unconditionally dereferences its new_name
> > parameter, to check whether it is an empty string.   Add a check to
> > avoid a segfault if new_name is null.
> > 
> > Signed-off-by: Euan Harris <euan.harris@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I think this is a good fix to have for 4.5, Konrad CCd.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > ---
> >  tools/libxl/libxl.c |    7 +++++++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f84f7c2..6e84b5d 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -385,6 +385,13 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
> >          }
> >      }
> >  
> > +    if (!new_name) {
> > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                        "new domain name not specified");
> > +        rc = ERROR_INVAL;
> > +        goto x_rc;
> > +    }
> > +
> >      if (new_name[0]) {
> >          /* nonempty names must be unique */
> >          uint32_t domid_e;
> 
> 

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ9H-0004xE-Le; Mon, 01 Dec 2014 22:08: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 1XvZ9G-0004uf-4K
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:50 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	78/33-02699-1F6EC745; Mon, 01 Dec 2014 22:08:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417471727!7665034!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17642 invoked from network); 1 Dec 2014 22:08:48 -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; 1 Dec 2014 22:08:48 -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 sB1M8DgH020257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:14 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
	sB1M8CFD011343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:13 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
	sB1M8CeG011332; Mon, 1 Dec 2014 22:08:12 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:12 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EF1DC11A6F0; Mon,  1 Dec 2014 11:51:55 -0500 (EST)
Date: Mon, 1 Dec 2014 11:51:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Waiman Long <waiman.long@hp.com>
Message-ID: <20141201165155.GH3180@laptop.dumpdata.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>
	<54751FF6.5050808@hp.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54751FF6.5050808@hp.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
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-Type: text/plain; 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 07:33:58PM -0500, Waiman Long wrote:
> 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

Did the readelf give you the paravirt note section?
> linking. Anyway, I will include the unlock call patching code as a separate
> patch as it seems there may be problem under certain circumstance.

one way to troubleshoot those is to enable the paravirt patching code to
actually print where it is patching the code. That way when you load the
module you can confirm it has done its job.

Then you can verify that the address  where the code is called:

ffffffffa06ff395

is indeed patched. You might as well also do a hexdump in the module loading
to confim that the patching had been done correctly.
> 
> 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 Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8v-0004fq-0B; Mon, 01 Dec 2014 22:08:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ8t-0004fL-Fq
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:27 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	DD/8B-22777-AD6EC745; Mon, 01 Dec 2014 22:08:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417471704!3339666!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32232 invoked from network); 1 Dec 2014 22:08:26 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 22:08: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 sB1M8MUl020459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:23 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
	sB1M8M1Z011761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:22 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
	sB1M8LDR019502; Mon, 1 Dec 2014 22:08:21 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:21 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A308311A9E4; Mon,  1 Dec 2014 16:18:36 -0500 (EST)
Date: Mon, 1 Dec 2014 16:18:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141201211836.GJ22021@laptop.dumpdata.com>
References: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417187826-5491-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, tim@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@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

On Fri, Nov 28, 2014 at 03:17:06PM +0000, Julien Grall wrote:
> 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.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 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 Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ94-0004kw-J3; Mon, 01 Dec 2014 22:08:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ92-0004jk-Iq
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:36 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	3A/FA-24124-3E6EC745; Mon, 01 Dec 2014 22:08:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417471714!10922412!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10945 invoked from network); 1 Dec 2014 22:08:35 -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; 1 Dec 2014 22:08:35 -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 sB1M8DZH020261
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:14 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
	sB1M8Car018972
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 1 Dec 2014 22:08:13 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
	sB1M8BfO007156; Mon, 1 Dec 2014 22:08:12 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:11 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E70A911A8F0; Mon,  1 Dec 2014 15:25:45 -0500 (EST)
Date: Mon, 1 Dec 2014 15:25:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141201202545.GB21626@laptop.dumpdata.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>
	<21624.25082.6881.622482@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21624.25082.6881.622482@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>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@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

On Fri, Nov 28, 2014 at 11:52:26AM +0000, Ian Jackson wrote:
> 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.

Correct.

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 Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ9H-0004wV-6c; Mon, 01 Dec 2014 22:08:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ9F-0004uL-Vk
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:50 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	A5/0E-25547-1F6EC745; Mon, 01 Dec 2014 22:08:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417471727!15139568!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10285 invoked from network); 1 Dec 2014 22:08: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; 1 Dec 2014 22:08:48 -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 sB1M8XUV020598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:34 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
	sB1M8WDZ028988
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 1 Dec 2014 22:08:33 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
	sB1M8VcS008003; Mon, 1 Dec 2014 22:08:31 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:31 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BB5D511A68E; Mon,  1 Dec 2014 10:37:59 -0500 (EST)
Date: Mon, 1 Dec 2014 10:37:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Josh Triplett <josh@joshtriplett.org>
Message-ID: <20141201153759.GE3180@laptop.dumpdata.com>
References: <cover.1414870871.git.josh@joshtriplett.org>
	<d50798c4b4860edfed4f95e34b7ffac3e6622aaf.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d50798c4b4860edfed4f95e34b7ffac3e6622aaf.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
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, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [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

On Sun, Nov 02, 2014 at 09:32:20AM -0800, Josh Triplett wrote:
> This will allow making set_iopl_mask optional later.
> 
> Signed-off-by: Josh Triplett <josh@joshtriplett.org>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  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

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8o-0004eJ-Cc; Mon, 01 Dec 2014 22:08: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 1XvZ8m-0004e8-G7
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:20 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	02/42-24859-3D6EC745; Mon, 01 Dec 2014 22:08:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417471697!14971316!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2378 invoked from network); 1 Dec 2014 22:08:19 -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; 1 Dec 2014 22:08: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 sB1M8Aws014628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:11 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
	sB1M89nA027973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:10 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
	sB1M89b6018761; Mon, 1 Dec 2014 22:08:09 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0726211AAD0; Mon,  1 Dec 2014 17:02:42 -0500 (EST)
Date: Mon, 1 Dec 2014 17:02:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201220242.GI24289@laptop.dumpdata.com>
References: <1417444026-31044-1-git-send-email-euan.harris@citrix.com>
	<1417445456.29138.33.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417445456.29138.33.camel@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, Euan Harris <euan.harris@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Don't derefence null new_name
 pointer in libxl_domain_rename()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 02:50:56PM +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 14:27 +0000, Euan Harris wrote:
> > libxl__domain_rename() unconditionally dereferences its new_name
> > parameter, to check whether it is an empty string.   Add a check to
> > avoid a segfault if new_name is null.
> > 
> > Signed-off-by: Euan Harris <euan.harris@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I think this is a good fix to have for 4.5, Konrad CCd.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > ---
> >  tools/libxl/libxl.c |    7 +++++++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f84f7c2..6e84b5d 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -385,6 +385,13 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
> >          }
> >      }
> >  
> > +    if (!new_name) {
> > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                        "new domain name not specified");
> > +        rc = ERROR_INVAL;
> > +        goto x_rc;
> > +    }
> > +
> >      if (new_name[0]) {
> >          /* nonempty names must be unique */
> >          uint32_t domid_e;
> 
> 

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ91-0004jJ-JF; Mon, 01 Dec 2014 22:08:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ90-0004iP-J2
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:34 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	E6/A5-22819-1E6EC745; Mon, 01 Dec 2014 22:08:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417471712!10968138!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9743 invoked from network); 1 Dec 2014 22:08:33 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 22:08: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 sB1M8MPF020458
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:23 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
	sB1M8LpD028552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:22 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
	sB1M8LIQ019472; Mon, 1 Dec 2014 22:08:21 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:20 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 54E0511A684; Mon,  1 Dec 2014 10:33:36 -0500 (EST)
Date: Mon, 1 Dec 2014 10:33:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andy Lutomirski <luto@amacapital.net>
Message-ID: <20141201153336.GB3180@laptop.dumpdata.com>
References: <cover.1414516558.git.luto@amacapital.net>
	<6b0c9b0fc128de68634c730a5b1a80e1d085ad02.1414516558.git.luto@amacapital.net>
	<20141028174629.GA2150@jtriplet-mobl1>
	<CALCETrUihPeKODJqi3tMYwyWYhML1Z=gr4wrVK5VnaFo=KGVJA@mail.gmail.com>
	<20141029200016.GK3424@laptop.dumpdata.com>
	<CALCETrW+f8S9fNrui_J34q3Ve4jwA=neGe-tYZ_Lbp+ML3LiRw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALCETrW+f8S9fNrui_J34q3Ve4jwA=neGe-tYZ_Lbp+ML3LiRw@mail.gmail.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" <xen-devel@lists.xenproject.org>,
	X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Josh Triplett <josh@joshtriplett.org>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/3] x86_64,
	vsyscall: Make vsyscall emulation 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>
Content-Type: text/plain; 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 02:30:29PM -0700, Andy Lutomirski wrote:
> On Oct 29, 2014 1:00 PM, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:
> >
> > On Tue, Oct 28, 2014 at 11:09:53AM -0700, Andy Lutomirski wrote:
> > > On Tue, Oct 28, 2014 at 10:57 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> > > > On Tue, Oct 28, 2014 at 10:22:28AM -0700, Andy Lutomirski wrote:
> > > >> This adds CONFIG_X86_VSYSCALL_EMULATION, guarded by CONFIG_EXPERT.
> > > >> Turning it off completely disables vsyscall emulation, saving ~3.5k
> > > >> for vsyscall_64.c, 4k for vsyscall_emu_64.S (the fake vsyscall
> > > >> page), some tiny amount of core mm code that supports a gate area,
> > > >> and possibly 4k for a wasted pagetable.  The latter is because the
> > > >> vsyscall addresses are misaligned and fit poorly in the fixmap.
> > > >>
> > > >> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> > > >
> > > > One minor nit below, but with or without that change,
> > > > Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> > > >
> > > >> --- a/arch/x86/xen/mmu.c
> > > >> +++ b/arch/x86/xen/mmu.c
> > > >> @@ -1456,11 +1456,13 @@ static int xen_pgd_alloc(struct mm_struct *mm)
> > > >>               user_pgd = (pgd_t *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
> > > >>               page->private = (unsigned long)user_pgd;
> > > >>
> > > >> +#ifdef CONFIG_X86_VSYSCALL_EMULATION
> > > >>               if (user_pgd != NULL) {
> > > >>                       user_pgd[pgd_index(VSYSCALL_ADDR)] =
> > > >>                               __pgd(__pa(level3_user_vsyscall) | _PAGE_TABLE);
> > > >>                       ret = 0;
> > > >>               }
> > > >> +#endif
> > > >
> > > > Could you instead make the if use IS_ENABLED?
> > > >
> > > >                 if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION) && user_pgd != NULL)
> > > >
> > > > That has the advantage of ensuring that the code continues to compile.
> > > > (Given that you haven't removed level3_user_vsyscall, that should work.)
> > >
> > > I need the ret = 0, I think, so I'll resend.
> > >
> > > I think I'd rather use #ifdef here, since I think it would be great if
> > > the Xen people could clean this up further.  With this change, under
> > > some configurations, there should be no user-accessible kernel
> > > addresses at all.  (Also, is there some PV mechanism

What about the vsyscall time stamp (aka kvm-clock). That is not
really VSYSCALL emulation based but normal code?

> > > that I'm not thinking of that will break with this change?  I know
> > > I've tripped over Xen pagetable and fixmap oddities before.)
> >
> > Not that I know of. The vsyscall is the only one that I know of that
> > does this.
> 
> There's kvm-clock, too, but that may never co-exist with Xen.

It will eventually.
> 
> I tagged v2 here:
> 
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/tag/?id=optional-vsyscall-emulation-v2
> 
> and I'll send it out in a bit.
> 
> --Andy
> 
> >
> > Do you have a full patchset somewhere for testing?
> > >
> > > --Andy

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ96-0004mW-12; Mon, 01 Dec 2014 22:08:40 +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 1XvZ94-0004kr-5W
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:38 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	EC/1C-27785-5E6EC745; Mon, 01 Dec 2014 22:08:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417471715!12323098!1
X-Originating-IP: [156.151.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 10294 invoked from network); 1 Dec 2014 22:08:36 -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; 1 Dec 2014 22:08:36 -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 sB1M8U0e015015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08: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
	sB1M8TuM028889
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 1 Dec 2014 22:08:30 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
	sB1M8SgW007914; Mon, 1 Dec 2014 22:08:29 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:28 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 88AD011A70C; Mon,  1 Dec 2014 12:01:51 -0500 (EST)
Date: Mon, 1 Dec 2014 12:01:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141201170151.GK3180@laptop.dumpdata.com>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141201133244.GA24600@aepfle.de>
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] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 02:32:44PM +0100, Olaf Hering wrote:
> On Mon, Dec 01, Olaf Hering wrote:
> 
> > # xl pci-assignable-add 01:10.0
> > # xl pci-assignable-list
> > 0000:01:10.0
> > # xl create -f domU.cfg
> > # xl console domU
> > ## lspci gives just emulated PCI devices
> 
> ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev ff)
> 
> > ## detach from domU console
> > # xl pci-attach domU 0000:01:10.0
> > # xl pci-list domU
> > Vdev Device
> > 04.0 0000:01:10.0
> > 
> > # xl console domU
> > ## lspci gives just emulated PCI devices
> 
> ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 01)
> 
> > ## detach from domU console
> > # xl pci-detach domU 0000:01:10.0
> Now lspci shows that the emulated network card is gone.

> ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 
> > # xl pci-attach domU 0000:01:10.0
> > # xl pci-list domU
> > Vdev Device
> > 04.0 0000:01:10.0
> > # xl console domU
> > ## lspci shows now also the assigned host device
> 
> 
> So the actual bug is that the very first time after pci-attach the guests
> "00:04.0" PCI device is (most likely) replaced with the host PCI device. Just
> the guest does not notice that "00:04.0" was actually already gone after unplug.

That is odd - I see any device 'hot-plugged' being added at 00:05 and further.

> 
> I wonder why the unplug code in xen_platform.c does just a qdev_free() instead
> of a real pci-detach kind of thing. I'm sure this could be done at least for
> emulated network cards.
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8v-0004g0-Bv; Mon, 01 Dec 2014 22:08: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 1XvZ8u-0004fH-D1
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:28 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	E3/35-02696-AD6EC745; Mon, 01 Dec 2014 22:08:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417471704!12316729!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18758 invoked from network); 1 Dec 2014 22:08:25 -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; 1 Dec 2014 22:08: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 sB1M8KAh020393
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:21 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
	sB1M8JPL011637
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:20 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
	sB1M8I90019335; Mon, 1 Dec 2014 22:08:18 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:18 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2C2BF11AAB8; Mon,  1 Dec 2014 16:59:28 -0500 (EST)
Date: Mon, 1 Dec 2014 16:59:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141201215927.GH24289@laptop.dumpdata.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
	<1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
	<547C77E0.5060607@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C77E0.5060607@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: bhelgaas@google.com, xen-devel@lists.xenproject.org, linux@eikelenboom.it,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 02:14:56PM +0000, David Vrabel wrote:
> On 21/11/14 22:17, Konrad Rzeszutek Wilk wrote:
> > 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");
> 
> Why dev_info when...
> 
> > @@ -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");
> 
> ... this one is dev_warn?

Should be the same, dev_info I think?
> 
> > +	else {
> > +		__pci_reset_function_locked(dev);
> 
> I think the reset should always be attempted regardless of whether the
> correct state was loaded or not.

/me nods. Will redo it as such.
> 
> David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ99-0004pT-GB; Mon, 01 Dec 2014 22:08: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 1XvZ98-0004ng-4U
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:42 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	95/CF-26652-9E6EC745; Mon, 01 Dec 2014 22:08:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417471719!10903756!1
X-Originating-IP: [156.151.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 7787 invoked from network); 1 Dec 2014 22:08:40 -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; 1 Dec 2014 22:08:40 -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 sB1M8ISI014796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:19 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
	sB1M8H2N028384
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:18 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
	sB1M8HRS011563; Mon, 1 Dec 2014 22:08:17 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A802F11AA32; Mon,  1 Dec 2014 16:35:18 -0500 (EST)
Date: Mon, 1 Dec 2014 16:35:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: greg@enjellic.com, tiejun.chen@intel.com
Message-ID: <20141201213518.GB24289@laptop.dumpdata.com>
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.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
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.
> 
> > > 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.

CC-ing Chien who has been looking at adding IGD passthrough support
in the qemu-upstream. Perhaps he can provide some ideas.

Thanks.
> 
> > 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 Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8y-0004h9-Oh; Mon, 01 Dec 2014 22:08:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ8x-0004gK-1M
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:31 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	BD/85-09284-ED6EC745; Mon, 01 Dec 2014 22:08:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417471708!15121907!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15022 invoked from network); 1 Dec 2014 22:08:29 -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; 1 Dec 2014 22:08: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 sB1M8QxD020492
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08: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
	sB1M8PHu028712
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:26 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
	sB1M8PLB019681; Mon, 1 Dec 2014 22:08:25 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:25 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4B6C111AA97; Mon,  1 Dec 2014 16:54:16 -0500 (EST)
Date: Mon, 1 Dec 2014 16:54:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141201215416.GF24289@laptop.dumpdata.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417433473-17272-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 v2 for-4.5 0/2] xl/libxl: fix API and 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

On Mon, Dec 01, 2014 at 11:31:11AM +0000, Wei Liu wrote:
> Return value of libxl_basename was erroneously marked as "const". This
> series removes that "const" and fixes two memory leaks in xl.
> 
> I think these fixes should be included in 4.5, given that they fix real
> issues and are very straight foward to reason about.

Thank you for catching those!

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Wei.
> 
> Wei Liu (2):
>   libxl: un-constify return value of libxl_basename
>   xl: fix two memory leaks
> 
>  tools/libxl/libxl.h       |   10 ++++++++++
>  tools/libxl/libxl_utils.c |    5 ++++-
>  tools/libxl/libxl_utils.h |    6 +++++-
>  tools/libxl/xl_cmdimpl.c  |    8 ++++++--
>  4 files changed, 25 insertions(+), 4 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 Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8z-0004hs-JO; Mon, 01 Dec 2014 22:08:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ8y-0004gf-5R
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:32 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	ED/EE-29352-FD6EC745; Mon, 01 Dec 2014 22:08:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417471709!10914939!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20827 invoked from network); 1 Dec 2014 22:08:30 -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; 1 Dec 2014 22:08: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 sB1M8Qrh020489
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08: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
	sB1M8P7m028708
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:26 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
	sB1M8Pfo028702; Mon, 1 Dec 2014 22:08:25 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:25 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 48DB611AA83; Mon,  1 Dec 2014 16:51:12 -0500 (EST)
Date: Mon, 1 Dec 2014 16:51:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201215112.GE24289@laptop.dumpdata.com>
References: <1417154122-23669-1-git-send-email-cyliu@suse.com>
	<1417176083.23604.20.camel@citrix.com>
	<547CBFB80200006600040E25@soto.provo.novell.com>
	<1417425684.23604.70.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425684.23604.70.camel@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, ian.jackson@eu.citrix.com,
	Chun Yan Liu <cyliu@suse.com>, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] =?utf-8?b?562U5aSN77yaIFJlOiBbUEFUQ0hdIG1pc3Npbmcg?=
 =?utf-8?q?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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBEZWMgMDEsIDIwMTQgYXQgMDk6MjE6MjRBTSArMDAwMCwgSWFuIENhbXBiZWxsIHdy
b3RlOgo+IE9uIE1vbiwgMjAxNC0xMi0wMSBhdCAwMToyMSAtMDcwMCwgQ2h1biBZYW4gTGl1IHdy
b3RlOgo+ID4gCj4gPiA+Pj4gSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT4g
MjAxNC0xMS0yOCDkuIvljYggMjA6MDEgPj4+IAo+ID4gT24gRnJpLCAyMDE0LTExLTI4IGF0IDEz
OjU1ICswODAwLCBDaHVueWFuIExpdSB3cm90ZTogCj4gPiA+PiBGb3VuZCBieSBTdGVmYW5vLCB0
aGlzIGNodW5rIG9mIHRoZSBwYXRjaCB3YXMgbmV2ZXIgYXBwbGllZCB0byAKPiA+ID4+IHhlbi11
bnN0YWJsZSAoY29tbWl0IDExZGZmYTIzNTllOGEyNjI5NDkwYzE0YzAyOWM3YzdjNzc3YjNlNDcp
LCAKPiA+ID4+IHNlZSBodHRwOi8vbWFyYy5pbmZvLz9sPXFlbXUtZGV2ZWwmbT0xNDA0NzE0OTM0
MjUzNTMmdz0yLiAKPiA+ID4KPiA+ID4gSG93IHN0cmFuZ2UsICJnaXQgYW0iIHVzdWFsbHkgbWFr
ZXMgaXQgcHJldHR5IGRpZmZpY3VsdCB0byBtaXNzIGh1bmtzLiAKPiA+ID4gU29ycnkgYWJvdXQg
dGhpcy4gCj4gPiAKPiA+ID4+IFNpZ25lZC1vZmYtYnk6IENodW55YW4gTGl1IDxjeWxpdUBzdXNl
LmNvbT4gCj4gPiAKPiA+ID4gQWNrZWQtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNp
dHJpeC5jb20+IAo+ID4gCj4gPiA+IEknbSBhZnJhaWQgdGhhdCBkZXNwaXRlIHRoZSBjaXJjdW1z
dGFuY2VzIHRoaXMgc3RpbGwgbmVlZHMgYSByZWxlYXNlIGFjayAKPiA+ID4gZnJvbSBLb25yYWQu
IE9idmlvdXNseSB0aGUgdXBzaWRlIGlzIGZpeGluZyBhIHBhcnRpYWxseSBpbXBsZW1lbnRlZCAK
PiA+ID4gZmVhdHVyZSwgYnV0IEknbSBub3Qgc3VyZSB3aGF0IHRoZSBkb3duc2lkZXMgYXJlLiAK
PiA+ID4KPiA+ID4gSGFzIHRoaXMgYmVlbiB0ZXN0ZWQgd2l0aCBzdHViZG9tcywgaW5jbHVkaW5n
IHdoZW4gdGhpcyBmZWF0dXJlIGlzIG5vdCAKPiA+ID4gdXNlZD8gTXkgYmlnZ2VzdCBjb25jZXJu
IGlzIHRoYXQgYmVjYXVzZSB0aGlzIGZ1bmN0aW9uIGlzIGFsc28gdXNlZCB0byAKPiA+ID4gYnVp
bGQgdGhlIGNvbW1hbmQgbGluZSBmb3IgdGhlIHN0dWJkb20gYW5kIHRoZSBzdHViZG9tIGlzIFBW
IGFuZCBoZW5jZSAKPiA+ID4gaGFzIGF0IGxlYXN0IGEgLT5rZXJuZWwgc2V0dGluZyB0aGVuIHRo
aXMgbmV3IGNvZGUgbWlnaHQgYnJlYWsgdGhhdCB1c2UgCj4gPiA+IGNhc2UsIGJ5IGFkZGluZyB0
aGVzZSBvcHRpb25zIHdoZW4gdGhleSBhcmUgbm90IHdhbnRlZC4gVGhpcyBwYXRoIGlzIGFsbCAK
PiA+ID4gYSBiaXQgdGFuZ2xlZCBzbyBJJ20gbm90IDEwMCUgc3VyZSBpZiB0aG9zZSBmaWVsZHMg
YXJlIGFjdHVhbGx5IHNldCBvciAKPiA+ID4gbm90Lgo+ID4gCj4gPiAKPiA+IAo+ID4gJy1rZXJu
ZWwnIGlzIG9ubHkgYWRkZWQgdG8gcWVtdSBjb21tYW5kIGxpbmUgdW5kZXIgSFZNIGNhc2UuIFBW
IHdvdWxkCj4gPiAKPiA+IG5vdCBiZSBhZmZlY3RlZC4gQW5kIG9ubHkgYWRkZWQgd2hlbiBkZXZp
Y2UgbW9kZWwgaXMgdXBzdHJlYW0gcWVtdSwgYnV0Cj4gPiAKPiA+IG5vdCBvbGQgcWVtdS14ZW4u
IEFib3V0IHN0dWJkb20sIHRlc3RlZCBiZWZvcmUsIHdoZW4gc3R1YmRvbSBpcyB1c2luZwo+IAo+
ID4gb2xkIHFlbXUteGVuLCB3b3VsZCBub3QgYmUgYWZmZWN0ZWQuCj4gCj4gQWggeWVzLCBJJ2Qg
Zm9yZ290dGVuIHdlIGRpZG4ndCBoYXZlIHVwc3RyZWFtIHN0dWJkb20geWV0LCBvYnZpb3VzbHkg
YW55Cj4gaXNzdWVzIGhlcmUgd2lsbCBiZWNvbWUgYXBwYXJlbnQgd2hlbmV2ZXIgdGhhdCBnZXRz
IGltcGxlbWVudGVkLgoKPG5vZHM+CgpSZWxlYXNlLUFja2VkLWJ5OiBLb25yYWQgUnplc3p1dGVr
IFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+Cj4gCj4gSWFuLgo+IAo+IAoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8z-0004hs-JO; Mon, 01 Dec 2014 22:08:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ8y-0004gf-5R
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:32 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	ED/EE-29352-FD6EC745; Mon, 01 Dec 2014 22:08:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417471709!10914939!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20827 invoked from network); 1 Dec 2014 22:08:30 -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; 1 Dec 2014 22:08: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 sB1M8Qrh020489
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08: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
	sB1M8P7m028708
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:26 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
	sB1M8Pfo028702; Mon, 1 Dec 2014 22:08:25 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:25 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 48DB611AA83; Mon,  1 Dec 2014 16:51:12 -0500 (EST)
Date: Mon, 1 Dec 2014 16:51:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201215112.GE24289@laptop.dumpdata.com>
References: <1417154122-23669-1-git-send-email-cyliu@suse.com>
	<1417176083.23604.20.camel@citrix.com>
	<547CBFB80200006600040E25@soto.provo.novell.com>
	<1417425684.23604.70.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425684.23604.70.camel@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, ian.jackson@eu.citrix.com,
	Chun Yan Liu <cyliu@suse.com>, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] =?utf-8?b?562U5aSN77yaIFJlOiBbUEFUQ0hdIG1pc3Npbmcg?=
 =?utf-8?q?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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBEZWMgMDEsIDIwMTQgYXQgMDk6MjE6MjRBTSArMDAwMCwgSWFuIENhbXBiZWxsIHdy
b3RlOgo+IE9uIE1vbiwgMjAxNC0xMi0wMSBhdCAwMToyMSAtMDcwMCwgQ2h1biBZYW4gTGl1IHdy
b3RlOgo+ID4gCj4gPiA+Pj4gSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT4g
MjAxNC0xMS0yOCDkuIvljYggMjA6MDEgPj4+IAo+ID4gT24gRnJpLCAyMDE0LTExLTI4IGF0IDEz
OjU1ICswODAwLCBDaHVueWFuIExpdSB3cm90ZTogCj4gPiA+PiBGb3VuZCBieSBTdGVmYW5vLCB0
aGlzIGNodW5rIG9mIHRoZSBwYXRjaCB3YXMgbmV2ZXIgYXBwbGllZCB0byAKPiA+ID4+IHhlbi11
bnN0YWJsZSAoY29tbWl0IDExZGZmYTIzNTllOGEyNjI5NDkwYzE0YzAyOWM3YzdjNzc3YjNlNDcp
LCAKPiA+ID4+IHNlZSBodHRwOi8vbWFyYy5pbmZvLz9sPXFlbXUtZGV2ZWwmbT0xNDA0NzE0OTM0
MjUzNTMmdz0yLiAKPiA+ID4KPiA+ID4gSG93IHN0cmFuZ2UsICJnaXQgYW0iIHVzdWFsbHkgbWFr
ZXMgaXQgcHJldHR5IGRpZmZpY3VsdCB0byBtaXNzIGh1bmtzLiAKPiA+ID4gU29ycnkgYWJvdXQg
dGhpcy4gCj4gPiAKPiA+ID4+IFNpZ25lZC1vZmYtYnk6IENodW55YW4gTGl1IDxjeWxpdUBzdXNl
LmNvbT4gCj4gPiAKPiA+ID4gQWNrZWQtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNp
dHJpeC5jb20+IAo+ID4gCj4gPiA+IEknbSBhZnJhaWQgdGhhdCBkZXNwaXRlIHRoZSBjaXJjdW1z
dGFuY2VzIHRoaXMgc3RpbGwgbmVlZHMgYSByZWxlYXNlIGFjayAKPiA+ID4gZnJvbSBLb25yYWQu
IE9idmlvdXNseSB0aGUgdXBzaWRlIGlzIGZpeGluZyBhIHBhcnRpYWxseSBpbXBsZW1lbnRlZCAK
PiA+ID4gZmVhdHVyZSwgYnV0IEknbSBub3Qgc3VyZSB3aGF0IHRoZSBkb3duc2lkZXMgYXJlLiAK
PiA+ID4KPiA+ID4gSGFzIHRoaXMgYmVlbiB0ZXN0ZWQgd2l0aCBzdHViZG9tcywgaW5jbHVkaW5n
IHdoZW4gdGhpcyBmZWF0dXJlIGlzIG5vdCAKPiA+ID4gdXNlZD8gTXkgYmlnZ2VzdCBjb25jZXJu
IGlzIHRoYXQgYmVjYXVzZSB0aGlzIGZ1bmN0aW9uIGlzIGFsc28gdXNlZCB0byAKPiA+ID4gYnVp
bGQgdGhlIGNvbW1hbmQgbGluZSBmb3IgdGhlIHN0dWJkb20gYW5kIHRoZSBzdHViZG9tIGlzIFBW
IGFuZCBoZW5jZSAKPiA+ID4gaGFzIGF0IGxlYXN0IGEgLT5rZXJuZWwgc2V0dGluZyB0aGVuIHRo
aXMgbmV3IGNvZGUgbWlnaHQgYnJlYWsgdGhhdCB1c2UgCj4gPiA+IGNhc2UsIGJ5IGFkZGluZyB0
aGVzZSBvcHRpb25zIHdoZW4gdGhleSBhcmUgbm90IHdhbnRlZC4gVGhpcyBwYXRoIGlzIGFsbCAK
PiA+ID4gYSBiaXQgdGFuZ2xlZCBzbyBJJ20gbm90IDEwMCUgc3VyZSBpZiB0aG9zZSBmaWVsZHMg
YXJlIGFjdHVhbGx5IHNldCBvciAKPiA+ID4gbm90Lgo+ID4gCj4gPiAKPiA+IAo+ID4gJy1rZXJu
ZWwnIGlzIG9ubHkgYWRkZWQgdG8gcWVtdSBjb21tYW5kIGxpbmUgdW5kZXIgSFZNIGNhc2UuIFBW
IHdvdWxkCj4gPiAKPiA+IG5vdCBiZSBhZmZlY3RlZC4gQW5kIG9ubHkgYWRkZWQgd2hlbiBkZXZp
Y2UgbW9kZWwgaXMgdXBzdHJlYW0gcWVtdSwgYnV0Cj4gPiAKPiA+IG5vdCBvbGQgcWVtdS14ZW4u
IEFib3V0IHN0dWJkb20sIHRlc3RlZCBiZWZvcmUsIHdoZW4gc3R1YmRvbSBpcyB1c2luZwo+IAo+
ID4gb2xkIHFlbXUteGVuLCB3b3VsZCBub3QgYmUgYWZmZWN0ZWQuCj4gCj4gQWggeWVzLCBJJ2Qg
Zm9yZ290dGVuIHdlIGRpZG4ndCBoYXZlIHVwc3RyZWFtIHN0dWJkb20geWV0LCBvYnZpb3VzbHkg
YW55Cj4gaXNzdWVzIGhlcmUgd2lsbCBiZWNvbWUgYXBwYXJlbnQgd2hlbmV2ZXIgdGhhdCBnZXRz
IGltcGxlbWVudGVkLgoKPG5vZHM+CgpSZWxlYXNlLUFja2VkLWJ5OiBLb25yYWQgUnplc3p1dGVr
IFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+Cj4gCj4gSWFuLgo+IAo+IAoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8q-0004eg-2y; Mon, 01 Dec 2014 22:08:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ8o-0004eI-FH
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:22 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	DD/75-22819-5D6EC745; Mon, 01 Dec 2014 22:08:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417471699!3339658!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31622 invoked from network); 1 Dec 2014 22:08:21 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 22:08: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 sB1M8FB5020295
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08: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
	sB1M8E7c019095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:15 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
	sB1M8EeS019049; Mon, 1 Dec 2014 22:08:14 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:13 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3C24E11A9C6; Mon,  1 Dec 2014 16:14:32 -0500 (EST)
Date: Mon, 1 Dec 2014 16:14:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141201211431.GG22021@laptop.dumpdata.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-4-git-send-email-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417091674-8163-4-git-send-email-andrew.cooper3@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>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@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, Nov 27, 2014 at 12:34:34PM +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>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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))
> -- 
> 1.7.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 Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8v-0004g0-Bv; Mon, 01 Dec 2014 22:08: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 1XvZ8u-0004fH-D1
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:28 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	E3/35-02696-AD6EC745; Mon, 01 Dec 2014 22:08:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417471704!12316729!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18758 invoked from network); 1 Dec 2014 22:08:25 -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; 1 Dec 2014 22:08: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 sB1M8KAh020393
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:21 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
	sB1M8JPL011637
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:20 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
	sB1M8I90019335; Mon, 1 Dec 2014 22:08:18 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:18 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2C2BF11AAB8; Mon,  1 Dec 2014 16:59:28 -0500 (EST)
Date: Mon, 1 Dec 2014 16:59:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141201215927.GH24289@laptop.dumpdata.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
	<1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
	<547C77E0.5060607@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C77E0.5060607@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: bhelgaas@google.com, xen-devel@lists.xenproject.org, linux@eikelenboom.it,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 02:14:56PM +0000, David Vrabel wrote:
> On 21/11/14 22:17, Konrad Rzeszutek Wilk wrote:
> > 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");
> 
> Why dev_info when...
> 
> > @@ -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");
> 
> ... this one is dev_warn?

Should be the same, dev_info I think?
> 
> > +	else {
> > +		__pci_reset_function_locked(dev);
> 
> I think the reset should always be attempted regardless of whether the
> correct state was loaded or not.

/me nods. Will redo it as such.
> 
> David

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ96-0004mW-12; Mon, 01 Dec 2014 22:08:40 +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 1XvZ94-0004kr-5W
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:38 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	EC/1C-27785-5E6EC745; Mon, 01 Dec 2014 22:08:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417471715!12323098!1
X-Originating-IP: [156.151.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 10294 invoked from network); 1 Dec 2014 22:08:36 -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; 1 Dec 2014 22:08:36 -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 sB1M8U0e015015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08: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
	sB1M8TuM028889
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 1 Dec 2014 22:08:30 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
	sB1M8SgW007914; Mon, 1 Dec 2014 22:08:29 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:28 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 88AD011A70C; Mon,  1 Dec 2014 12:01:51 -0500 (EST)
Date: Mon, 1 Dec 2014 12:01:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141201170151.GK3180@laptop.dumpdata.com>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141201133244.GA24600@aepfle.de>
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] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 02:32:44PM +0100, Olaf Hering wrote:
> On Mon, Dec 01, Olaf Hering wrote:
> 
> > # xl pci-assignable-add 01:10.0
> > # xl pci-assignable-list
> > 0000:01:10.0
> > # xl create -f domU.cfg
> > # xl console domU
> > ## lspci gives just emulated PCI devices
> 
> ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev ff)
> 
> > ## detach from domU console
> > # xl pci-attach domU 0000:01:10.0
> > # xl pci-list domU
> > Vdev Device
> > 04.0 0000:01:10.0
> > 
> > # xl console domU
> > ## lspci gives just emulated PCI devices
> 
> ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 01)
> 
> > ## detach from domU console
> > # xl pci-detach domU 0000:01:10.0
> Now lspci shows that the emulated network card is gone.

> ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 
> > # xl pci-attach domU 0000:01:10.0
> > # xl pci-list domU
> > Vdev Device
> > 04.0 0000:01:10.0
> > # xl console domU
> > ## lspci shows now also the assigned host device
> 
> 
> So the actual bug is that the very first time after pci-attach the guests
> "00:04.0" PCI device is (most likely) replaced with the host PCI device. Just
> the guest does not notice that "00:04.0" was actually already gone after unplug.

That is odd - I see any device 'hot-plugged' being added at 00:05 and further.

> 
> I wonder why the unplug code in xen_platform.c does just a qdev_free() instead
> of a real pci-detach kind of thing. I'm sure this could be done at least for
> emulated network cards.
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8q-0004en-Ef; Mon, 01 Dec 2014 22:08:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ8p-0004eS-2e
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:23 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B5/50-22737-6D6EC745; Mon, 01 Dec 2014 22:08:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417471700!5630820!1
X-Originating-IP: [156.151.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 28887 invoked from network); 1 Dec 2014 22:08:21 -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; 1 Dec 2014 22:08:21 -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 sB1M8Jd6014804
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Mon, 1 Dec 2014 22:08:19 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
	sB1M8IeU007463
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xenproject.org>; Mon, 1 Dec 2014 22:08:19 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
	sB1M8IWJ028407
	for <xen-devel@lists.xenproject.org>; Mon, 1 Dec 2014 22:08:18 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:18 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2DF3411A688; Mon,  1 Dec 2014 10:36:57 -0500 (EST)
Date: Mon, 1 Dec 2014 10:36:57 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Message-ID: <20141201153657.GC3180@laptop.dumpdata.com>
References: <20141031153000.GA19229@mwanda>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141031153000.GA19229@mwanda>
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
Subject: Re: [Xen-devel] xen/pciback: Drop two backends,
	squash and cleanup some code.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 31, 2014 at 06:30:01PM +0300, Dan Carpenter wrote:
> Hello Konrad Rzeszutek Wilk,
> 
> The patch a92336a1176b: "xen/pciback: Drop two backends, squash and
> cleanup some code." from Jul 19, 2011, leads to the following static
> checker warning:
> 
> 	drivers/xen/xen-pciback/conf_space_capability.c:163 pm_ctrl_init()
> 	error: passing non negative 135 to ERR_PTR
> 
> drivers/xen/xen-pciback/conf_space_capability.c
>    147  /* Ensure PMEs are disabled */
>    148  static void *pm_ctrl_init(struct pci_dev *dev, int offset)
>    149  {
>    150          int err;
>    151          u16 value;
>    152  
>    153          err = pci_read_config_word(dev, offset, &value);
>    154          if (err)
>    155                  goto out;
>    156  
>    157          if (value & PCI_PM_CTRL_PME_ENABLE) {
>    158                  value &= ~PCI_PM_CTRL_PME_ENABLE;
>    159                  err = pci_write_config_word(dev, offset, value);
> 
> The static check is complaining that pci_write_config_word() can
> return PCIBIOS_BAD_REGISTER_NUMBER, but actually I think that's not
> possible.
> 
> Anyway, this function is only called from
> xen_pcibk_config_add_field_offset() so why are we returning a pointer
> instead of just int?

Because all the other 'init' could. And 'bar_init' for example
returns the BAR value (wrapped in 'struct pci_bar_info').
> 
>    160          }
>    161  
>    162  out:
>    163          return ERR_PTR(err);
>    164  }
> 
> regards,
> dan carpenter

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ9F-0004tx-1w; Mon, 01 Dec 2014 22:08:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ9D-0004sa-QV
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:48 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	47/D3-02699-FE6EC745; Mon, 01 Dec 2014 22:08:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417471725!12301546!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9858 invoked from network); 1 Dec 2014 22:08:46 -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; 1 Dec 2014 22:08:46 -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 sB1M82xp020039
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:03 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
	sB1M80uY018085
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:01 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
	sB1M80pH027266; Mon, 1 Dec 2014 22:08:00 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:00 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id DDD6011A6E4; Mon,  1 Dec 2014 11:40:35 -0500 (EST)
Date: Mon, 1 Dec 2014 11:40:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Waiman Long <Waiman.Long@hp.com>
Message-ID: <20141201164035.GF3180@laptop.dumpdata.com>
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.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
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 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:
> This patch adds para-virtualization support to the queue spinlock
> code base with minimal impact to the native case. There are some
> minor code changes in the generic qspinlock.c file which should be
> usable in other architectures. The other code changes are specific
> to x86 processors and so are all put under the arch/x86 directory.
> 
> On the lock side, the slowpath code is split into 2 separate functions
> generated from the same code - one for bare metal and one for PV guest.
> The switching is done in the _raw_spin_lock* functions. This makes
> sure that the performance impact to the bare metal case is minimal,
> just a few NOPs in the _raw_spin_lock* functions. In the PV slowpath
> code, there are 2 paravirt callee saved calls that minimize register
> pressure.
> 
> On the unlock side, however, the disabling of unlock function inlining
> does have some slight impact on bare metal performance.
> 
> The actual paravirt code comes in 5 parts;
> 
>  - init_node; this initializes the extra data members required for PV
>    state. PV state data is kept 1 cacheline ahead of the regular data.
> 
>  - link_and_wait_node; this replaces the regular MCS queuing code. CPU
>    halting can happen if the wait is too long.
> 
>  - wait_head; this waits until the lock is avialable and the CPU will
>    be halted if the wait is too long.
> 
>  - wait_check; this is called after acquiring the lock to see if the
>    next queue head CPU is halted. If this is the case, the lock bit is
>    changed to indicate the queue head will have to be kicked on unlock.
> 
>  - queue_unlock;  this routine has a jump label to check if paravirt
>    is enabled. If yes, it has to do an atomic cmpxchg to clear the lock
>    bit or call the slowpath function to kick the queue head cpu.
> 
> Tracking the head is done in two parts, firstly the pv_wait_head will
> store its cpu number in whichever node is pointed to by the tail part
> of the lock word. Secondly, pv_link_and_wait_node() will propagate the
> existing head from the old to the new tail node.
> 
> Signed-off-by: Waiman Long <Waiman.Long@hp.com>
> ---
>  arch/x86/include/asm/paravirt.h       |   19 ++
>  arch/x86/include/asm/paravirt_types.h |   20 ++
>  arch/x86/include/asm/pvqspinlock.h    |  411 +++++++++++++++++++++++++++++++++
>  arch/x86/include/asm/qspinlock.h      |   71 ++++++-
>  arch/x86/kernel/paravirt-spinlocks.c  |    6 +
>  include/asm-generic/qspinlock.h       |    2 +
>  kernel/locking/qspinlock.c            |   69 +++++-
>  7 files changed, 591 insertions(+), 7 deletions(-)
>  create mode 100644 arch/x86/include/asm/pvqspinlock.h
> 
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index cd6e161..7e296e6 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -712,6 +712,24 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
>  
>  #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS)
>  
> +#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);
> +}
> +
> +#else
>  static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
>  							__ticket_t ticket)
>  {
> @@ -723,6 +741,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
>  {
>  	PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket);
>  }
> +#endif
>  
>  #endif
>  
> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> index 7549b8b..49e4b76 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -326,6 +326,9 @@ struct pv_mmu_ops {
>  			   phys_addr_t phys, pgprot_t flags);
>  };
>  
> +struct mcs_spinlock;
> +struct qspinlock;
> +
>  struct arch_spinlock;
>  #ifdef CONFIG_SMP
>  #include <asm/spinlock_types.h>
> @@ -333,9 +336,26 @@ struct arch_spinlock;
>  typedef u16 __ticket_t;
>  #endif
>  
> +#ifdef CONFIG_QUEUE_SPINLOCK
> +enum pv_lock_stats {
> +	PV_HALT_QHEAD,		/* Queue head halting	    */
> +	PV_HALT_QNODE,		/* Other queue node halting */
> +	PV_HALT_ABORT,		/* Halting aborted	    */
> +	PV_WAKE_KICKED,		/* Wakeup by kicking	    */
> +	PV_WAKE_SPURIOUS,	/* Spurious wakeup	    */
> +	PV_KICK_NOHALT		/* Kick but CPU not halted  */
> +};
> +#endif
> +
>  struct pv_lock_ops {
> +#ifdef CONFIG_QUEUE_SPINLOCK
> +	struct paravirt_callee_save kick_cpu;
> +	struct paravirt_callee_save lockstat;
> +	struct paravirt_callee_save lockwait;
> +#else
>  	struct paravirt_callee_save lock_spinning;
>  	void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket);
> +#endif
>  };
>  
>  /* This contains all the paravirt structures: we get a convenient
> diff --git a/arch/x86/include/asm/pvqspinlock.h b/arch/x86/include/asm/pvqspinlock.h
> new file mode 100644
> index 0000000..85ccde6
> --- /dev/null
> +++ b/arch/x86/include/asm/pvqspinlock.h
> @@ -0,0 +1,411 @@
> +#ifndef _ASM_X86_PVQSPINLOCK_H
> +#define _ASM_X86_PVQSPINLOCK_H
> +
> +/*
> + *	Queue Spinlock Para-Virtualization (PV) Support
> + *
> + * The PV support code for queue spinlock is roughly the same as that
> + * of the ticket spinlock. 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.

Kind of. There is a lot more of going to sleep here than the PV ticketlock.
In there the CPU would go to sleep and wait until it was its turn in. Here
we need go to sleep when we are at the queue and then wake up to move a bit.

That means the next in the line has at least two halt and wakeups?

How does it compare to the PV ticketlocks that exists right now?

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ9F-0004uM-FW; Mon, 01 Dec 2014 22:08:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ9E-0004t2-Bf
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:48 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	0D/C8-02698-FE6EC745; Mon, 01 Dec 2014 22:08:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417471725!12312222!1
X-Originating-IP: [156.151.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 28613 invoked from network); 1 Dec 2014 22:08: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; 1 Dec 2014 22:08: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 sB1M8PbL014927
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:26 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
	sB1M8Pj7007747
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:25 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
	sB1M8OxF011867; Mon, 1 Dec 2014 22:08:24 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:24 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 69D7011A9B7; Mon,  1 Dec 2014 16:11:18 -0500 (EST)
Date: Mon, 1 Dec 2014 16:11:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201211117.GF22021@laptop.dumpdata.com>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com>
	<1417176581.23604.25.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417176581.23604.25.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Wei Liu <wei.liu2@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,
	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 Fri, Nov 28, 2014 at 12:09:41PM +0000, Ian Campbell wrote:
> 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...

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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));
> > >  
> > 
> 
> 

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ99-0004pT-GB; Mon, 01 Dec 2014 22:08: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 1XvZ98-0004ng-4U
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:42 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	95/CF-26652-9E6EC745; Mon, 01 Dec 2014 22:08:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417471719!10903756!1
X-Originating-IP: [156.151.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 7787 invoked from network); 1 Dec 2014 22:08:40 -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; 1 Dec 2014 22:08:40 -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 sB1M8ISI014796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:19 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
	sB1M8H2N028384
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:18 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
	sB1M8HRS011563; Mon, 1 Dec 2014 22:08:17 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A802F11AA32; Mon,  1 Dec 2014 16:35:18 -0500 (EST)
Date: Mon, 1 Dec 2014 16:35:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: greg@enjellic.com, tiejun.chen@intel.com
Message-ID: <20141201213518.GB24289@laptop.dumpdata.com>
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.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
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.
> 
> > > 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.

CC-ing Chien who has been looking at adding IGD passthrough support
in the qemu-upstream. Perhaps he can provide some ideas.

Thanks.
> 
> > 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 Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ9H-0004xE-Le; Mon, 01 Dec 2014 22:08: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 1XvZ9G-0004uf-4K
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:50 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	78/33-02699-1F6EC745; Mon, 01 Dec 2014 22:08:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417471727!7665034!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17642 invoked from network); 1 Dec 2014 22:08:48 -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; 1 Dec 2014 22:08:48 -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 sB1M8DgH020257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:14 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
	sB1M8CFD011343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:13 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
	sB1M8CeG011332; Mon, 1 Dec 2014 22:08:12 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:12 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EF1DC11A6F0; Mon,  1 Dec 2014 11:51:55 -0500 (EST)
Date: Mon, 1 Dec 2014 11:51:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Waiman Long <waiman.long@hp.com>
Message-ID: <20141201165155.GH3180@laptop.dumpdata.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>
	<54751FF6.5050808@hp.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54751FF6.5050808@hp.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
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-Type: text/plain; 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 07:33:58PM -0500, Waiman Long wrote:
> 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

Did the readelf give you the paravirt note section?
> linking. Anyway, I will include the unlock call patching code as a separate
> patch as it seems there may be problem under certain circumstance.

one way to troubleshoot those is to enable the paravirt patching code to
actually print where it is patching the code. That way when you load the
module you can confirm it has done its job.

Then you can verify that the address  where the code is called:

ffffffffa06ff395

is indeed patched. You might as well also do a hexdump in the module loading
to confim that the patching had been done correctly.
> 
> 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 Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8o-0004eV-Na; Mon, 01 Dec 2014 22:08: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 1XvZ8m-0004e9-GV
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:20 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	5B/60-17735-3D6EC745; Mon, 01 Dec 2014 22:08:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417471697!15139511!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9219 invoked from network); 1 Dec 2014 22:08:19 -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; 1 Dec 2014 22:08:19 -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 sB1M8DHC020246
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:13 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
	sB1M8BuI018918
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:12 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
	sB1M8BSf028063; Mon, 1 Dec 2014 22:08:11 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:11 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 38AE411A908; Mon,  1 Dec 2014 15:30:01 -0500 (EST)
Date: Mon, 1 Dec 2014 15:30:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201203001.GE21626@laptop.dumpdata.com>
References: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417174284.23604.9.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417174284.23604.9.camel@citrix.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, Boris Ostrovsky <boris.ostrovsky@oracle.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 Fri, Nov 28, 2014 at 11:31:24AM +0000, Ian Campbell wrote:
> 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.

I am bit lost. I thought Andrew NACKed this?

> 
> > ---
> > 
> > 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 Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ94-0004kw-J3; Mon, 01 Dec 2014 22:08:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ92-0004jk-Iq
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:36 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	3A/FA-24124-3E6EC745; Mon, 01 Dec 2014 22:08:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417471714!10922412!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10945 invoked from network); 1 Dec 2014 22:08:35 -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; 1 Dec 2014 22:08:35 -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 sB1M8DZH020261
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:14 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
	sB1M8Car018972
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 1 Dec 2014 22:08:13 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
	sB1M8BfO007156; Mon, 1 Dec 2014 22:08:12 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:11 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E70A911A8F0; Mon,  1 Dec 2014 15:25:45 -0500 (EST)
Date: Mon, 1 Dec 2014 15:25:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141201202545.GB21626@laptop.dumpdata.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>
	<21624.25082.6881.622482@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21624.25082.6881.622482@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>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@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

On Fri, Nov 28, 2014 at 11:52:26AM +0000, Ian Jackson wrote:
> 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.

Correct.

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 Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ9F-0004tx-1w; Mon, 01 Dec 2014 22:08:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ9D-0004sa-QV
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:48 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	47/D3-02699-FE6EC745; Mon, 01 Dec 2014 22:08:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417471725!12301546!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9858 invoked from network); 1 Dec 2014 22:08:46 -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; 1 Dec 2014 22:08:46 -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 sB1M82xp020039
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:03 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
	sB1M80uY018085
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:01 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
	sB1M80pH027266; Mon, 1 Dec 2014 22:08:00 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:00 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id DDD6011A6E4; Mon,  1 Dec 2014 11:40:35 -0500 (EST)
Date: Mon, 1 Dec 2014 11:40:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Waiman Long <Waiman.Long@hp.com>
Message-ID: <20141201164035.GF3180@laptop.dumpdata.com>
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.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
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 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:
> This patch adds para-virtualization support to the queue spinlock
> code base with minimal impact to the native case. There are some
> minor code changes in the generic qspinlock.c file which should be
> usable in other architectures. The other code changes are specific
> to x86 processors and so are all put under the arch/x86 directory.
> 
> On the lock side, the slowpath code is split into 2 separate functions
> generated from the same code - one for bare metal and one for PV guest.
> The switching is done in the _raw_spin_lock* functions. This makes
> sure that the performance impact to the bare metal case is minimal,
> just a few NOPs in the _raw_spin_lock* functions. In the PV slowpath
> code, there are 2 paravirt callee saved calls that minimize register
> pressure.
> 
> On the unlock side, however, the disabling of unlock function inlining
> does have some slight impact on bare metal performance.
> 
> The actual paravirt code comes in 5 parts;
> 
>  - init_node; this initializes the extra data members required for PV
>    state. PV state data is kept 1 cacheline ahead of the regular data.
> 
>  - link_and_wait_node; this replaces the regular MCS queuing code. CPU
>    halting can happen if the wait is too long.
> 
>  - wait_head; this waits until the lock is avialable and the CPU will
>    be halted if the wait is too long.
> 
>  - wait_check; this is called after acquiring the lock to see if the
>    next queue head CPU is halted. If this is the case, the lock bit is
>    changed to indicate the queue head will have to be kicked on unlock.
> 
>  - queue_unlock;  this routine has a jump label to check if paravirt
>    is enabled. If yes, it has to do an atomic cmpxchg to clear the lock
>    bit or call the slowpath function to kick the queue head cpu.
> 
> Tracking the head is done in two parts, firstly the pv_wait_head will
> store its cpu number in whichever node is pointed to by the tail part
> of the lock word. Secondly, pv_link_and_wait_node() will propagate the
> existing head from the old to the new tail node.
> 
> Signed-off-by: Waiman Long <Waiman.Long@hp.com>
> ---
>  arch/x86/include/asm/paravirt.h       |   19 ++
>  arch/x86/include/asm/paravirt_types.h |   20 ++
>  arch/x86/include/asm/pvqspinlock.h    |  411 +++++++++++++++++++++++++++++++++
>  arch/x86/include/asm/qspinlock.h      |   71 ++++++-
>  arch/x86/kernel/paravirt-spinlocks.c  |    6 +
>  include/asm-generic/qspinlock.h       |    2 +
>  kernel/locking/qspinlock.c            |   69 +++++-
>  7 files changed, 591 insertions(+), 7 deletions(-)
>  create mode 100644 arch/x86/include/asm/pvqspinlock.h
> 
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index cd6e161..7e296e6 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -712,6 +712,24 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
>  
>  #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS)
>  
> +#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);
> +}
> +
> +#else
>  static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
>  							__ticket_t ticket)
>  {
> @@ -723,6 +741,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
>  {
>  	PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket);
>  }
> +#endif
>  
>  #endif
>  
> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> index 7549b8b..49e4b76 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -326,6 +326,9 @@ struct pv_mmu_ops {
>  			   phys_addr_t phys, pgprot_t flags);
>  };
>  
> +struct mcs_spinlock;
> +struct qspinlock;
> +
>  struct arch_spinlock;
>  #ifdef CONFIG_SMP
>  #include <asm/spinlock_types.h>
> @@ -333,9 +336,26 @@ struct arch_spinlock;
>  typedef u16 __ticket_t;
>  #endif
>  
> +#ifdef CONFIG_QUEUE_SPINLOCK
> +enum pv_lock_stats {
> +	PV_HALT_QHEAD,		/* Queue head halting	    */
> +	PV_HALT_QNODE,		/* Other queue node halting */
> +	PV_HALT_ABORT,		/* Halting aborted	    */
> +	PV_WAKE_KICKED,		/* Wakeup by kicking	    */
> +	PV_WAKE_SPURIOUS,	/* Spurious wakeup	    */
> +	PV_KICK_NOHALT		/* Kick but CPU not halted  */
> +};
> +#endif
> +
>  struct pv_lock_ops {
> +#ifdef CONFIG_QUEUE_SPINLOCK
> +	struct paravirt_callee_save kick_cpu;
> +	struct paravirt_callee_save lockstat;
> +	struct paravirt_callee_save lockwait;
> +#else
>  	struct paravirt_callee_save lock_spinning;
>  	void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket);
> +#endif
>  };
>  
>  /* This contains all the paravirt structures: we get a convenient
> diff --git a/arch/x86/include/asm/pvqspinlock.h b/arch/x86/include/asm/pvqspinlock.h
> new file mode 100644
> index 0000000..85ccde6
> --- /dev/null
> +++ b/arch/x86/include/asm/pvqspinlock.h
> @@ -0,0 +1,411 @@
> +#ifndef _ASM_X86_PVQSPINLOCK_H
> +#define _ASM_X86_PVQSPINLOCK_H
> +
> +/*
> + *	Queue Spinlock Para-Virtualization (PV) Support
> + *
> + * The PV support code for queue spinlock is roughly the same as that
> + * of the ticket spinlock. 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.

Kind of. There is a lot more of going to sleep here than the PV ticketlock.
In there the CPU would go to sleep and wait until it was its turn in. Here
we need go to sleep when we are at the queue and then wake up to move a bit.

That means the next in the line has at least two halt and wakeups?

How does it compare to the PV ticketlocks that exists right now?

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8o-0004eV-Na; Mon, 01 Dec 2014 22:08: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 1XvZ8m-0004e9-GV
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:20 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	5B/60-17735-3D6EC745; Mon, 01 Dec 2014 22:08:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417471697!15139511!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9219 invoked from network); 1 Dec 2014 22:08:19 -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; 1 Dec 2014 22:08:19 -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 sB1M8DHC020246
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:13 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
	sB1M8BuI018918
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:12 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
	sB1M8BSf028063; Mon, 1 Dec 2014 22:08:11 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:11 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 38AE411A908; Mon,  1 Dec 2014 15:30:01 -0500 (EST)
Date: Mon, 1 Dec 2014 15:30:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201203001.GE21626@laptop.dumpdata.com>
References: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417174284.23604.9.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417174284.23604.9.camel@citrix.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, Boris Ostrovsky <boris.ostrovsky@oracle.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 Fri, Nov 28, 2014 at 11:31:24AM +0000, Ian Campbell wrote:
> 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.

I am bit lost. I thought Andrew NACKed this?

> 
> > ---
> > 
> > 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 Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ9H-0004wV-6c; Mon, 01 Dec 2014 22:08:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ9F-0004uL-Vk
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:50 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	A5/0E-25547-1F6EC745; Mon, 01 Dec 2014 22:08:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417471727!15139568!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10285 invoked from network); 1 Dec 2014 22:08: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; 1 Dec 2014 22:08:48 -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 sB1M8XUV020598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:34 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
	sB1M8WDZ028988
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 1 Dec 2014 22:08:33 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
	sB1M8VcS008003; Mon, 1 Dec 2014 22:08:31 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:31 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BB5D511A68E; Mon,  1 Dec 2014 10:37:59 -0500 (EST)
Date: Mon, 1 Dec 2014 10:37:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Josh Triplett <josh@joshtriplett.org>
Message-ID: <20141201153759.GE3180@laptop.dumpdata.com>
References: <cover.1414870871.git.josh@joshtriplett.org>
	<d50798c4b4860edfed4f95e34b7ffac3e6622aaf.1414870871.git.josh@joshtriplett.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d50798c4b4860edfed4f95e34b7ffac3e6622aaf.1414870871.git.josh@joshtriplett.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
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, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [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

On Sun, Nov 02, 2014 at 09:32:20AM -0800, Josh Triplett wrote:
> This will allow making set_iopl_mask optional later.
> 
> Signed-off-by: Josh Triplett <josh@joshtriplett.org>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  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

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8z-0004hP-59; Mon, 01 Dec 2014 22:08: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 1XvZ8x-0004gc-W6
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:32 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7E/57-09842-FD6EC745; Mon, 01 Dec 2014 22:08:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417471709!9264095!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21131 invoked from network); 1 Dec 2014 22:08:30 -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; 1 Dec 2014 22:08:30 -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 sB1M8NVL020460
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:24 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
	sB1M8MUB019549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:22 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
	sB1M8Lkt019518; Mon, 1 Dec 2014 22:08:22 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:21 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5E5D511A9DE; Mon,  1 Dec 2014 16:16:53 -0500 (EST)
Date: Mon, 1 Dec 2014 16:16:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141201211653.GI22021@laptop.dumpdata.com>
References: <1417177608-6705-1-git-send-email-rcojocaru@bitdefender.com>
	<21624.27430.789784.210615@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21624.27430.789784.210615@mariner.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.xenproject.org, wei.liu2@citrix.com,
	ian.campbell@citrix.com, Razvan Cojocaru <rcojocaru@bitdefender.com>,
	stefano.stabellini@eu.citrix.com
Subject: Re: [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

On Fri, Nov 28, 2014 at 12:31:34PM +0000, Ian Jackson wrote:
> 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>

It is documentation per say so it can go in ..
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8q-0004en-Ef; Mon, 01 Dec 2014 22:08:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ8p-0004eS-2e
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:23 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B5/50-22737-6D6EC745; Mon, 01 Dec 2014 22:08:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417471700!5630820!1
X-Originating-IP: [156.151.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 28887 invoked from network); 1 Dec 2014 22:08:21 -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; 1 Dec 2014 22:08:21 -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 sB1M8Jd6014804
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Mon, 1 Dec 2014 22:08:19 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
	sB1M8IeU007463
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xenproject.org>; Mon, 1 Dec 2014 22:08:19 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
	sB1M8IWJ028407
	for <xen-devel@lists.xenproject.org>; Mon, 1 Dec 2014 22:08:18 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:18 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2DF3411A688; Mon,  1 Dec 2014 10:36:57 -0500 (EST)
Date: Mon, 1 Dec 2014 10:36:57 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Message-ID: <20141201153657.GC3180@laptop.dumpdata.com>
References: <20141031153000.GA19229@mwanda>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141031153000.GA19229@mwanda>
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
Subject: Re: [Xen-devel] xen/pciback: Drop two backends,
	squash and cleanup some code.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 31, 2014 at 06:30:01PM +0300, Dan Carpenter wrote:
> Hello Konrad Rzeszutek Wilk,
> 
> The patch a92336a1176b: "xen/pciback: Drop two backends, squash and
> cleanup some code." from Jul 19, 2011, leads to the following static
> checker warning:
> 
> 	drivers/xen/xen-pciback/conf_space_capability.c:163 pm_ctrl_init()
> 	error: passing non negative 135 to ERR_PTR
> 
> drivers/xen/xen-pciback/conf_space_capability.c
>    147  /* Ensure PMEs are disabled */
>    148  static void *pm_ctrl_init(struct pci_dev *dev, int offset)
>    149  {
>    150          int err;
>    151          u16 value;
>    152  
>    153          err = pci_read_config_word(dev, offset, &value);
>    154          if (err)
>    155                  goto out;
>    156  
>    157          if (value & PCI_PM_CTRL_PME_ENABLE) {
>    158                  value &= ~PCI_PM_CTRL_PME_ENABLE;
>    159                  err = pci_write_config_word(dev, offset, value);
> 
> The static check is complaining that pci_write_config_word() can
> return PCIBIOS_BAD_REGISTER_NUMBER, but actually I think that's not
> possible.
> 
> Anyway, this function is only called from
> xen_pcibk_config_add_field_offset() so why are we returning a pointer
> instead of just int?

Because all the other 'init' could. And 'bar_init' for example
returns the BAR value (wrapped in 'struct pci_bar_info').
> 
>    160          }
>    161  
>    162  out:
>    163          return ERR_PTR(err);
>    164  }
> 
> regards,
> dan carpenter

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ91-0004ij-0Z; Mon, 01 Dec 2014 22:08:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ8z-0004h8-4X
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:33 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3D/84-25276-0E6EC745; Mon, 01 Dec 2014 22:08:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417471710!12677530!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31208 invoked from network); 1 Dec 2014 22:08:31 -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; 1 Dec 2014 22:08: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 sB1M8Rxm020503
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22: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
	sB1M8Qg4028757
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:27 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
	sB1M8Qd4028744; Mon, 1 Dec 2014 22:08:26 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:26 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 60A7011A9C9; Mon,  1 Dec 2014 16:14:56 -0500 (EST)
Date: Mon, 1 Dec 2014 16:14:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201211456.GH22021@laptop.dumpdata.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
	<1417174732.23604.13.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417174732.23604.13.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, 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 Fri, Nov 28, 2014 at 11:38:52AM +0000, Ian Campbell wrote:
> 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>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8v-0004fq-0B; Mon, 01 Dec 2014 22:08:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ8t-0004fL-Fq
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:27 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	DD/8B-22777-AD6EC745; Mon, 01 Dec 2014 22:08:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417471704!3339666!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32232 invoked from network); 1 Dec 2014 22:08:26 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 22:08: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 sB1M8MUl020459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:23 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
	sB1M8M1Z011761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:22 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
	sB1M8LDR019502; Mon, 1 Dec 2014 22:08:21 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:21 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A308311A9E4; Mon,  1 Dec 2014 16:18:36 -0500 (EST)
Date: Mon, 1 Dec 2014 16:18:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141201211836.GJ22021@laptop.dumpdata.com>
References: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417187826-5491-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, tim@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@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

On Fri, Nov 28, 2014 at 03:17:06PM +0000, Julien Grall wrote:
> 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.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 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 Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ91-0004ij-0Z; Mon, 01 Dec 2014 22:08:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ8z-0004h8-4X
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:33 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3D/84-25276-0E6EC745; Mon, 01 Dec 2014 22:08:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417471710!12677530!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31208 invoked from network); 1 Dec 2014 22:08:31 -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; 1 Dec 2014 22:08: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 sB1M8Rxm020503
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22: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
	sB1M8Qg4028757
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:27 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
	sB1M8Qd4028744; Mon, 1 Dec 2014 22:08:26 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:26 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 60A7011A9C9; Mon,  1 Dec 2014 16:14:56 -0500 (EST)
Date: Mon, 1 Dec 2014 16:14:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201211456.GH22021@laptop.dumpdata.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
	<1417174732.23604.13.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417174732.23604.13.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, 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 Fri, Nov 28, 2014 at 11:38:52AM +0000, Ian Campbell wrote:
> 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>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8z-0004hP-59; Mon, 01 Dec 2014 22:08: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 1XvZ8x-0004gc-W6
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:08:32 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7E/57-09842-FD6EC745; Mon, 01 Dec 2014 22:08:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417471709!9264095!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21131 invoked from network); 1 Dec 2014 22:08:30 -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; 1 Dec 2014 22:08:30 -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 sB1M8NVL020460
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:24 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
	sB1M8MUB019549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:22 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
	sB1M8Lkt019518; Mon, 1 Dec 2014 22:08:22 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:21 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5E5D511A9DE; Mon,  1 Dec 2014 16:16:53 -0500 (EST)
Date: Mon, 1 Dec 2014 16:16:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141201211653.GI22021@laptop.dumpdata.com>
References: <1417177608-6705-1-git-send-email-rcojocaru@bitdefender.com>
	<21624.27430.789784.210615@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21624.27430.789784.210615@mariner.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.xenproject.org, wei.liu2@citrix.com,
	ian.campbell@citrix.com, Razvan Cojocaru <rcojocaru@bitdefender.com>,
	stefano.stabellini@eu.citrix.com
Subject: Re: [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

On Fri, Nov 28, 2014 at 12:31:34PM +0000, Ian Jackson wrote:
> 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>

It is documentation per say so it can go in ..
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ8q-0004eg-2y; Mon, 01 Dec 2014 22:08:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ8o-0004eI-FH
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:22 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	DD/75-22819-5D6EC745; Mon, 01 Dec 2014 22:08:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417471699!3339658!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31622 invoked from network); 1 Dec 2014 22:08:21 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 22:08: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 sB1M8FB5020295
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08: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
	sB1M8E7c019095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:15 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
	sB1M8EeS019049; Mon, 1 Dec 2014 22:08:14 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:13 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3C24E11A9C6; Mon,  1 Dec 2014 16:14:32 -0500 (EST)
Date: Mon, 1 Dec 2014 16:14:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141201211431.GG22021@laptop.dumpdata.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-4-git-send-email-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417091674-8163-4-git-send-email-andrew.cooper3@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>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@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, Nov 27, 2014 at 12:34:34PM +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>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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))
> -- 
> 1.7.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 Dec 01 22:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22: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 1XvZ9F-0004uM-FW; Mon, 01 Dec 2014 22:08:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvZ9E-0004t2-Bf
	for xen-devel@lists.xen.org; Mon, 01 Dec 2014 22:08:48 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	0D/C8-02698-FE6EC745; Mon, 01 Dec 2014 22:08:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417471725!12312222!1
X-Originating-IP: [156.151.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 28613 invoked from network); 1 Dec 2014 22:08: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; 1 Dec 2014 22:08: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 sB1M8PbL014927
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 1 Dec 2014 22:08:26 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
	sB1M8Pj7007747
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 1 Dec 2014 22:08:25 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
	sB1M8OxF011867; Mon, 1 Dec 2014 22:08:24 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 01 Dec 2014 14:08:24 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 69D7011A9B7; Mon,  1 Dec 2014 16:11:18 -0500 (EST)
Date: Mon, 1 Dec 2014 16:11:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141201211117.GF22021@laptop.dumpdata.com>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com>
	<1417176581.23604.25.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417176581.23604.25.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Wei Liu <wei.liu2@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,
	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 Fri, Nov 28, 2014 at 12:09:41PM +0000, Ian Campbell wrote:
> 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...

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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));
> > >  
> > 
> 
> 

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:36:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22:36:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvZZo-0007Hh-9Q; Mon, 01 Dec 2014 22:36:16 +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 1XvZZm-0007HW-0f
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:36:14 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	6D/CA-23865-D5DEC745; Mon, 01 Dec 2014 22:36:13 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417473372!15048866!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 31627 invoked from network); 1 Dec 2014 22:36:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 22:36:12 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A335BABCA;
	Mon,  1 Dec 2014 22:36:11 +0000 (UTC)
Date: Mon, 1 Dec 2014 23:36:11 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141201223611.GM25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
	<547CB07C.1050507@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547CB07C.1050507@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>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 Mon, Dec 01, 2014 at 06:16:28PM +0000, David Vrabel wrote:
> On 01/12/14 16:19, Luis R. Rodriguez wrote:
> > On Mon, Dec 01, 2014 at 03:54:24PM +0000, David Vrabel wrote:
> >> On 01/12/14 15:44, Luis R. Rodriguez wrote:
> >>> On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> >>>> On 01/12/14 15:05, Luis R. Rodriguez wrote:
> >>>>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
> >>>>>> [...]
> >>>>>>>>> --- 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
> >>>>>>
> >>>>>> As Juergen points out, this does nothing.  You need to schedule while in
> >>>>>> the middle of the hypercall.
> >>>>>>
> >>>>>> Remember that Xen's hypercall preemption only preempts the hypercall to
> >>>>>> run interrupts in the guest.
> >>>>>
> >>>>> How is it ensured that when the kernel preempts on this code path on
> >>>>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
> >>>>
> >>>> Sorry, I really didn't describe this very well.
> >>>>
> >>>> If a hypercall needs a continuation, Xen returns to the guest with the
> >>>> IP set to the hypercall instruction, and on the way back to the guest
> >>>> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
> >>>>
> >>>> The guest is free to return from the upcall to the original task
> >>>> (continuing the hypercall) or to a different one.
> >>>
> >>> OK so that addresses what Xen will do when using continuation and
> >>> hypercall preemption, my concern here was that using
> >>> preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
> >>> hypercall on the return from an interrupt (e.g., the timer interrupt)
> >>> would still let the kernel preempt to tasks other than those related
> >>> to Xen.
> >>
> >> Um.  Why would that be a problem?  We do want to switch to any task the
> >> Linux scheduler thinks is best.
> > 
> > Its safe but -- it technically is doing kernel preemption, unless we want
> > to adjust the definition of CONFIG_PREEMPT=n to exclude hypercalls. This
> > was my original concern with the use of preempt_schedule_irq() to do this.
> > I am afraid of setting precedents without being clear or wider review and
> > acceptance.
> 
> It's voluntary preemption at a well defined point. 

Its voluntarily preempting the kernel even for CONFIG_PREEMPT=n kernels... 

> It's no different to a cond_resched() call.

Then I do agree its a fair analogy (and find this obviously odd that how
widespread cond_resched() is), we just don't have an equivalent for IRQ
context, why not avoid the special check then and use this all the time in the
middle of a hypercall on the return from an interrupt (e.g., the timer
interrupt)?

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5e344bb..e60b5a1 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2759,6 +2759,12 @@ static inline int signal_pending_state(long state, struct task_struct *p)
  */
 extern int _cond_resched(void);
 
+/*
+ * Voluntarily preempting the kernel even for CONFIG_PREEMPT=n kernels
+ * on very special circumstances.
+ */
+extern int cond_resched_irq(void);
+
 #define cond_resched() ({			\
 	__might_sleep(__FILE__, __LINE__, 0);	\
 	_cond_resched();			\
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 240157c..1c4d443 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4264,6 +4264,16 @@ int __sched _cond_resched(void)
 }
 EXPORT_SYMBOL(_cond_resched);
 
+int __sched cond_resched_irq(void)
+{
+	if (should_resched()) {
+		preempt_schedule_irq();
+		return 1;
+	}
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cond_resched_irq);
+
 /*
  * __cond_resched_lock() - if a reschedule is pending, drop the given lock,
  * call schedule, and on return reacquire the lock.
  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 22:36:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 22:36:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvZZo-0007Hh-9Q; Mon, 01 Dec 2014 22:36:16 +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 1XvZZm-0007HW-0f
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 22:36:14 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	6D/CA-23865-D5DEC745; Mon, 01 Dec 2014 22:36:13 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417473372!15048866!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 31627 invoked from network); 1 Dec 2014 22:36:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 22:36:12 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A335BABCA;
	Mon,  1 Dec 2014 22:36:11 +0000 (UTC)
Date: Mon, 1 Dec 2014 23:36:11 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141201223611.GM25677@wotan.suse.de>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>
	<5476C66F.5040308@suse.com> <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
	<547CB07C.1050507@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547CB07C.1050507@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>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 Mon, Dec 01, 2014 at 06:16:28PM +0000, David Vrabel wrote:
> On 01/12/14 16:19, Luis R. Rodriguez wrote:
> > On Mon, Dec 01, 2014 at 03:54:24PM +0000, David Vrabel wrote:
> >> On 01/12/14 15:44, Luis R. Rodriguez wrote:
> >>> On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> >>>> On 01/12/14 15:05, Luis R. Rodriguez wrote:
> >>>>> On Mon, Dec 01, 2014 at 11:11:43AM +0000, David Vrabel 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
> >>>>>> [...]
> >>>>>>>>> --- 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
> >>>>>>
> >>>>>> As Juergen points out, this does nothing.  You need to schedule while in
> >>>>>> the middle of the hypercall.
> >>>>>>
> >>>>>> Remember that Xen's hypercall preemption only preempts the hypercall to
> >>>>>> run interrupts in the guest.
> >>>>>
> >>>>> How is it ensured that when the kernel preempts on this code path on
> >>>>> CONFIG_PREEMPT=n kernel that only interrupts in the guest are run?
> >>>>
> >>>> Sorry, I really didn't describe this very well.
> >>>>
> >>>> If a hypercall needs a continuation, Xen returns to the guest with the
> >>>> IP set to the hypercall instruction, and on the way back to the guest
> >>>> Xen may schedule a different VCPU or it will do any upcalls (as per normal).
> >>>>
> >>>> The guest is free to return from the upcall to the original task
> >>>> (continuing the hypercall) or to a different one.
> >>>
> >>> OK so that addresses what Xen will do when using continuation and
> >>> hypercall preemption, my concern here was that using
> >>> preempt_schedule_irq() on CONFIG_PREEMPT=n kernels in the middle of a
> >>> hypercall on the return from an interrupt (e.g., the timer interrupt)
> >>> would still let the kernel preempt to tasks other than those related
> >>> to Xen.
> >>
> >> Um.  Why would that be a problem?  We do want to switch to any task the
> >> Linux scheduler thinks is best.
> > 
> > Its safe but -- it technically is doing kernel preemption, unless we want
> > to adjust the definition of CONFIG_PREEMPT=n to exclude hypercalls. This
> > was my original concern with the use of preempt_schedule_irq() to do this.
> > I am afraid of setting precedents without being clear or wider review and
> > acceptance.
> 
> It's voluntary preemption at a well defined point. 

Its voluntarily preempting the kernel even for CONFIG_PREEMPT=n kernels... 

> It's no different to a cond_resched() call.

Then I do agree its a fair analogy (and find this obviously odd that how
widespread cond_resched() is), we just don't have an equivalent for IRQ
context, why not avoid the special check then and use this all the time in the
middle of a hypercall on the return from an interrupt (e.g., the timer
interrupt)?

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5e344bb..e60b5a1 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2759,6 +2759,12 @@ static inline int signal_pending_state(long state, struct task_struct *p)
  */
 extern int _cond_resched(void);
 
+/*
+ * Voluntarily preempting the kernel even for CONFIG_PREEMPT=n kernels
+ * on very special circumstances.
+ */
+extern int cond_resched_irq(void);
+
 #define cond_resched() ({			\
 	__might_sleep(__FILE__, __LINE__, 0);	\
 	_cond_resched();			\
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 240157c..1c4d443 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4264,6 +4264,16 @@ int __sched _cond_resched(void)
 }
 EXPORT_SYMBOL(_cond_resched);
 
+int __sched cond_resched_irq(void)
+{
+	if (should_resched()) {
+		preempt_schedule_irq();
+		return 1;
+	}
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cond_resched_irq);
+
 /*
  * __cond_resched_lock() - if a reschedule is pending, drop the given lock,
  * call schedule, and on return reacquire the lock.
  Luis

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 23:16:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 23: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 1XvaBx-0008Ho-Ma; Mon, 01 Dec 2014 23:15:41 +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 1XvaBw-0008Hj-Er
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 23:15:40 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	F5/7C-18267-B96FC745; Mon, 01 Dec 2014 23:15:39 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417475737!15146827!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 19113 invoked from network); 1 Dec 2014 23:15:38 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 23:15:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417475738; x=1449011738;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=FNA4BvkrU8sOibGp9MCKVPWE7HdfrSrFb5ehm8FfbhI=;
	b=osIkcRdsmBzGPSQ2hFjPu5ZYx7oGIMeBhdaiB492Wm9cyunu2kYk52Ee
	hU9pX88LDc6YfBiB6WrAuVqf/1IRoAVnQx1VTtxjdQegzPXNVWC8jypuS
	Fx/S//0opQRkUznAKxTX08HDgM0j2GlzojV6XZNm59t9tkYQkwd51kwIh I=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 01 Dec 2014 23:15:36 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,497,1413244800"; d="scan'208";a="918342683"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.111.135])
	by fldsmtpi01.verizon.com with ESMTP; 01 Dec 2014 23:15:35 +0000
Message-ID: <547CF696.9040009@terremark.com>
Date: Mon, 01 Dec 2014 18:15:34 -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>, 
	xen-devel@lists.xensource.com
References: <alpine.DEB.2.02.1411251745520.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411251745520.14135@kaball.uk.xensource.com>
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [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-Transfer-Encoding: 7bit
Content-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 12:54, Stefano Stabellini wrote:
> 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);

This fills ptr with uninitialized data.  You need to call

xc_domain_getinfolist()

before this.  However calling xc_domain_getinfolist() here and retry
of the xenstore transaction, you will adjust this more then one time.

So I think that xc_domain_getinfolist() needs to be called before
the label retry_transaction.  However rc is a mess in this routine.

rc = 1 is the normal return (since rc = xc_domain_getinfolist() is
the last setting of rc).  So all the rest of "rc =" needs to be adjusted
someway.

    -Don Slutz


> +
> +    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


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 23:16:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 23: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 1XvaBx-0008Ho-Ma; Mon, 01 Dec 2014 23:15:41 +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 1XvaBw-0008Hj-Er
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 23:15:40 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	F5/7C-18267-B96FC745; Mon, 01 Dec 2014 23:15:39 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417475737!15146827!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 19113 invoked from network); 1 Dec 2014 23:15:38 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 23:15:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417475738; x=1449011738;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=FNA4BvkrU8sOibGp9MCKVPWE7HdfrSrFb5ehm8FfbhI=;
	b=osIkcRdsmBzGPSQ2hFjPu5ZYx7oGIMeBhdaiB492Wm9cyunu2kYk52Ee
	hU9pX88LDc6YfBiB6WrAuVqf/1IRoAVnQx1VTtxjdQegzPXNVWC8jypuS
	Fx/S//0opQRkUznAKxTX08HDgM0j2GlzojV6XZNm59t9tkYQkwd51kwIh I=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 01 Dec 2014 23:15:36 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,497,1413244800"; d="scan'208";a="918342683"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.111.135])
	by fldsmtpi01.verizon.com with ESMTP; 01 Dec 2014 23:15:35 +0000
Message-ID: <547CF696.9040009@terremark.com>
Date: Mon, 01 Dec 2014 18:15:34 -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>, 
	xen-devel@lists.xensource.com
References: <alpine.DEB.2.02.1411251745520.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1411251745520.14135@kaball.uk.xensource.com>
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [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-Transfer-Encoding: 7bit
Content-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 12:54, Stefano Stabellini wrote:
> 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);

This fills ptr with uninitialized data.  You need to call

xc_domain_getinfolist()

before this.  However calling xc_domain_getinfolist() here and retry
of the xenstore transaction, you will adjust this more then one time.

So I think that xc_domain_getinfolist() needs to be called before
the label retry_transaction.  However rc is a mess in this routine.

rc = 1 is the normal return (since rc = xc_domain_getinfolist() is
the last setting of rc).  So all the rest of "rc =" needs to be adjusted
someway.

    -Don Slutz


> +
> +    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


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

From xen-devel-bounces@lists.xen.org Mon Dec 01 23:16:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 23:16:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvaCj-0008LU-A5; Mon, 01 Dec 2014 23:16:29 +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 1XvaCi-0008LJ-4j
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 23:16:28 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	58/EA-17735-BC6FC745; Mon, 01 Dec 2014 23:16:27 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417475785!11380746!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 1158 invoked from network); 1 Dec 2014 23:16:26 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 23:16:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417475786; x=1449011786;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=FURbRzN1v9EzeytzzSCkgPIsgpY+rZQ1JfJU5j3S/KE=;
	b=nvldTZ2cp+tMJMdnvNOLtK+HnZPRL6QwVJFh1GwDGBy0riroaZoDi8Ez
	BqOLyxrC+6zRb9Ms9gVMXtqyXZTCJwRStPTmMJYrj64EBfP58nHeieHLG
	acz8onN8Z5DE666VDUrNxZkk8SyKqD/S7DnEfKHBR20260iHi91cfWHqU o=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 01 Dec 2014 23:16:24 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,497,1413244800"; d="scan'208";a="918343717"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.111.135])
	by fldsmtpi01.verizon.com with ESMTP; 01 Dec 2014 23:16:23 +0000
Message-ID: <547CF6C6.4060106@terremark.com>
Date: Mon, 01 Dec 2014 18:16:22 -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: <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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412011528540.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 12/01/14 10:37, Stefano Stabellini wrote:
> On Mon, 1 Dec 2014, Don Slutz wrote:
>> On 11/27/14 05:48, Stefano Stabellini wrote:

[...]

>>
>> Works fine in both claim modes and with PoD used (maxmem > memory).  Do
>> not know how to test with tmem.  I do not see how it would be worse then
>> current
>> code that does not auto increase.  I.E. even without a xen change, I think
>> something
>> like this could be done.
> OK, good to know. I am OK with increasing maxmem only if it is strictly
> necessary.
>
>
>>>> 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.
>> Ok.  I did find the 32 it is VGA_HOLE_SIZE.  So here is what I have which
>> includes
>> a lot of extra printf.
> In QEMU I would prefer not to assume that libxl increased maxmem for the
> vga hole. I would rather call xc_domain_setmaxmem twice for the vga hole
> than tie QEMU to a particular maxmem allocation scheme in libxl.

Ok.  The area we are talking about is 0x000a0000 to 0x000c0000.
It is in libxc (xc_hvm_build_x86), not libxl.   I have no issue with a 
name change to
some thing like QEMU_EXTRA_FREE_PAGES.

My testing has shows that some of these 32 pages are used outside of QEMU.
I am seeing just 23 free pages using a standalone program to display
the same info after a CentOS 6.3 guest is done booting.

> In libxl I would like to avoid increasing mamxem for anything QEMU will
> allocate later, that includes rom and vga vram. I am not sure how to
> make that work with older QEMU versions that don't call
> xc_domain_setmaxmem by themselves yet though. Maybe we could check the
> specific QEMU version in libxl and decide based on that. Or we could
> export a feature flag in QEMU.

Yes, it would be nice to adjust libxl to not increase maxmem. However since
videoram is included in memory (and maxmem), making the change related
to vram is a bigger issue.

the rom change is much simpler.

Currently I do not know of a way to do different things based on the 
QEMU version
and/or features (this includes getting the QEMU version in libxl).

I have been going with:
1) change QEMU 1st.
2) Wait for an upstream version of QEMU with this.
3) change xen to optionally use a feature in the latest QEMU.

>
>
>> --- a/xen-hvm.c
>> +++ b/xen-hvm.c
>> @@ -67,6 +67,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t
>> *shared_page, int vcpu)
>>   #endif
>>
>>   #define BUFFER_IO_MAX_DELAY  100
>> +#define VGA_HOLE_SIZE (0x20)
>>
>>   typedef struct XenPhysmap {
>>       hwaddr start_addr;
>> @@ -219,6 +220,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
>> MemoryRegion *mr)
>>       xen_pfn_t *pfn_list;
>>       int i;
>>       xc_dominfo_t info;
>> +    unsigned long max_pages, free_pages, real_free;
>> +    long need_pages;
>> +    uint64_t tot_pages, pod_cache_pages, pod_entries;
>> +
>> +    trace_xen_ram_alloc(ram_addr, size, mr->name);
>>
>>       if (runstate_check(RUN_STATE_INMIGRATE)) {
>>           /* RAM already populated in Xen */
>> @@ -232,13 +238,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
>> MemoryRegion *mr)
>>           return;
>>       }
>>
>> -    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
>> -            " bytes (%ld Kib) of ram at "RAM_ADDR_FMT
>> -            " mr.name=%s\n",
>> -            __func__, size, (long)(size>>10), ram_addr, mr->name);
>> -
>> -    trace_xen_ram_alloc(ram_addr, size);
>> -
>>       nr_pfn = size >> TARGET_PAGE_BITS;
>>       pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
>>
>> @@ -246,11 +245,38 @@ 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) {
>> +    if ((xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) ||
>> +       (info.domid != xen_domid)) {
>>           hw_error("xc_domain_getinfo failed");
>>       }
>> -    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;
>> +    real_free = free_pages;
>> +    if (free_pages > VGA_HOLE_SIZE) {
>> +        free_pages -= VGA_HOLE_SIZE;
>> +    } else {
>> +        free_pages = 0;
>> +    }
>> +    need_pages = nr_pfn - free_pages;
>> +    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
>> +            " bytes (%ld KiB) of ram at "RAM_ADDR_FMT
>> +            " mp=%ld fp=%ld nr=%ld need=%ld mr.name=%s\n",
>> +            __func__, size, (long)(size>>10), ram_addr,
>> +           max_pages, free_pages, nr_pfn, need_pages,
>> +            mr->name);
>> +    if (xc_domain_get_pod_target(xen_xc, xen_domid, &tot_pages,
>> +                                 &pod_cache_pages, &pod_entries) >= 0) {
>> +        unsigned long populated = tot_pages - pod_cache_pages;
>> +        long delta_tot = tot_pages - info.nr_pages;
>> +
>> +        fprintf(stderr, "%s: PoD pop=%ld tot=%ld(%ld) cnt=%ld ent=%ld nop=%ld
>> free=%ld\n",
>> +                __func__, populated, (long)tot_pages, delta_tot,
>> +                (long)pod_cache_pages, (long)pod_entries,
>> +               (long)info.nr_outstanding_pages, real_free);
>> +    }
> What is the purpose of calling xc_domain_get_pod_target here? It doesn't
> look like is affecting the parameters passed to xc_domain_setmaxmem.

This was just to test and see if anything was needed for PoD mode.
I did not see anything.

Did you want me to make a patch to send to the list that has my proposed
changes?

I do think that what I have would be fine to do since most of the time the
new code does nothing with the current xen (and older versions), until
more then 4 nics are configured for xen.

It would be good to have the change:

[PATCH] libxl_set_memory_target: retain the same maxmem offset on top of 
the current target

(When working) in xen before using a QEMU with this change.

Not sure I would push for 2.2 however.

    -Don Slutz

>
>> +    if ((free_pages < nr_pfn) &&
>> +       (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
>> +                            (need_pages * 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)) {
>>
>>
>> Note: I already had a trace_xen_ram_alloc, here is the delta in trace-events
>> (which
>> has others not yet sent):
>>
>>
>>
>> diff --git a/trace-events b/trace-events
>> index eaeecd5..a58fc11 100644
>> --- a/trace-events
>> +++ b/trace-events
>> @@ -908,7 +908,7 @@ pvscsi_tx_rings_ppn(const char* label, uint64_t ppn) "%s
>> page: %"PRIx64""
>>   pvscsi_tx_rings_num_pages(const char* label, uint32_t num) "Number of %s
>> pages: %u"
>>
>>   # xen-all.c
>> -xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: %#lx,
>> size %#lx"
>> +xen_ram_alloc(unsigned long ram_addr, unsigned long size, const char*
>> mr_name) "requested: %#lx size %#lx mr->name=%s"
>>   xen_client_set_memory(uint64_t start_addr, unsigned long size, bool
>> log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
>>   handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df, uint32_t
>> data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
>> "I/O=%p type=%d dir=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d
>> size=%d"
>>   handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t
>> data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
>> "I/O=%p read type=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d
>> size=%d"
>>
>>
>>     -Don Slutz
>>
>>>>      -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 Mon Dec 01 23:16:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 23:16:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvaCj-0008LU-A5; Mon, 01 Dec 2014 23:16:29 +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 1XvaCi-0008LJ-4j
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 23:16:28 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	58/EA-17735-BC6FC745; Mon, 01 Dec 2014 23:16:27 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417475785!11380746!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 1158 invoked from network); 1 Dec 2014 23:16:26 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Dec 2014 23:16:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417475786; x=1449011786;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=FURbRzN1v9EzeytzzSCkgPIsgpY+rZQ1JfJU5j3S/KE=;
	b=nvldTZ2cp+tMJMdnvNOLtK+HnZPRL6QwVJFh1GwDGBy0riroaZoDi8Ez
	BqOLyxrC+6zRb9Ms9gVMXtqyXZTCJwRStPTmMJYrj64EBfP58nHeieHLG
	acz8onN8Z5DE666VDUrNxZkk8SyKqD/S7DnEfKHBR20260iHi91cfWHqU o=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 01 Dec 2014 23:16:24 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,497,1413244800"; d="scan'208";a="918343717"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.111.135])
	by fldsmtpi01.verizon.com with ESMTP; 01 Dec 2014 23:16:23 +0000
Message-ID: <547CF6C6.4060106@terremark.com>
Date: Mon, 01 Dec 2014 18:16:22 -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: <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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412011528540.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 12/01/14 10:37, Stefano Stabellini wrote:
> On Mon, 1 Dec 2014, Don Slutz wrote:
>> On 11/27/14 05:48, Stefano Stabellini wrote:

[...]

>>
>> Works fine in both claim modes and with PoD used (maxmem > memory).  Do
>> not know how to test with tmem.  I do not see how it would be worse then
>> current
>> code that does not auto increase.  I.E. even without a xen change, I think
>> something
>> like this could be done.
> OK, good to know. I am OK with increasing maxmem only if it is strictly
> necessary.
>
>
>>>> 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.
>> Ok.  I did find the 32 it is VGA_HOLE_SIZE.  So here is what I have which
>> includes
>> a lot of extra printf.
> In QEMU I would prefer not to assume that libxl increased maxmem for the
> vga hole. I would rather call xc_domain_setmaxmem twice for the vga hole
> than tie QEMU to a particular maxmem allocation scheme in libxl.

Ok.  The area we are talking about is 0x000a0000 to 0x000c0000.
It is in libxc (xc_hvm_build_x86), not libxl.   I have no issue with a 
name change to
some thing like QEMU_EXTRA_FREE_PAGES.

My testing has shows that some of these 32 pages are used outside of QEMU.
I am seeing just 23 free pages using a standalone program to display
the same info after a CentOS 6.3 guest is done booting.

> In libxl I would like to avoid increasing mamxem for anything QEMU will
> allocate later, that includes rom and vga vram. I am not sure how to
> make that work with older QEMU versions that don't call
> xc_domain_setmaxmem by themselves yet though. Maybe we could check the
> specific QEMU version in libxl and decide based on that. Or we could
> export a feature flag in QEMU.

Yes, it would be nice to adjust libxl to not increase maxmem. However since
videoram is included in memory (and maxmem), making the change related
to vram is a bigger issue.

the rom change is much simpler.

Currently I do not know of a way to do different things based on the 
QEMU version
and/or features (this includes getting the QEMU version in libxl).

I have been going with:
1) change QEMU 1st.
2) Wait for an upstream version of QEMU with this.
3) change xen to optionally use a feature in the latest QEMU.

>
>
>> --- a/xen-hvm.c
>> +++ b/xen-hvm.c
>> @@ -67,6 +67,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t
>> *shared_page, int vcpu)
>>   #endif
>>
>>   #define BUFFER_IO_MAX_DELAY  100
>> +#define VGA_HOLE_SIZE (0x20)
>>
>>   typedef struct XenPhysmap {
>>       hwaddr start_addr;
>> @@ -219,6 +220,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
>> MemoryRegion *mr)
>>       xen_pfn_t *pfn_list;
>>       int i;
>>       xc_dominfo_t info;
>> +    unsigned long max_pages, free_pages, real_free;
>> +    long need_pages;
>> +    uint64_t tot_pages, pod_cache_pages, pod_entries;
>> +
>> +    trace_xen_ram_alloc(ram_addr, size, mr->name);
>>
>>       if (runstate_check(RUN_STATE_INMIGRATE)) {
>>           /* RAM already populated in Xen */
>> @@ -232,13 +238,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
>> MemoryRegion *mr)
>>           return;
>>       }
>>
>> -    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
>> -            " bytes (%ld Kib) of ram at "RAM_ADDR_FMT
>> -            " mr.name=%s\n",
>> -            __func__, size, (long)(size>>10), ram_addr, mr->name);
>> -
>> -    trace_xen_ram_alloc(ram_addr, size);
>> -
>>       nr_pfn = size >> TARGET_PAGE_BITS;
>>       pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
>>
>> @@ -246,11 +245,38 @@ 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) {
>> +    if ((xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) ||
>> +       (info.domid != xen_domid)) {
>>           hw_error("xc_domain_getinfo failed");
>>       }
>> -    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;
>> +    real_free = free_pages;
>> +    if (free_pages > VGA_HOLE_SIZE) {
>> +        free_pages -= VGA_HOLE_SIZE;
>> +    } else {
>> +        free_pages = 0;
>> +    }
>> +    need_pages = nr_pfn - free_pages;
>> +    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
>> +            " bytes (%ld KiB) of ram at "RAM_ADDR_FMT
>> +            " mp=%ld fp=%ld nr=%ld need=%ld mr.name=%s\n",
>> +            __func__, size, (long)(size>>10), ram_addr,
>> +           max_pages, free_pages, nr_pfn, need_pages,
>> +            mr->name);
>> +    if (xc_domain_get_pod_target(xen_xc, xen_domid, &tot_pages,
>> +                                 &pod_cache_pages, &pod_entries) >= 0) {
>> +        unsigned long populated = tot_pages - pod_cache_pages;
>> +        long delta_tot = tot_pages - info.nr_pages;
>> +
>> +        fprintf(stderr, "%s: PoD pop=%ld tot=%ld(%ld) cnt=%ld ent=%ld nop=%ld
>> free=%ld\n",
>> +                __func__, populated, (long)tot_pages, delta_tot,
>> +                (long)pod_cache_pages, (long)pod_entries,
>> +               (long)info.nr_outstanding_pages, real_free);
>> +    }
> What is the purpose of calling xc_domain_get_pod_target here? It doesn't
> look like is affecting the parameters passed to xc_domain_setmaxmem.

This was just to test and see if anything was needed for PoD mode.
I did not see anything.

Did you want me to make a patch to send to the list that has my proposed
changes?

I do think that what I have would be fine to do since most of the time the
new code does nothing with the current xen (and older versions), until
more then 4 nics are configured for xen.

It would be good to have the change:

[PATCH] libxl_set_memory_target: retain the same maxmem offset on top of 
the current target

(When working) in xen before using a QEMU with this change.

Not sure I would push for 2.2 however.

    -Don Slutz

>
>> +    if ((free_pages < nr_pfn) &&
>> +       (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
>> +                            (need_pages * 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)) {
>>
>>
>> Note: I already had a trace_xen_ram_alloc, here is the delta in trace-events
>> (which
>> has others not yet sent):
>>
>>
>>
>> diff --git a/trace-events b/trace-events
>> index eaeecd5..a58fc11 100644
>> --- a/trace-events
>> +++ b/trace-events
>> @@ -908,7 +908,7 @@ pvscsi_tx_rings_ppn(const char* label, uint64_t ppn) "%s
>> page: %"PRIx64""
>>   pvscsi_tx_rings_num_pages(const char* label, uint32_t num) "Number of %s
>> pages: %u"
>>
>>   # xen-all.c
>> -xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: %#lx,
>> size %#lx"
>> +xen_ram_alloc(unsigned long ram_addr, unsigned long size, const char*
>> mr_name) "requested: %#lx size %#lx mr->name=%s"
>>   xen_client_set_memory(uint64_t start_addr, unsigned long size, bool
>> log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
>>   handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df, uint32_t
>> data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
>> "I/O=%p type=%d dir=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d
>> size=%d"
>>   handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t
>> data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
>> "I/O=%p read type=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d
>> size=%d"
>>
>>
>>     -Don Slutz
>>
>>>>      -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 Mon Dec 01 23:18:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 23:18:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvaEl-0008VG-R4; Mon, 01 Dec 2014 23:18:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1XvaEj-0008VB-Nv
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 23:18:33 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	F7/F3-25727-947FC745; Mon, 01 Dec 2014 23:18:33 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417475911!15087167!1
X-Originating-IP: [209.85.215.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 24700 invoked from network); 1 Dec 2014 23:18:32 -0000
Received: from mail-la0-f48.google.com (HELO mail-la0-f48.google.com)
	(209.85.215.48)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 23:18:32 -0000
Received: by mail-la0-f48.google.com with SMTP id s18so9945803lam.35
	for <xen-devel@lists.xenproject.org>;
	Mon, 01 Dec 2014 15:18:31 -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=MH83A6iOfroED2Z26ArVOK/r/TilZIz/cfKRyB9ZxNQ=;
	b=fjNlXz0Es8SIUjmj29B08krGpWd2x3JB7LyqmY/PPjVg8WJDdViiZY/oLo/RGyF2ry
	tOm4wFU5wNQ9fxjhoBolLFqNW+0d1Ic8Ju64ExPyA9wfZ9C1djDM8gLBEmvHTUKOjPId
	TzvU58GBrxYxnlPP6EujBKrdIaJr0v1Hj+FXpYMr3TuKengtk9HLUaKyw6Is/ivs8e0C
	gKu8mmwgavWTml9cPupgKXbQzdHn2sNLPCHbOV86Pl8SypGknn3jtF6eN1jLscMZNa+w
	8JxHZEtO7depFgsXMFhKjb8OfDMKT99w+1ldecVE0F6XyBScqV1sijkvZ5voEDVVmxqj
	PPmg==
X-Gm-Message-State: ALoCoQklg6KyqQdi9+l4F0lg3JFUvlL4OV/VXF59zc5f09pTZXIxZQx0uviSnvmsC0uV30ooP2s8
X-Received: by 10.112.219.227 with SMTP id pr3mr55492127lbc.63.1417475911353; 
	Mon, 01 Dec 2014 15:18:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.7.132 with HTTP; Mon, 1 Dec 2014 15:18:11 -0800 (PST)
In-Reply-To: <20141201153336.GB3180@laptop.dumpdata.com>
References: <cover.1414516558.git.luto@amacapital.net>
	<6b0c9b0fc128de68634c730a5b1a80e1d085ad02.1414516558.git.luto@amacapital.net>
	<20141028174629.GA2150@jtriplet-mobl1>
	<CALCETrUihPeKODJqi3tMYwyWYhML1Z=gr4wrVK5VnaFo=KGVJA@mail.gmail.com>
	<20141029200016.GK3424@laptop.dumpdata.com>
	<CALCETrW+f8S9fNrui_J34q3Ve4jwA=neGe-tYZ_Lbp+ML3LiRw@mail.gmail.com>
	<20141201153336.GB3180@laptop.dumpdata.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Mon, 1 Dec 2014 15:18:11 -0800
Message-ID: <CALCETrUR6RKPZ7XpEp6NNu7n2W4TdAPQTCkB8Tpc2iF2SfdROw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Josh Triplett <josh@joshtriplett.org>
Subject: Re: [Xen-devel] [PATCH 3/3] x86_64,
	vsyscall: Make vsyscall emulation 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Dec 1, 2014 2:08 PM, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:
>
> On Wed, Oct 29, 2014 at 02:30:29PM -0700, Andy Lutomirski wrote:
> > On Oct 29, 2014 1:00 PM, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:
> > >
> > > On Tue, Oct 28, 2014 at 11:09:53AM -0700, Andy Lutomirski wrote:
> > > > On Tue, Oct 28, 2014 at 10:57 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> > > > > On Tue, Oct 28, 2014 at 10:22:28AM -0700, Andy Lutomirski wrote:
> > > > >> This adds CONFIG_X86_VSYSCALL_EMULATION, guarded by CONFIG_EXPERT.
> > > > >> Turning it off completely disables vsyscall emulation, saving ~3.5k
> > > > >> for vsyscall_64.c, 4k for vsyscall_emu_64.S (the fake vsyscall
> > > > >> page), some tiny amount of core mm code that supports a gate area,
> > > > >> and possibly 4k for a wasted pagetable.  The latter is because the
> > > > >> vsyscall addresses are misaligned and fit poorly in the fixmap.
> > > > >>
> > > > >> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> > > > >
> > > > > One minor nit below, but with or without that change,
> > > > > Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> > > > >
> > > > >> --- a/arch/x86/xen/mmu.c
> > > > >> +++ b/arch/x86/xen/mmu.c
> > > > >> @@ -1456,11 +1456,13 @@ static int xen_pgd_alloc(struct mm_struct *mm)
> > > > >>               user_pgd = (pgd_t *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
> > > > >>               page->private = (unsigned long)user_pgd;
> > > > >>
> > > > >> +#ifdef CONFIG_X86_VSYSCALL_EMULATION
> > > > >>               if (user_pgd != NULL) {
> > > > >>                       user_pgd[pgd_index(VSYSCALL_ADDR)] =
> > > > >>                               __pgd(__pa(level3_user_vsyscall) | _PAGE_TABLE);
> > > > >>                       ret = 0;
> > > > >>               }
> > > > >> +#endif
> > > > >
> > > > > Could you instead make the if use IS_ENABLED?
> > > > >
> > > > >                 if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION) && user_pgd != NULL)
> > > > >
> > > > > That has the advantage of ensuring that the code continues to compile.
> > > > > (Given that you haven't removed level3_user_vsyscall, that should work.)
> > > >
> > > > I need the ret = 0, I think, so I'll resend.
> > > >
> > > > I think I'd rather use #ifdef here, since I think it would be great if
> > > > the Xen people could clean this up further.  With this change, under
> > > > some configurations, there should be no user-accessible kernel
> > > > addresses at all.  (Also, is there some PV mechanism
>
> What about the vsyscall time stamp (aka kvm-clock). That is not
> really VSYSCALL emulation based but normal code?

That's entirely separate now.

>
> > > > that I'm not thinking of that will break with this change?  I know
> > > > I've tripped over Xen pagetable and fixmap oddities before.)
> > >
> > > Not that I know of. The vsyscall is the only one that I know of that
> > > does this.
> >
> > There's kvm-clock, too, but that may never co-exist with Xen.
>
> It will eventually.

Hmm. Maybe I should clean up the read code first.

--Andy

> >
> > I tagged v2 here:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/tag/?id=optional-vsyscall-emulation-v2
> >
> > and I'll send it out in a bit.
> >
> > --Andy
> >
> > >
> > > Do you have a full patchset somewhere for testing?
> > > >
> > > > --Andy

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 23:18:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 23:18:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvaEl-0008VG-R4; Mon, 01 Dec 2014 23:18:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1XvaEj-0008VB-Nv
	for xen-devel@lists.xenproject.org; Mon, 01 Dec 2014 23:18:33 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	F7/F3-25727-947FC745; Mon, 01 Dec 2014 23:18:33 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417475911!15087167!1
X-Originating-IP: [209.85.215.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 24700 invoked from network); 1 Dec 2014 23:18:32 -0000
Received: from mail-la0-f48.google.com (HELO mail-la0-f48.google.com)
	(209.85.215.48)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Dec 2014 23:18:32 -0000
Received: by mail-la0-f48.google.com with SMTP id s18so9945803lam.35
	for <xen-devel@lists.xenproject.org>;
	Mon, 01 Dec 2014 15:18:31 -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=MH83A6iOfroED2Z26ArVOK/r/TilZIz/cfKRyB9ZxNQ=;
	b=fjNlXz0Es8SIUjmj29B08krGpWd2x3JB7LyqmY/PPjVg8WJDdViiZY/oLo/RGyF2ry
	tOm4wFU5wNQ9fxjhoBolLFqNW+0d1Ic8Ju64ExPyA9wfZ9C1djDM8gLBEmvHTUKOjPId
	TzvU58GBrxYxnlPP6EujBKrdIaJr0v1Hj+FXpYMr3TuKengtk9HLUaKyw6Is/ivs8e0C
	gKu8mmwgavWTml9cPupgKXbQzdHn2sNLPCHbOV86Pl8SypGknn3jtF6eN1jLscMZNa+w
	8JxHZEtO7depFgsXMFhKjb8OfDMKT99w+1ldecVE0F6XyBScqV1sijkvZ5voEDVVmxqj
	PPmg==
X-Gm-Message-State: ALoCoQklg6KyqQdi9+l4F0lg3JFUvlL4OV/VXF59zc5f09pTZXIxZQx0uviSnvmsC0uV30ooP2s8
X-Received: by 10.112.219.227 with SMTP id pr3mr55492127lbc.63.1417475911353; 
	Mon, 01 Dec 2014 15:18:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.7.132 with HTTP; Mon, 1 Dec 2014 15:18:11 -0800 (PST)
In-Reply-To: <20141201153336.GB3180@laptop.dumpdata.com>
References: <cover.1414516558.git.luto@amacapital.net>
	<6b0c9b0fc128de68634c730a5b1a80e1d085ad02.1414516558.git.luto@amacapital.net>
	<20141028174629.GA2150@jtriplet-mobl1>
	<CALCETrUihPeKODJqi3tMYwyWYhML1Z=gr4wrVK5VnaFo=KGVJA@mail.gmail.com>
	<20141029200016.GK3424@laptop.dumpdata.com>
	<CALCETrW+f8S9fNrui_J34q3Ve4jwA=neGe-tYZ_Lbp+ML3LiRw@mail.gmail.com>
	<20141201153336.GB3180@laptop.dumpdata.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Mon, 1 Dec 2014 15:18:11 -0800
Message-ID: <CALCETrUR6RKPZ7XpEp6NNu7n2W4TdAPQTCkB8Tpc2iF2SfdROw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Josh Triplett <josh@joshtriplett.org>
Subject: Re: [Xen-devel] [PATCH 3/3] x86_64,
	vsyscall: Make vsyscall emulation 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Dec 1, 2014 2:08 PM, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:
>
> On Wed, Oct 29, 2014 at 02:30:29PM -0700, Andy Lutomirski wrote:
> > On Oct 29, 2014 1:00 PM, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:
> > >
> > > On Tue, Oct 28, 2014 at 11:09:53AM -0700, Andy Lutomirski wrote:
> > > > On Tue, Oct 28, 2014 at 10:57 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> > > > > On Tue, Oct 28, 2014 at 10:22:28AM -0700, Andy Lutomirski wrote:
> > > > >> This adds CONFIG_X86_VSYSCALL_EMULATION, guarded by CONFIG_EXPERT.
> > > > >> Turning it off completely disables vsyscall emulation, saving ~3.5k
> > > > >> for vsyscall_64.c, 4k for vsyscall_emu_64.S (the fake vsyscall
> > > > >> page), some tiny amount of core mm code that supports a gate area,
> > > > >> and possibly 4k for a wasted pagetable.  The latter is because the
> > > > >> vsyscall addresses are misaligned and fit poorly in the fixmap.
> > > > >>
> > > > >> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> > > > >
> > > > > One minor nit below, but with or without that change,
> > > > > Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> > > > >
> > > > >> --- a/arch/x86/xen/mmu.c
> > > > >> +++ b/arch/x86/xen/mmu.c
> > > > >> @@ -1456,11 +1456,13 @@ static int xen_pgd_alloc(struct mm_struct *mm)
> > > > >>               user_pgd = (pgd_t *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
> > > > >>               page->private = (unsigned long)user_pgd;
> > > > >>
> > > > >> +#ifdef CONFIG_X86_VSYSCALL_EMULATION
> > > > >>               if (user_pgd != NULL) {
> > > > >>                       user_pgd[pgd_index(VSYSCALL_ADDR)] =
> > > > >>                               __pgd(__pa(level3_user_vsyscall) | _PAGE_TABLE);
> > > > >>                       ret = 0;
> > > > >>               }
> > > > >> +#endif
> > > > >
> > > > > Could you instead make the if use IS_ENABLED?
> > > > >
> > > > >                 if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION) && user_pgd != NULL)
> > > > >
> > > > > That has the advantage of ensuring that the code continues to compile.
> > > > > (Given that you haven't removed level3_user_vsyscall, that should work.)
> > > >
> > > > I need the ret = 0, I think, so I'll resend.
> > > >
> > > > I think I'd rather use #ifdef here, since I think it would be great if
> > > > the Xen people could clean this up further.  With this change, under
> > > > some configurations, there should be no user-accessible kernel
> > > > addresses at all.  (Also, is there some PV mechanism
>
> What about the vsyscall time stamp (aka kvm-clock). That is not
> really VSYSCALL emulation based but normal code?

That's entirely separate now.

>
> > > > that I'm not thinking of that will break with this change?  I know
> > > > I've tripped over Xen pagetable and fixmap oddities before.)
> > >
> > > Not that I know of. The vsyscall is the only one that I know of that
> > > does this.
> >
> > There's kvm-clock, too, but that may never co-exist with Xen.
>
> It will eventually.

Hmm. Maybe I should clean up the read code first.

--Andy

> >
> > I tagged v2 here:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/tag/?id=optional-vsyscall-emulation-v2
> >
> > and I'll send it out in a bit.
> >
> > --Andy
> >
> > >
> > > Do you have a full patchset somewhere for testing?
> > > >
> > > > --Andy

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

From xen-devel-bounces@lists.xen.org Mon Dec 01 23:25:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 23:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvaLT-0000O4-N4; Mon, 01 Dec 2014 23: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.Jackson@citrix.com>) id 1XvaLS-0000Nz-Aw
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 23:25:30 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	09/58-07724-9E8FC745; Mon, 01 Dec 2014 23:25:29 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417476327!15130480!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22199 invoked from network); 1 Dec 2014 23:25:28 -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;
	1 Dec 2014 23:25:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,497,1413244800"; d="scan'208";a="198301150"
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, 1 Dec 2014 18:25: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 1XvaLN-0006oc-P5;
	Mon, 01 Dec 2014 23:25:25 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvaIa-00066Z-Uc;
	Mon, 01 Dec 2014 23:25:13 +0000
Date: Mon, 1 Dec 2014 23:22:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31969-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] 31969: 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 31969 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31969/

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 31941 REGR. vs. 31781

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)     broken pass in 31941
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 31941
 test-amd64-i386-pair          4 host-install/dst_host(4)  broken pass in 31941

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-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
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31941 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                                         broken  
 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-i386-pair host-install/src_host(3)
broken-step test-amd64-i386-pair host-install/dst_host(4)

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 Mon Dec 01 23:25:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 01 Dec 2014 23:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvaLT-0000O4-N4; Mon, 01 Dec 2014 23: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.Jackson@citrix.com>) id 1XvaLS-0000Nz-Aw
	for xen-devel@lists.xensource.com; Mon, 01 Dec 2014 23:25:30 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	09/58-07724-9E8FC745; Mon, 01 Dec 2014 23:25:29 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417476327!15130480!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22199 invoked from network); 1 Dec 2014 23:25:28 -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;
	1 Dec 2014 23:25:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,497,1413244800"; d="scan'208";a="198301150"
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, 1 Dec 2014 18:25: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 1XvaLN-0006oc-P5;
	Mon, 01 Dec 2014 23:25:25 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvaIa-00066Z-Uc;
	Mon, 01 Dec 2014 23:25:13 +0000
Date: Mon, 1 Dec 2014 23:22:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31969-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] 31969: 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 31969 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31969/

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 31941 REGR. vs. 31781

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)     broken pass in 31941
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 31941
 test-amd64-i386-pair          4 host-install/dst_host(4)  broken pass in 31941

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-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
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 31941 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                                         broken  
 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-i386-pair host-install/src_host(3)
broken-step test-amd64-i386-pair host-install/dst_host(4)

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 Tue Dec 02 00:26:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 00:26:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvbI0-00025J-86; Tue, 02 Dec 2014 00:26: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 1XvbHy-00025E-Sc
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 00:25:59 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2F/0D-15461-6170D745; Tue, 02 Dec 2014 00:25:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417479956!12721321!1
X-Originating-IP: [66.165.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 24317 invoked from network); 2 Dec 2014 00:25:57 -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;
	2 Dec 2014 00:25:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,497,1413244800"; d="scan'208";a="198319338"
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, 1 Dec 2014 19:25: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 1XvbHu-00076s-8P;
	Tue, 02 Dec 2014 00:25:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvbHt-00034R-PD;
	Tue, 02 Dec 2014 00:25:54 +0000
Date: Tue, 2 Dec 2014 00:25:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31972-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] 31972: 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 31972 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31972/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf                   4 host-build-prep           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-credit2   13 guest-saverestore.2         fail pass in 31922
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail in 31922 pass in 31972

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail like 26261
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot           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-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 build-armhf-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 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-qemut-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-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-libvirt      5 xen-boot              fail in 31922 never pass
 test-armhf-armhf-xl           5 xen-boot              fail in 31922 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                                                  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                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-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                                   fail    
 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


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 Dec 02 00:26:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 00:26:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvbI0-00025J-86; Tue, 02 Dec 2014 00:26: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 1XvbHy-00025E-Sc
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 00:25:59 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2F/0D-15461-6170D745; Tue, 02 Dec 2014 00:25:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417479956!12721321!1
X-Originating-IP: [66.165.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 24317 invoked from network); 2 Dec 2014 00:25:57 -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;
	2 Dec 2014 00:25:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,497,1413244800"; d="scan'208";a="198319338"
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, 1 Dec 2014 19:25: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 1XvbHu-00076s-8P;
	Tue, 02 Dec 2014 00:25:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvbHt-00034R-PD;
	Tue, 02 Dec 2014 00:25:54 +0000
Date: Tue, 2 Dec 2014 00:25:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31972-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] 31972: 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 31972 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31972/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf                   4 host-build-prep           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-credit2   13 guest-saverestore.2         fail pass in 31922
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail in 31922 pass in 31972

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail like 26261
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot           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-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 build-armhf-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 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-qemut-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-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-libvirt      5 xen-boot              fail in 31922 never pass
 test-armhf-armhf-xl           5 xen-boot              fail in 31922 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                                                  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                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-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                                   fail    
 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


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 Dec 02 02:45:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 02: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 1XvdRt-0001rl-PS; Tue, 02 Dec 2014 02:44:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XvdRr-0001re-Rc
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 02:44:19 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	32/08-17735-2872D745; Tue, 02 Dec 2014 02:44:18 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417488257!15188258!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 30316 invoked from network); 2 Dec 2014 02:44:18 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 02:44:18 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-82-26-166-100.pete.adsl.virginm.net
	([82.26.166.100]:51706 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 1XvdRk-0004O2-F9 (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 02 Dec 2014 02:44:14 +0000
Message-ID: <547D276C.2070805@citrix.com>
Date: Tue, 02 Dec 2014 02:43: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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>	<1417174284.23604.9.camel@citrix.com>
	<20141201203001.GE21626@laptop.dumpdata.com>
In-Reply-To: <20141201203001.GE21626@laptop.dumpdata.com>
Cc: wei.liu2@citrix.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian.Jackson@eu.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 01/12/2014 20:30, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 28, 2014 at 11:31:24AM +0000, Ian Campbell wrote:
>> 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.
> I am bit lost. I thought Andrew NACKed this?

I didn't, as I am not in a position to.  I have not tested the result,
but believe it is sufficient to fix the exact error at hand.  If the
maintainers think it is the best solution then so be it, but I am still
of the opinion that it is is still a hack upon a hack.

~Andrew

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 02:45:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 02: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 1XvdRt-0001rl-PS; Tue, 02 Dec 2014 02:44:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1XvdRr-0001re-Rc
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 02:44:19 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	32/08-17735-2872D745; Tue, 02 Dec 2014 02:44:18 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417488257!15188258!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 30316 invoked from network); 2 Dec 2014 02:44:18 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 02:44:18 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-82-26-166-100.pete.adsl.virginm.net
	([82.26.166.100]:51706 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 1XvdRk-0004O2-F9 (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 02 Dec 2014 02:44:14 +0000
Message-ID: <547D276C.2070805@citrix.com>
Date: Tue, 02 Dec 2014 02:43: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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>	<1417174284.23604.9.camel@citrix.com>
	<20141201203001.GE21626@laptop.dumpdata.com>
In-Reply-To: <20141201203001.GE21626@laptop.dumpdata.com>
Cc: wei.liu2@citrix.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Ian.Jackson@eu.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 01/12/2014 20:30, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 28, 2014 at 11:31:24AM +0000, Ian Campbell wrote:
>> 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.
> I am bit lost. I thought Andrew NACKed this?

I didn't, as I am not in a position to.  I have not tested the result,
but believe it is sufficient to fix the exact error at hand.  If the
maintainers think it is the best solution then so be it, but I am still
of the opinion that it is is still a hack upon a hack.

~Andrew

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 03:02:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 03: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 1XvdjC-0002Gj-O6; Tue, 02 Dec 2014 03:02: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 1XvdjB-0002Ge-8E
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 03:02:13 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	E9/4E-03148-4BB2D745; Tue, 02 Dec 2014 03:02:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417489330!6914944!1
X-Originating-IP: [66.165.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 25164 invoked from network); 2 Dec 2014 03:02:11 -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;
	2 Dec 2014 03:02:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,498,1413244800"; d="scan'208";a="198682058"
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, 1 Dec 2014 22:02: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 1Xvdj6-0007tD-TL;
	Tue, 02 Dec 2014 03: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 1Xvdj6-00083q-NF;
	Tue, 02 Dec 2014 03:02:08 +0000
Date: Tue, 2 Dec 2014 03:02:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31976-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] 31976: 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 31976 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31976/

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-amd64-libvirt      3 host-install(3)       broken baseline untested
 test-amd64-amd64-xl           3 host-install(3)       broken baseline untested
 test-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  5 xen-boot        fail baseline untested
 test-amd64-i386-freebsd10-i386  5 xen-boot              fail baseline untested
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                fail baseline untested
 test-armhf-armhf-xl           5 xen-boot                fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64  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-qemuu-ovmf-amd64  5 xen-boot         fail baseline untested
 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken baseline untested
 test-amd64-amd64-xl-qemuu-debianhvm-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-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 3 host-install(3) broken 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                3314bf6ba2ac8f1a2dd0d55a980835a258f1a45d

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                                           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                     broken  
 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                                     broken  
 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                     broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://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 Dec 02 03:02:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 03: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 1XvdjC-0002Gj-O6; Tue, 02 Dec 2014 03:02: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 1XvdjB-0002Ge-8E
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 03:02:13 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	E9/4E-03148-4BB2D745; Tue, 02 Dec 2014 03:02:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417489330!6914944!1
X-Originating-IP: [66.165.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 25164 invoked from network); 2 Dec 2014 03:02:11 -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;
	2 Dec 2014 03:02:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,498,1413244800"; d="scan'208";a="198682058"
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, 1 Dec 2014 22:02: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 1Xvdj6-0007tD-TL;
	Tue, 02 Dec 2014 03: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 1Xvdj6-00083q-NF;
	Tue, 02 Dec 2014 03:02:08 +0000
Date: Tue, 2 Dec 2014 03:02:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31976-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] 31976: 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 31976 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31976/

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-amd64-libvirt      3 host-install(3)       broken baseline untested
 test-amd64-amd64-xl           3 host-install(3)       broken baseline untested
 test-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  5 xen-boot        fail baseline untested
 test-amd64-i386-freebsd10-i386  5 xen-boot              fail baseline untested
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                fail baseline untested
 test-armhf-armhf-xl           5 xen-boot                fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64  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-qemuu-ovmf-amd64  5 xen-boot         fail baseline untested
 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken baseline untested
 test-amd64-amd64-xl-qemuu-debianhvm-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-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 3 host-install(3) broken 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                3314bf6ba2ac8f1a2dd0d55a980835a258f1a45d

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                                           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                     broken  
 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                                     broken  
 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                     broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://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 Dec 02 07:40:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 07:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvi44-00056W-O3; Tue, 02 Dec 2014 07:40:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1Xvi42-00056R-RL
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 07:40:03 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	52/7C-22737-1DC6D745; Tue, 02 Dec 2014 07:40:01 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417505999!5680501!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32400 invoked from network); 2 Dec 2014 07:40:00 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-206.messagelabs.com with SMTP;
	2 Dec 2014 07:40:00 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 01 Dec 2014 23:39:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="617107801"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga001.jf.intel.com with ESMTP; 01 Dec 2014 23:39:56 -0800
Message-ID: <547D6C86.4090400@linux.intel.com>
Date: Tue, 02 Dec 2014 15:38:46 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.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: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
In-Reply-To: <20141201121300.GB69236@deinos.phlegethon.org>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/1/2014 8:13 PM, Tim Deegan wrote:
> At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>>>>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>>> At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
>>>>>>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
>>>>> To my understanding, pages with p2m_ram_ro are not supposed to be
>>>>> modified by guest. So in __hvm_copy(), when p2m type of a page is
>>>>> p2m_ram_rom, no copy will occur.
>>>>> However, to our usage, we just wanna this page to be write protected, so
>>>>> that our device model can be triggered to do some emulation. The content
>>>>> written to this page is supposed not to be dropped. This way, if
>>>>> sequentially a read operation is performed by guest to this page, the
>>>>> guest will still see its anticipated value.
>>>>
>>>> __hvm_copy() is only a helper function, and doesn't write to
>>>> mmio_dm space either; instead its (indirect) callers would invoke
>>>> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
>>>> returns. The question hence is about the apparent inconsistency
>>>> resulting from writes to ram_ro being dropped here but getting
>>>> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
>>>> that really intentional?
>>>
>>> No - and AFAICT it shouldn't be happening.  It _is_ how it was
>>> implemented originally, because it involved fewer moving parts and
>>> didn't need to be efficient (and after all, writes to entirely missing
>>> addresses go to the device model too).
>>>
>>> But the code was later updated to log and discard writes to read-only
>>> memory (see 4d8aa29 from Trolle Selander).
>>>
>>> Early version of p2m_ram_ro were documented in the internal headers as
>>> sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
>>> has always said that writes are discarded.
>>
>> Hmm, so which way do you recommend resolving the inconsistency
>> then - match what the public interface says or what the apparent
>> original intention for the internal type was? Presumably we need to
>> follow the public interface mandated model, and hence require the
>> new type to be introduced.
>
> Sorry, I was unclear -- there isn't an inconsistency; both internal
> and public headers currently say that writes are discarded and AFAICT
> that is what the code does.
>
> But yes, we ought to follow the established hypercall interface, and
> so we need the new type.
>
>>> During this bit of archaeology I realised that either this new type
>>> should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
>>> class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
>>> for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
>>> just p2m_ram_ro and p2m_grant_map_ro.
>>
>> And I suppose in that latter case the new type could be made part
>> of P2M_RO_TYPES()?
>
> Yes indeed, as P2M_RO_TYPES is defined as "must have the _PAGE_RW bit
> clear in their PTEs".
>

Thanks Tim.
Following are my understanding of the P2M_RO_TYPES and your comments.
Not sure if I get it right. Please correct me if anything wrong:
1> The P2M_RO_TYPES now bears 2 meanings: one is "w bit is clear in the 
pte"; and another being to discard the write operations;
2> We better define another class to bear the second meaning.

Also some questions for the new p2m class, say P2M_DISCARD_WRITE_TYPES, 
and the new predicates, say p2m_is_discard_write:
1> You mentioned emulate_gva_to_mfn() and __hvm_copy() should discard 
the write ops, yet I also noticed many other places using the 
p2m_is_readonly, or only the "p2mt == p2m_ram_ro" judgement(in 
__hvm_copy/__hvm_clear). Among all these other places, is there any ones 
also supposed to use the p2m_is_discard_write?
2> p2m_grant_map_ro is also supposed to be discarded? Will handling of 
this type of pages goes into __hvm_copy()/__hvm_clear(), or should?

I'm a new guy of this area, and sorry for my messed questions. :)

Yu




> 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 Dec 02 07:40:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 07:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvi44-00056W-O3; Tue, 02 Dec 2014 07:40:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1Xvi42-00056R-RL
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 07:40:03 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	52/7C-22737-1DC6D745; Tue, 02 Dec 2014 07:40:01 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417505999!5680501!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32400 invoked from network); 2 Dec 2014 07:40:00 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-206.messagelabs.com with SMTP;
	2 Dec 2014 07:40:00 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 01 Dec 2014 23:39:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="617107801"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga001.jf.intel.com with ESMTP; 01 Dec 2014 23:39:56 -0800
Message-ID: <547D6C86.4090400@linux.intel.com>
Date: Tue, 02 Dec 2014 15:38:46 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.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: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
In-Reply-To: <20141201121300.GB69236@deinos.phlegethon.org>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/1/2014 8:13 PM, Tim Deegan wrote:
> At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>>>>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>>> At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
>>>>>>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
>>>>> To my understanding, pages with p2m_ram_ro are not supposed to be
>>>>> modified by guest. So in __hvm_copy(), when p2m type of a page is
>>>>> p2m_ram_rom, no copy will occur.
>>>>> However, to our usage, we just wanna this page to be write protected, so
>>>>> that our device model can be triggered to do some emulation. The content
>>>>> written to this page is supposed not to be dropped. This way, if
>>>>> sequentially a read operation is performed by guest to this page, the
>>>>> guest will still see its anticipated value.
>>>>
>>>> __hvm_copy() is only a helper function, and doesn't write to
>>>> mmio_dm space either; instead its (indirect) callers would invoke
>>>> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
>>>> returns. The question hence is about the apparent inconsistency
>>>> resulting from writes to ram_ro being dropped here but getting
>>>> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
>>>> that really intentional?
>>>
>>> No - and AFAICT it shouldn't be happening.  It _is_ how it was
>>> implemented originally, because it involved fewer moving parts and
>>> didn't need to be efficient (and after all, writes to entirely missing
>>> addresses go to the device model too).
>>>
>>> But the code was later updated to log and discard writes to read-only
>>> memory (see 4d8aa29 from Trolle Selander).
>>>
>>> Early version of p2m_ram_ro were documented in the internal headers as
>>> sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
>>> has always said that writes are discarded.
>>
>> Hmm, so which way do you recommend resolving the inconsistency
>> then - match what the public interface says or what the apparent
>> original intention for the internal type was? Presumably we need to
>> follow the public interface mandated model, and hence require the
>> new type to be introduced.
>
> Sorry, I was unclear -- there isn't an inconsistency; both internal
> and public headers currently say that writes are discarded and AFAICT
> that is what the code does.
>
> But yes, we ought to follow the established hypercall interface, and
> so we need the new type.
>
>>> During this bit of archaeology I realised that either this new type
>>> should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
>>> class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
>>> for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
>>> just p2m_ram_ro and p2m_grant_map_ro.
>>
>> And I suppose in that latter case the new type could be made part
>> of P2M_RO_TYPES()?
>
> Yes indeed, as P2M_RO_TYPES is defined as "must have the _PAGE_RW bit
> clear in their PTEs".
>

Thanks Tim.
Following are my understanding of the P2M_RO_TYPES and your comments.
Not sure if I get it right. Please correct me if anything wrong:
1> The P2M_RO_TYPES now bears 2 meanings: one is "w bit is clear in the 
pte"; and another being to discard the write operations;
2> We better define another class to bear the second meaning.

Also some questions for the new p2m class, say P2M_DISCARD_WRITE_TYPES, 
and the new predicates, say p2m_is_discard_write:
1> You mentioned emulate_gva_to_mfn() and __hvm_copy() should discard 
the write ops, yet I also noticed many other places using the 
p2m_is_readonly, or only the "p2mt == p2m_ram_ro" judgement(in 
__hvm_copy/__hvm_clear). Among all these other places, is there any ones 
also supposed to use the p2m_is_discard_write?
2> p2m_grant_map_ro is also supposed to be discarded? Will handling of 
this type of pages goes into __hvm_copy()/__hvm_clear(), or should?

I'm a new guy of this area, and sorry for my messed questions. :)

Yu




> 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 Dec 02 07:50:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 07:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XviDZ-0005Kh-19; Tue, 02 Dec 2014 07:49:53 +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 1XviDX-0005Kc-Rj
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 07:49:51 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F9/65-15461-F1F6D745; Tue, 02 Dec 2014 07:49:51 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417506589!12742057!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8668 invoked from network); 2 Dec 2014 07:49:50 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-15.tower-21.messagelabs.com with SMTP;
	2 Dec 2014 07:49:50 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 23:46:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="617111126"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga001.jf.intel.com with ESMTP; 01 Dec 2014 23:49:46 -0800
Message-ID: <547D6ED6.2030803@linux.intel.com>
Date: Tue, 02 Dec 2014 15:48:38 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.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 Deegan <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547C6D98020000780004BB9D@mail.emea.novell.com>
In-Reply-To: <547C6D98020000780004BB9D@mail.emea.novell.com>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/1/2014 8:31 PM, Jan Beulich wrote:
>>>> On 01.12.14 at 13:13, <tim@xen.org> wrote:
>> At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>>>>>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>>>> At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
>>>>>>>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
>>>>>> To my understanding, pages with p2m_ram_ro are not supposed to be
>>>>>> modified by guest. So in __hvm_copy(), when p2m type of a page is
>>>>>> p2m_ram_rom, no copy will occur.
>>>>>> However, to our usage, we just wanna this page to be write protected, so
>>>>>> that our device model can be triggered to do some emulation. The content
>>>>>> written to this page is supposed not to be dropped. This way, if
>>>>>> sequentially a read operation is performed by guest to this page, the
>>>>>> guest will still see its anticipated value.
>>>>>
>>>>> __hvm_copy() is only a helper function, and doesn't write to
>>>>> mmio_dm space either; instead its (indirect) callers would invoke
>>>>> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
>>>>> returns. The question hence is about the apparent inconsistency
>>>>> resulting from writes to ram_ro being dropped here but getting
>>>>> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
>>>>> that really intentional?
>>>>
>>>> No - and AFAICT it shouldn't be happening.  It _is_ how it was
>>>> implemented originally, because it involved fewer moving parts and
>>>> didn't need to be efficient (and after all, writes to entirely missing
>>>> addresses go to the device model too).
>>>>
>>>> But the code was later updated to log and discard writes to read-only
>>>> memory (see 4d8aa29 from Trolle Selander).
>>>>
>>>> Early version of p2m_ram_ro were documented in the internal headers as
>>>> sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
>>>> has always said that writes are discarded.
>>>
>>> Hmm, so which way do you recommend resolving the inconsistency
>>> then - match what the public interface says or what the apparent
>>> original intention for the internal type was? Presumably we need to
>>> follow the public interface mandated model, and hence require the
>>> new type to be introduced.
>>
>> Sorry, I was unclear -- there isn't an inconsistency; both internal
>> and public headers currently say that writes are discarded and AFAICT
>> that is what the code does.
>
> Not for hvm_hap_nested_page_fault() afaict - the forwarding to
> DM there contradicts the "writes are discarded" model that other
> code paths follow.
>
Thanks, Jan.
By "inconsistency", do you mean the p2m_ram_ro shall not trigger the 
handle_mmio_with_translation() in hvm_hap_nested_page_fault()?
I'm also a bit confused with the "writes are discarded/dropped" comments 
in the code. Does this mean writes to the p2m_ram_ro pages should be 
abandoned without going to the dm, or going to the dm and  ignored 
later? The code seems to be the second one.

> Jan
>
>
>

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 07:50:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 07:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XviDZ-0005Kh-19; Tue, 02 Dec 2014 07:49:53 +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 1XviDX-0005Kc-Rj
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 07:49:51 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F9/65-15461-F1F6D745; Tue, 02 Dec 2014 07:49:51 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417506589!12742057!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8668 invoked from network); 2 Dec 2014 07:49:50 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-15.tower-21.messagelabs.com with SMTP;
	2 Dec 2014 07:49:50 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 01 Dec 2014 23:46:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="617111126"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga001.jf.intel.com with ESMTP; 01 Dec 2014 23:49:46 -0800
Message-ID: <547D6ED6.2030803@linux.intel.com>
Date: Tue, 02 Dec 2014 15:48:38 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.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 Deegan <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547C6D98020000780004BB9D@mail.emea.novell.com>
In-Reply-To: <547C6D98020000780004BB9D@mail.emea.novell.com>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/1/2014 8:31 PM, Jan Beulich wrote:
>>>> On 01.12.14 at 13:13, <tim@xen.org> wrote:
>> At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>>>>>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>>>> At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
>>>>>>>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
>>>>>> To my understanding, pages with p2m_ram_ro are not supposed to be
>>>>>> modified by guest. So in __hvm_copy(), when p2m type of a page is
>>>>>> p2m_ram_rom, no copy will occur.
>>>>>> However, to our usage, we just wanna this page to be write protected, so
>>>>>> that our device model can be triggered to do some emulation. The content
>>>>>> written to this page is supposed not to be dropped. This way, if
>>>>>> sequentially a read operation is performed by guest to this page, the
>>>>>> guest will still see its anticipated value.
>>>>>
>>>>> __hvm_copy() is only a helper function, and doesn't write to
>>>>> mmio_dm space either; instead its (indirect) callers would invoke
>>>>> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
>>>>> returns. The question hence is about the apparent inconsistency
>>>>> resulting from writes to ram_ro being dropped here but getting
>>>>> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
>>>>> that really intentional?
>>>>
>>>> No - and AFAICT it shouldn't be happening.  It _is_ how it was
>>>> implemented originally, because it involved fewer moving parts and
>>>> didn't need to be efficient (and after all, writes to entirely missing
>>>> addresses go to the device model too).
>>>>
>>>> But the code was later updated to log and discard writes to read-only
>>>> memory (see 4d8aa29 from Trolle Selander).
>>>>
>>>> Early version of p2m_ram_ro were documented in the internal headers as
>>>> sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
>>>> has always said that writes are discarded.
>>>
>>> Hmm, so which way do you recommend resolving the inconsistency
>>> then - match what the public interface says or what the apparent
>>> original intention for the internal type was? Presumably we need to
>>> follow the public interface mandated model, and hence require the
>>> new type to be introduced.
>>
>> Sorry, I was unclear -- there isn't an inconsistency; both internal
>> and public headers currently say that writes are discarded and AFAICT
>> that is what the code does.
>
> Not for hvm_hap_nested_page_fault() afaict - the forwarding to
> DM there contradicts the "writes are discarded" model that other
> code paths follow.
>
Thanks, Jan.
By "inconsistency", do you mean the p2m_ram_ro shall not trigger the 
handle_mmio_with_translation() in hvm_hap_nested_page_fault()?
I'm also a bit confused with the "writes are discarded/dropped" comments 
in the code. Does this mean writes to the p2m_ram_ro pages should be 
abandoned without going to the dm, or going to the dm and  ignored 
later? The code seems to be the second one.

> Jan
>
>
>

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 07:54:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 07: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 1XviI4-0005WE-Np; Tue, 02 Dec 2014 07:54:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1XviI3-0005W9-2f
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 07:54:31 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	E6/1C-17694-6307D745; Tue, 02 Dec 2014 07:54:30 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417506869!11439691!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 10931 invoked from network); 2 Dec 2014 07:54:29 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-9.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 07:54:29 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id sB27sJAs013256;
	Tue, 2 Dec 2014 01:54:19 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id sB27sJOW013255;
	Tue, 2 Dec 2014 01:54:19 -0600
Date: Tue, 2 Dec 2014 01:54:19 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201412020754.sB27sJOW013255@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
	29, 1:09pm)
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]);
	Tue, 02 Dec 2014 01:54:19 -0600 (CST)
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
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 29,  1:09pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:
} Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.

Good morning Pasi, thanks for taking the time to follow up.

> > > > 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.

I just fired up a pass-through session to check on this.  The driver
version and date are as follows:

	Driver Date:		09/26/2014
	Driver Version:		10.18.10.29458

They were the most current version of the driver available on Intel's
website as of a week ago.

As soon as we sort out the details on whether or not we can get the
IGD device re-started we will put a patch up on our FTP server with
the changes needed to implement both ATI and IGD passthrough on 4.4.1
as a resource to the community.

> Thanks,
>  
> -- Pasi

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
------------------------------------------------------------------------------
"In the future, company names will be a 32-character hex string."
                                -- Bruce Schneier

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 07:54:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 07: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 1XviI4-0005WE-Np; Tue, 02 Dec 2014 07:54:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1XviI3-0005W9-2f
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 07:54:31 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	E6/1C-17694-6307D745; Tue, 02 Dec 2014 07:54:30 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417506869!11439691!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 10931 invoked from network); 2 Dec 2014 07:54:29 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-9.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 07:54:29 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id sB27sJAs013256;
	Tue, 2 Dec 2014 01:54:19 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id sB27sJOW013255;
	Tue, 2 Dec 2014 01:54:19 -0600
Date: Tue, 2 Dec 2014 01:54:19 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201412020754.sB27sJOW013255@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
	29, 1:09pm)
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]);
	Tue, 02 Dec 2014 01:54:19 -0600 (CST)
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
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 29,  1:09pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:
} Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.

Good morning Pasi, thanks for taking the time to follow up.

> > > > 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.

I just fired up a pass-through session to check on this.  The driver
version and date are as follows:

	Driver Date:		09/26/2014
	Driver Version:		10.18.10.29458

They were the most current version of the driver available on Intel's
website as of a week ago.

As soon as we sort out the details on whether or not we can get the
IGD device re-started we will put a patch up on our FTP server with
the changes needed to implement both ATI and IGD passthrough on 4.4.1
as a resource to the community.

> Thanks,
>  
> -- Pasi

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
------------------------------------------------------------------------------
"In the future, company names will be a 32-character hex string."
                                -- Bruce Schneier

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 08:31:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 08:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvirP-0006J1-6a; Tue, 02 Dec 2014 08:31:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@gmail.com>) id 1XvirN-0006Iw-1L
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 08:31:01 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	52/E8-20609-4C87D745; Tue, 02 Dec 2014 08:31:00 +0000
X-Env-Sender: zhangleiqiang@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417509057!12393999!1
X-Originating-IP: [209.85.220.53]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 870 invoked from network); 2 Dec 2014 08:30:58 -0000
Received: from mail-pa0-f53.google.com (HELO mail-pa0-f53.google.com)
	(209.85.220.53)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 08:30:58 -0000
Received: by mail-pa0-f53.google.com with SMTP id kq14so12976247pab.12
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 00:30:57 -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:subject
	:message-id:date:to;
	bh=fk/p7iazc8JOoxiJ8r482qxW8TEctmplquJSNZ24Q60=;
	b=P/ez0zQ8p3ZmrvTBClqJd3dBUgJiVnS0U5O18fK9jJnODGKbjdGZAJK2SH1BKz7/S/
	z4/GY1AyOlT40uoqeEC6ZJnLwIAfuW07aPGlMmw1U5tzha8e6YrT9ZBoc/uUXML+qx5l
	nOoX7fx426RvGkZqQCdw7spU2TxckOMCc9YSXzxa27bWqsf53G0rR6vO/briiUciXU4b
	Ab2X/BsgXEN6mFWdNbVAkyawI7+v60b+4S436SQjvJglknsgZQ0OOZM1N1Dl0wZLiexT
	sB0ilPaToZmSu22PX5cUEJTIPAQ5IoIa4WE4XChRtDMFI7gvf1DZGscN62BapWj+VLSL
	rIqQ==
X-Received: by 10.70.133.72 with SMTP id pa8mr106895982pdb.59.1417509057115;
	Tue, 02 Dec 2014 00:30:57 -0800 (PST)
Received: from [10.62.5.220] ([36.45.0.12]) by mx.google.com with ESMTPSA id
	wl10sm19506759pbc.58.2014.12.02.00.30.54
	for <xen-devel@lists.xen.org>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 02 Dec 2014 00:30:55 -0800 (PST)
From: zhangleiqiang <zhangleiqiang@gmail.com>
Mime-Version: 1.0 (1.0)
Message-Id: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
Date: Tue, 2 Dec 2014 16:30:49 +0800
To: xen-devel@lists.xen.org
X-Mailer: iPhone Mail (12B411)
Subject: [Xen-devel] Poor network performance between DomU with multiqueue
	support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1327411302560573387=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1327411302560573387==
Content-Type: multipart/alternative;
	boundary=Apple-Mail-043A107B-8FBB-48C3-8335-0EE6E2C01279
Content-Transfer-Encoding: 7bit


--Apple-Mail-043A107B-8FBB-48C3-8335-0EE6E2C01279
Content-Type: text/plain;
	charset=gb2312
Content-Transfer-Encoding: quoted-printable

Hi, all
    I am testing the performance of xen netfront-netback driver that with mu=
lti-queues support. The throughput from domU to remote dom0 is 9.2Gb/s, but t=
he throughput from domU to remote domU is only 3.6Gb/s, I think the bottlene=
ck is the throughput from dom0 to local domU. However, we have done some tes=
ting and found the throughput from dom0 to local domU is 5.8Gb/s.
    And if we send packets from one DomU to other 3 DomUs on different host s=
imultaneously, the sum of throughout can reach 9Gbps. It seems like the bott=
leneck is the receiver?
    After some analysis, I found that even the max_queue of netfront/back is=
 set to 4, there are some strange results as follows:
    1. In domU, only one rx queue deal with softirq
    2. In dom0, only two netback queues process are scheduled, other two pro=
cess aren't scheduled.

    Are there any issues in my test? In theory, can we achieve 9~10Gb/s betw=
een DomUs on different hosts using netfront/netback?
   =20
     The testing environment details are as follows:
   1. Hardware
       a. CPU: Intel(R) Xeon(R) CPU E5645 @ 2.40GHz, 2 CPU 6 Cores with Hype=
r Thread enabled
       b. NIC: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connect=
ion (rev 01)
   2. Sofware:
       a. HostOS: SLES 12 (Kernel 3.16-7,git commit d0335e4feea0d3f7a8af3116=
c5dc166239da7521 )
       b. NIC Driver: IXGBE 3.21.2=20
       c. OVS: 2.1.3
       d. MTU: 1600
       e. Dom0=A3=BA6U6G
       f. queue number: 4
       g. xen 4.4
       h. DomU: 4U4G
   3. Networking Environment:
       a. All network flows are transmit/receive through OVS
       b. Sender server and receiver server are connected directly between 1=
0GE NIC
   4. Testing Tools:
       a. Sender: netperf
       b. Receiver: netserver


----------
zhangleiqiang (Trump)
Best Regards=

--Apple-Mail-043A107B-8FBB-48C3-8335-0EE6E2C01279
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><span style=3D"background-color: rgba(=
255, 255, 255, 0);">Hi, all</span></div><div><span style=3D"background-color=
: rgba(255, 255, 255, 0);">&nbsp; &nbsp; I am testing the performance of xen=
 netfront-netback driver that with multi-queues support. The throughput from=
 domU to remote dom0 is 9.2Gb/s, but the throughput from domU to remote domU=
 is only 3.6Gb/s, I think the bottleneck is the throughput from dom0 to loca=
l domU. However, we have done some testing and found the throughput from dom=
0 to local domU is 5.8Gb/s.</span></div><div><span style=3D"background-color=
: rgba(255, 255, 255, 0);">&nbsp; &nbsp; And if we send packets from one Dom=
U to other 3 DomUs on different host simultaneously, the sum of throughout c=
an reach 9Gbps. It seems like the bottleneck is the receiver?</span></div><d=
iv><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; A=
fter some analysis, I found that even the max_queue of netfront/back is set t=
o 4, there are some strange results as follows:</span></div><div><span style=
=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; 1. In domU, onl=
y one rx queue deal with softirq</span></div><div><span style=3D"background-=
color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; 2. In dom0, only two netback q=
ueues process are scheduled, other two process aren't scheduled.</span></div=
><div><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></span><=
/div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &=
nbsp; Are there any issues in my test? In theory, can we achieve 9~10Gb/s be=
tween DomUs on different hosts using netfront/netback?</span></div><div><spa=
n style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp;&nbsp;</s=
pan></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">&nb=
sp; &nbsp; &nbsp;The testing environment details are as follows:</span></div=
><div><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp=
;1. Hardware</span></div><div><span style=3D"background-color: rgba(255, 255=
, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;a. CPU: Intel(R) Xeon(R) CPU E5645 @ 2=
.40GHz, 2 CPU 6 Cores with Hyper Thread enabled</span></div><div><span style=
=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;b.=
 NIC: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 0=
1)</span></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);=
">&nbsp; &nbsp;2. Sofware:</span></div><div><span style=3D"background-color:=
 rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;a. HostOS: SLES 12 (Ker=
nel&nbsp;<a href=3D"x-apple-data-detectors://0" x-apple-data-detectors=3D"tr=
ue" x-apple-data-detectors-type=3D"calendar-event" x-apple-data-detectors-re=
sult=3D"0">3.16-7</a>,git commit d0335e4feea0d3f7a8af3116c5dc166239da7521 )<=
/span></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">&=
nbsp; &nbsp; &nbsp; &nbsp;b. NIC Driver: IXGBE 3.21.2&nbsp;</span></div><div=
><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nb=
sp; &nbsp;c. OVS: 2.1.3</span></div><div><span style=3D"background-color: rg=
ba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;d. MTU: 1600</span></div><=
div><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &=
nbsp; &nbsp;e. Dom0=EF=BC=9A6U6G</span></div><div><span style=3D"background-=
color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;f. queue number: 4=
</span></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">=
&nbsp; &nbsp; &nbsp; &nbsp;g. xen 4.4</span></div><div><span style=3D"backgr=
ound-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;h. DomU: 4U4=
G</span></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);"=
>&nbsp; &nbsp;3. Networking Environment:</span></div><div><span style=3D"bac=
kground-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;a. All ne=
twork flows are transmit/receive through OVS</span></div><div><span style=3D=
"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;b. Se=
nder server and receiver server are connected directly between 10GE NIC</spa=
n></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp=
; &nbsp;4. Testing Tools:</span></div><div><span style=3D"background-color: r=
gba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;a. Sender: netperf</span>=
</div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &=
nbsp; &nbsp; &nbsp;b. Receiver: netserver</span></div><div><span style=3D"ba=
ckground-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style=3D=
"background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span styl=
e=3D"background-color: rgba(255, 255, 255, 0);">----------</span></div><div>=
zhangleiqiang (Trump)</div><div>Best Regards</div></body></html>=

--Apple-Mail-043A107B-8FBB-48C3-8335-0EE6E2C01279--


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

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

--===============1327411302560573387==--


From xen-devel-bounces@lists.xen.org Tue Dec 02 08:31:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 08:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvirP-0006J1-6a; Tue, 02 Dec 2014 08:31:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@gmail.com>) id 1XvirN-0006Iw-1L
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 08:31:01 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	52/E8-20609-4C87D745; Tue, 02 Dec 2014 08:31:00 +0000
X-Env-Sender: zhangleiqiang@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417509057!12393999!1
X-Originating-IP: [209.85.220.53]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 870 invoked from network); 2 Dec 2014 08:30:58 -0000
Received: from mail-pa0-f53.google.com (HELO mail-pa0-f53.google.com)
	(209.85.220.53)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 08:30:58 -0000
Received: by mail-pa0-f53.google.com with SMTP id kq14so12976247pab.12
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 00:30:57 -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:subject
	:message-id:date:to;
	bh=fk/p7iazc8JOoxiJ8r482qxW8TEctmplquJSNZ24Q60=;
	b=P/ez0zQ8p3ZmrvTBClqJd3dBUgJiVnS0U5O18fK9jJnODGKbjdGZAJK2SH1BKz7/S/
	z4/GY1AyOlT40uoqeEC6ZJnLwIAfuW07aPGlMmw1U5tzha8e6YrT9ZBoc/uUXML+qx5l
	nOoX7fx426RvGkZqQCdw7spU2TxckOMCc9YSXzxa27bWqsf53G0rR6vO/briiUciXU4b
	Ab2X/BsgXEN6mFWdNbVAkyawI7+v60b+4S436SQjvJglknsgZQ0OOZM1N1Dl0wZLiexT
	sB0ilPaToZmSu22PX5cUEJTIPAQ5IoIa4WE4XChRtDMFI7gvf1DZGscN62BapWj+VLSL
	rIqQ==
X-Received: by 10.70.133.72 with SMTP id pa8mr106895982pdb.59.1417509057115;
	Tue, 02 Dec 2014 00:30:57 -0800 (PST)
Received: from [10.62.5.220] ([36.45.0.12]) by mx.google.com with ESMTPSA id
	wl10sm19506759pbc.58.2014.12.02.00.30.54
	for <xen-devel@lists.xen.org>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 02 Dec 2014 00:30:55 -0800 (PST)
From: zhangleiqiang <zhangleiqiang@gmail.com>
Mime-Version: 1.0 (1.0)
Message-Id: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
Date: Tue, 2 Dec 2014 16:30:49 +0800
To: xen-devel@lists.xen.org
X-Mailer: iPhone Mail (12B411)
Subject: [Xen-devel] Poor network performance between DomU with multiqueue
	support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1327411302560573387=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1327411302560573387==
Content-Type: multipart/alternative;
	boundary=Apple-Mail-043A107B-8FBB-48C3-8335-0EE6E2C01279
Content-Transfer-Encoding: 7bit


--Apple-Mail-043A107B-8FBB-48C3-8335-0EE6E2C01279
Content-Type: text/plain;
	charset=gb2312
Content-Transfer-Encoding: quoted-printable

Hi, all
    I am testing the performance of xen netfront-netback driver that with mu=
lti-queues support. The throughput from domU to remote dom0 is 9.2Gb/s, but t=
he throughput from domU to remote domU is only 3.6Gb/s, I think the bottlene=
ck is the throughput from dom0 to local domU. However, we have done some tes=
ting and found the throughput from dom0 to local domU is 5.8Gb/s.
    And if we send packets from one DomU to other 3 DomUs on different host s=
imultaneously, the sum of throughout can reach 9Gbps. It seems like the bott=
leneck is the receiver?
    After some analysis, I found that even the max_queue of netfront/back is=
 set to 4, there are some strange results as follows:
    1. In domU, only one rx queue deal with softirq
    2. In dom0, only two netback queues process are scheduled, other two pro=
cess aren't scheduled.

    Are there any issues in my test? In theory, can we achieve 9~10Gb/s betw=
een DomUs on different hosts using netfront/netback?
   =20
     The testing environment details are as follows:
   1. Hardware
       a. CPU: Intel(R) Xeon(R) CPU E5645 @ 2.40GHz, 2 CPU 6 Cores with Hype=
r Thread enabled
       b. NIC: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connect=
ion (rev 01)
   2. Sofware:
       a. HostOS: SLES 12 (Kernel 3.16-7,git commit d0335e4feea0d3f7a8af3116=
c5dc166239da7521 )
       b. NIC Driver: IXGBE 3.21.2=20
       c. OVS: 2.1.3
       d. MTU: 1600
       e. Dom0=A3=BA6U6G
       f. queue number: 4
       g. xen 4.4
       h. DomU: 4U4G
   3. Networking Environment:
       a. All network flows are transmit/receive through OVS
       b. Sender server and receiver server are connected directly between 1=
0GE NIC
   4. Testing Tools:
       a. Sender: netperf
       b. Receiver: netserver


----------
zhangleiqiang (Trump)
Best Regards=

--Apple-Mail-043A107B-8FBB-48C3-8335-0EE6E2C01279
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><span style=3D"background-color: rgba(=
255, 255, 255, 0);">Hi, all</span></div><div><span style=3D"background-color=
: rgba(255, 255, 255, 0);">&nbsp; &nbsp; I am testing the performance of xen=
 netfront-netback driver that with multi-queues support. The throughput from=
 domU to remote dom0 is 9.2Gb/s, but the throughput from domU to remote domU=
 is only 3.6Gb/s, I think the bottleneck is the throughput from dom0 to loca=
l domU. However, we have done some testing and found the throughput from dom=
0 to local domU is 5.8Gb/s.</span></div><div><span style=3D"background-color=
: rgba(255, 255, 255, 0);">&nbsp; &nbsp; And if we send packets from one Dom=
U to other 3 DomUs on different host simultaneously, the sum of throughout c=
an reach 9Gbps. It seems like the bottleneck is the receiver?</span></div><d=
iv><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; A=
fter some analysis, I found that even the max_queue of netfront/back is set t=
o 4, there are some strange results as follows:</span></div><div><span style=
=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; 1. In domU, onl=
y one rx queue deal with softirq</span></div><div><span style=3D"background-=
color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; 2. In dom0, only two netback q=
ueues process are scheduled, other two process aren't scheduled.</span></div=
><div><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></span><=
/div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &=
nbsp; Are there any issues in my test? In theory, can we achieve 9~10Gb/s be=
tween DomUs on different hosts using netfront/netback?</span></div><div><spa=
n style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp;&nbsp;</s=
pan></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">&nb=
sp; &nbsp; &nbsp;The testing environment details are as follows:</span></div=
><div><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp=
;1. Hardware</span></div><div><span style=3D"background-color: rgba(255, 255=
, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;a. CPU: Intel(R) Xeon(R) CPU E5645 @ 2=
.40GHz, 2 CPU 6 Cores with Hyper Thread enabled</span></div><div><span style=
=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;b.=
 NIC: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 0=
1)</span></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);=
">&nbsp; &nbsp;2. Sofware:</span></div><div><span style=3D"background-color:=
 rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;a. HostOS: SLES 12 (Ker=
nel&nbsp;<a href=3D"x-apple-data-detectors://0" x-apple-data-detectors=3D"tr=
ue" x-apple-data-detectors-type=3D"calendar-event" x-apple-data-detectors-re=
sult=3D"0">3.16-7</a>,git commit d0335e4feea0d3f7a8af3116c5dc166239da7521 )<=
/span></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">&=
nbsp; &nbsp; &nbsp; &nbsp;b. NIC Driver: IXGBE 3.21.2&nbsp;</span></div><div=
><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nb=
sp; &nbsp;c. OVS: 2.1.3</span></div><div><span style=3D"background-color: rg=
ba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;d. MTU: 1600</span></div><=
div><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &=
nbsp; &nbsp;e. Dom0=EF=BC=9A6U6G</span></div><div><span style=3D"background-=
color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;f. queue number: 4=
</span></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">=
&nbsp; &nbsp; &nbsp; &nbsp;g. xen 4.4</span></div><div><span style=3D"backgr=
ound-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;h. DomU: 4U4=
G</span></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);"=
>&nbsp; &nbsp;3. Networking Environment:</span></div><div><span style=3D"bac=
kground-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;a. All ne=
twork flows are transmit/receive through OVS</span></div><div><span style=3D=
"background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;b. Se=
nder server and receiver server are connected directly between 10GE NIC</spa=
n></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp=
; &nbsp;4. Testing Tools:</span></div><div><span style=3D"background-color: r=
gba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp;a. Sender: netperf</span>=
</div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">&nbsp; &=
nbsp; &nbsp; &nbsp;b. Receiver: netserver</span></div><div><span style=3D"ba=
ckground-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style=3D=
"background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span styl=
e=3D"background-color: rgba(255, 255, 255, 0);">----------</span></div><div>=
zhangleiqiang (Trump)</div><div>Best Regards</div></body></html>=

--Apple-Mail-043A107B-8FBB-48C3-8335-0EE6E2C01279--


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

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

--===============1327411302560573387==--


From xen-devel-bounces@lists.xen.org Tue Dec 02 08:33:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 08:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvitY-0006TT-O5; Tue, 02 Dec 2014 08:33:16 +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 1XvitW-0006TM-V9
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 08:33:15 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	2B/5A-17958-A497D745; Tue, 02 Dec 2014 08:33:14 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417509191!15186354!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 20228 invoked from network); 2 Dec 2014 08:33:12 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-16.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 08:33:12 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 02 Dec 2014 00:29:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="492137986"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga003.jf.intel.com with ESMTP; 02 Dec 2014 00:29:55 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 16:33:06 +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; Tue, 2 Dec 2014 16:33:05 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
Thread-Index: AQHQDUl6Se46zODvj028i9c0xTR8UJx7+dDQ
Date: Tue, 2 Dec 2014 08:33:04 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AB18@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-3-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Monday, December 01, 2014 5:24 PM
> 
> This should be based on a new parameter globally, 'pci_rdmforce'.
> 
> 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.

since no one requires it, why bother adding it? better to just
keep global option.

> 
> So this domctl provides an approach to control how to populate
> reserved device memory by tools.
> 
> Note we always post a message to user about this once we owns
> RMRR.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  docs/man/xl.cfg.pod.5              |  6 +++++
>  docs/misc/vtd.txt                  | 15 ++++++++++++
>  tools/libxc/include/xenctrl.h      |  6 +++++
>  tools/libxc/xc_domain.c            | 28 +++++++++++++++++++++++
>  tools/libxl/libxl_create.c         |  3 +++
>  tools/libxl/libxl_dm.c             | 47
> ++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h       |  4 ++++
>  tools/libxl/libxl_types.idl        |  2 ++
>  tools/libxl/libxlu_pci.c           |  2 ++
>  tools/libxl/xl_cmdimpl.c           | 10 ++++++++
>  xen/drivers/passthrough/pci.c      | 39
> +++++++++++++++++++++++++++++++
>  xen/drivers/passthrough/vtd/dmar.c |  8 +++++++
>  xen/include/asm-x86/hvm/domain.h   |  4 ++++
>  xen/include/public/domctl.h        | 21 +++++++++++++++++
>  xen/xsm/flask/hooks.c              |  1 +
>  15 files changed, 196 insertions(+)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 622ea53..9adc41e 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -645,6 +645,12 @@ dom0 without confirmation.  Please use with care.
>  D0-D3hot power management states for the PCI device. False (0) by
>  default.
> 
> +=item B<rdmforce=BOOLEAN>
> +
> +(HVM/x86 only) Specifies that the VM would force to check and try to
> +reserve all reserved device memory, like RMRR, associated to the PCI
> +device. False (0) by default.
> +
>  =back
> 
>  =back
> diff --git a/docs/misc/vtd.txt b/docs/misc/vtd.txt
> index 9af0e99..23544d5 100644
> --- a/docs/misc/vtd.txt
> +++ b/docs/misc/vtd.txt
> @@ -111,6 +111,21 @@ in the config file:
>  To override for a specific device:
>  	pci = [ '01:00.0,msitranslate=0', '03:00.0' ]
> 
> +RDM, 'reserved device memory', for PCI Device Passthrough
> +---------------------------------------------------------
> +
> +The BIOS controls some devices in terms of some reginos of memory used for
> +these devices. This kind of region should be reserved before creating a VM
> +to make sure they are not occupied by RAM/MMIO to conflict, and also we
> can
> +create necessary IOMMU table successfully.
> +
> +To enable this globally, add "pci_rdmforce" in the config file:
> +
> +	pci_rdmforce = 1         (default is 0)
> +
> +Or just enable for a specific device:
> +	pci = [ '01:00.0,rdmforce=1', '03:00.0' ]
> +
> 
>  Caveat on Conventional PCI Device Passthrough
>  ---------------------------------------------
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 0ad8b8d..84012fe 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2038,6 +2038,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 b864872..7fd43e9 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -1633,6 +1633,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_t)domid;
> +    domctl.u.set_rdm.flags = 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/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 1198225..c615686 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -862,6 +862,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..e50587d 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -90,6 +90,53 @@ 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;
> +    uint32_t rdmforce = 0;
> +
> +    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].devfn = PCI_DEVFN(d_config->pcidevs[i].dev,
> +
> d_config->pcidevs[i].func);
> +                pcidevs[i].bus = d_config->pcidevs[i].bus;
> +                pcidevs[i].seg = d_config->pcidevs[i].domain;
> +                pcidevs[i].flags = d_config->pcidevs[i].rdmforce &
> +                                   PCI_DEV_RDM_CHECK;
> +            }
> +        }
> +        else
> +        {
> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                               "Can't allocate for pcidevs.");
> +            return -1;
> +        }
> +    }
> +    rdmforce = libxl_defbool_val(d_config->b_info.rdmforce) ? 1 : 0;
> +
> +    /* Nothing to do. */
> +    if ( !rdmforce && !d_config->num_pcidevs )
> +        return 0;

move check before creating pcidevs.

> +
> +    ret = xc_domain_device_setrdm(ctx->xch, dm_domid,
> +                                  (uint32_t)d_config->num_pcidevs,
> +                                  rdmforce,
> +                                  pcidevs);
> +    if ( d_config->num_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 a38f695..be397a6 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1477,6 +1477,10 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc
> *gc,
>          int nr_disks, libxl_device_disk *disks,
>          int nr_channels, libxl_device_channel *channels);
> 
> +_hidden int libxl__domain_device_setrdm(libxl__gc *gc,
> +                                        libxl_domain_config *info,
> +                                        uint32_t domid);
> +
>  /*
>   * This function will cause the whole libxl process to hang
>   * if the device model does not respond.  It is deprecated.
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index f7fc695..0076a32 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),
> +    ("rdmforce",         libxl_defbool),
>      ("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 0e754e7..9c23733 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -919,6 +919,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 +1700,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,6 +1723,7 @@ 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++;
>          }
> @@ -1726,6 +1731,11 @@ skip_vfb:
>              libxl_defbool_set(&b_info->u.pv.e820_host, true);
>      }
> 
> +    if ((c_info->type == LIBXL_DOMAIN_TYPE_HVM) && pci_rdmforce)
> +        libxl_defbool_set(&b_info->rdmforce, true);
> +    else
> +        libxl_defbool_set(&b_info->rdmforce, false);
> +
>      switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
>      case 0:
>          {
> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
> index 78c6977..ae924ad 100644
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -34,6 +34,7 @@
>  #include <xen/tasklet.h>
>  #include <xsm/xsm.h>
>  #include <asm/msi.h>
> +#include <xen/stdbool.h>
> 
>  struct pci_seg {
>      struct list_head alldevs_list;
> @@ -1553,6 +1554,44 @@ 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 = NULL;
> +        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
> +
> +        if ( d == NULL )
> +            return -ESRCH;
> +
> +        d->arch.hvm_domain.pci_force =
> +                            xdsr->flags & PCI_DEV_RDM_CHECK ?
> true : false;
> +        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;
> +        d->arch.hvm_domain.pcidevs = NULL;
> +
> +        if ( xdsr->num_pcidevs )
> +        {
> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
> +                                    xdsr->num_pcidevs);
> +            if ( pcidevs == NULL )
> +            {
> +                rcu_unlock_domain(d);
> +                return -ENOMEM;
> +            }
> +
> +            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
> +
> xdsr->num_pcidevs*sizeof(*pcidevs)) )
> +            {
> +                xfree(pcidevs);
> +                rcu_unlock_domain(d);
> +                return -EFAULT;
> +            }
> +        }
> +
> +        d->arch.hvm_domain.pcidevs = pcidevs;
> +        rcu_unlock_domain(d);
> +    }
> +        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 1152c3a..5e41e7a 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header
> *header)
>                          "  RMRR region: base_addr %"PRIx64
>                          " end_address %"PRIx64"\n",
>                          rmrru->base_address, rmrru->end_address);
> +            /*
> +             * TODO: we may provide a precise paramter just to reserve
> +             * RMRR range specific to one device.
> +             */
> +            dprintk(XENLOG_WARNING VTDPREFIX,
> +                    "So please set pci_rdmforce to reserve these ranges"
> +                    " if you need such a device in hotplug case.\n");
> +
>              acpi_register_rmrr_unit(rmrru);
>          }
>      }
> diff --git a/xen/include/asm-x86/hvm/domain.h
> b/xen/include/asm-x86/hvm/domain.h
> index 2757c7f..38530e5 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;
> 
> +    bool_t                  pci_force;
> +    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 57e2ed7..ba8970d 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -508,6 +508,25 @@ struct xen_domctl_get_device_group {
>  typedef struct xen_domctl_get_device_group
> xen_domctl_get_device_group_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_get_device_group_t);
> 
> +/* Currently just one bit to indicate force to check Reserved Device Memory.
> */
> +#define PCI_DEV_RDM_CHECK   0x1
> +struct xen_guest_pcidev_info {
> +    uint16_t    seg;
> +    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);
> +
>  /* Pass-through interrupts: bind real irq -> hvm devfn. */
>  /* XEN_DOMCTL_bind_pt_irq */
>  /* XEN_DOMCTL_unbind_pt_irq */
> @@ -1070,6 +1089,7 @@ struct xen_domctl {
>  #define XEN_DOMCTL_setvnumainfo                  74
>  #define XEN_DOMCTL_psr_cmt_op                    75
>  #define XEN_DOMCTL_arm_configure_domain          76
> +#define XEN_DOMCTL_set_rdm                       77
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -1135,6 +1155,7 @@ struct xen_domctl {
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>          struct xen_domctl_vnuma             vnuma;
>          struct xen_domctl_psr_cmt_op        psr_cmt_op;
> +        struct xen_domctl_set_rdm           set_rdm;
>          uint8_t                             pad[128];
>      } u;
>  };
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index d48463f..5a760e2 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -592,6 +592,7 @@ static int flask_domctl(struct domain *d, int cmd)
>      case XEN_DOMCTL_test_assign_device:
>      case XEN_DOMCTL_assign_device:
>      case XEN_DOMCTL_deassign_device:
> +    case XEN_DOMCTL_set_rdm:
>  #endif
>          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 Tue Dec 02 08:33:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 08:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvitY-0006TT-O5; Tue, 02 Dec 2014 08:33:16 +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 1XvitW-0006TM-V9
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 08:33:15 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	2B/5A-17958-A497D745; Tue, 02 Dec 2014 08:33:14 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417509191!15186354!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 20228 invoked from network); 2 Dec 2014 08:33:12 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-16.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 08:33:12 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 02 Dec 2014 00:29:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="492137986"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga003.jf.intel.com with ESMTP; 02 Dec 2014 00:29:55 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 16:33:06 +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; Tue, 2 Dec 2014 16:33:05 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
Thread-Index: AQHQDUl6Se46zODvj028i9c0xTR8UJx7+dDQ
Date: Tue, 2 Dec 2014 08:33:04 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AB18@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-3-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Monday, December 01, 2014 5:24 PM
> 
> This should be based on a new parameter globally, 'pci_rdmforce'.
> 
> 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.

since no one requires it, why bother adding it? better to just
keep global option.

> 
> So this domctl provides an approach to control how to populate
> reserved device memory by tools.
> 
> Note we always post a message to user about this once we owns
> RMRR.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  docs/man/xl.cfg.pod.5              |  6 +++++
>  docs/misc/vtd.txt                  | 15 ++++++++++++
>  tools/libxc/include/xenctrl.h      |  6 +++++
>  tools/libxc/xc_domain.c            | 28 +++++++++++++++++++++++
>  tools/libxl/libxl_create.c         |  3 +++
>  tools/libxl/libxl_dm.c             | 47
> ++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h       |  4 ++++
>  tools/libxl/libxl_types.idl        |  2 ++
>  tools/libxl/libxlu_pci.c           |  2 ++
>  tools/libxl/xl_cmdimpl.c           | 10 ++++++++
>  xen/drivers/passthrough/pci.c      | 39
> +++++++++++++++++++++++++++++++
>  xen/drivers/passthrough/vtd/dmar.c |  8 +++++++
>  xen/include/asm-x86/hvm/domain.h   |  4 ++++
>  xen/include/public/domctl.h        | 21 +++++++++++++++++
>  xen/xsm/flask/hooks.c              |  1 +
>  15 files changed, 196 insertions(+)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 622ea53..9adc41e 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -645,6 +645,12 @@ dom0 without confirmation.  Please use with care.
>  D0-D3hot power management states for the PCI device. False (0) by
>  default.
> 
> +=item B<rdmforce=BOOLEAN>
> +
> +(HVM/x86 only) Specifies that the VM would force to check and try to
> +reserve all reserved device memory, like RMRR, associated to the PCI
> +device. False (0) by default.
> +
>  =back
> 
>  =back
> diff --git a/docs/misc/vtd.txt b/docs/misc/vtd.txt
> index 9af0e99..23544d5 100644
> --- a/docs/misc/vtd.txt
> +++ b/docs/misc/vtd.txt
> @@ -111,6 +111,21 @@ in the config file:
>  To override for a specific device:
>  	pci = [ '01:00.0,msitranslate=0', '03:00.0' ]
> 
> +RDM, 'reserved device memory', for PCI Device Passthrough
> +---------------------------------------------------------
> +
> +The BIOS controls some devices in terms of some reginos of memory used for
> +these devices. This kind of region should be reserved before creating a VM
> +to make sure they are not occupied by RAM/MMIO to conflict, and also we
> can
> +create necessary IOMMU table successfully.
> +
> +To enable this globally, add "pci_rdmforce" in the config file:
> +
> +	pci_rdmforce = 1         (default is 0)
> +
> +Or just enable for a specific device:
> +	pci = [ '01:00.0,rdmforce=1', '03:00.0' ]
> +
> 
>  Caveat on Conventional PCI Device Passthrough
>  ---------------------------------------------
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 0ad8b8d..84012fe 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2038,6 +2038,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 b864872..7fd43e9 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -1633,6 +1633,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_t)domid;
> +    domctl.u.set_rdm.flags = 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/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 1198225..c615686 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -862,6 +862,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..e50587d 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -90,6 +90,53 @@ 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;
> +    uint32_t rdmforce = 0;
> +
> +    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].devfn = PCI_DEVFN(d_config->pcidevs[i].dev,
> +
> d_config->pcidevs[i].func);
> +                pcidevs[i].bus = d_config->pcidevs[i].bus;
> +                pcidevs[i].seg = d_config->pcidevs[i].domain;
> +                pcidevs[i].flags = d_config->pcidevs[i].rdmforce &
> +                                   PCI_DEV_RDM_CHECK;
> +            }
> +        }
> +        else
> +        {
> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                               "Can't allocate for pcidevs.");
> +            return -1;
> +        }
> +    }
> +    rdmforce = libxl_defbool_val(d_config->b_info.rdmforce) ? 1 : 0;
> +
> +    /* Nothing to do. */
> +    if ( !rdmforce && !d_config->num_pcidevs )
> +        return 0;

move check before creating pcidevs.

> +
> +    ret = xc_domain_device_setrdm(ctx->xch, dm_domid,
> +                                  (uint32_t)d_config->num_pcidevs,
> +                                  rdmforce,
> +                                  pcidevs);
> +    if ( d_config->num_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 a38f695..be397a6 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1477,6 +1477,10 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc
> *gc,
>          int nr_disks, libxl_device_disk *disks,
>          int nr_channels, libxl_device_channel *channels);
> 
> +_hidden int libxl__domain_device_setrdm(libxl__gc *gc,
> +                                        libxl_domain_config *info,
> +                                        uint32_t domid);
> +
>  /*
>   * This function will cause the whole libxl process to hang
>   * if the device model does not respond.  It is deprecated.
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index f7fc695..0076a32 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),
> +    ("rdmforce",         libxl_defbool),
>      ("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 0e754e7..9c23733 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -919,6 +919,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 +1700,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,6 +1723,7 @@ 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++;
>          }
> @@ -1726,6 +1731,11 @@ skip_vfb:
>              libxl_defbool_set(&b_info->u.pv.e820_host, true);
>      }
> 
> +    if ((c_info->type == LIBXL_DOMAIN_TYPE_HVM) && pci_rdmforce)
> +        libxl_defbool_set(&b_info->rdmforce, true);
> +    else
> +        libxl_defbool_set(&b_info->rdmforce, false);
> +
>      switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
>      case 0:
>          {
> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
> index 78c6977..ae924ad 100644
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -34,6 +34,7 @@
>  #include <xen/tasklet.h>
>  #include <xsm/xsm.h>
>  #include <asm/msi.h>
> +#include <xen/stdbool.h>
> 
>  struct pci_seg {
>      struct list_head alldevs_list;
> @@ -1553,6 +1554,44 @@ 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 = NULL;
> +        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
> +
> +        if ( d == NULL )
> +            return -ESRCH;
> +
> +        d->arch.hvm_domain.pci_force =
> +                            xdsr->flags & PCI_DEV_RDM_CHECK ?
> true : false;
> +        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;
> +        d->arch.hvm_domain.pcidevs = NULL;
> +
> +        if ( xdsr->num_pcidevs )
> +        {
> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
> +                                    xdsr->num_pcidevs);
> +            if ( pcidevs == NULL )
> +            {
> +                rcu_unlock_domain(d);
> +                return -ENOMEM;
> +            }
> +
> +            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
> +
> xdsr->num_pcidevs*sizeof(*pcidevs)) )
> +            {
> +                xfree(pcidevs);
> +                rcu_unlock_domain(d);
> +                return -EFAULT;
> +            }
> +        }
> +
> +        d->arch.hvm_domain.pcidevs = pcidevs;
> +        rcu_unlock_domain(d);
> +    }
> +        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 1152c3a..5e41e7a 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header
> *header)
>                          "  RMRR region: base_addr %"PRIx64
>                          " end_address %"PRIx64"\n",
>                          rmrru->base_address, rmrru->end_address);
> +            /*
> +             * TODO: we may provide a precise paramter just to reserve
> +             * RMRR range specific to one device.
> +             */
> +            dprintk(XENLOG_WARNING VTDPREFIX,
> +                    "So please set pci_rdmforce to reserve these ranges"
> +                    " if you need such a device in hotplug case.\n");
> +
>              acpi_register_rmrr_unit(rmrru);
>          }
>      }
> diff --git a/xen/include/asm-x86/hvm/domain.h
> b/xen/include/asm-x86/hvm/domain.h
> index 2757c7f..38530e5 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;
> 
> +    bool_t                  pci_force;
> +    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 57e2ed7..ba8970d 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -508,6 +508,25 @@ struct xen_domctl_get_device_group {
>  typedef struct xen_domctl_get_device_group
> xen_domctl_get_device_group_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_get_device_group_t);
> 
> +/* Currently just one bit to indicate force to check Reserved Device Memory.
> */
> +#define PCI_DEV_RDM_CHECK   0x1
> +struct xen_guest_pcidev_info {
> +    uint16_t    seg;
> +    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);
> +
>  /* Pass-through interrupts: bind real irq -> hvm devfn. */
>  /* XEN_DOMCTL_bind_pt_irq */
>  /* XEN_DOMCTL_unbind_pt_irq */
> @@ -1070,6 +1089,7 @@ struct xen_domctl {
>  #define XEN_DOMCTL_setvnumainfo                  74
>  #define XEN_DOMCTL_psr_cmt_op                    75
>  #define XEN_DOMCTL_arm_configure_domain          76
> +#define XEN_DOMCTL_set_rdm                       77
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -1135,6 +1155,7 @@ struct xen_domctl {
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>          struct xen_domctl_vnuma             vnuma;
>          struct xen_domctl_psr_cmt_op        psr_cmt_op;
> +        struct xen_domctl_set_rdm           set_rdm;
>          uint8_t                             pad[128];
>      } u;
>  };
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index d48463f..5a760e2 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -592,6 +592,7 @@ static int flask_domctl(struct domain *d, int cmd)
>      case XEN_DOMCTL_test_assign_device:
>      case XEN_DOMCTL_assign_device:
>      case XEN_DOMCTL_deassign_device:
> +    case XEN_DOMCTL_set_rdm:
>  #endif
>          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 Tue Dec 02 08:46:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 08: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 1Xvj6C-0006nH-8H; Tue, 02 Dec 2014 08:46:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Xvj6A-0006nC-W3
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 08:46:19 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	DF/C9-02699-A5C7D745; Tue, 02 Dec 2014 08:46:18 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417509974!9050127!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 8434 invoked from network); 2 Dec 2014 08:46:15 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-27.messagelabs.com with SMTP;
	2 Dec 2014 08:46:15 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2014 00:46:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="631228678"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2014 00:46:10 -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; Tue, 2 Dec 2014 16:46:09 +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, 2 Dec 2014 16:46:07 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 04/17] update the existing hypercall to support
	XEN_DOMCTL_set_rdm
Thread-Index: AQHQDUl+JQ1RlBbQjUezMiuvzwgHfZx7/YRw
Date: Tue, 2 Dec 2014 08:46:07 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AB50@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-5-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Monday, December 01, 2014 5:24 PM
> 
> After we intend to expost that hypercall explicitly based on
> XEN_DOMCTL_set_rdm, we need this rebase. I hope we can squash
> this into that previous patch once Jan Ack this.

better to merge together, since it's the right thing to do based on previous
discussion.

one question about 'd->arch.hvm_domain.pci_force'. My impression is
that this flag enables force check, and while enabled, you'll always
do selected BDF filtering by default. However from below code, seems
pci_force is used to whether report all or selected regions. Am I reading
it wrong?

> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/common/compat/memory.c         | 75
> ++++++++++++++++++++++++++++++--------
>  xen/common/memory.c                | 71
> +++++++++++++++++++++++++++++-------
>  xen/drivers/passthrough/vtd/dmar.c | 32 ++++++++++++----
>  xen/include/public/memory.h        |  5 +++
>  xen/include/xen/iommu.h            |  2 +-
>  xen/include/xen/pci.h              |  2 +
>  6 files changed, 148 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
> index 60512fa..e6a256e 100644
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -22,27 +22,66 @@ 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;
> +    unsigned int i;
> +    u32 sbdf;
> +    struct compat_reserved_device_memory rdm = {
> +        .start_pfn = start, .nr_pages = nr
> +    };
> 
> -    if ( grdm->used_entries < grdm->map.nr_entries )
> -    {
> -        struct compat_reserved_device_memory rdm = {
> -            .start_pfn = start, .nr_pages = nr
> -        };
> +    if ( rdm.start_pfn != start || rdm.nr_pages != nr )
> +        return -ERANGE;
> 
> -        if ( rdm.start_pfn != start || rdm.nr_pages != nr )
> -            return -ERANGE;
> +    d = rcu_lock_domain_by_any_id(grdm->map.domid);
> +    if ( d == NULL )
> +        return -ESRCH;
> 
> -        if ( __copy_to_compat_offset(grdm->map.buffer,
> grdm->used_entries,
> -                                     &rdm, 1) )
> -            return -EFAULT;
> +    if ( d )
> +    {
> +        if ( d->arch.hvm_domain.pci_force )
> +        {
> +            if ( grdm->used_entries < grdm->map.nr_entries )
> +            {
> +                if ( __copy_to_compat_offset(grdm->map.buffer,
> +                                             grdm->used_entries,
> +                                             &rdm, 1) )
> +                {
> +                    rcu_unlock_domain(d);
> +                    return -EFAULT;
> +                }
> +            }
> +            ++grdm->used_entries;
> +        }
> +        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 ( grdm->used_entries < grdm->map.nr_entries )
> +                    {
> +                        if
> ( __copy_to_compat_offset(grdm->map.buffer,
> +
> grdm->used_entries,
> +                                                     &rdm, 1) )
> +                        {
> +                            rcu_unlock_domain(d);
> +                            return -EFAULT;
> +                        }
> +                    }
> +                    ++grdm->used_entries;
> +                }
> +            }
> +        }
>      }
> 
> -    ++grdm->used_entries;
> -
> +    rcu_unlock_domain(d);
>      return 0;
>  }
>  #endif
> @@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd,
> XEN_GUEST_HANDLE_PARAM(void) compat)
> 
>              if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>                  rc = -ENOBUFS;
> +
>              grdm.map.nr_entries = grdm.used_entries;
> -            if ( __copy_to_guest(compat, &grdm.map, 1) )
> -                rc = -EFAULT;
> +            if ( grdm.map.nr_entries )
> +            {
> +                if ( __copy_to_guest(compat, &grdm.map, 1) )
> +                    rc = -EFAULT;
> +            }
> 
>              return rc;
>          }
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 4788acc..9ce82b1 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -698,24 +698,63 @@ 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;
> +    unsigned int i;
> +    u32 sbdf;
> +    struct xen_reserved_device_memory rdm = {
> +        .start_pfn = start, .nr_pages = nr
> +    };
> 
> -    if ( grdm->used_entries < grdm->map.nr_entries )
> -    {
> -        struct xen_reserved_device_memory rdm = {
> -            .start_pfn = start, .nr_pages = nr
> -        };
> +    d = rcu_lock_domain_by_any_id(grdm->map.domid);
> +    if ( d == NULL )
> +        return -ESRCH;
> 
> -        if ( __copy_to_guest_offset(grdm->map.buffer,
> grdm->used_entries,
> -                                    &rdm, 1) )
> -            return -EFAULT;
> +    if ( d )
> +    {
> +        if ( d->arch.hvm_domain.pci_force )
> +        {
> +            if ( grdm->used_entries < grdm->map.nr_entries )
> +            {
> +                if ( __copy_to_guest_offset(grdm->map.buffer,
> +                                            grdm->used_entries,
> +                                            &rdm, 1) )
> +                {
> +                    rcu_unlock_domain(d);
> +                    return -EFAULT;
> +                }
> +            }
> +            ++grdm->used_entries;
> +        }
> +        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 ( grdm->used_entries < grdm->map.nr_entries )
> +                    {
> +                        if ( __copy_to_guest_offset(grdm->map.buffer,
> +
> grdm->used_entries,
> +                                                    &rdm, 1) )
> +                        {
> +                            rcu_unlock_domain(d);
> +                            return -EFAULT;
> +                        }
> +                    }
> +                    ++grdm->used_entries;
> +                }
> +            }
> +        }
>      }
> 
> -    ++grdm->used_entries;
> -
> +    rcu_unlock_domain(d);
>      return 0;
>  }
>  #endif
> @@ -1144,9 +1183,13 @@ long do_memory_op(unsigned long cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> 
>          if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>              rc = -ENOBUFS;
> +
>          grdm.map.nr_entries = grdm.used_entries;
> -        if ( __copy_to_guest(arg, &grdm.map, 1) )
> -            rc = -EFAULT;
> +        if ( grdm.map.nr_entries )
> +        {
> +            if ( __copy_to_guest(arg, &grdm.map, 1) )
> +                rc = -EFAULT;
> +        }
> 
>          break;
>      }
> diff --git a/xen/drivers/passthrough/vtd/dmar.c
> b/xen/drivers/passthrough/vtd/dmar.c
> index 86cfad3..c5bc8d6 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
> 
>  int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void
> *ctxt)
>  {
> -    struct acpi_rmrr_unit *rmrr;
> +    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
>      int rc = 0;
> +    unsigned 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 ( 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;
> +
> +            /* Just go next. */
> +            if ( !rc )
> +                rmrr_cur = rmrr;
> +
> +            /* Now just return specific to user requirement. */
> +            if ( rc > 0 )
> +                return rc;
> +        }
>      }
> 
> -    return rc;
> +    return 0;
>  }
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index cee4535..0d0544e 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -586,6 +586,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..8fc6d6d 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, u32 id, 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 5f295f3..d34205f 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;
> --
> 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 Dec 02 08:46:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 08: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 1Xvj6C-0006nH-8H; Tue, 02 Dec 2014 08:46:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Xvj6A-0006nC-W3
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 08:46:19 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	DF/C9-02699-A5C7D745; Tue, 02 Dec 2014 08:46:18 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417509974!9050127!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 8434 invoked from network); 2 Dec 2014 08:46:15 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-27.messagelabs.com with SMTP;
	2 Dec 2014 08:46:15 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2014 00:46:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="631228678"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2014 00:46:10 -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; Tue, 2 Dec 2014 16:46:09 +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, 2 Dec 2014 16:46:07 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 04/17] update the existing hypercall to support
	XEN_DOMCTL_set_rdm
Thread-Index: AQHQDUl+JQ1RlBbQjUezMiuvzwgHfZx7/YRw
Date: Tue, 2 Dec 2014 08:46:07 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AB50@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-5-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Monday, December 01, 2014 5:24 PM
> 
> After we intend to expost that hypercall explicitly based on
> XEN_DOMCTL_set_rdm, we need this rebase. I hope we can squash
> this into that previous patch once Jan Ack this.

better to merge together, since it's the right thing to do based on previous
discussion.

one question about 'd->arch.hvm_domain.pci_force'. My impression is
that this flag enables force check, and while enabled, you'll always
do selected BDF filtering by default. However from below code, seems
pci_force is used to whether report all or selected regions. Am I reading
it wrong?

> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/common/compat/memory.c         | 75
> ++++++++++++++++++++++++++++++--------
>  xen/common/memory.c                | 71
> +++++++++++++++++++++++++++++-------
>  xen/drivers/passthrough/vtd/dmar.c | 32 ++++++++++++----
>  xen/include/public/memory.h        |  5 +++
>  xen/include/xen/iommu.h            |  2 +-
>  xen/include/xen/pci.h              |  2 +
>  6 files changed, 148 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
> index 60512fa..e6a256e 100644
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -22,27 +22,66 @@ 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;
> +    unsigned int i;
> +    u32 sbdf;
> +    struct compat_reserved_device_memory rdm = {
> +        .start_pfn = start, .nr_pages = nr
> +    };
> 
> -    if ( grdm->used_entries < grdm->map.nr_entries )
> -    {
> -        struct compat_reserved_device_memory rdm = {
> -            .start_pfn = start, .nr_pages = nr
> -        };
> +    if ( rdm.start_pfn != start || rdm.nr_pages != nr )
> +        return -ERANGE;
> 
> -        if ( rdm.start_pfn != start || rdm.nr_pages != nr )
> -            return -ERANGE;
> +    d = rcu_lock_domain_by_any_id(grdm->map.domid);
> +    if ( d == NULL )
> +        return -ESRCH;
> 
> -        if ( __copy_to_compat_offset(grdm->map.buffer,
> grdm->used_entries,
> -                                     &rdm, 1) )
> -            return -EFAULT;
> +    if ( d )
> +    {
> +        if ( d->arch.hvm_domain.pci_force )
> +        {
> +            if ( grdm->used_entries < grdm->map.nr_entries )
> +            {
> +                if ( __copy_to_compat_offset(grdm->map.buffer,
> +                                             grdm->used_entries,
> +                                             &rdm, 1) )
> +                {
> +                    rcu_unlock_domain(d);
> +                    return -EFAULT;
> +                }
> +            }
> +            ++grdm->used_entries;
> +        }
> +        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 ( grdm->used_entries < grdm->map.nr_entries )
> +                    {
> +                        if
> ( __copy_to_compat_offset(grdm->map.buffer,
> +
> grdm->used_entries,
> +                                                     &rdm, 1) )
> +                        {
> +                            rcu_unlock_domain(d);
> +                            return -EFAULT;
> +                        }
> +                    }
> +                    ++grdm->used_entries;
> +                }
> +            }
> +        }
>      }
> 
> -    ++grdm->used_entries;
> -
> +    rcu_unlock_domain(d);
>      return 0;
>  }
>  #endif
> @@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd,
> XEN_GUEST_HANDLE_PARAM(void) compat)
> 
>              if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>                  rc = -ENOBUFS;
> +
>              grdm.map.nr_entries = grdm.used_entries;
> -            if ( __copy_to_guest(compat, &grdm.map, 1) )
> -                rc = -EFAULT;
> +            if ( grdm.map.nr_entries )
> +            {
> +                if ( __copy_to_guest(compat, &grdm.map, 1) )
> +                    rc = -EFAULT;
> +            }
> 
>              return rc;
>          }
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 4788acc..9ce82b1 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -698,24 +698,63 @@ 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;
> +    unsigned int i;
> +    u32 sbdf;
> +    struct xen_reserved_device_memory rdm = {
> +        .start_pfn = start, .nr_pages = nr
> +    };
> 
> -    if ( grdm->used_entries < grdm->map.nr_entries )
> -    {
> -        struct xen_reserved_device_memory rdm = {
> -            .start_pfn = start, .nr_pages = nr
> -        };
> +    d = rcu_lock_domain_by_any_id(grdm->map.domid);
> +    if ( d == NULL )
> +        return -ESRCH;
> 
> -        if ( __copy_to_guest_offset(grdm->map.buffer,
> grdm->used_entries,
> -                                    &rdm, 1) )
> -            return -EFAULT;
> +    if ( d )
> +    {
> +        if ( d->arch.hvm_domain.pci_force )
> +        {
> +            if ( grdm->used_entries < grdm->map.nr_entries )
> +            {
> +                if ( __copy_to_guest_offset(grdm->map.buffer,
> +                                            grdm->used_entries,
> +                                            &rdm, 1) )
> +                {
> +                    rcu_unlock_domain(d);
> +                    return -EFAULT;
> +                }
> +            }
> +            ++grdm->used_entries;
> +        }
> +        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 ( grdm->used_entries < grdm->map.nr_entries )
> +                    {
> +                        if ( __copy_to_guest_offset(grdm->map.buffer,
> +
> grdm->used_entries,
> +                                                    &rdm, 1) )
> +                        {
> +                            rcu_unlock_domain(d);
> +                            return -EFAULT;
> +                        }
> +                    }
> +                    ++grdm->used_entries;
> +                }
> +            }
> +        }
>      }
> 
> -    ++grdm->used_entries;
> -
> +    rcu_unlock_domain(d);
>      return 0;
>  }
>  #endif
> @@ -1144,9 +1183,13 @@ long do_memory_op(unsigned long cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> 
>          if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>              rc = -ENOBUFS;
> +
>          grdm.map.nr_entries = grdm.used_entries;
> -        if ( __copy_to_guest(arg, &grdm.map, 1) )
> -            rc = -EFAULT;
> +        if ( grdm.map.nr_entries )
> +        {
> +            if ( __copy_to_guest(arg, &grdm.map, 1) )
> +                rc = -EFAULT;
> +        }
> 
>          break;
>      }
> diff --git a/xen/drivers/passthrough/vtd/dmar.c
> b/xen/drivers/passthrough/vtd/dmar.c
> index 86cfad3..c5bc8d6 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
> 
>  int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void
> *ctxt)
>  {
> -    struct acpi_rmrr_unit *rmrr;
> +    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
>      int rc = 0;
> +    unsigned 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 ( 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;
> +
> +            /* Just go next. */
> +            if ( !rc )
> +                rmrr_cur = rmrr;
> +
> +            /* Now just return specific to user requirement. */
> +            if ( rc > 0 )
> +                return rc;
> +        }
>      }
> 
> -    return rc;
> +    return 0;
>  }
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index cee4535..0d0544e 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -586,6 +586,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..8fc6d6d 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, u32 id, 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 5f295f3..d34205f 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;
> --
> 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 Dec 02 08:46:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 08: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 1Xvj6l-0006p6-LH; Tue, 02 Dec 2014 08:46:55 +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 1Xvj6k-0006ox-Gt
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 08:46:54 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	2B/64-23865-D7C7D745; Tue, 02 Dec 2014 08:46:53 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417510012!15190319!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 21820 invoked from network); 2 Dec 2014 08:46:52 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 08:46:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2014 00:46:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="631228885"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2014 00:46:48 -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; Tue, 2 Dec 2014 16:46:48 +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, 2 Dec 2014 16:46:47 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 05/17] tools/libxc: introduce hypercall for
	xc_reserved_device_memory_map
Thread-Index: AQHQDUmAtJ4/CEtH+E2VATebG8NLFJx7/ldw
Date: Tue, 2 Dec 2014 08:46:46 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AB60@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-6-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-6-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 05/17] tools/libxc: introduce hypercall
 for xc_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Monday, December 01, 2014 5:24 PM
> 
> We will introduce that hypercall xc_reserved_device_memory_map
> approach to libxc.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

> ---
>  tools/libxc/include/xenctrl.h |  5 +++++
>  tools/libxc/xc_domain.c       | 30 ++++++++++++++++++++++++++++++
>  2 files changed, 35 insertions(+)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 84012fe..a3aeac3 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1294,6 +1294,11 @@ int xc_domain_set_memory_map(xc_interface
> *xch,
>  int xc_get_machine_memory_map(xc_interface *xch,
>                                struct e820entry entries[],
>                                uint32_t max_entries);
> +
> +int xc_reserved_device_memory_map(xc_interface *xch,
> +                                  uint32_t dom,
> +                                  struct
> xen_reserved_device_memory entries[],
> +                                  uint32_t *max_entries);
>  #endif
>  int xc_domain_set_time_offset(xc_interface *xch,
>                                uint32_t domid,
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 7fd43e9..09fd988 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -679,6 +679,36 @@ int xc_domain_set_memory_map(xc_interface *xch,
> 
>      return rc;
>  }
> +
> +int xc_reserved_device_memory_map(xc_interface *xch,
> +                                  uint32_t domid,
> +                                  struct
> xen_reserved_device_memory entries[],
> +                                  uint32_t *max_entries)
> +{
> +    int rc;
> +    struct xen_reserved_device_memory_map xrdmmap = {
> +        .domid = domid,
> +        .nr_entries = *max_entries
> +    };
> +    DECLARE_HYPERCALL_BOUNCE(entries,
> +                             sizeof(struct
> xen_reserved_device_memory) *
> +                             *max_entries,
> XC_HYPERCALL_BUFFER_BOUNCE_OUT);
> +
> +    if ( xc_hypercall_bounce_pre(xch, entries) )
> +        return -1;
> +
> +    set_xen_guest_handle(xrdmmap.buffer, entries);
> +
> +    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
> +                      &xrdmmap, sizeof(xrdmmap));
> +
> +    xc_hypercall_bounce_post(xch, entries);
> +
> +    *max_entries = xrdmmap.nr_entries;
> +
> +    return rc ? rc : xrdmmap.nr_entries;
> +}
> +
>  int xc_get_machine_memory_map(xc_interface *xch,
>                                struct e820entry entries[],
>                                uint32_t max_entries)
> --
> 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 Dec 02 08:46:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 08: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 1Xvj6l-0006p6-LH; Tue, 02 Dec 2014 08:46:55 +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 1Xvj6k-0006ox-Gt
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 08:46:54 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	2B/64-23865-D7C7D745; Tue, 02 Dec 2014 08:46:53 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417510012!15190319!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 21820 invoked from network); 2 Dec 2014 08:46:52 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 08:46:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2014 00:46:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="631228885"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2014 00:46:48 -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; Tue, 2 Dec 2014 16:46:48 +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, 2 Dec 2014 16:46:47 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 05/17] tools/libxc: introduce hypercall for
	xc_reserved_device_memory_map
Thread-Index: AQHQDUmAtJ4/CEtH+E2VATebG8NLFJx7/ldw
Date: Tue, 2 Dec 2014 08:46:46 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AB60@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-6-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-6-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 05/17] tools/libxc: introduce hypercall
 for xc_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Monday, December 01, 2014 5:24 PM
> 
> We will introduce that hypercall xc_reserved_device_memory_map
> approach to libxc.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

> ---
>  tools/libxc/include/xenctrl.h |  5 +++++
>  tools/libxc/xc_domain.c       | 30 ++++++++++++++++++++++++++++++
>  2 files changed, 35 insertions(+)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 84012fe..a3aeac3 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1294,6 +1294,11 @@ int xc_domain_set_memory_map(xc_interface
> *xch,
>  int xc_get_machine_memory_map(xc_interface *xch,
>                                struct e820entry entries[],
>                                uint32_t max_entries);
> +
> +int xc_reserved_device_memory_map(xc_interface *xch,
> +                                  uint32_t dom,
> +                                  struct
> xen_reserved_device_memory entries[],
> +                                  uint32_t *max_entries);
>  #endif
>  int xc_domain_set_time_offset(xc_interface *xch,
>                                uint32_t domid,
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 7fd43e9..09fd988 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -679,6 +679,36 @@ int xc_domain_set_memory_map(xc_interface *xch,
> 
>      return rc;
>  }
> +
> +int xc_reserved_device_memory_map(xc_interface *xch,
> +                                  uint32_t domid,
> +                                  struct
> xen_reserved_device_memory entries[],
> +                                  uint32_t *max_entries)
> +{
> +    int rc;
> +    struct xen_reserved_device_memory_map xrdmmap = {
> +        .domid = domid,
> +        .nr_entries = *max_entries
> +    };
> +    DECLARE_HYPERCALL_BOUNCE(entries,
> +                             sizeof(struct
> xen_reserved_device_memory) *
> +                             *max_entries,
> XC_HYPERCALL_BUFFER_BOUNCE_OUT);
> +
> +    if ( xc_hypercall_bounce_pre(xch, entries) )
> +        return -1;
> +
> +    set_xen_guest_handle(xrdmmap.buffer, entries);
> +
> +    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
> +                      &xrdmmap, sizeof(xrdmmap));
> +
> +    xc_hypercall_bounce_post(xch, entries);
> +
> +    *max_entries = xrdmmap.nr_entries;
> +
> +    return rc ? rc : xrdmmap.nr_entries;
> +}
> +
>  int xc_get_machine_memory_map(xc_interface *xch,
>                                struct e820entry entries[],
>                                uint32_t max_entries)
> --
> 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 Dec 02 08:55:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 08:55:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvjEi-00077j-0i; Tue, 02 Dec 2014 08:55:08 +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 1XvjEg-00077b-SB
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 08:55:07 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	AD/BE-18267-96E7D745; Tue, 02 Dec 2014 08:55:05 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417510503!12737826!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 24713 invoked from network); 2 Dec 2014 08:55:04 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-14.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 08:55:04 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 02 Dec 2014 00:55:03 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="631232031"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2014 00:55:00 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 16:55:00 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Tue, 2 Dec 2014 16:54:58 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 06/17] tools/libxc: check if modules space is
	overlapping with reserved device memory
Thread-Index: AQHQDUmC4cWf9aqwWk+cX7UhaQMIX5x8AFLw
Date: Tue, 2 Dec 2014 08:54:57 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610ABB4@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-7-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-7-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 06/17] tools/libxc: check if modules
 space is overlapping with reserved device 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

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:24 PM
> 
> In case of reserved device memory overlapping with ram, it also probably
> overlap with modules space so we need to check these reserved device
> memory as well.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>, with one small comment

> ---
>  tools/libxc/xc_hvm_build_x86.c | 94
> +++++++++++++++++++++++++++++++++++-------
>  1 file changed, 79 insertions(+), 15 deletions(-)
> 
> diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
> index c81a25b..ddcf06d 100644
> --- a/tools/libxc/xc_hvm_build_x86.c
> +++ b/tools/libxc/xc_hvm_build_x86.c
> @@ -54,9 +54,82 @@
> 
>  #define VGA_HOLE_SIZE (0x20)
> 
> +/*
> + * Check whether there exists mmio hole in the specified memory range.
> + * Returns 1 if exists, else returns 0.
> + */
> +static int check_mmio_hole(uint64_t start, uint64_t memsize,
> +                           uint64_t mmio_start, uint64_t mmio_size)
> +{
> +    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
> +        return 0;
> +    else
> +        return 1;
> +}
> +
> +/* Getting all reserved device memory map info. */
> +static struct xen_reserved_device_memory
> +*xc_get_reserved_device_memory_map(xc_interface *xch, unsigned int
> nr_entries,
> +                                   uint32_t dom)
> +{
> +    struct xen_reserved_device_memory *xrdm = NULL;
> +    int rc = xc_reserved_device_memory_map(xch, dom, xrdm,
> &nr_entries);
> +
> +    if ( rc < 0 )
> +    {
> +        if ( errno == ENOBUFS )
> +        {
> +            if ( (xrdm = malloc(nr_entries *
> +
> sizeof(xen_reserved_device_memory_t))) == NULL )
> +            {
> +                PERROR("Could not allocate memory.");
> +                return 0;
> +            }
> +            rc = xc_reserved_device_memory_map(xch, dom, xrdm,
> &nr_entries);
> +            if ( rc )
> +            {
> +                PERROR("Could not get reserved device memory maps.");
> +                free(xrdm);
> +                return 0;
> +            }
> +        }
> +        else
> +            PERROR("Could not get reserved device memory maps.");
> +    }
> +
> +    return xrdm;
> +}
> +
> +static int xc_check_modules_space(xc_interface *xch, uint64_t *mstart_out,
> +                                  uint64_t *mend_out, uint32_t dom)
> +{
> +    unsigned int i = 0, nr_entries = 0;
> +    uint64_t rdm_start = 0, rdm_end = 0;
> +    struct xen_reserved_device_memory *rdm_map =
> +                        xc_get_reserved_device_memory_map(xch,
> nr_entries, dom);
> +
> +    for ( i = 0; i < nr_entries; i++ )
> +    {
> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << XC_PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages <<
> XC_PAGE_SHIFT);
> +
> +        /* Just use check_mmio_hole() to check modules ranges. */
> +        if ( check_mmio_hole(rdm_start,
> +                             rdm_end - rdm_start,

then you don't need a rdm_end variable here, since only size is wanted.

> +                             *mstart_out, *mend_out) )
> +            return -1;
> +    }
> +
> +    free(rdm_map);
> +
> +    return 0;
> +}
> +
>  static int modules_init(struct xc_hvm_build_args *args,
>                          uint64_t vend, struct elf_binary *elf,
> -                        uint64_t *mstart_out, uint64_t *mend_out)
> +                        uint64_t *mstart_out, uint64_t *mend_out,
> +                        xc_interface *xch,
> +                        uint32_t dom)
>  {
>  #define MODULE_ALIGN 1UL << 7
>  #define MB_ALIGN     1UL << 20
> @@ -80,6 +153,10 @@ static int modules_init(struct xc_hvm_build_args
> *args,
>      if ( *mend_out > vend )
>          return -1;
> 
> +    /* Is it overlapping with reserved device memory? */
> +    if ( xc_check_modules_space(xch, mstart_out, mend_out, dom) )
> +        return -1;
> +
>      if ( args->acpi_module.length != 0 )
>          args->acpi_module.guest_addr_out = *mstart_out;
>      if ( args->smbios_module.length != 0 )
> @@ -226,19 +303,6 @@ static int loadmodules(xc_interface *xch,
>      return rc;
>  }
> 
> -/*
> - * Check whether there exists mmio hole in the specified memory range.
> - * Returns 1 if exists, else returns 0.
> - */
> -static int check_mmio_hole(uint64_t start, uint64_t memsize,
> -                           uint64_t mmio_start, uint64_t mmio_size)
> -{
> -    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
> -        return 0;
> -    else
> -        return 1;
> -}
> -
>  static int setup_guest(xc_interface *xch,
>                         uint32_t dom, struct xc_hvm_build_args *args,
>                         char *image, unsigned long image_size)
> @@ -282,7 +346,7 @@ static int setup_guest(xc_interface *xch,
>          goto error_out;
>      }
> 
> -    if ( modules_init(args, v_end, &elf, &m_start, &m_end) != 0 )
> +    if ( modules_init(args, v_end, &elf, &m_start, &m_end, xch, dom) != 0 )
>      {
>          ERROR("Insufficient space to load modules.");
>          goto error_out;
> --
> 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 Dec 02 08:55:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 08:55:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvjEi-00077j-0i; Tue, 02 Dec 2014 08:55:08 +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 1XvjEg-00077b-SB
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 08:55:07 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	AD/BE-18267-96E7D745; Tue, 02 Dec 2014 08:55:05 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417510503!12737826!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 24713 invoked from network); 2 Dec 2014 08:55:04 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-14.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 08:55:04 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 02 Dec 2014 00:55:03 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="631232031"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2014 00:55:00 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 16:55:00 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Tue, 2 Dec 2014 16:54:58 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 06/17] tools/libxc: check if modules space is
	overlapping with reserved device memory
Thread-Index: AQHQDUmC4cWf9aqwWk+cX7UhaQMIX5x8AFLw
Date: Tue, 2 Dec 2014 08:54:57 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610ABB4@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-7-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-7-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 06/17] tools/libxc: check if modules
 space is overlapping with reserved device 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

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:24 PM
> 
> In case of reserved device memory overlapping with ram, it also probably
> overlap with modules space so we need to check these reserved device
> memory as well.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>, with one small comment

> ---
>  tools/libxc/xc_hvm_build_x86.c | 94
> +++++++++++++++++++++++++++++++++++-------
>  1 file changed, 79 insertions(+), 15 deletions(-)
> 
> diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
> index c81a25b..ddcf06d 100644
> --- a/tools/libxc/xc_hvm_build_x86.c
> +++ b/tools/libxc/xc_hvm_build_x86.c
> @@ -54,9 +54,82 @@
> 
>  #define VGA_HOLE_SIZE (0x20)
> 
> +/*
> + * Check whether there exists mmio hole in the specified memory range.
> + * Returns 1 if exists, else returns 0.
> + */
> +static int check_mmio_hole(uint64_t start, uint64_t memsize,
> +                           uint64_t mmio_start, uint64_t mmio_size)
> +{
> +    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
> +        return 0;
> +    else
> +        return 1;
> +}
> +
> +/* Getting all reserved device memory map info. */
> +static struct xen_reserved_device_memory
> +*xc_get_reserved_device_memory_map(xc_interface *xch, unsigned int
> nr_entries,
> +                                   uint32_t dom)
> +{
> +    struct xen_reserved_device_memory *xrdm = NULL;
> +    int rc = xc_reserved_device_memory_map(xch, dom, xrdm,
> &nr_entries);
> +
> +    if ( rc < 0 )
> +    {
> +        if ( errno == ENOBUFS )
> +        {
> +            if ( (xrdm = malloc(nr_entries *
> +
> sizeof(xen_reserved_device_memory_t))) == NULL )
> +            {
> +                PERROR("Could not allocate memory.");
> +                return 0;
> +            }
> +            rc = xc_reserved_device_memory_map(xch, dom, xrdm,
> &nr_entries);
> +            if ( rc )
> +            {
> +                PERROR("Could not get reserved device memory maps.");
> +                free(xrdm);
> +                return 0;
> +            }
> +        }
> +        else
> +            PERROR("Could not get reserved device memory maps.");
> +    }
> +
> +    return xrdm;
> +}
> +
> +static int xc_check_modules_space(xc_interface *xch, uint64_t *mstart_out,
> +                                  uint64_t *mend_out, uint32_t dom)
> +{
> +    unsigned int i = 0, nr_entries = 0;
> +    uint64_t rdm_start = 0, rdm_end = 0;
> +    struct xen_reserved_device_memory *rdm_map =
> +                        xc_get_reserved_device_memory_map(xch,
> nr_entries, dom);
> +
> +    for ( i = 0; i < nr_entries; i++ )
> +    {
> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << XC_PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages <<
> XC_PAGE_SHIFT);
> +
> +        /* Just use check_mmio_hole() to check modules ranges. */
> +        if ( check_mmio_hole(rdm_start,
> +                             rdm_end - rdm_start,

then you don't need a rdm_end variable here, since only size is wanted.

> +                             *mstart_out, *mend_out) )
> +            return -1;
> +    }
> +
> +    free(rdm_map);
> +
> +    return 0;
> +}
> +
>  static int modules_init(struct xc_hvm_build_args *args,
>                          uint64_t vend, struct elf_binary *elf,
> -                        uint64_t *mstart_out, uint64_t *mend_out)
> +                        uint64_t *mstart_out, uint64_t *mend_out,
> +                        xc_interface *xch,
> +                        uint32_t dom)
>  {
>  #define MODULE_ALIGN 1UL << 7
>  #define MB_ALIGN     1UL << 20
> @@ -80,6 +153,10 @@ static int modules_init(struct xc_hvm_build_args
> *args,
>      if ( *mend_out > vend )
>          return -1;
> 
> +    /* Is it overlapping with reserved device memory? */
> +    if ( xc_check_modules_space(xch, mstart_out, mend_out, dom) )
> +        return -1;
> +
>      if ( args->acpi_module.length != 0 )
>          args->acpi_module.guest_addr_out = *mstart_out;
>      if ( args->smbios_module.length != 0 )
> @@ -226,19 +303,6 @@ static int loadmodules(xc_interface *xch,
>      return rc;
>  }
> 
> -/*
> - * Check whether there exists mmio hole in the specified memory range.
> - * Returns 1 if exists, else returns 0.
> - */
> -static int check_mmio_hole(uint64_t start, uint64_t memsize,
> -                           uint64_t mmio_start, uint64_t mmio_size)
> -{
> -    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
> -        return 0;
> -    else
> -        return 1;
> -}
> -
>  static int setup_guest(xc_interface *xch,
>                         uint32_t dom, struct xc_hvm_build_args *args,
>                         char *image, unsigned long image_size)
> @@ -282,7 +346,7 @@ static int setup_guest(xc_interface *xch,
>          goto error_out;
>      }
> 
> -    if ( modules_init(args, v_end, &elf, &m_start, &m_end) != 0 )
> +    if ( modules_init(args, v_end, &elf, &m_start, &m_end, xch, dom) != 0 )
>      {
>          ERROR("Insufficient space to load modules.");
>          goto error_out;
> --
> 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 Dec 02 08:59:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 08: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 1XvjIl-0007Eu-Lq; Tue, 02 Dec 2014 08:59:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XvjIk-0007En-Eq
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 08:59:18 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	47/BD-02696-56F7D745; Tue, 02 Dec 2014 08:59:17 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417510756!12396565!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 20338 invoked from network); 2 Dec 2014 08:59:16 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-27.messagelabs.com with SMTP;
	2 Dec 2014 08:59:16 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 02 Dec 2014 00:56:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="617144062"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by orsmga001.jf.intel.com with ESMTP; 02 Dec 2014 00:59:12 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 16:59:11 +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, 2 Dec 2014 16:59:10 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 07/17] hvmloader/util: get reserved device memory maps
Thread-Index: AQHQDUmHjmUlCxxh30uC+WVrZsEO1px8AVYw
Date: Tue, 2 Dec 2014 08:59:08 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610ABCD@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-8-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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: Monday, December 01, 2014 5:24 PM
> 
> We need to use reserved device memory maps with multiple times, so
> provide just one common function should be friend.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/util.c | 59
> +++++++++++++++++++++++++++++++++++++++++
>  tools/firmware/hvmloader/util.h |  2 ++
>  2 files changed, 61 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 80d822f..dd81fb6 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -22,11 +22,14 @@
>  #include "config.h"
>  #include "hypercall.h"
>  #include "ctype.h"
> +#include "errno.h"
>  #include <stdint.h>
>  #include <xen/xen.h>
>  #include <xen/memory.h>
>  #include <xen/sched.h>
> 
> +struct xen_reserved_device_memory *rdm_map;
> +
>  void wrmsr(uint32_t idx, uint64_t v)
>  {
>      asm volatile (
> @@ -828,6 +831,62 @@ int hpet_exists(unsigned long hpet_base)
>      return ((hpet_id >> 16) == 0x8086);
>  }
> 
> +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 = {
> +        .domid = DOMID_SELF,
> +        .nr_entries = *max_entries
> +    };
> +
> +    set_xen_guest_handle(xrdmmap.buffer, entries);
> +
> +    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map,
> &xrdmmap);
> +    *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)
> +{
> +    static unsigned int nr_entries = 0;
> +    int rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
> +

if this function is aimed to be invoked once, just check wheher rdm_map
is valid instead of always issuing a new call.

> +    if ( rc == -ENOBUFS )
> +    {
> +        rdm_map = mem_alloc(nr_entries*sizeof(struct
> xen_reserved_device_memory),
> +                            0);
> +        if ( rdm_map )
> +        {
> +            rc = get_reserved_device_memory_map(rdm_map,
> &nr_entries);
> +            if ( rc )
> +            {
> +                printf("Could not get reserved dev memory info on
> domain");
> +                return 0;

why return '0' at failure?

> +            }
> +        }
> +        else
> +        {
> +            printf("No space to get reserved dev memory maps!\n");
> +            return 0;
> +        }
> +    }
> +    else if ( rc )
> +    {
> +        printf("Could not get reserved dev memory info on domain");
> +        return 0;
> +    }
> +
> +    return nr_entries;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/firmware/hvmloader/util.h
> b/tools/firmware/hvmloader/util.h
> index a70e4aa..e4f1851 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -241,6 +241,8 @@ int build_e820_table(struct e820entry *e820,
>                       unsigned int bios_image_base);
>  void dump_e820_table(struct e820entry *e820, unsigned int nr);
> 
> +unsigned int hvm_get_reserved_device_memory_map(void);
> +
>  #ifndef NDEBUG
>  void perform_tests(void);
>  #else
> --
> 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 Dec 02 08:59:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 08: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 1XvjIl-0007Eu-Lq; Tue, 02 Dec 2014 08:59:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XvjIk-0007En-Eq
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 08:59:18 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	47/BD-02696-56F7D745; Tue, 02 Dec 2014 08:59:17 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417510756!12396565!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 20338 invoked from network); 2 Dec 2014 08:59:16 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-27.messagelabs.com with SMTP;
	2 Dec 2014 08:59:16 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 02 Dec 2014 00:56:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="617144062"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by orsmga001.jf.intel.com with ESMTP; 02 Dec 2014 00:59:12 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 16:59:11 +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, 2 Dec 2014 16:59:10 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 07/17] hvmloader/util: get reserved device memory maps
Thread-Index: AQHQDUmHjmUlCxxh30uC+WVrZsEO1px8AVYw
Date: Tue, 2 Dec 2014 08:59:08 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610ABCD@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-8-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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: Monday, December 01, 2014 5:24 PM
> 
> We need to use reserved device memory maps with multiple times, so
> provide just one common function should be friend.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/util.c | 59
> +++++++++++++++++++++++++++++++++++++++++
>  tools/firmware/hvmloader/util.h |  2 ++
>  2 files changed, 61 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 80d822f..dd81fb6 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -22,11 +22,14 @@
>  #include "config.h"
>  #include "hypercall.h"
>  #include "ctype.h"
> +#include "errno.h"
>  #include <stdint.h>
>  #include <xen/xen.h>
>  #include <xen/memory.h>
>  #include <xen/sched.h>
> 
> +struct xen_reserved_device_memory *rdm_map;
> +
>  void wrmsr(uint32_t idx, uint64_t v)
>  {
>      asm volatile (
> @@ -828,6 +831,62 @@ int hpet_exists(unsigned long hpet_base)
>      return ((hpet_id >> 16) == 0x8086);
>  }
> 
> +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 = {
> +        .domid = DOMID_SELF,
> +        .nr_entries = *max_entries
> +    };
> +
> +    set_xen_guest_handle(xrdmmap.buffer, entries);
> +
> +    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map,
> &xrdmmap);
> +    *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)
> +{
> +    static unsigned int nr_entries = 0;
> +    int rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
> +

if this function is aimed to be invoked once, just check wheher rdm_map
is valid instead of always issuing a new call.

> +    if ( rc == -ENOBUFS )
> +    {
> +        rdm_map = mem_alloc(nr_entries*sizeof(struct
> xen_reserved_device_memory),
> +                            0);
> +        if ( rdm_map )
> +        {
> +            rc = get_reserved_device_memory_map(rdm_map,
> &nr_entries);
> +            if ( rc )
> +            {
> +                printf("Could not get reserved dev memory info on
> domain");
> +                return 0;

why return '0' at failure?

> +            }
> +        }
> +        else
> +        {
> +            printf("No space to get reserved dev memory maps!\n");
> +            return 0;
> +        }
> +    }
> +    else if ( rc )
> +    {
> +        printf("Could not get reserved dev memory info on domain");
> +        return 0;
> +    }
> +
> +    return nr_entries;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/firmware/hvmloader/util.h
> b/tools/firmware/hvmloader/util.h
> index a70e4aa..e4f1851 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -241,6 +241,8 @@ int build_e820_table(struct e820entry *e820,
>                       unsigned int bios_image_base);
>  void dump_e820_table(struct e820entry *e820, unsigned int nr);
> 
> +unsigned int hvm_get_reserved_device_memory_map(void);
> +
>  #ifndef NDEBUG
>  void perform_tests(void);
>  #else
> --
> 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 Dec 02 09:11:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09: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 1XvjUY-0007Wj-6G; Tue, 02 Dec 2014 09:11:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XvjUX-0007We-6G
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 09:11:29 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	7C/7F-02953-0428D745; Tue, 02 Dec 2014 09:11:28 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417511486!7745566!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 6226 invoked from network); 2 Dec 2014 09:11:27 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-27.messagelabs.com with SMTP;
	2 Dec 2014 09:11:27 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2014 01:11:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="631238752"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2014 01:11:23 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 17:11:22 +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, 2 Dec 2014 17:11:21 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 08/17] hvmloader/mmio: reconcile guest mmio with
	reserved device memory
Thread-Index: AQHQDUmIFzkXIenq7k+3qBTY2jsgvJx8A++A
Date: Tue, 2 Dec 2014 09:11:20 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610ABFD@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-9-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-9-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 08/17] hvmloader/mmio: reconcile guest
 mmio with reserved device 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

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:24 PM
> 
> We need to make sure all mmio allocation don't overlap
> any rdm, reserved device memory. Here we just skip
> all reserved device memory range in mmio space.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/pci.c  | 54
> ++++++++++++++++++++++++++++++++++++++++-
>  tools/firmware/hvmloader/util.c |  9 +++++++
>  tools/firmware/hvmloader/util.h |  2 ++
>  3 files changed, 64 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index 4e8d803..fc22ab3 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -38,6 +38,30 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
>  enum virtual_vga virtual_vga = VGA_none;
>  unsigned long igd_opregion_pgbase = 0;
> 
> +static unsigned int need_skip_rmrr;
> +extern struct xen_reserved_device_memory *rdm_map;
> +
> +static unsigned int
> +check_reserved_device_memory_map(uint64_t mmio_base, uint64_t
> mmio_max)
> +{
> +    uint32_t i;
> +    uint64_t rdm_start, rdm_end;
> +    unsigned int nr_rdm_entries =
> hvm_get_reserved_device_memory_map();
> +
> +    for ( i = 0; i < nr_rdm_entries; i++ )
> +    {
> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages <<
> PAGE_SHIFT);
> +        if ( check_rdm_hole_conflict(mmio_base, mmio_max -
> mmio_base,
> +                                     rdm_start, rdm_end -
> rdm_start) )
> +        {
> +            need_skip_rmrr++;
> +        }
> +    }
> +
> +    return nr_rdm_entries;
> +}
> +

I don't understand the use of need_skip_rmrr here. What does the counter actually
mean here? Also the function is not well organized. Usually the value returned is
the major purpose of the function, but it looks the function is actually for need_skip_rmrr.
If it's the actual purpose, better to rename the function and move nr_rdm_entries
directly in the outer function.

>  void pci_setup(void)
>  {
>      uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> @@ -59,8 +83,10 @@ void pci_setup(void)
>          uint32_t bar_reg;
>          uint64_t bar_sz;
>      } *bars = (struct bars *)scratch_start;
> -    unsigned int i, nr_bars = 0;
> +    unsigned int i, j, nr_bars = 0;
>      uint64_t mmio_hole_size = 0;
> +    unsigned int nr_rdm_entries;
> +    uint64_t rdm_start, rdm_end;
> 
>      const char *s;
>      /*
> @@ -338,6 +364,14 @@ void pci_setup(void)
>      io_resource.base = 0xc000;
>      io_resource.max = 0x10000;
> 
> +    /* Check low mmio range. */
> +    nr_rdm_entries =
> check_reserved_device_memory_map(mem_resource.base,
> +
> mem_resource.max);
> +    /* Check high mmio range. */
> +    if ( nr_rdm_entries )
> +        nr_rdm_entries =
> check_reserved_device_memory_map(high_mem_resource.base,
> +
> high_mem_resource.max);
> +
>      /* Assign iomem and ioport resources in descending order of size. */
>      for ( i = 0; i < nr_bars; i++ )
>      {
> @@ -393,8 +427,26 @@ void pci_setup(void)
>          }
> 
>          base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> + reallocate_mmio:
>          bar_data |= (uint32_t)base;
>          bar_data_upper = (uint32_t)(base >> 32);
> +
> +        if ( need_skip_rmrr )
> +        {
> +            for ( j = 0; j < nr_rdm_entries; j++ )
> +            {
> +                rdm_start = (uint64_t)rdm_map[j].start_pfn <<
> PAGE_SHIFT;
> +                rdm_end = rdm_start + ((uint64_t)rdm_map[j].nr_pages
> << PAGE_SHIFT);
> +                if ( check_rdm_hole_conflict(base, bar_sz,
> +                                             rdm_start, rdm_end -
> rdm_start) )
> +                {
> +                    base = (rdm_end  + bar_sz - 1) & ~(uint64_t)(bar_sz
> - 1);
> +                    need_skip_rmrr--;
> +                    goto reallocate_mmio;
> +                }
> +            }
> +        }
> +

here is the point which I don't understand. what's required here is just to
walk the rmrr entries for a given allocation, and if conflicting then move
the base. Then how does need_skip_rmrr helps here? and why do you
need pre-check on low/high region earlier?

>          base += bar_sz;
> 
>          if ( (base < resource->base) || (base > resource->max) )
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index dd81fb6..8767897 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -887,6 +887,15 @@ unsigned int
> hvm_get_reserved_device_memory_map(void)
>      return nr_entries;
>  }
> 
> +int check_rdm_hole_conflict(uint64_t start, uint64_t size,
> +                            uint64_t rdm_start, uint64_t rdm_size)
> +{
> +    if ( start + size <= rdm_start || start >= rdm_start + rdm_size )
> +        return 0;
> +    else
> +        return 1;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/firmware/hvmloader/util.h
> b/tools/firmware/hvmloader/util.h
> index e4f1851..9b02f95 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -242,6 +242,8 @@ int build_e820_table(struct e820entry *e820,
>  void dump_e820_table(struct e820entry *e820, unsigned int nr);
> 
>  unsigned int hvm_get_reserved_device_memory_map(void);
> +int check_rdm_hole_conflict(uint64_t start, uint64_t size,
> +                            uint64_t rdm_start, uint64_t rdm_size);
> 
>  #ifndef NDEBUG
>  void perform_tests(void);
> --
> 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 Dec 02 09:11:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09: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 1XvjUY-0007Wj-6G; Tue, 02 Dec 2014 09:11:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XvjUX-0007We-6G
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 09:11:29 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	7C/7F-02953-0428D745; Tue, 02 Dec 2014 09:11:28 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417511486!7745566!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 6226 invoked from network); 2 Dec 2014 09:11:27 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-27.messagelabs.com with SMTP;
	2 Dec 2014 09:11:27 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2014 01:11:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="631238752"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2014 01:11:23 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 17:11:22 +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, 2 Dec 2014 17:11:21 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 08/17] hvmloader/mmio: reconcile guest mmio with
	reserved device memory
Thread-Index: AQHQDUmIFzkXIenq7k+3qBTY2jsgvJx8A++A
Date: Tue, 2 Dec 2014 09:11:20 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610ABFD@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-9-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-9-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 08/17] hvmloader/mmio: reconcile guest
 mmio with reserved device 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

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:24 PM
> 
> We need to make sure all mmio allocation don't overlap
> any rdm, reserved device memory. Here we just skip
> all reserved device memory range in mmio space.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/pci.c  | 54
> ++++++++++++++++++++++++++++++++++++++++-
>  tools/firmware/hvmloader/util.c |  9 +++++++
>  tools/firmware/hvmloader/util.h |  2 ++
>  3 files changed, 64 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index 4e8d803..fc22ab3 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -38,6 +38,30 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
>  enum virtual_vga virtual_vga = VGA_none;
>  unsigned long igd_opregion_pgbase = 0;
> 
> +static unsigned int need_skip_rmrr;
> +extern struct xen_reserved_device_memory *rdm_map;
> +
> +static unsigned int
> +check_reserved_device_memory_map(uint64_t mmio_base, uint64_t
> mmio_max)
> +{
> +    uint32_t i;
> +    uint64_t rdm_start, rdm_end;
> +    unsigned int nr_rdm_entries =
> hvm_get_reserved_device_memory_map();
> +
> +    for ( i = 0; i < nr_rdm_entries; i++ )
> +    {
> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages <<
> PAGE_SHIFT);
> +        if ( check_rdm_hole_conflict(mmio_base, mmio_max -
> mmio_base,
> +                                     rdm_start, rdm_end -
> rdm_start) )
> +        {
> +            need_skip_rmrr++;
> +        }
> +    }
> +
> +    return nr_rdm_entries;
> +}
> +

I don't understand the use of need_skip_rmrr here. What does the counter actually
mean here? Also the function is not well organized. Usually the value returned is
the major purpose of the function, but it looks the function is actually for need_skip_rmrr.
If it's the actual purpose, better to rename the function and move nr_rdm_entries
directly in the outer function.

>  void pci_setup(void)
>  {
>      uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> @@ -59,8 +83,10 @@ void pci_setup(void)
>          uint32_t bar_reg;
>          uint64_t bar_sz;
>      } *bars = (struct bars *)scratch_start;
> -    unsigned int i, nr_bars = 0;
> +    unsigned int i, j, nr_bars = 0;
>      uint64_t mmio_hole_size = 0;
> +    unsigned int nr_rdm_entries;
> +    uint64_t rdm_start, rdm_end;
> 
>      const char *s;
>      /*
> @@ -338,6 +364,14 @@ void pci_setup(void)
>      io_resource.base = 0xc000;
>      io_resource.max = 0x10000;
> 
> +    /* Check low mmio range. */
> +    nr_rdm_entries =
> check_reserved_device_memory_map(mem_resource.base,
> +
> mem_resource.max);
> +    /* Check high mmio range. */
> +    if ( nr_rdm_entries )
> +        nr_rdm_entries =
> check_reserved_device_memory_map(high_mem_resource.base,
> +
> high_mem_resource.max);
> +
>      /* Assign iomem and ioport resources in descending order of size. */
>      for ( i = 0; i < nr_bars; i++ )
>      {
> @@ -393,8 +427,26 @@ void pci_setup(void)
>          }
> 
>          base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> + reallocate_mmio:
>          bar_data |= (uint32_t)base;
>          bar_data_upper = (uint32_t)(base >> 32);
> +
> +        if ( need_skip_rmrr )
> +        {
> +            for ( j = 0; j < nr_rdm_entries; j++ )
> +            {
> +                rdm_start = (uint64_t)rdm_map[j].start_pfn <<
> PAGE_SHIFT;
> +                rdm_end = rdm_start + ((uint64_t)rdm_map[j].nr_pages
> << PAGE_SHIFT);
> +                if ( check_rdm_hole_conflict(base, bar_sz,
> +                                             rdm_start, rdm_end -
> rdm_start) )
> +                {
> +                    base = (rdm_end  + bar_sz - 1) & ~(uint64_t)(bar_sz
> - 1);
> +                    need_skip_rmrr--;
> +                    goto reallocate_mmio;
> +                }
> +            }
> +        }
> +

here is the point which I don't understand. what's required here is just to
walk the rmrr entries for a given allocation, and if conflicting then move
the base. Then how does need_skip_rmrr helps here? and why do you
need pre-check on low/high region earlier?

>          base += bar_sz;
> 
>          if ( (base < resource->base) || (base > resource->max) )
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index dd81fb6..8767897 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -887,6 +887,15 @@ unsigned int
> hvm_get_reserved_device_memory_map(void)
>      return nr_entries;
>  }
> 
> +int check_rdm_hole_conflict(uint64_t start, uint64_t size,
> +                            uint64_t rdm_start, uint64_t rdm_size)
> +{
> +    if ( start + size <= rdm_start || start >= rdm_start + rdm_size )
> +        return 0;
> +    else
> +        return 1;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/firmware/hvmloader/util.h
> b/tools/firmware/hvmloader/util.h
> index e4f1851..9b02f95 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -242,6 +242,8 @@ int build_e820_table(struct e820entry *e820,
>  void dump_e820_table(struct e820entry *e820, unsigned int nr);
> 
>  unsigned int hvm_get_reserved_device_memory_map(void);
> +int check_rdm_hole_conflict(uint64_t start, uint64_t size,
> +                            uint64_t rdm_start, uint64_t rdm_size);
> 
>  #ifndef NDEBUG
>  void perform_tests(void);
> --
> 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 Dec 02 09:29:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09:29:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvjly-0007oG-Sg; Tue, 02 Dec 2014 09:29: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 1Xvjly-0007o8-0v; Tue, 02 Dec 2014 09:29:30 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	B9/C0-20609-9768D745; Tue, 02 Dec 2014 09:29:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417512567!12411158!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11243 invoked from network); 2 Dec 2014 09:29:28 -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;
	2 Dec 2014 09:29:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,499,1413244800"; d="scan'208";a="198769863"
Message-ID: <1417512564.15063.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mark Pryor <tlviewer@yahoo.com>
Date: Tue, 2 Dec 2014 09:29:24 +0000
In-Reply-To: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Olaf Hering <olaf@aepfle.de>, 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>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-01 at 23:41 +0000, Mark Pryor wrote:
> list,

Thanks. If you've identified a buggy changeset then it is fine to post
to the devel lists. I've added a CC. I've also CCd everyone listed in
the commit which you've fingered.

Olaf, does this suggested change look correct? If so then can you turn
it into a patch please.

> 
> 
>  this commit to 4.5: 
> 
> git show 4542ae340d75bd6319e3fcd94e6c9336e210aeef
> 
> 
> 
>  ^^ causes my C7 install to hang at shutdown.
>  xenstored.service will shutdown in parallel with xendomains before it
> should
>  and its broken
> 
> its by Olaf
> I took the time to narrow the commit down exactly.. first time I ever
> did that
> Its a regression. The xen shutdown process in systemd was OK before
> that commit
> 
> 
> 
> xenconsoled.service needs
> After=xenstored.service
> 
> 
> not,
> After=xenstored.socket
> 
> 
> regards,
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 09:29:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09:29:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvjly-0007oG-Sg; Tue, 02 Dec 2014 09:29: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 1Xvjly-0007o8-0v; Tue, 02 Dec 2014 09:29:30 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	B9/C0-20609-9768D745; Tue, 02 Dec 2014 09:29:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417512567!12411158!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11243 invoked from network); 2 Dec 2014 09:29:28 -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;
	2 Dec 2014 09:29:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,499,1413244800"; d="scan'208";a="198769863"
Message-ID: <1417512564.15063.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mark Pryor <tlviewer@yahoo.com>
Date: Tue, 2 Dec 2014 09:29:24 +0000
In-Reply-To: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Olaf Hering <olaf@aepfle.de>, 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>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-01 at 23:41 +0000, Mark Pryor wrote:
> list,

Thanks. If you've identified a buggy changeset then it is fine to post
to the devel lists. I've added a CC. I've also CCd everyone listed in
the commit which you've fingered.

Olaf, does this suggested change look correct? If so then can you turn
it into a patch please.

> 
> 
>  this commit to 4.5: 
> 
> git show 4542ae340d75bd6319e3fcd94e6c9336e210aeef
> 
> 
> 
>  ^^ causes my C7 install to hang at shutdown.
>  xenstored.service will shutdown in parallel with xendomains before it
> should
>  and its broken
> 
> its by Olaf
> I took the time to narrow the commit down exactly.. first time I ever
> did that
> Its a regression. The xen shutdown process in systemd was OK before
> that commit
> 
> 
> 
> xenconsoled.service needs
> After=xenstored.service
> 
> 
> not,
> After=xenstored.socket
> 
> 
> regards,
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 09:35:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09: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 1Xvjre-00089L-7W; Tue, 02 Dec 2014 09:35: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 1Xvjrc-00089D-Lc
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 09:35:20 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BC/D8-09842-8D78D745; Tue, 02 Dec 2014 09:35:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417512918!12448503!1
X-Originating-IP: [66.165.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 19090 invoked from network); 2 Dec 2014 09:35: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;
	2 Dec 2014 09:35:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,499,1413244800"; d="scan'208";a="198439778"
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, 2 Dec 2014 04:35:17 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XvjrY-0001Ot-QR;
	Tue, 02 Dec 2014 09:35:16 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvjrY-0001uc-Jp;
	Tue, 02 Dec 2014 09:35:16 +0000
Date: Tue, 2 Dec 2014 09:35:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31980-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] 31980: 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 31980 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31980/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  3 host-install(3)     broken REGR. vs. 31241
 test-amd64-i386-libvirt       3 host-install(3)         broken 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    3 host-install(3)         broken REGR. vs. 31241
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 31241
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 31241
 test-amd64-amd64-xl-win7-amd64  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

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-amd64-xl-sedf      3 host-install(3)         broken 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-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-amd64-xl-qemut-winxpsp3 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-amd64-xl-qemuu-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-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:
 linux                009d0431c3914de64666bec0d350e54fdd59df6a
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
700 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                    broken  
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     broken  
 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                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-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                                      broken  
 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                                     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-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://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-rumpuserxen-i386 host-install(3)
broken-step test-amd64-i386-libvirt host-install(3)
broken-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-xl-win7-amd64 host-install(3)
broken-step test-amd64-amd64-xl-win7-amd64 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-sedf host-install(3)

Not pushing.

(No revision log; it would be 30868 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 Dec 02 09:35:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09: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 1Xvjre-00089L-7W; Tue, 02 Dec 2014 09:35: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 1Xvjrc-00089D-Lc
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 09:35:20 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BC/D8-09842-8D78D745; Tue, 02 Dec 2014 09:35:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417512918!12448503!1
X-Originating-IP: [66.165.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 19090 invoked from network); 2 Dec 2014 09:35: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;
	2 Dec 2014 09:35:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,499,1413244800"; d="scan'208";a="198439778"
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, 2 Dec 2014 04:35:17 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XvjrY-0001Ot-QR;
	Tue, 02 Dec 2014 09:35:16 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvjrY-0001uc-Jp;
	Tue, 02 Dec 2014 09:35:16 +0000
Date: Tue, 2 Dec 2014 09:35:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31980-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] 31980: 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 31980 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31980/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  3 host-install(3)     broken REGR. vs. 31241
 test-amd64-i386-libvirt       3 host-install(3)         broken 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    3 host-install(3)         broken REGR. vs. 31241
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 31241
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 31241
 test-amd64-amd64-xl-win7-amd64  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

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-amd64-xl-sedf      3 host-install(3)         broken 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-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-amd64-xl-qemut-winxpsp3 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-amd64-xl-qemuu-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-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:
 linux                009d0431c3914de64666bec0d350e54fdd59df6a
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
700 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                    broken  
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     broken  
 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                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-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                                      broken  
 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                                     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-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


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

Logs, config files, etc. are available at
    http://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-rumpuserxen-i386 host-install(3)
broken-step test-amd64-i386-libvirt host-install(3)
broken-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-xl-win7-amd64 host-install(3)
broken-step test-amd64-amd64-xl-win7-amd64 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-sedf host-install(3)

Not pushing.

(No revision log; it would be 30868 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 Dec 02 09:39:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvjvH-0008JQ-Rh; Tue, 02 Dec 2014 09:39:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XvjvG-0008JJ-Ja
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 09:39:06 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	B9/3C-23865-9B88D745; Tue, 02 Dec 2014 09:39:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417513145!15173969!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13125 invoked from network); 2 Dec 2014 09:39:05 -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; 2 Dec 2014 09:39:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 09:39:04 +0000
Message-Id: <547D96C4020000780004C047@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 09:39:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zhang Yu" <yu.c.zhang@linux.intel.com>,"Tim Deegan" <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547C6D98020000780004BB9D@mail.emea.novell.com>
	<547D6ED6.2030803@linux.intel.com>
In-Reply-To: <547D6ED6.2030803@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, 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 02.12.14 at 08:48, <yu.c.zhang@linux.intel.com> wrote:

> 
> On 12/1/2014 8:31 PM, Jan Beulich wrote:
>>>>> On 01.12.14 at 13:13, <tim@xen.org> wrote:
>>> At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>>>>>>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>>>>> At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
>>>>>>>>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
>>>>>>> To my understanding, pages with p2m_ram_ro are not supposed to be
>>>>>>> modified by guest. So in __hvm_copy(), when p2m type of a page is
>>>>>>> p2m_ram_rom, no copy will occur.
>>>>>>> However, to our usage, we just wanna this page to be write protected, so
>>>>>>> that our device model can be triggered to do some emulation. The content
>>>>>>> written to this page is supposed not to be dropped. This way, if
>>>>>>> sequentially a read operation is performed by guest to this page, the
>>>>>>> guest will still see its anticipated value.
>>>>>>
>>>>>> __hvm_copy() is only a helper function, and doesn't write to
>>>>>> mmio_dm space either; instead its (indirect) callers would invoke
>>>>>> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
>>>>>> returns. The question hence is about the apparent inconsistency
>>>>>> resulting from writes to ram_ro being dropped here but getting
>>>>>> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
>>>>>> that really intentional?
>>>>>
>>>>> No - and AFAICT it shouldn't be happening.  It _is_ how it was
>>>>> implemented originally, because it involved fewer moving parts and
>>>>> didn't need to be efficient (and after all, writes to entirely missing
>>>>> addresses go to the device model too).
>>>>>
>>>>> But the code was later updated to log and discard writes to read-only
>>>>> memory (see 4d8aa29 from Trolle Selander).
>>>>>
>>>>> Early version of p2m_ram_ro were documented in the internal headers as
>>>>> sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
>>>>> has always said that writes are discarded.
>>>>
>>>> Hmm, so which way do you recommend resolving the inconsistency
>>>> then - match what the public interface says or what the apparent
>>>> original intention for the internal type was? Presumably we need to
>>>> follow the public interface mandated model, and hence require the
>>>> new type to be introduced.
>>>
>>> Sorry, I was unclear -- there isn't an inconsistency; both internal
>>> and public headers currently say that writes are discarded and AFAICT
>>> that is what the code does.
>>
>> Not for hvm_hap_nested_page_fault() afaict - the forwarding to
>> DM there contradicts the "writes are discarded" model that other
>> code paths follow.
>>
> Thanks, Jan.
> By "inconsistency", do you mean the p2m_ram_ro shall not trigger the 
> handle_mmio_with_translation() in hvm_hap_nested_page_fault()?

Yes, pending Tim's agreement.

> I'm also a bit confused with the "writes are discarded/dropped" comments 
> in the code. Does this mean writes to the p2m_ram_ro pages should be 
> abandoned without going to the dm, or going to the dm and  ignored 
> later? The code seems to be the second one.

And it would seem to me that it should be the former.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 09:39:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvjvH-0008JQ-Rh; Tue, 02 Dec 2014 09:39:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XvjvG-0008JJ-Ja
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 09:39:06 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	B9/3C-23865-9B88D745; Tue, 02 Dec 2014 09:39:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417513145!15173969!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13125 invoked from network); 2 Dec 2014 09:39:05 -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; 2 Dec 2014 09:39:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 09:39:04 +0000
Message-Id: <547D96C4020000780004C047@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 09:39:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zhang Yu" <yu.c.zhang@linux.intel.com>,"Tim Deegan" <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547C6D98020000780004BB9D@mail.emea.novell.com>
	<547D6ED6.2030803@linux.intel.com>
In-Reply-To: <547D6ED6.2030803@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, 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 02.12.14 at 08:48, <yu.c.zhang@linux.intel.com> wrote:

> 
> On 12/1/2014 8:31 PM, Jan Beulich wrote:
>>>>> On 01.12.14 at 13:13, <tim@xen.org> wrote:
>>> At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>>>>>>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>>>>> At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
>>>>>>>>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
>>>>>>> To my understanding, pages with p2m_ram_ro are not supposed to be
>>>>>>> modified by guest. So in __hvm_copy(), when p2m type of a page is
>>>>>>> p2m_ram_rom, no copy will occur.
>>>>>>> However, to our usage, we just wanna this page to be write protected, so
>>>>>>> that our device model can be triggered to do some emulation. The content
>>>>>>> written to this page is supposed not to be dropped. This way, if
>>>>>>> sequentially a read operation is performed by guest to this page, the
>>>>>>> guest will still see its anticipated value.
>>>>>>
>>>>>> __hvm_copy() is only a helper function, and doesn't write to
>>>>>> mmio_dm space either; instead its (indirect) callers would invoke
>>>>>> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
>>>>>> returns. The question hence is about the apparent inconsistency
>>>>>> resulting from writes to ram_ro being dropped here but getting
>>>>>> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
>>>>>> that really intentional?
>>>>>
>>>>> No - and AFAICT it shouldn't be happening.  It _is_ how it was
>>>>> implemented originally, because it involved fewer moving parts and
>>>>> didn't need to be efficient (and after all, writes to entirely missing
>>>>> addresses go to the device model too).
>>>>>
>>>>> But the code was later updated to log and discard writes to read-only
>>>>> memory (see 4d8aa29 from Trolle Selander).
>>>>>
>>>>> Early version of p2m_ram_ro were documented in the internal headers as
>>>>> sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
>>>>> has always said that writes are discarded.
>>>>
>>>> Hmm, so which way do you recommend resolving the inconsistency
>>>> then - match what the public interface says or what the apparent
>>>> original intention for the internal type was? Presumably we need to
>>>> follow the public interface mandated model, and hence require the
>>>> new type to be introduced.
>>>
>>> Sorry, I was unclear -- there isn't an inconsistency; both internal
>>> and public headers currently say that writes are discarded and AFAICT
>>> that is what the code does.
>>
>> Not for hvm_hap_nested_page_fault() afaict - the forwarding to
>> DM there contradicts the "writes are discarded" model that other
>> code paths follow.
>>
> Thanks, Jan.
> By "inconsistency", do you mean the p2m_ram_ro shall not trigger the 
> handle_mmio_with_translation() in hvm_hap_nested_page_fault()?

Yes, pending Tim's agreement.

> I'm also a bit confused with the "writes are discarded/dropped" comments 
> in the code. Does this mean writes to the p2m_ram_ro pages should be 
> abandoned without going to the dm, or going to the dm and  ignored 
> later? The code seems to be the second one.

And it would seem to me that it should be the former.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 09:40:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvjwB-0008Oj-9F; Tue, 02 Dec 2014 09:40:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xvjw9-0008OR-ER
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 09:40:01 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	0E/A4-05632-0F88D745; Tue, 02 Dec 2014 09:40:00 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417513200!15206630!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 1975 invoked from network); 2 Dec 2014 09:40:00 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 09:40:00 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id F054AAC18
	for <xen-devel@lists.xensource.com>;
	Tue,  2 Dec 2014 09:39:59 +0000 (UTC)
Message-ID: <547D88EF.4050206@suse.com>
Date: Tue, 02 Dec 2014 10:39:59 +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] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

looking into the upstream linux sources I realized that the PVHVM
drivers of XEN are only available with the pvops kernel. Is this on
purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
configurable without having to enable CONFIG_PARAVIRT?

Juergen

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 09:40:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvjwB-0008Oj-9F; Tue, 02 Dec 2014 09:40:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xvjw9-0008OR-ER
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 09:40:01 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	0E/A4-05632-0F88D745; Tue, 02 Dec 2014 09:40:00 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417513200!15206630!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 1975 invoked from network); 2 Dec 2014 09:40:00 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 09:40:00 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id F054AAC18
	for <xen-devel@lists.xensource.com>;
	Tue,  2 Dec 2014 09:39:59 +0000 (UTC)
Message-ID: <547D88EF.4050206@suse.com>
Date: Tue, 02 Dec 2014 10:39:59 +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] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

looking into the upstream linux sources I realized that the PVHVM
drivers of XEN are only available with the pvops kernel. Is this on
purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
configurable without having to enable CONFIG_PARAVIRT?

Juergen

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 09:42:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1Xvjyb-0000EB-3G; Tue, 02 Dec 2014 09:42:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Xvjya-0000E4-AL
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 09:42:32 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	6B/9C-20609-7898D745; Tue, 02 Dec 2014 09:42:31 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417513349!12406942!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11373 invoked from network); 2 Dec 2014 09:42:30 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-15.tower-27.messagelabs.com with SMTP;
	2 Dec 2014 09:42:30 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 02 Dec 2014 01:39:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="492164413"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by orsmga003.jf.intel.com with ESMTP; 02 Dec 2014 01:39:13 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 17:42:25 +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, 2 Dec 2014 17:42:18 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 09/17] hvmloader/ram: check if guest memory is out
	of reserved device memory maps
Thread-Index: AQHQDUmK/4QEBbod+kaNVPhbdBPGPJx8BuQA
Date: Tue, 2 Dec 2014 09:42:17 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AC79@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-10-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 09/17] 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: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:24 PM
> 
> We need to check to reserve all reserved device memory maps in e820
> to avoid any potential guest memory conflict.
> 
> Currently, if we can't insert RDM entries directly, we may need to handle
> several ranges as follows:
> a. Fixed Ranges --> BUG()
>  lowmem_reserved_base-0xA0000: reserved by BIOS implementation,
>  BIOS region,
>  RESERVED_MEMBASE ~ 0x100000000,
> b. RAM or RAM:Hole -> Try to reserve
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/e820.c | 168
> ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 168 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/e820.c
> b/tools/firmware/hvmloader/e820.c
> index 2e05e93..ef87e41 100644
> --- a/tools/firmware/hvmloader/e820.c
> +++ b/tools/firmware/hvmloader/e820.c
> @@ -22,6 +22,7 @@
> 
>  #include "config.h"
>  #include "util.h"
> +#include <xen/memory.h>
> 
>  void dump_e820_table(struct e820entry *e820, unsigned int nr)
>  {
> @@ -68,12 +69,173 @@ void dump_e820_table(struct e820entry *e820,
> unsigned int nr)
>      }
>  }
> 
> +extern struct xen_reserved_device_memory *rdm_map;
> +static unsigned int construct_rdm_e820_maps(unsigned int
> next_e820_entry_index,
> +                                            uint32_t nr_map,
> +                                            struct
> xen_reserved_device_memory *map,
> +                                            struct e820entry
> *e820,
> +                                            unsigned int
> lowmem_reserved_base,
> +                                            unsigned int
> bios_image_base)
> +{
> +    unsigned int i, j, sum_nr;
> +    uint64_t start, end, next_start, rdm_start, rdm_end;
> +    uint32_t type;
> +    int err = 0;
> +
> +    for ( i = 0; i < nr_map; i++ )
> +    {
> +        rdm_start = (uint64_t)map[i].start_pfn << PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)map[i].nr_pages <<
> PAGE_SHIFT);
> +
> +        for ( j = 0; j < next_e820_entry_index - 1; j++ )
> +        {
> +            sum_nr = next_e820_entry_index + nr_map;

need a check whether sum_nr exceeds max #entries...

> +            start = e820[j].addr;
> +            end = e820[j].addr + e820[j].size;
> +            type = e820[j].type;
> +            next_start = e820[j+1].addr;
> +
> +            if ( rdm_start >= start && rdm_start <= end )
> +            {

what about other confliction pattern here, e.g. rdm_end between [start,end]?

> +                /*
> +                 * lowmem_reserved_base-0xA0000: reserved by BIOS
> +                 * implementation.
> +                 * Or BIOS region.
> +                 */
> +                if ( (lowmem_reserved_base < 0xA0000 &&
> +                        start == lowmem_reserved_base) ||
> +                     start == bios_image_base )
> +                {
> +                    err = -1;
> +                    break;
> +                }
> +            }
> +
> +            /* Just amid those remaining e820 entries. */
> +            if ( (rdm_start > end) && (rdm_end < next_start) )

>= and <=?

> +            {
> +                memmove(&e820[j+2], &e820[j+1],
> +                        (sum_nr - j - 1) * sizeof(struct e820entry));

seems you just need (next_e820_entry_index - j - 1)

> +
> +                /* Then fill RMRR into that entry. */
> +                e820[j+1].addr = rdm_start;
> +                e820[j+1].size = rdm_end - rdm_start;
> +                e820[j+1].type = E820_RESERVED;
> +                next_e820_entry_index++;
> +                continue;

continue->break? otherwise the newly added rmrr entry will be checked next
for same rmrr entry, and then catch an unnecessary confliction.

> +            }
> +
> +            /* Already at the end. */
> +            if ( (rdm_start > end) && !next_start )
> +            {
> +                e820[next_e820_entry_index].addr = rdm_start;
> +                e820[next_e820_entry_index].size = rdm_end -
> rdm_start;
> +                e820[next_e820_entry_index].type = E820_RESERVED;
> +                next_e820_entry_index++;
> +                continue;

break though it's the last one.

> +            }
> +
> +            if ( type == E820_RAM )
> +            {
> +                /* If coincide with one RAM range. */
> +                if ( rdm_start == start && rdm_end == end)
> +                {
> +                    e820[j].type = E820_RESERVED;
> +                    continue;
> +                }
> +
> +                /* If we're just aligned with start of one RAM range. */
> +                if ( rdm_start == start && rdm_end < end )
> +                {
> +                    memmove(&e820[j+1], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j+1].addr = rdm_end;
> +                    e820[j+1].size = e820[j].addr + e820[j].size -
> rdm_end;
> +                    e820[j+1].type = E820_RAM;
> +                    next_e820_entry_index++;
> +
> +                    e820[j].addr = rdm_start;
> +                    e820[j].size = rdm_end - rdm_start;
> +                    e820[j].type = E820_RESERVED;
> +                    continue;
> +                }
> +
> +                /* If we're just aligned with end of one RAM range. */
> +                if ( rdm_start > start && rdm_end == end )
> +                {
> +                    memmove(&e820[j+1], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j].size = rdm_start - e820[j].addr;
> +                    e820[j].type = E820_RAM;
> +
> +                    e820[j+1].addr = rdm_start;
> +                    e820[j+1].size = rdm_end - rdm_start;
> +                    e820[j+1].type = E820_RESERVED;
> +                    next_e820_entry_index++;
> +                    continue;
> +                }
> +
> +                /* If we're just in of one RAM range */
> +                if ( rdm_start > start && rdm_end < end )
> +                {
> +                    memmove(&e820[j+2], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j+2].addr = rdm_end;
> +                    e820[j+2].size = e820[j].addr + e820[j].size -
> rdm_end;
> +                    e820[j+2].type = E820_RAM;
> +                    next_e820_entry_index++;
> +
> +                    e820[j+1].addr = rdm_start;
> +                    e820[j+1].size = rdm_end - rdm_start;
> +                    e820[j+1].type = E820_RESERVED;
> +                    next_e820_entry_index++;
> +
> +                    e820[j].size = rdm_start - e820[j].addr;
> +                    e820[j].type = E820_RAM;
> +                    continue;
> +                }
> +
> +                /* If we're going last RAM:Hole range */
> +                if ( end < next_start && rdm_start > start &&
> +                     rdm_end < next_start )
> +                {
> +                    memmove(&e820[j+1], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j].size = rdm_start - e820[j].addr;
> +                    e820[j].type = E820_RAM;
> +
> +                    e820[j+1].addr = rdm_start;
> +                    e820[j+1].size = rdm_end - rdm_start;
> +                    e820[j+1].type = E820_RESERVED;
> +                    next_e820_entry_index++;
> +                    continue;

above logic looks incomplete. e.g. what about a RMRR region conflicts with multiple
e820 entries, etc.

also you need detect confliction with igd_opregion too, since although it's marked
as reserved, it means some useful thing so confliction with RMRR also means problem.
ideally like Yang suggested before, opregion base can be adjusted dynamically but
here at least an error should be thrown out as the 1st step.

> +                }
> +            }
> +        }

here also need a check on 'err'. You don't want to continue the outer loop too when
you already see an error condition.

> +    }
> +
> +    /* These overlap may issue guest can't work well. */
> +    if ( err )
> +    {
> +        printf("Guest can't work with some reserved device memory
> overlap!\n");
> +        BUG();
> +    }
> +
> +    /* Fine to construct RDM mappings into e820. */
> +    return next_e820_entry_index;
> +}
> +
>  /* Create an E820 table based on memory parameters provided in hvm_info.
> */
>  int build_e820_table(struct e820entry *e820,
>                       unsigned int lowmem_reserved_base,
>                       unsigned int bios_image_base)
>  {
>      unsigned int nr = 0;
> +    unsigned int nr_entries = 0;
> 
>      if ( !lowmem_reserved_base )
>              lowmem_reserved_base = 0xA0000;
> @@ -169,6 +331,12 @@ int build_e820_table(struct e820entry *e820,
>          nr++;
>      }
> 
> +    nr_entries = hvm_get_reserved_device_memory_map();
> +    if ( nr_entries )
> +        nr = construct_rdm_e820_maps(nr, nr_entries, rdm_map, e820,
> +                                     lowmem_reserved_base,
> +                                     bios_image_base);
> +
>      return nr;
>  }
> 
> --
> 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 Dec 02 09:42:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1Xvjyb-0000EB-3G; Tue, 02 Dec 2014 09:42:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Xvjya-0000E4-AL
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 09:42:32 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	6B/9C-20609-7898D745; Tue, 02 Dec 2014 09:42:31 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417513349!12406942!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11373 invoked from network); 2 Dec 2014 09:42:30 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-15.tower-27.messagelabs.com with SMTP;
	2 Dec 2014 09:42:30 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 02 Dec 2014 01:39:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="492164413"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by orsmga003.jf.intel.com with ESMTP; 02 Dec 2014 01:39:13 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 17:42:25 +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, 2 Dec 2014 17:42:18 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 09/17] hvmloader/ram: check if guest memory is out
	of reserved device memory maps
Thread-Index: AQHQDUmK/4QEBbod+kaNVPhbdBPGPJx8BuQA
Date: Tue, 2 Dec 2014 09:42:17 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AC79@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-10-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 09/17] 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: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:24 PM
> 
> We need to check to reserve all reserved device memory maps in e820
> to avoid any potential guest memory conflict.
> 
> Currently, if we can't insert RDM entries directly, we may need to handle
> several ranges as follows:
> a. Fixed Ranges --> BUG()
>  lowmem_reserved_base-0xA0000: reserved by BIOS implementation,
>  BIOS region,
>  RESERVED_MEMBASE ~ 0x100000000,
> b. RAM or RAM:Hole -> Try to reserve
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/e820.c | 168
> ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 168 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/e820.c
> b/tools/firmware/hvmloader/e820.c
> index 2e05e93..ef87e41 100644
> --- a/tools/firmware/hvmloader/e820.c
> +++ b/tools/firmware/hvmloader/e820.c
> @@ -22,6 +22,7 @@
> 
>  #include "config.h"
>  #include "util.h"
> +#include <xen/memory.h>
> 
>  void dump_e820_table(struct e820entry *e820, unsigned int nr)
>  {
> @@ -68,12 +69,173 @@ void dump_e820_table(struct e820entry *e820,
> unsigned int nr)
>      }
>  }
> 
> +extern struct xen_reserved_device_memory *rdm_map;
> +static unsigned int construct_rdm_e820_maps(unsigned int
> next_e820_entry_index,
> +                                            uint32_t nr_map,
> +                                            struct
> xen_reserved_device_memory *map,
> +                                            struct e820entry
> *e820,
> +                                            unsigned int
> lowmem_reserved_base,
> +                                            unsigned int
> bios_image_base)
> +{
> +    unsigned int i, j, sum_nr;
> +    uint64_t start, end, next_start, rdm_start, rdm_end;
> +    uint32_t type;
> +    int err = 0;
> +
> +    for ( i = 0; i < nr_map; i++ )
> +    {
> +        rdm_start = (uint64_t)map[i].start_pfn << PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)map[i].nr_pages <<
> PAGE_SHIFT);
> +
> +        for ( j = 0; j < next_e820_entry_index - 1; j++ )
> +        {
> +            sum_nr = next_e820_entry_index + nr_map;

need a check whether sum_nr exceeds max #entries...

> +            start = e820[j].addr;
> +            end = e820[j].addr + e820[j].size;
> +            type = e820[j].type;
> +            next_start = e820[j+1].addr;
> +
> +            if ( rdm_start >= start && rdm_start <= end )
> +            {

what about other confliction pattern here, e.g. rdm_end between [start,end]?

> +                /*
> +                 * lowmem_reserved_base-0xA0000: reserved by BIOS
> +                 * implementation.
> +                 * Or BIOS region.
> +                 */
> +                if ( (lowmem_reserved_base < 0xA0000 &&
> +                        start == lowmem_reserved_base) ||
> +                     start == bios_image_base )
> +                {
> +                    err = -1;
> +                    break;
> +                }
> +            }
> +
> +            /* Just amid those remaining e820 entries. */
> +            if ( (rdm_start > end) && (rdm_end < next_start) )

>= and <=?

> +            {
> +                memmove(&e820[j+2], &e820[j+1],
> +                        (sum_nr - j - 1) * sizeof(struct e820entry));

seems you just need (next_e820_entry_index - j - 1)

> +
> +                /* Then fill RMRR into that entry. */
> +                e820[j+1].addr = rdm_start;
> +                e820[j+1].size = rdm_end - rdm_start;
> +                e820[j+1].type = E820_RESERVED;
> +                next_e820_entry_index++;
> +                continue;

continue->break? otherwise the newly added rmrr entry will be checked next
for same rmrr entry, and then catch an unnecessary confliction.

> +            }
> +
> +            /* Already at the end. */
> +            if ( (rdm_start > end) && !next_start )
> +            {
> +                e820[next_e820_entry_index].addr = rdm_start;
> +                e820[next_e820_entry_index].size = rdm_end -
> rdm_start;
> +                e820[next_e820_entry_index].type = E820_RESERVED;
> +                next_e820_entry_index++;
> +                continue;

break though it's the last one.

> +            }
> +
> +            if ( type == E820_RAM )
> +            {
> +                /* If coincide with one RAM range. */
> +                if ( rdm_start == start && rdm_end == end)
> +                {
> +                    e820[j].type = E820_RESERVED;
> +                    continue;
> +                }
> +
> +                /* If we're just aligned with start of one RAM range. */
> +                if ( rdm_start == start && rdm_end < end )
> +                {
> +                    memmove(&e820[j+1], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j+1].addr = rdm_end;
> +                    e820[j+1].size = e820[j].addr + e820[j].size -
> rdm_end;
> +                    e820[j+1].type = E820_RAM;
> +                    next_e820_entry_index++;
> +
> +                    e820[j].addr = rdm_start;
> +                    e820[j].size = rdm_end - rdm_start;
> +                    e820[j].type = E820_RESERVED;
> +                    continue;
> +                }
> +
> +                /* If we're just aligned with end of one RAM range. */
> +                if ( rdm_start > start && rdm_end == end )
> +                {
> +                    memmove(&e820[j+1], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j].size = rdm_start - e820[j].addr;
> +                    e820[j].type = E820_RAM;
> +
> +                    e820[j+1].addr = rdm_start;
> +                    e820[j+1].size = rdm_end - rdm_start;
> +                    e820[j+1].type = E820_RESERVED;
> +                    next_e820_entry_index++;
> +                    continue;
> +                }
> +
> +                /* If we're just in of one RAM range */
> +                if ( rdm_start > start && rdm_end < end )
> +                {
> +                    memmove(&e820[j+2], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j+2].addr = rdm_end;
> +                    e820[j+2].size = e820[j].addr + e820[j].size -
> rdm_end;
> +                    e820[j+2].type = E820_RAM;
> +                    next_e820_entry_index++;
> +
> +                    e820[j+1].addr = rdm_start;
> +                    e820[j+1].size = rdm_end - rdm_start;
> +                    e820[j+1].type = E820_RESERVED;
> +                    next_e820_entry_index++;
> +
> +                    e820[j].size = rdm_start - e820[j].addr;
> +                    e820[j].type = E820_RAM;
> +                    continue;
> +                }
> +
> +                /* If we're going last RAM:Hole range */
> +                if ( end < next_start && rdm_start > start &&
> +                     rdm_end < next_start )
> +                {
> +                    memmove(&e820[j+1], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j].size = rdm_start - e820[j].addr;
> +                    e820[j].type = E820_RAM;
> +
> +                    e820[j+1].addr = rdm_start;
> +                    e820[j+1].size = rdm_end - rdm_start;
> +                    e820[j+1].type = E820_RESERVED;
> +                    next_e820_entry_index++;
> +                    continue;

above logic looks incomplete. e.g. what about a RMRR region conflicts with multiple
e820 entries, etc.

also you need detect confliction with igd_opregion too, since although it's marked
as reserved, it means some useful thing so confliction with RMRR also means problem.
ideally like Yang suggested before, opregion base can be adjusted dynamically but
here at least an error should be thrown out as the 1st step.

> +                }
> +            }
> +        }

here also need a check on 'err'. You don't want to continue the outer loop too when
you already see an error condition.

> +    }
> +
> +    /* These overlap may issue guest can't work well. */
> +    if ( err )
> +    {
> +        printf("Guest can't work with some reserved device memory
> overlap!\n");
> +        BUG();
> +    }
> +
> +    /* Fine to construct RDM mappings into e820. */
> +    return next_e820_entry_index;
> +}
> +
>  /* Create an E820 table based on memory parameters provided in hvm_info.
> */
>  int build_e820_table(struct e820entry *e820,
>                       unsigned int lowmem_reserved_base,
>                       unsigned int bios_image_base)
>  {
>      unsigned int nr = 0;
> +    unsigned int nr_entries = 0;
> 
>      if ( !lowmem_reserved_base )
>              lowmem_reserved_base = 0xA0000;
> @@ -169,6 +331,12 @@ int build_e820_table(struct e820entry *e820,
>          nr++;
>      }
> 
> +    nr_entries = hvm_get_reserved_device_memory_map();
> +    if ( nr_entries )
> +        nr = construct_rdm_e820_maps(nr, nr_entries, rdm_map, e820,
> +                                     lowmem_reserved_base,
> +                                     bios_image_base);
> +
>      return nr;
>  }
> 
> --
> 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 Dec 02 09:49:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09:49:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvk4a-0000RK-Ti; Tue, 02 Dec 2014 09:48:44 +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 1Xvk4Z-0000RB-LC
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 09:48:43 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	4C/A4-14727-AFA8D745; Tue, 02 Dec 2014 09:48:42 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417513721!11024566!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 6666 invoked from network); 2 Dec 2014 09:48:42 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-13.tower-206.messagelabs.com with SMTP;
	2 Dec 2014 09:48:42 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 02 Dec 2014 01:41:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="423950812"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by FMSMGA003.fm.intel.com with ESMTP; 02 Dec 2014 01:38:10 -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; Tue, 2 Dec 2014 17:48:21 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Tue, 2 Dec 2014 17:48:19 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip any overlap
	with reserved device memory
Thread-Index: AQHQDUmN7gqygqmJTE+Kag6M8MgfNpx8DiPg
Date: Tue, 2 Dec 2014 09:48:18 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610ACB7@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-11-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip
 any overlap with reserved device 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

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:24 PM
> 
> In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
> to allocate some memory to use in runtime cycle, so we alsoe need to
> make sure all reserved device memory don't overlap such a region.

OK, seems you meant to use this patch to address opregion confliction.
when it works, I think it's better to still add opregion detection in e820,
as a modulo suggestion. It's not good to make assumption in one module
about how other module works. Now opregion is allocated dynamically,
but it may be fixed somewhere in the future. So you always need to
detect confliction, purely in e820 world, regardless of how a range is
actually allocated.

> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/util.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 8767897..f3723c7 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -416,9 +416,29 @@ static uint32_t alloc_down =
> RESERVED_MEMORY_DYNAMIC_END;
> 
>  xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
>  {
> +    unsigned int i, num = hvm_get_reserved_device_memory_map();
> +    uint64_t rdm_start, rdm_end;
> +    uint32_t alloc_start, alloc_end;
> +
>      alloc_down -= nr_mfns << PAGE_SHIFT;
> +    alloc_start = alloc_down;
> +    alloc_end = alloc_start + (nr_mfns << PAGE_SHIFT);
> +    for ( i = 0; i < num; i++ )
> +    {
> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages <<
> PAGE_SHIFT);
> +        if ( check_rdm_hole_conflict((uint64_t)alloc_start,
> +                                     (uint64_t)alloc_end,
> +                                     rdm_start, rdm_end -
> rdm_start) )
> +        {
> +            alloc_end = rdm_start;
> +            alloc_start = alloc_end - (nr_mfns << PAGE_SHIFT);
> +            BUG_ON(alloc_up >= alloc_start);
> +        }
> +    }
> +
>      BUG_ON(alloc_up >= alloc_down);
> -    return alloc_down >> PAGE_SHIFT;
> +    return alloc_start >> PAGE_SHIFT;
>  }
> 

this patch is required, but I'd prefer to have an initialization phase check
to have a sane alloc_up/down, so you don't bother detection for every
run-time call.

>  void *mem_alloc(uint32_t size, uint32_t align)
> --
> 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 Dec 02 09:49:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09:49:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvk4a-0000RK-Ti; Tue, 02 Dec 2014 09:48:44 +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 1Xvk4Z-0000RB-LC
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 09:48:43 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	4C/A4-14727-AFA8D745; Tue, 02 Dec 2014 09:48:42 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417513721!11024566!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 6666 invoked from network); 2 Dec 2014 09:48:42 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-13.tower-206.messagelabs.com with SMTP;
	2 Dec 2014 09:48:42 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 02 Dec 2014 01:41:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="423950812"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by FMSMGA003.fm.intel.com with ESMTP; 02 Dec 2014 01:38:10 -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; Tue, 2 Dec 2014 17:48:21 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Tue, 2 Dec 2014 17:48:19 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip any overlap
	with reserved device memory
Thread-Index: AQHQDUmN7gqygqmJTE+Kag6M8MgfNpx8DiPg
Date: Tue, 2 Dec 2014 09:48:18 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610ACB7@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-11-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip
 any overlap with reserved device 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

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:24 PM
> 
> In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
> to allocate some memory to use in runtime cycle, so we alsoe need to
> make sure all reserved device memory don't overlap such a region.

OK, seems you meant to use this patch to address opregion confliction.
when it works, I think it's better to still add opregion detection in e820,
as a modulo suggestion. It's not good to make assumption in one module
about how other module works. Now opregion is allocated dynamically,
but it may be fixed somewhere in the future. So you always need to
detect confliction, purely in e820 world, regardless of how a range is
actually allocated.

> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/util.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 8767897..f3723c7 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -416,9 +416,29 @@ static uint32_t alloc_down =
> RESERVED_MEMORY_DYNAMIC_END;
> 
>  xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
>  {
> +    unsigned int i, num = hvm_get_reserved_device_memory_map();
> +    uint64_t rdm_start, rdm_end;
> +    uint32_t alloc_start, alloc_end;
> +
>      alloc_down -= nr_mfns << PAGE_SHIFT;
> +    alloc_start = alloc_down;
> +    alloc_end = alloc_start + (nr_mfns << PAGE_SHIFT);
> +    for ( i = 0; i < num; i++ )
> +    {
> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages <<
> PAGE_SHIFT);
> +        if ( check_rdm_hole_conflict((uint64_t)alloc_start,
> +                                     (uint64_t)alloc_end,
> +                                     rdm_start, rdm_end -
> rdm_start) )
> +        {
> +            alloc_end = rdm_start;
> +            alloc_start = alloc_end - (nr_mfns << PAGE_SHIFT);
> +            BUG_ON(alloc_up >= alloc_start);
> +        }
> +    }
> +
>      BUG_ON(alloc_up >= alloc_down);
> -    return alloc_down >> PAGE_SHIFT;
> +    return alloc_start >> PAGE_SHIFT;
>  }
> 

this patch is required, but I'd prefer to have an initialization phase check
to have a sane alloc_up/down, so you don't bother detection for every
run-time call.

>  void *mem_alloc(uint32_t size, uint32_t align)
> --
> 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 Dec 02 09:57:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09:57:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvkCn-0000e8-Sd; Tue, 02 Dec 2014 09:57: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 1XvkCm-0000e3-74
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 09:57:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	13/A0-15461-7FC8D745; Tue, 02 Dec 2014 09:57:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417514231!12779583!1
X-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 7029 invoked from network); 2 Dec 2014 09:57:11 -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; 2 Dec 2014 09:57:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 09:57:10 +0000
Message-Id: <547D9B05020000780004C07B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 09:57:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.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>
	<alpine.DEB.2.02.1412011852390.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412011852390.14135@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, linux@eikelenboom.it,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] call xc_domain_irq_permission
 before xc_domain_irq_permission
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.12.14 at 20:22, <stefano.stabellini@eu.citrix.com> wrote:
> xc_physdev_unmap_pirq might revoke the permission to map the irq from
> the domain causing the following xc_domain_irq_permission call to fail
> and return error (domain_pirq_to_irq returns 0).

Apart from the patch title being rather confusing, isn't the root
problem then xc_physdev_unmap_pirq() removes permissions? At
least after the strict splitting of permission granting and mapping for
MMIO (commit 0561e1f0) it would seem that if the underlying
hypercall here behaves similarly to the original behavior there, it
ought to be fixed in an analogous way.

Jan

> Call xc_domain_irq_permission first to prevent this from happening
> (xc_physdev_unmap_pirq calls irq_deny_access, that doesn't fail if the
> permission is already removed).
> 
> This is a simple bug fix and I think should go in 4.5.
> 
> 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..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 




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

From xen-devel-bounces@lists.xen.org Tue Dec 02 09:57:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09:57:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvkCn-0000e8-Sd; Tue, 02 Dec 2014 09:57: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 1XvkCm-0000e3-74
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 09:57:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	13/A0-15461-7FC8D745; Tue, 02 Dec 2014 09:57:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417514231!12779583!1
X-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 7029 invoked from network); 2 Dec 2014 09:57:11 -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; 2 Dec 2014 09:57:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 09:57:10 +0000
Message-Id: <547D9B05020000780004C07B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 09:57:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.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>
	<alpine.DEB.2.02.1412011852390.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412011852390.14135@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, linux@eikelenboom.it,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] call xc_domain_irq_permission
 before xc_domain_irq_permission
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.12.14 at 20:22, <stefano.stabellini@eu.citrix.com> wrote:
> xc_physdev_unmap_pirq might revoke the permission to map the irq from
> the domain causing the following xc_domain_irq_permission call to fail
> and return error (domain_pirq_to_irq returns 0).

Apart from the patch title being rather confusing, isn't the root
problem then xc_physdev_unmap_pirq() removes permissions? At
least after the strict splitting of permission granting and mapping for
MMIO (commit 0561e1f0) it would seem that if the underlying
hypercall here behaves similarly to the original behavior there, it
ought to be fixed in an analogous way.

Jan

> Call xc_domain_irq_permission first to prevent this from happening
> (xc_physdev_unmap_pirq calls irq_deny_access, that doesn't fail if the
> permission is already removed).
> 
> This is a simple bug fix and I think should go in 4.5.
> 
> 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..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 




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

From xen-devel-bounces@lists.xen.org Tue Dec 02 09:57:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvkDB-0000fk-8t; Tue, 02 Dec 2014 09:57:37 +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 1XvkD9-0000fG-GF
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 09:57:35 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	10/16-25727-E0D8D745; Tue, 02 Dec 2014 09:57:34 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417514251!15072184!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 2187 invoked from network); 2 Dec 2014 09:57:32 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 09:57:32 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 02 Dec 2014 01:57:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="646768658"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by orsmga002.jf.intel.com with ESMTP; 02 Dec 2014 01:57:12 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 17:57:03 +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, 2 Dec 2014 17:57:02 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 11/17] xen/x86/p2m: reject populating for reserved
	device memory mapping
Thread-Index: AQHQDUmO+4bNOv0gcEqo8U2cwIXqeZx8EegQ
Date: Tue, 2 Dec 2014 09:57:01 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610ACEB@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-12-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-12-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 11/17] xen/x86/p2m: reject populating
 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

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:24 PM
> 
> We need to reject to populate reserved device memory mapping, and
> then make sure all reserved device memory can't be accessed by any
> !iommu approach.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/arch/x86/mm/p2m.c     | 59
> +++++++++++++++++++++++++++++++++++++++++++++--
>  xen/include/asm-x86/p2m.h |  9 ++++++++
>  2 files changed, 66 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index efa49dd..607ecd0 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -556,6 +556,40 @@ guest_physmap_remove_page(struct domain *d,
> unsigned long gfn,
>      gfn_unlock(p2m, gfn, page_order);
>  }
> 
> +/* Check if we are accessing rdm. */
> +int p2m_check_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
> +                                     u32 id, void *ctxt)
> +{
> +    xen_pfn_t end = start + nr;
> +    unsigned int i;
> +    u32 sbdf;
> +    struct p2m_get_reserved_device_memory *pgrdm = ctxt;
> +    struct domain *d = pgrdm->domain;
> +
> +    if ( d->arch.hvm_domain.pci_force )
> +    {
> +        if ( pgrdm->gfn >= start && pgrdm->gfn < end )
> +            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 ( pgrdm->gfn >= start && pgrdm->gfn < end )
> +                    return 1;
> +            }
> +        }
> +    }
> +
> +    return 0;
> +}
> +
>  int
>  guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>                          unsigned long mfn, unsigned int page_order,
> @@ -568,6 +602,7 @@ guest_physmap_add_entry(struct domain *d, unsigned
> long gfn,
>      mfn_t omfn;
>      int pod_count = 0;
>      int rc = 0;
> +    struct p2m_get_reserved_device_memory pgrdm;
> 
>      if ( !paging_mode_translate(d) )
>      {
> @@ -686,8 +721,28 @@ 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);
> +        pgrdm.gfn = gfn;
> +        pgrdm.domain = d;
> +        if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )

why is this check only for shared case?

> +        {
> +            rc =
> iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                                  &pgrdm);
> +            /* We always avoid populating reserved device memory. */
> +            if ( rc == 1 )
> +            {
> +                rc = -EBUSY;
> +                goto out;
> +            }
> +            else if ( rc < 0 )
> +            {
> +                printk(XENLOG_G_WARNING
> +                       "Can't check reserved device memory for
> Dom%d.\n",
> +                       d->domain_id);
> +                goto out;
> +            }
> +        }
> +
> +        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
> p2m->default_access);
>          if ( rc )
>              goto out; /* Failed to update p2m, bail without updating m2p.
> */
> 
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index 5f7fe71..99f7fb7 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -709,6 +709,15 @@ static inline unsigned int
> p2m_get_iommu_flags(p2m_type_t p2mt)
>      return flags;
>  }
> 
> +struct p2m_get_reserved_device_memory {
> +    unsigned long gfn;
> +    struct domain *domain;
> +};
> +
> +/* Check if we are accessing rdm. */
> +extern int p2m_check_reserved_device_memory(xen_pfn_t start,
> xen_ulong_t nr,
> +                                            u32 id, void *ctxt);
> +
>  #endif /* _XEN_P2M_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 Dec 02 09:57:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 09:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvkDB-0000fk-8t; Tue, 02 Dec 2014 09:57:37 +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 1XvkD9-0000fG-GF
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 09:57:35 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	10/16-25727-E0D8D745; Tue, 02 Dec 2014 09:57:34 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417514251!15072184!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 2187 invoked from network); 2 Dec 2014 09:57:32 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 09:57:32 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 02 Dec 2014 01:57:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,499,1413270000"; d="scan'208";a="646768658"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by orsmga002.jf.intel.com with ESMTP; 02 Dec 2014 01:57:12 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 17:57:03 +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, 2 Dec 2014 17:57:02 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 11/17] xen/x86/p2m: reject populating for reserved
	device memory mapping
Thread-Index: AQHQDUmO+4bNOv0gcEqo8U2cwIXqeZx8EegQ
Date: Tue, 2 Dec 2014 09:57:01 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610ACEB@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-12-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-12-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 11/17] xen/x86/p2m: reject populating
 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

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:24 PM
> 
> We need to reject to populate reserved device memory mapping, and
> then make sure all reserved device memory can't be accessed by any
> !iommu approach.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/arch/x86/mm/p2m.c     | 59
> +++++++++++++++++++++++++++++++++++++++++++++--
>  xen/include/asm-x86/p2m.h |  9 ++++++++
>  2 files changed, 66 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index efa49dd..607ecd0 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -556,6 +556,40 @@ guest_physmap_remove_page(struct domain *d,
> unsigned long gfn,
>      gfn_unlock(p2m, gfn, page_order);
>  }
> 
> +/* Check if we are accessing rdm. */
> +int p2m_check_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
> +                                     u32 id, void *ctxt)
> +{
> +    xen_pfn_t end = start + nr;
> +    unsigned int i;
> +    u32 sbdf;
> +    struct p2m_get_reserved_device_memory *pgrdm = ctxt;
> +    struct domain *d = pgrdm->domain;
> +
> +    if ( d->arch.hvm_domain.pci_force )
> +    {
> +        if ( pgrdm->gfn >= start && pgrdm->gfn < end )
> +            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 ( pgrdm->gfn >= start && pgrdm->gfn < end )
> +                    return 1;
> +            }
> +        }
> +    }
> +
> +    return 0;
> +}
> +
>  int
>  guest_physmap_add_entry(struct domain *d, unsigned long gfn,
>                          unsigned long mfn, unsigned int page_order,
> @@ -568,6 +602,7 @@ guest_physmap_add_entry(struct domain *d, unsigned
> long gfn,
>      mfn_t omfn;
>      int pod_count = 0;
>      int rc = 0;
> +    struct p2m_get_reserved_device_memory pgrdm;
> 
>      if ( !paging_mode_translate(d) )
>      {
> @@ -686,8 +721,28 @@ 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);
> +        pgrdm.gfn = gfn;
> +        pgrdm.domain = d;
> +        if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )

why is this check only for shared case?

> +        {
> +            rc =
> iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                                  &pgrdm);
> +            /* We always avoid populating reserved device memory. */
> +            if ( rc == 1 )
> +            {
> +                rc = -EBUSY;
> +                goto out;
> +            }
> +            else if ( rc < 0 )
> +            {
> +                printk(XENLOG_G_WARNING
> +                       "Can't check reserved device memory for
> Dom%d.\n",
> +                       d->domain_id);
> +                goto out;
> +            }
> +        }
> +
> +        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
> p2m->default_access);
>          if ( rc )
>              goto out; /* Failed to update p2m, bail without updating m2p.
> */
> 
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index 5f7fe71..99f7fb7 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -709,6 +709,15 @@ static inline unsigned int
> p2m_get_iommu_flags(p2m_type_t p2mt)
>      return flags;
>  }
> 
> +struct p2m_get_reserved_device_memory {
> +    unsigned long gfn;
> +    struct domain *domain;
> +};
> +
> +/* Check if we are accessing rdm. */
> +extern int p2m_check_reserved_device_memory(xen_pfn_t start,
> xen_ulong_t nr,
> +                                            u32 id, void *ctxt);
> +
>  #endif /* _XEN_P2M_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 Dec 02 09:59:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1XvkF5-0000rd-Vm; Tue, 02 Dec 2014 09:59:35 +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 1XvkF4-0000rW-I8
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 09:59:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	62/F9-09842-58D8D745; Tue, 02 Dec 2014 09:59:33 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417514372!12768649!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11293 invoked from network); 2 Dec 2014 09:59:32 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-4.tower-21.messagelabs.com with SMTP;
	2 Dec 2014 09:59:32 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 02 Dec 2014 01:56:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="492170507"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by orsmga003.jf.intel.com with ESMTP; 02 Dec 2014 01:56:17 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 17:59:14 +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; Tue, 2 Dec 2014 17:59:12 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 12/17] xen/x86/ept: handle reserved device memory
	in ept_handle_violation
Thread-Index: AQHQDUmSUsBROo5ydEi8iuUD13P9MJx8Eo4A
Date: Tue, 2 Dec 2014 09:59:11 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AD15@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-13-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-13-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 12/17] xen/x86/ept: handle reserved
 device memory in ept_handle_violation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Monday, December 01, 2014 5:25 PM
> 
> We always reserve these ranges since we never allow any stuff to
> poke them.
> 
> But in theory some untrusted VM can maliciously access them. So we
> need to intercept this approach. But we just don't want to leak
> anything or introduce any side affect since other OSs may touch them
> by careless behavior, so its enough to have a lightweight way, and
> it shouldn't be same as those broken pages which cause domain crush.
> 
> So we just need to return with next eip then let VM/OS itself handle
> such a scenario as its own logic.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/arch/x86/hvm/vmx/vmx.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 2907afa..3ee884a 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2403,6 +2403,7 @@ static void ept_handle_violation(unsigned long
> qualification, paddr_t gpa)
>      p2m_type_t p2mt;
>      int ret;
>      struct domain *d = current->domain;
> +    struct p2m_get_reserved_device_memory pgrdm;
> 
>      /*
>       * We treat all write violations also as read violations.
> @@ -2438,6 +2439,23 @@ static void ept_handle_violation(unsigned long
> qualification, paddr_t gpa)
>          __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
>      }
> 
> +    /* This means some untrusted VM can maliciously access reserved
> +     * device memory. But we just don't want to leak anything or
> +     * introduce any side affect since other OSs may touch them by
> +     * careless behavior, so its enough to have a lightweight way.
> +     * Here we just need to return with next eip then let VM/OS itself
> +     * handle such a scenario as its own logic.
> +     */
> +    pgrdm.gfn = gfn;
> +    pgrdm.domain = d;
> +    ret =
> iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                           &pgrdm);

can this be optimized to not walk rmrr map if no device is assigned?

> +    if ( ret )
> +    {
> +        update_guest_eip();
> +        return;
> +    }
> +
>      if ( qualification & EPT_GLA_VALID )
>      {
>          __vmread(GUEST_LINEAR_ADDRESS, &gla);
> --
> 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 Dec 02 09:59:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1XvkF5-0000rd-Vm; Tue, 02 Dec 2014 09:59:35 +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 1XvkF4-0000rW-I8
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 09:59:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	62/F9-09842-58D8D745; Tue, 02 Dec 2014 09:59:33 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417514372!12768649!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11293 invoked from network); 2 Dec 2014 09:59:32 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-4.tower-21.messagelabs.com with SMTP;
	2 Dec 2014 09:59:32 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 02 Dec 2014 01:56:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="492170507"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by orsmga003.jf.intel.com with ESMTP; 02 Dec 2014 01:56:17 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 17:59:14 +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; Tue, 2 Dec 2014 17:59:12 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 12/17] xen/x86/ept: handle reserved device memory
	in ept_handle_violation
Thread-Index: AQHQDUmSUsBROo5ydEi8iuUD13P9MJx8Eo4A
Date: Tue, 2 Dec 2014 09:59:11 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AD15@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-13-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-13-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 12/17] xen/x86/ept: handle reserved
 device memory in ept_handle_violation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Monday, December 01, 2014 5:25 PM
> 
> We always reserve these ranges since we never allow any stuff to
> poke them.
> 
> But in theory some untrusted VM can maliciously access them. So we
> need to intercept this approach. But we just don't want to leak
> anything or introduce any side affect since other OSs may touch them
> by careless behavior, so its enough to have a lightweight way, and
> it shouldn't be same as those broken pages which cause domain crush.
> 
> So we just need to return with next eip then let VM/OS itself handle
> such a scenario as its own logic.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/arch/x86/hvm/vmx/vmx.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 2907afa..3ee884a 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2403,6 +2403,7 @@ static void ept_handle_violation(unsigned long
> qualification, paddr_t gpa)
>      p2m_type_t p2mt;
>      int ret;
>      struct domain *d = current->domain;
> +    struct p2m_get_reserved_device_memory pgrdm;
> 
>      /*
>       * We treat all write violations also as read violations.
> @@ -2438,6 +2439,23 @@ static void ept_handle_violation(unsigned long
> qualification, paddr_t gpa)
>          __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
>      }
> 
> +    /* This means some untrusted VM can maliciously access reserved
> +     * device memory. But we just don't want to leak anything or
> +     * introduce any side affect since other OSs may touch them by
> +     * careless behavior, so its enough to have a lightweight way.
> +     * Here we just need to return with next eip then let VM/OS itself
> +     * handle such a scenario as its own logic.
> +     */
> +    pgrdm.gfn = gfn;
> +    pgrdm.domain = d;
> +    ret =
> iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                           &pgrdm);

can this be optimized to not walk rmrr map if no device is assigned?

> +    if ( ret )
> +    {
> +        update_guest_eip();
> +        return;
> +    }
> +
>      if ( qualification & EPT_GLA_VALID )
>      {
>          __vmread(GUEST_LINEAR_ADDRESS, &gla);
> --
> 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 Dec 02 10:01:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkGU-00013h-FL; Tue, 02 Dec 2014 10:01:02 +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 1XvkGS-00013S-PI
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:01:00 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	ED/F4-26858-BDD8D745; Tue, 02 Dec 2014 10:00:59 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417514456!15122215!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 824 invoked from network); 2 Dec 2014 10:00:57 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 10:00:57 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga101.jf.intel.com with ESMTP; 02 Dec 2014 02:00:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="492171195"
Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103])
	by orsmga003.jf.intel.com with ESMTP; 02 Dec 2014 01:57:41 -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; Tue, 2 Dec 2014 18:00:51 +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; Tue, 2 Dec 2014 18:00:50 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 14/17] xen/x86/p2m: introduce set_identity_p2m_entry
Thread-Index: AQHQDUmXFZkwSMj7UUidIPNkMo7225x8Ew6Q
Date: Tue, 2 Dec 2014 10:00:49 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AD32@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-15-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-15-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 14/17] xen/x86/p2m: introduce
	set_identity_p2m_entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:25 PM
> 
> We will create RMRR mapping as follows:
> 
> If gfn space unoccupied, we just set that. If
> space already occupy by 1:1 RMRR mapping do thing. Others
> should be failed.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

> ---
>  xen/arch/x86/mm/p2m.c     | 28 ++++++++++++++++++++++++++++
>  xen/include/asm-x86/p2m.h |  4 ++++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 607ecd0..c415521 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -913,6 +913,34 @@ int set_mmio_p2m_entry(struct domain *d, unsigned
> long gfn, mfn_t mfn)
>      return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct);
>  }
> 
> +int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
> +                           p2m_access_t p2ma)
> +{
> +    p2m_type_t p2mt;
> +    p2m_access_t a;
> +    mfn_t mfn;
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int ret = -EBUSY;
> +
> +    gfn_lock(p2m, gfn, 0);
> +
> +    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
> +
> +    if ( !mfn_valid(mfn) )
> +        ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
> p2m_mmio_direct,
> +                            p2ma);
> +    else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a ==
> p2ma )
> +        ret = 0;
> +    else
> +        printk(XENLOG_G_WARNING
> +               "Cannot identity map d%d:%lx, already mapped to %lx.\n",
> +               d->domain_id, gfn, mfn_x(mfn));
> +
> +    gfn_unlock(p2m, gfn, 0);
> +
> +    return ret;
> +}
> +
>  /* Returns: 0 for success, -errno for failure */
>  int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
>  {
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index 99f7fb7..26cf0cc 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -509,6 +509,10 @@ int p2m_is_logdirty_range(struct p2m_domain *,
> unsigned long start,
>  int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
>  int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
> 
> +/* Set identity addresses in the p2m table (for pass-through) */
> +int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
> +                           p2m_access_t p2ma);
> +
>  /* Add foreign mapping to the guest's p2m table. */
>  int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
>                      unsigned long gpfn, domid_t foreign_domid);
> --
> 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 Dec 02 10:01:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkGU-00013h-FL; Tue, 02 Dec 2014 10:01:02 +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 1XvkGS-00013S-PI
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:01:00 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	ED/F4-26858-BDD8D745; Tue, 02 Dec 2014 10:00:59 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417514456!15122215!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 824 invoked from network); 2 Dec 2014 10:00:57 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 10:00:57 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga101.jf.intel.com with ESMTP; 02 Dec 2014 02:00:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="492171195"
Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103])
	by orsmga003.jf.intel.com with ESMTP; 02 Dec 2014 01:57:41 -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; Tue, 2 Dec 2014 18:00:51 +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; Tue, 2 Dec 2014 18:00:50 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 14/17] xen/x86/p2m: introduce set_identity_p2m_entry
Thread-Index: AQHQDUmXFZkwSMj7UUidIPNkMo7225x8Ew6Q
Date: Tue, 2 Dec 2014 10:00:49 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AD32@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-15-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-15-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 14/17] xen/x86/p2m: introduce
	set_identity_p2m_entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:25 PM
> 
> We will create RMRR mapping as follows:
> 
> If gfn space unoccupied, we just set that. If
> space already occupy by 1:1 RMRR mapping do thing. Others
> should be failed.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

> ---
>  xen/arch/x86/mm/p2m.c     | 28 ++++++++++++++++++++++++++++
>  xen/include/asm-x86/p2m.h |  4 ++++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 607ecd0..c415521 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -913,6 +913,34 @@ int set_mmio_p2m_entry(struct domain *d, unsigned
> long gfn, mfn_t mfn)
>      return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct);
>  }
> 
> +int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
> +                           p2m_access_t p2ma)
> +{
> +    p2m_type_t p2mt;
> +    p2m_access_t a;
> +    mfn_t mfn;
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int ret = -EBUSY;
> +
> +    gfn_lock(p2m, gfn, 0);
> +
> +    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
> +
> +    if ( !mfn_valid(mfn) )
> +        ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
> p2m_mmio_direct,
> +                            p2ma);
> +    else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a ==
> p2ma )
> +        ret = 0;
> +    else
> +        printk(XENLOG_G_WARNING
> +               "Cannot identity map d%d:%lx, already mapped to %lx.\n",
> +               d->domain_id, gfn, mfn_x(mfn));
> +
> +    gfn_unlock(p2m, gfn, 0);
> +
> +    return ret;
> +}
> +
>  /* Returns: 0 for success, -errno for failure */
>  int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
>  {
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index 99f7fb7..26cf0cc 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -509,6 +509,10 @@ int p2m_is_logdirty_range(struct p2m_domain *,
> unsigned long start,
>  int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
>  int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
> 
> +/* Set identity addresses in the p2m table (for pass-through) */
> +int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
> +                           p2m_access_t p2ma);
> +
>  /* Add foreign mapping to the guest's p2m table. */
>  int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
>                      unsigned long gpfn, domid_t foreign_domid);
> --
> 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 Dec 02 10:04:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkJd-0001Jh-2b; Tue, 02 Dec 2014 10:04: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 1XvkJb-0001Jc-BR
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:04:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EA/46-09842-E9E8D745; Tue, 02 Dec 2014 10:04:14 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417514653!12808077!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3114 invoked from network); 2 Dec 2014 10:04:14 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-21.messagelabs.com with SMTP;
	2 Dec 2014 10:04:14 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 02 Dec 2014 02:04:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="423955947"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by FMSMGA003.fm.intel.com with ESMTP; 02 Dec 2014 01:53:59 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 18:02:03 +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, 2 Dec 2014 18:02:02 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 15/17] xen:vtd: create RMRR mapping
Thread-Index: AQHQDUmZXL8m9ChsFU616GrSYfoQvJx8E2XQ
Date: Tue, 2 Dec 2014 10:02:01 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AD6F@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-16-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-16-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 15/17] xen:vtd: create RMRR 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

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:25 PM
> 
> intel_iommu_map_page() does nothing if VT-d shares EPT page table.
> So rmrr_identity_mapping() never create RMRR mapping but in some
> cases like some GFX drivers it still need to access RMRR.
> 
> Here we will create those RMRR mappings even in shared EPT case.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>

Acked-by: Kevin Tian <kevin.tian@intel.com>

> ---
>  xen/drivers/passthrough/vtd/iommu.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index a38f201..a54c6eb 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1856,10 +1856,15 @@ static int rmrr_identity_mapping(struct domain
> *d, bool_t map,
> 
>      while ( base_pfn < end_pfn )
>      {
> -        int err = intel_iommu_map_page(d, base_pfn, base_pfn,
> -
> IOMMUF_readable|IOMMUF_writable);
> -
> -        if ( err )
> +        int err = 0;
> +        if ( iommu_use_hap_pt(d) )
> +        {
> +            ASSERT(!iommu_passthrough || !is_hardware_domain(d));
> +            if ( (err = set_identity_p2m_entry(d, base_pfn,
> p2m_access_rw)) )
> +                return err;
> +        }
> +        else if ( (err = intel_iommu_map_page(d, base_pfn, base_pfn,
> +					      IOMMUF_readable|IOMMUF_writable)) )
>              return err;
>          base_pfn++;
>      }
> --
> 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 Dec 02 10:04:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkJd-0001Jh-2b; Tue, 02 Dec 2014 10:04: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 1XvkJb-0001Jc-BR
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:04:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EA/46-09842-E9E8D745; Tue, 02 Dec 2014 10:04:14 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417514653!12808077!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3114 invoked from network); 2 Dec 2014 10:04:14 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-21.messagelabs.com with SMTP;
	2 Dec 2014 10:04:14 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 02 Dec 2014 02:04:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="423955947"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by FMSMGA003.fm.intel.com with ESMTP; 02 Dec 2014 01:53:59 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 2 Dec 2014 18:02:03 +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, 2 Dec 2014 18:02:02 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 15/17] xen:vtd: create RMRR mapping
Thread-Index: AQHQDUmZXL8m9ChsFU616GrSYfoQvJx8E2XQ
Date: Tue, 2 Dec 2014 10:02:01 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610AD6F@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-16-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-16-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 15/17] xen:vtd: create RMRR 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

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:25 PM
> 
> intel_iommu_map_page() does nothing if VT-d shares EPT page table.
> So rmrr_identity_mapping() never create RMRR mapping but in some
> cases like some GFX drivers it still need to access RMRR.
> 
> Here we will create those RMRR mappings even in shared EPT case.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>

Acked-by: Kevin Tian <kevin.tian@intel.com>

> ---
>  xen/drivers/passthrough/vtd/iommu.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index a38f201..a54c6eb 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1856,10 +1856,15 @@ static int rmrr_identity_mapping(struct domain
> *d, bool_t map,
> 
>      while ( base_pfn < end_pfn )
>      {
> -        int err = intel_iommu_map_page(d, base_pfn, base_pfn,
> -
> IOMMUF_readable|IOMMUF_writable);
> -
> -        if ( err )
> +        int err = 0;
> +        if ( iommu_use_hap_pt(d) )
> +        {
> +            ASSERT(!iommu_passthrough || !is_hardware_domain(d));
> +            if ( (err = set_identity_p2m_entry(d, base_pfn,
> p2m_access_rw)) )
> +                return err;
> +        }
> +        else if ( (err = intel_iommu_map_page(d, base_pfn, base_pfn,
> +					      IOMMUF_readable|IOMMUF_writable)) )
>              return err;
>          base_pfn++;
>      }
> --
> 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 Dec 02 10:07:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkMT-0001RD-LK; Tue, 02 Dec 2014 10:07:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1XvkMR-0001Qv-RL
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:07:12 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	46/EC-09842-F4F8D745; Tue, 02 Dec 2014 10:07:11 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417514828!12809031!1
X-Originating-IP: [207.171.178.25]
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 30093 invoked from network); 2 Dec 2014 10:07:09 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 10:07:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417514829; x=1449050829;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version;
	bh=wGCZXeKIoqGPBXGer+Y2SIjNP2zV2zqWKF7Bm5/+UFY=;
	b=IEz/Jjhx/y0RNGTNxK5/qr02OMdI1hrxWm19TB00/Ge38Lnhf+whpIPE
	JiLKSYjv8+ITRM/7CCbj2a1lAw6gDd2P9Ceh67SsbypRBWFP0XTu1BuQE
	13G9GFZm8OxChfLPtJKP45KRa+1N7LUaVhASkQeu4BTJzr3tbpZNavIp2 A=;
X-IronPort-AV: E=Sophos;i="5.07,499,1413244800"; d="scan'208";a="174736709"
Received: from email-inbound-relay-6002.iad6.amazon.com ([10.219.219.179])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 10:07:06 +0000
Received: from ex10-hub-7002.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com
	[10.0.103.146])
	by email-inbound-relay-6002.iad6.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB2A72AV024508
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 10:07:05 GMT
Received: from EX13D05UWC001.ant.amazon.com (10.43.162.82) by
	ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 02:07:03 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.162.149) by
	EX13D05UWC001.ant.amazon.com (10.43.162.82) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 10:07:00 +0000
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 11:06:23 +0100
Message-ID: <1417514784-15749-2-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1417514784-15749-1-git-send-email-chegger@amazon.de>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
MIME-Version: 1.0
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D05UWC001.ant.amazon.com (10.43.162.82) To
	EX13D05UWC001.ant.amazon.com (10.43.162.82)
Precedence: Bulk
Cc: Christoph Egger <chegger@amazon.de>, Keir Fraser <keir@xen.org>, Jan
	Beulich <jbeulich@suse.com>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 1/2] gnttab: Introduce rwlock to protect updates
	to grant table state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 lock to maptrack_lock and use it to protect maptrack state.

The new rwlock is used to prevent readers from accessing
inconsistent grant table state such as current
version, partially initialized active table pages,
etc.

Signed-off-by: Matt Wilson <msw@amazon.com>
[chegger: ported to xen-staging, split into multiple commits]
Signed-off-by: Christoph Egger <chegger@amazon.de>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
---
 docs/misc/grant-tables.txt    |   28 ++++++++-
 xen/arch/x86/mm.c             |    4 +-
 xen/common/grant_table.c      |  135 ++++++++++++++++++++++++-----------------
 xen/include/xen/grant_table.h |    9 ++-
 4 files changed, 115 insertions(+), 61 deletions(-)

diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt
index 19db4ec..c9ae8f2 100644
--- a/docs/misc/grant-tables.txt
+++ b/docs/misc/grant-tables.txt
@@ -74,7 +74,33 @@ is complete.
  matching map track entry is then removed, as if unmap had been invoked.
  These are not used by the transfer mechanism.
   map->domid         : owner of the mapped frame
-  map->ref_and_flags : grant reference, ro/rw, mapped for host or device access
+  map->ref           : grant reference
+  map->flags         : ro/rw, mapped for host or device access
+
+********************************************************************************
+ Locking
+ ~~~~~~~
+ Xen uses several locks to serialize access to the internal grant table state.
+
+  grant_table->lock          : rwlock used to prevent readers from accessing
+                               inconsistent grant table state such as current
+                               version, partially initialized active table pages,
+                               etc.
+  grant_table->maptrack_lock : spinlock used to protect the maptrack state
+
+ The primary lock for the grant table is a read/write spinlock. All
+ functions that access members of struct grant_table must acquire a
+ read lock around critical sections. Any modification to the members
+ of struct grant_table (e.g., nr_status_frames, nr_grant_frames,
+ active frames, etc.) must only be made if the write lock is
+ held. These elements are read-mostly, and read critical sections can
+ be large, which makes a rwlock a good choice.
+
+ The maptrack state is protected by its own spinlock. Any access (read
+ or write) of struct grant_table members that have a "maptrack_"
+ prefix must be made while holding the maptrack lock. The maptrack
+ state can be rapidly modified under some workloads, and the critical
+ sections are very small, thus we use a spinlock to protect them.
 
 ********************************************************************************
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 522c43d..37c13b1 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
                 mfn = virt_to_mfn(d->shared_info);
             break;
         case XENMAPSPACE_grant_table:
-            spin_lock(&d->grant_table->lock);
+            write_lock(&d->grant_table->lock);
 
             if ( d->grant_table->gt_version == 0 )
                 d->grant_table->gt_version = 1;
@@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
                     mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
             }
 
-            spin_unlock(&d->grant_table->lock);
+            write_unlock(&d->grant_table->lock);
             break;
         case XENMAPSPACE_gmfn_range:
         case XENMAPSPACE_gmfn:
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 8fba923..018b5b6 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -227,23 +227,23 @@ double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
 {
     if ( lgt < rgt )
     {
-        spin_lock(&lgt->lock);
-        spin_lock(&rgt->lock);
+        spin_lock(&lgt->maptrack_lock);
+        spin_lock(&rgt->maptrack_lock);
     }
     else
     {
         if ( lgt != rgt )
-            spin_lock(&rgt->lock);
-        spin_lock(&lgt->lock);
+            spin_lock(&rgt->maptrack_lock);
+        spin_lock(&lgt->maptrack_lock);
     }
 }
 
 static inline void
 double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
 {
-    spin_unlock(&lgt->lock);
+    spin_unlock(&lgt->maptrack_lock);
     if ( lgt != rgt )
-        spin_unlock(&rgt->lock);
+        spin_unlock(&rgt->maptrack_lock);
 }
 
 static inline int
@@ -261,10 +261,10 @@ static inline void
 put_maptrack_handle(
     struct grant_table *t, int handle)
 {
-    spin_lock(&t->lock);
+    spin_lock(&t->maptrack_lock);
     maptrack_entry(t, handle).ref = t->maptrack_head;
     t->maptrack_head = handle;
-    spin_unlock(&t->lock);
+    spin_unlock(&t->maptrack_lock);
 }
 
 static inline int
@@ -276,7 +276,7 @@ get_maptrack_handle(
     struct grant_mapping *new_mt;
     unsigned int          new_mt_limit, nr_frames;
 
-    spin_lock(&lgt->lock);
+    spin_lock(&lgt->maptrack_lock);
 
     while ( unlikely((handle = __get_maptrack_handle(lgt)) == -1) )
     {
@@ -305,7 +305,7 @@ get_maptrack_handle(
                  nr_frames + 1);
     }
 
-    spin_unlock(&lgt->lock);
+    spin_unlock(&lgt->maptrack_lock);
 
     return handle;
 }
@@ -502,7 +502,7 @@ static int grant_map_exists(const struct domain *ld,
     const struct active_grant_entry *act;
     unsigned int ref, max_iter;
     
-    ASSERT(spin_is_locked(&rgt->lock));
+    ASSERT(rw_is_locked(&rgt->lock));
 
     max_iter = min(*ref_count + (1 << GNTTABOP_CONTINUATION_ARG_SHIFT),
                    nr_grant_entries(rgt));
@@ -623,7 +623,7 @@ __gnttab_map_grant_ref(
     }
 
     rgt = rd->grant_table;
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
         PIN_FAIL(unlock_out, GNTST_general_error,
@@ -696,7 +696,7 @@ __gnttab_map_grant_ref(
 
     cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
 
     /* pg may be set, with a refcount included, from __get_paged_frame */
     if ( !pg )
@@ -831,7 +831,7 @@ __gnttab_map_grant_ref(
         put_page(pg);
     }
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     act = &active_entry(rgt, op->ref);
 
@@ -851,7 +851,7 @@ __gnttab_map_grant_ref(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     op->status = rc;
     put_maptrack_handle(lgt, handle);
     rcu_unlock_domain(rd);
@@ -891,28 +891,28 @@ __gnttab_unmap_common(
     ld = current->domain;
     lgt = ld->grant_table;
 
+    read_lock(&lgt->lock);
     op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
 
     if ( unlikely(op->handle >= lgt->maptrack_limit) )
     {
+        read_unlock(&lgt->lock);
         gdprintk(XENLOG_INFO, "Bad handle (%d).\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
+    read_unlock(&lgt->lock);
     op->map = &maptrack_entry(lgt, op->handle);
-    spin_lock(&lgt->lock);
 
     if ( unlikely(!op->map->flags) )
     {
-        spin_unlock(&lgt->lock);
         gdprintk(XENLOG_INFO, "Zero flags for handle (%d).\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
     dom = op->map->domid;
-    spin_unlock(&lgt->lock);
 
     if ( unlikely((rd = rcu_lock_domain_by_id(dom)) == NULL) )
     {
@@ -944,6 +944,7 @@ __gnttab_unmap_common(
     }
 
     op->rd = rd;
+    read_lock(&rgt->lock);
     act = &active_entry(rgt, op->map->ref);
 
     if ( op->frame == 0 )
@@ -1004,6 +1005,7 @@ __gnttab_unmap_common(
 
  unmap_out:
     double_gt_unlock(lgt, rgt);
+    read_unlock(&rgt->lock);
     op->status = rc;
     rcu_unlock_domain(rd);
 }
@@ -1033,8 +1035,8 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
 
     rcu_lock_domain(rd);
     rgt = rd->grant_table;
-    spin_lock(&rgt->lock);
 
+    read_lock(&rgt->lock);
     if ( rgt->gt_version == 0 )
         goto unmap_out;
 
@@ -1098,7 +1100,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
         gnttab_clear_flag(_GTF_reading, status);
 
  unmap_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     if ( put_handle )
     {
         op->map->flags = 0;
@@ -1284,10 +1286,13 @@ gnttab_unpopulate_status_frames(struct domain *d, struct grant_table *gt)
     gt->nr_status_frames = 0;
 }
 
+/* Grow the grant table. The caller must hold the grant table's
+ * write lock before calling this function.
+ */
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
 {
-    /* d's grant table lock must be held by the caller */
+    /* d's grant table write lock must be held by the caller */
 
     struct grant_table *gt = d->grant_table;
     unsigned int i;
@@ -1392,7 +1397,7 @@ gnttab_setup_table(
     }
 
     gt = d->grant_table;
-    spin_lock(&gt->lock);
+    write_lock(&gt->lock);
 
     if ( gt->gt_version == 0 )
         gt->gt_version = 1;
@@ -1420,7 +1425,7 @@ gnttab_setup_table(
     }
 
  out3:
-    spin_unlock(&gt->lock);
+    write_unlock(&gt->lock);
  out2:
     rcu_unlock_domain(d);
  out1:
@@ -1462,13 +1467,13 @@ gnttab_query_size(
         goto query_out_unlock;
     }
 
-    spin_lock(&d->grant_table->lock);
+    read_lock(&d->grant_table->lock);
 
     op.nr_frames     = nr_grant_frames(d->grant_table);
     op.max_nr_frames = max_grant_frames;
     op.status        = GNTST_okay;
 
-    spin_unlock(&d->grant_table->lock);
+    read_unlock(&d->grant_table->lock);
 
  
  query_out_unlock:
@@ -1494,7 +1499,7 @@ gnttab_prepare_for_transfer(
     union grant_combo   scombo, prev_scombo, new_scombo;
     int                 retries = 0;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
     {
@@ -1545,11 +1550,11 @@ gnttab_prepare_for_transfer(
         scombo = prev_scombo;
     }
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return 1;
 
  fail:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return 0;
 }
 
@@ -1741,7 +1746,7 @@ gnttab_transfer(
         TRACE_1D(TRC_MEM_PAGE_GRANT_TRANSFER, e->domain_id);
 
         /* Tell the guest about its new page frame. */
-        spin_lock(&e->grant_table->lock);
+        read_lock(&e->grant_table->lock);
 
         if ( e->grant_table->gt_version == 1 )
         {
@@ -1759,7 +1764,7 @@ gnttab_transfer(
         shared_entry_header(e->grant_table, gop.ref)->flags |=
             GTF_transfer_completed;
 
-        spin_unlock(&e->grant_table->lock);
+        read_unlock(&e->grant_table->lock);
 
         rcu_unlock_domain(e);
 
@@ -1797,7 +1802,7 @@ __release_grant_for_copy(
     released_read = 0;
     released_write = 0;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     act = &active_entry(rgt, gref);
     sha = shared_entry_header(rgt, gref);
@@ -1838,7 +1843,7 @@ __release_grant_for_copy(
         released_read = 1;
     }
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
 
     if ( td != rd )
     {
@@ -1896,7 +1901,7 @@ __acquire_grant_for_copy(
 
     *page = NULL;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
         PIN_FAIL(unlock_out, GNTST_general_error,
@@ -1965,17 +1970,21 @@ __acquire_grant_for_copy(
                 PIN_FAIL(unlock_out_clear, GNTST_general_error,
                          "transitive grant referenced bad domain %d\n",
                          trans_domid);
-            spin_unlock(&rgt->lock);
+
+            /* __acquire_grant_for_copy() could take the read lock on
+             * the right table (if rd == td), so we have to drop the
+             * lock here and reacquire */
+            read_unlock(&rgt->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd->domain_id,
                                           readonly, &grant_frame, page,
                                           &trans_page_off, &trans_length, 0);
 
-            spin_lock(&rgt->lock);
+            read_lock(&rgt->lock);
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_copy_pin(act, status);
+                read_unlock(&rgt->lock);
                 rcu_unlock_domain(td);
-                spin_unlock(&rgt->lock);
                 return rc;
             }
 
@@ -1987,7 +1996,7 @@ __acquire_grant_for_copy(
             {
                 __fixup_status_for_copy_pin(act, status);
                 rcu_unlock_domain(td);
-                spin_unlock(&rgt->lock);
+                read_unlock(&rgt->lock);
                 put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ldom, readonly,
                                                 frame, page, page_off, length,
@@ -2055,7 +2064,7 @@ __acquire_grant_for_copy(
     *length = act->length;
     *frame = act->frame;
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return rc;
  
  unlock_out_clear:
@@ -2067,7 +2076,7 @@ __acquire_grant_for_copy(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return rc;
 }
 
@@ -2241,7 +2250,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     if ( gt->gt_version == op.version )
         goto out;
 
-    spin_lock(&gt->lock);
+    write_lock(&gt->lock);
     /* Make sure that the grant table isn't currently in use when we
        change the version number, except for the first 8 entries which
        are allowed to be in use (xenstore/xenconsole keeps them mapped).
@@ -2327,7 +2336,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     gt->gt_version = op.version;
 
 out_unlock:
-    spin_unlock(&gt->lock);
+    write_unlock(&gt->lock);
 
 out:
     op.version = gt->gt_version;
@@ -2383,7 +2392,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
 
     op.status = GNTST_okay;
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     for ( i = 0; i < op.nr_frames; i++ )
     {
@@ -2392,7 +2401,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
             op.status = GNTST_bad_virt_addr;
     }
 
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 out2:
     rcu_unlock_domain(d);
 out1:
@@ -2441,7 +2450,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     struct active_grant_entry *act;
     s16 rc = GNTST_okay;
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     /* Bounds check on the grant refs */
     if ( unlikely(ref_a >= nr_grant_entries(d->grant_table)))
@@ -2481,7 +2490,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     }
 
 out:
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 
     rcu_unlock_domain(d);
 
@@ -2501,8 +2510,19 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) uop,
             return i;
         if ( unlikely(__copy_from_guest(&op, uop, 1)) )
             return -EFAULT;
-        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
-        if ( unlikely(__copy_field_to_guest(uop, &op, status)) )
+        if ( unlikely(op.ref_a == op.ref_b) )
+        {
+            /* noop, so avoid acquiring the same active entry
+             * twice in __gnttab_swap_grant_ref(), which would
+             * case a deadlock.
+             */
+            op.status = GNTST_okay;
+        }
+        else
+        {
+            op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
+        }
+        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
             return -EFAULT;
         guest_handle_add_offset(uop, 1);
     }
@@ -2552,12 +2572,12 @@ static int __gnttab_cache_flush(gnttab_cache_flush_t *cflush,
 
     if ( d != owner )
     {
-        spin_lock(&owner->grant_table->lock);
+        read_lock(&owner->grant_table->lock);
 
         ret = grant_map_exists(d, owner->grant_table, mfn, ref_count);
         if ( ret != 0 )
         {
-            spin_unlock(&owner->grant_table->lock);
+            read_unlock(&owner->grant_table->lock);
             rcu_unlock_domain(d);
             put_page(page);
             return ret;
@@ -2577,7 +2597,7 @@ static int __gnttab_cache_flush(gnttab_cache_flush_t *cflush,
         ret = 0;
 
     if ( d != owner )
-        spin_unlock(&owner->grant_table->lock);
+        read_unlock(&owner->grant_table->lock);
     unmap_domain_page(v);
     put_page(page);
 
@@ -2793,7 +2813,8 @@ grant_table_create(
         goto no_mem_0;
 
     /* Simple stuff. */
-    spin_lock_init(&t->lock);
+    rwlock_init(&t->lock);
+    spin_lock_init(&t->maptrack_lock);
     t->nr_grant_frames = INITIAL_NR_GRANT_FRAMES;
 
     /* Active grant table. */
@@ -2900,7 +2921,7 @@ gnttab_release_mappings(
         }
 
         rgt = rd->grant_table;
-        spin_lock(&rgt->lock);
+        read_lock(&rgt->lock);
 
         act = &active_entry(rgt, ref);
         sha = shared_entry_header(rgt, ref);
@@ -2960,7 +2981,7 @@ gnttab_release_mappings(
         if ( act->pin == 0 )
             gnttab_clear_flag(_GTF_reading, status);
 
-        spin_unlock(&rgt->lock);
+        read_unlock(&rgt->lock);
 
         rcu_unlock_domain(rd);
 
@@ -2978,6 +2999,8 @@ grant_table_destroy(
 
     if ( t == NULL )
         return;
+
+    write_lock(&t->lock);
     
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
@@ -2995,6 +3018,8 @@ grant_table_destroy(
         free_xenheap_page(t->status[i]);
     xfree(t->status);
 
+    write_unlock(&t->lock);
+
     xfree(t);
     d->grant_table = NULL;
 }
@@ -3008,7 +3033,7 @@ static void gnttab_usage_print(struct domain *rd)
     printk("      -------- active --------       -------- shared --------\n");
     printk("[ref] localdom mfn      pin          localdom gmfn     flags\n");
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     if ( gt->gt_version == 0 )
         goto out;
@@ -3057,7 +3082,7 @@ static void gnttab_usage_print(struct domain *rd)
     }
 
  out:
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 
     if ( first )
         printk("grant-table for remote domain:%5d ... "
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 32f5786..ca49b41 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -82,8 +82,11 @@ struct grant_table {
     struct grant_mapping **maptrack;
     unsigned int          maptrack_head;
     unsigned int          maptrack_limit;
-    /* Lock protecting updates to active and shared grant tables. */
-    spinlock_t            lock;
+    /* Lock protecting the maptrack page list, head, and limit */
+    spinlock_t            maptrack_lock;
+    /* Lock protecting updates to grant table state (version, active
+       entry list, etc.) */
+    rwlock_t              lock;
     /* The defined versions are 1 and 2.  Set to 0 if we don't know
        what version to use yet. */
     unsigned              gt_version;
@@ -101,7 +104,7 @@ gnttab_release_mappings(
     struct domain *d);
 
 /* Increase the size of a domain's grant table.
- * Caller must hold d's grant table lock.
+ * Caller must hold d's grant table write lock.
  */
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames);
-- 
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 Dec 02 10:07:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkMU-0001Rb-FB; Tue, 02 Dec 2014 10:07:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1XvkMS-0001R2-Sr
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:07:13 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	9E/12-25727-05F8D745; Tue, 02 Dec 2014 10:07:12 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417514824!12760806!2
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjA0MDI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2010 invoked from network); 2 Dec 2014 10:07:10 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 10:07:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417514830; x=1449050830;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version;
	bh=OPPNBVnxn51UV2JAt+1lM+8iAvUNqls00ItrjauEYmE=;
	b=o3h8e8uwgaXC3ndV5QJuLS/4TMx9VTYMNXXuvcoGGw5O1GciNkb6zkcR
	jqplwPkjkINVEFLwM5DVpbDoS8+CwVcFU5wgTHZK4F9wb1D54CvvJoYNP
	TQ1o0fRPEn9paJ9j+BDQ59fl6wrJkXTTVHT0kWM7AHkSZ2ZZkiNOn+9Zi w=;
X-IronPort-AV: E=Sophos;i="5.07,499,1413244800"; d="scan'208";a="150586403"
Received: from email-inbound-relay-25002.iad12.amazon.com ([10.205.29.134])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 10:07:09 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com
	[10.0.103.150])
	by email-inbound-relay-25002.iad12.amazon.com (8.14.7/8.14.7) with
	ESMTP id sB2A76I4008556
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 10:07:07 GMT
Received: from EX13D05UWC001.ant.amazon.com (10.43.162.82) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 02:07:05 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.162.149) by
	EX13D05UWC001.ant.amazon.com (10.43.162.82) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 10:07:03 +0000
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 11:06:24 +0100
Message-ID: <1417514784-15749-3-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1417514784-15749-1-git-send-email-chegger@amazon.de>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
MIME-Version: 1.0
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D05UWC001.ant.amazon.com (10.43.162.82) To
	EX13D05UWC001.ant.amazon.com (10.43.162.82)
Precedence: Bulk
Cc: Jan Beulich <jbeulich@suse.com>, Christoph Egger <chegger@amazon.de>,
	Keir Fraser <keir@xen.org>, Anthony Liguori <aliguori@amazon.com>,
	Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 2/2] gnttab: refactor locking for scalability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Matt Wilson <msw@amazon.com>

This patch refactors grant table locking. It splits the previous
single spinlock per grant table into multiple locks. The heavily
modified components of the grant table (the maptrack state and the
active entries) are now protected by their own spinlocks. The
remaining elements of the grant table are read-mostly, so the main
grant table lock is modified to be a rwlock to improve concurrency.

Workloads with high grant table operation rates, especially map/unmap
operations as used by blkback/blkfront when persistent grants are not
supported, show marked improvement with these changes. A domU with 24
VBDs in a streaming 2M write workload achieved 1,400 MB/sec before
this change. Performance more than doubles with this patch, reaching
3,000 MB/sec before tuning and 3,600 MB/sec after adjusting event
channel vCPU bindings.

Signed-off-by: Matt Wilson <msw@amazon.com>
[chegger: ported to xen-staging, split into multiple commits]
Signed-off-by: Christoph Egger <chegger@amazon.de>
Cc: Anthony Liguori <aliguori@amazon.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
---
 docs/misc/grant-tables.txt |   21 +++++
 xen/common/grant_table.c   |  213 ++++++++++++++++++++++++++++----------------
 2 files changed, 157 insertions(+), 77 deletions(-)

diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt
index c9ae8f2..1ada018 100644
--- a/docs/misc/grant-tables.txt
+++ b/docs/misc/grant-tables.txt
@@ -63,6 +63,7 @@ is complete.
   act->domid : remote domain being granted rights
   act->frame : machine frame being granted
   act->pin   : used to hold reference counts
+  act->lock  : spinlock used to serialize access to active entry state
 
  Map tracking
  ~~~~~~~~~~~~
@@ -87,6 +88,8 @@ is complete.
                                version, partially initialized active table pages,
                                etc.
   grant_table->maptrack_lock : spinlock used to protect the maptrack state
+  active_grant_entry->lock   : spinlock used to serialize modifications to
+                               active entries
 
  The primary lock for the grant table is a read/write spinlock. All
  functions that access members of struct grant_table must acquire a
@@ -102,6 +105,24 @@ is complete.
  state can be rapidly modified under some workloads, and the critical
  sections are very small, thus we use a spinlock to protect them.
 
+ Active entries are obtained by calling active_entry_acquire(gt, ref).
+ This function returns a pointer to the active entry after locking its
+ spinlock. The caller must hold the rwlock for the gt in question
+ before calling active_entry_acquire(). This is because the grant
+ table can be dynamically extended via gnttab_grow_table() while a
+ domain is running and must be fully initialized. Once all access to
+ the active entry is complete, release the lock by calling
+ active_entry_release(act).
+
+ Summary of rules for locking:
+  active_entry_acquire() and active_entry_release() can only be
+  called when holding the relevant grant table's lock. I.e.:
+    read_lock(&gt->lock);
+    act = active_entry_acquire(gt, ref);
+    ...
+    active_entry_release(act);
+    read_unlock(&gt->lock);
+
 ********************************************************************************
 
  Granting a foreign domain access to frames
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 018b5b6..6b59627 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -151,10 +151,13 @@ struct active_grant_entry {
                                in the page.                           */
     unsigned      length:16; /* For sub-page grants, the length of the
                                 grant.                                */
+    spinlock_t    lock;      /* lock to protect access of this entry.
+                                see docs/misc/grant-tables.txt for
+                                locking protocol                      */
 };
 
 #define ACGNT_PER_PAGE (PAGE_SIZE / sizeof(struct active_grant_entry))
-#define active_entry(t, e) \
+#define _active_entry(t, e) \
     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
 
 static inline void gnttab_flush_tlb(const struct domain *d)
@@ -182,6 +185,29 @@ nr_active_grant_frames(struct grant_table *gt)
     return num_act_frames_from_sha_frames(nr_grant_frames(gt));
 }
 
+static inline struct active_grant_entry *
+active_entry_acquire(struct grant_table *t, grant_ref_t e)
+{
+    struct active_grant_entry *act;
+
+#ifndef NDEBUG
+    /* not perfect, but better than nothing for a debug build
+     * sanity check
+     */
+    BUG_ON(!rw_is_locked(&t->lock));
+#endif
+
+    act = &_active_entry(t, e);
+    spin_lock(&act->lock);
+
+    return act;
+}
+
+static inline void active_entry_release(struct active_grant_entry *act)
+{
+    spin_unlock(&act->lock);
+}
+    
 /* Check if the page has been paged out, or needs unsharing. 
    If rc == GNTST_okay, *page contains the page struct with a ref taken.
    Caller must do put_page(*page).
@@ -222,30 +248,6 @@ static int __get_paged_frame(unsigned long gfn, unsigned long *frame, struct pag
     return rc;
 }
 
-static inline void
-double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
-{
-    if ( lgt < rgt )
-    {
-        spin_lock(&lgt->maptrack_lock);
-        spin_lock(&rgt->maptrack_lock);
-    }
-    else
-    {
-        if ( lgt != rgt )
-            spin_lock(&rgt->maptrack_lock);
-        spin_lock(&lgt->maptrack_lock);
-    }
-}
-
-static inline void
-double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
-{
-    spin_unlock(&lgt->maptrack_lock);
-    if ( lgt != rgt )
-        spin_unlock(&rgt->maptrack_lock);
-}
-
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -310,7 +312,8 @@ get_maptrack_handle(
     return handle;
 }
 
-/* Number of grant table entries. Caller must hold d's grant table lock. */
+/* Number of grant table entries. Caller must hold d's grant table
+   read lock. */
 static unsigned int nr_grant_entries(struct grant_table *gt)
 {
     ASSERT(gt->gt_version != 0);
@@ -499,7 +502,7 @@ static int grant_map_exists(const struct domain *ld,
                             unsigned long mfn,
                             unsigned int *ref_count)
 {
-    const struct active_grant_entry *act;
+    struct active_grant_entry *act;
     unsigned int ref, max_iter;
     
     ASSERT(rw_is_locked(&rgt->lock));
@@ -508,17 +511,27 @@ static int grant_map_exists(const struct domain *ld,
                    nr_grant_entries(rgt));
     for ( ref = *ref_count; ref < max_iter; ref++ )
     {
-        act = &active_entry(rgt, ref);
+        act = active_entry_acquire(rgt, ref);
 
         if ( !act->pin )
+        {
+            active_entry_release(act);
             continue;
+        }
 
         if ( act->domid != ld->domain_id )
+        {
+            active_entry_release(act);
             continue;
+        }
 
         if ( act->frame != mfn )
+        {
+            active_entry_release(act);
             continue;
+        }
 
+        active_entry_release(act);
         return 0;
     }
 
@@ -531,24 +544,44 @@ static int grant_map_exists(const struct domain *ld,
     return -EINVAL;
 }
 
+/* Count the number of mapped ro or rw entries tracked in the left
+ * grant table given a provided mfn provided by a foreign domain. 
+ *
+ * This function takes the maptrack lock from the left grant table and
+ * must be called with the right grant table's rwlock held.
+ */
 static void mapcount(
     struct grant_table *lgt, struct domain *rd, unsigned long mfn,
     unsigned int *wrc, unsigned int *rdc)
 {
     struct grant_mapping *map;
     grant_handle_t handle;
+    struct active_grant_entry *act;
 
     *wrc = *rdc = 0;
 
+    /* N.B.: while taking the left side maptrack spinlock prevents
+     * any mapping changes, the right side active entries could be
+     * changing while we are counting. To be perfectly correct, the
+     * caller should hold the grant table write lock, or some other
+     * mechanism should be used to prevent concurrent changes during
+     * this operation. This is tricky because we can't promote a read
+     * lock into a write lock.
+     */
+    spin_lock(&lgt->maptrack_lock);
+
     for ( handle = 0; handle < lgt->maptrack_limit; handle++ )
     {
         map = &maptrack_entry(lgt, handle);
         if ( !(map->flags & (GNTMAP_device_map|GNTMAP_host_map)) ||
              map->domid != rd->domain_id )
             continue;
-        if ( active_entry(rd->grant_table, map->ref).frame == mfn )
+        act = &_active_entry(rd->grant_table, map->ref);
+        if ( act->frame == mfn )
             (map->flags & GNTMAP_readonly) ? (*rdc)++ : (*wrc)++;
     }
+
+    spin_unlock(&lgt->maptrack_lock);
 }
 
 /*
@@ -570,7 +603,6 @@ __gnttab_map_grant_ref(
     struct page_info *pg = NULL;
     int            rc = GNTST_okay;
     u32            old_pin;
-    u32            act_pin;
     unsigned int   cache_flags;
     struct active_grant_entry *act = NULL;
     struct grant_mapping *mt;
@@ -633,7 +665,7 @@ __gnttab_map_grant_ref(
     if ( unlikely(op->ref >= nr_grant_entries(rgt)))
         PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref (%d).\n", op->ref);
 
-    act = &active_entry(rgt, op->ref);
+    act = active_entry_acquire(rgt, op->ref);
     shah = shared_entry_header(rgt, op->ref);
     if (rgt->gt_version == 1) {
         sha1 = &shared_entry_v1(rgt, op->ref);
@@ -650,7 +682,7 @@ __gnttab_map_grant_ref(
          ((act->domid != ld->domain_id) ||
           (act->pin & 0x80808080U) != 0 ||
           (act->is_sub_page)) )
-        PIN_FAIL(unlock_out, GNTST_general_error,
+        PIN_FAIL(act_release_out, GNTST_general_error,
                  "Bad domain (%d != %d), or risk of counter overflow %08x, or subpage %d\n",
                  act->domid, ld->domain_id, act->pin, act->is_sub_page);
 
@@ -661,7 +693,7 @@ __gnttab_map_grant_ref(
         if ( (rc = _set_status(rgt->gt_version, ld->domain_id,
                                op->flags & GNTMAP_readonly,
                                1, shah, act, status) ) != GNTST_okay )
-             goto unlock_out;
+            goto act_release_out;
 
         if ( !act->pin )
         {
@@ -692,12 +724,9 @@ __gnttab_map_grant_ref(
             GNTPIN_hstr_inc : GNTPIN_hstw_inc;
 
     frame = act->frame;
-    act_pin = act->pin;
 
     cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
-    read_unlock(&rgt->lock);
-
     /* pg may be set, with a refcount included, from __get_paged_frame */
     if ( !pg )
     {
@@ -772,8 +801,6 @@ __gnttab_map_grant_ref(
         goto undo_out;
     }
 
-    double_gt_lock(lgt, rgt);
-
     if ( gnttab_need_iommu_mapping(ld) )
     {
         unsigned int wrc, rdc;
@@ -781,21 +808,20 @@ __gnttab_map_grant_ref(
         /* We're not translated, so we know that gmfns and mfns are
            the same things, so the IOMMU entry is always 1-to-1. */
         mapcount(lgt, rd, frame, &wrc, &rdc);
-        if ( (act_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
+        if ( (act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
              !(old_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
         {
             if ( wrc == 0 )
                 err = iommu_map_page(ld, frame, frame,
                                      IOMMUF_readable|IOMMUF_writable);
         }
-        else if ( act_pin && !old_pin )
+        else if ( act->pin && !old_pin )
         {
             if ( (wrc + rdc) == 0 )
                 err = iommu_map_page(ld, frame, frame, IOMMUF_readable);
         }
         if ( err )
         {
-            double_gt_unlock(lgt, rgt);
             rc = GNTST_general_error;
             goto undo_out;
         }
@@ -808,7 +834,8 @@ __gnttab_map_grant_ref(
     mt->ref   = op->ref;
     mt->flags = op->flags;
 
-    double_gt_unlock(lgt, rgt);
+    active_entry_release(act);
+    read_unlock(&rgt->lock);
 
     op->dev_bus_addr = (u64)frame << PAGE_SHIFT;
     op->handle       = handle;
@@ -831,10 +858,6 @@ __gnttab_map_grant_ref(
         put_page(pg);
     }
 
-    read_lock(&rgt->lock);
-
-    act = &active_entry(rgt, op->ref);
-
     if ( op->flags & GNTMAP_device_map )
         act->pin -= (op->flags & GNTMAP_readonly) ?
             GNTPIN_devr_inc : GNTPIN_devw_inc;
@@ -850,6 +873,9 @@ __gnttab_map_grant_ref(
     if ( !act->pin )
         gnttab_clear_flag(_GTF_reading, status);
 
+ act_release_out:
+    active_entry_release(act);
+
  unlock_out:
     read_unlock(&rgt->lock);
     op->status = rc;
@@ -891,9 +917,9 @@ __gnttab_unmap_common(
     ld = current->domain;
     lgt = ld->grant_table;
 
-    read_lock(&lgt->lock);
     op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
 
+    read_lock(&lgt->lock);
     if ( unlikely(op->handle >= lgt->maptrack_limit) )
     {
         read_unlock(&lgt->lock);
@@ -933,19 +959,18 @@ __gnttab_unmap_common(
     TRACE_1D(TRC_MEM_PAGE_GRANT_UNMAP, dom);
 
     rgt = rd->grant_table;
-    double_gt_lock(lgt, rgt);
 
     op->flags = op->map->flags;
     if ( unlikely(!op->flags) || unlikely(op->map->domid != dom) )
     {
         gdprintk(XENLOG_WARNING, "Unstable handle %u\n", op->handle);
         rc = GNTST_bad_handle;
-        goto unmap_out;
+        goto unlock_out;
     }
 
     op->rd = rd;
     read_lock(&rgt->lock);
-    act = &active_entry(rgt, op->map->ref);
+    act = active_entry_acquire(rgt, op->map->ref);
 
     if ( op->frame == 0 )
     {
@@ -954,7 +979,7 @@ __gnttab_unmap_common(
     else
     {
         if ( unlikely(op->frame != act->frame) )
-            PIN_FAIL(unmap_out, GNTST_general_error,
+            PIN_FAIL(act_release_out, GNTST_general_error,
                      "Bad frame number doesn't match gntref. (%lx != %lx)\n",
                      op->frame, act->frame);
         if ( op->flags & GNTMAP_device_map )
@@ -973,7 +998,7 @@ __gnttab_unmap_common(
         if ( (rc = replace_grant_host_mapping(op->host_addr,
                                               op->frame, op->new_addr, 
                                               op->flags)) < 0 )
-            goto unmap_out;
+            goto act_release_out;
 
         ASSERT(act->pin & (GNTPIN_hstw_mask | GNTPIN_hstr_mask));
         op->map->flags &= ~GNTMAP_host_map;
@@ -995,7 +1020,7 @@ __gnttab_unmap_common(
         if ( err )
         {
             rc = GNTST_general_error;
-            goto unmap_out;
+            goto act_release_out;
         }
     }
 
@@ -1003,9 +1028,11 @@ __gnttab_unmap_common(
     if ( !(op->flags & GNTMAP_readonly) )
          gnttab_mark_dirty(rd, op->frame);
 
- unmap_out:
-    double_gt_unlock(lgt, rgt);
+ act_release_out:
+    active_entry_release(act);
     read_unlock(&rgt->lock);
+
+ unlock_out:
     op->status = rc;
     rcu_unlock_domain(rd);
 }
@@ -1038,9 +1065,9 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
 
     read_lock(&rgt->lock);
     if ( rgt->gt_version == 0 )
-        goto unmap_out;
+        goto unlock_out;
 
-    act = &active_entry(rgt, op->map->ref);
+    act = active_entry_acquire(rgt, op->map->ref);
     sha = shared_entry_header(rgt, op->map->ref);
 
     if ( rgt->gt_version == 1 )
@@ -1054,7 +1081,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
          * Suggests that __gntab_unmap_common failed early and so
          * nothing further to do
          */
-        goto unmap_out;
+        goto act_release_out;
     }
 
     pg = mfn_to_page(op->frame);
@@ -1078,7 +1105,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
              * Suggests that __gntab_unmap_common failed in
              * replace_grant_host_mapping() so nothing further to do
              */
-            goto unmap_out;
+            goto act_release_out;
         }
 
         if ( !is_iomem_page(op->frame) ) 
@@ -1099,8 +1126,12 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
     if ( act->pin == 0 )
         gnttab_clear_flag(_GTF_reading, status);
 
- unmap_out:
+ act_release_out:
+    active_entry_release(act);
+    
+ unlock_out:
     read_unlock(&rgt->lock);
+
     if ( put_handle )
     {
         op->map->flags = 0;
@@ -1295,7 +1326,7 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
     /* d's grant table write lock must be held by the caller */
 
     struct grant_table *gt = d->grant_table;
-    unsigned int i;
+    unsigned int i, j;
 
     ASSERT(req_nr_frames <= max_grant_frames);
 
@@ -1310,6 +1341,10 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
         if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
             goto active_alloc_failed;
         clear_page(gt->active[i]);
+        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+        {
+            spin_lock_init(&gt->active[i][j].lock);
+        }
     }
 
     /* Shared */
@@ -1804,7 +1839,7 @@ __release_grant_for_copy(
 
     read_lock(&rgt->lock);
 
-    act = &active_entry(rgt, gref);
+    act = active_entry_acquire(rgt, gref);
     sha = shared_entry_header(rgt, gref);
     r_frame = act->frame;
 
@@ -1843,6 +1878,7 @@ __release_grant_for_copy(
         released_read = 1;
     }
 
+    active_entry_release(act);
     read_unlock(&rgt->lock);
 
     if ( td != rd )
@@ -1904,14 +1940,14 @@ __acquire_grant_for_copy(
     read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
-        PIN_FAIL(unlock_out, GNTST_general_error,
+        PIN_FAIL(gnt_unlock_out, GNTST_general_error,
                  "remote grant table not ready\n");
 
     if ( unlikely(gref >= nr_grant_entries(rgt)) )
-        PIN_FAIL(unlock_out, GNTST_bad_gntref,
+        PIN_FAIL(gnt_unlock_out, GNTST_bad_gntref,
                  "Bad grant reference %ld\n", gref);
 
-    act = &active_entry(rgt, gref);
+    act = active_entry_acquire(rgt, gref);
     shah = shared_entry_header(rgt, gref);
     if ( rgt->gt_version == 1 )
     {
@@ -1974,6 +2010,7 @@ __acquire_grant_for_copy(
             /* __acquire_grant_for_copy() could take the read lock on
              * the right table (if rd == td), so we have to drop the
              * lock here and reacquire */
+            active_entry_release(act);
             read_unlock(&rgt->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd->domain_id,
@@ -1981,8 +2018,11 @@ __acquire_grant_for_copy(
                                           &trans_page_off, &trans_length, 0);
 
             read_lock(&rgt->lock);
+            act = active_entry_acquire(rgt, gref);
+
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_copy_pin(act, status);
+                active_entry_release(act);
                 read_unlock(&rgt->lock);
                 rcu_unlock_domain(td);
                 return rc;
@@ -1996,6 +2036,7 @@ __acquire_grant_for_copy(
             {
                 __fixup_status_for_copy_pin(act, status);
                 rcu_unlock_domain(td);
+                active_entry_release(act);
                 read_unlock(&rgt->lock);
                 put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ldom, readonly,
@@ -2064,6 +2105,7 @@ __acquire_grant_for_copy(
     *length = act->length;
     *frame = act->frame;
 
+    active_entry_release(act);
     read_unlock(&rgt->lock);
     return rc;
  
@@ -2076,6 +2118,9 @@ __acquire_grant_for_copy(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
+    active_entry_release(act);
+
+ gnt_unlock_out:
     read_unlock(&rgt->lock);
     return rc;
 }
@@ -2259,16 +2304,18 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     {
         for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
-            act = &active_entry(gt, i);
+            act = active_entry_acquire(gt, i);
             if ( act->pin != 0 )
             {
                 gdprintk(XENLOG_WARNING,
                          "tried to change grant table version from %d to %d, but some grant entries still in use\n",
                          gt->gt_version,
                          op.version);
+                active_entry_release(act);
                 res = -EBUSY;
                 goto out_unlock;
             }
+            active_entry_release(act);
         }
     }
 
@@ -2447,7 +2494,8 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
 {
     struct domain *d = rcu_lock_current_domain();
     struct grant_table *gt = d->grant_table;
-    struct active_grant_entry *act;
+    struct active_grant_entry *act_a = NULL;
+    struct active_grant_entry *act_b = NULL;
     s16 rc = GNTST_okay;
 
     read_lock(&gt->lock);
@@ -2458,12 +2506,12 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     if ( unlikely(ref_b >= nr_grant_entries(d->grant_table)))
         PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-b (%d).\n", ref_b);
 
-    act = &active_entry(gt, ref_a);
-    if ( act->pin )
+    act_a = active_entry_acquire(gt, ref_a);
+    if ( act_a->pin )
         PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
 
-    act = &active_entry(gt, ref_b);
-    if ( act->pin )
+    act_b = active_entry_acquire(gt, ref_b);
+    if ( act_b->pin )
         PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
 
     if ( gt->gt_version == 1 )
@@ -2490,8 +2538,11 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     }
 
 out:
+    if ( act_b != NULL )
+        active_entry_release(act_b);
+    if ( act_a != NULL )
+        active_entry_release(act_a);
     read_unlock(&gt->lock);
-
     rcu_unlock_domain(d);
 
     return rc;
@@ -2807,7 +2858,7 @@ grant_table_create(
     struct domain *d)
 {
     struct grant_table *t;
-    int                 i;
+    int                 i, j;
 
     if ( (t = xzalloc(struct grant_table)) == NULL )
         goto no_mem_0;
@@ -2827,6 +2878,10 @@ grant_table_create(
         if ( (t->active[i] = alloc_xenheap_page()) == NULL )
             goto no_mem_2;
         clear_page(t->active[i]);
+        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+        {
+            spin_lock_init(&t->active[i][j].lock);
+        }
     }
 
     /* Tracking of mapped foreign frames table */
@@ -2923,7 +2978,7 @@ gnttab_release_mappings(
         rgt = rd->grant_table;
         read_lock(&rgt->lock);
 
-        act = &active_entry(rgt, ref);
+        act = active_entry_acquire(rgt, ref);
         sha = shared_entry_header(rgt, ref);
         if (rgt->gt_version == 1)
             status = &sha->flags;
@@ -2981,6 +3036,7 @@ gnttab_release_mappings(
         if ( act->pin == 0 )
             gnttab_clear_flag(_GTF_reading, status);
 
+        active_entry_release(act);
         read_unlock(&rgt->lock);
 
         rcu_unlock_domain(rd);
@@ -3001,7 +3057,7 @@ grant_table_destroy(
         return;
 
     write_lock(&t->lock);
-    
+
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
     xfree(t->shared_raw);
@@ -3047,9 +3103,11 @@ static void gnttab_usage_print(struct domain *rd)
         uint16_t status;
         uint64_t frame;
 
-        act = &active_entry(gt, ref);
-        if ( !act->pin )
+        act = active_entry_acquire(gt, ref);
+        if ( !act->pin ) {
+            active_entry_release(act);
             continue;
+        }
 
         sha = shared_entry_header(gt, ref);
 
@@ -3079,6 +3137,7 @@ static void gnttab_usage_print(struct domain *rd)
         printk("[%3d]    %5d 0x%06lx 0x%08x      %5d 0x%06"PRIx64" 0x%02x\n",
                ref, act->domid, act->frame, act->pin,
                sha->domid, frame, status);
+        active_entry_release(act);
     }
 
  out:
-- 
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 Dec 02 10:07:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkMT-0001RD-LK; Tue, 02 Dec 2014 10:07:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1XvkMR-0001Qv-RL
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:07:12 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	46/EC-09842-F4F8D745; Tue, 02 Dec 2014 10:07:11 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417514828!12809031!1
X-Originating-IP: [207.171.178.25]
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 30093 invoked from network); 2 Dec 2014 10:07:09 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 10:07:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417514829; x=1449050829;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version;
	bh=wGCZXeKIoqGPBXGer+Y2SIjNP2zV2zqWKF7Bm5/+UFY=;
	b=IEz/Jjhx/y0RNGTNxK5/qr02OMdI1hrxWm19TB00/Ge38Lnhf+whpIPE
	JiLKSYjv8+ITRM/7CCbj2a1lAw6gDd2P9Ceh67SsbypRBWFP0XTu1BuQE
	13G9GFZm8OxChfLPtJKP45KRa+1N7LUaVhASkQeu4BTJzr3tbpZNavIp2 A=;
X-IronPort-AV: E=Sophos;i="5.07,499,1413244800"; d="scan'208";a="174736709"
Received: from email-inbound-relay-6002.iad6.amazon.com ([10.219.219.179])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 10:07:06 +0000
Received: from ex10-hub-7002.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com
	[10.0.103.146])
	by email-inbound-relay-6002.iad6.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB2A72AV024508
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 10:07:05 GMT
Received: from EX13D05UWC001.ant.amazon.com (10.43.162.82) by
	ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 02:07:03 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.162.149) by
	EX13D05UWC001.ant.amazon.com (10.43.162.82) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 10:07:00 +0000
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 11:06:23 +0100
Message-ID: <1417514784-15749-2-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1417514784-15749-1-git-send-email-chegger@amazon.de>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
MIME-Version: 1.0
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D05UWC001.ant.amazon.com (10.43.162.82) To
	EX13D05UWC001.ant.amazon.com (10.43.162.82)
Precedence: Bulk
Cc: Christoph Egger <chegger@amazon.de>, Keir Fraser <keir@xen.org>, Jan
	Beulich <jbeulich@suse.com>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 1/2] gnttab: Introduce rwlock to protect updates
	to grant table state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 lock to maptrack_lock and use it to protect maptrack state.

The new rwlock is used to prevent readers from accessing
inconsistent grant table state such as current
version, partially initialized active table pages,
etc.

Signed-off-by: Matt Wilson <msw@amazon.com>
[chegger: ported to xen-staging, split into multiple commits]
Signed-off-by: Christoph Egger <chegger@amazon.de>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
---
 docs/misc/grant-tables.txt    |   28 ++++++++-
 xen/arch/x86/mm.c             |    4 +-
 xen/common/grant_table.c      |  135 ++++++++++++++++++++++++-----------------
 xen/include/xen/grant_table.h |    9 ++-
 4 files changed, 115 insertions(+), 61 deletions(-)

diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt
index 19db4ec..c9ae8f2 100644
--- a/docs/misc/grant-tables.txt
+++ b/docs/misc/grant-tables.txt
@@ -74,7 +74,33 @@ is complete.
  matching map track entry is then removed, as if unmap had been invoked.
  These are not used by the transfer mechanism.
   map->domid         : owner of the mapped frame
-  map->ref_and_flags : grant reference, ro/rw, mapped for host or device access
+  map->ref           : grant reference
+  map->flags         : ro/rw, mapped for host or device access
+
+********************************************************************************
+ Locking
+ ~~~~~~~
+ Xen uses several locks to serialize access to the internal grant table state.
+
+  grant_table->lock          : rwlock used to prevent readers from accessing
+                               inconsistent grant table state such as current
+                               version, partially initialized active table pages,
+                               etc.
+  grant_table->maptrack_lock : spinlock used to protect the maptrack state
+
+ The primary lock for the grant table is a read/write spinlock. All
+ functions that access members of struct grant_table must acquire a
+ read lock around critical sections. Any modification to the members
+ of struct grant_table (e.g., nr_status_frames, nr_grant_frames,
+ active frames, etc.) must only be made if the write lock is
+ held. These elements are read-mostly, and read critical sections can
+ be large, which makes a rwlock a good choice.
+
+ The maptrack state is protected by its own spinlock. Any access (read
+ or write) of struct grant_table members that have a "maptrack_"
+ prefix must be made while holding the maptrack lock. The maptrack
+ state can be rapidly modified under some workloads, and the critical
+ sections are very small, thus we use a spinlock to protect them.
 
 ********************************************************************************
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 522c43d..37c13b1 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
                 mfn = virt_to_mfn(d->shared_info);
             break;
         case XENMAPSPACE_grant_table:
-            spin_lock(&d->grant_table->lock);
+            write_lock(&d->grant_table->lock);
 
             if ( d->grant_table->gt_version == 0 )
                 d->grant_table->gt_version = 1;
@@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
                     mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
             }
 
-            spin_unlock(&d->grant_table->lock);
+            write_unlock(&d->grant_table->lock);
             break;
         case XENMAPSPACE_gmfn_range:
         case XENMAPSPACE_gmfn:
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 8fba923..018b5b6 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -227,23 +227,23 @@ double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
 {
     if ( lgt < rgt )
     {
-        spin_lock(&lgt->lock);
-        spin_lock(&rgt->lock);
+        spin_lock(&lgt->maptrack_lock);
+        spin_lock(&rgt->maptrack_lock);
     }
     else
     {
         if ( lgt != rgt )
-            spin_lock(&rgt->lock);
-        spin_lock(&lgt->lock);
+            spin_lock(&rgt->maptrack_lock);
+        spin_lock(&lgt->maptrack_lock);
     }
 }
 
 static inline void
 double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
 {
-    spin_unlock(&lgt->lock);
+    spin_unlock(&lgt->maptrack_lock);
     if ( lgt != rgt )
-        spin_unlock(&rgt->lock);
+        spin_unlock(&rgt->maptrack_lock);
 }
 
 static inline int
@@ -261,10 +261,10 @@ static inline void
 put_maptrack_handle(
     struct grant_table *t, int handle)
 {
-    spin_lock(&t->lock);
+    spin_lock(&t->maptrack_lock);
     maptrack_entry(t, handle).ref = t->maptrack_head;
     t->maptrack_head = handle;
-    spin_unlock(&t->lock);
+    spin_unlock(&t->maptrack_lock);
 }
 
 static inline int
@@ -276,7 +276,7 @@ get_maptrack_handle(
     struct grant_mapping *new_mt;
     unsigned int          new_mt_limit, nr_frames;
 
-    spin_lock(&lgt->lock);
+    spin_lock(&lgt->maptrack_lock);
 
     while ( unlikely((handle = __get_maptrack_handle(lgt)) == -1) )
     {
@@ -305,7 +305,7 @@ get_maptrack_handle(
                  nr_frames + 1);
     }
 
-    spin_unlock(&lgt->lock);
+    spin_unlock(&lgt->maptrack_lock);
 
     return handle;
 }
@@ -502,7 +502,7 @@ static int grant_map_exists(const struct domain *ld,
     const struct active_grant_entry *act;
     unsigned int ref, max_iter;
     
-    ASSERT(spin_is_locked(&rgt->lock));
+    ASSERT(rw_is_locked(&rgt->lock));
 
     max_iter = min(*ref_count + (1 << GNTTABOP_CONTINUATION_ARG_SHIFT),
                    nr_grant_entries(rgt));
@@ -623,7 +623,7 @@ __gnttab_map_grant_ref(
     }
 
     rgt = rd->grant_table;
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
         PIN_FAIL(unlock_out, GNTST_general_error,
@@ -696,7 +696,7 @@ __gnttab_map_grant_ref(
 
     cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
 
     /* pg may be set, with a refcount included, from __get_paged_frame */
     if ( !pg )
@@ -831,7 +831,7 @@ __gnttab_map_grant_ref(
         put_page(pg);
     }
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     act = &active_entry(rgt, op->ref);
 
@@ -851,7 +851,7 @@ __gnttab_map_grant_ref(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     op->status = rc;
     put_maptrack_handle(lgt, handle);
     rcu_unlock_domain(rd);
@@ -891,28 +891,28 @@ __gnttab_unmap_common(
     ld = current->domain;
     lgt = ld->grant_table;
 
+    read_lock(&lgt->lock);
     op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
 
     if ( unlikely(op->handle >= lgt->maptrack_limit) )
     {
+        read_unlock(&lgt->lock);
         gdprintk(XENLOG_INFO, "Bad handle (%d).\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
+    read_unlock(&lgt->lock);
     op->map = &maptrack_entry(lgt, op->handle);
-    spin_lock(&lgt->lock);
 
     if ( unlikely(!op->map->flags) )
     {
-        spin_unlock(&lgt->lock);
         gdprintk(XENLOG_INFO, "Zero flags for handle (%d).\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
     dom = op->map->domid;
-    spin_unlock(&lgt->lock);
 
     if ( unlikely((rd = rcu_lock_domain_by_id(dom)) == NULL) )
     {
@@ -944,6 +944,7 @@ __gnttab_unmap_common(
     }
 
     op->rd = rd;
+    read_lock(&rgt->lock);
     act = &active_entry(rgt, op->map->ref);
 
     if ( op->frame == 0 )
@@ -1004,6 +1005,7 @@ __gnttab_unmap_common(
 
  unmap_out:
     double_gt_unlock(lgt, rgt);
+    read_unlock(&rgt->lock);
     op->status = rc;
     rcu_unlock_domain(rd);
 }
@@ -1033,8 +1035,8 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
 
     rcu_lock_domain(rd);
     rgt = rd->grant_table;
-    spin_lock(&rgt->lock);
 
+    read_lock(&rgt->lock);
     if ( rgt->gt_version == 0 )
         goto unmap_out;
 
@@ -1098,7 +1100,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
         gnttab_clear_flag(_GTF_reading, status);
 
  unmap_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     if ( put_handle )
     {
         op->map->flags = 0;
@@ -1284,10 +1286,13 @@ gnttab_unpopulate_status_frames(struct domain *d, struct grant_table *gt)
     gt->nr_status_frames = 0;
 }
 
+/* Grow the grant table. The caller must hold the grant table's
+ * write lock before calling this function.
+ */
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
 {
-    /* d's grant table lock must be held by the caller */
+    /* d's grant table write lock must be held by the caller */
 
     struct grant_table *gt = d->grant_table;
     unsigned int i;
@@ -1392,7 +1397,7 @@ gnttab_setup_table(
     }
 
     gt = d->grant_table;
-    spin_lock(&gt->lock);
+    write_lock(&gt->lock);
 
     if ( gt->gt_version == 0 )
         gt->gt_version = 1;
@@ -1420,7 +1425,7 @@ gnttab_setup_table(
     }
 
  out3:
-    spin_unlock(&gt->lock);
+    write_unlock(&gt->lock);
  out2:
     rcu_unlock_domain(d);
  out1:
@@ -1462,13 +1467,13 @@ gnttab_query_size(
         goto query_out_unlock;
     }
 
-    spin_lock(&d->grant_table->lock);
+    read_lock(&d->grant_table->lock);
 
     op.nr_frames     = nr_grant_frames(d->grant_table);
     op.max_nr_frames = max_grant_frames;
     op.status        = GNTST_okay;
 
-    spin_unlock(&d->grant_table->lock);
+    read_unlock(&d->grant_table->lock);
 
  
  query_out_unlock:
@@ -1494,7 +1499,7 @@ gnttab_prepare_for_transfer(
     union grant_combo   scombo, prev_scombo, new_scombo;
     int                 retries = 0;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
     {
@@ -1545,11 +1550,11 @@ gnttab_prepare_for_transfer(
         scombo = prev_scombo;
     }
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return 1;
 
  fail:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return 0;
 }
 
@@ -1741,7 +1746,7 @@ gnttab_transfer(
         TRACE_1D(TRC_MEM_PAGE_GRANT_TRANSFER, e->domain_id);
 
         /* Tell the guest about its new page frame. */
-        spin_lock(&e->grant_table->lock);
+        read_lock(&e->grant_table->lock);
 
         if ( e->grant_table->gt_version == 1 )
         {
@@ -1759,7 +1764,7 @@ gnttab_transfer(
         shared_entry_header(e->grant_table, gop.ref)->flags |=
             GTF_transfer_completed;
 
-        spin_unlock(&e->grant_table->lock);
+        read_unlock(&e->grant_table->lock);
 
         rcu_unlock_domain(e);
 
@@ -1797,7 +1802,7 @@ __release_grant_for_copy(
     released_read = 0;
     released_write = 0;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     act = &active_entry(rgt, gref);
     sha = shared_entry_header(rgt, gref);
@@ -1838,7 +1843,7 @@ __release_grant_for_copy(
         released_read = 1;
     }
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
 
     if ( td != rd )
     {
@@ -1896,7 +1901,7 @@ __acquire_grant_for_copy(
 
     *page = NULL;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
         PIN_FAIL(unlock_out, GNTST_general_error,
@@ -1965,17 +1970,21 @@ __acquire_grant_for_copy(
                 PIN_FAIL(unlock_out_clear, GNTST_general_error,
                          "transitive grant referenced bad domain %d\n",
                          trans_domid);
-            spin_unlock(&rgt->lock);
+
+            /* __acquire_grant_for_copy() could take the read lock on
+             * the right table (if rd == td), so we have to drop the
+             * lock here and reacquire */
+            read_unlock(&rgt->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd->domain_id,
                                           readonly, &grant_frame, page,
                                           &trans_page_off, &trans_length, 0);
 
-            spin_lock(&rgt->lock);
+            read_lock(&rgt->lock);
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_copy_pin(act, status);
+                read_unlock(&rgt->lock);
                 rcu_unlock_domain(td);
-                spin_unlock(&rgt->lock);
                 return rc;
             }
 
@@ -1987,7 +1996,7 @@ __acquire_grant_for_copy(
             {
                 __fixup_status_for_copy_pin(act, status);
                 rcu_unlock_domain(td);
-                spin_unlock(&rgt->lock);
+                read_unlock(&rgt->lock);
                 put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ldom, readonly,
                                                 frame, page, page_off, length,
@@ -2055,7 +2064,7 @@ __acquire_grant_for_copy(
     *length = act->length;
     *frame = act->frame;
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return rc;
  
  unlock_out_clear:
@@ -2067,7 +2076,7 @@ __acquire_grant_for_copy(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return rc;
 }
 
@@ -2241,7 +2250,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     if ( gt->gt_version == op.version )
         goto out;
 
-    spin_lock(&gt->lock);
+    write_lock(&gt->lock);
     /* Make sure that the grant table isn't currently in use when we
        change the version number, except for the first 8 entries which
        are allowed to be in use (xenstore/xenconsole keeps them mapped).
@@ -2327,7 +2336,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     gt->gt_version = op.version;
 
 out_unlock:
-    spin_unlock(&gt->lock);
+    write_unlock(&gt->lock);
 
 out:
     op.version = gt->gt_version;
@@ -2383,7 +2392,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
 
     op.status = GNTST_okay;
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     for ( i = 0; i < op.nr_frames; i++ )
     {
@@ -2392,7 +2401,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
             op.status = GNTST_bad_virt_addr;
     }
 
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 out2:
     rcu_unlock_domain(d);
 out1:
@@ -2441,7 +2450,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     struct active_grant_entry *act;
     s16 rc = GNTST_okay;
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     /* Bounds check on the grant refs */
     if ( unlikely(ref_a >= nr_grant_entries(d->grant_table)))
@@ -2481,7 +2490,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     }
 
 out:
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 
     rcu_unlock_domain(d);
 
@@ -2501,8 +2510,19 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) uop,
             return i;
         if ( unlikely(__copy_from_guest(&op, uop, 1)) )
             return -EFAULT;
-        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
-        if ( unlikely(__copy_field_to_guest(uop, &op, status)) )
+        if ( unlikely(op.ref_a == op.ref_b) )
+        {
+            /* noop, so avoid acquiring the same active entry
+             * twice in __gnttab_swap_grant_ref(), which would
+             * case a deadlock.
+             */
+            op.status = GNTST_okay;
+        }
+        else
+        {
+            op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
+        }
+        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
             return -EFAULT;
         guest_handle_add_offset(uop, 1);
     }
@@ -2552,12 +2572,12 @@ static int __gnttab_cache_flush(gnttab_cache_flush_t *cflush,
 
     if ( d != owner )
     {
-        spin_lock(&owner->grant_table->lock);
+        read_lock(&owner->grant_table->lock);
 
         ret = grant_map_exists(d, owner->grant_table, mfn, ref_count);
         if ( ret != 0 )
         {
-            spin_unlock(&owner->grant_table->lock);
+            read_unlock(&owner->grant_table->lock);
             rcu_unlock_domain(d);
             put_page(page);
             return ret;
@@ -2577,7 +2597,7 @@ static int __gnttab_cache_flush(gnttab_cache_flush_t *cflush,
         ret = 0;
 
     if ( d != owner )
-        spin_unlock(&owner->grant_table->lock);
+        read_unlock(&owner->grant_table->lock);
     unmap_domain_page(v);
     put_page(page);
 
@@ -2793,7 +2813,8 @@ grant_table_create(
         goto no_mem_0;
 
     /* Simple stuff. */
-    spin_lock_init(&t->lock);
+    rwlock_init(&t->lock);
+    spin_lock_init(&t->maptrack_lock);
     t->nr_grant_frames = INITIAL_NR_GRANT_FRAMES;
 
     /* Active grant table. */
@@ -2900,7 +2921,7 @@ gnttab_release_mappings(
         }
 
         rgt = rd->grant_table;
-        spin_lock(&rgt->lock);
+        read_lock(&rgt->lock);
 
         act = &active_entry(rgt, ref);
         sha = shared_entry_header(rgt, ref);
@@ -2960,7 +2981,7 @@ gnttab_release_mappings(
         if ( act->pin == 0 )
             gnttab_clear_flag(_GTF_reading, status);
 
-        spin_unlock(&rgt->lock);
+        read_unlock(&rgt->lock);
 
         rcu_unlock_domain(rd);
 
@@ -2978,6 +2999,8 @@ grant_table_destroy(
 
     if ( t == NULL )
         return;
+
+    write_lock(&t->lock);
     
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
@@ -2995,6 +3018,8 @@ grant_table_destroy(
         free_xenheap_page(t->status[i]);
     xfree(t->status);
 
+    write_unlock(&t->lock);
+
     xfree(t);
     d->grant_table = NULL;
 }
@@ -3008,7 +3033,7 @@ static void gnttab_usage_print(struct domain *rd)
     printk("      -------- active --------       -------- shared --------\n");
     printk("[ref] localdom mfn      pin          localdom gmfn     flags\n");
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     if ( gt->gt_version == 0 )
         goto out;
@@ -3057,7 +3082,7 @@ static void gnttab_usage_print(struct domain *rd)
     }
 
  out:
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 
     if ( first )
         printk("grant-table for remote domain:%5d ... "
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 32f5786..ca49b41 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -82,8 +82,11 @@ struct grant_table {
     struct grant_mapping **maptrack;
     unsigned int          maptrack_head;
     unsigned int          maptrack_limit;
-    /* Lock protecting updates to active and shared grant tables. */
-    spinlock_t            lock;
+    /* Lock protecting the maptrack page list, head, and limit */
+    spinlock_t            maptrack_lock;
+    /* Lock protecting updates to grant table state (version, active
+       entry list, etc.) */
+    rwlock_t              lock;
     /* The defined versions are 1 and 2.  Set to 0 if we don't know
        what version to use yet. */
     unsigned              gt_version;
@@ -101,7 +104,7 @@ gnttab_release_mappings(
     struct domain *d);
 
 /* Increase the size of a domain's grant table.
- * Caller must hold d's grant table lock.
+ * Caller must hold d's grant table write lock.
  */
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames);
-- 
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 Dec 02 10:07:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkMU-0001RO-3D; Tue, 02 Dec 2014 10:07:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1XvkMS-0001Qk-6I
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:07:12 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	4B/AA-17735-A4F8D745; Tue, 02 Dec 2014 10:07:06 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417514824!12760806!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjA0MDI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 472 invoked from network); 2 Dec 2014 10:07:06 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 10:07:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417514826; x=1449050826;
	h=from:to:subject:date:message-id:mime-version;
	bh=J+pbe/XL+HH4PwTHiLAZiBkniTjACSSrC3OY/zv8L1Q=;
	b=d5tIudZ8w2iqvbbetSUtSje1IC+8uGSHui+yWnVfezDlmnHISHTq7NEa
	S7+T4ahSXIpgQw359X874yZiSMorFPWhj+yy6NozU0HDObav7Q7tItHDc
	dVJmQdFykC53lYuHsVC3tRtkJu3dxjIxU0BOfo9NF0URvw7wxWempDRWv 4=;
X-IronPort-AV: E=Sophos;i="5.07,499,1413244800"; d="scan'208";a="150586336"
Received: from smtp-in-7002.iad7.amazon.com ([10.229.167.11])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 10:07:03 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com
	[10.0.103.146])
	by smtp-in-7002.iad7.amazon.com (8.14.7/8.14.7) with ESMTP id
	sB2A70Yh020895
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Tue, 2 Dec 2014 10:07:02 GMT
Received: from EX13D05UWC001.ant.amazon.com (10.43.162.82) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 02:07:01 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.162.149) by
	EX13D05UWC001.ant.amazon.com (10.43.162.82) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 10:06:59 +0000
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 11:06:22 +0100
Message-ID: <1417514784-15749-1-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D05UWC001.ant.amazon.com (10.43.162.82) To
	EX13D05UWC001.ant.amazon.com (10.43.162.82)
Precedence: Bulk
Subject: [Xen-devel] [PATCH 0/2] gnttab: Improve scaleability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 changes the grant table locking to
a more fain grained locking protocol. The result is
a performance boost measured with blkfront/blkback.
Document the locking protocol.

[PATCH 1/2] gnttab: Introduce rwlock to protect updates to grant
[PATCH 2/2] gnttab: refactor locking for scalability

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 10:07:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkMU-0001Rb-FB; Tue, 02 Dec 2014 10:07:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1XvkMS-0001R2-Sr
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:07:13 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	9E/12-25727-05F8D745; Tue, 02 Dec 2014 10:07:12 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417514824!12760806!2
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjA0MDI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2010 invoked from network); 2 Dec 2014 10:07:10 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 10:07:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417514830; x=1449050830;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version;
	bh=OPPNBVnxn51UV2JAt+1lM+8iAvUNqls00ItrjauEYmE=;
	b=o3h8e8uwgaXC3ndV5QJuLS/4TMx9VTYMNXXuvcoGGw5O1GciNkb6zkcR
	jqplwPkjkINVEFLwM5DVpbDoS8+CwVcFU5wgTHZK4F9wb1D54CvvJoYNP
	TQ1o0fRPEn9paJ9j+BDQ59fl6wrJkXTTVHT0kWM7AHkSZ2ZZkiNOn+9Zi w=;
X-IronPort-AV: E=Sophos;i="5.07,499,1413244800"; d="scan'208";a="150586403"
Received: from email-inbound-relay-25002.iad12.amazon.com ([10.205.29.134])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 10:07:09 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com
	[10.0.103.150])
	by email-inbound-relay-25002.iad12.amazon.com (8.14.7/8.14.7) with
	ESMTP id sB2A76I4008556
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 10:07:07 GMT
Received: from EX13D05UWC001.ant.amazon.com (10.43.162.82) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 02:07:05 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.162.149) by
	EX13D05UWC001.ant.amazon.com (10.43.162.82) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 10:07:03 +0000
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 11:06:24 +0100
Message-ID: <1417514784-15749-3-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1417514784-15749-1-git-send-email-chegger@amazon.de>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
MIME-Version: 1.0
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D05UWC001.ant.amazon.com (10.43.162.82) To
	EX13D05UWC001.ant.amazon.com (10.43.162.82)
Precedence: Bulk
Cc: Jan Beulich <jbeulich@suse.com>, Christoph Egger <chegger@amazon.de>,
	Keir Fraser <keir@xen.org>, Anthony Liguori <aliguori@amazon.com>,
	Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 2/2] gnttab: refactor locking for scalability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Matt Wilson <msw@amazon.com>

This patch refactors grant table locking. It splits the previous
single spinlock per grant table into multiple locks. The heavily
modified components of the grant table (the maptrack state and the
active entries) are now protected by their own spinlocks. The
remaining elements of the grant table are read-mostly, so the main
grant table lock is modified to be a rwlock to improve concurrency.

Workloads with high grant table operation rates, especially map/unmap
operations as used by blkback/blkfront when persistent grants are not
supported, show marked improvement with these changes. A domU with 24
VBDs in a streaming 2M write workload achieved 1,400 MB/sec before
this change. Performance more than doubles with this patch, reaching
3,000 MB/sec before tuning and 3,600 MB/sec after adjusting event
channel vCPU bindings.

Signed-off-by: Matt Wilson <msw@amazon.com>
[chegger: ported to xen-staging, split into multiple commits]
Signed-off-by: Christoph Egger <chegger@amazon.de>
Cc: Anthony Liguori <aliguori@amazon.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
---
 docs/misc/grant-tables.txt |   21 +++++
 xen/common/grant_table.c   |  213 ++++++++++++++++++++++++++++----------------
 2 files changed, 157 insertions(+), 77 deletions(-)

diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt
index c9ae8f2..1ada018 100644
--- a/docs/misc/grant-tables.txt
+++ b/docs/misc/grant-tables.txt
@@ -63,6 +63,7 @@ is complete.
   act->domid : remote domain being granted rights
   act->frame : machine frame being granted
   act->pin   : used to hold reference counts
+  act->lock  : spinlock used to serialize access to active entry state
 
  Map tracking
  ~~~~~~~~~~~~
@@ -87,6 +88,8 @@ is complete.
                                version, partially initialized active table pages,
                                etc.
   grant_table->maptrack_lock : spinlock used to protect the maptrack state
+  active_grant_entry->lock   : spinlock used to serialize modifications to
+                               active entries
 
  The primary lock for the grant table is a read/write spinlock. All
  functions that access members of struct grant_table must acquire a
@@ -102,6 +105,24 @@ is complete.
  state can be rapidly modified under some workloads, and the critical
  sections are very small, thus we use a spinlock to protect them.
 
+ Active entries are obtained by calling active_entry_acquire(gt, ref).
+ This function returns a pointer to the active entry after locking its
+ spinlock. The caller must hold the rwlock for the gt in question
+ before calling active_entry_acquire(). This is because the grant
+ table can be dynamically extended via gnttab_grow_table() while a
+ domain is running and must be fully initialized. Once all access to
+ the active entry is complete, release the lock by calling
+ active_entry_release(act).
+
+ Summary of rules for locking:
+  active_entry_acquire() and active_entry_release() can only be
+  called when holding the relevant grant table's lock. I.e.:
+    read_lock(&gt->lock);
+    act = active_entry_acquire(gt, ref);
+    ...
+    active_entry_release(act);
+    read_unlock(&gt->lock);
+
 ********************************************************************************
 
  Granting a foreign domain access to frames
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 018b5b6..6b59627 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -151,10 +151,13 @@ struct active_grant_entry {
                                in the page.                           */
     unsigned      length:16; /* For sub-page grants, the length of the
                                 grant.                                */
+    spinlock_t    lock;      /* lock to protect access of this entry.
+                                see docs/misc/grant-tables.txt for
+                                locking protocol                      */
 };
 
 #define ACGNT_PER_PAGE (PAGE_SIZE / sizeof(struct active_grant_entry))
-#define active_entry(t, e) \
+#define _active_entry(t, e) \
     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
 
 static inline void gnttab_flush_tlb(const struct domain *d)
@@ -182,6 +185,29 @@ nr_active_grant_frames(struct grant_table *gt)
     return num_act_frames_from_sha_frames(nr_grant_frames(gt));
 }
 
+static inline struct active_grant_entry *
+active_entry_acquire(struct grant_table *t, grant_ref_t e)
+{
+    struct active_grant_entry *act;
+
+#ifndef NDEBUG
+    /* not perfect, but better than nothing for a debug build
+     * sanity check
+     */
+    BUG_ON(!rw_is_locked(&t->lock));
+#endif
+
+    act = &_active_entry(t, e);
+    spin_lock(&act->lock);
+
+    return act;
+}
+
+static inline void active_entry_release(struct active_grant_entry *act)
+{
+    spin_unlock(&act->lock);
+}
+    
 /* Check if the page has been paged out, or needs unsharing. 
    If rc == GNTST_okay, *page contains the page struct with a ref taken.
    Caller must do put_page(*page).
@@ -222,30 +248,6 @@ static int __get_paged_frame(unsigned long gfn, unsigned long *frame, struct pag
     return rc;
 }
 
-static inline void
-double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
-{
-    if ( lgt < rgt )
-    {
-        spin_lock(&lgt->maptrack_lock);
-        spin_lock(&rgt->maptrack_lock);
-    }
-    else
-    {
-        if ( lgt != rgt )
-            spin_lock(&rgt->maptrack_lock);
-        spin_lock(&lgt->maptrack_lock);
-    }
-}
-
-static inline void
-double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
-{
-    spin_unlock(&lgt->maptrack_lock);
-    if ( lgt != rgt )
-        spin_unlock(&rgt->maptrack_lock);
-}
-
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -310,7 +312,8 @@ get_maptrack_handle(
     return handle;
 }
 
-/* Number of grant table entries. Caller must hold d's grant table lock. */
+/* Number of grant table entries. Caller must hold d's grant table
+   read lock. */
 static unsigned int nr_grant_entries(struct grant_table *gt)
 {
     ASSERT(gt->gt_version != 0);
@@ -499,7 +502,7 @@ static int grant_map_exists(const struct domain *ld,
                             unsigned long mfn,
                             unsigned int *ref_count)
 {
-    const struct active_grant_entry *act;
+    struct active_grant_entry *act;
     unsigned int ref, max_iter;
     
     ASSERT(rw_is_locked(&rgt->lock));
@@ -508,17 +511,27 @@ static int grant_map_exists(const struct domain *ld,
                    nr_grant_entries(rgt));
     for ( ref = *ref_count; ref < max_iter; ref++ )
     {
-        act = &active_entry(rgt, ref);
+        act = active_entry_acquire(rgt, ref);
 
         if ( !act->pin )
+        {
+            active_entry_release(act);
             continue;
+        }
 
         if ( act->domid != ld->domain_id )
+        {
+            active_entry_release(act);
             continue;
+        }
 
         if ( act->frame != mfn )
+        {
+            active_entry_release(act);
             continue;
+        }
 
+        active_entry_release(act);
         return 0;
     }
 
@@ -531,24 +544,44 @@ static int grant_map_exists(const struct domain *ld,
     return -EINVAL;
 }
 
+/* Count the number of mapped ro or rw entries tracked in the left
+ * grant table given a provided mfn provided by a foreign domain. 
+ *
+ * This function takes the maptrack lock from the left grant table and
+ * must be called with the right grant table's rwlock held.
+ */
 static void mapcount(
     struct grant_table *lgt, struct domain *rd, unsigned long mfn,
     unsigned int *wrc, unsigned int *rdc)
 {
     struct grant_mapping *map;
     grant_handle_t handle;
+    struct active_grant_entry *act;
 
     *wrc = *rdc = 0;
 
+    /* N.B.: while taking the left side maptrack spinlock prevents
+     * any mapping changes, the right side active entries could be
+     * changing while we are counting. To be perfectly correct, the
+     * caller should hold the grant table write lock, or some other
+     * mechanism should be used to prevent concurrent changes during
+     * this operation. This is tricky because we can't promote a read
+     * lock into a write lock.
+     */
+    spin_lock(&lgt->maptrack_lock);
+
     for ( handle = 0; handle < lgt->maptrack_limit; handle++ )
     {
         map = &maptrack_entry(lgt, handle);
         if ( !(map->flags & (GNTMAP_device_map|GNTMAP_host_map)) ||
              map->domid != rd->domain_id )
             continue;
-        if ( active_entry(rd->grant_table, map->ref).frame == mfn )
+        act = &_active_entry(rd->grant_table, map->ref);
+        if ( act->frame == mfn )
             (map->flags & GNTMAP_readonly) ? (*rdc)++ : (*wrc)++;
     }
+
+    spin_unlock(&lgt->maptrack_lock);
 }
 
 /*
@@ -570,7 +603,6 @@ __gnttab_map_grant_ref(
     struct page_info *pg = NULL;
     int            rc = GNTST_okay;
     u32            old_pin;
-    u32            act_pin;
     unsigned int   cache_flags;
     struct active_grant_entry *act = NULL;
     struct grant_mapping *mt;
@@ -633,7 +665,7 @@ __gnttab_map_grant_ref(
     if ( unlikely(op->ref >= nr_grant_entries(rgt)))
         PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref (%d).\n", op->ref);
 
-    act = &active_entry(rgt, op->ref);
+    act = active_entry_acquire(rgt, op->ref);
     shah = shared_entry_header(rgt, op->ref);
     if (rgt->gt_version == 1) {
         sha1 = &shared_entry_v1(rgt, op->ref);
@@ -650,7 +682,7 @@ __gnttab_map_grant_ref(
          ((act->domid != ld->domain_id) ||
           (act->pin & 0x80808080U) != 0 ||
           (act->is_sub_page)) )
-        PIN_FAIL(unlock_out, GNTST_general_error,
+        PIN_FAIL(act_release_out, GNTST_general_error,
                  "Bad domain (%d != %d), or risk of counter overflow %08x, or subpage %d\n",
                  act->domid, ld->domain_id, act->pin, act->is_sub_page);
 
@@ -661,7 +693,7 @@ __gnttab_map_grant_ref(
         if ( (rc = _set_status(rgt->gt_version, ld->domain_id,
                                op->flags & GNTMAP_readonly,
                                1, shah, act, status) ) != GNTST_okay )
-             goto unlock_out;
+            goto act_release_out;
 
         if ( !act->pin )
         {
@@ -692,12 +724,9 @@ __gnttab_map_grant_ref(
             GNTPIN_hstr_inc : GNTPIN_hstw_inc;
 
     frame = act->frame;
-    act_pin = act->pin;
 
     cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
-    read_unlock(&rgt->lock);
-
     /* pg may be set, with a refcount included, from __get_paged_frame */
     if ( !pg )
     {
@@ -772,8 +801,6 @@ __gnttab_map_grant_ref(
         goto undo_out;
     }
 
-    double_gt_lock(lgt, rgt);
-
     if ( gnttab_need_iommu_mapping(ld) )
     {
         unsigned int wrc, rdc;
@@ -781,21 +808,20 @@ __gnttab_map_grant_ref(
         /* We're not translated, so we know that gmfns and mfns are
            the same things, so the IOMMU entry is always 1-to-1. */
         mapcount(lgt, rd, frame, &wrc, &rdc);
-        if ( (act_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
+        if ( (act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
              !(old_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
         {
             if ( wrc == 0 )
                 err = iommu_map_page(ld, frame, frame,
                                      IOMMUF_readable|IOMMUF_writable);
         }
-        else if ( act_pin && !old_pin )
+        else if ( act->pin && !old_pin )
         {
             if ( (wrc + rdc) == 0 )
                 err = iommu_map_page(ld, frame, frame, IOMMUF_readable);
         }
         if ( err )
         {
-            double_gt_unlock(lgt, rgt);
             rc = GNTST_general_error;
             goto undo_out;
         }
@@ -808,7 +834,8 @@ __gnttab_map_grant_ref(
     mt->ref   = op->ref;
     mt->flags = op->flags;
 
-    double_gt_unlock(lgt, rgt);
+    active_entry_release(act);
+    read_unlock(&rgt->lock);
 
     op->dev_bus_addr = (u64)frame << PAGE_SHIFT;
     op->handle       = handle;
@@ -831,10 +858,6 @@ __gnttab_map_grant_ref(
         put_page(pg);
     }
 
-    read_lock(&rgt->lock);
-
-    act = &active_entry(rgt, op->ref);
-
     if ( op->flags & GNTMAP_device_map )
         act->pin -= (op->flags & GNTMAP_readonly) ?
             GNTPIN_devr_inc : GNTPIN_devw_inc;
@@ -850,6 +873,9 @@ __gnttab_map_grant_ref(
     if ( !act->pin )
         gnttab_clear_flag(_GTF_reading, status);
 
+ act_release_out:
+    active_entry_release(act);
+
  unlock_out:
     read_unlock(&rgt->lock);
     op->status = rc;
@@ -891,9 +917,9 @@ __gnttab_unmap_common(
     ld = current->domain;
     lgt = ld->grant_table;
 
-    read_lock(&lgt->lock);
     op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
 
+    read_lock(&lgt->lock);
     if ( unlikely(op->handle >= lgt->maptrack_limit) )
     {
         read_unlock(&lgt->lock);
@@ -933,19 +959,18 @@ __gnttab_unmap_common(
     TRACE_1D(TRC_MEM_PAGE_GRANT_UNMAP, dom);
 
     rgt = rd->grant_table;
-    double_gt_lock(lgt, rgt);
 
     op->flags = op->map->flags;
     if ( unlikely(!op->flags) || unlikely(op->map->domid != dom) )
     {
         gdprintk(XENLOG_WARNING, "Unstable handle %u\n", op->handle);
         rc = GNTST_bad_handle;
-        goto unmap_out;
+        goto unlock_out;
     }
 
     op->rd = rd;
     read_lock(&rgt->lock);
-    act = &active_entry(rgt, op->map->ref);
+    act = active_entry_acquire(rgt, op->map->ref);
 
     if ( op->frame == 0 )
     {
@@ -954,7 +979,7 @@ __gnttab_unmap_common(
     else
     {
         if ( unlikely(op->frame != act->frame) )
-            PIN_FAIL(unmap_out, GNTST_general_error,
+            PIN_FAIL(act_release_out, GNTST_general_error,
                      "Bad frame number doesn't match gntref. (%lx != %lx)\n",
                      op->frame, act->frame);
         if ( op->flags & GNTMAP_device_map )
@@ -973,7 +998,7 @@ __gnttab_unmap_common(
         if ( (rc = replace_grant_host_mapping(op->host_addr,
                                               op->frame, op->new_addr, 
                                               op->flags)) < 0 )
-            goto unmap_out;
+            goto act_release_out;
 
         ASSERT(act->pin & (GNTPIN_hstw_mask | GNTPIN_hstr_mask));
         op->map->flags &= ~GNTMAP_host_map;
@@ -995,7 +1020,7 @@ __gnttab_unmap_common(
         if ( err )
         {
             rc = GNTST_general_error;
-            goto unmap_out;
+            goto act_release_out;
         }
     }
 
@@ -1003,9 +1028,11 @@ __gnttab_unmap_common(
     if ( !(op->flags & GNTMAP_readonly) )
          gnttab_mark_dirty(rd, op->frame);
 
- unmap_out:
-    double_gt_unlock(lgt, rgt);
+ act_release_out:
+    active_entry_release(act);
     read_unlock(&rgt->lock);
+
+ unlock_out:
     op->status = rc;
     rcu_unlock_domain(rd);
 }
@@ -1038,9 +1065,9 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
 
     read_lock(&rgt->lock);
     if ( rgt->gt_version == 0 )
-        goto unmap_out;
+        goto unlock_out;
 
-    act = &active_entry(rgt, op->map->ref);
+    act = active_entry_acquire(rgt, op->map->ref);
     sha = shared_entry_header(rgt, op->map->ref);
 
     if ( rgt->gt_version == 1 )
@@ -1054,7 +1081,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
          * Suggests that __gntab_unmap_common failed early and so
          * nothing further to do
          */
-        goto unmap_out;
+        goto act_release_out;
     }
 
     pg = mfn_to_page(op->frame);
@@ -1078,7 +1105,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
              * Suggests that __gntab_unmap_common failed in
              * replace_grant_host_mapping() so nothing further to do
              */
-            goto unmap_out;
+            goto act_release_out;
         }
 
         if ( !is_iomem_page(op->frame) ) 
@@ -1099,8 +1126,12 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
     if ( act->pin == 0 )
         gnttab_clear_flag(_GTF_reading, status);
 
- unmap_out:
+ act_release_out:
+    active_entry_release(act);
+    
+ unlock_out:
     read_unlock(&rgt->lock);
+
     if ( put_handle )
     {
         op->map->flags = 0;
@@ -1295,7 +1326,7 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
     /* d's grant table write lock must be held by the caller */
 
     struct grant_table *gt = d->grant_table;
-    unsigned int i;
+    unsigned int i, j;
 
     ASSERT(req_nr_frames <= max_grant_frames);
 
@@ -1310,6 +1341,10 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
         if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
             goto active_alloc_failed;
         clear_page(gt->active[i]);
+        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+        {
+            spin_lock_init(&gt->active[i][j].lock);
+        }
     }
 
     /* Shared */
@@ -1804,7 +1839,7 @@ __release_grant_for_copy(
 
     read_lock(&rgt->lock);
 
-    act = &active_entry(rgt, gref);
+    act = active_entry_acquire(rgt, gref);
     sha = shared_entry_header(rgt, gref);
     r_frame = act->frame;
 
@@ -1843,6 +1878,7 @@ __release_grant_for_copy(
         released_read = 1;
     }
 
+    active_entry_release(act);
     read_unlock(&rgt->lock);
 
     if ( td != rd )
@@ -1904,14 +1940,14 @@ __acquire_grant_for_copy(
     read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
-        PIN_FAIL(unlock_out, GNTST_general_error,
+        PIN_FAIL(gnt_unlock_out, GNTST_general_error,
                  "remote grant table not ready\n");
 
     if ( unlikely(gref >= nr_grant_entries(rgt)) )
-        PIN_FAIL(unlock_out, GNTST_bad_gntref,
+        PIN_FAIL(gnt_unlock_out, GNTST_bad_gntref,
                  "Bad grant reference %ld\n", gref);
 
-    act = &active_entry(rgt, gref);
+    act = active_entry_acquire(rgt, gref);
     shah = shared_entry_header(rgt, gref);
     if ( rgt->gt_version == 1 )
     {
@@ -1974,6 +2010,7 @@ __acquire_grant_for_copy(
             /* __acquire_grant_for_copy() could take the read lock on
              * the right table (if rd == td), so we have to drop the
              * lock here and reacquire */
+            active_entry_release(act);
             read_unlock(&rgt->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd->domain_id,
@@ -1981,8 +2018,11 @@ __acquire_grant_for_copy(
                                           &trans_page_off, &trans_length, 0);
 
             read_lock(&rgt->lock);
+            act = active_entry_acquire(rgt, gref);
+
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_copy_pin(act, status);
+                active_entry_release(act);
                 read_unlock(&rgt->lock);
                 rcu_unlock_domain(td);
                 return rc;
@@ -1996,6 +2036,7 @@ __acquire_grant_for_copy(
             {
                 __fixup_status_for_copy_pin(act, status);
                 rcu_unlock_domain(td);
+                active_entry_release(act);
                 read_unlock(&rgt->lock);
                 put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ldom, readonly,
@@ -2064,6 +2105,7 @@ __acquire_grant_for_copy(
     *length = act->length;
     *frame = act->frame;
 
+    active_entry_release(act);
     read_unlock(&rgt->lock);
     return rc;
  
@@ -2076,6 +2118,9 @@ __acquire_grant_for_copy(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
+    active_entry_release(act);
+
+ gnt_unlock_out:
     read_unlock(&rgt->lock);
     return rc;
 }
@@ -2259,16 +2304,18 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     {
         for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
-            act = &active_entry(gt, i);
+            act = active_entry_acquire(gt, i);
             if ( act->pin != 0 )
             {
                 gdprintk(XENLOG_WARNING,
                          "tried to change grant table version from %d to %d, but some grant entries still in use\n",
                          gt->gt_version,
                          op.version);
+                active_entry_release(act);
                 res = -EBUSY;
                 goto out_unlock;
             }
+            active_entry_release(act);
         }
     }
 
@@ -2447,7 +2494,8 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
 {
     struct domain *d = rcu_lock_current_domain();
     struct grant_table *gt = d->grant_table;
-    struct active_grant_entry *act;
+    struct active_grant_entry *act_a = NULL;
+    struct active_grant_entry *act_b = NULL;
     s16 rc = GNTST_okay;
 
     read_lock(&gt->lock);
@@ -2458,12 +2506,12 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     if ( unlikely(ref_b >= nr_grant_entries(d->grant_table)))
         PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-b (%d).\n", ref_b);
 
-    act = &active_entry(gt, ref_a);
-    if ( act->pin )
+    act_a = active_entry_acquire(gt, ref_a);
+    if ( act_a->pin )
         PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
 
-    act = &active_entry(gt, ref_b);
-    if ( act->pin )
+    act_b = active_entry_acquire(gt, ref_b);
+    if ( act_b->pin )
         PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
 
     if ( gt->gt_version == 1 )
@@ -2490,8 +2538,11 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     }
 
 out:
+    if ( act_b != NULL )
+        active_entry_release(act_b);
+    if ( act_a != NULL )
+        active_entry_release(act_a);
     read_unlock(&gt->lock);
-
     rcu_unlock_domain(d);
 
     return rc;
@@ -2807,7 +2858,7 @@ grant_table_create(
     struct domain *d)
 {
     struct grant_table *t;
-    int                 i;
+    int                 i, j;
 
     if ( (t = xzalloc(struct grant_table)) == NULL )
         goto no_mem_0;
@@ -2827,6 +2878,10 @@ grant_table_create(
         if ( (t->active[i] = alloc_xenheap_page()) == NULL )
             goto no_mem_2;
         clear_page(t->active[i]);
+        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+        {
+            spin_lock_init(&t->active[i][j].lock);
+        }
     }
 
     /* Tracking of mapped foreign frames table */
@@ -2923,7 +2978,7 @@ gnttab_release_mappings(
         rgt = rd->grant_table;
         read_lock(&rgt->lock);
 
-        act = &active_entry(rgt, ref);
+        act = active_entry_acquire(rgt, ref);
         sha = shared_entry_header(rgt, ref);
         if (rgt->gt_version == 1)
             status = &sha->flags;
@@ -2981,6 +3036,7 @@ gnttab_release_mappings(
         if ( act->pin == 0 )
             gnttab_clear_flag(_GTF_reading, status);
 
+        active_entry_release(act);
         read_unlock(&rgt->lock);
 
         rcu_unlock_domain(rd);
@@ -3001,7 +3057,7 @@ grant_table_destroy(
         return;
 
     write_lock(&t->lock);
-    
+
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
     xfree(t->shared_raw);
@@ -3047,9 +3103,11 @@ static void gnttab_usage_print(struct domain *rd)
         uint16_t status;
         uint64_t frame;
 
-        act = &active_entry(gt, ref);
-        if ( !act->pin )
+        act = active_entry_acquire(gt, ref);
+        if ( !act->pin ) {
+            active_entry_release(act);
             continue;
+        }
 
         sha = shared_entry_header(gt, ref);
 
@@ -3079,6 +3137,7 @@ static void gnttab_usage_print(struct domain *rd)
         printk("[%3d]    %5d 0x%06lx 0x%08x      %5d 0x%06"PRIx64" 0x%02x\n",
                ref, act->domid, act->frame, act->pin,
                sha->domid, frame, status);
+        active_entry_release(act);
     }
 
  out:
-- 
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 Dec 02 10:07:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkMU-0001RO-3D; Tue, 02 Dec 2014 10:07:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1XvkMS-0001Qk-6I
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:07:12 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	4B/AA-17735-A4F8D745; Tue, 02 Dec 2014 10:07:06 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417514824!12760806!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMjA0MDI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 472 invoked from network); 2 Dec 2014 10:07:06 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 10:07:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417514826; x=1449050826;
	h=from:to:subject:date:message-id:mime-version;
	bh=J+pbe/XL+HH4PwTHiLAZiBkniTjACSSrC3OY/zv8L1Q=;
	b=d5tIudZ8w2iqvbbetSUtSje1IC+8uGSHui+yWnVfezDlmnHISHTq7NEa
	S7+T4ahSXIpgQw359X874yZiSMorFPWhj+yy6NozU0HDObav7Q7tItHDc
	dVJmQdFykC53lYuHsVC3tRtkJu3dxjIxU0BOfo9NF0URvw7wxWempDRWv 4=;
X-IronPort-AV: E=Sophos;i="5.07,499,1413244800"; d="scan'208";a="150586336"
Received: from smtp-in-7002.iad7.amazon.com ([10.229.167.11])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 10:07:03 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com
	[10.0.103.146])
	by smtp-in-7002.iad7.amazon.com (8.14.7/8.14.7) with ESMTP id
	sB2A70Yh020895
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Tue, 2 Dec 2014 10:07:02 GMT
Received: from EX13D05UWC001.ant.amazon.com (10.43.162.82) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 02:07:01 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.162.149) by
	EX13D05UWC001.ant.amazon.com (10.43.162.82) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 10:06:59 +0000
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 11:06:22 +0100
Message-ID: <1417514784-15749-1-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D05UWC001.ant.amazon.com (10.43.162.82) To
	EX13D05UWC001.ant.amazon.com (10.43.162.82)
Precedence: Bulk
Subject: [Xen-devel] [PATCH 0/2] gnttab: Improve scaleability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 changes the grant table locking to
a more fain grained locking protocol. The result is
a performance boost measured with blkfront/blkback.
Document the locking protocol.

[PATCH 1/2] gnttab: Introduce rwlock to protect updates to grant
[PATCH 2/2] gnttab: refactor locking for scalability

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 10:10:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkPQ-0001qF-GA; Tue, 02 Dec 2014 10:10: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 1XvkPP-0001q3-Cf
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 10:10:15 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	51/12-16982-6009D745; Tue, 02 Dec 2014 10:10:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417515013!15214702!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25418 invoked from network); 2 Dec 2014 10:10:14 -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; 2 Dec 2014 10:10:14 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 10:10:13 +0000
Message-Id: <547D9E13020000780004C0B3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 10:10:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: bhelgaas@google.com, linux@eikelenboom.it, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [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>
Content-Type: text/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:17, <konrad.wilk@oracle.com> wrote:
> 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.

So my "xen-pciback: drop SR-IOV VFs when PF driver unloads" isn't
among them, nor is there any alternative. What's the status of that
patch (or the problem that prompted its creation)?

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 10:10:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkPQ-0001qF-GA; Tue, 02 Dec 2014 10:10: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 1XvkPP-0001q3-Cf
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 10:10:15 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	51/12-16982-6009D745; Tue, 02 Dec 2014 10:10:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417515013!15214702!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25418 invoked from network); 2 Dec 2014 10:10:14 -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; 2 Dec 2014 10:10:14 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 10:10:13 +0000
Message-Id: <547D9E13020000780004C0B3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 10:10:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: bhelgaas@google.com, linux@eikelenboom.it, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [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>
Content-Type: text/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:17, <konrad.wilk@oracle.com> wrote:
> 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.

So my "xen-pciback: drop SR-IOV VFs when PF driver unloads" isn't
among them, nor is there any alternative. What's the status of that
patch (or the problem that prompted its creation)?

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 10:23:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvkbM-00029l-O2; Tue, 02 Dec 2014 10:22:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XvkbL-00029g-Ql
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:22:36 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	35/C9-02702-6E29D745; Tue, 02 Dec 2014 10:22:30 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417515745!6988503!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 17429 invoked from network); 2 Dec 2014 10:22:26 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-27.messagelabs.com with SMTP;
	2 Dec 2014 10:22:26 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2014 02:22:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,500,1413270000"; d="scan'208";a="631281162"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2014 02:11:32 -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, 2 Dec 2014 18:11:32 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Tue, 2 Dec 2014 18:11:31 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 16/17] xen/vtd: group assigned device with RMRR
Thread-Index: AQHQDUmafTrQG0f+c0+V2DX2TcnI5Jx8E9Zg
Date: Tue, 2 Dec 2014 10:11:30 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610ADCA@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-17-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-17-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 16/17] xen/vtd: group assigned device
	with RMRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Monday, December 01, 2014 5:25 PM
> 
> Sometimes different devices may share RMRR range so in this
> case we shouldn't assign these devices into different VMs
> since they may have potential leakage even damage between VMs.
> 
> So we need to group all devices as RMRR range to make sure they
> are just assigned into the same VM.
> 
> Here we introduce two field, gid and domid, in struct,
> acpi_rmrr_unit:
>  gid: indicate which group this device owns. "0" is invalid so
>       just start from "1".
>  domid: indicate which domain this device owns currently. Firstly
>         the hardware domain should own it.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/drivers/passthrough/vtd/dmar.c  | 28 ++++++++++++++-
>  xen/drivers/passthrough/vtd/dmar.h  |  2 ++
>  xen/drivers/passthrough/vtd/iommu.c | 68
> +++++++++++++++++++++++++++++++++----
>  3 files changed, 91 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/dmar.c
> b/xen/drivers/passthrough/vtd/dmar.c
> index c5bc8d6..8d3406f 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -572,10 +572,11 @@ acpi_parse_one_rmrr(struct acpi_dmar_header
> *header)
>  {
>      struct acpi_dmar_reserved_memory *rmrr =
>          container_of(header, struct acpi_dmar_reserved_memory,
> header);
> -    struct acpi_rmrr_unit *rmrru;
> +    struct acpi_rmrr_unit *rmrru, *cur_rmrr;
>      void *dev_scope_start, *dev_scope_end;
>      u64 base_addr = rmrr->base_address, end_addr = rmrr->end_address;
>      int ret;
> +    static unsigned int group_id = 0;
> 
>      if ( (ret = acpi_dmar_check_length(header, sizeof(*rmrr))) != 0 )
>          return ret;
> @@ -611,6 +612,8 @@ acpi_parse_one_rmrr(struct acpi_dmar_header
> *header)
>      rmrru->base_address = base_addr;
>      rmrru->end_address = end_addr;
>      rmrru->segment = rmrr->segment;
> +    /* "0" is an invalid group id. */
> +    rmrru->gid = 0;
> 
>      dev_scope_start = (void *)(rmrr + 1);
>      dev_scope_end   = ((void *)rmrr) + header->length;
> @@ -682,7 +685,30 @@ acpi_parse_one_rmrr(struct acpi_dmar_header
> *header)
>                      "So please set pci_rdmforce to reserve these ranges"
>                      " if you need such a device in hotplug case.\n");
> 
> +            list_for_each_entry(cur_rmrr, &acpi_rmrr_units, list)
> +            {
> +                /*
> +                 * Any same or overlap range mean they should be
> +                 * at same group.
> +                 */
> +                if ( ((base_addr >= cur_rmrr->base_address) &&
> +                     (end_addr <= cur_rmrr->end_address)) ||
> +                     ((base_addr <= cur_rmrr->base_address) &&
> +                     (end_addr >= cur_rmrr->end_address)) )

again, such overlap detection pattern is incomplete.

> +                {
> +                    rmrru->gid = cur_rmrr->gid;
> +                    continue;
> +                }
> +            }
> +
>              acpi_register_rmrr_unit(rmrru);
> +
> +            /* Allocate group id from gid:1. */
> +            if ( !rmrru->gid )
> +            {
> +                group_id++;
> +                rmrru->gid = group_id;
> +            }
>          }
>      }
> 
> diff --git a/xen/drivers/passthrough/vtd/dmar.h
> b/xen/drivers/passthrough/vtd/dmar.h
> index af1feef..a57c0d4 100644
> --- a/xen/drivers/passthrough/vtd/dmar.h
> +++ b/xen/drivers/passthrough/vtd/dmar.h
> @@ -76,6 +76,8 @@ struct acpi_rmrr_unit {
>      u64    end_address;
>      u16    segment;
>      u8     allow_all:1;
> +    int    gid;
> +    domid_t    domid;
>  };
> 
>  struct acpi_atsr_unit {
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index a54c6eb..ba40209 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1882,9 +1882,9 @@ static int rmrr_identity_mapping(struct domain *d,
> bool_t map,
> 
>  static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
>  {
> -    struct acpi_rmrr_unit *rmrr;
> -    u16 bdf;
> -    int ret, i;
> +    struct acpi_rmrr_unit *rmrr, *g_rmrr;
> +    u16 bdf, g_bdf;
> +    int ret, i, j;
> 
>      ASSERT(spin_is_locked(&pcidevs_lock));
> 
> @@ -1905,6 +1905,32 @@ static int intel_iommu_add_device(u8 devfn, struct
> pci_dev *pdev)
>               PCI_BUS(bdf) == pdev->bus &&
>               PCI_DEVFN2(bdf) == devfn )
>          {
> +            if ( rmrr->domid == hardware_domain->domain_id )
> +            {
> +                for_each_rmrr_device ( g_rmrr, g_bdf, j )
> +                {
> +                    if ( g_rmrr->gid == rmrr->gid )
> +                    {
> +                        if ( g_rmrr->domid ==
> hardware_domain->domain_id )
> +                            g_rmrr->domid =
> pdev->domain->domain_id;
> +                        else if ( g_rmrr->domid !=
> pdev->domain->domain_id )
> +                        {
> +                            rmrr->domid = g_rmrr->domid;
> +                            continue;
> +                        }
> +                    }
> +                }
> +            }
> +
> +            if ( rmrr->domid != pdev->domain->domain_id )
> +            {
> +                domain_context_unmap(pdev->domain, devfn, pdev);
> +                dprintk(XENLOG_ERR VTDPREFIX, "d%d: this is a group
> device owned by d%d\n",
> +                        pdev->domain->domain_id, rmrr->domid);
> +                rmrr->domid = 0;

0 or release to hardware domain?

> +                return -EINVAL;
> +            }
> +
>              ret = rmrr_identity_mapping(pdev->domain, 1, rmrr);
>              if ( ret )
>                  dprintk(XENLOG_ERR VTDPREFIX, "d%d: RMRR mapping
> failed\n",
> @@ -1946,6 +1972,8 @@ static int intel_iommu_remove_device(u8 devfn,
> struct pci_dev *pdev)
>               PCI_DEVFN2(bdf) != devfn )
>              continue;
> 
> +        /* Just release to hardware domain. */
> +        rmrr->domid = hardware_domain->domain_id;
>          rmrr_identity_mapping(pdev->domain, 0, rmrr);
>      }
> 
> @@ -2104,6 +2132,8 @@ static void __hwdom_init setup_hwdom_rmrr(struct
> domain *d)
>      spin_lock(&pcidevs_lock);
>      for_each_rmrr_device ( rmrr, bdf, i )
>      {
> +        /* hwdom should own all devices at first. */
> +        rmrr->domid = d->domain_id;
>          ret = rmrr_identity_mapping(d, 1, rmrr);
>          if ( ret )
>              dprintk(XENLOG_ERR VTDPREFIX,
> @@ -2273,9 +2303,9 @@ static int reassign_device_ownership(
>  static int intel_iommu_assign_device(
>      struct domain *d, u8 devfn, struct pci_dev *pdev)
>  {
> -    struct acpi_rmrr_unit *rmrr;
> -    int ret = 0, i;
> -    u16 bdf, seg;
> +    struct acpi_rmrr_unit *rmrr, *g_rmrr;
> +    int ret = 0, i, j;
> +    u16 bdf, seg, g_bdf;
>      u8 bus;
> 
>      if ( list_empty(&acpi_drhd_units) )
> @@ -2300,6 +2330,32 @@ static int intel_iommu_assign_device(
>               PCI_BUS(bdf) == bus &&
>               PCI_DEVFN2(bdf) == devfn )
>          {
> +            if ( rmrr->domid == hardware_domain->domain_id )
> +            {
> +                for_each_rmrr_device ( g_rmrr, g_bdf, j )
> +                {
> +                    if ( g_rmrr->gid == rmrr->gid )
> +                    {
> +                        if ( g_rmrr->domid ==
> hardware_domain->domain_id )
> +                            g_rmrr->domid =
> pdev->domain->domain_id;
> +                        else if ( g_rmrr->domid !=
> pdev->domain->domain_id )
> +                        {
> +                            rmrr->domid = g_rmrr->domid;
> +                            continue;
> +                        }
> +                    }
> +                }
> +            }
> +
> +            if ( rmrr->domid != pdev->domain->domain_id )
> +            {
> +                domain_context_unmap(pdev->domain, devfn, pdev);
> +                dprintk(XENLOG_ERR VTDPREFIX, "d%d: this is a group
> device owned by d%d\n",
> +                        pdev->domain->domain_id, rmrr->domid);
> +                rmrr->domid = 0;
> +                return -EINVAL;
> +            }
> +
>              ret = rmrr_identity_mapping(d, 1, rmrr);
>              if ( ret )
>              {
> --
> 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 Dec 02 10:23:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvkbM-00029l-O2; Tue, 02 Dec 2014 10:22:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XvkbL-00029g-Ql
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:22:36 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	35/C9-02702-6E29D745; Tue, 02 Dec 2014 10:22:30 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417515745!6988503!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 17429 invoked from network); 2 Dec 2014 10:22:26 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-27.messagelabs.com with SMTP;
	2 Dec 2014 10:22:26 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2014 02:22:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,500,1413270000"; d="scan'208";a="631281162"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2014 02:11:32 -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, 2 Dec 2014 18:11:32 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Tue, 2 Dec 2014 18:11:31 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, "jbeulich@suse.com"
	<jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "tim@xen.org" <tim@xen.org>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>
Thread-Topic: [v8][PATCH 16/17] xen/vtd: group assigned device with RMRR
Thread-Index: AQHQDUmafTrQG0f+c0+V2DX2TcnI5Jx8E9Zg
Date: Tue, 2 Dec 2014 10:11:30 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610ADCA@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-17-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-17-git-send-email-tiejun.chen@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: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 16/17] xen/vtd: group assigned device
	with RMRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Monday, December 01, 2014 5:25 PM
> 
> Sometimes different devices may share RMRR range so in this
> case we shouldn't assign these devices into different VMs
> since they may have potential leakage even damage between VMs.
> 
> So we need to group all devices as RMRR range to make sure they
> are just assigned into the same VM.
> 
> Here we introduce two field, gid and domid, in struct,
> acpi_rmrr_unit:
>  gid: indicate which group this device owns. "0" is invalid so
>       just start from "1".
>  domid: indicate which domain this device owns currently. Firstly
>         the hardware domain should own it.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/drivers/passthrough/vtd/dmar.c  | 28 ++++++++++++++-
>  xen/drivers/passthrough/vtd/dmar.h  |  2 ++
>  xen/drivers/passthrough/vtd/iommu.c | 68
> +++++++++++++++++++++++++++++++++----
>  3 files changed, 91 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/dmar.c
> b/xen/drivers/passthrough/vtd/dmar.c
> index c5bc8d6..8d3406f 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -572,10 +572,11 @@ acpi_parse_one_rmrr(struct acpi_dmar_header
> *header)
>  {
>      struct acpi_dmar_reserved_memory *rmrr =
>          container_of(header, struct acpi_dmar_reserved_memory,
> header);
> -    struct acpi_rmrr_unit *rmrru;
> +    struct acpi_rmrr_unit *rmrru, *cur_rmrr;
>      void *dev_scope_start, *dev_scope_end;
>      u64 base_addr = rmrr->base_address, end_addr = rmrr->end_address;
>      int ret;
> +    static unsigned int group_id = 0;
> 
>      if ( (ret = acpi_dmar_check_length(header, sizeof(*rmrr))) != 0 )
>          return ret;
> @@ -611,6 +612,8 @@ acpi_parse_one_rmrr(struct acpi_dmar_header
> *header)
>      rmrru->base_address = base_addr;
>      rmrru->end_address = end_addr;
>      rmrru->segment = rmrr->segment;
> +    /* "0" is an invalid group id. */
> +    rmrru->gid = 0;
> 
>      dev_scope_start = (void *)(rmrr + 1);
>      dev_scope_end   = ((void *)rmrr) + header->length;
> @@ -682,7 +685,30 @@ acpi_parse_one_rmrr(struct acpi_dmar_header
> *header)
>                      "So please set pci_rdmforce to reserve these ranges"
>                      " if you need such a device in hotplug case.\n");
> 
> +            list_for_each_entry(cur_rmrr, &acpi_rmrr_units, list)
> +            {
> +                /*
> +                 * Any same or overlap range mean they should be
> +                 * at same group.
> +                 */
> +                if ( ((base_addr >= cur_rmrr->base_address) &&
> +                     (end_addr <= cur_rmrr->end_address)) ||
> +                     ((base_addr <= cur_rmrr->base_address) &&
> +                     (end_addr >= cur_rmrr->end_address)) )

again, such overlap detection pattern is incomplete.

> +                {
> +                    rmrru->gid = cur_rmrr->gid;
> +                    continue;
> +                }
> +            }
> +
>              acpi_register_rmrr_unit(rmrru);
> +
> +            /* Allocate group id from gid:1. */
> +            if ( !rmrru->gid )
> +            {
> +                group_id++;
> +                rmrru->gid = group_id;
> +            }
>          }
>      }
> 
> diff --git a/xen/drivers/passthrough/vtd/dmar.h
> b/xen/drivers/passthrough/vtd/dmar.h
> index af1feef..a57c0d4 100644
> --- a/xen/drivers/passthrough/vtd/dmar.h
> +++ b/xen/drivers/passthrough/vtd/dmar.h
> @@ -76,6 +76,8 @@ struct acpi_rmrr_unit {
>      u64    end_address;
>      u16    segment;
>      u8     allow_all:1;
> +    int    gid;
> +    domid_t    domid;
>  };
> 
>  struct acpi_atsr_unit {
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index a54c6eb..ba40209 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1882,9 +1882,9 @@ static int rmrr_identity_mapping(struct domain *d,
> bool_t map,
> 
>  static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
>  {
> -    struct acpi_rmrr_unit *rmrr;
> -    u16 bdf;
> -    int ret, i;
> +    struct acpi_rmrr_unit *rmrr, *g_rmrr;
> +    u16 bdf, g_bdf;
> +    int ret, i, j;
> 
>      ASSERT(spin_is_locked(&pcidevs_lock));
> 
> @@ -1905,6 +1905,32 @@ static int intel_iommu_add_device(u8 devfn, struct
> pci_dev *pdev)
>               PCI_BUS(bdf) == pdev->bus &&
>               PCI_DEVFN2(bdf) == devfn )
>          {
> +            if ( rmrr->domid == hardware_domain->domain_id )
> +            {
> +                for_each_rmrr_device ( g_rmrr, g_bdf, j )
> +                {
> +                    if ( g_rmrr->gid == rmrr->gid )
> +                    {
> +                        if ( g_rmrr->domid ==
> hardware_domain->domain_id )
> +                            g_rmrr->domid =
> pdev->domain->domain_id;
> +                        else if ( g_rmrr->domid !=
> pdev->domain->domain_id )
> +                        {
> +                            rmrr->domid = g_rmrr->domid;
> +                            continue;
> +                        }
> +                    }
> +                }
> +            }
> +
> +            if ( rmrr->domid != pdev->domain->domain_id )
> +            {
> +                domain_context_unmap(pdev->domain, devfn, pdev);
> +                dprintk(XENLOG_ERR VTDPREFIX, "d%d: this is a group
> device owned by d%d\n",
> +                        pdev->domain->domain_id, rmrr->domid);
> +                rmrr->domid = 0;

0 or release to hardware domain?

> +                return -EINVAL;
> +            }
> +
>              ret = rmrr_identity_mapping(pdev->domain, 1, rmrr);
>              if ( ret )
>                  dprintk(XENLOG_ERR VTDPREFIX, "d%d: RMRR mapping
> failed\n",
> @@ -1946,6 +1972,8 @@ static int intel_iommu_remove_device(u8 devfn,
> struct pci_dev *pdev)
>               PCI_DEVFN2(bdf) != devfn )
>              continue;
> 
> +        /* Just release to hardware domain. */
> +        rmrr->domid = hardware_domain->domain_id;
>          rmrr_identity_mapping(pdev->domain, 0, rmrr);
>      }
> 
> @@ -2104,6 +2132,8 @@ static void __hwdom_init setup_hwdom_rmrr(struct
> domain *d)
>      spin_lock(&pcidevs_lock);
>      for_each_rmrr_device ( rmrr, bdf, i )
>      {
> +        /* hwdom should own all devices at first. */
> +        rmrr->domid = d->domain_id;
>          ret = rmrr_identity_mapping(d, 1, rmrr);
>          if ( ret )
>              dprintk(XENLOG_ERR VTDPREFIX,
> @@ -2273,9 +2303,9 @@ static int reassign_device_ownership(
>  static int intel_iommu_assign_device(
>      struct domain *d, u8 devfn, struct pci_dev *pdev)
>  {
> -    struct acpi_rmrr_unit *rmrr;
> -    int ret = 0, i;
> -    u16 bdf, seg;
> +    struct acpi_rmrr_unit *rmrr, *g_rmrr;
> +    int ret = 0, i, j;
> +    u16 bdf, seg, g_bdf;
>      u8 bus;
> 
>      if ( list_empty(&acpi_drhd_units) )
> @@ -2300,6 +2330,32 @@ static int intel_iommu_assign_device(
>               PCI_BUS(bdf) == bus &&
>               PCI_DEVFN2(bdf) == devfn )
>          {
> +            if ( rmrr->domid == hardware_domain->domain_id )
> +            {
> +                for_each_rmrr_device ( g_rmrr, g_bdf, j )
> +                {
> +                    if ( g_rmrr->gid == rmrr->gid )
> +                    {
> +                        if ( g_rmrr->domid ==
> hardware_domain->domain_id )
> +                            g_rmrr->domid =
> pdev->domain->domain_id;
> +                        else if ( g_rmrr->domid !=
> pdev->domain->domain_id )
> +                        {
> +                            rmrr->domid = g_rmrr->domid;
> +                            continue;
> +                        }
> +                    }
> +                }
> +            }
> +
> +            if ( rmrr->domid != pdev->domain->domain_id )
> +            {
> +                domain_context_unmap(pdev->domain, devfn, pdev);
> +                dprintk(XENLOG_ERR VTDPREFIX, "d%d: this is a group
> device owned by d%d\n",
> +                        pdev->domain->domain_id, rmrr->domid);
> +                rmrr->domid = 0;
> +                return -EINVAL;
> +            }
> +
>              ret = rmrr_identity_mapping(d, 1, rmrr);
>              if ( ret )
>              {
> --
> 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 Dec 02 10:38:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkqJ-0002Qg-Aj; Tue, 02 Dec 2014 10:38:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XvkqH-0002Qb-8H
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:38:01 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8F/CF-09842-8869D745; Tue, 02 Dec 2014 10:38:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417516679!4779069!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 3903 invoked from network); 2 Dec 2014 10:38:00 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 10:38:00 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xvkpr-000G5W-OX; Tue, 02 Dec 2014 10:37:35 +0000
Date: Tue, 2 Dec 2014 11:37:35 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141202103735.GC69236@deinos.phlegethon.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547C6D98020000780004BB9D@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C6D98020000780004BB9D@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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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

At 12:31 +0000 on 01 Dec (1417433464), Jan Beulich wrote:
> >>> On 01.12.14 at 13:13, <tim@xen.org> wrote:
> > At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
> >> >>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
> >> > At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
> >> >> >>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
> >> >> > To my understanding, pages with p2m_ram_ro are not supposed to be 
> >> >> > modified by guest. So in __hvm_copy(), when p2m type of a page is 
> >> >> > p2m_ram_rom, no copy will occur.
> >> >> > However, to our usage, we just wanna this page to be write protected, so 
> >> >> > that our device model can be triggered to do some emulation. The content 
> >> >> > written to this page is supposed not to be dropped. This way, if 
> >> >> > sequentially a read operation is performed by guest to this page, the 
> >> >> > guest will still see its anticipated value.
> >> >> 
> >> >> __hvm_copy() is only a helper function, and doesn't write to
> >> >> mmio_dm space either; instead its (indirect) callers would invoke
> >> >> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
> >> >> returns. The question hence is about the apparent inconsistency
> >> >> resulting from writes to ram_ro being dropped here but getting
> >> >> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
> >> >> that really intentional?
> >> > 
> >> > No - and AFAICT it shouldn't be happening.  It _is_ how it was
> >> > implemented originally, because it involved fewer moving parts and
> >> > didn't need to be efficient (and after all, writes to entirely missing
> >> > addresses go to the device model too).
> >> > 
> >> > But the code was later updated to log and discard writes to read-only
> >> > memory (see 4d8aa29 from Trolle Selander).
> >> > 
> >> > Early version of p2m_ram_ro were documented in the internal headers as
> >> > sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
> >> > has always said that writes are discarded.
> >> 
> >> Hmm, so which way do you recommend resolving the inconsistency
> >> then - match what the public interface says or what the apparent
> >> original intention for the internal type was? Presumably we need to
> >> follow the public interface mandated model, and hence require the
> >> new type to be introduced.
> > 
> > Sorry, I was unclear -- there isn't an inconsistency; both internal
> > and public headers currently say that writes are discarded and AFAICT
> > that is what the code does.
> 
> Not for hvm_hap_nested_page_fault() afaict - the forwarding to
> DM there contradicts the "writes are discarded" model that other
> code paths follow.

It calls handle_mmio() to emulate the instruction for it, but
handle_mmio() ought not to send anything to the DM.  hvmemul_write()
will call hvm_copy(), which will drop the write and report success.

The shadow code has its own emulator framework for emulting PT writes,
which does much the same thing.

Tim.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 10:38:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10: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 1XvkqJ-0002Qg-Aj; Tue, 02 Dec 2014 10:38:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XvkqH-0002Qb-8H
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:38:01 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8F/CF-09842-8869D745; Tue, 02 Dec 2014 10:38:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417516679!4779069!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 3903 invoked from network); 2 Dec 2014 10:38:00 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 10:38:00 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xvkpr-000G5W-OX; Tue, 02 Dec 2014 10:37:35 +0000
Date: Tue, 2 Dec 2014 11:37:35 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141202103735.GC69236@deinos.phlegethon.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547C6D98020000780004BB9D@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C6D98020000780004BB9D@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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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

At 12:31 +0000 on 01 Dec (1417433464), Jan Beulich wrote:
> >>> On 01.12.14 at 13:13, <tim@xen.org> wrote:
> > At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
> >> >>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
> >> > At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
> >> >> >>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
> >> >> > To my understanding, pages with p2m_ram_ro are not supposed to be 
> >> >> > modified by guest. So in __hvm_copy(), when p2m type of a page is 
> >> >> > p2m_ram_rom, no copy will occur.
> >> >> > However, to our usage, we just wanna this page to be write protected, so 
> >> >> > that our device model can be triggered to do some emulation. The content 
> >> >> > written to this page is supposed not to be dropped. This way, if 
> >> >> > sequentially a read operation is performed by guest to this page, the 
> >> >> > guest will still see its anticipated value.
> >> >> 
> >> >> __hvm_copy() is only a helper function, and doesn't write to
> >> >> mmio_dm space either; instead its (indirect) callers would invoke
> >> >> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
> >> >> returns. The question hence is about the apparent inconsistency
> >> >> resulting from writes to ram_ro being dropped here but getting
> >> >> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
> >> >> that really intentional?
> >> > 
> >> > No - and AFAICT it shouldn't be happening.  It _is_ how it was
> >> > implemented originally, because it involved fewer moving parts and
> >> > didn't need to be efficient (and after all, writes to entirely missing
> >> > addresses go to the device model too).
> >> > 
> >> > But the code was later updated to log and discard writes to read-only
> >> > memory (see 4d8aa29 from Trolle Selander).
> >> > 
> >> > Early version of p2m_ram_ro were documented in the internal headers as
> >> > sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
> >> > has always said that writes are discarded.
> >> 
> >> Hmm, so which way do you recommend resolving the inconsistency
> >> then - match what the public interface says or what the apparent
> >> original intention for the internal type was? Presumably we need to
> >> follow the public interface mandated model, and hence require the
> >> new type to be introduced.
> > 
> > Sorry, I was unclear -- there isn't an inconsistency; both internal
> > and public headers currently say that writes are discarded and AFAICT
> > that is what the code does.
> 
> Not for hvm_hap_nested_page_fault() afaict - the forwarding to
> DM there contradicts the "writes are discarded" model that other
> code paths follow.

It calls handle_mmio() to emulate the instruction for it, but
handle_mmio() ought not to send anything to the DM.  hvmemul_write()
will call hvm_copy(), which will drop the write and report success.

The shadow code has its own emulator framework for emulting PT writes,
which does much the same thing.

Tim.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 10:54:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvl5q-0002j0-Rz; Tue, 02 Dec 2014 10:54:06 +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 1Xvl5q-0002iv-F2
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 10:54:06 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	B6/E6-07724-D4A9D745; Tue, 02 Dec 2014 10:54:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417517643!15199180!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15568 invoked from network); 2 Dec 2014 10:54:05 -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;
	2 Dec 2014 10:54:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198791611"
Message-ID: <547D9A4A.6010201@citrix.com>
Date: Tue, 2 Dec 2014 10:54:02 +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: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <547D88EF.4050206@suse.com>
In-Reply-To: <547D88EF.4050206@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/12/14 09:39, Juergen Gross wrote:
> Hi,
> 
> looking into the upstream linux sources I realized that the PVHVM
> drivers of XEN are only available with the pvops kernel. Is this on
> purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
> configurable without having to enable CONFIG_PARAVIRT?

I suppose that would be possible but I don't think it's a useful
configuration because you would lose PV spinlocks for example.

David

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 10:54:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvl5q-0002j0-Rz; Tue, 02 Dec 2014 10:54:06 +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 1Xvl5q-0002iv-F2
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 10:54:06 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	B6/E6-07724-D4A9D745; Tue, 02 Dec 2014 10:54:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417517643!15199180!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15568 invoked from network); 2 Dec 2014 10:54:05 -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;
	2 Dec 2014 10:54:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198791611"
Message-ID: <547D9A4A.6010201@citrix.com>
Date: Tue, 2 Dec 2014 10:54:02 +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: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <547D88EF.4050206@suse.com>
In-Reply-To: <547D88EF.4050206@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/12/14 09:39, Juergen Gross wrote:
> Hi,
> 
> looking into the upstream linux sources I realized that the PVHVM
> drivers of XEN are only available with the pvops kernel. Is this on
> purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
> configurable without having to enable CONFIG_PARAVIRT?

I suppose that would be possible but I don't think it's a useful
configuration because you would lose PV spinlocks for example.

David

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 10:55:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvl71-0002mn-Ao; Tue, 02 Dec 2014 10:55: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 1Xvl70-0002md-5B
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 10:55:18 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	5F/02-24124-59A9D745; Tue, 02 Dec 2014 10:55:17 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417517713!11070279!1
X-Originating-IP: [66.165.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 18583 invoked from network); 2 Dec 2014 10:55:15 -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;
	2 Dec 2014 10:55:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198460252"
Received: from ukmail1.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, 2 Dec 2014 05:55: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 1Xvl6u-0005ao-Nn;
	Tue, 02 Dec 2014 10:55:12 +0000
Date: Tue, 2 Dec 2014 10:55:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <547D9B05020000780004C07B@mail.emea.novell.com>
Message-ID: <alpine.DEB.2.02.1412021052170.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>
	<alpine.DEB.2.02.1412011852390.14135@kaball.uk.xensource.com>
	<547D9B05020000780004C07B@mail.emea.novell.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 Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, linux@eikelenboom.it,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] call xc_domain_irq_permission
 before xc_domain_irq_permission
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2 Dec 2014, Jan Beulich wrote:
> >>> On 01.12.14 at 20:22, <stefano.stabellini@eu.citrix.com> wrote:
> > xc_physdev_unmap_pirq might revoke the permission to map the irq from
> > the domain causing the following xc_domain_irq_permission call to fail
> > and return error (domain_pirq_to_irq returns 0).
> 
> Apart from the patch title being rather confusing, isn't the root
> problem then xc_physdev_unmap_pirq() removes permissions? At
> least after the strict splitting of permission granting and mapping for
> MMIO (commit 0561e1f0) it would seem that if the underlying
> hypercall here behaves similarly to the original behavior there, it
> ought to be fixed in an analogous way.

The big difference is that 0561e1f0 makes XEN_DOMCTL_memory_mapping
stricker, while you are suggesting to make xc_physdev_unmap_pirq laxer.

Are you sure that is a good idea? What if a third party caller of
xc_physdev_unmap_pirq relies on that behaviour?


 
> > Call xc_domain_irq_permission first to prevent this from happening
> > (xc_physdev_unmap_pirq calls irq_deny_access, that doesn't fail if the
> > permission is already removed).
> > 
> > This is a simple bug fix and I think should go in 4.5.
> > 
> > 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..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 
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 10:55:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10:55:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvl71-0002mn-Ao; Tue, 02 Dec 2014 10:55: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 1Xvl70-0002md-5B
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 10:55:18 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	5F/02-24124-59A9D745; Tue, 02 Dec 2014 10:55:17 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417517713!11070279!1
X-Originating-IP: [66.165.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 18583 invoked from network); 2 Dec 2014 10:55:15 -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;
	2 Dec 2014 10:55:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198460252"
Received: from ukmail1.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, 2 Dec 2014 05:55: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 1Xvl6u-0005ao-Nn;
	Tue, 02 Dec 2014 10:55:12 +0000
Date: Tue, 2 Dec 2014 10:55:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <547D9B05020000780004C07B@mail.emea.novell.com>
Message-ID: <alpine.DEB.2.02.1412021052170.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>
	<alpine.DEB.2.02.1412011852390.14135@kaball.uk.xensource.com>
	<547D9B05020000780004C07B@mail.emea.novell.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 Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, linux@eikelenboom.it,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] call xc_domain_irq_permission
 before xc_domain_irq_permission
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2 Dec 2014, Jan Beulich wrote:
> >>> On 01.12.14 at 20:22, <stefano.stabellini@eu.citrix.com> wrote:
> > xc_physdev_unmap_pirq might revoke the permission to map the irq from
> > the domain causing the following xc_domain_irq_permission call to fail
> > and return error (domain_pirq_to_irq returns 0).
> 
> Apart from the patch title being rather confusing, isn't the root
> problem then xc_physdev_unmap_pirq() removes permissions? At
> least after the strict splitting of permission granting and mapping for
> MMIO (commit 0561e1f0) it would seem that if the underlying
> hypercall here behaves similarly to the original behavior there, it
> ought to be fixed in an analogous way.

The big difference is that 0561e1f0 makes XEN_DOMCTL_memory_mapping
stricker, while you are suggesting to make xc_physdev_unmap_pirq laxer.

Are you sure that is a good idea? What if a third party caller of
xc_physdev_unmap_pirq relies on that behaviour?


 
> > Call xc_domain_irq_permission first to prevent this from happening
> > (xc_physdev_unmap_pirq calls irq_deny_access, that doesn't fail if the
> > permission is already removed).
> > 
> > This is a simple bug fix and I think should go in 4.5.
> > 
> > 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..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 
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 10:57:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvl8m-0002ug-RG; Tue, 02 Dec 2014 10:57:08 +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 1Xvl8l-0002uX-Il
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:57:07 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	A1/55-11581-20B9D745; Tue, 02 Dec 2014 10:57:06 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417517820!7673728!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10666 invoked from network); 2 Dec 2014 10:57:06 -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;
	2 Dec 2014 10:57:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198460782"
Message-ID: <547D9B00.2090506@citrix.com>
Date: Tue, 2 Dec 2014 10:57:04 +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: zhangleiqiang <zhangleiqiang@gmail.com>, <xen-devel@lists.xen.org>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
In-Reply-To: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 08:30, zhangleiqiang wrote:
> Hi, all
>     I am testing the performance of xen netfront-netback driver that
> with multi-queues support. The throughput from domU to remote dom0 is
> 9.2Gb/s, but the throughput from domU to remote domU is only 3.6Gb/s, I
> think the bottleneck is the throughput from dom0 to local domU. However,
> we have done some testing and found the throughput from dom0 to local
> domU is 5.8Gb/s.
>     And if we send packets from one DomU to other 3 DomUs on different
> host simultaneously, the sum of throughout can reach 9Gbps. It seems
> like the bottleneck is the receiver?
>     After some analysis, I found that even the max_queue of
> netfront/back is set to 4, there are some strange results as follows:
>     1. In domU, only one rx queue deal with softirq
>     2. In dom0, only two netback queues process are scheduled, other two
> process aren't scheduled.

Multiqueue only has benefits if you have multiple flows since the
source/destination addresses are hashed to a queue number.  This
probably explains why only some of the queues are being used in your test.

David

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 10:57:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 10:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvl8m-0002ug-RG; Tue, 02 Dec 2014 10:57:08 +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 1Xvl8l-0002uX-Il
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 10:57:07 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	A1/55-11581-20B9D745; Tue, 02 Dec 2014 10:57:06 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417517820!7673728!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10666 invoked from network); 2 Dec 2014 10:57:06 -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;
	2 Dec 2014 10:57:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198460782"
Message-ID: <547D9B00.2090506@citrix.com>
Date: Tue, 2 Dec 2014 10:57:04 +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: zhangleiqiang <zhangleiqiang@gmail.com>, <xen-devel@lists.xen.org>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
In-Reply-To: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 08:30, zhangleiqiang wrote:
> Hi, all
>     I am testing the performance of xen netfront-netback driver that
> with multi-queues support. The throughput from domU to remote dom0 is
> 9.2Gb/s, but the throughput from domU to remote domU is only 3.6Gb/s, I
> think the bottleneck is the throughput from dom0 to local domU. However,
> we have done some testing and found the throughput from dom0 to local
> domU is 5.8Gb/s.
>     And if we send packets from one DomU to other 3 DomUs on different
> host simultaneously, the sum of throughout can reach 9Gbps. It seems
> like the bottleneck is the receiver?
>     After some analysis, I found that even the max_queue of
> netfront/back is set to 4, there are some strange results as follows:
>     1. In domU, only one rx queue deal with softirq
>     2. In dom0, only two netback queues process are scheduled, other two
> process aren't scheduled.

Multiqueue only has benefits if you have multiple flows since the
source/destination addresses are hashed to a queue number.  This
probably explains why only some of the queues are being used in your test.

David

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:00:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvlBm-0003Ak-JF; Tue, 02 Dec 2014 11:00:14 +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 1XvlBl-0003AZ-B2
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:00:13 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	44/C2-09284-CBB9D745; Tue, 02 Dec 2014 11:00:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417518010!15091920!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3320 invoked from network); 2 Dec 2014 11:00: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;
	2 Dec 2014 11:00:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198461327"
Message-ID: <547D9BB9.7010305@citrix.com>
Date: Tue, 2 Dec 2014 11:00:09 +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: Christoph Egger <chegger@amazon.de>, <xen-devel@lists.xen.org>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
In-Reply-To: <1417514784-15749-1-git-send-email-chegger@amazon.de>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 0/2] gnttab: Improve scaleability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 10:06, Christoph Egger wrote:
> This patch series changes the grant table locking to
> a more fain grained locking protocol. The result is
> a performance boost measured with blkfront/blkback.
> Document the locking protocol.
>
> [PATCH 1/2] gnttab: Introduce rwlock to protect updates to grant
> [PATCH 2/2] gnttab: refactor locking for scalability

XenServer has been using the original version of this patch (forward
ported a little), and it makes significant improvements to our scalability.

I highly recommend this for inclusion, although for 4.6 at this point.

~Andrew


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:00:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvlBm-0003Ak-JF; Tue, 02 Dec 2014 11:00:14 +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 1XvlBl-0003AZ-B2
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:00:13 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	44/C2-09284-CBB9D745; Tue, 02 Dec 2014 11:00:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417518010!15091920!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3320 invoked from network); 2 Dec 2014 11:00: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;
	2 Dec 2014 11:00:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198461327"
Message-ID: <547D9BB9.7010305@citrix.com>
Date: Tue, 2 Dec 2014 11:00:09 +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: Christoph Egger <chegger@amazon.de>, <xen-devel@lists.xen.org>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
In-Reply-To: <1417514784-15749-1-git-send-email-chegger@amazon.de>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 0/2] gnttab: Improve scaleability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 10:06, Christoph Egger wrote:
> This patch series changes the grant table locking to
> a more fain grained locking protocol. The result is
> a performance boost measured with blkfront/blkback.
> Document the locking protocol.
>
> [PATCH 1/2] gnttab: Introduce rwlock to protect updates to grant
> [PATCH 2/2] gnttab: refactor locking for scalability

XenServer has been using the original version of this patch (forward
ported a little), and it makes significant improvements to our scalability.

I highly recommend this for inclusion, although for 4.6 at this point.

~Andrew


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:01:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11: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 1XvlD8-0003G3-20; Tue, 02 Dec 2014 11:01:38 +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 1XvlD7-0003Fy-7q
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:01:37 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	1A/30-02697-01C9D745; Tue, 02 Dec 2014 11:01:36 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417518094!11072225!1
X-Originating-IP: [66.165.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 13551 invoked from network); 2 Dec 2014 11:01:35 -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;
	2 Dec 2014 11:01:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198793342"
Received: from ukmail1.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, 2 Dec 2014 06:01:33 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XvlD3-0005k7-HF;
	Tue, 02 Dec 2014 11:01:33 +0000
Date: Tue, 2 Dec 2014 11:01:33 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: zhangleiqiang <zhangleiqiang@gmail.com>
Message-ID: <20141202110133.GA5768@zion.uk.xensource.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
MIME-Version: 1.0
Content-Length: 3198
Content-Disposition: inline
In-Reply-To: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBEZWMgMDIsIDIwMTQgYXQgMDQ6MzA6NDlQTSArMDgwMCwgemhhbmdsZWlxaWFuZyB3
cm90ZToKPiBIaSwgYWxsCj4gICAgIEkgYW0gdGVzdGluZyB0aGUgcGVyZm9ybWFuY2Ugb2YgeGVu
IG5ldGZyb250LW5ldGJhY2sgZHJpdmVyIHRoYXQgd2l0aCBtdWx0aS1xdWV1ZXMgc3VwcG9ydC4g
VGhlIHRocm91Z2hwdXQgZnJvbSBkb21VIHRvIHJlbW90ZSBkb20wIGlzIDkuMkdiL3MsIGJ1dCB0
aGUgdGhyb3VnaHB1dCBmcm9tIGRvbVUgdG8gcmVtb3RlIGRvbVUgaXMgb25seSAzLjZHYi9zLCBJ
IHRoaW5rIHRoZSBib3R0bGVuZWNrIGlzIHRoZSB0aHJvdWdocHV0IGZyb20gZG9tMCB0byBsb2Nh
bCBkb21VLiBIb3dldmVyLCB3ZSBoYXZlIGRvbmUgc29tZSB0ZXN0aW5nIGFuZCBmb3VuZCB0aGUg
dGhyb3VnaHB1dCBmcm9tIGRvbTAgdG8gbG9jYWwgZG9tVSBpcyA1LjhHYi9zLgo+ICAgICBBbmQg
aWYgd2Ugc2VuZCBwYWNrZXRzIGZyb20gb25lIERvbVUgdG8gb3RoZXIgMyBEb21VcyBvbiBkaWZm
ZXJlbnQgaG9zdCBzaW11bHRhbmVvdXNseSwgdGhlIHN1bSBvZiB0aHJvdWdob3V0IGNhbiByZWFj
aCA5R2Jwcy4gSXQgc2VlbXMgbGlrZSB0aGUgYm90dGxlbmVjayBpcyB0aGUgcmVjZWl2ZXI/Cj4g
ICAgIEFmdGVyIHNvbWUgYW5hbHlzaXMsIEkgZm91bmQgdGhhdCBldmVuIHRoZSBtYXhfcXVldWUg
b2YgbmV0ZnJvbnQvYmFjayBpcyBzZXQgdG8gNCwgdGhlcmUgYXJlIHNvbWUgc3RyYW5nZSByZXN1
bHRzIGFzIGZvbGxvd3M6Cj4gICAgIDEuIEluIGRvbVUsIG9ubHkgb25lIHJ4IHF1ZXVlIGRlYWwg
d2l0aCBzb2Z0aXJxCgpUcnkgdG8gYmluZCBpcnEgdG8gZGlmZmVyZW50IHZjcHVzPwoKPiAgICAg
Mi4gSW4gZG9tMCwgb25seSB0d28gbmV0YmFjayBxdWV1ZXMgcHJvY2VzcyBhcmUgc2NoZWR1bGVk
LCBvdGhlciB0d28gcHJvY2VzcyBhcmVuJ3Qgc2NoZWR1bGVkLgoKSG93IG1hbnkgRG9tMCB2Y3B1
IGRvIHlvdSBoYXZlPyBJZiBpdCBvbmx5IGhhcyB0d28gdGhlbiB0aGVyZSB3aWxsIG9ubHkKYmUg
dHdvIHByb2Nlc3NlcyBydW5uaW5nIGF0IGEgdGltZS4KCj4gCj4gICAgIEFyZSB0aGVyZSBhbnkg
aXNzdWVzIGluIG15IHRlc3Q/IEluIHRoZW9yeSwgY2FuIHdlIGFjaGlldmUgOX4xMEdiL3MgYmV0
d2VlbiBEb21VcyBvbiBkaWZmZXJlbnQgaG9zdHMgdXNpbmcgbmV0ZnJvbnQvbmV0YmFjaz8KPiAg
ICAgCj4gICAgICBUaGUgdGVzdGluZyBlbnZpcm9ubWVudCBkZXRhaWxzIGFyZSBhcyBmb2xsb3dz
Ogo+ICAgIDEuIEhhcmR3YXJlCj4gICAgICAgIGEuIENQVTogSW50ZWwoUikgWGVvbihSKSBDUFUg
RTU2NDUgQCAyLjQwR0h6LCAyIENQVSA2IENvcmVzIHdpdGggSHlwZXIgVGhyZWFkIGVuYWJsZWQK
PiAgICAgICAgYi4gTklDOiBJbnRlbCBDb3Jwb3JhdGlvbiA4MjU5OUVCIDEwLUdpZ2FiaXQgU0ZJ
L1NGUCsgTmV0d29yayBDb25uZWN0aW9uIChyZXYgMDEpCj4gICAgMi4gU29md2FyZToKPiAgICAg
ICAgYS4gSG9zdE9TOiBTTEVTIDEyIChLZXJuZWwgMy4xNi03LGdpdCBjb21taXQgZDAzMzVlNGZl
ZWEwZDNmN2E4YWYzMTE2YzVkYzE2NjIzOWRhNzUyMSApCgpBbmQgdGhpcyBpcyBhIFN1U0Uga2Vy
bmVsPwoKPiAgICAgICAgYi4gTklDIERyaXZlcjogSVhHQkUgMy4yMS4yIAo+ICAgICAgICBjLiBP
VlM6IDIuMS4zCj4gICAgICAgIGQuIE1UVTogMTYwMAo+ICAgICAgICBlLiBEb20w77yaNlU2Rwo+
ICAgICAgICBmLiBxdWV1ZSBudW1iZXI6IDQKPiAgICAgICAgZy4geGVuIDQuNAo+ICAgICAgICBo
LiBEb21VOiA0VTRHCj4gICAgMy4gTmV0d29ya2luZyBFbnZpcm9ubWVudDoKPiAgICAgICAgYS4g
QWxsIG5ldHdvcmsgZmxvd3MgYXJlIHRyYW5zbWl0L3JlY2VpdmUgdGhyb3VnaCBPVlMKPiAgICAg
ICAgYi4gU2VuZGVyIHNlcnZlciBhbmQgcmVjZWl2ZXIgc2VydmVyIGFyZSBjb25uZWN0ZWQgZGly
ZWN0bHkgYmV0d2VlbiAxMEdFIE5JQwo+ICAgIDQuIFRlc3RpbmcgVG9vbHM6Cj4gICAgICAgIGEu
IFNlbmRlcjogbmV0cGVyZgo+ICAgICAgICBiLiBSZWNlaXZlcjogbmV0c2VydmVyCj4gCj4gCj4g
LS0tLS0tLS0tLQo+IHpoYW5nbGVpcWlhbmcgKFRydW1wKQo+IEJlc3QgUmVnYXJkcwoKPiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4u
b3JnL3hlbi1kZXZlbAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:01:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11: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 1XvlD8-0003G3-20; Tue, 02 Dec 2014 11:01:38 +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 1XvlD7-0003Fy-7q
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:01:37 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	1A/30-02697-01C9D745; Tue, 02 Dec 2014 11:01:36 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417518094!11072225!1
X-Originating-IP: [66.165.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 13551 invoked from network); 2 Dec 2014 11:01:35 -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;
	2 Dec 2014 11:01:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198793342"
Received: from ukmail1.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, 2 Dec 2014 06:01:33 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XvlD3-0005k7-HF;
	Tue, 02 Dec 2014 11:01:33 +0000
Date: Tue, 2 Dec 2014 11:01:33 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: zhangleiqiang <zhangleiqiang@gmail.com>
Message-ID: <20141202110133.GA5768@zion.uk.xensource.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
MIME-Version: 1.0
Content-Length: 3198
Content-Disposition: inline
In-Reply-To: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBEZWMgMDIsIDIwMTQgYXQgMDQ6MzA6NDlQTSArMDgwMCwgemhhbmdsZWlxaWFuZyB3
cm90ZToKPiBIaSwgYWxsCj4gICAgIEkgYW0gdGVzdGluZyB0aGUgcGVyZm9ybWFuY2Ugb2YgeGVu
IG5ldGZyb250LW5ldGJhY2sgZHJpdmVyIHRoYXQgd2l0aCBtdWx0aS1xdWV1ZXMgc3VwcG9ydC4g
VGhlIHRocm91Z2hwdXQgZnJvbSBkb21VIHRvIHJlbW90ZSBkb20wIGlzIDkuMkdiL3MsIGJ1dCB0
aGUgdGhyb3VnaHB1dCBmcm9tIGRvbVUgdG8gcmVtb3RlIGRvbVUgaXMgb25seSAzLjZHYi9zLCBJ
IHRoaW5rIHRoZSBib3R0bGVuZWNrIGlzIHRoZSB0aHJvdWdocHV0IGZyb20gZG9tMCB0byBsb2Nh
bCBkb21VLiBIb3dldmVyLCB3ZSBoYXZlIGRvbmUgc29tZSB0ZXN0aW5nIGFuZCBmb3VuZCB0aGUg
dGhyb3VnaHB1dCBmcm9tIGRvbTAgdG8gbG9jYWwgZG9tVSBpcyA1LjhHYi9zLgo+ICAgICBBbmQg
aWYgd2Ugc2VuZCBwYWNrZXRzIGZyb20gb25lIERvbVUgdG8gb3RoZXIgMyBEb21VcyBvbiBkaWZm
ZXJlbnQgaG9zdCBzaW11bHRhbmVvdXNseSwgdGhlIHN1bSBvZiB0aHJvdWdob3V0IGNhbiByZWFj
aCA5R2Jwcy4gSXQgc2VlbXMgbGlrZSB0aGUgYm90dGxlbmVjayBpcyB0aGUgcmVjZWl2ZXI/Cj4g
ICAgIEFmdGVyIHNvbWUgYW5hbHlzaXMsIEkgZm91bmQgdGhhdCBldmVuIHRoZSBtYXhfcXVldWUg
b2YgbmV0ZnJvbnQvYmFjayBpcyBzZXQgdG8gNCwgdGhlcmUgYXJlIHNvbWUgc3RyYW5nZSByZXN1
bHRzIGFzIGZvbGxvd3M6Cj4gICAgIDEuIEluIGRvbVUsIG9ubHkgb25lIHJ4IHF1ZXVlIGRlYWwg
d2l0aCBzb2Z0aXJxCgpUcnkgdG8gYmluZCBpcnEgdG8gZGlmZmVyZW50IHZjcHVzPwoKPiAgICAg
Mi4gSW4gZG9tMCwgb25seSB0d28gbmV0YmFjayBxdWV1ZXMgcHJvY2VzcyBhcmUgc2NoZWR1bGVk
LCBvdGhlciB0d28gcHJvY2VzcyBhcmVuJ3Qgc2NoZWR1bGVkLgoKSG93IG1hbnkgRG9tMCB2Y3B1
IGRvIHlvdSBoYXZlPyBJZiBpdCBvbmx5IGhhcyB0d28gdGhlbiB0aGVyZSB3aWxsIG9ubHkKYmUg
dHdvIHByb2Nlc3NlcyBydW5uaW5nIGF0IGEgdGltZS4KCj4gCj4gICAgIEFyZSB0aGVyZSBhbnkg
aXNzdWVzIGluIG15IHRlc3Q/IEluIHRoZW9yeSwgY2FuIHdlIGFjaGlldmUgOX4xMEdiL3MgYmV0
d2VlbiBEb21VcyBvbiBkaWZmZXJlbnQgaG9zdHMgdXNpbmcgbmV0ZnJvbnQvbmV0YmFjaz8KPiAg
ICAgCj4gICAgICBUaGUgdGVzdGluZyBlbnZpcm9ubWVudCBkZXRhaWxzIGFyZSBhcyBmb2xsb3dz
Ogo+ICAgIDEuIEhhcmR3YXJlCj4gICAgICAgIGEuIENQVTogSW50ZWwoUikgWGVvbihSKSBDUFUg
RTU2NDUgQCAyLjQwR0h6LCAyIENQVSA2IENvcmVzIHdpdGggSHlwZXIgVGhyZWFkIGVuYWJsZWQK
PiAgICAgICAgYi4gTklDOiBJbnRlbCBDb3Jwb3JhdGlvbiA4MjU5OUVCIDEwLUdpZ2FiaXQgU0ZJ
L1NGUCsgTmV0d29yayBDb25uZWN0aW9uIChyZXYgMDEpCj4gICAgMi4gU29md2FyZToKPiAgICAg
ICAgYS4gSG9zdE9TOiBTTEVTIDEyIChLZXJuZWwgMy4xNi03LGdpdCBjb21taXQgZDAzMzVlNGZl
ZWEwZDNmN2E4YWYzMTE2YzVkYzE2NjIzOWRhNzUyMSApCgpBbmQgdGhpcyBpcyBhIFN1U0Uga2Vy
bmVsPwoKPiAgICAgICAgYi4gTklDIERyaXZlcjogSVhHQkUgMy4yMS4yIAo+ICAgICAgICBjLiBP
VlM6IDIuMS4zCj4gICAgICAgIGQuIE1UVTogMTYwMAo+ICAgICAgICBlLiBEb20w77yaNlU2Rwo+
ICAgICAgICBmLiBxdWV1ZSBudW1iZXI6IDQKPiAgICAgICAgZy4geGVuIDQuNAo+ICAgICAgICBo
LiBEb21VOiA0VTRHCj4gICAgMy4gTmV0d29ya2luZyBFbnZpcm9ubWVudDoKPiAgICAgICAgYS4g
QWxsIG5ldHdvcmsgZmxvd3MgYXJlIHRyYW5zbWl0L3JlY2VpdmUgdGhyb3VnaCBPVlMKPiAgICAg
ICAgYi4gU2VuZGVyIHNlcnZlciBhbmQgcmVjZWl2ZXIgc2VydmVyIGFyZSBjb25uZWN0ZWQgZGly
ZWN0bHkgYmV0d2VlbiAxMEdFIE5JQwo+ICAgIDQuIFRlc3RpbmcgVG9vbHM6Cj4gICAgICAgIGEu
IFNlbmRlcjogbmV0cGVyZgo+ICAgICAgICBiLiBSZWNlaXZlcjogbmV0c2VydmVyCj4gCj4gCj4g
LS0tLS0tLS0tLQo+IHpoYW5nbGVpcWlhbmcgKFRydW1wKQo+IEJlc3QgUmVnYXJkcwoKPiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4u
b3JnL3hlbi1kZXZlbAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:02:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvlDe-0003Or-Es; Tue, 02 Dec 2014 11:02: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 1XvlDc-0003OY-MF
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:02:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E4/DB-25276-03C9D745; Tue, 02 Dec 2014 11:02:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417518127!12826506!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 9004 invoked from network); 2 Dec 2014 11:02:07 -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; 2 Dec 2014 11:02:07 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 37E5BAC24;
	Tue,  2 Dec 2014 11:02:07 +0000 (UTC)
Message-ID: <547D9C2E.3040804@suse.com>
Date: Tue, 02 Dec 2014 12:02: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: David Vrabel <david.vrabel@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
In-Reply-To: <547D9A4A.6010201@citrix.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 11:54 AM, David Vrabel wrote:
> On 02/12/14 09:39, Juergen Gross wrote:
>> Hi,
>>
>> looking into the upstream linux sources I realized that the PVHVM
>> drivers of XEN are only available with the pvops kernel. Is this on
>> purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
>> configurable without having to enable CONFIG_PARAVIRT?
>
> I suppose that would be possible but I don't think it's a useful
> configuration because you would lose PV spinlocks for example.

Having no pv spinlocks on a single vcpu HVM guest isn't so bad. Having
no pv-drivers for disks and networking is worse.


Juergen

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:02:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvlDe-0003Or-Es; Tue, 02 Dec 2014 11:02: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 1XvlDc-0003OY-MF
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:02:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E4/DB-25276-03C9D745; Tue, 02 Dec 2014 11:02:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417518127!12826506!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 9004 invoked from network); 2 Dec 2014 11:02:07 -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; 2 Dec 2014 11:02:07 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 37E5BAC24;
	Tue,  2 Dec 2014 11:02:07 +0000 (UTC)
Message-ID: <547D9C2E.3040804@suse.com>
Date: Tue, 02 Dec 2014 12:02: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: David Vrabel <david.vrabel@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
In-Reply-To: <547D9A4A.6010201@citrix.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 11:54 AM, David Vrabel wrote:
> On 02/12/14 09:39, Juergen Gross wrote:
>> Hi,
>>
>> looking into the upstream linux sources I realized that the PVHVM
>> drivers of XEN are only available with the pvops kernel. Is this on
>> purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
>> configurable without having to enable CONFIG_PARAVIRT?
>
> I suppose that would be possible but I don't think it's a useful
> configuration because you would lose PV spinlocks for example.

Having no pv spinlocks on a single vcpu HVM guest isn't so bad. Having
no pv-drivers for disks and networking is worse.


Juergen

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:03:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:03:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvlFJ-0003YA-UG; Tue, 02 Dec 2014 11:03:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XvlFI-0003Xw-05
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:03:52 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	8B/C4-25727-79C9D745; Tue, 02 Dec 2014 11:03:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417518230!15202465!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18681 invoked from network); 2 Dec 2014 11:03:50 -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; 2 Dec 2014 11:03:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 11:03:49 +0000
Message-Id: <547DAAA2020000780004C10F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 11:03:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547C6D98020000780004BB9D@mail.emea.novell.com>
	<20141202103735.GC69236@deinos.phlegethon.org>
In-Reply-To: <20141202103735.GC69236@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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 02.12.14 at 11:37, <tim@xen.org> wrote:
> At 12:31 +0000 on 01 Dec (1417433464), Jan Beulich wrote:
>> >>> On 01.12.14 at 13:13, <tim@xen.org> wrote:
>> > At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>> >> >>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>> >> > At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
>> >> >> >>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
>> >> >> > To my understanding, pages with p2m_ram_ro are not supposed to be 
>> >> >> > modified by guest. So in __hvm_copy(), when p2m type of a page is 
>> >> >> > p2m_ram_rom, no copy will occur.
>> >> >> > However, to our usage, we just wanna this page to be write protected, so 
>> >> >> > that our device model can be triggered to do some emulation. The content 
>> >> >> > written to this page is supposed not to be dropped. This way, if 
>> >> >> > sequentially a read operation is performed by guest to this page, the 
>> >> >> > guest will still see its anticipated value.
>> >> >> 
>> >> >> __hvm_copy() is only a helper function, and doesn't write to
>> >> >> mmio_dm space either; instead its (indirect) callers would invoke
>> >> >> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
>> >> >> returns. The question hence is about the apparent inconsistency
>> >> >> resulting from writes to ram_ro being dropped here but getting
>> >> >> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
>> >> >> that really intentional?
>> >> > 
>> >> > No - and AFAICT it shouldn't be happening.  It _is_ how it was
>> >> > implemented originally, because it involved fewer moving parts and
>> >> > didn't need to be efficient (and after all, writes to entirely missing
>> >> > addresses go to the device model too).
>> >> > 
>> >> > But the code was later updated to log and discard writes to read-only
>> >> > memory (see 4d8aa29 from Trolle Selander).
>> >> > 
>> >> > Early version of p2m_ram_ro were documented in the internal headers as
>> >> > sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
>> >> > has always said that writes are discarded.
>> >> 
>> >> Hmm, so which way do you recommend resolving the inconsistency
>> >> then - match what the public interface says or what the apparent
>> >> original intention for the internal type was? Presumably we need to
>> >> follow the public interface mandated model, and hence require the
>> >> new type to be introduced.
>> > 
>> > Sorry, I was unclear -- there isn't an inconsistency; both internal
>> > and public headers currently say that writes are discarded and AFAICT
>> > that is what the code does.
>> 
>> Not for hvm_hap_nested_page_fault() afaict - the forwarding to
>> DM there contradicts the "writes are discarded" model that other
>> code paths follow.
> 
> It calls handle_mmio() to emulate the instruction for it, but
> handle_mmio() ought not to send anything to the DM.  hvmemul_write()
> will call hvm_copy(), which will drop the write and report success.

Oh, of course - it's really just the wording of the comment there
that mislead me to assume the operation gets passed on for
actual handling. Thanks for clarifying!

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:03:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:03:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvlFJ-0003YA-UG; Tue, 02 Dec 2014 11:03:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XvlFI-0003Xw-05
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:03:52 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	8B/C4-25727-79C9D745; Tue, 02 Dec 2014 11:03:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417518230!15202465!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18681 invoked from network); 2 Dec 2014 11:03:50 -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; 2 Dec 2014 11:03:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 11:03:49 +0000
Message-Id: <547DAAA2020000780004C10F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 11:03:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547C6D98020000780004BB9D@mail.emea.novell.com>
	<20141202103735.GC69236@deinos.phlegethon.org>
In-Reply-To: <20141202103735.GC69236@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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 02.12.14 at 11:37, <tim@xen.org> wrote:
> At 12:31 +0000 on 01 Dec (1417433464), Jan Beulich wrote:
>> >>> On 01.12.14 at 13:13, <tim@xen.org> wrote:
>> > At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>> >> >>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>> >> > At 09:32 +0000 on 01 Dec (1417422746), Jan Beulich wrote:
>> >> >> >>> On 01.12.14 at 09:49, <yu.c.zhang@linux.intel.com> wrote:
>> >> >> > To my understanding, pages with p2m_ram_ro are not supposed to be 
>> >> >> > modified by guest. So in __hvm_copy(), when p2m type of a page is 
>> >> >> > p2m_ram_rom, no copy will occur.
>> >> >> > However, to our usage, we just wanna this page to be write protected, so 
>> >> >> > that our device model can be triggered to do some emulation. The content 
>> >> >> > written to this page is supposed not to be dropped. This way, if 
>> >> >> > sequentially a read operation is performed by guest to this page, the 
>> >> >> > guest will still see its anticipated value.
>> >> >> 
>> >> >> __hvm_copy() is only a helper function, and doesn't write to
>> >> >> mmio_dm space either; instead its (indirect) callers would invoke
>> >> >> hvmemul_do_mmio() upon seeing HVMCOPY_bad_gfn_to_mfn
>> >> >> returns. The question hence is about the apparent inconsistency
>> >> >> resulting from writes to ram_ro being dropped here but getting
>> >> >> passed to the DM by hvm_hap_nested_page_fault(). Tim - is
>> >> >> that really intentional?
>> >> > 
>> >> > No - and AFAICT it shouldn't be happening.  It _is_ how it was
>> >> > implemented originally, because it involved fewer moving parts and
>> >> > didn't need to be efficient (and after all, writes to entirely missing
>> >> > addresses go to the device model too).
>> >> > 
>> >> > But the code was later updated to log and discard writes to read-only
>> >> > memory (see 4d8aa29 from Trolle Selander).
>> >> > 
>> >> > Early version of p2m_ram_ro were documented in the internal headers as
>> >> > sending the writes to the DM, but the public interface (HVMMEM_ram_ro)
>> >> > has always said that writes are discarded.
>> >> 
>> >> Hmm, so which way do you recommend resolving the inconsistency
>> >> then - match what the public interface says or what the apparent
>> >> original intention for the internal type was? Presumably we need to
>> >> follow the public interface mandated model, and hence require the
>> >> new type to be introduced.
>> > 
>> > Sorry, I was unclear -- there isn't an inconsistency; both internal
>> > and public headers currently say that writes are discarded and AFAICT
>> > that is what the code does.
>> 
>> Not for hvm_hap_nested_page_fault() afaict - the forwarding to
>> DM there contradicts the "writes are discarded" model that other
>> code paths follow.
> 
> It calls handle_mmio() to emulate the instruction for it, but
> handle_mmio() ought not to send anything to the DM.  hvmemul_write()
> will call hvm_copy(), which will drop the write and report success.

Oh, of course - it's really just the wording of the comment there
that mislead me to assume the operation gets passed on for
actual handling. Thanks for clarifying!

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:06:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11: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 1XvlHD-0003jS-Ec; Tue, 02 Dec 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 <Ian.Campbell@citrix.com>) id 1XvlHC-0003jN-VU
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:05:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8F/04-25276-E0D9D745; Tue, 02 Dec 2014 11:05:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417518344!12849723!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 31435 invoked from network); 2 Dec 2014 11:05: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;
	2 Dec 2014 11:05:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198462515"
Message-ID: <1417518314.24320.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 2 Dec 2014 11:05:14 +0000
In-Reply-To: <547D9A4A.6010201@citrix.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@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] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 10:54 +0000, David Vrabel wrote:
> On 02/12/14 09:39, Juergen Gross wrote:
> > Hi,
> > 
> > looking into the upstream linux sources I realized that the PVHVM
> > drivers of XEN are only available with the pvops kernel. Is this on
> > purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
> > configurable without having to enable CONFIG_PARAVIRT?
> 
> I suppose that would be possible but I don't think it's a useful
> configuration because you would lose PV spinlocks for example.

IIRC the reason this hasn't been implemented until now is that
refactoring would be required to the various bits of driver code which
assumes PAE + PARAVIRT when they aren't strictly needed, e.g. grant
table code. Whether its worth the churn at this stage is debatable, but
I think the (in)ability to use PV spinlocks is a red-herring.

Adding PV drivers to an HVM guest is a useful thing to do, even without
PV spinlocks. PV IO gets you far more incremental benefit than the locks
do, adding PV IO paths is the number 1 thing which should be done to any
guest.

One actual usecase is installing from a distro installer which isn't
PAE, let alone PARAVIRT enabled[0], to get far enough that you can
install a more capable PVHVM kernel with more bells and whistles.

If there were distros around who refused wholesale to enable PARAVIRT
even in a non-default kernel then it would be more likely that they
could be convinced to enable a set of PV IO drivers, since they have 0
impact on a non-PARAVIRT system, and still give significant benefit to
Xen users. I don't know of any of the major distros are refusing
PARAVIRT in this way though.

Ian.

[0] The default i386 Debian installer falls into this camp, but you can
use the special PV Xen variant to install as PVHVM too so it's not so
critical.


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:06:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11: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 1XvlHD-0003jS-Ec; Tue, 02 Dec 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 <Ian.Campbell@citrix.com>) id 1XvlHC-0003jN-VU
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:05:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8F/04-25276-E0D9D745; Tue, 02 Dec 2014 11:05:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417518344!12849723!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 31435 invoked from network); 2 Dec 2014 11:05: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;
	2 Dec 2014 11:05:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198462515"
Message-ID: <1417518314.24320.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 2 Dec 2014 11:05:14 +0000
In-Reply-To: <547D9A4A.6010201@citrix.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@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] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 10:54 +0000, David Vrabel wrote:
> On 02/12/14 09:39, Juergen Gross wrote:
> > Hi,
> > 
> > looking into the upstream linux sources I realized that the PVHVM
> > drivers of XEN are only available with the pvops kernel. Is this on
> > purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
> > configurable without having to enable CONFIG_PARAVIRT?
> 
> I suppose that would be possible but I don't think it's a useful
> configuration because you would lose PV spinlocks for example.

IIRC the reason this hasn't been implemented until now is that
refactoring would be required to the various bits of driver code which
assumes PAE + PARAVIRT when they aren't strictly needed, e.g. grant
table code. Whether its worth the churn at this stage is debatable, but
I think the (in)ability to use PV spinlocks is a red-herring.

Adding PV drivers to an HVM guest is a useful thing to do, even without
PV spinlocks. PV IO gets you far more incremental benefit than the locks
do, adding PV IO paths is the number 1 thing which should be done to any
guest.

One actual usecase is installing from a distro installer which isn't
PAE, let alone PARAVIRT enabled[0], to get far enough that you can
install a more capable PVHVM kernel with more bells and whistles.

If there were distros around who refused wholesale to enable PARAVIRT
even in a non-default kernel then it would be more likely that they
could be convinced to enable a set of PV IO drivers, since they have 0
impact on a non-PARAVIRT system, and still give significant benefit to
Xen users. I don't know of any of the major distros are refusing
PARAVIRT in this way though.

Ian.

[0] The default i386 Debian installer falls into this camp, but you can
use the special PV Xen variant to install as PVHVM too so it's not so
critical.


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1XvlJl-0003sY-0Q; Tue, 02 Dec 2014 11:08:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1XvlJj-0003sO-LV
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:08:27 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	D2/25-09284-7AD9D745; Tue, 02 Dec 2014 11:08:23 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417518501!15262453!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE4NjQwNA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19070 invoked from network); 2 Dec 2014 11:08:22 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 11:08:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417518502; x=1449054502;
	h=message-id:date:from:mime-version:to:subject:references:
	in-reply-to:content-transfer-encoding;
	bh=1BWGCwNDXlJ5ynZR1xGCJd9b6CdXuGcEqg+MnTJfyW4=;
	b=p1kn2qytZiYBnV3Ump76yJN5sL89udj6wWxEwlP6cYZbaitsC8fwUpK2
	Kq34zdf3jDWUm+uorMH8BC04iQ7u6tfOpNVJlt0dVEFV25OcXA918dQmk
	yN4RlGB/HlHhHGFQ3lcBZNJY0mFV7H4Fik+lEXkwCCfykrvrhFXOQVrOY c=;
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="144715470"
Received: from email-inbound-relay-6002.iad6.amazon.com ([10.219.219.179])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 11:08:20 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com
	[10.0.103.146])
	by email-inbound-relay-6002.iad6.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB2B8CD0030734
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 11:08:19 GMT
Received: from EX13D04UWA001.ant.amazon.com (10.43.160.47) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 03:08:12 -0800
Received: from a8206654c64f.ant.amazon.com (10.43.162.149) by
	EX13D04UWA001.ant.amazon.com (10.43.160.47) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 11:08:10 +0000
Message-ID: <547D9D96.2090700@amazon.de>
Date: Tue, 2 Dec 2014 12:08:06 +0100
From: "Egger, Christoph" <chegger@amazon.de>
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: Andrew Cooper <andrew.cooper3@citrix.com>, <xen-devel@lists.xen.org>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
	<547D9BB9.7010305@citrix.com>
In-Reply-To: <547D9BB9.7010305@citrix.com>
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D04UWA003.ant.amazon.com (10.43.160.212) To
	EX13D04UWA001.ant.amazon.com (10.43.160.47)
Precedence: Bulk
Subject: Re: [Xen-devel] [PATCH 0/2] gnttab: Improve scaleability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/02 12:00, Andrew Cooper wrote:
> On 02/12/14 10:06, Christoph Egger wrote:
>> This patch series changes the grant table locking to
>> a more fain grained locking protocol. The result is
>> a performance boost measured with blkfront/blkback.
>> Document the locking protocol.
>>
>> [PATCH 1/2] gnttab: Introduce rwlock to protect updates to grant
>> [PATCH 2/2] gnttab: refactor locking for scalability
> 
> XenServer has been using the original version of this patch

Maybe the one sent by Matt Wilson some time ago?

> (forward ported a little),

This version is against staging tree.

> and it makes significant improvements to our scalability.

Thanks for confirmation.

> I highly recommend this for inclusion, although for 4.6 at this point.

I am fine with this. I would be happy to see a backport to xen 4.5 and
4.4 then.

Christoph


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1XvlJl-0003sY-0Q; Tue, 02 Dec 2014 11:08:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1XvlJj-0003sO-LV
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:08:27 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	D2/25-09284-7AD9D745; Tue, 02 Dec 2014 11:08:23 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417518501!15262453!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE4NjQwNA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19070 invoked from network); 2 Dec 2014 11:08:22 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 11:08:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417518502; x=1449054502;
	h=message-id:date:from:mime-version:to:subject:references:
	in-reply-to:content-transfer-encoding;
	bh=1BWGCwNDXlJ5ynZR1xGCJd9b6CdXuGcEqg+MnTJfyW4=;
	b=p1kn2qytZiYBnV3Ump76yJN5sL89udj6wWxEwlP6cYZbaitsC8fwUpK2
	Kq34zdf3jDWUm+uorMH8BC04iQ7u6tfOpNVJlt0dVEFV25OcXA918dQmk
	yN4RlGB/HlHhHGFQ3lcBZNJY0mFV7H4Fik+lEXkwCCfykrvrhFXOQVrOY c=;
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="144715470"
Received: from email-inbound-relay-6002.iad6.amazon.com ([10.219.219.179])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 11:08:20 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com
	[10.0.103.146])
	by email-inbound-relay-6002.iad6.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB2B8CD0030734
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 11:08:19 GMT
Received: from EX13D04UWA001.ant.amazon.com (10.43.160.47) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 03:08:12 -0800
Received: from a8206654c64f.ant.amazon.com (10.43.162.149) by
	EX13D04UWA001.ant.amazon.com (10.43.160.47) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 11:08:10 +0000
Message-ID: <547D9D96.2090700@amazon.de>
Date: Tue, 2 Dec 2014 12:08:06 +0100
From: "Egger, Christoph" <chegger@amazon.de>
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: Andrew Cooper <andrew.cooper3@citrix.com>, <xen-devel@lists.xen.org>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
	<547D9BB9.7010305@citrix.com>
In-Reply-To: <547D9BB9.7010305@citrix.com>
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D04UWA003.ant.amazon.com (10.43.160.212) To
	EX13D04UWA001.ant.amazon.com (10.43.160.47)
Precedence: Bulk
Subject: Re: [Xen-devel] [PATCH 0/2] gnttab: Improve scaleability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/02 12:00, Andrew Cooper wrote:
> On 02/12/14 10:06, Christoph Egger wrote:
>> This patch series changes the grant table locking to
>> a more fain grained locking protocol. The result is
>> a performance boost measured with blkfront/blkback.
>> Document the locking protocol.
>>
>> [PATCH 1/2] gnttab: Introduce rwlock to protect updates to grant
>> [PATCH 2/2] gnttab: refactor locking for scalability
> 
> XenServer has been using the original version of this patch

Maybe the one sent by Matt Wilson some time ago?

> (forward ported a little),

This version is against staging tree.

> and it makes significant improvements to our scalability.

Thanks for confirmation.

> I highly recommend this for inclusion, although for 4.6 at this point.

I am fine with this. I would be happy to see a backport to xen 4.5 and
4.4 then.

Christoph


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:11:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:11:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvlMc-00041B-Iz; Tue, 02 Dec 2014 11:11:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XvlMa-000413-LH
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 11:11:24 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B5/19-09842-C5E9D745; Tue, 02 Dec 2014 11:11:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417518682!12848138!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22122 invoked from network); 2 Dec 2014 11:11:23 -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;
	2 Dec 2014 11:11:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198795713"
Message-ID: <547D9E56.50708@citrix.com>
Date: Tue, 2 Dec 2014 11:11:18 +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: "Luis R. Rodriguez" <mcgrof@suse.com>, David Vrabel
	<david.vrabel@citrix.com>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>	<5476C66F.5040308@suse.com>
	<20141127183616.GV25677@wotan.suse.de>	<547C4CEF.1010603@citrix.com>	<20141201150546.GC25677@wotan.suse.de>	<547C86BF.2040705@citrix.com>	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>	<547C8F30.1010306@citrix.com>	<20141201161905.GH25677@wotan.suse.de>	<547CB07C.1050507@citrix.com>
	<20141201223611.GM25677@wotan.suse.de>
In-Reply-To: <20141201223611.GM25677@wotan.suse.de>
X-DLP: MIA1
Cc: Juergen Gross <jgross@suse.com>, Joerg Roedel <jroedel@suse.de>,
	kvm@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 01/12/14 22:36, Luis R. Rodriguez wrote:
> 
> Then I do agree its a fair analogy (and find this obviously odd that how
> widespread cond_resched() is), we just don't have an equivalent for IRQ
> context, why not avoid the special check then and use this all the time in the
> middle of a hypercall on the return from an interrupt (e.g., the timer
> interrupt)?

http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html

David

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:11:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:11:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvlMc-00041B-Iz; Tue, 02 Dec 2014 11:11:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XvlMa-000413-LH
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 11:11:24 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B5/19-09842-C5E9D745; Tue, 02 Dec 2014 11:11:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417518682!12848138!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22122 invoked from network); 2 Dec 2014 11:11:23 -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;
	2 Dec 2014 11:11:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198795713"
Message-ID: <547D9E56.50708@citrix.com>
Date: Tue, 2 Dec 2014 11:11:18 +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: "Luis R. Rodriguez" <mcgrof@suse.com>, David Vrabel
	<david.vrabel@citrix.com>
References: <1417040805-15857-1-git-send-email-mcgrof@do-not-panic.com>	<5476C66F.5040308@suse.com>
	<20141127183616.GV25677@wotan.suse.de>	<547C4CEF.1010603@citrix.com>	<20141201150546.GC25677@wotan.suse.de>	<547C86BF.2040705@citrix.com>	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>	<547C8F30.1010306@citrix.com>	<20141201161905.GH25677@wotan.suse.de>	<547CB07C.1050507@citrix.com>
	<20141201223611.GM25677@wotan.suse.de>
In-Reply-To: <20141201223611.GM25677@wotan.suse.de>
X-DLP: MIA1
Cc: Juergen Gross <jgross@suse.com>, Joerg Roedel <jroedel@suse.de>,
	kvm@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 01/12/14 22:36, Luis R. Rodriguez wrote:
> 
> Then I do agree its a fair analogy (and find this obviously odd that how
> widespread cond_resched() is), we just don't have an equivalent for IRQ
> context, why not avoid the special check then and use this all the time in the
> middle of a hypercall on the return from an interrupt (e.g., the timer
> interrupt)?

http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html

David

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:19:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1XvlTr-0004H0-15; Tue, 02 Dec 2014 11:18:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XvlTp-0004Gr-OR
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 11:18:53 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	7C/AC-22819-D10AD745; Tue, 02 Dec 2014 11:18:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417519132!6910710!1
X-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 19756 invoked from network); 2 Dec 2014 11:18:52 -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; 2 Dec 2014 11:18:52 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 11:18:51 +0000
Message-Id: <547DAE28020000780004C150@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 11:18:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.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>
	<alpine.DEB.2.02.1412011852390.14135@kaball.uk.xensource.com>
	<547D9B05020000780004C07B@mail.emea.novell.com>
	<alpine.DEB.2.02.1412021052170.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412021052170.14135@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, linux@eikelenboom.it,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] call xc_domain_irq_permission
 before xc_domain_irq_permission
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 11:55, <stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 2 Dec 2014, Jan Beulich wrote:
>> >>> On 01.12.14 at 20:22, <stefano.stabellini@eu.citrix.com> wrote:
>> > xc_physdev_unmap_pirq might revoke the permission to map the irq from
>> > the domain causing the following xc_domain_irq_permission call to fail
>> > and return error (domain_pirq_to_irq returns 0).
>> 
>> Apart from the patch title being rather confusing, isn't the root
>> problem then xc_physdev_unmap_pirq() removes permissions? At
>> least after the strict splitting of permission granting and mapping for
>> MMIO (commit 0561e1f0) it would seem that if the underlying
>> hypercall here behaves similarly to the original behavior there, it
>> ought to be fixed in an analogous way.
> 
> The big difference is that 0561e1f0 makes XEN_DOMCTL_memory_mapping
> stricker, while you are suggesting to make xc_physdev_unmap_pirq laxer.
> 
> Are you sure that is a good idea? What if a third party caller of
> xc_physdev_unmap_pirq relies on that behaviour?

Yes, I think this would be correct. We expect tool stacks to be in
sync with the hypervisor. That said, I'm not sure it would actually
work, since if we did that change, the implicit access granting in
the map operation would also need to be dropped. Yet the map
operation is a prerequisite for XEN_DOMCTL_irq_permission to work
at all right now, as it needs to look up the pIRQ->IRQ translation
(which looks wrong to me now anyway, as it makes little sense for
the same pIRQ to be associated with the same IRQ in two different
domains, i.e. I think the pirq_{permit,deny}_access() calls there
really need to be irq_{permit,deny}_access(), handed the IRQ
translated from the passed in pIRQ).

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:19:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1XvlTr-0004H0-15; Tue, 02 Dec 2014 11:18:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XvlTp-0004Gr-OR
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 11:18:53 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	7C/AC-22819-D10AD745; Tue, 02 Dec 2014 11:18:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417519132!6910710!1
X-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 19756 invoked from network); 2 Dec 2014 11:18:52 -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; 2 Dec 2014 11:18:52 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 11:18:51 +0000
Message-Id: <547DAE28020000780004C150@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 11:18:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.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>
	<alpine.DEB.2.02.1412011852390.14135@kaball.uk.xensource.com>
	<547D9B05020000780004C07B@mail.emea.novell.com>
	<alpine.DEB.2.02.1412021052170.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412021052170.14135@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, linux@eikelenboom.it,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH for-4.5] call xc_domain_irq_permission
 before xc_domain_irq_permission
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 11:55, <stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 2 Dec 2014, Jan Beulich wrote:
>> >>> On 01.12.14 at 20:22, <stefano.stabellini@eu.citrix.com> wrote:
>> > xc_physdev_unmap_pirq might revoke the permission to map the irq from
>> > the domain causing the following xc_domain_irq_permission call to fail
>> > and return error (domain_pirq_to_irq returns 0).
>> 
>> Apart from the patch title being rather confusing, isn't the root
>> problem then xc_physdev_unmap_pirq() removes permissions? At
>> least after the strict splitting of permission granting and mapping for
>> MMIO (commit 0561e1f0) it would seem that if the underlying
>> hypercall here behaves similarly to the original behavior there, it
>> ought to be fixed in an analogous way.
> 
> The big difference is that 0561e1f0 makes XEN_DOMCTL_memory_mapping
> stricker, while you are suggesting to make xc_physdev_unmap_pirq laxer.
> 
> Are you sure that is a good idea? What if a third party caller of
> xc_physdev_unmap_pirq relies on that behaviour?

Yes, I think this would be correct. We expect tool stacks to be in
sync with the hypervisor. That said, I'm not sure it would actually
work, since if we did that change, the implicit access granting in
the map operation would also need to be dropped. Yet the map
operation is a prerequisite for XEN_DOMCTL_irq_permission to work
at all right now, as it needs to look up the pIRQ->IRQ translation
(which looks wrong to me now anyway, as it makes little sense for
the same pIRQ to be associated with the same IRQ in two different
domains, i.e. I think the pirq_{permit,deny}_access() calls there
really need to be irq_{permit,deny}_access(), handed the IRQ
translated from the passed in pIRQ).

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:29:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11: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 1XvldL-0004hv-AC; Tue, 02 Dec 2014 11:28:43 +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 1XvldJ-0004hp-JM
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:28:41 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	22/51-05632-862AD745; Tue, 02 Dec 2014 11:28:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417519718!12786255!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26081 invoked from network); 2 Dec 2014 11:28:40 -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;
	2 Dec 2014 11:28:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198467907"
Message-ID: <547DA24C.2050508@citrix.com>
Date: Tue, 2 Dec 2014 11:28: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: Christoph Egger <chegger@amazon.de>, <xen-devel@lists.xen.org>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
	<1417514784-15749-2-git-send-email-chegger@amazon.de>
In-Reply-To: <1417514784-15749-2-git-send-email-chegger@amazon.de>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/2] gnttab: Introduce rwlock to protect
 updates to grant table 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 02/12/14 10:06, Christoph Egger wrote:
> Rename lock to maptrack_lock and use it to protect maptrack state.
>
> The new rwlock is used to prevent readers from accessing
> inconsistent grant table state such as current
> version, partially initialized active table pages,
> etc.

I would suggest phrasing this slightly differently, as it isn't a simple
rename.

What you are doing is taking the existing grant table lock, splitting it
in two to separate the grant locking from the maptrack locking, and
changing the resulting grant lock to be a rwlock.

With this noted, it would certainly be easier to review if this patch
was split in two; one patch to split the spinlocks and one patch to
change the grant lock from a spinlock to a rwlock.

> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 8fba923..018b5b6 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2501,8 +2510,19 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) uop,
>              return i;
>          if ( unlikely(__copy_from_guest(&op, uop, 1)) )
>              return -EFAULT;
> -        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
> -        if ( unlikely(__copy_field_to_guest(uop, &op, status)) )
> +        if ( unlikely(op.ref_a == op.ref_b) )
> +        {
> +            /* noop, so avoid acquiring the same active entry
> +             * twice in __gnttab_swap_grant_ref(), which would
> +             * case a deadlock.
> +             */
> +            op.status = GNTST_okay;
> +        }
> +        else
> +        {
> +            op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
> +        }
> +        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )

I believe this comment only applies to the changes in active locking
introduced in the subsequent patch?

Either way, I think the a == b check should be in
__gnttab_swap_grant_ref() make any caller safe, not just the this one.

~Andrew


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:29:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11: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 1XvldL-0004hv-AC; Tue, 02 Dec 2014 11:28:43 +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 1XvldJ-0004hp-JM
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:28:41 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	22/51-05632-862AD745; Tue, 02 Dec 2014 11:28:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417519718!12786255!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26081 invoked from network); 2 Dec 2014 11:28:40 -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;
	2 Dec 2014 11:28:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198467907"
Message-ID: <547DA24C.2050508@citrix.com>
Date: Tue, 2 Dec 2014 11:28: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: Christoph Egger <chegger@amazon.de>, <xen-devel@lists.xen.org>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
	<1417514784-15749-2-git-send-email-chegger@amazon.de>
In-Reply-To: <1417514784-15749-2-git-send-email-chegger@amazon.de>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/2] gnttab: Introduce rwlock to protect
 updates to grant table 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 02/12/14 10:06, Christoph Egger wrote:
> Rename lock to maptrack_lock and use it to protect maptrack state.
>
> The new rwlock is used to prevent readers from accessing
> inconsistent grant table state such as current
> version, partially initialized active table pages,
> etc.

I would suggest phrasing this slightly differently, as it isn't a simple
rename.

What you are doing is taking the existing grant table lock, splitting it
in two to separate the grant locking from the maptrack locking, and
changing the resulting grant lock to be a rwlock.

With this noted, it would certainly be easier to review if this patch
was split in two; one patch to split the spinlocks and one patch to
change the grant lock from a spinlock to a rwlock.

> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 8fba923..018b5b6 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2501,8 +2510,19 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) uop,
>              return i;
>          if ( unlikely(__copy_from_guest(&op, uop, 1)) )
>              return -EFAULT;
> -        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
> -        if ( unlikely(__copy_field_to_guest(uop, &op, status)) )
> +        if ( unlikely(op.ref_a == op.ref_b) )
> +        {
> +            /* noop, so avoid acquiring the same active entry
> +             * twice in __gnttab_swap_grant_ref(), which would
> +             * case a deadlock.
> +             */
> +            op.status = GNTST_okay;
> +        }
> +        else
> +        {
> +            op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
> +        }
> +        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )

I believe this comment only applies to the changes in active locking
introduced in the subsequent patch?

Either way, I think the a == b check should be in
__gnttab_swap_grant_ref() make any caller safe, not just the this one.

~Andrew


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:33:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:33:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvliA-0004xt-0r; Tue, 02 Dec 2014 11:33:42 +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 1Xvli8-0004xo-Sk
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:33:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	28/3B-25276-493AD745; Tue, 02 Dec 2014 11:33:40 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417520019!12839681!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 6446 invoked from network); 2 Dec 2014 11:33:39 -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; 2 Dec 2014 11:33:39 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 70673AC18;
	Tue,  2 Dec 2014 11:33:39 +0000 (UTC)
Message-ID: <547DA392.90701@suse.com>
Date: Tue, 02 Dec 2014 12:33: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: Ian Campbell <Ian.Campbell@citrix.com>, 
	David Vrabel <david.vrabel@citrix.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com>
In-Reply-To: <1417518314.24320.9.camel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 12:05 PM, Ian Campbell wrote:
> On Tue, 2014-12-02 at 10:54 +0000, David Vrabel wrote:
>> On 02/12/14 09:39, Juergen Gross wrote:
>>> Hi,
>>>
>>> looking into the upstream linux sources I realized that the PVHVM
>>> drivers of XEN are only available with the pvops kernel. Is this on
>>> purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
>>> configurable without having to enable CONFIG_PARAVIRT?
>>
>> I suppose that would be possible but I don't think it's a useful
>> configuration because you would lose PV spinlocks for example.
>
> IIRC the reason this hasn't been implemented until now is that
> refactoring would be required to the various bits of driver code which
> assumes PAE + PARAVIRT when they aren't strictly needed, e.g. grant
> table code. Whether its worth the churn at this stage is debatable, but
> I think the (in)ability to use PV spinlocks is a red-herring.
>
> Adding PV drivers to an HVM guest is a useful thing to do, even without
> PV spinlocks. PV IO gets you far more incremental benefit than the locks
> do, adding PV IO paths is the number 1 thing which should be done to any
> guest.

I take this as an "ack" to change this. :-)

> One actual usecase is installing from a distro installer which isn't
> PAE, let alone PARAVIRT enabled[0], to get far enough that you can
> install a more capable PVHVM kernel with more bells and whistles.
>
> If there were distros around who refused wholesale to enable PARAVIRT
> even in a non-default kernel then it would be more likely that they
> could be convinced to enable a set of PV IO drivers, since they have 0
> impact on a non-PARAVIRT system, and still give significant benefit to
> Xen users. I don't know of any of the major distros are refusing
> PARAVIRT in this way though.

I think we have customers wanting to run a default kernel as domU. So it
isn't always the distro refusing paravirt, it might be the user...

Okay, how do the current config settings regarding Xen look like?

We have:
- XEN depending on PARAVIRT
- XEN_DOM0 depending on XEN and others
- XEN_BACKEND depending on XEN_DOM0
- various backend drivers depending on XEN_BACKEND
- XEN_PVHVM depending on XEN
- various frontend drivers depending on XEN (even if some are not
   depending on XEN according to Kconfig, they do as the complete
   drivers/xen directory is made only if CONFIG_XEN is defined)

To sort things out I'd suggest to:
- make XEN independent from PARAVIRT
- let XEN_DOM0 select XEN_BACKEND, PARAVIRT, XEN
- let XEN_BACKEND select PARAVIRT, XEN (I'd like to be able to build
   a driver domain without XEN_DOM0)
- introduce XEN_FRONTEND, let it select XEN
- let frontend drivers and drivers needed by those depend on
   XEN_FRONTEND
- let XEN_PVHVM select XEN_FRONTEND
- don't skip drivers/xen on make, as XEN might be selected via a
   config item in that directory


Juergen


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:33:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:33:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvliA-0004xt-0r; Tue, 02 Dec 2014 11:33:42 +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 1Xvli8-0004xo-Sk
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:33:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	28/3B-25276-493AD745; Tue, 02 Dec 2014 11:33:40 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417520019!12839681!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 6446 invoked from network); 2 Dec 2014 11:33:39 -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; 2 Dec 2014 11:33:39 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 70673AC18;
	Tue,  2 Dec 2014 11:33:39 +0000 (UTC)
Message-ID: <547DA392.90701@suse.com>
Date: Tue, 02 Dec 2014 12:33: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: Ian Campbell <Ian.Campbell@citrix.com>, 
	David Vrabel <david.vrabel@citrix.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com>
In-Reply-To: <1417518314.24320.9.camel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 12:05 PM, Ian Campbell wrote:
> On Tue, 2014-12-02 at 10:54 +0000, David Vrabel wrote:
>> On 02/12/14 09:39, Juergen Gross wrote:
>>> Hi,
>>>
>>> looking into the upstream linux sources I realized that the PVHVM
>>> drivers of XEN are only available with the pvops kernel. Is this on
>>> purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
>>> configurable without having to enable CONFIG_PARAVIRT?
>>
>> I suppose that would be possible but I don't think it's a useful
>> configuration because you would lose PV spinlocks for example.
>
> IIRC the reason this hasn't been implemented until now is that
> refactoring would be required to the various bits of driver code which
> assumes PAE + PARAVIRT when they aren't strictly needed, e.g. grant
> table code. Whether its worth the churn at this stage is debatable, but
> I think the (in)ability to use PV spinlocks is a red-herring.
>
> Adding PV drivers to an HVM guest is a useful thing to do, even without
> PV spinlocks. PV IO gets you far more incremental benefit than the locks
> do, adding PV IO paths is the number 1 thing which should be done to any
> guest.

I take this as an "ack" to change this. :-)

> One actual usecase is installing from a distro installer which isn't
> PAE, let alone PARAVIRT enabled[0], to get far enough that you can
> install a more capable PVHVM kernel with more bells and whistles.
>
> If there were distros around who refused wholesale to enable PARAVIRT
> even in a non-default kernel then it would be more likely that they
> could be convinced to enable a set of PV IO drivers, since they have 0
> impact on a non-PARAVIRT system, and still give significant benefit to
> Xen users. I don't know of any of the major distros are refusing
> PARAVIRT in this way though.

I think we have customers wanting to run a default kernel as domU. So it
isn't always the distro refusing paravirt, it might be the user...

Okay, how do the current config settings regarding Xen look like?

We have:
- XEN depending on PARAVIRT
- XEN_DOM0 depending on XEN and others
- XEN_BACKEND depending on XEN_DOM0
- various backend drivers depending on XEN_BACKEND
- XEN_PVHVM depending on XEN
- various frontend drivers depending on XEN (even if some are not
   depending on XEN according to Kconfig, they do as the complete
   drivers/xen directory is made only if CONFIG_XEN is defined)

To sort things out I'd suggest to:
- make XEN independent from PARAVIRT
- let XEN_DOM0 select XEN_BACKEND, PARAVIRT, XEN
- let XEN_BACKEND select PARAVIRT, XEN (I'd like to be able to build
   a driver domain without XEN_DOM0)
- introduce XEN_FRONTEND, let it select XEN
- let frontend drivers and drivers needed by those depend on
   XEN_FRONTEND
- let XEN_PVHVM select XEN_FRONTEND
- don't skip drivers/xen on make, as XEN might be selected via a
   config item in that directory


Juergen


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:36:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvlko-0005AM-49; Tue, 02 Dec 2014 11:36:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xvlkm-0005AC-MP
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:36:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B4/29-15461-834AD745; Tue, 02 Dec 2014 11:36:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417520182!12800027!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 7121 invoked from network); 2 Dec 2014 11:36:23 -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;
	2 Dec 2014 11:36:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198801674"
Message-ID: <1417520175.24320.13.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <jgross@suse.com>
Date: Tue, 2 Dec 2014 11:36:15 +0000
In-Reply-To: <547DA392.90701@suse.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.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>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 12:33 +0100, Juergen Gross wrote:
> On 12/02/2014 12:05 PM, Ian Campbell wrote:
> > On Tue, 2014-12-02 at 10:54 +0000, David Vrabel wrote:
> >> On 02/12/14 09:39, Juergen Gross wrote:
> >>> Hi,
> >>>
> >>> looking into the upstream linux sources I realized that the PVHVM
> >>> drivers of XEN are only available with the pvops kernel. Is this on
> >>> purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
> >>> configurable without having to enable CONFIG_PARAVIRT?
> >>
> >> I suppose that would be possible but I don't think it's a useful
> >> configuration because you would lose PV spinlocks for example.
> >
> > IIRC the reason this hasn't been implemented until now is that
> > refactoring would be required to the various bits of driver code which
> > assumes PAE + PARAVIRT when they aren't strictly needed, e.g. grant
> > table code. Whether its worth the churn at this stage is debatable, but
> > I think the (in)ability to use PV spinlocks is a red-herring.
> >
> > Adding PV drivers to an HVM guest is a useful thing to do, even without
> > PV spinlocks. PV IO gets you far more incremental benefit than the locks
> > do, adding PV IO paths is the number 1 thing which should be done to any
> > guest.
> 
> I take this as an "ack" to change this. :-)

It's a best "IMHO being able to do this is a useful thing". I can't ack
the actual final patch, a) I'm not a relevant maintainer and b) I've not
seen the patch.

> Okay, how do the current config settings regarding Xen look like?

...I'll leave the mechanics down to you and the maintainers to thrash
out.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:36:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvlko-0005AM-49; Tue, 02 Dec 2014 11:36:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xvlkm-0005AC-MP
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:36:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B4/29-15461-834AD745; Tue, 02 Dec 2014 11:36:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417520182!12800027!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 7121 invoked from network); 2 Dec 2014 11:36:23 -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;
	2 Dec 2014 11:36:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198801674"
Message-ID: <1417520175.24320.13.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <jgross@suse.com>
Date: Tue, 2 Dec 2014 11:36:15 +0000
In-Reply-To: <547DA392.90701@suse.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.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>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 12:33 +0100, Juergen Gross wrote:
> On 12/02/2014 12:05 PM, Ian Campbell wrote:
> > On Tue, 2014-12-02 at 10:54 +0000, David Vrabel wrote:
> >> On 02/12/14 09:39, Juergen Gross wrote:
> >>> Hi,
> >>>
> >>> looking into the upstream linux sources I realized that the PVHVM
> >>> drivers of XEN are only available with the pvops kernel. Is this on
> >>> purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
> >>> configurable without having to enable CONFIG_PARAVIRT?
> >>
> >> I suppose that would be possible but I don't think it's a useful
> >> configuration because you would lose PV spinlocks for example.
> >
> > IIRC the reason this hasn't been implemented until now is that
> > refactoring would be required to the various bits of driver code which
> > assumes PAE + PARAVIRT when they aren't strictly needed, e.g. grant
> > table code. Whether its worth the churn at this stage is debatable, but
> > I think the (in)ability to use PV spinlocks is a red-herring.
> >
> > Adding PV drivers to an HVM guest is a useful thing to do, even without
> > PV spinlocks. PV IO gets you far more incremental benefit than the locks
> > do, adding PV IO paths is the number 1 thing which should be done to any
> > guest.
> 
> I take this as an "ack" to change this. :-)

It's a best "IMHO being able to do this is a useful thing". I can't ack
the actual final patch, a) I'm not a relevant maintainer and b) I've not
seen the patch.

> Okay, how do the current config settings regarding Xen look like?

...I'll leave the mechanics down to you and the maintainers to thrash
out.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:39:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:39:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvlnR-0005Ly-Lj; Tue, 02 Dec 2014 11:39:09 +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 1XvlnP-0005Lf-MM
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:39:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A4/C6-25276-BD4AD745; Tue, 02 Dec 2014 11:39:07 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417520346!4797977!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 6193 invoked from network); 2 Dec 2014 11:39:06 -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; 2 Dec 2014 11:39:06 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3A95EAC54;
	Tue,  2 Dec 2014 11:39:06 +0000 (UTC)
Message-ID: <547DA4D9.2060206@suse.com>
Date: Tue, 02 Dec 2014 12:39:05 +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: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>	
	<1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.com>
	<1417520175.24320.13.camel@citrix.com>
In-Reply-To: <1417520175.24320.13.camel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 12:36 PM, Ian Campbell wrote:
> On Tue, 2014-12-02 at 12:33 +0100, Juergen Gross wrote:
>> On 12/02/2014 12:05 PM, Ian Campbell wrote:
>>> On Tue, 2014-12-02 at 10:54 +0000, David Vrabel wrote:
>>>> On 02/12/14 09:39, Juergen Gross wrote:
>>>>> Hi,
>>>>>
>>>>> looking into the upstream linux sources I realized that the PVHVM
>>>>> drivers of XEN are only available with the pvops kernel. Is this on
>>>>> purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
>>>>> configurable without having to enable CONFIG_PARAVIRT?
>>>>
>>>> I suppose that would be possible but I don't think it's a useful
>>>> configuration because you would lose PV spinlocks for example.
>>>
>>> IIRC the reason this hasn't been implemented until now is that
>>> refactoring would be required to the various bits of driver code which
>>> assumes PAE + PARAVIRT when they aren't strictly needed, e.g. grant
>>> table code. Whether its worth the churn at this stage is debatable, but
>>> I think the (in)ability to use PV spinlocks is a red-herring.
>>>
>>> Adding PV drivers to an HVM guest is a useful thing to do, even without
>>> PV spinlocks. PV IO gets you far more incremental benefit than the locks
>>> do, adding PV IO paths is the number 1 thing which should be done to any
>>> guest.
>>
>> I take this as an "ack" to change this. :-)
>
> It's a best "IMHO being able to do this is a useful thing". I can't ack
> the actual final patch, a) I'm not a relevant maintainer and b) I've not
> seen the patch.

It was not meant to be taken as an ack for a not yet written patch. :-)

>
>> Okay, how do the current config settings regarding Xen look like?
>
> ...I'll leave the mechanics down to you and the maintainers to thrash
> out.

Yeah, 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 Tue Dec 02 11:39:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:39:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvlnR-0005Ly-Lj; Tue, 02 Dec 2014 11:39:09 +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 1XvlnP-0005Lf-MM
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:39:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A4/C6-25276-BD4AD745; Tue, 02 Dec 2014 11:39:07 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417520346!4797977!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 6193 invoked from network); 2 Dec 2014 11:39:06 -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; 2 Dec 2014 11:39:06 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3A95EAC54;
	Tue,  2 Dec 2014 11:39:06 +0000 (UTC)
Message-ID: <547DA4D9.2060206@suse.com>
Date: Tue, 02 Dec 2014 12:39:05 +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: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>	
	<1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.com>
	<1417520175.24320.13.camel@citrix.com>
In-Reply-To: <1417520175.24320.13.camel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 12:36 PM, Ian Campbell wrote:
> On Tue, 2014-12-02 at 12:33 +0100, Juergen Gross wrote:
>> On 12/02/2014 12:05 PM, Ian Campbell wrote:
>>> On Tue, 2014-12-02 at 10:54 +0000, David Vrabel wrote:
>>>> On 02/12/14 09:39, Juergen Gross wrote:
>>>>> Hi,
>>>>>
>>>>> looking into the upstream linux sources I realized that the PVHVM
>>>>> drivers of XEN are only available with the pvops kernel. Is this on
>>>>> purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
>>>>> configurable without having to enable CONFIG_PARAVIRT?
>>>>
>>>> I suppose that would be possible but I don't think it's a useful
>>>> configuration because you would lose PV spinlocks for example.
>>>
>>> IIRC the reason this hasn't been implemented until now is that
>>> refactoring would be required to the various bits of driver code which
>>> assumes PAE + PARAVIRT when they aren't strictly needed, e.g. grant
>>> table code. Whether its worth the churn at this stage is debatable, but
>>> I think the (in)ability to use PV spinlocks is a red-herring.
>>>
>>> Adding PV drivers to an HVM guest is a useful thing to do, even without
>>> PV spinlocks. PV IO gets you far more incremental benefit than the locks
>>> do, adding PV IO paths is the number 1 thing which should be done to any
>>> guest.
>>
>> I take this as an "ack" to change this. :-)
>
> It's a best "IMHO being able to do this is a useful thing". I can't ack
> the actual final patch, a) I'm not a relevant maintainer and b) I've not
> seen the patch.

It was not meant to be taken as an ack for a not yet written patch. :-)

>
>> Okay, how do the current config settings regarding Xen look like?
>
> ...I'll leave the mechanics down to you and the maintainers to thrash
> out.

Yeah, 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 Tue Dec 02 11:40:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11: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 1Xvlou-0005Un-52; Tue, 02 Dec 2014 11:40:40 +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 1Xvlos-0005Ub-S2
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:40:38 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	46/D1-15461-635AD745; Tue, 02 Dec 2014 11:40:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417520437!12828588!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 15465 invoked from network); 2 Dec 2014 11:40:37 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 11:40:37 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XvloX-000H74-0E; Tue, 02 Dec 2014 11:40:17 +0000
Date: Tue, 2 Dec 2014 12:40:16 +0100
From: Tim Deegan <tim@xen.org>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Message-ID: <20141202114016.GD69236@deinos.phlegethon.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547D6C86.4090400@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547D6C86.4090400@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com,
	Jan Beulich <JBeulich@suse.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

At 15:38 +0800 on 02 Dec (1417531126), Yu, Zhang wrote:
> On 12/1/2014 8:13 PM, Tim Deegan wrote:
> > At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
> >>>>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
> >>> During this bit of archaeology I realised that either this new type
> >>> should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
> >>> class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
> >>> for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
> >>> just p2m_ram_ro and p2m_grant_map_ro.
> >>
> >> And I suppose in that latter case the new type could be made part
> >> of P2M_RO_TYPES()?
> >
> > Yes indeed, as P2M_RO_TYPES is defined as "must have the _PAGE_RW bit
> > clear in their PTEs".
> >
> 
> Thanks Tim.
> Following are my understanding of the P2M_RO_TYPES and your comments.
> Not sure if I get it right. Please correct me if anything wrong:
> 1> The P2M_RO_TYPES now bears 2 meanings: one is "w bit is clear in the 
> pte"; and another being to discard the write operations;
> 2> We better define another class to bear the second meaning.

Yes, that's what I meant.

Answering your other questions in reverse order:

> 2> p2m_grant_map_ro is also supposed to be discarded? Will handling of 
> this type of pages goes into __hvm_copy()/__hvm_clear(), or should?

I think so, yes.  At the moment we inject #GP when the guest writes to
a read-only grant, which is OK: the guest really ought to know better.
But I think we'll probably end up with neater code if we handle
read-only grants the same way as p2m_ram_ro.

Anyone else have an opinion on the right thing to do here?

> Also some questions for the new p2m class, say P2M_DISCARD_WRITE_TYPES, 
> and the new predicates, say p2m_is_discard_write:
> 1> You mentioned emulate_gva_to_mfn() and __hvm_copy() should discard 
> the write ops, yet I also noticed many other places using the 
> p2m_is_readonly, or only the "p2mt == p2m_ram_ro" judgement(in 
> __hvm_copy/__hvm_clear). Among all these other places, is there any ones 
> also supposed to use the p2m_is_discard_write?

I've just had a look through them all, and I can see exactly four
places that should be using the new p2m_is_discard_write() test:

 - emulate_gva_to_mfn() (Though in fact it's a no-op as shadow-mode
   guests never have p2m_ram_shared or p2m_ram_logdirty mappings.)
 - __hvm_copy() 
 - __hvm_clear() and
 - hvm_hap_nested_page_fault() (where you should also remove the
   explicit handling of p2m_grant_map_ro below.)

Looking through that turned up a few other oddities, which I'm
listing here to remind myself to look at them later (i.e. you don't
need to worry about them for this patch):

 - nsvm_get_nvmcb_page() and nestedhap_walk_L0_p2m() need to handle
   p2m_ram_logdirty or they might spuriously fail duiring live
   migration.
 - __hvm_copy() and __hvm_clear are probably over-strict in their
   failure to handle grant types.
 - P2M_UNMAP_TYPES in vmce.c is a mess.  It's not the right place to
   define this, since it definitely won't be seen my anyone
   adding a new type, and it already has an 'XXX' comment that says
   it doesn't cover a lot of cases. :(

I'll have a look at those another time.

Cheers,

Tim.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:40:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11: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 1Xvlou-0005Un-52; Tue, 02 Dec 2014 11:40:40 +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 1Xvlos-0005Ub-S2
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:40:38 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	46/D1-15461-635AD745; Tue, 02 Dec 2014 11:40:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417520437!12828588!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 15465 invoked from network); 2 Dec 2014 11:40:37 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 11:40:37 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XvloX-000H74-0E; Tue, 02 Dec 2014 11:40:17 +0000
Date: Tue, 2 Dec 2014 12:40:16 +0100
From: Tim Deegan <tim@xen.org>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Message-ID: <20141202114016.GD69236@deinos.phlegethon.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547D6C86.4090400@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547D6C86.4090400@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com,
	Jan Beulich <JBeulich@suse.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

At 15:38 +0800 on 02 Dec (1417531126), Yu, Zhang wrote:
> On 12/1/2014 8:13 PM, Tim Deegan wrote:
> > At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
> >>>>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
> >>> During this bit of archaeology I realised that either this new type
> >>> should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
> >>> class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
> >>> for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
> >>> just p2m_ram_ro and p2m_grant_map_ro.
> >>
> >> And I suppose in that latter case the new type could be made part
> >> of P2M_RO_TYPES()?
> >
> > Yes indeed, as P2M_RO_TYPES is defined as "must have the _PAGE_RW bit
> > clear in their PTEs".
> >
> 
> Thanks Tim.
> Following are my understanding of the P2M_RO_TYPES and your comments.
> Not sure if I get it right. Please correct me if anything wrong:
> 1> The P2M_RO_TYPES now bears 2 meanings: one is "w bit is clear in the 
> pte"; and another being to discard the write operations;
> 2> We better define another class to bear the second meaning.

Yes, that's what I meant.

Answering your other questions in reverse order:

> 2> p2m_grant_map_ro is also supposed to be discarded? Will handling of 
> this type of pages goes into __hvm_copy()/__hvm_clear(), or should?

I think so, yes.  At the moment we inject #GP when the guest writes to
a read-only grant, which is OK: the guest really ought to know better.
But I think we'll probably end up with neater code if we handle
read-only grants the same way as p2m_ram_ro.

Anyone else have an opinion on the right thing to do here?

> Also some questions for the new p2m class, say P2M_DISCARD_WRITE_TYPES, 
> and the new predicates, say p2m_is_discard_write:
> 1> You mentioned emulate_gva_to_mfn() and __hvm_copy() should discard 
> the write ops, yet I also noticed many other places using the 
> p2m_is_readonly, or only the "p2mt == p2m_ram_ro" judgement(in 
> __hvm_copy/__hvm_clear). Among all these other places, is there any ones 
> also supposed to use the p2m_is_discard_write?

I've just had a look through them all, and I can see exactly four
places that should be using the new p2m_is_discard_write() test:

 - emulate_gva_to_mfn() (Though in fact it's a no-op as shadow-mode
   guests never have p2m_ram_shared or p2m_ram_logdirty mappings.)
 - __hvm_copy() 
 - __hvm_clear() and
 - hvm_hap_nested_page_fault() (where you should also remove the
   explicit handling of p2m_grant_map_ro below.)

Looking through that turned up a few other oddities, which I'm
listing here to remind myself to look at them later (i.e. you don't
need to worry about them for this patch):

 - nsvm_get_nvmcb_page() and nestedhap_walk_L0_p2m() need to handle
   p2m_ram_logdirty or they might spuriously fail duiring live
   migration.
 - __hvm_copy() and __hvm_clear are probably over-strict in their
   failure to handle grant types.
 - P2M_UNMAP_TYPES in vmce.c is a mess.  It's not the right place to
   define this, since it definitely won't be seen my anyone
   adding a new type, and it already has an 'XXX' comment that says
   it doesn't cover a lot of cases. :(

I'll have a look at those another time.

Cheers,

Tim.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:50:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11: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 1Xvlxr-00067B-QT; Tue, 02 Dec 2014 11:49: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 1Xvlxr-000676-9F
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:49:55 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	1A/07-24859-267AD745; Tue, 02 Dec 2014 11:49:54 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417520991!15216948!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9016 invoked from network); 2 Dec 2014 11:49: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;
	2 Dec 2014 11:49:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198472594"
Received: from ukmail1.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, 2 Dec 2014 06: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 1Xvlxm-000779-OH;
	Tue, 02 Dec 2014 11:49:50 +0000
Date: Tue, 2 Dec 2014 11:49:39 +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: <547CF696.9040009@terremark.com>
Message-ID: <alpine.DEB.2.02.1412021140320.14135@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251745520.14135@kaball.uk.xensource.com>
	<547CF696.9040009@terremark.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>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] 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

On Mon, 1 Dec 2014, Don Slutz wrote:
> On 11/25/14 12:54, Stefano Stabellini wrote:
> > 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);
> 
> This fills ptr with uninitialized data.  You need to call
> 
> xc_domain_getinfolist()
> 
> before this.  However calling xc_domain_getinfolist() here and retry
> of the xenstore transaction, you will adjust this more then one time.
> 
> So I think that xc_domain_getinfolist() needs to be called before
> the label retry_transaction.  However rc is a mess in this routine.
> 
> rc = 1 is the normal return (since rc = xc_domain_getinfolist() is
> the last setting of rc).  So all the rest of "rc =" needs to be adjusted
> someway.

Instead of calling xc_domain_getinfolist, I think it's best to call
libxl_domain_info. You are right that I need to call it before
retry_transaction.

Thanks for the review!



>    -Don Slutz
> 
> 
> > +
> > +    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
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:50:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11: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 1Xvlxr-00067B-QT; Tue, 02 Dec 2014 11:49: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 1Xvlxr-000676-9F
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:49:55 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	1A/07-24859-267AD745; Tue, 02 Dec 2014 11:49:54 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417520991!15216948!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9016 invoked from network); 2 Dec 2014 11:49: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;
	2 Dec 2014 11:49:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198472594"
Received: from ukmail1.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, 2 Dec 2014 06: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 1Xvlxm-000779-OH;
	Tue, 02 Dec 2014 11:49:50 +0000
Date: Tue, 2 Dec 2014 11:49:39 +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: <547CF696.9040009@terremark.com>
Message-ID: <alpine.DEB.2.02.1412021140320.14135@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411251745520.14135@kaball.uk.xensource.com>
	<547CF696.9040009@terremark.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>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] 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

On Mon, 1 Dec 2014, Don Slutz wrote:
> On 11/25/14 12:54, Stefano Stabellini wrote:
> > 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);
> 
> This fills ptr with uninitialized data.  You need to call
> 
> xc_domain_getinfolist()
> 
> before this.  However calling xc_domain_getinfolist() here and retry
> of the xenstore transaction, you will adjust this more then one time.
> 
> So I think that xc_domain_getinfolist() needs to be called before
> the label retry_transaction.  However rc is a mess in this routine.
> 
> rc = 1 is the normal return (since rc = xc_domain_getinfolist() is
> the last setting of rc).  So all the rest of "rc =" needs to be adjusted
> someway.

Instead of calling xc_domain_getinfolist, I think it's best to call
libxl_domain_info. You are right that I need to call it before
retry_transaction.

Thanks for the review!



>    -Don Slutz
> 
> 
> > +
> > +    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
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:52:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11: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 1Xvm02-0006HV-B1; Tue, 02 Dec 2014 11:52:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xvm00-0006GS-VU
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:52:09 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	46/CF-09284-8E7AD745; Tue, 02 Dec 2014 11:52:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417521127!15237598!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6611 invoked from network); 2 Dec 2014 11:52:07 -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; 2 Dec 2014 11:52:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 11:52:06 +0000
Message-Id: <547DB5F4020000780004C18B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 11:52:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547D6C86.4090400@linux.intel.com>
	<20141202114016.GD69236@deinos.phlegethon.org>
In-Reply-To: <20141202114016.GD69236@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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 02.12.14 at 12:40, <tim@xen.org> wrote:
> At 15:38 +0800 on 02 Dec (1417531126), Yu, Zhang wrote:
>> 2> p2m_grant_map_ro is also supposed to be discarded? Will handling of 
>> this type of pages goes into __hvm_copy()/__hvm_clear(), or should?
> 
> I think so, yes.  At the moment we inject #GP when the guest writes to
> a read-only grant, which is OK: the guest really ought to know better.
> But I think we'll probably end up with neater code if we handle
> read-only grants the same way as p2m_ram_ro.
> 
> Anyone else have an opinion on the right thing to do here?

I actually came to the same conclusion.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:52:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11: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 1Xvm02-0006HV-B1; Tue, 02 Dec 2014 11:52:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xvm00-0006GS-VU
	for Xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:52:09 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	46/CF-09284-8E7AD745; Tue, 02 Dec 2014 11:52:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417521127!15237598!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6611 invoked from network); 2 Dec 2014 11:52:07 -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; 2 Dec 2014 11:52:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 11:52:06 +0000
Message-Id: <547DB5F4020000780004C18B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 11:52:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547D6C86.4090400@linux.intel.com>
	<20141202114016.GD69236@deinos.phlegethon.org>
In-Reply-To: <20141202114016.GD69236@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, Zhang Yu <yu.c.zhang@linux.intel.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 02.12.14 at 12:40, <tim@xen.org> wrote:
> At 15:38 +0800 on 02 Dec (1417531126), Yu, Zhang wrote:
>> 2> p2m_grant_map_ro is also supposed to be discarded? Will handling of 
>> this type of pages goes into __hvm_copy()/__hvm_clear(), or should?
> 
> I think so, yes.  At the moment we inject #GP when the guest writes to
> a read-only grant, which is OK: the guest really ought to know better.
> But I think we'll probably end up with neater code if we handle
> read-only grants the same way as p2m_ram_ro.
> 
> Anyone else have an opinion on the right thing to do here?

I actually came to the same conclusion.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:53:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1Xvm1h-0006Ta-11; Tue, 02 Dec 2014 11:53:53 +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 1Xvm1f-0006TO-J1
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:53:51 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	08/87-02712-E48AD745; Tue, 02 Dec 2014 11:53:50 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417521228!12429095!1
X-Originating-IP: [66.165.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 30110 invoked from network); 2 Dec 2014 11:53:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 11:53:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198473363"
Received: from ukmail1.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, 2 Dec 2014 06:53: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 1Xvm1X-0007AP-2T;
	Tue, 02 Dec 2014 11:53:43 +0000
Date: Tue, 2 Dec 2014 11:53:32 +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.1412021152080.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>, dslutz@verizon.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 for-4.6] 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>

---

Changes in v2:
- call libxl_domain_info instead of libxl_dominfo_init;
- call libxl_domain_info before retry_transaction.

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..569a32a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
     char *uuid;
     xs_transaction_t t;
 
+    if (libxl_domain_info(ctx, &ptr, domid) < 0)
+        goto out_no_transaction;
+
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
@@ -4767,10 +4770,9 @@ 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);
+    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 Dec 02 11:53:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1Xvm1h-0006Ta-11; Tue, 02 Dec 2014 11:53:53 +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 1Xvm1f-0006TO-J1
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:53:51 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	08/87-02712-E48AD745; Tue, 02 Dec 2014 11:53:50 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417521228!12429095!1
X-Originating-IP: [66.165.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 30110 invoked from network); 2 Dec 2014 11:53:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 11:53:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198473363"
Received: from ukmail1.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, 2 Dec 2014 06:53: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 1Xvm1X-0007AP-2T;
	Tue, 02 Dec 2014 11:53:43 +0000
Date: Tue, 2 Dec 2014 11:53:32 +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.1412021152080.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>, dslutz@verizon.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 for-4.6] 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>

---

Changes in v2:
- call libxl_domain_info instead of libxl_dominfo_init;
- call libxl_domain_info before retry_transaction.

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..569a32a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
     char *uuid;
     xs_transaction_t t;
 
+    if (libxl_domain_info(ctx, &ptr, domid) < 0)
+        goto out_no_transaction;
+
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
@@ -4767,10 +4770,9 @@ 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);
+    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 Dec 02 11:53:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:53:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvm1k-0006UV-Cb; Tue, 02 Dec 2014 11:53:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1Xvm1j-0006Tv-53
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:53:55 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	32/D3-25276-258AD745; Tue, 02 Dec 2014 11:53:54 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417521230!12804978!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28451 invoked from network); 2 Dec 2014 11:53:53 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 11:53:53 -0000
Received: from 172.24.2.119 (EHLO SZXEMA414-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDH90117; Tue, 02 Dec 2014 19:53:42 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id
	14.03.0158.001; Tue, 2 Dec 2014 19:53:35 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: David Vrabel <david.vrabel@citrix.com>, zhangleiqiang
	<zhangleiqiang@gmail.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh7VTv6XnC5lYUyZ+zzcpS/K6Zx8MD6g
Date: Tue, 2 Dec 2014 11:53:35 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE23931FBB@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<547D9B00.2090506@citrix.com>
In-Reply-To: <547D9B00.2090506@citrix.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 David Vrabel
> Sent: Tuesday, December 02, 2014 6:57 PM
> To: zhangleiqiang; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> On 02/12/14 08:30, zhangleiqiang wrote:
> > Hi, all
> >     I am testing the performance of xen netfront-netback driver that
> > with multi-queues support. The throughput from domU to remote dom0 is
> > 9.2Gb/s, but the throughput from domU to remote domU is only 3.6Gb/s,
> > I think the bottleneck is the throughput from dom0 to local domU.
> > However, we have done some testing and found the throughput from dom0
> > to local domU is 5.8Gb/s.
> >     And if we send packets from one DomU to other 3 DomUs on different
> > host simultaneously, the sum of throughout can reach 9Gbps. It seems
> > like the bottleneck is the receiver?
> >     After some analysis, I found that even the max_queue of
> > netfront/back is set to 4, there are some strange results as follows:
> >     1. In domU, only one rx queue deal with softirq
> >     2. In dom0, only two netback queues process are scheduled, other
> > two process aren't scheduled.
> 
> Multiqueue only has benefits if you have multiple flows since the
> source/destination addresses are hashed to a queue number.  This probably
> explains why only some of the queues are being used in your test.

The hash method you mentioned is used for selection of netback process or netfront rx queue? 
Indeed, there are 4 netback processes running in Dom0, because there are only one DomU running in Dom0 and so four netback processes are running in Dom0 (the max_queue param of netback kernel module is set to 4). 
The phenomenon is that only 2 of these four netback process were running with about 70% cpu usage, and another two use little CPU.

> 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 Tue Dec 02 11:53:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:53:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvm1k-0006UV-Cb; Tue, 02 Dec 2014 11:53:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1Xvm1j-0006Tv-53
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:53:55 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	32/D3-25276-258AD745; Tue, 02 Dec 2014 11:53:54 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417521230!12804978!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28451 invoked from network); 2 Dec 2014 11:53:53 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 11:53:53 -0000
Received: from 172.24.2.119 (EHLO SZXEMA414-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDH90117; Tue, 02 Dec 2014 19:53:42 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id
	14.03.0158.001; Tue, 2 Dec 2014 19:53:35 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: David Vrabel <david.vrabel@citrix.com>, zhangleiqiang
	<zhangleiqiang@gmail.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh7VTv6XnC5lYUyZ+zzcpS/K6Zx8MD6g
Date: Tue, 2 Dec 2014 11:53:35 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE23931FBB@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<547D9B00.2090506@citrix.com>
In-Reply-To: <547D9B00.2090506@citrix.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 David Vrabel
> Sent: Tuesday, December 02, 2014 6:57 PM
> To: zhangleiqiang; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> On 02/12/14 08:30, zhangleiqiang wrote:
> > Hi, all
> >     I am testing the performance of xen netfront-netback driver that
> > with multi-queues support. The throughput from domU to remote dom0 is
> > 9.2Gb/s, but the throughput from domU to remote domU is only 3.6Gb/s,
> > I think the bottleneck is the throughput from dom0 to local domU.
> > However, we have done some testing and found the throughput from dom0
> > to local domU is 5.8Gb/s.
> >     And if we send packets from one DomU to other 3 DomUs on different
> > host simultaneously, the sum of throughout can reach 9Gbps. It seems
> > like the bottleneck is the receiver?
> >     After some analysis, I found that even the max_queue of
> > netfront/back is set to 4, there are some strange results as follows:
> >     1. In domU, only one rx queue deal with softirq
> >     2. In dom0, only two netback queues process are scheduled, other
> > two process aren't scheduled.
> 
> Multiqueue only has benefits if you have multiple flows since the
> source/destination addresses are hashed to a queue number.  This probably
> explains why only some of the queues are being used in your test.

The hash method you mentioned is used for selection of netback process or netfront rx queue? 
Indeed, there are 4 netback processes running in Dom0, because there are only one DomU running in Dom0 and so four netback processes are running in Dom0 (the max_queue param of netback kernel module is set to 4). 
The phenomenon is that only 2 of these four netback process were running with about 70% cpu usage, and another two use little CPU.

> 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 Tue Dec 02 11:54:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvm1z-0006Yn-T6; Tue, 02 Dec 2014 11:54:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1Xvm1y-0006YE-7D
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:54:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DD/82-09842-168AD745; Tue, 02 Dec 2014 11:54:09 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417521245!12842270!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26303 invoked from network); 2 Dec 2014 11:54:08 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 11:54:08 -0000
Received: from 172.24.2.119 (EHLO szxema411-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDH90140; Tue, 02 Dec 2014 19:54:00 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id
	14.03.0158.001; Tue, 2 Dec 2014 19:50:59 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, zhangleiqiang <zhangleiqiang@gmail.com>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g
Date: Tue, 2 Dec 2014 11:50:59 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
In-Reply-To: <20141202110133.GA5768@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB4ZW4tZGV2ZWwtYm91bmNlc0Bs
aXN0cy54ZW4ub3JnDQo+IFttYWlsdG86eGVuLWRldmVsLWJvdW5jZXNAbGlzdHMueGVuLm9yZ10g
T24gQmVoYWxmIE9mIFdlaSBMaXUNCj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDIsIDIwMTQg
NzowMiBQTQ0KPiBUbzogemhhbmdsZWlxaWFuZw0KPiBDYzogd2VpLmxpdTJAY2l0cml4LmNvbTsg
eGVuLWRldmVsQGxpc3RzLnhlbi5vcmcNCj4gU3ViamVjdDogUmU6IFtYZW4tZGV2ZWxdIFBvb3Ig
bmV0d29yayBwZXJmb3JtYW5jZSBiZXR3ZWVuIERvbVUgd2l0aA0KPiBtdWx0aXF1ZXVlIHN1cHBv
cnQNCj4gDQo+IE9uIFR1ZSwgRGVjIDAyLCAyMDE0IGF0IDA0OjMwOjQ5UE0gKzA4MDAsIHpoYW5n
bGVpcWlhbmcgd3JvdGU6DQo+ID4gSGksIGFsbA0KPiA+ICAgICBJIGFtIHRlc3RpbmcgdGhlIHBl
cmZvcm1hbmNlIG9mIHhlbiBuZXRmcm9udC1uZXRiYWNrIGRyaXZlciB0aGF0IHdpdGgNCj4gbXVs
dGktcXVldWVzIHN1cHBvcnQuIFRoZSB0aHJvdWdocHV0IGZyb20gZG9tVSB0byByZW1vdGUgZG9t
MCBpcyA5LjJHYi9zLA0KPiBidXQgdGhlIHRocm91Z2hwdXQgZnJvbSBkb21VIHRvIHJlbW90ZSBk
b21VIGlzIG9ubHkgMy42R2IvcywgSSB0aGluayB0aGUNCj4gYm90dGxlbmVjayBpcyB0aGUgdGhy
b3VnaHB1dCBmcm9tIGRvbTAgdG8gbG9jYWwgZG9tVS4gSG93ZXZlciwgd2UgaGF2ZQ0KPiBkb25l
IHNvbWUgdGVzdGluZyBhbmQgZm91bmQgdGhlIHRocm91Z2hwdXQgZnJvbSBkb20wIHRvIGxvY2Fs
IGRvbVUgaXMNCj4gNS44R2Ivcy4NCj4gPiAgICAgQW5kIGlmIHdlIHNlbmQgcGFja2V0cyBmcm9t
IG9uZSBEb21VIHRvIG90aGVyIDMgRG9tVXMgb24gZGlmZmVyZW50DQo+IGhvc3Qgc2ltdWx0YW5l
b3VzbHksIHRoZSBzdW0gb2YgdGhyb3VnaG91dCBjYW4gcmVhY2ggOUdicHMuIEl0IHNlZW1zIGxp
a2UgdGhlDQo+IGJvdHRsZW5lY2sgaXMgdGhlIHJlY2VpdmVyPw0KPiA+ICAgICBBZnRlciBzb21l
IGFuYWx5c2lzLCBJIGZvdW5kIHRoYXQgZXZlbiB0aGUgbWF4X3F1ZXVlIG9mIG5ldGZyb250L2Jh
Y2sNCj4gaXMgc2V0IHRvIDQsIHRoZXJlIGFyZSBzb21lIHN0cmFuZ2UgcmVzdWx0cyBhcyBmb2xs
b3dzOg0KPiA+ICAgICAxLiBJbiBkb21VLCBvbmx5IG9uZSByeCBxdWV1ZSBkZWFsIHdpdGggc29m
dGlycQ0KPiANCj4gVHJ5IHRvIGJpbmQgaXJxIHRvIGRpZmZlcmVudCB2Y3B1cz8NCg0KRG8geW91
IG1lYW4gd2UgdHJ5IHRvIGJpbmQgaXJxIHRvIGRpZmZlcmVudCB2Y3B1cyBpbiBEb21VPyBJIHdp
bGwgdHJ5IGl0IG5vdy4NCg0KPiANCj4gPiAgICAgMi4gSW4gZG9tMCwgb25seSB0d28gbmV0YmFj
ayBxdWV1ZXMgcHJvY2VzcyBhcmUgc2NoZWR1bGVkLCBvdGhlciB0d28NCj4gcHJvY2VzcyBhcmVu
J3Qgc2NoZWR1bGVkLg0KPiANCj4gSG93IG1hbnkgRG9tMCB2Y3B1IGRvIHlvdSBoYXZlPyBJZiBp
dCBvbmx5IGhhcyB0d28gdGhlbiB0aGVyZSB3aWxsIG9ubHkgYmUNCj4gdHdvIHByb2Nlc3NlcyBy
dW5uaW5nIGF0IGEgdGltZS4NCg0KRG9tMCBoYXMgNiB2Y3B1cywgYW5kIDZHIG1lbW9yeS4gVGhl
cmUgYXJlIG9ubHkgb25lIERvbVUgcnVubmluZyBpbiBEb20wIGFuZCBzbyBmb3VyIG5ldGJhY2sg
cHJvY2Vzc2VzIGFyZSBydW5uaW5nIGluIERvbTAgKGJlY2F1c2UgdGhlIG1heF9xdWV1ZSBwYXJh
bSBvZiBuZXRiYWNrIGtlcm5lbCBtb2R1bGUgaXMgc2V0IHRvIDQpLiANClRoZSBwaGVub21lbm9u
IGlzIHRoYXQgb25seSAyIG9mIHRoZXNlIGZvdXIgbmV0YmFjayBwcm9jZXNzIHdlcmUgcnVubmlu
ZyB3aXRoIGFib3V0IDcwJSBjcHUgdXNhZ2UsIGFuZCBhbm90aGVyIHR3byB1c2UgbGl0dGxlIENQ
VS4NCklzIHRoZXJlIGEgaGFzaCBhbGdvcml0aG0gdG8gZGV0ZXJtaW5lIHdoaWNoIG5ldGJhY2sg
cHJvY2VzcyB0byBoYW5kbGUgdGhlIGlucHV0IHBhY2tldD8NCg0KPiA+DQo+ID4gICAgIEFyZSB0
aGVyZSBhbnkgaXNzdWVzIGluIG15IHRlc3Q/IEluIHRoZW9yeSwgY2FuIHdlIGFjaGlldmUgOX4x
MEdiL3MNCj4gYmV0d2VlbiBEb21VcyBvbiBkaWZmZXJlbnQgaG9zdHMgdXNpbmcgbmV0ZnJvbnQv
bmV0YmFjaz8NCj4gPg0KPiA+ICAgICAgVGhlIHRlc3RpbmcgZW52aXJvbm1lbnQgZGV0YWlscyBh
cmUgYXMgZm9sbG93czoNCj4gPiAgICAxLiBIYXJkd2FyZQ0KPiA+ICAgICAgICBhLiBDUFU6IElu
dGVsKFIpIFhlb24oUikgQ1BVIEU1NjQ1IEAgMi40MEdIeiwgMiBDUFUgNiBDb3JlcyB3aXRoDQo+
IEh5cGVyIFRocmVhZCBlbmFibGVkDQo+ID4gICAgICAgIGIuIE5JQzogSW50ZWwgQ29ycG9yYXRp
b24gODI1OTlFQiAxMC1HaWdhYml0IFNGSS9TRlArIE5ldHdvcmsNCj4gQ29ubmVjdGlvbiAocmV2
IDAxKQ0KPiA+ICAgIDIuIFNvZndhcmU6DQo+ID4gICAgICAgIGEuIEhvc3RPUzogU0xFUyAxMiAo
S2VybmVsIDMuMTYtNyxnaXQgY29tbWl0DQo+ID4gZDAzMzVlNGZlZWEwZDNmN2E4YWYzMTE2YzVk
YzE2NjIzOWRhNzUyMSApDQo+IA0KPiBBbmQgdGhpcyBpcyBhIFN1U0Uga2VybmVsPw0KDQpObywg
SSBqdXN0IGNvbXBpbGUgRG9tMCBhbmQgRG9tVSBrZXJuZWwgdXNpbmcgMy4xNi03IHRhZyBmcm9t
IGtlcm5lbC5vcmcuDQoNCj4gPiAgICAgICAgYi4gTklDIERyaXZlcjogSVhHQkUgMy4yMS4yDQo+
ID4gICAgICAgIGMuIE9WUzogMi4xLjMNCj4gPiAgICAgICAgZC4gTVRVOiAxNjAwDQo+ID4gICAg
ICAgIGUuIERvbTDvvJo2VTZHDQo+ID4gICAgICAgIGYuIHF1ZXVlIG51bWJlcjogNA0KPiA+ICAg
ICAgICBnLiB4ZW4gNC40DQo+ID4gICAgICAgIGguIERvbVU6IDRVNEcNCj4gPiAgICAzLiBOZXR3
b3JraW5nIEVudmlyb25tZW50Og0KPiA+ICAgICAgICBhLiBBbGwgbmV0d29yayBmbG93cyBhcmUg
dHJhbnNtaXQvcmVjZWl2ZSB0aHJvdWdoIE9WUw0KPiA+ICAgICAgICBiLiBTZW5kZXIgc2VydmVy
IGFuZCByZWNlaXZlciBzZXJ2ZXIgYXJlIGNvbm5lY3RlZCBkaXJlY3RseSBiZXR3ZWVuDQo+IDEw
R0UgTklDDQo+ID4gICAgNC4gVGVzdGluZyBUb29sczoNCj4gPiAgICAgICAgYS4gU2VuZGVyOiBu
ZXRwZXJmDQo+ID4gICAgICAgIGIuIFJlY2VpdmVyOiBuZXRzZXJ2ZXINCj4gPg0KPiA+DQo+ID4g
LS0tLS0tLS0tLQ0KPiA+IHpoYW5nbGVpcWlhbmcgKFRydW1wKQ0KPiA+IEJlc3QgUmVnYXJkcw0K
PiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiA+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QNCj4gPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZw0K
PiA+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbA0KPiANCj4gDQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QNCj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcNCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:54:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvm1z-0006Yn-T6; Tue, 02 Dec 2014 11:54:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1Xvm1y-0006YE-7D
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 11:54:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DD/82-09842-168AD745; Tue, 02 Dec 2014 11:54:09 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417521245!12842270!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26303 invoked from network); 2 Dec 2014 11:54:08 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 11:54:08 -0000
Received: from 172.24.2.119 (EHLO szxema411-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDH90140; Tue, 02 Dec 2014 19:54:00 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id
	14.03.0158.001; Tue, 2 Dec 2014 19:50:59 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, zhangleiqiang <zhangleiqiang@gmail.com>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g
Date: Tue, 2 Dec 2014 11:50:59 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
In-Reply-To: <20141202110133.GA5768@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB4ZW4tZGV2ZWwtYm91bmNlc0Bs
aXN0cy54ZW4ub3JnDQo+IFttYWlsdG86eGVuLWRldmVsLWJvdW5jZXNAbGlzdHMueGVuLm9yZ10g
T24gQmVoYWxmIE9mIFdlaSBMaXUNCj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDIsIDIwMTQg
NzowMiBQTQ0KPiBUbzogemhhbmdsZWlxaWFuZw0KPiBDYzogd2VpLmxpdTJAY2l0cml4LmNvbTsg
eGVuLWRldmVsQGxpc3RzLnhlbi5vcmcNCj4gU3ViamVjdDogUmU6IFtYZW4tZGV2ZWxdIFBvb3Ig
bmV0d29yayBwZXJmb3JtYW5jZSBiZXR3ZWVuIERvbVUgd2l0aA0KPiBtdWx0aXF1ZXVlIHN1cHBv
cnQNCj4gDQo+IE9uIFR1ZSwgRGVjIDAyLCAyMDE0IGF0IDA0OjMwOjQ5UE0gKzA4MDAsIHpoYW5n
bGVpcWlhbmcgd3JvdGU6DQo+ID4gSGksIGFsbA0KPiA+ICAgICBJIGFtIHRlc3RpbmcgdGhlIHBl
cmZvcm1hbmNlIG9mIHhlbiBuZXRmcm9udC1uZXRiYWNrIGRyaXZlciB0aGF0IHdpdGgNCj4gbXVs
dGktcXVldWVzIHN1cHBvcnQuIFRoZSB0aHJvdWdocHV0IGZyb20gZG9tVSB0byByZW1vdGUgZG9t
MCBpcyA5LjJHYi9zLA0KPiBidXQgdGhlIHRocm91Z2hwdXQgZnJvbSBkb21VIHRvIHJlbW90ZSBk
b21VIGlzIG9ubHkgMy42R2IvcywgSSB0aGluayB0aGUNCj4gYm90dGxlbmVjayBpcyB0aGUgdGhy
b3VnaHB1dCBmcm9tIGRvbTAgdG8gbG9jYWwgZG9tVS4gSG93ZXZlciwgd2UgaGF2ZQ0KPiBkb25l
IHNvbWUgdGVzdGluZyBhbmQgZm91bmQgdGhlIHRocm91Z2hwdXQgZnJvbSBkb20wIHRvIGxvY2Fs
IGRvbVUgaXMNCj4gNS44R2Ivcy4NCj4gPiAgICAgQW5kIGlmIHdlIHNlbmQgcGFja2V0cyBmcm9t
IG9uZSBEb21VIHRvIG90aGVyIDMgRG9tVXMgb24gZGlmZmVyZW50DQo+IGhvc3Qgc2ltdWx0YW5l
b3VzbHksIHRoZSBzdW0gb2YgdGhyb3VnaG91dCBjYW4gcmVhY2ggOUdicHMuIEl0IHNlZW1zIGxp
a2UgdGhlDQo+IGJvdHRsZW5lY2sgaXMgdGhlIHJlY2VpdmVyPw0KPiA+ICAgICBBZnRlciBzb21l
IGFuYWx5c2lzLCBJIGZvdW5kIHRoYXQgZXZlbiB0aGUgbWF4X3F1ZXVlIG9mIG5ldGZyb250L2Jh
Y2sNCj4gaXMgc2V0IHRvIDQsIHRoZXJlIGFyZSBzb21lIHN0cmFuZ2UgcmVzdWx0cyBhcyBmb2xs
b3dzOg0KPiA+ICAgICAxLiBJbiBkb21VLCBvbmx5IG9uZSByeCBxdWV1ZSBkZWFsIHdpdGggc29m
dGlycQ0KPiANCj4gVHJ5IHRvIGJpbmQgaXJxIHRvIGRpZmZlcmVudCB2Y3B1cz8NCg0KRG8geW91
IG1lYW4gd2UgdHJ5IHRvIGJpbmQgaXJxIHRvIGRpZmZlcmVudCB2Y3B1cyBpbiBEb21VPyBJIHdp
bGwgdHJ5IGl0IG5vdy4NCg0KPiANCj4gPiAgICAgMi4gSW4gZG9tMCwgb25seSB0d28gbmV0YmFj
ayBxdWV1ZXMgcHJvY2VzcyBhcmUgc2NoZWR1bGVkLCBvdGhlciB0d28NCj4gcHJvY2VzcyBhcmVu
J3Qgc2NoZWR1bGVkLg0KPiANCj4gSG93IG1hbnkgRG9tMCB2Y3B1IGRvIHlvdSBoYXZlPyBJZiBp
dCBvbmx5IGhhcyB0d28gdGhlbiB0aGVyZSB3aWxsIG9ubHkgYmUNCj4gdHdvIHByb2Nlc3NlcyBy
dW5uaW5nIGF0IGEgdGltZS4NCg0KRG9tMCBoYXMgNiB2Y3B1cywgYW5kIDZHIG1lbW9yeS4gVGhl
cmUgYXJlIG9ubHkgb25lIERvbVUgcnVubmluZyBpbiBEb20wIGFuZCBzbyBmb3VyIG5ldGJhY2sg
cHJvY2Vzc2VzIGFyZSBydW5uaW5nIGluIERvbTAgKGJlY2F1c2UgdGhlIG1heF9xdWV1ZSBwYXJh
bSBvZiBuZXRiYWNrIGtlcm5lbCBtb2R1bGUgaXMgc2V0IHRvIDQpLiANClRoZSBwaGVub21lbm9u
IGlzIHRoYXQgb25seSAyIG9mIHRoZXNlIGZvdXIgbmV0YmFjayBwcm9jZXNzIHdlcmUgcnVubmlu
ZyB3aXRoIGFib3V0IDcwJSBjcHUgdXNhZ2UsIGFuZCBhbm90aGVyIHR3byB1c2UgbGl0dGxlIENQ
VS4NCklzIHRoZXJlIGEgaGFzaCBhbGdvcml0aG0gdG8gZGV0ZXJtaW5lIHdoaWNoIG5ldGJhY2sg
cHJvY2VzcyB0byBoYW5kbGUgdGhlIGlucHV0IHBhY2tldD8NCg0KPiA+DQo+ID4gICAgIEFyZSB0
aGVyZSBhbnkgaXNzdWVzIGluIG15IHRlc3Q/IEluIHRoZW9yeSwgY2FuIHdlIGFjaGlldmUgOX4x
MEdiL3MNCj4gYmV0d2VlbiBEb21VcyBvbiBkaWZmZXJlbnQgaG9zdHMgdXNpbmcgbmV0ZnJvbnQv
bmV0YmFjaz8NCj4gPg0KPiA+ICAgICAgVGhlIHRlc3RpbmcgZW52aXJvbm1lbnQgZGV0YWlscyBh
cmUgYXMgZm9sbG93czoNCj4gPiAgICAxLiBIYXJkd2FyZQ0KPiA+ICAgICAgICBhLiBDUFU6IElu
dGVsKFIpIFhlb24oUikgQ1BVIEU1NjQ1IEAgMi40MEdIeiwgMiBDUFUgNiBDb3JlcyB3aXRoDQo+
IEh5cGVyIFRocmVhZCBlbmFibGVkDQo+ID4gICAgICAgIGIuIE5JQzogSW50ZWwgQ29ycG9yYXRp
b24gODI1OTlFQiAxMC1HaWdhYml0IFNGSS9TRlArIE5ldHdvcmsNCj4gQ29ubmVjdGlvbiAocmV2
IDAxKQ0KPiA+ICAgIDIuIFNvZndhcmU6DQo+ID4gICAgICAgIGEuIEhvc3RPUzogU0xFUyAxMiAo
S2VybmVsIDMuMTYtNyxnaXQgY29tbWl0DQo+ID4gZDAzMzVlNGZlZWEwZDNmN2E4YWYzMTE2YzVk
YzE2NjIzOWRhNzUyMSApDQo+IA0KPiBBbmQgdGhpcyBpcyBhIFN1U0Uga2VybmVsPw0KDQpObywg
SSBqdXN0IGNvbXBpbGUgRG9tMCBhbmQgRG9tVSBrZXJuZWwgdXNpbmcgMy4xNi03IHRhZyBmcm9t
IGtlcm5lbC5vcmcuDQoNCj4gPiAgICAgICAgYi4gTklDIERyaXZlcjogSVhHQkUgMy4yMS4yDQo+
ID4gICAgICAgIGMuIE9WUzogMi4xLjMNCj4gPiAgICAgICAgZC4gTVRVOiAxNjAwDQo+ID4gICAg
ICAgIGUuIERvbTDvvJo2VTZHDQo+ID4gICAgICAgIGYuIHF1ZXVlIG51bWJlcjogNA0KPiA+ICAg
ICAgICBnLiB4ZW4gNC40DQo+ID4gICAgICAgIGguIERvbVU6IDRVNEcNCj4gPiAgICAzLiBOZXR3
b3JraW5nIEVudmlyb25tZW50Og0KPiA+ICAgICAgICBhLiBBbGwgbmV0d29yayBmbG93cyBhcmUg
dHJhbnNtaXQvcmVjZWl2ZSB0aHJvdWdoIE9WUw0KPiA+ICAgICAgICBiLiBTZW5kZXIgc2VydmVy
IGFuZCByZWNlaXZlciBzZXJ2ZXIgYXJlIGNvbm5lY3RlZCBkaXJlY3RseSBiZXR3ZWVuDQo+IDEw
R0UgTklDDQo+ID4gICAgNC4gVGVzdGluZyBUb29sczoNCj4gPiAgICAgICAgYS4gU2VuZGVyOiBu
ZXRwZXJmDQo+ID4gICAgICAgIGIuIFJlY2VpdmVyOiBuZXRzZXJ2ZXINCj4gPg0KPiA+DQo+ID4g
LS0tLS0tLS0tLQ0KPiA+IHpoYW5nbGVpcWlhbmcgKFRydW1wKQ0KPiA+IEJlc3QgUmVnYXJkcw0K
PiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiA+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QNCj4gPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZw0K
PiA+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbA0KPiANCj4gDQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QNCj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcNCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:59:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:59:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvm7A-0006xh-PR; Tue, 02 Dec 2014 11:59: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 1Xvm78-0006xc-Rw
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:59:30 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	D0/E2-20609-2A9AD745; Tue, 02 Dec 2014 11:59:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417521568!12420509!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11613 invoked from network); 2 Dec 2014 11:59:29 -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;
	2 Dec 2014 11:59:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198806400"
Message-ID: <547DA99E.5080001@citrix.com>
Date: Tue, 2 Dec 2014 11:59:26 +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: Juergen Gross <jgross@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.com>
In-Reply-To: <547DA392.90701@suse.com>
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/12/14 11:33, Juergen Gross wrote:
> 
> I think we have customers wanting to run a default kernel as domU. So it
> isn't always the distro refusing paravirt, it might be the user...

I don't think this is a sensible use case but I'm not adverse to
improving the set of Xen config options.

> To sort things out I'd suggest to:
> - make XEN independent from PARAVIRT
> - let XEN_DOM0 select XEN_BACKEND, PARAVIRT, XEN
> - let XEN_BACKEND select PARAVIRT, XEN (I'd like to be able to build
>   a driver domain without XEN_DOM0)
> - introduce XEN_FRONTEND, let it select XEN
> - let frontend drivers and drivers needed by those depend on
>   XEN_FRONTEND
> - let XEN_PVHVM select XEN_FRONTEND

Rather than looking at the current set of configuration options, can you
look at what user-visible functionality or use cases need to be covered
by a (potentially new) set of configuration options?

> - don't skip drivers/xen on make, as XEN might be selected via a
>   config item in that directory

I don't think this matters.

David

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 11:59:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 11:59:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvm7A-0006xh-PR; Tue, 02 Dec 2014 11:59: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 1Xvm78-0006xc-Rw
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 11:59:30 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	D0/E2-20609-2A9AD745; Tue, 02 Dec 2014 11:59:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417521568!12420509!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11613 invoked from network); 2 Dec 2014 11:59:29 -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;
	2 Dec 2014 11:59:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198806400"
Message-ID: <547DA99E.5080001@citrix.com>
Date: Tue, 2 Dec 2014 11:59:26 +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: Juergen Gross <jgross@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.com>
In-Reply-To: <547DA392.90701@suse.com>
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/12/14 11:33, Juergen Gross wrote:
> 
> I think we have customers wanting to run a default kernel as domU. So it
> isn't always the distro refusing paravirt, it might be the user...

I don't think this is a sensible use case but I'm not adverse to
improving the set of Xen config options.

> To sort things out I'd suggest to:
> - make XEN independent from PARAVIRT
> - let XEN_DOM0 select XEN_BACKEND, PARAVIRT, XEN
> - let XEN_BACKEND select PARAVIRT, XEN (I'd like to be able to build
>   a driver domain without XEN_DOM0)
> - introduce XEN_FRONTEND, let it select XEN
> - let frontend drivers and drivers needed by those depend on
>   XEN_FRONTEND
> - let XEN_PVHVM select XEN_FRONTEND

Rather than looking at the current set of configuration options, can you
look at what user-visible functionality or use cases need to be covered
by a (potentially new) set of configuration options?

> - don't skip drivers/xen on make, as XEN might be selected via a
>   config item in that directory

I don't think this matters.

David

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 12:12:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 12: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 1XvmJA-0007cs-Lm; Tue, 02 Dec 2014 12:11:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvmJ9-0007ck-97
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 12:11:55 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	F3/3D-08051-A8CAD745; Tue, 02 Dec 2014 12:11:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417522312!12416356!1
X-Originating-IP: [66.165.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 31246 invoked from network); 2 Dec 2014 12:11:53 -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;
	2 Dec 2014 12:11:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198478905"
Received: from ukmail1.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, 2 Dec 2014 07:11:51 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XvmJ5-0007X0-Ji;
	Tue, 02 Dec 2014 12:11:51 +0000
Date: Tue, 2 Dec 2014 12:11:51 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141202121151.GD5768@zion.uk.xensource.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: "Luohao \(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump) wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei Liu
> > Sent: Tuesday, December 02, 2014 7:02 PM
> > To: zhangleiqiang
> > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > multiqueue support
> > 
> > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > Hi, all
> > >     I am testing the performance of xen netfront-netback driver that with
> > multi-queues support. The throughput from domU to remote dom0 is 9.2Gb/s,
> > but the throughput from domU to remote domU is only 3.6Gb/s, I think the
> > bottleneck is the throughput from dom0 to local domU. However, we have
> > done some testing and found the throughput from dom0 to local domU is
> > 5.8Gb/s.
> > >     And if we send packets from one DomU to other 3 DomUs on different
> > host simultaneously, the sum of throughout can reach 9Gbps. It seems like the
> > bottleneck is the receiver?
> > >     After some analysis, I found that even the max_queue of netfront/back
> > is set to 4, there are some strange results as follows:
> > >     1. In domU, only one rx queue deal with softirq
> > 
> > Try to bind irq to different vcpus?
> 
> Do you mean we try to bind irq to different vcpus in DomU? I will try it now.
> 

Yes. Given the fact that you have two backend threads running while only
one DomU vcpu is busy, it smells like misconfiguration in DomU.

If this phenomenon persists after correctly binding irqs, you might want
to check traffic is steering correctly to different queues.

> > 
> > >     2. In dom0, only two netback queues process are scheduled, other two
> > process aren't scheduled.
> > 
> > How many Dom0 vcpu do you have? If it only has two then there will only be
> > two processes running at a time.
> 
> Dom0 has 6 vcpus, and 6G memory. There are only one DomU running in Dom0 and so four netback processes are running in Dom0 (because the max_queue param of netback kernel module is set to 4). 
> The phenomenon is that only 2 of these four netback process were running with about 70% cpu usage, and another two use little CPU.
> Is there a hash algorithm to determine which netback process to handle the input packet?
> 

I think that's whatever default algorithm Linux kernel is using.

We don't currently support other algorithms.

Wei.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 12:12:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 12: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 1XvmJA-0007cs-Lm; Tue, 02 Dec 2014 12:11:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvmJ9-0007ck-97
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 12:11:55 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	F3/3D-08051-A8CAD745; Tue, 02 Dec 2014 12:11:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417522312!12416356!1
X-Originating-IP: [66.165.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 31246 invoked from network); 2 Dec 2014 12:11:53 -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;
	2 Dec 2014 12:11:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198478905"
Received: from ukmail1.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, 2 Dec 2014 07:11:51 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XvmJ5-0007X0-Ji;
	Tue, 02 Dec 2014 12:11:51 +0000
Date: Tue, 2 Dec 2014 12:11:51 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141202121151.GD5768@zion.uk.xensource.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: "Luohao \(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump) wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei Liu
> > Sent: Tuesday, December 02, 2014 7:02 PM
> > To: zhangleiqiang
> > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > multiqueue support
> > 
> > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > Hi, all
> > >     I am testing the performance of xen netfront-netback driver that with
> > multi-queues support. The throughput from domU to remote dom0 is 9.2Gb/s,
> > but the throughput from domU to remote domU is only 3.6Gb/s, I think the
> > bottleneck is the throughput from dom0 to local domU. However, we have
> > done some testing and found the throughput from dom0 to local domU is
> > 5.8Gb/s.
> > >     And if we send packets from one DomU to other 3 DomUs on different
> > host simultaneously, the sum of throughout can reach 9Gbps. It seems like the
> > bottleneck is the receiver?
> > >     After some analysis, I found that even the max_queue of netfront/back
> > is set to 4, there are some strange results as follows:
> > >     1. In domU, only one rx queue deal with softirq
> > 
> > Try to bind irq to different vcpus?
> 
> Do you mean we try to bind irq to different vcpus in DomU? I will try it now.
> 

Yes. Given the fact that you have two backend threads running while only
one DomU vcpu is busy, it smells like misconfiguration in DomU.

If this phenomenon persists after correctly binding irqs, you might want
to check traffic is steering correctly to different queues.

> > 
> > >     2. In dom0, only two netback queues process are scheduled, other two
> > process aren't scheduled.
> > 
> > How many Dom0 vcpu do you have? If it only has two then there will only be
> > two processes running at a time.
> 
> Dom0 has 6 vcpus, and 6G memory. There are only one DomU running in Dom0 and so four netback processes are running in Dom0 (because the max_queue param of netback kernel module is set to 4). 
> The phenomenon is that only 2 of these four netback process were running with about 70% cpu usage, and another two use little CPU.
> Is there a hash algorithm to determine which netback process to handle the input packet?
> 

I think that's whatever default algorithm Linux kernel is using.

We don't currently support other algorithms.

Wei.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 12:25:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 12: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 1XvmWO-00007r-3e; Tue, 02 Dec 2014 12:25: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 1XvmWM-00007l-VK
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 12:25:35 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	5E/81-02699-EBFAD745; Tue, 02 Dec 2014 12:25:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417523117!12457638!1
X-Originating-IP: [66.165.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 22696 invoked from network); 2 Dec 2014 12:25:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 12:25:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198813259"
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, 2 Dec 2014 07:25: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 1XvmW3-0002Dp-U9;
	Tue, 02 Dec 2014 12:25:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvmW3-0006wp-O3;
	Tue, 02 Dec 2014 12:25:15 +0000
Date: Tue, 2 Dec 2014 12:25:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31983-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] 31983: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 31947

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

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-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-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                b19ca188022d720e6cdf87c43c27cb68bac32f6a
baseline version:
 qemuu                db12451decf7dfe0f083564183e135f2095228b9

------------------------------------------------------------
People who touched revisions under test:
  Gonglei <arei.gonglei@huawei.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                     fail    
 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 b19ca188022d720e6cdf87c43c27cb68bac32f6a
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Fri Nov 28 17:26:29 2014 +0800

    vhost: Fix vhostfd leak in error branch
    
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Message-id: 1417166789-1960-1-git-send-email-arei.gonglei@huawei.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 Tue Dec 02 12:25:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 12: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 1XvmWO-00007r-3e; Tue, 02 Dec 2014 12:25: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 1XvmWM-00007l-VK
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 12:25:35 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	5E/81-02699-EBFAD745; Tue, 02 Dec 2014 12:25:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417523117!12457638!1
X-Originating-IP: [66.165.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 22696 invoked from network); 2 Dec 2014 12:25:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 12:25:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198813259"
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, 2 Dec 2014 07:25: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 1XvmW3-0002Dp-U9;
	Tue, 02 Dec 2014 12:25:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvmW3-0006wp-O3;
	Tue, 02 Dec 2014 12:25:15 +0000
Date: Tue, 2 Dec 2014 12:25:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31983-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] 31983: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 31947

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

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-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-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                b19ca188022d720e6cdf87c43c27cb68bac32f6a
baseline version:
 qemuu                db12451decf7dfe0f083564183e135f2095228b9

------------------------------------------------------------
People who touched revisions under test:
  Gonglei <arei.gonglei@huawei.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                     fail    
 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 b19ca188022d720e6cdf87c43c27cb68bac32f6a
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Fri Nov 28 17:26:29 2014 +0800

    vhost: Fix vhostfd leak in error branch
    
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Message-id: 1417166789-1960-1-git-send-email-arei.gonglei@huawei.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 Tue Dec 02 12:26:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 12: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 1XvmXU-0000EM-IV; Tue, 02 Dec 2014 12:26: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 1XvmXT-0000E7-Gu
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 12:26:43 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	7F/53-24124-200BD745; Tue, 02 Dec 2014 12:26:42 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417523199!11047712!1
X-Originating-IP: [66.165.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 6571 invoked from network); 2 Dec 2014 12:26: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;
	2 Dec 2014 12:26:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198813675"
Received: from ukmail1.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, 2 Dec 2014 07:26: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 1XvmXO-0007z9-9E;
	Tue, 02 Dec 2014 12:26:38 +0000
Date: Tue, 2 Dec 2014 12:26:27 +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: <547CF6C6.4060106@terremark.com>
Message-ID: <alpine.DEB.2.02.1412021158210.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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@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 Mon, 1 Dec 2014, Don Slutz wrote:
> On 12/01/14 10:37, Stefano Stabellini wrote:
> > On Mon, 1 Dec 2014, Don Slutz wrote:
> > > On 11/27/14 05:48, Stefano Stabellini wrote:
> 
> [...]
> 
> > > 
> > > Works fine in both claim modes and with PoD used (maxmem > memory).  Do
> > > not know how to test with tmem.  I do not see how it would be worse then
> > > current
> > > code that does not auto increase.  I.E. even without a xen change, I think
> > > something
> > > like this could be done.
> > OK, good to know. I am OK with increasing maxmem only if it is strictly
> > necessary.
> > 
> > 
> > > > > 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.
> > > Ok.  I did find the 32 it is VGA_HOLE_SIZE.  So here is what I have which
> > > includes
> > > a lot of extra printf.
> > In QEMU I would prefer not to assume that libxl increased maxmem for the
> > vga hole. I would rather call xc_domain_setmaxmem twice for the vga hole
> > than tie QEMU to a particular maxmem allocation scheme in libxl.
> 
> Ok.  The area we are talking about is 0x000a0000 to 0x000c0000.
> It is in libxc (xc_hvm_build_x86), not libxl.   I have no issue with a name
> change to
> some thing like QEMU_EXTRA_FREE_PAGES.

Sorry, I was thinking about the relocated videoram region, the one
allocated by xen_add_to_physmap in QEMU.

Regarding 0x000a0000-0x000c0000, according to this comment:

    /*
     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
     *

xc_hvm_build_x86 shouldn't be allocating memory for it.
In fact if I remember correctly 0xa0000-0xc0000 is trapped and emulated.


> My testing has shows that some of these 32 pages are used outside of QEMU.
> I am seeing just 23 free pages using a standalone program to display
> the same info after a CentOS 6.3 guest is done booting.
>
> > In libxl I would like to avoid increasing mamxem for anything QEMU will
> > allocate later, that includes rom and vga vram. I am not sure how to
> > make that work with older QEMU versions that don't call
> > xc_domain_setmaxmem by themselves yet though. Maybe we could check the
> > specific QEMU version in libxl and decide based on that. Or we could
> > export a feature flag in QEMU.
> 
> Yes, it would be nice to adjust libxl to not increase maxmem. However since
> videoram is included in memory (and maxmem), making the change related
> to vram is a bigger issue.
> 
> the rom change is much simpler.
> 
> Currently I do not know of a way to do different things based on the QEMU
> version
> and/or features (this includes getting the QEMU version in libxl).
> 
> I have been going with:
> 1) change QEMU 1st.
> 2) Wait for an upstream version of QEMU with this.
> 3) change xen to optionally use a feature in the latest QEMU.

Let's try to take this approach for the videoram too


> > 
> > > --- a/xen-hvm.c
> > > +++ b/xen-hvm.c
> > > @@ -67,6 +67,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t
> > > *shared_page, int vcpu)
> > >   #endif
> > > 
> > >   #define BUFFER_IO_MAX_DELAY  100
> > > +#define VGA_HOLE_SIZE (0x20)
> > > 
> > >   typedef struct XenPhysmap {
> > >       hwaddr start_addr;
> > > @@ -219,6 +220,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t
> > > size,
> > > MemoryRegion *mr)
> > >       xen_pfn_t *pfn_list;
> > >       int i;
> > >       xc_dominfo_t info;
> > > +    unsigned long max_pages, free_pages, real_free;
> > > +    long need_pages;
> > > +    uint64_t tot_pages, pod_cache_pages, pod_entries;
> > > +
> > > +    trace_xen_ram_alloc(ram_addr, size, mr->name);
> > > 
> > >       if (runstate_check(RUN_STATE_INMIGRATE)) {
> > >           /* RAM already populated in Xen */
> > > @@ -232,13 +238,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t
> > > size,
> > > MemoryRegion *mr)
> > >           return;
> > >       }
> > > 
> > > -    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
> > > -            " bytes (%ld Kib) of ram at "RAM_ADDR_FMT
> > > -            " mr.name=%s\n",
> > > -            __func__, size, (long)(size>>10), ram_addr, mr->name);
> > > -
> > > -    trace_xen_ram_alloc(ram_addr, size);
> > > -
> > >       nr_pfn = size >> TARGET_PAGE_BITS;
> > >       pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
> > > 
> > > @@ -246,11 +245,38 @@ 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) {
> > > +    if ((xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) ||

I think it's best to call xc_domain_getinfolist.


> > > +       (info.domid != xen_domid)) {
> > >           hw_error("xc_domain_getinfo failed");
> > >       }
> > > -    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;
> > > +    real_free = free_pages;
> > > +    if (free_pages > VGA_HOLE_SIZE) {
> > > +        free_pages -= VGA_HOLE_SIZE;
> > > +    } else {
> > > +        free_pages = 0;
> > > +    }

I don't think we need to subtract VGA_HOLE_SIZE.


> > > +    need_pages = nr_pfn - free_pages;
> > > +    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
> > > +            " bytes (%ld KiB) of ram at "RAM_ADDR_FMT
> > > +            " mp=%ld fp=%ld nr=%ld need=%ld mr.name=%s\n",
> > > +            __func__, size, (long)(size>>10), ram_addr,
> > > +           max_pages, free_pages, nr_pfn, need_pages,
> > > +            mr->name);
> > > +    if (xc_domain_get_pod_target(xen_xc, xen_domid, &tot_pages,
> > > +                                 &pod_cache_pages, &pod_entries) >= 0) {
> > > +        unsigned long populated = tot_pages - pod_cache_pages;
> > > +        long delta_tot = tot_pages - info.nr_pages;
> > > +
> > > +        fprintf(stderr, "%s: PoD pop=%ld tot=%ld(%ld) cnt=%ld ent=%ld
> > > nop=%ld
> > > free=%ld\n",
> > > +                __func__, populated, (long)tot_pages, delta_tot,
> > > +                (long)pod_cache_pages, (long)pod_entries,
> > > +               (long)info.nr_outstanding_pages, real_free);
> > > +    }
> > What is the purpose of calling xc_domain_get_pod_target here? It doesn't
> > look like is affecting the parameters passed to xc_domain_setmaxmem.
> 
> This was just to test and see if anything was needed for PoD mode.
> I did not see anything.
> 
> Did you want me to make a patch to send to the list that has my proposed
> changes?

Yep, that's fine.


> I do think that what I have would be fine to do since most of the time the
> new code does nothing with the current xen (and older versions), until
> more then 4 nics are configured for xen.
> 
> It would be good to have the change:
> 
> [PATCH] libxl_set_memory_target: retain the same maxmem offset on top of the
> current target
> 
> (When working) in xen before using a QEMU with this change.
>
> Not sure I would push for 2.2 however.

I wouldn't.


>    -Don Slutz
> 
> > 
> > > +    if ((free_pages < nr_pfn) &&
> > > +       (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> > > +                            (need_pages * 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)) {
> > > 
> > > 
> > > Note: I already had a trace_xen_ram_alloc, here is the delta in
> > > trace-events
> > > (which
> > > has others not yet sent):
> > > 
> > > 
> > > 
> > > diff --git a/trace-events b/trace-events
> > > index eaeecd5..a58fc11 100644
> > > --- a/trace-events
> > > +++ b/trace-events
> > > @@ -908,7 +908,7 @@ pvscsi_tx_rings_ppn(const char* label, uint64_t ppn)
> > > "%s
> > > page: %"PRIx64""
> > >   pvscsi_tx_rings_num_pages(const char* label, uint32_t num) "Number of %s
> > > pages: %u"
> > > 
> > >   # xen-all.c
> > > -xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested:
> > > %#lx,
> > > size %#lx"
> > > +xen_ram_alloc(unsigned long ram_addr, unsigned long size, const char*
> > > mr_name) "requested: %#lx size %#lx mr->name=%s"
> > >   xen_client_set_memory(uint64_t start_addr, unsigned long size, bool
> > > log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
> > >   handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df,
> > > uint32_t
> > > data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
> > > "I/O=%p type=%d dir=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64"
> > > count=%d
> > > size=%d"
> > >   handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t
> > > data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
> > > "I/O=%p read type=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d
> > > size=%d"
> > > 
> > > 
> > >     -Don Slutz
> > > 
> > > > >      -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 Tue Dec 02 12:26:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 12: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 1XvmXU-0000EM-IV; Tue, 02 Dec 2014 12:26: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 1XvmXT-0000E7-Gu
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 12:26:43 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	7F/53-24124-200BD745; Tue, 02 Dec 2014 12:26:42 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417523199!11047712!1
X-Originating-IP: [66.165.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 6571 invoked from network); 2 Dec 2014 12:26: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;
	2 Dec 2014 12:26:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="198813675"
Received: from ukmail1.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, 2 Dec 2014 07:26: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 1XvmXO-0007z9-9E;
	Tue, 02 Dec 2014 12:26:38 +0000
Date: Tue, 2 Dec 2014 12:26:27 +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: <547CF6C6.4060106@terremark.com>
Message-ID: <alpine.DEB.2.02.1412021158210.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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@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 Mon, 1 Dec 2014, Don Slutz wrote:
> On 12/01/14 10:37, Stefano Stabellini wrote:
> > On Mon, 1 Dec 2014, Don Slutz wrote:
> > > On 11/27/14 05:48, Stefano Stabellini wrote:
> 
> [...]
> 
> > > 
> > > Works fine in both claim modes and with PoD used (maxmem > memory).  Do
> > > not know how to test with tmem.  I do not see how it would be worse then
> > > current
> > > code that does not auto increase.  I.E. even without a xen change, I think
> > > something
> > > like this could be done.
> > OK, good to know. I am OK with increasing maxmem only if it is strictly
> > necessary.
> > 
> > 
> > > > > 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.
> > > Ok.  I did find the 32 it is VGA_HOLE_SIZE.  So here is what I have which
> > > includes
> > > a lot of extra printf.
> > In QEMU I would prefer not to assume that libxl increased maxmem for the
> > vga hole. I would rather call xc_domain_setmaxmem twice for the vga hole
> > than tie QEMU to a particular maxmem allocation scheme in libxl.
> 
> Ok.  The area we are talking about is 0x000a0000 to 0x000c0000.
> It is in libxc (xc_hvm_build_x86), not libxl.   I have no issue with a name
> change to
> some thing like QEMU_EXTRA_FREE_PAGES.

Sorry, I was thinking about the relocated videoram region, the one
allocated by xen_add_to_physmap in QEMU.

Regarding 0x000a0000-0x000c0000, according to this comment:

    /*
     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
     *

xc_hvm_build_x86 shouldn't be allocating memory for it.
In fact if I remember correctly 0xa0000-0xc0000 is trapped and emulated.


> My testing has shows that some of these 32 pages are used outside of QEMU.
> I am seeing just 23 free pages using a standalone program to display
> the same info after a CentOS 6.3 guest is done booting.
>
> > In libxl I would like to avoid increasing mamxem for anything QEMU will
> > allocate later, that includes rom and vga vram. I am not sure how to
> > make that work with older QEMU versions that don't call
> > xc_domain_setmaxmem by themselves yet though. Maybe we could check the
> > specific QEMU version in libxl and decide based on that. Or we could
> > export a feature flag in QEMU.
> 
> Yes, it would be nice to adjust libxl to not increase maxmem. However since
> videoram is included in memory (and maxmem), making the change related
> to vram is a bigger issue.
> 
> the rom change is much simpler.
> 
> Currently I do not know of a way to do different things based on the QEMU
> version
> and/or features (this includes getting the QEMU version in libxl).
> 
> I have been going with:
> 1) change QEMU 1st.
> 2) Wait for an upstream version of QEMU with this.
> 3) change xen to optionally use a feature in the latest QEMU.

Let's try to take this approach for the videoram too


> > 
> > > --- a/xen-hvm.c
> > > +++ b/xen-hvm.c
> > > @@ -67,6 +67,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t
> > > *shared_page, int vcpu)
> > >   #endif
> > > 
> > >   #define BUFFER_IO_MAX_DELAY  100
> > > +#define VGA_HOLE_SIZE (0x20)
> > > 
> > >   typedef struct XenPhysmap {
> > >       hwaddr start_addr;
> > > @@ -219,6 +220,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t
> > > size,
> > > MemoryRegion *mr)
> > >       xen_pfn_t *pfn_list;
> > >       int i;
> > >       xc_dominfo_t info;
> > > +    unsigned long max_pages, free_pages, real_free;
> > > +    long need_pages;
> > > +    uint64_t tot_pages, pod_cache_pages, pod_entries;
> > > +
> > > +    trace_xen_ram_alloc(ram_addr, size, mr->name);
> > > 
> > >       if (runstate_check(RUN_STATE_INMIGRATE)) {
> > >           /* RAM already populated in Xen */
> > > @@ -232,13 +238,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t
> > > size,
> > > MemoryRegion *mr)
> > >           return;
> > >       }
> > > 
> > > -    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
> > > -            " bytes (%ld Kib) of ram at "RAM_ADDR_FMT
> > > -            " mr.name=%s\n",
> > > -            __func__, size, (long)(size>>10), ram_addr, mr->name);
> > > -
> > > -    trace_xen_ram_alloc(ram_addr, size);
> > > -
> > >       nr_pfn = size >> TARGET_PAGE_BITS;
> > >       pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
> > > 
> > > @@ -246,11 +245,38 @@ 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) {
> > > +    if ((xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) ||

I think it's best to call xc_domain_getinfolist.


> > > +       (info.domid != xen_domid)) {
> > >           hw_error("xc_domain_getinfo failed");
> > >       }
> > > -    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;
> > > +    real_free = free_pages;
> > > +    if (free_pages > VGA_HOLE_SIZE) {
> > > +        free_pages -= VGA_HOLE_SIZE;
> > > +    } else {
> > > +        free_pages = 0;
> > > +    }

I don't think we need to subtract VGA_HOLE_SIZE.


> > > +    need_pages = nr_pfn - free_pages;
> > > +    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
> > > +            " bytes (%ld KiB) of ram at "RAM_ADDR_FMT
> > > +            " mp=%ld fp=%ld nr=%ld need=%ld mr.name=%s\n",
> > > +            __func__, size, (long)(size>>10), ram_addr,
> > > +           max_pages, free_pages, nr_pfn, need_pages,
> > > +            mr->name);
> > > +    if (xc_domain_get_pod_target(xen_xc, xen_domid, &tot_pages,
> > > +                                 &pod_cache_pages, &pod_entries) >= 0) {
> > > +        unsigned long populated = tot_pages - pod_cache_pages;
> > > +        long delta_tot = tot_pages - info.nr_pages;
> > > +
> > > +        fprintf(stderr, "%s: PoD pop=%ld tot=%ld(%ld) cnt=%ld ent=%ld
> > > nop=%ld
> > > free=%ld\n",
> > > +                __func__, populated, (long)tot_pages, delta_tot,
> > > +                (long)pod_cache_pages, (long)pod_entries,
> > > +               (long)info.nr_outstanding_pages, real_free);
> > > +    }
> > What is the purpose of calling xc_domain_get_pod_target here? It doesn't
> > look like is affecting the parameters passed to xc_domain_setmaxmem.
> 
> This was just to test and see if anything was needed for PoD mode.
> I did not see anything.
> 
> Did you want me to make a patch to send to the list that has my proposed
> changes?

Yep, that's fine.


> I do think that what I have would be fine to do since most of the time the
> new code does nothing with the current xen (and older versions), until
> more then 4 nics are configured for xen.
> 
> It would be good to have the change:
> 
> [PATCH] libxl_set_memory_target: retain the same maxmem offset on top of the
> current target
> 
> (When working) in xen before using a QEMU with this change.
>
> Not sure I would push for 2.2 however.

I wouldn't.


>    -Don Slutz
> 
> > 
> > > +    if ((free_pages < nr_pfn) &&
> > > +       (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> > > +                            (need_pages * 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)) {
> > > 
> > > 
> > > Note: I already had a trace_xen_ram_alloc, here is the delta in
> > > trace-events
> > > (which
> > > has others not yet sent):
> > > 
> > > 
> > > 
> > > diff --git a/trace-events b/trace-events
> > > index eaeecd5..a58fc11 100644
> > > --- a/trace-events
> > > +++ b/trace-events
> > > @@ -908,7 +908,7 @@ pvscsi_tx_rings_ppn(const char* label, uint64_t ppn)
> > > "%s
> > > page: %"PRIx64""
> > >   pvscsi_tx_rings_num_pages(const char* label, uint32_t num) "Number of %s
> > > pages: %u"
> > > 
> > >   # xen-all.c
> > > -xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested:
> > > %#lx,
> > > size %#lx"
> > > +xen_ram_alloc(unsigned long ram_addr, unsigned long size, const char*
> > > mr_name) "requested: %#lx size %#lx mr->name=%s"
> > >   xen_client_set_memory(uint64_t start_addr, unsigned long size, bool
> > > log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
> > >   handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df,
> > > uint32_t
> > > data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
> > > "I/O=%p type=%d dir=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64"
> > > count=%d
> > > size=%d"
> > >   handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t
> > > data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
> > > "I/O=%p read type=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d
> > > size=%d"
> > > 
> > > 
> > >     -Don Slutz
> > > 
> > > > >      -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 Tue Dec 02 12:36:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 12:36:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvmgE-000101-AJ; Tue, 02 Dec 2014 12:35: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 1XvmgD-0000zl-1t
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 12:35:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0D/6C-09842-022BD745; Tue, 02 Dec 2014 12:35:44 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417523743!12877048!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14998 invoked from network); 2 Dec 2014 12:35:44 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 12:35:44 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so16952965wgh.12
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 04:35: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=MSWwTzaxKFD4GpMdgdFnVMV7hec/dncoLCdk5/yjrnA=;
	b=JnwYaDKaDisXlOJHPTQryeeKVTCwJeUaCprDeif9r+BY8aQK0aI4FfNj/Rc+a1ym3T
	ysd0mXNzgk6vMPcy3ovl6Ls+NRFH2i5RBmewpWK2l4dHqMdBnQuviyxknqUcRobDdQzS
	hPab7q5BSu2iaxOxR2aO4d/56kR3HB/a1l96AhWxb7KJrxaJKBKqk74Gh4v0/9QZf7S/
	xZWzGyRvZk88h8NJR2jAiZy1orQGCZFSi/mB5Y5izmsUezQvpW0K3KuHZnGhqcix+fVT
	v2j6vQBfEfkvRlHApGZh89KncqWKA7npvttts9aF4xblqsfXUD3xXT3huSI1QF0dkwIW
	gkbA==
X-Gm-Message-State: ALoCoQkZCbswlYJjHCxPZCDxdWI7E+t/HK2L+k9vKsZBlY4lLsPDNDLxv9Mx3+y3/zUvZ5ibTOud
X-Received: by 10.180.83.98 with SMTP id p2mr91154372wiy.20.1417523742620;
	Tue, 02 Dec 2014 04:35:42 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id f7sm32595162wiz.13.2014.12.02.04.35.41
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 04:35:41 -0800 (PST)
Message-ID: <547DB21A.3090009@linaro.org>
Date: Tue, 02 Dec 2014 12:35:38 +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: Christoph Egger <chegger@amazon.de>, xen-devel@lists.xen.org
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
	<1417514784-15749-2-git-send-email-chegger@amazon.de>
In-Reply-To: <1417514784-15749-2-git-send-email-chegger@amazon.de>
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/2] gnttab: Introduce rwlock to protect
 updates to grant table 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 Christoph,

On 02/12/14 10:06, Christoph Egger wrote:
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 522c43d..37c13b1 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
>                  mfn = virt_to_mfn(d->shared_info);
>              break;
>          case XENMAPSPACE_grant_table:
> -            spin_lock(&d->grant_table->lock);
> +            write_lock(&d->grant_table->lock);
>  
>              if ( d->grant_table->gt_version == 0 )
>                  d->grant_table->gt_version = 1;
> @@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
>                      mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
>              }
>  
> -            spin_unlock(&d->grant_table->lock);
> +            write_unlock(&d->grant_table->lock);
>              break;
>          case XENMAPSPACE_gmfn_range:
>          case XENMAPSPACE_gmfn:

You forgot to modify the ARM bits which is using the spinlock. See
arch/arm/mm.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 Tue Dec 02 12:36:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 12:36:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvmgE-000101-AJ; Tue, 02 Dec 2014 12:35: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 1XvmgD-0000zl-1t
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 12:35:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0D/6C-09842-022BD745; Tue, 02 Dec 2014 12:35:44 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417523743!12877048!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14998 invoked from network); 2 Dec 2014 12:35:44 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 12:35:44 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so16952965wgh.12
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 04:35: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=MSWwTzaxKFD4GpMdgdFnVMV7hec/dncoLCdk5/yjrnA=;
	b=JnwYaDKaDisXlOJHPTQryeeKVTCwJeUaCprDeif9r+BY8aQK0aI4FfNj/Rc+a1ym3T
	ysd0mXNzgk6vMPcy3ovl6Ls+NRFH2i5RBmewpWK2l4dHqMdBnQuviyxknqUcRobDdQzS
	hPab7q5BSu2iaxOxR2aO4d/56kR3HB/a1l96AhWxb7KJrxaJKBKqk74Gh4v0/9QZf7S/
	xZWzGyRvZk88h8NJR2jAiZy1orQGCZFSi/mB5Y5izmsUezQvpW0K3KuHZnGhqcix+fVT
	v2j6vQBfEfkvRlHApGZh89KncqWKA7npvttts9aF4xblqsfXUD3xXT3huSI1QF0dkwIW
	gkbA==
X-Gm-Message-State: ALoCoQkZCbswlYJjHCxPZCDxdWI7E+t/HK2L+k9vKsZBlY4lLsPDNDLxv9Mx3+y3/zUvZ5ibTOud
X-Received: by 10.180.83.98 with SMTP id p2mr91154372wiy.20.1417523742620;
	Tue, 02 Dec 2014 04:35:42 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id f7sm32595162wiz.13.2014.12.02.04.35.41
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 04:35:41 -0800 (PST)
Message-ID: <547DB21A.3090009@linaro.org>
Date: Tue, 02 Dec 2014 12:35:38 +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: Christoph Egger <chegger@amazon.de>, xen-devel@lists.xen.org
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
	<1417514784-15749-2-git-send-email-chegger@amazon.de>
In-Reply-To: <1417514784-15749-2-git-send-email-chegger@amazon.de>
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/2] gnttab: Introduce rwlock to protect
 updates to grant table 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 Christoph,

On 02/12/14 10:06, Christoph Egger wrote:
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 522c43d..37c13b1 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
>                  mfn = virt_to_mfn(d->shared_info);
>              break;
>          case XENMAPSPACE_grant_table:
> -            spin_lock(&d->grant_table->lock);
> +            write_lock(&d->grant_table->lock);
>  
>              if ( d->grant_table->gt_version == 0 )
>                  d->grant_table->gt_version = 1;
> @@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
>                      mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
>              }
>  
> -            spin_unlock(&d->grant_table->lock);
> +            write_unlock(&d->grant_table->lock);
>              break;
>          case XENMAPSPACE_gmfn_range:
>          case XENMAPSPACE_gmfn:

You forgot to modify the ARM bits which is using the spinlock. See
arch/arm/mm.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 Tue Dec 02 13:01:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13: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 1Xvn4Z-0001i7-QC; Tue, 02 Dec 2014 13:00:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xvn4Y-0001i2-8a
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 13:00:54 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	ED/9C-09842-508BD745; Tue, 02 Dec 2014 13:00:53 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417525252!12825104!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 23107 invoked from network); 2 Dec 2014 13:00:52 -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; 2 Dec 2014 13:00:52 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 49E4CAB43;
	Tue,  2 Dec 2014 13:00:52 +0000 (UTC)
Message-ID: <547DB802.9020900@suse.com>
Date: Tue, 02 Dec 2014 14:00:50 +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>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.com>
	<547DA99E.5080001@citrix.com>
In-Reply-To: <547DA99E.5080001@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 12:59 PM, David Vrabel wrote:
> On 02/12/14 11:33, Juergen Gross wrote:
>>
>> I think we have customers wanting to run a default kernel as domU. So it
>> isn't always the distro refusing paravirt, it might be the user...
>
> I don't think this is a sensible use case but I'm not adverse to
> improving the set of Xen config options.
>
>> To sort things out I'd suggest to:
>> - make XEN independent from PARAVIRT
>> - let XEN_DOM0 select XEN_BACKEND, PARAVIRT, XEN
>> - let XEN_BACKEND select PARAVIRT, XEN (I'd like to be able to build
>>    a driver domain without XEN_DOM0)
>> - introduce XEN_FRONTEND, let it select XEN
>> - let frontend drivers and drivers needed by those depend on
>>    XEN_FRONTEND
>> - let XEN_PVHVM select XEN_FRONTEND
>
> Rather than looking at the current set of configuration options, can you
> look at what user-visible functionality or use cases need to be covered
> by a (potentially new) set of configuration options?

I'd see:
- XEN_PV (selects PARAVIRT, XEN_FRONTEND): be able to run as pv-domain
   (x86 only)
- XEN_PVHVM (selects XEN_FRONTEND): be able to run as hvm-domain with
   pv-drivers
- XEN_BACKEND (selects PARAVIRT if x86): be able to run as driver domain
   (dom0 or other)
- XEN_DOM0 (selects PARAVIRT if x86, XEN_BACKEND): be able to run as
   dom0
- XEN_FRONTEND: be able to run as domU with pv-drivers


Juergen


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 13:01:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13: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 1Xvn4Z-0001i7-QC; Tue, 02 Dec 2014 13:00:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xvn4Y-0001i2-8a
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 13:00:54 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	ED/9C-09842-508BD745; Tue, 02 Dec 2014 13:00:53 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417525252!12825104!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 23107 invoked from network); 2 Dec 2014 13:00:52 -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; 2 Dec 2014 13:00:52 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 49E4CAB43;
	Tue,  2 Dec 2014 13:00:52 +0000 (UTC)
Message-ID: <547DB802.9020900@suse.com>
Date: Tue, 02 Dec 2014 14:00:50 +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>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.com>
	<547DA99E.5080001@citrix.com>
In-Reply-To: <547DA99E.5080001@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 12:59 PM, David Vrabel wrote:
> On 02/12/14 11:33, Juergen Gross wrote:
>>
>> I think we have customers wanting to run a default kernel as domU. So it
>> isn't always the distro refusing paravirt, it might be the user...
>
> I don't think this is a sensible use case but I'm not adverse to
> improving the set of Xen config options.
>
>> To sort things out I'd suggest to:
>> - make XEN independent from PARAVIRT
>> - let XEN_DOM0 select XEN_BACKEND, PARAVIRT, XEN
>> - let XEN_BACKEND select PARAVIRT, XEN (I'd like to be able to build
>>    a driver domain without XEN_DOM0)
>> - introduce XEN_FRONTEND, let it select XEN
>> - let frontend drivers and drivers needed by those depend on
>>    XEN_FRONTEND
>> - let XEN_PVHVM select XEN_FRONTEND
>
> Rather than looking at the current set of configuration options, can you
> look at what user-visible functionality or use cases need to be covered
> by a (potentially new) set of configuration options?

I'd see:
- XEN_PV (selects PARAVIRT, XEN_FRONTEND): be able to run as pv-domain
   (x86 only)
- XEN_PVHVM (selects XEN_FRONTEND): be able to run as hvm-domain with
   pv-drivers
- XEN_BACKEND (selects PARAVIRT if x86): be able to run as driver domain
   (dom0 or other)
- XEN_DOM0 (selects PARAVIRT if x86, XEN_BACKEND): be able to run as
   dom0
- XEN_FRONTEND: be able to run as domU with pv-drivers


Juergen


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 13:03:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13: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 1Xvn7G-0001wI-CB; Tue, 02 Dec 2014 13:03:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1Xvn7E-0001w2-Bk
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 13:03:40 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	75/4E-22777-BA8BD745; Tue, 02 Dec 2014 13:03:39 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417525416!11051804!1
X-Originating-IP: [207.171.178.25]
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 24292 invoked from network); 2 Dec 2014 13:03:37 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 13:03:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417525417; x=1449061417;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=VNWqMmaz1FnD9NHeAPwRCC8YSQPg9k37yyw+naxR2vw=;
	b=H6XUieJqzxjT32D6FkChyBreBav/pKA/MAukjeQWJOC3NY/EgWdLwfjn
	187CDeIDFz0AFn/eeho6LMQYvMH00S9LdsvrquC62VGcCTqsdyf+D4m4+
	w8rtiQmB4vfCPD7YDVEQU8iicoYVX12Jdv7YjKdg04RJI0ABG78sc/5BL Q=;
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="174819520"
Received: from email-inbound-relay-62040.pdx2.amazon.com ([10.241.21.71])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 13:03:35 +0000
Received: from ex10-hub-7002.ant.amazon.com (pdx1-ws-svc-lb16-vlan3.amazon.com
	[10.239.138.214])
	by email-inbound-relay-62040.pdx2.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB2D3YcF028234
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 13:03:35 GMT
Received: from EX13D02UWC003.ant.amazon.com (10.43.162.199) by
	ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 05:03:23 -0800
Received: from a8206654c64f.ant.amazon.com (10.43.162.149) by
	EX13D02UWC003.ant.amazon.com (10.43.162.199) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 13:03:20 +0000
Message-ID: <547DB893.9020605@amazon.de>
Date: Tue, 2 Dec 2014 14:03:15 +0100
From: "Egger, Christoph" <chegger@amazon.de>
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: Julien Grall <julien.grall@linaro.org>, <xen-devel@lists.xen.org>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
	<1417514784-15749-2-git-send-email-chegger@amazon.de>
	<547DB21A.3090009@linaro.org>
In-Reply-To: <547DB21A.3090009@linaro.org>
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D02UWC004.ant.amazon.com (10.43.162.236) To
	EX13D02UWC003.ant.amazon.com (10.43.162.199)
Precedence: Bulk
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/2] gnttab: Introduce rwlock to protect
 updates to grant table state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/02 13:35, Julien Grall wrote:
> Hi Christoph,
> 
> On 02/12/14 10:06, Christoph Egger wrote:
>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>> index 522c43d..37c13b1 100644
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
>>                  mfn = virt_to_mfn(d->shared_info);
>>              break;
>>          case XENMAPSPACE_grant_table:
>> -            spin_lock(&d->grant_table->lock);
>> +            write_lock(&d->grant_table->lock);
>>  
>>              if ( d->grant_table->gt_version == 0 )
>>                  d->grant_table->gt_version = 1;
>> @@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
>>                      mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
>>              }
>>  
>> -            spin_unlock(&d->grant_table->lock);
>> +            write_unlock(&d->grant_table->lock);
>>              break;
>>          case XENMAPSPACE_gmfn_range:
>>          case XENMAPSPACE_gmfn:
> 
> You forgot to modify the ARM bits which is using the spinlock. See
> arch/arm/mm.c

I can do the change. But I don't have ARM hardware nor the build
infrastructure. I need your help with compiling and testing on/for ARM.
Alternatively you can send me a patch I can add to or squash into my
patch series.

Christoph


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 13:03:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13: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 1Xvn7G-0001wI-CB; Tue, 02 Dec 2014 13:03:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1Xvn7E-0001w2-Bk
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 13:03:40 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	75/4E-22777-BA8BD745; Tue, 02 Dec 2014 13:03:39 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417525416!11051804!1
X-Originating-IP: [207.171.178.25]
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 24292 invoked from network); 2 Dec 2014 13:03:37 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 13:03:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417525417; x=1449061417;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=VNWqMmaz1FnD9NHeAPwRCC8YSQPg9k37yyw+naxR2vw=;
	b=H6XUieJqzxjT32D6FkChyBreBav/pKA/MAukjeQWJOC3NY/EgWdLwfjn
	187CDeIDFz0AFn/eeho6LMQYvMH00S9LdsvrquC62VGcCTqsdyf+D4m4+
	w8rtiQmB4vfCPD7YDVEQU8iicoYVX12Jdv7YjKdg04RJI0ABG78sc/5BL Q=;
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="174819520"
Received: from email-inbound-relay-62040.pdx2.amazon.com ([10.241.21.71])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 13:03:35 +0000
Received: from ex10-hub-7002.ant.amazon.com (pdx1-ws-svc-lb16-vlan3.amazon.com
	[10.239.138.214])
	by email-inbound-relay-62040.pdx2.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB2D3YcF028234
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 13:03:35 GMT
Received: from EX13D02UWC003.ant.amazon.com (10.43.162.199) by
	ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 05:03:23 -0800
Received: from a8206654c64f.ant.amazon.com (10.43.162.149) by
	EX13D02UWC003.ant.amazon.com (10.43.162.199) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 13:03:20 +0000
Message-ID: <547DB893.9020605@amazon.de>
Date: Tue, 2 Dec 2014 14:03:15 +0100
From: "Egger, Christoph" <chegger@amazon.de>
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: Julien Grall <julien.grall@linaro.org>, <xen-devel@lists.xen.org>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
	<1417514784-15749-2-git-send-email-chegger@amazon.de>
	<547DB21A.3090009@linaro.org>
In-Reply-To: <547DB21A.3090009@linaro.org>
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D02UWC004.ant.amazon.com (10.43.162.236) To
	EX13D02UWC003.ant.amazon.com (10.43.162.199)
Precedence: Bulk
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/2] gnttab: Introduce rwlock to protect
 updates to grant table state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/02 13:35, Julien Grall wrote:
> Hi Christoph,
> 
> On 02/12/14 10:06, Christoph Egger wrote:
>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>> index 522c43d..37c13b1 100644
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
>>                  mfn = virt_to_mfn(d->shared_info);
>>              break;
>>          case XENMAPSPACE_grant_table:
>> -            spin_lock(&d->grant_table->lock);
>> +            write_lock(&d->grant_table->lock);
>>  
>>              if ( d->grant_table->gt_version == 0 )
>>                  d->grant_table->gt_version = 1;
>> @@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
>>                      mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
>>              }
>>  
>> -            spin_unlock(&d->grant_table->lock);
>> +            write_unlock(&d->grant_table->lock);
>>              break;
>>          case XENMAPSPACE_gmfn_range:
>>          case XENMAPSPACE_gmfn:
> 
> You forgot to modify the ARM bits which is using the spinlock. See
> arch/arm/mm.c

I can do the change. But I don't have ARM hardware nor the build
infrastructure. I need your help with compiling and testing on/for ARM.
Alternatively you can send me a patch I can add to or squash into my
patch series.

Christoph


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 13:08:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13:08:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvnBk-00028I-5S; Tue, 02 Dec 2014 13:08:20 +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 1XvnBi-00028D-LM
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 13:08:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	67/EC-09842-2C9BD745; Tue, 02 Dec 2014 13:08:18 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417525697!12883266!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12893 invoked from network); 2 Dec 2014 13:08:17 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 13:08:17 -0000
Received: by mail-wg0-f50.google.com with SMTP id k14so17007508wgh.9
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 05:08: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
	:content-transfer-encoding;
	bh=6vM7PFD+UrXeu2AxviXikmDNcbITR1s98Yl4vqFAkwA=;
	b=RYFfupXxI6fAOcEfFpWN0bfYdxFxLigYUh39rqvXuLXmIMLdF/dnJ9fmlA4Esx41gw
	lH6XtGWvRSXsJtu8kPG4x/tuT9TNX6S58nscXFsMNrdhMalt3hhDMQetJLlGPbkNnRYN
	Fl+L3Sr9pnq7Z8SB9TJqpfz3zZKlFFM6RLaGS8spD8BT0rxUFP4Q/gKMbPsPsB8CFH5l
	gDiLKqY0VPdy4zv1ZLwgD+P9lOWuicvEUtieLw9xhk3vnuUWil+SakK1teNuha+e9OkL
	TOhwDlbcTby/jAjRPHv9MD6EyNREEVf/5bjNVMWvKDzKCHU0Zwnyabkoprwp7O7BWkPe
	NTDQ==
X-Gm-Message-State: ALoCoQkvyAsxOkP2KNEO1a0gOQDGWUSWurNTFZlpNLM4HVzH1vCI1wE3JCKXbcc8Br8lk3TVdmz9
X-Received: by 10.180.98.233 with SMTP id el9mr90951646wib.3.1417525697323;
	Tue, 02 Dec 2014 05:08:17 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ce1sm31865635wjc.2.2014.12.02.05.08.15
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 05:08:16 -0800 (PST)
Message-ID: <547DB9BC.4040800@linaro.org>
Date: Tue, 02 Dec 2014 13:08:12 +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: "Egger, Christoph" <chegger@amazon.de>, xen-devel@lists.xen.org
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
	<1417514784-15749-2-git-send-email-chegger@amazon.de>
	<547DB21A.3090009@linaro.org> <547DB893.9020605@amazon.de>
In-Reply-To: <547DB893.9020605@amazon.de>
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/2] gnttab: Introduce rwlock to protect
 updates to grant table 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,

On 02/12/14 13:03, Egger, Christoph wrote:
> On 2014/12/02 13:35, Julien Grall wrote:
>> Hi Christoph,
>>
>> On 02/12/14 10:06, Christoph Egger wrote:
>>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>>> index 522c43d..37c13b1 100644
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
>>>                  mfn = virt_to_mfn(d->shared_info);
>>>              break;
>>>          case XENMAPSPACE_grant_table:
>>> -            spin_lock(&d->grant_table->lock);
>>> +            write_lock(&d->grant_table->lock);
>>>  
>>>              if ( d->grant_table->gt_version == 0 )
>>>                  d->grant_table->gt_version = 1;
>>> @@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
>>>                      mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
>>>              }
>>>  
>>> -            spin_unlock(&d->grant_table->lock);
>>> +            write_unlock(&d->grant_table->lock);
>>>              break;
>>>          case XENMAPSPACE_gmfn_range:
>>>          case XENMAPSPACE_gmfn:
>>
>> You forgot to modify the ARM bits which is using the spinlock. See
>> arch/arm/mm.c
> 
> I can do the change. But I don't have ARM hardware nor the build
> infrastructure. I need your help with compiling and testing on/for ARM.
> Alternatively you can send me a patch I can add to or squash into my
> patch series.

I agree that testing the ARM part may require a bit of setup. But
you can easily build testing. only a cross-compiler for ARM is required
for this step. See:

http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions#Building_Xen_on_ARM

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 Dec 02 13:08:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13:08:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvnBk-00028I-5S; Tue, 02 Dec 2014 13:08:20 +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 1XvnBi-00028D-LM
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 13:08:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	67/EC-09842-2C9BD745; Tue, 02 Dec 2014 13:08:18 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417525697!12883266!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12893 invoked from network); 2 Dec 2014 13:08:17 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 13:08:17 -0000
Received: by mail-wg0-f50.google.com with SMTP id k14so17007508wgh.9
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 05:08: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
	:content-transfer-encoding;
	bh=6vM7PFD+UrXeu2AxviXikmDNcbITR1s98Yl4vqFAkwA=;
	b=RYFfupXxI6fAOcEfFpWN0bfYdxFxLigYUh39rqvXuLXmIMLdF/dnJ9fmlA4Esx41gw
	lH6XtGWvRSXsJtu8kPG4x/tuT9TNX6S58nscXFsMNrdhMalt3hhDMQetJLlGPbkNnRYN
	Fl+L3Sr9pnq7Z8SB9TJqpfz3zZKlFFM6RLaGS8spD8BT0rxUFP4Q/gKMbPsPsB8CFH5l
	gDiLKqY0VPdy4zv1ZLwgD+P9lOWuicvEUtieLw9xhk3vnuUWil+SakK1teNuha+e9OkL
	TOhwDlbcTby/jAjRPHv9MD6EyNREEVf/5bjNVMWvKDzKCHU0Zwnyabkoprwp7O7BWkPe
	NTDQ==
X-Gm-Message-State: ALoCoQkvyAsxOkP2KNEO1a0gOQDGWUSWurNTFZlpNLM4HVzH1vCI1wE3JCKXbcc8Br8lk3TVdmz9
X-Received: by 10.180.98.233 with SMTP id el9mr90951646wib.3.1417525697323;
	Tue, 02 Dec 2014 05:08:17 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ce1sm31865635wjc.2.2014.12.02.05.08.15
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 05:08:16 -0800 (PST)
Message-ID: <547DB9BC.4040800@linaro.org>
Date: Tue, 02 Dec 2014 13:08:12 +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: "Egger, Christoph" <chegger@amazon.de>, xen-devel@lists.xen.org
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
	<1417514784-15749-2-git-send-email-chegger@amazon.de>
	<547DB21A.3090009@linaro.org> <547DB893.9020605@amazon.de>
In-Reply-To: <547DB893.9020605@amazon.de>
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/2] gnttab: Introduce rwlock to protect
 updates to grant table 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,

On 02/12/14 13:03, Egger, Christoph wrote:
> On 2014/12/02 13:35, Julien Grall wrote:
>> Hi Christoph,
>>
>> On 02/12/14 10:06, Christoph Egger wrote:
>>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>>> index 522c43d..37c13b1 100644
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
>>>                  mfn = virt_to_mfn(d->shared_info);
>>>              break;
>>>          case XENMAPSPACE_grant_table:
>>> -            spin_lock(&d->grant_table->lock);
>>> +            write_lock(&d->grant_table->lock);
>>>  
>>>              if ( d->grant_table->gt_version == 0 )
>>>                  d->grant_table->gt_version = 1;
>>> @@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
>>>                      mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
>>>              }
>>>  
>>> -            spin_unlock(&d->grant_table->lock);
>>> +            write_unlock(&d->grant_table->lock);
>>>              break;
>>>          case XENMAPSPACE_gmfn_range:
>>>          case XENMAPSPACE_gmfn:
>>
>> You forgot to modify the ARM bits which is using the spinlock. See
>> arch/arm/mm.c
> 
> I can do the change. But I don't have ARM hardware nor the build
> infrastructure. I need your help with compiling and testing on/for ARM.
> Alternatively you can send me a patch I can add to or squash into my
> patch series.

I agree that testing the ARM part may require a bit of setup. But
you can easily build testing. only a cross-compiler for ARM is required
for this step. See:

http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions#Building_Xen_on_ARM

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 Dec 02 13:18:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13:18:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvnLB-0002P0-Ci; Tue, 02 Dec 2014 13:18:05 +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 1XvnL9-0002Ov-NI
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 13:18:03 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	4C/A8-17958-B0CBD745; Tue, 02 Dec 2014 13:18:03 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417526280!15263712!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 21311 invoked from network); 2 Dec 2014 13:18:01 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 13:18:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417526281; x=1449062281;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=YoWUAm+6pGvarfNifeOezQd0mrKea0GPhGPQhOpw9hM=;
	b=fFSaQ+VRiqcUDD/8DjMe09SVaRejtujzeaYOH87eVtsi3ka4+gJvpCeX
	i+A0RIXUCIb25+J77wEtgdWSmwyc2+A8EUTgpNVkvJobUe7kROO2lIGgY
	1g9R69j2R2+3Y4e0MXP9FJmQn2Qd+G08sbhReC8XEcvLRae19IVdtlbsp c=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 02 Dec 2014 13:17:59 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="883409661"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.109.213])
	by fldsmtpi03.verizon.com with ESMTP; 02 Dec 2014 13:17:58 +0000
Message-ID: <547DBC05.9070904@terremark.com>
Date: Tue, 02 Dec 2014 08:17:57 -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.1412021152080.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, dslutz@verizon.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.6] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/14 06:53, Stefano Stabellini wrote:
> 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>
>
> ---
>
> Changes in v2:
> - call libxl_domain_info instead of libxl_dominfo_init;
> - call libxl_domain_info before retry_transaction.
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..569a32a 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
>       char *uuid;
>       xs_transaction_t t;
>   
> +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
> +        goto out_no_transaction;
> +
>   retry_transaction:
>       t = xs_transaction_start(ctx->xsh);
>   
> @@ -4767,10 +4770,9 @@ 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);
> +    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 "

You need to remove LIBXL_MAXMEM_CONSTANT here also.

    -Don Slutz


> @@ -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 Dec 02 13:18:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13:18:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvnLB-0002P0-Ci; Tue, 02 Dec 2014 13:18:05 +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 1XvnL9-0002Ov-NI
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 13:18:03 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	4C/A8-17958-B0CBD745; Tue, 02 Dec 2014 13:18:03 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417526280!15263712!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 21311 invoked from network); 2 Dec 2014 13:18:01 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 13:18:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417526281; x=1449062281;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=YoWUAm+6pGvarfNifeOezQd0mrKea0GPhGPQhOpw9hM=;
	b=fFSaQ+VRiqcUDD/8DjMe09SVaRejtujzeaYOH87eVtsi3ka4+gJvpCeX
	i+A0RIXUCIb25+J77wEtgdWSmwyc2+A8EUTgpNVkvJobUe7kROO2lIGgY
	1g9R69j2R2+3Y4e0MXP9FJmQn2Qd+G08sbhReC8XEcvLRae19IVdtlbsp c=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 02 Dec 2014 13:17:59 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="883409661"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.109.213])
	by fldsmtpi03.verizon.com with ESMTP; 02 Dec 2014 13:17:58 +0000
Message-ID: <547DBC05.9070904@terremark.com>
Date: Tue, 02 Dec 2014 08:17:57 -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.1412021152080.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, dslutz@verizon.com
Subject: Re: [Xen-devel] [PATCH v2 for-4.6] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/14 06:53, Stefano Stabellini wrote:
> 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>
>
> ---
>
> Changes in v2:
> - call libxl_domain_info instead of libxl_dominfo_init;
> - call libxl_domain_info before retry_transaction.
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..569a32a 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
>       char *uuid;
>       xs_transaction_t t;
>   
> +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
> +        goto out_no_transaction;
> +
>   retry_transaction:
>       t = xs_transaction_start(ctx->xsh);
>   
> @@ -4767,10 +4770,9 @@ 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);
> +    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 "

You need to remove LIBXL_MAXMEM_CONSTANT here also.

    -Don Slutz


> @@ -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 Dec 02 13:18:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13:18:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvnM1-0002SN-Qh; Tue, 02 Dec 2014 13:18:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1XvnLz-0002S2-Pp
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 13:18:55 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	AA/75-02954-F3CBD745; Tue, 02 Dec 2014 13:18:55 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417526332!12446164!1
X-Originating-IP: [207.171.189.228]
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 18420 invoked from network); 2 Dec 2014 13:18:54 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 13:18:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417526334; x=1449062334;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=Ay4CMlfp8XIkbc0uhqfAvxEeowc5303+vfrkFYY6paY=;
	b=cXGRy/KrZeJmqJShOWB/2km6mkhI+QJa7KpjO/4b0SNX1Lx1VYMeYFqa
	NL9DpHdWkoTLYzoTDmXdmH2M7cSoynKMU2RM8B+uh9cTSCbHdkvIet2pX
	QOPqfi+0vKn2emasEXuEaVZJuTQtKyRqptblSZ+UORqsmoTUzWOFYMVYu 8=;
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="146450243"
Received: from email-inbound-relay-64002.pdx4.amazon.com ([10.220.169.156])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 13:18:51 +0000
Received: from ex10-hub-7001.ant.amazon.com (pdx1-ws-svc-lb16-vlan3.amazon.com
	[10.239.138.214])
	by email-inbound-relay-64002.pdx4.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB2DIokq018609
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 13:18:50 GMT
Received: from EX13D03UWC004.ant.amazon.com (10.43.162.49) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 05:18:42 -0800
Received: from a8206654c64f.ant.amazon.com (10.43.162.149) by
	EX13D03UWC004.ant.amazon.com (10.43.162.49) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 05:18:38 -0800
Message-ID: <547DBC2A.908@amazon.de>
Date: Tue, 2 Dec 2014 14:18:34 +0100
From: "Egger, Christoph" <chegger@amazon.de>
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: Julien Grall <julien.grall@linaro.org>, <xen-devel@lists.xen.org>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
	<1417514784-15749-2-git-send-email-chegger@amazon.de>
	<547DB21A.3090009@linaro.org> <547DB893.9020605@amazon.de>
	<547DB9BC.4040800@linaro.org>
In-Reply-To: <547DB9BC.4040800@linaro.org>
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D02UWC003.ant.amazon.com (10.43.162.199) To
	EX13D03UWC004.ant.amazon.com (10.43.162.49)
Precedence: Bulk
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/2] gnttab: Introduce rwlock to protect
 updates to grant table state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/02 14:08, Julien Grall wrote:
> Hi,
> 
> On 02/12/14 13:03, Egger, Christoph wrote:
>> On 2014/12/02 13:35, Julien Grall wrote:
>>> Hi Christoph,
>>>
>>> On 02/12/14 10:06, Christoph Egger wrote:
>>>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>>>> index 522c43d..37c13b1 100644
>>>> --- a/xen/arch/x86/mm.c
>>>> +++ b/xen/arch/x86/mm.c
>>>> @@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
>>>>                  mfn = virt_to_mfn(d->shared_info);
>>>>              break;
>>>>          case XENMAPSPACE_grant_table:
>>>> -            spin_lock(&d->grant_table->lock);
>>>> +            write_lock(&d->grant_table->lock);
>>>>  
>>>>              if ( d->grant_table->gt_version == 0 )
>>>>                  d->grant_table->gt_version = 1;
>>>> @@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
>>>>                      mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
>>>>              }
>>>>  
>>>> -            spin_unlock(&d->grant_table->lock);
>>>> +            write_unlock(&d->grant_table->lock);
>>>>              break;
>>>>          case XENMAPSPACE_gmfn_range:
>>>>          case XENMAPSPACE_gmfn:
>>>
>>> You forgot to modify the ARM bits which is using the spinlock. See
>>> arch/arm/mm.c
>>
>> I can do the change. But I don't have ARM hardware nor the build
>> infrastructure. I need your help with compiling and testing on/for ARM.
>> Alternatively you can send me a patch I can add to or squash into my
>> patch series.
> 
> I agree that testing the ARM part may require a bit of setup. But
> you can easily build testing. only a cross-compiler for ARM is required
> for this step. See:
> 
> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions#Building_Xen_on_ARM

Thank you for this pointer.

I just compared xenmem_add_to_physmap_one() x86 and arm versions.
The real architectural functions are virt_to_mfn(), mfn_to_page() and
friends. Everything else in this function is just common code and
can be moved into xen/common/ .

Christoph


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 13:18:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13:18:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvnM1-0002SN-Qh; Tue, 02 Dec 2014 13:18:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1XvnLz-0002S2-Pp
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 13:18:55 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	AA/75-02954-F3CBD745; Tue, 02 Dec 2014 13:18:55 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417526332!12446164!1
X-Originating-IP: [207.171.189.228]
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 18420 invoked from network); 2 Dec 2014 13:18:54 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 13:18:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417526334; x=1449062334;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=Ay4CMlfp8XIkbc0uhqfAvxEeowc5303+vfrkFYY6paY=;
	b=cXGRy/KrZeJmqJShOWB/2km6mkhI+QJa7KpjO/4b0SNX1Lx1VYMeYFqa
	NL9DpHdWkoTLYzoTDmXdmH2M7cSoynKMU2RM8B+uh9cTSCbHdkvIet2pX
	QOPqfi+0vKn2emasEXuEaVZJuTQtKyRqptblSZ+UORqsmoTUzWOFYMVYu 8=;
X-IronPort-AV: E=Sophos;i="5.07,500,1413244800"; d="scan'208";a="146450243"
Received: from email-inbound-relay-64002.pdx4.amazon.com ([10.220.169.156])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 13:18:51 +0000
Received: from ex10-hub-7001.ant.amazon.com (pdx1-ws-svc-lb16-vlan3.amazon.com
	[10.239.138.214])
	by email-inbound-relay-64002.pdx4.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB2DIokq018609
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 13:18:50 GMT
Received: from EX13D03UWC004.ant.amazon.com (10.43.162.49) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 05:18:42 -0800
Received: from a8206654c64f.ant.amazon.com (10.43.162.149) by
	EX13D03UWC004.ant.amazon.com (10.43.162.49) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 05:18:38 -0800
Message-ID: <547DBC2A.908@amazon.de>
Date: Tue, 2 Dec 2014 14:18:34 +0100
From: "Egger, Christoph" <chegger@amazon.de>
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: Julien Grall <julien.grall@linaro.org>, <xen-devel@lists.xen.org>
References: <1417514784-15749-1-git-send-email-chegger@amazon.de>
	<1417514784-15749-2-git-send-email-chegger@amazon.de>
	<547DB21A.3090009@linaro.org> <547DB893.9020605@amazon.de>
	<547DB9BC.4040800@linaro.org>
In-Reply-To: <547DB9BC.4040800@linaro.org>
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D02UWC003.ant.amazon.com (10.43.162.199) To
	EX13D03UWC004.ant.amazon.com (10.43.162.49)
Precedence: Bulk
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/2] gnttab: Introduce rwlock to protect
 updates to grant table state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/02 14:08, Julien Grall wrote:
> Hi,
> 
> On 02/12/14 13:03, Egger, Christoph wrote:
>> On 2014/12/02 13:35, Julien Grall wrote:
>>> Hi Christoph,
>>>
>>> On 02/12/14 10:06, Christoph Egger wrote:
>>>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>>>> index 522c43d..37c13b1 100644
>>>> --- a/xen/arch/x86/mm.c
>>>> +++ b/xen/arch/x86/mm.c
>>>> @@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
>>>>                  mfn = virt_to_mfn(d->shared_info);
>>>>              break;
>>>>          case XENMAPSPACE_grant_table:
>>>> -            spin_lock(&d->grant_table->lock);
>>>> +            write_lock(&d->grant_table->lock);
>>>>  
>>>>              if ( d->grant_table->gt_version == 0 )
>>>>                  d->grant_table->gt_version = 1;
>>>> @@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
>>>>                      mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
>>>>              }
>>>>  
>>>> -            spin_unlock(&d->grant_table->lock);
>>>> +            write_unlock(&d->grant_table->lock);
>>>>              break;
>>>>          case XENMAPSPACE_gmfn_range:
>>>>          case XENMAPSPACE_gmfn:
>>>
>>> You forgot to modify the ARM bits which is using the spinlock. See
>>> arch/arm/mm.c
>>
>> I can do the change. But I don't have ARM hardware nor the build
>> infrastructure. I need your help with compiling and testing on/for ARM.
>> Alternatively you can send me a patch I can add to or squash into my
>> patch series.
> 
> I agree that testing the ARM part may require a bit of setup. But
> you can easily build testing. only a cross-compiler for ARM is required
> for this step. See:
> 
> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions#Building_Xen_on_ARM

Thank you for this pointer.

I just compared xenmem_add_to_physmap_one() x86 and arm versions.
The real architectural functions are virt_to_mfn(), mfn_to_page() and
friends. Everything else in this function is just common code and
can be moved into xen/common/ .

Christoph


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 13:44:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13: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 1XvnkF-00036H-Cc; Tue, 02 Dec 2014 13:43:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvnkD-00036C-L5
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 13:43:57 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	06/9D-28296-C12CD745; Tue, 02 Dec 2014 13:43:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417527833!15295094!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17866 invoked from network); 2 Dec 2014 13:43: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;
	2 Dec 2014 13:43:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198507002"
Message-ID: <1417527800.24320.29.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 2 Dec 2014 13:43:20 +0000
In-Reply-To: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411281648500.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 \(Intern\)" <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, linux@eikelenboom.it,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [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 Fri, 2014-11-28 at 16:53 +0000, Stefano Stabellini wrote:

CCing Boris because he was fixing a similar sounding issue in the same
area. Not sure if this is related to those patches or not.

> 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.

ISTR seeing a conversation along the lines of there being a better
solution which was more 4.6 material, is that right?

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

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

But, I'd prefer to see a version which logs when the qemu side has
failed but it is continuing. Probably just adding right after the
existing if:
        if (rc)
            LOG("Something appropriate");
would do the trick.

Also this needs RM input from Konrad.

> 
> 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 Tue Dec 02 13:44:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13: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 1XvnkF-00036H-Cc; Tue, 02 Dec 2014 13:43:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvnkD-00036C-L5
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 13:43:57 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	06/9D-28296-C12CD745; Tue, 02 Dec 2014 13:43:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417527833!15295094!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17866 invoked from network); 2 Dec 2014 13:43: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;
	2 Dec 2014 13:43:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198507002"
Message-ID: <1417527800.24320.29.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 2 Dec 2014 13:43:20 +0000
In-Reply-To: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411281648500.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 \(Intern\)" <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, linux@eikelenboom.it,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [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 Fri, 2014-11-28 at 16:53 +0000, Stefano Stabellini wrote:

CCing Boris because he was fixing a similar sounding issue in the same
area. Not sure if this is related to those patches or not.

> 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.

ISTR seeing a conversation along the lines of there being a better
solution which was more 4.6 material, is that right?

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

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

But, I'd prefer to see a version which logs when the qemu side has
failed but it is continuing. Probably just adding right after the
existing if:
        if (rc)
            LOG("Something appropriate");
would do the trick.

Also this needs RM input from Konrad.

> 
> 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 Tue Dec 02 13:47:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13:47:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvnnW-0003CT-0D; Tue, 02 Dec 2014 13:47: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 1XvnnU-0003CN-RJ
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:47:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	96/0C-15461-8E2CD745; Tue, 02 Dec 2014 13:47:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417528038!12879267!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 14483 invoked from network); 2 Dec 2014 13:47: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;
	2 Dec 2014 13:47:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198508773"
Message-ID: <1417528036.24320.32.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: Tue, 2 Dec 2014 13:47:16 +0000
In-Reply-To: <20141201121955.GB19889@zion.uk.xensource.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@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, Ed Swierk <eswierk@skyportsystems.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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 Mon, 2014-12-01 at 12:19 +0000, Wei Liu wrote:
> On Mon, Dec 01, 2014 at 09:42:13AM +0000, Ian Campbell wrote:
> > On Sat, 2014-11-29 at 21:23 -0800, Ed Swierk wrote:
> > > - Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
> > >   parameter
> > > - Change deprecated %name-prefix= to %name-prefix
> > > 
> > > Tested against bison 2.4.1 and 3.0.2.
> > > 
> > > Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
> > 
> > Copying Ian J who is the bison guy among the toolstack maintainers.
> > 
> 
> FWIW I can confirm that libxlu_cfg_y.y won't build in Debian Jessie
> (bison 3.0.2) as is. And this patch fixes the problem for me.

That would seem like a pretty strong case for 4.5, *except* we ship the
generated files so it should be possible to build anywhere without
requiring any version of bison at all. If Bison is installed then
"./configure BISON=/bin/true" or some such might be needed to stop it
trying to regenerate.

Konrad, any thoughts.

> 
> Wei.
> 
> > > ---
> > >  tools/libxl/libxlu_cfg_y.y | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
> > > index aa9f787..5acd438 100644
> > > --- a/tools/libxl/libxlu_cfg_y.y
> > > +++ b/tools/libxl/libxlu_cfg_y.y
> > > @@ -17,7 +17,7 @@
> > >   */
> > >  
> > >  %{
> > > -#define YYLEX_PARAM ctx->scanner
> > > +#define ctx_scanner ctx->scanner
> > >  #include "libxlu_cfg_i.h"
> > >  #include "libxlu_cfg_l.h"
> > >  %}
> > > @@ -31,9 +31,9 @@
> > >  %pure-parser
> > >  %defines
> > >  %error-verbose
> > > -%name-prefix="xlu__cfg_yy"
> > > +%name-prefix "xlu__cfg_yy"
> > >  %parse-param { CfgParseContext *ctx }
> > > -%lex-param { void *scanner }
> > > +%lex-param { ctx_scanner }
> > >  
> > >  %token <string>                IDENT STRING NUMBER NEWLINE
> > >  %type <string>            atom
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Dec 02 13:47:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13:47:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvnnW-0003CT-0D; Tue, 02 Dec 2014 13:47: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 1XvnnU-0003CN-RJ
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:47:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	96/0C-15461-8E2CD745; Tue, 02 Dec 2014 13:47:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417528038!12879267!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 14483 invoked from network); 2 Dec 2014 13:47: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;
	2 Dec 2014 13:47:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198508773"
Message-ID: <1417528036.24320.32.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: Tue, 2 Dec 2014 13:47:16 +0000
In-Reply-To: <20141201121955.GB19889@zion.uk.xensource.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@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, Ed Swierk <eswierk@skyportsystems.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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 Mon, 2014-12-01 at 12:19 +0000, Wei Liu wrote:
> On Mon, Dec 01, 2014 at 09:42:13AM +0000, Ian Campbell wrote:
> > On Sat, 2014-11-29 at 21:23 -0800, Ed Swierk wrote:
> > > - Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
> > >   parameter
> > > - Change deprecated %name-prefix= to %name-prefix
> > > 
> > > Tested against bison 2.4.1 and 3.0.2.
> > > 
> > > Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
> > 
> > Copying Ian J who is the bison guy among the toolstack maintainers.
> > 
> 
> FWIW I can confirm that libxlu_cfg_y.y won't build in Debian Jessie
> (bison 3.0.2) as is. And this patch fixes the problem for me.

That would seem like a pretty strong case for 4.5, *except* we ship the
generated files so it should be possible to build anywhere without
requiring any version of bison at all. If Bison is installed then
"./configure BISON=/bin/true" or some such might be needed to stop it
trying to regenerate.

Konrad, any thoughts.

> 
> Wei.
> 
> > > ---
> > >  tools/libxl/libxlu_cfg_y.y | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
> > > index aa9f787..5acd438 100644
> > > --- a/tools/libxl/libxlu_cfg_y.y
> > > +++ b/tools/libxl/libxlu_cfg_y.y
> > > @@ -17,7 +17,7 @@
> > >   */
> > >  
> > >  %{
> > > -#define YYLEX_PARAM ctx->scanner
> > > +#define ctx_scanner ctx->scanner
> > >  #include "libxlu_cfg_i.h"
> > >  #include "libxlu_cfg_l.h"
> > >  %}
> > > @@ -31,9 +31,9 @@
> > >  %pure-parser
> > >  %defines
> > >  %error-verbose
> > > -%name-prefix="xlu__cfg_yy"
> > > +%name-prefix "xlu__cfg_yy"
> > >  %parse-param { CfgParseContext *ctx }
> > > -%lex-param { void *scanner }
> > > +%lex-param { ctx_scanner }
> > >  
> > >  %token <string>                IDENT STRING NUMBER NEWLINE
> > >  %type <string>            atom
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Dec 02 13:50:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvnqn-0003Nh-Pd; Tue, 02 Dec 2014 13:50:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xvnqm-0003Na-SD
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 13:50:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AF/DA-09842-4B3CD745; Tue, 02 Dec 2014 13:50:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417528242!12877440!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 32038 invoked from network); 2 Dec 2014 13:50:43 -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;
	2 Dec 2014 13:50:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198844830"
Message-ID: <1417528237.24320.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 13:50:37 +0000
In-Reply-To: <20141201211456.GH22021@laptop.dumpdata.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
	<1417174732.23604.13.camel@citrix.com>
	<20141201211456.GH22021@laptop.dumpdata.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>, 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 Mon, 2014-12-01 at 16:14 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 28, 2014 at 11:38:52AM +0000, Ian Campbell wrote:
> > 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>
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Did you intend to also ack patch #1? (or have I missed a mail?)




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

From xen-devel-bounces@lists.xen.org Tue Dec 02 13:50:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvnqn-0003Nh-Pd; Tue, 02 Dec 2014 13:50:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xvnqm-0003Na-SD
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 13:50:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AF/DA-09842-4B3CD745; Tue, 02 Dec 2014 13:50:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417528242!12877440!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 32038 invoked from network); 2 Dec 2014 13:50:43 -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;
	2 Dec 2014 13:50:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198844830"
Message-ID: <1417528237.24320.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 13:50:37 +0000
In-Reply-To: <20141201211456.GH22021@laptop.dumpdata.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
	<1417174732.23604.13.camel@citrix.com>
	<20141201211456.GH22021@laptop.dumpdata.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>, 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 Mon, 2014-12-01 at 16:14 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 28, 2014 at 11:38:52AM +0000, Ian Campbell wrote:
> > 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>
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Did you intend to also ack patch #1? (or have I missed a mail?)




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

From xen-devel-bounces@lists.xen.org Tue Dec 02 13:54:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13: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 1XvnuM-0003aB-EB; Tue, 02 Dec 2014 13:54:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvnuL-0003a4-Gk
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:54:25 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	22/1E-25547-094CD745; Tue, 02 Dec 2014 13:54:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417528462!15241615!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20029 invoked from network); 2 Dec 2014 13:54:24 -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;
	2 Dec 2014 13:54:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198511076"
Message-ID: <1417528456.24320.37.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Tue, 2 Dec 2014 13:54:16 +0000
In-Reply-To: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
References: <1417187826-5491-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: MIA2
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@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

On Fri, 2014-11-28 at 15:17 +0000, Julien Grall wrote:
> 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.
> 

When we reschedule the vcpu which caused the spurious interrupt, the IRQ
will definitely trigger again for real, right?

> Signed-off-by: Julien Grall <julien.grall@linaro.org>

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

I'll defer applying until you've said Yes to the above question.

> 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

"interrupts"

> +     * if the timer output signal is masked in the context switch, the
> +     * GIC will keep track that of any interrupts raised while IRQS as

s/as/are/

I'll fix those on commit.



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 13:54:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 13: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 1XvnuM-0003aB-EB; Tue, 02 Dec 2014 13:54:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvnuL-0003a4-Gk
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:54:25 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	22/1E-25547-094CD745; Tue, 02 Dec 2014 13:54:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417528462!15241615!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20029 invoked from network); 2 Dec 2014 13:54:24 -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;
	2 Dec 2014 13:54:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198511076"
Message-ID: <1417528456.24320.37.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Tue, 2 Dec 2014 13:54:16 +0000
In-Reply-To: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
References: <1417187826-5491-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: MIA2
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@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

On Fri, 2014-11-28 at 15:17 +0000, Julien Grall wrote:
> 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.
> 

When we reschedule the vcpu which caused the spurious interrupt, the IRQ
will definitely trigger again for real, right?

> Signed-off-by: Julien Grall <julien.grall@linaro.org>

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

I'll defer applying until you've said Yes to the above question.

> 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

"interrupts"

> +     * if the timer output signal is masked in the context switch, the
> +     * GIC will keep track that of any interrupts raised while IRQS as

s/as/are/

I'll fix those on commit.



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:01:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1Xvo0l-0003nr-Ar; Tue, 02 Dec 2014 14:01: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 1Xvo0j-0003nm-CK
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:01:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2C/34-15461-C16CD745; Tue, 02 Dec 2014 14:01:00 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417528858!12528655!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 2992 invoked from network); 2 Dec 2014 14:01:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:01:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198848438"
Message-ID: <547DC617.8020107@citrix.com>
Date: Tue, 2 Dec 2014 14:00: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: Ian Campbell <Ian.Campbell@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>	<1417426933.23604.77.camel@citrix.com>	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com>
In-Reply-To: <1417528036.24320.32.camel@citrix.com>
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Ed Swierk <eswierk@skyportsystems.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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 02/12/14 13:47, Ian Campbell wrote:
> On Mon, 2014-12-01 at 12:19 +0000, Wei Liu wrote:
>> On Mon, Dec 01, 2014 at 09:42:13AM +0000, Ian Campbell wrote:
>>> On Sat, 2014-11-29 at 21:23 -0800, Ed Swierk wrote:
>>>> - Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
>>>>   parameter
>>>> - Change deprecated %name-prefix= to %name-prefix
>>>>
>>>> Tested against bison 2.4.1 and 3.0.2.
>>>>
>>>> Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
>>> Copying Ian J who is the bison guy among the toolstack maintainers.
>>>
>> FWIW I can confirm that libxlu_cfg_y.y won't build in Debian Jessie
>> (bison 3.0.2) as is. And this patch fixes the problem for me.
> That would seem like a pretty strong case for 4.5, *except* we ship the
> generated files so it should be possible to build anywhere without
> requiring any version of bison at all. If Bison is installed then
> "./configure BISON=/bin/true" or some such might be needed to stop it
> trying to regenerate.
>
> Konrad, any thoughts.

The automatically generating doesn't actually work.  Depending on the
relative timestamps caused by a SCM checkout, or a tarball extraction,
the files will be attempted to be regenerated.

These files are regenerated in the XenServer build, simply because of
their order in the archived tarball.

~Andrew


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:01:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1Xvo0l-0003nr-Ar; Tue, 02 Dec 2014 14:01: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 1Xvo0j-0003nm-CK
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:01:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2C/34-15461-C16CD745; Tue, 02 Dec 2014 14:01:00 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417528858!12528655!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 2992 invoked from network); 2 Dec 2014 14:01:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:01:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198848438"
Message-ID: <547DC617.8020107@citrix.com>
Date: Tue, 2 Dec 2014 14:00: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: Ian Campbell <Ian.Campbell@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>	<1417426933.23604.77.camel@citrix.com>	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com>
In-Reply-To: <1417528036.24320.32.camel@citrix.com>
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Ed Swierk <eswierk@skyportsystems.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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 02/12/14 13:47, Ian Campbell wrote:
> On Mon, 2014-12-01 at 12:19 +0000, Wei Liu wrote:
>> On Mon, Dec 01, 2014 at 09:42:13AM +0000, Ian Campbell wrote:
>>> On Sat, 2014-11-29 at 21:23 -0800, Ed Swierk wrote:
>>>> - Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
>>>>   parameter
>>>> - Change deprecated %name-prefix= to %name-prefix
>>>>
>>>> Tested against bison 2.4.1 and 3.0.2.
>>>>
>>>> Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
>>> Copying Ian J who is the bison guy among the toolstack maintainers.
>>>
>> FWIW I can confirm that libxlu_cfg_y.y won't build in Debian Jessie
>> (bison 3.0.2) as is. And this patch fixes the problem for me.
> That would seem like a pretty strong case for 4.5, *except* we ship the
> generated files so it should be possible to build anywhere without
> requiring any version of bison at all. If Bison is installed then
> "./configure BISON=/bin/true" or some such might be needed to stop it
> trying to regenerate.
>
> Konrad, any thoughts.

The automatically generating doesn't actually work.  Depending on the
relative timestamps caused by a SCM checkout, or a tarball extraction,
the files will be attempted to be regenerated.

These files are regenerated in the XenServer build, simply because of
their order in the archived tarball.

~Andrew


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:03:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:03:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvo3Q-0003xz-SV; Tue, 02 Dec 2014 14:03:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xvo3O-0003xt-TV
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:03:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	60/9A-15461-2C6CD745; Tue, 02 Dec 2014 14:03:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417529024!12853037!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22889 invoked from network); 2 Dec 2014 14:03:45 -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;
	2 Dec 2014 14:03:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198849524"
Message-ID: <1417528978.24320.42.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 2 Dec 2014 14:02:58 +0000
In-Reply-To: <547D276C.2070805@citrix.com>
References: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417174284.23604.9.camel@citrix.com>
	<20141201203001.GE21626@laptop.dumpdata.com>
	<547D276C.2070805@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel@lists.xen.org, Ian.Jackson@eu.citrix.com
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-12-02 at 02:43 +0000, Andrew Cooper wrote:
> On 01/12/2014 20:30, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 28, 2014 at 11:31:24AM +0000, Ian Campbell wrote:
> >> 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.
> > I am bit lost. I thought Andrew NACKed this?
> 
> I didn't, as I am not in a position to.  I have not tested the result,
> but believe it is sufficient to fix the exact error at hand.  If the
> maintainers think it is the best solution then so be it, but I am still
> of the opinion that it is is still a hack upon a hack.

At this point in a freeze I'm much happier with:

 tools/pygrub/src/pygrub |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

than
 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(-)

Plus Boris' patch is far easier to reason about in isolation in a
dynamically/duck typed language.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:03:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:03:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvo3Q-0003xz-SV; Tue, 02 Dec 2014 14:03:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xvo3O-0003xt-TV
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:03:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	60/9A-15461-2C6CD745; Tue, 02 Dec 2014 14:03:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417529024!12853037!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22889 invoked from network); 2 Dec 2014 14:03:45 -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;
	2 Dec 2014 14:03:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198849524"
Message-ID: <1417528978.24320.42.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 2 Dec 2014 14:02:58 +0000
In-Reply-To: <547D276C.2070805@citrix.com>
References: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417174284.23604.9.camel@citrix.com>
	<20141201203001.GE21626@laptop.dumpdata.com>
	<547D276C.2070805@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel@lists.xen.org, Ian.Jackson@eu.citrix.com
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-12-02 at 02:43 +0000, Andrew Cooper wrote:
> On 01/12/2014 20:30, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 28, 2014 at 11:31:24AM +0000, Ian Campbell wrote:
> >> 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.
> > I am bit lost. I thought Andrew NACKed this?
> 
> I didn't, as I am not in a position to.  I have not tested the result,
> but believe it is sufficient to fix the exact error at hand.  If the
> maintainers think it is the best solution then so be it, but I am still
> of the opinion that it is is still a hack upon a hack.

At this point in a freeze I'm much happier with:

 tools/pygrub/src/pygrub |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

than
 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(-)

Plus Boris' patch is far easier to reason about in isolation in a
dynamically/duck typed language.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:08:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1Xvo82-00048A-Iy; Tue, 02 Dec 2014 14:08:34 +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 1Xvo81-000485-Jl
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:08:33 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	05/83-02699-0E7CD745; Tue, 02 Dec 2014 14:08:32 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417529312!12449313!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3671 invoked from network); 2 Dec 2014 14:08:32 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:08:32 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so28174348wid.3
	for <xen-devel@lists.xenproject.org>;
	Tue, 02 Dec 2014 06:08:31 -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=xt38xsD3mEzXY0scYqKj9O3InS0sh7PNGAMlePcUFPM=;
	b=aZkaNsWVPpkzJHBHOgXzvrnPFKCy77r0R5mSxHytOr9FAnuqMvlAtO+SB8zqR4V+Xi
	+YAEVb32FhUSw6DVaKgmvBe6m28mJyfjD/VZWyKZNrbPn62nXmW388CL4EUPVAuFNddx
	tcZQDE42TiXtClAxxkBLWrUyHLFOwoeVOIGo42mmDe5fXBQuHwnp0ri8toBiFwptlafs
	oZiHjBU5V6aGNk4i1lANocu9/iyBvmogk4VSIg76PSyCPyVSjy+ZOMN2KR3SRCnKhokg
	XDiV+mjqM8lTCp45jjS/nCB6D8m2s+9ih27wh9XK6tyNE6ze0f2HAMp1UwPntJQ16fSS
	ljAg==
X-Gm-Message-State: ALoCoQliNQHCafLvOdsOLKnINKTXSKEno/k8GodrBvxEVUgo9KXt/T1ys7bFwSMEagp2/uLZxu4a
X-Received: by 10.180.126.37 with SMTP id mv5mr91651162wib.2.1417529311731;
	Tue, 02 Dec 2014 06:08:31 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id h13sm46565007wiw.4.2014.12.02.06.08.30
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 06:08:30 -0800 (PST)
Message-ID: <547DC7DB.5040305@linaro.org>
Date: Tue, 02 Dec 2014 14:08:27 +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: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
	<1417528456.24320.37.camel@citrix.com>
In-Reply-To: <1417528456.24320.37.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@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

Hi Ian,

On 02/12/14 13:54, Ian Campbell wrote:
> On Fri, 2014-11-28 at 15:17 +0000, Julien Grall wrote:
>> 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.
>>
> 
> When we reschedule the vcpu which caused the spurious interrupt, the IRQ
> will definitely trigger again for real, right?

Xen arms a timer when the domain is saved. As we received an unexpected
interrupt that means the timer expires which will make Xen injected the
virtual timer interrupt (see virt_timer_expired).


>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I'll defer applying until you've said Yes to the above question.
> 
>> 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
> 
> "interrupts"
> 
>> +     * if the timer output signal is masked in the context switch, the
>> +     * GIC will keep track that of any interrupts raised while IRQS as
> 
> s/as/are/
> 
> I'll fix those on commit.

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 Tue Dec 02 14:08:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1Xvo82-00048A-Iy; Tue, 02 Dec 2014 14:08:34 +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 1Xvo81-000485-Jl
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:08:33 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	05/83-02699-0E7CD745; Tue, 02 Dec 2014 14:08:32 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417529312!12449313!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3671 invoked from network); 2 Dec 2014 14:08:32 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:08:32 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so28174348wid.3
	for <xen-devel@lists.xenproject.org>;
	Tue, 02 Dec 2014 06:08:31 -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=xt38xsD3mEzXY0scYqKj9O3InS0sh7PNGAMlePcUFPM=;
	b=aZkaNsWVPpkzJHBHOgXzvrnPFKCy77r0R5mSxHytOr9FAnuqMvlAtO+SB8zqR4V+Xi
	+YAEVb32FhUSw6DVaKgmvBe6m28mJyfjD/VZWyKZNrbPn62nXmW388CL4EUPVAuFNddx
	tcZQDE42TiXtClAxxkBLWrUyHLFOwoeVOIGo42mmDe5fXBQuHwnp0ri8toBiFwptlafs
	oZiHjBU5V6aGNk4i1lANocu9/iyBvmogk4VSIg76PSyCPyVSjy+ZOMN2KR3SRCnKhokg
	XDiV+mjqM8lTCp45jjS/nCB6D8m2s+9ih27wh9XK6tyNE6ze0f2HAMp1UwPntJQ16fSS
	ljAg==
X-Gm-Message-State: ALoCoQliNQHCafLvOdsOLKnINKTXSKEno/k8GodrBvxEVUgo9KXt/T1ys7bFwSMEagp2/uLZxu4a
X-Received: by 10.180.126.37 with SMTP id mv5mr91651162wib.2.1417529311731;
	Tue, 02 Dec 2014 06:08:31 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id h13sm46565007wiw.4.2014.12.02.06.08.30
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 06:08:30 -0800 (PST)
Message-ID: <547DC7DB.5040305@linaro.org>
Date: Tue, 02 Dec 2014 14:08:27 +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: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
	<1417528456.24320.37.camel@citrix.com>
In-Reply-To: <1417528456.24320.37.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@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

Hi Ian,

On 02/12/14 13:54, Ian Campbell wrote:
> On Fri, 2014-11-28 at 15:17 +0000, Julien Grall wrote:
>> 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.
>>
> 
> When we reschedule the vcpu which caused the spurious interrupt, the IRQ
> will definitely trigger again for real, right?

Xen arms a timer when the domain is saved. As we received an unexpected
interrupt that means the timer expires which will make Xen injected the
virtual timer interrupt (see virt_timer_expired).


>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I'll defer applying until you've said Yes to the above question.
> 
>> 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
> 
> "interrupts"
> 
>> +     * if the timer output signal is masked in the context switch, the
>> +     * GIC will keep track that of any interrupts raised while IRQS as
> 
> s/as/are/
> 
> I'll fix those on commit.

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 Tue Dec 02 14:09:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:09:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvo8x-0004Bk-0e; Tue, 02 Dec 2014 14:09:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xvo8v-0004Be-Ll
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 14:09:29 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	B9/21-17694-818CD745; Tue, 02 Dec 2014 14:09:28 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417529365!15147052!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5443 invoked from network); 2 Dec 2014 14:09:27 -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;
	2 Dec 2014 14:09:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198853050"
Message-ID: <547DC80A.10301@citrix.com>
Date: Tue, 2 Dec 2014 14:09:14 +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: Juergen Gross <jgross@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.com>
	<547DA99E.5080001@citrix.com> <547DB802.9020900@suse.com>
In-Reply-To: <547DB802.9020900@suse.com>
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/12/14 13:00, Juergen Gross wrote:
> 
> I'd see:
> - XEN_PV (selects PARAVIRT, XEN_FRONTEND): be able to run as pv-domain
>   (x86 only)

Depends on PARAVIRT perhaps?

> - XEN_PVHVM (selects XEN_FRONTEND): be able to run as hvm-domain with
>   pv-drivers
> - XEN_BACKEND (selects PARAVIRT if x86): be able to run as driver domain
>   (dom0 or other)

Does not need to select PARAVIRT -- HVM domains can run backends.

> - XEN_DOM0 (selects PARAVIRT if x86, XEN_BACKEND): be able to run as
>   dom0

XEN_DOM0 depends on XEN_PV or XEN_PVH (if x86) and whatever ARM needs.

> - XEN_FRONTEND: be able to run as domU with pv-drivers

It may also be interesting to consider splitting the PV MMU stuff under
a PARAVIRT_MMU option.  This might address a reason why people want to
disable PARAVIRT completely.

David

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:09:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:09:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvo8x-0004Bk-0e; Tue, 02 Dec 2014 14:09:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xvo8v-0004Be-Ll
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 14:09:29 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	B9/21-17694-818CD745; Tue, 02 Dec 2014 14:09:28 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417529365!15147052!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5443 invoked from network); 2 Dec 2014 14:09:27 -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;
	2 Dec 2014 14:09:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198853050"
Message-ID: <547DC80A.10301@citrix.com>
Date: Tue, 2 Dec 2014 14:09:14 +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: Juergen Gross <jgross@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.com>
	<547DA99E.5080001@citrix.com> <547DB802.9020900@suse.com>
In-Reply-To: <547DB802.9020900@suse.com>
X-DLP: MIA1
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/12/14 13:00, Juergen Gross wrote:
> 
> I'd see:
> - XEN_PV (selects PARAVIRT, XEN_FRONTEND): be able to run as pv-domain
>   (x86 only)

Depends on PARAVIRT perhaps?

> - XEN_PVHVM (selects XEN_FRONTEND): be able to run as hvm-domain with
>   pv-drivers
> - XEN_BACKEND (selects PARAVIRT if x86): be able to run as driver domain
>   (dom0 or other)

Does not need to select PARAVIRT -- HVM domains can run backends.

> - XEN_DOM0 (selects PARAVIRT if x86, XEN_BACKEND): be able to run as
>   dom0

XEN_DOM0 depends on XEN_PV or XEN_PVH (if x86) and whatever ARM needs.

> - XEN_FRONTEND: be able to run as domU with pv-drivers

It may also be interesting to consider splitting the PV MMU stuff under
a PARAVIRT_MMU option.  This might address a reason why people want to
disable PARAVIRT completely.

David

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:21:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1XvoJf-0004UA-LN; Tue, 02 Dec 2014 14:20: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 1XvoJe-0004U5-FQ
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:20:34 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	44/8E-29352-1BACD745; Tue, 02 Dec 2014 14:20:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417530027!5788313!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 20292 invoked from network); 2 Dec 2014 14:20:31 -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;
	2 Dec 2014 14:20:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198523841"
Message-ID: <1417529989.24320.48.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 2 Dec 2014 14:19:49 +0000
In-Reply-To: <1417433473-17272-3-git-send-email-wei.liu2@citrix.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<1417433473-17272-3-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
Content-Length: 1662
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 2/2] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDE0LTEyLTAxIGF0IDExOjMxICswMDAwLCBXZWkgTGl1IHdyb3RlOgo+IEZyZWUg
c3RyaW5ncyByZXR1cm5lZCBieSBsaWJ4bF9iYXNlbmFtZSBhZnRlciB1c2VkLgo+IAo+IFNpZ25l
ZC1vZmYtYnk6IFdlaSBMaXUgPHdlaS5saXUyQGNpdHJpeC5jb20+Cj4gQ2M6IElhbiBDYW1wYmVs
bCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Cj4gQ2M6IElhbiBKYWNrc29uIDxpYW4uamFja3Nv
bkBldS5jaXRyaXguY29tPgo+IC0tLQo+ICB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMgfCAgICA4
ICsrKysrKy0tCj4gIDEgZmlsZSBjaGFuZ2VkLCA2IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25z
KC0pCj4gCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xp
YnhsL3hsX2NtZGltcGwuYwo+IGluZGV4IDBlNzU0ZTcuLmZlMzAzNGYgMTAwNjQ0Cj4gLS0tIGEv
dG9vbHMvbGlieGwveGxfY21kaW1wbC5jCj4gKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5j
Cj4gQEAgLTkyMCw2ICs5MjAsNyBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShjb25z
dCBjaGFyICpjb25maWdfc291cmNlLAo+ICAgICAgaW50IHBjaV9wZXJtaXNzaXZlID0gMDsKPiAg
ICAgIGludCBwY2lfc2VpemUgPSAwOwo+ICAgICAgaW50IGksIGU7Cj4gKyAgICBjaGFyICpiYXNl
bmFtZTsKCkZvciBzb21lIHJlYXNvbiBvbiBhcm0zMiAob25seSkgdGhpcyBjYXVzZXM6CnhsX2Nt
ZGltcGwuYzogSW4gZnVuY3Rpb24g4oCYcGFyc2VfY29uZmlnX2RhdGHigJk6CnhsX2NtZGltcGwu
Yzo5Mjk6MTE6IGVycm9yOiBkZWNsYXJhdGlvbiBvZiDigJhiYXNlbmFtZeKAmSBzaGFkb3dzIGEg
Z2xvYmFsIGRlY2xhcmF0aW9uIFstV2Vycm9yPXNoYWRvd10KCmJhc2VuYW1lKDMpIGlzIGRlZmlu
ZWQgYnkgbGliZ2VuLmggd2hpY2ggd2UgZG9uJ3QgaW5jbHVkZSwgc28gSSBzdXNwZWN0CnRoaXMg
aXMgYSBsaWJjIGlzc3VlIG9uIGFybWhmICh1bmxlc3MgSWFuIGhhcyBhbnkgb3RoZXIgaWRlYXM/
KS4KCkhvdyBhYm91dCBJIHMvYmFzZW5hbWUva2VybmVsX2Jhc2VuYW1lLyBvciBzb21lIHN1Y2gg
b24gY29tbWl0PwoKSWFuLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:21:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1XvoJf-0004UA-LN; Tue, 02 Dec 2014 14:20: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 1XvoJe-0004U5-FQ
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:20:34 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	44/8E-29352-1BACD745; Tue, 02 Dec 2014 14:20:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417530027!5788313!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 20292 invoked from network); 2 Dec 2014 14:20:31 -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;
	2 Dec 2014 14:20:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198523841"
Message-ID: <1417529989.24320.48.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 2 Dec 2014 14:19:49 +0000
In-Reply-To: <1417433473-17272-3-git-send-email-wei.liu2@citrix.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<1417433473-17272-3-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
Content-Length: 1662
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 2/2] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDE0LTEyLTAxIGF0IDExOjMxICswMDAwLCBXZWkgTGl1IHdyb3RlOgo+IEZyZWUg
c3RyaW5ncyByZXR1cm5lZCBieSBsaWJ4bF9iYXNlbmFtZSBhZnRlciB1c2VkLgo+IAo+IFNpZ25l
ZC1vZmYtYnk6IFdlaSBMaXUgPHdlaS5saXUyQGNpdHJpeC5jb20+Cj4gQ2M6IElhbiBDYW1wYmVs
bCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Cj4gQ2M6IElhbiBKYWNrc29uIDxpYW4uamFja3Nv
bkBldS5jaXRyaXguY29tPgo+IC0tLQo+ICB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMgfCAgICA4
ICsrKysrKy0tCj4gIDEgZmlsZSBjaGFuZ2VkLCA2IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25z
KC0pCj4gCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xp
YnhsL3hsX2NtZGltcGwuYwo+IGluZGV4IDBlNzU0ZTcuLmZlMzAzNGYgMTAwNjQ0Cj4gLS0tIGEv
dG9vbHMvbGlieGwveGxfY21kaW1wbC5jCj4gKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5j
Cj4gQEAgLTkyMCw2ICs5MjAsNyBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShjb25z
dCBjaGFyICpjb25maWdfc291cmNlLAo+ICAgICAgaW50IHBjaV9wZXJtaXNzaXZlID0gMDsKPiAg
ICAgIGludCBwY2lfc2VpemUgPSAwOwo+ICAgICAgaW50IGksIGU7Cj4gKyAgICBjaGFyICpiYXNl
bmFtZTsKCkZvciBzb21lIHJlYXNvbiBvbiBhcm0zMiAob25seSkgdGhpcyBjYXVzZXM6CnhsX2Nt
ZGltcGwuYzogSW4gZnVuY3Rpb24g4oCYcGFyc2VfY29uZmlnX2RhdGHigJk6CnhsX2NtZGltcGwu
Yzo5Mjk6MTE6IGVycm9yOiBkZWNsYXJhdGlvbiBvZiDigJhiYXNlbmFtZeKAmSBzaGFkb3dzIGEg
Z2xvYmFsIGRlY2xhcmF0aW9uIFstV2Vycm9yPXNoYWRvd10KCmJhc2VuYW1lKDMpIGlzIGRlZmlu
ZWQgYnkgbGliZ2VuLmggd2hpY2ggd2UgZG9uJ3QgaW5jbHVkZSwgc28gSSBzdXNwZWN0CnRoaXMg
aXMgYSBsaWJjIGlzc3VlIG9uIGFybWhmICh1bmxlc3MgSWFuIGhhcyBhbnkgb3RoZXIgaWRlYXM/
KS4KCkhvdyBhYm91dCBJIHMvYmFzZW5hbWUva2VybmVsX2Jhc2VuYW1lLyBvciBzb21lIHN1Y2gg
b24gY29tbWl0PwoKSWFuLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:22:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:22:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvoL8-0004c6-AT; Tue, 02 Dec 2014 14:22: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 1XvoL7-0004c0-3l
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:22:05 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	05/0A-09842-C0BCD745; Tue, 02 Dec 2014 14:22:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417530122!12822232!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8903 invoked from network); 2 Dec 2014 14:22: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;
	2 Dec 2014 14:22:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198859313"
Message-ID: <1417530117.24320.50.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Tue, 2 Dec 2014 14:21:57 +0000
In-Reply-To: <547DC7DB.5040305@linaro.org>
References: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
	<1417528456.24320.37.camel@citrix.com> <547DC7DB.5040305@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] 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

On Tue, 2014-12-02 at 14:08 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 02/12/14 13:54, Ian Campbell wrote:
> > On Fri, 2014-11-28 at 15:17 +0000, Julien Grall wrote:
> >> 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.
> >>
> > 
> > When we reschedule the vcpu which caused the spurious interrupt, the IRQ
> > will definitely trigger again for real, right?
> 
> Xen arms a timer when the domain is saved. As we received an unexpected
> interrupt that means the timer expires which will make Xen injected the
> virtual timer interrupt (see virt_timer_expired).

Are we sure there is no race here where the software timer doesn't fire
because it appears to be in the past or something?

That would correspond to the sequence:
   disable interrupts
   h/w timer expires, interrupt raised but masked
   calculate timeout for s/w timeout => -ve.

Perhaps Xen s/w timers in the past fire immediately?



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:22:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:22:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvoL8-0004c6-AT; Tue, 02 Dec 2014 14:22: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 1XvoL7-0004c0-3l
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:22:05 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	05/0A-09842-C0BCD745; Tue, 02 Dec 2014 14:22:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417530122!12822232!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8903 invoked from network); 2 Dec 2014 14:22: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;
	2 Dec 2014 14:22:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198859313"
Message-ID: <1417530117.24320.50.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Tue, 2 Dec 2014 14:21:57 +0000
In-Reply-To: <547DC7DB.5040305@linaro.org>
References: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
	<1417528456.24320.37.camel@citrix.com> <547DC7DB.5040305@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] 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

On Tue, 2014-12-02 at 14:08 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 02/12/14 13:54, Ian Campbell wrote:
> > On Fri, 2014-11-28 at 15:17 +0000, Julien Grall wrote:
> >> 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.
> >>
> > 
> > When we reschedule the vcpu which caused the spurious interrupt, the IRQ
> > will definitely trigger again for real, right?
> 
> Xen arms a timer when the domain is saved. As we received an unexpected
> interrupt that means the timer expires which will make Xen injected the
> virtual timer interrupt (see virt_timer_expired).

Are we sure there is no race here where the software timer doesn't fire
because it appears to be in the past or something?

That would correspond to the sequence:
   disable interrupts
   h/w timer expires, interrupt raised but masked
   calculate timeout for s/w timeout => -ve.

Perhaps Xen s/w timers in the past fire immediately?



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:24:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1XvoNO-0004ny-Tt; Tue, 02 Dec 2014 14:24:26 +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 1XvoNN-0004np-Ud
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:24:26 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	E6/E1-18267-99BCD745; Tue, 02 Dec 2014 14:24:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417530262!11558209!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13335 invoked from network); 2 Dec 2014 14:24: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;
	2 Dec 2014 14:24:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198525939"
Received: from ukmail1.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, 2 Dec 2014 09:23:26 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XvoMQ-0001oK-07;
	Tue, 02 Dec 2014 14:23:26 +0000
Date: Tue, 2 Dec 2014 14:23:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202142325.GG5768@zion.uk.xensource.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<1417433473-17272-3-git-send-email-wei.liu2@citrix.com>
	<1417529989.24320.48.camel@citrix.com>
MIME-Version: 1.0
Content-Length: 1848
Content-Disposition: inline
In-Reply-To: <1417529989.24320.48.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 2/2] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBEZWMgMDIsIDIwMTQgYXQgMDI6MTk6NDlQTSArMDAwMCwgSWFuIENhbXBiZWxsIHdy
b3RlOgo+IE9uIE1vbiwgMjAxNC0xMi0wMSBhdCAxMTozMSArMDAwMCwgV2VpIExpdSB3cm90ZToK
PiA+IEZyZWUgc3RyaW5ncyByZXR1cm5lZCBieSBsaWJ4bF9iYXNlbmFtZSBhZnRlciB1c2VkLgo+
ID4gCj4gPiBTaWduZWQtb2ZmLWJ5OiBXZWkgTGl1IDx3ZWkubGl1MkBjaXRyaXguY29tPgo+ID4g
Q2M6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Cj4gPiBDYzogSWFuIEph
Y2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Cj4gPiAtLS0KPiA+ICB0b29scy9saWJ4
bC94bF9jbWRpbXBsLmMgfCAgICA4ICsrKysrKy0tCj4gPiAgMSBmaWxlIGNoYW5nZWQsIDYgaW5z
ZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKPiA+IAo+ID4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xp
YnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwo+ID4gaW5kZXggMGU3
NTRlNy4uZmUzMDM0ZiAxMDA2NDQKPiA+IC0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwo+
ID4gKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCj4gPiBAQCAtOTIwLDYgKzkyMCw3IEBA
IHN0YXRpYyB2b2lkIHBhcnNlX2NvbmZpZ19kYXRhKGNvbnN0IGNoYXIgKmNvbmZpZ19zb3VyY2Us
Cj4gPiAgICAgIGludCBwY2lfcGVybWlzc2l2ZSA9IDA7Cj4gPiAgICAgIGludCBwY2lfc2VpemUg
PSAwOwo+ID4gICAgICBpbnQgaSwgZTsKPiA+ICsgICAgY2hhciAqYmFzZW5hbWU7Cj4gCj4gRm9y
IHNvbWUgcmVhc29uIG9uIGFybTMyIChvbmx5KSB0aGlzIGNhdXNlczoKPiB4bF9jbWRpbXBsLmM6
IEluIGZ1bmN0aW9uIOKAmHBhcnNlX2NvbmZpZ19kYXRh4oCZOgo+IHhsX2NtZGltcGwuYzo5Mjk6
MTE6IGVycm9yOiBkZWNsYXJhdGlvbiBvZiDigJhiYXNlbmFtZeKAmSBzaGFkb3dzIGEgZ2xvYmFs
IGRlY2xhcmF0aW9uIFstV2Vycm9yPXNoYWRvd10KPiAKPiBiYXNlbmFtZSgzKSBpcyBkZWZpbmVk
IGJ5IGxpYmdlbi5oIHdoaWNoIHdlIGRvbid0IGluY2x1ZGUsIHNvIEkgc3VzcGVjdAo+IHRoaXMg
aXMgYSBsaWJjIGlzc3VlIG9uIGFybWhmICh1bmxlc3MgSWFuIGhhcyBhbnkgb3RoZXIgaWRlYXM/
KS4KPiAKPiBIb3cgYWJvdXQgSSBzL2Jhc2VuYW1lL2tlcm5lbF9iYXNlbmFtZS8gb3Igc29tZSBz
dWNoIG9uIGNvbW1pdD8KPiAKClRoYXQncyBPSy4KCldlaS4KCj4gSWFuLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:24:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1XvoNO-0004ny-Tt; Tue, 02 Dec 2014 14:24:26 +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 1XvoNN-0004np-Ud
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:24:26 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	E6/E1-18267-99BCD745; Tue, 02 Dec 2014 14:24:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417530262!11558209!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13335 invoked from network); 2 Dec 2014 14:24: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;
	2 Dec 2014 14:24:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198525939"
Received: from ukmail1.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, 2 Dec 2014 09:23:26 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XvoMQ-0001oK-07;
	Tue, 02 Dec 2014 14:23:26 +0000
Date: Tue, 2 Dec 2014 14:23:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202142325.GG5768@zion.uk.xensource.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<1417433473-17272-3-git-send-email-wei.liu2@citrix.com>
	<1417529989.24320.48.camel@citrix.com>
MIME-Version: 1.0
Content-Length: 1848
Content-Disposition: inline
In-Reply-To: <1417529989.24320.48.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 2/2] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBEZWMgMDIsIDIwMTQgYXQgMDI6MTk6NDlQTSArMDAwMCwgSWFuIENhbXBiZWxsIHdy
b3RlOgo+IE9uIE1vbiwgMjAxNC0xMi0wMSBhdCAxMTozMSArMDAwMCwgV2VpIExpdSB3cm90ZToK
PiA+IEZyZWUgc3RyaW5ncyByZXR1cm5lZCBieSBsaWJ4bF9iYXNlbmFtZSBhZnRlciB1c2VkLgo+
ID4gCj4gPiBTaWduZWQtb2ZmLWJ5OiBXZWkgTGl1IDx3ZWkubGl1MkBjaXRyaXguY29tPgo+ID4g
Q2M6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Cj4gPiBDYzogSWFuIEph
Y2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Cj4gPiAtLS0KPiA+ICB0b29scy9saWJ4
bC94bF9jbWRpbXBsLmMgfCAgICA4ICsrKysrKy0tCj4gPiAgMSBmaWxlIGNoYW5nZWQsIDYgaW5z
ZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKPiA+IAo+ID4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xp
YnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwo+ID4gaW5kZXggMGU3
NTRlNy4uZmUzMDM0ZiAxMDA2NDQKPiA+IC0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwo+
ID4gKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCj4gPiBAQCAtOTIwLDYgKzkyMCw3IEBA
IHN0YXRpYyB2b2lkIHBhcnNlX2NvbmZpZ19kYXRhKGNvbnN0IGNoYXIgKmNvbmZpZ19zb3VyY2Us
Cj4gPiAgICAgIGludCBwY2lfcGVybWlzc2l2ZSA9IDA7Cj4gPiAgICAgIGludCBwY2lfc2VpemUg
PSAwOwo+ID4gICAgICBpbnQgaSwgZTsKPiA+ICsgICAgY2hhciAqYmFzZW5hbWU7Cj4gCj4gRm9y
IHNvbWUgcmVhc29uIG9uIGFybTMyIChvbmx5KSB0aGlzIGNhdXNlczoKPiB4bF9jbWRpbXBsLmM6
IEluIGZ1bmN0aW9uIOKAmHBhcnNlX2NvbmZpZ19kYXRh4oCZOgo+IHhsX2NtZGltcGwuYzo5Mjk6
MTE6IGVycm9yOiBkZWNsYXJhdGlvbiBvZiDigJhiYXNlbmFtZeKAmSBzaGFkb3dzIGEgZ2xvYmFs
IGRlY2xhcmF0aW9uIFstV2Vycm9yPXNoYWRvd10KPiAKPiBiYXNlbmFtZSgzKSBpcyBkZWZpbmVk
IGJ5IGxpYmdlbi5oIHdoaWNoIHdlIGRvbid0IGluY2x1ZGUsIHNvIEkgc3VzcGVjdAo+IHRoaXMg
aXMgYSBsaWJjIGlzc3VlIG9uIGFybWhmICh1bmxlc3MgSWFuIGhhcyBhbnkgb3RoZXIgaWRlYXM/
KS4KPiAKPiBIb3cgYWJvdXQgSSBzL2Jhc2VuYW1lL2tlcm5lbF9iYXNlbmFtZS8gb3Igc29tZSBz
dWNoIG9uIGNvbW1pdD8KPiAKClRoYXQncyBPSy4KCldlaS4KCj4gSWFuLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:27:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1XvoPl-0004wn-KU; Tue, 02 Dec 2014 14:26: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 1XvoPk-0004wc-9m
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 14:26:52 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	22/47-22777-B2CCD745; Tue, 02 Dec 2014 14:26:51 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417530409!11081658!1
X-Originating-IP: [66.165.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 21883 invoked from network); 2 Dec 2014 14:26: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;
	2 Dec 2014 14:26:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198527813"
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, 2 Dec 2014 09:26: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 1XvoPg-0001tK-1r;
	Tue, 02 Dec 2014 14:26:48 +0000
Date: Tue, 2 Dec 2014 14:26:37 +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: <547DBC05.9070904@terremark.com>
Message-ID: <alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.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>, 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: Re: [Xen-devel] [PATCH v2 for-4.6] 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

On Tue, 2 Dec 2014, Don Slutz wrote:
> On 12/02/14 06:53, Stefano Stabellini wrote:
> > 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>
> > 
> > ---
> > 
> > Changes in v2:
> > - call libxl_domain_info instead of libxl_dominfo_init;
> > - call libxl_domain_info before retry_transaction.
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index de23fec..569a32a 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
> > domid,
> >       char *uuid;
> >       xs_transaction_t t;
> >   +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
> > +        goto out_no_transaction;
> > +
> >   retry_transaction:
> >       t = xs_transaction_start(ctx->xsh);
> >   @@ -4767,10 +4770,9 @@ 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);
> > +    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 "
> 
> You need to remove LIBXL_MAXMEM_CONSTANT here also.

I don't think so: LIBXL_MAXMEM_CONSTANT is supposed to be a safety
buffer and we should keep it as is across libxl_set_memory_target calls.
Arguably LIBXL_MAXMEM_CONSTANT could be removed entirely with the
proposed QEMU changes but that is a separate matter.

 
> > @@ -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 Dec 02 14:27:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1XvoPl-0004wn-KU; Tue, 02 Dec 2014 14:26: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 1XvoPk-0004wc-9m
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 14:26:52 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	22/47-22777-B2CCD745; Tue, 02 Dec 2014 14:26:51 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417530409!11081658!1
X-Originating-IP: [66.165.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 21883 invoked from network); 2 Dec 2014 14:26: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;
	2 Dec 2014 14:26:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198527813"
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, 2 Dec 2014 09:26: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 1XvoPg-0001tK-1r;
	Tue, 02 Dec 2014 14:26:48 +0000
Date: Tue, 2 Dec 2014 14:26:37 +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: <547DBC05.9070904@terremark.com>
Message-ID: <alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.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>, 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: Re: [Xen-devel] [PATCH v2 for-4.6] 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

On Tue, 2 Dec 2014, Don Slutz wrote:
> On 12/02/14 06:53, Stefano Stabellini wrote:
> > 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>
> > 
> > ---
> > 
> > Changes in v2:
> > - call libxl_domain_info instead of libxl_dominfo_init;
> > - call libxl_domain_info before retry_transaction.
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index de23fec..569a32a 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
> > domid,
> >       char *uuid;
> >       xs_transaction_t t;
> >   +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
> > +        goto out_no_transaction;
> > +
> >   retry_transaction:
> >       t = xs_transaction_start(ctx->xsh);
> >   @@ -4767,10 +4770,9 @@ 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);
> > +    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 "
> 
> You need to remove LIBXL_MAXMEM_CONSTANT here also.

I don't think so: LIBXL_MAXMEM_CONSTANT is supposed to be a safety
buffer and we should keep it as is across libxl_set_memory_target calls.
Arguably LIBXL_MAXMEM_CONSTANT could be removed entirely with the
proposed QEMU changes but that is a separate matter.

 
> > @@ -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 Dec 02 14:32:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:32:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvoV8-00057A-CU; Tue, 02 Dec 2014 14:32: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 1XvoV7-000575-RA
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:32:26 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	7F/65-03148-97DCD745; Tue, 02 Dec 2014 14:32:25 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417530743!12473253!1
X-Originating-IP: [74.125.82.52]
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 1924 invoked from network); 2 Dec 2014 14:32:24 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:32:24 -0000
Received: by mail-wg0-f52.google.com with SMTP id a1so17158553wgh.25
	for <xen-devel@lists.xenproject.org>;
	Tue, 02 Dec 2014 06: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:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=S6ZZC6OWvwwYOyoHcuaxTX/yGhfL7k0ikov2wmez7Gc=;
	b=YGpVssy0EJJv3+M6wk7dO68y18IL4A21rUnRj2TGMaceTGuuVOFKM+2BxVzDLE2VNl
	PPRLANA3mIlHP42OPtYOkEMIo/rdqF/DxE7ozXK7qSmRLc6UcGPLkIGFvGhCF3yH/Wbl
	qBqx0fB//LgQfnAI35DuWWrsDv9Ea+T2KIBqjFbRRS5MQ7CEL26zdoAL4VP4EdMUWSC6
	f8MCYxeYQWjIEbY15DEtJ/8yd2pg23qazRX5qfOkJTDx0cCvXLqlDsp67se46BXadG/c
	T2hHPbqc4A4lK5D2xvEQRaVFz+648MmkQiE7uAAM/QkElX0IVMeJpiOpJXrgleXDLpSo
	uaHQ==
X-Gm-Message-State: ALoCoQlVtUjFFfNmmLHmMlpEWymsv8rxr8s+vAPCdAOymTRpLiz+aNlsmpro7bFySXjiEi1NvCwS
X-Received: by 10.194.94.132 with SMTP id dc4mr106195376wjb.56.1417530743713; 
	Tue, 02 Dec 2014 06:32:23 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	dm10sm46627845wib.18.2014.12.02.06.32.22 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 06:32:23 -0800 (PST)
Message-ID: <547DCD73.9050202@linaro.org>
Date: Tue, 02 Dec 2014 14:32:19 +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: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>	
	<1417528456.24320.37.camel@citrix.com>
	<547DC7DB.5040305@linaro.org>
	<1417530117.24320.50.camel@citrix.com>
In-Reply-To: <1417530117.24320.50.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@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

On 02/12/14 14:21, Ian Campbell wrote:
> On Tue, 2014-12-02 at 14:08 +0000, Julien Grall wrote:
>> Hi Ian,
>>
>> On 02/12/14 13:54, Ian Campbell wrote:
>>> On Fri, 2014-11-28 at 15:17 +0000, Julien Grall wrote:
>>>> 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.
>>>>
>>>
>>> When we reschedule the vcpu which caused the spurious interrupt, the IRQ
>>> will definitely trigger again for real, right?
>>
>> Xen arms a timer when the domain is saved. As we received an unexpected
>> interrupt that means the timer expires which will make Xen injected the
>> virtual timer interrupt (see virt_timer_expired).
> 
> Are we sure there is no race here where the software timer doesn't fire
> because it appears to be in the past or something?
> 
> That would correspond to the sequence:
>    disable interrupts
>    h/w timer expires, interrupt raised but masked
>    calculate timeout for s/w timeout => -ve.

The s/w timers contains the absolute value of the deadline that will be
compared to NOW().

> Perhaps Xen s/w timers in the past fire immediately?

The s/w timer is added in the heap and a SOFTIRQ is raised.

When executed, the softirq will notice that the timer has to be fired
and therefore an interrupt will be injected to the guest.

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 Dec 02 14:32:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:32:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvoV8-00057A-CU; Tue, 02 Dec 2014 14:32: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 1XvoV7-000575-RA
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:32:26 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	7F/65-03148-97DCD745; Tue, 02 Dec 2014 14:32:25 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417530743!12473253!1
X-Originating-IP: [74.125.82.52]
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 1924 invoked from network); 2 Dec 2014 14:32:24 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:32:24 -0000
Received: by mail-wg0-f52.google.com with SMTP id a1so17158553wgh.25
	for <xen-devel@lists.xenproject.org>;
	Tue, 02 Dec 2014 06: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:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=S6ZZC6OWvwwYOyoHcuaxTX/yGhfL7k0ikov2wmez7Gc=;
	b=YGpVssy0EJJv3+M6wk7dO68y18IL4A21rUnRj2TGMaceTGuuVOFKM+2BxVzDLE2VNl
	PPRLANA3mIlHP42OPtYOkEMIo/rdqF/DxE7ozXK7qSmRLc6UcGPLkIGFvGhCF3yH/Wbl
	qBqx0fB//LgQfnAI35DuWWrsDv9Ea+T2KIBqjFbRRS5MQ7CEL26zdoAL4VP4EdMUWSC6
	f8MCYxeYQWjIEbY15DEtJ/8yd2pg23qazRX5qfOkJTDx0cCvXLqlDsp67se46BXadG/c
	T2hHPbqc4A4lK5D2xvEQRaVFz+648MmkQiE7uAAM/QkElX0IVMeJpiOpJXrgleXDLpSo
	uaHQ==
X-Gm-Message-State: ALoCoQlVtUjFFfNmmLHmMlpEWymsv8rxr8s+vAPCdAOymTRpLiz+aNlsmpro7bFySXjiEi1NvCwS
X-Received: by 10.194.94.132 with SMTP id dc4mr106195376wjb.56.1417530743713; 
	Tue, 02 Dec 2014 06:32:23 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	dm10sm46627845wib.18.2014.12.02.06.32.22 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 06:32:23 -0800 (PST)
Message-ID: <547DCD73.9050202@linaro.org>
Date: Tue, 02 Dec 2014 14:32:19 +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: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>	
	<1417528456.24320.37.camel@citrix.com>
	<547DC7DB.5040305@linaro.org>
	<1417530117.24320.50.camel@citrix.com>
In-Reply-To: <1417530117.24320.50.camel@citrix.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@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

On 02/12/14 14:21, Ian Campbell wrote:
> On Tue, 2014-12-02 at 14:08 +0000, Julien Grall wrote:
>> Hi Ian,
>>
>> On 02/12/14 13:54, Ian Campbell wrote:
>>> On Fri, 2014-11-28 at 15:17 +0000, Julien Grall wrote:
>>>> 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.
>>>>
>>>
>>> When we reschedule the vcpu which caused the spurious interrupt, the IRQ
>>> will definitely trigger again for real, right?
>>
>> Xen arms a timer when the domain is saved. As we received an unexpected
>> interrupt that means the timer expires which will make Xen injected the
>> virtual timer interrupt (see virt_timer_expired).
> 
> Are we sure there is no race here where the software timer doesn't fire
> because it appears to be in the past or something?
> 
> That would correspond to the sequence:
>    disable interrupts
>    h/w timer expires, interrupt raised but masked
>    calculate timeout for s/w timeout => -ve.

The s/w timers contains the absolute value of the deadline that will be
compared to NOW().

> Perhaps Xen s/w timers in the past fire immediately?

The s/w timer is added in the heap and a SOFTIRQ is raised.

When executed, the softirq will notice that the timer has to be fired
and therefore an interrupt will be injected to the guest.

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 Dec 02 14:35:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvoY8-0005ES-VS; Tue, 02 Dec 2014 14:35:32 +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 1XvoY7-0005EL-HQ
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 14:35:31 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	32/3C-22777-23ECD745; Tue, 02 Dec 2014 14:35:30 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417530930!11065437!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1948 invoked from network); 2 Dec 2014 14:35:30 -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; 2 Dec 2014 14:35:30 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 538C2AB07;
	Tue,  2 Dec 2014 14:35:29 +0000 (UTC)
Message-ID: <547DCE30.4080303@suse.com>
Date: Tue, 02 Dec 2014 15:35:28 +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>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.com>
	<547DA99E.5080001@citrix.com> <547DB802.9020900@suse.com>
	<547DC80A.10301@citrix.com>
In-Reply-To: <547DC80A.10301@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 03:09 PM, David Vrabel wrote:
> On 02/12/14 13:00, Juergen Gross wrote:
>>
>> I'd see:
>> - XEN_PV (selects PARAVIRT, XEN_FRONTEND): be able to run as pv-domain
>>    (x86 only)
>
> Depends on PARAVIRT perhaps?

Chicken and egg problem? :-)

I'd say select, as PARAVIRT isn't a primary function the user wants to
enable, it is a prerequisite for e.g. XEN_PV.

>
>> - XEN_PVHVM (selects XEN_FRONTEND): be able to run as hvm-domain with
>>    pv-drivers
>> - XEN_BACKEND (selects PARAVIRT if x86): be able to run as driver domain
>>    (dom0 or other)
>
> Does not need to select PARAVIRT -- HVM domains can run backends.

Okay.

>
>> - XEN_DOM0 (selects PARAVIRT if x86, XEN_BACKEND): be able to run as
>>    dom0
>
> XEN_DOM0 depends on XEN_PV or XEN_PVH (if x86) and whatever ARM needs.

I've removed XEN_PV as XEN_DOM0 shouldn't require XEN_FRONTEND.
We can add XEN_PARAVIRT instead which will be needed by XEN_DOM0 and
XEN_PV and will select PARAVIRT.

>
>> - XEN_FRONTEND: be able to run as domU with pv-drivers
>
> It may also be interesting to consider splitting the PV MMU stuff under
> a PARAVIRT_MMU option.  This might address a reason why people want to
> disable PARAVIRT completely.

Okay, seems sensible. Especially regarding XEN_PVH which I've omitted
here.

I'll try to assemble a complete config tree for review before starting
with patches. :-)


Juergen

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:35:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvoY8-0005ES-VS; Tue, 02 Dec 2014 14:35:32 +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 1XvoY7-0005EL-HQ
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 14:35:31 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	32/3C-22777-23ECD745; Tue, 02 Dec 2014 14:35:30 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417530930!11065437!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1948 invoked from network); 2 Dec 2014 14:35:30 -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; 2 Dec 2014 14:35:30 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 538C2AB07;
	Tue,  2 Dec 2014 14:35:29 +0000 (UTC)
Message-ID: <547DCE30.4080303@suse.com>
Date: Tue, 02 Dec 2014 15:35:28 +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>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com> <547DA392.90701@suse.com>
	<547DA99E.5080001@citrix.com> <547DB802.9020900@suse.com>
	<547DC80A.10301@citrix.com>
In-Reply-To: <547DC80A.10301@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 03:09 PM, David Vrabel wrote:
> On 02/12/14 13:00, Juergen Gross wrote:
>>
>> I'd see:
>> - XEN_PV (selects PARAVIRT, XEN_FRONTEND): be able to run as pv-domain
>>    (x86 only)
>
> Depends on PARAVIRT perhaps?

Chicken and egg problem? :-)

I'd say select, as PARAVIRT isn't a primary function the user wants to
enable, it is a prerequisite for e.g. XEN_PV.

>
>> - XEN_PVHVM (selects XEN_FRONTEND): be able to run as hvm-domain with
>>    pv-drivers
>> - XEN_BACKEND (selects PARAVIRT if x86): be able to run as driver domain
>>    (dom0 or other)
>
> Does not need to select PARAVIRT -- HVM domains can run backends.

Okay.

>
>> - XEN_DOM0 (selects PARAVIRT if x86, XEN_BACKEND): be able to run as
>>    dom0
>
> XEN_DOM0 depends on XEN_PV or XEN_PVH (if x86) and whatever ARM needs.

I've removed XEN_PV as XEN_DOM0 shouldn't require XEN_FRONTEND.
We can add XEN_PARAVIRT instead which will be needed by XEN_DOM0 and
XEN_PV and will select PARAVIRT.

>
>> - XEN_FRONTEND: be able to run as domU with pv-drivers
>
> It may also be interesting to consider splitting the PV MMU stuff under
> a PARAVIRT_MMU option.  This might address a reason why people want to
> disable PARAVIRT completely.

Okay, seems sensible. Especially regarding XEN_PVH which I've omitted
here.

I'll try to assemble a complete config tree for review before starting
with patches. :-)


Juergen

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:38:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1XvoaG-0005Lp-Gn; Tue, 02 Dec 2014 14:37: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 1XvoaE-0005Lk-RJ
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:37:42 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	BC/7C-05632-6BECD745; Tue, 02 Dec 2014 14:37:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417531058!15312418!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31104 invoked from network); 2 Dec 2014 14:37:40 -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;
	2 Dec 2014 14:37:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198533438"
Message-ID: <1417530970.24320.53.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Tue, 2 Dec 2014 14:36:10 +0000
In-Reply-To: <547DCD73.9050202@linaro.org>
References: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
	<1417528456.24320.37.camel@citrix.com> <547DC7DB.5040305@linaro.org>
	<1417530117.24320.50.camel@citrix.com> <547DCD73.9050202@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] 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

On Tue, 2014-12-02 at 14:32 +0000, Julien Grall wrote:
> On 02/12/14 14:21, Ian Campbell wrote:
> > On Tue, 2014-12-02 at 14:08 +0000, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 02/12/14 13:54, Ian Campbell wrote:
> >>> On Fri, 2014-11-28 at 15:17 +0000, Julien Grall wrote:
> >>>> 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.
> >>>>
> >>>
> >>> When we reschedule the vcpu which caused the spurious interrupt, the IRQ
> >>> will definitely trigger again for real, right?
> >>
> >> Xen arms a timer when the domain is saved. As we received an unexpected
> >> interrupt that means the timer expires which will make Xen injected the
> >> virtual timer interrupt (see virt_timer_expired).
> > 
> > Are we sure there is no race here where the software timer doesn't fire
> > because it appears to be in the past or something?
> > 
> > That would correspond to the sequence:
> >    disable interrupts
> >    h/w timer expires, interrupt raised but masked
> >    calculate timeout for s/w timeout => -ve.
> 
> The s/w timers contains the absolute value of the deadline that will be
> compared to NOW().
> 
> > Perhaps Xen s/w timers in the past fire immediately?
> 
> The s/w timer is added in the heap and a SOFTIRQ is raised.
> 
> When executed, the softirq will notice that the timer has to be fired
> and therefore an interrupt will be injected to the guest.

Perfect, thanks.

> 
> Regards,
> 



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:38:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1XvoaG-0005Lp-Gn; Tue, 02 Dec 2014 14:37: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 1XvoaE-0005Lk-RJ
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:37:42 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	BC/7C-05632-6BECD745; Tue, 02 Dec 2014 14:37:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417531058!15312418!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31104 invoked from network); 2 Dec 2014 14:37:40 -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;
	2 Dec 2014 14:37:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198533438"
Message-ID: <1417530970.24320.53.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Tue, 2 Dec 2014 14:36:10 +0000
In-Reply-To: <547DCD73.9050202@linaro.org>
References: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
	<1417528456.24320.37.camel@citrix.com> <547DC7DB.5040305@linaro.org>
	<1417530117.24320.50.camel@citrix.com> <547DCD73.9050202@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] 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

On Tue, 2014-12-02 at 14:32 +0000, Julien Grall wrote:
> On 02/12/14 14:21, Ian Campbell wrote:
> > On Tue, 2014-12-02 at 14:08 +0000, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 02/12/14 13:54, Ian Campbell wrote:
> >>> On Fri, 2014-11-28 at 15:17 +0000, Julien Grall wrote:
> >>>> 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.
> >>>>
> >>>
> >>> When we reschedule the vcpu which caused the spurious interrupt, the IRQ
> >>> will definitely trigger again for real, right?
> >>
> >> Xen arms a timer when the domain is saved. As we received an unexpected
> >> interrupt that means the timer expires which will make Xen injected the
> >> virtual timer interrupt (see virt_timer_expired).
> > 
> > Are we sure there is no race here where the software timer doesn't fire
> > because it appears to be in the past or something?
> > 
> > That would correspond to the sequence:
> >    disable interrupts
> >    h/w timer expires, interrupt raised but masked
> >    calculate timeout for s/w timeout => -ve.
> 
> The s/w timers contains the absolute value of the deadline that will be
> compared to NOW().
> 
> > Perhaps Xen s/w timers in the past fire immediately?
> 
> The s/w timer is added in the heap and a SOFTIRQ is raised.
> 
> When executed, the softirq will notice that the timer has to be fired
> and therefore an interrupt will be injected to the guest.

Perfect, thanks.

> 
> Regards,
> 



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:47:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1XvojL-0005eg-My; Tue, 02 Dec 2014 14:47:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XvojK-0005eY-Bb
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:47:06 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	29/CF-02696-9E0DD745; Tue, 02 Dec 2014 14:47:05 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417531617!12470445!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 665 invoked from network); 2 Dec 2014 14:47:02 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:47:02 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDI03916; Tue, 02 Dec 2014 22:46:47 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Tue, 2 Dec 2014 22:46:37 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQA==
Date: Tue, 2 Dec 2014 14:46:36 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
In-Reply-To: <20141202121151.GD5768@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for your reply, Wei.

I do the following testing just now and found the results as follows:

There are three DomUs (4U4G) are running on Host A (6U6G) and one DomU (4U4G) is running on Host B (6U6G), I send packets from three DomUs to the DomU on Host B simultaneously. 

1. The "top" output of Host B as follows:

top - 09:42:11 up  1:07,  2 users,  load average: 2.46, 1.90, 1.47
Tasks: 173 total,   4 running, 169 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 97.3 id,  0.0 wa,  0.0 hi,  0.8 si,  1.9 st
%Cpu1  :  0.0 us, 27.0 sy,  0.0 ni, 63.1 id,  0.0 wa,  0.0 hi,  9.5 si,  0.4 st
%Cpu2  :  0.0 us, 90.0 sy,  0.0 ni,  8.3 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st
%Cpu3  :  0.4 us,  1.4 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,  1.4 si,  1.4 st
%Cpu4  :  0.0 us, 60.2 sy,  0.0 ni, 39.5 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
%Cpu5  :  0.0 us,  2.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.0 hi,  6.9 si,  0.9 st
KiB Mem:   4517144 total,  3116480 used,  1400664 free,      876 buffers
KiB Swap:  2103292 total,        0 used,  2103292 free.  2374656 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                            
 7440 root      20   0       0      0      0 R 71.10 0.000   8:15.38 vif4.0-q3-guest                                                    
 7434 root      20   0       0      0      0 R 59.14 0.000   9:00.58 vif4.0-q0-guest                                                    
   18 root      20   0       0      0      0 R 33.89 0.000   2:35.06 ksoftirqd/2                                                        
   28 root      20   0       0      0      0 S 20.93 0.000   3:01.81 ksoftirqd/4


As shown above, only two netback related processes (vif4.0-*) are running with high cpu usage, and the other 2 netback processes are idle. The "ps" result of vif4.0-* processes as follows:

root      7434 50.5  0.0      0     0 ?        R    09:23  11:29 [vif4.0-q0-guest]
root      7435  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q0-deall]
root      7436  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q1-guest]
root      7437  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q1-deall]
root      7438  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q2-guest]
root      7439  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q2-deall]
root      7440 48.1  0.0      0     0 ?        R    09:23  10:55 [vif4.0-q3-guest]
root      7441  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q3-deall]
root      9724  0.0  0.0   9244  1520 pts/0    S+   09:46   0:00 grep --color=auto


2. The "rx" related content in /proc/interupts in receiver DomU (on Host B):

73: 	2		0		2925405		0			xen-dyn-event		eth0-q0-rx
75: 	43		93		0			118			xen-dyn-event		eth0-q1-rx
77: 	2		3376	14			1983		xen-dyn-event		eth0-q2-rx
79: 	2414666	0		9			0			xen-dyn-event		eth0-q3-rx

As shown above, it seems like that only q0 and q3 handles the interrupt triggered by packet receving.

Any advise? Thanks.
----------
zhangleiqiang (Trump)

Best Regards


> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Tuesday, December 02, 2014 8:12 PM
> To: Zhangleiqiang (Trump)
> Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian); Xiaoding
> (B); Yuzhou (C); Zhuangyuxin
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump) wrote:
> > > -----Original Message-----
> > > From: xen-devel-bounces@lists.xen.org
> > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei Liu
> > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > To: zhangleiqiang
> > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > > multiqueue support
> > >
> > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > Hi, all
> > > >     I am testing the performance of xen netfront-netback driver
> > > > that with
> > > multi-queues support. The throughput from domU to remote dom0 is
> > > 9.2Gb/s, but the throughput from domU to remote domU is only
> > > 3.6Gb/s, I think the bottleneck is the throughput from dom0 to local
> > > domU. However, we have done some testing and found the throughput
> > > from dom0 to local domU is 5.8Gb/s.
> > > >     And if we send packets from one DomU to other 3 DomUs on
> > > > different
> > > host simultaneously, the sum of throughout can reach 9Gbps. It seems
> > > like the bottleneck is the receiver?
> > > >     After some analysis, I found that even the max_queue of
> > > > netfront/back
> > > is set to 4, there are some strange results as follows:
> > > >     1. In domU, only one rx queue deal with softirq
> > >
> > > Try to bind irq to different vcpus?
> >
> > Do you mean we try to bind irq to different vcpus in DomU? I will try it now.
> >
> 
> Yes. Given the fact that you have two backend threads running while only one
> DomU vcpu is busy, it smells like misconfiguration in DomU.
> 
> If this phenomenon persists after correctly binding irqs, you might want to
> check traffic is steering correctly to different queues.
> 
> > >
> > > >     2. In dom0, only two netback queues process are scheduled,
> > > > other two
> > > process aren't scheduled.
> > >
> > > How many Dom0 vcpu do you have? If it only has two then there will
> > > only be two processes running at a time.
> >
> > Dom0 has 6 vcpus, and 6G memory. There are only one DomU running in
> Dom0 and so four netback processes are running in Dom0 (because the
> max_queue param of netback kernel module is set to 4).
> > The phenomenon is that only 2 of these four netback process were running
> with about 70% cpu usage, and another two use little CPU.
> > Is there a hash algorithm to determine which netback process to handle the
> input packet?
> >
> 
> I think that's whatever default algorithm Linux kernel is using.
> 
> We don't currently support other algorithms.
> 
> Wei.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:47:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1XvojL-0005eg-My; Tue, 02 Dec 2014 14:47:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XvojK-0005eY-Bb
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:47:06 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	29/CF-02696-9E0DD745; Tue, 02 Dec 2014 14:47:05 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417531617!12470445!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 665 invoked from network); 2 Dec 2014 14:47:02 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:47:02 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDI03916; Tue, 02 Dec 2014 22:46:47 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Tue, 2 Dec 2014 22:46:37 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQA==
Date: Tue, 2 Dec 2014 14:46:36 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
In-Reply-To: <20141202121151.GD5768@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for your reply, Wei.

I do the following testing just now and found the results as follows:

There are three DomUs (4U4G) are running on Host A (6U6G) and one DomU (4U4G) is running on Host B (6U6G), I send packets from three DomUs to the DomU on Host B simultaneously. 

1. The "top" output of Host B as follows:

top - 09:42:11 up  1:07,  2 users,  load average: 2.46, 1.90, 1.47
Tasks: 173 total,   4 running, 169 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 97.3 id,  0.0 wa,  0.0 hi,  0.8 si,  1.9 st
%Cpu1  :  0.0 us, 27.0 sy,  0.0 ni, 63.1 id,  0.0 wa,  0.0 hi,  9.5 si,  0.4 st
%Cpu2  :  0.0 us, 90.0 sy,  0.0 ni,  8.3 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st
%Cpu3  :  0.4 us,  1.4 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,  1.4 si,  1.4 st
%Cpu4  :  0.0 us, 60.2 sy,  0.0 ni, 39.5 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
%Cpu5  :  0.0 us,  2.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.0 hi,  6.9 si,  0.9 st
KiB Mem:   4517144 total,  3116480 used,  1400664 free,      876 buffers
KiB Swap:  2103292 total,        0 used,  2103292 free.  2374656 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                            
 7440 root      20   0       0      0      0 R 71.10 0.000   8:15.38 vif4.0-q3-guest                                                    
 7434 root      20   0       0      0      0 R 59.14 0.000   9:00.58 vif4.0-q0-guest                                                    
   18 root      20   0       0      0      0 R 33.89 0.000   2:35.06 ksoftirqd/2                                                        
   28 root      20   0       0      0      0 S 20.93 0.000   3:01.81 ksoftirqd/4


As shown above, only two netback related processes (vif4.0-*) are running with high cpu usage, and the other 2 netback processes are idle. The "ps" result of vif4.0-* processes as follows:

root      7434 50.5  0.0      0     0 ?        R    09:23  11:29 [vif4.0-q0-guest]
root      7435  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q0-deall]
root      7436  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q1-guest]
root      7437  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q1-deall]
root      7438  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q2-guest]
root      7439  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q2-deall]
root      7440 48.1  0.0      0     0 ?        R    09:23  10:55 [vif4.0-q3-guest]
root      7441  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q3-deall]
root      9724  0.0  0.0   9244  1520 pts/0    S+   09:46   0:00 grep --color=auto


2. The "rx" related content in /proc/interupts in receiver DomU (on Host B):

73: 	2		0		2925405		0			xen-dyn-event		eth0-q0-rx
75: 	43		93		0			118			xen-dyn-event		eth0-q1-rx
77: 	2		3376	14			1983		xen-dyn-event		eth0-q2-rx
79: 	2414666	0		9			0			xen-dyn-event		eth0-q3-rx

As shown above, it seems like that only q0 and q3 handles the interrupt triggered by packet receving.

Any advise? Thanks.
----------
zhangleiqiang (Trump)

Best Regards


> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Tuesday, December 02, 2014 8:12 PM
> To: Zhangleiqiang (Trump)
> Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian); Xiaoding
> (B); Yuzhou (C); Zhuangyuxin
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump) wrote:
> > > -----Original Message-----
> > > From: xen-devel-bounces@lists.xen.org
> > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei Liu
> > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > To: zhangleiqiang
> > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > > multiqueue support
> > >
> > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > Hi, all
> > > >     I am testing the performance of xen netfront-netback driver
> > > > that with
> > > multi-queues support. The throughput from domU to remote dom0 is
> > > 9.2Gb/s, but the throughput from domU to remote domU is only
> > > 3.6Gb/s, I think the bottleneck is the throughput from dom0 to local
> > > domU. However, we have done some testing and found the throughput
> > > from dom0 to local domU is 5.8Gb/s.
> > > >     And if we send packets from one DomU to other 3 DomUs on
> > > > different
> > > host simultaneously, the sum of throughout can reach 9Gbps. It seems
> > > like the bottleneck is the receiver?
> > > >     After some analysis, I found that even the max_queue of
> > > > netfront/back
> > > is set to 4, there are some strange results as follows:
> > > >     1. In domU, only one rx queue deal with softirq
> > >
> > > Try to bind irq to different vcpus?
> >
> > Do you mean we try to bind irq to different vcpus in DomU? I will try it now.
> >
> 
> Yes. Given the fact that you have two backend threads running while only one
> DomU vcpu is busy, it smells like misconfiguration in DomU.
> 
> If this phenomenon persists after correctly binding irqs, you might want to
> check traffic is steering correctly to different queues.
> 
> > >
> > > >     2. In dom0, only two netback queues process are scheduled,
> > > > other two
> > > process aren't scheduled.
> > >
> > > How many Dom0 vcpu do you have? If it only has two then there will
> > > only be two processes running at a time.
> >
> > Dom0 has 6 vcpus, and 6G memory. There are only one DomU running in
> Dom0 and so four netback processes are running in Dom0 (because the
> max_queue param of netback kernel module is set to 4).
> > The phenomenon is that only 2 of these four netback process were running
> with about 70% cpu usage, and another two use little CPU.
> > Is there a hash algorithm to determine which netback process to handle the
> input packet?
> >
> 
> I think that's whatever default algorithm Linux kernel is using.
> 
> We don't currently support other algorithms.
> 
> Wei.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:54:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:54:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvoqe-0005u5-6Y; Tue, 02 Dec 2014 14:54:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1Xvoqc-0005tt-Uq
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:54:39 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	A7/E0-26858-EA2DD745; Tue, 02 Dec 2014 14:54:38 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417532074!12848663!1
X-Originating-IP: [207.171.178.25]
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 12420 invoked from network); 2 Dec 2014 14:54:35 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:54:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417532075; x=1449068075;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version;
	bh=OPPNBVnxn51UV2JAt+1lM+8iAvUNqls00ItrjauEYmE=;
	b=ajI/w0+E1QZvVKk+wjF05XElVcZfdNnyp28CinbqW6uX6bZM1MzVGrc2
	kuXju9suTZwhVUP7nZNPOBqHz5hk1xxOb15HAfqgw1ko5Etvk/VYx9iVP
	3RAlQn7RKarAN5fuKTzRCrhArpsq1/dl3asVfLtDcfz3llWofK0rtxe3A Y=;
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="174879408"
Received: from email-inbound-relay-25001.iad12.amazon.com ([10.205.29.168])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 14:54:32 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com
	[10.0.103.150])
	by email-inbound-relay-25001.iad12.amazon.com (8.14.7/8.14.7) with
	ESMTP id sB2Es8mA015454
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 14:54:31 GMT
Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 06:54:21 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.162.149) by
	EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 06:54:18 -0800
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 15:53:55 +0100
Message-ID: <1417532035-4395-3-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1417532035-4395-1-git-send-email-chegger@amazon.de>
References: <1417532035-4395-1-git-send-email-chegger@amazon.de>
MIME-Version: 1.0
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D06UWA003.ant.amazon.com (10.43.160.13) To
	EX13D03UWA003.ant.amazon.com (10.43.160.39)
Precedence: Bulk
Cc: Jan Beulich <jbeulich@suse.com>, Christoph Egger <chegger@amazon.de>,
	Keir Fraser <keir@xen.org>, Anthony Liguori <aliguori@amazon.com>,
	Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH v2 2/2] gnttab: refactor locking for scalability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Matt Wilson <msw@amazon.com>

This patch refactors grant table locking. It splits the previous
single spinlock per grant table into multiple locks. The heavily
modified components of the grant table (the maptrack state and the
active entries) are now protected by their own spinlocks. The
remaining elements of the grant table are read-mostly, so the main
grant table lock is modified to be a rwlock to improve concurrency.

Workloads with high grant table operation rates, especially map/unmap
operations as used by blkback/blkfront when persistent grants are not
supported, show marked improvement with these changes. A domU with 24
VBDs in a streaming 2M write workload achieved 1,400 MB/sec before
this change. Performance more than doubles with this patch, reaching
3,000 MB/sec before tuning and 3,600 MB/sec after adjusting event
channel vCPU bindings.

Signed-off-by: Matt Wilson <msw@amazon.com>
[chegger: ported to xen-staging, split into multiple commits]
Signed-off-by: Christoph Egger <chegger@amazon.de>
Cc: Anthony Liguori <aliguori@amazon.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
---
 docs/misc/grant-tables.txt |   21 +++++
 xen/common/grant_table.c   |  213 ++++++++++++++++++++++++++++----------------
 2 files changed, 157 insertions(+), 77 deletions(-)

diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt
index c9ae8f2..1ada018 100644
--- a/docs/misc/grant-tables.txt
+++ b/docs/misc/grant-tables.txt
@@ -63,6 +63,7 @@ is complete.
   act->domid : remote domain being granted rights
   act->frame : machine frame being granted
   act->pin   : used to hold reference counts
+  act->lock  : spinlock used to serialize access to active entry state
 
  Map tracking
  ~~~~~~~~~~~~
@@ -87,6 +88,8 @@ is complete.
                                version, partially initialized active table pages,
                                etc.
   grant_table->maptrack_lock : spinlock used to protect the maptrack state
+  active_grant_entry->lock   : spinlock used to serialize modifications to
+                               active entries
 
  The primary lock for the grant table is a read/write spinlock. All
  functions that access members of struct grant_table must acquire a
@@ -102,6 +105,24 @@ is complete.
  state can be rapidly modified under some workloads, and the critical
  sections are very small, thus we use a spinlock to protect them.
 
+ Active entries are obtained by calling active_entry_acquire(gt, ref).
+ This function returns a pointer to the active entry after locking its
+ spinlock. The caller must hold the rwlock for the gt in question
+ before calling active_entry_acquire(). This is because the grant
+ table can be dynamically extended via gnttab_grow_table() while a
+ domain is running and must be fully initialized. Once all access to
+ the active entry is complete, release the lock by calling
+ active_entry_release(act).
+
+ Summary of rules for locking:
+  active_entry_acquire() and active_entry_release() can only be
+  called when holding the relevant grant table's lock. I.e.:
+    read_lock(&gt->lock);
+    act = active_entry_acquire(gt, ref);
+    ...
+    active_entry_release(act);
+    read_unlock(&gt->lock);
+
 ********************************************************************************
 
  Granting a foreign domain access to frames
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 018b5b6..6b59627 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -151,10 +151,13 @@ struct active_grant_entry {
                                in the page.                           */
     unsigned      length:16; /* For sub-page grants, the length of the
                                 grant.                                */
+    spinlock_t    lock;      /* lock to protect access of this entry.
+                                see docs/misc/grant-tables.txt for
+                                locking protocol                      */
 };
 
 #define ACGNT_PER_PAGE (PAGE_SIZE / sizeof(struct active_grant_entry))
-#define active_entry(t, e) \
+#define _active_entry(t, e) \
     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
 
 static inline void gnttab_flush_tlb(const struct domain *d)
@@ -182,6 +185,29 @@ nr_active_grant_frames(struct grant_table *gt)
     return num_act_frames_from_sha_frames(nr_grant_frames(gt));
 }
 
+static inline struct active_grant_entry *
+active_entry_acquire(struct grant_table *t, grant_ref_t e)
+{
+    struct active_grant_entry *act;
+
+#ifndef NDEBUG
+    /* not perfect, but better than nothing for a debug build
+     * sanity check
+     */
+    BUG_ON(!rw_is_locked(&t->lock));
+#endif
+
+    act = &_active_entry(t, e);
+    spin_lock(&act->lock);
+
+    return act;
+}
+
+static inline void active_entry_release(struct active_grant_entry *act)
+{
+    spin_unlock(&act->lock);
+}
+    
 /* Check if the page has been paged out, or needs unsharing. 
    If rc == GNTST_okay, *page contains the page struct with a ref taken.
    Caller must do put_page(*page).
@@ -222,30 +248,6 @@ static int __get_paged_frame(unsigned long gfn, unsigned long *frame, struct pag
     return rc;
 }
 
-static inline void
-double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
-{
-    if ( lgt < rgt )
-    {
-        spin_lock(&lgt->maptrack_lock);
-        spin_lock(&rgt->maptrack_lock);
-    }
-    else
-    {
-        if ( lgt != rgt )
-            spin_lock(&rgt->maptrack_lock);
-        spin_lock(&lgt->maptrack_lock);
-    }
-}
-
-static inline void
-double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
-{
-    spin_unlock(&lgt->maptrack_lock);
-    if ( lgt != rgt )
-        spin_unlock(&rgt->maptrack_lock);
-}
-
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -310,7 +312,8 @@ get_maptrack_handle(
     return handle;
 }
 
-/* Number of grant table entries. Caller must hold d's grant table lock. */
+/* Number of grant table entries. Caller must hold d's grant table
+   read lock. */
 static unsigned int nr_grant_entries(struct grant_table *gt)
 {
     ASSERT(gt->gt_version != 0);
@@ -499,7 +502,7 @@ static int grant_map_exists(const struct domain *ld,
                             unsigned long mfn,
                             unsigned int *ref_count)
 {
-    const struct active_grant_entry *act;
+    struct active_grant_entry *act;
     unsigned int ref, max_iter;
     
     ASSERT(rw_is_locked(&rgt->lock));
@@ -508,17 +511,27 @@ static int grant_map_exists(const struct domain *ld,
                    nr_grant_entries(rgt));
     for ( ref = *ref_count; ref < max_iter; ref++ )
     {
-        act = &active_entry(rgt, ref);
+        act = active_entry_acquire(rgt, ref);
 
         if ( !act->pin )
+        {
+            active_entry_release(act);
             continue;
+        }
 
         if ( act->domid != ld->domain_id )
+        {
+            active_entry_release(act);
             continue;
+        }
 
         if ( act->frame != mfn )
+        {
+            active_entry_release(act);
             continue;
+        }
 
+        active_entry_release(act);
         return 0;
     }
 
@@ -531,24 +544,44 @@ static int grant_map_exists(const struct domain *ld,
     return -EINVAL;
 }
 
+/* Count the number of mapped ro or rw entries tracked in the left
+ * grant table given a provided mfn provided by a foreign domain. 
+ *
+ * This function takes the maptrack lock from the left grant table and
+ * must be called with the right grant table's rwlock held.
+ */
 static void mapcount(
     struct grant_table *lgt, struct domain *rd, unsigned long mfn,
     unsigned int *wrc, unsigned int *rdc)
 {
     struct grant_mapping *map;
     grant_handle_t handle;
+    struct active_grant_entry *act;
 
     *wrc = *rdc = 0;
 
+    /* N.B.: while taking the left side maptrack spinlock prevents
+     * any mapping changes, the right side active entries could be
+     * changing while we are counting. To be perfectly correct, the
+     * caller should hold the grant table write lock, or some other
+     * mechanism should be used to prevent concurrent changes during
+     * this operation. This is tricky because we can't promote a read
+     * lock into a write lock.
+     */
+    spin_lock(&lgt->maptrack_lock);
+
     for ( handle = 0; handle < lgt->maptrack_limit; handle++ )
     {
         map = &maptrack_entry(lgt, handle);
         if ( !(map->flags & (GNTMAP_device_map|GNTMAP_host_map)) ||
              map->domid != rd->domain_id )
             continue;
-        if ( active_entry(rd->grant_table, map->ref).frame == mfn )
+        act = &_active_entry(rd->grant_table, map->ref);
+        if ( act->frame == mfn )
             (map->flags & GNTMAP_readonly) ? (*rdc)++ : (*wrc)++;
     }
+
+    spin_unlock(&lgt->maptrack_lock);
 }
 
 /*
@@ -570,7 +603,6 @@ __gnttab_map_grant_ref(
     struct page_info *pg = NULL;
     int            rc = GNTST_okay;
     u32            old_pin;
-    u32            act_pin;
     unsigned int   cache_flags;
     struct active_grant_entry *act = NULL;
     struct grant_mapping *mt;
@@ -633,7 +665,7 @@ __gnttab_map_grant_ref(
     if ( unlikely(op->ref >= nr_grant_entries(rgt)))
         PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref (%d).\n", op->ref);
 
-    act = &active_entry(rgt, op->ref);
+    act = active_entry_acquire(rgt, op->ref);
     shah = shared_entry_header(rgt, op->ref);
     if (rgt->gt_version == 1) {
         sha1 = &shared_entry_v1(rgt, op->ref);
@@ -650,7 +682,7 @@ __gnttab_map_grant_ref(
          ((act->domid != ld->domain_id) ||
           (act->pin & 0x80808080U) != 0 ||
           (act->is_sub_page)) )
-        PIN_FAIL(unlock_out, GNTST_general_error,
+        PIN_FAIL(act_release_out, GNTST_general_error,
                  "Bad domain (%d != %d), or risk of counter overflow %08x, or subpage %d\n",
                  act->domid, ld->domain_id, act->pin, act->is_sub_page);
 
@@ -661,7 +693,7 @@ __gnttab_map_grant_ref(
         if ( (rc = _set_status(rgt->gt_version, ld->domain_id,
                                op->flags & GNTMAP_readonly,
                                1, shah, act, status) ) != GNTST_okay )
-             goto unlock_out;
+            goto act_release_out;
 
         if ( !act->pin )
         {
@@ -692,12 +724,9 @@ __gnttab_map_grant_ref(
             GNTPIN_hstr_inc : GNTPIN_hstw_inc;
 
     frame = act->frame;
-    act_pin = act->pin;
 
     cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
-    read_unlock(&rgt->lock);
-
     /* pg may be set, with a refcount included, from __get_paged_frame */
     if ( !pg )
     {
@@ -772,8 +801,6 @@ __gnttab_map_grant_ref(
         goto undo_out;
     }
 
-    double_gt_lock(lgt, rgt);
-
     if ( gnttab_need_iommu_mapping(ld) )
     {
         unsigned int wrc, rdc;
@@ -781,21 +808,20 @@ __gnttab_map_grant_ref(
         /* We're not translated, so we know that gmfns and mfns are
            the same things, so the IOMMU entry is always 1-to-1. */
         mapcount(lgt, rd, frame, &wrc, &rdc);
-        if ( (act_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
+        if ( (act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
              !(old_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
         {
             if ( wrc == 0 )
                 err = iommu_map_page(ld, frame, frame,
                                      IOMMUF_readable|IOMMUF_writable);
         }
-        else if ( act_pin && !old_pin )
+        else if ( act->pin && !old_pin )
         {
             if ( (wrc + rdc) == 0 )
                 err = iommu_map_page(ld, frame, frame, IOMMUF_readable);
         }
         if ( err )
         {
-            double_gt_unlock(lgt, rgt);
             rc = GNTST_general_error;
             goto undo_out;
         }
@@ -808,7 +834,8 @@ __gnttab_map_grant_ref(
     mt->ref   = op->ref;
     mt->flags = op->flags;
 
-    double_gt_unlock(lgt, rgt);
+    active_entry_release(act);
+    read_unlock(&rgt->lock);
 
     op->dev_bus_addr = (u64)frame << PAGE_SHIFT;
     op->handle       = handle;
@@ -831,10 +858,6 @@ __gnttab_map_grant_ref(
         put_page(pg);
     }
 
-    read_lock(&rgt->lock);
-
-    act = &active_entry(rgt, op->ref);
-
     if ( op->flags & GNTMAP_device_map )
         act->pin -= (op->flags & GNTMAP_readonly) ?
             GNTPIN_devr_inc : GNTPIN_devw_inc;
@@ -850,6 +873,9 @@ __gnttab_map_grant_ref(
     if ( !act->pin )
         gnttab_clear_flag(_GTF_reading, status);
 
+ act_release_out:
+    active_entry_release(act);
+
  unlock_out:
     read_unlock(&rgt->lock);
     op->status = rc;
@@ -891,9 +917,9 @@ __gnttab_unmap_common(
     ld = current->domain;
     lgt = ld->grant_table;
 
-    read_lock(&lgt->lock);
     op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
 
+    read_lock(&lgt->lock);
     if ( unlikely(op->handle >= lgt->maptrack_limit) )
     {
         read_unlock(&lgt->lock);
@@ -933,19 +959,18 @@ __gnttab_unmap_common(
     TRACE_1D(TRC_MEM_PAGE_GRANT_UNMAP, dom);
 
     rgt = rd->grant_table;
-    double_gt_lock(lgt, rgt);
 
     op->flags = op->map->flags;
     if ( unlikely(!op->flags) || unlikely(op->map->domid != dom) )
     {
         gdprintk(XENLOG_WARNING, "Unstable handle %u\n", op->handle);
         rc = GNTST_bad_handle;
-        goto unmap_out;
+        goto unlock_out;
     }
 
     op->rd = rd;
     read_lock(&rgt->lock);
-    act = &active_entry(rgt, op->map->ref);
+    act = active_entry_acquire(rgt, op->map->ref);
 
     if ( op->frame == 0 )
     {
@@ -954,7 +979,7 @@ __gnttab_unmap_common(
     else
     {
         if ( unlikely(op->frame != act->frame) )
-            PIN_FAIL(unmap_out, GNTST_general_error,
+            PIN_FAIL(act_release_out, GNTST_general_error,
                      "Bad frame number doesn't match gntref. (%lx != %lx)\n",
                      op->frame, act->frame);
         if ( op->flags & GNTMAP_device_map )
@@ -973,7 +998,7 @@ __gnttab_unmap_common(
         if ( (rc = replace_grant_host_mapping(op->host_addr,
                                               op->frame, op->new_addr, 
                                               op->flags)) < 0 )
-            goto unmap_out;
+            goto act_release_out;
 
         ASSERT(act->pin & (GNTPIN_hstw_mask | GNTPIN_hstr_mask));
         op->map->flags &= ~GNTMAP_host_map;
@@ -995,7 +1020,7 @@ __gnttab_unmap_common(
         if ( err )
         {
             rc = GNTST_general_error;
-            goto unmap_out;
+            goto act_release_out;
         }
     }
 
@@ -1003,9 +1028,11 @@ __gnttab_unmap_common(
     if ( !(op->flags & GNTMAP_readonly) )
          gnttab_mark_dirty(rd, op->frame);
 
- unmap_out:
-    double_gt_unlock(lgt, rgt);
+ act_release_out:
+    active_entry_release(act);
     read_unlock(&rgt->lock);
+
+ unlock_out:
     op->status = rc;
     rcu_unlock_domain(rd);
 }
@@ -1038,9 +1065,9 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
 
     read_lock(&rgt->lock);
     if ( rgt->gt_version == 0 )
-        goto unmap_out;
+        goto unlock_out;
 
-    act = &active_entry(rgt, op->map->ref);
+    act = active_entry_acquire(rgt, op->map->ref);
     sha = shared_entry_header(rgt, op->map->ref);
 
     if ( rgt->gt_version == 1 )
@@ -1054,7 +1081,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
          * Suggests that __gntab_unmap_common failed early and so
          * nothing further to do
          */
-        goto unmap_out;
+        goto act_release_out;
     }
 
     pg = mfn_to_page(op->frame);
@@ -1078,7 +1105,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
              * Suggests that __gntab_unmap_common failed in
              * replace_grant_host_mapping() so nothing further to do
              */
-            goto unmap_out;
+            goto act_release_out;
         }
 
         if ( !is_iomem_page(op->frame) ) 
@@ -1099,8 +1126,12 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
     if ( act->pin == 0 )
         gnttab_clear_flag(_GTF_reading, status);
 
- unmap_out:
+ act_release_out:
+    active_entry_release(act);
+    
+ unlock_out:
     read_unlock(&rgt->lock);
+
     if ( put_handle )
     {
         op->map->flags = 0;
@@ -1295,7 +1326,7 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
     /* d's grant table write lock must be held by the caller */
 
     struct grant_table *gt = d->grant_table;
-    unsigned int i;
+    unsigned int i, j;
 
     ASSERT(req_nr_frames <= max_grant_frames);
 
@@ -1310,6 +1341,10 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
         if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
             goto active_alloc_failed;
         clear_page(gt->active[i]);
+        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+        {
+            spin_lock_init(&gt->active[i][j].lock);
+        }
     }
 
     /* Shared */
@@ -1804,7 +1839,7 @@ __release_grant_for_copy(
 
     read_lock(&rgt->lock);
 
-    act = &active_entry(rgt, gref);
+    act = active_entry_acquire(rgt, gref);
     sha = shared_entry_header(rgt, gref);
     r_frame = act->frame;
 
@@ -1843,6 +1878,7 @@ __release_grant_for_copy(
         released_read = 1;
     }
 
+    active_entry_release(act);
     read_unlock(&rgt->lock);
 
     if ( td != rd )
@@ -1904,14 +1940,14 @@ __acquire_grant_for_copy(
     read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
-        PIN_FAIL(unlock_out, GNTST_general_error,
+        PIN_FAIL(gnt_unlock_out, GNTST_general_error,
                  "remote grant table not ready\n");
 
     if ( unlikely(gref >= nr_grant_entries(rgt)) )
-        PIN_FAIL(unlock_out, GNTST_bad_gntref,
+        PIN_FAIL(gnt_unlock_out, GNTST_bad_gntref,
                  "Bad grant reference %ld\n", gref);
 
-    act = &active_entry(rgt, gref);
+    act = active_entry_acquire(rgt, gref);
     shah = shared_entry_header(rgt, gref);
     if ( rgt->gt_version == 1 )
     {
@@ -1974,6 +2010,7 @@ __acquire_grant_for_copy(
             /* __acquire_grant_for_copy() could take the read lock on
              * the right table (if rd == td), so we have to drop the
              * lock here and reacquire */
+            active_entry_release(act);
             read_unlock(&rgt->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd->domain_id,
@@ -1981,8 +2018,11 @@ __acquire_grant_for_copy(
                                           &trans_page_off, &trans_length, 0);
 
             read_lock(&rgt->lock);
+            act = active_entry_acquire(rgt, gref);
+
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_copy_pin(act, status);
+                active_entry_release(act);
                 read_unlock(&rgt->lock);
                 rcu_unlock_domain(td);
                 return rc;
@@ -1996,6 +2036,7 @@ __acquire_grant_for_copy(
             {
                 __fixup_status_for_copy_pin(act, status);
                 rcu_unlock_domain(td);
+                active_entry_release(act);
                 read_unlock(&rgt->lock);
                 put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ldom, readonly,
@@ -2064,6 +2105,7 @@ __acquire_grant_for_copy(
     *length = act->length;
     *frame = act->frame;
 
+    active_entry_release(act);
     read_unlock(&rgt->lock);
     return rc;
  
@@ -2076,6 +2118,9 @@ __acquire_grant_for_copy(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
+    active_entry_release(act);
+
+ gnt_unlock_out:
     read_unlock(&rgt->lock);
     return rc;
 }
@@ -2259,16 +2304,18 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     {
         for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
-            act = &active_entry(gt, i);
+            act = active_entry_acquire(gt, i);
             if ( act->pin != 0 )
             {
                 gdprintk(XENLOG_WARNING,
                          "tried to change grant table version from %d to %d, but some grant entries still in use\n",
                          gt->gt_version,
                          op.version);
+                active_entry_release(act);
                 res = -EBUSY;
                 goto out_unlock;
             }
+            active_entry_release(act);
         }
     }
 
@@ -2447,7 +2494,8 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
 {
     struct domain *d = rcu_lock_current_domain();
     struct grant_table *gt = d->grant_table;
-    struct active_grant_entry *act;
+    struct active_grant_entry *act_a = NULL;
+    struct active_grant_entry *act_b = NULL;
     s16 rc = GNTST_okay;
 
     read_lock(&gt->lock);
@@ -2458,12 +2506,12 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     if ( unlikely(ref_b >= nr_grant_entries(d->grant_table)))
         PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-b (%d).\n", ref_b);
 
-    act = &active_entry(gt, ref_a);
-    if ( act->pin )
+    act_a = active_entry_acquire(gt, ref_a);
+    if ( act_a->pin )
         PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
 
-    act = &active_entry(gt, ref_b);
-    if ( act->pin )
+    act_b = active_entry_acquire(gt, ref_b);
+    if ( act_b->pin )
         PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
 
     if ( gt->gt_version == 1 )
@@ -2490,8 +2538,11 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     }
 
 out:
+    if ( act_b != NULL )
+        active_entry_release(act_b);
+    if ( act_a != NULL )
+        active_entry_release(act_a);
     read_unlock(&gt->lock);
-
     rcu_unlock_domain(d);
 
     return rc;
@@ -2807,7 +2858,7 @@ grant_table_create(
     struct domain *d)
 {
     struct grant_table *t;
-    int                 i;
+    int                 i, j;
 
     if ( (t = xzalloc(struct grant_table)) == NULL )
         goto no_mem_0;
@@ -2827,6 +2878,10 @@ grant_table_create(
         if ( (t->active[i] = alloc_xenheap_page()) == NULL )
             goto no_mem_2;
         clear_page(t->active[i]);
+        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+        {
+            spin_lock_init(&t->active[i][j].lock);
+        }
     }
 
     /* Tracking of mapped foreign frames table */
@@ -2923,7 +2978,7 @@ gnttab_release_mappings(
         rgt = rd->grant_table;
         read_lock(&rgt->lock);
 
-        act = &active_entry(rgt, ref);
+        act = active_entry_acquire(rgt, ref);
         sha = shared_entry_header(rgt, ref);
         if (rgt->gt_version == 1)
             status = &sha->flags;
@@ -2981,6 +3036,7 @@ gnttab_release_mappings(
         if ( act->pin == 0 )
             gnttab_clear_flag(_GTF_reading, status);
 
+        active_entry_release(act);
         read_unlock(&rgt->lock);
 
         rcu_unlock_domain(rd);
@@ -3001,7 +3057,7 @@ grant_table_destroy(
         return;
 
     write_lock(&t->lock);
-    
+
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
     xfree(t->shared_raw);
@@ -3047,9 +3103,11 @@ static void gnttab_usage_print(struct domain *rd)
         uint16_t status;
         uint64_t frame;
 
-        act = &active_entry(gt, ref);
-        if ( !act->pin )
+        act = active_entry_acquire(gt, ref);
+        if ( !act->pin ) {
+            active_entry_release(act);
             continue;
+        }
 
         sha = shared_entry_header(gt, ref);
 
@@ -3079,6 +3137,7 @@ static void gnttab_usage_print(struct domain *rd)
         printk("[%3d]    %5d 0x%06lx 0x%08x      %5d 0x%06"PRIx64" 0x%02x\n",
                ref, act->domid, act->frame, act->pin,
                sha->domid, frame, status);
+        active_entry_release(act);
     }
 
  out:
-- 
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 Dec 02 14:54:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:54:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvoqV-0005tU-Qf; Tue, 02 Dec 2014 14:54:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1XvoqU-0005tP-Ab
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:54:30 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	C0/24-28296-5A2DD745; Tue, 02 Dec 2014 14:54:29 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417532067!15301566!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE4NjQwNA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13919 invoked from network); 2 Dec 2014 14:54:29 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:54:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417532069; x=1449068069;
	h=from:to:cc:subject:date:message-id:mime-version;
	bh=lDw1ppr+TnRCeTHael+aqZ6fN+Apn2bj7FU821MmwYI=;
	b=EuoVldAbe3eNLTBgQ9POyN03kBznSBp20t3466IBwV+ylG84KtO6tmBS
	sxJPZbbI2wG3hiO1nt615NzCMhi4TQ4EOVj1nAgqSz6goRw8EjyHDG24z
	v0s/1g6pmjVGTILo87WpE71M462uYDeqSyx87MkCLaOcJo3bblLSYJ6U4 w=;
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="144835330"
Received: from email-inbound-relay-25001.iad12.amazon.com ([10.205.29.168])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 14:54:25 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com
	[10.0.103.150])
	by email-inbound-relay-25001.iad12.amazon.com (8.14.7/8.14.7) with
	ESMTP id sB2Es8m6015454
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Tue, 2 Dec 2014 14:54:23 GMT
Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 06:54:16 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.162.149) by
	EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 06:54:14 -0800
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 15:53:53 +0100
Message-ID: <1417532035-4395-1-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D06UWA003.ant.amazon.com (10.43.160.13) To
	EX13D03UWA003.ant.amazon.com (10.43.160.39)
Precedence: Bulk
Cc: Christoph Egger <chegger@amazon.de>
Subject: [Xen-devel] [PATCH v2 0/2] gnttab: Improve scaleability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 changes the grant table locking to
a more fain grained locking protocol. The result is
a performance boost measured with blkfront/blkback.
Document the locking protocol.

Christoph Egger (1):
  gnttab: Introduce rwlock to protect updates to grant table state

Matt Wilson (1):
  gnttab: refactor locking for scalability

 docs/misc/grant-tables.txt    |   49 +++++-
 xen/arch/arm/mm.c             |    4 +-
 xen/arch/x86/mm.c             |    4 +-
 xen/common/grant_table.c      |  330 ++++++++++++++++++++++++++---------------
 xen/include/xen/grant_table.h |    9 +-
 5 files changed, 265 insertions(+), 131 deletions(-)

-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:54:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:54:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvoqe-0005u5-6Y; Tue, 02 Dec 2014 14:54:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1Xvoqc-0005tt-Uq
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:54:39 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	A7/E0-26858-EA2DD745; Tue, 02 Dec 2014 14:54:38 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417532074!12848663!1
X-Originating-IP: [207.171.178.25]
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 12420 invoked from network); 2 Dec 2014 14:54:35 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:54:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417532075; x=1449068075;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version;
	bh=OPPNBVnxn51UV2JAt+1lM+8iAvUNqls00ItrjauEYmE=;
	b=ajI/w0+E1QZvVKk+wjF05XElVcZfdNnyp28CinbqW6uX6bZM1MzVGrc2
	kuXju9suTZwhVUP7nZNPOBqHz5hk1xxOb15HAfqgw1ko5Etvk/VYx9iVP
	3RAlQn7RKarAN5fuKTzRCrhArpsq1/dl3asVfLtDcfz3llWofK0rtxe3A Y=;
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="174879408"
Received: from email-inbound-relay-25001.iad12.amazon.com ([10.205.29.168])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 14:54:32 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com
	[10.0.103.150])
	by email-inbound-relay-25001.iad12.amazon.com (8.14.7/8.14.7) with
	ESMTP id sB2Es8mA015454
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 14:54:31 GMT
Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 06:54:21 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.162.149) by
	EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 06:54:18 -0800
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 15:53:55 +0100
Message-ID: <1417532035-4395-3-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1417532035-4395-1-git-send-email-chegger@amazon.de>
References: <1417532035-4395-1-git-send-email-chegger@amazon.de>
MIME-Version: 1.0
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D06UWA003.ant.amazon.com (10.43.160.13) To
	EX13D03UWA003.ant.amazon.com (10.43.160.39)
Precedence: Bulk
Cc: Jan Beulich <jbeulich@suse.com>, Christoph Egger <chegger@amazon.de>,
	Keir Fraser <keir@xen.org>, Anthony Liguori <aliguori@amazon.com>,
	Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH v2 2/2] gnttab: refactor locking for scalability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Matt Wilson <msw@amazon.com>

This patch refactors grant table locking. It splits the previous
single spinlock per grant table into multiple locks. The heavily
modified components of the grant table (the maptrack state and the
active entries) are now protected by their own spinlocks. The
remaining elements of the grant table are read-mostly, so the main
grant table lock is modified to be a rwlock to improve concurrency.

Workloads with high grant table operation rates, especially map/unmap
operations as used by blkback/blkfront when persistent grants are not
supported, show marked improvement with these changes. A domU with 24
VBDs in a streaming 2M write workload achieved 1,400 MB/sec before
this change. Performance more than doubles with this patch, reaching
3,000 MB/sec before tuning and 3,600 MB/sec after adjusting event
channel vCPU bindings.

Signed-off-by: Matt Wilson <msw@amazon.com>
[chegger: ported to xen-staging, split into multiple commits]
Signed-off-by: Christoph Egger <chegger@amazon.de>
Cc: Anthony Liguori <aliguori@amazon.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
---
 docs/misc/grant-tables.txt |   21 +++++
 xen/common/grant_table.c   |  213 ++++++++++++++++++++++++++++----------------
 2 files changed, 157 insertions(+), 77 deletions(-)

diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt
index c9ae8f2..1ada018 100644
--- a/docs/misc/grant-tables.txt
+++ b/docs/misc/grant-tables.txt
@@ -63,6 +63,7 @@ is complete.
   act->domid : remote domain being granted rights
   act->frame : machine frame being granted
   act->pin   : used to hold reference counts
+  act->lock  : spinlock used to serialize access to active entry state
 
  Map tracking
  ~~~~~~~~~~~~
@@ -87,6 +88,8 @@ is complete.
                                version, partially initialized active table pages,
                                etc.
   grant_table->maptrack_lock : spinlock used to protect the maptrack state
+  active_grant_entry->lock   : spinlock used to serialize modifications to
+                               active entries
 
  The primary lock for the grant table is a read/write spinlock. All
  functions that access members of struct grant_table must acquire a
@@ -102,6 +105,24 @@ is complete.
  state can be rapidly modified under some workloads, and the critical
  sections are very small, thus we use a spinlock to protect them.
 
+ Active entries are obtained by calling active_entry_acquire(gt, ref).
+ This function returns a pointer to the active entry after locking its
+ spinlock. The caller must hold the rwlock for the gt in question
+ before calling active_entry_acquire(). This is because the grant
+ table can be dynamically extended via gnttab_grow_table() while a
+ domain is running and must be fully initialized. Once all access to
+ the active entry is complete, release the lock by calling
+ active_entry_release(act).
+
+ Summary of rules for locking:
+  active_entry_acquire() and active_entry_release() can only be
+  called when holding the relevant grant table's lock. I.e.:
+    read_lock(&gt->lock);
+    act = active_entry_acquire(gt, ref);
+    ...
+    active_entry_release(act);
+    read_unlock(&gt->lock);
+
 ********************************************************************************
 
  Granting a foreign domain access to frames
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 018b5b6..6b59627 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -151,10 +151,13 @@ struct active_grant_entry {
                                in the page.                           */
     unsigned      length:16; /* For sub-page grants, the length of the
                                 grant.                                */
+    spinlock_t    lock;      /* lock to protect access of this entry.
+                                see docs/misc/grant-tables.txt for
+                                locking protocol                      */
 };
 
 #define ACGNT_PER_PAGE (PAGE_SIZE / sizeof(struct active_grant_entry))
-#define active_entry(t, e) \
+#define _active_entry(t, e) \
     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
 
 static inline void gnttab_flush_tlb(const struct domain *d)
@@ -182,6 +185,29 @@ nr_active_grant_frames(struct grant_table *gt)
     return num_act_frames_from_sha_frames(nr_grant_frames(gt));
 }
 
+static inline struct active_grant_entry *
+active_entry_acquire(struct grant_table *t, grant_ref_t e)
+{
+    struct active_grant_entry *act;
+
+#ifndef NDEBUG
+    /* not perfect, but better than nothing for a debug build
+     * sanity check
+     */
+    BUG_ON(!rw_is_locked(&t->lock));
+#endif
+
+    act = &_active_entry(t, e);
+    spin_lock(&act->lock);
+
+    return act;
+}
+
+static inline void active_entry_release(struct active_grant_entry *act)
+{
+    spin_unlock(&act->lock);
+}
+    
 /* Check if the page has been paged out, or needs unsharing. 
    If rc == GNTST_okay, *page contains the page struct with a ref taken.
    Caller must do put_page(*page).
@@ -222,30 +248,6 @@ static int __get_paged_frame(unsigned long gfn, unsigned long *frame, struct pag
     return rc;
 }
 
-static inline void
-double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
-{
-    if ( lgt < rgt )
-    {
-        spin_lock(&lgt->maptrack_lock);
-        spin_lock(&rgt->maptrack_lock);
-    }
-    else
-    {
-        if ( lgt != rgt )
-            spin_lock(&rgt->maptrack_lock);
-        spin_lock(&lgt->maptrack_lock);
-    }
-}
-
-static inline void
-double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
-{
-    spin_unlock(&lgt->maptrack_lock);
-    if ( lgt != rgt )
-        spin_unlock(&rgt->maptrack_lock);
-}
-
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -310,7 +312,8 @@ get_maptrack_handle(
     return handle;
 }
 
-/* Number of grant table entries. Caller must hold d's grant table lock. */
+/* Number of grant table entries. Caller must hold d's grant table
+   read lock. */
 static unsigned int nr_grant_entries(struct grant_table *gt)
 {
     ASSERT(gt->gt_version != 0);
@@ -499,7 +502,7 @@ static int grant_map_exists(const struct domain *ld,
                             unsigned long mfn,
                             unsigned int *ref_count)
 {
-    const struct active_grant_entry *act;
+    struct active_grant_entry *act;
     unsigned int ref, max_iter;
     
     ASSERT(rw_is_locked(&rgt->lock));
@@ -508,17 +511,27 @@ static int grant_map_exists(const struct domain *ld,
                    nr_grant_entries(rgt));
     for ( ref = *ref_count; ref < max_iter; ref++ )
     {
-        act = &active_entry(rgt, ref);
+        act = active_entry_acquire(rgt, ref);
 
         if ( !act->pin )
+        {
+            active_entry_release(act);
             continue;
+        }
 
         if ( act->domid != ld->domain_id )
+        {
+            active_entry_release(act);
             continue;
+        }
 
         if ( act->frame != mfn )
+        {
+            active_entry_release(act);
             continue;
+        }
 
+        active_entry_release(act);
         return 0;
     }
 
@@ -531,24 +544,44 @@ static int grant_map_exists(const struct domain *ld,
     return -EINVAL;
 }
 
+/* Count the number of mapped ro or rw entries tracked in the left
+ * grant table given a provided mfn provided by a foreign domain. 
+ *
+ * This function takes the maptrack lock from the left grant table and
+ * must be called with the right grant table's rwlock held.
+ */
 static void mapcount(
     struct grant_table *lgt, struct domain *rd, unsigned long mfn,
     unsigned int *wrc, unsigned int *rdc)
 {
     struct grant_mapping *map;
     grant_handle_t handle;
+    struct active_grant_entry *act;
 
     *wrc = *rdc = 0;
 
+    /* N.B.: while taking the left side maptrack spinlock prevents
+     * any mapping changes, the right side active entries could be
+     * changing while we are counting. To be perfectly correct, the
+     * caller should hold the grant table write lock, or some other
+     * mechanism should be used to prevent concurrent changes during
+     * this operation. This is tricky because we can't promote a read
+     * lock into a write lock.
+     */
+    spin_lock(&lgt->maptrack_lock);
+
     for ( handle = 0; handle < lgt->maptrack_limit; handle++ )
     {
         map = &maptrack_entry(lgt, handle);
         if ( !(map->flags & (GNTMAP_device_map|GNTMAP_host_map)) ||
              map->domid != rd->domain_id )
             continue;
-        if ( active_entry(rd->grant_table, map->ref).frame == mfn )
+        act = &_active_entry(rd->grant_table, map->ref);
+        if ( act->frame == mfn )
             (map->flags & GNTMAP_readonly) ? (*rdc)++ : (*wrc)++;
     }
+
+    spin_unlock(&lgt->maptrack_lock);
 }
 
 /*
@@ -570,7 +603,6 @@ __gnttab_map_grant_ref(
     struct page_info *pg = NULL;
     int            rc = GNTST_okay;
     u32            old_pin;
-    u32            act_pin;
     unsigned int   cache_flags;
     struct active_grant_entry *act = NULL;
     struct grant_mapping *mt;
@@ -633,7 +665,7 @@ __gnttab_map_grant_ref(
     if ( unlikely(op->ref >= nr_grant_entries(rgt)))
         PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref (%d).\n", op->ref);
 
-    act = &active_entry(rgt, op->ref);
+    act = active_entry_acquire(rgt, op->ref);
     shah = shared_entry_header(rgt, op->ref);
     if (rgt->gt_version == 1) {
         sha1 = &shared_entry_v1(rgt, op->ref);
@@ -650,7 +682,7 @@ __gnttab_map_grant_ref(
          ((act->domid != ld->domain_id) ||
           (act->pin & 0x80808080U) != 0 ||
           (act->is_sub_page)) )
-        PIN_FAIL(unlock_out, GNTST_general_error,
+        PIN_FAIL(act_release_out, GNTST_general_error,
                  "Bad domain (%d != %d), or risk of counter overflow %08x, or subpage %d\n",
                  act->domid, ld->domain_id, act->pin, act->is_sub_page);
 
@@ -661,7 +693,7 @@ __gnttab_map_grant_ref(
         if ( (rc = _set_status(rgt->gt_version, ld->domain_id,
                                op->flags & GNTMAP_readonly,
                                1, shah, act, status) ) != GNTST_okay )
-             goto unlock_out;
+            goto act_release_out;
 
         if ( !act->pin )
         {
@@ -692,12 +724,9 @@ __gnttab_map_grant_ref(
             GNTPIN_hstr_inc : GNTPIN_hstw_inc;
 
     frame = act->frame;
-    act_pin = act->pin;
 
     cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
-    read_unlock(&rgt->lock);
-
     /* pg may be set, with a refcount included, from __get_paged_frame */
     if ( !pg )
     {
@@ -772,8 +801,6 @@ __gnttab_map_grant_ref(
         goto undo_out;
     }
 
-    double_gt_lock(lgt, rgt);
-
     if ( gnttab_need_iommu_mapping(ld) )
     {
         unsigned int wrc, rdc;
@@ -781,21 +808,20 @@ __gnttab_map_grant_ref(
         /* We're not translated, so we know that gmfns and mfns are
            the same things, so the IOMMU entry is always 1-to-1. */
         mapcount(lgt, rd, frame, &wrc, &rdc);
-        if ( (act_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
+        if ( (act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
              !(old_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
         {
             if ( wrc == 0 )
                 err = iommu_map_page(ld, frame, frame,
                                      IOMMUF_readable|IOMMUF_writable);
         }
-        else if ( act_pin && !old_pin )
+        else if ( act->pin && !old_pin )
         {
             if ( (wrc + rdc) == 0 )
                 err = iommu_map_page(ld, frame, frame, IOMMUF_readable);
         }
         if ( err )
         {
-            double_gt_unlock(lgt, rgt);
             rc = GNTST_general_error;
             goto undo_out;
         }
@@ -808,7 +834,8 @@ __gnttab_map_grant_ref(
     mt->ref   = op->ref;
     mt->flags = op->flags;
 
-    double_gt_unlock(lgt, rgt);
+    active_entry_release(act);
+    read_unlock(&rgt->lock);
 
     op->dev_bus_addr = (u64)frame << PAGE_SHIFT;
     op->handle       = handle;
@@ -831,10 +858,6 @@ __gnttab_map_grant_ref(
         put_page(pg);
     }
 
-    read_lock(&rgt->lock);
-
-    act = &active_entry(rgt, op->ref);
-
     if ( op->flags & GNTMAP_device_map )
         act->pin -= (op->flags & GNTMAP_readonly) ?
             GNTPIN_devr_inc : GNTPIN_devw_inc;
@@ -850,6 +873,9 @@ __gnttab_map_grant_ref(
     if ( !act->pin )
         gnttab_clear_flag(_GTF_reading, status);
 
+ act_release_out:
+    active_entry_release(act);
+
  unlock_out:
     read_unlock(&rgt->lock);
     op->status = rc;
@@ -891,9 +917,9 @@ __gnttab_unmap_common(
     ld = current->domain;
     lgt = ld->grant_table;
 
-    read_lock(&lgt->lock);
     op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
 
+    read_lock(&lgt->lock);
     if ( unlikely(op->handle >= lgt->maptrack_limit) )
     {
         read_unlock(&lgt->lock);
@@ -933,19 +959,18 @@ __gnttab_unmap_common(
     TRACE_1D(TRC_MEM_PAGE_GRANT_UNMAP, dom);
 
     rgt = rd->grant_table;
-    double_gt_lock(lgt, rgt);
 
     op->flags = op->map->flags;
     if ( unlikely(!op->flags) || unlikely(op->map->domid != dom) )
     {
         gdprintk(XENLOG_WARNING, "Unstable handle %u\n", op->handle);
         rc = GNTST_bad_handle;
-        goto unmap_out;
+        goto unlock_out;
     }
 
     op->rd = rd;
     read_lock(&rgt->lock);
-    act = &active_entry(rgt, op->map->ref);
+    act = active_entry_acquire(rgt, op->map->ref);
 
     if ( op->frame == 0 )
     {
@@ -954,7 +979,7 @@ __gnttab_unmap_common(
     else
     {
         if ( unlikely(op->frame != act->frame) )
-            PIN_FAIL(unmap_out, GNTST_general_error,
+            PIN_FAIL(act_release_out, GNTST_general_error,
                      "Bad frame number doesn't match gntref. (%lx != %lx)\n",
                      op->frame, act->frame);
         if ( op->flags & GNTMAP_device_map )
@@ -973,7 +998,7 @@ __gnttab_unmap_common(
         if ( (rc = replace_grant_host_mapping(op->host_addr,
                                               op->frame, op->new_addr, 
                                               op->flags)) < 0 )
-            goto unmap_out;
+            goto act_release_out;
 
         ASSERT(act->pin & (GNTPIN_hstw_mask | GNTPIN_hstr_mask));
         op->map->flags &= ~GNTMAP_host_map;
@@ -995,7 +1020,7 @@ __gnttab_unmap_common(
         if ( err )
         {
             rc = GNTST_general_error;
-            goto unmap_out;
+            goto act_release_out;
         }
     }
 
@@ -1003,9 +1028,11 @@ __gnttab_unmap_common(
     if ( !(op->flags & GNTMAP_readonly) )
          gnttab_mark_dirty(rd, op->frame);
 
- unmap_out:
-    double_gt_unlock(lgt, rgt);
+ act_release_out:
+    active_entry_release(act);
     read_unlock(&rgt->lock);
+
+ unlock_out:
     op->status = rc;
     rcu_unlock_domain(rd);
 }
@@ -1038,9 +1065,9 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
 
     read_lock(&rgt->lock);
     if ( rgt->gt_version == 0 )
-        goto unmap_out;
+        goto unlock_out;
 
-    act = &active_entry(rgt, op->map->ref);
+    act = active_entry_acquire(rgt, op->map->ref);
     sha = shared_entry_header(rgt, op->map->ref);
 
     if ( rgt->gt_version == 1 )
@@ -1054,7 +1081,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
          * Suggests that __gntab_unmap_common failed early and so
          * nothing further to do
          */
-        goto unmap_out;
+        goto act_release_out;
     }
 
     pg = mfn_to_page(op->frame);
@@ -1078,7 +1105,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
              * Suggests that __gntab_unmap_common failed in
              * replace_grant_host_mapping() so nothing further to do
              */
-            goto unmap_out;
+            goto act_release_out;
         }
 
         if ( !is_iomem_page(op->frame) ) 
@@ -1099,8 +1126,12 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
     if ( act->pin == 0 )
         gnttab_clear_flag(_GTF_reading, status);
 
- unmap_out:
+ act_release_out:
+    active_entry_release(act);
+    
+ unlock_out:
     read_unlock(&rgt->lock);
+
     if ( put_handle )
     {
         op->map->flags = 0;
@@ -1295,7 +1326,7 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
     /* d's grant table write lock must be held by the caller */
 
     struct grant_table *gt = d->grant_table;
-    unsigned int i;
+    unsigned int i, j;
 
     ASSERT(req_nr_frames <= max_grant_frames);
 
@@ -1310,6 +1341,10 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
         if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
             goto active_alloc_failed;
         clear_page(gt->active[i]);
+        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+        {
+            spin_lock_init(&gt->active[i][j].lock);
+        }
     }
 
     /* Shared */
@@ -1804,7 +1839,7 @@ __release_grant_for_copy(
 
     read_lock(&rgt->lock);
 
-    act = &active_entry(rgt, gref);
+    act = active_entry_acquire(rgt, gref);
     sha = shared_entry_header(rgt, gref);
     r_frame = act->frame;
 
@@ -1843,6 +1878,7 @@ __release_grant_for_copy(
         released_read = 1;
     }
 
+    active_entry_release(act);
     read_unlock(&rgt->lock);
 
     if ( td != rd )
@@ -1904,14 +1940,14 @@ __acquire_grant_for_copy(
     read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
-        PIN_FAIL(unlock_out, GNTST_general_error,
+        PIN_FAIL(gnt_unlock_out, GNTST_general_error,
                  "remote grant table not ready\n");
 
     if ( unlikely(gref >= nr_grant_entries(rgt)) )
-        PIN_FAIL(unlock_out, GNTST_bad_gntref,
+        PIN_FAIL(gnt_unlock_out, GNTST_bad_gntref,
                  "Bad grant reference %ld\n", gref);
 
-    act = &active_entry(rgt, gref);
+    act = active_entry_acquire(rgt, gref);
     shah = shared_entry_header(rgt, gref);
     if ( rgt->gt_version == 1 )
     {
@@ -1974,6 +2010,7 @@ __acquire_grant_for_copy(
             /* __acquire_grant_for_copy() could take the read lock on
              * the right table (if rd == td), so we have to drop the
              * lock here and reacquire */
+            active_entry_release(act);
             read_unlock(&rgt->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd->domain_id,
@@ -1981,8 +2018,11 @@ __acquire_grant_for_copy(
                                           &trans_page_off, &trans_length, 0);
 
             read_lock(&rgt->lock);
+            act = active_entry_acquire(rgt, gref);
+
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_copy_pin(act, status);
+                active_entry_release(act);
                 read_unlock(&rgt->lock);
                 rcu_unlock_domain(td);
                 return rc;
@@ -1996,6 +2036,7 @@ __acquire_grant_for_copy(
             {
                 __fixup_status_for_copy_pin(act, status);
                 rcu_unlock_domain(td);
+                active_entry_release(act);
                 read_unlock(&rgt->lock);
                 put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ldom, readonly,
@@ -2064,6 +2105,7 @@ __acquire_grant_for_copy(
     *length = act->length;
     *frame = act->frame;
 
+    active_entry_release(act);
     read_unlock(&rgt->lock);
     return rc;
  
@@ -2076,6 +2118,9 @@ __acquire_grant_for_copy(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
+    active_entry_release(act);
+
+ gnt_unlock_out:
     read_unlock(&rgt->lock);
     return rc;
 }
@@ -2259,16 +2304,18 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     {
         for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
-            act = &active_entry(gt, i);
+            act = active_entry_acquire(gt, i);
             if ( act->pin != 0 )
             {
                 gdprintk(XENLOG_WARNING,
                          "tried to change grant table version from %d to %d, but some grant entries still in use\n",
                          gt->gt_version,
                          op.version);
+                active_entry_release(act);
                 res = -EBUSY;
                 goto out_unlock;
             }
+            active_entry_release(act);
         }
     }
 
@@ -2447,7 +2494,8 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
 {
     struct domain *d = rcu_lock_current_domain();
     struct grant_table *gt = d->grant_table;
-    struct active_grant_entry *act;
+    struct active_grant_entry *act_a = NULL;
+    struct active_grant_entry *act_b = NULL;
     s16 rc = GNTST_okay;
 
     read_lock(&gt->lock);
@@ -2458,12 +2506,12 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     if ( unlikely(ref_b >= nr_grant_entries(d->grant_table)))
         PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-b (%d).\n", ref_b);
 
-    act = &active_entry(gt, ref_a);
-    if ( act->pin )
+    act_a = active_entry_acquire(gt, ref_a);
+    if ( act_a->pin )
         PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
 
-    act = &active_entry(gt, ref_b);
-    if ( act->pin )
+    act_b = active_entry_acquire(gt, ref_b);
+    if ( act_b->pin )
         PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
 
     if ( gt->gt_version == 1 )
@@ -2490,8 +2538,11 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     }
 
 out:
+    if ( act_b != NULL )
+        active_entry_release(act_b);
+    if ( act_a != NULL )
+        active_entry_release(act_a);
     read_unlock(&gt->lock);
-
     rcu_unlock_domain(d);
 
     return rc;
@@ -2807,7 +2858,7 @@ grant_table_create(
     struct domain *d)
 {
     struct grant_table *t;
-    int                 i;
+    int                 i, j;
 
     if ( (t = xzalloc(struct grant_table)) == NULL )
         goto no_mem_0;
@@ -2827,6 +2878,10 @@ grant_table_create(
         if ( (t->active[i] = alloc_xenheap_page()) == NULL )
             goto no_mem_2;
         clear_page(t->active[i]);
+        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+        {
+            spin_lock_init(&t->active[i][j].lock);
+        }
     }
 
     /* Tracking of mapped foreign frames table */
@@ -2923,7 +2978,7 @@ gnttab_release_mappings(
         rgt = rd->grant_table;
         read_lock(&rgt->lock);
 
-        act = &active_entry(rgt, ref);
+        act = active_entry_acquire(rgt, ref);
         sha = shared_entry_header(rgt, ref);
         if (rgt->gt_version == 1)
             status = &sha->flags;
@@ -2981,6 +3036,7 @@ gnttab_release_mappings(
         if ( act->pin == 0 )
             gnttab_clear_flag(_GTF_reading, status);
 
+        active_entry_release(act);
         read_unlock(&rgt->lock);
 
         rcu_unlock_domain(rd);
@@ -3001,7 +3057,7 @@ grant_table_destroy(
         return;
 
     write_lock(&t->lock);
-    
+
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
     xfree(t->shared_raw);
@@ -3047,9 +3103,11 @@ static void gnttab_usage_print(struct domain *rd)
         uint16_t status;
         uint64_t frame;
 
-        act = &active_entry(gt, ref);
-        if ( !act->pin )
+        act = active_entry_acquire(gt, ref);
+        if ( !act->pin ) {
+            active_entry_release(act);
             continue;
+        }
 
         sha = shared_entry_header(gt, ref);
 
@@ -3079,6 +3137,7 @@ static void gnttab_usage_print(struct domain *rd)
         printk("[%3d]    %5d 0x%06lx 0x%08x      %5d 0x%06"PRIx64" 0x%02x\n",
                ref, act->domid, act->frame, act->pin,
                sha->domid, frame, status);
+        active_entry_release(act);
     }
 
  out:
-- 
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 Dec 02 14:54:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:54:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvoqV-0005tU-Qf; Tue, 02 Dec 2014 14:54:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1XvoqU-0005tP-Ab
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:54:30 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	C0/24-28296-5A2DD745; Tue, 02 Dec 2014 14:54:29 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417532067!15301566!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE4NjQwNA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13919 invoked from network); 2 Dec 2014 14:54:29 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:54:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417532069; x=1449068069;
	h=from:to:cc:subject:date:message-id:mime-version;
	bh=lDw1ppr+TnRCeTHael+aqZ6fN+Apn2bj7FU821MmwYI=;
	b=EuoVldAbe3eNLTBgQ9POyN03kBznSBp20t3466IBwV+ylG84KtO6tmBS
	sxJPZbbI2wG3hiO1nt615NzCMhi4TQ4EOVj1nAgqSz6goRw8EjyHDG24z
	v0s/1g6pmjVGTILo87WpE71M462uYDeqSyx87MkCLaOcJo3bblLSYJ6U4 w=;
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="144835330"
Received: from email-inbound-relay-25001.iad12.amazon.com ([10.205.29.168])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 14:54:25 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com
	[10.0.103.150])
	by email-inbound-relay-25001.iad12.amazon.com (8.14.7/8.14.7) with
	ESMTP id sB2Es8m6015454
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Tue, 2 Dec 2014 14:54:23 GMT
Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 06:54:16 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.162.149) by
	EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 06:54:14 -0800
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 15:53:53 +0100
Message-ID: <1417532035-4395-1-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D06UWA003.ant.amazon.com (10.43.160.13) To
	EX13D03UWA003.ant.amazon.com (10.43.160.39)
Precedence: Bulk
Cc: Christoph Egger <chegger@amazon.de>
Subject: [Xen-devel] [PATCH v2 0/2] gnttab: Improve scaleability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 changes the grant table locking to
a more fain grained locking protocol. The result is
a performance boost measured with blkfront/blkback.
Document the locking protocol.

Christoph Egger (1):
  gnttab: Introduce rwlock to protect updates to grant table state

Matt Wilson (1):
  gnttab: refactor locking for scalability

 docs/misc/grant-tables.txt    |   49 +++++-
 xen/arch/arm/mm.c             |    4 +-
 xen/arch/x86/mm.c             |    4 +-
 xen/common/grant_table.c      |  330 ++++++++++++++++++++++++++---------------
 xen/include/xen/grant_table.h |    9 +-
 5 files changed, 265 insertions(+), 131 deletions(-)

-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 14:54:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvoqr-0005xN-Ob; Tue, 02 Dec 2014 14:54:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1Xvoqq-0005wo-0K
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:54:52 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	27/24-22777-BB2DD745; Tue, 02 Dec 2014 14:54:51 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417532089!5797590!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDEzMjEwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6096 invoked from network); 2 Dec 2014 14:54:50 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:54:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417532090; x=1449068090;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version;
	bh=/scCVTjKQbweLBGqtqU1aeeQs+vhukjiL1o7S78rkPU=;
	b=m6XRYgdrZRMuDJebOXYmQpGK/d+AuEjh/JRwqlW3lJqyBm+AN0qtzEHk
	13fSa3lKD15e/ZYi+IAhqRxlGg4h5CVOMnUISYhPEnjhZZTR1BWrrFud4
	P/sOVZIPdkuk7UYFpwHlNrbJwGZ5gDq5nUecF47rRQ/+C9oe5Fb8njVzi M=;
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="173808303"
Received: from email-inbound-relay-6003.iad6.amazon.com ([10.103.7.120])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 14:54:47 +0000
Received: from ex10-hub-7002.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com
	[10.0.103.150])
	by email-inbound-relay-6003.iad6.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB2EsXEZ003174
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 14:54:46 GMT
Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by
	ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 06:54:19 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.162.149) by
	EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 06:54:15 -0800
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 15:53:54 +0100
Message-ID: <1417532035-4395-2-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1417532035-4395-1-git-send-email-chegger@amazon.de>
References: <1417532035-4395-1-git-send-email-chegger@amazon.de>
MIME-Version: 1.0
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D06UWA003.ant.amazon.com (10.43.160.13) To
	EX13D03UWA003.ant.amazon.com (10.43.160.39)
Precedence: Bulk
Cc: Christoph Egger <chegger@amazon.de>, Keir Fraser <keir@xen.org>, Jan
	Beulich <jbeulich@suse.com>, Matt Wilson <msw@amazon.com>,
	Julien Grall <julien.grall@linaro.org>
Subject: [Xen-devel] [PATCH v2 1/2] gnttab: Introduce rwlock to protect
	updates to grant table state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Split grant table lock into two separate locks. One to protect
maptrack state and change the other into a rwlock.

The rwlock is used to prevent readers from accessing
inconsistent grant table state such as current
version, partially initialized active table pages,
etc.

Signed-off-by: Matt Wilson <msw@amazon.com>
[chegger: ported to xen-staging, split into multiple commits]

v2:
  * Add arm part per request from Julien Grall

Signed-off-by: Christoph Egger <chegger@amazon.de>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Julien Grall <julien.grall@linaro.org>
---
 docs/misc/grant-tables.txt    |   28 ++++++++-
 xen/arch/arm/mm.c             |    4 +-
 xen/arch/x86/mm.c             |    4 +-
 xen/common/grant_table.c      |  135 ++++++++++++++++++++++++-----------------
 xen/include/xen/grant_table.h |    9 ++-
 5 files changed, 117 insertions(+), 63 deletions(-)

diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt
index 19db4ec..c9ae8f2 100644
--- a/docs/misc/grant-tables.txt
+++ b/docs/misc/grant-tables.txt
@@ -74,7 +74,33 @@ is complete.
  matching map track entry is then removed, as if unmap had been invoked.
  These are not used by the transfer mechanism.
   map->domid         : owner of the mapped frame
-  map->ref_and_flags : grant reference, ro/rw, mapped for host or device access
+  map->ref           : grant reference
+  map->flags         : ro/rw, mapped for host or device access
+
+********************************************************************************
+ Locking
+ ~~~~~~~
+ Xen uses several locks to serialize access to the internal grant table state.
+
+  grant_table->lock          : rwlock used to prevent readers from accessing
+                               inconsistent grant table state such as current
+                               version, partially initialized active table pages,
+                               etc.
+  grant_table->maptrack_lock : spinlock used to protect the maptrack state
+
+ The primary lock for the grant table is a read/write spinlock. All
+ functions that access members of struct grant_table must acquire a
+ read lock around critical sections. Any modification to the members
+ of struct grant_table (e.g., nr_status_frames, nr_grant_frames,
+ active frames, etc.) must only be made if the write lock is
+ held. These elements are read-mostly, and read critical sections can
+ be large, which makes a rwlock a good choice.
+
+ The maptrack state is protected by its own spinlock. Any access (read
+ or write) of struct grant_table members that have a "maptrack_"
+ prefix must be made while holding the maptrack lock. The maptrack
+ state can be rapidly modified under some workloads, and the critical
+ sections are very small, thus we use a spinlock to protect them.
 
 ********************************************************************************
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7d4ba0c..2765683 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1037,7 +1037,7 @@ int xenmem_add_to_physmap_one(
     switch ( space )
     {
     case XENMAPSPACE_grant_table:
-        spin_lock(&d->grant_table->lock);
+        write_lock(&d->grant_table->lock);
 
         if ( d->grant_table->gt_version == 0 )
             d->grant_table->gt_version = 1;
@@ -1067,7 +1067,7 @@ int xenmem_add_to_physmap_one(
 
         t = p2m_ram_rw;
 
-        spin_unlock(&d->grant_table->lock);
+        write_unlock(&d->grant_table->lock);
         break;
     case XENMAPSPACE_shared_info:
         if ( idx != 0 )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 522c43d..37c13b1 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
                 mfn = virt_to_mfn(d->shared_info);
             break;
         case XENMAPSPACE_grant_table:
-            spin_lock(&d->grant_table->lock);
+            write_lock(&d->grant_table->lock);
 
             if ( d->grant_table->gt_version == 0 )
                 d->grant_table->gt_version = 1;
@@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
                     mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
             }
 
-            spin_unlock(&d->grant_table->lock);
+            write_unlock(&d->grant_table->lock);
             break;
         case XENMAPSPACE_gmfn_range:
         case XENMAPSPACE_gmfn:
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 8fba923..018b5b6 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -227,23 +227,23 @@ double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
 {
     if ( lgt < rgt )
     {
-        spin_lock(&lgt->lock);
-        spin_lock(&rgt->lock);
+        spin_lock(&lgt->maptrack_lock);
+        spin_lock(&rgt->maptrack_lock);
     }
     else
     {
         if ( lgt != rgt )
-            spin_lock(&rgt->lock);
-        spin_lock(&lgt->lock);
+            spin_lock(&rgt->maptrack_lock);
+        spin_lock(&lgt->maptrack_lock);
     }
 }
 
 static inline void
 double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
 {
-    spin_unlock(&lgt->lock);
+    spin_unlock(&lgt->maptrack_lock);
     if ( lgt != rgt )
-        spin_unlock(&rgt->lock);
+        spin_unlock(&rgt->maptrack_lock);
 }
 
 static inline int
@@ -261,10 +261,10 @@ static inline void
 put_maptrack_handle(
     struct grant_table *t, int handle)
 {
-    spin_lock(&t->lock);
+    spin_lock(&t->maptrack_lock);
     maptrack_entry(t, handle).ref = t->maptrack_head;
     t->maptrack_head = handle;
-    spin_unlock(&t->lock);
+    spin_unlock(&t->maptrack_lock);
 }
 
 static inline int
@@ -276,7 +276,7 @@ get_maptrack_handle(
     struct grant_mapping *new_mt;
     unsigned int          new_mt_limit, nr_frames;
 
-    spin_lock(&lgt->lock);
+    spin_lock(&lgt->maptrack_lock);
 
     while ( unlikely((handle = __get_maptrack_handle(lgt)) == -1) )
     {
@@ -305,7 +305,7 @@ get_maptrack_handle(
                  nr_frames + 1);
     }
 
-    spin_unlock(&lgt->lock);
+    spin_unlock(&lgt->maptrack_lock);
 
     return handle;
 }
@@ -502,7 +502,7 @@ static int grant_map_exists(const struct domain *ld,
     const struct active_grant_entry *act;
     unsigned int ref, max_iter;
     
-    ASSERT(spin_is_locked(&rgt->lock));
+    ASSERT(rw_is_locked(&rgt->lock));
 
     max_iter = min(*ref_count + (1 << GNTTABOP_CONTINUATION_ARG_SHIFT),
                    nr_grant_entries(rgt));
@@ -623,7 +623,7 @@ __gnttab_map_grant_ref(
     }
 
     rgt = rd->grant_table;
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
         PIN_FAIL(unlock_out, GNTST_general_error,
@@ -696,7 +696,7 @@ __gnttab_map_grant_ref(
 
     cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
 
     /* pg may be set, with a refcount included, from __get_paged_frame */
     if ( !pg )
@@ -831,7 +831,7 @@ __gnttab_map_grant_ref(
         put_page(pg);
     }
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     act = &active_entry(rgt, op->ref);
 
@@ -851,7 +851,7 @@ __gnttab_map_grant_ref(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     op->status = rc;
     put_maptrack_handle(lgt, handle);
     rcu_unlock_domain(rd);
@@ -891,28 +891,28 @@ __gnttab_unmap_common(
     ld = current->domain;
     lgt = ld->grant_table;
 
+    read_lock(&lgt->lock);
     op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
 
     if ( unlikely(op->handle >= lgt->maptrack_limit) )
     {
+        read_unlock(&lgt->lock);
         gdprintk(XENLOG_INFO, "Bad handle (%d).\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
+    read_unlock(&lgt->lock);
     op->map = &maptrack_entry(lgt, op->handle);
-    spin_lock(&lgt->lock);
 
     if ( unlikely(!op->map->flags) )
     {
-        spin_unlock(&lgt->lock);
         gdprintk(XENLOG_INFO, "Zero flags for handle (%d).\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
     dom = op->map->domid;
-    spin_unlock(&lgt->lock);
 
     if ( unlikely((rd = rcu_lock_domain_by_id(dom)) == NULL) )
     {
@@ -944,6 +944,7 @@ __gnttab_unmap_common(
     }
 
     op->rd = rd;
+    read_lock(&rgt->lock);
     act = &active_entry(rgt, op->map->ref);
 
     if ( op->frame == 0 )
@@ -1004,6 +1005,7 @@ __gnttab_unmap_common(
 
  unmap_out:
     double_gt_unlock(lgt, rgt);
+    read_unlock(&rgt->lock);
     op->status = rc;
     rcu_unlock_domain(rd);
 }
@@ -1033,8 +1035,8 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
 
     rcu_lock_domain(rd);
     rgt = rd->grant_table;
-    spin_lock(&rgt->lock);
 
+    read_lock(&rgt->lock);
     if ( rgt->gt_version == 0 )
         goto unmap_out;
 
@@ -1098,7 +1100,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
         gnttab_clear_flag(_GTF_reading, status);
 
  unmap_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     if ( put_handle )
     {
         op->map->flags = 0;
@@ -1284,10 +1286,13 @@ gnttab_unpopulate_status_frames(struct domain *d, struct grant_table *gt)
     gt->nr_status_frames = 0;
 }
 
+/* Grow the grant table. The caller must hold the grant table's
+ * write lock before calling this function.
+ */
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
 {
-    /* d's grant table lock must be held by the caller */
+    /* d's grant table write lock must be held by the caller */
 
     struct grant_table *gt = d->grant_table;
     unsigned int i;
@@ -1392,7 +1397,7 @@ gnttab_setup_table(
     }
 
     gt = d->grant_table;
-    spin_lock(&gt->lock);
+    write_lock(&gt->lock);
 
     if ( gt->gt_version == 0 )
         gt->gt_version = 1;
@@ -1420,7 +1425,7 @@ gnttab_setup_table(
     }
 
  out3:
-    spin_unlock(&gt->lock);
+    write_unlock(&gt->lock);
  out2:
     rcu_unlock_domain(d);
  out1:
@@ -1462,13 +1467,13 @@ gnttab_query_size(
         goto query_out_unlock;
     }
 
-    spin_lock(&d->grant_table->lock);
+    read_lock(&d->grant_table->lock);
 
     op.nr_frames     = nr_grant_frames(d->grant_table);
     op.max_nr_frames = max_grant_frames;
     op.status        = GNTST_okay;
 
-    spin_unlock(&d->grant_table->lock);
+    read_unlock(&d->grant_table->lock);
 
  
  query_out_unlock:
@@ -1494,7 +1499,7 @@ gnttab_prepare_for_transfer(
     union grant_combo   scombo, prev_scombo, new_scombo;
     int                 retries = 0;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
     {
@@ -1545,11 +1550,11 @@ gnttab_prepare_for_transfer(
         scombo = prev_scombo;
     }
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return 1;
 
  fail:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return 0;
 }
 
@@ -1741,7 +1746,7 @@ gnttab_transfer(
         TRACE_1D(TRC_MEM_PAGE_GRANT_TRANSFER, e->domain_id);
 
         /* Tell the guest about its new page frame. */
-        spin_lock(&e->grant_table->lock);
+        read_lock(&e->grant_table->lock);
 
         if ( e->grant_table->gt_version == 1 )
         {
@@ -1759,7 +1764,7 @@ gnttab_transfer(
         shared_entry_header(e->grant_table, gop.ref)->flags |=
             GTF_transfer_completed;
 
-        spin_unlock(&e->grant_table->lock);
+        read_unlock(&e->grant_table->lock);
 
         rcu_unlock_domain(e);
 
@@ -1797,7 +1802,7 @@ __release_grant_for_copy(
     released_read = 0;
     released_write = 0;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     act = &active_entry(rgt, gref);
     sha = shared_entry_header(rgt, gref);
@@ -1838,7 +1843,7 @@ __release_grant_for_copy(
         released_read = 1;
     }
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
 
     if ( td != rd )
     {
@@ -1896,7 +1901,7 @@ __acquire_grant_for_copy(
 
     *page = NULL;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
         PIN_FAIL(unlock_out, GNTST_general_error,
@@ -1965,17 +1970,21 @@ __acquire_grant_for_copy(
                 PIN_FAIL(unlock_out_clear, GNTST_general_error,
                          "transitive grant referenced bad domain %d\n",
                          trans_domid);
-            spin_unlock(&rgt->lock);
+
+            /* __acquire_grant_for_copy() could take the read lock on
+             * the right table (if rd == td), so we have to drop the
+             * lock here and reacquire */
+            read_unlock(&rgt->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd->domain_id,
                                           readonly, &grant_frame, page,
                                           &trans_page_off, &trans_length, 0);
 
-            spin_lock(&rgt->lock);
+            read_lock(&rgt->lock);
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_copy_pin(act, status);
+                read_unlock(&rgt->lock);
                 rcu_unlock_domain(td);
-                spin_unlock(&rgt->lock);
                 return rc;
             }
 
@@ -1987,7 +1996,7 @@ __acquire_grant_for_copy(
             {
                 __fixup_status_for_copy_pin(act, status);
                 rcu_unlock_domain(td);
-                spin_unlock(&rgt->lock);
+                read_unlock(&rgt->lock);
                 put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ldom, readonly,
                                                 frame, page, page_off, length,
@@ -2055,7 +2064,7 @@ __acquire_grant_for_copy(
     *length = act->length;
     *frame = act->frame;
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return rc;
  
  unlock_out_clear:
@@ -2067,7 +2076,7 @@ __acquire_grant_for_copy(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return rc;
 }
 
@@ -2241,7 +2250,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     if ( gt->gt_version == op.version )
         goto out;
 
-    spin_lock(&gt->lock);
+    write_lock(&gt->lock);
     /* Make sure that the grant table isn't currently in use when we
        change the version number, except for the first 8 entries which
        are allowed to be in use (xenstore/xenconsole keeps them mapped).
@@ -2327,7 +2336,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     gt->gt_version = op.version;
 
 out_unlock:
-    spin_unlock(&gt->lock);
+    write_unlock(&gt->lock);
 
 out:
     op.version = gt->gt_version;
@@ -2383,7 +2392,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
 
     op.status = GNTST_okay;
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     for ( i = 0; i < op.nr_frames; i++ )
     {
@@ -2392,7 +2401,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
             op.status = GNTST_bad_virt_addr;
     }
 
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 out2:
     rcu_unlock_domain(d);
 out1:
@@ -2441,7 +2450,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     struct active_grant_entry *act;
     s16 rc = GNTST_okay;
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     /* Bounds check on the grant refs */
     if ( unlikely(ref_a >= nr_grant_entries(d->grant_table)))
@@ -2481,7 +2490,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     }
 
 out:
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 
     rcu_unlock_domain(d);
 
@@ -2501,8 +2510,19 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) uop,
             return i;
         if ( unlikely(__copy_from_guest(&op, uop, 1)) )
             return -EFAULT;
-        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
-        if ( unlikely(__copy_field_to_guest(uop, &op, status)) )
+        if ( unlikely(op.ref_a == op.ref_b) )
+        {
+            /* noop, so avoid acquiring the same active entry
+             * twice in __gnttab_swap_grant_ref(), which would
+             * case a deadlock.
+             */
+            op.status = GNTST_okay;
+        }
+        else
+        {
+            op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
+        }
+        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
             return -EFAULT;
         guest_handle_add_offset(uop, 1);
     }
@@ -2552,12 +2572,12 @@ static int __gnttab_cache_flush(gnttab_cache_flush_t *cflush,
 
     if ( d != owner )
     {
-        spin_lock(&owner->grant_table->lock);
+        read_lock(&owner->grant_table->lock);
 
         ret = grant_map_exists(d, owner->grant_table, mfn, ref_count);
         if ( ret != 0 )
         {
-            spin_unlock(&owner->grant_table->lock);
+            read_unlock(&owner->grant_table->lock);
             rcu_unlock_domain(d);
             put_page(page);
             return ret;
@@ -2577,7 +2597,7 @@ static int __gnttab_cache_flush(gnttab_cache_flush_t *cflush,
         ret = 0;
 
     if ( d != owner )
-        spin_unlock(&owner->grant_table->lock);
+        read_unlock(&owner->grant_table->lock);
     unmap_domain_page(v);
     put_page(page);
 
@@ -2793,7 +2813,8 @@ grant_table_create(
         goto no_mem_0;
 
     /* Simple stuff. */
-    spin_lock_init(&t->lock);
+    rwlock_init(&t->lock);
+    spin_lock_init(&t->maptrack_lock);
     t->nr_grant_frames = INITIAL_NR_GRANT_FRAMES;
 
     /* Active grant table. */
@@ -2900,7 +2921,7 @@ gnttab_release_mappings(
         }
 
         rgt = rd->grant_table;
-        spin_lock(&rgt->lock);
+        read_lock(&rgt->lock);
 
         act = &active_entry(rgt, ref);
         sha = shared_entry_header(rgt, ref);
@@ -2960,7 +2981,7 @@ gnttab_release_mappings(
         if ( act->pin == 0 )
             gnttab_clear_flag(_GTF_reading, status);
 
-        spin_unlock(&rgt->lock);
+        read_unlock(&rgt->lock);
 
         rcu_unlock_domain(rd);
 
@@ -2978,6 +2999,8 @@ grant_table_destroy(
 
     if ( t == NULL )
         return;
+
+    write_lock(&t->lock);
     
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
@@ -2995,6 +3018,8 @@ grant_table_destroy(
         free_xenheap_page(t->status[i]);
     xfree(t->status);
 
+    write_unlock(&t->lock);
+
     xfree(t);
     d->grant_table = NULL;
 }
@@ -3008,7 +3033,7 @@ static void gnttab_usage_print(struct domain *rd)
     printk("      -------- active --------       -------- shared --------\n");
     printk("[ref] localdom mfn      pin          localdom gmfn     flags\n");
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     if ( gt->gt_version == 0 )
         goto out;
@@ -3057,7 +3082,7 @@ static void gnttab_usage_print(struct domain *rd)
     }
 
  out:
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 
     if ( first )
         printk("grant-table for remote domain:%5d ... "
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 32f5786..ca49b41 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -82,8 +82,11 @@ struct grant_table {
     struct grant_mapping **maptrack;
     unsigned int          maptrack_head;
     unsigned int          maptrack_limit;
-    /* Lock protecting updates to active and shared grant tables. */
-    spinlock_t            lock;
+    /* Lock protecting the maptrack page list, head, and limit */
+    spinlock_t            maptrack_lock;
+    /* Lock protecting updates to grant table state (version, active
+       entry list, etc.) */
+    rwlock_t              lock;
     /* The defined versions are 1 and 2.  Set to 0 if we don't know
        what version to use yet. */
     unsigned              gt_version;
@@ -101,7 +104,7 @@ gnttab_release_mappings(
     struct domain *d);
 
 /* Increase the size of a domain's grant table.
- * Caller must hold d's grant table lock.
+ * Caller must hold d's grant table write lock.
  */
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames);
-- 
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 Dec 02 14:54:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvoqr-0005xN-Ob; Tue, 02 Dec 2014 14:54:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40648fc38=chegger@amazon.de>)
	id 1Xvoqq-0005wo-0K
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:54:52 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	27/24-22777-BB2DD745; Tue, 02 Dec 2014 14:54:51 +0000
X-Env-Sender: prvs=40648fc38=chegger@amazon.de
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417532089!5797590!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDEzMjEwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6096 invoked from network); 2 Dec 2014 14:54:50 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 14:54:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417532090; x=1449068090;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version;
	bh=/scCVTjKQbweLBGqtqU1aeeQs+vhukjiL1o7S78rkPU=;
	b=m6XRYgdrZRMuDJebOXYmQpGK/d+AuEjh/JRwqlW3lJqyBm+AN0qtzEHk
	13fSa3lKD15e/ZYi+IAhqRxlGg4h5CVOMnUISYhPEnjhZZTR1BWrrFud4
	P/sOVZIPdkuk7UYFpwHlNrbJwGZ5gDq5nUecF47rRQ/+C9oe5Fb8njVzi M=;
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="173808303"
Received: from email-inbound-relay-6003.iad6.amazon.com ([10.103.7.120])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 14:54:47 +0000
Received: from ex10-hub-7002.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com
	[10.0.103.150])
	by email-inbound-relay-6003.iad6.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB2EsXEZ003174
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 14:54:46 GMT
Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by
	ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Tue, 2 Dec 2014 06:54:19 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.162.149) by
	EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Tue, 2 Dec 2014 06:54:15 -0800
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 15:53:54 +0100
Message-ID: <1417532035-4395-2-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1417532035-4395-1-git-send-email-chegger@amazon.de>
References: <1417532035-4395-1-git-send-email-chegger@amazon.de>
MIME-Version: 1.0
X-Originating-IP: [10.43.162.149]
X-ClientProxiedBy: EX13D06UWA003.ant.amazon.com (10.43.160.13) To
	EX13D03UWA003.ant.amazon.com (10.43.160.39)
Precedence: Bulk
Cc: Christoph Egger <chegger@amazon.de>, Keir Fraser <keir@xen.org>, Jan
	Beulich <jbeulich@suse.com>, Matt Wilson <msw@amazon.com>,
	Julien Grall <julien.grall@linaro.org>
Subject: [Xen-devel] [PATCH v2 1/2] gnttab: Introduce rwlock to protect
	updates to grant table state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Split grant table lock into two separate locks. One to protect
maptrack state and change the other into a rwlock.

The rwlock is used to prevent readers from accessing
inconsistent grant table state such as current
version, partially initialized active table pages,
etc.

Signed-off-by: Matt Wilson <msw@amazon.com>
[chegger: ported to xen-staging, split into multiple commits]

v2:
  * Add arm part per request from Julien Grall

Signed-off-by: Christoph Egger <chegger@amazon.de>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Julien Grall <julien.grall@linaro.org>
---
 docs/misc/grant-tables.txt    |   28 ++++++++-
 xen/arch/arm/mm.c             |    4 +-
 xen/arch/x86/mm.c             |    4 +-
 xen/common/grant_table.c      |  135 ++++++++++++++++++++++++-----------------
 xen/include/xen/grant_table.h |    9 ++-
 5 files changed, 117 insertions(+), 63 deletions(-)

diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt
index 19db4ec..c9ae8f2 100644
--- a/docs/misc/grant-tables.txt
+++ b/docs/misc/grant-tables.txt
@@ -74,7 +74,33 @@ is complete.
  matching map track entry is then removed, as if unmap had been invoked.
  These are not used by the transfer mechanism.
   map->domid         : owner of the mapped frame
-  map->ref_and_flags : grant reference, ro/rw, mapped for host or device access
+  map->ref           : grant reference
+  map->flags         : ro/rw, mapped for host or device access
+
+********************************************************************************
+ Locking
+ ~~~~~~~
+ Xen uses several locks to serialize access to the internal grant table state.
+
+  grant_table->lock          : rwlock used to prevent readers from accessing
+                               inconsistent grant table state such as current
+                               version, partially initialized active table pages,
+                               etc.
+  grant_table->maptrack_lock : spinlock used to protect the maptrack state
+
+ The primary lock for the grant table is a read/write spinlock. All
+ functions that access members of struct grant_table must acquire a
+ read lock around critical sections. Any modification to the members
+ of struct grant_table (e.g., nr_status_frames, nr_grant_frames,
+ active frames, etc.) must only be made if the write lock is
+ held. These elements are read-mostly, and read critical sections can
+ be large, which makes a rwlock a good choice.
+
+ The maptrack state is protected by its own spinlock. Any access (read
+ or write) of struct grant_table members that have a "maptrack_"
+ prefix must be made while holding the maptrack lock. The maptrack
+ state can be rapidly modified under some workloads, and the critical
+ sections are very small, thus we use a spinlock to protect them.
 
 ********************************************************************************
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7d4ba0c..2765683 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1037,7 +1037,7 @@ int xenmem_add_to_physmap_one(
     switch ( space )
     {
     case XENMAPSPACE_grant_table:
-        spin_lock(&d->grant_table->lock);
+        write_lock(&d->grant_table->lock);
 
         if ( d->grant_table->gt_version == 0 )
             d->grant_table->gt_version = 1;
@@ -1067,7 +1067,7 @@ int xenmem_add_to_physmap_one(
 
         t = p2m_ram_rw;
 
-        spin_unlock(&d->grant_table->lock);
+        write_unlock(&d->grant_table->lock);
         break;
     case XENMAPSPACE_shared_info:
         if ( idx != 0 )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 522c43d..37c13b1 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
                 mfn = virt_to_mfn(d->shared_info);
             break;
         case XENMAPSPACE_grant_table:
-            spin_lock(&d->grant_table->lock);
+            write_lock(&d->grant_table->lock);
 
             if ( d->grant_table->gt_version == 0 )
                 d->grant_table->gt_version = 1;
@@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
                     mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
             }
 
-            spin_unlock(&d->grant_table->lock);
+            write_unlock(&d->grant_table->lock);
             break;
         case XENMAPSPACE_gmfn_range:
         case XENMAPSPACE_gmfn:
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 8fba923..018b5b6 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -227,23 +227,23 @@ double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
 {
     if ( lgt < rgt )
     {
-        spin_lock(&lgt->lock);
-        spin_lock(&rgt->lock);
+        spin_lock(&lgt->maptrack_lock);
+        spin_lock(&rgt->maptrack_lock);
     }
     else
     {
         if ( lgt != rgt )
-            spin_lock(&rgt->lock);
-        spin_lock(&lgt->lock);
+            spin_lock(&rgt->maptrack_lock);
+        spin_lock(&lgt->maptrack_lock);
     }
 }
 
 static inline void
 double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
 {
-    spin_unlock(&lgt->lock);
+    spin_unlock(&lgt->maptrack_lock);
     if ( lgt != rgt )
-        spin_unlock(&rgt->lock);
+        spin_unlock(&rgt->maptrack_lock);
 }
 
 static inline int
@@ -261,10 +261,10 @@ static inline void
 put_maptrack_handle(
     struct grant_table *t, int handle)
 {
-    spin_lock(&t->lock);
+    spin_lock(&t->maptrack_lock);
     maptrack_entry(t, handle).ref = t->maptrack_head;
     t->maptrack_head = handle;
-    spin_unlock(&t->lock);
+    spin_unlock(&t->maptrack_lock);
 }
 
 static inline int
@@ -276,7 +276,7 @@ get_maptrack_handle(
     struct grant_mapping *new_mt;
     unsigned int          new_mt_limit, nr_frames;
 
-    spin_lock(&lgt->lock);
+    spin_lock(&lgt->maptrack_lock);
 
     while ( unlikely((handle = __get_maptrack_handle(lgt)) == -1) )
     {
@@ -305,7 +305,7 @@ get_maptrack_handle(
                  nr_frames + 1);
     }
 
-    spin_unlock(&lgt->lock);
+    spin_unlock(&lgt->maptrack_lock);
 
     return handle;
 }
@@ -502,7 +502,7 @@ static int grant_map_exists(const struct domain *ld,
     const struct active_grant_entry *act;
     unsigned int ref, max_iter;
     
-    ASSERT(spin_is_locked(&rgt->lock));
+    ASSERT(rw_is_locked(&rgt->lock));
 
     max_iter = min(*ref_count + (1 << GNTTABOP_CONTINUATION_ARG_SHIFT),
                    nr_grant_entries(rgt));
@@ -623,7 +623,7 @@ __gnttab_map_grant_ref(
     }
 
     rgt = rd->grant_table;
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
         PIN_FAIL(unlock_out, GNTST_general_error,
@@ -696,7 +696,7 @@ __gnttab_map_grant_ref(
 
     cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
 
     /* pg may be set, with a refcount included, from __get_paged_frame */
     if ( !pg )
@@ -831,7 +831,7 @@ __gnttab_map_grant_ref(
         put_page(pg);
     }
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     act = &active_entry(rgt, op->ref);
 
@@ -851,7 +851,7 @@ __gnttab_map_grant_ref(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     op->status = rc;
     put_maptrack_handle(lgt, handle);
     rcu_unlock_domain(rd);
@@ -891,28 +891,28 @@ __gnttab_unmap_common(
     ld = current->domain;
     lgt = ld->grant_table;
 
+    read_lock(&lgt->lock);
     op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
 
     if ( unlikely(op->handle >= lgt->maptrack_limit) )
     {
+        read_unlock(&lgt->lock);
         gdprintk(XENLOG_INFO, "Bad handle (%d).\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
+    read_unlock(&lgt->lock);
     op->map = &maptrack_entry(lgt, op->handle);
-    spin_lock(&lgt->lock);
 
     if ( unlikely(!op->map->flags) )
     {
-        spin_unlock(&lgt->lock);
         gdprintk(XENLOG_INFO, "Zero flags for handle (%d).\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
     dom = op->map->domid;
-    spin_unlock(&lgt->lock);
 
     if ( unlikely((rd = rcu_lock_domain_by_id(dom)) == NULL) )
     {
@@ -944,6 +944,7 @@ __gnttab_unmap_common(
     }
 
     op->rd = rd;
+    read_lock(&rgt->lock);
     act = &active_entry(rgt, op->map->ref);
 
     if ( op->frame == 0 )
@@ -1004,6 +1005,7 @@ __gnttab_unmap_common(
 
  unmap_out:
     double_gt_unlock(lgt, rgt);
+    read_unlock(&rgt->lock);
     op->status = rc;
     rcu_unlock_domain(rd);
 }
@@ -1033,8 +1035,8 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
 
     rcu_lock_domain(rd);
     rgt = rd->grant_table;
-    spin_lock(&rgt->lock);
 
+    read_lock(&rgt->lock);
     if ( rgt->gt_version == 0 )
         goto unmap_out;
 
@@ -1098,7 +1100,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
         gnttab_clear_flag(_GTF_reading, status);
 
  unmap_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     if ( put_handle )
     {
         op->map->flags = 0;
@@ -1284,10 +1286,13 @@ gnttab_unpopulate_status_frames(struct domain *d, struct grant_table *gt)
     gt->nr_status_frames = 0;
 }
 
+/* Grow the grant table. The caller must hold the grant table's
+ * write lock before calling this function.
+ */
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
 {
-    /* d's grant table lock must be held by the caller */
+    /* d's grant table write lock must be held by the caller */
 
     struct grant_table *gt = d->grant_table;
     unsigned int i;
@@ -1392,7 +1397,7 @@ gnttab_setup_table(
     }
 
     gt = d->grant_table;
-    spin_lock(&gt->lock);
+    write_lock(&gt->lock);
 
     if ( gt->gt_version == 0 )
         gt->gt_version = 1;
@@ -1420,7 +1425,7 @@ gnttab_setup_table(
     }
 
  out3:
-    spin_unlock(&gt->lock);
+    write_unlock(&gt->lock);
  out2:
     rcu_unlock_domain(d);
  out1:
@@ -1462,13 +1467,13 @@ gnttab_query_size(
         goto query_out_unlock;
     }
 
-    spin_lock(&d->grant_table->lock);
+    read_lock(&d->grant_table->lock);
 
     op.nr_frames     = nr_grant_frames(d->grant_table);
     op.max_nr_frames = max_grant_frames;
     op.status        = GNTST_okay;
 
-    spin_unlock(&d->grant_table->lock);
+    read_unlock(&d->grant_table->lock);
 
  
  query_out_unlock:
@@ -1494,7 +1499,7 @@ gnttab_prepare_for_transfer(
     union grant_combo   scombo, prev_scombo, new_scombo;
     int                 retries = 0;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
     {
@@ -1545,11 +1550,11 @@ gnttab_prepare_for_transfer(
         scombo = prev_scombo;
     }
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return 1;
 
  fail:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return 0;
 }
 
@@ -1741,7 +1746,7 @@ gnttab_transfer(
         TRACE_1D(TRC_MEM_PAGE_GRANT_TRANSFER, e->domain_id);
 
         /* Tell the guest about its new page frame. */
-        spin_lock(&e->grant_table->lock);
+        read_lock(&e->grant_table->lock);
 
         if ( e->grant_table->gt_version == 1 )
         {
@@ -1759,7 +1764,7 @@ gnttab_transfer(
         shared_entry_header(e->grant_table, gop.ref)->flags |=
             GTF_transfer_completed;
 
-        spin_unlock(&e->grant_table->lock);
+        read_unlock(&e->grant_table->lock);
 
         rcu_unlock_domain(e);
 
@@ -1797,7 +1802,7 @@ __release_grant_for_copy(
     released_read = 0;
     released_write = 0;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     act = &active_entry(rgt, gref);
     sha = shared_entry_header(rgt, gref);
@@ -1838,7 +1843,7 @@ __release_grant_for_copy(
         released_read = 1;
     }
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
 
     if ( td != rd )
     {
@@ -1896,7 +1901,7 @@ __acquire_grant_for_copy(
 
     *page = NULL;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
         PIN_FAIL(unlock_out, GNTST_general_error,
@@ -1965,17 +1970,21 @@ __acquire_grant_for_copy(
                 PIN_FAIL(unlock_out_clear, GNTST_general_error,
                          "transitive grant referenced bad domain %d\n",
                          trans_domid);
-            spin_unlock(&rgt->lock);
+
+            /* __acquire_grant_for_copy() could take the read lock on
+             * the right table (if rd == td), so we have to drop the
+             * lock here and reacquire */
+            read_unlock(&rgt->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd->domain_id,
                                           readonly, &grant_frame, page,
                                           &trans_page_off, &trans_length, 0);
 
-            spin_lock(&rgt->lock);
+            read_lock(&rgt->lock);
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_copy_pin(act, status);
+                read_unlock(&rgt->lock);
                 rcu_unlock_domain(td);
-                spin_unlock(&rgt->lock);
                 return rc;
             }
 
@@ -1987,7 +1996,7 @@ __acquire_grant_for_copy(
             {
                 __fixup_status_for_copy_pin(act, status);
                 rcu_unlock_domain(td);
-                spin_unlock(&rgt->lock);
+                read_unlock(&rgt->lock);
                 put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ldom, readonly,
                                                 frame, page, page_off, length,
@@ -2055,7 +2064,7 @@ __acquire_grant_for_copy(
     *length = act->length;
     *frame = act->frame;
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return rc;
  
  unlock_out_clear:
@@ -2067,7 +2076,7 @@ __acquire_grant_for_copy(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return rc;
 }
 
@@ -2241,7 +2250,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     if ( gt->gt_version == op.version )
         goto out;
 
-    spin_lock(&gt->lock);
+    write_lock(&gt->lock);
     /* Make sure that the grant table isn't currently in use when we
        change the version number, except for the first 8 entries which
        are allowed to be in use (xenstore/xenconsole keeps them mapped).
@@ -2327,7 +2336,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     gt->gt_version = op.version;
 
 out_unlock:
-    spin_unlock(&gt->lock);
+    write_unlock(&gt->lock);
 
 out:
     op.version = gt->gt_version;
@@ -2383,7 +2392,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
 
     op.status = GNTST_okay;
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     for ( i = 0; i < op.nr_frames; i++ )
     {
@@ -2392,7 +2401,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
             op.status = GNTST_bad_virt_addr;
     }
 
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 out2:
     rcu_unlock_domain(d);
 out1:
@@ -2441,7 +2450,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     struct active_grant_entry *act;
     s16 rc = GNTST_okay;
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     /* Bounds check on the grant refs */
     if ( unlikely(ref_a >= nr_grant_entries(d->grant_table)))
@@ -2481,7 +2490,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     }
 
 out:
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 
     rcu_unlock_domain(d);
 
@@ -2501,8 +2510,19 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) uop,
             return i;
         if ( unlikely(__copy_from_guest(&op, uop, 1)) )
             return -EFAULT;
-        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
-        if ( unlikely(__copy_field_to_guest(uop, &op, status)) )
+        if ( unlikely(op.ref_a == op.ref_b) )
+        {
+            /* noop, so avoid acquiring the same active entry
+             * twice in __gnttab_swap_grant_ref(), which would
+             * case a deadlock.
+             */
+            op.status = GNTST_okay;
+        }
+        else
+        {
+            op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
+        }
+        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
             return -EFAULT;
         guest_handle_add_offset(uop, 1);
     }
@@ -2552,12 +2572,12 @@ static int __gnttab_cache_flush(gnttab_cache_flush_t *cflush,
 
     if ( d != owner )
     {
-        spin_lock(&owner->grant_table->lock);
+        read_lock(&owner->grant_table->lock);
 
         ret = grant_map_exists(d, owner->grant_table, mfn, ref_count);
         if ( ret != 0 )
         {
-            spin_unlock(&owner->grant_table->lock);
+            read_unlock(&owner->grant_table->lock);
             rcu_unlock_domain(d);
             put_page(page);
             return ret;
@@ -2577,7 +2597,7 @@ static int __gnttab_cache_flush(gnttab_cache_flush_t *cflush,
         ret = 0;
 
     if ( d != owner )
-        spin_unlock(&owner->grant_table->lock);
+        read_unlock(&owner->grant_table->lock);
     unmap_domain_page(v);
     put_page(page);
 
@@ -2793,7 +2813,8 @@ grant_table_create(
         goto no_mem_0;
 
     /* Simple stuff. */
-    spin_lock_init(&t->lock);
+    rwlock_init(&t->lock);
+    spin_lock_init(&t->maptrack_lock);
     t->nr_grant_frames = INITIAL_NR_GRANT_FRAMES;
 
     /* Active grant table. */
@@ -2900,7 +2921,7 @@ gnttab_release_mappings(
         }
 
         rgt = rd->grant_table;
-        spin_lock(&rgt->lock);
+        read_lock(&rgt->lock);
 
         act = &active_entry(rgt, ref);
         sha = shared_entry_header(rgt, ref);
@@ -2960,7 +2981,7 @@ gnttab_release_mappings(
         if ( act->pin == 0 )
             gnttab_clear_flag(_GTF_reading, status);
 
-        spin_unlock(&rgt->lock);
+        read_unlock(&rgt->lock);
 
         rcu_unlock_domain(rd);
 
@@ -2978,6 +2999,8 @@ grant_table_destroy(
 
     if ( t == NULL )
         return;
+
+    write_lock(&t->lock);
     
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
@@ -2995,6 +3018,8 @@ grant_table_destroy(
         free_xenheap_page(t->status[i]);
     xfree(t->status);
 
+    write_unlock(&t->lock);
+
     xfree(t);
     d->grant_table = NULL;
 }
@@ -3008,7 +3033,7 @@ static void gnttab_usage_print(struct domain *rd)
     printk("      -------- active --------       -------- shared --------\n");
     printk("[ref] localdom mfn      pin          localdom gmfn     flags\n");
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     if ( gt->gt_version == 0 )
         goto out;
@@ -3057,7 +3082,7 @@ static void gnttab_usage_print(struct domain *rd)
     }
 
  out:
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 
     if ( first )
         printk("grant-table for remote domain:%5d ... "
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 32f5786..ca49b41 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -82,8 +82,11 @@ struct grant_table {
     struct grant_mapping **maptrack;
     unsigned int          maptrack_head;
     unsigned int          maptrack_limit;
-    /* Lock protecting updates to active and shared grant tables. */
-    spinlock_t            lock;
+    /* Lock protecting the maptrack page list, head, and limit */
+    spinlock_t            maptrack_lock;
+    /* Lock protecting updates to grant table state (version, active
+       entry list, etc.) */
+    rwlock_t              lock;
     /* The defined versions are 1 and 2.  Set to 0 if we don't know
        what version to use yet. */
     unsigned              gt_version;
@@ -101,7 +104,7 @@ gnttab_release_mappings(
     struct domain *d);
 
 /* Increase the size of a domain's grant table.
- * Caller must hold d's grant table lock.
+ * Caller must hold d's grant table write lock.
  */
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames);
-- 
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 Dec 02 14:54:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1Xvoqs-0005xr-7M; Tue, 02 Dec 2014 14:54:54 +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 1Xvoqq-0005x8-Sk
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:54:52 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	C0/1B-25547-CB2DD745; Tue, 02 Dec 2014 14:54:52 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417532091!15302033!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 18108 invoked from network); 2 Dec 2014 14:54:51 -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;
	2 Dec 2014 14:54:51 -0000
Received: by mail-wg0-f46.google.com with SMTP id a1so8952968wgh.5
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 06:54: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=sa49nkee3QQ1Ao1B7fbAXM+6Ijtd/aUJy5C1OrJ9eUw=;
	b=fj0JYkamLL/w0OKAkgMe6F7pj7f+lR+Ez+j2kAxPhYdJ6zTW5jLGaae+rNuxgYsGcH
	8lSNoF5IMtrQsPpHwgrtafw0moyEZ0lDazBIO9ReUjqLaIs2emit97EMt2OP5sXQdWgX
	VH6xDyfJ62dP+0ea5lx8Xa/6kyZzRXwguCM0KsbmCLNo0xF0Dw6CbLaHCaVRnpVxkQoV
	5A6wJ44dNPTQtznpfYuSHP4H8EZLPCs6J/SGrs0SWgRVrUypdQP6XFHlN3zIYH7BYlPG
	f3UFAjUZQ8HoUS7IXudKLwScS9370YYWq8ZZOHyzGasO++mB5/qZMSmk1k0XcRuM4xUz
	eIBQ==
X-Gm-Message-State: ALoCoQlKZKuMJY4hTx1GHCjdun8Oc12Y6fVWVRV5Ejvpe3yB99Y8Vfa71j6Ov35M5mgBGDgnNW3r
X-Received: by 10.180.20.106 with SMTP id m10mr47165784wie.1.1417532091415;
	Tue, 02 Dec 2014 06:54:51 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id a14sm3504425wib.22.2014.12.02.06.54.49
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 06:54:50 -0800 (PST)
Message-ID: <547DD2B6.1020202@linaro.org>
Date: Tue, 02 Dec 2014 14:54: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: Tiejun Chen <tiejun.chen@intel.com>, jbeulich@suse.com, 
	ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com, 
	ian.campbell@citrix.com, wei.liu2@citrix.com, kevin.tian@intel.com, 
	tim@xen.org, yang.z.zhang@intel.com
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
Cc: Tamas K Lengyel <tklengyel@sec.in.tum.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v8][PATCH 13/17] xen/mem_access: don't allow
 accessing reserved device 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

Hi,

CC Tamas as he did some work on memaccess for ARM.

On 01/12/14 09:24, Tiejun Chen wrote:
> We can't expost those reserved device memory in case of mem_access

s/expost/expose/

> since any access may corrupt device usage.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/common/mem_access.c | 41 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
> index 6c2724b..72a807a 100644
> --- a/xen/common/mem_access.c
> +++ b/xen/common/mem_access.c
> @@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)
>      }
>  }
>  
> +/* We can't expose reserved device memory. */
> +static int mem_access_check_rdm(struct domain *d, uint64_aligned_t start,
> +                                uint32_t nr)
> +{
> +    uint32_t i;
> +    struct p2m_get_reserved_device_memory pgrdm;

p2m_get_reserved_device_memory is only defined on x86. This will fail to
compile on ARM when memaccess is enabled.

> +    int rc = 0;
> +
> +    if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )
> +    {
> +        for ( i = 0; i < nr; i++ )
> +        {
> +            pgrdm.gfn = start + i;
> +            pgrdm.domain = d;
> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                                  &pgrdm);

Same here.

Overall, I'm not sure if it's worth to introduce this code in the common
part has it doesn't seem useful for ARM.

In any case, you have to at least stub those bits for ARM.

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 Dec 02 14:54:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1Xvoqs-0005xr-7M; Tue, 02 Dec 2014 14:54:54 +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 1Xvoqq-0005x8-Sk
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 14:54:52 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	C0/1B-25547-CB2DD745; Tue, 02 Dec 2014 14:54:52 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417532091!15302033!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 18108 invoked from network); 2 Dec 2014 14:54:51 -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;
	2 Dec 2014 14:54:51 -0000
Received: by mail-wg0-f46.google.com with SMTP id a1so8952968wgh.5
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 06:54: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=sa49nkee3QQ1Ao1B7fbAXM+6Ijtd/aUJy5C1OrJ9eUw=;
	b=fj0JYkamLL/w0OKAkgMe6F7pj7f+lR+Ez+j2kAxPhYdJ6zTW5jLGaae+rNuxgYsGcH
	8lSNoF5IMtrQsPpHwgrtafw0moyEZ0lDazBIO9ReUjqLaIs2emit97EMt2OP5sXQdWgX
	VH6xDyfJ62dP+0ea5lx8Xa/6kyZzRXwguCM0KsbmCLNo0xF0Dw6CbLaHCaVRnpVxkQoV
	5A6wJ44dNPTQtznpfYuSHP4H8EZLPCs6J/SGrs0SWgRVrUypdQP6XFHlN3zIYH7BYlPG
	f3UFAjUZQ8HoUS7IXudKLwScS9370YYWq8ZZOHyzGasO++mB5/qZMSmk1k0XcRuM4xUz
	eIBQ==
X-Gm-Message-State: ALoCoQlKZKuMJY4hTx1GHCjdun8Oc12Y6fVWVRV5Ejvpe3yB99Y8Vfa71j6Ov35M5mgBGDgnNW3r
X-Received: by 10.180.20.106 with SMTP id m10mr47165784wie.1.1417532091415;
	Tue, 02 Dec 2014 06:54:51 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id a14sm3504425wib.22.2014.12.02.06.54.49
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 06:54:50 -0800 (PST)
Message-ID: <547DD2B6.1020202@linaro.org>
Date: Tue, 02 Dec 2014 14:54: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: Tiejun Chen <tiejun.chen@intel.com>, jbeulich@suse.com, 
	ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com, 
	ian.campbell@citrix.com, wei.liu2@citrix.com, kevin.tian@intel.com, 
	tim@xen.org, yang.z.zhang@intel.com
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
Cc: Tamas K Lengyel <tklengyel@sec.in.tum.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [v8][PATCH 13/17] xen/mem_access: don't allow
 accessing reserved device 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

Hi,

CC Tamas as he did some work on memaccess for ARM.

On 01/12/14 09:24, Tiejun Chen wrote:
> We can't expost those reserved device memory in case of mem_access

s/expost/expose/

> since any access may corrupt device usage.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/common/mem_access.c | 41 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
> index 6c2724b..72a807a 100644
> --- a/xen/common/mem_access.c
> +++ b/xen/common/mem_access.c
> @@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)
>      }
>  }
>  
> +/* We can't expose reserved device memory. */
> +static int mem_access_check_rdm(struct domain *d, uint64_aligned_t start,
> +                                uint32_t nr)
> +{
> +    uint32_t i;
> +    struct p2m_get_reserved_device_memory pgrdm;

p2m_get_reserved_device_memory is only defined on x86. This will fail to
compile on ARM when memaccess is enabled.

> +    int rc = 0;
> +
> +    if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )
> +    {
> +        for ( i = 0; i < nr; i++ )
> +        {
> +            pgrdm.gfn = start + i;
> +            pgrdm.domain = d;
> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                                  &pgrdm);

Same here.

Overall, I'm not sure if it's worth to introduce this code in the common
part has it doesn't seem useful for ARM.

In any case, you have to at least stub those bits for ARM.

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 Dec 02 14:58:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1Xvoua-0006PH-1r; Tue, 02 Dec 2014 14:58:44 +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 1XvouY-0006P4-EW
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:58:42 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	9F/0F-01660-1A3DD745; Tue, 02 Dec 2014 14:58:41 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417532319!5798605!1
X-Originating-IP: [156.151.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 32386 invoked from network); 2 Dec 2014 14:58:41 -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; 2 Dec 2014 14:58:41 -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 sB2EwX0G022455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 14:58:34 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
	sB2EwXhI002303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 14:58:33 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
	sB2EwWw0003003; Tue, 2 Dec 2014 14:58:32 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 06:58:32 -0800
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Tue,  2 Dec 2014 15:57:54 +0100
Message-Id: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.7.10.4
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>, jbeulich@suse.com
Subject: [Xen-devel] [PATCH for-xen-4.5] console: increase initial conring
	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>
MIME-Version: 1.0
Content-Type: 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 general initial conring size is sufficient. However, if log
level is increased on platforms which have e.g. huge number
of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
which has more than 200 entries in EFI memory map) then some
of earlier messages in console ring are overwritten. It means
that in case of issues deeper analysis can be hindered. Sadly
conring_size argument does not help because new console buffer
is allocated late on heap. It means that it is not possible to
allocate larger ring earlier. So, in this situation initial
conring size should be increased. My experiments showed that
even on not so big machines more than 26 KiB of free space are
needed for initial messages. In theory we could increase conring
size buffer to 32 KiB. However, I think that this value could be
too small for huge machines with large number of ACPI tables and
EFI memory regions. Hence, this patch increases initial conring
size to 64 KiB.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/drivers/char/console.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 2f03259..429d296 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -67,7 +67,7 @@ custom_param("console_timestamps", parse_console_timestamps);
 static uint32_t __initdata opt_conring_size;
 size_param("conring_size", opt_conring_size);
 
-#define _CONRING_SIZE 16384
+#define _CONRING_SIZE 65536
 #define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
 static char __initdata _conring[_CONRING_SIZE];
 static char *__read_mostly conring = _conring;
-- 
1.7.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 Dec 02 14:58:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 14: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 1Xvoua-0006PH-1r; Tue, 02 Dec 2014 14:58:44 +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 1XvouY-0006P4-EW
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 14:58:42 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	9F/0F-01660-1A3DD745; Tue, 02 Dec 2014 14:58:41 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417532319!5798605!1
X-Originating-IP: [156.151.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 32386 invoked from network); 2 Dec 2014 14:58:41 -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; 2 Dec 2014 14:58:41 -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 sB2EwX0G022455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 14:58:34 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
	sB2EwXhI002303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 14:58:33 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
	sB2EwWw0003003; Tue, 2 Dec 2014 14:58:32 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 06:58:32 -0800
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Tue,  2 Dec 2014 15:57:54 +0100
Message-Id: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.7.10.4
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>, jbeulich@suse.com
Subject: [Xen-devel] [PATCH for-xen-4.5] console: increase initial conring
	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>
MIME-Version: 1.0
Content-Type: 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 general initial conring size is sufficient. However, if log
level is increased on platforms which have e.g. huge number
of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
which has more than 200 entries in EFI memory map) then some
of earlier messages in console ring are overwritten. It means
that in case of issues deeper analysis can be hindered. Sadly
conring_size argument does not help because new console buffer
is allocated late on heap. It means that it is not possible to
allocate larger ring earlier. So, in this situation initial
conring size should be increased. My experiments showed that
even on not so big machines more than 26 KiB of free space are
needed for initial messages. In theory we could increase conring
size buffer to 32 KiB. However, I think that this value could be
too small for huge machines with large number of ACPI tables and
EFI memory regions. Hence, this patch increases initial conring
size to 64 KiB.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/drivers/char/console.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 2f03259..429d296 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -67,7 +67,7 @@ custom_param("console_timestamps", parse_console_timestamps);
 static uint32_t __initdata opt_conring_size;
 size_param("conring_size", opt_conring_size);
 
-#define _CONRING_SIZE 16384
+#define _CONRING_SIZE 65536
 #define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
 static char __initdata _conring[_CONRING_SIZE];
 static char *__read_mostly conring = _conring;
-- 
1.7.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 Dec 02 15:00:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvovk-0006Wp-M6; Tue, 02 Dec 2014 14:59:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xvovj-0006Wj-C8
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 14:59:55 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	23/AF-27623-AE3DD745; Tue, 02 Dec 2014 14:59:54 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417532392!15333849!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 29074 invoked from network); 2 Dec 2014 14:59:54 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 14:59:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417532394; x=1449068394;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=GzY1nOvLYUQUhycGNxKCbSK16i2BE7TsMI2DQRJdLzI=;
	b=PcGaVgMatYgvjdxUPTvBj1en8g26/Ct/+vAdbGAVeX0NZ5GJGI5CCaUt
	D9VL6jihNyuUCwqX/WtMGzz76Mq3+nZTET2HPu+GNvLXOW3Pk74OOgwyy
	/fPmSvsf0VNiy7bBYyxZyhgO5vac7xIfviEDNSWpOED25TBeyWGQrobiL M=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 02 Dec 2014 14:59:51 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="883503805"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.109.253])
	by fldsmtpi03.verizon.com with ESMTP; 02 Dec 2014 14:59:49 +0000
Message-ID: <547DD3E5.9090303@terremark.com>
Date: Tue, 02 Dec 2014 09:59:49 -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: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.com>
	<alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.6] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/14 09:26, Stefano Stabellini wrote:
> On Tue, 2 Dec 2014, Don Slutz wrote:
>> On 12/02/14 06:53, Stefano Stabellini wrote:
>>> 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>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - call libxl_domain_info instead of libxl_dominfo_init;
>>> - call libxl_domain_info before retry_transaction.
>>>
>>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>>> index de23fec..569a32a 100644
>>> --- a/tools/libxl/libxl.c
>>> +++ b/tools/libxl/libxl.c
>>> @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
>>> domid,
>>>        char *uuid;
>>>        xs_transaction_t t;
>>>    +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
>>> +        goto out_no_transaction;
>>> +
>>>    retry_transaction:
>>>        t = xs_transaction_start(ctx->xsh);
>>>    @@ -4767,10 +4770,9 @@ 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);
>>> +    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 "
>> You need to remove LIBXL_MAXMEM_CONSTANT here also.
> I don't think so: LIBXL_MAXMEM_CONSTANT is supposed to be a safety
> buffer and we should keep it as is across libxl_set_memory_target calls.
> Arguably LIBXL_MAXMEM_CONSTANT could be removed entirely with the
> proposed QEMU changes but that is a separate matter.
>

I was talking about the line:

                     "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, 
rc);

(which is missing from the diff but is part of the LIBXL__LOG_ERRNO 
call).  The
error message no longer matches what  xc_domain_setmaxmem() was called
with.

    -Don Slutz

>   
>>> @@ -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 Dec 02 15:00:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvovk-0006Wp-M6; Tue, 02 Dec 2014 14:59:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1Xvovj-0006Wj-C8
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 14:59:55 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	23/AF-27623-AE3DD745; Tue, 02 Dec 2014 14:59:54 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417532392!15333849!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 29074 invoked from network); 2 Dec 2014 14:59:54 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 14:59:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417532394; x=1449068394;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=GzY1nOvLYUQUhycGNxKCbSK16i2BE7TsMI2DQRJdLzI=;
	b=PcGaVgMatYgvjdxUPTvBj1en8g26/Ct/+vAdbGAVeX0NZ5GJGI5CCaUt
	D9VL6jihNyuUCwqX/WtMGzz76Mq3+nZTET2HPu+GNvLXOW3Pk74OOgwyy
	/fPmSvsf0VNiy7bBYyxZyhgO5vac7xIfviEDNSWpOED25TBeyWGQrobiL M=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 02 Dec 2014 14:59:51 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="883503805"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.109.253])
	by fldsmtpi03.verizon.com with ESMTP; 02 Dec 2014 14:59:49 +0000
Message-ID: <547DD3E5.9090303@terremark.com>
Date: Tue, 02 Dec 2014 09:59:49 -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: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.com>
	<alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.6] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/14 09:26, Stefano Stabellini wrote:
> On Tue, 2 Dec 2014, Don Slutz wrote:
>> On 12/02/14 06:53, Stefano Stabellini wrote:
>>> 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>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - call libxl_domain_info instead of libxl_dominfo_init;
>>> - call libxl_domain_info before retry_transaction.
>>>
>>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>>> index de23fec..569a32a 100644
>>> --- a/tools/libxl/libxl.c
>>> +++ b/tools/libxl/libxl.c
>>> @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
>>> domid,
>>>        char *uuid;
>>>        xs_transaction_t t;
>>>    +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
>>> +        goto out_no_transaction;
>>> +
>>>    retry_transaction:
>>>        t = xs_transaction_start(ctx->xsh);
>>>    @@ -4767,10 +4770,9 @@ 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);
>>> +    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 "
>> You need to remove LIBXL_MAXMEM_CONSTANT here also.
> I don't think so: LIBXL_MAXMEM_CONSTANT is supposed to be a safety
> buffer and we should keep it as is across libxl_set_memory_target calls.
> Arguably LIBXL_MAXMEM_CONSTANT could be removed entirely with the
> proposed QEMU changes but that is a separate matter.
>

I was talking about the line:

                     "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, 
rc);

(which is missing from the diff but is part of the LIBXL__LOG_ERRNO 
call).  The
error message no longer matches what  xc_domain_setmaxmem() was called
with.

    -Don Slutz

>   
>>> @@ -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 Dec 02 15:04:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp01-0006pD-Co; Tue, 02 Dec 2014 15:04:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xvozz-0006p8-Fs
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:04:19 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	0D/3A-22777-2F4DD745; Tue, 02 Dec 2014 15:04:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417532656!5800389!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 13737 invoked from network); 2 Dec 2014 15:04: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;
	2 Dec 2014 15:04:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198883338"
Message-ID: <547DD4A8.2010002@citrix.com>
Date: Tue, 2 Dec 2014 15:03:04 +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 Kiper <daniel.kiper@oracle.com>, <xen-devel@lists.xenproject.org>
References: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
X-DLP: MIA1
Cc: keir@xen.org, ian.campbell@citrix.com, jbeulich@suse.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] console: increase initial
 conring 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 02/12/14 14:57, Daniel Kiper wrote:
> In general initial conring size is sufficient. However, if log
> level is increased on platforms which have e.g. huge number
> of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
> which has more than 200 entries in EFI memory map) then some
> of earlier messages in console ring are overwritten. It means
> that in case of issues deeper analysis can be hindered. Sadly
> conring_size argument does not help because new console buffer
> is allocated late on heap. It means that it is not possible to
> allocate larger ring earlier. So, in this situation initial
> conring size should be increased. My experiments showed that
> even on not so big machines more than 26 KiB of free space are
> needed for initial messages. In theory we could increase conring
> size buffer to 32 KiB. However, I think that this value could be
> too small for huge machines with large number of ACPI tables and
> EFI memory regions. Hence, this patch increases initial conring
> size to 64 KiB.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

For what it is worth, XenServer has been been using a 64k default
console size for a very long time now.

However, a change line this must include a change to
docs/misc/xen-command-line.markdown

~Andrew

> ---
>  xen/drivers/char/console.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 2f03259..429d296 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -67,7 +67,7 @@ custom_param("console_timestamps", parse_console_timestamps);
>  static uint32_t __initdata opt_conring_size;
>  size_param("conring_size", opt_conring_size);
>  
> -#define _CONRING_SIZE 16384
> +#define _CONRING_SIZE 65536
>  #define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
>  static char __initdata _conring[_CONRING_SIZE];
>  static char *__read_mostly conring = _conring;


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:04:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp01-0006pD-Co; Tue, 02 Dec 2014 15:04:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xvozz-0006p8-Fs
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:04:19 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	0D/3A-22777-2F4DD745; Tue, 02 Dec 2014 15:04:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417532656!5800389!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 13737 invoked from network); 2 Dec 2014 15:04: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;
	2 Dec 2014 15:04:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198883338"
Message-ID: <547DD4A8.2010002@citrix.com>
Date: Tue, 2 Dec 2014 15:03:04 +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 Kiper <daniel.kiper@oracle.com>, <xen-devel@lists.xenproject.org>
References: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
X-DLP: MIA1
Cc: keir@xen.org, ian.campbell@citrix.com, jbeulich@suse.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] console: increase initial
 conring 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 02/12/14 14:57, Daniel Kiper wrote:
> In general initial conring size is sufficient. However, if log
> level is increased on platforms which have e.g. huge number
> of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
> which has more than 200 entries in EFI memory map) then some
> of earlier messages in console ring are overwritten. It means
> that in case of issues deeper analysis can be hindered. Sadly
> conring_size argument does not help because new console buffer
> is allocated late on heap. It means that it is not possible to
> allocate larger ring earlier. So, in this situation initial
> conring size should be increased. My experiments showed that
> even on not so big machines more than 26 KiB of free space are
> needed for initial messages. In theory we could increase conring
> size buffer to 32 KiB. However, I think that this value could be
> too small for huge machines with large number of ACPI tables and
> EFI memory regions. Hence, this patch increases initial conring
> size to 64 KiB.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

For what it is worth, XenServer has been been using a 64k default
console size for a very long time now.

However, a change line this must include a change to
docs/misc/xen-command-line.markdown

~Andrew

> ---
>  xen/drivers/char/console.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 2f03259..429d296 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -67,7 +67,7 @@ custom_param("console_timestamps", parse_console_timestamps);
>  static uint32_t __initdata opt_conring_size;
>  size_param("conring_size", opt_conring_size);
>  
> -#define _CONRING_SIZE 16384
> +#define _CONRING_SIZE 65536
>  #define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
>  static char __initdata _conring[_CONRING_SIZE];
>  static char *__read_mostly conring = _conring;


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:05:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp16-0006sy-Qs; Tue, 02 Dec 2014 15:05:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xvp14-0006ss-Od
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:05:26 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	A2/F5-05632-635DD745; Tue, 02 Dec 2014 15:05:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417532723!15357080!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11609 invoked from network); 2 Dec 2014 15:05:25 -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; 2 Dec 2014 15: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 sB2F5GEH032236
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:05:16 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
	sB2F5EVw001465
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:05:15 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
	sB2F5ERK017906; Tue, 2 Dec 2014 15:05:14 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:05:14 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8BE1411ADE2; Tue,  2 Dec 2014 10:05:14 -0500 (EST)
Date: Tue, 2 Dec 2014 10:05:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141202150514.GC27869@laptop.dumpdata.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
	<547D9E13020000780004C0B3@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547D9E13020000780004C0B3@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: bhelgaas@google.com, linux@eikelenboom.it, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 10:10:11AM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 23:17, <konrad.wilk@oracle.com> wrote:
> > 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.
> 
> So my "xen-pciback: drop SR-IOV VFs when PF driver unloads" isn't
> among them, nor is there any alternative. What's the status of that
> patch (or the problem that prompted its creation)?

Oh, I've it in my queue. Um, here is what I did to it - I hadn't
yet tested it - hence the reason it is not on that list.


>From 82ad7b4cc73f2f9a9cfd6805cff996fd5009a31f Mon Sep 17 00:00:00 2001
From: Jan Beulich <JBeulich@suse.com>
Date: Thu, 6 Nov 2014 15:05:51 +0000
Subject: [PATCH 1/2] 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]
[v3: Redid it a bit differently]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 54 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index eb8b58e..ff27efa 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -1518,6 +1518,53 @@ parse_error:
 fs_initcall(pcistub_init);
 #endif
 
+#ifdef CONFIG_PCI_IOV
+static struct pcistub_device *find_vfs(const struct pci_dev *pdev)
+{
+	struct pcistub_device *psdev = NULL;
+	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)
+		return psdev;
+	return NULL;
+}
+
+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);
+
+	if (action != BUS_NOTIFY_UNBIND_DRIVER)
+		return NOTIFY_DONE;
+
+	if (!pdev->is_physfn)
+		return NOTIFY_DONE;
+
+	for (;;) {
+		struct pcistub_device *psdev = find_vfs(pdev);
+		if (!psdev)
+			break;
+		device_release_driver(&psdev->dev->dev);
+	}
+	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;
@@ -1539,12 +1586,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

> 
> Jan
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:05:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp16-0006sy-Qs; Tue, 02 Dec 2014 15:05:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xvp14-0006ss-Od
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:05:26 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	A2/F5-05632-635DD745; Tue, 02 Dec 2014 15:05:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417532723!15357080!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11609 invoked from network); 2 Dec 2014 15:05:25 -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; 2 Dec 2014 15: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 sB2F5GEH032236
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:05:16 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
	sB2F5EVw001465
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:05:15 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
	sB2F5ERK017906; Tue, 2 Dec 2014 15:05:14 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:05:14 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8BE1411ADE2; Tue,  2 Dec 2014 10:05:14 -0500 (EST)
Date: Tue, 2 Dec 2014 10:05:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141202150514.GC27869@laptop.dumpdata.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
	<547D9E13020000780004C0B3@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547D9E13020000780004C0B3@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: bhelgaas@google.com, linux@eikelenboom.it, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 10:10:11AM +0000, Jan Beulich wrote:
> >>> On 21.11.14 at 23:17, <konrad.wilk@oracle.com> wrote:
> > 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.
> 
> So my "xen-pciback: drop SR-IOV VFs when PF driver unloads" isn't
> among them, nor is there any alternative. What's the status of that
> patch (or the problem that prompted its creation)?

Oh, I've it in my queue. Um, here is what I did to it - I hadn't
yet tested it - hence the reason it is not on that list.


>From 82ad7b4cc73f2f9a9cfd6805cff996fd5009a31f Mon Sep 17 00:00:00 2001
From: Jan Beulich <JBeulich@suse.com>
Date: Thu, 6 Nov 2014 15:05:51 +0000
Subject: [PATCH 1/2] 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]
[v3: Redid it a bit differently]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 54 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index eb8b58e..ff27efa 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -1518,6 +1518,53 @@ parse_error:
 fs_initcall(pcistub_init);
 #endif
 
+#ifdef CONFIG_PCI_IOV
+static struct pcistub_device *find_vfs(const struct pci_dev *pdev)
+{
+	struct pcistub_device *psdev = NULL;
+	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)
+		return psdev;
+	return NULL;
+}
+
+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);
+
+	if (action != BUS_NOTIFY_UNBIND_DRIVER)
+		return NOTIFY_DONE;
+
+	if (!pdev->is_physfn)
+		return NOTIFY_DONE;
+
+	for (;;) {
+		struct pcistub_device *psdev = find_vfs(pdev);
+		if (!psdev)
+			break;
+		device_release_driver(&psdev->dev->dev);
+	}
+	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;
@@ -1539,12 +1586,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

> 
> Jan
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:06:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp1g-0006wc-A6; Tue, 02 Dec 2014 15:06:04 +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 1Xvp1f-0006wM-1n
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:06:03 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	EC/71-29352-A55DD745; Tue, 02 Dec 2014 15:06:02 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417532759!11074222!1
X-Originating-IP: [66.165.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 25833 invoked from network); 2 Dec 2014 15:06:01 -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;
	2 Dec 2014 15:06:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198551084"
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, 2 Dec 2014 10:04: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 1Xvozx-0002aK-QT;
	Tue, 02 Dec 2014 15:04:17 +0000
Date: Tue, 2 Dec 2014 15:04:06 +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: <547DD3E5.9090303@terremark.com>
Message-ID: <alpine.DEB.2.02.1412021503500.17262@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.com>
	<alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
	<547DD3E5.9090303@terremark.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>, 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: Re: [Xen-devel] [PATCH v2 for-4.6] 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

On Tue, 2 Dec 2014, Don Slutz wrote:
> On 12/02/14 09:26, Stefano Stabellini wrote:
> > On Tue, 2 Dec 2014, Don Slutz wrote:
> > > On 12/02/14 06:53, Stefano Stabellini wrote:
> > > > 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>
> > > > 
> > > > ---
> > > > 
> > > > Changes in v2:
> > > > - call libxl_domain_info instead of libxl_dominfo_init;
> > > > - call libxl_domain_info before retry_transaction.
> > > > 
> > > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > > index de23fec..569a32a 100644
> > > > --- a/tools/libxl/libxl.c
> > > > +++ b/tools/libxl/libxl.c
> > > > @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx,
> > > > uint32_t
> > > > domid,
> > > >        char *uuid;
> > > >        xs_transaction_t t;
> > > >    +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
> > > > +        goto out_no_transaction;
> > > > +
> > > >    retry_transaction:
> > > >        t = xs_transaction_start(ctx->xsh);
> > > >    @@ -4767,10 +4770,9 @@ 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);
> > > > +    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 "
> > > You need to remove LIBXL_MAXMEM_CONSTANT here also.
> > I don't think so: LIBXL_MAXMEM_CONSTANT is supposed to be a safety
> > buffer and we should keep it as is across libxl_set_memory_target calls.
> > Arguably LIBXL_MAXMEM_CONSTANT could be removed entirely with the
> > proposed QEMU changes but that is a separate matter.
> > 
> 
> I was talking about the line:
> 
>                     "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
> 
> (which is missing from the diff but is part of the LIBXL__LOG_ERRNO call).
> The
> error message no longer matches what  xc_domain_setmaxmem() was called
> with.

Yep, you are right, I'll fix.




> >   
> > > > @@ -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 Dec 02 15:06:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp1g-0006wc-A6; Tue, 02 Dec 2014 15:06:04 +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 1Xvp1f-0006wM-1n
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:06:03 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	EC/71-29352-A55DD745; Tue, 02 Dec 2014 15:06:02 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417532759!11074222!1
X-Originating-IP: [66.165.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 25833 invoked from network); 2 Dec 2014 15:06:01 -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;
	2 Dec 2014 15:06:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198551084"
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, 2 Dec 2014 10:04: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 1Xvozx-0002aK-QT;
	Tue, 02 Dec 2014 15:04:17 +0000
Date: Tue, 2 Dec 2014 15:04:06 +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: <547DD3E5.9090303@terremark.com>
Message-ID: <alpine.DEB.2.02.1412021503500.17262@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.com>
	<alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
	<547DD3E5.9090303@terremark.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>, 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: Re: [Xen-devel] [PATCH v2 for-4.6] 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

On Tue, 2 Dec 2014, Don Slutz wrote:
> On 12/02/14 09:26, Stefano Stabellini wrote:
> > On Tue, 2 Dec 2014, Don Slutz wrote:
> > > On 12/02/14 06:53, Stefano Stabellini wrote:
> > > > 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>
> > > > 
> > > > ---
> > > > 
> > > > Changes in v2:
> > > > - call libxl_domain_info instead of libxl_dominfo_init;
> > > > - call libxl_domain_info before retry_transaction.
> > > > 
> > > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > > index de23fec..569a32a 100644
> > > > --- a/tools/libxl/libxl.c
> > > > +++ b/tools/libxl/libxl.c
> > > > @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx,
> > > > uint32_t
> > > > domid,
> > > >        char *uuid;
> > > >        xs_transaction_t t;
> > > >    +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
> > > > +        goto out_no_transaction;
> > > > +
> > > >    retry_transaction:
> > > >        t = xs_transaction_start(ctx->xsh);
> > > >    @@ -4767,10 +4770,9 @@ 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);
> > > > +    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 "
> > > You need to remove LIBXL_MAXMEM_CONSTANT here also.
> > I don't think so: LIBXL_MAXMEM_CONSTANT is supposed to be a safety
> > buffer and we should keep it as is across libxl_set_memory_target calls.
> > Arguably LIBXL_MAXMEM_CONSTANT could be removed entirely with the
> > proposed QEMU changes but that is a separate matter.
> > 
> 
> I was talking about the line:
> 
>                     "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
> 
> (which is missing from the diff but is part of the LIBXL__LOG_ERRNO call).
> The
> error message no longer matches what  xc_domain_setmaxmem() was called
> with.

Yep, you are right, I'll fix.




> >   
> > > > @@ -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 Dec 02 15:08:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:08:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp3V-00079c-Vm; Tue, 02 Dec 2014 15:07:57 +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 1Xvp3U-00079R-Cz
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:07:56 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	7E/48-08051-BC5DD745; Tue, 02 Dec 2014 15:07:55 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417532873!12475482!1
X-Originating-IP: [156.151.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 30592 invoked from network); 2 Dec 2014 15:07:54 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:07:54 -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 sB2F7jvw003196
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:07:46 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
	sB2F7iCx015307
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:07:45 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
	sB2F7iBA028741; Tue, 2 Dec 2014 15:07:44 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, 02 Dec 2014 07:07:44 -0800
Message-ID: <547DD626.3070600@oracle.com>
Date: Tue, 02 Dec 2014 10:09:26 -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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
	<1417527800.24320.29.camel@citrix.com>
In-Reply-To: <1417527800.24320.29.camel@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>, xen-devel@lists.xensource.com,
	Ian Jackson <ian.jackson@eu.citrix.com>, linux@eikelenboom.it
Subject: Re: [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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 08:43 AM, Ian Campbell wrote:
> On Fri, 2014-11-28 at 16:53 +0000, Stefano Stabellini wrote:
>
> CCing Boris because he was fixing a similar sounding issue in the same
> area. Not sure if this is related to those patches or not.

Not really. I was trying to fix something that another Stefano's patch 
from yesterday is trying to address:

http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00160.html

although I thought that removing the call to xc_domain_irq_permission() 
would be the solution.

(which reminds me --- and maybe I shouldn't overload this thread --- 
that this patch from IanJ needs to get in as well:

http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg01342.html

)

Thanks.
-boris


>
>> 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.
> ISTR seeing a conversation along the lines of there being a better
> solution which was more 4.6 material, is that right?
>
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> But, I'd prefer to see a version which logs when the qemu side has
> failed but it is continuing. Probably just adding right after the
> existing if:
>          if (rc)
>              LOG("Something appropriate");
> would do the trick.
>
> Also this needs RM input from Konrad.
>
>> 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 Tue Dec 02 15:08:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:08:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp3V-00079c-Vm; Tue, 02 Dec 2014 15:07:57 +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 1Xvp3U-00079R-Cz
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:07:56 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	7E/48-08051-BC5DD745; Tue, 02 Dec 2014 15:07:55 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417532873!12475482!1
X-Originating-IP: [156.151.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 30592 invoked from network); 2 Dec 2014 15:07:54 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:07:54 -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 sB2F7jvw003196
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:07:46 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
	sB2F7iCx015307
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:07:45 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
	sB2F7iBA028741; Tue, 2 Dec 2014 15:07:44 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, 02 Dec 2014 07:07:44 -0800
Message-ID: <547DD626.3070600@oracle.com>
Date: Tue, 02 Dec 2014 10:09:26 -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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
	<1417527800.24320.29.camel@citrix.com>
In-Reply-To: <1417527800.24320.29.camel@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>, xen-devel@lists.xensource.com,
	Ian Jackson <ian.jackson@eu.citrix.com>, linux@eikelenboom.it
Subject: Re: [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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 08:43 AM, Ian Campbell wrote:
> On Fri, 2014-11-28 at 16:53 +0000, Stefano Stabellini wrote:
>
> CCing Boris because he was fixing a similar sounding issue in the same
> area. Not sure if this is related to those patches or not.

Not really. I was trying to fix something that another Stefano's patch 
from yesterday is trying to address:

http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00160.html

although I thought that removing the call to xc_domain_irq_permission() 
would be the solution.

(which reminds me --- and maybe I shouldn't overload this thread --- 
that this patch from IanJ needs to get in as well:

http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg01342.html

)

Thanks.
-boris


>
>> 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.
> ISTR seeing a conversation along the lines of there being a better
> solution which was more 4.6 material, is that right?
>
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> But, I'd prefer to see a version which logs when the qemu side has
> failed but it is continuing. Probably just adding right after the
> existing if:
>          if (rc)
>              LOG("Something appropriate");
> would do the trick.
>
> Also this needs RM input from Konrad.
>
>> 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 Tue Dec 02 15:09:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1Xvp5E-0007JZ-Fx; Tue, 02 Dec 2014 15:09:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xvp5C-0007JM-Fb
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:09:42 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	8D/0A-24124-536DD745; Tue, 02 Dec 2014 15:09:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417532979!11086408!1
X-Originating-IP: [156.151.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 10580 invoked from network); 2 Dec 2014 15:09:41 -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; 2 Dec 2014 15:09: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 sB2F9Y5i005812
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:09:34 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
	sB2F9XN2018803
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:09:34 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
	sB2F9XgO018743; Tue, 2 Dec 2014 15:09:33 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:09:32 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 760E111ADEF; Tue,  2 Dec 2014 10:09:33 -0500 (EST)
Date: Tue, 2 Dec 2014 10:09:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202150933.GE27869@laptop.dumpdata.com>
References: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417174284.23604.9.camel@citrix.com>
	<20141201203001.GE21626@laptop.dumpdata.com>
	<547D276C.2070805@citrix.com>
	<1417528978.24320.42.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417528978.24320.42.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>,
	Boris Ostrovsky <boris.ostrovsky@oracle.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, Dec 02, 2014 at 02:02:58PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 02:43 +0000, Andrew Cooper wrote:
> > On 01/12/2014 20:30, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 28, 2014 at 11:31:24AM +0000, Ian Campbell wrote:
> > >> 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.
> > > I am bit lost. I thought Andrew NACKed this?
> > 
> > I didn't, as I am not in a position to.  I have not tested the result,
> > but believe it is sufficient to fix the exact error at hand.  If the
> > maintainers think it is the best solution then so be it, but I am still
> > of the opinion that it is is still a hack upon a hack.
> 
> At this point in a freeze I'm much happier with:
> 
>  tools/pygrub/src/pygrub |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)

The same here. This is now the season of handing out band-aids.

As such Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> than
>  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(-)
> 
> Plus Boris' patch is far easier to reason about in isolation in a
> dynamically/duck typed language.
> 
> Ian.
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:09:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1Xvp5E-0007JZ-Fx; Tue, 02 Dec 2014 15:09:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xvp5C-0007JM-Fb
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:09:42 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	8D/0A-24124-536DD745; Tue, 02 Dec 2014 15:09:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417532979!11086408!1
X-Originating-IP: [156.151.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 10580 invoked from network); 2 Dec 2014 15:09:41 -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; 2 Dec 2014 15:09: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 sB2F9Y5i005812
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:09:34 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
	sB2F9XN2018803
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:09:34 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
	sB2F9XgO018743; Tue, 2 Dec 2014 15:09:33 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:09:32 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 760E111ADEF; Tue,  2 Dec 2014 10:09:33 -0500 (EST)
Date: Tue, 2 Dec 2014 10:09:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202150933.GE27869@laptop.dumpdata.com>
References: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417174284.23604.9.camel@citrix.com>
	<20141201203001.GE21626@laptop.dumpdata.com>
	<547D276C.2070805@citrix.com>
	<1417528978.24320.42.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417528978.24320.42.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>,
	Boris Ostrovsky <boris.ostrovsky@oracle.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, Dec 02, 2014 at 02:02:58PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 02:43 +0000, Andrew Cooper wrote:
> > On 01/12/2014 20:30, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 28, 2014 at 11:31:24AM +0000, Ian Campbell wrote:
> > >> 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.
> > > I am bit lost. I thought Andrew NACKed this?
> > 
> > I didn't, as I am not in a position to.  I have not tested the result,
> > but believe it is sufficient to fix the exact error at hand.  If the
> > maintainers think it is the best solution then so be it, but I am still
> > of the opinion that it is is still a hack upon a hack.
> 
> At this point in a freeze I'm much happier with:
> 
>  tools/pygrub/src/pygrub |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)

The same here. This is now the season of handing out band-aids.

As such Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> than
>  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(-)
> 
> Plus Boris' patch is far easier to reason about in isolation in a
> dynamically/duck typed language.
> 
> Ian.
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:10:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1Xvp5Z-0007Mo-2v; Tue, 02 Dec 2014 15:10: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 1Xvp5X-0007MZ-Qo
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:10:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	82/E9-25276-A46DD745; Tue, 02 Dec 2014 15:10:02 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417533002!12863565!1
X-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 457 invoked from network); 2 Dec 2014 15:10:02 -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; 2 Dec 2014 15:10:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 15:10:01 +0000
Message-Id: <547DD64602000078000C2DC0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 15:09:58 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
	<547D9E13020000780004C0B3@mail.emea.novell.com>
	<20141202150514.GC27869@laptop.dumpdata.com>
In-Reply-To: <20141202150514.GC27869@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: bhelgaas@google.com, linux@eikelenboom.it, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [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>
Content-Type: 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 <konrad.wilk@oracle.com> 12/02/14 4:05 PM >>>
>On Tue, Dec 02, 2014 at 10:10:11AM +0000, Jan Beulich wrote:
>> >>> On 21.11.14 at 23:17, <konrad.wilk@oracle.com> wrote:
>> > 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.
>> 
>> So my "xen-pciback: drop SR-IOV VFs when PF driver unloads" isn't
>> among them, nor is there any alternative. What's the status of that
>> patch (or the problem that prompted its creation)?
>
>Oh, I've it in my queue. Um, here is what I did to it - I hadn't
>yet tested it - hence the reason it is not on that list.

Yeah, if you like it better that way, it looks okay to me now.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:10:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1Xvp5Z-0007Mo-2v; Tue, 02 Dec 2014 15:10: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 1Xvp5X-0007MZ-Qo
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:10:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	82/E9-25276-A46DD745; Tue, 02 Dec 2014 15:10:02 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417533002!12863565!1
X-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 457 invoked from network); 2 Dec 2014 15:10:02 -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; 2 Dec 2014 15:10:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 15:10:01 +0000
Message-Id: <547DD64602000078000C2DC0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 15:09:58 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <konrad.wilk@oracle.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
	<547D9E13020000780004C0B3@mail.emea.novell.com>
	<20141202150514.GC27869@laptop.dumpdata.com>
In-Reply-To: <20141202150514.GC27869@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: bhelgaas@google.com, linux@eikelenboom.it, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [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>
Content-Type: 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 <konrad.wilk@oracle.com> 12/02/14 4:05 PM >>>
>On Tue, Dec 02, 2014 at 10:10:11AM +0000, Jan Beulich wrote:
>> >>> On 21.11.14 at 23:17, <konrad.wilk@oracle.com> wrote:
>> > 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.
>> 
>> So my "xen-pciback: drop SR-IOV VFs when PF driver unloads" isn't
>> among them, nor is there any alternative. What's the status of that
>> patch (or the problem that prompted its creation)?
>
>Oh, I've it in my queue. Um, here is what I did to it - I hadn't
>yet tested it - hence the reason it is not on that list.

Yeah, if you like it better that way, it looks okay to me now.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:10:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp5s-0007R5-Gp; Tue, 02 Dec 2014 15:10:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xvp5r-0007Qo-Lr
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:10:23 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	86/58-02696-E56DD745; Tue, 02 Dec 2014 15:10:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417533019!12479962!1
X-Originating-IP: [156.151.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 24895 invoked from network); 2 Dec 2014 15:10:21 -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; 2 Dec 2014 15:10:21 -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 sB2FAIH6007006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:10: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
	sB2FAHl2026373
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:10:17 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
	sB2FAGDW022351; Tue, 2 Dec 2014 15:10:16 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:10:16 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5CEF711ADFB; Tue,  2 Dec 2014 10:10:17 -0500 (EST)
Date: Tue, 2 Dec 2014 10:10:17 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141202151017.GF27869@laptop.dumpdata.com>
References: <547D88EF.4050206@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547D88EF.4050206@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" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 10:39:59AM +0100, Juergen Gross wrote:
> Hi,
> 
> looking into the upstream linux sources I realized that the PVHVM
> drivers of XEN are only available with the pvops kernel. Is this on
> purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
> configurable without having to enable CONFIG_PARAVIRT?

Yes. For example on non-PAE kernels
> 
> 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 Dec 02 15:10:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp5s-0007R5-Gp; Tue, 02 Dec 2014 15:10:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xvp5r-0007Qo-Lr
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:10:23 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	86/58-02696-E56DD745; Tue, 02 Dec 2014 15:10:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417533019!12479962!1
X-Originating-IP: [156.151.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 24895 invoked from network); 2 Dec 2014 15:10:21 -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; 2 Dec 2014 15:10:21 -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 sB2FAIH6007006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:10: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
	sB2FAHl2026373
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:10:17 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
	sB2FAGDW022351; Tue, 2 Dec 2014 15:10:16 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:10:16 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5CEF711ADFB; Tue,  2 Dec 2014 10:10:17 -0500 (EST)
Date: Tue, 2 Dec 2014 10:10:17 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141202151017.GF27869@laptop.dumpdata.com>
References: <547D88EF.4050206@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547D88EF.4050206@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" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 10:39:59AM +0100, Juergen Gross wrote:
> Hi,
> 
> looking into the upstream linux sources I realized that the PVHVM
> drivers of XEN are only available with the pvops kernel. Is this on
> purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
> configurable without having to enable CONFIG_PARAVIRT?

Yes. For example on non-PAE kernels
> 
> 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 Dec 02 15:10:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:10:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp61-0007Ti-13; Tue, 02 Dec 2014 15:10: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 1Xvp5y-0007Sx-Tn
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:10:31 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	40/2B-25276-666DD745; Tue, 02 Dec 2014 15:10:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417533029!12873910!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13303 invoked from network); 2 Dec 2014 15:10:29 -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;
	2 Dec 2014 15:10:29 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so21331095wid.0
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 07:10:29 -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=jobtqFeWZwDGNhs1Dk1XPcO9oVJssVzHPYRxeQkLrk4=;
	b=omTjNAbIGEgEW0x2XnF7PwI2nNB4sInHXfmQq4t6BzvMIdW2uK9k4X+9QFcV9njk6b
	MuQgA9PkXiLcBm5ivUWGfDnpQ1Aepf2JFc4dZbL740ZTYASObA0KIyBeEGKT2dXeyKpJ
	lx1wipg87q2RBBYT6veycZdRzI6xSfwHvBhZyGJC/vcktZ9/e/D+ZYJu+ClK219YIEQR
	86yFQyBDipQcAFs1UvKi4ZsRnJn+rj467e3aSZLqTX58XK3BFQaPwk+LMlnMKOr9mEzc
	IHN+TIk+l62qBSx5do8OqmsjDRK2FeIJIeiYkvUEJjCOTY9jA5G6pm3xzxuHXVcLA8gB
	FH9Q==
MIME-Version: 1.0
X-Received: by 10.180.76.211 with SMTP id m19mr5994640wiw.73.1417533029525;
	Tue, 02 Dec 2014 07:10:29 -0800 (PST)
Received: by 10.194.44.2 with HTTP; Tue, 2 Dec 2014 07:10:29 -0800 (PST)
In-Reply-To: <201411271512.sARFC11l001276@userz7022.oracle.com>
References: <201411271512.sARFC11l001276@userz7022.oracle.com>
Date: Tue, 2 Dec 2014 15:10:29 +0000
X-Google-Sender-Auth: SCk4oPX_OHdofCMqIZhOlrZ96xU
Message-ID: <CAFLBxZZKBf70oH7yUC9JDU7U3Ca5SAt6vWcNfnMy566KEPQS4w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tim Deegan <tim@xen.org>,
	"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, Nov 27, 2014 at 3:11 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>
> On Nov 27, 2014 6:59 AM, Tim Deegan <tim@xen.org> wrote:
>>
>> 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
>
> +1 too.

OK, that's +4 and no minuses after 5 days.  How long to I have to wait?  :-)

 -George

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:10:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:10:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp61-0007Ti-13; Tue, 02 Dec 2014 15:10: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 1Xvp5y-0007Sx-Tn
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:10:31 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	40/2B-25276-666DD745; Tue, 02 Dec 2014 15:10:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417533029!12873910!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13303 invoked from network); 2 Dec 2014 15:10:29 -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;
	2 Dec 2014 15:10:29 -0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so21331095wid.0
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 07:10:29 -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=jobtqFeWZwDGNhs1Dk1XPcO9oVJssVzHPYRxeQkLrk4=;
	b=omTjNAbIGEgEW0x2XnF7PwI2nNB4sInHXfmQq4t6BzvMIdW2uK9k4X+9QFcV9njk6b
	MuQgA9PkXiLcBm5ivUWGfDnpQ1Aepf2JFc4dZbL740ZTYASObA0KIyBeEGKT2dXeyKpJ
	lx1wipg87q2RBBYT6veycZdRzI6xSfwHvBhZyGJC/vcktZ9/e/D+ZYJu+ClK219YIEQR
	86yFQyBDipQcAFs1UvKi4ZsRnJn+rj467e3aSZLqTX58XK3BFQaPwk+LMlnMKOr9mEzc
	IHN+TIk+l62qBSx5do8OqmsjDRK2FeIJIeiYkvUEJjCOTY9jA5G6pm3xzxuHXVcLA8gB
	FH9Q==
MIME-Version: 1.0
X-Received: by 10.180.76.211 with SMTP id m19mr5994640wiw.73.1417533029525;
	Tue, 02 Dec 2014 07:10:29 -0800 (PST)
Received: by 10.194.44.2 with HTTP; Tue, 2 Dec 2014 07:10:29 -0800 (PST)
In-Reply-To: <201411271512.sARFC11l001276@userz7022.oracle.com>
References: <201411271512.sARFC11l001276@userz7022.oracle.com>
Date: Tue, 2 Dec 2014 15:10:29 +0000
X-Google-Sender-Auth: SCk4oPX_OHdofCMqIZhOlrZ96xU
Message-ID: <CAFLBxZZKBf70oH7yUC9JDU7U3Ca5SAt6vWcNfnMy566KEPQS4w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tim Deegan <tim@xen.org>,
	"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, Nov 27, 2014 at 3:11 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>
> On Nov 27, 2014 6:59 AM, Tim Deegan <tim@xen.org> wrote:
>>
>> 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
>
> +1 too.

OK, that's +4 and no minuses after 5 days.  How long to I have to wait?  :-)

 -George

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:11:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp6b-0007cp-Fw; Tue, 02 Dec 2014 15:11: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 1Xvp6a-0007cY-MK
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:11:08 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	A9/5E-18267-C86DD745; Tue, 02 Dec 2014 15:11:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417533065!15166281!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17290 invoked from network); 2 Dec 2014 15:11:07 -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; 2 Dec 2014 15:11:07 -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 sB2FB27L009657
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:11:02 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
	sB2FB1fE029073
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:11:02 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
	sB2FB1Sh029061; Tue, 2 Dec 2014 15:11:01 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:11:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BADE411ADFE; Tue,  2 Dec 2014 10:11:01 -0500 (EST)
Date: Tue, 2 Dec 2014 10:11:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202151101.GG27869@laptop.dumpdata.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417518314.24320.9.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 11:05:14AM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 10:54 +0000, David Vrabel wrote:
> > On 02/12/14 09:39, Juergen Gross wrote:
> > > Hi,
> > > 
> > > looking into the upstream linux sources I realized that the PVHVM
> > > drivers of XEN are only available with the pvops kernel. Is this on
> > > purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
> > > configurable without having to enable CONFIG_PARAVIRT?
> > 
> > I suppose that would be possible but I don't think it's a useful
> > configuration because you would lose PV spinlocks for example.
> 
> IIRC the reason this hasn't been implemented until now is that
> refactoring would be required to the various bits of driver code which
> assumes PAE + PARAVIRT when they aren't strictly needed, e.g. grant
> table code. Whether its worth the churn at this stage is debatable, but
> I think the (in)ability to use PV spinlocks is a red-herring.
> 
> Adding PV drivers to an HVM guest is a useful thing to do, even without
> PV spinlocks. PV IO gets you far more incremental benefit than the locks
> do, adding PV IO paths is the number 1 thing which should be done to any
> guest.
> 
> One actual usecase is installing from a distro installer which isn't
> PAE, let alone PARAVIRT enabled[0], to get far enough that you can
> install a more capable PVHVM kernel with more bells and whistles.
> 
> If there were distros around who refused wholesale to enable PARAVIRT
> even in a non-default kernel then it would be more likely that they
> could be convinced to enable a set of PV IO drivers, since they have 0
> impact on a non-PARAVIRT system, and still give significant benefit to
> Xen users. I don't know of any of the major distros are refusing
> PARAVIRT in this way though.
> 
> Ian.
> 
> [0] The default i386 Debian installer falls into this camp, but you can
> use the special PV Xen variant to install as PVHVM too so it's not so
> critical.

And the Fedora 21 LiveISO (32-bit) does too.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 02 15:11:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp6b-0007cp-Fw; Tue, 02 Dec 2014 15:11: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 1Xvp6a-0007cY-MK
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:11:08 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	A9/5E-18267-C86DD745; Tue, 02 Dec 2014 15:11:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417533065!15166281!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17290 invoked from network); 2 Dec 2014 15:11:07 -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; 2 Dec 2014 15:11:07 -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 sB2FB27L009657
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:11:02 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
	sB2FB1fE029073
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:11:02 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
	sB2FB1Sh029061; Tue, 2 Dec 2014 15:11:01 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:11:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BADE411ADFE; Tue,  2 Dec 2014 10:11:01 -0500 (EST)
Date: Tue, 2 Dec 2014 10:11:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202151101.GG27869@laptop.dumpdata.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417518314.24320.9.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 11:05:14AM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 10:54 +0000, David Vrabel wrote:
> > On 02/12/14 09:39, Juergen Gross wrote:
> > > Hi,
> > > 
> > > looking into the upstream linux sources I realized that the PVHVM
> > > drivers of XEN are only available with the pvops kernel. Is this on
> > > purpose? Shouldn't the frontend drivers, xen/platform-pci.c etc. be
> > > configurable without having to enable CONFIG_PARAVIRT?
> > 
> > I suppose that would be possible but I don't think it's a useful
> > configuration because you would lose PV spinlocks for example.
> 
> IIRC the reason this hasn't been implemented until now is that
> refactoring would be required to the various bits of driver code which
> assumes PAE + PARAVIRT when they aren't strictly needed, e.g. grant
> table code. Whether its worth the churn at this stage is debatable, but
> I think the (in)ability to use PV spinlocks is a red-herring.
> 
> Adding PV drivers to an HVM guest is a useful thing to do, even without
> PV spinlocks. PV IO gets you far more incremental benefit than the locks
> do, adding PV IO paths is the number 1 thing which should be done to any
> guest.
> 
> One actual usecase is installing from a distro installer which isn't
> PAE, let alone PARAVIRT enabled[0], to get far enough that you can
> install a more capable PVHVM kernel with more bells and whistles.
> 
> If there were distros around who refused wholesale to enable PARAVIRT
> even in a non-default kernel then it would be more likely that they
> could be convinced to enable a set of PV IO drivers, since they have 0
> impact on a non-PARAVIRT system, and still give significant benefit to
> Xen users. I don't know of any of the major distros are refusing
> PARAVIRT in this way though.
> 
> Ian.
> 
> [0] The default i386 Debian installer falls into this camp, but you can
> use the special PV Xen variant to install as PVHVM too so it's not so
> critical.

And the Fedora 21 LiveISO (32-bit) does too.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 02 15:14:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:14:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp9V-00085A-2l; Tue, 02 Dec 2014 15:14:09 +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 1Xvp9T-000851-Vq
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:14:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E0/83-09842-F37DD745; Tue, 02 Dec 2014 15:14:07 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417533246!4863371!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3173 invoked from network); 2 Dec 2014 15:14:06 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:14:06 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417533246; l=289;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=08MseM7T2mqqXpJhUKwVDM3jNGQ=;
	b=Y/6oV0/0nqXW7qKwVnM8JnrNsdK+tQubKINdazYM8amj283J2WW28so5nhOyOVm0R1H
	Mn99/dLRVB/s/lmMgEuBCPZhyfJpolJKGC+nj+1FQ0c/cwSuCpGumoobtoeeEMYzN2GXr
	vWANgh788+IDfAk6yL+O4kXXtj78crTpJRA=
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.2 AUTH) with ESMTPSA id 20598bqB2FDwmnJ
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 16:13:58 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id BAE2D5016D; Tue,  2 Dec 2014 16:13:57 +0100 (CET)
Date: Tue, 2 Dec 2014 16:13:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20141202151357.GA16942@aepfle.de>
References: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	andrew.cooper3@citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] console: increase initial
 conring 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, Dec 02, Daniel Kiper wrote:

> Hence, this patch increases initial conring size to 64 KiB.

Instead of increasing the default it was suggested to dynamically
allocate the buffer very early.

http://lists.xenproject.org/archives/html/xen-devel/2011-07/msg00689.html

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:14:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:14:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvp9V-00085A-2l; Tue, 02 Dec 2014 15:14:09 +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 1Xvp9T-000851-Vq
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:14:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E0/83-09842-F37DD745; Tue, 02 Dec 2014 15:14:07 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417533246!4863371!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3173 invoked from network); 2 Dec 2014 15:14:06 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:14:06 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417533246; l=289;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=08MseM7T2mqqXpJhUKwVDM3jNGQ=;
	b=Y/6oV0/0nqXW7qKwVnM8JnrNsdK+tQubKINdazYM8amj283J2WW28so5nhOyOVm0R1H
	Mn99/dLRVB/s/lmMgEuBCPZhyfJpolJKGC+nj+1FQ0c/cwSuCpGumoobtoeeEMYzN2GXr
	vWANgh788+IDfAk6yL+O4kXXtj78crTpJRA=
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.2 AUTH) with ESMTPSA id 20598bqB2FDwmnJ
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 16:13:58 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id BAE2D5016D; Tue,  2 Dec 2014 16:13:57 +0100 (CET)
Date: Tue, 2 Dec 2014 16:13:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20141202151357.GA16942@aepfle.de>
References: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	andrew.cooper3@citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] console: increase initial
 conring 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, Dec 02, Daniel Kiper wrote:

> Hence, this patch increases initial conring size to 64 KiB.

Instead of increasing the default it was suggested to dynamically
allocate the buffer very early.

http://lists.xenproject.org/archives/html/xen-devel/2011-07/msg00689.html

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:17:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpCY-0008Df-N6; Tue, 02 Dec 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 <olaf@aepfle.de>)
	id 1XvpCW-0008DV-In; Tue, 02 Dec 2014 15:17:16 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	02/17-26652-BF7DD745; Tue, 02 Dec 2014 15:17:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417533433!7746904!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7154 invoked from network); 2 Dec 2014 15:17:13 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2014 15:17:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417533433; l=3106;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=5S42KlYKAILe6Sl/LONoRZXR6vs=;
	b=rz0Tax253KJnTyO+XncxYi81DvQJ9Y7ZHoMJGrr+u9cjlJim795vkUNCNoVYjG7vr4W
	56YxupqKxMGN/7TrRcku1sU5lwUDrzImaG2ZeDCFpqNW2B3w8tUx+Cj1F0fUyY3WDjoRW
	J1r+TmfCMpdmBOZ6dBQwpIsQ4NPac4LMZbg=
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.2 AUTH) with ESMTPSA id J062c0qB2FH9ltK
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 16:17:09 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 1B5E35016D; Tue,  2 Dec 2014 16:17:09 +0100 (CET)
Date: Tue, 2 Dec 2014 16:17:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202151708.GA23112@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417512564.15063.4.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, 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>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Ian Campbell wrote:

> On Mon, 2014-12-01 at 23:41 +0000, Mark Pryor wrote:
> > list,
> 
> Thanks. If you've identified a buggy changeset then it is fine to post
> to the devel lists. I've added a CC. I've also CCd everyone listed in
> the commit which you've fingered.
> 
> Olaf, does this suggested change look correct? If so then can you turn
> it into a patch please.

Yes, something like this (sed -i 's@socket@service@g' *.in):


diff --git a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
index 4d4cb23..3befadc 100644
--- a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
+++ b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=xen-init-dom0, initialise Dom0 configuration (xenstore nodes, JSON configuration stub)
-Requires=xenstored.socket proc-xen.mount
-After=xenstored.socket proc-xen.mount
+Requires=xenstored.service proc-xen.mount
+After=xenstored.service proc-xen.mount
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]
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 6b9c96e..0a5807a 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
@@ -1,7 +1,7 @@
 [Unit]
 Description=qemu for xen dom0 disk backend
-Requires=proc-xen.mount xenstored.socket
-After=proc-xen.mount xenstored.socket xenconsoled.service
+Requires=proc-xen.mount xenstored.service
+After=proc-xen.mount xenstored.service xenconsoled.service
 Before=xendomains.service libvirtd.service libvirt-guests.service
 RefuseManualStop=true
 ConditionPathExists=/proc/xen/capabilities
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index 2c5d99f..cb44cd6 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=Xenconsoled - handles logging from guest consoles and hypervisor
-Requires=proc-xen.mount xenstored.socket
-After=proc-xen.mount xenstored.socket
+Requires=proc-xen.mount xenstored.service
+After=proc-xen.mount xenstored.service
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]
diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
index 757278f..9962671 100644
--- a/tools/hotplug/Linux/systemd/xendomains.service.in
+++ b/tools/hotplug/Linux/systemd/xendomains.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=Xendomains - start and stop guests on boot and shutdown
-Requires=proc-xen.mount xenstored.socket
-After=proc-xen.mount xenstored.socket xenconsoled.service xen-init-dom0.service
+Requires=proc-xen.mount xenstored.service
+After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:17:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpCY-0008Df-N6; Tue, 02 Dec 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 <olaf@aepfle.de>)
	id 1XvpCW-0008DV-In; Tue, 02 Dec 2014 15:17:16 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	02/17-26652-BF7DD745; Tue, 02 Dec 2014 15:17:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417533433!7746904!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7154 invoked from network); 2 Dec 2014 15:17:13 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2014 15:17:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417533433; l=3106;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=5S42KlYKAILe6Sl/LONoRZXR6vs=;
	b=rz0Tax253KJnTyO+XncxYi81DvQJ9Y7ZHoMJGrr+u9cjlJim795vkUNCNoVYjG7vr4W
	56YxupqKxMGN/7TrRcku1sU5lwUDrzImaG2ZeDCFpqNW2B3w8tUx+Cj1F0fUyY3WDjoRW
	J1r+TmfCMpdmBOZ6dBQwpIsQ4NPac4LMZbg=
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.2 AUTH) with ESMTPSA id J062c0qB2FH9ltK
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 16:17:09 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 1B5E35016D; Tue,  2 Dec 2014 16:17:09 +0100 (CET)
Date: Tue, 2 Dec 2014 16:17:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202151708.GA23112@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417512564.15063.4.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, 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>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Ian Campbell wrote:

> On Mon, 2014-12-01 at 23:41 +0000, Mark Pryor wrote:
> > list,
> 
> Thanks. If you've identified a buggy changeset then it is fine to post
> to the devel lists. I've added a CC. I've also CCd everyone listed in
> the commit which you've fingered.
> 
> Olaf, does this suggested change look correct? If so then can you turn
> it into a patch please.

Yes, something like this (sed -i 's@socket@service@g' *.in):


diff --git a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
index 4d4cb23..3befadc 100644
--- a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
+++ b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=xen-init-dom0, initialise Dom0 configuration (xenstore nodes, JSON configuration stub)
-Requires=xenstored.socket proc-xen.mount
-After=xenstored.socket proc-xen.mount
+Requires=xenstored.service proc-xen.mount
+After=xenstored.service proc-xen.mount
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]
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 6b9c96e..0a5807a 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
@@ -1,7 +1,7 @@
 [Unit]
 Description=qemu for xen dom0 disk backend
-Requires=proc-xen.mount xenstored.socket
-After=proc-xen.mount xenstored.socket xenconsoled.service
+Requires=proc-xen.mount xenstored.service
+After=proc-xen.mount xenstored.service xenconsoled.service
 Before=xendomains.service libvirtd.service libvirt-guests.service
 RefuseManualStop=true
 ConditionPathExists=/proc/xen/capabilities
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index 2c5d99f..cb44cd6 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=Xenconsoled - handles logging from guest consoles and hypervisor
-Requires=proc-xen.mount xenstored.socket
-After=proc-xen.mount xenstored.socket
+Requires=proc-xen.mount xenstored.service
+After=proc-xen.mount xenstored.service
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]
diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
index 757278f..9962671 100644
--- a/tools/hotplug/Linux/systemd/xendomains.service.in
+++ b/tools/hotplug/Linux/systemd/xendomains.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=Xendomains - start and stop guests on boot and shutdown
-Requires=proc-xen.mount xenstored.socket
-After=proc-xen.mount xenstored.socket xenconsoled.service xen-init-dom0.service
+Requires=proc-xen.mount xenstored.service
+After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:17:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvpD7-0008Ho-M4; Tue, 02 Dec 2014 15:17:53 +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 1XvpD6-0008HW-2d
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:17:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	58/E1-15461-F18DD745; Tue, 02 Dec 2014 15:17:51 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417533468!12554258!1
X-Originating-IP: [156.151.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 8471 invoked from network); 2 Dec 2014 15:17:49 -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; 2 Dec 2014 15:17:49 -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 sB2FHgqF017581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15: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
	sB2FHfPA021973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:17:41 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
	sB2FHeQs021935; Tue, 2 Dec 2014 15:17:41 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:17:40 -0800
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Tue,  2 Dec 2014 16:16:27 +0100
Message-Id: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.7.10.4
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, jbeulich@suse.com
Subject: [Xen-devel] [PATCH for-xen-4.5 0/3] tools: build system fixes and
	cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Here are three tools build system patches:
  - tools/hotplug: distclean target should remove files generated by configure,
  - gitignore: ignore some files generated by configure,
  - gitignore: group tools/hotplug files in one place.

First two are real fixes. Last one is a cleanup which is nice to have
but not required at this stage of 4.5 development.

Daniel

 .gitignore             |   12 +++++++-----
 tools/Makefile         |    3 +++
 tools/hotplug/Makefile |    5 ++++-
 3 files changed, 14 insertions(+), 6 deletions(-)

Daniel Kiper (3):
      tools/hotplug: distclean target should remove files generated by configure
      gitignore: ignore some files generated by configure
      gitignore: group tools/hotplug files in one place


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:17:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvpD7-0008Ho-M4; Tue, 02 Dec 2014 15:17:53 +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 1XvpD6-0008HW-2d
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:17:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	58/E1-15461-F18DD745; Tue, 02 Dec 2014 15:17:51 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417533468!12554258!1
X-Originating-IP: [156.151.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 8471 invoked from network); 2 Dec 2014 15:17:49 -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; 2 Dec 2014 15:17:49 -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 sB2FHgqF017581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15: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
	sB2FHfPA021973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:17:41 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
	sB2FHeQs021935; Tue, 2 Dec 2014 15:17:41 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:17:40 -0800
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Tue,  2 Dec 2014 16:16:27 +0100
Message-Id: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.7.10.4
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, jbeulich@suse.com
Subject: [Xen-devel] [PATCH for-xen-4.5 0/3] tools: build system fixes and
	cleanups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Here are three tools build system patches:
  - tools/hotplug: distclean target should remove files generated by configure,
  - gitignore: ignore some files generated by configure,
  - gitignore: group tools/hotplug files in one place.

First two are real fixes. Last one is a cleanup which is nice to have
but not required at this stage of 4.5 development.

Daniel

 .gitignore             |   12 +++++++-----
 tools/Makefile         |    3 +++
 tools/hotplug/Makefile |    5 ++++-
 3 files changed, 14 insertions(+), 6 deletions(-)

Daniel Kiper (3):
      tools/hotplug: distclean target should remove files generated by configure
      gitignore: ignore some files generated by configure
      gitignore: group tools/hotplug files in one place


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:17:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvpD8-0008Hz-18; Tue, 02 Dec 2014 15:17:54 +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 1XvpD6-0008HY-3Q
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:17:52 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	B3/92-11581-F18DD745; Tue, 02 Dec 2014 15:17:51 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417533469!3514970!1
X-Originating-IP: [156.151.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 14683 invoked from network); 2 Dec 2014 15:17:50 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:17: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 sB2FHit8017643
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:17:44 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
	sB2FHhP9018552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:17:43 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
	sB2FHhIX022108; Tue, 2 Dec 2014 15:17:43 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:17:42 -0800
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Tue,  2 Dec 2014 16:16:28 +0100
Message-Id: <1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian.jackson@eu.citrix.com, jbeulich@suse.com
Subject: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean target
	should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 tools/Makefile         |    3 +++
 tools/hotplug/Makefile |    5 ++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index af9798a..19b24f3 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -261,6 +261,9 @@ subdir-all-debugger/kdd: .phony
 subdir-distclean-firmware: .phony
 	$(MAKE) -C firmware distclean
 
+subdir-distclean-hotplug: .phony
+	$(MAKE) -C hotplug distclean
+
 subtree-force-update:
 ifeq ($(CONFIG_QEMU_XEN),y)
 	$(MAKE) qemu-xen-dir-force-update
diff --git a/tools/hotplug/Makefile b/tools/hotplug/Makefile
index 14ae9a8..a29a522 100644
--- a/tools/hotplug/Makefile
+++ b/tools/hotplug/Makefile
@@ -6,5 +6,8 @@ SUBDIRS-$(CONFIG_NetBSD) += NetBSD
 SUBDIRS-$(CONFIG_Linux) += Linux
 SUBDIRS-$(CONFIG_FreeBSD) += FreeBSD
 
-.PHONY: all clean install
+.PHONY: all clean distclean install
 all clean install: %: subdirs-%
+
+distclean:
+	rm -f Linux/init.d/sysconfig.xencommons Linux/init.d/xencommons NetBSD/rc.d/xencommons
-- 
1.7.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 Dec 02 15:17:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvpD8-0008Hz-18; Tue, 02 Dec 2014 15:17:54 +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 1XvpD6-0008HY-3Q
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:17:52 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	B3/92-11581-F18DD745; Tue, 02 Dec 2014 15:17:51 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417533469!3514970!1
X-Originating-IP: [156.151.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 14683 invoked from network); 2 Dec 2014 15:17:50 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:17: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 sB2FHit8017643
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:17:44 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
	sB2FHhP9018552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:17:43 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
	sB2FHhIX022108; Tue, 2 Dec 2014 15:17:43 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:17:42 -0800
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Tue,  2 Dec 2014 16:16:28 +0100
Message-Id: <1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian.jackson@eu.citrix.com, jbeulich@suse.com
Subject: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean target
	should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 tools/Makefile         |    3 +++
 tools/hotplug/Makefile |    5 ++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index af9798a..19b24f3 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -261,6 +261,9 @@ subdir-all-debugger/kdd: .phony
 subdir-distclean-firmware: .phony
 	$(MAKE) -C firmware distclean
 
+subdir-distclean-hotplug: .phony
+	$(MAKE) -C hotplug distclean
+
 subtree-force-update:
 ifeq ($(CONFIG_QEMU_XEN),y)
 	$(MAKE) qemu-xen-dir-force-update
diff --git a/tools/hotplug/Makefile b/tools/hotplug/Makefile
index 14ae9a8..a29a522 100644
--- a/tools/hotplug/Makefile
+++ b/tools/hotplug/Makefile
@@ -6,5 +6,8 @@ SUBDIRS-$(CONFIG_NetBSD) += NetBSD
 SUBDIRS-$(CONFIG_Linux) += Linux
 SUBDIRS-$(CONFIG_FreeBSD) += FreeBSD
 
-.PHONY: all clean install
+.PHONY: all clean distclean install
 all clean install: %: subdirs-%
+
+distclean:
+	rm -f Linux/init.d/sysconfig.xencommons Linux/init.d/xencommons NetBSD/rc.d/xencommons
-- 
1.7.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 Dec 02 15:17:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpDC-0008KW-M4; Tue, 02 Dec 2014 15:17:58 +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 1XvpDB-0008Ju-Jj
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:17:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6B/6F-09842-428DD745; Tue, 02 Dec 2014 15:17:56 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417533474!12868273!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20126 invoked from network); 2 Dec 2014 15:17:56 -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; 2 Dec 2014 15:17:56 -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 sB2FHkkK019162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:17:47 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
	sB2FHjhA022324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:17:46 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
	sB2FHjbQ022288; Tue, 2 Dec 2014 15:17:45 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:17:44 -0800
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Tue,  2 Dec 2014 16:16:29 +0100
Message-Id: <1417533390-29035-3-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian.jackson@eu.citrix.com, jbeulich@suse.com
Subject: [Xen-devel] [PATCH for-xen-4.5 2/3] gitignore: ignore some files
	generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 .gitignore |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/.gitignore b/.gitignore
index b24e905..2b51d5f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -141,12 +141,15 @@ tools/flask/utils/flask-set-bool
 tools/flask/utils/flask-label-pci
 tools/hotplug/common/hotplugpath.sh
 tools/hotplug/FreeBSD/rc.d/xencommons
+tools/hotplug/Linux/init.d/sysconfig.xencommons
 tools/hotplug/Linux/init.d/xen-watchdog
+tools/hotplug/Linux/init.d/xencommons
 tools/hotplug/Linux/init.d/xendomains
 tools/hotplug/Linux/vif-setup
 tools/hotplug/Linux/xen-backend.rules
 tools/hotplug/Linux/xen-hotplug-common.sh
 tools/hotplug/Linux/xendomains
+tools/hotplug/NetBSD/rc.d/xencommons
 tools/include/xen/*
 tools/include/xen-foreign/*.(c|h|size)
 tools/include/xen-foreign/checker
-- 
1.7.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 Dec 02 15:17:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpDC-0008KW-M4; Tue, 02 Dec 2014 15:17:58 +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 1XvpDB-0008Ju-Jj
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:17:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6B/6F-09842-428DD745; Tue, 02 Dec 2014 15:17:56 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417533474!12868273!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20126 invoked from network); 2 Dec 2014 15:17:56 -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; 2 Dec 2014 15:17:56 -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 sB2FHkkK019162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:17:47 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
	sB2FHjhA022324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 15:17:46 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
	sB2FHjbQ022288; Tue, 2 Dec 2014 15:17:45 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:17:44 -0800
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Tue,  2 Dec 2014 16:16:29 +0100
Message-Id: <1417533390-29035-3-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian.jackson@eu.citrix.com, jbeulich@suse.com
Subject: [Xen-devel] [PATCH for-xen-4.5 2/3] gitignore: ignore some files
	generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 .gitignore |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/.gitignore b/.gitignore
index b24e905..2b51d5f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -141,12 +141,15 @@ tools/flask/utils/flask-set-bool
 tools/flask/utils/flask-label-pci
 tools/hotplug/common/hotplugpath.sh
 tools/hotplug/FreeBSD/rc.d/xencommons
+tools/hotplug/Linux/init.d/sysconfig.xencommons
 tools/hotplug/Linux/init.d/xen-watchdog
+tools/hotplug/Linux/init.d/xencommons
 tools/hotplug/Linux/init.d/xendomains
 tools/hotplug/Linux/vif-setup
 tools/hotplug/Linux/xen-backend.rules
 tools/hotplug/Linux/xen-hotplug-common.sh
 tools/hotplug/Linux/xendomains
+tools/hotplug/NetBSD/rc.d/xencommons
 tools/include/xen/*
 tools/include/xen-foreign/*.(c|h|size)
 tools/include/xen-foreign/checker
-- 
1.7.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 Dec 02 15:18:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:18:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpDF-0008MG-3i; Tue, 02 Dec 2014 15:18:01 +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 1XvpDD-0008KU-3z
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:17:59 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	1F/D4-22819-628DD745; Tue, 02 Dec 2014 15:17:58 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417533476!8218525!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11041 invoked from network); 2 Dec 2014 15:17:57 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2014 15:17:57 -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 sB2FHocb019251
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:17:50 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
	sB2FHmFq024276
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 15:17:49 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
	sB2FHlOJ018784; Tue, 2 Dec 2014 15:17:47 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:17:46 -0800
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Tue,  2 Dec 2014 16:16:30 +0100
Message-Id: <1417533390-29035-4-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian.jackson@eu.citrix.com, jbeulich@suse.com
Subject: [Xen-devel] [PATCH for-xen-4.5 3/3] gitignore: group tools/hotplug
	files in one place
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 .gitignore |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/.gitignore b/.gitignore
index 2b51d5f..8c8c06f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -145,6 +145,10 @@ tools/hotplug/Linux/init.d/sysconfig.xencommons
 tools/hotplug/Linux/init.d/xen-watchdog
 tools/hotplug/Linux/init.d/xencommons
 tools/hotplug/Linux/init.d/xendomains
+tools/hotplug/Linux/systemd/*.conf
+tools/hotplug/Linux/systemd/*.mount
+tools/hotplug/Linux/systemd/*.socket
+tools/hotplug/Linux/systemd/*.service
 tools/hotplug/Linux/vif-setup
 tools/hotplug/Linux/xen-backend.rules
 tools/hotplug/Linux/xen-hotplug-common.sh
@@ -329,8 +333,3 @@ tools/xenstore/xenstore-watch
 docs/txt/misc/*.txt
 docs/txt/man/*.txt
 docs/figs/*.png
-
-tools/hotplug/Linux/systemd/*.conf
-tools/hotplug/Linux/systemd/*.mount
-tools/hotplug/Linux/systemd/*.socket
-tools/hotplug/Linux/systemd/*.service
-- 
1.7.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 Dec 02 15:18:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:18:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpDF-0008MG-3i; Tue, 02 Dec 2014 15:18:01 +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 1XvpDD-0008KU-3z
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:17:59 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	1F/D4-22819-628DD745; Tue, 02 Dec 2014 15:17:58 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417533476!8218525!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11041 invoked from network); 2 Dec 2014 15:17:57 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2014 15:17:57 -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 sB2FHocb019251
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 15:17:50 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
	sB2FHmFq024276
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 15:17:49 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
	sB2FHlOJ018784; Tue, 2 Dec 2014 15:17:47 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 07:17:46 -0800
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Tue,  2 Dec 2014 16:16:30 +0100
Message-Id: <1417533390-29035-4-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian.jackson@eu.citrix.com, jbeulich@suse.com
Subject: [Xen-devel] [PATCH for-xen-4.5 3/3] gitignore: group tools/hotplug
	files in one place
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 .gitignore |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/.gitignore b/.gitignore
index 2b51d5f..8c8c06f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -145,6 +145,10 @@ tools/hotplug/Linux/init.d/sysconfig.xencommons
 tools/hotplug/Linux/init.d/xen-watchdog
 tools/hotplug/Linux/init.d/xencommons
 tools/hotplug/Linux/init.d/xendomains
+tools/hotplug/Linux/systemd/*.conf
+tools/hotplug/Linux/systemd/*.mount
+tools/hotplug/Linux/systemd/*.socket
+tools/hotplug/Linux/systemd/*.service
 tools/hotplug/Linux/vif-setup
 tools/hotplug/Linux/xen-backend.rules
 tools/hotplug/Linux/xen-hotplug-common.sh
@@ -329,8 +333,3 @@ tools/xenstore/xenstore-watch
 docs/txt/misc/*.txt
 docs/txt/man/*.txt
 docs/figs/*.png
-
-tools/hotplug/Linux/systemd/*.conf
-tools/hotplug/Linux/systemd/*.mount
-tools/hotplug/Linux/systemd/*.socket
-tools/hotplug/Linux/systemd/*.service
-- 
1.7.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 Dec 02 15:18:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpDc-00004x-2W; Tue, 02 Dec 2014 15:18:24 +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 1XvpDa-0008Vj-Vb
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:18:23 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	98/99-24859-E38DD745; Tue, 02 Dec 2014 15:18:22 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417533499!15282711!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 10954 invoked from network); 2 Dec 2014 15:18:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:18:21 -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 sB2FIBC0018712
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 2 Dec 2014 10:18:11 -0500
Received: from vitty.brq.redhat.com (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 sB2FI9ec013381; Tue, 2 Dec 2014 10:18:09 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xen.org
Date: Tue,  2 Dec 2014 16:18:08 +0100
Message-Id: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.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] libxc: check in xc_get_tot_pages() that the
	proper domain is reported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
strange interface: it reports first domain which has domid >= requested domid
so all callers are supposed to check that the proper domain(s) was queried
by checking domid. xc_get_tot_pages() doesn't do that. In case the requested
domain was destroyed it will report first domain with domid > requested domid
which is apparently misleading as there is no way xc_get_tot_pages() callers
can figure out that they got tot_pages for some other domain.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxc/xc_private.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
index 1c214dd..e2441ad 100644
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -613,8 +613,10 @@ int xc_get_pfn_list(xc_interface *xch,
 long xc_get_tot_pages(xc_interface *xch, uint32_t domid)
 {
     xc_dominfo_t info;
-    return (xc_domain_getinfo(xch, domid, 1, &info) != 1) ?
-        -1 : info.nr_pages;
+    if ( (xc_domain_getinfo(xch, domid, 1, &info) != 1) ||
+         (info.domid != domid) )
+        return -1;
+    return info.nr_pages;
 }
 
 int xc_copy_to_domain_page(xc_interface *xch,
-- 
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 Dec 02 15:18:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpDc-00004x-2W; Tue, 02 Dec 2014 15:18:24 +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 1XvpDa-0008Vj-Vb
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:18:23 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	98/99-24859-E38DD745; Tue, 02 Dec 2014 15:18:22 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417533499!15282711!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 10954 invoked from network); 2 Dec 2014 15:18:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:18:21 -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 sB2FIBC0018712
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 2 Dec 2014 10:18:11 -0500
Received: from vitty.brq.redhat.com (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 sB2FI9ec013381; Tue, 2 Dec 2014 10:18:09 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xen.org
Date: Tue,  2 Dec 2014 16:18:08 +0100
Message-Id: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.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] libxc: check in xc_get_tot_pages() that the
	proper domain is reported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
strange interface: it reports first domain which has domid >= requested domid
so all callers are supposed to check that the proper domain(s) was queried
by checking domid. xc_get_tot_pages() doesn't do that. In case the requested
domain was destroyed it will report first domain with domid > requested domid
which is apparently misleading as there is no way xc_get_tot_pages() callers
can figure out that they got tot_pages for some other domain.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxc/xc_private.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
index 1c214dd..e2441ad 100644
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -613,8 +613,10 @@ int xc_get_pfn_list(xc_interface *xch,
 long xc_get_tot_pages(xc_interface *xch, uint32_t domid)
 {
     xc_dominfo_t info;
-    return (xc_domain_getinfo(xch, domid, 1, &info) != 1) ?
-        -1 : info.nr_pages;
+    if ( (xc_domain_getinfo(xch, domid, 1, &info) != 1) ||
+         (info.domid != domid) )
+        return -1;
+    return info.nr_pages;
 }
 
 int xc_copy_to_domain_page(xc_interface *xch,
-- 
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 Dec 02 15:27:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvpMR-00015C-NG; Tue, 02 Dec 2014 15:27: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 1XvpMQ-000157-JA
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:27:30 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	33/5B-18267-16ADD745; Tue, 02 Dec 2014 15:27:29 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417534046!15330727!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 32112 invoked from network); 2 Dec 2014 15:27:28 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:27: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=1417534048; x=1449070048;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=zCht/0a1zB+17QlJE0WVwUCNBA7kXs7mfiPd7YHTyK8=;
	b=J89sLOZEH+raUlQB3gP7S57ZWXOo/KtG88Ftx+8QeHmdW+lMrFO98EXT
	v+ygePJAVQB2k3Cd3hyFTvI5C1Q0KNgKU1za8TxB3kVRMA2tjObpTqn4z
	mIso+3uxTE02IBwbarDM/txnqM44JsXv6BdBVoSbmclaCrL6VZkeA6lsZ Q=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 02 Dec 2014 15:27:26 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="883539063"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.109.253])
	by fldsmtpi03.verizon.com with ESMTP; 02 Dec 2014 15:27:25 +0000
Message-ID: <547DDA5C.8080803@terremark.com>
Date: Tue, 02 Dec 2014 10:27: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: Don Slutz <dslutz@verizon.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.com>
	<alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
	<547DD3E5.9090303@terremark.com>
In-Reply-To: <547DD3E5.9090303@terremark.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.6] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/14 09:59, Don Slutz wrote:
> On 12/02/14 09:26, Stefano Stabellini wrote:
>> On Tue, 2 Dec 2014, Don Slutz wrote:
>>> On 12/02/14 06:53, Stefano Stabellini wrote:
>>>> 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>
>>>>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - call libxl_domain_info instead of libxl_dominfo_init;
>>>> - call libxl_domain_info before retry_transaction.
>>>>
>>>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>>>> index de23fec..569a32a 100644
>>>> --- a/tools/libxl/libxl.c
>>>> +++ b/tools/libxl/libxl.c
>>>> @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx, 
>>>> uint32_t
>>>> domid,
>>>>        char *uuid;
>>>>        xs_transaction_t t;
>>>>    +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
>>>> +        goto out_no_transaction;
>>>> +
>>>>    retry_transaction:
>>>>        t = xs_transaction_start(ctx->xsh);
>>>>    @@ -4767,10 +4770,9 @@ 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);
>>>> +    if (enforce && new_target_memkb > 0) {
>>>> +        memorykb = ptr.max_memkb - current_target_memkb + 
>>>> new_target_memkb;

My testing shows that this should be:

         memorykb = ptr.max_memkb - (current_target_memkb + videoram) +
             new_target_memkb;

As far as I can tell the reason for this is that memory/target (aka
current_target_memkb) was set based on:

     new_target_memkb -= videoram;

    -Don Slutz
>>>> +        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 "
>>> You need to remove LIBXL_MAXMEM_CONSTANT here also.
>> I don't think so: LIBXL_MAXMEM_CONSTANT is supposed to be a safety
>> buffer and we should keep it as is across libxl_set_memory_target calls.
>> Arguably LIBXL_MAXMEM_CONSTANT could be removed entirely with the
>> proposed QEMU changes but that is a separate matter.
>>
>
> I was talking about the line:
>
>                     "rc=%d\n", domid, memorykb + 
> LIBXL_MAXMEM_CONSTANT, rc);
>
> (which is missing from the diff but is part of the LIBXL__LOG_ERRNO 
> call).  The
> error message no longer matches what  xc_domain_setmaxmem() was called
> with.
>
>    -Don Slutz
>
>>>> @@ -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 Dec 02 15:27:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvpMR-00015C-NG; Tue, 02 Dec 2014 15:27: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 1XvpMQ-000157-JA
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:27:30 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	33/5B-18267-16ADD745; Tue, 02 Dec 2014 15:27:29 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417534046!15330727!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 32112 invoked from network); 2 Dec 2014 15:27:28 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:27: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=1417534048; x=1449070048;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=zCht/0a1zB+17QlJE0WVwUCNBA7kXs7mfiPd7YHTyK8=;
	b=J89sLOZEH+raUlQB3gP7S57ZWXOo/KtG88Ftx+8QeHmdW+lMrFO98EXT
	v+ygePJAVQB2k3Cd3hyFTvI5C1Q0KNgKU1za8TxB3kVRMA2tjObpTqn4z
	mIso+3uxTE02IBwbarDM/txnqM44JsXv6BdBVoSbmclaCrL6VZkeA6lsZ Q=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 02 Dec 2014 15:27:26 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="883539063"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.109.253])
	by fldsmtpi03.verizon.com with ESMTP; 02 Dec 2014 15:27:25 +0000
Message-ID: <547DDA5C.8080803@terremark.com>
Date: Tue, 02 Dec 2014 10:27: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: Don Slutz <dslutz@verizon.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.com>
	<alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
	<547DD3E5.9090303@terremark.com>
In-Reply-To: <547DD3E5.9090303@terremark.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.6] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/14 09:59, Don Slutz wrote:
> On 12/02/14 09:26, Stefano Stabellini wrote:
>> On Tue, 2 Dec 2014, Don Slutz wrote:
>>> On 12/02/14 06:53, Stefano Stabellini wrote:
>>>> 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>
>>>>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - call libxl_domain_info instead of libxl_dominfo_init;
>>>> - call libxl_domain_info before retry_transaction.
>>>>
>>>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>>>> index de23fec..569a32a 100644
>>>> --- a/tools/libxl/libxl.c
>>>> +++ b/tools/libxl/libxl.c
>>>> @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx, 
>>>> uint32_t
>>>> domid,
>>>>        char *uuid;
>>>>        xs_transaction_t t;
>>>>    +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
>>>> +        goto out_no_transaction;
>>>> +
>>>>    retry_transaction:
>>>>        t = xs_transaction_start(ctx->xsh);
>>>>    @@ -4767,10 +4770,9 @@ 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);
>>>> +    if (enforce && new_target_memkb > 0) {
>>>> +        memorykb = ptr.max_memkb - current_target_memkb + 
>>>> new_target_memkb;

My testing shows that this should be:

         memorykb = ptr.max_memkb - (current_target_memkb + videoram) +
             new_target_memkb;

As far as I can tell the reason for this is that memory/target (aka
current_target_memkb) was set based on:

     new_target_memkb -= videoram;

    -Don Slutz
>>>> +        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 "
>>> You need to remove LIBXL_MAXMEM_CONSTANT here also.
>> I don't think so: LIBXL_MAXMEM_CONSTANT is supposed to be a safety
>> buffer and we should keep it as is across libxl_set_memory_target calls.
>> Arguably LIBXL_MAXMEM_CONSTANT could be removed entirely with the
>> proposed QEMU changes but that is a separate matter.
>>
>
> I was talking about the line:
>
>                     "rc=%d\n", domid, memorykb + 
> LIBXL_MAXMEM_CONSTANT, rc);
>
> (which is missing from the diff but is part of the LIBXL__LOG_ERRNO 
> call).  The
> error message no longer matches what  xc_domain_setmaxmem() was called
> with.
>
>    -Don Slutz
>
>>>> @@ -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 Dec 02 15:31:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:31:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpQ2-0001El-B9; Tue, 02 Dec 2014 15:31:14 +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 1XvpQ1-0001Ef-9p
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:31:13 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	3D/1C-22777-04BDD745; Tue, 02 Dec 2014 15:31:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417534270!11102991!1
X-Originating-IP: [66.165.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 14016 invoked from network); 2 Dec 2014 15:31:11 -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;
	2 Dec 2014 15:31:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198889996"
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, 2 Dec 2014 10:11:30 -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 1Xvp6w-0002kB-2t;
	Tue, 02 Dec 2014 15:11:30 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 15:11:30 +0000
Message-ID: <1417533090-29651-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: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to determine
	systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
incorrect, even in the event systemd library is available.  Use
PKG_CHECK_MODULES instead.

Tested on Debian Jessie and Arch Linux.

Please rerun autogen.sh after applying this patch.

Reported-by: Mark Pryor <tlviewer@yahoo.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: Anthony Perard <anthony.perard@citrix.com>
Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Cc: Mark Pryor <tlviewer@yahoo.com>
---
 m4/systemd.m4 | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/m4/systemd.m4 b/m4/systemd.m4
index a832d59..b04964b 100644
--- a/m4/systemd.m4
+++ b/m4/systemd.m4
@@ -42,13 +42,6 @@ AC_DEFUN([AX_ALLOW_SYSTEMD_OPTS], [
 ])
 
 AC_DEFUN([AX_CHECK_SYSTEMD_LIBS], [
-	AC_CHECK_HEADER([systemd/sd-daemon.h], [
-	    AC_CHECK_LIB([systemd-daemon], [sd_listen_fds], [libsystemddaemon="y"])
-	])
-	AS_IF([test "x$libsystemddaemon" = x], [
-	    AC_MSG_ERROR([Unable to find a suitable libsystemd-daemon library])
-	])
-
 	PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon])
 	dnl pkg-config older than 0.24 does not set these for
 	dnl PKG_CHECK_MODULES() worth also noting is that as of version 208
@@ -98,9 +91,8 @@ AC_DEFUN([AX_CHECK_SYSTEMD], [
 ])
 
 AC_DEFUN([AX_CHECK_SYSTEMD_ENABLE_AVAILABLE], [
-	AC_CHECK_HEADER([systemd/sd-daemon.h], [
-	    AC_CHECK_LIB([systemd-daemon], [sd_listen_fds], [systemd="y"])
-	])
+	PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon], [systemd="y"],
+                          [systemd="n"])
 ])
 
 dnl Enables systemd by default and requires a --disable-systemd option flag
-- 
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 Dec 02 15:31:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:31:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpQ2-0001El-B9; Tue, 02 Dec 2014 15:31:14 +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 1XvpQ1-0001Ef-9p
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:31:13 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	3D/1C-22777-04BDD745; Tue, 02 Dec 2014 15:31:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417534270!11102991!1
X-Originating-IP: [66.165.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 14016 invoked from network); 2 Dec 2014 15:31:11 -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;
	2 Dec 2014 15:31:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198889996"
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, 2 Dec 2014 10:11:30 -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 1Xvp6w-0002kB-2t;
	Tue, 02 Dec 2014 15:11:30 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 2 Dec 2014 15:11:30 +0000
Message-ID: <1417533090-29651-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: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to determine
	systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
incorrect, even in the event systemd library is available.  Use
PKG_CHECK_MODULES instead.

Tested on Debian Jessie and Arch Linux.

Please rerun autogen.sh after applying this patch.

Reported-by: Mark Pryor <tlviewer@yahoo.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: Anthony Perard <anthony.perard@citrix.com>
Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Cc: Mark Pryor <tlviewer@yahoo.com>
---
 m4/systemd.m4 | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/m4/systemd.m4 b/m4/systemd.m4
index a832d59..b04964b 100644
--- a/m4/systemd.m4
+++ b/m4/systemd.m4
@@ -42,13 +42,6 @@ AC_DEFUN([AX_ALLOW_SYSTEMD_OPTS], [
 ])
 
 AC_DEFUN([AX_CHECK_SYSTEMD_LIBS], [
-	AC_CHECK_HEADER([systemd/sd-daemon.h], [
-	    AC_CHECK_LIB([systemd-daemon], [sd_listen_fds], [libsystemddaemon="y"])
-	])
-	AS_IF([test "x$libsystemddaemon" = x], [
-	    AC_MSG_ERROR([Unable to find a suitable libsystemd-daemon library])
-	])
-
 	PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon])
 	dnl pkg-config older than 0.24 does not set these for
 	dnl PKG_CHECK_MODULES() worth also noting is that as of version 208
@@ -98,9 +91,8 @@ AC_DEFUN([AX_CHECK_SYSTEMD], [
 ])
 
 AC_DEFUN([AX_CHECK_SYSTEMD_ENABLE_AVAILABLE], [
-	AC_CHECK_HEADER([systemd/sd-daemon.h], [
-	    AC_CHECK_LIB([systemd-daemon], [sd_listen_fds], [systemd="y"])
-	])
+	PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon], [systemd="y"],
+                          [systemd="n"])
 ])
 
 dnl Enables systemd by default and requires a --disable-systemd option flag
-- 
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 Dec 02 15:31:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvpQ8-0001Fd-NB; Tue, 02 Dec 2014 15:31:20 +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 1XvpQ7-0001F8-4o
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:31:19 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	4D/8A-27623-64BDD745; Tue, 02 Dec 2014 15:31:18 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417534276!15368345!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 13228 invoked from network); 2 Dec 2014 15:31:17 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:31:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417534277; x=1449070277;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=PZaTjHkS8ja+rCio9EdX6W3BOwxBluFu3IHr0YCi/ts=;
	b=ahlahD7m6vrHKWZPoE6gHoDE8y11Xg/hD3EGggHOi99FZl1GDdIfnb9A
	/Y+8Q39PrMMGGqdDYwGHbrhsqAJSoFgsQ6E9olEW94jtIFSQKZ9ek+qx0
	xTaElxAWak0g7pqjrAxzAFF99zzAXuHBiQRFQEi3HVHUnwtm7oEOLDW/x U=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 02 Dec 2014 15:31:15 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="918955107"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.109.253])
	by fldsmtpi01.verizon.com with ESMTP; 02 Dec 2014 15:31:11 +0000
Message-ID: <547DDB3F.9040509@terremark.com>
Date: Tue, 02 Dec 2014 10:31:11 -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: Vitaly Kuznetsov <vkuznets@redhat.com>, xen-devel@lists.xen.org
References: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Andrew Jones <drjones@redhat.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] libxc: check in xc_get_tot_pages() that the
 proper domain is reported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/14 10:18, Vitaly Kuznetsov wrote:
> XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
> strange interface: it reports first domain which has domid >= requested domid
> so all callers are supposed to check that the proper domain(s) was queried
> by checking domid. xc_get_tot_pages() doesn't do that. In case the requested
> domain was destroyed it will report first domain with domid > requested domid
> which is apparently misleading as there is no way xc_get_tot_pages() callers
> can figure out that they got tot_pages for some other domain.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
>   tools/libxc/xc_private.c | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
> index 1c214dd..e2441ad 100644
> --- a/tools/libxc/xc_private.c
> +++ b/tools/libxc/xc_private.c
> @@ -613,8 +613,10 @@ int xc_get_pfn_list(xc_interface *xch,
>   long xc_get_tot_pages(xc_interface *xch, uint32_t domid)
>   {
>       xc_dominfo_t info;
> -    return (xc_domain_getinfo(xch, domid, 1, &info) != 1) ?
> -        -1 : info.nr_pages;
> +    if ( (xc_domain_getinfo(xch, domid, 1, &info) != 1) ||
> +         (info.domid != domid) )
> +        return -1;
> +    return info.nr_pages;
>   }
>   
>   int xc_copy_to_domain_page(xc_interface *xch,

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 Tue Dec 02 15:31:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvpQ8-0001Fd-NB; Tue, 02 Dec 2014 15:31:20 +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 1XvpQ7-0001F8-4o
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:31:19 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	4D/8A-27623-64BDD745; Tue, 02 Dec 2014 15:31:18 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417534276!15368345!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 13228 invoked from network); 2 Dec 2014 15:31:17 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:31:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417534277; x=1449070277;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=PZaTjHkS8ja+rCio9EdX6W3BOwxBluFu3IHr0YCi/ts=;
	b=ahlahD7m6vrHKWZPoE6gHoDE8y11Xg/hD3EGggHOi99FZl1GDdIfnb9A
	/Y+8Q39PrMMGGqdDYwGHbrhsqAJSoFgsQ6E9olEW94jtIFSQKZ9ek+qx0
	xTaElxAWak0g7pqjrAxzAFF99zzAXuHBiQRFQEi3HVHUnwtm7oEOLDW/x U=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 02 Dec 2014 15:31:15 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="918955107"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.109.253])
	by fldsmtpi01.verizon.com with ESMTP; 02 Dec 2014 15:31:11 +0000
Message-ID: <547DDB3F.9040509@terremark.com>
Date: Tue, 02 Dec 2014 10:31:11 -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: Vitaly Kuznetsov <vkuznets@redhat.com>, xen-devel@lists.xen.org
References: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Andrew Jones <drjones@redhat.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] libxc: check in xc_get_tot_pages() that the
 proper domain is reported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/14 10:18, Vitaly Kuznetsov wrote:
> XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
> strange interface: it reports first domain which has domid >= requested domid
> so all callers are supposed to check that the proper domain(s) was queried
> by checking domid. xc_get_tot_pages() doesn't do that. In case the requested
> domain was destroyed it will report first domain with domid > requested domid
> which is apparently misleading as there is no way xc_get_tot_pages() callers
> can figure out that they got tot_pages for some other domain.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
>   tools/libxc/xc_private.c | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
> index 1c214dd..e2441ad 100644
> --- a/tools/libxc/xc_private.c
> +++ b/tools/libxc/xc_private.c
> @@ -613,8 +613,10 @@ int xc_get_pfn_list(xc_interface *xch,
>   long xc_get_tot_pages(xc_interface *xch, uint32_t domid)
>   {
>       xc_dominfo_t info;
> -    return (xc_domain_getinfo(xch, domid, 1, &info) != 1) ?
> -        -1 : info.nr_pages;
> +    if ( (xc_domain_getinfo(xch, domid, 1, &info) != 1) ||
> +         (info.domid != domid) )
> +        return -1;
> +    return info.nr_pages;
>   }
>   
>   int xc_copy_to_domain_page(xc_interface *xch,

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 Tue Dec 02 15:31:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:31:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpQL-0001Ia-7n; Tue, 02 Dec 2014 15:31:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XvpQJ-0001IC-Az
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:31:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	57/FE-15461-25BDD745; Tue, 02 Dec 2014 15:31:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417534289!12914617!1
X-Originating-IP: [209.85.192.53]
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 1616 invoked from network); 2 Dec 2014 15:31:29 -0000
Received: from mail-qg0-f53.google.com (HELO mail-qg0-f53.google.com)
	(209.85.192.53)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 15:31:29 -0000
Received: by mail-qg0-f53.google.com with SMTP id q108so9301634qgd.40
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 07:31: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=C5dSbRjt6cnv5aVYpi9MVPWQgb1Eqa3N/plkAxL9zyQ=;
	b=ceIF46G1xuyrp5AVupBFEwHf5MrIf3yR6XH8VDHVPJoaGMVZn7d4Bx/S4L0DTMXBgX
	bEbCzkLfQsCGpxE36X9mYcZ4teBCeHZjPtg9xvOVbMDNILFMu9akAEL+lE1MujmV0zXf
	Vo8OJDw2Es6ZwDgv9rFWohD7LYzZmT5pUj40lYW/dDZFR9hlYVTRT2sHLtP+7EYzC1Pz
	9+DQh3N0YtQQm0rCrT5Xf78RKAyLSyH1ji7nZv+ZRuVcrL9wRN2kYwMgDnmkdiwLTffS
	eJhSJXFsgDF8NCqP3TsJMwh2SRKTvVGNtbbVJkn9SttZuS/dSPtZeif2/DVEWpFVQt2M
	py2A==
X-Gm-Message-State: ALoCoQlirOPRyvOQfuagRNgWkQBanUmXRF6Iy64Xzn5TLHb/EHeAoTSNyp/5Q1TSTRE9aoBlijTo
X-Received: by 10.229.97.73 with SMTP id k9mr75283408qcn.15.1417534288818;
	Tue, 02 Dec 2014 07:31:28 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([185.25.64.249])
	by mx.google.com with ESMTPSA id k4sm20686774qaf.0.2014.12.02.07.31.26
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 07:31:28 -0800 (PST)
Message-ID: <547DDB4B.6060506@linaro.org>
Date: Tue, 02 Dec 2014 15:31: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: Andrew Turner <andrew@fubar.geek.nz>
References: <54726138.3090003@linaro.org> <20141128135737.23a71643@bender.lan>
In-Reply-To: <20141128135737.23a71643@bender.lan>
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-Transfer-Encoding: 7bit
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 Andrew,

On 28/11/2014 13:57, Andrew Turner wrote:
> On Sun, 23 Nov 2014 22:35:36 +0000
> Julien Grall <julien.grall@linaro.org> wrote:
>> 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.

Thanks, I will give a look to this solution.

>>
>> 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.

Thanks!

> 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.

Right, I guess I could just keep the roundup2.

>
> ...
>>
>> 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.

BTW, what is the actual status of the ARM64 port? I plan to give a look
for adding Xen support 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 Dec 02 15:31:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:31:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpQL-0001Ia-7n; Tue, 02 Dec 2014 15:31:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XvpQJ-0001IC-Az
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:31:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	57/FE-15461-25BDD745; Tue, 02 Dec 2014 15:31:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417534289!12914617!1
X-Originating-IP: [209.85.192.53]
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 1616 invoked from network); 2 Dec 2014 15:31:29 -0000
Received: from mail-qg0-f53.google.com (HELO mail-qg0-f53.google.com)
	(209.85.192.53)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 15:31:29 -0000
Received: by mail-qg0-f53.google.com with SMTP id q108so9301634qgd.40
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 07:31: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=C5dSbRjt6cnv5aVYpi9MVPWQgb1Eqa3N/plkAxL9zyQ=;
	b=ceIF46G1xuyrp5AVupBFEwHf5MrIf3yR6XH8VDHVPJoaGMVZn7d4Bx/S4L0DTMXBgX
	bEbCzkLfQsCGpxE36X9mYcZ4teBCeHZjPtg9xvOVbMDNILFMu9akAEL+lE1MujmV0zXf
	Vo8OJDw2Es6ZwDgv9rFWohD7LYzZmT5pUj40lYW/dDZFR9hlYVTRT2sHLtP+7EYzC1Pz
	9+DQh3N0YtQQm0rCrT5Xf78RKAyLSyH1ji7nZv+ZRuVcrL9wRN2kYwMgDnmkdiwLTffS
	eJhSJXFsgDF8NCqP3TsJMwh2SRKTvVGNtbbVJkn9SttZuS/dSPtZeif2/DVEWpFVQt2M
	py2A==
X-Gm-Message-State: ALoCoQlirOPRyvOQfuagRNgWkQBanUmXRF6Iy64Xzn5TLHb/EHeAoTSNyp/5Q1TSTRE9aoBlijTo
X-Received: by 10.229.97.73 with SMTP id k9mr75283408qcn.15.1417534288818;
	Tue, 02 Dec 2014 07:31:28 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([185.25.64.249])
	by mx.google.com with ESMTPSA id k4sm20686774qaf.0.2014.12.02.07.31.26
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 07:31:28 -0800 (PST)
Message-ID: <547DDB4B.6060506@linaro.org>
Date: Tue, 02 Dec 2014 15:31: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: Andrew Turner <andrew@fubar.geek.nz>
References: <54726138.3090003@linaro.org> <20141128135737.23a71643@bender.lan>
In-Reply-To: <20141128135737.23a71643@bender.lan>
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-Transfer-Encoding: 7bit
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 Andrew,

On 28/11/2014 13:57, Andrew Turner wrote:
> On Sun, 23 Nov 2014 22:35:36 +0000
> Julien Grall <julien.grall@linaro.org> wrote:
>> 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.

Thanks, I will give a look to this solution.

>>
>> 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.

Thanks!

> 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.

Right, I guess I could just keep the roundup2.

>
> ...
>>
>> 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.

BTW, what is the actual status of the ARM64 port? I plan to give a look
for adding Xen support 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 Dec 02 15:33:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:33:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpSP-0001dS-Vm; Tue, 02 Dec 2014 15:33:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvpSO-0001d8-Fv
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:33:40 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	9F/69-24859-3DBDD745; Tue, 02 Dec 2014 15:33:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417534414!12862375!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10377 invoked from network); 2 Dec 2014 15:33:38 -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;
	2 Dec 2014 15:33:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198557806"
Message-ID: <1417533160.24320.54.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 2 Dec 2014 15:12:40 +0000
In-Reply-To: <CAFLBxZZKBf70oH7yUC9JDU7U3Ca5SAt6vWcNfnMy566KEPQS4w@mail.gmail.com>
References: <201411271512.sARFC11l001276@userz7022.oracle.com>
	<CAFLBxZZKBf70oH7yUC9JDU7U3Ca5SAt6vWcNfnMy566KEPQS4w@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" <xen-devel@lists.xen.org>,
	Tim Deegan <tim@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 Tue, 2014-12-02 at 15:10 +0000, George Dunlap wrote:
> On Thu, Nov 27, 2014 at 3:11 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> >
> > On Nov 27, 2014 6:59 AM, Tim Deegan <tim@xen.org> wrote:
> >>
> >> 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
> >
> > +1 too.

> OK, that's +4 and no minuses after 5 days.  How long to I have to wait?  :-)

http://www.xenproject.org/help/contribution-guidelines.html says seven
days...

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:33:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:33:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpSP-0001dS-Vm; Tue, 02 Dec 2014 15:33:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvpSO-0001d8-Fv
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:33:40 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	9F/69-24859-3DBDD745; Tue, 02 Dec 2014 15:33:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417534414!12862375!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10377 invoked from network); 2 Dec 2014 15:33:38 -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;
	2 Dec 2014 15:33:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198557806"
Message-ID: <1417533160.24320.54.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 2 Dec 2014 15:12:40 +0000
In-Reply-To: <CAFLBxZZKBf70oH7yUC9JDU7U3Ca5SAt6vWcNfnMy566KEPQS4w@mail.gmail.com>
References: <201411271512.sARFC11l001276@userz7022.oracle.com>
	<CAFLBxZZKBf70oH7yUC9JDU7U3Ca5SAt6vWcNfnMy566KEPQS4w@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" <xen-devel@lists.xen.org>,
	Tim Deegan <tim@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 Tue, 2014-12-02 at 15:10 +0000, George Dunlap wrote:
> On Thu, Nov 27, 2014 at 3:11 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> >
> > On Nov 27, 2014 6:59 AM, Tim Deegan <tim@xen.org> wrote:
> >>
> >> 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
> >
> > +1 too.

> OK, that's +4 and no minuses after 5 days.  How long to I have to wait?  :-)

http://www.xenproject.org/help/contribution-guidelines.html says seven
days...

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:35:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpTw-0001nv-Fo; Tue, 02 Dec 2014 15:35:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvpTu-0001nj-H8
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:35:14 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	D5/F4-02953-13CDD745; Tue, 02 Dec 2014 15:35:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417534509!9176164!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 8165 invoked from network); 2 Dec 2014 15:35:13 -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;
	2 Dec 2014 15:35:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198558278"
Message-ID: <1417533208.24320.55.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:13:28 +0000
In-Reply-To: <20141202151101.GG27869@laptop.dumpdata.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com>
	<20141202151101.GG27869@laptop.dumpdata.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>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 10:11 -0500, Konrad Rzeszutek Wilk wrote:
> > [0] The default i386 Debian installer falls into this camp, but you can
> > use the special PV Xen variant to install as PVHVM too so it's not so
> > critical.
> 
> And the Fedora 21 LiveISO (32-bit) does too.

Interesting, I thought Fedora had switched to requiring PAE as a minimum
baseline everywhere 

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:35:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpTw-0001nv-Fo; Tue, 02 Dec 2014 15:35:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvpTu-0001nj-H8
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:35:14 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	D5/F4-02953-13CDD745; Tue, 02 Dec 2014 15:35:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417534509!9176164!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 8165 invoked from network); 2 Dec 2014 15:35:13 -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;
	2 Dec 2014 15:35:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198558278"
Message-ID: <1417533208.24320.55.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:13:28 +0000
In-Reply-To: <20141202151101.GG27869@laptop.dumpdata.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com>
	<20141202151101.GG27869@laptop.dumpdata.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>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 10:11 -0500, Konrad Rzeszutek Wilk wrote:
> > [0] The default i386 Debian installer falls into this camp, but you can
> > use the special PV Xen variant to install as PVHVM too so it's not so
> > critical.
> 
> And the Fedora 21 LiveISO (32-bit) does too.

Interesting, I thought Fedora had switched to requiring PAE as a minimum
baseline everywhere 

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:37:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvpVm-0001xW-WF; Tue, 02 Dec 2014 15:37: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 1XvpVl-0001xO-TX
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:37:10 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	67/CE-02576-5ACDD745; Tue, 02 Dec 2014 15:37:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417534625!12510449!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 3274 invoked from network); 2 Dec 2014 15:37:08 -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;
	2 Dec 2014 15:37:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198559334"
Message-ID: <1417533316.24320.57.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 2 Dec 2014 15:15:16 +0000
In-Reply-To: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
References: <1417533090-29651-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: Mark Pryor <tlviewer@yahoo.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-02 at 15:11 +0000, Wei Liu wrote:
> AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> incorrect, even in the event systemd library is available.  Use
> PKG_CHECK_MODULES instead.
> 
> Tested on Debian Jessie and Arch Linux.
> 
> Please rerun autogen.sh after applying this patch.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.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: Anthony Perard <anthony.perard@citrix.com>
> Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
> Cc: Mark Pryor <tlviewer@yahoo.com>

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

I think you should make reference in the commit log to the fact that the
library has change name upstream but that a compatibility pkg-config is
provided for the old name.

It'd be nice if there was a less repetitive way to handle defaults +
overriding in the autoconf stuff, but for a freeze exception this is the
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 Dec 02 15:37:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvpVm-0001xW-WF; Tue, 02 Dec 2014 15:37: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 1XvpVl-0001xO-TX
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:37:10 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	67/CE-02576-5ACDD745; Tue, 02 Dec 2014 15:37:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417534625!12510449!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 3274 invoked from network); 2 Dec 2014 15:37:08 -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;
	2 Dec 2014 15:37:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198559334"
Message-ID: <1417533316.24320.57.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 2 Dec 2014 15:15:16 +0000
In-Reply-To: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
References: <1417533090-29651-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: Mark Pryor <tlviewer@yahoo.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-02 at 15:11 +0000, Wei Liu wrote:
> AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> incorrect, even in the event systemd library is available.  Use
> PKG_CHECK_MODULES instead.
> 
> Tested on Debian Jessie and Arch Linux.
> 
> Please rerun autogen.sh after applying this patch.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.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: Anthony Perard <anthony.perard@citrix.com>
> Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
> Cc: Mark Pryor <tlviewer@yahoo.com>

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

I think you should make reference in the commit log to the fact that the
library has change name upstream but that a compatibility pkg-config is
provided for the old name.

It'd be nice if there was a less repetitive way to handle defaults +
overriding in the autoconf stuff, but for a freeze exception this is the
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 Dec 02 15:39:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:39:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpY6-00028E-HN; Tue, 02 Dec 2014 15:39:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XvpY4-000286-HV
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:39:32 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	62/A5-28296-33DDD745; Tue, 02 Dec 2014 15:39:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417534771!15276665!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 31487 invoked from network); 2 Dec 2014 15:39:31 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:39:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417534771; l=3808;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=DYHsjyCpAL1ho98bzhyRcAYeSeY=;
	b=rNFL+R4+Hbr506n6ol3kSy9fDyWT8OPm2Z+QOnEWN66Znn1UQjVSdXfW6Kj/vtq2H5D
	D8pjAbQHGyROFMSMa3SBGlgWq26xxEwjIr+WFvvyeF/nKc2Lm4JSHYYKpWFIRgkIndOYd
	4hm2/5g/WNnuN5o4nSZhTo12MCLiRXduT+g=
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.2 AUTH) with ESMTPSA id f04f85qB2FdSkr6
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 16:39:28 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 095995016D; Tue,  2 Dec 2014 16:39:27 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Tue,  2 Dec 2014 16:39:23 +0100
Message-Id: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to use
	service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
systemd xenstored dependencies") all service files use the .socket unit
as startup dependency. While this happens to work for boot it fails for
shutdown because a .socket does not seem to enforce ordering. When
xendomains.service runs during shutdown then systemd will stop
xenstored.service at the same time.

Change all "xenstored.socket" to "xenstored.service" to let systemd know
that xenstored has to be shutdown after everything else.

Reported-by: Mark Pryor <tlviewer@yahoo.com>
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---

This should go into 4.5 to fix xendomains.service.

 tools/hotplug/Linux/systemd/xen-init-dom0.service.in              | 4 ++--
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 4 ++--
 tools/hotplug/Linux/systemd/xenconsoled.service.in                | 4 ++--
 tools/hotplug/Linux/systemd/xendomains.service.in                 | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
index 4d4cb23..3befadc 100644
--- a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
+++ b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=xen-init-dom0, initialise Dom0 configuration (xenstore nodes, JSON configuration stub)
-Requires=xenstored.socket proc-xen.mount
-After=xenstored.socket proc-xen.mount
+Requires=xenstored.service proc-xen.mount
+After=xenstored.service proc-xen.mount
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]
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 6b9c96e..0a5807a 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
@@ -1,7 +1,7 @@
 [Unit]
 Description=qemu for xen dom0 disk backend
-Requires=proc-xen.mount xenstored.socket
-After=proc-xen.mount xenstored.socket xenconsoled.service
+Requires=proc-xen.mount xenstored.service
+After=proc-xen.mount xenstored.service xenconsoled.service
 Before=xendomains.service libvirtd.service libvirt-guests.service
 RefuseManualStop=true
 ConditionPathExists=/proc/xen/capabilities
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index 2c5d99f..cb44cd6 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=Xenconsoled - handles logging from guest consoles and hypervisor
-Requires=proc-xen.mount xenstored.socket
-After=proc-xen.mount xenstored.socket
+Requires=proc-xen.mount xenstored.service
+After=proc-xen.mount xenstored.service
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]
diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
index 757278f..9962671 100644
--- a/tools/hotplug/Linux/systemd/xendomains.service.in
+++ b/tools/hotplug/Linux/systemd/xendomains.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=Xendomains - start and stop guests on boot and shutdown
-Requires=proc-xen.mount xenstored.socket
-After=proc-xen.mount xenstored.socket xenconsoled.service xen-init-dom0.service
+Requires=proc-xen.mount xenstored.service
+After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:39:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:39:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpY6-00028E-HN; Tue, 02 Dec 2014 15:39:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XvpY4-000286-HV
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:39:32 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	62/A5-28296-33DDD745; Tue, 02 Dec 2014 15:39:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417534771!15276665!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 31487 invoked from network); 2 Dec 2014 15:39:31 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:39:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417534771; l=3808;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=DYHsjyCpAL1ho98bzhyRcAYeSeY=;
	b=rNFL+R4+Hbr506n6ol3kSy9fDyWT8OPm2Z+QOnEWN66Znn1UQjVSdXfW6Kj/vtq2H5D
	D8pjAbQHGyROFMSMa3SBGlgWq26xxEwjIr+WFvvyeF/nKc2Lm4JSHYYKpWFIRgkIndOYd
	4hm2/5g/WNnuN5o4nSZhTo12MCLiRXduT+g=
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.2 AUTH) with ESMTPSA id f04f85qB2FdSkr6
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 16:39:28 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 095995016D; Tue,  2 Dec 2014 16:39:27 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Tue,  2 Dec 2014 16:39:23 +0100
Message-Id: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to use
	service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
systemd xenstored dependencies") all service files use the .socket unit
as startup dependency. While this happens to work for boot it fails for
shutdown because a .socket does not seem to enforce ordering. When
xendomains.service runs during shutdown then systemd will stop
xenstored.service at the same time.

Change all "xenstored.socket" to "xenstored.service" to let systemd know
that xenstored has to be shutdown after everything else.

Reported-by: Mark Pryor <tlviewer@yahoo.com>
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---

This should go into 4.5 to fix xendomains.service.

 tools/hotplug/Linux/systemd/xen-init-dom0.service.in              | 4 ++--
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 4 ++--
 tools/hotplug/Linux/systemd/xenconsoled.service.in                | 4 ++--
 tools/hotplug/Linux/systemd/xendomains.service.in                 | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
index 4d4cb23..3befadc 100644
--- a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
+++ b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=xen-init-dom0, initialise Dom0 configuration (xenstore nodes, JSON configuration stub)
-Requires=xenstored.socket proc-xen.mount
-After=xenstored.socket proc-xen.mount
+Requires=xenstored.service proc-xen.mount
+After=xenstored.service proc-xen.mount
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]
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 6b9c96e..0a5807a 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
@@ -1,7 +1,7 @@
 [Unit]
 Description=qemu for xen dom0 disk backend
-Requires=proc-xen.mount xenstored.socket
-After=proc-xen.mount xenstored.socket xenconsoled.service
+Requires=proc-xen.mount xenstored.service
+After=proc-xen.mount xenstored.service xenconsoled.service
 Before=xendomains.service libvirtd.service libvirt-guests.service
 RefuseManualStop=true
 ConditionPathExists=/proc/xen/capabilities
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index 2c5d99f..cb44cd6 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=Xenconsoled - handles logging from guest consoles and hypervisor
-Requires=proc-xen.mount xenstored.socket
-After=proc-xen.mount xenstored.socket
+Requires=proc-xen.mount xenstored.service
+After=proc-xen.mount xenstored.service
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]
diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
index 757278f..9962671 100644
--- a/tools/hotplug/Linux/systemd/xendomains.service.in
+++ b/tools/hotplug/Linux/systemd/xendomains.service.in
@@ -1,7 +1,7 @@
 [Unit]
 Description=Xendomains - start and stop guests on boot and shutdown
-Requires=proc-xen.mount xenstored.socket
-After=proc-xen.mount xenstored.socket xenconsoled.service xen-init-dom0.service
+Requires=proc-xen.mount xenstored.service
+After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:40:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:40:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpZQ-0002Eb-0X; Tue, 02 Dec 2014 15:40:56 +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 1XvpZO-0002EP-AI
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:40:54 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	A6/18-24859-58DDD745; Tue, 02 Dec 2014 15:40:53 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417534852!15334732!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 26637 invoked from network); 2 Dec 2014 15:40:52 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-8.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 15:40:52 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 40BF51640DF;
	Tue,  2 Dec 2014 15:40:42 +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 tEB6sJKGgRGm; Tue,  2 Dec 2014 15:40:30 +0000 (GMT)
Received: from zimbra.overnetdata.com (zimbra.overnetdata.com [192.168.1.204])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 5057A16201C;
	Tue,  2 Dec 2014 15:40:30 +0000 (GMT)
Date: Tue, 2 Dec 2014 15:40:30 +0000 (GMT)
From: Anthony Wright <anthony@overnetdata.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <22601913.16.1417534830002.JavaMail.root@zimbra.overnetdata.com>
In-Reply-To: <547CB0AF.6010901@citrix.com>
MIME-Version: 1.0
X-Originating-IP: [192.168.1.31]
X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661)
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.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



----- Original Message -----
> On 01/12/14 14:22, David Vrabel wrote:
> > On 28/11/14 15:19, Anthony Wright wrote:
> > The guest's frontend driver isn't putting valid requests onto the
> > ring
> > (it crosses a page boundary) so this is a frontend bug.
> 
> This VIF protocol is weird. The first slot contains a txreq with a
> size
> for the total length of the packet, subsequent slots have sizes for
> that
> fragment only.
> 
> netback then has to calculate how long the first slot is, by
> subtracting
> all the size from the following slots.
> 
> So something has gone wrong but it's not obvious what it is. Any
> chance
> you can dump the ring state when it happens?
Really sorry, but how do I dump the ring state? I can a root shell on both the Dom0 & DomU, but I don't know the command to use to dump the ring state.

Anthony.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:40:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:40:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpZQ-0002Eb-0X; Tue, 02 Dec 2014 15:40:56 +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 1XvpZO-0002EP-AI
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 15:40:54 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	A6/18-24859-58DDD745; Tue, 02 Dec 2014 15:40:53 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417534852!15334732!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 26637 invoked from network); 2 Dec 2014 15:40:52 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-8.tower-31.messagelabs.com with SMTP;
	2 Dec 2014 15:40:52 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 40BF51640DF;
	Tue,  2 Dec 2014 15:40:42 +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 tEB6sJKGgRGm; Tue,  2 Dec 2014 15:40:30 +0000 (GMT)
Received: from zimbra.overnetdata.com (zimbra.overnetdata.com [192.168.1.204])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 5057A16201C;
	Tue,  2 Dec 2014 15:40:30 +0000 (GMT)
Date: Tue, 2 Dec 2014 15:40:30 +0000 (GMT)
From: Anthony Wright <anthony@overnetdata.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <22601913.16.1417534830002.JavaMail.root@zimbra.overnetdata.com>
In-Reply-To: <547CB0AF.6010901@citrix.com>
MIME-Version: 1.0
X-Originating-IP: [192.168.1.31]
X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661)
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.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



----- Original Message -----
> On 01/12/14 14:22, David Vrabel wrote:
> > On 28/11/14 15:19, Anthony Wright wrote:
> > The guest's frontend driver isn't putting valid requests onto the
> > ring
> > (it crosses a page boundary) so this is a frontend bug.
> 
> This VIF protocol is weird. The first slot contains a txreq with a
> size
> for the total length of the packet, subsequent slots have sizes for
> that
> fragment only.
> 
> netback then has to calculate how long the first slot is, by
> subtracting
> all the size from the following slots.
> 
> So something has gone wrong but it's not obvious what it is. Any
> chance
> you can dump the ring state when it happens?
Really sorry, but how do I dump the ring state? I can a root shell on both the Dom0 & DomU, but I don't know the command to use to dump the ring state.

Anthony.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:47:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvpfG-0002fv-7v; Tue, 02 Dec 2014 15:46:58 +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 1XvpfE-0002fq-U6
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:46:57 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	63/BF-27584-0FEDD745; Tue, 02 Dec 2014 15:46:56 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417535215!6986808!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9248 invoked from network); 2 Dec 2014 15:46:55 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2014 15:46:55 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417535215; l=370;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=9qmuqeWuHYvLeTm9X/7b+JDOn5I=;
	b=w9UQOcanibQ5xErLc3ngCtjJ91O8RtVmhAotgVjepivH0zMqBShBTo4zg0ZTVmnU9f4
	yNwcBAEDZiE41O2CV3x3D8vIz/WY6FrizqudHXjZQJVTcLFpv2YLdsnFVcD5WvCyimKId
	0OeIPIsRSbAGznsBSvtv4wm47sazSVz8U5Q=
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.2 AUTH) with ESMTPSA id d07bfeqB2FkqoDk
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 16:46:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 535B15016D; Tue,  2 Dec 2014 16:46:52 +0100 (CET)
Date: Tue, 2 Dec 2014 16:46:52 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141202154652.GA26732@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141201170151.GK3180@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, Konrad Rzeszutek Wilk wrote:

> That is odd - I see any device 'hot-plugged' being added at 00:05 and further.

Does this by any chance depend on the guest?! I mean, how is the guest
notified that a PCI device is gone (by unplug)? Maybe the pvops case
just happens to work because the unplug happens early, perhaps before
PCI discovery?!

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:47:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvpfG-0002fv-7v; Tue, 02 Dec 2014 15:46:58 +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 1XvpfE-0002fq-U6
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:46:57 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	63/BF-27584-0FEDD745; Tue, 02 Dec 2014 15:46:56 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417535215!6986808!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9248 invoked from network); 2 Dec 2014 15:46:55 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2014 15:46:55 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417535215; l=370;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=9qmuqeWuHYvLeTm9X/7b+JDOn5I=;
	b=w9UQOcanibQ5xErLc3ngCtjJ91O8RtVmhAotgVjepivH0zMqBShBTo4zg0ZTVmnU9f4
	yNwcBAEDZiE41O2CV3x3D8vIz/WY6FrizqudHXjZQJVTcLFpv2YLdsnFVcD5WvCyimKId
	0OeIPIsRSbAGznsBSvtv4wm47sazSVz8U5Q=
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.2 AUTH) with ESMTPSA id d07bfeqB2FkqoDk
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 16:46:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 535B15016D; Tue,  2 Dec 2014 16:46:52 +0100 (CET)
Date: Tue, 2 Dec 2014 16:46:52 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141202154652.GA26732@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141201170151.GK3180@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, Konrad Rzeszutek Wilk wrote:

> That is odd - I see any device 'hot-plugged' being added at 00:05 and further.

Does this by any chance depend on the guest?! I mean, how is the guest
notified that a PCI device is gone (by unplug)? Maybe the pvops case
just happens to work because the unplug happens early, perhaps before
PCI discovery?!

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:47:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1Xvpfc-0002hY-Lm; Tue, 02 Dec 2014 15:47:20 +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 1Xvpfa-0002hC-Pm
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:47:18 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	F2/C3-29352-60FDD745; Tue, 02 Dec 2014 15:47:18 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417535237!11129917!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11121 invoked from network); 2 Dec 2014 15:47:17 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:47:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417535237; l=227;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=7zSoCWEH9kYbr9er+JBxDUpT5OM=;
	b=f9rUJE5pe/J+yz3i07x1HX8QhYUZ/4gcXpm5t3BxOAxEmnTP//fnQcdAMrT5HKCkXZp
	wfk6ea7Jee0pY8VlV5KGGx/FipYiWw9aIV78FwEzxl/MViTUBoIszPlGYnRMwCrcZxYTr
	1E5vj2UXi2frNBetZxt2L1Dh/scK6UdVb+w=
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.2 AUTH) with ESMTPSA id j06569qB2FlHowI
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 16:47:17 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 1A9BB5016D; Tue,  2 Dec 2014 16:47:17 +0100 (CET)
Date: Tue, 2 Dec 2014 16:47:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141202154716.GB26732@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201134211.GA25822@aepfle.de>
	<1299044479.20141201145702@eikelenboom.it>
	<20141201143409.GA3669@aepfle.de>
	<805308753.20141201154658@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <805308753.20141201154658@eikelenboom.it>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, Sander Eikelenboom wrote:

> Monday, December 1, 2014, 3:34:09 PM, you wrote:
> > actually be a workaround for the double pci-attach bug.
> Don't know about that bug.

You just replied to it. ;-)

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:47:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1Xvpfc-0002hY-Lm; Tue, 02 Dec 2014 15:47:20 +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 1Xvpfa-0002hC-Pm
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:47:18 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	F2/C3-29352-60FDD745; Tue, 02 Dec 2014 15:47:18 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417535237!11129917!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11121 invoked from network); 2 Dec 2014 15:47:17 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 15:47:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417535237; l=227;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=7zSoCWEH9kYbr9er+JBxDUpT5OM=;
	b=f9rUJE5pe/J+yz3i07x1HX8QhYUZ/4gcXpm5t3BxOAxEmnTP//fnQcdAMrT5HKCkXZp
	wfk6ea7Jee0pY8VlV5KGGx/FipYiWw9aIV78FwEzxl/MViTUBoIszPlGYnRMwCrcZxYTr
	1E5vj2UXi2frNBetZxt2L1Dh/scK6UdVb+w=
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.2 AUTH) with ESMTPSA id j06569qB2FlHowI
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 16:47:17 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 1A9BB5016D; Tue,  2 Dec 2014 16:47:17 +0100 (CET)
Date: Tue, 2 Dec 2014 16:47:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20141202154716.GB26732@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201134211.GA25822@aepfle.de>
	<1299044479.20141201145702@eikelenboom.it>
	<20141201143409.GA3669@aepfle.de>
	<805308753.20141201154658@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <805308753.20141201154658@eikelenboom.it>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, Sander Eikelenboom wrote:

> Monday, December 1, 2014, 3:34:09 PM, you wrote:
> > actually be a workaround for the double pci-attach bug.
> Don't know about that bug.

You just replied to it. ;-)

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:53:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvplC-0002yR-FZ; Tue, 02 Dec 2014 15:53:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XvplA-0002yD-DE
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:53:04 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	C2/55-24124-F50ED745; Tue, 02 Dec 2014 15:53:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417535583!5817111!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3781 invoked from network); 2 Dec 2014 15:53:03 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2014 15:53:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417535583; l=1124;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=EEg6kLC/ZVzljeEOkRIkR4KNJ4I=;
	b=x2ciiJsTNwbnfSnZgQ8R6YwgW7Kmx6XYftM5zqnj5uh8Rl3N6J71O8Qe162GP/Q+Az8
	U/KZ5fjVXtysUz6zEWWWAPxnHFkyXDyIY6ypdUo0ukKT8/XNyBALeRfAR0qr3suxya7QF
	aMj4Mv1eDLvVPAR1IzFCVs+mJZVwo/pnVUo=
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.2 AUTH) with ESMTPSA id Y0259dqB2Fr1pWa
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 16:53:01 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id B669C5016D; Tue,  2 Dec 2014 16:53:00 +0100 (CET)
Date: Tue, 2 Dec 2014 16:53:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: qemu-devel@nongnu.org, xen-devel@lists.xen.org
Message-ID: <20141202155300.GC26732@aepfle.de>
References: <20141128154749.GA6749@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141128154749.GA6749@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [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

On Fri, Nov 28, Olaf Hering wrote:

> 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.

qemu-traditional did just close all tap devices. With qemu-upstream a
helper function exists to do all the cleanup. I think in a xen guest
there are just emulated network devices, so the "wipe all remaining"
could be done without breaking anything.


What about something like this?


Index: xen-4.4.1-testing/tools/qemu-xen-dir-remote/hw/xen/xen_platform.c
===================================================================
--- xen-4.4.1-testing.orig/tools/qemu-xen-dir-remote/hw/xen/xen_platform.c
+++ xen-4.4.1-testing/tools/qemu-xen-dir-remote/hw/xen/xen_platform.c
@@ -99,9 +99,11 @@ static void unplug_nic(PCIBus *b, PCIDev
     }
 }
 
+extern void net_cleanup(void);
 static void pci_unplug_nics(PCIBus *bus)
 {
     pci_for_each_device(bus, 0, unplug_nic, NULL);
+    net_cleanup();
 }
 
 static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)


Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:53:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvplC-0002yR-FZ; Tue, 02 Dec 2014 15:53:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XvplA-0002yD-DE
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:53:04 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	C2/55-24124-F50ED745; Tue, 02 Dec 2014 15:53:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417535583!5817111!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3781 invoked from network); 2 Dec 2014 15:53:03 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2014 15:53:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417535583; l=1124;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=EEg6kLC/ZVzljeEOkRIkR4KNJ4I=;
	b=x2ciiJsTNwbnfSnZgQ8R6YwgW7Kmx6XYftM5zqnj5uh8Rl3N6J71O8Qe162GP/Q+Az8
	U/KZ5fjVXtysUz6zEWWWAPxnHFkyXDyIY6ypdUo0ukKT8/XNyBALeRfAR0qr3suxya7QF
	aMj4Mv1eDLvVPAR1IzFCVs+mJZVwo/pnVUo=
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.2 AUTH) with ESMTPSA id Y0259dqB2Fr1pWa
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 16:53:01 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id B669C5016D; Tue,  2 Dec 2014 16:53:00 +0100 (CET)
Date: Tue, 2 Dec 2014 16:53:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: qemu-devel@nongnu.org, xen-devel@lists.xen.org
Message-ID: <20141202155300.GC26732@aepfle.de>
References: <20141128154749.GA6749@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141128154749.GA6749@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [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

On Fri, Nov 28, Olaf Hering wrote:

> 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.

qemu-traditional did just close all tap devices. With qemu-upstream a
helper function exists to do all the cleanup. I think in a xen guest
there are just emulated network devices, so the "wipe all remaining"
could be done without breaking anything.


What about something like this?


Index: xen-4.4.1-testing/tools/qemu-xen-dir-remote/hw/xen/xen_platform.c
===================================================================
--- xen-4.4.1-testing.orig/tools/qemu-xen-dir-remote/hw/xen/xen_platform.c
+++ xen-4.4.1-testing/tools/qemu-xen-dir-remote/hw/xen/xen_platform.c
@@ -99,9 +99,11 @@ static void unplug_nic(PCIBus *b, PCIDev
     }
 }
 
+extern void net_cleanup(void);
 static void pci_unplug_nics(PCIBus *bus)
 {
     pci_for_each_device(bus, 0, unplug_nic, NULL);
+    net_cleanup();
 }
 
 static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)


Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:56:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvpof-0003ED-7t; Tue, 02 Dec 2014 15:56:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xvpod-0003E6-TK
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:56:40 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	72/E0-26652-731ED745; Tue, 02 Dec 2014 15:56:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417535796!3526595!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 16158 invoked from network); 2 Dec 2014 15:56:38 -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 Dec 2014 15:56:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198911756"
Message-ID: <1417534502.24320.58.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:35:02 +0000
In-Reply-To: <20141201215416.GF24289@laptop.dumpdata.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<20141201215416.GF24289@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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 0/2] xl/libxl: fix API and 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

On Mon, 2014-12-01 at 16:54 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 11:31:11AM +0000, Wei Liu wrote:
> > Return value of libxl_basename was erroneously marked as "const". This
> > series removes that "const" and fixes two memory leaks in xl.
> > 
> > I think these fixes should be included in 4.5, given that they fix real
> > issues and are very straight foward to reason about.
> 
> Thank you for catching those!
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied both, including the modification discussed in my reply to the
second.

> > 
> > Wei.
> > 
> > Wei Liu (2):
> >   libxl: un-constify return value of libxl_basename
> >   xl: fix two memory leaks
> > 
> >  tools/libxl/libxl.h       |   10 ++++++++++
> >  tools/libxl/libxl_utils.c |    5 ++++-
> >  tools/libxl/libxl_utils.h |    6 +++++-
> >  tools/libxl/xl_cmdimpl.c  |    8 ++++++--
> >  4 files changed, 25 insertions(+), 4 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 Tue Dec 02 15:56:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvpof-0003ED-7t; Tue, 02 Dec 2014 15:56:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xvpod-0003E6-TK
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:56:40 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	72/E0-26652-731ED745; Tue, 02 Dec 2014 15:56:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417535796!3526595!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 16158 invoked from network); 2 Dec 2014 15:56:38 -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 Dec 2014 15:56:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198911756"
Message-ID: <1417534502.24320.58.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:35:02 +0000
In-Reply-To: <20141201215416.GF24289@laptop.dumpdata.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<20141201215416.GF24289@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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 0/2] xl/libxl: fix API and 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

On Mon, 2014-12-01 at 16:54 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 11:31:11AM +0000, Wei Liu wrote:
> > Return value of libxl_basename was erroneously marked as "const". This
> > series removes that "const" and fixes two memory leaks in xl.
> > 
> > I think these fixes should be included in 4.5, given that they fix real
> > issues and are very straight foward to reason about.
> 
> Thank you for catching those!
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied both, including the modification discussed in my reply to the
second.

> > 
> > Wei.
> > 
> > Wei Liu (2):
> >   libxl: un-constify return value of libxl_basename
> >   xl: fix two memory leaks
> > 
> >  tools/libxl/libxl.h       |   10 ++++++++++
> >  tools/libxl/libxl_utils.c |    5 ++++-
> >  tools/libxl/libxl_utils.h |    6 +++++-
> >  tools/libxl/xl_cmdimpl.c  |    8 ++++++--
> >  4 files changed, 25 insertions(+), 4 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 Tue Dec 02 15:57:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvppM-0003IC-LO; Tue, 02 Dec 2014 15:57: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 1XvppL-0003I1-3a
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:57:23 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	2F/64-02696-261ED745; Tue, 02 Dec 2014 15:57:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417535840!12495249!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8043 invoked from network); 2 Dec 2014 15:57:21 -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;
	2 Dec 2014 15:57:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198912415"
Message-ID: <1417534552.24320.60.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:35:52 +0000
In-Reply-To: <20141201215112.GE24289@laptop.dumpdata.com>
References: <1417154122-23669-1-git-send-email-cyliu@suse.com>
	<1417176083.23604.20.camel@citrix.com>
	<547CBFB80200006600040E25@soto.provo.novell.com>
	<1417425684.23604.70.camel@citrix.com>
	<20141201215112.GE24289@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
Content-Length: 3206
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,
	Chun Yan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] =?utf-8?b?562U5aSN77yaIFJlOiBbUEFUQ0hdIG1pc3Npbmcg?=
 =?utf-8?q?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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDE0LTEyLTAxIGF0IDE2OjUxIC0wNTAwLCBLb25yYWQgUnplc3p1dGVrIFdpbGsg
d3JvdGU6Cj4gT24gTW9uLCBEZWMgMDEsIDIwMTQgYXQgMDk6MjE6MjRBTSArMDAwMCwgSWFuIENh
bXBiZWxsIHdyb3RlOgo+ID4gT24gTW9uLCAyMDE0LTEyLTAxIGF0IDAxOjIxIC0wNzAwLCBDaHVu
IFlhbiBMaXUgd3JvdGU6Cj4gPiA+IAo+ID4gPiA+Pj4gSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJl
bGxAY2l0cml4LmNvbT4gMjAxNC0xMS0yOCDkuIvljYggMjA6MDEgPj4+IAo+ID4gPiBPbiBGcmks
IDIwMTQtMTEtMjggYXQgMTM6NTUgKzA4MDAsIENodW55YW4gTGl1IHdyb3RlOiAKPiA+ID4gPj4g
Rm91bmQgYnkgU3RlZmFubywgdGhpcyBjaHVuayBvZiB0aGUgcGF0Y2ggd2FzIG5ldmVyIGFwcGxp
ZWQgdG8gCj4gPiA+ID4+IHhlbi11bnN0YWJsZSAoY29tbWl0IDExZGZmYTIzNTllOGEyNjI5NDkw
YzE0YzAyOWM3YzdjNzc3YjNlNDcpLCAKPiA+ID4gPj4gc2VlIGh0dHA6Ly9tYXJjLmluZm8vP2w9
cWVtdS1kZXZlbCZtPTE0MDQ3MTQ5MzQyNTM1MyZ3PTIuIAo+ID4gPiA+Cj4gPiA+ID4gSG93IHN0
cmFuZ2UsICJnaXQgYW0iIHVzdWFsbHkgbWFrZXMgaXQgcHJldHR5IGRpZmZpY3VsdCB0byBtaXNz
IGh1bmtzLiAKPiA+ID4gPiBTb3JyeSBhYm91dCB0aGlzLiAKPiA+ID4gCj4gPiA+ID4+IFNpZ25l
ZC1vZmYtYnk6IENodW55YW4gTGl1IDxjeWxpdUBzdXNlLmNvbT4gCj4gPiA+IAo+ID4gPiA+IEFj
a2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPiAKPiA+ID4gCj4g
PiA+ID4gSSdtIGFmcmFpZCB0aGF0IGRlc3BpdGUgdGhlIGNpcmN1bXN0YW5jZXMgdGhpcyBzdGls
bCBuZWVkcyBhIHJlbGVhc2UgYWNrIAo+ID4gPiA+IGZyb20gS29ucmFkLiBPYnZpb3VzbHkgdGhl
IHVwc2lkZSBpcyBmaXhpbmcgYSBwYXJ0aWFsbHkgaW1wbGVtZW50ZWQgCj4gPiA+ID4gZmVhdHVy
ZSwgYnV0IEknbSBub3Qgc3VyZSB3aGF0IHRoZSBkb3duc2lkZXMgYXJlLiAKPiA+ID4gPgo+ID4g
PiA+IEhhcyB0aGlzIGJlZW4gdGVzdGVkIHdpdGggc3R1YmRvbXMsIGluY2x1ZGluZyB3aGVuIHRo
aXMgZmVhdHVyZSBpcyBub3QgCj4gPiA+ID4gdXNlZD8gTXkgYmlnZ2VzdCBjb25jZXJuIGlzIHRo
YXQgYmVjYXVzZSB0aGlzIGZ1bmN0aW9uIGlzIGFsc28gdXNlZCB0byAKPiA+ID4gPiBidWlsZCB0
aGUgY29tbWFuZCBsaW5lIGZvciB0aGUgc3R1YmRvbSBhbmQgdGhlIHN0dWJkb20gaXMgUFYgYW5k
IGhlbmNlIAo+ID4gPiA+IGhhcyBhdCBsZWFzdCBhIC0+a2VybmVsIHNldHRpbmcgdGhlbiB0aGlz
IG5ldyBjb2RlIG1pZ2h0IGJyZWFrIHRoYXQgdXNlIAo+ID4gPiA+IGNhc2UsIGJ5IGFkZGluZyB0
aGVzZSBvcHRpb25zIHdoZW4gdGhleSBhcmUgbm90IHdhbnRlZC4gVGhpcyBwYXRoIGlzIGFsbCAK
PiA+ID4gPiBhIGJpdCB0YW5nbGVkIHNvIEknbSBub3QgMTAwJSBzdXJlIGlmIHRob3NlIGZpZWxk
cyBhcmUgYWN0dWFsbHkgc2V0IG9yIAo+ID4gPiA+IG5vdC4KPiA+ID4gCj4gPiA+IAo+ID4gPiAK
PiA+ID4gJy1rZXJuZWwnIGlzIG9ubHkgYWRkZWQgdG8gcWVtdSBjb21tYW5kIGxpbmUgdW5kZXIg
SFZNIGNhc2UuIFBWIHdvdWxkCj4gPiA+IAo+ID4gPiBub3QgYmUgYWZmZWN0ZWQuIEFuZCBvbmx5
IGFkZGVkIHdoZW4gZGV2aWNlIG1vZGVsIGlzIHVwc3RyZWFtIHFlbXUsIGJ1dAo+ID4gPiAKPiA+
ID4gbm90IG9sZCBxZW11LXhlbi4gQWJvdXQgc3R1YmRvbSwgdGVzdGVkIGJlZm9yZSwgd2hlbiBz
dHViZG9tIGlzIHVzaW5nCj4gPiAKPiA+ID4gb2xkIHFlbXUteGVuLCB3b3VsZCBub3QgYmUgYWZm
ZWN0ZWQuCj4gPiAKPiA+IEFoIHllcywgSSdkIGZvcmdvdHRlbiB3ZSBkaWRuJ3QgaGF2ZSB1cHN0
cmVhbSBzdHViZG9tIHlldCwgb2J2aW91c2x5IGFueQo+ID4gaXNzdWVzIGhlcmUgd2lsbCBiZWNv
bWUgYXBwYXJlbnQgd2hlbmV2ZXIgdGhhdCBnZXRzIGltcGxlbWVudGVkLgo+IAo+IDxub2RzPgo+
IAo+IFJlbGVhc2UtQWNrZWQtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtA
b3JhY2xlLmNvbT4KCkFwcGxpZWQsIHRoYW5rcy4KCj4gPiAKPiA+IElhbi4KPiA+IAo+ID4gCj4g
Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:57:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15: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 1XvppM-0003IC-LO; Tue, 02 Dec 2014 15:57: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 1XvppL-0003I1-3a
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:57:23 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	2F/64-02696-261ED745; Tue, 02 Dec 2014 15:57:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417535840!12495249!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8043 invoked from network); 2 Dec 2014 15:57:21 -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;
	2 Dec 2014 15:57:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198912415"
Message-ID: <1417534552.24320.60.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:35:52 +0000
In-Reply-To: <20141201215112.GE24289@laptop.dumpdata.com>
References: <1417154122-23669-1-git-send-email-cyliu@suse.com>
	<1417176083.23604.20.camel@citrix.com>
	<547CBFB80200006600040E25@soto.provo.novell.com>
	<1417425684.23604.70.camel@citrix.com>
	<20141201215112.GE24289@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
Content-Length: 3206
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,
	Chun Yan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] =?utf-8?b?562U5aSN77yaIFJlOiBbUEFUQ0hdIG1pc3Npbmcg?=
 =?utf-8?q?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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDE0LTEyLTAxIGF0IDE2OjUxIC0wNTAwLCBLb25yYWQgUnplc3p1dGVrIFdpbGsg
d3JvdGU6Cj4gT24gTW9uLCBEZWMgMDEsIDIwMTQgYXQgMDk6MjE6MjRBTSArMDAwMCwgSWFuIENh
bXBiZWxsIHdyb3RlOgo+ID4gT24gTW9uLCAyMDE0LTEyLTAxIGF0IDAxOjIxIC0wNzAwLCBDaHVu
IFlhbiBMaXUgd3JvdGU6Cj4gPiA+IAo+ID4gPiA+Pj4gSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJl
bGxAY2l0cml4LmNvbT4gMjAxNC0xMS0yOCDkuIvljYggMjA6MDEgPj4+IAo+ID4gPiBPbiBGcmks
IDIwMTQtMTEtMjggYXQgMTM6NTUgKzA4MDAsIENodW55YW4gTGl1IHdyb3RlOiAKPiA+ID4gPj4g
Rm91bmQgYnkgU3RlZmFubywgdGhpcyBjaHVuayBvZiB0aGUgcGF0Y2ggd2FzIG5ldmVyIGFwcGxp
ZWQgdG8gCj4gPiA+ID4+IHhlbi11bnN0YWJsZSAoY29tbWl0IDExZGZmYTIzNTllOGEyNjI5NDkw
YzE0YzAyOWM3YzdjNzc3YjNlNDcpLCAKPiA+ID4gPj4gc2VlIGh0dHA6Ly9tYXJjLmluZm8vP2w9
cWVtdS1kZXZlbCZtPTE0MDQ3MTQ5MzQyNTM1MyZ3PTIuIAo+ID4gPiA+Cj4gPiA+ID4gSG93IHN0
cmFuZ2UsICJnaXQgYW0iIHVzdWFsbHkgbWFrZXMgaXQgcHJldHR5IGRpZmZpY3VsdCB0byBtaXNz
IGh1bmtzLiAKPiA+ID4gPiBTb3JyeSBhYm91dCB0aGlzLiAKPiA+ID4gCj4gPiA+ID4+IFNpZ25l
ZC1vZmYtYnk6IENodW55YW4gTGl1IDxjeWxpdUBzdXNlLmNvbT4gCj4gPiA+IAo+ID4gPiA+IEFj
a2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPiAKPiA+ID4gCj4g
PiA+ID4gSSdtIGFmcmFpZCB0aGF0IGRlc3BpdGUgdGhlIGNpcmN1bXN0YW5jZXMgdGhpcyBzdGls
bCBuZWVkcyBhIHJlbGVhc2UgYWNrIAo+ID4gPiA+IGZyb20gS29ucmFkLiBPYnZpb3VzbHkgdGhl
IHVwc2lkZSBpcyBmaXhpbmcgYSBwYXJ0aWFsbHkgaW1wbGVtZW50ZWQgCj4gPiA+ID4gZmVhdHVy
ZSwgYnV0IEknbSBub3Qgc3VyZSB3aGF0IHRoZSBkb3duc2lkZXMgYXJlLiAKPiA+ID4gPgo+ID4g
PiA+IEhhcyB0aGlzIGJlZW4gdGVzdGVkIHdpdGggc3R1YmRvbXMsIGluY2x1ZGluZyB3aGVuIHRo
aXMgZmVhdHVyZSBpcyBub3QgCj4gPiA+ID4gdXNlZD8gTXkgYmlnZ2VzdCBjb25jZXJuIGlzIHRo
YXQgYmVjYXVzZSB0aGlzIGZ1bmN0aW9uIGlzIGFsc28gdXNlZCB0byAKPiA+ID4gPiBidWlsZCB0
aGUgY29tbWFuZCBsaW5lIGZvciB0aGUgc3R1YmRvbSBhbmQgdGhlIHN0dWJkb20gaXMgUFYgYW5k
IGhlbmNlIAo+ID4gPiA+IGhhcyBhdCBsZWFzdCBhIC0+a2VybmVsIHNldHRpbmcgdGhlbiB0aGlz
IG5ldyBjb2RlIG1pZ2h0IGJyZWFrIHRoYXQgdXNlIAo+ID4gPiA+IGNhc2UsIGJ5IGFkZGluZyB0
aGVzZSBvcHRpb25zIHdoZW4gdGhleSBhcmUgbm90IHdhbnRlZC4gVGhpcyBwYXRoIGlzIGFsbCAK
PiA+ID4gPiBhIGJpdCB0YW5nbGVkIHNvIEknbSBub3QgMTAwJSBzdXJlIGlmIHRob3NlIGZpZWxk
cyBhcmUgYWN0dWFsbHkgc2V0IG9yIAo+ID4gPiA+IG5vdC4KPiA+ID4gCj4gPiA+IAo+ID4gPiAK
PiA+ID4gJy1rZXJuZWwnIGlzIG9ubHkgYWRkZWQgdG8gcWVtdSBjb21tYW5kIGxpbmUgdW5kZXIg
SFZNIGNhc2UuIFBWIHdvdWxkCj4gPiA+IAo+ID4gPiBub3QgYmUgYWZmZWN0ZWQuIEFuZCBvbmx5
IGFkZGVkIHdoZW4gZGV2aWNlIG1vZGVsIGlzIHVwc3RyZWFtIHFlbXUsIGJ1dAo+ID4gPiAKPiA+
ID4gbm90IG9sZCBxZW11LXhlbi4gQWJvdXQgc3R1YmRvbSwgdGVzdGVkIGJlZm9yZSwgd2hlbiBz
dHViZG9tIGlzIHVzaW5nCj4gPiAKPiA+ID4gb2xkIHFlbXUteGVuLCB3b3VsZCBub3QgYmUgYWZm
ZWN0ZWQuCj4gPiAKPiA+IEFoIHllcywgSSdkIGZvcmdvdHRlbiB3ZSBkaWRuJ3QgaGF2ZSB1cHN0
cmVhbSBzdHViZG9tIHlldCwgb2J2aW91c2x5IGFueQo+ID4gaXNzdWVzIGhlcmUgd2lsbCBiZWNv
bWUgYXBwYXJlbnQgd2hlbmV2ZXIgdGhhdCBnZXRzIGltcGxlbWVudGVkLgo+IAo+IDxub2RzPgo+
IAo+IFJlbGVhc2UtQWNrZWQtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtA
b3JhY2xlLmNvbT4KCkFwcGxpZWQsIHRoYW5rcy4KCj4gPiAKPiA+IElhbi4KPiA+IAo+ID4gCj4g
Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:57:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvppV-0003Js-1D; Tue, 02 Dec 2014 15: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.Campbell@citrix.com>) id 1XvppT-0003JW-NU
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:57:31 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	2B/46-17735-B61ED745; Tue, 02 Dec 2014 15:57:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417535847!15353577!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14368 invoked from network); 2 Dec 2014 15:57:30 -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;
	2 Dec 2014 15:57:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198912617"
Message-ID: <1417534566.24320.61.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:36:06 +0000
In-Reply-To: <20141201211653.GI22021@laptop.dumpdata.com>
References: <1417177608-6705-1-git-send-email-rcojocaru@bitdefender.com>
	<21624.27430.789784.210615@mariner.uk.xensource.com>
	<20141201211653.GI22021@laptop.dumpdata.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, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	wei.liu2@citrix.com, Razvan Cojocaru <rcojocaru@bitdefender.com>,
	stefano.stabellini@eu.citrix.com
Subject: Re: [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

On Mon, 2014-12-01 at 16:16 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 28, 2014 at 12:31:34PM +0000, Ian Jackson wrote:
> > 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>
> 
> It is documentation per say so it can go in ..

Applied.


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:57:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvppV-0003Js-1D; Tue, 02 Dec 2014 15: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.Campbell@citrix.com>) id 1XvppT-0003JW-NU
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:57:31 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	2B/46-17735-B61ED745; Tue, 02 Dec 2014 15:57:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417535847!15353577!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14368 invoked from network); 2 Dec 2014 15:57:30 -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;
	2 Dec 2014 15:57:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198912617"
Message-ID: <1417534566.24320.61.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:36:06 +0000
In-Reply-To: <20141201211653.GI22021@laptop.dumpdata.com>
References: <1417177608-6705-1-git-send-email-rcojocaru@bitdefender.com>
	<21624.27430.789784.210615@mariner.uk.xensource.com>
	<20141201211653.GI22021@laptop.dumpdata.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, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	wei.liu2@citrix.com, Razvan Cojocaru <rcojocaru@bitdefender.com>,
	stefano.stabellini@eu.citrix.com
Subject: Re: [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

On Mon, 2014-12-01 at 16:16 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 28, 2014 at 12:31:34PM +0000, Ian Jackson wrote:
> > 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>
> 
> It is documentation per say so it can go in ..

Applied.


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:58:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:58:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpqP-0003Td-GF; Tue, 02 Dec 2014 15:58: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 1XvpqO-0003TV-S8
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:58:28 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	31/AF-28296-4A1ED745; Tue, 02 Dec 2014 15:58:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417535905!15282367!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17609 invoked from network); 2 Dec 2014 15:58: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;
	2 Dec 2014 15:58:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198912911"
Message-ID: <1417534590.29004.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:36:30 +0000
In-Reply-To: <20141201202545.GB21626@laptop.dumpdata.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>
	<21624.25082.6881.622482@mariner.uk.xensource.com>
	<20141201202545.GB21626@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>,
	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,
	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

On Mon, 2014-12-01 at 15:25 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 28, 2014 at 11:52:26AM +0000, Ian Jackson wrote:
> > 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.
> 
> Correct.
> 
> 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 Dec 02 15:58:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:58:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpqP-0003Td-GF; Tue, 02 Dec 2014 15:58: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 1XvpqO-0003TV-S8
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 15:58:28 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	31/AF-28296-4A1ED745; Tue, 02 Dec 2014 15:58:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417535905!15282367!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17609 invoked from network); 2 Dec 2014 15:58: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;
	2 Dec 2014 15:58:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198912911"
Message-ID: <1417534590.29004.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:36:30 +0000
In-Reply-To: <20141201202545.GB21626@laptop.dumpdata.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>
	<21624.25082.6881.622482@mariner.uk.xensource.com>
	<20141201202545.GB21626@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>,
	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,
	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

On Mon, 2014-12-01 at 15:25 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 28, 2014 at 11:52:26AM +0000, Ian Jackson wrote:
> > 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.
> 
> Correct.
> 
> 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 Dec 02 15:59:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:59:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvpqs-0003YN-TP; Tue, 02 Dec 2014 15:58: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 1Xvpqr-0003Y5-NS
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:58:57 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	A9/77-07724-1C1ED745; Tue, 02 Dec 2014 15:58:57 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417535936!15263019!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 7875 invoked from network); 2 Dec 2014 15:58:56 -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; 2 Dec 2014 15:58:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 15:58:56 +0000
Message-Id: <547DE1BD02000078000C2DEF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 15:58:53 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <xen-devel@lists.xenproject.org>,<daniel.kiper@oracle.com>
References: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] console: increase initial
	conring 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

>>> Daniel Kiper <daniel.kiper@oracle.com> 12/02/14 3:58 PM >>>
>In general initial conring size is sufficient. However, if log
>level is increased on platforms which have e.g. huge number
>of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
>which has more than 200 entries in EFI memory map) then some
>of earlier messages in console ring are overwritten. It means
>that in case of issues deeper analysis can be hindered. Sadly
>conring_size argument does not help because new console buffer
>is allocated late on heap. It means that it is not possible to
>allocate larger ring earlier. So, in this situation initial
>conring size should be increased. My experiments showed that
>even on not so big machines more than 26 KiB of free space are
>needed for initial messages. In theory we could increase conring
>size buffer to 32 KiB. However, I think that this value could be
>too small for huge machines with large number of ACPI tables and
>EFI memory regions. Hence, this patch increases initial conring
>size to 64 KiB.
>
>Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

I think it was made clear before that just saying "for-xen-4.5" without any
further rationale is insufficient. Please explain what makes this so important
a change that it needs to go in now.

Apart from that, as Olaf validly replied, setting up a dynamically allocated
buffer earlier would seem like a much better course of action.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 15:59:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 15:59:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvpqs-0003YN-TP; Tue, 02 Dec 2014 15:58: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 1Xvpqr-0003Y5-NS
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:58:57 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	A9/77-07724-1C1ED745; Tue, 02 Dec 2014 15:58:57 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417535936!15263019!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 7875 invoked from network); 2 Dec 2014 15:58:56 -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; 2 Dec 2014 15:58:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 15:58:56 +0000
Message-Id: <547DE1BD02000078000C2DEF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 15:58:53 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <xen-devel@lists.xenproject.org>,<daniel.kiper@oracle.com>
References: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] console: increase initial
	conring 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

>>> Daniel Kiper <daniel.kiper@oracle.com> 12/02/14 3:58 PM >>>
>In general initial conring size is sufficient. However, if log
>level is increased on platforms which have e.g. huge number
>of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
>which has more than 200 entries in EFI memory map) then some
>of earlier messages in console ring are overwritten. It means
>that in case of issues deeper analysis can be hindered. Sadly
>conring_size argument does not help because new console buffer
>is allocated late on heap. It means that it is not possible to
>allocate larger ring earlier. So, in this situation initial
>conring size should be increased. My experiments showed that
>even on not so big machines more than 26 KiB of free space are
>needed for initial messages. In theory we could increase conring
>size buffer to 32 KiB. However, I think that this value could be
>too small for huge machines with large number of ACPI tables and
>EFI memory regions. Hence, this patch increases initial conring
>size to 64 KiB.
>
>Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

I think it was made clear before that just saying "for-xen-4.5" without any
further rationale is insufficient. Please explain what makes this so important
a change that it needs to go in now.

Apart from that, as Olaf validly replied, setting up a dynamically allocated
buffer earlier would seem like a much better course of action.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:00:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpsS-00043x-0a; Tue, 02 Dec 2014 16:00:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1XvpsP-00043e-G8; Tue, 02 Dec 2014 16:00:33 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	FC/CA-09284-022ED745; Tue, 02 Dec 2014 16:00:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417536028!11589242!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15139 invoked from network); 2 Dec 2014 16:00: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;
	2 Dec 2014 16:00:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198914758"
Message-ID: <1417534760.29004.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 2 Dec 2014 15:39:20 +0000
In-Reply-To: <20141202151708.GA23112@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.com>, 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>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 16:17 +0100, Olaf Hering wrote:
> On Tue, Dec 02, Ian Campbell wrote:
> 
> > On Mon, 2014-12-01 at 23:41 +0000, Mark Pryor wrote:
> > > list,
> > 
> > Thanks. If you've identified a buggy changeset then it is fine to post
> > to the devel lists. I've added a CC. I've also CCd everyone listed in
> > the commit which you've fingered.
> > 
> > Olaf, does this suggested change look correct? If so then can you turn
> > it into a patch please.
> 
> Yes, something like this (sed -i 's@socket@service@g' *.in):

Can you submit to -devel with a commit log and S-o-b etc please.

> 
> 
> diff --git a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> index 4d4cb23..3befadc 100644
> --- a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> +++ b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=xen-init-dom0, initialise Dom0 configuration (xenstore nodes, JSON configuration stub)
> -Requires=xenstored.socket proc-xen.mount
> -After=xenstored.socket proc-xen.mount
> +Requires=xenstored.service proc-xen.mount
> +After=xenstored.service proc-xen.mount
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
> 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 6b9c96e..0a5807a 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
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=qemu for xen dom0 disk backend
> -Requires=proc-xen.mount xenstored.socket
> -After=proc-xen.mount xenstored.socket xenconsoled.service
> +Requires=proc-xen.mount xenstored.service
> +After=proc-xen.mount xenstored.service xenconsoled.service
>  Before=xendomains.service libvirtd.service libvirt-guests.service
>  RefuseManualStop=true
>  ConditionPathExists=/proc/xen/capabilities
> diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> index 2c5d99f..cb44cd6 100644
> --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=Xenconsoled - handles logging from guest consoles and hypervisor
> -Requires=proc-xen.mount xenstored.socket
> -After=proc-xen.mount xenstored.socket
> +Requires=proc-xen.mount xenstored.service
> +After=proc-xen.mount xenstored.service
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
> diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
> index 757278f..9962671 100644
> --- a/tools/hotplug/Linux/systemd/xendomains.service.in
> +++ b/tools/hotplug/Linux/systemd/xendomains.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=Xendomains - start and stop guests on boot and shutdown
> -Requires=proc-xen.mount xenstored.socket
> -After=proc-xen.mount xenstored.socket xenconsoled.service xen-init-dom0.service
> +Requires=proc-xen.mount xenstored.service
> +After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 02 16:00:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpsS-00043x-0a; Tue, 02 Dec 2014 16:00:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1XvpsP-00043e-G8; Tue, 02 Dec 2014 16:00:33 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	FC/CA-09284-022ED745; Tue, 02 Dec 2014 16:00:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417536028!11589242!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15139 invoked from network); 2 Dec 2014 16:00: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;
	2 Dec 2014 16:00:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198914758"
Message-ID: <1417534760.29004.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 2 Dec 2014 15:39:20 +0000
In-Reply-To: <20141202151708.GA23112@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.com>, 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>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 16:17 +0100, Olaf Hering wrote:
> On Tue, Dec 02, Ian Campbell wrote:
> 
> > On Mon, 2014-12-01 at 23:41 +0000, Mark Pryor wrote:
> > > list,
> > 
> > Thanks. If you've identified a buggy changeset then it is fine to post
> > to the devel lists. I've added a CC. I've also CCd everyone listed in
> > the commit which you've fingered.
> > 
> > Olaf, does this suggested change look correct? If so then can you turn
> > it into a patch please.
> 
> Yes, something like this (sed -i 's@socket@service@g' *.in):

Can you submit to -devel with a commit log and S-o-b etc please.

> 
> 
> diff --git a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> index 4d4cb23..3befadc 100644
> --- a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> +++ b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=xen-init-dom0, initialise Dom0 configuration (xenstore nodes, JSON configuration stub)
> -Requires=xenstored.socket proc-xen.mount
> -After=xenstored.socket proc-xen.mount
> +Requires=xenstored.service proc-xen.mount
> +After=xenstored.service proc-xen.mount
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
> 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 6b9c96e..0a5807a 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
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=qemu for xen dom0 disk backend
> -Requires=proc-xen.mount xenstored.socket
> -After=proc-xen.mount xenstored.socket xenconsoled.service
> +Requires=proc-xen.mount xenstored.service
> +After=proc-xen.mount xenstored.service xenconsoled.service
>  Before=xendomains.service libvirtd.service libvirt-guests.service
>  RefuseManualStop=true
>  ConditionPathExists=/proc/xen/capabilities
> diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> index 2c5d99f..cb44cd6 100644
> --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=Xenconsoled - handles logging from guest consoles and hypervisor
> -Requires=proc-xen.mount xenstored.socket
> -After=proc-xen.mount xenstored.socket
> +Requires=proc-xen.mount xenstored.service
> +After=proc-xen.mount xenstored.service
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
> diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
> index 757278f..9962671 100644
> --- a/tools/hotplug/Linux/systemd/xendomains.service.in
> +++ b/tools/hotplug/Linux/systemd/xendomains.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=Xendomains - start and stop guests on boot and shutdown
> -Requires=proc-xen.mount xenstored.socket
> -After=proc-xen.mount xenstored.socket xenconsoled.service xen-init-dom0.service
> +Requires=proc-xen.mount xenstored.service
> +After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 02 16:01:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:01:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvptb-0004N2-Pt; Tue, 02 Dec 2014 16:01: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 1Xvpta-0004Mk-9x
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:01:46 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	C1/81-25727-962ED745; Tue, 02 Dec 2014 16:01:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417536100!15263919!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 32312 invoked from network); 2 Dec 2014 16:01: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;
	2 Dec 2014 16:01:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198581191"
Message-ID: <1417534533.24320.59.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:35:33 +0000
In-Reply-To: <20141201220242.GI24289@laptop.dumpdata.com>
References: <1417444026-31044-1-git-send-email-euan.harris@citrix.com>
	<1417445456.29138.33.camel@citrix.com>
	<20141201220242.GI24289@laptop.dumpdata.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, Euan Harris <euan.harris@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Don't derefence null new_name
 pointer in libxl_domain_rename()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-01 at 17:02 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 02:50:56PM +0000, Ian Campbell wrote:
> > On Mon, 2014-12-01 at 14:27 +0000, Euan Harris wrote:
> > > libxl__domain_rename() unconditionally dereferences its new_name
> > > parameter, to check whether it is an empty string.   Add a check to
> > > avoid a segfault if new_name is null.
> > > 
> > > Signed-off-by: Euan Harris <euan.harris@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > I think this is a good fix to have for 4.5, Konrad CCd.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied, fixing the typo in the subject as I went.



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:01:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:01:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvptb-0004N2-Pt; Tue, 02 Dec 2014 16:01: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 1Xvpta-0004Mk-9x
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:01:46 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	C1/81-25727-962ED745; Tue, 02 Dec 2014 16:01:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417536100!15263919!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 32312 invoked from network); 2 Dec 2014 16:01: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;
	2 Dec 2014 16:01:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198581191"
Message-ID: <1417534533.24320.59.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:35:33 +0000
In-Reply-To: <20141201220242.GI24289@laptop.dumpdata.com>
References: <1417444026-31044-1-git-send-email-euan.harris@citrix.com>
	<1417445456.29138.33.camel@citrix.com>
	<20141201220242.GI24289@laptop.dumpdata.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, Euan Harris <euan.harris@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: Don't derefence null new_name
 pointer in libxl_domain_rename()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-01 at 17:02 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 02:50:56PM +0000, Ian Campbell wrote:
> > On Mon, 2014-12-01 at 14:27 +0000, Euan Harris wrote:
> > > libxl__domain_rename() unconditionally dereferences its new_name
> > > parameter, to check whether it is an empty string.   Add a check to
> > > avoid a segfault if new_name is null.
> > > 
> > > Signed-off-by: Euan Harris <euan.harris@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > I think this is a good fix to have for 4.5, Konrad CCd.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied, fixing the typo in the subject as I went.



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:03:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:03:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvpup-0004Ys-CC; Tue, 02 Dec 2014 16:03:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xvpun-0004Yd-GO
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:03:01 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	8B/D4-02954-4B2ED745; Tue, 02 Dec 2014 16:03:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417536178!12523380!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 24505 invoked from network); 2 Dec 2014 16:03:00 -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;
	2 Dec 2014 16:03:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198583202"
Message-ID: <1417534629.29004.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>
Date: Tue, 2 Dec 2014 15:37:09 +0000
In-Reply-To: <1417432541.29138.8.camel@citrix.com>
References: <1417430853-26347-1-git-send-email-euan.harris@citrix.com>
	<1417432541.29138.8.camel@citrix.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] libxl: libxl_domain_info: fix typo in error
 message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-01 at 11:15 +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 10:47 +0000, Euan Harris wrote:
> > Signed-off-by: Euan Harris <euan.harris@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> This is so trivial as to not need a release ack IMHO, I'll apply next
> time I'm doing such things unless someone beats me to it...

Done.



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:03:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:03:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvpup-0004Ys-CC; Tue, 02 Dec 2014 16:03:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xvpun-0004Yd-GO
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:03:01 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	8B/D4-02954-4B2ED745; Tue, 02 Dec 2014 16:03:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417536178!12523380!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 24505 invoked from network); 2 Dec 2014 16:03:00 -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;
	2 Dec 2014 16:03:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198583202"
Message-ID: <1417534629.29004.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Euan Harris <euan.harris@citrix.com>
Date: Tue, 2 Dec 2014 15:37:09 +0000
In-Reply-To: <1417432541.29138.8.camel@citrix.com>
References: <1417430853-26347-1-git-send-email-euan.harris@citrix.com>
	<1417432541.29138.8.camel@citrix.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] libxl: libxl_domain_info: fix typo in error
 message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-01 at 11:15 +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 10:47 +0000, Euan Harris wrote:
> > Signed-off-by: Euan Harris <euan.harris@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> This is so trivial as to not need a release ack IMHO, I'll apply next
> time I'm doing such things unless someone beats me to it...

Done.



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:06:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1Xvpxp-0004rT-1e; Tue, 02 Dec 2014 16:06:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xvpxn-0004rI-V1
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:06:08 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	EC/A0-25547-F63ED745; Tue, 02 Dec 2014 16:06:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417536364!15342288!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21322 invoked from network); 2 Dec 2014 16:06:06 -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;
	2 Dec 2014 16:06:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198918007"
Message-ID: <1417535095.29004.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:44:55 +0000
In-Reply-To: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
References: <1417534763-25053-1-git-send-email-olaf@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] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
> Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
> systemd xenstored dependencies") all service files use the .socket unit
> as startup dependency. While this happens to work for boot it fails for
> shutdown because a .socket does not seem to enforce ordering. When
> xendomains.service runs during shutdown then systemd will stop
> xenstored.service at the same time.
> 
> Change all "xenstored.socket" to "xenstored.service" to let systemd know
> that xenstored has to be shutdown after everything else.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.com>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

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

> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
> 
> This should go into 4.5 to fix xendomains.service.

CCing Konrad...

> 
>  tools/hotplug/Linux/systemd/xen-init-dom0.service.in              | 4 ++--
>  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 4 ++--
>  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 4 ++--
>  tools/hotplug/Linux/systemd/xendomains.service.in                 | 4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> index 4d4cb23..3befadc 100644
> --- a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> +++ b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=xen-init-dom0, initialise Dom0 configuration (xenstore nodes, JSON configuration stub)
> -Requires=xenstored.socket proc-xen.mount
> -After=xenstored.socket proc-xen.mount
> +Requires=xenstored.service proc-xen.mount
> +After=xenstored.service proc-xen.mount
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
> 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 6b9c96e..0a5807a 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
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=qemu for xen dom0 disk backend
> -Requires=proc-xen.mount xenstored.socket
> -After=proc-xen.mount xenstored.socket xenconsoled.service
> +Requires=proc-xen.mount xenstored.service
> +After=proc-xen.mount xenstored.service xenconsoled.service
>  Before=xendomains.service libvirtd.service libvirt-guests.service
>  RefuseManualStop=true
>  ConditionPathExists=/proc/xen/capabilities
> diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> index 2c5d99f..cb44cd6 100644
> --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=Xenconsoled - handles logging from guest consoles and hypervisor
> -Requires=proc-xen.mount xenstored.socket
> -After=proc-xen.mount xenstored.socket
> +Requires=proc-xen.mount xenstored.service
> +After=proc-xen.mount xenstored.service
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
> diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
> index 757278f..9962671 100644
> --- a/tools/hotplug/Linux/systemd/xendomains.service.in
> +++ b/tools/hotplug/Linux/systemd/xendomains.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=Xendomains - start and stop guests on boot and shutdown
> -Requires=proc-xen.mount xenstored.socket
> -After=proc-xen.mount xenstored.socket xenconsoled.service xen-init-dom0.service
> +Requires=proc-xen.mount xenstored.service
> +After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 02 16:06:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1Xvpxp-0004rT-1e; Tue, 02 Dec 2014 16:06:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xvpxn-0004rI-V1
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:06:08 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	EC/A0-25547-F63ED745; Tue, 02 Dec 2014 16:06:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417536364!15342288!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21322 invoked from network); 2 Dec 2014 16:06:06 -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;
	2 Dec 2014 16:06:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198918007"
Message-ID: <1417535095.29004.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Tue, 2 Dec 2014 15:44:55 +0000
In-Reply-To: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
References: <1417534763-25053-1-git-send-email-olaf@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] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
> Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
> systemd xenstored dependencies") all service files use the .socket unit
> as startup dependency. While this happens to work for boot it fails for
> shutdown because a .socket does not seem to enforce ordering. When
> xendomains.service runs during shutdown then systemd will stop
> xenstored.service at the same time.
> 
> Change all "xenstored.socket" to "xenstored.service" to let systemd know
> that xenstored has to be shutdown after everything else.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.com>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

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

> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
> 
> This should go into 4.5 to fix xendomains.service.

CCing Konrad...

> 
>  tools/hotplug/Linux/systemd/xen-init-dom0.service.in              | 4 ++--
>  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 4 ++--
>  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 4 ++--
>  tools/hotplug/Linux/systemd/xendomains.service.in                 | 4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> index 4d4cb23..3befadc 100644
> --- a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> +++ b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=xen-init-dom0, initialise Dom0 configuration (xenstore nodes, JSON configuration stub)
> -Requires=xenstored.socket proc-xen.mount
> -After=xenstored.socket proc-xen.mount
> +Requires=xenstored.service proc-xen.mount
> +After=xenstored.service proc-xen.mount
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
> 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 6b9c96e..0a5807a 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
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=qemu for xen dom0 disk backend
> -Requires=proc-xen.mount xenstored.socket
> -After=proc-xen.mount xenstored.socket xenconsoled.service
> +Requires=proc-xen.mount xenstored.service
> +After=proc-xen.mount xenstored.service xenconsoled.service
>  Before=xendomains.service libvirtd.service libvirt-guests.service
>  RefuseManualStop=true
>  ConditionPathExists=/proc/xen/capabilities
> diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> index 2c5d99f..cb44cd6 100644
> --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=Xenconsoled - handles logging from guest consoles and hypervisor
> -Requires=proc-xen.mount xenstored.socket
> -After=proc-xen.mount xenstored.socket
> +Requires=proc-xen.mount xenstored.service
> +After=proc-xen.mount xenstored.service
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
> diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
> index 757278f..9962671 100644
> --- a/tools/hotplug/Linux/systemd/xendomains.service.in
> +++ b/tools/hotplug/Linux/systemd/xendomains.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=Xendomains - start and stop guests on boot and shutdown
> -Requires=proc-xen.mount xenstored.socket
> -After=proc-xen.mount xenstored.socket xenconsoled.service xen-init-dom0.service
> +Requires=proc-xen.mount xenstored.service
> +After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 02 16:06:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:06:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpyG-0004vD-Kx; Tue, 02 Dec 2014 16:06:36 +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 1XvpyF-0004uw-Mr; Tue, 02 Dec 2014 16:06:35 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	22/88-14727-A83ED745; Tue, 02 Dec 2014 16:06:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417536394!3529068!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9962 invoked from network); 2 Dec 2014 16:06:34 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 16:06:34 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417536394; l=911;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=CcStn0+SQmu1ugVhCGJ2SQYdbpM=;
	b=IiP/n3SpZL7HJWkyq15Zr8T43lzqNGgzw7Ja27vba1apC/p6TrlCwgLLyZmMlE0zwCS
	G/45NHhWsEbfv314ST4AArExSGuFkNaPKN5nFU6sKzaYIa9rZ+LFfNjJDbGl4qvUkiW4L
	GsW6rYML6S3j1LN3rF9IMjHN3EbbUoqvTVk=
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.2 AUTH) with ESMTPSA id h01c7aqB2G6VpMW
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 17:06:31 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id C3AB95016D; Tue,  2 Dec 2014 17:06:30 +0100 (CET)
Date: Tue, 2 Dec 2014 17:06:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202160630.GA30262@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<1417534760.29004.3.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417534760.29004.3.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, 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>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Ian Campbell wrote:

> On Tue, 2014-12-02 at 16:17 +0100, Olaf Hering wrote:
> > On Tue, Dec 02, Ian Campbell wrote:
> > 
> > > On Mon, 2014-12-01 at 23:41 +0000, Mark Pryor wrote:
> > > > list,
> > > 
> > > Thanks. If you've identified a buggy changeset then it is fine to post
> > > to the devel lists. I've added a CC. I've also CCd everyone listed in
> > > the commit which you've fingered.
> > > 
> > > Olaf, does this suggested change look correct? If so then can you turn
> > > it into a patch please.
> > 
> > Yes, something like this (sed -i 's@socket@service@g' *.in):
> 
> Can you submit to -devel with a commit log and S-o-b etc please.

Yes, I did already. Looks like git send-email does not process a
Reported-by tag so Mark did not actually got a copy of that submission.
But the actual patch did not change so what I sent him earlier can be
used as is.

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:06:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:06:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvpyG-0004vD-Kx; Tue, 02 Dec 2014 16:06:36 +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 1XvpyF-0004uw-Mr; Tue, 02 Dec 2014 16:06:35 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	22/88-14727-A83ED745; Tue, 02 Dec 2014 16:06:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417536394!3529068!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9962 invoked from network); 2 Dec 2014 16:06:34 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 16:06:34 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417536394; l=911;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=CcStn0+SQmu1ugVhCGJ2SQYdbpM=;
	b=IiP/n3SpZL7HJWkyq15Zr8T43lzqNGgzw7Ja27vba1apC/p6TrlCwgLLyZmMlE0zwCS
	G/45NHhWsEbfv314ST4AArExSGuFkNaPKN5nFU6sKzaYIa9rZ+LFfNjJDbGl4qvUkiW4L
	GsW6rYML6S3j1LN3rF9IMjHN3EbbUoqvTVk=
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.2 AUTH) with ESMTPSA id h01c7aqB2G6VpMW
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 2 Dec 2014 17:06:31 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id C3AB95016D; Tue,  2 Dec 2014 17:06:30 +0100 (CET)
Date: Tue, 2 Dec 2014 17:06:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202160630.GA30262@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<1417534760.29004.3.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417534760.29004.3.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, 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>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Ian Campbell wrote:

> On Tue, 2014-12-02 at 16:17 +0100, Olaf Hering wrote:
> > On Tue, Dec 02, Ian Campbell wrote:
> > 
> > > On Mon, 2014-12-01 at 23:41 +0000, Mark Pryor wrote:
> > > > list,
> > > 
> > > Thanks. If you've identified a buggy changeset then it is fine to post
> > > to the devel lists. I've added a CC. I've also CCd everyone listed in
> > > the commit which you've fingered.
> > > 
> > > Olaf, does this suggested change look correct? If so then can you turn
> > > it into a patch please.
> > 
> > Yes, something like this (sed -i 's@socket@service@g' *.in):
> 
> Can you submit to -devel with a commit log and S-o-b etc please.

Yes, I did already. Looks like git send-email does not process a
Reported-by tag so Mark did not actually got a copy of that submission.
But the actual patch did not change so what I sent him earlier can be
used as is.

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:15:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1Xvq6U-0005g1-9b; Tue, 02 Dec 2014 16:15: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 1Xvq6T-0005fw-7u
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:15:05 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	44/DD-14727-885ED745; Tue, 02 Dec 2014 16:15:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417536902!11114304!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 30144 invoked from network); 2 Dec 2014 16:15:03 -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;
	2 Dec 2014 16:15:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198590209"
Message-ID: <547DDF6A.7080500@citrix.com>
Date: Tue, 2 Dec 2014 15:48: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: Vitaly Kuznetsov <vkuznets@redhat.com>, <xen-devel@lists.xen.org>
References: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
X-DLP: MIA2
Cc: Andrew Jones <drjones@redhat.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>
Subject: Re: [Xen-devel] [PATCH] libxc: check in xc_get_tot_pages() that the
 proper domain is reported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 15:18, Vitaly Kuznetsov wrote:
> XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
> strange interface: it reports first domain which has domid >= requested domid
> so all callers are supposed to check that the proper domain(s) was queried
> by checking domid. xc_get_tot_pages() doesn't do that. In case the requested
> domain was destroyed it will report first domain with domid > requested domid
> which is apparently misleading as there is no way xc_get_tot_pages() callers
> can figure out that they got tot_pages for some other domain.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

CCing Konrad as this really should get a 4.5 release ack.  It is a
straight bugfix.

> ---
>  tools/libxc/xc_private.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
> index 1c214dd..e2441ad 100644
> --- a/tools/libxc/xc_private.c
> +++ b/tools/libxc/xc_private.c
> @@ -613,8 +613,10 @@ int xc_get_pfn_list(xc_interface *xch,
>  long xc_get_tot_pages(xc_interface *xch, uint32_t domid)
>  {
>      xc_dominfo_t info;
> -    return (xc_domain_getinfo(xch, domid, 1, &info) != 1) ?
> -        -1 : info.nr_pages;
> +    if ( (xc_domain_getinfo(xch, domid, 1, &info) != 1) ||
> +         (info.domid != domid) )
> +        return -1;
> +    return info.nr_pages;
>  }
>  
>  int xc_copy_to_domain_page(xc_interface *xch,


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:15:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1Xvq6U-0005g1-9b; Tue, 02 Dec 2014 16:15: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 1Xvq6T-0005fw-7u
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:15:05 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	44/DD-14727-885ED745; Tue, 02 Dec 2014 16:15:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417536902!11114304!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 30144 invoked from network); 2 Dec 2014 16:15:03 -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;
	2 Dec 2014 16:15:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198590209"
Message-ID: <547DDF6A.7080500@citrix.com>
Date: Tue, 2 Dec 2014 15:48: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: Vitaly Kuznetsov <vkuznets@redhat.com>, <xen-devel@lists.xen.org>
References: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
X-DLP: MIA2
Cc: Andrew Jones <drjones@redhat.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>
Subject: Re: [Xen-devel] [PATCH] libxc: check in xc_get_tot_pages() that the
 proper domain is reported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 15:18, Vitaly Kuznetsov wrote:
> XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
> strange interface: it reports first domain which has domid >= requested domid
> so all callers are supposed to check that the proper domain(s) was queried
> by checking domid. xc_get_tot_pages() doesn't do that. In case the requested
> domain was destroyed it will report first domain with domid > requested domid
> which is apparently misleading as there is no way xc_get_tot_pages() callers
> can figure out that they got tot_pages for some other domain.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

CCing Konrad as this really should get a 4.5 release ack.  It is a
straight bugfix.

> ---
>  tools/libxc/xc_private.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
> index 1c214dd..e2441ad 100644
> --- a/tools/libxc/xc_private.c
> +++ b/tools/libxc/xc_private.c
> @@ -613,8 +613,10 @@ int xc_get_pfn_list(xc_interface *xch,
>  long xc_get_tot_pages(xc_interface *xch, uint32_t domid)
>  {
>      xc_dominfo_t info;
> -    return (xc_domain_getinfo(xch, domid, 1, &info) != 1) ?
> -        -1 : info.nr_pages;
> +    if ( (xc_domain_getinfo(xch, domid, 1, &info) != 1) ||
> +         (info.domid != domid) )
> +        return -1;
> +    return info.nr_pages;
>  }
>  
>  int xc_copy_to_domain_page(xc_interface *xch,


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:16:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:16:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvq85-0005my-Qt; Tue, 02 Dec 2014 16:16:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xvq84-0005mo-R2
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:16:45 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	94/D1-22777-CE5ED745; Tue, 02 Dec 2014 16:16:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417537001!11106252!1
X-Originating-IP: [66.165.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 28793 invoked from network); 2 Dec 2014 16:16:43 -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;
	2 Dec 2014 16:16:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198926988"
Received: from ukmail1.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, 2 Dec 2014 10:58: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 1XvpqS-0004ID-Ng;
	Tue, 02 Dec 2014 15:58:32 +0000
Date: Tue, 2 Dec 2014 15:58:32 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141202155832.GH5768@zion.uk.xensource.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Luohao \(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 02:46:36PM +0000, Zhangleiqiang (Trump) wrote:
> Thanks for your reply, Wei.
> 
> I do the following testing just now and found the results as follows:
> 
> There are three DomUs (4U4G) are running on Host A (6U6G) and one DomU (4U4G) is running on Host B (6U6G), I send packets from three DomUs to the DomU on Host B simultaneously. 
> 
> 1. The "top" output of Host B as follows:
> 
> top - 09:42:11 up  1:07,  2 users,  load average: 2.46, 1.90, 1.47
> Tasks: 173 total,   4 running, 169 sleeping,   0 stopped,   0 zombie
> %Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 97.3 id,  0.0 wa,  0.0 hi,  0.8 si,  1.9 st
> %Cpu1  :  0.0 us, 27.0 sy,  0.0 ni, 63.1 id,  0.0 wa,  0.0 hi,  9.5 si,  0.4 st
> %Cpu2  :  0.0 us, 90.0 sy,  0.0 ni,  8.3 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st
> %Cpu3  :  0.4 us,  1.4 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,  1.4 si,  1.4 st
> %Cpu4  :  0.0 us, 60.2 sy,  0.0 ni, 39.5 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
> %Cpu5  :  0.0 us,  2.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.0 hi,  6.9 si,  0.9 st
> KiB Mem:   4517144 total,  3116480 used,  1400664 free,      876 buffers
> KiB Swap:  2103292 total,        0 used,  2103292 free.  2374656 cached Mem
> 
>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                            
>  7440 root      20   0       0      0      0 R 71.10 0.000   8:15.38 vif4.0-q3-guest                                                    
>  7434 root      20   0       0      0      0 R 59.14 0.000   9:00.58 vif4.0-q0-guest                                                    
>    18 root      20   0       0      0      0 R 33.89 0.000   2:35.06 ksoftirqd/2                                                        
>    28 root      20   0       0      0      0 S 20.93 0.000   3:01.81 ksoftirqd/4
> 
> 
> As shown above, only two netback related processes (vif4.0-*) are running with high cpu usage, and the other 2 netback processes are idle. The "ps" result of vif4.0-* processes as follows:
> 
> root      7434 50.5  0.0      0     0 ?        R    09:23  11:29 [vif4.0-q0-guest]
> root      7435  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q0-deall]
> root      7436  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q1-guest]
> root      7437  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q1-deall]
> root      7438  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q2-guest]
> root      7439  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q2-deall]
> root      7440 48.1  0.0      0     0 ?        R    09:23  10:55 [vif4.0-q3-guest]
> root      7441  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q3-deall]
> root      9724  0.0  0.0   9244  1520 pts/0    S+   09:46   0:00 grep --color=auto
> 
> 
> 2. The "rx" related content in /proc/interupts in receiver DomU (on Host B):
> 
> 73: 	2		0		2925405		0			xen-dyn-event		eth0-q0-rx
> 75: 	43		93		0			118			xen-dyn-event		eth0-q1-rx
> 77: 	2		3376	14			1983		xen-dyn-event		eth0-q2-rx
> 79: 	2414666	0		9			0			xen-dyn-event		eth0-q3-rx
> 
> As shown above, it seems like that only q0 and q3 handles the interrupt triggered by packet receving.
> 
> Any advise? Thanks.

Netback selects queue based on the return value of
skb_get_queue_mapping. The queue mapping is set by core driver or
ndo_select_queue (if specified by individual driver). In this case
netback doesn't have its implementation of ndo_select_queue, so it's up
to core driver to decide which queue to dispatch the packet to.  I
think you need to inspect why Dom0 only steers traffic to these two
queues but not all of them.

Don't know which utility is handy for this job. Probably tc(8) is
useful?

Wei.

> ----------
> zhangleiqiang (Trump)
> 
> Best Regards
> 
> 
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: Tuesday, December 02, 2014 8:12 PM
> > To: Zhangleiqiang (Trump)
> > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian); Xiaoding
> > (B); Yuzhou (C); Zhuangyuxin
> > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > multiqueue support
> > 
> > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump) wrote:
> > > > -----Original Message-----
> > > > From: xen-devel-bounces@lists.xen.org
> > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei Liu
> > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > To: zhangleiqiang
> > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > > > multiqueue support
> > > >
> > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > > Hi, all
> > > > >     I am testing the performance of xen netfront-netback driver
> > > > > that with
> > > > multi-queues support. The throughput from domU to remote dom0 is
> > > > 9.2Gb/s, but the throughput from domU to remote domU is only
> > > > 3.6Gb/s, I think the bottleneck is the throughput from dom0 to local
> > > > domU. However, we have done some testing and found the throughput
> > > > from dom0 to local domU is 5.8Gb/s.
> > > > >     And if we send packets from one DomU to other 3 DomUs on
> > > > > different
> > > > host simultaneously, the sum of throughout can reach 9Gbps. It seems
> > > > like the bottleneck is the receiver?
> > > > >     After some analysis, I found that even the max_queue of
> > > > > netfront/back
> > > > is set to 4, there are some strange results as follows:
> > > > >     1. In domU, only one rx queue deal with softirq
> > > >
> > > > Try to bind irq to different vcpus?
> > >
> > > Do you mean we try to bind irq to different vcpus in DomU? I will try it now.
> > >
> > 
> > Yes. Given the fact that you have two backend threads running while only one
> > DomU vcpu is busy, it smells like misconfiguration in DomU.
> > 
> > If this phenomenon persists after correctly binding irqs, you might want to
> > check traffic is steering correctly to different queues.
> > 
> > > >
> > > > >     2. In dom0, only two netback queues process are scheduled,
> > > > > other two
> > > > process aren't scheduled.
> > > >
> > > > How many Dom0 vcpu do you have? If it only has two then there will
> > > > only be two processes running at a time.
> > >
> > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU running in
> > Dom0 and so four netback processes are running in Dom0 (because the
> > max_queue param of netback kernel module is set to 4).
> > > The phenomenon is that only 2 of these four netback process were running
> > with about 70% cpu usage, and another two use little CPU.
> > > Is there a hash algorithm to determine which netback process to handle the
> > input packet?
> > >
> > 
> > I think that's whatever default algorithm Linux kernel is using.
> > 
> > We don't currently support other algorithms.
> > 
> > Wei.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:16:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:16:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvq85-0005my-Qt; Tue, 02 Dec 2014 16:16:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xvq84-0005mo-R2
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:16:45 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	94/D1-22777-CE5ED745; Tue, 02 Dec 2014 16:16:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417537001!11106252!1
X-Originating-IP: [66.165.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 28793 invoked from network); 2 Dec 2014 16:16:43 -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;
	2 Dec 2014 16:16:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198926988"
Received: from ukmail1.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, 2 Dec 2014 10:58: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 1XvpqS-0004ID-Ng;
	Tue, 02 Dec 2014 15:58:32 +0000
Date: Tue, 2 Dec 2014 15:58:32 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141202155832.GH5768@zion.uk.xensource.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Luohao \(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 02:46:36PM +0000, Zhangleiqiang (Trump) wrote:
> Thanks for your reply, Wei.
> 
> I do the following testing just now and found the results as follows:
> 
> There are three DomUs (4U4G) are running on Host A (6U6G) and one DomU (4U4G) is running on Host B (6U6G), I send packets from three DomUs to the DomU on Host B simultaneously. 
> 
> 1. The "top" output of Host B as follows:
> 
> top - 09:42:11 up  1:07,  2 users,  load average: 2.46, 1.90, 1.47
> Tasks: 173 total,   4 running, 169 sleeping,   0 stopped,   0 zombie
> %Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 97.3 id,  0.0 wa,  0.0 hi,  0.8 si,  1.9 st
> %Cpu1  :  0.0 us, 27.0 sy,  0.0 ni, 63.1 id,  0.0 wa,  0.0 hi,  9.5 si,  0.4 st
> %Cpu2  :  0.0 us, 90.0 sy,  0.0 ni,  8.3 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st
> %Cpu3  :  0.4 us,  1.4 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,  1.4 si,  1.4 st
> %Cpu4  :  0.0 us, 60.2 sy,  0.0 ni, 39.5 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
> %Cpu5  :  0.0 us,  2.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.0 hi,  6.9 si,  0.9 st
> KiB Mem:   4517144 total,  3116480 used,  1400664 free,      876 buffers
> KiB Swap:  2103292 total,        0 used,  2103292 free.  2374656 cached Mem
> 
>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                            
>  7440 root      20   0       0      0      0 R 71.10 0.000   8:15.38 vif4.0-q3-guest                                                    
>  7434 root      20   0       0      0      0 R 59.14 0.000   9:00.58 vif4.0-q0-guest                                                    
>    18 root      20   0       0      0      0 R 33.89 0.000   2:35.06 ksoftirqd/2                                                        
>    28 root      20   0       0      0      0 S 20.93 0.000   3:01.81 ksoftirqd/4
> 
> 
> As shown above, only two netback related processes (vif4.0-*) are running with high cpu usage, and the other 2 netback processes are idle. The "ps" result of vif4.0-* processes as follows:
> 
> root      7434 50.5  0.0      0     0 ?        R    09:23  11:29 [vif4.0-q0-guest]
> root      7435  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q0-deall]
> root      7436  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q1-guest]
> root      7437  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q1-deall]
> root      7438  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q2-guest]
> root      7439  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q2-deall]
> root      7440 48.1  0.0      0     0 ?        R    09:23  10:55 [vif4.0-q3-guest]
> root      7441  0.0  0.0      0     0 ?        S    09:23   0:00 [vif4.0-q3-deall]
> root      9724  0.0  0.0   9244  1520 pts/0    S+   09:46   0:00 grep --color=auto
> 
> 
> 2. The "rx" related content in /proc/interupts in receiver DomU (on Host B):
> 
> 73: 	2		0		2925405		0			xen-dyn-event		eth0-q0-rx
> 75: 	43		93		0			118			xen-dyn-event		eth0-q1-rx
> 77: 	2		3376	14			1983		xen-dyn-event		eth0-q2-rx
> 79: 	2414666	0		9			0			xen-dyn-event		eth0-q3-rx
> 
> As shown above, it seems like that only q0 and q3 handles the interrupt triggered by packet receving.
> 
> Any advise? Thanks.

Netback selects queue based on the return value of
skb_get_queue_mapping. The queue mapping is set by core driver or
ndo_select_queue (if specified by individual driver). In this case
netback doesn't have its implementation of ndo_select_queue, so it's up
to core driver to decide which queue to dispatch the packet to.  I
think you need to inspect why Dom0 only steers traffic to these two
queues but not all of them.

Don't know which utility is handy for this job. Probably tc(8) is
useful?

Wei.

> ----------
> zhangleiqiang (Trump)
> 
> Best Regards
> 
> 
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: Tuesday, December 02, 2014 8:12 PM
> > To: Zhangleiqiang (Trump)
> > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian); Xiaoding
> > (B); Yuzhou (C); Zhuangyuxin
> > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > multiqueue support
> > 
> > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump) wrote:
> > > > -----Original Message-----
> > > > From: xen-devel-bounces@lists.xen.org
> > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei Liu
> > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > To: zhangleiqiang
> > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > > > multiqueue support
> > > >
> > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > > Hi, all
> > > > >     I am testing the performance of xen netfront-netback driver
> > > > > that with
> > > > multi-queues support. The throughput from domU to remote dom0 is
> > > > 9.2Gb/s, but the throughput from domU to remote domU is only
> > > > 3.6Gb/s, I think the bottleneck is the throughput from dom0 to local
> > > > domU. However, we have done some testing and found the throughput
> > > > from dom0 to local domU is 5.8Gb/s.
> > > > >     And if we send packets from one DomU to other 3 DomUs on
> > > > > different
> > > > host simultaneously, the sum of throughout can reach 9Gbps. It seems
> > > > like the bottleneck is the receiver?
> > > > >     After some analysis, I found that even the max_queue of
> > > > > netfront/back
> > > > is set to 4, there are some strange results as follows:
> > > > >     1. In domU, only one rx queue deal with softirq
> > > >
> > > > Try to bind irq to different vcpus?
> > >
> > > Do you mean we try to bind irq to different vcpus in DomU? I will try it now.
> > >
> > 
> > Yes. Given the fact that you have two backend threads running while only one
> > DomU vcpu is busy, it smells like misconfiguration in DomU.
> > 
> > If this phenomenon persists after correctly binding irqs, you might want to
> > check traffic is steering correctly to different queues.
> > 
> > > >
> > > > >     2. In dom0, only two netback queues process are scheduled,
> > > > > other two
> > > > process aren't scheduled.
> > > >
> > > > How many Dom0 vcpu do you have? If it only has two then there will
> > > > only be two processes running at a time.
> > >
> > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU running in
> > Dom0 and so four netback processes are running in Dom0 (because the
> > max_queue param of netback kernel module is set to 4).
> > > The phenomenon is that only 2 of these four netback process were running
> > with about 70% cpu usage, and another two use little CPU.
> > > Is there a hash algorithm to determine which netback process to handle the
> > input packet?
> > >
> > 
> > I think that's whatever default algorithm Linux kernel is using.
> > 
> > We don't currently support other algorithms.
> > 
> > Wei.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:20:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1XvqBo-00062C-Ii; Tue, 02 Dec 2014 16:20:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqBm-000625-Nz
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:20:34 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	28/96-18267-2D6ED745; Tue, 02 Dec 2014 16:20:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417537230!15383139!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4863 invoked from network); 2 Dec 2014 16:20: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;
	2 Dec 2014 16:20:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198929535"
Message-ID: <1417536141.29004.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:02:21 +0000
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 <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH v2 OSSTEST 0/18] Implement for driving libvirt
	via virsh
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following series switches osstest to implement the toolstack via
get_host_method_object()->method rather than toolstack()->{Command}."
method" etc.

This is needed because virsh differs from xm/xl in a few commands.

It also implements partial virsh support (simple lifecycle stuff, but
not e.g. migration yet). Due to the ts-migration-check logic this means
that the libvirt sequence works in so far as it skips/ignores the
migration/save+restore related tests.

I've not kept notes on what I changes since last time (but noone has
really reviewed the v1/RFC anyway ;-)). This time around is more
complete in that it implements shutdown etc and the job completes and
I've actually removed ->{Command} which was just an aspiration last
timearound.

I've tested with:

test-amd64-amd64-libvirt on a xen-unstable flight, which failed due to
http://article.gmane.org/gmane.comp.emulators.xen.devel/224197 and that
set of issues.

test-amd64-amd64-libvirt on a xen-unstable flight with the above patches
added, works.

Since this touches xend code paths I've also tested using a
xen-4.4-testing based flight:

test-amd64-amd64-libvirt
test-amd64-amd64-pv (uses xend)
test-amd64-amd64-xl (uses xl, duh!)

All passed.

The last patch stubs out migration a bit but doesn't actually work and
obviously shouldn't be applied, it's included for reference. Note that
the series still enables useful functionality even without migration
(e.g. start/stop/destroy testing)

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:20:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1XvqBo-00062C-Ii; Tue, 02 Dec 2014 16:20:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqBm-000625-Nz
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:20:34 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	28/96-18267-2D6ED745; Tue, 02 Dec 2014 16:20:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417537230!15383139!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4863 invoked from network); 2 Dec 2014 16:20: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;
	2 Dec 2014 16:20:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198929535"
Message-ID: <1417536141.29004.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:02:21 +0000
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 <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH v2 OSSTEST 0/18] Implement for driving libvirt
	via virsh
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following series switches osstest to implement the toolstack via
get_host_method_object()->method rather than toolstack()->{Command}."
method" etc.

This is needed because virsh differs from xm/xl in a few commands.

It also implements partial virsh support (simple lifecycle stuff, but
not e.g. migration yet). Due to the ts-migration-check logic this means
that the libvirt sequence works in so far as it skips/ignores the
migration/save+restore related tests.

I've not kept notes on what I changes since last time (but noone has
really reviewed the v1/RFC anyway ;-)). This time around is more
complete in that it implements shutdown etc and the job completes and
I've actually removed ->{Command} which was just an aspiration last
timearound.

I've tested with:

test-amd64-amd64-libvirt on a xen-unstable flight, which failed due to
http://article.gmane.org/gmane.comp.emulators.xen.devel/224197 and that
set of issues.

test-amd64-amd64-libvirt on a xen-unstable flight with the above patches
added, works.

Since this touches xend code paths I've also tested using a
xen-4.4-testing based flight:

test-amd64-amd64-libvirt
test-amd64-amd64-pv (uses xend)
test-amd64-amd64-xl (uses xl, duh!)

All passed.

The last patch stubs out migration a bit but doesn't actually work and
obviously shouldn't be applied, it's included for reference. Note that
the series still enables useful functionality even without migration
(e.g. start/stop/destroy testing)

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Dec 02 16:23:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1XvqEm-0006Az-6O; Tue, 02 Dec 2014 16:23: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 1XvqEl-0006Ar-7f
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:23:39 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	8F/B9-17735-A87ED745; Tue, 02 Dec 2014 16:23:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417537415!15330124!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32693 invoked from network); 2 Dec 2014 16:23:37 -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;
	2 Dec 2014 16:23:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931127"
Received: from ukmail1.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, 2 Dec 2014 11:05:00 -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 1Xvpwh-0004Wx-4J;
	Tue, 02 Dec 2014 16:05:00 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:04:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:42 +0000
Message-ID: <1417536299-1810-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 01/18] apt: lock osstest's usages of
	apt-get against each other
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 rely on all apt-get invocations being in a single
ts-xen-build-prep job which can't run on a shared host.

That is a bit inflexible so instead use our own lock. We wait indefinitely and
rely on osstest's existing command timeout infrastructure to catch problems.

target_install_packages*() previous estimated the time taken to install the
packages based on the number of packages. This no longer applies because the
install might get stuck behind some other large install. Use a 3000s (nearly
an hour) timeout instead (I expect failures here to be unusual so erred on the
big side)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Debian.pm      | 2 +-
 Osstest/TestSupport.pm | 7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..b343f0f 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, ethtool, $extra_packages
+d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, chiark-utils-bin, $extra_packages
 
 $xopts{ExtraPreseed}
 
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index e6c54bc..2ac490f 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -433,17 +433,18 @@ sub target_putfile_root ($$$$;$) {
 sub target_run_apt {
     my ($ho, $timeout, @aptopts) = @_;
     target_cmd_root($ho,
-   "DEBIAN_PRIORITY=critical UCF_FORCE_CONFFOLD=y apt-get @aptopts",
+   "DEBIAN_PRIORITY=critical UCF_FORCE_CONFFOLD=y \
+        with-lock-ex -w /var/lock/osstest-apt apt-get @aptopts",
                     $timeout);
 }
 sub target_install_packages {
     my ($ho, @packages) = @_;
-    target_run_apt($ho, 300 + 100 * @packages,
+    target_run_apt($ho, 3000,
 		   qw(-y install), @packages);
 }
 sub target_install_packages_norec {
     my ($ho, @packages) = @_;
-    target_run_apt($ho, 300 + 100 * @packages,
+    target_run_apt($ho, 3000,
 		   qw(--no-install-recommends -y install), @packages);
 }
 
-- 
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 Tue Dec 02 16:23:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1XvqEm-0006Az-6O; Tue, 02 Dec 2014 16:23: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 1XvqEl-0006Ar-7f
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:23:39 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	8F/B9-17735-A87ED745; Tue, 02 Dec 2014 16:23:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417537415!15330124!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32693 invoked from network); 2 Dec 2014 16:23:37 -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;
	2 Dec 2014 16:23:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931127"
Received: from ukmail1.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, 2 Dec 2014 11:05:00 -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 1Xvpwh-0004Wx-4J;
	Tue, 02 Dec 2014 16:05:00 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:04:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:42 +0000
Message-ID: <1417536299-1810-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 01/18] apt: lock osstest's usages of
	apt-get against each other
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 rely on all apt-get invocations being in a single
ts-xen-build-prep job which can't run on a shared host.

That is a bit inflexible so instead use our own lock. We wait indefinitely and
rely on osstest's existing command timeout infrastructure to catch problems.

target_install_packages*() previous estimated the time taken to install the
packages based on the number of packages. This no longer applies because the
install might get stuck behind some other large install. Use a 3000s (nearly
an hour) timeout instead (I expect failures here to be unusual so erred on the
big side)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Debian.pm      | 2 +-
 Osstest/TestSupport.pm | 7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..b343f0f 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, ethtool, $extra_packages
+d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, chiark-utils-bin, $extra_packages
 
 $xopts{ExtraPreseed}
 
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index e6c54bc..2ac490f 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -433,17 +433,18 @@ sub target_putfile_root ($$$$;$) {
 sub target_run_apt {
     my ($ho, $timeout, @aptopts) = @_;
     target_cmd_root($ho,
-   "DEBIAN_PRIORITY=critical UCF_FORCE_CONFFOLD=y apt-get @aptopts",
+   "DEBIAN_PRIORITY=critical UCF_FORCE_CONFFOLD=y \
+        with-lock-ex -w /var/lock/osstest-apt apt-get @aptopts",
                     $timeout);
 }
 sub target_install_packages {
     my ($ho, @packages) = @_;
-    target_run_apt($ho, 300 + 100 * @packages,
+    target_run_apt($ho, 3000,
 		   qw(-y install), @packages);
 }
 sub target_install_packages_norec {
     my ($ho, @packages) = @_;
-    target_run_apt($ho, 300 + 100 * @packages,
+    target_run_apt($ho, 3000,
 		   qw(--no-install-recommends -y install), @packages);
 }
 
-- 
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 Tue Dec 02 16:24:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFI-0006Fq-MK; Tue, 02 Dec 2014 16:24:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqFH-0006Fc-Jd
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:11 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	6E/8A-17735-AA7ED745; Tue, 02 Dec 2014 16:24:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23367 invoked from network); 2 Dec 2014 16:24:10 -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;
	2 Dec 2014 16:24:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931554"
Received: from ukmail1.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, 2 Dec 2014 11:05:05 -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 1Xvpwm-0004XB-Aj;
	Tue, 02 Dec 2014 16:05:05 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:47 +0000
Message-ID: <1417536299-1810-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 06/18] TestSupport: always use xl for
	generic operations.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Unless the toolstack is xend (for compatibility with pre-xl Xen versions), when
we use xm.

For several operations in TestSupport.pm the actual toolstack isn't really
relevant, since we want info straight from Xen. For simplicity just use xl (or
xm) in these cases, to avoid needing to implement the following specially for
each toolstack:
  - host_get_free_memory
  - guest_get_state
  - guest_find_domid
  - listing assignable pci devices

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm | 13 ++++++++++---
 ts-debian-fixup        |  2 +-
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index df05d8a..3f63273 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -936,6 +936,13 @@ sub compress_stashed($) {
 
 #---------- other stuff ----------
 
+sub common_toolstack () {
+    my $tsname= $r{toolstack} || 'xend';
+    my $ts = 'xl';
+    $ts = 'xm' if $tsname eq 'xend';
+    return $ts;
+}
+
 sub host_reboot ($) {
     my ($ho) = @_;
     target_reboot($ho);
@@ -956,7 +963,7 @@ END
 
 sub host_get_free_memory($) {
     my ($ho) = @_;
-    my $toolstack = toolstack($ho)->{Command};
+    my $toolstack = common_toolstack();
     # The line is as followed:
     # free_memory       :   XXXX
     my $info = target_cmd_output_root($ho, "$toolstack info", 10);
@@ -1610,7 +1617,7 @@ sub guest_check_up ($) {
 
 sub guest_get_state ($$) {
     my ($ho,$gho) = @_;
-    my $domains= target_cmd_output_root($ho, toolstack($ho)->{Command}." list");
+    my $domains= target_cmd_output_root($ho, common_toolstack()." list");
     $domains =~ s/^Name.*\n//;
     foreach my $l (split /\n/, $domains) {
         $l =~ m/^(\S+) (?: \s+ \d+ ){3} \s+ ([-a-z]+) \s/x or die "$l ?";
@@ -1815,7 +1822,7 @@ sub guest_find_domid ($$) {
     my ($ho,$gho) = @_;
     return if defined $gho->{Domid};
     my $list= target_cmd_output_root($ho,
-                toolstack($ho)->{Command}." list $gho->{Name}");
+                common_toolstack()." list $gho->{Name}");
     $list =~ m/^(?!Name\s)(\S+)\s+(\d+)\s+(\d+)+(\d+)\s.*$/m
         or die "domain list: $list";
     $1 eq $gho->{Name} or die "domain list name $1 expected $gho->{Name}";
diff --git a/ts-debian-fixup b/ts-debian-fixup
index 11e956c..0dc2d07 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -142,7 +142,7 @@ sub otherfixupcfg () {
     if (@pcipt) {
         logm("checking passthrough device(s) are assignable: @pcipt");
         my @assignables= split /\n/,
-            target_cmd_output_root($ho, toolstack($ho)->{Command}.
+            target_cmd_output_root($ho, common_toolstack().
                                    " pci-assignable-list");
         foreach my $pcipt (@pcipt) {
             die "not assignable: $pcipt (not in: @assignables)"
-- 
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 Tue Dec 02 16:24:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFI-0006Fq-MK; Tue, 02 Dec 2014 16:24:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqFH-0006Fc-Jd
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:11 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	6E/8A-17735-AA7ED745; Tue, 02 Dec 2014 16:24:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23367 invoked from network); 2 Dec 2014 16:24:10 -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;
	2 Dec 2014 16:24:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931554"
Received: from ukmail1.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, 2 Dec 2014 11:05:05 -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 1Xvpwm-0004XB-Aj;
	Tue, 02 Dec 2014 16:05:05 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:47 +0000
Message-ID: <1417536299-1810-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 06/18] TestSupport: always use xl for
	generic operations.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Unless the toolstack is xend (for compatibility with pre-xl Xen versions), when
we use xm.

For several operations in TestSupport.pm the actual toolstack isn't really
relevant, since we want info straight from Xen. For simplicity just use xl (or
xm) in these cases, to avoid needing to implement the following specially for
each toolstack:
  - host_get_free_memory
  - guest_get_state
  - guest_find_domid
  - listing assignable pci devices

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm | 13 ++++++++++---
 ts-debian-fixup        |  2 +-
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index df05d8a..3f63273 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -936,6 +936,13 @@ sub compress_stashed($) {
 
 #---------- other stuff ----------
 
+sub common_toolstack () {
+    my $tsname= $r{toolstack} || 'xend';
+    my $ts = 'xl';
+    $ts = 'xm' if $tsname eq 'xend';
+    return $ts;
+}
+
 sub host_reboot ($) {
     my ($ho) = @_;
     target_reboot($ho);
@@ -956,7 +963,7 @@ END
 
 sub host_get_free_memory($) {
     my ($ho) = @_;
-    my $toolstack = toolstack($ho)->{Command};
+    my $toolstack = common_toolstack();
     # The line is as followed:
     # free_memory       :   XXXX
     my $info = target_cmd_output_root($ho, "$toolstack info", 10);
@@ -1610,7 +1617,7 @@ sub guest_check_up ($) {
 
 sub guest_get_state ($$) {
     my ($ho,$gho) = @_;
-    my $domains= target_cmd_output_root($ho, toolstack($ho)->{Command}." list");
+    my $domains= target_cmd_output_root($ho, common_toolstack()." list");
     $domains =~ s/^Name.*\n//;
     foreach my $l (split /\n/, $domains) {
         $l =~ m/^(\S+) (?: \s+ \d+ ){3} \s+ ([-a-z]+) \s/x or die "$l ?";
@@ -1815,7 +1822,7 @@ sub guest_find_domid ($$) {
     my ($ho,$gho) = @_;
     return if defined $gho->{Domid};
     my $list= target_cmd_output_root($ho,
-                toolstack($ho)->{Command}." list $gho->{Name}");
+                common_toolstack()." list $gho->{Name}");
     $list =~ m/^(?!Name\s)(\S+)\s+(\d+)\s+(\d+)+(\d+)\s.*$/m
         or die "domain list: $list";
     $1 eq $gho->{Name} or die "domain list name $1 expected $gho->{Name}";
diff --git a/ts-debian-fixup b/ts-debian-fixup
index 11e956c..0dc2d07 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -142,7 +142,7 @@ sub otherfixupcfg () {
     if (@pcipt) {
         logm("checking passthrough device(s) are assignable: @pcipt");
         my @assignables= split /\n/,
-            target_cmd_output_root($ho, toolstack($ho)->{Command}.
+            target_cmd_output_root($ho, common_toolstack().
                                    " pci-assignable-list");
         foreach my $pcipt (@pcipt) {
             die "not assignable: $pcipt (not in: @assignables)"
-- 
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 Tue Dec 02 16:24:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFK-0006Gq-7w; Tue, 02 Dec 2014 16:24: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 1XvqFI-0006Fn-KU
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:12 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	84/5E-18267-BA7ED745; Tue, 02 Dec 2014 16:24:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!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 23491 invoked from network); 2 Dec 2014 16:24:11 -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;
	2 Dec 2014 16:24:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931564"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwn-0004XE-Bg;
	Tue, 02 Dec 2014 16:05:06 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:48 +0000
Message-ID: <1417536299-1810-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 07/18] TestSupport: guest_create
	takes a $ho.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 looks up the toolstack from it.

This is now consistent with guest_destroy.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm         | 5 +++--
 ts-debian-hvm-install          | 7 ++-----
 ts-redhat-install              | 7 ++-----
 ts-rumpuserxen-demo-xenstorels | 2 +-
 4 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 3f63273..616f7ed 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1330,8 +1330,9 @@ sub guest_destroy ($$) {
 }
 
 sub guest_create ($$) {
-    my ($gho,$toolstack) = @_;
-    target_cmd_root($gho->{Host}, "$toolstack create $gho->{CfgPath}", 100);
+    my ($ho,$gho) = @_;
+    my $ts= toolstack($ho);
+    target_cmd_root($ho, $ts->{Command}." create $gho->{CfgPath}", 100);
 }
 
 
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 0148eef..f274630 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -41,9 +41,6 @@ our $disk_mb= 10000;
 our $guesthost= "$gn.guest.osstest";
 our $gho;
 
-our $toolstack= toolstack($ho)->{Command};
-
-
 sub preseed () {
 
     my $preseed_file = preseed_base('wheezy','',());
@@ -183,7 +180,7 @@ logm("Host has $host_freemem_mb MB free memory, setting guest memory size to $ra
 
 if (!$stage) {
     prep();
-    guest_create($gho,$toolstack);
+    guest_create($ho,$gho);
 } else {
     $gho= selectguest($gn,$gho);
 }
@@ -193,6 +190,6 @@ if ($stage<2) {
 }
 
 guest_editconfig_nocd($gho,$emptyiso);
-guest_create($gho,$toolstack);
+guest_create($ho,$gho);
 guest_await_dhcp_tcp($gho,300);
 guest_check_up($gho);
diff --git a/ts-redhat-install b/ts-redhat-install
index a0b1fab..0b4ee17 100755
--- a/ts-redhat-install
+++ b/ts-redhat-install
@@ -37,9 +37,6 @@ our $disk_mb= 50000;
 our $guesthost= "$gn.guest.osstest";
 our $gho;
 
-our $xl= toolstack($ho)->{Command};
-
-
 sub kickstart () {
     my $cryptpw= '$6$anjRJmBbJcrNJGWN$rqvGUhu8ITjvErdIA5C//w2R6b/6wAjHbaF7XF8u3lZg1XI3StthPIE6UII08scOFwASMOepCGpgtsYeCpjqb.';
     my $authkeys= authorized_keys();
@@ -152,7 +149,7 @@ sub prep () {
 
 if (!$stage) {
     prep();
-    guest_create($gho,$xl);
+    guest_create($ho,$gho);
 } else {
     $gho= selectguest($gn,$gho);
 }
@@ -162,6 +159,6 @@ if ($stage<2) {
 }
 
 guest_editconfig_nocd($gho,$emptyiso);
-guest_create($gho,$xl);
+guest_create($ho,$gho);
 guest_await_dhcp_tcp($gho,300);
 guest_check_up($gho);
diff --git a/ts-rumpuserxen-demo-xenstorels b/ts-rumpuserxen-demo-xenstorels
index 6698848..69a2186 100755
--- a/ts-rumpuserxen-demo-xenstorels
+++ b/ts-rumpuserxen-demo-xenstorels
@@ -40,7 +40,7 @@ sub arrangepreserve () {
 }
 
 sub start () {
-    guest_create($gho,toolstack($ho));
+    guest_create($ho, $gho);
 
     $domid = guest_find_domid($ho, $gho);
 }
-- 
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 Tue Dec 02 16:24:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFK-0006Gq-7w; Tue, 02 Dec 2014 16:24: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 1XvqFI-0006Fn-KU
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:12 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	84/5E-18267-BA7ED745; Tue, 02 Dec 2014 16:24:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!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 23491 invoked from network); 2 Dec 2014 16:24:11 -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;
	2 Dec 2014 16:24:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931564"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwn-0004XE-Bg;
	Tue, 02 Dec 2014 16:05:06 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:48 +0000
Message-ID: <1417536299-1810-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 07/18] TestSupport: guest_create
	takes a $ho.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 looks up the toolstack from it.

This is now consistent with guest_destroy.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm         | 5 +++--
 ts-debian-hvm-install          | 7 ++-----
 ts-redhat-install              | 7 ++-----
 ts-rumpuserxen-demo-xenstorels | 2 +-
 4 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 3f63273..616f7ed 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1330,8 +1330,9 @@ sub guest_destroy ($$) {
 }
 
 sub guest_create ($$) {
-    my ($gho,$toolstack) = @_;
-    target_cmd_root($gho->{Host}, "$toolstack create $gho->{CfgPath}", 100);
+    my ($ho,$gho) = @_;
+    my $ts= toolstack($ho);
+    target_cmd_root($ho, $ts->{Command}." create $gho->{CfgPath}", 100);
 }
 
 
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 0148eef..f274630 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -41,9 +41,6 @@ our $disk_mb= 10000;
 our $guesthost= "$gn.guest.osstest";
 our $gho;
 
-our $toolstack= toolstack($ho)->{Command};
-
-
 sub preseed () {
 
     my $preseed_file = preseed_base('wheezy','',());
@@ -183,7 +180,7 @@ logm("Host has $host_freemem_mb MB free memory, setting guest memory size to $ra
 
 if (!$stage) {
     prep();
-    guest_create($gho,$toolstack);
+    guest_create($ho,$gho);
 } else {
     $gho= selectguest($gn,$gho);
 }
@@ -193,6 +190,6 @@ if ($stage<2) {
 }
 
 guest_editconfig_nocd($gho,$emptyiso);
-guest_create($gho,$toolstack);
+guest_create($ho,$gho);
 guest_await_dhcp_tcp($gho,300);
 guest_check_up($gho);
diff --git a/ts-redhat-install b/ts-redhat-install
index a0b1fab..0b4ee17 100755
--- a/ts-redhat-install
+++ b/ts-redhat-install
@@ -37,9 +37,6 @@ our $disk_mb= 50000;
 our $guesthost= "$gn.guest.osstest";
 our $gho;
 
-our $xl= toolstack($ho)->{Command};
-
-
 sub kickstart () {
     my $cryptpw= '$6$anjRJmBbJcrNJGWN$rqvGUhu8ITjvErdIA5C//w2R6b/6wAjHbaF7XF8u3lZg1XI3StthPIE6UII08scOFwASMOepCGpgtsYeCpjqb.';
     my $authkeys= authorized_keys();
@@ -152,7 +149,7 @@ sub prep () {
 
 if (!$stage) {
     prep();
-    guest_create($gho,$xl);
+    guest_create($ho,$gho);
 } else {
     $gho= selectguest($gn,$gho);
 }
@@ -162,6 +159,6 @@ if ($stage<2) {
 }
 
 guest_editconfig_nocd($gho,$emptyiso);
-guest_create($gho,$xl);
+guest_create($ho,$gho);
 guest_await_dhcp_tcp($gho,300);
 guest_check_up($gho);
diff --git a/ts-rumpuserxen-demo-xenstorels b/ts-rumpuserxen-demo-xenstorels
index 6698848..69a2186 100755
--- a/ts-rumpuserxen-demo-xenstorels
+++ b/ts-rumpuserxen-demo-xenstorels
@@ -40,7 +40,7 @@ sub arrangepreserve () {
 }
 
 sub start () {
-    guest_create($gho,toolstack($ho));
+    guest_create($ho, $gho);
 
     $domid = guest_find_domid($ho, $gho);
 }
-- 
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 Tue Dec 02 16:24:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFL-0006IA-M7; Tue, 02 Dec 2014 16: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.Campbell@citrix.com>) id 1XvqFK-0006GR-8S
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:14 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	A8/0A-09284-DA7ED745; Tue, 02 Dec 2014 16:24:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!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 23550 invoked from network); 2 Dec 2014 16:24: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;
	2 Dec 2014 16:24:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931579"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwq-0004XO-FI;
	Tue, 02 Dec 2014 16:05:09 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:08 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:51 +0000
Message-ID: <1417536299-1810-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 10/18] Toolstack: Refactor shutdown
	support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
---
 Osstest/Toolstack/libvirt.pm | 6 ++++++
 Osstest/Toolstack/xend.pm    | 1 +
 Osstest/Toolstack/xl.pm      | 7 +++++++
 ts-guest-stop                | 5 +----
 4 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 54d2a6d..d039c06 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -57,4 +57,10 @@ sub consolecmd ($$) {
     return "virsh console $gn";
 }
 
+sub shutdown_wait ($$) {
+    my ($self,$gho) = @_;
+    my $gn = $gho->{Name};
+    die "libvirt shutdown wait not implemented yet."
+}
+
 1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 896d949..d0e1113 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -37,5 +37,6 @@ sub new {
 sub destroy { return &Osstest::Toolstack::xl::destroy; }
 sub create { return &Osstest::Toolstack::xl::create; }
 sub consolecmd { return &Osstest::Toolstack::xl::consolecmd; }
+sub shutdown_wait { return &Osstest::Toolstack::xl::shutdown_wait; }
 
 1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 4997775..ce2456b 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -51,4 +51,11 @@ sub consolecmd ($$) {
     return $self->{Command}." console $gn";
 }
 
+sub shutdown_wait ($$) {
+    my ($self,$gho) = @_;
+    my $ho = $self->{Host};
+    my $gn = $gho->{Name};
+    target_cmd_root($ho,"$self->{Command} shutdown -w $gn", 200);
+}
+
 1;
diff --git a/ts-guest-stop b/ts-guest-stop
index 0e3a863..5a10755 100755
--- a/ts-guest-stop
+++ b/ts-guest-stop
@@ -26,10 +26,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 
 sub stop () {
     guest_checkrunning($ho, $gho) or die "$gho->{Name} not running";
-    target_cmd_root($ho,
-		    toolstack($ho)->{Command}
-		    ." shutdown -w "
-		    .$gho->{Name}, 200);
+    toolstack($ho)->shutdown_wait($gho);
     guest_checkrunning($ho, $gho) and die $gho->{Name};
 }
 
-- 
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 Tue Dec 02 16:24:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFL-0006IA-M7; Tue, 02 Dec 2014 16: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.Campbell@citrix.com>) id 1XvqFK-0006GR-8S
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:14 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	A8/0A-09284-DA7ED745; Tue, 02 Dec 2014 16:24:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!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 23550 invoked from network); 2 Dec 2014 16:24: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;
	2 Dec 2014 16:24:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931579"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwq-0004XO-FI;
	Tue, 02 Dec 2014 16:05:09 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:08 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:51 +0000
Message-ID: <1417536299-1810-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 10/18] Toolstack: Refactor shutdown
	support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
---
 Osstest/Toolstack/libvirt.pm | 6 ++++++
 Osstest/Toolstack/xend.pm    | 1 +
 Osstest/Toolstack/xl.pm      | 7 +++++++
 ts-guest-stop                | 5 +----
 4 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 54d2a6d..d039c06 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -57,4 +57,10 @@ sub consolecmd ($$) {
     return "virsh console $gn";
 }
 
+sub shutdown_wait ($$) {
+    my ($self,$gho) = @_;
+    my $gn = $gho->{Name};
+    die "libvirt shutdown wait not implemented yet."
+}
+
 1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 896d949..d0e1113 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -37,5 +37,6 @@ sub new {
 sub destroy { return &Osstest::Toolstack::xl::destroy; }
 sub create { return &Osstest::Toolstack::xl::create; }
 sub consolecmd { return &Osstest::Toolstack::xl::consolecmd; }
+sub shutdown_wait { return &Osstest::Toolstack::xl::shutdown_wait; }
 
 1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 4997775..ce2456b 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -51,4 +51,11 @@ sub consolecmd ($$) {
     return $self->{Command}." console $gn";
 }
 
+sub shutdown_wait ($$) {
+    my ($self,$gho) = @_;
+    my $ho = $self->{Host};
+    my $gn = $gho->{Name};
+    target_cmd_root($ho,"$self->{Command} shutdown -w $gn", 200);
+}
+
 1;
diff --git a/ts-guest-stop b/ts-guest-stop
index 0e3a863..5a10755 100755
--- a/ts-guest-stop
+++ b/ts-guest-stop
@@ -26,10 +26,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 
 sub stop () {
     guest_checkrunning($ho, $gho) or die "$gho->{Name} not running";
-    target_cmd_root($ho,
-		    toolstack($ho)->{Command}
-		    ." shutdown -w "
-		    .$gho->{Name}, 200);
+    toolstack($ho)->shutdown_wait($gho);
     guest_checkrunning($ho, $gho) and die $gho->{Name};
 }
 
-- 
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 Tue Dec 02 16:24:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1XvqFN-0006JZ-5a; Tue, 02 Dec 2014 16:24: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 1XvqFL-0006HY-99
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:15 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	0B/59-23865-EA7ED745; Tue, 02 Dec 2014 16:24:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417537450!10905338!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7912 invoked from network); 2 Dec 2014 16:24:13 -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;
	2 Dec 2014 16:24:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931576"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwp-0004XL-E3;
	Tue, 02 Dec 2014 16:05:08 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:50 +0000
Message-ID: <1417536299-1810-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 09/18] Toolstack: Refactor consolecmd
	handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm | 6 ++++++
 Osstest/Toolstack/xend.pm    | 1 +
 Osstest/Toolstack/xl.pm      | 6 ++++++
 ts-logs-capture              | 2 +-
 4 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index ea83995..54d2a6d 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -51,4 +51,10 @@ sub create ($$) {
     target_cmd_root($ho, "virsh create --file $cfg.xml", 100);
 }
 
+sub consolecmd ($$) {
+    my ($self,$gho) = @_;
+    my $gn = $gho->{Name};
+    return "virsh console $gn";
+}
+
 1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index c921c20..896d949 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -36,5 +36,6 @@ sub new {
 # Defer to xl driver for most things
 sub destroy { return &Osstest::Toolstack::xl::destroy; }
 sub create { return &Osstest::Toolstack::xl::create; }
+sub consolecmd { return &Osstest::Toolstack::xl::consolecmd; }
 
 1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 12417ca..4997775 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -45,4 +45,10 @@ sub create ($$) {
     target_cmd_root($self->{Host}, $self->{Command}." create $cfg", 100);
 }
 
+sub consolecmd ($$) {
+    my ($self,$gho) = @_;
+    my $gn = $gho->{Name};
+    return $self->{Command}." console $gn";
+}
+
 1;
diff --git a/ts-logs-capture b/ts-logs-capture
index 841ad5a..dbca13a 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -195,7 +195,7 @@ sub fetch_logs_guest ($) {
         logm("cannot find domid: $@");
         return;
     }
-    my $consolecmd= toolstack($ho)->{Command}." console $gho->{Name}";
+    my $consolecmd= toolstack($ho)->consolecmd($gho);
     try_cmd_output_save("sleep 1 | $consolecmd | cat",
                         "guest-$gho->{Name}-console");
 
-- 
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 Tue Dec 02 16:24:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 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 1XvqFN-0006JZ-5a; Tue, 02 Dec 2014 16:24: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 1XvqFL-0006HY-99
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:15 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	0B/59-23865-EA7ED745; Tue, 02 Dec 2014 16:24:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417537450!10905338!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7912 invoked from network); 2 Dec 2014 16:24:13 -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;
	2 Dec 2014 16:24:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931576"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwp-0004XL-E3;
	Tue, 02 Dec 2014 16:05:08 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:50 +0000
Message-ID: <1417536299-1810-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 09/18] Toolstack: Refactor consolecmd
	handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm | 6 ++++++
 Osstest/Toolstack/xend.pm    | 1 +
 Osstest/Toolstack/xl.pm      | 6 ++++++
 ts-logs-capture              | 2 +-
 4 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index ea83995..54d2a6d 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -51,4 +51,10 @@ sub create ($$) {
     target_cmd_root($ho, "virsh create --file $cfg.xml", 100);
 }
 
+sub consolecmd ($$) {
+    my ($self,$gho) = @_;
+    my $gn = $gho->{Name};
+    return "virsh console $gn";
+}
+
 1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index c921c20..896d949 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -36,5 +36,6 @@ sub new {
 # Defer to xl driver for most things
 sub destroy { return &Osstest::Toolstack::xl::destroy; }
 sub create { return &Osstest::Toolstack::xl::create; }
+sub consolecmd { return &Osstest::Toolstack::xl::consolecmd; }
 
 1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 12417ca..4997775 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -45,4 +45,10 @@ sub create ($$) {
     target_cmd_root($self->{Host}, $self->{Command}." create $cfg", 100);
 }
 
+sub consolecmd ($$) {
+    my ($self,$gho) = @_;
+    my $gn = $gho->{Name};
+    return $self->{Command}." console $gn";
+}
+
 1;
diff --git a/ts-logs-capture b/ts-logs-capture
index 841ad5a..dbca13a 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -195,7 +195,7 @@ sub fetch_logs_guest ($) {
         logm("cannot find domid: $@");
         return;
     }
-    my $consolecmd= toolstack($ho)->{Command}." console $gho->{Name}";
+    my $consolecmd= toolstack($ho)->consolecmd($gho);
     try_cmd_output_save("sleep 1 | $consolecmd | cat",
                         "guest-$gho->{Name}-console");
 
-- 
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 Tue Dec 02 16:24:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1XvqFN-0006KE-Sx; Tue, 02 Dec 2014 16:24: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 1XvqFL-0006Hc-BY
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:15 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	0C/5A-17958-EA7ED745; Tue, 02 Dec 2014 16:24:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!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 23770 invoked from network); 2 Dec 2014 16:24:13 -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;
	2 Dec 2014 16:24:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931570"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwo-0004XI-Cv;
	Tue, 02 Dec 2014 16:05:07 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:06 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:49 +0000
Message-ID: <1417536299-1810-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 08/18] Toolstack: Refactor guest
	lifecycle.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement destory/create as per toolstack methods, including implementing the
libvirt version which previously didn't work. To do this we use the virsh
capability to convert an xl/xm style config file into the correct XML.

xend basically calls into the xl helper since they are compatible.

xl/x, uses ->{Command} which will eventually become private.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm       |  5 ++---
 Osstest/Toolstack/libvirt.pm | 20 ++++++++++++++++++++
 Osstest/Toolstack/xend.pm    |  5 +++++
 Osstest/Toolstack/xl.pm      | 13 +++++++++++++
 ts-guest-saverestore         |  2 +-
 ts-guest-start               |  4 +---
 ts-windows-install           |  7 +------
 7 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 616f7ed..16ab4c6 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1326,13 +1326,12 @@ sub guest_await_shutdown ($$$) {
 
 sub guest_destroy ($$) {
     my ($ho,$gho) = @_;
-    target_cmd_root($ho, toolstack($ho)->{Command}." destroy $gho->{Name}", 40);
+    toolstack($ho)->destroy($gho);
 }
 
 sub guest_create ($$) {
     my ($ho,$gho) = @_;
-    my $ts= toolstack($ho);
-    target_cmd_root($ho, $ts->{Command}." create $gho->{CfgPath}", 100);
+    toolstack($ho)->create($gho->{CfgPath});
 }
 
 
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 90fe434..ea83995 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -20,15 +20,35 @@ package Osstest::Toolstack::libvirt;
 use strict;
 use warnings;
 
+use Osstest::TestSupport;
+
 sub new {
     my ($class, $ho, $methname,$asset) = @_;
     return bless { Name => "libvirt",
 		   Host => $ho,
 		   NewDaemons => [qw(libvirtd)],
 		   Dom0MemFixed => 1,
+		   CfgPathVar => 'cfgpath',
 		   Command => 'virsh',
 		   ExtraPackages => [qw(libnl1 libavahi-client3)],
     }, $class;
 }
 
+sub destroy ($$) {
+    my ($self,$gho) = @_;
+    my $gn = $gho->{Name};
+    target_cmd_root($self->{Host}, "virsh destroy $gn", 40);
+}
+
+sub create ($$) {
+    my ($self,$cfg) = @_;
+    my $ho = $self->{Host};
+    my $lcfg = $cfg;
+    $lcfg =~ s,/,-,g;
+    $lcfg = "$ho->{Name}--$lcfg";
+    target_cmd_root($ho, "virsh domxml-from-native xen-xm $cfg > $cfg.xml", 30);
+    target_getfile_root($ho,60,"$cfg.xml", "$stash/$lcfg");
+    target_cmd_root($ho, "virsh create --file $cfg.xml", 100);
+}
+
 1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 881417d..c921c20 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -19,6 +19,7 @@ package Osstest::Toolstack::xend;
 
 use strict;
 use warnings;
+use Osstest::Toolstack::xl;
 
 sub new {
     my ($class, $ho, $methname,$asset) = @_;
@@ -32,4 +33,8 @@ sub new {
     }, $class;
 }
 
+# Defer to xl driver for most things
+sub destroy { return &Osstest::Toolstack::xl::destroy; }
+sub create { return &Osstest::Toolstack::xl::create; }
+
 1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 0b66201..12417ca 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -20,6 +20,8 @@ package Osstest::Toolstack::xl;
 use strict;
 use warnings;
 
+use Osstest::TestSupport;
+
 sub new {
     my ($class, $ho, $methname,$asset) = @_;
     return bless { Name => "xl",
@@ -32,4 +34,15 @@ sub new {
     }, $class;
 }
 
+sub destroy ($$) {
+    my ($self,$gho) = @_;
+    my $gn = $gho->{Name};
+    target_cmd_root($self->{Host}, $self->{Command}." destroy $gn", 40);
+}
+
+sub create ($$) {
+    my ($self,$cfg) = @_;
+    target_cmd_root($self->{Host}, $self->{Command}." create $cfg", 100);
+}
+
 1;
diff --git a/ts-guest-saverestore b/ts-guest-saverestore
index 9e04ae9..8911aed 100755
--- a/ts-guest-saverestore
+++ b/ts-guest-saverestore
@@ -38,7 +38,7 @@ sub restore () {
 		    toolstack($ho)->{Command}
 		    ." restore "
 		    .(toolstack($ho)->{RestoreNeedsConfig} ?
-		      $r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} } : '')
+		      $gho->{CfgPath} : '')
 		    ." image", 200);
     target_ping_check_up($gho);
 }
diff --git a/ts-guest-start b/ts-guest-start
index bfbb734..fb6a174 100755
--- a/ts-guest-start
+++ b/ts-guest-start
@@ -26,9 +26,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 
 sub start () {
     guest_umount_lv($ho, $gho);
-    my $cmd= toolstack($ho)->{Command}." create ".
-        $r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} };
-    target_cmd_root($ho, $cmd, 30);
+    toolstack($ho)->create($r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} });
 }
 
 sub checkstart () {
diff --git a/ts-windows-install b/ts-windows-install
index 4b06310..f12a4f4 100755
--- a/ts-windows-install
+++ b/ts-windows-install
@@ -49,13 +49,8 @@ END
     store_runvar("$gho->{Guest}_pingbroken", 1);
 }
 
-sub start () {
-    target_cmd_root($ho, toolstack($ho)->{Command}.
-                    " create $gho->{CfgPath}", 100);
-}
-
 prep();
-start();
+guest_create($ho,$gho);
 
 guest_await_dhcp_tcp($gho,7000);
 guest_check_up($gho);
-- 
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 Tue Dec 02 16:24:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1XvqFN-0006KE-Sx; Tue, 02 Dec 2014 16:24: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 1XvqFL-0006Hc-BY
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:15 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	0C/5A-17958-EA7ED745; Tue, 02 Dec 2014 16:24:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!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 23770 invoked from network); 2 Dec 2014 16:24:13 -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;
	2 Dec 2014 16:24:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931570"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwo-0004XI-Cv;
	Tue, 02 Dec 2014 16:05:07 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:06 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:49 +0000
Message-ID: <1417536299-1810-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 08/18] Toolstack: Refactor guest
	lifecycle.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement destory/create as per toolstack methods, including implementing the
libvirt version which previously didn't work. To do this we use the virsh
capability to convert an xl/xm style config file into the correct XML.

xend basically calls into the xl helper since they are compatible.

xl/x, uses ->{Command} which will eventually become private.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm       |  5 ++---
 Osstest/Toolstack/libvirt.pm | 20 ++++++++++++++++++++
 Osstest/Toolstack/xend.pm    |  5 +++++
 Osstest/Toolstack/xl.pm      | 13 +++++++++++++
 ts-guest-saverestore         |  2 +-
 ts-guest-start               |  4 +---
 ts-windows-install           |  7 +------
 7 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 616f7ed..16ab4c6 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1326,13 +1326,12 @@ sub guest_await_shutdown ($$$) {
 
 sub guest_destroy ($$) {
     my ($ho,$gho) = @_;
-    target_cmd_root($ho, toolstack($ho)->{Command}." destroy $gho->{Name}", 40);
+    toolstack($ho)->destroy($gho);
 }
 
 sub guest_create ($$) {
     my ($ho,$gho) = @_;
-    my $ts= toolstack($ho);
-    target_cmd_root($ho, $ts->{Command}." create $gho->{CfgPath}", 100);
+    toolstack($ho)->create($gho->{CfgPath});
 }
 
 
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 90fe434..ea83995 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -20,15 +20,35 @@ package Osstest::Toolstack::libvirt;
 use strict;
 use warnings;
 
+use Osstest::TestSupport;
+
 sub new {
     my ($class, $ho, $methname,$asset) = @_;
     return bless { Name => "libvirt",
 		   Host => $ho,
 		   NewDaemons => [qw(libvirtd)],
 		   Dom0MemFixed => 1,
+		   CfgPathVar => 'cfgpath',
 		   Command => 'virsh',
 		   ExtraPackages => [qw(libnl1 libavahi-client3)],
     }, $class;
 }
 
+sub destroy ($$) {
+    my ($self,$gho) = @_;
+    my $gn = $gho->{Name};
+    target_cmd_root($self->{Host}, "virsh destroy $gn", 40);
+}
+
+sub create ($$) {
+    my ($self,$cfg) = @_;
+    my $ho = $self->{Host};
+    my $lcfg = $cfg;
+    $lcfg =~ s,/,-,g;
+    $lcfg = "$ho->{Name}--$lcfg";
+    target_cmd_root($ho, "virsh domxml-from-native xen-xm $cfg > $cfg.xml", 30);
+    target_getfile_root($ho,60,"$cfg.xml", "$stash/$lcfg");
+    target_cmd_root($ho, "virsh create --file $cfg.xml", 100);
+}
+
 1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 881417d..c921c20 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -19,6 +19,7 @@ package Osstest::Toolstack::xend;
 
 use strict;
 use warnings;
+use Osstest::Toolstack::xl;
 
 sub new {
     my ($class, $ho, $methname,$asset) = @_;
@@ -32,4 +33,8 @@ sub new {
     }, $class;
 }
 
+# Defer to xl driver for most things
+sub destroy { return &Osstest::Toolstack::xl::destroy; }
+sub create { return &Osstest::Toolstack::xl::create; }
+
 1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 0b66201..12417ca 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -20,6 +20,8 @@ package Osstest::Toolstack::xl;
 use strict;
 use warnings;
 
+use Osstest::TestSupport;
+
 sub new {
     my ($class, $ho, $methname,$asset) = @_;
     return bless { Name => "xl",
@@ -32,4 +34,15 @@ sub new {
     }, $class;
 }
 
+sub destroy ($$) {
+    my ($self,$gho) = @_;
+    my $gn = $gho->{Name};
+    target_cmd_root($self->{Host}, $self->{Command}." destroy $gn", 40);
+}
+
+sub create ($$) {
+    my ($self,$cfg) = @_;
+    target_cmd_root($self->{Host}, $self->{Command}." create $cfg", 100);
+}
+
 1;
diff --git a/ts-guest-saverestore b/ts-guest-saverestore
index 9e04ae9..8911aed 100755
--- a/ts-guest-saverestore
+++ b/ts-guest-saverestore
@@ -38,7 +38,7 @@ sub restore () {
 		    toolstack($ho)->{Command}
 		    ." restore "
 		    .(toolstack($ho)->{RestoreNeedsConfig} ?
-		      $r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} } : '')
+		      $gho->{CfgPath} : '')
 		    ." image", 200);
     target_ping_check_up($gho);
 }
diff --git a/ts-guest-start b/ts-guest-start
index bfbb734..fb6a174 100755
--- a/ts-guest-start
+++ b/ts-guest-start
@@ -26,9 +26,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 
 sub start () {
     guest_umount_lv($ho, $gho);
-    my $cmd= toolstack($ho)->{Command}." create ".
-        $r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} };
-    target_cmd_root($ho, $cmd, 30);
+    toolstack($ho)->create($r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} });
 }
 
 sub checkstart () {
diff --git a/ts-windows-install b/ts-windows-install
index 4b06310..f12a4f4 100755
--- a/ts-windows-install
+++ b/ts-windows-install
@@ -49,13 +49,8 @@ END
     store_runvar("$gho->{Guest}_pingbroken", 1);
 }
 
-sub start () {
-    target_cmd_root($ho, toolstack($ho)->{Command}.
-                    " create $gho->{CfgPath}", 100);
-}
-
 prep();
-start();
+guest_create($ho,$gho);
 
 guest_await_dhcp_tcp($gho,7000);
 guest_check_up($gho);
-- 
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 Tue Dec 02 16:24:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1XvqFO-0006L9-H0; Tue, 02 Dec 2014 16:24:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqFM-0006I7-4Z
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:16 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	E0/69-23865-FA7ED745; Tue, 02 Dec 2014 16:24:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417537450!10905338!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 8053 invoked from network); 2 Dec 2014 16:24: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;
	2 Dec 2014 16:24:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931582"
Received: from ukmail1.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, 2 Dec 2014 11:05:10 -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 1Xvpwr-0004XR-Gc;
	Tue, 02 Dec 2014 16:05:10 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:52 +0000
Message-ID: <1417536299-1810-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 11/18] Toolstack: Refactor migration
	support 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

Not implemented for libvirt (the check itself that is, the hook is present).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm |  5 +++++
 Osstest/Toolstack/xend.pm    |  3 +++
 Osstest/Toolstack/xl.pm      |  9 +++++++++
 ts-migrate-support-check     | 10 +---------
 4 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index d039c06..75e49d0 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -63,4 +63,9 @@ sub shutdown_wait ($$) {
     die "libvirt shutdown wait not implemented yet."
 }
 
+sub migrate_check ($) {
+    my ($self) = @_;
+    die "Migration check is not yet supported on libvirt.";
+}
+
 1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index d0e1113..e69bb1f 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -39,4 +39,7 @@ sub create { return &Osstest::Toolstack::xl::create; }
 sub consolecmd { return &Osstest::Toolstack::xl::consolecmd; }
 sub shutdown_wait { return &Osstest::Toolstack::xl::shutdown_wait; }
 
+# xend always supported migration
+sub migrate_check ($) { return 0; }
+
 1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index ce2456b..3c59da3 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -58,4 +58,13 @@ sub shutdown_wait ($$) {
     target_cmd_root($ho,"$self->{Command} shutdown -w $gn", 200);
 }
 
+sub migrate_check ($) {
+    my ($self) = @_;
+    my $ho = $self->{Host};
+    my $help = target_cmd_output_root($ho, $self->{Command}." help");
+    my $rc = ($help =~ m/^\s*migrate/m) ? 0 : 1;
+    logm("rc=$rc");
+    return $rc;
+}
+
 1;
diff --git a/ts-migrate-support-check b/ts-migrate-support-check
index c70b77a..cd41f68 100755
--- a/ts-migrate-support-check
+++ b/ts-migrate-support-check
@@ -24,12 +24,4 @@ tsreadconfig();
 
 our $ho = selecthost($ARGV[0]);
 
-# all xend/xm platforms support migration
-exit(0) if toolstack($ho)->{Command} eq "xm";
-
-my $help = target_cmd_output_root($ho, toolstack($ho)->{Command}." help");
-
-my $rc = ($help =~ m/^\s*migrate/m) ? 0 : 1;
-
-logm("rc=$rc");
-exit($rc);
+exit(toolstack($ho)->migrate_check());
-- 
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 Tue Dec 02 16:24:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1XvqFO-0006L9-H0; Tue, 02 Dec 2014 16:24:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqFM-0006I7-4Z
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:16 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	E0/69-23865-FA7ED745; Tue, 02 Dec 2014 16:24:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417537450!10905338!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 8053 invoked from network); 2 Dec 2014 16:24: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;
	2 Dec 2014 16:24:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931582"
Received: from ukmail1.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, 2 Dec 2014 11:05:10 -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 1Xvpwr-0004XR-Gc;
	Tue, 02 Dec 2014 16:05:10 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:52 +0000
Message-ID: <1417536299-1810-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 11/18] Toolstack: Refactor migration
	support 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

Not implemented for libvirt (the check itself that is, the hook is present).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm |  5 +++++
 Osstest/Toolstack/xend.pm    |  3 +++
 Osstest/Toolstack/xl.pm      |  9 +++++++++
 ts-migrate-support-check     | 10 +---------
 4 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index d039c06..75e49d0 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -63,4 +63,9 @@ sub shutdown_wait ($$) {
     die "libvirt shutdown wait not implemented yet."
 }
 
+sub migrate_check ($) {
+    my ($self) = @_;
+    die "Migration check is not yet supported on libvirt.";
+}
+
 1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index d0e1113..e69bb1f 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -39,4 +39,7 @@ sub create { return &Osstest::Toolstack::xl::create; }
 sub consolecmd { return &Osstest::Toolstack::xl::consolecmd; }
 sub shutdown_wait { return &Osstest::Toolstack::xl::shutdown_wait; }
 
+# xend always supported migration
+sub migrate_check ($) { return 0; }
+
 1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index ce2456b..3c59da3 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -58,4 +58,13 @@ sub shutdown_wait ($$) {
     target_cmd_root($ho,"$self->{Command} shutdown -w $gn", 200);
 }
 
+sub migrate_check ($) {
+    my ($self) = @_;
+    my $ho = $self->{Host};
+    my $help = target_cmd_output_root($ho, $self->{Command}." help");
+    my $rc = ($help =~ m/^\s*migrate/m) ? 0 : 1;
+    logm("rc=$rc");
+    return $rc;
+}
+
 1;
diff --git a/ts-migrate-support-check b/ts-migrate-support-check
index c70b77a..cd41f68 100755
--- a/ts-migrate-support-check
+++ b/ts-migrate-support-check
@@ -24,12 +24,4 @@ tsreadconfig();
 
 our $ho = selecthost($ARGV[0]);
 
-# all xend/xm platforms support migration
-exit(0) if toolstack($ho)->{Command} eq "xm";
-
-my $help = target_cmd_output_root($ho, toolstack($ho)->{Command}." help");
-
-my $rc = ($help =~ m/^\s*migrate/m) ? 0 : 1;
-
-logm("rc=$rc");
-exit($rc);
+exit(toolstack($ho)->migrate_check());
-- 
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 Tue Dec 02 16:24:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFP-0006Lv-0t; Tue, 02 Dec 2014 16:24:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqFM-0006IU-Bw
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:16 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	9F/B0-11608-FA7ED745; Tue, 02 Dec 2014 16:24:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!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 23894 invoked from network); 2 Dec 2014 16:24:14 -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;
	2 Dec 2014 16:24:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931589"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpws-0004XU-I0;
	Tue, 02 Dec 2014 16:05:11 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:10 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:53 +0000
Message-ID: <1417536299-1810-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 12/18] Toolstack: Refactor migration
	support.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Note that since the previous patch arranges for
ts-migration-support-check to continue to fail for libvirt the libvirt
code is not actually called yet (and will die if it is). This patch is
mainly included to reduce the number of users of
toolstack()->{Command} closer to zero.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm | 5 +++++
 Osstest/Toolstack/xend.pm    | 1 +
 Osstest/Toolstack/xl.pm      | 9 +++++++++
 ts-guest-localmigrate        | 5 +----
 ts-guest-migrate             | 5 +----
 5 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 75e49d0..7740a89 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -68,4 +68,9 @@ sub migrate_check ($) {
     die "Migration check is not yet supported on libvirt.";
 }
 
+sub migrate ($) {
+    my ($self,$gho,$dst,$to) = @_;
+    die "Migration is not yet supported on libvirt.";
+}
+
 1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index e69bb1f..4b5482f 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -38,6 +38,7 @@ sub destroy { return &Osstest::Toolstack::xl::destroy; }
 sub create { return &Osstest::Toolstack::xl::create; }
 sub consolecmd { return &Osstest::Toolstack::xl::consolecmd; }
 sub shutdown_wait { return &Osstest::Toolstack::xl::shutdown_wait; }
+sub migrate { return &Osstest::Toolstack::xl::migrate; }
 
 # xend always supported migration
 sub migrate_check ($) { return 0; }
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 3c59da3..a6f04bc 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -67,4 +67,13 @@ sub migrate_check ($) {
     return $rc;
 }
 
+sub migrate ($$$$) {
+    my ($self,$gho,$dst,$to) = @_;
+    my $ho = $self->{Host};
+    my $gn = $gho->{Name};
+    target_cmd_root($ho,
+		    $self->{Command}." migrate $gn $dst",
+		    $to);
+}
+
 1;
diff --git a/ts-guest-localmigrate b/ts-guest-localmigrate
index f3381da..caefa11 100755
--- a/ts-guest-localmigrate
+++ b/ts-guest-localmigrate
@@ -32,10 +32,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 
 sub migrate () {
     guest_checkrunning($ho,$gho) or die $gho->{Name};
-    target_cmd_root($ho,
-		    toolstack($ho)->{Command}
-		    ." migrate $gho->{Name} localhost",
-		    $timeout{Migrate});
+    toolstack($ho)->migrate($gho, "localhost", $timeout{Migrate});
 }
 
 guest_await_dhcp_tcp($gho, 5);
diff --git a/ts-guest-migrate b/ts-guest-migrate
index 65e7b42..55d2854 100755
--- a/ts-guest-migrate
+++ b/ts-guest-migrate
@@ -31,10 +31,7 @@ our $gho = selectguest($ARGV[2],$sho);
 sub migrate () {
     guest_checkrunning($sho,$gho) or die $gho->{Name};
     my $err= guest_check_ip($gho);  die "$err $gho->{Name}" if defined $err;
-    target_cmd_root($sho,
-		    toolstack($sho)->{Command}
-		    ." migrate $gho->{Name} $dho->{Name}",
-		    $timeout{Migrate});
+    toolstack($sho)->migrate($gho, $dho->{Name}, $timeout{Migrate});
 }
 
 guest_await_dhcp_tcp($gho, 5);
-- 
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 Tue Dec 02 16:24:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFP-0006Lv-0t; Tue, 02 Dec 2014 16:24:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqFM-0006IU-Bw
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:16 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	9F/B0-11608-FA7ED745; Tue, 02 Dec 2014 16:24:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!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 23894 invoked from network); 2 Dec 2014 16:24:14 -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;
	2 Dec 2014 16:24:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931589"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpws-0004XU-I0;
	Tue, 02 Dec 2014 16:05:11 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:10 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:53 +0000
Message-ID: <1417536299-1810-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 12/18] Toolstack: Refactor migration
	support.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Note that since the previous patch arranges for
ts-migration-support-check to continue to fail for libvirt the libvirt
code is not actually called yet (and will die if it is). This patch is
mainly included to reduce the number of users of
toolstack()->{Command} closer to zero.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm | 5 +++++
 Osstest/Toolstack/xend.pm    | 1 +
 Osstest/Toolstack/xl.pm      | 9 +++++++++
 ts-guest-localmigrate        | 5 +----
 ts-guest-migrate             | 5 +----
 5 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 75e49d0..7740a89 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -68,4 +68,9 @@ sub migrate_check ($) {
     die "Migration check is not yet supported on libvirt.";
 }
 
+sub migrate ($) {
+    my ($self,$gho,$dst,$to) = @_;
+    die "Migration is not yet supported on libvirt.";
+}
+
 1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index e69bb1f..4b5482f 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -38,6 +38,7 @@ sub destroy { return &Osstest::Toolstack::xl::destroy; }
 sub create { return &Osstest::Toolstack::xl::create; }
 sub consolecmd { return &Osstest::Toolstack::xl::consolecmd; }
 sub shutdown_wait { return &Osstest::Toolstack::xl::shutdown_wait; }
+sub migrate { return &Osstest::Toolstack::xl::migrate; }
 
 # xend always supported migration
 sub migrate_check ($) { return 0; }
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 3c59da3..a6f04bc 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -67,4 +67,13 @@ sub migrate_check ($) {
     return $rc;
 }
 
+sub migrate ($$$$) {
+    my ($self,$gho,$dst,$to) = @_;
+    my $ho = $self->{Host};
+    my $gn = $gho->{Name};
+    target_cmd_root($ho,
+		    $self->{Command}." migrate $gn $dst",
+		    $to);
+}
+
 1;
diff --git a/ts-guest-localmigrate b/ts-guest-localmigrate
index f3381da..caefa11 100755
--- a/ts-guest-localmigrate
+++ b/ts-guest-localmigrate
@@ -32,10 +32,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 
 sub migrate () {
     guest_checkrunning($ho,$gho) or die $gho->{Name};
-    target_cmd_root($ho,
-		    toolstack($ho)->{Command}
-		    ." migrate $gho->{Name} localhost",
-		    $timeout{Migrate});
+    toolstack($ho)->migrate($gho, "localhost", $timeout{Migrate});
 }
 
 guest_await_dhcp_tcp($gho, 5);
diff --git a/ts-guest-migrate b/ts-guest-migrate
index 65e7b42..55d2854 100755
--- a/ts-guest-migrate
+++ b/ts-guest-migrate
@@ -31,10 +31,7 @@ our $gho = selectguest($ARGV[2],$sho);
 sub migrate () {
     guest_checkrunning($sho,$gho) or die $gho->{Name};
     my $err= guest_check_ip($gho);  die "$err $gho->{Name}" if defined $err;
-    target_cmd_root($sho,
-		    toolstack($sho)->{Command}
-		    ." migrate $gho->{Name} $dho->{Name}",
-		    $timeout{Migrate});
+    toolstack($sho)->migrate($gho, $dho->{Name}, $timeout{Migrate});
 }
 
 guest_await_dhcp_tcp($gho, 5);
-- 
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 Tue Dec 02 16:24:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFP-0006NL-Ra; Tue, 02 Dec 2014 16:24:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqFM-0006Ip-PX
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:16 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	3F/AA-17735-0B7ED745; Tue, 02 Dec 2014 16:24:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417537452!15384105!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31019 invoked from network); 2 Dec 2014 16:24:15 -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;
	2 Dec 2014 16:24:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931599"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwt-0004XY-JC;
	Tue, 02 Dec 2014 16:05:12 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:54 +0000
Message-ID: <1417536299-1810-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 13/18] Toolstack: Refactor
	save/restore support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Still stubbed out for libvirt.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm |  8 ++++++++
 Osstest/Toolstack/xend.pm    |  2 ++
 Osstest/Toolstack/xl.pm      | 18 ++++++++++++++++++
 ts-guest-saverestore         | 12 ++----------
 4 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 7740a89..8982cc1 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -73,4 +73,12 @@ sub migrate ($) {
     die "Migration is not yet supported on libvirt.";
 }
 
+sub save ($$$$) {
+    die "Save is not yet supported on libvirt.";
+}
+
+sub restore ($$$$$) {
+    die "Restore is not yet supported on libvirt.";
+}
+
 1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 4b5482f..6a5f9e6 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -39,6 +39,8 @@ sub create { return &Osstest::Toolstack::xl::create; }
 sub consolecmd { return &Osstest::Toolstack::xl::consolecmd; }
 sub shutdown_wait { return &Osstest::Toolstack::xl::shutdown_wait; }
 sub migrate { return &Osstest::Toolstack::xl::migrate; }
+sub save { return &Osstest::Toolstack::xl::save; }
+sub restore { return &Osstest::Toolstack::xl::restore; }
 
 # xend always supported migration
 sub migrate_check ($) { return 0; }
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index a6f04bc..adda0c7 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -76,4 +76,22 @@ sub migrate ($$$$) {
 		    $to);
 }
 
+sub save ($$$$) {
+    my ($self,$gho,$f,$to) = @_;
+    my $ho = $self->{Host};
+    my $gn = $gho->{Name};
+    target_cmd_root($ho,$self->{Command}." save $gn $f", $to);
+}
+
+sub restore ($$$$$) {
+    my ($self,$gho,$f,$cfg,$to) = @_;
+    my $ho = $self->{Host};
+    my $gn = $gho->{Name};
+    target_cmd_root($ho,
+		    $self->{Command}
+		    ." restore "
+		    .($self->{RestoreNeedsConfig} ? $cfg : '')
+		    ." $f", $to);
+}
+
 1;
diff --git a/ts-guest-saverestore b/ts-guest-saverestore
index 8911aed..07baa93 100755
--- a/ts-guest-saverestore
+++ b/ts-guest-saverestore
@@ -27,19 +27,11 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 sub save () {
     guest_checkrunning($ho,$gho) or die $gho->{Name};
     my $err= guest_check_ip($gho);  die "$err $gho->{Name}" if defined $err;
-    target_cmd_root($ho,
-		    toolstack($ho)->{Command}
-		    ." save $gho->{Name} image",
-		    200);
+    toolstack($ho)->save($gho,"image",200);
     target_ping_check_down($gho);
 }
 sub restore () {
-    target_cmd_root($ho,
-		    toolstack($ho)->{Command}
-		    ." restore "
-		    .(toolstack($ho)->{RestoreNeedsConfig} ?
-		      $gho->{CfgPath} : '')
-		    ." image", 200);
+    toolstack($ho)->restore($gho,"image",$gho->{CfgPath},200);
     target_ping_check_up($gho);
 }
 
-- 
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 Tue Dec 02 16:24:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFP-0006NL-Ra; Tue, 02 Dec 2014 16:24:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqFM-0006Ip-PX
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:16 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	3F/AA-17735-0B7ED745; Tue, 02 Dec 2014 16:24:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417537452!15384105!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31019 invoked from network); 2 Dec 2014 16:24:15 -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;
	2 Dec 2014 16:24:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931599"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwt-0004XY-JC;
	Tue, 02 Dec 2014 16:05:12 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:54 +0000
Message-ID: <1417536299-1810-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 13/18] Toolstack: Refactor
	save/restore support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Still stubbed out for libvirt.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm |  8 ++++++++
 Osstest/Toolstack/xend.pm    |  2 ++
 Osstest/Toolstack/xl.pm      | 18 ++++++++++++++++++
 ts-guest-saverestore         | 12 ++----------
 4 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 7740a89..8982cc1 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -73,4 +73,12 @@ sub migrate ($) {
     die "Migration is not yet supported on libvirt.";
 }
 
+sub save ($$$$) {
+    die "Save is not yet supported on libvirt.";
+}
+
+sub restore ($$$$$) {
+    die "Restore is not yet supported on libvirt.";
+}
+
 1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 4b5482f..6a5f9e6 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -39,6 +39,8 @@ sub create { return &Osstest::Toolstack::xl::create; }
 sub consolecmd { return &Osstest::Toolstack::xl::consolecmd; }
 sub shutdown_wait { return &Osstest::Toolstack::xl::shutdown_wait; }
 sub migrate { return &Osstest::Toolstack::xl::migrate; }
+sub save { return &Osstest::Toolstack::xl::save; }
+sub restore { return &Osstest::Toolstack::xl::restore; }
 
 # xend always supported migration
 sub migrate_check ($) { return 0; }
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index a6f04bc..adda0c7 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -76,4 +76,22 @@ sub migrate ($$$$) {
 		    $to);
 }
 
+sub save ($$$$) {
+    my ($self,$gho,$f,$to) = @_;
+    my $ho = $self->{Host};
+    my $gn = $gho->{Name};
+    target_cmd_root($ho,$self->{Command}." save $gn $f", $to);
+}
+
+sub restore ($$$$$) {
+    my ($self,$gho,$f,$cfg,$to) = @_;
+    my $ho = $self->{Host};
+    my $gn = $gho->{Name};
+    target_cmd_root($ho,
+		    $self->{Command}
+		    ." restore "
+		    .($self->{RestoreNeedsConfig} ? $cfg : '')
+		    ." $f", $to);
+}
+
 1;
diff --git a/ts-guest-saverestore b/ts-guest-saverestore
index 8911aed..07baa93 100755
--- a/ts-guest-saverestore
+++ b/ts-guest-saverestore
@@ -27,19 +27,11 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 sub save () {
     guest_checkrunning($ho,$gho) or die $gho->{Name};
     my $err= guest_check_ip($gho);  die "$err $gho->{Name}" if defined $err;
-    target_cmd_root($ho,
-		    toolstack($ho)->{Command}
-		    ." save $gho->{Name} image",
-		    200);
+    toolstack($ho)->save($gho,"image",200);
     target_ping_check_down($gho);
 }
 sub restore () {
-    target_cmd_root($ho,
-		    toolstack($ho)->{Command}
-		    ." restore "
-		    .(toolstack($ho)->{RestoreNeedsConfig} ?
-		      $gho->{CfgPath} : '')
-		    ." image", 200);
+    toolstack($ho)->restore($gho,"image",$gho->{CfgPath},200);
     target_ping_check_up($gho);
 }
 
-- 
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 Tue Dec 02 16:24:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFQ-0006OA-AS; Tue, 02 Dec 2014 16:24: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 1XvqFM-0006Io-QH
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:16 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	8C/D1-25547-0B7ED745; Tue, 02 Dec 2014 16:24:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417537450!10905338!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 8196 invoked from network); 2 Dec 2014 16:24: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;
	2 Dec 2014 16:24:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931607"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwv-0004Xk-Ls;
	Tue, 02 Dec 2014 16:05:14 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:13 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:56 +0000
Message-ID: <1417536299-1810-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 15/18] libvirt: Implement
	shutdown_wait
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

virsh does not include a --wait option to shutdown as xl and xm do, so
we implement it by hand.

Needs new guest_await_destroy helper. Note the guest_await_shutdown
requires on_shutdown='preserve'

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm       | 7 ++++++-
 Osstest/Toolstack/libvirt.pm | 4 +++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 16ab4c6..456cf49 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -93,7 +93,7 @@ BEGIN {
                       guest_checkrunning guest_check_ip guest_find_ether
                       guest_find_domid guest_check_up guest_check_up_quick
                       guest_get_state guest_await_reboot
-                      guest_await_shutdown guest_destroy
+                      guest_await_shutdown guest_await_destroy guest_destroy
                       guest_vncsnapshot_begin guest_vncsnapshot_stash
 		      guest_check_remus_ok guest_editconfig
                       host_involves_pcipassthrough host_get_pcipassthrough_devs
@@ -1324,6 +1324,11 @@ sub guest_await_shutdown ($$$) {
     return guest_await_state($ho,$gho, "shutdown", "s", $timeout);
 }
 
+sub guest_await_destroy ($$$) {
+    my ($ho,$gho, $timeout) = @_;
+    return guest_await_state($ho,$gho, "destroy", "", $timeout);
+}
+
 sub guest_destroy ($$) {
     my ($ho,$gho) = @_;
     toolstack($ho)->destroy($gho);
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 8982cc1..c18f467 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -59,8 +59,10 @@ sub consolecmd ($$) {
 
 sub shutdown_wait ($$) {
     my ($self,$gho) = @_;
+    my $ho = $self->{Host};
     my $gn = $gho->{Name};
-    die "libvirt shutdown wait not implemented yet."
+    target_cmd_root($ho, "virsh shutdown $gn", 30);
+    guest_await_destroy($ho,$gho,200);
 }
 
 sub migrate_check ($) {
-- 
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 Tue Dec 02 16:24:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFQ-0006OA-AS; Tue, 02 Dec 2014 16:24: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 1XvqFM-0006Io-QH
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:16 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	8C/D1-25547-0B7ED745; Tue, 02 Dec 2014 16:24:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417537450!10905338!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 8196 invoked from network); 2 Dec 2014 16:24: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;
	2 Dec 2014 16:24:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931607"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwv-0004Xk-Ls;
	Tue, 02 Dec 2014 16:05:14 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:13 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:56 +0000
Message-ID: <1417536299-1810-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 15/18] libvirt: Implement
	shutdown_wait
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

virsh does not include a --wait option to shutdown as xl and xm do, so
we implement it by hand.

Needs new guest_await_destroy helper. Note the guest_await_shutdown
requires on_shutdown='preserve'

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm       | 7 ++++++-
 Osstest/Toolstack/libvirt.pm | 4 +++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 16ab4c6..456cf49 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -93,7 +93,7 @@ BEGIN {
                       guest_checkrunning guest_check_ip guest_find_ether
                       guest_find_domid guest_check_up guest_check_up_quick
                       guest_get_state guest_await_reboot
-                      guest_await_shutdown guest_destroy
+                      guest_await_shutdown guest_await_destroy guest_destroy
                       guest_vncsnapshot_begin guest_vncsnapshot_stash
 		      guest_check_remus_ok guest_editconfig
                       host_involves_pcipassthrough host_get_pcipassthrough_devs
@@ -1324,6 +1324,11 @@ sub guest_await_shutdown ($$$) {
     return guest_await_state($ho,$gho, "shutdown", "s", $timeout);
 }
 
+sub guest_await_destroy ($$$) {
+    my ($ho,$gho, $timeout) = @_;
+    return guest_await_state($ho,$gho, "destroy", "", $timeout);
+}
+
 sub guest_destroy ($$) {
     my ($ho,$gho) = @_;
     toolstack($ho)->destroy($gho);
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 8982cc1..c18f467 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -59,8 +59,10 @@ sub consolecmd ($$) {
 
 sub shutdown_wait ($$) {
     my ($self,$gho) = @_;
+    my $ho = $self->{Host};
     my $gn = $gho->{Name};
-    die "libvirt shutdown wait not implemented yet."
+    target_cmd_root($ho, "virsh shutdown $gn", 30);
+    guest_await_destroy($ho,$gho,200);
 }
 
 sub migrate_check ($) {
-- 
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 Tue Dec 02 16:24:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1XvqFQ-0006P2-Ss; Tue, 02 Dec 2014 16:24: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 1XvqFM-0006J1-Tn
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:17 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	AC/7E-18267-0B7ED745; Tue, 02 Dec 2014 16:24:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!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 23956 invoked from network); 2 Dec 2014 16:24:15 -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;
	2 Dec 2014 16:24:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931618"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwx-0004Xq-OM;
	Tue, 02 Dec 2014 16:05:16 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:58 +0000
Message-ID: <1417536299-1810-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 17/18] ts-guest-start: Use
	guest_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This allows us to abolish CfgPathVar which was inconsistently used,
appears redundant with $gho->{CfgPath} and in any case never set to
anything other than 'cfgpath'.

I suppose it was intended to deal with toolstacks with a cfg format
completely dissimilar to xm/xl's. I think if this arises in a future
toolstack this functionality could be reintroduced pretty trivially
via the toolstack abstraction which is added by this series.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm | 1 -
 Osstest/Toolstack/xend.pm    | 1 -
 Osstest/Toolstack/xl.pm      | 1 -
 ts-guest-start               | 2 +-
 4 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index e50238d..8030aeb 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -28,7 +28,6 @@ sub new {
 		   Host => $ho,
 		   NewDaemons => [qw(libvirtd)],
 		   Dom0MemFixed => 1,
-		   CfgPathVar => 'cfgpath',
 		   ExtraPackages => [qw(libnl1 libavahi-client3)],
     }, $class;
 }
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 97c6da6..d76f650 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -28,7 +28,6 @@ sub new {
 		   NewDaemons => [qw(xend)],
 		   OldDaemonInitd => 'xend',
 		   _Command => 'xm',
-		   CfgPathVar => 'cfgpath',
 		   Dom0MemFixed => 1,
     }, $class;
 }
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 5480f8f..cd6ba15 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -29,7 +29,6 @@ sub new {
 		   NewDaemons => [],
 		   Dom0MemFixed => 1,
 		   _Command => 'xl',
-		   CfgPathVar => 'cfgpath',
 		   RestoreNeedsConfig => 1,
     }, $class;
 }
diff --git a/ts-guest-start b/ts-guest-start
index fb6a174..19d6830 100755
--- a/ts-guest-start
+++ b/ts-guest-start
@@ -26,7 +26,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 
 sub start () {
     guest_umount_lv($ho, $gho);
-    toolstack($ho)->create($r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} });
+    guest_create($ho,$gho);
 }
 
 sub checkstart () {
-- 
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 Tue Dec 02 16:24:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1XvqFQ-0006P2-Ss; Tue, 02 Dec 2014 16:24: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 1XvqFM-0006J1-Tn
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:17 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	AC/7E-18267-0B7ED745; Tue, 02 Dec 2014 16:24:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!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 23956 invoked from network); 2 Dec 2014 16:24:15 -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;
	2 Dec 2014 16:24:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931618"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwx-0004Xq-OM;
	Tue, 02 Dec 2014 16:05:16 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:58 +0000
Message-ID: <1417536299-1810-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 17/18] ts-guest-start: Use
	guest_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This allows us to abolish CfgPathVar which was inconsistently used,
appears redundant with $gho->{CfgPath} and in any case never set to
anything other than 'cfgpath'.

I suppose it was intended to deal with toolstacks with a cfg format
completely dissimilar to xm/xl's. I think if this arises in a future
toolstack this functionality could be reintroduced pretty trivially
via the toolstack abstraction which is added by this series.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm | 1 -
 Osstest/Toolstack/xend.pm    | 1 -
 Osstest/Toolstack/xl.pm      | 1 -
 ts-guest-start               | 2 +-
 4 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index e50238d..8030aeb 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -28,7 +28,6 @@ sub new {
 		   Host => $ho,
 		   NewDaemons => [qw(libvirtd)],
 		   Dom0MemFixed => 1,
-		   CfgPathVar => 'cfgpath',
 		   ExtraPackages => [qw(libnl1 libavahi-client3)],
     }, $class;
 }
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 97c6da6..d76f650 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -28,7 +28,6 @@ sub new {
 		   NewDaemons => [qw(xend)],
 		   OldDaemonInitd => 'xend',
 		   _Command => 'xm',
-		   CfgPathVar => 'cfgpath',
 		   Dom0MemFixed => 1,
     }, $class;
 }
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 5480f8f..cd6ba15 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -29,7 +29,6 @@ sub new {
 		   NewDaemons => [],
 		   Dom0MemFixed => 1,
 		   _Command => 'xl',
-		   CfgPathVar => 'cfgpath',
 		   RestoreNeedsConfig => 1,
     }, $class;
 }
diff --git a/ts-guest-start b/ts-guest-start
index fb6a174..19d6830 100755
--- a/ts-guest-start
+++ b/ts-guest-start
@@ -26,7 +26,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 
 sub start () {
     guest_umount_lv($ho, $gho);
-    toolstack($ho)->create($r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} });
+    guest_create($ho,$gho);
 }
 
 sub checkstart () {
-- 
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 Tue Dec 02 16:24:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFR-0006Qd-J9; Tue, 02 Dec 2014 16:24: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 1XvqFN-0006JX-JN
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:17 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	4A/78-07724-0B7ED745; Tue, 02 Dec 2014 16:24:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417537450!10905338!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 8348 invoked from network); 2 Dec 2014 16:24:16 -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;
	2 Dec 2014 16:24:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931603"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwu-0004Xb-KT;
	Tue, 02 Dec 2014 16:05:13 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:12 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:55 +0000
Message-ID: <1417536299-1810-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 14/18] libvirt: Implement initscript
	restart which has some hope of working.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-libvirt-build | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/ts-libvirt-build b/ts-libvirt-build
index 940c034..878d4e2 100755
--- a/ts-libvirt-build
+++ b/ts-libvirt-build
@@ -140,8 +140,10 @@ case "$1" in
 	[ "$VERBOSE" != no ] && log_end_msg $?
 	;;
   restart)
-	stop
-	start
+	[ "$VERBOSE" != no ] && log_daemon_msg "Restarting $DESC" "$DAEMON"
+	start-stop-daemon --oknodo --stop --pidfile $PIDFILE --exec $DAEMON
+	start-stop-daemon --start --pidfile $PIDFILE --exec $DAEMON -- -d $libvirtd_opts
+	[ "$VERBOSE" != no ] && log_end_msg $?
 	;;
   reload|force-reload)
 	start-stop-daemon --stop --signal 1 --quiet --pidfile \
-- 
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 Tue Dec 02 16:24:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFR-0006Qd-J9; Tue, 02 Dec 2014 16:24: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 1XvqFN-0006JX-JN
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:17 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	4A/78-07724-0B7ED745; Tue, 02 Dec 2014 16:24:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417537450!10905338!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 8348 invoked from network); 2 Dec 2014 16:24:16 -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;
	2 Dec 2014 16:24:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931603"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwu-0004Xb-KT;
	Tue, 02 Dec 2014 16:05:13 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:12 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:55 +0000
Message-ID: <1417536299-1810-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 14/18] libvirt: Implement initscript
	restart which has some hope of working.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-libvirt-build | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/ts-libvirt-build b/ts-libvirt-build
index 940c034..878d4e2 100755
--- a/ts-libvirt-build
+++ b/ts-libvirt-build
@@ -140,8 +140,10 @@ case "$1" in
 	[ "$VERBOSE" != no ] && log_end_msg $?
 	;;
   restart)
-	stop
-	start
+	[ "$VERBOSE" != no ] && log_daemon_msg "Restarting $DESC" "$DAEMON"
+	start-stop-daemon --oknodo --stop --pidfile $PIDFILE --exec $DAEMON
+	start-stop-daemon --start --pidfile $PIDFILE --exec $DAEMON -- -d $libvirtd_opts
+	[ "$VERBOSE" != no ] && log_end_msg $?
 	;;
   reload|force-reload)
 	start-stop-daemon --stop --signal 1 --quiet --pidfile \
-- 
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 Tue Dec 02 16:24:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFS-0006RY-4o; Tue, 02 Dec 2014 16:24: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 1XvqFN-0006Jd-ND
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:17 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	BB/A3-17694-1B7ED745; Tue, 02 Dec 2014 16:24:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417537452!15384105!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 31082 invoked from network); 2 Dec 2014 16:24:16 -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;
	2 Dec 2014 16:24:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931622"
Received: from ukmail1.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, 2 Dec 2014 11:05:18 -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 1Xvpwy-0004Xy-Pm;
	Tue, 02 Dec 2014 16:05:17 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:16 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:59 +0000
Message-ID: <1417536299-1810-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 18/18] WIP: libvirt: migration +
	save/restore support.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Note that this remains stubbed out, since making it actually work
requires more work (i.e. I need to figure out what is involved, seem
to need TLS and a CA etc...)

Appears to need gnutls enabling for migration, even to localhost.

NB haven't managed to get this actually working. With GNUtls enabled
it wants a CA certificate installed:
    error: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory

Other attempts give:
    # virsh migrate --live debian.guest.osstest xen://
    error: Requested operation is not valid: domain 'debian.guest.osstest' is already active

Also need to try tcp:// based, by bodging libvirtd.conf to turn on
tcp.

TODO: Ask Jim for advice...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm | 17 +++++++++++++++++
 ts-libvirt-build             |  3 +++
 ts-xen-build-prep            |  1 +
 3 files changed, 21 insertions(+)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 8030aeb..e427f63 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -65,12 +65,29 @@ sub shutdown_wait ($$) {
 
 sub migrate_check ($) {
     my ($self) = @_;
+
+    # Localhost migration currently requires more setup on our side
+    # than we currently do. Once that is sorted out the code below
+    # will correctly determine whether the version of libvirt under
+    # test even supports the possibility.
     die "Migration check is not yet supported on libvirt.";
+
+    my $ho = $self->{Host};
+    my $caps = target_cmd_output_root($ho, "virsh capabilities");
+    my $rc = ($caps =~ m/<migration_features>/) ? 0 : 1;
+    logm("rc=$rc");
+    return $rc;
 }
 
 sub migrate ($) {
     my ($self,$gho,$dst,$to) = @_;
     die "Migration is not yet supported on libvirt.";
+
+    my $ho = $self->{Host};
+    my $gn = $gho->{Name};
+    target_cmd_root($ho,
+		    "virsh migrate $gn $dst",
+		    $to);
 }
 
 sub save ($$$$) {
diff --git a/ts-libvirt-build b/ts-libvirt-build
index 878d4e2..c160533 100755
--- a/ts-libvirt-build
+++ b/ts-libvirt-build
@@ -55,6 +55,7 @@ sub config() {
             ./autogen.sh --no-git \\
                          --with-libxl --without-xen --without-xenapi --without-selinux \\
                          --without-lxc --without-vbox --without-uml \\
+                         --with-gnutls \\
                          --sysconfdir=/etc --localstatedir=/var #/
 END
 }
@@ -80,6 +81,8 @@ END
                                  $builddir.'/dist/etc/init.d/libvirtd');
     target_cmd_build($ho, 60, $builddir, <<END);
         chmod +x $builddir/dist/etc/init.d/libvirtd
+	#sed -i -e 's/\#\?listen_tls = .*/listen_tls = 0/g' $builddir/dist/etc/libvirt/libvirtd.conf
+	#sed -i -e 's/\#\?listen_tcp = .*/listen_tcp = 1/g' $builddir/dist/etc/libvirt/libvirtd.conf
 END
 }
 
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 05a7857..ae60b30 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -174,6 +174,7 @@ sub prep () {
                                libpci-dev libncurses5-dev libssl-dev python-dev
                                libx11-dev git-core uuid-dev gettext gawk
                                libsdl-dev libyajl-dev libaio-dev libpixman-1-dev
+                               libgnutls-dev
                                libglib2.0-dev liblzma-dev pkg-config
                                autoconf automake libtool xsltproc
                                libxml2-utils libxml2-dev libnl-dev
-- 
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 Tue Dec 02 16:24:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqFS-0006RY-4o; Tue, 02 Dec 2014 16:24: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 1XvqFN-0006Jd-ND
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:17 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	BB/A3-17694-1B7ED745; Tue, 02 Dec 2014 16:24:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417537452!15384105!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 31082 invoked from network); 2 Dec 2014 16:24:16 -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;
	2 Dec 2014 16:24:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931622"
Received: from ukmail1.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, 2 Dec 2014 11:05:18 -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 1Xvpwy-0004Xy-Pm;
	Tue, 02 Dec 2014 16:05:17 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:16 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:59 +0000
Message-ID: <1417536299-1810-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 18/18] WIP: libvirt: migration +
	save/restore support.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Note that this remains stubbed out, since making it actually work
requires more work (i.e. I need to figure out what is involved, seem
to need TLS and a CA etc...)

Appears to need gnutls enabling for migration, even to localhost.

NB haven't managed to get this actually working. With GNUtls enabled
it wants a CA certificate installed:
    error: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory

Other attempts give:
    # virsh migrate --live debian.guest.osstest xen://
    error: Requested operation is not valid: domain 'debian.guest.osstest' is already active

Also need to try tcp:// based, by bodging libvirtd.conf to turn on
tcp.

TODO: Ask Jim for advice...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm | 17 +++++++++++++++++
 ts-libvirt-build             |  3 +++
 ts-xen-build-prep            |  1 +
 3 files changed, 21 insertions(+)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 8030aeb..e427f63 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -65,12 +65,29 @@ sub shutdown_wait ($$) {
 
 sub migrate_check ($) {
     my ($self) = @_;
+
+    # Localhost migration currently requires more setup on our side
+    # than we currently do. Once that is sorted out the code below
+    # will correctly determine whether the version of libvirt under
+    # test even supports the possibility.
     die "Migration check is not yet supported on libvirt.";
+
+    my $ho = $self->{Host};
+    my $caps = target_cmd_output_root($ho, "virsh capabilities");
+    my $rc = ($caps =~ m/<migration_features>/) ? 0 : 1;
+    logm("rc=$rc");
+    return $rc;
 }
 
 sub migrate ($) {
     my ($self,$gho,$dst,$to) = @_;
     die "Migration is not yet supported on libvirt.";
+
+    my $ho = $self->{Host};
+    my $gn = $gho->{Name};
+    target_cmd_root($ho,
+		    "virsh migrate $gn $dst",
+		    $to);
 }
 
 sub save ($$$$) {
diff --git a/ts-libvirt-build b/ts-libvirt-build
index 878d4e2..c160533 100755
--- a/ts-libvirt-build
+++ b/ts-libvirt-build
@@ -55,6 +55,7 @@ sub config() {
             ./autogen.sh --no-git \\
                          --with-libxl --without-xen --without-xenapi --without-selinux \\
                          --without-lxc --without-vbox --without-uml \\
+                         --with-gnutls \\
                          --sysconfdir=/etc --localstatedir=/var #/
 END
 }
@@ -80,6 +81,8 @@ END
                                  $builddir.'/dist/etc/init.d/libvirtd');
     target_cmd_build($ho, 60, $builddir, <<END);
         chmod +x $builddir/dist/etc/init.d/libvirtd
+	#sed -i -e 's/\#\?listen_tls = .*/listen_tls = 0/g' $builddir/dist/etc/libvirt/libvirtd.conf
+	#sed -i -e 's/\#\?listen_tcp = .*/listen_tcp = 1/g' $builddir/dist/etc/libvirt/libvirtd.conf
 END
 }
 
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 05a7857..ae60b30 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -174,6 +174,7 @@ sub prep () {
                                libpci-dev libncurses5-dev libssl-dev python-dev
                                libx11-dev git-core uuid-dev gettext gawk
                                libsdl-dev libyajl-dev libaio-dev libpixman-1-dev
+                               libgnutls-dev
                                libglib2.0-dev liblzma-dev pkg-config
                                autoconf automake libtool xsltproc
                                libxml2-utils libxml2-dev libnl-dev
-- 
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 Tue Dec 02 16:24:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1XvqFS-0006Sy-SL; Tue, 02 Dec 2014 16:24: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 1XvqFN-0006Jf-O8
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:17 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	4A/81-05632-1B7ED745; Tue, 02 Dec 2014 16:24:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24059 invoked from network); 2 Dec 2014 16:24:16 -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;
	2 Dec 2014 16:24:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931610"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpww-0004Xn-My;
	Tue, 02 Dec 2014 16:05:15 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:57 +0000
Message-ID: <1417536299-1810-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 16/18] Toolstack: Remove Command
	field for all toolstacks.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Nothing in generic code uses this now, so remove.

xl+xend retain as _Command for internal use only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm |  1 -
 Osstest/Toolstack/xend.pm    |  2 +-
 Osstest/Toolstack/xl.pm      | 18 +++++++++---------
 3 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index c18f467..e50238d 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -29,7 +29,6 @@ sub new {
 		   NewDaemons => [qw(libvirtd)],
 		   Dom0MemFixed => 1,
 		   CfgPathVar => 'cfgpath',
-		   Command => 'virsh',
 		   ExtraPackages => [qw(libnl1 libavahi-client3)],
     }, $class;
 }
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 6a5f9e6..97c6da6 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -27,7 +27,7 @@ sub new {
 		   Host => $ho,
 		   NewDaemons => [qw(xend)],
 		   OldDaemonInitd => 'xend',
-		   Command => 'xm',
+		   _Command => 'xm',
 		   CfgPathVar => 'cfgpath',
 		   Dom0MemFixed => 1,
     }, $class;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index adda0c7..5480f8f 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -28,7 +28,7 @@ sub new {
 		   Host => $ho,
 		   NewDaemons => [],
 		   Dom0MemFixed => 1,
-		   Command => 'xl',
+		   _Command => 'xl',
 		   CfgPathVar => 'cfgpath',
 		   RestoreNeedsConfig => 1,
     }, $class;
@@ -37,31 +37,31 @@ sub new {
 sub destroy ($$) {
     my ($self,$gho) = @_;
     my $gn = $gho->{Name};
-    target_cmd_root($self->{Host}, $self->{Command}." destroy $gn", 40);
+    target_cmd_root($self->{Host}, $self->{_Command}." destroy $gn", 40);
 }
 
 sub create ($$) {
     my ($self,$cfg) = @_;
-    target_cmd_root($self->{Host}, $self->{Command}." create $cfg", 100);
+    target_cmd_root($self->{Host}, $self->{_Command}." create $cfg", 100);
 }
 
 sub consolecmd ($$) {
     my ($self,$gho) = @_;
     my $gn = $gho->{Name};
-    return $self->{Command}." console $gn";
+    return $self->{_Command}." console $gn";
 }
 
 sub shutdown_wait ($$) {
     my ($self,$gho) = @_;
     my $ho = $self->{Host};
     my $gn = $gho->{Name};
-    target_cmd_root($ho,"$self->{Command} shutdown -w $gn", 200);
+    target_cmd_root($ho,"$self->{_Command} shutdown -w $gn", 200);
 }
 
 sub migrate_check ($) {
     my ($self) = @_;
     my $ho = $self->{Host};
-    my $help = target_cmd_output_root($ho, $self->{Command}." help");
+    my $help = target_cmd_output_root($ho, $self->{_Command}." help");
     my $rc = ($help =~ m/^\s*migrate/m) ? 0 : 1;
     logm("rc=$rc");
     return $rc;
@@ -72,7 +72,7 @@ sub migrate ($$$$) {
     my $ho = $self->{Host};
     my $gn = $gho->{Name};
     target_cmd_root($ho,
-		    $self->{Command}." migrate $gn $dst",
+		    $self->{_Command}." migrate $gn $dst",
 		    $to);
 }
 
@@ -80,7 +80,7 @@ sub save ($$$$) {
     my ($self,$gho,$f,$to) = @_;
     my $ho = $self->{Host};
     my $gn = $gho->{Name};
-    target_cmd_root($ho,$self->{Command}." save $gn $f", $to);
+    target_cmd_root($ho,$self->{_Command}." save $gn $f", $to);
 }
 
 sub restore ($$$$$) {
@@ -88,7 +88,7 @@ sub restore ($$$$$) {
     my $ho = $self->{Host};
     my $gn = $gho->{Name};
     target_cmd_root($ho,
-		    $self->{Command}
+		    $self->{_Command}
 		    ." restore "
 		    .($self->{RestoreNeedsConfig} ? $cfg : '')
 		    ." $f", $to);
-- 
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 Tue Dec 02 16:24:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1XvqFS-0006Sy-SL; Tue, 02 Dec 2014 16:24: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 1XvqFN-0006Jf-O8
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:24:17 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	4A/81-05632-1B7ED745; Tue, 02 Dec 2014 16:24:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537447!15360642!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24059 invoked from network); 2 Dec 2014 16:24:16 -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;
	2 Dec 2014 16:24:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198931610"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpww-0004Xn-My;
	Tue, 02 Dec 2014 16:05:15 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:57 +0000
Message-ID: <1417536299-1810-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 16/18] Toolstack: Remove Command
	field for all toolstacks.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Nothing in generic code uses this now, so remove.

xl+xend retain as _Command for internal use only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Toolstack/libvirt.pm |  1 -
 Osstest/Toolstack/xend.pm    |  2 +-
 Osstest/Toolstack/xl.pm      | 18 +++++++++---------
 3 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index c18f467..e50238d 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -29,7 +29,6 @@ sub new {
 		   NewDaemons => [qw(libvirtd)],
 		   Dom0MemFixed => 1,
 		   CfgPathVar => 'cfgpath',
-		   Command => 'virsh',
 		   ExtraPackages => [qw(libnl1 libavahi-client3)],
     }, $class;
 }
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index 6a5f9e6..97c6da6 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -27,7 +27,7 @@ sub new {
 		   Host => $ho,
 		   NewDaemons => [qw(xend)],
 		   OldDaemonInitd => 'xend',
-		   Command => 'xm',
+		   _Command => 'xm',
 		   CfgPathVar => 'cfgpath',
 		   Dom0MemFixed => 1,
     }, $class;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index adda0c7..5480f8f 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -28,7 +28,7 @@ sub new {
 		   Host => $ho,
 		   NewDaemons => [],
 		   Dom0MemFixed => 1,
-		   Command => 'xl',
+		   _Command => 'xl',
 		   CfgPathVar => 'cfgpath',
 		   RestoreNeedsConfig => 1,
     }, $class;
@@ -37,31 +37,31 @@ sub new {
 sub destroy ($$) {
     my ($self,$gho) = @_;
     my $gn = $gho->{Name};
-    target_cmd_root($self->{Host}, $self->{Command}." destroy $gn", 40);
+    target_cmd_root($self->{Host}, $self->{_Command}." destroy $gn", 40);
 }
 
 sub create ($$) {
     my ($self,$cfg) = @_;
-    target_cmd_root($self->{Host}, $self->{Command}." create $cfg", 100);
+    target_cmd_root($self->{Host}, $self->{_Command}." create $cfg", 100);
 }
 
 sub consolecmd ($$) {
     my ($self,$gho) = @_;
     my $gn = $gho->{Name};
-    return $self->{Command}." console $gn";
+    return $self->{_Command}." console $gn";
 }
 
 sub shutdown_wait ($$) {
     my ($self,$gho) = @_;
     my $ho = $self->{Host};
     my $gn = $gho->{Name};
-    target_cmd_root($ho,"$self->{Command} shutdown -w $gn", 200);
+    target_cmd_root($ho,"$self->{_Command} shutdown -w $gn", 200);
 }
 
 sub migrate_check ($) {
     my ($self) = @_;
     my $ho = $self->{Host};
-    my $help = target_cmd_output_root($ho, $self->{Command}." help");
+    my $help = target_cmd_output_root($ho, $self->{_Command}." help");
     my $rc = ($help =~ m/^\s*migrate/m) ? 0 : 1;
     logm("rc=$rc");
     return $rc;
@@ -72,7 +72,7 @@ sub migrate ($$$$) {
     my $ho = $self->{Host};
     my $gn = $gho->{Name};
     target_cmd_root($ho,
-		    $self->{Command}." migrate $gn $dst",
+		    $self->{_Command}." migrate $gn $dst",
 		    $to);
 }
 
@@ -80,7 +80,7 @@ sub save ($$$$) {
     my ($self,$gho,$f,$to) = @_;
     my $ho = $self->{Host};
     my $gn = $gho->{Name};
-    target_cmd_root($ho,$self->{Command}." save $gn $f", $to);
+    target_cmd_root($ho,$self->{_Command}." save $gn $f", $to);
 }
 
 sub restore ($$$$$) {
@@ -88,7 +88,7 @@ sub restore ($$$$$) {
     my $ho = $self->{Host};
     my $gn = $gho->{Name};
     target_cmd_root($ho,
-		    $self->{Command}
+		    $self->{_Command}
 		    ." restore "
 		    .($self->{RestoreNeedsConfig} ? $cfg : '')
 		    ." $f", $to);
-- 
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 Tue Dec 02 16:30:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqLJ-0008Au-2C; Tue, 02 Dec 2014 16:30:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvqLH-0008Ap-Gb
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:30:23 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	73/C6-15461-D19ED745; Tue, 02 Dec 2014 16:30:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417537818!12928067!1
X-Originating-IP: [66.165.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 6700 invoked from network); 2 Dec 2014 16:30:21 -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;
	2 Dec 2014 16:30:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198600354"
Received: from ukmail1.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, 2 Dec 2014 11:04: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 1XvpwS-0004W6-Fa;
	Tue, 02 Dec 2014 16:04:44 +0000
Date: Tue, 2 Dec 2014 16:04:44 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141202160444.GI5768@zion.uk.xensource.com>
References: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Andrew Jones <drjones@redhat.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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxc: check in xc_get_tot_pages() that the
 proper domain is reported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 04:18:08PM +0100, Vitaly Kuznetsov wrote:
> XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
> strange interface: it reports first domain which has domid >= requested domid
> so all callers are supposed to check that the proper domain(s) was queried
> by checking domid. xc_get_tot_pages() doesn't do that. In case the requested
> domain was destroyed it will report first domain with domid > requested domid
> which is apparently misleading as there is no way xc_get_tot_pages() callers
> can figure out that they got tot_pages for some other domain.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>

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

> ---
>  tools/libxc/xc_private.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
> index 1c214dd..e2441ad 100644
> --- a/tools/libxc/xc_private.c
> +++ b/tools/libxc/xc_private.c
> @@ -613,8 +613,10 @@ int xc_get_pfn_list(xc_interface *xch,
>  long xc_get_tot_pages(xc_interface *xch, uint32_t domid)
>  {
>      xc_dominfo_t info;
> -    return (xc_domain_getinfo(xch, domid, 1, &info) != 1) ?
> -        -1 : info.nr_pages;
> +    if ( (xc_domain_getinfo(xch, domid, 1, &info) != 1) ||
> +         (info.domid != domid) )
> +        return -1;
> +    return info.nr_pages;
>  }
>  
>  int xc_copy_to_domain_page(xc_interface *xch,
> -- 
> 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 Dec 02 16:30:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqLJ-0008Au-2C; Tue, 02 Dec 2014 16:30:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XvqLH-0008Ap-Gb
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:30:23 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	73/C6-15461-D19ED745; Tue, 02 Dec 2014 16:30:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417537818!12928067!1
X-Originating-IP: [66.165.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 6700 invoked from network); 2 Dec 2014 16:30:21 -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;
	2 Dec 2014 16:30:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198600354"
Received: from ukmail1.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, 2 Dec 2014 11:04: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 1XvpwS-0004W6-Fa;
	Tue, 02 Dec 2014 16:04:44 +0000
Date: Tue, 2 Dec 2014 16:04:44 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141202160444.GI5768@zion.uk.xensource.com>
References: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Andrew Jones <drjones@redhat.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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxc: check in xc_get_tot_pages() that the
 proper domain is reported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 04:18:08PM +0100, Vitaly Kuznetsov wrote:
> XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
> strange interface: it reports first domain which has domid >= requested domid
> so all callers are supposed to check that the proper domain(s) was queried
> by checking domid. xc_get_tot_pages() doesn't do that. In case the requested
> domain was destroyed it will report first domain with domid > requested domid
> which is apparently misleading as there is no way xc_get_tot_pages() callers
> can figure out that they got tot_pages for some other domain.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>

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

> ---
>  tools/libxc/xc_private.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
> index 1c214dd..e2441ad 100644
> --- a/tools/libxc/xc_private.c
> +++ b/tools/libxc/xc_private.c
> @@ -613,8 +613,10 @@ int xc_get_pfn_list(xc_interface *xch,
>  long xc_get_tot_pages(xc_interface *xch, uint32_t domid)
>  {
>      xc_dominfo_t info;
> -    return (xc_domain_getinfo(xch, domid, 1, &info) != 1) ?
> -        -1 : info.nr_pages;
> +    if ( (xc_domain_getinfo(xch, domid, 1, &info) != 1) ||
> +         (info.domid != domid) )
> +        return -1;
> +    return info.nr_pages;
>  }
>  
>  int xc_copy_to_domain_page(xc_interface *xch,
> -- 
> 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 Dec 02 16:30:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqLf-0008DB-Jh; Tue, 02 Dec 2014 16:30: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 1XvqLe-0008Cu-8z
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:30:46 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	BC/C9-02954-539ED745; Tue, 02 Dec 2014 16:30:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417537842!12509177!1
X-Originating-IP: [66.165.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 10821 invoked from network); 2 Dec 2014 16:30:45 -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 Dec 2014 16:30:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198600484"
Received: from ukmail1.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, 2 Dec 2014 11:05:01 -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 1Xvpwi-0004Wz-5i;
	Tue, 02 Dec 2014 16:05:01 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:43 +0000
Message-ID: <1417536299-1810-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 02/18] ts-logs-capture: Collect some
	libvirt logs and capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-logs-capture | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/ts-logs-capture b/ts-logs-capture
index 21974a9..6cf51c1 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -117,6 +117,9 @@ sub fetch_logs_host_guests () {
                   /var/log/xen/osstest*
                   /var/log/xen/xenstored*
 
+                  /var/log/libvirt/libvirtd.log
+                  /var/log/libvirt/libxl/*
+
                   /var/run/xenstored*
                   /var/log/xenstored*
 
@@ -161,6 +164,7 @@ sub fetch_logs_host_guests () {
          'lspci -vvv',
          'lspci -tv',
          'cat /proc/partitions',
+         'virsh capabilities',
          ) {
             try_cmd_output_save($cmd);
         }
-- 
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 Tue Dec 02 16:30:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqLf-0008DB-Jh; Tue, 02 Dec 2014 16:30: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 1XvqLe-0008Cu-8z
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:30:46 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	BC/C9-02954-539ED745; Tue, 02 Dec 2014 16:30:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417537842!12509177!1
X-Originating-IP: [66.165.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 10821 invoked from network); 2 Dec 2014 16:30:45 -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 Dec 2014 16:30:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198600484"
Received: from ukmail1.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, 2 Dec 2014 11:05:01 -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 1Xvpwi-0004Wz-5i;
	Tue, 02 Dec 2014 16:05:01 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:43 +0000
Message-ID: <1417536299-1810-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 02/18] ts-logs-capture: Collect some
	libvirt logs and capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-logs-capture | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/ts-logs-capture b/ts-logs-capture
index 21974a9..6cf51c1 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -117,6 +117,9 @@ sub fetch_logs_host_guests () {
                   /var/log/xen/osstest*
                   /var/log/xen/xenstored*
 
+                  /var/log/libvirt/libvirtd.log
+                  /var/log/libvirt/libxl/*
+
                   /var/run/xenstored*
                   /var/log/xenstored*
 
@@ -161,6 +164,7 @@ sub fetch_logs_host_guests () {
          'lspci -vvv',
          'lspci -tv',
          'cat /proc/partitions',
+         'virsh capabilities',
          ) {
             try_cmd_output_save($cmd);
         }
-- 
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 Tue Dec 02 16:30:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1XvqLg-0008Dn-0N; Tue, 02 Dec 2014 16:30: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 1XvqLf-0008D3-2d
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:30:47 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	E6/CB-18267-639ED745; Tue, 02 Dec 2014 16:30:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537843!15362451!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.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); 2 Dec 2014 16:30: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;
	2 Dec 2014 16:30:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198600507"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwk-0004X5-8R;
	Tue, 02 Dec 2014 16:05:03 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:45 +0000
Message-ID: <1417536299-1810-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 04/18]
	ts-rumpuserxen-demo-xenstorels: Use standard functions for things
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Specifically guest_create and guest_find_domid.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-rumpuserxen-demo-xenstorels | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/ts-rumpuserxen-demo-xenstorels b/ts-rumpuserxen-demo-xenstorels
index a2a6a77..6698848 100755
--- a/ts-rumpuserxen-demo-xenstorels
+++ b/ts-rumpuserxen-demo-xenstorels
@@ -40,11 +40,9 @@ sub arrangepreserve () {
 }
 
 sub start () {
-    my $cmd= toolstack($ho)->{Command}." create ".
-        $r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} };
-    target_cmd_root($ho, $cmd, 30);
+    guest_create($gho,toolstack($ho));
 
-    $domid = target_cmd_output_root($ho,"xl domid $gho->{Guest}");
+    $domid = guest_find_domid($ho, $gho);
 }
 
 sub await_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 Tue Dec 02 16:30:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16: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 1XvqLg-0008Dn-0N; Tue, 02 Dec 2014 16:30: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 1XvqLf-0008D3-2d
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:30:47 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	E6/CB-18267-639ED745; Tue, 02 Dec 2014 16:30:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537843!15362451!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.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); 2 Dec 2014 16:30: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;
	2 Dec 2014 16:30:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198600507"
Received: from ukmail1.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, 2 Dec 2014 11:05: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 1Xvpwk-0004X5-8R;
	Tue, 02 Dec 2014 16:05:03 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:45 +0000
Message-ID: <1417536299-1810-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 04/18]
	ts-rumpuserxen-demo-xenstorels: Use standard functions for things
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Specifically guest_create and guest_find_domid.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-rumpuserxen-demo-xenstorels | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/ts-rumpuserxen-demo-xenstorels b/ts-rumpuserxen-demo-xenstorels
index a2a6a77..6698848 100755
--- a/ts-rumpuserxen-demo-xenstorels
+++ b/ts-rumpuserxen-demo-xenstorels
@@ -40,11 +40,9 @@ sub arrangepreserve () {
 }
 
 sub start () {
-    my $cmd= toolstack($ho)->{Command}." create ".
-        $r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} };
-    target_cmd_root($ho, $cmd, 30);
+    guest_create($gho,toolstack($ho));
 
-    $domid = target_cmd_output_root($ho,"xl domid $gho->{Guest}");
+    $domid = guest_find_domid($ho, $gho);
 }
 
 sub await_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 Tue Dec 02 16:30:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:30:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqLh-0008Eq-IM; Tue, 02 Dec 2014 16:30:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqLf-0008D9-PZ
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:30:47 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	08/13-20609-739ED745; Tue, 02 Dec 2014 16:30:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417537842!12509177!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10906 invoked from network); 2 Dec 2014 16:30:45 -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 Dec 2014 16:30:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198600493"
Received: from ukmail1.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, 2 Dec 2014 11:05:02 -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 1Xvpwj-0004X2-6s;
	Tue, 02 Dec 2014 16:05:02 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:44 +0000
Message-ID: <1417536299-1810-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 03/18] Pass host to toolstack()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be needed in a future patch.

Everywhere already has a $ho in hand. Also cache the answer as
$ho->{Toolstack}.

I scanned the source with:
    find -name \*.pm -exec perl -c {} \;
    for i in ts-* ; do perl -c $i; done
which reported "Not enough arguments for Osstest::TestSupport::toolstack" for
each callsite which needed changing.

Also don't pass the toolstack command name directly to host_get_free_memory().
Look it up instead.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm         | 16 ++++++++++------
 ts-debian-fixup                |  2 +-
 ts-debian-hvm-install          |  4 ++--
 ts-guest-localmigrate          |  2 +-
 ts-guest-migrate               |  2 +-
 ts-guest-saverestore           |  8 ++++----
 ts-guest-start                 |  4 ++--
 ts-guest-stop                  |  2 +-
 ts-logs-capture                |  2 +-
 ts-migrate-support-check       |  4 ++--
 ts-redhat-install              |  2 +-
 ts-rumpuserxen-demo-xenstorels |  4 ++--
 ts-windows-install             |  2 +-
 ts-xen-install                 | 10 +++++-----
 14 files changed, 34 insertions(+), 30 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 2ac490f..b7887bc 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -954,8 +954,9 @@ END
     });
 }
 
-sub host_get_free_memory($$) {
-    my ($ho,$toolstack) = @_;
+sub host_get_free_memory($) {
+    my ($ho) = @_;
+    my $toolstack = toolstack($ho)->{Command};
     # The line is as followed:
     # free_memory       :   XXXX
     my $info = target_cmd_output_root($ho, "$toolstack info", 10);
@@ -1318,7 +1319,7 @@ sub guest_await_shutdown ($$$) {
 
 sub guest_destroy ($$) {
     my ($ho,$gho) = @_;
-    target_cmd_root($ho, toolstack()->{Command}." destroy $gho->{Name}", 40);
+    target_cmd_root($ho, toolstack($ho)->{Command}." destroy $gho->{Name}", 40);
 }
 
 sub guest_create ($$) {
@@ -1609,7 +1610,7 @@ sub guest_check_up ($) {
 
 sub guest_get_state ($$) {
     my ($ho,$gho) = @_;
-    my $domains= target_cmd_output_root($ho, toolstack()->{Command}." list");
+    my $domains= target_cmd_output_root($ho, toolstack($ho)->{Command}." list");
     $domains =~ s/^Name.*\n//;
     foreach my $l (split /\n/, $domains) {
         $l =~ m/^(\S+) (?: \s+ \d+ ){3} \s+ ([-a-z]+) \s/x or die "$l ?";
@@ -1814,7 +1815,7 @@ sub guest_find_domid ($$) {
     my ($ho,$gho) = @_;
     return if defined $gho->{Domid};
     my $list= target_cmd_output_root($ho,
-                toolstack()->{Command}." list $gho->{Name}");
+                toolstack($ho)->{Command}." list $gho->{Name}");
     $list =~ m/^(?!Name\s)(\S+)\s+(\d+)\s+(\d+)+(\d+)\s.*$/m
         or die "domain list: $list";
     $1 eq $gho->{Name} or die "domain list name $1 expected $gho->{Name}";
@@ -1884,7 +1885,9 @@ our %toolstacks=
         },
      );
 
-sub toolstack () {
+sub toolstack ($) {
+    my ($ho) = @_;
+    return $ho->{Toolstack} if $ho->{Toolstack};
     my $tsname= $r{toolstack};
     $tsname= 'xend' if !defined $tsname;
     my $ts= $toolstacks{$tsname};
@@ -1893,6 +1896,7 @@ sub toolstack () {
         logm("toolstack $tsname");
         $ts->{Name}= $tsname;
     }
+    $ho->{Toolstack} = $ts;
     return $ts;
 }
 
diff --git a/ts-debian-fixup b/ts-debian-fixup
index f001418..11e956c 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -142,7 +142,7 @@ sub otherfixupcfg () {
     if (@pcipt) {
         logm("checking passthrough device(s) are assignable: @pcipt");
         my @assignables= split /\n/,
-            target_cmd_output_root($ho, toolstack()->{Command}.
+            target_cmd_output_root($ho, toolstack($ho)->{Command}.
                                    " pci-assignable-list");
         foreach my $pcipt (@pcipt) {
             die "not assignable: $pcipt (not in: @assignables)"
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 37eade2..0148eef 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -41,7 +41,7 @@ our $disk_mb= 10000;
 our $guesthost= "$gn.guest.osstest";
 our $gho;
 
-our $toolstack= toolstack()->{Command};
+our $toolstack= toolstack($ho)->{Command};
 
 
 sub preseed () {
@@ -171,7 +171,7 @@ sub prep () {
 
 # 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 $host_freemem_mb = host_get_free_memory($ho);
 my $ram_minslop = 100;
 my $ram_lots = 5000;
 if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
diff --git a/ts-guest-localmigrate b/ts-guest-localmigrate
index e50e93a..f3381da 100755
--- a/ts-guest-localmigrate
+++ b/ts-guest-localmigrate
@@ -33,7 +33,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 sub migrate () {
     guest_checkrunning($ho,$gho) or die $gho->{Name};
     target_cmd_root($ho,
-		    toolstack()->{Command}
+		    toolstack($ho)->{Command}
 		    ." migrate $gho->{Name} localhost",
 		    $timeout{Migrate});
 }
diff --git a/ts-guest-migrate b/ts-guest-migrate
index 17ac8a0..65e7b42 100755
--- a/ts-guest-migrate
+++ b/ts-guest-migrate
@@ -32,7 +32,7 @@ sub migrate () {
     guest_checkrunning($sho,$gho) or die $gho->{Name};
     my $err= guest_check_ip($gho);  die "$err $gho->{Name}" if defined $err;
     target_cmd_root($sho,
-		    toolstack()->{Command}
+		    toolstack($sho)->{Command}
 		    ." migrate $gho->{Name} $dho->{Name}",
 		    $timeout{Migrate});
 }
diff --git a/ts-guest-saverestore b/ts-guest-saverestore
index 81671c8..9e04ae9 100755
--- a/ts-guest-saverestore
+++ b/ts-guest-saverestore
@@ -28,17 +28,17 @@ sub save () {
     guest_checkrunning($ho,$gho) or die $gho->{Name};
     my $err= guest_check_ip($gho);  die "$err $gho->{Name}" if defined $err;
     target_cmd_root($ho,
-		    toolstack()->{Command}
+		    toolstack($ho)->{Command}
 		    ." save $gho->{Name} image",
 		    200);
     target_ping_check_down($gho);
 }
 sub restore () {
     target_cmd_root($ho,
-		    toolstack()->{Command}
+		    toolstack($ho)->{Command}
 		    ." restore "
-		    .(toolstack()->{RestoreNeedsConfig} ?
-		      $r{ $gho->{Guest}.'_'. toolstack()->{CfgPathVar} } : '')
+		    .(toolstack($ho)->{RestoreNeedsConfig} ?
+		      $r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} } : '')
 		    ." image", 200);
     target_ping_check_up($gho);
 }
diff --git a/ts-guest-start b/ts-guest-start
index 057afe6..bfbb734 100755
--- a/ts-guest-start
+++ b/ts-guest-start
@@ -26,8 +26,8 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 
 sub start () {
     guest_umount_lv($ho, $gho);
-    my $cmd= toolstack()->{Command}." create ".
-        $r{ $gho->{Guest}.'_'. toolstack()->{CfgPathVar} };
+    my $cmd= toolstack($ho)->{Command}." create ".
+        $r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} };
     target_cmd_root($ho, $cmd, 30);
 }
 
diff --git a/ts-guest-stop b/ts-guest-stop
index cc7db4c..0e3a863 100755
--- a/ts-guest-stop
+++ b/ts-guest-stop
@@ -27,7 +27,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 sub stop () {
     guest_checkrunning($ho, $gho) or die "$gho->{Name} not running";
     target_cmd_root($ho,
-		    toolstack()->{Command}
+		    toolstack($ho)->{Command}
 		    ." shutdown -w "
 		    .$gho->{Name}, 200);
     guest_checkrunning($ho, $gho) and die $gho->{Name};
diff --git a/ts-logs-capture b/ts-logs-capture
index 6cf51c1..841ad5a 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -195,7 +195,7 @@ sub fetch_logs_guest ($) {
         logm("cannot find domid: $@");
         return;
     }
-    my $consolecmd= toolstack()->{Command}." console $gho->{Name}";
+    my $consolecmd= toolstack($ho)->{Command}." console $gho->{Name}";
     try_cmd_output_save("sleep 1 | $consolecmd | cat",
                         "guest-$gho->{Name}-console");
 
diff --git a/ts-migrate-support-check b/ts-migrate-support-check
index ffae1b3..c70b77a 100755
--- a/ts-migrate-support-check
+++ b/ts-migrate-support-check
@@ -25,9 +25,9 @@ tsreadconfig();
 our $ho = selecthost($ARGV[0]);
 
 # all xend/xm platforms support migration
-exit(0) if toolstack()->{Command} eq "xm";
+exit(0) if toolstack($ho)->{Command} eq "xm";
 
-my $help = target_cmd_output_root($ho, toolstack()->{Command}." help");
+my $help = target_cmd_output_root($ho, toolstack($ho)->{Command}." help");
 
 my $rc = ($help =~ m/^\s*migrate/m) ? 0 : 1;
 
diff --git a/ts-redhat-install b/ts-redhat-install
index 56d4129..a0b1fab 100755
--- a/ts-redhat-install
+++ b/ts-redhat-install
@@ -37,7 +37,7 @@ our $disk_mb= 50000;
 our $guesthost= "$gn.guest.osstest";
 our $gho;
 
-our $xl= toolstack()->{Command};
+our $xl= toolstack($ho)->{Command};
 
 
 sub kickstart () {
diff --git a/ts-rumpuserxen-demo-xenstorels b/ts-rumpuserxen-demo-xenstorels
index 6db7024..a2a6a77 100755
--- a/ts-rumpuserxen-demo-xenstorels
+++ b/ts-rumpuserxen-demo-xenstorels
@@ -40,8 +40,8 @@ sub arrangepreserve () {
 }
 
 sub start () {
-    my $cmd= toolstack()->{Command}." create ".
-        $r{ $gho->{Guest}.'_'. toolstack()->{CfgPathVar} };
+    my $cmd= toolstack($ho)->{Command}." create ".
+        $r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} };
     target_cmd_root($ho, $cmd, 30);
 
     $domid = target_cmd_output_root($ho,"xl domid $gho->{Guest}");
diff --git a/ts-windows-install b/ts-windows-install
index 0a69f8e..4b06310 100755
--- a/ts-windows-install
+++ b/ts-windows-install
@@ -50,7 +50,7 @@ END
 }
 
 sub start () {
-    target_cmd_root($ho, toolstack()->{Command}.
+    target_cmd_root($ho, toolstack($ho)->{Command}.
                     " create $gho->{CfgPath}", 100);
 }
 
diff --git a/ts-xen-install b/ts-xen-install
index 4d34d1f..7cfe344 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -60,8 +60,8 @@ sub packages () {
     if ($r{arch} eq 'i386') {
 	target_install_packages($ho, 'libc6-xen');
     }
-    target_install_packages($ho, @{toolstack()->{ExtraPackages}})
-        if toolstack()->{ExtraPackages};
+    target_install_packages($ho, @{toolstack($ho)->{ExtraPackages}})
+        if toolstack($ho)->{ExtraPackages};
 }
 
 sub extract () {
@@ -101,7 +101,7 @@ sub adjustconfig () {
 	    }
 	}
 	print EO $extra or die $!;
-    }) if toolstack()->{Name} eq "xend";
+    }) if toolstack($ho)->{Name} eq "xend";
 
     my $trace_config_file;
     foreach my $try (qw(/etc/default/xencommons
@@ -147,7 +147,7 @@ sub setupboot () {
     } else {
 	logm("No Xen console device defined for host");
     }
-    if (toolstack()->{Dom0MemFixed}) {
+    if (toolstack($ho)->{Dom0MemFixed}) {
         $xenhopt .= " dom0_mem=512M,max:512M";
     }
     my $append= $r{xen_boot_append};
@@ -179,7 +179,7 @@ sub setupboot () {
 our $initscripts_nobridge;
 
 sub setupinitd () {
-    my $ts= toolstack();
+    my $ts= toolstack($ho);
     my $xencommons= '/etc/init.d/xencommons';
     my $have_xencommons=
         !!target_cmd_output_root($ho, <<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 Tue Dec 02 16:30:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:30:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqLh-0008Eq-IM; Tue, 02 Dec 2014 16:30:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqLf-0008D9-PZ
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:30:47 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	08/13-20609-739ED745; Tue, 02 Dec 2014 16:30:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417537842!12509177!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10906 invoked from network); 2 Dec 2014 16:30:45 -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 Dec 2014 16:30:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198600493"
Received: from ukmail1.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, 2 Dec 2014 11:05:02 -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 1Xvpwj-0004X2-6s;
	Tue, 02 Dec 2014 16:05:02 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:44 +0000
Message-ID: <1417536299-1810-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 03/18] Pass host to toolstack()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will be needed in a future patch.

Everywhere already has a $ho in hand. Also cache the answer as
$ho->{Toolstack}.

I scanned the source with:
    find -name \*.pm -exec perl -c {} \;
    for i in ts-* ; do perl -c $i; done
which reported "Not enough arguments for Osstest::TestSupport::toolstack" for
each callsite which needed changing.

Also don't pass the toolstack command name directly to host_get_free_memory().
Look it up instead.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm         | 16 ++++++++++------
 ts-debian-fixup                |  2 +-
 ts-debian-hvm-install          |  4 ++--
 ts-guest-localmigrate          |  2 +-
 ts-guest-migrate               |  2 +-
 ts-guest-saverestore           |  8 ++++----
 ts-guest-start                 |  4 ++--
 ts-guest-stop                  |  2 +-
 ts-logs-capture                |  2 +-
 ts-migrate-support-check       |  4 ++--
 ts-redhat-install              |  2 +-
 ts-rumpuserxen-demo-xenstorels |  4 ++--
 ts-windows-install             |  2 +-
 ts-xen-install                 | 10 +++++-----
 14 files changed, 34 insertions(+), 30 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 2ac490f..b7887bc 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -954,8 +954,9 @@ END
     });
 }
 
-sub host_get_free_memory($$) {
-    my ($ho,$toolstack) = @_;
+sub host_get_free_memory($) {
+    my ($ho) = @_;
+    my $toolstack = toolstack($ho)->{Command};
     # The line is as followed:
     # free_memory       :   XXXX
     my $info = target_cmd_output_root($ho, "$toolstack info", 10);
@@ -1318,7 +1319,7 @@ sub guest_await_shutdown ($$$) {
 
 sub guest_destroy ($$) {
     my ($ho,$gho) = @_;
-    target_cmd_root($ho, toolstack()->{Command}." destroy $gho->{Name}", 40);
+    target_cmd_root($ho, toolstack($ho)->{Command}." destroy $gho->{Name}", 40);
 }
 
 sub guest_create ($$) {
@@ -1609,7 +1610,7 @@ sub guest_check_up ($) {
 
 sub guest_get_state ($$) {
     my ($ho,$gho) = @_;
-    my $domains= target_cmd_output_root($ho, toolstack()->{Command}." list");
+    my $domains= target_cmd_output_root($ho, toolstack($ho)->{Command}." list");
     $domains =~ s/^Name.*\n//;
     foreach my $l (split /\n/, $domains) {
         $l =~ m/^(\S+) (?: \s+ \d+ ){3} \s+ ([-a-z]+) \s/x or die "$l ?";
@@ -1814,7 +1815,7 @@ sub guest_find_domid ($$) {
     my ($ho,$gho) = @_;
     return if defined $gho->{Domid};
     my $list= target_cmd_output_root($ho,
-                toolstack()->{Command}." list $gho->{Name}");
+                toolstack($ho)->{Command}." list $gho->{Name}");
     $list =~ m/^(?!Name\s)(\S+)\s+(\d+)\s+(\d+)+(\d+)\s.*$/m
         or die "domain list: $list";
     $1 eq $gho->{Name} or die "domain list name $1 expected $gho->{Name}";
@@ -1884,7 +1885,9 @@ our %toolstacks=
         },
      );
 
-sub toolstack () {
+sub toolstack ($) {
+    my ($ho) = @_;
+    return $ho->{Toolstack} if $ho->{Toolstack};
     my $tsname= $r{toolstack};
     $tsname= 'xend' if !defined $tsname;
     my $ts= $toolstacks{$tsname};
@@ -1893,6 +1896,7 @@ sub toolstack () {
         logm("toolstack $tsname");
         $ts->{Name}= $tsname;
     }
+    $ho->{Toolstack} = $ts;
     return $ts;
 }
 
diff --git a/ts-debian-fixup b/ts-debian-fixup
index f001418..11e956c 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -142,7 +142,7 @@ sub otherfixupcfg () {
     if (@pcipt) {
         logm("checking passthrough device(s) are assignable: @pcipt");
         my @assignables= split /\n/,
-            target_cmd_output_root($ho, toolstack()->{Command}.
+            target_cmd_output_root($ho, toolstack($ho)->{Command}.
                                    " pci-assignable-list");
         foreach my $pcipt (@pcipt) {
             die "not assignable: $pcipt (not in: @assignables)"
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 37eade2..0148eef 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -41,7 +41,7 @@ our $disk_mb= 10000;
 our $guesthost= "$gn.guest.osstest";
 our $gho;
 
-our $toolstack= toolstack()->{Command};
+our $toolstack= toolstack($ho)->{Command};
 
 
 sub preseed () {
@@ -171,7 +171,7 @@ sub prep () {
 
 # 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 $host_freemem_mb = host_get_free_memory($ho);
 my $ram_minslop = 100;
 my $ram_lots = 5000;
 if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
diff --git a/ts-guest-localmigrate b/ts-guest-localmigrate
index e50e93a..f3381da 100755
--- a/ts-guest-localmigrate
+++ b/ts-guest-localmigrate
@@ -33,7 +33,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 sub migrate () {
     guest_checkrunning($ho,$gho) or die $gho->{Name};
     target_cmd_root($ho,
-		    toolstack()->{Command}
+		    toolstack($ho)->{Command}
 		    ." migrate $gho->{Name} localhost",
 		    $timeout{Migrate});
 }
diff --git a/ts-guest-migrate b/ts-guest-migrate
index 17ac8a0..65e7b42 100755
--- a/ts-guest-migrate
+++ b/ts-guest-migrate
@@ -32,7 +32,7 @@ sub migrate () {
     guest_checkrunning($sho,$gho) or die $gho->{Name};
     my $err= guest_check_ip($gho);  die "$err $gho->{Name}" if defined $err;
     target_cmd_root($sho,
-		    toolstack()->{Command}
+		    toolstack($sho)->{Command}
 		    ." migrate $gho->{Name} $dho->{Name}",
 		    $timeout{Migrate});
 }
diff --git a/ts-guest-saverestore b/ts-guest-saverestore
index 81671c8..9e04ae9 100755
--- a/ts-guest-saverestore
+++ b/ts-guest-saverestore
@@ -28,17 +28,17 @@ sub save () {
     guest_checkrunning($ho,$gho) or die $gho->{Name};
     my $err= guest_check_ip($gho);  die "$err $gho->{Name}" if defined $err;
     target_cmd_root($ho,
-		    toolstack()->{Command}
+		    toolstack($ho)->{Command}
 		    ." save $gho->{Name} image",
 		    200);
     target_ping_check_down($gho);
 }
 sub restore () {
     target_cmd_root($ho,
-		    toolstack()->{Command}
+		    toolstack($ho)->{Command}
 		    ." restore "
-		    .(toolstack()->{RestoreNeedsConfig} ?
-		      $r{ $gho->{Guest}.'_'. toolstack()->{CfgPathVar} } : '')
+		    .(toolstack($ho)->{RestoreNeedsConfig} ?
+		      $r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} } : '')
 		    ." image", 200);
     target_ping_check_up($gho);
 }
diff --git a/ts-guest-start b/ts-guest-start
index 057afe6..bfbb734 100755
--- a/ts-guest-start
+++ b/ts-guest-start
@@ -26,8 +26,8 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 
 sub start () {
     guest_umount_lv($ho, $gho);
-    my $cmd= toolstack()->{Command}." create ".
-        $r{ $gho->{Guest}.'_'. toolstack()->{CfgPathVar} };
+    my $cmd= toolstack($ho)->{Command}." create ".
+        $r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} };
     target_cmd_root($ho, $cmd, 30);
 }
 
diff --git a/ts-guest-stop b/ts-guest-stop
index cc7db4c..0e3a863 100755
--- a/ts-guest-stop
+++ b/ts-guest-stop
@@ -27,7 +27,7 @@ our ($ho,$gho) = ts_get_host_guest(@ARGV);
 sub stop () {
     guest_checkrunning($ho, $gho) or die "$gho->{Name} not running";
     target_cmd_root($ho,
-		    toolstack()->{Command}
+		    toolstack($ho)->{Command}
 		    ." shutdown -w "
 		    .$gho->{Name}, 200);
     guest_checkrunning($ho, $gho) and die $gho->{Name};
diff --git a/ts-logs-capture b/ts-logs-capture
index 6cf51c1..841ad5a 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -195,7 +195,7 @@ sub fetch_logs_guest ($) {
         logm("cannot find domid: $@");
         return;
     }
-    my $consolecmd= toolstack()->{Command}." console $gho->{Name}";
+    my $consolecmd= toolstack($ho)->{Command}." console $gho->{Name}";
     try_cmd_output_save("sleep 1 | $consolecmd | cat",
                         "guest-$gho->{Name}-console");
 
diff --git a/ts-migrate-support-check b/ts-migrate-support-check
index ffae1b3..c70b77a 100755
--- a/ts-migrate-support-check
+++ b/ts-migrate-support-check
@@ -25,9 +25,9 @@ tsreadconfig();
 our $ho = selecthost($ARGV[0]);
 
 # all xend/xm platforms support migration
-exit(0) if toolstack()->{Command} eq "xm";
+exit(0) if toolstack($ho)->{Command} eq "xm";
 
-my $help = target_cmd_output_root($ho, toolstack()->{Command}." help");
+my $help = target_cmd_output_root($ho, toolstack($ho)->{Command}." help");
 
 my $rc = ($help =~ m/^\s*migrate/m) ? 0 : 1;
 
diff --git a/ts-redhat-install b/ts-redhat-install
index 56d4129..a0b1fab 100755
--- a/ts-redhat-install
+++ b/ts-redhat-install
@@ -37,7 +37,7 @@ our $disk_mb= 50000;
 our $guesthost= "$gn.guest.osstest";
 our $gho;
 
-our $xl= toolstack()->{Command};
+our $xl= toolstack($ho)->{Command};
 
 
 sub kickstart () {
diff --git a/ts-rumpuserxen-demo-xenstorels b/ts-rumpuserxen-demo-xenstorels
index 6db7024..a2a6a77 100755
--- a/ts-rumpuserxen-demo-xenstorels
+++ b/ts-rumpuserxen-demo-xenstorels
@@ -40,8 +40,8 @@ sub arrangepreserve () {
 }
 
 sub start () {
-    my $cmd= toolstack()->{Command}." create ".
-        $r{ $gho->{Guest}.'_'. toolstack()->{CfgPathVar} };
+    my $cmd= toolstack($ho)->{Command}." create ".
+        $r{ $gho->{Guest}.'_'. toolstack($ho)->{CfgPathVar} };
     target_cmd_root($ho, $cmd, 30);
 
     $domid = target_cmd_output_root($ho,"xl domid $gho->{Guest}");
diff --git a/ts-windows-install b/ts-windows-install
index 0a69f8e..4b06310 100755
--- a/ts-windows-install
+++ b/ts-windows-install
@@ -50,7 +50,7 @@ END
 }
 
 sub start () {
-    target_cmd_root($ho, toolstack()->{Command}.
+    target_cmd_root($ho, toolstack($ho)->{Command}.
                     " create $gho->{CfgPath}", 100);
 }
 
diff --git a/ts-xen-install b/ts-xen-install
index 4d34d1f..7cfe344 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -60,8 +60,8 @@ sub packages () {
     if ($r{arch} eq 'i386') {
 	target_install_packages($ho, 'libc6-xen');
     }
-    target_install_packages($ho, @{toolstack()->{ExtraPackages}})
-        if toolstack()->{ExtraPackages};
+    target_install_packages($ho, @{toolstack($ho)->{ExtraPackages}})
+        if toolstack($ho)->{ExtraPackages};
 }
 
 sub extract () {
@@ -101,7 +101,7 @@ sub adjustconfig () {
 	    }
 	}
 	print EO $extra or die $!;
-    }) if toolstack()->{Name} eq "xend";
+    }) if toolstack($ho)->{Name} eq "xend";
 
     my $trace_config_file;
     foreach my $try (qw(/etc/default/xencommons
@@ -147,7 +147,7 @@ sub setupboot () {
     } else {
 	logm("No Xen console device defined for host");
     }
-    if (toolstack()->{Dom0MemFixed}) {
+    if (toolstack($ho)->{Dom0MemFixed}) {
         $xenhopt .= " dom0_mem=512M,max:512M";
     }
     my $append= $r{xen_boot_append};
@@ -179,7 +179,7 @@ sub setupboot () {
 our $initscripts_nobridge;
 
 sub setupinitd () {
-    my $ts= toolstack();
+    my $ts= toolstack($ho);
     my $xencommons= '/etc/init.d/xencommons';
     my $have_xencommons=
         !!target_cmd_output_root($ho, <<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 Tue Dec 02 16:30:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:30:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqLh-0008FM-Un; Tue, 02 Dec 2014 16:30:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqLf-0008DA-U5
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:30:48 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	19/B3-07724-739ED745; Tue, 02 Dec 2014 16:30:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537843!15362451!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 7200 invoked from network); 2 Dec 2014 16:30:46 -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;
	2 Dec 2014 16:30:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198600511"
Received: from ukmail1.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, 2 Dec 2014 11:05:04 -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 1Xvpwl-0004X8-9Y;
	Tue, 02 Dec 2014 16:05:04 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:46 +0000
Message-ID: <1417536299-1810-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 05/18] Toolstack: use
	get_host_method_object() to manage toolstack selection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 us to more easily have per-toolstack methods etc.

The previous hash of toolstack parameters is now a blessed object. For
now the callers don't need to change but over the following patches we
will refactor things to use method calls. In particular we will be
aiming to remove Command from the hash and use method calls for
everything.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm       | 37 ++++---------------------------------
 Osstest/Toolstack/libvirt.pm | 34 ++++++++++++++++++++++++++++++++++
 Osstest/Toolstack/xend.pm    | 35 +++++++++++++++++++++++++++++++++++
 Osstest/Toolstack/xl.pm      | 35 +++++++++++++++++++++++++++++++++++
 4 files changed, 108 insertions(+), 33 deletions(-)
 create mode 100644 Osstest/Toolstack/libvirt.pm
 create mode 100644 Osstest/Toolstack/xend.pm
 create mode 100644 Osstest/Toolstack/xl.pm

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index b7887bc..df05d8a 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1862,42 +1862,13 @@ sub guest_vncsnapshot_stash ($$$$) {
     target_getfile_root($ho,100, "$rfile", "$stash/$leaf");
 }
 
-our %toolstacks=
-    ('xend' => {
-        NewDaemons => [qw(xend)],
-        OldDaemonInitd => 'xend',
-        Command => 'xm',
-        CfgPathVar => 'cfgpath',
-        Dom0MemFixed => 1,
-        },
-     'xl' => {
-        NewDaemons => [],
-        Dom0MemFixed => 1,
-        Command => 'xl',
-        CfgPathVar => 'cfgpath',
-	RestoreNeedsConfig => 1,
-        },
-     'libvirt' => {
-        NewDaemons => [qw(libvirtd)],
-        Dom0MemFixed => 1,
-        Command => 'virsh',
-        ExtraPackages => [qw(libnl1 libavahi-client3)],
-        },
-     );
-
 sub toolstack ($) {
     my ($ho) = @_;
     return $ho->{Toolstack} if $ho->{Toolstack};
-    my $tsname= $r{toolstack};
-    $tsname= 'xend' if !defined $tsname;
-    my $ts= $toolstacks{$tsname};
-    die "$tsname ?" unless defined $ts;
-    if (!exists $ts->{Name}) {
-        logm("toolstack $tsname");
-        $ts->{Name}= $tsname;
-    }
-    $ho->{Toolstack} = $ts;
-    return $ts;
+
+    my $tsname= $r{toolstack} || 'xend';
+    $ho->{Toolstack}= get_host_method_object($ho, 'Toolstack', $tsname);
+    return $ho->{Toolstack};
 }
 
 sub authorized_keys () {
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
new file mode 100644
index 0000000..90fe434
--- /dev/null
+++ b/Osstest/Toolstack/libvirt.pm
@@ -0,0 +1,34 @@
+# 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::Toolstack::libvirt;
+
+use strict;
+use warnings;
+
+sub new {
+    my ($class, $ho, $methname,$asset) = @_;
+    return bless { Name => "libvirt",
+		   Host => $ho,
+		   NewDaemons => [qw(libvirtd)],
+		   Dom0MemFixed => 1,
+		   Command => 'virsh',
+		   ExtraPackages => [qw(libnl1 libavahi-client3)],
+    }, $class;
+}
+
+1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
new file mode 100644
index 0000000..881417d
--- /dev/null
+++ b/Osstest/Toolstack/xend.pm
@@ -0,0 +1,35 @@
+# 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::Toolstack::xend;
+
+use strict;
+use warnings;
+
+sub new {
+    my ($class, $ho, $methname,$asset) = @_;
+    return bless { Name => "xend",
+		   Host => $ho,
+		   NewDaemons => [qw(xend)],
+		   OldDaemonInitd => 'xend',
+		   Command => 'xm',
+		   CfgPathVar => 'cfgpath',
+		   Dom0MemFixed => 1,
+    }, $class;
+}
+
+1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
new file mode 100644
index 0000000..0b66201
--- /dev/null
+++ b/Osstest/Toolstack/xl.pm
@@ -0,0 +1,35 @@
+# 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::Toolstack::xl;
+
+use strict;
+use warnings;
+
+sub new {
+    my ($class, $ho, $methname,$asset) = @_;
+    return bless { Name => "xl",
+		   Host => $ho,
+		   NewDaemons => [],
+		   Dom0MemFixed => 1,
+		   Command => 'xl',
+		   CfgPathVar => 'cfgpath',
+		   RestoreNeedsConfig => 1,
+    }, $class;
+}
+
+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 Tue Dec 02 16:30:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:30:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqLh-0008FM-Un; Tue, 02 Dec 2014 16:30:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XvqLf-0008DA-U5
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 16:30:48 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	19/B3-07724-739ED745; Tue, 02 Dec 2014 16:30:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417537843!15362451!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 7200 invoked from network); 2 Dec 2014 16:30:46 -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;
	2 Dec 2014 16:30:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198600511"
Received: from ukmail1.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, 2 Dec 2014 11:05:04 -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 1Xvpwl-0004X8-9Y;
	Tue, 02 Dec 2014 16:05:04 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Tue, 02 Dec
	2014 16:05:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Tue, 2 Dec 2014 16:04:46 +0000
Message-ID: <1417536299-1810-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417536141.29004.6.camel@citrix.com>
References: <1417536141.29004.6.camel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Jim Fehlig <jfehlig@suse.com>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH OSSTEST v2 05/18] Toolstack: use
	get_host_method_object() to manage toolstack selection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 us to more easily have per-toolstack methods etc.

The previous hash of toolstack parameters is now a blessed object. For
now the callers don't need to change but over the following patches we
will refactor things to use method calls. In particular we will be
aiming to remove Command from the hash and use method calls for
everything.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm       | 37 ++++---------------------------------
 Osstest/Toolstack/libvirt.pm | 34 ++++++++++++++++++++++++++++++++++
 Osstest/Toolstack/xend.pm    | 35 +++++++++++++++++++++++++++++++++++
 Osstest/Toolstack/xl.pm      | 35 +++++++++++++++++++++++++++++++++++
 4 files changed, 108 insertions(+), 33 deletions(-)
 create mode 100644 Osstest/Toolstack/libvirt.pm
 create mode 100644 Osstest/Toolstack/xend.pm
 create mode 100644 Osstest/Toolstack/xl.pm

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index b7887bc..df05d8a 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1862,42 +1862,13 @@ sub guest_vncsnapshot_stash ($$$$) {
     target_getfile_root($ho,100, "$rfile", "$stash/$leaf");
 }
 
-our %toolstacks=
-    ('xend' => {
-        NewDaemons => [qw(xend)],
-        OldDaemonInitd => 'xend',
-        Command => 'xm',
-        CfgPathVar => 'cfgpath',
-        Dom0MemFixed => 1,
-        },
-     'xl' => {
-        NewDaemons => [],
-        Dom0MemFixed => 1,
-        Command => 'xl',
-        CfgPathVar => 'cfgpath',
-	RestoreNeedsConfig => 1,
-        },
-     'libvirt' => {
-        NewDaemons => [qw(libvirtd)],
-        Dom0MemFixed => 1,
-        Command => 'virsh',
-        ExtraPackages => [qw(libnl1 libavahi-client3)],
-        },
-     );
-
 sub toolstack ($) {
     my ($ho) = @_;
     return $ho->{Toolstack} if $ho->{Toolstack};
-    my $tsname= $r{toolstack};
-    $tsname= 'xend' if !defined $tsname;
-    my $ts= $toolstacks{$tsname};
-    die "$tsname ?" unless defined $ts;
-    if (!exists $ts->{Name}) {
-        logm("toolstack $tsname");
-        $ts->{Name}= $tsname;
-    }
-    $ho->{Toolstack} = $ts;
-    return $ts;
+
+    my $tsname= $r{toolstack} || 'xend';
+    $ho->{Toolstack}= get_host_method_object($ho, 'Toolstack', $tsname);
+    return $ho->{Toolstack};
 }
 
 sub authorized_keys () {
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
new file mode 100644
index 0000000..90fe434
--- /dev/null
+++ b/Osstest/Toolstack/libvirt.pm
@@ -0,0 +1,34 @@
+# 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::Toolstack::libvirt;
+
+use strict;
+use warnings;
+
+sub new {
+    my ($class, $ho, $methname,$asset) = @_;
+    return bless { Name => "libvirt",
+		   Host => $ho,
+		   NewDaemons => [qw(libvirtd)],
+		   Dom0MemFixed => 1,
+		   Command => 'virsh',
+		   ExtraPackages => [qw(libnl1 libavahi-client3)],
+    }, $class;
+}
+
+1;
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
new file mode 100644
index 0000000..881417d
--- /dev/null
+++ b/Osstest/Toolstack/xend.pm
@@ -0,0 +1,35 @@
+# 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::Toolstack::xend;
+
+use strict;
+use warnings;
+
+sub new {
+    my ($class, $ho, $methname,$asset) = @_;
+    return bless { Name => "xend",
+		   Host => $ho,
+		   NewDaemons => [qw(xend)],
+		   OldDaemonInitd => 'xend',
+		   Command => 'xm',
+		   CfgPathVar => 'cfgpath',
+		   Dom0MemFixed => 1,
+    }, $class;
+}
+
+1;
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
new file mode 100644
index 0000000..0b66201
--- /dev/null
+++ b/Osstest/Toolstack/xl.pm
@@ -0,0 +1,35 @@
+# 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::Toolstack::xl;
+
+use strict;
+use warnings;
+
+sub new {
+    my ($class, $ho, $methname,$asset) = @_;
+    return bless { Name => "xl",
+		   Host => $ho,
+		   NewDaemons => [],
+		   Dom0MemFixed => 1,
+		   Command => 'xl',
+		   CfgPathVar => 'cfgpath',
+		   RestoreNeedsConfig => 1,
+    }, $class;
+}
+
+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 Tue Dec 02 16:40:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqV5-0000Z5-2d; Tue, 02 Dec 2014 16:40:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanosm@makatos-desktop.uk.xensource.com>)
	id 1XvqV3-0000Z0-BB
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 16:40:29 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	D9/D6-14727-C7BED745; Tue, 02 Dec 2014 16:40:28 +0000
X-Env-Sender: thanosm@makatos-desktop.uk.xensource.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417538423!11165711!1
X-Originating-IP: [66.165.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 9967 invoked from network); 2 Dec 2014 16:40:26 -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;
	2 Dec 2014 16:40:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198606506"
Received: from ukmail1.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, 2 Dec 2014 11:13:28 -0500
Received: from dhcp-3-216.uk.xensource.com ([10.80.3.216]
	helo=makatos-desktop)	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69) (envelope-from <thanosm@makatos-desktop.uk.xensource.com>)	id
	1Xvq4u-0004rT-6O; Tue, 02 Dec 2014 16:13:28 +0000
Received: from thanosm by makatos-desktop with local (Exim 4.76)
	(envelope-from <thanosm@makatos-desktop.uk.xensource.com>)	id
	1Xvq4t-0005sS-Tt; Tue, 02 Dec 2014 16:13:27 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 2 Dec 2014 16:13:26 +0000
Message-ID: <1417536806-22562-1-git-send-email-thanos.makatos@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-DLP: MIA1
Cc: boris.ostrovsky@oracle.com, david.vrabel@citrix.com,
	thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH v2] 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

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.

Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>
---
 drivers/xen/gntdev.c      |  171 +++++++++++++++++++++++++++++++++++++++++++++
 include/uapi/xen/gntdev.h |   69 ++++++++++++++++++
 2 files changed, 240 insertions(+)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 51f4c95..7b4a8e0 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -705,6 +705,174 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u)
 	return rc;
 }
 
+static int gntdev_gcopy_batch(int nr_segments, unsigned long gcopy_cb,
+		struct gntdev_grant_copy_segment __user *__segments, int dir,
+		int src, int dst) {
+
+	static const int batch_size = PAGE_SIZE / (sizeof(struct page*) +
+		sizeof(struct gnttab_copy) + sizeof(struct gntdev_grant_copy_segment));
+	struct page **pages = (struct page **)gcopy_cb;
+	struct gnttab_copy *batch = (struct gnttab_copy *)((unsigned long)pages +
+			sizeof(struct page*) * batch_size);
+	struct gntdev_grant_copy_segment *segments =
+		(struct gntdev_grant_copy_segment *)((unsigned long)batch +
+				sizeof(struct gnttab_copy) * batch_size);
+	unsigned int nr_pinned = 0, nr_segs2cp = 0;
+	int err = 0, i;
+	const int write = dir == GNTCOPY_IOCTL_g2s;
+
+	nr_segments = min(nr_segments, batch_size);
+
+	if (unlikely(copy_from_user(segments, __segments,
+			   sizeof(struct gntdev_grant_copy_segment) * nr_segments))) {
+		pr_debug("failed to copy %d segments from user", nr_segments);
+		err = -EFAULT;
+		goto out;
+	}
+
+	for (i = 0; i < nr_segments; i++) {
+
+		xen_pfn_t pgaddr;
+		unsigned long start, offset;
+		struct gntdev_grant_copy_segment *seg = &segments[i];
+
+		if (dir == GNTCOPY_IOCTL_s2g || dir == GNTCOPY_IOCTL_g2s) {
+
+			start = (unsigned long)seg->self.iov.iov_base & PAGE_MASK;
+			offset = (unsigned long)seg->self.iov.iov_base & ~PAGE_MASK;
+			if (unlikely(offset + seg->self.iov.iov_len > PAGE_SIZE)) {
+				pr_warn("segments crossing page boundaries not yet "
+						"implemented\n");
+				err = -ENOSYS;
+				goto out;
+			}
+
+			err = get_user_pages_fast(start, 1, write, &pages[i]);
+			if (unlikely(err != 1)) {
+				pr_debug("failed to get user page %lu", start);
+				err = -EFAULT;
+				goto out;
+			}
+
+			nr_pinned++;
+
+			pgaddr = pfn_to_mfn(page_to_pfn(pages[i]));
+		}
+
+		nr_segs2cp++;
+
+		switch (dir) {
+		case GNTCOPY_IOCTL_g2s: /* copy from guest */
+			batch[i].len = seg->self.iov.iov_len;
+			batch[i].source.u.ref = seg->self.ref;
+			batch[i].source.domid = src;
+			batch[i].source.offset = seg->self.offset;
+			batch[i].dest.u.gmfn = pgaddr;
+			batch[i].dest.domid = DOMID_SELF;
+			batch[i].dest.offset = offset;
+			batch[i].flags = GNTCOPY_source_gref;
+			break;
+		case GNTCOPY_IOCTL_s2g: /* copy to guest */
+			batch[i].len = seg->self.iov.iov_len;
+			batch[i].source.u.gmfn = pgaddr;
+			batch[i].source.domid = DOMID_SELF;
+			batch[i].source.offset = offset;
+			batch[i].dest.u.ref = seg->self.ref;
+			batch[i].dest.domid = dst;
+			batch[i].dest.offset = seg->self.offset;
+			batch[i].flags = GNTCOPY_dest_gref;
+			break;
+		case GNTCOPY_IOCTL_g2g: /* copy guest to guest */
+			batch[i].len = seg->g2g.len;
+			batch[i].source.u.ref = seg->g2g.src.ref;
+			batch[i].source.domid = src;
+			batch[i].source.offset = seg->g2g.src.offset;
+			batch[i].dest.u.ref = seg->g2g.dst.ref;
+			batch[i].dest.domid = dst;
+			batch[i].dest.offset = seg->g2g.dst.offset;
+			batch[i].flags = GNTCOPY_source_gref | GNTCOPY_dest_gref;
+			break;
+		default:
+			pr_debug("invalid grant-copy direction %d\n", dir);
+			err = -EINVAL;
+			goto out;
+		}
+	}
+
+	gnttab_batch_copy(batch, nr_segs2cp);
+	for (i = 0; i < nr_segs2cp; i++) {
+		err = put_user(batch[i].status, &__segments[i].status);
+		if (unlikely(err)) {
+			pr_debug("failed to copy error code %d to user: %d\n",
+					batch[i].status, err);
+			goto out;
+		}
+	}
+
+out:
+	for (i = 0; i < nr_pinned; i++)
+		put_page(pages[i]);
+
+	if (unlikely(err))
+		return err;
+
+	return nr_segs2cp;
+}
+
+static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
+{
+	struct ioctl_gntdev_grant_copy op;
+	unsigned int remaining;
+	int err = 0;
+	unsigned long gcopy_cb = 0;
+
+	if (unlikely(copy_from_user(&op, u, sizeof(op)))) {
+		pr_debug("failed to copy grant-copy parameters from user");
+		err = -EFAULT;
+		goto out;
+	}
+
+	if (unlikely(op.dir != GNTCOPY_IOCTL_s2g && op.dir != GNTCOPY_IOCTL_g2s &&
+			op.dir != GNTCOPY_IOCTL_g2g)) {
+		pr_debug("invalid copy direction %d\n", op.dir);
+		err = -EINVAL;
+		goto out;
+	}
+
+	if (!op.count) {
+		pr_debug("no segments to transfer");
+		err = 0;
+		goto out;
+	}
+
+	gcopy_cb = get_zeroed_page(GFP_KERNEL);
+	if (unlikely(!gcopy_cb)) {
+		pr_debug("failed to allocate page");
+		err = -ENOMEM;
+		goto out;
+	}
+
+	remaining = op.count;
+
+	while (remaining > 0) {
+		err = gntdev_gcopy_batch(remaining, gcopy_cb,
+				op.segments + (op.count - remaining), op.dir, op.src, op.dst);
+		if (unlikely(err < 0)) {
+			pr_debug("failed to grant-copy %d segments: %d",
+					op.count - remaining, err);
+			goto out;
+		}
+		remaining -= err;
+	}
+
+	err = 0;
+
+out:
+	if (likely(gcopy_cb))
+		free_page(gcopy_cb);
+	return err;
+}
+
 static long gntdev_ioctl(struct file *flip,
 			 unsigned int cmd, unsigned long arg)
 {
@@ -724,6 +892,9 @@ static long gntdev_ioctl(struct file *flip,
 	case IOCTL_GNTDEV_SET_UNMAP_NOTIFY:
 		return gntdev_ioctl_notify(priv, ptr);
 
+	case IOCTL_GNTDEV_GRANT_COPY:
+		return gntdev_ioctl_grant_copy(priv, ptr);
+
 	default:
 		pr_debug("priv %p, unknown cmd %x\n", priv, cmd);
 		return -ENOIOCTLCMD;
diff --git a/include/uapi/xen/gntdev.h b/include/uapi/xen/gntdev.h
index 5304bd3..17da5e9 100644
--- a/include/uapi/xen/gntdev.h
+++ b/include/uapi/xen/gntdev.h
@@ -33,6 +33,12 @@
 #ifndef __LINUX_PUBLIC_GNTDEV_H__
 #define __LINUX_PUBLIC_GNTDEV_H__
 
+#ifdef __KERNEL__
+#include <linux/uio.h>
+#else
+#include <sys/uio.h>
+#endif
+
 struct ioctl_gntdev_grant_ref {
 	/* The domain ID of the grant to be mapped. */
 	uint32_t domid;
@@ -142,6 +148,69 @@ struct ioctl_gntdev_unmap_notify {
 	uint32_t event_channel_port;
 };
 
+struct gntdev_grant_copy_segment {
+
+	union {
+		/* copy from (to) self to (from) guest */
+		struct {
+			/*
+			 * source address and length
+			 */
+			struct iovec iov;
+
+			/* the granted page */
+			uint32_t ref;
+
+			/* offset in the granted page */
+			uint16_t offset;
+		} self;
+
+		/* copy from guest to guest */
+		struct {
+			uint16_t len;
+
+			struct {
+				/* the granted page */
+				uint32_t ref;
+
+				/* offset in the granted page */
+				uint16_t offset;
+			} src, dst;
+		} g2g;
+	};
+
+	/* grant copy result (GNTST_XXX) */
+	int16_t status;
+};
+
+/* grant-copy from self to guest */
+#define GNTCOPY_IOCTL_s2g 0
+/* grant-copy from guest to self */
+#define GNTCOPY_IOCTL_g2s 1
+/* grant-copy from guest to guest */
+#define GNTCOPY_IOCTL_g2g 2
+
+#define IOCTL_GNTDEV_GRANT_COPY \
+_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
+struct ioctl_gntdev_grant_copy {
+	/*
+	 * copy direction, see GNTCOPY_IOCTL_XXX
+	 */
+	int dir;
+
+	/*
+	 * domain IDs:
+	 *	When the source (destination) domain is the one executing the
+	 *	grant-copy operation, the @src (@dst) parameter is ignored.
+	 */
+	uint32_t src;
+	uint32_t dst;
+
+	unsigned int count;
+
+	struct gntdev_grant_copy_segment __user *segments;
+};
+
 /* Clear (set to zero) the byte specified by index */
 #define UNMAP_NOTIFY_CLEAR_BYTE 0x1
 /* Send an interrupt on the indicated event channel */
-- 
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 Dec 02 16:40:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 16:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvqV5-0000Z5-2d; Tue, 02 Dec 2014 16:40:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanosm@makatos-desktop.uk.xensource.com>)
	id 1XvqV3-0000Z0-BB
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 16:40:29 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	D9/D6-14727-C7BED745; Tue, 02 Dec 2014 16:40:28 +0000
X-Env-Sender: thanosm@makatos-desktop.uk.xensource.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417538423!11165711!1
X-Originating-IP: [66.165.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 9967 invoked from network); 2 Dec 2014 16:40:26 -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;
	2 Dec 2014 16:40:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208";a="198606506"
Received: from ukmail1.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, 2 Dec 2014 11:13:28 -0500
Received: from dhcp-3-216.uk.xensource.com ([10.80.3.216]
	helo=makatos-desktop)	by ukmail1.uk.xensource.com with esmtp (Exim
	4.69) (envelope-from <thanosm@makatos-desktop.uk.xensource.com>)	id
	1Xvq4u-0004rT-6O; Tue, 02 Dec 2014 16:13:28 +0000
Received: from thanosm by makatos-desktop with local (Exim 4.76)
	(envelope-from <thanosm@makatos-desktop.uk.xensource.com>)	id
	1Xvq4t-0005sS-Tt; Tue, 02 Dec 2014 16:13:27 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Tue, 2 Dec 2014 16:13:26 +0000
Message-ID: <1417536806-22562-1-git-send-email-thanos.makatos@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-DLP: MIA1
Cc: boris.ostrovsky@oracle.com, david.vrabel@citrix.com,
	thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH v2] 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

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.

Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>
---
 drivers/xen/gntdev.c      |  171 +++++++++++++++++++++++++++++++++++++++++++++
 include/uapi/xen/gntdev.h |   69 ++++++++++++++++++
 2 files changed, 240 insertions(+)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 51f4c95..7b4a8e0 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -705,6 +705,174 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u)
 	return rc;
 }
 
+static int gntdev_gcopy_batch(int nr_segments, unsigned long gcopy_cb,
+		struct gntdev_grant_copy_segment __user *__segments, int dir,
+		int src, int dst) {
+
+	static const int batch_size = PAGE_SIZE / (sizeof(struct page*) +
+		sizeof(struct gnttab_copy) + sizeof(struct gntdev_grant_copy_segment));
+	struct page **pages = (struct page **)gcopy_cb;
+	struct gnttab_copy *batch = (struct gnttab_copy *)((unsigned long)pages +
+			sizeof(struct page*) * batch_size);
+	struct gntdev_grant_copy_segment *segments =
+		(struct gntdev_grant_copy_segment *)((unsigned long)batch +
+				sizeof(struct gnttab_copy) * batch_size);
+	unsigned int nr_pinned = 0, nr_segs2cp = 0;
+	int err = 0, i;
+	const int write = dir == GNTCOPY_IOCTL_g2s;
+
+	nr_segments = min(nr_segments, batch_size);
+
+	if (unlikely(copy_from_user(segments, __segments,
+			   sizeof(struct gntdev_grant_copy_segment) * nr_segments))) {
+		pr_debug("failed to copy %d segments from user", nr_segments);
+		err = -EFAULT;
+		goto out;
+	}
+
+	for (i = 0; i < nr_segments; i++) {
+
+		xen_pfn_t pgaddr;
+		unsigned long start, offset;
+		struct gntdev_grant_copy_segment *seg = &segments[i];
+
+		if (dir == GNTCOPY_IOCTL_s2g || dir == GNTCOPY_IOCTL_g2s) {
+
+			start = (unsigned long)seg->self.iov.iov_base & PAGE_MASK;
+			offset = (unsigned long)seg->self.iov.iov_base & ~PAGE_MASK;
+			if (unlikely(offset + seg->self.iov.iov_len > PAGE_SIZE)) {
+				pr_warn("segments crossing page boundaries not yet "
+						"implemented\n");
+				err = -ENOSYS;
+				goto out;
+			}
+
+			err = get_user_pages_fast(start, 1, write, &pages[i]);
+			if (unlikely(err != 1)) {
+				pr_debug("failed to get user page %lu", start);
+				err = -EFAULT;
+				goto out;
+			}
+
+			nr_pinned++;
+
+			pgaddr = pfn_to_mfn(page_to_pfn(pages[i]));
+		}
+
+		nr_segs2cp++;
+
+		switch (dir) {
+		case GNTCOPY_IOCTL_g2s: /* copy from guest */
+			batch[i].len = seg->self.iov.iov_len;
+			batch[i].source.u.ref = seg->self.ref;
+			batch[i].source.domid = src;
+			batch[i].source.offset = seg->self.offset;
+			batch[i].dest.u.gmfn = pgaddr;
+			batch[i].dest.domid = DOMID_SELF;
+			batch[i].dest.offset = offset;
+			batch[i].flags = GNTCOPY_source_gref;
+			break;
+		case GNTCOPY_IOCTL_s2g: /* copy to guest */
+			batch[i].len = seg->self.iov.iov_len;
+			batch[i].source.u.gmfn = pgaddr;
+			batch[i].source.domid = DOMID_SELF;
+			batch[i].source.offset = offset;
+			batch[i].dest.u.ref = seg->self.ref;
+			batch[i].dest.domid = dst;
+			batch[i].dest.offset = seg->self.offset;
+			batch[i].flags = GNTCOPY_dest_gref;
+			break;
+		case GNTCOPY_IOCTL_g2g: /* copy guest to guest */
+			batch[i].len = seg->g2g.len;
+			batch[i].source.u.ref = seg->g2g.src.ref;
+			batch[i].source.domid = src;
+			batch[i].source.offset = seg->g2g.src.offset;
+			batch[i].dest.u.ref = seg->g2g.dst.ref;
+			batch[i].dest.domid = dst;
+			batch[i].dest.offset = seg->g2g.dst.offset;
+			batch[i].flags = GNTCOPY_source_gref | GNTCOPY_dest_gref;
+			break;
+		default:
+			pr_debug("invalid grant-copy direction %d\n", dir);
+			err = -EINVAL;
+			goto out;
+		}
+	}
+
+	gnttab_batch_copy(batch, nr_segs2cp);
+	for (i = 0; i < nr_segs2cp; i++) {
+		err = put_user(batch[i].status, &__segments[i].status);
+		if (unlikely(err)) {
+			pr_debug("failed to copy error code %d to user: %d\n",
+					batch[i].status, err);
+			goto out;
+		}
+	}
+
+out:
+	for (i = 0; i < nr_pinned; i++)
+		put_page(pages[i]);
+
+	if (unlikely(err))
+		return err;
+
+	return nr_segs2cp;
+}
+
+static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
+{
+	struct ioctl_gntdev_grant_copy op;
+	unsigned int remaining;
+	int err = 0;
+	unsigned long gcopy_cb = 0;
+
+	if (unlikely(copy_from_user(&op, u, sizeof(op)))) {
+		pr_debug("failed to copy grant-copy parameters from user");
+		err = -EFAULT;
+		goto out;
+	}
+
+	if (unlikely(op.dir != GNTCOPY_IOCTL_s2g && op.dir != GNTCOPY_IOCTL_g2s &&
+			op.dir != GNTCOPY_IOCTL_g2g)) {
+		pr_debug("invalid copy direction %d\n", op.dir);
+		err = -EINVAL;
+		goto out;
+	}
+
+	if (!op.count) {
+		pr_debug("no segments to transfer");
+		err = 0;
+		goto out;
+	}
+
+	gcopy_cb = get_zeroed_page(GFP_KERNEL);
+	if (unlikely(!gcopy_cb)) {
+		pr_debug("failed to allocate page");
+		err = -ENOMEM;
+		goto out;
+	}
+
+	remaining = op.count;
+
+	while (remaining > 0) {
+		err = gntdev_gcopy_batch(remaining, gcopy_cb,
+				op.segments + (op.count - remaining), op.dir, op.src, op.dst);
+		if (unlikely(err < 0)) {
+			pr_debug("failed to grant-copy %d segments: %d",
+					op.count - remaining, err);
+			goto out;
+		}
+		remaining -= err;
+	}
+
+	err = 0;
+
+out:
+	if (likely(gcopy_cb))
+		free_page(gcopy_cb);
+	return err;
+}
+
 static long gntdev_ioctl(struct file *flip,
 			 unsigned int cmd, unsigned long arg)
 {
@@ -724,6 +892,9 @@ static long gntdev_ioctl(struct file *flip,
 	case IOCTL_GNTDEV_SET_UNMAP_NOTIFY:
 		return gntdev_ioctl_notify(priv, ptr);
 
+	case IOCTL_GNTDEV_GRANT_COPY:
+		return gntdev_ioctl_grant_copy(priv, ptr);
+
 	default:
 		pr_debug("priv %p, unknown cmd %x\n", priv, cmd);
 		return -ENOIOCTLCMD;
diff --git a/include/uapi/xen/gntdev.h b/include/uapi/xen/gntdev.h
index 5304bd3..17da5e9 100644
--- a/include/uapi/xen/gntdev.h
+++ b/include/uapi/xen/gntdev.h
@@ -33,6 +33,12 @@
 #ifndef __LINUX_PUBLIC_GNTDEV_H__
 #define __LINUX_PUBLIC_GNTDEV_H__
 
+#ifdef __KERNEL__
+#include <linux/uio.h>
+#else
+#include <sys/uio.h>
+#endif
+
 struct ioctl_gntdev_grant_ref {
 	/* The domain ID of the grant to be mapped. */
 	uint32_t domid;
@@ -142,6 +148,69 @@ struct ioctl_gntdev_unmap_notify {
 	uint32_t event_channel_port;
 };
 
+struct gntdev_grant_copy_segment {
+
+	union {
+		/* copy from (to) self to (from) guest */
+		struct {
+			/*
+			 * source address and length
+			 */
+			struct iovec iov;
+
+			/* the granted page */
+			uint32_t ref;
+
+			/* offset in the granted page */
+			uint16_t offset;
+		} self;
+
+		/* copy from guest to guest */
+		struct {
+			uint16_t len;
+
+			struct {
+				/* the granted page */
+				uint32_t ref;
+
+				/* offset in the granted page */
+				uint16_t offset;
+			} src, dst;
+		} g2g;
+	};
+
+	/* grant copy result (GNTST_XXX) */
+	int16_t status;
+};
+
+/* grant-copy from self to guest */
+#define GNTCOPY_IOCTL_s2g 0
+/* grant-copy from guest to self */
+#define GNTCOPY_IOCTL_g2s 1
+/* grant-copy from guest to guest */
+#define GNTCOPY_IOCTL_g2g 2
+
+#define IOCTL_GNTDEV_GRANT_COPY \
+_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
+struct ioctl_gntdev_grant_copy {
+	/*
+	 * copy direction, see GNTCOPY_IOCTL_XXX
+	 */
+	int dir;
+
+	/*
+	 * domain IDs:
+	 *	When the source (destination) domain is the one executing the
+	 *	grant-copy operation, the @src (@dst) parameter is ignored.
+	 */
+	uint32_t src;
+	uint32_t dst;
+
+	unsigned int count;
+
+	struct gntdev_grant_copy_segment __user *segments;
+};
+
 /* Clear (set to zero) the byte specified by index */
 #define UNMAP_NOTIFY_CLEAR_BYTE 0x1
 /* Send an interrupt on the indicated event channel */
-- 
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 Dec 02 17:05:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 17: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 1Xvqsx-0001bw-Ao; Tue, 02 Dec 2014 17:05:11 +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 1Xvqsw-0001bn-9W
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 17:05:10 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	39/A3-02696-541FD745; Tue, 02 Dec 2014 17:05:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417539907!12441445!1
X-Originating-IP: [156.151.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 29451 invoked from network); 2 Dec 2014 17:05:08 -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; 2 Dec 2014 17:05:08 -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 sB2H51vJ019924
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 17:05:02 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
	sB2H50d7017912
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 17:05:01 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
	sB2H4xUe001380; Tue, 2 Dec 2014 17:05:00 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 09:04:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BDB7711AF9E; Tue,  2 Dec 2014 12:04:56 -0500 (EST)
Date: Tue, 2 Dec 2014 12:04:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202170456.GB31436@laptop.dumpdata.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com>
	<20141202151101.GG27869@laptop.dumpdata.com>
	<1417533208.24320.55.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417533208.24320.55.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 03:13:28PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 10:11 -0500, Konrad Rzeszutek Wilk wrote:
> > > [0] The default i386 Debian installer falls into this camp, but you can
> > > use the special PV Xen variant to install as PVHVM too so it's not so
> > > critical.
> > 
> > And the Fedora 21 LiveISO (32-bit) does too.
> 
> Interesting, I thought Fedora had switched to requiring PAE as a minimum
> baseline everywhere 

It did, except for the GNOME based LiveCD. And oddly enough it will install
an PAE kernel (since the CPU is capable of it) . But of course it won't
bundle the Xen drivers in the initramfs, so when the new OS boots it
keels over as it unplugs the emulated ones.
> 
> Ian.
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 17:05:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 17: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 1Xvqsx-0001bw-Ao; Tue, 02 Dec 2014 17:05:11 +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 1Xvqsw-0001bn-9W
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 17:05:10 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	39/A3-02696-541FD745; Tue, 02 Dec 2014 17:05:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417539907!12441445!1
X-Originating-IP: [156.151.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 29451 invoked from network); 2 Dec 2014 17:05:08 -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; 2 Dec 2014 17:05:08 -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 sB2H51vJ019924
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 17:05:02 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
	sB2H50d7017912
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 17:05:01 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
	sB2H4xUe001380; Tue, 2 Dec 2014 17:05:00 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 09:04:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BDB7711AF9E; Tue,  2 Dec 2014 12:04:56 -0500 (EST)
Date: Tue, 2 Dec 2014 12:04:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202170456.GB31436@laptop.dumpdata.com>
References: <547D88EF.4050206@suse.com> <547D9A4A.6010201@citrix.com>
	<1417518314.24320.9.camel@citrix.com>
	<20141202151101.GG27869@laptop.dumpdata.com>
	<1417533208.24320.55.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417533208.24320.55.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] PVHVM drivers in upstream linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 03:13:28PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 10:11 -0500, Konrad Rzeszutek Wilk wrote:
> > > [0] The default i386 Debian installer falls into this camp, but you can
> > > use the special PV Xen variant to install as PVHVM too so it's not so
> > > critical.
> > 
> > And the Fedora 21 LiveISO (32-bit) does too.
> 
> Interesting, I thought Fedora had switched to requiring PAE as a minimum
> baseline everywhere 

It did, except for the GNOME based LiveCD. And oddly enough it will install
an PAE kernel (since the CPU is capable of it) . But of course it won't
bundle the Xen drivers in the initramfs, so when the new OS boots it
keels over as it unplugs the emulated ones.
> 
> Ian.
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 17:06:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 17: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 1XvquG-0001lH-RZ; Tue, 02 Dec 2014 17:06: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 1XvquF-0001l7-2j
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 17:06:31 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FA/3C-25276-691FD745; Tue, 02 Dec 2014 17:06:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417539988!4895655!1
X-Originating-IP: [156.151.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 16630 invoked from network); 2 Dec 2014 17:06:29 -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; 2 Dec 2014 17:06:29 -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 sB2H6LmR022058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 17:06:22 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
	sB2H6KFQ029905
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 17:06:21 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
	sB2H6KUK029895; Tue, 2 Dec 2014 17:06:20 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 09:06:20 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id CB31911AFA4; Tue,  2 Dec 2014 12:06:20 -0500 (EST)
Date: Tue, 2 Dec 2014 12:06:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202170620.GC31436@laptop.dumpdata.com>
References: <201411271512.sARFC11l001276@userz7022.oracle.com>
	<CAFLBxZZKBf70oH7yUC9JDU7U3Ca5SAt6vWcNfnMy566KEPQS4w@mail.gmail.com>
	<1417533160.24320.54.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417533160.24320.54.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [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 Tue, Dec 02, 2014 at 03:12:40PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 15:10 +0000, George Dunlap wrote:
> > On Thu, Nov 27, 2014 at 3:11 PM, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> > >
> > > On Nov 27, 2014 6:59 AM, Tim Deegan <tim@xen.org> wrote:
> > >>
> > >> 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
> > >
> > > +1 too.
> 
> > OK, that's +4 and no minuses after 5 days.  How long to I have to wait?  :-)
> 
> http://www.xenproject.org/help/contribution-guidelines.html says seven
> days...

Business or normal days :-)

> 
> Ian.
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 17:06:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 17: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 1XvquG-0001lH-RZ; Tue, 02 Dec 2014 17:06: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 1XvquF-0001l7-2j
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 17:06:31 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FA/3C-25276-691FD745; Tue, 02 Dec 2014 17:06:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417539988!4895655!1
X-Originating-IP: [156.151.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 16630 invoked from network); 2 Dec 2014 17:06:29 -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; 2 Dec 2014 17:06:29 -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 sB2H6LmR022058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 17:06:22 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
	sB2H6KFQ029905
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 17:06:21 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
	sB2H6KUK029895; Tue, 2 Dec 2014 17:06:20 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 09:06:20 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id CB31911AFA4; Tue,  2 Dec 2014 12:06:20 -0500 (EST)
Date: Tue, 2 Dec 2014 12:06:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202170620.GC31436@laptop.dumpdata.com>
References: <201411271512.sARFC11l001276@userz7022.oracle.com>
	<CAFLBxZZKBf70oH7yUC9JDU7U3Ca5SAt6vWcNfnMy566KEPQS4w@mail.gmail.com>
	<1417533160.24320.54.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417533160.24320.54.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [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 Tue, Dec 02, 2014 at 03:12:40PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 15:10 +0000, George Dunlap wrote:
> > On Thu, Nov 27, 2014 at 3:11 PM, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> > >
> > > On Nov 27, 2014 6:59 AM, Tim Deegan <tim@xen.org> wrote:
> > >>
> > >> 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
> > >
> > > +1 too.
> 
> > OK, that's +4 and no minuses after 5 days.  How long to I have to wait?  :-)
> 
> http://www.xenproject.org/help/contribution-guidelines.html says seven
> days...

Business or normal days :-)

> 
> Ian.
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 17:25:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 17:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvrCX-0002Ul-T6; Tue, 02 Dec 2014 17:25:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XvrCX-0002Ug-FB
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 17:25:25 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	E5/16-14214-406FD745; Tue, 02 Dec 2014 17:25:24 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417541123!11151591!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15724 invoked from network); 2 Dec 2014 17:25:24 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 17:25:24 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so17758466wgh.16
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 09:25: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=MJGAq+QwP7cKWaW4yVpUYawolfftAyt2dlpNPzKoIDU=;
	b=U7jo3Dl/q/fmti3qdk98d7LA65rSsMuK90ql0E4baX5UqrN48VFCdHJAKa7C6EmSBu
	8ynCLMvlf5WZ4YVGIQ185F/r9sKZdBDpQmZpaiU0BgaqtSezJXkle6bcpRt4bB4FHYGU
	HXvRnXoMZdfVy89AGrnIrOXb7l1DK4OqS75bOzV2LDxval66icGAESP5C2/vVgi7KTaU
	5i8JvhP8v51ope4O/3ju//Xwf/vibFIda2+xWxVvGaHoNnl4V4if/LoxfJNhYdjHGVLM
	4qSgHr+W+42bgicV38LeX86ICnSfFnGhM7gYq2yoD4oG21hZNLb3pJtGVpYWBPZGMmNt
	+Ljw==
X-Gm-Message-State: ALoCoQmhqGgdnCf5Gn+3jl8b3NfwD6o27ojZDm/eBzmol5+X0aqOf6cVPZFgVD9mTKzysy3cARsn
X-Received: by 10.194.79.199 with SMTP id l7mr496291wjx.136.1417541123769;
	Tue, 02 Dec 2014 09:25:23 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id
	gl11sm7425253wjc.40.2014.12.02.09.25.22 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 09:25:23 -0800 (PST)
Message-ID: <547DF602.2040704@linaro.org>
Date: Tue, 02 Dec 2014 17:25:22 +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 (Trump)" <zhangleiqiang@huawei.com>, 
	David Vrabel <david.vrabel@citrix.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>	<547D9B00.2090506@citrix.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FBB@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE23931FBB@SZXEMA512-MBX.china.huawei.com>
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 02/12/14 11:53, Zhangleiqiang (Trump) wrote:
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org
>> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of David Vrabel
>> Sent: Tuesday, December 02, 2014 6:57 PM
>> To: zhangleiqiang; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] Poor network performance between DomU with
>> multiqueue support
>>
>> On 02/12/14 08:30, zhangleiqiang wrote:
>>> Hi, all
>>>      I am testing the performance of xen netfront-netback driver that
>>> with multi-queues support. The throughput from domU to remote dom0 is
>>> 9.2Gb/s, but the throughput from domU to remote domU is only 3.6Gb/s,
>>> I think the bottleneck is the throughput from dom0 to local domU.
>>> However, we have done some testing and found the throughput from dom0
>>> to local domU is 5.8Gb/s.
>>>      And if we send packets from one DomU to other 3 DomUs on different
>>> host simultaneously, the sum of throughout can reach 9Gbps. It seems
>>> like the bottleneck is the receiver?
>>>      After some analysis, I found that even the max_queue of
>>> netfront/back is set to 4, there are some strange results as follows:
>>>      1. In domU, only one rx queue deal with softirq
>>>      2. In dom0, only two netback queues process are scheduled, other
>>> two process aren't scheduled.
>>
>> Multiqueue only has benefits if you have multiple flows since the
>> source/destination addresses are hashed to a queue number.  This probably
>> explains why only some of the queues are being used in your test.
>
> The hash method you mentioned is used for selection of netback process or netfront rx queue?
It's used in both direction to select the queue.

> Indeed, there are 4 netback processes running in Dom0, because there are only one DomU running in Dom0 and so four netback processes are running in Dom0 (the max_queue param of netback kernel module is set to 4).
> The phenomenon is that only 2 of these four netback process were running with about 70% cpu usage, and another two use little CPU.
>
>> 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
>

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 17:25:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 17:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvrCX-0002Ul-T6; Tue, 02 Dec 2014 17:25:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zoltan.kiss@linaro.org>) id 1XvrCX-0002Ug-FB
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 17:25:25 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	E5/16-14214-406FD745; Tue, 02 Dec 2014 17:25:24 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417541123!11151591!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15724 invoked from network); 2 Dec 2014 17:25:24 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 17:25:24 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so17758466wgh.16
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 09:25: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=MJGAq+QwP7cKWaW4yVpUYawolfftAyt2dlpNPzKoIDU=;
	b=U7jo3Dl/q/fmti3qdk98d7LA65rSsMuK90ql0E4baX5UqrN48VFCdHJAKa7C6EmSBu
	8ynCLMvlf5WZ4YVGIQ185F/r9sKZdBDpQmZpaiU0BgaqtSezJXkle6bcpRt4bB4FHYGU
	HXvRnXoMZdfVy89AGrnIrOXb7l1DK4OqS75bOzV2LDxval66icGAESP5C2/vVgi7KTaU
	5i8JvhP8v51ope4O/3ju//Xwf/vibFIda2+xWxVvGaHoNnl4V4if/LoxfJNhYdjHGVLM
	4qSgHr+W+42bgicV38LeX86ICnSfFnGhM7gYq2yoD4oG21hZNLb3pJtGVpYWBPZGMmNt
	+Ljw==
X-Gm-Message-State: ALoCoQmhqGgdnCf5Gn+3jl8b3NfwD6o27ojZDm/eBzmol5+X0aqOf6cVPZFgVD9mTKzysy3cARsn
X-Received: by 10.194.79.199 with SMTP id l7mr496291wjx.136.1417541123769;
	Tue, 02 Dec 2014 09:25:23 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id
	gl11sm7425253wjc.40.2014.12.02.09.25.22 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 02 Dec 2014 09:25:23 -0800 (PST)
Message-ID: <547DF602.2040704@linaro.org>
Date: Tue, 02 Dec 2014 17:25:22 +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 (Trump)" <zhangleiqiang@huawei.com>, 
	David Vrabel <david.vrabel@citrix.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>	<547D9B00.2090506@citrix.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FBB@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE23931FBB@SZXEMA512-MBX.china.huawei.com>
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 02/12/14 11:53, Zhangleiqiang (Trump) wrote:
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org
>> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of David Vrabel
>> Sent: Tuesday, December 02, 2014 6:57 PM
>> To: zhangleiqiang; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] Poor network performance between DomU with
>> multiqueue support
>>
>> On 02/12/14 08:30, zhangleiqiang wrote:
>>> Hi, all
>>>      I am testing the performance of xen netfront-netback driver that
>>> with multi-queues support. The throughput from domU to remote dom0 is
>>> 9.2Gb/s, but the throughput from domU to remote domU is only 3.6Gb/s,
>>> I think the bottleneck is the throughput from dom0 to local domU.
>>> However, we have done some testing and found the throughput from dom0
>>> to local domU is 5.8Gb/s.
>>>      And if we send packets from one DomU to other 3 DomUs on different
>>> host simultaneously, the sum of throughout can reach 9Gbps. It seems
>>> like the bottleneck is the receiver?
>>>      After some analysis, I found that even the max_queue of
>>> netfront/back is set to 4, there are some strange results as follows:
>>>      1. In domU, only one rx queue deal with softirq
>>>      2. In dom0, only two netback queues process are scheduled, other
>>> two process aren't scheduled.
>>
>> Multiqueue only has benefits if you have multiple flows since the
>> source/destination addresses are hashed to a queue number.  This probably
>> explains why only some of the queues are being used in your test.
>
> The hash method you mentioned is used for selection of netback process or netfront rx queue?
It's used in both direction to select the queue.

> Indeed, there are 4 netback processes running in Dom0, because there are only one DomU running in Dom0 and so four netback processes are running in Dom0 (the max_queue param of netback kernel module is set to 4).
> The phenomenon is that only 2 of these four netback process were running with about 70% cpu usage, and another two use little CPU.
>
>> 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
>

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 17:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 17: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 1Xvraf-000342-3v; Tue, 02 Dec 2014 17:50:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eswierk@skyportsystems.com>) id 1Xvrae-00033x-AJ
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 17:50:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	16/8D-15461-BDBFD745; Tue, 02 Dec 2014 17:50:19 +0000
X-Env-Sender: eswierk@skyportsystems.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417542618!12907392!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16363 invoked from network); 2 Dec 2014 17:50:19 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 17:50:19 -0000
Received: by mail-vc0-f173.google.com with SMTP id im17so5917675vcb.32
	for <xen-devel@lists.xenproject.org>;
	Tue, 02 Dec 2014 09:50: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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=aU2ZCvcZvfTVTJYz46H7QXD4UpJZ51Fki2hlhuFsk+o=;
	b=WAAX6/Z0BC7GYoqrW4AeGwcWQnTbNcyOtKqB6OL0vZs4BEdvoT2T9kzOmDFfWCxMJl
	eNaGLzrBU3JsVccy2Zn6GvXbPUXaQjDJnJPKI+ReQ3T6gZUyq7LmsmnjNtCe3Luh/LQc
	OXaWSJhWyctFi20esHrO6hlkkGUxbNtmD+wRrObTg4/TwfwPhs/U48bJDOEIWe0eVPxZ
	J5T54it0lsgqf/C13MvffsbJEoHNnP9BzhgEiQrkXL6GubgUQLqzEgARKDw2vCElb9gJ
	gmN7bWPa6oBc6+WpoH01yNI/VD9lKhKVmt2w9nfsYLq5jUJxEbncT6THzhGzYKBEpFLM
	ifmA==
X-Gm-Message-State: ALoCoQn+IXzSwGW/pGVvWR+O/AsbevpKRkgDMuhUfC/hZ07t5gVUp/F2qvFTJ4Com1w3yjSwTfj4
X-Received: by 10.220.103.74 with SMTP id j10mr458141vco.58.1417542618090;
	Tue, 02 Dec 2014 09:50:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.9.6 with HTTP; Tue, 2 Dec 2014 09:49:37 -0800 (PST)
In-Reply-To: <547DC617.8020107@citrix.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com> <547DC617.8020107@citrix.com>
From: Ed Swierk <eswierk@skyportsystems.com>
Date: Tue, 2 Dec 2014 09:49:37 -0800
Message-ID: <CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xenproject.org,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
	bison 3.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, Dec 2, 2014 at 6:00 AM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> The automatically generating doesn't actually work.  Depending on the
> relative timestamps caused by a SCM checkout, or a tarball extraction,
> the files will be attempted to be regenerated.
>
> These files are regenerated in the XenServer build, simply because of
> their order in the archived tarball.

When I clone the xen tree from git, the timestamps match about 95% of
the time, but the 5% failure rate was annoying enough that I finally
dug in to fix the parser build.

IMHO the generated files should be omitted from the source tree; as
long as the source files are actually buildable, there's no reason not
to treat them like any other source file.

--Ed

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 17:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 17: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 1Xvraf-000342-3v; Tue, 02 Dec 2014 17:50:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eswierk@skyportsystems.com>) id 1Xvrae-00033x-AJ
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 17:50:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	16/8D-15461-BDBFD745; Tue, 02 Dec 2014 17:50:19 +0000
X-Env-Sender: eswierk@skyportsystems.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417542618!12907392!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16363 invoked from network); 2 Dec 2014 17:50:19 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 17:50:19 -0000
Received: by mail-vc0-f173.google.com with SMTP id im17so5917675vcb.32
	for <xen-devel@lists.xenproject.org>;
	Tue, 02 Dec 2014 09:50: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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=aU2ZCvcZvfTVTJYz46H7QXD4UpJZ51Fki2hlhuFsk+o=;
	b=WAAX6/Z0BC7GYoqrW4AeGwcWQnTbNcyOtKqB6OL0vZs4BEdvoT2T9kzOmDFfWCxMJl
	eNaGLzrBU3JsVccy2Zn6GvXbPUXaQjDJnJPKI+ReQ3T6gZUyq7LmsmnjNtCe3Luh/LQc
	OXaWSJhWyctFi20esHrO6hlkkGUxbNtmD+wRrObTg4/TwfwPhs/U48bJDOEIWe0eVPxZ
	J5T54it0lsgqf/C13MvffsbJEoHNnP9BzhgEiQrkXL6GubgUQLqzEgARKDw2vCElb9gJ
	gmN7bWPa6oBc6+WpoH01yNI/VD9lKhKVmt2w9nfsYLq5jUJxEbncT6THzhGzYKBEpFLM
	ifmA==
X-Gm-Message-State: ALoCoQn+IXzSwGW/pGVvWR+O/AsbevpKRkgDMuhUfC/hZ07t5gVUp/F2qvFTJ4Com1w3yjSwTfj4
X-Received: by 10.220.103.74 with SMTP id j10mr458141vco.58.1417542618090;
	Tue, 02 Dec 2014 09:50:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.9.6 with HTTP; Tue, 2 Dec 2014 09:49:37 -0800 (PST)
In-Reply-To: <547DC617.8020107@citrix.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com> <547DC617.8020107@citrix.com>
From: Ed Swierk <eswierk@skyportsystems.com>
Date: Tue, 2 Dec 2014 09:49:37 -0800
Message-ID: <CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xenproject.org,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
	bison 3.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, Dec 2, 2014 at 6:00 AM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> The automatically generating doesn't actually work.  Depending on the
> relative timestamps caused by a SCM checkout, or a tarball extraction,
> the files will be attempted to be regenerated.
>
> These files are regenerated in the XenServer build, simply because of
> their order in the archived tarball.

When I clone the xen tree from git, the timestamps match about 95% of
the time, but the 5% failure rate was annoying enough that I finally
dug in to fix the parser build.

IMHO the generated files should be omitted from the source tree; as
long as the source files are actually buildable, there's no reason not
to treat them like any other source file.

--Ed

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 18:11:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvruR-0003dO-WB; Tue, 02 Dec 2014 18:10: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 1XvruQ-0003dJ-Hr
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 18:10:46 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	DC/2E-08051-5A00E745; Tue, 02 Dec 2014 18:10:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417543843!12453245!1
X-Originating-IP: [66.165.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 4980 invoked from network); 2 Dec 2014 18:10:45 -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;
	2 Dec 2014 18:10:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,502,1413244800"; d="scan'208";a="198996364"
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, 2 Dec 2014 13:00: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 1Xvrku-0003rx-OA;
	Tue, 02 Dec 2014 18:00:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xvrku-0003X2-CZ;
	Tue, 02 Dec 2014 18:00:56 +0000
Date: Tue, 2 Dec 2014 18:00:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31985-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] 31985: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10      fail pass in 31965
 test-amd64-i386-xl-win7-amd64  5 xen-boot          fail in 31965 pass in 31985

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
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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
 test-amd64-amd64-xl-qemut-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                                 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 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 Tue Dec 02 18:11:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvruR-0003dO-WB; Tue, 02 Dec 2014 18:10: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 1XvruQ-0003dJ-Hr
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 18:10:46 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	DC/2E-08051-5A00E745; Tue, 02 Dec 2014 18:10:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417543843!12453245!1
X-Originating-IP: [66.165.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 4980 invoked from network); 2 Dec 2014 18:10:45 -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;
	2 Dec 2014 18:10:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,502,1413244800"; d="scan'208";a="198996364"
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, 2 Dec 2014 13:00: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 1Xvrku-0003rx-OA;
	Tue, 02 Dec 2014 18:00:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xvrku-0003X2-CZ;
	Tue, 02 Dec 2014 18:00:56 +0000
Date: Tue, 2 Dec 2014 18:00:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31985-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] 31985: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10      fail pass in 31965
 test-amd64-i386-xl-win7-amd64  5 xen-boot          fail in 31965 pass in 31985

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
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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
 test-amd64-amd64-xl-qemut-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                                 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 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 Tue Dec 02 18:33:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvsFv-0004Ga-7A; Tue, 02 Dec 2014 18:32: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 1XvsFu-0004GV-8o
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 18:32:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	10/A5-25276-9D50E745; Tue, 02 Dec 2014 18:32:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417545175!5642002!1
X-Originating-IP: [156.151.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 11373 invoked from network); 2 Dec 2014 18:32:56 -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; 2 Dec 2014 18:32:56 -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 sB2IWlPX007858
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:32:48 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
	sB2IWjNU007935
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 18:32:46 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
	sB2IWjfJ013198; Tue, 2 Dec 2014 18:32:45 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:32:45 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0EC9F11B062; Tue,  2 Dec 2014 13:32:44 -0500 (EST)
Date: Tue, 2 Dec 2014 13:32:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202183244.GD32385@laptop.dumpdata.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417528036.24320.32.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>,
	Ed Swierk <eswierk@skyportsystems.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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, Dec 02, 2014 at 01:47:16PM +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 12:19 +0000, Wei Liu wrote:
> > On Mon, Dec 01, 2014 at 09:42:13AM +0000, Ian Campbell wrote:
> > > On Sat, 2014-11-29 at 21:23 -0800, Ed Swierk wrote:
> > > > - Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
> > > >   parameter
> > > > - Change deprecated %name-prefix= to %name-prefix
> > > > 
> > > > Tested against bison 2.4.1 and 3.0.2.
> > > > 
> > > > Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
> > > 
> > > Copying Ian J who is the bison guy among the toolstack maintainers.
> > > 
> > 
> > FWIW I can confirm that libxlu_cfg_y.y won't build in Debian Jessie
> > (bison 3.0.2) as is. And this patch fixes the problem for me.
> 
> That would seem like a pretty strong case for 4.5, *except* we ship the
> generated files so it should be possible to build anywhere without
> requiring any version of bison at all. If Bison is installed then
> "./configure BISON=/bin/true" or some such might be needed to stop it
> trying to regenerate.
> 
> Konrad, any thoughts.

Using the autogenerated one means that it might introduce a bug.

However we do allow regeneration of it - and it would be a shame if
the auto-generated well, could not be autogenerated!

That is a bug, not a major one, but a bug nonethless.

It is not a regression thought.

The build systems (debian, fedora) all have buildrequires which do
not list 'bison' and as such don't encounter this I think - which means
it is only encountered by folks who build from the sources - which
is a small list.

I would lean towards documenting this in the release notes (the work
around mentioned above) and defer this to Xen 4.6.



> 
> > 
> > Wei.
> > 
> > > > ---
> > > >  tools/libxl/libxlu_cfg_y.y | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
> > > > index aa9f787..5acd438 100644
> > > > --- a/tools/libxl/libxlu_cfg_y.y
> > > > +++ b/tools/libxl/libxlu_cfg_y.y
> > > > @@ -17,7 +17,7 @@
> > > >   */
> > > >  
> > > >  %{
> > > > -#define YYLEX_PARAM ctx->scanner
> > > > +#define ctx_scanner ctx->scanner
> > > >  #include "libxlu_cfg_i.h"
> > > >  #include "libxlu_cfg_l.h"
> > > >  %}
> > > > @@ -31,9 +31,9 @@
> > > >  %pure-parser
> > > >  %defines
> > > >  %error-verbose
> > > > -%name-prefix="xlu__cfg_yy"
> > > > +%name-prefix "xlu__cfg_yy"
> > > >  %parse-param { CfgParseContext *ctx }
> > > > -%lex-param { void *scanner }
> > > > +%lex-param { ctx_scanner }
> > > >  
> > > >  %token <string>                IDENT STRING NUMBER NEWLINE
> > > >  %type <string>            atom
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/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 Dec 02 18:33:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvsG3-0004H1-J9; Tue, 02 Dec 2014 18:33:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <imp@bsdimp.com>) id 1XvsDO-00046x-KX
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:30:22 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	46/5D-17694-D350E745; Tue, 02 Dec 2014 18:30:21 +0000
X-Env-Sender: imp@bsdimp.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417545018!12902694!1
X-Originating-IP: [209.85.192.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 12127 invoked from network); 2 Dec 2014 18:30:20 -0000
Received: from mail-pd0-f174.google.com (HELO mail-pd0-f174.google.com)
	(209.85.192.174)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 18:30:20 -0000
Received: by mail-pd0-f174.google.com with SMTP id w10so13581819pde.5
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 10:30: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:sender:subject:mime-version:content-type:from
	:in-reply-to:date:cc:message-id:references:to;
	bh=X5Op8ICs+XBRo0QRKJt9D4w6MuspzvQIWq3yN7h/cfw=;
	b=D1bMkmc3/vn3rhdGGfAJ0lumJohrZUfR9S7bq/mdtPl/w8PVa6ICWfzig89RToNp6L
	beXYWUubkfT7oQ02OS7h800ViHtxfra2nHSCd1DI89LzHHpF0zWLFeLXyU9k6DgFwAJs
	/jMTUVrUlCz34h/XEj+0XCjIB/glvPt7qbmy/S/rcp1xMckzoT1gbF34iy6VSOWGqgE2
	C4wzHQOEKD+94sHi3vm7OUlBrcrS5SgbOciyKhkxbMOjlnLdUnYZ9aILvUIbHlnO2idG
	AQx14GXHzBnS95RNwEQ1zUup+MFgsT9/bIoU8IeeOSYvz8QkCN4lWESDdhuLp65Jk4Ew
	Zy4g==
X-Gm-Message-State: ALoCoQkGZbQpOZUqgmtSVLAY1enBP86DeebrQXiRL9HAgHh0v6wy4tCNPyA3Qf0j8AbdFx3BlzVj
X-Received: by 10.66.221.168 with SMTP id qf8mr1192832pac.102.1417545018305;
	Tue, 02 Dec 2014 10:30:18 -0800 (PST)
Received: from [10.64.24.134] ([69.53.236.236])
	by mx.google.com with ESMTPSA id
	xk1sm12855272pab.13.2014.12.02.10.30.16 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 02 Dec 2014 10:30:17 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Pgp-Agent: GPGMail 2.5b3
From: Warner Losh <imp@bsdimp.com>
In-Reply-To: <547DDB4B.6060506@linaro.org>
Date: Tue, 2 Dec 2014 11:30:14 -0700
Message-Id: <B47D5F0D-4C91-4F43-A436-F67522EEE8EA@bsdimp.com>
References: <54726138.3090003@linaro.org> <20141128135737.23a71643@bender.lan>
	<547DDB4B.6060506@linaro.org>
To: Julien Grall <julien.grall@linaro.org>
X-Mailer: Apple Mail (2.1993)
X-Mailman-Approved-At: Tue, 02 Dec 2014 18:33:06 +0000
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Andrew Turner <andrew@fubar.geek.nz>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	freebsd-xen@freebsd.org, freebsd-arm <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: multipart/mixed; boundary="===============2381160073233956394=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2381160073233956394==
Content-Type: multipart/signed; boundary="Apple-Mail=_1310916B-3B53-4C5A-B293-E67B588CB60E"; protocol="application/pgp-signature"; micalg=pgp-sha512


--Apple-Mail=_1310916B-3B53-4C5A-B293-E67B588CB60E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hey Julien,

Have you rebased your patch train after Andrew=E2=80=99s commits?

Warner

> On Dec 2, 2014, at 8:31 AM, Julien Grall <julien.grall@linaro.org> =
wrote:
>=20
> Hello Andrew,
>=20
> On 28/11/2014 13:57, Andrew Turner wrote:
>> On Sun, 23 Nov 2014 22:35:36 +0000
>> Julien Grall <julien.grall@linaro.org> wrote:
>>> 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)
>>>=20
>>> 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?
>>=20
>> 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.
>=20
> Thanks, I will give a look to this solution.
>=20
>>>=20
>>> 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
>>=20
>> I have committed patches 30 and 40 as they look good.
>=20
> Thanks!
>=20
>> 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.
>=20
> Right, I guess I could just keep the roundup2.
>=20
>>=20
>> ...
>>>=20
>>> TODO:
>>> 	* Add SMP/PSCI support in FreeBSD. Could be useful other
>>> platform too
>>=20
>> Adding PSCI support is on my TODO lost for arm64, however I don't
>> expect to get on ti in until early next year.
>=20
> BTW, what is the actual status of the ARM64 port? I plan to give a =
look
> for adding Xen support too.


--Apple-Mail=_1310916B-3B53-4C5A-B293-E67B588CB60E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUfgU2AAoJEGwc0Sh9sBEAqIQP/Rx3lyiz1spiwso9X2aKl4qk
RMCKlQPUsujqoNa29nEtzNjmRidzXbgm3VV/fBOXkLkKefZ8vwgVoPCHOBd/9zua
qmnAGyfju+xDw5LPeRrsPOLXA4OctOPEG7vJy+52tdyKDYpB2F+P60Y8NuttL3wR
sVrHbo7V9PzmoQBzFgmCWaMg1A86K6O50b9uRZREL8qX4x+cx/M97bUmH0AbaesE
5bA+Avn9RmN3lmaIWCcTFMDj6zkplLBOaB4pBMf5+JpDYw8Tm8kF7jWXkUgLqzRn
9HFLjJMlDDWSdyG0vOAzUeyaQBlg+u7LcpgIlkKk4awNcoLTc5uUvaDr+re8eYny
eW1FBzyujK9N8Itc68m4k4CcYbBMlKLxzJHAnNt3Te+3JFrAIzI4H9cRX8Q1qmFC
o+Nbr5h2S2rMZfl3qRtIj0JTtnRjs9PGug4Bv3vIVujBZ67rRepyMkuKjBrXfKBR
lqTntSHnkD7jNEwyLBXxy50Mq9jJopI8uBEBmLWJ1RdEudcWlTSpxDEv5qiPjMhf
XEeGg8CaEAY/vuixibDqzzM0MthX/XFAH3ubboAUPEGIPiAOXcMLMJOnw5JtrjZK
zQ7UWQh2ie33Zb9LMrP3t6+71SN6G0ZbiDpRlD/RJ1neBpnsnQgwSkQBu7PPa+u/
gk/rYNoAnGOyvay0YYeV
=gSrq
-----END PGP SIGNATURE-----

--Apple-Mail=_1310916B-3B53-4C5A-B293-E67B588CB60E--


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

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

--===============2381160073233956394==--


From xen-devel-bounces@lists.xen.org Tue Dec 02 18:33:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvsFv-0004Ga-7A; Tue, 02 Dec 2014 18:32: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 1XvsFu-0004GV-8o
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 18:32:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	10/A5-25276-9D50E745; Tue, 02 Dec 2014 18:32:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417545175!5642002!1
X-Originating-IP: [156.151.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 11373 invoked from network); 2 Dec 2014 18:32:56 -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; 2 Dec 2014 18:32:56 -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 sB2IWlPX007858
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:32:48 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
	sB2IWjNU007935
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 18:32:46 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
	sB2IWjfJ013198; Tue, 2 Dec 2014 18:32:45 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:32:45 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0EC9F11B062; Tue,  2 Dec 2014 13:32:44 -0500 (EST)
Date: Tue, 2 Dec 2014 13:32:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202183244.GD32385@laptop.dumpdata.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417528036.24320.32.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>,
	Ed Swierk <eswierk@skyportsystems.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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, Dec 02, 2014 at 01:47:16PM +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 12:19 +0000, Wei Liu wrote:
> > On Mon, Dec 01, 2014 at 09:42:13AM +0000, Ian Campbell wrote:
> > > On Sat, 2014-11-29 at 21:23 -0800, Ed Swierk wrote:
> > > > - Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
> > > >   parameter
> > > > - Change deprecated %name-prefix= to %name-prefix
> > > > 
> > > > Tested against bison 2.4.1 and 3.0.2.
> > > > 
> > > > Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
> > > 
> > > Copying Ian J who is the bison guy among the toolstack maintainers.
> > > 
> > 
> > FWIW I can confirm that libxlu_cfg_y.y won't build in Debian Jessie
> > (bison 3.0.2) as is. And this patch fixes the problem for me.
> 
> That would seem like a pretty strong case for 4.5, *except* we ship the
> generated files so it should be possible to build anywhere without
> requiring any version of bison at all. If Bison is installed then
> "./configure BISON=/bin/true" or some such might be needed to stop it
> trying to regenerate.
> 
> Konrad, any thoughts.

Using the autogenerated one means that it might introduce a bug.

However we do allow regeneration of it - and it would be a shame if
the auto-generated well, could not be autogenerated!

That is a bug, not a major one, but a bug nonethless.

It is not a regression thought.

The build systems (debian, fedora) all have buildrequires which do
not list 'bison' and as such don't encounter this I think - which means
it is only encountered by folks who build from the sources - which
is a small list.

I would lean towards documenting this in the release notes (the work
around mentioned above) and defer this to Xen 4.6.



> 
> > 
> > Wei.
> > 
> > > > ---
> > > >  tools/libxl/libxlu_cfg_y.y | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
> > > > index aa9f787..5acd438 100644
> > > > --- a/tools/libxl/libxlu_cfg_y.y
> > > > +++ b/tools/libxl/libxlu_cfg_y.y
> > > > @@ -17,7 +17,7 @@
> > > >   */
> > > >  
> > > >  %{
> > > > -#define YYLEX_PARAM ctx->scanner
> > > > +#define ctx_scanner ctx->scanner
> > > >  #include "libxlu_cfg_i.h"
> > > >  #include "libxlu_cfg_l.h"
> > > >  %}
> > > > @@ -31,9 +31,9 @@
> > > >  %pure-parser
> > > >  %defines
> > > >  %error-verbose
> > > > -%name-prefix="xlu__cfg_yy"
> > > > +%name-prefix "xlu__cfg_yy"
> > > >  %parse-param { CfgParseContext *ctx }
> > > > -%lex-param { void *scanner }
> > > > +%lex-param { ctx_scanner }
> > > >  
> > > >  %token <string>                IDENT STRING NUMBER NEWLINE
> > > >  %type <string>            atom
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/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 Dec 02 18:33:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvsG3-0004H1-J9; Tue, 02 Dec 2014 18:33:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <imp@bsdimp.com>) id 1XvsDO-00046x-KX
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:30:22 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	46/5D-17694-D350E745; Tue, 02 Dec 2014 18:30:21 +0000
X-Env-Sender: imp@bsdimp.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417545018!12902694!1
X-Originating-IP: [209.85.192.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 12127 invoked from network); 2 Dec 2014 18:30:20 -0000
Received: from mail-pd0-f174.google.com (HELO mail-pd0-f174.google.com)
	(209.85.192.174)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Dec 2014 18:30:20 -0000
Received: by mail-pd0-f174.google.com with SMTP id w10so13581819pde.5
	for <xen-devel@lists.xen.org>; Tue, 02 Dec 2014 10:30: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:sender:subject:mime-version:content-type:from
	:in-reply-to:date:cc:message-id:references:to;
	bh=X5Op8ICs+XBRo0QRKJt9D4w6MuspzvQIWq3yN7h/cfw=;
	b=D1bMkmc3/vn3rhdGGfAJ0lumJohrZUfR9S7bq/mdtPl/w8PVa6ICWfzig89RToNp6L
	beXYWUubkfT7oQ02OS7h800ViHtxfra2nHSCd1DI89LzHHpF0zWLFeLXyU9k6DgFwAJs
	/jMTUVrUlCz34h/XEj+0XCjIB/glvPt7qbmy/S/rcp1xMckzoT1gbF34iy6VSOWGqgE2
	C4wzHQOEKD+94sHi3vm7OUlBrcrS5SgbOciyKhkxbMOjlnLdUnYZ9aILvUIbHlnO2idG
	AQx14GXHzBnS95RNwEQ1zUup+MFgsT9/bIoU8IeeOSYvz8QkCN4lWESDdhuLp65Jk4Ew
	Zy4g==
X-Gm-Message-State: ALoCoQkGZbQpOZUqgmtSVLAY1enBP86DeebrQXiRL9HAgHh0v6wy4tCNPyA3Qf0j8AbdFx3BlzVj
X-Received: by 10.66.221.168 with SMTP id qf8mr1192832pac.102.1417545018305;
	Tue, 02 Dec 2014 10:30:18 -0800 (PST)
Received: from [10.64.24.134] ([69.53.236.236])
	by mx.google.com with ESMTPSA id
	xk1sm12855272pab.13.2014.12.02.10.30.16 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 02 Dec 2014 10:30:17 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Pgp-Agent: GPGMail 2.5b3
From: Warner Losh <imp@bsdimp.com>
In-Reply-To: <547DDB4B.6060506@linaro.org>
Date: Tue, 2 Dec 2014 11:30:14 -0700
Message-Id: <B47D5F0D-4C91-4F43-A436-F67522EEE8EA@bsdimp.com>
References: <54726138.3090003@linaro.org> <20141128135737.23a71643@bender.lan>
	<547DDB4B.6060506@linaro.org>
To: Julien Grall <julien.grall@linaro.org>
X-Mailer: Apple Mail (2.1993)
X-Mailman-Approved-At: Tue, 02 Dec 2014 18:33:06 +0000
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Andrew Turner <andrew@fubar.geek.nz>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	freebsd-xen@freebsd.org, freebsd-arm <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: multipart/mixed; boundary="===============2381160073233956394=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2381160073233956394==
Content-Type: multipart/signed; boundary="Apple-Mail=_1310916B-3B53-4C5A-B293-E67B588CB60E"; protocol="application/pgp-signature"; micalg=pgp-sha512


--Apple-Mail=_1310916B-3B53-4C5A-B293-E67B588CB60E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hey Julien,

Have you rebased your patch train after Andrew=E2=80=99s commits?

Warner

> On Dec 2, 2014, at 8:31 AM, Julien Grall <julien.grall@linaro.org> =
wrote:
>=20
> Hello Andrew,
>=20
> On 28/11/2014 13:57, Andrew Turner wrote:
>> On Sun, 23 Nov 2014 22:35:36 +0000
>> Julien Grall <julien.grall@linaro.org> wrote:
>>> 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)
>>>=20
>>> 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?
>>=20
>> 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.
>=20
> Thanks, I will give a look to this solution.
>=20
>>>=20
>>> 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
>>=20
>> I have committed patches 30 and 40 as they look good.
>=20
> Thanks!
>=20
>> 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.
>=20
> Right, I guess I could just keep the roundup2.
>=20
>>=20
>> ...
>>>=20
>>> TODO:
>>> 	* Add SMP/PSCI support in FreeBSD. Could be useful other
>>> platform too
>>=20
>> Adding PSCI support is on my TODO lost for arm64, however I don't
>> expect to get on ti in until early next year.
>=20
> BTW, what is the actual status of the ARM64 port? I plan to give a =
look
> for adding Xen support too.


--Apple-Mail=_1310916B-3B53-4C5A-B293-E67B588CB60E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUfgU2AAoJEGwc0Sh9sBEAqIQP/Rx3lyiz1spiwso9X2aKl4qk
RMCKlQPUsujqoNa29nEtzNjmRidzXbgm3VV/fBOXkLkKefZ8vwgVoPCHOBd/9zua
qmnAGyfju+xDw5LPeRrsPOLXA4OctOPEG7vJy+52tdyKDYpB2F+P60Y8NuttL3wR
sVrHbo7V9PzmoQBzFgmCWaMg1A86K6O50b9uRZREL8qX4x+cx/M97bUmH0AbaesE
5bA+Avn9RmN3lmaIWCcTFMDj6zkplLBOaB4pBMf5+JpDYw8Tm8kF7jWXkUgLqzRn
9HFLjJMlDDWSdyG0vOAzUeyaQBlg+u7LcpgIlkKk4awNcoLTc5uUvaDr+re8eYny
eW1FBzyujK9N8Itc68m4k4CcYbBMlKLxzJHAnNt3Te+3JFrAIzI4H9cRX8Q1qmFC
o+Nbr5h2S2rMZfl3qRtIj0JTtnRjs9PGug4Bv3vIVujBZ67rRepyMkuKjBrXfKBR
lqTntSHnkD7jNEwyLBXxy50Mq9jJopI8uBEBmLWJ1RdEudcWlTSpxDEv5qiPjMhf
XEeGg8CaEAY/vuixibDqzzM0MthX/XFAH3ubboAUPEGIPiAOXcMLMJOnw5JtrjZK
zQ7UWQh2ie33Zb9LMrP3t6+71SN6G0ZbiDpRlD/RJ1neBpnsnQgwSkQBu7PPa+u/
gk/rYNoAnGOyvay0YYeV
=gSrq
-----END PGP SIGNATURE-----

--Apple-Mail=_1310916B-3B53-4C5A-B293-E67B588CB60E--


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

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

--===============2381160073233956394==--


From xen-devel-bounces@lists.xen.org Tue Dec 02 18:36:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18:36:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvsJL-0004U0-7G; Tue, 02 Dec 2014 18:36:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvsJK-0004Ts-Bp
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 18:36:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	42/58-25276-DA60E745; Tue, 02 Dec 2014 18:36:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417545387!12600654!1
X-Originating-IP: [156.151.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 5309 invoked from network); 2 Dec 2014 18:36: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; 2 Dec 2014 18:36:28 -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 sB2IaLO3012470
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:36: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
	sB2IaKjd020493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 18:36:20 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
	sB2IaKpk020484; Tue, 2 Dec 2014 18:36:20 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:36:19 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5DF5211B06B; Tue,  2 Dec 2014 13:36:20 -0500 (EST)
Date: Tue, 2 Dec 2014 13:36:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20141202183620.GE32385@laptop.dumpdata.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
 target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

This usage scenario which I can see this being useful (and
I've tripped over this) is when you rebuild a new version
from the same repo. As in, this affects developers, but
not end-users and not distros. But perhaps I am missing
one scenario?

As such I would lean towards deferring this (and the other
two) to Xen 4.6.

Thank you!
> ---
>  tools/Makefile         |    3 +++
>  tools/hotplug/Makefile |    5 ++++-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index af9798a..19b24f3 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -261,6 +261,9 @@ subdir-all-debugger/kdd: .phony
>  subdir-distclean-firmware: .phony
>  	$(MAKE) -C firmware distclean
>  
> +subdir-distclean-hotplug: .phony
> +	$(MAKE) -C hotplug distclean
> +
>  subtree-force-update:
>  ifeq ($(CONFIG_QEMU_XEN),y)
>  	$(MAKE) qemu-xen-dir-force-update
> diff --git a/tools/hotplug/Makefile b/tools/hotplug/Makefile
> index 14ae9a8..a29a522 100644
> --- a/tools/hotplug/Makefile
> +++ b/tools/hotplug/Makefile
> @@ -6,5 +6,8 @@ SUBDIRS-$(CONFIG_NetBSD) += NetBSD
>  SUBDIRS-$(CONFIG_Linux) += Linux
>  SUBDIRS-$(CONFIG_FreeBSD) += FreeBSD
>  
> -.PHONY: all clean install
> +.PHONY: all clean distclean install
>  all clean install: %: subdirs-%
> +
> +distclean:
> +	rm -f Linux/init.d/sysconfig.xencommons Linux/init.d/xencommons NetBSD/rc.d/xencommons
> -- 
> 1.7.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 Dec 02 18:36:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18:36:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvsJL-0004U0-7G; Tue, 02 Dec 2014 18:36:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvsJK-0004Ts-Bp
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 18:36:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	42/58-25276-DA60E745; Tue, 02 Dec 2014 18:36:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417545387!12600654!1
X-Originating-IP: [156.151.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 5309 invoked from network); 2 Dec 2014 18:36: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; 2 Dec 2014 18:36:28 -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 sB2IaLO3012470
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:36: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
	sB2IaKjd020493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 18:36:20 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
	sB2IaKpk020484; Tue, 2 Dec 2014 18:36:20 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:36:19 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5DF5211B06B; Tue,  2 Dec 2014 13:36:20 -0500 (EST)
Date: Tue, 2 Dec 2014 13:36:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20141202183620.GE32385@laptop.dumpdata.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
 target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

This usage scenario which I can see this being useful (and
I've tripped over this) is when you rebuild a new version
from the same repo. As in, this affects developers, but
not end-users and not distros. But perhaps I am missing
one scenario?

As such I would lean towards deferring this (and the other
two) to Xen 4.6.

Thank you!
> ---
>  tools/Makefile         |    3 +++
>  tools/hotplug/Makefile |    5 ++++-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index af9798a..19b24f3 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -261,6 +261,9 @@ subdir-all-debugger/kdd: .phony
>  subdir-distclean-firmware: .phony
>  	$(MAKE) -C firmware distclean
>  
> +subdir-distclean-hotplug: .phony
> +	$(MAKE) -C hotplug distclean
> +
>  subtree-force-update:
>  ifeq ($(CONFIG_QEMU_XEN),y)
>  	$(MAKE) qemu-xen-dir-force-update
> diff --git a/tools/hotplug/Makefile b/tools/hotplug/Makefile
> index 14ae9a8..a29a522 100644
> --- a/tools/hotplug/Makefile
> +++ b/tools/hotplug/Makefile
> @@ -6,5 +6,8 @@ SUBDIRS-$(CONFIG_NetBSD) += NetBSD
>  SUBDIRS-$(CONFIG_Linux) += Linux
>  SUBDIRS-$(CONFIG_FreeBSD) += FreeBSD
>  
> -.PHONY: all clean install
> +.PHONY: all clean distclean install
>  all clean install: %: subdirs-%
> +
> +distclean:
> +	rm -f Linux/init.d/sysconfig.xencommons Linux/init.d/xencommons NetBSD/rc.d/xencommons
> -- 
> 1.7.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 Dec 02 18:38:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18:38:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvsLF-0004bp-OR; Tue, 02 Dec 2014 18:38: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 1XvsLE-0004bk-W1
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:38:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0A/F9-25276-4270E745; Tue, 02 Dec 2014 18:38:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417545506!12924556!1
X-Originating-IP: [156.151.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 15447 invoked from network); 2 Dec 2014 18:38:27 -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; 2 Dec 2014 18:38:27 -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 sB2IbvDP014190
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:37:57 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
	sB2IbtOd000010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 18:37:56 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
	sB2Ibtdq018924; Tue, 2 Dec 2014 18:37:55 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:37:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 485E011B06E; Tue,  2 Dec 2014 13:37:55 -0500 (EST)
Date: Tue, 2 Dec 2014 13:37:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>, olaf@aepfle.de, m.a.young@durham.ac.uk
Message-ID: <20141202183755.GF32385@laptop.dumpdata.com>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Mark Pryor <tlviewer@yahoo.com>, Ian Campbell <ian.campbell@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 03:11:30PM +0000, Wei Liu wrote:
> AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> incorrect, even in the event systemd library is available.  Use
> PKG_CHECK_MODULES instead.
> 
> Tested on Debian Jessie and Arch Linux.

And Fedora and SuSE? CC-ing the other distro maintainers
for their input.

> 
> Please rerun autogen.sh after applying this patch.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.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: Anthony Perard <anthony.perard@citrix.com>
> Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
> Cc: Mark Pryor <tlviewer@yahoo.com>
> ---
>  m4/systemd.m4 | 12 ++----------
>  1 file changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/m4/systemd.m4 b/m4/systemd.m4
> index a832d59..b04964b 100644
> --- a/m4/systemd.m4
> +++ b/m4/systemd.m4
> @@ -42,13 +42,6 @@ AC_DEFUN([AX_ALLOW_SYSTEMD_OPTS], [
>  ])
>  
>  AC_DEFUN([AX_CHECK_SYSTEMD_LIBS], [
> -	AC_CHECK_HEADER([systemd/sd-daemon.h], [
> -	    AC_CHECK_LIB([systemd-daemon], [sd_listen_fds], [libsystemddaemon="y"])
> -	])
> -	AS_IF([test "x$libsystemddaemon" = x], [
> -	    AC_MSG_ERROR([Unable to find a suitable libsystemd-daemon library])
> -	])
> -
>  	PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon])
>  	dnl pkg-config older than 0.24 does not set these for
>  	dnl PKG_CHECK_MODULES() worth also noting is that as of version 208
> @@ -98,9 +91,8 @@ AC_DEFUN([AX_CHECK_SYSTEMD], [
>  ])
>  
>  AC_DEFUN([AX_CHECK_SYSTEMD_ENABLE_AVAILABLE], [
> -	AC_CHECK_HEADER([systemd/sd-daemon.h], [
> -	    AC_CHECK_LIB([systemd-daemon], [sd_listen_fds], [systemd="y"])
> -	])
> +	PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon], [systemd="y"],
> +                          [systemd="n"])
>  ])
>  
>  dnl Enables systemd by default and requires a --disable-systemd option flag
> -- 
> 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 Dec 02 18:38:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18:38:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvsLF-0004bp-OR; Tue, 02 Dec 2014 18:38: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 1XvsLE-0004bk-W1
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:38:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0A/F9-25276-4270E745; Tue, 02 Dec 2014 18:38:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417545506!12924556!1
X-Originating-IP: [156.151.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 15447 invoked from network); 2 Dec 2014 18:38:27 -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; 2 Dec 2014 18:38:27 -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 sB2IbvDP014190
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:37:57 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
	sB2IbtOd000010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 18:37:56 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
	sB2Ibtdq018924; Tue, 2 Dec 2014 18:37:55 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:37:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 485E011B06E; Tue,  2 Dec 2014 13:37:55 -0500 (EST)
Date: Tue, 2 Dec 2014 13:37:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>, olaf@aepfle.de, m.a.young@durham.ac.uk
Message-ID: <20141202183755.GF32385@laptop.dumpdata.com>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Mark Pryor <tlviewer@yahoo.com>, Ian Campbell <ian.campbell@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 03:11:30PM +0000, Wei Liu wrote:
> AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> incorrect, even in the event systemd library is available.  Use
> PKG_CHECK_MODULES instead.
> 
> Tested on Debian Jessie and Arch Linux.

And Fedora and SuSE? CC-ing the other distro maintainers
for their input.

> 
> Please rerun autogen.sh after applying this patch.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.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: Anthony Perard <anthony.perard@citrix.com>
> Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
> Cc: Mark Pryor <tlviewer@yahoo.com>
> ---
>  m4/systemd.m4 | 12 ++----------
>  1 file changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/m4/systemd.m4 b/m4/systemd.m4
> index a832d59..b04964b 100644
> --- a/m4/systemd.m4
> +++ b/m4/systemd.m4
> @@ -42,13 +42,6 @@ AC_DEFUN([AX_ALLOW_SYSTEMD_OPTS], [
>  ])
>  
>  AC_DEFUN([AX_CHECK_SYSTEMD_LIBS], [
> -	AC_CHECK_HEADER([systemd/sd-daemon.h], [
> -	    AC_CHECK_LIB([systemd-daemon], [sd_listen_fds], [libsystemddaemon="y"])
> -	])
> -	AS_IF([test "x$libsystemddaemon" = x], [
> -	    AC_MSG_ERROR([Unable to find a suitable libsystemd-daemon library])
> -	])
> -
>  	PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon])
>  	dnl pkg-config older than 0.24 does not set these for
>  	dnl PKG_CHECK_MODULES() worth also noting is that as of version 208
> @@ -98,9 +91,8 @@ AC_DEFUN([AX_CHECK_SYSTEMD], [
>  ])
>  
>  AC_DEFUN([AX_CHECK_SYSTEMD_ENABLE_AVAILABLE], [
> -	AC_CHECK_HEADER([systemd/sd-daemon.h], [
> -	    AC_CHECK_LIB([systemd-daemon], [sd_listen_fds], [systemd="y"])
> -	])
> +	PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon], [systemd="y"],
> +                          [systemd="n"])
>  ])
>  
>  dnl Enables systemd by default and requires a --disable-systemd option flag
> -- 
> 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 Dec 02 18:39:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18:39:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvsMC-0004go-6u; Tue, 02 Dec 2014 18:39: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 1XvsMB-0004gd-7F
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:39:27 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	30/44-22737-E570E745; Tue, 02 Dec 2014 18:39:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417545564!8259948!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15715 invoked from network); 2 Dec 2014 18:39:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2014 18:39: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 sB2IdLrd020936
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:39:22 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
	sB2IdKCN004615
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 18:39:21 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
	sB2IdKZa000972; Tue, 2 Dec 2014 18:39:20 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:39:20 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 98DFD11B072; Tue,  2 Dec 2014 13:39:20 -0500 (EST)
Date: Tue, 2 Dec 2014 13:39:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141202183920.GG32385@laptop.dumpdata.com>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
	<20141202154652.GA26732@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202154652.GA26732@aepfle.de>
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
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 04:46:52PM +0100, Olaf Hering wrote:
> On Mon, Dec 01, Konrad Rzeszutek Wilk wrote:
> 
> > That is odd - I see any device 'hot-plugged' being added at 00:05 and further.
> 
> Does this by any chance depend on the guest?! I mean, how is the guest

I doubt it.

> notified that a PCI device is gone (by unplug)? Maybe the pvops case
> just happens to work because the unplug happens early, perhaps before
> PCI discovery?!

ACPI hotplug. And it does work after PCI discovery.
> 
> Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 18:39:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18:39:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvsMC-0004go-6u; Tue, 02 Dec 2014 18:39: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 1XvsMB-0004gd-7F
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:39:27 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	30/44-22737-E570E745; Tue, 02 Dec 2014 18:39:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417545564!8259948!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15715 invoked from network); 2 Dec 2014 18:39:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2014 18:39: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 sB2IdLrd020936
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:39:22 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
	sB2IdKCN004615
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 18:39:21 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
	sB2IdKZa000972; Tue, 2 Dec 2014 18:39:20 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:39:20 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 98DFD11B072; Tue,  2 Dec 2014 13:39:20 -0500 (EST)
Date: Tue, 2 Dec 2014 13:39:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141202183920.GG32385@laptop.dumpdata.com>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
	<20141202154652.GA26732@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202154652.GA26732@aepfle.de>
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
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 04:46:52PM +0100, Olaf Hering wrote:
> On Mon, Dec 01, Konrad Rzeszutek Wilk wrote:
> 
> > That is odd - I see any device 'hot-plugged' being added at 00:05 and further.
> 
> Does this by any chance depend on the guest?! I mean, how is the guest

I doubt it.

> notified that a PCI device is gone (by unplug)? Maybe the pvops case
> just happens to work because the unplug happens early, perhaps before
> PCI discovery?!

ACPI hotplug. And it does work after PCI discovery.
> 
> Olaf

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 18:40:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvsNF-0004nv-7l; Tue, 02 Dec 2014 18:40: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 1XvsND-0004nj-2Q
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:40:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	10/C8-15461-E970E745; Tue, 02 Dec 2014 18:40:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417545628!12952750!1
X-Originating-IP: [156.151.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 2935 invoked from network); 2 Dec 2014 18:40:29 -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; 2 Dec 2014 18:40: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 sB2IeKma017409
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:40:21 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
	sB2IeK1H008267
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 18:40:20 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
	sB2IeJKs008735; Tue, 2 Dec 2014 18:40:19 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:40:19 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id C7DD611B074; Tue,  2 Dec 2014 13:40:19 -0500 (EST)
Date: Tue, 2 Dec 2014 13:40:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202184019.GH32385@laptop.dumpdata.com>
References: <1417430853-26347-1-git-send-email-euan.harris@citrix.com>
	<1417432541.29138.8.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417432541.29138.8.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@eu.citrix.com, Euan Harris <euan.harris@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: libxl_domain_info: fix typo in error
 message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 11:15:41AM +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 10:47 +0000, Euan Harris wrote:
> > Signed-off-by: Euan Harris <euan.harris@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> This is so trivial as to not need a release ack IMHO, I'll apply next

<nods>
> time I'm doing such things unless someone beats me to it...
> 
> > ---
> >  tools/libxl/libxl.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f84f7c2..c50c323 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -674,7 +674,7 @@ int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo *info_r,
> >  
> >      ret = xc_domain_getinfolist(ctx->xch, domid, 1, &xcinfo);
> >      if (ret<0) {
> > -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
> > +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
> >          return ERROR_FAIL;
> >      }
> >      if (ret==0 || xcinfo.domain != domid) return ERROR_INVAL;
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 18:40:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvsNF-0004nv-7l; Tue, 02 Dec 2014 18:40: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 1XvsND-0004nj-2Q
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:40:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	10/C8-15461-E970E745; Tue, 02 Dec 2014 18:40:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417545628!12952750!1
X-Originating-IP: [156.151.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 2935 invoked from network); 2 Dec 2014 18:40:29 -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; 2 Dec 2014 18:40: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 sB2IeKma017409
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:40:21 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
	sB2IeK1H008267
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 18:40:20 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
	sB2IeJKs008735; Tue, 2 Dec 2014 18:40:19 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:40:19 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id C7DD611B074; Tue,  2 Dec 2014 13:40:19 -0500 (EST)
Date: Tue, 2 Dec 2014 13:40:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202184019.GH32385@laptop.dumpdata.com>
References: <1417430853-26347-1-git-send-email-euan.harris@citrix.com>
	<1417432541.29138.8.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417432541.29138.8.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@eu.citrix.com, Euan Harris <euan.harris@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: libxl_domain_info: fix typo in error
 message
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 11:15:41AM +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 10:47 +0000, Euan Harris wrote:
> > Signed-off-by: Euan Harris <euan.harris@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> This is so trivial as to not need a release ack IMHO, I'll apply next

<nods>
> time I'm doing such things unless someone beats me to it...
> 
> > ---
> >  tools/libxl/libxl.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index f84f7c2..c50c323 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -674,7 +674,7 @@ int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo *info_r,
> >  
> >      ret = xc_domain_getinfolist(ctx->xch, domid, 1, &xcinfo);
> >      if (ret<0) {
> > -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
> > +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
> >          return ERROR_FAIL;
> >      }
> >      if (ret==0 || xcinfo.domain != domid) return ERROR_INVAL;
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 18:43:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvsPq-0005Ar-16; Tue, 02 Dec 2014 18:43:14 +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 1XvsPo-0005Af-4p
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:43:12 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	A4/10-05632-F380E745; Tue, 02 Dec 2014 18:43:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417545789!15217306!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27358 invoked from network); 2 Dec 2014 18:43:10 -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; 2 Dec 2014 18:43:10 -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 sB2Igj6g020806
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:42: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
	sB2IghWW013684
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 18:42:43 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
	sB2Igf63015374; Tue, 2 Dec 2014 18:42:42 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:42:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E3CBB11B07A; Tue,  2 Dec 2014 13:42:40 -0500 (EST)
Date: Tue, 2 Dec 2014 13:42:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, m.a.young@durham.ac.uk
Message-ID: <20141202184240.GI32385@laptop.dumpdata.com>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417535095.29004.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] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 03:44:55PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
> > Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
> > systemd xenstored dependencies") all service files use the .socket unit
> > as startup dependency. While this happens to work for boot it fails for
> > shutdown because a .socket does not seem to enforce ordering. When
> > xendomains.service runs during shutdown then systemd will stop
> > xenstored.service at the same time.
> > 
> > Change all "xenstored.socket" to "xenstored.service" to let systemd know
> > that xenstored has to be shutdown after everything else.
> > 
> > Reported-by: Mark Pryor <tlviewer@yahoo.com>
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > ---
> > 
> > This should go into 4.5 to fix xendomains.service.
> 
> CCing Konrad...

CC-ing Michael.

Michael, since Fedora is using systemd, did you observe this bug as well?
(I think I did, but I might have blamed it on my wacky setup).

> 
> > 
> >  tools/hotplug/Linux/systemd/xen-init-dom0.service.in              | 4 ++--
> >  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 4 ++--
> >  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 4 ++--
> >  tools/hotplug/Linux/systemd/xendomains.service.in                 | 4 ++--
> >  4 files changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> > index 4d4cb23..3befadc 100644
> > --- a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> > +++ b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> > @@ -1,7 +1,7 @@
> >  [Unit]
> >  Description=xen-init-dom0, initialise Dom0 configuration (xenstore nodes, JSON configuration stub)
> > -Requires=xenstored.socket proc-xen.mount
> > -After=xenstored.socket proc-xen.mount
> > +Requires=xenstored.service proc-xen.mount
> > +After=xenstored.service proc-xen.mount
> >  ConditionPathExists=/proc/xen/capabilities
> >  
> >  [Service]
> > 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 6b9c96e..0a5807a 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
> > @@ -1,7 +1,7 @@
> >  [Unit]
> >  Description=qemu for xen dom0 disk backend
> > -Requires=proc-xen.mount xenstored.socket
> > -After=proc-xen.mount xenstored.socket xenconsoled.service
> > +Requires=proc-xen.mount xenstored.service
> > +After=proc-xen.mount xenstored.service xenconsoled.service
> >  Before=xendomains.service libvirtd.service libvirt-guests.service
> >  RefuseManualStop=true
> >  ConditionPathExists=/proc/xen/capabilities
> > diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > index 2c5d99f..cb44cd6 100644
> > --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > @@ -1,7 +1,7 @@
> >  [Unit]
> >  Description=Xenconsoled - handles logging from guest consoles and hypervisor
> > -Requires=proc-xen.mount xenstored.socket
> > -After=proc-xen.mount xenstored.socket
> > +Requires=proc-xen.mount xenstored.service
> > +After=proc-xen.mount xenstored.service
> >  ConditionPathExists=/proc/xen/capabilities
> >  
> >  [Service]
> > diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
> > index 757278f..9962671 100644
> > --- a/tools/hotplug/Linux/systemd/xendomains.service.in
> > +++ b/tools/hotplug/Linux/systemd/xendomains.service.in
> > @@ -1,7 +1,7 @@
> >  [Unit]
> >  Description=Xendomains - start and stop guests on boot and shutdown
> > -Requires=proc-xen.mount xenstored.socket
> > -After=proc-xen.mount xenstored.socket xenconsoled.service xen-init-dom0.service
> > +Requires=proc-xen.mount xenstored.service
> > +After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
> >  ConditionPathExists=/proc/xen/capabilities
> >  
> >  [Service]
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Dec 02 18:43:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvsPq-0005Ar-16; Tue, 02 Dec 2014 18:43:14 +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 1XvsPo-0005Af-4p
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:43:12 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	A4/10-05632-F380E745; Tue, 02 Dec 2014 18:43:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417545789!15217306!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27358 invoked from network); 2 Dec 2014 18:43:10 -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; 2 Dec 2014 18:43:10 -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 sB2Igj6g020806
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:42: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
	sB2IghWW013684
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 18:42:43 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
	sB2Igf63015374; Tue, 2 Dec 2014 18:42:42 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:42:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E3CBB11B07A; Tue,  2 Dec 2014 13:42:40 -0500 (EST)
Date: Tue, 2 Dec 2014 13:42:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, m.a.young@durham.ac.uk
Message-ID: <20141202184240.GI32385@laptop.dumpdata.com>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417535095.29004.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] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 03:44:55PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
> > Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
> > systemd xenstored dependencies") all service files use the .socket unit
> > as startup dependency. While this happens to work for boot it fails for
> > shutdown because a .socket does not seem to enforce ordering. When
> > xendomains.service runs during shutdown then systemd will stop
> > xenstored.service at the same time.
> > 
> > Change all "xenstored.socket" to "xenstored.service" to let systemd know
> > that xenstored has to be shutdown after everything else.
> > 
> > Reported-by: Mark Pryor <tlviewer@yahoo.com>
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > ---
> > 
> > This should go into 4.5 to fix xendomains.service.
> 
> CCing Konrad...

CC-ing Michael.

Michael, since Fedora is using systemd, did you observe this bug as well?
(I think I did, but I might have blamed it on my wacky setup).

> 
> > 
> >  tools/hotplug/Linux/systemd/xen-init-dom0.service.in              | 4 ++--
> >  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 4 ++--
> >  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 4 ++--
> >  tools/hotplug/Linux/systemd/xendomains.service.in                 | 4 ++--
> >  4 files changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> > index 4d4cb23..3befadc 100644
> > --- a/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> > +++ b/tools/hotplug/Linux/systemd/xen-init-dom0.service.in
> > @@ -1,7 +1,7 @@
> >  [Unit]
> >  Description=xen-init-dom0, initialise Dom0 configuration (xenstore nodes, JSON configuration stub)
> > -Requires=xenstored.socket proc-xen.mount
> > -After=xenstored.socket proc-xen.mount
> > +Requires=xenstored.service proc-xen.mount
> > +After=xenstored.service proc-xen.mount
> >  ConditionPathExists=/proc/xen/capabilities
> >  
> >  [Service]
> > 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 6b9c96e..0a5807a 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
> > @@ -1,7 +1,7 @@
> >  [Unit]
> >  Description=qemu for xen dom0 disk backend
> > -Requires=proc-xen.mount xenstored.socket
> > -After=proc-xen.mount xenstored.socket xenconsoled.service
> > +Requires=proc-xen.mount xenstored.service
> > +After=proc-xen.mount xenstored.service xenconsoled.service
> >  Before=xendomains.service libvirtd.service libvirt-guests.service
> >  RefuseManualStop=true
> >  ConditionPathExists=/proc/xen/capabilities
> > diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > index 2c5d99f..cb44cd6 100644
> > --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> > @@ -1,7 +1,7 @@
> >  [Unit]
> >  Description=Xenconsoled - handles logging from guest consoles and hypervisor
> > -Requires=proc-xen.mount xenstored.socket
> > -After=proc-xen.mount xenstored.socket
> > +Requires=proc-xen.mount xenstored.service
> > +After=proc-xen.mount xenstored.service
> >  ConditionPathExists=/proc/xen/capabilities
> >  
> >  [Service]
> > diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
> > index 757278f..9962671 100644
> > --- a/tools/hotplug/Linux/systemd/xendomains.service.in
> > +++ b/tools/hotplug/Linux/systemd/xendomains.service.in
> > @@ -1,7 +1,7 @@
> >  [Unit]
> >  Description=Xendomains - start and stop guests on boot and shutdown
> > -Requires=proc-xen.mount xenstored.socket
> > -After=proc-xen.mount xenstored.socket xenconsoled.service xen-init-dom0.service
> > +Requires=proc-xen.mount xenstored.service
> > +After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
> >  ConditionPathExists=/proc/xen/capabilities
> >  
> >  [Service]
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Dec 02 18:43:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvsQD-0005Dx-EA; Tue, 02 Dec 2014 18:43:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvsQC-0005Do-PP
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:43:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E0/9C-09842-8580E745; Tue, 02 Dec 2014 18:43:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417545814!12914831!1
X-Originating-IP: [156.151.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 1251 invoked from network); 2 Dec 2014 18:43:35 -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; 2 Dec 2014 18:43: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 sB2IhSjd021789
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:43:29 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
	sB2IhRM1016414
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 18:43:27 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
	sB2IhQdX017859; Tue, 2 Dec 2014 18:43:26 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:43:26 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 93E4D11B07D; Tue,  2 Dec 2014 13:43:26 -0500 (EST)
Date: Tue, 2 Dec 2014 13:43:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141202184326.GJ32385@laptop.dumpdata.com>
References: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
	<20141202160444.GI5768@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202160444.GI5768@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andrew Jones <drjones@redhat.com>, 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,
	Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [Xen-devel] [PATCH] libxc: check in xc_get_tot_pages() that the
 proper domain is reported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 04:04:44PM +0000, Wei Liu wrote:
> On Tue, Dec 02, 2014 at 04:18:08PM +0100, Vitaly Kuznetsov wrote:
> > XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
> > strange interface: it reports first domain which has domid >= requested domid
> > so all callers are supposed to check that the proper domain(s) was queried
> > by checking domid. xc_get_tot_pages() doesn't do that. In case the requested
> > domain was destroyed it will report first domain with domid > requested domid
> > which is apparently misleading as there is no way xc_get_tot_pages() callers
> > can figure out that they got tot_pages for some other domain.
> > 
> > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> 
> Acked-by: Wei Liu <wei.liu2@citrix.com>

Lets add another Ack to this party..

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > ---
> >  tools/libxc/xc_private.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
> > index 1c214dd..e2441ad 100644
> > --- a/tools/libxc/xc_private.c
> > +++ b/tools/libxc/xc_private.c
> > @@ -613,8 +613,10 @@ int xc_get_pfn_list(xc_interface *xch,
> >  long xc_get_tot_pages(xc_interface *xch, uint32_t domid)
> >  {
> >      xc_dominfo_t info;
> > -    return (xc_domain_getinfo(xch, domid, 1, &info) != 1) ?
> > -        -1 : info.nr_pages;
> > +    if ( (xc_domain_getinfo(xch, domid, 1, &info) != 1) ||
> > +         (info.domid != domid) )
> > +        return -1;
> > +    return info.nr_pages;
> >  }
> >  
> >  int xc_copy_to_domain_page(xc_interface *xch,
> > -- 
> > 1.9.3
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 18:43:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvsQD-0005Dx-EA; Tue, 02 Dec 2014 18:43:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvsQC-0005Do-PP
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:43:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E0/9C-09842-8580E745; Tue, 02 Dec 2014 18:43:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417545814!12914831!1
X-Originating-IP: [156.151.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 1251 invoked from network); 2 Dec 2014 18:43:35 -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; 2 Dec 2014 18:43: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 sB2IhSjd021789
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:43:29 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
	sB2IhRM1016414
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 18:43:27 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
	sB2IhQdX017859; Tue, 2 Dec 2014 18:43:26 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:43:26 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 93E4D11B07D; Tue,  2 Dec 2014 13:43:26 -0500 (EST)
Date: Tue, 2 Dec 2014 13:43:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141202184326.GJ32385@laptop.dumpdata.com>
References: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
	<20141202160444.GI5768@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202160444.GI5768@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andrew Jones <drjones@redhat.com>, 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,
	Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [Xen-devel] [PATCH] libxc: check in xc_get_tot_pages() that the
 proper domain is reported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 04:04:44PM +0000, Wei Liu wrote:
> On Tue, Dec 02, 2014 at 04:18:08PM +0100, Vitaly Kuznetsov wrote:
> > XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
> > strange interface: it reports first domain which has domid >= requested domid
> > so all callers are supposed to check that the proper domain(s) was queried
> > by checking domid. xc_get_tot_pages() doesn't do that. In case the requested
> > domain was destroyed it will report first domain with domid > requested domid
> > which is apparently misleading as there is no way xc_get_tot_pages() callers
> > can figure out that they got tot_pages for some other domain.
> > 
> > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> 
> Acked-by: Wei Liu <wei.liu2@citrix.com>

Lets add another Ack to this party..

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > ---
> >  tools/libxc/xc_private.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
> > index 1c214dd..e2441ad 100644
> > --- a/tools/libxc/xc_private.c
> > +++ b/tools/libxc/xc_private.c
> > @@ -613,8 +613,10 @@ int xc_get_pfn_list(xc_interface *xch,
> >  long xc_get_tot_pages(xc_interface *xch, uint32_t domid)
> >  {
> >      xc_dominfo_t info;
> > -    return (xc_domain_getinfo(xch, domid, 1, &info) != 1) ?
> > -        -1 : info.nr_pages;
> > +    if ( (xc_domain_getinfo(xch, domid, 1, &info) != 1) ||
> > +         (info.domid != domid) )
> > +        return -1;
> > +    return info.nr_pages;
> >  }
> >  
> >  int xc_copy_to_domain_page(xc_interface *xch,
> > -- 
> > 1.9.3
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 18:47:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18:47:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvsUJ-0005SA-7R; Tue, 02 Dec 2014 18:47:51 +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 1XvsUI-0005S3-88
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:47:50 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BE/11-25276-5590E745; Tue, 02 Dec 2014 18:47:49 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417546067!12975353!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22016 invoked from network); 2 Dec 2014 18:47:48 -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;
	2 Dec 2014 18:47:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,502,1413244800"; d="scan'208";a="199020230"
Message-ID: <547E08A2.2030608@citrix.com>
Date: Tue, 2 Dec 2014 18:44: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: Wei Liu <wei.liu2@citrix.com>, <xen-devel@lists.xen.org>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<1417433473-17272-2-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417433473-17272-2-git-send-email-wei.liu2@citrix.com>
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 1/2] libxl: un-constify return
 value of libxl_basename
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 01/12/14 11:31, Wei Liu wrote:
> The string returned is malloc'ed but marked as "const".
>
> 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.h       |   10 ++++++++++
>  tools/libxl/libxl_utils.c |    5 ++++-
>  tools/libxl/libxl_utils.h |    6 +++++-
>  3 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 41d6e8d..291c190 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -478,6 +478,16 @@ typedef struct libxl__ctx libxl_ctx;
>  #endif
>  
>  /*
> + * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> + *
> + * The return value of libxl_basename is malloc'ed but the erroneously
> + * marked as "const" in releases before 4.5.
> + */
> +#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
> +#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
> +#endif

This define is currently useless.  Only newer code is capable of making
use of newly introduced LIBXL_HAVE_$FOO flags, and with its current
arrangement, this flag is only exposed to code requesting an older API
version.

This instead needs to be LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
which should be 1 for any API version >= 4.5

~Andrew


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 18:47:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18:47:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvsUJ-0005SA-7R; Tue, 02 Dec 2014 18:47:51 +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 1XvsUI-0005S3-88
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:47:50 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BE/11-25276-5590E745; Tue, 02 Dec 2014 18:47:49 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417546067!12975353!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22016 invoked from network); 2 Dec 2014 18:47:48 -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;
	2 Dec 2014 18:47:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,502,1413244800"; d="scan'208";a="199020230"
Message-ID: <547E08A2.2030608@citrix.com>
Date: Tue, 2 Dec 2014 18:44: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: Wei Liu <wei.liu2@citrix.com>, <xen-devel@lists.xen.org>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<1417433473-17272-2-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417433473-17272-2-git-send-email-wei.liu2@citrix.com>
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 1/2] libxl: un-constify return
 value of libxl_basename
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 01/12/14 11:31, Wei Liu wrote:
> The string returned is malloc'ed but marked as "const".
>
> 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.h       |   10 ++++++++++
>  tools/libxl/libxl_utils.c |    5 ++++-
>  tools/libxl/libxl_utils.h |    6 +++++-
>  3 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 41d6e8d..291c190 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -478,6 +478,16 @@ typedef struct libxl__ctx libxl_ctx;
>  #endif
>  
>  /*
> + * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> + *
> + * The return value of libxl_basename is malloc'ed but the erroneously
> + * marked as "const" in releases before 4.5.
> + */
> +#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
> +#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
> +#endif

This define is currently useless.  Only newer code is capable of making
use of newly introduced LIBXL_HAVE_$FOO flags, and with its current
arrangement, this flag is only exposed to code requesting an older API
version.

This instead needs to be LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
which should be 1 for any API version >= 4.5

~Andrew


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 18:48:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvsUa-0005Uq-7K; Tue, 02 Dec 2014 18:48: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 1XvsUZ-0005UU-0f
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:48:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	24/8E-15461-6690E745; Tue, 02 Dec 2014 18:48:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417546077!12975372!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22870 invoked from network); 2 Dec 2014 18:47:58 -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; 2 Dec 2014 18:47:58 -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 sB2IlqjT031724
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:47:53 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
	sB2Ilo2U003084
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 18:47:51 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
	sB2IloJq027461; Tue, 2 Dec 2014 18:47:50 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:47:50 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3259611B08D; Tue,  2 Dec 2014 13:47:49 -0500 (EST)
Date: Tue, 2 Dec 2014 13:47:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202184749.GC32622@laptop.dumpdata.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
	<1417174732.23604.13.camel@citrix.com>
	<20141201211456.GH22021@laptop.dumpdata.com>
	<1417528237.24320.34.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417528237.24320.34.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>, 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 Tue, Dec 02, 2014 at 01:50:37PM +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 16:14 -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 28, 2014 at 11:38:52AM +0000, Ian Campbell wrote:
> > > 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>
> > 
> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Did you intend to also ack patch #1? (or have I missed a mail?)

No. You two still were discussing it so I figured I will wait
until a repost.
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 18:48:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18: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 1XvsUa-0005Uq-7K; Tue, 02 Dec 2014 18:48: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 1XvsUZ-0005UU-0f
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:48:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	24/8E-15461-6690E745; Tue, 02 Dec 2014 18:48:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417546077!12975372!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22870 invoked from network); 2 Dec 2014 18:47:58 -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; 2 Dec 2014 18:47:58 -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 sB2IlqjT031724
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:47:53 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
	sB2Ilo2U003084
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 18:47:51 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
	sB2IloJq027461; Tue, 2 Dec 2014 18:47:50 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:47:50 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3259611B08D; Tue,  2 Dec 2014 13:47:49 -0500 (EST)
Date: Tue, 2 Dec 2014 13:47:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202184749.GC32622@laptop.dumpdata.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
	<1417174732.23604.13.camel@citrix.com>
	<20141201211456.GH22021@laptop.dumpdata.com>
	<1417528237.24320.34.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417528237.24320.34.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>, 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 Tue, Dec 02, 2014 at 01:50:37PM +0000, Ian Campbell wrote:
> On Mon, 2014-12-01 at 16:14 -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 28, 2014 at 11:38:52AM +0000, Ian Campbell wrote:
> > > 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>
> > 
> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Did you intend to also ack patch #1? (or have I missed a mail?)

No. You two still were discussing it so I figured I will wait
until a repost.
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 18:52:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvsYc-00061P-Tq; Tue, 02 Dec 2014 18:52:18 +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 1XvsYb-00061D-Px
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:52:17 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	82/C6-18267-16A0E745; Tue, 02 Dec 2014 18:52:17 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417546336!12905974!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 4111 invoked from network); 2 Dec 2014 18:52:16 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 18:52:16 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sB2Ipu0v007292;
	Tue, 2 Dec 2014 18:52:00 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 sB2Ipp8k017174
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 18:51:51 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sB2Ippip001832;
	Tue, 2 Dec 2014 18:51:51 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sB2Ipob2001828; Tue, 2 Dec 2014 18:51:51 GMT
Date: Tue, 2 Dec 2014 18:51:50 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141202184240.GI32385@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.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: sB2Ipu0v007292
Cc: Olaf Hering <olaf@aepfle.de>, 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.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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, 2 Dec 2014, Konrad Rzeszutek Wilk wrote:

> On Tue, Dec 02, 2014 at 03:44:55PM +0000, Ian Campbell wrote:
>> On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
>>> Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
>>> systemd xenstored dependencies") all service files use the .socket unit
>>> as startup dependency. While this happens to work for boot it fails for
>>> shutdown because a .socket does not seem to enforce ordering. When
>>> xendomains.service runs during shutdown then systemd will stop
>>> xenstored.service at the same time.
>>>
>>> Change all "xenstored.socket" to "xenstored.service" to let systemd know
>>> that xenstored has to be shutdown after everything else.
>>>
>>> Reported-by: Mark Pryor <tlviewer@yahoo.com>
>>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>
>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>
>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>> ---
>>>
>>> This should go into 4.5 to fix xendomains.service.
>>
>> CCing Konrad...
>
> CC-ing Michael.
>
> Michael, since Fedora is using systemd, did you observe this bug as well?
> (I think I did, but I might have blamed it on my wacky setup).

I only tried the xen systemd on xen 4.5-rc2 and didn't have a lot of 
success even when I reverted to Fedora's systemd for xen, so I can't 
really comment. I did have issues with xen systemd which I shall report if 
they are still there in -rc3.

 	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 Dec 02 18:52:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvsYc-00061P-Tq; Tue, 02 Dec 2014 18:52:18 +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 1XvsYb-00061D-Px
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 18:52:17 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	82/C6-18267-16A0E745; Tue, 02 Dec 2014 18:52:17 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417546336!12905974!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 4111 invoked from network); 2 Dec 2014 18:52:16 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 18:52:16 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id sB2Ipu0v007292;
	Tue, 2 Dec 2014 18:52:00 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 sB2Ipp8k017174
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 18:51:51 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id sB2Ippip001832;
	Tue, 2 Dec 2014 18:51:51 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sB2Ipob2001828; Tue, 2 Dec 2014 18:51:51 GMT
Date: Tue, 2 Dec 2014 18:51:50 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141202184240.GI32385@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.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: sB2Ipu0v007292
Cc: Olaf Hering <olaf@aepfle.de>, 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.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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, 2 Dec 2014, Konrad Rzeszutek Wilk wrote:

> On Tue, Dec 02, 2014 at 03:44:55PM +0000, Ian Campbell wrote:
>> On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
>>> Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
>>> systemd xenstored dependencies") all service files use the .socket unit
>>> as startup dependency. While this happens to work for boot it fails for
>>> shutdown because a .socket does not seem to enforce ordering. When
>>> xendomains.service runs during shutdown then systemd will stop
>>> xenstored.service at the same time.
>>>
>>> Change all "xenstored.socket" to "xenstored.service" to let systemd know
>>> that xenstored has to be shutdown after everything else.
>>>
>>> Reported-by: Mark Pryor <tlviewer@yahoo.com>
>>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>
>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>
>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>> ---
>>>
>>> This should go into 4.5 to fix xendomains.service.
>>
>> CCing Konrad...
>
> CC-ing Michael.
>
> Michael, since Fedora is using systemd, did you observe this bug as well?
> (I think I did, but I might have blamed it on my wacky setup).

I only tried the xen systemd on xen 4.5-rc2 and didn't have a lot of 
success even when I reverted to Fedora's systemd for xen, so I can't 
really comment. I did have issues with xen systemd which I shall report if 
they are still there in -rc3.

 	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 Dec 02 18:55:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18:55:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvsbJ-0006Ab-Jd; Tue, 02 Dec 2014 18:55: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 1XvsbI-0006AQ-4B
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 18:55:04 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	8A/BA-02696-70B0E745; Tue, 02 Dec 2014 18:55:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417546501!7901240!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19834 invoked from network); 2 Dec 2014 18:55:02 -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; 2 Dec 2014 18:55:02 -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 sB2Isnn5008275
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:54:50 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
	sB2IslRe024818
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 18:54:48 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
	sB2IslmD026557; Tue, 2 Dec 2014 18:54:47 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:54:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 13EE511B09D; Tue,  2 Dec 2014 13:54:47 -0500 (EST)
Date: Tue, 2 Dec 2014 13:54:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141202185446.GD32622@laptop.dumpdata.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
	<547C51AD.8070904@citrix.com> <547C64F3.9050005@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C64F3.9050005@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, andrew.cooper3@citrix.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 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 01:54:11PM +0100, Juergen Gross wrote:
> On 12/01/2014 12:31 PM, David Vrabel wrote:
> >On 28/11/14 10:53, 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.
> >
> >What are the results of the testing I asked for?
> 
> You asked for those replying to the patch introducing the linear
> mapping. So I added the description of the tested scenarios in the
> patch description of that patch.
> 
> >If Konrad or Boris are happy with this series I think it can go into 3.19.
> 
> Great, thanks!

I am happy.

> 
> 
> Juergen
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 18:55:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 18:55:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvsbJ-0006Ab-Jd; Tue, 02 Dec 2014 18:55: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 1XvsbI-0006AQ-4B
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 18:55:04 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	8A/BA-02696-70B0E745; Tue, 02 Dec 2014 18:55:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417546501!7901240!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19834 invoked from network); 2 Dec 2014 18:55:02 -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; 2 Dec 2014 18:55:02 -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 sB2Isnn5008275
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 18:54:50 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
	sB2IslRe024818
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 18:54:48 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
	sB2IslmD026557; Tue, 2 Dec 2014 18:54:47 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 10:54:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 13EE511B09D; Tue,  2 Dec 2014 13:54:47 -0500 (EST)
Date: Tue, 2 Dec 2014 13:54:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141202185446.GD32622@laptop.dumpdata.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
	<547C51AD.8070904@citrix.com> <547C64F3.9050005@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547C64F3.9050005@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, andrew.cooper3@citrix.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 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 01:54:11PM +0100, Juergen Gross wrote:
> On 12/01/2014 12:31 PM, David Vrabel wrote:
> >On 28/11/14 10:53, 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.
> >
> >What are the results of the testing I asked for?
> 
> You asked for those replying to the patch introducing the linear
> mapping. So I added the description of the tested scenarios in the
> patch description of that patch.
> 
> >If Konrad or Boris are happy with this series I think it can go into 3.19.
> 
> Great, thanks!

I am happy.

> 
> 
> Juergen
> 

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 19:12:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 19: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 1Xvsrt-0006mz-GC; Tue, 02 Dec 2014 19:12:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xvsrr-0006lv-UP
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 19:12:12 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	AC/1D-14727-B0F0E745; Tue, 02 Dec 2014 19:12:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417547529!11135000!1
X-Originating-IP: [156.151.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 2697 invoked from network); 2 Dec 2014 19:12:10 -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; 2 Dec 2014 19:12:10 -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 sB2JB4CQ026035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 19:11:05 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
	sB2JB099028652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 19:11:01 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
	sB2JAxk9019513; Tue, 2 Dec 2014 19:10:59 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 11:10:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id CE73F11B0C8; Tue,  2 Dec 2014 14:10:58 -0500 (EST)
Date: Tue, 2 Dec 2014 14:10:58 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Waiman Long <Waiman.Long@hp.com>
Message-ID: <20141202191058.GA357@laptop.dumpdata.com>
References: <1414613951-32532-1-git-send-email-Waiman.Long@hp.com>
	<1414613951-32532-11-git-send-email-Waiman.Long@hp.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1414613951-32532-11-git-send-email-Waiman.Long@hp.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
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 v13 10/11] pvqspinlock,
	x86: Enable PV qspinlock for KVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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:10PM -0400, Waiman Long wrote:
> This patch adds the necessary KVM specific code to allow KVM to
> support the CPU halting and kicking operations needed by the queue
> spinlock PV code.
> 
> Two KVM guests of 20 CPU cores (2 nodes) were created for performance
> testing in one of the following three configurations:
>  1) Only 1 VM is active
>  2) Both VMs are active and they share the same 20 physical CPUs
>     (200% overcommit)
> 
> The tests run included the disk workload of the AIM7 benchmark on
> both ext4 and xfs RAM disks at 3000 users on a 3.17 based kernel. The
> "ebizzy -m" test and futextest was was also run and its performance
> data were recorded.  With two VMs running, the "idle=poll" kernel
> option was added to simulate a busy guest. If PV qspinlock is not
> enabled, unfairlock will be used automically in a guest.

What is the unfairlock? Isn't it just using a bytelock at this point?

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 19:12:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 19: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 1Xvsrt-0006mz-GC; Tue, 02 Dec 2014 19:12:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xvsrr-0006lv-UP
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 19:12:12 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	AC/1D-14727-B0F0E745; Tue, 02 Dec 2014 19:12:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417547529!11135000!1
X-Originating-IP: [156.151.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 2697 invoked from network); 2 Dec 2014 19:12:10 -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; 2 Dec 2014 19:12:10 -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 sB2JB4CQ026035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 19:11:05 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
	sB2JB099028652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 19:11:01 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
	sB2JAxk9019513; Tue, 2 Dec 2014 19:10:59 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 11:10:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id CE73F11B0C8; Tue,  2 Dec 2014 14:10:58 -0500 (EST)
Date: Tue, 2 Dec 2014 14:10:58 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Waiman Long <Waiman.Long@hp.com>
Message-ID: <20141202191058.GA357@laptop.dumpdata.com>
References: <1414613951-32532-1-git-send-email-Waiman.Long@hp.com>
	<1414613951-32532-11-git-send-email-Waiman.Long@hp.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1414613951-32532-11-git-send-email-Waiman.Long@hp.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
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 v13 10/11] pvqspinlock,
	x86: Enable PV qspinlock for KVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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:10PM -0400, Waiman Long wrote:
> This patch adds the necessary KVM specific code to allow KVM to
> support the CPU halting and kicking operations needed by the queue
> spinlock PV code.
> 
> Two KVM guests of 20 CPU cores (2 nodes) were created for performance
> testing in one of the following three configurations:
>  1) Only 1 VM is active
>  2) Both VMs are active and they share the same 20 physical CPUs
>     (200% overcommit)
> 
> The tests run included the disk workload of the AIM7 benchmark on
> both ext4 and xfs RAM disks at 3000 users on a 3.17 based kernel. The
> "ebizzy -m" test and futextest was was also run and its performance
> data were recorded.  With two VMs running, the "idle=poll" kernel
> option was added to simulate a busy guest. If PV qspinlock is not
> enabled, unfairlock will be used automically in a guest.

What is the unfairlock? Isn't it just using a bytelock at this point?

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 19:18:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 19: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 1XvsxL-0006wD-Am; Tue, 02 Dec 2014 19:17:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvsxJ-0006w8-Ml
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 19:17:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BB/B8-09842-D501E745; Tue, 02 Dec 2014 19:17:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417547867!12958109!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16913 invoked from network); 2 Dec 2014 19:17:48 -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; 2 Dec 2014 19: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 sB2JHdaJ007910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 19:17:40 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
	sB2JHbS6011168
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 19:17:37 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
	sB2JHavK010208; Tue, 2 Dec 2014 19:17:36 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 11:17:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D5AE511B0D2; Tue,  2 Dec 2014 14:17:35 -0500 (EST)
Date: Tue, 2 Dec 2014 14:17:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202191735.GB357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 00/17] xen: RMRR fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> How to reproduce this issu:
> 
> * In shared-ept case with Xen.
> * Target owns RMRR.

How do you verify/check for that?


> * Do IGD passthrough with Windows guest OS: gfx_passthru=1 pci=["00:02.0"]
> * Please use qemu-xen-traditional.
> 
> My test machine is BDW with Windows 7.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 19:18:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 19: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 1XvsxL-0006wD-Am; Tue, 02 Dec 2014 19:17:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvsxJ-0006w8-Ml
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 19:17:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BB/B8-09842-D501E745; Tue, 02 Dec 2014 19:17:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417547867!12958109!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16913 invoked from network); 2 Dec 2014 19:17:48 -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; 2 Dec 2014 19: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 sB2JHdaJ007910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 19:17:40 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
	sB2JHbS6011168
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 19:17:37 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
	sB2JHavK010208; Tue, 2 Dec 2014 19:17:36 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 11:17:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D5AE511B0D2; Tue,  2 Dec 2014 14:17:35 -0500 (EST)
Date: Tue, 2 Dec 2014 14:17:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202191735.GB357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 00/17] xen: RMRR fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> How to reproduce this issu:
> 
> * In shared-ept case with Xen.
> * Target owns RMRR.

How do you verify/check for that?


> * Do IGD passthrough with Windows guest OS: gfx_passthru=1 pci=["00:02.0"]
> * Please use qemu-xen-traditional.
> 
> My test machine is BDW with Windows 7.

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 19:40:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 19: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 1XvtIo-0007Ok-Bi; Tue, 02 Dec 2014 19:40: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 1XvtIm-0007Ob-7U
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 19:40:00 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	8D/5A-26858-F851E745; Tue, 02 Dec 2014 19:39:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417549196!12912864!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8404 invoked from network); 2 Dec 2014 19:39:58 -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; 2 Dec 2014 19:39: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 sB2Jdk2Q030766
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 19:39: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
	sB2JdieF013605
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 19:39:45 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
	sB2Jdi7O006269; Tue, 2 Dec 2014 19:39:44 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 11:39:44 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 11E3E11B0FA; Tue,  2 Dec 2014 14:39:43 -0500 (EST)
Date: Tue, 2 Dec 2014 14:39:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202193943.GC357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 05:24:20PM +0800, Tiejun Chen wrote:
> This should be based on a new parameter globally, 'pci_rdmforce'.
> 
> 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 this domctl provides an approach to control how to populate
> reserved device memory by tools.
> 
> Note we always post a message to user about this once we owns
> RMRR.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  docs/man/xl.cfg.pod.5              |  6 +++++
>  docs/misc/vtd.txt                  | 15 ++++++++++++
>  tools/libxc/include/xenctrl.h      |  6 +++++
>  tools/libxc/xc_domain.c            | 28 +++++++++++++++++++++++
>  tools/libxl/libxl_create.c         |  3 +++
>  tools/libxl/libxl_dm.c             | 47 ++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h       |  4 ++++
>  tools/libxl/libxl_types.idl        |  2 ++
>  tools/libxl/libxlu_pci.c           |  2 ++
>  tools/libxl/xl_cmdimpl.c           | 10 ++++++++

In the past we had split the hypervisor and the
toolstack patches in two. So that one could focus
on the hypervisor ones first, and then in another
patch on the toolstack.

But perhaps this was intended to be in one patch?

>  xen/drivers/passthrough/pci.c      | 39 +++++++++++++++++++++++++++++++
>  xen/drivers/passthrough/vtd/dmar.c |  8 +++++++
>  xen/include/asm-x86/hvm/domain.h   |  4 ++++

I don't see ARM here? Should there be an ARM variant of this? If not
should the toolstack ones only run under x86?

>  xen/include/public/domctl.h        | 21 +++++++++++++++++
>  xen/xsm/flask/hooks.c              |  1 +
>  15 files changed, 196 insertions(+)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 622ea53..9adc41e 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -645,6 +645,12 @@ dom0 without confirmation.  Please use with care.
>  D0-D3hot power management states for the PCI device. False (0) by
>  default.
>  
> +=item B<rdmforce=BOOLEAN>
> +
> +(HVM/x86 only) Specifies that the VM would force to check and try to

s/force/forced/
> +reserve all reserved device memory, like RMRR, associated to the PCI
> +device. False (0) by default.

Not sure I understand. How would the VM be forced to do this? Or is
it that the hvmloader would force to do this? And if it fails (as you
say 'try') ? What then? 

> +
>  =back
>  
>  =back
> diff --git a/docs/misc/vtd.txt b/docs/misc/vtd.txt
> index 9af0e99..23544d5 100644
> --- a/docs/misc/vtd.txt
> +++ b/docs/misc/vtd.txt
> @@ -111,6 +111,21 @@ in the config file:
>  To override for a specific device:
>  	pci = [ '01:00.0,msitranslate=0', '03:00.0' ]
>  
> +RDM, 'reserved device memory', for PCI Device Passthrough
> +---------------------------------------------------------
> +
> +The BIOS controls some devices in terms of some reginos of memory used for

Could you elaborate what 'some devices' are? Network cards? GPUs? What
are the most commons ones.

s/reginos/regions/

And by regions you mean BAR regions?

> +these devices. This kind of region should be reserved before creating a VM
> +to make sure they are not occupied by RAM/MMIO to conflict, and also we can

You said 'This' but here you are using the plural ' are'. IF you want it plural
it needs to be 'These regions'
> +create necessary IOMMU table successfully.
> +
> +To enable this globally, add "pci_rdmforce" in the config file:
> +
> +	pci_rdmforce = 1         (default is 0)

The guest config file? Or /etc/xen/xl.conf ?

> +
> +Or just enable for a specific device:
> +	pci = [ '01:00.0,rdmforce=1', '03:00.0' ]
> +
>  
>  Caveat on Conventional PCI Device Passthrough
>  ---------------------------------------------
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 0ad8b8d..84012fe 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2038,6 +2038,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 b864872..7fd43e9 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -1633,6 +1633,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_t)domid;
> +    domctl.u.set_rdm.flags = 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/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 1198225..c615686 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -862,6 +862,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..e50587d 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -90,6 +90,53 @@ 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;
> +    uint32_t rdmforce = 0;
> +
> +    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].devfn = PCI_DEVFN(d_config->pcidevs[i].dev,
> +                                             d_config->pcidevs[i].func);
> +                pcidevs[i].bus = d_config->pcidevs[i].bus;
> +                pcidevs[i].seg = d_config->pcidevs[i].domain;
> +                pcidevs[i].flags = d_config->pcidevs[i].rdmforce &
> +                                   PCI_DEV_RDM_CHECK;
> +            }
> +        }
> +        else
> +        {
> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                               "Can't allocate for pcidevs.");
> +            return -1;
> +        }
> +    }
> +    rdmforce = libxl_defbool_val(d_config->b_info.rdmforce) ? 1 : 0;
> +
> +    /* Nothing to do. */
> +    if ( !rdmforce && !d_config->num_pcidevs )
> +        return 0;
> +
> +    ret = xc_domain_device_setrdm(ctx->xch, dm_domid,
> +                                  (uint32_t)d_config->num_pcidevs,
> +                                  rdmforce,
> +                                  pcidevs);
> +    if ( d_config->num_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 a38f695..be397a6 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1477,6 +1477,10 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
>          int nr_disks, libxl_device_disk *disks,
>          int nr_channels, libxl_device_channel *channels);
>  
> +_hidden int libxl__domain_device_setrdm(libxl__gc *gc,
> +                                        libxl_domain_config *info,
> +                                        uint32_t domid);
> +
>  /*
>   * This function will cause the whole libxl process to hang
>   * if the device model does not respond.  It is deprecated.
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index f7fc695..0076a32 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),
> +    ("rdmforce",         libxl_defbool),
>      ("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 0e754e7..9c23733 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -919,6 +919,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 +1700,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,6 +1723,7 @@ 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++;
>          }
> @@ -1726,6 +1731,11 @@ skip_vfb:
>              libxl_defbool_set(&b_info->u.pv.e820_host, true);
>      }
>  
> +    if ((c_info->type == LIBXL_DOMAIN_TYPE_HVM) && pci_rdmforce)
> +        libxl_defbool_set(&b_info->rdmforce, true);
> +    else
> +        libxl_defbool_set(&b_info->rdmforce, false);
> +
>      switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
>      case 0:
>          {
> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
> index 78c6977..ae924ad 100644
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -34,6 +34,7 @@
>  #include <xen/tasklet.h>
>  #include <xsm/xsm.h>
>  #include <asm/msi.h>
> +#include <xen/stdbool.h>
>  
>  struct pci_seg {
>      struct list_head alldevs_list;
> @@ -1553,6 +1554,44 @@ 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 = NULL;
> +        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
> +
> +        if ( d == NULL )
> +            return -ESRCH;
> +

What if this is called on an PV domain?

You are also missing the XSM checks.

What if this is called multiple times. Is it OK to over-ride
the 'pci_force' or should it stick once?


> +        d->arch.hvm_domain.pci_force =
> +                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;

Won't we crash here if this is called for PV guests?

> +        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;

What if the 'num_pcidevs' has some bogus value. You need to check for that.


> +        d->arch.hvm_domain.pcidevs = NULL;

Please first free it. It might be that the toolstack
is doing this a couple of times. You don't want to leak memory.


> +
> +        if ( xdsr->num_pcidevs )
> +        {
> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
> +                                    xdsr->num_pcidevs);
> +            if ( pcidevs == NULL )
> +            {
> +                rcu_unlock_domain(d);
> +                return -ENOMEM;

But you already have set 'num_pcidevs' to some value. This copying/check
should be done before you modify 'd->arch.hvm_domain'...
> +            }
> +
> +            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
> +                                 xdsr->num_pcidevs*sizeof(*pcidevs)) )
> +            {
> +                xfree(pcidevs);
> +                rcu_unlock_domain(d);

Ditto. You need to do these checks before you modify 'd->arch.hvm_domain'.

> +                return -EFAULT;
> +            }
> +        }
> +
> +        d->arch.hvm_domain.pcidevs = pcidevs;
> +        rcu_unlock_domain(d);
> +    }
> +        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 1152c3a..5e41e7a 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>                          "  RMRR region: base_addr %"PRIx64
>                          " end_address %"PRIx64"\n",
>                          rmrru->base_address, rmrru->end_address);
> +            /*
> +             * TODO: we may provide a precise paramter just to reserve

s/paramter/parameter/
> +             * RMRR range specific to one device.
> +             */
> +            dprintk(XENLOG_WARNING VTDPREFIX,
> +                    "So please set pci_rdmforce to reserve these ranges"
> +                    " if you need such a device in hotplug case.\n");

'Please set rdmforce to reserve ranges %lx->%lx if you plan to hotplug this device.'

But then this is going to be a bit verbose, so perhaps:

'Ranges %lx-%lx need rdmforce to properly work.' ?

> +
>              acpi_register_rmrr_unit(rmrru);
>          }
>      }
> diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
> index 2757c7f..38530e5 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;
>  

Maybe a comment explaining its purpose?

> +    bool_t                  pci_force;
> +    uint32_t                num_pcidevs;
> +    struct xen_guest_pcidev_info      *pcidevs;
> +

You are also missing freeing of this in the hypervisor when the guest
is destroyed. Please fix that.

>      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 57e2ed7..ba8970d 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -508,6 +508,25 @@ struct xen_domctl_get_device_group {
>  typedef struct xen_domctl_get_device_group xen_domctl_get_device_group_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_get_device_group_t);
>  
> +/* Currently just one bit to indicate force to check Reserved Device Memory. */

Not sure I understand. Did you mean:

'Check Reserved Device Memory'.

What happens if you do not have this flag? What are the semantics 
of this hypercall - as in what will it mean.

> +#define PCI_DEV_RDM_CHECK   0x1
> +struct xen_guest_pcidev_info {
> +    uint16_t    seg;
> +    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;

What is this 'flags' purpose compared to the 'pcidevs.flags'? Please
explain.

> +    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);
> +
>  /* Pass-through interrupts: bind real irq -> hvm devfn. */
>  /* XEN_DOMCTL_bind_pt_irq */
>  /* XEN_DOMCTL_unbind_pt_irq */
> @@ -1070,6 +1089,7 @@ struct xen_domctl {
>  #define XEN_DOMCTL_setvnumainfo                  74
>  #define XEN_DOMCTL_psr_cmt_op                    75
>  #define XEN_DOMCTL_arm_configure_domain          76
> +#define XEN_DOMCTL_set_rdm                       77
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -1135,6 +1155,7 @@ struct xen_domctl {
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>          struct xen_domctl_vnuma             vnuma;
>          struct xen_domctl_psr_cmt_op        psr_cmt_op;
> +        struct xen_domctl_set_rdm           set_rdm;
>          uint8_t                             pad[128];
>      } u;
>  };
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index d48463f..5a760e2 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -592,6 +592,7 @@ static int flask_domctl(struct domain *d, int cmd)
>      case XEN_DOMCTL_test_assign_device:
>      case XEN_DOMCTL_assign_device:
>      case XEN_DOMCTL_deassign_device:
> +    case XEN_DOMCTL_set_rdm:

There is more to XSM than just this file..

Please compile with XSM enabled.
>  #endif
>          return 0;


Also how does this work with 32-bit dom0s? Is there a need to use the
compat layer?

>  
> -- 
> 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 Dec 02 19:40:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 19: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 1XvtIo-0007Ok-Bi; Tue, 02 Dec 2014 19:40: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 1XvtIm-0007Ob-7U
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 19:40:00 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	8D/5A-26858-F851E745; Tue, 02 Dec 2014 19:39:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417549196!12912864!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8404 invoked from network); 2 Dec 2014 19:39:58 -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; 2 Dec 2014 19:39: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 sB2Jdk2Q030766
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 19:39: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
	sB2JdieF013605
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 19:39:45 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
	sB2Jdi7O006269; Tue, 2 Dec 2014 19:39:44 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 11:39:44 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 11E3E11B0FA; Tue,  2 Dec 2014 14:39:43 -0500 (EST)
Date: Tue, 2 Dec 2014 14:39:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202193943.GC357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 05:24:20PM +0800, Tiejun Chen wrote:
> This should be based on a new parameter globally, 'pci_rdmforce'.
> 
> 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 this domctl provides an approach to control how to populate
> reserved device memory by tools.
> 
> Note we always post a message to user about this once we owns
> RMRR.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  docs/man/xl.cfg.pod.5              |  6 +++++
>  docs/misc/vtd.txt                  | 15 ++++++++++++
>  tools/libxc/include/xenctrl.h      |  6 +++++
>  tools/libxc/xc_domain.c            | 28 +++++++++++++++++++++++
>  tools/libxl/libxl_create.c         |  3 +++
>  tools/libxl/libxl_dm.c             | 47 ++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h       |  4 ++++
>  tools/libxl/libxl_types.idl        |  2 ++
>  tools/libxl/libxlu_pci.c           |  2 ++
>  tools/libxl/xl_cmdimpl.c           | 10 ++++++++

In the past we had split the hypervisor and the
toolstack patches in two. So that one could focus
on the hypervisor ones first, and then in another
patch on the toolstack.

But perhaps this was intended to be in one patch?

>  xen/drivers/passthrough/pci.c      | 39 +++++++++++++++++++++++++++++++
>  xen/drivers/passthrough/vtd/dmar.c |  8 +++++++
>  xen/include/asm-x86/hvm/domain.h   |  4 ++++

I don't see ARM here? Should there be an ARM variant of this? If not
should the toolstack ones only run under x86?

>  xen/include/public/domctl.h        | 21 +++++++++++++++++
>  xen/xsm/flask/hooks.c              |  1 +
>  15 files changed, 196 insertions(+)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 622ea53..9adc41e 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -645,6 +645,12 @@ dom0 without confirmation.  Please use with care.
>  D0-D3hot power management states for the PCI device. False (0) by
>  default.
>  
> +=item B<rdmforce=BOOLEAN>
> +
> +(HVM/x86 only) Specifies that the VM would force to check and try to

s/force/forced/
> +reserve all reserved device memory, like RMRR, associated to the PCI
> +device. False (0) by default.

Not sure I understand. How would the VM be forced to do this? Or is
it that the hvmloader would force to do this? And if it fails (as you
say 'try') ? What then? 

> +
>  =back
>  
>  =back
> diff --git a/docs/misc/vtd.txt b/docs/misc/vtd.txt
> index 9af0e99..23544d5 100644
> --- a/docs/misc/vtd.txt
> +++ b/docs/misc/vtd.txt
> @@ -111,6 +111,21 @@ in the config file:
>  To override for a specific device:
>  	pci = [ '01:00.0,msitranslate=0', '03:00.0' ]
>  
> +RDM, 'reserved device memory', for PCI Device Passthrough
> +---------------------------------------------------------
> +
> +The BIOS controls some devices in terms of some reginos of memory used for

Could you elaborate what 'some devices' are? Network cards? GPUs? What
are the most commons ones.

s/reginos/regions/

And by regions you mean BAR regions?

> +these devices. This kind of region should be reserved before creating a VM
> +to make sure they are not occupied by RAM/MMIO to conflict, and also we can

You said 'This' but here you are using the plural ' are'. IF you want it plural
it needs to be 'These regions'
> +create necessary IOMMU table successfully.
> +
> +To enable this globally, add "pci_rdmforce" in the config file:
> +
> +	pci_rdmforce = 1         (default is 0)

The guest config file? Or /etc/xen/xl.conf ?

> +
> +Or just enable for a specific device:
> +	pci = [ '01:00.0,rdmforce=1', '03:00.0' ]
> +
>  
>  Caveat on Conventional PCI Device Passthrough
>  ---------------------------------------------
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 0ad8b8d..84012fe 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2038,6 +2038,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 b864872..7fd43e9 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -1633,6 +1633,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_t)domid;
> +    domctl.u.set_rdm.flags = 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/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 1198225..c615686 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -862,6 +862,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..e50587d 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -90,6 +90,53 @@ 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;
> +    uint32_t rdmforce = 0;
> +
> +    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].devfn = PCI_DEVFN(d_config->pcidevs[i].dev,
> +                                             d_config->pcidevs[i].func);
> +                pcidevs[i].bus = d_config->pcidevs[i].bus;
> +                pcidevs[i].seg = d_config->pcidevs[i].domain;
> +                pcidevs[i].flags = d_config->pcidevs[i].rdmforce &
> +                                   PCI_DEV_RDM_CHECK;
> +            }
> +        }
> +        else
> +        {
> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                               "Can't allocate for pcidevs.");
> +            return -1;
> +        }
> +    }
> +    rdmforce = libxl_defbool_val(d_config->b_info.rdmforce) ? 1 : 0;
> +
> +    /* Nothing to do. */
> +    if ( !rdmforce && !d_config->num_pcidevs )
> +        return 0;
> +
> +    ret = xc_domain_device_setrdm(ctx->xch, dm_domid,
> +                                  (uint32_t)d_config->num_pcidevs,
> +                                  rdmforce,
> +                                  pcidevs);
> +    if ( d_config->num_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 a38f695..be397a6 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1477,6 +1477,10 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
>          int nr_disks, libxl_device_disk *disks,
>          int nr_channels, libxl_device_channel *channels);
>  
> +_hidden int libxl__domain_device_setrdm(libxl__gc *gc,
> +                                        libxl_domain_config *info,
> +                                        uint32_t domid);
> +
>  /*
>   * This function will cause the whole libxl process to hang
>   * if the device model does not respond.  It is deprecated.
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index f7fc695..0076a32 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),
> +    ("rdmforce",         libxl_defbool),
>      ("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 0e754e7..9c23733 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -919,6 +919,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 +1700,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,6 +1723,7 @@ 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++;
>          }
> @@ -1726,6 +1731,11 @@ skip_vfb:
>              libxl_defbool_set(&b_info->u.pv.e820_host, true);
>      }
>  
> +    if ((c_info->type == LIBXL_DOMAIN_TYPE_HVM) && pci_rdmforce)
> +        libxl_defbool_set(&b_info->rdmforce, true);
> +    else
> +        libxl_defbool_set(&b_info->rdmforce, false);
> +
>      switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
>      case 0:
>          {
> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
> index 78c6977..ae924ad 100644
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -34,6 +34,7 @@
>  #include <xen/tasklet.h>
>  #include <xsm/xsm.h>
>  #include <asm/msi.h>
> +#include <xen/stdbool.h>
>  
>  struct pci_seg {
>      struct list_head alldevs_list;
> @@ -1553,6 +1554,44 @@ 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 = NULL;
> +        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
> +
> +        if ( d == NULL )
> +            return -ESRCH;
> +

What if this is called on an PV domain?

You are also missing the XSM checks.

What if this is called multiple times. Is it OK to over-ride
the 'pci_force' or should it stick once?


> +        d->arch.hvm_domain.pci_force =
> +                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;

Won't we crash here if this is called for PV guests?

> +        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;

What if the 'num_pcidevs' has some bogus value. You need to check for that.


> +        d->arch.hvm_domain.pcidevs = NULL;

Please first free it. It might be that the toolstack
is doing this a couple of times. You don't want to leak memory.


> +
> +        if ( xdsr->num_pcidevs )
> +        {
> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
> +                                    xdsr->num_pcidevs);
> +            if ( pcidevs == NULL )
> +            {
> +                rcu_unlock_domain(d);
> +                return -ENOMEM;

But you already have set 'num_pcidevs' to some value. This copying/check
should be done before you modify 'd->arch.hvm_domain'...
> +            }
> +
> +            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
> +                                 xdsr->num_pcidevs*sizeof(*pcidevs)) )
> +            {
> +                xfree(pcidevs);
> +                rcu_unlock_domain(d);

Ditto. You need to do these checks before you modify 'd->arch.hvm_domain'.

> +                return -EFAULT;
> +            }
> +        }
> +
> +        d->arch.hvm_domain.pcidevs = pcidevs;
> +        rcu_unlock_domain(d);
> +    }
> +        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 1152c3a..5e41e7a 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>                          "  RMRR region: base_addr %"PRIx64
>                          " end_address %"PRIx64"\n",
>                          rmrru->base_address, rmrru->end_address);
> +            /*
> +             * TODO: we may provide a precise paramter just to reserve

s/paramter/parameter/
> +             * RMRR range specific to one device.
> +             */
> +            dprintk(XENLOG_WARNING VTDPREFIX,
> +                    "So please set pci_rdmforce to reserve these ranges"
> +                    " if you need such a device in hotplug case.\n");

'Please set rdmforce to reserve ranges %lx->%lx if you plan to hotplug this device.'

But then this is going to be a bit verbose, so perhaps:

'Ranges %lx-%lx need rdmforce to properly work.' ?

> +
>              acpi_register_rmrr_unit(rmrru);
>          }
>      }
> diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
> index 2757c7f..38530e5 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;
>  

Maybe a comment explaining its purpose?

> +    bool_t                  pci_force;
> +    uint32_t                num_pcidevs;
> +    struct xen_guest_pcidev_info      *pcidevs;
> +

You are also missing freeing of this in the hypervisor when the guest
is destroyed. Please fix that.

>      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 57e2ed7..ba8970d 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -508,6 +508,25 @@ struct xen_domctl_get_device_group {
>  typedef struct xen_domctl_get_device_group xen_domctl_get_device_group_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_get_device_group_t);
>  
> +/* Currently just one bit to indicate force to check Reserved Device Memory. */

Not sure I understand. Did you mean:

'Check Reserved Device Memory'.

What happens if you do not have this flag? What are the semantics 
of this hypercall - as in what will it mean.

> +#define PCI_DEV_RDM_CHECK   0x1
> +struct xen_guest_pcidev_info {
> +    uint16_t    seg;
> +    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;

What is this 'flags' purpose compared to the 'pcidevs.flags'? Please
explain.

> +    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);
> +
>  /* Pass-through interrupts: bind real irq -> hvm devfn. */
>  /* XEN_DOMCTL_bind_pt_irq */
>  /* XEN_DOMCTL_unbind_pt_irq */
> @@ -1070,6 +1089,7 @@ struct xen_domctl {
>  #define XEN_DOMCTL_setvnumainfo                  74
>  #define XEN_DOMCTL_psr_cmt_op                    75
>  #define XEN_DOMCTL_arm_configure_domain          76
> +#define XEN_DOMCTL_set_rdm                       77
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -1135,6 +1155,7 @@ struct xen_domctl {
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>          struct xen_domctl_vnuma             vnuma;
>          struct xen_domctl_psr_cmt_op        psr_cmt_op;
> +        struct xen_domctl_set_rdm           set_rdm;
>          uint8_t                             pad[128];
>      } u;
>  };
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index d48463f..5a760e2 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -592,6 +592,7 @@ static int flask_domctl(struct domain *d, int cmd)
>      case XEN_DOMCTL_test_assign_device:
>      case XEN_DOMCTL_assign_device:
>      case XEN_DOMCTL_deassign_device:
> +    case XEN_DOMCTL_set_rdm:

There is more to XSM than just this file..

Please compile with XSM enabled.
>  #endif
>          return 0;


Also how does this work with 32-bit dom0s? Is there a need to use the
compat layer?

>  
> -- 
> 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 Dec 02 19:47:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 19:47:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvtPy-0007iB-EO; Tue, 02 Dec 2014 19:47:26 +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 1XvtPx-0007i6-6K
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 19:47:25 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	0E/4E-17958-C471E745; Tue, 02 Dec 2014 19:47:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417549642!12913781!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8177 invoked from network); 2 Dec 2014 19:47:23 -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; 2 Dec 2014 19:47: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 sB2JlB8O007522
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 19:47:12 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
	sB2JlA7S008182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 19:47:10 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
	sB2JlAAx008173; Tue, 2 Dec 2014 19:47:10 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 11:47:10 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D6B8911B102; Tue,  2 Dec 2014 14:47:09 -0500 (EST)
Date: Tue, 2 Dec 2014 14:47:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202194709.GD357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 03/17] introduce
	XENMEM_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 05:24:21PM +0800, Tiejun Chen wrote:
> From: Jan Beulich <jbeulich@suse.com>
> 
> This is a prerequisite for punching holes into HVM and PVH guests' P2M
> to allow passing through devices that are associated with (on VT-d)
> RMRRs.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Acked-by: Kevin Tian <kevin.tian@intel.com>
> ---
>  xen/common/compat/memory.c           | 54 ++++++++++++++++++++++++++++++++++++
>  xen/common/memory.c                  | 51 ++++++++++++++++++++++++++++++++++
>  xen/drivers/passthrough/iommu.c      | 10 +++++++
>  xen/drivers/passthrough/vtd/dmar.c   | 17 ++++++++++++
>  xen/drivers/passthrough/vtd/extern.h |  1 +
>  xen/drivers/passthrough/vtd/iommu.c  |  1 +
>  xen/include/public/memory.h          | 24 +++++++++++++++-
>  xen/include/xen/iommu.h              |  4 +++
>  xen/include/xlat.lst                 |  3 +-
>  9 files changed, 163 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
> index 06c90be..60512fa 100644
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -16,6 +16,37 @@ CHECK_TYPE(domid);
>  
>  CHECK_mem_access_op;
>  
> +#ifdef HAS_PASSTHROUGH
> +struct get_reserved_device_memory {
> +    struct compat_reserved_device_memory_map map;
> +    unsigned int used_entries;
> +};
> +
> +static int get_reserved_device_memory(xen_pfn_t start,
> +                                      xen_ulong_t nr, void *ctxt)
> +{
> +    struct get_reserved_device_memory *grdm = ctxt;
> +
> +    if ( grdm->used_entries < grdm->map.nr_entries )
> +    {
> +        struct compat_reserved_device_memory rdm = {
> +            .start_pfn = start, .nr_pages = nr
> +        };
> +
> +        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;
> +    }
> +
> +    ++grdm->used_entries;
> +
> +    return 0;
> +}
> +#endif
> +
>  int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>  {
>      int split, op = cmd & MEMOP_CMD_MASK;
> @@ -273,6 +304,29 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>              break;
>          }
>  
> +#ifdef HAS_PASSTHROUGH
> +        case XENMEM_reserved_device_memory_map:
> +        {
> +            struct get_reserved_device_memory grdm;
> +
> +            if ( copy_from_guest(&grdm.map, compat, 1) ||
> +                 !compat_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
> +                return -EFAULT;
> +
> +            grdm.used_entries = 0;
> +            rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
> +                                                  &grdm);
> +
> +            if ( !rc && grdm.map.nr_entries < grdm.used_entries )
> +                rc = -ENOBUFS;
> +            grdm.map.nr_entries = grdm.used_entries;
> +            if ( __copy_to_guest(compat, &grdm.map, 1) )
> +                rc = -EFAULT;
> +
> +            return rc;
> +        }
> +#endif
> +
>          default:
>              return compat_arch_memory_op(cmd, compat);
>          }
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 9f21bd3..4788acc 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -692,6 +692,34 @@ out:
>      return rc;
>  }
>  
> +#ifdef HAS_PASSTHROUGH
> +struct get_reserved_device_memory {
> +    struct xen_reserved_device_memory_map map;
> +    unsigned int used_entries;
> +};
> +
> +static int get_reserved_device_memory(xen_pfn_t start,
> +                                      xen_ulong_t nr, void *ctxt)
> +{
> +    struct get_reserved_device_memory *grdm = ctxt;
> +
> +    if ( grdm->used_entries < grdm->map.nr_entries )
> +    {
> +        struct xen_reserved_device_memory rdm = {
> +            .start_pfn = start, .nr_pages = nr
> +        };
> +
> +        if ( __copy_to_guest_offset(grdm->map.buffer, grdm->used_entries,
> +                                    &rdm, 1) )
> +            return -EFAULT;
> +    }
> +
> +    ++grdm->used_entries;
> +
> +    return 0;
> +}
> +#endif
> +
>  long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      struct domain *d;
> @@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          break;
>      }
>  
> +#ifdef HAS_PASSTHROUGH
> +    case XENMEM_reserved_device_memory_map:
> +    {
> +        struct get_reserved_device_memory grdm;
> +
> +        if ( copy_from_guest(&grdm.map, arg, 1) ||
> +             !guest_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
> +            return -EFAULT;
> +

Shouldn't there be an XSM check here?

> +        grdm.used_entries = 0;
> +        rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
> +                                              &grdm);
> +

Also since we doing an iteration over possible many nr_entries should
we think about returning -EAGAIN to user-space so that it can retry?
(As in, have preemption baked in this hypercall)

> +        if ( !rc && grdm.map.nr_entries < grdm.used_entries )
> +            rc = -ENOBUFS;
> +        grdm.map.nr_entries = grdm.used_entries;
> +        if ( __copy_to_guest(arg, &grdm.map, 1) )
> +            rc = -EFAULT;
> +
> +        break;
> +    }
> +#endif
> +
>      default:
>          rc = arch_memory_op(cmd, arg);
>          break;
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
> index cc12735..7c17e8d 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -344,6 +344,16 @@ void iommu_crash_shutdown(void)
>      iommu_enabled = iommu_intremap = 0;
>  }
>  
> +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);
> +}
> +
>  bool_t iommu_has_feature(struct domain *d, enum iommu_feature feature)
>  {
>      const struct hvm_iommu *hd = domain_hvm_iommu(d);
> diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
> index 5e41e7a..86cfad3 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -901,3 +901,20 @@ int platform_supports_x2apic(void)
>      unsigned int mask = ACPI_DMAR_INTR_REMAP | ACPI_DMAR_X2APIC_OPT_OUT;
>      return cpu_has_x2apic && ((dmar_flags & mask) == ACPI_DMAR_INTR_REMAP);
>  }
> +
> +int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
> +{
> +    struct acpi_rmrr_unit *rmrr;
> +    int rc = 0;
> +
> +    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;
> +    }
> +
> +    return rc;
> +}
> diff --git a/xen/drivers/passthrough/vtd/extern.h b/xen/drivers/passthrough/vtd/extern.h
> index 5524dba..f9ee9b0 100644
> --- a/xen/drivers/passthrough/vtd/extern.h
> +++ b/xen/drivers/passthrough/vtd/extern.h
> @@ -75,6 +75,7 @@ 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);
>  
>  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/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
> index 19d8165..a38f201 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2491,6 +2491,7 @@ const struct iommu_ops intel_iommu_ops = {
>      .crash_shutdown = vtd_crash_shutdown,
>      .iotlb_flush = intel_iommu_iotlb_flush,
>      .iotlb_flush_all = intel_iommu_iotlb_flush_all,
> +    .get_reserved_device_memory = intel_iommu_get_reserved_device_memory,
>      .dump_p2m_table = vtd_dump_p2m_table,
>  };
>  
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index 595f953..cee4535 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -572,7 +572,29 @@ struct xen_vnuma_topology_info {
>  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 */
> +/*
> + * For legacy reasons, some devices must be configured with special memory
> + * regions to function correctly.  The guest must avoid using any of these
> + * regions.
> + */
> +#define XENMEM_reserved_device_memory_map   27
> +struct xen_reserved_device_memory {
> +    xen_pfn_t start_pfn;
> +    xen_ulong_t nr_pages;
> +};
> +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 {
> +    /* IN/OUT */
> +    unsigned int nr_entries;
> +    /* OUT */
> +    XEN_GUEST_HANDLE(xen_reserved_device_memory_t) buffer;
> +};
> +typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t);
> +
> +/* Next available subop number is 28 */
>  
>  #endif /* __XEN_PUBLIC_MEMORY_H__ */
>  
> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
> index 8eb764a..409f6f8 100644
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -120,6 +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);
> +
>  struct iommu_ops {
>      int (*init)(struct domain *d);
>      void (*hwdom_init)(struct domain *d);
> @@ -156,12 +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 *);
>      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 *);
>  
>  void iommu_share_p2m_table(struct domain *d);
>  
> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
> index 41b3e35..42229fd 100644
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -61,9 +61,10 @@
>  !	memory_exchange			memory.h
>  !	memory_map			memory.h
>  !	memory_reservation		memory.h
> -?	mem_access_op		memory.h
> +?	mem_access_op			memory.h
>  !	pod_target			memory.h
>  !	remove_from_physmap		memory.h
> +!	reserved_device_memory_map	memory.h
>  ?	physdev_eoi			physdev.h
>  ?	physdev_get_free_pirq		physdev.h
>  ?	physdev_irq			physdev.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 Dec 02 19:47:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 19:47:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvtPy-0007iB-EO; Tue, 02 Dec 2014 19:47:26 +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 1XvtPx-0007i6-6K
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 19:47:25 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	0E/4E-17958-C471E745; Tue, 02 Dec 2014 19:47:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417549642!12913781!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8177 invoked from network); 2 Dec 2014 19:47:23 -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; 2 Dec 2014 19:47: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 sB2JlB8O007522
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 19:47:12 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
	sB2JlA7S008182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 19:47:10 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
	sB2JlAAx008173; Tue, 2 Dec 2014 19:47:10 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 11:47:10 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D6B8911B102; Tue,  2 Dec 2014 14:47:09 -0500 (EST)
Date: Tue, 2 Dec 2014 14:47:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202194709.GD357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 03/17] introduce
	XENMEM_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 05:24:21PM +0800, Tiejun Chen wrote:
> From: Jan Beulich <jbeulich@suse.com>
> 
> This is a prerequisite for punching holes into HVM and PVH guests' P2M
> to allow passing through devices that are associated with (on VT-d)
> RMRRs.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Acked-by: Kevin Tian <kevin.tian@intel.com>
> ---
>  xen/common/compat/memory.c           | 54 ++++++++++++++++++++++++++++++++++++
>  xen/common/memory.c                  | 51 ++++++++++++++++++++++++++++++++++
>  xen/drivers/passthrough/iommu.c      | 10 +++++++
>  xen/drivers/passthrough/vtd/dmar.c   | 17 ++++++++++++
>  xen/drivers/passthrough/vtd/extern.h |  1 +
>  xen/drivers/passthrough/vtd/iommu.c  |  1 +
>  xen/include/public/memory.h          | 24 +++++++++++++++-
>  xen/include/xen/iommu.h              |  4 +++
>  xen/include/xlat.lst                 |  3 +-
>  9 files changed, 163 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
> index 06c90be..60512fa 100644
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -16,6 +16,37 @@ CHECK_TYPE(domid);
>  
>  CHECK_mem_access_op;
>  
> +#ifdef HAS_PASSTHROUGH
> +struct get_reserved_device_memory {
> +    struct compat_reserved_device_memory_map map;
> +    unsigned int used_entries;
> +};
> +
> +static int get_reserved_device_memory(xen_pfn_t start,
> +                                      xen_ulong_t nr, void *ctxt)
> +{
> +    struct get_reserved_device_memory *grdm = ctxt;
> +
> +    if ( grdm->used_entries < grdm->map.nr_entries )
> +    {
> +        struct compat_reserved_device_memory rdm = {
> +            .start_pfn = start, .nr_pages = nr
> +        };
> +
> +        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;
> +    }
> +
> +    ++grdm->used_entries;
> +
> +    return 0;
> +}
> +#endif
> +
>  int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>  {
>      int split, op = cmd & MEMOP_CMD_MASK;
> @@ -273,6 +304,29 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>              break;
>          }
>  
> +#ifdef HAS_PASSTHROUGH
> +        case XENMEM_reserved_device_memory_map:
> +        {
> +            struct get_reserved_device_memory grdm;
> +
> +            if ( copy_from_guest(&grdm.map, compat, 1) ||
> +                 !compat_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
> +                return -EFAULT;
> +
> +            grdm.used_entries = 0;
> +            rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
> +                                                  &grdm);
> +
> +            if ( !rc && grdm.map.nr_entries < grdm.used_entries )
> +                rc = -ENOBUFS;
> +            grdm.map.nr_entries = grdm.used_entries;
> +            if ( __copy_to_guest(compat, &grdm.map, 1) )
> +                rc = -EFAULT;
> +
> +            return rc;
> +        }
> +#endif
> +
>          default:
>              return compat_arch_memory_op(cmd, compat);
>          }
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 9f21bd3..4788acc 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -692,6 +692,34 @@ out:
>      return rc;
>  }
>  
> +#ifdef HAS_PASSTHROUGH
> +struct get_reserved_device_memory {
> +    struct xen_reserved_device_memory_map map;
> +    unsigned int used_entries;
> +};
> +
> +static int get_reserved_device_memory(xen_pfn_t start,
> +                                      xen_ulong_t nr, void *ctxt)
> +{
> +    struct get_reserved_device_memory *grdm = ctxt;
> +
> +    if ( grdm->used_entries < grdm->map.nr_entries )
> +    {
> +        struct xen_reserved_device_memory rdm = {
> +            .start_pfn = start, .nr_pages = nr
> +        };
> +
> +        if ( __copy_to_guest_offset(grdm->map.buffer, grdm->used_entries,
> +                                    &rdm, 1) )
> +            return -EFAULT;
> +    }
> +
> +    ++grdm->used_entries;
> +
> +    return 0;
> +}
> +#endif
> +
>  long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      struct domain *d;
> @@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          break;
>      }
>  
> +#ifdef HAS_PASSTHROUGH
> +    case XENMEM_reserved_device_memory_map:
> +    {
> +        struct get_reserved_device_memory grdm;
> +
> +        if ( copy_from_guest(&grdm.map, arg, 1) ||
> +             !guest_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
> +            return -EFAULT;
> +

Shouldn't there be an XSM check here?

> +        grdm.used_entries = 0;
> +        rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
> +                                              &grdm);
> +

Also since we doing an iteration over possible many nr_entries should
we think about returning -EAGAIN to user-space so that it can retry?
(As in, have preemption baked in this hypercall)

> +        if ( !rc && grdm.map.nr_entries < grdm.used_entries )
> +            rc = -ENOBUFS;
> +        grdm.map.nr_entries = grdm.used_entries;
> +        if ( __copy_to_guest(arg, &grdm.map, 1) )
> +            rc = -EFAULT;
> +
> +        break;
> +    }
> +#endif
> +
>      default:
>          rc = arch_memory_op(cmd, arg);
>          break;
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
> index cc12735..7c17e8d 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -344,6 +344,16 @@ void iommu_crash_shutdown(void)
>      iommu_enabled = iommu_intremap = 0;
>  }
>  
> +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);
> +}
> +
>  bool_t iommu_has_feature(struct domain *d, enum iommu_feature feature)
>  {
>      const struct hvm_iommu *hd = domain_hvm_iommu(d);
> diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
> index 5e41e7a..86cfad3 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -901,3 +901,20 @@ int platform_supports_x2apic(void)
>      unsigned int mask = ACPI_DMAR_INTR_REMAP | ACPI_DMAR_X2APIC_OPT_OUT;
>      return cpu_has_x2apic && ((dmar_flags & mask) == ACPI_DMAR_INTR_REMAP);
>  }
> +
> +int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
> +{
> +    struct acpi_rmrr_unit *rmrr;
> +    int rc = 0;
> +
> +    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;
> +    }
> +
> +    return rc;
> +}
> diff --git a/xen/drivers/passthrough/vtd/extern.h b/xen/drivers/passthrough/vtd/extern.h
> index 5524dba..f9ee9b0 100644
> --- a/xen/drivers/passthrough/vtd/extern.h
> +++ b/xen/drivers/passthrough/vtd/extern.h
> @@ -75,6 +75,7 @@ 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);
>  
>  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/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
> index 19d8165..a38f201 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2491,6 +2491,7 @@ const struct iommu_ops intel_iommu_ops = {
>      .crash_shutdown = vtd_crash_shutdown,
>      .iotlb_flush = intel_iommu_iotlb_flush,
>      .iotlb_flush_all = intel_iommu_iotlb_flush_all,
> +    .get_reserved_device_memory = intel_iommu_get_reserved_device_memory,
>      .dump_p2m_table = vtd_dump_p2m_table,
>  };
>  
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index 595f953..cee4535 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -572,7 +572,29 @@ struct xen_vnuma_topology_info {
>  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 */
> +/*
> + * For legacy reasons, some devices must be configured with special memory
> + * regions to function correctly.  The guest must avoid using any of these
> + * regions.
> + */
> +#define XENMEM_reserved_device_memory_map   27
> +struct xen_reserved_device_memory {
> +    xen_pfn_t start_pfn;
> +    xen_ulong_t nr_pages;
> +};
> +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 {
> +    /* IN/OUT */
> +    unsigned int nr_entries;
> +    /* OUT */
> +    XEN_GUEST_HANDLE(xen_reserved_device_memory_t) buffer;
> +};
> +typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t);
> +
> +/* Next available subop number is 28 */
>  
>  #endif /* __XEN_PUBLIC_MEMORY_H__ */
>  
> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
> index 8eb764a..409f6f8 100644
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -120,6 +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);
> +
>  struct iommu_ops {
>      int (*init)(struct domain *d);
>      void (*hwdom_init)(struct domain *d);
> @@ -156,12 +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 *);
>      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 *);
>  
>  void iommu_share_p2m_table(struct domain *d);
>  
> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
> index 41b3e35..42229fd 100644
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -61,9 +61,10 @@
>  !	memory_exchange			memory.h
>  !	memory_map			memory.h
>  !	memory_reservation		memory.h
> -?	mem_access_op		memory.h
> +?	mem_access_op			memory.h
>  !	pod_target			memory.h
>  !	remove_from_physmap		memory.h
> +!	reserved_device_memory_map	memory.h
>  ?	physdev_eoi			physdev.h
>  ?	physdev_get_free_pirq		physdev.h
>  ?	physdev_irq			physdev.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 Dec 02 19:50:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 19: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 1XvtSy-0007oa-14; Tue, 02 Dec 2014 19:50:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvtSw-0007oP-FH
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 19:50:30 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	1C/CF-17735-5081E745; Tue, 02 Dec 2014 19:50:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417549827!12914235!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20121 invoked from network); 2 Dec 2014 19:50:28 -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; 2 Dec 2014 19:50: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 sB2JoJam017969
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 19:50:20 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
	sB2JoJtT022735
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 19:50:19 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
	sB2JoIaG022852; Tue, 2 Dec 2014 19:50:18 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 11:50:18 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 180C811B10C; Tue,  2 Dec 2014 14:50:18 -0500 (EST)
Date: Tue, 2 Dec 2014 14:50:17 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202195017.GE357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-6-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-6-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 05/17] tools/libxc: introduce hypercall
 for xc_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 05:24:23PM +0800, Tiejun Chen wrote:
> We will introduce that hypercall xc_reserved_device_memory_map
> approach to libxc.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/libxc/include/xenctrl.h |  5 +++++
>  tools/libxc/xc_domain.c       | 30 ++++++++++++++++++++++++++++++
>  2 files changed, 35 insertions(+)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 84012fe..a3aeac3 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1294,6 +1294,11 @@ int xc_domain_set_memory_map(xc_interface *xch,
>  int xc_get_machine_memory_map(xc_interface *xch,
>                                struct e820entry entries[],
>                                uint32_t max_entries);
> +
> +int xc_reserved_device_memory_map(xc_interface *xch,
> +                                  uint32_t dom,
> +                                  struct xen_reserved_device_memory entries[],
> +                                  uint32_t *max_entries);
>  #endif
>  int xc_domain_set_time_offset(xc_interface *xch,
>                                uint32_t domid,
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 7fd43e9..09fd988 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -679,6 +679,36 @@ int xc_domain_set_memory_map(xc_interface *xch,
>  
>      return rc;
>  }
> +
> +int xc_reserved_device_memory_map(xc_interface *xch,
> +                                  uint32_t domid,
> +                                  struct xen_reserved_device_memory entries[],
> +                                  uint32_t *max_entries)
> +{
> +    int rc;
> +    struct xen_reserved_device_memory_map xrdmmap = {
> +        .domid = domid,
> +        .nr_entries = *max_entries
> +    };
> +    DECLARE_HYPERCALL_BOUNCE(entries,
> +                             sizeof(struct xen_reserved_device_memory) *
> +                             *max_entries, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
> +
> +    if ( xc_hypercall_bounce_pre(xch, entries) )
> +        return -1;
> +
> +    set_xen_guest_handle(xrdmmap.buffer, entries);
> +
> +    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
> +                      &xrdmmap, sizeof(xrdmmap));
> +
> +    xc_hypercall_bounce_post(xch, entries);
> +
> +    *max_entries = xrdmmap.nr_entries;
> +

I would bake the -EAGAIN support in here to loop here.

See how the xc_domain_destroy does it.
> +    return rc ? rc : xrdmmap.nr_entries;
> +}
> +
>  int xc_get_machine_memory_map(xc_interface *xch,
>                                struct e820entry entries[],
>                                uint32_t max_entries)
> -- 
> 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 Dec 02 19:50:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 19: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 1XvtSy-0007oa-14; Tue, 02 Dec 2014 19:50:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvtSw-0007oP-FH
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 19:50:30 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	1C/CF-17735-5081E745; Tue, 02 Dec 2014 19:50:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417549827!12914235!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20121 invoked from network); 2 Dec 2014 19:50:28 -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; 2 Dec 2014 19:50: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 sB2JoJam017969
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 19:50:20 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
	sB2JoJtT022735
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 19:50:19 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
	sB2JoIaG022852; Tue, 2 Dec 2014 19:50:18 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 11:50:18 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 180C811B10C; Tue,  2 Dec 2014 14:50:18 -0500 (EST)
Date: Tue, 2 Dec 2014 14:50:17 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202195017.GE357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-6-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-6-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 05/17] tools/libxc: introduce hypercall
 for xc_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 05:24:23PM +0800, Tiejun Chen wrote:
> We will introduce that hypercall xc_reserved_device_memory_map
> approach to libxc.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/libxc/include/xenctrl.h |  5 +++++
>  tools/libxc/xc_domain.c       | 30 ++++++++++++++++++++++++++++++
>  2 files changed, 35 insertions(+)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 84012fe..a3aeac3 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1294,6 +1294,11 @@ int xc_domain_set_memory_map(xc_interface *xch,
>  int xc_get_machine_memory_map(xc_interface *xch,
>                                struct e820entry entries[],
>                                uint32_t max_entries);
> +
> +int xc_reserved_device_memory_map(xc_interface *xch,
> +                                  uint32_t dom,
> +                                  struct xen_reserved_device_memory entries[],
> +                                  uint32_t *max_entries);
>  #endif
>  int xc_domain_set_time_offset(xc_interface *xch,
>                                uint32_t domid,
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 7fd43e9..09fd988 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -679,6 +679,36 @@ int xc_domain_set_memory_map(xc_interface *xch,
>  
>      return rc;
>  }
> +
> +int xc_reserved_device_memory_map(xc_interface *xch,
> +                                  uint32_t domid,
> +                                  struct xen_reserved_device_memory entries[],
> +                                  uint32_t *max_entries)
> +{
> +    int rc;
> +    struct xen_reserved_device_memory_map xrdmmap = {
> +        .domid = domid,
> +        .nr_entries = *max_entries
> +    };
> +    DECLARE_HYPERCALL_BOUNCE(entries,
> +                             sizeof(struct xen_reserved_device_memory) *
> +                             *max_entries, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
> +
> +    if ( xc_hypercall_bounce_pre(xch, entries) )
> +        return -1;
> +
> +    set_xen_guest_handle(xrdmmap.buffer, entries);
> +
> +    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
> +                      &xrdmmap, sizeof(xrdmmap));
> +
> +    xc_hypercall_bounce_post(xch, entries);
> +
> +    *max_entries = xrdmmap.nr_entries;
> +

I would bake the -EAGAIN support in here to loop here.

See how the xc_domain_destroy does it.
> +    return rc ? rc : xrdmmap.nr_entries;
> +}
> +
>  int xc_get_machine_memory_map(xc_interface *xch,
>                                struct e820entry entries[],
>                                uint32_t max_entries)
> -- 
> 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 Dec 02 19:55:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 19:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvtXe-00087K-O1; Tue, 02 Dec 2014 19:55: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 1XvtXd-00087F-6n
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 19:55:21 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	BA/2D-27584-8291E745; Tue, 02 Dec 2014 19:55:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417550118!3564867!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20870 invoked from network); 2 Dec 2014 19:55:19 -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; 2 Dec 2014 19:55: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 sB2JtAcQ023335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 19:55:10 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
	sB2Jt7v7002900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 19:55:07 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
	sB2Jt720021406; Tue, 2 Dec 2014 19:55:07 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 11:55:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D824911B113; Tue,  2 Dec 2014 14:55:06 -0500 (EST)
Date: Tue, 2 Dec 2014 14:55:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202195506.GF357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-7-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-7-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 06/17] tools/libxc: check if modules
 space is overlapping with reserved device 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, Dec 01, 2014 at 05:24:24PM +0800, Tiejun Chen wrote:
> In case of reserved device memory overlapping with ram, it also probably

s/also//
> overlap with modules space so we need to check these reserved device
s/overlap/overlaps/

What is 'modules space'?

> memory as well.

s/reserved device memory/E820_RSV/ ?

> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/libxc/xc_hvm_build_x86.c | 94 +++++++++++++++++++++++++++++++++++-------
>  1 file changed, 79 insertions(+), 15 deletions(-)
> 
> diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
> index c81a25b..ddcf06d 100644
> --- a/tools/libxc/xc_hvm_build_x86.c
> +++ b/tools/libxc/xc_hvm_build_x86.c
> @@ -54,9 +54,82 @@
>  
>  #define VGA_HOLE_SIZE (0x20)
>  
> +/*
> + * Check whether there exists mmio hole in the specified memory range.
> + * Returns 1 if exists, else returns 0.
> + */
> +static int check_mmio_hole(uint64_t start, uint64_t memsize,
> +                           uint64_t mmio_start, uint64_t mmio_size)
> +{
> +    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
> +        return 0;
> +    else
> +        return 1;
> +}
> +
> +/* Getting all reserved device memory map info. */
> +static struct xen_reserved_device_memory
> +*xc_get_reserved_device_memory_map(xc_interface *xch, unsigned int nr_entries,
> +                                   uint32_t dom)
> +{
> +    struct xen_reserved_device_memory *xrdm = NULL;
> +    int rc = xc_reserved_device_memory_map(xch, dom, xrdm, &nr_entries);
> +
> +    if ( rc < 0 )
> +    {
> +        if ( errno == ENOBUFS )
> +        {
> +            if ( (xrdm = malloc(nr_entries *
> +                                sizeof(xen_reserved_device_memory_t))) == NULL )
> +            {
> +                PERROR("Could not allocate memory.");
> +                return 0;
> +            }
> +            rc = xc_reserved_device_memory_map(xch, dom, xrdm, &nr_entries);
> +            if ( rc )
> +            {
> +                PERROR("Could not get reserved device memory maps.");
> +                free(xrdm);
> +                return 0;

Uhhh, is that the right error to return?

Don't you mean ERR_PTR logic? Or 'return NULL' ?


> +            }
> +        }
> +        else
> +            PERROR("Could not get reserved device memory maps.");
> +    }
> +
> +    return xrdm;
> +}
> +
> +static int xc_check_modules_space(xc_interface *xch, uint64_t *mstart_out,
> +                                  uint64_t *mend_out, uint32_t dom)
> +{
> +    unsigned int i = 0, nr_entries = 0;
> +    uint64_t rdm_start = 0, rdm_end = 0;
> +    struct xen_reserved_device_memory *rdm_map =
> +                        xc_get_reserved_device_memory_map(xch, nr_entries, dom);
> +

You need to check whether 'rdm_map' is NULL.

> +    for ( i = 0; i < nr_entries; i++ )
> +    {
> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << XC_PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << XC_PAGE_SHIFT);
> +
> +        /* Just use check_mmio_hole() to check modules ranges. */
> +        if ( check_mmio_hole(rdm_start,
> +                             rdm_end - rdm_start,
> +                             *mstart_out, *mend_out) )
> +            return -1;
> +    }
> +    
> +    free(rdm_map);
> +
> +    return 0;
> +}
> +
>  static int modules_init(struct xc_hvm_build_args *args,
>                          uint64_t vend, struct elf_binary *elf,
> -                        uint64_t *mstart_out, uint64_t *mend_out)
> +                        uint64_t *mstart_out, uint64_t *mend_out,
> +                        xc_interface *xch,
> +                        uint32_t dom)
>  {
>  #define MODULE_ALIGN 1UL << 7
>  #define MB_ALIGN     1UL << 20
> @@ -80,6 +153,10 @@ static int modules_init(struct xc_hvm_build_args *args,
>      if ( *mend_out > vend )    
>          return -1;
>  
> +    /* Is it overlapping with reserved device memory? */
> +    if ( xc_check_modules_space(xch, mstart_out, mend_out, dom) )
> +        return -1;
> +
>      if ( args->acpi_module.length != 0 )
>          args->acpi_module.guest_addr_out = *mstart_out;
>      if ( args->smbios_module.length != 0 )
> @@ -226,19 +303,6 @@ static int loadmodules(xc_interface *xch,
>      return rc;
>  }
>  
> -/*
> - * Check whether there exists mmio hole in the specified memory range.
> - * Returns 1 if exists, else returns 0.
> - */
> -static int check_mmio_hole(uint64_t start, uint64_t memsize,
> -                           uint64_t mmio_start, uint64_t mmio_size)
> -{
> -    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
> -        return 0;
> -    else
> -        return 1;
> -}
> -

This movement of 'check_mmio_hole' needs to be a seperate patch.

>  static int setup_guest(xc_interface *xch,
>                         uint32_t dom, struct xc_hvm_build_args *args,
>                         char *image, unsigned long image_size)
> @@ -282,7 +346,7 @@ static int setup_guest(xc_interface *xch,
>          goto error_out;
>      }
>  
> -    if ( modules_init(args, v_end, &elf, &m_start, &m_end) != 0 )
> +    if ( modules_init(args, v_end, &elf, &m_start, &m_end, xch, dom) != 0 )
>      {
>          ERROR("Insufficient space to load modules.");
>          goto error_out;
> -- 
> 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 Dec 02 19:55:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 19:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvtXe-00087K-O1; Tue, 02 Dec 2014 19:55: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 1XvtXd-00087F-6n
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 19:55:21 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	BA/2D-27584-8291E745; Tue, 02 Dec 2014 19:55:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417550118!3564867!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20870 invoked from network); 2 Dec 2014 19:55:19 -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; 2 Dec 2014 19:55: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 sB2JtAcQ023335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 19:55:10 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
	sB2Jt7v7002900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 19:55:07 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
	sB2Jt720021406; Tue, 2 Dec 2014 19:55:07 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 11:55:06 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id D824911B113; Tue,  2 Dec 2014 14:55:06 -0500 (EST)
Date: Tue, 2 Dec 2014 14:55:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202195506.GF357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-7-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-7-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 06/17] tools/libxc: check if modules
 space is overlapping with reserved device 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, Dec 01, 2014 at 05:24:24PM +0800, Tiejun Chen wrote:
> In case of reserved device memory overlapping with ram, it also probably

s/also//
> overlap with modules space so we need to check these reserved device
s/overlap/overlaps/

What is 'modules space'?

> memory as well.

s/reserved device memory/E820_RSV/ ?

> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/libxc/xc_hvm_build_x86.c | 94 +++++++++++++++++++++++++++++++++++-------
>  1 file changed, 79 insertions(+), 15 deletions(-)
> 
> diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
> index c81a25b..ddcf06d 100644
> --- a/tools/libxc/xc_hvm_build_x86.c
> +++ b/tools/libxc/xc_hvm_build_x86.c
> @@ -54,9 +54,82 @@
>  
>  #define VGA_HOLE_SIZE (0x20)
>  
> +/*
> + * Check whether there exists mmio hole in the specified memory range.
> + * Returns 1 if exists, else returns 0.
> + */
> +static int check_mmio_hole(uint64_t start, uint64_t memsize,
> +                           uint64_t mmio_start, uint64_t mmio_size)
> +{
> +    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
> +        return 0;
> +    else
> +        return 1;
> +}
> +
> +/* Getting all reserved device memory map info. */
> +static struct xen_reserved_device_memory
> +*xc_get_reserved_device_memory_map(xc_interface *xch, unsigned int nr_entries,
> +                                   uint32_t dom)
> +{
> +    struct xen_reserved_device_memory *xrdm = NULL;
> +    int rc = xc_reserved_device_memory_map(xch, dom, xrdm, &nr_entries);
> +
> +    if ( rc < 0 )
> +    {
> +        if ( errno == ENOBUFS )
> +        {
> +            if ( (xrdm = malloc(nr_entries *
> +                                sizeof(xen_reserved_device_memory_t))) == NULL )
> +            {
> +                PERROR("Could not allocate memory.");
> +                return 0;
> +            }
> +            rc = xc_reserved_device_memory_map(xch, dom, xrdm, &nr_entries);
> +            if ( rc )
> +            {
> +                PERROR("Could not get reserved device memory maps.");
> +                free(xrdm);
> +                return 0;

Uhhh, is that the right error to return?

Don't you mean ERR_PTR logic? Or 'return NULL' ?


> +            }
> +        }
> +        else
> +            PERROR("Could not get reserved device memory maps.");
> +    }
> +
> +    return xrdm;
> +}
> +
> +static int xc_check_modules_space(xc_interface *xch, uint64_t *mstart_out,
> +                                  uint64_t *mend_out, uint32_t dom)
> +{
> +    unsigned int i = 0, nr_entries = 0;
> +    uint64_t rdm_start = 0, rdm_end = 0;
> +    struct xen_reserved_device_memory *rdm_map =
> +                        xc_get_reserved_device_memory_map(xch, nr_entries, dom);
> +

You need to check whether 'rdm_map' is NULL.

> +    for ( i = 0; i < nr_entries; i++ )
> +    {
> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << XC_PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << XC_PAGE_SHIFT);
> +
> +        /* Just use check_mmio_hole() to check modules ranges. */
> +        if ( check_mmio_hole(rdm_start,
> +                             rdm_end - rdm_start,
> +                             *mstart_out, *mend_out) )
> +            return -1;
> +    }
> +    
> +    free(rdm_map);
> +
> +    return 0;
> +}
> +
>  static int modules_init(struct xc_hvm_build_args *args,
>                          uint64_t vend, struct elf_binary *elf,
> -                        uint64_t *mstart_out, uint64_t *mend_out)
> +                        uint64_t *mstart_out, uint64_t *mend_out,
> +                        xc_interface *xch,
> +                        uint32_t dom)
>  {
>  #define MODULE_ALIGN 1UL << 7
>  #define MB_ALIGN     1UL << 20
> @@ -80,6 +153,10 @@ static int modules_init(struct xc_hvm_build_args *args,
>      if ( *mend_out > vend )    
>          return -1;
>  
> +    /* Is it overlapping with reserved device memory? */
> +    if ( xc_check_modules_space(xch, mstart_out, mend_out, dom) )
> +        return -1;
> +
>      if ( args->acpi_module.length != 0 )
>          args->acpi_module.guest_addr_out = *mstart_out;
>      if ( args->smbios_module.length != 0 )
> @@ -226,19 +303,6 @@ static int loadmodules(xc_interface *xch,
>      return rc;
>  }
>  
> -/*
> - * Check whether there exists mmio hole in the specified memory range.
> - * Returns 1 if exists, else returns 0.
> - */
> -static int check_mmio_hole(uint64_t start, uint64_t memsize,
> -                           uint64_t mmio_start, uint64_t mmio_size)
> -{
> -    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
> -        return 0;
> -    else
> -        return 1;
> -}
> -

This movement of 'check_mmio_hole' needs to be a seperate patch.

>  static int setup_guest(xc_interface *xch,
>                         uint32_t dom, struct xc_hvm_build_args *args,
>                         char *image, unsigned long image_size)
> @@ -282,7 +346,7 @@ static int setup_guest(xc_interface *xch,
>          goto error_out;
>      }
>  
> -    if ( modules_init(args, v_end, &elf, &m_start, &m_end) != 0 )
> +    if ( modules_init(args, v_end, &elf, &m_start, &m_end, xch, dom) != 0 )
>      {
>          ERROR("Insufficient space to load modules.");
>          goto error_out;
> -- 
> 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 Dec 02 20:01:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1XvtdU-0008Jl-GV; Tue, 02 Dec 2014 20:01:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvtdS-0008Jg-Qs
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:01:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AB/F6-09842-29A1E745; Tue, 02 Dec 2014 20:01:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417550480!12925760!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31311 invoked from network); 2 Dec 2014 20:01:21 -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; 2 Dec 2014 20:01:21 -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 sB2K147u031274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:01:05 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
	sB2K13KI011295
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:01:04 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
	sB2K13oF011271; Tue, 2 Dec 2014 20:01:03 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:01:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8615F11B121; Tue,  2 Dec 2014 15:01:00 -0500 (EST)
Date: Tue, 2 Dec 2014 15:01:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202200100.GG357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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 Mon, Dec 01, 2014 at 05:24:25PM +0800, Tiejun Chen wrote:
> We need to use reserved device memory maps with multiple times, so
> provide just one common function should be friend.

We need to call reserved device memory maps hypercall
(XENMEM_reserved_device_memory_map) many times, hence provide one common function.

> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/util.c | 59 +++++++++++++++++++++++++++++++++++++++++
>  tools/firmware/hvmloader/util.h |  2 ++
>  2 files changed, 61 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 80d822f..dd81fb6 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -22,11 +22,14 @@
>  #include "config.h"
>  #include "hypercall.h"
>  #include "ctype.h"
> +#include "errno.h"
>  #include <stdint.h>
>  #include <xen/xen.h>
>  #include <xen/memory.h>
>  #include <xen/sched.h>
>  
> +struct xen_reserved_device_memory *rdm_map;
> +
>  void wrmsr(uint32_t idx, uint64_t v)
>  {
>      asm volatile (
> @@ -828,6 +831,62 @@ int hpet_exists(unsigned long hpet_base)
>      return ((hpet_id >> 16) == 0x8086);
>  }
>  
> +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 = {
> +        .domid = DOMID_SELF,
> +        .nr_entries = *max_entries
> +    };
> +
> +    set_xen_guest_handle(xrdmmap.buffer, entries);
> +
> +    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map, &xrdmmap);
> +    *max_entries = xrdmmap.nr_entries;

Don't you want to check rc first before altering 'max_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.

That does not sound like the right error value. Why not a proper
return value? At worst you can put 'nr_entries' as an parameter
and return the error value.

> + */
> +unsigned int hvm_get_reserved_device_memory_map(void)
> +{
> +    static unsigned int nr_entries = 0;
> +    int rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
> +
> +    if ( rc == -ENOBUFS )
> +    {
> +        rdm_map = mem_alloc(nr_entries*sizeof(struct xen_reserved_device_memory),

That '*' being squashed looks wrong. Just make it bigger and don't worry about
the 80 line.

> +                            0);
> +        if ( rdm_map )
> +        {
> +            rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
> +            if ( rc )
> +            {
> +                printf("Could not get reserved dev memory info on domain");
> +                return 0;
> +            }
> +        }
> +        else
> +        {
> +            printf("No space to get reserved dev memory maps!\n");
> +            return 0;
> +        }
> +    }
> +    else if ( rc )
> +    {
> +        printf("Could not get reserved dev memory info on domain");
> +        return 0;
> +    }
> +
> +    return nr_entries;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> index a70e4aa..e4f1851 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -241,6 +241,8 @@ int build_e820_table(struct e820entry *e820,
>                       unsigned int bios_image_base);
>  void dump_e820_table(struct e820entry *e820, unsigned int nr);
>  
> +unsigned int hvm_get_reserved_device_memory_map(void);
> +
>  #ifndef NDEBUG
>  void perform_tests(void);
>  #else
> -- 
> 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 Dec 02 20:01:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1XvtdU-0008Jl-GV; Tue, 02 Dec 2014 20:01:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvtdS-0008Jg-Qs
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:01:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AB/F6-09842-29A1E745; Tue, 02 Dec 2014 20:01:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417550480!12925760!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31311 invoked from network); 2 Dec 2014 20:01:21 -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; 2 Dec 2014 20:01:21 -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 sB2K147u031274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:01:05 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
	sB2K13KI011295
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:01:04 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
	sB2K13oF011271; Tue, 2 Dec 2014 20:01:03 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:01:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8615F11B121; Tue,  2 Dec 2014 15:01:00 -0500 (EST)
Date: Tue, 2 Dec 2014 15:01:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202200100.GG357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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 Mon, Dec 01, 2014 at 05:24:25PM +0800, Tiejun Chen wrote:
> We need to use reserved device memory maps with multiple times, so
> provide just one common function should be friend.

We need to call reserved device memory maps hypercall
(XENMEM_reserved_device_memory_map) many times, hence provide one common function.

> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/util.c | 59 +++++++++++++++++++++++++++++++++++++++++
>  tools/firmware/hvmloader/util.h |  2 ++
>  2 files changed, 61 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 80d822f..dd81fb6 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -22,11 +22,14 @@
>  #include "config.h"
>  #include "hypercall.h"
>  #include "ctype.h"
> +#include "errno.h"
>  #include <stdint.h>
>  #include <xen/xen.h>
>  #include <xen/memory.h>
>  #include <xen/sched.h>
>  
> +struct xen_reserved_device_memory *rdm_map;
> +
>  void wrmsr(uint32_t idx, uint64_t v)
>  {
>      asm volatile (
> @@ -828,6 +831,62 @@ int hpet_exists(unsigned long hpet_base)
>      return ((hpet_id >> 16) == 0x8086);
>  }
>  
> +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 = {
> +        .domid = DOMID_SELF,
> +        .nr_entries = *max_entries
> +    };
> +
> +    set_xen_guest_handle(xrdmmap.buffer, entries);
> +
> +    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map, &xrdmmap);
> +    *max_entries = xrdmmap.nr_entries;

Don't you want to check rc first before altering 'max_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.

That does not sound like the right error value. Why not a proper
return value? At worst you can put 'nr_entries' as an parameter
and return the error value.

> + */
> +unsigned int hvm_get_reserved_device_memory_map(void)
> +{
> +    static unsigned int nr_entries = 0;
> +    int rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
> +
> +    if ( rc == -ENOBUFS )
> +    {
> +        rdm_map = mem_alloc(nr_entries*sizeof(struct xen_reserved_device_memory),

That '*' being squashed looks wrong. Just make it bigger and don't worry about
the 80 line.

> +                            0);
> +        if ( rdm_map )
> +        {
> +            rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
> +            if ( rc )
> +            {
> +                printf("Could not get reserved dev memory info on domain");
> +                return 0;
> +            }
> +        }
> +        else
> +        {
> +            printf("No space to get reserved dev memory maps!\n");
> +            return 0;
> +        }
> +    }
> +    else if ( rc )
> +    {
> +        printf("Could not get reserved dev memory info on domain");
> +        return 0;
> +    }
> +
> +    return nr_entries;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> index a70e4aa..e4f1851 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -241,6 +241,8 @@ int build_e820_table(struct e820entry *e820,
>                       unsigned int bios_image_base);
>  void dump_e820_table(struct e820entry *e820, unsigned int nr);
>  
> +unsigned int hvm_get_reserved_device_memory_map(void);
> +
>  #ifndef NDEBUG
>  void perform_tests(void);
>  #else
> -- 
> 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 Dec 02 20:18:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1XvttY-0000Ny-CI; Tue, 02 Dec 2014 20:18:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvttX-0000Nt-Gx
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:17:59 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B8/17-22737-67E1E745; Tue, 02 Dec 2014 20:17:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417551476!7799812!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11503 invoked from network); 2 Dec 2014 20:17:57 -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; 2 Dec 2014 20:17:57 -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 sB2KHmmG019052
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:17:49 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
	sB2KHjZU022140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:17:45 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
	sB2KHijh000781; Tue, 2 Dec 2014 20:17:44 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:17:44 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7E83211B142; Tue,  2 Dec 2014 15:17:44 -0500 (EST)
Date: Tue, 2 Dec 2014 15:17:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202201744.GH357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 09/17] 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 Mon, Dec 01, 2014 at 05:24:27PM +0800, Tiejun Chen wrote:
> We need to check to reserve all reserved device memory maps in e820
> to avoid any potential guest memory conflict.
> 
> Currently, if we can't insert RDM entries directly, we may need to handle
> several ranges as follows:

s/several/two/

s/follows/follow/

> a. Fixed Ranges --> BUG()
>  lowmem_reserved_base-0xA0000: reserved by BIOS implementation,
>  BIOS region,
>  RESERVED_MEMBASE ~ 0x100000000,

I am not sure what you are trying to say here. Could you explain it 
a bit more please?

> b. RAM or RAM:Hole -> Try to reserve

Reading the beginning of the 'Currently'.. this says:

we may need to handle RAM or RAM:Hole -> Try to reserve.

I don't know what 'RAM:Hole' means. And instead of using '->' you can
say: we will try to reserve.

But what are we reserving ? Are we reserving it as an E820_RSV or just
as an hole? What about the RAM behind it? Are we gulping up the RAM regions
(as in losing them) or are we moving the RAM regions (GPFNs) to somewhere else?

> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/e820.c | 168 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 168 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
> index 2e05e93..ef87e41 100644
> --- a/tools/firmware/hvmloader/e820.c
> +++ b/tools/firmware/hvmloader/e820.c
> @@ -22,6 +22,7 @@
>  
>  #include "config.h"
>  #include "util.h"
> +#include <xen/memory.h>
>  
>  void dump_e820_table(struct e820entry *e820, unsigned int nr)
>  {
> @@ -68,12 +69,173 @@ void dump_e820_table(struct e820entry *e820, unsigned int nr)
>      }
>  }
>  
> +extern struct xen_reserved_device_memory *rdm_map;
> +static unsigned int construct_rdm_e820_maps(unsigned int next_e820_entry_index,

s/next_e820_entry_index/next_entry/ ?

> +                                            uint32_t nr_map,
> +                                            struct xen_reserved_device_memory *map,
> +                                            struct e820entry *e820,
> +                                            unsigned int lowmem_reserved_base,
> +                                            unsigned int bios_image_base)
> +{
> +    unsigned int i, j, sum_nr;
> +    uint64_t start, end, next_start, rdm_start, rdm_end;
> +    uint32_t type;
> +    int err = 0;
> +
> +    for ( i = 0; i < nr_map; i++ )
> +    {
> +        rdm_start = (uint64_t)map[i].start_pfn << PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)map[i].nr_pages << PAGE_SHIFT);
> +
> +        for ( j = 0; j < next_e820_entry_index - 1; j++ )
> +        {
> +            sum_nr = next_e820_entry_index + nr_map;
> +            start = e820[j].addr;
> +            end = e820[j].addr + e820[j].size;
> +            type = e820[j].type;
> +            next_start = e820[j+1].addr;
> +
> +            if ( rdm_start >= start && rdm_start <= end )
> +            {
> +                /*
> +                 * lowmem_reserved_base-0xA0000: reserved by BIOS
> +                 * implementation.
> +                 * Or BIOS region.
> +                 */
> +                if ( (lowmem_reserved_base < 0xA0000 &&
> +                        start == lowmem_reserved_base) ||
> +                     start == bios_image_base )

something is off with your spaces.
> +                {
> +                    err = -1;
> +                    break;

Keep in mind we will just break out of this loop. Do you want to add
at the end of this loop:


if (err)
	break;

> +                }
> +            }
> +
> +            /* Just amid those remaining e820 entries. */
> +            if ( (rdm_start > end) && (rdm_end < next_start) )
> +            {
> +                memmove(&e820[j+2], &e820[j+1],
> +                        (sum_nr - j - 1) * sizeof(struct e820entry));

What if there is something at j+2? Should we have an
j-2 < E820_MAX check somewhere?

This whole 'memmove' logic is making me a bit worried.

Would it be easier to have this logic inside build_e820_table so
that it could construct the e820 with this information right away?

Or if that was deemed incorrect could you explain that in the
commit description?

> +
> +                /* Then fill RMRR into that entry. */
> +                e820[j+1].addr = rdm_start;
> +                e820[j+1].size = rdm_end - rdm_start;
> +                e820[j+1].type = E820_RESERVED;
> +                next_e820_entry_index++;
> +                continue;
> +            }
> +
> +            /* Already at the end. */
> +            if ( (rdm_start > end) && !next_start )
> +            {
> +                e820[next_e820_entry_index].addr = rdm_start;
> +                e820[next_e820_entry_index].size = rdm_end - rdm_start;
> +                e820[next_e820_entry_index].type = E820_RESERVED;
> +                next_e820_entry_index++;
> +                continue;
> +            }
> +
> +            if ( type == E820_RAM )
> +            {
> +                /* If coincide with one RAM range. */
> +                if ( rdm_start == start && rdm_end == end)
> +                {
> +                    e820[j].type = E820_RESERVED;
> +                    continue;
> +                }
> +
> +                /* If we're just aligned with start of one RAM range. */
> +                if ( rdm_start == start && rdm_end < end )
> +                {
> +                    memmove(&e820[j+1], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j+1].addr = rdm_end;
> +                    e820[j+1].size = e820[j].addr + e820[j].size - rdm_end;
> +                    e820[j+1].type = E820_RAM;
> +                    next_e820_entry_index++;
> +
> +                    e820[j].addr = rdm_start;
> +                    e820[j].size = rdm_end - rdm_start;
> +                    e820[j].type = E820_RESERVED;
> +                    continue;
> +                }
> +
> +                /* If we're just aligned with end of one RAM range. */
> +                if ( rdm_start > start && rdm_end == end )
> +                {
> +                    memmove(&e820[j+1], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j].size = rdm_start - e820[j].addr;
> +                    e820[j].type = E820_RAM;
> +
> +                    e820[j+1].addr = rdm_start;
> +                    e820[j+1].size = rdm_end - rdm_start;
> +                    e820[j+1].type = E820_RESERVED;
> +                    next_e820_entry_index++;
> +                    continue;
> +                }
> +
> +                /* If we're just in of one RAM range */
> +                if ( rdm_start > start && rdm_end < end )
> +                {
> +                    memmove(&e820[j+2], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j+2].addr = rdm_end;
> +                    e820[j+2].size = e820[j].addr + e820[j].size - rdm_end;
> +                    e820[j+2].type = E820_RAM;
> +                    next_e820_entry_index++;
> +
> +                    e820[j+1].addr = rdm_start;
> +                    e820[j+1].size = rdm_end - rdm_start;
> +                    e820[j+1].type = E820_RESERVED;
> +                    next_e820_entry_index++;
> +
> +                    e820[j].size = rdm_start - e820[j].addr;
> +                    e820[j].type = E820_RAM;
> +                    continue;
> +                }
> +
> +                /* If we're going last RAM:Hole range */
> +                if ( end < next_start && rdm_start > start &&
> +                     rdm_end < next_start )
> +                {
> +                    memmove(&e820[j+1], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j].size = rdm_start - e820[j].addr;
> +                    e820[j].type = E820_RAM;
> +
> +                    e820[j+1].addr = rdm_start;
> +                    e820[j+1].size = rdm_end - rdm_start;
> +                    e820[j+1].type = E820_RESERVED;
> +                    next_e820_entry_index++;
> +                    continue;
> +                }
> +            }
> +        }
> +    }
> +
> +    /* These overlap may issue guest can't work well. */
> +    if ( err )
> +    {
> +        printf("Guest can't work with some reserved device memory overlap!\n");
> +        BUG();
> +    }
> +
> +    /* Fine to construct RDM mappings into e820. */
> +    return next_e820_entry_index;
> +}
> +
>  /* Create an E820 table based on memory parameters provided in hvm_info. */
>  int build_e820_table(struct e820entry *e820,
>                       unsigned int lowmem_reserved_base,
>                       unsigned int bios_image_base)
>  {
>      unsigned int nr = 0;
> +    unsigned int nr_entries = 0;
>  
>      if ( !lowmem_reserved_base )
>              lowmem_reserved_base = 0xA0000;
> @@ -169,6 +331,12 @@ int build_e820_table(struct e820entry *e820,
>          nr++;
>      }
>  
> +    nr_entries = hvm_get_reserved_device_memory_map();
> +    if ( nr_entries )
> +        nr = construct_rdm_e820_maps(nr, nr_entries, rdm_map, e820,
> +                                     lowmem_reserved_base,
> +                                     bios_image_base);
> +
>      return nr;
>  }
>  
> -- 
> 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 Dec 02 20:18:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1XvttY-0000Ny-CI; Tue, 02 Dec 2014 20:18:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvttX-0000Nt-Gx
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:17:59 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B8/17-22737-67E1E745; Tue, 02 Dec 2014 20:17:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417551476!7799812!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11503 invoked from network); 2 Dec 2014 20:17:57 -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; 2 Dec 2014 20:17:57 -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 sB2KHmmG019052
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:17:49 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
	sB2KHjZU022140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:17:45 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
	sB2KHijh000781; Tue, 2 Dec 2014 20:17:44 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:17:44 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7E83211B142; Tue,  2 Dec 2014 15:17:44 -0500 (EST)
Date: Tue, 2 Dec 2014 15:17:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202201744.GH357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 09/17] 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 Mon, Dec 01, 2014 at 05:24:27PM +0800, Tiejun Chen wrote:
> We need to check to reserve all reserved device memory maps in e820
> to avoid any potential guest memory conflict.
> 
> Currently, if we can't insert RDM entries directly, we may need to handle
> several ranges as follows:

s/several/two/

s/follows/follow/

> a. Fixed Ranges --> BUG()
>  lowmem_reserved_base-0xA0000: reserved by BIOS implementation,
>  BIOS region,
>  RESERVED_MEMBASE ~ 0x100000000,

I am not sure what you are trying to say here. Could you explain it 
a bit more please?

> b. RAM or RAM:Hole -> Try to reserve

Reading the beginning of the 'Currently'.. this says:

we may need to handle RAM or RAM:Hole -> Try to reserve.

I don't know what 'RAM:Hole' means. And instead of using '->' you can
say: we will try to reserve.

But what are we reserving ? Are we reserving it as an E820_RSV or just
as an hole? What about the RAM behind it? Are we gulping up the RAM regions
(as in losing them) or are we moving the RAM regions (GPFNs) to somewhere else?

> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/e820.c | 168 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 168 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
> index 2e05e93..ef87e41 100644
> --- a/tools/firmware/hvmloader/e820.c
> +++ b/tools/firmware/hvmloader/e820.c
> @@ -22,6 +22,7 @@
>  
>  #include "config.h"
>  #include "util.h"
> +#include <xen/memory.h>
>  
>  void dump_e820_table(struct e820entry *e820, unsigned int nr)
>  {
> @@ -68,12 +69,173 @@ void dump_e820_table(struct e820entry *e820, unsigned int nr)
>      }
>  }
>  
> +extern struct xen_reserved_device_memory *rdm_map;
> +static unsigned int construct_rdm_e820_maps(unsigned int next_e820_entry_index,

s/next_e820_entry_index/next_entry/ ?

> +                                            uint32_t nr_map,
> +                                            struct xen_reserved_device_memory *map,
> +                                            struct e820entry *e820,
> +                                            unsigned int lowmem_reserved_base,
> +                                            unsigned int bios_image_base)
> +{
> +    unsigned int i, j, sum_nr;
> +    uint64_t start, end, next_start, rdm_start, rdm_end;
> +    uint32_t type;
> +    int err = 0;
> +
> +    for ( i = 0; i < nr_map; i++ )
> +    {
> +        rdm_start = (uint64_t)map[i].start_pfn << PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)map[i].nr_pages << PAGE_SHIFT);
> +
> +        for ( j = 0; j < next_e820_entry_index - 1; j++ )
> +        {
> +            sum_nr = next_e820_entry_index + nr_map;
> +            start = e820[j].addr;
> +            end = e820[j].addr + e820[j].size;
> +            type = e820[j].type;
> +            next_start = e820[j+1].addr;
> +
> +            if ( rdm_start >= start && rdm_start <= end )
> +            {
> +                /*
> +                 * lowmem_reserved_base-0xA0000: reserved by BIOS
> +                 * implementation.
> +                 * Or BIOS region.
> +                 */
> +                if ( (lowmem_reserved_base < 0xA0000 &&
> +                        start == lowmem_reserved_base) ||
> +                     start == bios_image_base )

something is off with your spaces.
> +                {
> +                    err = -1;
> +                    break;

Keep in mind we will just break out of this loop. Do you want to add
at the end of this loop:


if (err)
	break;

> +                }
> +            }
> +
> +            /* Just amid those remaining e820 entries. */
> +            if ( (rdm_start > end) && (rdm_end < next_start) )
> +            {
> +                memmove(&e820[j+2], &e820[j+1],
> +                        (sum_nr - j - 1) * sizeof(struct e820entry));

What if there is something at j+2? Should we have an
j-2 < E820_MAX check somewhere?

This whole 'memmove' logic is making me a bit worried.

Would it be easier to have this logic inside build_e820_table so
that it could construct the e820 with this information right away?

Or if that was deemed incorrect could you explain that in the
commit description?

> +
> +                /* Then fill RMRR into that entry. */
> +                e820[j+1].addr = rdm_start;
> +                e820[j+1].size = rdm_end - rdm_start;
> +                e820[j+1].type = E820_RESERVED;
> +                next_e820_entry_index++;
> +                continue;
> +            }
> +
> +            /* Already at the end. */
> +            if ( (rdm_start > end) && !next_start )
> +            {
> +                e820[next_e820_entry_index].addr = rdm_start;
> +                e820[next_e820_entry_index].size = rdm_end - rdm_start;
> +                e820[next_e820_entry_index].type = E820_RESERVED;
> +                next_e820_entry_index++;
> +                continue;
> +            }
> +
> +            if ( type == E820_RAM )
> +            {
> +                /* If coincide with one RAM range. */
> +                if ( rdm_start == start && rdm_end == end)
> +                {
> +                    e820[j].type = E820_RESERVED;
> +                    continue;
> +                }
> +
> +                /* If we're just aligned with start of one RAM range. */
> +                if ( rdm_start == start && rdm_end < end )
> +                {
> +                    memmove(&e820[j+1], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j+1].addr = rdm_end;
> +                    e820[j+1].size = e820[j].addr + e820[j].size - rdm_end;
> +                    e820[j+1].type = E820_RAM;
> +                    next_e820_entry_index++;
> +
> +                    e820[j].addr = rdm_start;
> +                    e820[j].size = rdm_end - rdm_start;
> +                    e820[j].type = E820_RESERVED;
> +                    continue;
> +                }
> +
> +                /* If we're just aligned with end of one RAM range. */
> +                if ( rdm_start > start && rdm_end == end )
> +                {
> +                    memmove(&e820[j+1], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j].size = rdm_start - e820[j].addr;
> +                    e820[j].type = E820_RAM;
> +
> +                    e820[j+1].addr = rdm_start;
> +                    e820[j+1].size = rdm_end - rdm_start;
> +                    e820[j+1].type = E820_RESERVED;
> +                    next_e820_entry_index++;
> +                    continue;
> +                }
> +
> +                /* If we're just in of one RAM range */
> +                if ( rdm_start > start && rdm_end < end )
> +                {
> +                    memmove(&e820[j+2], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j+2].addr = rdm_end;
> +                    e820[j+2].size = e820[j].addr + e820[j].size - rdm_end;
> +                    e820[j+2].type = E820_RAM;
> +                    next_e820_entry_index++;
> +
> +                    e820[j+1].addr = rdm_start;
> +                    e820[j+1].size = rdm_end - rdm_start;
> +                    e820[j+1].type = E820_RESERVED;
> +                    next_e820_entry_index++;
> +
> +                    e820[j].size = rdm_start - e820[j].addr;
> +                    e820[j].type = E820_RAM;
> +                    continue;
> +                }
> +
> +                /* If we're going last RAM:Hole range */
> +                if ( end < next_start && rdm_start > start &&
> +                     rdm_end < next_start )
> +                {
> +                    memmove(&e820[j+1], &e820[j],
> +                            (sum_nr - j) * sizeof(struct e820entry));
> +
> +                    e820[j].size = rdm_start - e820[j].addr;
> +                    e820[j].type = E820_RAM;
> +
> +                    e820[j+1].addr = rdm_start;
> +                    e820[j+1].size = rdm_end - rdm_start;
> +                    e820[j+1].type = E820_RESERVED;
> +                    next_e820_entry_index++;
> +                    continue;
> +                }
> +            }
> +        }
> +    }
> +
> +    /* These overlap may issue guest can't work well. */
> +    if ( err )
> +    {
> +        printf("Guest can't work with some reserved device memory overlap!\n");
> +        BUG();
> +    }
> +
> +    /* Fine to construct RDM mappings into e820. */
> +    return next_e820_entry_index;
> +}
> +
>  /* Create an E820 table based on memory parameters provided in hvm_info. */
>  int build_e820_table(struct e820entry *e820,
>                       unsigned int lowmem_reserved_base,
>                       unsigned int bios_image_base)
>  {
>      unsigned int nr = 0;
> +    unsigned int nr_entries = 0;
>  
>      if ( !lowmem_reserved_base )
>              lowmem_reserved_base = 0xA0000;
> @@ -169,6 +331,12 @@ int build_e820_table(struct e820entry *e820,
>          nr++;
>      }
>  
> +    nr_entries = hvm_get_reserved_device_memory_map();
> +    if ( nr_entries )
> +        nr = construct_rdm_e820_maps(nr, nr_entries, rdm_map, e820,
> +                                     lowmem_reserved_base,
> +                                     bios_image_base);
> +
>      return nr;
>  }
>  
> -- 
> 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 Dec 02 20:19:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1Xvtue-0000Rd-Qk; Tue, 02 Dec 2014 20:19:08 +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 1Xvtud-0000RS-Pe
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:19:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E8/90-15461-BBE1E745; Tue, 02 Dec 2014 20:19:07 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417551545!12928076!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1049 invoked from network); 2 Dec 2014 20:19:06 -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; 2 Dec 2014 20:19: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 sB2KJ00X020240
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:19:00 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
	sB2KIxCb004332
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 20:18: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
	sB2KIw91019166; Tue, 2 Dec 2014 20:18:58 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:18:57 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Date: Tue,  2 Dec 2014 15:19:13 -0500
Message-Id: <1417551553-22234-3-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
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 v4 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               | 16 +++++++
 2 files changed, 107 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..37914ef 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,20 @@ int __init pci_xen_init(void)
 #ifdef CONFIG_PCI_MSI
 void __init xen_msi_init(void)
 {
+	if (!disable_apic) {
+		/*
+		 * If hardware supports (x2)APIC virtualization (as indicated
+		 * by hypervisor's leaf 4) then we don't need to use pirqs/
+		 * event channels for MSI handling and instead use regular
+		 * APIC processing
+		 */
+		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.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 Tue Dec 02 20:19:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1Xvtue-0000Rd-Qk; Tue, 02 Dec 2014 20:19:08 +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 1Xvtud-0000RS-Pe
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:19:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E8/90-15461-BBE1E745; Tue, 02 Dec 2014 20:19:07 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417551545!12928076!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1049 invoked from network); 2 Dec 2014 20:19:06 -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; 2 Dec 2014 20:19: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 sB2KJ00X020240
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:19:00 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
	sB2KIxCb004332
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 20:18: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
	sB2KIw91019166; Tue, 2 Dec 2014 20:18:58 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:18:57 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Date: Tue,  2 Dec 2014 15:19:13 -0500
Message-Id: <1417551553-22234-3-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
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 v4 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               | 16 +++++++
 2 files changed, 107 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..37914ef 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,20 @@ int __init pci_xen_init(void)
 #ifdef CONFIG_PCI_MSI
 void __init xen_msi_init(void)
 {
+	if (!disable_apic) {
+		/*
+		 * If hardware supports (x2)APIC virtualization (as indicated
+		 * by hypervisor's leaf 4) then we don't need to use pirqs/
+		 * event channels for MSI handling and instead use regular
+		 * APIC processing
+		 */
+		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.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 Tue Dec 02 20:19:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvtuh-0000SX-6q; Tue, 02 Dec 2014 20:19:11 +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 1Xvtuf-0000Rp-SO
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:19:09 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	13/5D-11608-CBE1E745; Tue, 02 Dec 2014 20:19:08 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417551546!15401769!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31437 invoked from network); 2 Dec 2014 20:19:08 -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; 2 Dec 2014 20:19:08 -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 sB2KJ1Fv013592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:19:02 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
	sB2KJ0CM004390
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 20:19:01 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
	sB2KIx2G019229; Tue, 2 Dec 2014 20:19:00 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:18:57 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Date: Tue,  2 Dec 2014 15:19:12 -0500
Message-Id: <1417551553-22234-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
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 v4 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>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.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.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 Tue Dec 02 20:19:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvtuh-0000SX-6q; Tue, 02 Dec 2014 20:19:11 +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 1Xvtuf-0000Rp-SO
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:19:09 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	13/5D-11608-CBE1E745; Tue, 02 Dec 2014 20:19:08 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417551546!15401769!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31437 invoked from network); 2 Dec 2014 20:19:08 -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; 2 Dec 2014 20:19:08 -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 sB2KJ1Fv013592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:19:02 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
	sB2KJ0CM004390
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 20:19:01 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
	sB2KIx2G019229; Tue, 2 Dec 2014 20:19:00 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:18:57 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Date: Tue,  2 Dec 2014 15:19:12 -0500
Message-Id: <1417551553-22234-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
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 v4 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>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.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.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 Tue Dec 02 20:19:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvtuh-0000T5-MQ; Tue, 02 Dec 2014 20:19:11 +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 1Xvtug-0000Rs-45
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:19:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6F/03-09842-DBE1E745; Tue, 02 Dec 2014 20:19:09 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417551544!12984900!1
X-Originating-IP: [156.151.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 864 invoked from network); 2 Dec 2014 20:19:05 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 20:19:05 -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 sB2KIvPr013521
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:18: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
	sB2KIviw025518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:18:57 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
	sB2KIufj004273; Tue, 2 Dec 2014 20:18:56 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:18:56 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Date: Tue,  2 Dec 2014 15:19:11 -0500
Message-Id: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
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 v4 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 v4:
* Added comment describing what we check for in pci_xen_init()

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               | 31 +++++++++++++-
 2 files changed, 120 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/include/asm/xen/cpuid.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 Tue Dec 02 20:19:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvtuh-0000T5-MQ; Tue, 02 Dec 2014 20:19:11 +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 1Xvtug-0000Rs-45
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:19:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6F/03-09842-DBE1E745; Tue, 02 Dec 2014 20:19:09 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417551544!12984900!1
X-Originating-IP: [156.151.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 864 invoked from network); 2 Dec 2014 20:19:05 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Dec 2014 20:19:05 -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 sB2KIvPr013521
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:18: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
	sB2KIviw025518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:18:57 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
	sB2KIufj004273; Tue, 2 Dec 2014 20:18:56 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:18:56 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com,
	stefano.stabellini@eu.citrix.com
Date: Tue,  2 Dec 2014 15:19:11 -0500
Message-Id: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
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 v4 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 v4:
* Added comment describing what we check for in pci_xen_init()

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               | 31 +++++++++++++-
 2 files changed, 120 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/include/asm/xen/cpuid.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 Tue Dec 02 20:22:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvtxu-0000wA-K8; Tue, 02 Dec 2014 20:22:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xvtxs-0000vt-Ip
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 20:22:28 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	8C/5C-02707-38F1E745; Tue, 02 Dec 2014 20:22:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417551745!7800254!1
X-Originating-IP: [66.165.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 27355 invoked from network); 2 Dec 2014 20:22:26 -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;
	2 Dec 2014 20:22:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,503,1413244800"; d="scan'208";a="199073564"
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, 2 Dec 2014 15:22: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 1Xvtxn-0004ZF-HW;
	Tue, 02 Dec 2014 20:22:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xvtxn-0004or-Al;
	Tue, 02 Dec 2014 20:22:23 +0000
Date: Tue, 2 Dec 2014 20:22:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31986-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] 31986: 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 31986 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31986/

Failures :-/ but no regressions.

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

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

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-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
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31963 never pass

version targeted for testing:
 xen                  188336bb86d0992a2a034ece5f39eccc5d10f337
baseline version:
 xen                  188336bb86d0992a2a034ece5f39eccc5d10f337

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                         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


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 Dec 02 20:22:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvtxu-0000wA-K8; Tue, 02 Dec 2014 20:22:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xvtxs-0000vt-Ip
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 20:22:28 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	8C/5C-02707-38F1E745; Tue, 02 Dec 2014 20:22:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417551745!7800254!1
X-Originating-IP: [66.165.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 27355 invoked from network); 2 Dec 2014 20:22:26 -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;
	2 Dec 2014 20:22:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,503,1413244800"; d="scan'208";a="199073564"
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, 2 Dec 2014 15:22: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 1Xvtxn-0004ZF-HW;
	Tue, 02 Dec 2014 20:22:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xvtxn-0004or-Al;
	Tue, 02 Dec 2014 20:22:23 +0000
Date: Tue, 2 Dec 2014 20:22:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31986-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] 31986: 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 31986 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31986/

Failures :-/ but no regressions.

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

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

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-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
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31963 never pass

version targeted for testing:
 xen                  188336bb86d0992a2a034ece5f39eccc5d10f337
baseline version:
 xen                  188336bb86d0992a2a034ece5f39eccc5d10f337

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                         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


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 Dec 02 20:23:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvtz0-00019O-EO; Tue, 02 Dec 2014 20:23: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 1Xvtyz-00019E-Kd
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:23:37 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	83/BB-26858-8CF1E745; Tue, 02 Dec 2014 20:23:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417551814!15310554!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12324 invoked from network); 2 Dec 2014 20:23:36 -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; 2 Dec 2014 20:23:36 -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 sB2KNChW018595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:23:13 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
	sB2KNAf7008279
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:23:11 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
	sB2KNAd9016751; Tue, 2 Dec 2014 20:23:10 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:23:10 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4BFBE11B155; Tue,  2 Dec 2014 15:23:10 -0500 (EST)
Date: Tue, 2 Dec 2014 15:23:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202202310.GI357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip
 any overlap with reserved device 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, Dec 01, 2014 at 05:24:28PM +0800, Tiejun Chen wrote:
> In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
> to allocate some memory to use in runtime cycle, so we alsoe need to

s/cycle//

s/alsoe/also

> make sure all reserved device memory don't overlap such a region.

s/such a/with such/
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/util.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 8767897..f3723c7 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -416,9 +416,29 @@ static uint32_t alloc_down = RESERVED_MEMORY_DYNAMIC_END;
>  
>  xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
>  {
> +    unsigned int i, num = hvm_get_reserved_device_memory_map();
> +    uint64_t rdm_start, rdm_end;
> +    uint32_t alloc_start, alloc_end;
> +
>      alloc_down -= nr_mfns << PAGE_SHIFT;
> +    alloc_start = alloc_down;
> +    alloc_end = alloc_start + (nr_mfns << PAGE_SHIFT);
> +    for ( i = 0; i < num; i++ )
> +    {
> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << PAGE_SHIFT);
> +        if ( check_rdm_hole_conflict((uint64_t)alloc_start,
> +                                     (uint64_t)alloc_end,
> +                                     rdm_start, rdm_end - rdm_start) )
> +        {
> +            alloc_end = rdm_start;
> +            alloc_start = alloc_end - (nr_mfns << PAGE_SHIFT);
> +            BUG_ON(alloc_up >= alloc_start);
> +        }
> +    }
> +
>      BUG_ON(alloc_up >= alloc_down);
> -    return alloc_down >> PAGE_SHIFT;
> +    return alloc_start >> PAGE_SHIFT;
>  }
>  
>  void *mem_alloc(uint32_t size, uint32_t align)
> -- 
> 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 Dec 02 20:23:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvtyx-00018y-28; Tue, 02 Dec 2014 20:23:35 +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 1Xvtyw-00018r-B6
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 20:23:34 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	7E/7E-26652-5CF1E745; Tue, 02 Dec 2014 20:23:33 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417551811!11171338!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16822 invoked from network); 2 Dec 2014 20:23:32 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2014 20:23: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=1417551812; x=1449087812;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=e+btiN+KQFvNcrdPJjkEoqzYn18x7med9CMAmMquHwc=;
	b=OwdMCRASudoXpRi8kDCK60bBGh4D3n4gAvnriYELEvB0EV5jeb4KnmX9
	3AcBnA85SIJzA78xmAFPVgZm8aLD+NLYNTkCjlz8j3NLCoucrm4MEbKCt
	PqTso/U6j7brco9qcdKiyBvOgU4mtOGMT/T6D4j3y4jMJ5VBNy9CSDCPF 4=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 02 Dec 2014 20:23:30 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,503,1413244800"; d="scan'208";a="883875036"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.109.197])
	by fldsmtpi03.verizon.com with ESMTP; 02 Dec 2014 20:23:29 +0000
Message-ID: <547E1FC1.70004@terremark.com>
Date: Tue, 02 Dec 2014 15:23: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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Don Slutz <dslutz@verizon.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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412021158210.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 12/02/14 07:26, Stefano Stabellini wrote:
> On Mon, 1 Dec 2014, Don Slutz wrote:
>> On 12/01/14 10:37, Stefano Stabellini wrote:
>>> On Mon, 1 Dec 2014, Don Slutz wrote:
>>>> On 11/27/14 05:48, Stefano Stabellini wrote:
>> [...]
>>
>>>> Works fine in both claim modes and with PoD used (maxmem > memory).  Do
>>>> not know how to test with tmem.  I do not see how it would be worse then
>>>> current
>>>> code that does not auto increase.  I.E. even without a xen change, I think
>>>> something
>>>> like this could be done.
>>> OK, good to know. I am OK with increasing maxmem only if it is strictly
>>> necessary.
>>>
>>>
>>>>>> 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.
>>>> Ok.  I did find the 32 it is VGA_HOLE_SIZE.  So here is what I have which
>>>> includes
>>>> a lot of extra printf.
>>> In QEMU I would prefer not to assume that libxl increased maxmem for the
>>> vga hole. I would rather call xc_domain_setmaxmem twice for the vga hole
>>> than tie QEMU to a particular maxmem allocation scheme in libxl.
>> Ok.  The area we are talking about is 0x000a0000 to 0x000c0000.
>> It is in libxc (xc_hvm_build_x86), not libxl.   I have no issue with a name
>> change to
>> some thing like QEMU_EXTRA_FREE_PAGES.
> Sorry, I was thinking about the relocated videoram region, the one
> allocated by xen_add_to_physmap in QEMU.
>
> Regarding 0x000a0000-0x000c0000, according to this comment:
>
>      /*
>       * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
>       *
>
> xc_hvm_build_x86 shouldn't be allocating memory for it.
> In fact if I remember correctly 0xa0000-0xc0000 is trapped and emulated.
>

Clearly I am not writing clear enough statements.

xc_hvm_build_x86 is not allocating memory for it.  libxl__build_pre() sets
maxmem via xc_domain_setmaxmem().  Then xc_hvm_build_x86 allocates
memory skipping the VGA hole 0xA0000-0xC0000. So difference between
maxmem (max_pages, xlinfo->max_memkb) and tot_pages 
(xlinfo->current_memkb) is videoram + LIBXL_MAXMEM_CONSTANT + 32
(I.E. what VGA_HOLE_SIZE is definded as).


>> My testing has shows that some of these 32 pages are used outside of QEMU.
>> I am seeing just 23 free pages using a standalone program to display
>> the same info after a CentOS 6.3 guest is done booting.
>>
>>> In libxl I would like to avoid increasing mamxem for anything QEMU will
>>> allocate later, that includes rom and vga vram. I am not sure how to
>>> make that work with older QEMU versions that don't call
>>> xc_domain_setmaxmem by themselves yet though. Maybe we could check the
>>> specific QEMU version in libxl and decide based on that. Or we could
>>> export a feature flag in QEMU.
>> Yes, it would be nice to adjust libxl to not increase maxmem. However since
>> videoram is included in memory (and maxmem), making the change related
>> to vram is a bigger issue.
>>
>> the rom change is much simpler.
>>
>> Currently I do not know of a way to do different things based on the QEMU
>> version
>> and/or features (this includes getting the QEMU version in libxl).
>>
>> I have been going with:
>> 1) change QEMU 1st.
>> 2) Wait for an upstream version of QEMU with this.
>> 3) change xen to optionally use a feature in the latest QEMU.
> Let's try to take this approach for the videoram too

Ok.

>
>>>> --- a/xen-hvm.c
>>>> +++ b/xen-hvm.c
>>>> @@ -67,6 +67,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t
>>>> *shared_page, int vcpu)
>>>>    #endif
>>>>
>>>>    #define BUFFER_IO_MAX_DELAY  100
>>>> +#define VGA_HOLE_SIZE (0x20)
>>>>
>>>>    typedef struct XenPhysmap {
>>>>        hwaddr start_addr;
>>>> @@ -219,6 +220,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t
>>>> size,
>>>> MemoryRegion *mr)
>>>>        xen_pfn_t *pfn_list;
>>>>        int i;
>>>>        xc_dominfo_t info;
>>>> +    unsigned long max_pages, free_pages, real_free;
>>>> +    long need_pages;
>>>> +    uint64_t tot_pages, pod_cache_pages, pod_entries;
>>>> +
>>>> +    trace_xen_ram_alloc(ram_addr, size, mr->name);
>>>>
>>>>        if (runstate_check(RUN_STATE_INMIGRATE)) {
>>>>            /* RAM already populated in Xen */
>>>> @@ -232,13 +238,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t
>>>> size,
>>>> MemoryRegion *mr)
>>>>            return;
>>>>        }
>>>>
>>>> -    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
>>>> -            " bytes (%ld Kib) of ram at "RAM_ADDR_FMT
>>>> -            " mr.name=%s\n",
>>>> -            __func__, size, (long)(size>>10), ram_addr, mr->name);
>>>> -
>>>> -    trace_xen_ram_alloc(ram_addr, size);
>>>> -
>>>>        nr_pfn = size >> TARGET_PAGE_BITS;
>>>>        pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
>>>>
>>>> @@ -246,11 +245,38 @@ 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) {
>>>> +    if ((xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) ||
> I think it's best to call xc_domain_getinfolist.
>

Will switch.

>>>> +       (info.domid != xen_domid)) {
>>>>            hw_error("xc_domain_getinfo failed");
>>>>        }
>>>> -    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;
>>>> +    real_free = free_pages;
>>>> +    if (free_pages > VGA_HOLE_SIZE) {
>>>> +        free_pages -= VGA_HOLE_SIZE;
>>>> +    } else {
>>>> +        free_pages = 0;
>>>> +    }
> I don't think we need to subtract VGA_HOLE_SIZE.

If you do not use some slack (like 32 here), xen does report:


(d5) [2014-11-29 17:07:21] Loaded SeaBIOS
(d5) [2014-11-29 17:07:21] Creating MP tables ...
(d5) [2014-11-29 17:07:21] Loading ACPI ...
(XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for 
domain 5: 1057417 > 1057416
(XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0 
extent: id=5 memflags=0 (0 of 1)
(d5) [2014-11-29 17:07:21] vm86 TSS at 00098c00
(d5) [2014-11-29 17:07:21] BIOS map:


However while QEMU startup ends with 32 "free" pages (maxmem - curmem)
this quickly changes to 23.  I.E. there are 7 more places that act like 
a call
to xc_domain_populate_physmap_exact() but do not log errors if there is
no free pages.  And just to make sure I do not fully understand what is
happening here, after the message above, the domain appears to work
fine and ends up with 8 "free" pages (code I do not know about ends up
releasing populated pages).

So my current thinking is to have QEMU leave a few (9 to 32 (64?)) pages 
"free".


>
>>>> +    need_pages = nr_pfn - free_pages;
>>>> +    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
>>>> +            " bytes (%ld KiB) of ram at "RAM_ADDR_FMT
>>>> +            " mp=%ld fp=%ld nr=%ld need=%ld mr.name=%s\n",
>>>> +            __func__, size, (long)(size>>10), ram_addr,
>>>> +           max_pages, free_pages, nr_pfn, need_pages,
>>>> +            mr->name);
>>>> +    if (xc_domain_get_pod_target(xen_xc, xen_domid, &tot_pages,
>>>> +                                 &pod_cache_pages, &pod_entries) >= 0) {
>>>> +        unsigned long populated = tot_pages - pod_cache_pages;
>>>> +        long delta_tot = tot_pages - info.nr_pages;
>>>> +
>>>> +        fprintf(stderr, "%s: PoD pop=%ld tot=%ld(%ld) cnt=%ld ent=%ld
>>>> nop=%ld
>>>> free=%ld\n",
>>>> +                __func__, populated, (long)tot_pages, delta_tot,
>>>> +                (long)pod_cache_pages, (long)pod_entries,
>>>> +               (long)info.nr_outstanding_pages, real_free);
>>>> +    }
>>> What is the purpose of calling xc_domain_get_pod_target here? It doesn't
>>> look like is affecting the parameters passed to xc_domain_setmaxmem.
>> This was just to test and see if anything was needed for PoD mode.
>> I did not see anything.
>>
>> Did you want me to make a patch to send to the list that has my proposed
>> changes?
> Yep, that's fine.
>
>
>> I do think that what I have would be fine to do since most of the time the
>> new code does nothing with the current xen (and older versions), until
>> more then 4 nics are configured for xen.
>>
>> It would be good to have the change:
>>
>> [PATCH] libxl_set_memory_target: retain the same maxmem offset on top of the
>> current target
>>
>> (When working) in xen before using a QEMU with this change.
>>
>> Not sure I would push for 2.2 however.
> I wouldn't.
>

Will mark as for 2.3

    -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 Dec 02 20:23:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvtz0-00019O-EO; Tue, 02 Dec 2014 20:23: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 1Xvtyz-00019E-Kd
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:23:37 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	83/BB-26858-8CF1E745; Tue, 02 Dec 2014 20:23:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417551814!15310554!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12324 invoked from network); 2 Dec 2014 20:23:36 -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; 2 Dec 2014 20:23:36 -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 sB2KNChW018595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:23:13 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
	sB2KNAf7008279
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:23:11 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
	sB2KNAd9016751; Tue, 2 Dec 2014 20:23:10 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:23:10 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4BFBE11B155; Tue,  2 Dec 2014 15:23:10 -0500 (EST)
Date: Tue, 2 Dec 2014 15:23:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202202310.GI357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip
 any overlap with reserved device 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, Dec 01, 2014 at 05:24:28PM +0800, Tiejun Chen wrote:
> In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
> to allocate some memory to use in runtime cycle, so we alsoe need to

s/cycle//

s/alsoe/also

> make sure all reserved device memory don't overlap such a region.

s/such a/with such/
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  tools/firmware/hvmloader/util.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 8767897..f3723c7 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -416,9 +416,29 @@ static uint32_t alloc_down = RESERVED_MEMORY_DYNAMIC_END;
>  
>  xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
>  {
> +    unsigned int i, num = hvm_get_reserved_device_memory_map();
> +    uint64_t rdm_start, rdm_end;
> +    uint32_t alloc_start, alloc_end;
> +
>      alloc_down -= nr_mfns << PAGE_SHIFT;
> +    alloc_start = alloc_down;
> +    alloc_end = alloc_start + (nr_mfns << PAGE_SHIFT);
> +    for ( i = 0; i < num; i++ )
> +    {
> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << PAGE_SHIFT);
> +        if ( check_rdm_hole_conflict((uint64_t)alloc_start,
> +                                     (uint64_t)alloc_end,
> +                                     rdm_start, rdm_end - rdm_start) )
> +        {
> +            alloc_end = rdm_start;
> +            alloc_start = alloc_end - (nr_mfns << PAGE_SHIFT);
> +            BUG_ON(alloc_up >= alloc_start);
> +        }
> +    }
> +
>      BUG_ON(alloc_up >= alloc_down);
> -    return alloc_down >> PAGE_SHIFT;
> +    return alloc_start >> PAGE_SHIFT;
>  }
>  
>  void *mem_alloc(uint32_t size, uint32_t align)
> -- 
> 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 Dec 02 20:23:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvtyx-00018y-28; Tue, 02 Dec 2014 20:23:35 +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 1Xvtyw-00018r-B6
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 20:23:34 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	7E/7E-26652-5CF1E745; Tue, 02 Dec 2014 20:23:33 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417551811!11171338!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16822 invoked from network); 2 Dec 2014 20:23:32 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Dec 2014 20:23: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=1417551812; x=1449087812;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=e+btiN+KQFvNcrdPJjkEoqzYn18x7med9CMAmMquHwc=;
	b=OwdMCRASudoXpRi8kDCK60bBGh4D3n4gAvnriYELEvB0EV5jeb4KnmX9
	3AcBnA85SIJzA78xmAFPVgZm8aLD+NLYNTkCjlz8j3NLCoucrm4MEbKCt
	PqTso/U6j7brco9qcdKiyBvOgU4mtOGMT/T6D4j3y4jMJ5VBNy9CSDCPF 4=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 02 Dec 2014 20:23:30 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,503,1413244800"; d="scan'208";a="883875036"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.109.197])
	by fldsmtpi03.verizon.com with ESMTP; 02 Dec 2014 20:23:29 +0000
Message-ID: <547E1FC1.70004@terremark.com>
Date: Tue, 02 Dec 2014 15:23: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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Don Slutz <dslutz@verizon.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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412021158210.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 12/02/14 07:26, Stefano Stabellini wrote:
> On Mon, 1 Dec 2014, Don Slutz wrote:
>> On 12/01/14 10:37, Stefano Stabellini wrote:
>>> On Mon, 1 Dec 2014, Don Slutz wrote:
>>>> On 11/27/14 05:48, Stefano Stabellini wrote:
>> [...]
>>
>>>> Works fine in both claim modes and with PoD used (maxmem > memory).  Do
>>>> not know how to test with tmem.  I do not see how it would be worse then
>>>> current
>>>> code that does not auto increase.  I.E. even without a xen change, I think
>>>> something
>>>> like this could be done.
>>> OK, good to know. I am OK with increasing maxmem only if it is strictly
>>> necessary.
>>>
>>>
>>>>>> 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.
>>>> Ok.  I did find the 32 it is VGA_HOLE_SIZE.  So here is what I have which
>>>> includes
>>>> a lot of extra printf.
>>> In QEMU I would prefer not to assume that libxl increased maxmem for the
>>> vga hole. I would rather call xc_domain_setmaxmem twice for the vga hole
>>> than tie QEMU to a particular maxmem allocation scheme in libxl.
>> Ok.  The area we are talking about is 0x000a0000 to 0x000c0000.
>> It is in libxc (xc_hvm_build_x86), not libxl.   I have no issue with a name
>> change to
>> some thing like QEMU_EXTRA_FREE_PAGES.
> Sorry, I was thinking about the relocated videoram region, the one
> allocated by xen_add_to_physmap in QEMU.
>
> Regarding 0x000a0000-0x000c0000, according to this comment:
>
>      /*
>       * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
>       *
>
> xc_hvm_build_x86 shouldn't be allocating memory for it.
> In fact if I remember correctly 0xa0000-0xc0000 is trapped and emulated.
>

Clearly I am not writing clear enough statements.

xc_hvm_build_x86 is not allocating memory for it.  libxl__build_pre() sets
maxmem via xc_domain_setmaxmem().  Then xc_hvm_build_x86 allocates
memory skipping the VGA hole 0xA0000-0xC0000. So difference between
maxmem (max_pages, xlinfo->max_memkb) and tot_pages 
(xlinfo->current_memkb) is videoram + LIBXL_MAXMEM_CONSTANT + 32
(I.E. what VGA_HOLE_SIZE is definded as).


>> My testing has shows that some of these 32 pages are used outside of QEMU.
>> I am seeing just 23 free pages using a standalone program to display
>> the same info after a CentOS 6.3 guest is done booting.
>>
>>> In libxl I would like to avoid increasing mamxem for anything QEMU will
>>> allocate later, that includes rom and vga vram. I am not sure how to
>>> make that work with older QEMU versions that don't call
>>> xc_domain_setmaxmem by themselves yet though. Maybe we could check the
>>> specific QEMU version in libxl and decide based on that. Or we could
>>> export a feature flag in QEMU.
>> Yes, it would be nice to adjust libxl to not increase maxmem. However since
>> videoram is included in memory (and maxmem), making the change related
>> to vram is a bigger issue.
>>
>> the rom change is much simpler.
>>
>> Currently I do not know of a way to do different things based on the QEMU
>> version
>> and/or features (this includes getting the QEMU version in libxl).
>>
>> I have been going with:
>> 1) change QEMU 1st.
>> 2) Wait for an upstream version of QEMU with this.
>> 3) change xen to optionally use a feature in the latest QEMU.
> Let's try to take this approach for the videoram too

Ok.

>
>>>> --- a/xen-hvm.c
>>>> +++ b/xen-hvm.c
>>>> @@ -67,6 +67,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t
>>>> *shared_page, int vcpu)
>>>>    #endif
>>>>
>>>>    #define BUFFER_IO_MAX_DELAY  100
>>>> +#define VGA_HOLE_SIZE (0x20)
>>>>
>>>>    typedef struct XenPhysmap {
>>>>        hwaddr start_addr;
>>>> @@ -219,6 +220,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t
>>>> size,
>>>> MemoryRegion *mr)
>>>>        xen_pfn_t *pfn_list;
>>>>        int i;
>>>>        xc_dominfo_t info;
>>>> +    unsigned long max_pages, free_pages, real_free;
>>>> +    long need_pages;
>>>> +    uint64_t tot_pages, pod_cache_pages, pod_entries;
>>>> +
>>>> +    trace_xen_ram_alloc(ram_addr, size, mr->name);
>>>>
>>>>        if (runstate_check(RUN_STATE_INMIGRATE)) {
>>>>            /* RAM already populated in Xen */
>>>> @@ -232,13 +238,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t
>>>> size,
>>>> MemoryRegion *mr)
>>>>            return;
>>>>        }
>>>>
>>>> -    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
>>>> -            " bytes (%ld Kib) of ram at "RAM_ADDR_FMT
>>>> -            " mr.name=%s\n",
>>>> -            __func__, size, (long)(size>>10), ram_addr, mr->name);
>>>> -
>>>> -    trace_xen_ram_alloc(ram_addr, size);
>>>> -
>>>>        nr_pfn = size >> TARGET_PAGE_BITS;
>>>>        pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
>>>>
>>>> @@ -246,11 +245,38 @@ 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) {
>>>> +    if ((xc_domain_getinfo(xen_xc, xen_domid, 1, &info) != 1) ||
> I think it's best to call xc_domain_getinfolist.
>

Will switch.

>>>> +       (info.domid != xen_domid)) {
>>>>            hw_error("xc_domain_getinfo failed");
>>>>        }
>>>> -    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;
>>>> +    real_free = free_pages;
>>>> +    if (free_pages > VGA_HOLE_SIZE) {
>>>> +        free_pages -= VGA_HOLE_SIZE;
>>>> +    } else {
>>>> +        free_pages = 0;
>>>> +    }
> I don't think we need to subtract VGA_HOLE_SIZE.

If you do not use some slack (like 32 here), xen does report:


(d5) [2014-11-29 17:07:21] Loaded SeaBIOS
(d5) [2014-11-29 17:07:21] Creating MP tables ...
(d5) [2014-11-29 17:07:21] Loading ACPI ...
(XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for 
domain 5: 1057417 > 1057416
(XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0 
extent: id=5 memflags=0 (0 of 1)
(d5) [2014-11-29 17:07:21] vm86 TSS at 00098c00
(d5) [2014-11-29 17:07:21] BIOS map:


However while QEMU startup ends with 32 "free" pages (maxmem - curmem)
this quickly changes to 23.  I.E. there are 7 more places that act like 
a call
to xc_domain_populate_physmap_exact() but do not log errors if there is
no free pages.  And just to make sure I do not fully understand what is
happening here, after the message above, the domain appears to work
fine and ends up with 8 "free" pages (code I do not know about ends up
releasing populated pages).

So my current thinking is to have QEMU leave a few (9 to 32 (64?)) pages 
"free".


>
>>>> +    need_pages = nr_pfn - free_pages;
>>>> +    fprintf(stderr, "%s: alloc "RAM_ADDR_FMT
>>>> +            " bytes (%ld KiB) of ram at "RAM_ADDR_FMT
>>>> +            " mp=%ld fp=%ld nr=%ld need=%ld mr.name=%s\n",
>>>> +            __func__, size, (long)(size>>10), ram_addr,
>>>> +           max_pages, free_pages, nr_pfn, need_pages,
>>>> +            mr->name);
>>>> +    if (xc_domain_get_pod_target(xen_xc, xen_domid, &tot_pages,
>>>> +                                 &pod_cache_pages, &pod_entries) >= 0) {
>>>> +        unsigned long populated = tot_pages - pod_cache_pages;
>>>> +        long delta_tot = tot_pages - info.nr_pages;
>>>> +
>>>> +        fprintf(stderr, "%s: PoD pop=%ld tot=%ld(%ld) cnt=%ld ent=%ld
>>>> nop=%ld
>>>> free=%ld\n",
>>>> +                __func__, populated, (long)tot_pages, delta_tot,
>>>> +                (long)pod_cache_pages, (long)pod_entries,
>>>> +               (long)info.nr_outstanding_pages, real_free);
>>>> +    }
>>> What is the purpose of calling xc_domain_get_pod_target here? It doesn't
>>> look like is affecting the parameters passed to xc_domain_setmaxmem.
>> This was just to test and see if anything was needed for PoD mode.
>> I did not see anything.
>>
>> Did you want me to make a patch to send to the list that has my proposed
>> changes?
> Yep, that's fine.
>
>
>> I do think that what I have would be fine to do since most of the time the
>> new code does nothing with the current xen (and older versions), until
>> more then 4 nics are configured for xen.
>>
>> It would be good to have the change:
>>
>> [PATCH] libxl_set_memory_target: retain the same maxmem offset on top of the
>> current target
>>
>> (When working) in xen before using a QEMU with this change.
>>
>> Not sure I would push for 2.2 however.
> I wouldn't.
>

Will mark as for 2.3

    -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 Dec 02 20:26:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1Xvu21-0001Qf-2b; Tue, 02 Dec 2014 20:26:45 +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 1Xvu1z-0001Q9-D9
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:26:43 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	09/17-17694-2802E745; Tue, 02 Dec 2014 20:26:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417552000!15310966!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29443 invoked from network); 2 Dec 2014 20:26:42 -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; 2 Dec 2014 20:26:42 -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 sB2KQXgG029165
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:26:34 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
	sB2KQWap025498
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 20:26:33 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
	sB2KQVqR009332; Tue, 2 Dec 2014 20:26:31 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:26:30 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 180F411B15F; Tue,  2 Dec 2014 15:26:31 -0500 (EST)
Date: Tue, 2 Dec 2014 15:26:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202202630.GJ357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-13-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-13-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 12/17] xen/x86/ept: handle reserved
 device memory in ept_handle_violation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 05:24:30PM +0800, Tiejun Chen wrote:
> We always reserve these ranges since we never allow any stuff to
> poke them.

s/any stuff to poke them/guest to access them./
> 
> But in theory some untrusted VM can maliciously access them. So we
> need to intercept this approach. But we just don't want to leak
> anything or introduce any side affect since other OSs may touch them
> by careless behavior, so its enough to have a lightweight way, and
> it shouldn't be same as those broken pages which cause domain crush.

s/crush/crash/
> 
> So we just need to return with next eip then let VM/OS itself handle

s/So//

s/itself//
> such a scenario as its own logic.

s/as its own/using its own/
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/arch/x86/hvm/vmx/vmx.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 2907afa..3ee884a 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2403,6 +2403,7 @@ static void ept_handle_violation(unsigned long qualification, paddr_t gpa)
>      p2m_type_t p2mt;
>      int ret;
>      struct domain *d = current->domain;
> +    struct p2m_get_reserved_device_memory pgrdm;
>  
>      /*
>       * We treat all write violations also as read violations.
> @@ -2438,6 +2439,23 @@ static void ept_handle_violation(unsigned long qualification, paddr_t gpa)
>          __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
>      }
>  
> +    /* This means some untrusted VM can maliciously access reserved
> +     * device memory. But we just don't want to leak anything or
> +     * introduce any side affect since other OSs may touch them by
> +     * careless behavior, so its enough to have a lightweight way.
> +     * Here we just need to return with next eip then let VM/OS itself
> +     * handle such a scenario as its own logic.
> +     */
> +    pgrdm.gfn = gfn;
> +    pgrdm.domain = d;
> +    ret = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                           &pgrdm);
> +    if ( ret )
> +    {
> +        update_guest_eip();
> +        return;
> +    }
> +
>      if ( qualification & EPT_GLA_VALID )
>      {
>          __vmread(GUEST_LINEAR_ADDRESS, &gla);
> -- 
> 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 Dec 02 20:26:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1Xvu21-0001Qf-2b; Tue, 02 Dec 2014 20:26:45 +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 1Xvu1z-0001Q9-D9
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:26:43 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	09/17-17694-2802E745; Tue, 02 Dec 2014 20:26:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417552000!15310966!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29443 invoked from network); 2 Dec 2014 20:26:42 -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; 2 Dec 2014 20:26:42 -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 sB2KQXgG029165
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:26:34 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
	sB2KQWap025498
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 20:26:33 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
	sB2KQVqR009332; Tue, 2 Dec 2014 20:26:31 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:26:30 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 180F411B15F; Tue,  2 Dec 2014 15:26:31 -0500 (EST)
Date: Tue, 2 Dec 2014 15:26:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202202630.GJ357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-13-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-13-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 12/17] xen/x86/ept: handle reserved
 device memory in ept_handle_violation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 05:24:30PM +0800, Tiejun Chen wrote:
> We always reserve these ranges since we never allow any stuff to
> poke them.

s/any stuff to poke them/guest to access them./
> 
> But in theory some untrusted VM can maliciously access them. So we
> need to intercept this approach. But we just don't want to leak
> anything or introduce any side affect since other OSs may touch them
> by careless behavior, so its enough to have a lightweight way, and
> it shouldn't be same as those broken pages which cause domain crush.

s/crush/crash/
> 
> So we just need to return with next eip then let VM/OS itself handle

s/So//

s/itself//
> such a scenario as its own logic.

s/as its own/using its own/
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/arch/x86/hvm/vmx/vmx.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 2907afa..3ee884a 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2403,6 +2403,7 @@ static void ept_handle_violation(unsigned long qualification, paddr_t gpa)
>      p2m_type_t p2mt;
>      int ret;
>      struct domain *d = current->domain;
> +    struct p2m_get_reserved_device_memory pgrdm;
>  
>      /*
>       * We treat all write violations also as read violations.
> @@ -2438,6 +2439,23 @@ static void ept_handle_violation(unsigned long qualification, paddr_t gpa)
>          __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
>      }
>  
> +    /* This means some untrusted VM can maliciously access reserved
> +     * device memory. But we just don't want to leak anything or
> +     * introduce any side affect since other OSs may touch them by
> +     * careless behavior, so its enough to have a lightweight way.
> +     * Here we just need to return with next eip then let VM/OS itself
> +     * handle such a scenario as its own logic.
> +     */
> +    pgrdm.gfn = gfn;
> +    pgrdm.domain = d;
> +    ret = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                           &pgrdm);
> +    if ( ret )
> +    {
> +        update_guest_eip();
> +        return;
> +    }
> +
>      if ( qualification & EPT_GLA_VALID )
>      {
>          __vmread(GUEST_LINEAR_ADDRESS, &gla);
> -- 
> 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 Dec 02 20:27:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1Xvu2p-0001X7-LY; Tue, 02 Dec 2014 20:27:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xvu2o-0001Wv-HX
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:27:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	88/E7-09842-5B02E745; Tue, 02 Dec 2014 20:27:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417552051!12930725!1
X-Originating-IP: [156.151.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 15498 invoked from network); 2 Dec 2014 20:27:33 -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; 2 Dec 2014 20:27: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 sB2KRNQ2023896
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:27:24 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
	sB2KRNYA008352
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:27:23 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
	sB2KRMUl008321; Tue, 2 Dec 2014 20:27:22 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:27:22 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3773D11B161; Tue,  2 Dec 2014 15:27:22 -0500 (EST)
Date: Tue, 2 Dec 2014 15:27:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202202722.GK357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 13/17] xen/mem_access: don't allow
 accessing reserved device 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, Dec 01, 2014 at 05:24:31PM +0800, Tiejun Chen wrote:
> We can't expost those reserved device memory in case of mem_access

s/expost/expose/

> since any access may corrupt device usage.

Could you explain this in more details please?

> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/common/mem_access.c | 41 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
> index 6c2724b..72a807a 100644
> --- a/xen/common/mem_access.c
> +++ b/xen/common/mem_access.c
> @@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)
>      }
>  }
>  
> +/* We can't expose reserved device memory. */
> +static int mem_access_check_rdm(struct domain *d, uint64_aligned_t start,
> +                                uint32_t nr)
> +{
> +    uint32_t i;
> +    struct p2m_get_reserved_device_memory pgrdm;
> +    int rc = 0;
> +
> +    if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )
> +    {
> +        for ( i = 0; i < nr; i++ )
> +        {
> +            pgrdm.gfn = start + i;
> +            pgrdm.domain = d;
> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                                  &pgrdm);
> +            if ( rc < 0 )
> +            {
> +                printk(XENLOG_WARNING
> +                       "Domain %d can't check reserved device memory.\n",
> +                       d->domain_id);
> +                return rc;
> +            }
> +
> +            if ( rc == 1 )
> +            {
> +                printk(XENLOG_WARNING
> +                       "Domain %d: we shouldn't mem_access reserved device memory.\n",
> +                       d->domain_id);
> +                return rc;
> +            }
> +        }
> +    }
> +
> +    return rc;
> +}
> +
>  int mem_access_memop(unsigned long cmd,
>                       XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg)
>  {
> @@ -99,6 +136,10 @@ int mem_access_memop(unsigned long cmd,
>                ((mao.pfn + mao.nr - 1) > domain_get_maximum_gpfn(d))) )
>              break;
>  
> +        rc =  mem_access_check_rdm(d, mao.pfn, mao.nr);
> +        if ( rc == 1 )
> +            break;
> +
>          rc = p2m_set_mem_access(d, mao.pfn, mao.nr, start_iter,
>                                  MEMOP_CMD_MASK, mao.access);
>          if ( rc > 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 Tue Dec 02 20:27:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1Xvu2p-0001X7-LY; Tue, 02 Dec 2014 20:27:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xvu2o-0001Wv-HX
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:27:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	88/E7-09842-5B02E745; Tue, 02 Dec 2014 20:27:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417552051!12930725!1
X-Originating-IP: [156.151.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 15498 invoked from network); 2 Dec 2014 20:27:33 -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; 2 Dec 2014 20:27: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 sB2KRNQ2023896
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:27:24 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
	sB2KRNYA008352
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:27:23 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
	sB2KRMUl008321; Tue, 2 Dec 2014 20:27:22 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:27:22 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3773D11B161; Tue,  2 Dec 2014 15:27:22 -0500 (EST)
Date: Tue, 2 Dec 2014 15:27:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202202722.GK357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 13/17] xen/mem_access: don't allow
 accessing reserved device 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, Dec 01, 2014 at 05:24:31PM +0800, Tiejun Chen wrote:
> We can't expost those reserved device memory in case of mem_access

s/expost/expose/

> since any access may corrupt device usage.

Could you explain this in more details please?

> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/common/mem_access.c | 41 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
> index 6c2724b..72a807a 100644
> --- a/xen/common/mem_access.c
> +++ b/xen/common/mem_access.c
> @@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)
>      }
>  }
>  
> +/* We can't expose reserved device memory. */
> +static int mem_access_check_rdm(struct domain *d, uint64_aligned_t start,
> +                                uint32_t nr)
> +{
> +    uint32_t i;
> +    struct p2m_get_reserved_device_memory pgrdm;
> +    int rc = 0;
> +
> +    if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )
> +    {
> +        for ( i = 0; i < nr; i++ )
> +        {
> +            pgrdm.gfn = start + i;
> +            pgrdm.domain = d;
> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                                  &pgrdm);
> +            if ( rc < 0 )
> +            {
> +                printk(XENLOG_WARNING
> +                       "Domain %d can't check reserved device memory.\n",
> +                       d->domain_id);
> +                return rc;
> +            }
> +
> +            if ( rc == 1 )
> +            {
> +                printk(XENLOG_WARNING
> +                       "Domain %d: we shouldn't mem_access reserved device memory.\n",
> +                       d->domain_id);
> +                return rc;
> +            }
> +        }
> +    }
> +
> +    return rc;
> +}
> +
>  int mem_access_memop(unsigned long cmd,
>                       XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg)
>  {
> @@ -99,6 +136,10 @@ int mem_access_memop(unsigned long cmd,
>                ((mao.pfn + mao.nr - 1) > domain_get_maximum_gpfn(d))) )
>              break;
>  
> +        rc =  mem_access_check_rdm(d, mao.pfn, mao.nr);
> +        if ( rc == 1 )
> +            break;
> +
>          rc = p2m_set_mem_access(d, mao.pfn, mao.nr, start_iter,
>                                  MEMOP_CMD_MASK, mao.access);
>          if ( rc > 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 Tue Dec 02 20:29:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1Xvu4S-0001fe-56; Tue, 02 Dec 2014 20:29: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 1Xvu4Q-0001fT-UN
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:29:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	92/D6-15461-A112E745; Tue, 02 Dec 2014 20:29:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417552152!12939759!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11694 invoked from network); 2 Dec 2014 20:29:13 -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; 2 Dec 2014 20:29: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 sB2KT5PO032197
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:29:06 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
	sB2KT44H012298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:29:05 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
	sB2KT4bn024988; Tue, 2 Dec 2014 20:29:04 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:29:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 23B0911B165; Tue,  2 Dec 2014 15:29:04 -0500 (EST)
Date: Tue, 2 Dec 2014 15:29:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202202903.GL357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-15-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-15-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 14/17] xen/x86/p2m: introduce
	set_identity_p2m_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 Mon, Dec 01, 2014 at 05:24:32PM +0800, Tiejun Chen wrote:
> We will create RMRR mapping as follows:
> 
> If gfn space unoccupied, we just set that. If
> space already occupy by 1:1 RMRR mapping do thing. Others

What is 'do thing'?

It looks as if we do nothing. Is that what you meant?

> should be failed.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/arch/x86/mm/p2m.c     | 28 ++++++++++++++++++++++++++++
>  xen/include/asm-x86/p2m.h |  4 ++++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 607ecd0..c415521 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -913,6 +913,34 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
>      return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct);
>  }
>  
> +int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
> +                           p2m_access_t p2ma)
> +{
> +    p2m_type_t p2mt;
> +    p2m_access_t a;
> +    mfn_t mfn;
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int ret = -EBUSY;
> +
> +    gfn_lock(p2m, gfn, 0);
> +
> +    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
> +
> +    if ( !mfn_valid(mfn) )
> +        ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct,
> +                            p2ma);
> +    else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
> +        ret = 0;
> +    else
> +        printk(XENLOG_G_WARNING
> +               "Cannot identity map d%d:%lx, already mapped to %lx.\n",
> +               d->domain_id, gfn, mfn_x(mfn));
> +
> +    gfn_unlock(p2m, gfn, 0);
> +
> +    return ret;
> +}
> +
>  /* Returns: 0 for success, -errno for failure */
>  int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
>  {
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index 99f7fb7..26cf0cc 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -509,6 +509,10 @@ int p2m_is_logdirty_range(struct p2m_domain *, unsigned long start,
>  int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
>  int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
>  
> +/* Set identity addresses in the p2m table (for pass-through) */
> +int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
> +                           p2m_access_t p2ma);
> +
>  /* Add foreign mapping to the guest's p2m table. */
>  int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
>                      unsigned long gpfn, domid_t foreign_domid);
> -- 
> 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 Dec 02 20:29:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1Xvu4S-0001fe-56; Tue, 02 Dec 2014 20:29: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 1Xvu4Q-0001fT-UN
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:29:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	92/D6-15461-A112E745; Tue, 02 Dec 2014 20:29:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417552152!12939759!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11694 invoked from network); 2 Dec 2014 20:29:13 -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; 2 Dec 2014 20:29: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 sB2KT5PO032197
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:29:06 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
	sB2KT44H012298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:29:05 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
	sB2KT4bn024988; Tue, 2 Dec 2014 20:29:04 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:29:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 23B0911B165; Tue,  2 Dec 2014 15:29:04 -0500 (EST)
Date: Tue, 2 Dec 2014 15:29:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202202903.GL357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-15-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-15-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 14/17] xen/x86/p2m: introduce
	set_identity_p2m_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 Mon, Dec 01, 2014 at 05:24:32PM +0800, Tiejun Chen wrote:
> We will create RMRR mapping as follows:
> 
> If gfn space unoccupied, we just set that. If
> space already occupy by 1:1 RMRR mapping do thing. Others

What is 'do thing'?

It looks as if we do nothing. Is that what you meant?

> should be failed.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/arch/x86/mm/p2m.c     | 28 ++++++++++++++++++++++++++++
>  xen/include/asm-x86/p2m.h |  4 ++++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 607ecd0..c415521 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -913,6 +913,34 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
>      return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct);
>  }
>  
> +int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
> +                           p2m_access_t p2ma)
> +{
> +    p2m_type_t p2mt;
> +    p2m_access_t a;
> +    mfn_t mfn;
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int ret = -EBUSY;
> +
> +    gfn_lock(p2m, gfn, 0);
> +
> +    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
> +
> +    if ( !mfn_valid(mfn) )
> +        ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct,
> +                            p2ma);
> +    else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
> +        ret = 0;
> +    else
> +        printk(XENLOG_G_WARNING
> +               "Cannot identity map d%d:%lx, already mapped to %lx.\n",
> +               d->domain_id, gfn, mfn_x(mfn));
> +
> +    gfn_unlock(p2m, gfn, 0);
> +
> +    return ret;
> +}
> +
>  /* Returns: 0 for success, -errno for failure */
>  int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
>  {
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index 99f7fb7..26cf0cc 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -509,6 +509,10 @@ int p2m_is_logdirty_range(struct p2m_domain *, unsigned long start,
>  int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
>  int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
>  
> +/* Set identity addresses in the p2m table (for pass-through) */
> +int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
> +                           p2m_access_t p2ma);
> +
>  /* Add foreign mapping to the guest's p2m table. */
>  int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
>                      unsigned long gpfn, domid_t foreign_domid);
> -- 
> 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 Dec 02 20:31:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1Xvu6J-0001os-Li; Tue, 02 Dec 2014 20:31:11 +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 1Xvu6I-0001og-9h
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:31:10 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	0A/95-02954-D812E745; Tue, 02 Dec 2014 20:31:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417552267!12566280!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 709 invoked from network); 2 Dec 2014 20:31:08 -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; 2 Dec 2014 20:31:08 -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 sB2KUu7k002058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:30:57 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
	sB2KUuRX020471
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:30:56 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
	sB2KUtgw016897; Tue, 2 Dec 2014 20:30:55 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:30:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 603DC11B16D; Tue,  2 Dec 2014 15:30:55 -0500 (EST)
Date: Tue, 2 Dec 2014 15:30:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202203055.GM357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-16-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-16-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 15/17] xen:vtd: create RMRR 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 Mon, Dec 01, 2014 at 05:24:33PM +0800, Tiejun Chen wrote:
> intel_iommu_map_page() does nothing if VT-d shares EPT page table.
> So rmrr_identity_mapping() never create RMRR mapping but in some

s/So//

s/create/creates/
> cases like some GFX drivers it still need to access RMRR.

s/drivers .../drivers which may need to access RMRR/
> 
> Here we will create those RMRR mappings even in shared EPT case.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/drivers/passthrough/vtd/iommu.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
> index a38f201..a54c6eb 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1856,10 +1856,15 @@ static int rmrr_identity_mapping(struct domain *d, bool_t map,
>  
>      while ( base_pfn < end_pfn )
>      {
> -        int err = intel_iommu_map_page(d, base_pfn, base_pfn,
> -                                       IOMMUF_readable|IOMMUF_writable);
> -
> -        if ( err )
> +        int err = 0;
> +        if ( iommu_use_hap_pt(d) )
> +        {
> +            ASSERT(!iommu_passthrough || !is_hardware_domain(d));
> +            if ( (err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw)) )
> +                return err;
> +        }
> +        else if ( (err = intel_iommu_map_page(d, base_pfn, base_pfn,
> +					      IOMMUF_readable|IOMMUF_writable)) )
>              return err;
>          base_pfn++;
>      }
> -- 
> 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 Dec 02 20:31:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1Xvu6J-0001os-Li; Tue, 02 Dec 2014 20:31:11 +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 1Xvu6I-0001og-9h
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:31:10 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	0A/95-02954-D812E745; Tue, 02 Dec 2014 20:31:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417552267!12566280!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 709 invoked from network); 2 Dec 2014 20:31:08 -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; 2 Dec 2014 20:31:08 -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 sB2KUu7k002058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:30:57 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
	sB2KUuRX020471
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:30:56 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
	sB2KUtgw016897; Tue, 2 Dec 2014 20:30:55 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:30:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 603DC11B16D; Tue,  2 Dec 2014 15:30:55 -0500 (EST)
Date: Tue, 2 Dec 2014 15:30:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202203055.GM357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-16-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-16-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 15/17] xen:vtd: create RMRR 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 Mon, Dec 01, 2014 at 05:24:33PM +0800, Tiejun Chen wrote:
> intel_iommu_map_page() does nothing if VT-d shares EPT page table.
> So rmrr_identity_mapping() never create RMRR mapping but in some

s/So//

s/create/creates/
> cases like some GFX drivers it still need to access RMRR.

s/drivers .../drivers which may need to access RMRR/
> 
> Here we will create those RMRR mappings even in shared EPT case.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/drivers/passthrough/vtd/iommu.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
> index a38f201..a54c6eb 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1856,10 +1856,15 @@ static int rmrr_identity_mapping(struct domain *d, bool_t map,
>  
>      while ( base_pfn < end_pfn )
>      {
> -        int err = intel_iommu_map_page(d, base_pfn, base_pfn,
> -                                       IOMMUF_readable|IOMMUF_writable);
> -
> -        if ( err )
> +        int err = 0;
> +        if ( iommu_use_hap_pt(d) )
> +        {
> +            ASSERT(!iommu_passthrough || !is_hardware_domain(d));
> +            if ( (err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw)) )
> +                return err;
> +        }
> +        else if ( (err = intel_iommu_map_page(d, base_pfn, base_pfn,
> +					      IOMMUF_readable|IOMMUF_writable)) )
>              return err;
>          base_pfn++;
>      }
> -- 
> 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 Dec 02 20:40:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1XvuFP-0002AB-N6; Tue, 02 Dec 2014 20:40: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 1XvuFN-0002A6-Jg
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:40:33 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	4A/29-24859-0C32E745; Tue, 02 Dec 2014 20:40:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417552830!15426588!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28199 invoked from network); 2 Dec 2014 20:40:31 -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; 2 Dec 2014 20:40:31 -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 sB2KeJFQ006476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:40:20 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
	sB2KeIwS011240
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:40:18 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
	sB2KeH5P011211; Tue, 2 Dec 2014 20:40:17 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:40:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 19BB511B181; Tue,  2 Dec 2014 15:40:17 -0500 (EST)
Date: Tue, 2 Dec 2014 15:40:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202204016.GN357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-17-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-17-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 16/17] xen/vtd: group assigned device
	with RMRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 05:24:34PM +0800, Tiejun Chen wrote:
> Sometimes different devices may share RMRR range so in this

s/Sometimes//

s/range/ranges/
> case we shouldn't assign these devices into different VMs
> since they may have potential leakage even damage between VMs.

s/potential leak../corrupt each other/?

I am actually not sure what they would leak? Security data?

> 
> So we need to group all devices as RMRR range to make sure they

s/So//

s/range/ranges/
> are just assigned into the same VM.
> 
> Here we introduce two field, gid and domid, in struct,
> acpi_rmrr_unit:
>  gid: indicate which group this device owns. "0" is invalid so
>       just start from "1".
>  domid: indicate which domain this device owns currently. Firstly
>         the hardware domain should own it.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/drivers/passthrough/vtd/dmar.c  | 28 ++++++++++++++-
>  xen/drivers/passthrough/vtd/dmar.h  |  2 ++
>  xen/drivers/passthrough/vtd/iommu.c | 68 +++++++++++++++++++++++++++++++++----
>  3 files changed, 91 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
> index c5bc8d6..8d3406f 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -572,10 +572,11 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>  {
>      struct acpi_dmar_reserved_memory *rmrr =
>          container_of(header, struct acpi_dmar_reserved_memory, header);
> -    struct acpi_rmrr_unit *rmrru;
> +    struct acpi_rmrr_unit *rmrru, *cur_rmrr;
>      void *dev_scope_start, *dev_scope_end;
>      u64 base_addr = rmrr->base_address, end_addr = rmrr->end_address;
>      int ret;
> +    static unsigned int group_id = 0;
>  
>      if ( (ret = acpi_dmar_check_length(header, sizeof(*rmrr))) != 0 )
>          return ret;
> @@ -611,6 +612,8 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>      rmrru->base_address = base_addr;
>      rmrru->end_address = end_addr;
>      rmrru->segment = rmrr->segment;
> +    /* "0" is an invalid group id. */
> +    rmrru->gid = 0;
>  
>      dev_scope_start = (void *)(rmrr + 1);
>      dev_scope_end   = ((void *)rmrr) + header->length;
> @@ -682,7 +685,30 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>                      "So please set pci_rdmforce to reserve these ranges"
>                      " if you need such a device in hotplug case.\n");
>  
> +            list_for_each_entry(cur_rmrr, &acpi_rmrr_units, list)
> +            {
> +                /*
> +                 * Any same or overlap range mean they should be
> +                 * at same group.

Same or overlap ranges must be in the same group.

> +                 */
> +                if ( ((base_addr >= cur_rmrr->base_address) &&
> +                     (end_addr <= cur_rmrr->end_address)) ||
> +                     ((base_addr <= cur_rmrr->base_address) &&
> +                     (end_addr >= cur_rmrr->end_address)) )
> +                {
> +                    rmrru->gid = cur_rmrr->gid;
> +                    continue;
> +                }
> +            }
> +
>              acpi_register_rmrr_unit(rmrru);
> +
> +            /* Allocate group id from gid:1. */
> +            if ( !rmrru->gid )
> +            {
> +                group_id++;
> +                rmrru->gid = group_id;
> +            }
>          }
>      }
>  
> diff --git a/xen/drivers/passthrough/vtd/dmar.h b/xen/drivers/passthrough/vtd/dmar.h
> index af1feef..a57c0d4 100644
> --- a/xen/drivers/passthrough/vtd/dmar.h
> +++ b/xen/drivers/passthrough/vtd/dmar.h
> @@ -76,6 +76,8 @@ struct acpi_rmrr_unit {
>      u64    end_address;
>      u16    segment;
>      u8     allow_all:1;
> +    int    gid;

unsigned int?

> +    domid_t    domid;
>  };
>  
>  struct acpi_atsr_unit {
> diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
> index a54c6eb..ba40209 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1882,9 +1882,9 @@ static int rmrr_identity_mapping(struct domain *d, bool_t map,
>  
>  static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
>  {
> -    struct acpi_rmrr_unit *rmrr;
> -    u16 bdf;
> -    int ret, i;
> +    struct acpi_rmrr_unit *rmrr, *g_rmrr;
> +    u16 bdf, g_bdf;
> +    int ret, i, j;
>  
>      ASSERT(spin_is_locked(&pcidevs_lock));
>  
> @@ -1905,6 +1905,32 @@ static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
>               PCI_BUS(bdf) == pdev->bus &&
>               PCI_DEVFN2(bdf) == devfn )
>          {
> +            if ( rmrr->domid == hardware_domain->domain_id )
> +            {
> +                for_each_rmrr_device ( g_rmrr, g_bdf, j )
> +                {
> +                    if ( g_rmrr->gid == rmrr->gid )
> +                    {
> +                        if ( g_rmrr->domid == hardware_domain->domain_id )
> +                            g_rmrr->domid = pdev->domain->domain_id;
> +                        else if ( g_rmrr->domid != pdev->domain->domain_id )
> +                        {
> +                            rmrr->domid = g_rmrr->domid;
> +                            continue;
> +                        }
> +                    }
> +                }
> +            }
> +
> +            if ( rmrr->domid != pdev->domain->domain_id )
> +            {
> +                domain_context_unmap(pdev->domain, devfn, pdev);
> +                dprintk(XENLOG_ERR VTDPREFIX, "d%d: this is a group device owned by d%d\n",
> +                        pdev->domain->domain_id, rmrr->domid);
> +                rmrr->domid = 0;
> +                return -EINVAL;
> +            }
> +
>              ret = rmrr_identity_mapping(pdev->domain, 1, rmrr);
>              if ( ret )
>                  dprintk(XENLOG_ERR VTDPREFIX, "d%d: RMRR mapping failed\n",
> @@ -1946,6 +1972,8 @@ static int intel_iommu_remove_device(u8 devfn, struct pci_dev *pdev)
>               PCI_DEVFN2(bdf) != devfn )
>              continue;
>  
> +        /* Just release to hardware domain. */
> +        rmrr->domid = hardware_domain->domain_id;
>          rmrr_identity_mapping(pdev->domain, 0, rmrr);
>      }
>  
> @@ -2104,6 +2132,8 @@ static void __hwdom_init setup_hwdom_rmrr(struct domain *d)
>      spin_lock(&pcidevs_lock);
>      for_each_rmrr_device ( rmrr, bdf, i )
>      {
> +        /* hwdom should own all devices at first. */
> +        rmrr->domid = d->domain_id;
>          ret = rmrr_identity_mapping(d, 1, rmrr);
>          if ( ret )
>              dprintk(XENLOG_ERR VTDPREFIX,
> @@ -2273,9 +2303,9 @@ static int reassign_device_ownership(
>  static int intel_iommu_assign_device(
>      struct domain *d, u8 devfn, struct pci_dev *pdev)
>  {
> -    struct acpi_rmrr_unit *rmrr;
> -    int ret = 0, i;
> -    u16 bdf, seg;
> +    struct acpi_rmrr_unit *rmrr, *g_rmrr;
> +    int ret = 0, i, j;
> +    u16 bdf, seg, g_bdf;
>      u8 bus;
>  
>      if ( list_empty(&acpi_drhd_units) )
> @@ -2300,6 +2330,32 @@ static int intel_iommu_assign_device(
>               PCI_BUS(bdf) == bus &&
>               PCI_DEVFN2(bdf) == devfn )
>          {
> +            if ( rmrr->domid == hardware_domain->domain_id )
> +            {
> +                for_each_rmrr_device ( g_rmrr, g_bdf, j )
> +                {
> +                    if ( g_rmrr->gid == rmrr->gid )
> +                    {
> +                        if ( g_rmrr->domid == hardware_domain->domain_id )
> +                            g_rmrr->domid = pdev->domain->domain_id;
> +                        else if ( g_rmrr->domid != pdev->domain->domain_id )
> +                        {
> +                            rmrr->domid = g_rmrr->domid;
> +                            continue;
> +                        }
> +                    }
> +                }
> +            }
> +
> +            if ( rmrr->domid != pdev->domain->domain_id )
> +            {
> +                domain_context_unmap(pdev->domain, devfn, pdev);
> +                dprintk(XENLOG_ERR VTDPREFIX, "d%d: this is a group device owned by d%d\n",
> +                        pdev->domain->domain_id, rmrr->domid);
> +                rmrr->domid = 0;
> +                return -EINVAL;
> +            }
> +

Please make this a function.
>              ret = rmrr_identity_mapping(d, 1, rmrr);
>              if ( ret )
>              {
> -- 
> 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 Dec 02 20:40:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1XvuFP-0002AB-N6; Tue, 02 Dec 2014 20:40: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 1XvuFN-0002A6-Jg
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:40:33 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	4A/29-24859-0C32E745; Tue, 02 Dec 2014 20:40:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417552830!15426588!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28199 invoked from network); 2 Dec 2014 20:40:31 -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; 2 Dec 2014 20:40:31 -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 sB2KeJFQ006476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:40:20 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
	sB2KeIwS011240
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:40:18 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
	sB2KeH5P011211; Tue, 2 Dec 2014 20:40:17 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:40:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 19BB511B181; Tue,  2 Dec 2014 15:40:17 -0500 (EST)
Date: Tue, 2 Dec 2014 15:40:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141202204016.GN357@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-17-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-17-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 16/17] xen/vtd: group assigned device
	with RMRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 05:24:34PM +0800, Tiejun Chen wrote:
> Sometimes different devices may share RMRR range so in this

s/Sometimes//

s/range/ranges/
> case we shouldn't assign these devices into different VMs
> since they may have potential leakage even damage between VMs.

s/potential leak../corrupt each other/?

I am actually not sure what they would leak? Security data?

> 
> So we need to group all devices as RMRR range to make sure they

s/So//

s/range/ranges/
> are just assigned into the same VM.
> 
> Here we introduce two field, gid and domid, in struct,
> acpi_rmrr_unit:
>  gid: indicate which group this device owns. "0" is invalid so
>       just start from "1".
>  domid: indicate which domain this device owns currently. Firstly
>         the hardware domain should own it.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/drivers/passthrough/vtd/dmar.c  | 28 ++++++++++++++-
>  xen/drivers/passthrough/vtd/dmar.h  |  2 ++
>  xen/drivers/passthrough/vtd/iommu.c | 68 +++++++++++++++++++++++++++++++++----
>  3 files changed, 91 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
> index c5bc8d6..8d3406f 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -572,10 +572,11 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>  {
>      struct acpi_dmar_reserved_memory *rmrr =
>          container_of(header, struct acpi_dmar_reserved_memory, header);
> -    struct acpi_rmrr_unit *rmrru;
> +    struct acpi_rmrr_unit *rmrru, *cur_rmrr;
>      void *dev_scope_start, *dev_scope_end;
>      u64 base_addr = rmrr->base_address, end_addr = rmrr->end_address;
>      int ret;
> +    static unsigned int group_id = 0;
>  
>      if ( (ret = acpi_dmar_check_length(header, sizeof(*rmrr))) != 0 )
>          return ret;
> @@ -611,6 +612,8 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>      rmrru->base_address = base_addr;
>      rmrru->end_address = end_addr;
>      rmrru->segment = rmrr->segment;
> +    /* "0" is an invalid group id. */
> +    rmrru->gid = 0;
>  
>      dev_scope_start = (void *)(rmrr + 1);
>      dev_scope_end   = ((void *)rmrr) + header->length;
> @@ -682,7 +685,30 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>                      "So please set pci_rdmforce to reserve these ranges"
>                      " if you need such a device in hotplug case.\n");
>  
> +            list_for_each_entry(cur_rmrr, &acpi_rmrr_units, list)
> +            {
> +                /*
> +                 * Any same or overlap range mean they should be
> +                 * at same group.

Same or overlap ranges must be in the same group.

> +                 */
> +                if ( ((base_addr >= cur_rmrr->base_address) &&
> +                     (end_addr <= cur_rmrr->end_address)) ||
> +                     ((base_addr <= cur_rmrr->base_address) &&
> +                     (end_addr >= cur_rmrr->end_address)) )
> +                {
> +                    rmrru->gid = cur_rmrr->gid;
> +                    continue;
> +                }
> +            }
> +
>              acpi_register_rmrr_unit(rmrru);
> +
> +            /* Allocate group id from gid:1. */
> +            if ( !rmrru->gid )
> +            {
> +                group_id++;
> +                rmrru->gid = group_id;
> +            }
>          }
>      }
>  
> diff --git a/xen/drivers/passthrough/vtd/dmar.h b/xen/drivers/passthrough/vtd/dmar.h
> index af1feef..a57c0d4 100644
> --- a/xen/drivers/passthrough/vtd/dmar.h
> +++ b/xen/drivers/passthrough/vtd/dmar.h
> @@ -76,6 +76,8 @@ struct acpi_rmrr_unit {
>      u64    end_address;
>      u16    segment;
>      u8     allow_all:1;
> +    int    gid;

unsigned int?

> +    domid_t    domid;
>  };
>  
>  struct acpi_atsr_unit {
> diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
> index a54c6eb..ba40209 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1882,9 +1882,9 @@ static int rmrr_identity_mapping(struct domain *d, bool_t map,
>  
>  static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
>  {
> -    struct acpi_rmrr_unit *rmrr;
> -    u16 bdf;
> -    int ret, i;
> +    struct acpi_rmrr_unit *rmrr, *g_rmrr;
> +    u16 bdf, g_bdf;
> +    int ret, i, j;
>  
>      ASSERT(spin_is_locked(&pcidevs_lock));
>  
> @@ -1905,6 +1905,32 @@ static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
>               PCI_BUS(bdf) == pdev->bus &&
>               PCI_DEVFN2(bdf) == devfn )
>          {
> +            if ( rmrr->domid == hardware_domain->domain_id )
> +            {
> +                for_each_rmrr_device ( g_rmrr, g_bdf, j )
> +                {
> +                    if ( g_rmrr->gid == rmrr->gid )
> +                    {
> +                        if ( g_rmrr->domid == hardware_domain->domain_id )
> +                            g_rmrr->domid = pdev->domain->domain_id;
> +                        else if ( g_rmrr->domid != pdev->domain->domain_id )
> +                        {
> +                            rmrr->domid = g_rmrr->domid;
> +                            continue;
> +                        }
> +                    }
> +                }
> +            }
> +
> +            if ( rmrr->domid != pdev->domain->domain_id )
> +            {
> +                domain_context_unmap(pdev->domain, devfn, pdev);
> +                dprintk(XENLOG_ERR VTDPREFIX, "d%d: this is a group device owned by d%d\n",
> +                        pdev->domain->domain_id, rmrr->domid);
> +                rmrr->domid = 0;
> +                return -EINVAL;
> +            }
> +
>              ret = rmrr_identity_mapping(pdev->domain, 1, rmrr);
>              if ( ret )
>                  dprintk(XENLOG_ERR VTDPREFIX, "d%d: RMRR mapping failed\n",
> @@ -1946,6 +1972,8 @@ static int intel_iommu_remove_device(u8 devfn, struct pci_dev *pdev)
>               PCI_DEVFN2(bdf) != devfn )
>              continue;
>  
> +        /* Just release to hardware domain. */
> +        rmrr->domid = hardware_domain->domain_id;
>          rmrr_identity_mapping(pdev->domain, 0, rmrr);
>      }
>  
> @@ -2104,6 +2132,8 @@ static void __hwdom_init setup_hwdom_rmrr(struct domain *d)
>      spin_lock(&pcidevs_lock);
>      for_each_rmrr_device ( rmrr, bdf, i )
>      {
> +        /* hwdom should own all devices at first. */
> +        rmrr->domid = d->domain_id;
>          ret = rmrr_identity_mapping(d, 1, rmrr);
>          if ( ret )
>              dprintk(XENLOG_ERR VTDPREFIX,
> @@ -2273,9 +2303,9 @@ static int reassign_device_ownership(
>  static int intel_iommu_assign_device(
>      struct domain *d, u8 devfn, struct pci_dev *pdev)
>  {
> -    struct acpi_rmrr_unit *rmrr;
> -    int ret = 0, i;
> -    u16 bdf, seg;
> +    struct acpi_rmrr_unit *rmrr, *g_rmrr;
> +    int ret = 0, i, j;
> +    u16 bdf, seg, g_bdf;
>      u8 bus;
>  
>      if ( list_empty(&acpi_drhd_units) )
> @@ -2300,6 +2330,32 @@ static int intel_iommu_assign_device(
>               PCI_BUS(bdf) == bus &&
>               PCI_DEVFN2(bdf) == devfn )
>          {
> +            if ( rmrr->domid == hardware_domain->domain_id )
> +            {
> +                for_each_rmrr_device ( g_rmrr, g_bdf, j )
> +                {
> +                    if ( g_rmrr->gid == rmrr->gid )
> +                    {
> +                        if ( g_rmrr->domid == hardware_domain->domain_id )
> +                            g_rmrr->domid = pdev->domain->domain_id;
> +                        else if ( g_rmrr->domid != pdev->domain->domain_id )
> +                        {
> +                            rmrr->domid = g_rmrr->domid;
> +                            continue;
> +                        }
> +                    }
> +                }
> +            }
> +
> +            if ( rmrr->domid != pdev->domain->domain_id )
> +            {
> +                domain_context_unmap(pdev->domain, devfn, pdev);
> +                dprintk(XENLOG_ERR VTDPREFIX, "d%d: this is a group device owned by d%d\n",
> +                        pdev->domain->domain_id, rmrr->domid);
> +                rmrr->domid = 0;
> +                return -EINVAL;
> +            }
> +

Please make this a function.
>              ret = rmrr_identity_mapping(d, 1, rmrr);
>              if ( ret )
>              {
> -- 
> 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 Dec 02 20:43:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1XvuI1-0002Q2-8h; Tue, 02 Dec 2014 20:43:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvuI0-0002Pw-1n
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:43:16 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	71/A8-31453-3642E745; Tue, 02 Dec 2014 20:43:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417552993!5748678!1
X-Originating-IP: [156.151.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 10682 invoked from network); 2 Dec 2014 20:43:14 -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; 2 Dec 2014 20:43:14 -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 sB2Kgns9009366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:42:50 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
	sB2KgmqP021383
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:42:48 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
	sB2Kgl0U017990; Tue, 2 Dec 2014 20:42:48 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:42:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4AB5911B185; Tue,  2 Dec 2014 15:42:45 -0500 (EST)
Date: Tue, 2 Dec 2014 15:42:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141202204245.GO357@laptop.dumpdata.com>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Olaf Hering <olaf@aepfle.de>, 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.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 06:51:50PM +0000, M A Young wrote:
> On Tue, 2 Dec 2014, Konrad Rzeszutek Wilk wrote:
> 
> >On Tue, Dec 02, 2014 at 03:44:55PM +0000, Ian Campbell wrote:
> >>On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
> >>>Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
> >>>systemd xenstored dependencies") all service files use the .socket unit
> >>>as startup dependency. While this happens to work for boot it fails for
> >>>shutdown because a .socket does not seem to enforce ordering. When
> >>>xendomains.service runs during shutdown then systemd will stop
> >>>xenstored.service at the same time.
> >>>
> >>>Change all "xenstored.socket" to "xenstored.service" to let systemd know
> >>>that xenstored has to be shutdown after everything else.
> >>>
> >>>Reported-by: Mark Pryor <tlviewer@yahoo.com>
> >>>Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >>>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >>>Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>
> >>Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >>
> >>>Cc: Wei Liu <wei.liu2@citrix.com>
> >>>---
> >>>
> >>>This should go into 4.5 to fix xendomains.service.
> >>
> >>CCing Konrad...
> >
> >CC-ing Michael.
> >
> >Michael, since Fedora is using systemd, did you observe this bug as well?
> >(I think I did, but I might have blamed it on my wacky setup).
> 
> I only tried the xen systemd on xen 4.5-rc2 and didn't have a lot of success
> even when I reverted to Fedora's systemd for xen, so I can't really comment.

Ugh.
> I did have issues with xen systemd which I shall report if they are still
> there in -rc3.

OK, lets then go with this.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> 	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 Dec 02 20:43:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20: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 1XvuI1-0002Q2-8h; Tue, 02 Dec 2014 20:43:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvuI0-0002Pw-1n
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:43:16 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	71/A8-31453-3642E745; Tue, 02 Dec 2014 20:43:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417552993!5748678!1
X-Originating-IP: [156.151.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 10682 invoked from network); 2 Dec 2014 20:43:14 -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; 2 Dec 2014 20:43:14 -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 sB2Kgns9009366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:42:50 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
	sB2KgmqP021383
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:42:48 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
	sB2Kgl0U017990; Tue, 2 Dec 2014 20:42:48 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:42:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4AB5911B185; Tue,  2 Dec 2014 15:42:45 -0500 (EST)
Date: Tue, 2 Dec 2014 15:42:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141202204245.GO357@laptop.dumpdata.com>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Olaf Hering <olaf@aepfle.de>, 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.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 06:51:50PM +0000, M A Young wrote:
> On Tue, 2 Dec 2014, Konrad Rzeszutek Wilk wrote:
> 
> >On Tue, Dec 02, 2014 at 03:44:55PM +0000, Ian Campbell wrote:
> >>On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
> >>>Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
> >>>systemd xenstored dependencies") all service files use the .socket unit
> >>>as startup dependency. While this happens to work for boot it fails for
> >>>shutdown because a .socket does not seem to enforce ordering. When
> >>>xendomains.service runs during shutdown then systemd will stop
> >>>xenstored.service at the same time.
> >>>
> >>>Change all "xenstored.socket" to "xenstored.service" to let systemd know
> >>>that xenstored has to be shutdown after everything else.
> >>>
> >>>Reported-by: Mark Pryor <tlviewer@yahoo.com>
> >>>Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >>>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >>>Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>
> >>Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >>
> >>>Cc: Wei Liu <wei.liu2@citrix.com>
> >>>---
> >>>
> >>>This should go into 4.5 to fix xendomains.service.
> >>
> >>CCing Konrad...
> >
> >CC-ing Michael.
> >
> >Michael, since Fedora is using systemd, did you observe this bug as well?
> >(I think I did, but I might have blamed it on my wacky setup).
> 
> I only tried the xen systemd on xen 4.5-rc2 and didn't have a lot of success
> even when I reverted to Fedora's systemd for xen, so I can't really comment.

Ugh.
> I did have issues with xen systemd which I shall report if they are still
> there in -rc3.

OK, lets then go with this.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> 	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 Dec 02 20:48:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvuND-0002c0-6N; Tue, 02 Dec 2014 20:48:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvuNC-0002bv-1F
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:48:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	30/2D-09842-5A52E745; Tue, 02 Dec 2014 20:48:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417553315!12933160!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28282 invoked from network); 2 Dec 2014 20:48:36 -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; 2 Dec 2014 20:48: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 sB2KmSF2023429
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:48: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
	sB2KmRoH006923
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:48:27 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
	sB2KmQXX003021; Tue, 2 Dec 2014 20:48:26 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:48:26 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0D85711B192; Tue,  2 Dec 2014 15:48:26 -0500 (EST)
Date: Tue, 2 Dec 2014 15:48:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141202204825.GS357@laptop.dumpdata.com>
References: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.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.xen.org,
	david.vrabel@citrix.com, jun.nakajima@intel.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v4 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 Tue, Dec 02, 2014 at 03:19:11PM -0500, Boris Ostrovsky wrote:
> Changes in v4:
> * Added comment describing what we check for in pci_xen_init()
> 

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 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               | 31 +++++++++++++-
>  2 files changed, 120 insertions(+), 2 deletions(-)
>  create mode 100644 arch/x86/include/asm/xen/cpuid.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 Tue Dec 02 20:48:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 20:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvuND-0002c0-6N; Tue, 02 Dec 2014 20:48:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XvuNC-0002bv-1F
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 20:48:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	30/2D-09842-5A52E745; Tue, 02 Dec 2014 20:48:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417553315!12933160!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28282 invoked from network); 2 Dec 2014 20:48:36 -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; 2 Dec 2014 20:48: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 sB2KmSF2023429
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 20:48: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
	sB2KmRoH006923
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 20:48:27 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
	sB2KmQXX003021; Tue, 2 Dec 2014 20:48:26 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 12:48:26 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0D85711B192; Tue,  2 Dec 2014 15:48:26 -0500 (EST)
Date: Tue, 2 Dec 2014 15:48:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141202204825.GS357@laptop.dumpdata.com>
References: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.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.xen.org,
	david.vrabel@citrix.com, jun.nakajima@intel.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v4 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 Tue, Dec 02, 2014 at 03:19:11PM -0500, Boris Ostrovsky wrote:
> Changes in v4:
> * Added comment describing what we check for in pci_xen_init()
> 

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 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               | 31 +++++++++++++-
>  2 files changed, 120 insertions(+), 2 deletions(-)
>  create mode 100644 arch/x86/include/asm/xen/cpuid.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 Tue Dec 02 21:10:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 21:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvuhu-000384-3g; Tue, 02 Dec 2014 21:10:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xvuhs-00037v-5T
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 21:10:00 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	67/00-31453-7AA2E745; Tue, 02 Dec 2014 21:09:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417554597!3572591!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22459 invoked from network); 2 Dec 2014 21:09:58 -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; 2 Dec 2014 21:09:58 -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 sB2L9jx8016160
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 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
	sB2L9hCu000914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 21:09:44 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
	sB2L9gSi007000; Tue, 2 Dec 2014 21:09:42 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 13:09:42 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1659711B1D2; Tue,  2 Dec 2014 16:09:42 -0500 (EST)
Date: Tue, 2 Dec 2014 16:09:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202210941.GA1593@laptop.dumpdata.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
	<1417175443.23604.18.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417175443.23604.18.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, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	tim@xen.org, 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, Nov 28, 2014 at 11:50:43AM +0000, Ian Campbell wrote:
> 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...

Jan acked it.
> 
> > ---
> >  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

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 21:10:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 21:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvuhu-000384-3g; Tue, 02 Dec 2014 21:10:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xvuhs-00037v-5T
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 21:10:00 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	67/00-31453-7AA2E745; Tue, 02 Dec 2014 21:09:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417554597!3572591!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22459 invoked from network); 2 Dec 2014 21:09:58 -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; 2 Dec 2014 21:09:58 -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 sB2L9jx8016160
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 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
	sB2L9hCu000914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 21:09:44 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
	sB2L9gSi007000; Tue, 2 Dec 2014 21:09:42 GMT
Received: from laptop.dumpdata.com (/10.154.122.207)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 13:09:42 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1659711B1D2; Tue,  2 Dec 2014 16:09:42 -0500 (EST)
Date: Tue, 2 Dec 2014 16:09:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141202210941.GA1593@laptop.dumpdata.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
	<1417175443.23604.18.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417175443.23604.18.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, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	tim@xen.org, 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, Nov 28, 2014 at 11:50:43AM +0000, Ian Campbell wrote:
> 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...

Jan acked it.
> 
> > ---
> >  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

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

From xen-devel-bounces@lists.xen.org Tue Dec 02 21:34:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 21:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvv5E-0003s4-N3; Tue, 02 Dec 2014 21:34:08 +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 1Xvv5D-0003rv-LY
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 21:34:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	31/9C-15461-E403E745; Tue, 02 Dec 2014 21:34:06 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417556044!12911995!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21814 invoked from network); 2 Dec 2014 21:34:06 -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; 2 Dec 2014 21:34: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 sB2LY0SB011951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 21:34:01 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
	sB2LXxkv003356
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 21:33:59 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
	sB2LXws5005696; Tue, 2 Dec 2014 21:33:58 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 13:33:58 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com
Date: Tue,  2 Dec 2014 16:34:07 -0500
Message-Id: <1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: dario.faggioli@citrix.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] pci: Do not ignore device's PXM 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>
MIME-Version: 1.0
Content-Type: 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 ACPI provides PXM data for IO devices then dom0 will pass it to
hypervisor during PHYSDEVOP_pci_device_add call. This information,
however, is currently ignored.

We should remember it (in the form of nodeID). We will also print it
when user requests device information dump.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/physdev.c        | 20 +++++++++++++++++---
 xen/drivers/passthrough/pci.c | 13 +++++++++----
 xen/include/xen/pci.h         |  5 ++++-
 3 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 6b3201b..7775f80 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -565,7 +565,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
 
-        ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn, NULL);
+        ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn,
+                             NULL, NUMA_NO_NODE);
         break;
     }
 
@@ -597,13 +598,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         pdev_info.physfn.devfn = manage_pci_ext.physfn.devfn;
         ret = pci_add_device(0, manage_pci_ext.bus,
                              manage_pci_ext.devfn,
-                             &pdev_info);
+                             &pdev_info, NUMA_NO_NODE);
         break;
     }
 
     case PHYSDEVOP_pci_device_add: {
         struct physdev_pci_device_add add;
         struct pci_dev_info pdev_info;
+        int node;
 
         ret = -EFAULT;
         if ( copy_from_guest(&add, arg, 1) != 0 )
@@ -618,7 +620,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         }
         else
             pdev_info.is_virtfn = 0;
-        ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info);
+
+        if ( add.flags & XEN_PCI_DEV_PXM ) {
+            int optarr_off = offsetof(struct physdev_pci_device_add, optarr) /
+                             sizeof(add.optarr[0]);
+
+            if ( copy_from_guest_offset(&add.optarr[0], arg, optarr_off, 1) )
+                break;
+
+            node = pxm_to_node(add.optarr[0]);
+        } else
+            node = NUMA_NO_NODE;
+
+        ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info, node);
         break;
     }
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..898edaa 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -568,7 +568,8 @@ static void pci_enable_acs(struct pci_dev *pdev)
     pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl);
 }
 
-int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
+int pci_add_device(u16 seg, u8 bus, u8 devfn,
+                   const struct pci_dev_info *info, const int node)
 {
     struct pci_seg *pseg;
     struct pci_dev *pdev;
@@ -586,7 +587,8 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
         pdev = pci_get_pdev(seg, info->physfn.bus, info->physfn.devfn);
         spin_unlock(&pcidevs_lock);
         if ( !pdev )
-            pci_add_device(seg, info->physfn.bus, info->physfn.devfn, NULL);
+            pci_add_device(seg, info->physfn.bus, info->physfn.devfn,
+                           NULL, node);
         pdev_type = "virtual function";
     }
     else
@@ -609,6 +611,8 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
     if ( !pdev )
         goto out;
 
+    pdev->node = node;
+
     if ( info )
         pdev->info = *info;
     else if ( !pdev->vf_rlen[0] )
@@ -1191,10 +1195,11 @@ static int _dump_pci_devices(struct pci_seg *pseg, void *arg)
 
     list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list )
     {
-        printk("%04x:%02x:%02x.%u - dom %-3d - MSIs < ",
+        printk("%04x:%02x:%02x.%u - dom %-3d - node %-3d - MSIs < ",
                pseg->nr, pdev->bus,
                PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn),
-               pdev->domain ? pdev->domain->domain_id : -1);
+               pdev->domain ? pdev->domain->domain_id : -1,
+               (pdev->node != NUMA_NO_NODE) ? pdev->node : -1);
         list_for_each_entry ( msi, &pdev->msi_list, list )
                printk("%d ", msi->irq);
         printk(">\n");
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 5f295f3..a2a0a1c 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -56,6 +56,8 @@ struct pci_dev {
 
     u8 phantom_stride;
 
+    int node; /* NUMA node */
+
     enum pdev_type {
         DEV_TYPE_PCI_UNKNOWN,
         DEV_TYPE_PCIe_ENDPOINT,
@@ -102,7 +104,8 @@ void setup_hwdom_pci_devices(struct domain *,
 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 *);
+int pci_add_device(u16 seg, u8 bus, u8 devfn,
+                   const struct pci_dev_info *, const int);
 int pci_remove_device(u16 seg, u8 bus, u8 devfn);
 int pci_ro_device(int seg, int bus, int devfn);
 void arch_pci_ro_device(int seg, int bdf);
-- 
1.8.4.2


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 21:34:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 21:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvv5H-0003sP-2m; Tue, 02 Dec 2014 21:34:11 +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 1Xvv5F-0003s3-6d
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 21:34:09 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	63/8F-17958-0503E745; Tue, 02 Dec 2014 21:34:08 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417556045!10954926!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11983 invoked from network); 2 Dec 2014 21:34:07 -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; 2 Dec 2014 21:34:07 -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 sB2LY1F3012182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 21:34:02 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
	sB2LY0UY003440
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 21:34:01 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
	sB2LXxVn010177; Tue, 2 Dec 2014 21:33:59 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 13:33:59 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com
Date: Tue,  2 Dec 2014 16:34:08 -0500
Message-Id: <1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: dario.faggioli@citrix.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for returning
	IO topology 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>
MIME-Version: 1.0
Content-Type: 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 XEN_SYSCTL_topologyinfo more generic so that it can return both
CPU and IO topology (support for returning the latter is added in the
subsequent patch)

To do so move (and rename) previously used cpu_to_core/cpu_to_socket/
cpu_to_node into struct xen_sysctl_cputopo and move it, together with
newly added struct xen_sysctl_iotopo, to xen_sysctl_topologyinfo.

Add libxl_get_topology() to handle new interface and modify
libxl_get_cpu_topology() to be a wrapper around it.

Adjust xenpm and python's low-level C libraries for new interface.

This change requires bumping XEN_SYSCTL_INTERFACE_VERSION

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/libxl/libxl.c               | 79 ++++++++++++++++++++++++---------------
 tools/libxl/libxl.h               |  4 ++
 tools/libxl/libxl_types.idl       | 12 ++++++
 tools/libxl/libxl_utils.c         |  6 +++
 tools/misc/xenpm.c                | 64 +++++++++++++------------------
 tools/python/xen/lowlevel/xc/xc.c | 38 +++++++------------
 xen/common/sysctl.c               | 43 ++++++++++++---------
 xen/include/public/sysctl.h       | 36 +++++++++++++-----
 8 files changed, 162 insertions(+), 120 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..58cdc3b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5056,11 +5056,37 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out)
 {
     GC_INIT(ctx);
+    libxl_cputopology *cputopology = NULL;
+    libxl_topology *topo;
+    int i;
+
+    topo = libxl_get_topology(ctx);
+    if (topo == NULL) {
+        *nb_cpu_out = 0;
+        goto out;
+    }
+
+    cputopology = libxl__zalloc(NOGC, sizeof(libxl_cputopology) * topo->cpu_num);
+    for (i = 0; i < topo->cpu_num; i++) {
+        cputopology[i].core = topo->cpu[i].core;
+        cputopology[i].socket = topo->cpu[i].socket;
+        cputopology[i].node = topo->cpu[i].node;
+    }
+    *nb_cpu_out = topo->cpu_num;
+
+    libxl_topology_free(topo);
+
+ out:
+    GC_FREE;
+    return cputopology;
+}
+
+libxl_topology *libxl_get_topology(libxl_ctx *ctx)
+{
+    GC_INIT(ctx);
     xc_topologyinfo_t tinfo;
-    DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
-    DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
-    DECLARE_HYPERCALL_BUFFER(xc_cpu_to_node_t, nodemap);
-    libxl_cputopology *ret = NULL;
+    DECLARE_HYPERCALL_BUFFER(xen_sysctl_cputopo_t, cputopo);
+    libxl_topology *ret = NULL;
     int i;
     int max_cpus;
 
@@ -5072,48 +5098,39 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out)
         goto out;
     }
 
-    coremap = xc_hypercall_buffer_alloc
-        (ctx->xch, coremap, sizeof(*coremap) * max_cpus);
-    socketmap = xc_hypercall_buffer_alloc
-        (ctx->xch, socketmap, sizeof(*socketmap) * max_cpus);
-    nodemap = xc_hypercall_buffer_alloc
-        (ctx->xch, nodemap, sizeof(*nodemap) * max_cpus);
-    if ((coremap == NULL) || (socketmap == NULL) || (nodemap == NULL)) {
+    cputopo = xc_hypercall_buffer_alloc(ctx->xch, cputopo,
+                                        sizeof(*cputopo) * max_cpus);
+    if (cputopo == NULL) {
         LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
                             "Unable to allocate hypercall arguments");
         goto fail;
     }
-
-    set_xen_guest_handle(tinfo.cpu_to_core, coremap);
-    set_xen_guest_handle(tinfo.cpu_to_socket, socketmap);
-    set_xen_guest_handle(tinfo.cpu_to_node, nodemap);
+    set_xen_guest_handle(tinfo.cputopo, cputopo);
     tinfo.max_cpu_index = max_cpus - 1;
+
+    set_xen_guest_handle(tinfo.iotopo, HYPERCALL_BUFFER_NULL);
+
     if (xc_topologyinfo(ctx->xch, &tinfo) != 0) {
         LIBXL__LOG_ERRNO(ctx, XTL_ERROR, "Topology info hypercall failed");
         goto fail;
     }
 
-    if (tinfo.max_cpu_index < max_cpus - 1)
-        max_cpus = tinfo.max_cpu_index + 1;
+    ret = libxl__zalloc(NOGC, sizeof(*ret));
+    ret->cpu_num = tinfo.max_cpu_index + 1;
+    ret->cpu = libxl__zalloc(NOGC, sizeof(*(ret->cpu)) * ret->cpu_num);
 
-    ret = libxl__zalloc(NOGC, sizeof(libxl_cputopology) * max_cpus);
-
-    for (i = 0; i < max_cpus; i++) {
-#define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \
-    LIBXL_CPUTOPOLOGY_INVALID_ENTRY : map[i]
-        ret[i].core = V(coremap, i);
-        ret[i].socket = V(socketmap, i);
-        ret[i].node = V(nodemap, i);
+    for (i = 0; i < ret->cpu_num; i++) {
+#define V(map, i) ( cputopo[i].map == INVALID_TOPOLOGY_ID) ? \
+    LIBXL_CPUTOPOLOGY_INVALID_ENTRY :  cputopo[i].map
+        ret->cpu[i].core = V(core, i);
+        ret->cpu[i].socket = V(socket, i);
+        ret->cpu[i].node = V(node, i);
 #undef V
     }
 
-fail:
-    xc_hypercall_buffer_free(ctx->xch, coremap);
-    xc_hypercall_buffer_free(ctx->xch, socketmap);
-    xc_hypercall_buffer_free(ctx->xch, nodemap);
+ fail:
+    xc_hypercall_buffer_free(ctx->xch, cputopo);
 
-    if (ret)
-        *nb_cpu_out = max_cpus;
  out:
     GC_FREE;
     return ret;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c3451bd..5ab008d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1060,6 +1060,10 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nb_vm);
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out);
 void libxl_cputopology_list_free(libxl_cputopology *, int nb_cpu);
 
+#define LIBXL_TOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
+libxl_topology *libxl_get_topology(libxl_ctx *ctx);
+void libxl_topology_free(libxl_topology *);
+
 #define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
 libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
 void libxl_numainfo_list_free(libxl_numainfo *, int nr);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..673b273 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -642,6 +642,18 @@ libxl_cputopology = Struct("cputopology", [
     ("node", uint32),
     ], dir=DIR_OUT)
 
+libxl_iotopology = Struct("iotopology", [
+    ("seg", uint16),
+    ("bus", uint8),
+    ("devfn", uint8),
+    ("node", uint32),
+    ], dir=DIR_OUT)
+
+libxl_topology = Struct("topology", [
+    ("cpu", Array(libxl_cputopology, "cpu_num")),
+    ("dev", Array(libxl_iotopology, "dev_num")),
+    ], dir=DIR_OUT)
+
 libxl_sched_credit_params = Struct("sched_credit_params", [
     ("tslice_ms", integer),
     ("ratelimit_us", integer),
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 58df4f3..70c21a2 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -859,6 +859,12 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
     free(list);
 }
 
+void libxl_topology_free(libxl_topology *tinfo)
+{
+    libxl_topology_dispose(tinfo);
+    free(tinfo);
+}
+
 void libxl_numainfo_list_free(libxl_numainfo *list, int nr)
 {
     int i;
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index e43924c..8fd51d2 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -355,16 +355,11 @@ static void signal_int_handler(int signo)
     int i, j, k;
     struct timeval tv;
     int cx_cap = 0, px_cap = 0;
-    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_core);
-    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_socket);
-    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_node);
+    DECLARE_HYPERCALL_BUFFER(xen_sysctl_cputopo_t, cputopo);
     xc_topologyinfo_t info = { 0 };
 
-    cpu_to_core = xc_hypercall_buffer_alloc(xc_handle, cpu_to_core, sizeof(*cpu_to_core) * MAX_NR_CPU);
-    cpu_to_socket = xc_hypercall_buffer_alloc(xc_handle, cpu_to_socket, sizeof(*cpu_to_socket) * MAX_NR_CPU);
-    cpu_to_node = xc_hypercall_buffer_alloc(xc_handle, cpu_to_node, sizeof(*cpu_to_node) * MAX_NR_CPU);
-
-    if ( cpu_to_core == NULL || cpu_to_socket == NULL || cpu_to_node == NULL )
+    cputopo = xc_hypercall_buffer_alloc(xc_handle, cputopo, sizeof(*cputopo) * MAX_NR_CPU);
+    if ( cputopo == NULL )
     {
 	fprintf(stderr, "failed to allocate hypercall buffers\n");
 	goto out;
@@ -448,11 +443,11 @@ static void signal_int_handler(int signo)
             printf("  Avg freq\t%d\tKHz\n", avgfreq[i]);
     }
 
-    set_xen_guest_handle(info.cpu_to_core, cpu_to_core);
-    set_xen_guest_handle(info.cpu_to_socket, cpu_to_socket);
-    set_xen_guest_handle(info.cpu_to_node, cpu_to_node);
+    set_xen_guest_handle(info.cputopo, cputopo);
     info.max_cpu_index = MAX_NR_CPU - 1;
 
+    set_xen_guest_handle(info.iotopo, HYPERCALL_BUFFER_NULL);
+
     if ( cx_cap && !xc_topologyinfo(xc_handle, &info) )
     {
         uint32_t socket_ids[MAX_NR_CPU];
@@ -465,8 +460,8 @@ static void signal_int_handler(int signo)
         /* check validity */
         for ( i = 0; i <= info.max_cpu_index; i++ )
         {
-            if ( cpu_to_core[i] == INVALID_TOPOLOGY_ID ||
-                 cpu_to_socket[i] == INVALID_TOPOLOGY_ID )
+            if ( cputopo[i].core == INVALID_TOPOLOGY_ID ||
+                 cputopo[i].socket == INVALID_TOPOLOGY_ID )
                 break;
         }
         if ( i > info.max_cpu_index )
@@ -475,20 +470,20 @@ static void signal_int_handler(int signo)
             for ( i = 0; i <= info.max_cpu_index; i++ )
             {
                 for ( j = 0; j < socket_nr; j++ )
-                    if ( cpu_to_socket[i] == socket_ids[j] )
+                    if ( cputopo[i].socket == socket_ids[j] )
                         break;
                 if ( j == socket_nr )
                 {
-                    socket_ids[j] = cpu_to_socket[i];
+                    socket_ids[j] = cputopo[i].socket;
                     socket_nr++;
                 }
 
                 for ( j = 0; j < core_nr; j++ )
-                    if ( cpu_to_core[i] == core_ids[j] )
+                    if ( cputopo[i].core == core_ids[j] )
                         break;
                 if ( j == core_nr )
                 {
-                    core_ids[j] = cpu_to_core[i];
+                    core_ids[j] = cputopo[i].core;
                     core_nr++;
                 }
             }
@@ -501,7 +496,7 @@ static void signal_int_handler(int signo)
 
                 for ( j = 0; j <= info.max_cpu_index; j++ )
                 {
-                    if ( cpu_to_socket[j] == socket_ids[i] )
+                    if ( cputopo[j].socket == socket_ids[i] )
                         break;
                 }
                 printf("\nSocket %d\n", socket_ids[i]);
@@ -520,8 +515,8 @@ static void signal_int_handler(int signo)
                 {
                     for ( j = 0; j <= info.max_cpu_index; j++ )
                     {
-                        if ( cpu_to_socket[j] == socket_ids[i] &&
-                             cpu_to_core[j] == core_ids[k] )
+                        if ( cputopo[j].socket == socket_ids[i] &&
+                             cputopo[j].core == core_ids[k] )
                             break;
                     }
                     printf("\t Core %d CPU %d\n", core_ids[k], j);
@@ -556,9 +551,7 @@ static void signal_int_handler(int signo)
     free(sum);
     free(avgfreq);
 out:
-    xc_hypercall_buffer_free(xc_handle, cpu_to_core);
-    xc_hypercall_buffer_free(xc_handle, cpu_to_socket);
-    xc_hypercall_buffer_free(xc_handle, cpu_to_node);
+    xc_hypercall_buffer_free(xc_handle, cputopo);
     xc_interface_close(xc_handle);
     exit(0);
 }
@@ -965,27 +958,22 @@ void scaling_governor_func(int argc, char *argv[])
 
 void cpu_topology_func(int argc, char *argv[])
 {
-    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_core);
-    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_socket);
-    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_node);
+    DECLARE_HYPERCALL_BUFFER(xen_sysctl_cputopo_t, cputopo);
     xc_topologyinfo_t info = { 0 };
     int i, rc = ENOMEM;
 
-    cpu_to_core = xc_hypercall_buffer_alloc(xc_handle, cpu_to_core, sizeof(*cpu_to_core) * MAX_NR_CPU);
-    cpu_to_socket = xc_hypercall_buffer_alloc(xc_handle, cpu_to_socket, sizeof(*cpu_to_socket) * MAX_NR_CPU);
-    cpu_to_node = xc_hypercall_buffer_alloc(xc_handle, cpu_to_node, sizeof(*cpu_to_node) * MAX_NR_CPU);
-
-    if ( cpu_to_core == NULL || cpu_to_socket == NULL || cpu_to_node == NULL )
+    cputopo = xc_hypercall_buffer_alloc(xc_handle, cputopo, sizeof(*cputopo) * MAX_NR_CPU);
+    if ( cputopo == NULL )
     {
 	fprintf(stderr, "failed to allocate hypercall buffers\n");
 	goto out;
     }
 
-    set_xen_guest_handle(info.cpu_to_core, cpu_to_core);
-    set_xen_guest_handle(info.cpu_to_socket, cpu_to_socket);
-    set_xen_guest_handle(info.cpu_to_node, cpu_to_node);
+    set_xen_guest_handle(info.cputopo, cputopo);
     info.max_cpu_index = MAX_NR_CPU-1;
 
+    set_xen_guest_handle(info.iotopo, HYPERCALL_BUFFER_NULL);
+
     if ( xc_topologyinfo(xc_handle, &info) )
     {
         rc = errno;
@@ -1000,16 +988,14 @@ void cpu_topology_func(int argc, char *argv[])
     printf("CPU\tcore\tsocket\tnode\n");
     for ( i = 0; i <= info.max_cpu_index; i++ )
     {
-        if ( cpu_to_core[i] == INVALID_TOPOLOGY_ID )
+        if ( cputopo[i].core == INVALID_TOPOLOGY_ID )
             continue;
         printf("CPU%d\t %d\t %d\t %d\n",
-               i, cpu_to_core[i], cpu_to_socket[i], cpu_to_node[i]);
+               i, cputopo[i].core, cputopo[i].socket, cputopo[i].node);
     }
     rc = 0;
 out:
-    xc_hypercall_buffer_free(xc_handle, cpu_to_core);
-    xc_hypercall_buffer_free(xc_handle, cpu_to_socket);
-    xc_hypercall_buffer_free(xc_handle, cpu_to_node);
+    xc_hypercall_buffer_free(xc_handle, cputopo);
     if ( rc )
         exit(rc);
 }
diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
index d95d459..1f9252a 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1226,25 +1226,17 @@ static PyObject *pyxc_topologyinfo(XcObject *self)
     int i, max_cpu_index;
     PyObject *ret_obj = NULL;
     PyObject *cpu_to_core_obj, *cpu_to_socket_obj, *cpu_to_node_obj;
-    DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
-    DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
-    DECLARE_HYPERCALL_BUFFER(xc_cpu_to_node_t, nodemap);
 
-    coremap = xc_hypercall_buffer_alloc(self->xc_handle, coremap, sizeof(*coremap) * (MAX_CPU_INDEX+1));
-    if ( coremap == NULL )
-        goto out;
-    socketmap = xc_hypercall_buffer_alloc(self->xc_handle, socketmap, sizeof(*socketmap) * (MAX_CPU_INDEX+1));
-    if ( socketmap == NULL  )
-        goto out;
-    nodemap = xc_hypercall_buffer_alloc(self->xc_handle, nodemap, sizeof(*nodemap) * (MAX_CPU_INDEX+1));
-    if ( nodemap == NULL )
-        goto out;
+    DECLARE_HYPERCALL_BUFFER(xen_sysctl_cputopo_t, cputopo);
 
-    set_xen_guest_handle(tinfo.cpu_to_core, coremap);
-    set_xen_guest_handle(tinfo.cpu_to_socket, socketmap);
-    set_xen_guest_handle(tinfo.cpu_to_node, nodemap);
+    cputopo = xc_hypercall_buffer_alloc(self->xc_handle, cputopo, sizeof(*cputopo) * (MAX_CPU_INDEX+1));
+    if ( cputopo == NULL )
+	goto out;
+    set_xen_guest_handle(tinfo.cputopo, cputopo);
     tinfo.max_cpu_index = MAX_CPU_INDEX;
 
+    set_xen_guest_handle(tinfo.iotopo, HYPERCALL_BUFFER_NULL);
+
     if ( xc_topologyinfo(self->xc_handle, &tinfo) != 0 )
         goto out;
 
@@ -1258,35 +1250,35 @@ static PyObject *pyxc_topologyinfo(XcObject *self)
     cpu_to_node_obj = PyList_New(0);
     for ( i = 0; i <= max_cpu_index; i++ )
     {
-        if ( coremap[i] == INVALID_TOPOLOGY_ID )
+        if ( cputopo[i].core == INVALID_TOPOLOGY_ID )
         {
             PyList_Append(cpu_to_core_obj, Py_None);
         }
         else
         {
-            PyObject *pyint = PyInt_FromLong(coremap[i]);
+            PyObject *pyint = PyInt_FromLong(cputopo[i].core);
             PyList_Append(cpu_to_core_obj, pyint);
             Py_DECREF(pyint);
         }
 
-        if ( socketmap[i] == INVALID_TOPOLOGY_ID )
+        if ( cputopo[i].socket == INVALID_TOPOLOGY_ID )
         {
             PyList_Append(cpu_to_socket_obj, Py_None);
         }
         else
         {
-            PyObject *pyint = PyInt_FromLong(socketmap[i]);
+            PyObject *pyint = PyInt_FromLong(cputopo[i].socket);
             PyList_Append(cpu_to_socket_obj, pyint);
             Py_DECREF(pyint);
         }
 
-        if ( nodemap[i] == INVALID_TOPOLOGY_ID )
+        if ( cputopo[i].node == INVALID_TOPOLOGY_ID )
         {
             PyList_Append(cpu_to_node_obj, Py_None);
         }
         else
         {
-            PyObject *pyint = PyInt_FromLong(nodemap[i]);
+            PyObject *pyint = PyInt_FromLong(cputopo[i].node);
             PyList_Append(cpu_to_node_obj, pyint);
             Py_DECREF(pyint);
         }
@@ -1304,9 +1296,7 @@ static PyObject *pyxc_topologyinfo(XcObject *self)
     Py_DECREF(cpu_to_node_obj);
 
 out:
-    xc_hypercall_buffer_free(self->xc_handle, coremap);
-    xc_hypercall_buffer_free(self->xc_handle, socketmap);
-    xc_hypercall_buffer_free(self->xc_handle, nodemap);
+    xc_hypercall_buffer_free(self->xc_handle, cputopo);
     return ret_obj ? ret_obj : pyxc_error_to_exception(self->xc_handle);
 #undef MAX_CPU_INDEX
 }
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0cb6ee1..d4dc8ed 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -327,32 +327,41 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 
         last_online_cpu = cpumask_last(&cpu_online_map);
         max_cpu_index = min_t(uint32_t, ti->max_cpu_index, last_online_cpu);
-        ti->max_cpu_index = last_online_cpu;
+
+        if ( guest_handle_is_null(ti->cputopo) )
+        {
+            ret = -EINVAL;
+            break;
+        }
 
         for ( i = 0; i <= max_cpu_index; i++ )
         {
-            if ( !guest_handle_is_null(ti->cpu_to_core) )
-            {
-                uint32_t core = cpu_online(i) ? cpu_to_core(i) : ~0u;
-                if ( copy_to_guest_offset(ti->cpu_to_core, i, &core, 1) )
-                    break;
-            }
-            if ( !guest_handle_is_null(ti->cpu_to_socket) )
+            xen_sysctl_cputopo_t cputopo;
+
+            if ( cpu_online(i) )
             {
-                uint32_t socket = cpu_online(i) ? cpu_to_socket(i) : ~0u;
-                if ( copy_to_guest_offset(ti->cpu_to_socket, i, &socket, 1) )
-                    break;
+                cputopo.core = cpu_to_core(i);
+                cputopo.socket = cpu_to_socket(i);
+                cputopo.node = cpu_to_node(i);
             }
-            if ( !guest_handle_is_null(ti->cpu_to_node) )
+            else
+                cputopo.core = cputopo.socket =
+                    cputopo.node = INVALID_TOPOLOGY_ID;
+
+            if ( copy_to_guest_offset(ti->cputopo, i, &cputopo, 1) )
             {
-                uint32_t node = cpu_online(i) ? cpu_to_node(i) : ~0u;
-                if ( copy_to_guest_offset(ti->cpu_to_node, i, &node, 1) )
-                    break;
+                ret = -EFAULT;
+                break;
             }
         }
 
-        ret = ((i <= max_cpu_index) || copy_to_guest(u_sysctl, op, 1))
-            ? -EFAULT : 0;
+        if ( !ret && (ti->max_cpu_index != last_online_cpu) )
+        {
+             ti->max_cpu_index = last_online_cpu;
+             if ( __copy_field_to_guest(u_sysctl, op,
+                                        u.topologyinfo.max_cpu_index) )
+                ret = -EFAULT;
+        }
     }
     break;
 
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index b3713b3..e1d1348 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -34,7 +34,7 @@
 #include "xen.h"
 #include "domctl.h"
 
-#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000B
+#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000C
 
 /*
  * Read console content from Xen buffer ring.
@@ -464,26 +464,44 @@ DEFINE_XEN_GUEST_HANDLE(xen_sysctl_lockprof_op_t);
 
 /* XEN_SYSCTL_topologyinfo */
 #define INVALID_TOPOLOGY_ID  (~0U)
+
+struct xen_sysctl_cputopo {
+    uint32_t core;
+    uint32_t socket;
+    uint32_t node;
+};
+typedef struct xen_sysctl_cputopo xen_sysctl_cputopo_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cputopo_t);
+
+struct xen_sysctl_iotopo {
+    uint16_t seg;
+    uint8_t bus;
+    uint8_t devfn;
+    uint32_t node;
+};
+typedef struct xen_sysctl_iotopo xen_sysctl_iotopo_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_iotopo_t);
+
 struct xen_sysctl_topologyinfo {
     /*
      * IN: maximum addressable entry in the caller-provided arrays.
-     * OUT: largest cpu identifier in the system.
+     * OUT: largest cpu identifier or max number of devices 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;
+    uint32_t max_devs;
 
     /*
      * 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:
+     * for each cpu and/or node for each PCI device.
+     * If information for a particular entry is not avalable it is set to
+     * INVALID_TOPOLOGY_ID.
+     * The number of array elements for CPU topology written by the sysctl is:
      *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
      */
-    XEN_GUEST_HANDLE_64(uint32) cpu_to_core;
-    XEN_GUEST_HANDLE_64(uint32) cpu_to_socket;
-    XEN_GUEST_HANDLE_64(uint32) cpu_to_node;
+    XEN_GUEST_HANDLE_64(xen_sysctl_cputopo_t) cputopo;
+    XEN_GUEST_HANDLE_64(xen_sysctl_iotopo_t) iotopo;
 };
 typedef struct xen_sysctl_topologyinfo xen_sysctl_topologyinfo_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_topologyinfo_t);
-- 
1.8.4.2


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 21:34:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 21:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvv5H-0003si-LV; Tue, 02 Dec 2014 21:34:11 +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 1Xvv5G-0003sF-39
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 21:34:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3D/D0-09842-1503E745; Tue, 02 Dec 2014 21:34:09 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417556047!12966200!1
X-Originating-IP: [156.151.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 1270 invoked from network); 2 Dec 2014 21:34:08 -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; 2 Dec 2014 21:34:08 -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 sB2LY0Bx002767
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 21:34:01 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
	sB2LXwIl003341
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 21:33:59 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
	sB2LXvMa010113; Tue, 2 Dec 2014 21:33:58 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 13:33:57 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com
Date: Tue,  2 Dec 2014 16:34:06 -0500
Message-Id: <1417556050-23364-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: dario.faggioli@citrix.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/4] Display IO topology when PXM data is
	available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

4 patches that add interface for querying hypervisor about device
topology and allow 'xl info -n' display this information if PXM object
is provided by ACPI.

The patches are:

* Store PXM data (nodeID) in pci_dev during PHYSDEVOP_pci_device_add
  hypercall
* Modify XEN_SYSCTL_topologyinfo so that it can return both CPU and
  device topology data. Add corresponding libxl interface
* Use new interface to query the hypervisor about topology and print
  it with 'xl info -n'
* Replace all users of old cpu topology interface with the new
  call. This patch is optional.

Boris Ostrovsky (4):
  pci: Do not ignore device's PXM information
  sysctl/libxl: Add interface for returning IO topology data
  sysctl/libxl: Provide information about IO topology
  libxl: Switch to using new topology interface

 tools/libxl/libxl.c               | 130 +++++++++++++++++++++++++-------------
 tools/libxl/libxl.h               |   4 ++
 tools/libxl/libxl_freebsd.c       |  12 ++++
 tools/libxl/libxl_internal.h      |   5 ++
 tools/libxl/libxl_linux.c         |  74 ++++++++++++++++++++++
 tools/libxl/libxl_netbsd.c        |  12 ++++
 tools/libxl/libxl_numa.c          |  14 ++--
 tools/libxl/libxl_types.idl       |  12 ++++
 tools/libxl/libxl_utils.c         |  30 +++++----
 tools/libxl/xl_cmdimpl.c          |  75 +++++++++++++---------
 tools/misc/xenpm.c                |  64 ++++++++-----------
 tools/python/xen/lowlevel/xc/xc.c |  38 ++++-------
 xen/arch/x86/physdev.c            |  20 +++++-
 xen/common/sysctl.c               |  69 +++++++++++++++-----
 xen/drivers/passthrough/pci.c     |  13 ++--
 xen/include/public/sysctl.h       |  36 ++++++++---
 xen/include/xen/pci.h             |   5 +-
 17 files changed, 424 insertions(+), 189 deletions(-)

-- 
1.8.4.2


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 21:34:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 21:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvv5I-0003sv-10; Tue, 02 Dec 2014 21:34:12 +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 1Xvv5G-0003sG-Bc
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 21:34:10 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C3/C9-29352-1503E745; Tue, 02 Dec 2014 21:34:09 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417556047!7038082!1
X-Originating-IP: [156.151.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 20747 invoked from network); 2 Dec 2014 21:34:08 -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; 2 Dec 2014 21:34:08 -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 sB2LY1so003057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 21:34:02 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
	sB2LY0Ma010212
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 21:34:01 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
	sB2LY0H9003397; Tue, 2 Dec 2014 21:34:00 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 13:33:59 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com
Date: Tue,  2 Dec 2014 16:34:09 -0500
Message-Id: <1417556050-23364-4-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: dario.faggioli@citrix.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] sysctl/libxl: Provide information about IO
	topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 to XEN_SYSCTL_topologyinfo to return IO topology data.

Modify libxl_get_topology() to request this data, provide OS-dependent
helper functions that determine which devices we are inquiring about
(Linux only).

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/libxl/libxl.c          | 28 ++++++++++++++++-
 tools/libxl/libxl_freebsd.c  | 12 +++++++
 tools/libxl/libxl_internal.h |  5 +++
 tools/libxl/libxl_linux.c    | 74 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_netbsd.c   | 12 +++++++
 tools/libxl/xl_cmdimpl.c     | 31 ++++++++++++++-----
 xen/common/sysctl.c          | 30 ++++++++++++++++++
 7 files changed, 183 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 58cdc3b..ee103ac 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5086,6 +5086,7 @@ libxl_topology *libxl_get_topology(libxl_ctx *ctx)
     GC_INIT(ctx);
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xen_sysctl_cputopo_t, cputopo);
+    DECLARE_HYPERCALL_BUFFER(xen_sysctl_iotopo_t, iotopo);
     libxl_topology *ret = NULL;
     int i;
     int max_cpus;
@@ -5108,7 +5109,20 @@ libxl_topology *libxl_get_topology(libxl_ctx *ctx)
     set_xen_guest_handle(tinfo.cputopo, cputopo);
     tinfo.max_cpu_index = max_cpus - 1;
 
-    set_xen_guest_handle(tinfo.iotopo, HYPERCALL_BUFFER_NULL);
+    tinfo.max_devs = libxl_pci_numdevs(ctx);
+    if (tinfo.max_devs > 0) {
+        iotopo = xc_hypercall_buffer_alloc(ctx->xch, iotopo,
+                                           sizeof(*iotopo) * tinfo.max_devs);
+        if (iotopo != NULL) {
+            if (libxl_pci_topology_init(ctx, iotopo, tinfo.max_devs))
+                tinfo.max_devs = 0;
+        } else
+            tinfo.max_devs = 0;
+    }
+    if (tinfo.max_devs > 0)
+        set_xen_guest_handle(tinfo.iotopo, iotopo);
+    else
+        set_xen_guest_handle(tinfo.iotopo, HYPERCALL_BUFFER_NULL);
 
     if (xc_topologyinfo(ctx->xch, &tinfo) != 0) {
         LIBXL__LOG_ERRNO(ctx, XTL_ERROR, "Topology info hypercall failed");
@@ -5128,8 +5142,20 @@ libxl_topology *libxl_get_topology(libxl_ctx *ctx)
 #undef V
     }
 
+    ret->dev_num = tinfo.max_devs;
+    ret->dev = libxl__zalloc(NOGC, sizeof(libxl_iotopology) * ret->dev_num);
+
+    for (i = 0; i < tinfo.max_devs; i++) {
+        ret->dev[i].seg = iotopo[i].seg;
+        ret->dev[i].bus = iotopo[i].bus;
+        ret->dev[i].devfn = iotopo[i].devfn;
+        ret->dev[i].node = (iotopo[i].node == INVALID_TOPOLOGY_ID) ?
+                           LIBXL_TOPOLOGY_INVALID_ENTRY : iotopo[i].node;
+    }
+
  fail:
     xc_hypercall_buffer_free(ctx->xch, cputopo);
+    xc_hypercall_buffer_free(ctx->xch, iotopo);
 
  out:
     GC_FREE;
diff --git a/tools/libxl/libxl_freebsd.c b/tools/libxl/libxl_freebsd.c
index e8b88b3..8695a78 100644
--- a/tools/libxl/libxl_freebsd.c
+++ b/tools/libxl/libxl_freebsd.c
@@ -131,3 +131,15 @@ libxl_device_model_version libxl__default_device_model(libxl__gc *gc)
 {
     return LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
 }
+
+int libxl_pci_numdevs(libxl_ctx *ctx)
+{
+    return ERROR_NI;
+}
+
+int libxl_pci_topology_init(libxl_ctx *ctx,
+			    xen_sysctl_iotopo_t *iotopo,
+			    int numdev)
+{
+    return ERROR_NI;
+}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..c3a4194 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1168,6 +1168,11 @@ _hidden int libxl__try_phy_backend(mode_t st_mode);
 
 _hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid);
 
+_hidden int libxl_pci_numdevs(libxl_ctx *ctx);
+_hidden int libxl_pci_topology_init(libxl_ctx *ctx,
+                                    xen_sysctl_iotopo_t *iotopo,
+                                    int numdev);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index ea5d8c1..884c042 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -279,3 +279,77 @@ libxl_device_model_version libxl__default_device_model(libxl__gc *gc)
 {
     return LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
 }
+
+/* These two routines are "inspired" by pciutils */
+int libxl_pci_numdevs(libxl_ctx *ctx)
+{
+    DIR *dir;
+    struct dirent *entry;
+    int numdev = 0;
+
+    dir = opendir("/sys/bus/pci/devices");
+    if (!dir) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, errno,
+                            "Cannot open /sys/bus/pci/devices");
+        return ERROR_FAIL;
+    }
+
+    while ((entry = readdir(dir))) {
+        /* ".", ".." or a special non-device perhaps */
+        if (entry->d_name[0] == '.')
+            continue;
+        numdev++;
+    }
+    closedir(dir);
+
+    return numdev;
+}
+
+int libxl_pci_topology_init(libxl_ctx *ctx,
+                            xen_sysctl_iotopo_t *iotopo,
+			    int numdev)
+{
+
+    DIR *dir;
+    struct dirent *entry;
+    int i;
+
+    dir = opendir("/sys/bus/pci/devices");
+    if (!dir) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, errno,
+                            "Cannot open /sys/bus/pci/devices");
+        return ERROR_FAIL;
+    }
+
+    i = 0;
+    while ((entry = readdir(dir))) {
+        unsigned int dom, bus, dev, func;
+
+        /* ".", ".." or a special non-device perhaps */
+        if (entry->d_name[0] == '.')
+            continue;
+
+        if (i == numdev) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Too many devices\n");
+            closedir(dir);
+            return ERROR_FAIL;
+        }
+
+        if (sscanf(entry->d_name, "%x:%x:%x.%d", &dom, &bus, &dev, &func) < 4) {
+            LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, errno,
+                                "Cannot open /sys/bus/pci/devices");
+            closedir(dir);
+            return ERROR_FAIL;
+        }
+
+        iotopo[i].seg = dom;
+        iotopo[i].bus = bus;
+        iotopo[i].devfn = ((dev & 0x1f) << 3) | (func & 7);
+
+        i++;
+    }
+
+    closedir(dir);
+
+    return 0;
+}
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index 898e160..0946b64 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -95,3 +95,15 @@ libxl_device_model_version libxl__default_device_model(libxl__gc *gc)
 {
     return LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
 }
+
+int libxl_pci_numdevs(libxl_ctx *ctx)
+{
+    return ERROR_NI;
+}
+
+int libxl_pci_topology_init(libxl_ctx *ctx,
+			    xen_sysctl_iotopo_t *iotopo,
+			    int numdev)
+{
+    return ERROR_NI;
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9afef3f..fd9beb3 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5186,25 +5186,40 @@ static void output_numainfo(void)
 
 static void output_topologyinfo(void)
 {
-    libxl_cputopology *info;
-    int i, nr;
+    libxl_topology *info;
+    int i, valid_devs = 0;
 
-    info = libxl_get_cpu_topology(ctx, &nr);
+    info = libxl_get_topology(ctx);
     if (info == NULL) {
-        fprintf(stderr, "libxl_get_topologyinfo failed.\n");
+        fprintf(stderr, "libxl_get_topology failed.\n");
         return;
     }
 
     printf("cpu_topology           :\n");
     printf("cpu:    core    socket     node\n");
 
-    for (i = 0; i < nr; i++) {
-        if (info[i].core != LIBXL_CPUTOPOLOGY_INVALID_ENTRY)
+    for (i = 0; i < info->cpu_num; i++) {
+        if (info->cpu[i].core != LIBXL_CPUTOPOLOGY_INVALID_ENTRY)
             printf("%3d:    %4d     %4d     %4d\n", i,
-                   info[i].core, info[i].socket, info[i].node);
+                   info->cpu[i].core, info->cpu[i].socket, info->cpu[i].node);
     }
 
-    libxl_cputopology_list_free(info, nr);
+    printf("device topology        :\n");
+    printf("device           node\n");
+    for (i = 0; i < info->dev_num; i++) {
+        libxl_iotopology *dev = &info->dev[i];
+
+        if (dev->node != LIBXL_TOPOLOGY_INVALID_ENTRY) {
+	    printf("%04x:%02x:%02x.%01x      %d\n", dev->seg, dev->bus,
+                  ((dev->devfn >> 3) & 0x1f), (dev->devfn & 7), dev->node);
+            valid_devs++;
+        } 
+    }
+
+    if (valid_devs == 0)
+        printf(" No device topology data available\n");
+
+    libxl_topology_free(info);
 
     return;
 }
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d4dc8ed..a82e0ed 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -328,6 +328,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         last_online_cpu = cpumask_last(&cpu_online_map);
         max_cpu_index = min_t(uint32_t, ti->max_cpu_index, last_online_cpu);
 
+        /* CPU topology buffers should always be provided */
         if ( guest_handle_is_null(ti->cputopo) )
         {
             ret = -EINVAL;
@@ -362,6 +363,35 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
                                         u.topologyinfo.max_cpu_index) )
                 ret = -EFAULT;
         }
+
+        if ( !ret && !guest_handle_is_null(ti->iotopo) )
+        {
+            for ( i = 0; i < ti->max_devs; i++ )
+            {
+                xen_sysctl_iotopo_t iotopo;
+                struct pci_dev *pdev;
+
+                if ( copy_from_guest_offset(&iotopo, ti->iotopo, i, 1) )
+                {
+                    ret = -EFAULT;
+                    break;
+                }
+
+                spin_lock(&pcidevs_lock);
+                pdev = pci_get_pdev(iotopo.seg, iotopo.bus, iotopo.devfn);
+                if ( !pdev || (pdev->node == NUMA_NO_NODE) )
+                    iotopo.node = INVALID_TOPOLOGY_ID;
+                else
+                    iotopo.node = pdev->node;
+                spin_unlock(&pcidevs_lock);
+
+                if ( copy_to_guest_offset(ti->iotopo, i, &iotopo, 1) )
+                {
+                    ret = -EFAULT;
+                    break;
+                }
+            }
+        }
     }
     break;
 
-- 
1.8.4.2


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 21:34:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 21:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvv5E-0003s4-N3; Tue, 02 Dec 2014 21:34:08 +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 1Xvv5D-0003rv-LY
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 21:34:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	31/9C-15461-E403E745; Tue, 02 Dec 2014 21:34:06 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417556044!12911995!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21814 invoked from network); 2 Dec 2014 21:34:06 -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; 2 Dec 2014 21:34: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 sB2LY0SB011951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 21:34:01 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
	sB2LXxkv003356
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 21:33:59 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
	sB2LXws5005696; Tue, 2 Dec 2014 21:33:58 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 13:33:58 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com
Date: Tue,  2 Dec 2014 16:34:07 -0500
Message-Id: <1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: dario.faggioli@citrix.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] pci: Do not ignore device's PXM 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>
MIME-Version: 1.0
Content-Type: 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 ACPI provides PXM data for IO devices then dom0 will pass it to
hypervisor during PHYSDEVOP_pci_device_add call. This information,
however, is currently ignored.

We should remember it (in the form of nodeID). We will also print it
when user requests device information dump.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/physdev.c        | 20 +++++++++++++++++---
 xen/drivers/passthrough/pci.c | 13 +++++++++----
 xen/include/xen/pci.h         |  5 ++++-
 3 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 6b3201b..7775f80 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -565,7 +565,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
 
-        ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn, NULL);
+        ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn,
+                             NULL, NUMA_NO_NODE);
         break;
     }
 
@@ -597,13 +598,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         pdev_info.physfn.devfn = manage_pci_ext.physfn.devfn;
         ret = pci_add_device(0, manage_pci_ext.bus,
                              manage_pci_ext.devfn,
-                             &pdev_info);
+                             &pdev_info, NUMA_NO_NODE);
         break;
     }
 
     case PHYSDEVOP_pci_device_add: {
         struct physdev_pci_device_add add;
         struct pci_dev_info pdev_info;
+        int node;
 
         ret = -EFAULT;
         if ( copy_from_guest(&add, arg, 1) != 0 )
@@ -618,7 +620,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         }
         else
             pdev_info.is_virtfn = 0;
-        ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info);
+
+        if ( add.flags & XEN_PCI_DEV_PXM ) {
+            int optarr_off = offsetof(struct physdev_pci_device_add, optarr) /
+                             sizeof(add.optarr[0]);
+
+            if ( copy_from_guest_offset(&add.optarr[0], arg, optarr_off, 1) )
+                break;
+
+            node = pxm_to_node(add.optarr[0]);
+        } else
+            node = NUMA_NO_NODE;
+
+        ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info, node);
         break;
     }
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..898edaa 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -568,7 +568,8 @@ static void pci_enable_acs(struct pci_dev *pdev)
     pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl);
 }
 
-int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
+int pci_add_device(u16 seg, u8 bus, u8 devfn,
+                   const struct pci_dev_info *info, const int node)
 {
     struct pci_seg *pseg;
     struct pci_dev *pdev;
@@ -586,7 +587,8 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
         pdev = pci_get_pdev(seg, info->physfn.bus, info->physfn.devfn);
         spin_unlock(&pcidevs_lock);
         if ( !pdev )
-            pci_add_device(seg, info->physfn.bus, info->physfn.devfn, NULL);
+            pci_add_device(seg, info->physfn.bus, info->physfn.devfn,
+                           NULL, node);
         pdev_type = "virtual function";
     }
     else
@@ -609,6 +611,8 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
     if ( !pdev )
         goto out;
 
+    pdev->node = node;
+
     if ( info )
         pdev->info = *info;
     else if ( !pdev->vf_rlen[0] )
@@ -1191,10 +1195,11 @@ static int _dump_pci_devices(struct pci_seg *pseg, void *arg)
 
     list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list )
     {
-        printk("%04x:%02x:%02x.%u - dom %-3d - MSIs < ",
+        printk("%04x:%02x:%02x.%u - dom %-3d - node %-3d - MSIs < ",
                pseg->nr, pdev->bus,
                PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn),
-               pdev->domain ? pdev->domain->domain_id : -1);
+               pdev->domain ? pdev->domain->domain_id : -1,
+               (pdev->node != NUMA_NO_NODE) ? pdev->node : -1);
         list_for_each_entry ( msi, &pdev->msi_list, list )
                printk("%d ", msi->irq);
         printk(">\n");
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 5f295f3..a2a0a1c 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -56,6 +56,8 @@ struct pci_dev {
 
     u8 phantom_stride;
 
+    int node; /* NUMA node */
+
     enum pdev_type {
         DEV_TYPE_PCI_UNKNOWN,
         DEV_TYPE_PCIe_ENDPOINT,
@@ -102,7 +104,8 @@ void setup_hwdom_pci_devices(struct domain *,
 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 *);
+int pci_add_device(u16 seg, u8 bus, u8 devfn,
+                   const struct pci_dev_info *, const int);
 int pci_remove_device(u16 seg, u8 bus, u8 devfn);
 int pci_ro_device(int seg, int bus, int devfn);
 void arch_pci_ro_device(int seg, int bdf);
-- 
1.8.4.2


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 21:34:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 21:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvv5K-0003tR-E9; Tue, 02 Dec 2014 21:34:14 +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 1Xvv5I-0003t4-LR
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 21:34:12 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	D9/EA-02957-4503E745; Tue, 02 Dec 2014 21:34:12 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417556048!7142939!1
X-Originating-IP: [156.151.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 7111 invoked from network); 2 Dec 2014 21:34:10 -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; 2 Dec 2014 21:34: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 sB2LY2uD003082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 21:34:02 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
	sB2LY1Hu005879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 21:34:01 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
	sB2LY0Tj003495; Tue, 2 Dec 2014 21:34:00 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 13:34:00 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com
Date: Tue,  2 Dec 2014 16:34:10 -0500
Message-Id: <1417556050-23364-5-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: dario.faggioli@citrix.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] libxl: Switch to using new topology
	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>
MIME-Version: 1.0
Content-Type: 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 current users of libxl_get_cpu_topology() call
libxl_get_topology() instead.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/libxl/libxl.c       | 25 ++++++++++++-------------
 tools/libxl/libxl_numa.c  | 14 +++++++-------
 tools/libxl/libxl_utils.c | 24 ++++++++++++------------
 tools/libxl/xl_cmdimpl.c  | 44 +++++++++++++++++++++-----------------------
 4 files changed, 52 insertions(+), 55 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ee103ac..5398e41 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -6410,30 +6410,29 @@ int libxl_cpupool_cpuadd(libxl_ctx *ctx, uint32_t poolid, int cpu)
 int libxl_cpupool_cpuadd_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus)
 {
     int rc = 0;
-    int cpu, nr;
+    int cpu;
     libxl_bitmap freemap;
-    libxl_cputopology *topology;
+    libxl_topology *topology;
 
     if (libxl_get_freecpus(ctx, &freemap)) {
         return ERROR_FAIL;
     }
 
-    topology = libxl_get_cpu_topology(ctx, &nr);
+    topology = libxl_get_topology(ctx);
     if (!topology) {
         rc = ERROR_FAIL;
         goto out;
     }
 
     *cpus = 0;
-    for (cpu = 0; cpu < nr; cpu++) {
-        if (libxl_bitmap_test(&freemap, cpu) && (topology[cpu].node == node) &&
+    for (cpu = 0; cpu < topology->cpu_num; cpu++) {
+        if (libxl_bitmap_test(&freemap, cpu) && (topology->cpu[cpu].node == node) &&
             !libxl_cpupool_cpuadd(ctx, poolid, cpu)) {
                 (*cpus)++;
         }
-        libxl_cputopology_dispose(&topology[cpu]);
     }
 
-    free(topology);
+    libxl_topology_free(topology);
 out:
     libxl_bitmap_dispose(&freemap);
     return rc;
@@ -6457,8 +6456,8 @@ int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int
     int ret = 0;
     int n_pools;
     int p;
-    int cpu, nr_cpus;
-    libxl_cputopology *topology;
+    int cpu;
+    libxl_topology *topology;
     libxl_cpupoolinfo *poolinfo;
 
     poolinfo = libxl_list_cpupool(ctx, &n_pools);
@@ -6466,7 +6465,7 @@ int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int
         return ERROR_NOMEM;
     }
 
-    topology = libxl_get_cpu_topology(ctx, &nr_cpus);
+    topology = libxl_get_topology(ctx);
     if (!topology) {
         ret = ERROR_FAIL;
         goto out;
@@ -6475,8 +6474,8 @@ int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int
     *cpus = 0;
     for (p = 0; p < n_pools; p++) {
         if (poolinfo[p].poolid == poolid) {
-            for (cpu = 0; cpu < nr_cpus; cpu++) {
-                if ((topology[cpu].node == node) &&
+            for (cpu = 0; cpu < topology->cpu_num; cpu++) {
+                if ((topology->cpu[cpu].node == node) &&
                     libxl_bitmap_test(&poolinfo[p].cpumap, cpu) &&
                     !libxl_cpupool_cpuremove(ctx, poolid, cpu)) {
                         (*cpus)++;
@@ -6485,7 +6484,7 @@ int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int
         }
     }
 
-    libxl_cputopology_list_free(topology, nr_cpus);
+    libxl_topology_free(topology);
 
 out:
     libxl_cpupoolinfo_list_free(poolinfo, n_pools);
diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
index 94ca4fe..c809dc0 100644
--- a/tools/libxl/libxl_numa.c
+++ b/tools/libxl/libxl_numa.c
@@ -293,9 +293,9 @@ int libxl__get_numa_candidate(libxl__gc *gc,
                               int *cndt_found)
 {
     libxl__numa_candidate new_cndt;
-    libxl_cputopology *tinfo = NULL;
+    libxl_topology *tinfo = NULL;
     libxl_numainfo *ninfo = NULL;
-    int nr_nodes = 0, nr_suit_nodes, nr_cpus = 0;
+    int nr_nodes = 0, nr_suit_nodes;
     libxl_bitmap suitable_nodemap, nodemap;
     int *vcpus_on_node, rc = 0;
 
@@ -341,7 +341,7 @@ int libxl__get_numa_candidate(libxl__gc *gc,
         goto out;
     }
 
-    tinfo = libxl_get_cpu_topology(CTX, &nr_cpus);
+    tinfo = libxl_get_topology(CTX);
     if (tinfo == NULL) {
         rc = ERROR_FAIL;
         goto out;
@@ -372,7 +372,7 @@ int libxl__get_numa_candidate(libxl__gc *gc,
      * all we have to do later is summing up the right elements of the
      * vcpus_on_node array.
      */
-    rc = nr_vcpus_on_nodes(gc, tinfo, nr_cpus, suitable_cpumap, vcpus_on_node);
+    rc = nr_vcpus_on_nodes(gc, tinfo->cpu, tinfo->cpu_num, suitable_cpumap, vcpus_on_node);
     if (rc)
         goto out;
 
@@ -387,7 +387,7 @@ int libxl__get_numa_candidate(libxl__gc *gc,
     if (!min_nodes) {
         int cpus_per_node;
 
-        cpus_per_node = count_cpus_per_node(tinfo, nr_cpus, nr_nodes);
+        cpus_per_node = count_cpus_per_node(tinfo->cpu, tinfo->cpu_num, nr_nodes);
         if (cpus_per_node == 0)
             min_nodes = 1;
         else
@@ -451,7 +451,7 @@ int libxl__get_numa_candidate(libxl__gc *gc,
                 continue;
 
             /* And the same applies if this combination is short in cpus */
-            nodes_cpus = nodemap_to_nr_cpus(tinfo, nr_cpus, suitable_cpumap,
+            nodes_cpus = nodemap_to_nr_cpus(tinfo->cpu, tinfo->cpu_num, suitable_cpumap,
                                             &nodemap);
             if (min_cpus && nodes_cpus < min_cpus)
                 continue;
@@ -503,7 +503,7 @@ int libxl__get_numa_candidate(libxl__gc *gc,
     libxl_bitmap_dispose(&suitable_nodemap);
     libxl__numa_candidate_dispose(&new_cndt);
     libxl_numainfo_list_free(ninfo, nr_nodes);
-    libxl_cputopology_list_free(tinfo, nr_cpus);
+    libxl_topology_free(tinfo);
     return rc;
 }
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 70c21a2..3eb8684 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -751,22 +751,22 @@ int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
                             const libxl_bitmap *nodemap,
                             libxl_bitmap *cpumap)
 {
-    libxl_cputopology *tinfo = NULL;
-    int nr_cpus = 0, i, rc = 0;
+    libxl_topology *tinfo = NULL;
+    int i, rc = 0;
 
-    tinfo = libxl_get_cpu_topology(ctx, &nr_cpus);
+    tinfo = libxl_get_topology(ctx);
     if (tinfo == NULL) {
         rc = ERROR_FAIL;
         goto out;
     }
 
     libxl_bitmap_set_none(cpumap);
-    for (i = 0; i < nr_cpus; i++) {
-        if (libxl_bitmap_test(nodemap, tinfo[i].node))
+    for (i = 0; i < tinfo->cpu_num; i++) {
+        if (libxl_bitmap_test(nodemap, tinfo->cpu[i].node))
             libxl_bitmap_set(cpumap, i);
     }
  out:
-    libxl_cputopology_list_free(tinfo, nr_cpus);
+    libxl_topology_free(tinfo);
     return rc;
 }
 
@@ -796,10 +796,10 @@ int libxl_cpumap_to_nodemap(libxl_ctx *ctx,
                             const libxl_bitmap *cpumap,
                             libxl_bitmap *nodemap)
 {
-    libxl_cputopology *tinfo = NULL;
-    int nr_cpus = 0, i, rc = 0;
+    libxl_topology *tinfo = NULL;
+    int i, rc = 0;
 
-    tinfo = libxl_get_cpu_topology(ctx, &nr_cpus);
+    tinfo = libxl_get_topology(ctx);
     if (tinfo == NULL) {
         rc = ERROR_FAIL;
         goto out;
@@ -807,12 +807,12 @@ int libxl_cpumap_to_nodemap(libxl_ctx *ctx,
 
     libxl_bitmap_set_none(nodemap);
     libxl_for_each_set_bit(i, *cpumap) {
-        if (i >= nr_cpus)
+        if (i >= tinfo->cpu_num)
             break;
-        libxl_bitmap_set(nodemap, tinfo[i].node);
+        libxl_bitmap_set(nodemap, tinfo->cpu[i].node);
     }
  out:
-    libxl_cputopology_list_free(tinfo, nr_cpus);
+    libxl_topology_free(tinfo);
     return rc;
 }
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index fd9beb3..824f980 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7045,7 +7045,7 @@ int main_cpupoolcreate(int argc, char **argv)
     libxl_bitmap freemap;
     libxl_bitmap cpumap;
     libxl_uuid uuid;
-    libxl_cputopology *topology;
+    libxl_topology *topology;
     int rc = -ERROR_FAIL;
 
     SWITCH_FOREACH_OPT(opt, "hnf:", opts, "cpupool-create", 0) {
@@ -7149,18 +7149,17 @@ int main_cpupoolcreate(int argc, char **argv)
         goto out_cfg;
     }
     if (!xlu_cfg_get_list(config, "nodes", &nodes, 0, 0)) {
-        int nr;
         n_cpus = 0;
         n_nodes = 0;
-        topology = libxl_get_cpu_topology(ctx, &nr);
+        topology = libxl_get_topology(ctx);
         if (topology == NULL) {
-            fprintf(stderr, "libxl_get_topologyinfo failed\n");
+            fprintf(stderr, "libxl_get_topology failed\n");
             goto out_cfg;
         }
         while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) {
             n = atoi(buf);
-            for (i = 0; i < nr; i++) {
-                if ((topology[i].node == n) &&
+            for (i = 0; i < topology->cpu_num; i++) {
+                if ((topology->cpu[i].node == n) &&
                     libxl_bitmap_test(&freemap, i)) {
                     libxl_bitmap_set(&cpumap, i);
                     n_cpus++;
@@ -7169,7 +7168,7 @@ int main_cpupoolcreate(int argc, char **argv)
             n_nodes++;
         }
 
-        libxl_cputopology_list_free(topology, nr);
+        libxl_topology_free(topology);
 
         if (n_cpus == 0) {
             fprintf(stderr, "no free cpu found\n");
@@ -7462,12 +7461,11 @@ int main_cpupoolnumasplit(int argc, char **argv)
     libxl_scheduler sched;
     int n_pools;
     int node;
-    int n_cpus;
     char name[16];
     libxl_uuid uuid;
     libxl_bitmap cpumap;
     libxl_cpupoolinfo *poolinfo;
-    libxl_cputopology *topology;
+    libxl_topology *topology;
     libxl_dominfo info;
 
     SWITCH_FOREACH_OPT(opt, "", NULL, "cpupool-numa-split", 0) {
@@ -7491,22 +7489,22 @@ int main_cpupoolnumasplit(int argc, char **argv)
         return -ERROR_FAIL;
     }
 
-    topology = libxl_get_cpu_topology(ctx, &n_cpus);
+    topology = libxl_get_topology(ctx);
     if (topology == NULL) {
-        fprintf(stderr, "libxl_get_topologyinfo failed\n");
+        fprintf(stderr, "libxl_get_topology failed\n");
         return -ERROR_FAIL;
     }
 
     if (libxl_cpu_bitmap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
-        libxl_cputopology_list_free(topology, n_cpus);
+        libxl_topology_free(topology);
         return -ERROR_FAIL;
     }
 
     /* Reset Pool-0 to 1st node: first add cpus, then remove cpus to avoid
        a cpupool without cpus in between */
 
-    node = topology[0].node;
+    node = topology->cpu[0].node;
     if (libxl_cpupool_cpuadd_node(ctx, 0, node, &n)) {
         fprintf(stderr, "error on adding cpu to Pool 0\n");
         return -ERROR_FAIL;
@@ -7520,9 +7518,9 @@ int main_cpupoolnumasplit(int argc, char **argv)
     }
 
     n = 0;
-    for (c = 0; c < n_cpus; c++) {
-        if (topology[c].node == node) {
-            topology[c].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
+    for (c = 0; c < topology->cpu_num; c++) {
+        if (topology->cpu[c].node == node) {
+            topology->cpu[c].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
             libxl_bitmap_set(&cpumap, n);
             n++;
         }
@@ -7547,12 +7545,12 @@ int main_cpupoolnumasplit(int argc, char **argv)
     }
     libxl_bitmap_set_none(&cpumap);
 
-    for (c = 0; c < n_cpus; c++) {
-        if (topology[c].node == LIBXL_CPUTOPOLOGY_INVALID_ENTRY) {
+    for (c = 0; c < topology->cpu_num; c++) {
+        if (topology->cpu[c].node == LIBXL_CPUTOPOLOGY_INVALID_ENTRY) {
             continue;
         }
 
-        node = topology[c].node;
+        node = topology->cpu[c].node;
         ret = -libxl_cpupool_cpuremove_node(ctx, 0, node, &n);
         if (ret) {
             fprintf(stderr, "error on removing cpu from Pool 0\n");
@@ -7574,15 +7572,15 @@ int main_cpupoolnumasplit(int argc, char **argv)
             goto out;
         }
 
-        for (p = c; p < n_cpus; p++) {
-            if (topology[p].node == node) {
-                topology[p].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
+        for (p = c; p < topology->cpu_num; p++) {
+            if (topology->cpu[p].node == node) {
+                topology->cpu[p].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
             }
         }
     }
 
 out:
-    libxl_cputopology_list_free(topology, n_cpus);
+    libxl_topology_free(topology);
     libxl_bitmap_dispose(&cpumap);
 
     return ret;
-- 
1.8.4.2


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 21:34:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 21:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvv5H-0003sP-2m; Tue, 02 Dec 2014 21:34:11 +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 1Xvv5F-0003s3-6d
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 21:34:09 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	63/8F-17958-0503E745; Tue, 02 Dec 2014 21:34:08 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417556045!10954926!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11983 invoked from network); 2 Dec 2014 21:34:07 -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; 2 Dec 2014 21:34:07 -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 sB2LY1F3012182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 21:34:02 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
	sB2LY0UY003440
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 21:34:01 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
	sB2LXxVn010177; Tue, 2 Dec 2014 21:33:59 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 13:33:59 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com
Date: Tue,  2 Dec 2014 16:34:08 -0500
Message-Id: <1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: dario.faggioli@citrix.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for returning
	IO topology 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>
MIME-Version: 1.0
Content-Type: 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 XEN_SYSCTL_topologyinfo more generic so that it can return both
CPU and IO topology (support for returning the latter is added in the
subsequent patch)

To do so move (and rename) previously used cpu_to_core/cpu_to_socket/
cpu_to_node into struct xen_sysctl_cputopo and move it, together with
newly added struct xen_sysctl_iotopo, to xen_sysctl_topologyinfo.

Add libxl_get_topology() to handle new interface and modify
libxl_get_cpu_topology() to be a wrapper around it.

Adjust xenpm and python's low-level C libraries for new interface.

This change requires bumping XEN_SYSCTL_INTERFACE_VERSION

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/libxl/libxl.c               | 79 ++++++++++++++++++++++++---------------
 tools/libxl/libxl.h               |  4 ++
 tools/libxl/libxl_types.idl       | 12 ++++++
 tools/libxl/libxl_utils.c         |  6 +++
 tools/misc/xenpm.c                | 64 +++++++++++++------------------
 tools/python/xen/lowlevel/xc/xc.c | 38 +++++++------------
 xen/common/sysctl.c               | 43 ++++++++++++---------
 xen/include/public/sysctl.h       | 36 +++++++++++++-----
 8 files changed, 162 insertions(+), 120 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..58cdc3b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5056,11 +5056,37 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out)
 {
     GC_INIT(ctx);
+    libxl_cputopology *cputopology = NULL;
+    libxl_topology *topo;
+    int i;
+
+    topo = libxl_get_topology(ctx);
+    if (topo == NULL) {
+        *nb_cpu_out = 0;
+        goto out;
+    }
+
+    cputopology = libxl__zalloc(NOGC, sizeof(libxl_cputopology) * topo->cpu_num);
+    for (i = 0; i < topo->cpu_num; i++) {
+        cputopology[i].core = topo->cpu[i].core;
+        cputopology[i].socket = topo->cpu[i].socket;
+        cputopology[i].node = topo->cpu[i].node;
+    }
+    *nb_cpu_out = topo->cpu_num;
+
+    libxl_topology_free(topo);
+
+ out:
+    GC_FREE;
+    return cputopology;
+}
+
+libxl_topology *libxl_get_topology(libxl_ctx *ctx)
+{
+    GC_INIT(ctx);
     xc_topologyinfo_t tinfo;
-    DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
-    DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
-    DECLARE_HYPERCALL_BUFFER(xc_cpu_to_node_t, nodemap);
-    libxl_cputopology *ret = NULL;
+    DECLARE_HYPERCALL_BUFFER(xen_sysctl_cputopo_t, cputopo);
+    libxl_topology *ret = NULL;
     int i;
     int max_cpus;
 
@@ -5072,48 +5098,39 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out)
         goto out;
     }
 
-    coremap = xc_hypercall_buffer_alloc
-        (ctx->xch, coremap, sizeof(*coremap) * max_cpus);
-    socketmap = xc_hypercall_buffer_alloc
-        (ctx->xch, socketmap, sizeof(*socketmap) * max_cpus);
-    nodemap = xc_hypercall_buffer_alloc
-        (ctx->xch, nodemap, sizeof(*nodemap) * max_cpus);
-    if ((coremap == NULL) || (socketmap == NULL) || (nodemap == NULL)) {
+    cputopo = xc_hypercall_buffer_alloc(ctx->xch, cputopo,
+                                        sizeof(*cputopo) * max_cpus);
+    if (cputopo == NULL) {
         LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
                             "Unable to allocate hypercall arguments");
         goto fail;
     }
-
-    set_xen_guest_handle(tinfo.cpu_to_core, coremap);
-    set_xen_guest_handle(tinfo.cpu_to_socket, socketmap);
-    set_xen_guest_handle(tinfo.cpu_to_node, nodemap);
+    set_xen_guest_handle(tinfo.cputopo, cputopo);
     tinfo.max_cpu_index = max_cpus - 1;
+
+    set_xen_guest_handle(tinfo.iotopo, HYPERCALL_BUFFER_NULL);
+
     if (xc_topologyinfo(ctx->xch, &tinfo) != 0) {
         LIBXL__LOG_ERRNO(ctx, XTL_ERROR, "Topology info hypercall failed");
         goto fail;
     }
 
-    if (tinfo.max_cpu_index < max_cpus - 1)
-        max_cpus = tinfo.max_cpu_index + 1;
+    ret = libxl__zalloc(NOGC, sizeof(*ret));
+    ret->cpu_num = tinfo.max_cpu_index + 1;
+    ret->cpu = libxl__zalloc(NOGC, sizeof(*(ret->cpu)) * ret->cpu_num);
 
-    ret = libxl__zalloc(NOGC, sizeof(libxl_cputopology) * max_cpus);
-
-    for (i = 0; i < max_cpus; i++) {
-#define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \
-    LIBXL_CPUTOPOLOGY_INVALID_ENTRY : map[i]
-        ret[i].core = V(coremap, i);
-        ret[i].socket = V(socketmap, i);
-        ret[i].node = V(nodemap, i);
+    for (i = 0; i < ret->cpu_num; i++) {
+#define V(map, i) ( cputopo[i].map == INVALID_TOPOLOGY_ID) ? \
+    LIBXL_CPUTOPOLOGY_INVALID_ENTRY :  cputopo[i].map
+        ret->cpu[i].core = V(core, i);
+        ret->cpu[i].socket = V(socket, i);
+        ret->cpu[i].node = V(node, i);
 #undef V
     }
 
-fail:
-    xc_hypercall_buffer_free(ctx->xch, coremap);
-    xc_hypercall_buffer_free(ctx->xch, socketmap);
-    xc_hypercall_buffer_free(ctx->xch, nodemap);
+ fail:
+    xc_hypercall_buffer_free(ctx->xch, cputopo);
 
-    if (ret)
-        *nb_cpu_out = max_cpus;
  out:
     GC_FREE;
     return ret;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c3451bd..5ab008d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1060,6 +1060,10 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nb_vm);
 libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out);
 void libxl_cputopology_list_free(libxl_cputopology *, int nb_cpu);
 
+#define LIBXL_TOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
+libxl_topology *libxl_get_topology(libxl_ctx *ctx);
+void libxl_topology_free(libxl_topology *);
+
 #define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
 libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
 void libxl_numainfo_list_free(libxl_numainfo *, int nr);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..673b273 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -642,6 +642,18 @@ libxl_cputopology = Struct("cputopology", [
     ("node", uint32),
     ], dir=DIR_OUT)
 
+libxl_iotopology = Struct("iotopology", [
+    ("seg", uint16),
+    ("bus", uint8),
+    ("devfn", uint8),
+    ("node", uint32),
+    ], dir=DIR_OUT)
+
+libxl_topology = Struct("topology", [
+    ("cpu", Array(libxl_cputopology, "cpu_num")),
+    ("dev", Array(libxl_iotopology, "dev_num")),
+    ], dir=DIR_OUT)
+
 libxl_sched_credit_params = Struct("sched_credit_params", [
     ("tslice_ms", integer),
     ("ratelimit_us", integer),
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 58df4f3..70c21a2 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -859,6 +859,12 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
     free(list);
 }
 
+void libxl_topology_free(libxl_topology *tinfo)
+{
+    libxl_topology_dispose(tinfo);
+    free(tinfo);
+}
+
 void libxl_numainfo_list_free(libxl_numainfo *list, int nr)
 {
     int i;
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index e43924c..8fd51d2 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -355,16 +355,11 @@ static void signal_int_handler(int signo)
     int i, j, k;
     struct timeval tv;
     int cx_cap = 0, px_cap = 0;
-    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_core);
-    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_socket);
-    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_node);
+    DECLARE_HYPERCALL_BUFFER(xen_sysctl_cputopo_t, cputopo);
     xc_topologyinfo_t info = { 0 };
 
-    cpu_to_core = xc_hypercall_buffer_alloc(xc_handle, cpu_to_core, sizeof(*cpu_to_core) * MAX_NR_CPU);
-    cpu_to_socket = xc_hypercall_buffer_alloc(xc_handle, cpu_to_socket, sizeof(*cpu_to_socket) * MAX_NR_CPU);
-    cpu_to_node = xc_hypercall_buffer_alloc(xc_handle, cpu_to_node, sizeof(*cpu_to_node) * MAX_NR_CPU);
-
-    if ( cpu_to_core == NULL || cpu_to_socket == NULL || cpu_to_node == NULL )
+    cputopo = xc_hypercall_buffer_alloc(xc_handle, cputopo, sizeof(*cputopo) * MAX_NR_CPU);
+    if ( cputopo == NULL )
     {
 	fprintf(stderr, "failed to allocate hypercall buffers\n");
 	goto out;
@@ -448,11 +443,11 @@ static void signal_int_handler(int signo)
             printf("  Avg freq\t%d\tKHz\n", avgfreq[i]);
     }
 
-    set_xen_guest_handle(info.cpu_to_core, cpu_to_core);
-    set_xen_guest_handle(info.cpu_to_socket, cpu_to_socket);
-    set_xen_guest_handle(info.cpu_to_node, cpu_to_node);
+    set_xen_guest_handle(info.cputopo, cputopo);
     info.max_cpu_index = MAX_NR_CPU - 1;
 
+    set_xen_guest_handle(info.iotopo, HYPERCALL_BUFFER_NULL);
+
     if ( cx_cap && !xc_topologyinfo(xc_handle, &info) )
     {
         uint32_t socket_ids[MAX_NR_CPU];
@@ -465,8 +460,8 @@ static void signal_int_handler(int signo)
         /* check validity */
         for ( i = 0; i <= info.max_cpu_index; i++ )
         {
-            if ( cpu_to_core[i] == INVALID_TOPOLOGY_ID ||
-                 cpu_to_socket[i] == INVALID_TOPOLOGY_ID )
+            if ( cputopo[i].core == INVALID_TOPOLOGY_ID ||
+                 cputopo[i].socket == INVALID_TOPOLOGY_ID )
                 break;
         }
         if ( i > info.max_cpu_index )
@@ -475,20 +470,20 @@ static void signal_int_handler(int signo)
             for ( i = 0; i <= info.max_cpu_index; i++ )
             {
                 for ( j = 0; j < socket_nr; j++ )
-                    if ( cpu_to_socket[i] == socket_ids[j] )
+                    if ( cputopo[i].socket == socket_ids[j] )
                         break;
                 if ( j == socket_nr )
                 {
-                    socket_ids[j] = cpu_to_socket[i];
+                    socket_ids[j] = cputopo[i].socket;
                     socket_nr++;
                 }
 
                 for ( j = 0; j < core_nr; j++ )
-                    if ( cpu_to_core[i] == core_ids[j] )
+                    if ( cputopo[i].core == core_ids[j] )
                         break;
                 if ( j == core_nr )
                 {
-                    core_ids[j] = cpu_to_core[i];
+                    core_ids[j] = cputopo[i].core;
                     core_nr++;
                 }
             }
@@ -501,7 +496,7 @@ static void signal_int_handler(int signo)
 
                 for ( j = 0; j <= info.max_cpu_index; j++ )
                 {
-                    if ( cpu_to_socket[j] == socket_ids[i] )
+                    if ( cputopo[j].socket == socket_ids[i] )
                         break;
                 }
                 printf("\nSocket %d\n", socket_ids[i]);
@@ -520,8 +515,8 @@ static void signal_int_handler(int signo)
                 {
                     for ( j = 0; j <= info.max_cpu_index; j++ )
                     {
-                        if ( cpu_to_socket[j] == socket_ids[i] &&
-                             cpu_to_core[j] == core_ids[k] )
+                        if ( cputopo[j].socket == socket_ids[i] &&
+                             cputopo[j].core == core_ids[k] )
                             break;
                     }
                     printf("\t Core %d CPU %d\n", core_ids[k], j);
@@ -556,9 +551,7 @@ static void signal_int_handler(int signo)
     free(sum);
     free(avgfreq);
 out:
-    xc_hypercall_buffer_free(xc_handle, cpu_to_core);
-    xc_hypercall_buffer_free(xc_handle, cpu_to_socket);
-    xc_hypercall_buffer_free(xc_handle, cpu_to_node);
+    xc_hypercall_buffer_free(xc_handle, cputopo);
     xc_interface_close(xc_handle);
     exit(0);
 }
@@ -965,27 +958,22 @@ void scaling_governor_func(int argc, char *argv[])
 
 void cpu_topology_func(int argc, char *argv[])
 {
-    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_core);
-    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_socket);
-    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_node);
+    DECLARE_HYPERCALL_BUFFER(xen_sysctl_cputopo_t, cputopo);
     xc_topologyinfo_t info = { 0 };
     int i, rc = ENOMEM;
 
-    cpu_to_core = xc_hypercall_buffer_alloc(xc_handle, cpu_to_core, sizeof(*cpu_to_core) * MAX_NR_CPU);
-    cpu_to_socket = xc_hypercall_buffer_alloc(xc_handle, cpu_to_socket, sizeof(*cpu_to_socket) * MAX_NR_CPU);
-    cpu_to_node = xc_hypercall_buffer_alloc(xc_handle, cpu_to_node, sizeof(*cpu_to_node) * MAX_NR_CPU);
-
-    if ( cpu_to_core == NULL || cpu_to_socket == NULL || cpu_to_node == NULL )
+    cputopo = xc_hypercall_buffer_alloc(xc_handle, cputopo, sizeof(*cputopo) * MAX_NR_CPU);
+    if ( cputopo == NULL )
     {
 	fprintf(stderr, "failed to allocate hypercall buffers\n");
 	goto out;
     }
 
-    set_xen_guest_handle(info.cpu_to_core, cpu_to_core);
-    set_xen_guest_handle(info.cpu_to_socket, cpu_to_socket);
-    set_xen_guest_handle(info.cpu_to_node, cpu_to_node);
+    set_xen_guest_handle(info.cputopo, cputopo);
     info.max_cpu_index = MAX_NR_CPU-1;
 
+    set_xen_guest_handle(info.iotopo, HYPERCALL_BUFFER_NULL);
+
     if ( xc_topologyinfo(xc_handle, &info) )
     {
         rc = errno;
@@ -1000,16 +988,14 @@ void cpu_topology_func(int argc, char *argv[])
     printf("CPU\tcore\tsocket\tnode\n");
     for ( i = 0; i <= info.max_cpu_index; i++ )
     {
-        if ( cpu_to_core[i] == INVALID_TOPOLOGY_ID )
+        if ( cputopo[i].core == INVALID_TOPOLOGY_ID )
             continue;
         printf("CPU%d\t %d\t %d\t %d\n",
-               i, cpu_to_core[i], cpu_to_socket[i], cpu_to_node[i]);
+               i, cputopo[i].core, cputopo[i].socket, cputopo[i].node);
     }
     rc = 0;
 out:
-    xc_hypercall_buffer_free(xc_handle, cpu_to_core);
-    xc_hypercall_buffer_free(xc_handle, cpu_to_socket);
-    xc_hypercall_buffer_free(xc_handle, cpu_to_node);
+    xc_hypercall_buffer_free(xc_handle, cputopo);
     if ( rc )
         exit(rc);
 }
diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
index d95d459..1f9252a 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1226,25 +1226,17 @@ static PyObject *pyxc_topologyinfo(XcObject *self)
     int i, max_cpu_index;
     PyObject *ret_obj = NULL;
     PyObject *cpu_to_core_obj, *cpu_to_socket_obj, *cpu_to_node_obj;
-    DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
-    DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
-    DECLARE_HYPERCALL_BUFFER(xc_cpu_to_node_t, nodemap);
 
-    coremap = xc_hypercall_buffer_alloc(self->xc_handle, coremap, sizeof(*coremap) * (MAX_CPU_INDEX+1));
-    if ( coremap == NULL )
-        goto out;
-    socketmap = xc_hypercall_buffer_alloc(self->xc_handle, socketmap, sizeof(*socketmap) * (MAX_CPU_INDEX+1));
-    if ( socketmap == NULL  )
-        goto out;
-    nodemap = xc_hypercall_buffer_alloc(self->xc_handle, nodemap, sizeof(*nodemap) * (MAX_CPU_INDEX+1));
-    if ( nodemap == NULL )
-        goto out;
+    DECLARE_HYPERCALL_BUFFER(xen_sysctl_cputopo_t, cputopo);
 
-    set_xen_guest_handle(tinfo.cpu_to_core, coremap);
-    set_xen_guest_handle(tinfo.cpu_to_socket, socketmap);
-    set_xen_guest_handle(tinfo.cpu_to_node, nodemap);
+    cputopo = xc_hypercall_buffer_alloc(self->xc_handle, cputopo, sizeof(*cputopo) * (MAX_CPU_INDEX+1));
+    if ( cputopo == NULL )
+	goto out;
+    set_xen_guest_handle(tinfo.cputopo, cputopo);
     tinfo.max_cpu_index = MAX_CPU_INDEX;
 
+    set_xen_guest_handle(tinfo.iotopo, HYPERCALL_BUFFER_NULL);
+
     if ( xc_topologyinfo(self->xc_handle, &tinfo) != 0 )
         goto out;
 
@@ -1258,35 +1250,35 @@ static PyObject *pyxc_topologyinfo(XcObject *self)
     cpu_to_node_obj = PyList_New(0);
     for ( i = 0; i <= max_cpu_index; i++ )
     {
-        if ( coremap[i] == INVALID_TOPOLOGY_ID )
+        if ( cputopo[i].core == INVALID_TOPOLOGY_ID )
         {
             PyList_Append(cpu_to_core_obj, Py_None);
         }
         else
         {
-            PyObject *pyint = PyInt_FromLong(coremap[i]);
+            PyObject *pyint = PyInt_FromLong(cputopo[i].core);
             PyList_Append(cpu_to_core_obj, pyint);
             Py_DECREF(pyint);
         }
 
-        if ( socketmap[i] == INVALID_TOPOLOGY_ID )
+        if ( cputopo[i].socket == INVALID_TOPOLOGY_ID )
         {
             PyList_Append(cpu_to_socket_obj, Py_None);
         }
         else
         {
-            PyObject *pyint = PyInt_FromLong(socketmap[i]);
+            PyObject *pyint = PyInt_FromLong(cputopo[i].socket);
             PyList_Append(cpu_to_socket_obj, pyint);
             Py_DECREF(pyint);
         }
 
-        if ( nodemap[i] == INVALID_TOPOLOGY_ID )
+        if ( cputopo[i].node == INVALID_TOPOLOGY_ID )
         {
             PyList_Append(cpu_to_node_obj, Py_None);
         }
         else
         {
-            PyObject *pyint = PyInt_FromLong(nodemap[i]);
+            PyObject *pyint = PyInt_FromLong(cputopo[i].node);
             PyList_Append(cpu_to_node_obj, pyint);
             Py_DECREF(pyint);
         }
@@ -1304,9 +1296,7 @@ static PyObject *pyxc_topologyinfo(XcObject *self)
     Py_DECREF(cpu_to_node_obj);
 
 out:
-    xc_hypercall_buffer_free(self->xc_handle, coremap);
-    xc_hypercall_buffer_free(self->xc_handle, socketmap);
-    xc_hypercall_buffer_free(self->xc_handle, nodemap);
+    xc_hypercall_buffer_free(self->xc_handle, cputopo);
     return ret_obj ? ret_obj : pyxc_error_to_exception(self->xc_handle);
 #undef MAX_CPU_INDEX
 }
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0cb6ee1..d4dc8ed 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -327,32 +327,41 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 
         last_online_cpu = cpumask_last(&cpu_online_map);
         max_cpu_index = min_t(uint32_t, ti->max_cpu_index, last_online_cpu);
-        ti->max_cpu_index = last_online_cpu;
+
+        if ( guest_handle_is_null(ti->cputopo) )
+        {
+            ret = -EINVAL;
+            break;
+        }
 
         for ( i = 0; i <= max_cpu_index; i++ )
         {
-            if ( !guest_handle_is_null(ti->cpu_to_core) )
-            {
-                uint32_t core = cpu_online(i) ? cpu_to_core(i) : ~0u;
-                if ( copy_to_guest_offset(ti->cpu_to_core, i, &core, 1) )
-                    break;
-            }
-            if ( !guest_handle_is_null(ti->cpu_to_socket) )
+            xen_sysctl_cputopo_t cputopo;
+
+            if ( cpu_online(i) )
             {
-                uint32_t socket = cpu_online(i) ? cpu_to_socket(i) : ~0u;
-                if ( copy_to_guest_offset(ti->cpu_to_socket, i, &socket, 1) )
-                    break;
+                cputopo.core = cpu_to_core(i);
+                cputopo.socket = cpu_to_socket(i);
+                cputopo.node = cpu_to_node(i);
             }
-            if ( !guest_handle_is_null(ti->cpu_to_node) )
+            else
+                cputopo.core = cputopo.socket =
+                    cputopo.node = INVALID_TOPOLOGY_ID;
+
+            if ( copy_to_guest_offset(ti->cputopo, i, &cputopo, 1) )
             {
-                uint32_t node = cpu_online(i) ? cpu_to_node(i) : ~0u;
-                if ( copy_to_guest_offset(ti->cpu_to_node, i, &node, 1) )
-                    break;
+                ret = -EFAULT;
+                break;
             }
         }
 
-        ret = ((i <= max_cpu_index) || copy_to_guest(u_sysctl, op, 1))
-            ? -EFAULT : 0;
+        if ( !ret && (ti->max_cpu_index != last_online_cpu) )
+        {
+             ti->max_cpu_index = last_online_cpu;
+             if ( __copy_field_to_guest(u_sysctl, op,
+                                        u.topologyinfo.max_cpu_index) )
+                ret = -EFAULT;
+        }
     }
     break;
 
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index b3713b3..e1d1348 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -34,7 +34,7 @@
 #include "xen.h"
 #include "domctl.h"
 
-#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000B
+#define XEN_SYSCTL_INTERFACE_VERSION 0x0000000C
 
 /*
  * Read console content from Xen buffer ring.
@@ -464,26 +464,44 @@ DEFINE_XEN_GUEST_HANDLE(xen_sysctl_lockprof_op_t);
 
 /* XEN_SYSCTL_topologyinfo */
 #define INVALID_TOPOLOGY_ID  (~0U)
+
+struct xen_sysctl_cputopo {
+    uint32_t core;
+    uint32_t socket;
+    uint32_t node;
+};
+typedef struct xen_sysctl_cputopo xen_sysctl_cputopo_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cputopo_t);
+
+struct xen_sysctl_iotopo {
+    uint16_t seg;
+    uint8_t bus;
+    uint8_t devfn;
+    uint32_t node;
+};
+typedef struct xen_sysctl_iotopo xen_sysctl_iotopo_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_iotopo_t);
+
 struct xen_sysctl_topologyinfo {
     /*
      * IN: maximum addressable entry in the caller-provided arrays.
-     * OUT: largest cpu identifier in the system.
+     * OUT: largest cpu identifier or max number of devices 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;
+    uint32_t max_devs;
 
     /*
      * 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:
+     * for each cpu and/or node for each PCI device.
+     * If information for a particular entry is not avalable it is set to
+     * INVALID_TOPOLOGY_ID.
+     * The number of array elements for CPU topology written by the sysctl is:
      *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
      */
-    XEN_GUEST_HANDLE_64(uint32) cpu_to_core;
-    XEN_GUEST_HANDLE_64(uint32) cpu_to_socket;
-    XEN_GUEST_HANDLE_64(uint32) cpu_to_node;
+    XEN_GUEST_HANDLE_64(xen_sysctl_cputopo_t) cputopo;
+    XEN_GUEST_HANDLE_64(xen_sysctl_iotopo_t) iotopo;
 };
 typedef struct xen_sysctl_topologyinfo xen_sysctl_topologyinfo_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_topologyinfo_t);
-- 
1.8.4.2


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 21:34:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 21:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvv5H-0003si-LV; Tue, 02 Dec 2014 21:34:11 +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 1Xvv5G-0003sF-39
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 21:34:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	3D/D0-09842-1503E745; Tue, 02 Dec 2014 21:34:09 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417556047!12966200!1
X-Originating-IP: [156.151.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 1270 invoked from network); 2 Dec 2014 21:34:08 -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; 2 Dec 2014 21:34:08 -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 sB2LY0Bx002767
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 21:34:01 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
	sB2LXwIl003341
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 21:33:59 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
	sB2LXvMa010113; Tue, 2 Dec 2014 21:33:58 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 13:33:57 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com
Date: Tue,  2 Dec 2014 16:34:06 -0500
Message-Id: <1417556050-23364-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: dario.faggioli@citrix.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/4] Display IO topology when PXM data is
	available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

4 patches that add interface for querying hypervisor about device
topology and allow 'xl info -n' display this information if PXM object
is provided by ACPI.

The patches are:

* Store PXM data (nodeID) in pci_dev during PHYSDEVOP_pci_device_add
  hypercall
* Modify XEN_SYSCTL_topologyinfo so that it can return both CPU and
  device topology data. Add corresponding libxl interface
* Use new interface to query the hypervisor about topology and print
  it with 'xl info -n'
* Replace all users of old cpu topology interface with the new
  call. This patch is optional.

Boris Ostrovsky (4):
  pci: Do not ignore device's PXM information
  sysctl/libxl: Add interface for returning IO topology data
  sysctl/libxl: Provide information about IO topology
  libxl: Switch to using new topology interface

 tools/libxl/libxl.c               | 130 +++++++++++++++++++++++++-------------
 tools/libxl/libxl.h               |   4 ++
 tools/libxl/libxl_freebsd.c       |  12 ++++
 tools/libxl/libxl_internal.h      |   5 ++
 tools/libxl/libxl_linux.c         |  74 ++++++++++++++++++++++
 tools/libxl/libxl_netbsd.c        |  12 ++++
 tools/libxl/libxl_numa.c          |  14 ++--
 tools/libxl/libxl_types.idl       |  12 ++++
 tools/libxl/libxl_utils.c         |  30 +++++----
 tools/libxl/xl_cmdimpl.c          |  75 +++++++++++++---------
 tools/misc/xenpm.c                |  64 ++++++++-----------
 tools/python/xen/lowlevel/xc/xc.c |  38 ++++-------
 xen/arch/x86/physdev.c            |  20 +++++-
 xen/common/sysctl.c               |  69 +++++++++++++++-----
 xen/drivers/passthrough/pci.c     |  13 ++--
 xen/include/public/sysctl.h       |  36 ++++++++---
 xen/include/xen/pci.h             |   5 +-
 17 files changed, 424 insertions(+), 189 deletions(-)

-- 
1.8.4.2


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 21:34:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 21:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvv5I-0003sv-10; Tue, 02 Dec 2014 21:34:12 +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 1Xvv5G-0003sG-Bc
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 21:34:10 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C3/C9-29352-1503E745; Tue, 02 Dec 2014 21:34:09 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417556047!7038082!1
X-Originating-IP: [156.151.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 20747 invoked from network); 2 Dec 2014 21:34:08 -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; 2 Dec 2014 21:34:08 -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 sB2LY1so003057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 21:34:02 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
	sB2LY0Ma010212
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 21:34:01 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
	sB2LY0H9003397; Tue, 2 Dec 2014 21:34:00 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 13:33:59 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com
Date: Tue,  2 Dec 2014 16:34:09 -0500
Message-Id: <1417556050-23364-4-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: dario.faggioli@citrix.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] sysctl/libxl: Provide information about IO
	topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 to XEN_SYSCTL_topologyinfo to return IO topology data.

Modify libxl_get_topology() to request this data, provide OS-dependent
helper functions that determine which devices we are inquiring about
(Linux only).

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/libxl/libxl.c          | 28 ++++++++++++++++-
 tools/libxl/libxl_freebsd.c  | 12 +++++++
 tools/libxl/libxl_internal.h |  5 +++
 tools/libxl/libxl_linux.c    | 74 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_netbsd.c   | 12 +++++++
 tools/libxl/xl_cmdimpl.c     | 31 ++++++++++++++-----
 xen/common/sysctl.c          | 30 ++++++++++++++++++
 7 files changed, 183 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 58cdc3b..ee103ac 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5086,6 +5086,7 @@ libxl_topology *libxl_get_topology(libxl_ctx *ctx)
     GC_INIT(ctx);
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xen_sysctl_cputopo_t, cputopo);
+    DECLARE_HYPERCALL_BUFFER(xen_sysctl_iotopo_t, iotopo);
     libxl_topology *ret = NULL;
     int i;
     int max_cpus;
@@ -5108,7 +5109,20 @@ libxl_topology *libxl_get_topology(libxl_ctx *ctx)
     set_xen_guest_handle(tinfo.cputopo, cputopo);
     tinfo.max_cpu_index = max_cpus - 1;
 
-    set_xen_guest_handle(tinfo.iotopo, HYPERCALL_BUFFER_NULL);
+    tinfo.max_devs = libxl_pci_numdevs(ctx);
+    if (tinfo.max_devs > 0) {
+        iotopo = xc_hypercall_buffer_alloc(ctx->xch, iotopo,
+                                           sizeof(*iotopo) * tinfo.max_devs);
+        if (iotopo != NULL) {
+            if (libxl_pci_topology_init(ctx, iotopo, tinfo.max_devs))
+                tinfo.max_devs = 0;
+        } else
+            tinfo.max_devs = 0;
+    }
+    if (tinfo.max_devs > 0)
+        set_xen_guest_handle(tinfo.iotopo, iotopo);
+    else
+        set_xen_guest_handle(tinfo.iotopo, HYPERCALL_BUFFER_NULL);
 
     if (xc_topologyinfo(ctx->xch, &tinfo) != 0) {
         LIBXL__LOG_ERRNO(ctx, XTL_ERROR, "Topology info hypercall failed");
@@ -5128,8 +5142,20 @@ libxl_topology *libxl_get_topology(libxl_ctx *ctx)
 #undef V
     }
 
+    ret->dev_num = tinfo.max_devs;
+    ret->dev = libxl__zalloc(NOGC, sizeof(libxl_iotopology) * ret->dev_num);
+
+    for (i = 0; i < tinfo.max_devs; i++) {
+        ret->dev[i].seg = iotopo[i].seg;
+        ret->dev[i].bus = iotopo[i].bus;
+        ret->dev[i].devfn = iotopo[i].devfn;
+        ret->dev[i].node = (iotopo[i].node == INVALID_TOPOLOGY_ID) ?
+                           LIBXL_TOPOLOGY_INVALID_ENTRY : iotopo[i].node;
+    }
+
  fail:
     xc_hypercall_buffer_free(ctx->xch, cputopo);
+    xc_hypercall_buffer_free(ctx->xch, iotopo);
 
  out:
     GC_FREE;
diff --git a/tools/libxl/libxl_freebsd.c b/tools/libxl/libxl_freebsd.c
index e8b88b3..8695a78 100644
--- a/tools/libxl/libxl_freebsd.c
+++ b/tools/libxl/libxl_freebsd.c
@@ -131,3 +131,15 @@ libxl_device_model_version libxl__default_device_model(libxl__gc *gc)
 {
     return LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
 }
+
+int libxl_pci_numdevs(libxl_ctx *ctx)
+{
+    return ERROR_NI;
+}
+
+int libxl_pci_topology_init(libxl_ctx *ctx,
+			    xen_sysctl_iotopo_t *iotopo,
+			    int numdev)
+{
+    return ERROR_NI;
+}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..c3a4194 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1168,6 +1168,11 @@ _hidden int libxl__try_phy_backend(mode_t st_mode);
 
 _hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid);
 
+_hidden int libxl_pci_numdevs(libxl_ctx *ctx);
+_hidden int libxl_pci_topology_init(libxl_ctx *ctx,
+                                    xen_sysctl_iotopo_t *iotopo,
+                                    int numdev);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index ea5d8c1..884c042 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -279,3 +279,77 @@ libxl_device_model_version libxl__default_device_model(libxl__gc *gc)
 {
     return LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
 }
+
+/* These two routines are "inspired" by pciutils */
+int libxl_pci_numdevs(libxl_ctx *ctx)
+{
+    DIR *dir;
+    struct dirent *entry;
+    int numdev = 0;
+
+    dir = opendir("/sys/bus/pci/devices");
+    if (!dir) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, errno,
+                            "Cannot open /sys/bus/pci/devices");
+        return ERROR_FAIL;
+    }
+
+    while ((entry = readdir(dir))) {
+        /* ".", ".." or a special non-device perhaps */
+        if (entry->d_name[0] == '.')
+            continue;
+        numdev++;
+    }
+    closedir(dir);
+
+    return numdev;
+}
+
+int libxl_pci_topology_init(libxl_ctx *ctx,
+                            xen_sysctl_iotopo_t *iotopo,
+			    int numdev)
+{
+
+    DIR *dir;
+    struct dirent *entry;
+    int i;
+
+    dir = opendir("/sys/bus/pci/devices");
+    if (!dir) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, errno,
+                            "Cannot open /sys/bus/pci/devices");
+        return ERROR_FAIL;
+    }
+
+    i = 0;
+    while ((entry = readdir(dir))) {
+        unsigned int dom, bus, dev, func;
+
+        /* ".", ".." or a special non-device perhaps */
+        if (entry->d_name[0] == '.')
+            continue;
+
+        if (i == numdev) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Too many devices\n");
+            closedir(dir);
+            return ERROR_FAIL;
+        }
+
+        if (sscanf(entry->d_name, "%x:%x:%x.%d", &dom, &bus, &dev, &func) < 4) {
+            LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, errno,
+                                "Cannot open /sys/bus/pci/devices");
+            closedir(dir);
+            return ERROR_FAIL;
+        }
+
+        iotopo[i].seg = dom;
+        iotopo[i].bus = bus;
+        iotopo[i].devfn = ((dev & 0x1f) << 3) | (func & 7);
+
+        i++;
+    }
+
+    closedir(dir);
+
+    return 0;
+}
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index 898e160..0946b64 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -95,3 +95,15 @@ libxl_device_model_version libxl__default_device_model(libxl__gc *gc)
 {
     return LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
 }
+
+int libxl_pci_numdevs(libxl_ctx *ctx)
+{
+    return ERROR_NI;
+}
+
+int libxl_pci_topology_init(libxl_ctx *ctx,
+			    xen_sysctl_iotopo_t *iotopo,
+			    int numdev)
+{
+    return ERROR_NI;
+}
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9afef3f..fd9beb3 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5186,25 +5186,40 @@ static void output_numainfo(void)
 
 static void output_topologyinfo(void)
 {
-    libxl_cputopology *info;
-    int i, nr;
+    libxl_topology *info;
+    int i, valid_devs = 0;
 
-    info = libxl_get_cpu_topology(ctx, &nr);
+    info = libxl_get_topology(ctx);
     if (info == NULL) {
-        fprintf(stderr, "libxl_get_topologyinfo failed.\n");
+        fprintf(stderr, "libxl_get_topology failed.\n");
         return;
     }
 
     printf("cpu_topology           :\n");
     printf("cpu:    core    socket     node\n");
 
-    for (i = 0; i < nr; i++) {
-        if (info[i].core != LIBXL_CPUTOPOLOGY_INVALID_ENTRY)
+    for (i = 0; i < info->cpu_num; i++) {
+        if (info->cpu[i].core != LIBXL_CPUTOPOLOGY_INVALID_ENTRY)
             printf("%3d:    %4d     %4d     %4d\n", i,
-                   info[i].core, info[i].socket, info[i].node);
+                   info->cpu[i].core, info->cpu[i].socket, info->cpu[i].node);
     }
 
-    libxl_cputopology_list_free(info, nr);
+    printf("device topology        :\n");
+    printf("device           node\n");
+    for (i = 0; i < info->dev_num; i++) {
+        libxl_iotopology *dev = &info->dev[i];
+
+        if (dev->node != LIBXL_TOPOLOGY_INVALID_ENTRY) {
+	    printf("%04x:%02x:%02x.%01x      %d\n", dev->seg, dev->bus,
+                  ((dev->devfn >> 3) & 0x1f), (dev->devfn & 7), dev->node);
+            valid_devs++;
+        } 
+    }
+
+    if (valid_devs == 0)
+        printf(" No device topology data available\n");
+
+    libxl_topology_free(info);
 
     return;
 }
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d4dc8ed..a82e0ed 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -328,6 +328,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         last_online_cpu = cpumask_last(&cpu_online_map);
         max_cpu_index = min_t(uint32_t, ti->max_cpu_index, last_online_cpu);
 
+        /* CPU topology buffers should always be provided */
         if ( guest_handle_is_null(ti->cputopo) )
         {
             ret = -EINVAL;
@@ -362,6 +363,35 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
                                         u.topologyinfo.max_cpu_index) )
                 ret = -EFAULT;
         }
+
+        if ( !ret && !guest_handle_is_null(ti->iotopo) )
+        {
+            for ( i = 0; i < ti->max_devs; i++ )
+            {
+                xen_sysctl_iotopo_t iotopo;
+                struct pci_dev *pdev;
+
+                if ( copy_from_guest_offset(&iotopo, ti->iotopo, i, 1) )
+                {
+                    ret = -EFAULT;
+                    break;
+                }
+
+                spin_lock(&pcidevs_lock);
+                pdev = pci_get_pdev(iotopo.seg, iotopo.bus, iotopo.devfn);
+                if ( !pdev || (pdev->node == NUMA_NO_NODE) )
+                    iotopo.node = INVALID_TOPOLOGY_ID;
+                else
+                    iotopo.node = pdev->node;
+                spin_unlock(&pcidevs_lock);
+
+                if ( copy_to_guest_offset(ti->iotopo, i, &iotopo, 1) )
+                {
+                    ret = -EFAULT;
+                    break;
+                }
+            }
+        }
     }
     break;
 
-- 
1.8.4.2


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 21:34:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 21:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvv5K-0003tR-E9; Tue, 02 Dec 2014 21:34:14 +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 1Xvv5I-0003t4-LR
	for xen-devel@lists.xen.org; Tue, 02 Dec 2014 21:34:12 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	D9/EA-02957-4503E745; Tue, 02 Dec 2014 21:34:12 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417556048!7142939!1
X-Originating-IP: [156.151.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 7111 invoked from network); 2 Dec 2014 21:34:10 -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; 2 Dec 2014 21:34: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 sB2LY2uD003082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 21:34:02 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
	sB2LY1Hu005879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 2 Dec 2014 21:34:01 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
	sB2LY0Tj003495; Tue, 2 Dec 2014 21:34:00 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 02 Dec 2014 13:34:00 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	wei.liu2@citrix.com
Date: Tue,  2 Dec 2014 16:34:10 -0500
Message-Id: <1417556050-23364-5-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: dario.faggioli@citrix.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] libxl: Switch to using new topology
	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>
MIME-Version: 1.0
Content-Type: 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 current users of libxl_get_cpu_topology() call
libxl_get_topology() instead.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/libxl/libxl.c       | 25 ++++++++++++-------------
 tools/libxl/libxl_numa.c  | 14 +++++++-------
 tools/libxl/libxl_utils.c | 24 ++++++++++++------------
 tools/libxl/xl_cmdimpl.c  | 44 +++++++++++++++++++++-----------------------
 4 files changed, 52 insertions(+), 55 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ee103ac..5398e41 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -6410,30 +6410,29 @@ int libxl_cpupool_cpuadd(libxl_ctx *ctx, uint32_t poolid, int cpu)
 int libxl_cpupool_cpuadd_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus)
 {
     int rc = 0;
-    int cpu, nr;
+    int cpu;
     libxl_bitmap freemap;
-    libxl_cputopology *topology;
+    libxl_topology *topology;
 
     if (libxl_get_freecpus(ctx, &freemap)) {
         return ERROR_FAIL;
     }
 
-    topology = libxl_get_cpu_topology(ctx, &nr);
+    topology = libxl_get_topology(ctx);
     if (!topology) {
         rc = ERROR_FAIL;
         goto out;
     }
 
     *cpus = 0;
-    for (cpu = 0; cpu < nr; cpu++) {
-        if (libxl_bitmap_test(&freemap, cpu) && (topology[cpu].node == node) &&
+    for (cpu = 0; cpu < topology->cpu_num; cpu++) {
+        if (libxl_bitmap_test(&freemap, cpu) && (topology->cpu[cpu].node == node) &&
             !libxl_cpupool_cpuadd(ctx, poolid, cpu)) {
                 (*cpus)++;
         }
-        libxl_cputopology_dispose(&topology[cpu]);
     }
 
-    free(topology);
+    libxl_topology_free(topology);
 out:
     libxl_bitmap_dispose(&freemap);
     return rc;
@@ -6457,8 +6456,8 @@ int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int
     int ret = 0;
     int n_pools;
     int p;
-    int cpu, nr_cpus;
-    libxl_cputopology *topology;
+    int cpu;
+    libxl_topology *topology;
     libxl_cpupoolinfo *poolinfo;
 
     poolinfo = libxl_list_cpupool(ctx, &n_pools);
@@ -6466,7 +6465,7 @@ int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int
         return ERROR_NOMEM;
     }
 
-    topology = libxl_get_cpu_topology(ctx, &nr_cpus);
+    topology = libxl_get_topology(ctx);
     if (!topology) {
         ret = ERROR_FAIL;
         goto out;
@@ -6475,8 +6474,8 @@ int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int
     *cpus = 0;
     for (p = 0; p < n_pools; p++) {
         if (poolinfo[p].poolid == poolid) {
-            for (cpu = 0; cpu < nr_cpus; cpu++) {
-                if ((topology[cpu].node == node) &&
+            for (cpu = 0; cpu < topology->cpu_num; cpu++) {
+                if ((topology->cpu[cpu].node == node) &&
                     libxl_bitmap_test(&poolinfo[p].cpumap, cpu) &&
                     !libxl_cpupool_cpuremove(ctx, poolid, cpu)) {
                         (*cpus)++;
@@ -6485,7 +6484,7 @@ int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int
         }
     }
 
-    libxl_cputopology_list_free(topology, nr_cpus);
+    libxl_topology_free(topology);
 
 out:
     libxl_cpupoolinfo_list_free(poolinfo, n_pools);
diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
index 94ca4fe..c809dc0 100644
--- a/tools/libxl/libxl_numa.c
+++ b/tools/libxl/libxl_numa.c
@@ -293,9 +293,9 @@ int libxl__get_numa_candidate(libxl__gc *gc,
                               int *cndt_found)
 {
     libxl__numa_candidate new_cndt;
-    libxl_cputopology *tinfo = NULL;
+    libxl_topology *tinfo = NULL;
     libxl_numainfo *ninfo = NULL;
-    int nr_nodes = 0, nr_suit_nodes, nr_cpus = 0;
+    int nr_nodes = 0, nr_suit_nodes;
     libxl_bitmap suitable_nodemap, nodemap;
     int *vcpus_on_node, rc = 0;
 
@@ -341,7 +341,7 @@ int libxl__get_numa_candidate(libxl__gc *gc,
         goto out;
     }
 
-    tinfo = libxl_get_cpu_topology(CTX, &nr_cpus);
+    tinfo = libxl_get_topology(CTX);
     if (tinfo == NULL) {
         rc = ERROR_FAIL;
         goto out;
@@ -372,7 +372,7 @@ int libxl__get_numa_candidate(libxl__gc *gc,
      * all we have to do later is summing up the right elements of the
      * vcpus_on_node array.
      */
-    rc = nr_vcpus_on_nodes(gc, tinfo, nr_cpus, suitable_cpumap, vcpus_on_node);
+    rc = nr_vcpus_on_nodes(gc, tinfo->cpu, tinfo->cpu_num, suitable_cpumap, vcpus_on_node);
     if (rc)
         goto out;
 
@@ -387,7 +387,7 @@ int libxl__get_numa_candidate(libxl__gc *gc,
     if (!min_nodes) {
         int cpus_per_node;
 
-        cpus_per_node = count_cpus_per_node(tinfo, nr_cpus, nr_nodes);
+        cpus_per_node = count_cpus_per_node(tinfo->cpu, tinfo->cpu_num, nr_nodes);
         if (cpus_per_node == 0)
             min_nodes = 1;
         else
@@ -451,7 +451,7 @@ int libxl__get_numa_candidate(libxl__gc *gc,
                 continue;
 
             /* And the same applies if this combination is short in cpus */
-            nodes_cpus = nodemap_to_nr_cpus(tinfo, nr_cpus, suitable_cpumap,
+            nodes_cpus = nodemap_to_nr_cpus(tinfo->cpu, tinfo->cpu_num, suitable_cpumap,
                                             &nodemap);
             if (min_cpus && nodes_cpus < min_cpus)
                 continue;
@@ -503,7 +503,7 @@ int libxl__get_numa_candidate(libxl__gc *gc,
     libxl_bitmap_dispose(&suitable_nodemap);
     libxl__numa_candidate_dispose(&new_cndt);
     libxl_numainfo_list_free(ninfo, nr_nodes);
-    libxl_cputopology_list_free(tinfo, nr_cpus);
+    libxl_topology_free(tinfo);
     return rc;
 }
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 70c21a2..3eb8684 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -751,22 +751,22 @@ int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
                             const libxl_bitmap *nodemap,
                             libxl_bitmap *cpumap)
 {
-    libxl_cputopology *tinfo = NULL;
-    int nr_cpus = 0, i, rc = 0;
+    libxl_topology *tinfo = NULL;
+    int i, rc = 0;
 
-    tinfo = libxl_get_cpu_topology(ctx, &nr_cpus);
+    tinfo = libxl_get_topology(ctx);
     if (tinfo == NULL) {
         rc = ERROR_FAIL;
         goto out;
     }
 
     libxl_bitmap_set_none(cpumap);
-    for (i = 0; i < nr_cpus; i++) {
-        if (libxl_bitmap_test(nodemap, tinfo[i].node))
+    for (i = 0; i < tinfo->cpu_num; i++) {
+        if (libxl_bitmap_test(nodemap, tinfo->cpu[i].node))
             libxl_bitmap_set(cpumap, i);
     }
  out:
-    libxl_cputopology_list_free(tinfo, nr_cpus);
+    libxl_topology_free(tinfo);
     return rc;
 }
 
@@ -796,10 +796,10 @@ int libxl_cpumap_to_nodemap(libxl_ctx *ctx,
                             const libxl_bitmap *cpumap,
                             libxl_bitmap *nodemap)
 {
-    libxl_cputopology *tinfo = NULL;
-    int nr_cpus = 0, i, rc = 0;
+    libxl_topology *tinfo = NULL;
+    int i, rc = 0;
 
-    tinfo = libxl_get_cpu_topology(ctx, &nr_cpus);
+    tinfo = libxl_get_topology(ctx);
     if (tinfo == NULL) {
         rc = ERROR_FAIL;
         goto out;
@@ -807,12 +807,12 @@ int libxl_cpumap_to_nodemap(libxl_ctx *ctx,
 
     libxl_bitmap_set_none(nodemap);
     libxl_for_each_set_bit(i, *cpumap) {
-        if (i >= nr_cpus)
+        if (i >= tinfo->cpu_num)
             break;
-        libxl_bitmap_set(nodemap, tinfo[i].node);
+        libxl_bitmap_set(nodemap, tinfo->cpu[i].node);
     }
  out:
-    libxl_cputopology_list_free(tinfo, nr_cpus);
+    libxl_topology_free(tinfo);
     return rc;
 }
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index fd9beb3..824f980 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7045,7 +7045,7 @@ int main_cpupoolcreate(int argc, char **argv)
     libxl_bitmap freemap;
     libxl_bitmap cpumap;
     libxl_uuid uuid;
-    libxl_cputopology *topology;
+    libxl_topology *topology;
     int rc = -ERROR_FAIL;
 
     SWITCH_FOREACH_OPT(opt, "hnf:", opts, "cpupool-create", 0) {
@@ -7149,18 +7149,17 @@ int main_cpupoolcreate(int argc, char **argv)
         goto out_cfg;
     }
     if (!xlu_cfg_get_list(config, "nodes", &nodes, 0, 0)) {
-        int nr;
         n_cpus = 0;
         n_nodes = 0;
-        topology = libxl_get_cpu_topology(ctx, &nr);
+        topology = libxl_get_topology(ctx);
         if (topology == NULL) {
-            fprintf(stderr, "libxl_get_topologyinfo failed\n");
+            fprintf(stderr, "libxl_get_topology failed\n");
             goto out_cfg;
         }
         while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) {
             n = atoi(buf);
-            for (i = 0; i < nr; i++) {
-                if ((topology[i].node == n) &&
+            for (i = 0; i < topology->cpu_num; i++) {
+                if ((topology->cpu[i].node == n) &&
                     libxl_bitmap_test(&freemap, i)) {
                     libxl_bitmap_set(&cpumap, i);
                     n_cpus++;
@@ -7169,7 +7168,7 @@ int main_cpupoolcreate(int argc, char **argv)
             n_nodes++;
         }
 
-        libxl_cputopology_list_free(topology, nr);
+        libxl_topology_free(topology);
 
         if (n_cpus == 0) {
             fprintf(stderr, "no free cpu found\n");
@@ -7462,12 +7461,11 @@ int main_cpupoolnumasplit(int argc, char **argv)
     libxl_scheduler sched;
     int n_pools;
     int node;
-    int n_cpus;
     char name[16];
     libxl_uuid uuid;
     libxl_bitmap cpumap;
     libxl_cpupoolinfo *poolinfo;
-    libxl_cputopology *topology;
+    libxl_topology *topology;
     libxl_dominfo info;
 
     SWITCH_FOREACH_OPT(opt, "", NULL, "cpupool-numa-split", 0) {
@@ -7491,22 +7489,22 @@ int main_cpupoolnumasplit(int argc, char **argv)
         return -ERROR_FAIL;
     }
 
-    topology = libxl_get_cpu_topology(ctx, &n_cpus);
+    topology = libxl_get_topology(ctx);
     if (topology == NULL) {
-        fprintf(stderr, "libxl_get_topologyinfo failed\n");
+        fprintf(stderr, "libxl_get_topology failed\n");
         return -ERROR_FAIL;
     }
 
     if (libxl_cpu_bitmap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
-        libxl_cputopology_list_free(topology, n_cpus);
+        libxl_topology_free(topology);
         return -ERROR_FAIL;
     }
 
     /* Reset Pool-0 to 1st node: first add cpus, then remove cpus to avoid
        a cpupool without cpus in between */
 
-    node = topology[0].node;
+    node = topology->cpu[0].node;
     if (libxl_cpupool_cpuadd_node(ctx, 0, node, &n)) {
         fprintf(stderr, "error on adding cpu to Pool 0\n");
         return -ERROR_FAIL;
@@ -7520,9 +7518,9 @@ int main_cpupoolnumasplit(int argc, char **argv)
     }
 
     n = 0;
-    for (c = 0; c < n_cpus; c++) {
-        if (topology[c].node == node) {
-            topology[c].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
+    for (c = 0; c < topology->cpu_num; c++) {
+        if (topology->cpu[c].node == node) {
+            topology->cpu[c].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
             libxl_bitmap_set(&cpumap, n);
             n++;
         }
@@ -7547,12 +7545,12 @@ int main_cpupoolnumasplit(int argc, char **argv)
     }
     libxl_bitmap_set_none(&cpumap);
 
-    for (c = 0; c < n_cpus; c++) {
-        if (topology[c].node == LIBXL_CPUTOPOLOGY_INVALID_ENTRY) {
+    for (c = 0; c < topology->cpu_num; c++) {
+        if (topology->cpu[c].node == LIBXL_CPUTOPOLOGY_INVALID_ENTRY) {
             continue;
         }
 
-        node = topology[c].node;
+        node = topology->cpu[c].node;
         ret = -libxl_cpupool_cpuremove_node(ctx, 0, node, &n);
         if (ret) {
             fprintf(stderr, "error on removing cpu from Pool 0\n");
@@ -7574,15 +7572,15 @@ int main_cpupoolnumasplit(int argc, char **argv)
             goto out;
         }
 
-        for (p = c; p < n_cpus; p++) {
-            if (topology[p].node == node) {
-                topology[p].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
+        for (p = c; p < topology->cpu_num; p++) {
+            if (topology->cpu[p].node == node) {
+                topology->cpu[p].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
             }
         }
     }
 
 out:
-    libxl_cputopology_list_free(topology, n_cpus);
+    libxl_topology_free(topology);
     libxl_bitmap_dispose(&cpumap);
 
     return ret;
-- 
1.8.4.2


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 22:29:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 22:29:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvvwD-0005Sm-BC; Tue, 02 Dec 2014 22:28:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XvvwC-0005Sh-4l
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 22:28:52 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	6F/1F-02954-32D3E745; Tue, 02 Dec 2014 22:28:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417559327!12583872!1
X-Originating-IP: [66.165.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 17362 invoked from network); 2 Dec 2014 22:28:48 -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;
	2 Dec 2014 22:28:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,503,1413244800"; d="scan'208";a="199125350"
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, 2 Dec 2014 17:28: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 1Xvvw5-0005Aw-DV;
	Tue, 02 Dec 2014 22:28:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xvvw4-0007Qh-80;
	Tue, 02 Dec 2014 22:28:44 +0000
Date: Tue, 2 Dec 2014 22:28:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31991-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] 31991: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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-armhf-armhf-libvirt      4 xen-install                 fail pass in 31969
 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 31969 pass in 31991
 test-amd64-i386-pair  3 host-install/src_host(3) broken in 31969 pass in 31991
 test-amd64-i386-pair  4 host-install/dst_host(4) broken in 31969 pass in 31991

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-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-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-amd64-xl-pcipt-intel  9 guest-start                 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
 test-armhf-armhf-libvirt      9 guest-start           fail in 31969 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                                 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 Tue Dec 02 22:29:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 22:29:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvvwD-0005Sm-BC; Tue, 02 Dec 2014 22:28:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XvvwC-0005Sh-4l
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 22:28:52 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	6F/1F-02954-32D3E745; Tue, 02 Dec 2014 22:28:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417559327!12583872!1
X-Originating-IP: [66.165.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 17362 invoked from network); 2 Dec 2014 22:28:48 -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;
	2 Dec 2014 22:28:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,503,1413244800"; d="scan'208";a="199125350"
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, 2 Dec 2014 17:28: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 1Xvvw5-0005Aw-DV;
	Tue, 02 Dec 2014 22:28:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xvvw4-0007Qh-80;
	Tue, 02 Dec 2014 22:28:44 +0000
Date: Tue, 2 Dec 2014 22:28:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31991-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] 31991: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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-armhf-armhf-libvirt      4 xen-install                 fail pass in 31969
 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 31969 pass in 31991
 test-amd64-i386-pair  3 host-install/src_host(3) broken in 31969 pass in 31991
 test-amd64-i386-pair  4 host-install/dst_host(4) broken in 31969 pass in 31991

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-libvirt      9 guest-start                  fail   never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-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-amd64-xl-pcipt-intel  9 guest-start                 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
 test-armhf-armhf-libvirt      9 guest-start           fail in 31969 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                                 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 Tue Dec 02 23:10:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 23: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 1XvwaJ-00062Q-Sy; Tue, 02 Dec 2014 23:10: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 1XvwaH-00062L-Tv
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 23:10:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D0/6C-25276-9D64E745; Tue, 02 Dec 2014 23:10:17 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417561815!12990025!1
X-Originating-IP: [156.151.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 32507 invoked from network); 2 Dec 2014 23:10:16 -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; 2 Dec 2014 23:10:16 -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 sB2NAAOF012182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 23:10:11 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
	sB2NA8hW001699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 23:10:09 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
	sB2NA7gC029591; Tue, 2 Dec 2014 23:10:08 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, 02 Dec 2014 15:10:07 -0800
Message-ID: <547E4736.5000303@oracle.com>
Date: Tue, 02 Dec 2014 18:11:50 -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>,
	xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
	<1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: Re: [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>
Content-Transfer-Encoding: 7bit
Content-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 05:17 PM, Konrad Rzeszutek Wilk wrote:
> 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.


Doesn't this all mean that patch 1/7 broke pcistub_put_pci_dev()?

-boris


>
> 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);
>   


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 23:10:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 23: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 1XvwaJ-00062Q-Sy; Tue, 02 Dec 2014 23:10: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 1XvwaH-00062L-Tv
	for xen-devel@lists.xenproject.org; Tue, 02 Dec 2014 23:10:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D0/6C-25276-9D64E745; Tue, 02 Dec 2014 23:10:17 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417561815!12990025!1
X-Originating-IP: [156.151.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 32507 invoked from network); 2 Dec 2014 23:10:16 -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; 2 Dec 2014 23:10:16 -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 sB2NAAOF012182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 2 Dec 2014 23:10:11 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
	sB2NA8hW001699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2014 23:10:09 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
	sB2NA7gC029591; Tue, 2 Dec 2014 23:10:08 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, 02 Dec 2014 15:10:07 -0800
Message-ID: <547E4736.5000303@oracle.com>
Date: Tue, 02 Dec 2014 18:11:50 -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>,
	xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, bhelgaas@google.com, linux@eikelenboom.it
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
	<1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: Re: [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>
Content-Transfer-Encoding: 7bit
Content-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 05:17 PM, Konrad Rzeszutek Wilk wrote:
> 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.


Doesn't this all mean that patch 1/7 broke pcistub_put_pci_dev()?

-boris


>
> 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);
>   


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

From xen-devel-bounces@lists.xen.org Tue Dec 02 23:59:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 23: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 1XvxLH-000702-W9; Tue, 02 Dec 2014 23:58: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 1XvxLG-0006zx-Na
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 23:58:50 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	B0/02-29352-A325E745; Tue, 02 Dec 2014 23:58:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417564727!5765562!1
X-Originating-IP: [66.165.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 23586 invoked from network); 2 Dec 2014 23:58: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;
	2 Dec 2014 23:58:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,504,1413244800"; d="scan'208";a="198823172"
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, 2 Dec 2014 18:50: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 1XvxD8-0005ZX-PO;
	Tue, 02 Dec 2014 23:50:26 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvxD8-0006iD-De;
	Tue, 02 Dec 2014 23:50:26 +0000
Date: Tue, 2 Dec 2014 23:50:26 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31993-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] 31993: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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. 26303
 build-armhf                   4 host-build-prep  fail in 31972 REGR. vs. 26303
 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail in 31972 REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install      fail pass in 31972
 test-amd64-i386-xl-credit2  13 guest-saverestore.2 fail in 31972 pass in 31993

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 31972 like 26261
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot  fail in 31972 blocked in 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install       fail in 31972 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  1 build-check(1)             blocked n/a
 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  1 build-check(1)               blocked  n/a
 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      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  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-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf      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           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-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-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-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-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-pair         1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)            blocked in 31972 n/a
 build-armhf-libvirt           1 build-check(1)            blocked in 31972 n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 31972 never pass
 test-armhf-armhf-xl           1 build-check(1)            blocked in 31972 n/a
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 31972 never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 31972 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 31972 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31972 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop      fail in 31972 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                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          blocked 
 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                    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-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-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 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                         fail    
 test-amd64-amd64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     fail    
 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 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 Dec 02 23:59:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 02 Dec 2014 23: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 1XvxLH-000702-W9; Tue, 02 Dec 2014 23:58: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 1XvxLG-0006zx-Na
	for xen-devel@lists.xensource.com; Tue, 02 Dec 2014 23:58:50 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	B0/02-29352-A325E745; Tue, 02 Dec 2014 23:58:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417564727!5765562!1
X-Originating-IP: [66.165.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 23586 invoked from network); 2 Dec 2014 23:58: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;
	2 Dec 2014 23:58:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,504,1413244800"; d="scan'208";a="198823172"
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, 2 Dec 2014 18:50: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 1XvxD8-0005ZX-PO;
	Tue, 02 Dec 2014 23:50:26 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XvxD8-0006iD-De;
	Tue, 02 Dec 2014 23:50:26 +0000
Date: Tue, 2 Dec 2014 23:50:26 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-31993-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] 31993: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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. 26303
 build-armhf                   4 host-build-prep  fail in 31972 REGR. vs. 26303
 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail in 31972 REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install      fail pass in 31972
 test-amd64-i386-xl-credit2  13 guest-saverestore.2 fail in 31972 pass in 31993

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 31972 like 26261
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot  fail in 31972 blocked in 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install       fail in 31972 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  1 build-check(1)             blocked n/a
 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  1 build-check(1)               blocked  n/a
 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      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  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-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf      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           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-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-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-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-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-pair         1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)            blocked in 31972 n/a
 build-armhf-libvirt           1 build-check(1)            blocked in 31972 n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 31972 never pass
 test-armhf-armhf-xl           1 build-check(1)            blocked in 31972 n/a
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 31972 never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 31972 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 31972 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 31972 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop      fail in 31972 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                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          blocked 
 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                    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-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-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 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                         fail    
 test-amd64-amd64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     fail    
 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 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 Dec 03 00:10:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 00:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvxWV-0007on-6o; Wed, 03 Dec 2014 00:10:27 +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 1XvxWT-0007oi-Fw
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 00:10:25 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	7A/3B-31453-0F45E745; Wed, 03 Dec 2014 00:10:24 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417565424!11217115!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17116 invoked from network); 3 Dec 2014 00:10:24 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 00:10:24 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-27-15-155.glfd.adsl.virginm.net ([86.27.15.155]:57238
	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 1XvxWO-0006me-Fg (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Wed, 03 Dec 2014 00:10:21 +0000
Message-ID: <547E54EB.8070707@citrix.com>
Date: Wed, 03 Dec 2014 00:10:19 +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>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141202204825.GS357@laptop.dumpdata.com>
In-Reply-To: <20141202204825.GS357@laptop.dumpdata.com>
Cc: stefano.stabellini@eu.citrix.com, david.vrabel@citrix.com,
	linux-kernel@vger.kernel.org, jun.nakajima@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4 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 02/12/2014 20:48, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 03:19:11PM -0500, Boris Ostrovsky wrote:
>> Changes in v4:
>> * Added comment describing what we check for in pci_xen_init()
>>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

>
>> 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               | 31 +++++++++++++-
>>  2 files changed, 120 insertions(+), 2 deletions(-)
>>  create mode 100644 arch/x86/include/asm/xen/cpuid.h
>>
>> -- 
>> 1.8.1.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 Dec 03 00:10:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 00:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvxWV-0007on-6o; Wed, 03 Dec 2014 00:10:27 +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 1XvxWT-0007oi-Fw
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 00:10:25 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	7A/3B-31453-0F45E745; Wed, 03 Dec 2014 00:10:24 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417565424!11217115!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17116 invoked from network); 3 Dec 2014 00:10:24 -0000
Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk)
	(131.111.8.152)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 00:10:24 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-86-27-15-155.glfd.adsl.virginm.net ([86.27.15.155]:57238
	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 1XvxWO-0006me-Fg (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Wed, 03 Dec 2014 00:10:21 +0000
Message-ID: <547E54EB.8070707@citrix.com>
Date: Wed, 03 Dec 2014 00:10:19 +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>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141202204825.GS357@laptop.dumpdata.com>
In-Reply-To: <20141202204825.GS357@laptop.dumpdata.com>
Cc: stefano.stabellini@eu.citrix.com, david.vrabel@citrix.com,
	linux-kernel@vger.kernel.org, jun.nakajima@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4 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 02/12/2014 20:48, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 03:19:11PM -0500, Boris Ostrovsky wrote:
>> Changes in v4:
>> * Added comment describing what we check for in pci_xen_init()
>>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

>
>> 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               | 31 +++++++++++++-
>>  2 files changed, 120 insertions(+), 2 deletions(-)
>>  create mode 100644 arch/x86/include/asm/xen/cpuid.h
>>
>> -- 
>> 1.8.1.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 Dec 03 00:41:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 00: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 1Xvy0L-0008KU-AW; Wed, 03 Dec 2014 00:41:17 +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 1Xvy0K-0008KP-CC
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 00:41:16 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	CD/21-17735-B2C5E745; Wed, 03 Dec 2014 00:41:15 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417567274!15400121!1
X-Originating-IP: [62.245.132.108]
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 1975 invoked from network); 3 Dec 2014 00:41:14 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 3 Dec 2014 00:41:14 -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 1Xvxzz-0003uo-3o; Wed, 03 Dec 2014 01:40:55 +0100
Date: Wed, 3 Dec 2014 01:40:53 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Waiman Long <Waiman.Long@hp.com>
In-Reply-To: <1414613951-32532-11-git-send-email-Waiman.Long@hp.com>
Message-ID: <alpine.DEB.2.11.1412030115100.16275@nanos>
References: <1414613951-32532-1-git-send-email-Waiman.Long@hp.com>
	<1414613951-32532-11-git-send-email-Waiman.Long@hp.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: linux-arch@vger.kernel.org,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	kvm@vger.kernel.org, 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,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>, Douglas Hatch <doug.hatch@hp.com>
Subject: Re: [Xen-devel] [PATCH v13 10/11] pvqspinlock,
 x86: Enable PV qspinlock for KVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 29 Oct 2014, Waiman Long wrote:
>                 AIM7 XFS Disk Test (no overcommit)
>   kernel                 JPM    Real Time   Sys Time    Usr Time
>   -----                  ---    ---------   --------    --------
>   PV ticketlock         2542373    7.08       98.95       5.44
>   PV qspinlock          2549575    7.06       98.63       5.40
>   unfairlock	        2616279    6.91       97.05       5.42
> 
>                 AIM7 XFS Disk Test (200% overcommit)
>   kernel                 JPM    Real Time   Sys Time    Usr Time
>   -----                  ---    ---------   --------    --------
>   PV ticketlock         644468    27.93      415.22       6.33
>   PV qspinlock          645624    27.88      419.84       0.39

That number is made up by what? ----------------------------^^^^

>   unfairlock	        695518    25.88      377.40       4.09
> 
>                 AIM7 EXT4 Disk Test (no overcommit)
>   kernel                 JPM    Real Time   Sys Time    Usr Time
>   -----                  ---    ---------   --------    --------
>   PV ticketlock         1995565    9.02      103.67       5.76
>   PV qspinlock          2011173    8.95      102.15       5.40
>   unfairlock	        2066590    8.71       98.13       5.46
> 
>                 AIM7 EXT4 Disk Test (200% overcommit)
>   kernel                 JPM    Real Time   Sys Time    Usr Time
>   -----                  ---    ---------   --------    --------
>   PV ticketlock         478341    37.63      495.81      30.78
>   PV qspinlock          474058    37.97      475.74      30.95
>   unfairlock	        560224    32.13      398.43      26.27
> 
> For the AIM7 disk workload, both PV ticketlock and qspinlock have
> about the same performance. The unfairlock performs slightly better
> than the PV lock.

Slightly?

Taking the PV locks, which are basically the same for the existing
ticket locks and your new fangled qlocks as a reference then the so
called 'unfair locks' which are just the native locks w/o the PV
nonsense are fundamentally better up to a whopping 18% in the
ext4/200% overcommit case. See below.
 
>                 EBIZZY-m Test (no overcommit)
>   kernel                Rec/s   Real Time   Sys Time    Usr Time
>   -----                 -----   ---------   --------    --------
>   PV ticketlock         3255      10.00       60.65       3.62
>   PV qspinlock          3318      10.00       54.27       3.60
>   unfairlock	        2833      10.00       26.66       3.09
> 
>                 EBIZZY-m Test (200% overcommit)
>   kernel                Rec/s   Real Time   Sys Time    Usr Time
>   -----                 -----   ---------   --------    --------
>   PV ticketlock          841      10.00       71.03       2.37
>   PV qspinlock           834      10.00       68.27       2.39
>   unfairlock	         865      10.00       27.08       1.51
> 
>   futextest (no overcommit)
>   kernel               kops/s
>   -----                ------
>   PV ticketlock        11523
>   PV qspinlock         12328
>   unfairlock	        9478
> 
>   futextest (200% overcommit)
>   kernel               kops/s
>   -----                ------
>   PV ticketlock         7276
>   PV qspinlock          7095
>   unfairlock	        5614
> 
> The ebizzy and futextest have much higher spinlock contention than
> the AIM7 disk workload. In this case, the unfairlock performs worse
> than both the PV ticketlock and qspinlock. The performance of the 2
> PV locks are comparable.

While I can see that the PV lock stuff performs 13% better for the
ebizzy no overcommit case, what about the very interresting numbers
for the same test with 200% overcommit?

The regular lock has a slightly better performance, but significantly
less sys/usr time. How do you explain that?

'Lies, damned lies and statistics' comes to my mind.

Thanks,

	tglx

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 00:41:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 00: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 1Xvy0L-0008KU-AW; Wed, 03 Dec 2014 00:41:17 +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 1Xvy0K-0008KP-CC
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 00:41:16 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	CD/21-17735-B2C5E745; Wed, 03 Dec 2014 00:41:15 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417567274!15400121!1
X-Originating-IP: [62.245.132.108]
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 1975 invoked from network); 3 Dec 2014 00:41:14 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 3 Dec 2014 00:41:14 -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 1Xvxzz-0003uo-3o; Wed, 03 Dec 2014 01:40:55 +0100
Date: Wed, 3 Dec 2014 01:40:53 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Waiman Long <Waiman.Long@hp.com>
In-Reply-To: <1414613951-32532-11-git-send-email-Waiman.Long@hp.com>
Message-ID: <alpine.DEB.2.11.1412030115100.16275@nanos>
References: <1414613951-32532-1-git-send-email-Waiman.Long@hp.com>
	<1414613951-32532-11-git-send-email-Waiman.Long@hp.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: linux-arch@vger.kernel.org,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	kvm@vger.kernel.org, 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,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>, Douglas Hatch <doug.hatch@hp.com>
Subject: Re: [Xen-devel] [PATCH v13 10/11] pvqspinlock,
 x86: Enable PV qspinlock for KVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 29 Oct 2014, Waiman Long wrote:
>                 AIM7 XFS Disk Test (no overcommit)
>   kernel                 JPM    Real Time   Sys Time    Usr Time
>   -----                  ---    ---------   --------    --------
>   PV ticketlock         2542373    7.08       98.95       5.44
>   PV qspinlock          2549575    7.06       98.63       5.40
>   unfairlock	        2616279    6.91       97.05       5.42
> 
>                 AIM7 XFS Disk Test (200% overcommit)
>   kernel                 JPM    Real Time   Sys Time    Usr Time
>   -----                  ---    ---------   --------    --------
>   PV ticketlock         644468    27.93      415.22       6.33
>   PV qspinlock          645624    27.88      419.84       0.39

That number is made up by what? ----------------------------^^^^

>   unfairlock	        695518    25.88      377.40       4.09
> 
>                 AIM7 EXT4 Disk Test (no overcommit)
>   kernel                 JPM    Real Time   Sys Time    Usr Time
>   -----                  ---    ---------   --------    --------
>   PV ticketlock         1995565    9.02      103.67       5.76
>   PV qspinlock          2011173    8.95      102.15       5.40
>   unfairlock	        2066590    8.71       98.13       5.46
> 
>                 AIM7 EXT4 Disk Test (200% overcommit)
>   kernel                 JPM    Real Time   Sys Time    Usr Time
>   -----                  ---    ---------   --------    --------
>   PV ticketlock         478341    37.63      495.81      30.78
>   PV qspinlock          474058    37.97      475.74      30.95
>   unfairlock	        560224    32.13      398.43      26.27
> 
> For the AIM7 disk workload, both PV ticketlock and qspinlock have
> about the same performance. The unfairlock performs slightly better
> than the PV lock.

Slightly?

Taking the PV locks, which are basically the same for the existing
ticket locks and your new fangled qlocks as a reference then the so
called 'unfair locks' which are just the native locks w/o the PV
nonsense are fundamentally better up to a whopping 18% in the
ext4/200% overcommit case. See below.
 
>                 EBIZZY-m Test (no overcommit)
>   kernel                Rec/s   Real Time   Sys Time    Usr Time
>   -----                 -----   ---------   --------    --------
>   PV ticketlock         3255      10.00       60.65       3.62
>   PV qspinlock          3318      10.00       54.27       3.60
>   unfairlock	        2833      10.00       26.66       3.09
> 
>                 EBIZZY-m Test (200% overcommit)
>   kernel                Rec/s   Real Time   Sys Time    Usr Time
>   -----                 -----   ---------   --------    --------
>   PV ticketlock          841      10.00       71.03       2.37
>   PV qspinlock           834      10.00       68.27       2.39
>   unfairlock	         865      10.00       27.08       1.51
> 
>   futextest (no overcommit)
>   kernel               kops/s
>   -----                ------
>   PV ticketlock        11523
>   PV qspinlock         12328
>   unfairlock	        9478
> 
>   futextest (200% overcommit)
>   kernel               kops/s
>   -----                ------
>   PV ticketlock         7276
>   PV qspinlock          7095
>   unfairlock	        5614
> 
> The ebizzy and futextest have much higher spinlock contention than
> the AIM7 disk workload. In this case, the unfairlock performs worse
> than both the PV ticketlock and qspinlock. The performance of the 2
> PV locks are comparable.

While I can see that the PV lock stuff performs 13% better for the
ebizzy no overcommit case, what about the very interresting numbers
for the same test with 200% overcommit?

The regular lock has a slightly better performance, but significantly
less sys/usr time. How do you explain that?

'Lies, damned lies and statistics' comes to my mind.

Thanks,

	tglx

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 00:43:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 00:43:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvy2p-0008Ro-Ry; Wed, 03 Dec 2014 00:43: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 1Xvy2o-0008Rh-IN
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 00:43:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FA/9E-15461-5CC5E745; Wed, 03 Dec 2014 00:43:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417567427!12968846!1
X-Originating-IP: [66.165.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 5212 invoked from network); 3 Dec 2014 00:43:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 00:43:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,504,1413244800"; d="scan'208";a="198838551"
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, 2 Dec 2014 19:43: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 1Xvy2j-0005pQ-QA;
	Wed, 03 Dec 2014 00:43:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xvy2j-0007pQ-I5;
	Wed, 03 Dec 2014 00:43:45 +0000
Date: Wed, 3 Dec 2014 00:43:45 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32006-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] 32006: 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 32006 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32006/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d
baseline version:
 rumpuserxen          6dac8499151377c6e5eb57b5bf1fff7b62776ca5

------------------------------------------------------------
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=f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d
+ . 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 f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d
+ branch=rumpuserxen
+ revision=f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d
+ . 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 f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   6dac849..f302fca  f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d -> 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 Dec 03 00:43:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 00:43:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvy2p-0008Ro-Ry; Wed, 03 Dec 2014 00:43: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 1Xvy2o-0008Rh-IN
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 00:43:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FA/9E-15461-5CC5E745; Wed, 03 Dec 2014 00:43:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417567427!12968846!1
X-Originating-IP: [66.165.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 5212 invoked from network); 3 Dec 2014 00:43:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 00:43:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,504,1413244800"; d="scan'208";a="198838551"
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, 2 Dec 2014 19:43: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 1Xvy2j-0005pQ-QA;
	Wed, 03 Dec 2014 00:43:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xvy2j-0007pQ-I5;
	Wed, 03 Dec 2014 00:43:45 +0000
Date: Wed, 3 Dec 2014 00:43:45 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32006-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] 32006: 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 32006 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32006/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d
baseline version:
 rumpuserxen          6dac8499151377c6e5eb57b5bf1fff7b62776ca5

------------------------------------------------------------
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=f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d
+ . 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 f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d
+ branch=rumpuserxen
+ revision=f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d
+ . 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 f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   6dac849..f302fca  f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d -> 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 Dec 03 02:29:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 02:29:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvzgF-0005qp-6X; Wed, 03 Dec 2014 02:28:39 +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 1XvzgD-0005qk-Qz
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 02:28:37 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	88/26-02698-5557E745; Wed, 03 Dec 2014 02:28:37 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417573716!12606437!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 8927 invoked from network); 3 Dec 2014 02:28:36 -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; 3 Dec 2014 02:28:36 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 13BAAAB43;
	Wed,  3 Dec 2014 02:28:33 +0000 (UTC)
Date: Wed, 3 Dec 2014 03:28:33 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141203022833.GS25677@wotan.suse.de>
References: <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
	<547CB07C.1050507@citrix.com>
	<20141201223611.GM25677@wotan.suse.de> <547D9E56.50708@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547D9E56.50708@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>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 Tue, Dec 02, 2014 at 11:11:18AM +0000, David Vrabel wrote:
> On 01/12/14 22:36, Luis R. Rodriguez wrote:
> > 
> > Then I do agree its a fair analogy (and find this obviously odd that how
> > widespread cond_resched() is), we just don't have an equivalent for IRQ
> > context, why not avoid the special check then and use this all the time in the
> > middle of a hypercall on the return from an interrupt (e.g., the timer
> > interrupt)?
> 
> http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html

OK thanks! That explains why we need some asm code but in that submission you
still also had used is_preemptible_hypercall(regs) and in the new
implementation you use a CPU variable xen_in_preemptible_hcall prior to calling
preempt_schedule_irq(). I believe you added the CPU variable because
preempt_schedule_irq() will preempt first without any checks if it should, I'm
asking why not do something like cond_resched_irq() where we check with
should_resched() prior to preempting and that way we can avoid having to use
the CPU variable?

  Luis

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 02:29:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 02:29:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XvzgF-0005qp-6X; Wed, 03 Dec 2014 02:28:39 +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 1XvzgD-0005qk-Qz
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 02:28:37 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	88/26-02698-5557E745; Wed, 03 Dec 2014 02:28:37 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417573716!12606437!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 8927 invoked from network); 3 Dec 2014 02:28:36 -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; 3 Dec 2014 02:28:36 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 13BAAAB43;
	Wed,  3 Dec 2014 02:28:33 +0000 (UTC)
Date: Wed, 3 Dec 2014 03:28:33 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141203022833.GS25677@wotan.suse.de>
References: <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
	<547CB07C.1050507@citrix.com>
	<20141201223611.GM25677@wotan.suse.de> <547D9E56.50708@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547D9E56.50708@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>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 Tue, Dec 02, 2014 at 11:11:18AM +0000, David Vrabel wrote:
> On 01/12/14 22:36, Luis R. Rodriguez wrote:
> > 
> > Then I do agree its a fair analogy (and find this obviously odd that how
> > widespread cond_resched() is), we just don't have an equivalent for IRQ
> > context, why not avoid the special check then and use this all the time in the
> > middle of a hypercall on the return from an interrupt (e.g., the timer
> > interrupt)?
> 
> http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html

OK thanks! That explains why we need some asm code but in that submission you
still also had used is_preemptible_hypercall(regs) and in the new
implementation you use a CPU variable xen_in_preemptible_hcall prior to calling
preempt_schedule_irq(). I believe you added the CPU variable because
preempt_schedule_irq() will preempt first without any checks if it should, I'm
asking why not do something like cond_resched_irq() where we check with
should_resched() prior to preempting and that way we can avoid having to use
the CPU variable?

  Luis

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 02:34:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 02:34:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvzla-00064T-DT; Wed, 03 Dec 2014 02:34: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 1XvzlZ-00064M-30
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 02:34:09 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B7/C6-15461-0A67E745; Wed, 03 Dec 2014 02:34:08 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417574046!12942923!1
X-Originating-IP: [66.165.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 10192 invoked from network); 3 Dec 2014 02:34: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 Dec 2014 02:34:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,505,1413244800"; d="scan'208";a="198867067"
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, 2 Dec 2014 21: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 1XvzlV-0006Mn-0A;
	Wed, 03 Dec 2014 02: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 1XvzlU-0003Vp-OQ;
	Wed, 03 Dec 2014 02:34:04 +0000
Date: Wed, 3 Dec 2014 02:34:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32005-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] 32005: 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 32005 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32005/

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              ff018e686a8a412255bc34d3dc558a1bcf74fac5
baseline version:
 libvirt              6085d917d5c5839b7ed351e99fadbbb56f5178fe

------------------------------------------------------------
People who touched revisions under test:
  Eduardo Costa <eduardobmc@gmail.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Jiri Denemark <jdenemar@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Luyao Huang <lhuang@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?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=ff018e686a8a412255bc34d3dc558a1bcf74fac5
+ . 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 ff018e686a8a412255bc34d3dc558a1bcf74fac5
+ branch=libvirt
+ revision=ff018e686a8a412255bc34d3dc558a1bcf74fac5
+ . 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 ff018e686a8a412255bc34d3dc558a1bcf74fac5:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   6085d91..ff018e6  ff018e686a8a412255bc34d3dc558a1bcf74fac5 -> 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 Dec 03 02:34:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 02:34:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xvzla-00064T-DT; Wed, 03 Dec 2014 02:34: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 1XvzlZ-00064M-30
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 02:34:09 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B7/C6-15461-0A67E745; Wed, 03 Dec 2014 02:34:08 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417574046!12942923!1
X-Originating-IP: [66.165.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 10192 invoked from network); 3 Dec 2014 02:34: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 Dec 2014 02:34:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,505,1413244800"; d="scan'208";a="198867067"
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, 2 Dec 2014 21: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 1XvzlV-0006Mn-0A;
	Wed, 03 Dec 2014 02: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 1XvzlU-0003Vp-OQ;
	Wed, 03 Dec 2014 02:34:04 +0000
Date: Wed, 3 Dec 2014 02:34:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32005-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] 32005: 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 32005 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32005/

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              ff018e686a8a412255bc34d3dc558a1bcf74fac5
baseline version:
 libvirt              6085d917d5c5839b7ed351e99fadbbb56f5178fe

------------------------------------------------------------
People who touched revisions under test:
  Eduardo Costa <eduardobmc@gmail.com>
  Eric Blake <eblake@redhat.com>
  Erik Skultety <eskultet@redhat.com>
  Jiri Denemark <jdenemar@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Luyao Huang <lhuang@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?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=ff018e686a8a412255bc34d3dc558a1bcf74fac5
+ . 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 ff018e686a8a412255bc34d3dc558a1bcf74fac5
+ branch=libvirt
+ revision=ff018e686a8a412255bc34d3dc558a1bcf74fac5
+ . 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 ff018e686a8a412255bc34d3dc558a1bcf74fac5:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   6085d91..ff018e6  ff018e686a8a412255bc34d3dc558a1bcf74fac5 -> 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 Dec 03 03:21:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 03:21:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw0V6-0007DM-VB; Wed, 03 Dec 2014 03:21:12 +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 1Xw0V5-0007DH-KD
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 03:21:11 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	DE/79-27785-7A18E745; Wed, 03 Dec 2014 03:21:11 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417576869!12606233!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 795 invoked from network); 3 Dec 2014 03:21:10 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-13.tower-27.messagelabs.com with SMTP;
	3 Dec 2014 03:21:10 -0000
Received: from localhost (unknown [12.131.143.131])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 4C633590754;
	Tue,  2 Dec 2014 19:21:08 -0800 (PST)
Date: Tue, 02 Dec 2014 19:25:30 -0800 (PST)
Message-Id: <20141202.192530.460426718376541462.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.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]);
	Tue, 02 Dec 2014 19:21:09 -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>

Applied, thanks.

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 03:21:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 03:21:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw0V6-0007DM-VB; Wed, 03 Dec 2014 03:21:12 +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 1Xw0V5-0007DH-KD
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 03:21:11 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	DE/79-27785-7A18E745; Wed, 03 Dec 2014 03:21:11 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417576869!12606233!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 795 invoked from network); 3 Dec 2014 03:21:10 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-13.tower-27.messagelabs.com with SMTP;
	3 Dec 2014 03:21:10 -0000
Received: from localhost (unknown [12.131.143.131])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 4C633590754;
	Tue,  2 Dec 2014 19:21:08 -0800 (PST)
Date: Tue, 02 Dec 2014 19:25:30 -0800 (PST)
Message-Id: <20141202.192530.460426718376541462.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.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]);
	Tue, 02 Dec 2014 19:21:09 -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>

Applied, thanks.

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 04:38:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 04:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw1hN-0008Hw-Sh; Wed, 03 Dec 2014 04:37:57 +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 1Xw1hL-0008Hr-Pg
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 04:37:55 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	2F/2C-08051-3A39E745; Wed, 03 Dec 2014 04:37:55 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417581474!9273403!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 3977 invoked from network); 3 Dec 2014 04:37:54 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 04:37:54 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id EA9E8AC7D;
	Wed,  3 Dec 2014 04:37:52 +0000 (UTC)
Message-ID: <547E939F.40106@suse.com>
Date: Wed, 03 Dec 2014 05:37: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: "Luis R. Rodriguez" <mcgrof@suse.com>, 
	David Vrabel <david.vrabel@citrix.com>
References: <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
	<547CB07C.1050507@citrix.com>
	<20141201223611.GM25677@wotan.suse.de> <547D9E56.50708@citrix.com>
	<20141203022833.GS25677@wotan.suse.de>
In-Reply-To: <20141203022833.GS25677@wotan.suse.de>
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 12/03/2014 03:28 AM, Luis R. Rodriguez wrote:
> On Tue, Dec 02, 2014 at 11:11:18AM +0000, David Vrabel wrote:
>> On 01/12/14 22:36, Luis R. Rodriguez wrote:
>>>
>>> Then I do agree its a fair analogy (and find this obviously odd that how
>>> widespread cond_resched() is), we just don't have an equivalent for IRQ
>>> context, why not avoid the special check then and use this all the time in the
>>> middle of a hypercall on the return from an interrupt (e.g., the timer
>>> interrupt)?
>>
>> http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html
>
> OK thanks! That explains why we need some asm code but in that submission you
> still also had used is_preemptible_hypercall(regs) and in the new
> implementation you use a CPU variable xen_in_preemptible_hcall prior to calling
> preempt_schedule_irq(). I believe you added the CPU variable because
> preempt_schedule_irq() will preempt first without any checks if it should, I'm
> asking why not do something like cond_resched_irq() where we check with
> should_resched() prior to preempting and that way we can avoid having to use
> the CPU variable?

Because that could preempt at any asynchronous interrupt making the
no-preempt kernel fully preemptive. How would you know you are just
doing a critical hypercall which should be preempted?

Juergen


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 04:38:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 04:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw1hN-0008Hw-Sh; Wed, 03 Dec 2014 04:37:57 +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 1Xw1hL-0008Hr-Pg
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 04:37:55 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	2F/2C-08051-3A39E745; Wed, 03 Dec 2014 04:37:55 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417581474!9273403!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 3977 invoked from network); 3 Dec 2014 04:37:54 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 04:37:54 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id EA9E8AC7D;
	Wed,  3 Dec 2014 04:37:52 +0000 (UTC)
Message-ID: <547E939F.40106@suse.com>
Date: Wed, 03 Dec 2014 05:37: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: "Luis R. Rodriguez" <mcgrof@suse.com>, 
	David Vrabel <david.vrabel@citrix.com>
References: <20141127183616.GV25677@wotan.suse.de>
	<547C4CEF.1010603@citrix.com>
	<20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
	<547CB07C.1050507@citrix.com>
	<20141201223611.GM25677@wotan.suse.de> <547D9E56.50708@citrix.com>
	<20141203022833.GS25677@wotan.suse.de>
In-Reply-To: <20141203022833.GS25677@wotan.suse.de>
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, Borislav Petkov <bp@suse.de>,
	Olaf Hering <ohering@suse.de>, Ingo Molnar <mingo@kernel.org>
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 12/03/2014 03:28 AM, Luis R. Rodriguez wrote:
> On Tue, Dec 02, 2014 at 11:11:18AM +0000, David Vrabel wrote:
>> On 01/12/14 22:36, Luis R. Rodriguez wrote:
>>>
>>> Then I do agree its a fair analogy (and find this obviously odd that how
>>> widespread cond_resched() is), we just don't have an equivalent for IRQ
>>> context, why not avoid the special check then and use this all the time in the
>>> middle of a hypercall on the return from an interrupt (e.g., the timer
>>> interrupt)?
>>
>> http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html
>
> OK thanks! That explains why we need some asm code but in that submission you
> still also had used is_preemptible_hypercall(regs) and in the new
> implementation you use a CPU variable xen_in_preemptible_hcall prior to calling
> preempt_schedule_irq(). I believe you added the CPU variable because
> preempt_schedule_irq() will preempt first without any checks if it should, I'm
> asking why not do something like cond_resched_irq() where we check with
> should_resched() prior to preempting and that way we can avoid having to use
> the CPU variable?

Because that could preempt at any asynchronous interrupt making the
no-preempt kernel fully preemptive. How would you know you are just
doing a critical hypercall which should be preempted?

Juergen


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 04:39:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 04:39:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw1j6-0008PG-D2; Wed, 03 Dec 2014 04:39:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <patel_mp@yahoo.co.in>) id 1Xw1j5-0008P6-L5
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 04:39:43 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	80/C4-22737-E049E745; Wed, 03 Dec 2014 04:39:42 +0000
X-Env-Sender: patel_mp@yahoo.co.in
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417581578!11171154!1
X-Originating-IP: [106.10.151.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7984 invoked from network); 3 Dec 2014 04:39:41 -0000
Received: from nm24-vm2.bullet.mail.sg3.yahoo.com (HELO
	nm24-vm2.bullet.mail.sg3.yahoo.com) (106.10.151.81)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 04:39:41 -0000
Received: from [106.10.166.121] by nm24.bullet.mail.sg3.yahoo.com with NNFMP;
	03 Dec 2014 04:39:38 -0000
Received: from [106.10.151.234] by tm10.bullet.mail.sg3.yahoo.com with NNFMP;
	03 Dec 2014 04:39:38 -0000
Received: from [127.0.0.1] by omp1018.mail.sg3.yahoo.com with NNFMP;
	03 Dec 2014 04:39:38 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 5742.94594.bm@omp1018.mail.sg3.yahoo.com
Received: (qmail 40544 invoked by uid 60001); 3 Dec 2014 04:39:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024;
	t=1417581577; bh=vbqBGekd9Q3mXiCLyKz6puobURBH4FJ6rOTPz2qSuuM=;
	h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=Wwoci1DqxFf+Y+Jl2TJBsngyvDS/5zj9/N6nspZFWgU61ZaROSjdP32cgx4HAH4y9Z0DXfvwxSsj214QEgOhD68Ggc/6tkW1qNL3ltA/R0fAgUsGoi6nki/e7zJJdVI41xfBXK5WV3UUTuiwMuO2w+4eY7ZQG1zCoUZW5rpI/iw=
X-YMail-OSG: yw2vWhoVM1k3f1XS3FANmbRMFJ2KM9yCNT6cp5xhhEsnSRJ
	vQ.tHtkucNTC2zQ.t69COp6wZFDymg.kudFW1GycKhXgUN1AhFH_a6UGmnC6
	6IR72_7SYCkdyzACUlP0eHs_hBlsNBmkmnSbIEUZdvshiJ1YbmBDkNUiDOQE
	C1iP0DzMVABq1aOL9QYrtK4rRHeSqmAlUTMAJbQopD2B9dY4CmtoXvfNQ2gQ
	pTgjCXcj2cGALQriU.2rimbjVEfWLOPuIPBCYm2xXehJupc3kNQoPXOX0WgM
	Qtt_lWoVsWyrAN3xxb377mbuVw1duWnWNMEoOep88HtXDi2FNZOXXUG0sw4u
	VsMWWWdm0wGiZIrAAdljzcxHV44igukLD46p.OwLK1a_qu_l0BgdfvinOEIg
	J._pELZruMbUIWgTPYwlj48vuaj_BEPnu19C0mS9U_MybhLtZjdIM1LFC8lx
	dOZCBdiBhqs34uDiBCHFp0DnbIB.Kd6.pH2oD20tEMpxPMEKXRA1fxWOKVq8
	Ez5XlILEJDr8Fwc7pLC4txfVEoxlHyK5rIK_pG6YDbtbrhW5X3Vt4tdTs8h_
	I365uAwi04w58_0BnlDB5O0J0UqjFTabS51XyIgiZeSp0pMz9XVEY1jb212g
	PxiJrJwZdeeqKo16VLS_XMywFeWYgsqkSd6x8IeWG3Z45vL1QjO9q8c.8EGC
	zDf1JDRN2kH52g3aNIDcTvA--
Received: from [117.247.92.67] by web190602.mail.sg3.yahoo.com via HTTP;
	Wed, 03 Dec 2014 12:39:37 SGT
X-Rocket-MIMEInfo: 002.001,
	CkhvcGUgYWxsIHdvdWxkIGJlIGZpbmUuCgoKSSByZXF1ZXN0IHlvdSB0byBndWlkZSBteSB0d28gaXNzdWVzIGZvciBsaXZlIG1pZ3JhaXRvbjoKMSkgU2V0IHVwOiBJIHdvdWxkIGxpa2UgdG8gbWlncmF0ZSBteSBleGlzdGluZyBzeXN0ZW0gZnJvbSB4ZW40LjEgdG8geGVuNC4yKy4gSSBoYXZlIGJlZW4gd29ya2luZyB3aXRoIHhlbjQuMS40KyBEUkJEIGZvciBsaXZlIG1pZ3JhdGlvbi4KIAoKSSBoYXZlIG1vZGlmaWVkIGtlcm5lbCBieSBjb21waW5nIGxpbnV4IGFuZCBpbnN0YWxsZWQgeGVuNC4xLjQgYnUBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.203.740
Message-ID: <1417581577.21228.YahooMailNeo@web190602.mail.sg3.yahoo.com>
Date: Wed, 3 Dec 2014 12:39:37 +0800
From: Minalkumar Patel <patel_mp@yahoo.co.in>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] Xen Hardware Setup (DRBD) and Algorithmic Discussion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Minalkumar Patel <patel_mp@yahoo.co.in>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7352228783540597115=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7352228783540597115==
Content-Type: multipart/alternative; boundary="-67152274-33507778-1417581577=:21228"

---67152274-33507778-1417581577=:21228
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0AHope all would be fine.=0A=0A=0AI request you to guide my two issues for=
 live migraiton:=0A1) Set up: I would like to migrate my existing system fr=
om xen4.1 to xen4.2+. I have been working with xen4.1.4+ DRBD for live migr=
ation.=0A =0A=0AI have modified kernel by comping linux and installed xen4.=
1.4 but now i want to migrate to xen4.2+ so please give any idea.=0A=0Anew =
code of xen 4.2+ is downloaded and make world is done  but at the time of m=
igration, ssh connection port 22 error is given. it also shows=0Ain grub tw=
o entries xenolder and xennewer.so is their xen(newer/older) conflict?=0A=
=0A=0A2) Algorithmic Part:=0A=0AI would like to work on Delta compression/P=
rediction technique for live migration using Xen. I have set up Xen Framewo=
rk usign DRB D and completed load balancing kind stuff. I used Xen4.1 for m=
y experimental work which gives freedom to work with xm and xl toolstacks.=
=0A=0ABut compression code is available from xen4.2+. I am understanding da=
ta structures of xc_domain_save and xc_compression using fossies (source co=
de documentation) given in http://fossies.org/dox/xen-4.4.1/xc__domain__sav=
e_8c.html is there any other easy documentation because number of research =
papers are available but i didn't understand the practical aspect from them=
.=0A=0AIansir has requested me about migration v2 (to be proposed in xen6 w=
ritten by Andrew Cooper) for live migration but i did not able to find any =
kind of patch of Coopersir in that email. The email is found in May'14 xen-=
devel but i am not more clear about migration v2.=0A=0ARegards,
---67152274-33507778-1417581577=:21228
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;fo=
nt-size:12px"><div style=3D"color: rgb(34, 34, 34); font-family: arial, san=
s-serif; font-size: 13px;" class=3D""><br class=3D"" style=3D"">Hope all wo=
uld be fine.<br class=3D"" style=3D""><br class=3D"" style=3D""></div><div =
style=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size:=
 13px;" class=3D"">I request you to guide my two issues for live migraiton:=
</div><div style=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif;=
 font-size: 13px;" class=3D"">1) Set up:&nbsp;<span style=3D"color: rgb(0, =
0, 0); font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Luc=
ida Grande', sans-serif; font-size: 12px;" class=3D"">I would like to migra=
te my existing system from xen4.1 to xen4.2+. I have been working with xen4=
.1.4+ DRBD for live migration.</span><div style=3D"color: rgb(0, 0, 0); fon=
t-family: HelveticaNeue,
 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size=
: 12px;" class=3D"">&nbsp;<br class=3D"" style=3D""></div><div style=3D"col=
or: rgb(0, 0, 0); font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, =
Arial, 'Lucida Grande', sans-serif; font-size: 12px;" class=3D"">I have mod=
ified kernel by comping linux and installed xen4.1.4 but now i want to migr=
ate to xen4.2+ so please give any idea.</div><div style=3D"color: rgb(0, 0,=
 0); font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucid=
a Grande', sans-serif; font-size: 12px;" class=3D""><br class=3D"" style=3D=
""></div><div style=3D"color: rgb(0, 0, 0); font-family: HelveticaNeue, 'He=
lvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12=
px;" class=3D"">new code of xen 4.2+ is downloaded and make world is done &=
nbsp;but at the time of migration, ssh connection port 22 error is given. i=
t also shows</div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica=
Neue, 'Helvetica
 Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12px;" cl=
ass=3D"">in grub two entries xenolder and xennewer.so is their xen(newer/ol=
der) conflict?</div><div style=3D"color: rgb(0, 0, 0); font-family: Helveti=
caNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; fo=
nt-size: 12px;" class=3D""><br class=3D"" style=3D""></div><div style=3D"co=
lor: rgb(0, 0, 0); font-family: HelveticaNeue, 'Helvetica Neue', Helvetica,=
 Arial, 'Lucida Grande', sans-serif; font-size: 12px;" class=3D""><br class=
=3D"" style=3D""></div><div style=3D"color: rgb(0, 0, 0); font-family: Helv=
eticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif;=
 font-size: 12px;" class=3D""><span style=3D"font-family: arial, sans-serif=
; font-size: 13px; color: rgb(34, 34, 34);" class=3D"">2) Algorithmic Part:=
</span><br class=3D"" style=3D""></div></div><div class=3D"" style=3D""><sp=
an style=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif; font-si=
ze: 13px;" class=3D"">I would
 like to work on Delta compression/Prediction technique for live migration =
using Xen. I have set up Xen Framework usign DRB D and completed load balan=
cing kind stuff. I used Xen4.1 for my experimental work which gives freedom=
 to work with xm and xl toolstacks.</span><span class=3D"" style=3D""><br s=
tyle=3D""></span></div><div class=3D"" style=3D"color: rgb(0, 0, 0); font-s=
ize: 12px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, =
'Lucida Grande', sans-serif; font-style: normal; background-color: transpar=
ent;"><span style=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif=
; font-size: 13px;" class=3D"">But compression code is available from xen4.=
2+. I am understanding data structures of xc_domain_save and xc_compression=
 using fossies (source code documentation) given in <a href=3D"http://fossi=
es.org/dox/xen-4.4.1/xc__domain__save_8c.html" class=3D"" style=3D"">http:/=
/fossies.org/dox/xen-4.4.1/xc__domain__save_8c.html</a>&nbsp;is there any o=
ther easy
 documentation because number of research papers are available but i didn't=
 understand the practical aspect from them.</span></div><div class=3D"" sty=
le=3D"color: rgb(34, 34, 34); font-size: 13px; font-family: arial, sans-ser=
if; font-style: normal; background-color: transparent;"><span style=3D"colo=
r: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px;" class=
=3D""><br class=3D"" style=3D""></span></div><div class=3D"" style=3D"color=
: rgb(34, 34, 34); font-size: 13px; font-family: arial, sans-serif; font-st=
yle: normal; background-color: transparent;">Iansir has requested me about =
migration v2 (to be proposed in xen6 written by Andrew Cooper) for live mig=
ration but i did not able to find any kind of patch of Coopersir in that em=
ail. The email is found in May'14 xen-devel but i am not more clear about m=
igration v2.</div><div class=3D"" style=3D"color: rgb(34, 34, 34); font-siz=
e: 13px; font-family: arial, sans-serif; font-style: normal; background-col=
or:
 transparent;"><br class=3D"" style=3D""></div><div class=3D"" style=3D"col=
or: rgb(34, 34, 34); font-size: 13px; font-family: arial, sans-serif; font-=
style: normal; background-color: transparent;">Regards,</div><div class=3D"=
" style=3D"color: rgb(34, 34, 34); font-size: 13px; font-family: arial, san=
s-serif; font-style: normal; background-color: transparent;"><br class=3D""=
 style=3D""></div><div class=3D"" style=3D""></div><div class=3D"" style=3D=
"">&nbsp;</div><div class=3D"" style=3D""><br class=3D"" style=3D""></div><=
/div></body></html>
---67152274-33507778-1417581577=:21228--


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

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

--===============7352228783540597115==--


From xen-devel-bounces@lists.xen.org Wed Dec 03 04:39:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 04:39:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw1j6-0008PG-D2; Wed, 03 Dec 2014 04:39:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <patel_mp@yahoo.co.in>) id 1Xw1j5-0008P6-L5
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 04:39:43 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	80/C4-22737-E049E745; Wed, 03 Dec 2014 04:39:42 +0000
X-Env-Sender: patel_mp@yahoo.co.in
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417581578!11171154!1
X-Originating-IP: [106.10.151.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7984 invoked from network); 3 Dec 2014 04:39:41 -0000
Received: from nm24-vm2.bullet.mail.sg3.yahoo.com (HELO
	nm24-vm2.bullet.mail.sg3.yahoo.com) (106.10.151.81)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 04:39:41 -0000
Received: from [106.10.166.121] by nm24.bullet.mail.sg3.yahoo.com with NNFMP;
	03 Dec 2014 04:39:38 -0000
Received: from [106.10.151.234] by tm10.bullet.mail.sg3.yahoo.com with NNFMP;
	03 Dec 2014 04:39:38 -0000
Received: from [127.0.0.1] by omp1018.mail.sg3.yahoo.com with NNFMP;
	03 Dec 2014 04:39:38 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 5742.94594.bm@omp1018.mail.sg3.yahoo.com
Received: (qmail 40544 invoked by uid 60001); 3 Dec 2014 04:39:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024;
	t=1417581577; bh=vbqBGekd9Q3mXiCLyKz6puobURBH4FJ6rOTPz2qSuuM=;
	h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=Wwoci1DqxFf+Y+Jl2TJBsngyvDS/5zj9/N6nspZFWgU61ZaROSjdP32cgx4HAH4y9Z0DXfvwxSsj214QEgOhD68Ggc/6tkW1qNL3ltA/R0fAgUsGoi6nki/e7zJJdVI41xfBXK5WV3UUTuiwMuO2w+4eY7ZQG1zCoUZW5rpI/iw=
X-YMail-OSG: yw2vWhoVM1k3f1XS3FANmbRMFJ2KM9yCNT6cp5xhhEsnSRJ
	vQ.tHtkucNTC2zQ.t69COp6wZFDymg.kudFW1GycKhXgUN1AhFH_a6UGmnC6
	6IR72_7SYCkdyzACUlP0eHs_hBlsNBmkmnSbIEUZdvshiJ1YbmBDkNUiDOQE
	C1iP0DzMVABq1aOL9QYrtK4rRHeSqmAlUTMAJbQopD2B9dY4CmtoXvfNQ2gQ
	pTgjCXcj2cGALQriU.2rimbjVEfWLOPuIPBCYm2xXehJupc3kNQoPXOX0WgM
	Qtt_lWoVsWyrAN3xxb377mbuVw1duWnWNMEoOep88HtXDi2FNZOXXUG0sw4u
	VsMWWWdm0wGiZIrAAdljzcxHV44igukLD46p.OwLK1a_qu_l0BgdfvinOEIg
	J._pELZruMbUIWgTPYwlj48vuaj_BEPnu19C0mS9U_MybhLtZjdIM1LFC8lx
	dOZCBdiBhqs34uDiBCHFp0DnbIB.Kd6.pH2oD20tEMpxPMEKXRA1fxWOKVq8
	Ez5XlILEJDr8Fwc7pLC4txfVEoxlHyK5rIK_pG6YDbtbrhW5X3Vt4tdTs8h_
	I365uAwi04w58_0BnlDB5O0J0UqjFTabS51XyIgiZeSp0pMz9XVEY1jb212g
	PxiJrJwZdeeqKo16VLS_XMywFeWYgsqkSd6x8IeWG3Z45vL1QjO9q8c.8EGC
	zDf1JDRN2kH52g3aNIDcTvA--
Received: from [117.247.92.67] by web190602.mail.sg3.yahoo.com via HTTP;
	Wed, 03 Dec 2014 12:39:37 SGT
X-Rocket-MIMEInfo: 002.001,
	CkhvcGUgYWxsIHdvdWxkIGJlIGZpbmUuCgoKSSByZXF1ZXN0IHlvdSB0byBndWlkZSBteSB0d28gaXNzdWVzIGZvciBsaXZlIG1pZ3JhaXRvbjoKMSkgU2V0IHVwOiBJIHdvdWxkIGxpa2UgdG8gbWlncmF0ZSBteSBleGlzdGluZyBzeXN0ZW0gZnJvbSB4ZW40LjEgdG8geGVuNC4yKy4gSSBoYXZlIGJlZW4gd29ya2luZyB3aXRoIHhlbjQuMS40KyBEUkJEIGZvciBsaXZlIG1pZ3JhdGlvbi4KIAoKSSBoYXZlIG1vZGlmaWVkIGtlcm5lbCBieSBjb21waW5nIGxpbnV4IGFuZCBpbnN0YWxsZWQgeGVuNC4xLjQgYnUBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.203.740
Message-ID: <1417581577.21228.YahooMailNeo@web190602.mail.sg3.yahoo.com>
Date: Wed, 3 Dec 2014 12:39:37 +0800
From: Minalkumar Patel <patel_mp@yahoo.co.in>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] Xen Hardware Setup (DRBD) and Algorithmic Discussion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Minalkumar Patel <patel_mp@yahoo.co.in>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7352228783540597115=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7352228783540597115==
Content-Type: multipart/alternative; boundary="-67152274-33507778-1417581577=:21228"

---67152274-33507778-1417581577=:21228
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0AHope all would be fine.=0A=0A=0AI request you to guide my two issues for=
 live migraiton:=0A1) Set up: I would like to migrate my existing system fr=
om xen4.1 to xen4.2+. I have been working with xen4.1.4+ DRBD for live migr=
ation.=0A =0A=0AI have modified kernel by comping linux and installed xen4.=
1.4 but now i want to migrate to xen4.2+ so please give any idea.=0A=0Anew =
code of xen 4.2+ is downloaded and make world is done  but at the time of m=
igration, ssh connection port 22 error is given. it also shows=0Ain grub tw=
o entries xenolder and xennewer.so is their xen(newer/older) conflict?=0A=
=0A=0A2) Algorithmic Part:=0A=0AI would like to work on Delta compression/P=
rediction technique for live migration using Xen. I have set up Xen Framewo=
rk usign DRB D and completed load balancing kind stuff. I used Xen4.1 for m=
y experimental work which gives freedom to work with xm and xl toolstacks.=
=0A=0ABut compression code is available from xen4.2+. I am understanding da=
ta structures of xc_domain_save and xc_compression using fossies (source co=
de documentation) given in http://fossies.org/dox/xen-4.4.1/xc__domain__sav=
e_8c.html is there any other easy documentation because number of research =
papers are available but i didn't understand the practical aspect from them=
.=0A=0AIansir has requested me about migration v2 (to be proposed in xen6 w=
ritten by Andrew Cooper) for live migration but i did not able to find any =
kind of patch of Coopersir in that email. The email is found in May'14 xen-=
devel but i am not more clear about migration v2.=0A=0ARegards,
---67152274-33507778-1417581577=:21228
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;fo=
nt-size:12px"><div style=3D"color: rgb(34, 34, 34); font-family: arial, san=
s-serif; font-size: 13px;" class=3D""><br class=3D"" style=3D"">Hope all wo=
uld be fine.<br class=3D"" style=3D""><br class=3D"" style=3D""></div><div =
style=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size:=
 13px;" class=3D"">I request you to guide my two issues for live migraiton:=
</div><div style=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif;=
 font-size: 13px;" class=3D"">1) Set up:&nbsp;<span style=3D"color: rgb(0, =
0, 0); font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Luc=
ida Grande', sans-serif; font-size: 12px;" class=3D"">I would like to migra=
te my existing system from xen4.1 to xen4.2+. I have been working with xen4=
.1.4+ DRBD for live migration.</span><div style=3D"color: rgb(0, 0, 0); fon=
t-family: HelveticaNeue,
 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size=
: 12px;" class=3D"">&nbsp;<br class=3D"" style=3D""></div><div style=3D"col=
or: rgb(0, 0, 0); font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, =
Arial, 'Lucida Grande', sans-serif; font-size: 12px;" class=3D"">I have mod=
ified kernel by comping linux and installed xen4.1.4 but now i want to migr=
ate to xen4.2+ so please give any idea.</div><div style=3D"color: rgb(0, 0,=
 0); font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucid=
a Grande', sans-serif; font-size: 12px;" class=3D""><br class=3D"" style=3D=
""></div><div style=3D"color: rgb(0, 0, 0); font-family: HelveticaNeue, 'He=
lvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12=
px;" class=3D"">new code of xen 4.2+ is downloaded and make world is done &=
nbsp;but at the time of migration, ssh connection port 22 error is given. i=
t also shows</div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica=
Neue, 'Helvetica
 Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12px;" cl=
ass=3D"">in grub two entries xenolder and xennewer.so is their xen(newer/ol=
der) conflict?</div><div style=3D"color: rgb(0, 0, 0); font-family: Helveti=
caNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; fo=
nt-size: 12px;" class=3D""><br class=3D"" style=3D""></div><div style=3D"co=
lor: rgb(0, 0, 0); font-family: HelveticaNeue, 'Helvetica Neue', Helvetica,=
 Arial, 'Lucida Grande', sans-serif; font-size: 12px;" class=3D""><br class=
=3D"" style=3D""></div><div style=3D"color: rgb(0, 0, 0); font-family: Helv=
eticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif;=
 font-size: 12px;" class=3D""><span style=3D"font-family: arial, sans-serif=
; font-size: 13px; color: rgb(34, 34, 34);" class=3D"">2) Algorithmic Part:=
</span><br class=3D"" style=3D""></div></div><div class=3D"" style=3D""><sp=
an style=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif; font-si=
ze: 13px;" class=3D"">I would
 like to work on Delta compression/Prediction technique for live migration =
using Xen. I have set up Xen Framework usign DRB D and completed load balan=
cing kind stuff. I used Xen4.1 for my experimental work which gives freedom=
 to work with xm and xl toolstacks.</span><span class=3D"" style=3D""><br s=
tyle=3D""></span></div><div class=3D"" style=3D"color: rgb(0, 0, 0); font-s=
ize: 12px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, =
'Lucida Grande', sans-serif; font-style: normal; background-color: transpar=
ent;"><span style=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif=
; font-size: 13px;" class=3D"">But compression code is available from xen4.=
2+. I am understanding data structures of xc_domain_save and xc_compression=
 using fossies (source code documentation) given in <a href=3D"http://fossi=
es.org/dox/xen-4.4.1/xc__domain__save_8c.html" class=3D"" style=3D"">http:/=
/fossies.org/dox/xen-4.4.1/xc__domain__save_8c.html</a>&nbsp;is there any o=
ther easy
 documentation because number of research papers are available but i didn't=
 understand the practical aspect from them.</span></div><div class=3D"" sty=
le=3D"color: rgb(34, 34, 34); font-size: 13px; font-family: arial, sans-ser=
if; font-style: normal; background-color: transparent;"><span style=3D"colo=
r: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px;" class=
=3D""><br class=3D"" style=3D""></span></div><div class=3D"" style=3D"color=
: rgb(34, 34, 34); font-size: 13px; font-family: arial, sans-serif; font-st=
yle: normal; background-color: transparent;">Iansir has requested me about =
migration v2 (to be proposed in xen6 written by Andrew Cooper) for live mig=
ration but i did not able to find any kind of patch of Coopersir in that em=
ail. The email is found in May'14 xen-devel but i am not more clear about m=
igration v2.</div><div class=3D"" style=3D"color: rgb(34, 34, 34); font-siz=
e: 13px; font-family: arial, sans-serif; font-style: normal; background-col=
or:
 transparent;"><br class=3D"" style=3D""></div><div class=3D"" style=3D"col=
or: rgb(34, 34, 34); font-size: 13px; font-family: arial, sans-serif; font-=
style: normal; background-color: transparent;">Regards,</div><div class=3D"=
" style=3D"color: rgb(34, 34, 34); font-size: 13px; font-family: arial, san=
s-serif; font-style: normal; background-color: transparent;"><br class=3D""=
 style=3D""></div><div class=3D"" style=3D""></div><div class=3D"" style=3D=
"">&nbsp;</div><div class=3D"" style=3D""><br class=3D"" style=3D""></div><=
/div></body></html>
---67152274-33507778-1417581577=:21228--


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

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

--===============7352228783540597115==--


From xen-devel-bounces@lists.xen.org Wed Dec 03 06:15:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 06: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 1Xw3D0-0001W2-VH; Wed, 03 Dec 2014 06:14:42 +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 1Xw3Cy-0001Vx-Rm
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 06:14:41 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	5F/D8-17735-F4AAE745; Wed, 03 Dec 2014 06:14:39 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417587276!12979307!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 5701 invoked from network); 3 Dec 2014 06:14:38 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 06:14:38 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 23:14:34 -0700
Message-Id: <547F44F5020000660004100F@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 23:14:29 -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>
	<5474B784020000660007D9AA@soto.provo.novell.com>
	<1417189409.23604.62.camel@citrix.com>
In-Reply-To: <1417189409.23604.62.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



>>> On 11/28/2014 at 11:43 PM, in message <1417189409.23604.62.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> 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.
  
The reason why I post such an overview here before sending next
version is: I'm puzzled about what should be in libxl and what
in toolstack after previous discussion. So posted here to seek
some ideas or agreement first. It's not a full design, not break
down to libxl and toolstack yet.

>  
> 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. 

About notification API, after looking at lvm, vhd-util and qcow2, 
I don't think we need it. No extra work needs to do to handle 
disk snapshot chain. 
lvm: doesn't support snapshot of snapshot. 
vhd-util: backing file chain, external snapshot. Don't need to 
          delete the disk snapshot when deleting domain snapshot. 
qcow2: 
* internal disk snapshot: each snapshot increases the refcount 
  of data, deleting snapshot only decrease the refcount, won't 
  affect other snapshots. 
* external disk snapshot: same as vhd-util, backing file chain. 
  Don't need to delete disk snapshot when deleting domain snapshot.

>  
> >  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.  
For saving memory, there is already API for that. The missing part is
taking disk snapshot.

>  
> 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. 

Like delete a disk snapshot, xl can call external command to do that
(e.g. qemu-img). But it's better to call qmp to do that.
Anyway, if for domain snapshot create, we should put creating disk
snapshot process in libxl, then for domain snapshot delete, we
should put deleting disk snapshot process in libxl. That is, in libxl
there should be:
libxl_disk_snapshot_create (which handles creating disk snapshot)
libxl_disk_snapshot_delete (which handles deleting disk snapshot)

Otherwise I would think it's weird to have in libxl:
libxl_domain_snapshot_create (wrap saving memory [already has API] 
                              and creating disk snapshot)
libxl_disk_snapshot_delete (deleting disk snapshot)

>  
> 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.
 
And about the snapshot json file store and retrieve, using
gentype.py to autogenerate xx_to_json and xx_from_json functions
is very convenient, there would be a group of functions
set/get/update/delete_snapshot_metadata based on that.
But I didn't see other such usage in xl, and it's not proper to 
place in libxl. Anywhere could it be placed but used by xl? 
Wei might have some ideas about this?

-Chunyan

> >  
> > 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 Wed Dec 03 06:15:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 06: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 1Xw3D0-0001W2-VH; Wed, 03 Dec 2014 06:14:42 +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 1Xw3Cy-0001Vx-Rm
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 06:14:41 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	5F/D8-17735-F4AAE745; Wed, 03 Dec 2014 06:14:39 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417587276!12979307!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 5701 invoked from network); 3 Dec 2014 06:14:38 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 06:14:38 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 23:14:34 -0700
Message-Id: <547F44F5020000660004100F@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 23:14:29 -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>
	<5474B784020000660007D9AA@soto.provo.novell.com>
	<1417189409.23604.62.camel@citrix.com>
In-Reply-To: <1417189409.23604.62.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



>>> On 11/28/2014 at 11:43 PM, in message <1417189409.23604.62.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> 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.
  
The reason why I post such an overview here before sending next
version is: I'm puzzled about what should be in libxl and what
in toolstack after previous discussion. So posted here to seek
some ideas or agreement first. It's not a full design, not break
down to libxl and toolstack yet.

>  
> 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. 

About notification API, after looking at lvm, vhd-util and qcow2, 
I don't think we need it. No extra work needs to do to handle 
disk snapshot chain. 
lvm: doesn't support snapshot of snapshot. 
vhd-util: backing file chain, external snapshot. Don't need to 
          delete the disk snapshot when deleting domain snapshot. 
qcow2: 
* internal disk snapshot: each snapshot increases the refcount 
  of data, deleting snapshot only decrease the refcount, won't 
  affect other snapshots. 
* external disk snapshot: same as vhd-util, backing file chain. 
  Don't need to delete disk snapshot when deleting domain snapshot.

>  
> >  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.  
For saving memory, there is already API for that. The missing part is
taking disk snapshot.

>  
> 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. 

Like delete a disk snapshot, xl can call external command to do that
(e.g. qemu-img). But it's better to call qmp to do that.
Anyway, if for domain snapshot create, we should put creating disk
snapshot process in libxl, then for domain snapshot delete, we
should put deleting disk snapshot process in libxl. That is, in libxl
there should be:
libxl_disk_snapshot_create (which handles creating disk snapshot)
libxl_disk_snapshot_delete (which handles deleting disk snapshot)

Otherwise I would think it's weird to have in libxl:
libxl_domain_snapshot_create (wrap saving memory [already has API] 
                              and creating disk snapshot)
libxl_disk_snapshot_delete (deleting disk snapshot)

>  
> 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.
 
And about the snapshot json file store and retrieve, using
gentype.py to autogenerate xx_to_json and xx_from_json functions
is very convenient, there would be a group of functions
set/get/update/delete_snapshot_metadata based on that.
But I didn't see other such usage in xl, and it's not proper to 
place in libxl. Anywhere could it be placed but used by xl? 
Wei might have some ideas about this?

-Chunyan

> >  
> > 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 Wed Dec 03 06:27:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 06:27:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw3Oz-0001kz-Hv; Wed, 03 Dec 2014 06:27:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1Xw3Ox-0001ku-Ia
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 06:27:03 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	80/D0-26652-63DAE745; Wed, 03 Dec 2014 06:27:02 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417588020!7847915!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31906 invoked from network); 3 Dec 2014 06:27:01 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Dec 2014 06:27:01 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 23:26:59 -0700
Message-Id: <547F47E0020000660004101C@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 23:26:56 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: <Ian.Campbell@citrix.com>
References: <547F479A0200006600041019@soto.provo.novell.com>
	<547F47E0020000660004101C@soto.provo.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>, wei.liu2@citrix.com,
	dunlapg@umich.edu, 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/28/2014 at 11:43 PM, in message <1417189409.23604.62.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> 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.
  
The reason why I post such an overview here before sending next
version is: I'm puzzled about what should be in libxl and what
in toolstack after previous discussion. So posted here to seek
some ideas or agreement first. It's not a full design, not break
down to libxl and toolstack yet.

>  
> 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. 

About notification API, after looking at lvm, vhd-util and qcow2, 
I don't think we need it. No extra work needs to do to handle 
disk snapshot chain. 
lvm: doesn't support snapshot of snapshot. 
vhd-util: backing file chain, external snapshot. Don't need to 
          delete the disk snapshot when deleting domain snapshot. 
qcow2: 
* internal disk snapshot: each snapshot increases the refcount 
  of data, deleting snapshot only decrease the refcount, won't 
  affect other snapshots. 
* external disk snapshot: same as vhd-util, backing file chain. 
  Don't need to delete disk snapshot when deleting domain snapshot.

>  
> >  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.  
For saving memory, there is already API for that. The missing part is
taking disk snapshot.

>  
> 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. 

Like delete a disk snapshot, xl can call external command to do that
(e.g. qemu-img). But it's better to call qmp to do that.
Anyway, if for domain snapshot create, we should put creating disk
snapshot process in libxl, then for domain snapshot delete, we
should put deleting disk snapshot process in libxl. That is, in libxl
there should be:
libxl_disk_snapshot_create (which handles creating disk snapshot)
libxl_disk_snapshot_delete (which handles deleting disk snapshot)

Otherwise I would think it's weird to have in libxl:
libxl_domain_snapshot_create (wrap saving memory [already has API] 
                              and creating disk snapshot)
libxl_disk_snapshot_delete (deleting disk snapshot)

>  
> 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.
 
And about the snapshot json file store and retrieve, using
gentype.py to autogenerate xx_to_json and xx_from_json functions
is very convenient, there would be a group of functions
set/get/update/delete_snapshot_metadata based on that.
But I didn't see other such usage in xl, and it's not proper to 
place in libxl. Anywhere could it be placed but used by xl? 
Wei might have some ideas about this?

-Chunyan

> >  
> > 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 Wed Dec 03 06:27:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 06:27:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw3Oz-0001kz-Hv; Wed, 03 Dec 2014 06:27:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cyliu@suse.com>) id 1Xw3Ox-0001ku-Ia
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 06:27:03 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	80/D0-26652-63DAE745; Wed, 03 Dec 2014 06:27:02 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417588020!7847915!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31906 invoked from network); 3 Dec 2014 06:27:01 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Dec 2014 06:27:01 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Tue, 02 Dec 2014 23:26:59 -0700
Message-Id: <547F47E0020000660004101C@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 02 Dec 2014 23:26:56 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: <Ian.Campbell@citrix.com>
References: <547F479A0200006600041019@soto.provo.novell.com>
	<547F47E0020000660004101C@soto.provo.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>, wei.liu2@citrix.com,
	dunlapg@umich.edu, 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/28/2014 at 11:43 PM, in message <1417189409.23604.62.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> 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.
  
The reason why I post such an overview here before sending next
version is: I'm puzzled about what should be in libxl and what
in toolstack after previous discussion. So posted here to seek
some ideas or agreement first. It's not a full design, not break
down to libxl and toolstack yet.

>  
> 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. 

About notification API, after looking at lvm, vhd-util and qcow2, 
I don't think we need it. No extra work needs to do to handle 
disk snapshot chain. 
lvm: doesn't support snapshot of snapshot. 
vhd-util: backing file chain, external snapshot. Don't need to 
          delete the disk snapshot when deleting domain snapshot. 
qcow2: 
* internal disk snapshot: each snapshot increases the refcount 
  of data, deleting snapshot only decrease the refcount, won't 
  affect other snapshots. 
* external disk snapshot: same as vhd-util, backing file chain. 
  Don't need to delete disk snapshot when deleting domain snapshot.

>  
> >  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.  
For saving memory, there is already API for that. The missing part is
taking disk snapshot.

>  
> 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. 

Like delete a disk snapshot, xl can call external command to do that
(e.g. qemu-img). But it's better to call qmp to do that.
Anyway, if for domain snapshot create, we should put creating disk
snapshot process in libxl, then for domain snapshot delete, we
should put deleting disk snapshot process in libxl. That is, in libxl
there should be:
libxl_disk_snapshot_create (which handles creating disk snapshot)
libxl_disk_snapshot_delete (which handles deleting disk snapshot)

Otherwise I would think it's weird to have in libxl:
libxl_domain_snapshot_create (wrap saving memory [already has API] 
                              and creating disk snapshot)
libxl_disk_snapshot_delete (deleting disk snapshot)

>  
> 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.
 
And about the snapshot json file store and retrieve, using
gentype.py to autogenerate xx_to_json and xx_from_json functions
is very convenient, there would be a group of functions
set/get/update/delete_snapshot_metadata based on that.
But I didn't see other such usage in xl, and it's not proper to 
place in libxl. Anywhere could it be placed but used by xl? 
Wei might have some ideas about this?

-Chunyan

> >  
> > 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 Wed Dec 03 06:59:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 06: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 1Xw3uH-0002Fb-Eh; Wed, 03 Dec 2014 06:59:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1Xw3uG-0002FW-E1
	for Xen-devel@lists.xen.org; Wed, 03 Dec 2014 06:59:24 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	9C/21-17694-BC4BE745; Wed, 03 Dec 2014 06:59:23 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417589962!15295581!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 14221 invoked from network); 3 Dec 2014 06:59:23 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-31.messagelabs.com with SMTP;
	3 Dec 2014 06:59:23 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 02 Dec 2014 22:59:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,506,1413270000"; d="scan'208";a="641716508"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by fmsmga002.fm.intel.com with ESMTP; 02 Dec 2014 22:59:18 -0800
Message-ID: <547EB47F.4060004@linux.intel.com>
Date: Wed, 03 Dec 2014 14:58:07 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.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: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547D6C86.4090400@linux.intel.com>
	<20141202114016.GD69236@deinos.phlegethon.org>
In-Reply-To: <20141202114016.GD69236@deinos.phlegethon.org>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/2/2014 7:40 PM, Tim Deegan wrote:
> At 15:38 +0800 on 02 Dec (1417531126), Yu, Zhang wrote:
>> On 12/1/2014 8:13 PM, Tim Deegan wrote:
>>> At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>>>>>>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>>>>> During this bit of archaeology I realised that either this new type
>>>>> should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
>>>>> class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
>>>>> for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
>>>>> just p2m_ram_ro and p2m_grant_map_ro.
>>>>
>>>> And I suppose in that latter case the new type could be made part
>>>> of P2M_RO_TYPES()?
>>>
>>> Yes indeed, as P2M_RO_TYPES is defined as "must have the _PAGE_RW bit
>>> clear in their PTEs".
>>>
>>
>> Thanks Tim.
>> Following are my understanding of the P2M_RO_TYPES and your comments.
>> Not sure if I get it right. Please correct me if anything wrong:
>> 1> The P2M_RO_TYPES now bears 2 meanings: one is "w bit is clear in the
>> pte"; and another being to discard the write operations;
>> 2> We better define another class to bear the second meaning.
>
> Yes, that's what I meant.
>
> Answering your other questions in reverse order:
>
>> 2> p2m_grant_map_ro is also supposed to be discarded? Will handling of
>> this type of pages goes into __hvm_copy()/__hvm_clear(), or should?
>
> I think so, yes.  At the moment we inject #GP when the guest writes to
> a read-only grant, which is OK: the guest really ought to know better.
> But I think we'll probably end up with neater code if we handle
> read-only grants the same way as p2m_ram_ro.
>
> Anyone else have an opinion on the right thing to do here?
>
>> Also some questions for the new p2m class, say P2M_DISCARD_WRITE_TYPES,
>> and the new predicates, say p2m_is_discard_write:
>> 1> You mentioned emulate_gva_to_mfn() and __hvm_copy() should discard
>> the write ops, yet I also noticed many other places using the
>> p2m_is_readonly, or only the "p2mt == p2m_ram_ro" judgement(in
>> __hvm_copy/__hvm_clear). Among all these other places, is there any ones
>> also supposed to use the p2m_is_discard_write?
>
> I've just had a look through them all, and I can see exactly four
> places that should be using the new p2m_is_discard_write() test:
>
>   - emulate_gva_to_mfn() (Though in fact it's a no-op as shadow-mode
>     guests never have p2m_ram_shared or p2m_ram_logdirty mappings.)
>   - __hvm_copy()
>   - __hvm_clear() and
>   - hvm_hap_nested_page_fault() (where you should also remove the
>     explicit handling of p2m_grant_map_ro below.)
>
Thank you, Tim & Jan.
To give a summary for all the comments:

1> new p2m type p2m_mmio_write_dm is to be added;
2> new p2m type need to be added to P2M_RO_TYPES class;
3> new p2m class, say P2M_DISCARD_WRITE_TYPES(which only include 
p2m_ram_ro and p2m_grant_map_ro), and the new predicates, say 
p2m_is_discard_write are needed to in these 4 places to discard the 
write op;
4> and of cause hvm_hap_nested_page_fault() do not need the special 
handling for p2m_grant_map_ro anymore;
5> coding style changes pointed out by Jan
6> clear the commit message

I'll prepare the patch and thanks! :)

Yu

> Looking through that turned up a few other oddities, which I'm
> listing here to remind myself to look at them later (i.e. you don't
> need to worry about them for this patch):
>
>   - nsvm_get_nvmcb_page() and nestedhap_walk_L0_p2m() need to handle
>     p2m_ram_logdirty or they might spuriously fail duiring live
>     migration.
>   - __hvm_copy() and __hvm_clear are probably over-strict in their
>     failure to handle grant types.
>   - P2M_UNMAP_TYPES in vmce.c is a mess.  It's not the right place to
>     define this, since it definitely won't be seen my anyone
>     adding a new type, and it already has an 'XXX' comment that says
>     it doesn't cover a lot of cases. :(
>
> I'll have a look at those another time.
>
> Cheers,
>
> Tim.
>
>

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 06:59:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 06: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 1Xw3uH-0002Fb-Eh; Wed, 03 Dec 2014 06:59:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1Xw3uG-0002FW-E1
	for Xen-devel@lists.xen.org; Wed, 03 Dec 2014 06:59:24 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	9C/21-17694-BC4BE745; Wed, 03 Dec 2014 06:59:23 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417589962!15295581!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 14221 invoked from network); 3 Dec 2014 06:59:23 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-31.messagelabs.com with SMTP;
	3 Dec 2014 06:59:23 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 02 Dec 2014 22:59:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,506,1413270000"; d="scan'208";a="641716508"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by fmsmga002.fm.intel.com with ESMTP; 02 Dec 2014 22:59:18 -0800
Message-ID: <547EB47F.4060004@linux.intel.com>
Date: Wed, 03 Dec 2014 14:58:07 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.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: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547D6C86.4090400@linux.intel.com>
	<20141202114016.GD69236@deinos.phlegethon.org>
In-Reply-To: <20141202114016.GD69236@deinos.phlegethon.org>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/2/2014 7:40 PM, Tim Deegan wrote:
> At 15:38 +0800 on 02 Dec (1417531126), Yu, Zhang wrote:
>> On 12/1/2014 8:13 PM, Tim Deegan wrote:
>>> At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>>>>>>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>>>>> During this bit of archaeology I realised that either this new type
>>>>> should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
>>>>> class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
>>>>> for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
>>>>> just p2m_ram_ro and p2m_grant_map_ro.
>>>>
>>>> And I suppose in that latter case the new type could be made part
>>>> of P2M_RO_TYPES()?
>>>
>>> Yes indeed, as P2M_RO_TYPES is defined as "must have the _PAGE_RW bit
>>> clear in their PTEs".
>>>
>>
>> Thanks Tim.
>> Following are my understanding of the P2M_RO_TYPES and your comments.
>> Not sure if I get it right. Please correct me if anything wrong:
>> 1> The P2M_RO_TYPES now bears 2 meanings: one is "w bit is clear in the
>> pte"; and another being to discard the write operations;
>> 2> We better define another class to bear the second meaning.
>
> Yes, that's what I meant.
>
> Answering your other questions in reverse order:
>
>> 2> p2m_grant_map_ro is also supposed to be discarded? Will handling of
>> this type of pages goes into __hvm_copy()/__hvm_clear(), or should?
>
> I think so, yes.  At the moment we inject #GP when the guest writes to
> a read-only grant, which is OK: the guest really ought to know better.
> But I think we'll probably end up with neater code if we handle
> read-only grants the same way as p2m_ram_ro.
>
> Anyone else have an opinion on the right thing to do here?
>
>> Also some questions for the new p2m class, say P2M_DISCARD_WRITE_TYPES,
>> and the new predicates, say p2m_is_discard_write:
>> 1> You mentioned emulate_gva_to_mfn() and __hvm_copy() should discard
>> the write ops, yet I also noticed many other places using the
>> p2m_is_readonly, or only the "p2mt == p2m_ram_ro" judgement(in
>> __hvm_copy/__hvm_clear). Among all these other places, is there any ones
>> also supposed to use the p2m_is_discard_write?
>
> I've just had a look through them all, and I can see exactly four
> places that should be using the new p2m_is_discard_write() test:
>
>   - emulate_gva_to_mfn() (Though in fact it's a no-op as shadow-mode
>     guests never have p2m_ram_shared or p2m_ram_logdirty mappings.)
>   - __hvm_copy()
>   - __hvm_clear() and
>   - hvm_hap_nested_page_fault() (where you should also remove the
>     explicit handling of p2m_grant_map_ro below.)
>
Thank you, Tim & Jan.
To give a summary for all the comments:

1> new p2m type p2m_mmio_write_dm is to be added;
2> new p2m type need to be added to P2M_RO_TYPES class;
3> new p2m class, say P2M_DISCARD_WRITE_TYPES(which only include 
p2m_ram_ro and p2m_grant_map_ro), and the new predicates, say 
p2m_is_discard_write are needed to in these 4 places to discard the 
write op;
4> and of cause hvm_hap_nested_page_fault() do not need the special 
handling for p2m_grant_map_ro anymore;
5> coding style changes pointed out by Jan
6> clear the commit message

I'll prepare the patch and thanks! :)

Yu

> Looking through that turned up a few other oddities, which I'm
> listing here to remind myself to look at them later (i.e. you don't
> need to worry about them for this patch):
>
>   - nsvm_get_nvmcb_page() and nestedhap_walk_L0_p2m() need to handle
>     p2m_ram_logdirty or they might spuriously fail duiring live
>     migration.
>   - __hvm_copy() and __hvm_clear are probably over-strict in their
>     failure to handle grant types.
>   - P2M_UNMAP_TYPES in vmce.c is a mess.  It's not the right place to
>     define this, since it definitely won't be seen my anyone
>     adding a new type, and it already has an 'XXX' comment that says
>     it doesn't cover a lot of cases. :(
>
> I'll have a look at those another time.
>
> Cheers,
>
> Tim.
>
>

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 08:37:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 08:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw5QJ-0004Q2-Pm; Wed, 03 Dec 2014 08:36:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xw5QI-0004Px-1Z
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 08:36:34 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	37/A4-05632-19BCE745; Wed, 03 Dec 2014 08:36:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417595792!11723612!1
X-Originating-IP: [81.169.146.163]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21498 invoked from network); 3 Dec 2014 08:36:32 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 08:36:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417595792; l=752;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=kWafP/dVGTgT+A+HvevY8xKouQI=;
	b=B6NauCt/bvw0DwWE3bhp8IPWlqa7kyisaLmX0O0cMNV8sewfY0fse1iEjNEziua7sEC
	XhpnwQBkzs8kfcZQf+XzTuo6ZGovrMKN/91PqyU2//4qJBs8HyERj6hy2PH9CGk0JGQFX
	gotU/CbLpPsS10p/NpaXWP+vbr+KpWbm8zI=
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.2 AUTH) with ESMTPSA id a00a98qB38aTy5i
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 09:36:29 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A2CF35016D; Wed,  3 Dec 2014 09:36:28 +0100 (CET)
Date: Wed, 3 Dec 2014 09:36:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141203083628.GA11508@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
	<20141202154652.GA26732@aepfle.de>
	<20141202183920.GG32385@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202183920.GG32385@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Konrad Rzeszutek Wilk wrote:

> On Tue, Dec 02, 2014 at 04:46:52PM +0100, Olaf Hering wrote:
> > On Mon, Dec 01, Konrad Rzeszutek Wilk wrote:
> > 
> > > That is odd - I see any device 'hot-plugged' being added at 00:05 and further.
> > 
> > Does this by any chance depend on the guest?! I mean, how is the guest
> 
> I doubt it.

Something is different here, likely just the non-pvops guest kernel.

> > notified that a PCI device is gone (by unplug)? Maybe the pvops case
> > just happens to work because the unplug happens early, perhaps before
> > PCI discovery?!
> 
> ACPI hotplug. And it does work after PCI discovery.

In a pvops kernel, is the emulated but unplugged PCI hardware still listed with lspci?

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 08:37:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 08:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw5QJ-0004Q2-Pm; Wed, 03 Dec 2014 08:36:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xw5QI-0004Px-1Z
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 08:36:34 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	37/A4-05632-19BCE745; Wed, 03 Dec 2014 08:36:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417595792!11723612!1
X-Originating-IP: [81.169.146.163]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21498 invoked from network); 3 Dec 2014 08:36:32 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 08:36:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417595792; l=752;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=kWafP/dVGTgT+A+HvevY8xKouQI=;
	b=B6NauCt/bvw0DwWE3bhp8IPWlqa7kyisaLmX0O0cMNV8sewfY0fse1iEjNEziua7sEC
	XhpnwQBkzs8kfcZQf+XzTuo6ZGovrMKN/91PqyU2//4qJBs8HyERj6hy2PH9CGk0JGQFX
	gotU/CbLpPsS10p/NpaXWP+vbr+KpWbm8zI=
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.2 AUTH) with ESMTPSA id a00a98qB38aTy5i
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 09:36:29 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A2CF35016D; Wed,  3 Dec 2014 09:36:28 +0100 (CET)
Date: Wed, 3 Dec 2014 09:36:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141203083628.GA11508@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
	<20141202154652.GA26732@aepfle.de>
	<20141202183920.GG32385@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202183920.GG32385@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Konrad Rzeszutek Wilk wrote:

> On Tue, Dec 02, 2014 at 04:46:52PM +0100, Olaf Hering wrote:
> > On Mon, Dec 01, Konrad Rzeszutek Wilk wrote:
> > 
> > > That is odd - I see any device 'hot-plugged' being added at 00:05 and further.
> > 
> > Does this by any chance depend on the guest?! I mean, how is the guest
> 
> I doubt it.

Something is different here, likely just the non-pvops guest kernel.

> > notified that a PCI device is gone (by unplug)? Maybe the pvops case
> > just happens to work because the unplug happens early, perhaps before
> > PCI discovery?!
> 
> ACPI hotplug. And it does work after PCI discovery.

In a pvops kernel, is the emulated but unplugged PCI hardware still listed with lspci?

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 08:53:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 08:53:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw5fw-0004hL-BK; Wed, 03 Dec 2014 08:52:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xw5fu-0004hE-JG
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 08:52:42 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	B6/80-09284-95FCE745; Wed, 03 Dec 2014 08:52:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417596761!15401744!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 21845 invoked from network); 3 Dec 2014 08:52:41 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 08:52:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417596761; l=548;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=iF3zaNIuXuKpHcI1BcKo/7zQSsI=;
	b=iyAvGOVPpNl2Zy/J/zBjRGoGY/iujEDlUyDkv2k+UTNqBvNRosnh/qU9ijbUdnRfb6e
	9dYWJoq7N0UcyDr6tvy53X4qbdUwhJQhpgVlPisKdp9BECWVwXQF0JCjGaetKdC2cnQUR
	Qxc3MFtj7TP6TTA+HjVu1hlvIl+Wq3boMZI=
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.2 AUTH) with ESMTPSA id U020f3qB38qbwCj
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 09:52:37 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id DB3705016D; Wed,  3 Dec 2014 09:52:36 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Wed,  3 Dec 2014 09:52:34 +0100
Message-Id: <1417596754-14063-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] INSTALL: fix typo in xendomains.service name
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
 INSTALL | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/INSTALL b/INSTALL
index 0bc67ea..71dd0eb 100644
--- a/INSTALL
+++ b/INSTALL
@@ -284,7 +284,7 @@ systemctl enable xen-init-dom0.service
 systemctl enable xenconsoled.service
 
 Other optional services are:
-systemctl enable xen-domains.service
+systemctl enable xendomains.service
 systemctl enable xen-watchdog.service
 
 

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 08:53:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 08:53:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw5fw-0004hL-BK; Wed, 03 Dec 2014 08:52:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xw5fu-0004hE-JG
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 08:52:42 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	B6/80-09284-95FCE745; Wed, 03 Dec 2014 08:52:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417596761!15401744!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 21845 invoked from network); 3 Dec 2014 08:52:41 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 08:52:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417596761; l=548;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=iF3zaNIuXuKpHcI1BcKo/7zQSsI=;
	b=iyAvGOVPpNl2Zy/J/zBjRGoGY/iujEDlUyDkv2k+UTNqBvNRosnh/qU9ijbUdnRfb6e
	9dYWJoq7N0UcyDr6tvy53X4qbdUwhJQhpgVlPisKdp9BECWVwXQF0JCjGaetKdC2cnQUR
	Qxc3MFtj7TP6TTA+HjVu1hlvIl+Wq3boMZI=
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.2 AUTH) with ESMTPSA id U020f3qB38qbwCj
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 09:52:37 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id DB3705016D; Wed,  3 Dec 2014 09:52:36 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Wed,  3 Dec 2014 09:52:34 +0100
Message-Id: <1417596754-14063-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] INSTALL: fix typo in xendomains.service name
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
 INSTALL | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/INSTALL b/INSTALL
index 0bc67ea..71dd0eb 100644
--- a/INSTALL
+++ b/INSTALL
@@ -284,7 +284,7 @@ systemctl enable xen-init-dom0.service
 systemctl enable xenconsoled.service
 
 Other optional services are:
-systemctl enable xen-domains.service
+systemctl enable xendomains.service
 systemctl enable xen-watchdog.service
 
 

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 09:39:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 09:39:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw6Od-0005kf-Dr; Wed, 03 Dec 2014 09:38: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 1Xw6Oc-0005kY-RN
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 09:38:54 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	87/A4-02953-E2ADE745; Wed, 03 Dec 2014 09:38:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417599532!12571765!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 17707 invoked from network); 3 Dec 2014 09:38:53 -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;
	3 Dec 2014 09:38:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,506,1413244800"; d="scan'208";a="198981789"
Message-ID: <1417599529.29004.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 3 Dec 2014 09:38:49 +0000
In-Reply-To: <20141202210941.GA1593@laptop.dumpdata.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
	<1417175443.23604.18.camel@citrix.com>
	<20141202210941.GA1593@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, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	tim@xen.org, 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 Tue, 2014-12-02 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 28, 2014 at 11:50:43AM +0000, Ian Campbell wrote:
> > 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...
> 
> Jan acked it.

For 4.5?

Have you release acked it?

This seemed like 4.6 material to me, or at least I've not seen any
mention/argument to the contrary.

Ian.

> > 
> > > ---
> > >  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



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

From xen-devel-bounces@lists.xen.org Wed Dec 03 09:39:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 09:39:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw6Od-0005kf-Dr; Wed, 03 Dec 2014 09:38: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 1Xw6Oc-0005kY-RN
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 09:38:54 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	87/A4-02953-E2ADE745; Wed, 03 Dec 2014 09:38:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417599532!12571765!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 17707 invoked from network); 3 Dec 2014 09:38:53 -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;
	3 Dec 2014 09:38:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,506,1413244800"; d="scan'208";a="198981789"
Message-ID: <1417599529.29004.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 3 Dec 2014 09:38:49 +0000
In-Reply-To: <20141202210941.GA1593@laptop.dumpdata.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
	<1417175443.23604.18.camel@citrix.com>
	<20141202210941.GA1593@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, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	tim@xen.org, 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 Tue, 2014-12-02 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 28, 2014 at 11:50:43AM +0000, Ian Campbell wrote:
> > 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...
> 
> Jan acked it.

For 4.5?

Have you release acked it?

This seemed like 4.6 material to me, or at least I've not seen any
mention/argument to the contrary.

Ian.

> > 
> > > ---
> > >  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



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

From xen-devel-bounces@lists.xen.org Wed Dec 03 09:52:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 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 1Xw6b0-0006BK-Mq; Wed, 03 Dec 2014 09:51:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xw6az-0006BF-IO
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 09:51:41 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	14/E5-25727-C2DDE745; Wed, 03 Dec 2014 09:51:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417600298!7035984!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 5074 invoked from network); 3 Dec 2014 09:51:40 -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;
	3 Dec 2014 09:51:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="198989836"
Message-ID: <1417600295.11243.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 3 Dec 2014 09:51:35 +0000
In-Reply-To: <547E08A2.2030608@citrix.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<1417433473-17272-2-git-send-email-wei.liu2@citrix.com>
	<547E08A2.2030608@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>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 1/2] libxl: un-constify return
 value of libxl_basename
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-02 at 18:44 +0000, Andrew Cooper wrote:
> On 01/12/14 11:31, Wei Liu wrote:
> > The string returned is malloc'ed but marked as "const".
> >
> > 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.h       |   10 ++++++++++
> >  tools/libxl/libxl_utils.c |    5 ++++-
> >  tools/libxl/libxl_utils.h |    6 +++++-
> >  3 files changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index 41d6e8d..291c190 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -478,6 +478,16 @@ typedef struct libxl__ctx libxl_ctx;
> >  #endif
> >  
> >  /*
> > + * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> > + *
> > + * The return value of libxl_basename is malloc'ed but the erroneously
> > + * marked as "const" in releases before 4.5.
> > + */
> > +#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
> > +#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
> > +#endif
> 
> This define is currently useless.  Only newer code is capable of making
> use of newly introduced LIBXL_HAVE_$FOO flags, and with its current
> arrangement, this flag is only exposed to code requesting an older API
> version.
> 
> This instead needs to be LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
> which should be 1 for any API version >= 4.5

Oops, yes. Wei, can you send an incremental fixup please?

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 09:52:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 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 1Xw6b0-0006BK-Mq; Wed, 03 Dec 2014 09:51:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xw6az-0006BF-IO
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 09:51:41 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	14/E5-25727-C2DDE745; Wed, 03 Dec 2014 09:51:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417600298!7035984!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 5074 invoked from network); 3 Dec 2014 09:51:40 -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;
	3 Dec 2014 09:51:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="198989836"
Message-ID: <1417600295.11243.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed, 3 Dec 2014 09:51:35 +0000
In-Reply-To: <547E08A2.2030608@citrix.com>
References: <1417433473-17272-1-git-send-email-wei.liu2@citrix.com>
	<1417433473-17272-2-git-send-email-wei.liu2@citrix.com>
	<547E08A2.2030608@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>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for-4.5 1/2] libxl: un-constify return
 value of libxl_basename
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-02 at 18:44 +0000, Andrew Cooper wrote:
> On 01/12/14 11:31, Wei Liu wrote:
> > The string returned is malloc'ed but marked as "const".
> >
> > 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.h       |   10 ++++++++++
> >  tools/libxl/libxl_utils.c |    5 ++++-
> >  tools/libxl/libxl_utils.h |    6 +++++-
> >  3 files changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index 41d6e8d..291c190 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -478,6 +478,16 @@ typedef struct libxl__ctx libxl_ctx;
> >  #endif
> >  
> >  /*
> > + * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> > + *
> > + * The return value of libxl_basename is malloc'ed but the erroneously
> > + * marked as "const" in releases before 4.5.
> > + */
> > +#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
> > +#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
> > +#endif
> 
> This define is currently useless.  Only newer code is capable of making
> use of newly introduced LIBXL_HAVE_$FOO flags, and with its current
> arrangement, this flag is only exposed to code requesting an older API
> version.
> 
> This instead needs to be LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
> which should be 1 for any API version >= 4.5

Oops, yes. Wei, can you send an incremental fixup please?

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 09:53:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 09:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw6cI-0006JT-5D; Wed, 03 Dec 2014 09:53: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 1Xw6cG-0006JH-Gy
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 09:53:00 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	4F/C0-02953-A7DDE745; Wed, 03 Dec 2014 09:52:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417600376!8018710!1
X-Originating-IP: [81.169.146.163]
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 15774 invoked from network); 3 Dec 2014 09:52:56 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 09:52:56 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417600376; l=1012;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=YVxl8ZwZOd4sUC71Hzy9BQS4asw=;
	b=k5cwWYs6Z+/mZJL3X3LIPx3Ye4rpvI9fQxTGlnvU0Qg4fHs3zACP1GHBfZy5VZ6K7Am
	uxt3wXhzwHXxpLjVn1FIDr1AFoP9/ymT2XJ3wShn5PkXQyxyTufcCLim9x67d4vsny4YN
	yjbql2sklIlAzFXgFp4PPHPNsRqwmxd9DHQ=
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.2 AUTH) with ESMTPSA id c034d8qB39qq5wM
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 10:52:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 7455E5016D; Wed,  3 Dec 2014 10:52:52 +0100 (CET)
Date: Wed, 3 Dec 2014 10:52:52 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20141203095252.GA25950@aepfle.de>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Olaf Hering wrote:

> Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
> systemd xenstored dependencies") all service files use the .socket unit
> as startup dependency. While this happens to work for boot it fails for
> shutdown because a .socket does not seem to enforce ordering. When
> xendomains.service runs during shutdown then systemd will stop
> xenstored.service at the same time.
> 
> Change all "xenstored.socket" to "xenstored.service" to let systemd know
> that xenstored has to be shutdown after everything else.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.com>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>

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

I was able to reproduce the hang on shutdown with openSUSE 13.1. This
patch fixes the hang.

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 09:53:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 09:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw6cI-0006JT-5D; Wed, 03 Dec 2014 09:53: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 1Xw6cG-0006JH-Gy
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 09:53:00 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	4F/C0-02953-A7DDE745; Wed, 03 Dec 2014 09:52:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417600376!8018710!1
X-Originating-IP: [81.169.146.163]
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 15774 invoked from network); 3 Dec 2014 09:52:56 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 09:52:56 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417600376; l=1012;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=YVxl8ZwZOd4sUC71Hzy9BQS4asw=;
	b=k5cwWYs6Z+/mZJL3X3LIPx3Ye4rpvI9fQxTGlnvU0Qg4fHs3zACP1GHBfZy5VZ6K7Am
	uxt3wXhzwHXxpLjVn1FIDr1AFoP9/ymT2XJ3wShn5PkXQyxyTufcCLim9x67d4vsny4YN
	yjbql2sklIlAzFXgFp4PPHPNsRqwmxd9DHQ=
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.2 AUTH) with ESMTPSA id c034d8qB39qq5wM
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 10:52:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 7455E5016D; Wed,  3 Dec 2014 10:52:52 +0100 (CET)
Date: Wed, 3 Dec 2014 10:52:52 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20141203095252.GA25950@aepfle.de>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Olaf Hering wrote:

> Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
> systemd xenstored dependencies") all service files use the .socket unit
> as startup dependency. While this happens to work for boot it fails for
> shutdown because a .socket does not seem to enforce ordering. When
> xendomains.service runs during shutdown then systemd will stop
> xenstored.service at the same time.
> 
> Change all "xenstored.socket" to "xenstored.service" to let systemd know
> that xenstored has to be shutdown after everything else.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.com>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>

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

I was able to reproduce the hang on shutdown with openSUSE 13.1. This
patch fixes the hang.

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 09:53:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 09: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 1Xw6dB-0006P2-Jj; Wed, 03 Dec 2014 09:53:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xw6dA-0006Og-2Q
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 09:53:56 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	55/51-31453-3BDDE745; Wed, 03 Dec 2014 09:53:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417600433!11241915!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25849 invoked from network); 3 Dec 2014 09:53:54 -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;
	3 Dec 2014 09:53:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199328798"
Message-ID: <1417600430.11243.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ed Swierk <eswierk@skyportsystems.com>
Date: Wed, 3 Dec 2014 09:53:50 +0000
In-Reply-To: <CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com> <547DC617.8020107@citrix.com>
	<CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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-12-02 at 09:49 -0800, Ed Swierk wrote:
> On Tue, Dec 2, 2014 at 6:00 AM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > The automatically generating doesn't actually work.  Depending on the
> > relative timestamps caused by a SCM checkout, or a tarball extraction,
> > the files will be attempted to be regenerated.
> >
> > These files are regenerated in the XenServer build, simply because of
> > their order in the archived tarball.
> 
> When I clone the xen tree from git, the timestamps match about 95% of
> the time, but the 5% failure rate was annoying enough that I finally
> dug in to fix the parser build.
> 
> IMHO the generated files should be omitted from the source tree; as
> long as the source files are actually buildable, there's no reason not
> to treat them like any other source file.

There was a point in time where the prevailing version of bison (or
maybe flex) in stable distro releases had a bug which meant these files
could not be regenerated easily on common distros. I don't recall the
details well enough to know if that time has now passed. Perhaps Ian J
does.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 09:53:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 09: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 1Xw6dB-0006P2-Jj; Wed, 03 Dec 2014 09:53:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xw6dA-0006Og-2Q
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 09:53:56 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	55/51-31453-3BDDE745; Wed, 03 Dec 2014 09:53:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417600433!11241915!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25849 invoked from network); 3 Dec 2014 09:53:54 -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;
	3 Dec 2014 09:53:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199328798"
Message-ID: <1417600430.11243.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ed Swierk <eswierk@skyportsystems.com>
Date: Wed, 3 Dec 2014 09:53:50 +0000
In-Reply-To: <CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com> <547DC617.8020107@citrix.com>
	<CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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-12-02 at 09:49 -0800, Ed Swierk wrote:
> On Tue, Dec 2, 2014 at 6:00 AM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > The automatically generating doesn't actually work.  Depending on the
> > relative timestamps caused by a SCM checkout, or a tarball extraction,
> > the files will be attempted to be regenerated.
> >
> > These files are regenerated in the XenServer build, simply because of
> > their order in the archived tarball.
> 
> When I clone the xen tree from git, the timestamps match about 95% of
> the time, but the 5% failure rate was annoying enough that I finally
> dug in to fix the parser build.
> 
> IMHO the generated files should be omitted from the source tree; as
> long as the source files are actually buildable, there's no reason not
> to treat them like any other source file.

There was a point in time where the prevailing version of bison (or
maybe flex) in stable distro releases had a bug which meant these files
could not be regenerated easily on common distros. I don't recall the
details well enough to know if that time has now passed. Perhaps Ian J
does.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:01:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10: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 1Xw6kI-0006pN-UM; Wed, 03 Dec 2014 10:01:18 +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 1Xw6kH-0006pF-7S
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 10:01:17 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	DF/0B-14727-C6FDE745; Wed, 03 Dec 2014 10:01:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417600875!3660313!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10426 invoked from network); 3 Dec 2014 10:01:15 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 10:01:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417600875; l=613;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=hWsyIPW/I/c/+L2XeobQXkVHP78=;
	b=dE9sA5OrHu9rlYmmcgoLUnf6REppaMeDjwLiIonQm3ARCRYZbDvxxzEPds+TRLGaMxB
	5t6+O4vsuOZAWZ1LELCDSsOa07DpgNCUdBxpyxqqTbczqeLM/e//34mF7TV4qKsgXxOJD
	OyIx0CRSe/+6T76dFN2CtvmDleX4ZZskXE8=
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.2 AUTH) with ESMTPSA id u005e3qB3A1EuU9
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 11:01:14 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 1436F5016D; Wed,  3 Dec 2014 11:01:13 +0100 (CET)
Date: Wed, 3 Dec 2014 11:01:13 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141203100113.GA26895@aepfle.de>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com>
	<547DC617.8020107@citrix.com>
	<CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
	<1417600430.11243.1.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417600430.11243.1.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ed Swierk <eswierk@skyportsystems.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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, Dec 03, Ian Campbell wrote:

> There was a point in time where the prevailing version of bison (or
> maybe flex) in stable distro releases had a bug which meant these files
> could not be regenerated easily on common distros. I don't recall the
> details well enough to know if that time has now passed. Perhaps Ian J
> does.

Its very easy to build a private bison/flex/whatever and use this
instead of one from the system. Our configure can easily detect a broken
version and refuse to compile.  After all we dont ship .i or .s files
because some compilers happen to optimize better.

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:01:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10: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 1Xw6kI-0006pN-UM; Wed, 03 Dec 2014 10:01:18 +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 1Xw6kH-0006pF-7S
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 10:01:17 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	DF/0B-14727-C6FDE745; Wed, 03 Dec 2014 10:01:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417600875!3660313!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10426 invoked from network); 3 Dec 2014 10:01:15 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 10:01:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417600875; l=613;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=hWsyIPW/I/c/+L2XeobQXkVHP78=;
	b=dE9sA5OrHu9rlYmmcgoLUnf6REppaMeDjwLiIonQm3ARCRYZbDvxxzEPds+TRLGaMxB
	5t6+O4vsuOZAWZ1LELCDSsOa07DpgNCUdBxpyxqqTbczqeLM/e//34mF7TV4qKsgXxOJD
	OyIx0CRSe/+6T76dFN2CtvmDleX4ZZskXE8=
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.2 AUTH) with ESMTPSA id u005e3qB3A1EuU9
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 11:01:14 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 1436F5016D; Wed,  3 Dec 2014 11:01:13 +0100 (CET)
Date: Wed, 3 Dec 2014 11:01:13 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141203100113.GA26895@aepfle.de>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com>
	<547DC617.8020107@citrix.com>
	<CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
	<1417600430.11243.1.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417600430.11243.1.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ed Swierk <eswierk@skyportsystems.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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, Dec 03, Ian Campbell wrote:

> There was a point in time where the prevailing version of bison (or
> maybe flex) in stable distro releases had a bug which meant these files
> could not be regenerated easily on common distros. I don't recall the
> details well enough to know if that time has now passed. Perhaps Ian J
> does.

Its very easy to build a private bison/flex/whatever and use this
instead of one from the system. Our configure can easily detect a broken
version and refuse to compile.  After all we dont ship .i or .s files
because some compilers happen to optimize better.

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:27:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10: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 1Xw78w-0007GO-5v; Wed, 03 Dec 2014 10: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 1Xw78u-0007GH-FM
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:26:44 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	8A/4A-17735-365EE745; Wed, 03 Dec 2014 10:26:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417602403!10787442!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19811 invoked from network); 3 Dec 2014 10:26:43 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 10:26:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417602402; l=937;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=fH19paw85eLDyIYJ3a8ClyBeeos=;
	b=ihMkLjv69HV/vhiH3i1YEfhkEDra+KZ9O9jRq0ppE1/oOTbYwJgvZVg2h0VLjATV0Kv
	+mStVL1b3zW14H11MfjXmNU5lqnnh9DK7Vazw6QkJg87RvYbtBH3DCkRmiUKSNPwNsrAy
	dM0FlBiAZXdsPV0jAdHh+tbrI2czglPTHeE=
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.2 AUTH) with ESMTPSA id Q06535qB3AQawD2
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 11:26:36 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 853EA5016D; Wed,  3 Dec 2014 11:26:36 +0100 (CET)
Date: Wed, 3 Dec 2014 11:26:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141203102636.GA29307@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202183755.GF32385@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Konrad Rzeszutek Wilk wrote:

> On Tue, Dec 02, 2014 at 03:11:30PM +0000, Wei Liu wrote:
> > AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> > incorrect, even in the event systemd library is available.  Use
> > PKG_CHECK_MODULES instead.
> > 
> > Tested on Debian Jessie and Arch Linux.
> 
> And Fedora and SuSE? CC-ing the other distro maintainers
> for their input.

I'm fine with that. But:

It seems be that sd_listen_fds() is new in v209. It was backported to
v208 in openSUSE 13.1. So there should be some detection if
sd_listen_fds() is really available. Looks like this patch removes the
check.

I get this from pkg-config:

root@optiplex:/work/olaf/13.1/github/olafhering/xen.git # pkg-config --cflags libsystemd-daemon ; echo $?

0
root@optiplex:/work/olaf/13.1/github/olafhering/xen.git # pkg-config --libs libsystemd-daemon ; echo $?
-lsystemd-daemon 
0

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:27:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10: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 1Xw78w-0007GO-5v; Wed, 03 Dec 2014 10: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 1Xw78u-0007GH-FM
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:26:44 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	8A/4A-17735-365EE745; Wed, 03 Dec 2014 10:26:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417602403!10787442!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19811 invoked from network); 3 Dec 2014 10:26:43 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 10:26:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417602402; l=937;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=fH19paw85eLDyIYJ3a8ClyBeeos=;
	b=ihMkLjv69HV/vhiH3i1YEfhkEDra+KZ9O9jRq0ppE1/oOTbYwJgvZVg2h0VLjATV0Kv
	+mStVL1b3zW14H11MfjXmNU5lqnnh9DK7Vazw6QkJg87RvYbtBH3DCkRmiUKSNPwNsrAy
	dM0FlBiAZXdsPV0jAdHh+tbrI2czglPTHeE=
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.2 AUTH) with ESMTPSA id Q06535qB3AQawD2
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 11:26:36 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 853EA5016D; Wed,  3 Dec 2014 11:26:36 +0100 (CET)
Date: Wed, 3 Dec 2014 11:26:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141203102636.GA29307@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202183755.GF32385@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Konrad Rzeszutek Wilk wrote:

> On Tue, Dec 02, 2014 at 03:11:30PM +0000, Wei Liu wrote:
> > AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> > incorrect, even in the event systemd library is available.  Use
> > PKG_CHECK_MODULES instead.
> > 
> > Tested on Debian Jessie and Arch Linux.
> 
> And Fedora and SuSE? CC-ing the other distro maintainers
> for their input.

I'm fine with that. But:

It seems be that sd_listen_fds() is new in v209. It was backported to
v208 in openSUSE 13.1. So there should be some detection if
sd_listen_fds() is really available. Looks like this patch removes the
check.

I get this from pkg-config:

root@optiplex:/work/olaf/13.1/github/olafhering/xen.git # pkg-config --cflags libsystemd-daemon ; echo $?

0
root@optiplex:/work/olaf/13.1/github/olafhering/xen.git # pkg-config --libs libsystemd-daemon ; echo $?
-lsystemd-daemon 
0

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:29:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10: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 1Xw7BC-0007Pf-PT; Wed, 03 Dec 2014 10:29: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 1Xw7BB-0007PZ-Fw
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:29:05 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	58/AD-02699-0F5EE745; Wed, 03 Dec 2014 10:29:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417602542!12644664!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 12184 invoked from network); 3 Dec 2014 10:29:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 10:29:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199003846"
Message-ID: <1417602539.11243.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 3 Dec 2014 10:28:59 +0000
In-Reply-To: <20141203102636.GA29307@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-03 at 11:26 +0100, Olaf Hering wrote:
> On Tue, Dec 02, Konrad Rzeszutek Wilk wrote:
> 
> > On Tue, Dec 02, 2014 at 03:11:30PM +0000, Wei Liu wrote:
> > > AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> > > incorrect, even in the event systemd library is available.  Use
> > > PKG_CHECK_MODULES instead.
> > > 
> > > Tested on Debian Jessie and Arch Linux.
> > 
> > And Fedora and SuSE? CC-ing the other distro maintainers
> > for their input.
> 
> I'm fine with that. But:
> 
> It seems be that sd_listen_fds() is new in v209. It was backported to
> v208 in openSUSE 13.1. So there should be some detection if
> sd_listen_fds() is really available. Looks like this patch removes the
> check.

Ah I didn't know about the sd_listen_fds thing, so I think that what we
need then is to use pkg-config first to determine if systemd-daemon is
present at all, and then check for specific symbols we require using the
pkg-config supplied CFLAGS and LDFLAGS rather than assuming
-lsystemd-daemon.

Ian.

> 
> I get this from pkg-config:
> 
> root@optiplex:/work/olaf/13.1/github/olafhering/xen.git # pkg-config --cflags libsystemd-daemon ; echo $?
> 
> 0
> root@optiplex:/work/olaf/13.1/github/olafhering/xen.git # pkg-config --libs libsystemd-daemon ; echo $?
> -lsystemd-daemon 
> 0
> 
> Olaf



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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:29:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10: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 1Xw7BC-0007Pf-PT; Wed, 03 Dec 2014 10:29: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 1Xw7BB-0007PZ-Fw
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:29:05 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	58/AD-02699-0F5EE745; Wed, 03 Dec 2014 10:29:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417602542!12644664!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 12184 invoked from network); 3 Dec 2014 10:29:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 10:29:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199003846"
Message-ID: <1417602539.11243.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 3 Dec 2014 10:28:59 +0000
In-Reply-To: <20141203102636.GA29307@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-03 at 11:26 +0100, Olaf Hering wrote:
> On Tue, Dec 02, Konrad Rzeszutek Wilk wrote:
> 
> > On Tue, Dec 02, 2014 at 03:11:30PM +0000, Wei Liu wrote:
> > > AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> > > incorrect, even in the event systemd library is available.  Use
> > > PKG_CHECK_MODULES instead.
> > > 
> > > Tested on Debian Jessie and Arch Linux.
> > 
> > And Fedora and SuSE? CC-ing the other distro maintainers
> > for their input.
> 
> I'm fine with that. But:
> 
> It seems be that sd_listen_fds() is new in v209. It was backported to
> v208 in openSUSE 13.1. So there should be some detection if
> sd_listen_fds() is really available. Looks like this patch removes the
> check.

Ah I didn't know about the sd_listen_fds thing, so I think that what we
need then is to use pkg-config first to determine if systemd-daemon is
present at all, and then check for specific symbols we require using the
pkg-config supplied CFLAGS and LDFLAGS rather than assuming
-lsystemd-daemon.

Ian.

> 
> I get this from pkg-config:
> 
> root@optiplex:/work/olaf/13.1/github/olafhering/xen.git # pkg-config --cflags libsystemd-daemon ; echo $?
> 
> 0
> root@optiplex:/work/olaf/13.1/github/olafhering/xen.git # pkg-config --libs libsystemd-daemon ; echo $?
> -lsystemd-daemon 
> 0
> 
> Olaf



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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:37:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10:37:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw7JS-0007eb-Ox; Wed, 03 Dec 2014 10:37:38 +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 1Xw7JR-0007eW-5e
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:37:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6E/B2-15461-0F7EE745; Wed, 03 Dec 2014 10:37:36 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417603055!13066428!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=2.9 required=7.0 tests=HTML_60_70,
	HTML_IMAGE_ONLY_12,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20286 invoked from network); 3 Dec 2014 10:37:35 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 10:37:35 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so19574796wgh.16
	for <xen-devel@lists.xen.org>; Wed, 03 Dec 2014 02:37:35 -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=X6XevGO38CYaPZNuc6Fqkoh/1qt/QEpapLYAeGG0clg=;
	b=hJ7gMK9RNYXCnmDZFm7OVYleM+9gw2eK6CHg5RcY907+k+oM6lbd/ME+ZghrjpZ3Dm
	3j5bScX687hdxtHwB1+gm/kQJ9Vlu0aG5NvBmLW5cV06U0NVZk8Rs7f9OKw1P20PQ4mx
	mgJSbUjNaqfpfnTc7DQG0gHOvUO+Oemjqy2mGZIrs3y2/Vano1Q0+AJAWxeU5sS7xG9/
	GwpzneGj66ztOoh7qXWQKF3iDFG3FoVYChEKCu1CpwC/l8e5MiSrebOz6Y2tuw/Acum3
	UuL+EFmtZVfT6muUz0lYaTMFNn30wF86tirwob/LaA315iBxtzLgZ7rRoJv/7pvf7w6r
	g/XQ==
MIME-Version: 1.0
X-Received: by 10.194.249.232 with SMTP id yx8mr6370715wjc.1.1417603055541;
	Wed, 03 Dec 2014 02:37:35 -0800 (PST)
Received: by 10.194.44.2 with HTTP; Wed, 3 Dec 2014 02:37:35 -0800 (PST)
In-Reply-To: <CAE9jt3-MmniP=DdOqtjmE3TmnhGW=qrdtV0uwnL49-FZMm2nMQ@mail.gmail.com>
References: <CAE9jt3-MmniP=DdOqtjmE3TmnhGW=qrdtV0uwnL49-FZMm2nMQ@mail.gmail.com>
Date: Wed, 3 Dec 2014 10:37:35 +0000
X-Google-Sender-Auth: E0BbZb65hGAt-7RDurpAnDUjhDY
Message-ID: <CAFLBxZaR_Rq-gOJrRs99z-cVp2UZDf=av2FMS4cM09DrskYR_Q@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: leon zawodowiec <vianom@gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Time dilation in XEN 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4327939558481742066=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4327939558481742066==
Content-Type: multipart/alternative; boundary=001a11c2a3168ee4f505094d6ec6

--001a11c2a3168ee4f505094d6ec6
Content-Type: text/plain; charset=UTF-8

On Mon, Dec 1, 2014 at 8:10 PM, leon zawodowiec <vianom@gmail.com> wrote:

> Hello, is it possible to implement time dilation in XEN 4.2 without
> modyfing kernel(also hints are welcome)? Thank you for replies.
>

I don't think anyone knows what you're talking about.

It might be helpful if you read this document and then try asking your
question again with a bit more detail:

wiki.xenproject.org/wiki/Asking_Developer_Questions

 -George

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

<div dir=3D"ltr">On Mon, Dec 1, 2014 at 8:10 PM, leon zawodowiec <span dir=
=3D"ltr">&lt;<a href=3D"mailto:vianom@gmail.com" target=3D"_blank">vianom@g=
mail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr">Hello, is it possible to implement time dilation in XEN 4.2 without mo=
dyfing kernel(also hints are welcome)? Thank you for replies.<img src=3D"ht=
tp://t.signaledue.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v4LN9-W2=
zqh2z3N1NYTVdD-D81pctGFW5wMh8b1k1H6H0?si=3D6102418673106944&amp;pi=3De0d109=
d5-af93-43e1-c1cd-574eeb41a0d1" width=3D"1" height=3D"1"></div></blockquote=
><div><br></div><div>I don&#39;t think anyone knows what you&#39;re talking=
 about.<br><br></div><div>It might be helpful if you read this document and=
 then try asking your question again with a bit more detail:<br><br><a href=
=3D"http://wiki.xenproject.org/wiki/Asking_Developer_Questions">wiki.xenpro=
ject.org/wiki/Asking_Developer_Questions</a>=C2=A0 <br><br></div><div>=C2=
=A0-George<br></div></div></div></div>

--001a11c2a3168ee4f505094d6ec6--


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

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

--===============4327939558481742066==--


From xen-devel-bounces@lists.xen.org Wed Dec 03 10:37:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10:37:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw7JS-0007eb-Ox; Wed, 03 Dec 2014 10:37:38 +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 1Xw7JR-0007eW-5e
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:37:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6E/B2-15461-0F7EE745; Wed, 03 Dec 2014 10:37:36 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417603055!13066428!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=2.9 required=7.0 tests=HTML_60_70,
	HTML_IMAGE_ONLY_12,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20286 invoked from network); 3 Dec 2014 10:37:35 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 10:37:35 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so19574796wgh.16
	for <xen-devel@lists.xen.org>; Wed, 03 Dec 2014 02:37:35 -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=X6XevGO38CYaPZNuc6Fqkoh/1qt/QEpapLYAeGG0clg=;
	b=hJ7gMK9RNYXCnmDZFm7OVYleM+9gw2eK6CHg5RcY907+k+oM6lbd/ME+ZghrjpZ3Dm
	3j5bScX687hdxtHwB1+gm/kQJ9Vlu0aG5NvBmLW5cV06U0NVZk8Rs7f9OKw1P20PQ4mx
	mgJSbUjNaqfpfnTc7DQG0gHOvUO+Oemjqy2mGZIrs3y2/Vano1Q0+AJAWxeU5sS7xG9/
	GwpzneGj66ztOoh7qXWQKF3iDFG3FoVYChEKCu1CpwC/l8e5MiSrebOz6Y2tuw/Acum3
	UuL+EFmtZVfT6muUz0lYaTMFNn30wF86tirwob/LaA315iBxtzLgZ7rRoJv/7pvf7w6r
	g/XQ==
MIME-Version: 1.0
X-Received: by 10.194.249.232 with SMTP id yx8mr6370715wjc.1.1417603055541;
	Wed, 03 Dec 2014 02:37:35 -0800 (PST)
Received: by 10.194.44.2 with HTTP; Wed, 3 Dec 2014 02:37:35 -0800 (PST)
In-Reply-To: <CAE9jt3-MmniP=DdOqtjmE3TmnhGW=qrdtV0uwnL49-FZMm2nMQ@mail.gmail.com>
References: <CAE9jt3-MmniP=DdOqtjmE3TmnhGW=qrdtV0uwnL49-FZMm2nMQ@mail.gmail.com>
Date: Wed, 3 Dec 2014 10:37:35 +0000
X-Google-Sender-Auth: E0BbZb65hGAt-7RDurpAnDUjhDY
Message-ID: <CAFLBxZaR_Rq-gOJrRs99z-cVp2UZDf=av2FMS4cM09DrskYR_Q@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: leon zawodowiec <vianom@gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Time dilation in XEN 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4327939558481742066=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4327939558481742066==
Content-Type: multipart/alternative; boundary=001a11c2a3168ee4f505094d6ec6

--001a11c2a3168ee4f505094d6ec6
Content-Type: text/plain; charset=UTF-8

On Mon, Dec 1, 2014 at 8:10 PM, leon zawodowiec <vianom@gmail.com> wrote:

> Hello, is it possible to implement time dilation in XEN 4.2 without
> modyfing kernel(also hints are welcome)? Thank you for replies.
>

I don't think anyone knows what you're talking about.

It might be helpful if you read this document and then try asking your
question again with a bit more detail:

wiki.xenproject.org/wiki/Asking_Developer_Questions

 -George

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

<div dir=3D"ltr">On Mon, Dec 1, 2014 at 8:10 PM, leon zawodowiec <span dir=
=3D"ltr">&lt;<a href=3D"mailto:vianom@gmail.com" target=3D"_blank">vianom@g=
mail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr">Hello, is it possible to implement time dilation in XEN 4.2 without mo=
dyfing kernel(also hints are welcome)? Thank you for replies.<img src=3D"ht=
tp://t.signaledue.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v4LN9-W2=
zqh2z3N1NYTVdD-D81pctGFW5wMh8b1k1H6H0?si=3D6102418673106944&amp;pi=3De0d109=
d5-af93-43e1-c1cd-574eeb41a0d1" width=3D"1" height=3D"1"></div></blockquote=
><div><br></div><div>I don&#39;t think anyone knows what you&#39;re talking=
 about.<br><br></div><div>It might be helpful if you read this document and=
 then try asking your question again with a bit more detail:<br><br><a href=
=3D"http://wiki.xenproject.org/wiki/Asking_Developer_Questions">wiki.xenpro=
ject.org/wiki/Asking_Developer_Questions</a>=C2=A0 <br><br></div><div>=C2=
=A0-George<br></div></div></div></div>

--001a11c2a3168ee4f505094d6ec6--


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

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

--===============4327939558481742066==--


From xen-devel-bounces@lists.xen.org Wed Dec 03 10:41:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10:41:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw7NP-0007rv-Dz; Wed, 03 Dec 2014 10:41: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 1Xw7NN-0007rp-RU
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:41:41 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	83/6C-08051-5E8EE745; Wed, 03 Dec 2014 10:41:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417603299!12691708!1
X-Originating-IP: [66.165.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 7064 invoked from network); 3 Dec 2014 10:41:40 -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;
	3 Dec 2014 10:41:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199006913"
Received: from ukmail1.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, 3 Dec 2014 05:41:38 -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 1Xw7NK-0006XT-BC;
	Wed, 03 Dec 2014 10:41:38 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 3 Dec 2014 10:41:38 +0000
Message-ID: <1417603298-4213-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>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl: expose #define to 4.5 and above
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 e3abab74 (libxl: un-constify return value of libxl_basename), the
macro was exposed to releases < 4.5. However only new code is able to
make use of that macro so it should be exposed to releases >= 4.5.

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: Andrew Cooper <andrew.cooper3@citrix.com>
---
 tools/libxl/libxl.h       |    6 +++---
 tools/libxl/libxl_utils.c |    2 +-
 tools/libxl/libxl_utils.h |    2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 291c190..0a123f1 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -478,13 +478,13 @@ typedef struct libxl__ctx libxl_ctx;
 #endif
 
 /*
- * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
+ * LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
  *
  * The return value of libxl_basename is malloc'ed but the erroneously
  * marked as "const" in releases before 4.5.
  */
-#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
-#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
+#if !defined(LIBXL_API_VERSION) || LIBXL_API_VERSION >= 0x040500
+#define LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE 1
 #endif
 
 /*
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 22119fc..7095b58 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -19,7 +19,7 @@
 
 #include "libxl_internal.h"
 
-#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
+#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
 const
 #endif
 char *libxl_basename(const char *name)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 8277eb9..acacdd9 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -18,7 +18,7 @@
 
 #include "libxl.h"
 
-#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
+#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
 const
 #endif
 char *libxl_basename(const char *name); /* returns string from strdup */
-- 
1.7.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 Dec 03 10:41:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10:41:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw7NP-0007rv-Dz; Wed, 03 Dec 2014 10:41: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 1Xw7NN-0007rp-RU
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:41:41 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	83/6C-08051-5E8EE745; Wed, 03 Dec 2014 10:41:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417603299!12691708!1
X-Originating-IP: [66.165.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 7064 invoked from network); 3 Dec 2014 10:41:40 -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;
	3 Dec 2014 10:41:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199006913"
Received: from ukmail1.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, 3 Dec 2014 05:41:38 -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 1Xw7NK-0006XT-BC;
	Wed, 03 Dec 2014 10:41:38 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 3 Dec 2014 10:41:38 +0000
Message-ID: <1417603298-4213-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>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl: expose #define to 4.5 and above
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 e3abab74 (libxl: un-constify return value of libxl_basename), the
macro was exposed to releases < 4.5. However only new code is able to
make use of that macro so it should be exposed to releases >= 4.5.

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: Andrew Cooper <andrew.cooper3@citrix.com>
---
 tools/libxl/libxl.h       |    6 +++---
 tools/libxl/libxl_utils.c |    2 +-
 tools/libxl/libxl_utils.h |    2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 291c190..0a123f1 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -478,13 +478,13 @@ typedef struct libxl__ctx libxl_ctx;
 #endif
 
 /*
- * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
+ * LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
  *
  * The return value of libxl_basename is malloc'ed but the erroneously
  * marked as "const" in releases before 4.5.
  */
-#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
-#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
+#if !defined(LIBXL_API_VERSION) || LIBXL_API_VERSION >= 0x040500
+#define LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE 1
 #endif
 
 /*
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 22119fc..7095b58 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -19,7 +19,7 @@
 
 #include "libxl_internal.h"
 
-#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
+#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
 const
 #endif
 char *libxl_basename(const char *name)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 8277eb9..acacdd9 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -18,7 +18,7 @@
 
 #include "libxl.h"
 
-#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
+#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
 const
 #endif
 char *libxl_basename(const char *name); /* returns string from strdup */
-- 
1.7.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 Dec 03 10:49:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10:49:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw7Up-00087R-Aw; Wed, 03 Dec 2014 10:49:23 +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 1Xw7Um-00087M-SO
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:49:21 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	6F/7D-08051-0BAEE745; Wed, 03 Dec 2014 10:49:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417603759!12682171!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31857 invoked from network); 3 Dec 2014 10:49:19 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 10:49:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417603759; l=493;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=dmoxTq6+D27kN2ZXOKTorQe1C9M=;
	b=fVLPC+35YKSwzt2ap0vy8INlYdjnT4l4Oi3K6NTuaG5nMGUN1t9DUePj3tGnkePE3B4
	Swt4V4Ya6bWgyamdLe22GkR2OD3mo4FFfC3ljo0wLR1yAjSx46CiQT/YlEDLez5eUw6IT
	5fFsqkcLaRsrIKo04J5x9XItsxlGrAiLKuQ=
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.2 AUTH) with ESMTPSA id z04c12qB3AnD0Ds
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 11:49:13 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id D53F35016D; Wed,  3 Dec 2014 11:49:12 +0100 (CET)
Date: Wed, 3 Dec 2014 11:49:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141203104912.GA30431@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
	<1417602539.11243.4.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417602539.11243.4.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, Ian Campbell wrote:

> Ah I didn't know about the sd_listen_fds thing, so I think that what we
> need then is to use pkg-config first to determine if systemd-daemon is
> present at all, and then check for specific symbols we require using the
> pkg-config supplied CFLAGS and LDFLAGS rather than assuming
> -lsystemd-daemon.

Correction: sd_listen_fds is available since at least v1.
 git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d
 v1~390

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:49:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10:49:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw7Up-00087R-Aw; Wed, 03 Dec 2014 10:49:23 +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 1Xw7Um-00087M-SO
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:49:21 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	6F/7D-08051-0BAEE745; Wed, 03 Dec 2014 10:49:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417603759!12682171!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31857 invoked from network); 3 Dec 2014 10:49:19 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 10:49:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417603759; l=493;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=dmoxTq6+D27kN2ZXOKTorQe1C9M=;
	b=fVLPC+35YKSwzt2ap0vy8INlYdjnT4l4Oi3K6NTuaG5nMGUN1t9DUePj3tGnkePE3B4
	Swt4V4Ya6bWgyamdLe22GkR2OD3mo4FFfC3ljo0wLR1yAjSx46CiQT/YlEDLez5eUw6IT
	5fFsqkcLaRsrIKo04J5x9XItsxlGrAiLKuQ=
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.2 AUTH) with ESMTPSA id z04c12qB3AnD0Ds
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 11:49:13 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id D53F35016D; Wed,  3 Dec 2014 11:49:12 +0100 (CET)
Date: Wed, 3 Dec 2014 11:49:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141203104912.GA30431@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
	<1417602539.11243.4.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417602539.11243.4.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, Ian Campbell wrote:

> Ah I didn't know about the sd_listen_fds thing, so I think that what we
> need then is to use pkg-config first to determine if systemd-daemon is
> present at all, and then check for specific symbols we require using the
> pkg-config supplied CFLAGS and LDFLAGS rather than assuming
> -lsystemd-daemon.

Correction: sd_listen_fds is available since at least v1.
 git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d
 v1~390

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:51:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw7Wa-0008Cd-Ql; Wed, 03 Dec 2014 10:51: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 1Xw7Wa-0008CY-8W
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:51:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F0/CC-15461-F1BEE745; Wed, 03 Dec 2014 10:51:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417603869!13068833!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8009 invoked from network); 3 Dec 2014 10:51:10 -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;
	3 Dec 2014 10:51:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199346139"
Message-ID: <1417603834.11243.9.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: Wed, 3 Dec 2014 10:50:34 +0000
In-Reply-To: <1417603298-4213-1-git-send-email-wei.liu2@citrix.com>
References: <1417603298-4213-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: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: expose #define to 4.5 and
	above
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-03 at 10:41 +0000, Wei Liu wrote:
> In e3abab74 (libxl: un-constify return value of libxl_basename), the
> macro was exposed to releases < 4.5. However only new code is able to
> make use of that macro so it should be exposed to releases >= 4.5.
> 
> 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: Andrew Cooper <andrew.cooper3@citrix.com>

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

Konrad, given that the original patch is in 4.5 (as of yesterday) we
should obviously take this one too.

> ---
>  tools/libxl/libxl.h       |    6 +++---
>  tools/libxl/libxl_utils.c |    2 +-
>  tools/libxl/libxl_utils.h |    2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 291c190..0a123f1 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -478,13 +478,13 @@ typedef struct libxl__ctx libxl_ctx;
>  #endif
>  
>  /*
> - * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> + * LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
>   *
>   * The return value of libxl_basename is malloc'ed but the erroneously
>   * marked as "const" in releases before 4.5.
>   */
> -#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
> -#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
> +#if !defined(LIBXL_API_VERSION) || LIBXL_API_VERSION >= 0x040500
> +#define LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE 1
>  #endif
>  
>  /*
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 22119fc..7095b58 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -19,7 +19,7 @@
>  
>  #include "libxl_internal.h"
>  
> -#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> +#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
>  const
>  #endif
>  char *libxl_basename(const char *name)
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> index 8277eb9..acacdd9 100644
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -18,7 +18,7 @@
>  
>  #include "libxl.h"
>  
> -#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> +#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
>  const
>  #endif
>  char *libxl_basename(const char *name); /* returns string from strdup */



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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:51:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw7Wa-0008Cd-Ql; Wed, 03 Dec 2014 10:51: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 1Xw7Wa-0008CY-8W
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:51:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F0/CC-15461-F1BEE745; Wed, 03 Dec 2014 10:51:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417603869!13068833!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8009 invoked from network); 3 Dec 2014 10:51:10 -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;
	3 Dec 2014 10:51:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199346139"
Message-ID: <1417603834.11243.9.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: Wed, 3 Dec 2014 10:50:34 +0000
In-Reply-To: <1417603298-4213-1-git-send-email-wei.liu2@citrix.com>
References: <1417603298-4213-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: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: expose #define to 4.5 and
	above
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-03 at 10:41 +0000, Wei Liu wrote:
> In e3abab74 (libxl: un-constify return value of libxl_basename), the
> macro was exposed to releases < 4.5. However only new code is able to
> make use of that macro so it should be exposed to releases >= 4.5.
> 
> 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: Andrew Cooper <andrew.cooper3@citrix.com>

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

Konrad, given that the original patch is in 4.5 (as of yesterday) we
should obviously take this one too.

> ---
>  tools/libxl/libxl.h       |    6 +++---
>  tools/libxl/libxl_utils.c |    2 +-
>  tools/libxl/libxl_utils.h |    2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 291c190..0a123f1 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -478,13 +478,13 @@ typedef struct libxl__ctx libxl_ctx;
>  #endif
>  
>  /*
> - * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> + * LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
>   *
>   * The return value of libxl_basename is malloc'ed but the erroneously
>   * marked as "const" in releases before 4.5.
>   */
> -#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
> -#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
> +#if !defined(LIBXL_API_VERSION) || LIBXL_API_VERSION >= 0x040500
> +#define LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE 1
>  #endif
>  
>  /*
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 22119fc..7095b58 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -19,7 +19,7 @@
>  
>  #include "libxl_internal.h"
>  
> -#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> +#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
>  const
>  #endif
>  char *libxl_basename(const char *name)
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> index 8277eb9..acacdd9 100644
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -18,7 +18,7 @@
>  
>  #include "libxl.h"
>  
> -#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> +#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
>  const
>  #endif
>  char *libxl_basename(const char *name); /* returns string from strdup */



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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:51:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10: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 1Xw7Wf-0008Dc-6X; Wed, 03 Dec 2014 10:51: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 1Xw7Wd-0008DF-KU
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:51:15 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	5C/15-27623-22BEE745; Wed, 03 Dec 2014 10:51:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417603872!10782815!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 2456 invoked from network); 3 Dec 2014 10:51:14 -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;
	3 Dec 2014 10:51:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199009308"
Message-ID: <1417603870.11243.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 3 Dec 2014 10:51:10 +0000
In-Reply-To: <20141203104912.GA30431@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
	<1417602539.11243.4.camel@citrix.com>
	<20141203104912.GA30431@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-03 at 11:49 +0100, Olaf Hering wrote:
> On Wed, Dec 03, Ian Campbell wrote:
> 
> > Ah I didn't know about the sd_listen_fds thing, so I think that what we
> > need then is to use pkg-config first to determine if systemd-daemon is
> > present at all, and then check for specific symbols we require using the
> > pkg-config supplied CFLAGS and LDFLAGS rather than assuming
> > -lsystemd-daemon.
> 
> Correction: sd_listen_fds is available since at least v1.
>  git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d
>  v1~390

In that case I don't think we realistically need to check 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 Wed Dec 03 10:51:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10: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 1Xw7Wf-0008Dc-6X; Wed, 03 Dec 2014 10:51: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 1Xw7Wd-0008DF-KU
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:51:15 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	5C/15-27623-22BEE745; Wed, 03 Dec 2014 10:51:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417603872!10782815!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 2456 invoked from network); 3 Dec 2014 10:51:14 -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;
	3 Dec 2014 10:51:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199009308"
Message-ID: <1417603870.11243.10.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 3 Dec 2014 10:51:10 +0000
In-Reply-To: <20141203104912.GA30431@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
	<1417602539.11243.4.camel@citrix.com>
	<20141203104912.GA30431@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-03 at 11:49 +0100, Olaf Hering wrote:
> On Wed, Dec 03, Ian Campbell wrote:
> 
> > Ah I didn't know about the sd_listen_fds thing, so I think that what we
> > need then is to use pkg-config first to determine if systemd-daemon is
> > present at all, and then check for specific symbols we require using the
> > pkg-config supplied CFLAGS and LDFLAGS rather than assuming
> > -lsystemd-daemon.
> 
> Correction: sd_listen_fds is available since at least v1.
>  git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d
>  v1~390

In that case I don't think we realistically need to check 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 Wed Dec 03 10:55:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10:55:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw7aI-0000AV-3B; Wed, 03 Dec 2014 10:55:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xw7aH-0000AQ-MQ
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 10:55:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5A/54-15461-50CEE745; Wed, 03 Dec 2014 10:55:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417604099!13115953!1
X-Originating-IP: [66.165.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 3338 invoked from network); 3 Dec 2014 10:55:00 -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 Dec 2014 10:55:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199346954"
Received: from ukmail1.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, 3 Dec 2014 05:54: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 1Xw7aE-0006sJ-5x;
	Wed, 03 Dec 2014 10:54:58 +0000
Date: Wed, 3 Dec 2014 10:54:58 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Don Slutz <dslutz@verizon.com>
Message-ID: <20141203105458.GA4208@zion.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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
	<547E1FC1.70004@terremark.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547E1FC1.70004@terremark.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
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 Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote:
[...]
> >>>>           hw_error("xc_domain_getinfo failed");
> >>>>       }
> >>>>-    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;
> >>>>+    real_free = free_pages;
> >>>>+    if (free_pages > VGA_HOLE_SIZE) {
> >>>>+        free_pages -= VGA_HOLE_SIZE;
> >>>>+    } else {
> >>>>+        free_pages = 0;
> >>>>+    }
> >I don't think we need to subtract VGA_HOLE_SIZE.
> 
> If you do not use some slack (like 32 here), xen does report:
> 
> 
> (d5) [2014-11-29 17:07:21] Loaded SeaBIOS
> (d5) [2014-11-29 17:07:21] Creating MP tables ...
> (d5) [2014-11-29 17:07:21] Loading ACPI ...
> (XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for domain
> 5: 1057417 > 1057416
> (XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0

This message is a bit red herring.

It's hvmloader trying to populate ram for firmware data. The actual
amount of extra pages needed depends on the firmware.

In any case it's safe to disallow hvmloader from doing so, it will just
relocate some pages from ram (hence shrinking *mem_end).

> extent: id=5 memflags=0 (0 of 1)
> (d5) [2014-11-29 17:07:21] vm86 TSS at 00098c00
> (d5) [2014-11-29 17:07:21] BIOS map:
> 
> 
> However while QEMU startup ends with 32 "free" pages (maxmem - curmem)
> this quickly changes to 23.  I.E. there are 7 more places that act like a
> call
> to xc_domain_populate_physmap_exact() but do not log errors if there is
> no free pages.  And just to make sure I do not fully understand what is
> happening here, after the message above, the domain appears to work
> fine and ends up with 8 "free" pages (code I do not know about ends up
> releasing populated pages).
> 
> So my current thinking is to have QEMU leave a few (9 to 32 (64?)) pages
> "free".
> 

Unless we know before hand how many pages hvmloader needs this number is
estimation at best.

Wei.

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:55:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10:55:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw7aI-0000AV-3B; Wed, 03 Dec 2014 10:55:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xw7aH-0000AQ-MQ
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 10:55:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5A/54-15461-50CEE745; Wed, 03 Dec 2014 10:55:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417604099!13115953!1
X-Originating-IP: [66.165.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 3338 invoked from network); 3 Dec 2014 10:55:00 -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 Dec 2014 10:55:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199346954"
Received: from ukmail1.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, 3 Dec 2014 05:54: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 1Xw7aE-0006sJ-5x;
	Wed, 03 Dec 2014 10:54:58 +0000
Date: Wed, 3 Dec 2014 10:54:58 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Don Slutz <dslutz@verizon.com>
Message-ID: <20141203105458.GA4208@zion.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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
	<547E1FC1.70004@terremark.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547E1FC1.70004@terremark.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
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 Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote:
[...]
> >>>>           hw_error("xc_domain_getinfo failed");
> >>>>       }
> >>>>-    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;
> >>>>+    real_free = free_pages;
> >>>>+    if (free_pages > VGA_HOLE_SIZE) {
> >>>>+        free_pages -= VGA_HOLE_SIZE;
> >>>>+    } else {
> >>>>+        free_pages = 0;
> >>>>+    }
> >I don't think we need to subtract VGA_HOLE_SIZE.
> 
> If you do not use some slack (like 32 here), xen does report:
> 
> 
> (d5) [2014-11-29 17:07:21] Loaded SeaBIOS
> (d5) [2014-11-29 17:07:21] Creating MP tables ...
> (d5) [2014-11-29 17:07:21] Loading ACPI ...
> (XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for domain
> 5: 1057417 > 1057416
> (XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0

This message is a bit red herring.

It's hvmloader trying to populate ram for firmware data. The actual
amount of extra pages needed depends on the firmware.

In any case it's safe to disallow hvmloader from doing so, it will just
relocate some pages from ram (hence shrinking *mem_end).

> extent: id=5 memflags=0 (0 of 1)
> (d5) [2014-11-29 17:07:21] vm86 TSS at 00098c00
> (d5) [2014-11-29 17:07:21] BIOS map:
> 
> 
> However while QEMU startup ends with 32 "free" pages (maxmem - curmem)
> this quickly changes to 23.  I.E. there are 7 more places that act like a
> call
> to xc_domain_populate_physmap_exact() but do not log errors if there is
> no free pages.  And just to make sure I do not fully understand what is
> happening here, after the message above, the domain appears to work
> fine and ends up with 8 "free" pages (code I do not know about ends up
> releasing populated pages).
> 
> So my current thinking is to have QEMU leave a few (9 to 32 (64?)) pages
> "free".
> 

Unless we know before hand how many pages hvmloader needs this number is
estimation at best.

Wei.

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:55:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10: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 1Xw7am-0000DF-Fz; Wed, 03 Dec 2014 10:55:32 +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 1Xw7al-0000D8-GG
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:55:31 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	39/1B-03148-22CEE745; Wed, 03 Dec 2014 10:55:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417604130!12694425!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15987 invoked from network); 3 Dec 2014 10:55:30 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 10:55:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417604130; l=796;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=4gU4BFOxOHP8kfNbCtQnRiV1nEg=;
	b=EDoetbmXABQpd8j/H9DZE2mNNS1zCElFNusUDh8WJ6AG25/8mC5p//hswEi/9AjZxPz
	tiax97LyvZb6ivgQQMVA/fDZfAfDGppSUrzf+A8Ku2SGBFPd9zJce1PUPeDUONPfHamzg
	z7h7Xwlig9FaIQtBzkvkSRqE36TaYcJF1Ow=
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.2 AUTH) with ESMTPSA id L0210bqB3AtNzv2
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 11:55:23 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 069E35016D; Wed,  3 Dec 2014 11:55:22 +0100 (CET)
Date: Wed, 3 Dec 2014 11:55:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141203105522.GA32341@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
	<1417602539.11243.4.camel@citrix.com>
	<20141203104912.GA30431@aepfle.de>
	<1417603870.11243.10.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417603870.11243.10.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, Ian Campbell wrote:

> On Wed, 2014-12-03 at 11:49 +0100, Olaf Hering wrote:
> > On Wed, Dec 03, Ian Campbell wrote:
> > 
> > > Ah I didn't know about the sd_listen_fds thing, so I think that what we
> > > need then is to use pkg-config first to determine if systemd-daemon is
> > > present at all, and then check for specific symbols we require using the
> > > pkg-config supplied CFLAGS and LDFLAGS rather than assuming
> > > -lsystemd-daemon.
> > 
> > Correction: sd_listen_fds is available since at least v1.
> >  git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d
> >  v1~390
> 
> In that case I don't think we realistically need to check for it?

Yes. Anything before 208 is stale. At least I dont have anything older
around for testing.

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 10:55:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 10: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 1Xw7am-0000DF-Fz; Wed, 03 Dec 2014 10:55:32 +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 1Xw7al-0000D8-GG
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 10:55:31 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	39/1B-03148-22CEE745; Wed, 03 Dec 2014 10:55:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417604130!12694425!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15987 invoked from network); 3 Dec 2014 10:55:30 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 10:55:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417604130; l=796;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=4gU4BFOxOHP8kfNbCtQnRiV1nEg=;
	b=EDoetbmXABQpd8j/H9DZE2mNNS1zCElFNusUDh8WJ6AG25/8mC5p//hswEi/9AjZxPz
	tiax97LyvZb6ivgQQMVA/fDZfAfDGppSUrzf+A8Ku2SGBFPd9zJce1PUPeDUONPfHamzg
	z7h7Xwlig9FaIQtBzkvkSRqE36TaYcJF1Ow=
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.2 AUTH) with ESMTPSA id L0210bqB3AtNzv2
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 11:55:23 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 069E35016D; Wed,  3 Dec 2014 11:55:22 +0100 (CET)
Date: Wed, 3 Dec 2014 11:55:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141203105522.GA32341@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
	<1417602539.11243.4.camel@citrix.com>
	<20141203104912.GA30431@aepfle.de>
	<1417603870.11243.10.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417603870.11243.10.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, Ian Campbell wrote:

> On Wed, 2014-12-03 at 11:49 +0100, Olaf Hering wrote:
> > On Wed, Dec 03, Ian Campbell wrote:
> > 
> > > Ah I didn't know about the sd_listen_fds thing, so I think that what we
> > > need then is to use pkg-config first to determine if systemd-daemon is
> > > present at all, and then check for specific symbols we require using the
> > > pkg-config supplied CFLAGS and LDFLAGS rather than assuming
> > > -lsystemd-daemon.
> > 
> > Correction: sd_listen_fds is available since at least v1.
> >  git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d
> >  v1~390
> 
> In that case I don't think we realistically need to check for it?

Yes. Anything before 208 is stale. At least I dont have anything older
around for testing.

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 11:25:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 11:25:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw82t-0000qh-2N; Wed, 03 Dec 2014 11:24:35 +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 1Xw82q-0000qc-UQ
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 11:24:33 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	88/70-02957-0F2FE745; Wed, 03 Dec 2014 11:24:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417605871!12707363!1
X-Originating-IP: [81.169.146.163]
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 19199 invoked from network); 3 Dec 2014 11:24:31 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 11:24:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417605871; l=480;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=ogZoa8zcqI5FE0mJn7EkZg02b9o=;
	b=gpQmlo6a4GqR4QLZEL2TvQlUJsKbS6KSLmx6vtC8XdzdEWAeLHzGxW/Q8XhjB9icCn+
	bgTv0gJd38qMOjW2Zzb3pD/lghJL8eUih7JbeBtg2CxvWnda04zaYRLJZ4J2qDR97Uq+2
	Jn/m41Pkhos727klNnbJTSMSydD0gU0PUhw=
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.2 AUTH) with ESMTPSA id v0026cqB3BOSw86
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 12:24:28 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 2AD6F5016D; Wed,  3 Dec 2014 12:24:28 +0100 (CET)
Date: Wed, 3 Dec 2014 12:24:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141203112427.GA7383@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
	<20141202154652.GA26732@aepfle.de>
	<20141202183920.GG32385@laptop.dumpdata.com>
	<20141203083628.GA11508@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141203083628.GA11508@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first 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 Wed, Dec 03, Olaf Hering wrote:

> On Tue, Dec 02, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 02, 2014 at 04:46:52PM +0100, Olaf Hering wrote:
> > > On Mon, Dec 01, Konrad Rzeszutek Wilk wrote:
> > ACPI hotplug. And it does work after PCI discovery.
> In a pvops kernel, is the emulated but unplugged PCI hardware still listed with lspci?

It is not. So thats why it happens to work.

So how would I trigger an ACPI hotplug event within qemus unplug code?

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 11:25:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 11:25:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw82t-0000qh-2N; Wed, 03 Dec 2014 11:24:35 +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 1Xw82q-0000qc-UQ
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 11:24:33 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	88/70-02957-0F2FE745; Wed, 03 Dec 2014 11:24:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417605871!12707363!1
X-Originating-IP: [81.169.146.163]
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 19199 invoked from network); 3 Dec 2014 11:24:31 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 11:24:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417605871; l=480;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=ogZoa8zcqI5FE0mJn7EkZg02b9o=;
	b=gpQmlo6a4GqR4QLZEL2TvQlUJsKbS6KSLmx6vtC8XdzdEWAeLHzGxW/Q8XhjB9icCn+
	bgTv0gJd38qMOjW2Zzb3pD/lghJL8eUih7JbeBtg2CxvWnda04zaYRLJZ4J2qDR97Uq+2
	Jn/m41Pkhos727klNnbJTSMSydD0gU0PUhw=
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.2 AUTH) with ESMTPSA id v0026cqB3BOSw86
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 3 Dec 2014 12:24:28 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 2AD6F5016D; Wed,  3 Dec 2014 12:24:28 +0100 (CET)
Date: Wed, 3 Dec 2014 12:24:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141203112427.GA7383@aepfle.de>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
	<20141202154652.GA26732@aepfle.de>
	<20141202183920.GG32385@laptop.dumpdata.com>
	<20141203083628.GA11508@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141203083628.GA11508@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first 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 Wed, Dec 03, Olaf Hering wrote:

> On Tue, Dec 02, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 02, 2014 at 04:46:52PM +0100, Olaf Hering wrote:
> > > On Mon, Dec 01, Konrad Rzeszutek Wilk wrote:
> > ACPI hotplug. And it does work after PCI discovery.
> In a pvops kernel, is the emulated but unplugged PCI hardware still listed with lspci?

It is not. So thats why it happens to work.

So how would I trigger an ACPI hotplug event within qemus unplug code?

Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 11:36:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 11:36:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw8E5-00017q-8l; Wed, 03 Dec 2014 11:36: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 1Xw8E3-00017i-EY
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 11:36:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EC/A7-25276-6A5FE745; Wed, 03 Dec 2014 11:36:06 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417606566!13113476!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8497 invoked from network); 3 Dec 2014 11:36:06 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 11:36:06 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so19577793wgg.1
	for <xen-devel@lists.xen.org>; Wed, 03 Dec 2014 03: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:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=XH+clNP1L8EkI48OdCucbHeLq2TBSnIJQ+ffG6Lq10I=;
	b=DPvAddJAHbdGxR4JV5ELKr5qFFhN5EM6+iehjIL5RjI4jf8OY60rFHcbB3VqGzgJc7
	V14hLNR+mC2+m5uo27o/7ZR5u7sohtw8j8iVkiNTr9QHWgF1XNojkCihtA+RDQ7shN7d
	o18QLHmrQsI7z29mQxwCDLMU+h0elu/Jl4M2ZhF1Bzyd+mxC2+j3/zifMcav4NV6uTTB
	sK2tahpmb2eP+uctjfcKlIU4/p3CZ8lmIRXDOleOs9Ss3fN6jItdT/2UkqTPEyJr3WM+
	N+qlS9rmr/6H0ZAu9+URiaFH88pSCPbEUoWKbbWDA+idL5HWa4dOYgPr9vxAxJ1hliuE
	fRig==
X-Gm-Message-State: ALoCoQkQZk+AQaaXywi2IuIf7wXxZipUxFItX3JDSurnY+P3Q9Jxy7YHiKxYxFP6L8L1qsPsoq0T
X-Received: by 10.194.19.38 with SMTP id b6mr6816542wje.44.1417606566076;
	Wed, 03 Dec 2014 03:36:06 -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
	mw7sm36742510wib.14.2014.12.03.03.36.04 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 03 Dec 2014 03:36:05 -0800 (PST)
Message-ID: <547EF5A3.6030705@linaro.org>
Date: Wed, 03 Dec 2014 11:36:03 +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.3.0
MIME-Version: 1.0
To: Warner Losh <imp@bsdimp.com>
References: <54726138.3090003@linaro.org> <20141128135737.23a71643@bender.lan>
	<547DDB4B.6060506@linaro.org>
	<B47D5F0D-4C91-4F43-A436-F67522EEE8EA@bsdimp.com>
In-Reply-To: <B47D5F0D-4C91-4F43-A436-F67522EEE8EA@bsdimp.com>
Content-Length: 629
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Andrew Turner <andrew@fubar.geek.nz>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	freebsd-xen@freebsd.org, freebsd-arm <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-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

T24gMDIvMTIvMjAxNCAxODozMCwgV2FybmVyIExvc2ggd3JvdGU6Cj4gSGV5IEp1bGllbiwKCkhp
IFdhcm5lciwKCj4gSGF2ZSB5b3UgcmViYXNlZCB5b3VyIHBhdGNoIHRyYWluIGFmdGVyIEFuZHJl
d+KAmXMgY29tbWl0cz8KCkkganVzdCBwdXNoZWQgYSBuZXcgYnJhbmNoIHJlYmFzZWQgb24gdGhl
IGxhdGVzdCBtYXN0ZXI6CgpnaXQ6Ly94ZW5iaXRzLnhlbi5vcmcvcGVvcGxlL2p1bGllbmcvZnJl
ZWJzZC5naXQgYnJhbmNoIHhlbi1hcm0tdjIuMgoKSSBjYW4gcmUtZXhwb3J0IHRoZSBwYXRjaCBp
bnRvIGZpbGVzIGlmIG5lY2Vzc2FyeS4KClJlZ2FyZHMsCgotLSAKSnVsaWVuIEdyYWxsCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Dec 03 11:36:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 11:36:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw8E5-00017q-8l; Wed, 03 Dec 2014 11:36: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 1Xw8E3-00017i-EY
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 11:36:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EC/A7-25276-6A5FE745; Wed, 03 Dec 2014 11:36:06 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417606566!13113476!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8497 invoked from network); 3 Dec 2014 11:36:06 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 11:36:06 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so19577793wgg.1
	for <xen-devel@lists.xen.org>; Wed, 03 Dec 2014 03: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:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=XH+clNP1L8EkI48OdCucbHeLq2TBSnIJQ+ffG6Lq10I=;
	b=DPvAddJAHbdGxR4JV5ELKr5qFFhN5EM6+iehjIL5RjI4jf8OY60rFHcbB3VqGzgJc7
	V14hLNR+mC2+m5uo27o/7ZR5u7sohtw8j8iVkiNTr9QHWgF1XNojkCihtA+RDQ7shN7d
	o18QLHmrQsI7z29mQxwCDLMU+h0elu/Jl4M2ZhF1Bzyd+mxC2+j3/zifMcav4NV6uTTB
	sK2tahpmb2eP+uctjfcKlIU4/p3CZ8lmIRXDOleOs9Ss3fN6jItdT/2UkqTPEyJr3WM+
	N+qlS9rmr/6H0ZAu9+URiaFH88pSCPbEUoWKbbWDA+idL5HWa4dOYgPr9vxAxJ1hliuE
	fRig==
X-Gm-Message-State: ALoCoQkQZk+AQaaXywi2IuIf7wXxZipUxFItX3JDSurnY+P3Q9Jxy7YHiKxYxFP6L8L1qsPsoq0T
X-Received: by 10.194.19.38 with SMTP id b6mr6816542wje.44.1417606566076;
	Wed, 03 Dec 2014 03:36:06 -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
	mw7sm36742510wib.14.2014.12.03.03.36.04 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 03 Dec 2014 03:36:05 -0800 (PST)
Message-ID: <547EF5A3.6030705@linaro.org>
Date: Wed, 03 Dec 2014 11:36:03 +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.3.0
MIME-Version: 1.0
To: Warner Losh <imp@bsdimp.com>
References: <54726138.3090003@linaro.org> <20141128135737.23a71643@bender.lan>
	<547DDB4B.6060506@linaro.org>
	<B47D5F0D-4C91-4F43-A436-F67522EEE8EA@bsdimp.com>
In-Reply-To: <B47D5F0D-4C91-4F43-A436-F67522EEE8EA@bsdimp.com>
Content-Length: 629
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Andrew Turner <andrew@fubar.geek.nz>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	freebsd-xen@freebsd.org, freebsd-arm <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-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

T24gMDIvMTIvMjAxNCAxODozMCwgV2FybmVyIExvc2ggd3JvdGU6Cj4gSGV5IEp1bGllbiwKCkhp
IFdhcm5lciwKCj4gSGF2ZSB5b3UgcmViYXNlZCB5b3VyIHBhdGNoIHRyYWluIGFmdGVyIEFuZHJl
d+KAmXMgY29tbWl0cz8KCkkganVzdCBwdXNoZWQgYSBuZXcgYnJhbmNoIHJlYmFzZWQgb24gdGhl
IGxhdGVzdCBtYXN0ZXI6CgpnaXQ6Ly94ZW5iaXRzLnhlbi5vcmcvcGVvcGxlL2p1bGllbmcvZnJl
ZWJzZC5naXQgYnJhbmNoIHhlbi1hcm0tdjIuMgoKSSBjYW4gcmUtZXhwb3J0IHRoZSBwYXRjaCBp
bnRvIGZpbGVzIGlmIG5lY2Vzc2FyeS4KClJlZ2FyZHMsCgotLSAKSnVsaWVuIEdyYWxsCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Dec 03 11:51:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 11: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 1Xw8Sp-0001Oe-0o; Wed, 03 Dec 2014 11:51:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xw8Sn-0001OZ-SQ
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 11:51:22 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	77/89-17735-939FE745; Wed, 03 Dec 2014 11:51:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417607479!10797348!1
X-Originating-IP: [66.165.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 20010 invoked from network); 3 Dec 2014 11:51:20 -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;
	3 Dec 2014 11:51:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199359649"
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, 3 Dec 2014 06:50: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 1Xw8S9-0000dW-Hs;
	Wed, 03 Dec 2014 11:50:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xw8S6-0008BW-TW;
	Wed, 03 Dec 2014 11:50:39 +0000
Date: Wed, 3 Dec 2014 11:50:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32019-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] 32019: 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 32019 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32019/

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            1 STARTING                 running [st=running!]
 test-amd64-i386-xl-multivcpu 11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2      <none executed>              broken
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 31241
 test-amd64-i386-qemuu-rhel6hvm-intel  1 STARTING         running [st=running!]
 test-amd64-i386-xl-win7-amd64    <none executed>              blocked
 test-amd64-amd64-xl-qemut-winxpsp3  2 STARTING           running [st=running!]
 test-amd64-i386-xl-qemut-debianhvm-amd64    <none executed>             broken
 test-amd64-amd64-xl-qemut-debianhvm-amd64 2 hosts-allocate broken REGR. vs. 31241
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)           running [st=running!]
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-sedf      1 build-check(1)           running [st=running!]
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1    <none executed>             broken
 test-amd64-i386-xl-qemut-winxpsp3    <none executed>              blocked
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)           running [st=running!]

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-pcipt-intel  2 hosts-allocate       broken 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-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 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-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-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-winxpsp3-vcpus1 14 guest-stop               fail never pass

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

------------------------------------------------------------
700 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                                           blocked 
 test-amd64-i386-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                     broken  
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              blocked 
 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                                blocked 
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               fail    
 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                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-xl-sedf                                     blocked 
 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                           broken  
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 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

broken test-amd64-i386-xl STARTING running
broken-job test-amd64-i386-xl-credit2 broken
broken test-amd64-i386-qemuu-rhel6hvm-intel STARTING running
broken-job test-amd64-i386-xl-win7-amd64 blocked
broken test-amd64-amd64-xl-qemut-winxpsp3 STARTING running
broken-job test-amd64-i386-xl-qemut-debianhvm-amd64 broken
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 hosts-allocate
broken test-amd64-amd64-xl-sedf-pin build-check(1) running
broken test-amd64-amd64-xl-sedf build-check(1) running
broken-step test-amd64-amd64-xl-pcipt-intel hosts-allocate
broken-job test-amd64-i386-xl-qemut-winxpsp3-vcpus1 broken
broken-job test-amd64-i386-xl-qemut-winxpsp3 blocked
broken test-amd64-amd64-xl-winxpsp3 build-check(1) running

Not pushing.

(No revision log; it would be 30923 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 Dec 03 11:51:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 11: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 1Xw8Sp-0001Oe-0o; Wed, 03 Dec 2014 11:51:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xw8Sn-0001OZ-SQ
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 11:51:22 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	77/89-17735-939FE745; Wed, 03 Dec 2014 11:51:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417607479!10797348!1
X-Originating-IP: [66.165.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 20010 invoked from network); 3 Dec 2014 11:51:20 -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;
	3 Dec 2014 11:51:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199359649"
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, 3 Dec 2014 06:50: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 1Xw8S9-0000dW-Hs;
	Wed, 03 Dec 2014 11:50:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xw8S6-0008BW-TW;
	Wed, 03 Dec 2014 11:50:39 +0000
Date: Wed, 3 Dec 2014 11:50:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32019-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] 32019: 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 32019 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32019/

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            1 STARTING                 running [st=running!]
 test-amd64-i386-xl-multivcpu 11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2      <none executed>              broken
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 31241
 test-amd64-i386-qemuu-rhel6hvm-intel  1 STARTING         running [st=running!]
 test-amd64-i386-xl-win7-amd64    <none executed>              blocked
 test-amd64-amd64-xl-qemut-winxpsp3  2 STARTING           running [st=running!]
 test-amd64-i386-xl-qemut-debianhvm-amd64    <none executed>             broken
 test-amd64-amd64-xl-qemut-debianhvm-amd64 2 hosts-allocate broken REGR. vs. 31241
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)           running [st=running!]
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-amd64-xl-sedf      1 build-check(1)           running [st=running!]
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1    <none executed>             broken
 test-amd64-i386-xl-qemut-winxpsp3    <none executed>              blocked
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)           running [st=running!]

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-pcipt-intel  2 hosts-allocate       broken 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-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 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-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-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-winxpsp3-vcpus1 14 guest-stop               fail never pass

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

------------------------------------------------------------
700 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                                           blocked 
 test-amd64-i386-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                     broken  
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              blocked 
 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                                blocked 
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               fail    
 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                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-xl-sedf                                     blocked 
 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                           broken  
 test-amd64-i386-xl-qemut-winxpsp3                            blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 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

broken test-amd64-i386-xl STARTING running
broken-job test-amd64-i386-xl-credit2 broken
broken test-amd64-i386-qemuu-rhel6hvm-intel STARTING running
broken-job test-amd64-i386-xl-win7-amd64 blocked
broken test-amd64-amd64-xl-qemut-winxpsp3 STARTING running
broken-job test-amd64-i386-xl-qemut-debianhvm-amd64 broken
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 hosts-allocate
broken test-amd64-amd64-xl-sedf-pin build-check(1) running
broken test-amd64-amd64-xl-sedf build-check(1) running
broken-step test-amd64-amd64-xl-pcipt-intel hosts-allocate
broken-job test-amd64-i386-xl-qemut-winxpsp3-vcpus1 broken
broken-job test-amd64-i386-xl-qemut-winxpsp3 blocked
broken test-amd64-amd64-xl-winxpsp3 build-check(1) running

Not pushing.

(No revision log; it would be 30923 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 Dec 03 12:20:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 12: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 1Xw8us-00023j-Fl; Wed, 03 Dec 2014 12:20: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 1Xw8uq-00023e-JU
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 12:20:20 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	17/53-17735-3000F745; Wed, 03 Dec 2014 12:20:19 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417609217!10849185!1
X-Originating-IP: [66.165.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 23913 invoked from network); 3 Dec 2014 12:20: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;
	3 Dec 2014 12:20:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199367198"
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, 3 Dec 2014 07:20: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 1Xw8um-0000vb-Ju;
	Wed, 03 Dec 2014 12:20:16 +0000
Date: Wed, 3 Dec 2014 12:20:04 +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: <20141203105458.GA4208@zion.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1412031218290.30971@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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
	<547E1FC1.70004@terremark.com>
	<20141203105458.GA4208@zion.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, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, qemu-devel@nongnu.org,
	Don Slutz <dslutz@verizon.com>
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, 3 Dec 2014, Wei Liu wrote:
> On Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote:
> [...]
> > >>>>           hw_error("xc_domain_getinfo failed");
> > >>>>       }
> > >>>>-    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;
> > >>>>+    real_free = free_pages;
> > >>>>+    if (free_pages > VGA_HOLE_SIZE) {
> > >>>>+        free_pages -= VGA_HOLE_SIZE;
> > >>>>+    } else {
> > >>>>+        free_pages = 0;
> > >>>>+    }
> > >I don't think we need to subtract VGA_HOLE_SIZE.
> > 
> > If you do not use some slack (like 32 here), xen does report:
> > 
> > 
> > (d5) [2014-11-29 17:07:21] Loaded SeaBIOS
> > (d5) [2014-11-29 17:07:21] Creating MP tables ...
> > (d5) [2014-11-29 17:07:21] Loading ACPI ...
> > (XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for domain
> > 5: 1057417 > 1057416
> > (XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0
> 
> This message is a bit red herring.
> 
> It's hvmloader trying to populate ram for firmware data. The actual
> amount of extra pages needed depends on the firmware.
> 
> In any case it's safe to disallow hvmloader from doing so, it will just
> relocate some pages from ram (hence shrinking *mem_end).

That looks like a better solution


> > extent: id=5 memflags=0 (0 of 1)
> > (d5) [2014-11-29 17:07:21] vm86 TSS at 00098c00
> > (d5) [2014-11-29 17:07:21] BIOS map:
> > 
> > 
> > However while QEMU startup ends with 32 "free" pages (maxmem - curmem)
> > this quickly changes to 23.  I.E. there are 7 more places that act like a
> > call
> > to xc_domain_populate_physmap_exact() but do not log errors if there is
> > no free pages.  And just to make sure I do not fully understand what is
> > happening here, after the message above, the domain appears to work
> > fine and ends up with 8 "free" pages (code I do not know about ends up
> > releasing populated pages).
> > 
> > So my current thinking is to have QEMU leave a few (9 to 32 (64?)) pages
> > "free".
> > 
> 
> Unless we know before hand how many pages hvmloader needs this number is
> estimation at best.
 
Right. It would be nice to get rid of any estimations by:
- making hvmloader use normal ram
- making qemu increase maxmem
- removing all the estimation from libxl

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 12:20:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 12: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 1Xw8us-00023j-Fl; Wed, 03 Dec 2014 12:20: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 1Xw8uq-00023e-JU
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 12:20:20 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	17/53-17735-3000F745; Wed, 03 Dec 2014 12:20:19 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417609217!10849185!1
X-Originating-IP: [66.165.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 23913 invoked from network); 3 Dec 2014 12:20: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;
	3 Dec 2014 12:20:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199367198"
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, 3 Dec 2014 07:20: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 1Xw8um-0000vb-Ju;
	Wed, 03 Dec 2014 12:20:16 +0000
Date: Wed, 3 Dec 2014 12:20:04 +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: <20141203105458.GA4208@zion.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1412031218290.30971@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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
	<547E1FC1.70004@terremark.com>
	<20141203105458.GA4208@zion.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, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, qemu-devel@nongnu.org,
	Don Slutz <dslutz@verizon.com>
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, 3 Dec 2014, Wei Liu wrote:
> On Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote:
> [...]
> > >>>>           hw_error("xc_domain_getinfo failed");
> > >>>>       }
> > >>>>-    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;
> > >>>>+    real_free = free_pages;
> > >>>>+    if (free_pages > VGA_HOLE_SIZE) {
> > >>>>+        free_pages -= VGA_HOLE_SIZE;
> > >>>>+    } else {
> > >>>>+        free_pages = 0;
> > >>>>+    }
> > >I don't think we need to subtract VGA_HOLE_SIZE.
> > 
> > If you do not use some slack (like 32 here), xen does report:
> > 
> > 
> > (d5) [2014-11-29 17:07:21] Loaded SeaBIOS
> > (d5) [2014-11-29 17:07:21] Creating MP tables ...
> > (d5) [2014-11-29 17:07:21] Loading ACPI ...
> > (XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for domain
> > 5: 1057417 > 1057416
> > (XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0
> 
> This message is a bit red herring.
> 
> It's hvmloader trying to populate ram for firmware data. The actual
> amount of extra pages needed depends on the firmware.
> 
> In any case it's safe to disallow hvmloader from doing so, it will just
> relocate some pages from ram (hence shrinking *mem_end).

That looks like a better solution


> > extent: id=5 memflags=0 (0 of 1)
> > (d5) [2014-11-29 17:07:21] vm86 TSS at 00098c00
> > (d5) [2014-11-29 17:07:21] BIOS map:
> > 
> > 
> > However while QEMU startup ends with 32 "free" pages (maxmem - curmem)
> > this quickly changes to 23.  I.E. there are 7 more places that act like a
> > call
> > to xc_domain_populate_physmap_exact() but do not log errors if there is
> > no free pages.  And just to make sure I do not fully understand what is
> > happening here, after the message above, the domain appears to work
> > fine and ends up with 8 "free" pages (code I do not know about ends up
> > releasing populated pages).
> > 
> > So my current thinking is to have QEMU leave a few (9 to 32 (64?)) pages
> > "free".
> > 
> 
> Unless we know before hand how many pages hvmloader needs this number is
> estimation at best.
 
Right. It would be nice to get rid of any estimations by:
- making hvmloader use normal ram
- making qemu increase maxmem
- removing all the estimation from libxl

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 12:53:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 12:53:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw9Qg-0002ed-Ew; Wed, 03 Dec 2014 12:53:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xw9Qf-0002eY-DX
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 12:53:13 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	E4/44-02699-8B70F745; Wed, 03 Dec 2014 12:53:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417611190!12729048!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 25947 invoked from network); 3 Dec 2014 12:53:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 12:53:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199038295"
Message-ID: <547F07B4.2050805@citrix.com>
Date: Wed, 3 Dec 2014 12:53:08 +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>, <xen-devel@lists.xen.org>
References: <1417603298-4213-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417603298-4213-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>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: expose #define to 4.5 and
	above
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 10:41, Wei Liu wrote:
> In e3abab74 (libxl: un-constify return value of libxl_basename), the
> macro was exposed to releases < 4.5. However only new code is able to
> make use of that macro so it should be exposed to releases >= 4.5.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  tools/libxl/libxl.h       |    6 +++---
>  tools/libxl/libxl_utils.c |    2 +-
>  tools/libxl/libxl_utils.h |    2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 291c190..0a123f1 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -478,13 +478,13 @@ typedef struct libxl__ctx libxl_ctx;
>  #endif
>  
>  /*
> - * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> + * LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
>   *
>   * The return value of libxl_basename is malloc'ed but the erroneously
>   * marked as "const" in releases before 4.5.
>   */
> -#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
> -#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
> +#if !defined(LIBXL_API_VERSION) || LIBXL_API_VERSION >= 0x040500
> +#define LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE 1
>  #endif
>  
>  /*
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 22119fc..7095b58 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -19,7 +19,7 @@
>  
>  #include "libxl_internal.h"
>  
> -#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> +#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
>  const
>  #endif
>  char *libxl_basename(const char *name)
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> index 8277eb9..acacdd9 100644
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -18,7 +18,7 @@
>  
>  #include "libxl.h"
>  
> -#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> +#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
>  const
>  #endif
>  char *libxl_basename(const char *name); /* returns string from strdup */


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 12:53:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 12:53:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw9Qg-0002ed-Ew; Wed, 03 Dec 2014 12:53:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xw9Qf-0002eY-DX
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 12:53:13 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	E4/44-02699-8B70F745; Wed, 03 Dec 2014 12:53:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417611190!12729048!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 25947 invoked from network); 3 Dec 2014 12:53:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 12:53:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199038295"
Message-ID: <547F07B4.2050805@citrix.com>
Date: Wed, 3 Dec 2014 12:53:08 +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>, <xen-devel@lists.xen.org>
References: <1417603298-4213-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417603298-4213-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>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: expose #define to 4.5 and
	above
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 10:41, Wei Liu wrote:
> In e3abab74 (libxl: un-constify return value of libxl_basename), the
> macro was exposed to releases < 4.5. However only new code is able to
> make use of that macro so it should be exposed to releases >= 4.5.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  tools/libxl/libxl.h       |    6 +++---
>  tools/libxl/libxl_utils.c |    2 +-
>  tools/libxl/libxl_utils.h |    2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 291c190..0a123f1 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -478,13 +478,13 @@ typedef struct libxl__ctx libxl_ctx;
>  #endif
>  
>  /*
> - * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> + * LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
>   *
>   * The return value of libxl_basename is malloc'ed but the erroneously
>   * marked as "const" in releases before 4.5.
>   */
> -#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
> -#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
> +#if !defined(LIBXL_API_VERSION) || LIBXL_API_VERSION >= 0x040500
> +#define LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE 1
>  #endif
>  
>  /*
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 22119fc..7095b58 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -19,7 +19,7 @@
>  
>  #include "libxl_internal.h"
>  
> -#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> +#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
>  const
>  #endif
>  char *libxl_basename(const char *name)
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> index 8277eb9..acacdd9 100644
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -18,7 +18,7 @@
>  
>  #include "libxl.h"
>  
> -#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> +#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
>  const
>  #endif
>  char *libxl_basename(const char *name); /* returns string from strdup */


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 13:15:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 13:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw9mB-0003AB-EJ; Wed, 03 Dec 2014 13:15:27 +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 1Xw9mA-0003A6-GH
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 13:15:26 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	EA/A1-14214-DEC0F745; Wed, 03 Dec 2014 13:15:25 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417612524!11279308!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15323 invoked from network); 3 Dec 2014 13:15:25 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 13:15:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417612525; x=1449148525;
	h=from:to:cc:subject:date:message-id;
	bh=tSxncX9rv9Q64K10mhLa8Pd1QCN/8iHG6G0ct9W3fH0=;
	b=E0P6X3LvqHgy3hn4oFUZKeoLQX/K56TsjJyyp5lhZgmluiuUqhv5SQaU
	kkUjgpIwyS69vEXsGe6DYR/ZGzlfSEEJ9PhCHCRL4L6rbWkFY42t/Y6Q1
	0ccSWh6JbVereblvQ/y2SiGhhHkkFDyjGxU329Vojvon3S0YA8xuWEi+n M=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 03 Dec 2014 13:15:23 +0000
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="884376074"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.110.97])
	by fldsmtpi03.verizon.com with ESMTP; 03 Dec 2014 13:15:22 +0000
From: Don Slutz <dslutz@verizon.com>
To: qemu-devel@nongnu.org, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed,  3 Dec 2014 08:15:19 -0500
Message-Id: <1417612519-6931-1-git-send-email-dslutz@verizon.com>
X-Mailer: git-send-email 1.8.4
Cc: Don Slutz <dslutz@verizon.com>
Subject: [Xen-devel] [PATCH for 2.3 v2 1/1] xen-hvm: 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

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>
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
v2: Changes by Don Slutz
  Switch from xc_domain_getinfo to xc_domain_getinfolist
  Fix error check for xc_domain_getinfolist
  Limit increase of maxmem to only do when needed:
    Add QEMU_SPARE_PAGES (How many pages to leave free)
    Add free_pages calculation

 xen-hvm.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/xen-hvm.c b/xen-hvm.c
index 7548794..d30e77e 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -90,6 +90,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
 #endif
 
 #define BUFFER_IO_MAX_DELAY  100
+#define QEMU_SPARE_PAGES 16
 
 typedef struct XenPhysmap {
     hwaddr start_addr;
@@ -244,6 +245,8 @@ 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_domaininfo_t info;
+    unsigned long free_pages;
 
     if (runstate_check(RUN_STATE_INMIGRATE)) {
         /* RAM already populated in Xen */
@@ -266,6 +269,22 @@ 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_getinfolist(xen_xc, xen_domid, 1, &info) != 1) ||
+        (info.domain != xen_domid)) {
+        hw_error("xc_domain_getinfolist failed");
+    }
+    free_pages = info.max_pages - info.tot_pages;
+    if (free_pages > QEMU_SPARE_PAGES) {
+        free_pages -= QEMU_SPARE_PAGES;
+    } else {
+        free_pages = 0;
+    }
+    if ((free_pages < nr_pfn) &&
+        (xc_domain_setmaxmem(xen_xc, xen_domid,
+                             ((info.max_pages + nr_pfn - free_pages)
+                              << (XC_PAGE_SHIFT - 10))) < 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);
     }
-- 
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 Dec 03 13:15:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 13:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xw9mB-0003AB-EJ; Wed, 03 Dec 2014 13:15:27 +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 1Xw9mA-0003A6-GH
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 13:15:26 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	EA/A1-14214-DEC0F745; Wed, 03 Dec 2014 13:15:25 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417612524!11279308!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15323 invoked from network); 3 Dec 2014 13:15:25 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 13:15:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417612525; x=1449148525;
	h=from:to:cc:subject:date:message-id;
	bh=tSxncX9rv9Q64K10mhLa8Pd1QCN/8iHG6G0ct9W3fH0=;
	b=E0P6X3LvqHgy3hn4oFUZKeoLQX/K56TsjJyyp5lhZgmluiuUqhv5SQaU
	kkUjgpIwyS69vEXsGe6DYR/ZGzlfSEEJ9PhCHCRL4L6rbWkFY42t/Y6Q1
	0ccSWh6JbVereblvQ/y2SiGhhHkkFDyjGxU329Vojvon3S0YA8xuWEi+n M=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 03 Dec 2014 13:15:23 +0000
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="884376074"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.110.97])
	by fldsmtpi03.verizon.com with ESMTP; 03 Dec 2014 13:15:22 +0000
From: Don Slutz <dslutz@verizon.com>
To: qemu-devel@nongnu.org, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed,  3 Dec 2014 08:15:19 -0500
Message-Id: <1417612519-6931-1-git-send-email-dslutz@verizon.com>
X-Mailer: git-send-email 1.8.4
Cc: Don Slutz <dslutz@verizon.com>
Subject: [Xen-devel] [PATCH for 2.3 v2 1/1] xen-hvm: 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

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>
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
v2: Changes by Don Slutz
  Switch from xc_domain_getinfo to xc_domain_getinfolist
  Fix error check for xc_domain_getinfolist
  Limit increase of maxmem to only do when needed:
    Add QEMU_SPARE_PAGES (How many pages to leave free)
    Add free_pages calculation

 xen-hvm.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/xen-hvm.c b/xen-hvm.c
index 7548794..d30e77e 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -90,6 +90,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
 #endif
 
 #define BUFFER_IO_MAX_DELAY  100
+#define QEMU_SPARE_PAGES 16
 
 typedef struct XenPhysmap {
     hwaddr start_addr;
@@ -244,6 +245,8 @@ 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_domaininfo_t info;
+    unsigned long free_pages;
 
     if (runstate_check(RUN_STATE_INMIGRATE)) {
         /* RAM already populated in Xen */
@@ -266,6 +269,22 @@ 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_getinfolist(xen_xc, xen_domid, 1, &info) != 1) ||
+        (info.domain != xen_domid)) {
+        hw_error("xc_domain_getinfolist failed");
+    }
+    free_pages = info.max_pages - info.tot_pages;
+    if (free_pages > QEMU_SPARE_PAGES) {
+        free_pages -= QEMU_SPARE_PAGES;
+    } else {
+        free_pages = 0;
+    }
+    if ((free_pages < nr_pfn) &&
+        (xc_domain_setmaxmem(xen_xc, xen_domid,
+                             ((info.max_pages + nr_pfn - free_pages)
+                              << (XC_PAGE_SHIFT - 10))) < 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);
     }
-- 
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 Dec 03 13:40:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 13:40:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwA9V-0003XX-IX; Wed, 03 Dec 2014 13:39:33 +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 1XwA9U-0003XS-5u
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 13:39:32 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	14/8E-26652-3921F745; Wed, 03 Dec 2014 13:39:31 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417613948!11349592!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28274 invoked from network); 3 Dec 2014 13:39:09 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 13:39:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417613948; x=1449149948;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=56GzNuiaA5V+CJ1WuWu/3wUqEr4qhtv04j4q/w2u0vI=;
	b=BR/18WjNlwhjRqqygXz7azhFW2V8pxQ3aJ/9JokThEurQIxB7NSpew2l
	r7khANMfbZT34TNloBNcmIWpPDlEUQB2XjKVEIw4N35OpKKWgCgH0+62t
	DaLyrHZtDOPN0XCw3/QHypFdek0oURoHl2cP+ybewmbN/Buw2L8vAbD7Y w=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by fldsmtpe04.verizon.com with ESMTP; 03 Dec 2014 13:39:02 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="919846207"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.105.118])
	by fldsmtpi01.verizon.com with ESMTP; 03 Dec 2014 13:39:01 +0000
Message-ID: <547F1274.6090607@terremark.com>
Date: Wed, 03 Dec 2014 08:39:00 -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>
	<54768F7F.2030602@terremark.com>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
	<547E1FC1.70004@terremark.com>
	<20141203105458.GA4208@zion.uk.xensource.com>
	<alpine.DEB.2.02.1412031218290.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412031218290.30971@kaball.uk.xensource.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, qemu-devel@nongnu.org,
	Don Slutz <dslutz@verizon.com>
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 12/03/14 07:20, Stefano Stabellini wrote:
> On Wed, 3 Dec 2014, Wei Liu wrote:
>> On Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote:
>> [...]
>>>>>>>            hw_error("xc_domain_getinfo failed");
>>>>>>>        }
>>>>>>> -    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;
>>>>>>> +    real_free = free_pages;
>>>>>>> +    if (free_pages > VGA_HOLE_SIZE) {
>>>>>>> +        free_pages -= VGA_HOLE_SIZE;
>>>>>>> +    } else {
>>>>>>> +        free_pages = 0;
>>>>>>> +    }
>>>> I don't think we need to subtract VGA_HOLE_SIZE.
>>> If you do not use some slack (like 32 here), xen does report:
>>>
>>>
>>> (d5) [2014-11-29 17:07:21] Loaded SeaBIOS
>>> (d5) [2014-11-29 17:07:21] Creating MP tables ...
>>> (d5) [2014-11-29 17:07:21] Loading ACPI ...
>>> (XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for domain
>>> 5: 1057417 > 1057416
>>> (XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0
>> This message is a bit red herring.
>>
>> It's hvmloader trying to populate ram for firmware data. The actual
>> amount of extra pages needed depends on the firmware.
>>
>> In any case it's safe to disallow hvmloader from doing so, it will just
>> relocate some pages from ram (hence shrinking *mem_end).
> That looks like a better solution
>

I went with a "leave some slack" so that the error message above is not 
output.

When a change to hvmloader is done so that the message does not appear 
during
normal usage, the extra pages in QEMU can be dropped.


>>> extent: id=5 memflags=0 (0 of 1)
>>> (d5) [2014-11-29 17:07:21] vm86 TSS at 00098c00
>>> (d5) [2014-11-29 17:07:21] BIOS map:
>>>
>>>
>>> However while QEMU startup ends with 32 "free" pages (maxmem - curmem)
>>> this quickly changes to 23.  I.E. there are 7 more places that act like a
>>> call
>>> to xc_domain_populate_physmap_exact() but do not log errors if there is
>>> no free pages.  And just to make sure I do not fully understand what is
>>> happening here, after the message above, the domain appears to work
>>> fine and ends up with 8 "free" pages (code I do not know about ends up
>>> releasing populated pages).
>>>
>>> So my current thinking is to have QEMU leave a few (9 to 32 (64?)) pages
>>> "free".
>>>
>> Unless we know before hand how many pages hvmloader needs this number is
>> estimation at best.
>   
> Right. It would be nice to get rid of any estimations by:
> - making hvmloader use normal ram
> - making qemu increase maxmem
> - removing all the estimation from libxl

Sounds like a plan for 4.6

     -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 Dec 03 13:40:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 13:40:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwA9V-0003XX-IX; Wed, 03 Dec 2014 13:39:33 +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 1XwA9U-0003XS-5u
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 13:39:32 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	14/8E-26652-3921F745; Wed, 03 Dec 2014 13:39:31 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417613948!11349592!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28274 invoked from network); 3 Dec 2014 13:39:09 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 13:39:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417613948; x=1449149948;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=56GzNuiaA5V+CJ1WuWu/3wUqEr4qhtv04j4q/w2u0vI=;
	b=BR/18WjNlwhjRqqygXz7azhFW2V8pxQ3aJ/9JokThEurQIxB7NSpew2l
	r7khANMfbZT34TNloBNcmIWpPDlEUQB2XjKVEIw4N35OpKKWgCgH0+62t
	DaLyrHZtDOPN0XCw3/QHypFdek0oURoHl2cP+ybewmbN/Buw2L8vAbD7Y w=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by fldsmtpe04.verizon.com with ESMTP; 03 Dec 2014 13:39:02 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="919846207"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.105.118])
	by fldsmtpi01.verizon.com with ESMTP; 03 Dec 2014 13:39:01 +0000
Message-ID: <547F1274.6090607@terremark.com>
Date: Wed, 03 Dec 2014 08:39:00 -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>
	<54768F7F.2030602@terremark.com>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
	<547E1FC1.70004@terremark.com>
	<20141203105458.GA4208@zion.uk.xensource.com>
	<alpine.DEB.2.02.1412031218290.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412031218290.30971@kaball.uk.xensource.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, qemu-devel@nongnu.org,
	Don Slutz <dslutz@verizon.com>
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 12/03/14 07:20, Stefano Stabellini wrote:
> On Wed, 3 Dec 2014, Wei Liu wrote:
>> On Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote:
>> [...]
>>>>>>>            hw_error("xc_domain_getinfo failed");
>>>>>>>        }
>>>>>>> -    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;
>>>>>>> +    real_free = free_pages;
>>>>>>> +    if (free_pages > VGA_HOLE_SIZE) {
>>>>>>> +        free_pages -= VGA_HOLE_SIZE;
>>>>>>> +    } else {
>>>>>>> +        free_pages = 0;
>>>>>>> +    }
>>>> I don't think we need to subtract VGA_HOLE_SIZE.
>>> If you do not use some slack (like 32 here), xen does report:
>>>
>>>
>>> (d5) [2014-11-29 17:07:21] Loaded SeaBIOS
>>> (d5) [2014-11-29 17:07:21] Creating MP tables ...
>>> (d5) [2014-11-29 17:07:21] Loading ACPI ...
>>> (XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for domain
>>> 5: 1057417 > 1057416
>>> (XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0
>> This message is a bit red herring.
>>
>> It's hvmloader trying to populate ram for firmware data. The actual
>> amount of extra pages needed depends on the firmware.
>>
>> In any case it's safe to disallow hvmloader from doing so, it will just
>> relocate some pages from ram (hence shrinking *mem_end).
> That looks like a better solution
>

I went with a "leave some slack" so that the error message above is not 
output.

When a change to hvmloader is done so that the message does not appear 
during
normal usage, the extra pages in QEMU can be dropped.


>>> extent: id=5 memflags=0 (0 of 1)
>>> (d5) [2014-11-29 17:07:21] vm86 TSS at 00098c00
>>> (d5) [2014-11-29 17:07:21] BIOS map:
>>>
>>>
>>> However while QEMU startup ends with 32 "free" pages (maxmem - curmem)
>>> this quickly changes to 23.  I.E. there are 7 more places that act like a
>>> call
>>> to xc_domain_populate_physmap_exact() but do not log errors if there is
>>> no free pages.  And just to make sure I do not fully understand what is
>>> happening here, after the message above, the domain appears to work
>>> fine and ends up with 8 "free" pages (code I do not know about ends up
>>> releasing populated pages).
>>>
>>> So my current thinking is to have QEMU leave a few (9 to 32 (64?)) pages
>>> "free".
>>>
>> Unless we know before hand how many pages hvmloader needs this number is
>> estimation at best.
>   
> Right. It would be nice to get rid of any estimations by:
> - making hvmloader use normal ram
> - making qemu increase maxmem
> - removing all the estimation from libxl

Sounds like a plan for 4.6

     -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 Dec 03 13:46:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 13:46:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwAFl-0003oE-GH; Wed, 03 Dec 2014 13:46:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek@citrix.com>)
	id 1XwAFj-0003na-C8; Wed, 03 Dec 2014 13:45:59 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	C4/16-02954-6141F745; Wed, 03 Dec 2014 13:45:58 +0000
X-Env-Sender: russell.pavlicek@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417614354!12642055!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3806 invoked from network); 3 Dec 2014 13:45:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 13:45:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199396524"
From: Russell Pavlicek <russell.pavlicek@citrix.com>
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"xen-api@lists.xen.org"
	<xen-api@lists.xen.org>, "xen-announce@lists.xenproject.org"
	<xen-announce@lists.xenproject.org>, "xs-devel@lists.xenserver.org"
	<xs-devel@lists.xenserver.org>, "mirageos-devel@lists.xenproject.org"
	<mirageos-devel@lists.xenproject.org>
Thread-Topic: Announcing Xen Project Test Day for 4.5 RC3 on December	4
Thread-Index: AQHQDmhP3KthO1lmv0KpABJgHiXx6A==
Date: Wed, 3 Dec 2014 13:45:40 +0000
Message-ID: <55E78A57290FB64FA0D3CF672F9F3DA2050D17DF@SJCPEX01CL03.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
Subject: [Xen-devel] Announcing Xen Project Test Day for 4.5 RC3 on
	December	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

Folks,

This Thursday, December 4, is our third Test Day for the 4.5 release
cycle. Release Candidate 3 will be available for assessment on 
Wednesday.  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_RC3_test_instructions

To learn more about Test Days, including the proposed dates 
for the RC4 Test Day and final release, 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 Wed Dec 03 13:46:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 13:46:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwAFl-0003oE-GH; Wed, 03 Dec 2014 13:46:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek@citrix.com>)
	id 1XwAFj-0003na-C8; Wed, 03 Dec 2014 13:45:59 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	C4/16-02954-6141F745; Wed, 03 Dec 2014 13:45:58 +0000
X-Env-Sender: russell.pavlicek@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417614354!12642055!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3806 invoked from network); 3 Dec 2014 13:45:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 13:45:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199396524"
From: Russell Pavlicek <russell.pavlicek@citrix.com>
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"xen-api@lists.xen.org"
	<xen-api@lists.xen.org>, "xen-announce@lists.xenproject.org"
	<xen-announce@lists.xenproject.org>, "xs-devel@lists.xenserver.org"
	<xs-devel@lists.xenserver.org>, "mirageos-devel@lists.xenproject.org"
	<mirageos-devel@lists.xenproject.org>
Thread-Topic: Announcing Xen Project Test Day for 4.5 RC3 on December	4
Thread-Index: AQHQDmhP3KthO1lmv0KpABJgHiXx6A==
Date: Wed, 3 Dec 2014 13:45:40 +0000
Message-ID: <55E78A57290FB64FA0D3CF672F9F3DA2050D17DF@SJCPEX01CL03.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
Subject: [Xen-devel] Announcing Xen Project Test Day for 4.5 RC3 on
	December	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

Folks,

This Thursday, December 4, is our third Test Day for the 4.5 release
cycle. Release Candidate 3 will be available for assessment on 
Wednesday.  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_RC3_test_instructions

To learn more about Test Days, including the proposed dates 
for the RC4 Test Day and final release, 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 Wed Dec 03 14:21:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 14:21:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwAnp-0005SK-ER; Wed, 03 Dec 2014 14:21: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 1XwAnn-0005SC-V0
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 14:21:12 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	FD/F1-02953-75C1F745; Wed, 03 Dec 2014 14:21:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417616469!12742554!1
X-Originating-IP: [66.165.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 12302 invoked from network); 3 Dec 2014 14:21:10 -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;
	3 Dec 2014 14:21:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199071027"
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, 3 Dec 2014 09:20: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 1XwAnR-0001Nf-Mt;
	Wed, 03 Dec 2014 14:20:49 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwAnP-0000gR-Bp;
	Wed, 03 Dec 2014 14:20:47 +0000
Date: Wed, 3 Dec 2014 14:20:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32024-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-upstream-unstable test] 32024: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32024 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32024/

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. 31848

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

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-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-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-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-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-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-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                1ebb75b1fee779621b63e84fefa7b07354c43a99
baseline version:
 qemuu                a230ec3101ddda868252c036ea960af2b2d6cd5a

------------------------------------------------------------
People who touched revisions under test:
  Jason Wang <jasowang@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                    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 1ebb75b1fee779621b63e84fefa7b07354c43a99
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.
    
    upstream-commit-id: 771b6ed37e3aa188a7485560b949a41c6cf174dc
    
    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>
    Reviewed-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 Wed Dec 03 14:21:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 14:21:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwAnp-0005SK-ER; Wed, 03 Dec 2014 14:21: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 1XwAnn-0005SC-V0
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 14:21:12 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	FD/F1-02953-75C1F745; Wed, 03 Dec 2014 14:21:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417616469!12742554!1
X-Originating-IP: [66.165.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 12302 invoked from network); 3 Dec 2014 14:21:10 -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;
	3 Dec 2014 14:21:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199071027"
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, 3 Dec 2014 09:20: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 1XwAnR-0001Nf-Mt;
	Wed, 03 Dec 2014 14:20:49 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwAnP-0000gR-Bp;
	Wed, 03 Dec 2014 14:20:47 +0000
Date: Wed, 3 Dec 2014 14:20:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32024-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-upstream-unstable test] 32024: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32024 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32024/

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. 31848

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

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-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-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-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-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-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-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                1ebb75b1fee779621b63e84fefa7b07354c43a99
baseline version:
 qemuu                a230ec3101ddda868252c036ea960af2b2d6cd5a

------------------------------------------------------------
People who touched revisions under test:
  Jason Wang <jasowang@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                    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 1ebb75b1fee779621b63e84fefa7b07354c43a99
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.
    
    upstream-commit-id: 771b6ed37e3aa188a7485560b949a41c6cf174dc
    
    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>
    Reviewed-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 Wed Dec 03 14:30:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 14: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 1XwAwD-0005xm-04; Wed, 03 Dec 2014 14:29:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40726a7d2=chegger@amazon.de>)
	id 1XwAwB-0005xQ-0t
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 14:29:51 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	06/CE-02698-E5E1F745; Wed, 03 Dec 2014 14:29:50 +0000
X-Env-Sender: prvs=40726a7d2=chegger@amazon.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417616988!12745227!1
X-Originating-IP: [207.171.178.25]
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 29487 invoked from network); 3 Dec 2014 14:29:49 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 14:29:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417616989; x=1449152989;
	h=from:to:cc:subject:date:message-id:mime-version;
	bh=ZQApBNgc7lakgfj/M47wMqOMEJvKnCZNk7tDJR0EQII=;
	b=r9ixw/EnMoaOiciBCeRKg57MNxaD3q4JR5rhua0OiNC4Z5Kdx8ffxblA
	KD4xA1TNdFrygq+ngOWPczySt2XWemPcUY9JeFIOSChH2RYQtCuB3M67A
	VgSZBQSGdFxR/M/6/O17JwZNN0yud2HODYFClpuWAwiafQKHpWmlwMcZf Q=;
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="175640602"
Received: from email-inbound-relay-7002.iad7.amazon.com ([10.55.235.150])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2014 14:29:47 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com
	[10.0.103.150])
	by email-inbound-relay-7002.iad7.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB3EThhM025627
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Wed, 3 Dec 2014 14:29:46 GMT
Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Wed, 3 Dec 2014 06:29:45 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.160.14) by
	EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Wed, 3 Dec 2014 06:29:43 -0800
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Wed, 3 Dec 2014 15:29:25 +0100
Message-ID: <1417616967-18720-1-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-Originating-IP: [10.43.160.14]
X-ClientProxiedBy: EX13D03UWA003.ant.amazon.com (10.43.160.39) To
	EX13D03UWA003.ant.amazon.com (10.43.160.39)
Precedence: Bulk
Cc: Christoph Egger <chegger@amazon.de>
Subject: [Xen-devel] [PATCH v3 0/2] gnttab: Improve scaleability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 changes the grant table locking to
a more fain grained locking protocol. The result is
a performance boost measured with blkfront/blkback.
Document the locking protocol.

v3:
  * Addressed gnttab_swap_grant_ref() comment from Andrew Cooper
v2:
  * Add arm part per request from Julien Grall

Christoph Egger (1):
  gnttab: Introduce rwlock to protect updates to grant table state

Matt Wilson (1):
  gnttab: refactor locking for scalability

 docs/misc/grant-tables.txt    |   49 ++++++-
 xen/arch/arm/mm.c             |    4 +-
 xen/arch/x86/mm.c             |    4 +-
 xen/common/grant_table.c      |  321 +++++++++++++++++++++++++----------------
 xen/include/xen/grant_table.h |    9 +-
 5 files changed, 258 insertions(+), 129 deletions(-)

-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 14:30:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 14: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 1XwAwJ-0005z6-CU; Wed, 03 Dec 2014 14:29:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40726a7d2=chegger@amazon.de>)
	id 1XwAwH-0005yW-DT
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 14:29:57 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	C2/1A-02699-46E1F745; Wed, 03 Dec 2014 14:29:56 +0000
X-Env-Sender: prvs=40726a7d2=chegger@amazon.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417616988!12745227!2
X-Originating-IP: [207.171.178.25]
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 30247 invoked from network); 3 Dec 2014 14:29:54 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 14:29:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417616994; x=1449152994;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version;
	bh=7P8K4+hxN8TLZhT58GSD2XksX3gZDhztUoPjxgCtMUA=;
	b=cbfmVL9gHyJHATJ8PvRPjz6mLLgG5ziDJU3P2LkCay6DyyOHUA+WCDSN
	mpvyizJ20WloSZKccjgd25nsPfhgY1S+Vi+BZBuOfjmyBixePO7nBNjT/
	bYo7lTXk4AmdKlXtQKFHKwAveuIR2vFECC3zjO+ENNiw+BmFcYO6s2NlP Y=;
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="175640702"
Received: from email-inbound-relay-25001.iad12.amazon.com ([10.205.29.168])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2014 14:29:53 +0000
Received: from ex10-hub-7002.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com
	[10.0.103.150])
	by email-inbound-relay-25001.iad12.amazon.com (8.14.7/8.14.7) with
	ESMTP id sB3ETa0v008994
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 14:29:51 GMT
Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by
	ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Wed, 3 Dec 2014 06:29:48 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.160.14) by
	EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Wed, 3 Dec 2014 06:29:44 -0800
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Wed, 3 Dec 2014 15:29:26 +0100
Message-ID: <1417616967-18720-2-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1417616967-18720-1-git-send-email-chegger@amazon.de>
References: <1417616967-18720-1-git-send-email-chegger@amazon.de>
MIME-Version: 1.0
X-Originating-IP: [10.43.160.14]
X-ClientProxiedBy: EX13D03UWA003.ant.amazon.com (10.43.160.39) To
	EX13D03UWA003.ant.amazon.com (10.43.160.39)
Precedence: Bulk
Cc: Christoph Egger <chegger@amazon.de>, Keir Fraser <keir@xen.org>, Jan
	Beulich <jbeulich@suse.com>, Matt Wilson <msw@amazon.com>,
	Julien Grall <julien.grall@linaro.org>
Subject: [Xen-devel] [PATCH v3 1/2] gnttab: Introduce rwlock to protect
	updates to grant table state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Split grant table lock into two separate locks. One to protect
maptrack state and change the other into a rwlock.

The rwlock is used to prevent readers from accessing
inconsistent grant table state such as current
version, partially initialized active table pages,
etc.

Signed-off-by: Matt Wilson <msw@amazon.com>
[chegger: ported to xen-staging, split into multiple commits]

v3:
  * Addressed gnttab_swap_grant_ref() comment from Andrew Cooper
v2:
  * Add arm part per request from Julien Grall

Signed-off-by: Christoph Egger <chegger@amazon.de>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Julien Grall <julien.grall@linaro.org>
---
 docs/misc/grant-tables.txt    |   28 +++++++++-
 xen/arch/arm/mm.c             |    4 +-
 xen/arch/x86/mm.c             |    4 +-
 xen/common/grant_table.c      |  120 +++++++++++++++++++++++------------------
 xen/include/xen/grant_table.h |    9 ++--
 5 files changed, 104 insertions(+), 61 deletions(-)

diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt
index 19db4ec..c9ae8f2 100644
--- a/docs/misc/grant-tables.txt
+++ b/docs/misc/grant-tables.txt
@@ -74,7 +74,33 @@ is complete.
  matching map track entry is then removed, as if unmap had been invoked.
  These are not used by the transfer mechanism.
   map->domid         : owner of the mapped frame
-  map->ref_and_flags : grant reference, ro/rw, mapped for host or device access
+  map->ref           : grant reference
+  map->flags         : ro/rw, mapped for host or device access
+
+********************************************************************************
+ Locking
+ ~~~~~~~
+ Xen uses several locks to serialize access to the internal grant table state.
+
+  grant_table->lock          : rwlock used to prevent readers from accessing
+                               inconsistent grant table state such as current
+                               version, partially initialized active table pages,
+                               etc.
+  grant_table->maptrack_lock : spinlock used to protect the maptrack state
+
+ The primary lock for the grant table is a read/write spinlock. All
+ functions that access members of struct grant_table must acquire a
+ read lock around critical sections. Any modification to the members
+ of struct grant_table (e.g., nr_status_frames, nr_grant_frames,
+ active frames, etc.) must only be made if the write lock is
+ held. These elements are read-mostly, and read critical sections can
+ be large, which makes a rwlock a good choice.
+
+ The maptrack state is protected by its own spinlock. Any access (read
+ or write) of struct grant_table members that have a "maptrack_"
+ prefix must be made while holding the maptrack lock. The maptrack
+ state can be rapidly modified under some workloads, and the critical
+ sections are very small, thus we use a spinlock to protect them.
 
 ********************************************************************************
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7d4ba0c..2765683 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1037,7 +1037,7 @@ int xenmem_add_to_physmap_one(
     switch ( space )
     {
     case XENMAPSPACE_grant_table:
-        spin_lock(&d->grant_table->lock);
+        write_lock(&d->grant_table->lock);
 
         if ( d->grant_table->gt_version == 0 )
             d->grant_table->gt_version = 1;
@@ -1067,7 +1067,7 @@ int xenmem_add_to_physmap_one(
 
         t = p2m_ram_rw;
 
-        spin_unlock(&d->grant_table->lock);
+        write_unlock(&d->grant_table->lock);
         break;
     case XENMAPSPACE_shared_info:
         if ( idx != 0 )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 522c43d..37c13b1 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
                 mfn = virt_to_mfn(d->shared_info);
             break;
         case XENMAPSPACE_grant_table:
-            spin_lock(&d->grant_table->lock);
+            write_lock(&d->grant_table->lock);
 
             if ( d->grant_table->gt_version == 0 )
                 d->grant_table->gt_version = 1;
@@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
                     mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
             }
 
-            spin_unlock(&d->grant_table->lock);
+            write_unlock(&d->grant_table->lock);
             break;
         case XENMAPSPACE_gmfn_range:
         case XENMAPSPACE_gmfn:
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 8fba923..24feb65 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -227,23 +227,23 @@ double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
 {
     if ( lgt < rgt )
     {
-        spin_lock(&lgt->lock);
-        spin_lock(&rgt->lock);
+        spin_lock(&lgt->maptrack_lock);
+        spin_lock(&rgt->maptrack_lock);
     }
     else
     {
         if ( lgt != rgt )
-            spin_lock(&rgt->lock);
-        spin_lock(&lgt->lock);
+            spin_lock(&rgt->maptrack_lock);
+        spin_lock(&lgt->maptrack_lock);
     }
 }
 
 static inline void
 double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
 {
-    spin_unlock(&lgt->lock);
+    spin_unlock(&lgt->maptrack_lock);
     if ( lgt != rgt )
-        spin_unlock(&rgt->lock);
+        spin_unlock(&rgt->maptrack_lock);
 }
 
 static inline int
@@ -261,10 +261,10 @@ static inline void
 put_maptrack_handle(
     struct grant_table *t, int handle)
 {
-    spin_lock(&t->lock);
+    spin_lock(&t->maptrack_lock);
     maptrack_entry(t, handle).ref = t->maptrack_head;
     t->maptrack_head = handle;
-    spin_unlock(&t->lock);
+    spin_unlock(&t->maptrack_lock);
 }
 
 static inline int
@@ -276,7 +276,7 @@ get_maptrack_handle(
     struct grant_mapping *new_mt;
     unsigned int          new_mt_limit, nr_frames;
 
-    spin_lock(&lgt->lock);
+    spin_lock(&lgt->maptrack_lock);
 
     while ( unlikely((handle = __get_maptrack_handle(lgt)) == -1) )
     {
@@ -305,7 +305,7 @@ get_maptrack_handle(
                  nr_frames + 1);
     }
 
-    spin_unlock(&lgt->lock);
+    spin_unlock(&lgt->maptrack_lock);
 
     return handle;
 }
@@ -502,7 +502,7 @@ static int grant_map_exists(const struct domain *ld,
     const struct active_grant_entry *act;
     unsigned int ref, max_iter;
     
-    ASSERT(spin_is_locked(&rgt->lock));
+    ASSERT(rw_is_locked(&rgt->lock));
 
     max_iter = min(*ref_count + (1 << GNTTABOP_CONTINUATION_ARG_SHIFT),
                    nr_grant_entries(rgt));
@@ -623,7 +623,7 @@ __gnttab_map_grant_ref(
     }
 
     rgt = rd->grant_table;
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
         PIN_FAIL(unlock_out, GNTST_general_error,
@@ -696,7 +696,7 @@ __gnttab_map_grant_ref(
 
     cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
 
     /* pg may be set, with a refcount included, from __get_paged_frame */
     if ( !pg )
@@ -831,7 +831,7 @@ __gnttab_map_grant_ref(
         put_page(pg);
     }
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     act = &active_entry(rgt, op->ref);
 
@@ -851,7 +851,7 @@ __gnttab_map_grant_ref(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     op->status = rc;
     put_maptrack_handle(lgt, handle);
     rcu_unlock_domain(rd);
@@ -891,28 +891,28 @@ __gnttab_unmap_common(
     ld = current->domain;
     lgt = ld->grant_table;
 
+    read_lock(&lgt->lock);
     op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
 
     if ( unlikely(op->handle >= lgt->maptrack_limit) )
     {
+        read_unlock(&lgt->lock);
         gdprintk(XENLOG_INFO, "Bad handle (%d).\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
+    read_unlock(&lgt->lock);
     op->map = &maptrack_entry(lgt, op->handle);
-    spin_lock(&lgt->lock);
 
     if ( unlikely(!op->map->flags) )
     {
-        spin_unlock(&lgt->lock);
         gdprintk(XENLOG_INFO, "Zero flags for handle (%d).\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
     dom = op->map->domid;
-    spin_unlock(&lgt->lock);
 
     if ( unlikely((rd = rcu_lock_domain_by_id(dom)) == NULL) )
     {
@@ -944,6 +944,7 @@ __gnttab_unmap_common(
     }
 
     op->rd = rd;
+    read_lock(&rgt->lock);
     act = &active_entry(rgt, op->map->ref);
 
     if ( op->frame == 0 )
@@ -1004,6 +1005,7 @@ __gnttab_unmap_common(
 
  unmap_out:
     double_gt_unlock(lgt, rgt);
+    read_unlock(&rgt->lock);
     op->status = rc;
     rcu_unlock_domain(rd);
 }
@@ -1033,8 +1035,8 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
 
     rcu_lock_domain(rd);
     rgt = rd->grant_table;
-    spin_lock(&rgt->lock);
 
+    read_lock(&rgt->lock);
     if ( rgt->gt_version == 0 )
         goto unmap_out;
 
@@ -1098,7 +1100,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
         gnttab_clear_flag(_GTF_reading, status);
 
  unmap_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     if ( put_handle )
     {
         op->map->flags = 0;
@@ -1284,10 +1286,13 @@ gnttab_unpopulate_status_frames(struct domain *d, struct grant_table *gt)
     gt->nr_status_frames = 0;
 }
 
+/* Grow the grant table. The caller must hold the grant table's
+ * write lock before calling this function.
+ */
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
 {
-    /* d's grant table lock must be held by the caller */
+    /* d's grant table write lock must be held by the caller */
 
     struct grant_table *gt = d->grant_table;
     unsigned int i;
@@ -1392,7 +1397,7 @@ gnttab_setup_table(
     }
 
     gt = d->grant_table;
-    spin_lock(&gt->lock);
+    write_lock(&gt->lock);
 
     if ( gt->gt_version == 0 )
         gt->gt_version = 1;
@@ -1420,7 +1425,7 @@ gnttab_setup_table(
     }
 
  out3:
-    spin_unlock(&gt->lock);
+    write_unlock(&gt->lock);
  out2:
     rcu_unlock_domain(d);
  out1:
@@ -1462,13 +1467,13 @@ gnttab_query_size(
         goto query_out_unlock;
     }
 
-    spin_lock(&d->grant_table->lock);
+    read_lock(&d->grant_table->lock);
 
     op.nr_frames     = nr_grant_frames(d->grant_table);
     op.max_nr_frames = max_grant_frames;
     op.status        = GNTST_okay;
 
-    spin_unlock(&d->grant_table->lock);
+    read_unlock(&d->grant_table->lock);
 
  
  query_out_unlock:
@@ -1494,7 +1499,7 @@ gnttab_prepare_for_transfer(
     union grant_combo   scombo, prev_scombo, new_scombo;
     int                 retries = 0;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
     {
@@ -1545,11 +1550,11 @@ gnttab_prepare_for_transfer(
         scombo = prev_scombo;
     }
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return 1;
 
  fail:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return 0;
 }
 
@@ -1741,7 +1746,7 @@ gnttab_transfer(
         TRACE_1D(TRC_MEM_PAGE_GRANT_TRANSFER, e->domain_id);
 
         /* Tell the guest about its new page frame. */
-        spin_lock(&e->grant_table->lock);
+        read_lock(&e->grant_table->lock);
 
         if ( e->grant_table->gt_version == 1 )
         {
@@ -1759,7 +1764,7 @@ gnttab_transfer(
         shared_entry_header(e->grant_table, gop.ref)->flags |=
             GTF_transfer_completed;
 
-        spin_unlock(&e->grant_table->lock);
+        read_unlock(&e->grant_table->lock);
 
         rcu_unlock_domain(e);
 
@@ -1797,7 +1802,7 @@ __release_grant_for_copy(
     released_read = 0;
     released_write = 0;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     act = &active_entry(rgt, gref);
     sha = shared_entry_header(rgt, gref);
@@ -1838,7 +1843,7 @@ __release_grant_for_copy(
         released_read = 1;
     }
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
 
     if ( td != rd )
     {
@@ -1896,7 +1901,7 @@ __acquire_grant_for_copy(
 
     *page = NULL;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
         PIN_FAIL(unlock_out, GNTST_general_error,
@@ -1965,17 +1970,21 @@ __acquire_grant_for_copy(
                 PIN_FAIL(unlock_out_clear, GNTST_general_error,
                          "transitive grant referenced bad domain %d\n",
                          trans_domid);
-            spin_unlock(&rgt->lock);
+
+            /* __acquire_grant_for_copy() could take the read lock on
+             * the right table (if rd == td), so we have to drop the
+             * lock here and reacquire */
+            read_unlock(&rgt->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd->domain_id,
                                           readonly, &grant_frame, page,
                                           &trans_page_off, &trans_length, 0);
 
-            spin_lock(&rgt->lock);
+            read_lock(&rgt->lock);
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_copy_pin(act, status);
+                read_unlock(&rgt->lock);
                 rcu_unlock_domain(td);
-                spin_unlock(&rgt->lock);
                 return rc;
             }
 
@@ -1987,7 +1996,7 @@ __acquire_grant_for_copy(
             {
                 __fixup_status_for_copy_pin(act, status);
                 rcu_unlock_domain(td);
-                spin_unlock(&rgt->lock);
+                read_unlock(&rgt->lock);
                 put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ldom, readonly,
                                                 frame, page, page_off, length,
@@ -2055,7 +2064,7 @@ __acquire_grant_for_copy(
     *length = act->length;
     *frame = act->frame;
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return rc;
  
  unlock_out_clear:
@@ -2067,7 +2076,7 @@ __acquire_grant_for_copy(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return rc;
 }
 
@@ -2241,7 +2250,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     if ( gt->gt_version == op.version )
         goto out;
 
-    spin_lock(&gt->lock);
+    write_lock(&gt->lock);
     /* Make sure that the grant table isn't currently in use when we
        change the version number, except for the first 8 entries which
        are allowed to be in use (xenstore/xenconsole keeps them mapped).
@@ -2327,7 +2336,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     gt->gt_version = op.version;
 
 out_unlock:
-    spin_unlock(&gt->lock);
+    write_unlock(&gt->lock);
 
 out:
     op.version = gt->gt_version;
@@ -2383,7 +2392,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
 
     op.status = GNTST_okay;
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     for ( i = 0; i < op.nr_frames; i++ )
     {
@@ -2392,7 +2401,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
             op.status = GNTST_bad_virt_addr;
     }
 
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 out2:
     rcu_unlock_domain(d);
 out1:
@@ -2441,7 +2450,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     struct active_grant_entry *act;
     s16 rc = GNTST_okay;
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     /* Bounds check on the grant refs */
     if ( unlikely(ref_a >= nr_grant_entries(d->grant_table)))
@@ -2481,7 +2490,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     }
 
 out:
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 
     rcu_unlock_domain(d);
 
@@ -2552,12 +2561,12 @@ static int __gnttab_cache_flush(gnttab_cache_flush_t *cflush,
 
     if ( d != owner )
     {
-        spin_lock(&owner->grant_table->lock);
+        read_lock(&owner->grant_table->lock);
 
         ret = grant_map_exists(d, owner->grant_table, mfn, ref_count);
         if ( ret != 0 )
         {
-            spin_unlock(&owner->grant_table->lock);
+            read_unlock(&owner->grant_table->lock);
             rcu_unlock_domain(d);
             put_page(page);
             return ret;
@@ -2577,7 +2586,7 @@ static int __gnttab_cache_flush(gnttab_cache_flush_t *cflush,
         ret = 0;
 
     if ( d != owner )
-        spin_unlock(&owner->grant_table->lock);
+        read_unlock(&owner->grant_table->lock);
     unmap_domain_page(v);
     put_page(page);
 
@@ -2793,7 +2802,8 @@ grant_table_create(
         goto no_mem_0;
 
     /* Simple stuff. */
-    spin_lock_init(&t->lock);
+    rwlock_init(&t->lock);
+    spin_lock_init(&t->maptrack_lock);
     t->nr_grant_frames = INITIAL_NR_GRANT_FRAMES;
 
     /* Active grant table. */
@@ -2900,7 +2910,7 @@ gnttab_release_mappings(
         }
 
         rgt = rd->grant_table;
-        spin_lock(&rgt->lock);
+        read_lock(&rgt->lock);
 
         act = &active_entry(rgt, ref);
         sha = shared_entry_header(rgt, ref);
@@ -2960,7 +2970,7 @@ gnttab_release_mappings(
         if ( act->pin == 0 )
             gnttab_clear_flag(_GTF_reading, status);
 
-        spin_unlock(&rgt->lock);
+        read_unlock(&rgt->lock);
 
         rcu_unlock_domain(rd);
 
@@ -2978,6 +2988,8 @@ grant_table_destroy(
 
     if ( t == NULL )
         return;
+
+    write_lock(&t->lock);
     
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
@@ -2995,6 +3007,8 @@ grant_table_destroy(
         free_xenheap_page(t->status[i]);
     xfree(t->status);
 
+    write_unlock(&t->lock);
+
     xfree(t);
     d->grant_table = NULL;
 }
@@ -3008,7 +3022,7 @@ static void gnttab_usage_print(struct domain *rd)
     printk("      -------- active --------       -------- shared --------\n");
     printk("[ref] localdom mfn      pin          localdom gmfn     flags\n");
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     if ( gt->gt_version == 0 )
         goto out;
@@ -3057,7 +3071,7 @@ static void gnttab_usage_print(struct domain *rd)
     }
 
  out:
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 
     if ( first )
         printk("grant-table for remote domain:%5d ... "
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 32f5786..ca49b41 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -82,8 +82,11 @@ struct grant_table {
     struct grant_mapping **maptrack;
     unsigned int          maptrack_head;
     unsigned int          maptrack_limit;
-    /* Lock protecting updates to active and shared grant tables. */
-    spinlock_t            lock;
+    /* Lock protecting the maptrack page list, head, and limit */
+    spinlock_t            maptrack_lock;
+    /* Lock protecting updates to grant table state (version, active
+       entry list, etc.) */
+    rwlock_t              lock;
     /* The defined versions are 1 and 2.  Set to 0 if we don't know
        what version to use yet. */
     unsigned              gt_version;
@@ -101,7 +104,7 @@ gnttab_release_mappings(
     struct domain *d);
 
 /* Increase the size of a domain's grant table.
- * Caller must hold d's grant table lock.
+ * Caller must hold d's grant table write lock.
  */
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames);
-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 14:30:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 14: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 1XwAwK-0005zY-PS; Wed, 03 Dec 2014 14:30:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40726a7d2=chegger@amazon.de>)
	id 1XwAwK-0005zD-0m
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 14:30:00 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	A6/92-02953-76E1F745; Wed, 03 Dec 2014 14:29:59 +0000
X-Env-Sender: prvs=40726a7d2=chegger@amazon.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417616995!12724989!1
X-Originating-IP: [207.171.189.228]
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 5395 invoked from network); 3 Dec 2014 14:29:57 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 14:29:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417616997; x=1449152997;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version;
	bh=KZa56xh6qWp80nyzLyFZwYC5xCbzbZBulyb5nfZzdxs=;
	b=DFtKqRQ4KF5avykVI+JupQtEsSyyBaCx5xPNDcauaSe5btWBPgTBCboc
	9Hjl4aLX59plM4q/GvzMtzee5Cru2wI9z61JLw7l1FCCOQEP9H4OI2X2O
	vfliyJW9C9T6zt1+/UP6CNtlFmh5VOUAXV1hnQUz+bt7wDBBFWLPRsfNQ A=;
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="147250227"
Received: from email-inbound-relay-6001.iad6.amazon.com ([10.128.255.172])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2014 14:29:54 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com
	[10.0.103.146])
	by email-inbound-relay-6001.iad6.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB3ETpfm016253
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 14:29:52 GMT
Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Wed, 3 Dec 2014 06:29:50 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.160.14) by
	EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Wed, 3 Dec 2014 06:29:47 -0800
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Wed, 3 Dec 2014 15:29:27 +0100
Message-ID: <1417616967-18720-3-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1417616967-18720-1-git-send-email-chegger@amazon.de>
References: <1417616967-18720-1-git-send-email-chegger@amazon.de>
MIME-Version: 1.0
X-Originating-IP: [10.43.160.14]
X-ClientProxiedBy: EX13D03UWA003.ant.amazon.com (10.43.160.39) To
	EX13D03UWA003.ant.amazon.com (10.43.160.39)
Precedence: Bulk
Cc: Jan Beulich <jbeulich@suse.com>, Christoph Egger <chegger@amazon.de>,
	Keir Fraser <keir@xen.org>, Anthony Liguori <aliguori@amazon.com>,
	Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH v3 2/2] gnttab: refactor locking for scalability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Matt Wilson <msw@amazon.com>

This patch refactors grant table locking. It splits the previous
single spinlock per grant table into multiple locks. The heavily
modified components of the grant table (the maptrack state and the
active entries) are now protected by their own spinlocks. The
remaining elements of the grant table are read-mostly, so the main
grant table lock is modified to be a rwlock to improve concurrency.

Workloads with high grant table operation rates, especially map/unmap
operations as used by blkback/blkfront when persistent grants are not
supported, show marked improvement with these changes. A domU with 24
VBDs in a streaming 2M write workload achieved 1,400 MB/sec before
this change. Performance more than doubles with this patch, reaching
3,000 MB/sec before tuning and 3,600 MB/sec after adjusting event
channel vCPU bindings.

Signed-off-by: Matt Wilson <msw@amazon.com>
[chegger: ported to xen-staging, split into multiple commits]

v3:
  * Addressed gnttab_swap_grant_ref() comment from Andrew Cooper

Signed-off-by: Christoph Egger <chegger@amazon.de>
Cc: Anthony Liguori <aliguori@amazon.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
---
 docs/misc/grant-tables.txt |   21 +++++
 xen/common/grant_table.c   |  219 ++++++++++++++++++++++++++++----------------
 2 files changed, 163 insertions(+), 77 deletions(-)

diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt
index c9ae8f2..1ada018 100644
--- a/docs/misc/grant-tables.txt
+++ b/docs/misc/grant-tables.txt
@@ -63,6 +63,7 @@ is complete.
   act->domid : remote domain being granted rights
   act->frame : machine frame being granted
   act->pin   : used to hold reference counts
+  act->lock  : spinlock used to serialize access to active entry state
 
  Map tracking
  ~~~~~~~~~~~~
@@ -87,6 +88,8 @@ is complete.
                                version, partially initialized active table pages,
                                etc.
   grant_table->maptrack_lock : spinlock used to protect the maptrack state
+  active_grant_entry->lock   : spinlock used to serialize modifications to
+                               active entries
 
  The primary lock for the grant table is a read/write spinlock. All
  functions that access members of struct grant_table must acquire a
@@ -102,6 +105,24 @@ is complete.
  state can be rapidly modified under some workloads, and the critical
  sections are very small, thus we use a spinlock to protect them.
 
+ Active entries are obtained by calling active_entry_acquire(gt, ref).
+ This function returns a pointer to the active entry after locking its
+ spinlock. The caller must hold the rwlock for the gt in question
+ before calling active_entry_acquire(). This is because the grant
+ table can be dynamically extended via gnttab_grow_table() while a
+ domain is running and must be fully initialized. Once all access to
+ the active entry is complete, release the lock by calling
+ active_entry_release(act).
+
+ Summary of rules for locking:
+  active_entry_acquire() and active_entry_release() can only be
+  called when holding the relevant grant table's lock. I.e.:
+    read_lock(&gt->lock);
+    act = active_entry_acquire(gt, ref);
+    ...
+    active_entry_release(act);
+    read_unlock(&gt->lock);
+
 ********************************************************************************
 
  Granting a foreign domain access to frames
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 24feb65..5601863 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -151,10 +151,13 @@ struct active_grant_entry {
                                in the page.                           */
     unsigned      length:16; /* For sub-page grants, the length of the
                                 grant.                                */
+    spinlock_t    lock;      /* lock to protect access of this entry.
+                                see docs/misc/grant-tables.txt for
+                                locking protocol                      */
 };
 
 #define ACGNT_PER_PAGE (PAGE_SIZE / sizeof(struct active_grant_entry))
-#define active_entry(t, e) \
+#define _active_entry(t, e) \
     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
 
 static inline void gnttab_flush_tlb(const struct domain *d)
@@ -182,6 +185,29 @@ nr_active_grant_frames(struct grant_table *gt)
     return num_act_frames_from_sha_frames(nr_grant_frames(gt));
 }
 
+static inline struct active_grant_entry *
+active_entry_acquire(struct grant_table *t, grant_ref_t e)
+{
+    struct active_grant_entry *act;
+
+#ifndef NDEBUG
+    /* not perfect, but better than nothing for a debug build
+     * sanity check
+     */
+    BUG_ON(!rw_is_locked(&t->lock));
+#endif
+
+    act = &_active_entry(t, e);
+    spin_lock(&act->lock);
+
+    return act;
+}
+
+static inline void active_entry_release(struct active_grant_entry *act)
+{
+    spin_unlock(&act->lock);
+}
+    
 /* Check if the page has been paged out, or needs unsharing. 
    If rc == GNTST_okay, *page contains the page struct with a ref taken.
    Caller must do put_page(*page).
@@ -222,30 +248,6 @@ static int __get_paged_frame(unsigned long gfn, unsigned long *frame, struct pag
     return rc;
 }
 
-static inline void
-double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
-{
-    if ( lgt < rgt )
-    {
-        spin_lock(&lgt->maptrack_lock);
-        spin_lock(&rgt->maptrack_lock);
-    }
-    else
-    {
-        if ( lgt != rgt )
-            spin_lock(&rgt->maptrack_lock);
-        spin_lock(&lgt->maptrack_lock);
-    }
-}
-
-static inline void
-double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
-{
-    spin_unlock(&lgt->maptrack_lock);
-    if ( lgt != rgt )
-        spin_unlock(&rgt->maptrack_lock);
-}
-
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -310,7 +312,8 @@ get_maptrack_handle(
     return handle;
 }
 
-/* Number of grant table entries. Caller must hold d's grant table lock. */
+/* Number of grant table entries. Caller must hold d's grant table
+   read lock. */
 static unsigned int nr_grant_entries(struct grant_table *gt)
 {
     ASSERT(gt->gt_version != 0);
@@ -499,7 +502,7 @@ static int grant_map_exists(const struct domain *ld,
                             unsigned long mfn,
                             unsigned int *ref_count)
 {
-    const struct active_grant_entry *act;
+    struct active_grant_entry *act;
     unsigned int ref, max_iter;
     
     ASSERT(rw_is_locked(&rgt->lock));
@@ -508,17 +511,27 @@ static int grant_map_exists(const struct domain *ld,
                    nr_grant_entries(rgt));
     for ( ref = *ref_count; ref < max_iter; ref++ )
     {
-        act = &active_entry(rgt, ref);
+        act = active_entry_acquire(rgt, ref);
 
         if ( !act->pin )
+        {
+            active_entry_release(act);
             continue;
+        }
 
         if ( act->domid != ld->domain_id )
+        {
+            active_entry_release(act);
             continue;
+        }
 
         if ( act->frame != mfn )
+        {
+            active_entry_release(act);
             continue;
+        }
 
+        active_entry_release(act);
         return 0;
     }
 
@@ -531,24 +544,44 @@ static int grant_map_exists(const struct domain *ld,
     return -EINVAL;
 }
 
+/* Count the number of mapped ro or rw entries tracked in the left
+ * grant table given a provided mfn provided by a foreign domain. 
+ *
+ * This function takes the maptrack lock from the left grant table and
+ * must be called with the right grant table's rwlock held.
+ */
 static void mapcount(
     struct grant_table *lgt, struct domain *rd, unsigned long mfn,
     unsigned int *wrc, unsigned int *rdc)
 {
     struct grant_mapping *map;
     grant_handle_t handle;
+    struct active_grant_entry *act;
 
     *wrc = *rdc = 0;
 
+    /* N.B.: while taking the left side maptrack spinlock prevents
+     * any mapping changes, the right side active entries could be
+     * changing while we are counting. To be perfectly correct, the
+     * caller should hold the grant table write lock, or some other
+     * mechanism should be used to prevent concurrent changes during
+     * this operation. This is tricky because we can't promote a read
+     * lock into a write lock.
+     */
+    spin_lock(&lgt->maptrack_lock);
+
     for ( handle = 0; handle < lgt->maptrack_limit; handle++ )
     {
         map = &maptrack_entry(lgt, handle);
         if ( !(map->flags & (GNTMAP_device_map|GNTMAP_host_map)) ||
              map->domid != rd->domain_id )
             continue;
-        if ( active_entry(rd->grant_table, map->ref).frame == mfn )
+        act = &_active_entry(rd->grant_table, map->ref);
+        if ( act->frame == mfn )
             (map->flags & GNTMAP_readonly) ? (*rdc)++ : (*wrc)++;
     }
+
+    spin_unlock(&lgt->maptrack_lock);
 }
 
 /*
@@ -570,7 +603,6 @@ __gnttab_map_grant_ref(
     struct page_info *pg = NULL;
     int            rc = GNTST_okay;
     u32            old_pin;
-    u32            act_pin;
     unsigned int   cache_flags;
     struct active_grant_entry *act = NULL;
     struct grant_mapping *mt;
@@ -633,7 +665,7 @@ __gnttab_map_grant_ref(
     if ( unlikely(op->ref >= nr_grant_entries(rgt)))
         PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref (%d).\n", op->ref);
 
-    act = &active_entry(rgt, op->ref);
+    act = active_entry_acquire(rgt, op->ref);
     shah = shared_entry_header(rgt, op->ref);
     if (rgt->gt_version == 1) {
         sha1 = &shared_entry_v1(rgt, op->ref);
@@ -650,7 +682,7 @@ __gnttab_map_grant_ref(
          ((act->domid != ld->domain_id) ||
           (act->pin & 0x80808080U) != 0 ||
           (act->is_sub_page)) )
-        PIN_FAIL(unlock_out, GNTST_general_error,
+        PIN_FAIL(act_release_out, GNTST_general_error,
                  "Bad domain (%d != %d), or risk of counter overflow %08x, or subpage %d\n",
                  act->domid, ld->domain_id, act->pin, act->is_sub_page);
 
@@ -661,7 +693,7 @@ __gnttab_map_grant_ref(
         if ( (rc = _set_status(rgt->gt_version, ld->domain_id,
                                op->flags & GNTMAP_readonly,
                                1, shah, act, status) ) != GNTST_okay )
-             goto unlock_out;
+            goto act_release_out;
 
         if ( !act->pin )
         {
@@ -692,12 +724,9 @@ __gnttab_map_grant_ref(
             GNTPIN_hstr_inc : GNTPIN_hstw_inc;
 
     frame = act->frame;
-    act_pin = act->pin;
 
     cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
-    read_unlock(&rgt->lock);
-
     /* pg may be set, with a refcount included, from __get_paged_frame */
     if ( !pg )
     {
@@ -772,8 +801,6 @@ __gnttab_map_grant_ref(
         goto undo_out;
     }
 
-    double_gt_lock(lgt, rgt);
-
     if ( gnttab_need_iommu_mapping(ld) )
     {
         unsigned int wrc, rdc;
@@ -781,21 +808,20 @@ __gnttab_map_grant_ref(
         /* We're not translated, so we know that gmfns and mfns are
            the same things, so the IOMMU entry is always 1-to-1. */
         mapcount(lgt, rd, frame, &wrc, &rdc);
-        if ( (act_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
+        if ( (act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
              !(old_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
         {
             if ( wrc == 0 )
                 err = iommu_map_page(ld, frame, frame,
                                      IOMMUF_readable|IOMMUF_writable);
         }
-        else if ( act_pin && !old_pin )
+        else if ( act->pin && !old_pin )
         {
             if ( (wrc + rdc) == 0 )
                 err = iommu_map_page(ld, frame, frame, IOMMUF_readable);
         }
         if ( err )
         {
-            double_gt_unlock(lgt, rgt);
             rc = GNTST_general_error;
             goto undo_out;
         }
@@ -808,7 +834,8 @@ __gnttab_map_grant_ref(
     mt->ref   = op->ref;
     mt->flags = op->flags;
 
-    double_gt_unlock(lgt, rgt);
+    active_entry_release(act);
+    read_unlock(&rgt->lock);
 
     op->dev_bus_addr = (u64)frame << PAGE_SHIFT;
     op->handle       = handle;
@@ -831,10 +858,6 @@ __gnttab_map_grant_ref(
         put_page(pg);
     }
 
-    read_lock(&rgt->lock);
-
-    act = &active_entry(rgt, op->ref);
-
     if ( op->flags & GNTMAP_device_map )
         act->pin -= (op->flags & GNTMAP_readonly) ?
             GNTPIN_devr_inc : GNTPIN_devw_inc;
@@ -850,6 +873,9 @@ __gnttab_map_grant_ref(
     if ( !act->pin )
         gnttab_clear_flag(_GTF_reading, status);
 
+ act_release_out:
+    active_entry_release(act);
+
  unlock_out:
     read_unlock(&rgt->lock);
     op->status = rc;
@@ -891,9 +917,9 @@ __gnttab_unmap_common(
     ld = current->domain;
     lgt = ld->grant_table;
 
-    read_lock(&lgt->lock);
     op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
 
+    read_lock(&lgt->lock);
     if ( unlikely(op->handle >= lgt->maptrack_limit) )
     {
         read_unlock(&lgt->lock);
@@ -933,19 +959,18 @@ __gnttab_unmap_common(
     TRACE_1D(TRC_MEM_PAGE_GRANT_UNMAP, dom);
 
     rgt = rd->grant_table;
-    double_gt_lock(lgt, rgt);
 
     op->flags = op->map->flags;
     if ( unlikely(!op->flags) || unlikely(op->map->domid != dom) )
     {
         gdprintk(XENLOG_WARNING, "Unstable handle %u\n", op->handle);
         rc = GNTST_bad_handle;
-        goto unmap_out;
+        goto unlock_out;
     }
 
     op->rd = rd;
     read_lock(&rgt->lock);
-    act = &active_entry(rgt, op->map->ref);
+    act = active_entry_acquire(rgt, op->map->ref);
 
     if ( op->frame == 0 )
     {
@@ -954,7 +979,7 @@ __gnttab_unmap_common(
     else
     {
         if ( unlikely(op->frame != act->frame) )
-            PIN_FAIL(unmap_out, GNTST_general_error,
+            PIN_FAIL(act_release_out, GNTST_general_error,
                      "Bad frame number doesn't match gntref. (%lx != %lx)\n",
                      op->frame, act->frame);
         if ( op->flags & GNTMAP_device_map )
@@ -973,7 +998,7 @@ __gnttab_unmap_common(
         if ( (rc = replace_grant_host_mapping(op->host_addr,
                                               op->frame, op->new_addr, 
                                               op->flags)) < 0 )
-            goto unmap_out;
+            goto act_release_out;
 
         ASSERT(act->pin & (GNTPIN_hstw_mask | GNTPIN_hstr_mask));
         op->map->flags &= ~GNTMAP_host_map;
@@ -995,7 +1020,7 @@ __gnttab_unmap_common(
         if ( err )
         {
             rc = GNTST_general_error;
-            goto unmap_out;
+            goto act_release_out;
         }
     }
 
@@ -1003,9 +1028,11 @@ __gnttab_unmap_common(
     if ( !(op->flags & GNTMAP_readonly) )
          gnttab_mark_dirty(rd, op->frame);
 
- unmap_out:
-    double_gt_unlock(lgt, rgt);
+ act_release_out:
+    active_entry_release(act);
     read_unlock(&rgt->lock);
+
+ unlock_out:
     op->status = rc;
     rcu_unlock_domain(rd);
 }
@@ -1038,9 +1065,9 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
 
     read_lock(&rgt->lock);
     if ( rgt->gt_version == 0 )
-        goto unmap_out;
+        goto unlock_out;
 
-    act = &active_entry(rgt, op->map->ref);
+    act = active_entry_acquire(rgt, op->map->ref);
     sha = shared_entry_header(rgt, op->map->ref);
 
     if ( rgt->gt_version == 1 )
@@ -1054,7 +1081,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
          * Suggests that __gntab_unmap_common failed early and so
          * nothing further to do
          */
-        goto unmap_out;
+        goto act_release_out;
     }
 
     pg = mfn_to_page(op->frame);
@@ -1078,7 +1105,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
              * Suggests that __gntab_unmap_common failed in
              * replace_grant_host_mapping() so nothing further to do
              */
-            goto unmap_out;
+            goto act_release_out;
         }
 
         if ( !is_iomem_page(op->frame) ) 
@@ -1099,8 +1126,12 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
     if ( act->pin == 0 )
         gnttab_clear_flag(_GTF_reading, status);
 
- unmap_out:
+ act_release_out:
+    active_entry_release(act);
+    
+ unlock_out:
     read_unlock(&rgt->lock);
+
     if ( put_handle )
     {
         op->map->flags = 0;
@@ -1295,7 +1326,7 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
     /* d's grant table write lock must be held by the caller */
 
     struct grant_table *gt = d->grant_table;
-    unsigned int i;
+    unsigned int i, j;
 
     ASSERT(req_nr_frames <= max_grant_frames);
 
@@ -1310,6 +1341,10 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
         if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
             goto active_alloc_failed;
         clear_page(gt->active[i]);
+        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+        {
+            spin_lock_init(&gt->active[i][j].lock);
+        }
     }
 
     /* Shared */
@@ -1804,7 +1839,7 @@ __release_grant_for_copy(
 
     read_lock(&rgt->lock);
 
-    act = &active_entry(rgt, gref);
+    act = active_entry_acquire(rgt, gref);
     sha = shared_entry_header(rgt, gref);
     r_frame = act->frame;
 
@@ -1843,6 +1878,7 @@ __release_grant_for_copy(
         released_read = 1;
     }
 
+    active_entry_release(act);
     read_unlock(&rgt->lock);
 
     if ( td != rd )
@@ -1904,14 +1940,14 @@ __acquire_grant_for_copy(
     read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
-        PIN_FAIL(unlock_out, GNTST_general_error,
+        PIN_FAIL(gnt_unlock_out, GNTST_general_error,
                  "remote grant table not ready\n");
 
     if ( unlikely(gref >= nr_grant_entries(rgt)) )
-        PIN_FAIL(unlock_out, GNTST_bad_gntref,
+        PIN_FAIL(gnt_unlock_out, GNTST_bad_gntref,
                  "Bad grant reference %ld\n", gref);
 
-    act = &active_entry(rgt, gref);
+    act = active_entry_acquire(rgt, gref);
     shah = shared_entry_header(rgt, gref);
     if ( rgt->gt_version == 1 )
     {
@@ -1974,6 +2010,7 @@ __acquire_grant_for_copy(
             /* __acquire_grant_for_copy() could take the read lock on
              * the right table (if rd == td), so we have to drop the
              * lock here and reacquire */
+            active_entry_release(act);
             read_unlock(&rgt->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd->domain_id,
@@ -1981,8 +2018,11 @@ __acquire_grant_for_copy(
                                           &trans_page_off, &trans_length, 0);
 
             read_lock(&rgt->lock);
+            act = active_entry_acquire(rgt, gref);
+
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_copy_pin(act, status);
+                active_entry_release(act);
                 read_unlock(&rgt->lock);
                 rcu_unlock_domain(td);
                 return rc;
@@ -1996,6 +2036,7 @@ __acquire_grant_for_copy(
             {
                 __fixup_status_for_copy_pin(act, status);
                 rcu_unlock_domain(td);
+                active_entry_release(act);
                 read_unlock(&rgt->lock);
                 put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ldom, readonly,
@@ -2064,6 +2105,7 @@ __acquire_grant_for_copy(
     *length = act->length;
     *frame = act->frame;
 
+    active_entry_release(act);
     read_unlock(&rgt->lock);
     return rc;
  
@@ -2076,6 +2118,9 @@ __acquire_grant_for_copy(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
+    active_entry_release(act);
+
+ gnt_unlock_out:
     read_unlock(&rgt->lock);
     return rc;
 }
@@ -2259,16 +2304,18 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     {
         for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
-            act = &active_entry(gt, i);
+            act = active_entry_acquire(gt, i);
             if ( act->pin != 0 )
             {
                 gdprintk(XENLOG_WARNING,
                          "tried to change grant table version from %d to %d, but some grant entries still in use\n",
                          gt->gt_version,
                          op.version);
+                active_entry_release(act);
                 res = -EBUSY;
                 goto out_unlock;
             }
+            active_entry_release(act);
         }
     }
 
@@ -2447,9 +2494,16 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
 {
     struct domain *d = rcu_lock_current_domain();
     struct grant_table *gt = d->grant_table;
-    struct active_grant_entry *act;
+    struct active_grant_entry *act_a = NULL;
+    struct active_grant_entry *act_b = NULL;
     s16 rc = GNTST_okay;
 
+    if ( ref_a == ref_b )
+        /* noop, so avoid acquiring the same active entry
+         * twice which would case a deadlock.
+         */
+        return rc;
+
     read_lock(&gt->lock);
 
     /* Bounds check on the grant refs */
@@ -2458,12 +2512,12 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     if ( unlikely(ref_b >= nr_grant_entries(d->grant_table)))
         PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-b (%d).\n", ref_b);
 
-    act = &active_entry(gt, ref_a);
-    if ( act->pin )
+    act_a = active_entry_acquire(gt, ref_a);
+    if ( act_a->pin )
         PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
 
-    act = &active_entry(gt, ref_b);
-    if ( act->pin )
+    act_b = active_entry_acquire(gt, ref_b);
+    if ( act_b->pin )
         PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
 
     if ( gt->gt_version == 1 )
@@ -2490,8 +2544,11 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     }
 
 out:
+    if ( act_b != NULL )
+        active_entry_release(act_b);
+    if ( act_a != NULL )
+        active_entry_release(act_a);
     read_unlock(&gt->lock);
-
     rcu_unlock_domain(d);
 
     return rc;
@@ -2796,7 +2853,7 @@ grant_table_create(
     struct domain *d)
 {
     struct grant_table *t;
-    int                 i;
+    int                 i, j;
 
     if ( (t = xzalloc(struct grant_table)) == NULL )
         goto no_mem_0;
@@ -2816,6 +2873,10 @@ grant_table_create(
         if ( (t->active[i] = alloc_xenheap_page()) == NULL )
             goto no_mem_2;
         clear_page(t->active[i]);
+        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+        {
+            spin_lock_init(&t->active[i][j].lock);
+        }
     }
 
     /* Tracking of mapped foreign frames table */
@@ -2912,7 +2973,7 @@ gnttab_release_mappings(
         rgt = rd->grant_table;
         read_lock(&rgt->lock);
 
-        act = &active_entry(rgt, ref);
+        act = active_entry_acquire(rgt, ref);
         sha = shared_entry_header(rgt, ref);
         if (rgt->gt_version == 1)
             status = &sha->flags;
@@ -2970,6 +3031,7 @@ gnttab_release_mappings(
         if ( act->pin == 0 )
             gnttab_clear_flag(_GTF_reading, status);
 
+        active_entry_release(act);
         read_unlock(&rgt->lock);
 
         rcu_unlock_domain(rd);
@@ -2990,7 +3052,7 @@ grant_table_destroy(
         return;
 
     write_lock(&t->lock);
-    
+
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
     xfree(t->shared_raw);
@@ -3036,9 +3098,11 @@ static void gnttab_usage_print(struct domain *rd)
         uint16_t status;
         uint64_t frame;
 
-        act = &active_entry(gt, ref);
-        if ( !act->pin )
+        act = active_entry_acquire(gt, ref);
+        if ( !act->pin ) {
+            active_entry_release(act);
             continue;
+        }
 
         sha = shared_entry_header(gt, ref);
 
@@ -3068,6 +3132,7 @@ static void gnttab_usage_print(struct domain *rd)
         printk("[%3d]    %5d 0x%06lx 0x%08x      %5d 0x%06"PRIx64" 0x%02x\n",
                ref, act->domid, act->frame, act->pin,
                sha->domid, frame, status);
+        active_entry_release(act);
     }
 
  out:
-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 14:30:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 14: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 1XwAwD-0005xm-04; Wed, 03 Dec 2014 14:29:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40726a7d2=chegger@amazon.de>)
	id 1XwAwB-0005xQ-0t
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 14:29:51 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	06/CE-02698-E5E1F745; Wed, 03 Dec 2014 14:29:50 +0000
X-Env-Sender: prvs=40726a7d2=chegger@amazon.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417616988!12745227!1
X-Originating-IP: [207.171.178.25]
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 29487 invoked from network); 3 Dec 2014 14:29:49 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 14:29:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417616989; x=1449152989;
	h=from:to:cc:subject:date:message-id:mime-version;
	bh=ZQApBNgc7lakgfj/M47wMqOMEJvKnCZNk7tDJR0EQII=;
	b=r9ixw/EnMoaOiciBCeRKg57MNxaD3q4JR5rhua0OiNC4Z5Kdx8ffxblA
	KD4xA1TNdFrygq+ngOWPczySt2XWemPcUY9JeFIOSChH2RYQtCuB3M67A
	VgSZBQSGdFxR/M/6/O17JwZNN0yud2HODYFClpuWAwiafQKHpWmlwMcZf Q=;
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="175640602"
Received: from email-inbound-relay-7002.iad7.amazon.com ([10.55.235.150])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2014 14:29:47 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com
	[10.0.103.150])
	by email-inbound-relay-7002.iad7.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB3EThhM025627
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Wed, 3 Dec 2014 14:29:46 GMT
Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Wed, 3 Dec 2014 06:29:45 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.160.14) by
	EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Wed, 3 Dec 2014 06:29:43 -0800
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Wed, 3 Dec 2014 15:29:25 +0100
Message-ID: <1417616967-18720-1-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
X-Originating-IP: [10.43.160.14]
X-ClientProxiedBy: EX13D03UWA003.ant.amazon.com (10.43.160.39) To
	EX13D03UWA003.ant.amazon.com (10.43.160.39)
Precedence: Bulk
Cc: Christoph Egger <chegger@amazon.de>
Subject: [Xen-devel] [PATCH v3 0/2] gnttab: Improve scaleability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 changes the grant table locking to
a more fain grained locking protocol. The result is
a performance boost measured with blkfront/blkback.
Document the locking protocol.

v3:
  * Addressed gnttab_swap_grant_ref() comment from Andrew Cooper
v2:
  * Add arm part per request from Julien Grall

Christoph Egger (1):
  gnttab: Introduce rwlock to protect updates to grant table state

Matt Wilson (1):
  gnttab: refactor locking for scalability

 docs/misc/grant-tables.txt    |   49 ++++++-
 xen/arch/arm/mm.c             |    4 +-
 xen/arch/x86/mm.c             |    4 +-
 xen/common/grant_table.c      |  321 +++++++++++++++++++++++++----------------
 xen/include/xen/grant_table.h |    9 +-
 5 files changed, 258 insertions(+), 129 deletions(-)

-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 14:30:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 14: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 1XwAwK-0005zY-PS; Wed, 03 Dec 2014 14:30:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40726a7d2=chegger@amazon.de>)
	id 1XwAwK-0005zD-0m
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 14:30:00 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	A6/92-02953-76E1F745; Wed, 03 Dec 2014 14:29:59 +0000
X-Env-Sender: prvs=40726a7d2=chegger@amazon.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417616995!12724989!1
X-Originating-IP: [207.171.189.228]
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 5395 invoked from network); 3 Dec 2014 14:29:57 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 14:29:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417616997; x=1449152997;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version;
	bh=KZa56xh6qWp80nyzLyFZwYC5xCbzbZBulyb5nfZzdxs=;
	b=DFtKqRQ4KF5avykVI+JupQtEsSyyBaCx5xPNDcauaSe5btWBPgTBCboc
	9Hjl4aLX59plM4q/GvzMtzee5Cru2wI9z61JLw7l1FCCOQEP9H4OI2X2O
	vfliyJW9C9T6zt1+/UP6CNtlFmh5VOUAXV1hnQUz+bt7wDBBFWLPRsfNQ A=;
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="147250227"
Received: from email-inbound-relay-6001.iad6.amazon.com ([10.128.255.172])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2014 14:29:54 +0000
Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com
	[10.0.103.146])
	by email-inbound-relay-6001.iad6.amazon.com (8.14.7/8.14.7) with ESMTP
	id sB3ETpfm016253
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 14:29:52 GMT
Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by
	ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Wed, 3 Dec 2014 06:29:50 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.160.14) by
	EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Wed, 3 Dec 2014 06:29:47 -0800
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Wed, 3 Dec 2014 15:29:27 +0100
Message-ID: <1417616967-18720-3-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1417616967-18720-1-git-send-email-chegger@amazon.de>
References: <1417616967-18720-1-git-send-email-chegger@amazon.de>
MIME-Version: 1.0
X-Originating-IP: [10.43.160.14]
X-ClientProxiedBy: EX13D03UWA003.ant.amazon.com (10.43.160.39) To
	EX13D03UWA003.ant.amazon.com (10.43.160.39)
Precedence: Bulk
Cc: Jan Beulich <jbeulich@suse.com>, Christoph Egger <chegger@amazon.de>,
	Keir Fraser <keir@xen.org>, Anthony Liguori <aliguori@amazon.com>,
	Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH v3 2/2] gnttab: refactor locking for scalability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Matt Wilson <msw@amazon.com>

This patch refactors grant table locking. It splits the previous
single spinlock per grant table into multiple locks. The heavily
modified components of the grant table (the maptrack state and the
active entries) are now protected by their own spinlocks. The
remaining elements of the grant table are read-mostly, so the main
grant table lock is modified to be a rwlock to improve concurrency.

Workloads with high grant table operation rates, especially map/unmap
operations as used by blkback/blkfront when persistent grants are not
supported, show marked improvement with these changes. A domU with 24
VBDs in a streaming 2M write workload achieved 1,400 MB/sec before
this change. Performance more than doubles with this patch, reaching
3,000 MB/sec before tuning and 3,600 MB/sec after adjusting event
channel vCPU bindings.

Signed-off-by: Matt Wilson <msw@amazon.com>
[chegger: ported to xen-staging, split into multiple commits]

v3:
  * Addressed gnttab_swap_grant_ref() comment from Andrew Cooper

Signed-off-by: Christoph Egger <chegger@amazon.de>
Cc: Anthony Liguori <aliguori@amazon.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
---
 docs/misc/grant-tables.txt |   21 +++++
 xen/common/grant_table.c   |  219 ++++++++++++++++++++++++++++----------------
 2 files changed, 163 insertions(+), 77 deletions(-)

diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt
index c9ae8f2..1ada018 100644
--- a/docs/misc/grant-tables.txt
+++ b/docs/misc/grant-tables.txt
@@ -63,6 +63,7 @@ is complete.
   act->domid : remote domain being granted rights
   act->frame : machine frame being granted
   act->pin   : used to hold reference counts
+  act->lock  : spinlock used to serialize access to active entry state
 
  Map tracking
  ~~~~~~~~~~~~
@@ -87,6 +88,8 @@ is complete.
                                version, partially initialized active table pages,
                                etc.
   grant_table->maptrack_lock : spinlock used to protect the maptrack state
+  active_grant_entry->lock   : spinlock used to serialize modifications to
+                               active entries
 
  The primary lock for the grant table is a read/write spinlock. All
  functions that access members of struct grant_table must acquire a
@@ -102,6 +105,24 @@ is complete.
  state can be rapidly modified under some workloads, and the critical
  sections are very small, thus we use a spinlock to protect them.
 
+ Active entries are obtained by calling active_entry_acquire(gt, ref).
+ This function returns a pointer to the active entry after locking its
+ spinlock. The caller must hold the rwlock for the gt in question
+ before calling active_entry_acquire(). This is because the grant
+ table can be dynamically extended via gnttab_grow_table() while a
+ domain is running and must be fully initialized. Once all access to
+ the active entry is complete, release the lock by calling
+ active_entry_release(act).
+
+ Summary of rules for locking:
+  active_entry_acquire() and active_entry_release() can only be
+  called when holding the relevant grant table's lock. I.e.:
+    read_lock(&gt->lock);
+    act = active_entry_acquire(gt, ref);
+    ...
+    active_entry_release(act);
+    read_unlock(&gt->lock);
+
 ********************************************************************************
 
  Granting a foreign domain access to frames
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 24feb65..5601863 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -151,10 +151,13 @@ struct active_grant_entry {
                                in the page.                           */
     unsigned      length:16; /* For sub-page grants, the length of the
                                 grant.                                */
+    spinlock_t    lock;      /* lock to protect access of this entry.
+                                see docs/misc/grant-tables.txt for
+                                locking protocol                      */
 };
 
 #define ACGNT_PER_PAGE (PAGE_SIZE / sizeof(struct active_grant_entry))
-#define active_entry(t, e) \
+#define _active_entry(t, e) \
     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
 
 static inline void gnttab_flush_tlb(const struct domain *d)
@@ -182,6 +185,29 @@ nr_active_grant_frames(struct grant_table *gt)
     return num_act_frames_from_sha_frames(nr_grant_frames(gt));
 }
 
+static inline struct active_grant_entry *
+active_entry_acquire(struct grant_table *t, grant_ref_t e)
+{
+    struct active_grant_entry *act;
+
+#ifndef NDEBUG
+    /* not perfect, but better than nothing for a debug build
+     * sanity check
+     */
+    BUG_ON(!rw_is_locked(&t->lock));
+#endif
+
+    act = &_active_entry(t, e);
+    spin_lock(&act->lock);
+
+    return act;
+}
+
+static inline void active_entry_release(struct active_grant_entry *act)
+{
+    spin_unlock(&act->lock);
+}
+    
 /* Check if the page has been paged out, or needs unsharing. 
    If rc == GNTST_okay, *page contains the page struct with a ref taken.
    Caller must do put_page(*page).
@@ -222,30 +248,6 @@ static int __get_paged_frame(unsigned long gfn, unsigned long *frame, struct pag
     return rc;
 }
 
-static inline void
-double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
-{
-    if ( lgt < rgt )
-    {
-        spin_lock(&lgt->maptrack_lock);
-        spin_lock(&rgt->maptrack_lock);
-    }
-    else
-    {
-        if ( lgt != rgt )
-            spin_lock(&rgt->maptrack_lock);
-        spin_lock(&lgt->maptrack_lock);
-    }
-}
-
-static inline void
-double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
-{
-    spin_unlock(&lgt->maptrack_lock);
-    if ( lgt != rgt )
-        spin_unlock(&rgt->maptrack_lock);
-}
-
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -310,7 +312,8 @@ get_maptrack_handle(
     return handle;
 }
 
-/* Number of grant table entries. Caller must hold d's grant table lock. */
+/* Number of grant table entries. Caller must hold d's grant table
+   read lock. */
 static unsigned int nr_grant_entries(struct grant_table *gt)
 {
     ASSERT(gt->gt_version != 0);
@@ -499,7 +502,7 @@ static int grant_map_exists(const struct domain *ld,
                             unsigned long mfn,
                             unsigned int *ref_count)
 {
-    const struct active_grant_entry *act;
+    struct active_grant_entry *act;
     unsigned int ref, max_iter;
     
     ASSERT(rw_is_locked(&rgt->lock));
@@ -508,17 +511,27 @@ static int grant_map_exists(const struct domain *ld,
                    nr_grant_entries(rgt));
     for ( ref = *ref_count; ref < max_iter; ref++ )
     {
-        act = &active_entry(rgt, ref);
+        act = active_entry_acquire(rgt, ref);
 
         if ( !act->pin )
+        {
+            active_entry_release(act);
             continue;
+        }
 
         if ( act->domid != ld->domain_id )
+        {
+            active_entry_release(act);
             continue;
+        }
 
         if ( act->frame != mfn )
+        {
+            active_entry_release(act);
             continue;
+        }
 
+        active_entry_release(act);
         return 0;
     }
 
@@ -531,24 +544,44 @@ static int grant_map_exists(const struct domain *ld,
     return -EINVAL;
 }
 
+/* Count the number of mapped ro or rw entries tracked in the left
+ * grant table given a provided mfn provided by a foreign domain. 
+ *
+ * This function takes the maptrack lock from the left grant table and
+ * must be called with the right grant table's rwlock held.
+ */
 static void mapcount(
     struct grant_table *lgt, struct domain *rd, unsigned long mfn,
     unsigned int *wrc, unsigned int *rdc)
 {
     struct grant_mapping *map;
     grant_handle_t handle;
+    struct active_grant_entry *act;
 
     *wrc = *rdc = 0;
 
+    /* N.B.: while taking the left side maptrack spinlock prevents
+     * any mapping changes, the right side active entries could be
+     * changing while we are counting. To be perfectly correct, the
+     * caller should hold the grant table write lock, or some other
+     * mechanism should be used to prevent concurrent changes during
+     * this operation. This is tricky because we can't promote a read
+     * lock into a write lock.
+     */
+    spin_lock(&lgt->maptrack_lock);
+
     for ( handle = 0; handle < lgt->maptrack_limit; handle++ )
     {
         map = &maptrack_entry(lgt, handle);
         if ( !(map->flags & (GNTMAP_device_map|GNTMAP_host_map)) ||
              map->domid != rd->domain_id )
             continue;
-        if ( active_entry(rd->grant_table, map->ref).frame == mfn )
+        act = &_active_entry(rd->grant_table, map->ref);
+        if ( act->frame == mfn )
             (map->flags & GNTMAP_readonly) ? (*rdc)++ : (*wrc)++;
     }
+
+    spin_unlock(&lgt->maptrack_lock);
 }
 
 /*
@@ -570,7 +603,6 @@ __gnttab_map_grant_ref(
     struct page_info *pg = NULL;
     int            rc = GNTST_okay;
     u32            old_pin;
-    u32            act_pin;
     unsigned int   cache_flags;
     struct active_grant_entry *act = NULL;
     struct grant_mapping *mt;
@@ -633,7 +665,7 @@ __gnttab_map_grant_ref(
     if ( unlikely(op->ref >= nr_grant_entries(rgt)))
         PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref (%d).\n", op->ref);
 
-    act = &active_entry(rgt, op->ref);
+    act = active_entry_acquire(rgt, op->ref);
     shah = shared_entry_header(rgt, op->ref);
     if (rgt->gt_version == 1) {
         sha1 = &shared_entry_v1(rgt, op->ref);
@@ -650,7 +682,7 @@ __gnttab_map_grant_ref(
          ((act->domid != ld->domain_id) ||
           (act->pin & 0x80808080U) != 0 ||
           (act->is_sub_page)) )
-        PIN_FAIL(unlock_out, GNTST_general_error,
+        PIN_FAIL(act_release_out, GNTST_general_error,
                  "Bad domain (%d != %d), or risk of counter overflow %08x, or subpage %d\n",
                  act->domid, ld->domain_id, act->pin, act->is_sub_page);
 
@@ -661,7 +693,7 @@ __gnttab_map_grant_ref(
         if ( (rc = _set_status(rgt->gt_version, ld->domain_id,
                                op->flags & GNTMAP_readonly,
                                1, shah, act, status) ) != GNTST_okay )
-             goto unlock_out;
+            goto act_release_out;
 
         if ( !act->pin )
         {
@@ -692,12 +724,9 @@ __gnttab_map_grant_ref(
             GNTPIN_hstr_inc : GNTPIN_hstw_inc;
 
     frame = act->frame;
-    act_pin = act->pin;
 
     cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
-    read_unlock(&rgt->lock);
-
     /* pg may be set, with a refcount included, from __get_paged_frame */
     if ( !pg )
     {
@@ -772,8 +801,6 @@ __gnttab_map_grant_ref(
         goto undo_out;
     }
 
-    double_gt_lock(lgt, rgt);
-
     if ( gnttab_need_iommu_mapping(ld) )
     {
         unsigned int wrc, rdc;
@@ -781,21 +808,20 @@ __gnttab_map_grant_ref(
         /* We're not translated, so we know that gmfns and mfns are
            the same things, so the IOMMU entry is always 1-to-1. */
         mapcount(lgt, rd, frame, &wrc, &rdc);
-        if ( (act_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
+        if ( (act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
              !(old_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
         {
             if ( wrc == 0 )
                 err = iommu_map_page(ld, frame, frame,
                                      IOMMUF_readable|IOMMUF_writable);
         }
-        else if ( act_pin && !old_pin )
+        else if ( act->pin && !old_pin )
         {
             if ( (wrc + rdc) == 0 )
                 err = iommu_map_page(ld, frame, frame, IOMMUF_readable);
         }
         if ( err )
         {
-            double_gt_unlock(lgt, rgt);
             rc = GNTST_general_error;
             goto undo_out;
         }
@@ -808,7 +834,8 @@ __gnttab_map_grant_ref(
     mt->ref   = op->ref;
     mt->flags = op->flags;
 
-    double_gt_unlock(lgt, rgt);
+    active_entry_release(act);
+    read_unlock(&rgt->lock);
 
     op->dev_bus_addr = (u64)frame << PAGE_SHIFT;
     op->handle       = handle;
@@ -831,10 +858,6 @@ __gnttab_map_grant_ref(
         put_page(pg);
     }
 
-    read_lock(&rgt->lock);
-
-    act = &active_entry(rgt, op->ref);
-
     if ( op->flags & GNTMAP_device_map )
         act->pin -= (op->flags & GNTMAP_readonly) ?
             GNTPIN_devr_inc : GNTPIN_devw_inc;
@@ -850,6 +873,9 @@ __gnttab_map_grant_ref(
     if ( !act->pin )
         gnttab_clear_flag(_GTF_reading, status);
 
+ act_release_out:
+    active_entry_release(act);
+
  unlock_out:
     read_unlock(&rgt->lock);
     op->status = rc;
@@ -891,9 +917,9 @@ __gnttab_unmap_common(
     ld = current->domain;
     lgt = ld->grant_table;
 
-    read_lock(&lgt->lock);
     op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
 
+    read_lock(&lgt->lock);
     if ( unlikely(op->handle >= lgt->maptrack_limit) )
     {
         read_unlock(&lgt->lock);
@@ -933,19 +959,18 @@ __gnttab_unmap_common(
     TRACE_1D(TRC_MEM_PAGE_GRANT_UNMAP, dom);
 
     rgt = rd->grant_table;
-    double_gt_lock(lgt, rgt);
 
     op->flags = op->map->flags;
     if ( unlikely(!op->flags) || unlikely(op->map->domid != dom) )
     {
         gdprintk(XENLOG_WARNING, "Unstable handle %u\n", op->handle);
         rc = GNTST_bad_handle;
-        goto unmap_out;
+        goto unlock_out;
     }
 
     op->rd = rd;
     read_lock(&rgt->lock);
-    act = &active_entry(rgt, op->map->ref);
+    act = active_entry_acquire(rgt, op->map->ref);
 
     if ( op->frame == 0 )
     {
@@ -954,7 +979,7 @@ __gnttab_unmap_common(
     else
     {
         if ( unlikely(op->frame != act->frame) )
-            PIN_FAIL(unmap_out, GNTST_general_error,
+            PIN_FAIL(act_release_out, GNTST_general_error,
                      "Bad frame number doesn't match gntref. (%lx != %lx)\n",
                      op->frame, act->frame);
         if ( op->flags & GNTMAP_device_map )
@@ -973,7 +998,7 @@ __gnttab_unmap_common(
         if ( (rc = replace_grant_host_mapping(op->host_addr,
                                               op->frame, op->new_addr, 
                                               op->flags)) < 0 )
-            goto unmap_out;
+            goto act_release_out;
 
         ASSERT(act->pin & (GNTPIN_hstw_mask | GNTPIN_hstr_mask));
         op->map->flags &= ~GNTMAP_host_map;
@@ -995,7 +1020,7 @@ __gnttab_unmap_common(
         if ( err )
         {
             rc = GNTST_general_error;
-            goto unmap_out;
+            goto act_release_out;
         }
     }
 
@@ -1003,9 +1028,11 @@ __gnttab_unmap_common(
     if ( !(op->flags & GNTMAP_readonly) )
          gnttab_mark_dirty(rd, op->frame);
 
- unmap_out:
-    double_gt_unlock(lgt, rgt);
+ act_release_out:
+    active_entry_release(act);
     read_unlock(&rgt->lock);
+
+ unlock_out:
     op->status = rc;
     rcu_unlock_domain(rd);
 }
@@ -1038,9 +1065,9 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
 
     read_lock(&rgt->lock);
     if ( rgt->gt_version == 0 )
-        goto unmap_out;
+        goto unlock_out;
 
-    act = &active_entry(rgt, op->map->ref);
+    act = active_entry_acquire(rgt, op->map->ref);
     sha = shared_entry_header(rgt, op->map->ref);
 
     if ( rgt->gt_version == 1 )
@@ -1054,7 +1081,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
          * Suggests that __gntab_unmap_common failed early and so
          * nothing further to do
          */
-        goto unmap_out;
+        goto act_release_out;
     }
 
     pg = mfn_to_page(op->frame);
@@ -1078,7 +1105,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
              * Suggests that __gntab_unmap_common failed in
              * replace_grant_host_mapping() so nothing further to do
              */
-            goto unmap_out;
+            goto act_release_out;
         }
 
         if ( !is_iomem_page(op->frame) ) 
@@ -1099,8 +1126,12 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
     if ( act->pin == 0 )
         gnttab_clear_flag(_GTF_reading, status);
 
- unmap_out:
+ act_release_out:
+    active_entry_release(act);
+    
+ unlock_out:
     read_unlock(&rgt->lock);
+
     if ( put_handle )
     {
         op->map->flags = 0;
@@ -1295,7 +1326,7 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
     /* d's grant table write lock must be held by the caller */
 
     struct grant_table *gt = d->grant_table;
-    unsigned int i;
+    unsigned int i, j;
 
     ASSERT(req_nr_frames <= max_grant_frames);
 
@@ -1310,6 +1341,10 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
         if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
             goto active_alloc_failed;
         clear_page(gt->active[i]);
+        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+        {
+            spin_lock_init(&gt->active[i][j].lock);
+        }
     }
 
     /* Shared */
@@ -1804,7 +1839,7 @@ __release_grant_for_copy(
 
     read_lock(&rgt->lock);
 
-    act = &active_entry(rgt, gref);
+    act = active_entry_acquire(rgt, gref);
     sha = shared_entry_header(rgt, gref);
     r_frame = act->frame;
 
@@ -1843,6 +1878,7 @@ __release_grant_for_copy(
         released_read = 1;
     }
 
+    active_entry_release(act);
     read_unlock(&rgt->lock);
 
     if ( td != rd )
@@ -1904,14 +1940,14 @@ __acquire_grant_for_copy(
     read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
-        PIN_FAIL(unlock_out, GNTST_general_error,
+        PIN_FAIL(gnt_unlock_out, GNTST_general_error,
                  "remote grant table not ready\n");
 
     if ( unlikely(gref >= nr_grant_entries(rgt)) )
-        PIN_FAIL(unlock_out, GNTST_bad_gntref,
+        PIN_FAIL(gnt_unlock_out, GNTST_bad_gntref,
                  "Bad grant reference %ld\n", gref);
 
-    act = &active_entry(rgt, gref);
+    act = active_entry_acquire(rgt, gref);
     shah = shared_entry_header(rgt, gref);
     if ( rgt->gt_version == 1 )
     {
@@ -1974,6 +2010,7 @@ __acquire_grant_for_copy(
             /* __acquire_grant_for_copy() could take the read lock on
              * the right table (if rd == td), so we have to drop the
              * lock here and reacquire */
+            active_entry_release(act);
             read_unlock(&rgt->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd->domain_id,
@@ -1981,8 +2018,11 @@ __acquire_grant_for_copy(
                                           &trans_page_off, &trans_length, 0);
 
             read_lock(&rgt->lock);
+            act = active_entry_acquire(rgt, gref);
+
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_copy_pin(act, status);
+                active_entry_release(act);
                 read_unlock(&rgt->lock);
                 rcu_unlock_domain(td);
                 return rc;
@@ -1996,6 +2036,7 @@ __acquire_grant_for_copy(
             {
                 __fixup_status_for_copy_pin(act, status);
                 rcu_unlock_domain(td);
+                active_entry_release(act);
                 read_unlock(&rgt->lock);
                 put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ldom, readonly,
@@ -2064,6 +2105,7 @@ __acquire_grant_for_copy(
     *length = act->length;
     *frame = act->frame;
 
+    active_entry_release(act);
     read_unlock(&rgt->lock);
     return rc;
  
@@ -2076,6 +2118,9 @@ __acquire_grant_for_copy(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
+    active_entry_release(act);
+
+ gnt_unlock_out:
     read_unlock(&rgt->lock);
     return rc;
 }
@@ -2259,16 +2304,18 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     {
         for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
-            act = &active_entry(gt, i);
+            act = active_entry_acquire(gt, i);
             if ( act->pin != 0 )
             {
                 gdprintk(XENLOG_WARNING,
                          "tried to change grant table version from %d to %d, but some grant entries still in use\n",
                          gt->gt_version,
                          op.version);
+                active_entry_release(act);
                 res = -EBUSY;
                 goto out_unlock;
             }
+            active_entry_release(act);
         }
     }
 
@@ -2447,9 +2494,16 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
 {
     struct domain *d = rcu_lock_current_domain();
     struct grant_table *gt = d->grant_table;
-    struct active_grant_entry *act;
+    struct active_grant_entry *act_a = NULL;
+    struct active_grant_entry *act_b = NULL;
     s16 rc = GNTST_okay;
 
+    if ( ref_a == ref_b )
+        /* noop, so avoid acquiring the same active entry
+         * twice which would case a deadlock.
+         */
+        return rc;
+
     read_lock(&gt->lock);
 
     /* Bounds check on the grant refs */
@@ -2458,12 +2512,12 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     if ( unlikely(ref_b >= nr_grant_entries(d->grant_table)))
         PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-b (%d).\n", ref_b);
 
-    act = &active_entry(gt, ref_a);
-    if ( act->pin )
+    act_a = active_entry_acquire(gt, ref_a);
+    if ( act_a->pin )
         PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
 
-    act = &active_entry(gt, ref_b);
-    if ( act->pin )
+    act_b = active_entry_acquire(gt, ref_b);
+    if ( act_b->pin )
         PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
 
     if ( gt->gt_version == 1 )
@@ -2490,8 +2544,11 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     }
 
 out:
+    if ( act_b != NULL )
+        active_entry_release(act_b);
+    if ( act_a != NULL )
+        active_entry_release(act_a);
     read_unlock(&gt->lock);
-
     rcu_unlock_domain(d);
 
     return rc;
@@ -2796,7 +2853,7 @@ grant_table_create(
     struct domain *d)
 {
     struct grant_table *t;
-    int                 i;
+    int                 i, j;
 
     if ( (t = xzalloc(struct grant_table)) == NULL )
         goto no_mem_0;
@@ -2816,6 +2873,10 @@ grant_table_create(
         if ( (t->active[i] = alloc_xenheap_page()) == NULL )
             goto no_mem_2;
         clear_page(t->active[i]);
+        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+        {
+            spin_lock_init(&t->active[i][j].lock);
+        }
     }
 
     /* Tracking of mapped foreign frames table */
@@ -2912,7 +2973,7 @@ gnttab_release_mappings(
         rgt = rd->grant_table;
         read_lock(&rgt->lock);
 
-        act = &active_entry(rgt, ref);
+        act = active_entry_acquire(rgt, ref);
         sha = shared_entry_header(rgt, ref);
         if (rgt->gt_version == 1)
             status = &sha->flags;
@@ -2970,6 +3031,7 @@ gnttab_release_mappings(
         if ( act->pin == 0 )
             gnttab_clear_flag(_GTF_reading, status);
 
+        active_entry_release(act);
         read_unlock(&rgt->lock);
 
         rcu_unlock_domain(rd);
@@ -2990,7 +3052,7 @@ grant_table_destroy(
         return;
 
     write_lock(&t->lock);
-    
+
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
     xfree(t->shared_raw);
@@ -3036,9 +3098,11 @@ static void gnttab_usage_print(struct domain *rd)
         uint16_t status;
         uint64_t frame;
 
-        act = &active_entry(gt, ref);
-        if ( !act->pin )
+        act = active_entry_acquire(gt, ref);
+        if ( !act->pin ) {
+            active_entry_release(act);
             continue;
+        }
 
         sha = shared_entry_header(gt, ref);
 
@@ -3068,6 +3132,7 @@ static void gnttab_usage_print(struct domain *rd)
         printk("[%3d]    %5d 0x%06lx 0x%08x      %5d 0x%06"PRIx64" 0x%02x\n",
                ref, act->domid, act->frame, act->pin,
                sha->domid, frame, status);
+        active_entry_release(act);
     }
 
  out:
-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 14:30:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 14: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 1XwAwJ-0005z6-CU; Wed, 03 Dec 2014 14:29:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=40726a7d2=chegger@amazon.de>)
	id 1XwAwH-0005yW-DT
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 14:29:57 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	C2/1A-02699-46E1F745; Wed, 03 Dec 2014 14:29:56 +0000
X-Env-Sender: prvs=40726a7d2=chegger@amazon.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417616988!12745227!2
X-Originating-IP: [207.171.178.25]
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 30247 invoked from network); 3 Dec 2014 14:29:54 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 14:29:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;
	t=1417616994; x=1449152994;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version;
	bh=7P8K4+hxN8TLZhT58GSD2XksX3gZDhztUoPjxgCtMUA=;
	b=cbfmVL9gHyJHATJ8PvRPjz6mLLgG5ziDJU3P2LkCay6DyyOHUA+WCDSN
	mpvyizJ20WloSZKccjgd25nsPfhgY1S+Vi+BZBuOfjmyBixePO7nBNjT/
	bYo7lTXk4AmdKlXtQKFHKwAveuIR2vFECC3zjO+ENNiw+BmFcYO6s2NlP Y=;
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="175640702"
Received: from email-inbound-relay-25001.iad12.amazon.com ([10.205.29.168])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2014 14:29:53 +0000
Received: from ex10-hub-7002.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com
	[10.0.103.150])
	by email-inbound-relay-25001.iad12.amazon.com (8.14.7/8.14.7) with
	ESMTP id sB3ETa0v008994
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 14:29:51 GMT
Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by
	ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server
	(TLS) id 14.3.181.6; Wed, 3 Dec 2014 06:29:48 -0800
Received: from ub8ca3ab5e76052a86f39.drs10.amazon.com (10.43.160.14) by
	EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server
	(TLS) id 15.0.995.29; Wed, 3 Dec 2014 06:29:44 -0800
From: Christoph Egger <chegger@amazon.de>
To: <xen-devel@lists.xen.org>
Date: Wed, 3 Dec 2014 15:29:26 +0100
Message-ID: <1417616967-18720-2-git-send-email-chegger@amazon.de>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1417616967-18720-1-git-send-email-chegger@amazon.de>
References: <1417616967-18720-1-git-send-email-chegger@amazon.de>
MIME-Version: 1.0
X-Originating-IP: [10.43.160.14]
X-ClientProxiedBy: EX13D03UWA003.ant.amazon.com (10.43.160.39) To
	EX13D03UWA003.ant.amazon.com (10.43.160.39)
Precedence: Bulk
Cc: Christoph Egger <chegger@amazon.de>, Keir Fraser <keir@xen.org>, Jan
	Beulich <jbeulich@suse.com>, Matt Wilson <msw@amazon.com>,
	Julien Grall <julien.grall@linaro.org>
Subject: [Xen-devel] [PATCH v3 1/2] gnttab: Introduce rwlock to protect
	updates to grant table state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Split grant table lock into two separate locks. One to protect
maptrack state and change the other into a rwlock.

The rwlock is used to prevent readers from accessing
inconsistent grant table state such as current
version, partially initialized active table pages,
etc.

Signed-off-by: Matt Wilson <msw@amazon.com>
[chegger: ported to xen-staging, split into multiple commits]

v3:
  * Addressed gnttab_swap_grant_ref() comment from Andrew Cooper
v2:
  * Add arm part per request from Julien Grall

Signed-off-by: Christoph Egger <chegger@amazon.de>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Julien Grall <julien.grall@linaro.org>
---
 docs/misc/grant-tables.txt    |   28 +++++++++-
 xen/arch/arm/mm.c             |    4 +-
 xen/arch/x86/mm.c             |    4 +-
 xen/common/grant_table.c      |  120 +++++++++++++++++++++++------------------
 xen/include/xen/grant_table.h |    9 ++--
 5 files changed, 104 insertions(+), 61 deletions(-)

diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt
index 19db4ec..c9ae8f2 100644
--- a/docs/misc/grant-tables.txt
+++ b/docs/misc/grant-tables.txt
@@ -74,7 +74,33 @@ is complete.
  matching map track entry is then removed, as if unmap had been invoked.
  These are not used by the transfer mechanism.
   map->domid         : owner of the mapped frame
-  map->ref_and_flags : grant reference, ro/rw, mapped for host or device access
+  map->ref           : grant reference
+  map->flags         : ro/rw, mapped for host or device access
+
+********************************************************************************
+ Locking
+ ~~~~~~~
+ Xen uses several locks to serialize access to the internal grant table state.
+
+  grant_table->lock          : rwlock used to prevent readers from accessing
+                               inconsistent grant table state such as current
+                               version, partially initialized active table pages,
+                               etc.
+  grant_table->maptrack_lock : spinlock used to protect the maptrack state
+
+ The primary lock for the grant table is a read/write spinlock. All
+ functions that access members of struct grant_table must acquire a
+ read lock around critical sections. Any modification to the members
+ of struct grant_table (e.g., nr_status_frames, nr_grant_frames,
+ active frames, etc.) must only be made if the write lock is
+ held. These elements are read-mostly, and read critical sections can
+ be large, which makes a rwlock a good choice.
+
+ The maptrack state is protected by its own spinlock. Any access (read
+ or write) of struct grant_table members that have a "maptrack_"
+ prefix must be made while holding the maptrack lock. The maptrack
+ state can be rapidly modified under some workloads, and the critical
+ sections are very small, thus we use a spinlock to protect them.
 
 ********************************************************************************
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7d4ba0c..2765683 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1037,7 +1037,7 @@ int xenmem_add_to_physmap_one(
     switch ( space )
     {
     case XENMAPSPACE_grant_table:
-        spin_lock(&d->grant_table->lock);
+        write_lock(&d->grant_table->lock);
 
         if ( d->grant_table->gt_version == 0 )
             d->grant_table->gt_version = 1;
@@ -1067,7 +1067,7 @@ int xenmem_add_to_physmap_one(
 
         t = p2m_ram_rw;
 
-        spin_unlock(&d->grant_table->lock);
+        write_unlock(&d->grant_table->lock);
         break;
     case XENMAPSPACE_shared_info:
         if ( idx != 0 )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 522c43d..37c13b1 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4565,7 +4565,7 @@ int xenmem_add_to_physmap_one(
                 mfn = virt_to_mfn(d->shared_info);
             break;
         case XENMAPSPACE_grant_table:
-            spin_lock(&d->grant_table->lock);
+            write_lock(&d->grant_table->lock);
 
             if ( d->grant_table->gt_version == 0 )
                 d->grant_table->gt_version = 1;
@@ -4587,7 +4587,7 @@ int xenmem_add_to_physmap_one(
                     mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
             }
 
-            spin_unlock(&d->grant_table->lock);
+            write_unlock(&d->grant_table->lock);
             break;
         case XENMAPSPACE_gmfn_range:
         case XENMAPSPACE_gmfn:
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 8fba923..24feb65 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -227,23 +227,23 @@ double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
 {
     if ( lgt < rgt )
     {
-        spin_lock(&lgt->lock);
-        spin_lock(&rgt->lock);
+        spin_lock(&lgt->maptrack_lock);
+        spin_lock(&rgt->maptrack_lock);
     }
     else
     {
         if ( lgt != rgt )
-            spin_lock(&rgt->lock);
-        spin_lock(&lgt->lock);
+            spin_lock(&rgt->maptrack_lock);
+        spin_lock(&lgt->maptrack_lock);
     }
 }
 
 static inline void
 double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
 {
-    spin_unlock(&lgt->lock);
+    spin_unlock(&lgt->maptrack_lock);
     if ( lgt != rgt )
-        spin_unlock(&rgt->lock);
+        spin_unlock(&rgt->maptrack_lock);
 }
 
 static inline int
@@ -261,10 +261,10 @@ static inline void
 put_maptrack_handle(
     struct grant_table *t, int handle)
 {
-    spin_lock(&t->lock);
+    spin_lock(&t->maptrack_lock);
     maptrack_entry(t, handle).ref = t->maptrack_head;
     t->maptrack_head = handle;
-    spin_unlock(&t->lock);
+    spin_unlock(&t->maptrack_lock);
 }
 
 static inline int
@@ -276,7 +276,7 @@ get_maptrack_handle(
     struct grant_mapping *new_mt;
     unsigned int          new_mt_limit, nr_frames;
 
-    spin_lock(&lgt->lock);
+    spin_lock(&lgt->maptrack_lock);
 
     while ( unlikely((handle = __get_maptrack_handle(lgt)) == -1) )
     {
@@ -305,7 +305,7 @@ get_maptrack_handle(
                  nr_frames + 1);
     }
 
-    spin_unlock(&lgt->lock);
+    spin_unlock(&lgt->maptrack_lock);
 
     return handle;
 }
@@ -502,7 +502,7 @@ static int grant_map_exists(const struct domain *ld,
     const struct active_grant_entry *act;
     unsigned int ref, max_iter;
     
-    ASSERT(spin_is_locked(&rgt->lock));
+    ASSERT(rw_is_locked(&rgt->lock));
 
     max_iter = min(*ref_count + (1 << GNTTABOP_CONTINUATION_ARG_SHIFT),
                    nr_grant_entries(rgt));
@@ -623,7 +623,7 @@ __gnttab_map_grant_ref(
     }
 
     rgt = rd->grant_table;
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
         PIN_FAIL(unlock_out, GNTST_general_error,
@@ -696,7 +696,7 @@ __gnttab_map_grant_ref(
 
     cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
 
     /* pg may be set, with a refcount included, from __get_paged_frame */
     if ( !pg )
@@ -831,7 +831,7 @@ __gnttab_map_grant_ref(
         put_page(pg);
     }
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     act = &active_entry(rgt, op->ref);
 
@@ -851,7 +851,7 @@ __gnttab_map_grant_ref(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     op->status = rc;
     put_maptrack_handle(lgt, handle);
     rcu_unlock_domain(rd);
@@ -891,28 +891,28 @@ __gnttab_unmap_common(
     ld = current->domain;
     lgt = ld->grant_table;
 
+    read_lock(&lgt->lock);
     op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
 
     if ( unlikely(op->handle >= lgt->maptrack_limit) )
     {
+        read_unlock(&lgt->lock);
         gdprintk(XENLOG_INFO, "Bad handle (%d).\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
+    read_unlock(&lgt->lock);
     op->map = &maptrack_entry(lgt, op->handle);
-    spin_lock(&lgt->lock);
 
     if ( unlikely(!op->map->flags) )
     {
-        spin_unlock(&lgt->lock);
         gdprintk(XENLOG_INFO, "Zero flags for handle (%d).\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
     dom = op->map->domid;
-    spin_unlock(&lgt->lock);
 
     if ( unlikely((rd = rcu_lock_domain_by_id(dom)) == NULL) )
     {
@@ -944,6 +944,7 @@ __gnttab_unmap_common(
     }
 
     op->rd = rd;
+    read_lock(&rgt->lock);
     act = &active_entry(rgt, op->map->ref);
 
     if ( op->frame == 0 )
@@ -1004,6 +1005,7 @@ __gnttab_unmap_common(
 
  unmap_out:
     double_gt_unlock(lgt, rgt);
+    read_unlock(&rgt->lock);
     op->status = rc;
     rcu_unlock_domain(rd);
 }
@@ -1033,8 +1035,8 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
 
     rcu_lock_domain(rd);
     rgt = rd->grant_table;
-    spin_lock(&rgt->lock);
 
+    read_lock(&rgt->lock);
     if ( rgt->gt_version == 0 )
         goto unmap_out;
 
@@ -1098,7 +1100,7 @@ __gnttab_unmap_common_complete(struct gnttab_unmap_common *op)
         gnttab_clear_flag(_GTF_reading, status);
 
  unmap_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     if ( put_handle )
     {
         op->map->flags = 0;
@@ -1284,10 +1286,13 @@ gnttab_unpopulate_status_frames(struct domain *d, struct grant_table *gt)
     gt->nr_status_frames = 0;
 }
 
+/* Grow the grant table. The caller must hold the grant table's
+ * write lock before calling this function.
+ */
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
 {
-    /* d's grant table lock must be held by the caller */
+    /* d's grant table write lock must be held by the caller */
 
     struct grant_table *gt = d->grant_table;
     unsigned int i;
@@ -1392,7 +1397,7 @@ gnttab_setup_table(
     }
 
     gt = d->grant_table;
-    spin_lock(&gt->lock);
+    write_lock(&gt->lock);
 
     if ( gt->gt_version == 0 )
         gt->gt_version = 1;
@@ -1420,7 +1425,7 @@ gnttab_setup_table(
     }
 
  out3:
-    spin_unlock(&gt->lock);
+    write_unlock(&gt->lock);
  out2:
     rcu_unlock_domain(d);
  out1:
@@ -1462,13 +1467,13 @@ gnttab_query_size(
         goto query_out_unlock;
     }
 
-    spin_lock(&d->grant_table->lock);
+    read_lock(&d->grant_table->lock);
 
     op.nr_frames     = nr_grant_frames(d->grant_table);
     op.max_nr_frames = max_grant_frames;
     op.status        = GNTST_okay;
 
-    spin_unlock(&d->grant_table->lock);
+    read_unlock(&d->grant_table->lock);
 
  
  query_out_unlock:
@@ -1494,7 +1499,7 @@ gnttab_prepare_for_transfer(
     union grant_combo   scombo, prev_scombo, new_scombo;
     int                 retries = 0;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
     {
@@ -1545,11 +1550,11 @@ gnttab_prepare_for_transfer(
         scombo = prev_scombo;
     }
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return 1;
 
  fail:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return 0;
 }
 
@@ -1741,7 +1746,7 @@ gnttab_transfer(
         TRACE_1D(TRC_MEM_PAGE_GRANT_TRANSFER, e->domain_id);
 
         /* Tell the guest about its new page frame. */
-        spin_lock(&e->grant_table->lock);
+        read_lock(&e->grant_table->lock);
 
         if ( e->grant_table->gt_version == 1 )
         {
@@ -1759,7 +1764,7 @@ gnttab_transfer(
         shared_entry_header(e->grant_table, gop.ref)->flags |=
             GTF_transfer_completed;
 
-        spin_unlock(&e->grant_table->lock);
+        read_unlock(&e->grant_table->lock);
 
         rcu_unlock_domain(e);
 
@@ -1797,7 +1802,7 @@ __release_grant_for_copy(
     released_read = 0;
     released_write = 0;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     act = &active_entry(rgt, gref);
     sha = shared_entry_header(rgt, gref);
@@ -1838,7 +1843,7 @@ __release_grant_for_copy(
         released_read = 1;
     }
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
 
     if ( td != rd )
     {
@@ -1896,7 +1901,7 @@ __acquire_grant_for_copy(
 
     *page = NULL;
 
-    spin_lock(&rgt->lock);
+    read_lock(&rgt->lock);
 
     if ( rgt->gt_version == 0 )
         PIN_FAIL(unlock_out, GNTST_general_error,
@@ -1965,17 +1970,21 @@ __acquire_grant_for_copy(
                 PIN_FAIL(unlock_out_clear, GNTST_general_error,
                          "transitive grant referenced bad domain %d\n",
                          trans_domid);
-            spin_unlock(&rgt->lock);
+
+            /* __acquire_grant_for_copy() could take the read lock on
+             * the right table (if rd == td), so we have to drop the
+             * lock here and reacquire */
+            read_unlock(&rgt->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd->domain_id,
                                           readonly, &grant_frame, page,
                                           &trans_page_off, &trans_length, 0);
 
-            spin_lock(&rgt->lock);
+            read_lock(&rgt->lock);
             if ( rc != GNTST_okay ) {
                 __fixup_status_for_copy_pin(act, status);
+                read_unlock(&rgt->lock);
                 rcu_unlock_domain(td);
-                spin_unlock(&rgt->lock);
                 return rc;
             }
 
@@ -1987,7 +1996,7 @@ __acquire_grant_for_copy(
             {
                 __fixup_status_for_copy_pin(act, status);
                 rcu_unlock_domain(td);
-                spin_unlock(&rgt->lock);
+                read_unlock(&rgt->lock);
                 put_page(*page);
                 return __acquire_grant_for_copy(rd, gref, ldom, readonly,
                                                 frame, page, page_off, length,
@@ -2055,7 +2064,7 @@ __acquire_grant_for_copy(
     *length = act->length;
     *frame = act->frame;
 
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return rc;
  
  unlock_out_clear:
@@ -2067,7 +2076,7 @@ __acquire_grant_for_copy(
         gnttab_clear_flag(_GTF_reading, status);
 
  unlock_out:
-    spin_unlock(&rgt->lock);
+    read_unlock(&rgt->lock);
     return rc;
 }
 
@@ -2241,7 +2250,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     if ( gt->gt_version == op.version )
         goto out;
 
-    spin_lock(&gt->lock);
+    write_lock(&gt->lock);
     /* Make sure that the grant table isn't currently in use when we
        change the version number, except for the first 8 entries which
        are allowed to be in use (xenstore/xenconsole keeps them mapped).
@@ -2327,7 +2336,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
     gt->gt_version = op.version;
 
 out_unlock:
-    spin_unlock(&gt->lock);
+    write_unlock(&gt->lock);
 
 out:
     op.version = gt->gt_version;
@@ -2383,7 +2392,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
 
     op.status = GNTST_okay;
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     for ( i = 0; i < op.nr_frames; i++ )
     {
@@ -2392,7 +2401,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
             op.status = GNTST_bad_virt_addr;
     }
 
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 out2:
     rcu_unlock_domain(d);
 out1:
@@ -2441,7 +2450,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     struct active_grant_entry *act;
     s16 rc = GNTST_okay;
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     /* Bounds check on the grant refs */
     if ( unlikely(ref_a >= nr_grant_entries(d->grant_table)))
@@ -2481,7 +2490,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
     }
 
 out:
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 
     rcu_unlock_domain(d);
 
@@ -2552,12 +2561,12 @@ static int __gnttab_cache_flush(gnttab_cache_flush_t *cflush,
 
     if ( d != owner )
     {
-        spin_lock(&owner->grant_table->lock);
+        read_lock(&owner->grant_table->lock);
 
         ret = grant_map_exists(d, owner->grant_table, mfn, ref_count);
         if ( ret != 0 )
         {
-            spin_unlock(&owner->grant_table->lock);
+            read_unlock(&owner->grant_table->lock);
             rcu_unlock_domain(d);
             put_page(page);
             return ret;
@@ -2577,7 +2586,7 @@ static int __gnttab_cache_flush(gnttab_cache_flush_t *cflush,
         ret = 0;
 
     if ( d != owner )
-        spin_unlock(&owner->grant_table->lock);
+        read_unlock(&owner->grant_table->lock);
     unmap_domain_page(v);
     put_page(page);
 
@@ -2793,7 +2802,8 @@ grant_table_create(
         goto no_mem_0;
 
     /* Simple stuff. */
-    spin_lock_init(&t->lock);
+    rwlock_init(&t->lock);
+    spin_lock_init(&t->maptrack_lock);
     t->nr_grant_frames = INITIAL_NR_GRANT_FRAMES;
 
     /* Active grant table. */
@@ -2900,7 +2910,7 @@ gnttab_release_mappings(
         }
 
         rgt = rd->grant_table;
-        spin_lock(&rgt->lock);
+        read_lock(&rgt->lock);
 
         act = &active_entry(rgt, ref);
         sha = shared_entry_header(rgt, ref);
@@ -2960,7 +2970,7 @@ gnttab_release_mappings(
         if ( act->pin == 0 )
             gnttab_clear_flag(_GTF_reading, status);
 
-        spin_unlock(&rgt->lock);
+        read_unlock(&rgt->lock);
 
         rcu_unlock_domain(rd);
 
@@ -2978,6 +2988,8 @@ grant_table_destroy(
 
     if ( t == NULL )
         return;
+
+    write_lock(&t->lock);
     
     for ( i = 0; i < nr_grant_frames(t); i++ )
         free_xenheap_page(t->shared_raw[i]);
@@ -2995,6 +3007,8 @@ grant_table_destroy(
         free_xenheap_page(t->status[i]);
     xfree(t->status);
 
+    write_unlock(&t->lock);
+
     xfree(t);
     d->grant_table = NULL;
 }
@@ -3008,7 +3022,7 @@ static void gnttab_usage_print(struct domain *rd)
     printk("      -------- active --------       -------- shared --------\n");
     printk("[ref] localdom mfn      pin          localdom gmfn     flags\n");
 
-    spin_lock(&gt->lock);
+    read_lock(&gt->lock);
 
     if ( gt->gt_version == 0 )
         goto out;
@@ -3057,7 +3071,7 @@ static void gnttab_usage_print(struct domain *rd)
     }
 
  out:
-    spin_unlock(&gt->lock);
+    read_unlock(&gt->lock);
 
     if ( first )
         printk("grant-table for remote domain:%5d ... "
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 32f5786..ca49b41 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -82,8 +82,11 @@ struct grant_table {
     struct grant_mapping **maptrack;
     unsigned int          maptrack_head;
     unsigned int          maptrack_limit;
-    /* Lock protecting updates to active and shared grant tables. */
-    spinlock_t            lock;
+    /* Lock protecting the maptrack page list, head, and limit */
+    spinlock_t            maptrack_lock;
+    /* Lock protecting updates to grant table state (version, active
+       entry list, etc.) */
+    rwlock_t              lock;
     /* The defined versions are 1 and 2.  Set to 0 if we don't know
        what version to use yet. */
     unsigned              gt_version;
@@ -101,7 +104,7 @@ gnttab_release_mappings(
     struct domain *d);
 
 /* Increase the size of a domain's grant table.
- * Caller must hold d's grant table lock.
+ * Caller must hold d's grant table write lock.
  */
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames);
-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 14:44:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 14: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 1XwBA3-0006mB-Hr; Wed, 03 Dec 2014 14:44:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XwBA2-0006m5-77
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 14:44:10 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	D5/FE-02699-9B12F745; Wed, 03 Dec 2014 14:44:09 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417617839!12755747!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23545 invoked from network); 3 Dec 2014 14:44:04 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 14:44:04 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDJ48090; Wed, 03 Dec 2014 22:43:49 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Wed, 3 Dec 2014 22:43:38 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961A=
Date: Wed, 3 Dec 2014 14:43:37 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
In-Reply-To: <20141202155832.GH5768@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Tuesday, December 02, 2014 11:59 PM
> To: Zhangleiqiang (Trump)
> Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian); Xiaoding
> (B); Yuzhou (C); Zhuangyuxin
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> On Tue, Dec 02, 2014 at 02:46:36PM +0000, Zhangleiqiang (Trump) wrote:
> > Thanks for your reply, Wei.
> >
> > I do the following testing just now and found the results as follows:
> >
> > There are three DomUs (4U4G) are running on Host A (6U6G) and one DomU
> (4U4G) is running on Host B (6U6G), I send packets from three DomUs to the
> DomU on Host B simultaneously.
> >
> > 1. The "top" output of Host B as follows:
> >
> > top - 09:42:11 up  1:07,  2 users,  load average: 2.46, 1.90, 1.47
> > Tasks: 173 total,   4 running, 169 sleeping,   0 stopped,   0 zombie
> > %Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 97.3 id,  0.0 wa,  0.0 hi,  0.8
> > si,  1.9 st
> > %Cpu1  :  0.0 us, 27.0 sy,  0.0 ni, 63.1 id,  0.0 wa,  0.0 hi,  9.5
> > si,  0.4 st
> > %Cpu2  :  0.0 us, 90.0 sy,  0.0 ni,  8.3 id,  0.0 wa,  0.0 hi,  1.7
> > si,  0.0 st
> > %Cpu3  :  0.4 us,  1.4 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,  1.4
> > si,  1.4 st
> > %Cpu4  :  0.0 us, 60.2 sy,  0.0 ni, 39.5 id,  0.0 wa,  0.0 hi,  0.3
> > si,  0.0 st
> > %Cpu5  :  0.0 us,  2.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.0 hi,  6.9 si,  0.9
> st
> > KiB Mem:   4517144 total,  3116480 used,  1400664 free,      876
> buffers
> > KiB Swap:  2103292 total,        0 used,  2103292 free.  2374656
> cached Mem
> >
> >   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM
> TIME+ COMMAND
> >  7440 root      20   0       0      0      0 R 71.10 0.000
> 8:15.38 vif4.0-q3-guest
> >  7434 root      20   0       0      0      0 R 59.14 0.000
> 9:00.58 vif4.0-q0-guest
> >    18 root      20   0       0      0      0 R 33.89 0.000
> 2:35.06 ksoftirqd/2
> >    28 root      20   0       0      0      0 S 20.93 0.000
> 3:01.81 ksoftirqd/4
> >
> >
> > As shown above, only two netback related processes (vif4.0-*) are running
> with high cpu usage, and the other 2 netback processes are idle. The "ps"
> result of vif4.0-* processes as follows:
> >
> > root      7434 50.5  0.0      0     0 ?        R    09:23  11:29
> [vif4.0-q0-guest]
> > root      7435  0.0  0.0      0     0 ?        S    09:23   0:00
> [vif4.0-q0-deall]
> > root      7436  0.0  0.0      0     0 ?        S    09:23   0:00
> [vif4.0-q1-guest]
> > root      7437  0.0  0.0      0     0 ?        S    09:23   0:00
> [vif4.0-q1-deall]
> > root      7438  0.0  0.0      0     0 ?        S    09:23   0:00
> [vif4.0-q2-guest]
> > root      7439  0.0  0.0      0     0 ?        S    09:23   0:00
> [vif4.0-q2-deall]
> > root      7440 48.1  0.0      0     0 ?        R    09:23  10:55
> [vif4.0-q3-guest]
> > root      7441  0.0  0.0      0     0 ?        S    09:23   0:00
> [vif4.0-q3-deall]
> > root      9724  0.0  0.0   9244  1520 pts/0    S+   09:46   0:00
> grep --color=auto
> >
> >
> > 2. The "rx" related content in /proc/interupts in receiver DomU (on Host B):
> >
> > 73: 	2		0		2925405		0			xen-dyn-event
> 	eth0-q0-rx
> > 75: 	43		93		0			118			xen-dyn-event
> 	eth0-q1-rx
> > 77: 	2		3376	14			1983		xen-dyn-event
> 	eth0-q2-rx
> > 79: 	2414666	0		9			0			xen-dyn-event
> 	eth0-q3-rx
> >
> > As shown above, it seems like that only q0 and q3 handles the interrupt
> triggered by packet receving.
> >
> > Any advise? Thanks.
> 
> Netback selects queue based on the return value of skb_get_queue_mapping.
> The queue mapping is set by core driver or ndo_select_queue (if specified by
> individual driver). In this case netback doesn't have its implementation of
> ndo_select_queue, so it's up to core driver to decide which queue to dispatch
> the packet to.  I think you need to inspect why Dom0 only steers traffic to
> these two queues but not all of them.
> 
> Don't know which utility is handy for this job. Probably tc(8) is useful?

Thanks Wei.

I think the reason for the above results that only two netback/netfront processes works hard is the queue select method. I have tried to send packets from multiple host/vm to a vm, and all of the netback/netfront processes are running with high cpu usage a few times.

However, I find another issue. Even using 6 queues and making sure that all of these 6 netback processes running with high cpu usage (indeed, any of it running with 87% cpu usage), the whole VM receive throughout is not very higher than results when using 4 queues. The results are from 4.5Gbps to 5.04 Gbps using TCP with 512 bytes length and 4.3Gbps to 5.78Gbps using TCP with 1460 bytes length.

According to the testing result from WIKI: http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_performance_testing, The VM receive throughput is also more lower than VM transmit. 

I am wondering why the VM receive throughout cannot be up to 8-10Gbps as VM transmit under multi-queue?  I also tried to send packets directly from Local Dom0 to DomU, the DomU receive throughput can reach about 8-12Gbps, so I am also wondering why transmitting packets from Dom0 to Remote DomU can only reach about 4-5Gbps throughout?

> Wei.
> 
> > ----------
> > zhangleiqiang (Trump)
> >
> > Best Regards
> >
> >
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: Tuesday, December 02, 2014 8:12 PM
> > > To: Zhangleiqiang (Trump)
> > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian);
> > > Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > > multiqueue support
> > >
> > > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump) wrote:
> > > > > -----Original Message-----
> > > > > From: xen-devel-bounces@lists.xen.org
> > > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei Liu
> > > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > > To: zhangleiqiang
> > > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > > Subject: Re: [Xen-devel] Poor network performance between DomU
> > > > > with multiqueue support
> > > > >
> > > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > > > Hi, all
> > > > > >     I am testing the performance of xen netfront-netback
> > > > > > driver that with
> > > > > multi-queues support. The throughput from domU to remote dom0 is
> > > > > 9.2Gb/s, but the throughput from domU to remote domU is only
> > > > > 3.6Gb/s, I think the bottleneck is the throughput from dom0 to
> > > > > local domU. However, we have done some testing and found the
> > > > > throughput from dom0 to local domU is 5.8Gb/s.
> > > > > >     And if we send packets from one DomU to other 3 DomUs on
> > > > > > different
> > > > > host simultaneously, the sum of throughout can reach 9Gbps. It
> > > > > seems like the bottleneck is the receiver?
> > > > > >     After some analysis, I found that even the max_queue of
> > > > > > netfront/back
> > > > > is set to 4, there are some strange results as follows:
> > > > > >     1. In domU, only one rx queue deal with softirq
> > > > >
> > > > > Try to bind irq to different vcpus?
> > > >
> > > > Do you mean we try to bind irq to different vcpus in DomU? I will try it
> now.
> > > >
> > >
> > > Yes. Given the fact that you have two backend threads running while
> > > only one DomU vcpu is busy, it smells like misconfiguration in DomU.
> > >
> > > If this phenomenon persists after correctly binding irqs, you might
> > > want to check traffic is steering correctly to different queues.
> > >
> > > > >
> > > > > >     2. In dom0, only two netback queues process are scheduled,
> > > > > > other two
> > > > > process aren't scheduled.
> > > > >
> > > > > How many Dom0 vcpu do you have? If it only has two then there
> > > > > will only be two processes running at a time.
> > > >
> > > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU running
> > > > in
> > > Dom0 and so four netback processes are running in Dom0 (because the
> > > max_queue param of netback kernel module is set to 4).
> > > > The phenomenon is that only 2 of these four netback process were
> > > > running
> > > with about 70% cpu usage, and another two use little CPU.
> > > > Is there a hash algorithm to determine which netback process to
> > > > handle the
> > > input packet?
> > > >
> > >
> > > I think that's whatever default algorithm Linux kernel is using.
> > >
> > > We don't currently support other algorithms.
> > >
> > > Wei.

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 14:44:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 14: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 1XwBA3-0006mB-Hr; Wed, 03 Dec 2014 14:44:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XwBA2-0006m5-77
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 14:44:10 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	D5/FE-02699-9B12F745; Wed, 03 Dec 2014 14:44:09 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417617839!12755747!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23545 invoked from network); 3 Dec 2014 14:44:04 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 14:44:04 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDJ48090; Wed, 03 Dec 2014 22:43:49 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Wed, 3 Dec 2014 22:43:38 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961A=
Date: Wed, 3 Dec 2014 14:43:37 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
In-Reply-To: <20141202155832.GH5768@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Tuesday, December 02, 2014 11:59 PM
> To: Zhangleiqiang (Trump)
> Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian); Xiaoding
> (B); Yuzhou (C); Zhuangyuxin
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> On Tue, Dec 02, 2014 at 02:46:36PM +0000, Zhangleiqiang (Trump) wrote:
> > Thanks for your reply, Wei.
> >
> > I do the following testing just now and found the results as follows:
> >
> > There are three DomUs (4U4G) are running on Host A (6U6G) and one DomU
> (4U4G) is running on Host B (6U6G), I send packets from three DomUs to the
> DomU on Host B simultaneously.
> >
> > 1. The "top" output of Host B as follows:
> >
> > top - 09:42:11 up  1:07,  2 users,  load average: 2.46, 1.90, 1.47
> > Tasks: 173 total,   4 running, 169 sleeping,   0 stopped,   0 zombie
> > %Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 97.3 id,  0.0 wa,  0.0 hi,  0.8
> > si,  1.9 st
> > %Cpu1  :  0.0 us, 27.0 sy,  0.0 ni, 63.1 id,  0.0 wa,  0.0 hi,  9.5
> > si,  0.4 st
> > %Cpu2  :  0.0 us, 90.0 sy,  0.0 ni,  8.3 id,  0.0 wa,  0.0 hi,  1.7
> > si,  0.0 st
> > %Cpu3  :  0.4 us,  1.4 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,  1.4
> > si,  1.4 st
> > %Cpu4  :  0.0 us, 60.2 sy,  0.0 ni, 39.5 id,  0.0 wa,  0.0 hi,  0.3
> > si,  0.0 st
> > %Cpu5  :  0.0 us,  2.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.0 hi,  6.9 si,  0.9
> st
> > KiB Mem:   4517144 total,  3116480 used,  1400664 free,      876
> buffers
> > KiB Swap:  2103292 total,        0 used,  2103292 free.  2374656
> cached Mem
> >
> >   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM
> TIME+ COMMAND
> >  7440 root      20   0       0      0      0 R 71.10 0.000
> 8:15.38 vif4.0-q3-guest
> >  7434 root      20   0       0      0      0 R 59.14 0.000
> 9:00.58 vif4.0-q0-guest
> >    18 root      20   0       0      0      0 R 33.89 0.000
> 2:35.06 ksoftirqd/2
> >    28 root      20   0       0      0      0 S 20.93 0.000
> 3:01.81 ksoftirqd/4
> >
> >
> > As shown above, only two netback related processes (vif4.0-*) are running
> with high cpu usage, and the other 2 netback processes are idle. The "ps"
> result of vif4.0-* processes as follows:
> >
> > root      7434 50.5  0.0      0     0 ?        R    09:23  11:29
> [vif4.0-q0-guest]
> > root      7435  0.0  0.0      0     0 ?        S    09:23   0:00
> [vif4.0-q0-deall]
> > root      7436  0.0  0.0      0     0 ?        S    09:23   0:00
> [vif4.0-q1-guest]
> > root      7437  0.0  0.0      0     0 ?        S    09:23   0:00
> [vif4.0-q1-deall]
> > root      7438  0.0  0.0      0     0 ?        S    09:23   0:00
> [vif4.0-q2-guest]
> > root      7439  0.0  0.0      0     0 ?        S    09:23   0:00
> [vif4.0-q2-deall]
> > root      7440 48.1  0.0      0     0 ?        R    09:23  10:55
> [vif4.0-q3-guest]
> > root      7441  0.0  0.0      0     0 ?        S    09:23   0:00
> [vif4.0-q3-deall]
> > root      9724  0.0  0.0   9244  1520 pts/0    S+   09:46   0:00
> grep --color=auto
> >
> >
> > 2. The "rx" related content in /proc/interupts in receiver DomU (on Host B):
> >
> > 73: 	2		0		2925405		0			xen-dyn-event
> 	eth0-q0-rx
> > 75: 	43		93		0			118			xen-dyn-event
> 	eth0-q1-rx
> > 77: 	2		3376	14			1983		xen-dyn-event
> 	eth0-q2-rx
> > 79: 	2414666	0		9			0			xen-dyn-event
> 	eth0-q3-rx
> >
> > As shown above, it seems like that only q0 and q3 handles the interrupt
> triggered by packet receving.
> >
> > Any advise? Thanks.
> 
> Netback selects queue based on the return value of skb_get_queue_mapping.
> The queue mapping is set by core driver or ndo_select_queue (if specified by
> individual driver). In this case netback doesn't have its implementation of
> ndo_select_queue, so it's up to core driver to decide which queue to dispatch
> the packet to.  I think you need to inspect why Dom0 only steers traffic to
> these two queues but not all of them.
> 
> Don't know which utility is handy for this job. Probably tc(8) is useful?

Thanks Wei.

I think the reason for the above results that only two netback/netfront processes works hard is the queue select method. I have tried to send packets from multiple host/vm to a vm, and all of the netback/netfront processes are running with high cpu usage a few times.

However, I find another issue. Even using 6 queues and making sure that all of these 6 netback processes running with high cpu usage (indeed, any of it running with 87% cpu usage), the whole VM receive throughout is not very higher than results when using 4 queues. The results are from 4.5Gbps to 5.04 Gbps using TCP with 512 bytes length and 4.3Gbps to 5.78Gbps using TCP with 1460 bytes length.

According to the testing result from WIKI: http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_performance_testing, The VM receive throughput is also more lower than VM transmit. 

I am wondering why the VM receive throughout cannot be up to 8-10Gbps as VM transmit under multi-queue?  I also tried to send packets directly from Local Dom0 to DomU, the DomU receive throughput can reach about 8-12Gbps, so I am also wondering why transmitting packets from Dom0 to Remote DomU can only reach about 4-5Gbps throughout?

> Wei.
> 
> > ----------
> > zhangleiqiang (Trump)
> >
> > Best Regards
> >
> >
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: Tuesday, December 02, 2014 8:12 PM
> > > To: Zhangleiqiang (Trump)
> > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian);
> > > Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > > multiqueue support
> > >
> > > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump) wrote:
> > > > > -----Original Message-----
> > > > > From: xen-devel-bounces@lists.xen.org
> > > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei Liu
> > > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > > To: zhangleiqiang
> > > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > > Subject: Re: [Xen-devel] Poor network performance between DomU
> > > > > with multiqueue support
> > > > >
> > > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > > > Hi, all
> > > > > >     I am testing the performance of xen netfront-netback
> > > > > > driver that with
> > > > > multi-queues support. The throughput from domU to remote dom0 is
> > > > > 9.2Gb/s, but the throughput from domU to remote domU is only
> > > > > 3.6Gb/s, I think the bottleneck is the throughput from dom0 to
> > > > > local domU. However, we have done some testing and found the
> > > > > throughput from dom0 to local domU is 5.8Gb/s.
> > > > > >     And if we send packets from one DomU to other 3 DomUs on
> > > > > > different
> > > > > host simultaneously, the sum of throughout can reach 9Gbps. It
> > > > > seems like the bottleneck is the receiver?
> > > > > >     After some analysis, I found that even the max_queue of
> > > > > > netfront/back
> > > > > is set to 4, there are some strange results as follows:
> > > > > >     1. In domU, only one rx queue deal with softirq
> > > > >
> > > > > Try to bind irq to different vcpus?
> > > >
> > > > Do you mean we try to bind irq to different vcpus in DomU? I will try it
> now.
> > > >
> > >
> > > Yes. Given the fact that you have two backend threads running while
> > > only one DomU vcpu is busy, it smells like misconfiguration in DomU.
> > >
> > > If this phenomenon persists after correctly binding irqs, you might
> > > want to check traffic is steering correctly to different queues.
> > >
> > > > >
> > > > > >     2. In dom0, only two netback queues process are scheduled,
> > > > > > other two
> > > > > process aren't scheduled.
> > > > >
> > > > > How many Dom0 vcpu do you have? If it only has two then there
> > > > > will only be two processes running at a time.
> > > >
> > > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU running
> > > > in
> > > Dom0 and so four netback processes are running in Dom0 (because the
> > > max_queue param of netback kernel module is set to 4).
> > > > The phenomenon is that only 2 of these four netback process were
> > > > running
> > > with about 70% cpu usage, and another two use little CPU.
> > > > Is there a hash algorithm to determine which netback process to
> > > > handle the
> > > input packet?
> > > >
> > >
> > > I think that's whatever default algorithm Linux kernel is using.
> > >
> > > We don't currently support other algorithms.
> > >
> > > Wei.

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 14:51:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 14: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 1XwBGf-0007Ga-De; Wed, 03 Dec 2014 14:51:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XwBGe-0007GV-Ua
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 14:51:01 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	13/B4-19763-4532F745; Wed, 03 Dec 2014 14:51:00 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417618257!11316112!1
X-Originating-IP: [66.165.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 2039 invoked from network); 3 Dec 2014 14:50: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;
	3 Dec 2014 14:50:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199082722"
Received: from ukmail1.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, 3 Dec 2014 09:50: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 1XwBGZ-0004GT-Lq;
	Wed, 03 Dec 2014 14:50:55 +0000
Date: Wed, 3 Dec 2014 14:50:43 +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: <547F1274.6090607@terremark.com>
Message-ID: <alpine.DEB.2.02.1412031447350.30971@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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
	<547E1FC1.70004@terremark.com>
	<20141203105458.GA4208@zion.uk.xensource.com>
	<alpine.DEB.2.02.1412031218290.30971@kaball.uk.xensource.com>
	<547F1274.6090607@terremark.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>,
	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, 3 Dec 2014, Don Slutz wrote:
> On 12/03/14 07:20, Stefano Stabellini wrote:
> > On Wed, 3 Dec 2014, Wei Liu wrote:
> > > On Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote:
> > > [...]
> > > > > > > >            hw_error("xc_domain_getinfo failed");
> > > > > > > >        }
> > > > > > > > -    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;
> > > > > > > > +    real_free = free_pages;
> > > > > > > > +    if (free_pages > VGA_HOLE_SIZE) {
> > > > > > > > +        free_pages -= VGA_HOLE_SIZE;
> > > > > > > > +    } else {
> > > > > > > > +        free_pages = 0;
> > > > > > > > +    }
> > > > > I don't think we need to subtract VGA_HOLE_SIZE.
> > > > If you do not use some slack (like 32 here), xen does report:
> > > > 
> > > > 
> > > > (d5) [2014-11-29 17:07:21] Loaded SeaBIOS
> > > > (d5) [2014-11-29 17:07:21] Creating MP tables ...
> > > > (d5) [2014-11-29 17:07:21] Loading ACPI ...
> > > > (XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for
> > > > domain
> > > > 5: 1057417 > 1057416
> > > > (XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0
> > > This message is a bit red herring.
> > > 
> > > It's hvmloader trying to populate ram for firmware data. The actual
> > > amount of extra pages needed depends on the firmware.
> > > 
> > > In any case it's safe to disallow hvmloader from doing so, it will just
> > > relocate some pages from ram (hence shrinking *mem_end).
> > That looks like a better solution
> > 
> 
> I went with a "leave some slack" so that the error message above is not
> output.
> 
> When a change to hvmloader is done so that the message does not appear during
> normal usage, the extra pages in QEMU can be dropped.

Although those messages look like fatal errors, they are not. It is
normal way for hvmloader to operate: firstly it tries to allocate extra
memory until it gets an error, then it continues with normal memory,
see:

void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns)
{
    static int over_allocated;
    struct xen_add_to_physmap xatp;
    struct xen_memory_reservation xmr;

    for ( ; nr_mfns-- != 0; mfn++ )
    {
        /* Try to allocate a brand new page in the reserved area. */
        if ( !over_allocated )
        {
            xmr.domid = DOMID_SELF;
            xmr.mem_flags = 0;
            xmr.extent_order = 0;
            xmr.nr_extents = 1;
            set_xen_guest_handle(xmr.extent_start, &mfn);
            if ( hypercall_memory_op(XENMEM_populate_physmap, &xmr) == 1 )
                continue;
            over_allocated = 1;
        }

        /* Otherwise, relocate a page from the ordinary RAM map. */

I think there is really nothing to change there. Maybe we want to make
those warnings less scary.

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 14:51:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 14: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 1XwBGf-0007Ga-De; Wed, 03 Dec 2014 14:51:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XwBGe-0007GV-Ua
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 14:51:01 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	13/B4-19763-4532F745; Wed, 03 Dec 2014 14:51:00 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417618257!11316112!1
X-Originating-IP: [66.165.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 2039 invoked from network); 3 Dec 2014 14:50: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;
	3 Dec 2014 14:50:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199082722"
Received: from ukmail1.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, 3 Dec 2014 09:50: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 1XwBGZ-0004GT-Lq;
	Wed, 03 Dec 2014 14:50:55 +0000
Date: Wed, 3 Dec 2014 14:50:43 +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: <547F1274.6090607@terremark.com>
Message-ID: <alpine.DEB.2.02.1412031447350.30971@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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
	<547E1FC1.70004@terremark.com>
	<20141203105458.GA4208@zion.uk.xensource.com>
	<alpine.DEB.2.02.1412031218290.30971@kaball.uk.xensource.com>
	<547F1274.6090607@terremark.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>,
	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, 3 Dec 2014, Don Slutz wrote:
> On 12/03/14 07:20, Stefano Stabellini wrote:
> > On Wed, 3 Dec 2014, Wei Liu wrote:
> > > On Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote:
> > > [...]
> > > > > > > >            hw_error("xc_domain_getinfo failed");
> > > > > > > >        }
> > > > > > > > -    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;
> > > > > > > > +    real_free = free_pages;
> > > > > > > > +    if (free_pages > VGA_HOLE_SIZE) {
> > > > > > > > +        free_pages -= VGA_HOLE_SIZE;
> > > > > > > > +    } else {
> > > > > > > > +        free_pages = 0;
> > > > > > > > +    }
> > > > > I don't think we need to subtract VGA_HOLE_SIZE.
> > > > If you do not use some slack (like 32 here), xen does report:
> > > > 
> > > > 
> > > > (d5) [2014-11-29 17:07:21] Loaded SeaBIOS
> > > > (d5) [2014-11-29 17:07:21] Creating MP tables ...
> > > > (d5) [2014-11-29 17:07:21] Loading ACPI ...
> > > > (XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for
> > > > domain
> > > > 5: 1057417 > 1057416
> > > > (XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0
> > > This message is a bit red herring.
> > > 
> > > It's hvmloader trying to populate ram for firmware data. The actual
> > > amount of extra pages needed depends on the firmware.
> > > 
> > > In any case it's safe to disallow hvmloader from doing so, it will just
> > > relocate some pages from ram (hence shrinking *mem_end).
> > That looks like a better solution
> > 
> 
> I went with a "leave some slack" so that the error message above is not
> output.
> 
> When a change to hvmloader is done so that the message does not appear during
> normal usage, the extra pages in QEMU can be dropped.

Although those messages look like fatal errors, they are not. It is
normal way for hvmloader to operate: firstly it tries to allocate extra
memory until it gets an error, then it continues with normal memory,
see:

void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns)
{
    static int over_allocated;
    struct xen_add_to_physmap xatp;
    struct xen_memory_reservation xmr;

    for ( ; nr_mfns-- != 0; mfn++ )
    {
        /* Try to allocate a brand new page in the reserved area. */
        if ( !over_allocated )
        {
            xmr.domid = DOMID_SELF;
            xmr.mem_flags = 0;
            xmr.extent_order = 0;
            xmr.nr_extents = 1;
            set_xen_guest_handle(xmr.extent_start, &mfn);
            if ( hypercall_memory_op(XENMEM_populate_physmap, &xmr) == 1 )
                continue;
            over_allocated = 1;
        }

        /* Otherwise, relocate a page from the ordinary RAM map. */

I think there is really nothing to change there. Maybe we want to make
those warnings less scary.

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:02:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15: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 1XwBR5-0007ab-In; Wed, 03 Dec 2014 15:01: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 1XwBR4-0007aW-9q
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:01:46 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	A0/5E-26858-9D52F745; Wed, 03 Dec 2014 15:01:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417618902!10870779!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 14832 invoked from network); 3 Dec 2014 15:01:44 -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;
	3 Dec 2014 15:01:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199429578"
Message-ID: <547F25CC.80200@citrix.com>
Date: Wed, 3 Dec 2014 15:01: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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, <jbeulich@suse.com>,
	<keir@xen.org>, <ian.jackson@eu.citrix.com>,
	<stefano.stabellini@eu.citrix.com>, <ian.campbell@citrix.com>,
	<wei.liu2@citrix.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
X-DLP: MIA2
Cc: dario.faggioli@citrix.com, ufimtseva@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] pci: Do not ignore device's PXM
	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 02/12/14 21:34, Boris Ostrovsky wrote:
> If ACPI provides PXM data for IO devices then dom0 will pass it to
> hypervisor during PHYSDEVOP_pci_device_add call. This information,
> however, is currently ignored.
>
> We should remember it (in the form of nodeID). We will also print it
> when user requests device information dump.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  xen/arch/x86/physdev.c        | 20 +++++++++++++++++---
>  xen/drivers/passthrough/pci.c | 13 +++++++++----
>  xen/include/xen/pci.h         |  5 ++++-
>  3 files changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> index 6b3201b..7775f80 100644
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -565,7 +565,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
>              break;
>  
> -        ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn, NULL);
> +        ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn,
> +                             NULL, NUMA_NO_NODE);
>          break;
>      }
>  
> @@ -597,13 +598,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          pdev_info.physfn.devfn = manage_pci_ext.physfn.devfn;
>          ret = pci_add_device(0, manage_pci_ext.bus,
>                               manage_pci_ext.devfn,
> -                             &pdev_info);
> +                             &pdev_info, NUMA_NO_NODE);
>          break;
>      }
>  
>      case PHYSDEVOP_pci_device_add: {
>          struct physdev_pci_device_add add;
>          struct pci_dev_info pdev_info;
> +        int node;
>  
>          ret = -EFAULT;
>          if ( copy_from_guest(&add, arg, 1) != 0 )
> @@ -618,7 +620,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          }
>          else
>              pdev_info.is_virtfn = 0;
> -        ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info);
> +
> +        if ( add.flags & XEN_PCI_DEV_PXM ) {
> +            int optarr_off = offsetof(struct physdev_pci_device_add, optarr) /
> +                             sizeof(add.optarr[0]);
> +
> +            if ( copy_from_guest_offset(&add.optarr[0], arg, optarr_off, 1) )
> +                break;

This will clobber the hypervisor stack, attempting to put the PXM
information into what is probably pdev_info.

How is one expected to use XEN_PCI_DEV_PXM ? There is currently no
specification of how to use the variable length structure.

~Andrew


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:02:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15: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 1XwBR5-0007ab-In; Wed, 03 Dec 2014 15:01: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 1XwBR4-0007aW-9q
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:01:46 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	A0/5E-26858-9D52F745; Wed, 03 Dec 2014 15:01:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417618902!10870779!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 14832 invoked from network); 3 Dec 2014 15:01:44 -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;
	3 Dec 2014 15:01:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199429578"
Message-ID: <547F25CC.80200@citrix.com>
Date: Wed, 3 Dec 2014 15:01: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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, <jbeulich@suse.com>,
	<keir@xen.org>, <ian.jackson@eu.citrix.com>,
	<stefano.stabellini@eu.citrix.com>, <ian.campbell@citrix.com>,
	<wei.liu2@citrix.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
X-DLP: MIA2
Cc: dario.faggioli@citrix.com, ufimtseva@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] pci: Do not ignore device's PXM
	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 02/12/14 21:34, Boris Ostrovsky wrote:
> If ACPI provides PXM data for IO devices then dom0 will pass it to
> hypervisor during PHYSDEVOP_pci_device_add call. This information,
> however, is currently ignored.
>
> We should remember it (in the form of nodeID). We will also print it
> when user requests device information dump.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  xen/arch/x86/physdev.c        | 20 +++++++++++++++++---
>  xen/drivers/passthrough/pci.c | 13 +++++++++----
>  xen/include/xen/pci.h         |  5 ++++-
>  3 files changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> index 6b3201b..7775f80 100644
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -565,7 +565,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
>              break;
>  
> -        ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn, NULL);
> +        ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn,
> +                             NULL, NUMA_NO_NODE);
>          break;
>      }
>  
> @@ -597,13 +598,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          pdev_info.physfn.devfn = manage_pci_ext.physfn.devfn;
>          ret = pci_add_device(0, manage_pci_ext.bus,
>                               manage_pci_ext.devfn,
> -                             &pdev_info);
> +                             &pdev_info, NUMA_NO_NODE);
>          break;
>      }
>  
>      case PHYSDEVOP_pci_device_add: {
>          struct physdev_pci_device_add add;
>          struct pci_dev_info pdev_info;
> +        int node;
>  
>          ret = -EFAULT;
>          if ( copy_from_guest(&add, arg, 1) != 0 )
> @@ -618,7 +620,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          }
>          else
>              pdev_info.is_virtfn = 0;
> -        ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info);
> +
> +        if ( add.flags & XEN_PCI_DEV_PXM ) {
> +            int optarr_off = offsetof(struct physdev_pci_device_add, optarr) /
> +                             sizeof(add.optarr[0]);
> +
> +            if ( copy_from_guest_offset(&add.optarr[0], arg, optarr_off, 1) )
> +                break;

This will clobber the hypervisor stack, attempting to put the PXM
information into what is probably pdev_info.

How is one expected to use XEN_PCI_DEV_PXM ? There is currently no
specification of how to use the variable length structure.

~Andrew


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:18:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 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 1XwBgn-0007kV-3T; Wed, 03 Dec 2014 15:18:01 +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 1XwBgl-0007kP-F2
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:17:59 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	6D/02-24859-6A92F745; Wed, 03 Dec 2014 15:17:58 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417619876!10902424!1
X-Originating-IP: [156.151.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 28270 invoked from network); 3 Dec 2014 15:17:57 -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; 3 Dec 2014 15:17: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 sB3FHjxM015747
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 15:17: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
	sB3FHi41006075
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 15:17:44 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
	sB3FHh3X022028; Wed, 3 Dec 2014 15:17: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 ; Wed, 03 Dec 2014 07:17:43 -0800
Message-ID: <547F29FF.5040300@oracle.com>
Date: Wed, 03 Dec 2014 10:19:27 -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>, jbeulich@suse.com, keir@xen.org,
	ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, wei.liu2@citrix.com
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
	<547F25CC.80200@citrix.com>
In-Reply-To: <547F25CC.80200@citrix.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: dario.faggioli@citrix.com, ufimtseva@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] pci: Do not ignore device's PXM
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/03/2014 10:01 AM, Andrew Cooper wrote:
> On 02/12/14 21:34, Boris Ostrovsky wrote:
>> If ACPI provides PXM data for IO devices then dom0 will pass it to
>> hypervisor during PHYSDEVOP_pci_device_add call. This information,
>> however, is currently ignored.
>>
>> We should remember it (in the form of nodeID). We will also print it
>> when user requests device information dump.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>   xen/arch/x86/physdev.c        | 20 +++++++++++++++++---
>>   xen/drivers/passthrough/pci.c | 13 +++++++++----
>>   xen/include/xen/pci.h         |  5 ++++-
>>   3 files changed, 30 insertions(+), 8 deletions(-)
>>
>> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
>> index 6b3201b..7775f80 100644
>> --- a/xen/arch/x86/physdev.c
>> +++ b/xen/arch/x86/physdev.c
>> @@ -565,7 +565,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>           if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
>>               break;
>>   
>> -        ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn, NULL);
>> +        ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn,
>> +                             NULL, NUMA_NO_NODE);
>>           break;
>>       }
>>   
>> @@ -597,13 +598,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>           pdev_info.physfn.devfn = manage_pci_ext.physfn.devfn;
>>           ret = pci_add_device(0, manage_pci_ext.bus,
>>                                manage_pci_ext.devfn,
>> -                             &pdev_info);
>> +                             &pdev_info, NUMA_NO_NODE);
>>           break;
>>       }
>>   
>>       case PHYSDEVOP_pci_device_add: {
>>           struct physdev_pci_device_add add;
>>           struct pci_dev_info pdev_info;
>> +        int node;
>>   
>>           ret = -EFAULT;
>>           if ( copy_from_guest(&add, arg, 1) != 0 )
>> @@ -618,7 +620,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>           }
>>           else
>>               pdev_info.is_virtfn = 0;
>> -        ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info);
>> +
>> +        if ( add.flags & XEN_PCI_DEV_PXM ) {
>> +            int optarr_off = offsetof(struct physdev_pci_device_add, optarr) /
>> +                             sizeof(add.optarr[0]);
>> +
>> +            if ( copy_from_guest_offset(&add.optarr[0], arg, optarr_off, 1) )
>> +                break;
> This will clobber the hypervisor stack, attempting to put the PXM
> information into what is probably pdev_info.

Sigh... I actually fixed this on Linux side and now introduced this same 
bug here. (I guess I was lucky here that compiler must have inserted a 
word between add and pdev_info for alignment).

>
> How is one expected to use XEN_PCI_DEV_PXM ? There is currently no
> specification of how to use the variable length structure.

I don't think this is explicitly specified anywhere but if this flag is 
set then optarr[0] is supposed to store uint32_t pxm. I will add a 
comment to this effect to physdev.h

Thanks.
-boris


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:18:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 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 1XwBgn-0007kV-3T; Wed, 03 Dec 2014 15:18:01 +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 1XwBgl-0007kP-F2
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:17:59 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	6D/02-24859-6A92F745; Wed, 03 Dec 2014 15:17:58 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417619876!10902424!1
X-Originating-IP: [156.151.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 28270 invoked from network); 3 Dec 2014 15:17:57 -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; 3 Dec 2014 15:17: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 sB3FHjxM015747
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 15:17: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
	sB3FHi41006075
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 15:17:44 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
	sB3FHh3X022028; Wed, 3 Dec 2014 15:17: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 ; Wed, 03 Dec 2014 07:17:43 -0800
Message-ID: <547F29FF.5040300@oracle.com>
Date: Wed, 03 Dec 2014 10:19:27 -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>, jbeulich@suse.com, keir@xen.org,
	ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, wei.liu2@citrix.com
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
	<547F25CC.80200@citrix.com>
In-Reply-To: <547F25CC.80200@citrix.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: dario.faggioli@citrix.com, ufimtseva@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] pci: Do not ignore device's PXM
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/03/2014 10:01 AM, Andrew Cooper wrote:
> On 02/12/14 21:34, Boris Ostrovsky wrote:
>> If ACPI provides PXM data for IO devices then dom0 will pass it to
>> hypervisor during PHYSDEVOP_pci_device_add call. This information,
>> however, is currently ignored.
>>
>> We should remember it (in the form of nodeID). We will also print it
>> when user requests device information dump.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>   xen/arch/x86/physdev.c        | 20 +++++++++++++++++---
>>   xen/drivers/passthrough/pci.c | 13 +++++++++----
>>   xen/include/xen/pci.h         |  5 ++++-
>>   3 files changed, 30 insertions(+), 8 deletions(-)
>>
>> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
>> index 6b3201b..7775f80 100644
>> --- a/xen/arch/x86/physdev.c
>> +++ b/xen/arch/x86/physdev.c
>> @@ -565,7 +565,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>           if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
>>               break;
>>   
>> -        ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn, NULL);
>> +        ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn,
>> +                             NULL, NUMA_NO_NODE);
>>           break;
>>       }
>>   
>> @@ -597,13 +598,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>           pdev_info.physfn.devfn = manage_pci_ext.physfn.devfn;
>>           ret = pci_add_device(0, manage_pci_ext.bus,
>>                                manage_pci_ext.devfn,
>> -                             &pdev_info);
>> +                             &pdev_info, NUMA_NO_NODE);
>>           break;
>>       }
>>   
>>       case PHYSDEVOP_pci_device_add: {
>>           struct physdev_pci_device_add add;
>>           struct pci_dev_info pdev_info;
>> +        int node;
>>   
>>           ret = -EFAULT;
>>           if ( copy_from_guest(&add, arg, 1) != 0 )
>> @@ -618,7 +620,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>           }
>>           else
>>               pdev_info.is_virtfn = 0;
>> -        ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info);
>> +
>> +        if ( add.flags & XEN_PCI_DEV_PXM ) {
>> +            int optarr_off = offsetof(struct physdev_pci_device_add, optarr) /
>> +                             sizeof(add.optarr[0]);
>> +
>> +            if ( copy_from_guest_offset(&add.optarr[0], arg, optarr_off, 1) )
>> +                break;
> This will clobber the hypervisor stack, attempting to put the PXM
> information into what is probably pdev_info.

Sigh... I actually fixed this on Linux side and now introduced this same 
bug here. (I guess I was lucky here that compiler must have inserted a 
word between add and pdev_info for alignment).

>
> How is one expected to use XEN_PCI_DEV_PXM ? There is currently no
> specification of how to use the variable length structure.

I don't think this is explicitly specified anywhere but if this flag is 
set then optarr[0] is supposed to store uint32_t pxm. I will add a 
comment to this effect to physdev.h

Thanks.
-boris


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:21:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15: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 1XwBjn-0007pv-Mo; Wed, 03 Dec 2014 15:21:07 +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 1XwBjm-0007pm-CN
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:21:06 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	1D/F6-22737-16A2F745; Wed, 03 Dec 2014 15:21:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417620063!11330613!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 32099 invoked from network); 3 Dec 2014 15:21: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;
	3 Dec 2014 15:21:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199099055"
Message-ID: <547F2A5B.9060407@citrix.com>
Date: Wed, 3 Dec 2014 15:20:59 +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>, <jbeulich@suse.com>,
	<keir@xen.org>, <ian.jackson@eu.citrix.com>,
	<stefano.stabellini@eu.citrix.com>, <ian.campbell@citrix.com>,
	<wei.liu2@citrix.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
X-DLP: MIA1
Cc: dario.faggioli@citrix.com, ufimtseva@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 02/12/14 21:34, Boris Ostrovsky wrote:
>  /* XEN_SYSCTL_topologyinfo */
>  #define INVALID_TOPOLOGY_ID  (~0U)
> +
> +struct xen_sysctl_cputopo {
> +    uint32_t core;
> +    uint32_t socket;
> +    uint32_t node;
> +};
> +typedef struct xen_sysctl_cputopo xen_sysctl_cputopo_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cputopo_t);
> +
> +struct xen_sysctl_iotopo {
> +    uint16_t seg;
> +    uint8_t bus;
> +    uint8_t devfn;
> +    uint32_t node;
> +};
> +typedef struct xen_sysctl_iotopo xen_sysctl_iotopo_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_sysctl_iotopo_t);
> +
>  struct xen_sysctl_topologyinfo {
>      /*
>       * IN: maximum addressable entry in the caller-provided arrays.
> -     * OUT: largest cpu identifier in the system.
> +     * OUT: largest cpu identifier or max number of devices 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;
> +    uint32_t max_devs;
>  
>      /*
>       * 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:
> +     * for each cpu and/or node for each PCI device.
> +     * If information for a particular entry is not avalable it is set to
> +     * INVALID_TOPOLOGY_ID.
> +     * The number of array elements for CPU topology written by the sysctl is:
>       *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
>       */
> -    XEN_GUEST_HANDLE_64(uint32) cpu_to_core;
> -    XEN_GUEST_HANDLE_64(uint32) cpu_to_socket;
> -    XEN_GUEST_HANDLE_64(uint32) cpu_to_node;
> +    XEN_GUEST_HANDLE_64(xen_sysctl_cputopo_t) cputopo;
> +    XEN_GUEST_HANDLE_64(xen_sysctl_iotopo_t) iotopo;

These are inherently lists with different indicies.  They should not
conglomerated like this.

I would suggest introducing a new hypercall (xen_sysctl_iotopologyinfo
?) and leave this one alone.

~Andrew

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:21:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15: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 1XwBjn-0007pv-Mo; Wed, 03 Dec 2014 15:21:07 +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 1XwBjm-0007pm-CN
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:21:06 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	1D/F6-22737-16A2F745; Wed, 03 Dec 2014 15:21:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417620063!11330613!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 32099 invoked from network); 3 Dec 2014 15:21: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;
	3 Dec 2014 15:21:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199099055"
Message-ID: <547F2A5B.9060407@citrix.com>
Date: Wed, 3 Dec 2014 15:20:59 +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>, <jbeulich@suse.com>,
	<keir@xen.org>, <ian.jackson@eu.citrix.com>,
	<stefano.stabellini@eu.citrix.com>, <ian.campbell@citrix.com>,
	<wei.liu2@citrix.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
X-DLP: MIA1
Cc: dario.faggioli@citrix.com, ufimtseva@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 02/12/14 21:34, Boris Ostrovsky wrote:
>  /* XEN_SYSCTL_topologyinfo */
>  #define INVALID_TOPOLOGY_ID  (~0U)
> +
> +struct xen_sysctl_cputopo {
> +    uint32_t core;
> +    uint32_t socket;
> +    uint32_t node;
> +};
> +typedef struct xen_sysctl_cputopo xen_sysctl_cputopo_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cputopo_t);
> +
> +struct xen_sysctl_iotopo {
> +    uint16_t seg;
> +    uint8_t bus;
> +    uint8_t devfn;
> +    uint32_t node;
> +};
> +typedef struct xen_sysctl_iotopo xen_sysctl_iotopo_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_sysctl_iotopo_t);
> +
>  struct xen_sysctl_topologyinfo {
>      /*
>       * IN: maximum addressable entry in the caller-provided arrays.
> -     * OUT: largest cpu identifier in the system.
> +     * OUT: largest cpu identifier or max number of devices 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;
> +    uint32_t max_devs;
>  
>      /*
>       * 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:
> +     * for each cpu and/or node for each PCI device.
> +     * If information for a particular entry is not avalable it is set to
> +     * INVALID_TOPOLOGY_ID.
> +     * The number of array elements for CPU topology written by the sysctl is:
>       *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
>       */
> -    XEN_GUEST_HANDLE_64(uint32) cpu_to_core;
> -    XEN_GUEST_HANDLE_64(uint32) cpu_to_socket;
> -    XEN_GUEST_HANDLE_64(uint32) cpu_to_node;
> +    XEN_GUEST_HANDLE_64(xen_sysctl_cputopo_t) cputopo;
> +    XEN_GUEST_HANDLE_64(xen_sysctl_iotopo_t) iotopo;

These are inherently lists with different indicies.  They should not
conglomerated like this.

I would suggest introducing a new hypercall (xen_sysctl_iotopologyinfo
?) and leave this one alone.

~Andrew

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:37:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwByl-0000FF-F5; Wed, 03 Dec 2014 15:36:35 +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 1XwByk-0000FA-DB
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:36:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4A/02-09842-10E2F745; Wed, 03 Dec 2014 15:36:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417620991!13202104!1
X-Originating-IP: [156.151.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 24663 invoked from network); 3 Dec 2014 15:36:33 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 15:36: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 sB3FaHiD009421
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 15:36:21 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
	sB3FaGmn009608
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 15:36:17 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
	sB3FaF79010331; Wed, 3 Dec 2014 15:36:15 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 ; Wed, 03 Dec 2014 07:36:15 -0800
Message-ID: <547F2E57.7010300@oracle.com>
Date: Wed, 03 Dec 2014 10:37: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>, jbeulich@suse.com, keir@xen.org,
	ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, wei.liu2@citrix.com
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<547F2A5B.9060407@citrix.com>
In-Reply-To: <547F2A5B.9060407@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: dario.faggioli@citrix.com, ufimtseva@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 12/03/2014 10:20 AM, Andrew Cooper wrote:
> On 02/12/14 21:34, Boris Ostrovsky wrote:
>>   /* XEN_SYSCTL_topologyinfo */
>>   #define INVALID_TOPOLOGY_ID  (~0U)
>> +
>> +struct xen_sysctl_cputopo {
>> +    uint32_t core;
>> +    uint32_t socket;
>> +    uint32_t node;
>> +};
>> +typedef struct xen_sysctl_cputopo xen_sysctl_cputopo_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cputopo_t);
>> +
>> +struct xen_sysctl_iotopo {
>> +    uint16_t seg;
>> +    uint8_t bus;
>> +    uint8_t devfn;
>> +    uint32_t node;
>> +};
>> +typedef struct xen_sysctl_iotopo xen_sysctl_iotopo_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_sysctl_iotopo_t);
>> +
>>   struct xen_sysctl_topologyinfo {
>>       /*
>>        * IN: maximum addressable entry in the caller-provided arrays.
>> -     * OUT: largest cpu identifier in the system.
>> +     * OUT: largest cpu identifier or max number of devices 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;
>> +    uint32_t max_devs;
>>   
>>       /*
>>        * 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:
>> +     * for each cpu and/or node for each PCI device.
>> +     * If information for a particular entry is not avalable it is set to
>> +     * INVALID_TOPOLOGY_ID.
>> +     * The number of array elements for CPU topology written by the sysctl is:
>>        *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
>>        */
>> -    XEN_GUEST_HANDLE_64(uint32) cpu_to_core;
>> -    XEN_GUEST_HANDLE_64(uint32) cpu_to_socket;
>> -    XEN_GUEST_HANDLE_64(uint32) cpu_to_node;
>> +    XEN_GUEST_HANDLE_64(xen_sysctl_cputopo_t) cputopo;
>> +    XEN_GUEST_HANDLE_64(xen_sysctl_iotopo_t) iotopo;
> These are inherently lists with different indicies.  They should not
> conglomerated like this.


I don't follow this. These are indeed lists with different indicies but 
why can't they both be part of this struct?

-boris

>
> I would suggest introducing a new hypercall (xen_sysctl_iotopologyinfo
> ?) and leave this one alone.
>
> ~Andrew


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:37:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwByl-0000FF-F5; Wed, 03 Dec 2014 15:36:35 +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 1XwByk-0000FA-DB
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:36:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4A/02-09842-10E2F745; Wed, 03 Dec 2014 15:36:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417620991!13202104!1
X-Originating-IP: [156.151.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 24663 invoked from network); 3 Dec 2014 15:36:33 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 15:36: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 sB3FaHiD009421
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 15:36:21 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
	sB3FaGmn009608
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 15:36:17 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
	sB3FaF79010331; Wed, 3 Dec 2014 15:36:15 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 ; Wed, 03 Dec 2014 07:36:15 -0800
Message-ID: <547F2E57.7010300@oracle.com>
Date: Wed, 03 Dec 2014 10:37: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>, jbeulich@suse.com, keir@xen.org,
	ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, wei.liu2@citrix.com
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<547F2A5B.9060407@citrix.com>
In-Reply-To: <547F2A5B.9060407@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: dario.faggioli@citrix.com, ufimtseva@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 12/03/2014 10:20 AM, Andrew Cooper wrote:
> On 02/12/14 21:34, Boris Ostrovsky wrote:
>>   /* XEN_SYSCTL_topologyinfo */
>>   #define INVALID_TOPOLOGY_ID  (~0U)
>> +
>> +struct xen_sysctl_cputopo {
>> +    uint32_t core;
>> +    uint32_t socket;
>> +    uint32_t node;
>> +};
>> +typedef struct xen_sysctl_cputopo xen_sysctl_cputopo_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cputopo_t);
>> +
>> +struct xen_sysctl_iotopo {
>> +    uint16_t seg;
>> +    uint8_t bus;
>> +    uint8_t devfn;
>> +    uint32_t node;
>> +};
>> +typedef struct xen_sysctl_iotopo xen_sysctl_iotopo_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_sysctl_iotopo_t);
>> +
>>   struct xen_sysctl_topologyinfo {
>>       /*
>>        * IN: maximum addressable entry in the caller-provided arrays.
>> -     * OUT: largest cpu identifier in the system.
>> +     * OUT: largest cpu identifier or max number of devices 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;
>> +    uint32_t max_devs;
>>   
>>       /*
>>        * 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:
>> +     * for each cpu and/or node for each PCI device.
>> +     * If information for a particular entry is not avalable it is set to
>> +     * INVALID_TOPOLOGY_ID.
>> +     * The number of array elements for CPU topology written by the sysctl is:
>>        *   min(@max_cpu_index_IN,@max_cpu_index_OUT)+1
>>        */
>> -    XEN_GUEST_HANDLE_64(uint32) cpu_to_core;
>> -    XEN_GUEST_HANDLE_64(uint32) cpu_to_socket;
>> -    XEN_GUEST_HANDLE_64(uint32) cpu_to_node;
>> +    XEN_GUEST_HANDLE_64(xen_sysctl_cputopo_t) cputopo;
>> +    XEN_GUEST_HANDLE_64(xen_sysctl_iotopo_t) iotopo;
> These are inherently lists with different indicies.  They should not
> conglomerated like this.


I don't follow this. These are indeed lists with different indicies but 
why can't they both be part of this struct?

-boris

>
> I would suggest introducing a new hypercall (xen_sysctl_iotopologyinfo
> ?) and leave this one alone.
>
> ~Andrew


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:37:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15:37:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwBzh-0000IY-T0; Wed, 03 Dec 2014 15:37:33 +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 1XwBzg-0000IK-Ch
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 15:37:32 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	19/D9-02954-B3E2F745; Wed, 03 Dec 2014 15:37:31 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417621049!8116062!1
X-Originating-IP: [156.151.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 12348 invoked from network); 3 Dec 2014 15:37:30 -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; 3 Dec 2014 15:37: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 sB3FbN9u010917
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 15:37:24 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
	sB3FbMoH011778
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 15:37:23 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
	sB3FbMMA011771; Wed, 3 Dec 2014 15:37:22 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 07:37:22 -0800
Date: Wed, 3 Dec 2014 16:37:17 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <20141203153717.GM16236@olila.local.net-space.pl>
References: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
	<547DE1BD02000078000C2DEF@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547DE1BD02000078000C2DEF@mail.emea.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] console: increase initial
	conring 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, Dec 02, 2014 at 03:58:53PM +0000, Jan Beulich wrote:
> >>> Daniel Kiper <daniel.kiper@oracle.com> 12/02/14 3:58 PM >>>
> >In general initial conring size is sufficient. However, if log
> >level is increased on platforms which have e.g. huge number
> >of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
> >which has more than 200 entries in EFI memory map) then some
> >of earlier messages in console ring are overwritten. It means
> >that in case of issues deeper analysis can be hindered. Sadly
> >conring_size argument does not help because new console buffer
> >is allocated late on heap. It means that it is not possible to
> >allocate larger ring earlier. So, in this situation initial
> >conring size should be increased. My experiments showed that
> >even on not so big machines more than 26 KiB of free space are
> >needed for initial messages. In theory we could increase conring
> >size buffer to 32 KiB. However, I think that this value could be
> >too small for huge machines with large number of ACPI tables and
> >EFI memory regions. Hence, this patch increases initial conring
> >size to 64 KiB.
> >
> >Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>
> I think it was made clear before that just saying "for-xen-4.5" without any
> further rationale is insufficient. Please explain what makes this so important
> a change that it needs to go in now.

What is not clear in commit message? It describes a bug, how to fix it
and why in that way. Do you need anything else?

> Apart from that, as Olaf validly replied, setting up a dynamically allocated
> buffer earlier would seem like a much better course of action.

I though about that before posting this patch (I did not know beforehand about
Olaf's work made in 2011). However, I stated that it is too late to make so
intrusive changes. I think we should (sadly) apply this "band-aid" right
now because, as you can see, this bug hits more and more people. On the
other hand I agree that we should finally fix this issue in better way.
Even I am able to add this thing to my TODO list but it is quite long
so I do not know when it will happen.

Daniel

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:37:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15:37:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwBzh-0000IY-T0; Wed, 03 Dec 2014 15:37:33 +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 1XwBzg-0000IK-Ch
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 15:37:32 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	19/D9-02954-B3E2F745; Wed, 03 Dec 2014 15:37:31 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417621049!8116062!1
X-Originating-IP: [156.151.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 12348 invoked from network); 3 Dec 2014 15:37:30 -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; 3 Dec 2014 15:37: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 sB3FbN9u010917
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 15:37:24 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
	sB3FbMoH011778
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 15:37:23 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
	sB3FbMMA011771; Wed, 3 Dec 2014 15:37:22 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 07:37:22 -0800
Date: Wed, 3 Dec 2014 16:37:17 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <20141203153717.GM16236@olila.local.net-space.pl>
References: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
	<547DE1BD02000078000C2DEF@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547DE1BD02000078000C2DEF@mail.emea.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] console: increase initial
	conring 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, Dec 02, 2014 at 03:58:53PM +0000, Jan Beulich wrote:
> >>> Daniel Kiper <daniel.kiper@oracle.com> 12/02/14 3:58 PM >>>
> >In general initial conring size is sufficient. However, if log
> >level is increased on platforms which have e.g. huge number
> >of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
> >which has more than 200 entries in EFI memory map) then some
> >of earlier messages in console ring are overwritten. It means
> >that in case of issues deeper analysis can be hindered. Sadly
> >conring_size argument does not help because new console buffer
> >is allocated late on heap. It means that it is not possible to
> >allocate larger ring earlier. So, in this situation initial
> >conring size should be increased. My experiments showed that
> >even on not so big machines more than 26 KiB of free space are
> >needed for initial messages. In theory we could increase conring
> >size buffer to 32 KiB. However, I think that this value could be
> >too small for huge machines with large number of ACPI tables and
> >EFI memory regions. Hence, this patch increases initial conring
> >size to 64 KiB.
> >
> >Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>
> I think it was made clear before that just saying "for-xen-4.5" without any
> further rationale is insufficient. Please explain what makes this so important
> a change that it needs to go in now.

What is not clear in commit message? It describes a bug, how to fix it
and why in that way. Do you need anything else?

> Apart from that, as Olaf validly replied, setting up a dynamically allocated
> buffer earlier would seem like a much better course of action.

I though about that before posting this patch (I did not know beforehand about
Olaf's work made in 2011). However, I stated that it is too late to make so
intrusive changes. I think we should (sadly) apply this "band-aid" right
now because, as you can see, this bug hits more and more people. On the
other hand I agree that we should finally fix this issue in better way.
Even I am able to add this thing to my TODO list but it is quite long
so I do not know when it will happen.

Daniel

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:39:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwC1U-0000QR-Bf; Wed, 03 Dec 2014 15:39:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.haxby@oracle.com>) id 1XwC1T-0000QH-AK
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:39:23 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	3D/0E-24859-AAE2F745; Wed, 03 Dec 2014 15:39:22 +0000
X-Env-Sender: john.haxby@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417621160!10908759!1
X-Originating-IP: [156.151.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 30500 invoked from network); 3 Dec 2014 15:39:21 -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; 3 Dec 2014 15:39:21 -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 sB3FdHpi013658
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 15:39:18 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
	sB3FdH1r020583
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 15:39: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
	sB3FdGjD020571; Wed, 3 Dec 2014 15:39:17 GMT
Received: from sheep.uk.oracle.com (/10.175.197.246)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 07:39:16 -0800
Message-ID: <547F2EA2.5030702@oracle.com>
Date: Wed, 03 Dec 2014 15:39:14 +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: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>	<1417444646-20636-2-git-send-email-john.haxby@oracle.com>
	<547CA220.9070604@citrix.com>
In-Reply-To: <547CA220.9070604@citrix.com>
Content-Length: 3713
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: Re: [Xen-devel] [PATCH 1/2] xen-detect: fix strict-aliasing
 compilation warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDEvMTIvMTQgMTc6MTUsIEFuZHJldyBDb29wZXIgd3JvdGU6Cj4gT24gMDEvMTIvMTQgMTQ6
MzcsIEpvaG4gSGF4Ynkgd3JvdGU6Cj4+IFdpdGggZ2NjIDQuOC4zLCBjb21waWxpbmcgeGVuLWRl
dGVjdCBnaXZlcyBhIGNvbXBpbGF0aW9uIHdhcm5pbmcgaWYKPj4geW91J3JlIG9wdGltaXNpbmc6
Cj4+Cj4+ICQgY2MgLVdhbGwgLU9zIHhlbi1kZXRlY3QuYwo+PiB4ZW4tZGV0ZWN0LmM6IEluIGZ1
bmN0aW9uIOKAmGNoZWNrX2Zvcl94ZW7igJk6Cj4+IHhlbi1kZXRlY3QuYzo2NTo5OiB3YXJuaW5n
OiBkZXJlZmVyZW5jaW5nIHR5cGUtcHVubmVkIHBvaW50ZXIgd2lsbCBicmVhawo+PiBzdHJpY3Qt
YWxpYXNpbmcgcnVsZXMgWy1Xc3RyaWN0LWFsaWFzaW5nXQo+PiAgICAgICAgICAqKHVpbnQzMl90
ICopKHNpZ25hdHVyZSArIDApID0gcmVnc1sxXTsKPj4gICAgICAgICAgXgo+Pgo+PiBTaWduZWQt
b2ZmLWJ5OiBKb2huIEhheGJ5IDxqb2huLmhheGJ5QG9yYWNsZS5jb20+Cj4gCj4gV2h5IGFyZSB5
b3UgY29tcGlsaW5nIHdpdGhvdXQgdGhlIENGTEFHUyBmcm9tIHRoZSBYZW4gYnVpbGQgc3lzdGVt
Pwo+IAo+IFdlIGV4cGxpY2l0bHkgZGlzYWJsZSBzdHJpY3QgYWxpYXMgb3B0aW1pc2F0aW9ucywg
YmVjYXVzZSBvcHRpbWlzYXRpb25zCj4gYmFzZWQgdXBvbiB0aGUgYWxpYXNpbmcgcnVsZXMgaW4g
QyBpcyBtYWQuICBFdmVuIHdoZW4geW91IGVsaW1pbmF0ZSBhbGwKPiB0aGUgd2FybmluZ3MsIHRo
ZXJlIGFyZSBzdGlsbCBzdWJ0bGUgYnVncyBiZWNhdXNlIHRoZSBjb21waWxlciBpcyBmcmVlCj4g
dG8gYXNzdW1lIGEgbG90IG1vcmUgdGhhbiBhIHByb2dyYW1tZXIgd291bGQgdHlwaWNhbGx5IGRl
ZW0gcmVhc29uYWJsZS4KCkRvIHlvdSB3YW50IG1lIHRvIHJlcG9zdCB0aGUgc2Vjb25kIHBhdGNo
ICh0aGUgYWN0dWFsIGJ1ZyBmaXggb25lKSBzbwp0aGF0IGl0IGRvZXNuJ3QgYXNzdW1lIHRoZSBs
aW5lIG51bWJlciBjaGFuZ2VzIGFuZCB3aGF0bm90IGZvciB0aGlzIG9uZT8KCmpjaAoKCj4gCj4g
fkFuZHJldwo+IAo+PiAtLS0KPj4gIHRvb2xzL21pc2MveGVuLWRldGVjdC5jIHwgMjEgKysrKysr
KysrKy0tLS0tLS0tLS0tCj4+ICAxIGZpbGUgY2hhbmdlZCwgMTAgaW5zZXJ0aW9ucygrKSwgMTEg
ZGVsZXRpb25zKC0pCj4+Cj4+IGRpZmYgLS1naXQgYS90b29scy9taXNjL3hlbi1kZXRlY3QuYyBi
L3Rvb2xzL21pc2MveGVuLWRldGVjdC5jCj4+IGluZGV4IDc4N2I1ZGEuLjE5YzY2ZDEgMTAwNjQ0
Cj4+IC0tLSBhL3Rvb2xzL21pc2MveGVuLWRldGVjdC5jCj4+ICsrKyBiL3Rvb2xzL21pc2MveGVu
LWRldGVjdC5jCj4+IEBAIC01NCwyOCArNTQsMjcgQEAgc3RhdGljIHZvaWQgY3B1aWQodWludDMy
X3QgaWR4LCB1aW50MzJfdCAqcmVncywgaW50IHB2X2NvbnRleHQpCj4+ICAKPj4gIHN0YXRpYyBp
bnQgY2hlY2tfZm9yX3hlbihpbnQgcHZfY29udGV4dCkKPj4gIHsKPj4gLSAgICB1aW50MzJfdCBy
ZWdzWzRdOwo+PiAtICAgIGNoYXIgc2lnbmF0dXJlWzEzXTsKPj4gKyAgICB1bmlvbgo+PiArICAg
IHsKPj4gKyAgICAgICAgdWludDMyX3QgcmVnc1s0XTsKPj4gKyAgICAgICAgY2hhciBzaWduYXR1
cmVbMTddOwo+PiArICAgIH0gdTsKPj4gICAgICB1aW50MzJfdCBiYXNlOwo+PiAgCj4+ICAgICAg
Zm9yICggYmFzZSA9IDB4NDAwMDAwMDA7IGJhc2UgPCAweDQwMDEwMDAwOyBiYXNlICs9IDB4MTAw
ICkKPj4gICAgICB7Cj4+IC0gICAgICAgIGNwdWlkKGJhc2UsIHJlZ3MsIHB2X2NvbnRleHQpOwo+
PiAtCj4+IC0gICAgICAgICoodWludDMyX3QgKikoc2lnbmF0dXJlICsgMCkgPSByZWdzWzFdOwo+
PiAtICAgICAgICAqKHVpbnQzMl90ICopKHNpZ25hdHVyZSArIDQpID0gcmVnc1syXTsKPj4gLSAg
ICAgICAgKih1aW50MzJfdCAqKShzaWduYXR1cmUgKyA4KSA9IHJlZ3NbM107Cj4+IC0gICAgICAg
IHNpZ25hdHVyZVsxMl0gPSAnXDAnOwo+PiArICAgICAgICBjcHVpZChiYXNlLCB1LnJlZ3MsIHB2
X2NvbnRleHQpOwo+PiArICAgICAgICB1LnNpZ25hdHVyZVsxNl0gPSAnXDAnOwo+PiAgCj4+IC0g
ICAgICAgIGlmICggIXN0cmNtcCgiWGVuVk1NWGVuVk1NIiwgc2lnbmF0dXJlKSAmJiAocmVnc1sw
XSA+PSAoYmFzZSArIDIpKSApCj4+ICsgICAgICAgIGlmICggIXN0cmNtcCgiWGVuVk1NWGVuVk1N
IiwgdS5zaWduYXR1cmUrNCkgJiYgKHUucmVnc1swXSA+PSAoYmFzZSArIDIpKSApCj4+ICAgICAg
ICAgICAgICBnb3RvIGZvdW5kOwo+PiAgICAgIH0KPj4gIAo+PiAgICAgIHJldHVybiAwOwo+PiAg
Cj4+ICAgZm91bmQ6Cj4+IC0gICAgY3B1aWQoYmFzZSArIDEsIHJlZ3MsIHB2X2NvbnRleHQpOwo+
PiAtICAgIHJldHVybiByZWdzWzBdOwo+PiArICAgIGNwdWlkKGJhc2UgKyAxLCB1LnJlZ3MsIHB2
X2NvbnRleHQpOwo+PiArICAgIHJldHVybiB1LnJlZ3NbMF07Cj4+ICB9Cj4+ICAKPj4gIHN0YXRp
YyBqbXBfYnVmIHNpZ2lsbF9qbXA7Cj4gCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRl
dmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKPiAKCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:39:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwC1U-0000QR-Bf; Wed, 03 Dec 2014 15:39:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.haxby@oracle.com>) id 1XwC1T-0000QH-AK
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:39:23 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	3D/0E-24859-AAE2F745; Wed, 03 Dec 2014 15:39:22 +0000
X-Env-Sender: john.haxby@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417621160!10908759!1
X-Originating-IP: [156.151.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 30500 invoked from network); 3 Dec 2014 15:39:21 -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; 3 Dec 2014 15:39:21 -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 sB3FdHpi013658
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 15:39:18 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
	sB3FdH1r020583
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 15:39: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
	sB3FdGjD020571; Wed, 3 Dec 2014 15:39:17 GMT
Received: from sheep.uk.oracle.com (/10.175.197.246)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 07:39:16 -0800
Message-ID: <547F2EA2.5030702@oracle.com>
Date: Wed, 03 Dec 2014 15:39:14 +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: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>	<1417444646-20636-2-git-send-email-john.haxby@oracle.com>
	<547CA220.9070604@citrix.com>
In-Reply-To: <547CA220.9070604@citrix.com>
Content-Length: 3713
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: Re: [Xen-devel] [PATCH 1/2] xen-detect: fix strict-aliasing
 compilation warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDEvMTIvMTQgMTc6MTUsIEFuZHJldyBDb29wZXIgd3JvdGU6Cj4gT24gMDEvMTIvMTQgMTQ6
MzcsIEpvaG4gSGF4Ynkgd3JvdGU6Cj4+IFdpdGggZ2NjIDQuOC4zLCBjb21waWxpbmcgeGVuLWRl
dGVjdCBnaXZlcyBhIGNvbXBpbGF0aW9uIHdhcm5pbmcgaWYKPj4geW91J3JlIG9wdGltaXNpbmc6
Cj4+Cj4+ICQgY2MgLVdhbGwgLU9zIHhlbi1kZXRlY3QuYwo+PiB4ZW4tZGV0ZWN0LmM6IEluIGZ1
bmN0aW9uIOKAmGNoZWNrX2Zvcl94ZW7igJk6Cj4+IHhlbi1kZXRlY3QuYzo2NTo5OiB3YXJuaW5n
OiBkZXJlZmVyZW5jaW5nIHR5cGUtcHVubmVkIHBvaW50ZXIgd2lsbCBicmVhawo+PiBzdHJpY3Qt
YWxpYXNpbmcgcnVsZXMgWy1Xc3RyaWN0LWFsaWFzaW5nXQo+PiAgICAgICAgICAqKHVpbnQzMl90
ICopKHNpZ25hdHVyZSArIDApID0gcmVnc1sxXTsKPj4gICAgICAgICAgXgo+Pgo+PiBTaWduZWQt
b2ZmLWJ5OiBKb2huIEhheGJ5IDxqb2huLmhheGJ5QG9yYWNsZS5jb20+Cj4gCj4gV2h5IGFyZSB5
b3UgY29tcGlsaW5nIHdpdGhvdXQgdGhlIENGTEFHUyBmcm9tIHRoZSBYZW4gYnVpbGQgc3lzdGVt
Pwo+IAo+IFdlIGV4cGxpY2l0bHkgZGlzYWJsZSBzdHJpY3QgYWxpYXMgb3B0aW1pc2F0aW9ucywg
YmVjYXVzZSBvcHRpbWlzYXRpb25zCj4gYmFzZWQgdXBvbiB0aGUgYWxpYXNpbmcgcnVsZXMgaW4g
QyBpcyBtYWQuICBFdmVuIHdoZW4geW91IGVsaW1pbmF0ZSBhbGwKPiB0aGUgd2FybmluZ3MsIHRo
ZXJlIGFyZSBzdGlsbCBzdWJ0bGUgYnVncyBiZWNhdXNlIHRoZSBjb21waWxlciBpcyBmcmVlCj4g
dG8gYXNzdW1lIGEgbG90IG1vcmUgdGhhbiBhIHByb2dyYW1tZXIgd291bGQgdHlwaWNhbGx5IGRl
ZW0gcmVhc29uYWJsZS4KCkRvIHlvdSB3YW50IG1lIHRvIHJlcG9zdCB0aGUgc2Vjb25kIHBhdGNo
ICh0aGUgYWN0dWFsIGJ1ZyBmaXggb25lKSBzbwp0aGF0IGl0IGRvZXNuJ3QgYXNzdW1lIHRoZSBs
aW5lIG51bWJlciBjaGFuZ2VzIGFuZCB3aGF0bm90IGZvciB0aGlzIG9uZT8KCmpjaAoKCj4gCj4g
fkFuZHJldwo+IAo+PiAtLS0KPj4gIHRvb2xzL21pc2MveGVuLWRldGVjdC5jIHwgMjEgKysrKysr
KysrKy0tLS0tLS0tLS0tCj4+ICAxIGZpbGUgY2hhbmdlZCwgMTAgaW5zZXJ0aW9ucygrKSwgMTEg
ZGVsZXRpb25zKC0pCj4+Cj4+IGRpZmYgLS1naXQgYS90b29scy9taXNjL3hlbi1kZXRlY3QuYyBi
L3Rvb2xzL21pc2MveGVuLWRldGVjdC5jCj4+IGluZGV4IDc4N2I1ZGEuLjE5YzY2ZDEgMTAwNjQ0
Cj4+IC0tLSBhL3Rvb2xzL21pc2MveGVuLWRldGVjdC5jCj4+ICsrKyBiL3Rvb2xzL21pc2MveGVu
LWRldGVjdC5jCj4+IEBAIC01NCwyOCArNTQsMjcgQEAgc3RhdGljIHZvaWQgY3B1aWQodWludDMy
X3QgaWR4LCB1aW50MzJfdCAqcmVncywgaW50IHB2X2NvbnRleHQpCj4+ICAKPj4gIHN0YXRpYyBp
bnQgY2hlY2tfZm9yX3hlbihpbnQgcHZfY29udGV4dCkKPj4gIHsKPj4gLSAgICB1aW50MzJfdCBy
ZWdzWzRdOwo+PiAtICAgIGNoYXIgc2lnbmF0dXJlWzEzXTsKPj4gKyAgICB1bmlvbgo+PiArICAg
IHsKPj4gKyAgICAgICAgdWludDMyX3QgcmVnc1s0XTsKPj4gKyAgICAgICAgY2hhciBzaWduYXR1
cmVbMTddOwo+PiArICAgIH0gdTsKPj4gICAgICB1aW50MzJfdCBiYXNlOwo+PiAgCj4+ICAgICAg
Zm9yICggYmFzZSA9IDB4NDAwMDAwMDA7IGJhc2UgPCAweDQwMDEwMDAwOyBiYXNlICs9IDB4MTAw
ICkKPj4gICAgICB7Cj4+IC0gICAgICAgIGNwdWlkKGJhc2UsIHJlZ3MsIHB2X2NvbnRleHQpOwo+
PiAtCj4+IC0gICAgICAgICoodWludDMyX3QgKikoc2lnbmF0dXJlICsgMCkgPSByZWdzWzFdOwo+
PiAtICAgICAgICAqKHVpbnQzMl90ICopKHNpZ25hdHVyZSArIDQpID0gcmVnc1syXTsKPj4gLSAg
ICAgICAgKih1aW50MzJfdCAqKShzaWduYXR1cmUgKyA4KSA9IHJlZ3NbM107Cj4+IC0gICAgICAg
IHNpZ25hdHVyZVsxMl0gPSAnXDAnOwo+PiArICAgICAgICBjcHVpZChiYXNlLCB1LnJlZ3MsIHB2
X2NvbnRleHQpOwo+PiArICAgICAgICB1LnNpZ25hdHVyZVsxNl0gPSAnXDAnOwo+PiAgCj4+IC0g
ICAgICAgIGlmICggIXN0cmNtcCgiWGVuVk1NWGVuVk1NIiwgc2lnbmF0dXJlKSAmJiAocmVnc1sw
XSA+PSAoYmFzZSArIDIpKSApCj4+ICsgICAgICAgIGlmICggIXN0cmNtcCgiWGVuVk1NWGVuVk1N
IiwgdS5zaWduYXR1cmUrNCkgJiYgKHUucmVnc1swXSA+PSAoYmFzZSArIDIpKSApCj4+ICAgICAg
ICAgICAgICBnb3RvIGZvdW5kOwo+PiAgICAgIH0KPj4gIAo+PiAgICAgIHJldHVybiAwOwo+PiAg
Cj4+ICAgZm91bmQ6Cj4+IC0gICAgY3B1aWQoYmFzZSArIDEsIHJlZ3MsIHB2X2NvbnRleHQpOwo+
PiAtICAgIHJldHVybiByZWdzWzBdOwo+PiArICAgIGNwdWlkKGJhc2UgKyAxLCB1LnJlZ3MsIHB2
X2NvbnRleHQpOwo+PiArICAgIHJldHVybiB1LnJlZ3NbMF07Cj4+ICB9Cj4+ICAKPj4gIHN0YXRp
YyBqbXBfYnVmIHNpZ2lsbF9qbXA7Cj4gCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRl
dmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKPiAKCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:45:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15:45:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwC6r-0000dt-4J; Wed, 03 Dec 2014 15:44:57 +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 1XwC6p-0000do-S5
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:44:56 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	0D/6A-19763-7FF2F745; Wed, 03 Dec 2014 15:44:55 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417621491!5933174!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 10125 invoked from network); 3 Dec 2014 15:44:53 -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;
	3 Dec 2014 15:44:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; 
	d="scan'208,217";a="199452291"
Message-ID: <547F2FF0.9000201@citrix.com>
Date: Wed, 3 Dec 2014 15:44: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: John Haxby <john.haxby@oracle.com>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
	<1417444646-20636-2-git-send-email-john.haxby@oracle.com>
	<547CA220.9070604@citrix.com>
	<309AAB3D-A4EE-485C-BE09-AAC4192E7F27@oracle.com>
In-Reply-To: <309AAB3D-A4EE-485C-BE09-AAC4192E7F27@oracle.com>
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] xen-detect: fix strict-aliasing
 compilation warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6305509876595795036=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6305509876595795036==
Content-Type: multipart/alternative;
	boundary="------------050902070405050302090504"

--------------050902070405050302090504
Content-Type: text/plain; charset="utf-8"
Content-Length: 1722
Content-Transfer-Encoding: quoted-printable

On 01/12/14 18:45, John Haxby wrote:
>
>> On 1 Dec 2014, at 17:15, Andrew Cooper <andrew.cooper3@citrix.com
>> <mailto:andrew.cooper3@citrix.com>> wrote:
>>
>> On 01/12/14 14:37, John Haxby wrote:
>>> With gcc 4.8.3, compiling xen-detect gives a compilation warning if
>>> you're optimising:
>>>
>>> $ cc -Wall -Os xen-detect.c
>>> xen-detect.c: In function =E2=80=98check_for_xen=E2=80=99:
>>> xen-detect.c:65:9: warning: dereferencing type-punned pointer will break
>>> strict-aliasing rules [-Wstrict-aliasing]
>>>         *(uint32_t *)(signature + 0) =3D regs[1];
>>>         ^
>>>
>>> Signed-off-by: John Haxby <john.haxby@oracle.com
>>> <mailto:john.haxby@oracle.com>>
>>
>> Why are you compiling without the CFLAGS from the Xen build system=3F
>>
>> We explicitly disable strict alias optimisations, because optimisations
>> based upon the aliasing rules in C is mad.  Even when you eliminate all
>> the warnings, there are still subtle bugs because the compiler is free
>> to assume a lot more than a programmer would typically deem reasonable.
>
>
> I wasn=E2=80=99t building the whole system, I just wanted xen-detect so I
> pulled it out and compiled it; I usually use "-Wall -Os=E2=80=9D because the
> combination finds problems I might otherwise overlook.   The patch
> also removes three lines of code :) but you can take it or leave it as
> you choose.   The other patch =E2=80=94 reversing the code of pv and hvm
> checking =E2=80=94 was the real problem.
>
> jch

I feel it would be neater to fix this by using the
XEN_CPUID_SIGNATURE_E{B,C,D}X constants from the API.  This fixes the
strict aliasing, and does away with the string handling completely.

~Andrew

--------------050902070405050302090504
Content-Type: text/html; charset="utf-8"
Content-Length: 9822
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 01/12/14 18:45, John Haxby wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:309AAB3D-A4EE-485C-BE09-AAC4192E7F27@oracle.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
      <br class=3D"">
      <div>
        <blockquote type=3D"cite" class=3D"">
          <div class=3D"">On 1 Dec 2014, at 17:15, Andrew Cooper &lt;<a
              moz-do-not-send=3D"true"
              href=3D"mailto:andrew.cooper3@citrix.com" class=3D"">andrew.cooper3@citrix.com</a>&gt;
            wrote:</div>
          <br class=3D"Apple-interchange-newline">
          <div class=3D""><span style=3D"font-family: Menlo-Regular;
              font-size: 11px; font-style: normal; font-variant: normal;
              font-weight: normal; letter-spacing: normal; line-height:
              normal; orphans: auto; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal; widows:
              auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
              float: none; display: inline !important;" class=3D"">On
              01/12/14 14:37, John Haxby wrote:</span><br
              style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <blockquote type=3D"cite" style=3D"font-family: Menlo-Regular;
              font-size: 11px; font-style: normal; font-variant: normal;
              font-weight: normal; letter-spacing: normal; line-height:
              normal; orphans: auto; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal; widows:
              auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">With gcc 4.8.3, compiling xen-detect gives a
              compilation warning if<br class=3D"">
              you're optimising:<br class=3D"">
              <br class=3D"">
              $ cc -Wall -Os xen-detect.c<br class=3D"">
              xen-detect.c: In function =E2=80=98check_for_xen=E2=80=99:<br class=3D"">
              xen-detect.c:65:9: warning: dereferencing type-punned
              pointer will break<br class=3D"">
              strict-aliasing rules [-Wstrict-aliasing]<br class=3D"">
              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*(uint32_t *)(signature + 0) =3D regs[1];<br
                class=3D"">
              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0^<br class=3D"">
              <br class=3D"">
              Signed-off-by: John Haxby &lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:john.haxby@oracle.com" class=3D"">john.haxby@oracle.com</a>&gt;<br
                class=3D"">
            </blockquote>
            <br style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <span style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px; float:
              none; display: inline !important;" class=3D"">Why are you
              compiling without the CFLAGS from the Xen build system=3F</span><br
              style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <br style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <span style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px; float:
              none; display: inline !important;" class=3D"">We explicitly
              disable strict alias optimisations, because optimisations</span><br
              style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <span style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px; float:
              none; display: inline !important;" class=3D"">based upon the
              aliasing rules in C is mad. =C2=A0Even when you eliminate all</span><br
              style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <span style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px; float:
              none; display: inline !important;" class=3D"">the warnings,
              there are still subtle bugs because the compiler is free</span><br
              style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <span style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px; float:
              none; display: inline !important;" class=3D"">to assume a
              lot more than a programmer would typically deem
              reasonable.</span></div>
        </blockquote>
      </div>
      <br class=3D"">
      <div class=3D""><br class=3D"">
      </div>
      <div class=3D"">I wasn=E2=80=99t building the whole system, I just wanted
        xen-detect so I pulled it out and compiled it; I usually use
        "-Wall -Os=E2=80=9D because the combination finds problems I might
        otherwise overlook. =C2=A0 The patch also removes three lines of code
        :) but you can take it or leave it as you choose. =C2=A0 The other
        patch =E2=80=94 reversing the code of pv and hvm checking =E2=80=94 was the real
        problem.</div>
      <div class=3D""><br class=3D"">
      </div>
      <div class=3D"">jch</div>
    </blockquote>
    <br>
    I feel it would be neater to fix this by using the
    XEN_CPUID_SIGNATURE_E{B,C,D}X constants from the API.=C2=A0 This fixes
    the strict aliasing, and does away with the string handling
    completely.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------050902070405050302090504--


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

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

--===============6305509876595795036==--


From xen-devel-bounces@lists.xen.org Wed Dec 03 15:45:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15:45:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwC6r-0000dt-4J; Wed, 03 Dec 2014 15:44:57 +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 1XwC6p-0000do-S5
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:44:56 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	0D/6A-19763-7FF2F745; Wed, 03 Dec 2014 15:44:55 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417621491!5933174!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 10125 invoked from network); 3 Dec 2014 15:44:53 -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;
	3 Dec 2014 15:44:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; 
	d="scan'208,217";a="199452291"
Message-ID: <547F2FF0.9000201@citrix.com>
Date: Wed, 3 Dec 2014 15:44: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: John Haxby <john.haxby@oracle.com>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
	<1417444646-20636-2-git-send-email-john.haxby@oracle.com>
	<547CA220.9070604@citrix.com>
	<309AAB3D-A4EE-485C-BE09-AAC4192E7F27@oracle.com>
In-Reply-To: <309AAB3D-A4EE-485C-BE09-AAC4192E7F27@oracle.com>
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] xen-detect: fix strict-aliasing
 compilation warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6305509876595795036=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6305509876595795036==
Content-Type: multipart/alternative;
	boundary="------------050902070405050302090504"

--------------050902070405050302090504
Content-Type: text/plain; charset="utf-8"
Content-Length: 1722
Content-Transfer-Encoding: quoted-printable

On 01/12/14 18:45, John Haxby wrote:
>
>> On 1 Dec 2014, at 17:15, Andrew Cooper <andrew.cooper3@citrix.com
>> <mailto:andrew.cooper3@citrix.com>> wrote:
>>
>> On 01/12/14 14:37, John Haxby wrote:
>>> With gcc 4.8.3, compiling xen-detect gives a compilation warning if
>>> you're optimising:
>>>
>>> $ cc -Wall -Os xen-detect.c
>>> xen-detect.c: In function =E2=80=98check_for_xen=E2=80=99:
>>> xen-detect.c:65:9: warning: dereferencing type-punned pointer will break
>>> strict-aliasing rules [-Wstrict-aliasing]
>>>         *(uint32_t *)(signature + 0) =3D regs[1];
>>>         ^
>>>
>>> Signed-off-by: John Haxby <john.haxby@oracle.com
>>> <mailto:john.haxby@oracle.com>>
>>
>> Why are you compiling without the CFLAGS from the Xen build system=3F
>>
>> We explicitly disable strict alias optimisations, because optimisations
>> based upon the aliasing rules in C is mad.  Even when you eliminate all
>> the warnings, there are still subtle bugs because the compiler is free
>> to assume a lot more than a programmer would typically deem reasonable.
>
>
> I wasn=E2=80=99t building the whole system, I just wanted xen-detect so I
> pulled it out and compiled it; I usually use "-Wall -Os=E2=80=9D because the
> combination finds problems I might otherwise overlook.   The patch
> also removes three lines of code :) but you can take it or leave it as
> you choose.   The other patch =E2=80=94 reversing the code of pv and hvm
> checking =E2=80=94 was the real problem.
>
> jch

I feel it would be neater to fix this by using the
XEN_CPUID_SIGNATURE_E{B,C,D}X constants from the API.  This fixes the
strict aliasing, and does away with the string handling completely.

~Andrew

--------------050902070405050302090504
Content-Type: text/html; charset="utf-8"
Content-Length: 9822
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 01/12/14 18:45, John Haxby wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:309AAB3D-A4EE-485C-BE09-AAC4192E7F27@oracle.com"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
      <br class=3D"">
      <div>
        <blockquote type=3D"cite" class=3D"">
          <div class=3D"">On 1 Dec 2014, at 17:15, Andrew Cooper &lt;<a
              moz-do-not-send=3D"true"
              href=3D"mailto:andrew.cooper3@citrix.com" class=3D"">andrew.cooper3@citrix.com</a>&gt;
            wrote:</div>
          <br class=3D"Apple-interchange-newline">
          <div class=3D""><span style=3D"font-family: Menlo-Regular;
              font-size: 11px; font-style: normal; font-variant: normal;
              font-weight: normal; letter-spacing: normal; line-height:
              normal; orphans: auto; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal; widows:
              auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
              float: none; display: inline !important;" class=3D"">On
              01/12/14 14:37, John Haxby wrote:</span><br
              style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <blockquote type=3D"cite" style=3D"font-family: Menlo-Regular;
              font-size: 11px; font-style: normal; font-variant: normal;
              font-weight: normal; letter-spacing: normal; line-height:
              normal; orphans: auto; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal; widows:
              auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">With gcc 4.8.3, compiling xen-detect gives a
              compilation warning if<br class=3D"">
              you're optimising:<br class=3D"">
              <br class=3D"">
              $ cc -Wall -Os xen-detect.c<br class=3D"">
              xen-detect.c: In function =E2=80=98check_for_xen=E2=80=99:<br class=3D"">
              xen-detect.c:65:9: warning: dereferencing type-punned
              pointer will break<br class=3D"">
              strict-aliasing rules [-Wstrict-aliasing]<br class=3D"">
              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*(uint32_t *)(signature + 0) =3D regs[1];<br
                class=3D"">
              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0^<br class=3D"">
              <br class=3D"">
              Signed-off-by: John Haxby &lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:john.haxby@oracle.com" class=3D"">john.haxby@oracle.com</a>&gt;<br
                class=3D"">
            </blockquote>
            <br style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <span style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px; float:
              none; display: inline !important;" class=3D"">Why are you
              compiling without the CFLAGS from the Xen build system=3F</span><br
              style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <br style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <span style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px; float:
              none; display: inline !important;" class=3D"">We explicitly
              disable strict alias optimisations, because optimisations</span><br
              style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <span style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px; float:
              none; display: inline !important;" class=3D"">based upon the
              aliasing rules in C is mad. =C2=A0Even when you eliminate all</span><br
              style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <span style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px; float:
              none; display: inline !important;" class=3D"">the warnings,
              there are still subtle bugs because the compiler is free</span><br
              style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;"
              class=3D"">
            <span style=3D"font-family: Menlo-Regular; font-size: 11px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px; float:
              none; display: inline !important;" class=3D"">to assume a
              lot more than a programmer would typically deem
              reasonable.</span></div>
        </blockquote>
      </div>
      <br class=3D"">
      <div class=3D""><br class=3D"">
      </div>
      <div class=3D"">I wasn=E2=80=99t building the whole system, I just wanted
        xen-detect so I pulled it out and compiled it; I usually use
        "-Wall -Os=E2=80=9D because the combination finds problems I might
        otherwise overlook. =C2=A0 The patch also removes three lines of code
        :) but you can take it or leave it as you choose. =C2=A0 The other
        patch =E2=80=94 reversing the code of pv and hvm checking =E2=80=94 was the real
        problem.</div>
      <div class=3D""><br class=3D"">
      </div>
      <div class=3D"">jch</div>
    </blockquote>
    <br>
    I feel it would be neater to fix this by using the
    XEN_CPUID_SIGNATURE_E{B,C,D}X constants from the API.=C2=A0 This fixes
    the strict aliasing, and does away with the string handling
    completely.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

--------------050902070405050302090504--


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

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

--===============6305509876595795036==--


From xen-devel-bounces@lists.xen.org Wed Dec 03 15:52:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15: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 1XwCDY-0000oM-83; Wed, 03 Dec 2014 15:51:52 +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 1XwCDW-0000oF-V3
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:51:51 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	EB/E8-14727-6913F745; Wed, 03 Dec 2014 15:51:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417621907!5935032!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 2611 invoked from network); 3 Dec 2014 15:51:49 -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 Dec 2014 15:51:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199114293"
Message-ID: <547F318F.60002@citrix.com>
Date: Wed, 3 Dec 2014 15:51: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: John Haxby <john.haxby@oracle.com>, <xen-devel@lists.xen.org>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>	<1417444646-20636-2-git-send-email-john.haxby@oracle.com>
	<547CA220.9070604@citrix.com> <547F2EA2.5030702@oracle.com>
In-Reply-To: <547F2EA2.5030702@oracle.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 1/2] xen-detect: fix strict-aliasing
 compilation warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDMvMTIvMTQgMTU6MzksIEpvaG4gSGF4Ynkgd3JvdGU6Cj4gT24gMDEvMTIvMTQgMTc6MTUs
IEFuZHJldyBDb29wZXIgd3JvdGU6Cj4+IE9uIDAxLzEyLzE0IDE0OjM3LCBKb2huIEhheGJ5IHdy
b3RlOgo+Pj4gV2l0aCBnY2MgNC44LjMsIGNvbXBpbGluZyB4ZW4tZGV0ZWN0IGdpdmVzIGEgY29t
cGlsYXRpb24gd2FybmluZyBpZgo+Pj4geW91J3JlIG9wdGltaXNpbmc6Cj4+Pgo+Pj4gJCBjYyAt
V2FsbCAtT3MgeGVuLWRldGVjdC5jCj4+PiB4ZW4tZGV0ZWN0LmM6IEluIGZ1bmN0aW9uIOKAmGNo
ZWNrX2Zvcl94ZW7igJk6Cj4+PiB4ZW4tZGV0ZWN0LmM6NjU6OTogd2FybmluZzogZGVyZWZlcmVu
Y2luZyB0eXBlLXB1bm5lZCBwb2ludGVyIHdpbGwgYnJlYWsKPj4+IHN0cmljdC1hbGlhc2luZyBy
dWxlcyBbLVdzdHJpY3QtYWxpYXNpbmddCj4+PiAgICAgICAgICAqKHVpbnQzMl90ICopKHNpZ25h
dHVyZSArIDApID0gcmVnc1sxXTsKPj4+ICAgICAgICAgIF4KPj4+Cj4+PiBTaWduZWQtb2ZmLWJ5
OiBKb2huIEhheGJ5IDxqb2huLmhheGJ5QG9yYWNsZS5jb20+Cj4+IFdoeSBhcmUgeW91IGNvbXBp
bGluZyB3aXRob3V0IHRoZSBDRkxBR1MgZnJvbSB0aGUgWGVuIGJ1aWxkIHN5c3RlbT8KPj4KPj4g
V2UgZXhwbGljaXRseSBkaXNhYmxlIHN0cmljdCBhbGlhcyBvcHRpbWlzYXRpb25zLCBiZWNhdXNl
IG9wdGltaXNhdGlvbnMKPj4gYmFzZWQgdXBvbiB0aGUgYWxpYXNpbmcgcnVsZXMgaW4gQyBpcyBt
YWQuICBFdmVuIHdoZW4geW91IGVsaW1pbmF0ZSBhbGwKPj4gdGhlIHdhcm5pbmdzLCB0aGVyZSBh
cmUgc3RpbGwgc3VidGxlIGJ1Z3MgYmVjYXVzZSB0aGUgY29tcGlsZXIgaXMgZnJlZQo+PiB0byBh
c3N1bWUgYSBsb3QgbW9yZSB0aGFuIGEgcHJvZ3JhbW1lciB3b3VsZCB0eXBpY2FsbHkgZGVlbSBy
ZWFzb25hYmxlLgo+IERvIHlvdSB3YW50IG1lIHRvIHJlcG9zdCB0aGUgc2Vjb25kIHBhdGNoICh0
aGUgYWN0dWFsIGJ1ZyBmaXggb25lKSBzbwo+IHRoYXQgaXQgZG9lc24ndCBhc3N1bWUgdGhlIGxp
bmUgbnVtYmVyIGNoYW5nZXMgYW5kIHdoYXRub3QgZm9yIHRoaXMgb25lPwo+Cj4gamNoCgpXaXRo
IGEgcHJhZ21hdGljIGhhdCBvbiwgbWFraW5nIG1vcmUgc3R1ZmYgIi1XYWxsIiBzYWZlIGlzIHBy
b2JhYmx5CmJldHRlciwgYWx0aG91Z2ggcHJvZHVjdGlvbiBjb2RlIHNob3VsZCB1c2UgdGhlIHN1
cnJvdW5kaW5nIGluZnJhc3RydWN0dXJlLgoKV2l0aCBhbGwgb2YgdGhlc2UgcGF0Y2hlcywgeW91
IG11c3QgQ0MgdGhlIHRvb2xzdGFjayBtYWludGFpbmVycy4gIElmCnlvdSBiZWxpZXZlIGl0IHNo
b3VsZCBtYWtlIHRoZSBjdXQgZm9yIDQuNSwgeW91IG11c3QgYWxzbyBDQyBLb25yYWQgYW5kCmFy
Z3VlIGZvciBhIHJlbGVhc2UgYWNrLgoKfkFuZHJldwoKCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:52:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15: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 1XwCDY-0000oM-83; Wed, 03 Dec 2014 15:51:52 +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 1XwCDW-0000oF-V3
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 15:51:51 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	EB/E8-14727-6913F745; Wed, 03 Dec 2014 15:51:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417621907!5935032!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 2611 invoked from network); 3 Dec 2014 15:51:49 -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 Dec 2014 15:51:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199114293"
Message-ID: <547F318F.60002@citrix.com>
Date: Wed, 3 Dec 2014 15:51: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: John Haxby <john.haxby@oracle.com>, <xen-devel@lists.xen.org>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>	<1417444646-20636-2-git-send-email-john.haxby@oracle.com>
	<547CA220.9070604@citrix.com> <547F2EA2.5030702@oracle.com>
In-Reply-To: <547F2EA2.5030702@oracle.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 1/2] xen-detect: fix strict-aliasing
 compilation warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDMvMTIvMTQgMTU6MzksIEpvaG4gSGF4Ynkgd3JvdGU6Cj4gT24gMDEvMTIvMTQgMTc6MTUs
IEFuZHJldyBDb29wZXIgd3JvdGU6Cj4+IE9uIDAxLzEyLzE0IDE0OjM3LCBKb2huIEhheGJ5IHdy
b3RlOgo+Pj4gV2l0aCBnY2MgNC44LjMsIGNvbXBpbGluZyB4ZW4tZGV0ZWN0IGdpdmVzIGEgY29t
cGlsYXRpb24gd2FybmluZyBpZgo+Pj4geW91J3JlIG9wdGltaXNpbmc6Cj4+Pgo+Pj4gJCBjYyAt
V2FsbCAtT3MgeGVuLWRldGVjdC5jCj4+PiB4ZW4tZGV0ZWN0LmM6IEluIGZ1bmN0aW9uIOKAmGNo
ZWNrX2Zvcl94ZW7igJk6Cj4+PiB4ZW4tZGV0ZWN0LmM6NjU6OTogd2FybmluZzogZGVyZWZlcmVu
Y2luZyB0eXBlLXB1bm5lZCBwb2ludGVyIHdpbGwgYnJlYWsKPj4+IHN0cmljdC1hbGlhc2luZyBy
dWxlcyBbLVdzdHJpY3QtYWxpYXNpbmddCj4+PiAgICAgICAgICAqKHVpbnQzMl90ICopKHNpZ25h
dHVyZSArIDApID0gcmVnc1sxXTsKPj4+ICAgICAgICAgIF4KPj4+Cj4+PiBTaWduZWQtb2ZmLWJ5
OiBKb2huIEhheGJ5IDxqb2huLmhheGJ5QG9yYWNsZS5jb20+Cj4+IFdoeSBhcmUgeW91IGNvbXBp
bGluZyB3aXRob3V0IHRoZSBDRkxBR1MgZnJvbSB0aGUgWGVuIGJ1aWxkIHN5c3RlbT8KPj4KPj4g
V2UgZXhwbGljaXRseSBkaXNhYmxlIHN0cmljdCBhbGlhcyBvcHRpbWlzYXRpb25zLCBiZWNhdXNl
IG9wdGltaXNhdGlvbnMKPj4gYmFzZWQgdXBvbiB0aGUgYWxpYXNpbmcgcnVsZXMgaW4gQyBpcyBt
YWQuICBFdmVuIHdoZW4geW91IGVsaW1pbmF0ZSBhbGwKPj4gdGhlIHdhcm5pbmdzLCB0aGVyZSBh
cmUgc3RpbGwgc3VidGxlIGJ1Z3MgYmVjYXVzZSB0aGUgY29tcGlsZXIgaXMgZnJlZQo+PiB0byBh
c3N1bWUgYSBsb3QgbW9yZSB0aGFuIGEgcHJvZ3JhbW1lciB3b3VsZCB0eXBpY2FsbHkgZGVlbSBy
ZWFzb25hYmxlLgo+IERvIHlvdSB3YW50IG1lIHRvIHJlcG9zdCB0aGUgc2Vjb25kIHBhdGNoICh0
aGUgYWN0dWFsIGJ1ZyBmaXggb25lKSBzbwo+IHRoYXQgaXQgZG9lc24ndCBhc3N1bWUgdGhlIGxp
bmUgbnVtYmVyIGNoYW5nZXMgYW5kIHdoYXRub3QgZm9yIHRoaXMgb25lPwo+Cj4gamNoCgpXaXRo
IGEgcHJhZ21hdGljIGhhdCBvbiwgbWFraW5nIG1vcmUgc3R1ZmYgIi1XYWxsIiBzYWZlIGlzIHBy
b2JhYmx5CmJldHRlciwgYWx0aG91Z2ggcHJvZHVjdGlvbiBjb2RlIHNob3VsZCB1c2UgdGhlIHN1
cnJvdW5kaW5nIGluZnJhc3RydWN0dXJlLgoKV2l0aCBhbGwgb2YgdGhlc2UgcGF0Y2hlcywgeW91
IG11c3QgQ0MgdGhlIHRvb2xzdGFjayBtYWludGFpbmVycy4gIElmCnlvdSBiZWxpZXZlIGl0IHNo
b3VsZCBtYWtlIHRoZSBjdXQgZm9yIDQuNSwgeW91IG11c3QgYWxzbyBDQyBLb25yYWQgYW5kCmFy
Z3VlIGZvciBhIHJlbGVhc2UgYWNrLgoKfkFuZHJldwoKCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:54:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15: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 1XwCFn-0000tT-O1; Wed, 03 Dec 2014 15:54:11 +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 1XwCFm-0000tO-T7
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 15:54:10 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	E1/FA-02698-2223F745; Wed, 03 Dec 2014 15:54:10 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417622048!12775833!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31111 invoked from network); 3 Dec 2014 15:54:09 -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 Dec 2014 15:54:09 -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 sB3Fs25Y008985
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 15:54: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
	sB3FrxOC015980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 15:54:01 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
	sB3Frxem016543; Wed, 3 Dec 2014 15:53:59 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 07:53:58 -0800
Date: Wed, 3 Dec 2014 16:53:53 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141203155353.GN16236@olila.local.net-space.pl>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
	<20141202183620.GE32385@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202183620.GE32385@laptop.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
 target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>
> This usage scenario which I can see this being useful (and
> I've tripped over this) is when you rebuild a new version
> from the same repo. As in, this affects developers, but
> not end-users and not distros. But perhaps I am missing
> one scenario?
>
> As such I would lean towards deferring this (and the other
> two) to Xen 4.6.

As I know Debian build system sometimes complain if make distclean
does not leave build tree in distclean state (read "state before
configure" != "state after distclean"). It means that from
distros point of view we should apply this patch. However,
other two are not required and we can deffer them to Xen 4.6.

Daniel

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 15:54:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 15: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 1XwCFn-0000tT-O1; Wed, 03 Dec 2014 15:54:11 +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 1XwCFm-0000tO-T7
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 15:54:10 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	E1/FA-02698-2223F745; Wed, 03 Dec 2014 15:54:10 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417622048!12775833!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31111 invoked from network); 3 Dec 2014 15:54:09 -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 Dec 2014 15:54:09 -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 sB3Fs25Y008985
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 15:54: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
	sB3FrxOC015980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 15:54:01 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
	sB3Frxem016543; Wed, 3 Dec 2014 15:53:59 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 07:53:58 -0800
Date: Wed, 3 Dec 2014 16:53:53 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141203155353.GN16236@olila.local.net-space.pl>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
	<20141202183620.GE32385@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202183620.GE32385@laptop.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
 target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>
> This usage scenario which I can see this being useful (and
> I've tripped over this) is when you rebuild a new version
> from the same repo. As in, this affects developers, but
> not end-users and not distros. But perhaps I am missing
> one scenario?
>
> As such I would lean towards deferring this (and the other
> two) to Xen 4.6.

As I know Debian build system sometimes complain if make distclean
does not leave build tree in distclean state (read "state before
configure" != "state after distclean"). It means that from
distros point of view we should apply this patch. However,
other two are not required and we can deffer them to Xen 4.6.

Daniel

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 16:01:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 16: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 1XwCMO-0001Mo-La; Wed, 03 Dec 2014 16:01:00 +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 1XwCMN-0001Mj-V0
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 16:01:00 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	88/B1-29352-BB33F745; Wed, 03 Dec 2014 16:00:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417622457!5937310!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 17335 invoked from network); 3 Dec 2014 16:00:58 -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 Dec 2014 16:00:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199118672"
Message-ID: <547F33B6.8090802@citrix.com>
Date: Wed, 3 Dec 2014 16:00: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: John Haxby <john.haxby@oracle.com>, <xen-devel@lists.xen.org>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
	<1417444646-20636-3-git-send-email-john.haxby@oracle.com>
In-Reply-To: <1417444646-20636-3-git-send-email-john.haxby@oracle.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH 2/2] xen-detect: check for XEN_PV before
	XEN_HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 01/12/14 14:37, John Haxby wrote:
> At some stage, the cpuid instruction used to detect a xen hvm domain
> also started working in a pv domain so pv domains were being identified
> as hvm (dom0 excepted).  Change the order so that pv is tested for
> first.
>
> Signed-off-by: John Haxby <john.haxby@oracle.com>

This will have happened as a side effect of Intels CPUID-faulting
ability present in IvyBridge servers and later, which permits Xen the
ability to intercept regular cpuid instructions.

On the other hand, the forced emulation prefix is now valid in HVM
guests in debug Xens with the "hvm_fep" command line option.  In that
case, the HVM domain would be erroneously identified as PV.

Perhaps it is worth having an explicit guest type available in the cpuid
leaves themselves, so guest userspace need not guess at all?

~Andrew


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 16:01:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 16: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 1XwCMO-0001Mo-La; Wed, 03 Dec 2014 16:01:00 +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 1XwCMN-0001Mj-V0
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 16:01:00 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	88/B1-29352-BB33F745; Wed, 03 Dec 2014 16:00:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417622457!5937310!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 17335 invoked from network); 3 Dec 2014 16:00:58 -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 Dec 2014 16:00:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199118672"
Message-ID: <547F33B6.8090802@citrix.com>
Date: Wed, 3 Dec 2014 16:00: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: John Haxby <john.haxby@oracle.com>, <xen-devel@lists.xen.org>
References: <1417444646-20636-1-git-send-email-john.haxby@oracle.com>
	<1417444646-20636-3-git-send-email-john.haxby@oracle.com>
In-Reply-To: <1417444646-20636-3-git-send-email-john.haxby@oracle.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH 2/2] xen-detect: check for XEN_PV before
	XEN_HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 01/12/14 14:37, John Haxby wrote:
> At some stage, the cpuid instruction used to detect a xen hvm domain
> also started working in a pv domain so pv domains were being identified
> as hvm (dom0 excepted).  Change the order so that pv is tested for
> first.
>
> Signed-off-by: John Haxby <john.haxby@oracle.com>

This will have happened as a side effect of Intels CPUID-faulting
ability present in IvyBridge servers and later, which permits Xen the
ability to intercept regular cpuid instructions.

On the other hand, the forced emulation prefix is now valid in HVM
guests in debug Xens with the "hvm_fep" command line option.  In that
case, the HVM domain would be erroneously identified as PV.

Perhaps it is worth having an explicit guest type available in the cpuid
leaves themselves, so guest userspace need not guess at all?

~Andrew


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 16:04:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 16:04:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwCQB-0001ck-IT; Wed, 03 Dec 2014 16:04:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XwCQ9-0001ce-NN
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 16:04:53 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	52/6A-15461-5A43F745; Wed, 03 Dec 2014 16:04:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417622691!12836283!1
X-Originating-IP: [66.165.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 6501 invoked from network); 3 Dec 2014 16:04:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 16:04:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199462678"
Received: from ukmail1.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, 3 Dec 2014 11:04:33 -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 1XwCPp-0005rC-6n;
	Wed, 03 Dec 2014 16:04:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Wed, 3 Dec 2014 16:04:20 +0000
Message-ID: <1417622660-23912-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: Keir Fraser <keir@xen.org>, 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>
Subject: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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

The default limit for the number of PIRQs for hardware domains (dom0)
is not sufficient for some (x86) systems.

Since the pirq structures are individually and dynamically allocated,
the limit for hardware domains may be increased to the number of
possible IRQs.

The extra_guest_irqs command line option now only allows changes to
the domU value.  Any argument for dom0 is ignored.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 docs/misc/xen-command-line.markdown |   11 ++++-------
 xen/common/domain.c                 |    7 +------
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 0866df2..d352031 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -594,15 +594,12 @@ except for debugging purposes.
 Force or disable use of EFI runtime services.
 
 ### extra\_guest\_irqs
-> `= [<domU number>][,<dom0 number>]`
+> `= [<number>]`
 
-> Default: `32,256`
+> Default: `32`
 
-Change the number of PIRQs available for guests.  The optional first number is
-common for all domUs, while the optional second number (preceded by a comma)
-is for dom0.  Changing the setting for domU has no impact on dom0 and vice
-versa.  For example to change dom0 without changing domU, use
-`extra_guest_irqs=,512`
+Change the number of PIRQs available for guests. This limit does not
+apply to hardware domains (dom0).
 
 ### flask\_enabled
 > `= <integer>`
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 4a62c1d..a88d829 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -231,14 +231,11 @@ static int late_hwdom_init(struct domain *d)
 #endif
 }
 
-static unsigned int __read_mostly extra_dom0_irqs = 256;
 static unsigned int __read_mostly extra_domU_irqs = 32;
 static void __init parse_extra_guest_irqs(const char *s)
 {
     if ( isdigit(*s) )
         extra_domU_irqs = simple_strtoul(s, &s, 0);
-    if ( *s == ',' && isdigit(*++s) )
-        extra_dom0_irqs = simple_strtoul(s, &s, 0);
 }
 custom_param("extra_guest_irqs", parse_extra_guest_irqs);
 
@@ -324,10 +321,8 @@ struct domain *domain_create(
         atomic_inc(&d->pause_count);
 
         if ( !is_hardware_domain(d) )
-            d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
+            d->nr_pirqs = min(nr_static_irqs + extra_domU_irqs, nr_irqs);
         else
-            d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
-        if ( d->nr_pirqs > nr_irqs )
             d->nr_pirqs = nr_irqs;
 
         radix_tree_init(&d->pirq_tree);
-- 
1.7.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 Dec 03 16:04:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 16:04:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwCQB-0001ck-IT; Wed, 03 Dec 2014 16:04:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XwCQ9-0001ce-NN
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 16:04:53 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	52/6A-15461-5A43F745; Wed, 03 Dec 2014 16:04:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417622691!12836283!1
X-Originating-IP: [66.165.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 6501 invoked from network); 3 Dec 2014 16:04:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 16:04:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199462678"
Received: from ukmail1.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, 3 Dec 2014 11:04:33 -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 1XwCPp-0005rC-6n;
	Wed, 03 Dec 2014 16:04:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Wed, 3 Dec 2014 16:04:20 +0000
Message-ID: <1417622660-23912-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: Keir Fraser <keir@xen.org>, 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>
Subject: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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

The default limit for the number of PIRQs for hardware domains (dom0)
is not sufficient for some (x86) systems.

Since the pirq structures are individually and dynamically allocated,
the limit for hardware domains may be increased to the number of
possible IRQs.

The extra_guest_irqs command line option now only allows changes to
the domU value.  Any argument for dom0 is ignored.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 docs/misc/xen-command-line.markdown |   11 ++++-------
 xen/common/domain.c                 |    7 +------
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 0866df2..d352031 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -594,15 +594,12 @@ except for debugging purposes.
 Force or disable use of EFI runtime services.
 
 ### extra\_guest\_irqs
-> `= [<domU number>][,<dom0 number>]`
+> `= [<number>]`
 
-> Default: `32,256`
+> Default: `32`
 
-Change the number of PIRQs available for guests.  The optional first number is
-common for all domUs, while the optional second number (preceded by a comma)
-is for dom0.  Changing the setting for domU has no impact on dom0 and vice
-versa.  For example to change dom0 without changing domU, use
-`extra_guest_irqs=,512`
+Change the number of PIRQs available for guests. This limit does not
+apply to hardware domains (dom0).
 
 ### flask\_enabled
 > `= <integer>`
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 4a62c1d..a88d829 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -231,14 +231,11 @@ static int late_hwdom_init(struct domain *d)
 #endif
 }
 
-static unsigned int __read_mostly extra_dom0_irqs = 256;
 static unsigned int __read_mostly extra_domU_irqs = 32;
 static void __init parse_extra_guest_irqs(const char *s)
 {
     if ( isdigit(*s) )
         extra_domU_irqs = simple_strtoul(s, &s, 0);
-    if ( *s == ',' && isdigit(*++s) )
-        extra_dom0_irqs = simple_strtoul(s, &s, 0);
 }
 custom_param("extra_guest_irqs", parse_extra_guest_irqs);
 
@@ -324,10 +321,8 @@ struct domain *domain_create(
         atomic_inc(&d->pause_count);
 
         if ( !is_hardware_domain(d) )
-            d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
+            d->nr_pirqs = min(nr_static_irqs + extra_domU_irqs, nr_irqs);
         else
-            d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
-        if ( d->nr_pirqs > nr_irqs )
             d->nr_pirqs = nr_irqs;
 
         radix_tree_init(&d->pirq_tree);
-- 
1.7.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 Dec 03 16:09:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 16:09:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwCU3-0002Gs-7A; Wed, 03 Dec 2014 16:08: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 1XwCU2-0002Gn-2R
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 16:08:54 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	BF/FE-02712-5953F745; Wed, 03 Dec 2014 16:08:53 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417622931!12788407!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 10155 invoked from network); 3 Dec 2014 16:08: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;
	3 Dec 2014 16:08:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199464585"
Message-ID: <547F3567.2090305@citrix.com>
Date: Wed, 3 Dec 2014 16:08:07 +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: David Vrabel <david.vrabel@citrix.com>, <xen-devel@lists.xenproject.org>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 03/12/14 16:04, David Vrabel wrote:
> The default limit for the number of PIRQs for hardware domains (dom0)
> is not sufficient for some (x86) systems.
>
> Since the pirq structures are individually and dynamically allocated,
> the limit for hardware domains may be increased to the number of
> possible IRQs.
>
> The extra_guest_irqs command line option now only allows changes to
> the domU value.  Any argument for dom0 is ignored.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  docs/misc/xen-command-line.markdown |   11 ++++-------
>  xen/common/domain.c                 |    7 +------
>  2 files changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> index 0866df2..d352031 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -594,15 +594,12 @@ except for debugging purposes.
>  Force or disable use of EFI runtime services.
>  
>  ### extra\_guest\_irqs
> -> `= [<domU number>][,<dom0 number>]`
> +> `= [<number>]`
>  
> -> Default: `32,256`
> +> Default: `32`
>  
> -Change the number of PIRQs available for guests.  The optional first number is
> -common for all domUs, while the optional second number (preceded by a comma)
> -is for dom0.  Changing the setting for domU has no impact on dom0 and vice
> -versa.  For example to change dom0 without changing domU, use
> -`extra_guest_irqs=,512`
> +Change the number of PIRQs available for guests. This limit does not
> +apply to hardware domains (dom0).
>  
>  ### flask\_enabled
>  > `= <integer>`
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 4a62c1d..a88d829 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -231,14 +231,11 @@ static int late_hwdom_init(struct domain *d)
>  #endif
>  }
>  
> -static unsigned int __read_mostly extra_dom0_irqs = 256;
>  static unsigned int __read_mostly extra_domU_irqs = 32;
>  static void __init parse_extra_guest_irqs(const char *s)
>  {
>      if ( isdigit(*s) )
>          extra_domU_irqs = simple_strtoul(s, &s, 0);
> -    if ( *s == ',' && isdigit(*++s) )
> -        extra_dom0_irqs = simple_strtoul(s, &s, 0);
>  }
>  custom_param("extra_guest_irqs", parse_extra_guest_irqs);
>  
> @@ -324,10 +321,8 @@ struct domain *domain_create(
>          atomic_inc(&d->pause_count);
>  
>          if ( !is_hardware_domain(d) )
> -            d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
> +            d->nr_pirqs = min(nr_static_irqs + extra_domU_irqs, nr_irqs);
>          else
> -            d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
> -        if ( d->nr_pirqs > nr_irqs )
>              d->nr_pirqs = nr_irqs;
>  
>          radix_tree_init(&d->pirq_tree);


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 16:09:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 16:09:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwCU3-0002Gs-7A; Wed, 03 Dec 2014 16:08: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 1XwCU2-0002Gn-2R
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 16:08:54 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	BF/FE-02712-5953F745; Wed, 03 Dec 2014 16:08:53 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417622931!12788407!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 10155 invoked from network); 3 Dec 2014 16:08: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;
	3 Dec 2014 16:08:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="199464585"
Message-ID: <547F3567.2090305@citrix.com>
Date: Wed, 3 Dec 2014 16:08:07 +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: David Vrabel <david.vrabel@citrix.com>, <xen-devel@lists.xenproject.org>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 03/12/14 16:04, David Vrabel wrote:
> The default limit for the number of PIRQs for hardware domains (dom0)
> is not sufficient for some (x86) systems.
>
> Since the pirq structures are individually and dynamically allocated,
> the limit for hardware domains may be increased to the number of
> possible IRQs.
>
> The extra_guest_irqs command line option now only allows changes to
> the domU value.  Any argument for dom0 is ignored.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  docs/misc/xen-command-line.markdown |   11 ++++-------
>  xen/common/domain.c                 |    7 +------
>  2 files changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> index 0866df2..d352031 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -594,15 +594,12 @@ except for debugging purposes.
>  Force or disable use of EFI runtime services.
>  
>  ### extra\_guest\_irqs
> -> `= [<domU number>][,<dom0 number>]`
> +> `= [<number>]`
>  
> -> Default: `32,256`
> +> Default: `32`
>  
> -Change the number of PIRQs available for guests.  The optional first number is
> -common for all domUs, while the optional second number (preceded by a comma)
> -is for dom0.  Changing the setting for domU has no impact on dom0 and vice
> -versa.  For example to change dom0 without changing domU, use
> -`extra_guest_irqs=,512`
> +Change the number of PIRQs available for guests. This limit does not
> +apply to hardware domains (dom0).
>  
>  ### flask\_enabled
>  > `= <integer>`
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 4a62c1d..a88d829 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -231,14 +231,11 @@ static int late_hwdom_init(struct domain *d)
>  #endif
>  }
>  
> -static unsigned int __read_mostly extra_dom0_irqs = 256;
>  static unsigned int __read_mostly extra_domU_irqs = 32;
>  static void __init parse_extra_guest_irqs(const char *s)
>  {
>      if ( isdigit(*s) )
>          extra_domU_irqs = simple_strtoul(s, &s, 0);
> -    if ( *s == ',' && isdigit(*++s) )
> -        extra_dom0_irqs = simple_strtoul(s, &s, 0);
>  }
>  custom_param("extra_guest_irqs", parse_extra_guest_irqs);
>  
> @@ -324,10 +321,8 @@ struct domain *domain_create(
>          atomic_inc(&d->pause_count);
>  
>          if ( !is_hardware_domain(d) )
> -            d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
> +            d->nr_pirqs = min(nr_static_irqs + extra_domU_irqs, nr_irqs);
>          else
> -            d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
> -        if ( d->nr_pirqs > nr_irqs )
>              d->nr_pirqs = nr_irqs;
>  
>          radix_tree_init(&d->pirq_tree);


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 16:56:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 16:56:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDDd-0003U4-4r; Wed, 03 Dec 2014 16:56:01 +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 1XwDDc-0003Tz-3z
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 16:56:00 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	1D/F9-17694-F904F745; Wed, 03 Dec 2014 16:55:59 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417625757!10919771!1
X-Originating-IP: [156.151.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 1495 invoked from network); 3 Dec 2014 16:55:58 -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; 3 Dec 2014 16:55:58 -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 sB3GtpvU027864
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 16:55:53 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
	sB3GtolZ016454
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 16:55:50 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
	sB3Gtn1P018299; Wed, 3 Dec 2014 16:55:49 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 ; Wed, 03 Dec 2014 08:55:48 -0800
Message-ID: <547F40FC.7030403@oracle.com>
Date: Wed, 03 Dec 2014 11:57:32 -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: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
	<1417438873-2082-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417438873-2082-1-git-send-email-vkuznets@redhat.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
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 RESEND] 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 12/01/2014 08:01 AM, 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>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

(although, as I mentioned last time, a companion patch to remove 
flush_op would be a good thing to have)


-boris

> ---
>   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;
>   		}
>   


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 16:56:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 16:56:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDDd-0003U4-4r; Wed, 03 Dec 2014 16:56:01 +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 1XwDDc-0003Tz-3z
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 16:56:00 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	1D/F9-17694-F904F745; Wed, 03 Dec 2014 16:55:59 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417625757!10919771!1
X-Originating-IP: [156.151.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 1495 invoked from network); 3 Dec 2014 16:55:58 -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; 3 Dec 2014 16:55:58 -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 sB3GtpvU027864
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 16:55:53 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
	sB3GtolZ016454
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 16:55:50 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
	sB3Gtn1P018299; Wed, 3 Dec 2014 16:55:49 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 ; Wed, 03 Dec 2014 08:55:48 -0800
Message-ID: <547F40FC.7030403@oracle.com>
Date: Wed, 03 Dec 2014 11:57:32 -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: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
	<1417438873-2082-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417438873-2082-1-git-send-email-vkuznets@redhat.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
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 RESEND] 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 12/01/2014 08:01 AM, 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>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

(although, as I mentioned last time, a companion patch to remove 
flush_op would be a good thing to have)


-boris

> ---
>   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;
>   		}
>   


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 17:06:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:06:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDNB-0003rA-QI; Wed, 03 Dec 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 <vkuznets@redhat.com>) id 1XwDNA-0003r5-8g
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:05:52 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	BE/64-11581-FE24F745; Wed, 03 Dec 2014 17:05:51 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417626349!11337676!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12470 invoked from network); 3 Dec 2014 17:05:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:05:50 -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 sB3H5jVi011128
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:05:45 -0500
Received: from vitty.brq.redhat.com.smtpmail-local-domain
	(vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3H5gwM001445
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 12:05:43 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
	<1417438873-2082-1-git-send-email-vkuznets@redhat.com>
	<547F40FC.7030403@oracle.com>
Date: Wed, 03 Dec 2014 18:05:42 +0100
In-Reply-To: <547F40FC.7030403@oracle.com> (Boris Ostrovsky's message of "Wed, 
	03 Dec 2014 11:57:32 -0500")
Message-ID: <87wq68k6jd.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.22
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 RESEND] 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 12/01/2014 08:01 AM, 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>
>> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
>
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>
> (although, as I mentioned last time, a companion patch to remove
> flush_op would be a good thing to have)
>

Thanks, it is on my todo list but I'm trying to separate this
(potential) bugfix from straight cleanup.

> -boris
>
>> ---
>>   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;
>>   		}
>>   

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 17:06:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:06:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDNB-0003rA-QI; Wed, 03 Dec 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 <vkuznets@redhat.com>) id 1XwDNA-0003r5-8g
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:05:52 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	BE/64-11581-FE24F745; Wed, 03 Dec 2014 17:05:51 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417626349!11337676!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12470 invoked from network); 3 Dec 2014 17:05:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:05:50 -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 sB3H5jVi011128
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:05:45 -0500
Received: from vitty.brq.redhat.com.smtpmail-local-domain
	(vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3H5gwM001445
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 12:05:43 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>
	<1417438873-2082-1-git-send-email-vkuznets@redhat.com>
	<547F40FC.7030403@oracle.com>
Date: Wed, 03 Dec 2014 18:05:42 +0100
In-Reply-To: <547F40FC.7030403@oracle.com> (Boris Ostrovsky's message of "Wed, 
	03 Dec 2014 11:57:32 -0500")
Message-ID: <87wq68k6jd.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.22
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 RESEND] 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 12/01/2014 08:01 AM, 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>
>> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
>
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>
> (although, as I mentioned last time, a companion patch to remove
> flush_op would be a good thing to have)
>

Thanks, it is on my todo list but I'm trying to separate this
(potential) bugfix from straight cleanup.

> -boris
>
>> ---
>>   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;
>>   		}
>>   

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 17:16:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXs-0004Q7-Vr; Wed, 03 Dec 2014 17:16:56 +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 1XwDXs-0004PX-0s
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BD/67-15461-7854F745; Wed, 03 Dec 2014 17:16:55 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417627012!5165150!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9848 invoked from network); 3 Dec 2014 17:16:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:16:54 -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 sB3HGlG2016756
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:48 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkV008593; Wed, 3 Dec 2014 12:16:45 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:20 +0100
Message-Id: <1417626981-8432-9-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 8/9] libxl: soft reset support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Perform soft reset when a domain did SHUTDOWN_soft_reset. Migrate the
content with xc_domain_soft_reset(), reload dm and toolstack.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxl/libxl.h          |   6 +++
 tools/libxl/libxl_create.c   | 103 +++++++++++++++++++++++++++++++++++++++----
 tools/libxl/libxl_internal.h |   4 ++
 tools/libxl/xl_cmdimpl.c     |  22 ++++++++-
 4 files changed, 124 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 41d6e8d..c802635 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -919,6 +919,12 @@ int static inline libxl_domain_create_restore_0x040200(
 
 #endif
 
+int libxl_domain_soft_reset(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            uint32_t *domid, uint32_t domid_old,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+
   /* A progress report will be made via ao_console_how, of type
    * domain_create_console_available, when the domain's primary
    * console is available and can be connected to.
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1198225..b1e809b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -25,6 +25,8 @@
 #include <xen/hvm/hvm_info_table.h>
 #include <xen/hvm/e820.h>
 
+#define INVALID_DOMID ~0
+
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                          libxl_domain_create_info *c_info)
 {
@@ -903,6 +905,9 @@ static void initiate_domain_create(libxl__egc *egc,
     if (restore_fd >= 0) {
         LOG(DEBUG, "restoring, not running bootloader");
         domcreate_bootloader_done(egc, &dcs->bl, 0);
+    } else if (dcs->domid_soft_reset != INVALID_DOMID) {
+        LOG(DEBUG, "soft reset, not running bootloader\n");
+        domcreate_bootloader_done(egc, &dcs->bl, 0);
     } else  {
         LOG(DEBUG, "running bootloader");
         dcs->bl.callback = domcreate_bootloader_done;
@@ -951,6 +956,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl_domain_config *const d_config = dcs->guest_config;
     libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
+    const uint32_t domid_soft_reset = dcs->domid_soft_reset;
     libxl__domain_build_state *const state = &dcs->build_state;
     libxl__srm_restore_autogen_callbacks *const callbacks =
         &dcs->shs.callbacks.restore.a;
@@ -974,7 +980,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->dmss.dm.callback = domcreate_devmodel_started;
     dcs->dmss.callback = domcreate_devmodel_started;
 
-    if ( restore_fd < 0 ) {
+    if ( (restore_fd < 0) && (domid_soft_reset == INVALID_DOMID) ) {
         rc = libxl__domain_build(gc, d_config, domid, state);
         domcreate_rebuild_done(egc, dcs, rc);
         return;
@@ -1004,14 +1010,74 @@ static void domcreate_bootloader_done(libxl__egc *egc,
         rc = ERROR_INVAL;
         goto out;
     }
-    libxl__xc_domain_restore(egc, dcs,
-                             hvm, pae, superpages);
+    if ( restore_fd >= 0 ) {
+        libxl__xc_domain_restore(egc, dcs,
+                                 hvm, pae, superpages);
+    } else {
+        libxl__xc_domain_soft_reset(egc, dcs);
+    }
+
     return;
 
  out:
     libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
 }
 
+void libxl__xc_domain_soft_reset(libxl__egc *egc,
+                                 libxl__domain_create_state *dcs)
+{
+    STATE_AO_GC(dcs->ao);
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    const uint32_t domid_soft_reset = dcs->domid_soft_reset;
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
+    uint8_t *buf;
+    uint32_t len;
+    uint32_t console_domid, store_domid;
+    unsigned long store_mfn, console_mfn;
+    int rc;
+    struct libxl__domain_suspend_state *dss;
+
+    GCNEW(dss);
+
+    dss->ao = ao;
+    dss->domid = domid_soft_reset;
+    dss->dm_savefile = GCSPRINTF("/var/lib/xen/qemu-save.%d",
+                                 domid_soft_reset);
+
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        rc = libxl__domain_suspend_device_model(gc, dss);
+        if (rc) goto out;
+    }
+
+    console_domid = dcs->build_state.console_domid;
+    store_domid = dcs->build_state.store_domid;
+
+    libxl__domain_soft_reset_destroy_old(ctx, domid_soft_reset, 0);
+
+    rc = xc_domain_soft_reset(ctx->xch, domid_soft_reset, domid, console_domid,
+                              &console_mfn, store_domid, &store_mfn);
+    if (rc) goto out;
+
+    libxl__qmp_cleanup(gc, domid_soft_reset);
+
+    dcs->build_state.store_mfn = store_mfn;
+    dcs->build_state.console_mfn = console_mfn;
+
+    rc = libxl__toolstack_save(domid_soft_reset, &buf, &len, dss);
+    if (rc) goto out;
+
+    rc = libxl__toolstack_restore(domid, buf, len, &dcs->shs);
+    if (rc) goto out;
+out:
+    /*
+     * Now pretend we did normal restore and simply call
+     * libxl__xc_domain_restore_done().
+     */
+    libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
+}
+
 void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
           unsigned long console_mfn, void *user)
 {
@@ -1037,6 +1103,7 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
 
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
+    const uint32_t domid_soft_reset = dcs->domid_soft_reset;
     libxl_domain_config *const d_config = dcs->guest_config;
     libxl_domain_build_info *const info = &d_config->b_info;
     libxl__domain_build_state *const state = &dcs->build_state;
@@ -1089,9 +1156,12 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
     if (ret)
         goto out;
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM && fd != -1) {
         state->saved_state = GCSPRINTF(
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
+    } else if (domid_soft_reset != INVALID_DOMID) {
+        state->saved_state = GCSPRINTF(
+                       "/var/lib/xen/qemu-save.%d", domid_soft_reset);
     }
 
 out:
@@ -1100,9 +1170,12 @@ out:
         libxl__file_reference_unmap(&state->pv_ramdisk);
     }
 
-    esave = errno;
-    libxl_fd_set_nonblock(ctx, fd, 0);
-    errno = esave;
+    if ( fd != -1 ) {
+        esave = errno;
+        libxl_fd_set_nonblock(ctx, fd, 0);
+        errno = esave;
+    }
+
     domcreate_rebuild_done(egc, dcs, ret);
 }
 
@@ -1495,6 +1568,7 @@ static void domain_create_cb(libxl__egc *egc,
 static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid,
                             int restore_fd, int checkpointed_stream,
+                            uint32_t domid_old,
                             const libxl_asyncop_how *ao_how,
                             const libxl_asyncprogress_how *aop_console_how)
 {
@@ -1507,6 +1581,7 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     libxl_domain_config_init(&cdcs->dcs.guest_config_saved);
     libxl_domain_config_copy(ctx, &cdcs->dcs.guest_config_saved, d_config);
     cdcs->dcs.restore_fd = restore_fd;
+    cdcs->dcs.domid_soft_reset = domid_old;
     cdcs->dcs.callback = domain_create_cb;
     cdcs->dcs.checkpointed_stream = checkpointed_stream;
     libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
@@ -1535,7 +1610,7 @@ int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             const libxl_asyncop_how *ao_how,
                             const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, domid, -1, 0,
+    return do_domain_create(ctx, d_config, domid, -1, 0, INVALID_DOMID,
                             ao_how, aop_console_how);
 }
 
@@ -1546,7 +1621,17 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 const libxl_asyncprogress_how *aop_console_how)
 {
     return do_domain_create(ctx, d_config, domid, restore_fd,
-                            params->checkpointed_stream, ao_how, aop_console_how);
+                            params->checkpointed_stream, INVALID_DOMID,
+                            ao_how, aop_console_how);
+}
+
+int libxl_domain_soft_reset(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            uint32_t *domid, uint32_t domid_old,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
+{
+    return do_domain_create(ctx, d_config, domid, -1, 0, domid_old,
+                            ao_how, aop_console_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f29ed83..e40bba1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3069,6 +3069,7 @@ struct libxl__domain_create_state {
     libxl_domain_config *guest_config;
     libxl_domain_config guest_config_saved; /* vanilla config */
     int restore_fd;
+    uint32_t domid_soft_reset;
     libxl__domain_create_cb *callback;
     libxl_asyncprogress_how aop_console_how;
     /* private to domain_create */
@@ -3123,6 +3124,9 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
  * If rc!=0, retval and errnoval are undefined. */
 _hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
+/* calls libxl__xc_domain_restore_done when done */
+_hidden void libxl__xc_domain_soft_reset(libxl__egc *egc,
+                                         libxl__domain_create_state *dcs);
 
 /* Each time the dm needs to be saved, we must call suspend and then save */
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 53611dc..eb833f0 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2043,7 +2043,8 @@ static void reload_domain_config(uint32_t domid,
 }
 
 /* Returns 1 if domain should be restarted,
- * 2 if domain should be renamed then restarted, or 0
+ * 2 if domain should be renamed then restarted,
+ * 3 if domain performed soft reset, or 0
  * Can update r_domid if domain is destroyed etc */
 static int handle_domain_death(uint32_t *r_domid,
                                libxl_event *event,
@@ -2069,6 +2070,9 @@ static int handle_domain_death(uint32_t *r_domid,
     case LIBXL_SHUTDOWN_REASON_WATCHDOG:
         action = d_config->on_watchdog;
         break;
+    case LIBXL_SHUTDOWN_REASON_SOFT_RESET:
+        LOG("Domain performed soft reset.");
+        return 3;
     default:
         LOG("Unknown shutdown reason code %d. Destroying domain.",
             event->u.domain_shutdown.shutdown_reason);
@@ -2285,6 +2289,7 @@ static void evdisable_disk_ejects(libxl_evgen_disk_eject **diskws,
 static uint32_t create_domain(struct domain_create *dom_info)
 {
     uint32_t domid = INVALID_DOMID;
+    uint32_t domid_old = INVALID_DOMID;
 
     libxl_domain_config d_config;
 
@@ -2510,7 +2515,18 @@ start:
          * restore/migrate-receive it again.
          */
         restoring = 0;
-    }else{
+    } else if (domid_old != INVALID_DOMID) {
+        /* Do soft reset */
+        d_config.b_info.nodemap.size = 0;
+        ret = libxl_domain_soft_reset(ctx, &d_config,
+                                      &domid, domid_old,
+                                      0, 0);
+
+        if ( ret ) {
+            goto error_out;
+        }
+        domid_old = INVALID_DOMID;
+    } else {
         ret = libxl_domain_create_new(ctx, &d_config, &domid,
                                       0, autoconnect_console_how);
     }
@@ -2574,6 +2590,8 @@ start:
                 event->u.domain_shutdown.shutdown_reason,
                 event->u.domain_shutdown.shutdown_reason);
             switch (handle_domain_death(&domid, event, &d_config)) {
+            case 3:
+                domid_old = domid;
             case 2:
                 if (!preserve_domain(&domid, event, &d_config)) {
                     /* If we fail then exit leaving the old domain in place. */
-- 
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 Dec 03 17:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXj-0004LQ-DT; Wed, 03 Dec 2014 17:16:47 +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 1XwDXh-0004Ku-Tz
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:46 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6F/37-15461-D754F745; Wed, 03 Dec 2014 17:16:45 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417627003!13168840!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26664 invoked from network); 3 Dec 2014 17:16:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:16:44 -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 sB3HGa6c023005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:37 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkR008593; Wed, 3 Dec 2014 12:16:34 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:16 +0100
Message-Id: <1417626981-8432-5-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

New operation sets the 'recipient' domain which will recieve all
memory pages from a particular domain and kills the original domain.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/domain.c         |  3 +++
 xen/common/domctl.c         | 33 +++++++++++++++++++++++++++++++++
 xen/common/page_alloc.c     | 28 ++++++++++++++++++++++++----
 xen/include/public/domctl.h | 15 +++++++++++++++
 xen/include/xen/sched.h     |  2 ++
 5 files changed, 77 insertions(+), 4 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index c13a7cf..f26267a 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -825,6 +825,9 @@ static void complete_domain_destroy(struct rcu_head *head)
     if ( d->target != NULL )
         put_domain(d->target);
 
+    if ( d->recipient != NULL )
+        put_domain(d->recipient);
+
     evtchn_destroy_final(d);
 
     radix_tree_destroy(&d->pirq_tree, free_pirq_struct);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index f15dcfe..7e7fb47 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1177,6 +1177,39 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_devour:
+    {
+        struct domain *recipient_dom;
+
+        if ( !d->recipient )
+        {
+            recipient_dom = get_domain_by_id(op->u.devour.recipient);
+            if ( recipient_dom == NULL )
+            {
+                ret = -ESRCH;
+                break;
+            }
+
+            if ( recipient_dom->tot_pages != 0 )
+            {
+                put_domain(recipient_dom);
+                ret = -EINVAL;
+                break;
+            }
+            /*
+             * Make sure no allocation/remapping is ongoing and set is_dying
+             * flag to prevent such actions in future.
+             */
+            spin_lock(&d->page_alloc_lock);
+            d->is_dying = DOMDYING_locked;
+            d->recipient = recipient_dom;
+            smp_wmb(); /* make sure recipient was set before domain_kill() */
+            spin_unlock(&d->page_alloc_lock);
+        }
+        ret = domain_kill(d);
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 7b4092d..7eb4404 100644
--- 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,13 +1765,32 @@ 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);
+            if ( assign_pages(d->recipient, pg, order, 0) )
+                /* assign_pages reports the error by itself */
+                goto out;
+
+            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
+                printk(XENLOG_G_INFO
+                       "Failed to add MFN %lx (GFN %lx) to Dom%d's physmap\n",
+                       mfn, gmfn, d->recipient->domain_id);
+        }
     }
 
+out:
     if ( drop_dom_ref )
         put_domain(d);
 }
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 57e2ed7..871fa5e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -995,6 +995,19 @@ struct xen_domctl_psr_cmt_op {
 typedef struct xen_domctl_psr_cmt_op xen_domctl_psr_cmt_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cmt_op_t);
 
+/*
+ * XEN_DOMCTL_devour - kills the domain reassigning all of its domheap pages
+ * to the 'recipient' domain. Pages from xen heap belonging to the domain
+ * are not copied. Reassigned pages are mapped to the same GMFNs in the
+ * recipient domain as they were mapped in the original. The recipient domain
+ * is supposed to not have any domheap pages to avoid MFN-GMFN collisions.
+ */
+struct xen_domctl_devour {
+    domid_t recipient;
+};
+typedef struct xen_domctl_devour xen_domctl_devour_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_devour_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -1070,6 +1083,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_setvnumainfo                  74
 #define XEN_DOMCTL_psr_cmt_op                    75
 #define XEN_DOMCTL_arm_configure_domain          76
+#define XEN_DOMCTL_devour                        77
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1135,6 +1149,7 @@ struct xen_domctl {
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         struct xen_domctl_vnuma             vnuma;
         struct xen_domctl_psr_cmt_op        psr_cmt_op;
+        struct xen_domctl_devour            devour;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index a42d0b8..552e4a3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -366,6 +366,8 @@ struct domain
     bool_t           is_privileged;
     /* Which guest this guest has privileges on */
     struct domain   *target;
+    /* Which guest receives freed memory pages */
+    struct domain   *recipient;
     /* Is this guest being debugged by dom0? */
     bool_t           debugger_attached;
     /* Is this guest dying (i.e., a zombie)? */
-- 
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 Dec 03 17:16:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXq-0004P0-H2; Wed, 03 Dec 2014 17:16:54 +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 1XwDXo-0004OH-R3
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:53 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	A1/93-02696-4854F745; Wed, 03 Dec 2014 17:16:52 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417627009!12791058!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20335 invoked from network); 3 Dec 2014 17:16:51 -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; 3 Dec 2014 17:16:51 -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 sB3HGjjg031555
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:45 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkU008593; Wed, 3 Dec 2014 12:16:42 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:19 +0100
Message-Id: <1417626981-8432-8-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 7/9] libxc: introduce soft reset for 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>
MIME-Version: 1.0
Content-Type: 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 new xc_domain_soft_reset() function which performs so-called 'soft reset'
for an HVM domain. It is being performed in the following way:
- Save HVM context and all HVM params;
- Devour original domain with XEN_DOMCTL_devour;
- Wait till original domain dies or has no pages left;
- Restore HVM context, HVM params, seed grant table.

After that the domain resumes execution from where SHUTDOWN_soft_reset was
called.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxc/Makefile               |   1 +
 tools/libxc/include/xenguest.h     |  20 +++
 tools/libxc/xc_domain_soft_reset.c | 282 +++++++++++++++++++++++++++++++++++++
 3 files changed, 303 insertions(+)
 create mode 100644 tools/libxc/xc_domain_soft_reset.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index bd2ca6c..8f8abd6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -52,6 +52,7 @@ GUEST_SRCS-y += xc_offline_page.c xc_compression.c
 else
 GUEST_SRCS-y += xc_nomigrate.c
 endif
+GUEST_SRCS-y += xc_domain_soft_reset.c
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 40bbac8..770cd10 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -131,6 +131,26 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
  * of the new domain is automatically appended to the filename,
  * separated by a ".".
  */
+
+/**
+ * This function does soft reset for a domain. During soft reset all
+ * source domain's memory is being reassigned to the destination domain,
+ * HVM context and HVM params are being copied.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm source_dom the id of the source domain
+ * @parm dest_dom the id of the destination domain
+ * @parm console_domid the id of the domain handling console
+ * @parm console_mfn returned with the mfn of the console page
+ * @parm store_domid the id of the domain handling store
+ * @parm store_mfn returned with the mfn of the store page
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_soft_reset(xc_interface *xch, uint32_t source_dom,
+                         uint32_t dest_dom, domid_t console_domid,
+                         unsigned long *console_mfn, domid_t store_domid,
+                         unsigned long *store_mfn);
+
 #define XC_DEVICE_MODEL_RESTORE_FILE "/var/lib/xen/qemu-resume"
 
 /**
diff --git a/tools/libxc/xc_domain_soft_reset.c b/tools/libxc/xc_domain_soft_reset.c
new file mode 100644
index 0000000..24d0b48
--- /dev/null
+++ b/tools/libxc/xc_domain_soft_reset.c
@@ -0,0 +1,282 @@
+/******************************************************************************
+ * xc_domain_soft_reset.c
+ *
+ * Do soft reset.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <inttypes.h>
+#include <time.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <sys/time.h>
+
+#include "xc_private.h"
+#include "xc_core.h"
+#include "xc_bitops.h"
+#include "xc_dom.h"
+#include "xg_private.h"
+#include "xg_save_restore.h"
+
+#include <xen/hvm/params.h>
+
+#define SLEEP_INT 1
+
+int xc_domain_soft_reset(xc_interface *xch, uint32_t source_dom,
+                         uint32_t dest_dom, domid_t console_domid,
+                         unsigned long *console_mfn, domid_t store_domid,
+                         unsigned long *store_mfn)
+{
+    xc_dominfo_t old_info, new_info;
+    int rc = 1;
+
+    uint32_t hvm_buf_size = 0;
+    uint8_t *hvm_buf = NULL;
+    unsigned long console_pfn, store_pfn, io_pfn, buffio_pfn;
+    unsigned long max_gpfn;
+    uint64_t hvm_params[HVM_NR_PARAMS];
+    xen_pfn_t sharedinfo_pfn;
+
+    DPRINTF("%s: soft reset domid %u -> %u", __func__, source_dom, dest_dom);
+
+    if ( xc_domain_getinfo(xch, source_dom, 1, &old_info) != 1 )
+    {
+        PERROR("Could not get old domain info");
+        return 1;
+    }
+
+    if ( xc_domain_getinfo(xch, dest_dom, 1, &new_info) != 1 )
+    {
+        PERROR("Could not get new domain info");
+        return 1;
+    }
+
+    if ( !old_info.hvm || !new_info.hvm )
+    {
+        PERROR("Soft reset is supported for HVM only");
+        return 1;
+    }
+
+    max_gpfn = xc_domain_maximum_gpfn(xch, source_dom);
+
+    sharedinfo_pfn = old_info.shared_info_frame;
+    if ( xc_get_pfn_type_batch(xch, source_dom, 1, &sharedinfo_pfn) )
+    {
+        PERROR("xc_get_pfn_type_batch failed");
+        goto out;
+    }
+
+    hvm_buf_size = xc_domain_hvm_getcontext(xch, source_dom, 0, 0);
+    if ( hvm_buf_size == -1 )
+    {
+        PERROR("Couldn't get HVM context size from Xen");
+        goto out;
+    }
+
+    hvm_buf = malloc(hvm_buf_size);
+    if ( !hvm_buf )
+    {
+        ERROR("Couldn't allocate memory");
+        goto out;
+    }
+
+    if ( xc_domain_hvm_getcontext(xch, source_dom, hvm_buf,
+                                  hvm_buf_size) == -1 )
+    {
+        PERROR("HVM:Could not get hvm buffer");
+        goto out;
+    }
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_STORE_PFN,
+                     &hvm_params[HVM_PARAM_STORE_PFN]);
+    store_pfn = hvm_params[HVM_PARAM_STORE_PFN];
+    *store_mfn = store_pfn;
+
+    xc_hvm_param_get(xch, source_dom,
+                     HVM_PARAM_CONSOLE_PFN,
+                     &hvm_params[HVM_PARAM_CONSOLE_PFN]);
+    console_pfn = hvm_params[HVM_PARAM_CONSOLE_PFN];
+    *console_mfn = console_pfn;
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_BUFIOREQ_PFN,
+                     &hvm_params[HVM_PARAM_BUFIOREQ_PFN]);
+    buffio_pfn = hvm_params[HVM_PARAM_BUFIOREQ_PFN];
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_IOREQ_PFN,
+                     &hvm_params[HVM_PARAM_IOREQ_PFN]);
+    io_pfn = hvm_params[HVM_PARAM_IOREQ_PFN];
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_IDENT_PT,
+                     &hvm_params[HVM_PARAM_IDENT_PT]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_PAGING_RING_PFN,
+                     &hvm_params[HVM_PARAM_PAGING_RING_PFN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_ACCESS_RING_PFN,
+                     &hvm_params[HVM_PARAM_ACCESS_RING_PFN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_VM86_TSS,
+                     &hvm_params[HVM_PARAM_VM86_TSS]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_ACPI_IOPORTS_LOCATION,
+                     &hvm_params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_VIRIDIAN,
+                     &hvm_params[HVM_PARAM_VIRIDIAN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_PAE_ENABLED,
+                     &hvm_params[HVM_PARAM_PAE_ENABLED]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_STORE_EVTCHN,
+                     &hvm_params[HVM_PARAM_STORE_EVTCHN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_IOREQ_SERVER_PFN,
+                     &hvm_params[HVM_PARAM_IOREQ_SERVER_PFN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
+                     &hvm_params[HVM_PARAM_NR_IOREQ_SERVER_PAGES]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
+                     &hvm_params[HVM_PARAM_VM_GENERATION_ID_ADDR]);
+
+    rc = xc_domain_devour(xch, source_dom, dest_dom);
+    if ( rc != 0 )
+    {
+        PERROR("failed to devour original domain, rc=%d\n", rc);
+        goto out;
+    }
+
+    while ( 1 )
+    {
+        sleep(SLEEP_INT);
+        if ( xc_get_tot_pages(xch, source_dom) <= 0 )
+        {
+            DPRINTF("All pages were transferred");
+            break;
+        }
+    }
+
+
+    if ( sharedinfo_pfn == XEN_DOMCTL_PFINFO_XTAB)
+    {
+        /*
+         * Shared info frame is being removed when guest maps shared info so
+         * this page is likely XEN_DOMCTL_PFINFO_XTAB but we need to replace
+         * it with an empty page in that case.
+         */
+
+        if ( xc_domain_populate_physmap_exact(xch, dest_dom, 1, 0, 0,
+                                              &old_info.shared_info_frame) )
+        {
+            PERROR("failed to populate pfn %lx (shared info)", old_info.shared_info_frame);
+            goto out;
+        }
+    }
+
+    if ( xc_domain_hvm_setcontext(xch, dest_dom, hvm_buf,
+                                  hvm_buf_size) == -1 )
+    {
+        PERROR("HVM:Could not set hvm buffer");
+        goto out;
+    }
+
+    if ( store_pfn )
+        xc_clear_domain_page(xch, dest_dom, store_pfn);
+
+    if ( console_pfn )
+        xc_clear_domain_page(xch, dest_dom, console_pfn);
+
+    if ( buffio_pfn )
+        xc_clear_domain_page(xch, dest_dom, buffio_pfn);
+
+    if ( io_pfn )
+        xc_clear_domain_page(xch, dest_dom, io_pfn);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_STORE_PFN,
+                     hvm_params[HVM_PARAM_STORE_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom,
+                     HVM_PARAM_CONSOLE_PFN,
+                     hvm_params[HVM_PARAM_CONSOLE_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_BUFIOREQ_PFN,
+                     hvm_params[HVM_PARAM_BUFIOREQ_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_IOREQ_PFN,
+                     hvm_params[HVM_PARAM_IOREQ_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_IDENT_PT,
+                     hvm_params[HVM_PARAM_IDENT_PT]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_PAGING_RING_PFN,
+                     hvm_params[HVM_PARAM_PAGING_RING_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_ACCESS_RING_PFN,
+                     hvm_params[HVM_PARAM_ACCESS_RING_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_VM86_TSS,
+                     hvm_params[HVM_PARAM_VM86_TSS]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_ACPI_IOPORTS_LOCATION,
+                     hvm_params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_VIRIDIAN,
+                     hvm_params[HVM_PARAM_VIRIDIAN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_PAE_ENABLED,
+                     hvm_params[HVM_PARAM_PAE_ENABLED]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_STORE_EVTCHN,
+                     hvm_params[HVM_PARAM_STORE_EVTCHN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_IOREQ_SERVER_PFN,
+                     hvm_params[HVM_PARAM_IOREQ_SERVER_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
+                     hvm_params[HVM_PARAM_NR_IOREQ_SERVER_PAGES]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
+                     hvm_params[HVM_PARAM_VM_GENERATION_ID_ADDR]);
+
+    if (xc_dom_gnttab_hvm_seed(xch, dest_dom, console_pfn, store_pfn,
+                               console_domid, store_domid))
+    {
+        PERROR("error seeding hvm grant table");
+        goto out;
+    }
+
+    rc = 0;
+out:
+    if (hvm_buf) free(hvm_buf);
+
+    if ( (rc != 0) && (dest_dom != 0) ) {
+            PERROR("Faled to perform soft reset, destroying domain %d",
+                   dest_dom);
+	    xc_domain_destroy(xch, dest_dom);
+    }
+
+    return !!rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
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 Dec 03 17:16:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXc-0004Jt-Kg; Wed, 03 Dec 2014 17:16:40 +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 1XwDXa-0004Jd-KS
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:38 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	35/FA-25547-5754F745; Wed, 03 Dec 2014 17:16:37 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417626995!10830253!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14358 invoked from network); 3 Dec 2014 17:16:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:16:37 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sB3HGPWe002481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:26 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkN008593; Wed, 3 Dec 2014 12:16:23 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:12 +0100
Message-Id: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 0/9] 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes from RFCv3:
This is the first non-RFC series as no major concerns were expressed. I'm trying
to address Jan's comments. Changes are:
- Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really like
  the name but nothing more appropriate came to my mind) which incorporates
  former XEN_DOMCTL_set_recipient and XEN_DOMCTL_destroydomain to prevent
  original domain from changing its allocations during transfer procedure.
- Check in free_domheap_pages() that assign_pages() succeeded.
- Change printk() in free_domheap_pages().
- DOMDYING_locked state was introduced to support XEN_DOMCTL_devour.
- xc_domain_soft_reset() got simplified a bit. Now we just wait for the original
  domain to die or loose all its pages.
- rebased on top of current master branch.

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.

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 (9):
  xen: introduce DOMDYING_locked state
  xen: introduce SHUTDOWN_soft_reset shutdown reason
  libxl: support SHUTDOWN_soft_reset shutdown reason
  xen: introduce XEN_DOMCTL_devour
  libxc: support XEN_DOMCTL_devour
  libxl: add libxl__domain_soft_reset_destroy_old()
  libxc: introduce soft reset for HVM domains
  libxl: soft reset support
  xsm: add XEN_DOMCTL_devour support

 tools/libxc/Makefile                |   1 +
 tools/libxc/include/xenctrl.h       |  14 ++
 tools/libxc/include/xenguest.h      |  20 +++
 tools/libxc/xc_domain.c             |  13 ++
 tools/libxc/xc_domain_soft_reset.c  | 282 ++++++++++++++++++++++++++++++++++++
 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                 |   4 +
 xen/common/domctl.c                 |  39 +++++
 xen/common/page_alloc.c             |  28 +++-
 xen/common/shutdown.c               |   7 +
 xen/include/public/domctl.h         |  15 ++
 xen/include/public/sched.h          |   3 +-
 xen/include/xen/sched.h             |   5 +-
 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, 623 insertions(+), 23 deletions(-)
 create mode 100644 tools/libxc/xc_domain_soft_reset.c

-- 
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 Dec 03 17:16:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXc-0004Jt-Kg; Wed, 03 Dec 2014 17:16:40 +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 1XwDXa-0004Jd-KS
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:38 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	35/FA-25547-5754F745; Wed, 03 Dec 2014 17:16:37 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417626995!10830253!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14358 invoked from network); 3 Dec 2014 17:16:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:16:37 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sB3HGPWe002481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:26 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkN008593; Wed, 3 Dec 2014 12:16:23 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:12 +0100
Message-Id: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 0/9] 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes from RFCv3:
This is the first non-RFC series as no major concerns were expressed. I'm trying
to address Jan's comments. Changes are:
- Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really like
  the name but nothing more appropriate came to my mind) which incorporates
  former XEN_DOMCTL_set_recipient and XEN_DOMCTL_destroydomain to prevent
  original domain from changing its allocations during transfer procedure.
- Check in free_domheap_pages() that assign_pages() succeeded.
- Change printk() in free_domheap_pages().
- DOMDYING_locked state was introduced to support XEN_DOMCTL_devour.
- xc_domain_soft_reset() got simplified a bit. Now we just wait for the original
  domain to die or loose all its pages.
- rebased on top of current master branch.

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.

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 (9):
  xen: introduce DOMDYING_locked state
  xen: introduce SHUTDOWN_soft_reset shutdown reason
  libxl: support SHUTDOWN_soft_reset shutdown reason
  xen: introduce XEN_DOMCTL_devour
  libxc: support XEN_DOMCTL_devour
  libxl: add libxl__domain_soft_reset_destroy_old()
  libxc: introduce soft reset for HVM domains
  libxl: soft reset support
  xsm: add XEN_DOMCTL_devour support

 tools/libxc/Makefile                |   1 +
 tools/libxc/include/xenctrl.h       |  14 ++
 tools/libxc/include/xenguest.h      |  20 +++
 tools/libxc/xc_domain.c             |  13 ++
 tools/libxc/xc_domain_soft_reset.c  | 282 ++++++++++++++++++++++++++++++++++++
 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                 |   4 +
 xen/common/domctl.c                 |  39 +++++
 xen/common/page_alloc.c             |  28 +++-
 xen/common/shutdown.c               |   7 +
 xen/include/public/domctl.h         |  15 ++
 xen/include/public/sched.h          |   3 +-
 xen/include/xen/sched.h             |   5 +-
 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, 623 insertions(+), 23 deletions(-)
 create mode 100644 tools/libxc/xc_domain_soft_reset.c

-- 
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 Dec 03 17:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXa-0004Je-8h; Wed, 03 Dec 2014 17:16:38 +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 1XwDXZ-0004JY-GF
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	25/04-09842-4754F745; Wed, 03 Dec 2014 17:16:36 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417626994!13223446!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20370 invoked from network); 3 Dec 2014 17:16:36 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:16:36 -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 sB3HGSLO031427
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:28 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkO008593; Wed, 3 Dec 2014 12:16:26 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:13 +0100
Message-Id: <1417626981-8432-2-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 1/9] xen: introduce DOMDYING_locked state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

New dying state is requred to indicate that a particular domain
is dying but cleanup procedure wasn't started. This state can be
set from outside of domain_kill().

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/domain.c     | 1 +
 xen/include/xen/sched.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 4a62c1d..c13a7cf 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -603,6 +603,7 @@ int domain_kill(struct domain *d)
     switch ( d->is_dying )
     {
     case DOMDYING_alive:
+    case DOMDYING_locked:
         domain_pause(d);
         d->is_dying = DOMDYING_dying;
         spin_barrier(&d->domain_lock);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 46fc6e3..a42d0b8 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -369,7 +369,8 @@ struct domain
     /* Is this guest being debugged by dom0? */
     bool_t           debugger_attached;
     /* Is this guest dying (i.e., a zombie)? */
-    enum { DOMDYING_alive, DOMDYING_dying, DOMDYING_dead } is_dying;
+    enum { DOMDYING_alive, DOMDYING_locked, DOMDYING_dying, DOMDYING_dead }
+        is_dying;
     /* Domain is paused by controller software? */
     int              controller_pause_count;
     /* Domain's VCPUs are pinned 1:1 to physical CPUs? */
-- 
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 Dec 03 17:16:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXg-0004KV-0e; Wed, 03 Dec 2014 17:16:44 +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 1XwDXe-0004KF-NP
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:42 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	1A/18-02712-A754F745; Wed, 03 Dec 2014 17:16:42 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417626999!9451648!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24039 invoked from network); 3 Dec 2014 17:16:41 -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 Dec 2014 17:16:41 -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 sB3HGYkn018183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:34 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkQ008593; Wed, 3 Dec 2014 12:16:31 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:15 +0100
Message-Id: <1417626981-8432-4-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 3/9] libxl: support SHUTDOWN_soft_reset
	shutdown reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 letter 't' to indicate a domain in such state.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxl/libxl_types.idl       | 1 +
 tools/libxl/xl_cmdimpl.c          | 2 +-
 tools/python/xen/lowlevel/xl/xl.c | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..4a0e2be 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -175,6 +175,7 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
     (2, "suspend"),
     (3, "crash"),
     (4, "watchdog"),
+    (5, "soft_reset"),
     ], init_val = "LIBXL_SHUTDOWN_REASON_UNKNOWN")
 
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0e754e7..53611dc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3497,7 +3497,7 @@ static void list_domains(int verbose, int context, int claim, int numa,
                          const libxl_dominfo *info, int nb_domain)
 {
     int i;
-    static const char shutdown_reason_letters[]= "-rscw";
+    static const char shutdown_reason_letters[]= "-rscwt";
     libxl_bitmap nodemap;
     libxl_physinfo physinfo;
 
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index 32f982a..7c61160 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -784,6 +784,7 @@ PyMODINIT_FUNC initxl(void)
     _INT_CONST_LIBXL(m, SHUTDOWN_REASON_SUSPEND);
     _INT_CONST_LIBXL(m, SHUTDOWN_REASON_CRASH);
     _INT_CONST_LIBXL(m, SHUTDOWN_REASON_WATCHDOG);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_SOFT_RESET);
 
     genwrap__init(m);
 }
-- 
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 Dec 03 17:16:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXg-0004KV-0e; Wed, 03 Dec 2014 17:16:44 +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 1XwDXe-0004KF-NP
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:42 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	1A/18-02712-A754F745; Wed, 03 Dec 2014 17:16:42 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417626999!9451648!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24039 invoked from network); 3 Dec 2014 17:16:41 -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 Dec 2014 17:16:41 -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 sB3HGYkn018183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:34 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkQ008593; Wed, 3 Dec 2014 12:16:31 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:15 +0100
Message-Id: <1417626981-8432-4-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 3/9] libxl: support SHUTDOWN_soft_reset
	shutdown reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 letter 't' to indicate a domain in such state.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxl/libxl_types.idl       | 1 +
 tools/libxl/xl_cmdimpl.c          | 2 +-
 tools/python/xen/lowlevel/xl/xl.c | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..4a0e2be 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -175,6 +175,7 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
     (2, "suspend"),
     (3, "crash"),
     (4, "watchdog"),
+    (5, "soft_reset"),
     ], init_val = "LIBXL_SHUTDOWN_REASON_UNKNOWN")
 
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0e754e7..53611dc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3497,7 +3497,7 @@ static void list_domains(int verbose, int context, int claim, int numa,
                          const libxl_dominfo *info, int nb_domain)
 {
     int i;
-    static const char shutdown_reason_letters[]= "-rscw";
+    static const char shutdown_reason_letters[]= "-rscwt";
     libxl_bitmap nodemap;
     libxl_physinfo physinfo;
 
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index 32f982a..7c61160 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -784,6 +784,7 @@ PyMODINIT_FUNC initxl(void)
     _INT_CONST_LIBXL(m, SHUTDOWN_REASON_SUSPEND);
     _INT_CONST_LIBXL(m, SHUTDOWN_REASON_CRASH);
     _INT_CONST_LIBXL(m, SHUTDOWN_REASON_WATCHDOG);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_SOFT_RESET);
 
     genwrap__init(m);
 }
-- 
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 Dec 03 17:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXa-0004Je-8h; Wed, 03 Dec 2014 17:16:38 +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 1XwDXZ-0004JY-GF
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	25/04-09842-4754F745; Wed, 03 Dec 2014 17:16:36 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417626994!13223446!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20370 invoked from network); 3 Dec 2014 17:16:36 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:16:36 -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 sB3HGSLO031427
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:28 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkO008593; Wed, 3 Dec 2014 12:16:26 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:13 +0100
Message-Id: <1417626981-8432-2-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 1/9] xen: introduce DOMDYING_locked state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

New dying state is requred to indicate that a particular domain
is dying but cleanup procedure wasn't started. This state can be
set from outside of domain_kill().

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/domain.c     | 1 +
 xen/include/xen/sched.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 4a62c1d..c13a7cf 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -603,6 +603,7 @@ int domain_kill(struct domain *d)
     switch ( d->is_dying )
     {
     case DOMDYING_alive:
+    case DOMDYING_locked:
         domain_pause(d);
         d->is_dying = DOMDYING_dying;
         spin_barrier(&d->domain_lock);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 46fc6e3..a42d0b8 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -369,7 +369,8 @@ struct domain
     /* Is this guest being debugged by dom0? */
     bool_t           debugger_attached;
     /* Is this guest dying (i.e., a zombie)? */
-    enum { DOMDYING_alive, DOMDYING_dying, DOMDYING_dead } is_dying;
+    enum { DOMDYING_alive, DOMDYING_locked, DOMDYING_dying, DOMDYING_dead }
+        is_dying;
     /* Domain is paused by controller software? */
     int              controller_pause_count;
     /* Domain's VCPUs are pinned 1:1 to physical CPUs? */
-- 
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 Dec 03 17:16:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXq-0004P0-H2; Wed, 03 Dec 2014 17:16:54 +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 1XwDXo-0004OH-R3
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:53 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	A1/93-02696-4854F745; Wed, 03 Dec 2014 17:16:52 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417627009!12791058!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20335 invoked from network); 3 Dec 2014 17:16:51 -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; 3 Dec 2014 17:16:51 -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 sB3HGjjg031555
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:45 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkU008593; Wed, 3 Dec 2014 12:16:42 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:19 +0100
Message-Id: <1417626981-8432-8-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 7/9] libxc: introduce soft reset for 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>
MIME-Version: 1.0
Content-Type: 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 new xc_domain_soft_reset() function which performs so-called 'soft reset'
for an HVM domain. It is being performed in the following way:
- Save HVM context and all HVM params;
- Devour original domain with XEN_DOMCTL_devour;
- Wait till original domain dies or has no pages left;
- Restore HVM context, HVM params, seed grant table.

After that the domain resumes execution from where SHUTDOWN_soft_reset was
called.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxc/Makefile               |   1 +
 tools/libxc/include/xenguest.h     |  20 +++
 tools/libxc/xc_domain_soft_reset.c | 282 +++++++++++++++++++++++++++++++++++++
 3 files changed, 303 insertions(+)
 create mode 100644 tools/libxc/xc_domain_soft_reset.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index bd2ca6c..8f8abd6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -52,6 +52,7 @@ GUEST_SRCS-y += xc_offline_page.c xc_compression.c
 else
 GUEST_SRCS-y += xc_nomigrate.c
 endif
+GUEST_SRCS-y += xc_domain_soft_reset.c
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 40bbac8..770cd10 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -131,6 +131,26 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
  * of the new domain is automatically appended to the filename,
  * separated by a ".".
  */
+
+/**
+ * This function does soft reset for a domain. During soft reset all
+ * source domain's memory is being reassigned to the destination domain,
+ * HVM context and HVM params are being copied.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm source_dom the id of the source domain
+ * @parm dest_dom the id of the destination domain
+ * @parm console_domid the id of the domain handling console
+ * @parm console_mfn returned with the mfn of the console page
+ * @parm store_domid the id of the domain handling store
+ * @parm store_mfn returned with the mfn of the store page
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_soft_reset(xc_interface *xch, uint32_t source_dom,
+                         uint32_t dest_dom, domid_t console_domid,
+                         unsigned long *console_mfn, domid_t store_domid,
+                         unsigned long *store_mfn);
+
 #define XC_DEVICE_MODEL_RESTORE_FILE "/var/lib/xen/qemu-resume"
 
 /**
diff --git a/tools/libxc/xc_domain_soft_reset.c b/tools/libxc/xc_domain_soft_reset.c
new file mode 100644
index 0000000..24d0b48
--- /dev/null
+++ b/tools/libxc/xc_domain_soft_reset.c
@@ -0,0 +1,282 @@
+/******************************************************************************
+ * xc_domain_soft_reset.c
+ *
+ * Do soft reset.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <inttypes.h>
+#include <time.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <sys/time.h>
+
+#include "xc_private.h"
+#include "xc_core.h"
+#include "xc_bitops.h"
+#include "xc_dom.h"
+#include "xg_private.h"
+#include "xg_save_restore.h"
+
+#include <xen/hvm/params.h>
+
+#define SLEEP_INT 1
+
+int xc_domain_soft_reset(xc_interface *xch, uint32_t source_dom,
+                         uint32_t dest_dom, domid_t console_domid,
+                         unsigned long *console_mfn, domid_t store_domid,
+                         unsigned long *store_mfn)
+{
+    xc_dominfo_t old_info, new_info;
+    int rc = 1;
+
+    uint32_t hvm_buf_size = 0;
+    uint8_t *hvm_buf = NULL;
+    unsigned long console_pfn, store_pfn, io_pfn, buffio_pfn;
+    unsigned long max_gpfn;
+    uint64_t hvm_params[HVM_NR_PARAMS];
+    xen_pfn_t sharedinfo_pfn;
+
+    DPRINTF("%s: soft reset domid %u -> %u", __func__, source_dom, dest_dom);
+
+    if ( xc_domain_getinfo(xch, source_dom, 1, &old_info) != 1 )
+    {
+        PERROR("Could not get old domain info");
+        return 1;
+    }
+
+    if ( xc_domain_getinfo(xch, dest_dom, 1, &new_info) != 1 )
+    {
+        PERROR("Could not get new domain info");
+        return 1;
+    }
+
+    if ( !old_info.hvm || !new_info.hvm )
+    {
+        PERROR("Soft reset is supported for HVM only");
+        return 1;
+    }
+
+    max_gpfn = xc_domain_maximum_gpfn(xch, source_dom);
+
+    sharedinfo_pfn = old_info.shared_info_frame;
+    if ( xc_get_pfn_type_batch(xch, source_dom, 1, &sharedinfo_pfn) )
+    {
+        PERROR("xc_get_pfn_type_batch failed");
+        goto out;
+    }
+
+    hvm_buf_size = xc_domain_hvm_getcontext(xch, source_dom, 0, 0);
+    if ( hvm_buf_size == -1 )
+    {
+        PERROR("Couldn't get HVM context size from Xen");
+        goto out;
+    }
+
+    hvm_buf = malloc(hvm_buf_size);
+    if ( !hvm_buf )
+    {
+        ERROR("Couldn't allocate memory");
+        goto out;
+    }
+
+    if ( xc_domain_hvm_getcontext(xch, source_dom, hvm_buf,
+                                  hvm_buf_size) == -1 )
+    {
+        PERROR("HVM:Could not get hvm buffer");
+        goto out;
+    }
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_STORE_PFN,
+                     &hvm_params[HVM_PARAM_STORE_PFN]);
+    store_pfn = hvm_params[HVM_PARAM_STORE_PFN];
+    *store_mfn = store_pfn;
+
+    xc_hvm_param_get(xch, source_dom,
+                     HVM_PARAM_CONSOLE_PFN,
+                     &hvm_params[HVM_PARAM_CONSOLE_PFN]);
+    console_pfn = hvm_params[HVM_PARAM_CONSOLE_PFN];
+    *console_mfn = console_pfn;
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_BUFIOREQ_PFN,
+                     &hvm_params[HVM_PARAM_BUFIOREQ_PFN]);
+    buffio_pfn = hvm_params[HVM_PARAM_BUFIOREQ_PFN];
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_IOREQ_PFN,
+                     &hvm_params[HVM_PARAM_IOREQ_PFN]);
+    io_pfn = hvm_params[HVM_PARAM_IOREQ_PFN];
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_IDENT_PT,
+                     &hvm_params[HVM_PARAM_IDENT_PT]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_PAGING_RING_PFN,
+                     &hvm_params[HVM_PARAM_PAGING_RING_PFN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_ACCESS_RING_PFN,
+                     &hvm_params[HVM_PARAM_ACCESS_RING_PFN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_VM86_TSS,
+                     &hvm_params[HVM_PARAM_VM86_TSS]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_ACPI_IOPORTS_LOCATION,
+                     &hvm_params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_VIRIDIAN,
+                     &hvm_params[HVM_PARAM_VIRIDIAN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_PAE_ENABLED,
+                     &hvm_params[HVM_PARAM_PAE_ENABLED]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_STORE_EVTCHN,
+                     &hvm_params[HVM_PARAM_STORE_EVTCHN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_IOREQ_SERVER_PFN,
+                     &hvm_params[HVM_PARAM_IOREQ_SERVER_PFN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
+                     &hvm_params[HVM_PARAM_NR_IOREQ_SERVER_PAGES]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
+                     &hvm_params[HVM_PARAM_VM_GENERATION_ID_ADDR]);
+
+    rc = xc_domain_devour(xch, source_dom, dest_dom);
+    if ( rc != 0 )
+    {
+        PERROR("failed to devour original domain, rc=%d\n", rc);
+        goto out;
+    }
+
+    while ( 1 )
+    {
+        sleep(SLEEP_INT);
+        if ( xc_get_tot_pages(xch, source_dom) <= 0 )
+        {
+            DPRINTF("All pages were transferred");
+            break;
+        }
+    }
+
+
+    if ( sharedinfo_pfn == XEN_DOMCTL_PFINFO_XTAB)
+    {
+        /*
+         * Shared info frame is being removed when guest maps shared info so
+         * this page is likely XEN_DOMCTL_PFINFO_XTAB but we need to replace
+         * it with an empty page in that case.
+         */
+
+        if ( xc_domain_populate_physmap_exact(xch, dest_dom, 1, 0, 0,
+                                              &old_info.shared_info_frame) )
+        {
+            PERROR("failed to populate pfn %lx (shared info)", old_info.shared_info_frame);
+            goto out;
+        }
+    }
+
+    if ( xc_domain_hvm_setcontext(xch, dest_dom, hvm_buf,
+                                  hvm_buf_size) == -1 )
+    {
+        PERROR("HVM:Could not set hvm buffer");
+        goto out;
+    }
+
+    if ( store_pfn )
+        xc_clear_domain_page(xch, dest_dom, store_pfn);
+
+    if ( console_pfn )
+        xc_clear_domain_page(xch, dest_dom, console_pfn);
+
+    if ( buffio_pfn )
+        xc_clear_domain_page(xch, dest_dom, buffio_pfn);
+
+    if ( io_pfn )
+        xc_clear_domain_page(xch, dest_dom, io_pfn);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_STORE_PFN,
+                     hvm_params[HVM_PARAM_STORE_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom,
+                     HVM_PARAM_CONSOLE_PFN,
+                     hvm_params[HVM_PARAM_CONSOLE_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_BUFIOREQ_PFN,
+                     hvm_params[HVM_PARAM_BUFIOREQ_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_IOREQ_PFN,
+                     hvm_params[HVM_PARAM_IOREQ_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_IDENT_PT,
+                     hvm_params[HVM_PARAM_IDENT_PT]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_PAGING_RING_PFN,
+                     hvm_params[HVM_PARAM_PAGING_RING_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_ACCESS_RING_PFN,
+                     hvm_params[HVM_PARAM_ACCESS_RING_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_VM86_TSS,
+                     hvm_params[HVM_PARAM_VM86_TSS]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_ACPI_IOPORTS_LOCATION,
+                     hvm_params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_VIRIDIAN,
+                     hvm_params[HVM_PARAM_VIRIDIAN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_PAE_ENABLED,
+                     hvm_params[HVM_PARAM_PAE_ENABLED]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_STORE_EVTCHN,
+                     hvm_params[HVM_PARAM_STORE_EVTCHN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_IOREQ_SERVER_PFN,
+                     hvm_params[HVM_PARAM_IOREQ_SERVER_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
+                     hvm_params[HVM_PARAM_NR_IOREQ_SERVER_PAGES]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
+                     hvm_params[HVM_PARAM_VM_GENERATION_ID_ADDR]);
+
+    if (xc_dom_gnttab_hvm_seed(xch, dest_dom, console_pfn, store_pfn,
+                               console_domid, store_domid))
+    {
+        PERROR("error seeding hvm grant table");
+        goto out;
+    }
+
+    rc = 0;
+out:
+    if (hvm_buf) free(hvm_buf);
+
+    if ( (rc != 0) && (dest_dom != 0) ) {
+            PERROR("Faled to perform soft reset, destroying domain %d",
+                   dest_dom);
+	    xc_domain_destroy(xch, dest_dom);
+    }
+
+    return !!rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
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 Dec 03 17:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXk-0004MB-Ra; Wed, 03 Dec 2014 17:16:48 +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 1XwDXj-0004L6-62
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	83/34-09842-E754F745; Wed, 03 Dec 2014 17:16:46 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417627004!13207479!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25880 invoked from network); 3 Dec 2014 17:16:45 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:16:45 -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 sB3HGdY1031514
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:39 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkS008593; Wed, 3 Dec 2014 12:16:36 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:17 +0100
Message-Id: <1417626981-8432-6-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 5/9] libxc: support XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 new xc_domain_devour() function to support XEN_DOMCTL_devour.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxc/include/xenctrl.h | 14 ++++++++++++++
 tools/libxc/xc_domain.c       | 13 +++++++++++++
 2 files changed, 27 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..a789de3 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -558,6 +558,20 @@ int xc_domain_unpause(xc_interface *xch,
 int xc_domain_destroy(xc_interface *xch,
                       uint32_t domid);
 
+/**
+ * This function sets a 'recipient' domain for a domain (when the source domain
+ * releases memory it is being reassigned to the recipient domain instead of
+ * being freed) and kills the original domain. The destination domain is supposed
+ * to have enough max_mem and no pages assigned.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the source domain id
+ * @parm recipient the destrination domain id
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_devour(xc_interface *xch,
+                     uint32_t domid, uint32_t recipient);
+
 
 /**
  * This function resumes a suspended domain. The domain should have
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index b864872..5949725 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -122,6 +122,19 @@ int xc_domain_destroy(xc_interface *xch,
     return ret;
 }
 
+int xc_domain_devour(xc_interface *xch, uint32_t domid, uint32_t recipient)
+{
+    int ret;
+    DECLARE_DOMCTL;
+    domctl.cmd = XEN_DOMCTL_devour;
+    domctl.domain = (domid_t)domid;
+    domctl.u.devour.recipient = (domid_t)recipient;
+    do {
+        ret = do_domctl(xch, &domctl);
+    } while ( ret && (errno == EAGAIN) );
+    return ret;
+}
+
 int xc_domain_shutdown(xc_interface *xch,
                        uint32_t domid,
                        int reason)
-- 
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 Dec 03 17:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXk-0004MB-Ra; Wed, 03 Dec 2014 17:16:48 +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 1XwDXj-0004L6-62
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	83/34-09842-E754F745; Wed, 03 Dec 2014 17:16:46 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417627004!13207479!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25880 invoked from network); 3 Dec 2014 17:16:45 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:16:45 -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 sB3HGdY1031514
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:39 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkS008593; Wed, 3 Dec 2014 12:16:36 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:17 +0100
Message-Id: <1417626981-8432-6-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 5/9] libxc: support XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 new xc_domain_devour() function to support XEN_DOMCTL_devour.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxc/include/xenctrl.h | 14 ++++++++++++++
 tools/libxc/xc_domain.c       | 13 +++++++++++++
 2 files changed, 27 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..a789de3 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -558,6 +558,20 @@ int xc_domain_unpause(xc_interface *xch,
 int xc_domain_destroy(xc_interface *xch,
                       uint32_t domid);
 
+/**
+ * This function sets a 'recipient' domain for a domain (when the source domain
+ * releases memory it is being reassigned to the recipient domain instead of
+ * being freed) and kills the original domain. The destination domain is supposed
+ * to have enough max_mem and no pages assigned.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the source domain id
+ * @parm recipient the destrination domain id
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_devour(xc_interface *xch,
+                     uint32_t domid, uint32_t recipient);
+
 
 /**
  * This function resumes a suspended domain. The domain should have
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index b864872..5949725 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -122,6 +122,19 @@ int xc_domain_destroy(xc_interface *xch,
     return ret;
 }
 
+int xc_domain_devour(xc_interface *xch, uint32_t domid, uint32_t recipient)
+{
+    int ret;
+    DECLARE_DOMCTL;
+    domctl.cmd = XEN_DOMCTL_devour;
+    domctl.domain = (domid_t)domid;
+    domctl.u.devour.recipient = (domid_t)recipient;
+    do {
+        ret = do_domctl(xch, &domctl);
+    } while ( ret && (errno == EAGAIN) );
+    return ret;
+}
+
 int xc_domain_shutdown(xc_interface *xch,
                        uint32_t domid,
                        int reason)
-- 
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 Dec 03 17:16:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXs-0004Q7-Vr; Wed, 03 Dec 2014 17:16:56 +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 1XwDXs-0004PX-0s
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BD/67-15461-7854F745; Wed, 03 Dec 2014 17:16:55 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417627012!5165150!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9848 invoked from network); 3 Dec 2014 17:16:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:16:54 -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 sB3HGlG2016756
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:48 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkV008593; Wed, 3 Dec 2014 12:16:45 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:20 +0100
Message-Id: <1417626981-8432-9-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 8/9] libxl: soft reset support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Perform soft reset when a domain did SHUTDOWN_soft_reset. Migrate the
content with xc_domain_soft_reset(), reload dm and toolstack.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxl/libxl.h          |   6 +++
 tools/libxl/libxl_create.c   | 103 +++++++++++++++++++++++++++++++++++++++----
 tools/libxl/libxl_internal.h |   4 ++
 tools/libxl/xl_cmdimpl.c     |  22 ++++++++-
 4 files changed, 124 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 41d6e8d..c802635 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -919,6 +919,12 @@ int static inline libxl_domain_create_restore_0x040200(
 
 #endif
 
+int libxl_domain_soft_reset(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            uint32_t *domid, uint32_t domid_old,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+
   /* A progress report will be made via ao_console_how, of type
    * domain_create_console_available, when the domain's primary
    * console is available and can be connected to.
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1198225..b1e809b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -25,6 +25,8 @@
 #include <xen/hvm/hvm_info_table.h>
 #include <xen/hvm/e820.h>
 
+#define INVALID_DOMID ~0
+
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                          libxl_domain_create_info *c_info)
 {
@@ -903,6 +905,9 @@ static void initiate_domain_create(libxl__egc *egc,
     if (restore_fd >= 0) {
         LOG(DEBUG, "restoring, not running bootloader");
         domcreate_bootloader_done(egc, &dcs->bl, 0);
+    } else if (dcs->domid_soft_reset != INVALID_DOMID) {
+        LOG(DEBUG, "soft reset, not running bootloader\n");
+        domcreate_bootloader_done(egc, &dcs->bl, 0);
     } else  {
         LOG(DEBUG, "running bootloader");
         dcs->bl.callback = domcreate_bootloader_done;
@@ -951,6 +956,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl_domain_config *const d_config = dcs->guest_config;
     libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
+    const uint32_t domid_soft_reset = dcs->domid_soft_reset;
     libxl__domain_build_state *const state = &dcs->build_state;
     libxl__srm_restore_autogen_callbacks *const callbacks =
         &dcs->shs.callbacks.restore.a;
@@ -974,7 +980,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->dmss.dm.callback = domcreate_devmodel_started;
     dcs->dmss.callback = domcreate_devmodel_started;
 
-    if ( restore_fd < 0 ) {
+    if ( (restore_fd < 0) && (domid_soft_reset == INVALID_DOMID) ) {
         rc = libxl__domain_build(gc, d_config, domid, state);
         domcreate_rebuild_done(egc, dcs, rc);
         return;
@@ -1004,14 +1010,74 @@ static void domcreate_bootloader_done(libxl__egc *egc,
         rc = ERROR_INVAL;
         goto out;
     }
-    libxl__xc_domain_restore(egc, dcs,
-                             hvm, pae, superpages);
+    if ( restore_fd >= 0 ) {
+        libxl__xc_domain_restore(egc, dcs,
+                                 hvm, pae, superpages);
+    } else {
+        libxl__xc_domain_soft_reset(egc, dcs);
+    }
+
     return;
 
  out:
     libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
 }
 
+void libxl__xc_domain_soft_reset(libxl__egc *egc,
+                                 libxl__domain_create_state *dcs)
+{
+    STATE_AO_GC(dcs->ao);
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    const uint32_t domid_soft_reset = dcs->domid_soft_reset;
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
+    uint8_t *buf;
+    uint32_t len;
+    uint32_t console_domid, store_domid;
+    unsigned long store_mfn, console_mfn;
+    int rc;
+    struct libxl__domain_suspend_state *dss;
+
+    GCNEW(dss);
+
+    dss->ao = ao;
+    dss->domid = domid_soft_reset;
+    dss->dm_savefile = GCSPRINTF("/var/lib/xen/qemu-save.%d",
+                                 domid_soft_reset);
+
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        rc = libxl__domain_suspend_device_model(gc, dss);
+        if (rc) goto out;
+    }
+
+    console_domid = dcs->build_state.console_domid;
+    store_domid = dcs->build_state.store_domid;
+
+    libxl__domain_soft_reset_destroy_old(ctx, domid_soft_reset, 0);
+
+    rc = xc_domain_soft_reset(ctx->xch, domid_soft_reset, domid, console_domid,
+                              &console_mfn, store_domid, &store_mfn);
+    if (rc) goto out;
+
+    libxl__qmp_cleanup(gc, domid_soft_reset);
+
+    dcs->build_state.store_mfn = store_mfn;
+    dcs->build_state.console_mfn = console_mfn;
+
+    rc = libxl__toolstack_save(domid_soft_reset, &buf, &len, dss);
+    if (rc) goto out;
+
+    rc = libxl__toolstack_restore(domid, buf, len, &dcs->shs);
+    if (rc) goto out;
+out:
+    /*
+     * Now pretend we did normal restore and simply call
+     * libxl__xc_domain_restore_done().
+     */
+    libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
+}
+
 void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
           unsigned long console_mfn, void *user)
 {
@@ -1037,6 +1103,7 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
 
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
+    const uint32_t domid_soft_reset = dcs->domid_soft_reset;
     libxl_domain_config *const d_config = dcs->guest_config;
     libxl_domain_build_info *const info = &d_config->b_info;
     libxl__domain_build_state *const state = &dcs->build_state;
@@ -1089,9 +1156,12 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
     if (ret)
         goto out;
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM && fd != -1) {
         state->saved_state = GCSPRINTF(
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
+    } else if (domid_soft_reset != INVALID_DOMID) {
+        state->saved_state = GCSPRINTF(
+                       "/var/lib/xen/qemu-save.%d", domid_soft_reset);
     }
 
 out:
@@ -1100,9 +1170,12 @@ out:
         libxl__file_reference_unmap(&state->pv_ramdisk);
     }
 
-    esave = errno;
-    libxl_fd_set_nonblock(ctx, fd, 0);
-    errno = esave;
+    if ( fd != -1 ) {
+        esave = errno;
+        libxl_fd_set_nonblock(ctx, fd, 0);
+        errno = esave;
+    }
+
     domcreate_rebuild_done(egc, dcs, ret);
 }
 
@@ -1495,6 +1568,7 @@ static void domain_create_cb(libxl__egc *egc,
 static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid,
                             int restore_fd, int checkpointed_stream,
+                            uint32_t domid_old,
                             const libxl_asyncop_how *ao_how,
                             const libxl_asyncprogress_how *aop_console_how)
 {
@@ -1507,6 +1581,7 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     libxl_domain_config_init(&cdcs->dcs.guest_config_saved);
     libxl_domain_config_copy(ctx, &cdcs->dcs.guest_config_saved, d_config);
     cdcs->dcs.restore_fd = restore_fd;
+    cdcs->dcs.domid_soft_reset = domid_old;
     cdcs->dcs.callback = domain_create_cb;
     cdcs->dcs.checkpointed_stream = checkpointed_stream;
     libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
@@ -1535,7 +1610,7 @@ int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             const libxl_asyncop_how *ao_how,
                             const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, domid, -1, 0,
+    return do_domain_create(ctx, d_config, domid, -1, 0, INVALID_DOMID,
                             ao_how, aop_console_how);
 }
 
@@ -1546,7 +1621,17 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 const libxl_asyncprogress_how *aop_console_how)
 {
     return do_domain_create(ctx, d_config, domid, restore_fd,
-                            params->checkpointed_stream, ao_how, aop_console_how);
+                            params->checkpointed_stream, INVALID_DOMID,
+                            ao_how, aop_console_how);
+}
+
+int libxl_domain_soft_reset(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            uint32_t *domid, uint32_t domid_old,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
+{
+    return do_domain_create(ctx, d_config, domid, -1, 0, domid_old,
+                            ao_how, aop_console_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f29ed83..e40bba1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3069,6 +3069,7 @@ struct libxl__domain_create_state {
     libxl_domain_config *guest_config;
     libxl_domain_config guest_config_saved; /* vanilla config */
     int restore_fd;
+    uint32_t domid_soft_reset;
     libxl__domain_create_cb *callback;
     libxl_asyncprogress_how aop_console_how;
     /* private to domain_create */
@@ -3123,6 +3124,9 @@ _hidden void libxl__xc_domain_restore(libxl__egc *egc,
  * If rc!=0, retval and errnoval are undefined. */
 _hidden void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
                                            int rc, int retval, int errnoval);
+/* calls libxl__xc_domain_restore_done when done */
+_hidden void libxl__xc_domain_soft_reset(libxl__egc *egc,
+                                         libxl__domain_create_state *dcs);
 
 /* Each time the dm needs to be saved, we must call suspend and then save */
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 53611dc..eb833f0 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2043,7 +2043,8 @@ static void reload_domain_config(uint32_t domid,
 }
 
 /* Returns 1 if domain should be restarted,
- * 2 if domain should be renamed then restarted, or 0
+ * 2 if domain should be renamed then restarted,
+ * 3 if domain performed soft reset, or 0
  * Can update r_domid if domain is destroyed etc */
 static int handle_domain_death(uint32_t *r_domid,
                                libxl_event *event,
@@ -2069,6 +2070,9 @@ static int handle_domain_death(uint32_t *r_domid,
     case LIBXL_SHUTDOWN_REASON_WATCHDOG:
         action = d_config->on_watchdog;
         break;
+    case LIBXL_SHUTDOWN_REASON_SOFT_RESET:
+        LOG("Domain performed soft reset.");
+        return 3;
     default:
         LOG("Unknown shutdown reason code %d. Destroying domain.",
             event->u.domain_shutdown.shutdown_reason);
@@ -2285,6 +2289,7 @@ static void evdisable_disk_ejects(libxl_evgen_disk_eject **diskws,
 static uint32_t create_domain(struct domain_create *dom_info)
 {
     uint32_t domid = INVALID_DOMID;
+    uint32_t domid_old = INVALID_DOMID;
 
     libxl_domain_config d_config;
 
@@ -2510,7 +2515,18 @@ start:
          * restore/migrate-receive it again.
          */
         restoring = 0;
-    }else{
+    } else if (domid_old != INVALID_DOMID) {
+        /* Do soft reset */
+        d_config.b_info.nodemap.size = 0;
+        ret = libxl_domain_soft_reset(ctx, &d_config,
+                                      &domid, domid_old,
+                                      0, 0);
+
+        if ( ret ) {
+            goto error_out;
+        }
+        domid_old = INVALID_DOMID;
+    } else {
         ret = libxl_domain_create_new(ctx, &d_config, &domid,
                                       0, autoconnect_console_how);
     }
@@ -2574,6 +2590,8 @@ start:
                 event->u.domain_shutdown.shutdown_reason,
                 event->u.domain_shutdown.shutdown_reason);
             switch (handle_domain_death(&domid, event, &d_config)) {
+            case 3:
+                domid_old = domid;
             case 2:
                 if (!preserve_domain(&domid, event, &d_config)) {
                     /* If we fail then exit leaving the old domain in place. */
-- 
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 Dec 03 17:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDXj-0004LQ-DT; Wed, 03 Dec 2014 17:16:47 +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 1XwDXh-0004Ku-Tz
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:46 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6F/37-15461-D754F745; Wed, 03 Dec 2014 17:16:45 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417627003!13168840!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26664 invoked from network); 3 Dec 2014 17:16:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:16:44 -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 sB3HGa6c023005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:37 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkR008593; Wed, 3 Dec 2014 12:16:34 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:16 +0100
Message-Id: <1417626981-8432-5-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

New operation sets the 'recipient' domain which will recieve all
memory pages from a particular domain and kills the original domain.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/domain.c         |  3 +++
 xen/common/domctl.c         | 33 +++++++++++++++++++++++++++++++++
 xen/common/page_alloc.c     | 28 ++++++++++++++++++++++++----
 xen/include/public/domctl.h | 15 +++++++++++++++
 xen/include/xen/sched.h     |  2 ++
 5 files changed, 77 insertions(+), 4 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index c13a7cf..f26267a 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -825,6 +825,9 @@ static void complete_domain_destroy(struct rcu_head *head)
     if ( d->target != NULL )
         put_domain(d->target);
 
+    if ( d->recipient != NULL )
+        put_domain(d->recipient);
+
     evtchn_destroy_final(d);
 
     radix_tree_destroy(&d->pirq_tree, free_pirq_struct);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index f15dcfe..7e7fb47 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1177,6 +1177,39 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_devour:
+    {
+        struct domain *recipient_dom;
+
+        if ( !d->recipient )
+        {
+            recipient_dom = get_domain_by_id(op->u.devour.recipient);
+            if ( recipient_dom == NULL )
+            {
+                ret = -ESRCH;
+                break;
+            }
+
+            if ( recipient_dom->tot_pages != 0 )
+            {
+                put_domain(recipient_dom);
+                ret = -EINVAL;
+                break;
+            }
+            /*
+             * Make sure no allocation/remapping is ongoing and set is_dying
+             * flag to prevent such actions in future.
+             */
+            spin_lock(&d->page_alloc_lock);
+            d->is_dying = DOMDYING_locked;
+            d->recipient = recipient_dom;
+            smp_wmb(); /* make sure recipient was set before domain_kill() */
+            spin_unlock(&d->page_alloc_lock);
+        }
+        ret = domain_kill(d);
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 7b4092d..7eb4404 100644
--- 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,13 +1765,32 @@ 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);
+            if ( assign_pages(d->recipient, pg, order, 0) )
+                /* assign_pages reports the error by itself */
+                goto out;
+
+            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
+                printk(XENLOG_G_INFO
+                       "Failed to add MFN %lx (GFN %lx) to Dom%d's physmap\n",
+                       mfn, gmfn, d->recipient->domain_id);
+        }
     }
 
+out:
     if ( drop_dom_ref )
         put_domain(d);
 }
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 57e2ed7..871fa5e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -995,6 +995,19 @@ struct xen_domctl_psr_cmt_op {
 typedef struct xen_domctl_psr_cmt_op xen_domctl_psr_cmt_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cmt_op_t);
 
+/*
+ * XEN_DOMCTL_devour - kills the domain reassigning all of its domheap pages
+ * to the 'recipient' domain. Pages from xen heap belonging to the domain
+ * are not copied. Reassigned pages are mapped to the same GMFNs in the
+ * recipient domain as they were mapped in the original. The recipient domain
+ * is supposed to not have any domheap pages to avoid MFN-GMFN collisions.
+ */
+struct xen_domctl_devour {
+    domid_t recipient;
+};
+typedef struct xen_domctl_devour xen_domctl_devour_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_devour_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -1070,6 +1083,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_setvnumainfo                  74
 #define XEN_DOMCTL_psr_cmt_op                    75
 #define XEN_DOMCTL_arm_configure_domain          76
+#define XEN_DOMCTL_devour                        77
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1135,6 +1149,7 @@ struct xen_domctl {
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         struct xen_domctl_vnuma             vnuma;
         struct xen_domctl_psr_cmt_op        psr_cmt_op;
+        struct xen_domctl_devour            devour;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index a42d0b8..552e4a3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -366,6 +366,8 @@ struct domain
     bool_t           is_privileged;
     /* Which guest this guest has privileges on */
     struct domain   *target;
+    /* Which guest receives freed memory pages */
+    struct domain   *recipient;
     /* Is this guest being debugged by dom0? */
     bool_t           debugger_attached;
     /* Is this guest dying (i.e., a zombie)? */
-- 
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 Dec 03 17:17:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17: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 1XwDXy-0004U8-1f; Wed, 03 Dec 2014 17:17:02 +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 1XwDXv-0004RB-Du
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:59 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	CF/D7-22737-A854F745; Wed, 03 Dec 2014 17:16:58 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417627016!11339433!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31762 invoked from network); 3 Dec 2014 17:16:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:16:57 -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 sB3HGo9F031595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:50 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkW008593; Wed, 3 Dec 2014 12:16:48 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:21 +0100
Message-Id: <1417626981-8432-10-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 9/9] xsm: add XEN_DOMCTL_devour support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/domctl.c                 |  6 ++++++
 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 ++++++++++
 6 files changed, 46 insertions(+)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 7e7fb47..7c22e35 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1190,6 +1190,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                 break;
             }
 
+            ret = xsm_devour(XSM_HOOK, d, recipient_dom);
+            if ( ret ) {
+                put_domain(recipient_dom);
+                break;
+            }
+
             if ( recipient_dom->tot_pages != 0 )
             {
                 put_domain(recipient_dom);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f20e89c..6e9e38b 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -113,6 +113,12 @@ static XSM_INLINE int xsm_set_target(XSM_DEFAULT_ARG struct domain *d, struct do
     return xsm_default_action(action, current->domain, NULL);
 }
 
+static XSM_INLINE int xsm_devour(XSM_DEFAULT_ARG struct domain *d, struct domain *e)
+{
+    XSM_ASSERT_ACTION(XSM_HOOK);
+    return xsm_default_action(action, current->domain, NULL);
+}
+
 static XSM_INLINE int xsm_domctl(XSM_DEFAULT_ARG struct domain *d, int cmd)
 {
     XSM_ASSERT_ACTION(XSM_OTHER);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4ce089f..7db7433 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -58,6 +58,7 @@ struct xsm_operations {
     int (*domctl_scheduler_op) (struct domain *d, int op);
     int (*sysctl_scheduler_op) (int op);
     int (*set_target) (struct domain *d, struct domain *e);
+    int (*devour) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
     int (*sysctl) (int cmd);
     int (*readconsole) (uint32_t clear);
@@ -213,6 +214,11 @@ static inline int xsm_set_target (xsm_default_t def, struct domain *d, struct do
     return xsm_ops->set_target(d, e);
 }
 
+static inline int xsm_devour (xsm_default_t def, struct domain *d, struct domain *r)
+{
+    return xsm_ops->devour(d, r);
+}
+
 static inline int xsm_domctl (xsm_default_t def, struct domain *d, int cmd)
 {
     return xsm_ops->domctl(d, cmd);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 8eb3050..f3c2f9e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -35,6 +35,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domctl_scheduler_op);
     set_to_dummy_if_null(ops, sysctl_scheduler_op);
     set_to_dummy_if_null(ops, set_target);
+    set_to_dummy_if_null(ops, devour);
     set_to_dummy_if_null(ops, domctl);
     set_to_dummy_if_null(ops, sysctl);
     set_to_dummy_if_null(ops, readconsole);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d48463f..097c8c2 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -565,6 +565,21 @@ static int flask_set_target(struct domain *d, struct domain *t)
     return rc;
 }
 
+static int flask_devour(struct domain *d, struct domain *r)
+{
+    int rc;
+    struct domain_security_struct *dsec, *rsec;
+    dsec = d->ssid;
+    rsec = r->ssid;
+
+    rc = current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_SOURCE);
+    if ( rc )
+        return rc;
+    if ( r )
+        rc = current_has_perm(r, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_RECIPIENT);
+    return rc;
+}
+
 static int flask_domctl(struct domain *d, int cmd)
 {
     switch ( cmd )
@@ -580,6 +595,7 @@ static int flask_domctl(struct domain *d, int cmd)
 #ifdef HAS_MEM_ACCESS
     case XEN_DOMCTL_mem_event_op:
 #endif
+    case XEN_DOMCTL_devour:
 #ifdef CONFIG_X86
     /* These have individual XSM hooks (arch/x86/domctl.c) */
     case XEN_DOMCTL_shadow_op:
@@ -1512,6 +1528,7 @@ static struct xsm_operations flask_ops = {
     .domctl_scheduler_op = flask_domctl_scheduler_op,
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
     .set_target = flask_set_target,
+    .devour = flask_devour,
     .domctl = flask_domctl,
     .sysctl = flask_sysctl,
     .readconsole = flask_readconsole,
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 1da9f63..64c3424 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -142,6 +142,8 @@ class domain
 #  target = the new target domain
 # see also the domain2 make_priv_for and set_as_target checks
     set_target
+# XEN_DOMCTL_devour
+    devour
 # SCHEDOP_remote_shutdown
     shutdown
 # XEN_DOMCTL_set{,_machine}_address_size
@@ -196,6 +198,14 @@ class domain2
 #  source = the domain making the hypercall
 #  target = the new target domain
     set_as_target
+# checked in XEN_DOMCTL_devour:
+#  source = the domain making the hypercall
+#  target = the new source domain
+    set_as_source
+# checked in XEN_DOMCTL_devour:
+#  source = the domain making the hypercall
+#  target = the new recipient domain
+    set_as_recipient
 # XEN_DOMCTL_set_cpuid
     set_cpuid
 # XEN_DOMCTL_gettscinfo
-- 
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 Dec 03 17:17:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17: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 1XwDXy-0004U8-1f; Wed, 03 Dec 2014 17:17:02 +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 1XwDXv-0004RB-Du
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:16:59 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	CF/D7-22737-A854F745; Wed, 03 Dec 2014 17:16:58 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417627016!11339433!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31762 invoked from network); 3 Dec 2014 17:16:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:16:57 -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 sB3HGo9F031595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:50 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkW008593; Wed, 3 Dec 2014 12:16:48 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:21 +0100
Message-Id: <1417626981-8432-10-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 9/9] xsm: add XEN_DOMCTL_devour support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/domctl.c                 |  6 ++++++
 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 ++++++++++
 6 files changed, 46 insertions(+)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 7e7fb47..7c22e35 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1190,6 +1190,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                 break;
             }
 
+            ret = xsm_devour(XSM_HOOK, d, recipient_dom);
+            if ( ret ) {
+                put_domain(recipient_dom);
+                break;
+            }
+
             if ( recipient_dom->tot_pages != 0 )
             {
                 put_domain(recipient_dom);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f20e89c..6e9e38b 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -113,6 +113,12 @@ static XSM_INLINE int xsm_set_target(XSM_DEFAULT_ARG struct domain *d, struct do
     return xsm_default_action(action, current->domain, NULL);
 }
 
+static XSM_INLINE int xsm_devour(XSM_DEFAULT_ARG struct domain *d, struct domain *e)
+{
+    XSM_ASSERT_ACTION(XSM_HOOK);
+    return xsm_default_action(action, current->domain, NULL);
+}
+
 static XSM_INLINE int xsm_domctl(XSM_DEFAULT_ARG struct domain *d, int cmd)
 {
     XSM_ASSERT_ACTION(XSM_OTHER);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4ce089f..7db7433 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -58,6 +58,7 @@ struct xsm_operations {
     int (*domctl_scheduler_op) (struct domain *d, int op);
     int (*sysctl_scheduler_op) (int op);
     int (*set_target) (struct domain *d, struct domain *e);
+    int (*devour) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
     int (*sysctl) (int cmd);
     int (*readconsole) (uint32_t clear);
@@ -213,6 +214,11 @@ static inline int xsm_set_target (xsm_default_t def, struct domain *d, struct do
     return xsm_ops->set_target(d, e);
 }
 
+static inline int xsm_devour (xsm_default_t def, struct domain *d, struct domain *r)
+{
+    return xsm_ops->devour(d, r);
+}
+
 static inline int xsm_domctl (xsm_default_t def, struct domain *d, int cmd)
 {
     return xsm_ops->domctl(d, cmd);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 8eb3050..f3c2f9e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -35,6 +35,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domctl_scheduler_op);
     set_to_dummy_if_null(ops, sysctl_scheduler_op);
     set_to_dummy_if_null(ops, set_target);
+    set_to_dummy_if_null(ops, devour);
     set_to_dummy_if_null(ops, domctl);
     set_to_dummy_if_null(ops, sysctl);
     set_to_dummy_if_null(ops, readconsole);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d48463f..097c8c2 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -565,6 +565,21 @@ static int flask_set_target(struct domain *d, struct domain *t)
     return rc;
 }
 
+static int flask_devour(struct domain *d, struct domain *r)
+{
+    int rc;
+    struct domain_security_struct *dsec, *rsec;
+    dsec = d->ssid;
+    rsec = r->ssid;
+
+    rc = current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_SOURCE);
+    if ( rc )
+        return rc;
+    if ( r )
+        rc = current_has_perm(r, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_RECIPIENT);
+    return rc;
+}
+
 static int flask_domctl(struct domain *d, int cmd)
 {
     switch ( cmd )
@@ -580,6 +595,7 @@ static int flask_domctl(struct domain *d, int cmd)
 #ifdef HAS_MEM_ACCESS
     case XEN_DOMCTL_mem_event_op:
 #endif
+    case XEN_DOMCTL_devour:
 #ifdef CONFIG_X86
     /* These have individual XSM hooks (arch/x86/domctl.c) */
     case XEN_DOMCTL_shadow_op:
@@ -1512,6 +1528,7 @@ static struct xsm_operations flask_ops = {
     .domctl_scheduler_op = flask_domctl_scheduler_op,
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
     .set_target = flask_set_target,
+    .devour = flask_devour,
     .domctl = flask_domctl,
     .sysctl = flask_sysctl,
     .readconsole = flask_readconsole,
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 1da9f63..64c3424 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -142,6 +142,8 @@ class domain
 #  target = the new target domain
 # see also the domain2 make_priv_for and set_as_target checks
     set_target
+# XEN_DOMCTL_devour
+    devour
 # SCHEDOP_remote_shutdown
     shutdown
 # XEN_DOMCTL_set{,_machine}_address_size
@@ -196,6 +198,14 @@ class domain2
 #  source = the domain making the hypercall
 #  target = the new target domain
     set_as_target
+# checked in XEN_DOMCTL_devour:
+#  source = the domain making the hypercall
+#  target = the new source domain
+    set_as_source
+# checked in XEN_DOMCTL_devour:
+#  source = the domain making the hypercall
+#  target = the new recipient domain
+    set_as_recipient
 # XEN_DOMCTL_set_cpuid
     set_cpuid
 # XEN_DOMCTL_gettscinfo
-- 
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 Dec 03 17:30:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:30:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDkW-0005YD-Ru; Wed, 03 Dec 2014 17:30: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 1XwDkW-0005Y8-4T
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:30:00 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	AF/1D-22737-7984F745; Wed, 03 Dec 2014 17:29:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417627797!3777232!1
X-Originating-IP: [66.165.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 18699 invoked from network); 3 Dec 2014 17:29:58 -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;
	3 Dec 2014 17:29:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="199152471"
Received: from ukmail1.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, 3 Dec 2014 12:08:38 -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 1XwDPq-0007wk-Gk;
	Wed, 03 Dec 2014 17:08:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwDPq-00028C-68;
	Wed, 03 Dec 2014 17:08:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21631.17301.870199.992160@mariner.uk.xensource.com>
Date: Wed, 3 Dec 2014 17:08:37 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	<russell.pavlicek@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: [Xen-devel] 4.5.0-rc3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 has tagged 4.5.0-rc3.

The tag has been pushed to xen.git, along with the force push of the
qemu tag to master.  I have merged the result into staging.  The
tarball is in the expected place.

Thanks, Konrad.

Ian.

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 17:30:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:30:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDkW-0005YD-Ru; Wed, 03 Dec 2014 17:30: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 1XwDkW-0005Y8-4T
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:30:00 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	AF/1D-22737-7984F745; Wed, 03 Dec 2014 17:29:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417627797!3777232!1
X-Originating-IP: [66.165.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 18699 invoked from network); 3 Dec 2014 17:29:58 -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;
	3 Dec 2014 17:29:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="199152471"
Received: from ukmail1.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, 3 Dec 2014 12:08:38 -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 1XwDPq-0007wk-Gk;
	Wed, 03 Dec 2014 17:08:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwDPq-00028C-68;
	Wed, 03 Dec 2014 17:08:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21631.17301.870199.992160@mariner.uk.xensource.com>
Date: Wed, 3 Dec 2014 17:08:37 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	<russell.pavlicek@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: [Xen-devel] 4.5.0-rc3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 has tagged 4.5.0-rc3.

The tag has been pushed to xen.git, along with the force push of the
qemu tag to master.  I have merged the result into staging.  The
tarball is in the expected place.

Thanks, Konrad.

Ian.

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 17:31:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:31:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDm8-0005dK-Ak; Wed, 03 Dec 2014 17:31:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XwDm6-0005dC-Us
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 17:31:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	58/39-15461-AF84F745; Wed, 03 Dec 2014 17:31:38 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417627895!12856457!1
X-Originating-IP: [66.165.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 7871 invoked from network); 3 Dec 2014 17:31: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;
	3 Dec 2014 17:31:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="199505722"
Received: from ukmail1.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, 3 Dec 2014 12:31:35 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XwDm2-0008R7-SB;
	Wed, 03 Dec 2014 17:31:34 +0000
Date: Wed, 3 Dec 2014 17:31:22 +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: <547DDA5C.8080803@terremark.com>
Message-ID: <alpine.DEB.2.02.1412031728290.30971@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.com>
	<alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
	<547DD3E5.9090303@terremark.com> <547DDA5C.8080803@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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: Re: [Xen-devel] [PATCH v2 for-4.6] 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

On Tue, 2 Dec 2014, Don Slutz wrote:
> On 12/02/14 09:59, Don Slutz wrote:
> > On 12/02/14 09:26, Stefano Stabellini wrote:
> > > On Tue, 2 Dec 2014, Don Slutz wrote:
> > > > On 12/02/14 06:53, Stefano Stabellini wrote:
> > > > > 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>
> > > > > 
> > > > > ---
> > > > > 
> > > > > Changes in v2:
> > > > > - call libxl_domain_info instead of libxl_dominfo_init;
> > > > > - call libxl_domain_info before retry_transaction.
> > > > > 
> > > > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > > > index de23fec..569a32a 100644
> > > > > --- a/tools/libxl/libxl.c
> > > > > +++ b/tools/libxl/libxl.c
> > > > > @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx,
> > > > > uint32_t
> > > > > domid,
> > > > >        char *uuid;
> > > > >        xs_transaction_t t;
> > > > >    +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
> > > > > +        goto out_no_transaction;
> > > > > +
> > > > >    retry_transaction:
> > > > >        t = xs_transaction_start(ctx->xsh);
> > > > >    @@ -4767,10 +4770,9 @@ 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);
> > > > > +    if (enforce && new_target_memkb > 0) {
> > > > > +        memorykb = ptr.max_memkb - current_target_memkb +
> > > > > new_target_memkb;
> 
> My testing shows that this should be:
> 
>         memorykb = ptr.max_memkb - (current_target_memkb + videoram) +
>             new_target_memkb;
> 
> As far as I can tell the reason for this is that memory/target (aka
> current_target_memkb) was set based on:
> 
>     new_target_memkb -= videoram;

Thank you very much for testing and the suggestion!

I think that the right fix for this is to remove videoram from
new_target_memkb earlier and only when the new target is absolute,
otherwise we risk removing videoram twice (in case the new target is
relative). I wonder why we didn't notice this before.


diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d5d5204..4803cc4 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4744,13 +4744,17 @@ retry_transaction:
         goto out;
     }
 
+    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
+                "%s/memory/videoram", dompath));
+    videoram = videoram_s ? atoi(videoram_s) : 0;
+
     if (relative) {
         if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
             new_target_memkb = 0;
         else
             new_target_memkb = current_target_memkb + target_memkb;
     } else
-        new_target_memkb = target_memkb;
+        new_target_memkb = target_memkb - videoram;
     if (new_target_memkb > memorykb) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "memory_dynamic_max must be less than or equal to"
@@ -4766,9 +4770,6 @@ retry_transaction:
         abort_transaction = 1;
         goto out;
     }
-    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
-                "%s/memory/videoram", dompath));
-    videoram = videoram_s ? atoi(videoram_s) : 0;
 
     if (enforce && new_target_memkb > 0) {
         memorykb = ptr.max_memkb - current_target_memkb + new_target_memkb;
@@ -4782,7 +4783,6 @@ retry_transaction:
         }
     }
 
-    new_target_memkb -= videoram;
     rc = xc_domain_set_pod_target(ctx->xch, domid,
             new_target_memkb / 4, NULL, NULL, NULL);
     if (rc != 0) {

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 17:31:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:31:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDm8-0005dK-Ak; Wed, 03 Dec 2014 17:31:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XwDm6-0005dC-Us
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 17:31:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	58/39-15461-AF84F745; Wed, 03 Dec 2014 17:31:38 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417627895!12856457!1
X-Originating-IP: [66.165.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 7871 invoked from network); 3 Dec 2014 17:31: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;
	3 Dec 2014 17:31:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="199505722"
Received: from ukmail1.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, 3 Dec 2014 12:31:35 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1XwDm2-0008R7-SB;
	Wed, 03 Dec 2014 17:31:34 +0000
Date: Wed, 3 Dec 2014 17:31:22 +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: <547DDA5C.8080803@terremark.com>
Message-ID: <alpine.DEB.2.02.1412031728290.30971@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.com>
	<alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
	<547DD3E5.9090303@terremark.com> <547DDA5C.8080803@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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: Re: [Xen-devel] [PATCH v2 for-4.6] 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

On Tue, 2 Dec 2014, Don Slutz wrote:
> On 12/02/14 09:59, Don Slutz wrote:
> > On 12/02/14 09:26, Stefano Stabellini wrote:
> > > On Tue, 2 Dec 2014, Don Slutz wrote:
> > > > On 12/02/14 06:53, Stefano Stabellini wrote:
> > > > > 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>
> > > > > 
> > > > > ---
> > > > > 
> > > > > Changes in v2:
> > > > > - call libxl_domain_info instead of libxl_dominfo_init;
> > > > > - call libxl_domain_info before retry_transaction.
> > > > > 
> > > > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > > > index de23fec..569a32a 100644
> > > > > --- a/tools/libxl/libxl.c
> > > > > +++ b/tools/libxl/libxl.c
> > > > > @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx,
> > > > > uint32_t
> > > > > domid,
> > > > >        char *uuid;
> > > > >        xs_transaction_t t;
> > > > >    +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
> > > > > +        goto out_no_transaction;
> > > > > +
> > > > >    retry_transaction:
> > > > >        t = xs_transaction_start(ctx->xsh);
> > > > >    @@ -4767,10 +4770,9 @@ 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);
> > > > > +    if (enforce && new_target_memkb > 0) {
> > > > > +        memorykb = ptr.max_memkb - current_target_memkb +
> > > > > new_target_memkb;
> 
> My testing shows that this should be:
> 
>         memorykb = ptr.max_memkb - (current_target_memkb + videoram) +
>             new_target_memkb;
> 
> As far as I can tell the reason for this is that memory/target (aka
> current_target_memkb) was set based on:
> 
>     new_target_memkb -= videoram;

Thank you very much for testing and the suggestion!

I think that the right fix for this is to remove videoram from
new_target_memkb earlier and only when the new target is absolute,
otherwise we risk removing videoram twice (in case the new target is
relative). I wonder why we didn't notice this before.


diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d5d5204..4803cc4 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4744,13 +4744,17 @@ retry_transaction:
         goto out;
     }
 
+    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
+                "%s/memory/videoram", dompath));
+    videoram = videoram_s ? atoi(videoram_s) : 0;
+
     if (relative) {
         if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
             new_target_memkb = 0;
         else
             new_target_memkb = current_target_memkb + target_memkb;
     } else
-        new_target_memkb = target_memkb;
+        new_target_memkb = target_memkb - videoram;
     if (new_target_memkb > memorykb) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "memory_dynamic_max must be less than or equal to"
@@ -4766,9 +4770,6 @@ retry_transaction:
         abort_transaction = 1;
         goto out;
     }
-    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
-                "%s/memory/videoram", dompath));
-    videoram = videoram_s ? atoi(videoram_s) : 0;
 
     if (enforce && new_target_memkb > 0) {
         memorykb = ptr.max_memkb - current_target_memkb + new_target_memkb;
@@ -4782,7 +4783,6 @@ retry_transaction:
         }
     }
 
-    new_target_memkb -= videoram;
     rc = xc_domain_set_pod_target(ctx->xch, domid,
             new_target_memkb / 4, NULL, NULL, NULL);
     if (rc != 0) {

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 17:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDzv-00063G-OQ; Wed, 03 Dec 2014 17:45:55 +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 1XwDzu-000637-Gw
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:45:54 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	06/19-25276-15C4F745; Wed, 03 Dec 2014 17:45:53 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417628751!5901510!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15320 invoked from network); 3 Dec 2014 17:45:53 -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 Dec 2014 17:45:53 -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 sB3Hjg1H010887
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:45:43 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkP008593; Wed, 3 Dec 2014 12:16:28 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:14 +0100
Message-Id: <1417626981-8432-3-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 2/9] xen: introduce SHUTDOWN_soft_reset
	shutdown reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/shutdown.c      | 7 +++++++
 xen/include/public/sched.h | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index 94d4c53..5c3a158 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -71,6 +71,13 @@ void hwdom_shutdown(u8 reason)
         break; /* not reached */
     }
 
+    case SHUTDOWN_soft_reset:
+    {
+        printk("Domain 0 did soft reset but it is unsupported, rebooting.\n");
+        machine_restart(0);
+        break; /* not reached */
+    }
+
     default:
     {
         printk("Domain 0 shutdown (unknown reason %u): ", reason);
diff --git a/xen/include/public/sched.h b/xen/include/public/sched.h
index 4000ac9..800c808 100644
--- a/xen/include/public/sched.h
+++ b/xen/include/public/sched.h
@@ -159,7 +159,8 @@ DEFINE_XEN_GUEST_HANDLE(sched_watchdog_t);
 #define SHUTDOWN_suspend    2  /* Clean up, save suspend info, kill.         */
 #define SHUTDOWN_crash      3  /* Tell controller we've crashed.             */
 #define SHUTDOWN_watchdog   4  /* Restart because watchdog time expired.     */
-#define SHUTDOWN_MAX        4  /* Maximum valid shutdown reason.             */
+#define SHUTDOWN_soft_reset 5  /* Soft reset, rebuild keeping memory content */
+#define SHUTDOWN_MAX        5  /* Maximum valid shutdown reason.             */
 /* ` } */
 
 #endif /* __XEN_PUBLIC_SCHED_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 Wed Dec 03 17:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwE02-00063h-9i; Wed, 03 Dec 2014 17:46:02 +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 1XwE00-00063W-LC
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:46:00 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	BF/E2-03145-75C4F745; Wed, 03 Dec 2014 17:45:59 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417628756!12705237!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31652 invoked from network); 3 Dec 2014 17:45:58 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:45: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 sB3HGgT5029919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:42 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkT008593; Wed, 3 Dec 2014 12:16:39 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:18 +0100
Message-Id: <1417626981-8432-7-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 6/9] libxl: add
	libxl__domain_soft_reset_destroy_old()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

New libxl__domain_soft_reset_destroy_old() is an internal-only
version of libxl_domain_destroy() which follows the same domain
destroy path with the only difference: xc_domain_destroy() is
being avoided so the domain is not actually being destroyed.

Add soft_reset flag to libxl__domain_destroy_state structure
to support the change.

The original libxl_domain_destroy() function could be easily
modified to support new flag but I'm trying to avoid that as
it is part of public API.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxl/libxl.c          | 32 +++++++++++++++++++++++++++-----
 tools/libxl/libxl_internal.h |  4 ++++
 2 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f84f7c2..c2bd730 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1437,6 +1437,23 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
     return AO_INPROGRESS;
 }
 
+int libxl__domain_soft_reset_destroy_old(libxl_ctx *ctx, uint32_t domid,
+                                         const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__domain_destroy_state *dds;
+
+    GCNEW(dds);
+    dds->ao = ao;
+    dds->domid = domid;
+    dds->callback = domain_destroy_cb;
+    dds->soft_reset = 1;
+    libxl__domain_destroy(egc, dds);
+
+    return AO_INPROGRESS;
+}
+
+
 static void domain_destroy_cb(libxl__egc *egc, libxl__domain_destroy_state *dds,
                               int rc)
 {
@@ -1612,6 +1629,7 @@ static void devices_destroy_cb(libxl__egc *egc,
 {
     STATE_AO_GC(drs->ao);
     libxl__destroy_domid_state *dis = CONTAINER_OF(drs, *dis, drs);
+    libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, domain);
     libxl_ctx *ctx = CTX;
     uint32_t domid = dis->domid;
     char *dom_path;
@@ -1650,11 +1668,15 @@ static void devices_destroy_cb(libxl__egc *egc,
     }
     libxl__userdata_destroyall(gc, domid);
 
-    rc = xc_domain_destroy(ctx->xch, domid);
-    if (rc < 0) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_destroy failed for %d", domid);
-        rc = ERROR_FAIL;
-        goto out;
+    if (!dds->soft_reset)
+    {
+        rc = xc_domain_destroy(ctx->xch, domid);
+        if (rc < 0) {
+            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
+                                "xc_domain_destroy failed for %d", domid);
+            rc = ERROR_FAIL;
+            goto out;
+        }
     }
     rc = 0;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a38f695..f29ed83 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2969,6 +2969,7 @@ struct libxl__domain_destroy_state {
     int stubdom_finished;
     libxl__destroy_domid_state domain;
     int domain_finished;
+    int soft_reset;
 };
 
 /*
@@ -3132,6 +3133,9 @@ _hidden void libxl__domain_save_device_model(libxl__egc *egc,
 
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 
+_hidden int libxl__domain_soft_reset_destroy_old(libxl_ctx *ctx, uint32_t domid,
+                                                 const libxl_asyncop_how *ao_how);
+
 
 /*
  * Convenience macros.
-- 
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 Dec 03 17:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwDzv-00063G-OQ; Wed, 03 Dec 2014 17:45:55 +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 1XwDzu-000637-Gw
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:45:54 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	06/19-25276-15C4F745; Wed, 03 Dec 2014 17:45:53 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417628751!5901510!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15320 invoked from network); 3 Dec 2014 17:45:53 -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 Dec 2014 17:45:53 -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 sB3Hjg1H010887
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:45:43 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkP008593; Wed, 3 Dec 2014 12:16:28 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:14 +0100
Message-Id: <1417626981-8432-3-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 2/9] xen: introduce SHUTDOWN_soft_reset
	shutdown reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/shutdown.c      | 7 +++++++
 xen/include/public/sched.h | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index 94d4c53..5c3a158 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -71,6 +71,13 @@ void hwdom_shutdown(u8 reason)
         break; /* not reached */
     }
 
+    case SHUTDOWN_soft_reset:
+    {
+        printk("Domain 0 did soft reset but it is unsupported, rebooting.\n");
+        machine_restart(0);
+        break; /* not reached */
+    }
+
     default:
     {
         printk("Domain 0 shutdown (unknown reason %u): ", reason);
diff --git a/xen/include/public/sched.h b/xen/include/public/sched.h
index 4000ac9..800c808 100644
--- a/xen/include/public/sched.h
+++ b/xen/include/public/sched.h
@@ -159,7 +159,8 @@ DEFINE_XEN_GUEST_HANDLE(sched_watchdog_t);
 #define SHUTDOWN_suspend    2  /* Clean up, save suspend info, kill.         */
 #define SHUTDOWN_crash      3  /* Tell controller we've crashed.             */
 #define SHUTDOWN_watchdog   4  /* Restart because watchdog time expired.     */
-#define SHUTDOWN_MAX        4  /* Maximum valid shutdown reason.             */
+#define SHUTDOWN_soft_reset 5  /* Soft reset, rebuild keeping memory content */
+#define SHUTDOWN_MAX        5  /* Maximum valid shutdown reason.             */
 /* ` } */
 
 #endif /* __XEN_PUBLIC_SCHED_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 Wed Dec 03 17:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 17:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwE02-00063h-9i; Wed, 03 Dec 2014 17:46:02 +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 1XwE00-00063W-LC
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 17:46:00 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	BF/E2-03145-75C4F745; Wed, 03 Dec 2014 17:45:59 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417628756!12705237!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31652 invoked from network); 3 Dec 2014 17:45:58 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 17:45: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 sB3HGgT5029919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Wed, 3 Dec 2014 12:16:42 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB3HGMkT008593; Wed, 3 Dec 2014 12:16:39 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Wed,  3 Dec 2014 18:16:18 +0100
Message-Id: <1417626981-8432-7-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v4 6/9] libxl: add
	libxl__domain_soft_reset_destroy_old()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

New libxl__domain_soft_reset_destroy_old() is an internal-only
version of libxl_domain_destroy() which follows the same domain
destroy path with the only difference: xc_domain_destroy() is
being avoided so the domain is not actually being destroyed.

Add soft_reset flag to libxl__domain_destroy_state structure
to support the change.

The original libxl_domain_destroy() function could be easily
modified to support new flag but I'm trying to avoid that as
it is part of public API.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxl/libxl.c          | 32 +++++++++++++++++++++++++++-----
 tools/libxl/libxl_internal.h |  4 ++++
 2 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f84f7c2..c2bd730 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1437,6 +1437,23 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
     return AO_INPROGRESS;
 }
 
+int libxl__domain_soft_reset_destroy_old(libxl_ctx *ctx, uint32_t domid,
+                                         const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__domain_destroy_state *dds;
+
+    GCNEW(dds);
+    dds->ao = ao;
+    dds->domid = domid;
+    dds->callback = domain_destroy_cb;
+    dds->soft_reset = 1;
+    libxl__domain_destroy(egc, dds);
+
+    return AO_INPROGRESS;
+}
+
+
 static void domain_destroy_cb(libxl__egc *egc, libxl__domain_destroy_state *dds,
                               int rc)
 {
@@ -1612,6 +1629,7 @@ static void devices_destroy_cb(libxl__egc *egc,
 {
     STATE_AO_GC(drs->ao);
     libxl__destroy_domid_state *dis = CONTAINER_OF(drs, *dis, drs);
+    libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, domain);
     libxl_ctx *ctx = CTX;
     uint32_t domid = dis->domid;
     char *dom_path;
@@ -1650,11 +1668,15 @@ static void devices_destroy_cb(libxl__egc *egc,
     }
     libxl__userdata_destroyall(gc, domid);
 
-    rc = xc_domain_destroy(ctx->xch, domid);
-    if (rc < 0) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_destroy failed for %d", domid);
-        rc = ERROR_FAIL;
-        goto out;
+    if (!dds->soft_reset)
+    {
+        rc = xc_domain_destroy(ctx->xch, domid);
+        if (rc < 0) {
+            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
+                                "xc_domain_destroy failed for %d", domid);
+            rc = ERROR_FAIL;
+            goto out;
+        }
     }
     rc = 0;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a38f695..f29ed83 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2969,6 +2969,7 @@ struct libxl__domain_destroy_state {
     int stubdom_finished;
     libxl__destroy_domid_state domain;
     int domain_finished;
+    int soft_reset;
 };
 
 /*
@@ -3132,6 +3133,9 @@ _hidden void libxl__domain_save_device_model(libxl__egc *egc,
 
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 
+_hidden int libxl__domain_soft_reset_destroy_old(libxl_ctx *ctx, uint32_t domid,
+                                                 const libxl_asyncop_how *ao_how);
+
 
 /*
  * Convenience macros.
-- 
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 Dec 03 18:08:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 18:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwELG-0006pa-Bm; Wed, 03 Dec 2014 18:07:58 +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 1XwELE-0006pV-DV
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 18:07:56 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	AA/1B-07724-B715F745; Wed, 03 Dec 2014 18:07:55 +0000
X-Env-Sender: donald.d.dugger@intel.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417630073!10889276!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21603 invoked from network); 3 Dec 2014 18:07:54 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-31.messagelabs.com with SMTP;
	3 Dec 2014 18:07:54 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga101.jf.intel.com with ESMTP; 03 Dec 2014 09:14:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="492992511"
Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129])
	by orsmga003.jf.intel.com with ESMTP; 03 Dec 2014 09:10:47 -0800
Received: from orsmsx158.amr.corp.intel.com (10.22.240.20) by
	ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 3 Dec 2014 09:14:04 -0800
Received: from orsmsx114.amr.corp.intel.com ([169.254.8.127]) by
	ORSMSX158.amr.corp.intel.com ([169.254.10.157]) with mapi id
	14.03.0195.001; Wed, 3 Dec 2014 09:14:04 -0800
From: "Dugger, Donald D" <donald.d.dugger@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Steve Freitas <sflist@ihonk.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>
Thread-Topic: [Xen-devel] Regression, host crash with 4.5rc1
Thread-Index: AQHQCiRvziVk7QxTkUiRMb29ncqaJZx+JI+A
Date: Wed, 3 Dec 2014 17:14:04 +0000
Message-ID: <6AF484C0160C61439DE06F17668F3BCB53440D89@ORSMSX114.amr.corp.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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.139]
MIME-Version: 1.0
Cc: 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

Jan-

No, I have no knowledge of an unpublished errata related to C State issues.

--
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: Thursday, November 27, 2014 2:28 AM
To: Steve Freitas; Dugger, Donald D; Nakajima, Jun
Cc: xen-devel@lists.xen.org; Don Slutz
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1

>>> 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 Wed Dec 03 18:08:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 18:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwELG-0006pa-Bm; Wed, 03 Dec 2014 18:07:58 +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 1XwELE-0006pV-DV
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 18:07:56 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	AA/1B-07724-B715F745; Wed, 03 Dec 2014 18:07:55 +0000
X-Env-Sender: donald.d.dugger@intel.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417630073!10889276!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21603 invoked from network); 3 Dec 2014 18:07:54 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-31.messagelabs.com with SMTP;
	3 Dec 2014 18:07:54 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga101.jf.intel.com with ESMTP; 03 Dec 2014 09:14:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="492992511"
Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129])
	by orsmga003.jf.intel.com with ESMTP; 03 Dec 2014 09:10:47 -0800
Received: from orsmsx158.amr.corp.intel.com (10.22.240.20) by
	ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 3 Dec 2014 09:14:04 -0800
Received: from orsmsx114.amr.corp.intel.com ([169.254.8.127]) by
	ORSMSX158.amr.corp.intel.com ([169.254.10.157]) with mapi id
	14.03.0195.001; Wed, 3 Dec 2014 09:14:04 -0800
From: "Dugger, Donald D" <donald.d.dugger@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Steve Freitas <sflist@ihonk.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>
Thread-Topic: [Xen-devel] Regression, host crash with 4.5rc1
Thread-Index: AQHQCiRvziVk7QxTkUiRMb29ncqaJZx+JI+A
Date: Wed, 3 Dec 2014 17:14:04 +0000
Message-ID: <6AF484C0160C61439DE06F17668F3BCB53440D89@ORSMSX114.amr.corp.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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.139]
MIME-Version: 1.0
Cc: 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

Jan-

No, I have no knowledge of an unpublished errata related to C State issues.

--
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: Thursday, November 27, 2014 2:28 AM
To: Steve Freitas; Dugger, Donald D; Nakajima, Jun
Cc: xen-devel@lists.xen.org; Don Slutz
Subject: Re: [Xen-devel] Regression, host crash with 4.5rc1

>>> 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 Wed Dec 03 18:15:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 18:15:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwESi-0007Jn-9N; Wed, 03 Dec 2014 18:15:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XwESg-0007Ji-SP
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 18:15:39 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5D/A8-09842-A435F745; Wed, 03 Dec 2014 18:15:38 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417630536!13218162!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14498 invoked from network); 3 Dec 2014 18:15:37 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 18:15:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417630537; x=1449166537;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=aLXy8+roEcWJvVfuxhVP4wr3jaEYy+xwhuk6OA81/AM=;
	b=uGXw+xnB92sI2BnIimIwQnfQZPASnchUcbWvaDbeSClGcyyg3ufqM/jl
	bcWquCUYknFD4k+q82cOQLHZSSnqbYiAnUdgHo02XRFA1Bf+vbPpacqrH
	oELw2G85WPSV+aFUnyXT1S/IaNpQSLQr758IDDXE7+dYZzlT1unesKVRl I=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 03 Dec 2014 18:12:26 +0000
Received: from unknown (HELO omzsmtpe04.verizonbusiness.com) ([199.249.25.207])
	by fldsmtpi03.verizon.com with ESMTP; 03 Dec 2014 18:09:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417630195; x=1449166195;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=aLXy8+roEcWJvVfuxhVP4wr3jaEYy+xwhuk6OA81/AM=;
	b=IRK9y30VajsAtVDrTXVTY59DgfMSgqjUiNCjVqhFpUXeYAkXLyLSLfj6
	QgbFSEzNr7mXnzG5kg/W7uJS58/n5euiyW1/DsFrMNJkp84ecnqJnOnz1
	rihFNwoNmYrA1JTfUwg4cc8VX23/z08jB6Eu5ARYUbC9r9RnkDb5rGBXM k=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 03 Dec 2014 18:09:54 +0000
Received: from unknown (HELO omzsmtpe04.verizonbusiness.com) ([199.249.25.207])
	by fldsmtpi02.verizon.com with ESMTP; 03 Dec 2014 18:08:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417630117; x=1449166117;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=aLXy8+roEcWJvVfuxhVP4wr3jaEYy+xwhuk6OA81/AM=;
	b=HBhBu0M0++Q0+UHzsqFZETWGhYPq2LlCemDGr4t3pQZOmDBPOelWvxX/
	+Tvgsq+etLYUfhLuXryR3lBra7owhGpw9Gv+XBX3yRzGZ2XOvh34pn2vc
	XZcF8BHh8wHHYNMI7k4k55B4GIKn90a1wry3NwLDeNCh3EYbvPopCL1W8 A=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 03 Dec 2014 18:08:36 +0000
Received: from unknown (HELO omzsmtpe04.verizonbusiness.com) ([199.249.25.207])
	by fldsmtpi02.verizon.com with ESMTP; 03 Dec 2014 18:07:41 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417630061; x=1449166061;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=aLXy8+roEcWJvVfuxhVP4wr3jaEYy+xwhuk6OA81/AM=;
	b=n2t1NrRFV33dsXaBM2FZR6VJrIyZU2xIHEQXMQIvMTKT38EqB6K/Nbiq
	gFUYLoVma4IOCvZtZf5jhAyxo8HoeZjLIhEnTejUvy82kqEtkTfyYJhvn
	49G3aFhAMOVhh6lZSivhNQB/pSu5unBjN6jt45MsV0+W4Bo0maKiTcd9n E=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 03 Dec 2014 18:07:40 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="920203694"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.106.64])
	by fldsmtpi01.verizon.com with ESMTP; 03 Dec 2014 18:07:33 +0000
Message-ID: <547F5165.4040804@terremark.com>
Date: Wed, 03 Dec 2014 13:07:33 -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: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.com>
	<alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
	<547DD3E5.9090303@terremark.com> <547DDA5C.8080803@terremark.com>
	<alpine.DEB.2.02.1412031728290.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412031728290.30971@kaball.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.6] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/03/14 12:31, Stefano Stabellini wrote:
> On Tue, 2 Dec 2014, Don Slutz wrote:
>> On 12/02/14 09:59, Don Slutz wrote:
>>> On 12/02/14 09:26, Stefano Stabellini wrote:
>>>> On Tue, 2 Dec 2014, Don Slutz wrote:
>>>>> On 12/02/14 06:53, Stefano Stabellini wrote:
>>>>>> 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>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Changes in v2:
>>>>>> - call libxl_domain_info instead of libxl_dominfo_init;
>>>>>> - call libxl_domain_info before retry_transaction.
>>>>>>
>>>>>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>>>>>> index de23fec..569a32a 100644
>>>>>> --- a/tools/libxl/libxl.c
>>>>>> +++ b/tools/libxl/libxl.c
>>>>>> @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx,
>>>>>> uint32_t
>>>>>> domid,
>>>>>>         char *uuid;
>>>>>>         xs_transaction_t t;
>>>>>>     +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
>>>>>> +        goto out_no_transaction;
>>>>>> +
>>>>>>     retry_transaction:
>>>>>>         t = xs_transaction_start(ctx->xsh);
>>>>>>     @@ -4767,10 +4770,9 @@ 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);
>>>>>> +    if (enforce && new_target_memkb > 0) {
>>>>>> +        memorykb = ptr.max_memkb - current_target_memkb +
>>>>>> new_target_memkb;
>> My testing shows that this should be:
>>
>>          memorykb = ptr.max_memkb - (current_target_memkb + videoram) +
>>              new_target_memkb;
>>
>> As far as I can tell the reason for this is that memory/target (aka
>> current_target_memkb) was set based on:
>>
>>      new_target_memkb -= videoram;
> Thank you very much for testing and the suggestion!
>
> I think that the right fix for this is to remove videoram from
> new_target_memkb earlier and only when the new target is absolute,
> otherwise we risk removing videoram twice (in case the new target is
> relative). I wonder why we didn't notice this before.

Sounds like a good idea.  No clue, I have been looking real close at 
this stuff.
and that my be why I tripped over it.

>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index d5d5204..4803cc4 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4744,13 +4744,17 @@ retry_transaction:
>           goto out;
>       }
>   
> +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> +                "%s/memory/videoram", dompath));
> +    videoram = videoram_s ? atoi(videoram_s) : 0;
> +
>       if (relative) {
>           if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
>               new_target_memkb = 0;
>           else
>               new_target_memkb = current_target_memkb + target_memkb;
>       } else
> -        new_target_memkb = target_memkb;
> +        new_target_memkb = target_memkb - videoram;
>       if (new_target_memkb > memorykb) {
>           LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                   "memory_dynamic_max must be less than or equal to"
> @@ -4766,9 +4770,6 @@ retry_transaction:
>           abort_transaction = 1;
>           goto out;
>       }
> -    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> -                "%s/memory/videoram", dompath));
> -    videoram = videoram_s ? atoi(videoram_s) : 0;
>   
>       if (enforce && new_target_memkb > 0) {
>           memorykb = ptr.max_memkb - current_target_memkb + new_target_memkb;
> @@ -4782,7 +4783,6 @@ retry_transaction:
>           }
>       }
>   
> -    new_target_memkb -= videoram;
>       rc = xc_domain_set_pod_target(ctx->xch, domid,
>               new_target_memkb / 4, NULL, NULL, NULL);
>       if (rc != 0) {

This does look like a bugfix for just the videoram issue.  Not sure why
you made this v2 since I do not see the original change.

Anyway if you want to post this change for 4.5 (?) I would be happy to 
review it.
     -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 Dec 03 18:15:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 18:15:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwESi-0007Jn-9N; Wed, 03 Dec 2014 18:15:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dslutz@verizon.com>) id 1XwESg-0007Ji-SP
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 18:15:39 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5D/A8-09842-A435F745; Wed, 03 Dec 2014 18:15:38 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417630536!13218162!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14498 invoked from network); 3 Dec 2014 18:15:37 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 18:15:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417630537; x=1449166537;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=aLXy8+roEcWJvVfuxhVP4wr3jaEYy+xwhuk6OA81/AM=;
	b=uGXw+xnB92sI2BnIimIwQnfQZPASnchUcbWvaDbeSClGcyyg3ufqM/jl
	bcWquCUYknFD4k+q82cOQLHZSSnqbYiAnUdgHo02XRFA1Bf+vbPpacqrH
	oELw2G85WPSV+aFUnyXT1S/IaNpQSLQr758IDDXE7+dYZzlT1unesKVRl I=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 03 Dec 2014 18:12:26 +0000
Received: from unknown (HELO omzsmtpe04.verizonbusiness.com) ([199.249.25.207])
	by fldsmtpi03.verizon.com with ESMTP; 03 Dec 2014 18:09:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417630195; x=1449166195;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=aLXy8+roEcWJvVfuxhVP4wr3jaEYy+xwhuk6OA81/AM=;
	b=IRK9y30VajsAtVDrTXVTY59DgfMSgqjUiNCjVqhFpUXeYAkXLyLSLfj6
	QgbFSEzNr7mXnzG5kg/W7uJS58/n5euiyW1/DsFrMNJkp84ecnqJnOnz1
	rihFNwoNmYrA1JTfUwg4cc8VX23/z08jB6Eu5ARYUbC9r9RnkDb5rGBXM k=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 03 Dec 2014 18:09:54 +0000
Received: from unknown (HELO omzsmtpe04.verizonbusiness.com) ([199.249.25.207])
	by fldsmtpi02.verizon.com with ESMTP; 03 Dec 2014 18:08:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417630117; x=1449166117;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=aLXy8+roEcWJvVfuxhVP4wr3jaEYy+xwhuk6OA81/AM=;
	b=HBhBu0M0++Q0+UHzsqFZETWGhYPq2LlCemDGr4t3pQZOmDBPOelWvxX/
	+Tvgsq+etLYUfhLuXryR3lBra7owhGpw9Gv+XBX3yRzGZ2XOvh34pn2vc
	XZcF8BHh8wHHYNMI7k4k55B4GIKn90a1wry3NwLDeNCh3EYbvPopCL1W8 A=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 03 Dec 2014 18:08:36 +0000
Received: from unknown (HELO omzsmtpe04.verizonbusiness.com) ([199.249.25.207])
	by fldsmtpi02.verizon.com with ESMTP; 03 Dec 2014 18:07:41 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417630061; x=1449166061;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=aLXy8+roEcWJvVfuxhVP4wr3jaEYy+xwhuk6OA81/AM=;
	b=n2t1NrRFV33dsXaBM2FZR6VJrIyZU2xIHEQXMQIvMTKT38EqB6K/Nbiq
	gFUYLoVma4IOCvZtZf5jhAyxo8HoeZjLIhEnTejUvy82kqEtkTfyYJhvn
	49G3aFhAMOVhh6lZSivhNQB/pSu5unBjN6jt45MsV0+W4Bo0maKiTcd9n E=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 03 Dec 2014 18:07:40 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="920203694"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.106.64])
	by fldsmtpi01.verizon.com with ESMTP; 03 Dec 2014 18:07:33 +0000
Message-ID: <547F5165.4040804@terremark.com>
Date: Wed, 03 Dec 2014 13:07:33 -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: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.com>
	<alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
	<547DD3E5.9090303@terremark.com> <547DDA5C.8080803@terremark.com>
	<alpine.DEB.2.02.1412031728290.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412031728290.30971@kaball.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 for-4.6] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/03/14 12:31, Stefano Stabellini wrote:
> On Tue, 2 Dec 2014, Don Slutz wrote:
>> On 12/02/14 09:59, Don Slutz wrote:
>>> On 12/02/14 09:26, Stefano Stabellini wrote:
>>>> On Tue, 2 Dec 2014, Don Slutz wrote:
>>>>> On 12/02/14 06:53, Stefano Stabellini wrote:
>>>>>> 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>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Changes in v2:
>>>>>> - call libxl_domain_info instead of libxl_dominfo_init;
>>>>>> - call libxl_domain_info before retry_transaction.
>>>>>>
>>>>>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>>>>>> index de23fec..569a32a 100644
>>>>>> --- a/tools/libxl/libxl.c
>>>>>> +++ b/tools/libxl/libxl.c
>>>>>> @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx,
>>>>>> uint32_t
>>>>>> domid,
>>>>>>         char *uuid;
>>>>>>         xs_transaction_t t;
>>>>>>     +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
>>>>>> +        goto out_no_transaction;
>>>>>> +
>>>>>>     retry_transaction:
>>>>>>         t = xs_transaction_start(ctx->xsh);
>>>>>>     @@ -4767,10 +4770,9 @@ 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);
>>>>>> +    if (enforce && new_target_memkb > 0) {
>>>>>> +        memorykb = ptr.max_memkb - current_target_memkb +
>>>>>> new_target_memkb;
>> My testing shows that this should be:
>>
>>          memorykb = ptr.max_memkb - (current_target_memkb + videoram) +
>>              new_target_memkb;
>>
>> As far as I can tell the reason for this is that memory/target (aka
>> current_target_memkb) was set based on:
>>
>>      new_target_memkb -= videoram;
> Thank you very much for testing and the suggestion!
>
> I think that the right fix for this is to remove videoram from
> new_target_memkb earlier and only when the new target is absolute,
> otherwise we risk removing videoram twice (in case the new target is
> relative). I wonder why we didn't notice this before.

Sounds like a good idea.  No clue, I have been looking real close at 
this stuff.
and that my be why I tripped over it.

>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index d5d5204..4803cc4 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4744,13 +4744,17 @@ retry_transaction:
>           goto out;
>       }
>   
> +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> +                "%s/memory/videoram", dompath));
> +    videoram = videoram_s ? atoi(videoram_s) : 0;
> +
>       if (relative) {
>           if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
>               new_target_memkb = 0;
>           else
>               new_target_memkb = current_target_memkb + target_memkb;
>       } else
> -        new_target_memkb = target_memkb;
> +        new_target_memkb = target_memkb - videoram;
>       if (new_target_memkb > memorykb) {
>           LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                   "memory_dynamic_max must be less than or equal to"
> @@ -4766,9 +4770,6 @@ retry_transaction:
>           abort_transaction = 1;
>           goto out;
>       }
> -    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> -                "%s/memory/videoram", dompath));
> -    videoram = videoram_s ? atoi(videoram_s) : 0;
>   
>       if (enforce && new_target_memkb > 0) {
>           memorykb = ptr.max_memkb - current_target_memkb + new_target_memkb;
> @@ -4782,7 +4783,6 @@ retry_transaction:
>           }
>       }
>   
> -    new_target_memkb -= videoram;
>       rc = xc_domain_set_pod_target(ctx->xch, domid,
>               new_target_memkb / 4, NULL, NULL, NULL);
>       if (rc != 0) {

This does look like a bugfix for just the videoram issue.  Not sure why
you made this v2 since I do not see the original change.

Anyway if you want to post this change for 4.5 (?) I would be happy to 
review it.
     -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 Dec 03 18:20:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 18: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 1XwEX7-0007UC-6e; Wed, 03 Dec 2014 18:20:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XwEX5-0007U6-OV
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 18:20:11 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	C9/EF-27584-A545F745; Wed, 03 Dec 2014 18:20:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417630808!11368294!1
X-Originating-IP: [66.165.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 8746 invoked from network); 3 Dec 2014 18:20:10 -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;
	3 Dec 2014 18:20:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="199184765"
Received: from ukmail1.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, 3 Dec 2014 13:18: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 1XwEVC-00019G-FJ;
	Wed, 03 Dec 2014 18:18:14 +0000
Date: Wed, 3 Dec 2014 18:18:02 +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: <547F5165.4040804@terremark.com>
Message-ID: <alpine.DEB.2.02.1412031817530.30971@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.com>
	<alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
	<547DD3E5.9090303@terremark.com> <547DDA5C.8080803@terremark.com>
	<alpine.DEB.2.02.1412031728290.30971@kaball.uk.xensource.com>
	<547F5165.4040804@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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: Re: [Xen-devel] [PATCH v2 for-4.6] 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

On Wed, 3 Dec 2014, Don Slutz wrote:
> On 12/03/14 12:31, Stefano Stabellini wrote:
> > On Tue, 2 Dec 2014, Don Slutz wrote:
> > > On 12/02/14 09:59, Don Slutz wrote:
> > > > On 12/02/14 09:26, Stefano Stabellini wrote:
> > > > > On Tue, 2 Dec 2014, Don Slutz wrote:
> > > > > > On 12/02/14 06:53, Stefano Stabellini wrote:
> > > > > > > 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>
> > > > > > > 
> > > > > > > ---
> > > > > > > 
> > > > > > > Changes in v2:
> > > > > > > - call libxl_domain_info instead of libxl_dominfo_init;
> > > > > > > - call libxl_domain_info before retry_transaction.
> > > > > > > 
> > > > > > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > > > > > index de23fec..569a32a 100644
> > > > > > > --- a/tools/libxl/libxl.c
> > > > > > > +++ b/tools/libxl/libxl.c
> > > > > > > @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx,
> > > > > > > uint32_t
> > > > > > > domid,
> > > > > > >         char *uuid;
> > > > > > >         xs_transaction_t t;
> > > > > > >     +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
> > > > > > > +        goto out_no_transaction;
> > > > > > > +
> > > > > > >     retry_transaction:
> > > > > > >         t = xs_transaction_start(ctx->xsh);
> > > > > > >     @@ -4767,10 +4770,9 @@ 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);
> > > > > > > +    if (enforce && new_target_memkb > 0) {
> > > > > > > +        memorykb = ptr.max_memkb - current_target_memkb +
> > > > > > > new_target_memkb;
> > > My testing shows that this should be:
> > > 
> > >          memorykb = ptr.max_memkb - (current_target_memkb + videoram) +
> > >              new_target_memkb;
> > > 
> > > As far as I can tell the reason for this is that memory/target (aka
> > > current_target_memkb) was set based on:
> > > 
> > >      new_target_memkb -= videoram;
> > Thank you very much for testing and the suggestion!
> > 
> > I think that the right fix for this is to remove videoram from
> > new_target_memkb earlier and only when the new target is absolute,
> > otherwise we risk removing videoram twice (in case the new target is
> > relative). I wonder why we didn't notice this before.
> 
> Sounds like a good idea.  No clue, I have been looking real close at this
> stuff.
> and that my be why I tripped over it.
> 
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index d5d5204..4803cc4 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4744,13 +4744,17 @@ retry_transaction:
> >           goto out;
> >       }
> >   +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> > +                "%s/memory/videoram", dompath));
> > +    videoram = videoram_s ? atoi(videoram_s) : 0;
> > +
> >       if (relative) {
> >           if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
> >               new_target_memkb = 0;
> >           else
> >               new_target_memkb = current_target_memkb + target_memkb;
> >       } else
> > -        new_target_memkb = target_memkb;
> > +        new_target_memkb = target_memkb - videoram;
> >       if (new_target_memkb > memorykb) {
> >           LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> >                   "memory_dynamic_max must be less than or equal to"
> > @@ -4766,9 +4770,6 @@ retry_transaction:
> >           abort_transaction = 1;
> >           goto out;
> >       }
> > -    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> > -                "%s/memory/videoram", dompath));
> > -    videoram = videoram_s ? atoi(videoram_s) : 0;
> >         if (enforce && new_target_memkb > 0) {
> >           memorykb = ptr.max_memkb - current_target_memkb +
> > new_target_memkb;
> > @@ -4782,7 +4783,6 @@ retry_transaction:
> >           }
> >       }
> >   -    new_target_memkb -= videoram;
> >       rc = xc_domain_set_pod_target(ctx->xch, domid,
> >               new_target_memkb / 4, NULL, NULL, NULL);
> >       if (rc != 0) {
> 
> This does look like a bugfix for just the videoram issue.  Not sure why
> you made this v2 since I do not see the original change.
> 
> Anyway if you want to post this change for 4.5 (?) I would be happy to review
> it.

Thanks, I'll do.

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 18:20:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 18: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 1XwEX7-0007UC-6e; Wed, 03 Dec 2014 18:20:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XwEX5-0007U6-OV
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 18:20:11 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	C9/EF-27584-A545F745; Wed, 03 Dec 2014 18:20:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417630808!11368294!1
X-Originating-IP: [66.165.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 8746 invoked from network); 3 Dec 2014 18:20:10 -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;
	3 Dec 2014 18:20:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="199184765"
Received: from ukmail1.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, 3 Dec 2014 13:18: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 1XwEVC-00019G-FJ;
	Wed, 03 Dec 2014 18:18:14 +0000
Date: Wed, 3 Dec 2014 18:18:02 +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: <547F5165.4040804@terremark.com>
Message-ID: <alpine.DEB.2.02.1412031817530.30971@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1412021152080.14135@kaball.uk.xensource.com>
	<547DBC05.9070904@terremark.com>
	<alpine.DEB.2.02.1412021422470.14135@kaball.uk.xensource.com>
	<547DD3E5.9090303@terremark.com> <547DDA5C.8080803@terremark.com>
	<alpine.DEB.2.02.1412031728290.30971@kaball.uk.xensource.com>
	<547F5165.4040804@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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: Re: [Xen-devel] [PATCH v2 for-4.6] 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

On Wed, 3 Dec 2014, Don Slutz wrote:
> On 12/03/14 12:31, Stefano Stabellini wrote:
> > On Tue, 2 Dec 2014, Don Slutz wrote:
> > > On 12/02/14 09:59, Don Slutz wrote:
> > > > On 12/02/14 09:26, Stefano Stabellini wrote:
> > > > > On Tue, 2 Dec 2014, Don Slutz wrote:
> > > > > > On 12/02/14 06:53, Stefano Stabellini wrote:
> > > > > > > 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>
> > > > > > > 
> > > > > > > ---
> > > > > > > 
> > > > > > > Changes in v2:
> > > > > > > - call libxl_domain_info instead of libxl_dominfo_init;
> > > > > > > - call libxl_domain_info before retry_transaction.
> > > > > > > 
> > > > > > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > > > > > index de23fec..569a32a 100644
> > > > > > > --- a/tools/libxl/libxl.c
> > > > > > > +++ b/tools/libxl/libxl.c
> > > > > > > @@ -4694,6 +4694,9 @@ int libxl_set_memory_target(libxl_ctx *ctx,
> > > > > > > uint32_t
> > > > > > > domid,
> > > > > > >         char *uuid;
> > > > > > >         xs_transaction_t t;
> > > > > > >     +    if (libxl_domain_info(ctx, &ptr, domid) < 0)
> > > > > > > +        goto out_no_transaction;
> > > > > > > +
> > > > > > >     retry_transaction:
> > > > > > >         t = xs_transaction_start(ctx->xsh);
> > > > > > >     @@ -4767,10 +4770,9 @@ 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);
> > > > > > > +    if (enforce && new_target_memkb > 0) {
> > > > > > > +        memorykb = ptr.max_memkb - current_target_memkb +
> > > > > > > new_target_memkb;
> > > My testing shows that this should be:
> > > 
> > >          memorykb = ptr.max_memkb - (current_target_memkb + videoram) +
> > >              new_target_memkb;
> > > 
> > > As far as I can tell the reason for this is that memory/target (aka
> > > current_target_memkb) was set based on:
> > > 
> > >      new_target_memkb -= videoram;
> > Thank you very much for testing and the suggestion!
> > 
> > I think that the right fix for this is to remove videoram from
> > new_target_memkb earlier and only when the new target is absolute,
> > otherwise we risk removing videoram twice (in case the new target is
> > relative). I wonder why we didn't notice this before.
> 
> Sounds like a good idea.  No clue, I have been looking real close at this
> stuff.
> and that my be why I tripped over it.
> 
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index d5d5204..4803cc4 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4744,13 +4744,17 @@ retry_transaction:
> >           goto out;
> >       }
> >   +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> > +                "%s/memory/videoram", dompath));
> > +    videoram = videoram_s ? atoi(videoram_s) : 0;
> > +
> >       if (relative) {
> >           if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
> >               new_target_memkb = 0;
> >           else
> >               new_target_memkb = current_target_memkb + target_memkb;
> >       } else
> > -        new_target_memkb = target_memkb;
> > +        new_target_memkb = target_memkb - videoram;
> >       if (new_target_memkb > memorykb) {
> >           LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> >                   "memory_dynamic_max must be less than or equal to"
> > @@ -4766,9 +4770,6 @@ retry_transaction:
> >           abort_transaction = 1;
> >           goto out;
> >       }
> > -    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> > -                "%s/memory/videoram", dompath));
> > -    videoram = videoram_s ? atoi(videoram_s) : 0;
> >         if (enforce && new_target_memkb > 0) {
> >           memorykb = ptr.max_memkb - current_target_memkb +
> > new_target_memkb;
> > @@ -4782,7 +4783,6 @@ retry_transaction:
> >           }
> >       }
> >   -    new_target_memkb -= videoram;
> >       rc = xc_domain_set_pod_target(ctx->xch, domid,
> >               new_target_memkb / 4, NULL, NULL, NULL);
> >       if (rc != 0) {
> 
> This does look like a bugfix for just the videoram issue.  Not sure why
> you made this v2 since I do not see the original change.
> 
> Anyway if you want to post this change for 4.5 (?) I would be happy to review
> it.

Thanks, I'll do.

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 18:21:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 18:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwEXv-0007Xu-K8; Wed, 03 Dec 2014 18:21:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XwEXt-0007Xj-T4
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 18:21:02 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	02/16-27623-D845F745; Wed, 03 Dec 2014 18:21:01 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417630859!10943445!1
X-Originating-IP: [66.165.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 29545 invoked from network); 3 Dec 2014 18:21:00 -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;
	3 Dec 2014 18:21:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="199529382"
Received: from ukmail1.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, 3 Dec 2014 13:20: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 1XwEXl-0001CU-El;
	Wed, 03 Dec 2014 18:20:53 +0000
Date: Wed, 3 Dec 2014 18:20:41 +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.1412031818180.30971@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Anthony Perard <anthony.perard@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	dslutz@verizon.com, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl_set_memory_target: only remove
 videoram from absolute targets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If the new target is relative to the current target, do not remove
videoram again: it has already been removed from the current target.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..2aa83bd 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4741,13 +4741,17 @@ retry_transaction:
         goto out;
     }
 
+    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
+                "%s/memory/videoram", dompath));
+    videoram = videoram_s ? atoi(videoram_s) : 0;
+
     if (relative) {
         if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
             new_target_memkb = 0;
         else
             new_target_memkb = current_target_memkb + target_memkb;
     } else
-        new_target_memkb = target_memkb;
+        new_target_memkb = target_memkb - videoram;
     if (new_target_memkb > memorykb) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "memory_dynamic_max must be less than or equal to"
@@ -4763,9 +4767,6 @@ retry_transaction:
         abort_transaction = 1;
         goto out;
     }
-    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
-                "%s/memory/videoram", dompath));
-    videoram = videoram_s ? atoi(videoram_s) : 0;
 
     if (enforce) {
         memorykb = new_target_memkb;
@@ -4780,7 +4781,6 @@ retry_transaction:
         }
     }
 
-    new_target_memkb -= videoram;
     rc = xc_domain_set_pod_target(ctx->xch, domid,
             new_target_memkb / 4, NULL, NULL, NULL);
     if (rc != 0) {

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 18:21:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 18:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwEXv-0007Xu-K8; Wed, 03 Dec 2014 18:21:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XwEXt-0007Xj-T4
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 18:21:02 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	02/16-27623-D845F745; Wed, 03 Dec 2014 18:21:01 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417630859!10943445!1
X-Originating-IP: [66.165.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 29545 invoked from network); 3 Dec 2014 18:21:00 -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;
	3 Dec 2014 18:21:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="199529382"
Received: from ukmail1.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, 3 Dec 2014 13:20: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 1XwEXl-0001CU-El;
	Wed, 03 Dec 2014 18:20:53 +0000
Date: Wed, 3 Dec 2014 18:20:41 +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.1412031818180.30971@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Anthony Perard <anthony.perard@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	dslutz@verizon.com, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH for-4.5] libxl_set_memory_target: only remove
 videoram from absolute targets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If the new target is relative to the current target, do not remove
videoram again: it has already been removed from the current target.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index de23fec..2aa83bd 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4741,13 +4741,17 @@ retry_transaction:
         goto out;
     }
 
+    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
+                "%s/memory/videoram", dompath));
+    videoram = videoram_s ? atoi(videoram_s) : 0;
+
     if (relative) {
         if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
             new_target_memkb = 0;
         else
             new_target_memkb = current_target_memkb + target_memkb;
     } else
-        new_target_memkb = target_memkb;
+        new_target_memkb = target_memkb - videoram;
     if (new_target_memkb > memorykb) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "memory_dynamic_max must be less than or equal to"
@@ -4763,9 +4767,6 @@ retry_transaction:
         abort_transaction = 1;
         goto out;
     }
-    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
-                "%s/memory/videoram", dompath));
-    videoram = videoram_s ? atoi(videoram_s) : 0;
 
     if (enforce) {
         memorykb = new_target_memkb;
@@ -4780,7 +4781,6 @@ retry_transaction:
         }
     }
 
-    new_target_memkb -= videoram;
     rc = xc_domain_set_pod_target(ctx->xch, domid,
             new_target_memkb / 4, NULL, NULL, NULL);
     if (rc != 0) {

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 18:37:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 18: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 1XwEnl-0008Aa-60; Wed, 03 Dec 2014 18:37:25 +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 1XwEnj-0008AV-QR
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 18:37:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C2/1C-09842-3685F745; Wed, 03 Dec 2014 18:37:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417631842!13155419!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2745 invoked from network); 3 Dec 2014 18:37:22 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-6.tower-21.messagelabs.com with SMTP;
	3 Dec 2014 18:37:22 -0000
X-TM-IMSS-Message-ID: <5c892afc0006229d@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 5c892afc0006229d ;
	Wed, 3 Dec 2014 13:37: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 sB3Ib2WR003583; 
	Wed, 3 Dec 2014 13:37:12 -0500
Message-ID: <547F584E.2090003@tycho.nsa.gov>
Date: Wed, 03 Dec 2014 13:37:02 -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>,
	George Dunlap <George.Dunlap@eu.citrix.com>
References: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
	<CAFLBxZY253TVWetxMAMCBzcRB3qvd490OOaHpQ1j7fqVyb-90g@mail.gmail.com>
	<5477445E.4040803@citrix.com>
In-Reply-To: <5477445E.4040803@citrix.com>
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-Transfer-Encoding: 7bit
Content-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 10:33 AM, Andrew Cooper wrote:
> 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

This allows any (privileged or unprivileged) guest to trigger the ASSERT
and cause a hypervisor crash on a debug build.  Given that XSA-37 was
considered a security vulnerability due to this type of behavior, I am
hesitant to deliberately add a path to trigger a hypervisor crash, even
if it makes testing easier.

-- 
Daniel De Graaf
National Security Agency

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 18:37:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 18: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 1XwEnl-0008Aa-60; Wed, 03 Dec 2014 18:37:25 +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 1XwEnj-0008AV-QR
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 18:37:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C2/1C-09842-3685F745; Wed, 03 Dec 2014 18:37:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417631842!13155419!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2745 invoked from network); 3 Dec 2014 18:37:22 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-6.tower-21.messagelabs.com with SMTP;
	3 Dec 2014 18:37:22 -0000
X-TM-IMSS-Message-ID: <5c892afc0006229d@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 5c892afc0006229d ;
	Wed, 3 Dec 2014 13:37: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 sB3Ib2WR003583; 
	Wed, 3 Dec 2014 13:37:12 -0500
Message-ID: <547F584E.2090003@tycho.nsa.gov>
Date: Wed, 03 Dec 2014 13:37:02 -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>,
	George Dunlap <George.Dunlap@eu.citrix.com>
References: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
	<CAFLBxZY253TVWetxMAMCBzcRB3qvd490OOaHpQ1j7fqVyb-90g@mail.gmail.com>
	<5477445E.4040803@citrix.com>
In-Reply-To: <5477445E.4040803@citrix.com>
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-Transfer-Encoding: 7bit
Content-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 10:33 AM, Andrew Cooper wrote:
> 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

This allows any (privileged or unprivileged) guest to trigger the ASSERT
and cause a hypervisor crash on a debug build.  Given that XSA-37 was
considered a security vulnerability due to this type of behavior, I am
hesitant to deliberately add a path to trigger a hypervisor crash, even
if it makes testing easier.

-- 
Daniel De Graaf
National Security Agency

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 18:43:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 18: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 1XwEtB-0008Sd-Ue; Wed, 03 Dec 2014 18:43:01 +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 1XwEtA-0008SY-Nv
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 18:43:00 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	A6/00-02954-4B95F745; Wed, 03 Dec 2014 18:43:00 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417632177!12783361!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 32499 invoked from network); 3 Dec 2014 18:42:59 -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;
	3 Dec 2014 18:42:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="199539943"
Message-ID: <547F5998.6060904@citrix.com>
Date: Wed, 3 Dec 2014 18:42: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: Daniel De Graaf <dgdegra@tycho.nsa.gov>, George Dunlap
	<George.Dunlap@eu.citrix.com>
References: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
	<CAFLBxZY253TVWetxMAMCBzcRB3qvd490OOaHpQ1j7fqVyb-90g@mail.gmail.com>
	<5477445E.4040803@citrix.com> <547F584E.2090003@tycho.nsa.gov>
In-Reply-To: <547F584E.2090003@tycho.nsa.gov>
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 03/12/14 18:37, Daniel De Graaf wrote:
> On 11/27/2014 10:33 AM, Andrew Cooper wrote:
>> 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
>
> This allows any (privileged or unprivileged) guest to trigger the ASSERT
> and cause a hypervisor crash on a debug build.  Given that XSA-37 was
> considered a security vulnerability due to this type of behavior, I am
> hesitant to deliberately add a path to trigger a hypervisor crash, even
> if it makes testing easier.
>

XSA-37 was only an XSA because the rules at the time were unclear as
whether it was an issue or not.  At the same time, the rules were
clarified to state that issues in a debug build only are not security
issues.

~Andrew

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 18:43:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 18: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 1XwEtB-0008Sd-Ue; Wed, 03 Dec 2014 18:43:01 +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 1XwEtA-0008SY-Nv
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 18:43:00 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	A6/00-02954-4B95F745; Wed, 03 Dec 2014 18:43:00 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417632177!12783361!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 32499 invoked from network); 3 Dec 2014 18:42:59 -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;
	3 Dec 2014 18:42:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="199539943"
Message-ID: <547F5998.6060904@citrix.com>
Date: Wed, 3 Dec 2014 18:42: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: Daniel De Graaf <dgdegra@tycho.nsa.gov>, George Dunlap
	<George.Dunlap@eu.citrix.com>
References: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>
	<CAFLBxZY253TVWetxMAMCBzcRB3qvd490OOaHpQ1j7fqVyb-90g@mail.gmail.com>
	<5477445E.4040803@citrix.com> <547F584E.2090003@tycho.nsa.gov>
In-Reply-To: <547F584E.2090003@tycho.nsa.gov>
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 03/12/14 18:37, Daniel De Graaf wrote:
> On 11/27/2014 10:33 AM, Andrew Cooper wrote:
>> 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
>
> This allows any (privileged or unprivileged) guest to trigger the ASSERT
> and cause a hypervisor crash on a debug build.  Given that XSA-37 was
> considered a security vulnerability due to this type of behavior, I am
> hesitant to deliberately add a path to trigger a hypervisor crash, even
> if it makes testing easier.
>

XSA-37 was only an XSA because the rules at the time were unclear as
whether it was an issue or not.  At the same time, the rules were
clarified to state that issues in a debug build only are not security
issues.

~Andrew

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 19:40:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 19:40:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwFmC-00010g-EQ; Wed, 03 Dec 2014 19:39:52 +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 1XwFmA-00010b-Sq
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 19:39:50 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	BD/EA-20609-6076F745; Wed, 03 Dec 2014 19:39:50 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417635588!7388204!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 20582 invoked from network); 3 Dec 2014 19:39:49 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 19:39:49 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 394DEAB43;
	Wed,  3 Dec 2014 19:39:48 +0000 (UTC)
Date: Wed, 3 Dec 2014 20:39:47 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141203193947.GD25677@wotan.suse.de>
References: <20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
	<547CB07C.1050507@citrix.com>
	<20141201223611.GM25677@wotan.suse.de> <547D9E56.50708@citrix.com>
	<20141203022833.GS25677@wotan.suse.de> <547E939F.40106@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547E939F.40106@suse.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	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>, Ingo Molnar <mingo@kernel.org>
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 Wed, Dec 03, 2014 at 05:37:51AM +0100, Juergen Gross wrote:
> On 12/03/2014 03:28 AM, Luis R. Rodriguez wrote:
>> On Tue, Dec 02, 2014 at 11:11:18AM +0000, David Vrabel wrote:
>>> On 01/12/14 22:36, Luis R. Rodriguez wrote:
>>>>
>>>> Then I do agree its a fair analogy (and find this obviously odd that how
>>>> widespread cond_resched() is), we just don't have an equivalent for IRQ
>>>> context, why not avoid the special check then and use this all the time in the
>>>> middle of a hypercall on the return from an interrupt (e.g., the timer
>>>> interrupt)?
>>>
>>> http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html
>>
>> OK thanks! That explains why we need some asm code but in that submission you
>> still also had used is_preemptible_hypercall(regs) and in the new
>> implementation you use a CPU variable xen_in_preemptible_hcall prior to calling
>> preempt_schedule_irq(). I believe you added the CPU variable because
>> preempt_schedule_irq() will preempt first without any checks if it should, I'm
>> asking why not do something like cond_resched_irq() where we check with
>> should_resched() prior to preempting and that way we can avoid having to use
>> the CPU variable?
>
> Because that could preempt at any asynchronous interrupt making the
> no-preempt kernel fully preemptive. 

OK yeah I see. That still doesn't negate the value of using something
like cond_resched_irq() with a should_resched() on only critical hypercalls.
The current implementation (patch by David) forces preemption without
checking for should_resched() so it would preempt unnecessarily at least
once.

> How would you know you are just
> doing a critical hypercall which should be preempted?

You would not, you're right. I was just trying to see if we could generalize
an API for this to avoid having users having to create their own CPU variables
but this all seems very specialized as we want to use this on the timer
so if we do generalize a cond_resched_irq() perhaps the documentation can
warn about this type of case or abuse.

  Luis

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 19:40:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 19:40:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwFmC-00010g-EQ; Wed, 03 Dec 2014 19:39:52 +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 1XwFmA-00010b-Sq
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 19:39:50 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	BD/EA-20609-6076F745; Wed, 03 Dec 2014 19:39:50 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417635588!7388204!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 20582 invoked from network); 3 Dec 2014 19:39:49 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 19:39:49 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 394DEAB43;
	Wed,  3 Dec 2014 19:39:48 +0000 (UTC)
Date: Wed, 3 Dec 2014 20:39:47 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141203193947.GD25677@wotan.suse.de>
References: <20141201150546.GC25677@wotan.suse.de>
	<547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
	<547CB07C.1050507@citrix.com>
	<20141201223611.GM25677@wotan.suse.de> <547D9E56.50708@citrix.com>
	<20141203022833.GS25677@wotan.suse.de> <547E939F.40106@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547E939F.40106@suse.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	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>, Ingo Molnar <mingo@kernel.org>
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 Wed, Dec 03, 2014 at 05:37:51AM +0100, Juergen Gross wrote:
> On 12/03/2014 03:28 AM, Luis R. Rodriguez wrote:
>> On Tue, Dec 02, 2014 at 11:11:18AM +0000, David Vrabel wrote:
>>> On 01/12/14 22:36, Luis R. Rodriguez wrote:
>>>>
>>>> Then I do agree its a fair analogy (and find this obviously odd that how
>>>> widespread cond_resched() is), we just don't have an equivalent for IRQ
>>>> context, why not avoid the special check then and use this all the time in the
>>>> middle of a hypercall on the return from an interrupt (e.g., the timer
>>>> interrupt)?
>>>
>>> http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html
>>
>> OK thanks! That explains why we need some asm code but in that submission you
>> still also had used is_preemptible_hypercall(regs) and in the new
>> implementation you use a CPU variable xen_in_preemptible_hcall prior to calling
>> preempt_schedule_irq(). I believe you added the CPU variable because
>> preempt_schedule_irq() will preempt first without any checks if it should, I'm
>> asking why not do something like cond_resched_irq() where we check with
>> should_resched() prior to preempting and that way we can avoid having to use
>> the CPU variable?
>
> Because that could preempt at any asynchronous interrupt making the
> no-preempt kernel fully preemptive. 

OK yeah I see. That still doesn't negate the value of using something
like cond_resched_irq() with a should_resched() on only critical hypercalls.
The current implementation (patch by David) forces preemption without
checking for should_resched() so it would preempt unnecessarily at least
once.

> How would you know you are just
> doing a critical hypercall which should be preempted?

You would not, you're right. I was just trying to see if we could generalize
an API for this to avoid having users having to create their own CPU variables
but this all seems very specialized as we want to use this on the timer
so if we do generalize a cond_resched_irq() perhaps the documentation can
warn about this type of case or abuse.

  Luis

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:12:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGHU-0001p6-G3; Wed, 03 Dec 2014 20:12:12 +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 1XwGHS-0001p1-Qx
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 20:12:10 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	0F/2F-11608-99E6F745; Wed, 03 Dec 2014 20:12:09 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417637527!10875207!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4024 invoked from network); 3 Dec 2014 20:12:09 -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; 3 Dec 2014 20:12:09 -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 sB3KBxaj030579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:12:01 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
	sB3KBvPw023605
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 20:11:58 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
	sB3KBurm020143; Wed, 3 Dec 2014 20:11:56 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 ; Wed, 03 Dec 2014 12:11:56 -0800
Message-ID: <547F6EF3.5080304@oracle.com>
Date: Wed, 03 Dec 2014 15:13: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: 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>
	<5475E46B.9000502@oracle.com>
	<5476F580020000780004B0E2@mail.emea.novell.com>
In-Reply-To: <5476F580020000780004B0E2@mail.emea.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
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/27/2014 03:57 AM, Jan Beulich wrote:
>>>> 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.

I started to make this change and then I realized that the next patch 
(12/21) is actually already taking care of this problem: most of the 
*_vpmu_initialise() will be executed as initcalls during host boot and 
if any of those fail then we do want to disable VPMU globally (those 
failures would not be VCPU-specific).

-boris




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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:12:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGHU-0001p6-G3; Wed, 03 Dec 2014 20:12:12 +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 1XwGHS-0001p1-Qx
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 20:12:10 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	0F/2F-11608-99E6F745; Wed, 03 Dec 2014 20:12:09 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417637527!10875207!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4024 invoked from network); 3 Dec 2014 20:12:09 -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; 3 Dec 2014 20:12:09 -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 sB3KBxaj030579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:12:01 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
	sB3KBvPw023605
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 20:11:58 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
	sB3KBurm020143; Wed, 3 Dec 2014 20:11:56 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 ; Wed, 03 Dec 2014 12:11:56 -0800
Message-ID: <547F6EF3.5080304@oracle.com>
Date: Wed, 03 Dec 2014 15:13: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: 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>
	<5475E46B.9000502@oracle.com>
	<5476F580020000780004B0E2@mail.emea.novell.com>
In-Reply-To: <5476F580020000780004B0E2@mail.emea.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
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/27/2014 03:57 AM, Jan Beulich wrote:
>>>> 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.

I started to make this change and then I realized that the next patch 
(12/21) is actually already taking care of this problem: most of the 
*_vpmu_initialise() will be executed as initcalls during host boot and 
if any of those fail then we do want to disable VPMU globally (those 
failures would not be VCPU-specific).

-boris




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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:27:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGWP-0002Ke-6S; Wed, 03 Dec 2014 20:27:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XwGWO-0002KZ-6h
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 20:27:36 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	42/F0-03148-7327F745; Wed, 03 Dec 2014 20:27:35 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417638453!12827313!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20384 invoked from network); 3 Dec 2014 20:27:34 -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 Dec 2014 20:27: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 sB3KRN30017744
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:27:24 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
	sB3KRJfv019204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 20:27:19 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
	sB3KRITF012200; Wed, 3 Dec 2014 20:27:18 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 ; Wed, 03 Dec 2014 12:27:18 -0800
Message-ID: <547F728E.7030907@oracle.com>
Date: Wed, 03 Dec 2014 15:29:02 -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>
	<5475E610.2020707@oracle.com>
	<5476F5FE020000780004B0E5@mail.emea.novell.com>
In-Reply-To: <5476F5FE020000780004B0E5@mail.emea.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
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/27/2014 03:59 AM, Jan Beulich wrote:
>>>> 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?


Yes, I think it may be better. Let the caller sort out how to interpret it.

-boris


>> 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 Wed Dec 03 20:27:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGWP-0002Ke-6S; Wed, 03 Dec 2014 20:27:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XwGWO-0002KZ-6h
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 20:27:36 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	42/F0-03148-7327F745; Wed, 03 Dec 2014 20:27:35 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417638453!12827313!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20384 invoked from network); 3 Dec 2014 20:27:34 -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 Dec 2014 20:27: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 sB3KRN30017744
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:27:24 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
	sB3KRJfv019204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 20:27:19 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
	sB3KRITF012200; Wed, 3 Dec 2014 20:27:18 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 ; Wed, 03 Dec 2014 12:27:18 -0800
Message-ID: <547F728E.7030907@oracle.com>
Date: Wed, 03 Dec 2014 15:29:02 -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>
	<5475E610.2020707@oracle.com>
	<5476F5FE020000780004B0E5@mail.emea.novell.com>
In-Reply-To: <5476F5FE020000780004B0E5@mail.emea.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
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/27/2014 03:59 AM, Jan Beulich wrote:
>>>> 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?


Yes, I think it may be better. Let the caller sort out how to interpret it.

-boris


>> 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 Wed Dec 03 20:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGZi-0002TG-Lq; Wed, 03 Dec 2014 20:31:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XwGZg-0002ST-Fn
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 20:31:00 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C8/37-22737-3037F745; Wed, 03 Dec 2014 20:30:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417638657!11385124!1
X-Originating-IP: [156.151.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 18172 invoked from network); 3 Dec 2014 20:30:59 -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; 3 Dec 2014 20:30: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 sB3KUnjJ009075
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:30:49 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
	sB3KUmE9004649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 20:30:48 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
	sB3KUl6s004586; Wed, 3 Dec 2014 20:30:47 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:30:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1DBDA11B535; Wed,  3 Dec 2014 10:57:45 -0500 (EST)
Date: Wed, 3 Dec 2014 10:57:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141203155744.GE3081@laptop.dumpdata.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
	<1417175443.23604.18.camel@citrix.com>
	<20141202210941.GA1593@laptop.dumpdata.com>
	<1417599529.29004.16.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417599529.29004.16.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, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	tim@xen.org, 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 Wed, Dec 03, 2014 at 09:38:49AM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 28, 2014 at 11:50:43AM +0000, Ian Campbell wrote:
> > > 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...
> > 
> > Jan acked it.
> 
> For 4.5?

Probably not.
> 
> Have you release acked it?

No.
> 
> This seemed like 4.6 material to me, or at least I've not seen any
> mention/argument to the contrary.

Correct. 4.6 please.
> 
> Ian.
> 
> > > 
> > > > ---
> > > >  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
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGZc-0002S5-Pf; Wed, 03 Dec 2014 20:30: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 1XwGZb-0002Rz-LD
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 20:30:55 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	77/AC-02576-FF27F745; Wed, 03 Dec 2014 20:30:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417638652!12799535!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11033 invoked from network); 3 Dec 2014 20:30: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; 3 Dec 2014 20:30:54 -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 sB3KUkM4021578
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:30:47 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
	sB3KUkvG029904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 20:30:46 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
	sB3KUjSs006690; Wed, 3 Dec 2014 20:30:45 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:30:45 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E1D6311B810; Wed,  3 Dec 2014 11:20:27 -0500 (EST)
Date: Wed, 3 Dec 2014 11:20:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141203162027.GG3081@laptop.dumpdata.com>
References: <1417603298-4213-1-git-send-email-wei.liu2@citrix.com>
	<1417603834.11243.9.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417603834.11243.9.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>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: expose #define to 4.5 and
	above
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 10:50:34AM +0000, Ian Campbell wrote:
> On Wed, 2014-12-03 at 10:41 +0000, Wei Liu wrote:
> > In e3abab74 (libxl: un-constify return value of libxl_basename), the
> > macro was exposed to releases < 4.5. However only new code is able to
> > make use of that macro so it should be exposed to releases >= 4.5.
> > 
> > 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: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Konrad, given that the original patch is in 4.5 (as of yesterday) we
> should obviously take this one too.

Right. Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > ---
> >  tools/libxl/libxl.h       |    6 +++---
> >  tools/libxl/libxl_utils.c |    2 +-
> >  tools/libxl/libxl_utils.h |    2 +-
> >  3 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index 291c190..0a123f1 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -478,13 +478,13 @@ typedef struct libxl__ctx libxl_ctx;
> >  #endif
> >  
> >  /*
> > - * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> > + * LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
> >   *
> >   * The return value of libxl_basename is malloc'ed but the erroneously
> >   * marked as "const" in releases before 4.5.
> >   */
> > -#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
> > -#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
> > +#if !defined(LIBXL_API_VERSION) || LIBXL_API_VERSION >= 0x040500
> > +#define LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE 1
> >  #endif
> >  
> >  /*
> > diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> > index 22119fc..7095b58 100644
> > --- a/tools/libxl/libxl_utils.c
> > +++ b/tools/libxl/libxl_utils.c
> > @@ -19,7 +19,7 @@
> >  
> >  #include "libxl_internal.h"
> >  
> > -#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> > +#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
> >  const
> >  #endif
> >  char *libxl_basename(const char *name)
> > diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> > index 8277eb9..acacdd9 100644
> > --- a/tools/libxl/libxl_utils.h
> > +++ b/tools/libxl/libxl_utils.h
> > @@ -18,7 +18,7 @@
> >  
> >  #include "libxl.h"
> >  
> > -#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> > +#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
> >  const
> >  #endif
> >  char *libxl_basename(const char *name); /* returns string from strdup */
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGZg-0002SU-4i; Wed, 03 Dec 2014 20:31:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XwGZe-0002SG-Pp
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 20:30:59 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	26/6F-25727-2037F745; Wed, 03 Dec 2014 20:30:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417638655!10833959!1
X-Originating-IP: [156.151.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 5023 invoked from network); 3 Dec 2014 20:30:57 -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; 3 Dec 2014 20:30:57 -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 sB3KUotS009095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:30:51 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
	sB3KUlTa006770
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 20:30:50 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
	sB3KUkiF004557; Wed, 3 Dec 2014 20:30:47 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:30:46 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id ABEC811B521; Wed,  3 Dec 2014 10:52:08 -0500 (EST)
Date: Wed, 3 Dec 2014 10:52:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141203155208.GC3081@laptop.dumpdata.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
	<1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
	<547E4736.5000303@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547E4736.5000303@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: bhelgaas@google.com, xen-devel@lists.xenproject.org, linux@eikelenboom.it,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 06:11:50PM -0500, Boris Ostrovsky wrote:
> On 11/21/2014 05:17 PM, Konrad Rzeszutek Wilk wrote:
> >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.
> 
> 
> Doesn't this all mean that patch 1/7 broke pcistub_put_pci_dev()?

It fixed it (there was a deadlock there).

But the fix to the dead-lock exposed this bug.

One could say that 1/7 broke it because it never worked in the
first place, but now that it works (thanks to #1)  - it did not
work right?

Squashing the patches together is a bit too much I fear.

> 
> -boris
> 
> 
> >
> >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);
> 

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGZh-0002T4-H1; Wed, 03 Dec 2014 20:31: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 1XwGZg-0002SQ-5M
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 20:31:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AA/B9-09842-3037F745; Wed, 03 Dec 2014 20:30:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417638657!13255621!1
X-Originating-IP: [156.151.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 9997 invoked from network); 3 Dec 2014 20:30:58 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 20:30:58 -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 sB3KUnb8009079
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:30:50 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
	sB3KUmEp000054
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 20:30:49 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
	sB3KUlqu004602; Wed, 3 Dec 2014 20:30:48 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:30:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 540D011B532; Wed,  3 Dec 2014 10:57:13 -0500 (EST)
Date: Wed, 3 Dec 2014 10:57:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141203155713.GD3081@laptop.dumpdata.com>
References: <1417596754-14063-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417596754-14063-1-git-send-email-olaf@aepfle.de>
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>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] INSTALL: fix typo in xendomains.service name
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 09:52:34AM +0100, Olaf Hering wrote:
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  INSTALL | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This being a doc it can go in anytime. thank you!
> 
> diff --git a/INSTALL b/INSTALL
> index 0bc67ea..71dd0eb 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -284,7 +284,7 @@ systemctl enable xen-init-dom0.service
>  systemctl enable xenconsoled.service
>  
>  Other optional services are:
> -systemctl enable xen-domains.service
> +systemctl enable xendomains.service
>  systemctl enable xen-watchdog.service
>  
>  

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGZi-0002TG-Lq; Wed, 03 Dec 2014 20:31:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XwGZg-0002ST-Fn
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 20:31:00 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C8/37-22737-3037F745; Wed, 03 Dec 2014 20:30:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417638657!11385124!1
X-Originating-IP: [156.151.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 18172 invoked from network); 3 Dec 2014 20:30:59 -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; 3 Dec 2014 20:30: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 sB3KUnjJ009075
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:30:49 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
	sB3KUmE9004649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 20:30:48 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
	sB3KUl6s004586; Wed, 3 Dec 2014 20:30:47 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:30:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1DBDA11B535; Wed,  3 Dec 2014 10:57:45 -0500 (EST)
Date: Wed, 3 Dec 2014 10:57:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141203155744.GE3081@laptop.dumpdata.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
	<1417175443.23604.18.camel@citrix.com>
	<20141202210941.GA1593@laptop.dumpdata.com>
	<1417599529.29004.16.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417599529.29004.16.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, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com, Liang Li <liang.z.li@intel.com>,
	tim@xen.org, 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 Wed, Dec 03, 2014 at 09:38:49AM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 28, 2014 at 11:50:43AM +0000, Ian Campbell wrote:
> > > 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...
> > 
> > Jan acked it.
> 
> For 4.5?

Probably not.
> 
> Have you release acked it?

No.
> 
> This seemed like 4.6 material to me, or at least I've not seen any
> mention/argument to the contrary.

Correct. 4.6 please.
> 
> Ian.
> 
> > > 
> > > > ---
> > > >  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
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGZc-0002S5-Pf; Wed, 03 Dec 2014 20:30: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 1XwGZb-0002Rz-LD
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 20:30:55 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	77/AC-02576-FF27F745; Wed, 03 Dec 2014 20:30:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417638652!12799535!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11033 invoked from network); 3 Dec 2014 20:30: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; 3 Dec 2014 20:30:54 -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 sB3KUkM4021578
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:30:47 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
	sB3KUkvG029904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 20:30:46 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
	sB3KUjSs006690; Wed, 3 Dec 2014 20:30:45 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:30:45 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E1D6311B810; Wed,  3 Dec 2014 11:20:27 -0500 (EST)
Date: Wed, 3 Dec 2014 11:20:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141203162027.GG3081@laptop.dumpdata.com>
References: <1417603298-4213-1-git-send-email-wei.liu2@citrix.com>
	<1417603834.11243.9.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417603834.11243.9.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>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: expose #define to 4.5 and
	above
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 10:50:34AM +0000, Ian Campbell wrote:
> On Wed, 2014-12-03 at 10:41 +0000, Wei Liu wrote:
> > In e3abab74 (libxl: un-constify return value of libxl_basename), the
> > macro was exposed to releases < 4.5. However only new code is able to
> > make use of that macro so it should be exposed to releases >= 4.5.
> > 
> > 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: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Konrad, given that the original patch is in 4.5 (as of yesterday) we
> should obviously take this one too.

Right. Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > ---
> >  tools/libxl/libxl.h       |    6 +++---
> >  tools/libxl/libxl_utils.c |    2 +-
> >  tools/libxl/libxl_utils.h |    2 +-
> >  3 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index 291c190..0a123f1 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -478,13 +478,13 @@ typedef struct libxl__ctx libxl_ctx;
> >  #endif
> >  
> >  /*
> > - * LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> > + * LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
> >   *
> >   * The return value of libxl_basename is malloc'ed but the erroneously
> >   * marked as "const" in releases before 4.5.
> >   */
> > -#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
> > -#define LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE 1
> > +#if !defined(LIBXL_API_VERSION) || LIBXL_API_VERSION >= 0x040500
> > +#define LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE 1
> >  #endif
> >  
> >  /*
> > diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> > index 22119fc..7095b58 100644
> > --- a/tools/libxl/libxl_utils.c
> > +++ b/tools/libxl/libxl_utils.c
> > @@ -19,7 +19,7 @@
> >  
> >  #include "libxl_internal.h"
> >  
> > -#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> > +#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
> >  const
> >  #endif
> >  char *libxl_basename(const char *name)
> > diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> > index 8277eb9..acacdd9 100644
> > --- a/tools/libxl/libxl_utils.h
> > +++ b/tools/libxl/libxl_utils.h
> > @@ -18,7 +18,7 @@
> >  
> >  #include "libxl.h"
> >  
> > -#ifdef LIBXL_HAVE_CONST_LIBXL_BASENAME_RETURN_VALUE
> > +#ifndef LIBXL_HAVE_NONCONST_LIBXL_BASENAME_RETURN_VALUE
> >  const
> >  #endif
> >  char *libxl_basename(const char *name); /* returns string from strdup */
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGZh-0002T4-H1; Wed, 03 Dec 2014 20:31: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 1XwGZg-0002SQ-5M
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 20:31:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AA/B9-09842-3037F745; Wed, 03 Dec 2014 20:30:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417638657!13255621!1
X-Originating-IP: [156.151.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 9997 invoked from network); 3 Dec 2014 20:30:58 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 20:30:58 -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 sB3KUnb8009079
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:30:50 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
	sB3KUmEp000054
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 20:30:49 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
	sB3KUlqu004602; Wed, 3 Dec 2014 20:30:48 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:30:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 540D011B532; Wed,  3 Dec 2014 10:57:13 -0500 (EST)
Date: Wed, 3 Dec 2014 10:57:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141203155713.GD3081@laptop.dumpdata.com>
References: <1417596754-14063-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417596754-14063-1-git-send-email-olaf@aepfle.de>
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>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] INSTALL: fix typo in xendomains.service name
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 09:52:34AM +0100, Olaf Hering wrote:
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  INSTALL | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This being a doc it can go in anytime. thank you!
> 
> diff --git a/INSTALL b/INSTALL
> index 0bc67ea..71dd0eb 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -284,7 +284,7 @@ systemctl enable xen-init-dom0.service
>  systemctl enable xenconsoled.service
>  
>  Other optional services are:
> -systemctl enable xen-domains.service
> +systemctl enable xendomains.service
>  systemctl enable xen-watchdog.service
>  
>  

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGZg-0002SU-4i; Wed, 03 Dec 2014 20:31:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XwGZe-0002SG-Pp
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 20:30:59 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	26/6F-25727-2037F745; Wed, 03 Dec 2014 20:30:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417638655!10833959!1
X-Originating-IP: [156.151.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 5023 invoked from network); 3 Dec 2014 20:30:57 -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; 3 Dec 2014 20:30:57 -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 sB3KUotS009095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:30:51 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
	sB3KUlTa006770
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 20:30:50 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
	sB3KUkiF004557; Wed, 3 Dec 2014 20:30:47 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:30:46 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id ABEC811B521; Wed,  3 Dec 2014 10:52:08 -0500 (EST)
Date: Wed, 3 Dec 2014 10:52:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141203155208.GC3081@laptop.dumpdata.com>
References: <1416608271-18931-1-git-send-email-konrad.wilk@oracle.com>
	<1416608271-18931-8-git-send-email-konrad.wilk@oracle.com>
	<547E4736.5000303@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <547E4736.5000303@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: bhelgaas@google.com, xen-devel@lists.xenproject.org, linux@eikelenboom.it,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 06:11:50PM -0500, Boris Ostrovsky wrote:
> On 11/21/2014 05:17 PM, Konrad Rzeszutek Wilk wrote:
> >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.
> 
> 
> Doesn't this all mean that patch 1/7 broke pcistub_put_pci_dev()?

It fixed it (there was a deadlock there).

But the fix to the dead-lock exposed this bug.

One could say that 1/7 broke it because it never worked in the
first place, but now that it works (thanks to #1)  - it did not
work right?

Squashing the patches together is a bit too much I fear.

> 
> -boris
> 
> 
> >
> >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);
> 

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:31:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20:31:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwGZx-0002Ze-7I; Wed, 03 Dec 2014 20:31:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XwGZu-0002Yk-Qw
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 20:31:14 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5C/D9-09842-2137F745; Wed, 03 Dec 2014 20:31:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417638672!13173683!1
X-Originating-IP: [156.151.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 8115 invoked from network); 3 Dec 2014 20:31:13 -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; 3 Dec 2014 20:31: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 sB3KUl4T009065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:30:48 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
	sB3KUkJJ029916
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 20:30:46 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
	sB3KUkMN029906; Wed, 3 Dec 2014 20:30:46 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:30:45 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id AAC5D11EB88; Wed,  3 Dec 2014 11:54:10 -0500 (EST)
Date: Wed, 3 Dec 2014 11:54:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141203165410.GA2819@laptop.dumpdata.com>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Olaf Hering <olaf@aepfle.de>, 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.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 06:51:50PM +0000, M A Young wrote:
> On Tue, 2 Dec 2014, Konrad Rzeszutek Wilk wrote:
> 
> >On Tue, Dec 02, 2014 at 03:44:55PM +0000, Ian Campbell wrote:
> >>On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
> >>>Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
> >>>systemd xenstored dependencies") all service files use the .socket unit
> >>>as startup dependency. While this happens to work for boot it fails for
> >>>shutdown because a .socket does not seem to enforce ordering. When
> >>>xendomains.service runs during shutdown then systemd will stop
> >>>xenstored.service at the same time.
> >>>
> >>>Change all "xenstored.socket" to "xenstored.service" to let systemd know
> >>>that xenstored has to be shutdown after everything else.
> >>>
> >>>Reported-by: Mark Pryor <tlviewer@yahoo.com>
> >>>Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >>>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >>>Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>
> >>Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >>
> >>>Cc: Wei Liu <wei.liu2@citrix.com>
> >>>---
> >>>
> >>>This should go into 4.5 to fix xendomains.service.
> >>
> >>CCing Konrad...
> >
> >CC-ing Michael.
> >
> >Michael, since Fedora is using systemd, did you observe this bug as well?
> >(I think I did, but I might have blamed it on my wacky setup).
> 
> I only tried the xen systemd on xen 4.5-rc2 and didn't have a lot of success
> even when I reverted to Fedora's systemd for xen, so I can't really comment.
> I did have issues with xen systemd which I shall report if they are still
> there in -rc3.

It seems that hte issue I am having is:

ELinux: security_context_to_sid($XENSTORED_MOUNT_CTX) failed for (dev tmpfs, type tmpfs) er
Dec 03 11:46:07 laptop.dumpdata.com systemd[1]: var-lib-xenstored.mount mount process exited, code=exited status=32
Dec 03 11:46:07 laptop.dumpdata.com systemd[1]: Failed to mount mount xenstore file system.

Which looks like so:

[root@laptop system]# more var-lib-xenstored.mount 
[Unit]
Description=mount xenstore file system
Requires=proc-xen.mount
After=proc-xen.mount
ConditionPathExists=/proc/xen/capabilities
RefuseManualStop=true

[Mount]
Environment=XENSTORED_MOUNT_CTX=none
EnvironmentFile=-/etc/sysconfig/xenstored
What=xenstore
Where=/var/lib/xenstored
Type=tmpfs
Options=mode=755,context="$XENSTORED_MOUNT_CTX"


There is no /etc/sysconfig/xenstored (there is an oxenstored.conf)

If I alter it:

Options=mode=755
#,context="$XENSTORED_MOUNT_CTX"

It starts.
> 
> 	Michael Young

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:31:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20:31:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwGZx-0002Ze-7I; Wed, 03 Dec 2014 20:31:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XwGZu-0002Yk-Qw
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 20:31:14 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5C/D9-09842-2137F745; Wed, 03 Dec 2014 20:31:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417638672!13173683!1
X-Originating-IP: [156.151.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 8115 invoked from network); 3 Dec 2014 20:31:13 -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; 3 Dec 2014 20:31: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 sB3KUl4T009065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:30:48 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
	sB3KUkJJ029916
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 20:30:46 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
	sB3KUkMN029906; Wed, 3 Dec 2014 20:30:46 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:30:45 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id AAC5D11EB88; Wed,  3 Dec 2014 11:54:10 -0500 (EST)
Date: Wed, 3 Dec 2014 11:54:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141203165410.GA2819@laptop.dumpdata.com>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Olaf Hering <olaf@aepfle.de>, 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.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 06:51:50PM +0000, M A Young wrote:
> On Tue, 2 Dec 2014, Konrad Rzeszutek Wilk wrote:
> 
> >On Tue, Dec 02, 2014 at 03:44:55PM +0000, Ian Campbell wrote:
> >>On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
> >>>Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
> >>>systemd xenstored dependencies") all service files use the .socket unit
> >>>as startup dependency. While this happens to work for boot it fails for
> >>>shutdown because a .socket does not seem to enforce ordering. When
> >>>xendomains.service runs during shutdown then systemd will stop
> >>>xenstored.service at the same time.
> >>>
> >>>Change all "xenstored.socket" to "xenstored.service" to let systemd know
> >>>that xenstored has to be shutdown after everything else.
> >>>
> >>>Reported-by: Mark Pryor <tlviewer@yahoo.com>
> >>>Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >>>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >>>Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>
> >>Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >>
> >>>Cc: Wei Liu <wei.liu2@citrix.com>
> >>>---
> >>>
> >>>This should go into 4.5 to fix xendomains.service.
> >>
> >>CCing Konrad...
> >
> >CC-ing Michael.
> >
> >Michael, since Fedora is using systemd, did you observe this bug as well?
> >(I think I did, but I might have blamed it on my wacky setup).
> 
> I only tried the xen systemd on xen 4.5-rc2 and didn't have a lot of success
> even when I reverted to Fedora's systemd for xen, so I can't really comment.
> I did have issues with xen systemd which I shall report if they are still
> there in -rc3.

It seems that hte issue I am having is:

ELinux: security_context_to_sid($XENSTORED_MOUNT_CTX) failed for (dev tmpfs, type tmpfs) er
Dec 03 11:46:07 laptop.dumpdata.com systemd[1]: var-lib-xenstored.mount mount process exited, code=exited status=32
Dec 03 11:46:07 laptop.dumpdata.com systemd[1]: Failed to mount mount xenstore file system.

Which looks like so:

[root@laptop system]# more var-lib-xenstored.mount 
[Unit]
Description=mount xenstore file system
Requires=proc-xen.mount
After=proc-xen.mount
ConditionPathExists=/proc/xen/capabilities
RefuseManualStop=true

[Mount]
Environment=XENSTORED_MOUNT_CTX=none
EnvironmentFile=-/etc/sysconfig/xenstored
What=xenstore
Where=/var/lib/xenstored
Type=tmpfs
Options=mode=755,context="$XENSTORED_MOUNT_CTX"


There is no /etc/sysconfig/xenstored (there is an oxenstored.conf)

If I alter it:

Options=mode=755
#,context="$XENSTORED_MOUNT_CTX"

It starts.
> 
> 	Michael Young

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:37:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGfb-0003FP-Ap; Wed, 03 Dec 2014 20:37:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XwGfZ-0003FK-PL
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 20:37:05 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DA/4D-09842-1747F745; Wed, 03 Dec 2014 20:37:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417639023!13212732!1
X-Originating-IP: [156.151.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 26819 invoked from network); 3 Dec 2014 20:37:04 -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; 3 Dec 2014 20:37:04 -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 sB3KaHOh015626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:36:17 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
	sB3KaFAD009371
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 20:36:16 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
	sB3KaFkq024194; Wed, 3 Dec 2014 20:36:15 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:36:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id AAA1B11EDD3; Wed,  3 Dec 2014 15:36:16 -0500 (EST)
Date: Wed, 3 Dec 2014 15:36:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>, abe@debian.org,
	pkg-xen-devel@lists.alioth.debian.org
Message-ID: <20141203203616.GA8802@laptop.dumpdata.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
	<20141202183620.GE32385@laptop.dumpdata.com>
	<20141203155353.GN16236@olila.local.net-space.pl>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141203155353.GN16236@olila.local.net-space.pl>
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,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
 target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 04:53:53PM +0100, Daniel Kiper wrote:
> On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> > > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> >
> > This usage scenario which I can see this being useful (and
> > I've tripped over this) is when you rebuild a new version
> > from the same repo. As in, this affects developers, but
> > not end-users and not distros. But perhaps I am missing
> > one scenario?
> >
> > As such I would lean towards deferring this (and the other
> > two) to Xen 4.6.
> 
> As I know Debian build system sometimes complain if make distclean
> does not leave build tree in distclean state (read "state before
> configure" != "state after distclean"). It means that from
> distros point of view we should apply this patch. However,
> other two are not required and we can deffer them to Xen 4.6.

Cc-ing Axel and Debian Xen Team.
> 
> Daniel

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:37:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20: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 1XwGfb-0003FP-Ap; Wed, 03 Dec 2014 20:37:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XwGfZ-0003FK-PL
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 20:37:05 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DA/4D-09842-1747F745; Wed, 03 Dec 2014 20:37:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417639023!13212732!1
X-Originating-IP: [156.151.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 26819 invoked from network); 3 Dec 2014 20:37:04 -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; 3 Dec 2014 20:37:04 -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 sB3KaHOh015626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:36:17 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
	sB3KaFAD009371
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 20:36:16 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
	sB3KaFkq024194; Wed, 3 Dec 2014 20:36:15 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:36:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id AAA1B11EDD3; Wed,  3 Dec 2014 15:36:16 -0500 (EST)
Date: Wed, 3 Dec 2014 15:36:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>, abe@debian.org,
	pkg-xen-devel@lists.alioth.debian.org
Message-ID: <20141203203616.GA8802@laptop.dumpdata.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
	<20141202183620.GE32385@laptop.dumpdata.com>
	<20141203155353.GN16236@olila.local.net-space.pl>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141203155353.GN16236@olila.local.net-space.pl>
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,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
 target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 04:53:53PM +0100, Daniel Kiper wrote:
> On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> > > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> >
> > This usage scenario which I can see this being useful (and
> > I've tripped over this) is when you rebuild a new version
> > from the same repo. As in, this affects developers, but
> > not end-users and not distros. But perhaps I am missing
> > one scenario?
> >
> > As such I would lean towards deferring this (and the other
> > two) to Xen 4.6.
> 
> As I know Debian build system sometimes complain if make distclean
> does not leave build tree in distclean state (read "state before
> configure" != "state after distclean"). It means that from
> distros point of view we should apply this patch. However,
> other two are not required and we can deffer them to Xen 4.6.

Cc-ing Axel and Debian Xen Team.
> 
> Daniel

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:38:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwGh0-0003OC-Px; Wed, 03 Dec 2014 20:38: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 1XwGgz-0003O4-2V
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 20:38:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FD/0E-09842-8C47F745; Wed, 03 Dec 2014 20:38:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417639110!5198011!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12173 invoked from network); 3 Dec 2014 20:38:31 -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; 3 Dec 2014 20:38: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 sB3KcPwq031019
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:38: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
	sB3KcOo3027251
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 20:38:25 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
	sB3KcOFp027191; Wed, 3 Dec 2014 20:38:24 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:38:23 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4B2AC11EDDC; Wed,  3 Dec 2014 15:38:25 -0500 (EST)
Date: Wed, 3 Dec 2014 15:38:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141203203825.GB8802@laptop.dumpdata.com>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
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>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 Wed, Dec 03, 2014 at 04:04:20PM +0000, David Vrabel wrote:
> The default limit for the number of PIRQs for hardware domains (dom0)
> is not sufficient for some (x86) systems.
> 
> Since the pirq structures are individually and dynamically allocated,
> the limit for hardware domains may be increased to the number of
> possible IRQs.

Why not also expand the number for the guest?
> 
> The extra_guest_irqs command line option now only allows changes to
> the domU value.  Any argument for dom0 is ignored.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  docs/misc/xen-command-line.markdown |   11 ++++-------
>  xen/common/domain.c                 |    7 +------
>  2 files changed, 5 insertions(+), 13 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> index 0866df2..d352031 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -594,15 +594,12 @@ except for debugging purposes.
>  Force or disable use of EFI runtime services.
>  
>  ### extra\_guest\_irqs
> -> `= [<domU number>][,<dom0 number>]`
> +> `= [<number>]`
>  
> -> Default: `32,256`
> +> Default: `32`
>  
> -Change the number of PIRQs available for guests.  The optional first number is
> -common for all domUs, while the optional second number (preceded by a comma)
> -is for dom0.  Changing the setting for domU has no impact on dom0 and vice
> -versa.  For example to change dom0 without changing domU, use
> -`extra_guest_irqs=,512`
> +Change the number of PIRQs available for guests. This limit does not
> +apply to hardware domains (dom0).
>  
>  ### flask\_enabled
>  > `= <integer>`
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 4a62c1d..a88d829 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -231,14 +231,11 @@ static int late_hwdom_init(struct domain *d)
>  #endif
>  }
>  
> -static unsigned int __read_mostly extra_dom0_irqs = 256;
>  static unsigned int __read_mostly extra_domU_irqs = 32;
>  static void __init parse_extra_guest_irqs(const char *s)
>  {
>      if ( isdigit(*s) )
>          extra_domU_irqs = simple_strtoul(s, &s, 0);
> -    if ( *s == ',' && isdigit(*++s) )
> -        extra_dom0_irqs = simple_strtoul(s, &s, 0);
>  }
>  custom_param("extra_guest_irqs", parse_extra_guest_irqs);
>  
> @@ -324,10 +321,8 @@ struct domain *domain_create(
>          atomic_inc(&d->pause_count);
>  
>          if ( !is_hardware_domain(d) )
> -            d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
> +            d->nr_pirqs = min(nr_static_irqs + extra_domU_irqs, nr_irqs);
>          else
> -            d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
> -        if ( d->nr_pirqs > nr_irqs )
>              d->nr_pirqs = nr_irqs;
>  
>          radix_tree_init(&d->pirq_tree);
> -- 
> 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 Dec 03 20:38:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwGh0-0003OC-Px; Wed, 03 Dec 2014 20:38: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 1XwGgz-0003O4-2V
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 20:38:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FD/0E-09842-8C47F745; Wed, 03 Dec 2014 20:38:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417639110!5198011!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12173 invoked from network); 3 Dec 2014 20:38:31 -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; 3 Dec 2014 20:38: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 sB3KcPwq031019
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:38: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
	sB3KcOo3027251
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 20:38:25 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
	sB3KcOFp027191; Wed, 3 Dec 2014 20:38:24 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:38:23 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4B2AC11EDDC; Wed,  3 Dec 2014 15:38:25 -0500 (EST)
Date: Wed, 3 Dec 2014 15:38:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141203203825.GB8802@laptop.dumpdata.com>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
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>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 Wed, Dec 03, 2014 at 04:04:20PM +0000, David Vrabel wrote:
> The default limit for the number of PIRQs for hardware domains (dom0)
> is not sufficient for some (x86) systems.
> 
> Since the pirq structures are individually and dynamically allocated,
> the limit for hardware domains may be increased to the number of
> possible IRQs.

Why not also expand the number for the guest?
> 
> The extra_guest_irqs command line option now only allows changes to
> the domU value.  Any argument for dom0 is ignored.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  docs/misc/xen-command-line.markdown |   11 ++++-------
>  xen/common/domain.c                 |    7 +------
>  2 files changed, 5 insertions(+), 13 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> index 0866df2..d352031 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -594,15 +594,12 @@ except for debugging purposes.
>  Force or disable use of EFI runtime services.
>  
>  ### extra\_guest\_irqs
> -> `= [<domU number>][,<dom0 number>]`
> +> `= [<number>]`
>  
> -> Default: `32,256`
> +> Default: `32`
>  
> -Change the number of PIRQs available for guests.  The optional first number is
> -common for all domUs, while the optional second number (preceded by a comma)
> -is for dom0.  Changing the setting for domU has no impact on dom0 and vice
> -versa.  For example to change dom0 without changing domU, use
> -`extra_guest_irqs=,512`
> +Change the number of PIRQs available for guests. This limit does not
> +apply to hardware domains (dom0).
>  
>  ### flask\_enabled
>  > `= <integer>`
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 4a62c1d..a88d829 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -231,14 +231,11 @@ static int late_hwdom_init(struct domain *d)
>  #endif
>  }
>  
> -static unsigned int __read_mostly extra_dom0_irqs = 256;
>  static unsigned int __read_mostly extra_domU_irqs = 32;
>  static void __init parse_extra_guest_irqs(const char *s)
>  {
>      if ( isdigit(*s) )
>          extra_domU_irqs = simple_strtoul(s, &s, 0);
> -    if ( *s == ',' && isdigit(*++s) )
> -        extra_dom0_irqs = simple_strtoul(s, &s, 0);
>  }
>  custom_param("extra_guest_irqs", parse_extra_guest_irqs);
>  
> @@ -324,10 +321,8 @@ struct domain *domain_create(
>          atomic_inc(&d->pause_count);
>  
>          if ( !is_hardware_domain(d) )
> -            d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
> +            d->nr_pirqs = min(nr_static_irqs + extra_domU_irqs, nr_irqs);
>          else
> -            d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
> -        if ( d->nr_pirqs > nr_irqs )
>              d->nr_pirqs = nr_irqs;
>  
>          radix_tree_init(&d->pirq_tree);
> -- 
> 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 Dec 03 20:41:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20:41:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwGjs-0003Yj-CR; Wed, 03 Dec 2014 20:41: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 1XwGjq-0003YY-MC
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 20:41:30 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	07/88-15461-A757F745; Wed, 03 Dec 2014 20:41:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417639288!13213244!1
X-Originating-IP: [156.151.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 10354 invoked from network); 3 Dec 2014 20:41:29 -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; 3 Dec 2014 20:41:29 -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 sB3KfLZg022327
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:41:21 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
	sB3KfKqC006004
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 20:41:20 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
	sB3KfJco003246; Wed, 3 Dec 2014 20:41:19 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:41:19 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 78FDF11EDED; Wed,  3 Dec 2014 15:41:21 -0500 (EST)
Date: Wed, 3 Dec 2014 15:41:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141203204121.GA9287@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1412031818180.30971@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1412031818180.30971@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, dslutz@verizon.com
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl_set_memory_target: only
 remove videoram from absolute targets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 06:20:41PM +0000, Stefano Stabellini wrote:
> If the new target is relative to the current target, do not remove
> videoram again: it has already been removed from the current target.

Please explain:
 - Is this an regression?
 - How often does it occur?
 - Is it fatal?
 - Are there work-arounds?

Thanks!
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..2aa83bd 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4741,13 +4741,17 @@ retry_transaction:
>          goto out;
>      }
>  
> +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> +                "%s/memory/videoram", dompath));
> +    videoram = videoram_s ? atoi(videoram_s) : 0;
> +
>      if (relative) {
>          if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
>              new_target_memkb = 0;
>          else
>              new_target_memkb = current_target_memkb + target_memkb;
>      } else
> -        new_target_memkb = target_memkb;
> +        new_target_memkb = target_memkb - videoram;
>      if (new_target_memkb > memorykb) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                  "memory_dynamic_max must be less than or equal to"
> @@ -4763,9 +4767,6 @@ retry_transaction:
>          abort_transaction = 1;
>          goto out;
>      }
> -    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> -                "%s/memory/videoram", dompath));
> -    videoram = videoram_s ? atoi(videoram_s) : 0;
>  
>      if (enforce) {
>          memorykb = new_target_memkb;
> @@ -4780,7 +4781,6 @@ retry_transaction:
>          }
>      }
>  
> -    new_target_memkb -= videoram;
>      rc = xc_domain_set_pod_target(ctx->xch, domid,
>              new_target_memkb / 4, NULL, NULL, NULL);
>      if (rc != 0) {

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 20:41:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 20:41:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwGjs-0003Yj-CR; Wed, 03 Dec 2014 20:41: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 1XwGjq-0003YY-MC
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 20:41:30 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	07/88-15461-A757F745; Wed, 03 Dec 2014 20:41:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417639288!13213244!1
X-Originating-IP: [156.151.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 10354 invoked from network); 3 Dec 2014 20:41:29 -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; 3 Dec 2014 20:41:29 -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 sB3KfLZg022327
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 20:41:21 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
	sB3KfKqC006004
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 20:41:20 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
	sB3KfJco003246; Wed, 3 Dec 2014 20:41:19 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 12:41:19 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 78FDF11EDED; Wed,  3 Dec 2014 15:41:21 -0500 (EST)
Date: Wed, 3 Dec 2014 15:41:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141203204121.GA9287@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1412031818180.30971@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1412031818180.30971@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, dslutz@verizon.com
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl_set_memory_target: only
 remove videoram from absolute targets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 06:20:41PM +0000, Stefano Stabellini wrote:
> If the new target is relative to the current target, do not remove
> videoram again: it has already been removed from the current target.

Please explain:
 - Is this an regression?
 - How often does it occur?
 - Is it fatal?
 - Are there work-arounds?

Thanks!
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..2aa83bd 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4741,13 +4741,17 @@ retry_transaction:
>          goto out;
>      }
>  
> +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> +                "%s/memory/videoram", dompath));
> +    videoram = videoram_s ? atoi(videoram_s) : 0;
> +
>      if (relative) {
>          if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
>              new_target_memkb = 0;
>          else
>              new_target_memkb = current_target_memkb + target_memkb;
>      } else
> -        new_target_memkb = target_memkb;
> +        new_target_memkb = target_memkb - videoram;
>      if (new_target_memkb > memorykb) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                  "memory_dynamic_max must be less than or equal to"
> @@ -4763,9 +4767,6 @@ retry_transaction:
>          abort_transaction = 1;
>          goto out;
>      }
> -    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> -                "%s/memory/videoram", dompath));
> -    videoram = videoram_s ? atoi(videoram_s) : 0;
>  
>      if (enforce) {
>          memorykb = new_target_memkb;
> @@ -4780,7 +4781,6 @@ retry_transaction:
>          }
>      }
>  
> -    new_target_memkb -= videoram;
>      rc = xc_domain_set_pod_target(ctx->xch, domid,
>              new_target_memkb / 4, NULL, NULL, NULL);
>      if (rc != 0) {

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:03:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:03:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwH4P-0004Ay-AJ; Wed, 03 Dec 2014 21:02:45 +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 1XwH4N-0004Ad-Pm
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:02:43 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	56/B7-25547-27A7F745; Wed, 03 Dec 2014 21:02:42 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417640560!10902839!1
X-Originating-IP: [156.151.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 17649 invoked from network); 3 Dec 2014 21:02:42 -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; 3 Dec 2014 21:02:42 -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 sB3L2XHc014389
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:02:34 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
	sB3L2Wrv009067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:02: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
	sB3L2Vrq012555; Wed, 3 Dec 2014 21:02:31 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:02:30 -0800
Date: Wed, 3 Dec 2014 22:02:25 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: andrew.cooper3@citrix.com, ian.campbell@citrix.com, jbeulich@suse.com,
	konrad.wilk@oracle.com, keir@xen.org, roy.franz@linaro.org,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xenproject.org
Message-ID: <20141203210225.GR16236@olila.local.net-space.pl>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey,

1) Why is there in EFI code so many functions (e.g. efi_start(),
   efi_arch_edd(), ...) with local variables declared as a static?
   Though some of them have also regular local variables. I do not
   why it was decided that some of them must be the static and
   some of do not. It is a bit confusing. As I can see there is
   only one place which have to have local static (place_string()).
   Other seems to me as thing to save space on the stack but I do
   not think we need that. According to UEFI spec there will be
   "128 KiB or more of available stack space" when system runs in
   boot services mode. It is a lot of space. So, I think we can
   safely convert most of local static variables to normal local
   variables. Am I right?

2) I am going to add EDID support to EFI code. Should it be x86
   specific code or common one? As I can see EDID is defined as
   part of GOP so I think that EDID code should be placed in
   xen/common/efi/boot.c.

3) Should not we change xen/arch/*/efi/efi-boot.h to
   xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
   code than definitions, declarations and short static
   functions. So, I think that it is more regular *.c file
   than header file.

Daniel

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:03:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:03:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwH4P-0004Ay-AJ; Wed, 03 Dec 2014 21:02:45 +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 1XwH4N-0004Ad-Pm
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:02:43 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	56/B7-25547-27A7F745; Wed, 03 Dec 2014 21:02:42 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417640560!10902839!1
X-Originating-IP: [156.151.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 17649 invoked from network); 3 Dec 2014 21:02:42 -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; 3 Dec 2014 21:02:42 -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 sB3L2XHc014389
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:02:34 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
	sB3L2Wrv009067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:02: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
	sB3L2Vrq012555; Wed, 3 Dec 2014 21:02:31 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:02:30 -0800
Date: Wed, 3 Dec 2014 22:02:25 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: andrew.cooper3@citrix.com, ian.campbell@citrix.com, jbeulich@suse.com,
	konrad.wilk@oracle.com, keir@xen.org, roy.franz@linaro.org,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xenproject.org
Message-ID: <20141203210225.GR16236@olila.local.net-space.pl>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey,

1) Why is there in EFI code so many functions (e.g. efi_start(),
   efi_arch_edd(), ...) with local variables declared as a static?
   Though some of them have also regular local variables. I do not
   why it was decided that some of them must be the static and
   some of do not. It is a bit confusing. As I can see there is
   only one place which have to have local static (place_string()).
   Other seems to me as thing to save space on the stack but I do
   not think we need that. According to UEFI spec there will be
   "128 KiB or more of available stack space" when system runs in
   boot services mode. It is a lot of space. So, I think we can
   safely convert most of local static variables to normal local
   variables. Am I right?

2) I am going to add EDID support to EFI code. Should it be x86
   specific code or common one? As I can see EDID is defined as
   part of GOP so I think that EDID code should be placed in
   xen/common/efi/boot.c.

3) Should not we change xen/arch/*/efi/efi-boot.h to
   xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
   code than definitions, declarations and short static
   functions. So, I think that it is more regular *.c file
   than header file.

Daniel

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:06:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21: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 1XwH7o-0004OQ-UX; Wed, 03 Dec 2014 21:06: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 1XwH7n-0004OG-Q5
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 21:06:15 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	FB/34-17694-64B7F745; Wed, 03 Dec 2014 21:06:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417640772!8472056!1
X-Originating-IP: [156.151.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 21865 invoked from network); 3 Dec 2014 21:06: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; 3 Dec 2014 21:06: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 sB3L5hpf017979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:05:44 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
	sB3L5gDk000923
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:05:43 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
	sB3L5f40022648; Wed, 3 Dec 2014 21:05:41 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:05:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5CB3611EE3E; Wed,  3 Dec 2014 16:05:42 -0500 (EST)
Date: Wed, 3 Dec 2014 16:05:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141203210542.GB10336@laptop.dumpdata.com>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
	<1417602539.11243.4.camel@citrix.com>
	<20141203104912.GA30431@aepfle.de>
	<1417603870.11243.10.camel@citrix.com>
	<20141203105522.GA32341@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141203105522.GA32341@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 11:55:22AM +0100, Olaf Hering wrote:
> On Wed, Dec 03, Ian Campbell wrote:
> 
> > On Wed, 2014-12-03 at 11:49 +0100, Olaf Hering wrote:
> > > On Wed, Dec 03, Ian Campbell wrote:
> > > 
> > > > Ah I didn't know about the sd_listen_fds thing, so I think that what we
> > > > need then is to use pkg-config first to determine if systemd-daemon is
> > > > present at all, and then check for specific symbols we require using the
> > > > pkg-config supplied CFLAGS and LDFLAGS rather than assuming
> > > > -lsystemd-daemon.
> > > 
> > > Correction: sd_listen_fds is available since at least v1.
> > >  git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d
> > >  v1~390
> > 
> > In that case I don't think we realistically need to check for it?
> 
> Yes. Anything before 208 is stale. At least I dont have anything older
> around for testing.

And for Fedora it is Fedora 21 or later. F20 has 208 so we are OK there.

> 
> Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:06:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21: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 1XwH7o-0004OQ-UX; Wed, 03 Dec 2014 21:06: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 1XwH7n-0004OG-Q5
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 21:06:15 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	FB/34-17694-64B7F745; Wed, 03 Dec 2014 21:06:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417640772!8472056!1
X-Originating-IP: [156.151.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 21865 invoked from network); 3 Dec 2014 21:06: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; 3 Dec 2014 21:06: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 sB3L5hpf017979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:05:44 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
	sB3L5gDk000923
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:05:43 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
	sB3L5f40022648; Wed, 3 Dec 2014 21:05:41 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:05:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5CB3611EE3E; Wed,  3 Dec 2014 16:05:42 -0500 (EST)
Date: Wed, 3 Dec 2014 16:05:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141203210542.GB10336@laptop.dumpdata.com>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
	<1417602539.11243.4.camel@citrix.com>
	<20141203104912.GA30431@aepfle.de>
	<1417603870.11243.10.camel@citrix.com>
	<20141203105522.GA32341@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141203105522.GA32341@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 11:55:22AM +0100, Olaf Hering wrote:
> On Wed, Dec 03, Ian Campbell wrote:
> 
> > On Wed, 2014-12-03 at 11:49 +0100, Olaf Hering wrote:
> > > On Wed, Dec 03, Ian Campbell wrote:
> > > 
> > > > Ah I didn't know about the sd_listen_fds thing, so I think that what we
> > > > need then is to use pkg-config first to determine if systemd-daemon is
> > > > present at all, and then check for specific symbols we require using the
> > > > pkg-config supplied CFLAGS and LDFLAGS rather than assuming
> > > > -lsystemd-daemon.
> > > 
> > > Correction: sd_listen_fds is available since at least v1.
> > >  git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d
> > >  v1~390
> > 
> > In that case I don't think we realistically need to check for it?
> 
> Yes. Anything before 208 is stale. At least I dont have anything older
> around for testing.

And for Fedora it is Fedora 21 or later. F20 has 208 so we are OK there.

> 
> Olaf

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:12:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21: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 1XwHDQ-0004cB-O1; Wed, 03 Dec 2014 21:12:04 +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 1XwHDO-0004bM-N0
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 21:12:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F3/F8-15461-2AC7F745; Wed, 03 Dec 2014 21:12:02 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417641121!13232404!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30026 invoked from network); 3 Dec 2014 21:12:01 -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; 3 Dec 2014 21:12:01 -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 sB3LBirf012050;
	Wed, 3 Dec 2014 21:11:48 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 sB3LBeKW031115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:11: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 sB3LBeZT016854;
	Wed, 3 Dec 2014 21:11:40 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sB3LBdXQ016850; Wed, 3 Dec 2014 21:11:39 GMT
Date: Wed, 3 Dec 2014 21:11:39 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141203165410.GA2819@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.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: sB3LBirf012050
Cc: Olaf Hering <olaf@aepfle.de>, 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.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Wed, 3 Dec 2014, Konrad Rzeszutek Wilk wrote:

> On Tue, Dec 02, 2014 at 06:51:50PM +0000, M A Young wrote:
>> On Tue, 2 Dec 2014, Konrad Rzeszutek Wilk wrote:
>>
>>> On Tue, Dec 02, 2014 at 03:44:55PM +0000, Ian Campbell wrote:
>>>> On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
>>>>> Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
>>>>> systemd xenstored dependencies") all service files use the .socket unit
>>>>> as startup dependency. While this happens to work for boot it fails for
>>>>> shutdown because a .socket does not seem to enforce ordering. When
>>>>> xendomains.service runs during shutdown then systemd will stop
>>>>> xenstored.service at the same time.
>>>>>
>>>>> Change all "xenstored.socket" to "xenstored.service" to let systemd know
>>>>> that xenstored has to be shutdown after everything else.
>>>>>
>>>>> Reported-by: Mark Pryor <tlviewer@yahoo.com>
>>>>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>>>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>>>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>>
>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>>
>>>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>>> ---
>>>>>
>>>>> This should go into 4.5 to fix xendomains.service.
>>>>
>>>> CCing Konrad...
>>>
>>> CC-ing Michael.
>>>
>>> Michael, since Fedora is using systemd, did you observe this bug as well?
>>> (I think I did, but I might have blamed it on my wacky setup).
>>
>> I only tried the xen systemd on xen 4.5-rc2 and didn't have a lot of success
>> even when I reverted to Fedora's systemd for xen, so I can't really comment.
>> I did have issues with xen systemd which I shall report if they are still
>> there in -rc3.
>
> It seems that hte issue I am having is:
>
> ELinux: security_context_to_sid($XENSTORED_MOUNT_CTX) failed for (dev tmpfs, type tmpfs) er
> Dec 03 11:46:07 laptop.dumpdata.com systemd[1]: var-lib-xenstored.mount mount process exited, code=exited status=32
> Dec 03 11:46:07 laptop.dumpdata.com systemd[1]: Failed to mount mount xenstore file system.
>
> Which looks like so:
>
> [root@laptop system]# more var-lib-xenstored.mount
> [Unit]
> Description=mount xenstore file system
> Requires=proc-xen.mount
> After=proc-xen.mount
> ConditionPathExists=/proc/xen/capabilities
> RefuseManualStop=true
>
> [Mount]
> Environment=XENSTORED_MOUNT_CTX=none
> EnvironmentFile=-/etc/sysconfig/xenstored
> What=xenstore
> Where=/var/lib/xenstored
> Type=tmpfs
> Options=mode=755,context="$XENSTORED_MOUNT_CTX"

Yes, that was on my probable bug list, as context="none" isn't a valid 
mount option (on Fedora at least), presumably because context has to be 
followed by a valid selinux context.

 	Michael Young

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:12:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21: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 1XwHDQ-0004cB-O1; Wed, 03 Dec 2014 21:12:04 +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 1XwHDO-0004bM-N0
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 21:12:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F3/F8-15461-2AC7F745; Wed, 03 Dec 2014 21:12:02 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417641121!13232404!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30026 invoked from network); 3 Dec 2014 21:12:01 -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; 3 Dec 2014 21:12:01 -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 sB3LBirf012050;
	Wed, 3 Dec 2014 21:11:48 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 sB3LBeKW031115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:11: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 sB3LBeZT016854;
	Wed, 3 Dec 2014 21:11:40 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sB3LBdXQ016850; Wed, 3 Dec 2014 21:11:39 GMT
Date: Wed, 3 Dec 2014 21:11:39 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141203165410.GA2819@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.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: sB3LBirf012050
Cc: Olaf Hering <olaf@aepfle.de>, 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.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Wed, 3 Dec 2014, Konrad Rzeszutek Wilk wrote:

> On Tue, Dec 02, 2014 at 06:51:50PM +0000, M A Young wrote:
>> On Tue, 2 Dec 2014, Konrad Rzeszutek Wilk wrote:
>>
>>> On Tue, Dec 02, 2014 at 03:44:55PM +0000, Ian Campbell wrote:
>>>> On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
>>>>> Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
>>>>> systemd xenstored dependencies") all service files use the .socket unit
>>>>> as startup dependency. While this happens to work for boot it fails for
>>>>> shutdown because a .socket does not seem to enforce ordering. When
>>>>> xendomains.service runs during shutdown then systemd will stop
>>>>> xenstored.service at the same time.
>>>>>
>>>>> Change all "xenstored.socket" to "xenstored.service" to let systemd know
>>>>> that xenstored has to be shutdown after everything else.
>>>>>
>>>>> Reported-by: Mark Pryor <tlviewer@yahoo.com>
>>>>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>>>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>>>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>>
>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>>
>>>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>>> ---
>>>>>
>>>>> This should go into 4.5 to fix xendomains.service.
>>>>
>>>> CCing Konrad...
>>>
>>> CC-ing Michael.
>>>
>>> Michael, since Fedora is using systemd, did you observe this bug as well?
>>> (I think I did, but I might have blamed it on my wacky setup).
>>
>> I only tried the xen systemd on xen 4.5-rc2 and didn't have a lot of success
>> even when I reverted to Fedora's systemd for xen, so I can't really comment.
>> I did have issues with xen systemd which I shall report if they are still
>> there in -rc3.
>
> It seems that hte issue I am having is:
>
> ELinux: security_context_to_sid($XENSTORED_MOUNT_CTX) failed for (dev tmpfs, type tmpfs) er
> Dec 03 11:46:07 laptop.dumpdata.com systemd[1]: var-lib-xenstored.mount mount process exited, code=exited status=32
> Dec 03 11:46:07 laptop.dumpdata.com systemd[1]: Failed to mount mount xenstore file system.
>
> Which looks like so:
>
> [root@laptop system]# more var-lib-xenstored.mount
> [Unit]
> Description=mount xenstore file system
> Requires=proc-xen.mount
> After=proc-xen.mount
> ConditionPathExists=/proc/xen/capabilities
> RefuseManualStop=true
>
> [Mount]
> Environment=XENSTORED_MOUNT_CTX=none
> EnvironmentFile=-/etc/sysconfig/xenstored
> What=xenstore
> Where=/var/lib/xenstored
> Type=tmpfs
> Options=mode=755,context="$XENSTORED_MOUNT_CTX"

Yes, that was on my probable bug list, as context="none" isn't a valid 
mount option (on Fedora at least), presumably because context has to be 
followed by a valid selinux context.

 	Michael Young

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:20:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:20:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHLV-0004q9-0e; Wed, 03 Dec 2014 21:20:25 +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 1XwHLT-0004q4-F7
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 21:20:23 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	BA/25-05632-69E7F745; Wed, 03 Dec 2014 21:20:22 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417641621!10840170!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10383 invoked from network); 3 Dec 2014 21:20:21 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 21:20:21 -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 sB3LK7UR013911;
	Wed, 3 Dec 2014 21:20:11 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 sB3LK1pQ026093
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:20:01 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 sB3LK10p015372;
	Wed, 3 Dec 2014 21:20:01 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sB3LK1j7015368; Wed, 3 Dec 2014 21:20:01 GMT
Date: Wed, 3 Dec 2014 21:20:01 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141203210542.GB10336@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1412032115460.16535@procyon.dur.ac.uk>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
	<1417602539.11243.4.camel@citrix.com>
	<20141203104912.GA30431@aepfle.de>
	<1417603870.11243.10.camel@citrix.com>
	<20141203105522.GA32341@aepfle.de>
	<20141203210542.GB10336@laptop.dumpdata.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: sB3LK7UR013911
Cc: Mark Pryor <tlviewer@yahoo.com>, Olaf Hering <olaf@aepfle.de>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Wed, 3 Dec 2014, Konrad Rzeszutek Wilk wrote:

> On Wed, Dec 03, 2014 at 11:55:22AM +0100, Olaf Hering wrote:
>> On Wed, Dec 03, Ian Campbell wrote:
>>
>>> On Wed, 2014-12-03 at 11:49 +0100, Olaf Hering wrote:
>>>> On Wed, Dec 03, Ian Campbell wrote:
>>>>
>>>>> Ah I didn't know about the sd_listen_fds thing, so I think that what we
>>>>> need then is to use pkg-config first to determine if systemd-daemon is
>>>>> present at all, and then check for specific symbols we require using the
>>>>> pkg-config supplied CFLAGS and LDFLAGS rather than assuming
>>>>> -lsystemd-daemon.
>>>>
>>>> Correction: sd_listen_fds is available since at least v1.
>>>>  git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d
>>>>  v1~390
>>>
>>> In that case I don't think we realistically need to check for it?
>>
>> Yes. Anything before 208 is stale. At least I dont have anything older
>> around for testing.
>
> And for Fedora it is Fedora 21 or later. F20 has 208 so we are OK there.

Fedora 21 is going through its final release candidates now so it will 
stick to Xen 4.4 . The first Fedora release that might use this code (if I 
decide to use it - at the moment I have reservations) would be Fedora 22.

 	Michael Young

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:20:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:20:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHLV-0004q9-0e; Wed, 03 Dec 2014 21:20:25 +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 1XwHLT-0004q4-F7
	for xen-devel@lists.xen.org; Wed, 03 Dec 2014 21:20:23 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	BA/25-05632-69E7F745; Wed, 03 Dec 2014 21:20:22 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417641621!10840170!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10383 invoked from network); 3 Dec 2014 21:20:21 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 21:20:21 -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 sB3LK7UR013911;
	Wed, 3 Dec 2014 21:20:11 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 sB3LK1pQ026093
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:20:01 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 sB3LK10p015372;
	Wed, 3 Dec 2014 21:20:01 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sB3LK1j7015368; Wed, 3 Dec 2014 21:20:01 GMT
Date: Wed, 3 Dec 2014 21:20:01 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141203210542.GB10336@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1412032115460.16535@procyon.dur.ac.uk>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
	<1417602539.11243.4.camel@citrix.com>
	<20141203104912.GA30431@aepfle.de>
	<1417603870.11243.10.camel@citrix.com>
	<20141203105522.GA32341@aepfle.de>
	<20141203210542.GB10336@laptop.dumpdata.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: sB3LK7UR013911
Cc: Mark Pryor <tlviewer@yahoo.com>, Olaf Hering <olaf@aepfle.de>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Wed, 3 Dec 2014, Konrad Rzeszutek Wilk wrote:

> On Wed, Dec 03, 2014 at 11:55:22AM +0100, Olaf Hering wrote:
>> On Wed, Dec 03, Ian Campbell wrote:
>>
>>> On Wed, 2014-12-03 at 11:49 +0100, Olaf Hering wrote:
>>>> On Wed, Dec 03, Ian Campbell wrote:
>>>>
>>>>> Ah I didn't know about the sd_listen_fds thing, so I think that what we
>>>>> need then is to use pkg-config first to determine if systemd-daemon is
>>>>> present at all, and then check for specific symbols we require using the
>>>>> pkg-config supplied CFLAGS and LDFLAGS rather than assuming
>>>>> -lsystemd-daemon.
>>>>
>>>> Correction: sd_listen_fds is available since at least v1.
>>>>  git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d
>>>>  v1~390
>>>
>>> In that case I don't think we realistically need to check for it?
>>
>> Yes. Anything before 208 is stale. At least I dont have anything older
>> around for testing.
>
> And for Fedora it is Fedora 21 or later. F20 has 208 so we are OK there.

Fedora 21 is going through its final release candidates now so it will 
stick to Xen 4.4 . The first Fedora release that might use this code (if I 
decide to use it - at the moment I have reservations) would be Fedora 22.

 	Michael Young

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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfa-0005Rj-2y; Wed, 03 Dec 2014 21:41: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 1XwHfY-0005Qr-AD
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E1/00-09842-3738F745; Wed, 03 Dec 2014 21:41:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417642863!13209259!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2978 invoked from network); 3 Dec 2014 21:41:04 -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; 3 Dec 2014 21:41:04 -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 sB3Lf0QX007645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:01 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
	sB3LexpO004026
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:41:00 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
	sB3LexUv024694; Wed, 3 Dec 2014 21:40:59 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A96E011EEA9; Wed,  3 Dec 2014 16:41:00 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:28 -0500
Message-Id: <1417642834-20350-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 3/9] 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfb-0005Sz-S2; Wed, 03 Dec 2014 21:41: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 1XwHfa-0005RV-9k
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:10 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	8C/92-17958-5738F745; Wed, 03 Dec 2014 21:41:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417642867!10916569!1
X-Originating-IP: [156.151.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 23797 invoked from network); 3 Dec 2014 21:41:08 -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; 3 Dec 2014 21:41:08 -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 sB3Lf3mC026649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:04 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
	sB3Lf2RT004320
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:41:03 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
	sB3Lf1Mf007454; Wed, 3 Dec 2014 21:41:02 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:41:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 58F2611EEB5; Wed,  3 Dec 2014 16:41:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:34 -0500
Message-Id: <1417642834-20350-10-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 9/9] xen/pciback: Implement PCI reset slot or
	bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The life-cycle of a PCI device in Xen pciback is complex
and is constrained by the PCI generic locking mechanism.

It starts with the device being binded to us - for which
we do a device function reset (and done via SysFS
so the PCI lock is held)

If the device is unbinded from us - we also do a function
reset (also done via SysFS so the PCI lock is held).

If the device is un-assigned from a guest - we do a function
reset (no PCI lock).

All on the individual PCI function level (so bus:device:function).

Unfortunatly a function reset is not adequate for certain
PCIe devices. The reset for an individual PCI function "means
device must support FLR (PCIe or AF), PM reset on D3hot->D0
device specific reset, or be a singleton device on a bus
a secondary bus reset.  FLR does not have widespread support,
reset is not very reliable, and bus topology is dictated by the
and device design.  We need to provide a means for a user to
a bus reset in cases where the existing mechanisms are not
 or not reliable. " (Adam Williamson, 'vfio-pci: PCI hot reset
interface' commit 8b27ee60bfd6bbb84d2df28fa706c5c5081066ca).

As such to do a slot or a bus reset is we need another mechanism.
This is not exposed SysFS as there is no good way of exposing
a bus topology there.

This is due to the complexity - we MUST know that the different
functions off a PCIe device are not in use by other drivers, or
if they are in use (say one of them is assigned to a guest
and the other is idle) - it is still OK to reset the slot
(assuming both of them are owned by Xen pciback).

This patch does that by doing an slot or bus reset (if
slot not supported) if all of the functions of a PCIe
device belong to Xen PCIback. We do not care if the device is
in-use as we depend on the toolstack to be aware of this -
however if it is we will WARN the user.

Due to the complexity with the PCI lock we cannot do
the reset when a device is binded ('echo $BDF > bind')
or when unbinded ('echo $BDF > unbind') as the pci_[slot|bus]_reset
also take the same lock resulting in a dead-lock.

Putting the reset function in a workqueue or thread
won't work either - as we have to do the reset function
outside the 'unbind' context (it holds the PCI lock).
But once you 'unbind' a device the device is no longer
under the ownership of Xen pciback and the pci_set_drvdata
has been reset so we cannot use a thread for this.

Instead of doing all this complex dance, we depend on the toolstack
doing the right thing. As such implement the 'do_flr' SysFS attribute
which 'xl' uses when a device is detached or attached from/to a guest.
It bypasses the need to worry about the PCI lock.

To not inadvertly do a bus reset that would affect devices that
are in use by other drivers (other than Xen pciback) prior
to the reset we check that all of the devices under the bridge
are owned by Xen pciback. If they are not we do not do
the bus (or slot) reset.

We also warn the user if the device is in use - but still
continue with the reset. This should not happen as the toolstack
also does the check.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 Documentation/ABI/testing/sysfs-driver-pciback |  12 +++
 drivers/xen/xen-pciback/pci_stub.c             | 124 ++++++++++++++++++++++---
 2 files changed, 125 insertions(+), 11 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-pciback b/Documentation/ABI/testing/sysfs-driver-pciback
index 6a733bf..2d4e32f 100644
--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++ b/Documentation/ABI/testing/sysfs-driver-pciback
@@ -11,3 +11,15 @@ Description:
                 #echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
                 will allow the guest to read and write to the configuration
                 register 0x0E.
+
+
+What:           /sys/bus/pci/drivers/pciback/do_flr
+Date:           December 2014
+KernelVersion:  3.19
+Contact:        xen-devel@lists.xenproject.org
+Description:
+                An option to slot or bus reset an PCI device owned by
+                Xen PCI backend. Writing a string of DDDD:BB:DD.F will cause
+                the driver to perform an slot or bus reset if the device
+                supports. It also checks to make sure that all of the devices
+                under the bridge are owned by Xen PCI backend.
diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index cc3cbb4..f830bf4 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -100,14 +100,9 @@ static void pcistub_device_release(struct kref *kref)
 
 	xen_unregister_device_domain_owner(dev);
 
-	/* Call the reset function which does not take lock as this
-	 * is called from "unbind" which takes a device_lock mutex.
-	 */
-	__pci_reset_function_locked(dev);
+	/* Reset is done by the toolstack by using 'do_flr' on the SysFS. */
 	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_restore_state(dev);
 
 	if (dev->msix_cap) {
 		struct physdev_pci_device ppdev = {
@@ -123,9 +118,6 @@ static void pcistub_device_release(struct kref *kref)
 				 err);
 	}
 
-	/* Disable the device */
-	xen_pcibk_reset_device(dev);
-
 	kfree(dev_data);
 	pci_set_drvdata(dev, NULL);
 
@@ -242,6 +234,87 @@ struct pci_dev *pcistub_get_pci_dev(struct xen_pcibk_device *pdev,
 	return found_dev;
 }
 
+struct wrapper_args {
+	struct pci_dev *dev;
+	int in_use;
+};
+
+static int pcistub_pci_walk_wrapper(struct pci_dev *dev, void *data)
+{
+	struct pcistub_device *psdev, *found_psdev = NULL;
+	struct wrapper_args *arg = data;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pcistub_devices_lock, flags);
+	list_for_each_entry(psdev, &pcistub_devices, dev_list) {
+		if (psdev->dev == dev) {
+			found_psdev = psdev;
+			if (psdev->pdev)
+				arg->in_use++;
+			break;
+		}
+	}
+	spin_unlock_irqrestore(&pcistub_devices_lock, flags);
+	dev_dbg(&dev->dev, "%s\n", found_psdev ? "OK" : "not owned by us!");
+
+	if (!found_psdev)
+		arg->dev = dev;
+	return found_psdev ? 0 : 1;
+}
+
+static int pcistub_reset_pci_dev(struct pci_dev *dev)
+{
+	struct xen_pcibk_dev_data *dev_data;
+	struct wrapper_args arg = { .dev = NULL, .in_use = 0 };
+	bool slot = false, bus = false;
+	int rc;
+
+	if (!dev)
+		return -EINVAL;
+
+	if (!pci_probe_reset_slot(dev->slot))
+		slot = true;
+	else if (!pci_probe_reset_bus(dev->bus)) {
+		/* We won't attempt to reset a root bridge. */
+		if (!pci_is_root_bus(dev->bus))
+			bus = true;
+	}
+	dev_dbg(&dev->dev, "resetting (FLR, D3, %s %s) the device\n",
+		slot ? "slot" : "", bus ? "bus" : "");
+
+	pci_walk_bus(dev->bus, pcistub_pci_walk_wrapper, &arg);
+
+	if (arg.in_use)
+		dev_err(&dev->dev, "is in use!\n");
+
+	/*
+	 * Takes the PCI lock. OK to do it as we are never called
+	 * from 'unbind' state and don't deadlock.
+	 */
+	dev_data = pci_get_drvdata(dev);
+	if (!pci_load_saved_state(dev, dev_data->pci_saved_state))
+		pci_restore_state(dev);
+
+	pci_reset_function(dev);
+
+	/* This disables the device. */
+	xen_pcibk_reset_device(dev);
+
+	/* And cleanup up our emulated fields. */
+	xen_pcibk_config_reset_dev(dev);
+
+	if (!bus && !slot)
+		return 0;
+
+	/* All slots or devices under the bus should be part of pcistub! */
+	if (arg.dev) {
+		dev_err(&dev->dev, "depends on: %s!\n", pci_name(arg.dev));
+		return -EBUSY;
+	}
+	return slot ? pci_try_reset_slot(dev->slot) :
+		      pci_try_reset_bus(dev->bus);
+}
+
 /*
  * Called when:
  *  - XenBus state has been reconfigure (pci unplug). See xen_pcibk_remove_device
@@ -277,8 +350,9 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	* pcistub and xen_pcibk when AER is in processing
 	*/
 	down_write(&pcistub_sem);
-	/* Cleanup our device
-	 * (so it's ready for the next domain)
+	/* Cleanup our device (so it's ready for the next domain)
+	 * That is the job of the toolstack which has to call 'do_flr' before
+	 * providing the PCI device to a guest (see pcistub_do_flr).
 	 */
 	device_lock_assert(&dev->dev);
 	__pci_reset_function_locked(dev);
@@ -1389,6 +1463,29 @@ static ssize_t permissive_show(struct device_driver *drv, char *buf)
 static DRIVER_ATTR(permissive, S_IRUSR | S_IWUSR, permissive_show,
 		   permissive_add);
 
+static ssize_t pcistub_do_flr(struct device_driver *drv, const char *buf,
+				size_t count)
+{
+	int domain, bus, slot, func;
+	int err;
+	struct pcistub_device *psdev;
+
+	err = str_to_slot(buf, &domain, &bus, &slot, &func);
+	if (err)
+		goto out;
+
+	psdev = pcistub_device_find(domain, bus, slot, func);
+	if (psdev) {
+		err = pcistub_reset_pci_dev(psdev->dev);
+		pcistub_device_put(psdev);
+	} else
+		err = -ENODEV;
+out:
+	if (!err)
+		err = count;
+	return err;
+}
+static DRIVER_ATTR(do_flr, S_IWUSR, NULL, pcistub_do_flr);
 static void pcistub_exit(void)
 {
 	driver_remove_file(&xen_pcibk_pci_driver.driver, &driver_attr_new_slot);
@@ -1402,6 +1499,8 @@ static void pcistub_exit(void)
 			   &driver_attr_irq_handlers);
 	driver_remove_file(&xen_pcibk_pci_driver.driver,
 			   &driver_attr_irq_handler_state);
+	driver_remove_file(&xen_pcibk_pci_driver.driver,
+			   &driver_attr_do_flr);
 	pci_unregister_driver(&xen_pcibk_pci_driver);
 }
 
@@ -1495,6 +1594,9 @@ static int __init pcistub_init(void)
 	if (!err)
 		err = driver_create_file(&xen_pcibk_pci_driver.driver,
 					&driver_attr_irq_handler_state);
+	if (!err)
+		err = driver_create_file(&xen_pcibk_pci_driver.driver,
+					&driver_attr_do_flr);
 	if (err)
 		pcistub_exit();
 
-- 
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 Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfa-0005Rs-F2; Wed, 03 Dec 2014 21:41: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 1XwHfY-0005Qu-Be
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1C/EB-25276-3738F745; Wed, 03 Dec 2014 21:41:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417642865!13245351!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8231 invoked from network); 3 Dec 2014 21:41:07 -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 Dec 2014 21:41:07 -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 sB3Lf33P007930
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:04 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
	sB3Lf27R007523
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:41: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
	sB3Lf1RO007447; Wed, 3 Dec 2014 21:41:02 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:41:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1D96311EEB2; Wed,  3 Dec 2014 16:41:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:32 -0500
Message-Id: <1417642834-20350-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 7/9] 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>
---
v2: Always FLR reset
---
 drivers/xen/xen-pciback/pci_stub.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 843a2ba..8580e53 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);
 
@@ -280,8 +282,18 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	 */
 	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) {
+		/*
+		 * 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);
+	} else
+		dev_info(&dev->dev, "Could not reload PCI state\n");
 	/* 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfa-0005S5-ST; Wed, 03 Dec 2014 21:41: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 1XwHfZ-0005R3-0s
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:09 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	DC/C7-15461-4738F745; Wed, 03 Dec 2014 21:41:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417642866!13220326!1
X-Originating-IP: [156.151.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 21927 invoked from network); 3 Dec 2014 21:41:07 -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; 3 Dec 2014 21:41: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 sB3Lf32L026642
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41: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
	sB3Lf2He022354
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:41:02 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
	sB3Lf2JU004240; Wed, 3 Dec 2014 21:41:02 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:41:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3CD7E11EEB3; Wed,  3 Dec 2014 16:41:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:33 -0500
Message-Id: <1417642834-20350-9-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Jan Beulich <jbeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v5 8/9] 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jan Beulich <JBeulich@suse.com>

When 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]
[v3: Redid it a bit differently]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 54 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 8580e53..cc3cbb4 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -1518,6 +1518,53 @@ parse_error:
 fs_initcall(pcistub_init);
 #endif
 
+#ifdef CONFIG_PCI_IOV
+static struct pcistub_device *find_vfs(const struct pci_dev *pdev)
+{
+	struct pcistub_device *psdev = NULL;
+	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)
+		return psdev;
+	return NULL;
+}
+
+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);
+
+	if (action != BUS_NOTIFY_UNBIND_DRIVER)
+		return NOTIFY_DONE;
+
+	if (!pdev->is_physfn)
+		return NOTIFY_DONE;
+
+	for (;;) {
+		struct pcistub_device *psdev = find_vfs(pdev);
+		if (!psdev)
+			break;
+		device_release_driver(&psdev->dev->dev);
+	}
+	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;
@@ -1539,12 +1586,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


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfZ-0005RR-O4; Wed, 03 Dec 2014 21:41: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 1XwHfX-0005QP-5C
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:07 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	F5/0B-17694-2738F745; Wed, 03 Dec 2014 21:41:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417642864!10952129!1
X-Originating-IP: [156.151.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 24418 invoked from network); 3 Dec 2014 21:41:05 -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; 3 Dec 2014 21:41:05 -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 sB3Lf19X026392
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:01 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
	sB3Lf0BN007315
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:41:00 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
	sB3LexZO024709; Wed, 3 Dec 2014 21:40:59 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 362BA11EEAD; Wed,  3 Dec 2014 16:41:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:30 -0500
Message-Id: <1417642834-20350-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 5/9] 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfX-0005Qj-K0; Wed, 03 Dec 2014 21:41: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 1XwHfW-0005QE-2n
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:06 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	7A/36-02957-1738F745; Wed, 03 Dec 2014 21:41:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417642863!7402326!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25259 invoked from network); 3 Dec 2014 21:41:04 -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; 3 Dec 2014 21:41:04 -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 sB3Lf00N007637
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:00 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
	sB3Lex9m007293
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:40:59 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
	sB3Lewwq022126; Wed, 3 Dec 2014 21:40:59 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4354911EEA3; Wed,  3 Dec 2014 16:41:00 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:25 -0500
Message-Id: <1417642834-20350-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 v5] 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


Since v4 (http://lists.xen.org/archives/html/xen-devel/2014-11/msg02130.html):
 - Per David's review altered one of the patches.
v3 (https://lkml.org/lkml/2014/7/8/533):
 - Epic discussion.

These patches fix some issues with PCI back and also add proper
bus/slot reset.


 Documentation/ABI/testing/sysfs-driver-pciback |  12 ++
 drivers/pci/pci.c                              |   5 +-
 drivers/xen/xen-pciback/passthrough.c          |  14 +-
 drivers/xen/xen-pciback/pci_stub.c             | 236 +++++++++++++++++++++----
 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 +
 9 files changed, 254 insertions(+), 45 deletions(-)


Jan Beulich (1):
      xen-pciback: drop SR-IOV VFs when PF driver unloads

Konrad Rzeszutek Wilk (8):
      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/pciback: Implement PCI reset slot or bus with 'do_flr' SysFS attribute


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfZ-0005RK-BX; Wed, 03 Dec 2014 21:41: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 1XwHfW-0005QN-RF
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:07 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	C5/23-19763-2738F745; Wed, 03 Dec 2014 21:41:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417642864!11393085!1
X-Originating-IP: [156.151.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 23241 invoked from network); 3 Dec 2014 21:41:05 -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; 3 Dec 2014 21:41:05 -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 sB3Lf0mS026361
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:00 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
	sB3LexAA007294
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:41:00 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
	sB3Lex6R003989; Wed, 3 Dec 2014 21:40:59 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 628E011EEA5; Wed,  3 Dec 2014 16:41:00 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:26 -0500
Message-Id: <1417642834-20350-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 1/9] 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfb-0005SK-8L; Wed, 03 Dec 2014 21:41: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 1XwHfZ-0005R4-5N
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:09 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	0F/52-05632-4738F745; Wed, 03 Dec 2014 21:41:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417642866!10885586!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22152 invoked from network); 3 Dec 2014 21:41:07 -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; 3 Dec 2014 21:41: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 sB3Lf4v7007959
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:05 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
	sB3Lf0g2024801
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:41:01 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
	sB3Lex7K007308; Wed, 3 Dec 2014 21:41:00 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E36DE11EEAB; Wed,  3 Dec 2014 16:41:00 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:29 -0500
Message-Id: <1417642834-20350-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 4/9] 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfY-0005R5-Va; Wed, 03 Dec 2014 21:41: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 1XwHfW-0005QO-Rn
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:06 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	6E/41-25547-2738F745; Wed, 03 Dec 2014 21:41:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417642864!6477170!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18973 invoked from network); 3 Dec 2014 21:41: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; 3 Dec 2014 21:41: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 sB3Lf0JK007674
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:01 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
	sB3Lf0Os004062
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:41:00 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
	sB3Lf0u4024721; Wed, 3 Dec 2014 21:41:00 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5483F11EEAF; Wed,  3 Dec 2014 16:41:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:31 -0500
Message-Id: <1417642834-20350-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 6/9] 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfZ-0005RK-BX; Wed, 03 Dec 2014 21:41: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 1XwHfW-0005QN-RF
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:07 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	C5/23-19763-2738F745; Wed, 03 Dec 2014 21:41:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417642864!11393085!1
X-Originating-IP: [156.151.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 23241 invoked from network); 3 Dec 2014 21:41:05 -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; 3 Dec 2014 21:41:05 -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 sB3Lf0mS026361
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:00 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
	sB3LexAA007294
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:41:00 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
	sB3Lex6R003989; Wed, 3 Dec 2014 21:40:59 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 628E011EEA5; Wed,  3 Dec 2014 16:41:00 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:26 -0500
Message-Id: <1417642834-20350-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 1/9] 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfX-0005Qj-K0; Wed, 03 Dec 2014 21:41: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 1XwHfW-0005QE-2n
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:06 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	7A/36-02957-1738F745; Wed, 03 Dec 2014 21:41:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417642863!7402326!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25259 invoked from network); 3 Dec 2014 21:41:04 -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; 3 Dec 2014 21:41:04 -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 sB3Lf00N007637
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:00 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
	sB3Lex9m007293
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:40:59 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
	sB3Lewwq022126; Wed, 3 Dec 2014 21:40:59 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4354911EEA3; Wed,  3 Dec 2014 16:41:00 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:25 -0500
Message-Id: <1417642834-20350-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 v5] 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


Since v4 (http://lists.xen.org/archives/html/xen-devel/2014-11/msg02130.html):
 - Per David's review altered one of the patches.
v3 (https://lkml.org/lkml/2014/7/8/533):
 - Epic discussion.

These patches fix some issues with PCI back and also add proper
bus/slot reset.


 Documentation/ABI/testing/sysfs-driver-pciback |  12 ++
 drivers/pci/pci.c                              |   5 +-
 drivers/xen/xen-pciback/passthrough.c          |  14 +-
 drivers/xen/xen-pciback/pci_stub.c             | 236 +++++++++++++++++++++----
 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 +
 9 files changed, 254 insertions(+), 45 deletions(-)


Jan Beulich (1):
      xen-pciback: drop SR-IOV VFs when PF driver unloads

Konrad Rzeszutek Wilk (8):
      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/pciback: Implement PCI reset slot or bus with 'do_flr' SysFS attribute


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfX-0005QY-9D; Wed, 03 Dec 2014 21:41: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 1XwHfV-0005QD-Up
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:06 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	3C/80-17735-1738F745; Wed, 03 Dec 2014 21:41:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417642863!10907521!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26021 invoked from network); 3 Dec 2014 21:41:04 -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; 3 Dec 2014 21:41:04 -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 sB3Lf0As007639
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:01 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
	sB3Lexoo007304
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:41:00 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
	sB3Lexkj022149; Wed, 3 Dec 2014 21:40:59 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7E7F211EEA7; Wed,  3 Dec 2014 16:41:00 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:27 -0500
Message-Id: <1417642834-20350-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 2/9] 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfZ-0005RR-O4; Wed, 03 Dec 2014 21:41: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 1XwHfX-0005QP-5C
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:07 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	F5/0B-17694-2738F745; Wed, 03 Dec 2014 21:41:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417642864!10952129!1
X-Originating-IP: [156.151.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 24418 invoked from network); 3 Dec 2014 21:41:05 -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; 3 Dec 2014 21:41:05 -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 sB3Lf19X026392
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:01 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
	sB3Lf0BN007315
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:41:00 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
	sB3LexZO024709; Wed, 3 Dec 2014 21:40:59 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 362BA11EEAD; Wed,  3 Dec 2014 16:41:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:30 -0500
Message-Id: <1417642834-20350-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 5/9] 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfa-0005Rj-2y; Wed, 03 Dec 2014 21:41: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 1XwHfY-0005Qr-AD
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E1/00-09842-3738F745; Wed, 03 Dec 2014 21:41:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417642863!13209259!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2978 invoked from network); 3 Dec 2014 21:41:04 -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; 3 Dec 2014 21:41:04 -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 sB3Lf0QX007645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:01 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
	sB3LexpO004026
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:41:00 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
	sB3LexUv024694; Wed, 3 Dec 2014 21:40:59 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A96E011EEA9; Wed,  3 Dec 2014 16:41:00 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:28 -0500
Message-Id: <1417642834-20350-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 3/9] 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfa-0005Rs-F2; Wed, 03 Dec 2014 21:41: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 1XwHfY-0005Qu-Be
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1C/EB-25276-3738F745; Wed, 03 Dec 2014 21:41:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417642865!13245351!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8231 invoked from network); 3 Dec 2014 21:41:07 -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 Dec 2014 21:41:07 -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 sB3Lf33P007930
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:04 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
	sB3Lf27R007523
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:41: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
	sB3Lf1RO007447; Wed, 3 Dec 2014 21:41:02 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:41:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1D96311EEB2; Wed,  3 Dec 2014 16:41:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:32 -0500
Message-Id: <1417642834-20350-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 7/9] 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>
---
v2: Always FLR reset
---
 drivers/xen/xen-pciback/pci_stub.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 843a2ba..8580e53 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);
 
@@ -280,8 +282,18 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	 */
 	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) {
+		/*
+		 * 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);
+	} else
+		dev_info(&dev->dev, "Could not reload PCI state\n");
 	/* 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfX-0005QY-9D; Wed, 03 Dec 2014 21:41: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 1XwHfV-0005QD-Up
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:06 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	3C/80-17735-1738F745; Wed, 03 Dec 2014 21:41:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417642863!10907521!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26021 invoked from network); 3 Dec 2014 21:41:04 -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; 3 Dec 2014 21:41:04 -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 sB3Lf0As007639
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:01 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
	sB3Lexoo007304
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:41:00 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
	sB3Lexkj022149; Wed, 3 Dec 2014 21:40:59 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 7E7F211EEA7; Wed,  3 Dec 2014 16:41:00 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:27 -0500
Message-Id: <1417642834-20350-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 2/9] 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfb-0005Sz-S2; Wed, 03 Dec 2014 21:41: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 1XwHfa-0005RV-9k
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:10 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	8C/92-17958-5738F745; Wed, 03 Dec 2014 21:41:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417642867!10916569!1
X-Originating-IP: [156.151.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 23797 invoked from network); 3 Dec 2014 21:41:08 -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; 3 Dec 2014 21:41:08 -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 sB3Lf3mC026649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:04 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
	sB3Lf2RT004320
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:41:03 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
	sB3Lf1Mf007454; Wed, 3 Dec 2014 21:41:02 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:41:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 58F2611EEB5; Wed,  3 Dec 2014 16:41:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:34 -0500
Message-Id: <1417642834-20350-10-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 9/9] xen/pciback: Implement PCI reset slot or
	bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The life-cycle of a PCI device in Xen pciback is complex
and is constrained by the PCI generic locking mechanism.

It starts with the device being binded to us - for which
we do a device function reset (and done via SysFS
so the PCI lock is held)

If the device is unbinded from us - we also do a function
reset (also done via SysFS so the PCI lock is held).

If the device is un-assigned from a guest - we do a function
reset (no PCI lock).

All on the individual PCI function level (so bus:device:function).

Unfortunatly a function reset is not adequate for certain
PCIe devices. The reset for an individual PCI function "means
device must support FLR (PCIe or AF), PM reset on D3hot->D0
device specific reset, or be a singleton device on a bus
a secondary bus reset.  FLR does not have widespread support,
reset is not very reliable, and bus topology is dictated by the
and device design.  We need to provide a means for a user to
a bus reset in cases where the existing mechanisms are not
 or not reliable. " (Adam Williamson, 'vfio-pci: PCI hot reset
interface' commit 8b27ee60bfd6bbb84d2df28fa706c5c5081066ca).

As such to do a slot or a bus reset is we need another mechanism.
This is not exposed SysFS as there is no good way of exposing
a bus topology there.

This is due to the complexity - we MUST know that the different
functions off a PCIe device are not in use by other drivers, or
if they are in use (say one of them is assigned to a guest
and the other is idle) - it is still OK to reset the slot
(assuming both of them are owned by Xen pciback).

This patch does that by doing an slot or bus reset (if
slot not supported) if all of the functions of a PCIe
device belong to Xen PCIback. We do not care if the device is
in-use as we depend on the toolstack to be aware of this -
however if it is we will WARN the user.

Due to the complexity with the PCI lock we cannot do
the reset when a device is binded ('echo $BDF > bind')
or when unbinded ('echo $BDF > unbind') as the pci_[slot|bus]_reset
also take the same lock resulting in a dead-lock.

Putting the reset function in a workqueue or thread
won't work either - as we have to do the reset function
outside the 'unbind' context (it holds the PCI lock).
But once you 'unbind' a device the device is no longer
under the ownership of Xen pciback and the pci_set_drvdata
has been reset so we cannot use a thread for this.

Instead of doing all this complex dance, we depend on the toolstack
doing the right thing. As such implement the 'do_flr' SysFS attribute
which 'xl' uses when a device is detached or attached from/to a guest.
It bypasses the need to worry about the PCI lock.

To not inadvertly do a bus reset that would affect devices that
are in use by other drivers (other than Xen pciback) prior
to the reset we check that all of the devices under the bridge
are owned by Xen pciback. If they are not we do not do
the bus (or slot) reset.

We also warn the user if the device is in use - but still
continue with the reset. This should not happen as the toolstack
also does the check.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 Documentation/ABI/testing/sysfs-driver-pciback |  12 +++
 drivers/xen/xen-pciback/pci_stub.c             | 124 ++++++++++++++++++++++---
 2 files changed, 125 insertions(+), 11 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-pciback b/Documentation/ABI/testing/sysfs-driver-pciback
index 6a733bf..2d4e32f 100644
--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++ b/Documentation/ABI/testing/sysfs-driver-pciback
@@ -11,3 +11,15 @@ Description:
                 #echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
                 will allow the guest to read and write to the configuration
                 register 0x0E.
+
+
+What:           /sys/bus/pci/drivers/pciback/do_flr
+Date:           December 2014
+KernelVersion:  3.19
+Contact:        xen-devel@lists.xenproject.org
+Description:
+                An option to slot or bus reset an PCI device owned by
+                Xen PCI backend. Writing a string of DDDD:BB:DD.F will cause
+                the driver to perform an slot or bus reset if the device
+                supports. It also checks to make sure that all of the devices
+                under the bridge are owned by Xen PCI backend.
diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index cc3cbb4..f830bf4 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -100,14 +100,9 @@ static void pcistub_device_release(struct kref *kref)
 
 	xen_unregister_device_domain_owner(dev);
 
-	/* Call the reset function which does not take lock as this
-	 * is called from "unbind" which takes a device_lock mutex.
-	 */
-	__pci_reset_function_locked(dev);
+	/* Reset is done by the toolstack by using 'do_flr' on the SysFS. */
 	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_restore_state(dev);
 
 	if (dev->msix_cap) {
 		struct physdev_pci_device ppdev = {
@@ -123,9 +118,6 @@ static void pcistub_device_release(struct kref *kref)
 				 err);
 	}
 
-	/* Disable the device */
-	xen_pcibk_reset_device(dev);
-
 	kfree(dev_data);
 	pci_set_drvdata(dev, NULL);
 
@@ -242,6 +234,87 @@ struct pci_dev *pcistub_get_pci_dev(struct xen_pcibk_device *pdev,
 	return found_dev;
 }
 
+struct wrapper_args {
+	struct pci_dev *dev;
+	int in_use;
+};
+
+static int pcistub_pci_walk_wrapper(struct pci_dev *dev, void *data)
+{
+	struct pcistub_device *psdev, *found_psdev = NULL;
+	struct wrapper_args *arg = data;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pcistub_devices_lock, flags);
+	list_for_each_entry(psdev, &pcistub_devices, dev_list) {
+		if (psdev->dev == dev) {
+			found_psdev = psdev;
+			if (psdev->pdev)
+				arg->in_use++;
+			break;
+		}
+	}
+	spin_unlock_irqrestore(&pcistub_devices_lock, flags);
+	dev_dbg(&dev->dev, "%s\n", found_psdev ? "OK" : "not owned by us!");
+
+	if (!found_psdev)
+		arg->dev = dev;
+	return found_psdev ? 0 : 1;
+}
+
+static int pcistub_reset_pci_dev(struct pci_dev *dev)
+{
+	struct xen_pcibk_dev_data *dev_data;
+	struct wrapper_args arg = { .dev = NULL, .in_use = 0 };
+	bool slot = false, bus = false;
+	int rc;
+
+	if (!dev)
+		return -EINVAL;
+
+	if (!pci_probe_reset_slot(dev->slot))
+		slot = true;
+	else if (!pci_probe_reset_bus(dev->bus)) {
+		/* We won't attempt to reset a root bridge. */
+		if (!pci_is_root_bus(dev->bus))
+			bus = true;
+	}
+	dev_dbg(&dev->dev, "resetting (FLR, D3, %s %s) the device\n",
+		slot ? "slot" : "", bus ? "bus" : "");
+
+	pci_walk_bus(dev->bus, pcistub_pci_walk_wrapper, &arg);
+
+	if (arg.in_use)
+		dev_err(&dev->dev, "is in use!\n");
+
+	/*
+	 * Takes the PCI lock. OK to do it as we are never called
+	 * from 'unbind' state and don't deadlock.
+	 */
+	dev_data = pci_get_drvdata(dev);
+	if (!pci_load_saved_state(dev, dev_data->pci_saved_state))
+		pci_restore_state(dev);
+
+	pci_reset_function(dev);
+
+	/* This disables the device. */
+	xen_pcibk_reset_device(dev);
+
+	/* And cleanup up our emulated fields. */
+	xen_pcibk_config_reset_dev(dev);
+
+	if (!bus && !slot)
+		return 0;
+
+	/* All slots or devices under the bus should be part of pcistub! */
+	if (arg.dev) {
+		dev_err(&dev->dev, "depends on: %s!\n", pci_name(arg.dev));
+		return -EBUSY;
+	}
+	return slot ? pci_try_reset_slot(dev->slot) :
+		      pci_try_reset_bus(dev->bus);
+}
+
 /*
  * Called when:
  *  - XenBus state has been reconfigure (pci unplug). See xen_pcibk_remove_device
@@ -277,8 +350,9 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	* pcistub and xen_pcibk when AER is in processing
 	*/
 	down_write(&pcistub_sem);
-	/* Cleanup our device
-	 * (so it's ready for the next domain)
+	/* Cleanup our device (so it's ready for the next domain)
+	 * That is the job of the toolstack which has to call 'do_flr' before
+	 * providing the PCI device to a guest (see pcistub_do_flr).
 	 */
 	device_lock_assert(&dev->dev);
 	__pci_reset_function_locked(dev);
@@ -1389,6 +1463,29 @@ static ssize_t permissive_show(struct device_driver *drv, char *buf)
 static DRIVER_ATTR(permissive, S_IRUSR | S_IWUSR, permissive_show,
 		   permissive_add);
 
+static ssize_t pcistub_do_flr(struct device_driver *drv, const char *buf,
+				size_t count)
+{
+	int domain, bus, slot, func;
+	int err;
+	struct pcistub_device *psdev;
+
+	err = str_to_slot(buf, &domain, &bus, &slot, &func);
+	if (err)
+		goto out;
+
+	psdev = pcistub_device_find(domain, bus, slot, func);
+	if (psdev) {
+		err = pcistub_reset_pci_dev(psdev->dev);
+		pcistub_device_put(psdev);
+	} else
+		err = -ENODEV;
+out:
+	if (!err)
+		err = count;
+	return err;
+}
+static DRIVER_ATTR(do_flr, S_IWUSR, NULL, pcistub_do_flr);
 static void pcistub_exit(void)
 {
 	driver_remove_file(&xen_pcibk_pci_driver.driver, &driver_attr_new_slot);
@@ -1402,6 +1499,8 @@ static void pcistub_exit(void)
 			   &driver_attr_irq_handlers);
 	driver_remove_file(&xen_pcibk_pci_driver.driver,
 			   &driver_attr_irq_handler_state);
+	driver_remove_file(&xen_pcibk_pci_driver.driver,
+			   &driver_attr_do_flr);
 	pci_unregister_driver(&xen_pcibk_pci_driver);
 }
 
@@ -1495,6 +1594,9 @@ static int __init pcistub_init(void)
 	if (!err)
 		err = driver_create_file(&xen_pcibk_pci_driver.driver,
 					&driver_attr_irq_handler_state);
+	if (!err)
+		err = driver_create_file(&xen_pcibk_pci_driver.driver,
+					&driver_attr_do_flr);
 	if (err)
 		pcistub_exit();
 
-- 
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 Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfa-0005S5-ST; Wed, 03 Dec 2014 21:41: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 1XwHfZ-0005R3-0s
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:09 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	DC/C7-15461-4738F745; Wed, 03 Dec 2014 21:41:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417642866!13220326!1
X-Originating-IP: [156.151.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 21927 invoked from network); 3 Dec 2014 21:41:07 -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; 3 Dec 2014 21:41: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 sB3Lf32L026642
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41: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
	sB3Lf2He022354
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:41:02 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
	sB3Lf2JU004240; Wed, 3 Dec 2014 21:41:02 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:41:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3CD7E11EEB3; Wed,  3 Dec 2014 16:41:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:33 -0500
Message-Id: <1417642834-20350-9-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Jan Beulich <jbeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v5 8/9] 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jan Beulich <JBeulich@suse.com>

When 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]
[v3: Redid it a bit differently]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c | 54 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 8580e53..cc3cbb4 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -1518,6 +1518,53 @@ parse_error:
 fs_initcall(pcistub_init);
 #endif
 
+#ifdef CONFIG_PCI_IOV
+static struct pcistub_device *find_vfs(const struct pci_dev *pdev)
+{
+	struct pcistub_device *psdev = NULL;
+	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)
+		return psdev;
+	return NULL;
+}
+
+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);
+
+	if (action != BUS_NOTIFY_UNBIND_DRIVER)
+		return NOTIFY_DONE;
+
+	if (!pdev->is_physfn)
+		return NOTIFY_DONE;
+
+	for (;;) {
+		struct pcistub_device *psdev = find_vfs(pdev);
+		if (!psdev)
+			break;
+		device_release_driver(&psdev->dev->dev);
+	}
+	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;
@@ -1539,12 +1586,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


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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfb-0005SK-8L; Wed, 03 Dec 2014 21:41: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 1XwHfZ-0005R4-5N
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:09 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	0F/52-05632-4738F745; Wed, 03 Dec 2014 21:41:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417642866!10885586!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22152 invoked from network); 3 Dec 2014 21:41:07 -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; 3 Dec 2014 21:41: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 sB3Lf4v7007959
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:05 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
	sB3Lf0g2024801
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 3 Dec 2014 21:41:01 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
	sB3Lex7K007308; Wed, 3 Dec 2014 21:41:00 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E36DE11EEAB; Wed,  3 Dec 2014 16:41:00 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:29 -0500
Message-Id: <1417642834-20350-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 4/9] 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 Wed Dec 03 21:41:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHfY-0005R5-Va; Wed, 03 Dec 2014 21:41: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 1XwHfW-0005QO-Rn
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:41:06 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	6E/41-25547-2738F745; Wed, 03 Dec 2014 21:41:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417642864!6477170!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18973 invoked from network); 3 Dec 2014 21:41: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; 3 Dec 2014 21:41: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 sB3Lf0JK007674
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 3 Dec 2014 21:41:01 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
	sB3Lf0Os004062
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 3 Dec 2014 21:41:00 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
	sB3Lf0u4024721; Wed, 3 Dec 2014 21:41:00 GMT
Received: from laptop.dumpdata.com (/10.154.99.34)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 13:40:59 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5483F11EEAF; Wed,  3 Dec 2014 16:41:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, david.vrabel@citrix.com
Date: Wed,  3 Dec 2014 16:40:31 -0500
Message-Id: <1417642834-20350-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.9.3
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-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 v5 6/9] 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 Wed Dec 03 21:42:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21: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 1XwHgy-0006Bw-Cu; Wed, 03 Dec 2014 21:42: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 1XwHgw-0006BC-Lr
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 21:42:34 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	50/7C-02954-AC38F745; Wed, 03 Dec 2014 21:42:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417642951!8178519!1
X-Originating-IP: [66.165.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 11401 invoked from network); 3 Dec 2014 21:42:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 21:42:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,510,1413244800"; d="scan'208";a="199288043"
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, 3 Dec 2014 16:42: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 1XwHgo-0003Vl-2g;
	Wed, 03 Dec 2014 21:42:26 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwHgn-00028J-T0;
	Wed, 03 Dec 2014 21:42:25 +0000
Date: Wed, 3 Dec 2014 21:42:25 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32064-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 3158
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32064: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5539163572748059705=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5539163572748059705==
Content-Type: text/plain
Content-Length: 2762
Content-Transfer-Encoding: quoted-printable

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32005
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32005
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32005

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              86a15a258283850ec5563e2a66bf389aa2dfa318
baseline version:
 libvirt              ff018e686a8a412255bc34d3dc558a1bcf74fac5

------------------------------------------------------------
People who touched revisions under test:
  Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
  Dmitry Guryanov <dguryanov@parallels.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Laine Stump <laine@laine.org>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Pavel Hrdina <phrdina@redhat.com>
  Wang Rui <moon.wangrui@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

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


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

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

--===============5539163572748059705==--

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:42:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21: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 1XwHgy-0006Bw-Cu; Wed, 03 Dec 2014 21:42: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 1XwHgw-0006BC-Lr
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 21:42:34 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	50/7C-02954-AC38F745; Wed, 03 Dec 2014 21:42:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417642951!8178519!1
X-Originating-IP: [66.165.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 11401 invoked from network); 3 Dec 2014 21:42:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 21:42:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,510,1413244800"; d="scan'208";a="199288043"
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, 3 Dec 2014 16:42: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 1XwHgo-0003Vl-2g;
	Wed, 03 Dec 2014 21:42:26 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwHgn-00028J-T0;
	Wed, 03 Dec 2014 21:42:25 +0000
Date: Wed, 3 Dec 2014 21:42:25 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32064-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 3158
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32064: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5539163572748059705=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5539163572748059705==
Content-Type: text/plain
Content-Length: 2762
Content-Transfer-Encoding: quoted-printable

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32005
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32005
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32005

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              86a15a258283850ec5563e2a66bf389aa2dfa318
baseline version:
 libvirt              ff018e686a8a412255bc34d3dc558a1bcf74fac5

------------------------------------------------------------
People who touched revisions under test:
  Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
  Dmitry Guryanov <dguryanov@parallels.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Laine Stump <laine@laine.org>
  Martin Kletzander <mkletzan@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Pavel Hrdina <phrdina@redhat.com>
  Wang Rui <moon.wangrui@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

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


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

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

--===============5539163572748059705==--

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:47:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:47:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHlL-0006vN-F6; Wed, 03 Dec 2014 21:47:07 +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 1XwHlK-0006vI-FZ
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 21:47:06 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	E0/C1-02712-9D48F745; Wed, 03 Dec 2014 21:47:05 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417643222!12827738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5739 invoked from network); 3 Dec 2014 21:47:04 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 21:47: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=1417643224; x=1449179224;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=dQkN0n4FFZAqQq4VZTYN3VWZQykejI7BdNu8QYzQ7A4=;
	b=Ihb7KVIRG06dtXIycKnEgzSIu0FiKQ9BL+5y6FVuJBKw5plvf2uiKahu
	emy9T1TzDIduVhndtQ+uEn59SrjJ6EyA0+yULKQhR39xB4P/Ef+eIqAEd
	7dhMlMZpr17DdKKbzgeZYCzd5oL2RZ+ErECyJ3Sz+scaFjscdlRHs9tDd o=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 03 Dec 2014 21:47:01 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,510,1413244800"; d="scan'208";a="920483933"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.110.83])
	by fldsmtpi01.verizon.com with ESMTP; 03 Dec 2014 21:47:00 +0000
Message-ID: <547F84D3.3090501@terremark.com>
Date: Wed, 03 Dec 2014 16:46:59 -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>, 
	xen-devel@lists.xensource.com
References: <alpine.DEB.2.02.1412031818180.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412031818180.30971@kaball.uk.xensource.com>
Cc: Anthony Perard <anthony.perard@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	dslutz@verizon.com
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl_set_memory_target: only
 remove videoram from absolute targets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/03/14 13:20, Stefano Stabellini wrote:
> If the new target is relative to the current target, do not remove
> videoram again: it has already been removed from the current target.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..2aa83bd 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4741,13 +4741,17 @@ retry_transaction:
>           goto out;
>       }
>   
> +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> +                "%s/memory/videoram", dompath));
> +    videoram = videoram_s ? atoi(videoram_s) : 0;
> +
>       if (relative) {
>           if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
>               new_target_memkb = 0;
>           else
>               new_target_memkb = current_target_memkb + target_memkb;
>       } else
> -        new_target_memkb = target_memkb;
> +        new_target_memkb = target_memkb - videoram;
>       if (new_target_memkb > memorykb) {
>           LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                   "memory_dynamic_max must be less than or equal to"
> @@ -4763,9 +4767,6 @@ retry_transaction:
>           abort_transaction = 1;
>           goto out;
>       }
> -    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> -                "%s/memory/videoram", dompath));
> -    videoram = videoram_s ? atoi(videoram_s) : 0;
>   
>       if (enforce) {
>           memorykb = new_target_memkb;

Since new_target_memkb is now adjusted before this line, you
need to change this to:

          memorykb = new_target_memkb + videoram;

    -Don Slutz

> @@ -4780,7 +4781,6 @@ retry_transaction:
>           }
>       }
>   
> -    new_target_memkb -= videoram;
>       rc = xc_domain_set_pod_target(ctx->xch, domid,
>               new_target_memkb / 4, NULL, NULL, NULL);
>       if (rc != 0) {



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

From xen-devel-bounces@lists.xen.org Wed Dec 03 21:47:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 21:47:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwHlL-0006vN-F6; Wed, 03 Dec 2014 21:47:07 +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 1XwHlK-0006vI-FZ
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 21:47:06 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	E0/C1-02712-9D48F745; Wed, 03 Dec 2014 21:47:05 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417643222!12827738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5739 invoked from network); 3 Dec 2014 21:47:04 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Dec 2014 21:47: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=1417643224; x=1449179224;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=dQkN0n4FFZAqQq4VZTYN3VWZQykejI7BdNu8QYzQ7A4=;
	b=Ihb7KVIRG06dtXIycKnEgzSIu0FiKQ9BL+5y6FVuJBKw5plvf2uiKahu
	emy9T1TzDIduVhndtQ+uEn59SrjJ6EyA0+yULKQhR39xB4P/Ef+eIqAEd
	7dhMlMZpr17DdKKbzgeZYCzd5oL2RZ+ErECyJ3Sz+scaFjscdlRHs9tDd o=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 03 Dec 2014 21:47:01 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,510,1413244800"; d="scan'208";a="920483933"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.110.83])
	by fldsmtpi01.verizon.com with ESMTP; 03 Dec 2014 21:47:00 +0000
Message-ID: <547F84D3.3090501@terremark.com>
Date: Wed, 03 Dec 2014 16:46:59 -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>, 
	xen-devel@lists.xensource.com
References: <alpine.DEB.2.02.1412031818180.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412031818180.30971@kaball.uk.xensource.com>
Cc: Anthony Perard <anthony.perard@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	dslutz@verizon.com
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl_set_memory_target: only
 remove videoram from absolute targets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/03/14 13:20, Stefano Stabellini wrote:
> If the new target is relative to the current target, do not remove
> videoram again: it has already been removed from the current target.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..2aa83bd 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4741,13 +4741,17 @@ retry_transaction:
>           goto out;
>       }
>   
> +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> +                "%s/memory/videoram", dompath));
> +    videoram = videoram_s ? atoi(videoram_s) : 0;
> +
>       if (relative) {
>           if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
>               new_target_memkb = 0;
>           else
>               new_target_memkb = current_target_memkb + target_memkb;
>       } else
> -        new_target_memkb = target_memkb;
> +        new_target_memkb = target_memkb - videoram;
>       if (new_target_memkb > memorykb) {
>           LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>                   "memory_dynamic_max must be less than or equal to"
> @@ -4763,9 +4767,6 @@ retry_transaction:
>           abort_transaction = 1;
>           goto out;
>       }
> -    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> -                "%s/memory/videoram", dompath));
> -    videoram = videoram_s ? atoi(videoram_s) : 0;
>   
>       if (enforce) {
>           memorykb = new_target_memkb;

Since new_target_memkb is now adjusted before this line, you
need to change this to:

          memorykb = new_target_memkb + videoram;

    -Don Slutz

> @@ -4780,7 +4781,6 @@ retry_transaction:
>           }
>       }
>   
> -    new_target_memkb -= videoram;
>       rc = xc_domain_set_pod_target(ctx->xch, domid,
>               new_target_memkb / 4, NULL, NULL, NULL);
>       if (rc != 0) {



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

From xen-devel-bounces@lists.xen.org Wed Dec 03 22:20:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 22: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 1XwIH8-0007oD-9n; Wed, 03 Dec 2014 22:19: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 1XwIH6-0007o8-MB
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 22:19:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F1/2C-15461-C8C8F745; Wed, 03 Dec 2014 22:19:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417645193!13250574!1
X-Originating-IP: [66.165.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 30559 invoked from network); 3 Dec 2014 22:19:54 -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;
	3 Dec 2014 22:19:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,510,1413244800"; d="scan'208";a="199647491"
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, 3 Dec 2014 17: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 1XwIH2-0003h4-6D;
	Wed, 03 Dec 2014 22: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 1XwIH1-0003ud-V2;
	Wed, 03 Dec 2014 22:19:51 +0000
Date: Wed, 3 Dec 2014 22:19:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32029-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] 32029: 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 32029 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32029/

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 31947

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-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-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                0d7954c288e91b8a457f15a0a8e8244facf6594b
baseline version:
 qemuu                db12451decf7dfe0f083564183e135f2095228b9

------------------------------------------------------------
People who touched revisions under test:
  Gonglei <arei.gonglei@huawei.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                    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=0d7954c288e91b8a457f15a0a8e8244facf6594b
+ . 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 0d7954c288e91b8a457f15a0a8e8244facf6594b
+ branch=qemu-mainline
+ revision=0d7954c288e91b8a457f15a0a8e8244facf6594b
+ . 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 0d7954c288e91b8a457f15a0a8e8244facf6594b:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   db12451..0d7954c  0d7954c288e91b8a457f15a0a8e8244facf6594b -> 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 Dec 03 22:20:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 22: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 1XwIH8-0007oD-9n; Wed, 03 Dec 2014 22:19: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 1XwIH6-0007o8-MB
	for xen-devel@lists.xensource.com; Wed, 03 Dec 2014 22:19:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F1/2C-15461-C8C8F745; Wed, 03 Dec 2014 22:19:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417645193!13250574!1
X-Originating-IP: [66.165.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 30559 invoked from network); 3 Dec 2014 22:19:54 -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;
	3 Dec 2014 22:19:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,510,1413244800"; d="scan'208";a="199647491"
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, 3 Dec 2014 17: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 1XwIH2-0003h4-6D;
	Wed, 03 Dec 2014 22: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 1XwIH1-0003ud-V2;
	Wed, 03 Dec 2014 22:19:51 +0000
Date: Wed, 3 Dec 2014 22:19:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32029-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] 32029: 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 32029 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32029/

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 31947

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-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-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                0d7954c288e91b8a457f15a0a8e8244facf6594b
baseline version:
 qemuu                db12451decf7dfe0f083564183e135f2095228b9

------------------------------------------------------------
People who touched revisions under test:
  Gonglei <arei.gonglei@huawei.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                    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=0d7954c288e91b8a457f15a0a8e8244facf6594b
+ . 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 0d7954c288e91b8a457f15a0a8e8244facf6594b
+ branch=qemu-mainline
+ revision=0d7954c288e91b8a457f15a0a8e8244facf6594b
+ . 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 0d7954c288e91b8a457f15a0a8e8244facf6594b:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   db12451..0d7954c  0d7954c288e91b8a457f15a0a8e8244facf6594b -> 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 Dec 03 23:50:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 23:50:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwJgF-0000wC-Cp; Wed, 03 Dec 2014 23:49:59 +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 1XwJgD-0000w7-Mq
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 23:49:57 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	7D/F6-27785-2A1AF745; Wed, 03 Dec 2014 23:49:54 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417650591!12855259!1
X-Originating-IP: [209.85.192.48]
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 5073 invoked from network); 3 Dec 2014 23:49:52 -0000
Received: from mail-qg0-f48.google.com (HELO mail-qg0-f48.google.com)
	(209.85.192.48)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 23:49:52 -0000
Received: by mail-qg0-f48.google.com with SMTP id q107so11630511qgd.7
	for <xen-devel@lists.xenproject.org>;
	Wed, 03 Dec 2014 15:49:51 -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=NKZM20YgsqOR5VUWyG9R4BrW5gFIdlLxphZo4eLFNU4=;
	b=mzaAuG8V07lcRBku63VPKcFdANRCxSYiej1B6LJZGflKNOUCeOU9uFBbcASkKJAg7U
	53bi4GWu+MfpsaFs6E0J/6KzGgELt+AZOaYVGr/M3+3tAmY6pfWWKvnFb304+bVLSqV4
	A2FGuWL+qk6XPHZGJr+fZ6mqpA9AC0dGKrFfUNMuk9XRNLuZHs+2pliIE1LGPfKw8HY7
	4p0Mb9NYRlEtmmKv50BTZZacnVXCofmJeS73nT7sNJhVGIgLFEp+NS3I4CooDDQmTU2f
	2yb4udTcHH8m3ju3onQNGGisftqO/ddk6zHkxTE8rDMLeXCwd109QRNdmOGD7g/qqDZs
	Nl1g==
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=NKZM20YgsqOR5VUWyG9R4BrW5gFIdlLxphZo4eLFNU4=;
	b=cfpOJr+/Fla9oXQQhM8jf31xHFU75Tn4TwsLhnstdCW9zTf3mBXIs59E9/M8YtMxpu
	n/NRZS+zZJFnenrrM0Mx/LGkQyhDDdH+uf4R2Sk4v0srGrwkN6mPwdXIRJ8jtaAlOVvu
	Jq+givRu3nnO2VKkTIpCXM+zPJ+S+GrPTZ/74exkC84AE/+KwTW1+nXsrWU78MXDzPzz
	X/MbcDxe1XCQ78r9tPhYVqQ7av4zq2KFenrWy2ztPtd3QI+NTScohBv9HATnrb1eDWpQ
	bN0oJ9EFgrOqoNMxbQEk0uf9rqUZkkPrE1wcT3S11FwkWmI/be6eQWJlRyds6PtwwRRW
	uXTA==
X-Gm-Message-State: ALoCoQlQILYwxDk/1T6nxCeXJZMkZmG3L8p8wmpyEI7FFmXwwzskFocXr2ODVkadYyGcweU2jGzO
X-Received: by 10.224.67.7 with SMTP id p7mr11893724qai.97.1417650591009; Wed,
	03 Dec 2014 15:49:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.94.74 with HTTP; Wed, 3 Dec 2014 15:49:30 -0800 (PST)
In-Reply-To: <1417642834-20350-7-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
	<1417642834-20350-7-git-send-email-konrad.wilk@oracle.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Date: Wed, 3 Dec 2014 16:49:30 -0700
Message-ID: <CAErSpo62D02fh-AmLC4N7OUK0yYN89X_FuZNqXsv4AfYUTj5eg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v5 6/9] 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 3, 2014 at 2:40 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> 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>

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

I assume you'll merge this whole series through your tree.  Let me
know if you want me to do anything else.

> ---
>  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 Wed Dec 03 23:50:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 03 Dec 2014 23:50:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwJgF-0000wC-Cp; Wed, 03 Dec 2014 23:49:59 +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 1XwJgD-0000w7-Mq
	for xen-devel@lists.xenproject.org; Wed, 03 Dec 2014 23:49:57 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	7D/F6-27785-2A1AF745; Wed, 03 Dec 2014 23:49:54 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417650591!12855259!1
X-Originating-IP: [209.85.192.48]
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 5073 invoked from network); 3 Dec 2014 23:49:52 -0000
Received: from mail-qg0-f48.google.com (HELO mail-qg0-f48.google.com)
	(209.85.192.48)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Dec 2014 23:49:52 -0000
Received: by mail-qg0-f48.google.com with SMTP id q107so11630511qgd.7
	for <xen-devel@lists.xenproject.org>;
	Wed, 03 Dec 2014 15:49:51 -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=NKZM20YgsqOR5VUWyG9R4BrW5gFIdlLxphZo4eLFNU4=;
	b=mzaAuG8V07lcRBku63VPKcFdANRCxSYiej1B6LJZGflKNOUCeOU9uFBbcASkKJAg7U
	53bi4GWu+MfpsaFs6E0J/6KzGgELt+AZOaYVGr/M3+3tAmY6pfWWKvnFb304+bVLSqV4
	A2FGuWL+qk6XPHZGJr+fZ6mqpA9AC0dGKrFfUNMuk9XRNLuZHs+2pliIE1LGPfKw8HY7
	4p0Mb9NYRlEtmmKv50BTZZacnVXCofmJeS73nT7sNJhVGIgLFEp+NS3I4CooDDQmTU2f
	2yb4udTcHH8m3ju3onQNGGisftqO/ddk6zHkxTE8rDMLeXCwd109QRNdmOGD7g/qqDZs
	Nl1g==
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=NKZM20YgsqOR5VUWyG9R4BrW5gFIdlLxphZo4eLFNU4=;
	b=cfpOJr+/Fla9oXQQhM8jf31xHFU75Tn4TwsLhnstdCW9zTf3mBXIs59E9/M8YtMxpu
	n/NRZS+zZJFnenrrM0Mx/LGkQyhDDdH+uf4R2Sk4v0srGrwkN6mPwdXIRJ8jtaAlOVvu
	Jq+givRu3nnO2VKkTIpCXM+zPJ+S+GrPTZ/74exkC84AE/+KwTW1+nXsrWU78MXDzPzz
	X/MbcDxe1XCQ78r9tPhYVqQ7av4zq2KFenrWy2ztPtd3QI+NTScohBv9HATnrb1eDWpQ
	bN0oJ9EFgrOqoNMxbQEk0uf9rqUZkkPrE1wcT3S11FwkWmI/be6eQWJlRyds6PtwwRRW
	uXTA==
X-Gm-Message-State: ALoCoQlQILYwxDk/1T6nxCeXJZMkZmG3L8p8wmpyEI7FFmXwwzskFocXr2ODVkadYyGcweU2jGzO
X-Received: by 10.224.67.7 with SMTP id p7mr11893724qai.97.1417650591009; Wed,
	03 Dec 2014 15:49:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.94.74 with HTTP; Wed, 3 Dec 2014 15:49:30 -0800 (PST)
In-Reply-To: <1417642834-20350-7-git-send-email-konrad.wilk@oracle.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
	<1417642834-20350-7-git-send-email-konrad.wilk@oracle.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Date: Wed, 3 Dec 2014 16:49:30 -0700
Message-ID: <CAErSpo62D02fh-AmLC4N7OUK0yYN89X_FuZNqXsv4AfYUTj5eg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v5 6/9] 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 3, 2014 at 2:40 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> 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>

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

I assume you'll merge this whole series through your tree.  Let me
know if you want me to do anything else.

> ---
>  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 Thu Dec 04 00:51:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 00:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwKd1-0002kT-AX; Thu, 04 Dec 2014 00:50:43 +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 1XwKcz-0002kO-TH
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 00:50:42 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	F8/B7-03145-1EFAF745; Thu, 04 Dec 2014 00:50:41 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417654240!12846172!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21994 invoked from network); 4 Dec 2014 00:50:40 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 00:50:40 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so26244144wiv.7
	for <xen-devel@lists.xenproject.org>;
	Wed, 03 Dec 2014 16:50: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
	:content-transfer-encoding;
	bh=Umu1e83fMqDYENPEy7LEY117j4a6SbENfgJLEnjuRnY=;
	b=GHEE3Dh9RsI01OQj4Pp5jUQmva+jyPzJ9ac2p8coC7WqNUpPZyCkmzmFrtQef/L0OC
	W4tGpGnInivwQaFVgzJYc+CgfLj3U+Vdnpg9mWMG4eM48N40ZLC05fHrsQq40O5su2P+
	Y/ZMiTmqzco5nfzK+GJ9dUXOCzuDw97otPZQZB59yAaHGkE0IA2kdHwDNmsRDcioDxLw
	ynQMLt3BYk0b5miO/ACerab+7HZK/TI77yWA+xq34mjdwQ+ILkJYiZigBmWppVzpxYGr
	4/0igPh73i+FjTXb2i3NnO+u/klta4JALE01OmEqS5daUdyRWKW6MWnsP9RxgTlBmsd4
	+ROQ==
X-Gm-Message-State: ALoCoQmllkW893Md70g97DOAYJL76APtVwR6kExyT7NRHoFhiln6sj3+44ihKV0J5KypFzZN2g/i
X-Received: by 10.180.94.230 with SMTP id df6mr17663841wib.25.1417654239853;
	Wed, 03 Dec 2014 16:50:39 -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 h8sm39196705wiy.17.2014.12.03.16.50.38
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 03 Dec 2014 16:50:39 -0800 (PST)
Message-ID: <547FAFDD.8010005@linaro.org>
Date: Thu, 04 Dec 2014 00:50:37 +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.3.0
MIME-Version: 1.0
To: Vitaly Kuznetsov <vkuznets@redhat.com>, 
 xen-devel@lists.xenproject.org
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-5-git-send-email-vkuznets@redhat.com>
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Vitaly,

On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
> New operation sets the 'recipient' domain which will recieve all

s/recieve/receive/

> memory pages from a particular domain and kills the original domain.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> @@ -1764,13 +1765,32 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)

[..]

> +        else
> +        {
> +            mfn = page_to_mfn(pg);
> +            gmfn = mfn_to_gmfn(d, mfn);
> +
> +            page_set_owner(pg, NULL);
> +            if ( assign_pages(d->recipient, pg, order, 0) )
> +                /* assign_pages reports the error by itself */
> +                goto out;
> +
> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )

On ARM, mfn_to_gmfn will always return the mfn. This would result to add 
a 1:1 mapping in the recipient domain.

But ... only DOM0 has its memory mapped 1:1. So this code may blow up 
the P2M of the recipient domain.

I'm not an x86 expert, but this may also happen when the recipient 
domain is using translated page mode (i.e HVM/PVHM).

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 Dec 04 00:51:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 00:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwKd1-0002kT-AX; Thu, 04 Dec 2014 00:50:43 +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 1XwKcz-0002kO-TH
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 00:50:42 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	F8/B7-03145-1EFAF745; Thu, 04 Dec 2014 00:50:41 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417654240!12846172!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21994 invoked from network); 4 Dec 2014 00:50:40 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 00:50:40 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so26244144wiv.7
	for <xen-devel@lists.xenproject.org>;
	Wed, 03 Dec 2014 16:50: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
	:content-transfer-encoding;
	bh=Umu1e83fMqDYENPEy7LEY117j4a6SbENfgJLEnjuRnY=;
	b=GHEE3Dh9RsI01OQj4Pp5jUQmva+jyPzJ9ac2p8coC7WqNUpPZyCkmzmFrtQef/L0OC
	W4tGpGnInivwQaFVgzJYc+CgfLj3U+Vdnpg9mWMG4eM48N40ZLC05fHrsQq40O5su2P+
	Y/ZMiTmqzco5nfzK+GJ9dUXOCzuDw97otPZQZB59yAaHGkE0IA2kdHwDNmsRDcioDxLw
	ynQMLt3BYk0b5miO/ACerab+7HZK/TI77yWA+xq34mjdwQ+ILkJYiZigBmWppVzpxYGr
	4/0igPh73i+FjTXb2i3NnO+u/klta4JALE01OmEqS5daUdyRWKW6MWnsP9RxgTlBmsd4
	+ROQ==
X-Gm-Message-State: ALoCoQmllkW893Md70g97DOAYJL76APtVwR6kExyT7NRHoFhiln6sj3+44ihKV0J5KypFzZN2g/i
X-Received: by 10.180.94.230 with SMTP id df6mr17663841wib.25.1417654239853;
	Wed, 03 Dec 2014 16:50:39 -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 h8sm39196705wiy.17.2014.12.03.16.50.38
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 03 Dec 2014 16:50:39 -0800 (PST)
Message-ID: <547FAFDD.8010005@linaro.org>
Date: Thu, 04 Dec 2014 00:50:37 +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.3.0
MIME-Version: 1.0
To: Vitaly Kuznetsov <vkuznets@redhat.com>, 
 xen-devel@lists.xenproject.org
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-5-git-send-email-vkuznets@redhat.com>
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Vitaly,

On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
> New operation sets the 'recipient' domain which will recieve all

s/recieve/receive/

> memory pages from a particular domain and kills the original domain.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> @@ -1764,13 +1765,32 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)

[..]

> +        else
> +        {
> +            mfn = page_to_mfn(pg);
> +            gmfn = mfn_to_gmfn(d, mfn);
> +
> +            page_set_owner(pg, NULL);
> +            if ( assign_pages(d->recipient, pg, order, 0) )
> +                /* assign_pages reports the error by itself */
> +                goto out;
> +
> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )

On ARM, mfn_to_gmfn will always return the mfn. This would result to add 
a 1:1 mapping in the recipient domain.

But ... only DOM0 has its memory mapped 1:1. So this code may blow up 
the P2M of the recipient domain.

I'm not an x86 expert, but this may also happen when the recipient 
domain is using translated page mode (i.e HVM/PVHM).

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 Dec 04 01:31:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 01:31:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwLGG-0007cz-Rw; Thu, 04 Dec 2014 01:31:16 +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 1XwLGE-0007cu-Mw
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 01:31:14 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	19/10-22777-269BF745; Thu, 04 Dec 2014 01:31:14 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417656669!11411007!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13034 invoked from network); 4 Dec 2014 01:31:10 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Dec 2014 01:31:10 -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
	sB41V3Jk031545
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 3 Dec 2014 20:31:03 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sB41V3UB031543;
	Wed, 3 Dec 2014 20:31:03 -0500
Date: Wed, 3 Dec 2014 21:31:03 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141204013102.GA31385@andromeda.dapyr.net>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141201170151.GK3180@laptop.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 12:01:51PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 02:32:44PM +0100, Olaf Hering wrote:
> > On Mon, Dec 01, Olaf Hering wrote:
> > 
> > > # xl pci-assignable-add 01:10.0
> > > # xl pci-assignable-list
> > > 0000:01:10.0
> > > # xl create -f domU.cfg
> > > # xl console domU
> > > ## lspci gives just emulated PCI devices
> > 
> > ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> > 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> > 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev ff)
> > 
> > > ## detach from domU console
> > > # xl pci-attach domU 0000:01:10.0
> > > # xl pci-list domU
> > > Vdev Device
> > > 04.0 0000:01:10.0
> > > 
> > > # xl console domU
> > > ## lspci gives just emulated PCI devices
> > 
> > ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> > 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> > 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 01)
> > 
> > > ## detach from domU console
> > > # xl pci-detach domU 0000:01:10.0
> > Now lspci shows that the emulated network card is gone.
> 
> > ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> > 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> > 
> > > # xl pci-attach domU 0000:01:10.0
> > > # xl pci-list domU
> > > Vdev Device
> > > 04.0 0000:01:10.0
> > > # xl console domU
> > > ## lspci shows now also the assigned host device
> > 
> > 
> > So the actual bug is that the very first time after pci-attach the guests
> > "00:04.0" PCI device is (most likely) replaced with the host PCI device. Just
> > the guest does not notice that "00:04.0" was actually already gone after unplug.
> 
> That is odd - I see any device 'hot-plugged' being added at 00:05 and further.

I have to apologize. The reason it works for me is because the emulated
device gets unplugged quite early:

# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446

[and here I run 'xl pci-attach USB 00:1a.0]

# [   30.609802] hpet1: lost 1589 rtc interrupts
[   30.672030] hpet1: lost 2200 rtc interrupts
[   30.672030] hpet1: lost 2201 rtc interrupts
[   30.672030] hpet1: lost 2200 rtc interrupts
[   30.899341] pci 0000:00:04.0: [8086:1c2d] type 00 class 0x0c0320

And the other test I have been running is when the guest is booted
with an PCI device (and then unplugged):

# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
00:05.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 04)

But oddly enough when I do 'pci-detach' and then 'pci-attach' I get:
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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
00:04.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 04)

so something is busted as you surmised

And it looks to be busted in two cases - I see the 'hpet1' issues
and the guest then crashes!
> 
> > 
> > I wonder why the unplug code in xen_platform.c does just a qdev_free() instead
> > of a real pci-detach kind of thing. I'm sure this could be done at least for
> > emulated network cards.
> > 
> > Olaf
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@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 Dec 04 01:31:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 01:31:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwLGG-0007cz-Rw; Thu, 04 Dec 2014 01:31:16 +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 1XwLGE-0007cu-Mw
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 01:31:14 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	19/10-22777-269BF745; Thu, 04 Dec 2014 01:31:14 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417656669!11411007!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13034 invoked from network); 4 Dec 2014 01:31:10 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Dec 2014 01:31:10 -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
	sB41V3Jk031545
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 3 Dec 2014 20:31:03 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sB41V3UB031543;
	Wed, 3 Dec 2014 20:31:03 -0500
Date: Wed, 3 Dec 2014 21:31:03 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141204013102.GA31385@andromeda.dapyr.net>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141201170151.GK3180@laptop.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 12:01:51PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 02:32:44PM +0100, Olaf Hering wrote:
> > On Mon, Dec 01, Olaf Hering wrote:
> > 
> > > # xl pci-assignable-add 01:10.0
> > > # xl pci-assignable-list
> > > 0000:01:10.0
> > > # xl create -f domU.cfg
> > > # xl console domU
> > > ## lspci gives just emulated PCI devices
> > 
> > ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> > 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> > 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev ff)
> > 
> > > ## detach from domU console
> > > # xl pci-attach domU 0000:01:10.0
> > > # xl pci-list domU
> > > Vdev Device
> > > 04.0 0000:01:10.0
> > > 
> > > # xl console domU
> > > ## lspci gives just emulated PCI devices
> > 
> > ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> > 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> > 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 01)
> > 
> > > ## detach from domU console
> > > # xl pci-detach domU 0000:01:10.0
> > Now lspci shows that the emulated network card is gone.
> 
> > ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> > 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> > 
> > > # xl pci-attach domU 0000:01:10.0
> > > # xl pci-list domU
> > > Vdev Device
> > > 04.0 0000:01:10.0
> > > # xl console domU
> > > ## lspci shows now also the assigned host device
> > 
> > 
> > So the actual bug is that the very first time after pci-attach the guests
> > "00:04.0" PCI device is (most likely) replaced with the host PCI device. Just
> > the guest does not notice that "00:04.0" was actually already gone after unplug.
> 
> That is odd - I see any device 'hot-plugged' being added at 00:05 and further.

I have to apologize. The reason it works for me is because the emulated
device gets unplugged quite early:

# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446

[and here I run 'xl pci-attach USB 00:1a.0]

# [   30.609802] hpet1: lost 1589 rtc interrupts
[   30.672030] hpet1: lost 2200 rtc interrupts
[   30.672030] hpet1: lost 2201 rtc interrupts
[   30.672030] hpet1: lost 2200 rtc interrupts
[   30.899341] pci 0000:00:04.0: [8086:1c2d] type 00 class 0x0c0320

And the other test I have been running is when the guest is booted
with an PCI device (and then unplugged):

# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
00:05.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 04)

But oddly enough when I do 'pci-detach' and then 'pci-attach' I get:
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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
00:04.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 04)

so something is busted as you surmised

And it looks to be busted in two cases - I see the 'hpet1' issues
and the guest then crashes!
> 
> > 
> > I wonder why the unplug code in xen_platform.c does just a qdev_free() instead
> > of a real pci-detach kind of thing. I'm sure this could be done at least for
> > emulated network cards.
> > 
> > Olaf
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@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 Dec 04 01:47:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 01: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 1XwLVj-00085c-EA; Thu, 04 Dec 2014 01:47:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XwLVi-00085X-G6
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 01:47:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9D/F7-25276-12DBF745; Thu, 04 Dec 2014 01:47:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417657631!13270908!1
X-Originating-IP: [156.151.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 1355 invoked from network); 4 Dec 2014 01:47:13 -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; 4 Dec 2014 01:47: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 sB41kwhj006161
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 01:46:59 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
	sB41kvYJ001581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2014 01:46:57 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
	sB41kuq1015476; Thu, 4 Dec 2014 01:46:56 GMT
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 17:46:55 -0800
Date: Wed, 3 Dec 2014 20:46:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20141204014650.GA26886@konrad-lan.dumpdata.com>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
	<20141204013102.GA31385@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141204013102.GA31385@andromeda.dapyr.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first 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 Wed, Dec 03, 2014 at 09:31:03PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 12:01:51PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Dec 01, 2014 at 02:32:44PM +0100, Olaf Hering wrote:
> > > On Mon, Dec 01, Olaf Hering wrote:
> > > 
> > > > # xl pci-assignable-add 01:10.0
> > > > # xl pci-assignable-list
> > > > 0000:01:10.0
> > > > # xl create -f domU.cfg
> > > > # xl console domU
> > > > ## lspci gives just emulated PCI devices
> > > 
> > > ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> > > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> > > 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> > > 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev ff)
> > > 
> > > > ## detach from domU console
> > > > # xl pci-attach domU 0000:01:10.0
> > > > # xl pci-list domU
> > > > Vdev Device
> > > > 04.0 0000:01:10.0
> > > > 
> > > > # xl console domU
> > > > ## lspci gives just emulated PCI devices
> > > 
> > > ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> > > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> > > 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> > > 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 01)
> > > 
> > > > ## detach from domU console
> > > > # xl pci-detach domU 0000:01:10.0
> > > Now lspci shows that the emulated network card is gone.
> > 
> > > ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> > > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> > > 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> > > 
> > > > # xl pci-attach domU 0000:01:10.0
> > > > # xl pci-list domU
> > > > Vdev Device
> > > > 04.0 0000:01:10.0
> > > > # xl console domU
> > > > ## lspci shows now also the assigned host device
> > > 
> > > 
> > > So the actual bug is that the very first time after pci-attach the guests
> > > "00:04.0" PCI device is (most likely) replaced with the host PCI device. Just
> > > the guest does not notice that "00:04.0" was actually already gone after unplug.
> > 
> > That is odd - I see any device 'hot-plugged' being added at 00:05 and further.
> 
> I have to apologize. The reason it works for me is because the emulated
> device gets unplugged quite early:
> 
> # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 
> [and here I run 'xl pci-attach USB 00:1a.0]
> 
> # [   30.609802] hpet1: lost 1589 rtc interrupts
> [   30.672030] hpet1: lost 2200 rtc interrupts
> [   30.672030] hpet1: lost 2201 rtc interrupts
> [   30.672030] hpet1: lost 2200 rtc interrupts
> [   30.899341] pci 0000:00:04.0: [8086:1c2d] type 00 class 0x0c0320
> 
> And the other test I have been running is when the guest is booted
> with an PCI device (and then unplugged):
> 
> # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
> 00:02.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
> 00:05.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 04)
> 
> But oddly enough when I do 'pci-detach' and then 'pci-attach' I get:
> 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
> 00:02.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
> 00:04.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 04)
> 
> so something is busted as you surmised
> 
> And it looks to be busted in two cases - I see the 'hpet1' issues
> and the guest then crashes!

But that only shows up on this particular machine. If I use VFs and
unplug/plug it works OK.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 01:47:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 01: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 1XwLVj-00085c-EA; Thu, 04 Dec 2014 01:47:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XwLVi-00085X-G6
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 01:47:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9D/F7-25276-12DBF745; Thu, 04 Dec 2014 01:47:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417657631!13270908!1
X-Originating-IP: [156.151.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 1355 invoked from network); 4 Dec 2014 01:47:13 -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; 4 Dec 2014 01:47: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 sB41kwhj006161
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 01:46:59 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
	sB41kvYJ001581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2014 01:46:57 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
	sB41kuq1015476; Thu, 4 Dec 2014 01:46:56 GMT
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 03 Dec 2014 17:46:55 -0800
Date: Wed, 3 Dec 2014 20:46:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20141204014650.GA26886@konrad-lan.dumpdata.com>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
	<20141204013102.GA31385@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141204013102.GA31385@andromeda.dapyr.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first 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 Wed, Dec 03, 2014 at 09:31:03PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 12:01:51PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Dec 01, 2014 at 02:32:44PM +0100, Olaf Hering wrote:
> > > On Mon, Dec 01, Olaf Hering wrote:
> > > 
> > > > # xl pci-assignable-add 01:10.0
> > > > # xl pci-assignable-list
> > > > 0000:01:10.0
> > > > # xl create -f domU.cfg
> > > > # xl console domU
> > > > ## lspci gives just emulated PCI devices
> > > 
> > > ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> > > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> > > 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> > > 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev ff)
> > > 
> > > > ## detach from domU console
> > > > # xl pci-attach domU 0000:01:10.0
> > > > # xl pci-list domU
> > > > Vdev Device
> > > > 04.0 0000:01:10.0
> > > > 
> > > > # xl console domU
> > > > ## lspci gives just emulated PCI devices
> > > 
> > > ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> > > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> > > 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> > > 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 01)
> > > 
> > > > ## detach from domU console
> > > > # xl pci-detach domU 0000:01:10.0
> > > Now lspci shows that the emulated network card is gone.
> > 
> > > ttyS0:Rescue:~ # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> > > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> > > 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> > > 
> > > > # xl pci-attach domU 0000:01:10.0
> > > > # xl pci-list domU
> > > > Vdev Device
> > > > 04.0 0000:01:10.0
> > > > # xl console domU
> > > > ## lspci shows now also the assigned host device
> > > 
> > > 
> > > So the actual bug is that the very first time after pci-attach the guests
> > > "00:04.0" PCI device is (most likely) replaced with the host PCI device. Just
> > > the guest does not notice that "00:04.0" was actually already gone after unplug.
> > 
> > That is odd - I see any device 'hot-plugged' being added at 00:05 and further.
> 
> I have to apologize. The reason it works for me is because the emulated
> device gets unplugged quite early:
> 
> # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 
> [and here I run 'xl pci-attach USB 00:1a.0]
> 
> # [   30.609802] hpet1: lost 1589 rtc interrupts
> [   30.672030] hpet1: lost 2200 rtc interrupts
> [   30.672030] hpet1: lost 2201 rtc interrupts
> [   30.672030] hpet1: lost 2200 rtc interrupts
> [   30.899341] pci 0000:00:04.0: [8086:1c2d] type 00 class 0x0c0320
> 
> And the other test I have been running is when the guest is booted
> with an PCI device (and then unplugged):
> 
> # 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
> 00:02.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
> 00:05.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 04)
> 
> But oddly enough when I do 'pci-detach' and then 'pci-attach' I get:
> 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
> 00:02.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
> 00:04.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 04)
> 
> so something is busted as you surmised
> 
> And it looks to be busted in two cases - I see the 'hpet1' issues
> and the guest then crashes!

But that only shows up on this particular machine. If I use VFs and
unplug/plug it works OK.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 01:50:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 01:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwLYf-0008CA-16; Thu, 04 Dec 2014 01:50:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1XwLYd-0008C3-IU
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 01:50:15 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	7A/34-14727-6DDBF745; Thu, 04 Dec 2014 01:50:14 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417657812!11410644!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32547 invoked from network); 4 Dec 2014 01:50:13 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-206.messagelabs.com with SMTP;
	4 Dec 2014 01:50:13 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2014 17:50:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="424811874"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
	by FMSMGA003.fm.intel.com with ESMTP; 03 Dec 2014 17:39:51 -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; Thu, 4 Dec 2014 09:50:08 +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; Thu, 4 Dec 2014 09:50:06 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [v4] libxc: Expose the 1GB pages cpuid flag to guest
Thread-Index: AQHQDz6aHN6mmrBrwkaQMp5zyWZGe5x+qWJg
Date: Thu, 4 Dec 2014 01:50:06 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABF82AB@SHSMSX104.ccr.corp.intel.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
	<1417175443.23604.18.camel@citrix.com>
	<20141202210941.GA1593@laptop.dumpdata.com>
	<1417599529.29004.16.camel@citrix.com>
	<20141203155744.GE3081@laptop.dumpdata.com>
In-Reply-To: <20141203155744.GE3081@laptop.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_A9667DDFB95DB7438FA9D7D576C3D87E0ABF82ABSHSMSX104ccrcor_"
MIME-Version: 1.0
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Li, Liang Z" <liang.z.li@intel.com>,
	"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>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Konrad Rzeszutek Wilk wrote on 2014-12-03:
> On Wed, Dec 03, 2014 at 09:38:49AM +0000, Ian Campbell wrote:
>> On Tue, 2014-12-02 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Nov 28, 2014 at 11:50:43AM +0000, Ian Campbell wrote:
>>>> 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=3D ' option in config fil
>>>>> e to turn it on.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Signed-off-by: Liang Li <liang.z.li@intel.com>
>>>>> Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
>>>>=20
>>>> FTR although this is strictly speaking a toolstack patch I think the
>>>> main ack required should be from the x86 hypervisor guys...
>>>=20
>>> Jan acked it.
>>=20
>> For 4.5?
>=20
> Probably not.
>>=20
>> Have you release acked it?
>=20
> No.
>>=20
>> This seemed like 4.6 material to me, or at least I've not seen any
>> mention/argument to the contrary.
>=20
> Correct. 4.6 please.

I think this more like a bug fixing than a feature. See our previous discus=
sion.

>>=20
>> Ian.
>>=20
>>>>=20
>>>>> ---
>>>>>  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] &=3D (0x0183f3ff | /* features shared with
> 0x00000001:EDX */
>>>>>                      bitmaskof(X86_FEATURE_NX) |
>>>>>                      bitmaskof(X86_FEATURE_LM) | +                 =20
>>>>>                       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] &=3D
>>>>>                      (bitmaskof(X86_FEATURE_NX) |
>>>>>                      bitmaskof(X86_FEATURE_LM) | +                 =20
>>>>>                       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;
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xen.org
>>>> http://lists.xen.org/xen-devel
>>=20
>>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


Best regards,
Yang



--_002_A9667DDFB95DB7438FA9D7D576C3D87E0ABF82ABSHSMSX104ccrcor_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Thu, 04 Dec 2014 01:50:06 GMT";
	modification-date="Thu, 04 Dec 2014 01:50:06 GMT"

Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by
 SHSMSX103.ccr.corp.intel.com (10.239.4.69) with Microsoft SMTP Server (TLS)
 id 14.3.123.3; Thu, 16 Jan 2014 04:10:40 +0800
Received: from orsmsx103.amr.corp.intel.com (10.22.225.130) by
 fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS)
 id 14.3.123.3; Wed, 15 Jan 2014 12:10:38 -0800
Received: from orsmga001.jf.intel.com (10.7.209.18) by
 ORSMSX103-1.jf.intel.com (10.22.225.130) with Microsoft SMTP Server id
 14.3.123.3; Wed, 15 Jan 2014 12:10:38 -0800
Received: from orsmga102-1.jf.intel.com (HELO mga09.intel.com) ([10.7.208.27])
  by orsmga001-1.jf.intel.com with ESMTP; 15 Jan 2014 12:10:32 -0800
Received: from lists.xen.org ([50.57.142.19])  by mga09.intel.com with ESMTP;
 15 Jan 2014 12:06:04 -0800
Received: from localhost ([127.0.0.1] helo=lists.xen.org)	by lists.xen.org
 with esmtp (Exim 4.72)	(envelope-from <xen-devel-bounces@lists.xen.org>)	id
 1W3Wle-0003ps-Tp; Wed, 15 Jan 2014 20:08: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 1W3Wlb-0003pn-L5	for xen-devel@lists.xenproject.org; Wed, 15 Jan 2014
 20:08:47 +0000
Received: from [85.158.137.68:46466] by server-17.bemta-3.messagelabs.com id
	1E/15-15965-ECAE6D25; Wed, 15 Jan 2014 20:08:46 +0000
Received: (qmail 5215 invoked from network); 15 Jan 2014 20:08:45 -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; 15 Jan 2014 20:08: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
 s0FK7dwh015819	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
 verify=OK);	Wed, 15 Jan 2014 20:07:39 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	s0FK7c7S013823
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);	Wed, 15
 Jan 2014 20:07:38 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	s0FK7bEE008344; Wed,
 15 Jan 2014 20:07:37 GMT
Received: from phenom.dumpdata.com (/50.195.21.189)	by default (Oracle Beehive
 Gateway v4.0)	with ESMTP ; Wed, 15 Jan 2014 12:07:37 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)	id 7F72B1BFB4A;
 Wed, 15 Jan 2014 15:07:36 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>, "Nakajima, Jun" <jun.nakajima@intel.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
 disables it.
Thread-Topic: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
 disables it.
Thread-Index: AQHPEi3cJLkYs2VhL0qN3zw8dITRcA==
Sender: "xen-devel-bounces@lists.xen.org" <xen-devel-bounces@lists.xen.org>
Date: Wed, 15 Jan 2014 20:07:36 +0000
Message-ID: <20140115200736.GB5201@phenom.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>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
In-Reply-To: <52D3E1500200007800113058@nat28.tlf.novell.com>
Content-Language: en-US
X-MS-Exchange-Organization-AuthSource: ORSMSX103.amr.corp.intel.com
X-MS-Has-Attach: 
X-Auto-Response-Suppress: All
X-MS-TNEF-Correlator: 
user-agent: Mutt/1.5.21 (2010-09-15)
x-ironport-av: E=Sophos;i="4.95,664,1384329600";
    d="scan'208";a="133570250"
list-post: <mailto:xen-devel@lists.xen.org>
list-id: Xen developer discussion <xen-devel.lists.xen.org>
x-beenthere: xen-devel@lists.xen.org
x-mailman-version: 2.1.13
errors-to: xen-devel-bounces@lists.xen.org
x-ironport-anti-spam-filtered: true
x-ironport-anti-spam-result: AgUCAM/q1lIyOY4TnGdsb2JhbABZg0NWvB0WDgEBAQEBCAsJCRQogiUBAQEBAwEBATcMCh4LAwMBAgYBAQoOCgkVBAQIAwELBRQEMRMFh38EAaZtAQGcUheSKoETAQOJR4wIglABgTCJG4ISiQOCDA
x-originating-ip: [156.151.31.81]
x-source-ip: ucsinet22.oracle.com [156.151.31.94]
x-spamreason: No, hits=0.0 required=7.0 tests=sa_preprocessor:
 	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
x-starscan-version: 6.9.16; banners=-,-,-
x-viruschecked: Checked
x-env-sender: konrad.wilk@oracle.com
x-msg-ref: server-4.tower-31.messagelabs.com!1389816523!9383604!1
Content-Type: text/plain; charset="us-ascii"
Content-ID: <ECBF4C3BD1EBB54EBBE9654213D47EA3@intel.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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 =3D hypervisor_is_64bit(xch) && is_pae;
> >
> >                 /* Only a few features are advertised in Intel's 0x8000=
0001. */
> >                 regs[2] &=3D (is_64bit ? bitmaskof(X86_FEATURE_LAHF_LM)=
 : 0) |
> >                                        bitmaskof(X86_FEATURE_ABM);
> >                 regs[3] &=3D ((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] &=3D (0x0183f3ff | /* features shared with 0x00000001:E=
DX */
> >                     (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?
>
> Jan
>

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

--_002_A9667DDFB95DB7438FA9D7D576C3D87E0ABF82ABSHSMSX104ccrcor_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_A9667DDFB95DB7438FA9D7D576C3D87E0ABF82ABSHSMSX104ccrcor_--


From xen-devel-bounces@lists.xen.org Thu Dec 04 01:50:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 01:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwLYf-0008CA-16; Thu, 04 Dec 2014 01:50:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1XwLYd-0008C3-IU
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 01:50:15 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	7A/34-14727-6DDBF745; Thu, 04 Dec 2014 01:50:14 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417657812!11410644!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32547 invoked from network); 4 Dec 2014 01:50:13 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-206.messagelabs.com with SMTP;
	4 Dec 2014 01:50:13 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2014 17:50:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="424811874"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
	by FMSMGA003.fm.intel.com with ESMTP; 03 Dec 2014 17:39:51 -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; Thu, 4 Dec 2014 09:50:08 +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; Thu, 4 Dec 2014 09:50:06 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [v4] libxc: Expose the 1GB pages cpuid flag to guest
Thread-Index: AQHQDz6aHN6mmrBrwkaQMp5zyWZGe5x+qWJg
Date: Thu, 4 Dec 2014 01:50:06 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABF82AB@SHSMSX104.ccr.corp.intel.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
	<1417175443.23604.18.camel@citrix.com>
	<20141202210941.GA1593@laptop.dumpdata.com>
	<1417599529.29004.16.camel@citrix.com>
	<20141203155744.GE3081@laptop.dumpdata.com>
In-Reply-To: <20141203155744.GE3081@laptop.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_A9667DDFB95DB7438FA9D7D576C3D87E0ABF82ABSHSMSX104ccrcor_"
MIME-Version: 1.0
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Li, Liang Z" <liang.z.li@intel.com>,
	"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>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Konrad Rzeszutek Wilk wrote on 2014-12-03:
> On Wed, Dec 03, 2014 at 09:38:49AM +0000, Ian Campbell wrote:
>> On Tue, 2014-12-02 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Nov 28, 2014 at 11:50:43AM +0000, Ian Campbell wrote:
>>>> 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=3D ' option in config fil
>>>>> e to turn it on.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Signed-off-by: Liang Li <liang.z.li@intel.com>
>>>>> Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
>>>>=20
>>>> FTR although this is strictly speaking a toolstack patch I think the
>>>> main ack required should be from the x86 hypervisor guys...
>>>=20
>>> Jan acked it.
>>=20
>> For 4.5?
>=20
> Probably not.
>>=20
>> Have you release acked it?
>=20
> No.
>>=20
>> This seemed like 4.6 material to me, or at least I've not seen any
>> mention/argument to the contrary.
>=20
> Correct. 4.6 please.

I think this more like a bug fixing than a feature. See our previous discus=
sion.

>>=20
>> Ian.
>>=20
>>>>=20
>>>>> ---
>>>>>  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] &=3D (0x0183f3ff | /* features shared with
> 0x00000001:EDX */
>>>>>                      bitmaskof(X86_FEATURE_NX) |
>>>>>                      bitmaskof(X86_FEATURE_LM) | +                 =20
>>>>>                       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] &=3D
>>>>>                      (bitmaskof(X86_FEATURE_NX) |
>>>>>                      bitmaskof(X86_FEATURE_LM) | +                 =20
>>>>>                       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;
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xen.org
>>>> http://lists.xen.org/xen-devel
>>=20
>>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


Best regards,
Yang



--_002_A9667DDFB95DB7438FA9D7D576C3D87E0ABF82ABSHSMSX104ccrcor_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Thu, 04 Dec 2014 01:50:06 GMT";
	modification-date="Thu, 04 Dec 2014 01:50:06 GMT"

Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by
 SHSMSX103.ccr.corp.intel.com (10.239.4.69) with Microsoft SMTP Server (TLS)
 id 14.3.123.3; Thu, 16 Jan 2014 04:10:40 +0800
Received: from orsmsx103.amr.corp.intel.com (10.22.225.130) by
 fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS)
 id 14.3.123.3; Wed, 15 Jan 2014 12:10:38 -0800
Received: from orsmga001.jf.intel.com (10.7.209.18) by
 ORSMSX103-1.jf.intel.com (10.22.225.130) with Microsoft SMTP Server id
 14.3.123.3; Wed, 15 Jan 2014 12:10:38 -0800
Received: from orsmga102-1.jf.intel.com (HELO mga09.intel.com) ([10.7.208.27])
  by orsmga001-1.jf.intel.com with ESMTP; 15 Jan 2014 12:10:32 -0800
Received: from lists.xen.org ([50.57.142.19])  by mga09.intel.com with ESMTP;
 15 Jan 2014 12:06:04 -0800
Received: from localhost ([127.0.0.1] helo=lists.xen.org)	by lists.xen.org
 with esmtp (Exim 4.72)	(envelope-from <xen-devel-bounces@lists.xen.org>)	id
 1W3Wle-0003ps-Tp; Wed, 15 Jan 2014 20:08: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 1W3Wlb-0003pn-L5	for xen-devel@lists.xenproject.org; Wed, 15 Jan 2014
 20:08:47 +0000
Received: from [85.158.137.68:46466] by server-17.bemta-3.messagelabs.com id
	1E/15-15965-ECAE6D25; Wed, 15 Jan 2014 20:08:46 +0000
Received: (qmail 5215 invoked from network); 15 Jan 2014 20:08:45 -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; 15 Jan 2014 20:08: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
 s0FK7dwh015819	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
 verify=OK);	Wed, 15 Jan 2014 20:07:39 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	s0FK7c7S013823
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);	Wed, 15
 Jan 2014 20:07:38 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	s0FK7bEE008344; Wed,
 15 Jan 2014 20:07:37 GMT
Received: from phenom.dumpdata.com (/50.195.21.189)	by default (Oracle Beehive
 Gateway v4.0)	with ESMTP ; Wed, 15 Jan 2014 12:07:37 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)	id 7F72B1BFB4A;
 Wed, 15 Jan 2014 15:07:36 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>, "Nakajima, Jun" <jun.nakajima@intel.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
 disables it.
Thread-Topic: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default
 disables it.
Thread-Index: AQHPEi3cJLkYs2VhL0qN3zw8dITRcA==
Sender: "xen-devel-bounces@lists.xen.org" <xen-devel-bounces@lists.xen.org>
Date: Wed, 15 Jan 2014 20:07:36 +0000
Message-ID: <20140115200736.GB5201@phenom.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>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
In-Reply-To: <52D3E1500200007800113058@nat28.tlf.novell.com>
Content-Language: en-US
X-MS-Exchange-Organization-AuthSource: ORSMSX103.amr.corp.intel.com
X-MS-Has-Attach: 
X-Auto-Response-Suppress: All
X-MS-TNEF-Correlator: 
user-agent: Mutt/1.5.21 (2010-09-15)
x-ironport-av: E=Sophos;i="4.95,664,1384329600";
    d="scan'208";a="133570250"
list-post: <mailto:xen-devel@lists.xen.org>
list-id: Xen developer discussion <xen-devel.lists.xen.org>
x-beenthere: xen-devel@lists.xen.org
x-mailman-version: 2.1.13
errors-to: xen-devel-bounces@lists.xen.org
x-ironport-anti-spam-filtered: true
x-ironport-anti-spam-result: AgUCAM/q1lIyOY4TnGdsb2JhbABZg0NWvB0WDgEBAQEBCAsJCRQogiUBAQEBAwEBATcMCh4LAwMBAgYBAQoOCgkVBAQIAwELBRQEMRMFh38EAaZtAQGcUheSKoETAQOJR4wIglABgTCJG4ISiQOCDA
x-originating-ip: [156.151.31.81]
x-source-ip: ucsinet22.oracle.com [156.151.31.94]
x-spamreason: No, hits=0.0 required=7.0 tests=sa_preprocessor:
 	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n
x-starscan-version: 6.9.16; banners=-,-,-
x-viruschecked: Checked
x-env-sender: konrad.wilk@oracle.com
x-msg-ref: server-4.tower-31.messagelabs.com!1389816523!9383604!1
Content-Type: text/plain; charset="us-ascii"
Content-ID: <ECBF4C3BD1EBB54EBBE9654213D47EA3@intel.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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 =3D hypervisor_is_64bit(xch) && is_pae;
> >
> >                 /* Only a few features are advertised in Intel's 0x8000=
0001. */
> >                 regs[2] &=3D (is_64bit ? bitmaskof(X86_FEATURE_LAHF_LM)=
 : 0) |
> >                                        bitmaskof(X86_FEATURE_ABM);
> >                 regs[3] &=3D ((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] &=3D (0x0183f3ff | /* features shared with 0x00000001:E=
DX */
> >                     (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?
>
> Jan
>

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

--_002_A9667DDFB95DB7438FA9D7D576C3D87E0ABF82ABSHSMSX104ccrcor_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_A9667DDFB95DB7438FA9D7D576C3D87E0ABF82ABSHSMSX104ccrcor_--


From xen-devel-bounces@lists.xen.org Thu Dec 04 02:48:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 02: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 1XwMSQ-0001J0-ON; Thu, 04 Dec 2014 02:47:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jike.song@intel.com>) id 1XwMSP-0001Iv-Fv
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 02:47:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	56/7F-25276-85BCF745; Thu, 04 Dec 2014 02:47:52 +0000
X-Env-Sender: jike.song@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417661270!12924659!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30632 invoked from network); 4 Dec 2014 02:47:51 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-21.messagelabs.com with SMTP;
	4 Dec 2014 02:47:51 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2014 18:47:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,512,1413270000"; d="scan'208";a="632397549"
Received: from git1.bj.intel.com ([10.238.135.214])
	by fmsmga001.fm.intel.com with ESMTP; 03 Dec 2014 18:47:47 -0800
Message-ID: <547FCAAD.2060406@intel.com>
Date: Thu, 04 Dec 2014 10:45:01 +0800
From: Jike Song <jike.song@intel.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: xen-devel@lists.xen.org, intel-gfx@lists.freedesktop.org, 
	linux-kernel@vger.kernel.org
References: <53D215D3.50608@intel.com>
In-Reply-To: <53D215D3.50608@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, "White,
	Michael L" <michael.l.white@intel.com>, "Dong,
	Eddie" <eddie.dong@intel.com>, "Li, Susie" <susie.li@intel.com>,
	"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>,
	"Zhou, Chao" <chao.zhou@intel.com>, "Haron,
	Sandra" <sandra.haron@intel.com>, "Zhu, Libo" <libo.zhu@intel.com>
Subject: Re: [Xen-devel] [Intel-gfx] [Announcement] 2014-Q3 release of XenGT
 - a Mediated Graphics Passthrough Solution from Intel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

We're pleased to announce a public release to Intel Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution with mediated pass-through, supported today on 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance among performance, feature, and sharing capability. Though we only support Xen on Intel Processor Graphics so far, the core logic can be easily ported to other hypervisors.


The news of this update:


	- kernel update from 3.11.6 to 3.14.1

	- We plan to integrate Intel GVT-g as a feature in i915 driver. That effort is still under review, not included in this update yet

	- Next update will be around early Jan, 2015


This update consists of:

	- Windows HVM support with driver version 15.33.3910

	- Stability fixes, e.g. stabilize GPU, the GPU hang occurrence rate becomes rare now

	- Hardware Media Acceleration for Decoding/Encoding/Transcoding, VC1, H264 etc. format supporting

	- Display enhancements, e.g. DP type is supported for virtual PORT

	- Display port capability virtualization: with this feature, dom0 manager could freely assign virtual DDI ports to VM, not necessary to check whether the corresponding physical DDI ports are available



Please refer to the new setup guide, which provides step-to-step details about building/configuring/running Intel GVT-g:


	https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide.pdf



The new source codes are available at the updated github repos:


	Linux: https://github.com/01org/XenGT-Preview-kernel.git

	Xen: https://github.com/01org/XenGT-Preview-xen.git

	Qemu: https://github.com/01org/XenGT-Preview-qemu.git


More information about Intel GVT-g background, architecture, etc can be found at:


	https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian

	http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf

	https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt


The previous update can be found here:


	http://lists.xen.org/archives/html/xen-devel/2014-07/msg03248.html


Appreciate your comments!


--
Thanks,
Jike

On 07/25/2014 04:31 PM, Jike Song wrote:
> Hi all,
>
> We're pleased to announce an update to Intel Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution with mediated pass-through, supported today on 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance among performance, feature, and sharing capability. Though we only support Xen on Intel Processor Graphics so far, the core logic can be easily ported to other hypervisors.
>
> The news of this update:
>
> 	- Project code name is "XenGT", now official name is Intel Graphics Virtualization Technology (Intel GVT-g)
> 	- Currently Intel GVT-g supports Intel Processor Graphics built into 4th generation Intel Core processors - Haswell platform
> 	- Moving forward, XenGT will change to quarterly release cadence. Next update will be around early October, 2014.
>
> This update consists of:
>
> 	- Stability fixes, e.g. stable DP support
> 	- Display enhancements, e.g. virtual monitor support. Users can define a virtual monitor type with customized EDID for virtual machines, not necessarily the same as physical monitors.
> 	- Improved support for GPU recovery
> 	- Experimental Windows HVM support. To download the experimental version, see setup guide for details
> 	- Experimental Hardware Media Acceleration for decoding.
>
>
> Please refer to the new setup guide, which provides step-to-step details about building/configuring/running Intel GVT-g:
>
> 	https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide.pdf
>
>
> The new source codes are available at the updated github repos:
>
> 	Linux: https://github.com/01org/XenGT-Preview-kernel.git
> 	Xen: https://github.com/01org/XenGT-Preview-xen.git
> 	Qemu: https://github.com/01org/XenGT-Preview-qemu.git
>
>
> More information about Intel GVT-g background, architecture, etc can be found at:
>
> 	https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
> 	http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf
> 	https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
>
> The previous update can be found here:
>
> 	http://lists.xen.org/archives/html/xen-devel/2014-02/msg01848.html
>
> Appreciate your comments!
>
>
>
>
> --
> Thanks,
> Jike
>

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 02:48:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 02: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 1XwMSQ-0001J0-ON; Thu, 04 Dec 2014 02:47:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jike.song@intel.com>) id 1XwMSP-0001Iv-Fv
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 02:47:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	56/7F-25276-85BCF745; Thu, 04 Dec 2014 02:47:52 +0000
X-Env-Sender: jike.song@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417661270!12924659!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30632 invoked from network); 4 Dec 2014 02:47:51 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-21.messagelabs.com with SMTP;
	4 Dec 2014 02:47:51 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2014 18:47:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,512,1413270000"; d="scan'208";a="632397549"
Received: from git1.bj.intel.com ([10.238.135.214])
	by fmsmga001.fm.intel.com with ESMTP; 03 Dec 2014 18:47:47 -0800
Message-ID: <547FCAAD.2060406@intel.com>
Date: Thu, 04 Dec 2014 10:45:01 +0800
From: Jike Song <jike.song@intel.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: xen-devel@lists.xen.org, intel-gfx@lists.freedesktop.org, 
	linux-kernel@vger.kernel.org
References: <53D215D3.50608@intel.com>
In-Reply-To: <53D215D3.50608@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, "White,
	Michael L" <michael.l.white@intel.com>, "Dong,
	Eddie" <eddie.dong@intel.com>, "Li, Susie" <susie.li@intel.com>,
	"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>,
	"Zhou, Chao" <chao.zhou@intel.com>, "Haron,
	Sandra" <sandra.haron@intel.com>, "Zhu, Libo" <libo.zhu@intel.com>
Subject: Re: [Xen-devel] [Intel-gfx] [Announcement] 2014-Q3 release of XenGT
 - a Mediated Graphics Passthrough Solution from Intel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

We're pleased to announce a public release to Intel Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution with mediated pass-through, supported today on 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance among performance, feature, and sharing capability. Though we only support Xen on Intel Processor Graphics so far, the core logic can be easily ported to other hypervisors.


The news of this update:


	- kernel update from 3.11.6 to 3.14.1

	- We plan to integrate Intel GVT-g as a feature in i915 driver. That effort is still under review, not included in this update yet

	- Next update will be around early Jan, 2015


This update consists of:

	- Windows HVM support with driver version 15.33.3910

	- Stability fixes, e.g. stabilize GPU, the GPU hang occurrence rate becomes rare now

	- Hardware Media Acceleration for Decoding/Encoding/Transcoding, VC1, H264 etc. format supporting

	- Display enhancements, e.g. DP type is supported for virtual PORT

	- Display port capability virtualization: with this feature, dom0 manager could freely assign virtual DDI ports to VM, not necessary to check whether the corresponding physical DDI ports are available



Please refer to the new setup guide, which provides step-to-step details about building/configuring/running Intel GVT-g:


	https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide.pdf



The new source codes are available at the updated github repos:


	Linux: https://github.com/01org/XenGT-Preview-kernel.git

	Xen: https://github.com/01org/XenGT-Preview-xen.git

	Qemu: https://github.com/01org/XenGT-Preview-qemu.git


More information about Intel GVT-g background, architecture, etc can be found at:


	https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian

	http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf

	https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt


The previous update can be found here:


	http://lists.xen.org/archives/html/xen-devel/2014-07/msg03248.html


Appreciate your comments!


--
Thanks,
Jike

On 07/25/2014 04:31 PM, Jike Song wrote:
> Hi all,
>
> We're pleased to announce an update to Intel Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution with mediated pass-through, supported today on 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance among performance, feature, and sharing capability. Though we only support Xen on Intel Processor Graphics so far, the core logic can be easily ported to other hypervisors.
>
> The news of this update:
>
> 	- Project code name is "XenGT", now official name is Intel Graphics Virtualization Technology (Intel GVT-g)
> 	- Currently Intel GVT-g supports Intel Processor Graphics built into 4th generation Intel Core processors - Haswell platform
> 	- Moving forward, XenGT will change to quarterly release cadence. Next update will be around early October, 2014.
>
> This update consists of:
>
> 	- Stability fixes, e.g. stable DP support
> 	- Display enhancements, e.g. virtual monitor support. Users can define a virtual monitor type with customized EDID for virtual machines, not necessarily the same as physical monitors.
> 	- Improved support for GPU recovery
> 	- Experimental Windows HVM support. To download the experimental version, see setup guide for details
> 	- Experimental Hardware Media Acceleration for decoding.
>
>
> Please refer to the new setup guide, which provides step-to-step details about building/configuring/running Intel GVT-g:
>
> 	https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide.pdf
>
>
> The new source codes are available at the updated github repos:
>
> 	Linux: https://github.com/01org/XenGT-Preview-kernel.git
> 	Xen: https://github.com/01org/XenGT-Preview-xen.git
> 	Qemu: https://github.com/01org/XenGT-Preview-qemu.git
>
>
> More information about Intel GVT-g background, architecture, etc can be found at:
>
> 	https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
> 	http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf
> 	https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
>
> The previous update can be found here:
>
> 	http://lists.xen.org/archives/html/xen-devel/2014-02/msg01848.html
>
> Appreciate your comments!
>
>
>
>
> --
> Thanks,
> Jike
>

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 03:50:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 03: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 1XwNQZ-0002UK-SU; Thu, 04 Dec 2014 03:50:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.kilari@gmail.com>) id 1XwNQY-0002UF-Pq
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 03:50:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	99/BA-09842-AE9DF745; Thu, 04 Dec 2014 03:50:02 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417665000!13281124!1
X-Originating-IP: [209.85.223.170]
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 8689 invoked from network); 4 Dec 2014 03:50:01 -0000
Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com)
	(209.85.223.170)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 03:50:01 -0000
Received: by mail-ie0-f170.google.com with SMTP id rd18so15049543iec.29
	for <xen-devel@lists.xen.org>; Wed, 03 Dec 2014 19:50:00 -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:cc:content-type;
	bh=8mSgTNN+2pe4hIMRt6TXlLRGpnY1u96sNdfW7RRJ0mU=;
	b=Xn7E0Je3F0CS4nGpOgVfOGUs38ry4S3cm1Du4uF/s0kDOfHnKZg6n1cs7wlvxJyErk
	wMrb6B88emGnI6ht34DLbSojN5fPyl76fHOAo8zrKcgjjPn5EQefdL/hDNZsMp2uAqN5
	LmrMfn6URpE7/9q0KVa39hSEW4cKg1tmUvFJZBEPrQYjKdjIlgD+hBvCVZytv4xgM8yW
	Nw3N10Xt5tyrihZbLYf07OyFjBOjUk/T5VmRbfU7A1XisbWI7A35lhme9298M7+WOpfm
	o5r5cG9A+1p2SY5HoBr+HWVUQ0c6OhZS+aGee8HnJt4EWnkXrcSnPiE6h43yQqRES5sX
	HngQ==
MIME-Version: 1.0
X-Received: by 10.107.36.5 with SMTP id k5mr7974487iok.4.1417665000058; Wed,
	03 Dec 2014 19:50:00 -0800 (PST)
Received: by 10.64.121.194 with HTTP; Wed, 3 Dec 2014 19:50:00 -0800 (PST)
Date: Thu, 4 Dec 2014 09:20:00 +0530
Message-ID: <CALicx6trd6Pvsit0LfbC66JU5G3r+1XTt0d-h0DLo8rd31X9vw@mail.gmail.com>
From: Vijay Kilari <vijay.kilari@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] xen/arm: uart interrupts 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 Tim,

I see that on uart interrupt, ICR is written to clear the all
interrupts except TX, RX and RX timeout. With this, cpu always finds
TX/RX is active and never
comes out of the loop.

With the below changes, TX, RX & RTI are cleared before handling this
interrupts.

Is my observation is correct?. If so I wonder how it is working on
platforms that
are using pl011. Without this for my cpu just keeps looping here.

  index fba0a55..d21bce3 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -63,7 +63,7 @@ static void pl011_interrupt(int irq, void *data,
struct cpu_user_regs *regs)
     {
         do
         {
-            pl011_write(uart, ICR, status & ~(TXI|RTI|RXI));
+            pl011_write(uart, ICR, status & (TXI|RTI|RXI));

             if ( status & (RTI|RXI) )
                 serial_rx_interrupt(port, regs);
@@ -157,7 +157,7 @@ static void pl011_resume(struct serial_port *port)
 {
     BUG(); // XXX
 }


Regards
Vijay

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 03:50:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 03: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 1XwNQZ-0002UK-SU; Thu, 04 Dec 2014 03:50:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.kilari@gmail.com>) id 1XwNQY-0002UF-Pq
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 03:50:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	99/BA-09842-AE9DF745; Thu, 04 Dec 2014 03:50:02 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417665000!13281124!1
X-Originating-IP: [209.85.223.170]
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 8689 invoked from network); 4 Dec 2014 03:50:01 -0000
Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com)
	(209.85.223.170)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 03:50:01 -0000
Received: by mail-ie0-f170.google.com with SMTP id rd18so15049543iec.29
	for <xen-devel@lists.xen.org>; Wed, 03 Dec 2014 19:50:00 -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:cc:content-type;
	bh=8mSgTNN+2pe4hIMRt6TXlLRGpnY1u96sNdfW7RRJ0mU=;
	b=Xn7E0Je3F0CS4nGpOgVfOGUs38ry4S3cm1Du4uF/s0kDOfHnKZg6n1cs7wlvxJyErk
	wMrb6B88emGnI6ht34DLbSojN5fPyl76fHOAo8zrKcgjjPn5EQefdL/hDNZsMp2uAqN5
	LmrMfn6URpE7/9q0KVa39hSEW4cKg1tmUvFJZBEPrQYjKdjIlgD+hBvCVZytv4xgM8yW
	Nw3N10Xt5tyrihZbLYf07OyFjBOjUk/T5VmRbfU7A1XisbWI7A35lhme9298M7+WOpfm
	o5r5cG9A+1p2SY5HoBr+HWVUQ0c6OhZS+aGee8HnJt4EWnkXrcSnPiE6h43yQqRES5sX
	HngQ==
MIME-Version: 1.0
X-Received: by 10.107.36.5 with SMTP id k5mr7974487iok.4.1417665000058; Wed,
	03 Dec 2014 19:50:00 -0800 (PST)
Received: by 10.64.121.194 with HTTP; Wed, 3 Dec 2014 19:50:00 -0800 (PST)
Date: Thu, 4 Dec 2014 09:20:00 +0530
Message-ID: <CALicx6trd6Pvsit0LfbC66JU5G3r+1XTt0d-h0DLo8rd31X9vw@mail.gmail.com>
From: Vijay Kilari <vijay.kilari@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] xen/arm: uart interrupts 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 Tim,

I see that on uart interrupt, ICR is written to clear the all
interrupts except TX, RX and RX timeout. With this, cpu always finds
TX/RX is active and never
comes out of the loop.

With the below changes, TX, RX & RTI are cleared before handling this
interrupts.

Is my observation is correct?. If so I wonder how it is working on
platforms that
are using pl011. Without this for my cpu just keeps looping here.

  index fba0a55..d21bce3 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -63,7 +63,7 @@ static void pl011_interrupt(int irq, void *data,
struct cpu_user_regs *regs)
     {
         do
         {
-            pl011_write(uart, ICR, status & ~(TXI|RTI|RXI));
+            pl011_write(uart, ICR, status & (TXI|RTI|RXI));

             if ( status & (RTI|RXI) )
                 serial_rx_interrupt(port, regs);
@@ -157,7 +157,7 @@ static void pl011_resume(struct serial_port *port)
 {
     BUG(); // XXX
 }


Regards
Vijay

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 05:49:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 05: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 1XwPHS-0004uU-Sf; Thu, 04 Dec 2014 05:48:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwPHQ-0004uN-Up
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 05:48:45 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	CC/1F-03145-BB5FF745; Thu, 04 Dec 2014 05:48:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417672121!8221595!1
X-Originating-IP: [66.165.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 419 invoked from network); 4 Dec 2014 05:48: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;
	4 Dec 2014 05:48:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,513,1413244800"; d="scan'208";a="199426889"
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, 4 Dec 2014 00:48: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 1XwPHM-0005r6-Cy;
	Thu, 04 Dec 2014 05:48:40 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwPHM-0005aI-5K;
	Thu, 04 Dec 2014 05:48:40 +0000
Date: Thu, 4 Dec 2014 05:48:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32058-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] 32058: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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 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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           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-qemut-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-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                    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 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 Dec 04 05:49:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 05: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 1XwPHS-0004uU-Sf; Thu, 04 Dec 2014 05:48:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwPHQ-0004uN-Up
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 05:48:45 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	CC/1F-03145-BB5FF745; Thu, 04 Dec 2014 05:48:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417672121!8221595!1
X-Originating-IP: [66.165.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 419 invoked from network); 4 Dec 2014 05:48: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;
	4 Dec 2014 05:48:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,513,1413244800"; d="scan'208";a="199426889"
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, 4 Dec 2014 00:48: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 1XwPHM-0005r6-Cy;
	Thu, 04 Dec 2014 05:48:40 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwPHM-0005aI-5K;
	Thu, 04 Dec 2014 05:48:40 +0000
Date: Thu, 4 Dec 2014 05:48:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32058-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] 32058: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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 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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           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-qemut-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-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                    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 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 Dec 04 07:48:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 07: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 1XwR93-0007FX-0H; Thu, 04 Dec 2014 07:48:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XwR91-0007FS-26
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 07:48:11 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	C7/66-19763-AB110845; Thu, 04 Dec 2014 07:48:10 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417679289!11467717!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19424 invoked from network); 4 Dec 2014 07:48:09 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Dec 2014 07:48:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417679289; l=438;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=NkzVkuX+ULqDRl/u8KULhrC72A8=;
	b=a1VqyCBCEw/QiJ76mXGPsqdZ2sbXr1/qHyeQYUasEXpqAzX8IZgbPX+rZbxA4WYX9hE
	VtTvN8EXW4I2Ru1dUycB+swgb18VPxvYDXtb6CxHO0wp5UkaV4fXPZcMoUKNAh9Wx4X4W
	sGQR+Kws4vCu1//hNfcy0AvDKlxwBzJ1MRw=
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.2 AUTH) with ESMTPSA id n072edqB47luADC
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 4 Dec 2014 08:47:56 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id C498A5016D; Thu,  4 Dec 2014 08:47:56 +0100 (CET)
Date: Thu, 4 Dec 2014 08:47:56 +0100
From: Olaf Hering <olaf@aepfle.de>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141204074756.GA4505@aepfle.de>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, M A Young wrote:

> On Wed, 3 Dec 2014, Konrad Rzeszutek Wilk wrote:
> >Options=mode=755,context="$XENSTORED_MOUNT_CTX"
> 
> Yes, that was on my probable bug list, as context="none" isn't a valid mount
> option (on Fedora at least), presumably because context has to be followed
> by a valid selinux context.

Is that something the sysadmin has to adjust, or should the xen source
provide proper values?

Olaf

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 07:48:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 07: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 1XwR93-0007FX-0H; Thu, 04 Dec 2014 07:48:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XwR91-0007FS-26
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 07:48:11 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	C7/66-19763-AB110845; Thu, 04 Dec 2014 07:48:10 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417679289!11467717!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19424 invoked from network); 4 Dec 2014 07:48:09 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Dec 2014 07:48:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417679289; l=438;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=NkzVkuX+ULqDRl/u8KULhrC72A8=;
	b=a1VqyCBCEw/QiJ76mXGPsqdZ2sbXr1/qHyeQYUasEXpqAzX8IZgbPX+rZbxA4WYX9hE
	VtTvN8EXW4I2Ru1dUycB+swgb18VPxvYDXtb6CxHO0wp5UkaV4fXPZcMoUKNAh9Wx4X4W
	sGQR+Kws4vCu1//hNfcy0AvDKlxwBzJ1MRw=
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.2 AUTH) with ESMTPSA id n072edqB47luADC
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 4 Dec 2014 08:47:56 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id C498A5016D; Thu,  4 Dec 2014 08:47:56 +0100 (CET)
Date: Thu, 4 Dec 2014 08:47:56 +0100
From: Olaf Hering <olaf@aepfle.de>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141204074756.GA4505@aepfle.de>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, M A Young wrote:

> On Wed, 3 Dec 2014, Konrad Rzeszutek Wilk wrote:
> >Options=mode=755,context="$XENSTORED_MOUNT_CTX"
> 
> Yes, that was on my probable bug list, as context="none" isn't a valid mount
> option (on Fedora at least), presumably because context has to be followed
> by a valid selinux context.

Is that something the sysadmin has to adjust, or should the xen source
provide proper values?

Olaf

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 08:17:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 08:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwRbN-0008HU-Ii; Thu, 04 Dec 2014 08:17:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1XwRbM-0008HP-VM
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 08:17:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C7/A7-09842-89810845; Thu, 04 Dec 2014 08:17:28 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417681047!13295814!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8953 invoked from network); 4 Dec 2014 08:17:27 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-15.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Dec 2014 08:17:27 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginm.net ([86.6.25.227]
	helo=dagon.hellion.org.uk) by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1XwRbE-0000FC-J0; Thu, 04 Dec 2014 08:17:20 +0000
Message-ID: <1417681039.2372.40.camel@hellion.org.uk>
From: Ian Campbell <ijc@hellion.org.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 04 Dec 2014 08:17:19 +0000
In-Reply-To: <20141203203616.GA8802@laptop.dumpdata.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
	<20141202183620.GE32385@laptop.dumpdata.com>
	<20141203155353.GN16236@olila.local.net-space.pl>
	<20141203203616.GA8802@laptop.dumpdata.com>
X-Mailer: Evolution 3.12.7-1 
Mime-Version: 1.0
Cc: keir@xen.org, pkg-xen-devel@lists.alioth.debian.org,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org, abe@debian.org
Subject: Re: [Xen-devel] [Pkg-xen-devel] [PATCH for-xen-4.5 1/3]
 tools/hotplug: distclean target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-12-03 at 15:36 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 03, 2014 at 04:53:53PM +0100, Daniel Kiper wrote:
> > On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> > > > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > >
> > > This usage scenario which I can see this being useful (and
> > > I've tripped over this) is when you rebuild a new version
> > > from the same repo. As in, this affects developers, but
> > > not end-users and not distros. But perhaps I am missing
> > > one scenario?
> > >
> > > As such I would lean towards deferring this (and the other
> > > two) to Xen 4.6.
> > 
> > As I know Debian build system sometimes complain if make distclean
> > does not leave build tree in distclean state (read "state before
> > configure" != "state after distclean"). It means that from
> > distros point of view we should apply this patch. However,
> > other two are not required and we can deffer them to Xen 4.6.
> 
> Cc-ing Axel and Debian Xen Team.

Debian is shipping 4.4 in the next release (8, Jessie, already frozen)
and I think it likely that the release after that will ship something
greater than 4.5 due to the timelines involved.

In any case, the Debian Xen packages cannot have any bugs of the kind
mentioned here because the package copyies the source to
debian/build/foo (for reasons other than distclean) and nuking the
entire of debian/build on clean.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 08:17:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 08:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwRbN-0008HU-Ii; Thu, 04 Dec 2014 08:17:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1XwRbM-0008HP-VM
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 08:17:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C7/A7-09842-89810845; Thu, 04 Dec 2014 08:17:28 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417681047!13295814!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8953 invoked from network); 4 Dec 2014 08:17:27 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-15.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Dec 2014 08:17:27 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginm.net ([86.6.25.227]
	helo=dagon.hellion.org.uk) by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1XwRbE-0000FC-J0; Thu, 04 Dec 2014 08:17:20 +0000
Message-ID: <1417681039.2372.40.camel@hellion.org.uk>
From: Ian Campbell <ijc@hellion.org.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 04 Dec 2014 08:17:19 +0000
In-Reply-To: <20141203203616.GA8802@laptop.dumpdata.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
	<20141202183620.GE32385@laptop.dumpdata.com>
	<20141203155353.GN16236@olila.local.net-space.pl>
	<20141203203616.GA8802@laptop.dumpdata.com>
X-Mailer: Evolution 3.12.7-1 
Mime-Version: 1.0
Cc: keir@xen.org, pkg-xen-devel@lists.alioth.debian.org,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org, abe@debian.org
Subject: Re: [Xen-devel] [Pkg-xen-devel] [PATCH for-xen-4.5 1/3]
 tools/hotplug: distclean target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-12-03 at 15:36 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 03, 2014 at 04:53:53PM +0100, Daniel Kiper wrote:
> > On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> > > > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > >
> > > This usage scenario which I can see this being useful (and
> > > I've tripped over this) is when you rebuild a new version
> > > from the same repo. As in, this affects developers, but
> > > not end-users and not distros. But perhaps I am missing
> > > one scenario?
> > >
> > > As such I would lean towards deferring this (and the other
> > > two) to Xen 4.6.
> > 
> > As I know Debian build system sometimes complain if make distclean
> > does not leave build tree in distclean state (read "state before
> > configure" != "state after distclean"). It means that from
> > distros point of view we should apply this patch. However,
> > other two are not required and we can deffer them to Xen 4.6.
> 
> Cc-ing Axel and Debian Xen Team.

Debian is shipping 4.4 in the next release (8, Jessie, already frozen)
and I think it likely that the release after that will ship something
greater than 4.5 due to the timelines involved.

In any case, the Debian Xen packages cannot have any bugs of the kind
mentioned here because the package copyies the source to
debian/build/foo (for reasons other than distclean) and nuking the
entire of debian/build on clean.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 08:27:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1XwRl6-00006x-M2; Thu, 04 Dec 2014 08:27: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 1XwRl5-00006s-Qu
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 08:27:31 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	47/CC-27623-2FA10845; Thu, 04 Dec 2014 08:27:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417681650!11011647!1
X-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 12561 invoked from network); 4 Dec 2014 08:27:30 -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; 4 Dec 2014 08:27:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 08:27:29 +0000
Message-Id: <54802900020000780004C93D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 08:27:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
	<547DE1BD02000078000C2DEF@mail.emea.novell.com>
	<20141203153717.GM16236@olila.local.net-space.pl>
In-Reply-To: <20141203153717.GM16236@olila.local.net-space.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] console: increase initial
	conring 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 03.12.14 at 16:37, <daniel.kiper@oracle.com> wrote:
> On Tue, Dec 02, 2014 at 03:58:53PM +0000, Jan Beulich wrote:
>> >>> Daniel Kiper <daniel.kiper@oracle.com> 12/02/14 3:58 PM >>>
>> >In general initial conring size is sufficient. However, if log
>> >level is increased on platforms which have e.g. huge number
>> >of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
>> >which has more than 200 entries in EFI memory map) then some
>> >of earlier messages in console ring are overwritten. It means
>> >that in case of issues deeper analysis can be hindered. Sadly
>> >conring_size argument does not help because new console buffer
>> >is allocated late on heap. It means that it is not possible to
>> >allocate larger ring earlier. So, in this situation initial
>> >conring size should be increased. My experiments showed that
>> >even on not so big machines more than 26 KiB of free space are
>> >needed for initial messages. In theory we could increase conring
>> >size buffer to 32 KiB. However, I think that this value could be
>> >too small for huge machines with large number of ACPI tables and
>> >EFI memory regions. Hence, this patch increases initial conring
>> >size to 64 KiB.
>> >
>> >Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>>
>> I think it was made clear before that just saying "for-xen-4.5" without any
>> further rationale is insufficient. Please explain what makes this so 
> important
>> a change that it needs to go in now.
> 
> What is not clear in commit message? It describes a bug, how to fix it
> and why in that way. Do you need anything else?

I didn't say the commit message is unclear. Instead I told you that
after a --- separate I would have expected justification for the
request to include this in 4.5. After all what you call a bug here
is imo merely a lack of functionality.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 08:27:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1XwRl6-00006x-M2; Thu, 04 Dec 2014 08:27: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 1XwRl5-00006s-Qu
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 08:27:31 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	47/CC-27623-2FA10845; Thu, 04 Dec 2014 08:27:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417681650!11011647!1
X-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 12561 invoked from network); 4 Dec 2014 08:27:30 -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; 4 Dec 2014 08:27:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 08:27:29 +0000
Message-Id: <54802900020000780004C93D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 08:27:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <1417532274-28976-1-git-send-email-daniel.kiper@oracle.com>
	<547DE1BD02000078000C2DEF@mail.emea.novell.com>
	<20141203153717.GM16236@olila.local.net-space.pl>
In-Reply-To: <20141203153717.GM16236@olila.local.net-space.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5] console: increase initial
	conring 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 03.12.14 at 16:37, <daniel.kiper@oracle.com> wrote:
> On Tue, Dec 02, 2014 at 03:58:53PM +0000, Jan Beulich wrote:
>> >>> Daniel Kiper <daniel.kiper@oracle.com> 12/02/14 3:58 PM >>>
>> >In general initial conring size is sufficient. However, if log
>> >level is increased on platforms which have e.g. huge number
>> >of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
>> >which has more than 200 entries in EFI memory map) then some
>> >of earlier messages in console ring are overwritten. It means
>> >that in case of issues deeper analysis can be hindered. Sadly
>> >conring_size argument does not help because new console buffer
>> >is allocated late on heap. It means that it is not possible to
>> >allocate larger ring earlier. So, in this situation initial
>> >conring size should be increased. My experiments showed that
>> >even on not so big machines more than 26 KiB of free space are
>> >needed for initial messages. In theory we could increase conring
>> >size buffer to 32 KiB. However, I think that this value could be
>> >too small for huge machines with large number of ACPI tables and
>> >EFI memory regions. Hence, this patch increases initial conring
>> >size to 64 KiB.
>> >
>> >Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>>
>> I think it was made clear before that just saying "for-xen-4.5" without any
>> further rationale is insufficient. Please explain what makes this so 
> important
>> a change that it needs to go in now.
> 
> What is not clear in commit message? It describes a bug, how to fix it
> and why in that way. Do you need anything else?

I didn't say the commit message is unclear. Instead I told you that
after a --- separate I would have expected justification for the
request to include this in 4.5. After all what you call a bug here
is imo merely a lack of functionality.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 08:31:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 08: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 1XwRpK-0000Pc-Go; Thu, 04 Dec 2014 08:31:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwRpI-0000Oa-Pm
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 08:31:52 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A4/5F-09842-8FB10845; Thu, 04 Dec 2014 08:31:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417681910!12975643!1
X-Originating-IP: [66.165.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 8843 invoked from network); 4 Dec 2014 08:31:51 -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 Dec 2014 08:31:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199889807"
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, 4 Dec 2014 03:31: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 1XwRpE-0006gA-QO;
	Thu, 04 Dec 2014 08:31:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwRpC-0005Hb-Cm;
	Thu, 04 Dec 2014 08:31:46 +0000
Date: Thu, 4 Dec 2014 08:31:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32044-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] 32044: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-saverestore   fail pass in 31985
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10 fail in 31985 pass in 32044

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
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     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-xend-winxpsp3 17 leak-check/check             fail  never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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-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
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 31985 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 Thu Dec 04 08:31:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 08: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 1XwRpK-0000Pc-Go; Thu, 04 Dec 2014 08:31:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwRpI-0000Oa-Pm
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 08:31:52 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A4/5F-09842-8FB10845; Thu, 04 Dec 2014 08:31:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417681910!12975643!1
X-Originating-IP: [66.165.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 8843 invoked from network); 4 Dec 2014 08:31:51 -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 Dec 2014 08:31:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199889807"
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, 4 Dec 2014 03:31: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 1XwRpE-0006gA-QO;
	Thu, 04 Dec 2014 08:31:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwRpC-0005Hb-Cm;
	Thu, 04 Dec 2014 08:31:46 +0000
Date: Thu, 4 Dec 2014 08:31:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32044-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] 32044: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-saverestore   fail pass in 31985
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10 fail in 31985 pass in 32044

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
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     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-xend-winxpsp3 17 leak-check/check             fail  never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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-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
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 31985 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 Thu Dec 04 08:52:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 08: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 1XwS8i-0000kZ-In; Thu, 04 Dec 2014 08:51: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 1XwS8h-0000kU-5O
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 08:51:55 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	63/B1-09842-AA020845; Thu, 04 Dec 2014 08:51:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417683113!13307819!1
X-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 14368 invoked from network); 4 Dec 2014 08:51:53 -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; 4 Dec 2014 08:51:53 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 08:51:52 +0000
Message-Id: <54802EB9020000780004C994@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 08:51:53 +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>
	<5476F580020000780004B0E2@mail.emea.novell.com>
	<547F6EF3.5080304@oracle.com>
In-Reply-To: <547F6EF3.5080304@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 03.12.14 at 21:13, <boris.ostrovsky@oracle.com> wrote:
> On 11/27/2014 03:57 AM, Jan Beulich wrote:
>>>>> 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.
> 
> I started to make this change and then I realized that the next patch 
> (12/21) is actually already taking care of this problem: most of the 
> *_vpmu_initialise() will be executed as initcalls during host boot and 
> if any of those fail then we do want to disable VPMU globally (those 
> failures would not be VCPU-specific).

Funny that you say that - it was actually while reviewing that next
patch when I made that observation: svm_vpmu_initialise() get a
-ENOMEM return _added_ there for example, which is contrary to
what I asked for above.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 08:52:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 08: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 1XwS8i-0000kZ-In; Thu, 04 Dec 2014 08:51: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 1XwS8h-0000kU-5O
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 08:51:55 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	63/B1-09842-AA020845; Thu, 04 Dec 2014 08:51:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417683113!13307819!1
X-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 14368 invoked from network); 4 Dec 2014 08:51:53 -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; 4 Dec 2014 08:51:53 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 08:51:52 +0000
Message-Id: <54802EB9020000780004C994@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 08:51:53 +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>
	<5476F580020000780004B0E2@mail.emea.novell.com>
	<547F6EF3.5080304@oracle.com>
In-Reply-To: <547F6EF3.5080304@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 03.12.14 at 21:13, <boris.ostrovsky@oracle.com> wrote:
> On 11/27/2014 03:57 AM, Jan Beulich wrote:
>>>>> 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.
> 
> I started to make this change and then I realized that the next patch 
> (12/21) is actually already taking care of this problem: most of the 
> *_vpmu_initialise() will be executed as initcalls during host boot and 
> if any of those fail then we do want to disable VPMU globally (those 
> failures would not be VCPU-specific).

Funny that you say that - it was actually while reviewing that next
patch when I made that observation: svm_vpmu_initialise() get a
-ENOMEM return _added_ there for example, which is contrary to
what I asked for above.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 09:03:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 09:03:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwSJA-0001CS-1H; Thu, 04 Dec 2014 09:02:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XwSJ8-0001CN-HN
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 09:02:42 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	3F/CB-03148-13320845; Thu, 04 Dec 2014 09:02:41 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417683757!12927690!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25690 invoked from network); 4 Dec 2014 09:02:40 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-15.tower-27.messagelabs.com with SMTP;
	4 Dec 2014 09:02:40 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 04 Dec 2014 01:00:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="493447485"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga003.jf.intel.com with ESMTP; 04 Dec 2014 00:59:10 -0800
Message-ID: <548022DE.3090906@linux.intel.com>
Date: Thu, 04 Dec 2014 17:01:18 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>	<54785525020000780004B588@mail.emea.novell.com>	<547C2BAF.6010004@linux.intel.com>	<547C43BA020000780004B9BE@mail.emea.novell.com>	<20141201103012.GA69236@deinos.phlegethon.org>	<547C5C43020000780004BAFD@mail.emea.novell.com>	<20141201121300.GB69236@deinos.phlegethon.org>	<547D6C86.4090400@linux.intel.com>
	<20141202114016.GD69236@deinos.phlegethon.org>
In-Reply-To: <20141202114016.GD69236@deinos.phlegethon.org>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com,
	Jan Beulich <JBeulich@suse.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/2/2014 7:40 PM, Tim Deegan wrote:
> At 15:38 +0800 on 02 Dec (1417531126), Yu, Zhang wrote:
>> On 12/1/2014 8:13 PM, Tim Deegan wrote:
>>> At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>>>>>>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>>>>> During this bit of archaeology I realised that either this new type
>>>>> should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
>>>>> class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
>>>>> for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
>>>>> just p2m_ram_ro and p2m_grant_map_ro.
>>>>
>>>> And I suppose in that latter case the new type could be made part
>>>> of P2M_RO_TYPES()?
>>>
>>> Yes indeed, as P2M_RO_TYPES is defined as "must have the _PAGE_RW bit
>>> clear in their PTEs".
>>>
>>
>> Thanks Tim.
>> Following are my understanding of the P2M_RO_TYPES and your comments.
>> Not sure if I get it right. Please correct me if anything wrong:
>> 1> The P2M_RO_TYPES now bears 2 meanings: one is "w bit is clear in the
>> pte"; and another being to discard the write operations;
>> 2> We better define another class to bear the second meaning.
>
> Yes, that's what I meant.
>
> Answering your other questions in reverse order:
>
>> 2> p2m_grant_map_ro is also supposed to be discarded? Will handling of
>> this type of pages goes into __hvm_copy()/__hvm_clear(), or should?
>
> I think so, yes.  At the moment we inject #GP when the guest writes to
> a read-only grant, which is OK: the guest really ought to know better.
> But I think we'll probably end up with neater code if we handle
> read-only grants the same way as p2m_ram_ro.
>
> Anyone else have an opinion on the right thing to do here?
>
>> Also some questions for the new p2m class, say P2M_DISCARD_WRITE_TYPES,
>> and the new predicates, say p2m_is_discard_write:
>> 1> You mentioned emulate_gva_to_mfn() and __hvm_copy() should discard
>> the write ops, yet I also noticed many other places using the
>> p2m_is_readonly, or only the "p2mt == p2m_ram_ro" judgement(in
>> __hvm_copy/__hvm_clear). Among all these other places, is there any ones
>> also supposed to use the p2m_is_discard_write?
>
> I've just had a look through them all, and I can see exactly four
> places that should be using the new p2m_is_discard_write() test:
>
>   - emulate_gva_to_mfn() (Though in fact it's a no-op as shadow-mode
>     guests never have p2m_ram_shared or p2m_ram_logdirty mappings.)
>   - __hvm_copy()
>   - __hvm_clear() and
>   - hvm_hap_nested_page_fault() (where you should also remove the
>     explicit handling of p2m_grant_map_ro below.)
>
> Looking through that turned up a few other oddities, which I'm
> listing here to remind myself to look at them later (i.e. you don't
> need to worry about them for this patch):
>
>   - nsvm_get_nvmcb_page() and nestedhap_walk_L0_p2m() need to handle
>     p2m_ram_logdirty or they might spuriously fail duiring live
>     migration.
>   - __hvm_copy() and __hvm_clear are probably over-strict in their
>     failure to handle grant types.

Hi Tim. Sorry to bother you. :)
I just noticed that in __hvm_copy()/__hvm_clear(), the grant types are 
handled before the p2m_ram_ro - will return HVMCOPY_unhandleable. So if
p2m_is_discard_write() is supposed to replace the handling of 
p2m_ram_ro, handling of p2m_grant_map_ro will still return 
HVMCOPY_unhandleable, before the p2m_is_discard_write() predicate.
Even we move the testing of p2m_is_discard_write() before the handling 
of grant types, it seems not quite clean.
By "over-strict in their failure to handle grant types.", do you also 
mean this?

Thanks
Yu

>   - P2M_UNMAP_TYPES in vmce.c is a mess.  It's not the right place to
>     define this, since it definitely won't be seen my anyone
>     adding a new type, and it already has an 'XXX' comment that says
>     it doesn't cover a lot of cases. :(
>
> I'll have a look at those another time.
>
> Cheers,
>
> Tim.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 09:03:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 09:03:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwSJA-0001CS-1H; Thu, 04 Dec 2014 09:02:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XwSJ8-0001CN-HN
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 09:02:42 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	3F/CB-03148-13320845; Thu, 04 Dec 2014 09:02:41 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417683757!12927690!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25690 invoked from network); 4 Dec 2014 09:02:40 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-15.tower-27.messagelabs.com with SMTP;
	4 Dec 2014 09:02:40 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 04 Dec 2014 01:00:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="493447485"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga003.jf.intel.com with ESMTP; 04 Dec 2014 00:59:10 -0800
Message-ID: <548022DE.3090906@linux.intel.com>
Date: Thu, 04 Dec 2014 17:01:18 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>	<54785525020000780004B588@mail.emea.novell.com>	<547C2BAF.6010004@linux.intel.com>	<547C43BA020000780004B9BE@mail.emea.novell.com>	<20141201103012.GA69236@deinos.phlegethon.org>	<547C5C43020000780004BAFD@mail.emea.novell.com>	<20141201121300.GB69236@deinos.phlegethon.org>	<547D6C86.4090400@linux.intel.com>
	<20141202114016.GD69236@deinos.phlegethon.org>
In-Reply-To: <20141202114016.GD69236@deinos.phlegethon.org>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com,
	Jan Beulich <JBeulich@suse.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/2/2014 7:40 PM, Tim Deegan wrote:
> At 15:38 +0800 on 02 Dec (1417531126), Yu, Zhang wrote:
>> On 12/1/2014 8:13 PM, Tim Deegan wrote:
>>> At 11:17 +0000 on 01 Dec (1417429027), Jan Beulich wrote:
>>>>>>> On 01.12.14 at 11:30, <tim@xen.org> wrote:
>>>>> During this bit of archaeology I realised that either this new type
>>>>> should _not_ be made part of P2M_RO_TYPES, or, better, we need a new
>>>>> class of P2M types (P2M_DISCARD_WRITE_TYPES, say) that should be used
>>>>> for these paths in emulate_gva_to_mfn() and __hvm_copy(), containing
>>>>> just p2m_ram_ro and p2m_grant_map_ro.
>>>>
>>>> And I suppose in that latter case the new type could be made part
>>>> of P2M_RO_TYPES()?
>>>
>>> Yes indeed, as P2M_RO_TYPES is defined as "must have the _PAGE_RW bit
>>> clear in their PTEs".
>>>
>>
>> Thanks Tim.
>> Following are my understanding of the P2M_RO_TYPES and your comments.
>> Not sure if I get it right. Please correct me if anything wrong:
>> 1> The P2M_RO_TYPES now bears 2 meanings: one is "w bit is clear in the
>> pte"; and another being to discard the write operations;
>> 2> We better define another class to bear the second meaning.
>
> Yes, that's what I meant.
>
> Answering your other questions in reverse order:
>
>> 2> p2m_grant_map_ro is also supposed to be discarded? Will handling of
>> this type of pages goes into __hvm_copy()/__hvm_clear(), or should?
>
> I think so, yes.  At the moment we inject #GP when the guest writes to
> a read-only grant, which is OK: the guest really ought to know better.
> But I think we'll probably end up with neater code if we handle
> read-only grants the same way as p2m_ram_ro.
>
> Anyone else have an opinion on the right thing to do here?
>
>> Also some questions for the new p2m class, say P2M_DISCARD_WRITE_TYPES,
>> and the new predicates, say p2m_is_discard_write:
>> 1> You mentioned emulate_gva_to_mfn() and __hvm_copy() should discard
>> the write ops, yet I also noticed many other places using the
>> p2m_is_readonly, or only the "p2mt == p2m_ram_ro" judgement(in
>> __hvm_copy/__hvm_clear). Among all these other places, is there any ones
>> also supposed to use the p2m_is_discard_write?
>
> I've just had a look through them all, and I can see exactly four
> places that should be using the new p2m_is_discard_write() test:
>
>   - emulate_gva_to_mfn() (Though in fact it's a no-op as shadow-mode
>     guests never have p2m_ram_shared or p2m_ram_logdirty mappings.)
>   - __hvm_copy()
>   - __hvm_clear() and
>   - hvm_hap_nested_page_fault() (where you should also remove the
>     explicit handling of p2m_grant_map_ro below.)
>
> Looking through that turned up a few other oddities, which I'm
> listing here to remind myself to look at them later (i.e. you don't
> need to worry about them for this patch):
>
>   - nsvm_get_nvmcb_page() and nestedhap_walk_L0_p2m() need to handle
>     p2m_ram_logdirty or they might spuriously fail duiring live
>     migration.
>   - __hvm_copy() and __hvm_clear are probably over-strict in their
>     failure to handle grant types.

Hi Tim. Sorry to bother you. :)
I just noticed that in __hvm_copy()/__hvm_clear(), the grant types are 
handled before the p2m_ram_ro - will return HVMCOPY_unhandleable. So if
p2m_is_discard_write() is supposed to replace the handling of 
p2m_ram_ro, handling of p2m_grant_map_ro will still return 
HVMCOPY_unhandleable, before the p2m_is_discard_write() predicate.
Even we move the testing of p2m_is_discard_write() before the handling 
of grant types, it seems not quite clean.
By "over-strict in their failure to handle grant types.", do you also 
mean this?

Thanks
Yu

>   - P2M_UNMAP_TYPES in vmce.c is a mess.  It's not the right place to
>     define this, since it definitely won't be seen my anyone
>     adding a new type, and it already has an 'XXX' comment that says
>     it doesn't cover a lot of cases. :(
>
> I'll have a look at those another time.
>
> Cheers,
>
> Tim.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 09:29:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 09:29:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwSia-0001kw-DX; Thu, 04 Dec 2014 09:29: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 1XwSiZ-0001kr-Hh
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 09:28:59 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	69/B4-27623-A5920845; Thu, 04 Dec 2014 09:28:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417685336!11037135!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5487 invoked from network); 4 Dec 2014 09:28: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;
	4 Dec 2014 09:28:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199927062"
Message-ID: <1417685334.22808.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Thu, 4 Dec 2014 09:28:54 +0000
In-Reply-To: <20141204013102.GA31385@andromeda.dapyr.net>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
	<20141204013102.GA31385@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first 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 Wed, 2014-12-03 at 21:31 -0400, Konrad Rzeszutek Wilk wrote:
> so something is busted as you surmised

I haven't been following closely, so this may be completely unrelated to
the issue under discussion, but doesn't in-HVM-guest hotplug require a
guest side driver to be loaded? I recall in the dim and distant past
having to manually load some sort of foo_hp.ko.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 09:29:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 09:29:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwSia-0001kw-DX; Thu, 04 Dec 2014 09:29: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 1XwSiZ-0001kr-Hh
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 09:28:59 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	69/B4-27623-A5920845; Thu, 04 Dec 2014 09:28:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417685336!11037135!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5487 invoked from network); 4 Dec 2014 09:28: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;
	4 Dec 2014 09:28:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199927062"
Message-ID: <1417685334.22808.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Thu, 4 Dec 2014 09:28:54 +0000
In-Reply-To: <20141204013102.GA31385@andromeda.dapyr.net>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
	<20141204013102.GA31385@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first 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 Wed, 2014-12-03 at 21:31 -0400, Konrad Rzeszutek Wilk wrote:
> so something is busted as you surmised

I haven't been following closely, so this may be completely unrelated to
the issue under discussion, but doesn't in-HVM-guest hotplug require a
guest side driver to be loaded? I recall in the dim and distant past
having to manually load some sort of foo_hp.ko.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 09:35:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 09: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 1XwSoS-00022B-AM; Thu, 04 Dec 2014 09:35: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 1XwSoR-000226-A0
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 09:35:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	20/57-09842-6CA20845; Thu, 04 Dec 2014 09:35:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417685701!13281248!1
X-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 20478 invoked from network); 4 Dec 2014 09:35:01 -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; 4 Dec 2014 09:35:01 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 09:35:00 +0000
Message-Id: <548038D5020000780004C9E8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 09:35:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
In-Reply-To: <20141203210225.GR16236@olila.local.net-space.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
> Hey,
> 
> 1) Why is there in EFI code so many functions (e.g. efi_start(),
>    efi_arch_edd(), ...) with local variables declared as a static?
>    Though some of them have also regular local variables. I do not
>    why it was decided that some of them must be the static and
>    some of do not. It is a bit confusing. As I can see there is
>    only one place which have to have local static (place_string()).
>    Other seems to me as thing to save space on the stack but I do
>    not think we need that. According to UEFI spec there will be
>    "128 KiB or more of available stack space" when system runs in
>    boot services mode. It is a lot of space. So, I think we can
>    safely convert most of local static variables to normal local
>    variables. Am I right?

No. Consider what code results when you e.g. make an EFI_GUID
instance non-static.

> 2) I am going to add EDID support to EFI code. Should it be x86
>    specific code or common one? As I can see EDID is defined as
>    part of GOP so I think that EDID code should be placed in
>    xen/common/efi/boot.c.

Yes.

> 3) Should not we change xen/arch/*/efi/efi-boot.h to
>    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
>    code than definitions, declarations and short static
>    functions. So, I think that it is more regular *.c file
>    than header file.

That's a matter of taste - I'd probably have made it .c too, but
didn't mind it being .h as done by Roy (presumably on the basis
that #include directives are preferred to have .h files as their
operands). The only thing I regret is that I didn't ask for the
pointless efi- prefix to 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 Thu Dec 04 09:35:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 09: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 1XwSoS-00022B-AM; Thu, 04 Dec 2014 09:35: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 1XwSoR-000226-A0
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 09:35:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	20/57-09842-6CA20845; Thu, 04 Dec 2014 09:35:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417685701!13281248!1
X-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 20478 invoked from network); 4 Dec 2014 09:35:01 -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; 4 Dec 2014 09:35:01 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 09:35:00 +0000
Message-Id: <548038D5020000780004C9E8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 09:35:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
In-Reply-To: <20141203210225.GR16236@olila.local.net-space.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
> Hey,
> 
> 1) Why is there in EFI code so many functions (e.g. efi_start(),
>    efi_arch_edd(), ...) with local variables declared as a static?
>    Though some of them have also regular local variables. I do not
>    why it was decided that some of them must be the static and
>    some of do not. It is a bit confusing. As I can see there is
>    only one place which have to have local static (place_string()).
>    Other seems to me as thing to save space on the stack but I do
>    not think we need that. According to UEFI spec there will be
>    "128 KiB or more of available stack space" when system runs in
>    boot services mode. It is a lot of space. So, I think we can
>    safely convert most of local static variables to normal local
>    variables. Am I right?

No. Consider what code results when you e.g. make an EFI_GUID
instance non-static.

> 2) I am going to add EDID support to EFI code. Should it be x86
>    specific code or common one? As I can see EDID is defined as
>    part of GOP so I think that EDID code should be placed in
>    xen/common/efi/boot.c.

Yes.

> 3) Should not we change xen/arch/*/efi/efi-boot.h to
>    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
>    code than definitions, declarations and short static
>    functions. So, I think that it is more regular *.c file
>    than header file.

That's a matter of taste - I'd probably have made it .c too, but
didn't mind it being .h as done by Roy (presumably on the basis
that #include directives are preferred to have .h files as their
operands). The only thing I regret is that I didn't ask for the
pointless efi- prefix to 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 Thu Dec 04 09:36:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 09:36:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwSpk-00028B-V8; Thu, 04 Dec 2014 09:36:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XwSpj-000280-48
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 09:36:23 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	7A/57-22737-61B20845; Thu, 04 Dec 2014 09:36:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417685781!11474811!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 4130 invoked from network); 4 Dec 2014 09:36:22 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Dec 2014 09:36:22 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwSpM-0009Ow-TK; Thu, 04 Dec 2014 09:36:01 +0000
Date: Thu, 4 Dec 2014 10:36:00 +0100
From: Tim Deegan <tim@xen.org>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Message-ID: <20141204093600.GA35555@deinos.phlegethon.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547D6C86.4090400@linux.intel.com>
	<20141202114016.GD69236@deinos.phlegethon.org>
	<548022DE.3090906@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548022DE.3090906@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com,
	Jan Beulich <JBeulich@suse.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

Hi, 

At 17:01 +0800 on 04 Dec (1417708878), Yu, Zhang wrote:
> I just noticed that in __hvm_copy()/__hvm_clear(), the grant types are 
> handled before the p2m_ram_ro - will return HVMCOPY_unhandleable. So if
> p2m_is_discard_write() is supposed to replace the handling of 
> p2m_ram_ro, handling of p2m_grant_map_ro will still return 
> HVMCOPY_unhandleable, before the p2m_is_discard_write() predicate.
> Even we move the testing of p2m_is_discard_write() before the handling 
> of grant types, it seems not quite clean.
> By "over-strict in their failure to handle grant types.", do you also 
> mean this?

Yes, that's the sort of thing I meant.  I'll try to write a patch for
that later today or next week -- in the meantime I think you should
ignore it. :)

An unrelated thought: when you send your next version can you send it
as a two-patch series, where the first patch does the
p2m_is_discard_write() changes and the second adds your new type?

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 Dec 04 09:36:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 09:36:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwSpk-00028B-V8; Thu, 04 Dec 2014 09:36:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XwSpj-000280-48
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 09:36:23 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	7A/57-22737-61B20845; Thu, 04 Dec 2014 09:36:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417685781!11474811!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 4130 invoked from network); 4 Dec 2014 09:36:22 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Dec 2014 09:36:22 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwSpM-0009Ow-TK; Thu, 04 Dec 2014 09:36:01 +0000
Date: Thu, 4 Dec 2014 10:36:00 +0100
From: Tim Deegan <tim@xen.org>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Message-ID: <20141204093600.GA35555@deinos.phlegethon.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54785525020000780004B588@mail.emea.novell.com>
	<547C2BAF.6010004@linux.intel.com>
	<547C43BA020000780004B9BE@mail.emea.novell.com>
	<20141201103012.GA69236@deinos.phlegethon.org>
	<547C5C43020000780004BAFD@mail.emea.novell.com>
	<20141201121300.GB69236@deinos.phlegethon.org>
	<547D6C86.4090400@linux.intel.com>
	<20141202114016.GD69236@deinos.phlegethon.org>
	<548022DE.3090906@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548022DE.3090906@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com,
	Jan Beulich <JBeulich@suse.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

Hi, 

At 17:01 +0800 on 04 Dec (1417708878), Yu, Zhang wrote:
> I just noticed that in __hvm_copy()/__hvm_clear(), the grant types are 
> handled before the p2m_ram_ro - will return HVMCOPY_unhandleable. So if
> p2m_is_discard_write() is supposed to replace the handling of 
> p2m_ram_ro, handling of p2m_grant_map_ro will still return 
> HVMCOPY_unhandleable, before the p2m_is_discard_write() predicate.
> Even we move the testing of p2m_is_discard_write() before the handling 
> of grant types, it seems not quite clean.
> By "over-strict in their failure to handle grant types.", do you also 
> mean this?

Yes, that's the sort of thing I meant.  I'll try to write a patch for
that later today or next week -- in the meantime I think you should
ignore it. :)

An unrelated thought: when you send your next version can you send it
as a two-patch series, where the first patch does the
p2m_is_discard_write() changes and the second adds your new type?

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 Dec 04 09:40:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 09: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 1XwStQ-0002Kt-BY; Thu, 04 Dec 2014 09:40:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrew.reimers@orionvm.com>) id 1XwStO-0002Ke-Ep
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 09:40:10 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	57/39-24859-9FB20845; Thu, 04 Dec 2014 09:40:09 +0000
X-Env-Sender: andrew.reimers@orionvm.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417686005!10939243!1
X-Originating-IP: [103.29.67.250]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11249 invoked from network); 4 Dec 2014 09:40:09 -0000
Received: from mail.orionvm.com (HELO mail.orionvm.com) (103.29.67.250)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 09:40:09 -0000
From: Andrew Reimers <andrew.reimers@orionvm.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Possible bug in xenbus __xenbus_switch_state
Thread-Index: AdAPpkaT2DfcOA3fSKWnN6ZNaeY4Qg==
Date: Thu, 4 Dec 2014 09:40:01 +0000
Message-ID: <4841C18C109F9B4E86BBDE59113F98D7A8F52D@Exchange1.orionvm.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
Subject: [Xen-devel] Possible bug in xenbus __xenbus_switch_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,

Looking at the function __xenbus_switch_state in file source/drivers/xen/xenbus/xenbus_client.c,

The comment says:

"We check whether the state is currently set to the given value, and
	   if not, then the state is set."

The code loads the old state value, but never does anything with it.

I would expect it to look something like:

err = xenbus_scanf(xbt, dev->nodename, "state", "%d", &current_state);
if (err != 1 || current_state != state) {
	err = xenbus_printf(xbt, dev->nodename, "state", "%d", state);
		if (err) {
		xenbus_switch_fatal(dev, depth, err, "writing new state");
		goto abort;
	}
}

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 09:40:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 09: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 1XwStQ-0002Kt-BY; Thu, 04 Dec 2014 09:40:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andrew.reimers@orionvm.com>) id 1XwStO-0002Ke-Ep
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 09:40:10 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	57/39-24859-9FB20845; Thu, 04 Dec 2014 09:40:09 +0000
X-Env-Sender: andrew.reimers@orionvm.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417686005!10939243!1
X-Originating-IP: [103.29.67.250]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11249 invoked from network); 4 Dec 2014 09:40:09 -0000
Received: from mail.orionvm.com (HELO mail.orionvm.com) (103.29.67.250)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 09:40:09 -0000
From: Andrew Reimers <andrew.reimers@orionvm.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Possible bug in xenbus __xenbus_switch_state
Thread-Index: AdAPpkaT2DfcOA3fSKWnN6ZNaeY4Qg==
Date: Thu, 4 Dec 2014 09:40:01 +0000
Message-ID: <4841C18C109F9B4E86BBDE59113F98D7A8F52D@Exchange1.orionvm.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
Subject: [Xen-devel] Possible bug in xenbus __xenbus_switch_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,

Looking at the function __xenbus_switch_state in file source/drivers/xen/xenbus/xenbus_client.c,

The comment says:

"We check whether the state is currently set to the given value, and
	   if not, then the state is set."

The code loads the old state value, but never does anything with it.

I would expect it to look something like:

err = xenbus_scanf(xbt, dev->nodename, "state", "%d", &current_state);
if (err != 1 || current_state != state) {
	err = xenbus_printf(xbt, dev->nodename, "state", "%d", state);
		if (err) {
		xenbus_switch_fatal(dev, depth, err, "writing new state");
		goto abort;
	}
}

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 09:44:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 09: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 1XwSx5-0002hm-Vz; Thu, 04 Dec 2014 09:43:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XwSx4-0002he-E3
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 09:43:58 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	88/37-05632-DDC20845; Thu, 04 Dec 2014 09:43:57 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417686236!10923905!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14561 invoked from network); 4 Dec 2014 09:43:57 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-31.messagelabs.com with SMTP;
	4 Dec 2014 09:43:57 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 04 Dec 2014 01:43:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="424960671"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by FMSMGA003.fm.intel.com with ESMTP; 04 Dec 2014 01:33:35 -0800
Message-ID: <54802C90.1030401@linux.intel.com>
Date: Thu, 04 Dec 2014 17:42:40 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>	<54785525020000780004B588@mail.emea.novell.com>	<547C2BAF.6010004@linux.intel.com>	<547C43BA020000780004B9BE@mail.emea.novell.com>	<20141201103012.GA69236@deinos.phlegethon.org>	<547C5C43020000780004BAFD@mail.emea.novell.com>	<20141201121300.GB69236@deinos.phlegethon.org>	<547D6C86.4090400@linux.intel.com>	<20141202114016.GD69236@deinos.phlegethon.org>	<548022DE.3090906@linux.intel.com>
	<20141204093600.GA35555@deinos.phlegethon.org>
In-Reply-To: <20141204093600.GA35555@deinos.phlegethon.org>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com,
	Jan Beulich <JBeulich@suse.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/4/2014 5:36 PM, Tim Deegan wrote:
> Hi,
>
> At 17:01 +0800 on 04 Dec (1417708878), Yu, Zhang wrote:
>> I just noticed that in __hvm_copy()/__hvm_clear(), the grant types are
>> handled before the p2m_ram_ro - will return HVMCOPY_unhandleable. So if
>> p2m_is_discard_write() is supposed to replace the handling of
>> p2m_ram_ro, handling of p2m_grant_map_ro will still return
>> HVMCOPY_unhandleable, before the p2m_is_discard_write() predicate.
>> Even we move the testing of p2m_is_discard_write() before the handling
>> of grant types, it seems not quite clean.
>> By "over-strict in their failure to handle grant types.", do you also
>> mean this?
>
> Yes, that's the sort of thing I meant.  I'll try to write a patch for
> that later today or next week -- in the meantime I think you should
> ignore it. :)
>
> An unrelated thought: when you send your next version can you send it
> as a two-patch series, where the first patch does the
> p2m_is_discard_write() changes and the second adds your new type?

Sure, and thank you, Tim. :)
>
> Cheers,
>
> Tim.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 09:44:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 09: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 1XwSx5-0002hm-Vz; Thu, 04 Dec 2014 09:43:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XwSx4-0002he-E3
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 09:43:58 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	88/37-05632-DDC20845; Thu, 04 Dec 2014 09:43:57 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417686236!10923905!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14561 invoked from network); 4 Dec 2014 09:43:57 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-31.messagelabs.com with SMTP;
	4 Dec 2014 09:43:57 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 04 Dec 2014 01:43:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="424960671"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by FMSMGA003.fm.intel.com with ESMTP; 04 Dec 2014 01:33:35 -0800
Message-ID: <54802C90.1030401@linux.intel.com>
Date: Thu, 04 Dec 2014 17:42:40 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1417161552-5155-1-git-send-email-yu.c.zhang@linux.intel.com>	<54785525020000780004B588@mail.emea.novell.com>	<547C2BAF.6010004@linux.intel.com>	<547C43BA020000780004B9BE@mail.emea.novell.com>	<20141201103012.GA69236@deinos.phlegethon.org>	<547C5C43020000780004BAFD@mail.emea.novell.com>	<20141201121300.GB69236@deinos.phlegethon.org>	<547D6C86.4090400@linux.intel.com>	<20141202114016.GD69236@deinos.phlegethon.org>	<548022DE.3090906@linux.intel.com>
	<20141204093600.GA35555@deinos.phlegethon.org>
In-Reply-To: <20141204093600.GA35555@deinos.phlegethon.org>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com,
	Jan Beulich <JBeulich@suse.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/4/2014 5:36 PM, Tim Deegan wrote:
> Hi,
>
> At 17:01 +0800 on 04 Dec (1417708878), Yu, Zhang wrote:
>> I just noticed that in __hvm_copy()/__hvm_clear(), the grant types are
>> handled before the p2m_ram_ro - will return HVMCOPY_unhandleable. So if
>> p2m_is_discard_write() is supposed to replace the handling of
>> p2m_ram_ro, handling of p2m_grant_map_ro will still return
>> HVMCOPY_unhandleable, before the p2m_is_discard_write() predicate.
>> Even we move the testing of p2m_is_discard_write() before the handling
>> of grant types, it seems not quite clean.
>> By "over-strict in their failure to handle grant types.", do you also
>> mean this?
>
> Yes, that's the sort of thing I meant.  I'll try to write a patch for
> that later today or next week -- in the meantime I think you should
> ignore it. :)
>
> An unrelated thought: when you send your next version can you send it
> as a two-patch series, where the first patch does the
> p2m_is_discard_write() changes and the second adds your new type?

Sure, and thank you, Tim. :)
>
> Cheers,
>
> Tim.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:13:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10:13:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwTOb-0003Om-Ds; Thu, 04 Dec 2014 10:12: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 1XwTOa-0003Oh-1L
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 10:12:24 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	30/25-17694-78330845; Thu, 04 Dec 2014 10:12:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417687940!10996675!1
X-Originating-IP: [66.165.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 2129 invoked from network); 4 Dec 2014 10:12: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;
	4 Dec 2014 10:12:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199957587"
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, 4 Dec 2014 05:12: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 1XwTOU-00079u-MM;
	Thu, 04 Dec 2014 10:12:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwTOU-00063s-FB;
	Thu, 04 Dec 2014 10:12:18 +0000
Date: Thu, 4 Dec 2014 10:12:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32051-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] 32051: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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. 31986

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair  18 guest-migrate/dst_host/src_host fail blocked in 31986

Tests which did not succeed, but are not blocking:
 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-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  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-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 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  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-win7-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-pair         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-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-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
 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  1 build-check(1)               blocked  n/a
 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  1 build-check(1)               blocked n/a

version targeted for testing:
 xen                  4d1a77ba7ab94183c203226d3fe7ac1cd087c59b
baseline version:
 xen                  188336bb86d0992a2a034ece5f39eccc5d10f337

------------------------------------------------------------
People who touched revisions under test:
  Chunyan Liu <cyliu@suse.com>
  Euan Harris <euan.harris@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  M A Young <m.a.young@durham.ac.uk>
  Michael Young <m.a.young@durham.ac.uk>
  Razvan Cojocaru <rcojocaru@bitdefender.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                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          blocked 
 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                    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-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-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 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-armhf-armhf-libvirt                                     fail    
 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.

------------------------------------------------------------
commit 4d1a77ba7ab94183c203226d3fe7ac1cd087c59b
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Dec 1 11:31:13 2014 +0000

    xl: fix two memory leaks
    
    Free strings returned by libxl_basename after used.
    
    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>
    [ ijc -- s/basename/kernel_basename in parse_config_data to avoid
             shadowing basename(3). ]

commit 276ba7806259c10b186c9cd9115078fb35b28bc7
Author: Euan Harris <euan.harris@citrix.com>
Date:   Mon Dec 1 14:27:06 2014 +0000

    libxl: Don't dereference null new_name pointer in libxl_domain_rename()
    
    libxl__domain_rename() unconditionally dereferences its new_name
    parameter, to check whether it is an empty string.   Add a check to
    avoid a segfault if new_name is null.
    
    Signed-off-by: Euan Harris <euan.harris@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit e3abab74598d96de87e3cbcaf1d567ac854e53cf
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Dec 1 11:31:12 2014 +0000

    libxl: un-constify return value of libxl_basename
    
    The string returned is malloc'ed but marked as "const".
    
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Cc: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit e609bb983ea6e0a5a4d791cffccad0ce3712e12f
Author: Chunyan Liu <cyliu@suse.com>
Date:   Fri Nov 28 13:55:22 2014 +0800

    missing chunk of HVM direct kernel boot patch
    
    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>
    Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 13dc6bf0430eedc3422d81b87764c31e59a73b1f
Author: Razvan Cojocaru <rcojocaru@bitdefender.com>
Date:   Fri Nov 28 14:26:48 2014 +0200

    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.
    
    Suggested-by: Ian Campbell <Ian.Campbell@citrix.com>
    Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

commit d36a3734a6abccd36a8050e19633af1671a2083d
Author: M A Young <m.a.young@durham.ac.uk>
Date:   Tue Dec 2 13:48:54 2014 +0000

    xl: fix migration failure with xl migrate --debug
    
    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>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 1fed4af8d870e6fe4c4e2eceafaf8afba49fc169
Author: Euan Harris <euan.harris@citrix.com>
Date:   Mon Dec 1 10:47:33 2014 +0000

    libxl: libxl_domain_info: fix typo in error message
    
    Signed-off-by: Euan Harris <euan.harris@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 04ae2f6837b35bcfb689baf15f493da626929fb5
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Dec 2 12:48:01 2014 +0100

    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>
    Signed-off-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:13:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10:13:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwTOb-0003Om-Ds; Thu, 04 Dec 2014 10:12: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 1XwTOa-0003Oh-1L
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 10:12:24 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	30/25-17694-78330845; Thu, 04 Dec 2014 10:12:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417687940!10996675!1
X-Originating-IP: [66.165.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 2129 invoked from network); 4 Dec 2014 10:12: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;
	4 Dec 2014 10:12:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199957587"
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, 4 Dec 2014 05:12: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 1XwTOU-00079u-MM;
	Thu, 04 Dec 2014 10:12:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwTOU-00063s-FB;
	Thu, 04 Dec 2014 10:12:18 +0000
Date: Thu, 4 Dec 2014 10:12:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32051-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] 32051: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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. 31986

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair  18 guest-migrate/dst_host/src_host fail blocked in 31986

Tests which did not succeed, but are not blocking:
 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-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  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-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 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  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-win7-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-pair         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-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-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
 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  1 build-check(1)               blocked  n/a
 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  1 build-check(1)               blocked n/a

version targeted for testing:
 xen                  4d1a77ba7ab94183c203226d3fe7ac1cd087c59b
baseline version:
 xen                  188336bb86d0992a2a034ece5f39eccc5d10f337

------------------------------------------------------------
People who touched revisions under test:
  Chunyan Liu <cyliu@suse.com>
  Euan Harris <euan.harris@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  M A Young <m.a.young@durham.ac.uk>
  Michael Young <m.a.young@durham.ac.uk>
  Razvan Cojocaru <rcojocaru@bitdefender.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                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          blocked 
 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                    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-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-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 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-armhf-armhf-libvirt                                     fail    
 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.

------------------------------------------------------------
commit 4d1a77ba7ab94183c203226d3fe7ac1cd087c59b
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Dec 1 11:31:13 2014 +0000

    xl: fix two memory leaks
    
    Free strings returned by libxl_basename after used.
    
    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>
    [ ijc -- s/basename/kernel_basename in parse_config_data to avoid
             shadowing basename(3). ]

commit 276ba7806259c10b186c9cd9115078fb35b28bc7
Author: Euan Harris <euan.harris@citrix.com>
Date:   Mon Dec 1 14:27:06 2014 +0000

    libxl: Don't dereference null new_name pointer in libxl_domain_rename()
    
    libxl__domain_rename() unconditionally dereferences its new_name
    parameter, to check whether it is an empty string.   Add a check to
    avoid a segfault if new_name is null.
    
    Signed-off-by: Euan Harris <euan.harris@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit e3abab74598d96de87e3cbcaf1d567ac854e53cf
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Dec 1 11:31:12 2014 +0000

    libxl: un-constify return value of libxl_basename
    
    The string returned is malloc'ed but marked as "const".
    
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Cc: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit e609bb983ea6e0a5a4d791cffccad0ce3712e12f
Author: Chunyan Liu <cyliu@suse.com>
Date:   Fri Nov 28 13:55:22 2014 +0800

    missing chunk of HVM direct kernel boot patch
    
    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>
    Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 13dc6bf0430eedc3422d81b87764c31e59a73b1f
Author: Razvan Cojocaru <rcojocaru@bitdefender.com>
Date:   Fri Nov 28 14:26:48 2014 +0200

    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.
    
    Suggested-by: Ian Campbell <Ian.Campbell@citrix.com>
    Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

commit d36a3734a6abccd36a8050e19633af1671a2083d
Author: M A Young <m.a.young@durham.ac.uk>
Date:   Tue Dec 2 13:48:54 2014 +0000

    xl: fix migration failure with xl migrate --debug
    
    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>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 1fed4af8d870e6fe4c4e2eceafaf8afba49fc169
Author: Euan Harris <euan.harris@citrix.com>
Date:   Mon Dec 1 10:47:33 2014 +0000

    libxl: libxl_domain_info: fix typo in error message
    
    Signed-off-by: Euan Harris <euan.harris@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 04ae2f6837b35bcfb689baf15f493da626929fb5
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Dec 2 12:48:01 2014 +0100

    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>
    Signed-off-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:14:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10:14:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwTQa-0003Vp-Ui; Thu, 04 Dec 2014 10:14:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sagun@nexchanges.com>) id 1XwTQZ-0003Vg-Uw
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:14:28 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	44/09-18267-30430845; Thu, 04 Dec 2014 10:14:27 +0000
X-Env-Sender: sagun@nexchanges.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417688065!10997381!1
X-Originating-IP: [209.85.218.54]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22855 invoked from network); 4 Dec 2014 10:14:26 -0000
Received: from mail-oi0-f54.google.com (HELO mail-oi0-f54.google.com)
	(209.85.218.54)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 10:14:26 -0000
Received: by mail-oi0-f54.google.com with SMTP id u20so12167598oif.27
	for <xen-devel@lists.xen.org>; Thu, 04 Dec 2014 02:14: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:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=UgWf/itAVzohb+qVkODYTJJDq3riD5RYPQJrIBUs8aw=;
	b=GdN7eOkPGMYe9GqdQ7DQ0uhqtmSPyyYFJjNnfYM0lVFVAge7f8o0FNYKQvMWunJQlG
	Q2PJ3S0kDBjlbHVCBC+HzTp2wdJ+qhYu7gDm/IhT4Mn3udRCEUzMc9lva2x1b8OULvKv
	bjodg8PFhp9S+8r9tmEHV2pEd+8huKyNNYDNR4X2UO6MHrTJfBrmriBkVNX7YL/cK0Pt
	JINONYSwfvd5A5fQfO+2/dkP7UXwQbLQ+ckmr3Xa6AZxDC51IC4kn0d8F+64dpxMVoiU
	4Xc1/2Bdu2SGSot6C1dRborHM91NDbF8rebbhghOl7NsZMYSTzKI8qNPPEUacdKoO3xD
	I7NQ==
X-Gm-Message-State: ALoCoQnK22KOaQEeezKXdFtlsR9BiChfr9UThASP5m03MPuI2AKpUjWtawLg4sQrRKMlpUOfKd0N
MIME-Version: 1.0
X-Received: by 10.182.44.229 with SMTP id h5mr6253640obm.86.1417688064662;
	Thu, 04 Dec 2014 02:14:24 -0800 (PST)
Received: by 10.76.33.136 with HTTP; Thu, 4 Dec 2014 02:14:24 -0800 (PST)
Date: Thu, 4 Dec 2014 15:44:24 +0530
Message-ID: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
From: Sagun Garg <sagun@nexchanges.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Install Xen on ARM in a bare metal fashion on a Nexus
 Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2705179579346713672=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2705179579346713672==
Content-Type: multipart/alternative; boundary=001a11c2e9f27f5c68050961392d

--001a11c2e9f27f5c68050961392d
Content-Type: text/plain; charset=UTF-8

Hi,

I am new to the world of *"Xen on ARM"* would like to seek help from
community on how can I install Xen on ARM on a Nexus Phone / Tablet or an
emulator

I actually wish to try and install a unikernel : LING (Erlang on Xen) on
top of the hypervisor dual booted with Android or QNX on a mobile phone or
a tablet.

If someone can help me point to a TUTORIAL, LINK or some BLOG it will be
awesome.

Cheers
Sagun Garg
Chief System Architect,
www.nexchanges.com
Mumbai, India

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

<div dir=3D"ltr"><div><div><div><div><div><div><div>Hi,<br><br></div>I am n=
ew to the world of <b>&quot;Xen on ARM&quot;</b> would like to seek help fr=
om community on how can I install Xen on ARM on a Nexus Phone / Tablet or a=
n emulator<br><br></div>I actually wish to try and install a unikernel : LI=
NG (Erlang on Xen) on top of the hypervisor dual booted with Android or QNX=
 on a mobile phone or a tablet. <br><br></div>If someone can help me point =
to a TUTORIAL, LINK or some BLOG it will be awesome.<br><br></div>Cheers<br=
></div>Sagun Garg<br></div>Chief System Architect, <br><a href=3D"http://ww=
w.nexchanges.com">www.nexchanges.com</a><br></div>Mumbai, India<br></div>

--001a11c2e9f27f5c68050961392d--


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

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

--===============2705179579346713672==--


From xen-devel-bounces@lists.xen.org Thu Dec 04 10:14:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10:14:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwTQa-0003Vp-Ui; Thu, 04 Dec 2014 10:14:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sagun@nexchanges.com>) id 1XwTQZ-0003Vg-Uw
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:14:28 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	44/09-18267-30430845; Thu, 04 Dec 2014 10:14:27 +0000
X-Env-Sender: sagun@nexchanges.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417688065!10997381!1
X-Originating-IP: [209.85.218.54]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22855 invoked from network); 4 Dec 2014 10:14:26 -0000
Received: from mail-oi0-f54.google.com (HELO mail-oi0-f54.google.com)
	(209.85.218.54)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 10:14:26 -0000
Received: by mail-oi0-f54.google.com with SMTP id u20so12167598oif.27
	for <xen-devel@lists.xen.org>; Thu, 04 Dec 2014 02:14: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:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=UgWf/itAVzohb+qVkODYTJJDq3riD5RYPQJrIBUs8aw=;
	b=GdN7eOkPGMYe9GqdQ7DQ0uhqtmSPyyYFJjNnfYM0lVFVAge7f8o0FNYKQvMWunJQlG
	Q2PJ3S0kDBjlbHVCBC+HzTp2wdJ+qhYu7gDm/IhT4Mn3udRCEUzMc9lva2x1b8OULvKv
	bjodg8PFhp9S+8r9tmEHV2pEd+8huKyNNYDNR4X2UO6MHrTJfBrmriBkVNX7YL/cK0Pt
	JINONYSwfvd5A5fQfO+2/dkP7UXwQbLQ+ckmr3Xa6AZxDC51IC4kn0d8F+64dpxMVoiU
	4Xc1/2Bdu2SGSot6C1dRborHM91NDbF8rebbhghOl7NsZMYSTzKI8qNPPEUacdKoO3xD
	I7NQ==
X-Gm-Message-State: ALoCoQnK22KOaQEeezKXdFtlsR9BiChfr9UThASP5m03MPuI2AKpUjWtawLg4sQrRKMlpUOfKd0N
MIME-Version: 1.0
X-Received: by 10.182.44.229 with SMTP id h5mr6253640obm.86.1417688064662;
	Thu, 04 Dec 2014 02:14:24 -0800 (PST)
Received: by 10.76.33.136 with HTTP; Thu, 4 Dec 2014 02:14:24 -0800 (PST)
Date: Thu, 4 Dec 2014 15:44:24 +0530
Message-ID: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
From: Sagun Garg <sagun@nexchanges.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Install Xen on ARM in a bare metal fashion on a Nexus
 Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2705179579346713672=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2705179579346713672==
Content-Type: multipart/alternative; boundary=001a11c2e9f27f5c68050961392d

--001a11c2e9f27f5c68050961392d
Content-Type: text/plain; charset=UTF-8

Hi,

I am new to the world of *"Xen on ARM"* would like to seek help from
community on how can I install Xen on ARM on a Nexus Phone / Tablet or an
emulator

I actually wish to try and install a unikernel : LING (Erlang on Xen) on
top of the hypervisor dual booted with Android or QNX on a mobile phone or
a tablet.

If someone can help me point to a TUTORIAL, LINK or some BLOG it will be
awesome.

Cheers
Sagun Garg
Chief System Architect,
www.nexchanges.com
Mumbai, India

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

<div dir=3D"ltr"><div><div><div><div><div><div><div>Hi,<br><br></div>I am n=
ew to the world of <b>&quot;Xen on ARM&quot;</b> would like to seek help fr=
om community on how can I install Xen on ARM on a Nexus Phone / Tablet or a=
n emulator<br><br></div>I actually wish to try and install a unikernel : LI=
NG (Erlang on Xen) on top of the hypervisor dual booted with Android or QNX=
 on a mobile phone or a tablet. <br><br></div>If someone can help me point =
to a TUTORIAL, LINK or some BLOG it will be awesome.<br><br></div>Cheers<br=
></div>Sagun Garg<br></div>Chief System Architect, <br><a href=3D"http://ww=
w.nexchanges.com">www.nexchanges.com</a><br></div>Mumbai, India<br></div>

--001a11c2e9f27f5c68050961392d--


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

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

--===============2705179579346713672==--


From xen-devel-bounces@lists.xen.org Thu Dec 04 10:19:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10: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 1XwTVG-0003ni-LO; Thu, 04 Dec 2014 10:19:18 +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 1XwTVE-0003nd-VL
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 10:19:17 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	2D/B2-08051-42530845; Thu, 04 Dec 2014 10:19:16 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417688354!9598242!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16197 invoked from network); 4 Dec 2014 10:19:15 -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;
	4 Dec 2014 10:19:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199606363"
Message-ID: <5480351F.3050907@citrix.com>
Date: Thu, 4 Dec 2014 10:19:11 +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: Julien Grall <julien.grall@linaro.org>, Vitaly Kuznetsov
	<vkuznets@redhat.com>, <xen-devel@lists.xenproject.org>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>
	<547FAFDD.8010005@linaro.org>
In-Reply-To: <547FAFDD.8010005@linaro.org>
X-DLP: MIA1
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 00:50, Julien Grall wrote:
> Hi Vitaly,
> 
> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>> New operation sets the 'recipient' domain which will recieve all
> 
> s/recieve/receive/
> 
>> memory pages from a particular domain and kills the original domain.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> @@ -1764,13 +1765,32 @@ void free_domheap_pages(struct page_info *pg,
>> unsigned int order)
> 
> [..]
> 
>> +        else
>> +        {
>> +            mfn = page_to_mfn(pg);
>> +            gmfn = mfn_to_gmfn(d, mfn);
>> +
>> +            page_set_owner(pg, NULL);
>> +            if ( assign_pages(d->recipient, pg, order, 0) )
>> +                /* assign_pages reports the error by itself */
>> +                goto out;
>> +
>> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn,
>> order) )
> 
> On ARM, mfn_to_gmfn will always return the mfn. This would result to add
> a 1:1 mapping in the recipient domain.
> 
> But ... only DOM0 has its memory mapped 1:1. So this code may blow up
> the P2M of the recipient domain.
> 
> I'm not an x86 expert, but this may also happen when the recipient
> domain is using translated page mode (i.e HVM/PVHM).

mfn_to_gmfn() does the correct thing on x86 as it does a m2p lookup.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:19:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10: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 1XwTVS-0003pA-67; Thu, 04 Dec 2014 10:19:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XwTVR-0003ox-3b
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:19:29 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	41/67-02712-03530845; Thu, 04 Dec 2014 10:19:28 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417688366!12938322!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17770 invoked from network); 4 Dec 2014 10:19:26 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 10:19:26 -0000
Received: by mail-wg0-f46.google.com with SMTP id a1so13928054wgh.19
	for <xen-devel@lists.xen.org>; Thu, 04 Dec 2014 02:19: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=gb4mtWKzjB39Nktid6WXEIJs6MLBFGaE9yY2p/wua3A=;
	b=ky/Wrmh5/K8AL41NXlK33DiR1n7d6pgK0INrN9ku1IejZFSza7SUsYe2//7Us6LE6R
	GYqLCvEL3QZrSJsk/4YylSDZg8eFR6ypYAbh/XWxEv+BCbxen6Ts1KeOV1VTlbybmK/6
	cLIKL2X+EANjLaf31ogwEWNp7HEUxq5CGvccaHBb7YSOBI94O4mGTbbyiCOl3vlzSEaM
	kFmINTlXg0bFQovNGtKipApnjeguLuSD/libI5TFGpm1Q3nfiqAER4wGcbda0TV5GWL1
	noQYBg3QsywPG0uIt3KB6FW+NvVu3pVQgeRcij0GVtWi4keFw2BsPPwD8yS/u2r6WpqT
	eijw==
X-Gm-Message-State: ALoCoQmOd7tNRMvWCGhuCvldA0dbgYTJyUEo2LSYoGjWhA50+qIrBin0PbLyzsktipf0+rhLs6yb
X-Received: by 10.180.76.211 with SMTP id m19mr20486503wiw.73.1417688366329;
	Thu, 04 Dec 2014 02:19:26 -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 gl5sm41188005wib.0.2014.12.04.02.19.23
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 04 Dec 2014 02:19:25 -0800 (PST)
Message-ID: <5480355E.4050502@m2r.biz>
Date: Thu, 04 Dec 2014 11:20: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.3.0
MIME-Version: 1.0
To: Jike Song <jike.song@intel.com>, xen-devel@lists.xen.org, 
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org
References: <53D215D3.50608@intel.com> <547FCAAD.2060406@intel.com>
In-Reply-To: <547FCAAD.2060406@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, "White,
	Michael L" <michael.l.white@intel.com>, "Dong,
	Eddie" <eddie.dong@intel.com>, "Li, Susie" <susie.li@intel.com>,
	"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>,
	"Zhou, Chao" <chao.zhou@intel.com>, "Haron,
	Sandra" <sandra.haron@intel.com>, "Zhu, Libo" <libo.zhu@intel.com>
Subject: Re: [Xen-devel] [Intel-gfx] [Announcement] 2014-Q3 release of XenGT
 - a Mediated Graphics Passthrough Solution from Intel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 04/12/2014 03:45, Jike Song ha scritto:
> Hi all,
>
> We're pleased to announce a public release to Intel Graphics 
> Virtualization Technology (Intel GVT-g, formerly known as XenGT). 
> Intel GVT-g is a complete vGPU solution with mediated pass-through, 
> supported today on 4th generation Intel Core(TM) processors with Intel 
> Graphics processors. A virtual GPU instance is maintained for each VM, 
> with part of performance critical resources directly assigned. The 
> capability of running native graphics driver inside a VM, without 
> hypervisor intervention in performance critical paths, achieves a good 
> balance among performance, feature, and sharing capability. Though we 
> only support Xen on Intel Processor Graphics so far, the core logic 
> can be easily ported to other hypervisors.
>
>
> The news of this update:
>
>
>     - kernel update from 3.11.6 to 3.14.1
>
>     - We plan to integrate Intel GVT-g as a feature in i915 driver. 
> That effort is still under review, not included in this update yet
>
>     - Next update will be around early Jan, 2015
>
>
> This update consists of:
>
>     - Windows HVM support with driver version 15.33.3910
>
>     - Stability fixes, e.g. stabilize GPU, the GPU hang occurrence 
> rate becomes rare now
>
>     - Hardware Media Acceleration for Decoding/Encoding/Transcoding, 
> VC1, H264 etc. format supporting
>
>     - Display enhancements, e.g. DP type is supported for virtual PORT
>
>     - Display port capability virtualization: with this feature, dom0 
> manager could freely assign virtual DDI ports to VM, not necessary to 
> check whether the corresponding physical DDI ports are available
>
>
>
> Please refer to the new setup guide, which provides step-to-step 
> details about building/configuring/running Intel GVT-g:
>
>
>     https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide.pdf 
>
>
>
>
> The new source codes are available at the updated github repos:
>
>
>     Linux: https://github.com/01org/XenGT-Preview-kernel.git
>
>     Xen: https://github.com/01org/XenGT-Preview-xen.git
>
>     Qemu: https://github.com/01org/XenGT-Preview-qemu.git
>
>
> More information about Intel GVT-g background, architecture, etc can 
> be found at:
>
>
>     https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian 
>
>
>     http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf 
>
>
>     https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
>
>
> The previous update can be found here:
>
>
>     http://lists.xen.org/archives/html/xen-devel/2014-07/msg03248.html
>
>
> Appreciate your comments!

Thanks for this very good project.
I did a fast look to xen patch about it, I have some small advices:
change to tools/examples/xmexample.hvm should be to 
tools/examples/xlexample.hvm instead since is implemented in xl and not xm.
I think is good rebase the patch to latest xen-unstable git that have 
many changes, for better reviews and for propose it upstream for xen 4.6 
if will be good.

Thanks for any reply and sorry for my bad english.

>
>
> -- 
> Thanks,
> Jike
>
> On 07/25/2014 04:31 PM, Jike Song wrote:
>> Hi all,
>>
>> We're pleased to announce an update to Intel Graphics Virtualization 
>> Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a 
>> complete vGPU solution with mediated pass-through, supported today on 
>> 4th generation Intel Core(TM) processors with Intel Graphics 
>> processors. A virtual GPU instance is maintained for each VM, with 
>> part of performance critical resources directly assigned. The 
>> capability of running native graphics driver inside a VM, without 
>> hypervisor intervention in performance critical paths, achieves a 
>> good balance among performance, feature, and sharing capability. 
>> Though we only support Xen on Intel Processor Graphics so far, the 
>> core logic can be easily ported to other hypervisors.
>>
>> The news of this update:
>>
>>     - Project code name is "XenGT", now official name is Intel 
>> Graphics Virtualization Technology (Intel GVT-g)
>>     - Currently Intel GVT-g supports Intel Processor Graphics built 
>> into 4th generation Intel Core processors - Haswell platform
>>     - Moving forward, XenGT will change to quarterly release cadence. 
>> Next update will be around early October, 2014.
>>
>> This update consists of:
>>
>>     - Stability fixes, e.g. stable DP support
>>     - Display enhancements, e.g. virtual monitor support. Users can 
>> define a virtual monitor type with customized EDID for virtual 
>> machines, not necessarily the same as physical monitors.
>>     - Improved support for GPU recovery
>>     - Experimental Windows HVM support. To download the experimental 
>> version, see setup guide for details
>>     - Experimental Hardware Media Acceleration for decoding.
>>
>>
>> Please refer to the new setup guide, which provides step-to-step 
>> details about building/configuring/running Intel GVT-g:
>>
>>     https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide.pdf 
>>
>>
>>
>> The new source codes are available at the updated github repos:
>>
>>     Linux: https://github.com/01org/XenGT-Preview-kernel.git
>>     Xen: https://github.com/01org/XenGT-Preview-xen.git
>>     Qemu: https://github.com/01org/XenGT-Preview-qemu.git
>>
>>
>> More information about Intel GVT-g background, architecture, etc can 
>> be found at:
>>
>>     https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian 
>>
>>     http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf 
>>
>>     https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
>>
>> The previous update can be found here:
>>
>>     http://lists.xen.org/archives/html/xen-devel/2014-02/msg01848.html
>>
>> Appreciate your comments!
>>
>>
>>
>>
>> -- 
>> Thanks,
>> Jike
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 04 10:19:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10: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 1XwTVG-0003ni-LO; Thu, 04 Dec 2014 10:19:18 +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 1XwTVE-0003nd-VL
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 10:19:17 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	2D/B2-08051-42530845; Thu, 04 Dec 2014 10:19:16 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417688354!9598242!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16197 invoked from network); 4 Dec 2014 10:19:15 -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;
	4 Dec 2014 10:19:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199606363"
Message-ID: <5480351F.3050907@citrix.com>
Date: Thu, 4 Dec 2014 10:19:11 +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: Julien Grall <julien.grall@linaro.org>, Vitaly Kuznetsov
	<vkuznets@redhat.com>, <xen-devel@lists.xenproject.org>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>
	<547FAFDD.8010005@linaro.org>
In-Reply-To: <547FAFDD.8010005@linaro.org>
X-DLP: MIA1
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 00:50, Julien Grall wrote:
> Hi Vitaly,
> 
> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>> New operation sets the 'recipient' domain which will recieve all
> 
> s/recieve/receive/
> 
>> memory pages from a particular domain and kills the original domain.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> @@ -1764,13 +1765,32 @@ void free_domheap_pages(struct page_info *pg,
>> unsigned int order)
> 
> [..]
> 
>> +        else
>> +        {
>> +            mfn = page_to_mfn(pg);
>> +            gmfn = mfn_to_gmfn(d, mfn);
>> +
>> +            page_set_owner(pg, NULL);
>> +            if ( assign_pages(d->recipient, pg, order, 0) )
>> +                /* assign_pages reports the error by itself */
>> +                goto out;
>> +
>> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn,
>> order) )
> 
> On ARM, mfn_to_gmfn will always return the mfn. This would result to add
> a 1:1 mapping in the recipient domain.
> 
> But ... only DOM0 has its memory mapped 1:1. So this code may blow up
> the P2M of the recipient domain.
> 
> I'm not an x86 expert, but this may also happen when the recipient
> domain is using translated page mode (i.e HVM/PVHM).

mfn_to_gmfn() does the correct thing on x86 as it does a m2p lookup.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:19:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10: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 1XwTVS-0003pA-67; Thu, 04 Dec 2014 10:19:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1XwTVR-0003ox-3b
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:19:29 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	41/67-02712-03530845; Thu, 04 Dec 2014 10:19:28 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417688366!12938322!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17770 invoked from network); 4 Dec 2014 10:19:26 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 10:19:26 -0000
Received: by mail-wg0-f46.google.com with SMTP id a1so13928054wgh.19
	for <xen-devel@lists.xen.org>; Thu, 04 Dec 2014 02:19: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=gb4mtWKzjB39Nktid6WXEIJs6MLBFGaE9yY2p/wua3A=;
	b=ky/Wrmh5/K8AL41NXlK33DiR1n7d6pgK0INrN9ku1IejZFSza7SUsYe2//7Us6LE6R
	GYqLCvEL3QZrSJsk/4YylSDZg8eFR6ypYAbh/XWxEv+BCbxen6Ts1KeOV1VTlbybmK/6
	cLIKL2X+EANjLaf31ogwEWNp7HEUxq5CGvccaHBb7YSOBI94O4mGTbbyiCOl3vlzSEaM
	kFmINTlXg0bFQovNGtKipApnjeguLuSD/libI5TFGpm1Q3nfiqAER4wGcbda0TV5GWL1
	noQYBg3QsywPG0uIt3KB6FW+NvVu3pVQgeRcij0GVtWi4keFw2BsPPwD8yS/u2r6WpqT
	eijw==
X-Gm-Message-State: ALoCoQmOd7tNRMvWCGhuCvldA0dbgYTJyUEo2LSYoGjWhA50+qIrBin0PbLyzsktipf0+rhLs6yb
X-Received: by 10.180.76.211 with SMTP id m19mr20486503wiw.73.1417688366329;
	Thu, 04 Dec 2014 02:19:26 -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 gl5sm41188005wib.0.2014.12.04.02.19.23
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 04 Dec 2014 02:19:25 -0800 (PST)
Message-ID: <5480355E.4050502@m2r.biz>
Date: Thu, 04 Dec 2014 11:20: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.3.0
MIME-Version: 1.0
To: Jike Song <jike.song@intel.com>, xen-devel@lists.xen.org, 
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org
References: <53D215D3.50608@intel.com> <547FCAAD.2060406@intel.com>
In-Reply-To: <547FCAAD.2060406@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, "White,
	Michael L" <michael.l.white@intel.com>, "Dong,
	Eddie" <eddie.dong@intel.com>, "Li, Susie" <susie.li@intel.com>,
	"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>,
	"Zhou, Chao" <chao.zhou@intel.com>, "Haron,
	Sandra" <sandra.haron@intel.com>, "Zhu, Libo" <libo.zhu@intel.com>
Subject: Re: [Xen-devel] [Intel-gfx] [Announcement] 2014-Q3 release of XenGT
 - a Mediated Graphics Passthrough Solution from Intel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 04/12/2014 03:45, Jike Song ha scritto:
> Hi all,
>
> We're pleased to announce a public release to Intel Graphics 
> Virtualization Technology (Intel GVT-g, formerly known as XenGT). 
> Intel GVT-g is a complete vGPU solution with mediated pass-through, 
> supported today on 4th generation Intel Core(TM) processors with Intel 
> Graphics processors. A virtual GPU instance is maintained for each VM, 
> with part of performance critical resources directly assigned. The 
> capability of running native graphics driver inside a VM, without 
> hypervisor intervention in performance critical paths, achieves a good 
> balance among performance, feature, and sharing capability. Though we 
> only support Xen on Intel Processor Graphics so far, the core logic 
> can be easily ported to other hypervisors.
>
>
> The news of this update:
>
>
>     - kernel update from 3.11.6 to 3.14.1
>
>     - We plan to integrate Intel GVT-g as a feature in i915 driver. 
> That effort is still under review, not included in this update yet
>
>     - Next update will be around early Jan, 2015
>
>
> This update consists of:
>
>     - Windows HVM support with driver version 15.33.3910
>
>     - Stability fixes, e.g. stabilize GPU, the GPU hang occurrence 
> rate becomes rare now
>
>     - Hardware Media Acceleration for Decoding/Encoding/Transcoding, 
> VC1, H264 etc. format supporting
>
>     - Display enhancements, e.g. DP type is supported for virtual PORT
>
>     - Display port capability virtualization: with this feature, dom0 
> manager could freely assign virtual DDI ports to VM, not necessary to 
> check whether the corresponding physical DDI ports are available
>
>
>
> Please refer to the new setup guide, which provides step-to-step 
> details about building/configuring/running Intel GVT-g:
>
>
>     https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide.pdf 
>
>
>
>
> The new source codes are available at the updated github repos:
>
>
>     Linux: https://github.com/01org/XenGT-Preview-kernel.git
>
>     Xen: https://github.com/01org/XenGT-Preview-xen.git
>
>     Qemu: https://github.com/01org/XenGT-Preview-qemu.git
>
>
> More information about Intel GVT-g background, architecture, etc can 
> be found at:
>
>
>     https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian 
>
>
>     http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf 
>
>
>     https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
>
>
> The previous update can be found here:
>
>
>     http://lists.xen.org/archives/html/xen-devel/2014-07/msg03248.html
>
>
> Appreciate your comments!

Thanks for this very good project.
I did a fast look to xen patch about it, I have some small advices:
change to tools/examples/xmexample.hvm should be to 
tools/examples/xlexample.hvm instead since is implemented in xl and not xm.
I think is good rebase the patch to latest xen-unstable git that have 
many changes, for better reviews and for propose it upstream for xen 4.6 
if will be good.

Thanks for any reply and sorry for my bad english.

>
>
> -- 
> Thanks,
> Jike
>
> On 07/25/2014 04:31 PM, Jike Song wrote:
>> Hi all,
>>
>> We're pleased to announce an update to Intel Graphics Virtualization 
>> Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a 
>> complete vGPU solution with mediated pass-through, supported today on 
>> 4th generation Intel Core(TM) processors with Intel Graphics 
>> processors. A virtual GPU instance is maintained for each VM, with 
>> part of performance critical resources directly assigned. The 
>> capability of running native graphics driver inside a VM, without 
>> hypervisor intervention in performance critical paths, achieves a 
>> good balance among performance, feature, and sharing capability. 
>> Though we only support Xen on Intel Processor Graphics so far, the 
>> core logic can be easily ported to other hypervisors.
>>
>> The news of this update:
>>
>>     - Project code name is "XenGT", now official name is Intel 
>> Graphics Virtualization Technology (Intel GVT-g)
>>     - Currently Intel GVT-g supports Intel Processor Graphics built 
>> into 4th generation Intel Core processors - Haswell platform
>>     - Moving forward, XenGT will change to quarterly release cadence. 
>> Next update will be around early October, 2014.
>>
>> This update consists of:
>>
>>     - Stability fixes, e.g. stable DP support
>>     - Display enhancements, e.g. virtual monitor support. Users can 
>> define a virtual monitor type with customized EDID for virtual 
>> machines, not necessarily the same as physical monitors.
>>     - Improved support for GPU recovery
>>     - Experimental Windows HVM support. To download the experimental 
>> version, see setup guide for details
>>     - Experimental Hardware Media Acceleration for decoding.
>>
>>
>> Please refer to the new setup guide, which provides step-to-step 
>> details about building/configuring/running Intel GVT-g:
>>
>>     https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Guide.pdf 
>>
>>
>>
>> The new source codes are available at the updated github repos:
>>
>>     Linux: https://github.com/01org/XenGT-Preview-kernel.git
>>     Xen: https://github.com/01org/XenGT-Preview-xen.git
>>     Qemu: https://github.com/01org/XenGT-Preview-qemu.git
>>
>>
>> More information about Intel GVT-g background, architecture, etc can 
>> be found at:
>>
>>     https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian 
>>
>>     http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf 
>>
>>     https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
>>
>> The previous update can be found here:
>>
>>     http://lists.xen.org/archives/html/xen-devel/2014-02/msg01848.html
>>
>> Appreciate your comments!
>>
>>
>>
>>
>> -- 
>> Thanks,
>> Jike
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 04 10:21:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10: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 1XwTXd-000411-NI; Thu, 04 Dec 2014 10:21: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 1XwTXc-00040c-4j
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:21:44 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	30/EA-02696-5B530845; Thu, 04 Dec 2014 10:21:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417688498!9599061!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 15854 invoked from network); 4 Dec 2014 10:21:40 -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;
	4 Dec 2014 10:21:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199607138"
Message-ID: <5480359B.1030609@citrix.com>
Date: Thu, 4 Dec 2014 10:21: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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, Ian Campbell <Ian.Campbell@citrix.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>	<1417175443.23604.18.camel@citrix.com>	<20141202210941.GA1593@laptop.dumpdata.com>	<1417599529.29004.16.camel@citrix.com>
	<20141203155744.GE3081@laptop.dumpdata.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABF82AB@SHSMSX104.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABF82AB@SHSMSX104.ccr.corp.intel.com>
X-DLP: MIA1
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Li, Liang Z" <liang.z.li@intel.com>,
	"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>
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 04/12/14 01:50, Zhang, Yang Z wrote:
> Konrad Rzeszutek Wilk wrote on 2014-12-03:
>> On Wed, Dec 03, 2014 at 09:38:49AM +0000, Ian Campbell wrote:
>>> On Tue, 2014-12-02 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
>>>> On Fri, Nov 28, 2014 at 11:50:43AM +0000, Ian Campbell wrote:
>>>>> 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...
>>>> Jan acked it.
>>> For 4.5?
>> Probably not.
>>> Have you release acked it?
>> No.
>>> This seemed like 4.6 material to me, or at least I've not seen any
>>> mention/argument to the contrary.
>> Correct. 4.6 please.
> I think this more like a bug fixing than a feature. See our previous discussion.

It is allowing HVM guests to use a brand new hardware feature which was
previously unavailable to them.

It is absolutely not a bugfix, and not appropriate for 4.5 at this
point, but a good candidate for acceptance as soon as the 4.6 dev window
opens.

~Andrew

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:21:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10: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 1XwTXd-000411-NI; Thu, 04 Dec 2014 10:21: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 1XwTXc-00040c-4j
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:21:44 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	30/EA-02696-5B530845; Thu, 04 Dec 2014 10:21:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417688498!9599061!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 15854 invoked from network); 4 Dec 2014 10:21:40 -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;
	4 Dec 2014 10:21:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199607138"
Message-ID: <5480359B.1030609@citrix.com>
Date: Thu, 4 Dec 2014 10:21: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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, Ian Campbell <Ian.Campbell@citrix.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>	<1417175443.23604.18.camel@citrix.com>	<20141202210941.GA1593@laptop.dumpdata.com>	<1417599529.29004.16.camel@citrix.com>
	<20141203155744.GE3081@laptop.dumpdata.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABF82AB@SHSMSX104.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABF82AB@SHSMSX104.ccr.corp.intel.com>
X-DLP: MIA1
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Li, Liang Z" <liang.z.li@intel.com>,
	"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>
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 04/12/14 01:50, Zhang, Yang Z wrote:
> Konrad Rzeszutek Wilk wrote on 2014-12-03:
>> On Wed, Dec 03, 2014 at 09:38:49AM +0000, Ian Campbell wrote:
>>> On Tue, 2014-12-02 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
>>>> On Fri, Nov 28, 2014 at 11:50:43AM +0000, Ian Campbell wrote:
>>>>> 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...
>>>> Jan acked it.
>>> For 4.5?
>> Probably not.
>>> Have you release acked it?
>> No.
>>> This seemed like 4.6 material to me, or at least I've not seen any
>>> mention/argument to the contrary.
>> Correct. 4.6 please.
> I think this more like a bug fixing than a feature. See our previous discussion.

It is allowing HVM guests to use a brand new hardware feature which was
previously unavailable to them.

It is absolutely not a bugfix, and not appropriate for 4.5 at this
point, but a good candidate for acceptance as soon as the 4.6 dev window
opens.

~Andrew

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:23:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10: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 1XwTZA-0004Ip-69; Thu, 04 Dec 2014 10:23: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 1XwTZ8-0004If-Rs
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:23:18 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	FC/18-11581-61630845; Thu, 04 Dec 2014 10:23:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417688596!11479579!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 7802 invoked from network); 4 Dec 2014 10:23:17 -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 Dec 2014 10:23:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199608171"
Message-ID: <54803612.4050508@citrix.com>
Date: Thu, 4 Dec 2014 10:23:14 +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: Andrew Reimers <andrew.reimers@orionvm.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <4841C18C109F9B4E86BBDE59113F98D7A8F52D@Exchange1.orionvm.com>
In-Reply-To: <4841C18C109F9B4E86BBDE59113F98D7A8F52D@Exchange1.orionvm.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] Possible bug in xenbus __xenbus_switch_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 04/12/14 09:40, Andrew Reimers wrote:
> HI,
> 
> Looking at the function __xenbus_switch_state in file source/drivers/xen/xenbus/xenbus_client.c,
> 
> The comment says:
> 
> "We check whether the state is currently set to the given value, and
> 	   if not, then the state is set."
> 
> The code loads the old state value, but never does anything with it.

It does:

        if (state == dev->state)
                return 0;

The read of the state key is to check it still exists.

   "Furthermore, if the node has gone, we don't write
    to it, as the device will be tearing down, and we don't want to
    resurrect that directory."

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:23:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10: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 1XwTZA-0004Ip-69; Thu, 04 Dec 2014 10:23: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 1XwTZ8-0004If-Rs
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:23:18 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	FC/18-11581-61630845; Thu, 04 Dec 2014 10:23:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417688596!11479579!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 7802 invoked from network); 4 Dec 2014 10:23:17 -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 Dec 2014 10:23:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199608171"
Message-ID: <54803612.4050508@citrix.com>
Date: Thu, 4 Dec 2014 10:23:14 +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: Andrew Reimers <andrew.reimers@orionvm.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <4841C18C109F9B4E86BBDE59113F98D7A8F52D@Exchange1.orionvm.com>
In-Reply-To: <4841C18C109F9B4E86BBDE59113F98D7A8F52D@Exchange1.orionvm.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] Possible bug in xenbus __xenbus_switch_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 04/12/14 09:40, Andrew Reimers wrote:
> HI,
> 
> Looking at the function __xenbus_switch_state in file source/drivers/xen/xenbus/xenbus_client.c,
> 
> The comment says:
> 
> "We check whether the state is currently set to the given value, and
> 	   if not, then the state is set."
> 
> The code loads the old state value, but never does anything with it.

It does:

        if (state == dev->state)
                return 0;

The read of the state key is to check it still exists.

   "Furthermore, if the node has gone, we don't write
    to it, as the device will be tearing down, and we don't want to
    resurrect that directory."

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:25:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwTbI-0004SM-QY; Thu, 04 Dec 2014 10:25:32 +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 1XwTbH-0004SE-C2
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 10:25:31 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	9E/7A-02697-A9630845; Thu, 04 Dec 2014 10:25:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417688728!8137847!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5826 invoked from network); 4 Dec 2014 10:25: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;
	4 Dec 2014 10:25:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199965467"
Message-ID: <54803696.5060004@citrix.com>
Date: Thu, 4 Dec 2014 10:25:26 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
	<20141203203825.GB8802@laptop.dumpdata.com>
In-Reply-To: <20141203203825.GB8802@laptop.dumpdata.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>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 03/12/14 20:38, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 03, 2014 at 04:04:20PM +0000, David Vrabel wrote:
>> The default limit for the number of PIRQs for hardware domains (dom0)
>> is not sufficient for some (x86) systems.
>>
>> Since the pirq structures are individually and dynamically allocated,
>> the limit for hardware domains may be increased to the number of
>> possible IRQs.
> 
> Why not also expand the number for the guest?

Because the default doesn't need to be increased for domUs at this time
and I did not want to audit the code to make sure a guest can't (for
example) repeatedly map PIRQs, using up all pirqs/irqs in Xen.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:25:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwTbI-0004SM-QY; Thu, 04 Dec 2014 10:25:32 +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 1XwTbH-0004SE-C2
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 10:25:31 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	9E/7A-02697-A9630845; Thu, 04 Dec 2014 10:25:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417688728!8137847!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5826 invoked from network); 4 Dec 2014 10:25: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;
	4 Dec 2014 10:25:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199965467"
Message-ID: <54803696.5060004@citrix.com>
Date: Thu, 4 Dec 2014 10:25:26 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
	<20141203203825.GB8802@laptop.dumpdata.com>
In-Reply-To: <20141203203825.GB8802@laptop.dumpdata.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>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 03/12/14 20:38, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 03, 2014 at 04:04:20PM +0000, David Vrabel wrote:
>> The default limit for the number of PIRQs for hardware domains (dom0)
>> is not sufficient for some (x86) systems.
>>
>> Since the pirq structures are individually and dynamically allocated,
>> the limit for hardware domains may be increased to the number of
>> possible IRQs.
> 
> Why not also expand the number for the guest?

Because the default doesn't need to be increased for domUs at this time
and I did not want to audit the code to make sure a guest can't (for
example) repeatedly map PIRQs, using up all pirqs/irqs in Xen.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:27:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1XwTci-0004Yu-9K; Thu, 04 Dec 2014 10:27:00 +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 1XwTcg-0004Yp-GD
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:26:58 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	21/99-09842-1F630845; Thu, 04 Dec 2014 10:26:57 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417688815!13297406!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 16936 invoked from network); 4 Dec 2014 10:26:56 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-21.messagelabs.com with SMTP;
	4 Dec 2014 10:26:56 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 04 Dec 2014 02:26:55 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="424978558"
Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103])
	by FMSMGA003.fm.intel.com with ESMTP; 04 Dec 2014 02:16:35 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 4 Dec 2014 18:26:52 +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, 4 Dec 2014 18:26:46 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>, "Song, Jike" <jike.song@intel.com>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [Intel-gfx] [Announcement] 2014-Q3 release of
	XenGT - a Mediated Graphics Passthrough Solution from Intel
Thread-Index: AQHQD6vxaPCH2D60dU6EZd8iq1QlaZx/ObLQ
Date: Thu, 4 Dec 2014 10:26:45 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610D564@SHSMSX101.ccr.corp.intel.com>
References: <53D215D3.50608@intel.com> <547FCAAD.2060406@intel.com>
	<5480355E.4050502@m2r.biz>
In-Reply-To: <5480355E.4050502@m2r.biz>
Accept-Language: en-US
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, Yu C" <yu.c.zhang@intel.com>, "White,
	Michael L" <michael.l.white@intel.com>, "Dong,
	Eddie" <eddie.dong@intel.com>, "Li, Susie" <susie.li@intel.com>,
	"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>, "Zhou,
	Chao" <chao.zhou@intel.com>, "Haron,
	Sandra" <sandra.haron@intel.com>, "Zhu, Libo" <libo.zhu@intel.com>
Subject: Re: [Xen-devel] [Intel-gfx] [Announcement] 2014-Q3 release of XenGT
 - a Mediated Graphics Passthrough Solution from Intel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz]
> Sent: Thursday, December 04, 2014 6:20 PM
> 
> Il 04/12/2014 03:45, Jike Song ha scritto:
> > Hi all,
> >
> > We're pleased to announce a public release to Intel Graphics
> > Virtualization Technology (Intel GVT-g, formerly known as XenGT).
> > Intel GVT-g is a complete vGPU solution with mediated pass-through,
> > supported today on 4th generation Intel Core(TM) processors with Intel
> > Graphics processors. A virtual GPU instance is maintained for each VM,
> > with part of performance critical resources directly assigned. The
> > capability of running native graphics driver inside a VM, without
> > hypervisor intervention in performance critical paths, achieves a good
> > balance among performance, feature, and sharing capability. Though we
> > only support Xen on Intel Processor Graphics so far, the core logic
> > can be easily ported to other hypervisors.
> >
> >
> > The news of this update:
> >
> >
> >     - kernel update from 3.11.6 to 3.14.1
> >
> >     - We plan to integrate Intel GVT-g as a feature in i915 driver.
> > That effort is still under review, not included in this update yet
> >
> >     - Next update will be around early Jan, 2015
> >
> >
> > This update consists of:
> >
> >     - Windows HVM support with driver version 15.33.3910
> >
> >     - Stability fixes, e.g. stabilize GPU, the GPU hang occurrence
> > rate becomes rare now
> >
> >     - Hardware Media Acceleration for Decoding/Encoding/Transcoding,
> > VC1, H264 etc. format supporting
> >
> >     - Display enhancements, e.g. DP type is supported for virtual PORT
> >
> >     - Display port capability virtualization: with this feature, dom0
> > manager could freely assign virtual DDI ports to VM, not necessary to
> > check whether the corresponding physical DDI ports are available
> >
> >
> >
> > Please refer to the new setup guide, which provides step-to-step
> > details about building/configuring/running Intel GVT-g:
> >
> >
> >
> https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_G
> uide.pdf
> >
> >
> >
> >
> > The new source codes are available at the updated github repos:
> >
> >
> >     Linux: https://github.com/01org/XenGT-Preview-kernel.git
> >
> >     Xen: https://github.com/01org/XenGT-Preview-xen.git
> >
> >     Qemu: https://github.com/01org/XenGT-Preview-qemu.git
> >
> >
> > More information about Intel GVT-g background, architecture, etc can
> > be found at:
> >
> >
> >
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tia
> n
> >
> >
> >
> http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Sum
> mit-v7_0.pdf
> >
> >
> >     https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
> >
> >
> > The previous update can be found here:
> >
> >
> >     http://lists.xen.org/archives/html/xen-devel/2014-07/msg03248.html
> >
> >
> > Appreciate your comments!
> 
> Thanks for this very good project.
> I did a fast look to xen patch about it, I have some small advices:
> change to tools/examples/xmexample.hvm should be to
> tools/examples/xlexample.hvm instead since is implemented in xl and not xm.
> I think is good rebase the patch to latest xen-unstable git that have
> many changes, for better reviews and for propose it upstream for xen 4.6
> if will be good.
> 
> Thanks for any reply and sorry for my bad english.
> 

Thanks for suggestion. We're now pushing our Xen hypervisor change,
which is much simplified than the code carried in this code drop. That's
why we didn't upgrade to latest xen-unstable, until we have necessary
changes accepted. At that time, lots of code will be removed and 
starting from then we'll follow xen-unstable more closely.

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 Dec 04 10:27:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1XwTci-0004Yu-9K; Thu, 04 Dec 2014 10:27:00 +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 1XwTcg-0004Yp-GD
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:26:58 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	21/99-09842-1F630845; Thu, 04 Dec 2014 10:26:57 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417688815!13297406!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 16936 invoked from network); 4 Dec 2014 10:26:56 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-21.messagelabs.com with SMTP;
	4 Dec 2014 10:26:56 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 04 Dec 2014 02:26:55 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="424978558"
Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103])
	by FMSMGA003.fm.intel.com with ESMTP; 04 Dec 2014 02:16:35 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 4 Dec 2014 18:26:52 +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, 4 Dec 2014 18:26:46 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>, "Song, Jike" <jike.song@intel.com>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [Intel-gfx] [Announcement] 2014-Q3 release of
	XenGT - a Mediated Graphics Passthrough Solution from Intel
Thread-Index: AQHQD6vxaPCH2D60dU6EZd8iq1QlaZx/ObLQ
Date: Thu, 4 Dec 2014 10:26:45 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610D564@SHSMSX101.ccr.corp.intel.com>
References: <53D215D3.50608@intel.com> <547FCAAD.2060406@intel.com>
	<5480355E.4050502@m2r.biz>
In-Reply-To: <5480355E.4050502@m2r.biz>
Accept-Language: en-US
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, Yu C" <yu.c.zhang@intel.com>, "White,
	Michael L" <michael.l.white@intel.com>, "Dong,
	Eddie" <eddie.dong@intel.com>, "Li, Susie" <susie.li@intel.com>,
	"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>, "Zhou,
	Chao" <chao.zhou@intel.com>, "Haron,
	Sandra" <sandra.haron@intel.com>, "Zhu, Libo" <libo.zhu@intel.com>
Subject: Re: [Xen-devel] [Intel-gfx] [Announcement] 2014-Q3 release of XenGT
 - a Mediated Graphics Passthrough Solution from Intel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz]
> Sent: Thursday, December 04, 2014 6:20 PM
> 
> Il 04/12/2014 03:45, Jike Song ha scritto:
> > Hi all,
> >
> > We're pleased to announce a public release to Intel Graphics
> > Virtualization Technology (Intel GVT-g, formerly known as XenGT).
> > Intel GVT-g is a complete vGPU solution with mediated pass-through,
> > supported today on 4th generation Intel Core(TM) processors with Intel
> > Graphics processors. A virtual GPU instance is maintained for each VM,
> > with part of performance critical resources directly assigned. The
> > capability of running native graphics driver inside a VM, without
> > hypervisor intervention in performance critical paths, achieves a good
> > balance among performance, feature, and sharing capability. Though we
> > only support Xen on Intel Processor Graphics so far, the core logic
> > can be easily ported to other hypervisors.
> >
> >
> > The news of this update:
> >
> >
> >     - kernel update from 3.11.6 to 3.14.1
> >
> >     - We plan to integrate Intel GVT-g as a feature in i915 driver.
> > That effort is still under review, not included in this update yet
> >
> >     - Next update will be around early Jan, 2015
> >
> >
> > This update consists of:
> >
> >     - Windows HVM support with driver version 15.33.3910
> >
> >     - Stability fixes, e.g. stabilize GPU, the GPU hang occurrence
> > rate becomes rare now
> >
> >     - Hardware Media Acceleration for Decoding/Encoding/Transcoding,
> > VC1, H264 etc. format supporting
> >
> >     - Display enhancements, e.g. DP type is supported for virtual PORT
> >
> >     - Display port capability virtualization: with this feature, dom0
> > manager could freely assign virtual DDI ports to VM, not necessary to
> > check whether the corresponding physical DDI ports are available
> >
> >
> >
> > Please refer to the new setup guide, which provides step-to-step
> > details about building/configuring/running Intel GVT-g:
> >
> >
> >
> https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_G
> uide.pdf
> >
> >
> >
> >
> > The new source codes are available at the updated github repos:
> >
> >
> >     Linux: https://github.com/01org/XenGT-Preview-kernel.git
> >
> >     Xen: https://github.com/01org/XenGT-Preview-xen.git
> >
> >     Qemu: https://github.com/01org/XenGT-Preview-qemu.git
> >
> >
> > More information about Intel GVT-g background, architecture, etc can
> > be found at:
> >
> >
> >
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tia
> n
> >
> >
> >
> http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Sum
> mit-v7_0.pdf
> >
> >
> >     https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
> >
> >
> > The previous update can be found here:
> >
> >
> >     http://lists.xen.org/archives/html/xen-devel/2014-07/msg03248.html
> >
> >
> > Appreciate your comments!
> 
> Thanks for this very good project.
> I did a fast look to xen patch about it, I have some small advices:
> change to tools/examples/xmexample.hvm should be to
> tools/examples/xlexample.hvm instead since is implemented in xl and not xm.
> I think is good rebase the patch to latest xen-unstable git that have
> many changes, for better reviews and for propose it upstream for xen 4.6
> if will be good.
> 
> Thanks for any reply and sorry for my bad english.
> 

Thanks for suggestion. We're now pushing our Xen hypervisor change,
which is much simplified than the code carried in this code drop. That's
why we didn't upgrade to latest xen-unstable, until we have necessary
changes accepted. At that time, lots of code will be removed and 
starting from then we'll follow xen-unstable more closely.

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 Dec 04 10:29:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10: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 1XwTfN-0004in-Ri; Thu, 04 Dec 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 <Ian.Campbell@citrix.com>) id 1XwTfM-0004ig-6b
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:29:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	19/9F-09842-79730845; Thu, 04 Dec 2014 10:29:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417688981!13352101!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 31038 invoked from network); 4 Dec 2014 10:29:42 -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;
	4 Dec 2014 10:29:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199612494"
Message-ID: <1417688979.22808.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sagun Garg <sagun@nexchanges.com>
Date: Thu, 4 Dec 2014 10:29:39 +0000
In-Reply-To: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@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
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-12-04 at 15:44 +0530, Sagun Garg wrote:
> Hi,
> 
> 
> I am new to the world of "Xen on ARM" would like to seek help from
> community on how can I install Xen on ARM on a Nexus Phone / Tablet or
> an emulator
> 
> 
> I actually wish to try and install a unikernel : LING (Erlang on Xen)
> on top of the hypervisor dual booted with Android or QNX on a mobile
> phone or a tablet. 
> 
> 
> If someone can help me point to a TUTORIAL, LINK or some BLOG it will
> be awesome.

http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions is the
starting point for all Xen on ARM stuff. There is a list of supported
hardware there, but note that it doesn't include Nexus phones etc,
although of course you could port it if you wanted.

Arndale is probably the most mobile-like platform there (being a dev
board for the Exynos processor used in many phones), my personal
recommendation for running Xen on ARM is a sunxi platform, e.g.
cubietruck except in your case I'm not aware of anyone having looked
into the graphics side of things, which is probably a blocker for you.

You may be interested in http://wiki.xen.org/wiki/Xen_ARM_%28PV%29,
which has been run on tablets/phones, but note that it is not developed
by anyone on this list and is mostly abandonware as far as the open
source code goes.

Ian.




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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:29:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10: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 1XwTfN-0004in-Ri; Thu, 04 Dec 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 <Ian.Campbell@citrix.com>) id 1XwTfM-0004ig-6b
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:29:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	19/9F-09842-79730845; Thu, 04 Dec 2014 10:29:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417688981!13352101!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 31038 invoked from network); 4 Dec 2014 10:29:42 -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;
	4 Dec 2014 10:29:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199612494"
Message-ID: <1417688979.22808.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sagun Garg <sagun@nexchanges.com>
Date: Thu, 4 Dec 2014 10:29:39 +0000
In-Reply-To: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@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
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-12-04 at 15:44 +0530, Sagun Garg wrote:
> Hi,
> 
> 
> I am new to the world of "Xen on ARM" would like to seek help from
> community on how can I install Xen on ARM on a Nexus Phone / Tablet or
> an emulator
> 
> 
> I actually wish to try and install a unikernel : LING (Erlang on Xen)
> on top of the hypervisor dual booted with Android or QNX on a mobile
> phone or a tablet. 
> 
> 
> If someone can help me point to a TUTORIAL, LINK or some BLOG it will
> be awesome.

http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions is the
starting point for all Xen on ARM stuff. There is a list of supported
hardware there, but note that it doesn't include Nexus phones etc,
although of course you could port it if you wanted.

Arndale is probably the most mobile-like platform there (being a dev
board for the Exynos processor used in many phones), my personal
recommendation for running Xen on ARM is a sunxi platform, e.g.
cubietruck except in your case I'm not aware of anyone having looked
into the graphics side of things, which is probably a blocker for you.

You may be interested in http://wiki.xen.org/wiki/Xen_ARM_%28PV%29,
which has been run on tablets/phones, but note that it is not developed
by anyone on this list and is mostly abandonware as far as the open
source code goes.

Ian.




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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:38:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwTnQ-00053F-02; Thu, 04 Dec 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 <david.vrabel@citrix.com>) id 1XwTnO-000539-UF
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:38:03 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	FC/E0-17735-98930845; Thu, 04 Dec 2014 10:38:01 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417689480!10958228!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 9247 invoked from network); 4 Dec 2014 10:38:01 -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 Dec 2014 10:38:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199974734"
Message-ID: <54803986.4030208@citrix.com>
Date: Thu, 4 Dec 2014 10:37:58 +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: Andrew Cooper <andrew.cooper3@citrix.com>, Daniel De Graaf
	<dgdegra@tycho.nsa.gov>, George Dunlap <George.Dunlap@eu.citrix.com>
References: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>	<CAFLBxZY253TVWetxMAMCBzcRB3qvd490OOaHpQ1j7fqVyb-90g@mail.gmail.com>	<5477445E.4040803@citrix.com>
	<547F584E.2090003@tycho.nsa.gov> <547F5998.6060904@citrix.com>
In-Reply-To: <547F5998.6060904@citrix.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 03/12/14 18:42, Andrew Cooper wrote:
> 
> XSA-37 was only an XSA because the rules at the time were unclear as
> whether it was an issue or not.  At the same time, the rules were
> clarified to state that issues in a debug build only are not security
> issues.

Given that we occasionally ask our customers to run debug versions of
Xen to diagnose particular problems I think this policy should change
(if not by the Xen project security team, then at least internally).

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:38:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwTnQ-00053F-02; Thu, 04 Dec 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 <david.vrabel@citrix.com>) id 1XwTnO-000539-UF
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:38:03 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	FC/E0-17735-98930845; Thu, 04 Dec 2014 10:38:01 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417689480!10958228!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 9247 invoked from network); 4 Dec 2014 10:38:01 -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 Dec 2014 10:38:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199974734"
Message-ID: <54803986.4030208@citrix.com>
Date: Thu, 4 Dec 2014 10:37:58 +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: Andrew Cooper <andrew.cooper3@citrix.com>, Daniel De Graaf
	<dgdegra@tycho.nsa.gov>, George Dunlap <George.Dunlap@eu.citrix.com>
References: <1416938704-17884-1-git-send-email-dgdegra@tycho.nsa.gov>	<CAFLBxZY253TVWetxMAMCBzcRB3qvd490OOaHpQ1j7fqVyb-90g@mail.gmail.com>	<5477445E.4040803@citrix.com>
	<547F584E.2090003@tycho.nsa.gov> <547F5998.6060904@citrix.com>
In-Reply-To: <547F5998.6060904@citrix.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 03/12/14 18:42, Andrew Cooper wrote:
> 
> XSA-37 was only an XSA because the rules at the time were unclear as
> whether it was an issue or not.  At the same time, the rules were
> clarified to state that issues in a debug build only are not security
> issues.

Given that we occasionally ask our customers to run debug versions of
Xen to diagnose particular problems I think this policy should change
(if not by the Xen project security team, then at least internally).

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:50:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10:50:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwTzP-0005Ld-AJ; Thu, 04 Dec 2014 10:50:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XwTzN-0005LY-WB
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:50:26 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	FB/02-02702-17C30845; Thu, 04 Dec 2014 10:50:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417690222!12958365!1
X-Originating-IP: [66.165.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 9357 invoked from network); 4 Dec 2014 10:50:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 10:50:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199627549"
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, 4 Dec 2014 05:50: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 1XwTzJ-0001JX-75;
	Thu, 04 Dec 2014 10:50:21 +0000
Date: Thu, 4 Dec 2014 10:50:21 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141204105021.GA16532@zion.uk.xensource.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 02:43:37PM +0000, Zhangleiqiang (Trump) wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: Tuesday, December 02, 2014 11:59 PM
> > To: Zhangleiqiang (Trump)
> > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian); Xiaoding
> > (B); Yuzhou (C); Zhuangyuxin
> > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > multiqueue support
> > 
> > On Tue, Dec 02, 2014 at 02:46:36PM +0000, Zhangleiqiang (Trump) wrote:
> > > Thanks for your reply, Wei.
> > >
> > > I do the following testing just now and found the results as follows:
> > >
> > > There are three DomUs (4U4G) are running on Host A (6U6G) and one DomU
> > (4U4G) is running on Host B (6U6G), I send packets from three DomUs to the
> > DomU on Host B simultaneously.
> > >
> > > 1. The "top" output of Host B as follows:
> > >
> > > top - 09:42:11 up  1:07,  2 users,  load average: 2.46, 1.90, 1.47
> > > Tasks: 173 total,   4 running, 169 sleeping,   0 stopped,   0 zombie
> > > %Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 97.3 id,  0.0 wa,  0.0 hi,  0.8
> > > si,  1.9 st
> > > %Cpu1  :  0.0 us, 27.0 sy,  0.0 ni, 63.1 id,  0.0 wa,  0.0 hi,  9.5
> > > si,  0.4 st
> > > %Cpu2  :  0.0 us, 90.0 sy,  0.0 ni,  8.3 id,  0.0 wa,  0.0 hi,  1.7
> > > si,  0.0 st
> > > %Cpu3  :  0.4 us,  1.4 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,  1.4
> > > si,  1.4 st
> > > %Cpu4  :  0.0 us, 60.2 sy,  0.0 ni, 39.5 id,  0.0 wa,  0.0 hi,  0.3
> > > si,  0.0 st
> > > %Cpu5  :  0.0 us,  2.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.0 hi,  6.9 si,  0.9
> > st
> > > KiB Mem:   4517144 total,  3116480 used,  1400664 free,      876
> > buffers
> > > KiB Swap:  2103292 total,        0 used,  2103292 free.  2374656
> > cached Mem
> > >
> > >   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM
> > TIME+ COMMAND
> > >  7440 root      20   0       0      0      0 R 71.10 0.000
> > 8:15.38 vif4.0-q3-guest
> > >  7434 root      20   0       0      0      0 R 59.14 0.000
> > 9:00.58 vif4.0-q0-guest
> > >    18 root      20   0       0      0      0 R 33.89 0.000
> > 2:35.06 ksoftirqd/2
> > >    28 root      20   0       0      0      0 S 20.93 0.000
> > 3:01.81 ksoftirqd/4
> > >
> > >
> > > As shown above, only two netback related processes (vif4.0-*) are running
> > with high cpu usage, and the other 2 netback processes are idle. The "ps"
> > result of vif4.0-* processes as follows:
> > >
> > > root      7434 50.5  0.0      0     0 ?        R    09:23  11:29
> > [vif4.0-q0-guest]
> > > root      7435  0.0  0.0      0     0 ?        S    09:23   0:00
> > [vif4.0-q0-deall]
> > > root      7436  0.0  0.0      0     0 ?        S    09:23   0:00
> > [vif4.0-q1-guest]
> > > root      7437  0.0  0.0      0     0 ?        S    09:23   0:00
> > [vif4.0-q1-deall]
> > > root      7438  0.0  0.0      0     0 ?        S    09:23   0:00
> > [vif4.0-q2-guest]
> > > root      7439  0.0  0.0      0     0 ?        S    09:23   0:00
> > [vif4.0-q2-deall]
> > > root      7440 48.1  0.0      0     0 ?        R    09:23  10:55
> > [vif4.0-q3-guest]
> > > root      7441  0.0  0.0      0     0 ?        S    09:23   0:00
> > [vif4.0-q3-deall]
> > > root      9724  0.0  0.0   9244  1520 pts/0    S+   09:46   0:00
> > grep --color=auto
> > >
> > >
> > > 2. The "rx" related content in /proc/interupts in receiver DomU (on Host B):
> > >
> > > 73: 	2		0		2925405		0			xen-dyn-event
> > 	eth0-q0-rx
> > > 75: 	43		93		0			118			xen-dyn-event
> > 	eth0-q1-rx
> > > 77: 	2		3376	14			1983		xen-dyn-event
> > 	eth0-q2-rx
> > > 79: 	2414666	0		9			0			xen-dyn-event
> > 	eth0-q3-rx
> > >
> > > As shown above, it seems like that only q0 and q3 handles the interrupt
> > triggered by packet receving.
> > >
> > > Any advise? Thanks.
> > 
> > Netback selects queue based on the return value of skb_get_queue_mapping.
> > The queue mapping is set by core driver or ndo_select_queue (if specified by
> > individual driver). In this case netback doesn't have its implementation of
> > ndo_select_queue, so it's up to core driver to decide which queue to dispatch
> > the packet to.  I think you need to inspect why Dom0 only steers traffic to
> > these two queues but not all of them.
> > 
> > Don't know which utility is handy for this job. Probably tc(8) is useful?
> 
> Thanks Wei.
> 

> I think the reason for the above results that only two
> netback/netfront processes works hard is the queue select method. I
> have tried to send packets from multiple host/vm to a vm, and all of
> the netback/netfront processes are running with high cpu usage a few
> times.
> 

A few times? You might want to check some patches to rework RX stall
detection by David Vrabel that went in after 3.16.

> However, I find another issue. Even using 6 queues and making sure
> that all of these 6 netback processes running with high cpu usage
> (indeed, any of it running with 87% cpu usage), the whole VM receive
> throughout is not very higher than results when using 4 queues. The
> results are from 4.5Gbps to 5.04 Gbps using TCP with 512 bytes length
> and 4.3Gbps to 5.78Gbps using TCP with 1460 bytes length.
> 

I would like to ask if you're still using 4U4G (4 CPU 4 G?)
configuration? If so, please make sure there are at least the same
number of vcpus as queues.

> According to the testing result from WIKI:
> http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_performance_testing,
> The VM receive throughput is also more lower than VM transmit. 
> 

I think that's expected, because guest RX data path still uses
grant_copy while guest TX uses grant_map to do zero-copy transmit.

> I am wondering why the VM receive throughout cannot be up to 8-10Gbps
> as VM transmit under multi-queue?  I also tried to send packets
> directly from Local Dom0 to DomU, the DomU receive throughput can
> reach about 8-12Gbps, so I am also wondering why transmitting packets
> from Dom0 to Remote DomU can only reach about 4-5Gbps throughout?

If data is from Dom0 to DomU then SKB is probably not fragmented by
network stack.  You can use tcpdump to check that.

Wei.

> 
> > Wei.
> > 
> > > ----------
> > > zhangleiqiang (Trump)
> > >
> > > Best Regards
> > >
> > >
> > > > -----Original Message-----
> > > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > > Sent: Tuesday, December 02, 2014 8:12 PM
> > > > To: Zhangleiqiang (Trump)
> > > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian);
> > > > Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > > > multiqueue support
> > > >
> > > > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump) wrote:
> > > > > > -----Original Message-----
> > > > > > From: xen-devel-bounces@lists.xen.org
> > > > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei Liu
> > > > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > > > To: zhangleiqiang
> > > > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > > > Subject: Re: [Xen-devel] Poor network performance between DomU
> > > > > > with multiqueue support
> > > > > >
> > > > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > > > > Hi, all
> > > > > > >     I am testing the performance of xen netfront-netback
> > > > > > > driver that with
> > > > > > multi-queues support. The throughput from domU to remote dom0 is
> > > > > > 9.2Gb/s, but the throughput from domU to remote domU is only
> > > > > > 3.6Gb/s, I think the bottleneck is the throughput from dom0 to
> > > > > > local domU. However, we have done some testing and found the
> > > > > > throughput from dom0 to local domU is 5.8Gb/s.
> > > > > > >     And if we send packets from one DomU to other 3 DomUs on
> > > > > > > different
> > > > > > host simultaneously, the sum of throughout can reach 9Gbps. It
> > > > > > seems like the bottleneck is the receiver?
> > > > > > >     After some analysis, I found that even the max_queue of
> > > > > > > netfront/back
> > > > > > is set to 4, there are some strange results as follows:
> > > > > > >     1. In domU, only one rx queue deal with softirq
> > > > > >
> > > > > > Try to bind irq to different vcpus?
> > > > >
> > > > > Do you mean we try to bind irq to different vcpus in DomU? I will try it
> > now.
> > > > >
> > > >
> > > > Yes. Given the fact that you have two backend threads running while
> > > > only one DomU vcpu is busy, it smells like misconfiguration in DomU.
> > > >
> > > > If this phenomenon persists after correctly binding irqs, you might
> > > > want to check traffic is steering correctly to different queues.
> > > >
> > > > > >
> > > > > > >     2. In dom0, only two netback queues process are scheduled,
> > > > > > > other two
> > > > > > process aren't scheduled.
> > > > > >
> > > > > > How many Dom0 vcpu do you have? If it only has two then there
> > > > > > will only be two processes running at a time.
> > > > >
> > > > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU running
> > > > > in
> > > > Dom0 and so four netback processes are running in Dom0 (because the
> > > > max_queue param of netback kernel module is set to 4).
> > > > > The phenomenon is that only 2 of these four netback process were
> > > > > running
> > > > with about 70% cpu usage, and another two use little CPU.
> > > > > Is there a hash algorithm to determine which netback process to
> > > > > handle the
> > > > input packet?
> > > > >
> > > >
> > > > I think that's whatever default algorithm Linux kernel is using.
> > > >
> > > > We don't currently support other algorithms.
> > > >
> > > > Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:50:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10:50:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwTzP-0005Ld-AJ; Thu, 04 Dec 2014 10:50:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XwTzN-0005LY-WB
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:50:26 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	FB/02-02702-17C30845; Thu, 04 Dec 2014 10:50:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417690222!12958365!1
X-Originating-IP: [66.165.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 9357 invoked from network); 4 Dec 2014 10:50:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 10:50:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199627549"
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, 4 Dec 2014 05:50: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 1XwTzJ-0001JX-75;
	Thu, 04 Dec 2014 10:50:21 +0000
Date: Thu, 4 Dec 2014 10:50:21 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141204105021.GA16532@zion.uk.xensource.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 02:43:37PM +0000, Zhangleiqiang (Trump) wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: Tuesday, December 02, 2014 11:59 PM
> > To: Zhangleiqiang (Trump)
> > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian); Xiaoding
> > (B); Yuzhou (C); Zhuangyuxin
> > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > multiqueue support
> > 
> > On Tue, Dec 02, 2014 at 02:46:36PM +0000, Zhangleiqiang (Trump) wrote:
> > > Thanks for your reply, Wei.
> > >
> > > I do the following testing just now and found the results as follows:
> > >
> > > There are three DomUs (4U4G) are running on Host A (6U6G) and one DomU
> > (4U4G) is running on Host B (6U6G), I send packets from three DomUs to the
> > DomU on Host B simultaneously.
> > >
> > > 1. The "top" output of Host B as follows:
> > >
> > > top - 09:42:11 up  1:07,  2 users,  load average: 2.46, 1.90, 1.47
> > > Tasks: 173 total,   4 running, 169 sleeping,   0 stopped,   0 zombie
> > > %Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 97.3 id,  0.0 wa,  0.0 hi,  0.8
> > > si,  1.9 st
> > > %Cpu1  :  0.0 us, 27.0 sy,  0.0 ni, 63.1 id,  0.0 wa,  0.0 hi,  9.5
> > > si,  0.4 st
> > > %Cpu2  :  0.0 us, 90.0 sy,  0.0 ni,  8.3 id,  0.0 wa,  0.0 hi,  1.7
> > > si,  0.0 st
> > > %Cpu3  :  0.4 us,  1.4 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,  1.4
> > > si,  1.4 st
> > > %Cpu4  :  0.0 us, 60.2 sy,  0.0 ni, 39.5 id,  0.0 wa,  0.0 hi,  0.3
> > > si,  0.0 st
> > > %Cpu5  :  0.0 us,  2.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.0 hi,  6.9 si,  0.9
> > st
> > > KiB Mem:   4517144 total,  3116480 used,  1400664 free,      876
> > buffers
> > > KiB Swap:  2103292 total,        0 used,  2103292 free.  2374656
> > cached Mem
> > >
> > >   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM
> > TIME+ COMMAND
> > >  7440 root      20   0       0      0      0 R 71.10 0.000
> > 8:15.38 vif4.0-q3-guest
> > >  7434 root      20   0       0      0      0 R 59.14 0.000
> > 9:00.58 vif4.0-q0-guest
> > >    18 root      20   0       0      0      0 R 33.89 0.000
> > 2:35.06 ksoftirqd/2
> > >    28 root      20   0       0      0      0 S 20.93 0.000
> > 3:01.81 ksoftirqd/4
> > >
> > >
> > > As shown above, only two netback related processes (vif4.0-*) are running
> > with high cpu usage, and the other 2 netback processes are idle. The "ps"
> > result of vif4.0-* processes as follows:
> > >
> > > root      7434 50.5  0.0      0     0 ?        R    09:23  11:29
> > [vif4.0-q0-guest]
> > > root      7435  0.0  0.0      0     0 ?        S    09:23   0:00
> > [vif4.0-q0-deall]
> > > root      7436  0.0  0.0      0     0 ?        S    09:23   0:00
> > [vif4.0-q1-guest]
> > > root      7437  0.0  0.0      0     0 ?        S    09:23   0:00
> > [vif4.0-q1-deall]
> > > root      7438  0.0  0.0      0     0 ?        S    09:23   0:00
> > [vif4.0-q2-guest]
> > > root      7439  0.0  0.0      0     0 ?        S    09:23   0:00
> > [vif4.0-q2-deall]
> > > root      7440 48.1  0.0      0     0 ?        R    09:23  10:55
> > [vif4.0-q3-guest]
> > > root      7441  0.0  0.0      0     0 ?        S    09:23   0:00
> > [vif4.0-q3-deall]
> > > root      9724  0.0  0.0   9244  1520 pts/0    S+   09:46   0:00
> > grep --color=auto
> > >
> > >
> > > 2. The "rx" related content in /proc/interupts in receiver DomU (on Host B):
> > >
> > > 73: 	2		0		2925405		0			xen-dyn-event
> > 	eth0-q0-rx
> > > 75: 	43		93		0			118			xen-dyn-event
> > 	eth0-q1-rx
> > > 77: 	2		3376	14			1983		xen-dyn-event
> > 	eth0-q2-rx
> > > 79: 	2414666	0		9			0			xen-dyn-event
> > 	eth0-q3-rx
> > >
> > > As shown above, it seems like that only q0 and q3 handles the interrupt
> > triggered by packet receving.
> > >
> > > Any advise? Thanks.
> > 
> > Netback selects queue based on the return value of skb_get_queue_mapping.
> > The queue mapping is set by core driver or ndo_select_queue (if specified by
> > individual driver). In this case netback doesn't have its implementation of
> > ndo_select_queue, so it's up to core driver to decide which queue to dispatch
> > the packet to.  I think you need to inspect why Dom0 only steers traffic to
> > these two queues but not all of them.
> > 
> > Don't know which utility is handy for this job. Probably tc(8) is useful?
> 
> Thanks Wei.
> 

> I think the reason for the above results that only two
> netback/netfront processes works hard is the queue select method. I
> have tried to send packets from multiple host/vm to a vm, and all of
> the netback/netfront processes are running with high cpu usage a few
> times.
> 

A few times? You might want to check some patches to rework RX stall
detection by David Vrabel that went in after 3.16.

> However, I find another issue. Even using 6 queues and making sure
> that all of these 6 netback processes running with high cpu usage
> (indeed, any of it running with 87% cpu usage), the whole VM receive
> throughout is not very higher than results when using 4 queues. The
> results are from 4.5Gbps to 5.04 Gbps using TCP with 512 bytes length
> and 4.3Gbps to 5.78Gbps using TCP with 1460 bytes length.
> 

I would like to ask if you're still using 4U4G (4 CPU 4 G?)
configuration? If so, please make sure there are at least the same
number of vcpus as queues.

> According to the testing result from WIKI:
> http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_performance_testing,
> The VM receive throughput is also more lower than VM transmit. 
> 

I think that's expected, because guest RX data path still uses
grant_copy while guest TX uses grant_map to do zero-copy transmit.

> I am wondering why the VM receive throughout cannot be up to 8-10Gbps
> as VM transmit under multi-queue?  I also tried to send packets
> directly from Local Dom0 to DomU, the DomU receive throughput can
> reach about 8-12Gbps, so I am also wondering why transmitting packets
> from Dom0 to Remote DomU can only reach about 4-5Gbps throughout?

If data is from Dom0 to DomU then SKB is probably not fragmented by
network stack.  You can use tcpdump to check that.

Wei.

> 
> > Wei.
> > 
> > > ----------
> > > zhangleiqiang (Trump)
> > >
> > > Best Regards
> > >
> > >
> > > > -----Original Message-----
> > > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > > Sent: Tuesday, December 02, 2014 8:12 PM
> > > > To: Zhangleiqiang (Trump)
> > > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian);
> > > > Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > > > multiqueue support
> > > >
> > > > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump) wrote:
> > > > > > -----Original Message-----
> > > > > > From: xen-devel-bounces@lists.xen.org
> > > > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei Liu
> > > > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > > > To: zhangleiqiang
> > > > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > > > Subject: Re: [Xen-devel] Poor network performance between DomU
> > > > > > with multiqueue support
> > > > > >
> > > > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > > > > Hi, all
> > > > > > >     I am testing the performance of xen netfront-netback
> > > > > > > driver that with
> > > > > > multi-queues support. The throughput from domU to remote dom0 is
> > > > > > 9.2Gb/s, but the throughput from domU to remote domU is only
> > > > > > 3.6Gb/s, I think the bottleneck is the throughput from dom0 to
> > > > > > local domU. However, we have done some testing and found the
> > > > > > throughput from dom0 to local domU is 5.8Gb/s.
> > > > > > >     And if we send packets from one DomU to other 3 DomUs on
> > > > > > > different
> > > > > > host simultaneously, the sum of throughout can reach 9Gbps. It
> > > > > > seems like the bottleneck is the receiver?
> > > > > > >     After some analysis, I found that even the max_queue of
> > > > > > > netfront/back
> > > > > > is set to 4, there are some strange results as follows:
> > > > > > >     1. In domU, only one rx queue deal with softirq
> > > > > >
> > > > > > Try to bind irq to different vcpus?
> > > > >
> > > > > Do you mean we try to bind irq to different vcpus in DomU? I will try it
> > now.
> > > > >
> > > >
> > > > Yes. Given the fact that you have two backend threads running while
> > > > only one DomU vcpu is busy, it smells like misconfiguration in DomU.
> > > >
> > > > If this phenomenon persists after correctly binding irqs, you might
> > > > want to check traffic is steering correctly to different queues.
> > > >
> > > > > >
> > > > > > >     2. In dom0, only two netback queues process are scheduled,
> > > > > > > other two
> > > > > > process aren't scheduled.
> > > > > >
> > > > > > How many Dom0 vcpu do you have? If it only has two then there
> > > > > > will only be two processes running at a time.
> > > > >
> > > > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU running
> > > > > in
> > > > Dom0 and so four netback processes are running in Dom0 (because the
> > > > max_queue param of netback kernel module is set to 4).
> > > > > The phenomenon is that only 2 of these four netback process were
> > > > > running
> > > > with about 70% cpu usage, and another two use little CPU.
> > > > > Is there a hash algorithm to determine which netback process to
> > > > > handle the
> > > > input packet?
> > > > >
> > > >
> > > > I think that's whatever default algorithm Linux kernel is using.
> > > >
> > > > We don't currently support other algorithms.
> > > >
> > > > Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:52:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10:52:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwU1W-0005V6-Qw; Thu, 04 Dec 2014 10:52:38 +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 1XwU1V-0005Uz-ME
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 10:52:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4E/12-15461-5FC30845; Thu, 04 Dec 2014 10:52:37 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417690356!13359406!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26124 invoked from network); 4 Dec 2014 10:52:36 -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;
	4 Dec 2014 10:52:36 -0000
Received: by mail-wg0-f46.google.com with SMTP id a1so13985009wgh.5
	for <xen-devel@lists.xenproject.org>;
	Thu, 04 Dec 2014 02:52: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=NqmGFzy6afphCZqvQoUWMAhVIiuUO8xOtkqIQFv31P4=;
	b=VXczBGbT88J3FRTbBRAGhmYq3lbckegeJTYQZwLd2F3PYTOcJ/4hhN4R7KHGLUiHLO
	q8RV7QpfBc2mK6+LoF16bLEHtY6+efda0RUWw2Tm+xCiAZKoFGAfvgUdW7tz7/5kb+27
	vnW9Jh6K797KpLVihYjDSabHd+4xnop54UvirBb6WLU/9j0PETab0WdCVHkWCNiz1T8d
	qjF2kZLWSuRJ4dq1PtlkVgTAFK0896yDBTNlumu37irNRY9IiUHfd0S0Up53mkskgTJw
	6yriqeHPyQxvAiNff99AWwHAvfesatjIkRv9VsSY0khqwxNGOiaHtifSciZiM1/l/gNB
	sRVQ==
X-Gm-Message-State: ALoCoQlyjQJEUG4BGwJR3JxZwFUjaXewmhcsqDR1+YRK5hUZ/EKY3hl+2rMkE3QNmTLxcfK6gqnV
X-Received: by 10.180.20.106 with SMTP id m10mr61803608wie.1.1417690356272;
	Thu, 04 Dec 2014 02:52:36 -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
	wz5sm39986985wjc.29.2014.12.04.02.52.34 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 04 Dec 2014 02:52:35 -0800 (PST)
Message-ID: <54803CF2.8080009@linaro.org>
Date: Thu, 04 Dec 2014 10:52: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.3.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, 
	Vitaly Kuznetsov <vkuznets@redhat.com>, xen-devel@lists.xenproject.org
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>
	<547FAFDD.8010005@linaro.org> <5480351F.3050907@citrix.com>
In-Reply-To: <5480351F.3050907@citrix.com>
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 04/12/2014 10:19, David Vrabel wrote:
> On 04/12/14 00:50, Julien Grall wrote:
>> Hi Vitaly,
>>
>> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>>> New operation sets the 'recipient' domain which will recieve all
>>
>> s/recieve/receive/
>>
>>> memory pages from a particular domain and kills the original domain.
>>>
>>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>>> ---
>>> @@ -1764,13 +1765,32 @@ void free_domheap_pages(struct page_info *pg,
>>> unsigned int order)
>>
>> [..]
>>
>>> +        else
>>> +        {
>>> +            mfn = page_to_mfn(pg);
>>> +            gmfn = mfn_to_gmfn(d, mfn);
>>> +
>>> +            page_set_owner(pg, NULL);
>>> +            if ( assign_pages(d->recipient, pg, order, 0) )
>>> +                /* assign_pages reports the error by itself */
>>> +                goto out;
>>> +
>>> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn,
>>> order) )
>>
>> On ARM, mfn_to_gmfn will always return the mfn. This would result to add
>> a 1:1 mapping in the recipient domain.
>>
>> But ... only DOM0 has its memory mapped 1:1. So this code may blow up
>> the P2M of the recipient domain.
>>
>> I'm not an x86 expert, but this may also happen when the recipient
>> domain is using translated page mode (i.e HVM/PVHM).
>
> mfn_to_gmfn() does the correct thing on x86 as it does a m2p lookup.

Is it because machine_to_phys_mapping caches the translation for dying
domain?

-- 
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 Dec 04 10:52:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10:52:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwU1W-0005V6-Qw; Thu, 04 Dec 2014 10:52:38 +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 1XwU1V-0005Uz-ME
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 10:52:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	4E/12-15461-5FC30845; Thu, 04 Dec 2014 10:52:37 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417690356!13359406!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26124 invoked from network); 4 Dec 2014 10:52:36 -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;
	4 Dec 2014 10:52:36 -0000
Received: by mail-wg0-f46.google.com with SMTP id a1so13985009wgh.5
	for <xen-devel@lists.xenproject.org>;
	Thu, 04 Dec 2014 02:52: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=NqmGFzy6afphCZqvQoUWMAhVIiuUO8xOtkqIQFv31P4=;
	b=VXczBGbT88J3FRTbBRAGhmYq3lbckegeJTYQZwLd2F3PYTOcJ/4hhN4R7KHGLUiHLO
	q8RV7QpfBc2mK6+LoF16bLEHtY6+efda0RUWw2Tm+xCiAZKoFGAfvgUdW7tz7/5kb+27
	vnW9Jh6K797KpLVihYjDSabHd+4xnop54UvirBb6WLU/9j0PETab0WdCVHkWCNiz1T8d
	qjF2kZLWSuRJ4dq1PtlkVgTAFK0896yDBTNlumu37irNRY9IiUHfd0S0Up53mkskgTJw
	6yriqeHPyQxvAiNff99AWwHAvfesatjIkRv9VsSY0khqwxNGOiaHtifSciZiM1/l/gNB
	sRVQ==
X-Gm-Message-State: ALoCoQlyjQJEUG4BGwJR3JxZwFUjaXewmhcsqDR1+YRK5hUZ/EKY3hl+2rMkE3QNmTLxcfK6gqnV
X-Received: by 10.180.20.106 with SMTP id m10mr61803608wie.1.1417690356272;
	Thu, 04 Dec 2014 02:52:36 -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
	wz5sm39986985wjc.29.2014.12.04.02.52.34 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 04 Dec 2014 02:52:35 -0800 (PST)
Message-ID: <54803CF2.8080009@linaro.org>
Date: Thu, 04 Dec 2014 10:52: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.3.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, 
	Vitaly Kuznetsov <vkuznets@redhat.com>, xen-devel@lists.xenproject.org
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>
	<547FAFDD.8010005@linaro.org> <5480351F.3050907@citrix.com>
In-Reply-To: <5480351F.3050907@citrix.com>
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 04/12/2014 10:19, David Vrabel wrote:
> On 04/12/14 00:50, Julien Grall wrote:
>> Hi Vitaly,
>>
>> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>>> New operation sets the 'recipient' domain which will recieve all
>>
>> s/recieve/receive/
>>
>>> memory pages from a particular domain and kills the original domain.
>>>
>>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>>> ---
>>> @@ -1764,13 +1765,32 @@ void free_domheap_pages(struct page_info *pg,
>>> unsigned int order)
>>
>> [..]
>>
>>> +        else
>>> +        {
>>> +            mfn = page_to_mfn(pg);
>>> +            gmfn = mfn_to_gmfn(d, mfn);
>>> +
>>> +            page_set_owner(pg, NULL);
>>> +            if ( assign_pages(d->recipient, pg, order, 0) )
>>> +                /* assign_pages reports the error by itself */
>>> +                goto out;
>>> +
>>> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn,
>>> order) )
>>
>> On ARM, mfn_to_gmfn will always return the mfn. This would result to add
>> a 1:1 mapping in the recipient domain.
>>
>> But ... only DOM0 has its memory mapped 1:1. So this code may blow up
>> the P2M of the recipient domain.
>>
>> I'm not an x86 expert, but this may also happen when the recipient
>> domain is using translated page mode (i.e HVM/PVHM).
>
> mfn_to_gmfn() does the correct thing on x86 as it does a m2p lookup.

Is it because machine_to_phys_mapping caches the translation for dying
domain?

-- 
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 Dec 04 10:57:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10: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 1XwU5m-0005kp-Ge; Thu, 04 Dec 2014 10:57:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XwU5k-0005kk-BO
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:57:00 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	90/3E-25276-BFD30845; Thu, 04 Dec 2014 10:56:59 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417690618!6061877!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11881 invoked from network); 4 Dec 2014 10:56:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 10:56:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199989276"
Message-ID: <54803DF7.1030903@citrix.com>
Date: Thu, 4 Dec 2014 10:56:55 +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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, <david.vrabel@citrix.com>,
	<konrad.wilk@oracle.com>, <stefano.stabellini@eu.citrix.com>
References: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
X-DLP: MIA1
Cc: linux-kernel@vger.kernel.org, jun.nakajima@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4 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 02/12/14 20:19, Boris Ostrovsky wrote:
> Changes in v4:
> * Added comment describing what we check for in pci_xen_init()

I applied v3 ages ago to the devel/for-linus-3.19 branch and I'm not
going to mess about replacing it for a comment change.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 10:57:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 10: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 1XwU5m-0005kp-Ge; Thu, 04 Dec 2014 10:57:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XwU5k-0005kk-BO
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 10:57:00 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	90/3E-25276-BFD30845; Thu, 04 Dec 2014 10:56:59 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417690618!6061877!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11881 invoked from network); 4 Dec 2014 10:56:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 10:56:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199989276"
Message-ID: <54803DF7.1030903@citrix.com>
Date: Thu, 4 Dec 2014 10:56:55 +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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, <david.vrabel@citrix.com>,
	<konrad.wilk@oracle.com>, <stefano.stabellini@eu.citrix.com>
References: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
X-DLP: MIA1
Cc: linux-kernel@vger.kernel.org, jun.nakajima@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4 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 02/12/14 20:19, Boris Ostrovsky wrote:
> Changes in v4:
> * Added comment describing what we check for in pci_xen_init()

I applied v3 ages ago to the devel/for-linus-3.19 branch and I'm not
going to mess about replacing it for a comment change.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:01:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11:01:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwU9h-0005uS-5h; Thu, 04 Dec 2014 11:01:05 +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 1XwU9g-0005uN-CZ
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 11:01:04 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	D4/C7-18267-FEE30845; Thu, 04 Dec 2014 11:01:03 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417690863!7298733!1
X-Originating-IP: [74.125.82.41]
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 28720 invoked from network); 4 Dec 2014 11:01:03 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 11:01:03 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so22367606wgg.0
	for <xen-devel@lists.xenproject.org>;
	Thu, 04 Dec 2014 03:01: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
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=QzNqTj4qs62gpCv/LRZFoOWfwfdecJNJ0lUy4dGxob8=;
	b=FDXsaomVp6L9h29pqQzq48SkqIT1Z1a4AL2MNWsOFPdbHb4g0+07O3ypyDh7Za/BRF
	YxNxL+bnMSN/t/cF+3ISqDIJ8QD5vQBfSGtr7pniezi0HAf0QgbjQ4lGRIOqihc7d4LT
	iLOxpaGcjNaAnldqcZLefdbDaA2Q3hfmD4I/bEpauOvkW2Zx37lrVv+mEvV43sTdyrKl
	YZyPedvItnvwxirYeGNXO9vkUsn+Baj6V+NPJisTRUO+yvJvYCCCZO0kor6Mgr4ikRf1
	B93vjgYktst4fD1ALVb6uYQ72zuWBNgjlOsW6cmHjbqaQm3saFVa98YNvLnU60p1iRHh
	FL9w==
X-Gm-Message-State: ALoCoQlAhgrU7Z3yXjMSpFkpGCyXoIbgqs5tP/o1C9UOuWCv3kDiqrfyT+5yRGD9yz8/Z4/P6Pnm
X-Received: by 10.180.73.206 with SMTP id n14mr20746794wiv.60.1417690862780;
	Thu, 04 Dec 2014 03:01:02 -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
	bc1sm54475418wib.16.2014.12.04.03.01.01 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 04 Dec 2014 03:01:02 -0800 (PST)
Message-ID: <54803EEC.5040404@linaro.org>
Date: Thu, 04 Dec 2014 11:01:00 +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.3.0
MIME-Version: 1.0
To: Vitaly Kuznetsov <vkuznets@redhat.com>, 
 xen-devel@lists.xenproject.org
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-5-git-send-email-vkuznets@redhat.com>
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/2014 17:16, Vitaly Kuznetsov wrote:
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index a42d0b8..552e4a3 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -366,6 +366,8 @@ struct domain
>       bool_t           is_privileged;
>       /* Which guest this guest has privileges on */
>       struct domain   *target;
> +    /* Which guest receives freed memory pages */

It took me a while to understand that the recipient domain is a newly 
created domain, right? It might be worth to add a word here (and maybe 
in assign_pages).

With that in mind, the code in assign_pages makes more sense.

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 Dec 04 11:01:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11:01:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwU9h-0005uS-5h; Thu, 04 Dec 2014 11:01:05 +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 1XwU9g-0005uN-CZ
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 11:01:04 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	D4/C7-18267-FEE30845; Thu, 04 Dec 2014 11:01:03 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417690863!7298733!1
X-Originating-IP: [74.125.82.41]
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 28720 invoked from network); 4 Dec 2014 11:01:03 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 11:01:03 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so22367606wgg.0
	for <xen-devel@lists.xenproject.org>;
	Thu, 04 Dec 2014 03:01: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
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=QzNqTj4qs62gpCv/LRZFoOWfwfdecJNJ0lUy4dGxob8=;
	b=FDXsaomVp6L9h29pqQzq48SkqIT1Z1a4AL2MNWsOFPdbHb4g0+07O3ypyDh7Za/BRF
	YxNxL+bnMSN/t/cF+3ISqDIJ8QD5vQBfSGtr7pniezi0HAf0QgbjQ4lGRIOqihc7d4LT
	iLOxpaGcjNaAnldqcZLefdbDaA2Q3hfmD4I/bEpauOvkW2Zx37lrVv+mEvV43sTdyrKl
	YZyPedvItnvwxirYeGNXO9vkUsn+Baj6V+NPJisTRUO+yvJvYCCCZO0kor6Mgr4ikRf1
	B93vjgYktst4fD1ALVb6uYQ72zuWBNgjlOsW6cmHjbqaQm3saFVa98YNvLnU60p1iRHh
	FL9w==
X-Gm-Message-State: ALoCoQlAhgrU7Z3yXjMSpFkpGCyXoIbgqs5tP/o1C9UOuWCv3kDiqrfyT+5yRGD9yz8/Z4/P6Pnm
X-Received: by 10.180.73.206 with SMTP id n14mr20746794wiv.60.1417690862780;
	Thu, 04 Dec 2014 03:01:02 -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
	bc1sm54475418wib.16.2014.12.04.03.01.01 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 04 Dec 2014 03:01:02 -0800 (PST)
Message-ID: <54803EEC.5040404@linaro.org>
Date: Thu, 04 Dec 2014 11:01:00 +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.3.0
MIME-Version: 1.0
To: Vitaly Kuznetsov <vkuznets@redhat.com>, 
 xen-devel@lists.xenproject.org
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1417626981-8432-5-git-send-email-vkuznets@redhat.com>
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/2014 17:16, Vitaly Kuznetsov wrote:
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index a42d0b8..552e4a3 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -366,6 +366,8 @@ struct domain
>       bool_t           is_privileged;
>       /* Which guest this guest has privileges on */
>       struct domain   *target;
> +    /* Which guest receives freed memory pages */

It took me a while to understand that the recipient domain is a newly 
created domain, right? It might be worth to add a word here (and maybe 
in assign_pages).

With that in mind, the code in assign_pages makes more sense.

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 Dec 04 11:08:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11:08:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwUGr-0006Cd-2G; Thu, 04 Dec 2014 11:08:29 +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 1XwUGp-0006CY-Np
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 11:08:27 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	ED/6A-02697-BA040845; Thu, 04 Dec 2014 11:08:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417691303!6209352!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 21433 invoked from network); 4 Dec 2014 11:08:25 -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;
	4 Dec 2014 11:08:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199640142"
Message-ID: <5480407F.7070402@citrix.com>
Date: Thu, 4 Dec 2014 11:07:43 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, <bhelgaas@google.com>,
	<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xenproject.org>, <boris.ostrovsky@oracle.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
	<1417642834-20350-9-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1417642834-20350-9-git-send-email-konrad.wilk@oracle.com>
X-DLP: MIA2
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v5 8/9] 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 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
> From: Jan Beulich <JBeulich@suse.com>
> 
> 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]
> [v3: Redid it a bit differently]

Jan, are you happy with Konrad's change now?

David

> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -1518,6 +1518,53 @@ parse_error:
>  fs_initcall(pcistub_init);
>  #endif
>  
> +#ifdef CONFIG_PCI_IOV
> +static struct pcistub_device *find_vfs(const struct pci_dev *pdev)
> +{
> +	struct pcistub_device *psdev = NULL;
> +	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)
> +		return psdev;
> +	return NULL;
> +}
> +
> +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);
> +
> +	if (action != BUS_NOTIFY_UNBIND_DRIVER)
> +		return NOTIFY_DONE;
> +
> +	if (!pdev->is_physfn)
> +		return NOTIFY_DONE;
> +
> +	for (;;) {
> +		struct pcistub_device *psdev = find_vfs(pdev);
> +		if (!psdev)
> +			break;
> +		device_release_driver(&psdev->dev->dev);
> +	}
> +	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;
> @@ -1539,12 +1586,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 Dec 04 11:08:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11:08:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwUGr-0006Cd-2G; Thu, 04 Dec 2014 11:08:29 +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 1XwUGp-0006CY-Np
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 11:08:27 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	ED/6A-02697-BA040845; Thu, 04 Dec 2014 11:08:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417691303!6209352!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 21433 invoked from network); 4 Dec 2014 11:08:25 -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;
	4 Dec 2014 11:08:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="199640142"
Message-ID: <5480407F.7070402@citrix.com>
Date: Thu, 4 Dec 2014 11:07:43 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, <bhelgaas@google.com>,
	<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xenproject.org>, <boris.ostrovsky@oracle.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
	<1417642834-20350-9-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1417642834-20350-9-git-send-email-konrad.wilk@oracle.com>
X-DLP: MIA2
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v5 8/9] 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 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
> From: Jan Beulich <JBeulich@suse.com>
> 
> 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]
> [v3: Redid it a bit differently]

Jan, are you happy with Konrad's change now?

David

> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -1518,6 +1518,53 @@ parse_error:
>  fs_initcall(pcistub_init);
>  #endif
>  
> +#ifdef CONFIG_PCI_IOV
> +static struct pcistub_device *find_vfs(const struct pci_dev *pdev)
> +{
> +	struct pcistub_device *psdev = NULL;
> +	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)
> +		return psdev;
> +	return NULL;
> +}
> +
> +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);
> +
> +	if (action != BUS_NOTIFY_UNBIND_DRIVER)
> +		return NOTIFY_DONE;
> +
> +	if (!pdev->is_physfn)
> +		return NOTIFY_DONE;
> +
> +	for (;;) {
> +		struct pcistub_device *psdev = find_vfs(pdev);
> +		if (!psdev)
> +			break;
> +		device_release_driver(&psdev->dev->dev);
> +	}
> +	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;
> @@ -1539,12 +1586,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 Dec 04 11:13:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11: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 1XwULZ-0006Tr-V3; Thu, 04 Dec 2014 11:13:21 +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 1XwULX-0006Tm-VZ
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 11:13:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	08/C2-25276-FC140845; Thu, 04 Dec 2014 11:13:19 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417691597!13376119!1
X-Originating-IP: [66.165.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 8436 invoked from network); 4 Dec 2014 11:13:18 -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;
	4 Dec 2014 11:13:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="200000549"
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, 4 Dec 2014 06:13:16 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XwULU-0001of-IS;
	Thu, 04 Dec 2014 11:13:16 +0000
Message-ID: <548041A6.2030004@eu.citrix.com>
Date: Thu, 4 Dec 2014 11:12:38 +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: David Vrabel <david.vrabel@citrix.com>, Andrew Cooper
	<andrew.cooper3@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>	<5477445E.4040803@citrix.com>
	<547F584E.2090003@tycho.nsa.gov> <547F5998.6060904@citrix.com>
	<54803986.4030208@citrix.com>
In-Reply-To: <54803986.4030208@citrix.com>
X-DLP: MIA2
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 12/04/2014 10:37 AM, David Vrabel wrote:
> On 03/12/14 18:42, Andrew Cooper wrote:
>>
>> XSA-37 was only an XSA because the rules at the time were unclear as
>> whether it was an issue or not.  At the same time, the rules were
>> clarified to state that issues in a debug build only are not security
>> issues.
> 
> Given that we occasionally ask our customers to run debug versions of
> Xen to diagnose particular problems I think this policy should change
> (if not by the Xen project security team, then at least internally).

Well given that debug builds *already*, by design, crash on a lot of
things that don't crash in production, then you are already increasing
their risk of a host crash just by giving them that build.  If
increasing the risk of a host crash isn't acceptable, then you should
stop giving them debug builds.

Alternately, maybe we can add an option either at compile time or at
boot time for ASSERTs not to crash for your situation.

But the fact that we have ASSERTs at all mean that we *expect* debug
builds to crash.  If that's not what we want we need to get rid of the
ASSERTs entirely.

 -George

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:13:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11: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 1XwULZ-0006Tr-V3; Thu, 04 Dec 2014 11:13:21 +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 1XwULX-0006Tm-VZ
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 11:13:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	08/C2-25276-FC140845; Thu, 04 Dec 2014 11:13:19 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417691597!13376119!1
X-Originating-IP: [66.165.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 8436 invoked from network); 4 Dec 2014 11:13:18 -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;
	4 Dec 2014 11:13:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,514,1413244800"; d="scan'208";a="200000549"
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, 4 Dec 2014 06:13:16 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1XwULU-0001of-IS;
	Thu, 04 Dec 2014 11:13:16 +0000
Message-ID: <548041A6.2030004@eu.citrix.com>
Date: Thu, 4 Dec 2014 11:12:38 +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: David Vrabel <david.vrabel@citrix.com>, Andrew Cooper
	<andrew.cooper3@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>	<5477445E.4040803@citrix.com>
	<547F584E.2090003@tycho.nsa.gov> <547F5998.6060904@citrix.com>
	<54803986.4030208@citrix.com>
In-Reply-To: <54803986.4030208@citrix.com>
X-DLP: MIA2
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 12/04/2014 10:37 AM, David Vrabel wrote:
> On 03/12/14 18:42, Andrew Cooper wrote:
>>
>> XSA-37 was only an XSA because the rules at the time were unclear as
>> whether it was an issue or not.  At the same time, the rules were
>> clarified to state that issues in a debug build only are not security
>> issues.
> 
> Given that we occasionally ask our customers to run debug versions of
> Xen to diagnose particular problems I think this policy should change
> (if not by the Xen project security team, then at least internally).

Well given that debug builds *already*, by design, crash on a lot of
things that don't crash in production, then you are already increasing
their risk of a host crash just by giving them that build.  If
increasing the risk of a host crash isn't acceptable, then you should
stop giving them debug builds.

Alternately, maybe we can add an option either at compile time or at
boot time for ASSERTs not to crash for your situation.

But the fact that we have ASSERTs at all mean that we *expect* debug
builds to crash.  If that's not what we want we need to get rid of the
ASSERTs entirely.

 -George

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11: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 1XwUPa-0006dd-KN; Thu, 04 Dec 2014 11:17:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XwUPY-0006dW-4b
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 11:17:29 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	F6/4E-22819-7C240845; Thu, 04 Dec 2014 11:17:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417691845!11494892!1
X-Originating-IP: [81.169.146.217]
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 30165 invoked from network); 4 Dec 2014 11:17:25 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 11:17:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417691845; l=666;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=xMQ6Lxy5vrsUjreY9guHpATN5IU=;
	b=up0IMIlJWErQxsYOurXk5OZu7643cUPtOMO2ba/jD6+2GvYD3T7X45kQcNLWsLydIQR
	4AY8UVUCXrtVwpvBTrFtNkP/x4hUepuZei50EO1899c5H0Dw+zfxQxXNGtozUVBkm1a+B
	2I7V6Viwe3ZYhrnJjqZNPigVAH1h3NrHrbk=
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.2 AUTH) with ESMTPSA id g05f4eqB4BHGCf2
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 4 Dec 2014 12:17:16 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id B5F3C5015A; Thu,  4 Dec 2014 12:17:15 +0100 (CET)
Date: Thu, 4 Dec 2014 12:17:15 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141204111715.GA15916@aepfle.de>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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 Wed, Dec 03, Vitaly Kuznetsov wrote:

> 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:

Its not clear to me how thew old kernel starts the new kernel.
How and where is that done?

Olaf

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:17:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11: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 1XwUPa-0006dd-KN; Thu, 04 Dec 2014 11:17:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XwUPY-0006dW-4b
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 11:17:29 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	F6/4E-22819-7C240845; Thu, 04 Dec 2014 11:17:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417691845!11494892!1
X-Originating-IP: [81.169.146.217]
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 30165 invoked from network); 4 Dec 2014 11:17:25 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 11:17:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417691845; l=666;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=xMQ6Lxy5vrsUjreY9guHpATN5IU=;
	b=up0IMIlJWErQxsYOurXk5OZu7643cUPtOMO2ba/jD6+2GvYD3T7X45kQcNLWsLydIQR
	4AY8UVUCXrtVwpvBTrFtNkP/x4hUepuZei50EO1899c5H0Dw+zfxQxXNGtozUVBkm1a+B
	2I7V6Viwe3ZYhrnJjqZNPigVAH1h3NrHrbk=
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.2 AUTH) with ESMTPSA id g05f4eqB4BHGCf2
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 4 Dec 2014 12:17:16 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id B5F3C5015A; Thu,  4 Dec 2014 12:17:15 +0100 (CET)
Date: Thu, 4 Dec 2014 12:17:15 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141204111715.GA15916@aepfle.de>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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 Wed, Dec 03, Vitaly Kuznetsov wrote:

> 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:

Its not clear to me how thew old kernel starts the new kernel.
How and where is that done?

Olaf

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:24:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11:24:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwUWD-0006vr-GR; Thu, 04 Dec 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 <david.vrabel@citrix.com>) id 1XwUWC-0006vm-1G
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 11:24:20 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	4B/07-01660-36440845; Thu, 04 Dec 2014 11:24:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417692257!11526431!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3302 invoked from network); 4 Dec 2014 11:24:18 -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;
	4 Dec 2014 11:24:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200008283"
Message-ID: <5480445F.10407@citrix.com>
Date: Thu, 4 Dec 2014 11:24:15 +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: George Dunlap <george.dunlap@eu.citrix.com>, David Vrabel
	<david.vrabel@citrix.com>, Andrew Cooper <andrew.cooper3@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>	<5477445E.4040803@citrix.com>	<547F584E.2090003@tycho.nsa.gov>
	<547F5998.6060904@citrix.com>	<54803986.4030208@citrix.com>
	<548041A6.2030004@eu.citrix.com>
In-Reply-To: <548041A6.2030004@eu.citrix.com>
X-DLP: MIA2
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 04/12/14 11:12, George Dunlap wrote:
> On 12/04/2014 10:37 AM, David Vrabel wrote:
>> On 03/12/14 18:42, Andrew Cooper wrote:
>>>
>>> XSA-37 was only an XSA because the rules at the time were unclear as
>>> whether it was an issue or not.  At the same time, the rules were
>>> clarified to state that issues in a debug build only are not security
>>> issues.
>>
>> Given that we occasionally ask our customers to run debug versions of
>> Xen to diagnose particular problems I think this policy should change
>> (if not by the Xen project security team, then at least internally).
> 
> Well given that debug builds *already*, by design, crash on a lot of
> things that don't crash in production, then you are already increasing
> their risk of a host crash just by giving them that build.  If
> increasing the risk of a host crash isn't acceptable, then you should
> stop giving them debug builds.

I disagree.  ASSERTs will cause Xen to fail more /predictably/.  A bug
that would trigger an ASSERT will most likely cause a less predictable
failure later on in a non-debug Xen.

> Alternately, maybe we can add an option either at compile time or at
> boot time for ASSERTs not to crash for your situation.

Making ASSERT not crash doesn't help (see above).

> But the fact that we have ASSERTs at all mean that we *expect* debug
> builds to crash.  If that's not what we want we need to get rid of the
> ASSERTs entirely.

????

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:24:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11:24:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwUWD-0006vr-GR; Thu, 04 Dec 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 <david.vrabel@citrix.com>) id 1XwUWC-0006vm-1G
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 11:24:20 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	4B/07-01660-36440845; Thu, 04 Dec 2014 11:24:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417692257!11526431!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3302 invoked from network); 4 Dec 2014 11:24:18 -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;
	4 Dec 2014 11:24:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200008283"
Message-ID: <5480445F.10407@citrix.com>
Date: Thu, 4 Dec 2014 11:24:15 +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: George Dunlap <george.dunlap@eu.citrix.com>, David Vrabel
	<david.vrabel@citrix.com>, Andrew Cooper <andrew.cooper3@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>	<5477445E.4040803@citrix.com>	<547F584E.2090003@tycho.nsa.gov>
	<547F5998.6060904@citrix.com>	<54803986.4030208@citrix.com>
	<548041A6.2030004@eu.citrix.com>
In-Reply-To: <548041A6.2030004@eu.citrix.com>
X-DLP: MIA2
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 04/12/14 11:12, George Dunlap wrote:
> On 12/04/2014 10:37 AM, David Vrabel wrote:
>> On 03/12/14 18:42, Andrew Cooper wrote:
>>>
>>> XSA-37 was only an XSA because the rules at the time were unclear as
>>> whether it was an issue or not.  At the same time, the rules were
>>> clarified to state that issues in a debug build only are not security
>>> issues.
>>
>> Given that we occasionally ask our customers to run debug versions of
>> Xen to diagnose particular problems I think this policy should change
>> (if not by the Xen project security team, then at least internally).
> 
> Well given that debug builds *already*, by design, crash on a lot of
> things that don't crash in production, then you are already increasing
> their risk of a host crash just by giving them that build.  If
> increasing the risk of a host crash isn't acceptable, then you should
> stop giving them debug builds.

I disagree.  ASSERTs will cause Xen to fail more /predictably/.  A bug
that would trigger an ASSERT will most likely cause a less predictable
failure later on in a non-debug Xen.

> Alternately, maybe we can add an option either at compile time or at
> boot time for ASSERTs not to crash for your situation.

Making ASSERT not crash doesn't help (see above).

> But the fact that we have ASSERTs at all mean that we *expect* debug
> builds to crash.  If that's not what we want we need to get rid of the
> ASSERTs entirely.

????

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:25:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1XwUWt-0006yX-Uv; Thu, 04 Dec 2014 11:25: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 1XwUWs-0006yP-SQ
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 11:25:02 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	5C/9F-28865-E8440845; Thu, 04 Dec 2014 11:25:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417692299!11506545!1
X-Originating-IP: [66.165.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 3971 invoked from network); 4 Dec 2014 11:25:01 -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;
	4 Dec 2014 11:25:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199652818"
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, 4 Dec 2014 06:24: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 1XwUWo-00026B-HZ;
	Thu, 04 Dec 2014 11:24:58 +0000
Date: Thu, 4 Dec 2014 11:24:58 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141204112458.GB16532@zion.uk.xensource.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417556050-23364-3-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, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, keir@xen.org, ufimtseva@gmail.com
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 Tue, Dec 02, 2014 at 04:34:08PM -0500, Boris Ostrovsky wrote:
[...]
>  void libxl_cputopology_list_free(libxl_cputopology *, int nb_cpu);
>  
> +#define LIBXL_TOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
> +libxl_topology *libxl_get_topology(libxl_ctx *ctx);
> +void libxl_topology_free(libxl_topology *);
> +
>  #define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
>  libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
>  void libxl_numainfo_list_free(libxl_numainfo *, int nr);
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index f7fc695..673b273 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -642,6 +642,18 @@ libxl_cputopology = Struct("cputopology", [
>      ("node", uint32),
>      ], dir=DIR_OUT)
>  
> +libxl_iotopology = Struct("iotopology", [
> +    ("seg", uint16),
> +    ("bus", uint8),
> +    ("devfn", uint8),
> +    ("node", uint32),
> +    ], dir=DIR_OUT)
> +
> +libxl_topology = Struct("topology", [
> +    ("cpu", Array(libxl_cputopology, "cpu_num")),
> +    ("dev", Array(libxl_iotopology, "dev_num")),
> +    ], dir=DIR_OUT)

Use "num_cpu" and "num_dev" please.

I think you also need to add a LIBXL_HAVE_$FOO in libxl.h. 

Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:25:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1XwUWt-0006yX-Uv; Thu, 04 Dec 2014 11:25: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 1XwUWs-0006yP-SQ
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 11:25:02 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	5C/9F-28865-E8440845; Thu, 04 Dec 2014 11:25:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417692299!11506545!1
X-Originating-IP: [66.165.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 3971 invoked from network); 4 Dec 2014 11:25:01 -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;
	4 Dec 2014 11:25:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199652818"
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, 4 Dec 2014 06:24: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 1XwUWo-00026B-HZ;
	Thu, 04 Dec 2014 11:24:58 +0000
Date: Thu, 4 Dec 2014 11:24:58 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141204112458.GB16532@zion.uk.xensource.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417556050-23364-3-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, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, keir@xen.org, ufimtseva@gmail.com
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 Tue, Dec 02, 2014 at 04:34:08PM -0500, Boris Ostrovsky wrote:
[...]
>  void libxl_cputopology_list_free(libxl_cputopology *, int nb_cpu);
>  
> +#define LIBXL_TOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
> +libxl_topology *libxl_get_topology(libxl_ctx *ctx);
> +void libxl_topology_free(libxl_topology *);
> +
>  #define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
>  libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
>  void libxl_numainfo_list_free(libxl_numainfo *, int nr);
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index f7fc695..673b273 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -642,6 +642,18 @@ libxl_cputopology = Struct("cputopology", [
>      ("node", uint32),
>      ], dir=DIR_OUT)
>  
> +libxl_iotopology = Struct("iotopology", [
> +    ("seg", uint16),
> +    ("bus", uint8),
> +    ("devfn", uint8),
> +    ("node", uint32),
> +    ], dir=DIR_OUT)
> +
> +libxl_topology = Struct("topology", [
> +    ("cpu", Array(libxl_cputopology, "cpu_num")),
> +    ("dev", Array(libxl_iotopology, "dev_num")),
> +    ], dir=DIR_OUT)

Use "num_cpu" and "num_dev" please.

I think you also need to add a LIBXL_HAVE_$FOO in libxl.h. 

Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:30:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwUbz-0007CH-Nb; Thu, 04 Dec 2014 11:30:19 +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 1XwUbz-0007CC-AO
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 11:30:19 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C5/B3-02696-AC540845; Thu, 04 Dec 2014 11:30:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417692616!12936222!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 823 invoked from network); 4 Dec 2014 11:30:18 -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 Dec 2014 11:30:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199656654"
Message-ID: <548045C6.2040104@citrix.com>
Date: Thu, 4 Dec 2014 11:30:14 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, <bhelgaas@google.com>,
	<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xenproject.org>, <boris.ostrovsky@oracle.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
	<1417642834-20350-10-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1417642834-20350-10-git-send-email-konrad.wilk@oracle.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 21:40, Konrad Rzeszutek Wilk wrote:
> 
> Instead of doing all this complex dance, we depend on the toolstack
> doing the right thing. As such implement the 'do_flr' SysFS attribute
> which 'xl' uses when a device is detached or attached from/to a guest.
> It bypasses the need to worry about the PCI lock.

No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly
proposed).

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:30:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwUbz-0007CH-Nb; Thu, 04 Dec 2014 11:30:19 +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 1XwUbz-0007CC-AO
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 11:30:19 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C5/B3-02696-AC540845; Thu, 04 Dec 2014 11:30:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417692616!12936222!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 823 invoked from network); 4 Dec 2014 11:30:18 -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 Dec 2014 11:30:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199656654"
Message-ID: <548045C6.2040104@citrix.com>
Date: Thu, 4 Dec 2014 11:30:14 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, <bhelgaas@google.com>,
	<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xenproject.org>, <boris.ostrovsky@oracle.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
	<1417642834-20350-10-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1417642834-20350-10-git-send-email-konrad.wilk@oracle.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 21:40, Konrad Rzeszutek Wilk wrote:
> 
> Instead of doing all this complex dance, we depend on the toolstack
> doing the right thing. As such implement the 'do_flr' SysFS attribute
> which 'xl' uses when a device is detached or attached from/to a guest.
> It bypasses the need to worry about the PCI lock.

No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly
proposed).

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:36:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11: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 1XwUi5-0007UC-8a; Thu, 04 Dec 2014 11:36:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwUi3-0007U7-V8
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 11:36:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8D/3E-09842-34740845; Thu, 04 Dec 2014 11:36:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417692994!13385345!1
X-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 24708 invoked from network); 4 Dec 2014 11:36:34 -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 Dec 2014 11:36:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 11:36:34 +0000
Message-Id: <54805552020000780004CAD4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 11:36:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
	<1417642834-20350-9-git-send-email-konrad.wilk@oracle.com>
	<5480407F.7070402@citrix.com>
In-Reply-To: <5480407F.7070402@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v5 8/9] 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 04.12.14 at 12:07, <david.vrabel@citrix.com> wrote:
> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
>> From: Jan Beulich <JBeulich@suse.com>
>> 
>> 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]
>> [v3: Redid it a bit differently]
> 
> Jan, are you happy with Konrad's change now?

Yes: http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00267.html

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:36:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11: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 1XwUi5-0007UC-8a; Thu, 04 Dec 2014 11:36:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwUi3-0007U7-V8
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 11:36:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8D/3E-09842-34740845; Thu, 04 Dec 2014 11:36:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417692994!13385345!1
X-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 24708 invoked from network); 4 Dec 2014 11:36:34 -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 Dec 2014 11:36:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 11:36:34 +0000
Message-Id: <54805552020000780004CAD4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 11:36:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
	<1417642834-20350-9-git-send-email-konrad.wilk@oracle.com>
	<5480407F.7070402@citrix.com>
In-Reply-To: <5480407F.7070402@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v5 8/9] 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 04.12.14 at 12:07, <david.vrabel@citrix.com> wrote:
> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
>> From: Jan Beulich <JBeulich@suse.com>
>> 
>> 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]
>> [v3: Redid it a bit differently]
> 
> Jan, are you happy with Konrad's change now?

Yes: http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00267.html

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:55:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwV0A-0008CV-I9; Thu, 04 Dec 2014 11:55:18 +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 1XwV09-0008CQ-C0
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 11:55:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B4/2D-15461-4AB40845; Thu, 04 Dec 2014 11:55:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417694113!13039497!1
X-Originating-IP: [66.165.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 13118 invoked from network); 4 Dec 2014 11:55:14 -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 Dec 2014 11:55:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199670899"
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, 4 Dec 2014 06:55: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 1XwV04-0002uZ-DS;
	Thu, 04 Dec 2014 11:55:12 +0000
Date: Thu, 4 Dec 2014 11:55:12 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141204115512.GC16532@zion.uk.xensource.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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 Wed, Dec 03, 2014 at 06:16:12PM +0100, Vitaly Kuznetsov wrote:
> Changes from RFCv3:
> This is the first non-RFC series as no major concerns were expressed. I'm trying
> to address Jan's comments. Changes are:
> - Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really like
>   the name but nothing more appropriate came to my mind) which incorporates
>   former XEN_DOMCTL_set_recipient and XEN_DOMCTL_destroydomain to prevent
>   original domain from changing its allocations during transfer procedure.
> - Check in free_domheap_pages() that assign_pages() succeeded.
> - Change printk() in free_domheap_pages().
> - DOMDYING_locked state was introduced to support XEN_DOMCTL_devour.
> - xc_domain_soft_reset() got simplified a bit. Now we just wait for the original
>   domain to die or loose all its pages.
> - rebased on top of current master branch.
> 
> 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.
> 

What would happen if you soft reset a PV guest? At the very least soft
reset should be explicitly forbidden in PV case.

> 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
> - ...

Is there a complete list?

> 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.
> 

As this approach requires toolstack do complex interaction with
hypervisor and preserve / throw away a bunch of states. I think the
whole procedure should be documented.

It would also be helpful if you link to previous discussions in your
cover letter.

Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:55:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwV0A-0008CV-I9; Thu, 04 Dec 2014 11:55:18 +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 1XwV09-0008CQ-C0
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 11:55:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B4/2D-15461-4AB40845; Thu, 04 Dec 2014 11:55:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417694113!13039497!1
X-Originating-IP: [66.165.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 13118 invoked from network); 4 Dec 2014 11:55:14 -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 Dec 2014 11:55:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199670899"
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, 4 Dec 2014 06:55: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 1XwV04-0002uZ-DS;
	Thu, 04 Dec 2014 11:55:12 +0000
Date: Thu, 4 Dec 2014 11:55:12 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141204115512.GC16532@zion.uk.xensource.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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 Wed, Dec 03, 2014 at 06:16:12PM +0100, Vitaly Kuznetsov wrote:
> Changes from RFCv3:
> This is the first non-RFC series as no major concerns were expressed. I'm trying
> to address Jan's comments. Changes are:
> - Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really like
>   the name but nothing more appropriate came to my mind) which incorporates
>   former XEN_DOMCTL_set_recipient and XEN_DOMCTL_destroydomain to prevent
>   original domain from changing its allocations during transfer procedure.
> - Check in free_domheap_pages() that assign_pages() succeeded.
> - Change printk() in free_domheap_pages().
> - DOMDYING_locked state was introduced to support XEN_DOMCTL_devour.
> - xc_domain_soft_reset() got simplified a bit. Now we just wait for the original
>   domain to die or loose all its pages.
> - rebased on top of current master branch.
> 
> 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.
> 

What would happen if you soft reset a PV guest? At the very least soft
reset should be explicitly forbidden in PV case.

> 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
> - ...

Is there a complete list?

> 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.
> 

As this approach requires toolstack do complex interaction with
hypervisor and preserve / throw away a bunch of states. I think the
whole procedure should be documented.

It would also be helpful if you link to previous discussions in your
cover letter.

Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 11:55:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11:55:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwV0g-0008EY-Ux; Thu, 04 Dec 2014 11:55: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 1XwV0e-0008EI-VM
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 11:55:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8F/BA-09842-4CB40845; Thu, 04 Dec 2014 11:55:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417694143!5352160!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8134 invoked from network); 4 Dec 2014 11:55:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 11:55:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200025489"
Message-ID: <1417694140.22808.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 4 Dec 2014 11:55:40 +0000
In-Reply-To: <1417603870.11243.10.camel@citrix.com>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
	<1417602539.11243.4.camel@citrix.com>
	<20141203104912.GA30431@aepfle.de>
	<1417603870.11243.10.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>, "Luis R.
	Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-03 at 10:51 +0000, Ian Campbell wrote:
> On Wed, 2014-12-03 at 11:49 +0100, Olaf Hering wrote:
> > On Wed, Dec 03, Ian Campbell wrote:
> > 
> > > Ah I didn't know about the sd_listen_fds thing, so I think that what we
> > > need then is to use pkg-config first to determine if systemd-daemon is
> > > present at all, and then check for specific symbols we require using the
> > > pkg-config supplied CFLAGS and LDFLAGS rather than assuming
> > > -lsystemd-daemon.
> > 
> > Correction: sd_listen_fds is available since at least v1.
> >  git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d
> >  v1~390
> 
> In that case I don't think we realistically need to check for it?

The implication here being that Wei's original patch is correct. Konrad,
do you think this is OK for the release?

> 
> 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 Dec 04 11:55:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11:55:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwV0g-0008EY-Ux; Thu, 04 Dec 2014 11:55: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 1XwV0e-0008EI-VM
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 11:55:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8F/BA-09842-4CB40845; Thu, 04 Dec 2014 11:55:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417694143!5352160!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8134 invoked from network); 4 Dec 2014 11:55:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 11:55:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200025489"
Message-ID: <1417694140.22808.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 4 Dec 2014 11:55:40 +0000
In-Reply-To: <1417603870.11243.10.camel@citrix.com>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141202183755.GF32385@laptop.dumpdata.com>
	<20141203102636.GA29307@aepfle.de>
	<1417602539.11243.4.camel@citrix.com>
	<20141203104912.GA30431@aepfle.de>
	<1417603870.11243.10.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>, "Luis R.
	Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	m.a.young@durham.ac.uk, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-03 at 10:51 +0000, Ian Campbell wrote:
> On Wed, 2014-12-03 at 11:49 +0100, Olaf Hering wrote:
> > On Wed, Dec 03, Ian Campbell wrote:
> > 
> > > Ah I didn't know about the sd_listen_fds thing, so I think that what we
> > > need then is to use pkg-config first to determine if systemd-daemon is
> > > present at all, and then check for specific symbols we require using the
> > > pkg-config supplied CFLAGS and LDFLAGS rather than assuming
> > > -lsystemd-daemon.
> > 
> > Correction: sd_listen_fds is available since at least v1.
> >  git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d
> >  v1~390
> 
> In that case I don't think we realistically need to check for it?

The implication here being that Wei's original patch is correct. Konrad,
do you think this is OK for the release?

> 
> 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 Dec 04 11:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11: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 1XwV0z-0008IX-2g; Thu, 04 Dec 2014 11:56:09 +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 1XwV0x-0008I4-DP
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 11:56:07 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	5A/A3-29352-6DB40845; Thu, 04 Dec 2014 11:56:06 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417694156!6224121!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: YXN5bmNfZGVsYXk6IDcwNjk1MTUgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1886 invoked from network); 4 Dec 2014 11:55:57 -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;
	4 Dec 2014 11:55:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; 
	d="asc'?scan'208";a="200025567"
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, 4 Dec 2014
	06:55:55 -0500
Message-ID: <1417694153.31647.32.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Thu, 4 Dec 2014 12:55:53 +0100
In-Reply-To: <1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-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, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, jbeulich@suse.com, keir@xen.org,
	ufimtseva@gmail.com
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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="===============4880993259704416736=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
> Make XEN_SYSCTL_topologyinfo more generic so that it can return both
> CPU and IO topology (support for returning the latter is added in the
> subsequent patch)
>=20
Is it always the case that we need the full information (i.e., both CPU
and IO topology), at all levels above Xen?

I appreciate the performance implications (one hcall instead of two) in
cases where we do, but I still think, as Andrew suggested, that having a
new XEN_SYSCTL_iotopology (or something like that) and leaving
*_topologyinfo alone would make a better low-level interface.

All IMHO, of course.

> To do so move (and rename) previously used cpu_to_core/cpu_to_socket/
> cpu_to_node into struct xen_sysctl_cputopo and move it, together with
> newly added struct xen_sysctl_iotopo, to xen_sysctl_topologyinfo.
>=20
> Add libxl_get_topology() to handle new interface and modify
> libxl_get_cpu_topology() to be a wrapper around it.
>=20
This is, I think, useful, and I'd go for it, even if we adding a new
hypercall at the Xen and xc level.

Of course, it would work the other way round: the new libxl function
would wrap the existing libxl_get_cpu_topology() and a new libxl call
(something like libxl_get_io_topology() ?).

> Adjust xenpm and python's low-level C libraries for new interface.
>=20
All in one patch? Wouldn't splitting it at least in two (hypervisor and
tools parts) be better? If it were me, I'd probably split even more...

> This change requires bumping XEN_SYSCTL_INTERFACE_VERSION
>
Which would not be the case if we take the approach of adding a new,
iotopology specific, hcall, would 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)


--=-jgGip5BffGeypJhUNu3O
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

iEYEABECAAYFAlSAS8kACgkQk4XaBE3IOsR4DQCgijaZ7G5o35XKBvnkHqhlqOKT
oeMAoI7O+Fe8C78oosEmxzxZ2jsOIhsu
=4L4S
-----END PGP SIGNATURE-----

--=-jgGip5BffGeypJhUNu3O--


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

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

--===============4880993259704416736==--


From xen-devel-bounces@lists.xen.org Thu Dec 04 11:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 11: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 1XwV0z-0008IX-2g; Thu, 04 Dec 2014 11:56:09 +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 1XwV0x-0008I4-DP
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 11:56:07 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	5A/A3-29352-6DB40845; Thu, 04 Dec 2014 11:56:06 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417694156!6224121!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: YXN5bmNfZGVsYXk6IDcwNjk1MTUgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1886 invoked from network); 4 Dec 2014 11:55:57 -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;
	4 Dec 2014 11:55:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; 
	d="asc'?scan'208";a="200025567"
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, 4 Dec 2014
	06:55:55 -0500
Message-ID: <1417694153.31647.32.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Thu, 4 Dec 2014 12:55:53 +0100
In-Reply-To: <1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-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, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, jbeulich@suse.com, keir@xen.org,
	ufimtseva@gmail.com
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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="===============4880993259704416736=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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

On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
> Make XEN_SYSCTL_topologyinfo more generic so that it can return both
> CPU and IO topology (support for returning the latter is added in the
> subsequent patch)
>=20
Is it always the case that we need the full information (i.e., both CPU
and IO topology), at all levels above Xen?

I appreciate the performance implications (one hcall instead of two) in
cases where we do, but I still think, as Andrew suggested, that having a
new XEN_SYSCTL_iotopology (or something like that) and leaving
*_topologyinfo alone would make a better low-level interface.

All IMHO, of course.

> To do so move (and rename) previously used cpu_to_core/cpu_to_socket/
> cpu_to_node into struct xen_sysctl_cputopo and move it, together with
> newly added struct xen_sysctl_iotopo, to xen_sysctl_topologyinfo.
>=20
> Add libxl_get_topology() to handle new interface and modify
> libxl_get_cpu_topology() to be a wrapper around it.
>=20
This is, I think, useful, and I'd go for it, even if we adding a new
hypercall at the Xen and xc level.

Of course, it would work the other way round: the new libxl function
would wrap the existing libxl_get_cpu_topology() and a new libxl call
(something like libxl_get_io_topology() ?).

> Adjust xenpm and python's low-level C libraries for new interface.
>=20
All in one patch? Wouldn't splitting it at least in two (hypervisor and
tools parts) be better? If it were me, I'd probably split even more...

> This change requires bumping XEN_SYSCTL_INTERFACE_VERSION
>
Which would not be the case if we take the approach of adding a new,
iotopology specific, hcall, would 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)


--=-jgGip5BffGeypJhUNu3O
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

iEYEABECAAYFAlSAS8kACgkQk4XaBE3IOsR4DQCgijaZ7G5o35XKBvnkHqhlqOKT
oeMAoI7O+Fe8C78oosEmxzxZ2jsOIhsu
=4L4S
-----END PGP SIGNATURE-----

--=-jgGip5BffGeypJhUNu3O--


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

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

--===============4880993259704416736==--


From xen-devel-bounces@lists.xen.org Thu Dec 04 12:03:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12:03:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwV7j-0000PM-KM; Thu, 04 Dec 2014 12:03:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1XwV7h-0000Oz-VA
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 12:03:06 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	A7/9A-20609-97D40845; Thu, 04 Dec 2014 12:03:05 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417694584!12971428!1
X-Originating-IP: [74.125.82.45]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32292 invoked from network); 4 Dec 2014 12:03:04 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 12:03:04 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so22490776wgh.4
	for <xen-devel@lists.xen.org>; Thu, 04 Dec 2014 04:03:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:reply-to:sender:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=cdWcuwO09PRr2EFJjY/tfTBZOeWgZMuB7afajXw9Tdg=;
	b=QPyLJrdDD48Bf3i9ZnPQPw3Hb0tRHyxqikfzbKBWaP41L8yeNFS1pu2VZXN2jDruMW
	HDXez5vIoIKs/od1XFjdkZGgN+NQbPG1p9aQ178ZotxdlZoFGosI5GoVFqPlwsQltgV3
	Mf+RM35LSaDInAHmJN1HsM8/tfMbsvEhAKPaGFfzbviDMCY6LUPtfB9jzarzAb+BioA6
	8PIjpPl7nvVkeC7dmSfDdt77FHXRwvjOHFUacCmwNJOl7c3O6ZvASoywV4BI7DUcA79v
	g4gDn/Fenr4v0IFS+sJ/H+H2VIb2Bry5NWd3+DxQeWeIVDz7+1mHWm8pnUO/0+3ns2F0
	MV3g==
MIME-Version: 1.0
X-Received: by 10.194.95.196 with SMTP id dm4mr15496246wjb.41.1417694583973;
	Thu, 04 Dec 2014 04:03:03 -0800 (PST)
Received: by 10.180.188.138 with HTTP; Thu, 4 Dec 2014 04:03:03 -0800 (PST)
Received: by 10.180.188.138 with HTTP; Thu, 4 Dec 2014 04:03:03 -0800 (PST)
In-Reply-To: <1417685334.22808.1.camel@citrix.com>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
	<20141204013102.GA31385@andromeda.dapyr.net>
	<1417685334.22808.1.camel@citrix.com>
Date: Thu, 4 Dec 2014 07:03:03 -0500
X-Google-Sender-Auth: tzFnojS22iDNXEkYbXG9cP9kmZU
Message-ID: <CAPbh3rsxQVe134BGz5JL5hEnt8qOW=J3xmzQqiWtKJ_UZsjnCg@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: konrad@darnok.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3328040774529802736=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3328040774529802736==
Content-Type: multipart/alternative; boundary=047d7bb709ce13ec01050962bed1

--047d7bb709ce13ec01050962bed1
Content-Type: text/plain; charset=UTF-8

On Dec 4, 2014 4:29 AM, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>
> On Wed, 2014-12-03 at 21:31 -0400, Konrad Rzeszutek Wilk wrote:
> > so something is busted as you surmised
>
> I haven't been following closely, so this may be completely unrelated to
> the issue under discussion, but doesn't in-HVM-guest hotplug require a
> guest side driver to be loaded? I recall in the dim and distant past
> having to manually load some sort of foo_hp.ko.
>

The ACPI PCI hotplug machinery does all of that nicely.

As mentioned - it works nicely - except that the BDF that is chosen is at
an wrong slot. In the 'xend' days in recall this working nicely and
sticking the PF at slot 5 and beyond. Though I have no clue how it dealt
with multiple emulated NICs and such.

> Ian.
>

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

<p dir=3D"ltr"><br>
On Dec 4, 2014 4:29 AM, &quot;Ian Campbell&quot; &lt;<a href=3D"mailto:Ian.=
Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wed, 2014-12-03 at 21:31 -0400, Konrad Rzeszutek Wilk wrote:<br>
&gt; &gt; so something is busted as you surmised<br>
&gt;<br>
&gt; I haven&#39;t been following closely, so this may be completely unrela=
ted to<br>
&gt; the issue under discussion, but doesn&#39;t in-HVM-guest hotplug requi=
re a<br>
&gt; guest side driver to be loaded? I recall in the dim and distant past<b=
r>
&gt; having to manually load some sort of foo_hp.ko.<br>
&gt;</p>
<p dir=3D"ltr">The ACPI PCI hotplug machinery does all of that nicely.</p>
<p dir=3D"ltr">As mentioned - it works nicely - except that the BDF that is=
 chosen is at an wrong slot. In the &#39;xend&#39; days in recall this work=
ing nicely and sticking the PF at slot 5 and beyond. Though I have no clue =
how it dealt with multiple emulated NICs and such.<br>
 <br>
&gt; Ian.<br>
&gt;<br>
</p>

--047d7bb709ce13ec01050962bed1--


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

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

--===============3328040774529802736==--


From xen-devel-bounces@lists.xen.org Thu Dec 04 12:03:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12:03:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwV7j-0000PM-KM; Thu, 04 Dec 2014 12:03:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1XwV7h-0000Oz-VA
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 12:03:06 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	A7/9A-20609-97D40845; Thu, 04 Dec 2014 12:03:05 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1417694584!12971428!1
X-Originating-IP: [74.125.82.45]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32292 invoked from network); 4 Dec 2014 12:03:04 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 12:03:04 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so22490776wgh.4
	for <xen-devel@lists.xen.org>; Thu, 04 Dec 2014 04:03:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:reply-to:sender:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=cdWcuwO09PRr2EFJjY/tfTBZOeWgZMuB7afajXw9Tdg=;
	b=QPyLJrdDD48Bf3i9ZnPQPw3Hb0tRHyxqikfzbKBWaP41L8yeNFS1pu2VZXN2jDruMW
	HDXez5vIoIKs/od1XFjdkZGgN+NQbPG1p9aQ178ZotxdlZoFGosI5GoVFqPlwsQltgV3
	Mf+RM35LSaDInAHmJN1HsM8/tfMbsvEhAKPaGFfzbviDMCY6LUPtfB9jzarzAb+BioA6
	8PIjpPl7nvVkeC7dmSfDdt77FHXRwvjOHFUacCmwNJOl7c3O6ZvASoywV4BI7DUcA79v
	g4gDn/Fenr4v0IFS+sJ/H+H2VIb2Bry5NWd3+DxQeWeIVDz7+1mHWm8pnUO/0+3ns2F0
	MV3g==
MIME-Version: 1.0
X-Received: by 10.194.95.196 with SMTP id dm4mr15496246wjb.41.1417694583973;
	Thu, 04 Dec 2014 04:03:03 -0800 (PST)
Received: by 10.180.188.138 with HTTP; Thu, 4 Dec 2014 04:03:03 -0800 (PST)
Received: by 10.180.188.138 with HTTP; Thu, 4 Dec 2014 04:03:03 -0800 (PST)
In-Reply-To: <1417685334.22808.1.camel@citrix.com>
References: <20141201125712.GA21576@aepfle.de>
	<20141201133244.GA24600@aepfle.de>
	<20141201170151.GK3180@laptop.dumpdata.com>
	<20141204013102.GA31385@andromeda.dapyr.net>
	<1417685334.22808.1.camel@citrix.com>
Date: Thu, 4 Dec 2014 07:03:03 -0500
X-Google-Sender-Auth: tzFnojS22iDNXEkYbXG9cP9kmZU
Message-ID: <CAPbh3rsxQVe134BGz5JL5hEnt8qOW=J3xmzQqiWtKJ_UZsjnCg@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xl pci-attach silently fails the first time
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: konrad@darnok.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3328040774529802736=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3328040774529802736==
Content-Type: multipart/alternative; boundary=047d7bb709ce13ec01050962bed1

--047d7bb709ce13ec01050962bed1
Content-Type: text/plain; charset=UTF-8

On Dec 4, 2014 4:29 AM, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>
> On Wed, 2014-12-03 at 21:31 -0400, Konrad Rzeszutek Wilk wrote:
> > so something is busted as you surmised
>
> I haven't been following closely, so this may be completely unrelated to
> the issue under discussion, but doesn't in-HVM-guest hotplug require a
> guest side driver to be loaded? I recall in the dim and distant past
> having to manually load some sort of foo_hp.ko.
>

The ACPI PCI hotplug machinery does all of that nicely.

As mentioned - it works nicely - except that the BDF that is chosen is at
an wrong slot. In the 'xend' days in recall this working nicely and
sticking the PF at slot 5 and beyond. Though I have no clue how it dealt
with multiple emulated NICs and such.

> Ian.
>

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

<p dir=3D"ltr"><br>
On Dec 4, 2014 4:29 AM, &quot;Ian Campbell&quot; &lt;<a href=3D"mailto:Ian.=
Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wed, 2014-12-03 at 21:31 -0400, Konrad Rzeszutek Wilk wrote:<br>
&gt; &gt; so something is busted as you surmised<br>
&gt;<br>
&gt; I haven&#39;t been following closely, so this may be completely unrela=
ted to<br>
&gt; the issue under discussion, but doesn&#39;t in-HVM-guest hotplug requi=
re a<br>
&gt; guest side driver to be loaded? I recall in the dim and distant past<b=
r>
&gt; having to manually load some sort of foo_hp.ko.<br>
&gt;</p>
<p dir=3D"ltr">The ACPI PCI hotplug machinery does all of that nicely.</p>
<p dir=3D"ltr">As mentioned - it works nicely - except that the BDF that is=
 chosen is at an wrong slot. In the &#39;xend&#39; days in recall this work=
ing nicely and sticking the PF at slot 5 and beyond. Though I have no clue =
how it dealt with multiple emulated NICs and such.<br>
 <br>
&gt; Ian.<br>
&gt;<br>
</p>

--047d7bb709ce13ec01050962bed1--


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

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

--===============3328040774529802736==--


From xen-devel-bounces@lists.xen.org Thu Dec 04 12:06:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12:06:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwVBM-0000jG-R7; Thu, 04 Dec 2014 12:06: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 1XwVBL-0000jA-9o
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 12:06:51 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	53/D2-02712-65E40845; Thu, 04 Dec 2014 12:06:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417694804!12881604!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2194 invoked from network); 4 Dec 2014 12:06:45 -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; 4 Dec 2014 12:06: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 sB4C6YLO029137
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 12:06: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
	sB4C6Xid009521
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2014 12:06:34 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
	sB4C6XVQ009497; Thu, 4 Dec 2014 12:06:33 GMT
Message-Id: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
Received: from [IPv6:2607:fb90:290f:2be6:6bc1:8513:2f2:893c] (/172.56.22.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 04 Dec 2014 04:06:32 -0800
Date: Thu, 04 Dec 2014 07:06:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
MIME-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ck9uIERlYyA0LCAyMDE0IDY6MzAgQU0sIERhdmlkIFZyYWJlbCA8ZGF2aWQudnJhYmVsQGNpdHJp
eC5jb20+IHdyb3RlOgo+Cj4gT24gMDMvMTIvMTQgMjE6NDAsIEtvbnJhZCBSemVzenV0ZWsgV2ls
ayB3cm90ZTogCj4gPiAKPiA+IEluc3RlYWQgb2YgZG9pbmcgYWxsIHRoaXMgY29tcGxleCBkYW5j
ZSwgd2UgZGVwZW5kIG9uIHRoZSB0b29sc3RhY2sgCj4gPiBkb2luZyB0aGUgcmlnaHQgdGhpbmcu
IEFzIHN1Y2ggaW1wbGVtZW50IHRoZSAnZG9fZmxyJyBTeXNGUyBhdHRyaWJ1dGUgCj4gPiB3aGlj
aCAneGwnIHVzZXMgd2hlbiBhIGRldmljZSBpcyBkZXRhY2hlZCBvciBhdHRhY2hlZCBmcm9tL3Rv
IGEgZ3Vlc3QuIAo+ID4gSXQgYnlwYXNzZXMgdGhlIG5lZWQgdG8gd29ycnkgYWJvdXQgdGhlIFBD
SSBsb2NrLiAKPgo+IE5vLsKgIEdldCBwY2liYWNrIHRvIGFkZCBpdHMgb3duICJyZXNldCIgc3lz
ZnMgZmlsZSAoYXMgSSBoYXZlIHJlcGVhdGVkbHkgCj4gcHJvcG9zZWQpLiAKPgoKV2hpY2ggZG9l
cyBub3Qgd29yayBhcyB0aGUga29iaiB3aWxsIGNvbXBsYWluIChhcyB0aGVyZSBpcyBhbHJlYWR5
IGFuICdyZXNldCcgYXNzb2NpYXRlZCB3aXRoIHRoZSBQQ0kgZGV2aWNlKS4KClVubGVzcyB5b3Ug
bWVhbiBhbiBkaWZmZXJlbnQgbmFtZSAocmVzZXQyKS4KCj4gRGF2aWQgCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Dec 04 12:06:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12:06:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwVBM-0000jG-R7; Thu, 04 Dec 2014 12:06: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 1XwVBL-0000jA-9o
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 12:06:51 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	53/D2-02712-65E40845; Thu, 04 Dec 2014 12:06:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417694804!12881604!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2194 invoked from network); 4 Dec 2014 12:06:45 -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; 4 Dec 2014 12:06: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 sB4C6YLO029137
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 12:06: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
	sB4C6Xid009521
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2014 12:06:34 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
	sB4C6XVQ009497; Thu, 4 Dec 2014 12:06:33 GMT
Message-Id: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
Received: from [IPv6:2607:fb90:290f:2be6:6bc1:8513:2f2:893c] (/172.56.22.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 04 Dec 2014 04:06:32 -0800
Date: Thu, 04 Dec 2014 07:06:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
MIME-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ck9uIERlYyA0LCAyMDE0IDY6MzAgQU0sIERhdmlkIFZyYWJlbCA8ZGF2aWQudnJhYmVsQGNpdHJp
eC5jb20+IHdyb3RlOgo+Cj4gT24gMDMvMTIvMTQgMjE6NDAsIEtvbnJhZCBSemVzenV0ZWsgV2ls
ayB3cm90ZTogCj4gPiAKPiA+IEluc3RlYWQgb2YgZG9pbmcgYWxsIHRoaXMgY29tcGxleCBkYW5j
ZSwgd2UgZGVwZW5kIG9uIHRoZSB0b29sc3RhY2sgCj4gPiBkb2luZyB0aGUgcmlnaHQgdGhpbmcu
IEFzIHN1Y2ggaW1wbGVtZW50IHRoZSAnZG9fZmxyJyBTeXNGUyBhdHRyaWJ1dGUgCj4gPiB3aGlj
aCAneGwnIHVzZXMgd2hlbiBhIGRldmljZSBpcyBkZXRhY2hlZCBvciBhdHRhY2hlZCBmcm9tL3Rv
IGEgZ3Vlc3QuIAo+ID4gSXQgYnlwYXNzZXMgdGhlIG5lZWQgdG8gd29ycnkgYWJvdXQgdGhlIFBD
SSBsb2NrLiAKPgo+IE5vLsKgIEdldCBwY2liYWNrIHRvIGFkZCBpdHMgb3duICJyZXNldCIgc3lz
ZnMgZmlsZSAoYXMgSSBoYXZlIHJlcGVhdGVkbHkgCj4gcHJvcG9zZWQpLiAKPgoKV2hpY2ggZG9l
cyBub3Qgd29yayBhcyB0aGUga29iaiB3aWxsIGNvbXBsYWluIChhcyB0aGVyZSBpcyBhbHJlYWR5
IGFuICdyZXNldCcgYXNzb2NpYXRlZCB3aXRoIHRoZSBQQ0kgZGV2aWNlKS4KClVubGVzcyB5b3Ug
bWVhbiBhbiBkaWZmZXJlbnQgbmFtZSAocmVzZXQyKS4KCj4gRGF2aWQgCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Dec 04 12:10:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwVEM-0000w9-Dv; Thu, 04 Dec 2014 12:09:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XwVEK-0000w3-BP
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 12:09:56 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	27/D4-18267-31F40845; Thu, 04 Dec 2014 12:09:55 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417694990!11083298!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18419 invoked from network); 4 Dec 2014 12:09:53 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 12:09:53 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDK93579; Thu, 04 Dec 2014 20:09:42 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Thu, 4 Dec 2014 20:09:34 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIAAiqFg
Date: Thu, 4 Dec 2014 12:09:33 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
In-Reply-To: <20141204105021.GA16532@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Thursday, December 04, 2014 6:50 PM
> To: Zhangleiqiang (Trump)
> Cc: Wei Liu; xen-devel@lists.xen.org; zhangleiqiang; Luohao (brian); Xiaoding
> (B); Yuzhou (C); Zhuangyuxin
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> On Wed, Dec 03, 2014 at 02:43:37PM +0000, Zhangleiqiang (Trump) wrote:
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: Tuesday, December 02, 2014 11:59 PM
> > > To: Zhangleiqiang (Trump)
> > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian);
> > > Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > > multiqueue support
> > >
> > > On Tue, Dec 02, 2014 at 02:46:36PM +0000, Zhangleiqiang (Trump) wrote:
> > > > Thanks for your reply, Wei.
> > > >
> > > > I do the following testing just now and found the results as follows:
> > > >
> > > > There are three DomUs (4U4G) are running on Host A (6U6G) and one
> > > > DomU
> > > (4U4G) is running on Host B (6U6G), I send packets from three DomUs
> > > to the DomU on Host B simultaneously.
> > > >
> > > > 1. The "top" output of Host B as follows:
> > > >
> > > > top - 09:42:11 up  1:07,  2 users,  load average: 2.46, 1.90, 1.47
> > > > Tasks: 173 total,   4 running, 169 sleeping,   0 stopped,   0 zombie
> > > > %Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 97.3 id,  0.0 wa,  0.0 hi,
> > > > 0.8 si,  1.9 st
> > > > %Cpu1  :  0.0 us, 27.0 sy,  0.0 ni, 63.1 id,  0.0 wa,  0.0 hi,
> > > > 9.5 si,  0.4 st
> > > > %Cpu2  :  0.0 us, 90.0 sy,  0.0 ni,  8.3 id,  0.0 wa,  0.0 hi,
> > > > 1.7 si,  0.0 st
> > > > %Cpu3  :  0.4 us,  1.4 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,
> > > > 1.4 si,  1.4 st
> > > > %Cpu4  :  0.0 us, 60.2 sy,  0.0 ni, 39.5 id,  0.0 wa,  0.0 hi,
> > > > 0.3 si,  0.0 st
> > > > %Cpu5  :  0.0 us,  2.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.0 hi,
> > > > 6.9 si,  0.9
> > > st
> > > > KiB Mem:   4517144 total,  3116480 used,  1400664 free,      876
> > > buffers
> > > > KiB Swap:  2103292 total,        0 used,  2103292 free.  2374656
> > > cached Mem
> > > >
> > > >   PID USER      PR  NI    VIRT    RES    SHR
> S  %CPU  %MEM
> > > TIME+ COMMAND
> > > >  7440 root      20   0       0      0      0 R 71.10 0.000
> > > 8:15.38 vif4.0-q3-guest
> > > >  7434 root      20   0       0      0      0 R 59.14 0.000
> > > 9:00.58 vif4.0-q0-guest
> > > >    18 root      20   0       0      0      0 R 33.89 0.000
> > > 2:35.06 ksoftirqd/2
> > > >    28 root      20   0       0      0      0 S 20.93 0.000
> > > 3:01.81 ksoftirqd/4
> > > >
> > > >
> > > > As shown above, only two netback related processes (vif4.0-*) are
> > > > running
> > > with high cpu usage, and the other 2 netback processes are idle. The "ps"
> > > result of vif4.0-* processes as follows:
> > > >
> > > > root      7434 50.5  0.0      0     0 ?        R    09:23
> 11:29
> > > [vif4.0-q0-guest]
> > > > root      7435  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q0-deall]
> > > > root      7436  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q1-guest]
> > > > root      7437  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q1-deall]
> > > > root      7438  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q2-guest]
> > > > root      7439  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q2-deall]
> > > > root      7440 48.1  0.0      0     0 ?        R    09:23
> 10:55
> > > [vif4.0-q3-guest]
> > > > root      7441  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q3-deall]
> > > > root      9724  0.0  0.0   9244  1520 pts/0    S+   09:46
> 0:00
> > > grep --color=auto
> > > >
> > > >
> > > > 2. The "rx" related content in /proc/interupts in receiver DomU (on Host
> B):
> > > >
> > > > 73: 	2		0		2925405		0			xen-dyn-event
> > > 	eth0-q0-rx
> > > > 75: 	43		93		0			118			xen-dyn-event
> > > 	eth0-q1-rx
> > > > 77: 	2		3376	14			1983		xen-dyn-event
> > > 	eth0-q2-rx
> > > > 79: 	2414666	0		9			0			xen-dyn-event
> > > 	eth0-q3-rx
> > > >
> > > > As shown above, it seems like that only q0 and q3 handles the
> > > > interrupt
> > > triggered by packet receving.
> > > >
> > > > Any advise? Thanks.
> > >
> > > Netback selects queue based on the return value of
> skb_get_queue_mapping.
> > > The queue mapping is set by core driver or ndo_select_queue (if
> > > specified by individual driver). In this case netback doesn't have
> > > its implementation of ndo_select_queue, so it's up to core driver to
> > > decide which queue to dispatch the packet to.  I think you need to
> > > inspect why Dom0 only steers traffic to these two queues but not all of
> them.
> > >
> > > Don't know which utility is handy for this job. Probably tc(8) is useful?
> >
> > Thanks Wei.
> >
> 
> > I think the reason for the above results that only two
> > netback/netfront processes works hard is the queue select method. I
> > have tried to send packets from multiple host/vm to a vm, and all of
> > the netback/netfront processes are running with high cpu usage a few
> > times.
> >
> 
> A few times? You might want to check some patches to rework RX stall
> detection by David Vrabel that went in after 3.16.

Thanks for your suggest. I have switched to latest stable branch 3.17.4 and I find the patches you mentioned are not merged in this branch too, I will merge this patch and try again.

> > However, I find another issue. Even using 6 queues and making sure
> > that all of these 6 netback processes running with high cpu usage
> > (indeed, any of it running with 87% cpu usage), the whole VM receive
> > throughout is not very higher than results when using 4 queues. The
> > results are from 4.5Gbps to 5.04 Gbps using TCP with 512 bytes length
> > and 4.3Gbps to 5.78Gbps using TCP with 1460 bytes length.
> >
> 
> I would like to ask if you're still using 4U4G (4 CPU 4 G?) configuration? If so,
> please make sure there are at least the same number of vcpus as queues.

Sorry for misleading you, 4U4G means 4 CPU and 4 G memory, :). I also found that the max_queue of netback is determinated by min(online_cpu, module_param) yesterday, so when using 6 queues in the previous testing, I used VM with 6 CPU and 6 G Memory.

> > According to the testing result from WIKI:
> > http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_perf
> > ormance_testing, The VM receive throughput is also more lower than VM
> > transmit.
> >
> 
> I think that's expected, because guest RX data path still uses grant_copy while
> guest TX uses grant_map to do zero-copy transmit.

As I understand, the RX process is as follows: 
1. Phy NIC receive packet
2. XEN Hypervisor trigger interrupt to Dom0
3. Dom0' s NIC driver do the "RX" operation, and the packet is stored into SKB which is also owned/shared with netback
4. NetBack notify netfront through event channel that a packet is receiving
5. Netfront grant a buffer for receiving and notify netback the GR (if using grant-resue mechanism, netfront just notify the GR to netback) through IO Ring
6. NetBack do the grant_copy to copy packet from its SKB to the buffer referenced by GR, and notify netfront through event channel
7. Netfront copy the data from buffer to user-level app's SKB

Am I right? Why not using zero-copy transmit in guest RX data pash too ?


> > I am wondering why the VM receive throughout cannot be up to 8-10Gbps
> > as VM transmit under multi-queue?  I also tried to send packets
> > directly from Local Dom0 to DomU, the DomU receive throughput can
> > reach about 8-12Gbps, so I am also wondering why transmitting packets
> > from Dom0 to Remote DomU can only reach about 4-5Gbps throughout?
> 
> If data is from Dom0 to DomU then SKB is probably not fragmented by network
> stack.  You can use tcpdump to check that.

In our testing , the MTU is set to 1600. However, even testing with packets whose length are 1024 (small than 1600), the throughout between Dom0 to Local DomU is more higher than that between Dom0 to Remote DomU. So maybe the fragment is not the reason for it.


> Wei.
> 
> >
> > > Wei.
> > >
> > > > ----------
> > > > zhangleiqiang (Trump)
> > > >
> > > > Best Regards
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > > > Sent: Tuesday, December 02, 2014 8:12 PM
> > > > > To: Zhangleiqiang (Trump)
> > > > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao
> > > > > (brian); Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > > > Subject: Re: [Xen-devel] Poor network performance between DomU
> > > > > with multiqueue support
> > > > >
> > > > > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump)
> wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: xen-devel-bounces@lists.xen.org
> > > > > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei
> > > > > > > Liu
> > > > > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > > > > To: zhangleiqiang
> > > > > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > > > > Subject: Re: [Xen-devel] Poor network performance between
> > > > > > > DomU with multiqueue support
> > > > > > >
> > > > > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > > > > > Hi, all
> > > > > > > >     I am testing the performance of xen netfront-netback
> > > > > > > > driver that with
> > > > > > > multi-queues support. The throughput from domU to remote
> > > > > > > dom0 is 9.2Gb/s, but the throughput from domU to remote domU
> > > > > > > is only 3.6Gb/s, I think the bottleneck is the throughput
> > > > > > > from dom0 to local domU. However, we have done some testing
> > > > > > > and found the throughput from dom0 to local domU is 5.8Gb/s.
> > > > > > > >     And if we send packets from one DomU to other 3 DomUs
> > > > > > > > on different
> > > > > > > host simultaneously, the sum of throughout can reach 9Gbps.
> > > > > > > It seems like the bottleneck is the receiver?
> > > > > > > >     After some analysis, I found that even the max_queue
> > > > > > > > of netfront/back
> > > > > > > is set to 4, there are some strange results as follows:
> > > > > > > >     1. In domU, only one rx queue deal with softirq
> > > > > > >
> > > > > > > Try to bind irq to different vcpus?
> > > > > >
> > > > > > Do you mean we try to bind irq to different vcpus in DomU? I
> > > > > > will try it
> > > now.
> > > > > >
> > > > >
> > > > > Yes. Given the fact that you have two backend threads running
> > > > > while only one DomU vcpu is busy, it smells like misconfiguration in
> DomU.
> > > > >
> > > > > If this phenomenon persists after correctly binding irqs, you
> > > > > might want to check traffic is steering correctly to different queues.
> > > > >
> > > > > > >
> > > > > > > >     2. In dom0, only two netback queues process are
> > > > > > > > scheduled, other two
> > > > > > > process aren't scheduled.
> > > > > > >
> > > > > > > How many Dom0 vcpu do you have? If it only has two then
> > > > > > > there will only be two processes running at a time.
> > > > > >
> > > > > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU
> > > > > > running in
> > > > > Dom0 and so four netback processes are running in Dom0 (because
> > > > > the max_queue param of netback kernel module is set to 4).
> > > > > > The phenomenon is that only 2 of these four netback process
> > > > > > were running
> > > > > with about 70% cpu usage, and another two use little CPU.
> > > > > > Is there a hash algorithm to determine which netback process
> > > > > > to handle the
> > > > > input packet?
> > > > > >
> > > > >
> > > > > I think that's whatever default algorithm Linux kernel is using.
> > > > >
> > > > > We don't currently support other algorithms.
> > > > >
> > > > > Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 12:10:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwVEM-0000w9-Dv; Thu, 04 Dec 2014 12:09:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XwVEK-0000w3-BP
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 12:09:56 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	27/D4-18267-31F40845; Thu, 04 Dec 2014 12:09:55 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417694990!11083298!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18419 invoked from network); 4 Dec 2014 12:09:53 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 12:09:53 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDK93579; Thu, 04 Dec 2014 20:09:42 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Thu, 4 Dec 2014 20:09:34 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIAAiqFg
Date: Thu, 4 Dec 2014 12:09:33 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
In-Reply-To: <20141204105021.GA16532@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Thursday, December 04, 2014 6:50 PM
> To: Zhangleiqiang (Trump)
> Cc: Wei Liu; xen-devel@lists.xen.org; zhangleiqiang; Luohao (brian); Xiaoding
> (B); Yuzhou (C); Zhuangyuxin
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> On Wed, Dec 03, 2014 at 02:43:37PM +0000, Zhangleiqiang (Trump) wrote:
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: Tuesday, December 02, 2014 11:59 PM
> > > To: Zhangleiqiang (Trump)
> > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian);
> > > Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > > multiqueue support
> > >
> > > On Tue, Dec 02, 2014 at 02:46:36PM +0000, Zhangleiqiang (Trump) wrote:
> > > > Thanks for your reply, Wei.
> > > >
> > > > I do the following testing just now and found the results as follows:
> > > >
> > > > There are three DomUs (4U4G) are running on Host A (6U6G) and one
> > > > DomU
> > > (4U4G) is running on Host B (6U6G), I send packets from three DomUs
> > > to the DomU on Host B simultaneously.
> > > >
> > > > 1. The "top" output of Host B as follows:
> > > >
> > > > top - 09:42:11 up  1:07,  2 users,  load average: 2.46, 1.90, 1.47
> > > > Tasks: 173 total,   4 running, 169 sleeping,   0 stopped,   0 zombie
> > > > %Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 97.3 id,  0.0 wa,  0.0 hi,
> > > > 0.8 si,  1.9 st
> > > > %Cpu1  :  0.0 us, 27.0 sy,  0.0 ni, 63.1 id,  0.0 wa,  0.0 hi,
> > > > 9.5 si,  0.4 st
> > > > %Cpu2  :  0.0 us, 90.0 sy,  0.0 ni,  8.3 id,  0.0 wa,  0.0 hi,
> > > > 1.7 si,  0.0 st
> > > > %Cpu3  :  0.4 us,  1.4 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,
> > > > 1.4 si,  1.4 st
> > > > %Cpu4  :  0.0 us, 60.2 sy,  0.0 ni, 39.5 id,  0.0 wa,  0.0 hi,
> > > > 0.3 si,  0.0 st
> > > > %Cpu5  :  0.0 us,  2.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.0 hi,
> > > > 6.9 si,  0.9
> > > st
> > > > KiB Mem:   4517144 total,  3116480 used,  1400664 free,      876
> > > buffers
> > > > KiB Swap:  2103292 total,        0 used,  2103292 free.  2374656
> > > cached Mem
> > > >
> > > >   PID USER      PR  NI    VIRT    RES    SHR
> S  %CPU  %MEM
> > > TIME+ COMMAND
> > > >  7440 root      20   0       0      0      0 R 71.10 0.000
> > > 8:15.38 vif4.0-q3-guest
> > > >  7434 root      20   0       0      0      0 R 59.14 0.000
> > > 9:00.58 vif4.0-q0-guest
> > > >    18 root      20   0       0      0      0 R 33.89 0.000
> > > 2:35.06 ksoftirqd/2
> > > >    28 root      20   0       0      0      0 S 20.93 0.000
> > > 3:01.81 ksoftirqd/4
> > > >
> > > >
> > > > As shown above, only two netback related processes (vif4.0-*) are
> > > > running
> > > with high cpu usage, and the other 2 netback processes are idle. The "ps"
> > > result of vif4.0-* processes as follows:
> > > >
> > > > root      7434 50.5  0.0      0     0 ?        R    09:23
> 11:29
> > > [vif4.0-q0-guest]
> > > > root      7435  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q0-deall]
> > > > root      7436  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q1-guest]
> > > > root      7437  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q1-deall]
> > > > root      7438  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q2-guest]
> > > > root      7439  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q2-deall]
> > > > root      7440 48.1  0.0      0     0 ?        R    09:23
> 10:55
> > > [vif4.0-q3-guest]
> > > > root      7441  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q3-deall]
> > > > root      9724  0.0  0.0   9244  1520 pts/0    S+   09:46
> 0:00
> > > grep --color=auto
> > > >
> > > >
> > > > 2. The "rx" related content in /proc/interupts in receiver DomU (on Host
> B):
> > > >
> > > > 73: 	2		0		2925405		0			xen-dyn-event
> > > 	eth0-q0-rx
> > > > 75: 	43		93		0			118			xen-dyn-event
> > > 	eth0-q1-rx
> > > > 77: 	2		3376	14			1983		xen-dyn-event
> > > 	eth0-q2-rx
> > > > 79: 	2414666	0		9			0			xen-dyn-event
> > > 	eth0-q3-rx
> > > >
> > > > As shown above, it seems like that only q0 and q3 handles the
> > > > interrupt
> > > triggered by packet receving.
> > > >
> > > > Any advise? Thanks.
> > >
> > > Netback selects queue based on the return value of
> skb_get_queue_mapping.
> > > The queue mapping is set by core driver or ndo_select_queue (if
> > > specified by individual driver). In this case netback doesn't have
> > > its implementation of ndo_select_queue, so it's up to core driver to
> > > decide which queue to dispatch the packet to.  I think you need to
> > > inspect why Dom0 only steers traffic to these two queues but not all of
> them.
> > >
> > > Don't know which utility is handy for this job. Probably tc(8) is useful?
> >
> > Thanks Wei.
> >
> 
> > I think the reason for the above results that only two
> > netback/netfront processes works hard is the queue select method. I
> > have tried to send packets from multiple host/vm to a vm, and all of
> > the netback/netfront processes are running with high cpu usage a few
> > times.
> >
> 
> A few times? You might want to check some patches to rework RX stall
> detection by David Vrabel that went in after 3.16.

Thanks for your suggest. I have switched to latest stable branch 3.17.4 and I find the patches you mentioned are not merged in this branch too, I will merge this patch and try again.

> > However, I find another issue. Even using 6 queues and making sure
> > that all of these 6 netback processes running with high cpu usage
> > (indeed, any of it running with 87% cpu usage), the whole VM receive
> > throughout is not very higher than results when using 4 queues. The
> > results are from 4.5Gbps to 5.04 Gbps using TCP with 512 bytes length
> > and 4.3Gbps to 5.78Gbps using TCP with 1460 bytes length.
> >
> 
> I would like to ask if you're still using 4U4G (4 CPU 4 G?) configuration? If so,
> please make sure there are at least the same number of vcpus as queues.

Sorry for misleading you, 4U4G means 4 CPU and 4 G memory, :). I also found that the max_queue of netback is determinated by min(online_cpu, module_param) yesterday, so when using 6 queues in the previous testing, I used VM with 6 CPU and 6 G Memory.

> > According to the testing result from WIKI:
> > http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_perf
> > ormance_testing, The VM receive throughput is also more lower than VM
> > transmit.
> >
> 
> I think that's expected, because guest RX data path still uses grant_copy while
> guest TX uses grant_map to do zero-copy transmit.

As I understand, the RX process is as follows: 
1. Phy NIC receive packet
2. XEN Hypervisor trigger interrupt to Dom0
3. Dom0' s NIC driver do the "RX" operation, and the packet is stored into SKB which is also owned/shared with netback
4. NetBack notify netfront through event channel that a packet is receiving
5. Netfront grant a buffer for receiving and notify netback the GR (if using grant-resue mechanism, netfront just notify the GR to netback) through IO Ring
6. NetBack do the grant_copy to copy packet from its SKB to the buffer referenced by GR, and notify netfront through event channel
7. Netfront copy the data from buffer to user-level app's SKB

Am I right? Why not using zero-copy transmit in guest RX data pash too ?


> > I am wondering why the VM receive throughout cannot be up to 8-10Gbps
> > as VM transmit under multi-queue?  I also tried to send packets
> > directly from Local Dom0 to DomU, the DomU receive throughput can
> > reach about 8-12Gbps, so I am also wondering why transmitting packets
> > from Dom0 to Remote DomU can only reach about 4-5Gbps throughout?
> 
> If data is from Dom0 to DomU then SKB is probably not fragmented by network
> stack.  You can use tcpdump to check that.

In our testing , the MTU is set to 1600. However, even testing with packets whose length are 1024 (small than 1600), the throughout between Dom0 to Local DomU is more higher than that between Dom0 to Remote DomU. So maybe the fragment is not the reason for it.


> Wei.
> 
> >
> > > Wei.
> > >
> > > > ----------
> > > > zhangleiqiang (Trump)
> > > >
> > > > Best Regards
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > > > Sent: Tuesday, December 02, 2014 8:12 PM
> > > > > To: Zhangleiqiang (Trump)
> > > > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao
> > > > > (brian); Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > > > Subject: Re: [Xen-devel] Poor network performance between DomU
> > > > > with multiqueue support
> > > > >
> > > > > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump)
> wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: xen-devel-bounces@lists.xen.org
> > > > > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei
> > > > > > > Liu
> > > > > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > > > > To: zhangleiqiang
> > > > > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > > > > Subject: Re: [Xen-devel] Poor network performance between
> > > > > > > DomU with multiqueue support
> > > > > > >
> > > > > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > > > > > Hi, all
> > > > > > > >     I am testing the performance of xen netfront-netback
> > > > > > > > driver that with
> > > > > > > multi-queues support. The throughput from domU to remote
> > > > > > > dom0 is 9.2Gb/s, but the throughput from domU to remote domU
> > > > > > > is only 3.6Gb/s, I think the bottleneck is the throughput
> > > > > > > from dom0 to local domU. However, we have done some testing
> > > > > > > and found the throughput from dom0 to local domU is 5.8Gb/s.
> > > > > > > >     And if we send packets from one DomU to other 3 DomUs
> > > > > > > > on different
> > > > > > > host simultaneously, the sum of throughout can reach 9Gbps.
> > > > > > > It seems like the bottleneck is the receiver?
> > > > > > > >     After some analysis, I found that even the max_queue
> > > > > > > > of netfront/back
> > > > > > > is set to 4, there are some strange results as follows:
> > > > > > > >     1. In domU, only one rx queue deal with softirq
> > > > > > >
> > > > > > > Try to bind irq to different vcpus?
> > > > > >
> > > > > > Do you mean we try to bind irq to different vcpus in DomU? I
> > > > > > will try it
> > > now.
> > > > > >
> > > > >
> > > > > Yes. Given the fact that you have two backend threads running
> > > > > while only one DomU vcpu is busy, it smells like misconfiguration in
> DomU.
> > > > >
> > > > > If this phenomenon persists after correctly binding irqs, you
> > > > > might want to check traffic is steering correctly to different queues.
> > > > >
> > > > > > >
> > > > > > > >     2. In dom0, only two netback queues process are
> > > > > > > > scheduled, other two
> > > > > > > process aren't scheduled.
> > > > > > >
> > > > > > > How many Dom0 vcpu do you have? If it only has two then
> > > > > > > there will only be two processes running at a time.
> > > > > >
> > > > > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU
> > > > > > running in
> > > > > Dom0 and so four netback processes are running in Dom0 (because
> > > > > the max_queue param of netback kernel module is set to 4).
> > > > > > The phenomenon is that only 2 of these four netback process
> > > > > > were running
> > > > > with about 70% cpu usage, and another two use little CPU.
> > > > > > Is there a hash algorithm to determine which netback process
> > > > > > to handle the
> > > > > input packet?
> > > > > >
> > > > >
> > > > > I think that's whatever default algorithm Linux kernel is using.
> > > > >
> > > > > We don't currently support other algorithms.
> > > > >
> > > > > Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 12:15:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12: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 1XwVJa-0001K6-6Y; Thu, 04 Dec 2014 12:15: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 1XwVJZ-0001K1-8e
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 12:15:21 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	23/AA-22737-85050845; Thu, 04 Dec 2014 12:15:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417695318!8170746!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21602 invoked from network); 4 Dec 2014 12:15:19 -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; 4 Dec 2014 12:15:19 -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 sB4CErv7005985
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 12:14:54 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
	sB4CEowT009907
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 4 Dec 2014 12:14:52 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
	sB4CEoXn022467; Thu, 4 Dec 2014 12:14:50 GMT
Message-Id: <201412041214.sB4CEoXn022467@aserz7021.oracle.com>
Received: from [IPv6:2607:fb90:e1d:a128:feaa:33ac:bd67:5442] (/172.56.23.134)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 04 Dec 2014 04:14:49 -0800
Date: Thu, 04 Dec 2014 07:13:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Mark Pryor <tlviewer@yahoo.com>, Olaf Hering <olaf@aepfle.de>,
	Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	M A Young <m.a.young@durham.ac.uk>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ck9uIERlYyA0LCAyMDE0IDY6NTUgQU0sIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJp
eC5jb20+IHdyb3RlOgo+Cj4gT24gV2VkLCAyMDE0LTEyLTAzIGF0IDEwOjUxICswMDAwLCBJYW4g
Q2FtcGJlbGwgd3JvdGU6IAo+ID4gT24gV2VkLCAyMDE0LTEyLTAzIGF0IDExOjQ5ICswMTAwLCBP
bGFmIEhlcmluZyB3cm90ZTogCj4gPiA+IE9uIFdlZCwgRGVjIDAzLCBJYW4gQ2FtcGJlbGwgd3Jv
dGU6IAo+ID4gPiAKPiA+ID4gPiBBaCBJIGRpZG4ndCBrbm93IGFib3V0IHRoZSBzZF9saXN0ZW5f
ZmRzIHRoaW5nLCBzbyBJIHRoaW5rIHRoYXQgd2hhdCB3ZSAKPiA+ID4gPiBuZWVkIHRoZW4gaXMg
dG8gdXNlIHBrZy1jb25maWcgZmlyc3QgdG8gZGV0ZXJtaW5lIGlmIHN5c3RlbWQtZGFlbW9uIGlz
IAo+ID4gPiA+IHByZXNlbnQgYXQgYWxsLCBhbmQgdGhlbiBjaGVjayBmb3Igc3BlY2lmaWMgc3lt
Ym9scyB3ZSByZXF1aXJlIHVzaW5nIHRoZSAKPiA+ID4gPiBwa2ctY29uZmlnIHN1cHBsaWVkIENG
TEFHUyBhbmQgTERGTEFHUyByYXRoZXIgdGhhbiBhc3N1bWluZyAKPiA+ID4gPiAtbHN5c3RlbWQt
ZGFlbW9uLiAKPiA+ID4gCj4gPiA+IENvcnJlY3Rpb246IHNkX2xpc3Rlbl9mZHMgaXMgYXZhaWxh
YmxlIHNpbmNlIGF0IGxlYXN0IHYxLiAKPiA+ID7CoCBnaXQgZGVzY3JpYmUgLS1jb250YWlucyBh
YmJiZWE4MWE4ZmE3MGJhZGI3YTA1ZTUxOGQ2YjA3YzM2MGZjMDlkIAo+ID4gPsKgIHYxfjM5MCAK
PiA+IAo+ID4gSW4gdGhhdCBjYXNlIEkgZG9uJ3QgdGhpbmsgd2UgcmVhbGlzdGljYWxseSBuZWVk
IHRvIGNoZWNrIGZvciBpdD8gCj4KPiBUaGUgaW1wbGljYXRpb24gaGVyZSBiZWluZyB0aGF0IFdl
aSdzIG9yaWdpbmFsIHBhdGNoIGlzIGNvcnJlY3QuIEtvbnJhZCwgCj4gZG8geW91IHRoaW5rIHRo
aXMgaXMgT0sgZm9yIHRoZSByZWxlYXNlPyAKPgo+ID4gCgpZZXMuIFJlbGVhc2UtQXhrZWQtQnk6
IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8S29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPiA+IElhbi4g
Cj4gPiAKPiA+IAo+ID4gCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXyAKPiA+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QgCj4gPiBYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZyAKPiA+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbCAKPgo+Cj4KPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyAKPiBYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0IAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnIAo+IGh0dHA6Ly9saXN0
cy54ZW4ub3JnL3hlbi1kZXZlbCAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9y
ZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Dec 04 12:15:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12: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 1XwVJa-0001K6-6Y; Thu, 04 Dec 2014 12:15: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 1XwVJZ-0001K1-8e
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 12:15:21 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	23/AA-22737-85050845; Thu, 04 Dec 2014 12:15:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417695318!8170746!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21602 invoked from network); 4 Dec 2014 12:15:19 -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; 4 Dec 2014 12:15:19 -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 sB4CErv7005985
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 12:14:54 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
	sB4CEowT009907
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 4 Dec 2014 12:14:52 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
	sB4CEoXn022467; Thu, 4 Dec 2014 12:14:50 GMT
Message-Id: <201412041214.sB4CEoXn022467@aserz7021.oracle.com>
Received: from [IPv6:2607:fb90:e1d:a128:feaa:33ac:bd67:5442] (/172.56.23.134)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 04 Dec 2014 04:14:49 -0800
Date: Thu, 04 Dec 2014 07:13:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Mark Pryor <tlviewer@yahoo.com>, Olaf Hering <olaf@aepfle.de>,
	Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	M A Young <m.a.young@durham.ac.uk>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ck9uIERlYyA0LCAyMDE0IDY6NTUgQU0sIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJp
eC5jb20+IHdyb3RlOgo+Cj4gT24gV2VkLCAyMDE0LTEyLTAzIGF0IDEwOjUxICswMDAwLCBJYW4g
Q2FtcGJlbGwgd3JvdGU6IAo+ID4gT24gV2VkLCAyMDE0LTEyLTAzIGF0IDExOjQ5ICswMTAwLCBP
bGFmIEhlcmluZyB3cm90ZTogCj4gPiA+IE9uIFdlZCwgRGVjIDAzLCBJYW4gQ2FtcGJlbGwgd3Jv
dGU6IAo+ID4gPiAKPiA+ID4gPiBBaCBJIGRpZG4ndCBrbm93IGFib3V0IHRoZSBzZF9saXN0ZW5f
ZmRzIHRoaW5nLCBzbyBJIHRoaW5rIHRoYXQgd2hhdCB3ZSAKPiA+ID4gPiBuZWVkIHRoZW4gaXMg
dG8gdXNlIHBrZy1jb25maWcgZmlyc3QgdG8gZGV0ZXJtaW5lIGlmIHN5c3RlbWQtZGFlbW9uIGlz
IAo+ID4gPiA+IHByZXNlbnQgYXQgYWxsLCBhbmQgdGhlbiBjaGVjayBmb3Igc3BlY2lmaWMgc3lt
Ym9scyB3ZSByZXF1aXJlIHVzaW5nIHRoZSAKPiA+ID4gPiBwa2ctY29uZmlnIHN1cHBsaWVkIENG
TEFHUyBhbmQgTERGTEFHUyByYXRoZXIgdGhhbiBhc3N1bWluZyAKPiA+ID4gPiAtbHN5c3RlbWQt
ZGFlbW9uLiAKPiA+ID4gCj4gPiA+IENvcnJlY3Rpb246IHNkX2xpc3Rlbl9mZHMgaXMgYXZhaWxh
YmxlIHNpbmNlIGF0IGxlYXN0IHYxLiAKPiA+ID7CoCBnaXQgZGVzY3JpYmUgLS1jb250YWlucyBh
YmJiZWE4MWE4ZmE3MGJhZGI3YTA1ZTUxOGQ2YjA3YzM2MGZjMDlkIAo+ID4gPsKgIHYxfjM5MCAK
PiA+IAo+ID4gSW4gdGhhdCBjYXNlIEkgZG9uJ3QgdGhpbmsgd2UgcmVhbGlzdGljYWxseSBuZWVk
IHRvIGNoZWNrIGZvciBpdD8gCj4KPiBUaGUgaW1wbGljYXRpb24gaGVyZSBiZWluZyB0aGF0IFdl
aSdzIG9yaWdpbmFsIHBhdGNoIGlzIGNvcnJlY3QuIEtvbnJhZCwgCj4gZG8geW91IHRoaW5rIHRo
aXMgaXMgT0sgZm9yIHRoZSByZWxlYXNlPyAKPgo+ID4gCgpZZXMuIFJlbGVhc2UtQXhrZWQtQnk6
IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8S29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPiA+IElhbi4g
Cj4gPiAKPiA+IAo+ID4gCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXyAKPiA+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QgCj4gPiBYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZyAKPiA+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbCAKPgo+Cj4KPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyAKPiBYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0IAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnIAo+IGh0dHA6Ly9saXN0
cy54ZW4ub3JnL3hlbi1kZXZlbCAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9y
ZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Dec 04 12:22:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12: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 1XwVQC-0001XA-KK; Thu, 04 Dec 2014 12:22:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XwVQA-0001Wu-UE
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 12:22:11 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	BE/8B-22737-2F150845; Thu, 04 Dec 2014 12:22:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417695728!11515184!1
X-Originating-IP: [66.165.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 28936 invoked from network); 4 Dec 2014 12:22:09 -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 Dec 2014 12:22:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200034320"
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, 4 Dec 2014 07:22: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 1XwVQ7-0003g0-9M;
	Thu, 04 Dec 2014 12:22:07 +0000
Date: Thu, 4 Dec 2014 12:21:54 +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: <20141203204121.GA9287@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1412041216320.30971@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1412031818180.30971@kaball.uk.xensource.com>
	<20141203204121.GA9287@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, dslutz@verizon.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl_set_memory_target: only
 remove videoram from absolute targets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 3 Dec 2014, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 03, 2014 at 06:20:41PM +0000, Stefano Stabellini wrote:
> > If the new target is relative to the current target, do not remove
> > videoram again: it has already been removed from the current target.
> 
> Please explain:
>  - Is this an regression?

No, it is not.


>  - How often does it occur?

Every time the user creates a domain and memory needs to be freed in
dom0 for the allocation.


>  - Is it fatal?

No, it causes the new target for dom0 to be lower than it actually
needs to be by videram amount. However I realize now that the videoram
for dom0 is 0 so the bug wouldn't cause any troubles at the moment.

I guess it might be best to postpone this fix to 4.6.


>  - Are there work-arounds?
> 
> Thanks!
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index de23fec..2aa83bd 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4741,13 +4741,17 @@ retry_transaction:
> >          goto out;
> >      }
> >  
> > +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> > +                "%s/memory/videoram", dompath));
> > +    videoram = videoram_s ? atoi(videoram_s) : 0;
> > +
> >      if (relative) {
> >          if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
> >              new_target_memkb = 0;
> >          else
> >              new_target_memkb = current_target_memkb + target_memkb;
> >      } else
> > -        new_target_memkb = target_memkb;
> > +        new_target_memkb = target_memkb - videoram;
> >      if (new_target_memkb > memorykb) {
> >          LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> >                  "memory_dynamic_max must be less than or equal to"
> > @@ -4763,9 +4767,6 @@ retry_transaction:
> >          abort_transaction = 1;
> >          goto out;
> >      }
> > -    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> > -                "%s/memory/videoram", dompath));
> > -    videoram = videoram_s ? atoi(videoram_s) : 0;
> >  
> >      if (enforce) {
> >          memorykb = new_target_memkb;
> > @@ -4780,7 +4781,6 @@ retry_transaction:
> >          }
> >      }
> >  
> > -    new_target_memkb -= videoram;
> >      rc = xc_domain_set_pod_target(ctx->xch, domid,
> >              new_target_memkb / 4, NULL, NULL, NULL);
> >      if (rc != 0) {
> 

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 12:22:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12: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 1XwVQH-0001YH-0g; Thu, 04 Dec 2014 12:22:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XwVQG-0001Xv-0e
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 12:22:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	99/38-25276-7F150845; Thu, 04 Dec 2014 12:22:15 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417695733!13335359!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12716 invoked from network); 4 Dec 2014 12:22:14 -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;
	4 Dec 2014 12:22:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; 
	d="asc'?scan'208";a="200034342"
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; Thu, 4 Dec 2014
	07:22:12 -0500
Message-ID: <1417695730.31647.35.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Thu, 4 Dec 2014 13:22:10 +0100
In-Reply-To: <1417556050-23364-4-git-send-email-boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-4-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: 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, jbeulich@suse.com, keir@xen.org,
	ufimtseva@gmail.com
Subject: Re: [Xen-devel] [PATCH 3/4] sysctl/libxl: Provide information about
	IO topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4112264579869404508=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4112264579869404508==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-7e0aft5uwqqBDq9RFrzU"

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

On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:

> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1168,6 +1168,11 @@ _hidden int libxl__try_phy_backend(mode_t st_mode)=
;
> =20
>  _hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid);
> =20
> +_hidden int libxl_pci_numdevs(libxl_ctx *ctx);
> +_hidden int libxl_pci_topology_init(libxl_ctx *ctx,
> +                                    xen_sysctl_iotopo_t *iotopo,
> +                                    int numdev);
> +
IIRC, internal/hidden function should have libxl__* as prefix.

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)


--=-7e0aft5uwqqBDq9RFrzU
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

iEYEABECAAYFAlSAUfIACgkQk4XaBE3IOsRuwACfThED3nOXKCOLpAElaefpGaXF
m04Ani+pEdJYqIBc2YBi+QrbsmCF08xz
=ZyE8
-----END PGP SIGNATURE-----

--=-7e0aft5uwqqBDq9RFrzU--


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

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

--===============4112264579869404508==--


From xen-devel-bounces@lists.xen.org Thu Dec 04 12:22:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12: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 1XwVQ4-0001W1-1w; Thu, 04 Dec 2014 12:22: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 1XwVQ2-0001Vu-JE
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 12:22:02 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	21/A5-17958-8E150845; Thu, 04 Dec 2014 12:22:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417695718!10922698!1
X-Originating-IP: [66.165.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 21986 invoked from network); 4 Dec 2014 12:22:00 -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 Dec 2014 12:22:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200034278"
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, 4 Dec 2014 07:21: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 1XwVPx-0007mi-8z;
	Thu, 04 Dec 2014 12:21:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwVPw-0002IV-Sx;
	Thu, 04 Dec 2014 12:21:56 +0000
Date: Thu, 4 Dec 2014 12:21:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32055-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] 32055: 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 32055 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32055/

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-pv          16 guest-stop                  fail pass in 31991
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)     broken pass in 31991
 test-armhf-armhf-libvirt      4 xen-install        fail in 31991 pass in 32055

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  like 31733

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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31991 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                           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                          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                                          fail    
 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-i386-qemut-rhel6hvm-amd 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 Thu Dec 04 12:22:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12: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 1XwVQC-0001XA-KK; Thu, 04 Dec 2014 12:22:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XwVQA-0001Wu-UE
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 12:22:11 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	BE/8B-22737-2F150845; Thu, 04 Dec 2014 12:22:10 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417695728!11515184!1
X-Originating-IP: [66.165.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 28936 invoked from network); 4 Dec 2014 12:22:09 -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 Dec 2014 12:22:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200034320"
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, 4 Dec 2014 07:22: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 1XwVQ7-0003g0-9M;
	Thu, 04 Dec 2014 12:22:07 +0000
Date: Thu, 4 Dec 2014 12:21:54 +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: <20141203204121.GA9287@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1412041216320.30971@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1412031818180.30971@kaball.uk.xensource.com>
	<20141203204121.GA9287@laptop.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, dslutz@verizon.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl_set_memory_target: only
 remove videoram from absolute targets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 3 Dec 2014, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 03, 2014 at 06:20:41PM +0000, Stefano Stabellini wrote:
> > If the new target is relative to the current target, do not remove
> > videoram again: it has already been removed from the current target.
> 
> Please explain:
>  - Is this an regression?

No, it is not.


>  - How often does it occur?

Every time the user creates a domain and memory needs to be freed in
dom0 for the allocation.


>  - Is it fatal?

No, it causes the new target for dom0 to be lower than it actually
needs to be by videram amount. However I realize now that the videoram
for dom0 is 0 so the bug wouldn't cause any troubles at the moment.

I guess it might be best to postpone this fix to 4.6.


>  - Are there work-arounds?
> 
> Thanks!
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index de23fec..2aa83bd 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4741,13 +4741,17 @@ retry_transaction:
> >          goto out;
> >      }
> >  
> > +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> > +                "%s/memory/videoram", dompath));
> > +    videoram = videoram_s ? atoi(videoram_s) : 0;
> > +
> >      if (relative) {
> >          if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
> >              new_target_memkb = 0;
> >          else
> >              new_target_memkb = current_target_memkb + target_memkb;
> >      } else
> > -        new_target_memkb = target_memkb;
> > +        new_target_memkb = target_memkb - videoram;
> >      if (new_target_memkb > memorykb) {
> >          LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> >                  "memory_dynamic_max must be less than or equal to"
> > @@ -4763,9 +4767,6 @@ retry_transaction:
> >          abort_transaction = 1;
> >          goto out;
> >      }
> > -    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> > -                "%s/memory/videoram", dompath));
> > -    videoram = videoram_s ? atoi(videoram_s) : 0;
> >  
> >      if (enforce) {
> >          memorykb = new_target_memkb;
> > @@ -4780,7 +4781,6 @@ retry_transaction:
> >          }
> >      }
> >  
> > -    new_target_memkb -= videoram;
> >      rc = xc_domain_set_pod_target(ctx->xch, domid,
> >              new_target_memkb / 4, NULL, NULL, NULL);
> >      if (rc != 0) {
> 

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 12:22:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12: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 1XwVQH-0001YH-0g; Thu, 04 Dec 2014 12:22:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1XwVQG-0001Xv-0e
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 12:22:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	99/38-25276-7F150845; Thu, 04 Dec 2014 12:22:15 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417695733!13335359!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12716 invoked from network); 4 Dec 2014 12:22:14 -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;
	4 Dec 2014 12:22:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; 
	d="asc'?scan'208";a="200034342"
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; Thu, 4 Dec 2014
	07:22:12 -0500
Message-ID: <1417695730.31647.35.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Thu, 4 Dec 2014 13:22:10 +0100
In-Reply-To: <1417556050-23364-4-git-send-email-boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-4-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: 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, jbeulich@suse.com, keir@xen.org,
	ufimtseva@gmail.com
Subject: Re: [Xen-devel] [PATCH 3/4] sysctl/libxl: Provide information about
	IO topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4112264579869404508=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4112264579869404508==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-7e0aft5uwqqBDq9RFrzU"

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

On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:

> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1168,6 +1168,11 @@ _hidden int libxl__try_phy_backend(mode_t st_mode)=
;
> =20
>  _hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid);
> =20
> +_hidden int libxl_pci_numdevs(libxl_ctx *ctx);
> +_hidden int libxl_pci_topology_init(libxl_ctx *ctx,
> +                                    xen_sysctl_iotopo_t *iotopo,
> +                                    int numdev);
> +
IIRC, internal/hidden function should have libxl__* as prefix.

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)


--=-7e0aft5uwqqBDq9RFrzU
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

iEYEABECAAYFAlSAUfIACgkQk4XaBE3IOsRuwACfThED3nOXKCOLpAElaefpGaXF
m04Ani+pEdJYqIBc2YBi+QrbsmCF08xz
=ZyE8
-----END PGP SIGNATURE-----

--=-7e0aft5uwqqBDq9RFrzU--


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

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

--===============4112264579869404508==--


From xen-devel-bounces@lists.xen.org Thu Dec 04 12:22:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12: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 1XwVQ4-0001W1-1w; Thu, 04 Dec 2014 12:22: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 1XwVQ2-0001Vu-JE
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 12:22:02 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	21/A5-17958-8E150845; Thu, 04 Dec 2014 12:22:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417695718!10922698!1
X-Originating-IP: [66.165.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 21986 invoked from network); 4 Dec 2014 12:22:00 -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 Dec 2014 12:22:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200034278"
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, 4 Dec 2014 07:21: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 1XwVPx-0007mi-8z;
	Thu, 04 Dec 2014 12:21:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwVPw-0002IV-Sx;
	Thu, 04 Dec 2014 12:21:56 +0000
Date: Thu, 4 Dec 2014 12:21:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32055-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] 32055: 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 32055 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32055/

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-pv          16 guest-stop                  fail pass in 31991
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)     broken pass in 31991
 test-armhf-armhf-libvirt      4 xen-install        fail in 31991 pass in 32055

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  like 31733

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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 31991 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                           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                          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                                          fail    
 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-i386-qemut-rhel6hvm-amd 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 Thu Dec 04 12:25:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12: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 1XwVTL-00023i-Kv; Thu, 04 Dec 2014 12:25:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XwVTK-00023Y-Aq
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 12:25:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	39/F7-15461-5B250845; Thu, 04 Dec 2014 12:25:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417695922!13418215!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 24488 invoked from network); 4 Dec 2014 12:25:23 -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 Dec 2014 12:25:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; 
	d="scan'208,223";a="200035145"
Message-ID: <5480528F.8010106@citrix.com>
Date: Thu, 4 Dec 2014 12:24:47 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, David Vrabel
	<david.vrabel@citrix.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
In-Reply-To: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
Content-Type: multipart/mixed; boundary="------------040006050709030007030805"
X-DLP: MIA2
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------040006050709030007030805
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
> 
> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>
>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>
>>> Instead of doing all this complex dance, we depend on the toolstack 
>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>> It bypasses the need to worry about the PCI lock. 
>>
>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>> proposed). 
>>
> 
> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).

It is only needed if the core won't provide one.

+static int pcistub_try_create_reset_file(struct pci_dev *pci)
+{
+       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
+       struct device *dev = &pci->dev;
+       int ret;
+
+       /* Already have a per-function reset? */
+       if (pci_probe_reset_function(pci) == 0)
+               return 0;
+
+       ret = device_create_file(dev, &dev_attr_reset);
+       if (ret < 0)
+               return ret;
+       dev_data->created_reset_file = true;
+       return 0;
+}

David



--------------040006050709030007030805
Content-Type: text/x-diff;
	name="0002-xen-pciback-provide-a-reset-sysfs-file-to-try-harder.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename*0="0002-xen-pciback-provide-a-reset-sysfs-file-to-try-harder.pa";
	filename*1="tch"

>From e65a814106bc9994ec47b5317f7cdc975270d27f Mon Sep 17 00:00:00 2001
From: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 10 Jul 2014 13:09:25 +0100
Subject: [PATCH 2/2] xen-pciback: provide a "reset" sysfs file to try harder
 at an SBR

The standard implementation of pci_reset_function() does not try an
SBR if there are other sibling devices.  This is a common
configuration for multi-function devices (e.g., GPUs with a HDMI audio
device function).

If all the functions are co-assigned to the same domain at the same
time, then it is safe to perform an SBR to reset all functions at the
same time.

Add a "reset" sysfs file with the same interface as the standard one
(i.e., write 1 to reset) that will try an SBR if all sibling devices
are unbound or bound to pciback.

Note that this is weaker than the requirement for functions to be
simultaneously co-assigned, but the toolstack is expected to ensure
this.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 4e8ba38..d6c29aa 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -14,6 +14,7 @@
 #include <linux/wait.h>
 #include <linux/sched.h>
 #include <linux/atomic.h>
+#include <linux/delay.h>
 #include <xen/events.h>
 #include <asm/xen/pci.h>
 #include <asm/xen/hypervisor.h>
@@ -60,6 +61,114 @@ static LIST_HEAD(pcistub_devices);
 static int initialize_devices;
 static LIST_HEAD(seized_devices);
 
+/*
+ * pci_reset_function() will only work if there is a mechanism to
+ * reset that single function (e.g., FLR or a D-state transition).
+ * For PCI hardware that has two or more functions but no per-function
+ * reset, we can do a bus reset iff all the functions are co-assigned
+ * to the same domain.
+ *
+ * If a function has no per-function reset mechanism the 'reset' sysfs
+ * file that the toolstack uses to reset a function prior to assigning
+ * the device will be missing.  In this case, pciback adds its own
+ * which will try a bus reset.
+ *
+ * Note: pciback does not check for co-assigment before doing a bus
+ * reset, only that the devices are bound to pciback.  The toolstack
+ * is assumed to have done the right thing.
+ */
+static int __pcistub_reset_function(struct pci_dev *dev)
+{
+	struct pci_dev *pdev;
+	u16 ctrl;
+	int ret;
+
+	ret = __pci_reset_function_locked(dev);
+	if (ret == 0)
+		return 0;
+
+	if (pci_is_root_bus(dev->bus) || dev->subordinate || !dev->bus->self)
+		return -ENOTTY;
+
+	list_for_each_entry(pdev, &dev->bus->devices, bus_list) {
+		if (pdev != dev && (!pdev->driver
+				    || strcmp(pdev->driver->name, "pciback")))
+			return -ENOTTY;
+		pci_save_state(pdev);
+	}
+
+	pci_read_config_word(dev->bus->self, PCI_BRIDGE_CONTROL, &ctrl);
+	ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
+	pci_write_config_word(dev->bus->self, PCI_BRIDGE_CONTROL, ctrl);
+	msleep(200);
+
+	ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
+	pci_write_config_word(dev->bus->self, PCI_BRIDGE_CONTROL, ctrl);
+	msleep(200);
+
+	list_for_each_entry(pdev, &dev->bus->devices, bus_list)
+		pci_restore_state(pdev);
+
+	return 0;
+}
+
+static int pcistub_reset_function(struct pci_dev *dev)
+{
+	int ret;
+
+	device_lock(&dev->dev);
+	ret = __pcistub_reset_function(dev);
+	device_unlock(&dev->dev);
+
+	return ret;
+}
+
+static ssize_t pcistub_reset_store(struct device *dev,
+				   struct device_attribute *attr,
+				   const char *buf, size_t count)
+{
+	struct pci_dev *pdev = to_pci_dev(dev);
+	unsigned long val;
+	ssize_t result = strict_strtoul(buf, 0, &val);
+
+	if (result < 0)
+		return result;
+
+	if (val != 1)
+		return -EINVAL;
+
+	result = pcistub_reset_function(pdev);
+	if (result < 0)
+		return result;
+	return count;
+}
+static DEVICE_ATTR(reset, 0200, NULL, pcistub_reset_store);
+
+static int pcistub_try_create_reset_file(struct pci_dev *pci)
+{
+	struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
+	struct device *dev = &pci->dev;
+	int ret;
+
+	/* Already have a per-function reset? */
+	if (pci_probe_reset_function(pci) == 0)
+		return 0;
+
+	ret = device_create_file(dev, &dev_attr_reset);
+	if (ret < 0)
+		return ret;
+	dev_data->created_reset_file = true;
+	return 0;
+}
+
+static void pcistub_remove_reset_file(struct pci_dev *pci)
+{
+	struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
+
+	if (dev_data && dev_data->created_reset_file)
+		device_remove_file(&pci->dev, &dev_attr_reset);
+}
+
 static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev)
 {
 	struct pcistub_device *psdev;
@@ -100,7 +209,8 @@ static void pcistub_device_release(struct kref *kref)
 	/* Call the reset function which does not take lock as this
 	 * is called from "unbind" which takes a device_lock mutex.
 	 */
-	__pci_reset_function_locked(dev);
+	__pcistub_reset_function(psdev->dev);
+
 	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
 		dev_dbg(&dev->dev, "Could not reload PCI state\n");
 	else
@@ -268,7 +378,7 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	/* This is OK - we are running from workqueue context
 	 * and want to inhibit the user from fiddling with 'reset'
 	 */
-	pci_reset_function(dev);
+	pcistub_reset_function(dev);
 	pci_restore_state(psdev->dev);
 
 	/* This disables the device. */
@@ -392,7 +502,7 @@ static int pcistub_init_device(struct pci_dev *dev)
 		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
 	else {
 		dev_dbg(&dev->dev, "resetting (FLR, D3, etc) the device\n");
-		__pci_reset_function_locked(dev);
+		__pcistub_reset_function(dev);
 		pci_restore_state(dev);
 	}
 	/* Now disable the device (this also ensures some private device
@@ -401,6 +511,10 @@ static int pcistub_init_device(struct pci_dev *dev)
 	dev_dbg(&dev->dev, "reset device\n");
 	xen_pcibk_reset_device(dev);
 
+	err = pcistub_try_create_reset_file(dev);
+	if (err < 0)
+		goto config_release;
+
 	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
 	return 0;
 
@@ -526,6 +640,8 @@ static void pcistub_remove(struct pci_dev *dev)
 
 	dev_dbg(&dev->dev, "removing\n");
 
+	pcistub_remove_reset_file(dev);
+
 	spin_lock_irqsave(&pcistub_devices_lock, flags);
 
 	xen_pcibk_config_quirk_release(dev);
diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
index f72af87..708ade9 100644
--- a/drivers/xen/xen-pciback/pciback.h
+++ b/drivers/xen/xen-pciback/pciback.h
@@ -42,6 +42,7 @@ struct xen_pcibk_device {
 struct xen_pcibk_dev_data {
 	struct list_head config_fields;
 	struct pci_saved_state *pci_saved_state;
+	bool created_reset_file;
 	unsigned int permissive:1;
 	unsigned int warned_on_write:1;
 	unsigned int enable_intx:1;

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

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

--------------040006050709030007030805--


From xen-devel-bounces@lists.xen.org Thu Dec 04 12:25:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12: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 1XwVTL-00023i-Kv; Thu, 04 Dec 2014 12:25:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XwVTK-00023Y-Aq
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 12:25:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	39/F7-15461-5B250845; Thu, 04 Dec 2014 12:25:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417695922!13418215!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 24488 invoked from network); 4 Dec 2014 12:25:23 -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 Dec 2014 12:25:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; 
	d="scan'208,223";a="200035145"
Message-ID: <5480528F.8010106@citrix.com>
Date: Thu, 4 Dec 2014 12:24:47 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, David Vrabel
	<david.vrabel@citrix.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
In-Reply-To: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
Content-Type: multipart/mixed; boundary="------------040006050709030007030805"
X-DLP: MIA2
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------040006050709030007030805
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
> 
> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>
>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>
>>> Instead of doing all this complex dance, we depend on the toolstack 
>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>> It bypasses the need to worry about the PCI lock. 
>>
>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>> proposed). 
>>
> 
> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).

It is only needed if the core won't provide one.

+static int pcistub_try_create_reset_file(struct pci_dev *pci)
+{
+       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
+       struct device *dev = &pci->dev;
+       int ret;
+
+       /* Already have a per-function reset? */
+       if (pci_probe_reset_function(pci) == 0)
+               return 0;
+
+       ret = device_create_file(dev, &dev_attr_reset);
+       if (ret < 0)
+               return ret;
+       dev_data->created_reset_file = true;
+       return 0;
+}

David



--------------040006050709030007030805
Content-Type: text/x-diff;
	name="0002-xen-pciback-provide-a-reset-sysfs-file-to-try-harder.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename*0="0002-xen-pciback-provide-a-reset-sysfs-file-to-try-harder.pa";
	filename*1="tch"

>From e65a814106bc9994ec47b5317f7cdc975270d27f Mon Sep 17 00:00:00 2001
From: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 10 Jul 2014 13:09:25 +0100
Subject: [PATCH 2/2] xen-pciback: provide a "reset" sysfs file to try harder
 at an SBR

The standard implementation of pci_reset_function() does not try an
SBR if there are other sibling devices.  This is a common
configuration for multi-function devices (e.g., GPUs with a HDMI audio
device function).

If all the functions are co-assigned to the same domain at the same
time, then it is safe to perform an SBR to reset all functions at the
same time.

Add a "reset" sysfs file with the same interface as the standard one
(i.e., write 1 to reset) that will try an SBR if all sibling devices
are unbound or bound to pciback.

Note that this is weaker than the requirement for functions to be
simultaneously co-assigned, but the toolstack is expected to ensure
this.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 4e8ba38..d6c29aa 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -14,6 +14,7 @@
 #include <linux/wait.h>
 #include <linux/sched.h>
 #include <linux/atomic.h>
+#include <linux/delay.h>
 #include <xen/events.h>
 #include <asm/xen/pci.h>
 #include <asm/xen/hypervisor.h>
@@ -60,6 +61,114 @@ static LIST_HEAD(pcistub_devices);
 static int initialize_devices;
 static LIST_HEAD(seized_devices);
 
+/*
+ * pci_reset_function() will only work if there is a mechanism to
+ * reset that single function (e.g., FLR or a D-state transition).
+ * For PCI hardware that has two or more functions but no per-function
+ * reset, we can do a bus reset iff all the functions are co-assigned
+ * to the same domain.
+ *
+ * If a function has no per-function reset mechanism the 'reset' sysfs
+ * file that the toolstack uses to reset a function prior to assigning
+ * the device will be missing.  In this case, pciback adds its own
+ * which will try a bus reset.
+ *
+ * Note: pciback does not check for co-assigment before doing a bus
+ * reset, only that the devices are bound to pciback.  The toolstack
+ * is assumed to have done the right thing.
+ */
+static int __pcistub_reset_function(struct pci_dev *dev)
+{
+	struct pci_dev *pdev;
+	u16 ctrl;
+	int ret;
+
+	ret = __pci_reset_function_locked(dev);
+	if (ret == 0)
+		return 0;
+
+	if (pci_is_root_bus(dev->bus) || dev->subordinate || !dev->bus->self)
+		return -ENOTTY;
+
+	list_for_each_entry(pdev, &dev->bus->devices, bus_list) {
+		if (pdev != dev && (!pdev->driver
+				    || strcmp(pdev->driver->name, "pciback")))
+			return -ENOTTY;
+		pci_save_state(pdev);
+	}
+
+	pci_read_config_word(dev->bus->self, PCI_BRIDGE_CONTROL, &ctrl);
+	ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
+	pci_write_config_word(dev->bus->self, PCI_BRIDGE_CONTROL, ctrl);
+	msleep(200);
+
+	ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
+	pci_write_config_word(dev->bus->self, PCI_BRIDGE_CONTROL, ctrl);
+	msleep(200);
+
+	list_for_each_entry(pdev, &dev->bus->devices, bus_list)
+		pci_restore_state(pdev);
+
+	return 0;
+}
+
+static int pcistub_reset_function(struct pci_dev *dev)
+{
+	int ret;
+
+	device_lock(&dev->dev);
+	ret = __pcistub_reset_function(dev);
+	device_unlock(&dev->dev);
+
+	return ret;
+}
+
+static ssize_t pcistub_reset_store(struct device *dev,
+				   struct device_attribute *attr,
+				   const char *buf, size_t count)
+{
+	struct pci_dev *pdev = to_pci_dev(dev);
+	unsigned long val;
+	ssize_t result = strict_strtoul(buf, 0, &val);
+
+	if (result < 0)
+		return result;
+
+	if (val != 1)
+		return -EINVAL;
+
+	result = pcistub_reset_function(pdev);
+	if (result < 0)
+		return result;
+	return count;
+}
+static DEVICE_ATTR(reset, 0200, NULL, pcistub_reset_store);
+
+static int pcistub_try_create_reset_file(struct pci_dev *pci)
+{
+	struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
+	struct device *dev = &pci->dev;
+	int ret;
+
+	/* Already have a per-function reset? */
+	if (pci_probe_reset_function(pci) == 0)
+		return 0;
+
+	ret = device_create_file(dev, &dev_attr_reset);
+	if (ret < 0)
+		return ret;
+	dev_data->created_reset_file = true;
+	return 0;
+}
+
+static void pcistub_remove_reset_file(struct pci_dev *pci)
+{
+	struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
+
+	if (dev_data && dev_data->created_reset_file)
+		device_remove_file(&pci->dev, &dev_attr_reset);
+}
+
 static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev)
 {
 	struct pcistub_device *psdev;
@@ -100,7 +209,8 @@ static void pcistub_device_release(struct kref *kref)
 	/* Call the reset function which does not take lock as this
 	 * is called from "unbind" which takes a device_lock mutex.
 	 */
-	__pci_reset_function_locked(dev);
+	__pcistub_reset_function(psdev->dev);
+
 	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
 		dev_dbg(&dev->dev, "Could not reload PCI state\n");
 	else
@@ -268,7 +378,7 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	/* This is OK - we are running from workqueue context
 	 * and want to inhibit the user from fiddling with 'reset'
 	 */
-	pci_reset_function(dev);
+	pcistub_reset_function(dev);
 	pci_restore_state(psdev->dev);
 
 	/* This disables the device. */
@@ -392,7 +502,7 @@ static int pcistub_init_device(struct pci_dev *dev)
 		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
 	else {
 		dev_dbg(&dev->dev, "resetting (FLR, D3, etc) the device\n");
-		__pci_reset_function_locked(dev);
+		__pcistub_reset_function(dev);
 		pci_restore_state(dev);
 	}
 	/* Now disable the device (this also ensures some private device
@@ -401,6 +511,10 @@ static int pcistub_init_device(struct pci_dev *dev)
 	dev_dbg(&dev->dev, "reset device\n");
 	xen_pcibk_reset_device(dev);
 
+	err = pcistub_try_create_reset_file(dev);
+	if (err < 0)
+		goto config_release;
+
 	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
 	return 0;
 
@@ -526,6 +640,8 @@ static void pcistub_remove(struct pci_dev *dev)
 
 	dev_dbg(&dev->dev, "removing\n");
 
+	pcistub_remove_reset_file(dev);
+
 	spin_lock_irqsave(&pcistub_devices_lock, flags);
 
 	xen_pcibk_config_quirk_release(dev);
diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
index f72af87..708ade9 100644
--- a/drivers/xen/xen-pciback/pciback.h
+++ b/drivers/xen/xen-pciback/pciback.h
@@ -42,6 +42,7 @@ struct xen_pcibk_device {
 struct xen_pcibk_dev_data {
 	struct list_head config_fields;
 	struct pci_saved_state *pci_saved_state;
+	bool created_reset_file;
 	unsigned int permissive:1;
 	unsigned int warned_on_write:1;
 	unsigned int enable_intx:1;

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

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

--------------040006050709030007030805--


From xen-devel-bounces@lists.xen.org Thu Dec 04 12:28:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12:28:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwVVl-0002Bi-6g; Thu, 04 Dec 2014 12:27:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XwVVj-0002Bb-74
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 12:27:55 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	10/41-28865-A4350845; Thu, 04 Dec 2014 12:27:54 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417696071!11547498!1
X-Originating-IP: [66.165.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 24070 invoked from network); 4 Dec 2014 12:27:52 -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;
	4 Dec 2014 12:27:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199682360"
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, 4 Dec 2014 07:27: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 1XwVUt-0003kh-B4;
	Thu, 04 Dec 2014 12:27:03 +0000
Date: Thu, 4 Dec 2014 12:26: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: <547F84D3.3090501@terremark.com>
Message-ID: <alpine.DEB.2.02.1412041226370.30971@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1412031818180.30971@kaball.uk.xensource.com>
	<547F84D3.3090501@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl_set_memory_target: only
 remove videoram from absolute targets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 3 Dec 2014, Don Slutz wrote:
> On 12/03/14 13:20, Stefano Stabellini wrote:
> > If the new target is relative to the current target, do not remove
> > videoram again: it has already been removed from the current target.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index de23fec..2aa83bd 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4741,13 +4741,17 @@ retry_transaction:
> >           goto out;
> >       }
> >   +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> > +                "%s/memory/videoram", dompath));
> > +    videoram = videoram_s ? atoi(videoram_s) : 0;
> > +
> >       if (relative) {
> >           if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
> >               new_target_memkb = 0;
> >           else
> >               new_target_memkb = current_target_memkb + target_memkb;
> >       } else
> > -        new_target_memkb = target_memkb;
> > +        new_target_memkb = target_memkb - videoram;
> >       if (new_target_memkb > memorykb) {
> >           LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> >                   "memory_dynamic_max must be less than or equal to"
> > @@ -4763,9 +4767,6 @@ retry_transaction:
> >           abort_transaction = 1;
> >           goto out;
> >       }
> > -    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> > -                "%s/memory/videoram", dompath));
> > -    videoram = videoram_s ? atoi(videoram_s) : 0;
> >         if (enforce) {
> >           memorykb = new_target_memkb;
> 
> Since new_target_memkb is now adjusted before this line, you
> need to change this to:
> 
>          memorykb = new_target_memkb + videoram;

You are right, I'll make the change.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 12:28:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12:28:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwVVl-0002Bi-6g; Thu, 04 Dec 2014 12:27:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1XwVVj-0002Bb-74
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 12:27:55 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	10/41-28865-A4350845; Thu, 04 Dec 2014 12:27:54 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417696071!11547498!1
X-Originating-IP: [66.165.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 24070 invoked from network); 4 Dec 2014 12:27:52 -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;
	4 Dec 2014 12:27:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199682360"
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, 4 Dec 2014 07:27: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 1XwVUt-0003kh-B4;
	Thu, 04 Dec 2014 12:27:03 +0000
Date: Thu, 4 Dec 2014 12:26: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: <547F84D3.3090501@terremark.com>
Message-ID: <alpine.DEB.2.02.1412041226370.30971@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1412031818180.30971@kaball.uk.xensource.com>
	<547F84D3.3090501@terremark.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony Perard <anthony.perard@citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl_set_memory_target: only
 remove videoram from absolute targets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 3 Dec 2014, Don Slutz wrote:
> On 12/03/14 13:20, Stefano Stabellini wrote:
> > If the new target is relative to the current target, do not remove
> > videoram again: it has already been removed from the current target.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index de23fec..2aa83bd 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4741,13 +4741,17 @@ retry_transaction:
> >           goto out;
> >       }
> >   +    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> > +                "%s/memory/videoram", dompath));
> > +    videoram = videoram_s ? atoi(videoram_s) : 0;
> > +
> >       if (relative) {
> >           if (target_memkb < 0 && abs(target_memkb) > current_target_memkb)
> >               new_target_memkb = 0;
> >           else
> >               new_target_memkb = current_target_memkb + target_memkb;
> >       } else
> > -        new_target_memkb = target_memkb;
> > +        new_target_memkb = target_memkb - videoram;
> >       if (new_target_memkb > memorykb) {
> >           LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> >                   "memory_dynamic_max must be less than or equal to"
> > @@ -4763,9 +4767,6 @@ retry_transaction:
> >           abort_transaction = 1;
> >           goto out;
> >       }
> > -    videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
> > -                "%s/memory/videoram", dompath));
> > -    videoram = videoram_s ? atoi(videoram_s) : 0;
> >         if (enforce) {
> >           memorykb = new_target_memkb;
> 
> Since new_target_memkb is now adjusted before this line, you
> need to change this to:
> 
>          memorykb = new_target_memkb + videoram;

You are right, I'll make the change.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 12:58:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwVzR-0002yK-05; Thu, 04 Dec 2014 12:58:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XwVzP-0002yF-IO
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 12:58:35 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	94/94-22737-A7A50845; Thu, 04 Dec 2014 12:58:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417697912!11531731!1
X-Originating-IP: [66.165.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 22144 invoked from network); 4 Dec 2014 12:58:33 -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;
	4 Dec 2014 12:58:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200050207"
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, 4 Dec 2014 07:58:31 -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
	1XwVzL-0004NZ-6V; Thu, 04 Dec 2014 12:58:31 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 4 Dec 2014 12:58:30 +0000
Message-ID: <1417697910-19824-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>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH for-4.5] x86/stack: Avoid peeking into unmapped
	guard pages when dumping Xens stack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently, Xens stack tracing and dumping of its own stacks will always
attempt to continue to the top of the primary stack.  While this is fine for
99% of cases, it is incorrect when the stack pointer starts on an IST stack.

In particular, the stack analysis functions will wander up from the IST
stacks, through the syscall trampolines and then onto the primary stack.  If
MEMORY_GUARD is enabled, this will cause a pagefault when attempting to read
from the guard page.  Being an unhandled hypervisor fault, the pagefault
handler will then attempt to dump the stacks, and fall over the same problem.

This change introduces more finegrained knowledge of the cpu stack layouts,
and introduces different boundaries for whether the stack pointer is on an IST
stack or the primary stack.  Stack analysis starting from an IST stack will
now never exceed the stack they start on, and specifically not spill over into
an adjacent IST stack, or the syscall trampoline area.

A sample now looks like:
(XEN) '1' pressed -> testing mce stack printing
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82d08019196b>] check_mce_test+0xb/0x20
(XEN) RFLAGS: 0000000000010002   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff82d0802caf58   rcx: 0000000000000000
(XEN) rdx: ffff82d080235d20   rsi: 000000000000000a   rdi: ffff82d0802caf58
(XEN) rbp: 0000000000000031   rsp: ffff82d0802caf40   r8:  ffff83007faf4000
(XEN) r9:  0000000000004000   r10: 0000000000000001   r11: 0000000000000006
(XEN) r12: ffff82d0802cfe58   r13: ffff82d0802cfe58   r14: dead0000c0de0000
(XEN) r15: ffff82d080191910   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000062565000   cr2: 00007fb98a5e8fe8
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff82d0802caf40:
(XEN)    ffff82d0801ad119 ffff82d080278da0 ffff82d080227907 ffff82d080191910
(XEN)    dead0000c0de0000 ffff82d0802cfe58 ffff82d0802cfe58 0000000000000031
(XEN)    ffff82d080278da0 0000000000000006 0000000000000001 0000000000004000
(XEN)    ffff83007faf4000 ffff82d0803101a0 0000000000000000 ffff82d0802c8000
(XEN)    000000000000000a ffff82d080277620 0000001200000000 ffff82d08018ae6a
(XEN)    000000000000e008 0000000000000292 ffff82d0802cfd18 000000000000e010
(XEN) Xen call trace:
(XEN)    [<ffff82d08019196b>] check_mce_test+0xb/0x20
(XEN)    [<ffff82d0801ad119>] do_machine_check+0x9/0x20
(XEN)    [<ffff82d080227907>] handle_ist_exception+0x8d/0xf6
(XEN)

In this test case, %r15 is deliberately set up with a function pointer in an
attempt to fool the naive stack trace algorithm.

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 was discovered as a one-off by XenServer automated testing where a server
had been woken straight from mwait with an MCE, then suffered an NMI watchdog
timeout while waiting for the mce_logout_lock.  Given no printk() from any
other cpus, and a reset while transitioning into the crash kernel, there is
sadly no more analysis which can be performed at this stage.

The stack trace produces for this issue ended up picking out everything
looking like a function return pointer across 6 pages of stack, leading to a
very confusing call trace.

Konrad: I am requesting a release ack for this change.  It aids the clarity of
certain crash information, and prevents cascade pagefaults in certain
circumstances, which would prevent execution of the crash kernel or a system
reboot.
---
 xen/arch/x86/traps.c          |   83 ++++++++++++++++++++++++++++++++++++++---
 xen/include/asm-x86/current.h |   33 +++++++++++++---
 2 files changed, 104 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 10fc2ca..e008295 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -193,6 +193,76 @@ static void show_guest_stack(struct vcpu *v, const struct cpu_user_regs *regs)
     printk("\n");
 }
 
+/*
+ * Notes for get_stack_trace_bottom() and get_stack_dump_bottom()
+ *
+ * Stack pages 0, 1 and 2:
+ *   These are all 1-page IST stacks.  Each of these stacks have an exception
+ *   frame and saved register state at the top.  The interesting bound for a
+ *   trace is the word adjacent to this, while the bound for a dump is the
+ *   very top, including the exception frame.
+ *
+ * Stack pages 3, 4 and 5:
+ *   None of these are particularly interesting.  With MEMORY_GUARD, page 5 is
+ *   explicitly not present, so attempting to dump or trace it is
+ *   counterproductive.  Without MEMORY_GUARD, it is possible for a call chain
+ *   to use the entire primary stack and wander into page 5.  In this case,
+ *   consider these pages an extension of the primary stack to aid debugging
+ *   hopefully rare situations where the primary stack has effective been
+ *   overflown.
+ *
+ * Stack pages 6 and 7:
+ *   These form the primary stack, and have a cpu_info at the top.  For a
+ *   trace, the interesting bound is adjacent to the cpu_info, while for a
+ *   dump, the entire cpu_info is interesting.
+ *
+ * For the cases where the stack should not be inspected, pretend that the
+ * passed stack pointer is already out of reasonable bounds.
+ */
+unsigned long get_stack_trace_bottom(unsigned long sp)
+{
+    switch ( get_stack_page(sp) )
+    {
+    case 0 ... 2:
+        return ROUNDUP(sp, PAGE_SIZE) -
+            offsetof(struct cpu_user_regs, es) - sizeof(unsigned long);
+
+#ifndef MEMORY_GUARD
+    case 3 ... 5:
+#endif
+    case 6 ... 7:
+        return ROUNDUP(sp, STACK_SIZE) -
+            sizeof(struct cpu_info) - sizeof(unsigned long);
+
+#ifdef MEMORY_GUARD
+    case 3 ... 5:
+#endif
+    default:
+        return sp - sizeof(unsigned long);
+    }
+}
+
+unsigned long get_stack_dump_bottom(unsigned long sp)
+{
+    switch ( get_stack_page(sp) )
+    {
+    case 0 ... 2:
+        return ROUNDUP(sp, PAGE_SIZE) - sizeof(unsigned long);
+
+#ifndef MEMORY_GUARD
+    case 3 ... 5:
+#endif
+    case 6 ... 7:
+        return ROUNDUP(sp, STACK_SIZE) - sizeof(unsigned long);
+
+#ifdef MEMORY_GUARD
+    case 3 ... 5:
+#endif
+    default:
+        return sp - sizeof(unsigned long);
+    }
+}
+
 #if !defined(CONFIG_FRAME_POINTER)
 
 /*
@@ -203,7 +273,7 @@ static void show_guest_stack(struct vcpu *v, const struct cpu_user_regs *regs)
 static void _show_trace(unsigned long sp, unsigned long __maybe_unused bp)
 {
     unsigned long *stack = (unsigned long *)sp, addr;
-    unsigned long *bottom = (unsigned long *)get_printable_stack_bottom(sp);
+    unsigned long *bottom = (unsigned long *)get_stack_trace_bottom(sp);
 
     while ( stack <= bottom )
     {
@@ -221,7 +291,7 @@ static void _show_trace(unsigned long sp, unsigned long bp)
     unsigned long *frame, next, addr;
 
     /* Bounds for range of valid frame pointer. */
-    unsigned long low = sp, high = get_printable_stack_bottom(sp);
+    unsigned long low = sp, high = get_stack_trace_bottom(sp);
 
     /* The initial frame pointer. */
     next = bp;
@@ -292,7 +362,7 @@ static void show_trace(const struct cpu_user_regs *regs)
 
 void show_stack(const struct cpu_user_regs *regs)
 {
-    unsigned long *stack = ESP_BEFORE_EXCEPTION(regs), addr;
+    unsigned long *stack = ESP_BEFORE_EXCEPTION(regs), *stack_bottom, addr;
     int i;
 
     if ( guest_mode(regs) )
@@ -300,10 +370,11 @@ void show_stack(const struct cpu_user_regs *regs)
 
     printk("Xen stack trace from "__OP"sp=%p:\n  ", stack);
 
-    for ( i = 0; i < (debug_stack_lines*stack_words_per_line); i++ )
+    stack_bottom = _p(get_stack_dump_bottom(regs->rsp));
+
+    for ( i = 0; i < (debug_stack_lines*stack_words_per_line) &&
+              (stack <= stack_bottom); i++ )
     {
-        if ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) == 0 )
-            break;
         if ( (i != 0) && ((i % stack_words_per_line) == 0) )
             printk("\n  ");
         addr = *stack++;
diff --git a/xen/include/asm-x86/current.h b/xen/include/asm-x86/current.h
index b95fd79..f011d2d 100644
--- a/xen/include/asm-x86/current.h
+++ b/xen/include/asm-x86/current.h
@@ -12,6 +12,28 @@
 #include <public/xen.h>
 #include <asm/page.h>
 
+/*
+ * Xen's cpu stacks are 8 pages (8-page aligned), arranged as:
+ *
+ * 7 - Primary stack (with a struct cpu_info at the top)
+ * 6 - Primary stack
+ * 5 - Optionally not preset (MEMORY_GUARD)
+ * 4 - unused
+ * 3 - Syscall trampolines
+ * 2 - MCE IST stack
+ * 1 - NMI IST stack
+ * 0 - Double Fault IST stack
+ */
+
+/*
+ * Identify which stack page the stack pointer is on.  Returns an index
+ * as per the comment above.
+ */
+static inline unsigned int get_stack_page(unsigned long sp)
+{
+    return (sp & (STACK_SIZE-1)) >> PAGE_SHIFT;
+}
+
 struct vcpu;
 
 struct cpu_info {
@@ -51,13 +73,12 @@ static inline struct cpu_info *get_cpu_info(void)
     ((unsigned long)&get_cpu_info()->guest_cpu_user_regs.es)
 
 /*
- * Get the bottom-of-stack, as useful for printing stack traces.  This is the
- * highest word on the stack which might be part of a stack trace, and is the
- * adjacent word to a struct cpu_info on the stack.
+ * Get the reasonable stack bounds for stack traces and stack dumps.  Stack
+ * dumps have a slightly larger range to include exception frames in the
+ * printed information.  The returned word is inside the interesting range.
  */
-#define get_printable_stack_bottom(sp)          \
-    ((sp & (~(STACK_SIZE-1))) +                 \
-     (STACK_SIZE - sizeof(struct cpu_info) - sizeof(unsigned long)))
+unsigned long get_stack_trace_bottom(unsigned long sp);
+unsigned long get_stack_dump_bottom (unsigned long sp);
 
 #define reset_stack_and_jump(__fn)                                      \
     ({                                                                  \
-- 
1.7.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 Dec 04 12:58:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 12:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwVzR-0002yK-05; Thu, 04 Dec 2014 12:58:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XwVzP-0002yF-IO
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 12:58:35 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	94/94-22737-A7A50845; Thu, 04 Dec 2014 12:58:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417697912!11531731!1
X-Originating-IP: [66.165.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 22144 invoked from network); 4 Dec 2014 12:58:33 -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;
	4 Dec 2014 12:58:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200050207"
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, 4 Dec 2014 07:58:31 -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
	1XwVzL-0004NZ-6V; Thu, 04 Dec 2014 12:58:31 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Thu, 4 Dec 2014 12:58:30 +0000
Message-ID: <1417697910-19824-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>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH for-4.5] x86/stack: Avoid peeking into unmapped
	guard pages when dumping Xens stack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Currently, Xens stack tracing and dumping of its own stacks will always
attempt to continue to the top of the primary stack.  While this is fine for
99% of cases, it is incorrect when the stack pointer starts on an IST stack.

In particular, the stack analysis functions will wander up from the IST
stacks, through the syscall trampolines and then onto the primary stack.  If
MEMORY_GUARD is enabled, this will cause a pagefault when attempting to read
from the guard page.  Being an unhandled hypervisor fault, the pagefault
handler will then attempt to dump the stacks, and fall over the same problem.

This change introduces more finegrained knowledge of the cpu stack layouts,
and introduces different boundaries for whether the stack pointer is on an IST
stack or the primary stack.  Stack analysis starting from an IST stack will
now never exceed the stack they start on, and specifically not spill over into
an adjacent IST stack, or the syscall trampoline area.

A sample now looks like:
(XEN) '1' pressed -> testing mce stack printing
(XEN) ----[ Xen-4.5.0-rc  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82d08019196b>] check_mce_test+0xb/0x20
(XEN) RFLAGS: 0000000000010002   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff82d0802caf58   rcx: 0000000000000000
(XEN) rdx: ffff82d080235d20   rsi: 000000000000000a   rdi: ffff82d0802caf58
(XEN) rbp: 0000000000000031   rsp: ffff82d0802caf40   r8:  ffff83007faf4000
(XEN) r9:  0000000000004000   r10: 0000000000000001   r11: 0000000000000006
(XEN) r12: ffff82d0802cfe58   r13: ffff82d0802cfe58   r14: dead0000c0de0000
(XEN) r15: ffff82d080191910   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000062565000   cr2: 00007fb98a5e8fe8
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff82d0802caf40:
(XEN)    ffff82d0801ad119 ffff82d080278da0 ffff82d080227907 ffff82d080191910
(XEN)    dead0000c0de0000 ffff82d0802cfe58 ffff82d0802cfe58 0000000000000031
(XEN)    ffff82d080278da0 0000000000000006 0000000000000001 0000000000004000
(XEN)    ffff83007faf4000 ffff82d0803101a0 0000000000000000 ffff82d0802c8000
(XEN)    000000000000000a ffff82d080277620 0000001200000000 ffff82d08018ae6a
(XEN)    000000000000e008 0000000000000292 ffff82d0802cfd18 000000000000e010
(XEN) Xen call trace:
(XEN)    [<ffff82d08019196b>] check_mce_test+0xb/0x20
(XEN)    [<ffff82d0801ad119>] do_machine_check+0x9/0x20
(XEN)    [<ffff82d080227907>] handle_ist_exception+0x8d/0xf6
(XEN)

In this test case, %r15 is deliberately set up with a function pointer in an
attempt to fool the naive stack trace algorithm.

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 was discovered as a one-off by XenServer automated testing where a server
had been woken straight from mwait with an MCE, then suffered an NMI watchdog
timeout while waiting for the mce_logout_lock.  Given no printk() from any
other cpus, and a reset while transitioning into the crash kernel, there is
sadly no more analysis which can be performed at this stage.

The stack trace produces for this issue ended up picking out everything
looking like a function return pointer across 6 pages of stack, leading to a
very confusing call trace.

Konrad: I am requesting a release ack for this change.  It aids the clarity of
certain crash information, and prevents cascade pagefaults in certain
circumstances, which would prevent execution of the crash kernel or a system
reboot.
---
 xen/arch/x86/traps.c          |   83 ++++++++++++++++++++++++++++++++++++++---
 xen/include/asm-x86/current.h |   33 +++++++++++++---
 2 files changed, 104 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 10fc2ca..e008295 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -193,6 +193,76 @@ static void show_guest_stack(struct vcpu *v, const struct cpu_user_regs *regs)
     printk("\n");
 }
 
+/*
+ * Notes for get_stack_trace_bottom() and get_stack_dump_bottom()
+ *
+ * Stack pages 0, 1 and 2:
+ *   These are all 1-page IST stacks.  Each of these stacks have an exception
+ *   frame and saved register state at the top.  The interesting bound for a
+ *   trace is the word adjacent to this, while the bound for a dump is the
+ *   very top, including the exception frame.
+ *
+ * Stack pages 3, 4 and 5:
+ *   None of these are particularly interesting.  With MEMORY_GUARD, page 5 is
+ *   explicitly not present, so attempting to dump or trace it is
+ *   counterproductive.  Without MEMORY_GUARD, it is possible for a call chain
+ *   to use the entire primary stack and wander into page 5.  In this case,
+ *   consider these pages an extension of the primary stack to aid debugging
+ *   hopefully rare situations where the primary stack has effective been
+ *   overflown.
+ *
+ * Stack pages 6 and 7:
+ *   These form the primary stack, and have a cpu_info at the top.  For a
+ *   trace, the interesting bound is adjacent to the cpu_info, while for a
+ *   dump, the entire cpu_info is interesting.
+ *
+ * For the cases where the stack should not be inspected, pretend that the
+ * passed stack pointer is already out of reasonable bounds.
+ */
+unsigned long get_stack_trace_bottom(unsigned long sp)
+{
+    switch ( get_stack_page(sp) )
+    {
+    case 0 ... 2:
+        return ROUNDUP(sp, PAGE_SIZE) -
+            offsetof(struct cpu_user_regs, es) - sizeof(unsigned long);
+
+#ifndef MEMORY_GUARD
+    case 3 ... 5:
+#endif
+    case 6 ... 7:
+        return ROUNDUP(sp, STACK_SIZE) -
+            sizeof(struct cpu_info) - sizeof(unsigned long);
+
+#ifdef MEMORY_GUARD
+    case 3 ... 5:
+#endif
+    default:
+        return sp - sizeof(unsigned long);
+    }
+}
+
+unsigned long get_stack_dump_bottom(unsigned long sp)
+{
+    switch ( get_stack_page(sp) )
+    {
+    case 0 ... 2:
+        return ROUNDUP(sp, PAGE_SIZE) - sizeof(unsigned long);
+
+#ifndef MEMORY_GUARD
+    case 3 ... 5:
+#endif
+    case 6 ... 7:
+        return ROUNDUP(sp, STACK_SIZE) - sizeof(unsigned long);
+
+#ifdef MEMORY_GUARD
+    case 3 ... 5:
+#endif
+    default:
+        return sp - sizeof(unsigned long);
+    }
+}
+
 #if !defined(CONFIG_FRAME_POINTER)
 
 /*
@@ -203,7 +273,7 @@ static void show_guest_stack(struct vcpu *v, const struct cpu_user_regs *regs)
 static void _show_trace(unsigned long sp, unsigned long __maybe_unused bp)
 {
     unsigned long *stack = (unsigned long *)sp, addr;
-    unsigned long *bottom = (unsigned long *)get_printable_stack_bottom(sp);
+    unsigned long *bottom = (unsigned long *)get_stack_trace_bottom(sp);
 
     while ( stack <= bottom )
     {
@@ -221,7 +291,7 @@ static void _show_trace(unsigned long sp, unsigned long bp)
     unsigned long *frame, next, addr;
 
     /* Bounds for range of valid frame pointer. */
-    unsigned long low = sp, high = get_printable_stack_bottom(sp);
+    unsigned long low = sp, high = get_stack_trace_bottom(sp);
 
     /* The initial frame pointer. */
     next = bp;
@@ -292,7 +362,7 @@ static void show_trace(const struct cpu_user_regs *regs)
 
 void show_stack(const struct cpu_user_regs *regs)
 {
-    unsigned long *stack = ESP_BEFORE_EXCEPTION(regs), addr;
+    unsigned long *stack = ESP_BEFORE_EXCEPTION(regs), *stack_bottom, addr;
     int i;
 
     if ( guest_mode(regs) )
@@ -300,10 +370,11 @@ void show_stack(const struct cpu_user_regs *regs)
 
     printk("Xen stack trace from "__OP"sp=%p:\n  ", stack);
 
-    for ( i = 0; i < (debug_stack_lines*stack_words_per_line); i++ )
+    stack_bottom = _p(get_stack_dump_bottom(regs->rsp));
+
+    for ( i = 0; i < (debug_stack_lines*stack_words_per_line) &&
+              (stack <= stack_bottom); i++ )
     {
-        if ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) == 0 )
-            break;
         if ( (i != 0) && ((i % stack_words_per_line) == 0) )
             printk("\n  ");
         addr = *stack++;
diff --git a/xen/include/asm-x86/current.h b/xen/include/asm-x86/current.h
index b95fd79..f011d2d 100644
--- a/xen/include/asm-x86/current.h
+++ b/xen/include/asm-x86/current.h
@@ -12,6 +12,28 @@
 #include <public/xen.h>
 #include <asm/page.h>
 
+/*
+ * Xen's cpu stacks are 8 pages (8-page aligned), arranged as:
+ *
+ * 7 - Primary stack (with a struct cpu_info at the top)
+ * 6 - Primary stack
+ * 5 - Optionally not preset (MEMORY_GUARD)
+ * 4 - unused
+ * 3 - Syscall trampolines
+ * 2 - MCE IST stack
+ * 1 - NMI IST stack
+ * 0 - Double Fault IST stack
+ */
+
+/*
+ * Identify which stack page the stack pointer is on.  Returns an index
+ * as per the comment above.
+ */
+static inline unsigned int get_stack_page(unsigned long sp)
+{
+    return (sp & (STACK_SIZE-1)) >> PAGE_SHIFT;
+}
+
 struct vcpu;
 
 struct cpu_info {
@@ -51,13 +73,12 @@ static inline struct cpu_info *get_cpu_info(void)
     ((unsigned long)&get_cpu_info()->guest_cpu_user_regs.es)
 
 /*
- * Get the bottom-of-stack, as useful for printing stack traces.  This is the
- * highest word on the stack which might be part of a stack trace, and is the
- * adjacent word to a struct cpu_info on the stack.
+ * Get the reasonable stack bounds for stack traces and stack dumps.  Stack
+ * dumps have a slightly larger range to include exception frames in the
+ * printed information.  The returned word is inside the interesting range.
  */
-#define get_printable_stack_bottom(sp)          \
-    ((sp & (~(STACK_SIZE-1))) +                 \
-     (STACK_SIZE - sizeof(struct cpu_info) - sizeof(unsigned long)))
+unsigned long get_stack_trace_bottom(unsigned long sp);
+unsigned long get_stack_dump_bottom (unsigned long sp);
 
 #define reset_stack_and_jump(__fn)                                      \
     ({                                                                  \
-- 
1.7.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 Dec 04 13:03:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwW3h-0003Ct-TG; Thu, 04 Dec 2014 13:03:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwW3g-0003Ci-0U
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:03:00 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	7A/36-27785-38B50845; Thu, 04 Dec 2014 13:02:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417698176!12972473!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 15790 invoked from network); 4 Dec 2014 13:02:58 -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 Dec 2014 13:02:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200051958"
Message-ID: <1417698124.22808.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:02:04 +0000
In-Reply-To: <20141203155713.GD3081@laptop.dumpdata.com>
References: <1417596754-14063-1-git-send-email-olaf@aepfle.de>
	<20141203155713.GD3081@laptop.dumpdata.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] INSTALL: fix typo in xendomains.service name
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-12-03 at 10:57 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 03, 2014 at 09:52:34AM +0100, Olaf Hering wrote:
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> >  INSTALL | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> This being a doc it can go in anytime. thank you!

Acked + applied, thanks


> > 
> > diff --git a/INSTALL b/INSTALL
> > index 0bc67ea..71dd0eb 100644
> > --- a/INSTALL
> > +++ b/INSTALL
> > @@ -284,7 +284,7 @@ systemctl enable xen-init-dom0.service
> >  systemctl enable xenconsoled.service
> >  
> >  Other optional services are:
> > -systemctl enable xen-domains.service
> > +systemctl enable xendomains.service
> >  systemctl enable xen-watchdog.service
> >  
> >  



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:03:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwW3h-0003Ct-TG; Thu, 04 Dec 2014 13:03:01 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwW3g-0003Ci-0U
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:03:00 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	7A/36-27785-38B50845; Thu, 04 Dec 2014 13:02:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417698176!12972473!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 15790 invoked from network); 4 Dec 2014 13:02:58 -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 Dec 2014 13:02:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200051958"
Message-ID: <1417698124.22808.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:02:04 +0000
In-Reply-To: <20141203155713.GD3081@laptop.dumpdata.com>
References: <1417596754-14063-1-git-send-email-olaf@aepfle.de>
	<20141203155713.GD3081@laptop.dumpdata.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] INSTALL: fix typo in xendomains.service name
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-12-03 at 10:57 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 03, 2014 at 09:52:34AM +0100, Olaf Hering wrote:
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > ---
> >  INSTALL | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> This being a doc it can go in anytime. thank you!

Acked + applied, thanks


> > 
> > diff --git a/INSTALL b/INSTALL
> > index 0bc67ea..71dd0eb 100644
> > --- a/INSTALL
> > +++ b/INSTALL
> > @@ -284,7 +284,7 @@ systemctl enable xen-init-dom0.service
> >  systemctl enable xenconsoled.service
> >  
> >  Other optional services are:
> > -systemctl enable xen-domains.service
> > +systemctl enable xendomains.service
> >  systemctl enable xen-watchdog.service
> >  
> >  



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:03:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:03:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwW4Q-0003LM-Bf; Thu, 04 Dec 2014 13:03: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 1XwW4P-0003K8-1f
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:03:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E0/7E-09842-0BB50845; Thu, 04 Dec 2014 13:03:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417698222!13413003!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 25454 invoked from network); 4 Dec 2014 13:03:43 -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;
	4 Dec 2014 13:03:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199698422"
Message-ID: <1417698145.22808.29.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:02:25 +0000
In-Reply-To: <20141203162027.GG3081@laptop.dumpdata.com>
References: <1417603298-4213-1-git-send-email-wei.liu2@citrix.com>
	<1417603834.11243.9.camel@citrix.com>
	<20141203162027.GG3081@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>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: expose #define to 4.5 and
	above
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-03 at 11:20 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 03, 2014 at 10:50:34AM +0000, Ian Campbell wrote:
> > On Wed, 2014-12-03 at 10:41 +0000, Wei Liu wrote:
> > > In e3abab74 (libxl: un-constify return value of libxl_basename), the
> > > macro was exposed to releases < 4.5. However only new code is able to
> > > make use of that macro so it should be exposed to releases >= 4.5.
> > > 
> > > 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: Andrew Cooper <andrew.cooper3@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Konrad, given that the original patch is in 4.5 (as of yesterday) we
> > should obviously take this one too.
> 
> Right. 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 Thu Dec 04 13:03:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:03:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwW4Q-0003LM-Bf; Thu, 04 Dec 2014 13:03: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 1XwW4P-0003K8-1f
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:03:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E0/7E-09842-0BB50845; Thu, 04 Dec 2014 13:03:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417698222!13413003!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 25454 invoked from network); 4 Dec 2014 13:03:43 -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;
	4 Dec 2014 13:03:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199698422"
Message-ID: <1417698145.22808.29.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:02:25 +0000
In-Reply-To: <20141203162027.GG3081@laptop.dumpdata.com>
References: <1417603298-4213-1-git-send-email-wei.liu2@citrix.com>
	<1417603834.11243.9.camel@citrix.com>
	<20141203162027.GG3081@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>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] libxl: expose #define to 4.5 and
	above
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-03 at 11:20 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 03, 2014 at 10:50:34AM +0000, Ian Campbell wrote:
> > On Wed, 2014-12-03 at 10:41 +0000, Wei Liu wrote:
> > > In e3abab74 (libxl: un-constify return value of libxl_basename), the
> > > macro was exposed to releases < 4.5. However only new code is able to
> > > make use of that macro so it should be exposed to releases >= 4.5.
> > > 
> > > 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: Andrew Cooper <andrew.cooper3@citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Konrad, given that the original patch is in 4.5 (as of yesterday) we
> > should obviously take this one too.
> 
> Right. 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 Thu Dec 04 13:07:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwW7o-0003bC-VG; Thu, 04 Dec 2014 13: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 1XwW7n-0003b4-Nr
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:07:15 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	DD/FD-26858-38C50845; Thu, 04 Dec 2014 13:07:15 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417698432!7343141!1
X-Originating-IP: [66.165.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 18585 invoked from network); 4 Dec 2014 13:07:14 -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;
	4 Dec 2014 13:07:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199700975"
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, 4 Dec 2014 08:05: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 1XwW67-0004WT-53;
	Thu, 04 Dec 2014 13:05:31 +0000
Date: Thu, 4 Dec 2014 13:05:31 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141204130531.GD16532@zion.uk.xensource.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 12:09:33PM +0000, Zhangleiqiang (Trump) wrote:
[...]
> > > However, I find another issue. Even using 6 queues and making sure
> > > that all of these 6 netback processes running with high cpu usage
> > > (indeed, any of it running with 87% cpu usage), the whole VM receive
> > > throughout is not very higher than results when using 4 queues. The
> > > results are from 4.5Gbps to 5.04 Gbps using TCP with 512 bytes length
> > > and 4.3Gbps to 5.78Gbps using TCP with 1460 bytes length.
> > >
> > 
> > I would like to ask if you're still using 4U4G (4 CPU 4 G?) configuration? If so,
> > please make sure there are at least the same number of vcpus as queues.
> 

> Sorry for misleading you, 4U4G means 4 CPU and 4 G memory, :). I also
> found that the max_queue of netback is determinated by min(online_cpu,
> module_param) yesterday, so when using 6 queues in the previous
> testing, I used VM with 6 CPU and 6 G Memory.

> 
> > > According to the testing result from WIKI:
> > > http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_perf
> > > ormance_testing, The VM receive throughput is also more lower than VM
> > > transmit.
> > >
> > 
> > I think that's expected, because guest RX data path still uses grant_copy while
> > guest TX uses grant_map to do zero-copy transmit.
> 
> As I understand, the RX process is as follows: 
> 1. Phy NIC receive packet
> 2. XEN Hypervisor trigger interrupt to Dom0
> 3. Dom0' s NIC driver do the "RX" operation, and the packet is stored into SKB which is also owned/shared with netback
> 4. NetBack notify netfront through event channel that a packet is receiving
> 5. Netfront grant a buffer for receiving and notify netback the GR (if using grant-resue mechanism, netfront just notify the GR to netback) through IO Ring
> 6. NetBack do the grant_copy to copy packet from its SKB to the buffer referenced by GR, and notify netfront through event channel
> 7. Netfront copy the data from buffer to user-level app's SKB
> 
> Am I right?

Step 4 is not correct, netback won't notify netfront at that point.

Step 5 is not correct, all grant refs are pre-allocated and
granted before that.

Other steps look correct.

> Why not using zero-copy transmit in guest RX data pash too ?
> 

A rogue / buggy guest might hold the mapping for arbitrary long period
of time.

> 
> > > I am wondering why the VM receive throughout cannot be up to 8-10Gbps
> > > as VM transmit under multi-queue?  I also tried to send packets
> > > directly from Local Dom0 to DomU, the DomU receive throughput can
> > > reach about 8-12Gbps, so I am also wondering why transmitting packets
> > > from Dom0 to Remote DomU can only reach about 4-5Gbps throughout?
> > 
> > If data is from Dom0 to DomU then SKB is probably not fragmented by network
> > stack.  You can use tcpdump to check that.
> 
> In our testing , the MTU is set to 1600. However, even testing with
> packets whose length are 1024 (small than 1600), the throughout
> between Dom0 to Local DomU is more higher than that between Dom0 to
> Remote DomU. So maybe the fragment is not the reason for it.
> 

Don't have much idea about this, sorry.

Wei.

> 
> > Wei.
> > 
> > >
> > > > Wei.
> > > >
> > > > > ----------
> > > > > zhangleiqiang (Trump)
> > > > >
> > > > > Best Regards
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > > > > Sent: Tuesday, December 02, 2014 8:12 PM
> > > > > > To: Zhangleiqiang (Trump)
> > > > > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao
> > > > > > (brian); Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > > > > Subject: Re: [Xen-devel] Poor network performance between DomU
> > > > > > with multiqueue support
> > > > > >
> > > > > > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump)
> > wrote:
> > > > > > > > -----Original Message-----
> > > > > > > > From: xen-devel-bounces@lists.xen.org
> > > > > > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei
> > > > > > > > Liu
> > > > > > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > > > > > To: zhangleiqiang
> > > > > > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > > > > > Subject: Re: [Xen-devel] Poor network performance between
> > > > > > > > DomU with multiqueue support
> > > > > > > >
> > > > > > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > > > > > > Hi, all
> > > > > > > > >     I am testing the performance of xen netfront-netback
> > > > > > > > > driver that with
> > > > > > > > multi-queues support. The throughput from domU to remote
> > > > > > > > dom0 is 9.2Gb/s, but the throughput from domU to remote domU
> > > > > > > > is only 3.6Gb/s, I think the bottleneck is the throughput
> > > > > > > > from dom0 to local domU. However, we have done some testing
> > > > > > > > and found the throughput from dom0 to local domU is 5.8Gb/s.
> > > > > > > > >     And if we send packets from one DomU to other 3 DomUs
> > > > > > > > > on different
> > > > > > > > host simultaneously, the sum of throughout can reach 9Gbps.
> > > > > > > > It seems like the bottleneck is the receiver?
> > > > > > > > >     After some analysis, I found that even the max_queue
> > > > > > > > > of netfront/back
> > > > > > > > is set to 4, there are some strange results as follows:
> > > > > > > > >     1. In domU, only one rx queue deal with softirq
> > > > > > > >
> > > > > > > > Try to bind irq to different vcpus?
> > > > > > >
> > > > > > > Do you mean we try to bind irq to different vcpus in DomU? I
> > > > > > > will try it
> > > > now.
> > > > > > >
> > > > > >
> > > > > > Yes. Given the fact that you have two backend threads running
> > > > > > while only one DomU vcpu is busy, it smells like misconfiguration in
> > DomU.
> > > > > >
> > > > > > If this phenomenon persists after correctly binding irqs, you
> > > > > > might want to check traffic is steering correctly to different queues.
> > > > > >
> > > > > > > >
> > > > > > > > >     2. In dom0, only two netback queues process are
> > > > > > > > > scheduled, other two
> > > > > > > > process aren't scheduled.
> > > > > > > >
> > > > > > > > How many Dom0 vcpu do you have? If it only has two then
> > > > > > > > there will only be two processes running at a time.
> > > > > > >
> > > > > > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU
> > > > > > > running in
> > > > > > Dom0 and so four netback processes are running in Dom0 (because
> > > > > > the max_queue param of netback kernel module is set to 4).
> > > > > > > The phenomenon is that only 2 of these four netback process
> > > > > > > were running
> > > > > > with about 70% cpu usage, and another two use little CPU.
> > > > > > > Is there a hash algorithm to determine which netback process
> > > > > > > to handle the
> > > > > > input packet?
> > > > > > >
> > > > > >
> > > > > > I think that's whatever default algorithm Linux kernel is using.
> > > > > >
> > > > > > We don't currently support other algorithms.
> > > > > >
> > > > > > Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:07:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwW7o-0003bC-VG; Thu, 04 Dec 2014 13: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 1XwW7n-0003b4-Nr
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:07:15 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	DD/FD-26858-38C50845; Thu, 04 Dec 2014 13:07:15 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417698432!7343141!1
X-Originating-IP: [66.165.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 18585 invoked from network); 4 Dec 2014 13:07:14 -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;
	4 Dec 2014 13:07:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199700975"
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, 4 Dec 2014 08:05: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 1XwW67-0004WT-53;
	Thu, 04 Dec 2014 13:05:31 +0000
Date: Thu, 4 Dec 2014 13:05:31 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141204130531.GD16532@zion.uk.xensource.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 12:09:33PM +0000, Zhangleiqiang (Trump) wrote:
[...]
> > > However, I find another issue. Even using 6 queues and making sure
> > > that all of these 6 netback processes running with high cpu usage
> > > (indeed, any of it running with 87% cpu usage), the whole VM receive
> > > throughout is not very higher than results when using 4 queues. The
> > > results are from 4.5Gbps to 5.04 Gbps using TCP with 512 bytes length
> > > and 4.3Gbps to 5.78Gbps using TCP with 1460 bytes length.
> > >
> > 
> > I would like to ask if you're still using 4U4G (4 CPU 4 G?) configuration? If so,
> > please make sure there are at least the same number of vcpus as queues.
> 

> Sorry for misleading you, 4U4G means 4 CPU and 4 G memory, :). I also
> found that the max_queue of netback is determinated by min(online_cpu,
> module_param) yesterday, so when using 6 queues in the previous
> testing, I used VM with 6 CPU and 6 G Memory.

> 
> > > According to the testing result from WIKI:
> > > http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_perf
> > > ormance_testing, The VM receive throughput is also more lower than VM
> > > transmit.
> > >
> > 
> > I think that's expected, because guest RX data path still uses grant_copy while
> > guest TX uses grant_map to do zero-copy transmit.
> 
> As I understand, the RX process is as follows: 
> 1. Phy NIC receive packet
> 2. XEN Hypervisor trigger interrupt to Dom0
> 3. Dom0' s NIC driver do the "RX" operation, and the packet is stored into SKB which is also owned/shared with netback
> 4. NetBack notify netfront through event channel that a packet is receiving
> 5. Netfront grant a buffer for receiving and notify netback the GR (if using grant-resue mechanism, netfront just notify the GR to netback) through IO Ring
> 6. NetBack do the grant_copy to copy packet from its SKB to the buffer referenced by GR, and notify netfront through event channel
> 7. Netfront copy the data from buffer to user-level app's SKB
> 
> Am I right?

Step 4 is not correct, netback won't notify netfront at that point.

Step 5 is not correct, all grant refs are pre-allocated and
granted before that.

Other steps look correct.

> Why not using zero-copy transmit in guest RX data pash too ?
> 

A rogue / buggy guest might hold the mapping for arbitrary long period
of time.

> 
> > > I am wondering why the VM receive throughout cannot be up to 8-10Gbps
> > > as VM transmit under multi-queue?  I also tried to send packets
> > > directly from Local Dom0 to DomU, the DomU receive throughput can
> > > reach about 8-12Gbps, so I am also wondering why transmitting packets
> > > from Dom0 to Remote DomU can only reach about 4-5Gbps throughout?
> > 
> > If data is from Dom0 to DomU then SKB is probably not fragmented by network
> > stack.  You can use tcpdump to check that.
> 
> In our testing , the MTU is set to 1600. However, even testing with
> packets whose length are 1024 (small than 1600), the throughout
> between Dom0 to Local DomU is more higher than that between Dom0 to
> Remote DomU. So maybe the fragment is not the reason for it.
> 

Don't have much idea about this, sorry.

Wei.

> 
> > Wei.
> > 
> > >
> > > > Wei.
> > > >
> > > > > ----------
> > > > > zhangleiqiang (Trump)
> > > > >
> > > > > Best Regards
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > > > > Sent: Tuesday, December 02, 2014 8:12 PM
> > > > > > To: Zhangleiqiang (Trump)
> > > > > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao
> > > > > > (brian); Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > > > > Subject: Re: [Xen-devel] Poor network performance between DomU
> > > > > > with multiqueue support
> > > > > >
> > > > > > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump)
> > wrote:
> > > > > > > > -----Original Message-----
> > > > > > > > From: xen-devel-bounces@lists.xen.org
> > > > > > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei
> > > > > > > > Liu
> > > > > > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > > > > > To: zhangleiqiang
> > > > > > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > > > > > Subject: Re: [Xen-devel] Poor network performance between
> > > > > > > > DomU with multiqueue support
> > > > > > > >
> > > > > > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > > > > > > Hi, all
> > > > > > > > >     I am testing the performance of xen netfront-netback
> > > > > > > > > driver that with
> > > > > > > > multi-queues support. The throughput from domU to remote
> > > > > > > > dom0 is 9.2Gb/s, but the throughput from domU to remote domU
> > > > > > > > is only 3.6Gb/s, I think the bottleneck is the throughput
> > > > > > > > from dom0 to local domU. However, we have done some testing
> > > > > > > > and found the throughput from dom0 to local domU is 5.8Gb/s.
> > > > > > > > >     And if we send packets from one DomU to other 3 DomUs
> > > > > > > > > on different
> > > > > > > > host simultaneously, the sum of throughout can reach 9Gbps.
> > > > > > > > It seems like the bottleneck is the receiver?
> > > > > > > > >     After some analysis, I found that even the max_queue
> > > > > > > > > of netfront/back
> > > > > > > > is set to 4, there are some strange results as follows:
> > > > > > > > >     1. In domU, only one rx queue deal with softirq
> > > > > > > >
> > > > > > > > Try to bind irq to different vcpus?
> > > > > > >
> > > > > > > Do you mean we try to bind irq to different vcpus in DomU? I
> > > > > > > will try it
> > > > now.
> > > > > > >
> > > > > >
> > > > > > Yes. Given the fact that you have two backend threads running
> > > > > > while only one DomU vcpu is busy, it smells like misconfiguration in
> > DomU.
> > > > > >
> > > > > > If this phenomenon persists after correctly binding irqs, you
> > > > > > might want to check traffic is steering correctly to different queues.
> > > > > >
> > > > > > > >
> > > > > > > > >     2. In dom0, only two netback queues process are
> > > > > > > > > scheduled, other two
> > > > > > > > process aren't scheduled.
> > > > > > > >
> > > > > > > > How many Dom0 vcpu do you have? If it only has two then
> > > > > > > > there will only be two processes running at a time.
> > > > > > >
> > > > > > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU
> > > > > > > running in
> > > > > > Dom0 and so four netback processes are running in Dom0 (because
> > > > > > the max_queue param of netback kernel module is set to 4).
> > > > > > > The phenomenon is that only 2 of these four netback process
> > > > > > > were running
> > > > > > with about 70% cpu usage, and another two use little CPU.
> > > > > > > Is there a hash algorithm to determine which netback process
> > > > > > > to handle the
> > > > > > input packet?
> > > > > > >
> > > > > >
> > > > > > I think that's whatever default algorithm Linux kernel is using.
> > > > > >
> > > > > > We don't currently support other algorithms.
> > > > > >
> > > > > > Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:11:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:11:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWBS-0003jM-JU; Thu, 04 Dec 2014 13:11:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XwWBR-0003jG-KH
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 13:11:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	78/FE-25276-56D50845; Thu, 04 Dec 2014 13:11:01 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417698658!13415587!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26547 invoked from network); 4 Dec 2014 13:10:58 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 4 Dec 2014 13:10:58 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52238 helo=w510-wired)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XwW8T-0000WS-Ne; Thu, 04 Dec 2014 14:07:57 +0100
Date: Thu, 4 Dec 2014 14:10:54 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1107877503.20141204141054@eikelenboom.it>
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <5480528F.8010106@citrix.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
MIME-Version: 1.0
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
	slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 4, 2014, 1:24:47 PM, you wrote:

> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>> 
>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>
>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>>
>>>> Instead of doing all this complex dance, we depend on the toolstack 
>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>>> It bypasses the need to worry about the PCI lock. 
>>>
>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>>> proposed). 
>>>
>> 
>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).

> It is only needed if the core won't provide one.

> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
> +{
> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
> +       struct device *dev = &pci->dev;
> +       int ret;
> +
> +       /* Already have a per-function reset? */
> +       if (pci_probe_reset_function(pci) == 0)
> +               return 0;
> +
> +       ret = device_create_file(dev, &dev_attr_reset);
> +       if (ret < 0)
> +               return ret;
+       dev_data->>created_reset_file = true;
> +       return 0;
> +}

Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
"pci.c:__pci_dev_reset" ?

The problem with that function is that from my testing it seems that the 
first option "pci_dev_specific_reset" always seems to return succes, so all the
other options are skipped (flr, pm, slot, bus). However the device it self is 
not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
none virtualization purposes and it's probably the least intrusive. For 
virtualization however it would be nice to be sure it resets properly, or have a 
way to force a specific reset routine.) 

So it's the ordering and skipping of the other resets that seems to make
this workaround necessary in the first place.

> David






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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:11:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:11:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWBS-0003jM-JU; Thu, 04 Dec 2014 13:11:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1XwWBR-0003jG-KH
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 13:11:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	78/FE-25276-56D50845; Thu, 04 Dec 2014 13:11:01 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417698658!13415587!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26547 invoked from network); 4 Dec 2014 13:10:58 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 4 Dec 2014 13:10:58 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52238 helo=w510-wired)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XwW8T-0000WS-Ne; Thu, 04 Dec 2014 14:07:57 +0100
Date: Thu, 4 Dec 2014 14:10:54 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1107877503.20141204141054@eikelenboom.it>
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <5480528F.8010106@citrix.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
MIME-Version: 1.0
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
	slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 4, 2014, 1:24:47 PM, you wrote:

> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>> 
>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>
>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>>
>>>> Instead of doing all this complex dance, we depend on the toolstack 
>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>>> It bypasses the need to worry about the PCI lock. 
>>>
>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>>> proposed). 
>>>
>> 
>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).

> It is only needed if the core won't provide one.

> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
> +{
> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
> +       struct device *dev = &pci->dev;
> +       int ret;
> +
> +       /* Already have a per-function reset? */
> +       if (pci_probe_reset_function(pci) == 0)
> +               return 0;
> +
> +       ret = device_create_file(dev, &dev_attr_reset);
> +       if (ret < 0)
> +               return ret;
+       dev_data->>created_reset_file = true;
> +       return 0;
> +}

Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
"pci.c:__pci_dev_reset" ?

The problem with that function is that from my testing it seems that the 
first option "pci_dev_specific_reset" always seems to return succes, so all the
other options are skipped (flr, pm, slot, bus). However the device it self is 
not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
none virtualization purposes and it's probably the least intrusive. For 
virtualization however it would be nice to be sure it resets properly, or have a 
way to force a specific reset routine.) 

So it's the ordering and skipping of the other resets that seems to make
this workaround necessary in the first place.

> David






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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:26:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWPy-0004B4-9n; Thu, 04 Dec 2014 13:26: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 1XwWPw-0004Ax-Cz
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 13:26:00 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	8D/E7-08051-7E060845; Thu, 04 Dec 2014 13:25:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417699558!12978912!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 17401 invoked from network); 4 Dec 2014 13:25:59 -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 Dec 2014 13:25:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200063477"
Message-ID: <1417699555.22808.31.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Date: Thu, 4 Dec 2014 13:25:55 +0000
In-Reply-To: <1417533390-29035-3-git-send-email-daniel.kiper@oracle.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-3-git-send-email-daniel.kiper@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, keir@xen.org, ian.jackson@eu.citrix.com,
	jbeulich@suse.com, andrew.cooper3@citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 2/3] gitignore: ignore some
 files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 16:16 +0100, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

.gitignore updates seem harmless enough. so I've applied this and the
third patch. Awaiting Konrad's verdict on the first.

> ---
>  .gitignore |    3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index b24e905..2b51d5f 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -141,12 +141,15 @@ tools/flask/utils/flask-set-bool
>  tools/flask/utils/flask-label-pci
>  tools/hotplug/common/hotplugpath.sh
>  tools/hotplug/FreeBSD/rc.d/xencommons
> +tools/hotplug/Linux/init.d/sysconfig.xencommons
>  tools/hotplug/Linux/init.d/xen-watchdog
> +tools/hotplug/Linux/init.d/xencommons
>  tools/hotplug/Linux/init.d/xendomains
>  tools/hotplug/Linux/vif-setup
>  tools/hotplug/Linux/xen-backend.rules
>  tools/hotplug/Linux/xen-hotplug-common.sh
>  tools/hotplug/Linux/xendomains
> +tools/hotplug/NetBSD/rc.d/xencommons
>  tools/include/xen/*
>  tools/include/xen-foreign/*.(c|h|size)
>  tools/include/xen-foreign/checker



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:26:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWPh-0004AP-Gw; Thu, 04 Dec 2014 13:25:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwWPg-0004AK-IR
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:25:44 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	FF/BA-23865-7D060845; Thu, 04 Dec 2014 13:25:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417699541!11108063!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 20501 invoked from network); 4 Dec 2014 13:25:42 -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 Dec 2014 13:25:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199710237"
Message-ID: <1417699539.22808.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:25:39 +0000
In-Reply-To: <20141202204245.GO357@laptop.dumpdata.com>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141202204245.GO357@laptop.dumpdata.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>, Wei Liu <wei.liu2@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] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 15:42 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 06:51:50PM +0000, M A Young wrote:
> > On Tue, 2 Dec 2014, Konrad Rzeszutek Wilk wrote:
> > 
> > >On Tue, Dec 02, 2014 at 03:44:55PM +0000, Ian Campbell wrote:
> > >>On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
> > >>>Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
> > >>>systemd xenstored dependencies") all service files use the .socket unit
> > >>>as startup dependency. While this happens to work for boot it fails for
> > >>>shutdown because a .socket does not seem to enforce ordering. When
> > >>>xendomains.service runs during shutdown then systemd will stop
> > >>>xenstored.service at the same time.
> > >>>
> > >>>Change all "xenstored.socket" to "xenstored.service" to let systemd know
> > >>>that xenstored has to be shutdown after everything else.
> > >>>
> > >>>Reported-by: Mark Pryor <tlviewer@yahoo.com>
> > >>>Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > >>>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > >>>Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >>
> > >>Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > >>
> > >>>Cc: Wei Liu <wei.liu2@citrix.com>
> > >>>---
> > >>>
> > >>>This should go into 4.5 to fix xendomains.service.
> > >>
> > >>CCing Konrad...
> > >
> > >CC-ing Michael.
> > >
> > >Michael, since Fedora is using systemd, did you observe this bug as well?
> > >(I think I did, but I might have blamed it on my wacky setup).
> > 
> > I only tried the xen systemd on xen 4.5-rc2 and didn't have a lot of success
> > even when I reverted to Fedora's systemd for xen, so I can't really comment.
> 
> Ugh.
> > I did have issues with xen systemd which I shall report if they are still
> > there in -rc3.
> 
> OK, lets then go with this.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied, thanks.

> > 
> > 	Michael Young



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:26:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWPy-0004B4-9n; Thu, 04 Dec 2014 13:26: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 1XwWPw-0004Ax-Cz
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 13:26:00 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	8D/E7-08051-7E060845; Thu, 04 Dec 2014 13:25:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417699558!12978912!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 17401 invoked from network); 4 Dec 2014 13:25:59 -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 Dec 2014 13:25:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200063477"
Message-ID: <1417699555.22808.31.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Date: Thu, 4 Dec 2014 13:25:55 +0000
In-Reply-To: <1417533390-29035-3-git-send-email-daniel.kiper@oracle.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-3-git-send-email-daniel.kiper@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, keir@xen.org, ian.jackson@eu.citrix.com,
	jbeulich@suse.com, andrew.cooper3@citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 2/3] gitignore: ignore some
 files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 16:16 +0100, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

.gitignore updates seem harmless enough. so I've applied this and the
third patch. Awaiting Konrad's verdict on the first.

> ---
>  .gitignore |    3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index b24e905..2b51d5f 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -141,12 +141,15 @@ tools/flask/utils/flask-set-bool
>  tools/flask/utils/flask-label-pci
>  tools/hotplug/common/hotplugpath.sh
>  tools/hotplug/FreeBSD/rc.d/xencommons
> +tools/hotplug/Linux/init.d/sysconfig.xencommons
>  tools/hotplug/Linux/init.d/xen-watchdog
> +tools/hotplug/Linux/init.d/xencommons
>  tools/hotplug/Linux/init.d/xendomains
>  tools/hotplug/Linux/vif-setup
>  tools/hotplug/Linux/xen-backend.rules
>  tools/hotplug/Linux/xen-hotplug-common.sh
>  tools/hotplug/Linux/xendomains
> +tools/hotplug/NetBSD/rc.d/xencommons
>  tools/include/xen/*
>  tools/include/xen-foreign/*.(c|h|size)
>  tools/include/xen-foreign/checker



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:26:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWPh-0004AP-Gw; Thu, 04 Dec 2014 13:25:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwWPg-0004AK-IR
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:25:44 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	FF/BA-23865-7D060845; Thu, 04 Dec 2014 13:25:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417699541!11108063!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 20501 invoked from network); 4 Dec 2014 13:25:42 -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 Dec 2014 13:25:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199710237"
Message-ID: <1417699539.22808.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:25:39 +0000
In-Reply-To: <20141202204245.GO357@laptop.dumpdata.com>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141202204245.GO357@laptop.dumpdata.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>, Wei Liu <wei.liu2@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] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 15:42 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 06:51:50PM +0000, M A Young wrote:
> > On Tue, 2 Dec 2014, Konrad Rzeszutek Wilk wrote:
> > 
> > >On Tue, Dec 02, 2014 at 03:44:55PM +0000, Ian Campbell wrote:
> > >>On Tue, 2014-12-02 at 16:39 +0100, Olaf Hering wrote:
> > >>>Since commit 4542ae340d75bd6319e3fcd94e6c9336e210aeef ("tools/hotplug:
> > >>>systemd xenstored dependencies") all service files use the .socket unit
> > >>>as startup dependency. While this happens to work for boot it fails for
> > >>>shutdown because a .socket does not seem to enforce ordering. When
> > >>>xendomains.service runs during shutdown then systemd will stop
> > >>>xenstored.service at the same time.
> > >>>
> > >>>Change all "xenstored.socket" to "xenstored.service" to let systemd know
> > >>>that xenstored has to be shutdown after everything else.
> > >>>
> > >>>Reported-by: Mark Pryor <tlviewer@yahoo.com>
> > >>>Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > >>>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > >>>Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >>
> > >>Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > >>
> > >>>Cc: Wei Liu <wei.liu2@citrix.com>
> > >>>---
> > >>>
> > >>>This should go into 4.5 to fix xendomains.service.
> > >>
> > >>CCing Konrad...
> > >
> > >CC-ing Michael.
> > >
> > >Michael, since Fedora is using systemd, did you observe this bug as well?
> > >(I think I did, but I might have blamed it on my wacky setup).
> > 
> > I only tried the xen systemd on xen 4.5-rc2 and didn't have a lot of success
> > even when I reverted to Fedora's systemd for xen, so I can't really comment.
> 
> Ugh.
> > I did have issues with xen systemd which I shall report if they are still
> > there in -rc3.
> 
> OK, lets then go with this.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied, thanks.

> > 
> > 	Michael Young



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:26:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWQG-0004Db-Mh; Thu, 04 Dec 2014 13:26: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 1XwWQG-0004DO-6e
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:26:20 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	3F/66-02576-BF060845; Thu, 04 Dec 2014 13:26:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417699577!12996115!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9650 invoked from network); 4 Dec 2014 13:26:18 -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;
	4 Dec 2014 13:26:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199710430"
Message-ID: <1417699575.22808.32.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:26:15 +0000
In-Reply-To: <20141202184749.GC32622@laptop.dumpdata.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
	<1417174732.23604.13.camel@citrix.com>
	<20141201211456.GH22021@laptop.dumpdata.com>
	<1417528237.24320.34.camel@citrix.com>
	<20141202184749.GC32622@laptop.dumpdata.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>, 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 Tue, 2014-12-02 at 13:47 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 01:50:37PM +0000, Ian Campbell wrote:
> > On Mon, 2014-12-01 at 16:14 -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 28, 2014 at 11:38:52AM +0000, Ian Campbell wrote:
> > > > 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>
> > > 
> > > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > Did you intend to also ack patch #1? (or have I missed a mail?)
> 
> No. You two still were discussing it so I figured I will wait
> until a repost.

I've applied these two.

FWIW despite the discussion I think the first could go in too, and
probably doesn't need a resend.



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:26:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWQG-0004Db-Mh; Thu, 04 Dec 2014 13:26: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 1XwWQG-0004DO-6e
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:26:20 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	3F/66-02576-BF060845; Thu, 04 Dec 2014 13:26:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417699577!12996115!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9650 invoked from network); 4 Dec 2014 13:26:18 -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;
	4 Dec 2014 13:26:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199710430"
Message-ID: <1417699575.22808.32.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:26:15 +0000
In-Reply-To: <20141202184749.GC32622@laptop.dumpdata.com>
References: <1417091674-8163-1-git-send-email-andrew.cooper3@citrix.com>
	<1417091674-8163-3-git-send-email-andrew.cooper3@citrix.com>
	<1417174732.23604.13.camel@citrix.com>
	<20141201211456.GH22021@laptop.dumpdata.com>
	<1417528237.24320.34.camel@citrix.com>
	<20141202184749.GC32622@laptop.dumpdata.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>, 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 Tue, 2014-12-02 at 13:47 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 01:50:37PM +0000, Ian Campbell wrote:
> > On Mon, 2014-12-01 at 16:14 -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 28, 2014 at 11:38:52AM +0000, Ian Campbell wrote:
> > > > 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>
> > > 
> > > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > Did you intend to also ack patch #1? (or have I missed a mail?)
> 
> No. You two still were discussing it so I figured I will wait
> until a repost.

I've applied these two.

FWIW despite the discussion I think the first could go in too, and
probably doesn't need a resend.



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:27:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWRB-0004Oa-Ab; Thu, 04 Dec 2014 13:27: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 1XwWR9-0004OH-Lt
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 13:27:15 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	E6/31-27623-23160845; Thu, 04 Dec 2014 13:27:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417699633!11059602!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 9419 invoked from network); 4 Dec 2014 13:27:14 -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 Dec 2014 13:27:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200063935"
Message-ID: <1417699631.22808.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 4 Dec 2014 13:27:11 +0000
In-Reply-To: <1417530970.24320.53.camel@citrix.com>
References: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
	<1417528456.24320.37.camel@citrix.com> <547DC7DB.5040305@linaro.org>
	<1417530117.24320.50.camel@citrix.com> <547DCD73.9050202@linaro.org>
	<1417530970.24320.53.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.xenproject.org, tim@xen.org, stefano.stabellini@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

On Tue, 2014-12-02 at 14:36 +0000, Ian Campbell wrote:

> > When executed, the softirq will notice that the timer has to be fired
> > and therefore an interrupt will be injected to the guest.
> 
> Perfect, thanks.

Konrad RM-acked it, so I have committed with the tweaks I mentioned.



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:27:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWRB-0004Oa-Ab; Thu, 04 Dec 2014 13:27: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 1XwWR9-0004OH-Lt
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 13:27:15 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	E6/31-27623-23160845; Thu, 04 Dec 2014 13:27:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417699633!11059602!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 9419 invoked from network); 4 Dec 2014 13:27:14 -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 Dec 2014 13:27:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200063935"
Message-ID: <1417699631.22808.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 4 Dec 2014 13:27:11 +0000
In-Reply-To: <1417530970.24320.53.camel@citrix.com>
References: <1417187826-5491-1-git-send-email-julien.grall@linaro.org>
	<1417528456.24320.37.camel@citrix.com> <547DC7DB.5040305@linaro.org>
	<1417530117.24320.50.camel@citrix.com> <547DCD73.9050202@linaro.org>
	<1417530970.24320.53.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.xenproject.org, tim@xen.org, stefano.stabellini@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

On Tue, 2014-12-02 at 14:36 +0000, Ian Campbell wrote:

> > When executed, the softirq will notice that the timer has to be fired
> > and therefore an interrupt will be injected to the guest.
> 
> Perfect, thanks.

Konrad RM-acked it, so I have committed with the tweaks I mentioned.



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:27:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWRE-0004Re-Ms; Thu, 04 Dec 2014 13:27: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 1XwWRD-0004PS-0G
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:27:19 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	A0/07-03148-63160845; Thu, 04 Dec 2014 13:27:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417699635!12906147!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29258 invoked from network); 4 Dec 2014 13:27:17 -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 Dec 2014 13:27:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199710613"
Message-ID: <1417699615.22808.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:26:55 +0000
In-Reply-To: <20141202150933.GE27869@laptop.dumpdata.com>
References: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417174284.23604.9.camel@citrix.com>
	<20141201203001.GE21626@laptop.dumpdata.com>
	<547D276C.2070805@citrix.com>
	<1417528978.24320.42.camel@citrix.com>
	<20141202150933.GE27869@laptop.dumpdata.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>,
	Boris Ostrovsky <boris.ostrovsky@oracle.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-12-02 at 10:09 -0500, Konrad Rzeszutek Wilk wrote:
> > At this point in a freeze I'm much happier with:
> > 
> >  tools/pygrub/src/pygrub |    4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> The same here. This is now the season of handing out band-aids.
> 
> As such Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied.

> > 
> > than
> >  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(-)
> > 
> > Plus Boris' patch is far easier to reason about in isolation in a
> > dynamically/duck typed language.
> > 
> > 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 Dec 04 13:27:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWRE-0004Re-Ms; Thu, 04 Dec 2014 13:27: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 1XwWRD-0004PS-0G
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:27:19 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	A0/07-03148-63160845; Thu, 04 Dec 2014 13:27:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417699635!12906147!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29258 invoked from network); 4 Dec 2014 13:27:17 -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 Dec 2014 13:27:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199710613"
Message-ID: <1417699615.22808.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:26:55 +0000
In-Reply-To: <20141202150933.GE27869@laptop.dumpdata.com>
References: <1416931910-8222-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417174284.23604.9.camel@citrix.com>
	<20141201203001.GE21626@laptop.dumpdata.com>
	<547D276C.2070805@citrix.com>
	<1417528978.24320.42.camel@citrix.com>
	<20141202150933.GE27869@laptop.dumpdata.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>,
	Boris Ostrovsky <boris.ostrovsky@oracle.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-12-02 at 10:09 -0500, Konrad Rzeszutek Wilk wrote:
> > At this point in a freeze I'm much happier with:
> > 
> >  tools/pygrub/src/pygrub |    4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> The same here. This is now the season of handing out band-aids.
> 
> As such Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied.

> > 
> > than
> >  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(-)
> > 
> > Plus Boris' patch is far easier to reason about in isolation in a
> > dynamically/duck typed language.
> > 
> > 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 Dec 04 13:27:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:27:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWRG-0004Sz-64; Thu, 04 Dec 2014 13:27: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 1XwWRF-0004S6-HN
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:27:21 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	36/B8-20609-83160845; Thu, 04 Dec 2014 13:27:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417699635!12906147!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 29186 invoked from network); 4 Dec 2014 13:27:16 -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 Dec 2014 13:27:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199710575"
Message-ID: <1417699608.22808.33.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:26:48 +0000
In-Reply-To: <20141202184326.GJ32385@laptop.dumpdata.com>
References: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
	<20141202160444.GI5768@zion.uk.xensource.com>
	<20141202184326.GJ32385@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Jones <drjones@redhat.com>, Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [Xen-devel] [PATCH] libxc: check in xc_get_tot_pages() that the
 proper domain is reported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-02 at 13:43 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 04:04:44PM +0000, Wei Liu wrote:
> > On Tue, Dec 02, 2014 at 04:18:08PM +0100, Vitaly Kuznetsov wrote:
> > > XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
> > > strange interface: it reports first domain which has domid >= requested domid
> > > so all callers are supposed to check that the proper domain(s) was queried
> > > by checking domid. xc_get_tot_pages() doesn't do that. In case the requested
> > > domain was destroyed it will report first domain with domid > requested domid
> > > which is apparently misleading as there is no way xc_get_tot_pages() callers
> > > can figure out that they got tot_pages for some other domain.
> > > 
> > > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> > 
> > Acked-by: Wei Liu <wei.liu2@citrix.com>
> 
> Lets add another Ack to this party..
> 
> 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 Thu Dec 04 13:27:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:27:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWRG-0004Sz-64; Thu, 04 Dec 2014 13:27: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 1XwWRF-0004S6-HN
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:27:21 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	36/B8-20609-83160845; Thu, 04 Dec 2014 13:27:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417699635!12906147!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 29186 invoked from network); 4 Dec 2014 13:27:16 -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 Dec 2014 13:27:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199710575"
Message-ID: <1417699608.22808.33.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:26:48 +0000
In-Reply-To: <20141202184326.GJ32385@laptop.dumpdata.com>
References: <1417533488-15787-1-git-send-email-vkuznets@redhat.com>
	<20141202160444.GI5768@zion.uk.xensource.com>
	<20141202184326.GJ32385@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Jones <drjones@redhat.com>, Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [Xen-devel] [PATCH] libxc: check in xc_get_tot_pages() that the
 proper domain is reported
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-02 at 13:43 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 04:04:44PM +0000, Wei Liu wrote:
> > On Tue, Dec 02, 2014 at 04:18:08PM +0100, Vitaly Kuznetsov wrote:
> > > XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
> > > strange interface: it reports first domain which has domid >= requested domid
> > > so all callers are supposed to check that the proper domain(s) was queried
> > > by checking domid. xc_get_tot_pages() doesn't do that. In case the requested
> > > domain was destroyed it will report first domain with domid > requested domid
> > > which is apparently misleading as there is no way xc_get_tot_pages() callers
> > > can figure out that they got tot_pages for some other domain.
> > > 
> > > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> > 
> > Acked-by: Wei Liu <wei.liu2@citrix.com>
> 
> Lets add another Ack to this party..
> 
> 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 Thu Dec 04 13:27:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:27:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWRX-0004Zb-Kq; Thu, 04 Dec 2014 13:27: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 1XwWRW-0004Yy-Jw
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:27:38 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	14/D6-02712-94160845; Thu, 04 Dec 2014 13:27:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417699656!9657790!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16419 invoked from network); 4 Dec 2014 13:27:37 -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;
	4 Dec 2014 13:27:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199710839"
Message-ID: <1417699646.22808.36.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:27:26 +0000
In-Reply-To: <201412041214.sB4CEoXn022467@aserz7021.oracle.com>
References: <201412041214.sB4CEoXn022467@aserz7021.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.com>, Olaf Hering <olaf@aepfle.de>, Wei
	Liu <wei.liu2@citrix.com>, "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	M A Young <m.a.young@durham.ac.uk>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-04 at 07:13 -0500, Konrad Rzeszutek Wilk wrote:
> On Dec 4, 2014 6:55 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > On Wed, 2014-12-03 at 10:51 +0000, Ian Campbell wrote: 
> > > On Wed, 2014-12-03 at 11:49 +0100, Olaf Hering wrote: 
> > > > On Wed, Dec 03, Ian Campbell wrote: 
> > > > 
> > > > > Ah I didn't know about the sd_listen_fds thing, so I think that what we 
> > > > > need then is to use pkg-config first to determine if systemd-daemon is 
> > > > > present at all, and then check for specific symbols we require using the 
> > > > > pkg-config supplied CFLAGS and LDFLAGS rather than assuming 
> > > > > -lsystemd-daemon. 
> > > > 
> > > > Correction: sd_listen_fds is available since at least v1. 
> > > >  git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d 
> > > >  v1~390 
> > > 
> > > In that case I don't think we realistically need to check for it? 
> >
> > The implication here being that Wei's original patch is correct. Konrad, 
> > do you think this is OK for the release? 
> >
> > > 
> 
> Yes. Release-Axked-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 
> >
> >
> >
> > _______________________________________________ 
> > Xen-devel mailing list 
> > Xen-devel@lists.xen.org 
> > http://lists.xen.org/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 Dec 04 13:27:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:27:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWRX-0004Zb-Kq; Thu, 04 Dec 2014 13:27: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 1XwWRW-0004Yy-Jw
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:27:38 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	14/D6-02712-94160845; Thu, 04 Dec 2014 13:27:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417699656!9657790!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16419 invoked from network); 4 Dec 2014 13:27:37 -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;
	4 Dec 2014 13:27:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199710839"
Message-ID: <1417699646.22808.36.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 4 Dec 2014 13:27:26 +0000
In-Reply-To: <201412041214.sB4CEoXn022467@aserz7021.oracle.com>
References: <201412041214.sB4CEoXn022467@aserz7021.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.com>, Olaf Hering <olaf@aepfle.de>, Wei
	Liu <wei.liu2@citrix.com>, "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	M A Young <m.a.young@durham.ac.uk>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-04 at 07:13 -0500, Konrad Rzeszutek Wilk wrote:
> On Dec 4, 2014 6:55 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > On Wed, 2014-12-03 at 10:51 +0000, Ian Campbell wrote: 
> > > On Wed, 2014-12-03 at 11:49 +0100, Olaf Hering wrote: 
> > > > On Wed, Dec 03, Ian Campbell wrote: 
> > > > 
> > > > > Ah I didn't know about the sd_listen_fds thing, so I think that what we 
> > > > > need then is to use pkg-config first to determine if systemd-daemon is 
> > > > > present at all, and then check for specific symbols we require using the 
> > > > > pkg-config supplied CFLAGS and LDFLAGS rather than assuming 
> > > > > -lsystemd-daemon. 
> > > > 
> > > > Correction: sd_listen_fds is available since at least v1. 
> > > >  git describe --contains abbbea81a8fa70badb7a05e518d6b07c360fc09d 
> > > >  v1~390 
> > > 
> > > In that case I don't think we realistically need to check for it? 
> >
> > The implication here being that Wei's original patch is correct. Konrad, 
> > do you think this is OK for the release? 
> >
> > > 
> 
> Yes. Release-Axked-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 
> >
> >
> >
> > _______________________________________________ 
> > Xen-devel mailing list 
> > Xen-devel@lists.xen.org 
> > http://lists.xen.org/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 Dec 04 13:28:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWSD-0004p1-2v; Thu, 04 Dec 2014 13:28: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 1XwWSB-0004oO-C6
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:28:19 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	13/AF-09842-27160845; Thu, 04 Dec 2014 13:28:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417699696!5380932!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 21840 invoked from network); 4 Dec 2014 13:28:17 -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;
	4 Dec 2014 13:28:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199711167"
Message-ID: <1417699693.22808.37.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Date: Thu, 4 Dec 2014 13:28:13 +0000
In-Reply-To: <1417695730.31647.35.camel@Abyss.station>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-4-git-send-email-boris.ostrovsky@oracle.com>
	<1417695730.31647.35.camel@Abyss.station>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: keir@xen.org, ufimtseva@gmail.com, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, wei.liu2@citrix.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] sysctl/libxl: Provide information about
	IO topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-12-04 at 13:22 +0100, Dario Faggioli wrote:
> On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
> 
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -1168,6 +1168,11 @@ _hidden int libxl__try_phy_backend(mode_t st_mode);
> >  
> >  _hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid);
> >  
> > +_hidden int libxl_pci_numdevs(libxl_ctx *ctx);
> > +_hidden int libxl_pci_topology_init(libxl_ctx *ctx,
> > +                                    xen_sysctl_iotopo_t *iotopo,
> > +                                    int numdev);
> > +
> IIRC, internal/hidden function should have libxl__* as prefix.

And, generally, take a gc instead of a ctx.




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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:28:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWSD-0004p1-2v; Thu, 04 Dec 2014 13:28: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 1XwWSB-0004oO-C6
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:28:19 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	13/AF-09842-27160845; Thu, 04 Dec 2014 13:28:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417699696!5380932!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 21840 invoked from network); 4 Dec 2014 13:28:17 -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;
	4 Dec 2014 13:28:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199711167"
Message-ID: <1417699693.22808.37.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Date: Thu, 4 Dec 2014 13:28:13 +0000
In-Reply-To: <1417695730.31647.35.camel@Abyss.station>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-4-git-send-email-boris.ostrovsky@oracle.com>
	<1417695730.31647.35.camel@Abyss.station>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: keir@xen.org, ufimtseva@gmail.com, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, wei.liu2@citrix.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] sysctl/libxl: Provide information about
	IO topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-12-04 at 13:22 +0100, Dario Faggioli wrote:
> On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
> 
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -1168,6 +1168,11 @@ _hidden int libxl__try_phy_backend(mode_t st_mode);
> >  
> >  _hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid);
> >  
> > +_hidden int libxl_pci_numdevs(libxl_ctx *ctx);
> > +_hidden int libxl_pci_topology_init(libxl_ctx *ctx,
> > +                                    xen_sysctl_iotopo_t *iotopo,
> > +                                    int numdev);
> > +
> IIRC, internal/hidden function should have libxl__* as prefix.

And, generally, take a gc instead of a ctx.




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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:33:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:33:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWWh-0005W8-Pg; Thu, 04 Dec 2014 13:32: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 1XwWWg-0005W0-Ot
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:32:58 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	5B/24-01660-A8260845; Thu, 04 Dec 2014 13:32:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417699976!11535664!1
X-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 21353 invoked from network); 4 Dec 2014 13:32:56 -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; 4 Dec 2014 13:32:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 13:32:56 +0000
Message-Id: <54807097020000780004CBC7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 13:32:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1417697910-19824-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1417697910-19824-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] x86/stack: Avoid peeking into
 unmapped guard pages when dumping Xens stack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.12.14 at 13:58, <andrew.cooper3@citrix.com> wrote:
> Konrad: I am requesting a release ack for this change.  It aids the clarity of
> certain crash information, and prevents cascade pagefaults in certain
> circumstances, which would prevent execution of the crash kernel or a system
> reboot.

With

#ifndef NDEBUG
#define MEMORY_GUARD
#endif

I don't think this qualifies as a necessary bug fix at this point of 4.5.

> +unsigned long get_stack_trace_bottom(unsigned long sp)
> +{
> +    switch ( get_stack_page(sp) )
> +    {
> +    case 0 ... 2:
> +        return ROUNDUP(sp, PAGE_SIZE) -
> +            offsetof(struct cpu_user_regs, es) - sizeof(unsigned long);

The only concern I have here is that this may wrongly truncate a
dump/trace when one of the IST stacks overflowed. But I think we
can live with that - an overflow of the first one would already have
similar behavior today.

> +
> +#ifndef MEMORY_GUARD
> +    case 3 ... 5:
> +#endif
> +    case 6 ... 7:
> +        return ROUNDUP(sp, STACK_SIZE) -
> +            sizeof(struct cpu_info) - sizeof(unsigned long);
> +
> +#ifdef MEMORY_GUARD
> +    case 3 ... 5:
> +#endif
> +    default:

What is the #ifdef good for when this is "default:" anyway? With
this dropped (also from the other function)
Reviewed-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 Thu Dec 04 13:33:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:33:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWWh-0005W8-Pg; Thu, 04 Dec 2014 13:32: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 1XwWWg-0005W0-Ot
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:32:58 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	5B/24-01660-A8260845; Thu, 04 Dec 2014 13:32:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417699976!11535664!1
X-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 21353 invoked from network); 4 Dec 2014 13:32:56 -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; 4 Dec 2014 13:32:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 13:32:56 +0000
Message-Id: <54807097020000780004CBC7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 13:32:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1417697910-19824-1-git-send-email-andrew.cooper3@citrix.com>
In-Reply-To: <1417697910-19824-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] x86/stack: Avoid peeking into
 unmapped guard pages when dumping Xens stack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.12.14 at 13:58, <andrew.cooper3@citrix.com> wrote:
> Konrad: I am requesting a release ack for this change.  It aids the clarity of
> certain crash information, and prevents cascade pagefaults in certain
> circumstances, which would prevent execution of the crash kernel or a system
> reboot.

With

#ifndef NDEBUG
#define MEMORY_GUARD
#endif

I don't think this qualifies as a necessary bug fix at this point of 4.5.

> +unsigned long get_stack_trace_bottom(unsigned long sp)
> +{
> +    switch ( get_stack_page(sp) )
> +    {
> +    case 0 ... 2:
> +        return ROUNDUP(sp, PAGE_SIZE) -
> +            offsetof(struct cpu_user_regs, es) - sizeof(unsigned long);

The only concern I have here is that this may wrongly truncate a
dump/trace when one of the IST stacks overflowed. But I think we
can live with that - an overflow of the first one would already have
similar behavior today.

> +
> +#ifndef MEMORY_GUARD
> +    case 3 ... 5:
> +#endif
> +    case 6 ... 7:
> +        return ROUNDUP(sp, STACK_SIZE) -
> +            sizeof(struct cpu_info) - sizeof(unsigned long);
> +
> +#ifdef MEMORY_GUARD
> +    case 3 ... 5:
> +#endif
> +    default:

What is the #ifdef good for when this is "default:" anyway? With
this dropped (also from the other function)
Reviewed-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 Thu Dec 04 13:35:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:35:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWYz-0005cQ-BT; Thu, 04 Dec 2014 13:35:21 +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 1XwWYx-0005cJ-It
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:35:19 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	C1/E5-16982-61360845; Thu, 04 Dec 2014 13:35:18 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417700117!11078698!1
X-Originating-IP: [74.125.82.51]
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 28741 invoked from network); 4 Dec 2014 13:35:18 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 13:35:18 -0000
Received: by mail-wg0-f51.google.com with SMTP id k14so22369633wgh.24
	for <xen-devel@lists.xen.org>; Thu, 04 Dec 2014 05:35: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
	:content-transfer-encoding;
	bh=BwYCd9oQ18kAtmRA0usyZRtlgl1zpHHTk2ekJIEAQUY=;
	b=mBFIRH1PzHVnx2TSYvFsEzbckOmDMiHZ1NvTIcJqmtBVwAb8svnGADH7lKWvfXZ8U6
	Y6vCNsD6XDYTH+A8vsgx8UadVha5kOFeU5YZ02hFSsdk1n2WtWHdxUzRNTAXnGUNYMn6
	OU5G4PZEjuRuDi2BLjH5sx8R/cYuF61e3zl2DV9IJFMbNVp8vLzhJfaq/oYvqC+w/GuJ
	mBMvKS1gR86Js4QJxvFeMshPss2d4WChLXU9WfctxUcX4KGqKKZNCeKMgcP8brorWLrf
	Gx82bgbxiECPSBDNqNC0fe2biH0HlP2RN0t8mmGo/jRql45XHM0NH4Y4wVarIqMQw0z7
	6yzA==
X-Gm-Message-State: ALoCoQlV/P0IhswS4+RDnmHfC6QDxmlDrr6lUqm4zbdEBytfiZaN+4fF9SOs7xmKeo5Gj6hH0UGc
X-Received: by 10.181.8.98 with SMTP id dj2mr95264019wid.81.1417700117845;
	Thu, 04 Dec 2014 05:35:17 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id
	gf6sm27732939wjc.11.2014.12.04.05.35.16 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 04 Dec 2014 05:35:17 -0800 (PST)
Message-ID: <54806315.6010007@linaro.org>
Date: Thu, 04 Dec 2014 13:35:17 +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 (Trump)" <zhangleiqiang@huawei.com>, 
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>	<20141202110133.GA5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>	<20141202121151.GD5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>	<20141202155832.GH5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 04/12/14 12:09, Zhangleiqiang (Trump) wrote:
>> I think that's expected, because guest RX data path still uses grant_copy while
>> >guest TX uses grant_map to do zero-copy transmit.
> As I understand, the RX process is as follows:
> 1. Phy NIC receive packet
> 2. XEN Hypervisor trigger interrupt to Dom0
> 3. Dom0' s NIC driver do the "RX" operation, and the packet is stored into SKB which is also owned/shared with netback
Not that easy. There is something between the NIC driver and netback 
which directs the packets, e.g. the old bridge driver, ovs, or the IP 
stack of the kernel.
> 4. NetBack notify netfront through event channel that a packet is receiving
> 5. Netfront grant a buffer for receiving and notify netback the GR (if using grant-resue mechanism, netfront just notify the GR to netback) through IO Ring
It looks a bit confusing in the code, but netfront put "requests" on the 
ring buffer, which contains the grant ref of the guest page where the 
backend can copy. When the packet comes, netback consumes these requests 
and send back a response telling the guest the grant copy of the packet 
finished, it can start handling the data. (sending a response means it's 
placing a response in the ring and trigger the event channel)
And ideally netback should always have requests in the ring, so it 
doesn't have to wait for the guest to fill it up.

> 6. NetBack do the grant_copy to copy packet from its SKB to the buffer referenced by GR, and notify netfront through event channel
> 7. Netfront copy the data from buffer to user-level app's SKB
Or wherever that SKB should go, yes. Like with any received packet on a 
real network interface.
>
> Am I right? Why not using zero-copy transmit in guest RX data pash too ?
Because that means you are mapping that memory to the guest, and you 
won't have any guarantee when the guest will release them. And netback 
can't just unmap them forcibly after a timeout, because finding a 
correct timeout value would be quite impossible.
A malicious/buggy/overloaded guest can hold on to Dom0 memory 
indefinitely, but it even becomes worse if the memory came from another 
guest: you can't shutdown that guest for example, until all its memory 
is returned to him.

Regards,

Zoli

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:35:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:35:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWYz-0005cQ-BT; Thu, 04 Dec 2014 13:35:21 +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 1XwWYx-0005cJ-It
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:35:19 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	C1/E5-16982-61360845; Thu, 04 Dec 2014 13:35:18 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417700117!11078698!1
X-Originating-IP: [74.125.82.51]
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 28741 invoked from network); 4 Dec 2014 13:35:18 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 13:35:18 -0000
Received: by mail-wg0-f51.google.com with SMTP id k14so22369633wgh.24
	for <xen-devel@lists.xen.org>; Thu, 04 Dec 2014 05:35: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
	:content-transfer-encoding;
	bh=BwYCd9oQ18kAtmRA0usyZRtlgl1zpHHTk2ekJIEAQUY=;
	b=mBFIRH1PzHVnx2TSYvFsEzbckOmDMiHZ1NvTIcJqmtBVwAb8svnGADH7lKWvfXZ8U6
	Y6vCNsD6XDYTH+A8vsgx8UadVha5kOFeU5YZ02hFSsdk1n2WtWHdxUzRNTAXnGUNYMn6
	OU5G4PZEjuRuDi2BLjH5sx8R/cYuF61e3zl2DV9IJFMbNVp8vLzhJfaq/oYvqC+w/GuJ
	mBMvKS1gR86Js4QJxvFeMshPss2d4WChLXU9WfctxUcX4KGqKKZNCeKMgcP8brorWLrf
	Gx82bgbxiECPSBDNqNC0fe2biH0HlP2RN0t8mmGo/jRql45XHM0NH4Y4wVarIqMQw0z7
	6yzA==
X-Gm-Message-State: ALoCoQlV/P0IhswS4+RDnmHfC6QDxmlDrr6lUqm4zbdEBytfiZaN+4fF9SOs7xmKeo5Gj6hH0UGc
X-Received: by 10.181.8.98 with SMTP id dj2mr95264019wid.81.1417700117845;
	Thu, 04 Dec 2014 05:35:17 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id
	gf6sm27732939wjc.11.2014.12.04.05.35.16 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 04 Dec 2014 05:35:17 -0800 (PST)
Message-ID: <54806315.6010007@linaro.org>
Date: Thu, 04 Dec 2014 13:35:17 +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 (Trump)" <zhangleiqiang@huawei.com>, 
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>	<20141202110133.GA5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>	<20141202121151.GD5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>	<20141202155832.GH5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 04/12/14 12:09, Zhangleiqiang (Trump) wrote:
>> I think that's expected, because guest RX data path still uses grant_copy while
>> >guest TX uses grant_map to do zero-copy transmit.
> As I understand, the RX process is as follows:
> 1. Phy NIC receive packet
> 2. XEN Hypervisor trigger interrupt to Dom0
> 3. Dom0' s NIC driver do the "RX" operation, and the packet is stored into SKB which is also owned/shared with netback
Not that easy. There is something between the NIC driver and netback 
which directs the packets, e.g. the old bridge driver, ovs, or the IP 
stack of the kernel.
> 4. NetBack notify netfront through event channel that a packet is receiving
> 5. Netfront grant a buffer for receiving and notify netback the GR (if using grant-resue mechanism, netfront just notify the GR to netback) through IO Ring
It looks a bit confusing in the code, but netfront put "requests" on the 
ring buffer, which contains the grant ref of the guest page where the 
backend can copy. When the packet comes, netback consumes these requests 
and send back a response telling the guest the grant copy of the packet 
finished, it can start handling the data. (sending a response means it's 
placing a response in the ring and trigger the event channel)
And ideally netback should always have requests in the ring, so it 
doesn't have to wait for the guest to fill it up.

> 6. NetBack do the grant_copy to copy packet from its SKB to the buffer referenced by GR, and notify netfront through event channel
> 7. Netfront copy the data from buffer to user-level app's SKB
Or wherever that SKB should go, yes. Like with any received packet on a 
real network interface.
>
> Am I right? Why not using zero-copy transmit in guest RX data pash too ?
Because that means you are mapping that memory to the guest, and you 
won't have any guarantee when the guest will release them. And netback 
can't just unmap them forcibly after a timeout, because finding a 
correct timeout value would be quite impossible.
A malicious/buggy/overloaded guest can hold on to Dom0 memory 
indefinitely, but it even becomes worse if the memory came from another 
guest: you can't shutdown that guest for example, until all its memory 
is returned to him.

Regards,

Zoli

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:43:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWgc-0005th-A2; Thu, 04 Dec 2014 13:43:14 +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 1XwWga-0005tc-H0
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 13:43:12 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	E5/AE-25727-FE460845; Thu, 04 Dec 2014 13:43:11 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417700589!7355249!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 30012 invoked from network); 4 Dec 2014 13:43:11 -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 Dec 2014 13:43:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200070164"
Message-ID: <548064EA.8090905@citrix.com>
Date: Thu, 4 Dec 2014 13:43:06 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
In-Reply-To: <1107877503.20141204141054@eikelenboom.it>
X-DLP: MIA2
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 13:10, Sander Eikelenboom wrote:
> 
> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
> 
>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>>
>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>
>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>>>
>>>>> Instead of doing all this complex dance, we depend on the toolstack 
>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>>>> It bypasses the need to worry about the PCI lock. 
>>>>
>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>>>> proposed). 
>>>>
>>>
>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
> 
>> It is only needed if the core won't provide one.
> 
>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
>> +{
>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
>> +       struct device *dev = &pci->dev;
>> +       int ret;
>> +
>> +       /* Already have a per-function reset? */
>> +       if (pci_probe_reset_function(pci) == 0)
>> +               return 0;
>> +
>> +       ret = device_create_file(dev, &dev_attr_reset);
>> +       if (ret < 0)
>> +               return ret;
> +       dev_data->>created_reset_file = true;
>> +       return 0;
>> +}
> 
> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
> "pci.c:__pci_dev_reset" ?
> 
> The problem with that function is that from my testing it seems that the 
> first option "pci_dev_specific_reset" always seems to return succes, so all the
> other options are skipped (flr, pm, slot, bus). However the device it self is 
> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
> none virtualization purposes and it's probably the least intrusive. For 
> virtualization however it would be nice to be sure it resets properly, or have a 
> way to force a specific reset routine.)

Then you need work with the maintainer for those specific devices or
drivers to fix their specific reset function.

I'm not adding stuff to pciback to workaround broken quirks.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:43:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWgc-0005th-A2; Thu, 04 Dec 2014 13:43:14 +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 1XwWga-0005tc-H0
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 13:43:12 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	E5/AE-25727-FE460845; Thu, 04 Dec 2014 13:43:11 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417700589!7355249!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 30012 invoked from network); 4 Dec 2014 13:43:11 -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 Dec 2014 13:43:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200070164"
Message-ID: <548064EA.8090905@citrix.com>
Date: Thu, 4 Dec 2014 13:43:06 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
In-Reply-To: <1107877503.20141204141054@eikelenboom.it>
X-DLP: MIA2
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 13:10, Sander Eikelenboom wrote:
> 
> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
> 
>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>>
>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>
>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>>>
>>>>> Instead of doing all this complex dance, we depend on the toolstack 
>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>>>> It bypasses the need to worry about the PCI lock. 
>>>>
>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>>>> proposed). 
>>>>
>>>
>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
> 
>> It is only needed if the core won't provide one.
> 
>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
>> +{
>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
>> +       struct device *dev = &pci->dev;
>> +       int ret;
>> +
>> +       /* Already have a per-function reset? */
>> +       if (pci_probe_reset_function(pci) == 0)
>> +               return 0;
>> +
>> +       ret = device_create_file(dev, &dev_attr_reset);
>> +       if (ret < 0)
>> +               return ret;
> +       dev_data->>created_reset_file = true;
>> +       return 0;
>> +}
> 
> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
> "pci.c:__pci_dev_reset" ?
> 
> The problem with that function is that from my testing it seems that the 
> first option "pci_dev_specific_reset" always seems to return succes, so all the
> other options are skipped (flr, pm, slot, bus). However the device it self is 
> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
> none virtualization purposes and it's probably the least intrusive. For 
> virtualization however it would be nice to be sure it resets properly, or have a 
> way to force a specific reset routine.)

Then you need work with the maintainer for those specific devices or
drivers to fix their specific reset function.

I'm not adding stuff to pciback to workaround broken quirks.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:43:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:43:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWh5-0005zh-Sv; Thu, 04 Dec 2014 13:43:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XwWh5-0005zX-07
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:43:43 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	3F/A2-24124-E0560845; Thu, 04 Dec 2014 13:43:42 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417700620!11544653!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27104 invoked from network); 4 Dec 2014 13:43:41 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-206.messagelabs.com with SMTP;
	4 Dec 2014 13:43:41 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 04 Dec 2014 05:42:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="493559533"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by orsmga003.jf.intel.com with ESMTP; 04 Dec 2014 05:40:16 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Thu,  4 Dec 2014 21:13:24 +0800
Message-Id: <1417698806-26807-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 v5 0/2] add new p2m type class and new p2m 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

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 added
a new p2m type, p2m_mmio_write_dm, to trap and emulate the write
operations 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_ram_ro types, write operations will not
trigger the device model, and will be discarded later in __hvm_copy();
while for the 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 v4:
 - A new p2m type class, P2M_DISCARD_WRITE_TYPES, is added;
 - A new predicate, p2m_is_discard_write, is used in __hvm_copy()/
   __hvm_clear()/emulate_gva_to_mfn()/hvm_hap_nested_page_fault(),
   to discard the write operations;
 - The new p2m type, p2m_mmio_write_dm, is added to P2M_RO_TYPES;
 - Coding style changes;

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.

Yu Zhang (2):
  Add a new p2m type class - P2M_DISCARD_WRITE_TYPES
  add a new p2m type - p2m_mmio_write_dm

 xen/arch/x86/hvm/hvm.c          | 25 ++++++++++---------------
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/include/asm-x86/p2m.h       |  9 ++++++++-
 xen/include/public/hvm/hvm_op.h |  1 +
 6 files changed, 22 insertions(+), 17 deletions(-)

-- 
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 Dec 04 13:43:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:43:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWh5-0005zh-Sv; Thu, 04 Dec 2014 13:43:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XwWh5-0005zX-07
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:43:43 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	3F/A2-24124-E0560845; Thu, 04 Dec 2014 13:43:42 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417700620!11544653!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27104 invoked from network); 4 Dec 2014 13:43:41 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-206.messagelabs.com with SMTP;
	4 Dec 2014 13:43:41 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 04 Dec 2014 05:42:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="493559533"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by orsmga003.jf.intel.com with ESMTP; 04 Dec 2014 05:40:16 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Thu,  4 Dec 2014 21:13:24 +0800
Message-Id: <1417698806-26807-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 v5 0/2] add new p2m type class and new p2m 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

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 added
a new p2m type, p2m_mmio_write_dm, to trap and emulate the write
operations 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_ram_ro types, write operations will not
trigger the device model, and will be discarded later in __hvm_copy();
while for the 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 v4:
 - A new p2m type class, P2M_DISCARD_WRITE_TYPES, is added;
 - A new predicate, p2m_is_discard_write, is used in __hvm_copy()/
   __hvm_clear()/emulate_gva_to_mfn()/hvm_hap_nested_page_fault(),
   to discard the write operations;
 - The new p2m type, p2m_mmio_write_dm, is added to P2M_RO_TYPES;
 - Coding style changes;

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.

Yu Zhang (2):
  Add a new p2m type class - P2M_DISCARD_WRITE_TYPES
  add a new p2m type - p2m_mmio_write_dm

 xen/arch/x86/hvm/hvm.c          | 25 ++++++++++---------------
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/include/asm-x86/p2m.h       |  9 ++++++++-
 xen/include/public/hvm/hvm_op.h |  1 +
 6 files changed, 22 insertions(+), 17 deletions(-)

-- 
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 Dec 04 13:43:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:43:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWh8-00060i-9q; Thu, 04 Dec 2014 13:43:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XwWh6-0005zy-NP
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:43:44 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	22/F0-25714-01560845; Thu, 04 Dec 2014 13:43:44 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417700620!11544653!2
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27309 invoked from network); 4 Dec 2014 13:43:43 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-206.messagelabs.com with SMTP;
	4 Dec 2014 13:43:43 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 04 Dec 2014 05:42:03 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="493559548"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by orsmga003.jf.intel.com with ESMTP; 04 Dec 2014 05:40:19 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Thu,  4 Dec 2014 21:13:25 +0800
Message-Id: <1417698806-26807-2-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
References: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
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 v5 1/2] add a new p2m type class -
	P2M_DISCARD_WRITE_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Yu Zhang <yu.c.zhang@intel.com>

Currently, the P2M_RO_TYPES bears 2 meanings: one is
"_PAGE_RW bit is clear in their PTEs", and another is
to discard the write operations on these pages. This
patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
to bear the second meaning, so we can use this type
class instead of the P2M_RO_TYPES, to decide if a write
operation is to be ignored.

Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
---
 xen/arch/x86/hvm/hvm.c         | 16 +++-------------
 xen/arch/x86/mm/shadow/multi.c |  2 +-
 xen/include/asm-x86/p2m.h      |  5 +++++
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 51ffc90..967f822 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2837,7 +2837,7 @@ 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 && (p2m_is_discard_write(p2mt))) )
     {
         put_gfn(p2m->domain, gfn);
 
@@ -2882,16 +2882,6 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
         goto out_put_gfn;
     }
 
-    /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
-    if ( npfec.write_access && (p2mt == p2m_grant_map_ro) )
-    {
-        gdprintk(XENLOG_WARNING,
-                 "trying to write to read-only grant mapping\n");
-        hvm_inject_hw_exception(TRAP_gp_fault, 0);
-        rc = 1;
-        goto out_put_gfn;
-    }
-
     /* If we fell through, the vcpu will retry now that access restrictions have
      * been removed. It may fault again if the p2m entry type still requires so.
      * Otherwise, this is an error condition. */
@@ -3941,7 +3931,7 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( flags & HVMCOPY_to_guest )
         {
-            if ( p2mt == p2m_ram_ro )
+            if ( p2m_is_discard_write(p2mt) )
             {
                 static unsigned long lastpage;
                 if ( xchg(&lastpage, gfn) != gfn )
@@ -4035,7 +4025,7 @@ static enum hvm_copy_result __hvm_clear(paddr_t addr, int size)
 
         p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
-        if ( p2mt == p2m_ram_ro )
+        if ( p2m_is_discard_write(p2mt) )
         {
             static unsigned long lastpage;
             if ( xchg(&lastpage, gfn) != gfn )
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 225290e..94cf06d 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4575,7 +4575,7 @@ static mfn_t emulate_gva_to_mfn(struct vcpu *v,
     {
         return _mfn(BAD_GFN_TO_MFN);
     }
-    if ( p2m_is_readonly(p2mt) )
+    if ( p2m_is_discard_write(p2mt) )
     {
         put_page(page);
         return _mfn(READONLY_GFN);
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 5f7fe71..42de75d 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -113,6 +113,10 @@ typedef unsigned int p2m_query_t;
                       | p2m_to_mask(p2m_grant_map_ro)   \
                       | p2m_to_mask(p2m_ram_shared) )
 
+/* Write-discard types, which should discard the write operations */
+#define P2M_DISCARD_WRITE_TYPES (p2m_to_mask(p2m_ram_ro)     \
+                      | p2m_to_mask(p2m_grant_map_ro))
+
 /* Types that can be subject to bulk transitions. */
 #define P2M_CHANGEABLE_TYPES (p2m_to_mask(p2m_ram_rw) \
                               | p2m_to_mask(p2m_ram_logdirty) )
@@ -145,6 +149,7 @@ typedef unsigned int p2m_query_t;
 #define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
 #define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
 #define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
+#define p2m_is_discard_write(_t) (p2m_to_mask(_t) & P2M_DISCARD_WRITE_TYPES)
 #define p2m_is_changeable(_t) (p2m_to_mask(_t) & P2M_CHANGEABLE_TYPES)
 #define p2m_is_pod(_t) (p2m_to_mask(_t) & P2M_POD_TYPES)
 #define p2m_is_grant(_t) (p2m_to_mask(_t) & P2M_GRANT_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 Thu Dec 04 13:43:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:43:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWh8-00060i-9q; Thu, 04 Dec 2014 13:43:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XwWh6-0005zy-NP
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:43:44 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	22/F0-25714-01560845; Thu, 04 Dec 2014 13:43:44 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417700620!11544653!2
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27309 invoked from network); 4 Dec 2014 13:43:43 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-206.messagelabs.com with SMTP;
	4 Dec 2014 13:43:43 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 04 Dec 2014 05:42:03 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="493559548"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by orsmga003.jf.intel.com with ESMTP; 04 Dec 2014 05:40:19 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Thu,  4 Dec 2014 21:13:25 +0800
Message-Id: <1417698806-26807-2-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
References: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
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 v5 1/2] add a new p2m type class -
	P2M_DISCARD_WRITE_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Yu Zhang <yu.c.zhang@intel.com>

Currently, the P2M_RO_TYPES bears 2 meanings: one is
"_PAGE_RW bit is clear in their PTEs", and another is
to discard the write operations on these pages. This
patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
to bear the second meaning, so we can use this type
class instead of the P2M_RO_TYPES, to decide if a write
operation is to be ignored.

Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
---
 xen/arch/x86/hvm/hvm.c         | 16 +++-------------
 xen/arch/x86/mm/shadow/multi.c |  2 +-
 xen/include/asm-x86/p2m.h      |  5 +++++
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 51ffc90..967f822 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2837,7 +2837,7 @@ 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 && (p2m_is_discard_write(p2mt))) )
     {
         put_gfn(p2m->domain, gfn);
 
@@ -2882,16 +2882,6 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
         goto out_put_gfn;
     }
 
-    /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
-    if ( npfec.write_access && (p2mt == p2m_grant_map_ro) )
-    {
-        gdprintk(XENLOG_WARNING,
-                 "trying to write to read-only grant mapping\n");
-        hvm_inject_hw_exception(TRAP_gp_fault, 0);
-        rc = 1;
-        goto out_put_gfn;
-    }
-
     /* If we fell through, the vcpu will retry now that access restrictions have
      * been removed. It may fault again if the p2m entry type still requires so.
      * Otherwise, this is an error condition. */
@@ -3941,7 +3931,7 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( flags & HVMCOPY_to_guest )
         {
-            if ( p2mt == p2m_ram_ro )
+            if ( p2m_is_discard_write(p2mt) )
             {
                 static unsigned long lastpage;
                 if ( xchg(&lastpage, gfn) != gfn )
@@ -4035,7 +4025,7 @@ static enum hvm_copy_result __hvm_clear(paddr_t addr, int size)
 
         p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
-        if ( p2mt == p2m_ram_ro )
+        if ( p2m_is_discard_write(p2mt) )
         {
             static unsigned long lastpage;
             if ( xchg(&lastpage, gfn) != gfn )
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 225290e..94cf06d 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4575,7 +4575,7 @@ static mfn_t emulate_gva_to_mfn(struct vcpu *v,
     {
         return _mfn(BAD_GFN_TO_MFN);
     }
-    if ( p2m_is_readonly(p2mt) )
+    if ( p2m_is_discard_write(p2mt) )
     {
         put_page(page);
         return _mfn(READONLY_GFN);
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 5f7fe71..42de75d 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -113,6 +113,10 @@ typedef unsigned int p2m_query_t;
                       | p2m_to_mask(p2m_grant_map_ro)   \
                       | p2m_to_mask(p2m_ram_shared) )
 
+/* Write-discard types, which should discard the write operations */
+#define P2M_DISCARD_WRITE_TYPES (p2m_to_mask(p2m_ram_ro)     \
+                      | p2m_to_mask(p2m_grant_map_ro))
+
 /* Types that can be subject to bulk transitions. */
 #define P2M_CHANGEABLE_TYPES (p2m_to_mask(p2m_ram_rw) \
                               | p2m_to_mask(p2m_ram_logdirty) )
@@ -145,6 +149,7 @@ typedef unsigned int p2m_query_t;
 #define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
 #define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
 #define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
+#define p2m_is_discard_write(_t) (p2m_to_mask(_t) & P2M_DISCARD_WRITE_TYPES)
 #define p2m_is_changeable(_t) (p2m_to_mask(_t) & P2M_CHANGEABLE_TYPES)
 #define p2m_is_pod(_t) (p2m_to_mask(_t) & P2M_POD_TYPES)
 #define p2m_is_grant(_t) (p2m_to_mask(_t) & P2M_GRANT_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 Thu Dec 04 13:43:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:43:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWhB-00062J-OC; Thu, 04 Dec 2014 13:43:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XwWhA-00061V-1G
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:43:48 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	8D/CE-11581-31560845; Thu, 04 Dec 2014 13:43:47 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417700620!11544653!3
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27608 invoked from network); 4 Dec 2014 13:43:46 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-206.messagelabs.com with SMTP;
	4 Dec 2014 13:43:46 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 04 Dec 2014 05:42:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="493559564"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by orsmga003.jf.intel.com with ESMTP; 04 Dec 2014 05:40:21 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Thu,  4 Dec 2014 21:13:26 +0800
Message-Id: <1417698806-26807-3-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
References: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
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 v5 2/2] add a new p2m type - 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

From: Yu Zhang <yu.c.zhang@intel.com>

A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
model, and will be discarded later in __hvm_copy(); while for the
p2m_mmio_write_dm type pages, writes will go to the device model
via ioreq-server.

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          | 11 ++++++++---
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/include/asm-x86/p2m.h       |  4 +++-
 xen/include/public/hvm/hvm_op.h |  1 +
 5 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 967f822..b4bdfab 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2837,7 +2837,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 && (p2m_is_discard_write(p2mt))) )
+         (npfec.write_access &&
+          (p2m_is_discard_write(p2mt) || (p2mt == p2m_mmio_write_dm))) )
     {
         put_gfn(p2m->domain, gfn);
 
@@ -5904,6 +5905,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
             get_gfn_query_unlocked(d, a.pfn, &t);
             if ( p2m_is_mmio(t) )
                 a.mem_type =  HVMMEM_mmio_dm;
+            else if ( t == p2m_mmio_write_dm )
+                a.mem_type = HVMMEM_mmio_write_dm;
             else if ( p2m_is_readonly(t) )
                 a.mem_type =  HVMMEM_ram_ro;
             else if ( p2m_is_ram(t) )
@@ -5931,7 +5934,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) )
@@ -5978,7 +5982,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
                 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;
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 42de75d..866fb0d 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 */
@@ -111,7 +112,8 @@ typedef unsigned int p2m_query_t;
 #define P2M_RO_TYPES (p2m_to_mask(p2m_ram_logdirty)     \
                       | p2m_to_mask(p2m_ram_ro)         \
                       | p2m_to_mask(p2m_grant_map_ro)   \
-                      | p2m_to_mask(p2m_ram_shared) )
+                      | p2m_to_mask(p2m_ram_shared)   \
+                      | p2m_to_mask(p2m_mmio_write_dm))
 
 /* Write-discard types, which should discard the write operations */
 #define P2M_DISCARD_WRITE_TYPES (p2m_to_mask(p2m_ram_ro)     \
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 Thu Dec 04 13:43:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:43:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWhB-00062J-OC; Thu, 04 Dec 2014 13:43:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XwWhA-00061V-1G
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:43:48 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	8D/CE-11581-31560845; Thu, 04 Dec 2014 13:43:47 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417700620!11544653!3
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27608 invoked from network); 4 Dec 2014 13:43:46 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-206.messagelabs.com with SMTP;
	4 Dec 2014 13:43:46 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 04 Dec 2014 05:42:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="493559564"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by orsmga003.jf.intel.com with ESMTP; 04 Dec 2014 05:40:21 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Thu,  4 Dec 2014 21:13:26 +0800
Message-Id: <1417698806-26807-3-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
References: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
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 v5 2/2] add a new p2m type - 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

From: Yu Zhang <yu.c.zhang@intel.com>

A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
model, and will be discarded later in __hvm_copy(); while for the
p2m_mmio_write_dm type pages, writes will go to the device model
via ioreq-server.

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          | 11 ++++++++---
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/include/asm-x86/p2m.h       |  4 +++-
 xen/include/public/hvm/hvm_op.h |  1 +
 5 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 967f822..b4bdfab 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2837,7 +2837,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 && (p2m_is_discard_write(p2mt))) )
+         (npfec.write_access &&
+          (p2m_is_discard_write(p2mt) || (p2mt == p2m_mmio_write_dm))) )
     {
         put_gfn(p2m->domain, gfn);
 
@@ -5904,6 +5905,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
             get_gfn_query_unlocked(d, a.pfn, &t);
             if ( p2m_is_mmio(t) )
                 a.mem_type =  HVMMEM_mmio_dm;
+            else if ( t == p2m_mmio_write_dm )
+                a.mem_type = HVMMEM_mmio_write_dm;
             else if ( p2m_is_readonly(t) )
                 a.mem_type =  HVMMEM_ram_ro;
             else if ( p2m_is_ram(t) )
@@ -5931,7 +5934,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) )
@@ -5978,7 +5982,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
                 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;
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 42de75d..866fb0d 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 */
@@ -111,7 +112,8 @@ typedef unsigned int p2m_query_t;
 #define P2M_RO_TYPES (p2m_to_mask(p2m_ram_logdirty)     \
                       | p2m_to_mask(p2m_ram_ro)         \
                       | p2m_to_mask(p2m_grant_map_ro)   \
-                      | p2m_to_mask(p2m_ram_shared) )
+                      | p2m_to_mask(p2m_ram_shared)   \
+                      | p2m_to_mask(p2m_mmio_write_dm))
 
 /* Write-discard types, which should discard the write operations */
 #define P2M_DISCARD_WRITE_TYPES (p2m_to_mask(p2m_ram_ro)     \
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 Thu Dec 04 13:44:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:44:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWha-0006Ao-5h; Thu, 04 Dec 2014 13:44:14 +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 1XwWhZ-0006AY-5j
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:44:13 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	0B/19-17735-C2560845; Thu, 04 Dec 2014 13:44:12 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417700648!11119135!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11621 invoked from network); 4 Dec 2014 13:44:09 -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 Dec 2014 13:44:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200070709"
Message-ID: <54806526.7040906@citrix.com>
Date: Thu, 4 Dec 2014 13:44:06 +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: David Vrabel <david.vrabel@citrix.com>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>, <konrad.wilk@oracle.com>,
	<stefano.stabellini@eu.citrix.com>
References: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
	<54803DF7.1030903@citrix.com>
In-Reply-To: <54803DF7.1030903@citrix.com>
X-DLP: MIA1
Cc: linux-kernel@vger.kernel.org, jun.nakajima@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4 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 04/12/14 10:56, David Vrabel wrote:
> On 02/12/14 20:19, Boris Ostrovsky wrote:
>> Changes in v4:
>> * Added comment describing what we check for in pci_xen_init()
> 
> I applied v3 ages ago to the devel/for-linus-3.19 branch and I'm not
> going to mess about replacing it for a comment change.

I had to mess with it anyway to fix a build problem.  I've applied this
version.

Thanks.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:44:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:44:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWha-0006Ao-5h; Thu, 04 Dec 2014 13:44:14 +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 1XwWhZ-0006AY-5j
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:44:13 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	0B/19-17735-C2560845; Thu, 04 Dec 2014 13:44:12 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417700648!11119135!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11621 invoked from network); 4 Dec 2014 13:44:09 -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 Dec 2014 13:44:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200070709"
Message-ID: <54806526.7040906@citrix.com>
Date: Thu, 4 Dec 2014 13:44:06 +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: David Vrabel <david.vrabel@citrix.com>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>, <konrad.wilk@oracle.com>,
	<stefano.stabellini@eu.citrix.com>
References: <1417551553-22234-1-git-send-email-boris.ostrovsky@oracle.com>
	<54803DF7.1030903@citrix.com>
In-Reply-To: <54803DF7.1030903@citrix.com>
X-DLP: MIA1
Cc: linux-kernel@vger.kernel.org, jun.nakajima@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4 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 04/12/14 10:56, David Vrabel wrote:
> On 02/12/14 20:19, Boris Ostrovsky wrote:
>> Changes in v4:
>> * Added comment describing what we check for in pci_xen_init()
> 
> I applied v3 ages ago to the devel/for-linus-3.19 branch and I'm not
> going to mess about replacing it for a comment change.

I had to mess with it anyway to fix a build problem.  I've applied this
version.

Thanks.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:50:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWn2-0006fr-2b; Thu, 04 Dec 2014 13:49: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 1XwWn0-0006fm-AI
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:49:50 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	C8/AF-18267-D7660845; Thu, 04 Dec 2014 13:49:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417700988!11121027!1
X-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 24216 invoked from network); 4 Dec 2014 13:49:49 -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 Dec 2014 13:49:49 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 13:49:48 +0000
Message-Id: <5480748B020000780004CBFC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 13:49:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
In-Reply-To: <547898E7.30400@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-develList <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 16:46, <andrew.cooper3@citrix.com> wrote:
> 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.

With no-one else voicing an opinion:

For hvmop, the mask currently is 8 bits and we've got 22 ops defined.

For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.

For the latter, we're fine even without further consideration. For the
former, the two operations actively using the continuation encoding
are tools-only ones. Since we're fine to alter the tools only interfaces,
and since it was intended for the tools-only HVM-ops to be split off
to a separate hypercall (e.g. hvmctl) anyway, the range restriction
would then no longer be a problem. Plus, in the worst case we could
always introduce yet another hypercall if we ran out of numbers.

Consequently what I'd like to propose (and I guess I'll craft a patch
as soon as I finished this mail) is that we add comments to these
masks (also the memop one) to make clear that they mustn't change.
Additionally for forward compatibility I'd also like to add checks for
the upper bits to be zero for any of the sub-ops that don't actually
use them to encode continuation information. Konrad, would you
consider doing so acceptable for 4.5?

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:50:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13: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 1XwWn2-0006fr-2b; Thu, 04 Dec 2014 13:49: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 1XwWn0-0006fm-AI
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:49:50 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	C8/AF-18267-D7660845; Thu, 04 Dec 2014 13:49:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417700988!11121027!1
X-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 24216 invoked from network); 4 Dec 2014 13:49:49 -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 Dec 2014 13:49:49 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 13:49:48 +0000
Message-Id: <5480748B020000780004CBFC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 13:49:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
In-Reply-To: <547898E7.30400@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-develList <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 16:46, <andrew.cooper3@citrix.com> wrote:
> 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.

With no-one else voicing an opinion:

For hvmop, the mask currently is 8 bits and we've got 22 ops defined.

For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.

For the latter, we're fine even without further consideration. For the
former, the two operations actively using the continuation encoding
are tools-only ones. Since we're fine to alter the tools only interfaces,
and since it was intended for the tools-only HVM-ops to be split off
to a separate hypercall (e.g. hvmctl) anyway, the range restriction
would then no longer be a problem. Plus, in the worst case we could
always introduce yet another hypercall if we ran out of numbers.

Consequently what I'd like to propose (and I guess I'll craft a patch
as soon as I finished this mail) is that we add comments to these
masks (also the memop one) to make clear that they mustn't change.
Additionally for forward compatibility I'd also like to add checks for
the upper bits to be zero for any of the sub-ops that don't actually
use them to encode continuation information. Konrad, would you
consider doing so acceptable for 4.5?

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 13:52:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWpC-0006nV-JE; Thu, 04 Dec 2014 13:52:06 +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 1XwWpB-0006nO-8W
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:52:05 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	03/FD-02953-40760845; Thu, 04 Dec 2014 13:52:04 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417701123!12969560!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32719 invoked from network); 4 Dec 2014 13:52:03 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 13:52:03 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so27904480wiv.7
	for <xen-devel@lists.xen.org>; Thu, 04 Dec 2014 05:52: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=RmbxxP1e5+NvIPhKZmuSXdTntbrEWqXspAr2ZLBVqAA=;
	b=V9jk4Dk4cQGcIbdLPcrPxSAIjIbP3gp4cz5FiCmSjkXYexFeRGRff1sZXMiRWv85g1
	vgbhEQb194IKhgVWgLuxYm1xFJXxUl7pEe3ZJH8j/TrrRtS3gK/FR2yZkYCSW3HFxG3a
	hNsVTJmb3g/Tw9ZXmkZLAwX2Yz1pizAdEWPcLAmN9C3JJDipK4BbY9ctKlqgXBQ+DTaQ
	9GUJVPj5R9PUlJAMKKQ0BF4FcWNsuLi4BgH3TaF27r9jeoc/7qP61btmHAIIY5OHuF8l
	9p2mIkxYu62tO6itSh5wn4pDF/AuaMe0HBoavf3AtmKE9PD9PRoPQRov3BaMTgZES9tn
	P/XA==
X-Gm-Message-State: ALoCoQm4Egz710Msc1sc3H6XdRMxXufOiRhGSLZcgW7sNSuDH4rr+dhp1B7TF0DR/u/zeiGrJTyJ
X-Received: by 10.181.13.242 with SMTP id fb18mr25426045wid.1.1417701122698;
	Thu, 04 Dec 2014 05:52:02 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	t10sm37199722wix.15.2014.12.04.05.52.01 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 04 Dec 2014 05:52:01 -0800 (PST)
Message-ID: <548066FE.90905@linaro.org>
Date: Thu, 04 Dec 2014 13:51:58 +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: Vijay Kilari <vijay.kilari@gmail.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <CALicx6trd6Pvsit0LfbC66JU5G3r+1XTt0d-h0DLo8rd31X9vw@mail.gmail.com>
In-Reply-To: <CALicx6trd6Pvsit0LfbC66JU5G3r+1XTt0d-h0DLo8rd31X9vw@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: uart interrupts 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 04/12/14 03:50, Vijay Kilari wrote:
> Hi Tim,

Hi Vijay,

> I see that on uart interrupt, ICR is written to clear the all
> interrupts except TX, RX and RX timeout. With this, cpu always finds
> TX/RX is active and never
> comes out of the loop.

FWIW, the PL011 serial code has been copied from the Linux drivers.

Linux interrupt handler also clear all interrupts except TX, RX, RX
timeout. So do you see the issue on Linux?

> 
> With the below changes, TX, RX & RTI are cleared before handling this
> interrupts.
> 
> Is my observation is correct?. If so I wonder how it is working on
> platforms that
> are using pl011. Without this for my cpu just keeps looping here.
> 
>   index fba0a55..d21bce3 100644
> --- a/xen/drivers/char/pl011.c
> +++ b/xen/drivers/char/pl011.c
> @@ -63,7 +63,7 @@ static void pl011_interrupt(int irq, void *data,
> struct cpu_user_regs *regs)
>      {
>          do
>          {
> -            pl011_write(uart, ICR, status & ~(TXI|RTI|RXI));
> +            pl011_write(uart, ICR, status & (TXI|RTI|RXI));


This changes looks wrong to me. We want to clear the bit in status we
don't handle. Otherwise the interrupt will be fired in loop.

If I'm not mistaken, TXI/RTI/RXI will be cleared when data is read or
write into the fifo. So we should not clear automatically.

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 Dec 04 13:52:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWpC-0006nV-JE; Thu, 04 Dec 2014 13:52:06 +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 1XwWpB-0006nO-8W
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:52:05 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	03/FD-02953-40760845; Thu, 04 Dec 2014 13:52:04 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417701123!12969560!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32719 invoked from network); 4 Dec 2014 13:52:03 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 13:52:03 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so27904480wiv.7
	for <xen-devel@lists.xen.org>; Thu, 04 Dec 2014 05:52: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=RmbxxP1e5+NvIPhKZmuSXdTntbrEWqXspAr2ZLBVqAA=;
	b=V9jk4Dk4cQGcIbdLPcrPxSAIjIbP3gp4cz5FiCmSjkXYexFeRGRff1sZXMiRWv85g1
	vgbhEQb194IKhgVWgLuxYm1xFJXxUl7pEe3ZJH8j/TrrRtS3gK/FR2yZkYCSW3HFxG3a
	hNsVTJmb3g/Tw9ZXmkZLAwX2Yz1pizAdEWPcLAmN9C3JJDipK4BbY9ctKlqgXBQ+DTaQ
	9GUJVPj5R9PUlJAMKKQ0BF4FcWNsuLi4BgH3TaF27r9jeoc/7qP61btmHAIIY5OHuF8l
	9p2mIkxYu62tO6itSh5wn4pDF/AuaMe0HBoavf3AtmKE9PD9PRoPQRov3BaMTgZES9tn
	P/XA==
X-Gm-Message-State: ALoCoQm4Egz710Msc1sc3H6XdRMxXufOiRhGSLZcgW7sNSuDH4rr+dhp1B7TF0DR/u/zeiGrJTyJ
X-Received: by 10.181.13.242 with SMTP id fb18mr25426045wid.1.1417701122698;
	Thu, 04 Dec 2014 05:52:02 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	t10sm37199722wix.15.2014.12.04.05.52.01 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 04 Dec 2014 05:52:01 -0800 (PST)
Message-ID: <548066FE.90905@linaro.org>
Date: Thu, 04 Dec 2014 13:51:58 +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: Vijay Kilari <vijay.kilari@gmail.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Tim Deegan <tim@xen.org>
References: <CALicx6trd6Pvsit0LfbC66JU5G3r+1XTt0d-h0DLo8rd31X9vw@mail.gmail.com>
In-Reply-To: <CALicx6trd6Pvsit0LfbC66JU5G3r+1XTt0d-h0DLo8rd31X9vw@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: uart interrupts 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 04/12/14 03:50, Vijay Kilari wrote:
> Hi Tim,

Hi Vijay,

> I see that on uart interrupt, ICR is written to clear the all
> interrupts except TX, RX and RX timeout. With this, cpu always finds
> TX/RX is active and never
> comes out of the loop.

FWIW, the PL011 serial code has been copied from the Linux drivers.

Linux interrupt handler also clear all interrupts except TX, RX, RX
timeout. So do you see the issue on Linux?

> 
> With the below changes, TX, RX & RTI are cleared before handling this
> interrupts.
> 
> Is my observation is correct?. If so I wonder how it is working on
> platforms that
> are using pl011. Without this for my cpu just keeps looping here.
> 
>   index fba0a55..d21bce3 100644
> --- a/xen/drivers/char/pl011.c
> +++ b/xen/drivers/char/pl011.c
> @@ -63,7 +63,7 @@ static void pl011_interrupt(int irq, void *data,
> struct cpu_user_regs *regs)
>      {
>          do
>          {
> -            pl011_write(uart, ICR, status & ~(TXI|RTI|RXI));
> +            pl011_write(uart, ICR, status & (TXI|RTI|RXI));


This changes looks wrong to me. We want to clear the bit in status we
don't handle. Otherwise the interrupt will be fired in loop.

If I'm not mistaken, TXI/RTI/RXI will be cleared when data is read or
write into the fifo. So we should not clear automatically.

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 Dec 04 13:56:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWss-00072x-DD; Thu, 04 Dec 2014 13:55:54 +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 1XwWsr-00072r-7e
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:55:53 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	5A/4F-09284-8E760845; Thu, 04 Dec 2014 13:55:52 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417701351!6645753!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11569 invoked from network); 4 Dec 2014 13:55:51 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 13:55:51 -0000
Received: from dezo.moloch.sk (unknown [92.240.231.146])
	by mail.moloch.sk (Postfix) with ESMTPSA id 40FED18050C7;
	Thu,  4 Dec 2014 14:55:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1417701351;
	bh=44Ub1kxwbizMdmbLKLM/1R2ZecJrchqj9wZ97D+OB3w=;
	h=Date:From:To:Cc:Subject:From;
	b=HWzX2D/xBS0yo9gDpOWmSpPi1MbkxQxl1x0XDXn5c6RmDHaX37hlUa7N803jN+IZE
	4gq1Lb/YJ6KwiqJO7SbeQSGs8Wh9tyqLy5hmvz8qfzRnxGZE3KU0J+QDrySiMFyUVb
	9m5CddirA2zVghLSdPDi6/0yfBBmfaNaX/E/WNPO+bR8EdWfUyAWO/Hu9vXGiS5JLj
	+G9oVaOU8587CjngSFdjV55dJ6UimrcnuPdIdnB8W0HJlAflGBfIE9HGRgbZ/Tpdf2
	cfKU2TqEMybIlNjxS5ZxoYzNLMioP66M2qNOp0FGkTTteShVs3i2gufaYbnFufT4fq
	LNevSFZCU24Cg==
Received: by dezo.moloch.sk (Postfix, from userid 1000)
	id DFE63D05952E; Thu,  4 Dec 2014 14:55:50 +0100 (CET)
Date: Thu, 4 Dec 2014 14:55:50 +0100
From: Martin Lucina <martin@lucina.net>
To: xen-devel@lists.xen.org
Message-ID: <20141204135550.GC11192@dezo.moloch.sk>
Mail-Followup-To: xen-devel@lists.xen.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	rumpkernel-users@lists.sourceforge.net
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: rumpkernel-users@lists.sourceforge.net,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] Mini-OS: netfront: Fix rx ring starvation in
	network_rx
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

following is a patch against vanilla Mini-OS in upstream xen.git for a
problem we have found in the netfront driver. When subjected to load
network receive would freeze due to the rx ring running out of free
request slots.

With this patch a httpd running on rumprun-xen [1] survives all the load I
can throw at it.

Note that I have only compile-tested this patch against the upstream
Mini-OS. It also does not address the -DHAVE_LIBC codepath as I don't know
how to test that or if anyone is using that code?

Further, I would like to clean this function up; the code is an impossible
to follow mess. What I'd like to arrive at is at [2], however this also
needs(?) to address the -DHAVE_LIBC codepath.

Martin

[1] http://repo.rumpkernel.org/rumprun-xen and
https://github.com/mato/rump-mathopd
[2] https://gist.github.com/mato/512eb70f39565b030f73

----

In network_rx() we must push the same amount of requests back onto the
ring in the second loop that we consumed in the first loop. Otherwise
the ring will eventually starve itself of free request slots and no
packets will be delivered.

Signed-off-by: Martin Lucina <martin@lucina.net>
---
 extras/mini-os/netfront.c |   17 ++++-------------
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/extras/mini-os/netfront.c b/extras/mini-os/netfront.c
index 44c3995..33afc9c 100644
--- a/extras/mini-os/netfront.c
+++ b/extras/mini-os/netfront.c
@@ -99,14 +99,14 @@ void network_rx(struct netfront_dev *dev)
     struct netif_rx_response *rx;
     int nr_consumed, some, more, i, notify;
 
-
+    nr_consumed = 0;
 moretodo:
     rp = dev->rx.sring->rsp_prod;
     rmb(); /* Ensure we see queued responses up to 'rp'. */
     cons = dev->rx.rsp_cons;
 
-    for (nr_consumed = 0, some = 0;
-         (cons != rp) && !some;
+    for (some = 0;
+         (cons != rp);
          nr_consumed++, cons++)
     {
         struct net_buffer* buf;
@@ -115,17 +115,8 @@ moretodo:
 
         rx = RING_GET_RESPONSE(&dev->rx, cons);
 
-        if (rx->flags & NETRXF_extra_info)
-        {
-            printk("+++++++++++++++++++++ we have extras!\n");
-            continue;
-        }
-
-
-        if (rx->status == NETIF_RSP_NULL) continue;
-
         id = rx->id;
-        BUG_ON(id >= NET_TX_RING_SIZE);
+        BUG_ON(id >= NET_RX_RING_SIZE);
 
         buf = &dev->rx_buffers[id];
         page = (unsigned char*)buf->page;
-- 
1.7.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 Dec 04 13:56:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 13:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwWss-00072x-DD; Thu, 04 Dec 2014 13:55:54 +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 1XwWsr-00072r-7e
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 13:55:53 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	5A/4F-09284-8E760845; Thu, 04 Dec 2014 13:55:52 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417701351!6645753!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11569 invoked from network); 4 Dec 2014 13:55:51 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 13:55:51 -0000
Received: from dezo.moloch.sk (unknown [92.240.231.146])
	by mail.moloch.sk (Postfix) with ESMTPSA id 40FED18050C7;
	Thu,  4 Dec 2014 14:55:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1417701351;
	bh=44Ub1kxwbizMdmbLKLM/1R2ZecJrchqj9wZ97D+OB3w=;
	h=Date:From:To:Cc:Subject:From;
	b=HWzX2D/xBS0yo9gDpOWmSpPi1MbkxQxl1x0XDXn5c6RmDHaX37hlUa7N803jN+IZE
	4gq1Lb/YJ6KwiqJO7SbeQSGs8Wh9tyqLy5hmvz8qfzRnxGZE3KU0J+QDrySiMFyUVb
	9m5CddirA2zVghLSdPDi6/0yfBBmfaNaX/E/WNPO+bR8EdWfUyAWO/Hu9vXGiS5JLj
	+G9oVaOU8587CjngSFdjV55dJ6UimrcnuPdIdnB8W0HJlAflGBfIE9HGRgbZ/Tpdf2
	cfKU2TqEMybIlNjxS5ZxoYzNLMioP66M2qNOp0FGkTTteShVs3i2gufaYbnFufT4fq
	LNevSFZCU24Cg==
Received: by dezo.moloch.sk (Postfix, from userid 1000)
	id DFE63D05952E; Thu,  4 Dec 2014 14:55:50 +0100 (CET)
Date: Thu, 4 Dec 2014 14:55:50 +0100
From: Martin Lucina <martin@lucina.net>
To: xen-devel@lists.xen.org
Message-ID: <20141204135550.GC11192@dezo.moloch.sk>
Mail-Followup-To: xen-devel@lists.xen.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	rumpkernel-users@lists.sourceforge.net
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: rumpkernel-users@lists.sourceforge.net,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] Mini-OS: netfront: Fix rx ring starvation in
	network_rx
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

following is a patch against vanilla Mini-OS in upstream xen.git for a
problem we have found in the netfront driver. When subjected to load
network receive would freeze due to the rx ring running out of free
request slots.

With this patch a httpd running on rumprun-xen [1] survives all the load I
can throw at it.

Note that I have only compile-tested this patch against the upstream
Mini-OS. It also does not address the -DHAVE_LIBC codepath as I don't know
how to test that or if anyone is using that code?

Further, I would like to clean this function up; the code is an impossible
to follow mess. What I'd like to arrive at is at [2], however this also
needs(?) to address the -DHAVE_LIBC codepath.

Martin

[1] http://repo.rumpkernel.org/rumprun-xen and
https://github.com/mato/rump-mathopd
[2] https://gist.github.com/mato/512eb70f39565b030f73

----

In network_rx() we must push the same amount of requests back onto the
ring in the second loop that we consumed in the first loop. Otherwise
the ring will eventually starve itself of free request slots and no
packets will be delivered.

Signed-off-by: Martin Lucina <martin@lucina.net>
---
 extras/mini-os/netfront.c |   17 ++++-------------
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/extras/mini-os/netfront.c b/extras/mini-os/netfront.c
index 44c3995..33afc9c 100644
--- a/extras/mini-os/netfront.c
+++ b/extras/mini-os/netfront.c
@@ -99,14 +99,14 @@ void network_rx(struct netfront_dev *dev)
     struct netif_rx_response *rx;
     int nr_consumed, some, more, i, notify;
 
-
+    nr_consumed = 0;
 moretodo:
     rp = dev->rx.sring->rsp_prod;
     rmb(); /* Ensure we see queued responses up to 'rp'. */
     cons = dev->rx.rsp_cons;
 
-    for (nr_consumed = 0, some = 0;
-         (cons != rp) && !some;
+    for (some = 0;
+         (cons != rp);
          nr_consumed++, cons++)
     {
         struct net_buffer* buf;
@@ -115,17 +115,8 @@ moretodo:
 
         rx = RING_GET_RESPONSE(&dev->rx, cons);
 
-        if (rx->flags & NETRXF_extra_info)
-        {
-            printk("+++++++++++++++++++++ we have extras!\n");
-            continue;
-        }
-
-
-        if (rx->status == NETIF_RSP_NULL) continue;
-
         id = rx->id;
-        BUG_ON(id >= NET_TX_RING_SIZE);
+        BUG_ON(id >= NET_RX_RING_SIZE);
 
         buf = &dev->rx_buffers[id];
         page = (unsigned char*)buf->page;
-- 
1.7.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 Dec 04 14:09:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:09:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwX5n-0007K6-OD; Thu, 04 Dec 2014 14:09:15 +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 1XwX5l-0007K1-UN
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:09:14 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	79/56-11608-90B60845; Thu, 04 Dec 2014 14:09:13 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417702152!11013576!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14167 invoked from network); 4 Dec 2014 14:09:12 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 4 Dec 2014 14:09:12 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52296 helo=w510-wired)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XwX2q-00056w-9a; Thu, 04 Dec 2014 15:06:12 +0100
Date: Thu, 4 Dec 2014 15:09:09 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <308719815.20141204150909@eikelenboom.it>
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <548064EA.8090905@citrix.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
MIME-Version: 1.0
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
	slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 4, 2014, 2:43:06 PM, you wrote:

> On 04/12/14 13:10, Sander Eikelenboom wrote:
>> 
>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>> 
>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>>>
>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>>
>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>>>>
>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>>>>> It bypasses the need to worry about the PCI lock. 
>>>>>
>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>>>>> proposed). 
>>>>>
>>>>
>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
>> 
>>> It is only needed if the core won't provide one.
>> 
>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
>>> +{
>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
>>> +       struct device *dev = &pci->dev;
>>> +       int ret;
>>> +
>>> +       /* Already have a per-function reset? */
>>> +       if (pci_probe_reset_function(pci) == 0)
>>> +               return 0;
>>> +
>>> +       ret = device_create_file(dev, &dev_attr_reset);
>>> +       if (ret < 0)
>>> +               return ret;
>> +       dev_data->>created_reset_file = true;
>>> +       return 0;
>>> +}
>> 
>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
>> "pci.c:__pci_dev_reset" ?
>> 
>> The problem with that function is that from my testing it seems that the 
>> first option "pci_dev_specific_reset" always seems to return succes, so all the
>> other options are skipped (flr, pm, slot, bus). However the device it self is 
>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
>> none virtualization purposes and it's probably the least intrusive. For 
>> virtualization however it would be nice to be sure it resets properly, or have a 
>> way to force a specific reset routine.)

> Then you need work with the maintainer for those specific devices or
> drivers to fix their specific reset function.

> I'm not adding stuff to pciback to workaround broken quirks.

OK that's a pretty clear message there, so if one wants to use pci and vga
passthrough one should better use KVM and vfio-pci. 

vfio-pci has:
- logic to do the try-slot-bus-reset logic
- it has quirks specific to vga passthrough
implemented in from the looks of it a quite clean driver.
(the main issue with it so far was you could only seize devices based on 
vendor and device id, which can be a problem when you have multiple devices.
However that was resolved recently if i am correct.)

And neither of those will be supported by xen-pciback if i get your message 
right ?

--
Sander

> David



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:09:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:09:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwX5n-0007K6-OD; Thu, 04 Dec 2014 14:09:15 +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 1XwX5l-0007K1-UN
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:09:14 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	79/56-11608-90B60845; Thu, 04 Dec 2014 14:09:13 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417702152!11013576!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14167 invoked from network); 4 Dec 2014 14:09:12 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 4 Dec 2014 14:09:12 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52296 helo=w510-wired)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XwX2q-00056w-9a; Thu, 04 Dec 2014 15:06:12 +0100
Date: Thu, 4 Dec 2014 15:09:09 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <308719815.20141204150909@eikelenboom.it>
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <548064EA.8090905@citrix.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
MIME-Version: 1.0
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
	slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 4, 2014, 2:43:06 PM, you wrote:

> On 04/12/14 13:10, Sander Eikelenboom wrote:
>> 
>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>> 
>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>>>
>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>>
>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>>>>
>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>>>>> It bypasses the need to worry about the PCI lock. 
>>>>>
>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>>>>> proposed). 
>>>>>
>>>>
>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
>> 
>>> It is only needed if the core won't provide one.
>> 
>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
>>> +{
>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
>>> +       struct device *dev = &pci->dev;
>>> +       int ret;
>>> +
>>> +       /* Already have a per-function reset? */
>>> +       if (pci_probe_reset_function(pci) == 0)
>>> +               return 0;
>>> +
>>> +       ret = device_create_file(dev, &dev_attr_reset);
>>> +       if (ret < 0)
>>> +               return ret;
>> +       dev_data->>created_reset_file = true;
>>> +       return 0;
>>> +}
>> 
>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
>> "pci.c:__pci_dev_reset" ?
>> 
>> The problem with that function is that from my testing it seems that the 
>> first option "pci_dev_specific_reset" always seems to return succes, so all the
>> other options are skipped (flr, pm, slot, bus). However the device it self is 
>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
>> none virtualization purposes and it's probably the least intrusive. For 
>> virtualization however it would be nice to be sure it resets properly, or have a 
>> way to force a specific reset routine.)

> Then you need work with the maintainer for those specific devices or
> drivers to fix their specific reset function.

> I'm not adding stuff to pciback to workaround broken quirks.

OK that's a pretty clear message there, so if one wants to use pci and vga
passthrough one should better use KVM and vfio-pci. 

vfio-pci has:
- logic to do the try-slot-bus-reset logic
- it has quirks specific to vga passthrough
implemented in from the looks of it a quite clean driver.
(the main issue with it so far was you could only seize devices based on 
vendor and device id, which can be a problem when you have multiple devices.
However that was resolved recently if i am correct.)

And neither of those will be supported by xen-pciback if i get your message 
right ?

--
Sander

> David



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:14:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:14:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXAz-0007VP-GV; Thu, 04 Dec 2014 14:14:37 +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 1XwXAy-0007VK-3k
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:14:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	90/ED-09842-B4C60845; Thu, 04 Dec 2014 14:14:35 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417702474!13456224!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31346 invoked from network); 4 Dec 2014 14:14:34 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 4 Dec 2014 14:14:34 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52360 helo=w510-wired)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XwX83-0005XK-2S; Thu, 04 Dec 2014 15:11:35 +0100
Date: Thu, 4 Dec 2014 15:14:32 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <19110649790.20141204151432@eikelenboom.it>
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <308719815.20141204150909@eikelenboom.it>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
MIME-Version: 1.0
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
	slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Sander,

Thursday, December 4, 2014, 3:09:09 PM, you wrote:


> Thursday, December 4, 2014, 2:43:06 PM, you wrote:

>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>>> 
>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>>> 
>>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>>>>
>>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>>>
>>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>>>>>
>>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
>>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>>>>>> It bypasses the need to worry about the PCI lock. 
>>>>>>
>>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>>>>>> proposed). 
>>>>>>
>>>>>
>>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
>>> 
>>>> It is only needed if the core won't provide one.
>>> 
>>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
>>>> +{
>>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
>>>> +       struct device *dev = &pci->dev;
>>>> +       int ret;
>>>> +
>>>> +       /* Already have a per-function reset? */
>>>> +       if (pci_probe_reset_function(pci) == 0)
>>>> +               return 0;
>>>> +
>>>> +       ret = device_create_file(dev, &dev_attr_reset);
>>>> +       if (ret < 0)
>>>> +               return ret;
>>> +       dev_data->>created_reset_file = true;
>>>> +       return 0;
>>>> +}
>>> 
>>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
>>> "pci.c:__pci_dev_reset" ?
>>> 
>>> The problem with that function is that from my testing it seems that the 
>>> first option "pci_dev_specific_reset" always seems to return succes, so all the
>>> other options are skipped (flr, pm, slot, bus). However the device it self is 
>>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
>>> none virtualization purposes and it's probably the least intrusive. For 
>>> virtualization however it would be nice to be sure it resets properly, or have a 
>>> way to force a specific reset routine.)

>> Then you need work with the maintainer for those specific devices or
>> drivers to fix their specific reset function.

>> I'm not adding stuff to pciback to workaround broken quirks.

> OK that's a pretty clear message there, so if one wants to use pci and vga
> passthrough one should better use KVM and vfio-pci. 

> vfio-pci has:
> - logic to do the try-slot-bus-reset logic
> - it has quirks specific to vga passthrough
Hrmm have to correct my self because the vga-pt quirks are part of the vfio-pci 
part in qemu.

The try-slot-bus-reset logic is part of the kernel vfio-pci driver though and they faced the same locking issue it 
seems:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=61cf16d8bd38c3dc52033ea75d5b1f8368514a17
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=890ed578df82f5b7b5a874f9f2fa4f117305df5f

> implemented in from the looks of it a quite clean driver.
> (the main issue with it so far was you could only seize devices based on 
> vendor and device id, which can be a problem when you have multiple devices.
> However that was resolved recently if i am correct.)

> And neither of those will be supported by xen-pciback if i get your message 
> right ?

> --
> Sander

>> David



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:14:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:14:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXAz-0007VP-GV; Thu, 04 Dec 2014 14:14:37 +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 1XwXAy-0007VK-3k
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:14:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	90/ED-09842-B4C60845; Thu, 04 Dec 2014 14:14:35 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417702474!13456224!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31346 invoked from network); 4 Dec 2014 14:14:34 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 4 Dec 2014 14:14:34 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52360 helo=w510-wired)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XwX83-0005XK-2S; Thu, 04 Dec 2014 15:11:35 +0100
Date: Thu, 4 Dec 2014 15:14:32 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <19110649790.20141204151432@eikelenboom.it>
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <308719815.20141204150909@eikelenboom.it>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
MIME-Version: 1.0
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
	slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Sander,

Thursday, December 4, 2014, 3:09:09 PM, you wrote:


> Thursday, December 4, 2014, 2:43:06 PM, you wrote:

>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>>> 
>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>>> 
>>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>>>>
>>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>>>
>>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>>>>>
>>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
>>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>>>>>> It bypasses the need to worry about the PCI lock. 
>>>>>>
>>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>>>>>> proposed). 
>>>>>>
>>>>>
>>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
>>> 
>>>> It is only needed if the core won't provide one.
>>> 
>>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
>>>> +{
>>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
>>>> +       struct device *dev = &pci->dev;
>>>> +       int ret;
>>>> +
>>>> +       /* Already have a per-function reset? */
>>>> +       if (pci_probe_reset_function(pci) == 0)
>>>> +               return 0;
>>>> +
>>>> +       ret = device_create_file(dev, &dev_attr_reset);
>>>> +       if (ret < 0)
>>>> +               return ret;
>>> +       dev_data->>created_reset_file = true;
>>>> +       return 0;
>>>> +}
>>> 
>>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
>>> "pci.c:__pci_dev_reset" ?
>>> 
>>> The problem with that function is that from my testing it seems that the 
>>> first option "pci_dev_specific_reset" always seems to return succes, so all the
>>> other options are skipped (flr, pm, slot, bus). However the device it self is 
>>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
>>> none virtualization purposes and it's probably the least intrusive. For 
>>> virtualization however it would be nice to be sure it resets properly, or have a 
>>> way to force a specific reset routine.)

>> Then you need work with the maintainer for those specific devices or
>> drivers to fix their specific reset function.

>> I'm not adding stuff to pciback to workaround broken quirks.

> OK that's a pretty clear message there, so if one wants to use pci and vga
> passthrough one should better use KVM and vfio-pci. 

> vfio-pci has:
> - logic to do the try-slot-bus-reset logic
> - it has quirks specific to vga passthrough
Hrmm have to correct my self because the vga-pt quirks are part of the vfio-pci 
part in qemu.

The try-slot-bus-reset logic is part of the kernel vfio-pci driver though and they faced the same locking issue it 
seems:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=61cf16d8bd38c3dc52033ea75d5b1f8368514a17
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=890ed578df82f5b7b5a874f9f2fa4f117305df5f

> implemented in from the looks of it a quite clean driver.
> (the main issue with it so far was you could only seize devices based on 
> vendor and device id, which can be a problem when you have multiple devices.
> However that was resolved recently if i am correct.)

> And neither of those will be supported by xen-pciback if i get your message 
> right ?

> --
> Sander

>> David



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:23:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXJ2-0008KF-Ej; Thu, 04 Dec 2014 14:22: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 1XwXJ1-0008KA-TY
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:22:56 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B5/CD-09842-F3E60845; Thu, 04 Dec 2014 14:22:55 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417702973!13426525!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 29150 invoked from network); 4 Dec 2014 14:22:54 -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;
	4 Dec 2014 14:22:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200088378"
Message-ID: <54806E39.4040308@citrix.com>
Date: Thu, 4 Dec 2014 14:22:49 +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: <1417697910-19824-1-git-send-email-andrew.cooper3@citrix.com>
	<54807097020000780004CBC7@mail.emea.novell.com>
In-Reply-To: <54807097020000780004CBC7@mail.emea.novell.com>
X-DLP: MIA1
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] x86/stack: Avoid peeking into
 unmapped guard pages when dumping Xens stack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/12/14 13:32, Jan Beulich wrote:
>>>> On 04.12.14 at 13:58, <andrew.cooper3@citrix.com> wrote:
>> Konrad: I am requesting a release ack for this change.  It aids the clarity of
>> certain crash information, and prevents cascade pagefaults in certain
>> circumstances, which would prevent execution of the crash kernel or a system
>> reboot.
> With
>
> #ifndef NDEBUG
> #define MEMORY_GUARD
> #endif
>
> I don't think this qualifies as a necessary bug fix at this point of 4.5.

Without frame pointers, you get a call trace of almost complete junk,
spanning 6 pages.  This is admittedly less bad, but still a bug.

>
>> +unsigned long get_stack_trace_bottom(unsigned long sp)
>> +{
>> +    switch ( get_stack_page(sp) )
>> +    {
>> +    case 0 ... 2:
>> +        return ROUNDUP(sp, PAGE_SIZE) -
>> +            offsetof(struct cpu_user_regs, es) - sizeof(unsigned long);
> The only concern I have here is that this may wrongly truncate a
> dump/trace when one of the IST stacks overflowed. But I think we
> can live with that - an overflow of the first one would already have
> similar behavior today.

I was already planning to do some improvements for 4.6, based on work
developed for the xen-crashdump-analyser which has proved very useful
when investigating XenServer crashes.  This includes the ability to spot
valid exception frames, and follow them back to the primary stack
through a set of nested IST faults.

Along the bugfix line, there are some other issues which would be nice
to fix.  Putting a guard pages in stack pages 0 and 7 to completely
prevent a stack overflow on cpu0 from sliding into Xens BSS.  This would
leave 3 unmapped guard pages, 2 pages of primary stack and 3 IST
stacks.  The syscall trampoline can safely live at the bottom of the #DF
stack.

For AMD hardware, the lack of TR switch on vmexit causes any interaction
with MEMORY_GUARD to be a triple fault as we currently must disable IST
for security reasons.  I am hoping that the overhead of switching the
task register will prove to be negligible, and that we can run without
playing any IST games in the slightest.  If not, then the switch can
reasonably be gated on MEMORY_GUARD, in which case we still
conditionally keep the IST games, but don't take the TR switch overhead
in non-debug builds.

>
>> +
>> +#ifndef MEMORY_GUARD
>> +    case 3 ... 5:
>> +#endif
>> +    case 6 ... 7:
>> +        return ROUNDUP(sp, STACK_SIZE) -
>> +            sizeof(struct cpu_info) - sizeof(unsigned long);
>> +
>> +#ifdef MEMORY_GUARD
>> +    case 3 ... 5:
>> +#endif
>> +    default:
> What is the #ifdef good for when this is "default:" anyway? With
> this dropped (also from the other function)
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Ah yes - a side effect of the way the patch was developed.  They can be
dropped.

~Andrew


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:23:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXJ2-0008KF-Ej; Thu, 04 Dec 2014 14:22: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 1XwXJ1-0008KA-TY
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:22:56 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B5/CD-09842-F3E60845; Thu, 04 Dec 2014 14:22:55 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417702973!13426525!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 29150 invoked from network); 4 Dec 2014 14:22:54 -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;
	4 Dec 2014 14:22:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200088378"
Message-ID: <54806E39.4040308@citrix.com>
Date: Thu, 4 Dec 2014 14:22:49 +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: <1417697910-19824-1-git-send-email-andrew.cooper3@citrix.com>
	<54807097020000780004CBC7@mail.emea.novell.com>
In-Reply-To: <54807097020000780004CBC7@mail.emea.novell.com>
X-DLP: MIA1
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] x86/stack: Avoid peeking into
 unmapped guard pages when dumping Xens stack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/12/14 13:32, Jan Beulich wrote:
>>>> On 04.12.14 at 13:58, <andrew.cooper3@citrix.com> wrote:
>> Konrad: I am requesting a release ack for this change.  It aids the clarity of
>> certain crash information, and prevents cascade pagefaults in certain
>> circumstances, which would prevent execution of the crash kernel or a system
>> reboot.
> With
>
> #ifndef NDEBUG
> #define MEMORY_GUARD
> #endif
>
> I don't think this qualifies as a necessary bug fix at this point of 4.5.

Without frame pointers, you get a call trace of almost complete junk,
spanning 6 pages.  This is admittedly less bad, but still a bug.

>
>> +unsigned long get_stack_trace_bottom(unsigned long sp)
>> +{
>> +    switch ( get_stack_page(sp) )
>> +    {
>> +    case 0 ... 2:
>> +        return ROUNDUP(sp, PAGE_SIZE) -
>> +            offsetof(struct cpu_user_regs, es) - sizeof(unsigned long);
> The only concern I have here is that this may wrongly truncate a
> dump/trace when one of the IST stacks overflowed. But I think we
> can live with that - an overflow of the first one would already have
> similar behavior today.

I was already planning to do some improvements for 4.6, based on work
developed for the xen-crashdump-analyser which has proved very useful
when investigating XenServer crashes.  This includes the ability to spot
valid exception frames, and follow them back to the primary stack
through a set of nested IST faults.

Along the bugfix line, there are some other issues which would be nice
to fix.  Putting a guard pages in stack pages 0 and 7 to completely
prevent a stack overflow on cpu0 from sliding into Xens BSS.  This would
leave 3 unmapped guard pages, 2 pages of primary stack and 3 IST
stacks.  The syscall trampoline can safely live at the bottom of the #DF
stack.

For AMD hardware, the lack of TR switch on vmexit causes any interaction
with MEMORY_GUARD to be a triple fault as we currently must disable IST
for security reasons.  I am hoping that the overhead of switching the
task register will prove to be negligible, and that we can run without
playing any IST games in the slightest.  If not, then the switch can
reasonably be gated on MEMORY_GUARD, in which case we still
conditionally keep the IST games, but don't take the TR switch overhead
in non-debug builds.

>
>> +
>> +#ifndef MEMORY_GUARD
>> +    case 3 ... 5:
>> +#endif
>> +    case 6 ... 7:
>> +        return ROUNDUP(sp, STACK_SIZE) -
>> +            sizeof(struct cpu_info) - sizeof(unsigned long);
>> +
>> +#ifdef MEMORY_GUARD
>> +    case 3 ... 5:
>> +#endif
>> +    default:
> What is the #ifdef good for when this is "default:" anyway? With
> this dropped (also from the other function)
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Ah yes - a side effect of the way the patch was developed.  They can be
dropped.

~Andrew


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:28:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXNw-0008Su-9m; Thu, 04 Dec 2014 14:28:00 +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 1XwXNv-0008So-MO
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:27:59 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	73/E0-15461-F6F60845; Thu, 04 Dec 2014 14:27:59 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417703278!6129263!1
X-Originating-IP: [62.176.169.44]
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 21615 invoked from network); 4 Dec 2014 14:27:58 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 14:27:58 -0000
Received: from dezo.moloch.sk (unknown [92.240.231.146])
	by mail.moloch.sk (Postfix) with ESMTPSA id E4A7018050C7;
	Thu,  4 Dec 2014 15:27:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1417703277;
	bh=XfhIpuj3lX+bz2jdNnj35OWZd4oDTL+RNbzY8inl0Ec=;
	h=Date:From:To:Cc:Subject:From;
	b=hj0HWTkPryCPsOLpN/coguKbUDSeZvn0NkYo/SayeZZrR12cZULiq7HcjQsKM5aKL
	fxvJ0qqwNY4JuUvmxelnIJS5DUV5tGeYx8FOWpNRGnH85cNFsdYoqwSuhdqxpFdBNd
	gOrl52o/l5s8ePfRDYcl+04dWgqLUWaKLnd5WvPr3lhe5cruXMQAJ8VXOIF9EulsYT
	UqXXRy+XysWLGvGVcehM3CPCjS05nti+iJWcv3TzZUIiQqAzNt6fQuysf7QwvSbMNK
	Ng1RMO+PGz7q3IYGqYGG2TGytjZlcNyVAATZ2o9jspqFGmbhVY63ESpbNq2XAxvNl+
	SmO+FZQDyLrxQ==
Received: by dezo.moloch.sk (Postfix, from userid 1000)
	id 802A9D05952E; Thu,  4 Dec 2014 15:27:57 +0100 (CET)
Date: Thu, 4 Dec 2014 15:27:57 +0100
From: Martin Lucina <martin@lucina.net>
To: xen-devel@lists.xen.org
Message-ID: <20141204142757.GD11192@dezo.moloch.sk>
Mail-Followup-To: xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: rumpkernel-users@lists.sourceforge.net,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>
Subject: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

In rumprun-xen [1] we use Mini-OS as a "base firmware" layer in our stack.
Currently we are using a slightly bastardized fork of the xen.git Mini-OS.

We would like to avoid this turning into a permanent fork. Following
previous discussion [2] on and openmirage-devel I would like to coordinate
upstreaming our changes if possible.

The biggest change which needs to be done is cleaning up the Mini-OS
namespace. This is necessary as we link Mini-OS with the application, rump
kernel and NetBSD libc to get a full application stack.

The changes as implemented in a semi-automated fashion for the Mini-OS used
by rumprun-xen can be viewed in the (since merged) pull request at [3]:

- 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.

Questions:

- Is there a general interest in upstreaming this work?
- Upstream Mini-OS provides things we (rumpkernel.org) don't need (stub
  "libc", ...). If we are to move to upstream then we will need to do a
  more general cleanup of Mini-OS to make these pluggable. Again, is there
  upstream interest in this work?
- As there is no formal API for Mini-OS. My changes only address the
  "public" functionality used by rumprun-xen. Other users mileage will
  vary; who else should I coordinate with?
- I have not namespaced macros such as local_irq_save(). Should this be
  done? 
  
  Also, the driver namespaces have been preserved (since I was lazy), these
  should probably be renamed under the minios namespace; it's plausible
  some day someone will try to link an application with a function called
  blkfront_init().

All comments and review welcome.

Martin

[1] http://repo.rumpkernel.org/rumprun-xen
[2] http://thread.gmane.org/gmane.comp.rumpkernel.user/514
[3] https://github.com/rumpkernel/rumprun-xen/pull/10

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:28:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXNw-0008Su-9m; Thu, 04 Dec 2014 14:28:00 +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 1XwXNv-0008So-MO
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:27:59 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	73/E0-15461-F6F60845; Thu, 04 Dec 2014 14:27:59 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417703278!6129263!1
X-Originating-IP: [62.176.169.44]
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 21615 invoked from network); 4 Dec 2014 14:27:58 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 14:27:58 -0000
Received: from dezo.moloch.sk (unknown [92.240.231.146])
	by mail.moloch.sk (Postfix) with ESMTPSA id E4A7018050C7;
	Thu,  4 Dec 2014 15:27:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1417703277;
	bh=XfhIpuj3lX+bz2jdNnj35OWZd4oDTL+RNbzY8inl0Ec=;
	h=Date:From:To:Cc:Subject:From;
	b=hj0HWTkPryCPsOLpN/coguKbUDSeZvn0NkYo/SayeZZrR12cZULiq7HcjQsKM5aKL
	fxvJ0qqwNY4JuUvmxelnIJS5DUV5tGeYx8FOWpNRGnH85cNFsdYoqwSuhdqxpFdBNd
	gOrl52o/l5s8ePfRDYcl+04dWgqLUWaKLnd5WvPr3lhe5cruXMQAJ8VXOIF9EulsYT
	UqXXRy+XysWLGvGVcehM3CPCjS05nti+iJWcv3TzZUIiQqAzNt6fQuysf7QwvSbMNK
	Ng1RMO+PGz7q3IYGqYGG2TGytjZlcNyVAATZ2o9jspqFGmbhVY63ESpbNq2XAxvNl+
	SmO+FZQDyLrxQ==
Received: by dezo.moloch.sk (Postfix, from userid 1000)
	id 802A9D05952E; Thu,  4 Dec 2014 15:27:57 +0100 (CET)
Date: Thu, 4 Dec 2014 15:27:57 +0100
From: Martin Lucina <martin@lucina.net>
To: xen-devel@lists.xen.org
Message-ID: <20141204142757.GD11192@dezo.moloch.sk>
Mail-Followup-To: xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: rumpkernel-users@lists.sourceforge.net,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>
Subject: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

In rumprun-xen [1] we use Mini-OS as a "base firmware" layer in our stack.
Currently we are using a slightly bastardized fork of the xen.git Mini-OS.

We would like to avoid this turning into a permanent fork. Following
previous discussion [2] on and openmirage-devel I would like to coordinate
upstreaming our changes if possible.

The biggest change which needs to be done is cleaning up the Mini-OS
namespace. This is necessary as we link Mini-OS with the application, rump
kernel and NetBSD libc to get a full application stack.

The changes as implemented in a semi-automated fashion for the Mini-OS used
by rumprun-xen can be viewed in the (since merged) pull request at [3]:

- 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.

Questions:

- Is there a general interest in upstreaming this work?
- Upstream Mini-OS provides things we (rumpkernel.org) don't need (stub
  "libc", ...). If we are to move to upstream then we will need to do a
  more general cleanup of Mini-OS to make these pluggable. Again, is there
  upstream interest in this work?
- As there is no formal API for Mini-OS. My changes only address the
  "public" functionality used by rumprun-xen. Other users mileage will
  vary; who else should I coordinate with?
- I have not namespaced macros such as local_irq_save(). Should this be
  done? 
  
  Also, the driver namespaces have been preserved (since I was lazy), these
  should probably be renamed under the minios namespace; it's plausible
  some day someone will try to link an application with a function called
  blkfront_init().

All comments and review welcome.

Martin

[1] http://repo.rumpkernel.org/rumprun-xen
[2] http://thread.gmane.org/gmane.comp.rumpkernel.user/514
[3] https://github.com/rumpkernel/rumprun-xen/pull/10

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:29:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14: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 1XwXPE-00005f-OV; Thu, 04 Dec 2014 14:29:20 +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 1XwXPD-00005U-1M
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:29:19 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	9F/C6-07724-EBF60845; Thu, 04 Dec 2014 14:29:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417703356!11078748!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 15571 invoked from network); 4 Dec 2014 14:29:17 -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 Dec 2014 14:29:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200092867"
Message-ID: <54806FA2.6080406@citrix.com>
Date: Thu, 4 Dec 2014 14:28: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: Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
In-Reply-To: <5480748B020000780004CBFC@mail.emea.novell.com>
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-develList <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 04/12/14 13:49, Jan Beulich wrote:
>>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>> 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.
> With no-one else voicing an opinion:
>
> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
>
> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
>
> For the latter, we're fine even without further consideration. For the
> former, the two operations actively using the continuation encoding
> are tools-only ones. Since we're fine to alter the tools only interfaces,
> and since it was intended for the tools-only HVM-ops to be split off
> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
> would then no longer be a problem. Plus, in the worst case we could
> always introduce yet another hypercall if we ran out of numbers.

Are you suggesting that we make a new hvmctl now and remove the hvmop
mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
subsequently remove it even if all continuable hypercalls move to a
separate hypercall.

>
> Consequently what I'd like to propose (and I guess I'll craft a patch
> as soon as I finished this mail) is that we add comments to these
> masks (also the memop one) to make clear that they mustn't change.
> Additionally for forward compatibility I'd also like to add checks for
> the upper bits to be zero for any of the sub-ops that don't actually
> use them to encode continuation information. Konrad, would you
> consider doing so acceptable for 4.5?

I will have to re-work around this new check for XenServer
compatibility, but I suppose that is fine.  I am certainly in favour of
leaving an ABI comment with the op masks.

~Andrew


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:29:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14: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 1XwXPE-00005f-OV; Thu, 04 Dec 2014 14:29:20 +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 1XwXPD-00005U-1M
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:29:19 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	9F/C6-07724-EBF60845; Thu, 04 Dec 2014 14:29:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417703356!11078748!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 15571 invoked from network); 4 Dec 2014 14:29:17 -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 Dec 2014 14:29:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200092867"
Message-ID: <54806FA2.6080406@citrix.com>
Date: Thu, 4 Dec 2014 14:28: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: Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
In-Reply-To: <5480748B020000780004CBFC@mail.emea.novell.com>
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-develList <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 04/12/14 13:49, Jan Beulich wrote:
>>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>> 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.
> With no-one else voicing an opinion:
>
> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
>
> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
>
> For the latter, we're fine even without further consideration. For the
> former, the two operations actively using the continuation encoding
> are tools-only ones. Since we're fine to alter the tools only interfaces,
> and since it was intended for the tools-only HVM-ops to be split off
> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
> would then no longer be a problem. Plus, in the worst case we could
> always introduce yet another hypercall if we ran out of numbers.

Are you suggesting that we make a new hvmctl now and remove the hvmop
mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
subsequently remove it even if all continuable hypercalls move to a
separate hypercall.

>
> Consequently what I'd like to propose (and I guess I'll craft a patch
> as soon as I finished this mail) is that we add comments to these
> masks (also the memop one) to make clear that they mustn't change.
> Additionally for forward compatibility I'd also like to add checks for
> the upper bits to be zero for any of the sub-ops that don't actually
> use them to encode continuation information. Konrad, would you
> consider doing so acceptable for 4.5?

I will have to re-work around this new check for XenServer
compatibility, but I suppose that is fine.  I am certainly in favour of
leaving an ABI comment with the op masks.

~Andrew


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:29:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:29:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXPk-0000AR-Bz; Thu, 04 Dec 2014 14:29:52 +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 1XwXPi-0000A2-Bm
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:29:50 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	33/19-02699-DDF60845; Thu, 04 Dec 2014 14:29:49 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417703387!13026872!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28910 invoked from network); 4 Dec 2014 14:29:48 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 14:29:48 -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 sB4ETH6G000403
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 4 Dec 2014 09:29:17 -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 sB4ETCtK015398
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2014 09:29:14 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Olaf Hering <olaf@aepfle.de>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<20141204111715.GA15916@aepfle.de>
Date: Thu, 04 Dec 2014 15:29:12 +0100
In-Reply-To: <20141204111715.GA15916@aepfle.de> (Olaf Hering's message of
	"Thu, 4 Dec 2014 12:17:15 +0100")
Message-ID: <87a933ij47.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: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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

Olaf Hering <olaf@aepfle.de> writes:

> On Wed, Dec 03, Vitaly Kuznetsov wrote:
>
>> 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:
>
> Its not clear to me how thew old kernel starts the new kernel.
> How and where is that done?

It is done by linux kernel itself, I bring nothing new into the
picture. It all works like this:
1) Original guest does HYPERVISOR_sched_op(SCHEDOP_shutdown, r = { .reason =
SHUTDOWN_soft_reset})
2) All this rebuild machinery happens including copying HVM context
3) New guest resumes from where old did the hypercall
4) Kernel does kexec and new kernel is being booted.

>
> Olaf

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:29:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:29:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXPk-0000AR-Bz; Thu, 04 Dec 2014 14:29:52 +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 1XwXPi-0000A2-Bm
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:29:50 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	33/19-02699-DDF60845; Thu, 04 Dec 2014 14:29:49 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417703387!13026872!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28910 invoked from network); 4 Dec 2014 14:29:48 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 14:29:48 -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 sB4ETH6G000403
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 4 Dec 2014 09:29:17 -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 sB4ETCtK015398
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2014 09:29:14 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Olaf Hering <olaf@aepfle.de>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<20141204111715.GA15916@aepfle.de>
Date: Thu, 04 Dec 2014 15:29:12 +0100
In-Reply-To: <20141204111715.GA15916@aepfle.de> (Olaf Hering's message of
	"Thu, 4 Dec 2014 12:17:15 +0100")
Message-ID: <87a933ij47.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: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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

Olaf Hering <olaf@aepfle.de> writes:

> On Wed, Dec 03, Vitaly Kuznetsov wrote:
>
>> 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:
>
> Its not clear to me how thew old kernel starts the new kernel.
> How and where is that done?

It is done by linux kernel itself, I bring nothing new into the
picture. It all works like this:
1) Original guest does HYPERVISOR_sched_op(SCHEDOP_shutdown, r = { .reason =
SHUTDOWN_soft_reset})
2) All this rebuild machinery happens including copying HVM context
3) New guest resumes from where old did the hypercall
4) Kernel does kexec and new kernel is being booted.

>
> Olaf

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:31:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14: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 1XwXR8-0000Kx-Qp; Thu, 04 Dec 2014 14:31:18 +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 1XwXR7-0000Kn-Hm
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:31:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5B/57-15461-43070845; Thu, 04 Dec 2014 14:31:16 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417703474!13402065!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 19638 invoked from network); 4 Dec 2014 14:31:16 -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 Dec 2014 14:31:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199738434"
Message-ID: <5480702F.2060004@citrix.com>
Date: Thu, 4 Dec 2014 14:31:11 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
In-Reply-To: <308719815.20141204150909@eikelenboom.it>
X-DLP: MIA1
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 14:09, Sander Eikelenboom wrote:
> 
> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
> 
>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>>>
>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>>>
>>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>>>>
>>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>>>
>>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>>>>>
>>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
>>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>>>>>> It bypasses the need to worry about the PCI lock. 
>>>>>>
>>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>>>>>> proposed). 
>>>>>>
>>>>>
>>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
>>>
>>>> It is only needed if the core won't provide one.
>>>
>>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
>>>> +{
>>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
>>>> +       struct device *dev = &pci->dev;
>>>> +       int ret;
>>>> +
>>>> +       /* Already have a per-function reset? */
>>>> +       if (pci_probe_reset_function(pci) == 0)
>>>> +               return 0;
>>>> +
>>>> +       ret = device_create_file(dev, &dev_attr_reset);
>>>> +       if (ret < 0)
>>>> +               return ret;
>>> +       dev_data->>created_reset_file = true;
>>>> +       return 0;
>>>> +}
>>>
>>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
>>> "pci.c:__pci_dev_reset" ?
>>>
>>> The problem with that function is that from my testing it seems that the 
>>> first option "pci_dev_specific_reset" always seems to return succes, so all the
>>> other options are skipped (flr, pm, slot, bus). However the device it self is 
>>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
>>> none virtualization purposes and it's probably the least intrusive. For 
>>> virtualization however it would be nice to be sure it resets properly, or have a 
>>> way to force a specific reset routine.)
> 
>> Then you need work with the maintainer for those specific devices or
>> drivers to fix their specific reset function.
> 
>> I'm not adding stuff to pciback to workaround broken quirks.
> 
> OK that's a pretty clear message there, so if one wants to use pci and vga
> passthrough one should better use KVM and vfio-pci.

Have you (or anyone else) ever raised the problem with the broken reset
quirk for certain devices with the relevant maintainer?

> vfio-pci has:
> - logic to do the try-slot-bus-reset logic

Just because vfio-pci fixed it incorrectly doesn't mean pciback has to
as well.

It makes no sense for both pciback and vfio-pci to workaround problems
with pci_function_reset() in different ways -- it should be fixed in the
core PCI code so both can benefit and make use of the same code.

David


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:31:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14: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 1XwXR8-0000Kx-Qp; Thu, 04 Dec 2014 14:31:18 +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 1XwXR7-0000Kn-Hm
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:31:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5B/57-15461-43070845; Thu, 04 Dec 2014 14:31:16 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417703474!13402065!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 19638 invoked from network); 4 Dec 2014 14:31:16 -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 Dec 2014 14:31:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="199738434"
Message-ID: <5480702F.2060004@citrix.com>
Date: Thu, 4 Dec 2014 14:31:11 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
In-Reply-To: <308719815.20141204150909@eikelenboom.it>
X-DLP: MIA1
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 14:09, Sander Eikelenboom wrote:
> 
> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
> 
>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>>>
>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>>>
>>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>>>>
>>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>>>
>>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>>>>>
>>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
>>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>>>>>> It bypasses the need to worry about the PCI lock. 
>>>>>>
>>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>>>>>> proposed). 
>>>>>>
>>>>>
>>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
>>>
>>>> It is only needed if the core won't provide one.
>>>
>>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
>>>> +{
>>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
>>>> +       struct device *dev = &pci->dev;
>>>> +       int ret;
>>>> +
>>>> +       /* Already have a per-function reset? */
>>>> +       if (pci_probe_reset_function(pci) == 0)
>>>> +               return 0;
>>>> +
>>>> +       ret = device_create_file(dev, &dev_attr_reset);
>>>> +       if (ret < 0)
>>>> +               return ret;
>>> +       dev_data->>created_reset_file = true;
>>>> +       return 0;
>>>> +}
>>>
>>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
>>> "pci.c:__pci_dev_reset" ?
>>>
>>> The problem with that function is that from my testing it seems that the 
>>> first option "pci_dev_specific_reset" always seems to return succes, so all the
>>> other options are skipped (flr, pm, slot, bus). However the device it self is 
>>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
>>> none virtualization purposes and it's probably the least intrusive. For 
>>> virtualization however it would be nice to be sure it resets properly, or have a 
>>> way to force a specific reset routine.)
> 
>> Then you need work with the maintainer for those specific devices or
>> drivers to fix their specific reset function.
> 
>> I'm not adding stuff to pciback to workaround broken quirks.
> 
> OK that's a pretty clear message there, so if one wants to use pci and vga
> passthrough one should better use KVM and vfio-pci.

Have you (or anyone else) ever raised the problem with the broken reset
quirk for certain devices with the relevant maintainer?

> vfio-pci has:
> - logic to do the try-slot-bus-reset logic

Just because vfio-pci fixed it incorrectly doesn't mean pciback has to
as well.

It makes no sense for both pciback and vfio-pci to workaround problems
with pci_function_reset() in different ways -- it should be fixed in the
core PCI code so both can benefit and make use of the same code.

David


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:31:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:31:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXRO-0000OE-6w; Thu, 04 Dec 2014 14:31:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XwXRM-0000Nv-Ul
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:31:33 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	DD/C5-27785-44070845; Thu, 04 Dec 2014 14:31:32 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417703487!12994344!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10538 invoked from network); 4 Dec 2014 14:31:30 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 14:31:30 -0000
Received: from 172.24.2.119 (EHLO SZXEMA412-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AYE40923; Thu, 04 Dec 2014 22:31:20 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id
	14.03.0158.001; Thu, 4 Dec 2014 22:31:12 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Zoltan Kiss <zoltan.kiss@linaro.org>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIAAiqFg//+jdIAAEh4VUA==
Date: Thu, 4 Dec 2014 14:31:12 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE23933926@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
	<54806315.6010007@linaro.org>
In-Reply-To: <54806315.6010007@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020205.54807038.0275, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.177,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2c17022d9804b70b5280b9a23b4c1bed
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>, "Luohao
	\(brian\)" <brian.luohao@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Zoltan Kiss [mailto:zoltan.kiss@linaro.org]
> Sent: Thursday, December 04, 2014 9:35 PM
> To: Zhangleiqiang (Trump); Wei Liu; xen-devel@lists.xen.org
> Cc: Xiaoding (B); Zhuangyuxin; zhangleiqiang; Luohao (brian); Yuzhou (C)
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> 
> 
> On 04/12/14 12:09, Zhangleiqiang (Trump) wrote:
> >> I think that's expected, because guest RX data path still uses
> >> grant_copy while
> >> >guest TX uses grant_map to do zero-copy transmit.
> > As I understand, the RX process is as follows:
> > 1. Phy NIC receive packet
> > 2. XEN Hypervisor trigger interrupt to Dom0 3. Dom0' s NIC driver do
> > the "RX" operation, and the packet is stored into SKB which is also
> > owned/shared with netback
> Not that easy. There is something between the NIC driver and netback which
> directs the packets, e.g. the old bridge driver, ovs, or the IP stack of the kernel.
> > 4. NetBack notify netfront through event channel that a packet is
> > receiving 5. Netfront grant a buffer for receiving and notify netback
> > the GR (if using grant-resue mechanism, netfront just notify the GR to
> > netback) through IO Ring
> It looks a bit confusing in the code, but netfront put "requests" on the ring
> buffer, which contains the grant ref of the guest page where the backend can
> copy. When the packet comes, netback consumes these requests and send
> back a response telling the guest the grant copy of the packet finished, it can
> start handling the data. (sending a response means it's placing a response in
> the ring and trigger the event channel) And ideally netback should always have
> requests in the ring, so it doesn't have to wait for the guest to fill it up.

> > 6. NetBack do the grant_copy to copy packet from its SKB to the buffer
> > referenced by GR, and notify netfront through event channel 7.
> > Netfront copy the data from buffer to user-level app's SKB
> Or wherever that SKB should go, yes. Like with any received packet on a real
> network interface.
> >
> > Am I right? Why not using zero-copy transmit in guest RX data pash too ?
> Because that means you are mapping that memory to the guest, and you won't
> have any guarantee when the guest will release them. And netback can't just
> unmap them forcibly after a timeout, because finding a correct timeout value
> would be quite impossible.
> A malicious/buggy/overloaded guest can hold on to Dom0 memory indefinitely,
> but it even becomes worse if the memory came from another
> guest: you can't shutdown that guest for example, until all its memory is
> returned to him.

Thanks for your detailed explanation about RX data path, I have get it, :)

About the issue that poor performance between DomU to DomU, but high throughout between Dom0 to remote Dom0/DomU mentioned in my previous mail, do you have any idea about it? 

I am wondering if netfront/netback can be optimized to reach the 10Gbps throughout between DomUs running on different hosts connected with 10GE network. Currently, it seems like the TX is not the bottleneck, because we can reach the aggregate throughout of 9Gbps when sending packets from one DomU to other 3 DomUs running on different host. So I think the bottleneck maybe the RX, are you agreed with me?

I am wondering what is the main reason that prevent RX to reach the higher throughout? Compared to KVM+virtio+vhost, which can reach high throughout, the RX has extra grantcopy operation, and the grantcopy operation may be one reason for it. Do you have any idea about it too?

> 
> Regards,
> 
> Zoli

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:31:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:31:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXRO-0000OE-6w; Thu, 04 Dec 2014 14:31:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XwXRM-0000Nv-Ul
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:31:33 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	DD/C5-27785-44070845; Thu, 04 Dec 2014 14:31:32 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417703487!12994344!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10538 invoked from network); 4 Dec 2014 14:31:30 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 14:31:30 -0000
Received: from 172.24.2.119 (EHLO SZXEMA412-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AYE40923; Thu, 04 Dec 2014 22:31:20 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id
	14.03.0158.001; Thu, 4 Dec 2014 22:31:12 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Zoltan Kiss <zoltan.kiss@linaro.org>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIAAiqFg//+jdIAAEh4VUA==
Date: Thu, 4 Dec 2014 14:31:12 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE23933926@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
	<54806315.6010007@linaro.org>
In-Reply-To: <54806315.6010007@linaro.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020205.54807038.0275, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.177,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2c17022d9804b70b5280b9a23b4c1bed
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>, "Luohao
	\(brian\)" <brian.luohao@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Zoltan Kiss [mailto:zoltan.kiss@linaro.org]
> Sent: Thursday, December 04, 2014 9:35 PM
> To: Zhangleiqiang (Trump); Wei Liu; xen-devel@lists.xen.org
> Cc: Xiaoding (B); Zhuangyuxin; zhangleiqiang; Luohao (brian); Yuzhou (C)
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> 
> 
> On 04/12/14 12:09, Zhangleiqiang (Trump) wrote:
> >> I think that's expected, because guest RX data path still uses
> >> grant_copy while
> >> >guest TX uses grant_map to do zero-copy transmit.
> > As I understand, the RX process is as follows:
> > 1. Phy NIC receive packet
> > 2. XEN Hypervisor trigger interrupt to Dom0 3. Dom0' s NIC driver do
> > the "RX" operation, and the packet is stored into SKB which is also
> > owned/shared with netback
> Not that easy. There is something between the NIC driver and netback which
> directs the packets, e.g. the old bridge driver, ovs, or the IP stack of the kernel.
> > 4. NetBack notify netfront through event channel that a packet is
> > receiving 5. Netfront grant a buffer for receiving and notify netback
> > the GR (if using grant-resue mechanism, netfront just notify the GR to
> > netback) through IO Ring
> It looks a bit confusing in the code, but netfront put "requests" on the ring
> buffer, which contains the grant ref of the guest page where the backend can
> copy. When the packet comes, netback consumes these requests and send
> back a response telling the guest the grant copy of the packet finished, it can
> start handling the data. (sending a response means it's placing a response in
> the ring and trigger the event channel) And ideally netback should always have
> requests in the ring, so it doesn't have to wait for the guest to fill it up.

> > 6. NetBack do the grant_copy to copy packet from its SKB to the buffer
> > referenced by GR, and notify netfront through event channel 7.
> > Netfront copy the data from buffer to user-level app's SKB
> Or wherever that SKB should go, yes. Like with any received packet on a real
> network interface.
> >
> > Am I right? Why not using zero-copy transmit in guest RX data pash too ?
> Because that means you are mapping that memory to the guest, and you won't
> have any guarantee when the guest will release them. And netback can't just
> unmap them forcibly after a timeout, because finding a correct timeout value
> would be quite impossible.
> A malicious/buggy/overloaded guest can hold on to Dom0 memory indefinitely,
> but it even becomes worse if the memory came from another
> guest: you can't shutdown that guest for example, until all its memory is
> returned to him.

Thanks for your detailed explanation about RX data path, I have get it, :)

About the issue that poor performance between DomU to DomU, but high throughout between Dom0 to remote Dom0/DomU mentioned in my previous mail, do you have any idea about it? 

I am wondering if netfront/netback can be optimized to reach the 10Gbps throughout between DomUs running on different hosts connected with 10GE network. Currently, it seems like the TX is not the bottleneck, because we can reach the aggregate throughout of 9Gbps when sending packets from one DomU to other 3 DomUs running on different host. So I think the bottleneck maybe the RX, are you agreed with me?

I am wondering what is the main reason that prevent RX to reach the higher throughout? Compared to KVM+virtio+vhost, which can reach high throughout, the RX has extra grantcopy operation, and the grantcopy operation may be one reason for it. Do you have any idea about it too?

> 
> Regards,
> 
> Zoli

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:38:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXY4-00010Z-6w; Thu, 04 Dec 2014 14:38:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XwXY2-00010U-0D
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:38:26 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	75/A6-29352-1E170845; Thu, 04 Dec 2014 14:38:25 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417703897!8682088!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30759 invoked from network); 4 Dec 2014 14:38: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;
	4 Dec 2014 14:38:23 -0000
Received: from 172.24.2.119 (EHLO SZXEMA412-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDL06762; Thu, 04 Dec 2014 22:38:07 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id
	14.03.0158.001; Thu, 4 Dec 2014 22:37:55 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIAAiqFg//+bI4AAE78pMA==
Date: Thu, 4 Dec 2014 14:37:54 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2393394C@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
	<20141204130531.GD16532@zion.uk.xensource.com>
In-Reply-To: <20141204130531.GD16532@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for your detailed explanation, Wei. 

I am wondering if netfront/netback can be optimized to reach the 10Gbps throughout between DomUs running on different hosts connected with 10GE network. Currently, it seems like the RX is the bottleneck, which also consist with the testing result in xenwiki: http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_performance_testing

I am wondering what factors prevent RX to reach the higher throughout? You have mentioned that one reason is that guest RX data path still uses grant_copy while guest TX uses grant_map to do zero-copy transmit. Do you know any other factors or ongoing work to optimize the RX data path?

----------
zhangleiqiang (Trump)

Best Regards


> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Thursday, December 04, 2014 9:06 PM
> To: Zhangleiqiang (Trump)
> Cc: Wei Liu; xen-devel@lists.xen.org; zhangleiqiang; Luohao (brian); Xiaoding
> (B); Yuzhou (C); Zhuangyuxin
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> On Thu, Dec 04, 2014 at 12:09:33PM +0000, Zhangleiqiang (Trump) wrote:
> [...]
> > > > However, I find another issue. Even using 6 queues and making sure
> > > > that all of these 6 netback processes running with high cpu usage
> > > > (indeed, any of it running with 87% cpu usage), the whole VM
> > > > receive throughout is not very higher than results when using 4
> > > > queues. The results are from 4.5Gbps to 5.04 Gbps using TCP with
> > > > 512 bytes length and 4.3Gbps to 5.78Gbps using TCP with 1460 bytes
> length.
> > > >
> > >
> > > I would like to ask if you're still using 4U4G (4 CPU 4 G?)
> > > configuration? If so, please make sure there are at least the same number
> of vcpus as queues.
> >
> 
> > Sorry for misleading you, 4U4G means 4 CPU and 4 G memory, :). I also
> > found that the max_queue of netback is determinated by min(online_cpu,
> > module_param) yesterday, so when using 6 queues in the previous
> > testing, I used VM with 6 CPU and 6 G Memory.
> 
> >
> > > > According to the testing result from WIKI:
> > > > http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_
> > > > perf ormance_testing, The VM receive throughput is also more lower
> > > > than VM transmit.
> > > >
> > >
> > > I think that's expected, because guest RX data path still uses
> > > grant_copy while guest TX uses grant_map to do zero-copy transmit.
> >
> > As I understand, the RX process is as follows:
> > 1. Phy NIC receive packet
> > 2. XEN Hypervisor trigger interrupt to Dom0 3. Dom0' s NIC driver do
> > the "RX" operation, and the packet is stored into SKB which is also
> > owned/shared with netback 4. NetBack notify netfront through event
> > channel that a packet is receiving 5. Netfront grant a buffer for
> > receiving and notify netback the GR (if using grant-resue mechanism,
> > netfront just notify the GR to netback) through IO Ring 6. NetBack do
> > the grant_copy to copy packet from its SKB to the buffer referenced by
> > GR, and notify netfront through event channel 7. Netfront copy the
> > data from buffer to user-level app's SKB
> >
> > Am I right?
> 
> Step 4 is not correct, netback won't notify netfront at that point.
> 
> Step 5 is not correct, all grant refs are pre-allocated and granted before that.
> 
> Other steps look correct.
> 
> > Why not using zero-copy transmit in guest RX data pash too ?
> >
> 
> A rogue / buggy guest might hold the mapping for arbitrary long period of time.
> 
> >
> > > > I am wondering why the VM receive throughout cannot be up to
> > > > 8-10Gbps as VM transmit under multi-queue?  I also tried to send
> > > > packets directly from Local Dom0 to DomU, the DomU receive
> > > > throughput can reach about 8-12Gbps, so I am also wondering why
> > > > transmitting packets from Dom0 to Remote DomU can only reach about
> 4-5Gbps throughout?
> > >
> > > If data is from Dom0 to DomU then SKB is probably not fragmented by
> > > network stack.  You can use tcpdump to check that.
> >
> > In our testing , the MTU is set to 1600. However, even testing with
> > packets whose length are 1024 (small than 1600), the throughout
> > between Dom0 to Local DomU is more higher than that between Dom0 to
> > Remote DomU. So maybe the fragment is not the reason for it.
> >
> 
> Don't have much idea about this, sorry.
> 
> Wei.
> 
> >
> > > Wei.
> > >
> > > >
> > > > > Wei.
> > > > >
> > > > > > ----------
> > > > > > zhangleiqiang (Trump)
> > > > > >
> > > > > > Best Regards
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > > > > > Sent: Tuesday, December 02, 2014 8:12 PM
> > > > > > > To: Zhangleiqiang (Trump)
> > > > > > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao
> > > > > > > (brian); Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > > > > > Subject: Re: [Xen-devel] Poor network performance between
> > > > > > > DomU with multiqueue support
> > > > > > >
> > > > > > > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang
> > > > > > > (Trump)
> > > wrote:
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: xen-devel-bounces@lists.xen.org
> > > > > > > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
> > > > > > > > > Wei Liu
> > > > > > > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > > > > > > To: zhangleiqiang
> > > > > > > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > > > > > > Subject: Re: [Xen-devel] Poor network performance
> > > > > > > > > between DomU with multiqueue support
> > > > > > > > >
> > > > > > > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang
> wrote:
> > > > > > > > > > Hi, all
> > > > > > > > > >     I am testing the performance of xen
> > > > > > > > > > netfront-netback driver that with
> > > > > > > > > multi-queues support. The throughput from domU to remote
> > > > > > > > > dom0 is 9.2Gb/s, but the throughput from domU to remote
> > > > > > > > > domU is only 3.6Gb/s, I think the bottleneck is the
> > > > > > > > > throughput from dom0 to local domU. However, we have
> > > > > > > > > done some testing and found the throughput from dom0 to local
> domU is 5.8Gb/s.
> > > > > > > > > >     And if we send packets from one DomU to other 3
> > > > > > > > > > DomUs on different
> > > > > > > > > host simultaneously, the sum of throughout can reach 9Gbps.
> > > > > > > > > It seems like the bottleneck is the receiver?
> > > > > > > > > >     After some analysis, I found that even the
> > > > > > > > > > max_queue of netfront/back
> > > > > > > > > is set to 4, there are some strange results as follows:
> > > > > > > > > >     1. In domU, only one rx queue deal with softirq
> > > > > > > > >
> > > > > > > > > Try to bind irq to different vcpus?
> > > > > > > >
> > > > > > > > Do you mean we try to bind irq to different vcpus in DomU?
> > > > > > > > I will try it
> > > > > now.
> > > > > > > >
> > > > > > >
> > > > > > > Yes. Given the fact that you have two backend threads
> > > > > > > running while only one DomU vcpu is busy, it smells like
> > > > > > > misconfiguration in
> > > DomU.
> > > > > > >
> > > > > > > If this phenomenon persists after correctly binding irqs,
> > > > > > > you might want to check traffic is steering correctly to different
> queues.
> > > > > > >
> > > > > > > > >
> > > > > > > > > >     2. In dom0, only two netback queues process are
> > > > > > > > > > scheduled, other two
> > > > > > > > > process aren't scheduled.
> > > > > > > > >
> > > > > > > > > How many Dom0 vcpu do you have? If it only has two then
> > > > > > > > > there will only be two processes running at a time.
> > > > > > > >
> > > > > > > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU
> > > > > > > > running in
> > > > > > > Dom0 and so four netback processes are running in Dom0
> > > > > > > (because the max_queue param of netback kernel module is set to
> 4).
> > > > > > > > The phenomenon is that only 2 of these four netback
> > > > > > > > process were running
> > > > > > > with about 70% cpu usage, and another two use little CPU.
> > > > > > > > Is there a hash algorithm to determine which netback
> > > > > > > > process to handle the
> > > > > > > input packet?
> > > > > > > >
> > > > > > >
> > > > > > > I think that's whatever default algorithm Linux kernel is using.
> > > > > > >
> > > > > > > We don't currently support other algorithms.
> > > > > > >
> > > > > > > Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:38:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXY4-00010Z-6w; Thu, 04 Dec 2014 14:38:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XwXY2-00010U-0D
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:38:26 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	75/A6-29352-1E170845; Thu, 04 Dec 2014 14:38:25 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417703897!8682088!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30759 invoked from network); 4 Dec 2014 14:38: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;
	4 Dec 2014 14:38:23 -0000
Received: from 172.24.2.119 (EHLO SZXEMA412-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDL06762; Thu, 04 Dec 2014 22:38:07 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id
	14.03.0158.001; Thu, 4 Dec 2014 22:37:55 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIAAiqFg//+bI4AAE78pMA==
Date: Thu, 4 Dec 2014 14:37:54 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2393394C@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
	<20141204130531.GD16532@zion.uk.xensource.com>
In-Reply-To: <20141204130531.GD16532@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for your detailed explanation, Wei. 

I am wondering if netfront/netback can be optimized to reach the 10Gbps throughout between DomUs running on different hosts connected with 10GE network. Currently, it seems like the RX is the bottleneck, which also consist with the testing result in xenwiki: http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_performance_testing

I am wondering what factors prevent RX to reach the higher throughout? You have mentioned that one reason is that guest RX data path still uses grant_copy while guest TX uses grant_map to do zero-copy transmit. Do you know any other factors or ongoing work to optimize the RX data path?

----------
zhangleiqiang (Trump)

Best Regards


> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Thursday, December 04, 2014 9:06 PM
> To: Zhangleiqiang (Trump)
> Cc: Wei Liu; xen-devel@lists.xen.org; zhangleiqiang; Luohao (brian); Xiaoding
> (B); Yuzhou (C); Zhuangyuxin
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> On Thu, Dec 04, 2014 at 12:09:33PM +0000, Zhangleiqiang (Trump) wrote:
> [...]
> > > > However, I find another issue. Even using 6 queues and making sure
> > > > that all of these 6 netback processes running with high cpu usage
> > > > (indeed, any of it running with 87% cpu usage), the whole VM
> > > > receive throughout is not very higher than results when using 4
> > > > queues. The results are from 4.5Gbps to 5.04 Gbps using TCP with
> > > > 512 bytes length and 4.3Gbps to 5.78Gbps using TCP with 1460 bytes
> length.
> > > >
> > >
> > > I would like to ask if you're still using 4U4G (4 CPU 4 G?)
> > > configuration? If so, please make sure there are at least the same number
> of vcpus as queues.
> >
> 
> > Sorry for misleading you, 4U4G means 4 CPU and 4 G memory, :). I also
> > found that the max_queue of netback is determinated by min(online_cpu,
> > module_param) yesterday, so when using 6 queues in the previous
> > testing, I used VM with 6 CPU and 6 G Memory.
> 
> >
> > > > According to the testing result from WIKI:
> > > > http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_
> > > > perf ormance_testing, The VM receive throughput is also more lower
> > > > than VM transmit.
> > > >
> > >
> > > I think that's expected, because guest RX data path still uses
> > > grant_copy while guest TX uses grant_map to do zero-copy transmit.
> >
> > As I understand, the RX process is as follows:
> > 1. Phy NIC receive packet
> > 2. XEN Hypervisor trigger interrupt to Dom0 3. Dom0' s NIC driver do
> > the "RX" operation, and the packet is stored into SKB which is also
> > owned/shared with netback 4. NetBack notify netfront through event
> > channel that a packet is receiving 5. Netfront grant a buffer for
> > receiving and notify netback the GR (if using grant-resue mechanism,
> > netfront just notify the GR to netback) through IO Ring 6. NetBack do
> > the grant_copy to copy packet from its SKB to the buffer referenced by
> > GR, and notify netfront through event channel 7. Netfront copy the
> > data from buffer to user-level app's SKB
> >
> > Am I right?
> 
> Step 4 is not correct, netback won't notify netfront at that point.
> 
> Step 5 is not correct, all grant refs are pre-allocated and granted before that.
> 
> Other steps look correct.
> 
> > Why not using zero-copy transmit in guest RX data pash too ?
> >
> 
> A rogue / buggy guest might hold the mapping for arbitrary long period of time.
> 
> >
> > > > I am wondering why the VM receive throughout cannot be up to
> > > > 8-10Gbps as VM transmit under multi-queue?  I also tried to send
> > > > packets directly from Local Dom0 to DomU, the DomU receive
> > > > throughput can reach about 8-12Gbps, so I am also wondering why
> > > > transmitting packets from Dom0 to Remote DomU can only reach about
> 4-5Gbps throughout?
> > >
> > > If data is from Dom0 to DomU then SKB is probably not fragmented by
> > > network stack.  You can use tcpdump to check that.
> >
> > In our testing , the MTU is set to 1600. However, even testing with
> > packets whose length are 1024 (small than 1600), the throughout
> > between Dom0 to Local DomU is more higher than that between Dom0 to
> > Remote DomU. So maybe the fragment is not the reason for it.
> >
> 
> Don't have much idea about this, sorry.
> 
> Wei.
> 
> >
> > > Wei.
> > >
> > > >
> > > > > Wei.
> > > > >
> > > > > > ----------
> > > > > > zhangleiqiang (Trump)
> > > > > >
> > > > > > Best Regards
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > > > > > Sent: Tuesday, December 02, 2014 8:12 PM
> > > > > > > To: Zhangleiqiang (Trump)
> > > > > > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao
> > > > > > > (brian); Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > > > > > Subject: Re: [Xen-devel] Poor network performance between
> > > > > > > DomU with multiqueue support
> > > > > > >
> > > > > > > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang
> > > > > > > (Trump)
> > > wrote:
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: xen-devel-bounces@lists.xen.org
> > > > > > > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
> > > > > > > > > Wei Liu
> > > > > > > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > > > > > > To: zhangleiqiang
> > > > > > > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > > > > > > Subject: Re: [Xen-devel] Poor network performance
> > > > > > > > > between DomU with multiqueue support
> > > > > > > > >
> > > > > > > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang
> wrote:
> > > > > > > > > > Hi, all
> > > > > > > > > >     I am testing the performance of xen
> > > > > > > > > > netfront-netback driver that with
> > > > > > > > > multi-queues support. The throughput from domU to remote
> > > > > > > > > dom0 is 9.2Gb/s, but the throughput from domU to remote
> > > > > > > > > domU is only 3.6Gb/s, I think the bottleneck is the
> > > > > > > > > throughput from dom0 to local domU. However, we have
> > > > > > > > > done some testing and found the throughput from dom0 to local
> domU is 5.8Gb/s.
> > > > > > > > > >     And if we send packets from one DomU to other 3
> > > > > > > > > > DomUs on different
> > > > > > > > > host simultaneously, the sum of throughout can reach 9Gbps.
> > > > > > > > > It seems like the bottleneck is the receiver?
> > > > > > > > > >     After some analysis, I found that even the
> > > > > > > > > > max_queue of netfront/back
> > > > > > > > > is set to 4, there are some strange results as follows:
> > > > > > > > > >     1. In domU, only one rx queue deal with softirq
> > > > > > > > >
> > > > > > > > > Try to bind irq to different vcpus?
> > > > > > > >
> > > > > > > > Do you mean we try to bind irq to different vcpus in DomU?
> > > > > > > > I will try it
> > > > > now.
> > > > > > > >
> > > > > > >
> > > > > > > Yes. Given the fact that you have two backend threads
> > > > > > > running while only one DomU vcpu is busy, it smells like
> > > > > > > misconfiguration in
> > > DomU.
> > > > > > >
> > > > > > > If this phenomenon persists after correctly binding irqs,
> > > > > > > you might want to check traffic is steering correctly to different
> queues.
> > > > > > >
> > > > > > > > >
> > > > > > > > > >     2. In dom0, only two netback queues process are
> > > > > > > > > > scheduled, other two
> > > > > > > > > process aren't scheduled.
> > > > > > > > >
> > > > > > > > > How many Dom0 vcpu do you have? If it only has two then
> > > > > > > > > there will only be two processes running at a time.
> > > > > > > >
> > > > > > > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU
> > > > > > > > running in
> > > > > > > Dom0 and so four netback processes are running in Dom0
> > > > > > > (because the max_queue param of netback kernel module is set to
> 4).
> > > > > > > > The phenomenon is that only 2 of these four netback
> > > > > > > > process were running
> > > > > > > with about 70% cpu usage, and another two use little CPU.
> > > > > > > > Is there a hash algorithm to determine which netback
> > > > > > > > process to handle the
> > > > > > > input packet?
> > > > > > > >
> > > > > > >
> > > > > > > I think that's whatever default algorithm Linux kernel is using.
> > > > > > >
> > > > > > > We don't currently support other algorithms.
> > > > > > >
> > > > > > > Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:41:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:41:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXad-00016w-Ok; Thu, 04 Dec 2014 14:41: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 1XwXac-00016o-LW
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:41:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	87/E9-15461-28270845; Thu, 04 Dec 2014 14:41:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417704063!5402556!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 27873 invoked from network); 4 Dec 2014 14:41:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 14:41:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200101635"
Message-ID: <54807253.5000603@citrix.com>
Date: Thu, 4 Dec 2014 14:40: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: <xen-devel@lists.xen.org>, <rumpkernel-users@lists.sourceforge.net>, Anil
	Madhavapeddy <anil@recoil.org>, Samuel Thibault
	<samuel.thibault@ens-lyon.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
In-Reply-To: <20141204142757.GD11192@dezo.moloch.sk>
X-DLP: MIA2
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 14:27, Martin Lucina wrote:
> Hi,
>
> In rumprun-xen [1] we use Mini-OS as a "base firmware" layer in our stack.
> Currently we are using a slightly bastardized fork of the xen.git Mini-OS.
>
> We would like to avoid this turning into a permanent fork. Following
> previous discussion [2] on and openmirage-devel I would like to coordinate
> upstreaming our changes if possible.
>
> The biggest change which needs to be done is cleaning up the Mini-OS
> namespace. This is necessary as we link Mini-OS with the application, rump
> kernel and NetBSD libc to get a full application stack.
>
> The changes as implemented in a semi-automated fashion for the Mini-OS used
> by rumprun-xen can be viewed in the (since merged) pull request at [3]:
>
> - 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.
>
> Questions:
>
> - Is there a general interest in upstreaming this work?
> - Upstream Mini-OS provides things we (rumpkernel.org) don't need (stub
>   "libc", ...). If we are to move to upstream then we will need to do a
>   more general cleanup of Mini-OS to make these pluggable. Again, is there
>   upstream interest in this work?
> - As there is no formal API for Mini-OS. My changes only address the
>   "public" functionality used by rumprun-xen. Other users mileage will
>   vary; who else should I coordinate with?
> - I have not namespaced macros such as local_irq_save(). Should this be
>   done? 
>   
>   Also, the driver namespaces have been preserved (since I was lazy), these
>   should probably be renamed under the minios namespace; it's plausible
>   some day someone will try to link an application with a function called
>   blkfront_init().
>
> All comments and review welcome.
>
> Martin

I think this is a very good idea, and I am completely in favour of it.

There are already-identified issues such as MiniOS leaking things like
ARRAY_SIZE() into linked namespaces, which I havn't yet had enough tuits
to fix.

I think splitting things like the stub libc away from the "MiniOS Xen
Framework" is also a good idea.  Ideally, the result of a "MiniOS Build"
would be a small set of .a's which can then be linked against some
normal C to make a minios guest.  (How feasible this is in reality
remains to be seen.)

>From a not-public-API point of view, all you have to worry about is that
the existing minios stuff in xen.git, including the stubdom stuff,
continues to work.  We have never made any guarantees to anyone using
minios out-of-tree.

~Andrew


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:41:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:41:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXad-00016w-Ok; Thu, 04 Dec 2014 14:41: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 1XwXac-00016o-LW
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:41:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	87/E9-15461-28270845; Thu, 04 Dec 2014 14:41:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417704063!5402556!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 27873 invoked from network); 4 Dec 2014 14:41:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 14:41:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200101635"
Message-ID: <54807253.5000603@citrix.com>
Date: Thu, 4 Dec 2014 14:40: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: <xen-devel@lists.xen.org>, <rumpkernel-users@lists.sourceforge.net>, Anil
	Madhavapeddy <anil@recoil.org>, Samuel Thibault
	<samuel.thibault@ens-lyon.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
In-Reply-To: <20141204142757.GD11192@dezo.moloch.sk>
X-DLP: MIA2
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 14:27, Martin Lucina wrote:
> Hi,
>
> In rumprun-xen [1] we use Mini-OS as a "base firmware" layer in our stack.
> Currently we are using a slightly bastardized fork of the xen.git Mini-OS.
>
> We would like to avoid this turning into a permanent fork. Following
> previous discussion [2] on and openmirage-devel I would like to coordinate
> upstreaming our changes if possible.
>
> The biggest change which needs to be done is cleaning up the Mini-OS
> namespace. This is necessary as we link Mini-OS with the application, rump
> kernel and NetBSD libc to get a full application stack.
>
> The changes as implemented in a semi-automated fashion for the Mini-OS used
> by rumprun-xen can be viewed in the (since merged) pull request at [3]:
>
> - 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.
>
> Questions:
>
> - Is there a general interest in upstreaming this work?
> - Upstream Mini-OS provides things we (rumpkernel.org) don't need (stub
>   "libc", ...). If we are to move to upstream then we will need to do a
>   more general cleanup of Mini-OS to make these pluggable. Again, is there
>   upstream interest in this work?
> - As there is no formal API for Mini-OS. My changes only address the
>   "public" functionality used by rumprun-xen. Other users mileage will
>   vary; who else should I coordinate with?
> - I have not namespaced macros such as local_irq_save(). Should this be
>   done? 
>   
>   Also, the driver namespaces have been preserved (since I was lazy), these
>   should probably be renamed under the minios namespace; it's plausible
>   some day someone will try to link an application with a function called
>   blkfront_init().
>
> All comments and review welcome.
>
> Martin

I think this is a very good idea, and I am completely in favour of it.

There are already-identified issues such as MiniOS leaking things like
ARRAY_SIZE() into linked namespaces, which I havn't yet had enough tuits
to fix.

I think splitting things like the stub libc away from the "MiniOS Xen
Framework" is also a good idea.  Ideally, the result of a "MiniOS Build"
would be a small set of .a's which can then be linked against some
normal C to make a minios guest.  (How feasible this is in reality
remains to be seen.)

>From a not-public-API point of view, all you have to worry about is that
the existing minios stuff in xen.git, including the stubdom stuff,
continues to work.  We have never made any guarantees to anyone using
minios out-of-tree.

~Andrew


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:47:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:47:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXgb-0001iu-Ri; Thu, 04 Dec 2014 14:47:17 +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 1XwXga-0001iW-FZ
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:47:16 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	0E/10-15461-3F370845; Thu, 04 Dec 2014 14:47:15 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417704432!10004219!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17607 invoked from network); 4 Dec 2014 14:47:14 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 14:47:14 -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 sB4El4GY028109
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 4 Dec 2014 09:47:05 -0500
Received: from vitty.brq.redhat.com.smtpmail-local-domain
	(vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB4El0hw022620
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2014 09:47:01 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Wei Liu <wei.liu2@citrix.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<20141204115512.GC16532@zion.uk.xensource.com>
Date: Thu, 04 Dec 2014 15:46:59 +0100
In-Reply-To: <20141204115512.GC16532@zion.uk.xensource.com> (Wei Liu's message
	of "Thu, 4 Dec 2014 11:55:12 +0000")
Message-ID: <8761driiak.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.24
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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

Wei Liu <wei.liu2@citrix.com> writes:

> On Wed, Dec 03, 2014 at 06:16:12PM +0100, Vitaly Kuznetsov wrote:
>> Changes from RFCv3:
>> This is the first non-RFC series as no major concerns were expressed. I'm trying
>> to address Jan's comments. Changes are:
>> - Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really like
>>   the name but nothing more appropriate came to my mind) which incorporates
>>   former XEN_DOMCTL_set_recipient and XEN_DOMCTL_destroydomain to prevent
>>   original domain from changing its allocations during transfer procedure.
>> - Check in free_domheap_pages() that assign_pages() succeeded.
>> - Change printk() in free_domheap_pages().
>> - DOMDYING_locked state was introduced to support XEN_DOMCTL_devour.
>> - xc_domain_soft_reset() got simplified a bit. Now we just wait for the original
>>   domain to die or loose all its pages.
>> - rebased on top of current master branch.
>> 
>> 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.
>> 
>
> What would happen if you soft reset a PV guest? At the very least soft
> reset should be explicitly forbidden in PV case.

Well, nothing particulary bad from hypervisor point of view
happens. But when PV guest dies page tables are being destroyed (and we
lose the knowledge anyway). It would be possible for the toolstack to
start from the beggining - build bootstrap tables, put kernel/initrd and
start everything. I however don't see any value in doing so: our memory
gets destroyed and it is going to be the same as plain reboot.

Why do we need to forbid the call for PV? (xc_domain_soft_reset()
already forbids PV).

>
>> 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
>> - ...
>
> Is there a complete list?
>

Konrad tried to assemble it here:
http://lists.xen.org/archives/html/xen-devel/2014-06/msg03889.html


>> 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.
>> 
>
> As this approach requires toolstack do complex interaction with
> hypervisor and preserve / throw away a bunch of states. I think the
> whole procedure should be documented.

Sure.. Where would you expect such doc to appear?

>
> It would also be helpful if you link to previous discussions in your
> cover letter.

Sure, will do next time. For now:
on resetting VCPU_info (and that's where 'rebuild everything with the
toolstack solution' was suggested):
http://lists.xen.org/archives/html/xen-devel/2014-08/msg01869.html
Previous versions:
http://lists.xen.org/archives/html/xen-devel/2014-08/msg01630.html
http://lists.xen.org/archives/html/xen-devel/2014-08/msg00603.html

EVTCHNOP_reset (got merged):
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03979.html
Previous:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03925.html
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03322.html
http://lists.xen.org/archives/html/xen-devel/2014-07/msg02500.html

This patch series:
http://lists.xen.org/archives/html/xen-devel/2014-10/msg00764.html
http://lists.xen.org/archives/html/xen-devel/2014-09/msg03623.html
http://lists.xen.org/archives/html/xen-devel/2014-08/msg02309.html

>
> Wei.

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:47:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:47:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXgb-0001iu-Ri; Thu, 04 Dec 2014 14:47:17 +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 1XwXga-0001iW-FZ
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:47:16 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	0E/10-15461-3F370845; Thu, 04 Dec 2014 14:47:15 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417704432!10004219!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17607 invoked from network); 4 Dec 2014 14:47:14 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 14:47:14 -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 sB4El4GY028109
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 4 Dec 2014 09:47:05 -0500
Received: from vitty.brq.redhat.com.smtpmail-local-domain
	(vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB4El0hw022620
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2014 09:47:01 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Wei Liu <wei.liu2@citrix.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<20141204115512.GC16532@zion.uk.xensource.com>
Date: Thu, 04 Dec 2014 15:46:59 +0100
In-Reply-To: <20141204115512.GC16532@zion.uk.xensource.com> (Wei Liu's message
	of "Thu, 4 Dec 2014 11:55:12 +0000")
Message-ID: <8761driiak.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.24
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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

Wei Liu <wei.liu2@citrix.com> writes:

> On Wed, Dec 03, 2014 at 06:16:12PM +0100, Vitaly Kuznetsov wrote:
>> Changes from RFCv3:
>> This is the first non-RFC series as no major concerns were expressed. I'm trying
>> to address Jan's comments. Changes are:
>> - Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really like
>>   the name but nothing more appropriate came to my mind) which incorporates
>>   former XEN_DOMCTL_set_recipient and XEN_DOMCTL_destroydomain to prevent
>>   original domain from changing its allocations during transfer procedure.
>> - Check in free_domheap_pages() that assign_pages() succeeded.
>> - Change printk() in free_domheap_pages().
>> - DOMDYING_locked state was introduced to support XEN_DOMCTL_devour.
>> - xc_domain_soft_reset() got simplified a bit. Now we just wait for the original
>>   domain to die or loose all its pages.
>> - rebased on top of current master branch.
>> 
>> 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.
>> 
>
> What would happen if you soft reset a PV guest? At the very least soft
> reset should be explicitly forbidden in PV case.

Well, nothing particulary bad from hypervisor point of view
happens. But when PV guest dies page tables are being destroyed (and we
lose the knowledge anyway). It would be possible for the toolstack to
start from the beggining - build bootstrap tables, put kernel/initrd and
start everything. I however don't see any value in doing so: our memory
gets destroyed and it is going to be the same as plain reboot.

Why do we need to forbid the call for PV? (xc_domain_soft_reset()
already forbids PV).

>
>> 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
>> - ...
>
> Is there a complete list?
>

Konrad tried to assemble it here:
http://lists.xen.org/archives/html/xen-devel/2014-06/msg03889.html


>> 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.
>> 
>
> As this approach requires toolstack do complex interaction with
> hypervisor and preserve / throw away a bunch of states. I think the
> whole procedure should be documented.

Sure.. Where would you expect such doc to appear?

>
> It would also be helpful if you link to previous discussions in your
> cover letter.

Sure, will do next time. For now:
on resetting VCPU_info (and that's where 'rebuild everything with the
toolstack solution' was suggested):
http://lists.xen.org/archives/html/xen-devel/2014-08/msg01869.html
Previous versions:
http://lists.xen.org/archives/html/xen-devel/2014-08/msg01630.html
http://lists.xen.org/archives/html/xen-devel/2014-08/msg00603.html

EVTCHNOP_reset (got merged):
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03979.html
Previous:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03925.html
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03322.html
http://lists.xen.org/archives/html/xen-devel/2014-07/msg02500.html

This patch series:
http://lists.xen.org/archives/html/xen-devel/2014-10/msg00764.html
http://lists.xen.org/archives/html/xen-devel/2014-09/msg03623.html
http://lists.xen.org/archives/html/xen-devel/2014-08/msg02309.html

>
> Wei.

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:48:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:48:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXi9-0001u7-BA; Thu, 04 Dec 2014 14:48:53 +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 1XwXi8-0001u1-QL
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:48:52 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	B2/22-05632-45470845; Thu, 04 Dec 2014 14:48:52 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417704529!8661521!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21295 invoked from network); 4 Dec 2014 14:48: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; 4 Dec 2014 14:48:51 -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 sB4Emhrb011218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 4 Dec 2014 09:48:43 -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 sB4EmdAl029528
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2014 09:48:40 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Julien Grall <julien.grall@linaro.org>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>
	<54803EEC.5040404@linaro.org>
Date: Thu, 04 Dec 2014 15:48:38 +0100
In-Reply-To: <54803EEC.5040404@linaro.org> (Julien Grall's message of "Thu, 04
	Dec 2014 11:01:00 +0000")
Message-ID: <871tofii7t.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: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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> writes:

> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
>> index a42d0b8..552e4a3 100644
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -366,6 +366,8 @@ struct domain
>>       bool_t           is_privileged;
>>       /* Which guest this guest has privileges on */
>>       struct domain   *target;
>> +    /* Which guest receives freed memory pages */
>
> It took me a while to understand that the recipient domain is a newly
> created domain, right? It might be worth to add a word here (and maybe
> in assign_pages).

Sure, will add. In case you think renaming 'recipient' to something else
makes sense I'm all in.

>
> With that in mind, the code in assign_pages makes more sense.
>
> Regards,

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:48:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:48:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXi9-0001u7-BA; Thu, 04 Dec 2014 14:48:53 +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 1XwXi8-0001u1-QL
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:48:52 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	B2/22-05632-45470845; Thu, 04 Dec 2014 14:48:52 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417704529!8661521!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21295 invoked from network); 4 Dec 2014 14:48: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; 4 Dec 2014 14:48:51 -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 sB4Emhrb011218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 4 Dec 2014 09:48:43 -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 sB4EmdAl029528
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2014 09:48:40 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Julien Grall <julien.grall@linaro.org>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>
	<54803EEC.5040404@linaro.org>
Date: Thu, 04 Dec 2014 15:48:38 +0100
In-Reply-To: <54803EEC.5040404@linaro.org> (Julien Grall's message of "Thu, 04
	Dec 2014 11:01:00 +0000")
Message-ID: <871tofii7t.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: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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> writes:

> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
>> index a42d0b8..552e4a3 100644
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -366,6 +366,8 @@ struct domain
>>       bool_t           is_privileged;
>>       /* Which guest this guest has privileges on */
>>       struct domain   *target;
>> +    /* Which guest receives freed memory pages */
>
> It took me a while to understand that the recipient domain is a newly
> created domain, right? It might be worth to add a word here (and maybe
> in assign_pages).

Sure, will add. In case you think renaming 'recipient' to something else
makes sense I'm all in.

>
> With that in mind, the code in assign_pages makes more sense.
>
> Regards,

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:50:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:50:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXjk-00021O-Qe; Thu, 04 Dec 2014 14:50:32 +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 1XwXjj-00021B-EU
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:50:31 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	4D/DD-02696-6B470845; Thu, 04 Dec 2014 14:50:30 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417704629!13034808!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24172 invoked from network); 4 Dec 2014 14:50:29 -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; 4 Dec 2014 14:50:29 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52613 helo=w510-wired)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XwXgm-0008M8-FF; Thu, 04 Dec 2014 15:47:28 +0100
Date: Thu, 4 Dec 2014 15:50:25 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1578910783.20141204155025@eikelenboom.it>
To: David Vrabel <david.vrabel@citrix.com>, bhelgaas@google.com, 
	Alex Williamson <alex.williamson@redhat.com>
In-Reply-To: <5480702F.2060004@citrix.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
MIME-Version: 1.0
Cc: linux-pci@vger.kernel.org, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
	slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 4, 2014, 3:31:11 PM, you wrote:

> On 04/12/14 14:09, Sander Eikelenboom wrote:
>> 
>> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
>> 
>>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>>>>
>>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>>>>
>>>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>>>>>
>>>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>>>>
>>>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>>>>>>
>>>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
>>>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>>>>>>> It bypasses the need to worry about the PCI lock. 
>>>>>>>
>>>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>>>>>>> proposed). 
>>>>>>>
>>>>>>
>>>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
>>>>
>>>>> It is only needed if the core won't provide one.
>>>>
>>>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
>>>>> +{
>>>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
>>>>> +       struct device *dev = &pci->dev;
>>>>> +       int ret;
>>>>> +
>>>>> +       /* Already have a per-function reset? */
>>>>> +       if (pci_probe_reset_function(pci) == 0)
>>>>> +               return 0;
>>>>> +
>>>>> +       ret = device_create_file(dev, &dev_attr_reset);
>>>>> +       if (ret < 0)
>>>>> +               return ret;
>>>> +       dev_data->>created_reset_file = true;
>>>>> +       return 0;
>>>>> +}
>>>>
>>>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
>>>> "pci.c:__pci_dev_reset" ?
>>>>
>>>> The problem with that function is that from my testing it seems that the 
>>>> first option "pci_dev_specific_reset" always seems to return succes, so all the
>>>> other options are skipped (flr, pm, slot, bus). However the device it self is 
>>>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
>>>> none virtualization purposes and it's probably the least intrusive. For 
>>>> virtualization however it would be nice to be sure it resets properly, or have a 
>>>> way to force a specific reset routine.)
>> 
>>> Then you need work with the maintainer for those specific devices or
>>> drivers to fix their specific reset function.
>> 
>>> I'm not adding stuff to pciback to workaround broken quirks.
>> 
>> OK that's a pretty clear message there, so if one wants to use pci and vga
>> passthrough one should better use KVM and vfio-pci.

> Have you (or anyone else) ever raised the problem with the broken reset
> quirk for certain devices with the relevant maintainer?

>> vfio-pci has:
>> - logic to do the try-slot-bus-reset logic

> Just because vfio-pci fixed it incorrectly doesn't mean pciback has to
> as well.

Depends on what you call an "incorrect fix" .. it fixes a quirk .. 
you can say that's incorrect, but then you would have to remove 50% of
the kernel and Xen code as well.

(i do in general agree it's better to strive for a generic solution though,
that's exactly why i brought up that that function doesn't seem to work perfect
for virtualization purposes) 

> It makes no sense for both pciback and vfio-pci to workaround problems
> with pci_function_reset() in different ways -- it should be fixed in the
> core PCI code so both can benefit and make use of the same code.

Well perhaps Bjorn knows why the order of resets and skipping the rest as
implemented in "pci.c:__pci_dev_reset" was implemented in that way ?

Especially what is the expectation about pci_dev_specific_reset doing a proper 
reset for say a vga-card:
- i know it doesn't work on a radeon card (doesn't blank screen, on next guest 
  boot reports it's already posted, powermanagement doesn't work).
- while with a slot/bus reset, that all just works fine, screen blanks 
  immediately and everything else also works.

Added Alex as well since he added this workaround for KVM/vfio-pci, perhaps he knows why
he introduced the workaround in vfio-pci instead of trying to fix it in core pci 
code ?

--
Sander


> David




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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:50:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14:50:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwXjk-00021O-Qe; Thu, 04 Dec 2014 14:50:32 +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 1XwXjj-00021B-EU
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:50:31 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	4D/DD-02696-6B470845; Thu, 04 Dec 2014 14:50:30 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417704629!13034808!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24172 invoked from network); 4 Dec 2014 14:50:29 -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; 4 Dec 2014 14:50:29 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52613 helo=w510-wired)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XwXgm-0008M8-FF; Thu, 04 Dec 2014 15:47:28 +0100
Date: Thu, 4 Dec 2014 15:50:25 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1578910783.20141204155025@eikelenboom.it>
To: David Vrabel <david.vrabel@citrix.com>, bhelgaas@google.com, 
	Alex Williamson <alex.williamson@redhat.com>
In-Reply-To: <5480702F.2060004@citrix.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
MIME-Version: 1.0
Cc: linux-pci@vger.kernel.org, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
	slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 4, 2014, 3:31:11 PM, you wrote:

> On 04/12/14 14:09, Sander Eikelenboom wrote:
>> 
>> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
>> 
>>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>>>>
>>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>>>>
>>>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>>>>>
>>>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>>>>
>>>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>>>>>>>>
>>>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
>>>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>>>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>>>>>>>> It bypasses the need to worry about the PCI lock. 
>>>>>>>
>>>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>>>>>>> proposed). 
>>>>>>>
>>>>>>
>>>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
>>>>
>>>>> It is only needed if the core won't provide one.
>>>>
>>>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
>>>>> +{
>>>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
>>>>> +       struct device *dev = &pci->dev;
>>>>> +       int ret;
>>>>> +
>>>>> +       /* Already have a per-function reset? */
>>>>> +       if (pci_probe_reset_function(pci) == 0)
>>>>> +               return 0;
>>>>> +
>>>>> +       ret = device_create_file(dev, &dev_attr_reset);
>>>>> +       if (ret < 0)
>>>>> +               return ret;
>>>> +       dev_data->>created_reset_file = true;
>>>>> +       return 0;
>>>>> +}
>>>>
>>>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
>>>> "pci.c:__pci_dev_reset" ?
>>>>
>>>> The problem with that function is that from my testing it seems that the 
>>>> first option "pci_dev_specific_reset" always seems to return succes, so all the
>>>> other options are skipped (flr, pm, slot, bus). However the device it self is 
>>>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
>>>> none virtualization purposes and it's probably the least intrusive. For 
>>>> virtualization however it would be nice to be sure it resets properly, or have a 
>>>> way to force a specific reset routine.)
>> 
>>> Then you need work with the maintainer for those specific devices or
>>> drivers to fix their specific reset function.
>> 
>>> I'm not adding stuff to pciback to workaround broken quirks.
>> 
>> OK that's a pretty clear message there, so if one wants to use pci and vga
>> passthrough one should better use KVM and vfio-pci.

> Have you (or anyone else) ever raised the problem with the broken reset
> quirk for certain devices with the relevant maintainer?

>> vfio-pci has:
>> - logic to do the try-slot-bus-reset logic

> Just because vfio-pci fixed it incorrectly doesn't mean pciback has to
> as well.

Depends on what you call an "incorrect fix" .. it fixes a quirk .. 
you can say that's incorrect, but then you would have to remove 50% of
the kernel and Xen code as well.

(i do in general agree it's better to strive for a generic solution though,
that's exactly why i brought up that that function doesn't seem to work perfect
for virtualization purposes) 

> It makes no sense for both pciback and vfio-pci to workaround problems
> with pci_function_reset() in different ways -- it should be fixed in the
> core PCI code so both can benefit and make use of the same code.

Well perhaps Bjorn knows why the order of resets and skipping the rest as
implemented in "pci.c:__pci_dev_reset" was implemented in that way ?

Especially what is the expectation about pci_dev_specific_reset doing a proper 
reset for say a vga-card:
- i know it doesn't work on a radeon card (doesn't blank screen, on next guest 
  boot reports it's already posted, powermanagement doesn't work).
- while with a slot/bus reset, that all just works fine, screen blanks 
  immediately and everything else also works.

Added Alex as well since he added this workaround for KVM/vfio-pci, perhaps he knows why
he introduced the workaround in vfio-pci instead of trying to fix it in core pci 
code ?

--
Sander


> David




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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:55:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14: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 1XwXoY-0002EK-IG; Thu, 04 Dec 2014 14:55:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwXoW-0002EF-JU
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:55:28 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	17/EA-26740-FD570845; Thu, 04 Dec 2014 14:55:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417704926!10973320!1
X-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 3167 invoked from network); 4 Dec 2014 14:55:26 -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; 4 Dec 2014 14:55:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 14:55:26 +0000
Message-Id: <548083EE020000780004CC90@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 14:55:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
	<54806FA2.6080406@citrix.com>
In-Reply-To: <54806FA2.6080406@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-develList <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 04.12.14 at 15:28, <andrew.cooper3@citrix.com> wrote:
> On 04/12/14 13:49, Jan Beulich wrote:
>>>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>>> 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.
>> With no-one else voicing an opinion:
>>
>> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
>>
>> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
>>
>> For the latter, we're fine even without further consideration. For the
>> former, the two operations actively using the continuation encoding
>> are tools-only ones. Since we're fine to alter the tools only interfaces,
>> and since it was intended for the tools-only HVM-ops to be split off
>> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
>> would then no longer be a problem. Plus, in the worst case we could
>> always introduce yet another hypercall if we ran out of numbers.
> 
> Are you suggesting that we make a new hvmctl now and remove the hvmop
> mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
> subsequently remove it even if all continuable hypercalls move to a
> separate hypercall.

Why? We certainly don't guarantee compatibility for undefined
hypercalls to behave in a certain way.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 14:55:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 14: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 1XwXoY-0002EK-IG; Thu, 04 Dec 2014 14:55:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwXoW-0002EF-JU
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 14:55:28 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	17/EA-26740-FD570845; Thu, 04 Dec 2014 14:55:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417704926!10973320!1
X-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 3167 invoked from network); 4 Dec 2014 14:55:26 -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; 4 Dec 2014 14:55:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 14:55:26 +0000
Message-Id: <548083EE020000780004CC90@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 14:55:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
	<54806FA2.6080406@citrix.com>
In-Reply-To: <54806FA2.6080406@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-develList <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 04.12.14 at 15:28, <andrew.cooper3@citrix.com> wrote:
> On 04/12/14 13:49, Jan Beulich wrote:
>>>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>>> 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.
>> With no-one else voicing an opinion:
>>
>> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
>>
>> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
>>
>> For the latter, we're fine even without further consideration. For the
>> former, the two operations actively using the continuation encoding
>> are tools-only ones. Since we're fine to alter the tools only interfaces,
>> and since it was intended for the tools-only HVM-ops to be split off
>> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
>> would then no longer be a problem. Plus, in the worst case we could
>> always introduce yet another hypercall if we ran out of numbers.
> 
> Are you suggesting that we make a new hvmctl now and remove the hvmop
> mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
> subsequently remove it even if all continuable hypercalls move to a
> separate hypercall.

Why? We certainly don't guarantee compatibility for undefined
hypercalls to behave in a certain way.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:11:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15: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 1XwY3f-0002ua-6Y; Thu, 04 Dec 2014 15:11:07 +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 1XwY3d-0002uV-0s
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:11:05 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	67/26-25276-88970845; Thu, 04 Dec 2014 15:11:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417705862!5417268!1
X-Originating-IP: [66.165.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 21754 invoked from network); 4 Dec 2014 15:11: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;
	4 Dec 2014 15:11:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200117845"
Received: from ukmail1.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, 4 Dec 2014 10:08: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 1XwY0y-0006q2-Kk;
	Thu, 04 Dec 2014 15:08:20 +0000
Date: Thu, 4 Dec 2014 15:08:20 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141204150820.GE16532@zion.uk.xensource.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<20141204115512.GC16532@zion.uk.xensource.com>
	<8761driiak.fsf@vitty.brq.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8761driiak.fsf@vitty.brq.redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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 Thu, Dec 04, 2014 at 03:46:59PM +0100, Vitaly Kuznetsov wrote:
> Wei Liu <wei.liu2@citrix.com> writes:
> 
> > On Wed, Dec 03, 2014 at 06:16:12PM +0100, Vitaly Kuznetsov wrote:
> >> Changes from RFCv3:
> >> This is the first non-RFC series as no major concerns were expressed. I'm trying
> >> to address Jan's comments. Changes are:
> >> - Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really like
> >>   the name but nothing more appropriate came to my mind) which incorporates
> >>   former XEN_DOMCTL_set_recipient and XEN_DOMCTL_destroydomain to prevent
> >>   original domain from changing its allocations during transfer procedure.
> >> - Check in free_domheap_pages() that assign_pages() succeeded.
> >> - Change printk() in free_domheap_pages().
> >> - DOMDYING_locked state was introduced to support XEN_DOMCTL_devour.
> >> - xc_domain_soft_reset() got simplified a bit. Now we just wait for the original
> >>   domain to die or loose all its pages.
> >> - rebased on top of current master branch.
> >> 
> >> 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.
> >> 
> >
> > What would happen if you soft reset a PV guest? At the very least soft
> > reset should be explicitly forbidden in PV case.
> 
> Well, nothing particulary bad from hypervisor point of view
> happens. But when PV guest dies page tables are being destroyed (and we
> lose the knowledge anyway). It would be possible for the toolstack to
> start from the beggining - build bootstrap tables, put kernel/initrd and
> start everything. I however don't see any value in doing so: our memory
> gets destroyed and it is going to be the same as plain reboot.
> 

OK. As long as hypervisor is safe I'm OK with it. I was thinking
from a security PoV, i.e. there is no guest triggerable crash of
hypervisor, guest cannot escape by providing arbitrary new kernel, etc.

> Why do we need to forbid the call for PV? (xc_domain_soft_reset()
> already forbids PV).
> 
> >
> >> 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
> >> - ...
> >
> > Is there a complete list?
> >
> 
> Konrad tried to assemble it here:
> http://lists.xen.org/archives/html/xen-devel/2014-06/msg03889.html
> 
> 
> >> 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.
> >> 
> >
> > As this approach requires toolstack do complex interaction with
> > hypervisor and preserve / throw away a bunch of states. I think the
> > whole procedure should be documented.
> 
> Sure.. Where would you expect such doc to appear?
> 

I think libxl_internal.h is the right place. Just group the
documentation with other internal functions you introduced.

Re all the links, thanks, I will have a look.

Wei.

> >
> > It would also be helpful if you link to previous discussions in your
> > cover letter.
> 
> Sure, will do next time. For now:
> on resetting VCPU_info (and that's where 'rebuild everything with the
> toolstack solution' was suggested):
> http://lists.xen.org/archives/html/xen-devel/2014-08/msg01869.html
> Previous versions:
> http://lists.xen.org/archives/html/xen-devel/2014-08/msg01630.html
> http://lists.xen.org/archives/html/xen-devel/2014-08/msg00603.html
> 
> EVTCHNOP_reset (got merged):
> http://lists.xen.org/archives/html/xen-devel/2014-07/msg03979.html
> Previous:
> http://lists.xen.org/archives/html/xen-devel/2014-07/msg03925.html
> http://lists.xen.org/archives/html/xen-devel/2014-07/msg03322.html
> http://lists.xen.org/archives/html/xen-devel/2014-07/msg02500.html
> 
> This patch series:
> http://lists.xen.org/archives/html/xen-devel/2014-10/msg00764.html
> http://lists.xen.org/archives/html/xen-devel/2014-09/msg03623.html
> http://lists.xen.org/archives/html/xen-devel/2014-08/msg02309.html
> 
> >
> > Wei.
> 
> -- 
>   Vitaly

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:11:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15: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 1XwY3f-0002ua-6Y; Thu, 04 Dec 2014 15:11:07 +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 1XwY3d-0002uV-0s
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:11:05 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	67/26-25276-88970845; Thu, 04 Dec 2014 15:11:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417705862!5417268!1
X-Originating-IP: [66.165.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 21754 invoked from network); 4 Dec 2014 15:11: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;
	4 Dec 2014 15:11:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208";a="200117845"
Received: from ukmail1.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, 4 Dec 2014 10:08: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 1XwY0y-0006q2-Kk;
	Thu, 04 Dec 2014 15:08:20 +0000
Date: Thu, 4 Dec 2014 15:08:20 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141204150820.GE16532@zion.uk.xensource.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<20141204115512.GC16532@zion.uk.xensource.com>
	<8761driiak.fsf@vitty.brq.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8761driiak.fsf@vitty.brq.redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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 Thu, Dec 04, 2014 at 03:46:59PM +0100, Vitaly Kuznetsov wrote:
> Wei Liu <wei.liu2@citrix.com> writes:
> 
> > On Wed, Dec 03, 2014 at 06:16:12PM +0100, Vitaly Kuznetsov wrote:
> >> Changes from RFCv3:
> >> This is the first non-RFC series as no major concerns were expressed. I'm trying
> >> to address Jan's comments. Changes are:
> >> - Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really like
> >>   the name but nothing more appropriate came to my mind) which incorporates
> >>   former XEN_DOMCTL_set_recipient and XEN_DOMCTL_destroydomain to prevent
> >>   original domain from changing its allocations during transfer procedure.
> >> - Check in free_domheap_pages() that assign_pages() succeeded.
> >> - Change printk() in free_domheap_pages().
> >> - DOMDYING_locked state was introduced to support XEN_DOMCTL_devour.
> >> - xc_domain_soft_reset() got simplified a bit. Now we just wait for the original
> >>   domain to die or loose all its pages.
> >> - rebased on top of current master branch.
> >> 
> >> 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.
> >> 
> >
> > What would happen if you soft reset a PV guest? At the very least soft
> > reset should be explicitly forbidden in PV case.
> 
> Well, nothing particulary bad from hypervisor point of view
> happens. But when PV guest dies page tables are being destroyed (and we
> lose the knowledge anyway). It would be possible for the toolstack to
> start from the beggining - build bootstrap tables, put kernel/initrd and
> start everything. I however don't see any value in doing so: our memory
> gets destroyed and it is going to be the same as plain reboot.
> 

OK. As long as hypervisor is safe I'm OK with it. I was thinking
from a security PoV, i.e. there is no guest triggerable crash of
hypervisor, guest cannot escape by providing arbitrary new kernel, etc.

> Why do we need to forbid the call for PV? (xc_domain_soft_reset()
> already forbids PV).
> 
> >
> >> 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
> >> - ...
> >
> > Is there a complete list?
> >
> 
> Konrad tried to assemble it here:
> http://lists.xen.org/archives/html/xen-devel/2014-06/msg03889.html
> 
> 
> >> 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.
> >> 
> >
> > As this approach requires toolstack do complex interaction with
> > hypervisor and preserve / throw away a bunch of states. I think the
> > whole procedure should be documented.
> 
> Sure.. Where would you expect such doc to appear?
> 

I think libxl_internal.h is the right place. Just group the
documentation with other internal functions you introduced.

Re all the links, thanks, I will have a look.

Wei.

> >
> > It would also be helpful if you link to previous discussions in your
> > cover letter.
> 
> Sure, will do next time. For now:
> on resetting VCPU_info (and that's where 'rebuild everything with the
> toolstack solution' was suggested):
> http://lists.xen.org/archives/html/xen-devel/2014-08/msg01869.html
> Previous versions:
> http://lists.xen.org/archives/html/xen-devel/2014-08/msg01630.html
> http://lists.xen.org/archives/html/xen-devel/2014-08/msg00603.html
> 
> EVTCHNOP_reset (got merged):
> http://lists.xen.org/archives/html/xen-devel/2014-07/msg03979.html
> Previous:
> http://lists.xen.org/archives/html/xen-devel/2014-07/msg03925.html
> http://lists.xen.org/archives/html/xen-devel/2014-07/msg03322.html
> http://lists.xen.org/archives/html/xen-devel/2014-07/msg02500.html
> 
> This patch series:
> http://lists.xen.org/archives/html/xen-devel/2014-10/msg00764.html
> http://lists.xen.org/archives/html/xen-devel/2014-09/msg03623.html
> http://lists.xen.org/archives/html/xen-devel/2014-08/msg02309.html
> 
> >
> > Wei.
> 
> -- 
>   Vitaly

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:13:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15: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 1XwY5j-0003Fl-Ru; Thu, 04 Dec 2014 15:13:15 +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 1XwY5i-0003Fe-Tj
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:13:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AE/A8-09842-A0A70845; Thu, 04 Dec 2014 15:13:14 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417705992!13475650!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6238 invoked from network); 4 Dec 2014 15:13:13 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 15:13:13 -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 sB4FD2Ku029314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 4 Dec 2014 10:13: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 sB4FCwhg003268
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2014 10:12:59 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Julien Grall <julien.grall@linaro.org>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>
	<547FAFDD.8010005@linaro.org>
Date: Thu, 04 Dec 2014 16:12:57 +0100
In-Reply-To: <547FAFDD.8010005@linaro.org> (Julien Grall's message of "Thu, 04
	Dec 2014 00:50:37 +0000")
Message-ID: <87wq67h2iu.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: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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> writes:

> Hi Vitaly,
>
> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>> New operation sets the 'recipient' domain which will recieve all
>
> s/recieve/receive/
>
>> memory pages from a particular domain and kills the original domain.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> @@ -1764,13 +1765,32 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>
> [..]
>
>> +        else
>> +        {
>> +            mfn = page_to_mfn(pg);
>> +            gmfn = mfn_to_gmfn(d, mfn);
>> +
>> +            page_set_owner(pg, NULL);
>> +            if ( assign_pages(d->recipient, pg, order, 0) )
>> +                /* assign_pages reports the error by itself */
>> +                goto out;
>> +
>> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
>
> On ARM, mfn_to_gmfn will always return the mfn. This would result to
> add a 1:1 mapping in the recipient domain.
>
> But ... only DOM0 has its memory mapped 1:1. So this code may blow up
> the P2M of the recipient domain.

I know almost nothing about ARM so please bear with me. So, for a guest
domain the mapping is not 1:1 (so guest sees different addresses) but
mfn_to_gmfn() doesn't returs these addresses? I was under an impression
it is not x86-specific and I can see its usage in e.g. getdomaininfo(),
memory_exchange(),.. How can one figure out the mapping then?
Anyway, what I want to do here is: when this page is freed I want to
reassign it to our newly-created guest at the exact same address it was
mapped in the original domain. 

>
> I'm not an x86 expert, but this may also happen when the recipient
> domain is using translated page mode (i.e HVM/PVHM).

PVHVM is the main target here (as kexec is unsupported for PV) and it
kinda works. mfn_to_gmfn() returns gmfn != mfn.

BTW, what's the current state of affairs with kexec and ARM guest? I
suppose we should have similar problems: vcpu_info, event channels,
.. 

>
> Regards,

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:13:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15: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 1XwY5j-0003Fl-Ru; Thu, 04 Dec 2014 15:13:15 +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 1XwY5i-0003Fe-Tj
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:13:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AE/A8-09842-A0A70845; Thu, 04 Dec 2014 15:13:14 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417705992!13475650!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6238 invoked from network); 4 Dec 2014 15:13:13 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 15:13:13 -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 sB4FD2Ku029314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 4 Dec 2014 10:13: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 sB4FCwhg003268
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2014 10:12:59 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Julien Grall <julien.grall@linaro.org>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>
	<547FAFDD.8010005@linaro.org>
Date: Thu, 04 Dec 2014 16:12:57 +0100
In-Reply-To: <547FAFDD.8010005@linaro.org> (Julien Grall's message of "Thu, 04
	Dec 2014 00:50:37 +0000")
Message-ID: <87wq67h2iu.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: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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> writes:

> Hi Vitaly,
>
> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>> New operation sets the 'recipient' domain which will recieve all
>
> s/recieve/receive/
>
>> memory pages from a particular domain and kills the original domain.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> @@ -1764,13 +1765,32 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>
> [..]
>
>> +        else
>> +        {
>> +            mfn = page_to_mfn(pg);
>> +            gmfn = mfn_to_gmfn(d, mfn);
>> +
>> +            page_set_owner(pg, NULL);
>> +            if ( assign_pages(d->recipient, pg, order, 0) )
>> +                /* assign_pages reports the error by itself */
>> +                goto out;
>> +
>> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
>
> On ARM, mfn_to_gmfn will always return the mfn. This would result to
> add a 1:1 mapping in the recipient domain.
>
> But ... only DOM0 has its memory mapped 1:1. So this code may blow up
> the P2M of the recipient domain.

I know almost nothing about ARM so please bear with me. So, for a guest
domain the mapping is not 1:1 (so guest sees different addresses) but
mfn_to_gmfn() doesn't returs these addresses? I was under an impression
it is not x86-specific and I can see its usage in e.g. getdomaininfo(),
memory_exchange(),.. How can one figure out the mapping then?
Anyway, what I want to do here is: when this page is freed I want to
reassign it to our newly-created guest at the exact same address it was
mapped in the original domain. 

>
> I'm not an x86 expert, but this may also happen when the recipient
> domain is using translated page mode (i.e HVM/PVHM).

PVHVM is the main target here (as kexec is unsupported for PV) and it
kinda works. mfn_to_gmfn() returns gmfn != mfn.

BTW, what's the current state of affairs with kexec and ARM guest? I
suppose we should have similar problems: vcpu_info, event channels,
.. 

>
> Regards,

-- 
  Vitaly

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:33:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:33:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYOz-0003wB-R7; Thu, 04 Dec 2014 15:33: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 1XwYOy-0003w3-Ea
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:33:08 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	CD/38-03148-3BE70845; Thu, 04 Dec 2014 15:33:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417707186!13052750!1
X-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 24407 invoked from network); 4 Dec 2014 15:33:07 -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; 4 Dec 2014 15:33:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 15:33:06 +0000
Message-Id: <54808CC3020000780004CCC8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 15:33:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-3-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -34,6 +34,7 @@
>  #include <xen/tasklet.h>
>  #include <xsm/xsm.h>
>  #include <asm/msi.h>
> +#include <xen/stdbool.h>

Please don't - we use bool_t in the hypervisor, not bool. The header
only exists for source code shared with the tools.

> @@ -1553,6 +1554,44 @@ 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 = NULL;
> +        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);

"d" gets passed into this function - no need to shadow the variable
and (wrongly) re-obtain the pointer.

> +
> +        if ( d == NULL )
> +            return -ESRCH;
> +
> +        d->arch.hvm_domain.pci_force =
> +                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;
> +        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;

You shouldn't set the count before setting the pointer.

> +        d->arch.hvm_domain.pcidevs = NULL;
> +
> +        if ( xdsr->num_pcidevs )
> +        {
> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
> +                                    xdsr->num_pcidevs);

New domctl-s must not represent security risks: xdsr->num_pcidevs
can be (almost) arbitrarily large - do you really want to allow such
huge allocations? A reasonable upper bound could for example be
the total number of PCI devices the hypervisor knows about.

> +            if ( pcidevs == NULL )
> +            {
> +                rcu_unlock_domain(d);
> +                return -ENOMEM;
> +            }
> +
> +            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
> +                                 xdsr->num_pcidevs*sizeof(*pcidevs)) )
> +            {
> +                xfree(pcidevs);
> +                rcu_unlock_domain(d);
> +                return -EFAULT;
> +            }
> +        }
> +
> +        d->arch.hvm_domain.pcidevs = pcidevs;

If the operation gets issued more than once for a given domain,
you're leaking the old pointer here. Overall should think a bit
more about this multiple use case (or outright disallow it).

> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>                          "  RMRR region: base_addr %"PRIx64
>                          " end_address %"PRIx64"\n",
>                          rmrru->base_address, rmrru->end_address);
> +            /*
> +             * TODO: we may provide a precise paramter just to reserve
> +             * RMRR range specific to one device.
> +             */
> +            dprintk(XENLOG_WARNING VTDPREFIX,
> +                    "So please set pci_rdmforce to reserve these ranges"
> +                    " if you need such a device in hotplug case.\n");

It makes no sense to use dprintk() here. I also don't see how this
message relates to whatever may have been logged immediately
before, so the wording ("So please set ...") is questionable. Nor is the
reference to "hotplug case" meaningful here - in this context, only
physical (host) device hotplug can be meant without further
qualification. In the end I think trying to log something here is just
wrong - simply drop the message and make sure whatever you want
to say can be found easily by looking elsewhere.

> --- 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;
>  
> +    bool_t                  pci_force;
> +    uint32_t                num_pcidevs;
> +    struct xen_guest_pcidev_info      *pcidevs;

Without a comment all these field names are pretty questionable.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:33:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:33:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYOz-0003wB-R7; Thu, 04 Dec 2014 15:33: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 1XwYOy-0003w3-Ea
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:33:08 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	CD/38-03148-3BE70845; Thu, 04 Dec 2014 15:33:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417707186!13052750!1
X-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 24407 invoked from network); 4 Dec 2014 15:33:07 -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; 4 Dec 2014 15:33:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 15:33:06 +0000
Message-Id: <54808CC3020000780004CCC8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 15:33:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-3-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -34,6 +34,7 @@
>  #include <xen/tasklet.h>
>  #include <xsm/xsm.h>
>  #include <asm/msi.h>
> +#include <xen/stdbool.h>

Please don't - we use bool_t in the hypervisor, not bool. The header
only exists for source code shared with the tools.

> @@ -1553,6 +1554,44 @@ 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 = NULL;
> +        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);

"d" gets passed into this function - no need to shadow the variable
and (wrongly) re-obtain the pointer.

> +
> +        if ( d == NULL )
> +            return -ESRCH;
> +
> +        d->arch.hvm_domain.pci_force =
> +                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;
> +        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;

You shouldn't set the count before setting the pointer.

> +        d->arch.hvm_domain.pcidevs = NULL;
> +
> +        if ( xdsr->num_pcidevs )
> +        {
> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
> +                                    xdsr->num_pcidevs);

New domctl-s must not represent security risks: xdsr->num_pcidevs
can be (almost) arbitrarily large - do you really want to allow such
huge allocations? A reasonable upper bound could for example be
the total number of PCI devices the hypervisor knows about.

> +            if ( pcidevs == NULL )
> +            {
> +                rcu_unlock_domain(d);
> +                return -ENOMEM;
> +            }
> +
> +            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
> +                                 xdsr->num_pcidevs*sizeof(*pcidevs)) )
> +            {
> +                xfree(pcidevs);
> +                rcu_unlock_domain(d);
> +                return -EFAULT;
> +            }
> +        }
> +
> +        d->arch.hvm_domain.pcidevs = pcidevs;

If the operation gets issued more than once for a given domain,
you're leaking the old pointer here. Overall should think a bit
more about this multiple use case (or outright disallow it).

> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>                          "  RMRR region: base_addr %"PRIx64
>                          " end_address %"PRIx64"\n",
>                          rmrru->base_address, rmrru->end_address);
> +            /*
> +             * TODO: we may provide a precise paramter just to reserve
> +             * RMRR range specific to one device.
> +             */
> +            dprintk(XENLOG_WARNING VTDPREFIX,
> +                    "So please set pci_rdmforce to reserve these ranges"
> +                    " if you need such a device in hotplug case.\n");

It makes no sense to use dprintk() here. I also don't see how this
message relates to whatever may have been logged immediately
before, so the wording ("So please set ...") is questionable. Nor is the
reference to "hotplug case" meaningful here - in this context, only
physical (host) device hotplug can be meant without further
qualification. In the end I think trying to log something here is just
wrong - simply drop the message and make sure whatever you want
to say can be found easily by looking elsewhere.

> --- 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;
>  
> +    bool_t                  pci_force;
> +    uint32_t                num_pcidevs;
> +    struct xen_guest_pcidev_info      *pcidevs;

Without a comment all these field names are pretty questionable.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:36:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYSD-00042Z-EA; Thu, 04 Dec 2014 15:36:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1XwYSC-00042U-3o
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 15:36:28 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	82/76-24124-B7F70845; Thu, 04 Dec 2014 15:36:27 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417707386!11629753!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 21048 invoked from network); 4 Dec 2014 15:36:26 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-7.tower-206.messagelabs.com with SMTP;
	4 Dec 2014 15:36:26 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id F3B001637BA;
	Thu,  4 Dec 2014 15:36:25 +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 oLV701bJD3Mh; Thu,  4 Dec 2014 15:36:20 +0000 (GMT)
Received: from zimbra.overnetdata.com (zimbra.overnetdata.com [192.168.1.204])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 596FF162317;
	Thu,  4 Dec 2014 15:36:20 +0000 (GMT)
Date: Thu, 4 Dec 2014 15:36:20 +0000 (GMT)
From: Anthony Wright <anthony@overnetdata.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <19758084.30.1417707380178.JavaMail.root@zimbra.overnetdata.com>
In-Reply-To: <547CB0AF.6010901@citrix.com>
MIME-Version: 1.0
X-Originating-IP: [192.168.1.31]
X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661)
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.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 01/12/14 14:22, David Vrabel wrote:
> This VIF protocol is weird. The first slot contains a txreq with a
> size
> for the total length of the packet, subsequent slots have sizes for
> that
> fragment only.
> 
> netback then has to calculate how long the first slot is, by
> subtracting
> all the size from the following slots.
> 
> So something has gone wrong but it's not obvious what it is. Any
> chance
> you can dump the ring state when it happens?

We think we've worked out how to dump the ring state, please see below.

dmesg output
============
[76571.687014] vif vif-6-0 vif6.0: txreq.offset: a5e, size: 4002, end: 6656
[76571.687035] vif vif-6-0 vif6.0: fatal error; disabling device
[76571.700304] br-primary-1: port 2(vif6.0) entered disabled state

/sys/kernel/debug/xen-netback/vif6.0/io_ring_q0
===============================================
Queue 0
TX: nr_ents 256
req prod 10164 (39) cons 10127 (2) event 10126 (1)
rsp prod 10125 (base) pvt 10125 (0) event 10145 (20)
pending prod 9589 pending cons 9333 nr_pending_reqs 0
dealloc prod 8501 dealloc cons 8501 dealloc_queue 0

RX: nr_ents 256
req prod 1321 (41) cons 1280 (0) event 1 (-1279)
rsp prod 1280 (base) pvt 1280 (0) event 1281 (1)

NAPI state: 1 NAPI weight: 64 TX queue len 0
Credit timer_pending: 0, credit: 18446744073709551615, usec: 0
remaining: 18446744073678062682, expires: 0, now: 4314107964


/sys/kernel/debug/xen-netback/vif6.0/io_ring_q1
===============================================
Queue 1
TX: nr_ents 256
req prod 10106 (0) cons 10106 (0) event 10107 (1)
rsp prod 10106 (base) pvt 10106 (0) event 10107 (1)
pending prod 9573 pending cons 9317 nr_pending_reqs 0
dealloc prod 8503 dealloc cons 8503 dealloc_queue 0

RX: nr_ents 256
req prod 594 (39) cons 555 (0) event 1 (-554)
rsp prod 555 (base) pvt 555 (0) event 556 (1)

NAPI state: 1 NAPI weight: 64 TX queue len 0
Credit timer_pending: 0, credit: 18446744073709551615, usec: 0
remaining: 18446744073678038030, expires: 0, now: 4314118667


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:36:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYSD-00042Z-EA; Thu, 04 Dec 2014 15:36:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1XwYSC-00042U-3o
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 15:36:28 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	82/76-24124-B7F70845; Thu, 04 Dec 2014 15:36:27 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417707386!11629753!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 21048 invoked from network); 4 Dec 2014 15:36:26 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-7.tower-206.messagelabs.com with SMTP;
	4 Dec 2014 15:36:26 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id F3B001637BA;
	Thu,  4 Dec 2014 15:36:25 +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 oLV701bJD3Mh; Thu,  4 Dec 2014 15:36:20 +0000 (GMT)
Received: from zimbra.overnetdata.com (zimbra.overnetdata.com [192.168.1.204])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 596FF162317;
	Thu,  4 Dec 2014 15:36:20 +0000 (GMT)
Date: Thu, 4 Dec 2014 15:36:20 +0000 (GMT)
From: Anthony Wright <anthony@overnetdata.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <19758084.30.1417707380178.JavaMail.root@zimbra.overnetdata.com>
In-Reply-To: <547CB0AF.6010901@citrix.com>
MIME-Version: 1.0
X-Originating-IP: [192.168.1.31]
X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661)
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.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 01/12/14 14:22, David Vrabel wrote:
> This VIF protocol is weird. The first slot contains a txreq with a
> size
> for the total length of the packet, subsequent slots have sizes for
> that
> fragment only.
> 
> netback then has to calculate how long the first slot is, by
> subtracting
> all the size from the following slots.
> 
> So something has gone wrong but it's not obvious what it is. Any
> chance
> you can dump the ring state when it happens?

We think we've worked out how to dump the ring state, please see below.

dmesg output
============
[76571.687014] vif vif-6-0 vif6.0: txreq.offset: a5e, size: 4002, end: 6656
[76571.687035] vif vif-6-0 vif6.0: fatal error; disabling device
[76571.700304] br-primary-1: port 2(vif6.0) entered disabled state

/sys/kernel/debug/xen-netback/vif6.0/io_ring_q0
===============================================
Queue 0
TX: nr_ents 256
req prod 10164 (39) cons 10127 (2) event 10126 (1)
rsp prod 10125 (base) pvt 10125 (0) event 10145 (20)
pending prod 9589 pending cons 9333 nr_pending_reqs 0
dealloc prod 8501 dealloc cons 8501 dealloc_queue 0

RX: nr_ents 256
req prod 1321 (41) cons 1280 (0) event 1 (-1279)
rsp prod 1280 (base) pvt 1280 (0) event 1281 (1)

NAPI state: 1 NAPI weight: 64 TX queue len 0
Credit timer_pending: 0, credit: 18446744073709551615, usec: 0
remaining: 18446744073678062682, expires: 0, now: 4314107964


/sys/kernel/debug/xen-netback/vif6.0/io_ring_q1
===============================================
Queue 1
TX: nr_ents 256
req prod 10106 (0) cons 10106 (0) event 10107 (1)
rsp prod 10106 (base) pvt 10106 (0) event 10107 (1)
pending prod 9573 pending cons 9317 nr_pending_reqs 0
dealloc prod 8503 dealloc cons 8503 dealloc_queue 0

RX: nr_ents 256
req prod 594 (39) cons 555 (0) event 1 (-554)
rsp prod 555 (base) pvt 555 (0) event 556 (1)

NAPI state: 1 NAPI weight: 64 TX queue len 0
Credit timer_pending: 0, credit: 18446744073709551615, usec: 0
remaining: 18446744073678038030, expires: 0, now: 4314118667


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:39:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:39:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYUy-0004BC-03; Thu, 04 Dec 2014 15:39:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex.williamson@redhat.com>) id 1XwYUw-0004B4-AO
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:39:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8A/41-09842-52080845; Thu, 04 Dec 2014 15:39:17 +0000
X-Env-Sender: alex.williamson@redhat.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417707555!13466513!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3385 invoked from network); 4 Dec 2014 15:39:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 15:39:16 -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 sB4Fd7LU002553
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 4 Dec 2014 10:39:07 -0500
Received: from [10.3.113.2] ([10.3.113.2])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB4Fd6N5026553; Thu, 4 Dec 2014 10:39:06 -0500
Message-ID: <1417707546.15750.100.camel@bling.home>
From: Alex Williamson <alex.williamson@redhat.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Thu, 04 Dec 2014 08:39:06 -0700
In-Reply-To: <1578910783.20141204155025@eikelenboom.it>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com> <308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, bhelgaas@google.com,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-04 at 15:50 +0100, Sander Eikelenboom wrote:
> Thursday, December 4, 2014, 3:31:11 PM, you wrote:
> 
> > On 04/12/14 14:09, Sander Eikelenboom wrote:
> >> 
> >> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
> >> 
> >>> On 04/12/14 13:10, Sander Eikelenboom wrote:
> >>>>
> >>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
> >>>>
> >>>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
> >>>>>>
> >>>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> >>>>>>>
> >>>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
> >>>>>>>>
> >>>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
> >>>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
> >>>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
> >>>>>>>> It bypasses the need to worry about the PCI lock. 
> >>>>>>>
> >>>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
> >>>>>>> proposed). 
> >>>>>>>
> >>>>>>
> >>>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
> >>>>
> >>>>> It is only needed if the core won't provide one.
> >>>>
> >>>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
> >>>>> +{
> >>>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
> >>>>> +       struct device *dev = &pci->dev;
> >>>>> +       int ret;
> >>>>> +
> >>>>> +       /* Already have a per-function reset? */
> >>>>> +       if (pci_probe_reset_function(pci) == 0)
> >>>>> +               return 0;
> >>>>> +
> >>>>> +       ret = device_create_file(dev, &dev_attr_reset);
> >>>>> +       if (ret < 0)
> >>>>> +               return ret;
> >>>> +       dev_data->>created_reset_file = true;
> >>>>> +       return 0;
> >>>>> +}
> >>>>
> >>>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
> >>>> "pci.c:__pci_dev_reset" ?
> >>>>
> >>>> The problem with that function is that from my testing it seems that the 
> >>>> first option "pci_dev_specific_reset" always seems to return succes, so all the
> >>>> other options are skipped (flr, pm, slot, bus). However the device it self is 
> >>>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
> >>>> none virtualization purposes and it's probably the least intrusive. For 
> >>>> virtualization however it would be nice to be sure it resets properly, or have a 
> >>>> way to force a specific reset routine.)
> >> 
> >>> Then you need work with the maintainer for those specific devices or
> >>> drivers to fix their specific reset function.
> >> 
> >>> I'm not adding stuff to pciback to workaround broken quirks.
> >> 
> >> OK that's a pretty clear message there, so if one wants to use pci and vga
> >> passthrough one should better use KVM and vfio-pci.
> 
> > Have you (or anyone else) ever raised the problem with the broken reset
> > quirk for certain devices with the relevant maintainer?
> 
> >> vfio-pci has:
> >> - logic to do the try-slot-bus-reset logic
> 
> > Just because vfio-pci fixed it incorrectly doesn't mean pciback has to
> > as well.
> 
> Depends on what you call an "incorrect fix" .. it fixes a quirk .. 
> you can say that's incorrect, but then you would have to remove 50% of
> the kernel and Xen code as well.
> 
> (i do in general agree it's better to strive for a generic solution though,
> that's exactly why i brought up that that function doesn't seem to work perfect
> for virtualization purposes) 
> 
> > It makes no sense for both pciback and vfio-pci to workaround problems
> > with pci_function_reset() in different ways -- it should be fixed in the
> > core PCI code so both can benefit and make use of the same code.
> 
> Well perhaps Bjorn knows why the order of resets and skipping the rest as
> implemented in "pci.c:__pci_dev_reset" was implemented in that way ?
> 
> Especially what is the expectation about pci_dev_specific_reset doing a proper 
> reset for say a vga-card:
> - i know it doesn't work on a radeon card (doesn't blank screen, on next guest 
>   boot reports it's already posted, powermanagement doesn't work).
> - while with a slot/bus reset, that all just works fine, screen blanks 
>   immediately and everything else also works.
> 
> Added Alex as well since he added this workaround for KVM/vfio-pci, perhaps he knows why
> he introduced the workaround in vfio-pci instead of trying to fix it in core pci 
> code ?

I don't know what workaround you're talking about.  As devices are
released from the user, vfio-pci attempts to reset them.  If
pci_reset_function() returns success we mark the device clean, otherwise
it gets marked dirty.  Each time a device is released, if there are
dirty devices we test whether we can try a bus/slot reset to clean them.
In the case of assigning a GPU this typically means that the GPU or
audio function come through first, there's no reset mechanism so it gets
marked dirty, the next device comes through and we manage to try a bus
reset.  vfio-pci does not have any device specific resets, all
functionality is added to the PCI-core, thank-you-very-much.  I even
posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
bad so that pci_reset_function() won't claim that worked.  All VGA
access quirks are done in QEMU, the kernel doesn't have any business in
remapping config space over MMIO regions or trapping other config space
backdoors.

I have never heard of problems with the dev specific reset claiming to
work and not doing anything, there are only a few of these, it should be
easy to debug.

I didn't read the original patch, but the title alone of this patch is
quite confusing.  FLR is specifically a function-level-reset, so one
would expect 'do_flr' to be function specific.  The pci-sysfs 'reset'
attribute is already function specific.  If pci_reset_function() isn't
doing the job and we need to use bus/slot reset, it's clearly not an
FLR.  Thanks,

Alex


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:39:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:39:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYUy-0004BC-03; Thu, 04 Dec 2014 15:39:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex.williamson@redhat.com>) id 1XwYUw-0004B4-AO
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:39:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8A/41-09842-52080845; Thu, 04 Dec 2014 15:39:17 +0000
X-Env-Sender: alex.williamson@redhat.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417707555!13466513!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3385 invoked from network); 4 Dec 2014 15:39:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 15:39:16 -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 sB4Fd7LU002553
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 4 Dec 2014 10:39:07 -0500
Received: from [10.3.113.2] ([10.3.113.2])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB4Fd6N5026553; Thu, 4 Dec 2014 10:39:06 -0500
Message-ID: <1417707546.15750.100.camel@bling.home>
From: Alex Williamson <alex.williamson@redhat.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Thu, 04 Dec 2014 08:39:06 -0700
In-Reply-To: <1578910783.20141204155025@eikelenboom.it>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com> <308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, bhelgaas@google.com,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-04 at 15:50 +0100, Sander Eikelenboom wrote:
> Thursday, December 4, 2014, 3:31:11 PM, you wrote:
> 
> > On 04/12/14 14:09, Sander Eikelenboom wrote:
> >> 
> >> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
> >> 
> >>> On 04/12/14 13:10, Sander Eikelenboom wrote:
> >>>>
> >>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
> >>>>
> >>>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
> >>>>>>
> >>>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> >>>>>>>
> >>>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
> >>>>>>>>
> >>>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
> >>>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
> >>>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
> >>>>>>>> It bypasses the need to worry about the PCI lock. 
> >>>>>>>
> >>>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
> >>>>>>> proposed). 
> >>>>>>>
> >>>>>>
> >>>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
> >>>>
> >>>>> It is only needed if the core won't provide one.
> >>>>
> >>>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
> >>>>> +{
> >>>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
> >>>>> +       struct device *dev = &pci->dev;
> >>>>> +       int ret;
> >>>>> +
> >>>>> +       /* Already have a per-function reset? */
> >>>>> +       if (pci_probe_reset_function(pci) == 0)
> >>>>> +               return 0;
> >>>>> +
> >>>>> +       ret = device_create_file(dev, &dev_attr_reset);
> >>>>> +       if (ret < 0)
> >>>>> +               return ret;
> >>>> +       dev_data->>created_reset_file = true;
> >>>>> +       return 0;
> >>>>> +}
> >>>>
> >>>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
> >>>> "pci.c:__pci_dev_reset" ?
> >>>>
> >>>> The problem with that function is that from my testing it seems that the 
> >>>> first option "pci_dev_specific_reset" always seems to return succes, so all the
> >>>> other options are skipped (flr, pm, slot, bus). However the device it self is 
> >>>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
> >>>> none virtualization purposes and it's probably the least intrusive. For 
> >>>> virtualization however it would be nice to be sure it resets properly, or have a 
> >>>> way to force a specific reset routine.)
> >> 
> >>> Then you need work with the maintainer for those specific devices or
> >>> drivers to fix their specific reset function.
> >> 
> >>> I'm not adding stuff to pciback to workaround broken quirks.
> >> 
> >> OK that's a pretty clear message there, so if one wants to use pci and vga
> >> passthrough one should better use KVM and vfio-pci.
> 
> > Have you (or anyone else) ever raised the problem with the broken reset
> > quirk for certain devices with the relevant maintainer?
> 
> >> vfio-pci has:
> >> - logic to do the try-slot-bus-reset logic
> 
> > Just because vfio-pci fixed it incorrectly doesn't mean pciback has to
> > as well.
> 
> Depends on what you call an "incorrect fix" .. it fixes a quirk .. 
> you can say that's incorrect, but then you would have to remove 50% of
> the kernel and Xen code as well.
> 
> (i do in general agree it's better to strive for a generic solution though,
> that's exactly why i brought up that that function doesn't seem to work perfect
> for virtualization purposes) 
> 
> > It makes no sense for both pciback and vfio-pci to workaround problems
> > with pci_function_reset() in different ways -- it should be fixed in the
> > core PCI code so both can benefit and make use of the same code.
> 
> Well perhaps Bjorn knows why the order of resets and skipping the rest as
> implemented in "pci.c:__pci_dev_reset" was implemented in that way ?
> 
> Especially what is the expectation about pci_dev_specific_reset doing a proper 
> reset for say a vga-card:
> - i know it doesn't work on a radeon card (doesn't blank screen, on next guest 
>   boot reports it's already posted, powermanagement doesn't work).
> - while with a slot/bus reset, that all just works fine, screen blanks 
>   immediately and everything else also works.
> 
> Added Alex as well since he added this workaround for KVM/vfio-pci, perhaps he knows why
> he introduced the workaround in vfio-pci instead of trying to fix it in core pci 
> code ?

I don't know what workaround you're talking about.  As devices are
released from the user, vfio-pci attempts to reset them.  If
pci_reset_function() returns success we mark the device clean, otherwise
it gets marked dirty.  Each time a device is released, if there are
dirty devices we test whether we can try a bus/slot reset to clean them.
In the case of assigning a GPU this typically means that the GPU or
audio function come through first, there's no reset mechanism so it gets
marked dirty, the next device comes through and we manage to try a bus
reset.  vfio-pci does not have any device specific resets, all
functionality is added to the PCI-core, thank-you-very-much.  I even
posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
bad so that pci_reset_function() won't claim that worked.  All VGA
access quirks are done in QEMU, the kernel doesn't have any business in
remapping config space over MMIO regions or trapping other config space
backdoors.

I have never heard of problems with the dev specific reset claiming to
work and not doing anything, there are only a few of these, it should be
easy to debug.

I didn't read the original patch, but the title alone of this patch is
quite confusing.  FLR is specifically a function-level-reset, so one
would expect 'do_flr' to be function specific.  The pci-sysfs 'reset'
attribute is already function specific.  If pci_reset_function() isn't
doing the job and we need to use bus/slot reset, it's clearly not an
FLR.  Thanks,

Alex


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:40:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1XwYW4-0004GT-Ej; Thu, 04 Dec 2014 15:40:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XwYW3-0004GL-D2
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:40:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EB/73-09842-A6080845; Thu, 04 Dec 2014 15:40:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417707625!13457201!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 12255 invoked from network); 4 Dec 2014 15:40:26 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 15:40:26 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwYVj-000FMv-06; Thu, 04 Dec 2014 15:40:07 +0000
Date: Thu, 4 Dec 2014 16:40:06 +0100
From: Tim Deegan <tim@xen.org>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141204154006.GA43178@deinos.phlegethon.org>
References: <CALicx6trd6Pvsit0LfbC66JU5G3r+1XTt0d-h0DLo8rd31X9vw@mail.gmail.com>
	<548066FE.90905@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548066FE.90905@linaro.org>
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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen/arm: uart interrupts handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:51 +0000 on 04 Dec (1417697518), Julien Grall wrote:
> On 04/12/14 03:50, Vijay Kilari wrote:
> > Hi Tim,
> 
> Hi Vijay,
> 
> > I see that on uart interrupt, ICR is written to clear the all
> > interrupts except TX, RX and RX timeout. With this, cpu always finds
> > TX/RX is active and never
> > comes out of the loop.
> 
> FWIW, the PL011 serial code has been copied from the Linux drivers.
> 
> Linux interrupt handler also clear all interrupts except TX, RX, RX
> timeout. So do you see the issue on Linux?
> 
> > 
> > With the below changes, TX, RX & RTI are cleared before handling this
> > interrupts.
> > 
> > Is my observation is correct?. If so I wonder how it is working on
> > platforms that
> > are using pl011. Without this for my cpu just keeps looping here.
> > 
> >   index fba0a55..d21bce3 100644
> > --- a/xen/drivers/char/pl011.c
> > +++ b/xen/drivers/char/pl011.c
> > @@ -63,7 +63,7 @@ static void pl011_interrupt(int irq, void *data,
> > struct cpu_user_regs *regs)
> >      {
> >          do
> >          {
> > -            pl011_write(uart, ICR, status & ~(TXI|RTI|RXI));
> > +            pl011_write(uart, ICR, status & (TXI|RTI|RXI));
> 
> 
> This changes looks wrong to me. We want to clear the bit in status we
> don't handle. Otherwise the interrupt will be fired in loop.

Yes - even if we do want to explicitly clear the TXI|RTI|RXI bits, we
must clear the others too!

> If I'm not mistaken, TXI/RTI/RXI will be cleared when data is read or
> write into the fifo. So we should not clear automatically.

I've been looking at that and I think it's OK for the RX path -- we
ought to keep calling serial_rx_interrupt() until we've drained the
FIFO, at which point both RTI and RXI will be cleared.  Certainly we
shouldn't unconditionally clear RXI/RTI without somehow making sure
that we're not leaving bytes in the FIFO.

The TX path looks more suspect -- if the uart raises TXI and we have
nothing buffered to send, then TXI won't get cleared.
Still, I wonder why you're seeing this and other people haven't.

And again, we ought not to just clear the interrupt:
serial_tx_interrupt might not send any bytes (and indeed by my reading
it won't do anything unless the FIFO is actually empty), in which case
we need to keep something around to tell us to try again.

Actually, looking at the current behaviour, I wonder whether we ought
to push the interrupt trigger back from firing at half-empty.  Like so:

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..2e97234 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -109,6 +109,8 @@ static void __init pl011_init_preirq(struct
serial_port *port)
             panic("pl011: No Baud rate configured\n");
         uart->baud = (uart->clock_hz << 2) / divisor;
     }
+    /* Trigger RX interrupt at 1/2 full, TX interrupt at 7/8 empty */
+    pl011_write(uart, IFLS, (2<<3 | 0));
     /* This write must follow FBRD and IBRD writes. */
     pl011_write(uart, LCR_H, (uart->data_bits - 5) << 5
                             | FEN


Tim.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:40:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1XwYW4-0004GT-Ej; Thu, 04 Dec 2014 15:40:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XwYW3-0004GL-D2
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:40:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EB/73-09842-A6080845; Thu, 04 Dec 2014 15:40:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417707625!13457201!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 12255 invoked from network); 4 Dec 2014 15:40:26 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 15:40:26 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwYVj-000FMv-06; Thu, 04 Dec 2014 15:40:07 +0000
Date: Thu, 4 Dec 2014 16:40:06 +0100
From: Tim Deegan <tim@xen.org>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141204154006.GA43178@deinos.phlegethon.org>
References: <CALicx6trd6Pvsit0LfbC66JU5G3r+1XTt0d-h0DLo8rd31X9vw@mail.gmail.com>
	<548066FE.90905@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548066FE.90905@linaro.org>
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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen/arm: uart interrupts handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:51 +0000 on 04 Dec (1417697518), Julien Grall wrote:
> On 04/12/14 03:50, Vijay Kilari wrote:
> > Hi Tim,
> 
> Hi Vijay,
> 
> > I see that on uart interrupt, ICR is written to clear the all
> > interrupts except TX, RX and RX timeout. With this, cpu always finds
> > TX/RX is active and never
> > comes out of the loop.
> 
> FWIW, the PL011 serial code has been copied from the Linux drivers.
> 
> Linux interrupt handler also clear all interrupts except TX, RX, RX
> timeout. So do you see the issue on Linux?
> 
> > 
> > With the below changes, TX, RX & RTI are cleared before handling this
> > interrupts.
> > 
> > Is my observation is correct?. If so I wonder how it is working on
> > platforms that
> > are using pl011. Without this for my cpu just keeps looping here.
> > 
> >   index fba0a55..d21bce3 100644
> > --- a/xen/drivers/char/pl011.c
> > +++ b/xen/drivers/char/pl011.c
> > @@ -63,7 +63,7 @@ static void pl011_interrupt(int irq, void *data,
> > struct cpu_user_regs *regs)
> >      {
> >          do
> >          {
> > -            pl011_write(uart, ICR, status & ~(TXI|RTI|RXI));
> > +            pl011_write(uart, ICR, status & (TXI|RTI|RXI));
> 
> 
> This changes looks wrong to me. We want to clear the bit in status we
> don't handle. Otherwise the interrupt will be fired in loop.

Yes - even if we do want to explicitly clear the TXI|RTI|RXI bits, we
must clear the others too!

> If I'm not mistaken, TXI/RTI/RXI will be cleared when data is read or
> write into the fifo. So we should not clear automatically.

I've been looking at that and I think it's OK for the RX path -- we
ought to keep calling serial_rx_interrupt() until we've drained the
FIFO, at which point both RTI and RXI will be cleared.  Certainly we
shouldn't unconditionally clear RXI/RTI without somehow making sure
that we're not leaving bytes in the FIFO.

The TX path looks more suspect -- if the uart raises TXI and we have
nothing buffered to send, then TXI won't get cleared.
Still, I wonder why you're seeing this and other people haven't.

And again, we ought not to just clear the interrupt:
serial_tx_interrupt might not send any bytes (and indeed by my reading
it won't do anything unless the FIFO is actually empty), in which case
we need to keep something around to tell us to try again.

Actually, looking at the current behaviour, I wonder whether we ought
to push the interrupt trigger back from firing at half-empty.  Like so:

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..2e97234 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -109,6 +109,8 @@ static void __init pl011_init_preirq(struct
serial_port *port)
             panic("pl011: No Baud rate configured\n");
         uart->baud = (uart->clock_hz << 2) / divisor;
     }
+    /* Trigger RX interrupt at 1/2 full, TX interrupt at 7/8 empty */
+    pl011_write(uart, IFLS, (2<<3 | 0));
     /* This write must follow FBRD and IBRD writes. */
     pl011_write(uart, LCR_H, (uart->data_bits - 5) << 5
                             | FEN


Tim.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:45:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15: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 1XwYan-0004i5-Cn; Thu, 04 Dec 2014 15:45:21 +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 1XwYal-0004i0-T8
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 15:45:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	55/D7-15461-F8180845; Thu, 04 Dec 2014 15:45:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417707916!13490601!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 28007 invoked from network); 4 Dec 2014 15:45:18 -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;
	4 Dec 2014 15:45:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="199780131"
Message-ID: <54808175.8040801@citrix.com>
Date: Thu, 4 Dec 2014 15:44: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: 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>,
	<andrew.cooper3@citrix.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
X-DLP: MIA2
Subject: Re: [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>
Content-Type: text/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:53, 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.

Applied to devel/for-linus-3.19.

Thanks.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:45:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15: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 1XwYan-0004i5-Cn; Thu, 04 Dec 2014 15:45:21 +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 1XwYal-0004i0-T8
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 15:45:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	55/D7-15461-F8180845; Thu, 04 Dec 2014 15:45:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417707916!13490601!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 28007 invoked from network); 4 Dec 2014 15:45:18 -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;
	4 Dec 2014 15:45:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="199780131"
Message-ID: <54808175.8040801@citrix.com>
Date: Thu, 4 Dec 2014 15:44: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: 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>,
	<andrew.cooper3@citrix.com>
References: <1417172039-8627-1-git-send-email-jgross@suse.com>
In-Reply-To: <1417172039-8627-1-git-send-email-jgross@suse.com>
X-DLP: MIA2
Subject: Re: [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>
Content-Type: text/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:53, 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.

Applied to devel/for-linus-3.19.

Thanks.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:46:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:46:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYcF-0004mn-ST; Thu, 04 Dec 2014 15:46: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 1XwYcE-0004mh-Pc
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:46:50 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	2A/14-02576-AE180845; Thu, 04 Dec 2014 15:46:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417708008!13057850!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 15111 invoked from network); 4 Dec 2014 15:46:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 15:46:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="200139474"
Message-ID: <548081D6.4080208@citrix.com>
Date: Thu, 4 Dec 2014 15:46: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: Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
	<54806FA2.6080406@citrix.com>
	<548083EE020000780004CC90@mail.emea.novell.com>
In-Reply-To: <548083EE020000780004CC90@mail.emea.novell.com>
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-develList <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 04/12/14 14:55, Jan Beulich wrote:
>>>> On 04.12.14 at 15:28, <andrew.cooper3@citrix.com> wrote:
>> On 04/12/14 13:49, Jan Beulich wrote:
>>>>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>>>> 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.
>>> With no-one else voicing an opinion:
>>>
>>> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
>>>
>>> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
>>>
>>> For the latter, we're fine even without further consideration. For the
>>> former, the two operations actively using the continuation encoding
>>> are tools-only ones. Since we're fine to alter the tools only interfaces,
>>> and since it was intended for the tools-only HVM-ops to be split off
>>> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
>>> would then no longer be a problem. Plus, in the worst case we could
>>> always introduce yet another hypercall if we ran out of numbers.
>> Are you suggesting that we make a new hvmctl now and remove the hvmop
>> mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
>> subsequently remove it even if all continuable hypercalls move to a
>> separate hypercall.
> Why? We certainly don't guarantee compatibility for undefined
> hypercalls to behave in a certain way.

A task is in the middle of a hypercall continuation.  The VM is migrated
to a newer Xen which has lost the op mask and gained a new hypercall
which would alias.

At this point, the task has transparently swapped hypercall subops,
through no fault of its own.

As I have said before, once an op mask has found its way into a released
version of Xen, it is irrevocably part of the ABI, and cannot change in
the future.

~Andrew


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:46:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:46:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYcF-0004mn-ST; Thu, 04 Dec 2014 15:46: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 1XwYcE-0004mh-Pc
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:46:50 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	2A/14-02576-AE180845; Thu, 04 Dec 2014 15:46:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417708008!13057850!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 15111 invoked from network); 4 Dec 2014 15:46:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 15:46:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="200139474"
Message-ID: <548081D6.4080208@citrix.com>
Date: Thu, 4 Dec 2014 15:46: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: Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
	<54806FA2.6080406@citrix.com>
	<548083EE020000780004CC90@mail.emea.novell.com>
In-Reply-To: <548083EE020000780004CC90@mail.emea.novell.com>
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-develList <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 04/12/14 14:55, Jan Beulich wrote:
>>>> On 04.12.14 at 15:28, <andrew.cooper3@citrix.com> wrote:
>> On 04/12/14 13:49, Jan Beulich wrote:
>>>>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>>>> 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.
>>> With no-one else voicing an opinion:
>>>
>>> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
>>>
>>> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
>>>
>>> For the latter, we're fine even without further consideration. For the
>>> former, the two operations actively using the continuation encoding
>>> are tools-only ones. Since we're fine to alter the tools only interfaces,
>>> and since it was intended for the tools-only HVM-ops to be split off
>>> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
>>> would then no longer be a problem. Plus, in the worst case we could
>>> always introduce yet another hypercall if we ran out of numbers.
>> Are you suggesting that we make a new hvmctl now and remove the hvmop
>> mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
>> subsequently remove it even if all continuable hypercalls move to a
>> separate hypercall.
> Why? We certainly don't guarantee compatibility for undefined
> hypercalls to behave in a certain way.

A task is in the middle of a hypercall continuation.  The VM is migrated
to a newer Xen which has lost the op mask and gained a new hypercall
which would alias.

At this point, the task has transparently swapped hypercall subops,
through no fault of its own.

As I have said before, once an op mask has found its way into a released
version of Xen, it is irrevocably part of the ABI, and cannot change in
the future.

~Andrew


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:46:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1XwYcK-0004nd-8o; Thu, 04 Dec 2014 15:46: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 1XwYcI-0004nL-IR
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:46:54 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	5B/27-11581-DE180845; Thu, 04 Dec 2014 15:46:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417708011!11568543!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 20409 invoked from network); 4 Dec 2014 15:46:53 -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 Dec 2014 15:46:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="200139589"
Message-ID: <548081E2.3080703@citrix.com>
Date: Thu, 4 Dec 2014 15:46:42 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, <bhelgaas@google.com>,
	<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xenproject.org>, <boris.ostrovsky@oracle.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH v5] 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>
Content-Type: text/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/12/14 21:40, Konrad Rzeszutek Wilk wrote:
> 
> These patches fix some issues with PCI back and also add proper
> bus/slot reset.

Applied 1-8 to devel/for-linus-3.19.  I did not apply #9.

Thanks.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:46:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1XwYcK-0004nd-8o; Thu, 04 Dec 2014 15:46: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 1XwYcI-0004nL-IR
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:46:54 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	5B/27-11581-DE180845; Thu, 04 Dec 2014 15:46:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417708011!11568543!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 20409 invoked from network); 4 Dec 2014 15:46:53 -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 Dec 2014 15:46:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="200139589"
Message-ID: <548081E2.3080703@citrix.com>
Date: Thu, 4 Dec 2014 15:46:42 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, <bhelgaas@google.com>,
	<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xenproject.org>, <boris.ostrovsky@oracle.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH v5] 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>
Content-Type: text/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/12/14 21:40, Konrad Rzeszutek Wilk wrote:
> 
> These patches fix some issues with PCI back and also add proper
> bus/slot reset.

Applied 1-8 to devel/for-linus-3.19.  I did not apply #9.

Thanks.

David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:50:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:50:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYfM-00053n-Ud; Thu, 04 Dec 2014 15:50: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 1XwYfL-00053e-VS
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:50:04 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	BC/78-18267-BA280845; Thu, 04 Dec 2014 15:50:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417708202!11128102!1
X-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 8368 invoked from network); 4 Dec 2014 15:50:02 -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 Dec 2014 15:50:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 15:50:01 +0000
Message-Id: <548090BA020000780004CCE6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 15:50:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-5-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -22,27 +22,66 @@ 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;
> +    unsigned int i;
> +    u32 sbdf;
> +    struct compat_reserved_device_memory rdm = {
> +        .start_pfn = start, .nr_pages = nr
> +    };
>  
> -    if ( grdm->used_entries < grdm->map.nr_entries )
> -    {
> -        struct compat_reserved_device_memory rdm = {
> -            .start_pfn = start, .nr_pages = nr
> -        };
> +    if ( rdm.start_pfn != start || rdm.nr_pages != nr )
> +        return -ERANGE;
>  
> -        if ( rdm.start_pfn != start || rdm.nr_pages != nr )
> -            return -ERANGE;
> +    d = rcu_lock_domain_by_any_id(grdm->map.domid);
> +    if ( d == NULL )
> +        return -ESRCH;

So why are you doing this in the call back (potentially many times)
instead of just once in compat_memory_op(), storing the pointer in
the context structure?

>  
> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
> -                                     &rdm, 1) )
> -            return -EFAULT;
> +    if ( d )
> +    {
> +        if ( d->arch.hvm_domain.pci_force )

You didn't verify that the domain is a HVM/PVH one.

> +        {
> +            if ( grdm->used_entries < grdm->map.nr_entries )
> +            {
> +                if ( __copy_to_compat_offset(grdm->map.buffer,
> +                                             grdm->used_entries,
> +                                             &rdm, 1) )
> +                {
> +                    rcu_unlock_domain(d);
> +                    return -EFAULT;
> +                }
> +            }
> +            ++grdm->used_entries;
> +        }
> +        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 ( grdm->used_entries < grdm->map.nr_entries )
> +                    {
> +                        if ( __copy_to_compat_offset(grdm->map.buffer,
> +                                                     grdm->used_entries,
> +                                                     &rdm, 1) )
> +                        {
> +                            rcu_unlock_domain(d);
> +                            return -EFAULT;
> +                        }
> +                    }
> +                    ++grdm->used_entries;

break;

Also trying to fold code identical on the if and else branches would
seem pretty desirable.

> @@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>  
>              if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>                  rc = -ENOBUFS;
> +
>              grdm.map.nr_entries = grdm.used_entries;
> -            if ( __copy_to_guest(compat, &grdm.map, 1) )
> -                rc = -EFAULT;
> +            if ( grdm.map.nr_entries )
> +            {
> +                if ( __copy_to_guest(compat, &grdm.map, 1) )
> +                    rc = -EFAULT;
> +            }

Why do you need this change?

> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
>  
>  int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>  {
> -    struct acpi_rmrr_unit *rmrr;
> +    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
>      int rc = 0;
> +    unsigned 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 ( 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;
> +
> +            /* Just go next. */
> +            if ( !rc )
> +                rmrr_cur = rmrr;
> +
> +            /* Now just return specific to user requirement. */
> +            if ( rc > 0 )
> +                return rc;

Nice that you check for that, but I can't see this case occurring
anymore. Did you lose some code? Also please don't write code
more complicated than necessary. The above two if()s could be


+            if ( rc > 0 )
+                return rc;
+
+            rmrr_cur = rmrr;

> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -586,6 +586,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 */

Your addition lacks an IN annotation.

> --- 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))

Missing several parentheses.

Jan

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:50:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:50:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYfM-00053n-Ud; Thu, 04 Dec 2014 15:50: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 1XwYfL-00053e-VS
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:50:04 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	BC/78-18267-BA280845; Thu, 04 Dec 2014 15:50:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417708202!11128102!1
X-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 8368 invoked from network); 4 Dec 2014 15:50:02 -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 Dec 2014 15:50:02 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 15:50:01 +0000
Message-Id: <548090BA020000780004CCE6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 15:50:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-5-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -22,27 +22,66 @@ 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;
> +    unsigned int i;
> +    u32 sbdf;
> +    struct compat_reserved_device_memory rdm = {
> +        .start_pfn = start, .nr_pages = nr
> +    };
>  
> -    if ( grdm->used_entries < grdm->map.nr_entries )
> -    {
> -        struct compat_reserved_device_memory rdm = {
> -            .start_pfn = start, .nr_pages = nr
> -        };
> +    if ( rdm.start_pfn != start || rdm.nr_pages != nr )
> +        return -ERANGE;
>  
> -        if ( rdm.start_pfn != start || rdm.nr_pages != nr )
> -            return -ERANGE;
> +    d = rcu_lock_domain_by_any_id(grdm->map.domid);
> +    if ( d == NULL )
> +        return -ESRCH;

So why are you doing this in the call back (potentially many times)
instead of just once in compat_memory_op(), storing the pointer in
the context structure?

>  
> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
> -                                     &rdm, 1) )
> -            return -EFAULT;
> +    if ( d )
> +    {
> +        if ( d->arch.hvm_domain.pci_force )

You didn't verify that the domain is a HVM/PVH one.

> +        {
> +            if ( grdm->used_entries < grdm->map.nr_entries )
> +            {
> +                if ( __copy_to_compat_offset(grdm->map.buffer,
> +                                             grdm->used_entries,
> +                                             &rdm, 1) )
> +                {
> +                    rcu_unlock_domain(d);
> +                    return -EFAULT;
> +                }
> +            }
> +            ++grdm->used_entries;
> +        }
> +        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 ( grdm->used_entries < grdm->map.nr_entries )
> +                    {
> +                        if ( __copy_to_compat_offset(grdm->map.buffer,
> +                                                     grdm->used_entries,
> +                                                     &rdm, 1) )
> +                        {
> +                            rcu_unlock_domain(d);
> +                            return -EFAULT;
> +                        }
> +                    }
> +                    ++grdm->used_entries;

break;

Also trying to fold code identical on the if and else branches would
seem pretty desirable.

> @@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>  
>              if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>                  rc = -ENOBUFS;
> +
>              grdm.map.nr_entries = grdm.used_entries;
> -            if ( __copy_to_guest(compat, &grdm.map, 1) )
> -                rc = -EFAULT;
> +            if ( grdm.map.nr_entries )
> +            {
> +                if ( __copy_to_guest(compat, &grdm.map, 1) )
> +                    rc = -EFAULT;
> +            }

Why do you need this change?

> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
>  
>  int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>  {
> -    struct acpi_rmrr_unit *rmrr;
> +    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
>      int rc = 0;
> +    unsigned 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 ( 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;
> +
> +            /* Just go next. */
> +            if ( !rc )
> +                rmrr_cur = rmrr;
> +
> +            /* Now just return specific to user requirement. */
> +            if ( rc > 0 )
> +                return rc;

Nice that you check for that, but I can't see this case occurring
anymore. Did you lose some code? Also please don't write code
more complicated than necessary. The above two if()s could be


+            if ( rc > 0 )
+                return rc;
+
+            rmrr_cur = rmrr;

> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -586,6 +586,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 */

Your addition lacks an IN annotation.

> --- 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))

Missing several parentheses.

Jan

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:50:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15: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 1XwYfY-00055N-CE; Thu, 04 Dec 2014 15:50:16 +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 1XwYfX-00055A-91
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:50:15 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	0C/4B-02697-6B280845; Thu, 04 Dec 2014 15:50:14 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417708213!4004694!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 13492 invoked from network); 4 Dec 2014 15:50:14 -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; 4 Dec 2014 15:50:14 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwYfB-000FVy-Vd; Thu, 04 Dec 2014 15:49:53 +0000
Date: Thu, 4 Dec 2014 16:49:53 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141204154953.GB43178@deinos.phlegethon.org>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
	<54806FA2.6080406@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54806FA2.6080406@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-develList <xen-devel@lists.xen.org>,
	IanCampbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
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

At 14:28 +0000 on 04 Dec (1417699730), Andrew Cooper wrote:
> On 04/12/14 13:49, Jan Beulich wrote:
> >>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
> >> 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.
> > With no-one else voicing an opinion:
> >
> > For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
> >
> > For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
> >
> > For the latter, we're fine even without further consideration. For the
> > former, the two operations actively using the continuation encoding
> > are tools-only ones. Since we're fine to alter the tools only interfaces,
> > and since it was intended for the tools-only HVM-ops to be split off
> > to a separate hypercall (e.g. hvmctl) anyway, the range restriction
> > would then no longer be a problem. Plus, in the worst case we could
> > always introduce yet another hypercall if we ran out of numbers.
> 
> Are you suggesting that we make a new hvmctl now and remove the hvmop
> mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
> subsequently remove it even if all continuable hypercalls move to a
> separate hypercall.

I think we can if the only hypercalls that use continuations are
tools-only (and so not liable to work across migration anyway).

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:50:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15: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 1XwYfY-00055N-CE; Thu, 04 Dec 2014 15:50:16 +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 1XwYfX-00055A-91
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:50:15 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	0C/4B-02697-6B280845; Thu, 04 Dec 2014 15:50:14 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417708213!4004694!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 13492 invoked from network); 4 Dec 2014 15:50:14 -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; 4 Dec 2014 15:50:14 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwYfB-000FVy-Vd; Thu, 04 Dec 2014 15:49:53 +0000
Date: Thu, 4 Dec 2014 16:49:53 +0100
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141204154953.GB43178@deinos.phlegethon.org>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
	<54806FA2.6080406@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54806FA2.6080406@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-develList <xen-devel@lists.xen.org>,
	IanCampbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
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

At 14:28 +0000 on 04 Dec (1417699730), Andrew Cooper wrote:
> On 04/12/14 13:49, Jan Beulich wrote:
> >>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
> >> 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.
> > With no-one else voicing an opinion:
> >
> > For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
> >
> > For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
> >
> > For the latter, we're fine even without further consideration. For the
> > former, the two operations actively using the continuation encoding
> > are tools-only ones. Since we're fine to alter the tools only interfaces,
> > and since it was intended for the tools-only HVM-ops to be split off
> > to a separate hypercall (e.g. hvmctl) anyway, the range restriction
> > would then no longer be a problem. Plus, in the worst case we could
> > always introduce yet another hypercall if we ran out of numbers.
> 
> Are you suggesting that we make a new hvmctl now and remove the hvmop
> mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
> subsequently remove it even if all continuable hypercalls move to a
> separate hypercall.

I think we can if the only hypercalls that use continuations are
tools-only (and so not liable to work across migration anyway).

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:53:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYiD-0005WU-55; Thu, 04 Dec 2014 15:53:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwYiB-0005WG-1Z
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:52:59 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	9D/50-22819-A5380845; Thu, 04 Dec 2014 15:52:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417708377!11569848!1
X-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 1160 invoked from network); 4 Dec 2014 15:52:58 -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; 4 Dec 2014 15:52:58 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 15:52:57 +0000
Message-Id: <54809169020000780004CD03@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 15:52:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-8-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> We need to use reserved device memory maps with multiple times, so
> provide just one common function should be friend.

I'm not going to repeat earlier comments; the way this is done right
now it's neither a proper runtime function nor a proper init time 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 Dec 04 15:53:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYiD-0005WU-55; Thu, 04 Dec 2014 15:53:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwYiB-0005WG-1Z
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:52:59 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	9D/50-22819-A5380845; Thu, 04 Dec 2014 15:52:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417708377!11569848!1
X-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 1160 invoked from network); 4 Dec 2014 15:52:58 -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; 4 Dec 2014 15:52:58 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 15:52:57 +0000
Message-Id: <54809169020000780004CD03@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 15:52:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-8-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> We need to use reserved device memory maps with multiple times, so
> provide just one common function should be friend.

I'm not going to repeat earlier comments; the way this is done right
now it's neither a proper runtime function nor a proper init time 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 Dec 04 15:53:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:53:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYig-0005bA-I9; Thu, 04 Dec 2014 15:53:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XwYif-0005az-LG
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 15:53:29 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	90/75-15461-97380845; Thu, 04 Dec 2014 15:53:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417708405!13446014!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 15053 invoked from network); 4 Dec 2014 15:53:28 -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;
	4 Dec 2014 15:53:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="200142813"
Message-ID: <54808372.8090102@citrix.com>
Date: Thu, 4 Dec 2014 15:53:22 +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: Anthony Wright <anthony@overnetdata.com>, David Vrabel
	<david.vrabel@citrix.com>
References: <19758084.30.1417707380178.JavaMail.root@zimbra.overnetdata.com>
In-Reply-To: <19758084.30.1417707380178.JavaMail.root@zimbra.overnetdata.com>
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] 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 04/12/14 15:36, Anthony Wright wrote:
>> On 01/12/14 14:22, David Vrabel wrote:
>> This VIF protocol is weird. The first slot contains a txreq with a
>> size
>> for the total length of the packet, subsequent slots have sizes for
>> that
>> fragment only.
>>
>> netback then has to calculate how long the first slot is, by
>> subtracting
>> all the size from the following slots.
>>
>> So something has gone wrong but it's not obvious what it is. Any
>> chance
>> you can dump the ring state when it happens?
> 
> We think we've worked out how to dump the ring state, please see below.

We need the full contents of the ring which isn't currently available
via debugfs and I haven't had time to put together a debug patch to make
it available.

David



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:53:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:53:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYig-0005bA-I9; Thu, 04 Dec 2014 15:53:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XwYif-0005az-LG
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 15:53:29 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	90/75-15461-97380845; Thu, 04 Dec 2014 15:53:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417708405!13446014!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 15053 invoked from network); 4 Dec 2014 15:53:28 -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;
	4 Dec 2014 15:53:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="200142813"
Message-ID: <54808372.8090102@citrix.com>
Date: Thu, 4 Dec 2014 15:53:22 +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: Anthony Wright <anthony@overnetdata.com>, David Vrabel
	<david.vrabel@citrix.com>
References: <19758084.30.1417707380178.JavaMail.root@zimbra.overnetdata.com>
In-Reply-To: <19758084.30.1417707380178.JavaMail.root@zimbra.overnetdata.com>
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] 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 04/12/14 15:36, Anthony Wright wrote:
>> On 01/12/14 14:22, David Vrabel wrote:
>> This VIF protocol is weird. The first slot contains a txreq with a
>> size
>> for the total length of the packet, subsequent slots have sizes for
>> that
>> fragment only.
>>
>> netback then has to calculate how long the first slot is, by
>> subtracting
>> all the size from the following slots.
>>
>> So something has gone wrong but it's not obvious what it is. Any
>> chance
>> you can dump the ring state when it happens?
> 
> We think we've worked out how to dump the ring state, please see below.

We need the full contents of the ring which isn't currently available
via debugfs and I haven't had time to put together a debug patch to make
it available.

David



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:53:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1XwYik-0005cX-VK; Thu, 04 Dec 2014 15:53:34 +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 1XwYik-0005c8-0b
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:53:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	CA/DC-09842-D7380845; Thu, 04 Dec 2014 15:53:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417708411!13470511!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25541 invoked from network); 4 Dec 2014 15:53:32 -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; 4 Dec 2014 15:53: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 sB4FrJ9x001871
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 15:53:20 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
	sB4FrIjr006545
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 4 Dec 2014 15:53:19 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
	sB4FrHwD009941; Thu, 4 Dec 2014 15:53:18 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, 04 Dec 2014 07:53:17 -0800
Message-ID: <548083D7.70006@oracle.com>
Date: Thu, 04 Dec 2014 10:55:03 -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>
	<5475E46B.9000502@oracle.com>
	<5476F580020000780004B0E2@mail.emea.novell.com>
	<547F6EF3.5080304@oracle.com>
	<54802EB9020000780004C994@mail.emea.novell.com>
In-Reply-To: <54802EB9020000780004C994@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 12/04/2014 03:51 AM, Jan Beulich wrote:
>>>> On 03.12.14 at 21:13, <boris.ostrovsky@oracle.com> wrote:
>> On 11/27/2014 03:57 AM, Jan Beulich wrote:
>>>>>> 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.
>> I started to make this change and then I realized that the next patch
>> (12/21) is actually already taking care of this problem: most of the
>> *_vpmu_initialise() will be executed as initcalls during host boot and
>> if any of those fail then we do want to disable VPMU globally (those
>> failures would not be VCPU-specific).
> Funny that you say that - it was actually while reviewing that next
> patch when I made that observation: svm_vpmu_initialise() get a
> -ENOMEM return _added_ there for example, which is contrary to
> what I asked for above.


Oh, *that* initialization code (I was looking at vpmu_init()). Yes, VPMU 
should not be turned off there.

-boris


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:53:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1XwYik-0005cX-VK; Thu, 04 Dec 2014 15:53:34 +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 1XwYik-0005c8-0b
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:53:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	CA/DC-09842-D7380845; Thu, 04 Dec 2014 15:53:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417708411!13470511!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25541 invoked from network); 4 Dec 2014 15:53:32 -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; 4 Dec 2014 15:53: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 sB4FrJ9x001871
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 15:53:20 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
	sB4FrIjr006545
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 4 Dec 2014 15:53:19 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
	sB4FrHwD009941; Thu, 4 Dec 2014 15:53:18 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, 04 Dec 2014 07:53:17 -0800
Message-ID: <548083D7.70006@oracle.com>
Date: Thu, 04 Dec 2014 10:55:03 -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>
	<5475E46B.9000502@oracle.com>
	<5476F580020000780004B0E2@mail.emea.novell.com>
	<547F6EF3.5080304@oracle.com>
	<54802EB9020000780004C994@mail.emea.novell.com>
In-Reply-To: <54802EB9020000780004C994@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 12/04/2014 03:51 AM, Jan Beulich wrote:
>>>> On 03.12.14 at 21:13, <boris.ostrovsky@oracle.com> wrote:
>> On 11/27/2014 03:57 AM, Jan Beulich wrote:
>>>>>> 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.
>> I started to make this change and then I realized that the next patch
>> (12/21) is actually already taking care of this problem: most of the
>> *_vpmu_initialise() will be executed as initcalls during host boot and
>> if any of those fail then we do want to disable VPMU globally (those
>> failures would not be VCPU-specific).
> Funny that you say that - it was actually while reviewing that next
> patch when I made that observation: svm_vpmu_initialise() get a
> -ENOMEM return _added_ there for example, which is contrary to
> what I asked for above.


Oh, *that* initialization code (I was looking at vpmu_init()). Yes, VPMU 
should not be turned off there.

-boris


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 15:54:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYjn-0005oh-Nb; Thu, 04 Dec 2014 15:54: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 1XwYjm-0005oO-9v
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:54:38 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	BD/12-08051-DB380845; Thu, 04 Dec 2014 15:54:37 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417708476!9705616!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31073 invoked from network); 4 Dec 2014 15:54:37 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 15:54:37 -0000
Received: by mail-wi0-f169.google.com with SMTP id r20so36796600wiv.0
	for <xen-devel@lists.xenproject.org>;
	Thu, 04 Dec 2014 07:54: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=IjjP5pCZj6ErB0AJcosxygohsSDYx1HwMDB0nYmcSTI=;
	b=F7/cr6v26we8ymH0agQo9uUG0sY98sm5pTnpy2YyLd345Lw6A7jjQdc0CAFiT9QBow
	gzcq8domc5vxcn5KBOT4zWjCP9E4nAEZTT/z38zf9KGVvii+g0iw1GWs4Mf/G3a7fzhl
	+WYIp7tOreLnYC//4jNGOba3o1hNfbKkdIACgjTu3hZvdAXzleswufRZvr4pe65g9IAx
	iAidJL1lqrB3aK46QCeWU55+50PGuzQ3WIj4pyniBZ4JDedbCRyVAxOcRa2H315FYP7u
	qT80OpWyMsIlLK7mBJXlIyoOckQj163Lohf0evQ2GEQ0SHJixDXmaMju+cTZZ6hHthAF
	Fugw==
X-Gm-Message-State: ALoCoQkSelwXAg4cd6uMC5XuzJRWFiMrliN/+0vVe6WRwy250ClnlTKaPDNKQr3W67RkaeBOSRXE
X-Received: by 10.180.104.65 with SMTP id gc1mr34071759wib.46.1417708475126;
	Thu, 04 Dec 2014 07:54:35 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id hn2sm41019873wjc.5.2014.12.04.07.54.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 04 Dec 2014 07:54:34 -0800 (PST)
Message-ID: <548083B6.8010408@linaro.org>
Date: Thu, 04 Dec 2014 15:54:30 +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: Vitaly Kuznetsov <vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>	<547FAFDD.8010005@linaro.org>
	<87wq67h2iu.fsf@vitty.brq.redhat.com>
In-Reply-To: <87wq67h2iu.fsf@vitty.brq.redhat.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 15:12, Vitaly Kuznetsov wrote:
> Julien Grall <julien.grall@linaro.org> writes:
> 
>> Hi Vitaly,
>>
>> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>>> New operation sets the 'recipient' domain which will recieve all
>>
>> s/recieve/receive/
>>
>>> memory pages from a particular domain and kills the original domain.
>>>
>>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>>> ---
>>> @@ -1764,13 +1765,32 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>>
>> [..]
>>
>>> +        else
>>> +        {
>>> +            mfn = page_to_mfn(pg);
>>> +            gmfn = mfn_to_gmfn(d, mfn);
>>> +
>>> +            page_set_owner(pg, NULL);
>>> +            if ( assign_pages(d->recipient, pg, order, 0) )
>>> +                /* assign_pages reports the error by itself */
>>> +                goto out;
>>> +
>>> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
>>
>> On ARM, mfn_to_gmfn will always return the mfn. This would result to
>> add a 1:1 mapping in the recipient domain.
>>
>> But ... only DOM0 has its memory mapped 1:1. So this code may blow up
>> the P2M of the recipient domain.
> 
> I know almost nothing about ARM so please bear with me. So, for a guest
> domain the mapping is not 1:1 (so guest sees different addresses) but
> mfn_to_gmfn() doesn't returs these addresses?

Yes. I guess it's because this macro is not really used (see why below).
Ian, Stefano: any idea why mfn_to_gfmn is not correctly implemented on ARM?

> I was under an impression
> it is not x86-specific and I can see its usage in e.g. getdomaininfo(),
> memory_exchange(),..

I can find two places in the common code:
	- getdomaininfo: The return is obviously buggy. Though, it doesn't seem
to be used in the toolstack side for ARM
	- memory_exchange: AFAIK this is not supported right now.

> How can one figure out the mapping then?

AFAIK, there is no way on ARM to get a GMFN from an MFN in Xen.

Maybe we should implement it correctly mfn_to_gmfn on ARM? Ian, Stefano,
any though?

> Anyway, what I want to do here is: when this page is freed I want to
> reassign it to our newly-created guest at the exact same address it was
> mapped in the original domain. 

> BTW, what's the current state of affairs with kexec and ARM guest?

AFAIK, nobody has worked on it for Xen ARM. I don't even know the status
for Kexec on ARM.

> I
> suppose we should have similar problems: vcpu_info, event channels,
> .. 

ARM guest is very similar to PVH guest. All the problems you will fixed
now means less work when we will add support for ARM ;).

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 Dec 04 15:54:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwYjn-0005oh-Nb; Thu, 04 Dec 2014 15:54: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 1XwYjm-0005oO-9v
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:54:38 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	BD/12-08051-DB380845; Thu, 04 Dec 2014 15:54:37 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417708476!9705616!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31073 invoked from network); 4 Dec 2014 15:54:37 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 15:54:37 -0000
Received: by mail-wi0-f169.google.com with SMTP id r20so36796600wiv.0
	for <xen-devel@lists.xenproject.org>;
	Thu, 04 Dec 2014 07:54: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=IjjP5pCZj6ErB0AJcosxygohsSDYx1HwMDB0nYmcSTI=;
	b=F7/cr6v26we8ymH0agQo9uUG0sY98sm5pTnpy2YyLd345Lw6A7jjQdc0CAFiT9QBow
	gzcq8domc5vxcn5KBOT4zWjCP9E4nAEZTT/z38zf9KGVvii+g0iw1GWs4Mf/G3a7fzhl
	+WYIp7tOreLnYC//4jNGOba3o1hNfbKkdIACgjTu3hZvdAXzleswufRZvr4pe65g9IAx
	iAidJL1lqrB3aK46QCeWU55+50PGuzQ3WIj4pyniBZ4JDedbCRyVAxOcRa2H315FYP7u
	qT80OpWyMsIlLK7mBJXlIyoOckQj163Lohf0evQ2GEQ0SHJixDXmaMju+cTZZ6hHthAF
	Fugw==
X-Gm-Message-State: ALoCoQkSelwXAg4cd6uMC5XuzJRWFiMrliN/+0vVe6WRwy250ClnlTKaPDNKQr3W67RkaeBOSRXE
X-Received: by 10.180.104.65 with SMTP id gc1mr34071759wib.46.1417708475126;
	Thu, 04 Dec 2014 07:54:35 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id hn2sm41019873wjc.5.2014.12.04.07.54.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 04 Dec 2014 07:54:34 -0800 (PST)
Message-ID: <548083B6.8010408@linaro.org>
Date: Thu, 04 Dec 2014 15:54:30 +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: Vitaly Kuznetsov <vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>	<1417626981-8432-5-git-send-email-vkuznets@redhat.com>	<547FAFDD.8010005@linaro.org>
	<87wq67h2iu.fsf@vitty.brq.redhat.com>
In-Reply-To: <87wq67h2iu.fsf@vitty.brq.redhat.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 15:12, Vitaly Kuznetsov wrote:
> Julien Grall <julien.grall@linaro.org> writes:
> 
>> Hi Vitaly,
>>
>> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>>> New operation sets the 'recipient' domain which will recieve all
>>
>> s/recieve/receive/
>>
>>> memory pages from a particular domain and kills the original domain.
>>>
>>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>>> ---
>>> @@ -1764,13 +1765,32 @@ void free_domheap_pages(struct page_info *pg, unsigned int order)
>>
>> [..]
>>
>>> +        else
>>> +        {
>>> +            mfn = page_to_mfn(pg);
>>> +            gmfn = mfn_to_gmfn(d, mfn);
>>> +
>>> +            page_set_owner(pg, NULL);
>>> +            if ( assign_pages(d->recipient, pg, order, 0) )
>>> +                /* assign_pages reports the error by itself */
>>> +                goto out;
>>> +
>>> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
>>
>> On ARM, mfn_to_gmfn will always return the mfn. This would result to
>> add a 1:1 mapping in the recipient domain.
>>
>> But ... only DOM0 has its memory mapped 1:1. So this code may blow up
>> the P2M of the recipient domain.
> 
> I know almost nothing about ARM so please bear with me. So, for a guest
> domain the mapping is not 1:1 (so guest sees different addresses) but
> mfn_to_gmfn() doesn't returs these addresses?

Yes. I guess it's because this macro is not really used (see why below).
Ian, Stefano: any idea why mfn_to_gfmn is not correctly implemented on ARM?

> I was under an impression
> it is not x86-specific and I can see its usage in e.g. getdomaininfo(),
> memory_exchange(),..

I can find two places in the common code:
	- getdomaininfo: The return is obviously buggy. Though, it doesn't seem
to be used in the toolstack side for ARM
	- memory_exchange: AFAIK this is not supported right now.

> How can one figure out the mapping then?

AFAIK, there is no way on ARM to get a GMFN from an MFN in Xen.

Maybe we should implement it correctly mfn_to_gmfn on ARM? Ian, Stefano,
any though?

> Anyway, what I want to do here is: when this page is freed I want to
> reassign it to our newly-created guest at the exact same address it was
> mapped in the original domain. 

> BTW, what's the current state of affairs with kexec and ARM guest?

AFAIK, nobody has worked on it for Xen ARM. I don't even know the status
for Kexec on ARM.

> I
> suppose we should have similar problems: vcpu_info, event channels,
> .. 

ARM guest is very similar to PVH guest. All the problems you will fixed
now means less work when we will add support for ARM ;).

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 Dec 04 15:57:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15: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 1XwYm1-00064k-98; Thu, 04 Dec 2014 15:56:57 +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 1XwYm0-00064d-4u
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:56:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	86/DA-15461-74480845; Thu, 04 Dec 2014 15:56:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417708615!10031488!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 5961 invoked from network); 4 Dec 2014 15:56:55 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 15:56:55 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwYlj-000Feb-88; Thu, 04 Dec 2014 15:56:39 +0000
Date: Thu, 4 Dec 2014 16:56:39 +0100
From: Tim Deegan <tim@xen.org>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Message-ID: <20141204155639.GC43116@deinos.phlegethon.org>
References: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417698806-26807-2-git-send-email-yu.c.zhang@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417698806-26807-2-git-send-email-yu.c.zhang@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, JBeulich@suse.com,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v5 1/2] add a new p2m type class -
	P2M_DISCARD_WRITE_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

At 21:13 +0800 on 04 Dec (1417724005), Yu Zhang wrote:
> From: Yu Zhang <yu.c.zhang@intel.com>
> 
> Currently, the P2M_RO_TYPES bears 2 meanings: one is
> "_PAGE_RW bit is clear in their PTEs", and another is
> to discard the write operations on these pages. This
> patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
> to bear the second meaning, so we can use this type
> class instead of the P2M_RO_TYPES, to decide if a write
> operation is to be ignored.
> 
> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.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 Dec 04 15:57:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 15: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 1XwYm1-00064k-98; Thu, 04 Dec 2014 15:56:57 +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 1XwYm0-00064d-4u
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 15:56:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	86/DA-15461-74480845; Thu, 04 Dec 2014 15:56:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417708615!10031488!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 5961 invoked from network); 4 Dec 2014 15:56:55 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 15:56:55 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwYlj-000Feb-88; Thu, 04 Dec 2014 15:56:39 +0000
Date: Thu, 4 Dec 2014 16:56:39 +0100
From: Tim Deegan <tim@xen.org>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Message-ID: <20141204155639.GC43116@deinos.phlegethon.org>
References: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417698806-26807-2-git-send-email-yu.c.zhang@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417698806-26807-2-git-send-email-yu.c.zhang@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, JBeulich@suse.com,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v5 1/2] add a new p2m type class -
	P2M_DISCARD_WRITE_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

At 21:13 +0800 on 04 Dec (1417724005), Yu Zhang wrote:
> From: Yu Zhang <yu.c.zhang@intel.com>
> 
> Currently, the P2M_RO_TYPES bears 2 meanings: one is
> "_PAGE_RW bit is clear in their PTEs", and another is
> to discard the write operations on these pages. This
> patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
> to bear the second meaning, so we can use this type
> class instead of the P2M_RO_TYPES, to decide if a write
> operation is to be ignored.
> 
> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.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 Dec 04 16:05:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwYtq-0006gz-JA; Thu, 04 Dec 2014 16:05:02 +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 1XwYtp-0006gq-9J
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:05:01 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	49/B8-03145-C2680845; Thu, 04 Dec 2014 16:05:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417709099!13056794!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 32168 invoked from network); 4 Dec 2014 16:04:59 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 16:04:59 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwYtZ-000FoS-At; Thu, 04 Dec 2014 16:04:45 +0000
Date: Thu, 4 Dec 2014 17:04:45 +0100
From: Tim Deegan <tim@xen.org>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Message-ID: <20141204160445.GD43116@deinos.phlegethon.org>
References: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417698806-26807-3-git-send-email-yu.c.zhang@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417698806-26807-3-git-send-email-yu.c.zhang@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, JBeulich@suse.com,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v5 2/2] add a new p2m type -
	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

Hi, 

At 21:13 +0800 on 04 Dec (1417724006), Yu Zhang wrote:
> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
> the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
> model, and will be discarded later in __hvm_copy(); while for the
> p2m_mmio_write_dm type pages, writes will go to the device model
> via ioreq-server.
> 
> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
> Signed-off-by: Wei Ye <wei.ye@intel.com>

Thanks for this -- only two comments:

> @@ -5978,7 +5982,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>                  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 )

I think that Jan already brough this up, and maybe I missed your
answer: this realaxation looks wrong to me. I would have thought that
transition between p2m_mmio_write_dm and p2m_ram_rw/p2m_ram_logdirty
would be the only ones you would want to allow.

> @@ -111,7 +112,8 @@ typedef unsigned int p2m_query_t;
>  #define P2M_RO_TYPES (p2m_to_mask(p2m_ram_logdirty)     \
>                        | p2m_to_mask(p2m_ram_ro)         \
>                        | p2m_to_mask(p2m_grant_map_ro)   \
> -                      | p2m_to_mask(p2m_ram_shared) )
> +                      | p2m_to_mask(p2m_ram_shared)   \
> +                      | p2m_to_mask(p2m_mmio_write_dm))

Nit: please align the '\' with the others above 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 Dec 04 16:05:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwYto-0006gj-7R; Thu, 04 Dec 2014 16:05:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwYtm-0006ge-AB
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:04:58 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	07/5D-25547-92680845; Thu, 04 Dec 2014 16:04:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417709096!11071989!1
X-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 4071 invoked from network); 4 Dec 2014 16:04:57 -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; 4 Dec 2014 16:04:57 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:04:56 +0000
Message-Id: <54809437020000780004CD43@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:04:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-9-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-9-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 08/17] hvmloader/mmio: reconcile guest
 mmio with reserved device 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 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> We need to make sure all mmio allocation don't overlap
> any rdm, reserved device memory. Here we just skip
> all reserved device memory range in mmio space.

I think someone else already suggested that this and patch 9 should
be swapped, and the BAR allocation be changed to use the E820
map as input. That may end up being a bigger change, but will yield
ultimately better (and namely better maintainable) code.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:05:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwYtq-0006gz-JA; Thu, 04 Dec 2014 16:05:02 +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 1XwYtp-0006gq-9J
	for Xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:05:01 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	49/B8-03145-C2680845; Thu, 04 Dec 2014 16:05:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417709099!13056794!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 32168 invoked from network); 4 Dec 2014 16:04:59 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 16:04:59 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwYtZ-000FoS-At; Thu, 04 Dec 2014 16:04:45 +0000
Date: Thu, 4 Dec 2014 17:04:45 +0100
From: Tim Deegan <tim@xen.org>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Message-ID: <20141204160445.GD43116@deinos.phlegethon.org>
References: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417698806-26807-3-git-send-email-yu.c.zhang@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417698806-26807-3-git-send-email-yu.c.zhang@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, JBeulich@suse.com,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v5 2/2] add a new p2m type -
	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

Hi, 

At 21:13 +0800 on 04 Dec (1417724006), Yu Zhang wrote:
> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
> the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
> model, and will be discarded later in __hvm_copy(); while for the
> p2m_mmio_write_dm type pages, writes will go to the device model
> via ioreq-server.
> 
> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
> Signed-off-by: Wei Ye <wei.ye@intel.com>

Thanks for this -- only two comments:

> @@ -5978,7 +5982,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>                  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 )

I think that Jan already brough this up, and maybe I missed your
answer: this realaxation looks wrong to me. I would have thought that
transition between p2m_mmio_write_dm and p2m_ram_rw/p2m_ram_logdirty
would be the only ones you would want to allow.

> @@ -111,7 +112,8 @@ typedef unsigned int p2m_query_t;
>  #define P2M_RO_TYPES (p2m_to_mask(p2m_ram_logdirty)     \
>                        | p2m_to_mask(p2m_ram_ro)         \
>                        | p2m_to_mask(p2m_grant_map_ro)   \
> -                      | p2m_to_mask(p2m_ram_shared) )
> +                      | p2m_to_mask(p2m_ram_shared)   \
> +                      | p2m_to_mask(p2m_mmio_write_dm))

Nit: please align the '\' with the others above 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 Dec 04 16:05:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwYto-0006gj-7R; Thu, 04 Dec 2014 16:05:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwYtm-0006ge-AB
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:04:58 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	07/5D-25547-92680845; Thu, 04 Dec 2014 16:04:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417709096!11071989!1
X-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 4071 invoked from network); 4 Dec 2014 16:04:57 -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; 4 Dec 2014 16:04:57 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:04:56 +0000
Message-Id: <54809437020000780004CD43@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:04:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-9-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-9-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 08/17] hvmloader/mmio: reconcile guest
 mmio with reserved device 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 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> We need to make sure all mmio allocation don't overlap
> any rdm, reserved device memory. Here we just skip
> all reserved device memory range in mmio space.

I think someone else already suggested that this and patch 9 should
be swapped, and the BAR allocation be changed to use the E820
map as input. That may end up being a bigger change, but will yield
ultimately better (and namely better maintainable) code.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:11:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZ0C-0006zT-EI; Thu, 04 Dec 2014 16:11:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwZ0A-0006zO-UR
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:11:35 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AF/DC-25276-6B780845; Thu, 04 Dec 2014 16:11:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417709493!13448233!1
X-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 25647 invoked from network); 4 Dec 2014 16:11:33 -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 Dec 2014 16:11:33 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:11:33 +0000
Message-Id: <548095C4020000780004CD59@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:11:32 +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>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
	<54806FA2.6080406@citrix.com>
	<548083EE020000780004CC90@mail.emea.novell.com>
	<548081D6.4080208@citrix.com>
In-Reply-To: <548081D6.4080208@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-develList <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 04.12.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
> On 04/12/14 14:55, Jan Beulich wrote:
>>>>> On 04.12.14 at 15:28, <andrew.cooper3@citrix.com> wrote:
>>> On 04/12/14 13:49, Jan Beulich wrote:
>>>>>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>>>>> 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.
>>>> With no-one else voicing an opinion:
>>>>
>>>> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
>>>>
>>>> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
>>>>
>>>> For the latter, we're fine even without further consideration. For the
>>>> former, the two operations actively using the continuation encoding
>>>> are tools-only ones. Since we're fine to alter the tools only interfaces,
>>>> and since it was intended for the tools-only HVM-ops to be split off
>>>> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
>>>> would then no longer be a problem. Plus, in the worst case we could
>>>> always introduce yet another hypercall if we ran out of numbers.
>>> Are you suggesting that we make a new hvmctl now and remove the hvmop
>>> mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
>>> subsequently remove it even if all continuable hypercalls move to a
>>> separate hypercall.
>> Why? We certainly don't guarantee compatibility for undefined
>> hypercalls to behave in a certain way.
> 
> A task is in the middle of a hypercall continuation.  The VM is migrated
> to a newer Xen which has lost the op mask and gained a new hypercall
> which would alias.

Impossible: A continuation could be in progress only when we
actually use the high bits (or else you have nowhere to encode
it). Operations not using continuations consequently aren't
susceptible to the mask disappearing.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:11:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZ0C-0006zT-EI; Thu, 04 Dec 2014 16:11:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwZ0A-0006zO-UR
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:11:35 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AF/DC-25276-6B780845; Thu, 04 Dec 2014 16:11:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417709493!13448233!1
X-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 25647 invoked from network); 4 Dec 2014 16:11:33 -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 Dec 2014 16:11:33 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:11:33 +0000
Message-Id: <548095C4020000780004CD59@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:11:32 +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>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
	<54806FA2.6080406@citrix.com>
	<548083EE020000780004CC90@mail.emea.novell.com>
	<548081D6.4080208@citrix.com>
In-Reply-To: <548081D6.4080208@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-develList <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 04.12.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
> On 04/12/14 14:55, Jan Beulich wrote:
>>>>> On 04.12.14 at 15:28, <andrew.cooper3@citrix.com> wrote:
>>> On 04/12/14 13:49, Jan Beulich wrote:
>>>>>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>>>>> 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.
>>>> With no-one else voicing an opinion:
>>>>
>>>> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
>>>>
>>>> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
>>>>
>>>> For the latter, we're fine even without further consideration. For the
>>>> former, the two operations actively using the continuation encoding
>>>> are tools-only ones. Since we're fine to alter the tools only interfaces,
>>>> and since it was intended for the tools-only HVM-ops to be split off
>>>> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
>>>> would then no longer be a problem. Plus, in the worst case we could
>>>> always introduce yet another hypercall if we ran out of numbers.
>>> Are you suggesting that we make a new hvmctl now and remove the hvmop
>>> mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
>>> subsequently remove it even if all continuable hypercalls move to a
>>> separate hypercall.
>> Why? We certainly don't guarantee compatibility for undefined
>> hypercalls to behave in a certain way.
> 
> A task is in the middle of a hypercall continuation.  The VM is migrated
> to a newer Xen which has lost the op mask and gained a new hypercall
> which would alias.

Impossible: A continuation could be in progress only when we
actually use the high bits (or else you have nowhere to encode
it). Operations not using continuations consequently aren't
susceptible to the mask disappearing.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:20:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:20:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZ8T-0007b7-GV; Thu, 04 Dec 2014 16:20: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 1XwZ8R-0007az-Hk
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:20:07 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	D4/B7-23865-6B980845; Thu, 04 Dec 2014 16:20:06 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417710004!11059060!1
X-Originating-IP: [66.165.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 29032 invoked from network); 4 Dec 2014 16:20:05 -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;
	4 Dec 2014 16:20:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="199802171"
Received: from ukmail1.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, 4 Dec 2014 11:18:02 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XwYqT-0007uX-Qt;
	Thu, 04 Dec 2014 16:01:33 +0000
Date: Thu, 4 Dec 2014 16:01:33 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141204160133.GA31446@zion.uk.xensource.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-9-git-send-email-vkuznets@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417626981-8432-9-git-send-email-vkuznets@redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 8/9] libxl: soft reset support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 skipped the internal implementation since I don't know what's
 required to fulfil soft reset.)

On Wed, Dec 03, 2014 at 06:16:20PM +0100, Vitaly Kuznetsov wrote:
[...]
> +                                         libxl__domain_create_state *dcs);
>  
>  /* Each time the dm needs to be saved, we must call suspend and then save */
>  _hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 53611dc..eb833f0 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2043,7 +2043,8 @@ static void reload_domain_config(uint32_t domid,
>  }
>  
>  /* Returns 1 if domain should be restarted,
> - * 2 if domain should be renamed then restarted, or 0
> + * 2 if domain should be renamed then restarted,
> + * 3 if domain performed soft reset, or 0
>   * Can update r_domid if domain is destroyed etc */
>  static int handle_domain_death(uint32_t *r_domid,
>                                 libxl_event *event,
> @@ -2069,6 +2070,9 @@ static int handle_domain_death(uint32_t *r_domid,
>      case LIBXL_SHUTDOWN_REASON_WATCHDOG:
>          action = d_config->on_watchdog;
>          break;
> +    case LIBXL_SHUTDOWN_REASON_SOFT_RESET:
> +        LOG("Domain performed soft reset.");
> +        return 3;

Would it be useful to provide "on_soft_reset" option in xl? Will the
admin be interested in performing some other action when domain does
soft reset? Say, for security reason admin want to prohibit domain from
soft resetting itself.

>      default:
>          LOG("Unknown shutdown reason code %d. Destroying domain.",
>              event->u.domain_shutdown.shutdown_reason);
> @@ -2285,6 +2289,7 @@ static void evdisable_disk_ejects(libxl_evgen_disk_eject **diskws,
>  static uint32_t create_domain(struct domain_create *dom_info)
>  {
>      uint32_t domid = INVALID_DOMID;
> +    uint32_t domid_old = INVALID_DOMID;
>  
>      libxl_domain_config d_config;
>  
> @@ -2510,7 +2515,18 @@ start:
>           * restore/migrate-receive it again.
>           */
>          restoring = 0;
> -    }else{
> +    } else if (domid_old != INVALID_DOMID) {
> +        /* Do soft reset */
> +        d_config.b_info.nodemap.size = 0;

What's the reason for doing this?

If you encounter problem with this it should probably be fixed in libxl.

Wei.

> +        ret = libxl_domain_soft_reset(ctx, &d_config,
> +                                      &domid, domid_old,
> +                                      0, 0);
> +
> +        if ( ret ) {
> +            goto error_out;
> +        }
> +        domid_old = INVALID_DOMID;
> +    } else {
>          ret = libxl_domain_create_new(ctx, &d_config, &domid,
>                                        0, autoconnect_console_how);
>      }
> @@ -2574,6 +2590,8 @@ start:
>                  event->u.domain_shutdown.shutdown_reason,
>                  event->u.domain_shutdown.shutdown_reason);
>              switch (handle_domain_death(&domid, event, &d_config)) {
> +            case 3:
> +                domid_old = domid;
>              case 2:
>                  if (!preserve_domain(&domid, event, &d_config)) {
>                      /* If we fail then exit leaving the old domain in place. */
> -- 
> 1.9.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:20:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:20:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZ8V-0007bL-SN; Thu, 04 Dec 2014 16:20:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwZ8U-0007bE-IB
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:20:10 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	35/9B-27584-9B980845; Thu, 04 Dec 2014 16:20:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417710005!6303484!1
X-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 8628 invoked from network); 4 Dec 2014 16:20:05 -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; 4 Dec 2014 16:20:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:20:04 +0000
Message-Id: <548097C5020000780004CD72@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:20:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-10-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 09/17] 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 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> We need to check to reserve all reserved device memory maps in e820
> to avoid any potential guest memory conflict.
> 
> Currently, if we can't insert RDM entries directly, we may need to handle
> several ranges as follows:
> a. Fixed Ranges --> BUG()
>  lowmem_reserved_base-0xA0000: reserved by BIOS implementation,
>  BIOS region,
>  RESERVED_MEMBASE ~ 0x100000000,
> b. RAM or RAM:Hole -> Try to reserve

I continue to be unconvinced of the overall approach: The domain
builder continues to populate these regions when it shouldn't. Yet
once it doesn't, it would be most natural to simply communicate the
RAM regions to hvmloader, and hvmloader would use just that to
build the E820 table (and subsequently assign BARs).

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:20:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:20:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZ8V-0007bL-SN; Thu, 04 Dec 2014 16:20:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwZ8U-0007bE-IB
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:20:10 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	35/9B-27584-9B980845; Thu, 04 Dec 2014 16:20:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417710005!6303484!1
X-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 8628 invoked from network); 4 Dec 2014 16:20:05 -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; 4 Dec 2014 16:20:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:20:04 +0000
Message-Id: <548097C5020000780004CD72@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:20:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-10-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 09/17] 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 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> We need to check to reserve all reserved device memory maps in e820
> to avoid any potential guest memory conflict.
> 
> Currently, if we can't insert RDM entries directly, we may need to handle
> several ranges as follows:
> a. Fixed Ranges --> BUG()
>  lowmem_reserved_base-0xA0000: reserved by BIOS implementation,
>  BIOS region,
>  RESERVED_MEMBASE ~ 0x100000000,
> b. RAM or RAM:Hole -> Try to reserve

I continue to be unconvinced of the overall approach: The domain
builder continues to populate these regions when it shouldn't. Yet
once it doesn't, it would be most natural to simply communicate the
RAM regions to hvmloader, and hvmloader would use just that to
build the E820 table (and subsequently assign BARs).

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:20:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:20:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZ8T-0007b7-GV; Thu, 04 Dec 2014 16:20: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 1XwZ8R-0007az-Hk
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:20:07 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	D4/B7-23865-6B980845; Thu, 04 Dec 2014 16:20:06 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417710004!11059060!1
X-Originating-IP: [66.165.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 29032 invoked from network); 4 Dec 2014 16:20:05 -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;
	4 Dec 2014 16:20:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="199802171"
Received: from ukmail1.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, 4 Dec 2014 11:18:02 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XwYqT-0007uX-Qt;
	Thu, 04 Dec 2014 16:01:33 +0000
Date: Thu, 4 Dec 2014 16:01:33 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141204160133.GA31446@zion.uk.xensource.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-9-git-send-email-vkuznets@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417626981-8432-9-git-send-email-vkuznets@redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 8/9] libxl: soft reset support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 skipped the internal implementation since I don't know what's
 required to fulfil soft reset.)

On Wed, Dec 03, 2014 at 06:16:20PM +0100, Vitaly Kuznetsov wrote:
[...]
> +                                         libxl__domain_create_state *dcs);
>  
>  /* Each time the dm needs to be saved, we must call suspend and then save */
>  _hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 53611dc..eb833f0 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2043,7 +2043,8 @@ static void reload_domain_config(uint32_t domid,
>  }
>  
>  /* Returns 1 if domain should be restarted,
> - * 2 if domain should be renamed then restarted, or 0
> + * 2 if domain should be renamed then restarted,
> + * 3 if domain performed soft reset, or 0
>   * Can update r_domid if domain is destroyed etc */
>  static int handle_domain_death(uint32_t *r_domid,
>                                 libxl_event *event,
> @@ -2069,6 +2070,9 @@ static int handle_domain_death(uint32_t *r_domid,
>      case LIBXL_SHUTDOWN_REASON_WATCHDOG:
>          action = d_config->on_watchdog;
>          break;
> +    case LIBXL_SHUTDOWN_REASON_SOFT_RESET:
> +        LOG("Domain performed soft reset.");
> +        return 3;

Would it be useful to provide "on_soft_reset" option in xl? Will the
admin be interested in performing some other action when domain does
soft reset? Say, for security reason admin want to prohibit domain from
soft resetting itself.

>      default:
>          LOG("Unknown shutdown reason code %d. Destroying domain.",
>              event->u.domain_shutdown.shutdown_reason);
> @@ -2285,6 +2289,7 @@ static void evdisable_disk_ejects(libxl_evgen_disk_eject **diskws,
>  static uint32_t create_domain(struct domain_create *dom_info)
>  {
>      uint32_t domid = INVALID_DOMID;
> +    uint32_t domid_old = INVALID_DOMID;
>  
>      libxl_domain_config d_config;
>  
> @@ -2510,7 +2515,18 @@ start:
>           * restore/migrate-receive it again.
>           */
>          restoring = 0;
> -    }else{
> +    } else if (domid_old != INVALID_DOMID) {
> +        /* Do soft reset */
> +        d_config.b_info.nodemap.size = 0;

What's the reason for doing this?

If you encounter problem with this it should probably be fixed in libxl.

Wei.

> +        ret = libxl_domain_soft_reset(ctx, &d_config,
> +                                      &domid, domid_old,
> +                                      0, 0);
> +
> +        if ( ret ) {
> +            goto error_out;
> +        }
> +        domid_old = INVALID_DOMID;
> +    } else {
>          ret = libxl_domain_create_new(ctx, &d_config, &domid,
>                                        0, autoconnect_console_how);
>      }
> @@ -2574,6 +2590,8 @@ start:
>                  event->u.domain_shutdown.shutdown_reason,
>                  event->u.domain_shutdown.shutdown_reason);
>              switch (handle_domain_death(&domid, event, &d_config)) {
> +            case 3:
> +                domid_old = domid;
>              case 2:
>                  if (!preserve_domain(&domid, event, &d_config)) {
>                      /* If we fail then exit leaving the old domain in place. */
> -- 
> 1.9.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:23:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZB7-0007r6-Jb; Thu, 04 Dec 2014 16:22: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 1XwZB6-0007r1-C6
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:22:52 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	26/7D-26858-B5A80845; Thu, 04 Dec 2014 16:22:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417710169!11077305!1
X-Originating-IP: [66.165.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 22592 invoked from network); 4 Dec 2014 16:22:51 -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;
	4 Dec 2014 16:22:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="199803518"
Received: from ukmail1.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, 4 Dec 2014 11: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 1XwZ8V-00008q-Hh;
	Thu, 04 Dec 2014 16:20:11 +0000
Date: Thu, 4 Dec 2014 16:20:11 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141204162011.GB31446@zion.uk.xensource.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-7-git-send-email-vkuznets@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417626981-8432-7-git-send-email-vkuznets@redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 6/9] libxl: add
	libxl__domain_soft_reset_destroy_old()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 06:16:18PM +0100, Vitaly Kuznetsov wrote:
> New libxl__domain_soft_reset_destroy_old() is an internal-only
> version of libxl_domain_destroy() which follows the same domain
> destroy path with the only difference: xc_domain_destroy() is
> being avoided so the domain is not actually being destroyed.
> 
> Add soft_reset flag to libxl__domain_destroy_state structure
> to support the change.
> 
> The original libxl_domain_destroy() function could be easily
> modified to support new flag but I'm trying to avoid that as
> it is part of public API.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
>  tools/libxl/libxl.c          | 32 +++++++++++++++++++++++++++-----
>  tools/libxl/libxl_internal.h |  4 ++++
>  2 files changed, 31 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f84f7c2..c2bd730 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1437,6 +1437,23 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
>      return AO_INPROGRESS;
>  }
>  
> +int libxl__domain_soft_reset_destroy_old(libxl_ctx *ctx, uint32_t domid,
> +                                         const libxl_asyncop_how *ao_how)
> +{

Internal function takes gc, not ctx.

> +    AO_CREATE(ctx, domid, ao_how);

If you want to use libxl context, use CTX macro.

> +    libxl__domain_destroy_state *dds;
> +
> +    GCNEW(dds);
> +    dds->ao = ao;
> +    dds->domid = domid;
> +    dds->callback = domain_destroy_cb;
> +    dds->soft_reset = 1;
> +    libxl__domain_destroy(egc, dds);
> +
> +    return AO_INPROGRESS;
> +}
> +
> +
>  static void domain_destroy_cb(libxl__egc *egc, libxl__domain_destroy_state *dds,
>                                int rc)
>  {
> @@ -1612,6 +1629,7 @@ static void devices_destroy_cb(libxl__egc *egc,
>  {
>      STATE_AO_GC(drs->ao);
>      libxl__destroy_domid_state *dis = CONTAINER_OF(drs, *dis, drs);
> +    libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, domain);
>      libxl_ctx *ctx = CTX;
>      uint32_t domid = dis->domid;
>      char *dom_path;
> @@ -1650,11 +1668,15 @@ static void devices_destroy_cb(libxl__egc *egc,
>      }
>      libxl__userdata_destroyall(gc, domid);
>  
> -    rc = xc_domain_destroy(ctx->xch, domid);
> -    if (rc < 0) {
> -        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_destroy failed for %d", domid);
> -        rc = ERROR_FAIL;
> -        goto out;
> +    if (!dds->soft_reset)
> +    {

Coding style.

Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:23:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZB7-0007r6-Jb; Thu, 04 Dec 2014 16:22: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 1XwZB6-0007r1-C6
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:22:52 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	26/7D-26858-B5A80845; Thu, 04 Dec 2014 16:22:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417710169!11077305!1
X-Originating-IP: [66.165.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 22592 invoked from network); 4 Dec 2014 16:22:51 -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;
	4 Dec 2014 16:22:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="199803518"
Received: from ukmail1.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, 4 Dec 2014 11: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 1XwZ8V-00008q-Hh;
	Thu, 04 Dec 2014 16:20:11 +0000
Date: Thu, 4 Dec 2014 16:20:11 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141204162011.GB31446@zion.uk.xensource.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-7-git-send-email-vkuznets@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417626981-8432-7-git-send-email-vkuznets@redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 6/9] libxl: add
	libxl__domain_soft_reset_destroy_old()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 03, 2014 at 06:16:18PM +0100, Vitaly Kuznetsov wrote:
> New libxl__domain_soft_reset_destroy_old() is an internal-only
> version of libxl_domain_destroy() which follows the same domain
> destroy path with the only difference: xc_domain_destroy() is
> being avoided so the domain is not actually being destroyed.
> 
> Add soft_reset flag to libxl__domain_destroy_state structure
> to support the change.
> 
> The original libxl_domain_destroy() function could be easily
> modified to support new flag but I'm trying to avoid that as
> it is part of public API.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
>  tools/libxl/libxl.c          | 32 +++++++++++++++++++++++++++-----
>  tools/libxl/libxl_internal.h |  4 ++++
>  2 files changed, 31 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f84f7c2..c2bd730 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1437,6 +1437,23 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
>      return AO_INPROGRESS;
>  }
>  
> +int libxl__domain_soft_reset_destroy_old(libxl_ctx *ctx, uint32_t domid,
> +                                         const libxl_asyncop_how *ao_how)
> +{

Internal function takes gc, not ctx.

> +    AO_CREATE(ctx, domid, ao_how);

If you want to use libxl context, use CTX macro.

> +    libxl__domain_destroy_state *dds;
> +
> +    GCNEW(dds);
> +    dds->ao = ao;
> +    dds->domid = domid;
> +    dds->callback = domain_destroy_cb;
> +    dds->soft_reset = 1;
> +    libxl__domain_destroy(egc, dds);
> +
> +    return AO_INPROGRESS;
> +}
> +
> +
>  static void domain_destroy_cb(libxl__egc *egc, libxl__domain_destroy_state *dds,
>                                int rc)
>  {
> @@ -1612,6 +1629,7 @@ static void devices_destroy_cb(libxl__egc *egc,
>  {
>      STATE_AO_GC(drs->ao);
>      libxl__destroy_domid_state *dis = CONTAINER_OF(drs, *dis, drs);
> +    libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, domain);
>      libxl_ctx *ctx = CTX;
>      uint32_t domid = dis->domid;
>      char *dom_path;
> @@ -1650,11 +1668,15 @@ static void devices_destroy_cb(libxl__egc *egc,
>      }
>      libxl__userdata_destroyall(gc, domid);
>  
> -    rc = xc_domain_destroy(ctx->xch, domid);
> -    if (rc < 0) {
> -        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_destroy failed for %d", domid);
> -        rc = ERROR_FAIL;
> -        goto out;
> +    if (!dds->soft_reset)
> +    {

Coding style.

Wei.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:24:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:24:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZCl-0008Ad-2b; Thu, 04 Dec 2014 16:24: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 1XwZCj-0008AS-SK
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:24:33 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	5D/A4-02699-1CA80845; Thu, 04 Dec 2014 16:24:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417710270!13032748!1
X-Originating-IP: [156.151.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 11623 invoked from network); 4 Dec 2014 16:24:32 -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; 4 Dec 2014 16:24:32 -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 sB4GOOWX002581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 16:24:25 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
	sB4GOOXS006501
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 4 Dec 2014 16:24:24 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
	sB4GONFE009001; Thu, 4 Dec 2014 16:24:23 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, 04 Dec 2014 08:24:23 -0800
Message-ID: <54808B20.9080503@oracle.com>
Date: Thu, 04 Dec 2014 11:26: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: Dario Faggioli <dario.faggioli@citrix.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>	
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<1417694153.31647.32.camel@Abyss.station>
In-Reply-To: <1417694153.31647.32.camel@Abyss.station>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, jbeulich@suse.com, keir@xen.org,
	ufimtseva@gmail.com
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 12/04/2014 06:55 AM, Dario Faggioli wrote:
> On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
>> Make XEN_SYSCTL_topologyinfo more generic so that it can return both
>> CPU and IO topology (support for returning the latter is added in the
>> subsequent patch)
>>
> Is it always the case that we need the full information (i.e., both CPU
> and IO topology), at all levels above Xen?
>
> I appreciate the performance implications (one hcall instead of two) in
> cases where we do, but I still think, as Andrew suggested, that having a
> new XEN_SYSCTL_iotopology (or something like that) and leaving
> *_topologyinfo alone would make a better low-level interface.
>
> All IMHO, of course.

I don't feel strongly either way so I can go that route (and it will 
make patch 4 completely unnecessary).

(I am not sure though I understood Andrew's reasoning for splitting into 
two sysctls.

>> To do so move (and rename) previously used cpu_to_core/cpu_to_socket/
>> cpu_to_node into struct xen_sysctl_cputopo and move it, together with
>> newly added struct xen_sysctl_iotopo, to xen_sysctl_topologyinfo.
>>
>> Add libxl_get_topology() to handle new interface and modify
>> libxl_get_cpu_topology() to be a wrapper around it.
>>
> This is, I think, useful, and I'd go for it, even if we adding a new
> hypercall at the Xen and xc level.
>
> Of course, it would work the other way round: the new libxl function
> would wrap the existing libxl_get_cpu_topology() and a new libxl call
> (something like libxl_get_io_topology() ?).
>
>> Adjust xenpm and python's low-level C libraries for new interface.
>>
> All in one patch? Wouldn't splitting it at least in two (hypervisor and
> tools parts) be better? If it were me, I'd probably split even more...

I could not split it because this patch changes sysctl interface (more 
specifically, xen_sysctl_topologyinfo_t/xc_topologyinfo_t) so anyone who 
uses this struct needed to be updated at the same time.

Of course, if I were to leave current interface intact and add another 
sysctl for IO topology then this will not be necessary

>
>> This change requires bumping XEN_SYSCTL_INTERFACE_VERSION
>>
> Which would not be the case if we take the approach of adding a new,
> iotopology specific, hcall, would it?

I would think that any changes to a public interface, including adding a 
new function, require new version.

(And if we get a new version, even if we split topology into CPU and IO 
sysctls, I'd still like to put cpu_to_[core|socket||node] into a single 
structure).

Thanks.
-boris

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:24:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:24:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZCl-0008Ad-2b; Thu, 04 Dec 2014 16:24: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 1XwZCj-0008AS-SK
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:24:33 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	5D/A4-02699-1CA80845; Thu, 04 Dec 2014 16:24:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417710270!13032748!1
X-Originating-IP: [156.151.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 11623 invoked from network); 4 Dec 2014 16:24:32 -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; 4 Dec 2014 16:24:32 -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 sB4GOOWX002581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 16:24:25 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
	sB4GOOXS006501
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 4 Dec 2014 16:24:24 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
	sB4GONFE009001; Thu, 4 Dec 2014 16:24:23 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, 04 Dec 2014 08:24:23 -0800
Message-ID: <54808B20.9080503@oracle.com>
Date: Thu, 04 Dec 2014 11:26: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: Dario Faggioli <dario.faggioli@citrix.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>	
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<1417694153.31647.32.camel@Abyss.station>
In-Reply-To: <1417694153.31647.32.camel@Abyss.station>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, jbeulich@suse.com, keir@xen.org,
	ufimtseva@gmail.com
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 12/04/2014 06:55 AM, Dario Faggioli wrote:
> On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
>> Make XEN_SYSCTL_topologyinfo more generic so that it can return both
>> CPU and IO topology (support for returning the latter is added in the
>> subsequent patch)
>>
> Is it always the case that we need the full information (i.e., both CPU
> and IO topology), at all levels above Xen?
>
> I appreciate the performance implications (one hcall instead of two) in
> cases where we do, but I still think, as Andrew suggested, that having a
> new XEN_SYSCTL_iotopology (or something like that) and leaving
> *_topologyinfo alone would make a better low-level interface.
>
> All IMHO, of course.

I don't feel strongly either way so I can go that route (and it will 
make patch 4 completely unnecessary).

(I am not sure though I understood Andrew's reasoning for splitting into 
two sysctls.

>> To do so move (and rename) previously used cpu_to_core/cpu_to_socket/
>> cpu_to_node into struct xen_sysctl_cputopo and move it, together with
>> newly added struct xen_sysctl_iotopo, to xen_sysctl_topologyinfo.
>>
>> Add libxl_get_topology() to handle new interface and modify
>> libxl_get_cpu_topology() to be a wrapper around it.
>>
> This is, I think, useful, and I'd go for it, even if we adding a new
> hypercall at the Xen and xc level.
>
> Of course, it would work the other way round: the new libxl function
> would wrap the existing libxl_get_cpu_topology() and a new libxl call
> (something like libxl_get_io_topology() ?).
>
>> Adjust xenpm and python's low-level C libraries for new interface.
>>
> All in one patch? Wouldn't splitting it at least in two (hypervisor and
> tools parts) be better? If it were me, I'd probably split even more...

I could not split it because this patch changes sysctl interface (more 
specifically, xen_sysctl_topologyinfo_t/xc_topologyinfo_t) so anyone who 
uses this struct needed to be updated at the same time.

Of course, if I were to leave current interface intact and add another 
sysctl for IO topology then this will not be necessary

>
>> This change requires bumping XEN_SYSCTL_INTERFACE_VERSION
>>
> Which would not be the case if we take the approach of adding a new,
> iotopology specific, hcall, would it?

I would think that any changes to a public interface, including adding a 
new function, require new version.

(And if we get a new version, even if we split topology into CPU and IO 
sysctls, I'd still like to put cpu_to_[core|socket||node] into a single 
structure).

Thanks.
-boris

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:26:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZEE-0008JK-IO; Thu, 04 Dec 2014 16:26: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 1XwZEC-0008J5-D9
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:26:04 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	30/0D-03148-B1B80845; Thu, 04 Dec 2014 16:26:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417710362!8401534!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6294 invoked from network); 4 Dec 2014 16:26:02 -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; 4 Dec 2014 16:26:02 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:53091 helo=w510-wired)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XwZBE-0007Rk-TW; Thu, 04 Dec 2014 17:23:00 +0100
Date: Thu, 4 Dec 2014 17:25:58 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <779770151.20141204172558@eikelenboom.it>
To: Alex Williamson <alex.williamson@redhat.com>
In-Reply-To: <1417707546.15750.100.camel@bling.home>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
	<1417707546.15750.100.camel@bling.home>
MIME-Version: 1.0
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, bhelgaas@google.com,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
	slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 4, 2014, 4:39:06 PM, you wrote:

> On Thu, 2014-12-04 at 15:50 +0100, Sander Eikelenboom wrote:
>> Thursday, December 4, 2014, 3:31:11 PM, you wrote:
>> 
>> > On 04/12/14 14:09, Sander Eikelenboom wrote:
>> >> 
>> >> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
>> >> 
>> >>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>> >>>>
>> >>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>> >>>>
>> >>>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>> >>>>>>
>> >>>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>> >>>>>>>
>> >>>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>> >>>>>>>>
>> >>>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
>> >>>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>> >>>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>> >>>>>>>> It bypasses the need to worry about the PCI lock. 
>> >>>>>>>
>> >>>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>> >>>>>>> proposed). 
>> >>>>>>>
>> >>>>>>
>> >>>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
>> >>>>
>> >>>>> It is only needed if the core won't provide one.
>> >>>>
>> >>>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
>> >>>>> +{
>> >>>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
>> >>>>> +       struct device *dev = &pci->dev;
>> >>>>> +       int ret;
>> >>>>> +
>> >>>>> +       /* Already have a per-function reset? */
>> >>>>> +       if (pci_probe_reset_function(pci) == 0)
>> >>>>> +               return 0;
>> >>>>> +
>> >>>>> +       ret = device_create_file(dev, &dev_attr_reset);
>> >>>>> +       if (ret < 0)
>> >>>>> +               return ret;
>> >>>> +       dev_data->>created_reset_file = true;
>> >>>>> +       return 0;
>> >>>>> +}
>> >>>>
>> >>>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
>> >>>> "pci.c:__pci_dev_reset" ?
>> >>>>
>> >>>> The problem with that function is that from my testing it seems that the 
>> >>>> first option "pci_dev_specific_reset" always seems to return succes, so all the
>> >>>> other options are skipped (flr, pm, slot, bus). However the device it self is 
>> >>>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
>> >>>> none virtualization purposes and it's probably the least intrusive. For 
>> >>>> virtualization however it would be nice to be sure it resets properly, or have a 
>> >>>> way to force a specific reset routine.)
>> >> 
>> >>> Then you need work with the maintainer for those specific devices or
>> >>> drivers to fix their specific reset function.
>> >> 
>> >>> I'm not adding stuff to pciback to workaround broken quirks.
>> >> 
>> >> OK that's a pretty clear message there, so if one wants to use pci and vga
>> >> passthrough one should better use KVM and vfio-pci.
>> 
>> > Have you (or anyone else) ever raised the problem with the broken reset
>> > quirk for certain devices with the relevant maintainer?
>> 
>> >> vfio-pci has:
>> >> - logic to do the try-slot-bus-reset logic
>> 
>> > Just because vfio-pci fixed it incorrectly doesn't mean pciback has to
>> > as well.
>> 
>> Depends on what you call an "incorrect fix" .. it fixes a quirk .. 
>> you can say that's incorrect, but then you would have to remove 50% of
>> the kernel and Xen code as well.
>> 
>> (i do in general agree it's better to strive for a generic solution though,
>> that's exactly why i brought up that that function doesn't seem to work perfect
>> for virtualization purposes) 
>> 
>> > It makes no sense for both pciback and vfio-pci to workaround problems
>> > with pci_function_reset() in different ways -- it should be fixed in the
>> > core PCI code so both can benefit and make use of the same code.
>> 
>> Well perhaps Bjorn knows why the order of resets and skipping the rest as
>> implemented in "pci.c:__pci_dev_reset" was implemented in that way ?
>> 
>> Especially what is the expectation about pci_dev_specific_reset doing a proper 
>> reset for say a vga-card:
>> - i know it doesn't work on a radeon card (doesn't blank screen, on next guest 
>>   boot reports it's already posted, powermanagement doesn't work).
>> - while with a slot/bus reset, that all just works fine, screen blanks 
>>   immediately and everything else also works.
>> 
>> Added Alex as well since he added this workaround for KVM/vfio-pci, perhaps he knows why
>> he introduced the workaround in vfio-pci instead of trying to fix it in core pci 
>> code ?

> I don't know what workaround you're talking about.  As devices are
> released from the user, vfio-pci attempts to reset them.  If
> pci_reset_function() returns success we mark the device clean, otherwise
> it gets marked dirty.  Each time a device is released, if there are
> dirty devices we test whether we can try a bus/slot reset to clean them.
> In the case of assigning a GPU this typically means that the GPU or
> audio function come through first, there's no reset mechanism so it gets
> marked dirty, the next device comes through and we manage to try a bus
> reset.  vfio-pci does not have any device specific resets, all
> functionality is added to the PCI-core, thank-you-very-much.  I even
> posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
> bad so that pci_reset_function() won't claim that worked.  All VGA
> access quirks are done in QEMU, the kernel doesn't have any business in
> remapping config space over MMIO regions or trapping other config space
> backdoors.

Thanks for your insightful reply!

With "workaround" I was trying to refer to "vfio_pci_try_bus_reset()" which
implements how to reset the devices, it indeed uses function you introduced in
pci core code (with a solution for locking issues Konrad also seems to have 
ran into: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=61cf16d8bd38c3dc52033ea75d5b1f8368514a17

David seems to be arguing the whole "vfio_pci_try_bus_reset()" should be not 
needed and just doing calling "pci_reset_function()" (directly or by
echo "1" > /sys/bus/pci/devices/BDF/reset shoud always magically do the
right thing. 
(Which in my opinion seems the contradict with the mere existence
of "vfio_pci_try_bus_reset()" (i don't think you would have implemented it 
when you would have deemed it unnecessary)) 

> I have never heard of problems with the dev specific reset claiming to
> work and not doing anything, there are only a few of these, it should be
> easy to debug.

> I didn't read the original patch, but the title alone of this patch is
> quite confusing.  FLR is specifically a function-level-reset, so one
> would expect 'do_flr' to be function specific.  The pci-sysfs 'reset'
> attribute is already function specific.  If pci_reset_function() isn't
> doing the job and we need to use bus/slot reset, it's clearly not an
> FLR.  Thanks,
> Alex

The name "do_flr" is coming from the Xen xl toolstack which historically has 
code that tries to reset devices using a echo "BDF" > /sys/bus/pci/drivers/pciback/do_flr

But the name "do_flr" and the debug messages indeed are incorrect (it's not 
doing a flr nor a D3/PM reset), confusing and should not be used.

And as you seem to have solved the locking issue for vfio-pci, it is probably 
possible for xen-pciback to do the same. Instead of letting xen-pciback
work around the locking problem by deferring to the xl toolstack the resetting
logic could be kept into xen-pciback it self. 
That would also mean that the sysfs attribute would be unnecessary and make 
the naming issue moot.

--
Sander



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:26:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZEE-0008JK-IO; Thu, 04 Dec 2014 16:26: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 1XwZEC-0008J5-D9
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:26:04 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	30/0D-03148-B1B80845; Thu, 04 Dec 2014 16:26:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417710362!8401534!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6294 invoked from network); 4 Dec 2014 16:26:02 -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; 4 Dec 2014 16:26:02 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:53091 helo=w510-wired)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1XwZBE-0007Rk-TW; Thu, 04 Dec 2014 17:23:00 +0100
Date: Thu, 4 Dec 2014 17:25:58 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <779770151.20141204172558@eikelenboom.it>
To: Alex Williamson <alex.williamson@redhat.com>
In-Reply-To: <1417707546.15750.100.camel@bling.home>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
	<1417707546.15750.100.camel@bling.home>
MIME-Version: 1.0
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, bhelgaas@google.com,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
	slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 4, 2014, 4:39:06 PM, you wrote:

> On Thu, 2014-12-04 at 15:50 +0100, Sander Eikelenboom wrote:
>> Thursday, December 4, 2014, 3:31:11 PM, you wrote:
>> 
>> > On 04/12/14 14:09, Sander Eikelenboom wrote:
>> >> 
>> >> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
>> >> 
>> >>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>> >>>>
>> >>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>> >>>>
>> >>>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>> >>>>>>
>> >>>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>> >>>>>>>
>> >>>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
>> >>>>>>>>
>> >>>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
>> >>>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
>> >>>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
>> >>>>>>>> It bypasses the need to worry about the PCI lock. 
>> >>>>>>>
>> >>>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
>> >>>>>>> proposed). 
>> >>>>>>>
>> >>>>>>
>> >>>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
>> >>>>
>> >>>>> It is only needed if the core won't provide one.
>> >>>>
>> >>>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
>> >>>>> +{
>> >>>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
>> >>>>> +       struct device *dev = &pci->dev;
>> >>>>> +       int ret;
>> >>>>> +
>> >>>>> +       /* Already have a per-function reset? */
>> >>>>> +       if (pci_probe_reset_function(pci) == 0)
>> >>>>> +               return 0;
>> >>>>> +
>> >>>>> +       ret = device_create_file(dev, &dev_attr_reset);
>> >>>>> +       if (ret < 0)
>> >>>>> +               return ret;
>> >>>> +       dev_data->>created_reset_file = true;
>> >>>>> +       return 0;
>> >>>>> +}
>> >>>>
>> >>>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
>> >>>> "pci.c:__pci_dev_reset" ?
>> >>>>
>> >>>> The problem with that function is that from my testing it seems that the 
>> >>>> first option "pci_dev_specific_reset" always seems to return succes, so all the
>> >>>> other options are skipped (flr, pm, slot, bus). However the device it self is 
>> >>>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
>> >>>> none virtualization purposes and it's probably the least intrusive. For 
>> >>>> virtualization however it would be nice to be sure it resets properly, or have a 
>> >>>> way to force a specific reset routine.)
>> >> 
>> >>> Then you need work with the maintainer for those specific devices or
>> >>> drivers to fix their specific reset function.
>> >> 
>> >>> I'm not adding stuff to pciback to workaround broken quirks.
>> >> 
>> >> OK that's a pretty clear message there, so if one wants to use pci and vga
>> >> passthrough one should better use KVM and vfio-pci.
>> 
>> > Have you (or anyone else) ever raised the problem with the broken reset
>> > quirk for certain devices with the relevant maintainer?
>> 
>> >> vfio-pci has:
>> >> - logic to do the try-slot-bus-reset logic
>> 
>> > Just because vfio-pci fixed it incorrectly doesn't mean pciback has to
>> > as well.
>> 
>> Depends on what you call an "incorrect fix" .. it fixes a quirk .. 
>> you can say that's incorrect, but then you would have to remove 50% of
>> the kernel and Xen code as well.
>> 
>> (i do in general agree it's better to strive for a generic solution though,
>> that's exactly why i brought up that that function doesn't seem to work perfect
>> for virtualization purposes) 
>> 
>> > It makes no sense for both pciback and vfio-pci to workaround problems
>> > with pci_function_reset() in different ways -- it should be fixed in the
>> > core PCI code so both can benefit and make use of the same code.
>> 
>> Well perhaps Bjorn knows why the order of resets and skipping the rest as
>> implemented in "pci.c:__pci_dev_reset" was implemented in that way ?
>> 
>> Especially what is the expectation about pci_dev_specific_reset doing a proper 
>> reset for say a vga-card:
>> - i know it doesn't work on a radeon card (doesn't blank screen, on next guest 
>>   boot reports it's already posted, powermanagement doesn't work).
>> - while with a slot/bus reset, that all just works fine, screen blanks 
>>   immediately and everything else also works.
>> 
>> Added Alex as well since he added this workaround for KVM/vfio-pci, perhaps he knows why
>> he introduced the workaround in vfio-pci instead of trying to fix it in core pci 
>> code ?

> I don't know what workaround you're talking about.  As devices are
> released from the user, vfio-pci attempts to reset them.  If
> pci_reset_function() returns success we mark the device clean, otherwise
> it gets marked dirty.  Each time a device is released, if there are
> dirty devices we test whether we can try a bus/slot reset to clean them.
> In the case of assigning a GPU this typically means that the GPU or
> audio function come through first, there's no reset mechanism so it gets
> marked dirty, the next device comes through and we manage to try a bus
> reset.  vfio-pci does not have any device specific resets, all
> functionality is added to the PCI-core, thank-you-very-much.  I even
> posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
> bad so that pci_reset_function() won't claim that worked.  All VGA
> access quirks are done in QEMU, the kernel doesn't have any business in
> remapping config space over MMIO regions or trapping other config space
> backdoors.

Thanks for your insightful reply!

With "workaround" I was trying to refer to "vfio_pci_try_bus_reset()" which
implements how to reset the devices, it indeed uses function you introduced in
pci core code (with a solution for locking issues Konrad also seems to have 
ran into: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=61cf16d8bd38c3dc52033ea75d5b1f8368514a17

David seems to be arguing the whole "vfio_pci_try_bus_reset()" should be not 
needed and just doing calling "pci_reset_function()" (directly or by
echo "1" > /sys/bus/pci/devices/BDF/reset shoud always magically do the
right thing. 
(Which in my opinion seems the contradict with the mere existence
of "vfio_pci_try_bus_reset()" (i don't think you would have implemented it 
when you would have deemed it unnecessary)) 

> I have never heard of problems with the dev specific reset claiming to
> work and not doing anything, there are only a few of these, it should be
> easy to debug.

> I didn't read the original patch, but the title alone of this patch is
> quite confusing.  FLR is specifically a function-level-reset, so one
> would expect 'do_flr' to be function specific.  The pci-sysfs 'reset'
> attribute is already function specific.  If pci_reset_function() isn't
> doing the job and we need to use bus/slot reset, it's clearly not an
> FLR.  Thanks,
> Alex

The name "do_flr" is coming from the Xen xl toolstack which historically has 
code that tries to reset devices using a echo "BDF" > /sys/bus/pci/drivers/pciback/do_flr

But the name "do_flr" and the debug messages indeed are incorrect (it's not 
doing a flr nor a D3/PM reset), confusing and should not be used.

And as you seem to have solved the locking issue for vfio-pci, it is probably 
possible for xen-pciback to do the same. Instead of letting xen-pciback
work around the locking problem by deferring to the xl toolstack the resetting
logic could be kept into xen-pciback it self. 
That would also mean that the sysfs attribute would be unnecessary and make 
the naming issue moot.

--
Sander



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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:27:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:27:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZFM-0008Pe-0v; Thu, 04 Dec 2014 16:27:16 +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 1XwZFK-0008PT-Oc
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 16:27:15 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	63/CD-02696-26B80845; Thu, 04 Dec 2014 16:27:14 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417710431!7629315!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21507 invoked from network); 4 Dec 2014 16:27:13 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 16:27:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417710433; x=1449246433;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=KfJUb/HOQ6CsHH1zG3NL4hsl75JnxnjHXcA8+UnNRdc=;
	b=ISvFm9RjOrzlVQ+dCAHIUNWIuJ04kXJzSav89XtXyxcTFNBCNq0TX6X+
	xZpsj5A7JU8RkBhGyoWFIrJg6637fBb7vb1ifdKJyfgrX4+QEvaiS2Xz1
	kr9A6p1hIUcpVZ+fs1WPzcvUpNczKcuzjMFHGW7kWdF8owpryqUvj7ECH s=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 04 Dec 2014 16:27:11 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="884065337"
Received: from unknown (HELO don-760.CloudSwitch.com) ([208.52.206.83])
	by fldsmtpi02.verizon.com with ESMTP; 04 Dec 2014 16:27:04 +0000
Message-ID: <54808B52.8010603@terremark.com>
Date: Thu, 04 Dec 2014 11:26: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: <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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
	<547E1FC1.70004@terremark.com>
	<20141203105458.GA4208@zion.uk.xensource.com>
	<alpine.DEB.2.02.1412031218290.30971@kaball.uk.xensource.com>
	<547F1274.6090607@terremark.com>
	<alpine.DEB.2.02.1412031447350.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412031447350.30971@kaball.uk.xensource.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <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 12/03/14 09:50, Stefano Stabellini wrote:
> On Wed, 3 Dec 2014, Don Slutz wrote:
>> On 12/03/14 07:20, Stefano Stabellini wrote:
>>> On Wed, 3 Dec 2014, Wei Liu wrote:
>>>> On Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote:
>>>> [...]
>>>>>>>>>             hw_error("xc_domain_getinfo failed");
>>>>>>>>>         }
>>>>>>>>> -    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;
>>>>>>>>> +    real_free = free_pages;
>>>>>>>>> +    if (free_pages > VGA_HOLE_SIZE) {
>>>>>>>>> +        free_pages -= VGA_HOLE_SIZE;
>>>>>>>>> +    } else {
>>>>>>>>> +        free_pages = 0;
>>>>>>>>> +    }
>>>>>> I don't think we need to subtract VGA_HOLE_SIZE.
>>>>> If you do not use some slack (like 32 here), xen does report:
>>>>>
>>>>>
>>>>> (d5) [2014-11-29 17:07:21] Loaded SeaBIOS
>>>>> (d5) [2014-11-29 17:07:21] Creating MP tables ...
>>>>> (d5) [2014-11-29 17:07:21] Loading ACPI ...
>>>>> (XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for
>>>>> domain
>>>>> 5: 1057417 > 1057416
>>>>> (XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0
>>>> This message is a bit red herring.
>>>>
>>>> It's hvmloader trying to populate ram for firmware data. The actual
>>>> amount of extra pages needed depends on the firmware.
>>>>
>>>> In any case it's safe to disallow hvmloader from doing so, it will just
>>>> relocate some pages from ram (hence shrinking *mem_end).
>>> That looks like a better solution
>>>
>> I went with a "leave some slack" so that the error message above is not
>> output.
>>
>> When a change to hvmloader is done so that the message does not appear during
>> normal usage, the extra pages in QEMU can be dropped.
> Although those messages look like fatal errors, they are not. It is
> normal way for hvmloader to operate: firstly it tries to allocate extra
> memory until it gets an error, then it continues with normal memory,
> see:
>
> void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns)
> {
>      static int over_allocated;
>      struct xen_add_to_physmap xatp;
>      struct xen_memory_reservation xmr;
>
>      for ( ; nr_mfns-- != 0; mfn++ )
>      {
>          /* Try to allocate a brand new page in the reserved area. */
>          if ( !over_allocated )
>          {
>              xmr.domid = DOMID_SELF;
>              xmr.mem_flags = 0;
>              xmr.extent_order = 0;
>              xmr.nr_extents = 1;
>              set_xen_guest_handle(xmr.extent_start, &mfn);
>              if ( hypercall_memory_op(XENMEM_populate_physmap, &xmr) == 1 )
>                  continue;
>              over_allocated = 1;
>          }
>
>          /* Otherwise, relocate a page from the ordinary RAM map. */
>
> I think there is really nothing to change there. Maybe we want to make
> those warnings less scary.

It was not so much that hvmloader is the one to change (but having it check
for room first might be good), but more that a change to xen would be good
(like changing the wording or maybe only output in debug=y builds, etc.).

Maybe a new XENMEMF to suppress the message?


    -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 Dec 04 16:27:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:27:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZFM-0008Pe-0v; Thu, 04 Dec 2014 16:27:16 +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 1XwZFK-0008PT-Oc
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 16:27:15 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	63/CD-02696-26B80845; Thu, 04 Dec 2014 16:27:14 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417710431!7629315!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21507 invoked from network); 4 Dec 2014 16:27:13 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 16:27:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1417710433; x=1449246433;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=KfJUb/HOQ6CsHH1zG3NL4hsl75JnxnjHXcA8+UnNRdc=;
	b=ISvFm9RjOrzlVQ+dCAHIUNWIuJ04kXJzSav89XtXyxcTFNBCNq0TX6X+
	xZpsj5A7JU8RkBhGyoWFIrJg6637fBb7vb1ifdKJyfgrX4+QEvaiS2Xz1
	kr9A6p1hIUcpVZ+fs1WPzcvUpNczKcuzjMFHGW7kWdF8owpryqUvj7ECH s=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 04 Dec 2014 16:27:11 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="884065337"
Received: from unknown (HELO don-760.CloudSwitch.com) ([208.52.206.83])
	by fldsmtpi02.verizon.com with ESMTP; 04 Dec 2014 16:27:04 +0000
Message-ID: <54808B52.8010603@terremark.com>
Date: Thu, 04 Dec 2014 11:26: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: <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>
	<alpine.DEB.2.02.1411271035580.14135@kaball.uk.xensource.com>
	<547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
	<547E1FC1.70004@terremark.com>
	<20141203105458.GA4208@zion.uk.xensource.com>
	<alpine.DEB.2.02.1412031218290.30971@kaball.uk.xensource.com>
	<547F1274.6090607@terremark.com>
	<alpine.DEB.2.02.1412031447350.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412031447350.30971@kaball.uk.xensource.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xensource.com,
	Wei Liu <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 12/03/14 09:50, Stefano Stabellini wrote:
> On Wed, 3 Dec 2014, Don Slutz wrote:
>> On 12/03/14 07:20, Stefano Stabellini wrote:
>>> On Wed, 3 Dec 2014, Wei Liu wrote:
>>>> On Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote:
>>>> [...]
>>>>>>>>>             hw_error("xc_domain_getinfo failed");
>>>>>>>>>         }
>>>>>>>>> -    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;
>>>>>>>>> +    real_free = free_pages;
>>>>>>>>> +    if (free_pages > VGA_HOLE_SIZE) {
>>>>>>>>> +        free_pages -= VGA_HOLE_SIZE;
>>>>>>>>> +    } else {
>>>>>>>>> +        free_pages = 0;
>>>>>>>>> +    }
>>>>>> I don't think we need to subtract VGA_HOLE_SIZE.
>>>>> If you do not use some slack (like 32 here), xen does report:
>>>>>
>>>>>
>>>>> (d5) [2014-11-29 17:07:21] Loaded SeaBIOS
>>>>> (d5) [2014-11-29 17:07:21] Creating MP tables ...
>>>>> (d5) [2014-11-29 17:07:21] Loading ACPI ...
>>>>> (XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for
>>>>> domain
>>>>> 5: 1057417 > 1057416
>>>>> (XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0
>>>> This message is a bit red herring.
>>>>
>>>> It's hvmloader trying to populate ram for firmware data. The actual
>>>> amount of extra pages needed depends on the firmware.
>>>>
>>>> In any case it's safe to disallow hvmloader from doing so, it will just
>>>> relocate some pages from ram (hence shrinking *mem_end).
>>> That looks like a better solution
>>>
>> I went with a "leave some slack" so that the error message above is not
>> output.
>>
>> When a change to hvmloader is done so that the message does not appear during
>> normal usage, the extra pages in QEMU can be dropped.
> Although those messages look like fatal errors, they are not. It is
> normal way for hvmloader to operate: firstly it tries to allocate extra
> memory until it gets an error, then it continues with normal memory,
> see:
>
> void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns)
> {
>      static int over_allocated;
>      struct xen_add_to_physmap xatp;
>      struct xen_memory_reservation xmr;
>
>      for ( ; nr_mfns-- != 0; mfn++ )
>      {
>          /* Try to allocate a brand new page in the reserved area. */
>          if ( !over_allocated )
>          {
>              xmr.domid = DOMID_SELF;
>              xmr.mem_flags = 0;
>              xmr.extent_order = 0;
>              xmr.nr_extents = 1;
>              set_xen_guest_handle(xmr.extent_start, &mfn);
>              if ( hypercall_memory_op(XENMEM_populate_physmap, &xmr) == 1 )
>                  continue;
>              over_allocated = 1;
>          }
>
>          /* Otherwise, relocate a page from the ordinary RAM map. */
>
> I think there is really nothing to change there. Maybe we want to make
> those warnings less scary.

It was not so much that hvmloader is the one to change (but having it check
for room first might be good), but more that a change to xen would be good
(like changing the wording or maybe only output in debug=y builds, etc.).

Maybe a new XENMEMF to suppress the message?


    -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 Dec 04 16:28:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZGx-00007u-HL; Thu, 04 Dec 2014 16:28: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 1XwZGw-00007k-Gc
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:28:54 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A3/88-25276-5CB80845; Thu, 04 Dec 2014 16:28:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417710533!13443858!1
X-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 14950 invoked from network); 4 Dec 2014 16:28:53 -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 Dec 2014 16:28:53 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:28:53 +0000
Message-Id: <548099D4020000780004CD9C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:28:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-11-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip
 any overlap with reserved device 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 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
> to allocate some memory to use in runtime cycle, so we alsoe need to
> make sure all reserved device memory don't overlap such a region.

While ideally this would get switched to the model outlined for
the previous two patches too, it's at least reasonable to keep
this simple allocator simple for the time being.

> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -416,9 +416,29 @@ static uint32_t alloc_down = RESERVED_MEMORY_DYNAMIC_END;
>  
>  xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
>  {
> +    unsigned int i, num = hvm_get_reserved_device_memory_map();
> +    uint64_t rdm_start, rdm_end;
> +    uint32_t alloc_start, alloc_end;
> +
>      alloc_down -= nr_mfns << PAGE_SHIFT;
> +    alloc_start = alloc_down;
> +    alloc_end = alloc_start + (nr_mfns << PAGE_SHIFT);
> +    for ( i = 0; i < num; i++ )
> +    {
> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << PAGE_SHIFT);
> +        if ( check_rdm_hole_conflict((uint64_t)alloc_start,
> +                                     (uint64_t)alloc_end,

Pointless casts.

> +                                     rdm_start, rdm_end - rdm_start) )
> +        {
> +            alloc_end = rdm_start;
> +            alloc_start = alloc_end - (nr_mfns << PAGE_SHIFT);
> +            BUG_ON(alloc_up >= alloc_start);

This is redundant with the BUG_ON() below afaict. Or at least it
would be, if you would properly update allow_down (if you don't
you may end up returning the same PFN for two allocations).

> +        }
> +    }
> +
>      BUG_ON(alloc_up >= alloc_down);

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:28:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZGx-00007u-HL; Thu, 04 Dec 2014 16:28: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 1XwZGw-00007k-Gc
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:28:54 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A3/88-25276-5CB80845; Thu, 04 Dec 2014 16:28:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417710533!13443858!1
X-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 14950 invoked from network); 4 Dec 2014 16:28:53 -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 Dec 2014 16:28:53 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:28:53 +0000
Message-Id: <548099D4020000780004CD9C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:28:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-11-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip
 any overlap with reserved device 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 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
> to allocate some memory to use in runtime cycle, so we alsoe need to
> make sure all reserved device memory don't overlap such a region.

While ideally this would get switched to the model outlined for
the previous two patches too, it's at least reasonable to keep
this simple allocator simple for the time being.

> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -416,9 +416,29 @@ static uint32_t alloc_down = RESERVED_MEMORY_DYNAMIC_END;
>  
>  xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
>  {
> +    unsigned int i, num = hvm_get_reserved_device_memory_map();
> +    uint64_t rdm_start, rdm_end;
> +    uint32_t alloc_start, alloc_end;
> +
>      alloc_down -= nr_mfns << PAGE_SHIFT;
> +    alloc_start = alloc_down;
> +    alloc_end = alloc_start + (nr_mfns << PAGE_SHIFT);
> +    for ( i = 0; i < num; i++ )
> +    {
> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << PAGE_SHIFT);
> +        if ( check_rdm_hole_conflict((uint64_t)alloc_start,
> +                                     (uint64_t)alloc_end,

Pointless casts.

> +                                     rdm_start, rdm_end - rdm_start) )
> +        {
> +            alloc_end = rdm_start;
> +            alloc_start = alloc_end - (nr_mfns << PAGE_SHIFT);
> +            BUG_ON(alloc_up >= alloc_start);

This is redundant with the BUG_ON() below afaict. Or at least it
would be, if you would properly update allow_down (if you don't
you may end up returning the same PFN for two allocations).

> +        }
> +    }
> +
>      BUG_ON(alloc_up >= alloc_down);

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:36:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:36:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZOC-0000WE-Jl; Thu, 04 Dec 2014 16:36:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1XwZOA-0000W9-M1
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:36:22 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D3/F4-25276-68D80845; Thu, 04 Dec 2014 16:36:22 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417710979!13482798!1
X-Originating-IP: [66.165.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 12424 invoked from network); 4 Dec 2014 16:36:21 -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;
	4 Dec 2014 16:36:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="199814277"
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; Thu, 4 Dec 2014
	11:36:00 -0500
Message-ID: <54808D6F.302@citrix.com>
Date: Thu, 4 Dec 2014 17:35:59 +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.3.0
MIME-Version: 1.0
To: <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>, Mukesh
	Rathor <mukesh.rathor@oracle.com>, Tim Deegan <tim@xen.org>
X-DLP: MIA2
Subject: [Xen-devel] Removing the PVH assert in arch/x86/hvm/io.c:87
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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've just stumbled upon this assert while testing PVH on different
hardware. It was added in 7c4870 as a safe belt, but it turns out INS
and OUTS go through handle_mmio. So using this instructions from a PVH
guest basically kills Xen.

I've removed it and everything seems fine, so I'm considering sending a
patch for 4.5 in order to have it removed. I think the path that could
trigger the crash because of the missing vioapic stuff is already
guarded by the other chunk added in the same patch.

Roger.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:36:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:36:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZOC-0000WE-Jl; Thu, 04 Dec 2014 16:36:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1XwZOA-0000W9-M1
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:36:22 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D3/F4-25276-68D80845; Thu, 04 Dec 2014 16:36:22 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417710979!13482798!1
X-Originating-IP: [66.165.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 12424 invoked from network); 4 Dec 2014 16:36:21 -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;
	4 Dec 2014 16:36:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="199814277"
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; Thu, 4 Dec 2014
	11:36:00 -0500
Message-ID: <54808D6F.302@citrix.com>
Date: Thu, 4 Dec 2014 17:35:59 +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.3.0
MIME-Version: 1.0
To: <xen-devel@lists.xenproject.org>, Jan Beulich <JBeulich@suse.com>, Mukesh
	Rathor <mukesh.rathor@oracle.com>, Tim Deegan <tim@xen.org>
X-DLP: MIA2
Subject: [Xen-devel] Removing the PVH assert in arch/x86/hvm/io.c:87
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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've just stumbled upon this assert while testing PVH on different
hardware. It was added in 7c4870 as a safe belt, but it turns out INS
and OUTS go through handle_mmio. So using this instructions from a PVH
guest basically kills Xen.

I've removed it and everything seems fine, so I'm considering sending a
patch for 4.5 in order to have it removed. I think the path that could
trigger the crash because of the missing vioapic stuff is already
guarded by the other chunk added in the same patch.

Roger.

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:38:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZQR-0000fW-7A; Thu, 04 Dec 2014 16:38:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XwZQQ-0000fF-Ab
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 16:38:42 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	94/EF-15461-11E80845; Thu, 04 Dec 2014 16:38:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417711119!13484356!1
X-Originating-IP: [66.165.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 9707 invoked from network); 4 Dec 2014 16:38:41 -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;
	4 Dec 2014 16:38:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="200173159"
Received: from ukmail1.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, 4 Dec 2014 11:38: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 1XwZQN-0000X3-5n;
	Thu, 04 Dec 2014 16:38:39 +0000
Date: Thu, 4 Dec 2014 16:38:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Don Slutz <dslutz@verizon.com>
Message-ID: <20141204163839.GC31446@zion.uk.xensource.com>
References: <547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
	<547E1FC1.70004@terremark.com>
	<20141203105458.GA4208@zion.uk.xensource.com>
	<alpine.DEB.2.02.1412031218290.30971@kaball.uk.xensource.com>
	<547F1274.6090607@terremark.com>
	<alpine.DEB.2.02.1412031447350.30971@kaball.uk.xensource.com>
	<54808B52.8010603@terremark.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54808B52.8010603@terremark.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>,
	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 Thu, Dec 04, 2014 at 11:26:58AM -0500, Don Slutz wrote:
[...]
> >those warnings less scary.
> 
> It was not so much that hvmloader is the one to change (but having it check
> for room first might be good), but more that a change to xen would be good
> (like changing the wording or maybe only output in debug=y builds, etc.).
> 
> Maybe a new XENMEMF to suppress the message?
> 

I don't think it should work like that. That message is perfectly
legitimate -- a domain is asking for more memory than it should and Xen
rightfully rejects that. Having a guest controlable way to suppress that
is a bad idea.

Wei.

> 
>    -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 Dec 04 16:38:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZQR-0000fW-7A; Thu, 04 Dec 2014 16:38:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XwZQQ-0000fF-Ab
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 16:38:42 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	94/EF-15461-11E80845; Thu, 04 Dec 2014 16:38:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417711119!13484356!1
X-Originating-IP: [66.165.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 9707 invoked from network); 4 Dec 2014 16:38:41 -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;
	4 Dec 2014 16:38:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="200173159"
Received: from ukmail1.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, 4 Dec 2014 11:38: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 1XwZQN-0000X3-5n;
	Thu, 04 Dec 2014 16:38:39 +0000
Date: Thu, 4 Dec 2014 16:38:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Don Slutz <dslutz@verizon.com>
Message-ID: <20141204163839.GC31446@zion.uk.xensource.com>
References: <547C6E12.50502@terremark.com>
	<alpine.DEB.2.02.1412011528540.14135@kaball.uk.xensource.com>
	<547CF6C6.4060106@terremark.com>
	<alpine.DEB.2.02.1412021158210.14135@kaball.uk.xensource.com>
	<547E1FC1.70004@terremark.com>
	<20141203105458.GA4208@zion.uk.xensource.com>
	<alpine.DEB.2.02.1412031218290.30971@kaball.uk.xensource.com>
	<547F1274.6090607@terremark.com>
	<alpine.DEB.2.02.1412031447350.30971@kaball.uk.xensource.com>
	<54808B52.8010603@terremark.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54808B52.8010603@terremark.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>,
	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 Thu, Dec 04, 2014 at 11:26:58AM -0500, Don Slutz wrote:
[...]
> >those warnings less scary.
> 
> It was not so much that hvmloader is the one to change (but having it check
> for room first might be good), but more that a change to xen would be good
> (like changing the wording or maybe only output in debug=y builds, etc.).
> 
> Maybe a new XENMEMF to suppress the message?
> 

I don't think it should work like that. That message is perfectly
legitimate -- a domain is asking for more memory than it should and Xen
rightfully rejects that. Having a guest controlable way to suppress that
is a bad idea.

Wei.

> 
>    -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 Dec 04 16:42:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZTp-0000xn-Ui; Thu, 04 Dec 2014 16:42:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwZTo-0000xd-Th
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:42:13 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	FE/8A-08051-4EE80845; Thu, 04 Dec 2014 16:42:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417711331!7632908!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3291 invoked from network); 4 Dec 2014 16:42:11 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 16:42:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:42:10 +0000
Message-Id: <54809CF1020000780004CDC6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:42:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-12-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-12-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 11/17] xen/x86/p2m: reject populating
 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 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -556,6 +556,40 @@ guest_physmap_remove_page(struct domain *d, unsigned long gfn,
>      gfn_unlock(p2m, gfn, page_order);
>  }
>  
> +/* Check if we are accessing rdm. */

If a comment doesn't do anything but re-state a function name,
it's imo superfluous.

> +int p2m_check_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
> +                                     u32 id, void *ctxt)
> +{
> +    xen_pfn_t end = start + nr;
> +    unsigned int i;
> +    u32 sbdf;
> +    struct p2m_get_reserved_device_memory *pgrdm = ctxt;
> +    struct domain *d = pgrdm->domain;
> +
> +    if ( d->arch.hvm_domain.pci_force )
> +    {
> +        if ( pgrdm->gfn >= start && pgrdm->gfn < end )
> +            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 ( pgrdm->gfn >= start && pgrdm->gfn < end )
> +                    return 1;
> +            }

Please join together if()s like these.

> @@ -686,8 +721,28 @@ 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);
> +        pgrdm.gfn = gfn;
> +        pgrdm.domain = d;
> +        if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )
> +        {
> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                                  &pgrdm);
> +            /* We always avoid populating reserved device memory. */
> +            if ( rc == 1 )
> +            {
> +                rc = -EBUSY;
> +                goto out;

Did I overlook something in the earlier tool stack patches? How does
the tool stack avoid populating these areas?

> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -709,6 +709,15 @@ static inline unsigned int p2m_get_iommu_flags(p2m_type_t p2mt)
>      return flags;
>  }
>  
> +struct p2m_get_reserved_device_memory {
> +    unsigned long gfn;
> +    struct domain *domain;
> +};
> +
> +/* Check if we are accessing rdm. */
> +extern int p2m_check_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
> +                                            u32 id, void *ctxt);

Are subsequent patches going to make use of this outside of p2m.c?
If not, these declarations don't belong here. And even if the
function was going to be used elsewhere, the structure wouldn't
need defining here.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:42:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZTp-0000xn-Ui; Thu, 04 Dec 2014 16:42:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwZTo-0000xd-Th
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:42:13 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	FE/8A-08051-4EE80845; Thu, 04 Dec 2014 16:42:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417711331!7632908!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3291 invoked from network); 4 Dec 2014 16:42:11 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 16:42:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:42:10 +0000
Message-Id: <54809CF1020000780004CDC6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:42:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-12-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-12-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 11/17] xen/x86/p2m: reject populating
 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 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -556,6 +556,40 @@ guest_physmap_remove_page(struct domain *d, unsigned long gfn,
>      gfn_unlock(p2m, gfn, page_order);
>  }
>  
> +/* Check if we are accessing rdm. */

If a comment doesn't do anything but re-state a function name,
it's imo superfluous.

> +int p2m_check_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
> +                                     u32 id, void *ctxt)
> +{
> +    xen_pfn_t end = start + nr;
> +    unsigned int i;
> +    u32 sbdf;
> +    struct p2m_get_reserved_device_memory *pgrdm = ctxt;
> +    struct domain *d = pgrdm->domain;
> +
> +    if ( d->arch.hvm_domain.pci_force )
> +    {
> +        if ( pgrdm->gfn >= start && pgrdm->gfn < end )
> +            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 ( pgrdm->gfn >= start && pgrdm->gfn < end )
> +                    return 1;
> +            }

Please join together if()s like these.

> @@ -686,8 +721,28 @@ 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);
> +        pgrdm.gfn = gfn;
> +        pgrdm.domain = d;
> +        if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )
> +        {
> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                                  &pgrdm);
> +            /* We always avoid populating reserved device memory. */
> +            if ( rc == 1 )
> +            {
> +                rc = -EBUSY;
> +                goto out;

Did I overlook something in the earlier tool stack patches? How does
the tool stack avoid populating these areas?

> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -709,6 +709,15 @@ static inline unsigned int p2m_get_iommu_flags(p2m_type_t p2mt)
>      return flags;
>  }
>  
> +struct p2m_get_reserved_device_memory {
> +    unsigned long gfn;
> +    struct domain *domain;
> +};
> +
> +/* Check if we are accessing rdm. */
> +extern int p2m_check_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
> +                                            u32 id, void *ctxt);

Are subsequent patches going to make use of this outside of p2m.c?
If not, these declarations don't belong here. And even if the
function was going to be used elsewhere, the structure wouldn't
need defining here.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:44:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZWL-0001Ix-GF; Thu, 04 Dec 2014 16: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 1XwZWK-0001Is-7K
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:44:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	87/36-09842-F7F80845; Thu, 04 Dec 2014 16:44:47 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417711484!13506177!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 21251 invoked from network); 4 Dec 2014 16:44: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;
	4 Dec 2014 16:44:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="199819992"
Message-ID: <54808F78.2020204@citrix.com>
Date: Thu, 4 Dec 2014 16:44: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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, Dario Faggioli
	<dario.faggioli@citrix.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>		<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>	<1417694153.31647.32.camel@Abyss.station>
	<54808B20.9080503@oracle.com>
In-Reply-To: <54808B20.9080503@oracle.com>
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, jbeulich@suse.com, keir@xen.org,
	ufimtseva@gmail.com
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 04/12/14 16:26, Boris Ostrovsky wrote:
> On 12/04/2014 06:55 AM, Dario Faggioli wrote:
>> On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
>>> Make XEN_SYSCTL_topologyinfo more generic so that it can return both
>>> CPU and IO topology (support for returning the latter is added in the
>>> subsequent patch)
>>>
>> Is it always the case that we need the full information (i.e., both CPU
>> and IO topology), at all levels above Xen?
>>
>> I appreciate the performance implications (one hcall instead of two) in
>> cases where we do, but I still think, as Andrew suggested, that having a
>> new XEN_SYSCTL_iotopology (or something like that) and leaving
>> *_topologyinfo alone would make a better low-level interface.
>>
>> All IMHO, of course.
>
> I don't feel strongly either way so I can go that route (and it will
> make patch 4 completely unnecessary).
>
> (I am not sure though I understood Andrew's reasoning for splitting
> into two sysctls.

The two bits of information are different, and it is perfectly
reasonable to want the cpu information at one point, but the io
information at another.

As it stands, you appear to mandate that the caller wants the cpu
information, which is not true.

>From a separate point of view, while the sysctl abi version does allow
us to make changes like this, it makes a mess for valgrind and strace to
have radically different hypercalls with the same name, separated by
only the interface version. 

>
>>> To do so move (and rename) previously used cpu_to_core/cpu_to_socket/
>>> cpu_to_node into struct xen_sysctl_cputopo and move it, together with
>>> newly added struct xen_sysctl_iotopo, to xen_sysctl_topologyinfo.
>>>
>>> Add libxl_get_topology() to handle new interface and modify
>>> libxl_get_cpu_topology() to be a wrapper around it.
>>>
>> This is, I think, useful, and I'd go for it, even if we adding a new
>> hypercall at the Xen and xc level.
>>
>> Of course, it would work the other way round: the new libxl function
>> would wrap the existing libxl_get_cpu_topology() and a new libxl call
>> (something like libxl_get_io_topology() ?).
>>
>>> Adjust xenpm and python's low-level C libraries for new interface.
>>>
>> All in one patch? Wouldn't splitting it at least in two (hypervisor and
>> tools parts) be better? If it were me, I'd probably split even more...
>
> I could not split it because this patch changes sysctl interface (more
> specifically, xen_sysctl_topologyinfo_t/xc_topologyinfo_t) so anyone
> who uses this struct needed to be updated at the same time.
>
> Of course, if I were to leave current interface intact and add another
> sysctl for IO topology then this will not be necessary

This is the other reason why change simply for changes sake in the
interface is best avoided.  The unstable API goes very deep into the
toolstack.

>
>>
>>> This change requires bumping XEN_SYSCTL_INTERFACE_VERSION
>>>
>> Which would not be the case if we take the approach of adding a new,
>> iotopology specific, hcall, would it?
>
> I would think that any changes to a public interface, including adding
> a new function, require new version.
>
> (And if we get a new version, even if we split topology into CPU and
> IO sysctls, I'd still like to put cpu_to_[core|socket||node] into a
> single structure).

This would certainly decrease the faff both the toostack and hypervisor
have to go to when passing the parameters, and I think it would be a
good improvement.

~Andrew


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:44:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16: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 1XwZWL-0001Ix-GF; Thu, 04 Dec 2014 16: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 1XwZWK-0001Is-7K
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:44:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	87/36-09842-F7F80845; Thu, 04 Dec 2014 16:44:47 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417711484!13506177!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 21251 invoked from network); 4 Dec 2014 16:44: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;
	4 Dec 2014 16:44:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="199819992"
Message-ID: <54808F78.2020204@citrix.com>
Date: Thu, 4 Dec 2014 16:44: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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, Dario Faggioli
	<dario.faggioli@citrix.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>		<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>	<1417694153.31647.32.camel@Abyss.station>
	<54808B20.9080503@oracle.com>
In-Reply-To: <54808B20.9080503@oracle.com>
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, jbeulich@suse.com, keir@xen.org,
	ufimtseva@gmail.com
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 04/12/14 16:26, Boris Ostrovsky wrote:
> On 12/04/2014 06:55 AM, Dario Faggioli wrote:
>> On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
>>> Make XEN_SYSCTL_topologyinfo more generic so that it can return both
>>> CPU and IO topology (support for returning the latter is added in the
>>> subsequent patch)
>>>
>> Is it always the case that we need the full information (i.e., both CPU
>> and IO topology), at all levels above Xen?
>>
>> I appreciate the performance implications (one hcall instead of two) in
>> cases where we do, but I still think, as Andrew suggested, that having a
>> new XEN_SYSCTL_iotopology (or something like that) and leaving
>> *_topologyinfo alone would make a better low-level interface.
>>
>> All IMHO, of course.
>
> I don't feel strongly either way so I can go that route (and it will
> make patch 4 completely unnecessary).
>
> (I am not sure though I understood Andrew's reasoning for splitting
> into two sysctls.

The two bits of information are different, and it is perfectly
reasonable to want the cpu information at one point, but the io
information at another.

As it stands, you appear to mandate that the caller wants the cpu
information, which is not true.

>From a separate point of view, while the sysctl abi version does allow
us to make changes like this, it makes a mess for valgrind and strace to
have radically different hypercalls with the same name, separated by
only the interface version. 

>
>>> To do so move (and rename) previously used cpu_to_core/cpu_to_socket/
>>> cpu_to_node into struct xen_sysctl_cputopo and move it, together with
>>> newly added struct xen_sysctl_iotopo, to xen_sysctl_topologyinfo.
>>>
>>> Add libxl_get_topology() to handle new interface and modify
>>> libxl_get_cpu_topology() to be a wrapper around it.
>>>
>> This is, I think, useful, and I'd go for it, even if we adding a new
>> hypercall at the Xen and xc level.
>>
>> Of course, it would work the other way round: the new libxl function
>> would wrap the existing libxl_get_cpu_topology() and a new libxl call
>> (something like libxl_get_io_topology() ?).
>>
>>> Adjust xenpm and python's low-level C libraries for new interface.
>>>
>> All in one patch? Wouldn't splitting it at least in two (hypervisor and
>> tools parts) be better? If it were me, I'd probably split even more...
>
> I could not split it because this patch changes sysctl interface (more
> specifically, xen_sysctl_topologyinfo_t/xc_topologyinfo_t) so anyone
> who uses this struct needed to be updated at the same time.
>
> Of course, if I were to leave current interface intact and add another
> sysctl for IO topology then this will not be necessary

This is the other reason why change simply for changes sake in the
interface is best avoided.  The unstable API goes very deep into the
toolstack.

>
>>
>>> This change requires bumping XEN_SYSCTL_INTERFACE_VERSION
>>>
>> Which would not be the case if we take the approach of adding a new,
>> iotopology specific, hcall, would it?
>
> I would think that any changes to a public interface, including adding
> a new function, require new version.
>
> (And if we get a new version, even if we split topology into CPU and
> IO sysctls, I'd still like to put cpu_to_[core|socket||node] into a
> single structure).

This would certainly decrease the faff both the toostack and hypervisor
have to go to when passing the parameters, and I think it would be a
good improvement.

~Andrew


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:45:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:45:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZX9-0001NH-Tz; Thu, 04 Dec 2014 16:45: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 1XwZX9-0001N9-56
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:45:39 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	91/B7-09842-2BF80845; Thu, 04 Dec 2014 16:45:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417711534!13132918!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 3706 invoked from network); 4 Dec 2014 16:45:36 -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 Dec 2014 16:45:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="199820594"
Message-ID: <54808FAC.6070308@citrix.com>
Date: Thu, 4 Dec 2014 16:45: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: Jan Beulich <JBeulich@suse.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
	<54806FA2.6080406@citrix.com>
	<548083EE020000780004CC90@mail.emea.novell.com>
	<548081D6.4080208@citrix.com>
	<548095C4020000780004CD59@mail.emea.novell.com>
In-Reply-To: <548095C4020000780004CD59@mail.emea.novell.com>
X-DLP: MIA1
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-develList <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 04/12/14 16:11, Jan Beulich wrote:
>>>> On 04.12.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>> On 04/12/14 14:55, Jan Beulich wrote:
>>>>>> On 04.12.14 at 15:28, <andrew.cooper3@citrix.com> wrote:
>>>> On 04/12/14 13:49, Jan Beulich wrote:
>>>>>>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>>>>>> 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.
>>>>> With no-one else voicing an opinion:
>>>>>
>>>>> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
>>>>>
>>>>> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
>>>>>
>>>>> For the latter, we're fine even without further consideration. For the
>>>>> former, the two operations actively using the continuation encoding
>>>>> are tools-only ones. Since we're fine to alter the tools only interfaces,
>>>>> and since it was intended for the tools-only HVM-ops to be split off
>>>>> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
>>>>> would then no longer be a problem. Plus, in the worst case we could
>>>>> always introduce yet another hypercall if we ran out of numbers.
>>>> Are you suggesting that we make a new hvmctl now and remove the hvmop
>>>> mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
>>>> subsequently remove it even if all continuable hypercalls move to a
>>>> separate hypercall.
>>> Why? We certainly don't guarantee compatibility for undefined
>>> hypercalls to behave in a certain way.
>> A task is in the middle of a hypercall continuation.  The VM is migrated
>> to a newer Xen which has lost the op mask and gained a new hypercall
>> which would alias.
> Impossible: A continuation could be in progress only when we
> actually use the high bits (or else you have nowhere to encode
> it). Operations not using continuations consequently aren't
> susceptible to the mask disappearing.

Ah yes - if nothing guest usable is currently continuable, then this is ok.

~Andrew


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:45:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:45:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZX9-0001NH-Tz; Thu, 04 Dec 2014 16:45: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 1XwZX9-0001N9-56
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:45:39 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	91/B7-09842-2BF80845; Thu, 04 Dec 2014 16:45:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417711534!13132918!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 3706 invoked from network); 4 Dec 2014 16:45:36 -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 Dec 2014 16:45:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="scan'208";a="199820594"
Message-ID: <54808FAC.6070308@citrix.com>
Date: Thu, 4 Dec 2014 16:45: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: Jan Beulich <JBeulich@suse.com>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
	<54806FA2.6080406@citrix.com>
	<548083EE020000780004CC90@mail.emea.novell.com>
	<548081D6.4080208@citrix.com>
	<548095C4020000780004CD59@mail.emea.novell.com>
In-Reply-To: <548095C4020000780004CD59@mail.emea.novell.com>
X-DLP: MIA1
Cc: Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Xen-develList <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 04/12/14 16:11, Jan Beulich wrote:
>>>> On 04.12.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>> On 04/12/14 14:55, Jan Beulich wrote:
>>>>>> On 04.12.14 at 15:28, <andrew.cooper3@citrix.com> wrote:
>>>> On 04/12/14 13:49, Jan Beulich wrote:
>>>>>>>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
>>>>>> 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.
>>>>> With no-one else voicing an opinion:
>>>>>
>>>>> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
>>>>>
>>>>> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
>>>>>
>>>>> For the latter, we're fine even without further consideration. For the
>>>>> former, the two operations actively using the continuation encoding
>>>>> are tools-only ones. Since we're fine to alter the tools only interfaces,
>>>>> and since it was intended for the tools-only HVM-ops to be split off
>>>>> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
>>>>> would then no longer be a problem. Plus, in the worst case we could
>>>>> always introduce yet another hypercall if we ran out of numbers.
>>>> Are you suggesting that we make a new hvmctl now and remove the hvmop
>>>> mask before 4.5?  If we ship 4.5 with the hvmop mask, we cannot
>>>> subsequently remove it even if all continuable hypercalls move to a
>>>> separate hypercall.
>>> Why? We certainly don't guarantee compatibility for undefined
>>> hypercalls to behave in a certain way.
>> A task is in the middle of a hypercall continuation.  The VM is migrated
>> to a newer Xen which has lost the op mask and gained a new hypercall
>> which would alias.
> Impossible: A continuation could be in progress only when we
> actually use the high bits (or else you have nowhere to encode
> it). Operations not using continuations consequently aren't
> susceptible to the mask disappearing.

Ah yes - if nothing guest usable is currently continuable, then this is ok.

~Andrew


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:46:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZXi-0001Rr-B6; Thu, 04 Dec 2014 16:46:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwZXg-0001Re-Sw
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:46:12 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	59/16-02957-4DF80845; Thu, 04 Dec 2014 16:46:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417711571!13071232!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 4 Dec 2014 16:46:11 -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; 4 Dec 2014 16:46:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:46:11 +0000
Message-Id: <54809DE1020000780004CDC9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:46:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-13-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-13-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 12/17] xen/x86/ept: handle reserved
 device memory in ept_handle_violation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> We always reserve these ranges since we never allow any stuff to
> poke them.
> 
> But in theory some untrusted VM can maliciously access them. So we
> need to intercept this approach. But we just don't want to leak
> anything or introduce any side affect since other OSs may touch them
> by careless behavior, so its enough to have a lightweight way, and
> it shouldn't be same as those broken pages which cause domain crush.

This needs a better explanation: If the devices associated with the
reserved region being touched are assigned to the guest, it is
permitted to touch them. If it touches regions of devices not yet or
not anymore assigned to it, the behavior should match real
hardware: Writes ignored and reads return all ones. I.e. such
accesses should get handed to the DM in that latter case.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:46:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZXi-0001Rr-B6; Thu, 04 Dec 2014 16:46:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwZXg-0001Re-Sw
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:46:12 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	59/16-02957-4DF80845; Thu, 04 Dec 2014 16:46:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417711571!13071232!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 4 Dec 2014 16:46:11 -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; 4 Dec 2014 16:46:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:46:11 +0000
Message-Id: <54809DE1020000780004CDC9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:46:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-13-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-13-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 12/17] xen/x86/ept: handle reserved
 device memory in ept_handle_violation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> We always reserve these ranges since we never allow any stuff to
> poke them.
> 
> But in theory some untrusted VM can maliciously access them. So we
> need to intercept this approach. But we just don't want to leak
> anything or introduce any side affect since other OSs may touch them
> by careless behavior, so its enough to have a lightweight way, and
> it shouldn't be same as those broken pages which cause domain crush.

This needs a better explanation: If the devices associated with the
reserved region being touched are assigned to the guest, it is
permitted to touch them. If it touches regions of devices not yet or
not anymore assigned to it, the behavior should match real
hardware: Writes ignored and reads return all ones. I.e. such
accesses should get handed to the DM in that latter case.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:52:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:52:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZd7-00024Q-4v; Thu, 04 Dec 2014 16:51:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwZd5-00023x-K1
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:51:47 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	73/EF-24124-22190845; Thu, 04 Dec 2014 16:51:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417711906!11625819!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22041 invoked from network); 4 Dec 2014 16:51:46 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 16:51:46 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:51:45 +0000
Message-Id: <54809F30020000780004CDF6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:51:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-14-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 13/17] xen/mem_access: don't allow
 accessing reserved device 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 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> --- a/xen/common/mem_access.c
> +++ b/xen/common/mem_access.c
> @@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)
>      }
>  }
>  
> +/* We can't expose reserved device memory. */
> +static int mem_access_check_rdm(struct domain *d, uint64_aligned_t start,
> +                                uint32_t nr)
> +{
> +    uint32_t i;
> +    struct p2m_get_reserved_device_memory pgrdm;
> +    int rc = 0;
> +
> +    if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )

Why?

> +    {
> +        for ( i = 0; i < nr; i++ )
> +        {
> +            pgrdm.gfn = start + i;
> +            pgrdm.domain = d;
> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                                  &pgrdm);
> +            if ( rc < 0 )
> +            {
> +                printk(XENLOG_WARNING
> +                       "Domain %d can't check reserved device memory.\n",

If I saw this text in a log file, it wouldn't mean anything to me.
Additionally this is only partly useful without also listing the
offending domain (which isn't d afaict) and the GFN.

> +                       d->domain_id);
> +                return rc;
> +            }
> +
> +            if ( rc == 1 )
> +            {
> +                printk(XENLOG_WARNING
> +                       "Domain %d: we shouldn't mem_access reserved device memory.\n",

This one's only marginally better than the one above.

> +                       d->domain_id);
> +                return rc;
> +            }
> +        }
> +    }
> +
> +    return rc;
> +}
> +
>  int mem_access_memop(unsigned long cmd,
>                       XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg)
>  {
> @@ -99,6 +136,10 @@ int mem_access_memop(unsigned long cmd,
>                ((mao.pfn + mao.nr - 1) > domain_get_maximum_gpfn(d))) )
>              break;
>  
> +        rc =  mem_access_check_rdm(d, mao.pfn, mao.nr);
> +        if ( rc == 1 )
> +            break;

So you decided to return 1 from the hypercall - what is that
supposed to mean to an unaware caller?

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:52:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:52:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZd7-00024Q-4v; Thu, 04 Dec 2014 16:51:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwZd5-00023x-K1
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 16:51:47 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	73/EF-24124-22190845; Thu, 04 Dec 2014 16:51:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417711906!11625819!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22041 invoked from network); 4 Dec 2014 16:51:46 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 16:51:46 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 16:51:45 +0000
Message-Id: <54809F30020000780004CDF6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 16:51:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-14-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 13/17] xen/mem_access: don't allow
 accessing reserved device 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 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> --- a/xen/common/mem_access.c
> +++ b/xen/common/mem_access.c
> @@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)
>      }
>  }
>  
> +/* We can't expose reserved device memory. */
> +static int mem_access_check_rdm(struct domain *d, uint64_aligned_t start,
> +                                uint32_t nr)
> +{
> +    uint32_t i;
> +    struct p2m_get_reserved_device_memory pgrdm;
> +    int rc = 0;
> +
> +    if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )

Why?

> +    {
> +        for ( i = 0; i < nr; i++ )
> +        {
> +            pgrdm.gfn = start + i;
> +            pgrdm.domain = d;
> +            rc = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                                  &pgrdm);
> +            if ( rc < 0 )
> +            {
> +                printk(XENLOG_WARNING
> +                       "Domain %d can't check reserved device memory.\n",

If I saw this text in a log file, it wouldn't mean anything to me.
Additionally this is only partly useful without also listing the
offending domain (which isn't d afaict) and the GFN.

> +                       d->domain_id);
> +                return rc;
> +            }
> +
> +            if ( rc == 1 )
> +            {
> +                printk(XENLOG_WARNING
> +                       "Domain %d: we shouldn't mem_access reserved device memory.\n",

This one's only marginally better than the one above.

> +                       d->domain_id);
> +                return rc;
> +            }
> +        }
> +    }
> +
> +    return rc;
> +}
> +
>  int mem_access_memop(unsigned long cmd,
>                       XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg)
>  {
> @@ -99,6 +136,10 @@ int mem_access_memop(unsigned long cmd,
>                ((mao.pfn + mao.nr - 1) > domain_get_maximum_gpfn(d))) )
>              break;
>  
> +        rc =  mem_access_check_rdm(d, mao.pfn, mao.nr);
> +        if ( rc == 1 )
> +            break;

So you decided to return 1 from the hypercall - what is that
supposed to mean to an unaware caller?

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:55:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZge-0002TO-Vt; Thu, 04 Dec 2014 16:55:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex.williamson@redhat.com>) id 1XwZgd-0002TJ-RX
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:55:28 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	45/0D-25727-EF190845; Thu, 04 Dec 2014 16:55:26 +0000
X-Env-Sender: alex.williamson@redhat.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417712123!11112476!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3243 invoked from network); 4 Dec 2014 16:55:25 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 16:55:25 -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 sB4GtFxM023048
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 4 Dec 2014 11:55:15 -0500
Received: from [10.3.113.2] ([10.3.113.2])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB4GtEk6007864; Thu, 4 Dec 2014 11:55:15 -0500
Message-ID: <1417712114.15750.123.camel@bling.home>
From: Alex Williamson <alex.williamson@redhat.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Thu, 04 Dec 2014 09:55:14 -0700
In-Reply-To: <779770151.20141204172558@eikelenboom.it>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com> <308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
	<1417707546.15750.100.camel@bling.home>
	<779770151.20141204172558@eikelenboom.it>
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, bhelgaas@google.com,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-04 at 17:25 +0100, Sander Eikelenboom wrote:
> Thursday, December 4, 2014, 4:39:06 PM, you wrote:
> 
> > On Thu, 2014-12-04 at 15:50 +0100, Sander Eikelenboom wrote:
> >> Thursday, December 4, 2014, 3:31:11 PM, you wrote:
> >> 
> >> > On 04/12/14 14:09, Sander Eikelenboom wrote:
> >> >> 
> >> >> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
> >> >> 
> >> >>> On 04/12/14 13:10, Sander Eikelenboom wrote:
> >> >>>>
> >> >>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
> >> >>>>
> >> >>>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
> >> >>>>>>
> >> >>>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> >> >>>>>>>
> >> >>>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
> >> >>>>>>>>
> >> >>>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
> >> >>>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
> >> >>>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
> >> >>>>>>>> It bypasses the need to worry about the PCI lock. 
> >> >>>>>>>
> >> >>>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
> >> >>>>>>> proposed). 
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
> >> >>>>
> >> >>>>> It is only needed if the core won't provide one.
> >> >>>>
> >> >>>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
> >> >>>>> +{
> >> >>>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
> >> >>>>> +       struct device *dev = &pci->dev;
> >> >>>>> +       int ret;
> >> >>>>> +
> >> >>>>> +       /* Already have a per-function reset? */
> >> >>>>> +       if (pci_probe_reset_function(pci) == 0)
> >> >>>>> +               return 0;
> >> >>>>> +
> >> >>>>> +       ret = device_create_file(dev, &dev_attr_reset);
> >> >>>>> +       if (ret < 0)
> >> >>>>> +               return ret;
> >> >>>> +       dev_data->>created_reset_file = true;
> >> >>>>> +       return 0;
> >> >>>>> +}
> >> >>>>
> >> >>>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
> >> >>>> "pci.c:__pci_dev_reset" ?
> >> >>>>
> >> >>>> The problem with that function is that from my testing it seems that the 
> >> >>>> first option "pci_dev_specific_reset" always seems to return succes, so all the
> >> >>>> other options are skipped (flr, pm, slot, bus). However the device it self is 
> >> >>>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
> >> >>>> none virtualization purposes and it's probably the least intrusive. For 
> >> >>>> virtualization however it would be nice to be sure it resets properly, or have a 
> >> >>>> way to force a specific reset routine.)
> >> >> 
> >> >>> Then you need work with the maintainer for those specific devices or
> >> >>> drivers to fix their specific reset function.
> >> >> 
> >> >>> I'm not adding stuff to pciback to workaround broken quirks.
> >> >> 
> >> >> OK that's a pretty clear message there, so if one wants to use pci and vga
> >> >> passthrough one should better use KVM and vfio-pci.
> >> 
> >> > Have you (or anyone else) ever raised the problem with the broken reset
> >> > quirk for certain devices with the relevant maintainer?
> >> 
> >> >> vfio-pci has:
> >> >> - logic to do the try-slot-bus-reset logic
> >> 
> >> > Just because vfio-pci fixed it incorrectly doesn't mean pciback has to
> >> > as well.
> >> 
> >> Depends on what you call an "incorrect fix" .. it fixes a quirk .. 
> >> you can say that's incorrect, but then you would have to remove 50% of
> >> the kernel and Xen code as well.
> >> 
> >> (i do in general agree it's better to strive for a generic solution though,
> >> that's exactly why i brought up that that function doesn't seem to work perfect
> >> for virtualization purposes) 
> >> 
> >> > It makes no sense for both pciback and vfio-pci to workaround problems
> >> > with pci_function_reset() in different ways -- it should be fixed in the
> >> > core PCI code so both can benefit and make use of the same code.
> >> 
> >> Well perhaps Bjorn knows why the order of resets and skipping the rest as
> >> implemented in "pci.c:__pci_dev_reset" was implemented in that way ?
> >> 
> >> Especially what is the expectation about pci_dev_specific_reset doing a proper 
> >> reset for say a vga-card:
> >> - i know it doesn't work on a radeon card (doesn't blank screen, on next guest 
> >>   boot reports it's already posted, powermanagement doesn't work).
> >> - while with a slot/bus reset, that all just works fine, screen blanks 
> >>   immediately and everything else also works.
> >> 
> >> Added Alex as well since he added this workaround for KVM/vfio-pci, perhaps he knows why
> >> he introduced the workaround in vfio-pci instead of trying to fix it in core pci 
> >> code ?
> 
> > I don't know what workaround you're talking about.  As devices are
> > released from the user, vfio-pci attempts to reset them.  If
> > pci_reset_function() returns success we mark the device clean, otherwise
> > it gets marked dirty.  Each time a device is released, if there are
> > dirty devices we test whether we can try a bus/slot reset to clean them.
> > In the case of assigning a GPU this typically means that the GPU or
> > audio function come through first, there's no reset mechanism so it gets
> > marked dirty, the next device comes through and we manage to try a bus
> > reset.  vfio-pci does not have any device specific resets, all
> > functionality is added to the PCI-core, thank-you-very-much.  I even
> > posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
> > bad so that pci_reset_function() won't claim that worked.  All VGA
> > access quirks are done in QEMU, the kernel doesn't have any business in
> > remapping config space over MMIO regions or trapping other config space
> > backdoors.
> 
> Thanks for your insightful reply!
> 
> With "workaround" I was trying to refer to "vfio_pci_try_bus_reset()" which
> implements how to reset the devices, it indeed uses function you introduced in
> pci core code (with a solution for locking issues Konrad also seems to have 
> ran into: 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=61cf16d8bd38c3dc52033ea75d5b1f8368514a17
> 
> David seems to be arguing the whole "vfio_pci_try_bus_reset()" should be not 
> needed and just doing calling "pci_reset_function()" (directly or by
> echo "1" > /sys/bus/pci/devices/BDF/reset shoud always magically do the
> right thing. 
> (Which in my opinion seems the contradict with the mere existence
> of "vfio_pci_try_bus_reset()" (i don't think you would have implemented it 
> when you would have deemed it unnecessary)) 

That truly would be magic because a bus/slot reset and function reset
are completely different beasts.  QEMU, through vfio-pci, makes use of
both.  Take for instance hot-plugging the second port of a dual-port NIC
to a guest, where the first port may be (a) assigned to the same guest,
(b) assigned to a different guest, (c) in-use by the host, or (d)
not-in-use.  For a hotplug I can only make use of a bus/slot reset in
one of those cases (d).  For a cold-plug or VM reset, only two (a,d).  I
don't see how pci_reset_function() can have that sort of visibility to
the ownership and usage of a given device.  vfio-pci doesn't even have
this visibility, which is why the distinction is made in QEMU.  vfio-pci
is just a conduit and gatekeeper to the PCI-core interfaces, for
instance preventing QEMU from doing a reset in the (b) and (c) cases.
What prevents that in the Xen case?  Userspace?

> > I have never heard of problems with the dev specific reset claiming to
> > work and not doing anything, there are only a few of these, it should be
> > easy to debug.
> 
> > I didn't read the original patch, but the title alone of this patch is
> > quite confusing.  FLR is specifically a function-level-reset, so one
> > would expect 'do_flr' to be function specific.  The pci-sysfs 'reset'
> > attribute is already function specific.  If pci_reset_function() isn't
> > doing the job and we need to use bus/slot reset, it's clearly not an
> > FLR.  Thanks,
> > Alex
> 
> The name "do_flr" is coming from the Xen xl toolstack which historically has 
> code that tries to reset devices using a echo "BDF" > /sys/bus/pci/drivers/pciback/do_flr

Redundant to /sys/bus/pci/devices/DDDD:BB:DD.F/reset

> But the name "do_flr" and the debug messages indeed are incorrect (it's not 
> doing a flr nor a D3/PM reset), confusing and should not be used.
> 
> And as you seem to have solved the locking issue for vfio-pci, it is probably 
> possible for xen-pciback to do the same. Instead of letting xen-pciback
> work around the locking problem by deferring to the xl toolstack the resetting
> logic could be kept into xen-pciback it self. 
> That would also mean that the sysfs attribute would be unnecessary and make 
> the naming issue moot.

I would consider the try_*_reset() interfaces to be a workaround for
existing locking issues which are much harder to solve.  It makes the
vfio-pci reset-on-release a best effort approach, which is generally
fine.  For vfio I can't rely on a toolstack, nor maybe should you.
There's always a chance that the VM/user is sent a kill -9 and it's the
kernel's job to protect itself and return things to a quiescent state.
This is why I don't simply have QEMU send a bus reset on shutdown or put
reset policy that can affect other users or the host in userspace.
Thanks,

Alex


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 16:55:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 16:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZge-0002TO-Vt; Thu, 04 Dec 2014 16:55:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex.williamson@redhat.com>) id 1XwZgd-0002TJ-RX
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:55:28 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	45/0D-25727-EF190845; Thu, 04 Dec 2014 16:55:26 +0000
X-Env-Sender: alex.williamson@redhat.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417712123!11112476!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3243 invoked from network); 4 Dec 2014 16:55:25 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 16:55:25 -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 sB4GtFxM023048
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 4 Dec 2014 11:55:15 -0500
Received: from [10.3.113.2] ([10.3.113.2])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB4GtEk6007864; Thu, 4 Dec 2014 11:55:15 -0500
Message-ID: <1417712114.15750.123.camel@bling.home>
From: Alex Williamson <alex.williamson@redhat.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Thu, 04 Dec 2014 09:55:14 -0700
In-Reply-To: <779770151.20141204172558@eikelenboom.it>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com> <308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
	<1417707546.15750.100.camel@bling.home>
	<779770151.20141204172558@eikelenboom.it>
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, bhelgaas@google.com,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-04 at 17:25 +0100, Sander Eikelenboom wrote:
> Thursday, December 4, 2014, 4:39:06 PM, you wrote:
> 
> > On Thu, 2014-12-04 at 15:50 +0100, Sander Eikelenboom wrote:
> >> Thursday, December 4, 2014, 3:31:11 PM, you wrote:
> >> 
> >> > On 04/12/14 14:09, Sander Eikelenboom wrote:
> >> >> 
> >> >> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
> >> >> 
> >> >>> On 04/12/14 13:10, Sander Eikelenboom wrote:
> >> >>>>
> >> >>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
> >> >>>>
> >> >>>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
> >> >>>>>>
> >> >>>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> >> >>>>>>>
> >> >>>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
> >> >>>>>>>>
> >> >>>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
> >> >>>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
> >> >>>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
> >> >>>>>>>> It bypasses the need to worry about the PCI lock. 
> >> >>>>>>>
> >> >>>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
> >> >>>>>>> proposed). 
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
> >> >>>>
> >> >>>>> It is only needed if the core won't provide one.
> >> >>>>
> >> >>>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
> >> >>>>> +{
> >> >>>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
> >> >>>>> +       struct device *dev = &pci->dev;
> >> >>>>> +       int ret;
> >> >>>>> +
> >> >>>>> +       /* Already have a per-function reset? */
> >> >>>>> +       if (pci_probe_reset_function(pci) == 0)
> >> >>>>> +               return 0;
> >> >>>>> +
> >> >>>>> +       ret = device_create_file(dev, &dev_attr_reset);
> >> >>>>> +       if (ret < 0)
> >> >>>>> +               return ret;
> >> >>>> +       dev_data->>created_reset_file = true;
> >> >>>>> +       return 0;
> >> >>>>> +}
> >> >>>>
> >> >>>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
> >> >>>> "pci.c:__pci_dev_reset" ?
> >> >>>>
> >> >>>> The problem with that function is that from my testing it seems that the 
> >> >>>> first option "pci_dev_specific_reset" always seems to return succes, so all the
> >> >>>> other options are skipped (flr, pm, slot, bus). However the device it self is 
> >> >>>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
> >> >>>> none virtualization purposes and it's probably the least intrusive. For 
> >> >>>> virtualization however it would be nice to be sure it resets properly, or have a 
> >> >>>> way to force a specific reset routine.)
> >> >> 
> >> >>> Then you need work with the maintainer for those specific devices or
> >> >>> drivers to fix their specific reset function.
> >> >> 
> >> >>> I'm not adding stuff to pciback to workaround broken quirks.
> >> >> 
> >> >> OK that's a pretty clear message there, so if one wants to use pci and vga
> >> >> passthrough one should better use KVM and vfio-pci.
> >> 
> >> > Have you (or anyone else) ever raised the problem with the broken reset
> >> > quirk for certain devices with the relevant maintainer?
> >> 
> >> >> vfio-pci has:
> >> >> - logic to do the try-slot-bus-reset logic
> >> 
> >> > Just because vfio-pci fixed it incorrectly doesn't mean pciback has to
> >> > as well.
> >> 
> >> Depends on what you call an "incorrect fix" .. it fixes a quirk .. 
> >> you can say that's incorrect, but then you would have to remove 50% of
> >> the kernel and Xen code as well.
> >> 
> >> (i do in general agree it's better to strive for a generic solution though,
> >> that's exactly why i brought up that that function doesn't seem to work perfect
> >> for virtualization purposes) 
> >> 
> >> > It makes no sense for both pciback and vfio-pci to workaround problems
> >> > with pci_function_reset() in different ways -- it should be fixed in the
> >> > core PCI code so both can benefit and make use of the same code.
> >> 
> >> Well perhaps Bjorn knows why the order of resets and skipping the rest as
> >> implemented in "pci.c:__pci_dev_reset" was implemented in that way ?
> >> 
> >> Especially what is the expectation about pci_dev_specific_reset doing a proper 
> >> reset for say a vga-card:
> >> - i know it doesn't work on a radeon card (doesn't blank screen, on next guest 
> >>   boot reports it's already posted, powermanagement doesn't work).
> >> - while with a slot/bus reset, that all just works fine, screen blanks 
> >>   immediately and everything else also works.
> >> 
> >> Added Alex as well since he added this workaround for KVM/vfio-pci, perhaps he knows why
> >> he introduced the workaround in vfio-pci instead of trying to fix it in core pci 
> >> code ?
> 
> > I don't know what workaround you're talking about.  As devices are
> > released from the user, vfio-pci attempts to reset them.  If
> > pci_reset_function() returns success we mark the device clean, otherwise
> > it gets marked dirty.  Each time a device is released, if there are
> > dirty devices we test whether we can try a bus/slot reset to clean them.
> > In the case of assigning a GPU this typically means that the GPU or
> > audio function come through first, there's no reset mechanism so it gets
> > marked dirty, the next device comes through and we manage to try a bus
> > reset.  vfio-pci does not have any device specific resets, all
> > functionality is added to the PCI-core, thank-you-very-much.  I even
> > posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
> > bad so that pci_reset_function() won't claim that worked.  All VGA
> > access quirks are done in QEMU, the kernel doesn't have any business in
> > remapping config space over MMIO regions or trapping other config space
> > backdoors.
> 
> Thanks for your insightful reply!
> 
> With "workaround" I was trying to refer to "vfio_pci_try_bus_reset()" which
> implements how to reset the devices, it indeed uses function you introduced in
> pci core code (with a solution for locking issues Konrad also seems to have 
> ran into: 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=61cf16d8bd38c3dc52033ea75d5b1f8368514a17
> 
> David seems to be arguing the whole "vfio_pci_try_bus_reset()" should be not 
> needed and just doing calling "pci_reset_function()" (directly or by
> echo "1" > /sys/bus/pci/devices/BDF/reset shoud always magically do the
> right thing. 
> (Which in my opinion seems the contradict with the mere existence
> of "vfio_pci_try_bus_reset()" (i don't think you would have implemented it 
> when you would have deemed it unnecessary)) 

That truly would be magic because a bus/slot reset and function reset
are completely different beasts.  QEMU, through vfio-pci, makes use of
both.  Take for instance hot-plugging the second port of a dual-port NIC
to a guest, where the first port may be (a) assigned to the same guest,
(b) assigned to a different guest, (c) in-use by the host, or (d)
not-in-use.  For a hotplug I can only make use of a bus/slot reset in
one of those cases (d).  For a cold-plug or VM reset, only two (a,d).  I
don't see how pci_reset_function() can have that sort of visibility to
the ownership and usage of a given device.  vfio-pci doesn't even have
this visibility, which is why the distinction is made in QEMU.  vfio-pci
is just a conduit and gatekeeper to the PCI-core interfaces, for
instance preventing QEMU from doing a reset in the (b) and (c) cases.
What prevents that in the Xen case?  Userspace?

> > I have never heard of problems with the dev specific reset claiming to
> > work and not doing anything, there are only a few of these, it should be
> > easy to debug.
> 
> > I didn't read the original patch, but the title alone of this patch is
> > quite confusing.  FLR is specifically a function-level-reset, so one
> > would expect 'do_flr' to be function specific.  The pci-sysfs 'reset'
> > attribute is already function specific.  If pci_reset_function() isn't
> > doing the job and we need to use bus/slot reset, it's clearly not an
> > FLR.  Thanks,
> > Alex
> 
> The name "do_flr" is coming from the Xen xl toolstack which historically has 
> code that tries to reset devices using a echo "BDF" > /sys/bus/pci/drivers/pciback/do_flr

Redundant to /sys/bus/pci/devices/DDDD:BB:DD.F/reset

> But the name "do_flr" and the debug messages indeed are incorrect (it's not 
> doing a flr nor a D3/PM reset), confusing and should not be used.
> 
> And as you seem to have solved the locking issue for vfio-pci, it is probably 
> possible for xen-pciback to do the same. Instead of letting xen-pciback
> work around the locking problem by deferring to the xl toolstack the resetting
> logic could be kept into xen-pciback it self. 
> That would also mean that the sysfs attribute would be unnecessary and make 
> the naming issue moot.

I would consider the try_*_reset() interfaces to be a workaround for
existing locking issues which are much harder to solve.  It makes the
vfio-pci reset-on-release a best effort approach, which is generally
fine.  For vfio I can't rely on a toolstack, nor maybe should you.
There's always a chance that the VM/user is sent a kill -9 and it's the
kernel's job to protect itself and return things to a quiescent state.
This is why I don't simply have QEMU send a bus reset on shutdown or put
reset policy that can affect other users or the host in userspace.
Thanks,

Alex


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 17:02:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 17: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 1XwZmu-0002gR-TR; Thu, 04 Dec 2014 17:01:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XwZmt-0002gM-Dx
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 17:01:55 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	12/D0-19763-28390845; Thu, 04 Dec 2014 17:01:54 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417712513!8253460!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 9093 invoked from network); 4 Dec 2014 17:01:54 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Dec 2014 17:01:54 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=Svm+YhdyIE8eMYJ8SXxYEC9PH+3m45Qbq9kk7of34fZbIBQJvev6fQbqnbu5Pk1GvL9VuhkOqGjUJffYZhrOT61RMI07J+WweeTaa3AeOqVnPHlhLRHjd89tlZFRKsBXMZOOQkO2CHKnZu/rRncXGv+IEZxAAN7p0uK7sUTA0BKOLNh2p+cgpzCQqQey+FGFlu7EVeWFeKBwDXMAYNUTuu9bTm4AVyZEVQLvp53cYSPG1gUPE/mnODIEEd1g+nxB/oHPVFs5Gj4v9EfaTimX8vhaAX+LuXp7YIHGkr1A4CiFcCOtz8H/CZf5zriDvLq6c5fz9BDUkHj2iRu4/u4hZg==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:MIME-Version: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=from:to
	:cc:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=C/3f/9vL8KCEvBjmdy/aCW
	XY788=; b=QJXxlDgkITZRsJxlsBvV2pZd5Tsl3NfownVEECJl/M6FyVuQUdErfu
	1uJ14W2W2Ozjqr8poNIt7sQYtuaI1vSG78pD5POt3cSuuarPDDBU4k/+vOD4Lh8p
	3vYtRs+oRJ/th7iH1OTJXtoZExWgg+6BfDeVk3MT2MKEgSygyNd/DSNro7NW78/6
	chjoakOaNsnADfrOSwbhG92g2mXvfloYvEViDesY97uPXbvo7AInnyEr3emO5weH
	wsyPiPhOu23dUpmzu9TTeHJL8/WCocpfyF5zFI/ys0c5VFuXtmS8RZfWJ1pZx74J
	0lowGIy2uFbUPyhK5GYokXRZ1YtPQiMg==
Received: (qmail 25239 invoked from network); 4 Dec 2014 19:01:52 +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 Dec 2014 19:01:52 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 037CC803F8
	for <xen-devel@lists.xenproject.org>;
	Thu,  4 Dec 2014 19:01:52 +0200 (EET)
Received: (qmail 25572 invoked from network); 4 Dec 2014 19:01:51 +0200
Received: from unknown (HELO mdontu-l.dsd.bitdefender.biz)
	(mdontu@bitdefender.com@91.199.104.6)
	by smtp03.buh.bitdefender.org with SMTP; 4 Dec 2014 19:01:51 +0200
From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
To: xen-devel@lists.xenproject.org
Date: Thu,  4 Dec 2014 19:01:40 +0200
Message-Id: <1417712500-28009-1-git-send-email-mdontu@bitdefender.com>
X-Mailer: git-send-email 2.2.0
MIME-Version: 1.0
Content-Length: 8697
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.58102
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374172,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; 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.1.0; Id: 2m1ghdo.198b2oeh4.4jk5],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
Subject: [Xen-devel] [PATCH] xmalloc: add support for checking the pool
	integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SW1wbGVtZW50ZWQgeG1lbV9wb29sX2NoZWNrKCksIHhtZW1fcG9vbF9jaGVja19sb2NrZWQoKSBh
bmQKeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKCkgdG8gdmVyaXR5IHRoZSBpbnRlZ3JpdHkgb2Yg
dGhlIFRMU0YgbWF0cml4LgoKU2lnbmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0
ZGVmZW5kZXIuY29tPgotLS0KIHhlbi9jb21tb24veG1hbGxvY190bHNmLmMgfCAxMTkgKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQogeGVuL2luY2x1ZGUveGVu
L3htYWxsb2MuaCB8ICAgNyArKysKIDIgZmlsZXMgY2hhbmdlZCwgMTI0IGluc2VydGlvbnMoKyks
IDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi94bWFsbG9jX3Rsc2YuYyBi
L3hlbi9jb21tb24veG1hbGxvY190bHNmLmMKaW5kZXggYTU3NjljOS4uMDA5YmE2MCAxMDA2NDQK
LS0tIGEveGVuL2NvbW1vbi94bWFsbG9jX3Rsc2YuYworKysgYi94ZW4vY29tbW9uL3htYWxsb2Nf
dGxzZi5jCkBAIC0xMjAsOSArMTIwLDEyMCBAQCBzdHJ1Y3QgeG1lbV9wb29sIHsKICAgICBjaGFy
IG5hbWVbTUFYX1BPT0xfTkFNRV9MRU5dOwogfTsKIAorc3RhdGljIHN0cnVjdCB4bWVtX3Bvb2wg
KnhlbnBvb2w7CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBNQVBQSU5HX0lOU0VSVCh1bnNpZ25lZCBs
b25nIHIsIGludCAqZmwsIGludCAqc2wpOworCiAvKgogICogSGVscGluZyBmdW5jdGlvbnMKICAq
LworI2lmbmRlZiBOREVCVUcKK3N0YXRpYyBpbnQgeG1lbV9wb29sX2NoZWNrX3NpemUoY29uc3Qg
c3RydWN0IGJoZHIgKmIsIGludCBmbCwgaW50IHNsKQoreworICAgIHdoaWxlICggYiApCisgICAg
eworICAgICAgICBpbnQgX19mbDsKKyAgICAgICAgaW50IF9fc2w7CisKKyAgICAgICAgTUFQUElO
R19JTlNFUlQoYi0+c2l6ZSwgJl9fZmwsICZfX3NsKTsKKyAgICAgICAgaWYgKCBfX2ZsICE9IGZs
IHx8IF9fc2wgIT0gc2wgKQorICAgICAgICB7CisgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VS
UiAieG1lbV9wb29sOiBmb3IgYmxvY2sgJXAgc2l6ZSA9ICV1LCB7IGZsID0gJWQsIHNsID0gJWQg
fSBzaG91bGQgYmUgeyBmbCA9ICVkLCBzbCA9ICVkIH1cbiIsIGIsIGItPnNpemUsIGZsLCBzbCwg
X19mbCwgX19zbCk7CisgICAgICAgICAgICByZXR1cm4gMDsKKyAgICAgICAgfQorICAgICAgICBi
ID0gYi0+cHRyLmZyZWVfcHRyLm5leHQ7CisgICAgfQorICAgIHJldHVybiAxOworfQorCisvKgor
ICogVGhpcyBmdW5jdGlvbiBtdXN0IGJlIGNhbGxlZCBmcm9tIGEgY29udGV4dCB3aGVyZSBwb29s
LT5sb2NrIGlzCisgKiBhbHJlYWR5IGFjcXVpcmVkCisgKi8KKyNkZWZpbmUgeG1lbV9wb29sX2No
ZWNrX3VubG9ja2VkKF9fcG9vbCkgX194bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoX19GSUxFX18s
IF9fTElORV9fLCBfX3Bvb2wpCitzdGF0aWMgaW50IF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2Vk
KGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBjb25zdCBzdHJ1Y3QgeG1lbV9wb29sICpwb29s
KQoreworICAgIGludCBpOworICAgIGludCB3b29wcyA9IDA7CisgICAgc3RhdGljIGludCBvbmNl
ID0gMTsKKworICAgIGZvciAoIGkgPSAwOyBpIDwgUkVBTF9GTEk7IGkrKyApCisgICAgeworICAg
ICAgICBpbnQgZmwgPSAoIHBvb2wtPmZsX2JpdG1hcCAmICgxIDw8IGkpICkgPyBpIDogLTE7CisK
KyAgICAgICAgaWYgKCBmbCA+PSAwICkKKyAgICAgICAgeworICAgICAgICAgICAgaW50IGo7Cisg
ICAgICAgICAgICBpbnQgYml0bWFwX2VtcHR5ID0gMTsKKyAgICAgICAgICAgIGludCBtYXRyaXhf
ZW1wdHkgPSAxOworCisgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IE1BWF9TTEk7IGorKyAp
CisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgaW50IHNsID0gKCBwb29sLT5zbF9iaXRt
YXBbZmxdICYgKDEgPDwgaikgKSA/IGogOiAtMTsKKworICAgICAgICAgICAgICAgIGlmICggc2wg
PCAwICkKKyAgICAgICAgICAgICAgICAgICAgY29udGludWU7CisKKyAgICAgICAgICAgICAgICBp
ZiAoIG9uY2UgJiYgIXBvb2wtPm1hdHJpeFtmbF1bc2xdICkKKyAgICAgICAgICAgICAgICB7Cisg
ICAgICAgICAgICAgICAgICAgIC8qIFRoZSBiaXRtYXAgaXMgY29ycnVwdGVkICovCisgICAgICAg
ICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4bWVtX3Bvb2w6JXM6JWQgdGhlIFRMU0Yg
Yml0bWFwIGlzIGNvcnJ1cHRlZFxuIiwgZmlsZSwgbGluZSk7CisgICAgICAgICAgICAgICAgICAg
IF9fd2FybigoY2hhciAqKWZpbGUsIGxpbmUpOworICAgICAgICAgICAgICAgICAgICBvbmNlID0g
MDsKKyAgICAgICAgICAgICAgICAgICAgd29vcHMgPSAxOworICAgICAgICAgICAgICAgIH0KKyAg
ICAgICAgICAgICAgICBlbHNlIGlmICggb25jZSAmJiAheG1lbV9wb29sX2NoZWNrX3NpemUocG9v
bC0+bWF0cml4W2ZsXVtzbF0sIGZsLCBzbCkpCisgICAgICAgICAgICAgICAgeworICAgICAgICAg
ICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9wb29sOiVzOiVkIHRoZSBUTFNGIGNo
dW5rIG1hdHJpeCBpcyBjb3JydXB0ZWRcbiIsIGZpbGUsIGxpbmUpOworICAgICAgICAgICAgICAg
ICAgICBfX3dhcm4oKGNoYXIgKilmaWxlLCBsaW5lKTsKKyAgICAgICAgICAgICAgICAgICAgb25j
ZSA9IDA7CisgICAgICAgICAgICAgICAgICAgIHdvb3BzID0gMTsKKyAgICAgICAgICAgICAgICB9
CisgICAgICAgICAgICAgICAgaWYgKCBwb29sLT5tYXRyaXhbZmxdW3NsXSApCisgICAgICAgICAg
ICAgICAgICAgIG1hdHJpeF9lbXB0eSA9IDA7CisgICAgICAgICAgICAgICAgYml0bWFwX2VtcHR5
ID0gMDsKKyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGlmICggb25jZSAmJiBiaXRtYXBfZW1w
dHkgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIC8qIFRoZSBiaXRtYXAgaXMgY29y
cnVwdGVkICovCisgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInhtZW1fcG9vbDol
czolZCB0aGUgVExTRiBiaXRtYXAgaXMgY29ycnVwdGVkIChub24tZW1wdHkgRkwgd2l0aCBlbXB0
eSBTTClcbiIsIGZpbGUsIGxpbmUpOworICAgICAgICAgICAgICAgIF9fd2FybigoY2hhciAqKWZp
bGUsIGxpbmUpOworICAgICAgICAgICAgICAgIG9uY2UgPSAwOworICAgICAgICAgICAgICAgIHdv
b3BzID0gMTsKKyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGlmICggb25jZSAmJiBtYXRyaXhf
ZW1wdHkgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIC8qIFRoZSBiaXRtYXAgaXMg
Y29ycnVwdGVkICovCisgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInhtZW1fcG9v
bDolczolZCB0aGUgVExTRiBiaXRtYXAgaXMgY29ycnVwdGVkIChlbXB0eSBtYXRyaXgpXG4iLCBm
aWxlLCBsaW5lKTsKKyAgICAgICAgICAgICAgICBfX3dhcm4oKGNoYXIgKilmaWxlLCBsaW5lKTsK
KyAgICAgICAgICAgICAgICBvbmNlID0gMDsKKyAgICAgICAgICAgICAgICB3b29wcyA9IDE7Cisg
ICAgICAgICAgICB9CisgICAgICAgIH0KKyAgICB9CisKKyAgICByZXR1cm4gd29vcHM7Cit9CisK
KyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChfX3Bvb2wpIF9feG1lbV9wb29sX2NoZWNr
X2xvY2tlZChfX0ZJTEVfXywgX19MSU5FX18sIF9fcG9vbCkKK3N0YXRpYyBpbnQgX194bWVtX3Bv
b2xfY2hlY2tfbG9ja2VkKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBzdHJ1Y3QgeG1lbV9w
b29sICpwb29sKQoreworICAgIGludCBlcnI7CisKKyAgICBzcGluX2xvY2soJnBvb2wtPmxvY2sp
OworICAgIGVyciA9IF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wp
OworICAgIHNwaW5fdW5sb2NrKCZwb29sLT5sb2NrKTsKKyAgICByZXR1cm4gZXJyOworfQorCitp
bnQgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpCit7CisgICAg
cmV0dXJuIF9feG1lbV9wb29sX2NoZWNrX2xvY2tlZChmaWxlLCBsaW5lLCB4ZW5wb29sKTsKK30K
KyNlbHNlCisjZGVmaW5lIHhtZW1fcG9vbF9jaGVja19sb2NrZWQoX19wb29sKSBkbyB7IGlmICgg
MCAmJiAoX19wb29sKSApOyB9IHdoaWxlICgwKQorI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfdW5s
b2NrZWQoX19wb29sKSBkbyB7IGlmICggMCAmJiAoX19wb29sKSApOyB9IHdoaWxlICgwKQorI2Vu
ZGlmCiAKIC8qKgogICogUmV0dXJucyBpbmRleGVzIChmbCwgc2wpIG9mIHRoZSBsaXN0IHVzZWQg
dG8gc2VydmUgcmVxdWVzdCBvZiBzaXplIHIKQEAgLTM4MSw2ICs0OTIsOCBAQCB2b2lkICp4bWVt
X3Bvb2xfYWxsb2ModW5zaWduZWQgbG9uZyBzaXplLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQog
ICAgIGludCBmbCwgc2w7CiAgICAgdW5zaWduZWQgbG9uZyB0bXBfc2l6ZTsKIAorICAgIHhtZW1f
cG9vbF9jaGVja19sb2NrZWQocG9vbCk7CisKICAgICBpZiAoIHBvb2wtPmluaXRfcmVnaW9uID09
IE5VTEwgKQogICAgIHsKICAgICAgICAgaWYgKCAocmVnaW9uID0gcG9vbC0+Z2V0X21lbShwb29s
LT5pbml0X3NpemUpKSA9PSBOVUxMICkKQEAgLTQ0MiwxMSArNTU1LDEzIEBAIHZvaWQgKnhtZW1f
cG9vbF9hbGxvYyh1bnNpZ25lZCBsb25nIHNpemUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCiAK
ICAgICBwb29sLT51c2VkX3NpemUgKz0gKGItPnNpemUgJiBCTE9DS19TSVpFX01BU0spICsgQkhE
Ul9PVkVSSEVBRDsKIAorICAgIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChwb29sKTsKICAgICBz
cGluX3VubG9jaygmcG9vbC0+bG9jayk7CiAgICAgcmV0dXJuICh2b2lkICopYi0+cHRyLmJ1ZmZl
cjsKIAogICAgIC8qIEZhaWxlZCBhbGxvYyAqLwogIG91dF9sb2NrZWQ6CisgICAgeG1lbV9wb29s
X2NoZWNrX3VubG9ja2VkKHBvb2wpOwogICAgIHNwaW5fdW5sb2NrKCZwb29sLT5sb2NrKTsKIAog
IG91dDoKQEAgLTQ2NCw2ICs1NzksNyBAQCB2b2lkIHhtZW1fcG9vbF9mcmVlKHZvaWQgKnB0ciwg
c3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKICAgICBiID0gKHN0cnVjdCBiaGRyICopKChjaGFyICop
IHB0ciAtIEJIRFJfT1ZFUkhFQUQpOwogCiAgICAgc3Bpbl9sb2NrKCZwb29sLT5sb2NrKTsKKyAg
ICB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQocG9vbCk7CiAgICAgYi0+c2l6ZSB8PSBGUkVFX0JM
T0NLOwogICAgIHBvb2wtPnVzZWRfc2l6ZSAtPSAoYi0+c2l6ZSAmIEJMT0NLX1NJWkVfTUFTSykg
KyBCSERSX09WRVJIRUFEOwogICAgIGItPnB0ci5mcmVlX3B0ciA9IChzdHJ1Y3QgZnJlZV9wdHIp
IHsgTlVMTCwgTlVMTH07CkBAIC01MDAsNiArNjE2LDcgQEAgdm9pZCB4bWVtX3Bvb2xfZnJlZSh2
b2lkICpwdHIsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCiAgICAgdG1wX2ItPnNpemUgfD0gUFJF
Vl9GUkVFOwogICAgIHRtcF9iLT5wcmV2X2hkciA9IGI7CiAgb3V0OgorICAgIHhtZW1fcG9vbF9j
aGVja191bmxvY2tlZChwb29sKTsKICAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7CiB9CiAK
QEAgLTUxMiw4ICs2MjksNiBAQCBpbnQgeG1lbV9wb29sX21heGFsbG9jKHN0cnVjdCB4bWVtX3Bv
b2wgKnBvb2wpCiAgKiBHbHVlIGZvciB4bWFsbG9jKCkuCiAgKi8KIAotc3RhdGljIHN0cnVjdCB4
bWVtX3Bvb2wgKnhlbnBvb2w7Ci0KIHN0YXRpYyB2b2lkICp4bWFsbG9jX3Bvb2xfZ2V0KHVuc2ln
bmVkIGxvbmcgc2l6ZSkKIHsKICAgICBBU1NFUlQoc2l6ZSA9PSBQQUdFX1NJWkUpOwpkaWZmIC0t
Z2l0IGEveGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaCBiL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9j
LmgKaW5kZXggMjRhOTlhYy4uNjI2ZWFkMCAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUveGVuL3ht
YWxsb2MuaAorKysgYi94ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCkBAIC0xMjMsNCArMTIzLDEx
IEBAIHVuc2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF91c2VkX3NpemUoc3RydWN0IHhtZW1fcG9v
bCAqcG9vbCk7CiAgKi8KIHVuc2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF90b3RhbF9zaXplKHN0
cnVjdCB4bWVtX3Bvb2wgKnBvb2wpOwogCisjaWZuZGVmIE5ERUJVRworI2RlZmluZSB4bWVtX3Bv
b2xfY2hlY2soKSBfX3htZW1fcG9vbF9jaGVjayhfX0ZJTEVfXywgX19MSU5FX18pCitpbnQgX194
bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpOworI2Vsc2UKKyNkZWZp
bmUgeG1lbV9wb29sX2NoZWNrKCkgZG8geyBpZiAoIDAgKTsgfSB3aGlsZSAoMCkKKyNlbmRpZgor
CiAjZW5kaWYgLyogX19YTUFMTE9DX0hfXyAqLwotLSAKMi4yLjAKCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Dec 04 17:02:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 17: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 1XwZmu-0002gR-TR; Thu, 04 Dec 2014 17:01:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XwZmt-0002gM-Dx
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 17:01:55 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	12/D0-19763-28390845; Thu, 04 Dec 2014 17:01:54 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417712513!8253460!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 9093 invoked from network); 4 Dec 2014 17:01:54 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Dec 2014 17:01:54 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=Svm+YhdyIE8eMYJ8SXxYEC9PH+3m45Qbq9kk7of34fZbIBQJvev6fQbqnbu5Pk1GvL9VuhkOqGjUJffYZhrOT61RMI07J+WweeTaa3AeOqVnPHlhLRHjd89tlZFRKsBXMZOOQkO2CHKnZu/rRncXGv+IEZxAAN7p0uK7sUTA0BKOLNh2p+cgpzCQqQey+FGFlu7EVeWFeKBwDXMAYNUTuu9bTm4AVyZEVQLvp53cYSPG1gUPE/mnODIEEd1g+nxB/oHPVFs5Gj4v9EfaTimX8vhaAX+LuXp7YIHGkr1A4CiFcCOtz8H/CZf5zriDvLq6c5fz9BDUkHj2iRu4/u4hZg==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:MIME-Version: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=from:to
	:cc:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=C/3f/9vL8KCEvBjmdy/aCW
	XY788=; b=QJXxlDgkITZRsJxlsBvV2pZd5Tsl3NfownVEECJl/M6FyVuQUdErfu
	1uJ14W2W2Ozjqr8poNIt7sQYtuaI1vSG78pD5POt3cSuuarPDDBU4k/+vOD4Lh8p
	3vYtRs+oRJ/th7iH1OTJXtoZExWgg+6BfDeVk3MT2MKEgSygyNd/DSNro7NW78/6
	chjoakOaNsnADfrOSwbhG92g2mXvfloYvEViDesY97uPXbvo7AInnyEr3emO5weH
	wsyPiPhOu23dUpmzu9TTeHJL8/WCocpfyF5zFI/ys0c5VFuXtmS8RZfWJ1pZx74J
	0lowGIy2uFbUPyhK5GYokXRZ1YtPQiMg==
Received: (qmail 25239 invoked from network); 4 Dec 2014 19:01:52 +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 Dec 2014 19:01:52 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 037CC803F8
	for <xen-devel@lists.xenproject.org>;
	Thu,  4 Dec 2014 19:01:52 +0200 (EET)
Received: (qmail 25572 invoked from network); 4 Dec 2014 19:01:51 +0200
Received: from unknown (HELO mdontu-l.dsd.bitdefender.biz)
	(mdontu@bitdefender.com@91.199.104.6)
	by smtp03.buh.bitdefender.org with SMTP; 4 Dec 2014 19:01:51 +0200
From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
To: xen-devel@lists.xenproject.org
Date: Thu,  4 Dec 2014 19:01:40 +0200
Message-Id: <1417712500-28009-1-git-send-email-mdontu@bitdefender.com>
X-Mailer: git-send-email 2.2.0
MIME-Version: 1.0
Content-Length: 8697
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.58102
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374172,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; 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.1.0; Id: 2m1ghdo.198b2oeh4.4jk5],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
Subject: [Xen-devel] [PATCH] xmalloc: add support for checking the pool
	integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SW1wbGVtZW50ZWQgeG1lbV9wb29sX2NoZWNrKCksIHhtZW1fcG9vbF9jaGVja19sb2NrZWQoKSBh
bmQKeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKCkgdG8gdmVyaXR5IHRoZSBpbnRlZ3JpdHkgb2Yg
dGhlIFRMU0YgbWF0cml4LgoKU2lnbmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0
ZGVmZW5kZXIuY29tPgotLS0KIHhlbi9jb21tb24veG1hbGxvY190bHNmLmMgfCAxMTkgKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQogeGVuL2luY2x1ZGUveGVu
L3htYWxsb2MuaCB8ICAgNyArKysKIDIgZmlsZXMgY2hhbmdlZCwgMTI0IGluc2VydGlvbnMoKyks
IDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi94bWFsbG9jX3Rsc2YuYyBi
L3hlbi9jb21tb24veG1hbGxvY190bHNmLmMKaW5kZXggYTU3NjljOS4uMDA5YmE2MCAxMDA2NDQK
LS0tIGEveGVuL2NvbW1vbi94bWFsbG9jX3Rsc2YuYworKysgYi94ZW4vY29tbW9uL3htYWxsb2Nf
dGxzZi5jCkBAIC0xMjAsOSArMTIwLDEyMCBAQCBzdHJ1Y3QgeG1lbV9wb29sIHsKICAgICBjaGFy
IG5hbWVbTUFYX1BPT0xfTkFNRV9MRU5dOwogfTsKIAorc3RhdGljIHN0cnVjdCB4bWVtX3Bvb2wg
KnhlbnBvb2w7CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBNQVBQSU5HX0lOU0VSVCh1bnNpZ25lZCBs
b25nIHIsIGludCAqZmwsIGludCAqc2wpOworCiAvKgogICogSGVscGluZyBmdW5jdGlvbnMKICAq
LworI2lmbmRlZiBOREVCVUcKK3N0YXRpYyBpbnQgeG1lbV9wb29sX2NoZWNrX3NpemUoY29uc3Qg
c3RydWN0IGJoZHIgKmIsIGludCBmbCwgaW50IHNsKQoreworICAgIHdoaWxlICggYiApCisgICAg
eworICAgICAgICBpbnQgX19mbDsKKyAgICAgICAgaW50IF9fc2w7CisKKyAgICAgICAgTUFQUElO
R19JTlNFUlQoYi0+c2l6ZSwgJl9fZmwsICZfX3NsKTsKKyAgICAgICAgaWYgKCBfX2ZsICE9IGZs
IHx8IF9fc2wgIT0gc2wgKQorICAgICAgICB7CisgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VS
UiAieG1lbV9wb29sOiBmb3IgYmxvY2sgJXAgc2l6ZSA9ICV1LCB7IGZsID0gJWQsIHNsID0gJWQg
fSBzaG91bGQgYmUgeyBmbCA9ICVkLCBzbCA9ICVkIH1cbiIsIGIsIGItPnNpemUsIGZsLCBzbCwg
X19mbCwgX19zbCk7CisgICAgICAgICAgICByZXR1cm4gMDsKKyAgICAgICAgfQorICAgICAgICBi
ID0gYi0+cHRyLmZyZWVfcHRyLm5leHQ7CisgICAgfQorICAgIHJldHVybiAxOworfQorCisvKgor
ICogVGhpcyBmdW5jdGlvbiBtdXN0IGJlIGNhbGxlZCBmcm9tIGEgY29udGV4dCB3aGVyZSBwb29s
LT5sb2NrIGlzCisgKiBhbHJlYWR5IGFjcXVpcmVkCisgKi8KKyNkZWZpbmUgeG1lbV9wb29sX2No
ZWNrX3VubG9ja2VkKF9fcG9vbCkgX194bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoX19GSUxFX18s
IF9fTElORV9fLCBfX3Bvb2wpCitzdGF0aWMgaW50IF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2Vk
KGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBjb25zdCBzdHJ1Y3QgeG1lbV9wb29sICpwb29s
KQoreworICAgIGludCBpOworICAgIGludCB3b29wcyA9IDA7CisgICAgc3RhdGljIGludCBvbmNl
ID0gMTsKKworICAgIGZvciAoIGkgPSAwOyBpIDwgUkVBTF9GTEk7IGkrKyApCisgICAgeworICAg
ICAgICBpbnQgZmwgPSAoIHBvb2wtPmZsX2JpdG1hcCAmICgxIDw8IGkpICkgPyBpIDogLTE7CisK
KyAgICAgICAgaWYgKCBmbCA+PSAwICkKKyAgICAgICAgeworICAgICAgICAgICAgaW50IGo7Cisg
ICAgICAgICAgICBpbnQgYml0bWFwX2VtcHR5ID0gMTsKKyAgICAgICAgICAgIGludCBtYXRyaXhf
ZW1wdHkgPSAxOworCisgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IE1BWF9TTEk7IGorKyAp
CisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgaW50IHNsID0gKCBwb29sLT5zbF9iaXRt
YXBbZmxdICYgKDEgPDwgaikgKSA/IGogOiAtMTsKKworICAgICAgICAgICAgICAgIGlmICggc2wg
PCAwICkKKyAgICAgICAgICAgICAgICAgICAgY29udGludWU7CisKKyAgICAgICAgICAgICAgICBp
ZiAoIG9uY2UgJiYgIXBvb2wtPm1hdHJpeFtmbF1bc2xdICkKKyAgICAgICAgICAgICAgICB7Cisg
ICAgICAgICAgICAgICAgICAgIC8qIFRoZSBiaXRtYXAgaXMgY29ycnVwdGVkICovCisgICAgICAg
ICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4bWVtX3Bvb2w6JXM6JWQgdGhlIFRMU0Yg
Yml0bWFwIGlzIGNvcnJ1cHRlZFxuIiwgZmlsZSwgbGluZSk7CisgICAgICAgICAgICAgICAgICAg
IF9fd2FybigoY2hhciAqKWZpbGUsIGxpbmUpOworICAgICAgICAgICAgICAgICAgICBvbmNlID0g
MDsKKyAgICAgICAgICAgICAgICAgICAgd29vcHMgPSAxOworICAgICAgICAgICAgICAgIH0KKyAg
ICAgICAgICAgICAgICBlbHNlIGlmICggb25jZSAmJiAheG1lbV9wb29sX2NoZWNrX3NpemUocG9v
bC0+bWF0cml4W2ZsXVtzbF0sIGZsLCBzbCkpCisgICAgICAgICAgICAgICAgeworICAgICAgICAg
ICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9wb29sOiVzOiVkIHRoZSBUTFNGIGNo
dW5rIG1hdHJpeCBpcyBjb3JydXB0ZWRcbiIsIGZpbGUsIGxpbmUpOworICAgICAgICAgICAgICAg
ICAgICBfX3dhcm4oKGNoYXIgKilmaWxlLCBsaW5lKTsKKyAgICAgICAgICAgICAgICAgICAgb25j
ZSA9IDA7CisgICAgICAgICAgICAgICAgICAgIHdvb3BzID0gMTsKKyAgICAgICAgICAgICAgICB9
CisgICAgICAgICAgICAgICAgaWYgKCBwb29sLT5tYXRyaXhbZmxdW3NsXSApCisgICAgICAgICAg
ICAgICAgICAgIG1hdHJpeF9lbXB0eSA9IDA7CisgICAgICAgICAgICAgICAgYml0bWFwX2VtcHR5
ID0gMDsKKyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGlmICggb25jZSAmJiBiaXRtYXBfZW1w
dHkgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIC8qIFRoZSBiaXRtYXAgaXMgY29y
cnVwdGVkICovCisgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInhtZW1fcG9vbDol
czolZCB0aGUgVExTRiBiaXRtYXAgaXMgY29ycnVwdGVkIChub24tZW1wdHkgRkwgd2l0aCBlbXB0
eSBTTClcbiIsIGZpbGUsIGxpbmUpOworICAgICAgICAgICAgICAgIF9fd2FybigoY2hhciAqKWZp
bGUsIGxpbmUpOworICAgICAgICAgICAgICAgIG9uY2UgPSAwOworICAgICAgICAgICAgICAgIHdv
b3BzID0gMTsKKyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGlmICggb25jZSAmJiBtYXRyaXhf
ZW1wdHkgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIC8qIFRoZSBiaXRtYXAgaXMg
Y29ycnVwdGVkICovCisgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInhtZW1fcG9v
bDolczolZCB0aGUgVExTRiBiaXRtYXAgaXMgY29ycnVwdGVkIChlbXB0eSBtYXRyaXgpXG4iLCBm
aWxlLCBsaW5lKTsKKyAgICAgICAgICAgICAgICBfX3dhcm4oKGNoYXIgKilmaWxlLCBsaW5lKTsK
KyAgICAgICAgICAgICAgICBvbmNlID0gMDsKKyAgICAgICAgICAgICAgICB3b29wcyA9IDE7Cisg
ICAgICAgICAgICB9CisgICAgICAgIH0KKyAgICB9CisKKyAgICByZXR1cm4gd29vcHM7Cit9CisK
KyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChfX3Bvb2wpIF9feG1lbV9wb29sX2NoZWNr
X2xvY2tlZChfX0ZJTEVfXywgX19MSU5FX18sIF9fcG9vbCkKK3N0YXRpYyBpbnQgX194bWVtX3Bv
b2xfY2hlY2tfbG9ja2VkKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBzdHJ1Y3QgeG1lbV9w
b29sICpwb29sKQoreworICAgIGludCBlcnI7CisKKyAgICBzcGluX2xvY2soJnBvb2wtPmxvY2sp
OworICAgIGVyciA9IF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wp
OworICAgIHNwaW5fdW5sb2NrKCZwb29sLT5sb2NrKTsKKyAgICByZXR1cm4gZXJyOworfQorCitp
bnQgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpCit7CisgICAg
cmV0dXJuIF9feG1lbV9wb29sX2NoZWNrX2xvY2tlZChmaWxlLCBsaW5lLCB4ZW5wb29sKTsKK30K
KyNlbHNlCisjZGVmaW5lIHhtZW1fcG9vbF9jaGVja19sb2NrZWQoX19wb29sKSBkbyB7IGlmICgg
MCAmJiAoX19wb29sKSApOyB9IHdoaWxlICgwKQorI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfdW5s
b2NrZWQoX19wb29sKSBkbyB7IGlmICggMCAmJiAoX19wb29sKSApOyB9IHdoaWxlICgwKQorI2Vu
ZGlmCiAKIC8qKgogICogUmV0dXJucyBpbmRleGVzIChmbCwgc2wpIG9mIHRoZSBsaXN0IHVzZWQg
dG8gc2VydmUgcmVxdWVzdCBvZiBzaXplIHIKQEAgLTM4MSw2ICs0OTIsOCBAQCB2b2lkICp4bWVt
X3Bvb2xfYWxsb2ModW5zaWduZWQgbG9uZyBzaXplLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQog
ICAgIGludCBmbCwgc2w7CiAgICAgdW5zaWduZWQgbG9uZyB0bXBfc2l6ZTsKIAorICAgIHhtZW1f
cG9vbF9jaGVja19sb2NrZWQocG9vbCk7CisKICAgICBpZiAoIHBvb2wtPmluaXRfcmVnaW9uID09
IE5VTEwgKQogICAgIHsKICAgICAgICAgaWYgKCAocmVnaW9uID0gcG9vbC0+Z2V0X21lbShwb29s
LT5pbml0X3NpemUpKSA9PSBOVUxMICkKQEAgLTQ0MiwxMSArNTU1LDEzIEBAIHZvaWQgKnhtZW1f
cG9vbF9hbGxvYyh1bnNpZ25lZCBsb25nIHNpemUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCiAK
ICAgICBwb29sLT51c2VkX3NpemUgKz0gKGItPnNpemUgJiBCTE9DS19TSVpFX01BU0spICsgQkhE
Ul9PVkVSSEVBRDsKIAorICAgIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChwb29sKTsKICAgICBz
cGluX3VubG9jaygmcG9vbC0+bG9jayk7CiAgICAgcmV0dXJuICh2b2lkICopYi0+cHRyLmJ1ZmZl
cjsKIAogICAgIC8qIEZhaWxlZCBhbGxvYyAqLwogIG91dF9sb2NrZWQ6CisgICAgeG1lbV9wb29s
X2NoZWNrX3VubG9ja2VkKHBvb2wpOwogICAgIHNwaW5fdW5sb2NrKCZwb29sLT5sb2NrKTsKIAog
IG91dDoKQEAgLTQ2NCw2ICs1NzksNyBAQCB2b2lkIHhtZW1fcG9vbF9mcmVlKHZvaWQgKnB0ciwg
c3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKICAgICBiID0gKHN0cnVjdCBiaGRyICopKChjaGFyICop
IHB0ciAtIEJIRFJfT1ZFUkhFQUQpOwogCiAgICAgc3Bpbl9sb2NrKCZwb29sLT5sb2NrKTsKKyAg
ICB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQocG9vbCk7CiAgICAgYi0+c2l6ZSB8PSBGUkVFX0JM
T0NLOwogICAgIHBvb2wtPnVzZWRfc2l6ZSAtPSAoYi0+c2l6ZSAmIEJMT0NLX1NJWkVfTUFTSykg
KyBCSERSX09WRVJIRUFEOwogICAgIGItPnB0ci5mcmVlX3B0ciA9IChzdHJ1Y3QgZnJlZV9wdHIp
IHsgTlVMTCwgTlVMTH07CkBAIC01MDAsNiArNjE2LDcgQEAgdm9pZCB4bWVtX3Bvb2xfZnJlZSh2
b2lkICpwdHIsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCiAgICAgdG1wX2ItPnNpemUgfD0gUFJF
Vl9GUkVFOwogICAgIHRtcF9iLT5wcmV2X2hkciA9IGI7CiAgb3V0OgorICAgIHhtZW1fcG9vbF9j
aGVja191bmxvY2tlZChwb29sKTsKICAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7CiB9CiAK
QEAgLTUxMiw4ICs2MjksNiBAQCBpbnQgeG1lbV9wb29sX21heGFsbG9jKHN0cnVjdCB4bWVtX3Bv
b2wgKnBvb2wpCiAgKiBHbHVlIGZvciB4bWFsbG9jKCkuCiAgKi8KIAotc3RhdGljIHN0cnVjdCB4
bWVtX3Bvb2wgKnhlbnBvb2w7Ci0KIHN0YXRpYyB2b2lkICp4bWFsbG9jX3Bvb2xfZ2V0KHVuc2ln
bmVkIGxvbmcgc2l6ZSkKIHsKICAgICBBU1NFUlQoc2l6ZSA9PSBQQUdFX1NJWkUpOwpkaWZmIC0t
Z2l0IGEveGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaCBiL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9j
LmgKaW5kZXggMjRhOTlhYy4uNjI2ZWFkMCAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUveGVuL3ht
YWxsb2MuaAorKysgYi94ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCkBAIC0xMjMsNCArMTIzLDEx
IEBAIHVuc2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF91c2VkX3NpemUoc3RydWN0IHhtZW1fcG9v
bCAqcG9vbCk7CiAgKi8KIHVuc2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF90b3RhbF9zaXplKHN0
cnVjdCB4bWVtX3Bvb2wgKnBvb2wpOwogCisjaWZuZGVmIE5ERUJVRworI2RlZmluZSB4bWVtX3Bv
b2xfY2hlY2soKSBfX3htZW1fcG9vbF9jaGVjayhfX0ZJTEVfXywgX19MSU5FX18pCitpbnQgX194
bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpOworI2Vsc2UKKyNkZWZp
bmUgeG1lbV9wb29sX2NoZWNrKCkgZG8geyBpZiAoIDAgKTsgfSB3aGlsZSAoMCkKKyNlbmRpZgor
CiAjZW5kaWYgLyogX19YTUFMTE9DX0hfXyAqLwotLSAKMi4yLjAKCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Dec 04 17:05:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 17:05:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZq1-0002rV-GV; Thu, 04 Dec 2014 17:05: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 1XwZpz-0002rB-Ka
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 17:05:07 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	CF/F0-02696-34490845; Thu, 04 Dec 2014 17:05:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417712706!13042798!1
X-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 31597 invoked from network); 4 Dec 2014 17:05:06 -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 Dec 2014 17:05:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 17:05:05 +0000
Message-Id: <5480A251020000780004CE14@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 17:05:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-17-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-17-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 16/17] xen/vtd: group assigned device
	with RMRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -572,10 +572,11 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>  {
>      struct acpi_dmar_reserved_memory *rmrr =
>          container_of(header, struct acpi_dmar_reserved_memory, header);
> -    struct acpi_rmrr_unit *rmrru;
> +    struct acpi_rmrr_unit *rmrru, *cur_rmrr;
>      void *dev_scope_start, *dev_scope_end;
>      u64 base_addr = rmrr->base_address, end_addr = rmrr->end_address;
>      int ret;
> +    static unsigned int group_id = 0;

__initdata. Pointless initializer.

> @@ -682,7 +685,30 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>                      "So please set pci_rdmforce to reserve these ranges"
>                      " if you need such a device in hotplug case.\n");
>  
> +            list_for_each_entry(cur_rmrr, &acpi_rmrr_units, list)
> +            {
> +                /*
> +                 * Any same or overlap range mean they should be
> +                 * at same group.
> +                 */
> +                if ( ((base_addr >= cur_rmrr->base_address) &&
> +                     (end_addr <= cur_rmrr->end_address)) ||
> +                     ((base_addr <= cur_rmrr->base_address) &&
> +                     (end_addr >= cur_rmrr->end_address)) )

This is both more complicated than needed and wrong. You want
an overlap (partial or complete doesn't matter) check, i.e.
start1 <= end2 && start2 <= end1.

> +                {
> +                    rmrru->gid = cur_rmrr->gid;
> +                    continue;

break

Also this doesn't seem to handle cases where you see in this order

[2,3]
[4,6]
[3,5]

But the more fundamental question is: Are overlaps of RMRRs
actually allowed, or would it not better to bail in that case and
leave the IOMMU disabled?

But the code further down looks so broken that I'll leave to you
to discuss this with your colleagues acting as VT-d maintainers.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 17:05:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 17:05:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZq1-0002rV-GV; Thu, 04 Dec 2014 17:05: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 1XwZpz-0002rB-Ka
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 17:05:07 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	CF/F0-02696-34490845; Thu, 04 Dec 2014 17:05:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417712706!13042798!1
X-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 31597 invoked from network); 4 Dec 2014 17:05:06 -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 Dec 2014 17:05:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 17:05:05 +0000
Message-Id: <5480A251020000780004CE14@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 17:05:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-17-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1417425875-9634-17-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 16/17] xen/vtd: group assigned device
	with RMRR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -572,10 +572,11 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>  {
>      struct acpi_dmar_reserved_memory *rmrr =
>          container_of(header, struct acpi_dmar_reserved_memory, header);
> -    struct acpi_rmrr_unit *rmrru;
> +    struct acpi_rmrr_unit *rmrru, *cur_rmrr;
>      void *dev_scope_start, *dev_scope_end;
>      u64 base_addr = rmrr->base_address, end_addr = rmrr->end_address;
>      int ret;
> +    static unsigned int group_id = 0;

__initdata. Pointless initializer.

> @@ -682,7 +685,30 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>                      "So please set pci_rdmforce to reserve these ranges"
>                      " if you need such a device in hotplug case.\n");
>  
> +            list_for_each_entry(cur_rmrr, &acpi_rmrr_units, list)
> +            {
> +                /*
> +                 * Any same or overlap range mean they should be
> +                 * at same group.
> +                 */
> +                if ( ((base_addr >= cur_rmrr->base_address) &&
> +                     (end_addr <= cur_rmrr->end_address)) ||
> +                     ((base_addr <= cur_rmrr->base_address) &&
> +                     (end_addr >= cur_rmrr->end_address)) )

This is both more complicated than needed and wrong. You want
an overlap (partial or complete doesn't matter) check, i.e.
start1 <= end2 && start2 <= end1.

> +                {
> +                    rmrru->gid = cur_rmrr->gid;
> +                    continue;

break

Also this doesn't seem to handle cases where you see in this order

[2,3]
[4,6]
[3,5]

But the more fundamental question is: Are overlaps of RMRRs
actually allowed, or would it not better to bail in that case and
leave the IOMMU disabled?

But the code further down looks so broken that I'll leave to you
to discuss this with your colleagues acting as VT-d maintainers.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 17:10:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 17: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 1XwZuw-0003DV-7x; Thu, 04 Dec 2014 17:10:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XwZuu-0003D6-VT
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 17:10:13 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	0C/86-27584-47590845; Thu, 04 Dec 2014 17:10:12 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417713010!11604876!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 3705 invoked from network); 4 Dec 2014 17:10:11 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 17:10:11 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=ERgT4t+ej46uXUEle0RZGzXHNjUlsTN42SnyGMl7/Q4FXZjYEHx/iiPnAaxg7bVfo3lXivYtVIfiNAmys+uPpckzdFGPWdxOgnOZBCdqXt5QTAKB4Orl7toCgAvzD/7DwrVMDRQSOx3QoZt0PvKnT6kPIT10i7X6Sw00gdtnIYj/7fJFKtMMpFEbKZXmk3ieBQ++VJDrBEsF3DT26aQqivCGfyLVY3DNcmB3sGy50Jvg/hvFcSBRgJF13aW5m+ki9AhIewHiNIy0PwOQMH2WTgLAllzAcIma/GbOlDFlKWfeWNO1+jgKohSeFQ9LrSKLkM9LBOVyknSTzUfqdJ1oqg==;
	h=Received:Received:Received:Received:Received:Date:From:To:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:subject:message-id:in-reply-to:references:mime-version
	:content-type:content-transfer-encoding; s=default; bh=GIjQMFIPh
	C4mVkYd9UhnFSX5csw=; b=oH4LjwVtk2mVwgmftZWk9NDvhk5Ks6iWtFkB5yoFM
	bY2QfX93teBELY3tRS+757ewYbJYHjNB2UbKQh9tWTFMG6r36O82k8tCcZzCUao8
	dSDhE5XupIJQAp7piik2kXnGBoJuhg/WeGu0NkBHmZg2Kh+0Cc8k0mL5TKRz5JGT
	tz8gG4ICrGDfSebdBGIAqYLz0f1ICeNHuwn5ELfBoEbsjFKDid47eCwKL/SvnRUz
	4MoQ7GA+aI6g+wuv2PftjaNBZDL1G3KogkAyX0AEPpVTGcz+kM66CGjZezZ/cPTq
	SKLVxtwPEBa8SmrOrrqGM0yk9/CEsXxiE/Us3yTF/HPYw==
Received: (qmail 27483 invoked from network); 4 Dec 2014 19:10:10 +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 Dec 2014 19:10:10 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id CB0CE803F8
	for <xen-devel@lists.xen.org>; Thu,  4 Dec 2014 19:10:09 +0200 (EET)
Received: (qmail 25747 invoked from network); 4 Dec 2014 19:10:09 +0200
Received: from unknown (HELO bitdefender.com)
	(mdontu@bitdefender.com@91.199.104.6)
	by smtp03.buh.bitdefender.org with SMTP; 4 Dec 2014 19:10:09 +0200
Date: Thu, 4 Dec 2014 19:10:09 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: xen-devel@lists.xen.org
Message-ID: <20141204191009.0434bc13@bitdefender.com>
In-Reply-To: <1417712500-28009-1-git-send-email-mdontu@bitdefender.com>
References: <1417712500-28009-1-git-send-email-mdontu@bitdefender.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.58104
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374177,
	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.1.0; Id:
	2m1ghdn.198b1eaj8.8qam], total: 0(775)
X-BitDefender-CF-Stamp: none
Subject: Re: [Xen-devel] [PATCH] xmalloc: add support for checking the pool
 integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1cnNkYXkgMDQgRGVjZW1iZXIgMjAxNCAxOTowMTo0MCBNaWhhaSBEb27Im3Ugd3JvdGU6
Cj4gSW1wbGVtZW50ZWQgeG1lbV9wb29sX2NoZWNrKCksIHhtZW1fcG9vbF9jaGVja19sb2NrZWQo
KSBhbmQKPiB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoKSB0byB2ZXJpdHkgdGhlIGludGVncml0
eSBvZiB0aGUgVExTRiBtYXRyaXguCj4gCj4gU2lnbmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxt
ZG9udHVAYml0ZGVmZW5kZXIuY29tPgo+IC0tLQo+ICB4ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5j
IHwgMTE5ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0KPiAg
eGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaCB8ICAgNyArKysKPiAgMiBmaWxlcyBjaGFuZ2VkLCAx
MjQgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKPiAKPiBkaWZmIC0tZ2l0IGEveGVuL2Nv
bW1vbi94bWFsbG9jX3Rsc2YuYyBiL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMKPiBpbmRleCBh
NTc2OWM5Li4wMDliYTYwIDEwMDY0NAo+IC0tLSBhL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMK
PiArKysgYi94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jCj4gQEAgLTEyMCw5ICsxMjAsMTIwIEBA
IHN0cnVjdCB4bWVtX3Bvb2wgewo+ICAgICAgY2hhciBuYW1lW01BWF9QT09MX05BTUVfTEVOXTsK
PiAgfTsKPiAgCj4gK3N0YXRpYyBzdHJ1Y3QgeG1lbV9wb29sICp4ZW5wb29sOwo+ICsKPiArc3Rh
dGljIGlubGluZSB2b2lkIE1BUFBJTkdfSU5TRVJUKHVuc2lnbmVkIGxvbmcgciwgaW50ICpmbCwg
aW50ICpzbCk7Cj4gKwo+ICAvKgo+ICAgKiBIZWxwaW5nIGZ1bmN0aW9ucwo+ICAgKi8KPiArI2lm
bmRlZiBOREVCVUcKPiArc3RhdGljIGludCB4bWVtX3Bvb2xfY2hlY2tfc2l6ZShjb25zdCBzdHJ1
Y3QgYmhkciAqYiwgaW50IGZsLCBpbnQgc2wpCj4gK3sKPiArICAgIHdoaWxlICggYiApCj4gKyAg
ICB7Cj4gKyAgICAgICAgaW50IF9fZmw7Cj4gKyAgICAgICAgaW50IF9fc2w7Cj4gKwo+ICsgICAg
ICAgIE1BUFBJTkdfSU5TRVJUKGItPnNpemUsICZfX2ZsLCAmX19zbCk7Cj4gKyAgICAgICAgaWYg
KCBfX2ZsICE9IGZsIHx8IF9fc2wgIT0gc2wgKQo+ICsgICAgICAgIHsKPiArICAgICAgICAgICAg
cHJpbnRrKFhFTkxPR19FUlIgInhtZW1fcG9vbDogZm9yIGJsb2NrICVwIHNpemUgPSAldSwgeyBm
bCA9ICVkLCBzbCA9ICVkIH0gc2hvdWxkIGJlIHsgZmwgPSAlZCwgc2wgPSAlZCB9XG4iLCBiLCBi
LT5zaXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOwo+ICsgICAgICAgICAgICByZXR1cm4gMDsKPiAr
ICAgICAgICB9Cj4gKyAgICAgICAgYiA9IGItPnB0ci5mcmVlX3B0ci5uZXh0Owo+ICsgICAgfQo+
ICsgICAgcmV0dXJuIDE7Cj4gK30KPiArCj4gKy8qCj4gKyAqIFRoaXMgZnVuY3Rpb24gbXVzdCBi
ZSBjYWxsZWQgZnJvbSBhIGNvbnRleHQgd2hlcmUgcG9vbC0+bG9jayBpcwo+ICsgKiBhbHJlYWR5
IGFjcXVpcmVkCj4gKyAqLwo+ICsjZGVmaW5lIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChfX3Bv
b2wpIF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKF9fRklMRV9fLCBfX0xJTkVfXywgX19wb29s
KQo+ICtzdGF0aWMgaW50IF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKGNvbnN0IGNoYXIgKmZp
bGUsIGludCBsaW5lLCBjb25zdCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ICt7Cj4gKyAgICBp
bnQgaTsKPiArICAgIGludCB3b29wcyA9IDA7Cj4gKyAgICBzdGF0aWMgaW50IG9uY2UgPSAxOwo+
ICsKPiArICAgIGZvciAoIGkgPSAwOyBpIDwgUkVBTF9GTEk7IGkrKyApCj4gKyAgICB7Cj4gKyAg
ICAgICAgaW50IGZsID0gKCBwb29sLT5mbF9iaXRtYXAgJiAoMSA8PCBpKSApID8gaSA6IC0xOwo+
ICsKPiArICAgICAgICBpZiAoIGZsID49IDAgKQo+ICsgICAgICAgIHsKPiArICAgICAgICAgICAg
aW50IGo7Cj4gKyAgICAgICAgICAgIGludCBiaXRtYXBfZW1wdHkgPSAxOwo+ICsgICAgICAgICAg
ICBpbnQgbWF0cml4X2VtcHR5ID0gMTsKPiArCj4gKyAgICAgICAgICAgIGZvciAoIGogPSAwOyBq
IDwgTUFYX1NMSTsgaisrICkKPiArICAgICAgICAgICAgewo+ICsgICAgICAgICAgICAgICAgaW50
IHNsID0gKCBwb29sLT5zbF9iaXRtYXBbZmxdICYgKDEgPDwgaikgKSA/IGogOiAtMTsKPiArCj4g
KyAgICAgICAgICAgICAgICBpZiAoIHNsIDwgMCApCj4gKyAgICAgICAgICAgICAgICAgICAgY29u
dGludWU7Cj4gKwo+ICsgICAgICAgICAgICAgICAgaWYgKCBvbmNlICYmICFwb29sLT5tYXRyaXhb
ZmxdW3NsXSApCj4gKyAgICAgICAgICAgICAgICB7Cj4gKyAgICAgICAgICAgICAgICAgICAgLyog
VGhlIGJpdG1hcCBpcyBjb3JydXB0ZWQgKi8KPiArICAgICAgICAgICAgICAgICAgICBwcmludGso
WEVOTE9HX0VSUiAieG1lbV9wb29sOiVzOiVkIHRoZSBUTFNGIGJpdG1hcCBpcyBjb3JydXB0ZWRc
biIsIGZpbGUsIGxpbmUpOwo+ICsgICAgICAgICAgICAgICAgICAgIF9fd2FybigoY2hhciAqKWZp
bGUsIGxpbmUpOwo+ICsgICAgICAgICAgICAgICAgICAgIG9uY2UgPSAwOwo+ICsgICAgICAgICAg
ICAgICAgICAgIHdvb3BzID0gMTsKPiArICAgICAgICAgICAgICAgIH0KPiArICAgICAgICAgICAg
ICAgIGVsc2UgaWYgKCBvbmNlICYmICF4bWVtX3Bvb2xfY2hlY2tfc2l6ZShwb29sLT5tYXRyaXhb
ZmxdW3NsXSwgZmwsIHNsKSkKPiArICAgICAgICAgICAgICAgIHsKPiArICAgICAgICAgICAgICAg
ICAgICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9wb29sOiVzOiVkIHRoZSBUTFNGIGNodW5rIG1h
dHJpeCBpcyBjb3JydXB0ZWRcbiIsIGZpbGUsIGxpbmUpOwo+ICsgICAgICAgICAgICAgICAgICAg
IF9fd2FybigoY2hhciAqKWZpbGUsIGxpbmUpOwo+ICsgICAgICAgICAgICAgICAgICAgIG9uY2Ug
PSAwOwo+ICsgICAgICAgICAgICAgICAgICAgIHdvb3BzID0gMTsKPiArICAgICAgICAgICAgICAg
IH0KPiArICAgICAgICAgICAgICAgIGlmICggcG9vbC0+bWF0cml4W2ZsXVtzbF0gKQo+ICsgICAg
ICAgICAgICAgICAgICAgIG1hdHJpeF9lbXB0eSA9IDA7Cj4gKyAgICAgICAgICAgICAgICBiaXRt
YXBfZW1wdHkgPSAwOwo+ICsgICAgICAgICAgICB9Cj4gKyAgICAgICAgICAgIGlmICggb25jZSAm
JiBiaXRtYXBfZW1wdHkgKQo+ICsgICAgICAgICAgICB7Cj4gKyAgICAgICAgICAgICAgICAvKiBU
aGUgYml0bWFwIGlzIGNvcnJ1cHRlZCAqLwo+ICsgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxP
R19FUlIgInhtZW1fcG9vbDolczolZCB0aGUgVExTRiBiaXRtYXAgaXMgY29ycnVwdGVkIChub24t
ZW1wdHkgRkwgd2l0aCBlbXB0eSBTTClcbiIsIGZpbGUsIGxpbmUpOwo+ICsgICAgICAgICAgICAg
ICAgX193YXJuKChjaGFyICopZmlsZSwgbGluZSk7Cj4gKyAgICAgICAgICAgICAgICBvbmNlID0g
MDsKPiArICAgICAgICAgICAgICAgIHdvb3BzID0gMTsKPiArICAgICAgICAgICAgfQo+ICsgICAg
ICAgICAgICBpZiAoIG9uY2UgJiYgbWF0cml4X2VtcHR5ICkKPiArICAgICAgICAgICAgewo+ICsg
ICAgICAgICAgICAgICAgLyogVGhlIGJpdG1hcCBpcyBjb3JydXB0ZWQgKi8KPiArICAgICAgICAg
ICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4bWVtX3Bvb2w6JXM6JWQgdGhlIFRMU0YgYml0bWFw
IGlzIGNvcnJ1cHRlZCAoZW1wdHkgbWF0cml4KVxuIiwgZmlsZSwgbGluZSk7Cj4gKyAgICAgICAg
ICAgICAgICBfX3dhcm4oKGNoYXIgKilmaWxlLCBsaW5lKTsKPiArICAgICAgICAgICAgICAgIG9u
Y2UgPSAwOwo+ICsgICAgICAgICAgICAgICAgd29vcHMgPSAxOwo+ICsgICAgICAgICAgICB9Cj4g
KyAgICAgICAgfQo+ICsgICAgfQo+ICsKPiArICAgIHJldHVybiB3b29wczsKPiArfQo+ICsKPiAr
I2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKF9fcG9vbCkgX194bWVtX3Bvb2xfY2hlY2tf
bG9ja2VkKF9fRklMRV9fLCBfX0xJTkVfXywgX19wb29sKQo+ICtzdGF0aWMgaW50IF9feG1lbV9w
b29sX2NoZWNrX2xvY2tlZChjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgc3RydWN0IHhtZW1f
cG9vbCAqcG9vbCkKPiArewo+ICsgICAgaW50IGVycjsKPiArCj4gKyAgICBzcGluX2xvY2soJnBv
b2wtPmxvY2spOwo+ICsgICAgZXJyID0gX194bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoZmlsZSwg
bGluZSwgcG9vbCk7Cj4gKyAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7Cj4gKyAgICByZXR1
cm4gZXJyOwo+ICt9Cj4gKwo+ICtpbnQgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmls
ZSwgaW50IGxpbmUpCj4gK3sKPiArICAgIHJldHVybiBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQo
ZmlsZSwgbGluZSwgeGVucG9vbCk7Cj4gK30KPiArI2Vsc2UKPiArI2RlZmluZSB4bWVtX3Bvb2xf
Y2hlY2tfbG9ja2VkKF9fcG9vbCkgZG8geyBpZiAoIDAgJiYgKF9fcG9vbCkgKTsgfSB3aGlsZSAo
MCkKPiArI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoX19wb29sKSBkbyB7IGlmICgg
MCAmJiAoX19wb29sKSApOyB9IHdoaWxlICgwKQo+ICsjZW5kaWYKPiAgCj4gIC8qKgo+ICAgKiBS
ZXR1cm5zIGluZGV4ZXMgKGZsLCBzbCkgb2YgdGhlIGxpc3QgdXNlZCB0byBzZXJ2ZSByZXF1ZXN0
IG9mIHNpemUgcgo+IEBAIC0zODEsNiArNDkyLDggQEAgdm9pZCAqeG1lbV9wb29sX2FsbG9jKHVu
c2lnbmVkIGxvbmcgc2l6ZSwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAgICAgIGludCBmbCwg
c2w7Cj4gICAgICB1bnNpZ25lZCBsb25nIHRtcF9zaXplOwo+ICAKPiArICAgIHhtZW1fcG9vbF9j
aGVja19sb2NrZWQocG9vbCk7Cj4gKwo+ICAgICAgaWYgKCBwb29sLT5pbml0X3JlZ2lvbiA9PSBO
VUxMICkKPiAgICAgIHsKPiAgICAgICAgICBpZiAoIChyZWdpb24gPSBwb29sLT5nZXRfbWVtKHBv
b2wtPmluaXRfc2l6ZSkpID09IE5VTEwgKQo+IEBAIC00NDIsMTEgKzU1NSwxMyBAQCB2b2lkICp4
bWVtX3Bvb2xfYWxsb2ModW5zaWduZWQgbG9uZyBzaXplLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29s
KQo+ICAKPiAgICAgIHBvb2wtPnVzZWRfc2l6ZSArPSAoYi0+c2l6ZSAmIEJMT0NLX1NJWkVfTUFT
SykgKyBCSERSX09WRVJIRUFEOwo+ICAKPiArICAgIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChw
b29sKTsKPiAgICAgIHNwaW5fdW5sb2NrKCZwb29sLT5sb2NrKTsKPiAgICAgIHJldHVybiAodm9p
ZCAqKWItPnB0ci5idWZmZXI7Cj4gIAo+ICAgICAgLyogRmFpbGVkIGFsbG9jICovCj4gICBvdXRf
bG9ja2VkOgo+ICsgICAgeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKHBvb2wpOwo+ICAgICAgc3Bp
bl91bmxvY2soJnBvb2wtPmxvY2spOwo+ICAKPiAgIG91dDoKPiBAQCAtNDY0LDYgKzU3OSw3IEBA
IHZvaWQgeG1lbV9wb29sX2ZyZWUodm9pZCAqcHRyLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+
ICAgICAgYiA9IChzdHJ1Y3QgYmhkciAqKSgoY2hhciAqKSBwdHIgLSBCSERSX09WRVJIRUFEKTsK
PiAgCj4gICAgICBzcGluX2xvY2soJnBvb2wtPmxvY2spOwo+ICsgICAgeG1lbV9wb29sX2NoZWNr
X3VubG9ja2VkKHBvb2wpOwo+ICAgICAgYi0+c2l6ZSB8PSBGUkVFX0JMT0NLOwo+ICAgICAgcG9v
bC0+dXNlZF9zaXplIC09IChiLT5zaXplICYgQkxPQ0tfU0laRV9NQVNLKSArIEJIRFJfT1ZFUkhF
QUQ7Cj4gICAgICBiLT5wdHIuZnJlZV9wdHIgPSAoc3RydWN0IGZyZWVfcHRyKSB7IE5VTEwsIE5V
TEx9Owo+IEBAIC01MDAsNiArNjE2LDcgQEAgdm9pZCB4bWVtX3Bvb2xfZnJlZSh2b2lkICpwdHIs
IHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gICAgICB0bXBfYi0+c2l6ZSB8PSBQUkVWX0ZSRUU7
Cj4gICAgICB0bXBfYi0+cHJldl9oZHIgPSBiOwo+ICAgb3V0Ogo+ICsgICAgeG1lbV9wb29sX2No
ZWNrX3VubG9ja2VkKHBvb2wpOwo+ICAgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwo+ICB9
Cj4gIAo+IEBAIC01MTIsOCArNjI5LDYgQEAgaW50IHhtZW1fcG9vbF9tYXhhbGxvYyhzdHJ1Y3Qg
eG1lbV9wb29sICpwb29sKQo+ICAgKiBHbHVlIGZvciB4bWFsbG9jKCkuCj4gICAqLwo+ICAKPiAt
c3RhdGljIHN0cnVjdCB4bWVtX3Bvb2wgKnhlbnBvb2w7Cj4gLQo+ICBzdGF0aWMgdm9pZCAqeG1h
bGxvY19wb29sX2dldCh1bnNpZ25lZCBsb25nIHNpemUpCj4gIHsKPiAgICAgIEFTU0VSVChzaXpl
ID09IFBBR0VfU0laRSk7Cj4gZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgg
Yi94ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCj4gaW5kZXggMjRhOTlhYy4uNjI2ZWFkMCAxMDA2
NDQKPiAtLS0gYS94ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCj4gKysrIGIveGVuL2luY2x1ZGUv
eGVuL3htYWxsb2MuaAo+IEBAIC0xMjMsNCArMTIzLDExIEBAIHVuc2lnbmVkIGxvbmcgeG1lbV9w
b29sX2dldF91c2VkX3NpemUoc3RydWN0IHhtZW1fcG9vbCAqcG9vbCk7Cj4gICAqLwo+ICB1bnNp
Z25lZCBsb25nIHhtZW1fcG9vbF9nZXRfdG90YWxfc2l6ZShzdHJ1Y3QgeG1lbV9wb29sICpwb29s
KTsKPiAgCj4gKyNpZm5kZWYgTkRFQlVHCj4gKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrKCkgX194
bWVtX3Bvb2xfY2hlY2soX19GSUxFX18sIF9fTElORV9fKQo+ICtpbnQgX194bWVtX3Bvb2xfY2hl
Y2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpOwo+ICsjZWxzZQo+ICsjZGVmaW5lIHhtZW1f
cG9vbF9jaGVjaygpIGRvIHsgaWYgKCAwICk7IH0gd2hpbGUgKDApCj4gKyNlbmRpZgo+ICsKPiAg
I2VuZGlmIC8qIF9fWE1BTExPQ19IX18gKi8KClRoaXMgY2hhbmdlIHdpbGwgZ2VuZXJhdGUgYSBt
ZXNzYWdlIGxpa2UgdGhpcyBvbmU6CgpbMjAxNC0xMi0wNCAxNTo0MToyM10gKFhFTikgWyAxMzc0
LjUwNzEyNV0geG1lbV9wb29sOiBmb3IgYmxvY2sgZmZmZjgzMDQwMDRmYjliMCBzaXplID0gMCwg
eyBmbCA9IDMsIHNsID0gOSB9IHNob3VsZCBiZSB7IGZsID0gMCwgc2wgPSAwIH0KWzIwMTQtMTIt
MDQgMTU6NDE6MjNdIChYRU4pIFsgMTM3NC41MDcxMjddIHhtZW1fcG9vbDp4bWFsbG9jX3Rsc2Yu
Yzo1ODIgdGhlIFRMU0YgY2h1bmsgbWF0cml4IGlzIGNvcnJ1cHRlZApbMjAxNC0xMi0wNCAxNTo0
MToyM10gKFhFTikgWyAxMzc0LjUwNzEyOF0gWGVuIFdBUk4gYXQgeG1hbGxvY190bHNmLmM6NTgy
ClsyMDE0LTEyLTA0IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MTMxXSAtLS0tWyBYZW4tNC40
LjEgIHg4Nl82NCAgZGVidWc9eSAgTm90IHRhaW50ZWQgXS0tLS0KWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxMzJdIENQVTogICAgMwpbMjAxNC0xMi0wNCAxNTo0MToyM10g
KFhFTikgWyAxMzc0LjUwNzEzM10gUklQOiAgICBlMDA4Ols8ZmZmZjgyZDA4MDE0MjhiMD5dIF9f
d2FybisweDFhLzB4MWUKWzIwMTQtMTItMDQgMTU6NDE6MjNdIChYRU4pIFsgMTM3NC41MDcxMzZd
IFJGTEFHUzogMDAwMDAwMDAwMDAxMDI4MiAgIENPTlRFWFQ6IGh5cGVydmlzb3IKWzIwMTQtMTIt
MDQgMTU6NDE6MjNdIChYRU4pIFsgMTM3NC41MDcxMzhdIHJheDogMDAwMDAwMDAwMDAwMDAwMCAg
IHJieDogMDAwMDAwMDAwMDAwMDAwOSAgIHJjeDogMDAwMDAwMDAwMDAwMDAwMApbMjAxNC0xMi0w
NCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzEzOV0gcmR4OiBmZmZmODMwNDE0Mzg4MDAwICAg
cnNpOiAwMDAwMDAwMDAwMDAwMDBhICAgcmRpOiBmZmZmODJkMDgwMjkyNmRjClsyMDE0LTEyLTA0
IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MTQxXSByYnA6IGZmZmY4MzA0MTQzOGZkMzggICBy
c3A6IGZmZmY4MzA0MTQzOGZkMzggICByODogIGZmZmY4MzA0MTQzYjAwMDAKWzIwMTQtMTItMDQg
MTU6NDE6MjNdIChYRU4pIFsgMTM3NC41MDcxNDJdIHI5OiAgMDAwMDAwMDAwMDAwMDAwNiAgIHIx
MDogMDAwMDAwMDAwMDA3YmNmOCAgIHIxMTogMDAwMDAwMDAwMDAwMDAwNgpbMjAxNC0xMi0wNCAx
NTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzE0M10gcjEyOiAwMDAwMDAwMDAwMDAwMDAzICAgcjEz
OiAwMDAwMDAwMDAwMDAwMDAxICAgcjE0OiAwMDAwMDAwMDAwMDAwMDAzClsyMDE0LTEyLTA0IDE1
OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MTQ1XSByMTU6IGZmZmY4MzA0MTQzY2EzMDAgICBjcjA6
IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6IDAwMDAwMDAwMDAxNTI2ZjAKWzIwMTQtMTItMDQgMTU6
NDE6MjNdIChYRU4pIFsgMTM3NC41MDcxNDZdIGNyMzogMDAwMDAwMDQwM2FmNjAwMCAgIGNyMjog
ZmZmZmZmZmZmZjYwMDQwMApbMjAxNC0xMi0wNCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzE0
N10gZHM6IDAwMmIgICBlczogMDAyYiAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczogZTAxMCAg
IGNzOiBlMDA4ClsyMDE0LTEyLTA0IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MTQ5XSBYZW4g
c3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgzMDQxNDM4ZmQzODoKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNTBdICAgIGZmZmY4MzA0MTQzOGZkYTggZmZmZjgyZDA4MDEz
MjRkNyAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMTNmZjg3MDc1YTIKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNTJdICAgIDAwMDAwMGZmOTZlZjFiMzggMDAwMDAyNDY4MDE2
ZTM1ZCBmZmZmODJkMDgwMjVhOGI5IGZmZmY4MzA0MTQzY2EwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNTVdICAgIDAwMDAwMDAwMDAwMDAwMDEgZmZmZjgzMDQwZmM2
NzAxMCBmZmZmODMwNDE0M2NhMDAwIGZmZmY4MzA0MTQzY2I4NjgKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNTddICAgIGZmZmY4MzA0MDIzMzgwMDAgZmZmZjgzMDQxMGRj
N2RlYyBmZmZmODMwNDE0MzhmZGQ4IGZmZmY4MmQwODAxMzJkYzUKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNTldICAgIGZmZmY4MzAwZGJmYjAwMzAgZmZmZjgzMDBkNGJm
YTAwMCBmZmZmODMwNDBmYzY3MDEwIGZmZmY4MzA0MDIzMzhkYTgKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNjFdICAgIGZmZmY4MzA0MTQzOGZlMTggZmZmZjgyZDA4MDEz
MzU4ZCBmZmZmODMwMGRiZmIwMDAwIGZmZmY4MzAwZDRiZmEwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNjRdICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDQwMjMz
OGRhOCBmZmZmODMwNDAyMzM4MDAwIGZmZmY4MzA0MTBkYzdkZWMKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNjZdICAgIGZmZmY4MzA0MTQzOGZlMzggZmZmZjgyZDA4MDFh
MmRhMiBmZmZmODMwNDE0MzhmZTQ4IGZmZmY4MzAwZDRiZmEwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNjhdICAgIGZmZmY4MzA0MTQzOGZlNDggZmZmZjgyZDA4MDE2
NzViYyBmZmZmODMwNDE0MzhmZTY4IGZmZmY4MmQwODAxNjEwMTUKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNzFdICAgIGZmZmY4MzAwZDRiZmEwMDAgZmZmZjgzMDBkNGJm
YTAwMCBmZmZmODMwNDE0MzhmZTk4IGZmZmY4MmQwODAxMDUwOTQKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNzNdICAgIGZmZmY4MzA0MTQzOTYyYzAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzA0MTQzODgwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNzVdICAgIGZmZmY4MzA0MTQzOGZlYzggZmZmZjgyZDA4MDEz
MzdkMCBmZmZmODMwNDE0MzYzZGVjIGZmZmY4MmQwODAzMDgxODAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNzddICAgIGZmZmY4MmQwODAzMDgwMDAgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmODMwNDE0MzhmZWY4IGZmZmY4MmQwODAxMmFhMzYKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxODBdICAgIGZmZmY4MzAwZDQ3ZmUwMDAgZmZmZjgzMDBkYmZi
MDAwMCAwMDAwMDAwMDAwMDAwMDAxIGZmZmY4MzA0MTBkYzcwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxODJdICAgIGZmZmY4MzA0MTQzOGZmMDggZmZmZjgyZDA4MDEy
YWE4ZiBmZmZmODMwNDE0MzhmZGEwIGZmZmY4MmQwODAyMmJkOTEKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxODRdICAgIGZmZmY4ODAwMjRjNDNmZDggZmZmZmZmZmY4MWFi
MWIzOCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxODZdICAgIGZmZmY4ODAwMjRjNDNlYzAgMDAwMDAwMDAwMDAw
MDAwMiAwMDAwMDAwMDAwMDAwMjQ2IDAwMDAwMDAwMDAwMDAwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxODhdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODEwMDEzYWEKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxOTBdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDBkZWFk
YmVlZiAwMDAwMDAwMGRlYWRiZWVmIDAwMDIwMTAwMDAwMDAwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxOTJdICAgIGZmZmZmZmZmODEwMDEzYWEgMDAwMDAwMDAwMDAw
ZTAzMyAwMDAwMDAwMDAwMDAwMjQ2IGZmZmY4ODAwMjRjNDNlYTgKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxOTRdIFhlbiBjYWxsIHRyYWNlOgpbMjAxNC0xMi0wNCAxNTo0
MToyM10gKFhFTikgWyAxMzc0LjUwNzE5Nl0gICAgWzxmZmZmODJkMDgwMTQyOGIwPl0gX193YXJu
KzB4MWEvMHgxZQpbMjAxNC0xMi0wNCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzE5OF0gICAg
WzxmZmZmODJkMDgwMTMyNGQ3Pl0gX194bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQrMHgxNDMvMHgy
NGYKWzIwMTQtMTItMDQgMTU6NDE6MjNdIChYRU4pIFsgMTM3NC41MDcyMDBdICAgIFs8ZmZmZjgy
ZDA4MDEzMmRjNT5dIHhtZW1fcG9vbF9mcmVlKzB4M2YvMHgyZDkKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcyMDFdICAgIFs8ZmZmZjgyZDA4MDEzMzU4ZD5dIHhmcmVlKzB4
MWQ1LzB4MjIyClsyMDE0LTEyLTA0IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MjAzXSAgICBb
PGZmZmY4MmQwODAxYTJkYTI+XSB4c3RhdGVfZnJlZV9zYXZlX2FyZWErMHgxOC8weDJhClsyMDE0
LTEyLTA0IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MjA1XSAgICBbPGZmZmY4MmQwODAxNjc1
YmM+XSB2Y3B1X2Rlc3Ryb3lfZnB1KzB4MTMvMHgyMwpbMjAxNC0xMi0wNCAxNTo0MToyM10gKFhF
TikgWyAxMzc0LjUwNzIwN10gICAgWzxmZmZmODJkMDgwMTYxMDE1Pl0gdmNwdV9kZXN0cm95KzB4
MjYvMHg1MApbMjAxNC0xMi0wNCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzIwOV0gICAgWzxm
ZmZmODJkMDgwMTA1MDk0Pl0gY29tcGxldGVfZG9tYWluX2Rlc3Ryb3krMHg0OS8weDE2YQpbMjAx
NC0xMi0wNCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzIxMV0gICAgWzxmZmZmODJkMDgwMTMz
N2QwPl0gcmN1X3Byb2Nlc3NfY2FsbGJhY2tzKzB4MTQ1LzB4MWE2ClsyMDE0LTEyLTA0IDE1OjQx
OjIzXSAoWEVOKSBbIDEzNzQuNTA3MjEzXSAgICBbPGZmZmY4MmQwODAxMmFhMzY+XSBfX2RvX3Nv
ZnRpcnErMHg4MS8weDhjClsyMDE0LTEyLTA0IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MjE1
XSAgICBbPGZmZmY4MmQwODAxMmFhOGY+XSBkb19zb2Z0aXJxKzB4MTMvMHgxNQpbMjAxNC0xMi0w
NCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzI1M10gICAgWzxmZmZmODJkMDgwMjJiZDkxPl0g
cHJvY2Vzc19zb2Z0aXJxcysweDIxLzB4MzAKCmV2ZXJ5IHRpbWUgdGhlIHhtZW0gcG9vbCBnZXRz
IGNvcnJ1cHRlZC4gVGhpcyBpcyBvbmx5IGEgaGludCwgdGhvdWdoLiBBCmRldmVsb3BlciB3aWxs
IGhhdmUgdG8gcGxhY2UgeG1lbV9wb29sX2NoZWNrKCkgaW4gdmFyaW91cyBwbGFjZXMgdG8KZGV0
ZXJtaW5lIHRoZSBzb3VyY2Ugb2YgdGhlIGNvcnJ1cHRpb24uIEkgdXNlZCBpdCB0byB0cmFjayBk
b3duIGEgdXNlCmFmdGVyIGZyZWUgYnVnIChkZXRhaWxzIHdpbGwgZm9sbG93IGxhdGVyKS4KClRo
YW5rcywKCi0tIApNaWhhaSBET07ImlUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Dec 04 17:10:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 17: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 1XwZuw-0003DV-7x; Thu, 04 Dec 2014 17:10:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XwZuu-0003D6-VT
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 17:10:13 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	0C/86-27584-47590845; Thu, 04 Dec 2014 17:10:12 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417713010!11604876!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 3705 invoked from network); 4 Dec 2014 17:10:11 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 17:10:11 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=ERgT4t+ej46uXUEle0RZGzXHNjUlsTN42SnyGMl7/Q4FXZjYEHx/iiPnAaxg7bVfo3lXivYtVIfiNAmys+uPpckzdFGPWdxOgnOZBCdqXt5QTAKB4Orl7toCgAvzD/7DwrVMDRQSOx3QoZt0PvKnT6kPIT10i7X6Sw00gdtnIYj/7fJFKtMMpFEbKZXmk3ieBQ++VJDrBEsF3DT26aQqivCGfyLVY3DNcmB3sGy50Jvg/hvFcSBRgJF13aW5m+ki9AhIewHiNIy0PwOQMH2WTgLAllzAcIma/GbOlDFlKWfeWNO1+jgKohSeFQ9LrSKLkM9LBOVyknSTzUfqdJ1oqg==;
	h=Received:Received:Received:Received:Received:Date:From:To:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:subject:message-id:in-reply-to:references:mime-version
	:content-type:content-transfer-encoding; s=default; bh=GIjQMFIPh
	C4mVkYd9UhnFSX5csw=; b=oH4LjwVtk2mVwgmftZWk9NDvhk5Ks6iWtFkB5yoFM
	bY2QfX93teBELY3tRS+757ewYbJYHjNB2UbKQh9tWTFMG6r36O82k8tCcZzCUao8
	dSDhE5XupIJQAp7piik2kXnGBoJuhg/WeGu0NkBHmZg2Kh+0Cc8k0mL5TKRz5JGT
	tz8gG4ICrGDfSebdBGIAqYLz0f1ICeNHuwn5ELfBoEbsjFKDid47eCwKL/SvnRUz
	4MoQ7GA+aI6g+wuv2PftjaNBZDL1G3KogkAyX0AEPpVTGcz+kM66CGjZezZ/cPTq
	SKLVxtwPEBa8SmrOrrqGM0yk9/CEsXxiE/Us3yTF/HPYw==
Received: (qmail 27483 invoked from network); 4 Dec 2014 19:10:10 +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 Dec 2014 19:10:10 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id CB0CE803F8
	for <xen-devel@lists.xen.org>; Thu,  4 Dec 2014 19:10:09 +0200 (EET)
Received: (qmail 25747 invoked from network); 4 Dec 2014 19:10:09 +0200
Received: from unknown (HELO bitdefender.com)
	(mdontu@bitdefender.com@91.199.104.6)
	by smtp03.buh.bitdefender.org with SMTP; 4 Dec 2014 19:10:09 +0200
Date: Thu, 4 Dec 2014 19:10:09 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: xen-devel@lists.xen.org
Message-ID: <20141204191009.0434bc13@bitdefender.com>
In-Reply-To: <1417712500-28009-1-git-send-email-mdontu@bitdefender.com>
References: <1417712500-28009-1-git-send-email-mdontu@bitdefender.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.58104
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374177,
	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.1.0; Id:
	2m1ghdn.198b1eaj8.8qam], total: 0(775)
X-BitDefender-CF-Stamp: none
Subject: Re: [Xen-devel] [PATCH] xmalloc: add support for checking the pool
 integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1cnNkYXkgMDQgRGVjZW1iZXIgMjAxNCAxOTowMTo0MCBNaWhhaSBEb27Im3Ugd3JvdGU6
Cj4gSW1wbGVtZW50ZWQgeG1lbV9wb29sX2NoZWNrKCksIHhtZW1fcG9vbF9jaGVja19sb2NrZWQo
KSBhbmQKPiB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoKSB0byB2ZXJpdHkgdGhlIGludGVncml0
eSBvZiB0aGUgVExTRiBtYXRyaXguCj4gCj4gU2lnbmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxt
ZG9udHVAYml0ZGVmZW5kZXIuY29tPgo+IC0tLQo+ICB4ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5j
IHwgMTE5ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0KPiAg
eGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaCB8ICAgNyArKysKPiAgMiBmaWxlcyBjaGFuZ2VkLCAx
MjQgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKPiAKPiBkaWZmIC0tZ2l0IGEveGVuL2Nv
bW1vbi94bWFsbG9jX3Rsc2YuYyBiL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMKPiBpbmRleCBh
NTc2OWM5Li4wMDliYTYwIDEwMDY0NAo+IC0tLSBhL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMK
PiArKysgYi94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jCj4gQEAgLTEyMCw5ICsxMjAsMTIwIEBA
IHN0cnVjdCB4bWVtX3Bvb2wgewo+ICAgICAgY2hhciBuYW1lW01BWF9QT09MX05BTUVfTEVOXTsK
PiAgfTsKPiAgCj4gK3N0YXRpYyBzdHJ1Y3QgeG1lbV9wb29sICp4ZW5wb29sOwo+ICsKPiArc3Rh
dGljIGlubGluZSB2b2lkIE1BUFBJTkdfSU5TRVJUKHVuc2lnbmVkIGxvbmcgciwgaW50ICpmbCwg
aW50ICpzbCk7Cj4gKwo+ICAvKgo+ICAgKiBIZWxwaW5nIGZ1bmN0aW9ucwo+ICAgKi8KPiArI2lm
bmRlZiBOREVCVUcKPiArc3RhdGljIGludCB4bWVtX3Bvb2xfY2hlY2tfc2l6ZShjb25zdCBzdHJ1
Y3QgYmhkciAqYiwgaW50IGZsLCBpbnQgc2wpCj4gK3sKPiArICAgIHdoaWxlICggYiApCj4gKyAg
ICB7Cj4gKyAgICAgICAgaW50IF9fZmw7Cj4gKyAgICAgICAgaW50IF9fc2w7Cj4gKwo+ICsgICAg
ICAgIE1BUFBJTkdfSU5TRVJUKGItPnNpemUsICZfX2ZsLCAmX19zbCk7Cj4gKyAgICAgICAgaWYg
KCBfX2ZsICE9IGZsIHx8IF9fc2wgIT0gc2wgKQo+ICsgICAgICAgIHsKPiArICAgICAgICAgICAg
cHJpbnRrKFhFTkxPR19FUlIgInhtZW1fcG9vbDogZm9yIGJsb2NrICVwIHNpemUgPSAldSwgeyBm
bCA9ICVkLCBzbCA9ICVkIH0gc2hvdWxkIGJlIHsgZmwgPSAlZCwgc2wgPSAlZCB9XG4iLCBiLCBi
LT5zaXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOwo+ICsgICAgICAgICAgICByZXR1cm4gMDsKPiAr
ICAgICAgICB9Cj4gKyAgICAgICAgYiA9IGItPnB0ci5mcmVlX3B0ci5uZXh0Owo+ICsgICAgfQo+
ICsgICAgcmV0dXJuIDE7Cj4gK30KPiArCj4gKy8qCj4gKyAqIFRoaXMgZnVuY3Rpb24gbXVzdCBi
ZSBjYWxsZWQgZnJvbSBhIGNvbnRleHQgd2hlcmUgcG9vbC0+bG9jayBpcwo+ICsgKiBhbHJlYWR5
IGFjcXVpcmVkCj4gKyAqLwo+ICsjZGVmaW5lIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChfX3Bv
b2wpIF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKF9fRklMRV9fLCBfX0xJTkVfXywgX19wb29s
KQo+ICtzdGF0aWMgaW50IF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKGNvbnN0IGNoYXIgKmZp
bGUsIGludCBsaW5lLCBjb25zdCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ICt7Cj4gKyAgICBp
bnQgaTsKPiArICAgIGludCB3b29wcyA9IDA7Cj4gKyAgICBzdGF0aWMgaW50IG9uY2UgPSAxOwo+
ICsKPiArICAgIGZvciAoIGkgPSAwOyBpIDwgUkVBTF9GTEk7IGkrKyApCj4gKyAgICB7Cj4gKyAg
ICAgICAgaW50IGZsID0gKCBwb29sLT5mbF9iaXRtYXAgJiAoMSA8PCBpKSApID8gaSA6IC0xOwo+
ICsKPiArICAgICAgICBpZiAoIGZsID49IDAgKQo+ICsgICAgICAgIHsKPiArICAgICAgICAgICAg
aW50IGo7Cj4gKyAgICAgICAgICAgIGludCBiaXRtYXBfZW1wdHkgPSAxOwo+ICsgICAgICAgICAg
ICBpbnQgbWF0cml4X2VtcHR5ID0gMTsKPiArCj4gKyAgICAgICAgICAgIGZvciAoIGogPSAwOyBq
IDwgTUFYX1NMSTsgaisrICkKPiArICAgICAgICAgICAgewo+ICsgICAgICAgICAgICAgICAgaW50
IHNsID0gKCBwb29sLT5zbF9iaXRtYXBbZmxdICYgKDEgPDwgaikgKSA/IGogOiAtMTsKPiArCj4g
KyAgICAgICAgICAgICAgICBpZiAoIHNsIDwgMCApCj4gKyAgICAgICAgICAgICAgICAgICAgY29u
dGludWU7Cj4gKwo+ICsgICAgICAgICAgICAgICAgaWYgKCBvbmNlICYmICFwb29sLT5tYXRyaXhb
ZmxdW3NsXSApCj4gKyAgICAgICAgICAgICAgICB7Cj4gKyAgICAgICAgICAgICAgICAgICAgLyog
VGhlIGJpdG1hcCBpcyBjb3JydXB0ZWQgKi8KPiArICAgICAgICAgICAgICAgICAgICBwcmludGso
WEVOTE9HX0VSUiAieG1lbV9wb29sOiVzOiVkIHRoZSBUTFNGIGJpdG1hcCBpcyBjb3JydXB0ZWRc
biIsIGZpbGUsIGxpbmUpOwo+ICsgICAgICAgICAgICAgICAgICAgIF9fd2FybigoY2hhciAqKWZp
bGUsIGxpbmUpOwo+ICsgICAgICAgICAgICAgICAgICAgIG9uY2UgPSAwOwo+ICsgICAgICAgICAg
ICAgICAgICAgIHdvb3BzID0gMTsKPiArICAgICAgICAgICAgICAgIH0KPiArICAgICAgICAgICAg
ICAgIGVsc2UgaWYgKCBvbmNlICYmICF4bWVtX3Bvb2xfY2hlY2tfc2l6ZShwb29sLT5tYXRyaXhb
ZmxdW3NsXSwgZmwsIHNsKSkKPiArICAgICAgICAgICAgICAgIHsKPiArICAgICAgICAgICAgICAg
ICAgICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9wb29sOiVzOiVkIHRoZSBUTFNGIGNodW5rIG1h
dHJpeCBpcyBjb3JydXB0ZWRcbiIsIGZpbGUsIGxpbmUpOwo+ICsgICAgICAgICAgICAgICAgICAg
IF9fd2FybigoY2hhciAqKWZpbGUsIGxpbmUpOwo+ICsgICAgICAgICAgICAgICAgICAgIG9uY2Ug
PSAwOwo+ICsgICAgICAgICAgICAgICAgICAgIHdvb3BzID0gMTsKPiArICAgICAgICAgICAgICAg
IH0KPiArICAgICAgICAgICAgICAgIGlmICggcG9vbC0+bWF0cml4W2ZsXVtzbF0gKQo+ICsgICAg
ICAgICAgICAgICAgICAgIG1hdHJpeF9lbXB0eSA9IDA7Cj4gKyAgICAgICAgICAgICAgICBiaXRt
YXBfZW1wdHkgPSAwOwo+ICsgICAgICAgICAgICB9Cj4gKyAgICAgICAgICAgIGlmICggb25jZSAm
JiBiaXRtYXBfZW1wdHkgKQo+ICsgICAgICAgICAgICB7Cj4gKyAgICAgICAgICAgICAgICAvKiBU
aGUgYml0bWFwIGlzIGNvcnJ1cHRlZCAqLwo+ICsgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxP
R19FUlIgInhtZW1fcG9vbDolczolZCB0aGUgVExTRiBiaXRtYXAgaXMgY29ycnVwdGVkIChub24t
ZW1wdHkgRkwgd2l0aCBlbXB0eSBTTClcbiIsIGZpbGUsIGxpbmUpOwo+ICsgICAgICAgICAgICAg
ICAgX193YXJuKChjaGFyICopZmlsZSwgbGluZSk7Cj4gKyAgICAgICAgICAgICAgICBvbmNlID0g
MDsKPiArICAgICAgICAgICAgICAgIHdvb3BzID0gMTsKPiArICAgICAgICAgICAgfQo+ICsgICAg
ICAgICAgICBpZiAoIG9uY2UgJiYgbWF0cml4X2VtcHR5ICkKPiArICAgICAgICAgICAgewo+ICsg
ICAgICAgICAgICAgICAgLyogVGhlIGJpdG1hcCBpcyBjb3JydXB0ZWQgKi8KPiArICAgICAgICAg
ICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4bWVtX3Bvb2w6JXM6JWQgdGhlIFRMU0YgYml0bWFw
IGlzIGNvcnJ1cHRlZCAoZW1wdHkgbWF0cml4KVxuIiwgZmlsZSwgbGluZSk7Cj4gKyAgICAgICAg
ICAgICAgICBfX3dhcm4oKGNoYXIgKilmaWxlLCBsaW5lKTsKPiArICAgICAgICAgICAgICAgIG9u
Y2UgPSAwOwo+ICsgICAgICAgICAgICAgICAgd29vcHMgPSAxOwo+ICsgICAgICAgICAgICB9Cj4g
KyAgICAgICAgfQo+ICsgICAgfQo+ICsKPiArICAgIHJldHVybiB3b29wczsKPiArfQo+ICsKPiAr
I2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKF9fcG9vbCkgX194bWVtX3Bvb2xfY2hlY2tf
bG9ja2VkKF9fRklMRV9fLCBfX0xJTkVfXywgX19wb29sKQo+ICtzdGF0aWMgaW50IF9feG1lbV9w
b29sX2NoZWNrX2xvY2tlZChjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgc3RydWN0IHhtZW1f
cG9vbCAqcG9vbCkKPiArewo+ICsgICAgaW50IGVycjsKPiArCj4gKyAgICBzcGluX2xvY2soJnBv
b2wtPmxvY2spOwo+ICsgICAgZXJyID0gX194bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoZmlsZSwg
bGluZSwgcG9vbCk7Cj4gKyAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7Cj4gKyAgICByZXR1
cm4gZXJyOwo+ICt9Cj4gKwo+ICtpbnQgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmls
ZSwgaW50IGxpbmUpCj4gK3sKPiArICAgIHJldHVybiBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQo
ZmlsZSwgbGluZSwgeGVucG9vbCk7Cj4gK30KPiArI2Vsc2UKPiArI2RlZmluZSB4bWVtX3Bvb2xf
Y2hlY2tfbG9ja2VkKF9fcG9vbCkgZG8geyBpZiAoIDAgJiYgKF9fcG9vbCkgKTsgfSB3aGlsZSAo
MCkKPiArI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoX19wb29sKSBkbyB7IGlmICgg
MCAmJiAoX19wb29sKSApOyB9IHdoaWxlICgwKQo+ICsjZW5kaWYKPiAgCj4gIC8qKgo+ICAgKiBS
ZXR1cm5zIGluZGV4ZXMgKGZsLCBzbCkgb2YgdGhlIGxpc3QgdXNlZCB0byBzZXJ2ZSByZXF1ZXN0
IG9mIHNpemUgcgo+IEBAIC0zODEsNiArNDkyLDggQEAgdm9pZCAqeG1lbV9wb29sX2FsbG9jKHVu
c2lnbmVkIGxvbmcgc2l6ZSwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAgICAgIGludCBmbCwg
c2w7Cj4gICAgICB1bnNpZ25lZCBsb25nIHRtcF9zaXplOwo+ICAKPiArICAgIHhtZW1fcG9vbF9j
aGVja19sb2NrZWQocG9vbCk7Cj4gKwo+ICAgICAgaWYgKCBwb29sLT5pbml0X3JlZ2lvbiA9PSBO
VUxMICkKPiAgICAgIHsKPiAgICAgICAgICBpZiAoIChyZWdpb24gPSBwb29sLT5nZXRfbWVtKHBv
b2wtPmluaXRfc2l6ZSkpID09IE5VTEwgKQo+IEBAIC00NDIsMTEgKzU1NSwxMyBAQCB2b2lkICp4
bWVtX3Bvb2xfYWxsb2ModW5zaWduZWQgbG9uZyBzaXplLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29s
KQo+ICAKPiAgICAgIHBvb2wtPnVzZWRfc2l6ZSArPSAoYi0+c2l6ZSAmIEJMT0NLX1NJWkVfTUFT
SykgKyBCSERSX09WRVJIRUFEOwo+ICAKPiArICAgIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChw
b29sKTsKPiAgICAgIHNwaW5fdW5sb2NrKCZwb29sLT5sb2NrKTsKPiAgICAgIHJldHVybiAodm9p
ZCAqKWItPnB0ci5idWZmZXI7Cj4gIAo+ICAgICAgLyogRmFpbGVkIGFsbG9jICovCj4gICBvdXRf
bG9ja2VkOgo+ICsgICAgeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKHBvb2wpOwo+ICAgICAgc3Bp
bl91bmxvY2soJnBvb2wtPmxvY2spOwo+ICAKPiAgIG91dDoKPiBAQCAtNDY0LDYgKzU3OSw3IEBA
IHZvaWQgeG1lbV9wb29sX2ZyZWUodm9pZCAqcHRyLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+
ICAgICAgYiA9IChzdHJ1Y3QgYmhkciAqKSgoY2hhciAqKSBwdHIgLSBCSERSX09WRVJIRUFEKTsK
PiAgCj4gICAgICBzcGluX2xvY2soJnBvb2wtPmxvY2spOwo+ICsgICAgeG1lbV9wb29sX2NoZWNr
X3VubG9ja2VkKHBvb2wpOwo+ICAgICAgYi0+c2l6ZSB8PSBGUkVFX0JMT0NLOwo+ICAgICAgcG9v
bC0+dXNlZF9zaXplIC09IChiLT5zaXplICYgQkxPQ0tfU0laRV9NQVNLKSArIEJIRFJfT1ZFUkhF
QUQ7Cj4gICAgICBiLT5wdHIuZnJlZV9wdHIgPSAoc3RydWN0IGZyZWVfcHRyKSB7IE5VTEwsIE5V
TEx9Owo+IEBAIC01MDAsNiArNjE2LDcgQEAgdm9pZCB4bWVtX3Bvb2xfZnJlZSh2b2lkICpwdHIs
IHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gICAgICB0bXBfYi0+c2l6ZSB8PSBQUkVWX0ZSRUU7
Cj4gICAgICB0bXBfYi0+cHJldl9oZHIgPSBiOwo+ICAgb3V0Ogo+ICsgICAgeG1lbV9wb29sX2No
ZWNrX3VubG9ja2VkKHBvb2wpOwo+ICAgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwo+ICB9
Cj4gIAo+IEBAIC01MTIsOCArNjI5LDYgQEAgaW50IHhtZW1fcG9vbF9tYXhhbGxvYyhzdHJ1Y3Qg
eG1lbV9wb29sICpwb29sKQo+ICAgKiBHbHVlIGZvciB4bWFsbG9jKCkuCj4gICAqLwo+ICAKPiAt
c3RhdGljIHN0cnVjdCB4bWVtX3Bvb2wgKnhlbnBvb2w7Cj4gLQo+ICBzdGF0aWMgdm9pZCAqeG1h
bGxvY19wb29sX2dldCh1bnNpZ25lZCBsb25nIHNpemUpCj4gIHsKPiAgICAgIEFTU0VSVChzaXpl
ID09IFBBR0VfU0laRSk7Cj4gZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgg
Yi94ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCj4gaW5kZXggMjRhOTlhYy4uNjI2ZWFkMCAxMDA2
NDQKPiAtLS0gYS94ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCj4gKysrIGIveGVuL2luY2x1ZGUv
eGVuL3htYWxsb2MuaAo+IEBAIC0xMjMsNCArMTIzLDExIEBAIHVuc2lnbmVkIGxvbmcgeG1lbV9w
b29sX2dldF91c2VkX3NpemUoc3RydWN0IHhtZW1fcG9vbCAqcG9vbCk7Cj4gICAqLwo+ICB1bnNp
Z25lZCBsb25nIHhtZW1fcG9vbF9nZXRfdG90YWxfc2l6ZShzdHJ1Y3QgeG1lbV9wb29sICpwb29s
KTsKPiAgCj4gKyNpZm5kZWYgTkRFQlVHCj4gKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrKCkgX194
bWVtX3Bvb2xfY2hlY2soX19GSUxFX18sIF9fTElORV9fKQo+ICtpbnQgX194bWVtX3Bvb2xfY2hl
Y2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpOwo+ICsjZWxzZQo+ICsjZGVmaW5lIHhtZW1f
cG9vbF9jaGVjaygpIGRvIHsgaWYgKCAwICk7IH0gd2hpbGUgKDApCj4gKyNlbmRpZgo+ICsKPiAg
I2VuZGlmIC8qIF9fWE1BTExPQ19IX18gKi8KClRoaXMgY2hhbmdlIHdpbGwgZ2VuZXJhdGUgYSBt
ZXNzYWdlIGxpa2UgdGhpcyBvbmU6CgpbMjAxNC0xMi0wNCAxNTo0MToyM10gKFhFTikgWyAxMzc0
LjUwNzEyNV0geG1lbV9wb29sOiBmb3IgYmxvY2sgZmZmZjgzMDQwMDRmYjliMCBzaXplID0gMCwg
eyBmbCA9IDMsIHNsID0gOSB9IHNob3VsZCBiZSB7IGZsID0gMCwgc2wgPSAwIH0KWzIwMTQtMTIt
MDQgMTU6NDE6MjNdIChYRU4pIFsgMTM3NC41MDcxMjddIHhtZW1fcG9vbDp4bWFsbG9jX3Rsc2Yu
Yzo1ODIgdGhlIFRMU0YgY2h1bmsgbWF0cml4IGlzIGNvcnJ1cHRlZApbMjAxNC0xMi0wNCAxNTo0
MToyM10gKFhFTikgWyAxMzc0LjUwNzEyOF0gWGVuIFdBUk4gYXQgeG1hbGxvY190bHNmLmM6NTgy
ClsyMDE0LTEyLTA0IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MTMxXSAtLS0tWyBYZW4tNC40
LjEgIHg4Nl82NCAgZGVidWc9eSAgTm90IHRhaW50ZWQgXS0tLS0KWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxMzJdIENQVTogICAgMwpbMjAxNC0xMi0wNCAxNTo0MToyM10g
KFhFTikgWyAxMzc0LjUwNzEzM10gUklQOiAgICBlMDA4Ols8ZmZmZjgyZDA4MDE0MjhiMD5dIF9f
d2FybisweDFhLzB4MWUKWzIwMTQtMTItMDQgMTU6NDE6MjNdIChYRU4pIFsgMTM3NC41MDcxMzZd
IFJGTEFHUzogMDAwMDAwMDAwMDAxMDI4MiAgIENPTlRFWFQ6IGh5cGVydmlzb3IKWzIwMTQtMTIt
MDQgMTU6NDE6MjNdIChYRU4pIFsgMTM3NC41MDcxMzhdIHJheDogMDAwMDAwMDAwMDAwMDAwMCAg
IHJieDogMDAwMDAwMDAwMDAwMDAwOSAgIHJjeDogMDAwMDAwMDAwMDAwMDAwMApbMjAxNC0xMi0w
NCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzEzOV0gcmR4OiBmZmZmODMwNDE0Mzg4MDAwICAg
cnNpOiAwMDAwMDAwMDAwMDAwMDBhICAgcmRpOiBmZmZmODJkMDgwMjkyNmRjClsyMDE0LTEyLTA0
IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MTQxXSByYnA6IGZmZmY4MzA0MTQzOGZkMzggICBy
c3A6IGZmZmY4MzA0MTQzOGZkMzggICByODogIGZmZmY4MzA0MTQzYjAwMDAKWzIwMTQtMTItMDQg
MTU6NDE6MjNdIChYRU4pIFsgMTM3NC41MDcxNDJdIHI5OiAgMDAwMDAwMDAwMDAwMDAwNiAgIHIx
MDogMDAwMDAwMDAwMDA3YmNmOCAgIHIxMTogMDAwMDAwMDAwMDAwMDAwNgpbMjAxNC0xMi0wNCAx
NTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzE0M10gcjEyOiAwMDAwMDAwMDAwMDAwMDAzICAgcjEz
OiAwMDAwMDAwMDAwMDAwMDAxICAgcjE0OiAwMDAwMDAwMDAwMDAwMDAzClsyMDE0LTEyLTA0IDE1
OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MTQ1XSByMTU6IGZmZmY4MzA0MTQzY2EzMDAgICBjcjA6
IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6IDAwMDAwMDAwMDAxNTI2ZjAKWzIwMTQtMTItMDQgMTU6
NDE6MjNdIChYRU4pIFsgMTM3NC41MDcxNDZdIGNyMzogMDAwMDAwMDQwM2FmNjAwMCAgIGNyMjog
ZmZmZmZmZmZmZjYwMDQwMApbMjAxNC0xMi0wNCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzE0
N10gZHM6IDAwMmIgICBlczogMDAyYiAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczogZTAxMCAg
IGNzOiBlMDA4ClsyMDE0LTEyLTA0IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MTQ5XSBYZW4g
c3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgzMDQxNDM4ZmQzODoKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNTBdICAgIGZmZmY4MzA0MTQzOGZkYTggZmZmZjgyZDA4MDEz
MjRkNyAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMTNmZjg3MDc1YTIKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNTJdICAgIDAwMDAwMGZmOTZlZjFiMzggMDAwMDAyNDY4MDE2
ZTM1ZCBmZmZmODJkMDgwMjVhOGI5IGZmZmY4MzA0MTQzY2EwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNTVdICAgIDAwMDAwMDAwMDAwMDAwMDEgZmZmZjgzMDQwZmM2
NzAxMCBmZmZmODMwNDE0M2NhMDAwIGZmZmY4MzA0MTQzY2I4NjgKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNTddICAgIGZmZmY4MzA0MDIzMzgwMDAgZmZmZjgzMDQxMGRj
N2RlYyBmZmZmODMwNDE0MzhmZGQ4IGZmZmY4MmQwODAxMzJkYzUKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNTldICAgIGZmZmY4MzAwZGJmYjAwMzAgZmZmZjgzMDBkNGJm
YTAwMCBmZmZmODMwNDBmYzY3MDEwIGZmZmY4MzA0MDIzMzhkYTgKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNjFdICAgIGZmZmY4MzA0MTQzOGZlMTggZmZmZjgyZDA4MDEz
MzU4ZCBmZmZmODMwMGRiZmIwMDAwIGZmZmY4MzAwZDRiZmEwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNjRdICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDQwMjMz
OGRhOCBmZmZmODMwNDAyMzM4MDAwIGZmZmY4MzA0MTBkYzdkZWMKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNjZdICAgIGZmZmY4MzA0MTQzOGZlMzggZmZmZjgyZDA4MDFh
MmRhMiBmZmZmODMwNDE0MzhmZTQ4IGZmZmY4MzAwZDRiZmEwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNjhdICAgIGZmZmY4MzA0MTQzOGZlNDggZmZmZjgyZDA4MDE2
NzViYyBmZmZmODMwNDE0MzhmZTY4IGZmZmY4MmQwODAxNjEwMTUKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNzFdICAgIGZmZmY4MzAwZDRiZmEwMDAgZmZmZjgzMDBkNGJm
YTAwMCBmZmZmODMwNDE0MzhmZTk4IGZmZmY4MmQwODAxMDUwOTQKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNzNdICAgIGZmZmY4MzA0MTQzOTYyYzAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzA0MTQzODgwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNzVdICAgIGZmZmY4MzA0MTQzOGZlYzggZmZmZjgyZDA4MDEz
MzdkMCBmZmZmODMwNDE0MzYzZGVjIGZmZmY4MmQwODAzMDgxODAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxNzddICAgIGZmZmY4MmQwODAzMDgwMDAgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmODMwNDE0MzhmZWY4IGZmZmY4MmQwODAxMmFhMzYKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxODBdICAgIGZmZmY4MzAwZDQ3ZmUwMDAgZmZmZjgzMDBkYmZi
MDAwMCAwMDAwMDAwMDAwMDAwMDAxIGZmZmY4MzA0MTBkYzcwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxODJdICAgIGZmZmY4MzA0MTQzOGZmMDggZmZmZjgyZDA4MDEy
YWE4ZiBmZmZmODMwNDE0MzhmZGEwIGZmZmY4MmQwODAyMmJkOTEKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxODRdICAgIGZmZmY4ODAwMjRjNDNmZDggZmZmZmZmZmY4MWFi
MWIzOCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxODZdICAgIGZmZmY4ODAwMjRjNDNlYzAgMDAwMDAwMDAwMDAw
MDAwMiAwMDAwMDAwMDAwMDAwMjQ2IDAwMDAwMDAwMDAwMDAwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxODhdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODEwMDEzYWEKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxOTBdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDBkZWFk
YmVlZiAwMDAwMDAwMGRlYWRiZWVmIDAwMDIwMTAwMDAwMDAwMDAKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxOTJdICAgIGZmZmZmZmZmODEwMDEzYWEgMDAwMDAwMDAwMDAw
ZTAzMyAwMDAwMDAwMDAwMDAwMjQ2IGZmZmY4ODAwMjRjNDNlYTgKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcxOTRdIFhlbiBjYWxsIHRyYWNlOgpbMjAxNC0xMi0wNCAxNTo0
MToyM10gKFhFTikgWyAxMzc0LjUwNzE5Nl0gICAgWzxmZmZmODJkMDgwMTQyOGIwPl0gX193YXJu
KzB4MWEvMHgxZQpbMjAxNC0xMi0wNCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzE5OF0gICAg
WzxmZmZmODJkMDgwMTMyNGQ3Pl0gX194bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQrMHgxNDMvMHgy
NGYKWzIwMTQtMTItMDQgMTU6NDE6MjNdIChYRU4pIFsgMTM3NC41MDcyMDBdICAgIFs8ZmZmZjgy
ZDA4MDEzMmRjNT5dIHhtZW1fcG9vbF9mcmVlKzB4M2YvMHgyZDkKWzIwMTQtMTItMDQgMTU6NDE6
MjNdIChYRU4pIFsgMTM3NC41MDcyMDFdICAgIFs8ZmZmZjgyZDA4MDEzMzU4ZD5dIHhmcmVlKzB4
MWQ1LzB4MjIyClsyMDE0LTEyLTA0IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MjAzXSAgICBb
PGZmZmY4MmQwODAxYTJkYTI+XSB4c3RhdGVfZnJlZV9zYXZlX2FyZWErMHgxOC8weDJhClsyMDE0
LTEyLTA0IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MjA1XSAgICBbPGZmZmY4MmQwODAxNjc1
YmM+XSB2Y3B1X2Rlc3Ryb3lfZnB1KzB4MTMvMHgyMwpbMjAxNC0xMi0wNCAxNTo0MToyM10gKFhF
TikgWyAxMzc0LjUwNzIwN10gICAgWzxmZmZmODJkMDgwMTYxMDE1Pl0gdmNwdV9kZXN0cm95KzB4
MjYvMHg1MApbMjAxNC0xMi0wNCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzIwOV0gICAgWzxm
ZmZmODJkMDgwMTA1MDk0Pl0gY29tcGxldGVfZG9tYWluX2Rlc3Ryb3krMHg0OS8weDE2YQpbMjAx
NC0xMi0wNCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzIxMV0gICAgWzxmZmZmODJkMDgwMTMz
N2QwPl0gcmN1X3Byb2Nlc3NfY2FsbGJhY2tzKzB4MTQ1LzB4MWE2ClsyMDE0LTEyLTA0IDE1OjQx
OjIzXSAoWEVOKSBbIDEzNzQuNTA3MjEzXSAgICBbPGZmZmY4MmQwODAxMmFhMzY+XSBfX2RvX3Nv
ZnRpcnErMHg4MS8weDhjClsyMDE0LTEyLTA0IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3MjE1
XSAgICBbPGZmZmY4MmQwODAxMmFhOGY+XSBkb19zb2Z0aXJxKzB4MTMvMHgxNQpbMjAxNC0xMi0w
NCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzI1M10gICAgWzxmZmZmODJkMDgwMjJiZDkxPl0g
cHJvY2Vzc19zb2Z0aXJxcysweDIxLzB4MzAKCmV2ZXJ5IHRpbWUgdGhlIHhtZW0gcG9vbCBnZXRz
IGNvcnJ1cHRlZC4gVGhpcyBpcyBvbmx5IGEgaGludCwgdGhvdWdoLiBBCmRldmVsb3BlciB3aWxs
IGhhdmUgdG8gcGxhY2UgeG1lbV9wb29sX2NoZWNrKCkgaW4gdmFyaW91cyBwbGFjZXMgdG8KZGV0
ZXJtaW5lIHRoZSBzb3VyY2Ugb2YgdGhlIGNvcnJ1cHRpb24uIEkgdXNlZCBpdCB0byB0cmFjayBk
b3duIGEgdXNlCmFmdGVyIGZyZWUgYnVnIChkZXRhaWxzIHdpbGwgZm9sbG93IGxhdGVyKS4KClRo
YW5rcywKCi0tIApNaWhhaSBET07ImlUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Dec 04 17:11:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 17:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZw7-0003KM-HC; Thu, 04 Dec 2014 17:11: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 1XwZw6-0003KC-7w
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 17:11:26 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	F1/24-17694-DB590845; Thu, 04 Dec 2014 17:11:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417713075!11017794!1
X-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 24787 invoked from network); 4 Dec 2014 17:11:15 -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; 4 Dec 2014 17:11:15 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 17:11:14 +0000
Message-Id: <5480A3C2020000780004CE26@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 17:11:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<1417694153.31647.32.camel@Abyss.station> <54808B20.9080503@oracle.com>
In-Reply-To: <54808B20.9080503@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: 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,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 04.12.14 at 17:26, <boris.ostrovsky@oracle.com> wrote:
> On 12/04/2014 06:55 AM, Dario Faggioli wrote:
>> On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
>>> This change requires bumping XEN_SYSCTL_INTERFACE_VERSION
>>>
>> Which would not be the case if we take the approach of adding a new,
>> iotopology specific, hcall, would it?
> 
> I would think that any changes to a public interface, including adding a 
> new function, require new version.

No, additions of new sub-ops don't require the version to be bumped.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 17:11:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 17:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwZw7-0003KM-HC; Thu, 04 Dec 2014 17:11: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 1XwZw6-0003KC-7w
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 17:11:26 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	F1/24-17694-DB590845; Thu, 04 Dec 2014 17:11:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417713075!11017794!1
X-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 24787 invoked from network); 4 Dec 2014 17:11:15 -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; 4 Dec 2014 17:11:15 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 04 Dec 2014 17:11:14 +0000
Message-Id: <5480A3C2020000780004CE26@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 04 Dec 2014 17:11:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<1417694153.31647.32.camel@Abyss.station> <54808B20.9080503@oracle.com>
In-Reply-To: <54808B20.9080503@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: 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,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 04.12.14 at 17:26, <boris.ostrovsky@oracle.com> wrote:
> On 12/04/2014 06:55 AM, Dario Faggioli wrote:
>> On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
>>> This change requires bumping XEN_SYSCTL_INTERFACE_VERSION
>>>
>> Which would not be the case if we take the approach of adding a new,
>> iotopology specific, hcall, would it?
> 
> I would think that any changes to a public interface, including adding a 
> new function, require new version.

No, additions of new sub-ops don't require the version to be bumped.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Dec 04 17:25:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 17: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 1Xwa9f-00041r-UE; Thu, 04 Dec 2014 17:25: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 1Xwa9e-00041m-S6
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 17:25:26 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	CF/B9-02696-60990845; Thu, 04 Dec 2014 17:25:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417713925!13069845!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 4761 invoked from network); 4 Dec 2014 17:25:25 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 17:25:25 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xwa9P-000HBS-8S; Thu, 04 Dec 2014 17:25:11 +0000
Date: Thu, 4 Dec 2014 18:25:11 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xenproject.org
Message-ID: <20141204172511.GF43116@deinos.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
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
Subject: [Xen-devel] PVH cleanups after 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

Hi all,

At the Hackathon in Rackspace we discussed a plan to tidy up the
hypervisor side of PVH code so that 'PVH' stops being a separate guest
type, becoming instead a HVM guest with various features disabled (and
one or two other tweaks). 

Although I had hoped to work on that in the meantime, various other
things have got in the way.  But I'd like to at least document the
plan in the hope of getting back on track in the 4.6 development
cycle.

The plan goes something like this:

1. Merge the PVH and HVM hypercall tables.  Patches were already
   posted for this but will need rebasing, and probably more scrutiny.

2. Make PVH-ness a flag on a HVM guest, retaining all the current
   has_hvm_container/is_pvh_domain tests as-is but dropping the
   three-way guest type.

3. Add feature flags to HVM guests that disable various features. 
   These flags should be set once, at domain creation/build, and
   for sanity of testing we should only allow two combinations
   of settings, corresponding to the current HVM and PVH types.
   Make sure that all PVH guests have the PVH feature set.

4. Replace tests for pvh-ness with feature-flag tests wherever
   possible.

5. Fix any outstanding is_pvh tests -- expect this mostly to be 
   feature compatibility with other HVM features (e.g. paging).
   Hopefully we can remove those constraints, or make them constraints
   on a feature set (e.g. can't have PCI passthrough w/out an
   emulated PCI controller).  This also needs an audit of is_hvm tests,
   which are implicitly !is_pvh at the moment.

6. Remove 'PVH' from the hypercall interface, and remove the PVH flag
   from the HVM domain struct.  At this point Xen no longer treats PVH
   and HVM as different (though the tools and the guests themselves
   can maintain the distinction).

Potential feature flags, based on whiteboard notes at the session.
Things that are 'Yes' in both columns might not need actual flags :)

                     'HVM'       'PVH'
64bit hypercalls      Yes         Yes
32bit hypercalls      Yes         No
Paging assistance     Yes         Yes
ioreq-servers         Yes         No
HVM-style CPUID       Yes         Yes
Interrupt controllers Yes         No     ([x2]apic, ioapic, pic &c)
Timers                Yes         No     (rtc, hpet, pit, pmtimer)
Machine Check regs    Yes         Yes
Emulated PCI          Yes         No     (PVH to use pcifront?)

This plan doesn't explicitly add things that we might like to happen
for PVH in 4.6 (e.g. PCI passthrough, compat hypercalls) but it ought
to make some of them easier, and we might get some (e.g. shadow
pagetables) for free as the differences between PVH and HVM go away.

I would like to work on this stuff, but I can't really guarantee to
get anything done for 4.6 in the time I have available.  Any
volunteers to help out would be welcomed!  Likewise, any feedback on
the overall plan is welcome before any more work gets done. :)

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 Dec 04 17:25:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 17: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 1Xwa9f-00041r-UE; Thu, 04 Dec 2014 17:25: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 1Xwa9e-00041m-S6
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 17:25:26 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	CF/B9-02696-60990845; Thu, 04 Dec 2014 17:25:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417713925!13069845!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 4761 invoked from network); 4 Dec 2014 17:25:25 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Dec 2014 17:25:25 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xwa9P-000HBS-8S; Thu, 04 Dec 2014 17:25:11 +0000
Date: Thu, 4 Dec 2014 18:25:11 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xenproject.org
Message-ID: <20141204172511.GF43116@deinos.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
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
Subject: [Xen-devel] PVH cleanups after 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

Hi all,

At the Hackathon in Rackspace we discussed a plan to tidy up the
hypervisor side of PVH code so that 'PVH' stops being a separate guest
type, becoming instead a HVM guest with various features disabled (and
one or two other tweaks). 

Although I had hoped to work on that in the meantime, various other
things have got in the way.  But I'd like to at least document the
plan in the hope of getting back on track in the 4.6 development
cycle.

The plan goes something like this:

1. Merge the PVH and HVM hypercall tables.  Patches were already
   posted for this but will need rebasing, and probably more scrutiny.

2. Make PVH-ness a flag on a HVM guest, retaining all the current
   has_hvm_container/is_pvh_domain tests as-is but dropping the
   three-way guest type.

3. Add feature flags to HVM guests that disable various features. 
   These flags should be set once, at domain creation/build, and
   for sanity of testing we should only allow two combinations
   of settings, corresponding to the current HVM and PVH types.
   Make sure that all PVH guests have the PVH feature set.

4. Replace tests for pvh-ness with feature-flag tests wherever
   possible.

5. Fix any outstanding is_pvh tests -- expect this mostly to be 
   feature compatibility with other HVM features (e.g. paging).
   Hopefully we can remove those constraints, or make them constraints
   on a feature set (e.g. can't have PCI passthrough w/out an
   emulated PCI controller).  This also needs an audit of is_hvm tests,
   which are implicitly !is_pvh at the moment.

6. Remove 'PVH' from the hypercall interface, and remove the PVH flag
   from the HVM domain struct.  At this point Xen no longer treats PVH
   and HVM as different (though the tools and the guests themselves
   can maintain the distinction).

Potential feature flags, based on whiteboard notes at the session.
Things that are 'Yes' in both columns might not need actual flags :)

                     'HVM'       'PVH'
64bit hypercalls      Yes         Yes
32bit hypercalls      Yes         No
Paging assistance     Yes         Yes
ioreq-servers         Yes         No
HVM-style CPUID       Yes         Yes
Interrupt controllers Yes         No     ([x2]apic, ioapic, pic &c)
Timers                Yes         No     (rtc, hpet, pit, pmtimer)
Machine Check regs    Yes         Yes
Emulated PCI          Yes         No     (PVH to use pcifront?)

This plan doesn't explicitly add things that we might like to happen
for PVH in 4.6 (e.g. PCI passthrough, compat hypercalls) but it ought
to make some of them easier, and we might get some (e.g. shadow
pagetables) for free as the differences between PVH and HVM go away.

I would like to work on this stuff, but I can't really guarantee to
get anything done for 4.6 in the time I have available.  Any
volunteers to help out would be welcomed!  Likewise, any feedback on
the overall plan is welcome before any more work gets done. :)

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 Dec 04 18:00:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 18: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 1Xwah9-00053w-Q3; Thu, 04 Dec 2014 18:00: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 1Xwah8-0004zl-0G
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 18:00:02 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	C5/E0-27785-121A0845; Thu, 04 Dec 2014 18:00:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417715999!13053313!1
X-Originating-IP: [156.151.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 27696 invoked from network); 4 Dec 2014 18:00:00 -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; 4 Dec 2014 18: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 sB4HxrAM005531
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 17:59:54 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
	sB4HxqYG006262
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 4 Dec 2014 17:59:53 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
	sB4Hxqlt012722; Thu, 4 Dec 2014 17:59:52 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 04 Dec 2014 09:59:52 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2CF5E11F265; Thu,  4 Dec 2014 12:59:51 -0500 (EST)
Date: Thu, 4 Dec 2014 12:59:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141204175950.GB3409@laptop.dumpdata.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
	<548081E2.3080703@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548081E2.3080703@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org, boris.ostrovsky@oracle.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v5] 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 03:46:42PM +0000, David Vrabel wrote:
> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
> > 
> > These patches fix some issues with PCI back and also add proper
> > bus/slot reset.
> 
> Applied 1-8 to devel/for-linus-3.19.  I did not apply #9.

Excellent. Thank you!
> 
> Thanks.
> 
> David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 18:00:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 18: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 1Xwah9-00053w-Q3; Thu, 04 Dec 2014 18:00: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 1Xwah8-0004zl-0G
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 18:00:02 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	C5/E0-27785-121A0845; Thu, 04 Dec 2014 18:00:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417715999!13053313!1
X-Originating-IP: [156.151.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 27696 invoked from network); 4 Dec 2014 18:00:00 -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; 4 Dec 2014 18: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 sB4HxrAM005531
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 17:59:54 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
	sB4HxqYG006262
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 4 Dec 2014 17:59:53 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
	sB4Hxqlt012722; Thu, 4 Dec 2014 17:59:52 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 04 Dec 2014 09:59:52 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2CF5E11F265; Thu,  4 Dec 2014 12:59:51 -0500 (EST)
Date: Thu, 4 Dec 2014 12:59:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141204175950.GB3409@laptop.dumpdata.com>
References: <1417642834-20350-1-git-send-email-konrad.wilk@oracle.com>
	<548081E2.3080703@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548081E2.3080703@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org, boris.ostrovsky@oracle.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v5] 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 03:46:42PM +0000, David Vrabel wrote:
> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
> > 
> > These patches fix some issues with PCI back and also add proper
> > bus/slot reset.
> 
> Applied 1-8 to devel/for-linus-3.19.  I did not apply #9.

Excellent. Thank you!
> 
> Thanks.
> 
> David

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 18:24:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1Xwb50-0005p0-V3; Thu, 04 Dec 2014 18:24:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xwb50-0005ov-4o
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 18:24:42 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	4D/76-17735-9E6A0845; Thu, 04 Dec 2014 18:24:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417717477!11193560!1
X-Originating-IP: [66.165.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 1051 invoked from network); 4 Dec 2014 18:24:40 -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;
	4 Dec 2014 18:24:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,517,1413244800"; d="scan'208";a="200233470"
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, 4 Dec 2014 13:24: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 1Xwb4t-00016e-JB;
	Thu, 04 Dec 2014 18:24:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xwb4t-0006Di-CF;
	Thu, 04 Dec 2014 18:24:35 +0000
Date: Thu, 4 Dec 2014 18:24:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32083-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 3299
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32083: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0959415559771881137=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0959415559771881137==
Content-Type: text/plain
Content-Length: 2907
Content-Transfer-Encoding: quoted-printable

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32005
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32005
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32005

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              bc3b5681039ce564e543b7e4d2bdc9acdd46f386
baseline version:
 libvirt              ff018e686a8a412255bc34d3dc558a1bcf74fac5

------------------------------------------------------------
People who touched revisions under test:
  Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
  Dmitry Guryanov <dguryanov@parallels.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Laine Stump <laine@laine.org>
  Luyao Huang <lhuang@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>
  Shanzhi Yu <shyu@redhat.com>
  Wang Rui <moon.wangrui@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

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


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

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

--===============0959415559771881137==--

From xen-devel-bounces@lists.xen.org Thu Dec 04 18:24:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 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 1Xwb50-0005p0-V3; Thu, 04 Dec 2014 18:24:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xwb50-0005ov-4o
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 18:24:42 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	4D/76-17735-9E6A0845; Thu, 04 Dec 2014 18:24:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417717477!11193560!1
X-Originating-IP: [66.165.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 1051 invoked from network); 4 Dec 2014 18:24:40 -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;
	4 Dec 2014 18:24:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,517,1413244800"; d="scan'208";a="200233470"
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, 4 Dec 2014 13:24: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 1Xwb4t-00016e-JB;
	Thu, 04 Dec 2014 18:24:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xwb4t-0006Di-CF;
	Thu, 04 Dec 2014 18:24:35 +0000
Date: Thu, 4 Dec 2014 18:24:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32083-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 3299
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32083: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0959415559771881137=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0959415559771881137==
Content-Type: text/plain
Content-Length: 2907
Content-Transfer-Encoding: quoted-printable

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32005
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32005
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32005

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              bc3b5681039ce564e543b7e4d2bdc9acdd46f386
baseline version:
 libvirt              ff018e686a8a412255bc34d3dc558a1bcf74fac5

------------------------------------------------------------
People who touched revisions under test:
  Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
  Dmitry Guryanov <dguryanov@parallels.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Laine Stump <laine@laine.org>
  Luyao Huang <lhuang@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>
  Shanzhi Yu <shyu@redhat.com>
  Wang Rui <moon.wangrui@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

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


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

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

--===============0959415559771881137==--

From xen-devel-bounces@lists.xen.org Thu Dec 04 18:52:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 18:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwbVR-0006mR-CH; Thu, 04 Dec 2014 18:52: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 1XwbVP-0006mI-Tv
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 18:52:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	81/52-09842-F4DA0845; Thu, 04 Dec 2014 18:51:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417719116!10067573!1
X-Originating-IP: [66.165.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 21413 invoked from network); 4 Dec 2014 18:51:58 -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;
	4 Dec 2014 18:51:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,517,1413244800"; d="scan'208";a="200248296"
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, 4 Dec 2014 13:51: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 1XwbUz-0001Em-4x;
	Thu, 04 Dec 2014 18:51:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwbUy-0005Gy-UD;
	Thu, 04 Dec 2014 18:51:32 +0000
Date: Thu, 4 Dec 2014 18:51:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32065-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] 32065: 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 32065 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32065/

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    9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf     13 guest-saverestore.2     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        16 guest-start/debian      fail baseline untested
 test-amd64-i386-rumpuserxen-i386  5 xen-boot            fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install  fail baseline untested
 test-amd64-i386-xl-winxpsp3   7 windows-install         fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install    fail baseline untested
 test-amd64-amd64-xl-win7-amd64  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-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install fail 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-amd64-xl-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-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-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 linux                e85db7e77c6801b854864ee65c264be164dd02c1
baseline version:
 linux                7a5a4f978750756755dc839014e13d1b088ccc8e

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 Thu Dec 04 18:52:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 18:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwbVR-0006mR-CH; Thu, 04 Dec 2014 18:52: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 1XwbVP-0006mI-Tv
	for xen-devel@lists.xensource.com; Thu, 04 Dec 2014 18:52:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	81/52-09842-F4DA0845; Thu, 04 Dec 2014 18:51:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417719116!10067573!1
X-Originating-IP: [66.165.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 21413 invoked from network); 4 Dec 2014 18:51:58 -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;
	4 Dec 2014 18:51:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,517,1413244800"; d="scan'208";a="200248296"
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, 4 Dec 2014 13:51: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 1XwbUz-0001Em-4x;
	Thu, 04 Dec 2014 18:51:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwbUy-0005Gy-UD;
	Thu, 04 Dec 2014 18:51:32 +0000
Date: Thu, 4 Dec 2014 18:51:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32065-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] 32065: 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 32065 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32065/

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    9 guest-start             fail baseline untested
 test-amd64-i386-xl-multivcpu  9 guest-start             fail baseline untested
 test-amd64-amd64-xl           9 guest-start             fail baseline untested
 test-amd64-amd64-xl-sedf     13 guest-saverestore.2     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        16 guest-start/debian      fail baseline untested
 test-amd64-i386-rumpuserxen-i386  5 xen-boot            fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install  fail baseline untested
 test-amd64-i386-xl-winxpsp3   7 windows-install         fail baseline untested
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install    fail baseline untested
 test-amd64-amd64-xl-win7-amd64  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-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install fail 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-amd64-xl-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-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-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass

version targeted for testing:
 linux                e85db7e77c6801b854864ee65c264be164dd02c1
baseline version:
 linux                7a5a4f978750756755dc839014e13d1b088ccc8e

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 Thu Dec 04 19:05:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 19:05:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwbiU-0007TD-Qk; Thu, 04 Dec 2014 19:05:30 +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 1XwbiT-0007T8-28
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 19:05:29 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	41/5B-27785-770B0845; Thu, 04 Dec 2014 19:05:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417719925!13048282!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11469 invoked from network); 4 Dec 2014 19:05:27 -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; 4 Dec 2014 19:05:27 -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 sB4J5IqJ007317
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 19:05:19 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
	sB4J5FW5007414
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 4 Dec 2014 19:05:18 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
	sB4J5FLJ004109; Thu, 4 Dec 2014 19:05:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 04 Dec 2014 11:05:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2A44511F345; Thu,  4 Dec 2014 14:05:14 -0500 (EST)
Date: Thu, 4 Dec 2014 14:05:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>, alex.williamson@redhat.com
Message-ID: <20141204190514.GB4545@laptop.dumpdata.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5480702F.2060004@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sander Eikelenboom <linux@eikelenboom.it>, bhelgaas@google.com,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 02:31:11PM +0000, David Vrabel wrote:
> On 04/12/14 14:09, Sander Eikelenboom wrote:
> > 
> > Thursday, December 4, 2014, 2:43:06 PM, you wrote:
> > 
> >> On 04/12/14 13:10, Sander Eikelenboom wrote:
> >>>
> >>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
> >>>
> >>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
> >>>>>
> >>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> >>>>>>
> >>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
> >>>>>>>
> >>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
> >>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
> >>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
> >>>>>>> It bypasses the need to worry about the PCI lock. 
> >>>>>>
> >>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
> >>>>>> proposed). 
> >>>>>>
> >>>>>
> >>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
> >>>
> >>>> It is only needed if the core won't provide one.
> >>>
> >>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
> >>>> +{
> >>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
> >>>> +       struct device *dev = &pci->dev;
> >>>> +       int ret;
> >>>> +
> >>>> +       /* Already have a per-function reset? */
> >>>> +       if (pci_probe_reset_function(pci) == 0)
> >>>> +               return 0;
> >>>> +
> >>>> +       ret = device_create_file(dev, &dev_attr_reset);
> >>>> +       if (ret < 0)
> >>>> +               return ret;
> >>> +       dev_data->>created_reset_file = true;
> >>>> +       return 0;
> >>>> +}
> >>>
> >>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
> >>> "pci.c:__pci_dev_reset" ?
> >>>
> >>> The problem with that function is that from my testing it seems that the 
> >>> first option "pci_dev_specific_reset" always seems to return succes, so all the
> >>> other options are skipped (flr, pm, slot, bus). However the device it self is 
> >>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
> >>> none virtualization purposes and it's probably the least intrusive. For 
> >>> virtualization however it would be nice to be sure it resets properly, or have a 
> >>> way to force a specific reset routine.)
> > 
> >> Then you need work with the maintainer for those specific devices or
> >> drivers to fix their specific reset function.
> > 
> >> I'm not adding stuff to pciback to workaround broken quirks.
> > 
> > OK that's a pretty clear message there, so if one wants to use pci and vga
> > passthrough one should better use KVM and vfio-pci.
> 
> Have you (or anyone else) ever raised the problem with the broken reset
> quirk for certain devices with the relevant maintainer?
> 
> > vfio-pci has:
> > - logic to do the try-slot-bus-reset logic
> 
> Just because vfio-pci fixed it incorrectly doesn't mean pciback has to
> as well.
> 
> It makes no sense for both pciback and vfio-pci to workaround problems
> with pci_function_reset() in different ways -- it should be fixed in the
> core PCI code so both can benefit and make use of the same code.

We seem to be going in circles.

This thread: http://patchwork.ozlabs.org/patch/368668/

has an interesting discussion that pretty much touches all of this
and I believe it ends with David agreeing with Alex that an
bus-reset is a perfect use-case.

I believe the contention was on how to expose this interface
to the user-space. David's was thinking to use 'reset' while
I used 'do_flr' (which is a misleading name but hte toolstack
already does it). Perhaps we should just have (as David suggested)
an 'bus_reset' on the devices.

I am going to go on a limb and presume that David was thinking
that this 'bus_reset' would be exposed in the generic PCI land?

> 
> David
> 

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 19:05:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 19:05:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwbiU-0007TD-Qk; Thu, 04 Dec 2014 19:05:30 +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 1XwbiT-0007T8-28
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 19:05:29 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	41/5B-27785-770B0845; Thu, 04 Dec 2014 19:05:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417719925!13048282!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11469 invoked from network); 4 Dec 2014 19:05:27 -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; 4 Dec 2014 19:05:27 -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 sB4J5IqJ007317
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 19:05:19 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
	sB4J5FW5007414
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 4 Dec 2014 19:05:18 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
	sB4J5FLJ004109; Thu, 4 Dec 2014 19:05:15 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 04 Dec 2014 11:05:15 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 2A44511F345; Thu,  4 Dec 2014 14:05:14 -0500 (EST)
Date: Thu, 4 Dec 2014 14:05:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>, alex.williamson@redhat.com
Message-ID: <20141204190514.GB4545@laptop.dumpdata.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5480702F.2060004@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sander Eikelenboom <linux@eikelenboom.it>, bhelgaas@google.com,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 02:31:11PM +0000, David Vrabel wrote:
> On 04/12/14 14:09, Sander Eikelenboom wrote:
> > 
> > Thursday, December 4, 2014, 2:43:06 PM, you wrote:
> > 
> >> On 04/12/14 13:10, Sander Eikelenboom wrote:
> >>>
> >>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
> >>>
> >>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
> >>>>>
> >>>>> On Dec 4, 2014 6:30 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> >>>>>>
> >>>>>> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote: 
> >>>>>>>
> >>>>>>> Instead of doing all this complex dance, we depend on the toolstack 
> >>>>>>> doing the right thing. As such implement the 'do_flr' SysFS attribute 
> >>>>>>> which 'xl' uses when a device is detached or attached from/to a guest. 
> >>>>>>> It bypasses the need to worry about the PCI lock. 
> >>>>>>
> >>>>>> No.  Get pciback to add its own "reset" sysfs file (as I have repeatedly 
> >>>>>> proposed). 
> >>>>>>
> >>>>>
> >>>>> Which does not work as the kobj will complain (as there is already an 'reset' associated with the PCI device).
> >>>
> >>>> It is only needed if the core won't provide one.
> >>>
> >>>> +static int pcistub_try_create_reset_file(struct pci_dev *pci)
> >>>> +{
> >>>> +       struct xen_pcibk_dev_data *dev_data = pci_get_drvdata(pci);
> >>>> +       struct device *dev = &pci->dev;
> >>>> +       int ret;
> >>>> +
> >>>> +       /* Already have a per-function reset? */
> >>>> +       if (pci_probe_reset_function(pci) == 0)
> >>>> +               return 0;
> >>>> +
> >>>> +       ret = device_create_file(dev, &dev_attr_reset);
> >>>> +       if (ret < 0)
> >>>> +               return ret;
> >>> +       dev_data->>created_reset_file = true;
> >>>> +       return 0;
> >>>> +}
> >>>
> >>> Wouldn't the "core-reset-sysfs-file" be still wired to the end up calling 
> >>> "pci.c:__pci_dev_reset" ?
> >>>
> >>> The problem with that function is that from my testing it seems that the 
> >>> first option "pci_dev_specific_reset" always seems to return succes, so all the
> >>> other options are skipped (flr, pm, slot, bus). However the device it self is 
> >>> not properly reset enough (perhaps the pci_dev_specific_reset is good enough for 
> >>> none virtualization purposes and it's probably the least intrusive. For 
> >>> virtualization however it would be nice to be sure it resets properly, or have a 
> >>> way to force a specific reset routine.)
> > 
> >> Then you need work with the maintainer for those specific devices or
> >> drivers to fix their specific reset function.
> > 
> >> I'm not adding stuff to pciback to workaround broken quirks.
> > 
> > OK that's a pretty clear message there, so if one wants to use pci and vga
> > passthrough one should better use KVM and vfio-pci.
> 
> Have you (or anyone else) ever raised the problem with the broken reset
> quirk for certain devices with the relevant maintainer?
> 
> > vfio-pci has:
> > - logic to do the try-slot-bus-reset logic
> 
> Just because vfio-pci fixed it incorrectly doesn't mean pciback has to
> as well.
> 
> It makes no sense for both pciback and vfio-pci to workaround problems
> with pci_function_reset() in different ways -- it should be fixed in the
> core PCI code so both can benefit and make use of the same code.

We seem to be going in circles.

This thread: http://patchwork.ozlabs.org/patch/368668/

has an interesting discussion that pretty much touches all of this
and I believe it ends with David agreeing with Alex that an
bus-reset is a perfect use-case.

I believe the contention was on how to expose this interface
to the user-space. David's was thinking to use 'reset' while
I used 'do_flr' (which is a misleading name but hte toolstack
already does it). Perhaps we should just have (as David suggested)
an 'bus_reset' on the devices.

I am going to go on a limb and presume that David was thinking
that this 'bus_reset' would be exposed in the generic PCI land?

> 
> David
> 

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 19:27:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 19:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwc3T-00088n-Tf; Thu, 04 Dec 2014 19:27: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 1Xwc3S-00088i-25
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 19:27:10 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	71/A0-28865-D85B0845; Thu, 04 Dec 2014 19:27:09 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417721225!11670461!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11017 invoked from network); 4 Dec 2014 19:27:05 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 19:27:05 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so37219571wib.3
	for <xen-devel@lists.xenproject.org>;
	Thu, 04 Dec 2014 11:27: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=JZNlK0R2Jb55EL+Hk/OLoS+r1TBEYIDXd/+6XikKrwM=;
	b=i3zV6JbgQmXK2V9/UfpPmyakJVUhQLGgJAUJvKX/YiIxD6GYxb/wArBOTf9wBtcA7w
	8PLnsKL+0WAUzyBafxl7DCtF3SdmN98IkQr9WOxYQZK0DMIvIrshgwrr7OlmoC39isQ7
	OQ1p5kpKN/9ndMBmrUmo2OVqvBlemcw+wQnsBJNycAGu0bU/toueh+PTh0uv8fmt7sIJ
	oZAyc38s0BiBJjW3lq+IJA13EFFsK6V5iJkGCA+5sCj8N8zVs13V0wwSRP8wZOwRROr6
	RKIYO3vD8YLpCwakrDvRCvNhOyZaik19YnFEIHObUp3eksv+1jOUSy6IhHsttTaVXxra
	CIMQ==
X-Gm-Message-State: ALoCoQlHcJBftlud6qiPctUEsxQsJfo/pyBB9TYum/xaMCs3bw1hBwMor2GE6aZj+Bl0ikEwNWeY
X-Received: by 10.194.178.231 with SMTP id db7mr18087059wjc.112.1417721225553; 
	Thu, 04 Dec 2014 11:27:05 -0800 (PST)
Received: from chilopoda.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id gl5sm43037768wib.0.2014.12.04.11.27.04
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Thu, 04 Dec 2014 11:27:04 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Thu,  4 Dec 2014 19:26:55 +0000
Message-Id: <1417721215-32639-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: Correct the opcode for
	BUG_INSTR on arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 0 was forgotten when the arm32 BUG instruction opcode has been added in commit
3e802c6ca1fb9a9549258c2855a57cad483f3cbd "xen/arm: Correctly support WARN_ON".

This will result to use a valid instruction (mcreq 0, 3, r0, cr15, cr0, {7}),
and inhibit usage of BUG/WARN_ON and co.

Signed-off-by: Julien Grall <julien.grall@linaro.org>

---

Not sure, why I dropped the 0 when I implemented the patch...
This is a bug fixed for Xen 4.5. This is only affected ARM32 where the
BUG opcode was malformed.

With the malformed opcode, the ASSERT/BUG_ON is skipped and the
processor may execute another patch (because the compiler has optimized
due the unreachable in both macro).

The code modified is only executed when Xen is in bad state.
---
 xen/include/asm-arm/arm32/bug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/arm32/bug.h b/xen/include/asm-arm/arm32/bug.h
index 155b420..3e66f35 100644
--- a/xen/include/asm-arm/arm32/bug.h
+++ b/xen/include/asm-arm/arm32/bug.h
@@ -6,7 +6,7 @@
 /* ARMv7 provides a list of undefined opcode (see A8.8.247 DDI 0406C.b)
  * Use one them encoding A1 to go in exception mode
  */
-#define BUG_OPCODE  0xe7f00f0
+#define BUG_OPCODE  0xe7f000f0
 
 #define BUG_INSTR ".word " __stringify(BUG_OPCODE)
 
-- 
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 Thu Dec 04 19:27:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 19:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwc3T-00088n-Tf; Thu, 04 Dec 2014 19:27: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 1Xwc3S-00088i-25
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 19:27:10 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	71/A0-28865-D85B0845; Thu, 04 Dec 2014 19:27:09 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417721225!11670461!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11017 invoked from network); 4 Dec 2014 19:27:05 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 19:27:05 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so37219571wib.3
	for <xen-devel@lists.xenproject.org>;
	Thu, 04 Dec 2014 11:27: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=JZNlK0R2Jb55EL+Hk/OLoS+r1TBEYIDXd/+6XikKrwM=;
	b=i3zV6JbgQmXK2V9/UfpPmyakJVUhQLGgJAUJvKX/YiIxD6GYxb/wArBOTf9wBtcA7w
	8PLnsKL+0WAUzyBafxl7DCtF3SdmN98IkQr9WOxYQZK0DMIvIrshgwrr7OlmoC39isQ7
	OQ1p5kpKN/9ndMBmrUmo2OVqvBlemcw+wQnsBJNycAGu0bU/toueh+PTh0uv8fmt7sIJ
	oZAyc38s0BiBJjW3lq+IJA13EFFsK6V5iJkGCA+5sCj8N8zVs13V0wwSRP8wZOwRROr6
	RKIYO3vD8YLpCwakrDvRCvNhOyZaik19YnFEIHObUp3eksv+1jOUSy6IhHsttTaVXxra
	CIMQ==
X-Gm-Message-State: ALoCoQlHcJBftlud6qiPctUEsxQsJfo/pyBB9TYum/xaMCs3bw1hBwMor2GE6aZj+Bl0ikEwNWeY
X-Received: by 10.194.178.231 with SMTP id db7mr18087059wjc.112.1417721225553; 
	Thu, 04 Dec 2014 11:27:05 -0800 (PST)
Received: from chilopoda.uk.xensource.com ([185.25.64.249])
	by mx.google.com with ESMTPSA id gl5sm43037768wib.0.2014.12.04.11.27.04
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Thu, 04 Dec 2014 11:27:04 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Thu,  4 Dec 2014 19:26:55 +0000
Message-Id: <1417721215-32639-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: Correct the opcode for
	BUG_INSTR on arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 0 was forgotten when the arm32 BUG instruction opcode has been added in commit
3e802c6ca1fb9a9549258c2855a57cad483f3cbd "xen/arm: Correctly support WARN_ON".

This will result to use a valid instruction (mcreq 0, 3, r0, cr15, cr0, {7}),
and inhibit usage of BUG/WARN_ON and co.

Signed-off-by: Julien Grall <julien.grall@linaro.org>

---

Not sure, why I dropped the 0 when I implemented the patch...
This is a bug fixed for Xen 4.5. This is only affected ARM32 where the
BUG opcode was malformed.

With the malformed opcode, the ASSERT/BUG_ON is skipped and the
processor may execute another patch (because the compiler has optimized
due the unreachable in both macro).

The code modified is only executed when Xen is in bad state.
---
 xen/include/asm-arm/arm32/bug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/arm32/bug.h b/xen/include/asm-arm/arm32/bug.h
index 155b420..3e66f35 100644
--- a/xen/include/asm-arm/arm32/bug.h
+++ b/xen/include/asm-arm/arm32/bug.h
@@ -6,7 +6,7 @@
 /* ARMv7 provides a list of undefined opcode (see A8.8.247 DDI 0406C.b)
  * Use one them encoding A1 to go in exception mode
  */
-#define BUG_OPCODE  0xe7f00f0
+#define BUG_OPCODE  0xe7f000f0
 
 #define BUG_INSTR ".word " __stringify(BUG_OPCODE)
 
-- 
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 Thu Dec 04 19:35:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 19: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 1XwcAq-00004w-SF; Thu, 04 Dec 2014 19:34: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 1XwcAq-00004r-0o
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 19:34:48 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	58/48-28865-757B0845; Thu, 04 Dec 2014 19:34:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417721685!11617178!1
X-Originating-IP: [156.151.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 2280 invoked from network); 4 Dec 2014 19:34: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; 4 Dec 2014 19:34: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 sB4JYcZJ028239
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 19:34: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
	sB4JYaW3020959
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 4 Dec 2014 19:34:37 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
	sB4JYZ6U023554; Thu, 4 Dec 2014 19:34:36 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 04 Dec 2014 11:34:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id AA0BF11F3A1; Thu,  4 Dec 2014 14:34:34 -0500 (EST)
Date: Thu, 4 Dec 2014 14:34:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141204193434.GB6225@laptop.dumpdata.com>
References: <1417721215-32639-1-git-send-email-julien.grall@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417721215-32639-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, tim@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Correct the opcode for
 BUG_INSTR on arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 07:26:55PM +0000, Julien Grall wrote:
> A 0 was forgotten when the arm32 BUG instruction opcode has been added in commit
> 3e802c6ca1fb9a9549258c2855a57cad483f3cbd "xen/arm: Correctly support WARN_ON".
> 
> This will result to use a valid instruction (mcreq 0, 3, r0, cr15, cr0, {7}),
> and inhibit usage of BUG/WARN_ON and co.
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> 
> ---
> 
> Not sure, why I dropped the 0 when I implemented the patch...
> This is a bug fixed for Xen 4.5. This is only affected ARM32 where the
> BUG opcode was malformed.
> 
> With the malformed opcode, the ASSERT/BUG_ON is skipped and the
> processor may execute another patch (because the compiler has optimized

s/patch/path/ ?

> due the unreachable in both macro).
> 
> The code modified is only executed when Xen is in bad state.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 

> ---
>  xen/include/asm-arm/arm32/bug.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/arm32/bug.h b/xen/include/asm-arm/arm32/bug.h
> index 155b420..3e66f35 100644
> --- a/xen/include/asm-arm/arm32/bug.h
> +++ b/xen/include/asm-arm/arm32/bug.h
> @@ -6,7 +6,7 @@
>  /* ARMv7 provides a list of undefined opcode (see A8.8.247 DDI 0406C.b)
>   * Use one them encoding A1 to go in exception mode
>   */
> -#define BUG_OPCODE  0xe7f00f0
> +#define BUG_OPCODE  0xe7f000f0
>  
>  #define BUG_INSTR ".word " __stringify(BUG_OPCODE)
>  
> -- 
> 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 Thu Dec 04 19:35:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 19: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 1XwcAq-00004w-SF; Thu, 04 Dec 2014 19:34: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 1XwcAq-00004r-0o
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 19:34:48 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	58/48-28865-757B0845; Thu, 04 Dec 2014 19:34:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417721685!11617178!1
X-Originating-IP: [156.151.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 2280 invoked from network); 4 Dec 2014 19:34: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; 4 Dec 2014 19:34: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 sB4JYcZJ028239
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 4 Dec 2014 19:34: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
	sB4JYaW3020959
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 4 Dec 2014 19:34:37 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
	sB4JYZ6U023554; Thu, 4 Dec 2014 19:34:36 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 04 Dec 2014 11:34:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id AA0BF11F3A1; Thu,  4 Dec 2014 14:34:34 -0500 (EST)
Date: Thu, 4 Dec 2014 14:34:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@linaro.org>
Message-ID: <20141204193434.GB6225@laptop.dumpdata.com>
References: <1417721215-32639-1-git-send-email-julien.grall@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417721215-32639-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, tim@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Correct the opcode for
 BUG_INSTR on arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 07:26:55PM +0000, Julien Grall wrote:
> A 0 was forgotten when the arm32 BUG instruction opcode has been added in commit
> 3e802c6ca1fb9a9549258c2855a57cad483f3cbd "xen/arm: Correctly support WARN_ON".
> 
> This will result to use a valid instruction (mcreq 0, 3, r0, cr15, cr0, {7}),
> and inhibit usage of BUG/WARN_ON and co.
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> 
> ---
> 
> Not sure, why I dropped the 0 when I implemented the patch...
> This is a bug fixed for Xen 4.5. This is only affected ARM32 where the
> BUG opcode was malformed.
> 
> With the malformed opcode, the ASSERT/BUG_ON is skipped and the
> processor may execute another patch (because the compiler has optimized

s/patch/path/ ?

> due the unreachable in both macro).
> 
> The code modified is only executed when Xen is in bad state.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 

> ---
>  xen/include/asm-arm/arm32/bug.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/arm32/bug.h b/xen/include/asm-arm/arm32/bug.h
> index 155b420..3e66f35 100644
> --- a/xen/include/asm-arm/arm32/bug.h
> +++ b/xen/include/asm-arm/arm32/bug.h
> @@ -6,7 +6,7 @@
>  /* ARMv7 provides a list of undefined opcode (see A8.8.247 DDI 0406C.b)
>   * Use one them encoding A1 to go in exception mode
>   */
> -#define BUG_OPCODE  0xe7f00f0
> +#define BUG_OPCODE  0xe7f000f0
>  
>  #define BUG_INSTR ".word " __stringify(BUG_OPCODE)
>  
> -- 
> 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 Thu Dec 04 21:23:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 21: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 1Xwdqv-00034Z-FK; Thu, 04 Dec 2014 21:22:21 +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 1Xwdqu-00034U-C8
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 21:22:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3E/4C-15461-B80D0845; Thu, 04 Dec 2014 21:22:19 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417728138!13491560!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6589 invoked from network); 4 Dec 2014 21:22:19 -0000
Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com)
	(209.85.215.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 21:22:19 -0000
Received: by mail-la0-f43.google.com with SMTP id ge10so10573566lab.16
	for <xen-devel@lists.xenproject.org>;
	Thu, 04 Dec 2014 13:22: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=IV4dw4YnsYpamEfK5OUWU5Plo9x2FZpnz5WwAkW4JAk=;
	b=Tyac4NwZ+GDvRJ2ij3w0Y4OWk0IJa6Wq9ufqSO3IZ5YXQb+zHqhmP72UGt2Oiomm/7
	ipk5+2u7AKVOi2Lhlwpe3lt3pCIIB4lHAS3kPQZ8MCogEG+fktQpFDdeGI5y2UeqSSoK
	sQNhg9Ewltrj5145euzofYDprzuNDgbtzTW5ufamj69L1+6ZAsU6bIB2g/mXqbtHdHhj
	JaWx/JvDrjTwSH3lSvNlnzhvOgxI25gfnNRw5BiXo0roaOrNKjU11Go6diXm94FADii0
	1UkbestdwJPh/7YWs8lpuxHi/RfW9x/evSmJ6Eq/UdK6egrH1G0AMVOttxTVYGHyHwhu
	6TSw==
X-Gm-Message-State: ALoCoQkbugKoaMjxQhHhIbUAaHK2p2wuuPvRNUjk/60YWGgMcrI2glv3n0skHqLmwjK2olWRH3Un
MIME-Version: 1.0
X-Received: by 10.112.145.37 with SMTP id sr5mr11990000lbb.76.1417728138135;
	Thu, 04 Dec 2014 13:22:18 -0800 (PST)
Received: by 10.25.151.4 with HTTP; Thu, 4 Dec 2014 13:22:18 -0800 (PST)
In-Reply-To: <548038D5020000780004C9E8@mail.emea.novell.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
Date: Thu, 4 Dec 2014 13:22:18 -0800
Message-ID: <CAFECyb8WJwW=winKPNK6eWeEMRa+RNHa_vLwcmUJo3j1WTo3FQ@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: keir <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
>> Hey,
>>
>> 1) Why is there in EFI code so many functions (e.g. efi_start(),
>>    efi_arch_edd(), ...) with local variables declared as a static?
>>    Though some of them have also regular local variables. I do not
>>    why it was decided that some of them must be the static and
>>    some of do not. It is a bit confusing. As I can see there is
>>    only one place which have to have local static (place_string()).
>>    Other seems to me as thing to save space on the stack but I do
>>    not think we need that. According to UEFI spec there will be
>>    "128 KiB or more of available stack space" when system runs in
>>    boot services mode. It is a lot of space. So, I think we can
>>    safely convert most of local static variables to normal local
>>    variables. Am I right?
>
> No. Consider what code results when you e.g. make an EFI_GUID
> instance non-static.
>
>> 2) I am going to add EDID support to EFI code. Should it be x86
>>    specific code or common one? As I can see EDID is defined as
>>    part of GOP so I think that EDID code should be placed in
>>    xen/common/efi/boot.c.
>
> Yes.
>
>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
>>    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
>>    code than definitions, declarations and short static
>>    functions. So, I think that it is more regular *.c file
>>    than header file.
>
> That's a matter of taste - I'd probably have made it .c too, but
> didn't mind it being .h as done by Roy (presumably on the basis
> that #include directives are preferred to have .h files as their
> operands). The only thing I regret is that I didn't ask for the
> pointless efi- prefix to be dropped.

I don't mind a change here, and I agree that it is more like a .c file
than a .h.  If a name change is done, is it worth dropping the "efi-" at
the same time?


>
> Jan
>

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 21:23:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 21: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 1Xwdqv-00034Z-FK; Thu, 04 Dec 2014 21:22:21 +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 1Xwdqu-00034U-C8
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 21:22:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3E/4C-15461-B80D0845; Thu, 04 Dec 2014 21:22:19 +0000
X-Env-Sender: roy.franz@linaro.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417728138!13491560!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6589 invoked from network); 4 Dec 2014 21:22:19 -0000
Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com)
	(209.85.215.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Dec 2014 21:22:19 -0000
Received: by mail-la0-f43.google.com with SMTP id ge10so10573566lab.16
	for <xen-devel@lists.xenproject.org>;
	Thu, 04 Dec 2014 13:22: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=IV4dw4YnsYpamEfK5OUWU5Plo9x2FZpnz5WwAkW4JAk=;
	b=Tyac4NwZ+GDvRJ2ij3w0Y4OWk0IJa6Wq9ufqSO3IZ5YXQb+zHqhmP72UGt2Oiomm/7
	ipk5+2u7AKVOi2Lhlwpe3lt3pCIIB4lHAS3kPQZ8MCogEG+fktQpFDdeGI5y2UeqSSoK
	sQNhg9Ewltrj5145euzofYDprzuNDgbtzTW5ufamj69L1+6ZAsU6bIB2g/mXqbtHdHhj
	JaWx/JvDrjTwSH3lSvNlnzhvOgxI25gfnNRw5BiXo0roaOrNKjU11Go6diXm94FADii0
	1UkbestdwJPh/7YWs8lpuxHi/RfW9x/evSmJ6Eq/UdK6egrH1G0AMVOttxTVYGHyHwhu
	6TSw==
X-Gm-Message-State: ALoCoQkbugKoaMjxQhHhIbUAaHK2p2wuuPvRNUjk/60YWGgMcrI2glv3n0skHqLmwjK2olWRH3Un
MIME-Version: 1.0
X-Received: by 10.112.145.37 with SMTP id sr5mr11990000lbb.76.1417728138135;
	Thu, 04 Dec 2014 13:22:18 -0800 (PST)
Received: by 10.25.151.4 with HTTP; Thu, 4 Dec 2014 13:22:18 -0800 (PST)
In-Reply-To: <548038D5020000780004C9E8@mail.emea.novell.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
Date: Thu, 4 Dec 2014 13:22:18 -0800
Message-ID: <CAFECyb8WJwW=winKPNK6eWeEMRa+RNHa_vLwcmUJo3j1WTo3FQ@mail.gmail.com>
From: Roy Franz <roy.franz@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: keir <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
>> Hey,
>>
>> 1) Why is there in EFI code so many functions (e.g. efi_start(),
>>    efi_arch_edd(), ...) with local variables declared as a static?
>>    Though some of them have also regular local variables. I do not
>>    why it was decided that some of them must be the static and
>>    some of do not. It is a bit confusing. As I can see there is
>>    only one place which have to have local static (place_string()).
>>    Other seems to me as thing to save space on the stack but I do
>>    not think we need that. According to UEFI spec there will be
>>    "128 KiB or more of available stack space" when system runs in
>>    boot services mode. It is a lot of space. So, I think we can
>>    safely convert most of local static variables to normal local
>>    variables. Am I right?
>
> No. Consider what code results when you e.g. make an EFI_GUID
> instance non-static.
>
>> 2) I am going to add EDID support to EFI code. Should it be x86
>>    specific code or common one? As I can see EDID is defined as
>>    part of GOP so I think that EDID code should be placed in
>>    xen/common/efi/boot.c.
>
> Yes.
>
>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
>>    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
>>    code than definitions, declarations and short static
>>    functions. So, I think that it is more regular *.c file
>>    than header file.
>
> That's a matter of taste - I'd probably have made it .c too, but
> didn't mind it being .h as done by Roy (presumably on the basis
> that #include directives are preferred to have .h files as their
> operands). The only thing I regret is that I didn't ask for the
> pointless efi- prefix to be dropped.

I don't mind a change here, and I agree that it is more like a .c file
than a .h.  If a name change is done, is it worth dropping the "efi-" at
the same time?


>
> Jan
>

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 21:32:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 21:32:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwe0C-0003Sl-HO; Thu, 04 Dec 2014 21:31:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dl9pf@gmx.de>) id 1Xwe0A-0003Sg-SK
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 21:31:54 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	B7/CC-28865-AC2D0845; Thu, 04 Dec 2014 21:31:54 +0000
X-Env-Sender: dl9pf@gmx.de
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417728713!6234311!1
X-Originating-IP: [212.227.17.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjIyID0+IDIxMDU4\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjIyID0+IDIxMDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18834 invoked from network); 4 Dec 2014 21:31:53 -0000
Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.22)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Dec 2014 21:31:53 -0000
Received: from aragorn.auenland.lan ([95.90.138.35]) by mail.gmx.com
	(mrgmx101) with ESMTPSA (Nemesis) id 0Lo2EO-1XTtpI3fbM-00g0WQ;
	Thu, 04 Dec 2014 22:31:52 +0100
From: Jan-Simon Moeller <dl9pf@gmx.de>
To: xen-devel@lists.xenproject.org
Date: Thu, 04 Dec 2014 22:30:29 +0100
Message-ID: <1727998.ort8X4yb3k@aragorn.auenland.lan>
User-Agent: KMail/4.14.3 (Linux/3.17.0-rc51-js2-00622-geae7382; KDE/4.14.3;
	x86_64; ; )
MIME-Version: 1.0
X-Provags-ID: V03:K0:YwaXzee/nSm7wq9VetnffRgJ7wgpGUKeHVpJfA9y21Q2O/7HT4u
	dfz//6j28m+v6fB7XvCcm1dLywdpR102zwcMvPwHVYps+hth4FKXDyn4v0ps5YFrRlBrwDP
	Kv9d88pGiNG3Kgckd9s799oFsYyVv327VEQKNBhKJO8XzvjdWdAtfumToHFUUcKbKhL7pTR
	m2BaMCwtxwmEiF5SeMruA==
X-UI-Out-Filterresults: notjunk:1;
Subject: [Xen-devel] Question about arch/x86/xen/mmu.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

Hi !

My name is Jan-Simon Moeller and I'm looking into compiling the kernel with 
LLVM/Clang (see llvm.linuxfoundation.org) . 

Right now we face this issue when compiling with clang:

 CC      arch/x86/xen/mmu.o
arch/x86/xen/mmu.c:1343:18: error: fields must have a constant size:
     'variable length array in structure' extension will never be
     supported
               DECLARE_BITMAP(mask, num_processors);
                              ^
include/linux/types.h:10:16: note: expanded from macro 'DECLARE_BITMAP'
       unsigned long name[BITS_TO_LONGS(bits)]
                     ^
1 error generated.


Question to the experts: why can't we just use NR_CPUS and be done with it ?
NR_CPUS will be setup by CONFIG_NR_CPUS and thus static.
( e.g. arch/x86/configs/x86_64_defconfig:CONFIG_NR_CPUS=64 )


The code in question is:

static void xen_flush_tlb_others(const struct cpumask *cpus,
				 struct mm_struct *mm, unsigned long start,
				 unsigned long end)
{
	struct {
		struct mmuext_op op;
#ifdef CONFIG_SMP
		DECLARE_BITMAP(mask, num_processors);
#else
		DECLARE_BITMAP(mask, NR_CPUS);
#endif
	} *args;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb_others(cpus, mm, start, end);

	if (cpumask_empty(cpus))
		return;		/* nothing to do */

	mcs = xen_mc_entry(sizeof(*args));
	args = mcs.args;
	args->op.arg2.vcpumask = to_cpumask(args->mask);

	/* Remove us, and any offline CPUS. */
	cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
	cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));

	args->op.cmd = MMUEXT_TLB_FLUSH_MULTI;
	if (end != TLB_FLUSH_ALL && (end - start) <= PAGE_SIZE) {
		args->op.cmd = MMUEXT_INVLPG_MULTI;
		args->op.arg1.linear_addr = start;
	}

	MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}


Pointers:
http://www.slideshare.net/linaroorg/lcu14-209-llvm-linux-39165110  # slide 19
http://lwn.net/Articles/441018/
http://stackoverflow.com/questions/14629504/variable-length-array-in-the-middle-of-struct-why-this-c-code-is-valid-for-gcc




Thanks!

Jan-Simon

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 21:32:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 21:32:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwe0C-0003Sl-HO; Thu, 04 Dec 2014 21:31:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dl9pf@gmx.de>) id 1Xwe0A-0003Sg-SK
	for xen-devel@lists.xenproject.org; Thu, 04 Dec 2014 21:31:54 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	B7/CC-28865-AC2D0845; Thu, 04 Dec 2014 21:31:54 +0000
X-Env-Sender: dl9pf@gmx.de
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417728713!6234311!1
X-Originating-IP: [212.227.17.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjIyID0+IDIxMDU4\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjIyID0+IDIxMDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18834 invoked from network); 4 Dec 2014 21:31:53 -0000
Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.22)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Dec 2014 21:31:53 -0000
Received: from aragorn.auenland.lan ([95.90.138.35]) by mail.gmx.com
	(mrgmx101) with ESMTPSA (Nemesis) id 0Lo2EO-1XTtpI3fbM-00g0WQ;
	Thu, 04 Dec 2014 22:31:52 +0100
From: Jan-Simon Moeller <dl9pf@gmx.de>
To: xen-devel@lists.xenproject.org
Date: Thu, 04 Dec 2014 22:30:29 +0100
Message-ID: <1727998.ort8X4yb3k@aragorn.auenland.lan>
User-Agent: KMail/4.14.3 (Linux/3.17.0-rc51-js2-00622-geae7382; KDE/4.14.3;
	x86_64; ; )
MIME-Version: 1.0
X-Provags-ID: V03:K0:YwaXzee/nSm7wq9VetnffRgJ7wgpGUKeHVpJfA9y21Q2O/7HT4u
	dfz//6j28m+v6fB7XvCcm1dLywdpR102zwcMvPwHVYps+hth4FKXDyn4v0ps5YFrRlBrwDP
	Kv9d88pGiNG3Kgckd9s799oFsYyVv327VEQKNBhKJO8XzvjdWdAtfumToHFUUcKbKhL7pTR
	m2BaMCwtxwmEiF5SeMruA==
X-UI-Out-Filterresults: notjunk:1;
Subject: [Xen-devel] Question about arch/x86/xen/mmu.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

Hi !

My name is Jan-Simon Moeller and I'm looking into compiling the kernel with 
LLVM/Clang (see llvm.linuxfoundation.org) . 

Right now we face this issue when compiling with clang:

 CC      arch/x86/xen/mmu.o
arch/x86/xen/mmu.c:1343:18: error: fields must have a constant size:
     'variable length array in structure' extension will never be
     supported
               DECLARE_BITMAP(mask, num_processors);
                              ^
include/linux/types.h:10:16: note: expanded from macro 'DECLARE_BITMAP'
       unsigned long name[BITS_TO_LONGS(bits)]
                     ^
1 error generated.


Question to the experts: why can't we just use NR_CPUS and be done with it ?
NR_CPUS will be setup by CONFIG_NR_CPUS and thus static.
( e.g. arch/x86/configs/x86_64_defconfig:CONFIG_NR_CPUS=64 )


The code in question is:

static void xen_flush_tlb_others(const struct cpumask *cpus,
				 struct mm_struct *mm, unsigned long start,
				 unsigned long end)
{
	struct {
		struct mmuext_op op;
#ifdef CONFIG_SMP
		DECLARE_BITMAP(mask, num_processors);
#else
		DECLARE_BITMAP(mask, NR_CPUS);
#endif
	} *args;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb_others(cpus, mm, start, end);

	if (cpumask_empty(cpus))
		return;		/* nothing to do */

	mcs = xen_mc_entry(sizeof(*args));
	args = mcs.args;
	args->op.arg2.vcpumask = to_cpumask(args->mask);

	/* Remove us, and any offline CPUS. */
	cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
	cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));

	args->op.cmd = MMUEXT_TLB_FLUSH_MULTI;
	if (end != TLB_FLUSH_ALL && (end - start) <= PAGE_SIZE) {
		args->op.cmd = MMUEXT_INVLPG_MULTI;
		args->op.arg1.linear_addr = start;
	}

	MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}


Pointers:
http://www.slideshare.net/linaroorg/lcu14-209-llvm-linux-39165110  # slide 19
http://lwn.net/Articles/441018/
http://stackoverflow.com/questions/14629504/variable-length-array-in-the-middle-of-struct-why-this-c-code-is-valid-for-gcc




Thanks!

Jan-Simon

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 22:52:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 22: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 1XwfFw-0005ba-1e; Thu, 04 Dec 2014 22:52:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1XwfFu-0005bV-6K
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 22:52:14 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	5D/3C-27623-D95E0845; Thu, 04 Dec 2014 22:52:13 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417733528!11131493!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18036 invoked from network); 4 Dec 2014 22:52:09 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-4.tower-31.messagelabs.com with SMTP;
	4 Dec 2014 22:52:09 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id 05513308E5A;
	Fri,  5 Dec 2014 00:52:06 +0200 (EET)
Message-ID: <5480E595.1010204@iki.fi>
Date: Thu, 04 Dec 2014 22:52:05 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org, 
	rumpkernel-users@lists.sourceforge.net, 
	Anil Madhavapeddy <anil@recoil.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com>
In-Reply-To: <54807253.5000603@citrix.com>
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/12/14 14:40, Andrew Cooper wrote:
> There are already-identified issues such as MiniOS leaking things like
> ARRAY_SIZE() into linked namespaces, which I havn't yet had enough tuits
> to fix.
>
> I think splitting things like the stub libc away from the "MiniOS Xen
> Framework" is also a good idea.  Ideally, the result of a "MiniOS Build"
> would be a small set of .a's which can then be linked against some
> normal C to make a minios guest.  (How feasible this is in reality
> remains to be seen.)

I've become increasingly convinced that we (rump kernels) would like to 
use MiniOS as a small firmware library that just takes care of bootstrap 
and provides a high-level interface to the Xen hypervisor.

A componentized MiniOS is not critical from our perspective, as long as 
you can can compile things out.  We always want the minimal version, and 
can use build flags to produce it.  Notably, thanks to recent work by 
Martin, MiniOS is already compiled to a .o in the rumprun-xen 
repository, and then just linked into the final image.

What is critical for us, however, is reducing the amount of support 
routines needed by MiniOS.  Currently, the software stack in rumprun-xen 
is confusing because MiniOS partially uses libc which runs on top of the 
rump kernel which runs on top of MiniOS...  This confusion springs from 
MiniOS providing its own libc, and while it's ok for standalone MiniOS 
to use its own libc, we do not.  To make things as simple as possible, I 
don't want our [compiled] version of MiniOS to depend on anything from libc.

So, while I agree with everyone that merging is a good idea, the realist 
in me remains in doubt just like you do; is it feasible to both trim 
MiniOS to be minimal enough for our needs and keep it maximal enough for 
yours?  Or does that result in too many ifdef noodles?

>>From a not-public-API point of view, all you have to worry about is that
> the existing minios stuff in xen.git, including the stubdom stuff,
> continues to work.  We have never made any guarantees to anyone using
> minios out-of-tree.

I wonder if work is minimized if we attempt to merge before or after we 
(I?) take the carving knife for a second round in the rumprun-xen repo 
to minimize MiniOS to run only on top of itself.

   - antti

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

From xen-devel-bounces@lists.xen.org Thu Dec 04 22:52:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 04 Dec 2014 22: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 1XwfFw-0005ba-1e; Thu, 04 Dec 2014 22:52:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1XwfFu-0005bV-6K
	for xen-devel@lists.xen.org; Thu, 04 Dec 2014 22:52:14 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	5D/3C-27623-D95E0845; Thu, 04 Dec 2014 22:52:13 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417733528!11131493!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18036 invoked from network); 4 Dec 2014 22:52:09 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-4.tower-31.messagelabs.com with SMTP;
	4 Dec 2014 22:52:09 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id 05513308E5A;
	Fri,  5 Dec 2014 00:52:06 +0200 (EET)
Message-ID: <5480E595.1010204@iki.fi>
Date: Thu, 04 Dec 2014 22:52:05 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org, 
	rumpkernel-users@lists.sourceforge.net, 
	Anil Madhavapeddy <anil@recoil.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com>
In-Reply-To: <54807253.5000603@citrix.com>
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 04/12/14 14:40, Andrew Cooper wrote:
> There are already-identified issues such as MiniOS leaking things like
> ARRAY_SIZE() into linked namespaces, which I havn't yet had enough tuits
> to fix.
>
> I think splitting things like the stub libc away from the "MiniOS Xen
> Framework" is also a good idea.  Ideally, the result of a "MiniOS Build"
> would be a small set of .a's which can then be linked against some
> normal C to make a minios guest.  (How feasible this is in reality
> remains to be seen.)

I've become increasingly convinced that we (rump kernels) would like to 
use MiniOS as a small firmware library that just takes care of bootstrap 
and provides a high-level interface to the Xen hypervisor.

A componentized MiniOS is not critical from our perspective, as long as 
you can can compile things out.  We always want the minimal version, and 
can use build flags to produce it.  Notably, thanks to recent work by 
Martin, MiniOS is already compiled to a .o in the rumprun-xen 
repository, and then just linked into the final image.

What is critical for us, however, is reducing the amount of support 
routines needed by MiniOS.  Currently, the software stack in rumprun-xen 
is confusing because MiniOS partially uses libc which runs on top of the 
rump kernel which runs on top of MiniOS...  This confusion springs from 
MiniOS providing its own libc, and while it's ok for standalone MiniOS 
to use its own libc, we do not.  To make things as simple as possible, I 
don't want our [compiled] version of MiniOS to depend on anything from libc.

So, while I agree with everyone that merging is a good idea, the realist 
in me remains in doubt just like you do; is it feasible to both trim 
MiniOS to be minimal enough for our needs and keep it maximal enough for 
yours?  Or does that result in too many ifdef noodles?

>>From a not-public-API point of view, all you have to worry about is that
> the existing minios stuff in xen.git, including the stubdom stuff,
> continues to work.  We have never made any guarantees to anyone using
> minios out-of-tree.

I wonder if work is minimized if we attempt to merge before or after we 
(I?) take the carving knife for a second round in the rumprun-xen repo 
to minimize MiniOS to run only on top of itself.

   - antti

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 00:01:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 00: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 1XwgKK-0007RI-H2; Fri, 05 Dec 2014 00: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 1XwgKI-0007RD-IS
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 00:00:50 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E6/8C-09284-1B5F0845; Fri, 05 Dec 2014 00:00:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417737647!11183367!1
X-Originating-IP: [66.165.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 25438 invoked from network); 5 Dec 2014 00: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;
	5 Dec 2014 00:00:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,519,1413244800"; d="scan'208";a="200039897"
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, 4 Dec 2014 19: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 1XwgKD-0002id-7e;
	Fri, 05 Dec 2014 00: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 1XwgKB-0005qa-Jz;
	Fri, 05 Dec 2014 00:00:43 +0000
Date: Fri, 5 Dec 2014 00:00:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32066-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] 32066: 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 32066 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32066/

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-multivcpu 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-i386-xl            1 STARTING        running in 32019 [st=running!]
 test-amd64-i386-xl-credit2      <none executed>              broken   in 32019
 test-amd64-i386-qemuu-rhel6hvm-intel 1 STARTING running in 32019 [st=running!]
 test-amd64-i386-xl-win7-amd64    <none executed>              blocked in 32019
 test-amd64-amd64-xl-qemut-winxpsp3  2 STARTING  running in 32019 [st=running!]
 test-amd64-i386-xl-qemut-debianhvm-amd64    <none executed>    broken in 32019
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)  running in 32019 [st=running!]
 test-amd64-amd64-xl-sedf      1 build-check(1)  running in 32019 [st=running!]
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1    <none executed>    broken in 32019
 test-amd64-i386-xl-qemut-winxpsp3    <none executed>          blocked in 32019
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)  running in 32019 [st=running!]

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt      5 xen-boot                    fail pass in 32019
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 32019
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 32019
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3)   broken pass in 32019
 test-amd64-i386-rhel6hvm-intel  5 xen-boot         fail in 32019 pass in 32066
 test-amd64-amd64-xl-qemut-debianhvm-amd64 2 hosts-allocate broken in 32019 pass in 32066
 test-amd64-amd64-xl-pcipt-intel 2 hosts-allocate broken in 32019 pass in 32066

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-amd64-xl-pcipt-intel  3 host-install(3)      broken 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-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-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  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-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-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-armhf-armhf-libvirt      9 guest-start           fail in 32019 never pass
 test-amd64-i386-libvirt       1 build-check(1)            blocked in 32019 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)         blocked in 32019 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)    blocked in 32019 n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 32019 never pass

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

------------------------------------------------------------
700 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                                           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                    broken  
 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                              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                                        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 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-qemut-win7-amd64 host-install(3)
broken test-amd64-i386-xl STARTING running
broken-job test-amd64-i386-xl-credit2 broken
broken test-amd64-i386-qemuu-rhel6hvm-intel STARTING running
broken-job test-amd64-i386-xl-win7-amd64 blocked
broken test-amd64-amd64-xl-qemut-winxpsp3 STARTING running
broken-job test-amd64-i386-xl-qemut-debianhvm-amd64 broken
broken test-amd64-amd64-xl-sedf-pin build-check(1) running
broken test-amd64-amd64-xl-sedf build-check(1) running
broken-job test-amd64-i386-xl-qemut-winxpsp3-vcpus1 broken
broken-job test-amd64-i386-xl-qemut-winxpsp3 blocked
broken test-amd64-amd64-xl-winxpsp3 build-check(1) running

Not pushing.

(No revision log; it would be 30923 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 Dec 05 00:01:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 00: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 1XwgKK-0007RI-H2; Fri, 05 Dec 2014 00: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 1XwgKI-0007RD-IS
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 00:00:50 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E6/8C-09284-1B5F0845; Fri, 05 Dec 2014 00:00:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417737647!11183367!1
X-Originating-IP: [66.165.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 25438 invoked from network); 5 Dec 2014 00: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;
	5 Dec 2014 00:00:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,519,1413244800"; d="scan'208";a="200039897"
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, 4 Dec 2014 19: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 1XwgKD-0002id-7e;
	Fri, 05 Dec 2014 00: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 1XwgKB-0005qa-Jz;
	Fri, 05 Dec 2014 00:00:43 +0000
Date: Fri, 5 Dec 2014 00:00:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32066-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] 32066: 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 32066 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32066/

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-multivcpu 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-i386-xl            1 STARTING        running in 32019 [st=running!]
 test-amd64-i386-xl-credit2      <none executed>              broken   in 32019
 test-amd64-i386-qemuu-rhel6hvm-intel 1 STARTING running in 32019 [st=running!]
 test-amd64-i386-xl-win7-amd64    <none executed>              blocked in 32019
 test-amd64-amd64-xl-qemut-winxpsp3  2 STARTING  running in 32019 [st=running!]
 test-amd64-i386-xl-qemut-debianhvm-amd64    <none executed>    broken in 32019
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)  running in 32019 [st=running!]
 test-amd64-amd64-xl-sedf      1 build-check(1)  running in 32019 [st=running!]
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1    <none executed>    broken in 32019
 test-amd64-i386-xl-qemut-winxpsp3    <none executed>          blocked in 32019
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)  running in 32019 [st=running!]

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt      5 xen-boot                    fail pass in 32019
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 32019
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 32019
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3)   broken pass in 32019
 test-amd64-i386-rhel6hvm-intel  5 xen-boot         fail in 32019 pass in 32066
 test-amd64-amd64-xl-qemut-debianhvm-amd64 2 hosts-allocate broken in 32019 pass in 32066
 test-amd64-amd64-xl-pcipt-intel 2 hosts-allocate broken in 32019 pass in 32066

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-amd64-xl-pcipt-intel  3 host-install(3)      broken 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-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-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  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-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-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-armhf-armhf-libvirt      9 guest-start           fail in 32019 never pass
 test-amd64-i386-libvirt       1 build-check(1)            blocked in 32019 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)         blocked in 32019 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)    blocked in 32019 n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 32019 never pass

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

------------------------------------------------------------
700 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                                           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                    broken  
 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                              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                                        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 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-qemut-win7-amd64 host-install(3)
broken test-amd64-i386-xl STARTING running
broken-job test-amd64-i386-xl-credit2 broken
broken test-amd64-i386-qemuu-rhel6hvm-intel STARTING running
broken-job test-amd64-i386-xl-win7-amd64 blocked
broken test-amd64-amd64-xl-qemut-winxpsp3 STARTING running
broken-job test-amd64-i386-xl-qemut-debianhvm-amd64 broken
broken test-amd64-amd64-xl-sedf-pin build-check(1) running
broken test-amd64-amd64-xl-sedf build-check(1) running
broken-job test-amd64-i386-xl-qemut-winxpsp3-vcpus1 broken
broken-job test-amd64-i386-xl-qemut-winxpsp3 blocked
broken test-amd64-amd64-xl-winxpsp3 build-check(1) running

Not pushing.

(No revision log; it would be 30923 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 Dec 05 00:46:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 00:46:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwh2N-0000TX-KW; Fri, 05 Dec 2014 00:46:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.kilari@gmail.com>) id 1Xwh2L-0000TS-PM
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 00:46:22 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	4C/95-02698-D5001845; Fri, 05 Dec 2014 00:46:21 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417740378!13086912!1
X-Originating-IP: [209.85.213.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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24509 invoked from network); 5 Dec 2014 00:46:19 -0000
Received: from mail-ig0-f182.google.com (HELO mail-ig0-f182.google.com)
	(209.85.213.182)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 00:46:19 -0000
Received: by mail-ig0-f182.google.com with SMTP id hn15so15658536igb.15
	for <xen-devel@lists.xen.org>; Thu, 04 Dec 2014 16:46: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=zcF2ONmFjnSntOfi2oerZ2em1lpPbztVyOARVECi8/I=;
	b=sT4iJsNlxyE22ZL51vL79AYK2s5Af3GlIGS9r4OMls5Ak/uVLJcZXIoHz9dnJRbLvw
	Fww78kxeQ1QmJtitR9KctPTfOha/oKBJDkx2lkMp+ayU4kdd0wpcVWlwt9WFUKirSkkT
	TaPL2pgoRaEMe0DvEQspStkOo5vYyjcCbR9l4lopNjfb6CK+NQ0gNYFRIdnUZzUTYgXS
	BT/e/CZSmd3VVQWyQZHoJQyRuFIT90fZ5GNPvHtuqmU4Sj9JR7jsv9j/RO3qC/fYrdvl
	dJ9f9FpmBeRq3SO3/fm0811dAVQ7ZEArXJtNkJjTWC9PphR+TgG/4YDhTrb3BLCTxvAZ
	5mJQ==
MIME-Version: 1.0
X-Received: by 10.51.17.2 with SMTP id ga2mr90898igd.39.1417740378638; Thu, 04
	Dec 2014 16:46:18 -0800 (PST)
Received: by 10.64.121.194 with HTTP; Thu, 4 Dec 2014 16:46:18 -0800 (PST)
In-Reply-To: <20141204154006.GA43178@deinos.phlegethon.org>
References: <CALicx6trd6Pvsit0LfbC66JU5G3r+1XTt0d-h0DLo8rd31X9vw@mail.gmail.com>
	<548066FE.90905@linaro.org>
	<20141204154006.GA43178@deinos.phlegethon.org>
Date: Fri, 5 Dec 2014 06:16:18 +0530
Message-ID: <CALicx6vVSL3mCxO6jrn2C-O8cFXLiPX=-uPPirB_JW02Bgx4zQ@mail.gmail.com>
From: Vijay Kilari <vijay.kilari@gmail.com>
To: Tim Deegan <tim@xen.org>
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/arm: uart interrupts 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 Tim,

On Thu, Dec 4, 2014 at 9:10 PM, Tim Deegan <tim@xen.org> wrote:
> At 13:51 +0000 on 04 Dec (1417697518), Julien Grall wrote:
>> On 04/12/14 03:50, Vijay Kilari wrote:
>> > Hi Tim,
>>
>> Hi Vijay,
>>
>> > I see that on uart interrupt, ICR is written to clear the all
>> > interrupts except TX, RX and RX timeout. With this, cpu always finds
>> > TX/RX is active and never
>> > comes out of the loop.
>>
>> FWIW, the PL011 serial code has been copied from the Linux drivers.
>>
>> Linux interrupt handler also clear all interrupts except TX, RX, RX
>> timeout. So do you see the issue on Linux?
>>
>> >
>> > With the below changes, TX, RX & RTI are cleared before handling this
>> > interrupts.
>> >
>> > Is my observation is correct?. If so I wonder how it is working on
>> > platforms that
>> > are using pl011. Without this for my cpu just keeps looping here.
>> >
>> >   index fba0a55..d21bce3 100644
>> > --- a/xen/drivers/char/pl011.c
>> > +++ b/xen/drivers/char/pl011.c
>> > @@ -63,7 +63,7 @@ static void pl011_interrupt(int irq, void *data,
>> > struct cpu_user_regs *regs)
>> >      {
>> >          do
>> >          {
>> > -            pl011_write(uart, ICR, status & ~(TXI|RTI|RXI));
>> > +            pl011_write(uart, ICR, status & (TXI|RTI|RXI));
>>
>>
>> This changes looks wrong to me. We want to clear the bit in status we
>> don't handle. Otherwise the interrupt will be fired in loop.
>
> Yes - even if we do want to explicitly clear the TXI|RTI|RXI bits, we
> must clear the others too!
>
>> If I'm not mistaken, TXI/RTI/RXI will be cleared when data is read or
>> write into the fifo. So we should not clear automatically.
>
> I've been looking at that and I think it's OK for the RX path -- we
> ought to keep calling serial_rx_interrupt() until we've drained the
> FIFO, at which point both RTI and RXI will be cleared.  Certainly we
> shouldn't unconditionally clear RXI/RTI without somehow making sure
> that we're not leaving bytes in the FIFO.
>
> The TX path looks more suspect -- if the uart raises TXI and we have
> nothing buffered to send, then TXI won't get cleared.
> Still, I wonder why you're seeing this and other people haven't.

Yes, this is the behaviour that Iam seeing. In Linux, uart driver
masks TXI interrupt
in IMSC if buffer is empty. However in xen, this scenario is not
handled. This is the reason why cpu does not come out of uart irq
routine if TX interrupt is raised but buffer is empty.

I have added below changes to fix this on top of your suggested change

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..ad48df3 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -109,6 +109,8 @@ static void __init pl011_init_preirq(struct
serial_port *port)
             panic("pl011: No Baud rate configured\n");
         uart->baud = (uart->clock_hz << 2) / divisor;
     }
+    /* Trigger RX interrupt at 1/2 full, TX interrupt at 7/8 empty */
+    pl011_write(uart, IFLS, (2<<3 | 0));
     /* This write must follow FBRD and IBRD writes. */
     pl011_write(uart, LCR_H, (uart->data_bits - 5) << 5
                             | FEN
@@ -197,6 +199,20 @@ static const struct vuart_info
*pl011_vuart(struct serial_port *port)
     return &uart->vuart;
 }

+static void pl011_tx_stop(struct serial_port *port)
+{
+    struct pl011 *uart = port->uart;
+
+    pl011_write(uart, IMSC, pl011_read(uart, IMSC) & ~(TXI));
+}
+
+static void pl011_tx_start(struct serial_port *port)
+{
+    struct pl011 *uart = port->uart;
+
+    pl011_write(uart, IMSC, pl011_read(uart, IMSC) | (TXI));
+}
+
 static struct uart_driver __read_mostly pl011_driver = {
     .init_preirq  = pl011_init_preirq,
     .init_postirq = pl011_init_postirq,
@@ -207,6 +223,8 @@ static struct uart_driver __read_mostly pl011_driver = {
     .putc         = pl011_putc,
     .getc         = pl011_getc,
     .irq          = pl011_irq,
+    .start_tx     = pl011_tx_start,
+    .stop_tx      = pl011_tx_stop,
     .vuart_info   = pl011_vuart,
 };

diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
index 44026b1..0f26d40 100644
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -76,6 +76,18 @@ void serial_tx_interrupt(struct serial_port *port,
struct cpu_user_regs *regs)
         cpu_relax();
     }

+    if ( port->txbufc == port->txbufp )
+    {
+        /* Disable TX. nothing to send */
+        port->driver->stop_tx(port);
+        spin_unlock(&port->tx_lock);
+        goto out;
+    }
+    else
+    {
+        if ( port->driver->tx_ready(port) )
+            port->driver->start_tx(port);
+    }
     for ( i = 0, n = port->driver->tx_ready(port); i < n; i++ )
     {
         if ( port->txbufc == port->txbufp )
@@ -117,6 +129,8 @@ static void __serial_putc(struct serial_port *port, char c)
                     cpu_relax();
                 if ( n > 0 )
                 {
+                    /* Enable TX before sending chars */
+                    port->driver->start_tx(port);
                     while ( n-- )
                         port->driver->putc(
                             port,
@@ -135,6 +149,8 @@ static void __serial_putc(struct serial_port *port, char c)
         if ( ((port->txbufp - port->txbufc) == 0) &&
              port->driver->tx_ready(port) > 0 )
         {
+            /* Enable TX before sending chars */
+            port->driver->start_tx(port);
             /* Buffer and UART FIFO are both empty, and port is available. */
             port->driver->putc(port, c);
         }
@@ -152,11 +168,16 @@ static void __serial_putc(struct serial_port
*port, char c)
         while ( !(n = port->driver->tx_ready(port)) )
             cpu_relax();
         if ( n > 0 )
+        {
+            /* Enable TX before sending chars */
+            port->driver->start_tx(port);
             port->driver->putc(port, c);
+        }
     }
     else
     {
         /* Simple synchronous transmitter. */
+        port->driver->start_tx(port);
         port->driver->putc(port, c);
     }
 }
@@ -404,6 +425,7 @@ void serial_start_sync(int handle)
                 /* port is unavailable and might not come up until reenabled by
                    dom0, we can't really do proper sync */
                 break;
+            port->driver->start_tx(port);
             port->driver->putc(
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);
         }
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 9f4451b..71e6ade 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -81,6 +81,10 @@ struct uart_driver {
     int  (*getc)(struct serial_port *, char *);
     /* Get IRQ number for this port's serial line: returns -1 if none. */
     int  (*irq)(struct serial_port *);
+    /* Unmask TX interrupt */
+    void  (*start_tx)(struct serial_port *);
+    /* Mask TX interrupt */
+    void  (*stop_tx)(struct serial_port *);
     /* Get serial information */
     const struct vuart_info *(*vuart_info)(struct serial_port *);
 };

-Vijay

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 00:46:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 00:46:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwh2N-0000TX-KW; Fri, 05 Dec 2014 00:46:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.kilari@gmail.com>) id 1Xwh2L-0000TS-PM
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 00:46:22 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	4C/95-02698-D5001845; Fri, 05 Dec 2014 00:46:21 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417740378!13086912!1
X-Originating-IP: [209.85.213.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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24509 invoked from network); 5 Dec 2014 00:46:19 -0000
Received: from mail-ig0-f182.google.com (HELO mail-ig0-f182.google.com)
	(209.85.213.182)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 00:46:19 -0000
Received: by mail-ig0-f182.google.com with SMTP id hn15so15658536igb.15
	for <xen-devel@lists.xen.org>; Thu, 04 Dec 2014 16:46: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=zcF2ONmFjnSntOfi2oerZ2em1lpPbztVyOARVECi8/I=;
	b=sT4iJsNlxyE22ZL51vL79AYK2s5Af3GlIGS9r4OMls5Ak/uVLJcZXIoHz9dnJRbLvw
	Fww78kxeQ1QmJtitR9KctPTfOha/oKBJDkx2lkMp+ayU4kdd0wpcVWlwt9WFUKirSkkT
	TaPL2pgoRaEMe0DvEQspStkOo5vYyjcCbR9l4lopNjfb6CK+NQ0gNYFRIdnUZzUTYgXS
	BT/e/CZSmd3VVQWyQZHoJQyRuFIT90fZ5GNPvHtuqmU4Sj9JR7jsv9j/RO3qC/fYrdvl
	dJ9f9FpmBeRq3SO3/fm0811dAVQ7ZEArXJtNkJjTWC9PphR+TgG/4YDhTrb3BLCTxvAZ
	5mJQ==
MIME-Version: 1.0
X-Received: by 10.51.17.2 with SMTP id ga2mr90898igd.39.1417740378638; Thu, 04
	Dec 2014 16:46:18 -0800 (PST)
Received: by 10.64.121.194 with HTTP; Thu, 4 Dec 2014 16:46:18 -0800 (PST)
In-Reply-To: <20141204154006.GA43178@deinos.phlegethon.org>
References: <CALicx6trd6Pvsit0LfbC66JU5G3r+1XTt0d-h0DLo8rd31X9vw@mail.gmail.com>
	<548066FE.90905@linaro.org>
	<20141204154006.GA43178@deinos.phlegethon.org>
Date: Fri, 5 Dec 2014 06:16:18 +0530
Message-ID: <CALicx6vVSL3mCxO6jrn2C-O8cFXLiPX=-uPPirB_JW02Bgx4zQ@mail.gmail.com>
From: Vijay Kilari <vijay.kilari@gmail.com>
To: Tim Deegan <tim@xen.org>
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/arm: uart interrupts 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 Tim,

On Thu, Dec 4, 2014 at 9:10 PM, Tim Deegan <tim@xen.org> wrote:
> At 13:51 +0000 on 04 Dec (1417697518), Julien Grall wrote:
>> On 04/12/14 03:50, Vijay Kilari wrote:
>> > Hi Tim,
>>
>> Hi Vijay,
>>
>> > I see that on uart interrupt, ICR is written to clear the all
>> > interrupts except TX, RX and RX timeout. With this, cpu always finds
>> > TX/RX is active and never
>> > comes out of the loop.
>>
>> FWIW, the PL011 serial code has been copied from the Linux drivers.
>>
>> Linux interrupt handler also clear all interrupts except TX, RX, RX
>> timeout. So do you see the issue on Linux?
>>
>> >
>> > With the below changes, TX, RX & RTI are cleared before handling this
>> > interrupts.
>> >
>> > Is my observation is correct?. If so I wonder how it is working on
>> > platforms that
>> > are using pl011. Without this for my cpu just keeps looping here.
>> >
>> >   index fba0a55..d21bce3 100644
>> > --- a/xen/drivers/char/pl011.c
>> > +++ b/xen/drivers/char/pl011.c
>> > @@ -63,7 +63,7 @@ static void pl011_interrupt(int irq, void *data,
>> > struct cpu_user_regs *regs)
>> >      {
>> >          do
>> >          {
>> > -            pl011_write(uart, ICR, status & ~(TXI|RTI|RXI));
>> > +            pl011_write(uart, ICR, status & (TXI|RTI|RXI));
>>
>>
>> This changes looks wrong to me. We want to clear the bit in status we
>> don't handle. Otherwise the interrupt will be fired in loop.
>
> Yes - even if we do want to explicitly clear the TXI|RTI|RXI bits, we
> must clear the others too!
>
>> If I'm not mistaken, TXI/RTI/RXI will be cleared when data is read or
>> write into the fifo. So we should not clear automatically.
>
> I've been looking at that and I think it's OK for the RX path -- we
> ought to keep calling serial_rx_interrupt() until we've drained the
> FIFO, at which point both RTI and RXI will be cleared.  Certainly we
> shouldn't unconditionally clear RXI/RTI without somehow making sure
> that we're not leaving bytes in the FIFO.
>
> The TX path looks more suspect -- if the uart raises TXI and we have
> nothing buffered to send, then TXI won't get cleared.
> Still, I wonder why you're seeing this and other people haven't.

Yes, this is the behaviour that Iam seeing. In Linux, uart driver
masks TXI interrupt
in IMSC if buffer is empty. However in xen, this scenario is not
handled. This is the reason why cpu does not come out of uart irq
routine if TX interrupt is raised but buffer is empty.

I have added below changes to fix this on top of your suggested change

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..ad48df3 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -109,6 +109,8 @@ static void __init pl011_init_preirq(struct
serial_port *port)
             panic("pl011: No Baud rate configured\n");
         uart->baud = (uart->clock_hz << 2) / divisor;
     }
+    /* Trigger RX interrupt at 1/2 full, TX interrupt at 7/8 empty */
+    pl011_write(uart, IFLS, (2<<3 | 0));
     /* This write must follow FBRD and IBRD writes. */
     pl011_write(uart, LCR_H, (uart->data_bits - 5) << 5
                             | FEN
@@ -197,6 +199,20 @@ static const struct vuart_info
*pl011_vuart(struct serial_port *port)
     return &uart->vuart;
 }

+static void pl011_tx_stop(struct serial_port *port)
+{
+    struct pl011 *uart = port->uart;
+
+    pl011_write(uart, IMSC, pl011_read(uart, IMSC) & ~(TXI));
+}
+
+static void pl011_tx_start(struct serial_port *port)
+{
+    struct pl011 *uart = port->uart;
+
+    pl011_write(uart, IMSC, pl011_read(uart, IMSC) | (TXI));
+}
+
 static struct uart_driver __read_mostly pl011_driver = {
     .init_preirq  = pl011_init_preirq,
     .init_postirq = pl011_init_postirq,
@@ -207,6 +223,8 @@ static struct uart_driver __read_mostly pl011_driver = {
     .putc         = pl011_putc,
     .getc         = pl011_getc,
     .irq          = pl011_irq,
+    .start_tx     = pl011_tx_start,
+    .stop_tx      = pl011_tx_stop,
     .vuart_info   = pl011_vuart,
 };

diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
index 44026b1..0f26d40 100644
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -76,6 +76,18 @@ void serial_tx_interrupt(struct serial_port *port,
struct cpu_user_regs *regs)
         cpu_relax();
     }

+    if ( port->txbufc == port->txbufp )
+    {
+        /* Disable TX. nothing to send */
+        port->driver->stop_tx(port);
+        spin_unlock(&port->tx_lock);
+        goto out;
+    }
+    else
+    {
+        if ( port->driver->tx_ready(port) )
+            port->driver->start_tx(port);
+    }
     for ( i = 0, n = port->driver->tx_ready(port); i < n; i++ )
     {
         if ( port->txbufc == port->txbufp )
@@ -117,6 +129,8 @@ static void __serial_putc(struct serial_port *port, char c)
                     cpu_relax();
                 if ( n > 0 )
                 {
+                    /* Enable TX before sending chars */
+                    port->driver->start_tx(port);
                     while ( n-- )
                         port->driver->putc(
                             port,
@@ -135,6 +149,8 @@ static void __serial_putc(struct serial_port *port, char c)
         if ( ((port->txbufp - port->txbufc) == 0) &&
              port->driver->tx_ready(port) > 0 )
         {
+            /* Enable TX before sending chars */
+            port->driver->start_tx(port);
             /* Buffer and UART FIFO are both empty, and port is available. */
             port->driver->putc(port, c);
         }
@@ -152,11 +168,16 @@ static void __serial_putc(struct serial_port
*port, char c)
         while ( !(n = port->driver->tx_ready(port)) )
             cpu_relax();
         if ( n > 0 )
+        {
+            /* Enable TX before sending chars */
+            port->driver->start_tx(port);
             port->driver->putc(port, c);
+        }
     }
     else
     {
         /* Simple synchronous transmitter. */
+        port->driver->start_tx(port);
         port->driver->putc(port, c);
     }
 }
@@ -404,6 +425,7 @@ void serial_start_sync(int handle)
                 /* port is unavailable and might not come up until reenabled by
                    dom0, we can't really do proper sync */
                 break;
+            port->driver->start_tx(port);
             port->driver->putc(
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);
         }
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 9f4451b..71e6ade 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -81,6 +81,10 @@ struct uart_driver {
     int  (*getc)(struct serial_port *, char *);
     /* Get IRQ number for this port's serial line: returns -1 if none. */
     int  (*irq)(struct serial_port *);
+    /* Unmask TX interrupt */
+    void  (*start_tx)(struct serial_port *);
+    /* Mask TX interrupt */
+    void  (*stop_tx)(struct serial_port *);
     /* Get serial information */
     const struct vuart_info *(*vuart_info)(struct serial_port *);
 };

-Vijay

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 01:05:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 01:05:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwhKQ-00055P-Bd; Fri, 05 Dec 2014 01:05:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1XwhKO-00055K-Qx
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 01:05:00 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	B1/6B-19763-CB401845; Fri, 05 Dec 2014 01:05:00 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417741497!11637314!1
X-Originating-IP: [156.151.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 32698 invoked from network); 5 Dec 2014 01:04:59 -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; 5 Dec 2014 01:04: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 sB514sk6016616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 01:04: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
	sB514qSt010817
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 01:04:53 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
	sB514qqD010812; Fri, 5 Dec 2014 01:04:52 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 04 Dec 2014 17:04:52 -0800
Date: Thu, 4 Dec 2014 17:04:50 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Roger Pau =?UTF-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Message-ID: <20141204170450.278bb591@mantra.us.oracle.com>
In-Reply-To: <54808D6F.302@citrix.com>
References: <54808D6F.302@citrix.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Removing the PVH assert in arch/x86/hvm/io.c:87
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCA0IERlYyAyMDE0IDE3OjM1OjU5ICswMTAwClJvZ2VyIFBhdSBNb25uw6kgPHJvZ2Vy
LnBhdUBjaXRyaXguY29tPiB3cm90ZToKCj4gSGVsbG8sCj4gCj4gSSd2ZSBqdXN0IHN0dW1ibGVk
IHVwb24gdGhpcyBhc3NlcnQgd2hpbGUgdGVzdGluZyBQVkggb24gZGlmZmVyZW50Cj4gaGFyZHdh
cmUuIEl0IHdhcyBhZGRlZCBpbiA3YzQ4NzAgYXMgYSBzYWZlIGJlbHQsIGJ1dCBpdCB0dXJucyBv
dXQgSU5TCj4gYW5kIE9VVFMgZ28gdGhyb3VnaCBoYW5kbGVfbW1pby4gU28gdXNpbmcgdGhpcyBp
bnN0cnVjdGlvbnMgZnJvbSBhIFBWSAo+IGd1ZXN0IGJhc2ljYWxseSBraWxscyBYZW4uCgpSaWdo
dC4gVW5mIENSLW1vdmVzL2xtc3cvY2x0cyBpbnRlcmNlcHRzIGFsc28gZ28gdGhydSBoYW5kbGVf
bW1pbywgYW5kCnRoZSBzdWdnZXN0aW9uIHdhcyB0byBjbGVhbiBpdCB1cCBmaXJzdCB3aXRoIGFu
b3RoZXIgZW11bGF0b3IgZnVuY3Rpb24KZm9yIENSL0lPIGludGVyY2VwdHMuIEkgYXR0ZW1wdGVk
IHRvIGRvIHRoYXQgYmVmb3JlIEkgbGVmdCA6CgpodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZl
cy9odG1sL3hlbi1kZXZlbC8yMDE0LTA4L21zZzAyMjA0Lmh0bWwKClNlZSBhbHNvOgoKaHR0cDov
L2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxNC0wOC9tc2cwMDM5MS5o
dG1sCgo+IEkndmUgcmVtb3ZlZCBpdCBhbmQgZXZlcnl0aGluZyBzZWVtcyBmaW5lLCBzbyBJJ20g
Y29uc2lkZXJpbmcgc2VuZGluZwo+IGEgcGF0Y2ggZm9yIDQuNSBpbiBvcmRlciB0byBoYXZlIGl0
IHJlbW92ZWQuIEkgdGhpbmsgdGhlIHBhdGggdGhhdAo+IGNvdWxkIHRyaWdnZXIgdGhlIGNyYXNo
IGJlY2F1c2Ugb2YgdGhlIG1pc3NpbmcgdmlvYXBpYyBzdHVmZiBpcwo+IGFscmVhZHkgZ3VhcmRl
ZCBieSB0aGUgb3RoZXIgY2h1bmsgYWRkZWQgaW4gdGhlIHNhbWUgcGF0Y2guCgpObywgdGhlcmUg
dXNlZCB0byBiZSBhbm90aGVyIHBhdGggdGhydSBodm1faGFwX25lc3RlZF9wYWdlX2ZhdWx0KCkK
dGhhdCB3b3VsZCB3YWxrIHRoZSBiYWNrIGVuZCBoYW5kbGVycyBhbmQgY3Jhc2ggeGVuLiBTbyB5
b3UgbWlnaHQKd2FubmEgY2hlY2sgdG8gbWFrZSBzdXJlLiBJIHNlZSBodm1faGFwX25lc3RlZF9w
YWdlX2ZhdWx0KCkgbG9va3MgYQpsaXR0bGUgZGlmZmVyZW50IG5vdywgc28gbm90IHN1cmUgaWYg
aXRzIHN0aWxsIGJyb2tlbi4uLiAKCk11a2VzaAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Dec 05 01:05:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 01:05:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwhKQ-00055P-Bd; Fri, 05 Dec 2014 01:05:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1XwhKO-00055K-Qx
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 01:05:00 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	B1/6B-19763-CB401845; Fri, 05 Dec 2014 01:05:00 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417741497!11637314!1
X-Originating-IP: [156.151.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 32698 invoked from network); 5 Dec 2014 01:04:59 -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; 5 Dec 2014 01:04: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 sB514sk6016616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 01:04: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
	sB514qSt010817
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 01:04:53 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
	sB514qqD010812; Fri, 5 Dec 2014 01:04:52 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 04 Dec 2014 17:04:52 -0800
Date: Thu, 4 Dec 2014 17:04:50 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Roger Pau =?UTF-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Message-ID: <20141204170450.278bb591@mantra.us.oracle.com>
In-Reply-To: <54808D6F.302@citrix.com>
References: <54808D6F.302@citrix.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Removing the PVH assert in arch/x86/hvm/io.c:87
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCA0IERlYyAyMDE0IDE3OjM1OjU5ICswMTAwClJvZ2VyIFBhdSBNb25uw6kgPHJvZ2Vy
LnBhdUBjaXRyaXguY29tPiB3cm90ZToKCj4gSGVsbG8sCj4gCj4gSSd2ZSBqdXN0IHN0dW1ibGVk
IHVwb24gdGhpcyBhc3NlcnQgd2hpbGUgdGVzdGluZyBQVkggb24gZGlmZmVyZW50Cj4gaGFyZHdh
cmUuIEl0IHdhcyBhZGRlZCBpbiA3YzQ4NzAgYXMgYSBzYWZlIGJlbHQsIGJ1dCBpdCB0dXJucyBv
dXQgSU5TCj4gYW5kIE9VVFMgZ28gdGhyb3VnaCBoYW5kbGVfbW1pby4gU28gdXNpbmcgdGhpcyBp
bnN0cnVjdGlvbnMgZnJvbSBhIFBWSAo+IGd1ZXN0IGJhc2ljYWxseSBraWxscyBYZW4uCgpSaWdo
dC4gVW5mIENSLW1vdmVzL2xtc3cvY2x0cyBpbnRlcmNlcHRzIGFsc28gZ28gdGhydSBoYW5kbGVf
bW1pbywgYW5kCnRoZSBzdWdnZXN0aW9uIHdhcyB0byBjbGVhbiBpdCB1cCBmaXJzdCB3aXRoIGFu
b3RoZXIgZW11bGF0b3IgZnVuY3Rpb24KZm9yIENSL0lPIGludGVyY2VwdHMuIEkgYXR0ZW1wdGVk
IHRvIGRvIHRoYXQgYmVmb3JlIEkgbGVmdCA6CgpodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZl
cy9odG1sL3hlbi1kZXZlbC8yMDE0LTA4L21zZzAyMjA0Lmh0bWwKClNlZSBhbHNvOgoKaHR0cDov
L2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxNC0wOC9tc2cwMDM5MS5o
dG1sCgo+IEkndmUgcmVtb3ZlZCBpdCBhbmQgZXZlcnl0aGluZyBzZWVtcyBmaW5lLCBzbyBJJ20g
Y29uc2lkZXJpbmcgc2VuZGluZwo+IGEgcGF0Y2ggZm9yIDQuNSBpbiBvcmRlciB0byBoYXZlIGl0
IHJlbW92ZWQuIEkgdGhpbmsgdGhlIHBhdGggdGhhdAo+IGNvdWxkIHRyaWdnZXIgdGhlIGNyYXNo
IGJlY2F1c2Ugb2YgdGhlIG1pc3NpbmcgdmlvYXBpYyBzdHVmZiBpcwo+IGFscmVhZHkgZ3VhcmRl
ZCBieSB0aGUgb3RoZXIgY2h1bmsgYWRkZWQgaW4gdGhlIHNhbWUgcGF0Y2guCgpObywgdGhlcmUg
dXNlZCB0byBiZSBhbm90aGVyIHBhdGggdGhydSBodm1faGFwX25lc3RlZF9wYWdlX2ZhdWx0KCkK
dGhhdCB3b3VsZCB3YWxrIHRoZSBiYWNrIGVuZCBoYW5kbGVycyBhbmQgY3Jhc2ggeGVuLiBTbyB5
b3UgbWlnaHQKd2FubmEgY2hlY2sgdG8gbWFrZSBzdXJlLiBJIHNlZSBodm1faGFwX25lc3RlZF9w
YWdlX2ZhdWx0KCkgbG9va3MgYQpsaXR0bGUgZGlmZmVyZW50IG5vdywgc28gbm90IHN1cmUgaWYg
aXRzIHN0aWxsIGJyb2tlbi4uLiAKCk11a2VzaAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Dec 05 01:18:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 01:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwhWt-0005Rl-LQ; Fri, 05 Dec 2014 01:17:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XwhWs-0005Rg-IH
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 01:17:54 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	64/5C-05632-1C701845; Fri, 05 Dec 2014 01:17:53 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417742267!7482773!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30890 invoked from network); 5 Dec 2014 01:17:51 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 01:17:51 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDL51072; Fri, 05 Dec 2014 09:17:26 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Fri, 5 Dec 2014 09:17:16 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIABdSnQ
Date: Fri, 5 Dec 2014 01:17:16 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
In-Reply-To: <20141204105021.GA16532@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Thursday, December 04, 2014 6:50 PM
> To: Zhangleiqiang (Trump)
> Cc: Wei Liu; xen-devel@lists.xen.org; zhangleiqiang; Luohao (brian); Xiaoding
> (B); Yuzhou (C); Zhuangyuxin
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> On Wed, Dec 03, 2014 at 02:43:37PM +0000, Zhangleiqiang (Trump) wrote:
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: Tuesday, December 02, 2014 11:59 PM
> > > To: Zhangleiqiang (Trump)
> > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian);
> > > Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > > multiqueue support
> > >
> > > On Tue, Dec 02, 2014 at 02:46:36PM +0000, Zhangleiqiang (Trump) wrote:
> > > > Thanks for your reply, Wei.
> > > >
> > > > I do the following testing just now and found the results as follows:
> > > >
> > > > There are three DomUs (4U4G) are running on Host A (6U6G) and one
> > > > DomU
> > > (4U4G) is running on Host B (6U6G), I send packets from three DomUs
> > > to the DomU on Host B simultaneously.
> > > >
> > > > 1. The "top" output of Host B as follows:
> > > >
> > > > top - 09:42:11 up  1:07,  2 users,  load average: 2.46, 1.90, 1.47
> > > > Tasks: 173 total,   4 running, 169 sleeping,   0 stopped,   0 zombie
> > > > %Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 97.3 id,  0.0 wa,  0.0 hi,
> > > > 0.8 si,  1.9 st
> > > > %Cpu1  :  0.0 us, 27.0 sy,  0.0 ni, 63.1 id,  0.0 wa,  0.0 hi,
> > > > 9.5 si,  0.4 st
> > > > %Cpu2  :  0.0 us, 90.0 sy,  0.0 ni,  8.3 id,  0.0 wa,  0.0 hi,
> > > > 1.7 si,  0.0 st
> > > > %Cpu3  :  0.4 us,  1.4 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,
> > > > 1.4 si,  1.4 st
> > > > %Cpu4  :  0.0 us, 60.2 sy,  0.0 ni, 39.5 id,  0.0 wa,  0.0 hi,
> > > > 0.3 si,  0.0 st
> > > > %Cpu5  :  0.0 us,  2.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.0 hi,
> > > > 6.9 si,  0.9
> > > st
> > > > KiB Mem:   4517144 total,  3116480 used,  1400664 free,      876
> > > buffers
> > > > KiB Swap:  2103292 total,        0 used,  2103292 free.  2374656
> > > cached Mem
> > > >
> > > >   PID USER      PR  NI    VIRT    RES    SHR
> S  %CPU  %MEM
> > > TIME+ COMMAND
> > > >  7440 root      20   0       0      0      0 R 71.10 0.000
> > > 8:15.38 vif4.0-q3-guest
> > > >  7434 root      20   0       0      0      0 R 59.14 0.000
> > > 9:00.58 vif4.0-q0-guest
> > > >    18 root      20   0       0      0      0 R 33.89 0.000
> > > 2:35.06 ksoftirqd/2
> > > >    28 root      20   0       0      0      0 S 20.93 0.000
> > > 3:01.81 ksoftirqd/4
> > > >
> > > >
> > > > As shown above, only two netback related processes (vif4.0-*) are
> > > > running
> > > with high cpu usage, and the other 2 netback processes are idle. The "ps"
> > > result of vif4.0-* processes as follows:
> > > >
> > > > root      7434 50.5  0.0      0     0 ?        R    09:23
> 11:29
> > > [vif4.0-q0-guest]
> > > > root      7435  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q0-deall]
> > > > root      7436  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q1-guest]
> > > > root      7437  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q1-deall]
> > > > root      7438  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q2-guest]
> > > > root      7439  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q2-deall]
> > > > root      7440 48.1  0.0      0     0 ?        R    09:23
> 10:55
> > > [vif4.0-q3-guest]
> > > > root      7441  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q3-deall]
> > > > root      9724  0.0  0.0   9244  1520 pts/0    S+   09:46
> 0:00
> > > grep --color=auto
> > > >
> > > >
> > > > 2. The "rx" related content in /proc/interupts in receiver DomU (on Host
> B):
> > > >
> > > > 73: 	2		0		2925405		0			xen-dyn-event
> > > 	eth0-q0-rx
> > > > 75: 	43		93		0			118			xen-dyn-event
> > > 	eth0-q1-rx
> > > > 77: 	2		3376	14			1983		xen-dyn-event
> > > 	eth0-q2-rx
> > > > 79: 	2414666	0		9			0			xen-dyn-event
> > > 	eth0-q3-rx
> > > >
> > > > As shown above, it seems like that only q0 and q3 handles the
> > > > interrupt
> > > triggered by packet receving.
> > > >
> > > > Any advise? Thanks.
> > >
> > > Netback selects queue based on the return value of
> skb_get_queue_mapping.
> > > The queue mapping is set by core driver or ndo_select_queue (if
> > > specified by individual driver). In this case netback doesn't have
> > > its implementation of ndo_select_queue, so it's up to core driver to
> > > decide which queue to dispatch the packet to.  I think you need to
> > > inspect why Dom0 only steers traffic to these two queues but not all of
> them.
> > >
> > > Don't know which utility is handy for this job. Probably tc(8) is useful?
> >
> > Thanks Wei.
> >
> 
> > I think the reason for the above results that only two
> > netback/netfront processes works hard is the queue select method. I
> > have tried to send packets from multiple host/vm to a vm, and all of
> > the netback/netfront processes are running with high cpu usage a few
> > times.
> >
> 
> A few times? You might want to check some patches to rework RX stall
> detection by David Vrabel that went in after 3.16.
> 
> > However, I find another issue. Even using 6 queues and making sure
> > that all of these 6 netback processes running with high cpu usage
> > (indeed, any of it running with 87% cpu usage), the whole VM receive
> > throughout is not very higher than results when using 4 queues. The
> > results are from 4.5Gbps to 5.04 Gbps using TCP with 512 bytes length
> > and 4.3Gbps to 5.78Gbps using TCP with 1460 bytes length.
> >
> 
> I would like to ask if you're still using 4U4G (4 CPU 4 G?) configuration? If so,
> please make sure there are at least the same number of vcpus as queues.
> 
> > According to the testing result from WIKI:
> > http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_perf
> > ormance_testing, The VM receive throughput is also more lower than VM
> > transmit.
> >
> 
> I think that's expected, because guest RX data path still uses grant_copy while
> guest TX uses grant_map to do zero-copy transmit.

As far as I know, there are three main grant-related operations used in split device model: grant mapping, grant transfer and grant copy. 
Grant transfer has not used now, and grant mapping and grant transfer both involve "TLB" refresh work for hypervisor, am I right?  Or only grant transfer has this overhead?
Does grant copy surely has more overhead than grant mapping? 

>From the code, I see that in TX, netback will do gnttab_batch_copy as well as gnttab_map_refs:

<code> //netback.c:xenvif_tx_action
	xenvif_tx_build_gops(queue, budget, &nr_cops, &nr_mops);

	if (nr_cops == 0)
		return 0;

	gnttab_batch_copy(queue->tx_copy_ops, nr_cops);
	if (nr_mops != 0) {
		ret = gnttab_map_refs(queue->tx_map_ops,
				      NULL,
				      queue->pages_to_map,
				      nr_mops);
		BUG_ON(ret);
	}
</code>

> > I am wondering why the VM receive throughout cannot be up to 8-10Gbps
> > as VM transmit under multi-queue?  I also tried to send packets
> > directly from Local Dom0 to DomU, the DomU receive throughput can
> > reach about 8-12Gbps, so I am also wondering why transmitting packets
> > from Dom0 to Remote DomU can only reach about 4-5Gbps throughout?
> 
> If data is from Dom0 to DomU then SKB is probably not fragmented by network
> stack.  You can use tcpdump to check that.
> 
> Wei.
> 
> >
> > > Wei.
> > >
> > > > ----------
> > > > zhangleiqiang (Trump)
> > > >
> > > > Best Regards
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > > > Sent: Tuesday, December 02, 2014 8:12 PM
> > > > > To: Zhangleiqiang (Trump)
> > > > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao
> > > > > (brian); Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > > > Subject: Re: [Xen-devel] Poor network performance between DomU
> > > > > with multiqueue support
> > > > >
> > > > > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump)
> wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: xen-devel-bounces@lists.xen.org
> > > > > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei
> > > > > > > Liu
> > > > > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > > > > To: zhangleiqiang
> > > > > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > > > > Subject: Re: [Xen-devel] Poor network performance between
> > > > > > > DomU with multiqueue support
> > > > > > >
> > > > > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > > > > > Hi, all
> > > > > > > >     I am testing the performance of xen netfront-netback
> > > > > > > > driver that with
> > > > > > > multi-queues support. The throughput from domU to remote
> > > > > > > dom0 is 9.2Gb/s, but the throughput from domU to remote domU
> > > > > > > is only 3.6Gb/s, I think the bottleneck is the throughput
> > > > > > > from dom0 to local domU. However, we have done some testing
> > > > > > > and found the throughput from dom0 to local domU is 5.8Gb/s.
> > > > > > > >     And if we send packets from one DomU to other 3 DomUs
> > > > > > > > on different
> > > > > > > host simultaneously, the sum of throughout can reach 9Gbps.
> > > > > > > It seems like the bottleneck is the receiver?
> > > > > > > >     After some analysis, I found that even the max_queue
> > > > > > > > of netfront/back
> > > > > > > is set to 4, there are some strange results as follows:
> > > > > > > >     1. In domU, only one rx queue deal with softirq
> > > > > > >
> > > > > > > Try to bind irq to different vcpus?
> > > > > >
> > > > > > Do you mean we try to bind irq to different vcpus in DomU? I
> > > > > > will try it
> > > now.
> > > > > >
> > > > >
> > > > > Yes. Given the fact that you have two backend threads running
> > > > > while only one DomU vcpu is busy, it smells like misconfiguration in
> DomU.
> > > > >
> > > > > If this phenomenon persists after correctly binding irqs, you
> > > > > might want to check traffic is steering correctly to different queues.
> > > > >
> > > > > > >
> > > > > > > >     2. In dom0, only two netback queues process are
> > > > > > > > scheduled, other two
> > > > > > > process aren't scheduled.
> > > > > > >
> > > > > > > How many Dom0 vcpu do you have? If it only has two then
> > > > > > > there will only be two processes running at a time.
> > > > > >
> > > > > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU
> > > > > > running in
> > > > > Dom0 and so four netback processes are running in Dom0 (because
> > > > > the max_queue param of netback kernel module is set to 4).
> > > > > > The phenomenon is that only 2 of these four netback process
> > > > > > were running
> > > > > with about 70% cpu usage, and another two use little CPU.
> > > > > > Is there a hash algorithm to determine which netback process
> > > > > > to handle the
> > > > > input packet?
> > > > > >
> > > > >
> > > > > I think that's whatever default algorithm Linux kernel is using.
> > > > >
> > > > > We don't currently support other algorithms.
> > > > >
> > > > > Wei.

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 01:18:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 01:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwhWt-0005Rl-LQ; Fri, 05 Dec 2014 01:17:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XwhWs-0005Rg-IH
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 01:17:54 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	64/5C-05632-1C701845; Fri, 05 Dec 2014 01:17:53 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417742267!7482773!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30890 invoked from network); 5 Dec 2014 01:17:51 -0000
Received: from szxga02-in.huawei.com (HELO szxga02-in.huawei.com)
	(119.145.14.65)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 01:17:51 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDL51072; Fri, 05 Dec 2014 09:17:26 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.177]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Fri, 5 Dec 2014 09:17:16 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIABdSnQ
Date: Fri, 5 Dec 2014 01:17:16 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
In-Reply-To: <20141204105021.GA16532@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Thursday, December 04, 2014 6:50 PM
> To: Zhangleiqiang (Trump)
> Cc: Wei Liu; xen-devel@lists.xen.org; zhangleiqiang; Luohao (brian); Xiaoding
> (B); Yuzhou (C); Zhuangyuxin
> Subject: Re: [Xen-devel] Poor network performance between DomU with
> multiqueue support
> 
> On Wed, Dec 03, 2014 at 02:43:37PM +0000, Zhangleiqiang (Trump) wrote:
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: Tuesday, December 02, 2014 11:59 PM
> > > To: Zhangleiqiang (Trump)
> > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao (brian);
> > > Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > Subject: Re: [Xen-devel] Poor network performance between DomU with
> > > multiqueue support
> > >
> > > On Tue, Dec 02, 2014 at 02:46:36PM +0000, Zhangleiqiang (Trump) wrote:
> > > > Thanks for your reply, Wei.
> > > >
> > > > I do the following testing just now and found the results as follows:
> > > >
> > > > There are three DomUs (4U4G) are running on Host A (6U6G) and one
> > > > DomU
> > > (4U4G) is running on Host B (6U6G), I send packets from three DomUs
> > > to the DomU on Host B simultaneously.
> > > >
> > > > 1. The "top" output of Host B as follows:
> > > >
> > > > top - 09:42:11 up  1:07,  2 users,  load average: 2.46, 1.90, 1.47
> > > > Tasks: 173 total,   4 running, 169 sleeping,   0 stopped,   0 zombie
> > > > %Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 97.3 id,  0.0 wa,  0.0 hi,
> > > > 0.8 si,  1.9 st
> > > > %Cpu1  :  0.0 us, 27.0 sy,  0.0 ni, 63.1 id,  0.0 wa,  0.0 hi,
> > > > 9.5 si,  0.4 st
> > > > %Cpu2  :  0.0 us, 90.0 sy,  0.0 ni,  8.3 id,  0.0 wa,  0.0 hi,
> > > > 1.7 si,  0.0 st
> > > > %Cpu3  :  0.4 us,  1.4 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,
> > > > 1.4 si,  1.4 st
> > > > %Cpu4  :  0.0 us, 60.2 sy,  0.0 ni, 39.5 id,  0.0 wa,  0.0 hi,
> > > > 0.3 si,  0.0 st
> > > > %Cpu5  :  0.0 us,  2.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.0 hi,
> > > > 6.9 si,  0.9
> > > st
> > > > KiB Mem:   4517144 total,  3116480 used,  1400664 free,      876
> > > buffers
> > > > KiB Swap:  2103292 total,        0 used,  2103292 free.  2374656
> > > cached Mem
> > > >
> > > >   PID USER      PR  NI    VIRT    RES    SHR
> S  %CPU  %MEM
> > > TIME+ COMMAND
> > > >  7440 root      20   0       0      0      0 R 71.10 0.000
> > > 8:15.38 vif4.0-q3-guest
> > > >  7434 root      20   0       0      0      0 R 59.14 0.000
> > > 9:00.58 vif4.0-q0-guest
> > > >    18 root      20   0       0      0      0 R 33.89 0.000
> > > 2:35.06 ksoftirqd/2
> > > >    28 root      20   0       0      0      0 S 20.93 0.000
> > > 3:01.81 ksoftirqd/4
> > > >
> > > >
> > > > As shown above, only two netback related processes (vif4.0-*) are
> > > > running
> > > with high cpu usage, and the other 2 netback processes are idle. The "ps"
> > > result of vif4.0-* processes as follows:
> > > >
> > > > root      7434 50.5  0.0      0     0 ?        R    09:23
> 11:29
> > > [vif4.0-q0-guest]
> > > > root      7435  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q0-deall]
> > > > root      7436  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q1-guest]
> > > > root      7437  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q1-deall]
> > > > root      7438  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q2-guest]
> > > > root      7439  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q2-deall]
> > > > root      7440 48.1  0.0      0     0 ?        R    09:23
> 10:55
> > > [vif4.0-q3-guest]
> > > > root      7441  0.0  0.0      0     0 ?        S    09:23
> 0:00
> > > [vif4.0-q3-deall]
> > > > root      9724  0.0  0.0   9244  1520 pts/0    S+   09:46
> 0:00
> > > grep --color=auto
> > > >
> > > >
> > > > 2. The "rx" related content in /proc/interupts in receiver DomU (on Host
> B):
> > > >
> > > > 73: 	2		0		2925405		0			xen-dyn-event
> > > 	eth0-q0-rx
> > > > 75: 	43		93		0			118			xen-dyn-event
> > > 	eth0-q1-rx
> > > > 77: 	2		3376	14			1983		xen-dyn-event
> > > 	eth0-q2-rx
> > > > 79: 	2414666	0		9			0			xen-dyn-event
> > > 	eth0-q3-rx
> > > >
> > > > As shown above, it seems like that only q0 and q3 handles the
> > > > interrupt
> > > triggered by packet receving.
> > > >
> > > > Any advise? Thanks.
> > >
> > > Netback selects queue based on the return value of
> skb_get_queue_mapping.
> > > The queue mapping is set by core driver or ndo_select_queue (if
> > > specified by individual driver). In this case netback doesn't have
> > > its implementation of ndo_select_queue, so it's up to core driver to
> > > decide which queue to dispatch the packet to.  I think you need to
> > > inspect why Dom0 only steers traffic to these two queues but not all of
> them.
> > >
> > > Don't know which utility is handy for this job. Probably tc(8) is useful?
> >
> > Thanks Wei.
> >
> 
> > I think the reason for the above results that only two
> > netback/netfront processes works hard is the queue select method. I
> > have tried to send packets from multiple host/vm to a vm, and all of
> > the netback/netfront processes are running with high cpu usage a few
> > times.
> >
> 
> A few times? You might want to check some patches to rework RX stall
> detection by David Vrabel that went in after 3.16.
> 
> > However, I find another issue. Even using 6 queues and making sure
> > that all of these 6 netback processes running with high cpu usage
> > (indeed, any of it running with 87% cpu usage), the whole VM receive
> > throughout is not very higher than results when using 4 queues. The
> > results are from 4.5Gbps to 5.04 Gbps using TCP with 512 bytes length
> > and 4.3Gbps to 5.78Gbps using TCP with 1460 bytes length.
> >
> 
> I would like to ask if you're still using 4U4G (4 CPU 4 G?) configuration? If so,
> please make sure there are at least the same number of vcpus as queues.
> 
> > According to the testing result from WIKI:
> > http://wiki.xen.org/wiki/Xen-netback_and_xen-netfront_multi-queue_perf
> > ormance_testing, The VM receive throughput is also more lower than VM
> > transmit.
> >
> 
> I think that's expected, because guest RX data path still uses grant_copy while
> guest TX uses grant_map to do zero-copy transmit.

As far as I know, there are three main grant-related operations used in split device model: grant mapping, grant transfer and grant copy. 
Grant transfer has not used now, and grant mapping and grant transfer both involve "TLB" refresh work for hypervisor, am I right?  Or only grant transfer has this overhead?
Does grant copy surely has more overhead than grant mapping? 

>From the code, I see that in TX, netback will do gnttab_batch_copy as well as gnttab_map_refs:

<code> //netback.c:xenvif_tx_action
	xenvif_tx_build_gops(queue, budget, &nr_cops, &nr_mops);

	if (nr_cops == 0)
		return 0;

	gnttab_batch_copy(queue->tx_copy_ops, nr_cops);
	if (nr_mops != 0) {
		ret = gnttab_map_refs(queue->tx_map_ops,
				      NULL,
				      queue->pages_to_map,
				      nr_mops);
		BUG_ON(ret);
	}
</code>

> > I am wondering why the VM receive throughout cannot be up to 8-10Gbps
> > as VM transmit under multi-queue?  I also tried to send packets
> > directly from Local Dom0 to DomU, the DomU receive throughput can
> > reach about 8-12Gbps, so I am also wondering why transmitting packets
> > from Dom0 to Remote DomU can only reach about 4-5Gbps throughout?
> 
> If data is from Dom0 to DomU then SKB is probably not fragmented by network
> stack.  You can use tcpdump to check that.
> 
> Wei.
> 
> >
> > > Wei.
> > >
> > > > ----------
> > > > zhangleiqiang (Trump)
> > > >
> > > > Best Regards
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > > > Sent: Tuesday, December 02, 2014 8:12 PM
> > > > > To: Zhangleiqiang (Trump)
> > > > > Cc: Wei Liu; zhangleiqiang; xen-devel@lists.xen.org; Luohao
> > > > > (brian); Xiaoding (B); Yuzhou (C); Zhuangyuxin
> > > > > Subject: Re: [Xen-devel] Poor network performance between DomU
> > > > > with multiqueue support
> > > > >
> > > > > On Tue, Dec 02, 2014 at 11:50:59AM +0000, Zhangleiqiang (Trump)
> wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: xen-devel-bounces@lists.xen.org
> > > > > > > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wei
> > > > > > > Liu
> > > > > > > Sent: Tuesday, December 02, 2014 7:02 PM
> > > > > > > To: zhangleiqiang
> > > > > > > Cc: wei.liu2@citrix.com; xen-devel@lists.xen.org
> > > > > > > Subject: Re: [Xen-devel] Poor network performance between
> > > > > > > DomU with multiqueue support
> > > > > > >
> > > > > > > On Tue, Dec 02, 2014 at 04:30:49PM +0800, zhangleiqiang wrote:
> > > > > > > > Hi, all
> > > > > > > >     I am testing the performance of xen netfront-netback
> > > > > > > > driver that with
> > > > > > > multi-queues support. The throughput from domU to remote
> > > > > > > dom0 is 9.2Gb/s, but the throughput from domU to remote domU
> > > > > > > is only 3.6Gb/s, I think the bottleneck is the throughput
> > > > > > > from dom0 to local domU. However, we have done some testing
> > > > > > > and found the throughput from dom0 to local domU is 5.8Gb/s.
> > > > > > > >     And if we send packets from one DomU to other 3 DomUs
> > > > > > > > on different
> > > > > > > host simultaneously, the sum of throughout can reach 9Gbps.
> > > > > > > It seems like the bottleneck is the receiver?
> > > > > > > >     After some analysis, I found that even the max_queue
> > > > > > > > of netfront/back
> > > > > > > is set to 4, there are some strange results as follows:
> > > > > > > >     1. In domU, only one rx queue deal with softirq
> > > > > > >
> > > > > > > Try to bind irq to different vcpus?
> > > > > >
> > > > > > Do you mean we try to bind irq to different vcpus in DomU? I
> > > > > > will try it
> > > now.
> > > > > >
> > > > >
> > > > > Yes. Given the fact that you have two backend threads running
> > > > > while only one DomU vcpu is busy, it smells like misconfiguration in
> DomU.
> > > > >
> > > > > If this phenomenon persists after correctly binding irqs, you
> > > > > might want to check traffic is steering correctly to different queues.
> > > > >
> > > > > > >
> > > > > > > >     2. In dom0, only two netback queues process are
> > > > > > > > scheduled, other two
> > > > > > > process aren't scheduled.
> > > > > > >
> > > > > > > How many Dom0 vcpu do you have? If it only has two then
> > > > > > > there will only be two processes running at a time.
> > > > > >
> > > > > > Dom0 has 6 vcpus, and 6G memory. There are only one DomU
> > > > > > running in
> > > > > Dom0 and so four netback processes are running in Dom0 (because
> > > > > the max_queue param of netback kernel module is set to 4).
> > > > > > The phenomenon is that only 2 of these four netback process
> > > > > > were running
> > > > > with about 70% cpu usage, and another two use little CPU.
> > > > > > Is there a hash algorithm to determine which netback process
> > > > > > to handle the
> > > > > input packet?
> > > > > >
> > > > >
> > > > > I think that's whatever default algorithm Linux kernel is using.
> > > > >
> > > > > We don't currently support other algorithms.
> > > > >
> > > > > Wei.

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 01:33:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 01:33:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwhlP-00061j-5B; Fri, 05 Dec 2014 01:32:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwhlN-00061e-Tg
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 01:32:54 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	34/A7-02702-54B01845; Fri, 05 Dec 2014 01:32:53 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417743171!13133547!1
X-Originating-IP: [66.165.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 9368 invoked from network); 5 Dec 2014 01:32:52 -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;
	5 Dec 2014 01:32:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,519,1413244800"; d="scan'208";a="200448594"
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, 4 Dec 2014 20:32: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 1XwhlI-0003AL-Ra;
	Fri, 05 Dec 2014 01:32:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwhlI-0008Kc-4c;
	Fri, 05 Dec 2014 01:32:48 +0000
Date: Fri, 5 Dec 2014 01:32:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32069-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-upstream-unstable test] 32069: tolerable trouble:
	broken/fail/pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32069 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32069/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 32024
 test-amd64-i386-freebsd10-amd64  3 host-install(3)        broken pass in 32024
 test-armhf-armhf-libvirt      4 xen-install        fail in 32024 pass in 32069

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

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-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-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-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-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-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-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                1ebb75b1fee779621b63e84fefa7b07354c43a99
baseline version:
 qemuu                a230ec3101ddda868252c036ea960af2b2d6cd5a

------------------------------------------------------------
People who touched revisions under test:
  Jason Wang <jasowang@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                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-i386-freebsd10-amd64 host-install(3)

Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=1ebb75b1fee779621b63e84fefa7b07354c43a99
+ . 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 1ebb75b1fee779621b63e84fefa7b07354c43a99
+ branch=qemu-upstream-unstable
+ revision=1ebb75b1fee779621b63e84fefa7b07354c43a99
+ . 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 1ebb75b1fee779621b63e84fefa7b07354c43a99:master
To osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
   a230ec3..1ebb75b  1ebb75b1fee779621b63e84fefa7b07354c43a99 -> master

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 01:33:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 01:33:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwhlP-00061j-5B; Fri, 05 Dec 2014 01:32:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwhlN-00061e-Tg
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 01:32:54 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	34/A7-02702-54B01845; Fri, 05 Dec 2014 01:32:53 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417743171!13133547!1
X-Originating-IP: [66.165.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 9368 invoked from network); 5 Dec 2014 01:32:52 -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;
	5 Dec 2014 01:32:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,519,1413244800"; d="scan'208";a="200448594"
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, 4 Dec 2014 20:32: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 1XwhlI-0003AL-Ra;
	Fri, 05 Dec 2014 01:32:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwhlI-0008Kc-4c;
	Fri, 05 Dec 2014 01:32:48 +0000
Date: Fri, 5 Dec 2014 01:32:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32069-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-upstream-unstable test] 32069: tolerable trouble:
	broken/fail/pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32069 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32069/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 32024
 test-amd64-i386-freebsd10-amd64  3 host-install(3)        broken pass in 32024
 test-armhf-armhf-libvirt      4 xen-install        fail in 32024 pass in 32069

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

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-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-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-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-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-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-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                1ebb75b1fee779621b63e84fefa7b07354c43a99
baseline version:
 qemuu                a230ec3101ddda868252c036ea960af2b2d6cd5a

------------------------------------------------------------
People who touched revisions under test:
  Jason Wang <jasowang@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                           fail    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-i386-freebsd10-amd64 host-install(3)

Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=1ebb75b1fee779621b63e84fefa7b07354c43a99
+ . 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 1ebb75b1fee779621b63e84fefa7b07354c43a99
+ branch=qemu-upstream-unstable
+ revision=1ebb75b1fee779621b63e84fefa7b07354c43a99
+ . 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 1ebb75b1fee779621b63e84fefa7b07354c43a99:master
To osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
   a230ec3..1ebb75b  1ebb75b1fee779621b63e84fefa7b07354c43a99 -> master

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 01:54:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 01: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 1Xwi5i-0006fp-F4; Fri, 05 Dec 2014 01:53:54 +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 1Xwi5h-0006fk-9r
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 01:53:53 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	69/D4-02699-E2011845; Fri, 05 Dec 2014 01:53:50 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417744428!13142071!1
X-Originating-IP: [206.212.254.10]
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 2641 invoked from network); 5 Dec 2014 01:53:49 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2014 01:53:49 -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
	sB51rfxo019491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 4 Dec 2014 20:53:41 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sB51relA019489;
	Thu, 4 Dec 2014 20:53:40 -0500
Date: Thu, 4 Dec 2014 21:53:40 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141205015340.GA19424@andromeda.dapyr.net>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
	<20141202183620.GE32385@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202183620.GE32385@laptop.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
	target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> 
> This usage scenario which I can see this being useful (and
> I've tripped over this) is when you rebuild a new version
> from the same repo. As in, this affects developers, but


Lets get it in. It fixes an issues that I keep on tripping
on and it is harmless enough that I don't see a way
for this to cause any regressions.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> not end-users and not distros. But perhaps I am missing
> one scenario?
> 
> As such I would lean towards deferring this (and the other
> two) to Xen 4.6.
> 
> Thank you!
> > ---
> >  tools/Makefile         |    3 +++
> >  tools/hotplug/Makefile |    5 ++++-
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/Makefile b/tools/Makefile
> > index af9798a..19b24f3 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -261,6 +261,9 @@ subdir-all-debugger/kdd: .phony
> >  subdir-distclean-firmware: .phony
> >  	$(MAKE) -C firmware distclean
> >  
> > +subdir-distclean-hotplug: .phony
> > +	$(MAKE) -C hotplug distclean
> > +
> >  subtree-force-update:
> >  ifeq ($(CONFIG_QEMU_XEN),y)
> >  	$(MAKE) qemu-xen-dir-force-update
> > diff --git a/tools/hotplug/Makefile b/tools/hotplug/Makefile
> > index 14ae9a8..a29a522 100644
> > --- a/tools/hotplug/Makefile
> > +++ b/tools/hotplug/Makefile
> > @@ -6,5 +6,8 @@ SUBDIRS-$(CONFIG_NetBSD) += NetBSD
> >  SUBDIRS-$(CONFIG_Linux) += Linux
> >  SUBDIRS-$(CONFIG_FreeBSD) += FreeBSD
> >  
> > -.PHONY: all clean install
> > +.PHONY: all clean distclean install
> >  all clean install: %: subdirs-%
> > +
> > +distclean:
> > +	rm -f Linux/init.d/sysconfig.xencommons Linux/init.d/xencommons NetBSD/rc.d/xencommons
> > -- 
> > 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 Dec 05 01:54:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 01: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 1Xwi5i-0006fp-F4; Fri, 05 Dec 2014 01:53:54 +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 1Xwi5h-0006fk-9r
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 01:53:53 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	69/D4-02699-E2011845; Fri, 05 Dec 2014 01:53:50 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417744428!13142071!1
X-Originating-IP: [206.212.254.10]
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 2641 invoked from network); 5 Dec 2014 01:53:49 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2014 01:53:49 -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
	sB51rfxo019491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 4 Dec 2014 20:53:41 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sB51relA019489;
	Thu, 4 Dec 2014 20:53:40 -0500
Date: Thu, 4 Dec 2014 21:53:40 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141205015340.GA19424@andromeda.dapyr.net>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
	<20141202183620.GE32385@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202183620.GE32385@laptop.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
	target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> 
> This usage scenario which I can see this being useful (and
> I've tripped over this) is when you rebuild a new version
> from the same repo. As in, this affects developers, but


Lets get it in. It fixes an issues that I keep on tripping
on and it is harmless enough that I don't see a way
for this to cause any regressions.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> not end-users and not distros. But perhaps I am missing
> one scenario?
> 
> As such I would lean towards deferring this (and the other
> two) to Xen 4.6.
> 
> Thank you!
> > ---
> >  tools/Makefile         |    3 +++
> >  tools/hotplug/Makefile |    5 ++++-
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/Makefile b/tools/Makefile
> > index af9798a..19b24f3 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -261,6 +261,9 @@ subdir-all-debugger/kdd: .phony
> >  subdir-distclean-firmware: .phony
> >  	$(MAKE) -C firmware distclean
> >  
> > +subdir-distclean-hotplug: .phony
> > +	$(MAKE) -C hotplug distclean
> > +
> >  subtree-force-update:
> >  ifeq ($(CONFIG_QEMU_XEN),y)
> >  	$(MAKE) qemu-xen-dir-force-update
> > diff --git a/tools/hotplug/Makefile b/tools/hotplug/Makefile
> > index 14ae9a8..a29a522 100644
> > --- a/tools/hotplug/Makefile
> > +++ b/tools/hotplug/Makefile
> > @@ -6,5 +6,8 @@ SUBDIRS-$(CONFIG_NetBSD) += NetBSD
> >  SUBDIRS-$(CONFIG_Linux) += Linux
> >  SUBDIRS-$(CONFIG_FreeBSD) += FreeBSD
> >  
> > -.PHONY: all clean install
> > +.PHONY: all clean distclean install
> >  all clean install: %: subdirs-%
> > +
> > +distclean:
> > +	rm -f Linux/init.d/sysconfig.xencommons Linux/init.d/xencommons NetBSD/rc.d/xencommons
> > -- 
> > 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 Dec 05 02:02:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 02: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 1XwiE9-0007NJ-F9; Fri, 05 Dec 2014 02:02:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XwiE7-0007NE-D9
	for Xen-devel@lists.xen.org; Fri, 05 Dec 2014 02:02:35 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	15/69-11581-A3211845; Fri, 05 Dec 2014 02:02:34 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417744953!4076348!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 6632 invoked from network); 5 Dec 2014 02:02:34 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-206.messagelabs.com with SMTP;
	5 Dec 2014 02:02:34 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 04 Dec 2014 18:02:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="425300642"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by FMSMGA003.fm.intel.com with ESMTP; 04 Dec 2014 17:51:39 -0800
Message-ID: <548111CC.1070300@linux.intel.com>
Date: Fri, 05 Dec 2014 10:00:44 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417698806-26807-3-git-send-email-yu.c.zhang@linux.intel.com>
	<20141204160445.GD43116@deinos.phlegethon.org>
In-Reply-To: <20141204160445.GD43116@deinos.phlegethon.org>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, JBeulich@suse.com,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v5 2/2] add a new p2m type -
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/5/2014 12:04 AM, Tim Deegan wrote:
> Hi,
>
> At 21:13 +0800 on 04 Dec (1417724006), Yu Zhang wrote:
>> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
>> the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
>> model, and will be discarded later in __hvm_copy(); while for the
>> p2m_mmio_write_dm type pages, writes will go to the device model
>> via ioreq-server.
>>
>> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
>> Signed-off-by: Wei Ye <wei.ye@intel.com>
>
> Thanks for this -- only two comments:
>
>> @@ -5978,7 +5982,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>>                   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 )
>
> I think that Jan already brough this up, and maybe I missed your
> answer: this realaxation looks wrong to me. I would have thought that
> transition between p2m_mmio_write_dm and p2m_ram_rw/p2m_ram_logdirty
> would be the only ones you would want to allow.

Ha. Sorry, my negligence, and thanks for pointing out. :)
The transition we use now is only between p2m_mmio_write_dm and 
p2m_ram_rw. So how about this:

     if ( !p2m_is_ram(t) &&
          (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) &&
          (t != p2m_mmio_write_dm || a.hvmmem_type != HVMMEM_ram_rw) )

>
>> @@ -111,7 +112,8 @@ typedef unsigned int p2m_query_t;
>>   #define P2M_RO_TYPES (p2m_to_mask(p2m_ram_logdirty)     \
>>                         | p2m_to_mask(p2m_ram_ro)         \
>>                         | p2m_to_mask(p2m_grant_map_ro)   \
>> -                      | p2m_to_mask(p2m_ram_shared) )
>> +                      | p2m_to_mask(p2m_ram_shared)   \
>> +                      | p2m_to_mask(p2m_mmio_write_dm))
>
> Nit: please align the '\' with the others above it.
Got it, and thanks.

B.R.
Yu
>
> Cheers,
>
> Tim.
>
>

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 02:02:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 02: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 1XwiE9-0007NJ-F9; Fri, 05 Dec 2014 02:02:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XwiE7-0007NE-D9
	for Xen-devel@lists.xen.org; Fri, 05 Dec 2014 02:02:35 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	15/69-11581-A3211845; Fri, 05 Dec 2014 02:02:34 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417744953!4076348!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 6632 invoked from network); 5 Dec 2014 02:02:34 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-206.messagelabs.com with SMTP;
	5 Dec 2014 02:02:34 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 04 Dec 2014 18:02:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="425300642"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by FMSMGA003.fm.intel.com with ESMTP; 04 Dec 2014 17:51:39 -0800
Message-ID: <548111CC.1070300@linux.intel.com>
Date: Fri, 05 Dec 2014 10:00:44 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417698806-26807-3-git-send-email-yu.c.zhang@linux.intel.com>
	<20141204160445.GD43116@deinos.phlegethon.org>
In-Reply-To: <20141204160445.GD43116@deinos.phlegethon.org>
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, JBeulich@suse.com,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v5 2/2] add a new p2m type -
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/5/2014 12:04 AM, Tim Deegan wrote:
> Hi,
>
> At 21:13 +0800 on 04 Dec (1417724006), Yu Zhang wrote:
>> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
>> the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
>> model, and will be discarded later in __hvm_copy(); while for the
>> p2m_mmio_write_dm type pages, writes will go to the device model
>> via ioreq-server.
>>
>> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
>> Signed-off-by: Wei Ye <wei.ye@intel.com>
>
> Thanks for this -- only two comments:
>
>> @@ -5978,7 +5982,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>>                   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 )
>
> I think that Jan already brough this up, and maybe I missed your
> answer: this realaxation looks wrong to me. I would have thought that
> transition between p2m_mmio_write_dm and p2m_ram_rw/p2m_ram_logdirty
> would be the only ones you would want to allow.

Ha. Sorry, my negligence, and thanks for pointing out. :)
The transition we use now is only between p2m_mmio_write_dm and 
p2m_ram_rw. So how about this:

     if ( !p2m_is_ram(t) &&
          (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) &&
          (t != p2m_mmio_write_dm || a.hvmmem_type != HVMMEM_ram_rw) )

>
>> @@ -111,7 +112,8 @@ typedef unsigned int p2m_query_t;
>>   #define P2M_RO_TYPES (p2m_to_mask(p2m_ram_logdirty)     \
>>                         | p2m_to_mask(p2m_ram_ro)         \
>>                         | p2m_to_mask(p2m_grant_map_ro)   \
>> -                      | p2m_to_mask(p2m_ram_shared) )
>> +                      | p2m_to_mask(p2m_ram_shared)   \
>> +                      | p2m_to_mask(p2m_mmio_write_dm))
>
> Nit: please align the '\' with the others above it.
Got it, and thanks.

B.R.
Yu
>
> Cheers,
>
> Tim.
>
>

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 02:15:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 02: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 1XwiQb-00080b-4I; Fri, 05 Dec 2014 02:15:29 +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 1XwiQZ-00080U-7q
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 02:15:27 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	95/3E-26858-E3511845; Fri, 05 Dec 2014 02:15:26 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417745724!11133638!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11374 invoked from network); 5 Dec 2014 02:15:25 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2014 02:15:25 -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
	sB52F909020879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 4 Dec 2014 21:15:09 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sB52F8pJ020877;
	Thu, 4 Dec 2014 21:15:08 -0500
Date: Thu, 4 Dec 2014 22:15:08 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141205021508.GB19424@andromeda.dapyr.net>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
	<20141204074756.GA4505@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141204074756.GA4505@aepfle.de>
User-Agent: Mutt/1.5.9i
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.xen.org,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
	use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 08:47:56AM +0100, Olaf Hering wrote:
> On Wed, Dec 03, M A Young wrote:
> 
> > On Wed, 3 Dec 2014, Konrad Rzeszutek Wilk wrote:
> > >Options=mode=755,context="$XENSTORED_MOUNT_CTX"
> > 
> > Yes, that was on my probable bug list, as context="none" isn't a valid mount
> > option (on Fedora at least), presumably because context has to be followed
> > by a valid selinux context.
> 
> Is that something the sysadmin has to adjust, or should the xen source
> provide proper values?

It would be rather cumbersome if the sysadmin had to adjust it. The goal
here would be that distros could use it and package it neatly so that it
works out of the box.

What are the proper values in SuSE?
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 05 02:15:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 02: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 1XwiQb-00080b-4I; Fri, 05 Dec 2014 02:15:29 +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 1XwiQZ-00080U-7q
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 02:15:27 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	95/3E-26858-E3511845; Fri, 05 Dec 2014 02:15:26 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417745724!11133638!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11374 invoked from network); 5 Dec 2014 02:15:25 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2014 02:15:25 -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
	sB52F909020879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 4 Dec 2014 21:15:09 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sB52F8pJ020877;
	Thu, 4 Dec 2014 21:15:08 -0500
Date: Thu, 4 Dec 2014 22:15:08 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141205021508.GB19424@andromeda.dapyr.net>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
	<20141204074756.GA4505@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141204074756.GA4505@aepfle.de>
User-Agent: Mutt/1.5.9i
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.xen.org,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
	use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 08:47:56AM +0100, Olaf Hering wrote:
> On Wed, Dec 03, M A Young wrote:
> 
> > On Wed, 3 Dec 2014, Konrad Rzeszutek Wilk wrote:
> > >Options=mode=755,context="$XENSTORED_MOUNT_CTX"
> > 
> > Yes, that was on my probable bug list, as context="none" isn't a valid mount
> > option (on Fedora at least), presumably because context has to be followed
> > by a valid selinux context.
> 
> Is that something the sysadmin has to adjust, or should the xen source
> provide proper values?

It would be rather cumbersome if the sysadmin had to adjust it. The goal
here would be that distros could use it and package it neatly so that it
works out of the box.

What are the proper values in SuSE?
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 05 02:19:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 02:19:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwiUY-00089o-SB; Fri, 05 Dec 2014 02:19:34 +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 1XwiUX-00089j-V2
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 02:19:34 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	A5/00-25714-43611845; Fri, 05 Dec 2014 02:19:32 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417745969!6368709!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32696 invoked from network); 5 Dec 2014 02:19:31 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2014 02:19:31 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	sB52JRil020954
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 4 Dec 2014 21:19:27 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sB52JQsW020952;
	Thu, 4 Dec 2014 21:19:26 -0500
Date: Thu, 4 Dec 2014 22:19:26 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205021926.GC19424@andromeda.dapyr.net>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5480748B020000780004CBFC@mail.emea.novell.com>
User-Agent: Mutt/1.5.9i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-develList <xen-devel@lists.xen.org>,
	Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>
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 Thu, Dec 04, 2014 at 01:49:47PM +0000, Jan Beulich wrote:
> >>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
> > 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.
> 
> With no-one else voicing an opinion:
> 
> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
> 
> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
> 
> For the latter, we're fine even without further consideration. For the
> former, the two operations actively using the continuation encoding
> are tools-only ones. Since we're fine to alter the tools only interfaces,
> and since it was intended for the tools-only HVM-ops to be split off
> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
> would then no longer be a problem. Plus, in the worst case we could
> always introduce yet another hypercall if we ran out of numbers.
> 
> Consequently what I'd like to propose (and I guess I'll craft a patch
> as soon as I finished this mail) is that we add comments to these
> masks (also the memop one) to make clear that they mustn't change.
> Additionally for forward compatibility I'd also like to add checks for
> the upper bits to be zero for any of the sub-ops that don't actually
> use them to encode continuation information. Konrad, would you
> consider doing so acceptable for 4.5?

Yes.

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

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 02:19:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 02:19:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwiUY-00089o-SB; Fri, 05 Dec 2014 02:19:34 +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 1XwiUX-00089j-V2
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 02:19:34 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	A5/00-25714-43611845; Fri, 05 Dec 2014 02:19:32 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417745969!6368709!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32696 invoked from network); 5 Dec 2014 02:19:31 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2014 02:19:31 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	sB52JRil020954
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 4 Dec 2014 21:19:27 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sB52JQsW020952;
	Thu, 4 Dec 2014 21:19:26 -0500
Date: Thu, 4 Dec 2014 22:19:26 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205021926.GC19424@andromeda.dapyr.net>
References: <54785E46.4080107@citrix.com>
	<5478819F020000780004B70D@mail.emea.novell.com>
	<54787ED8.2010508@citrix.com>
	<5478A056020000780004B7CE@mail.emea.novell.com>
	<547898E7.30400@citrix.com>
	<5480748B020000780004CBFC@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5480748B020000780004CBFC@mail.emea.novell.com>
User-Agent: Mutt/1.5.9i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-develList <xen-devel@lists.xen.org>,
	Tim Deegan <tim@xen.org>, IanCampbell <Ian.Campbell@citrix.com>
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 Thu, Dec 04, 2014 at 01:49:47PM +0000, Jan Beulich wrote:
> >>> On 28.11.14 at 16:46, <andrew.cooper3@citrix.com> wrote:
> > 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.
> 
> With no-one else voicing an opinion:
> 
> For hvmop, the mask currently is 8 bits and we've got 22 ops defined.
> 
> For gnttabop, the mask currently is 12 bits and we've got 12 ops defined.
> 
> For the latter, we're fine even without further consideration. For the
> former, the two operations actively using the continuation encoding
> are tools-only ones. Since we're fine to alter the tools only interfaces,
> and since it was intended for the tools-only HVM-ops to be split off
> to a separate hypercall (e.g. hvmctl) anyway, the range restriction
> would then no longer be a problem. Plus, in the worst case we could
> always introduce yet another hypercall if we ran out of numbers.
> 
> Consequently what I'd like to propose (and I guess I'll craft a patch
> as soon as I finished this mail) is that we add comments to these
> masks (also the memop one) to make clear that they mustn't change.
> Additionally for forward compatibility I'd also like to add checks for
> the upper bits to be zero for any of the sub-ops that don't actually
> use them to encode continuation information. Konrad, would you
> consider doing so acceptable for 4.5?

Yes.

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

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 03:15:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 03: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 1XwjMX-0001KZ-Ep; Fri, 05 Dec 2014 03:15: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 1XwjMV-0001KU-T8
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 03:15:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8A/6D-15461-74321845; Fri, 05 Dec 2014 03:15:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417749316!13212404!1
X-Originating-IP: [66.165.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 31922 invoked from network); 5 Dec 2014 03:15:18 -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;
	5 Dec 2014 03:15:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,519,1413244800"; d="scan'208";a="200514980"
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, 4 Dec 2014 22:15: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 1XwjMR-0003eW-Bf;
	Fri, 05 Dec 2014 03:15:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwjMR-0006fV-5K;
	Fri, 05 Dec 2014 03:15:15 +0000
Date: Fri, 5 Dec 2014 03:15:15 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32084-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] 32084: 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 32084 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32084/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          66b09d00078908e61d0f0c1b87fc140ed8c91e06
baseline version:
 rumpuserxen          f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d

------------------------------------------------------------
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=66b09d00078908e61d0f0c1b87fc140ed8c91e06
+ . 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 66b09d00078908e61d0f0c1b87fc140ed8c91e06
+ branch=rumpuserxen
+ revision=66b09d00078908e61d0f0c1b87fc140ed8c91e06
+ . 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 66b09d00078908e61d0f0c1b87fc140ed8c91e06:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   f302fca..66b09d0  66b09d00078908e61d0f0c1b87fc140ed8c91e06 -> 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 Dec 05 03:15:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 03: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 1XwjMX-0001KZ-Ep; Fri, 05 Dec 2014 03:15: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 1XwjMV-0001KU-T8
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 03:15:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8A/6D-15461-74321845; Fri, 05 Dec 2014 03:15:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417749316!13212404!1
X-Originating-IP: [66.165.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 31922 invoked from network); 5 Dec 2014 03:15:18 -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;
	5 Dec 2014 03:15:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,519,1413244800"; d="scan'208";a="200514980"
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, 4 Dec 2014 22:15: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 1XwjMR-0003eW-Bf;
	Fri, 05 Dec 2014 03:15:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwjMR-0006fV-5K;
	Fri, 05 Dec 2014 03:15:15 +0000
Date: Fri, 5 Dec 2014 03:15:15 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32084-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] 32084: 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 32084 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32084/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          66b09d00078908e61d0f0c1b87fc140ed8c91e06
baseline version:
 rumpuserxen          f302fca6c18c1ccdefe3d0d5f583e2d0970c2e2d

------------------------------------------------------------
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=66b09d00078908e61d0f0c1b87fc140ed8c91e06
+ . 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 66b09d00078908e61d0f0c1b87fc140ed8c91e06
+ branch=rumpuserxen
+ revision=66b09d00078908e61d0f0c1b87fc140ed8c91e06
+ . 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 66b09d00078908e61d0f0c1b87fc140ed8c91e06:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   f302fca..66b09d0  66b09d00078908e61d0f0c1b87fc140ed8c91e06 -> 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 Dec 05 04:48:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 04: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 1Xwko5-0003fv-Lv; Fri, 05 Dec 2014 04:47:53 +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 1Xwko3-0003fq-Ji
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 04:47:51 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	C6/04-23865-6F831845; Fri, 05 Dec 2014 04:47:50 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417754869!11238085!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 3667 invoked from network); 5 Dec 2014 04:47:50 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 04:47:50 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 5AB85AB07;
	Fri,  5 Dec 2014 04:47:49 +0000 (UTC)
Message-ID: <548138F5.30405@suse.com>
Date: Fri, 05 Dec 2014 05:47:49 +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-Simon Moeller <dl9pf@gmx.de>, xen-devel@lists.xenproject.org
References: <1727998.ort8X4yb3k@aragorn.auenland.lan>
In-Reply-To: <1727998.ort8X4yb3k@aragorn.auenland.lan>
Subject: Re: [Xen-devel] Question about arch/x86/xen/mmu.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 12/04/2014 10:30 PM, Jan-Simon Moeller wrote:
> Hi !
>
> My name is Jan-Simon Moeller and I'm looking into compiling the kernel with
> LLVM/Clang (see llvm.linuxfoundation.org) .
>
> Right now we face this issue when compiling with clang:
>
>   CC      arch/x86/xen/mmu.o
> arch/x86/xen/mmu.c:1343:18: error: fields must have a constant size:
>       'variable length array in structure' extension will never be
>       supported
>                 DECLARE_BITMAP(mask, num_processors);
>                                ^
> include/linux/types.h:10:16: note: expanded from macro 'DECLARE_BITMAP'
>         unsigned long name[BITS_TO_LONGS(bits)]
>                       ^
> 1 error generated.
>
>
> Question to the experts: why can't we just use NR_CPUS and be done with it ?
> NR_CPUS will be setup by CONFIG_NR_CPUS and thus static.
> ( e.g. arch/x86/configs/x86_64_defconfig:CONFIG_NR_CPUS=64 )

This would expand the structure on kernels configured for many cpus
(e.g. 4096) but running on a smaller machine dramatically.


Juergen


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

From xen-devel-bounces@lists.xen.org Fri Dec 05 04:48:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 04: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 1Xwko5-0003fv-Lv; Fri, 05 Dec 2014 04:47:53 +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 1Xwko3-0003fq-Ji
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 04:47:51 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	C6/04-23865-6F831845; Fri, 05 Dec 2014 04:47:50 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417754869!11238085!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 3667 invoked from network); 5 Dec 2014 04:47:50 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 04:47:50 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 5AB85AB07;
	Fri,  5 Dec 2014 04:47:49 +0000 (UTC)
Message-ID: <548138F5.30405@suse.com>
Date: Fri, 05 Dec 2014 05:47:49 +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-Simon Moeller <dl9pf@gmx.de>, xen-devel@lists.xenproject.org
References: <1727998.ort8X4yb3k@aragorn.auenland.lan>
In-Reply-To: <1727998.ort8X4yb3k@aragorn.auenland.lan>
Subject: Re: [Xen-devel] Question about arch/x86/xen/mmu.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 12/04/2014 10:30 PM, Jan-Simon Moeller wrote:
> Hi !
>
> My name is Jan-Simon Moeller and I'm looking into compiling the kernel with
> LLVM/Clang (see llvm.linuxfoundation.org) .
>
> Right now we face this issue when compiling with clang:
>
>   CC      arch/x86/xen/mmu.o
> arch/x86/xen/mmu.c:1343:18: error: fields must have a constant size:
>       'variable length array in structure' extension will never be
>       supported
>                 DECLARE_BITMAP(mask, num_processors);
>                                ^
> include/linux/types.h:10:16: note: expanded from macro 'DECLARE_BITMAP'
>         unsigned long name[BITS_TO_LONGS(bits)]
>                       ^
> 1 error generated.
>
>
> Question to the experts: why can't we just use NR_CPUS and be done with it ?
> NR_CPUS will be setup by CONFIG_NR_CPUS and thus static.
> ( e.g. arch/x86/configs/x86_64_defconfig:CONFIG_NR_CPUS=64 )

This would expand the structure on kernels configured for many cpus
(e.g. 4096) but running on a smaller machine dramatically.


Juergen


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

From xen-devel-bounces@lists.xen.org Fri Dec 05 05:25:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 05: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 1XwlNk-0004xB-28; Fri, 05 Dec 2014 05:24:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwlNj-0004x6-1J
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 05:24:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	86/87-15461-A9141845; Fri, 05 Dec 2014 05:24:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417757079!13575283!1
X-Originating-IP: [66.165.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 24539 invoked from network); 5 Dec 2014 05:24:40 -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;
	5 Dec 2014 05:24:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,520,1413244800"; d="scan'208";a="200191513"
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, 5 Dec 2014 00:24: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 1XwlNd-0004HI-Vy;
	Fri, 05 Dec 2014 05:24:38 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwlNd-0001f8-OM;
	Fri, 05 Dec 2014 05:24:37 +0000
Date: Fri, 5 Dec 2014 05:24:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32071-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] 32071: 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 32071 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32071/

Failures :-/ but no regressions.

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

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-winxpsp3-vcpus1 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-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              e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f
baseline version:
 seabios              b7f4a76a929ce4acd60e89aa273a8b208daa8233

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Patrick Georgi <pgeorgi@google.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=e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f
+ . 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 e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f
+ branch=seabios
+ revision=e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f
+ . 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 e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   b7f4a76..e5f4338  e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f -> 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 Dec 05 05:25:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 05: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 1XwlNk-0004xB-28; Fri, 05 Dec 2014 05:24:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwlNj-0004x6-1J
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 05:24:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	86/87-15461-A9141845; Fri, 05 Dec 2014 05:24:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417757079!13575283!1
X-Originating-IP: [66.165.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 24539 invoked from network); 5 Dec 2014 05:24:40 -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;
	5 Dec 2014 05:24:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,520,1413244800"; d="scan'208";a="200191513"
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, 5 Dec 2014 00:24: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 1XwlNd-0004HI-Vy;
	Fri, 05 Dec 2014 05:24:38 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwlNd-0001f8-OM;
	Fri, 05 Dec 2014 05:24:37 +0000
Date: Fri, 5 Dec 2014 05:24:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32071-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] 32071: 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 32071 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32071/

Failures :-/ but no regressions.

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

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-winxpsp3-vcpus1 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-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              e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f
baseline version:
 seabios              b7f4a76a929ce4acd60e89aa273a8b208daa8233

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Patrick Georgi <pgeorgi@google.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=e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f
+ . 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 e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f
+ branch=seabios
+ revision=e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f
+ . 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 e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   b7f4a76..e5f4338  e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f -> 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 Dec 05 05:32:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 05:32:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwlUT-00055i-VZ; Fri, 05 Dec 2014 05:31:41 +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 1XwlUS-00055d-DI
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 05:31:40 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2E/FB-09842-B3341845; Fri, 05 Dec 2014 05:31:39 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417757498!6266534!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 586 invoked from network); 5 Dec 2014 05:31:38 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-13.tower-21.messagelabs.com with SMTP;
	5 Dec 2014 05:31:38 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 04 Dec 2014 21:31:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,520,1413270000"; d="scan'208";a="642778351"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by fmsmga002.fm.intel.com with ESMTP; 04 Dec 2014 21:31:35 -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; Fri, 5 Dec 2014 13:30:54 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Fri, 5 Dec 2014 13:30:53 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Dugger, Donald D" <donald.d.dugger@intel.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH V4] Decouple SandyBridge quirk from VTd
	timeout
Thread-Index: AQHQBUn9wHKMcr65s0O1l1YczmPdT5yAjVXg
Date: Fri, 5 Dec 2014 05:30:52 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610E6D8@SHSMSX101.ccr.corp.intel.com>
References: <20141121051219.GB22258@n0ano.com>
In-Reply-To: <20141121051219.GB22258@n0ano.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Kay, Allen M" <allen.m.kay@intel.com>, "Auld, Will" <will.auld@intel.com>,
	"Dong, Eddie" <eddie.dong@intel.com>, "n0ano@n0ano.com" <n0ano@n0ano.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [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

> From: Donald D. Dugger
> Sent: Friday, November 21, 2014 1:12 PM
> 
> 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.

I'm OK with the patch except one comment. User usually thinks bool option
means default, but here an explicit 'default' actually means a different value.
It's a bit confused to me. How about changing 'default' to another more
meaningful word, e.g. 'max'? and you may still keep a 'snb_igd_quirk=
legacy' option, so all the possibilities are included in the assigned case, with
bool option alias to 'legacy'.

Thanks
Kevin

> 
> 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

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 05:32:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 05:32:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwlUT-00055i-VZ; Fri, 05 Dec 2014 05:31:41 +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 1XwlUS-00055d-DI
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 05:31:40 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2E/FB-09842-B3341845; Fri, 05 Dec 2014 05:31:39 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417757498!6266534!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 586 invoked from network); 5 Dec 2014 05:31:38 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-13.tower-21.messagelabs.com with SMTP;
	5 Dec 2014 05:31:38 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 04 Dec 2014 21:31:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,520,1413270000"; d="scan'208";a="642778351"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by fmsmga002.fm.intel.com with ESMTP; 04 Dec 2014 21:31:35 -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; Fri, 5 Dec 2014 13:30:54 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Fri, 5 Dec 2014 13:30:53 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Dugger, Donald D" <donald.d.dugger@intel.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH V4] Decouple SandyBridge quirk from VTd
	timeout
Thread-Index: AQHQBUn9wHKMcr65s0O1l1YczmPdT5yAjVXg
Date: Fri, 5 Dec 2014 05:30:52 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610E6D8@SHSMSX101.ccr.corp.intel.com>
References: <20141121051219.GB22258@n0ano.com>
In-Reply-To: <20141121051219.GB22258@n0ano.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Kay, Allen M" <allen.m.kay@intel.com>, "Auld, Will" <will.auld@intel.com>,
	"Dong, Eddie" <eddie.dong@intel.com>, "n0ano@n0ano.com" <n0ano@n0ano.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [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

> From: Donald D. Dugger
> Sent: Friday, November 21, 2014 1:12 PM
> 
> 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.

I'm OK with the patch except one comment. User usually thinks bool option
means default, but here an explicit 'default' actually means a different value.
It's a bit confused to me. How about changing 'default' to another more
meaningful word, e.g. 'max'? and you may still keep a 'snb_igd_quirk=
legacy' option, so all the possibilities are included in the assigned case, with
bool option alias to 'legacy'.

Thanks
Kevin

> 
> 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

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

From xen-devel-bounces@lists.xen.org Fri Dec 05 06:14:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 06: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 1Xwm96-0006RL-N8; Fri, 05 Dec 2014 06:13:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Xwm96-0006RG-3m
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 06:13:40 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	41/FD-02699-31D41845; Fri, 05 Dec 2014 06:13:39 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417760018!8497640!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28888 invoked from network); 5 Dec 2014 06:13:38 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-5.tower-27.messagelabs.com with SMTP;
	5 Dec 2014 06:13:38 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 04 Dec 2014 22:11:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="494039614"
Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103])
	by orsmga003.jf.intel.com with ESMTP; 04 Dec 2014 22:09:56 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 5 Dec 2014 14:13:19 +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; Fri, 5 Dec 2014 14:13:18 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Thread-Topic: [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
Thread-Index: AQHQD9eaSe46zODvj028i9c0xTR8UJyAgpAQ
Date: Fri, 5 Dec 2014 06:13:18 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610E770@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<54808CC3020000780004CCC8@mail.emea.novell.com>
In-Reply-To: <54808CC3020000780004CCC8@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: "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] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, December 04, 2014 11:33 PM
> > +            if ( pcidevs == NULL )
> > +            {
> > +                rcu_unlock_domain(d);
> > +                return -ENOMEM;
> > +            }
> > +
> > +            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
> > +
> xdsr->num_pcidevs*sizeof(*pcidevs)) )
> > +            {
> > +                xfree(pcidevs);
> > +                rcu_unlock_domain(d);
> > +                return -EFAULT;
> > +            }
> > +        }
> > +
> > +        d->arch.hvm_domain.pcidevs = pcidevs;
> 
> If the operation gets issued more than once for a given domain,
> you're leaking the old pointer here. Overall should think a bit
> more about this multiple use case (or outright disallow it).

from current discussion let's outright disallow it. the information
should be ready early enough before populating p2m.

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 Dec 05 06:14:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 06: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 1Xwm96-0006RL-N8; Fri, 05 Dec 2014 06:13:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Xwm96-0006RG-3m
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 06:13:40 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	41/FD-02699-31D41845; Fri, 05 Dec 2014 06:13:39 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417760018!8497640!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28888 invoked from network); 5 Dec 2014 06:13:38 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-5.tower-27.messagelabs.com with SMTP;
	5 Dec 2014 06:13:38 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 04 Dec 2014 22:11:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="494039614"
Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103])
	by orsmga003.jf.intel.com with ESMTP; 04 Dec 2014 22:09:56 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 5 Dec 2014 14:13:19 +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; Fri, 5 Dec 2014 14:13:18 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Thread-Topic: [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
Thread-Index: AQHQD9eaSe46zODvj028i9c0xTR8UJyAgpAQ
Date: Fri, 5 Dec 2014 06:13:18 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610E770@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<54808CC3020000780004CCC8@mail.emea.novell.com>
In-Reply-To: <54808CC3020000780004CCC8@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: "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] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, December 04, 2014 11:33 PM
> > +            if ( pcidevs == NULL )
> > +            {
> > +                rcu_unlock_domain(d);
> > +                return -ENOMEM;
> > +            }
> > +
> > +            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
> > +
> xdsr->num_pcidevs*sizeof(*pcidevs)) )
> > +            {
> > +                xfree(pcidevs);
> > +                rcu_unlock_domain(d);
> > +                return -EFAULT;
> > +            }
> > +        }
> > +
> > +        d->arch.hvm_domain.pcidevs = pcidevs;
> 
> If the operation gets issued more than once for a given domain,
> you're leaking the old pointer here. Overall should think a bit
> more about this multiple use case (or outright disallow it).

from current discussion let's outright disallow it. the information
should be ready early enough before populating p2m.

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 Dec 05 06:16:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 06:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwmC2-0006XV-Ah; Fri, 05 Dec 2014 06:16: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 1XwmC0-0006XL-FT
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 06:16:40 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	BA/65-01660-7CD41845; Fri, 05 Dec 2014 06:16:39 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417760198!11668805!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 27657 invoked from network); 5 Dec 2014 06:16:39 -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; 5 Dec 2014 06:16:39 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 4BC2AAB09;
	Fri,  5 Dec 2014 06:16: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
Date: Fri,  5 Dec 2014 07:16:35 +0100
Message-Id: <1417760195-16911-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] xen: fix sparse warning 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 patch "Speed up set_phys_to_machine() by using read-only mappings"
introduced a sparse warning:

arch/x86/xen/p2m.c:628:13: sparse: incorrect type in argument 1
                           (different address spaces)

Avoid the warning.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/p2m.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8b5db51..2defca9 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -615,6 +615,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	pte_t *ptep;
 	unsigned int level;
+	unsigned long __user *addr;
 
 	/* don't track P2M changes in autotranslate guests */
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -625,7 +626,8 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
-	if (likely(!__put_user(mfn, xen_p2m_addr + pfn)))
+	addr = (unsigned long __user *)xen_p2m_addr + pfn;
+	if (likely(!__put_user(mfn, addr)))
 		return true;
 
 	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
-- 
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 Dec 05 06:16:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 06:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwmC2-0006XV-Ah; Fri, 05 Dec 2014 06:16: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 1XwmC0-0006XL-FT
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 06:16:40 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	BA/65-01660-7CD41845; Fri, 05 Dec 2014 06:16:39 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417760198!11668805!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 27657 invoked from network); 5 Dec 2014 06:16:39 -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; 5 Dec 2014 06:16:39 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 4BC2AAB09;
	Fri,  5 Dec 2014 06:16: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
Date: Fri,  5 Dec 2014 07:16:35 +0100
Message-Id: <1417760195-16911-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] xen: fix sparse warning 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 patch "Speed up set_phys_to_machine() by using read-only mappings"
introduced a sparse warning:

arch/x86/xen/p2m.c:628:13: sparse: incorrect type in argument 1
                           (different address spaces)

Avoid the warning.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/p2m.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8b5db51..2defca9 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -615,6 +615,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	pte_t *ptep;
 	unsigned int level;
+	unsigned long __user *addr;
 
 	/* don't track P2M changes in autotranslate guests */
 	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
@@ -625,7 +626,8 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
-	if (likely(!__put_user(mfn, xen_p2m_addr + pfn)))
+	addr = (unsigned long __user *)xen_p2m_addr + pfn;
+	if (likely(!__put_user(mfn, addr)))
 		return true;
 
 	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
-- 
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 Dec 05 06:17:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 06: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 1XwmCM-0006Zj-NO; Fri, 05 Dec 2014 06:17:02 +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 1XwmCK-0006ZS-Uy
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 06:17:01 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	B6/24-09284-CDD41845; Fri, 05 Dec 2014 06:17:00 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417760219!11201680!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 30484 invoked from network); 5 Dec 2014 06:16:59 -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; 5 Dec 2014 06:16:59 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 4E05CAB09;
	Fri,  5 Dec 2014 06:16: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
Date: Fri,  5 Dec 2014 07:16:57 +0100
Message-Id: <1417760217-16977-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] xen: fix sparse warning in page.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

The inline function mfn_to_pfn_no_overrides() uses __get_user() to
access the machine_to_phys_mapping array to avoid crashes when
using out of bounds indices e.g. for I/O addresses.

Avoid sparse warnings by attributing the accessed address with __user.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index f5d5de4..6deff84 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -113,6 +113,7 @@ static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
 {
 	unsigned long pfn;
 	int ret;
+	unsigned long __user *addr;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return mfn;
@@ -125,7 +126,8 @@ static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
 	 * In such cases it doesn't matter what we return (we return garbage),
 	 * but we must handle the fault without crashing!
 	 */
-	ret = __get_user(pfn, &machine_to_phys_mapping[mfn]);
+	addr = (unsigned long __user *)(&machine_to_phys_mapping[mfn]);
+	ret = __get_user(pfn, addr);
 	if (ret < 0)
 		return ~0;
 
-- 
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 Dec 05 06:17:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 06: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 1XwmCM-0006Zj-NO; Fri, 05 Dec 2014 06:17:02 +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 1XwmCK-0006ZS-Uy
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 06:17:01 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	B6/24-09284-CDD41845; Fri, 05 Dec 2014 06:17:00 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417760219!11201680!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 30484 invoked from network); 5 Dec 2014 06:16:59 -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; 5 Dec 2014 06:16:59 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 4E05CAB09;
	Fri,  5 Dec 2014 06:16: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
Date: Fri,  5 Dec 2014 07:16:57 +0100
Message-Id: <1417760217-16977-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] xen: fix sparse warning in page.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

The inline function mfn_to_pfn_no_overrides() uses __get_user() to
access the machine_to_phys_mapping array to avoid crashes when
using out of bounds indices e.g. for I/O addresses.

Avoid sparse warnings by attributing the accessed address with __user.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index f5d5de4..6deff84 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -113,6 +113,7 @@ static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
 {
 	unsigned long pfn;
 	int ret;
+	unsigned long __user *addr;
 
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return mfn;
@@ -125,7 +126,8 @@ static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
 	 * In such cases it doesn't matter what we return (we return garbage),
 	 * but we must handle the fault without crashing!
 	 */
-	ret = __get_user(pfn, &machine_to_phys_mapping[mfn]);
+	addr = (unsigned long __user *)(&machine_to_phys_mapping[mfn]);
+	ret = __get_user(pfn, addr);
 	if (ret < 0)
 		return ~0;
 
-- 
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 Dec 05 06:24:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 06: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 1XwmJb-00075d-Ro; Fri, 05 Dec 2014 06:24:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XwmJa-00075Y-PA
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 06:24:30 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A8/BF-08051-E9F41845; Fri, 05 Dec 2014 06:24:30 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417760668!13152043!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.4 required=7.0 tests=URG_BIZ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22860 invoked from network); 5 Dec 2014 06:24:29 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-27.messagelabs.com with SMTP;
	5 Dec 2014 06:24:29 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 04 Dec 2014 22:22:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,521,1413270000"; d="scan'208";a="619014521"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by orsmga001.jf.intel.com with ESMTP; 04 Dec 2014 22:24:25 -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, 5 Dec 2014 14:23:31 +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, 5 Dec 2014 14:23:30 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Thread-Topic: [v8][PATCH 09/17] hvmloader/ram: check if guest memory is out
	of reserved device memory maps
Thread-Index: AQHQD94p/4QEBbod+kaNVPhbdBPGPJyAhCAA
Date: Fri, 5 Dec 2014 06:23:29 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610E7AC@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
	<548097C5020000780004CD72@mail.emea.novell.com>
In-Reply-To: <548097C5020000780004CD72@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: "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] [v8][PATCH 09/17] 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: Friday, December 05, 2014 12:20 AM
> 
> >>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> > We need to check to reserve all reserved device memory maps in e820
> > to avoid any potential guest memory conflict.
> >
> > Currently, if we can't insert RDM entries directly, we may need to handle
> > several ranges as follows:
> > a. Fixed Ranges --> BUG()
> >  lowmem_reserved_base-0xA0000: reserved by BIOS implementation,
> >  BIOS region,
> >  RESERVED_MEMBASE ~ 0x100000000,
> > b. RAM or RAM:Hole -> Try to reserve
> 
> I continue to be unconvinced of the overall approach: The domain
> builder continues to populate these regions when it shouldn't. Yet
> once it doesn't, it would be most natural to simply communicate the

doesn't -> does?

> RAM regions to hvmloader, and hvmloader would use just that to
> build the E820 table (and subsequently assign BARs).
> 

My impression is that you didn't like extending hvm_info to carry
sparse RAM regions. that's why the current tradeoff is taken, i.e.
leaving domain builder unchanged for RAM, then preventing EPT 
setup for reserved regions in hypervisor (means wasting memory), 
and then having hvmloader to actually figure out the final e820. 
and that's also why per-BDF design is introduced to minimize wasted 
memory. We discussed to change domain builder to avoid populating 
reserved regions as the next step after 4.5, but w/o extending 
hvm_info we always need the logic in hvmloader to construct e820 
from scratch.

I did not catch all the discussion history between you and Tiejun, so 
may miss sth. here. (btw Tiejun is on an urgent leave, so his response
will be slow in a few days)

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 Dec 05 06:24:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 06: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 1XwmJb-00075d-Ro; Fri, 05 Dec 2014 06:24:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XwmJa-00075Y-PA
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 06:24:30 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A8/BF-08051-E9F41845; Fri, 05 Dec 2014 06:24:30 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417760668!13152043!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.4 required=7.0 tests=URG_BIZ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22860 invoked from network); 5 Dec 2014 06:24:29 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-27.messagelabs.com with SMTP;
	5 Dec 2014 06:24:29 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 04 Dec 2014 22:22:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,521,1413270000"; d="scan'208";a="619014521"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by orsmga001.jf.intel.com with ESMTP; 04 Dec 2014 22:24:25 -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, 5 Dec 2014 14:23:31 +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, 5 Dec 2014 14:23:30 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Thread-Topic: [v8][PATCH 09/17] hvmloader/ram: check if guest memory is out
	of reserved device memory maps
Thread-Index: AQHQD94p/4QEBbod+kaNVPhbdBPGPJyAhCAA
Date: Fri, 5 Dec 2014 06:23:29 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610E7AC@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
	<548097C5020000780004CD72@mail.emea.novell.com>
In-Reply-To: <548097C5020000780004CD72@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: "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] [v8][PATCH 09/17] 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: Friday, December 05, 2014 12:20 AM
> 
> >>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> > We need to check to reserve all reserved device memory maps in e820
> > to avoid any potential guest memory conflict.
> >
> > Currently, if we can't insert RDM entries directly, we may need to handle
> > several ranges as follows:
> > a. Fixed Ranges --> BUG()
> >  lowmem_reserved_base-0xA0000: reserved by BIOS implementation,
> >  BIOS region,
> >  RESERVED_MEMBASE ~ 0x100000000,
> > b. RAM or RAM:Hole -> Try to reserve
> 
> I continue to be unconvinced of the overall approach: The domain
> builder continues to populate these regions when it shouldn't. Yet
> once it doesn't, it would be most natural to simply communicate the

doesn't -> does?

> RAM regions to hvmloader, and hvmloader would use just that to
> build the E820 table (and subsequently assign BARs).
> 

My impression is that you didn't like extending hvm_info to carry
sparse RAM regions. that's why the current tradeoff is taken, i.e.
leaving domain builder unchanged for RAM, then preventing EPT 
setup for reserved regions in hypervisor (means wasting memory), 
and then having hvmloader to actually figure out the final e820. 
and that's also why per-BDF design is introduced to minimize wasted 
memory. We discussed to change domain builder to avoid populating 
reserved regions as the next step after 4.5, but w/o extending 
hvm_info we always need the logic in hvmloader to construct e820 
from scratch.

I did not catch all the discussion history between you and Tiejun, so 
may miss sth. here. (btw Tiejun is on an urgent leave, so his response
will be slow in a few days)

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 Dec 05 06:25:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 06: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 1XwmKq-00079a-AA; Fri, 05 Dec 2014 06:25:48 +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 1XwmKo-00079P-W8
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 06:25:47 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	35/A7-28865-AEF41845; Fri, 05 Dec 2014 06:25:46 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417760745!11677523!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30215 invoked from network); 5 Dec 2014 06:25:45 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-206.messagelabs.com with SMTP;
	5 Dec 2014 06:25:45 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 04 Dec 2014 22:25:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,521,1413270000"; d="scan'208";a="642791978"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by fmsmga002.fm.intel.com with ESMTP; 04 Dec 2014 22:25:41 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 5 Dec 2014 14:24:54 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Fri, 5 Dec 2014 14:24:53 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Thread-Topic: [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip any overlap
	with reserved device memory
Thread-Index: AQHQD99j7gqygqmJTE+Kag6M8MgfNpyAiGDA
Date: Fri, 5 Dec 2014 06:24:52 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610E7BB@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
	<548099D4020000780004CD9C@mail.emea.novell.com>
In-Reply-To: <548099D4020000780004CD9C@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: "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] [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip
 any overlap with reserved device 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

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, December 05, 2014 12:29 AM
> 
> >>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> > In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
> > to allocate some memory to use in runtime cycle, so we alsoe need to
> > make sure all reserved device memory don't overlap such a region.
> 
> While ideally this would get switched to the model outlined for
> the previous two patches too, it's at least reasonable to keep
> this simple allocator simple for the time being.
> 
> > --- a/tools/firmware/hvmloader/util.c
> > +++ b/tools/firmware/hvmloader/util.c
> > @@ -416,9 +416,29 @@ static uint32_t alloc_down =
> RESERVED_MEMORY_DYNAMIC_END;
> >
> >  xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
> >  {
> > +    unsigned int i, num = hvm_get_reserved_device_memory_map();
> > +    uint64_t rdm_start, rdm_end;
> > +    uint32_t alloc_start, alloc_end;
> > +
> >      alloc_down -= nr_mfns << PAGE_SHIFT;
> > +    alloc_start = alloc_down;
> > +    alloc_end = alloc_start + (nr_mfns << PAGE_SHIFT);
> > +    for ( i = 0; i < num; i++ )
> > +    {
> > +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
> > +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages <<
> PAGE_SHIFT);
> > +        if ( check_rdm_hole_conflict((uint64_t)alloc_start,
> > +                                     (uint64_t)alloc_end,
> 
> Pointless casts.
> 
> > +                                     rdm_start, rdm_end -
> rdm_start) )
> > +        {
> > +            alloc_end = rdm_start;
> > +            alloc_start = alloc_end - (nr_mfns << PAGE_SHIFT);
> > +            BUG_ON(alloc_up >= alloc_start);
> 
> This is redundant with the BUG_ON() below afaict. Or at least it
> would be, if you would properly update allow_down (if you don't
> you may end up returning the same PFN for two allocations).
> 

I'd like this being done once at init time. Once alloc_up/down is
verified/adjusted, no need to add run-time overhead here.

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 Dec 05 06:25:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 06: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 1XwmKq-00079a-AA; Fri, 05 Dec 2014 06:25:48 +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 1XwmKo-00079P-W8
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 06:25:47 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	35/A7-28865-AEF41845; Fri, 05 Dec 2014 06:25:46 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417760745!11677523!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30215 invoked from network); 5 Dec 2014 06:25:45 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-206.messagelabs.com with SMTP;
	5 Dec 2014 06:25:45 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 04 Dec 2014 22:25:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,521,1413270000"; d="scan'208";a="642791978"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by fmsmga002.fm.intel.com with ESMTP; 04 Dec 2014 22:25:41 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 5 Dec 2014 14:24:54 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id
	14.03.0195.001; Fri, 5 Dec 2014 14:24:53 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Thread-Topic: [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip any overlap
	with reserved device memory
Thread-Index: AQHQD99j7gqygqmJTE+Kag6M8MgfNpyAiGDA
Date: Fri, 5 Dec 2014 06:24:52 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610E7BB@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
	<548099D4020000780004CD9C@mail.emea.novell.com>
In-Reply-To: <548099D4020000780004CD9C@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: "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] [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip
 any overlap with reserved device 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

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, December 05, 2014 12:29 AM
> 
> >>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> > In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
> > to allocate some memory to use in runtime cycle, so we alsoe need to
> > make sure all reserved device memory don't overlap such a region.
> 
> While ideally this would get switched to the model outlined for
> the previous two patches too, it's at least reasonable to keep
> this simple allocator simple for the time being.
> 
> > --- a/tools/firmware/hvmloader/util.c
> > +++ b/tools/firmware/hvmloader/util.c
> > @@ -416,9 +416,29 @@ static uint32_t alloc_down =
> RESERVED_MEMORY_DYNAMIC_END;
> >
> >  xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
> >  {
> > +    unsigned int i, num = hvm_get_reserved_device_memory_map();
> > +    uint64_t rdm_start, rdm_end;
> > +    uint32_t alloc_start, alloc_end;
> > +
> >      alloc_down -= nr_mfns << PAGE_SHIFT;
> > +    alloc_start = alloc_down;
> > +    alloc_end = alloc_start + (nr_mfns << PAGE_SHIFT);
> > +    for ( i = 0; i < num; i++ )
> > +    {
> > +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
> > +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages <<
> PAGE_SHIFT);
> > +        if ( check_rdm_hole_conflict((uint64_t)alloc_start,
> > +                                     (uint64_t)alloc_end,
> 
> Pointless casts.
> 
> > +                                     rdm_start, rdm_end -
> rdm_start) )
> > +        {
> > +            alloc_end = rdm_start;
> > +            alloc_start = alloc_end - (nr_mfns << PAGE_SHIFT);
> > +            BUG_ON(alloc_up >= alloc_start);
> 
> This is redundant with the BUG_ON() below afaict. Or at least it
> would be, if you would properly update allow_down (if you don't
> you may end up returning the same PFN for two allocations).
> 

I'd like this being done once at init time. Once alloc_up/down is
verified/adjusted, no need to add run-time overhead here.

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 Dec 05 06:28:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 06:28:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwmNZ-0007KK-Sf; Fri, 05 Dec 2014 06:28:37 +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 1XwmNX-0007KB-RS
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 06:28:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	89/57-09842-39051845; Fri, 05 Dec 2014 06:28:35 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417760913!13517484!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 3008 invoked from network); 5 Dec 2014 06:28:34 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-6.tower-21.messagelabs.com with SMTP;
	5 Dec 2014 06:28:34 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 04 Dec 2014 22:26:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,521,1413270000"; d="scan'208";a="648709841"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by orsmga002.jf.intel.com with ESMTP; 04 Dec 2014 22:27:58 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 5 Dec 2014 14:27:57 +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; Fri, 5 Dec 2014 14:27:57 +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; Fri, 5 Dec 2014 14:27:55 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Don Dugger <n0ano@n0ano.com>
Thread-Topic: [Xen-devel] [PATCH V4] Decouple SandyBridge quirk from VTd
	timeout
Thread-Index: AQHQBUn9wHKMcr65s0O1l1YczmPdT5yAjVXg//+HCQCAAIoEYA==
Date: Fri, 5 Dec 2014 06:27:55 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610E7E0@SHSMSX101.ccr.corp.intel.com>
References: <20141121051219.GB22258@n0ano.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610E6D8@SHSMSX101.ccr.corp.intel.com>
	<20141205061304.GI22950@n0ano.com>
In-Reply-To: <20141205061304.GI22950@n0ano.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Dong, Eddie" <eddie.dong@intel.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>, "Dugger,
	Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Auld,
	Will" <will.auld@intel.com>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [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

> From: Don Dugger [mailto:n0ano@n0ano.com]
> Sent: Friday, December 05, 2014 2:13 PM
> 
> On Fri, Dec 05, 2014 at 05:30:52AM +0000, Tian, Kevin wrote:
> > > From: Donald D. Dugger
> > > Sent: Friday, November 21, 2014 1:12 PM
> > >
> > > 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.
> >
> > I'm OK with the patch except one comment. User usually thinks bool option
> > means default, but here an explicit 'default' actually means a different
> value.
> > It's a bit confused to me. How about changing 'default' to another more
> > meaningful word, e.g. 'max'? and you may still keep a 'snb_igd_quirk=
> > legacy' option, so all the possibilities are included in the assigned case, with
> > bool option alias to 'legacy'.
> 
> I don't see a need for a `legacy' option, merely enabling the option (which is
> what current users are doing) will select the current 1 sec. timeout.  If you
> don't like `default' (and I don't like `max' since that would select a value
> less that the current default) how about the string `cap' (the cap on the
> theoretical timeout) to select the 670 msec value?
> 

that looks fine to me. You can have my ACK for your next version. :-)

Acked-by: Kevin Tian <kevin.tian@intel.com>


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

From xen-devel-bounces@lists.xen.org Fri Dec 05 06:28:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 06:28:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwmNZ-0007KK-Sf; Fri, 05 Dec 2014 06:28:37 +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 1XwmNX-0007KB-RS
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 06:28:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	89/57-09842-39051845; Fri, 05 Dec 2014 06:28:35 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417760913!13517484!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 3008 invoked from network); 5 Dec 2014 06:28:34 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-6.tower-21.messagelabs.com with SMTP;
	5 Dec 2014 06:28:34 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 04 Dec 2014 22:26:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,521,1413270000"; d="scan'208";a="648709841"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by orsmga002.jf.intel.com with ESMTP; 04 Dec 2014 22:27:58 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 5 Dec 2014 14:27:57 +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; Fri, 5 Dec 2014 14:27:57 +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; Fri, 5 Dec 2014 14:27:55 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Don Dugger <n0ano@n0ano.com>
Thread-Topic: [Xen-devel] [PATCH V4] Decouple SandyBridge quirk from VTd
	timeout
Thread-Index: AQHQBUn9wHKMcr65s0O1l1YczmPdT5yAjVXg//+HCQCAAIoEYA==
Date: Fri, 5 Dec 2014 06:27:55 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12610E7E0@SHSMSX101.ccr.corp.intel.com>
References: <20141121051219.GB22258@n0ano.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610E6D8@SHSMSX101.ccr.corp.intel.com>
	<20141205061304.GI22950@n0ano.com>
In-Reply-To: <20141205061304.GI22950@n0ano.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Dong, Eddie" <eddie.dong@intel.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>, "Dugger,
	Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Auld,
	Will" <will.auld@intel.com>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [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

> From: Don Dugger [mailto:n0ano@n0ano.com]
> Sent: Friday, December 05, 2014 2:13 PM
> 
> On Fri, Dec 05, 2014 at 05:30:52AM +0000, Tian, Kevin wrote:
> > > From: Donald D. Dugger
> > > Sent: Friday, November 21, 2014 1:12 PM
> > >
> > > 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.
> >
> > I'm OK with the patch except one comment. User usually thinks bool option
> > means default, but here an explicit 'default' actually means a different
> value.
> > It's a bit confused to me. How about changing 'default' to another more
> > meaningful word, e.g. 'max'? and you may still keep a 'snb_igd_quirk=
> > legacy' option, so all the possibilities are included in the assigned case, with
> > bool option alias to 'legacy'.
> 
> I don't see a need for a `legacy' option, merely enabling the option (which is
> what current users are doing) will select the current 1 sec. timeout.  If you
> don't like `default' (and I don't like `max' since that would select a value
> less that the current default) how about the string `cap' (the cap on the
> theoretical timeout) to select the 670 msec value?
> 

that looks fine to me. You can have my ACK for your next version. :-)

Acked-by: Kevin Tian <kevin.tian@intel.com>


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

From xen-devel-bounces@lists.xen.org Fri Dec 05 07:38:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 07: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 1XwnSC-00011I-1b; Fri, 05 Dec 2014 07:37: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 1XwnS9-00011D-T5
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 07:37:26 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	42/6E-25714-4B061845; Fri, 05 Dec 2014 07:37:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417765044!8807191!1
X-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 24511 invoked from network); 5 Dec 2014 07:37:24 -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; 5 Dec 2014 07:37:24 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 07:37:23 +0000
Message-Id: <54816EC3020000780004CFF3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 07:37:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roy Franz" <roy.franz@linaro.org>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<CAFECyb8WJwW=winKPNK6eWeEMRa+RNHa_vLwcmUJo3j1WTo3FQ@mail.gmail.com>
In-Reply-To: <CAFECyb8WJwW=winKPNK6eWeEMRa+RNHa_vLwcmUJo3j1WTo3FQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.12.14 at 22:22, <roy.franz@linaro.org> wrote:
> On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
>>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
>>>    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
>>>    code than definitions, declarations and short static
>>>    functions. So, I think that it is more regular *.c file
>>>    than header file.
>>
>> That's a matter of taste - I'd probably have made it .c too, but
>> didn't mind it being .h as done by Roy (presumably on the basis
>> that #include directives are preferred to have .h files as their
>> operands). The only thing I regret is that I didn't ask for the
>> pointless efi- prefix to be dropped.
> 
> I don't mind a change here, and I agree that it is more like a .c file
> than a .h.  If a name change is done, is it worth dropping the "efi-" at
> the same time?

If we indeed want to change the name (post 4.5), making both
adjustments at once would be kind of a requirement of mine.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 07:38:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 07: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 1XwnSC-00011I-1b; Fri, 05 Dec 2014 07:37: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 1XwnS9-00011D-T5
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 07:37:26 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	42/6E-25714-4B061845; Fri, 05 Dec 2014 07:37:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417765044!8807191!1
X-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 24511 invoked from network); 5 Dec 2014 07:37:24 -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; 5 Dec 2014 07:37:24 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 07:37:23 +0000
Message-Id: <54816EC3020000780004CFF3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 07:37:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roy Franz" <roy.franz@linaro.org>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<CAFECyb8WJwW=winKPNK6eWeEMRa+RNHa_vLwcmUJo3j1WTo3FQ@mail.gmail.com>
In-Reply-To: <CAFECyb8WJwW=winKPNK6eWeEMRa+RNHa_vLwcmUJo3j1WTo3FQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 04.12.14 at 22:22, <roy.franz@linaro.org> wrote:
> On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
>>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
>>>    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
>>>    code than definitions, declarations and short static
>>>    functions. So, I think that it is more regular *.c file
>>>    than header file.
>>
>> That's a matter of taste - I'd probably have made it .c too, but
>> didn't mind it being .h as done by Roy (presumably on the basis
>> that #include directives are preferred to have .h files as their
>> operands). The only thing I regret is that I didn't ask for the
>> pointless efi- prefix to be dropped.
> 
> I don't mind a change here, and I agree that it is more like a .c file
> than a .h.  If a name change is done, is it worth dropping the "efi-" at
> the same time?

If we indeed want to change the name (post 4.5), making both
adjustments at once would be kind of a requirement of mine.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 07:44:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 07: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 1XwnYM-0001No-S7; Fri, 05 Dec 2014 07:43: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 1XwnYL-0001Nj-KB
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 07:43:49 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	31/2A-03148-43261845; Fri, 05 Dec 2014 07:43:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417765428!13143622!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23044 invoked from network); 5 Dec 2014 07:43:48 -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; 5 Dec 2014 07:43:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 07:43:46 +0000
Message-Id: <54817042020000780004D012@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 07:43:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>, "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
	<548097C5020000780004CD72@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610E7AC@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610E7AC@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] [v8][PATCH 09/17] 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 05.12.14 at 07:23, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Friday, December 05, 2014 12:20 AM
>> 
>> >>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> > We need to check to reserve all reserved device memory maps in e820
>> > to avoid any potential guest memory conflict.
>> >
>> > Currently, if we can't insert RDM entries directly, we may need to handle
>> > several ranges as follows:
>> > a. Fixed Ranges --> BUG()
>> >  lowmem_reserved_base-0xA0000: reserved by BIOS implementation,
>> >  BIOS region,
>> >  RESERVED_MEMBASE ~ 0x100000000,
>> > b. RAM or RAM:Hole -> Try to reserve
>> 
>> I continue to be unconvinced of the overall approach: The domain
>> builder continues to populate these regions when it shouldn't. Yet
>> once it doesn't, it would be most natural to simply communicate the
> 
> doesn't -> does?

No. The domain builder currently populates these regions (at least
I didn't spot a change to make it not do so).

>> RAM regions to hvmloader, and hvmloader would use just that to
>> build the E820 table (and subsequently assign BARs).
>> 
> 
> My impression is that you didn't like extending hvm_info to carry
> sparse RAM regions. that's why the current tradeoff is taken, i.e.
> leaving domain builder unchanged for RAM, then preventing EPT 
> setup for reserved regions in hypervisor (means wasting memory), 
> and then having hvmloader to actually figure out the final e820. 
> and that's also why per-BDF design is introduced to minimize wasted 
> memory. We discussed to change domain builder to avoid populating 
> reserved regions as the next step after 4.5, but w/o extending 
> hvm_info we always need the logic in hvmloader to construct e820 
> from scratch.

Communicating this via hvm_info is not the only way. For example,
the XENMEM_{set_,}memory_map pair of hypercalls could be used
(and is readily available to be extended that way, since for HVM
domains XENMEM_set_memory_map returns -EPERM at present). The
only potentially problematic aspect I can see with using it might be
its limiting of the entry count to E820MAX.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 07:44:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 07: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 1XwnYM-0001No-S7; Fri, 05 Dec 2014 07:43: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 1XwnYL-0001Nj-KB
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 07:43:49 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	31/2A-03148-43261845; Fri, 05 Dec 2014 07:43:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1417765428!13143622!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23044 invoked from network); 5 Dec 2014 07:43:48 -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; 5 Dec 2014 07:43:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 07:43:46 +0000
Message-Id: <54817042020000780004D012@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 07:43:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>, "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-10-git-send-email-tiejun.chen@intel.com>
	<548097C5020000780004CD72@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610E7AC@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610E7AC@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] [v8][PATCH 09/17] 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 05.12.14 at 07:23, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Friday, December 05, 2014 12:20 AM
>> 
>> >>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> > We need to check to reserve all reserved device memory maps in e820
>> > to avoid any potential guest memory conflict.
>> >
>> > Currently, if we can't insert RDM entries directly, we may need to handle
>> > several ranges as follows:
>> > a. Fixed Ranges --> BUG()
>> >  lowmem_reserved_base-0xA0000: reserved by BIOS implementation,
>> >  BIOS region,
>> >  RESERVED_MEMBASE ~ 0x100000000,
>> > b. RAM or RAM:Hole -> Try to reserve
>> 
>> I continue to be unconvinced of the overall approach: The domain
>> builder continues to populate these regions when it shouldn't. Yet
>> once it doesn't, it would be most natural to simply communicate the
> 
> doesn't -> does?

No. The domain builder currently populates these regions (at least
I didn't spot a change to make it not do so).

>> RAM regions to hvmloader, and hvmloader would use just that to
>> build the E820 table (and subsequently assign BARs).
>> 
> 
> My impression is that you didn't like extending hvm_info to carry
> sparse RAM regions. that's why the current tradeoff is taken, i.e.
> leaving domain builder unchanged for RAM, then preventing EPT 
> setup for reserved regions in hypervisor (means wasting memory), 
> and then having hvmloader to actually figure out the final e820. 
> and that's also why per-BDF design is introduced to minimize wasted 
> memory. We discussed to change domain builder to avoid populating 
> reserved regions as the next step after 4.5, but w/o extending 
> hvm_info we always need the logic in hvmloader to construct e820 
> from scratch.

Communicating this via hvm_info is not the only way. For example,
the XENMEM_{set_,}memory_map pair of hypercalls could be used
(and is readily available to be extended that way, since for HVM
domains XENMEM_set_memory_map returns -EPERM at present). The
only potentially problematic aspect I can see with using it might be
its limiting of the entry count to E820MAX.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 07:46:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 07: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 1XwnbB-0001UP-EK; Fri, 05 Dec 2014 07:46:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwnbA-0001UH-AU
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 07:46:44 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	31/C1-19763-3E261845; Fri, 05 Dec 2014 07:46:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417765602!11688458!1
X-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 15824 invoked from network); 5 Dec 2014 07:46:43 -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; 5 Dec 2014 07:46:43 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 07:46:42 +0000
Message-Id: <548170F3020000780004D015@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 07:46:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>, "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
	<548099D4020000780004CD9C@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610E7BB@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610E7BB@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] [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip
 any overlap with reserved device 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 05.12.14 at 07:24, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Friday, December 05, 2014 12:29 AM
>> 
>> >>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> > In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
>> > to allocate some memory to use in runtime cycle, so we alsoe need to
>> > make sure all reserved device memory don't overlap such a region.
>> 
>> While ideally this would get switched to the model outlined for
>> the previous two patches too, it's at least reasonable to keep
>> this simple allocator simple for the time being.
>> 
>> > --- a/tools/firmware/hvmloader/util.c
>> > +++ b/tools/firmware/hvmloader/util.c
>> > @@ -416,9 +416,29 @@ static uint32_t alloc_down =
>> RESERVED_MEMORY_DYNAMIC_END;
>> >
>> >  xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
>> >  {
>> > +    unsigned int i, num = hvm_get_reserved_device_memory_map();
>> > +    uint64_t rdm_start, rdm_end;
>> > +    uint32_t alloc_start, alloc_end;
>> > +
>> >      alloc_down -= nr_mfns << PAGE_SHIFT;
>> > +    alloc_start = alloc_down;
>> > +    alloc_end = alloc_start + (nr_mfns << PAGE_SHIFT);
>> > +    for ( i = 0; i < num; i++ )
>> > +    {
>> > +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
>> > +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages <<
>> PAGE_SHIFT);
>> > +        if ( check_rdm_hole_conflict((uint64_t)alloc_start,
>> > +                                     (uint64_t)alloc_end,
>> 
>> Pointless casts.
>> 
>> > +                                     rdm_start, rdm_end -
>> rdm_start) )
>> > +        {
>> > +            alloc_end = rdm_start;
>> > +            alloc_start = alloc_end - (nr_mfns << PAGE_SHIFT);
>> > +            BUG_ON(alloc_up >= alloc_start);
>> 
>> This is redundant with the BUG_ON() below afaict. Or at least it
>> would be, if you would properly update allow_down (if you don't
>> you may end up returning the same PFN for two allocations).
>> 
> 
> I'd like this being done once at init time. Once alloc_up/down is
> verified/adjusted, no need to add run-time overhead here.

I don't think that would work, as you can't predict where the holes
are, and limiting allocations to e.g. just the largest region between
any two holes may end up being too restrictive (without having
checked how much memory may get allocated this way in the
worst case). Of course there's also the problem to address that
the whole region used so far overlaps with an enforced hole.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 07:46:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 07: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 1XwnbB-0001UP-EK; Fri, 05 Dec 2014 07:46:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwnbA-0001UH-AU
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 07:46:44 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	31/C1-19763-3E261845; Fri, 05 Dec 2014 07:46:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417765602!11688458!1
X-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 15824 invoked from network); 5 Dec 2014 07:46:43 -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; 5 Dec 2014 07:46:43 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 07:46:42 +0000
Message-Id: <548170F3020000780004D015@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 07:46:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>, "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-11-git-send-email-tiejun.chen@intel.com>
	<548099D4020000780004CD9C@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610E7BB@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610E7BB@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] [v8][PATCH 10/17] hvmloader/mem_hole_alloc: skip
 any overlap with reserved device 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 05.12.14 at 07:24, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Friday, December 05, 2014 12:29 AM
>> 
>> >>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> > In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
>> > to allocate some memory to use in runtime cycle, so we alsoe need to
>> > make sure all reserved device memory don't overlap such a region.
>> 
>> While ideally this would get switched to the model outlined for
>> the previous two patches too, it's at least reasonable to keep
>> this simple allocator simple for the time being.
>> 
>> > --- a/tools/firmware/hvmloader/util.c
>> > +++ b/tools/firmware/hvmloader/util.c
>> > @@ -416,9 +416,29 @@ static uint32_t alloc_down =
>> RESERVED_MEMORY_DYNAMIC_END;
>> >
>> >  xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
>> >  {
>> > +    unsigned int i, num = hvm_get_reserved_device_memory_map();
>> > +    uint64_t rdm_start, rdm_end;
>> > +    uint32_t alloc_start, alloc_end;
>> > +
>> >      alloc_down -= nr_mfns << PAGE_SHIFT;
>> > +    alloc_start = alloc_down;
>> > +    alloc_end = alloc_start + (nr_mfns << PAGE_SHIFT);
>> > +    for ( i = 0; i < num; i++ )
>> > +    {
>> > +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
>> > +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages <<
>> PAGE_SHIFT);
>> > +        if ( check_rdm_hole_conflict((uint64_t)alloc_start,
>> > +                                     (uint64_t)alloc_end,
>> 
>> Pointless casts.
>> 
>> > +                                     rdm_start, rdm_end -
>> rdm_start) )
>> > +        {
>> > +            alloc_end = rdm_start;
>> > +            alloc_start = alloc_end - (nr_mfns << PAGE_SHIFT);
>> > +            BUG_ON(alloc_up >= alloc_start);
>> 
>> This is redundant with the BUG_ON() below afaict. Or at least it
>> would be, if you would properly update allow_down (if you don't
>> you may end up returning the same PFN for two allocations).
>> 
> 
> I'd like this being done once at init time. Once alloc_up/down is
> verified/adjusted, no need to add run-time overhead here.

I don't think that would work, as you can't predict where the holes
are, and limiting allocations to e.g. just the largest region between
any two holes may end up being too restrictive (without having
checked how much memory may get allocated this way in the
worst case). Of course there's also the problem to address that
the whole region used so far overlaps with an enforced hole.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 07:47:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 07: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 1Xwnbz-0001Z7-SD; Fri, 05 Dec 2014 07:47:35 +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 1Xwnby-0001Yz-Oa
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 07:47:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	07/BC-09842-61361845; Fri, 05 Dec 2014 07:47:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417765653!13567397!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17368 invoked from network); 5 Dec 2014 07:47:33 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 07:47:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417765653; l=706;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=VQUfYT1IIL8c2/9x6wolWVcX88k=;
	b=h1T1fnTL02Kgc9bW0fNUl5P3bYkRSSrejalzF7Z0+Zsm2XKJ/NvFI/K9MlkJVNfxdEZ
	xe83pL2TwH6g6BISHcoDW+yjySAsoyUu1mCrQ8Kqme9wOZqWODNfaB/v0loy3vklsEmwe
	i9XDUehqq/PmwZnS4tKXAecAIdKZI0r7cvU=
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.2 AUTH) with ESMTPSA id 00145eqB57lXOUg
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 08:47:33 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 919A65015D; Fri,  5 Dec 2014 08:47:33 +0100 (CET)
Date: Fri, 5 Dec 2014 08:47:33 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20141205074733.GA29524@aepfle.de>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
	<20141204074756.GA4505@aepfle.de>
	<20141205021508.GB19424@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205021508.GB19424@andromeda.dapyr.net>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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.xen.org,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, Konrad Rzeszutek Wilk wrote:

> On Thu, Dec 04, 2014 at 08:47:56AM +0100, Olaf Hering wrote:
> > Is that something the sysadmin has to adjust, or should the xen source
> > provide proper values?
> It would be rather cumbersome if the sysadmin had to adjust it. The goal
> here would be that distros could use it and package it neatly so that it
> works out of the box.
> 
> What are the proper values in SuSE?

I have no idea, we dont run with selinux. At least not per default.
So what is supposed to be there, why does it happen to work for me?

And if there are changes required to the config file, they should be
passed in via configure instead of doing a patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 07:47:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 07: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 1Xwnbz-0001Z7-SD; Fri, 05 Dec 2014 07:47:35 +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 1Xwnby-0001Yz-Oa
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 07:47:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	07/BC-09842-61361845; Fri, 05 Dec 2014 07:47:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417765653!13567397!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17368 invoked from network); 5 Dec 2014 07:47:33 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 07:47:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417765653; l=706;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=VQUfYT1IIL8c2/9x6wolWVcX88k=;
	b=h1T1fnTL02Kgc9bW0fNUl5P3bYkRSSrejalzF7Z0+Zsm2XKJ/NvFI/K9MlkJVNfxdEZ
	xe83pL2TwH6g6BISHcoDW+yjySAsoyUu1mCrQ8Kqme9wOZqWODNfaB/v0loy3vklsEmwe
	i9XDUehqq/PmwZnS4tKXAecAIdKZI0r7cvU=
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.2 AUTH) with ESMTPSA id 00145eqB57lXOUg
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 08:47:33 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 919A65015D; Fri,  5 Dec 2014 08:47:33 +0100 (CET)
Date: Fri, 5 Dec 2014 08:47:33 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20141205074733.GA29524@aepfle.de>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
	<20141204074756.GA4505@aepfle.de>
	<20141205021508.GB19424@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205021508.GB19424@andromeda.dapyr.net>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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.xen.org,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, Konrad Rzeszutek Wilk wrote:

> On Thu, Dec 04, 2014 at 08:47:56AM +0100, Olaf Hering wrote:
> > Is that something the sysadmin has to adjust, or should the xen source
> > provide proper values?
> It would be rather cumbersome if the sysadmin had to adjust it. The goal
> here would be that distros could use it and package it neatly so that it
> works out of the box.
> 
> What are the proper values in SuSE?

I have no idea, we dont run with selinux. At least not per default.
So what is supposed to be there, why does it happen to work for me?

And if there are changes required to the config file, they should be
passed in via configure instead of doing a patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 07:48:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 07:48:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwnd3-0001h8-G9; Fri, 05 Dec 2014 07:48:41 +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 1Xwm8q-0006Qy-TS
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 06:13:25 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	D1/65-03145-40D41845; Fri, 05 Dec 2014 06:13:24 +0000
X-Env-Sender: n0ano@n0ano.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417760001!13148758!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19703 invoked from network); 5 Dec 2014 06:13:23 -0000
Received: from willie.n0ano.com (HELO willie.n0ano.com) (67.41.209.129)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Dec 2014 06:13:23 -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 1Xwm8n-0002BX-3T; Thu, 04 Dec 2014 23:13:21 -0700
Received: from n0ano by maat.n0ano.com with local (Exim 4.77)
	(envelope-from <n0ano@n0ano.com>)
	id 1Xwm8W-0004iF-Qr; Thu, 04 Dec 2014 23:13:04 -0700
Date: Thu, 4 Dec 2014 23:13:04 -0700
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141205061304.GI22950@n0ano.com>
References: <20141121051219.GB22258@n0ano.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610E6D8@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610E6D8@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
From: Don Dugger <n0ano@n0ano.com>
X-Mailman-Approved-At: Fri, 05 Dec 2014 07:48:41 +0000
Cc: "Dong, Eddie" <eddie.dong@intel.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>, "Dugger,
	Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Auld,
	Will" <will.auld@intel.com>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [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

On Fri, Dec 05, 2014 at 05:30:52AM +0000, Tian, Kevin wrote:
> > From: Donald D. Dugger
> > Sent: Friday, November 21, 2014 1:12 PM
> > 
> > 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.
> 
> I'm OK with the patch except one comment. User usually thinks bool option
> means default, but here an explicit 'default' actually means a different value.
> It's a bit confused to me. How about changing 'default' to another more
> meaningful word, e.g. 'max'? and you may still keep a 'snb_igd_quirk=
> legacy' option, so all the possibilities are included in the assigned case, with
> bool option alias to 'legacy'.

I don't see a need for a `legacy' option, merely enabling the option (which is
what current users are doing) will select the current 1 sec. timeout.  If you
don't like `default' (and I don't like `max' since that would select a value
less that the current default) how about the string `cap' (the cap on the
theoretical timeout) to select the 670 msec value?

> 
> Thanks
> Kevin

...

-- 
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 Dec 05 07:48:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 07:48:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwnd3-0001h8-G9; Fri, 05 Dec 2014 07:48:41 +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 1Xwm8q-0006Qy-TS
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 06:13:25 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	D1/65-03145-40D41845; Fri, 05 Dec 2014 06:13:24 +0000
X-Env-Sender: n0ano@n0ano.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417760001!13148758!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19703 invoked from network); 5 Dec 2014 06:13:23 -0000
Received: from willie.n0ano.com (HELO willie.n0ano.com) (67.41.209.129)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Dec 2014 06:13:23 -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 1Xwm8n-0002BX-3T; Thu, 04 Dec 2014 23:13:21 -0700
Received: from n0ano by maat.n0ano.com with local (Exim 4.77)
	(envelope-from <n0ano@n0ano.com>)
	id 1Xwm8W-0004iF-Qr; Thu, 04 Dec 2014 23:13:04 -0700
Date: Thu, 4 Dec 2014 23:13:04 -0700
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141205061304.GI22950@n0ano.com>
References: <20141121051219.GB22258@n0ano.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610E6D8@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610E6D8@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
From: Don Dugger <n0ano@n0ano.com>
X-Mailman-Approved-At: Fri, 05 Dec 2014 07:48:41 +0000
Cc: "Dong, Eddie" <eddie.dong@intel.com>, "Kay,
	Allen M" <allen.m.kay@intel.com>, "Dugger,
	Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Auld,
	Will" <will.auld@intel.com>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [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

On Fri, Dec 05, 2014 at 05:30:52AM +0000, Tian, Kevin wrote:
> > From: Donald D. Dugger
> > Sent: Friday, November 21, 2014 1:12 PM
> > 
> > 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.
> 
> I'm OK with the patch except one comment. User usually thinks bool option
> means default, but here an explicit 'default' actually means a different value.
> It's a bit confused to me. How about changing 'default' to another more
> meaningful word, e.g. 'max'? and you may still keep a 'snb_igd_quirk=
> legacy' option, so all the possibilities are included in the assigned case, with
> bool option alias to 'legacy'.

I don't see a need for a `legacy' option, merely enabling the option (which is
what current users are doing) will select the current 1 sec. timeout.  If you
don't like `default' (and I don't like `max' since that would select a value
less that the current default) how about the string `cap' (the cap on the
theoretical timeout) to select the 670 msec value?

> 
> Thanks
> Kevin

...

-- 
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 Dec 05 08:03:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 08: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 1Xwnr4-0002qK-BJ; Fri, 05 Dec 2014 08:03:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xwnr3-0002qF-4d
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 08:03:09 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	43/DF-28296-CB661845; Fri, 05 Dec 2014 08:03:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417766587!11173709!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19125 invoked from network); 5 Dec 2014 08:03:07 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 08:03:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417766587; l=1370;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=xe7UVThBh017CLOt0R7zPfTi1Sk=;
	b=iZhd+b6bOS4PK/bJteE2o6MFo7Qebq6+DxRIPcgiyKrNodbk+m7he+bRNWph7341S+X
	XJZ8M4uSOoW/q1ue9eRKr2TAF2MxBPWJ7esAx7onf2YlJcyBmZn08hFQoy+6dMEF+Z9iE
	uyIi48vN1mWcjZ5A+udvUM+KTouJxMw2U6s=
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.2 AUTH) with ESMTPSA id Q07caaqB5837LW7
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 09:03:07 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 1F3315015E; Fri,  5 Dec 2014 09:03:08 +0100 (CET)
Date: Fri, 5 Dec 2014 09:03:08 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20141205080307.GA31016@aepfle.de>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
	<20141204074756.GA4505@aepfle.de>
	<20141205021508.GB19424@andromeda.dapyr.net>
	<20141205074733.GA29524@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205074733.GA29524@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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.xen.org,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Olaf Hering wrote:

> On Thu, Dec 04, Konrad Rzeszutek Wilk wrote:
> 
> > On Thu, Dec 04, 2014 at 08:47:56AM +0100, Olaf Hering wrote:
> > > Is that something the sysadmin has to adjust, or should the xen source
> > > provide proper values?
> > It would be rather cumbersome if the sysadmin had to adjust it. The goal
> > here would be that distros could use it and package it neatly so that it
> > works out of the box.
> > 
> > What are the proper values in SuSE?
> 
> I have no idea, we dont run with selinux. At least not per default.
> So what is supposed to be there, why does it happen to work for me?
> 
> And if there are changes required to the config file, they should be
> passed in via configure instead of doing a patch.

So looking again at
tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in it seems that it
happens to work for me because XENSTORED_MOUNT_CTX is set within that
file. So if something happens to need a different value for
XENSTORED_MOUNT_CTX it has to be provided in the to-be-created config
file: EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
This config file is not part of xen. 

Does the current state of xen-4.5 (like "make rpmball") not work out of
the box on Fedora or anything that uses selinux? If thats the case it
should probably be covered in the INSTALL file.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 08:03:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 08: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 1Xwnr4-0002qK-BJ; Fri, 05 Dec 2014 08:03:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xwnr3-0002qF-4d
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 08:03:09 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	43/DF-28296-CB661845; Fri, 05 Dec 2014 08:03:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417766587!11173709!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19125 invoked from network); 5 Dec 2014 08:03:07 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 08:03:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417766587; l=1370;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=xe7UVThBh017CLOt0R7zPfTi1Sk=;
	b=iZhd+b6bOS4PK/bJteE2o6MFo7Qebq6+DxRIPcgiyKrNodbk+m7he+bRNWph7341S+X
	XJZ8M4uSOoW/q1ue9eRKr2TAF2MxBPWJ7esAx7onf2YlJcyBmZn08hFQoy+6dMEF+Z9iE
	uyIi48vN1mWcjZ5A+udvUM+KTouJxMw2U6s=
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.2 AUTH) with ESMTPSA id Q07caaqB5837LW7
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 09:03:07 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 1F3315015E; Fri,  5 Dec 2014 09:03:08 +0100 (CET)
Date: Fri, 5 Dec 2014 09:03:08 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20141205080307.GA31016@aepfle.de>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
	<20141204074756.GA4505@aepfle.de>
	<20141205021508.GB19424@andromeda.dapyr.net>
	<20141205074733.GA29524@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205074733.GA29524@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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.xen.org,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Olaf Hering wrote:

> On Thu, Dec 04, Konrad Rzeszutek Wilk wrote:
> 
> > On Thu, Dec 04, 2014 at 08:47:56AM +0100, Olaf Hering wrote:
> > > Is that something the sysadmin has to adjust, or should the xen source
> > > provide proper values?
> > It would be rather cumbersome if the sysadmin had to adjust it. The goal
> > here would be that distros could use it and package it neatly so that it
> > works out of the box.
> > 
> > What are the proper values in SuSE?
> 
> I have no idea, we dont run with selinux. At least not per default.
> So what is supposed to be there, why does it happen to work for me?
> 
> And if there are changes required to the config file, they should be
> passed in via configure instead of doing a patch.

So looking again at
tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in it seems that it
happens to work for me because XENSTORED_MOUNT_CTX is set within that
file. So if something happens to need a different value for
XENSTORED_MOUNT_CTX it has to be provided in the to-be-created config
file: EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
This config file is not part of xen. 

Does the current state of xen-4.5 (like "make rpmball") not work out of
the box on Fedora or anything that uses selinux? If thats the case it
should probably be covered in the INSTALL file.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 08:29:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 08:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwoFs-0003ZL-Io; Fri, 05 Dec 2014 08:28:48 +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 1XwoFr-0003ZG-4v
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 08:28:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	9D/64-09842-EBC61845; Fri, 05 Dec 2014 08:28:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417768125!13540244!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13590 invoked from network); 5 Dec 2014 08:28:46 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 08:28:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417768125; l=765;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=y4ZQD8UgbAp5RmoerU5j6y2tAf0=;
	b=PWdpi8rqCqfkaML73jtEgFJ0g64A5G98krrXk6/Dq4bp4qiCpFAis/0E1+fUBSty/13
	ReKgMpWgy76HNsCUrTJViT32WXFlD8/+vHYTMbDzQz2RHQLYYLE0miUTzOgnpeQjvnGCM
	CneeasNWFv+CnLSCc4CWtavT2Tnx3rlByTk=
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.2 AUTH) with ESMTPSA id f010f4qB58SjOVm
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 09:28:45 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 26B6D5015D; Fri,  5 Dec 2014 09:28:45 +0100 (CET)
Date: Fri, 5 Dec 2014 09:28:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20141205082844.GA643@aepfle.de>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
	<20141204074756.GA4505@aepfle.de>
	<20141205021508.GB19424@andromeda.dapyr.net>
	<20141205074733.GA29524@aepfle.de>
	<20141205080307.GA31016@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205080307.GA31016@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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.xen.org,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Olaf Hering wrote:

> So looking again at
> tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in it seems that it
> happens to work for me because XENSTORED_MOUNT_CTX is set within that
> file. So if something happens to need a different value for
> XENSTORED_MOUNT_CTX it has to be provided in the to-be-created config
> file: EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> This config file is not part of xen. 

And I wonder why a new config file has to be created, instead of just
reusing the existing tools/hotplug/Linux/init.d/sysconfig.xencommons.in?

I will send out a few patches to adjust the EnvironmentFile handling.

Its just the question if a configure --with-selinux-mount-context=VAL is
needed.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 08:29:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 08:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwoFs-0003ZL-Io; Fri, 05 Dec 2014 08:28:48 +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 1XwoFr-0003ZG-4v
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 08:28:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	9D/64-09842-EBC61845; Fri, 05 Dec 2014 08:28:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417768125!13540244!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13590 invoked from network); 5 Dec 2014 08:28:46 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 08:28:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417768125; l=765;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=y4ZQD8UgbAp5RmoerU5j6y2tAf0=;
	b=PWdpi8rqCqfkaML73jtEgFJ0g64A5G98krrXk6/Dq4bp4qiCpFAis/0E1+fUBSty/13
	ReKgMpWgy76HNsCUrTJViT32WXFlD8/+vHYTMbDzQz2RHQLYYLE0miUTzOgnpeQjvnGCM
	CneeasNWFv+CnLSCc4CWtavT2Tnx3rlByTk=
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.2 AUTH) with ESMTPSA id f010f4qB58SjOVm
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 09:28:45 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 26B6D5015D; Fri,  5 Dec 2014 09:28:45 +0100 (CET)
Date: Fri, 5 Dec 2014 09:28:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20141205082844.GA643@aepfle.de>
References: <1417534763-25053-1-git-send-email-olaf@aepfle.de>
	<1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
	<20141204074756.GA4505@aepfle.de>
	<20141205021508.GB19424@andromeda.dapyr.net>
	<20141205074733.GA29524@aepfle.de>
	<20141205080307.GA31016@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205080307.GA31016@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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.xen.org,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Olaf Hering wrote:

> So looking again at
> tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in it seems that it
> happens to work for me because XENSTORED_MOUNT_CTX is set within that
> file. So if something happens to need a different value for
> XENSTORED_MOUNT_CTX it has to be provided in the to-be-created config
> file: EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> This config file is not part of xen. 

And I wonder why a new config file has to be created, instead of just
reusing the existing tools/hotplug/Linux/init.d/sysconfig.xencommons.in?

I will send out a few patches to adjust the EnvironmentFile handling.

Its just the question if a configure --with-selinux-mount-context=VAL is
needed.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:16:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:16:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwozb-0004vr-ES; Fri, 05 Dec 2014 09:16:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwozZ-0004vm-47
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:16:01 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	3E/98-11581-0D771845; Fri, 05 Dec 2014 09:16:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417770959!7587522!1
X-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 28380 invoked from network); 5 Dec 2014 09:15:59 -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; 5 Dec 2014 09:15:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 09:15:59 +0000
Message-Id: <548185DF020000780004D076@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 09:15:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <54808D6F.302@citrix.com>
In-Reply-To: <54808D6F.302@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Removing the PVH assert in arch/x86/hvm/io.c:87
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 17:35, <roger.pau@citrix.com> wrote:
> I've just stumbled upon this assert while testing PVH on different
> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
> and OUTS go through handle_mmio. So using this instructions from a PVH
> guest basically kills Xen.
> 
> I've removed it and everything seems fine, so I'm considering sending a
> patch for 4.5 in order to have it removed. I think the path that could
> trigger the crash because of the missing vioapic stuff is already
> guarded by the other chunk added in the same patch.

Iirc we settled on forbidding paths to handle_mmio() for PVH (hence
the ASSERT()). Sadly you provide way too little detail on what is
actually happening in your case: What's the use case of to-be-
emulated INS/OUTS in a PVH kernel? What's the call tree that gets
you into handle_mmio(), considering that both calls to
handle_mmio_with_translation() from hvm_hap_nested_page_fault()
as well as the one to handle_mmio() ought to be unreachable for PVH?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:16:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:16:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwozb-0004vr-ES; Fri, 05 Dec 2014 09:16:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwozZ-0004vm-47
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:16:01 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	3E/98-11581-0D771845; Fri, 05 Dec 2014 09:16:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1417770959!7587522!1
X-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 28380 invoked from network); 5 Dec 2014 09:15:59 -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; 5 Dec 2014 09:15:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 09:15:59 +0000
Message-Id: <548185DF020000780004D076@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 09:15:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <54808D6F.302@citrix.com>
In-Reply-To: <54808D6F.302@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Removing the PVH assert in arch/x86/hvm/io.c:87
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 17:35, <roger.pau@citrix.com> wrote:
> I've just stumbled upon this assert while testing PVH on different
> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
> and OUTS go through handle_mmio. So using this instructions from a PVH
> guest basically kills Xen.
> 
> I've removed it and everything seems fine, so I'm considering sending a
> patch for 4.5 in order to have it removed. I think the path that could
> trigger the crash because of the missing vioapic stuff is already
> guarded by the other chunk added in the same patch.

Iirc we settled on forbidding paths to handle_mmio() for PVH (hence
the ASSERT()). Sadly you provide way too little detail on what is
actually happening in your case: What's the use case of to-be-
emulated INS/OUTS in a PVH kernel? What's the call tree that gets
you into handle_mmio(), considering that both calls to
handle_mmio_with_translation() from hvm_hap_nested_page_fault()
as well as the one to handle_mmio() ought to be unreachable for PVH?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:20:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1Xwp4K-00053f-57; Fri, 05 Dec 2014 09:20: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 1Xwp4J-00053a-DG
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:20:55 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	64/DF-03145-6F871845; Fri, 05 Dec 2014 09:20:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417771254!13200640!1
X-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 19339 invoked from network); 5 Dec 2014 09:20:54 -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; 5 Dec 2014 09:20:54 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 09:20:54 +0000
Message-Id: <54818706020000780004D07D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 09:20:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <20141204172511.GF43116@deinos.phlegethon.org>
In-Reply-To: <20141204172511.GF43116@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] PVH cleanups after 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.12.14 at 18:25, <tim@xen.org> wrote:
> Potential feature flags, based on whiteboard notes at the session.
> Things that are 'Yes' in both columns might not need actual flags :)
> 
>                      'HVM'       'PVH'
> 64bit hypercalls      Yes         Yes
> 32bit hypercalls      Yes         No

Iiuc the lack of support of 32-bit hypercalls is simply because PVH
guests aren't expected to use them as being always 64-bit right
now. I.e. I can't really see why we couldn't just enable them once
the 64-bit hypercall tables got combined, in which case we wouldn't
need a feature flag here either.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:20:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1Xwp4K-00053f-57; Fri, 05 Dec 2014 09:20: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 1Xwp4J-00053a-DG
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:20:55 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	64/DF-03145-6F871845; Fri, 05 Dec 2014 09:20:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417771254!13200640!1
X-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 19339 invoked from network); 5 Dec 2014 09:20:54 -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; 5 Dec 2014 09:20:54 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 09:20:54 +0000
Message-Id: <54818706020000780004D07D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 09:20:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <20141204172511.GF43116@deinos.phlegethon.org>
In-Reply-To: <20141204172511.GF43116@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] PVH cleanups after 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.12.14 at 18:25, <tim@xen.org> wrote:
> Potential feature flags, based on whiteboard notes at the session.
> Things that are 'Yes' in both columns might not need actual flags :)
> 
>                      'HVM'       'PVH'
> 64bit hypercalls      Yes         Yes
> 32bit hypercalls      Yes         No

Iiuc the lack of support of 32-bit hypercalls is simply because PVH
guests aren't expected to use them as being always 64-bit right
now. I.e. I can't really see why we couldn't just enable them once
the 64-bit hypercall tables got combined, in which case we wouldn't
need a feature flag here either.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:21:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwp51-00057p-Iq; Fri, 05 Dec 2014 09:21:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sagun@nexchanges.com>) id 1Xwp50-00057a-7i
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 09:21:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C3/C6-09842-12971845; Fri, 05 Dec 2014 09:21:37 +0000
X-Env-Sender: sagun@nexchanges.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417771295!13620080!1
X-Originating-IP: [209.85.216.175]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6874 invoked from network); 5 Dec 2014 09:21:36 -0000
Received: from mail-qc0-f175.google.com (HELO mail-qc0-f175.google.com)
	(209.85.216.175)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 09:21:36 -0000
Received: by mail-qc0-f175.google.com with SMTP id b13so171786qcw.20
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 01:21: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=ZAbMEkNDW6LFck97z2XBxAVCwKoyty2Stt2LbWQpJcw=;
	b=FNvpemlk+g10NYn/StdurGWjo4m/OPJCLrhfZ5pXNxYusTuMPtNWx8opn1997FxbW/
	K78O34ApLSgl+ORxae1tskvyVox5yyCwQzTg06EiEbKNUqZZPobWWYHgMDI71SLlx3wN
	D3TafrqQ0B6/A7JnFUdvuxoQTVo79+j22JWE79ahNB170MdBHhSqxLy+oy19WZEO07jT
	gBqcXw0TlWKuHdr/ivqcVaEdEacWmfkwnqMI3zbklsCQpiPPq71rmRTw6rNGu/b79Ny1
	aalqRotLOeGWce1Um2aTcja3s49+vDWcbvagcFBnfroTuUEjBRih+pt6P0H7cim52zne
	Ps7w==
X-Gm-Message-State: ALoCoQn9R0dbaA1rCQ9yhk3CKczap4oi9oyOdd+umHpK5V75D8CojYkitg9eAsgFjPKrIYxd+Jcg
MIME-Version: 1.0
X-Received: by 10.224.46.66 with SMTP id i2mr24015558qaf.72.1417771295215;
	Fri, 05 Dec 2014 01:21:35 -0800 (PST)
Received: by 10.140.102.183 with HTTP; Fri, 5 Dec 2014 01:21:35 -0800 (PST)
In-Reply-To: <1417688979.22808.6.camel@citrix.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
	<1417688979.22808.6.camel@citrix.com>
Date: Fri, 5 Dec 2014 14:51:35 +0530
Message-ID: <CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@mail.gmail.com>
From: Sagun Garg <sagun@nexchanges.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0709741566140618002=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0709741566140618002==
Content-Type: multipart/alternative; boundary=001a11c29e0a6ca80c0509749a4d

--001a11c29e0a6ca80c0509749a4d
Content-Type: text/plain; charset=UTF-8

Thanks Ian for helping me with the links,

FYI, I found following link :
https://blog.xenproject.org/2014/04/01/virtualization-on-arm-with-xen/
(Here it suggests using Foundation Model and Linaro, basically an emulator
to get started) though the advanced emulators offered by ARM are paid ones)

Would it be possible to install these ARM emulators on say AWS Amazon /
Digital Ocean with the free subscription to try and test these out ? Amazon
uses Xen as the underlying virtualization technology and it also uses
custom kernels since last 2 years so coincidentally it might just work
though the question is how (I read this somewhere on a blog, but I can't
point a link to it as I don't remember it, but would you know of such a
tuturial / link where someone else has pursued the same ?)

or would you know of any "RISC as a Service with ARM processors" that can
be provisioned on demand like AWS where we can install XEN on ARM directly
? Any cloud offering that can be used would be of great help.

Also I was wondering what are the risks / or rather shortcomings in trying
directly on the device Nexus / or any other ARM phone which has been tested
for the same.

Thanks in Advance

Cheers
Sagun Garg
Chief System Architect
www.nexchanges.com
+91 9920050386





On Thu, Dec 4, 2014 at 3:59 PM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> On Thu, 2014-12-04 at 15:44 +0530, Sagun Garg wrote:
> > Hi,
> >
> >
> > I am new to the world of "Xen on ARM" would like to seek help from
> > community on how can I install Xen on ARM on a Nexus Phone / Tablet or
> > an emulator
> >
> >
> > I actually wish to try and install a unikernel : LING (Erlang on Xen)
> > on top of the hypervisor dual booted with Android or QNX on a mobile
> > phone or a tablet.
> >
> >
> > If someone can help me point to a TUTORIAL, LINK or some BLOG it will
> > be awesome.
>
> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions is the
> starting point for all Xen on ARM stuff. There is a list of supported
> hardware there, but note that it doesn't include Nexus phones etc,
> although of course you could port it if you wanted.
>
> Arndale is probably the most mobile-like platform there (being a dev
> board for the Exynos processor used in many phones), my personal
> recommendation for running Xen on ARM is a sunxi platform, e.g.
> cubietruck except in your case I'm not aware of anyone having looked
> into the graphics side of things, which is probably a blocker for you.
>
> You may be interested in http://wiki.xen.org/wiki/Xen_ARM_%28PV%29,
> which has been run on tablets/phones, but note that it is not developed
> by anyone on this list and is mostly abandonware as far as the open
> source code goes.
>
> Ian.
>
>
>
>

--001a11c29e0a6ca80c0509749a4d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Thanks Ian for helping me with the links,<b=
r><br></div>FYI, I found following link : <a href=3D"https://blog.xenprojec=
t.org/2014/04/01/virtualization-on-arm-with-xen/">https://blog.xenproject.o=
rg/2014/04/01/virtualization-on-arm-with-xen/</a> (Here it suggests using F=
oundation Model and Linaro, basically an emulator to get started) though th=
e advanced emulators offered by ARM are paid ones)<br><br></div>Would it be=
 possible to install these ARM emulators on say AWS Amazon / Digital Ocean =
with the free subscription to try and test these out ? Amazon uses Xen as t=
he underlying virtualization technology and it also uses custom kernels sin=
ce last 2 years so coincidentally it might just work though the question is=
 how (I read this somewhere on a blog, but I can&#39;t point a link to it a=
s I don&#39;t remember it, but would you know of such a tuturial / link whe=
re someone else has pursued the same ?)<br><br></div>or would you know of a=
ny &quot;RISC as a Service with ARM processors&quot; that can be provisione=
d on demand like AWS where we can install XEN on ARM directly ? Any cloud o=
ffering that can be used would be of great help.<br><div><div><br>Also I wa=
s wondering what are the risks / or rather shortcomings in trying directly =
on the device Nexus / or any other ARM phone which has been tested for the =
same. <br><br></div><div>Thanks in Advance<br><br></div><div>Cheers<br>Sagu=
n Garg<br>Chief System Architect<br></div><div><a href=3D"http://www.nexcha=
nges.com">www.nexchanges.com</a><br>+91 9920050386<br></div><div><br><br><b=
r><br></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Thu, Dec 4, 2014 at 3:59 PM, Ian Campbell <span dir=3D"ltr">&lt;<=
a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@ci=
trix.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 cl=
ass=3D"">On Thu, 2014-12-04 at 15:44 +0530, Sagun Garg wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt;<br>
&gt; I am new to the world of &quot;Xen on ARM&quot; would like to seek hel=
p from<br>
&gt; community on how can I install Xen on ARM on a Nexus Phone / Tablet or=
<br>
&gt; an emulator<br>
&gt;<br>
&gt;<br>
&gt; I actually wish to try and install a unikernel : LING (Erlang on Xen)<=
br>
&gt; on top of the hypervisor dual booted with Android or QNX on a mobile<b=
r>
&gt; phone or a tablet.<br>
&gt;<br>
&gt;<br>
&gt; If someone can help me point to a TUTORIAL, LINK or some BLOG it will<=
br>
&gt; be awesome.<br>
<br>
</span><a href=3D"http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Exte=
nsions" target=3D"_blank">http://wiki.xen.org/wiki/Xen_ARM_with_Virtualizat=
ion_Extensions</a> is the<br>
starting point for all Xen on ARM stuff. There is a list of supported<br>
hardware there, but note that it doesn&#39;t include Nexus phones etc,<br>
although of course you could port it if you wanted.<br>
<br>
Arndale is probably the most mobile-like platform there (being a dev<br>
board for the Exynos processor used in many phones), my personal<br>
recommendation for running Xen on ARM is a sunxi platform, e.g.<br>
cubietruck except in your case I&#39;m not aware of anyone having looked<br=
>
into the graphics side of things, which is probably a blocker for you.<br>
<br>
You may be interested in <a href=3D"http://wiki.xen.org/wiki/Xen_ARM_%28PV%=
29" target=3D"_blank">http://wiki.xen.org/wiki/Xen_ARM_%28PV%29</a>,<br>
which has been run on tablets/phones, but note that it is not developed<br>
by anyone on this list and is mostly abandonware as far as the open<br>
source code goes.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--001a11c29e0a6ca80c0509749a4d--


--===============0709741566140618002==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0709741566140618002==--


From xen-devel-bounces@lists.xen.org Fri Dec 05 09:21:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwp51-00057p-Iq; Fri, 05 Dec 2014 09:21:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sagun@nexchanges.com>) id 1Xwp50-00057a-7i
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 09:21:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C3/C6-09842-12971845; Fri, 05 Dec 2014 09:21:37 +0000
X-Env-Sender: sagun@nexchanges.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417771295!13620080!1
X-Originating-IP: [209.85.216.175]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6874 invoked from network); 5 Dec 2014 09:21:36 -0000
Received: from mail-qc0-f175.google.com (HELO mail-qc0-f175.google.com)
	(209.85.216.175)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 09:21:36 -0000
Received: by mail-qc0-f175.google.com with SMTP id b13so171786qcw.20
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 01:21: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=ZAbMEkNDW6LFck97z2XBxAVCwKoyty2Stt2LbWQpJcw=;
	b=FNvpemlk+g10NYn/StdurGWjo4m/OPJCLrhfZ5pXNxYusTuMPtNWx8opn1997FxbW/
	K78O34ApLSgl+ORxae1tskvyVox5yyCwQzTg06EiEbKNUqZZPobWWYHgMDI71SLlx3wN
	D3TafrqQ0B6/A7JnFUdvuxoQTVo79+j22JWE79ahNB170MdBHhSqxLy+oy19WZEO07jT
	gBqcXw0TlWKuHdr/ivqcVaEdEacWmfkwnqMI3zbklsCQpiPPq71rmRTw6rNGu/b79Ny1
	aalqRotLOeGWce1Um2aTcja3s49+vDWcbvagcFBnfroTuUEjBRih+pt6P0H7cim52zne
	Ps7w==
X-Gm-Message-State: ALoCoQn9R0dbaA1rCQ9yhk3CKczap4oi9oyOdd+umHpK5V75D8CojYkitg9eAsgFjPKrIYxd+Jcg
MIME-Version: 1.0
X-Received: by 10.224.46.66 with SMTP id i2mr24015558qaf.72.1417771295215;
	Fri, 05 Dec 2014 01:21:35 -0800 (PST)
Received: by 10.140.102.183 with HTTP; Fri, 5 Dec 2014 01:21:35 -0800 (PST)
In-Reply-To: <1417688979.22808.6.camel@citrix.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
	<1417688979.22808.6.camel@citrix.com>
Date: Fri, 5 Dec 2014 14:51:35 +0530
Message-ID: <CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@mail.gmail.com>
From: Sagun Garg <sagun@nexchanges.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0709741566140618002=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0709741566140618002==
Content-Type: multipart/alternative; boundary=001a11c29e0a6ca80c0509749a4d

--001a11c29e0a6ca80c0509749a4d
Content-Type: text/plain; charset=UTF-8

Thanks Ian for helping me with the links,

FYI, I found following link :
https://blog.xenproject.org/2014/04/01/virtualization-on-arm-with-xen/
(Here it suggests using Foundation Model and Linaro, basically an emulator
to get started) though the advanced emulators offered by ARM are paid ones)

Would it be possible to install these ARM emulators on say AWS Amazon /
Digital Ocean with the free subscription to try and test these out ? Amazon
uses Xen as the underlying virtualization technology and it also uses
custom kernels since last 2 years so coincidentally it might just work
though the question is how (I read this somewhere on a blog, but I can't
point a link to it as I don't remember it, but would you know of such a
tuturial / link where someone else has pursued the same ?)

or would you know of any "RISC as a Service with ARM processors" that can
be provisioned on demand like AWS where we can install XEN on ARM directly
? Any cloud offering that can be used would be of great help.

Also I was wondering what are the risks / or rather shortcomings in trying
directly on the device Nexus / or any other ARM phone which has been tested
for the same.

Thanks in Advance

Cheers
Sagun Garg
Chief System Architect
www.nexchanges.com
+91 9920050386





On Thu, Dec 4, 2014 at 3:59 PM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> On Thu, 2014-12-04 at 15:44 +0530, Sagun Garg wrote:
> > Hi,
> >
> >
> > I am new to the world of "Xen on ARM" would like to seek help from
> > community on how can I install Xen on ARM on a Nexus Phone / Tablet or
> > an emulator
> >
> >
> > I actually wish to try and install a unikernel : LING (Erlang on Xen)
> > on top of the hypervisor dual booted with Android or QNX on a mobile
> > phone or a tablet.
> >
> >
> > If someone can help me point to a TUTORIAL, LINK or some BLOG it will
> > be awesome.
>
> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions is the
> starting point for all Xen on ARM stuff. There is a list of supported
> hardware there, but note that it doesn't include Nexus phones etc,
> although of course you could port it if you wanted.
>
> Arndale is probably the most mobile-like platform there (being a dev
> board for the Exynos processor used in many phones), my personal
> recommendation for running Xen on ARM is a sunxi platform, e.g.
> cubietruck except in your case I'm not aware of anyone having looked
> into the graphics side of things, which is probably a blocker for you.
>
> You may be interested in http://wiki.xen.org/wiki/Xen_ARM_%28PV%29,
> which has been run on tablets/phones, but note that it is not developed
> by anyone on this list and is mostly abandonware as far as the open
> source code goes.
>
> Ian.
>
>
>
>

--001a11c29e0a6ca80c0509749a4d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Thanks Ian for helping me with the links,<b=
r><br></div>FYI, I found following link : <a href=3D"https://blog.xenprojec=
t.org/2014/04/01/virtualization-on-arm-with-xen/">https://blog.xenproject.o=
rg/2014/04/01/virtualization-on-arm-with-xen/</a> (Here it suggests using F=
oundation Model and Linaro, basically an emulator to get started) though th=
e advanced emulators offered by ARM are paid ones)<br><br></div>Would it be=
 possible to install these ARM emulators on say AWS Amazon / Digital Ocean =
with the free subscription to try and test these out ? Amazon uses Xen as t=
he underlying virtualization technology and it also uses custom kernels sin=
ce last 2 years so coincidentally it might just work though the question is=
 how (I read this somewhere on a blog, but I can&#39;t point a link to it a=
s I don&#39;t remember it, but would you know of such a tuturial / link whe=
re someone else has pursued the same ?)<br><br></div>or would you know of a=
ny &quot;RISC as a Service with ARM processors&quot; that can be provisione=
d on demand like AWS where we can install XEN on ARM directly ? Any cloud o=
ffering that can be used would be of great help.<br><div><div><br>Also I wa=
s wondering what are the risks / or rather shortcomings in trying directly =
on the device Nexus / or any other ARM phone which has been tested for the =
same. <br><br></div><div>Thanks in Advance<br><br></div><div>Cheers<br>Sagu=
n Garg<br>Chief System Architect<br></div><div><a href=3D"http://www.nexcha=
nges.com">www.nexchanges.com</a><br>+91 9920050386<br></div><div><br><br><b=
r><br></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Thu, Dec 4, 2014 at 3:59 PM, Ian Campbell <span dir=3D"ltr">&lt;<=
a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@ci=
trix.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 cl=
ass=3D"">On Thu, 2014-12-04 at 15:44 +0530, Sagun Garg wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt;<br>
&gt; I am new to the world of &quot;Xen on ARM&quot; would like to seek hel=
p from<br>
&gt; community on how can I install Xen on ARM on a Nexus Phone / Tablet or=
<br>
&gt; an emulator<br>
&gt;<br>
&gt;<br>
&gt; I actually wish to try and install a unikernel : LING (Erlang on Xen)<=
br>
&gt; on top of the hypervisor dual booted with Android or QNX on a mobile<b=
r>
&gt; phone or a tablet.<br>
&gt;<br>
&gt;<br>
&gt; If someone can help me point to a TUTORIAL, LINK or some BLOG it will<=
br>
&gt; be awesome.<br>
<br>
</span><a href=3D"http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Exte=
nsions" target=3D"_blank">http://wiki.xen.org/wiki/Xen_ARM_with_Virtualizat=
ion_Extensions</a> is the<br>
starting point for all Xen on ARM stuff. There is a list of supported<br>
hardware there, but note that it doesn&#39;t include Nexus phones etc,<br>
although of course you could port it if you wanted.<br>
<br>
Arndale is probably the most mobile-like platform there (being a dev<br>
board for the Exynos processor used in many phones), my personal<br>
recommendation for running Xen on ARM is a sunxi platform, e.g.<br>
cubietruck except in your case I&#39;m not aware of anyone having looked<br=
>
into the graphics side of things, which is probably a blocker for you.<br>
<br>
You may be interested in <a href=3D"http://wiki.xen.org/wiki/Xen_ARM_%28PV%=
29" target=3D"_blank">http://wiki.xen.org/wiki/Xen_ARM_%28PV%29</a>,<br>
which has been run on tablets/phones, but note that it is not developed<br>
by anyone on this list and is mostly abandonware as far as the open<br>
source code goes.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--001a11c29e0a6ca80c0509749a4d--


--===============0709741566140618002==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0709741566140618002==--


From xen-devel-bounces@lists.xen.org Fri Dec 05 09:32:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:32:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpFS-0005eB-O9; Fri, 05 Dec 2014 09:32:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwpFQ-0005e6-Vy
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 09:32:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BB/DA-25276-8AB71845; Fri, 05 Dec 2014 09:32:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417771942!13558665!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 2056 invoked from network); 5 Dec 2014 09:32:23 -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 Dec 2014 09:32:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200627078"
Message-ID: <1417771940.22808.39.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sagun Garg <sagun@nexchanges.com>
Date: Fri, 5 Dec 2014 09:32:20 +0000
In-Reply-To: <CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@mail.gmail.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
	<1417688979.22808.6.camel@citrix.com>
	<CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@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
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't top post.

On Fri, 2014-12-05 at 14:51 +0530, Sagun Garg wrote:
> Thanks Ian for helping me with the links,
> 
> 
> FYI, I found following link :
> https://blog.xenproject.org/2014/04/01/virtualization-on-arm-with-xen/
> (Here it suggests using Foundation Model and Linaro, basically an
> emulator to get started) though the advanced emulators offered by ARM
> are paid ones)
> 
> 
> Would it be possible to install these ARM emulators on say AWS
> Amazon / Digital Ocean with the free subscription to try and test
> these out ?

Those emulators will run on any x86 system, whether it is virtualised by
Amazon/DO or not. They are quite CPU intensive though.

>  Amazon uses Xen as the underlying virtualization technology and it
> also uses custom kernels since last 2 years so coincidentally it might
> just work though the question is how (I read this somewhere on a blog,
> but I can't point a link to it as I don't remember it, but would you
> know of such a tuturial / link where someone else has pursued the
> same ?)

Amazon offers x86 Xen, not ARM Xen. Xen does not do any kind of
cross-architecture virtualisation (i.e. running ARM OSes on X86, or vice
versa). So the fact that Amazon happens to run x86 Xen is of no use when
you want to run ARM Xen.

> or would you know of any "RISC as a Service with ARM processors" that
> can be provisioned on demand like AWS where we can install XEN on ARM
> directly ? Any cloud offering that can be used would be of great help.

I'm not aware of any cloud service offering ARM at the moment.

> Also I was wondering what are the risks / or rather shortcomings in
> trying directly on the device Nexus / or any other ARM phone which has
> been tested for the same. 

Not sure what sorts of risks you mean, I don't think there is anything
Xen specific here, just the usual stuff with running an untested OS on
any new platform.

I don't know if Nexus devices are brickable, but if so then that might
be an issue with trying any untested OS on them.

Phones and the like aren't typically very good debug platforms (i.e. no
serial, no JTAG etc) so running an untested OS on them can end up being
hard (but not impossible) to debug if it doesn't work, that's why
platforms such as the Arndale exist -- they are mobile phones with all
the extra useful debug stuff brought out to headers.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:32:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:32:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpFS-0005eB-O9; Fri, 05 Dec 2014 09:32:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwpFQ-0005e6-Vy
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 09:32:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BB/DA-25276-8AB71845; Fri, 05 Dec 2014 09:32:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1417771942!13558665!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 2056 invoked from network); 5 Dec 2014 09:32:23 -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 Dec 2014 09:32:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200627078"
Message-ID: <1417771940.22808.39.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sagun Garg <sagun@nexchanges.com>
Date: Fri, 5 Dec 2014 09:32:20 +0000
In-Reply-To: <CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@mail.gmail.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
	<1417688979.22808.6.camel@citrix.com>
	<CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@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
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't top post.

On Fri, 2014-12-05 at 14:51 +0530, Sagun Garg wrote:
> Thanks Ian for helping me with the links,
> 
> 
> FYI, I found following link :
> https://blog.xenproject.org/2014/04/01/virtualization-on-arm-with-xen/
> (Here it suggests using Foundation Model and Linaro, basically an
> emulator to get started) though the advanced emulators offered by ARM
> are paid ones)
> 
> 
> Would it be possible to install these ARM emulators on say AWS
> Amazon / Digital Ocean with the free subscription to try and test
> these out ?

Those emulators will run on any x86 system, whether it is virtualised by
Amazon/DO or not. They are quite CPU intensive though.

>  Amazon uses Xen as the underlying virtualization technology and it
> also uses custom kernels since last 2 years so coincidentally it might
> just work though the question is how (I read this somewhere on a blog,
> but I can't point a link to it as I don't remember it, but would you
> know of such a tuturial / link where someone else has pursued the
> same ?)

Amazon offers x86 Xen, not ARM Xen. Xen does not do any kind of
cross-architecture virtualisation (i.e. running ARM OSes on X86, or vice
versa). So the fact that Amazon happens to run x86 Xen is of no use when
you want to run ARM Xen.

> or would you know of any "RISC as a Service with ARM processors" that
> can be provisioned on demand like AWS where we can install XEN on ARM
> directly ? Any cloud offering that can be used would be of great help.

I'm not aware of any cloud service offering ARM at the moment.

> Also I was wondering what are the risks / or rather shortcomings in
> trying directly on the device Nexus / or any other ARM phone which has
> been tested for the same. 

Not sure what sorts of risks you mean, I don't think there is anything
Xen specific here, just the usual stuff with running an untested OS on
any new platform.

I don't know if Nexus devices are brickable, but if so then that might
be an issue with trying any untested OS on them.

Phones and the like aren't typically very good debug platforms (i.e. no
serial, no JTAG etc) so running an untested OS on them can end up being
hard (but not impossible) to debug if it doesn't work, that's why
platforms such as the Arndale exist -- they are mobile phones with all
the extra useful debug stuff brought out to headers.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:33:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpGE-0005nm-AO; Fri, 05 Dec 2014 09:33: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 1XwpGD-0005nc-GK
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:33:13 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	A9/90-28296-8DB71845; Fri, 05 Dec 2014 09:33:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417771990!11314348!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 31294 invoked from network); 5 Dec 2014 09:33:11 -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 Dec 2014 09:33:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200627359"
Message-ID: <1417771988.22808.40.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 5 Dec 2014 09:33:08 +0000
In-Reply-To: <54816EC3020000780004CFF3@mail.emea.novell.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<CAFECyb8WJwW=winKPNK6eWeEMRa+RNHa_vLwcmUJo3j1WTo3FQ@mail.gmail.com>
	<54816EC3020000780004CFF3@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: keir <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Roy Franz <roy.franz@linaro.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-05 at 07:37 +0000, Jan Beulich wrote:
> >>> On 04.12.14 at 22:22, <roy.franz@linaro.org> wrote:
> > On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
> >>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
> >>>    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
> >>>    code than definitions, declarations and short static
> >>>    functions. So, I think that it is more regular *.c file
> >>>    than header file.
> >>
> >> That's a matter of taste - I'd probably have made it .c too, but
> >> didn't mind it being .h as done by Roy (presumably on the basis
> >> that #include directives are preferred to have .h files as their
> >> operands). The only thing I regret is that I didn't ask for the
> >> pointless efi- prefix to be dropped.
> > 
> > I don't mind a change here, and I agree that it is more like a .c file
> > than a .h.  If a name change is done, is it worth dropping the "efi-" at
> > the same time?
> 
> If we indeed want to change the name (post 4.5), making both
> adjustments at once would be kind of a requirement of mine.

Random thought: *.inc for .c files which happen to be embedded into
another using #include?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:33:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpGE-0005nm-AO; Fri, 05 Dec 2014 09:33: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 1XwpGD-0005nc-GK
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:33:13 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	A9/90-28296-8DB71845; Fri, 05 Dec 2014 09:33:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417771990!11314348!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 31294 invoked from network); 5 Dec 2014 09:33:11 -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 Dec 2014 09:33:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200627359"
Message-ID: <1417771988.22808.40.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 5 Dec 2014 09:33:08 +0000
In-Reply-To: <54816EC3020000780004CFF3@mail.emea.novell.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<CAFECyb8WJwW=winKPNK6eWeEMRa+RNHa_vLwcmUJo3j1WTo3FQ@mail.gmail.com>
	<54816EC3020000780004CFF3@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: keir <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Roy Franz <roy.franz@linaro.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-05 at 07:37 +0000, Jan Beulich wrote:
> >>> On 04.12.14 at 22:22, <roy.franz@linaro.org> wrote:
> > On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
> >>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
> >>>    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
> >>>    code than definitions, declarations and short static
> >>>    functions. So, I think that it is more regular *.c file
> >>>    than header file.
> >>
> >> That's a matter of taste - I'd probably have made it .c too, but
> >> didn't mind it being .h as done by Roy (presumably on the basis
> >> that #include directives are preferred to have .h files as their
> >> operands). The only thing I regret is that I didn't ask for the
> >> pointless efi- prefix to be dropped.
> > 
> > I don't mind a change here, and I agree that it is more like a .c file
> > than a .h.  If a name change is done, is it worth dropping the "efi-" at
> > the same time?
> 
> If we indeed want to change the name (post 4.5), making both
> adjustments at once would be kind of a requirement of mine.

Random thought: *.inc for .c files which happen to be embedded into
another using #include?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:35:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpIk-000631-SQ; Fri, 05 Dec 2014 09:35: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 1XwpIj-00062l-G8
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:35:49 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5E/5E-15461-47C71845; Fri, 05 Dec 2014 09:35:48 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417772148!10184001!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 24448 invoked from network); 5 Dec 2014 09:35:48 -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; 5 Dec 2014 09:35:48 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id B4D35AB43;
	Fri,  5 Dec 2014 09:35:47 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, jbeulich@suse.com
Date: Fri,  5 Dec 2014 10:35:43 +0100
Message-Id: <1417772144-24268-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] 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.

Changes in V3:
- removed XENFEAT_virtual_p2m completely as the linear p2m list and the
  3 level p2m tree can be used in parallel unless the domain size exceeds
  the limit mentioned above
- updated comments to reflect the parallel use of both p2m schemes

Changes in V2:
- add new structure member p2m_generation in arch_shared_info
- rename structure member referencing the p2m address space to p2m_cr3
- add some comments
- removed patches 2-4 as overriding missing XENFEAT_virtual_p2m will be
  done via kernel parameter (patch 2 will be resent after Xen 4.5 is out)


Juergen Gross (1):
  expand x86 arch_shared_info to support linear p2m list

 xen/include/public/arch-x86/xen.h | 36 +++++++++++++++++++++++++++++++++---
 1 file changed, 33 insertions(+), 3 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 Dec 05 09:35:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpIk-000631-SQ; Fri, 05 Dec 2014 09:35: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 1XwpIj-00062l-G8
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:35:49 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5E/5E-15461-47C71845; Fri, 05 Dec 2014 09:35:48 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417772148!10184001!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 24448 invoked from network); 5 Dec 2014 09:35:48 -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; 5 Dec 2014 09:35:48 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id B4D35AB43;
	Fri,  5 Dec 2014 09:35:47 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, jbeulich@suse.com
Date: Fri,  5 Dec 2014 10:35:43 +0100
Message-Id: <1417772144-24268-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] 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.

Changes in V3:
- removed XENFEAT_virtual_p2m completely as the linear p2m list and the
  3 level p2m tree can be used in parallel unless the domain size exceeds
  the limit mentioned above
- updated comments to reflect the parallel use of both p2m schemes

Changes in V2:
- add new structure member p2m_generation in arch_shared_info
- rename structure member referencing the p2m address space to p2m_cr3
- add some comments
- removed patches 2-4 as overriding missing XENFEAT_virtual_p2m will be
  done via kernel parameter (patch 2 will be resent after Xen 4.5 is out)


Juergen Gross (1):
  expand x86 arch_shared_info to support linear p2m list

 xen/include/public/arch-x86/xen.h | 36 +++++++++++++++++++++++++++++++++---
 1 file changed, 33 insertions(+), 3 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 Dec 05 09:35:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpIm-00063C-7d; Fri, 05 Dec 2014 09:35:52 +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 1XwpIk-00062t-JI
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:35:50 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	08/A8-02699-57C71845; Fri, 05 Dec 2014 09:35:49 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417772148!9851695!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 19056 invoked from network); 5 Dec 2014 09:35:49 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 09:35:49 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A9B79AC24;
	Fri,  5 Dec 2014 09:35:48 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, jbeulich@suse.com
Date: Fri,  5 Dec 2014 10:35:44 +0100
Message-Id: <1417772144-24268-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417772144-24268-1-git-send-email-jgross@suse.com>
References: <1417772144-24268-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [Patch V3] 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 an additional
virtual mapped p2m list.

This patch expands struct arch_shared_info with a new p2m list virtual
address, the root of the page table root and a p2m generation count.
The new information is indicated by the domain to be valid by storing
a non-zero value into the page table root member.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/include/public/arch-x86/xen.h | 36 +++++++++++++++++++++++++++++++++---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index f35804b..c5e880b 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -220,11 +220,41 @@ typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 
 struct arch_shared_info {
-    unsigned long max_pfn;                  /* max pfn that appears in table */
-    /* Frame containing list of mfns containing list of mfns containing p2m. */
+    /*
+     * Number of valid entries in the p2m table(s) anchored at
+     * pfn_to_mfn_frame_list_list and/or p2m_vaddr.
+     */
+    unsigned long max_pfn;
+    /*
+     * Frame containing list of mfns containing list of mfns containing p2m.
+     * A value of 0 indicates it has not yet been set up, ~0 indicates it has
+     * been set to invalid e.g. due to the p2m being too large for the 3-level
+     * p2m tree. In this case the linear mapper p2m list anchored at p2m_vaddr
+     * is to be used.
+     */
     xen_pfn_t     pfn_to_mfn_frame_list_list;
     unsigned long nmi_reason;
-    uint64_t pad[32];
+    /*
+     * Following three fields are valid if p2m_cr3 contains a value different
+     * from 0.
+     * p2m_cr3 is the root of the address space where p2m_vaddr is valid.
+     * p2m_cr3 is in the same format as a cr3 value in the vcpu register state
+     * and holds the folded machine frame number (via xen_pfn_to_cr3) of a
+     * L3 or L4 page table.
+     * p2m_vaddr holds the virtual address of the linear p2m list. All entries
+     * in the range [0...max_pfn[ are accessible via this pointer.
+     * p2m_generation will be incremented by the guest before and after each
+     * change of the mappings of the p2m list. p2m_generation starts at 0 and
+     * a value with the least significant bit set indicates that a mapping
+     * update is in progress. This allows guest external software (e.g. in Dom0)
+     * to verify that read mappings are consistent and whether they have changed
+     * since the last check.
+     * Modifying a p2m element in the linear p2m list is allowed via an atomic
+     * write only.
+     */
+    unsigned long p2m_cr3;         /* cr3 value of the p2m address space */
+    unsigned long p2m_vaddr;       /* virtual address of the p2m list */
+    unsigned long p2m_generation;  /* generation count of p2m mapping */
 };
 typedef struct arch_shared_info arch_shared_info_t;
 
-- 
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 Dec 05 09:35:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpIm-00063C-7d; Fri, 05 Dec 2014 09:35:52 +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 1XwpIk-00062t-JI
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:35:50 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	08/A8-02699-57C71845; Fri, 05 Dec 2014 09:35:49 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417772148!9851695!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 19056 invoked from network); 5 Dec 2014 09:35:49 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 09:35:49 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A9B79AC24;
	Fri,  5 Dec 2014 09:35:48 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: keir@xen.org, Ian.Campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, jbeulich@suse.com
Date: Fri,  5 Dec 2014 10:35:44 +0100
Message-Id: <1417772144-24268-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1417772144-24268-1-git-send-email-jgross@suse.com>
References: <1417772144-24268-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [Patch V3] 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 an additional
virtual mapped p2m list.

This patch expands struct arch_shared_info with a new p2m list virtual
address, the root of the page table root and a p2m generation count.
The new information is indicated by the domain to be valid by storing
a non-zero value into the page table root member.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/include/public/arch-x86/xen.h | 36 +++++++++++++++++++++++++++++++++---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index f35804b..c5e880b 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -220,11 +220,41 @@ typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 
 struct arch_shared_info {
-    unsigned long max_pfn;                  /* max pfn that appears in table */
-    /* Frame containing list of mfns containing list of mfns containing p2m. */
+    /*
+     * Number of valid entries in the p2m table(s) anchored at
+     * pfn_to_mfn_frame_list_list and/or p2m_vaddr.
+     */
+    unsigned long max_pfn;
+    /*
+     * Frame containing list of mfns containing list of mfns containing p2m.
+     * A value of 0 indicates it has not yet been set up, ~0 indicates it has
+     * been set to invalid e.g. due to the p2m being too large for the 3-level
+     * p2m tree. In this case the linear mapper p2m list anchored at p2m_vaddr
+     * is to be used.
+     */
     xen_pfn_t     pfn_to_mfn_frame_list_list;
     unsigned long nmi_reason;
-    uint64_t pad[32];
+    /*
+     * Following three fields are valid if p2m_cr3 contains a value different
+     * from 0.
+     * p2m_cr3 is the root of the address space where p2m_vaddr is valid.
+     * p2m_cr3 is in the same format as a cr3 value in the vcpu register state
+     * and holds the folded machine frame number (via xen_pfn_to_cr3) of a
+     * L3 or L4 page table.
+     * p2m_vaddr holds the virtual address of the linear p2m list. All entries
+     * in the range [0...max_pfn[ are accessible via this pointer.
+     * p2m_generation will be incremented by the guest before and after each
+     * change of the mappings of the p2m list. p2m_generation starts at 0 and
+     * a value with the least significant bit set indicates that a mapping
+     * update is in progress. This allows guest external software (e.g. in Dom0)
+     * to verify that read mappings are consistent and whether they have changed
+     * since the last check.
+     * Modifying a p2m element in the linear p2m list is allowed via an atomic
+     * write only.
+     */
+    unsigned long p2m_cr3;         /* cr3 value of the p2m address space */
+    unsigned long p2m_vaddr;       /* virtual address of the p2m list */
+    unsigned long p2m_generation;  /* generation count of p2m mapping */
 };
 typedef struct arch_shared_info arch_shared_info_t;
 
-- 
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 Dec 05 09:42:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:42:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpOz-0006RF-18; Fri, 05 Dec 2014 09:42: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 1XwpOx-0006RA-KJ
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 09:42:15 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	5C/BB-14727-6FD71845; Fri, 05 Dec 2014 09:42:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417772532!11716618!1
X-Originating-IP: [66.165.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 16633 invoked from network); 5 Dec 2014 09:42:13 -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 Dec 2014 09:42:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200630644"
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, 5 Dec 2014 04:42: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 1XwpOt-0005YM-4j;
	Fri, 05 Dec 2014 09:42:11 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwpOs-000549-TN;
	Fri, 05 Dec 2014 09:42:10 +0000
Date: Fri, 5 Dec 2014 09:42:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32086-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] 32086: 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 32086 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32086/

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):
 build-i386-rumpuserxen        3 host-install(3)        broken blocked in 26303
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail like 26261
 test-amd64-amd64-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-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           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-qemut-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-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                                       broken  
 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                             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 build-i386-rumpuserxen 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 Dec 05 09:42:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:42:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpOz-0006RF-18; Fri, 05 Dec 2014 09:42: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 1XwpOx-0006RA-KJ
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 09:42:15 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	5C/BB-14727-6FD71845; Fri, 05 Dec 2014 09:42:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417772532!11716618!1
X-Originating-IP: [66.165.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 16633 invoked from network); 5 Dec 2014 09:42:13 -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 Dec 2014 09:42:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200630644"
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, 5 Dec 2014 04:42: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 1XwpOt-0005YM-4j;
	Fri, 05 Dec 2014 09:42:11 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwpOs-000549-TN;
	Fri, 05 Dec 2014 09:42:10 +0000
Date: Fri, 5 Dec 2014 09:42:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32086-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] 32086: 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 32086 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32086/

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):
 build-i386-rumpuserxen        3 host-install(3)        broken blocked in 26303
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail like 26261
 test-amd64-amd64-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-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           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-qemut-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-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                                       broken  
 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                             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 build-i386-rumpuserxen 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 Dec 05 09:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpPI-0006U4-E0; Fri, 05 Dec 2014 09:42:36 +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 1XwpPG-0006Tp-V3
	for Xen-devel@lists.xen.org; Fri, 05 Dec 2014 09:42:35 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	E6/06-02954-A0E71845; Fri, 05 Dec 2014 09:42:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417772553!13206275!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 32456 invoked from network); 5 Dec 2014 09:42:33 -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; 5 Dec 2014 09:42:33 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwpOz-0006g6-98; Fri, 05 Dec 2014 09:42:17 +0000
Date: Fri, 5 Dec 2014 10:42:17 +0100
From: Tim Deegan <tim@xen.org>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Message-ID: <20141205094217.GA25082@deinos.phlegethon.org>
References: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417698806-26807-3-git-send-email-yu.c.zhang@linux.intel.com>
	<20141204160445.GD43116@deinos.phlegethon.org>
	<548111CC.1070300@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548111CC.1070300@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, JBeulich@suse.com,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v5 2/2] add a new p2m type -
	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

Hi,

At 10:00 +0800 on 05 Dec (1417770044), Yu, Zhang wrote:
> >> @@ -5978,7 +5982,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
> >>                   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 )
> >
> > I think that Jan already brough this up, and maybe I missed your
> > answer: this realaxation looks wrong to me. I would have thought that
> > transition between p2m_mmio_write_dm and p2m_ram_rw/p2m_ram_logdirty
> > would be the only ones you would want to allow.
> 
> Ha. Sorry, my negligence, and thanks for pointing out. :)
> The transition we use now is only between p2m_mmio_write_dm and 
> p2m_ram_rw. So how about this:
> 
>      if ( !p2m_is_ram(t) &&
>           (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) &&
>           (t != p2m_mmio_write_dm || a.hvmmem_type != HVMMEM_ram_rw) )

Yes, I think that's right. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:42:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpPI-0006U4-E0; Fri, 05 Dec 2014 09:42:36 +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 1XwpPG-0006Tp-V3
	for Xen-devel@lists.xen.org; Fri, 05 Dec 2014 09:42:35 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	E6/06-02954-A0E71845; Fri, 05 Dec 2014 09:42:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417772553!13206275!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 32456 invoked from network); 5 Dec 2014 09:42:33 -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; 5 Dec 2014 09:42:33 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwpOz-0006g6-98; Fri, 05 Dec 2014 09:42:17 +0000
Date: Fri, 5 Dec 2014 10:42:17 +0100
From: Tim Deegan <tim@xen.org>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Message-ID: <20141205094217.GA25082@deinos.phlegethon.org>
References: <1417698806-26807-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417698806-26807-3-git-send-email-yu.c.zhang@linux.intel.com>
	<20141204160445.GD43116@deinos.phlegethon.org>
	<548111CC.1070300@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548111CC.1070300@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, JBeulich@suse.com,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v5 2/2] add a new p2m type -
	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

Hi,

At 10:00 +0800 on 05 Dec (1417770044), Yu, Zhang wrote:
> >> @@ -5978,7 +5982,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
> >>                   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 )
> >
> > I think that Jan already brough this up, and maybe I missed your
> > answer: this realaxation looks wrong to me. I would have thought that
> > transition between p2m_mmio_write_dm and p2m_ram_rw/p2m_ram_logdirty
> > would be the only ones you would want to allow.
> 
> Ha. Sorry, my negligence, and thanks for pointing out. :)
> The transition we use now is only between p2m_mmio_write_dm and 
> p2m_ram_rw. So how about this:
> 
>      if ( !p2m_is_ram(t) &&
>           (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) &&
>           (t != p2m_mmio_write_dm || a.hvmmem_type != HVMMEM_ram_rw) )

Yes, I think that's right. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:44:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:44:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpRX-0006m9-VM; Fri, 05 Dec 2014 09:44:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwpRW-0006ly-LE
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:44:54 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	36/21-14727-59E71845; Fri, 05 Dec 2014 09:44:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417772692!11707844!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20611 invoked from network); 5 Dec 2014 09:44:53 -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; 5 Dec 2014 09:44:53 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 09:44:52 +0000
Message-Id: <54818CA5020000780004D0B2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 09:44:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 03.12.14 at 17:04, <david.vrabel@citrix.com> wrote:
> The default limit for the number of PIRQs for hardware domains (dom0)
> is not sufficient for some (x86) systems.
> 
> Since the pirq structures are individually and dynamically allocated,
> the limit for hardware domains may be increased to the number of
> possible IRQs.

I nevertheless disagree to moving the bound up to the Xen internal
limit unconditionally: What use does it have to allow hwdom to use
thousands of MSIs? If a system got that many, the main purpose of
running Xen on it I would expect to be to hand various of the
respective devices to guests. Hence no need for hwdom to have
that many by default, even if this doesn't result in any extra
resource consumption.

That said, I can see the current default of 256 being too low though.
Quite likely in the absence of a user specified value the default
ought to be derived from nr_irqs - nr_static_irqs rather than being
any fixed number. Considering the default used for nr_irqs, I'd think
along the lines of sqrt(num_present_cpus()) * NR_DYNAMIC_VECTORS
or dom0->max_vcpus * NR_DYNAMIC_VECTORS (or the minimum of
the two) for x86.

Jan

> The extra_guest_irqs command line option now only allows changes to
> the domU value.  Any argument for dom0 is ignored.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  docs/misc/xen-command-line.markdown |   11 ++++-------
>  xen/common/domain.c                 |    7 +------
>  2 files changed, 5 insertions(+), 13 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 0866df2..d352031 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -594,15 +594,12 @@ except for debugging purposes.
>  Force or disable use of EFI runtime services.
>  
>  ### extra\_guest\_irqs
> -> `= [<domU number>][,<dom0 number>]`
> +> `= [<number>]`
>  
> -> Default: `32,256`
> +> Default: `32`
>  
> -Change the number of PIRQs available for guests.  The optional first number 
> is
> -common for all domUs, while the optional second number (preceded by a comma)
> -is for dom0.  Changing the setting for domU has no impact on dom0 and vice
> -versa.  For example to change dom0 without changing domU, use
> -`extra_guest_irqs=,512`
> +Change the number of PIRQs available for guests. This limit does not
> +apply to hardware domains (dom0).
>  
>  ### flask\_enabled
>  > `= <integer>`
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 4a62c1d..a88d829 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -231,14 +231,11 @@ static int late_hwdom_init(struct domain *d)
>  #endif
>  }
>  
> -static unsigned int __read_mostly extra_dom0_irqs = 256;
>  static unsigned int __read_mostly extra_domU_irqs = 32;
>  static void __init parse_extra_guest_irqs(const char *s)
>  {
>      if ( isdigit(*s) )
>          extra_domU_irqs = simple_strtoul(s, &s, 0);
> -    if ( *s == ',' && isdigit(*++s) )
> -        extra_dom0_irqs = simple_strtoul(s, &s, 0);
>  }
>  custom_param("extra_guest_irqs", parse_extra_guest_irqs);
>  
> @@ -324,10 +321,8 @@ struct domain *domain_create(
>          atomic_inc(&d->pause_count);
>  
>          if ( !is_hardware_domain(d) )
> -            d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
> +            d->nr_pirqs = min(nr_static_irqs + extra_domU_irqs, nr_irqs);
>          else
> -            d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
> -        if ( d->nr_pirqs > nr_irqs )
>              d->nr_pirqs = nr_irqs;
>  
>          radix_tree_init(&d->pirq_tree);
> -- 
> 1.7.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 Dec 05 09:44:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:44:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpRX-0006m9-VM; Fri, 05 Dec 2014 09:44:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwpRW-0006ly-LE
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:44:54 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	36/21-14727-59E71845; Fri, 05 Dec 2014 09:44:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417772692!11707844!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20611 invoked from network); 5 Dec 2014 09:44:53 -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; 5 Dec 2014 09:44:53 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 09:44:52 +0000
Message-Id: <54818CA5020000780004D0B2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 09:44:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 03.12.14 at 17:04, <david.vrabel@citrix.com> wrote:
> The default limit for the number of PIRQs for hardware domains (dom0)
> is not sufficient for some (x86) systems.
> 
> Since the pirq structures are individually and dynamically allocated,
> the limit for hardware domains may be increased to the number of
> possible IRQs.

I nevertheless disagree to moving the bound up to the Xen internal
limit unconditionally: What use does it have to allow hwdom to use
thousands of MSIs? If a system got that many, the main purpose of
running Xen on it I would expect to be to hand various of the
respective devices to guests. Hence no need for hwdom to have
that many by default, even if this doesn't result in any extra
resource consumption.

That said, I can see the current default of 256 being too low though.
Quite likely in the absence of a user specified value the default
ought to be derived from nr_irqs - nr_static_irqs rather than being
any fixed number. Considering the default used for nr_irqs, I'd think
along the lines of sqrt(num_present_cpus()) * NR_DYNAMIC_VECTORS
or dom0->max_vcpus * NR_DYNAMIC_VECTORS (or the minimum of
the two) for x86.

Jan

> The extra_guest_irqs command line option now only allows changes to
> the domU value.  Any argument for dom0 is ignored.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  docs/misc/xen-command-line.markdown |   11 ++++-------
>  xen/common/domain.c                 |    7 +------
>  2 files changed, 5 insertions(+), 13 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 0866df2..d352031 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -594,15 +594,12 @@ except for debugging purposes.
>  Force or disable use of EFI runtime services.
>  
>  ### extra\_guest\_irqs
> -> `= [<domU number>][,<dom0 number>]`
> +> `= [<number>]`
>  
> -> Default: `32,256`
> +> Default: `32`
>  
> -Change the number of PIRQs available for guests.  The optional first number 
> is
> -common for all domUs, while the optional second number (preceded by a comma)
> -is for dom0.  Changing the setting for domU has no impact on dom0 and vice
> -versa.  For example to change dom0 without changing domU, use
> -`extra_guest_irqs=,512`
> +Change the number of PIRQs available for guests. This limit does not
> +apply to hardware domains (dom0).
>  
>  ### flask\_enabled
>  > `= <integer>`
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 4a62c1d..a88d829 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -231,14 +231,11 @@ static int late_hwdom_init(struct domain *d)
>  #endif
>  }
>  
> -static unsigned int __read_mostly extra_dom0_irqs = 256;
>  static unsigned int __read_mostly extra_domU_irqs = 32;
>  static void __init parse_extra_guest_irqs(const char *s)
>  {
>      if ( isdigit(*s) )
>          extra_domU_irqs = simple_strtoul(s, &s, 0);
> -    if ( *s == ',' && isdigit(*++s) )
> -        extra_dom0_irqs = simple_strtoul(s, &s, 0);
>  }
>  custom_param("extra_guest_irqs", parse_extra_guest_irqs);
>  
> @@ -324,10 +321,8 @@ struct domain *domain_create(
>          atomic_inc(&d->pause_count);
>  
>          if ( !is_hardware_domain(d) )
> -            d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
> +            d->nr_pirqs = min(nr_static_irqs + extra_domU_irqs, nr_irqs);
>          else
> -            d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
> -        if ( d->nr_pirqs > nr_irqs )
>              d->nr_pirqs = nr_irqs;
>  
>          radix_tree_init(&d->pirq_tree);
> -- 
> 1.7.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 Dec 05 09:47:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpTg-0006xZ-LL; Fri, 05 Dec 2014 09:47: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 1XwpTe-0006xL-OE
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:47:06 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	E3/7F-23865-91F71845; Fri, 05 Dec 2014 09:47:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417772825!8843327!1
X-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 11992 invoked from network); 5 Dec 2014 09:47:05 -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; 5 Dec 2014 09:47:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 09:47:04 +0000
Message-Id: <54818D2A020000780004D0CA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 09:47:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<CAFECyb8WJwW=winKPNK6eWeEMRa+RNHa_vLwcmUJo3j1WTo3FQ@mail.gmail.com>
	<54816EC3020000780004CFF3@mail.emea.novell.com>
	<1417771988.22808.40.camel@citrix.com>
In-Reply-To: <1417771988.22808.40.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Roy Franz <roy.franz@linaro.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 10:33, <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-12-05 at 07:37 +0000, Jan Beulich wrote:
>> >>> On 04.12.14 at 22:22, <roy.franz@linaro.org> wrote:
>> > On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
>> >>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
>> >>>    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
>> >>>    code than definitions, declarations and short static
>> >>>    functions. So, I think that it is more regular *.c file
>> >>>    than header file.
>> >>
>> >> That's a matter of taste - I'd probably have made it .c too, but
>> >> didn't mind it being .h as done by Roy (presumably on the basis
>> >> that #include directives are preferred to have .h files as their
>> >> operands). The only thing I regret is that I didn't ask for the
>> >> pointless efi- prefix to be dropped.
>> > 
>> > I don't mind a change here, and I agree that it is more like a .c file
>> > than a .h.  If a name change is done, is it worth dropping the "efi-" at
>> > the same time?
>> 
>> If we indeed want to change the name (post 4.5), making both
>> adjustments at once would be kind of a requirement of mine.
> 
> Random thought: *.inc for .c files which happen to be embedded into
> another using #include?

That may conflict with certain editors' language detection, as .inc
may have other meanings (in the x86 Windows world I'd expect this
to be an assembler include file for example).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:47:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpTg-0006xZ-LL; Fri, 05 Dec 2014 09:47: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 1XwpTe-0006xL-OE
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:47:06 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	E3/7F-23865-91F71845; Fri, 05 Dec 2014 09:47:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417772825!8843327!1
X-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 11992 invoked from network); 5 Dec 2014 09:47:05 -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; 5 Dec 2014 09:47:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 09:47:04 +0000
Message-Id: <54818D2A020000780004D0CA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 09:47:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<CAFECyb8WJwW=winKPNK6eWeEMRa+RNHa_vLwcmUJo3j1WTo3FQ@mail.gmail.com>
	<54816EC3020000780004CFF3@mail.emea.novell.com>
	<1417771988.22808.40.camel@citrix.com>
In-Reply-To: <1417771988.22808.40.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Roy Franz <roy.franz@linaro.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 10:33, <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-12-05 at 07:37 +0000, Jan Beulich wrote:
>> >>> On 04.12.14 at 22:22, <roy.franz@linaro.org> wrote:
>> > On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
>> >>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
>> >>>    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
>> >>>    code than definitions, declarations and short static
>> >>>    functions. So, I think that it is more regular *.c file
>> >>>    than header file.
>> >>
>> >> That's a matter of taste - I'd probably have made it .c too, but
>> >> didn't mind it being .h as done by Roy (presumably on the basis
>> >> that #include directives are preferred to have .h files as their
>> >> operands). The only thing I regret is that I didn't ask for the
>> >> pointless efi- prefix to be dropped.
>> > 
>> > I don't mind a change here, and I agree that it is more like a .c file
>> > than a .h.  If a name change is done, is it worth dropping the "efi-" at
>> > the same time?
>> 
>> If we indeed want to change the name (post 4.5), making both
>> adjustments at once would be kind of a requirement of mine.
> 
> Random thought: *.inc for .c files which happen to be embedded into
> another using #include?

That may conflict with certain editors' language detection, as .inc
may have other meanings (in the x86 Windows world I'd expect this
to be an assembler include file for example).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpVz-00075k-6d; Fri, 05 Dec 2014 09:49:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XwpVy-00075d-Bg
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:49:30 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	0E/87-27785-9AF71845; Fri, 05 Dec 2014 09:49:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417772968!13198161!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 24124 invoked from network); 5 Dec 2014 09:49:29 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 09:49:29 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwpVi-0006nj-Fw; Fri, 05 Dec 2014 09:49:14 +0000
Date: Fri, 5 Dec 2014 10:49:14 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205094914.GC25082@deinos.phlegethon.org>
References: <20141204172511.GF43116@deinos.phlegethon.org>
	<54818706020000780004D07D@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54818706020000780004D07D@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: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] PVH cleanups after 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

At 09:20 +0000 on 05 Dec (1417767654), Jan Beulich wrote:
> >>> On 04.12.14 at 18:25, <tim@xen.org> wrote:
> > Potential feature flags, based on whiteboard notes at the session.
> > Things that are 'Yes' in both columns might not need actual flags :)
> > 
> >                      'HVM'       'PVH'
> > 64bit hypercalls      Yes         Yes
> > 32bit hypercalls      Yes         No
> 
> Iiuc the lack of support of 32-bit hypercalls is simply because PVH
> guests aren't expected to use them as being always 64-bit right
> now. I.e. I can't really see why we couldn't just enable them once
> the 64-bit hypercall tables got combined, in which case we wouldn't
> need a feature flag here either.

Agreed -- I think the same will apply to a few other things, like shadow
pagetables and some of the other MM tricks.  

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpVz-00075k-6d; Fri, 05 Dec 2014 09:49:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XwpVy-00075d-Bg
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:49:30 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	0E/87-27785-9AF71845; Fri, 05 Dec 2014 09:49:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417772968!13198161!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 24124 invoked from network); 5 Dec 2014 09:49:29 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 09:49:29 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XwpVi-0006nj-Fw; Fri, 05 Dec 2014 09:49:14 +0000
Date: Fri, 5 Dec 2014 10:49:14 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205094914.GC25082@deinos.phlegethon.org>
References: <20141204172511.GF43116@deinos.phlegethon.org>
	<54818706020000780004D07D@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54818706020000780004D07D@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: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] PVH cleanups after 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

At 09:20 +0000 on 05 Dec (1417767654), Jan Beulich wrote:
> >>> On 04.12.14 at 18:25, <tim@xen.org> wrote:
> > Potential feature flags, based on whiteboard notes at the session.
> > Things that are 'Yes' in both columns might not need actual flags :)
> > 
> >                      'HVM'       'PVH'
> > 64bit hypercalls      Yes         Yes
> > 32bit hypercalls      Yes         No
> 
> Iiuc the lack of support of 32-bit hypercalls is simply because PVH
> guests aren't expected to use them as being always 64-bit right
> now. I.e. I can't really see why we couldn't just enable them once
> the 64-bit hypercall tables got combined, in which case we wouldn't
> need a feature flag here either.

Agreed -- I think the same will apply to a few other things, like shadow
pagetables and some of the other MM tricks.  

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:50:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpWW-00079G-Jj; Fri, 05 Dec 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 1XwpWU-000795-SQ
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 09:50:02 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	89/2D-25547-ACF71845; Fri, 05 Dec 2014 09:50:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417772999!11268593!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28682 invoked from network); 5 Dec 2014 09:50:01 -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 Dec 2014 09:50:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200633047"
Message-ID: <1417772967.22808.46.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <Ian.Jackson@eu.citrix.com>
Date: Fri, 5 Dec 2014 09:49:27 +0000
In-Reply-To: <osstest-32083-mainreport@xen.org>
References: <osstest-32083-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [libvirt test] 32083: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-04 at 18:24 +0000, xen.org wrote:
> flight 32083 libvirt real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32083/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32005
>  build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32005
>  build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32005

See
https://www.redhat.com/archives/libvir-list/2014-December/msg00082.html

I replied at:
https://www.redhat.com/archives/libvir-list/2014-December/msg00327.html

Not sure, but I think the answer will be for us to add libxml-xpath-perl
to the set of packages which we install in the build environment.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:50:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpWW-00079G-Jj; Fri, 05 Dec 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 1XwpWU-000795-SQ
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 09:50:02 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	89/2D-25547-ACF71845; Fri, 05 Dec 2014 09:50:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417772999!11268593!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28682 invoked from network); 5 Dec 2014 09:50:01 -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 Dec 2014 09:50:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200633047"
Message-ID: <1417772967.22808.46.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <Ian.Jackson@eu.citrix.com>
Date: Fri, 5 Dec 2014 09:49:27 +0000
In-Reply-To: <osstest-32083-mainreport@xen.org>
References: <osstest-32083-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [libvirt test] 32083: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-04 at 18:24 +0000, xen.org wrote:
> flight 32083 libvirt real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32083/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32005
>  build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32005
>  build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32005

See
https://www.redhat.com/archives/libvir-list/2014-December/msg00082.html

I replied at:
https://www.redhat.com/archives/libvir-list/2014-December/msg00327.html

Not sure, but I think the answer will be for us to add libxml-xpath-perl
to the set of packages which we install in the build environment.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:51:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpYJ-0007K9-4G; Fri, 05 Dec 2014 09:51:55 +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 1XwpYH-0007Jy-6o
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 09:51:53 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	44/3A-03145-83081845; Fri, 05 Dec 2014 09:51:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417773111!13107002!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8056 invoked from network); 5 Dec 2014 09:51:51 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 09:51:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417773111; l=1859;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=mTlycVc50XiitEZm9UKHbf/83zE=;
	b=UUGXA6cLqUFkT7f9L1NJJjS9wy8xVp84BYS64gotYuo8xXSAgjqMFsCXTZqYtB2PibR
	1zusNag/wooxSiFQI1m3/o12oPSnCnXEwE9QTU8s87LNXcggNGEugVKfdt6i31I3tQftF
	5H9YksqhQUkc2zFZK/JMZa7QYf+vhsNo+I8=
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.2 AUTH) with ESMTPSA id Z00f0aqB59plOsE
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 10:51:47 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 238B45015E; Fri,  5 Dec 2014 10:51:47 +0100 (CET)
Date: Fri, 5 Dec 2014 10:51:46 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141205095146.GA16843@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Ian Campbell <ian.campbell@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Wei Liu wrote:

> AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> incorrect, even in the event systemd library is available.  Use
> PKG_CHECK_MODULES instead.
> 
> Tested on Debian Jessie and Arch Linux.

I just tested this and got this failure. The reason is that the LDFLAGS come
before the objects. If I move LDFLAGS after $^ linking works. Will send a patch
to fix the failure.

Olaf

make[3]: Entering directory '/work/olaf/factory/github/olafhering/xen.git/tools/xenstore'
gcc    -Wl,-rpath,/opt/xen/upstream/staging-honor_prefix/lib64 -lsystemd  xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o xenstored_posix.o /work/olaf/factory/github/olafhering/xen.git/tools/xenstore/../../tools/libxc/libxenctrl.so  -o xenstored
xenstored_core.o: In function `xs_validate_active_socket':
xenstored_core.c:(.text.unlikely+0x38): undefined reference to `sd_notifyf'
xenstored_core.c:(.text.unlikely+0x59): undefined reference to `sd_is_socket_unix'
xenstored_core.c:(.text.unlikely+0x77): undefined reference to `sd_is_socket_unix'
xenstored_core.o: In function `main':
xenstored_core.c:(.text.startup+0x1df): undefined reference to `sd_booted'
xenstored_core.c:(.text.startup+0x23c): undefined reference to `sd_booted'
xenstored_core.c:(.text.startup+0x25b): undefined reference to `sd_listen_fds'
xenstored_core.c:(.text.startup+0x563): undefined reference to `sd_booted'
xenstored_core.c:(.text.startup+0x8f9): undefined reference to `sd_notifyf'
xenstored_core.c:(.text.startup+0x958): undefined reference to `sd_notifyf'
xenstored_core.c:(.text.startup+0xb0d): undefined reference to `sd_notify'
collect2: error: ld returned 1 exit status
Makefile:80: recipe for target 'xenstored' failed
make[3]: *** [xenstored] Error 1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:51:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpYJ-0007K9-4G; Fri, 05 Dec 2014 09:51:55 +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 1XwpYH-0007Jy-6o
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 09:51:53 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	44/3A-03145-83081845; Fri, 05 Dec 2014 09:51:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417773111!13107002!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8056 invoked from network); 5 Dec 2014 09:51:51 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 09:51:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417773111; l=1859;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=mTlycVc50XiitEZm9UKHbf/83zE=;
	b=UUGXA6cLqUFkT7f9L1NJJjS9wy8xVp84BYS64gotYuo8xXSAgjqMFsCXTZqYtB2PibR
	1zusNag/wooxSiFQI1m3/o12oPSnCnXEwE9QTU8s87LNXcggNGEugVKfdt6i31I3tQftF
	5H9YksqhQUkc2zFZK/JMZa7QYf+vhsNo+I8=
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.2 AUTH) with ESMTPSA id Z00f0aqB59plOsE
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 10:51:47 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 238B45015E; Fri,  5 Dec 2014 10:51:47 +0100 (CET)
Date: Fri, 5 Dec 2014 10:51:46 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141205095146.GA16843@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Ian Campbell <ian.campbell@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Wei Liu wrote:

> AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> incorrect, even in the event systemd library is available.  Use
> PKG_CHECK_MODULES instead.
> 
> Tested on Debian Jessie and Arch Linux.

I just tested this and got this failure. The reason is that the LDFLAGS come
before the objects. If I move LDFLAGS after $^ linking works. Will send a patch
to fix the failure.

Olaf

make[3]: Entering directory '/work/olaf/factory/github/olafhering/xen.git/tools/xenstore'
gcc    -Wl,-rpath,/opt/xen/upstream/staging-honor_prefix/lib64 -lsystemd  xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o xenstored_posix.o /work/olaf/factory/github/olafhering/xen.git/tools/xenstore/../../tools/libxc/libxenctrl.so  -o xenstored
xenstored_core.o: In function `xs_validate_active_socket':
xenstored_core.c:(.text.unlikely+0x38): undefined reference to `sd_notifyf'
xenstored_core.c:(.text.unlikely+0x59): undefined reference to `sd_is_socket_unix'
xenstored_core.c:(.text.unlikely+0x77): undefined reference to `sd_is_socket_unix'
xenstored_core.o: In function `main':
xenstored_core.c:(.text.startup+0x1df): undefined reference to `sd_booted'
xenstored_core.c:(.text.startup+0x23c): undefined reference to `sd_booted'
xenstored_core.c:(.text.startup+0x25b): undefined reference to `sd_listen_fds'
xenstored_core.c:(.text.startup+0x563): undefined reference to `sd_booted'
xenstored_core.c:(.text.startup+0x8f9): undefined reference to `sd_notifyf'
xenstored_core.c:(.text.startup+0x958): undefined reference to `sd_notifyf'
xenstored_core.c:(.text.startup+0xb0d): undefined reference to `sd_notify'
collect2: error: ld returned 1 exit status
Makefile:80: recipe for target 'xenstored' failed
make[3]: *** [xenstored] Error 1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:52:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpYl-0007QV-HK; Fri, 05 Dec 2014 09:52:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwpYk-0007QK-R0
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:52:22 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	70/FA-15461-65081845; Fri, 05 Dec 2014 09:52:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417773140!10188562!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 7644 invoked from network); 5 Dec 2014 09:52:21 -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;
	5 Dec 2014 09:52:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200633762"
Message-ID: <1417773128.22808.48.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 5 Dec 2014 09:52:08 +0000
In-Reply-To: <54818D2A020000780004D0CA@mail.emea.novell.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<CAFECyb8WJwW=winKPNK6eWeEMRa+RNHa_vLwcmUJo3j1WTo3FQ@mail.gmail.com>
	<54816EC3020000780004CFF3@mail.emea.novell.com>
	<1417771988.22808.40.camel@citrix.com>
	<54818D2A020000780004D0CA@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: keir <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Roy Franz <roy.franz@linaro.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-05 at 09:47 +0000, Jan Beulich wrote:
> >>> On 05.12.14 at 10:33, <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2014-12-05 at 07:37 +0000, Jan Beulich wrote:
> >> >>> On 04.12.14 at 22:22, <roy.franz@linaro.org> wrote:
> >> > On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> >>>>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
> >> >>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
> >> >>>    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
> >> >>>    code than definitions, declarations and short static
> >> >>>    functions. So, I think that it is more regular *.c file
> >> >>>    than header file.
> >> >>
> >> >> That's a matter of taste - I'd probably have made it .c too, but
> >> >> didn't mind it being .h as done by Roy (presumably on the basis
> >> >> that #include directives are preferred to have .h files as their
> >> >> operands). The only thing I regret is that I didn't ask for the
> >> >> pointless efi- prefix to be dropped.
> >> > 
> >> > I don't mind a change here, and I agree that it is more like a .c file
> >> > than a .h.  If a name change is done, is it worth dropping the "efi-" at
> >> > the same time?
> >> 
> >> If we indeed want to change the name (post 4.5), making both
> >> adjustments at once would be kind of a requirement of mine.
> > 
> > Random thought: *.inc for .c files which happen to be embedded into
> > another using #include?
> 
> That may conflict with certain editors' language detection, as .inc
> may have other meanings (in the x86 Windows world I'd expect this
> to be an assembler include file for example).

Oh, so does my emacs apparently (a leftover .emacs snippet from a
previous life...). Nevermind that suggestion then.

The existing comment at the top of the included files is probably
sufficient.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:52:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpYl-0007QV-HK; Fri, 05 Dec 2014 09:52:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwpYk-0007QK-R0
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:52:22 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	70/FA-15461-65081845; Fri, 05 Dec 2014 09:52:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417773140!10188562!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 7644 invoked from network); 5 Dec 2014 09:52:21 -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;
	5 Dec 2014 09:52:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200633762"
Message-ID: <1417773128.22808.48.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 5 Dec 2014 09:52:08 +0000
In-Reply-To: <54818D2A020000780004D0CA@mail.emea.novell.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<CAFECyb8WJwW=winKPNK6eWeEMRa+RNHa_vLwcmUJo3j1WTo3FQ@mail.gmail.com>
	<54816EC3020000780004CFF3@mail.emea.novell.com>
	<1417771988.22808.40.camel@citrix.com>
	<54818D2A020000780004D0CA@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: keir <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Roy Franz <roy.franz@linaro.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-05 at 09:47 +0000, Jan Beulich wrote:
> >>> On 05.12.14 at 10:33, <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2014-12-05 at 07:37 +0000, Jan Beulich wrote:
> >> >>> On 04.12.14 at 22:22, <roy.franz@linaro.org> wrote:
> >> > On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> >>>>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
> >> >>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
> >> >>>    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
> >> >>>    code than definitions, declarations and short static
> >> >>>    functions. So, I think that it is more regular *.c file
> >> >>>    than header file.
> >> >>
> >> >> That's a matter of taste - I'd probably have made it .c too, but
> >> >> didn't mind it being .h as done by Roy (presumably on the basis
> >> >> that #include directives are preferred to have .h files as their
> >> >> operands). The only thing I regret is that I didn't ask for the
> >> >> pointless efi- prefix to be dropped.
> >> > 
> >> > I don't mind a change here, and I agree that it is more like a .c file
> >> > than a .h.  If a name change is done, is it worth dropping the "efi-" at
> >> > the same time?
> >> 
> >> If we indeed want to change the name (post 4.5), making both
> >> adjustments at once would be kind of a requirement of mine.
> > 
> > Random thought: *.inc for .c files which happen to be embedded into
> > another using #include?
> 
> That may conflict with certain editors' language detection, as .inc
> may have other meanings (in the x86 Windows world I'd expect this
> to be an assembler include file for example).

Oh, so does my emacs apparently (a leftover .emacs snippet from a
previous life...). Nevermind that suggestion then.

The existing comment at the top of the included files is probably
sufficient.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:55:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpbR-0007rP-3G; Fri, 05 Dec 2014 09:55:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwpbP-0007rB-Ml
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:55:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	84/B5-25276-BF081845; Fri, 05 Dec 2014 09:55:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417773305!10189347!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 830 invoked from network); 5 Dec 2014 09:55:06 -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;
	5 Dec 2014 09:55:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200634300"
Message-ID: <1417773296.22808.50.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 5 Dec 2014 09:54:56 +0000
In-Reply-To: <20141205094914.GC25082@deinos.phlegethon.org>
References: <20141204172511.GF43116@deinos.phlegethon.org>
	<54818706020000780004D07D@mail.emea.novell.com>
	<20141205094914.GC25082@deinos.phlegethon.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, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] PVH cleanups after 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 Fri, 2014-12-05 at 10:49 +0100, Tim Deegan wrote:
> At 09:20 +0000 on 05 Dec (1417767654), Jan Beulich wrote:
> > >>> On 04.12.14 at 18:25, <tim@xen.org> wrote:
> > > Potential feature flags, based on whiteboard notes at the session.
> > > Things that are 'Yes' in both columns might not need actual flags :)
> > > 
> > >                      'HVM'       'PVH'
> > > 64bit hypercalls      Yes         Yes
> > > 32bit hypercalls      Yes         No
> > 
> > Iiuc the lack of support of 32-bit hypercalls is simply because PVH
> > guests aren't expected to use them as being always 64-bit right
> > now. I.e. I can't really see why we couldn't just enable them once
> > the 64-bit hypercall tables got combined, in which case we wouldn't
> > need a feature flag here either.
> 
> Agreed -- I think the same will apply to a few other things, like shadow
> pagetables and some of the other MM tricks.  

Might we want to constrain a given PVH domain to only make 32- or 64-bit
hypercalls?

Or do we consider already having crossed that bridge with HVM enough
reason to allow it for PVH? I'm wonder if that, even if it is
technically possible to support not, doing so might mitigate some
potential security issues down the line. There's obviously a tradeoff
against in-guest flexibility though.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:55:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09: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 1XwpbR-0007rP-3G; Fri, 05 Dec 2014 09:55:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwpbP-0007rB-Ml
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 09:55:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	84/B5-25276-BF081845; Fri, 05 Dec 2014 09:55:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417773305!10189347!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 830 invoked from network); 5 Dec 2014 09:55:06 -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;
	5 Dec 2014 09:55:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200634300"
Message-ID: <1417773296.22808.50.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 5 Dec 2014 09:54:56 +0000
In-Reply-To: <20141205094914.GC25082@deinos.phlegethon.org>
References: <20141204172511.GF43116@deinos.phlegethon.org>
	<54818706020000780004D07D@mail.emea.novell.com>
	<20141205094914.GC25082@deinos.phlegethon.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, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] PVH cleanups after 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 Fri, 2014-12-05 at 10:49 +0100, Tim Deegan wrote:
> At 09:20 +0000 on 05 Dec (1417767654), Jan Beulich wrote:
> > >>> On 04.12.14 at 18:25, <tim@xen.org> wrote:
> > > Potential feature flags, based on whiteboard notes at the session.
> > > Things that are 'Yes' in both columns might not need actual flags :)
> > > 
> > >                      'HVM'       'PVH'
> > > 64bit hypercalls      Yes         Yes
> > > 32bit hypercalls      Yes         No
> > 
> > Iiuc the lack of support of 32-bit hypercalls is simply because PVH
> > guests aren't expected to use them as being always 64-bit right
> > now. I.e. I can't really see why we couldn't just enable them once
> > the 64-bit hypercall tables got combined, in which case we wouldn't
> > need a feature flag here either.
> 
> Agreed -- I think the same will apply to a few other things, like shadow
> pagetables and some of the other MM tricks.  

Might we want to constrain a given PVH domain to only make 32- or 64-bit
hypercalls?

Or do we consider already having crossed that bridge with HVM enough
reason to allow it for PVH? I'm wonder if that, even if it is
technically possible to support not, doing so might mitigate some
potential security issues down the line. There's obviously a tradeoff
against in-guest flexibility though.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:59:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwpg3-00080N-Q1; Fri, 05 Dec 2014 09:59:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xwpg1-00080I-Pq
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 09:59:53 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	B1/01-01660-91281845; Fri, 05 Dec 2014 09:59:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417773591!11721085!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 5079 invoked from network); 5 Dec 2014 09:59:52 -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 Dec 2014 09:59:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200266742"
Message-ID: <1417773588.22808.52.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 5 Dec 2014 09:59:48 +0000
In-Reply-To: <20141205095146.GA16843@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141205095146.GA16843@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>, Ian
	Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 10:51 +0100, Olaf Hering wrote:
> On Tue, Dec 02, Wei Liu wrote:
> 
> > AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> > incorrect, even in the event systemd library is available.  Use
> > PKG_CHECK_MODULES instead.
> > 
> > Tested on Debian Jessie and Arch Linux.
> 
> I just tested this and got this failure. The reason is that the LDFLAGS come
> before the objects. If I move LDFLAGS after $^ linking works. Will send a patch
> to fix the failure.

Was this a new failure with this change? AFAICT LDFLAGS is still set
(via SYSTEMD_LIBS) in the same place relative to non-systemd stuff.

FWIW the reason I don't see this in my pre-commit test is that I don't
have the systemd headers installed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 09:59:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 09:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwpg3-00080N-Q1; Fri, 05 Dec 2014 09:59:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xwpg1-00080I-Pq
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 09:59:53 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	B1/01-01660-91281845; Fri, 05 Dec 2014 09:59:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417773591!11721085!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 5079 invoked from network); 5 Dec 2014 09:59:52 -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 Dec 2014 09:59:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200266742"
Message-ID: <1417773588.22808.52.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 5 Dec 2014 09:59:48 +0000
In-Reply-To: <20141205095146.GA16843@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141205095146.GA16843@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>, Ian
	Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 10:51 +0100, Olaf Hering wrote:
> On Tue, Dec 02, Wei Liu wrote:
> 
> > AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> > incorrect, even in the event systemd library is available.  Use
> > PKG_CHECK_MODULES instead.
> > 
> > Tested on Debian Jessie and Arch Linux.
> 
> I just tested this and got this failure. The reason is that the LDFLAGS come
> before the objects. If I move LDFLAGS after $^ linking works. Will send a patch
> to fix the failure.

Was this a new failure with this change? AFAICT LDFLAGS is still set
(via SYSTEMD_LIBS) in the same place relative to non-systemd stuff.

FWIW the reason I don't see this in my pre-commit test is that I don't
have the systemd headers installed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:00:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:00:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpgT-00087U-6F; Fri, 05 Dec 2014 10:00:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bob.liu@oracle.com>) id 1XwpgQ-000878-VA
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:00:19 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	1E/B8-03145-23281845; Fri, 05 Dec 2014 10:00:18 +0000
X-Env-Sender: bob.liu@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417773615!13211438!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5052 invoked from network); 5 Dec 2014 10:00:17 -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; 5 Dec 2014 10:00:17 -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 sB5A09EU013698
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 10:00: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
	sB5A09cE003669
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 10:00:09 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
	sB5A08Rh010412; Fri, 5 Dec 2014 10:00:08 GMT
Received: from [192.168.3.8] (/218.82.189.246)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 02:00:08 -0800
Message-ID: <54818221.1070804@oracle.com>
Date: Fri, 05 Dec 2014 18:00:01 +0800
From: Bob Liu <bob.liu@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xenproject.org>
References: <546F1033.7030005@oracle.com>
In-Reply-To: <546F1033.7030005@oracle.com>
X-Forwarded-Message-Id: <546F1033.7030005@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.campbell@citrix.com, JBeulich@suse.com
Subject: [Xen-devel] A good way to speed up the xl destroy time(guest page
	scrubbing)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 folks,

In recent months I've been working on speed up the 'xl des' time of XEN
guest with large RAM, but there is still no good solution yet.

I'm looking forward to get more suggestions and appreciate for all of
your input.

(1) The problem
When 'xl destory' a guest with large memory, we have to wait a long
time(~10 minutes for a guest with 1TB memory). Most of the time was
spent on page scrubbing, every page need to get scrubbed before free to
the heap_list(the buddy system).

(2) The way I've tired
1. When free a page to the buddy system only mark it with an new flag
'need_scrub' instead of scrubbing, so 'xl des' can return quickly.

2. Use all idle cpus to do the real page scrubbing in parallel. In:
static void idle_loop(void)
{
	iterate the &heap_list and scrub any 'need_scrub' page.
}

3. Also in the alloc_heap_page() path, 'need_scrub' pages can be
allocated and scrubbed.(If 'need_scrub' pages are skipped, 'xl create'
new guest may fail when the system is busy since no idle cpus can finish
the scrubbing.)

4. Problem of this way: Lock contention
The &heap_list is protected by heap_lock which is a spinlock.
alloc/free path may modify the heap list any time with heap_lock hold.

The idle_loop() need to iterate the heap list for every page scrubbing
(won't modify the list but will scrub page content), there is heavy lock
contention and slow down the alloc/free path.

5. Potential workaround
5.1 Use per-cpu list in idle_loop()
Delist a batch of pages from heap_list to a per-cpu list, then scrub the
per-cpu list and free back to heap_list.

But Jan disagree with this solution:
"You should really drop the idea of removing pages temporarily.
All you need to do is make sure a page being allocated and getting
simultaneously scrubbed by another CPU won't get passed to the
caller until the scrubbing finished."

Another reason was it's hard to say how many pages should be delisted to
per-cpu list.

5.2 Use more page flags
Konrad suggested to use more page flags and consider the 'cmpxchg'
instruction instead of spinlock for idle_loop() to iterate the &heap_list.
But 'cmpxchg' is only suitable to protect the content of every single
page, it's difficult to protect kinds of race conditions against a list.

(3) Other solutions for speed up page scrubbing
1. George suggested:
* Have a "clean" freelist and a "dirty" freelist
* When destroying a domain, simply move pages to the dirty freelist
* Have idle vcpus scrub the dirty freelist before going to sleep
 - ...

* In alloc_domheap_pages():
 - If there are pages on the "clean" freelist, allocate them
 - If there are no pages on the "clean" freelist but there are on the
"dirty" freelist, scrub pages from the "dirty" freelist synchronously.

But the lock contention is still a problem and may worse with two lists.

2. Delay page scrubbing to the page fault path
Which means a 'need_scrub' page won't be scrubbed until setting up the
page table mapping in page fault path. This is a populate way under linux.
But konrad mentioned this way was not suitable for Windows guest,
because Windows will access every page during boot up, the boot time of
windows might be slowed down.

Welcome any better ideas and thanks again for your patient to read this
long email.

-- 
Regards,
-Bob

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:00:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:00:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwpgT-00087U-6F; Fri, 05 Dec 2014 10:00:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bob.liu@oracle.com>) id 1XwpgQ-000878-VA
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:00:19 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	1E/B8-03145-23281845; Fri, 05 Dec 2014 10:00:18 +0000
X-Env-Sender: bob.liu@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417773615!13211438!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5052 invoked from network); 5 Dec 2014 10:00:17 -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; 5 Dec 2014 10:00:17 -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 sB5A09EU013698
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 10:00: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
	sB5A09cE003669
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 10:00:09 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
	sB5A08Rh010412; Fri, 5 Dec 2014 10:00:08 GMT
Received: from [192.168.3.8] (/218.82.189.246)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 02:00:08 -0800
Message-ID: <54818221.1070804@oracle.com>
Date: Fri, 05 Dec 2014 18:00:01 +0800
From: Bob Liu <bob.liu@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xenproject.org>
References: <546F1033.7030005@oracle.com>
In-Reply-To: <546F1033.7030005@oracle.com>
X-Forwarded-Message-Id: <546F1033.7030005@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.campbell@citrix.com, JBeulich@suse.com
Subject: [Xen-devel] A good way to speed up the xl destroy time(guest page
	scrubbing)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 folks,

In recent months I've been working on speed up the 'xl des' time of XEN
guest with large RAM, but there is still no good solution yet.

I'm looking forward to get more suggestions and appreciate for all of
your input.

(1) The problem
When 'xl destory' a guest with large memory, we have to wait a long
time(~10 minutes for a guest with 1TB memory). Most of the time was
spent on page scrubbing, every page need to get scrubbed before free to
the heap_list(the buddy system).

(2) The way I've tired
1. When free a page to the buddy system only mark it with an new flag
'need_scrub' instead of scrubbing, so 'xl des' can return quickly.

2. Use all idle cpus to do the real page scrubbing in parallel. In:
static void idle_loop(void)
{
	iterate the &heap_list and scrub any 'need_scrub' page.
}

3. Also in the alloc_heap_page() path, 'need_scrub' pages can be
allocated and scrubbed.(If 'need_scrub' pages are skipped, 'xl create'
new guest may fail when the system is busy since no idle cpus can finish
the scrubbing.)

4. Problem of this way: Lock contention
The &heap_list is protected by heap_lock which is a spinlock.
alloc/free path may modify the heap list any time with heap_lock hold.

The idle_loop() need to iterate the heap list for every page scrubbing
(won't modify the list but will scrub page content), there is heavy lock
contention and slow down the alloc/free path.

5. Potential workaround
5.1 Use per-cpu list in idle_loop()
Delist a batch of pages from heap_list to a per-cpu list, then scrub the
per-cpu list and free back to heap_list.

But Jan disagree with this solution:
"You should really drop the idea of removing pages temporarily.
All you need to do is make sure a page being allocated and getting
simultaneously scrubbed by another CPU won't get passed to the
caller until the scrubbing finished."

Another reason was it's hard to say how many pages should be delisted to
per-cpu list.

5.2 Use more page flags
Konrad suggested to use more page flags and consider the 'cmpxchg'
instruction instead of spinlock for idle_loop() to iterate the &heap_list.
But 'cmpxchg' is only suitable to protect the content of every single
page, it's difficult to protect kinds of race conditions against a list.

(3) Other solutions for speed up page scrubbing
1. George suggested:
* Have a "clean" freelist and a "dirty" freelist
* When destroying a domain, simply move pages to the dirty freelist
* Have idle vcpus scrub the dirty freelist before going to sleep
 - ...

* In alloc_domheap_pages():
 - If there are pages on the "clean" freelist, allocate them
 - If there are no pages on the "clean" freelist but there are on the
"dirty" freelist, scrub pages from the "dirty" freelist synchronously.

But the lock contention is still a problem and may worse with two lists.

2. Delay page scrubbing to the page fault path
Which means a 'need_scrub' page won't be scrubbed until setting up the
page table mapping in page fault path. This is a populate way under linux.
But konrad mentioned this way was not suitable for Windows guest,
because Windows will access every page during boot up, the boot time of
windows might be slowed down.

Welcome any better ideas and thanks again for your patient to read this
long email.

-- 
Regards,
-Bob

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:02:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:02:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwpik-0008Md-Ul; Fri, 05 Dec 2014 10:02:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xwpij-0008MM-0M
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 10:02:41 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	AB/95-17694-0C281845; Fri, 05 Dec 2014 10:02:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417773759!11299151!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5562 invoked from network); 5 Dec 2014 10:02:39 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 10:02:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417773759; l=1006;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=XhJTAtnnMVX6HZQnyfltrXJ7xm8=;
	b=yfNi3dv0sRpa6h1tM3vfPxUkGHX6N80hujvGrWY5DWHaX1RBHeS7NQhk+KQ94FLirOf
	vI3XtWGhizmI7R5ZeXVcTzL/KgOFn21M3dk4g4dugIZCRHhY5eEsLLxuRptX4LLRg3xE1
	Ke3+E+AhS8m2/wz+/pu8eTeNSItbh6j03zw=
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.2 AUTH) with ESMTPSA id Q02b07qB5A2aPZd
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 11:02:36 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A1A2F5015E; Fri,  5 Dec 2014 11:02:35 +0100 (CET)
Date: Fri, 5 Dec 2014 11:02:35 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141205100235.GA18455@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141205095146.GA16843@aepfle.de>
	<1417773588.22808.52.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417773588.22808.52.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Ian Campbell wrote:

> On Fri, 2014-12-05 at 10:51 +0100, Olaf Hering wrote:
> > On Tue, Dec 02, Wei Liu wrote:
> > 
> > > AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> > > incorrect, even in the event systemd library is available.  Use
> > > PKG_CHECK_MODULES instead.
> > > 
> > > Tested on Debian Jessie and Arch Linux.
> > 
> > I just tested this and got this failure. The reason is that the LDFLAGS come
> > before the objects. If I move LDFLAGS after $^ linking works. Will send a patch
> > to fix the failure.
> 
> Was this a new failure with this change? AFAICT LDFLAGS is still set
> (via SYSTEMD_LIBS) in the same place relative to non-systemd stuff.

No, happens even without it. I just realized that I missed a git rebase.
My own packages do not have systemd-devel yet, so I did not spot this
earlier. Maybe it just happens with the latest toolchain in Factory.
Last time it worked well in 13.1 at least, SLE12 was ok as well.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:02:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:02:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwpik-0008Md-Ul; Fri, 05 Dec 2014 10:02:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xwpij-0008MM-0M
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 10:02:41 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	AB/95-17694-0C281845; Fri, 05 Dec 2014 10:02:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417773759!11299151!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5562 invoked from network); 5 Dec 2014 10:02:39 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 10:02:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417773759; l=1006;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=XhJTAtnnMVX6HZQnyfltrXJ7xm8=;
	b=yfNi3dv0sRpa6h1tM3vfPxUkGHX6N80hujvGrWY5DWHaX1RBHeS7NQhk+KQ94FLirOf
	vI3XtWGhizmI7R5ZeXVcTzL/KgOFn21M3dk4g4dugIZCRHhY5eEsLLxuRptX4LLRg3xE1
	Ke3+E+AhS8m2/wz+/pu8eTeNSItbh6j03zw=
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.2 AUTH) with ESMTPSA id Q02b07qB5A2aPZd
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 11:02:36 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A1A2F5015E; Fri,  5 Dec 2014 11:02:35 +0100 (CET)
Date: Fri, 5 Dec 2014 11:02:35 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141205100235.GA18455@aepfle.de>
References: <1417533090-29651-1-git-send-email-wei.liu2@citrix.com>
	<20141205095146.GA16843@aepfle.de>
	<1417773588.22808.52.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417773588.22808.52.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.5] systemd: use pkg-config to
 determine systemd library availability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Ian Campbell wrote:

> On Fri, 2014-12-05 at 10:51 +0100, Olaf Hering wrote:
> > On Tue, Dec 02, Wei Liu wrote:
> > 
> > > AC_CHECK_LIB fails on Debian Jessie since the ld flag it generates is
> > > incorrect, even in the event systemd library is available.  Use
> > > PKG_CHECK_MODULES instead.
> > > 
> > > Tested on Debian Jessie and Arch Linux.
> > 
> > I just tested this and got this failure. The reason is that the LDFLAGS come
> > before the objects. If I move LDFLAGS after $^ linking works. Will send a patch
> > to fix the failure.
> 
> Was this a new failure with this change? AFAICT LDFLAGS is still set
> (via SYSTEMD_LIBS) in the same place relative to non-systemd stuff.

No, happens even without it. I just realized that I missed a git rebase.
My own packages do not have systemd-devel yet, so I did not spot this
earlier. Maybe it just happens with the latest toolchain in Factory.
Last time it worked well in 13.1 at least, SLE12 was ok as well.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:28:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1Xwq7Q-0000tS-3J; Fri, 05 Dec 2014 10:28:12 +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 1Xwq7P-0000tN-3r
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:28:11 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	96/B1-02576-9B881845; Fri, 05 Dec 2014 10:28:09 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417775288!13220986!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 11772 invoked from network); 5 Dec 2014 10:28:09 -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 Dec 2014 10:28:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200276518"
Message-ID: <548188B5.8010400@citrix.com>
Date: Fri, 5 Dec 2014 10:28:05 +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>, David Vrabel <david.vrabel@citrix.com>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
	<54818CA5020000780004D0B2@mail.emea.novell.com>
In-Reply-To: <54818CA5020000780004D0B2@mail.emea.novell.com>
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 05/12/14 09:44, Jan Beulich wrote:
>>>> On 03.12.14 at 17:04, <david.vrabel@citrix.com> wrote:
>> The default limit for the number of PIRQs for hardware domains (dom0)
>> is not sufficient for some (x86) systems.
>>
>> Since the pirq structures are individually and dynamically allocated,
>> the limit for hardware domains may be increased to the number of
>> possible IRQs.
> 
> I nevertheless disagree to moving the bound up to the Xen internal
> limit unconditionally: What use does it have to allow hwdom to use
> thousands of MSIs? If a system got that many, the main purpose of
> running Xen on it I would expect to be to hand various of the
> respective devices to guests. Hence no need for hwdom to have
> that many by default, even if this doesn't result in any extra
> resource consumption.
> 
> That said, I can see the current default of 256 being too low though.
> Quite likely in the absence of a user specified value the default
> ought to be derived from nr_irqs - nr_static_irqs rather than being
> any fixed number. Considering the default used for nr_irqs, I'd think
> along the lines of sqrt(num_present_cpus()) * NR_DYNAMIC_VECTORS
> or dom0->max_vcpus * NR_DYNAMIC_VECTORS (or the minimum of
> the two) for x86.

The reason for a non obvious default like this would need a comment and
I can't write one because I can't see a reason for it.  Perhaps if you
write a suitable comment for your preferred default I can respin this patch?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:28:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1Xwq7s-0000ui-Fy; Fri, 05 Dec 2014 10:28:40 +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 1Xwq7q-0000uZ-E3
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:28:38 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	B3/BB-02702-5D881845; Fri, 05 Dec 2014 10:28:37 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417775315!13117208!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 19040 invoked from network); 5 Dec 2014 10:28:37 -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;
	5 Dec 2014 10:28:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200276646"
Message-ID: <548188D1.9020004@citrix.com>
Date: Fri, 5 Dec 2014 10:28: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: Juergen Gross <jgross@suse.com>, <keir@xen.org>,
	<Ian.Campbell@citrix.com>, <ian.jackson@eu.citrix.com>, <tim@xen.org>, 
	<david.vrabel@citrix.com>, <xen-devel@lists.xenproject.org>,
	<jbeulich@suse.com>
References: <1417772144-24268-1-git-send-email-jgross@suse.com>
	<1417772144-24268-2-git-send-email-jgross@suse.com>
In-Reply-To: <1417772144-24268-2-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [Patch V3] 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 05/12/14 09:35, 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 an additional
> virtual mapped p2m list.
>
> This patch expands struct arch_shared_info with a new p2m list virtual
> address, the root of the page table root and a p2m generation count.
> The new information is indicated by the domain to be valid by storing
> a non-zero value into the page table root member.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Awesome - More documentation!

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  xen/include/public/arch-x86/xen.h | 36 +++++++++++++++++++++++++++++++++---
>  1 file changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
> index f35804b..c5e880b 100644
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -220,11 +220,41 @@ typedef struct vcpu_guest_context vcpu_guest_context_t;
>  DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
>  
>  struct arch_shared_info {
> -    unsigned long max_pfn;                  /* max pfn that appears in table */
> -    /* Frame containing list of mfns containing list of mfns containing p2m. */
> +    /*
> +     * Number of valid entries in the p2m table(s) anchored at
> +     * pfn_to_mfn_frame_list_list and/or p2m_vaddr.
> +     */
> +    unsigned long max_pfn;
> +    /*
> +     * Frame containing list of mfns containing list of mfns containing p2m.
> +     * A value of 0 indicates it has not yet been set up, ~0 indicates it has
> +     * been set to invalid e.g. due to the p2m being too large for the 3-level
> +     * p2m tree. In this case the linear mapper p2m list anchored at p2m_vaddr
> +     * is to be used.
> +     */
>      xen_pfn_t     pfn_to_mfn_frame_list_list;
>      unsigned long nmi_reason;
> -    uint64_t pad[32];
> +    /*
> +     * Following three fields are valid if p2m_cr3 contains a value different
> +     * from 0.
> +     * p2m_cr3 is the root of the address space where p2m_vaddr is valid.
> +     * p2m_cr3 is in the same format as a cr3 value in the vcpu register state
> +     * and holds the folded machine frame number (via xen_pfn_to_cr3) of a
> +     * L3 or L4 page table.
> +     * p2m_vaddr holds the virtual address of the linear p2m list. All entries
> +     * in the range [0...max_pfn[ are accessible via this pointer.
> +     * p2m_generation will be incremented by the guest before and after each
> +     * change of the mappings of the p2m list. p2m_generation starts at 0 and
> +     * a value with the least significant bit set indicates that a mapping
> +     * update is in progress. This allows guest external software (e.g. in Dom0)
> +     * to verify that read mappings are consistent and whether they have changed
> +     * since the last check.
> +     * Modifying a p2m element in the linear p2m list is allowed via an atomic
> +     * write only.
> +     */
> +    unsigned long p2m_cr3;         /* cr3 value of the p2m address space */
> +    unsigned long p2m_vaddr;       /* virtual address of the p2m list */
> +    unsigned long p2m_generation;  /* generation count of p2m mapping */
>  };
>  typedef struct arch_shared_info arch_shared_info_t;
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:28:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1Xwq7Q-0000tS-3J; Fri, 05 Dec 2014 10:28:12 +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 1Xwq7P-0000tN-3r
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:28:11 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	96/B1-02576-9B881845; Fri, 05 Dec 2014 10:28:09 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1417775288!13220986!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 11772 invoked from network); 5 Dec 2014 10:28:09 -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 Dec 2014 10:28:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200276518"
Message-ID: <548188B5.8010400@citrix.com>
Date: Fri, 5 Dec 2014 10:28:05 +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>, David Vrabel <david.vrabel@citrix.com>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
	<54818CA5020000780004D0B2@mail.emea.novell.com>
In-Reply-To: <54818CA5020000780004D0B2@mail.emea.novell.com>
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 05/12/14 09:44, Jan Beulich wrote:
>>>> On 03.12.14 at 17:04, <david.vrabel@citrix.com> wrote:
>> The default limit for the number of PIRQs for hardware domains (dom0)
>> is not sufficient for some (x86) systems.
>>
>> Since the pirq structures are individually and dynamically allocated,
>> the limit for hardware domains may be increased to the number of
>> possible IRQs.
> 
> I nevertheless disagree to moving the bound up to the Xen internal
> limit unconditionally: What use does it have to allow hwdom to use
> thousands of MSIs? If a system got that many, the main purpose of
> running Xen on it I would expect to be to hand various of the
> respective devices to guests. Hence no need for hwdom to have
> that many by default, even if this doesn't result in any extra
> resource consumption.
> 
> That said, I can see the current default of 256 being too low though.
> Quite likely in the absence of a user specified value the default
> ought to be derived from nr_irqs - nr_static_irqs rather than being
> any fixed number. Considering the default used for nr_irqs, I'd think
> along the lines of sqrt(num_present_cpus()) * NR_DYNAMIC_VECTORS
> or dom0->max_vcpus * NR_DYNAMIC_VECTORS (or the minimum of
> the two) for x86.

The reason for a non obvious default like this would need a comment and
I can't write one because I can't see a reason for it.  Perhaps if you
write a suitable comment for your preferred default I can respin this patch?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:28:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1Xwq7s-0000ui-Fy; Fri, 05 Dec 2014 10:28:40 +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 1Xwq7q-0000uZ-E3
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:28:38 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	B3/BB-02702-5D881845; Fri, 05 Dec 2014 10:28:37 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1417775315!13117208!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 19040 invoked from network); 5 Dec 2014 10:28:37 -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;
	5 Dec 2014 10:28:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200276646"
Message-ID: <548188D1.9020004@citrix.com>
Date: Fri, 5 Dec 2014 10:28: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: Juergen Gross <jgross@suse.com>, <keir@xen.org>,
	<Ian.Campbell@citrix.com>, <ian.jackson@eu.citrix.com>, <tim@xen.org>, 
	<david.vrabel@citrix.com>, <xen-devel@lists.xenproject.org>,
	<jbeulich@suse.com>
References: <1417772144-24268-1-git-send-email-jgross@suse.com>
	<1417772144-24268-2-git-send-email-jgross@suse.com>
In-Reply-To: <1417772144-24268-2-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [Patch V3] 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 05/12/14 09:35, 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 an additional
> virtual mapped p2m list.
>
> This patch expands struct arch_shared_info with a new p2m list virtual
> address, the root of the page table root and a p2m generation count.
> The new information is indicated by the domain to be valid by storing
> a non-zero value into the page table root member.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Awesome - More documentation!

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  xen/include/public/arch-x86/xen.h | 36 +++++++++++++++++++++++++++++++++---
>  1 file changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
> index f35804b..c5e880b 100644
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -220,11 +220,41 @@ typedef struct vcpu_guest_context vcpu_guest_context_t;
>  DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
>  
>  struct arch_shared_info {
> -    unsigned long max_pfn;                  /* max pfn that appears in table */
> -    /* Frame containing list of mfns containing list of mfns containing p2m. */
> +    /*
> +     * Number of valid entries in the p2m table(s) anchored at
> +     * pfn_to_mfn_frame_list_list and/or p2m_vaddr.
> +     */
> +    unsigned long max_pfn;
> +    /*
> +     * Frame containing list of mfns containing list of mfns containing p2m.
> +     * A value of 0 indicates it has not yet been set up, ~0 indicates it has
> +     * been set to invalid e.g. due to the p2m being too large for the 3-level
> +     * p2m tree. In this case the linear mapper p2m list anchored at p2m_vaddr
> +     * is to be used.
> +     */
>      xen_pfn_t     pfn_to_mfn_frame_list_list;
>      unsigned long nmi_reason;
> -    uint64_t pad[32];
> +    /*
> +     * Following three fields are valid if p2m_cr3 contains a value different
> +     * from 0.
> +     * p2m_cr3 is the root of the address space where p2m_vaddr is valid.
> +     * p2m_cr3 is in the same format as a cr3 value in the vcpu register state
> +     * and holds the folded machine frame number (via xen_pfn_to_cr3) of a
> +     * L3 or L4 page table.
> +     * p2m_vaddr holds the virtual address of the linear p2m list. All entries
> +     * in the range [0...max_pfn[ are accessible via this pointer.
> +     * p2m_generation will be incremented by the guest before and after each
> +     * change of the mappings of the p2m list. p2m_generation starts at 0 and
> +     * a value with the least significant bit set indicates that a mapping
> +     * update is in progress. This allows guest external software (e.g. in Dom0)
> +     * to verify that read mappings are consistent and whether they have changed
> +     * since the last check.
> +     * Modifying a p2m element in the linear p2m list is allowed via an atomic
> +     * write only.
> +     */
> +    unsigned long p2m_cr3;         /* cr3 value of the p2m address space */
> +    unsigned long p2m_vaddr;       /* virtual address of the p2m list */
> +    unsigned long p2m_generation;  /* generation count of p2m mapping */
>  };
>  typedef struct arch_shared_info arch_shared_info_t;
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:30:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1Xwq9M-00013J-VV; Fri, 05 Dec 2014 10:30:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xwq9M-00013E-ED
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:30:12 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	D6/54-17958-33981845; Fri, 05 Dec 2014 10:30:11 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417775409!11308147!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 10921 invoked from network); 5 Dec 2014 10:30:11 -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;
	5 Dec 2014 10:30:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200646006"
Message-ID: <54818929.5000008@citrix.com>
Date: Fri, 5 Dec 2014 10:30:01 +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: Alex Williamson <alex.williamson@redhat.com>, Sander Eikelenboom
	<linux@eikelenboom.it>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>	
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>	
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>	
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
	<1417707546.15750.100.camel@bling.home>
In-Reply-To: <1417707546.15750.100.camel@bling.home>
X-DLP: MIA1
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 15:39, Alex Williamson wrote:
> 
> I don't know what workaround you're talking about.  As devices are
> released from the user, vfio-pci attempts to reset them.  If
> pci_reset_function() returns success we mark the device clean, otherwise
> it gets marked dirty.  Each time a device is released, if there are
> dirty devices we test whether we can try a bus/slot reset to clean them.
> In the case of assigning a GPU this typically means that the GPU or
> audio function come through first, there's no reset mechanism so it gets
> marked dirty, the next device comes through and we manage to try a bus
> reset.  vfio-pci does not have any device specific resets, all
> functionality is added to the PCI-core, thank-you-very-much.  I even
> posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
> bad so that pci_reset_function() won't claim that worked.  All VGA
> access quirks are done in QEMU, the kernel doesn't have any business in
> remapping config space over MMIO regions or trapping other config space
> backdoors.

Thanks for the info Alex, I hadn't got around to actually looking and
the vfio-pci code and was just going to what Sander said.

We probably do need to have a more in depth look at now PCI devices and
handled by both the toolstack and pciback but in the short term I would
like a simple solution that does not extend the ABI.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:30:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1Xwq9M-00013J-VV; Fri, 05 Dec 2014 10:30:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xwq9M-00013E-ED
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:30:12 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	D6/54-17958-33981845; Fri, 05 Dec 2014 10:30:11 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417775409!11308147!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 10921 invoked from network); 5 Dec 2014 10:30:11 -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;
	5 Dec 2014 10:30:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200646006"
Message-ID: <54818929.5000008@citrix.com>
Date: Fri, 5 Dec 2014 10:30:01 +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: Alex Williamson <alex.williamson@redhat.com>, Sander Eikelenboom
	<linux@eikelenboom.it>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>	
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>	
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>	
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
	<1417707546.15750.100.camel@bling.home>
In-Reply-To: <1417707546.15750.100.camel@bling.home>
X-DLP: MIA1
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 15:39, Alex Williamson wrote:
> 
> I don't know what workaround you're talking about.  As devices are
> released from the user, vfio-pci attempts to reset them.  If
> pci_reset_function() returns success we mark the device clean, otherwise
> it gets marked dirty.  Each time a device is released, if there are
> dirty devices we test whether we can try a bus/slot reset to clean them.
> In the case of assigning a GPU this typically means that the GPU or
> audio function come through first, there's no reset mechanism so it gets
> marked dirty, the next device comes through and we manage to try a bus
> reset.  vfio-pci does not have any device specific resets, all
> functionality is added to the PCI-core, thank-you-very-much.  I even
> posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
> bad so that pci_reset_function() won't claim that worked.  All VGA
> access quirks are done in QEMU, the kernel doesn't have any business in
> remapping config space over MMIO regions or trapping other config space
> backdoors.

Thanks for the info Alex, I hadn't got around to actually looking and
the vfio-pci code and was just going to what Sander said.

We probably do need to have a more in depth look at now PCI devices and
handled by both the toolstack and pciback but in the short term I would
like a simple solution that does not extend the ABI.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:42:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:42:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwqLL-0001Vp-8D; Fri, 05 Dec 2014 10:42:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XwqLK-0001Vk-8Y
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:42:34 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	06/2A-15461-71C81845; Fri, 05 Dec 2014 10:42:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417776149!13616300!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 16891 invoked from network); 5 Dec 2014 10:42: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;
	5 Dec 2014 10:42:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200649742"
Message-ID: <54818C13.8020207@citrix.com>
Date: Fri, 5 Dec 2014 10:42:27 +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>, Tim Deegan <tim@xen.org>
References: <20141204172511.GF43116@deinos.phlegethon.org>	<54818706020000780004D07D@mail.emea.novell.com>	<20141205094914.GC25082@deinos.phlegethon.org>
	<1417773296.22808.50.camel@citrix.com>
In-Reply-To: <1417773296.22808.50.camel@citrix.com>
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] PVH cleanups after 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 05/12/14 09:54, Ian Campbell wrote:
> On Fri, 2014-12-05 at 10:49 +0100, Tim Deegan wrote:
>> At 09:20 +0000 on 05 Dec (1417767654), Jan Beulich wrote:
>>>>>> On 04.12.14 at 18:25, <tim@xen.org> wrote:
>>>> Potential feature flags, based on whiteboard notes at the session.
>>>> Things that are 'Yes' in both columns might not need actual flags :)
>>>>
>>>>                      'HVM'       'PVH'
>>>> 64bit hypercalls      Yes         Yes
>>>> 32bit hypercalls      Yes         No
>>> Iiuc the lack of support of 32-bit hypercalls is simply because PVH
>>> guests aren't expected to use them as being always 64-bit right
>>> now. I.e. I can't really see why we couldn't just enable them once
>>> the 64-bit hypercall tables got combined, in which case we wouldn't
>>> need a feature flag here either.
>> Agreed -- I think the same will apply to a few other things, like shadow
>> pagetables and some of the other MM tricks.  
> Might we want to constrain a given PVH domain to only make 32- or 64-bit
> hypercalls?
>
> Or do we consider already having crossed that bridge with HVM enough
> reason to allow it for PVH? I'm wonder if that, even if it is
> technically possible to support not, doing so might mitigate some
> potential security issues down the line. There's obviously a tradeoff
> against in-guest flexibility though.

Madating a 32/64bit split serves only to cause booting issues; you need
to know a-priori what the eventual kernel is going to be before you
build the domain. This is an awkward issue with PV domains which
*really* wants not to apply to PVH as well.

PVH guests with the plan of "HVM - qemu" should be able to fully choose
their operating mode, and allow for in-guest bootstrapping which is far
superior from a security/isolation point of view than toolstack
bootstrapping.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:42:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:42:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwqLL-0001Vp-8D; Fri, 05 Dec 2014 10:42:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XwqLK-0001Vk-8Y
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:42:34 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	06/2A-15461-71C81845; Fri, 05 Dec 2014 10:42:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417776149!13616300!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 16891 invoked from network); 5 Dec 2014 10:42: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;
	5 Dec 2014 10:42:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200649742"
Message-ID: <54818C13.8020207@citrix.com>
Date: Fri, 5 Dec 2014 10:42:27 +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>, Tim Deegan <tim@xen.org>
References: <20141204172511.GF43116@deinos.phlegethon.org>	<54818706020000780004D07D@mail.emea.novell.com>	<20141205094914.GC25082@deinos.phlegethon.org>
	<1417773296.22808.50.camel@citrix.com>
In-Reply-To: <1417773296.22808.50.camel@citrix.com>
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] PVH cleanups after 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 05/12/14 09:54, Ian Campbell wrote:
> On Fri, 2014-12-05 at 10:49 +0100, Tim Deegan wrote:
>> At 09:20 +0000 on 05 Dec (1417767654), Jan Beulich wrote:
>>>>>> On 04.12.14 at 18:25, <tim@xen.org> wrote:
>>>> Potential feature flags, based on whiteboard notes at the session.
>>>> Things that are 'Yes' in both columns might not need actual flags :)
>>>>
>>>>                      'HVM'       'PVH'
>>>> 64bit hypercalls      Yes         Yes
>>>> 32bit hypercalls      Yes         No
>>> Iiuc the lack of support of 32-bit hypercalls is simply because PVH
>>> guests aren't expected to use them as being always 64-bit right
>>> now. I.e. I can't really see why we couldn't just enable them once
>>> the 64-bit hypercall tables got combined, in which case we wouldn't
>>> need a feature flag here either.
>> Agreed -- I think the same will apply to a few other things, like shadow
>> pagetables and some of the other MM tricks.  
> Might we want to constrain a given PVH domain to only make 32- or 64-bit
> hypercalls?
>
> Or do we consider already having crossed that bridge with HVM enough
> reason to allow it for PVH? I'm wonder if that, even if it is
> technically possible to support not, doing so might mitigate some
> potential security issues down the line. There's obviously a tradeoff
> against in-guest flexibility though.

Madating a 32/64bit split serves only to cause booting issues; you need
to know a-priori what the eventual kernel is going to be before you
build the domain. This is an awkward issue with PV domains which
*really* wants not to apply to PVH as well.

PVH guests with the plan of "HVM - qemu" should be able to fully choose
their operating mode, and allow for in-guest bootstrapping which is far
superior from a security/isolation point of view than toolstack
bootstrapping.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:43:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:43:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwqM3-0001ZH-Mh; Fri, 05 Dec 2014 10:43: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 1XwqM2-0001Yz-Bh
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 10:43:18 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	3C/15-01660-54C81845; Fri, 05 Dec 2014 10:43:17 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417776194!4149377!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 13976 invoked from network); 5 Dec 2014 10:43:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 10:43:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200280696"
Message-ID: <54818C40.5020706@citrix.com>
Date: Fri, 5 Dec 2014 10:43:12 +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: 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>
References: <1417760195-16911-1-git-send-email-jgross@suse.com>
In-Reply-To: <1417760195-16911-1-git-send-email-jgross@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH] xen: fix sparse warning 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>
Content-Type: text/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/12/14 06:16, Juergen Gross wrote:
> The patch "Speed up set_phys_to_machine() by using read-only mappings"
> introduced a sparse warning:
> 
> arch/x86/xen/p2m.c:628:13: sparse: incorrect type in argument 1
>                            (different address spaces)
> 
> Avoid the warning.

Thanks.

But can you add some helper functions instead?  Perhaps:

static inline int xen_safe_write_ulong(unsigned long *addr,
    unsigned long val)
{
    //...
}

static inline int xen_safe_read_ulong(unsigned long *addr,
        unsigned long *val)
{
    //...
}

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:43:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:43:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwqM3-0001ZH-Mh; Fri, 05 Dec 2014 10:43: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 1XwqM2-0001Yz-Bh
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 10:43:18 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	3C/15-01660-54C81845; Fri, 05 Dec 2014 10:43:17 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417776194!4149377!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 13976 invoked from network); 5 Dec 2014 10:43:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 10:43:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200280696"
Message-ID: <54818C40.5020706@citrix.com>
Date: Fri, 5 Dec 2014 10:43:12 +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: 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>
References: <1417760195-16911-1-git-send-email-jgross@suse.com>
In-Reply-To: <1417760195-16911-1-git-send-email-jgross@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH] xen: fix sparse warning 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>
Content-Type: text/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/12/14 06:16, Juergen Gross wrote:
> The patch "Speed up set_phys_to_machine() by using read-only mappings"
> introduced a sparse warning:
> 
> arch/x86/xen/p2m.c:628:13: sparse: incorrect type in argument 1
>                            (different address spaces)
> 
> Avoid the warning.

Thanks.

But can you add some helper functions instead?  Perhaps:

static inline int xen_safe_write_ulong(unsigned long *addr,
    unsigned long val)
{
    //...
}

static inline int xen_safe_read_ulong(unsigned long *addr,
        unsigned long *val)
{
    //...
}

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:45:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:45:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwqOA-0001mp-8O; Fri, 05 Dec 2014 10:45:30 +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 1XwqO8-0001mX-4k
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:45:28 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	6F/16-26858-7CC81845; Fri, 05 Dec 2014 10:45:27 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417776324!6861946!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25595 invoked from network); 5 Dec 2014 10:45:26 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 10:45:26 -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 sB5AjIub018684
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Fri, 5 Dec 2014 05:45:18 -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 sB5AjE2H030127
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Fri, 5 Dec 2014 05:45:15 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Wei Liu <wei.liu2@citrix.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-9-git-send-email-vkuznets@redhat.com>
	<20141204160133.GA31446@zion.uk.xensource.com>
Date: Fri, 05 Dec 2014 11:45:14 +0100
In-Reply-To: <20141204160133.GA31446@zion.uk.xensource.com> (Wei Liu's message
	of "Thu, 4 Dec 2014 16:01:33 +0000")
Message-ID: <87oarifk91.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>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 8/9] libxl: soft reset support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 <wei.liu2@citrix.com> writes:

> (I've skipped the internal implementation since I don't know what's
>  required to fulfil soft reset.)
>
> On Wed, Dec 03, 2014 at 06:16:20PM +0100, Vitaly Kuznetsov wrote:
> [...]
>> +                                         libxl__domain_create_state *dcs);
>>  
>>  /* Each time the dm needs to be saved, we must call suspend and then save */
>>  _hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 53611dc..eb833f0 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>> @@ -2043,7 +2043,8 @@ static void reload_domain_config(uint32_t domid,
>>  }
>>  
>>  /* Returns 1 if domain should be restarted,
>> - * 2 if domain should be renamed then restarted, or 0
>> + * 2 if domain should be renamed then restarted,
>> + * 3 if domain performed soft reset, or 0
>>   * Can update r_domid if domain is destroyed etc */
>>  static int handle_domain_death(uint32_t *r_domid,
>>                                 libxl_event *event,
>> @@ -2069,6 +2070,9 @@ static int handle_domain_death(uint32_t *r_domid,
>>      case LIBXL_SHUTDOWN_REASON_WATCHDOG:
>>          action = d_config->on_watchdog;
>>          break;
>> +    case LIBXL_SHUTDOWN_REASON_SOFT_RESET:
>> +        LOG("Domain performed soft reset.");
>> +        return 3;
>
> Would it be useful to provide "on_soft_reset" option in xl? Will the
> admin be interested in performing some other action when domain does
> soft reset? Say, for security reason admin want to prohibit domain from
> soft resetting itself.
>

Makes sense, let's add it.

>>      default:
>>          LOG("Unknown shutdown reason code %d. Destroying domain.",
>>              event->u.domain_shutdown.shutdown_reason);
>> @@ -2285,6 +2289,7 @@ static void evdisable_disk_ejects(libxl_evgen_disk_eject **diskws,
>>  static uint32_t create_domain(struct domain_create *dom_info)
>>  {
>>      uint32_t domid = INVALID_DOMID;
>> +    uint32_t domid_old = INVALID_DOMID;
>>  
>>      libxl_domain_config d_config;
>>  
>> @@ -2510,7 +2515,18 @@ start:
>>           * restore/migrate-receive it again.
>>           */
>>          restoring = 0;
>> -    }else{
>> +    } else if (domid_old != INVALID_DOMID) {
>> +        /* Do soft reset */
>> +        d_config.b_info.nodemap.size = 0;
>
> What's the reason for doing this?
>
> If you encounter problem with this it should probably be fixed in
> libxl.

Ah, sorry, I forgot about this hackaround (which was required since
194e7183 if I'm not mistaken). The root cause is that
reload_domain_config() was missing on soft_reset path and we were
hitting "Can run NUMA placement only if the domain does not have any
NUMA node affinity set already" clause.

I will fix this along with "on_soft_reset" implementation.

>
> Wei.
>
>> +        ret = libxl_domain_soft_reset(ctx, &d_config,
>> +                                      &domid, domid_old,
>> +                                      0, 0);
>> +
>> +        if ( ret ) {
>> +            goto error_out;
>> +        }
>> +        domid_old = INVALID_DOMID;
>> +    } else {
>>          ret = libxl_domain_create_new(ctx, &d_config, &domid,
>>                                        0, autoconnect_console_how);
>>      }
>> @@ -2574,6 +2590,8 @@ start:
>>                  event->u.domain_shutdown.shutdown_reason,
>>                  event->u.domain_shutdown.shutdown_reason);
>>              switch (handle_domain_death(&domid, event, &d_config)) {
>> +            case 3:
>> +                domid_old = domid;
>>              case 2:
>>                  if (!preserve_domain(&domid, event, &d_config)) {
>>                      /* If we fail then exit leaving the old domain in place. */
>> -- 
>> 1.9.3
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

-- 
  Vitaly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:45:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:45:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwqOA-0001mp-8O; Fri, 05 Dec 2014 10:45:30 +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 1XwqO8-0001mX-4k
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:45:28 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	6F/16-26858-7CC81845; Fri, 05 Dec 2014 10:45:27 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417776324!6861946!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25595 invoked from network); 5 Dec 2014 10:45:26 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 10:45:26 -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 sB5AjIub018684
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Fri, 5 Dec 2014 05:45:18 -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 sB5AjE2H030127
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Fri, 5 Dec 2014 05:45:15 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Wei Liu <wei.liu2@citrix.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<1417626981-8432-9-git-send-email-vkuznets@redhat.com>
	<20141204160133.GA31446@zion.uk.xensource.com>
Date: Fri, 05 Dec 2014 11:45:14 +0100
In-Reply-To: <20141204160133.GA31446@zion.uk.xensource.com> (Wei Liu's message
	of "Thu, 4 Dec 2014 16:01:33 +0000")
Message-ID: <87oarifk91.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>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 8/9] libxl: soft reset support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 <wei.liu2@citrix.com> writes:

> (I've skipped the internal implementation since I don't know what's
>  required to fulfil soft reset.)
>
> On Wed, Dec 03, 2014 at 06:16:20PM +0100, Vitaly Kuznetsov wrote:
> [...]
>> +                                         libxl__domain_create_state *dcs);
>>  
>>  /* Each time the dm needs to be saved, we must call suspend and then save */
>>  _hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 53611dc..eb833f0 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>> @@ -2043,7 +2043,8 @@ static void reload_domain_config(uint32_t domid,
>>  }
>>  
>>  /* Returns 1 if domain should be restarted,
>> - * 2 if domain should be renamed then restarted, or 0
>> + * 2 if domain should be renamed then restarted,
>> + * 3 if domain performed soft reset, or 0
>>   * Can update r_domid if domain is destroyed etc */
>>  static int handle_domain_death(uint32_t *r_domid,
>>                                 libxl_event *event,
>> @@ -2069,6 +2070,9 @@ static int handle_domain_death(uint32_t *r_domid,
>>      case LIBXL_SHUTDOWN_REASON_WATCHDOG:
>>          action = d_config->on_watchdog;
>>          break;
>> +    case LIBXL_SHUTDOWN_REASON_SOFT_RESET:
>> +        LOG("Domain performed soft reset.");
>> +        return 3;
>
> Would it be useful to provide "on_soft_reset" option in xl? Will the
> admin be interested in performing some other action when domain does
> soft reset? Say, for security reason admin want to prohibit domain from
> soft resetting itself.
>

Makes sense, let's add it.

>>      default:
>>          LOG("Unknown shutdown reason code %d. Destroying domain.",
>>              event->u.domain_shutdown.shutdown_reason);
>> @@ -2285,6 +2289,7 @@ static void evdisable_disk_ejects(libxl_evgen_disk_eject **diskws,
>>  static uint32_t create_domain(struct domain_create *dom_info)
>>  {
>>      uint32_t domid = INVALID_DOMID;
>> +    uint32_t domid_old = INVALID_DOMID;
>>  
>>      libxl_domain_config d_config;
>>  
>> @@ -2510,7 +2515,18 @@ start:
>>           * restore/migrate-receive it again.
>>           */
>>          restoring = 0;
>> -    }else{
>> +    } else if (domid_old != INVALID_DOMID) {
>> +        /* Do soft reset */
>> +        d_config.b_info.nodemap.size = 0;
>
> What's the reason for doing this?
>
> If you encounter problem with this it should probably be fixed in
> libxl.

Ah, sorry, I forgot about this hackaround (which was required since
194e7183 if I'm not mistaken). The root cause is that
reload_domain_config() was missing on soft_reset path and we were
hitting "Can run NUMA placement only if the domain does not have any
NUMA node affinity set already" clause.

I will fix this along with "on_soft_reset" implementation.

>
> Wei.
>
>> +        ret = libxl_domain_soft_reset(ctx, &d_config,
>> +                                      &domid, domid_old,
>> +                                      0, 0);
>> +
>> +        if ( ret ) {
>> +            goto error_out;
>> +        }
>> +        domid_old = INVALID_DOMID;
>> +    } else {
>>          ret = libxl_domain_create_new(ctx, &d_config, &domid,
>>                                        0, autoconnect_console_how);
>>      }
>> @@ -2574,6 +2590,8 @@ start:
>>                  event->u.domain_shutdown.shutdown_reason,
>>                  event->u.domain_shutdown.shutdown_reason);
>>              switch (handle_domain_death(&domid, event, &d_config)) {
>> +            case 3:
>> +                domid_old = domid;
>>              case 2:
>>                  if (!preserve_domain(&domid, event, &d_config)) {
>>                      /* If we fail then exit leaving the old domain in place. */
>> -- 
>> 1.9.3
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

-- 
  Vitaly

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:50:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:50:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwqSS-00027G-4b; Fri, 05 Dec 2014 10:49:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XwqSQ-00027B-C4
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 10:49:54 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	4E/FF-23865-1DD81845; Fri, 05 Dec 2014 10:49:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417776592!6863383!1
X-Originating-IP: [81.169.146.220]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32575 invoked from network); 5 Dec 2014 10:49:53 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 10:49:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417776592; l=1946;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=BiSk0zml+zmn/xhOwrqIR6w+IuI=;
	b=oRVCuPZJgdyM//6CmJ+AwFZ+suOgbIv85w/qUDgtfPOm9hcdknwmCH8bPnlQ1QtVyDC
	kIgrNPwzSxNmE04QYL8qhz+kwhH2RWoJT80oZkzA/uSu58X9xaUOj8+W+vC8/qQB2kB86
	OBK/ubN7Xm4mDfnTuA9xwDi+LxfwiXTj4C0=
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.2 AUTH) with ESMTPSA id h073daqB5AnmRxa
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 11:49:48 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 769FD5015E; Fri,  5 Dec 2014 11:49:48 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 11:49:47 +0100
Message-Id: <1417776587-26018-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH] tools/xenstore: fix link error with libsystemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Linking fails with undefined reference to the used systemd functions.
Move LDFLAGS after the object files to fix the failure.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/xenstore/Makefile | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index bff9b25..11b6a06 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -74,10 +74,10 @@ endif
 init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
 
 init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
-	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
+	$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
 
 xenstored: $(XENSTORED_OBJS)
-	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
+	$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
 xenstored.a: $(XENSTORED_OBJS)
 	$(AR) cr $@ $^
@@ -86,13 +86,13 @@ $(CLIENTS): xenstore
 	ln -f xenstore $@
 
 xenstore: xenstore_client.o $(LIBXENSTORE)
-	$(CC) $(LDFLAGS) $< $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
+	$(CC) $< $(LDFLAGS) $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
 xenstore-control: xenstore_control.o $(LIBXENSTORE)
-	$(CC) $(LDFLAGS) $< $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
+	$(CC) $< $(LDFLAGS) $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
 xs_tdb_dump: xs_tdb_dump.o utils.o tdb.o talloc.o
-	$(CC) $(LDFLAGS) $^ -o $@ $(APPEND_LDFLAGS)
+	$(CC) $^ $(LDFLAGS) -o $@ $(APPEND_LDFLAGS)
 
 libxenstore.so: libxenstore.so.$(MAJOR)
 	ln -sf $< $@

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:50:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:50:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwqSS-00027G-4b; Fri, 05 Dec 2014 10:49:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XwqSQ-00027B-C4
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 10:49:54 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	4E/FF-23865-1DD81845; Fri, 05 Dec 2014 10:49:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417776592!6863383!1
X-Originating-IP: [81.169.146.220]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32575 invoked from network); 5 Dec 2014 10:49:53 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 10:49:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417776592; l=1946;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=BiSk0zml+zmn/xhOwrqIR6w+IuI=;
	b=oRVCuPZJgdyM//6CmJ+AwFZ+suOgbIv85w/qUDgtfPOm9hcdknwmCH8bPnlQ1QtVyDC
	kIgrNPwzSxNmE04QYL8qhz+kwhH2RWoJT80oZkzA/uSu58X9xaUOj8+W+vC8/qQB2kB86
	OBK/ubN7Xm4mDfnTuA9xwDi+LxfwiXTj4C0=
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.2 AUTH) with ESMTPSA id h073daqB5AnmRxa
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 11:49:48 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 769FD5015E; Fri,  5 Dec 2014 11:49:48 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 11:49:47 +0100
Message-Id: <1417776587-26018-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH] tools/xenstore: fix link error with libsystemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Linking fails with undefined reference to the used systemd functions.
Move LDFLAGS after the object files to fix the failure.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/xenstore/Makefile | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index bff9b25..11b6a06 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -74,10 +74,10 @@ endif
 init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
 
 init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
-	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
+	$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
 
 xenstored: $(XENSTORED_OBJS)
-	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
+	$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
 xenstored.a: $(XENSTORED_OBJS)
 	$(AR) cr $@ $^
@@ -86,13 +86,13 @@ $(CLIENTS): xenstore
 	ln -f xenstore $@
 
 xenstore: xenstore_client.o $(LIBXENSTORE)
-	$(CC) $(LDFLAGS) $< $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
+	$(CC) $< $(LDFLAGS) $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
 xenstore-control: xenstore_control.o $(LIBXENSTORE)
-	$(CC) $(LDFLAGS) $< $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
+	$(CC) $< $(LDFLAGS) $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
 xs_tdb_dump: xs_tdb_dump.o utils.o tdb.o talloc.o
-	$(CC) $(LDFLAGS) $^ -o $@ $(APPEND_LDFLAGS)
+	$(CC) $^ $(LDFLAGS) -o $@ $(APPEND_LDFLAGS)
 
 libxenstore.so: libxenstore.so.$(MAJOR)
 	ln -sf $< $@

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:52:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1XwqUd-0002N0-La; Fri, 05 Dec 2014 10:52: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 1XwqUc-0002Lh-1I
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 10:52:10 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	D8/F9-01660-95E81845; Fri, 05 Dec 2014 10:52:09 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417776728!6443098!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2639 invoked from network); 5 Dec 2014 10:52:09 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 10:52:09 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so957422wiv.7
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 02:52: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=BqPK0Gs4KKjEqIwljJkLlEFOIhaYQge5UIxm9h+5meo=;
	b=Wmu3s3sDZpUnezpMeldc7ezXdFPk3VJV/6iixbNGV+0UPqjdYG8B7tv7ojtzm37oIz
	AsNMVMjYtFMoJqhmSZ20QohJXw7HFEYDq60TLuv6Ef8cU+eJSv6S4PlCGElRHkbRpMcU
	7/gQyGmvSQqqLw2JjQ76I5qVhxzIyh8Eve/F5BiTrSQUYSgS1EJLmta52NWZ/K+a/UVY
	e6PWuIM4Fm8v+4tJZd72cFDPZ3EcOUfF2cV0Tg2uuqz+ocgCfdaBYmRFeNH+5yNxonNm
	oXdqU88Slf8QJCfw7SxvwzMiUJO7/TDvONQya5EwNB1BzK5J7pzkcD6NdEWHgPgMembp
	FHQw==
X-Gm-Message-State: ALoCoQnS/HRfewWMIajNZTZsOmTJrW0sz4q4oizu1KQW0dWxszUIc0XhzZISC00/KaUlZTaekAa7
X-Received: by 10.180.85.198 with SMTP id j6mr3085747wiz.23.1417776728769;
	Fri, 05 Dec 2014 02:52:08 -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 ep6sm1796185wib.0.2014.12.05.02.52.07
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 02:52:08 -0800 (PST)
Message-ID: <54818E56.4030304@linaro.org>
Date: Fri, 05 Dec 2014 10:52:06 +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.3.0
MIME-Version: 1.0
To: Vijay Kilari <vijay.kilari@gmail.com>, Tim Deegan <tim@xen.org>
References: <CALicx6trd6Pvsit0LfbC66JU5G3r+1XTt0d-h0DLo8rd31X9vw@mail.gmail.com>	<548066FE.90905@linaro.org>	<20141204154006.GA43178@deinos.phlegethon.org>
	<CALicx6vVSL3mCxO6jrn2C-O8cFXLiPX=-uPPirB_JW02Bgx4zQ@mail.gmail.com>
In-Reply-To: <CALicx6vVSL3mCxO6jrn2C-O8cFXLiPX=-uPPirB_JW02Bgx4zQ@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/arm: uart interrupts 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

Hi Vijay,

On 05/12/2014 00:46, Vijay Kilari wrote:
  > Yes, this is the behaviour that Iam seeing. In Linux, uart driver
> masks TXI interrupt
> in IMSC if buffer is empty. However in xen, this scenario is not
> handled. This is the reason why cpu does not come out of uart irq
> routine if TX interrupt is raised but buffer is empty.
>
> I have added below changes to fix this on top of your suggested change

Can you send a formal patch (commit message + signed-off-by)?

Also, you will have to make sure you don't break the other serial 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 Fri Dec 05 10:52:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1XwqUd-0002N0-La; Fri, 05 Dec 2014 10:52: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 1XwqUc-0002Lh-1I
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 10:52:10 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	D8/F9-01660-95E81845; Fri, 05 Dec 2014 10:52:09 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417776728!6443098!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2639 invoked from network); 5 Dec 2014 10:52:09 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 10:52:09 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so957422wiv.7
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 02:52: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=BqPK0Gs4KKjEqIwljJkLlEFOIhaYQge5UIxm9h+5meo=;
	b=Wmu3s3sDZpUnezpMeldc7ezXdFPk3VJV/6iixbNGV+0UPqjdYG8B7tv7ojtzm37oIz
	AsNMVMjYtFMoJqhmSZ20QohJXw7HFEYDq60TLuv6Ef8cU+eJSv6S4PlCGElRHkbRpMcU
	7/gQyGmvSQqqLw2JjQ76I5qVhxzIyh8Eve/F5BiTrSQUYSgS1EJLmta52NWZ/K+a/UVY
	e6PWuIM4Fm8v+4tJZd72cFDPZ3EcOUfF2cV0Tg2uuqz+ocgCfdaBYmRFeNH+5yNxonNm
	oXdqU88Slf8QJCfw7SxvwzMiUJO7/TDvONQya5EwNB1BzK5J7pzkcD6NdEWHgPgMembp
	FHQw==
X-Gm-Message-State: ALoCoQnS/HRfewWMIajNZTZsOmTJrW0sz4q4oizu1KQW0dWxszUIc0XhzZISC00/KaUlZTaekAa7
X-Received: by 10.180.85.198 with SMTP id j6mr3085747wiz.23.1417776728769;
	Fri, 05 Dec 2014 02:52:08 -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 ep6sm1796185wib.0.2014.12.05.02.52.07
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 02:52:08 -0800 (PST)
Message-ID: <54818E56.4030304@linaro.org>
Date: Fri, 05 Dec 2014 10:52:06 +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.3.0
MIME-Version: 1.0
To: Vijay Kilari <vijay.kilari@gmail.com>, Tim Deegan <tim@xen.org>
References: <CALicx6trd6Pvsit0LfbC66JU5G3r+1XTt0d-h0DLo8rd31X9vw@mail.gmail.com>	<548066FE.90905@linaro.org>	<20141204154006.GA43178@deinos.phlegethon.org>
	<CALicx6vVSL3mCxO6jrn2C-O8cFXLiPX=-uPPirB_JW02Bgx4zQ@mail.gmail.com>
In-Reply-To: <CALicx6vVSL3mCxO6jrn2C-O8cFXLiPX=-uPPirB_JW02Bgx4zQ@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/arm: uart interrupts 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

Hi Vijay,

On 05/12/2014 00:46, Vijay Kilari wrote:
  > Yes, this is the behaviour that Iam seeing. In Linux, uart driver
> masks TXI interrupt
> in IMSC if buffer is empty. However in xen, this scenario is not
> handled. This is the reason why cpu does not come out of uart irq
> routine if TX interrupt is raised but buffer is empty.
>
> I have added below changes to fix this on top of your suggested change

Can you send a formal patch (commit message + signed-off-by)?

Also, you will have to make sure you don't break the other serial 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 Fri Dec 05 10:53:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1XwqVU-0002Vl-2D; Fri, 05 Dec 2014 10:53:04 +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 1XwqVT-0002Vd-LA
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:53:03 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	17/D5-25714-E8E81845; Fri, 05 Dec 2014 10:53:02 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417776782!11736122!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23519 invoked from network); 5 Dec 2014 10:53:02 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 10:53:02 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so1004500wid.3
	for <xen-devel@lists.xenproject.org>;
	Fri, 05 Dec 2014 02:53: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
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=RRiraZul044O+sM4UlFaHs4FtL+WiGy70YI0mGT/uH4=;
	b=dBxeTNi+pg2GuFNaOW4EaZ3FpLeOIxqWkBfIwrWhpxbsg+xCXwMDTC9HvX1V0rcD2M
	uDWiXOR6Igbi3AVDB5UtjasL3W7adld2kS/gOpZJLN2ePt2xRxbuCvVQUh6x76NQP3/Y
	b7LN5hi8gKcznGny60yOHkrPgVEQa+koachaKsx4d8gyXTJbNkRWp9EjPnn19QfKq4j2
	ck/NgKM5nut1jbn3keAYCZTpdBrAyCL/pYnTDQemimoznTKYoCiOyDXyzoNs0v09OUFu
	VyPA1ph3AC+CtP4zdR67LpyMN5V1sCNUdMVaO/fKCJHKka/GulWQ4YKdIZDpWaZb5tHt
	Boaw==
X-Gm-Message-State: ALoCoQkKcnpzUdid6nF/3/0nWGo6F8ZaNX68USdpjgSohpO75SliBpbc5nsPl96HDSCZ7QcR290D
X-Received: by 10.194.191.227 with SMTP id hb3mr23803032wjc.79.1417776782085; 
	Fri, 05 Dec 2014 02:53:02 -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 j9sm12362637wjb.38.2014.12.05.02.53.00
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 02:53:01 -0800 (PST)
Message-ID: <54818E8C.3060004@linaro.org>
Date: Fri, 05 Dec 2014 10:53:00 +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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417721215-32639-1-git-send-email-julien.grall@linaro.org>
	<20141204193434.GB6225@laptop.dumpdata.com>
In-Reply-To: <20141204193434.GB6225@laptop.dumpdata.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Correct the opcode for
 BUG_INSTR on arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 04/12/2014 19:34, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 04, 2014 at 07:26:55PM +0000, Julien Grall wrote:
>> A 0 was forgotten when the arm32 BUG instruction opcode has been added in commit
>> 3e802c6ca1fb9a9549258c2855a57cad483f3cbd "xen/arm: Correctly support WARN_ON".
>>
>> This will result to use a valid instruction (mcreq 0, 3, r0, cr15, cr0, {7}),
>> and inhibit usage of BUG/WARN_ON and co.
>>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>
>> ---
>>
>> Not sure, why I dropped the 0 when I implemented the patch...
>> This is a bug fixed for Xen 4.5. This is only affected ARM32 where the
>> BUG opcode was malformed.
>>
>> With the malformed opcode, the ASSERT/BUG_ON is skipped and the
>> processor may execute another patch (because the compiler has optimized
>
> s/patch/path/ ?

Yes.

>> due the unreachable in both macro).
>>
>> The code modified is only executed when Xen is in bad state.
>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

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 Dec 05 10:53:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1XwqVU-0002Vl-2D; Fri, 05 Dec 2014 10:53:04 +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 1XwqVT-0002Vd-LA
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:53:03 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	17/D5-25714-E8E81845; Fri, 05 Dec 2014 10:53:02 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417776782!11736122!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23519 invoked from network); 5 Dec 2014 10:53:02 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 10:53:02 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so1004500wid.3
	for <xen-devel@lists.xenproject.org>;
	Fri, 05 Dec 2014 02:53: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
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=RRiraZul044O+sM4UlFaHs4FtL+WiGy70YI0mGT/uH4=;
	b=dBxeTNi+pg2GuFNaOW4EaZ3FpLeOIxqWkBfIwrWhpxbsg+xCXwMDTC9HvX1V0rcD2M
	uDWiXOR6Igbi3AVDB5UtjasL3W7adld2kS/gOpZJLN2ePt2xRxbuCvVQUh6x76NQP3/Y
	b7LN5hi8gKcznGny60yOHkrPgVEQa+koachaKsx4d8gyXTJbNkRWp9EjPnn19QfKq4j2
	ck/NgKM5nut1jbn3keAYCZTpdBrAyCL/pYnTDQemimoznTKYoCiOyDXyzoNs0v09OUFu
	VyPA1ph3AC+CtP4zdR67LpyMN5V1sCNUdMVaO/fKCJHKka/GulWQ4YKdIZDpWaZb5tHt
	Boaw==
X-Gm-Message-State: ALoCoQkKcnpzUdid6nF/3/0nWGo6F8ZaNX68USdpjgSohpO75SliBpbc5nsPl96HDSCZ7QcR290D
X-Received: by 10.194.191.227 with SMTP id hb3mr23803032wjc.79.1417776782085; 
	Fri, 05 Dec 2014 02:53:02 -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 j9sm12362637wjb.38.2014.12.05.02.53.00
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 02:53:01 -0800 (PST)
Message-ID: <54818E8C.3060004@linaro.org>
Date: Fri, 05 Dec 2014 10:53:00 +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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417721215-32639-1-git-send-email-julien.grall@linaro.org>
	<20141204193434.GB6225@laptop.dumpdata.com>
In-Reply-To: <20141204193434.GB6225@laptop.dumpdata.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Correct the opcode for
 BUG_INSTR on arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 04/12/2014 19:34, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 04, 2014 at 07:26:55PM +0000, Julien Grall wrote:
>> A 0 was forgotten when the arm32 BUG instruction opcode has been added in commit
>> 3e802c6ca1fb9a9549258c2855a57cad483f3cbd "xen/arm: Correctly support WARN_ON".
>>
>> This will result to use a valid instruction (mcreq 0, 3, r0, cr15, cr0, {7}),
>> and inhibit usage of BUG/WARN_ON and co.
>>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>
>> ---
>>
>> Not sure, why I dropped the 0 when I implemented the patch...
>> This is a bug fixed for Xen 4.5. This is only affected ARM32 where the
>> BUG opcode was malformed.
>>
>> With the malformed opcode, the ASSERT/BUG_ON is skipped and the
>> processor may execute another patch (because the compiler has optimized
>
> s/patch/path/ ?

Yes.

>> due the unreachable in both macro).
>>
>> The code modified is only executed when Xen is in bad state.
>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

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 Dec 05 10:53:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:53:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwqVb-0002XL-Eq; Fri, 05 Dec 2014 10:53:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwqVa-0002Wz-J8
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 10:53:10 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	58/31-26652-59E81845; Fri, 05 Dec 2014 10:53:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417776785!11755679!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 22562 invoked from network); 5 Dec 2014 10:53:07 -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 Dec 2014 10:53:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200283695"
Message-ID: <1417776783.22808.55.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 5 Dec 2014 10:53:03 +0000
In-Reply-To: <1417776587-26018-1-git-send-email-olaf@aepfle.de>
References: <1417776587-26018-1-git-send-email-olaf@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/xenstore: fix link error with
	libsystemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 11:49 +0100, Olaf Hering wrote:
> Linking fails with undefined reference to the used systemd functions.
> Move LDFLAGS after the object files to fix the failure.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

This should go into 4.5.

FWIW my suspicion is that this relates to toolstacks using --as-needed
by default.

> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
>  tools/xenstore/Makefile | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> index bff9b25..11b6a06 100644
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -74,10 +74,10 @@ endif
>  init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
>  
>  init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
> -	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
> +	$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
>  
>  xenstored: $(XENSTORED_OBJS)
> -	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> +	$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
>  xenstored.a: $(XENSTORED_OBJS)
>  	$(AR) cr $@ $^
> @@ -86,13 +86,13 @@ $(CLIENTS): xenstore
>  	ln -f xenstore $@
>  
>  xenstore: xenstore_client.o $(LIBXENSTORE)
> -	$(CC) $(LDFLAGS) $< $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> +	$(CC) $< $(LDFLAGS) $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
>  xenstore-control: xenstore_control.o $(LIBXENSTORE)
> -	$(CC) $(LDFLAGS) $< $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> +	$(CC) $< $(LDFLAGS) $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
>  xs_tdb_dump: xs_tdb_dump.o utils.o tdb.o talloc.o
> -	$(CC) $(LDFLAGS) $^ -o $@ $(APPEND_LDFLAGS)
> +	$(CC) $^ $(LDFLAGS) -o $@ $(APPEND_LDFLAGS)
>  
>  libxenstore.so: libxenstore.so.$(MAJOR)
>  	ln -sf $< $@



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:53:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10:53:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwqVb-0002XL-Eq; Fri, 05 Dec 2014 10:53:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwqVa-0002Wz-J8
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 10:53:10 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	58/31-26652-59E81845; Fri, 05 Dec 2014 10:53:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417776785!11755679!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 22562 invoked from network); 5 Dec 2014 10:53:07 -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 Dec 2014 10:53:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200283695"
Message-ID: <1417776783.22808.55.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 5 Dec 2014 10:53:03 +0000
In-Reply-To: <1417776587-26018-1-git-send-email-olaf@aepfle.de>
References: <1417776587-26018-1-git-send-email-olaf@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/xenstore: fix link error with
	libsystemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 11:49 +0100, Olaf Hering wrote:
> Linking fails with undefined reference to the used systemd functions.
> Move LDFLAGS after the object files to fix the failure.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

This should go into 4.5.

FWIW my suspicion is that this relates to toolstacks using --as-needed
by default.

> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
>  tools/xenstore/Makefile | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> index bff9b25..11b6a06 100644
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -74,10 +74,10 @@ endif
>  init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
>  
>  init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
> -	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
> +	$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
>  
>  xenstored: $(XENSTORED_OBJS)
> -	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> +	$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
>  xenstored.a: $(XENSTORED_OBJS)
>  	$(AR) cr $@ $^
> @@ -86,13 +86,13 @@ $(CLIENTS): xenstore
>  	ln -f xenstore $@
>  
>  xenstore: xenstore_client.o $(LIBXENSTORE)
> -	$(CC) $(LDFLAGS) $< $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> +	$(CC) $< $(LDFLAGS) $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
>  xenstore-control: xenstore_control.o $(LIBXENSTORE)
> -	$(CC) $(LDFLAGS) $< $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> +	$(CC) $< $(LDFLAGS) $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
>  xs_tdb_dump: xs_tdb_dump.o utils.o tdb.o talloc.o
> -	$(CC) $(LDFLAGS) $^ -o $@ $(APPEND_LDFLAGS)
> +	$(CC) $^ $(LDFLAGS) -o $@ $(APPEND_LDFLAGS)
>  
>  libxenstore.so: libxenstore.so.$(MAJOR)
>  	ln -sf $< $@



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:55:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1XwqXg-0002mB-Bs; Fri, 05 Dec 2014 10:55: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 1XwqXe-0002lk-5l
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:55:18 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	7F/DD-14214-51F81845; Fri, 05 Dec 2014 10:55:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417776915!4152411!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 9562 invoked from network); 5 Dec 2014 10:55:16 -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;
	5 Dec 2014 10:55:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200653241"
Message-ID: <1417776878.22808.56.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 5 Dec 2014 10:54:38 +0000
In-Reply-To: <20141204193434.GB6225@laptop.dumpdata.com>
References: <1417721215-32639-1-git-send-email-julien.grall@linaro.org>
	<20141204193434.GB6225@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>,
	tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Correct the opcode for
 BUG_INSTR on arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-12-04 at 14:34 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 04, 2014 at 07:26:55PM +0000, Julien Grall wrote:
> > A 0 was forgotten when the arm32 BUG instruction opcode has been added in commit
> > 3e802c6ca1fb9a9549258c2855a57cad483f3cbd "xen/arm: Correctly support WARN_ON".
> > 
> > This will result to use a valid instruction (mcreq 0, 3, r0, cr15, cr0, {7}),
> > and inhibit usage of BUG/WARN_ON and co.

Doh!

> > 
> > Signed-off-by: Julien Grall <julien.grall@linaro.org>
> > 
> > ---
> > 
> > Not sure, why I dropped the 0 when I implemented the patch...
> > This is a bug fixed for Xen 4.5. This is only affected ARM32 where the
> > BUG opcode was malformed.
> > 
> > With the malformed opcode, the ASSERT/BUG_ON is skipped and the
> > processor may execute another patch (because the compiler has optimized
> 
> s/patch/path/ ?

Will fix on commit.

> > due the unreachable in both macro).
> > 
> > The code modified is only executed when Xen is in bad state.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> > ---
> >  xen/include/asm-arm/arm32/bug.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/xen/include/asm-arm/arm32/bug.h b/xen/include/asm-arm/arm32/bug.h
> > index 155b420..3e66f35 100644
> > --- a/xen/include/asm-arm/arm32/bug.h
> > +++ b/xen/include/asm-arm/arm32/bug.h
> > @@ -6,7 +6,7 @@
> >  /* ARMv7 provides a list of undefined opcode (see A8.8.247 DDI 0406C.b)
> >   * Use one them encoding A1 to go in exception mode
> >   */
> > -#define BUG_OPCODE  0xe7f00f0
> > +#define BUG_OPCODE  0xe7f000f0
> >  
> >  #define BUG_INSTR ".word " __stringify(BUG_OPCODE)
> >  
> > -- 
> > 2.1.3
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:55:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1XwqXb-0002lU-Vk; Fri, 05 Dec 2014 10:55:15 +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 1XwqXb-0002lF-0y
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 10:55:15 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E6/B2-27584-21F81845; Fri, 05 Dec 2014 10:55:14 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417776912!11756236!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 15198 invoked from network); 5 Dec 2014 10:55:13 -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 Dec 2014 10:55:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200284168"
Message-ID: <54818F0E.1010904@citrix.com>
Date: Fri, 5 Dec 2014 10:55:10 +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: <20141204172511.GF43116@deinos.phlegethon.org>
In-Reply-To: <20141204172511.GF43116@deinos.phlegethon.org>
X-DLP: MIA2
Subject: Re: [Xen-devel] PVH cleanups after 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/12/14 17:25, Tim Deegan wrote:
>                      'HVM'       'PVH'
> 64bit hypercalls      Yes         Yes
> 32bit hypercalls      Yes         No
> Paging assistance     Yes         Yes
> ioreq-servers         Yes         No

                                    Perhaps, but no default one.  This
would be required for supporting virtual GPU passthrough to a PVH guest.

> HVM-style CPUID       Yes         Yes
> Interrupt controllers Yes         No     ([x2]apic, ioapic, pic &c)

                                    Yes, if enough APIC virtualization
hardware is available.

> Timers                Yes         No     (rtc, hpet, pit, pmtimer)
> Machine Check regs    Yes         Yes
> Emulated PCI          Yes         No     (PVH to use pcifront?)

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:55:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1XwqXb-0002lU-Vk; Fri, 05 Dec 2014 10:55:15 +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 1XwqXb-0002lF-0y
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 10:55:15 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E6/B2-27584-21F81845; Fri, 05 Dec 2014 10:55:14 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417776912!11756236!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 15198 invoked from network); 5 Dec 2014 10:55:13 -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 Dec 2014 10:55:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200284168"
Message-ID: <54818F0E.1010904@citrix.com>
Date: Fri, 5 Dec 2014 10:55:10 +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: <20141204172511.GF43116@deinos.phlegethon.org>
In-Reply-To: <20141204172511.GF43116@deinos.phlegethon.org>
X-DLP: MIA2
Subject: Re: [Xen-devel] PVH cleanups after 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/12/14 17:25, Tim Deegan wrote:
>                      'HVM'       'PVH'
> 64bit hypercalls      Yes         Yes
> 32bit hypercalls      Yes         No
> Paging assistance     Yes         Yes
> ioreq-servers         Yes         No

                                    Perhaps, but no default one.  This
would be required for supporting virtual GPU passthrough to a PVH guest.

> HVM-style CPUID       Yes         Yes
> Interrupt controllers Yes         No     ([x2]apic, ioapic, pic &c)

                                    Yes, if enough APIC virtualization
hardware is available.

> Timers                Yes         No     (rtc, hpet, pit, pmtimer)
> Machine Check regs    Yes         Yes
> Emulated PCI          Yes         No     (PVH to use pcifront?)

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 10:55:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 10: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 1XwqXg-0002mB-Bs; Fri, 05 Dec 2014 10:55: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 1XwqXe-0002lk-5l
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:55:18 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	7F/DD-14214-51F81845; Fri, 05 Dec 2014 10:55:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417776915!4152411!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 9562 invoked from network); 5 Dec 2014 10:55:16 -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;
	5 Dec 2014 10:55:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200653241"
Message-ID: <1417776878.22808.56.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 5 Dec 2014 10:54:38 +0000
In-Reply-To: <20141204193434.GB6225@laptop.dumpdata.com>
References: <1417721215-32639-1-git-send-email-julien.grall@linaro.org>
	<20141204193434.GB6225@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>,
	tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Correct the opcode for
 BUG_INSTR on arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-12-04 at 14:34 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 04, 2014 at 07:26:55PM +0000, Julien Grall wrote:
> > A 0 was forgotten when the arm32 BUG instruction opcode has been added in commit
> > 3e802c6ca1fb9a9549258c2855a57cad483f3cbd "xen/arm: Correctly support WARN_ON".
> > 
> > This will result to use a valid instruction (mcreq 0, 3, r0, cr15, cr0, {7}),
> > and inhibit usage of BUG/WARN_ON and co.

Doh!

> > 
> > Signed-off-by: Julien Grall <julien.grall@linaro.org>
> > 
> > ---
> > 
> > Not sure, why I dropped the 0 when I implemented the patch...
> > This is a bug fixed for Xen 4.5. This is only affected ARM32 where the
> > BUG opcode was malformed.
> > 
> > With the malformed opcode, the ASSERT/BUG_ON is skipped and the
> > processor may execute another patch (because the compiler has optimized
> 
> s/patch/path/ ?

Will fix on commit.

> > due the unreachable in both macro).
> > 
> > The code modified is only executed when Xen is in bad state.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> > ---
> >  xen/include/asm-arm/arm32/bug.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/xen/include/asm-arm/arm32/bug.h b/xen/include/asm-arm/arm32/bug.h
> > index 155b420..3e66f35 100644
> > --- a/xen/include/asm-arm/arm32/bug.h
> > +++ b/xen/include/asm-arm/arm32/bug.h
> > @@ -6,7 +6,7 @@
> >  /* ARMv7 provides a list of undefined opcode (see A8.8.247 DDI 0406C.b)
> >   * Use one them encoding A1 to go in exception mode
> >   */
> > -#define BUG_OPCODE  0xe7f00f0
> > +#define BUG_OPCODE  0xe7f000f0
> >  
> >  #define BUG_INSTR ".word " __stringify(BUG_OPCODE)
> >  
> > -- 
> > 2.1.3
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 11:08:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 11:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwqjr-0003G2-M4; Fri, 05 Dec 2014 11:07:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xwqjr-0003Fx-0c
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 11:07:55 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	29/26-25276-A0291845; Fri, 05 Dec 2014 11:07:54 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417777672!13652455!1
X-Originating-IP: [66.165.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 13284 invoked from network); 5 Dec 2014 11:07:53 -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;
	5 Dec 2014 11:07:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200657308"
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; Fri, 5 Dec 2014
	06:07:45 -0500
Message-ID: <54819200.3010601@citrix.com>
Date: Fri, 5 Dec 2014 12:07:44 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <54808D6F.302@citrix.com>
	<548185DF020000780004D076@mail.emea.novell.com>
In-Reply-To: <548185DF020000780004D076@mail.emea.novell.com>
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Removing the PVH assert in arch/x86/hvm/io.c:87
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 05/12/14 a les 10.15, Jan Beulich ha escrit:
>>>> On 04.12.14 at 17:35, <roger.pau@citrix.com> wrote:
>> I've just stumbled upon this assert while testing PVH on different
>> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
>> and OUTS go through handle_mmio. So using this instructions from a PVH
>> guest basically kills Xen.
>>
>> I've removed it and everything seems fine, so I'm considering sending a
>> patch for 4.5 in order to have it removed. I think the path that could
>> trigger the crash because of the missing vioapic stuff is already
>> guarded by the other chunk added in the same patch.
> 
> Iirc we settled on forbidding paths to handle_mmio() for PVH (hence
> the ASSERT()). Sadly you provide way too little detail on what is
> actually happening in your case: What's the use case of to-be-
> emulated INS/OUTS in a PVH kernel?

In this specific situation I'm seeing intsw instructions executed by the
FreeBSD ATA layer:

http://fxr.watson.org/fxr/source/dev/ata/ata-lowlevel.c#L740

> What's the call tree that gets
> you into handle_mmio(), considering that both calls to
> handle_mmio_with_translation() from hvm_hap_nested_page_fault()
> as well as the one to handle_mmio() ought to be unreachable for PVH?

You can get there from vmx_vmexit_handler if the exit reason is
EXIT_REASON_IO_INSTRUCTION.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 11:08:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 11:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwqjr-0003G2-M4; Fri, 05 Dec 2014 11:07:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Xwqjr-0003Fx-0c
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 11:07:55 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	29/26-25276-A0291845; Fri, 05 Dec 2014 11:07:54 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417777672!13652455!1
X-Originating-IP: [66.165.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 13284 invoked from network); 5 Dec 2014 11:07:53 -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;
	5 Dec 2014 11:07:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="200657308"
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; Fri, 5 Dec 2014
	06:07:45 -0500
Message-ID: <54819200.3010601@citrix.com>
Date: Fri, 5 Dec 2014 12:07:44 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <54808D6F.302@citrix.com>
	<548185DF020000780004D076@mail.emea.novell.com>
In-Reply-To: <548185DF020000780004D076@mail.emea.novell.com>
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Removing the PVH assert in arch/x86/hvm/io.c:87
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 05/12/14 a les 10.15, Jan Beulich ha escrit:
>>>> On 04.12.14 at 17:35, <roger.pau@citrix.com> wrote:
>> I've just stumbled upon this assert while testing PVH on different
>> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
>> and OUTS go through handle_mmio. So using this instructions from a PVH
>> guest basically kills Xen.
>>
>> I've removed it and everything seems fine, so I'm considering sending a
>> patch for 4.5 in order to have it removed. I think the path that could
>> trigger the crash because of the missing vioapic stuff is already
>> guarded by the other chunk added in the same patch.
> 
> Iirc we settled on forbidding paths to handle_mmio() for PVH (hence
> the ASSERT()). Sadly you provide way too little detail on what is
> actually happening in your case: What's the use case of to-be-
> emulated INS/OUTS in a PVH kernel?

In this specific situation I'm seeing intsw instructions executed by the
FreeBSD ATA layer:

http://fxr.watson.org/fxr/source/dev/ata/ata-lowlevel.c#L740

> What's the call tree that gets
> you into handle_mmio(), considering that both calls to
> handle_mmio_with_translation() from hvm_hap_nested_page_fault()
> as well as the one to handle_mmio() ought to be unreachable for PVH?

You can get there from vmx_vmexit_handler if the exit reason is
EXIT_REASON_IO_INSTRUCTION.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 11:17:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 11:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwqsU-0003ko-MZ; Fri, 05 Dec 2014 11:16: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 1XwqsT-0003kj-Ka
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 11:16:49 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	A0/6B-25547-02491845; Fri, 05 Dec 2014 11:16:48 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417778207!11339846!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10860 invoked from network); 5 Dec 2014 11:16:47 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 11:16:47 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so1009996wiw.16
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 03:16:47 -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=PeiUYwFZxkZ3FYqPmTOZsiNmUxmb9RVh2FDe8fqsheg=;
	b=Q95tiOcrZrMuEvei/nlVRny7cUZ+7pYSXaoqyeOKWdALTcRMt/CvTVvEm8fYuIcJMm
	wljCRNs8hCup+Ax8SonaHgyBkgr/FxJRmxpwva99l/kLoSXWIUeZw8iwAuSDgk5RjoT7
	YKnvuZCIRfIhyKG3kRzayf4xnuC6tPVIBJVsw3mtg4ZA8xQOUJ/vHa/7FwoXh2MQRGC/
	zoRgkp61+l2F8sXapqVLah8zFDjGDZbFNJ9LMuvS8uY3DzUvOELAm+I71qAaxUAdE3d/
	0tvbRFmWsb0J1S0PvlWYrthMChDExPYQkxX4P6iDR5XR9eCnQG7yN4ijgK9zCkpL5fkm
	2zIA==
X-Gm-Message-State: ALoCoQnHhlDufPB6pmK4qpNz9mk46EsXXhAKTEkm4V+8g/MFK6i5kVn2lzxfYiHredhsqhTjrTTx
X-Received: by 10.194.189.138 with SMTP id gi10mr24433471wjc.86.1417778207571; 
	Fri, 05 Dec 2014 03:16:47 -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 ej10sm1876847wib.2.2014.12.05.03.16.46
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 03:16:46 -0800 (PST)
Message-ID: <5481941D.6050106@linaro.org>
Date: Fri, 05 Dec 2014 11:16:45 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, Sagun Garg <sagun@nexchanges.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>	<1417688979.22808.6.camel@citrix.com>	<CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@mail.gmail.com>
	<1417771940.22808.39.camel@citrix.com>
In-Reply-To: <1417771940.22808.39.camel@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

On 05/12/2014 09:32, Ian Campbell wrote:
> On Fri, 2014-12-05 at 14:51 +0530, Sagun Garg wrote:
> Not sure what sorts of risks you mean, I don't think there is anything
> Xen specific here, just the usual stuff with running an untested OS on
> any new platform.
>
> I don't know if Nexus devices are brickable, but if so then that might
> be an issue with trying any untested OS on them.

Nexus platform tend to be a good platform for development. I would be 
surprised if you can brick it with untested OS. Though, I would not try 
to change the bootloader and I don't know if they support HYP mode.

>
> Phones and the like aren't typically very good debug platforms (i.e. no
> serial, no JTAG etc) so running an untested OS on them can end up being
> hard (but not impossible) to debug if it doesn't work, that's why
> platforms such as the Arndale exist -- they are mobile phones with all
> the extra useful debug stuff brought out to headers.

Nexus smartphone (at least 4) has an UART hidden in the headphone jack.
I don't know it's possible to buy the specific cable but you would be 
able to build your own. Though, I haven't tried myself.

The Linux kernel provided on AOSP has the code to enable the UART. So 
you should be able to get the log.

For Xen, you will have to implement yourself the debug UART.

-- 
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 Dec 05 11:17:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 11:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwqsU-0003ko-MZ; Fri, 05 Dec 2014 11:16: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 1XwqsT-0003kj-Ka
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 11:16:49 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	A0/6B-25547-02491845; Fri, 05 Dec 2014 11:16:48 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417778207!11339846!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10860 invoked from network); 5 Dec 2014 11:16:47 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 11:16:47 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so1009996wiw.16
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 03:16:47 -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=PeiUYwFZxkZ3FYqPmTOZsiNmUxmb9RVh2FDe8fqsheg=;
	b=Q95tiOcrZrMuEvei/nlVRny7cUZ+7pYSXaoqyeOKWdALTcRMt/CvTVvEm8fYuIcJMm
	wljCRNs8hCup+Ax8SonaHgyBkgr/FxJRmxpwva99l/kLoSXWIUeZw8iwAuSDgk5RjoT7
	YKnvuZCIRfIhyKG3kRzayf4xnuC6tPVIBJVsw3mtg4ZA8xQOUJ/vHa/7FwoXh2MQRGC/
	zoRgkp61+l2F8sXapqVLah8zFDjGDZbFNJ9LMuvS8uY3DzUvOELAm+I71qAaxUAdE3d/
	0tvbRFmWsb0J1S0PvlWYrthMChDExPYQkxX4P6iDR5XR9eCnQG7yN4ijgK9zCkpL5fkm
	2zIA==
X-Gm-Message-State: ALoCoQnHhlDufPB6pmK4qpNz9mk46EsXXhAKTEkm4V+8g/MFK6i5kVn2lzxfYiHredhsqhTjrTTx
X-Received: by 10.194.189.138 with SMTP id gi10mr24433471wjc.86.1417778207571; 
	Fri, 05 Dec 2014 03:16:47 -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 ej10sm1876847wib.2.2014.12.05.03.16.46
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 03:16:46 -0800 (PST)
Message-ID: <5481941D.6050106@linaro.org>
Date: Fri, 05 Dec 2014 11:16:45 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, Sagun Garg <sagun@nexchanges.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>	<1417688979.22808.6.camel@citrix.com>	<CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@mail.gmail.com>
	<1417771940.22808.39.camel@citrix.com>
In-Reply-To: <1417771940.22808.39.camel@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

On 05/12/2014 09:32, Ian Campbell wrote:
> On Fri, 2014-12-05 at 14:51 +0530, Sagun Garg wrote:
> Not sure what sorts of risks you mean, I don't think there is anything
> Xen specific here, just the usual stuff with running an untested OS on
> any new platform.
>
> I don't know if Nexus devices are brickable, but if so then that might
> be an issue with trying any untested OS on them.

Nexus platform tend to be a good platform for development. I would be 
surprised if you can brick it with untested OS. Though, I would not try 
to change the bootloader and I don't know if they support HYP mode.

>
> Phones and the like aren't typically very good debug platforms (i.e. no
> serial, no JTAG etc) so running an untested OS on them can end up being
> hard (but not impossible) to debug if it doesn't work, that's why
> platforms such as the Arndale exist -- they are mobile phones with all
> the extra useful debug stuff brought out to headers.

Nexus smartphone (at least 4) has an UART hidden in the headphone jack.
I don't know it's possible to buy the specific cable but you would be 
able to build your own. Though, I haven't tried myself.

The Linux kernel provided on AOSP has the code to enable the UART. So 
you should be able to get the log.

For Xen, you will have to implement yourself the debug UART.

-- 
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 Dec 05 11:24:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 11: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 1Xwqzw-00044K-PJ; Fri, 05 Dec 2014 11:24:32 +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 1Xwqzu-00044D-Jq
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 11:24:30 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	56/21-18267-DE591845; Fri, 05 Dec 2014 11:24:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417778667!7587444!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 13771 invoked from network); 5 Dec 2014 11:24:29 -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 Dec 2014 11:24:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200662436"
Message-ID: <548195EA.5050101@citrix.com>
Date: Fri, 5 Dec 2014 11:24:26 +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: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>, Jan Beulich
	<JBeulich@suse.com>
References: <54808D6F.302@citrix.com>	<548185DF020000780004D076@mail.emea.novell.com>
	<54819200.3010601@citrix.com>
In-Reply-To: <54819200.3010601@citrix.com>
Content-Length: 1340
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Removing the PVH assert in arch/x86/hvm/io.c:87
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 05/12/14 11:07, Roger Pau Monn=E9 wrote:
> El 05/12/14 a les 10.15, Jan Beulich ha escrit:
>>>>> On 04.12.14 at 17:35, <roger.pau@citrix.com> wrote:
>>> I've just stumbled upon this assert while testing PVH on different
>>> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
>>> and OUTS go through handle_mmio. So using this instructions from a PVH
>>> guest basically kills Xen.
>>>
>>> I've removed it and everything seems fine, so I'm considering sending a
>>> patch for 4.5 in order to have it removed. I think the path that could
>>> trigger the crash because of the missing vioapic stuff is already
>>> guarded by the other chunk added in the same patch.
>>
>> Iirc we settled on forbidding paths to handle_mmio() for PVH (hence
>> the ASSERT()). Sadly you provide way too little detail on what is
>> actually happening in your case: What's the use case of to-be-
>> emulated INS/OUTS in a PVH kernel?
> =

> In this specific situation I'm seeing intsw instructions executed by the
> FreeBSD ATA layer:
> =

> http://fxr.watson.org/fxr/source/dev/ata/ata-lowlevel.c#L740

Why are you running this device driver at all in a PVH guest?  It should
only be using PV block devices.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 11:24:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 11: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 1Xwqzw-00044K-PJ; Fri, 05 Dec 2014 11:24:32 +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 1Xwqzu-00044D-Jq
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 11:24:30 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	56/21-18267-DE591845; Fri, 05 Dec 2014 11:24:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417778667!7587444!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 13771 invoked from network); 5 Dec 2014 11:24:29 -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 Dec 2014 11:24:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200662436"
Message-ID: <548195EA.5050101@citrix.com>
Date: Fri, 5 Dec 2014 11:24:26 +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: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>, Jan Beulich
	<JBeulich@suse.com>
References: <54808D6F.302@citrix.com>	<548185DF020000780004D076@mail.emea.novell.com>
	<54819200.3010601@citrix.com>
In-Reply-To: <54819200.3010601@citrix.com>
Content-Length: 1340
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Removing the PVH assert in arch/x86/hvm/io.c:87
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 05/12/14 11:07, Roger Pau Monn=E9 wrote:
> El 05/12/14 a les 10.15, Jan Beulich ha escrit:
>>>>> On 04.12.14 at 17:35, <roger.pau@citrix.com> wrote:
>>> I've just stumbled upon this assert while testing PVH on different
>>> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
>>> and OUTS go through handle_mmio. So using this instructions from a PVH
>>> guest basically kills Xen.
>>>
>>> I've removed it and everything seems fine, so I'm considering sending a
>>> patch for 4.5 in order to have it removed. I think the path that could
>>> trigger the crash because of the missing vioapic stuff is already
>>> guarded by the other chunk added in the same patch.
>>
>> Iirc we settled on forbidding paths to handle_mmio() for PVH (hence
>> the ASSERT()). Sadly you provide way too little detail on what is
>> actually happening in your case: What's the use case of to-be-
>> emulated INS/OUTS in a PVH kernel?
> =

> In this specific situation I'm seeing intsw instructions executed by the
> FreeBSD ATA layer:
> =

> http://fxr.watson.org/fxr/source/dev/ata/ata-lowlevel.c#L740

Why are you running this device driver at all in a PVH guest?  It should
only be using PV block devices.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 11:26:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 11:26:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwr1l-0004Ea-CV; Fri, 05 Dec 2014 11:26: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 1Xwr1k-0004ET-P8
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 11:26:24 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	BB/2C-17694-06691845; Fri, 05 Dec 2014 11:26:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417778783!11255571!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21941 invoked from network); 5 Dec 2014 11:26:23 -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; 5 Dec 2014 11:26:23 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 11:26:22 +0000
Message-Id: <5481A46F020000780004D1C0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 11:26:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <54808D6F.302@citrix.com>
	<548185DF020000780004D076@mail.emea.novell.com>
	<54819200.3010601@citrix.com>
In-Reply-To: <54819200.3010601@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Removing the PVH assert in arch/x86/hvm/io.c:87
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 12:07, <roger.pau@citrix.com> wrote:
> El 05/12/14 a les 10.15, Jan Beulich ha escrit:
>>>>> On 04.12.14 at 17:35, <roger.pau@citrix.com> wrote:
>>> I've just stumbled upon this assert while testing PVH on different
>>> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
>>> and OUTS go through handle_mmio. So using this instructions from a PVH
>>> guest basically kills Xen.
>>>
>>> I've removed it and everything seems fine, so I'm considering sending a
>>> patch for 4.5 in order to have it removed. I think the path that could
>>> trigger the crash because of the missing vioapic stuff is already
>>> guarded by the other chunk added in the same patch.
>> 
>> Iirc we settled on forbidding paths to handle_mmio() for PVH (hence
>> the ASSERT()). Sadly you provide way too little detail on what is
>> actually happening in your case: What's the use case of to-be-
>> emulated INS/OUTS in a PVH kernel?
> 
> In this specific situation I'm seeing intsw instructions executed by the
> FreeBSD ATA layer:
> 
> http://fxr.watson.org/fxr/source/dev/ata/ata-lowlevel.c#L740 
> 
>> What's the call tree that gets
>> you into handle_mmio(), considering that both calls to
>> handle_mmio_with_translation() from hvm_hap_nested_page_fault()
>> as well as the one to handle_mmio() ought to be unreachable for PVH?
> 
> You can get there from vmx_vmexit_handler if the exit reason is
> EXIT_REASON_IO_INSTRUCTION.

A PVH guest without passed through device shouldn't access I/O
ports in the first place. Are you trying to hand an IDE or SATA
controller to the guest? Or is this happening with just Dom0, in
which case I'd suspect the I/O bitmap isn't being set up properly,
thus causing a VM exit when none is needed?

And yes, guarding the EXIT_REASON_IO_INSTRUCTION handling
in vmx_vmexit_handler() against PVH would seem necessary,
directing control flow to exit_and_crash. I'm pretty certain I had
pointed this out while reviewing the original PVH series.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 11:26:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 11:26:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwr1l-0004Ea-CV; Fri, 05 Dec 2014 11:26: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 1Xwr1k-0004ET-P8
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 11:26:24 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	BB/2C-17694-06691845; Fri, 05 Dec 2014 11:26:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417778783!11255571!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21941 invoked from network); 5 Dec 2014 11:26:23 -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; 5 Dec 2014 11:26:23 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 11:26:22 +0000
Message-Id: <5481A46F020000780004D1C0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 11:26:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <54808D6F.302@citrix.com>
	<548185DF020000780004D076@mail.emea.novell.com>
	<54819200.3010601@citrix.com>
In-Reply-To: <54819200.3010601@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Removing the PVH assert in arch/x86/hvm/io.c:87
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 12:07, <roger.pau@citrix.com> wrote:
> El 05/12/14 a les 10.15, Jan Beulich ha escrit:
>>>>> On 04.12.14 at 17:35, <roger.pau@citrix.com> wrote:
>>> I've just stumbled upon this assert while testing PVH on different
>>> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
>>> and OUTS go through handle_mmio. So using this instructions from a PVH
>>> guest basically kills Xen.
>>>
>>> I've removed it and everything seems fine, so I'm considering sending a
>>> patch for 4.5 in order to have it removed. I think the path that could
>>> trigger the crash because of the missing vioapic stuff is already
>>> guarded by the other chunk added in the same patch.
>> 
>> Iirc we settled on forbidding paths to handle_mmio() for PVH (hence
>> the ASSERT()). Sadly you provide way too little detail on what is
>> actually happening in your case: What's the use case of to-be-
>> emulated INS/OUTS in a PVH kernel?
> 
> In this specific situation I'm seeing intsw instructions executed by the
> FreeBSD ATA layer:
> 
> http://fxr.watson.org/fxr/source/dev/ata/ata-lowlevel.c#L740 
> 
>> What's the call tree that gets
>> you into handle_mmio(), considering that both calls to
>> handle_mmio_with_translation() from hvm_hap_nested_page_fault()
>> as well as the one to handle_mmio() ought to be unreachable for PVH?
> 
> You can get there from vmx_vmexit_handler if the exit reason is
> EXIT_REASON_IO_INSTRUCTION.

A PVH guest without passed through device shouldn't access I/O
ports in the first place. Are you trying to hand an IDE or SATA
controller to the guest? Or is this happening with just Dom0, in
which case I'd suspect the I/O bitmap isn't being set up properly,
thus causing a VM exit when none is needed?

And yes, guarding the EXIT_REASON_IO_INSTRUCTION handling
in vmx_vmexit_handler() against PVH would seem necessary,
directing control flow to exit_and_crash. I'm pretty certain I had
pointed this out while reviewing the original PVH series.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 11:31:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 11:31:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwr6L-0004Xh-Ns; Fri, 05 Dec 2014 11:31:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xwr6K-0004XW-Ty
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 11:31:09 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	6B/6B-24124-C7791845; Fri, 05 Dec 2014 11:31:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417779066!4161939!1
X-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 29518 invoked from network); 5 Dec 2014 11:31:06 -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; 5 Dec 2014 11:31:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 11:31:06 +0000
Message-Id: <5481A589020000780004D1E3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 11:31:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part43769B69.2__="
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] lock down hypercall continuation encoding masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part43769B69.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Andrew validly points out that even if these masks aren't a formal part
of the hypercall interface, we aren't free to change them: A guest
suspended for migration in the middle of a continuation would fail to
work if resumed on a hypervisor using a different value. Hence add
respective comments to their definitions.

Additionally, to help future extensibility as well as in the spirit of
reducing undefined behavior as much as possible, refuse hypercalls made
with the respective bits non-zero when the respective sub-ops don't
make use of those bits.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5458,16 +5458,34 @@ static int hvmop_destroy_ioreq_server(
     return rc;
 }
=20
+/*
+ * Note that this value is effectively part of the ABI, even if we don't =
need
+ * to make it a formal part of it: A guest suspended for migration in the
+ * middle of a continuation would fail to work if resumed on a hypervisor
+ * using a different value.
+ */
 #define HVMOP_op_mask 0xff
=20
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
=20
 {
     struct domain *curr_d =3D current->domain;
-    unsigned long start_iter =3D op & ~HVMOP_op_mask;
+    unsigned long start_iter, mask;
     long rc =3D 0;
=20
-    switch ( op &=3D HVMOP_op_mask )
+    switch ( op & HVMOP_op_mask )
+    {
+    default:
+        mask =3D ~0UL;
+        break;
+    case HVMOP_modified_memory:
+    case HVMOP_set_mem_type:
+        mask =3D HVMOP_op_mask;
+        break;
+    }
+
+    start_iter =3D op & ~mask;
+    switch ( op &=3D mask )
     {
     case HVMOP_create_ioreq_server:
         rc =3D hvmop_create_ioreq_server(
@@ -6120,7 +6138,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
=20
     if ( rc =3D=3D -ERESTART )
     {
-        ASSERT(!(start_iter & HVMOP_op_mask));
+        ASSERT(!(start_iter & mask));
         rc =3D hypercall_create_continuation(__HYPERVISOR_hvm_op, "lh",
                                            op | start_iter, arg);
     }
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4661,9 +4661,8 @@ int xenmem_add_to_physmap_one(
 long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int rc;
-    int op =3D cmd & MEMOP_CMD_MASK;
=20
-    switch ( op )
+    switch ( cmd )
     {
     case XENMEM_set_memory_map:
     {
@@ -4837,7 +4836,7 @@ long arch_memory_op(unsigned long cmd, X
         if ( d =3D=3D NULL )
             return -ESRCH;
=20
-        if ( op =3D=3D XENMEM_set_pod_target )
+        if ( cmd =3D=3D XENMEM_set_pod_target )
             rc =3D xsm_set_pod_target(XSM_PRIV, d);
         else
             rc =3D xsm_get_pod_target(XSM_PRIV, d);
@@ -4845,7 +4844,7 @@ long arch_memory_op(unsigned long cmd, X
         if ( rc !=3D 0 )
             goto pod_target_out_unlock;
=20
-        if ( op =3D=3D XENMEM_set_pod_target )
+        if ( cmd =3D=3D XENMEM_set_pod_target )
         {
             if ( target.target_pages > d->max_pages )
             {
@@ -4859,7 +4858,7 @@ long arch_memory_op(unsigned long cmd, X
         if ( rc =3D=3D -ERESTART )
         {
             rc =3D hypercall_create_continuation(
-                __HYPERVISOR_memory_op, "lh", op, arg);
+                __HYPERVISOR_memory_op, "lh", cmd, arg);
         }
         else if ( rc >=3D 0 )
         {
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -53,9 +53,8 @@ int compat_arch_memory_op(unsigned long=20
     compat_pfn_t mfn;
     unsigned int i;
     int rc =3D 0;
-    int op =3D cmd & MEMOP_CMD_MASK;
=20
-    switch ( op )
+    switch ( cmd )
     {
     case XENMEM_set_memory_map:
     {
@@ -192,7 +191,7 @@ int compat_arch_memory_op(unsigned long=20
         xen_mem_event_op_t meo;
         if ( copy_from_guest(&meo, arg, 1) )
             return -EFAULT;
-        rc =3D do_mem_event_op(op, meo.domain, (void *) &meo);
+        rc =3D do_mem_event_op(cmd, meo.domain, &meo);
         if ( !rc && __copy_to_guest(arg, &meo, 1) )
             return -EFAULT;
         break;
@@ -205,7 +204,7 @@ int compat_arch_memory_op(unsigned long=20
             return -EFAULT;
         if ( mso.op =3D=3D XENMEM_sharing_op_audit )
             return mem_sharing_audit();=20
-        rc =3D do_mem_event_op(op, mso.domain, (void *) &mso);
+        rc =3D do_mem_event_op(cmd, mso.domain, &mso);
         if ( !rc && __copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
         break;
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -906,9 +906,8 @@ long subarch_memory_op(unsigned long cmd
     xen_pfn_t mfn, last_mfn;
     unsigned int i;
     long rc =3D 0;
-    int op =3D cmd & MEMOP_CMD_MASK;
=20
-    switch ( op )
+    switch ( cmd )
     {
     case XENMEM_machphys_mfn_list:
         if ( copy_from_guest(&xmml, arg, 1) )
@@ -989,7 +988,7 @@ long subarch_memory_op(unsigned long cmd
         xen_mem_event_op_t meo;
         if ( copy_from_guest(&meo, arg, 1) )
             return -EFAULT;
-        rc =3D do_mem_event_op(op, meo.domain, (void *) &meo);
+        rc =3D do_mem_event_op(cmd, meo.domain, &meo);
         if ( !rc && __copy_to_guest(arg, &meo, 1) )
             return -EFAULT;
         break;
@@ -1002,7 +1001,7 @@ long subarch_memory_op(unsigned long cmd
             return -EFAULT;
         if ( mso.op =3D=3D XENMEM_sharing_op_audit )
             return mem_sharing_audit();=20
-        rc =3D do_mem_event_op(op, mso.domain, (void *) &mso);
+        rc =3D do_mem_event_op(cmd, mso.domain, &mso);
         if ( !rc && __copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
         break;
--- a/xen/common/compat/grant_table.c
+++ b/xen/common/compat/grant_table.c
@@ -65,6 +65,8 @@ int compat_grant_table_op(unsigned int c
=20
     set_xen_guest_handle(cnt_uop, NULL);
     cmd_op =3D cmd & GNTTABOP_CMD_MASK;
+    if ( cmd_op !=3D GNTTABOP_cache_flush )
+        cmd_op =3D cmd;
     switch ( cmd_op )
     {
 #define CASE(name) \
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -62,6 +62,12 @@ integer_param("gnttab_max_frames", max_g
 static unsigned int __read_mostly max_maptrack_frames;
 integer_param("gnttab_max_maptrack_frames", max_maptrack_frames);
=20
+/*
+ * Note that the three values below are effectively part of the ABI, even =
if
+ * we don't need to make them a formal part of it: A guest suspended for
+ * migration in the middle of a continuation would fail to work if =
resumed on
+ * a hypervisor using different values.
+ */
 #define GNTTABOP_CONTINUATION_ARG_SHIFT 12
 #define GNTTABOP_CMD_MASK               ((1<<GNTTABOP_CONTINUATION_ARG_SHI=
FT)-1)
 #define GNTTABOP_ARG_MASK               (~GNTTABOP_CMD_MASK)
@@ -2624,9 +2630,12 @@ do_grant_table_op(
    =20
     if ( (int)count < 0 )
         return -EINVAL;
+
+    if ( (cmd &=3D GNTTABOP_CMD_MASK) !=3D GNTTABOP_cache_flush && =
opaque_in )
+        return -ENOSYS;
    =20
     rc =3D -EFAULT;
-    switch ( cmd &=3D GNTTABOP_CMD_MASK )
+    switch ( cmd )
     {
     case GNTTABOP_map_grant_ref:
     {
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -58,6 +58,7 @@ void mem_access_resume(struct domain *d)
 int mem_access_memop(unsigned long cmd,
                      XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg)
 {
+    unsigned long start_iter =3D cmd & ~MEMOP_CMD_MASK;
     long rc;
     xen_mem_access_op_t mao;
     struct domain *d;
@@ -84,14 +85,16 @@ int mem_access_memop(unsigned long cmd,
     switch ( mao.op )
     {
     case XENMEM_access_op_resume:
-        mem_access_resume(d);
-        rc =3D 0;
+        if ( unlikely(start_iter) )
+            rc =3D -ENOSYS;
+        else
+        {
+            mem_access_resume(d);
+            rc =3D 0;
+        }
         break;
=20
     case XENMEM_access_op_set_access:
-    {
-        unsigned long start_iter =3D cmd & ~MEMOP_CMD_MASK;
-
         rc =3D -EINVAL;
         if ( (mao.pfn !=3D ~0ull) &&
              (mao.nr < start_iter ||
@@ -108,12 +111,15 @@ int mem_access_memop(unsigned long cmd,
                                                XENMEM_access_op | rc, =
arg);
         }
         break;
-    }
=20
     case XENMEM_access_op_get_access:
     {
         xenmem_access_t access;
=20
+        rc =3D -ENOSYS;
+        if ( unlikely(start_iter) )
+            break;
+
         rc =3D -EINVAL;
         if ( (mao.pfn > domain_get_maximum_gpfn(d)) && mao.pfn !=3D ~0ull =
)
             break;
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -779,16 +779,25 @@ long do_memory_op(unsigned long cmd, XEN
         break;
=20
     case XENMEM_exchange:
+        if ( unlikely(start_extent) )
+            return -ENOSYS;
+
         rc =3D memory_exchange(guest_handle_cast(arg, xen_memory_exchange_=
t));
         break;
=20
     case XENMEM_maximum_ram_page:
+        if ( unlikely(start_extent) )
+            return -ENOSYS;
+
         rc =3D max_page;
         break;
=20
     case XENMEM_current_reservation:
     case XENMEM_maximum_reservation:
     case XENMEM_maximum_gpfn:
+        if ( unlikely(start_extent) )
+            return -ENOSYS;
+
         if ( copy_from_guest(&domid, arg, 1) )
             return -EFAULT;
=20
@@ -912,6 +921,9 @@ long do_memory_op(unsigned long cmd, XEN
         struct page_info *page;
         struct domain *d;
=20
+        if ( unlikely(start_extent) )
+            return -ENOSYS;
+
         if ( copy_from_guest(&xrfp, arg, 1) )
             return -EFAULT;
=20
@@ -945,6 +957,9 @@ long do_memory_op(unsigned long cmd, XEN
         break;
=20
     case XENMEM_claim_pages:
+        if ( unlikely(start_extent) )
+            return -ENOSYS;
+
         if ( copy_from_guest(&reservation, arg, 1) )
             return -EFAULT;
=20
@@ -977,6 +992,9 @@ long do_memory_op(unsigned long cmd, XEN
         unsigned int dom_vnodes, dom_vranges, dom_vcpus;
         struct vnuma_info tmp;
=20
+        if ( unlikely(start_extent) )
+            return -ENOSYS;
+
         /*
          * Guest passes nr_vnodes, number of regions and nr_vcpus thus
          * we know how much memory guest has allocated.
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -57,6 +57,11 @@ do_platform_op(
  * To allow safe resume of do_memory_op() after preemption, we need to =
know
  * at what point in the page list to resume. For this purpose I steal the
  * high-order bits of the @cmd parameter, which are otherwise unused and =
zero.
+ *
+ * Note that both of these values are effectively part of the ABI, even =
if
+ * we don't need to make them a formal part of it: A guest suspended for
+ * migration in the middle of a continuation would fail to work if =
resumed on
+ * a hypervisor using different values.
  */
 #define MEMOP_EXTENT_SHIFT 6 /* cmd[:6] =3D=3D start_extent */
 #define MEMOP_CMD_MASK     ((1 << MEMOP_EXTENT_SHIFT) - 1)



--=__Part43769B69.2__=
Content-Type: text/plain; name="continuation-masks.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="continuation-masks.patch"

lock down hypercall continuation encoding masks=0A=0AAndrew validly points =
out that even if these masks aren't a formal part=0Aof the hypercall =
interface, we aren't free to change them: A guest=0Asuspended for =
migration in the middle of a continuation would fail to=0Awork if resumed =
on a hypervisor using a different value. Hence add=0Arespective comments =
to their definitions.=0A=0AAdditionally, to help future extensibility as =
well as in the spirit of=0Areducing undefined behavior as much as =
possible, refuse hypercalls made=0Awith the respective bits non-zero when =
the respective sub-ops don't=0Amake use of those bits.=0A=0AReported-by: =
Andrew Cooper <andrew.cooper3@citrix.com>=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ b/xen/arch/x86/=
hvm/hvm.c=0A@@ -5458,16 +5458,34 @@ static int hvmop_destroy_ioreq_server(=
=0A     return rc;=0A }=0A =0A+/*=0A+ * Note that this value is effectively=
 part of the ABI, even if we don't need=0A+ * to make it a formal part of =
it: A guest suspended for migration in the=0A+ * middle of a continuation =
would fail to work if resumed on a hypervisor=0A+ * using a different =
value.=0A+ */=0A #define HVMOP_op_mask 0xff=0A =0A long do_hvm_op(unsigned =
long op, XEN_GUEST_HANDLE_PARAM(void) arg)=0A =0A {=0A     struct domain =
*curr_d =3D current->domain;=0A-    unsigned long start_iter =3D op & =
~HVMOP_op_mask;=0A+    unsigned long start_iter, mask;=0A     long rc =3D =
0;=0A =0A-    switch ( op &=3D HVMOP_op_mask )=0A+    switch ( op & =
HVMOP_op_mask )=0A+    {=0A+    default:=0A+        mask =3D ~0UL;=0A+     =
   break;=0A+    case HVMOP_modified_memory:=0A+    case HVMOP_set_mem_type=
:=0A+        mask =3D HVMOP_op_mask;=0A+        break;=0A+    }=0A+=0A+    =
start_iter =3D op & ~mask;=0A+    switch ( op &=3D mask )=0A     {=0A     =
case HVMOP_create_ioreq_server:=0A         rc =3D hvmop_create_ioreq_server=
(=0A@@ -6120,7 +6138,7 @@ long do_hvm_op(unsigned long op, XEN_GUE=0A =0A  =
   if ( rc =3D=3D -ERESTART )=0A     {=0A-        ASSERT(!(start_iter & =
HVMOP_op_mask));=0A+        ASSERT(!(start_iter & mask));=0A         rc =
=3D hypercall_create_continuation(__HYPERVISOR_hvm_op, "lh",=0A            =
                                op | start_iter, arg);=0A     }=0A--- =
a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -4661,9 +4661,8 @@ int =
xenmem_add_to_physmap_one(=0A long arch_memory_op(unsigned long cmd, =
XEN_GUEST_HANDLE_PARAM(void) arg)=0A {=0A     int rc;=0A-    int op =3D =
cmd & MEMOP_CMD_MASK;=0A =0A-    switch ( op )=0A+    switch ( cmd )=0A    =
 {=0A     case XENMEM_set_memory_map:=0A     {=0A@@ -4837,7 +4836,7 @@ =
long arch_memory_op(unsigned long cmd, X=0A         if ( d =3D=3D NULL =
)=0A             return -ESRCH;=0A =0A-        if ( op =3D=3D XENMEM_set_po=
d_target )=0A+        if ( cmd =3D=3D XENMEM_set_pod_target )=0A           =
  rc =3D xsm_set_pod_target(XSM_PRIV, d);=0A         else=0A             =
rc =3D xsm_get_pod_target(XSM_PRIV, d);=0A@@ -4845,7 +4844,7 @@ long =
arch_memory_op(unsigned long cmd, X=0A         if ( rc !=3D 0 )=0A         =
    goto pod_target_out_unlock;=0A =0A-        if ( op =3D=3D XENMEM_set_po=
d_target )=0A+        if ( cmd =3D=3D XENMEM_set_pod_target )=0A         =
{=0A             if ( target.target_pages > d->max_pages )=0A             =
{=0A@@ -4859,7 +4858,7 @@ long arch_memory_op(unsigned long cmd, X=0A      =
   if ( rc =3D=3D -ERESTART )=0A         {=0A             rc =3D hypercall_=
create_continuation(=0A-                __HYPERVISOR_memory_op, "lh", op, =
arg);=0A+                __HYPERVISOR_memory_op, "lh", cmd, arg);=0A       =
  }=0A         else if ( rc >=3D 0 )=0A         {=0A--- a/xen/arch/x86/x86_=
64/compat/mm.c=0A+++ b/xen/arch/x86/x86_64/compat/mm.c=0A@@ -53,9 +53,8 @@ =
int compat_arch_memory_op(unsigned long =0A     compat_pfn_t mfn;=0A     =
unsigned int i;=0A     int rc =3D 0;=0A-    int op =3D cmd & MEMOP_CMD_MASK=
;=0A =0A-    switch ( op )=0A+    switch ( cmd )=0A     {=0A     case =
XENMEM_set_memory_map:=0A     {=0A@@ -192,7 +191,7 @@ int compat_arch_memor=
y_op(unsigned long =0A         xen_mem_event_op_t meo;=0A         if ( =
copy_from_guest(&meo, arg, 1) )=0A             return -EFAULT;=0A-        =
rc =3D do_mem_event_op(op, meo.domain, (void *) &meo);=0A+        rc =3D =
do_mem_event_op(cmd, meo.domain, &meo);=0A         if ( !rc && __copy_to_gu=
est(arg, &meo, 1) )=0A             return -EFAULT;=0A         break;=0A@@ =
-205,7 +204,7 @@ int compat_arch_memory_op(unsigned long =0A             =
return -EFAULT;=0A         if ( mso.op =3D=3D XENMEM_sharing_op_audit )=0A =
            return mem_sharing_audit(); =0A-        rc =3D do_mem_event_op(=
op, mso.domain, (void *) &mso);=0A+        rc =3D do_mem_event_op(cmd, =
mso.domain, &mso);=0A         if ( !rc && __copy_to_guest(arg, &mso, 1) =
)=0A             return -EFAULT;=0A         break;=0A--- a/xen/arch/x86/x86=
_64/mm.c=0A+++ b/xen/arch/x86/x86_64/mm.c=0A@@ -906,9 +906,8 @@ long =
subarch_memory_op(unsigned long cmd=0A     xen_pfn_t mfn, last_mfn;=0A     =
unsigned int i;=0A     long rc =3D 0;=0A-    int op =3D cmd & MEMOP_CMD_MAS=
K;=0A =0A-    switch ( op )=0A+    switch ( cmd )=0A     {=0A     case =
XENMEM_machphys_mfn_list:=0A         if ( copy_from_guest(&xmml, arg, 1) =
)=0A@@ -989,7 +988,7 @@ long subarch_memory_op(unsigned long cmd=0A        =
 xen_mem_event_op_t meo;=0A         if ( copy_from_guest(&meo, arg, 1) =
)=0A             return -EFAULT;=0A-        rc =3D do_mem_event_op(op, =
meo.domain, (void *) &meo);=0A+        rc =3D do_mem_event_op(cmd, =
meo.domain, &meo);=0A         if ( !rc && __copy_to_guest(arg, &meo, 1) =
)=0A             return -EFAULT;=0A         break;=0A@@ -1002,7 +1001,7 @@ =
long subarch_memory_op(unsigned long cmd=0A             return -EFAULT;=0A =
        if ( mso.op =3D=3D XENMEM_sharing_op_audit )=0A             return =
mem_sharing_audit(); =0A-        rc =3D do_mem_event_op(op, mso.domain, =
(void *) &mso);=0A+        rc =3D do_mem_event_op(cmd, mso.domain, =
&mso);=0A         if ( !rc && __copy_to_guest(arg, &mso, 1) )=0A           =
  return -EFAULT;=0A         break;=0A--- a/xen/common/compat/grant_table.c=
=0A+++ b/xen/common/compat/grant_table.c=0A@@ -65,6 +65,8 @@ int compat_gra=
nt_table_op(unsigned int c=0A =0A     set_xen_guest_handle(cnt_uop, =
NULL);=0A     cmd_op =3D cmd & GNTTABOP_CMD_MASK;=0A+    if ( cmd_op !=3D =
GNTTABOP_cache_flush )=0A+        cmd_op =3D cmd;=0A     switch ( cmd_op =
)=0A     {=0A #define CASE(name) \=0A--- a/xen/common/grant_table.c=0A+++ =
b/xen/common/grant_table.c=0A@@ -62,6 +62,12 @@ integer_param("gnttab_max_f=
rames", max_g=0A static unsigned int __read_mostly max_maptrack_frames;=0A =
integer_param("gnttab_max_maptrack_frames", max_maptrack_frames);=0A =
=0A+/*=0A+ * Note that the three values below are effectively part of the =
ABI, even if=0A+ * we don't need to make them a formal part of it: A guest =
suspended for=0A+ * migration in the middle of a continuation would fail =
to work if resumed on=0A+ * a hypervisor using different values.=0A+ */=0A =
#define GNTTABOP_CONTINUATION_ARG_SHIFT 12=0A #define GNTTABOP_CMD_MASK    =
           ((1<<GNTTABOP_CONTINUATION_ARG_SHIFT)-1)=0A #define GNTTABOP_ARG=
_MASK               (~GNTTABOP_CMD_MASK)=0A@@ -2624,9 +2630,12 @@ =
do_grant_table_op(=0A     =0A     if ( (int)count < 0 )=0A         return =
-EINVAL;=0A+=0A+    if ( (cmd &=3D GNTTABOP_CMD_MASK) !=3D GNTTABOP_cache_f=
lush && opaque_in )=0A+        return -ENOSYS;=0A     =0A     rc =3D =
-EFAULT;=0A-    switch ( cmd &=3D GNTTABOP_CMD_MASK )=0A+    switch ( cmd =
)=0A     {=0A     case GNTTABOP_map_grant_ref:=0A     {=0A--- a/xen/common/=
mem_access.c=0A+++ b/xen/common/mem_access.c=0A@@ -58,6 +58,7 @@ void =
mem_access_resume(struct domain *d)=0A int mem_access_memop(unsigned long =
cmd,=0A                      XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) =
arg)=0A {=0A+    unsigned long start_iter =3D cmd & ~MEMOP_CMD_MASK;=0A    =
 long rc;=0A     xen_mem_access_op_t mao;=0A     struct domain *d;=0A@@ =
-84,14 +85,16 @@ int mem_access_memop(unsigned long cmd,=0A     switch ( =
mao.op )=0A     {=0A     case XENMEM_access_op_resume:=0A-        =
mem_access_resume(d);=0A-        rc =3D 0;=0A+        if ( unlikely(start_i=
ter) )=0A+            rc =3D -ENOSYS;=0A+        else=0A+        {=0A+     =
       mem_access_resume(d);=0A+            rc =3D 0;=0A+        }=0A      =
   break;=0A =0A     case XENMEM_access_op_set_access:=0A-    {=0A-        =
unsigned long start_iter =3D cmd & ~MEMOP_CMD_MASK;=0A-=0A         rc =3D =
-EINVAL;=0A         if ( (mao.pfn !=3D ~0ull) &&=0A              (mao.nr < =
start_iter ||=0A@@ -108,12 +111,15 @@ int mem_access_memop(unsigned long =
cmd,=0A                                                XENMEM_access_op | =
rc, arg);=0A         }=0A         break;=0A-    }=0A =0A     case =
XENMEM_access_op_get_access:=0A     {=0A         xenmem_access_t access;=0A=
 =0A+        rc =3D -ENOSYS;=0A+        if ( unlikely(start_iter) )=0A+    =
        break;=0A+=0A         rc =3D -EINVAL;=0A         if ( (mao.pfn > =
domain_get_maximum_gpfn(d)) && mao.pfn !=3D ~0ull )=0A             =
break;=0A--- a/xen/common/memory.c=0A+++ b/xen/common/memory.c=0A@@ =
-779,16 +779,25 @@ long do_memory_op(unsigned long cmd, XEN=0A         =
break;=0A =0A     case XENMEM_exchange:=0A+        if ( unlikely(start_exte=
nt) )=0A+            return -ENOSYS;=0A+=0A         rc =3D memory_exchange(=
guest_handle_cast(arg, xen_memory_exchange_t));=0A         break;=0A =0A   =
  case XENMEM_maximum_ram_page:=0A+        if ( unlikely(start_extent) =
)=0A+            return -ENOSYS;=0A+=0A         rc =3D max_page;=0A        =
 break;=0A =0A     case XENMEM_current_reservation:=0A     case XENMEM_maxi=
mum_reservation:=0A     case XENMEM_maximum_gpfn:=0A+        if ( =
unlikely(start_extent) )=0A+            return -ENOSYS;=0A+=0A         if =
( copy_from_guest(&domid, arg, 1) )=0A             return -EFAULT;=0A =
=0A@@ -912,6 +921,9 @@ long do_memory_op(unsigned long cmd, XEN=0A         =
struct page_info *page;=0A         struct domain *d;=0A =0A+        if ( =
unlikely(start_extent) )=0A+            return -ENOSYS;=0A+=0A         if =
( copy_from_guest(&xrfp, arg, 1) )=0A             return -EFAULT;=0A =0A@@ =
-945,6 +957,9 @@ long do_memory_op(unsigned long cmd, XEN=0A         =
break;=0A =0A     case XENMEM_claim_pages:=0A+        if ( unlikely(start_e=
xtent) )=0A+            return -ENOSYS;=0A+=0A         if ( copy_from_guest=
(&reservation, arg, 1) )=0A             return -EFAULT;=0A =0A@@ -977,6 =
+992,9 @@ long do_memory_op(unsigned long cmd, XEN=0A         unsigned int =
dom_vnodes, dom_vranges, dom_vcpus;=0A         struct vnuma_info tmp;=0A =
=0A+        if ( unlikely(start_extent) )=0A+            return -ENOSYS;=0A=
+=0A         /*=0A          * Guest passes nr_vnodes, number of regions =
and nr_vcpus thus=0A          * we know how much memory guest has =
allocated.=0A--- a/xen/include/xen/hypercall.h=0A+++ b/xen/include/xen/hype=
rcall.h=0A@@ -57,6 +57,11 @@ do_platform_op(=0A  * To allow safe resume of =
do_memory_op() after preemption, we need to know=0A  * at what point in =
the page list to resume. For this purpose I steal the=0A  * high-order =
bits of the @cmd parameter, which are otherwise unused and zero.=0A+ *=0A+ =
* Note that both of these values are effectively part of the ABI, even =
if=0A+ * we don't need to make them a formal part of it: A guest suspended =
for=0A+ * migration in the middle of a continuation would fail to work if =
resumed on=0A+ * a hypervisor using different values.=0A  */=0A #define =
MEMOP_EXTENT_SHIFT 6 /* cmd[:6] =3D=3D start_extent */=0A #define =
MEMOP_CMD_MASK     ((1 << MEMOP_EXTENT_SHIFT) - 1)=0A
--=__Part43769B69.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

--=__Part43769B69.2__=--


From xen-devel-bounces@lists.xen.org Fri Dec 05 11:31:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 11:31:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwr6L-0004Xh-Ns; Fri, 05 Dec 2014 11:31:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xwr6K-0004XW-Ty
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 11:31:09 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	6B/6B-24124-C7791845; Fri, 05 Dec 2014 11:31:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417779066!4161939!1
X-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 29518 invoked from network); 5 Dec 2014 11:31:06 -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; 5 Dec 2014 11:31:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 11:31:06 +0000
Message-Id: <5481A589020000780004D1E3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 11:31:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part43769B69.2__="
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] lock down hypercall continuation encoding masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part43769B69.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Andrew validly points out that even if these masks aren't a formal part
of the hypercall interface, we aren't free to change them: A guest
suspended for migration in the middle of a continuation would fail to
work if resumed on a hypervisor using a different value. Hence add
respective comments to their definitions.

Additionally, to help future extensibility as well as in the spirit of
reducing undefined behavior as much as possible, refuse hypercalls made
with the respective bits non-zero when the respective sub-ops don't
make use of those bits.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5458,16 +5458,34 @@ static int hvmop_destroy_ioreq_server(
     return rc;
 }
=20
+/*
+ * Note that this value is effectively part of the ABI, even if we don't =
need
+ * to make it a formal part of it: A guest suspended for migration in the
+ * middle of a continuation would fail to work if resumed on a hypervisor
+ * using a different value.
+ */
 #define HVMOP_op_mask 0xff
=20
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
=20
 {
     struct domain *curr_d =3D current->domain;
-    unsigned long start_iter =3D op & ~HVMOP_op_mask;
+    unsigned long start_iter, mask;
     long rc =3D 0;
=20
-    switch ( op &=3D HVMOP_op_mask )
+    switch ( op & HVMOP_op_mask )
+    {
+    default:
+        mask =3D ~0UL;
+        break;
+    case HVMOP_modified_memory:
+    case HVMOP_set_mem_type:
+        mask =3D HVMOP_op_mask;
+        break;
+    }
+
+    start_iter =3D op & ~mask;
+    switch ( op &=3D mask )
     {
     case HVMOP_create_ioreq_server:
         rc =3D hvmop_create_ioreq_server(
@@ -6120,7 +6138,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
=20
     if ( rc =3D=3D -ERESTART )
     {
-        ASSERT(!(start_iter & HVMOP_op_mask));
+        ASSERT(!(start_iter & mask));
         rc =3D hypercall_create_continuation(__HYPERVISOR_hvm_op, "lh",
                                            op | start_iter, arg);
     }
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4661,9 +4661,8 @@ int xenmem_add_to_physmap_one(
 long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int rc;
-    int op =3D cmd & MEMOP_CMD_MASK;
=20
-    switch ( op )
+    switch ( cmd )
     {
     case XENMEM_set_memory_map:
     {
@@ -4837,7 +4836,7 @@ long arch_memory_op(unsigned long cmd, X
         if ( d =3D=3D NULL )
             return -ESRCH;
=20
-        if ( op =3D=3D XENMEM_set_pod_target )
+        if ( cmd =3D=3D XENMEM_set_pod_target )
             rc =3D xsm_set_pod_target(XSM_PRIV, d);
         else
             rc =3D xsm_get_pod_target(XSM_PRIV, d);
@@ -4845,7 +4844,7 @@ long arch_memory_op(unsigned long cmd, X
         if ( rc !=3D 0 )
             goto pod_target_out_unlock;
=20
-        if ( op =3D=3D XENMEM_set_pod_target )
+        if ( cmd =3D=3D XENMEM_set_pod_target )
         {
             if ( target.target_pages > d->max_pages )
             {
@@ -4859,7 +4858,7 @@ long arch_memory_op(unsigned long cmd, X
         if ( rc =3D=3D -ERESTART )
         {
             rc =3D hypercall_create_continuation(
-                __HYPERVISOR_memory_op, "lh", op, arg);
+                __HYPERVISOR_memory_op, "lh", cmd, arg);
         }
         else if ( rc >=3D 0 )
         {
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -53,9 +53,8 @@ int compat_arch_memory_op(unsigned long=20
     compat_pfn_t mfn;
     unsigned int i;
     int rc =3D 0;
-    int op =3D cmd & MEMOP_CMD_MASK;
=20
-    switch ( op )
+    switch ( cmd )
     {
     case XENMEM_set_memory_map:
     {
@@ -192,7 +191,7 @@ int compat_arch_memory_op(unsigned long=20
         xen_mem_event_op_t meo;
         if ( copy_from_guest(&meo, arg, 1) )
             return -EFAULT;
-        rc =3D do_mem_event_op(op, meo.domain, (void *) &meo);
+        rc =3D do_mem_event_op(cmd, meo.domain, &meo);
         if ( !rc && __copy_to_guest(arg, &meo, 1) )
             return -EFAULT;
         break;
@@ -205,7 +204,7 @@ int compat_arch_memory_op(unsigned long=20
             return -EFAULT;
         if ( mso.op =3D=3D XENMEM_sharing_op_audit )
             return mem_sharing_audit();=20
-        rc =3D do_mem_event_op(op, mso.domain, (void *) &mso);
+        rc =3D do_mem_event_op(cmd, mso.domain, &mso);
         if ( !rc && __copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
         break;
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -906,9 +906,8 @@ long subarch_memory_op(unsigned long cmd
     xen_pfn_t mfn, last_mfn;
     unsigned int i;
     long rc =3D 0;
-    int op =3D cmd & MEMOP_CMD_MASK;
=20
-    switch ( op )
+    switch ( cmd )
     {
     case XENMEM_machphys_mfn_list:
         if ( copy_from_guest(&xmml, arg, 1) )
@@ -989,7 +988,7 @@ long subarch_memory_op(unsigned long cmd
         xen_mem_event_op_t meo;
         if ( copy_from_guest(&meo, arg, 1) )
             return -EFAULT;
-        rc =3D do_mem_event_op(op, meo.domain, (void *) &meo);
+        rc =3D do_mem_event_op(cmd, meo.domain, &meo);
         if ( !rc && __copy_to_guest(arg, &meo, 1) )
             return -EFAULT;
         break;
@@ -1002,7 +1001,7 @@ long subarch_memory_op(unsigned long cmd
             return -EFAULT;
         if ( mso.op =3D=3D XENMEM_sharing_op_audit )
             return mem_sharing_audit();=20
-        rc =3D do_mem_event_op(op, mso.domain, (void *) &mso);
+        rc =3D do_mem_event_op(cmd, mso.domain, &mso);
         if ( !rc && __copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
         break;
--- a/xen/common/compat/grant_table.c
+++ b/xen/common/compat/grant_table.c
@@ -65,6 +65,8 @@ int compat_grant_table_op(unsigned int c
=20
     set_xen_guest_handle(cnt_uop, NULL);
     cmd_op =3D cmd & GNTTABOP_CMD_MASK;
+    if ( cmd_op !=3D GNTTABOP_cache_flush )
+        cmd_op =3D cmd;
     switch ( cmd_op )
     {
 #define CASE(name) \
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -62,6 +62,12 @@ integer_param("gnttab_max_frames", max_g
 static unsigned int __read_mostly max_maptrack_frames;
 integer_param("gnttab_max_maptrack_frames", max_maptrack_frames);
=20
+/*
+ * Note that the three values below are effectively part of the ABI, even =
if
+ * we don't need to make them a formal part of it: A guest suspended for
+ * migration in the middle of a continuation would fail to work if =
resumed on
+ * a hypervisor using different values.
+ */
 #define GNTTABOP_CONTINUATION_ARG_SHIFT 12
 #define GNTTABOP_CMD_MASK               ((1<<GNTTABOP_CONTINUATION_ARG_SHI=
FT)-1)
 #define GNTTABOP_ARG_MASK               (~GNTTABOP_CMD_MASK)
@@ -2624,9 +2630,12 @@ do_grant_table_op(
    =20
     if ( (int)count < 0 )
         return -EINVAL;
+
+    if ( (cmd &=3D GNTTABOP_CMD_MASK) !=3D GNTTABOP_cache_flush && =
opaque_in )
+        return -ENOSYS;
    =20
     rc =3D -EFAULT;
-    switch ( cmd &=3D GNTTABOP_CMD_MASK )
+    switch ( cmd )
     {
     case GNTTABOP_map_grant_ref:
     {
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -58,6 +58,7 @@ void mem_access_resume(struct domain *d)
 int mem_access_memop(unsigned long cmd,
                      XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg)
 {
+    unsigned long start_iter =3D cmd & ~MEMOP_CMD_MASK;
     long rc;
     xen_mem_access_op_t mao;
     struct domain *d;
@@ -84,14 +85,16 @@ int mem_access_memop(unsigned long cmd,
     switch ( mao.op )
     {
     case XENMEM_access_op_resume:
-        mem_access_resume(d);
-        rc =3D 0;
+        if ( unlikely(start_iter) )
+            rc =3D -ENOSYS;
+        else
+        {
+            mem_access_resume(d);
+            rc =3D 0;
+        }
         break;
=20
     case XENMEM_access_op_set_access:
-    {
-        unsigned long start_iter =3D cmd & ~MEMOP_CMD_MASK;
-
         rc =3D -EINVAL;
         if ( (mao.pfn !=3D ~0ull) &&
              (mao.nr < start_iter ||
@@ -108,12 +111,15 @@ int mem_access_memop(unsigned long cmd,
                                                XENMEM_access_op | rc, =
arg);
         }
         break;
-    }
=20
     case XENMEM_access_op_get_access:
     {
         xenmem_access_t access;
=20
+        rc =3D -ENOSYS;
+        if ( unlikely(start_iter) )
+            break;
+
         rc =3D -EINVAL;
         if ( (mao.pfn > domain_get_maximum_gpfn(d)) && mao.pfn !=3D ~0ull =
)
             break;
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -779,16 +779,25 @@ long do_memory_op(unsigned long cmd, XEN
         break;
=20
     case XENMEM_exchange:
+        if ( unlikely(start_extent) )
+            return -ENOSYS;
+
         rc =3D memory_exchange(guest_handle_cast(arg, xen_memory_exchange_=
t));
         break;
=20
     case XENMEM_maximum_ram_page:
+        if ( unlikely(start_extent) )
+            return -ENOSYS;
+
         rc =3D max_page;
         break;
=20
     case XENMEM_current_reservation:
     case XENMEM_maximum_reservation:
     case XENMEM_maximum_gpfn:
+        if ( unlikely(start_extent) )
+            return -ENOSYS;
+
         if ( copy_from_guest(&domid, arg, 1) )
             return -EFAULT;
=20
@@ -912,6 +921,9 @@ long do_memory_op(unsigned long cmd, XEN
         struct page_info *page;
         struct domain *d;
=20
+        if ( unlikely(start_extent) )
+            return -ENOSYS;
+
         if ( copy_from_guest(&xrfp, arg, 1) )
             return -EFAULT;
=20
@@ -945,6 +957,9 @@ long do_memory_op(unsigned long cmd, XEN
         break;
=20
     case XENMEM_claim_pages:
+        if ( unlikely(start_extent) )
+            return -ENOSYS;
+
         if ( copy_from_guest(&reservation, arg, 1) )
             return -EFAULT;
=20
@@ -977,6 +992,9 @@ long do_memory_op(unsigned long cmd, XEN
         unsigned int dom_vnodes, dom_vranges, dom_vcpus;
         struct vnuma_info tmp;
=20
+        if ( unlikely(start_extent) )
+            return -ENOSYS;
+
         /*
          * Guest passes nr_vnodes, number of regions and nr_vcpus thus
          * we know how much memory guest has allocated.
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -57,6 +57,11 @@ do_platform_op(
  * To allow safe resume of do_memory_op() after preemption, we need to =
know
  * at what point in the page list to resume. For this purpose I steal the
  * high-order bits of the @cmd parameter, which are otherwise unused and =
zero.
+ *
+ * Note that both of these values are effectively part of the ABI, even =
if
+ * we don't need to make them a formal part of it: A guest suspended for
+ * migration in the middle of a continuation would fail to work if =
resumed on
+ * a hypervisor using different values.
  */
 #define MEMOP_EXTENT_SHIFT 6 /* cmd[:6] =3D=3D start_extent */
 #define MEMOP_CMD_MASK     ((1 << MEMOP_EXTENT_SHIFT) - 1)



--=__Part43769B69.2__=
Content-Type: text/plain; name="continuation-masks.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="continuation-masks.patch"

lock down hypercall continuation encoding masks=0A=0AAndrew validly points =
out that even if these masks aren't a formal part=0Aof the hypercall =
interface, we aren't free to change them: A guest=0Asuspended for =
migration in the middle of a continuation would fail to=0Awork if resumed =
on a hypervisor using a different value. Hence add=0Arespective comments =
to their definitions.=0A=0AAdditionally, to help future extensibility as =
well as in the spirit of=0Areducing undefined behavior as much as =
possible, refuse hypercalls made=0Awith the respective bits non-zero when =
the respective sub-ops don't=0Amake use of those bits.=0A=0AReported-by: =
Andrew Cooper <andrew.cooper3@citrix.com>=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ b/xen/arch/x86/=
hvm/hvm.c=0A@@ -5458,16 +5458,34 @@ static int hvmop_destroy_ioreq_server(=
=0A     return rc;=0A }=0A =0A+/*=0A+ * Note that this value is effectively=
 part of the ABI, even if we don't need=0A+ * to make it a formal part of =
it: A guest suspended for migration in the=0A+ * middle of a continuation =
would fail to work if resumed on a hypervisor=0A+ * using a different =
value.=0A+ */=0A #define HVMOP_op_mask 0xff=0A =0A long do_hvm_op(unsigned =
long op, XEN_GUEST_HANDLE_PARAM(void) arg)=0A =0A {=0A     struct domain =
*curr_d =3D current->domain;=0A-    unsigned long start_iter =3D op & =
~HVMOP_op_mask;=0A+    unsigned long start_iter, mask;=0A     long rc =3D =
0;=0A =0A-    switch ( op &=3D HVMOP_op_mask )=0A+    switch ( op & =
HVMOP_op_mask )=0A+    {=0A+    default:=0A+        mask =3D ~0UL;=0A+     =
   break;=0A+    case HVMOP_modified_memory:=0A+    case HVMOP_set_mem_type=
:=0A+        mask =3D HVMOP_op_mask;=0A+        break;=0A+    }=0A+=0A+    =
start_iter =3D op & ~mask;=0A+    switch ( op &=3D mask )=0A     {=0A     =
case HVMOP_create_ioreq_server:=0A         rc =3D hvmop_create_ioreq_server=
(=0A@@ -6120,7 +6138,7 @@ long do_hvm_op(unsigned long op, XEN_GUE=0A =0A  =
   if ( rc =3D=3D -ERESTART )=0A     {=0A-        ASSERT(!(start_iter & =
HVMOP_op_mask));=0A+        ASSERT(!(start_iter & mask));=0A         rc =
=3D hypercall_create_continuation(__HYPERVISOR_hvm_op, "lh",=0A            =
                                op | start_iter, arg);=0A     }=0A--- =
a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -4661,9 +4661,8 @@ int =
xenmem_add_to_physmap_one(=0A long arch_memory_op(unsigned long cmd, =
XEN_GUEST_HANDLE_PARAM(void) arg)=0A {=0A     int rc;=0A-    int op =3D =
cmd & MEMOP_CMD_MASK;=0A =0A-    switch ( op )=0A+    switch ( cmd )=0A    =
 {=0A     case XENMEM_set_memory_map:=0A     {=0A@@ -4837,7 +4836,7 @@ =
long arch_memory_op(unsigned long cmd, X=0A         if ( d =3D=3D NULL =
)=0A             return -ESRCH;=0A =0A-        if ( op =3D=3D XENMEM_set_po=
d_target )=0A+        if ( cmd =3D=3D XENMEM_set_pod_target )=0A           =
  rc =3D xsm_set_pod_target(XSM_PRIV, d);=0A         else=0A             =
rc =3D xsm_get_pod_target(XSM_PRIV, d);=0A@@ -4845,7 +4844,7 @@ long =
arch_memory_op(unsigned long cmd, X=0A         if ( rc !=3D 0 )=0A         =
    goto pod_target_out_unlock;=0A =0A-        if ( op =3D=3D XENMEM_set_po=
d_target )=0A+        if ( cmd =3D=3D XENMEM_set_pod_target )=0A         =
{=0A             if ( target.target_pages > d->max_pages )=0A             =
{=0A@@ -4859,7 +4858,7 @@ long arch_memory_op(unsigned long cmd, X=0A      =
   if ( rc =3D=3D -ERESTART )=0A         {=0A             rc =3D hypercall_=
create_continuation(=0A-                __HYPERVISOR_memory_op, "lh", op, =
arg);=0A+                __HYPERVISOR_memory_op, "lh", cmd, arg);=0A       =
  }=0A         else if ( rc >=3D 0 )=0A         {=0A--- a/xen/arch/x86/x86_=
64/compat/mm.c=0A+++ b/xen/arch/x86/x86_64/compat/mm.c=0A@@ -53,9 +53,8 @@ =
int compat_arch_memory_op(unsigned long =0A     compat_pfn_t mfn;=0A     =
unsigned int i;=0A     int rc =3D 0;=0A-    int op =3D cmd & MEMOP_CMD_MASK=
;=0A =0A-    switch ( op )=0A+    switch ( cmd )=0A     {=0A     case =
XENMEM_set_memory_map:=0A     {=0A@@ -192,7 +191,7 @@ int compat_arch_memor=
y_op(unsigned long =0A         xen_mem_event_op_t meo;=0A         if ( =
copy_from_guest(&meo, arg, 1) )=0A             return -EFAULT;=0A-        =
rc =3D do_mem_event_op(op, meo.domain, (void *) &meo);=0A+        rc =3D =
do_mem_event_op(cmd, meo.domain, &meo);=0A         if ( !rc && __copy_to_gu=
est(arg, &meo, 1) )=0A             return -EFAULT;=0A         break;=0A@@ =
-205,7 +204,7 @@ int compat_arch_memory_op(unsigned long =0A             =
return -EFAULT;=0A         if ( mso.op =3D=3D XENMEM_sharing_op_audit )=0A =
            return mem_sharing_audit(); =0A-        rc =3D do_mem_event_op(=
op, mso.domain, (void *) &mso);=0A+        rc =3D do_mem_event_op(cmd, =
mso.domain, &mso);=0A         if ( !rc && __copy_to_guest(arg, &mso, 1) =
)=0A             return -EFAULT;=0A         break;=0A--- a/xen/arch/x86/x86=
_64/mm.c=0A+++ b/xen/arch/x86/x86_64/mm.c=0A@@ -906,9 +906,8 @@ long =
subarch_memory_op(unsigned long cmd=0A     xen_pfn_t mfn, last_mfn;=0A     =
unsigned int i;=0A     long rc =3D 0;=0A-    int op =3D cmd & MEMOP_CMD_MAS=
K;=0A =0A-    switch ( op )=0A+    switch ( cmd )=0A     {=0A     case =
XENMEM_machphys_mfn_list:=0A         if ( copy_from_guest(&xmml, arg, 1) =
)=0A@@ -989,7 +988,7 @@ long subarch_memory_op(unsigned long cmd=0A        =
 xen_mem_event_op_t meo;=0A         if ( copy_from_guest(&meo, arg, 1) =
)=0A             return -EFAULT;=0A-        rc =3D do_mem_event_op(op, =
meo.domain, (void *) &meo);=0A+        rc =3D do_mem_event_op(cmd, =
meo.domain, &meo);=0A         if ( !rc && __copy_to_guest(arg, &meo, 1) =
)=0A             return -EFAULT;=0A         break;=0A@@ -1002,7 +1001,7 @@ =
long subarch_memory_op(unsigned long cmd=0A             return -EFAULT;=0A =
        if ( mso.op =3D=3D XENMEM_sharing_op_audit )=0A             return =
mem_sharing_audit(); =0A-        rc =3D do_mem_event_op(op, mso.domain, =
(void *) &mso);=0A+        rc =3D do_mem_event_op(cmd, mso.domain, =
&mso);=0A         if ( !rc && __copy_to_guest(arg, &mso, 1) )=0A           =
  return -EFAULT;=0A         break;=0A--- a/xen/common/compat/grant_table.c=
=0A+++ b/xen/common/compat/grant_table.c=0A@@ -65,6 +65,8 @@ int compat_gra=
nt_table_op(unsigned int c=0A =0A     set_xen_guest_handle(cnt_uop, =
NULL);=0A     cmd_op =3D cmd & GNTTABOP_CMD_MASK;=0A+    if ( cmd_op !=3D =
GNTTABOP_cache_flush )=0A+        cmd_op =3D cmd;=0A     switch ( cmd_op =
)=0A     {=0A #define CASE(name) \=0A--- a/xen/common/grant_table.c=0A+++ =
b/xen/common/grant_table.c=0A@@ -62,6 +62,12 @@ integer_param("gnttab_max_f=
rames", max_g=0A static unsigned int __read_mostly max_maptrack_frames;=0A =
integer_param("gnttab_max_maptrack_frames", max_maptrack_frames);=0A =
=0A+/*=0A+ * Note that the three values below are effectively part of the =
ABI, even if=0A+ * we don't need to make them a formal part of it: A guest =
suspended for=0A+ * migration in the middle of a continuation would fail =
to work if resumed on=0A+ * a hypervisor using different values.=0A+ */=0A =
#define GNTTABOP_CONTINUATION_ARG_SHIFT 12=0A #define GNTTABOP_CMD_MASK    =
           ((1<<GNTTABOP_CONTINUATION_ARG_SHIFT)-1)=0A #define GNTTABOP_ARG=
_MASK               (~GNTTABOP_CMD_MASK)=0A@@ -2624,9 +2630,12 @@ =
do_grant_table_op(=0A     =0A     if ( (int)count < 0 )=0A         return =
-EINVAL;=0A+=0A+    if ( (cmd &=3D GNTTABOP_CMD_MASK) !=3D GNTTABOP_cache_f=
lush && opaque_in )=0A+        return -ENOSYS;=0A     =0A     rc =3D =
-EFAULT;=0A-    switch ( cmd &=3D GNTTABOP_CMD_MASK )=0A+    switch ( cmd =
)=0A     {=0A     case GNTTABOP_map_grant_ref:=0A     {=0A--- a/xen/common/=
mem_access.c=0A+++ b/xen/common/mem_access.c=0A@@ -58,6 +58,7 @@ void =
mem_access_resume(struct domain *d)=0A int mem_access_memop(unsigned long =
cmd,=0A                      XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) =
arg)=0A {=0A+    unsigned long start_iter =3D cmd & ~MEMOP_CMD_MASK;=0A    =
 long rc;=0A     xen_mem_access_op_t mao;=0A     struct domain *d;=0A@@ =
-84,14 +85,16 @@ int mem_access_memop(unsigned long cmd,=0A     switch ( =
mao.op )=0A     {=0A     case XENMEM_access_op_resume:=0A-        =
mem_access_resume(d);=0A-        rc =3D 0;=0A+        if ( unlikely(start_i=
ter) )=0A+            rc =3D -ENOSYS;=0A+        else=0A+        {=0A+     =
       mem_access_resume(d);=0A+            rc =3D 0;=0A+        }=0A      =
   break;=0A =0A     case XENMEM_access_op_set_access:=0A-    {=0A-        =
unsigned long start_iter =3D cmd & ~MEMOP_CMD_MASK;=0A-=0A         rc =3D =
-EINVAL;=0A         if ( (mao.pfn !=3D ~0ull) &&=0A              (mao.nr < =
start_iter ||=0A@@ -108,12 +111,15 @@ int mem_access_memop(unsigned long =
cmd,=0A                                                XENMEM_access_op | =
rc, arg);=0A         }=0A         break;=0A-    }=0A =0A     case =
XENMEM_access_op_get_access:=0A     {=0A         xenmem_access_t access;=0A=
 =0A+        rc =3D -ENOSYS;=0A+        if ( unlikely(start_iter) )=0A+    =
        break;=0A+=0A         rc =3D -EINVAL;=0A         if ( (mao.pfn > =
domain_get_maximum_gpfn(d)) && mao.pfn !=3D ~0ull )=0A             =
break;=0A--- a/xen/common/memory.c=0A+++ b/xen/common/memory.c=0A@@ =
-779,16 +779,25 @@ long do_memory_op(unsigned long cmd, XEN=0A         =
break;=0A =0A     case XENMEM_exchange:=0A+        if ( unlikely(start_exte=
nt) )=0A+            return -ENOSYS;=0A+=0A         rc =3D memory_exchange(=
guest_handle_cast(arg, xen_memory_exchange_t));=0A         break;=0A =0A   =
  case XENMEM_maximum_ram_page:=0A+        if ( unlikely(start_extent) =
)=0A+            return -ENOSYS;=0A+=0A         rc =3D max_page;=0A        =
 break;=0A =0A     case XENMEM_current_reservation:=0A     case XENMEM_maxi=
mum_reservation:=0A     case XENMEM_maximum_gpfn:=0A+        if ( =
unlikely(start_extent) )=0A+            return -ENOSYS;=0A+=0A         if =
( copy_from_guest(&domid, arg, 1) )=0A             return -EFAULT;=0A =
=0A@@ -912,6 +921,9 @@ long do_memory_op(unsigned long cmd, XEN=0A         =
struct page_info *page;=0A         struct domain *d;=0A =0A+        if ( =
unlikely(start_extent) )=0A+            return -ENOSYS;=0A+=0A         if =
( copy_from_guest(&xrfp, arg, 1) )=0A             return -EFAULT;=0A =0A@@ =
-945,6 +957,9 @@ long do_memory_op(unsigned long cmd, XEN=0A         =
break;=0A =0A     case XENMEM_claim_pages:=0A+        if ( unlikely(start_e=
xtent) )=0A+            return -ENOSYS;=0A+=0A         if ( copy_from_guest=
(&reservation, arg, 1) )=0A             return -EFAULT;=0A =0A@@ -977,6 =
+992,9 @@ long do_memory_op(unsigned long cmd, XEN=0A         unsigned int =
dom_vnodes, dom_vranges, dom_vcpus;=0A         struct vnuma_info tmp;=0A =
=0A+        if ( unlikely(start_extent) )=0A+            return -ENOSYS;=0A=
+=0A         /*=0A          * Guest passes nr_vnodes, number of regions =
and nr_vcpus thus=0A          * we know how much memory guest has =
allocated.=0A--- a/xen/include/xen/hypercall.h=0A+++ b/xen/include/xen/hype=
rcall.h=0A@@ -57,6 +57,11 @@ do_platform_op(=0A  * To allow safe resume of =
do_memory_op() after preemption, we need to know=0A  * at what point in =
the page list to resume. For this purpose I steal the=0A  * high-order =
bits of the @cmd parameter, which are otherwise unused and zero.=0A+ *=0A+ =
* Note that both of these values are effectively part of the ABI, even =
if=0A+ * we don't need to make them a formal part of it: A guest suspended =
for=0A+ * migration in the middle of a continuation would fail to work if =
resumed on=0A+ * a hypervisor using different values.=0A  */=0A #define =
MEMOP_EXTENT_SHIFT 6 /* cmd[:6] =3D=3D start_extent */=0A #define =
MEMOP_CMD_MASK     ((1 << MEMOP_EXTENT_SHIFT) - 1)=0A
--=__Part43769B69.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

--=__Part43769B69.2__=--


From xen-devel-bounces@lists.xen.org Fri Dec 05 12:03:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:03:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwrax-0005be-2w; Fri, 05 Dec 2014 12:02: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 1Xwrav-0005bY-F6
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 12:02:45 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	CF/70-25727-4EE91845; Fri, 05 Dec 2014 12:02:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417780962!11290682!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 29361 invoked from network); 5 Dec 2014 12:02:44 -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;
	5 Dec 2014 12:02:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200303580"
Message-ID: <54819EDF.30500@citrix.com>
Date: Fri, 5 Dec 2014 12:02: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: Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
	<54818CA5020000780004D0B2@mail.emea.novell.com>
In-Reply-To: <54818CA5020000780004D0B2@mail.emea.novell.com>
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 05/12/14 09:44, Jan Beulich wrote:
>>>> On 03.12.14 at 17:04, <david.vrabel@citrix.com> wrote:
>> The default limit for the number of PIRQs for hardware domains (dom0)
>> is not sufficient for some (x86) systems.
>>
>> Since the pirq structures are individually and dynamically allocated,
>> the limit for hardware domains may be increased to the number of
>> possible IRQs.
> I nevertheless disagree to moving the bound up to the Xen internal
> limit unconditionally: What use does it have to allow hwdom to use
> thousands of MSIs?

Because systems that big exist.  We have one.  In particular, it needs
somewhere between 288 and 512 pirqs to scan the bus and bring up the
physical functions alone.

> If a system got that many, the main purpose of
> running Xen on it I would expect to be to hand various of the
> respective devices to guests. Hence no need for hwdom to have
> that many by default, even if this doesn't result in any extra
> resource consumption.
>
> That said, I can see the current default of 256 being too low though.
> Quite likely in the absence of a user specified value the default
> ought to be derived from nr_irqs - nr_static_irqs rather than being
> any fixed number. Considering the default used for nr_irqs, I'd think
> along the lines of sqrt(num_present_cpus()) * NR_DYNAMIC_VECTORS
> or dom0->max_vcpus * NR_DYNAMIC_VECTORS (or the minimum of
> the two) for x86.

The hardware domain is trusted ultimately.  It can, amongst other
things, rewrite the bootloader command line and replace xen.gz.  It can
be trusted not to maliciously waste Xen resource.

Having an arbitrary restriction on the the hardware domains means only
that, in the case the arbitrary limit is hit, system devices fail to
function properly.  This is far more noticeable if the limit is hit
during probe.  The admin can edit the bootloader and increase the limit,
but only if the root disk was a driver lucky enough to get its
interrupt, or the default network card got its interrupts.

The limit serves no security or resource purpose, but has the chance of
crippling the boot of the system, and making recovery hard or
impossible.  On this justification alone, the limit should be removed.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:03:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:03:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwrax-0005be-2w; Fri, 05 Dec 2014 12:02: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 1Xwrav-0005bY-F6
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 12:02:45 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	CF/70-25727-4EE91845; Fri, 05 Dec 2014 12:02:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417780962!11290682!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 29361 invoked from network); 5 Dec 2014 12:02:44 -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;
	5 Dec 2014 12:02:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200303580"
Message-ID: <54819EDF.30500@citrix.com>
Date: Fri, 5 Dec 2014 12:02: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: Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
	<54818CA5020000780004D0B2@mail.emea.novell.com>
In-Reply-To: <54818CA5020000780004D0B2@mail.emea.novell.com>
X-DLP: MIA2
Cc: xen-devel@lists.xenproject.org, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 05/12/14 09:44, Jan Beulich wrote:
>>>> On 03.12.14 at 17:04, <david.vrabel@citrix.com> wrote:
>> The default limit for the number of PIRQs for hardware domains (dom0)
>> is not sufficient for some (x86) systems.
>>
>> Since the pirq structures are individually and dynamically allocated,
>> the limit for hardware domains may be increased to the number of
>> possible IRQs.
> I nevertheless disagree to moving the bound up to the Xen internal
> limit unconditionally: What use does it have to allow hwdom to use
> thousands of MSIs?

Because systems that big exist.  We have one.  In particular, it needs
somewhere between 288 and 512 pirqs to scan the bus and bring up the
physical functions alone.

> If a system got that many, the main purpose of
> running Xen on it I would expect to be to hand various of the
> respective devices to guests. Hence no need for hwdom to have
> that many by default, even if this doesn't result in any extra
> resource consumption.
>
> That said, I can see the current default of 256 being too low though.
> Quite likely in the absence of a user specified value the default
> ought to be derived from nr_irqs - nr_static_irqs rather than being
> any fixed number. Considering the default used for nr_irqs, I'd think
> along the lines of sqrt(num_present_cpus()) * NR_DYNAMIC_VECTORS
> or dom0->max_vcpus * NR_DYNAMIC_VECTORS (or the minimum of
> the two) for x86.

The hardware domain is trusted ultimately.  It can, amongst other
things, rewrite the bootloader command line and replace xen.gz.  It can
be trusted not to maliciously waste Xen resource.

Having an arbitrary restriction on the the hardware domains means only
that, in the case the arbitrary limit is hit, system devices fail to
function properly.  This is far more noticeable if the limit is hit
during probe.  The admin can edit the bootloader and increase the limit,
but only if the root disk was a driver lucky enough to get its
interrupt, or the default network card got its interrupts.

The limit serves no security or resource purpose, but has the chance of
crippling the boot of the system, and making recovery hard or
impossible.  On this justification alone, the limit should be removed.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:06:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwreC-0005zS-MN; Fri, 05 Dec 2014 12:06:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XwreB-0005zI-72
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:06:07 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	04/01-22819-EAF91845; Fri, 05 Dec 2014 12:06:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417781165!11746507!1
X-Originating-IP: [81.169.146.217]
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 20784 invoked from network); 5 Dec 2014 12:06:05 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:06:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417781165; l=1618;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=GfBraE/aAoLkkwD0XExQDOfhHIk=;
	b=jOvCj0u+nTfwr4+/EZRSengYQwWV2R29r5rBpkQsy/eih0TYBDM9cm0uzr4I164LjzZ
	lEYi4YxzBevLpLSBZhZMYpPYTxfxVow8/9xyALwdY7rzDC+dPI/g0lwmoWpCA6RFzqwA6
	hV5cglE9CfhjFMLQ2H0Bnc/Ryc50pDA6nXc=
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.2 AUTH) with ESMTPSA id D02cafqB5C62QBD
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:06:02 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 7F9885015E; Fri,  5 Dec 2014 13:06:02 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 13:05:47 +0100
Message-Id: <1417781152-9926-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 0/5] tools/hotplug: systemd changes 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>
MIME-Version: 1.0
Content-Type: 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 and Michael Young reported SELinux related failures in
var-lib-xenstored.mount. The first patch tries to address this by
makeing it easier to change the value of XENSTORED_MOUNT_CTX.

Its not clear to me if the mount option "context=" should be
adjustable by configure --with-selinux-mount-context=VAL to simplify
building via "make rpmball" for example. Looks like every new make
install or "rpm -U --force dist/xen.rpm" would require a readjustment of
XENSTORED_MOUNT_CTX without such new configure option.

The remaining patches are a result of reviewing the service files.
They reference non-existant sysconfig files. We should fix this before
the release of 4.5 to avoid stale sysconfig files if someone wants to
adjust the values.

I have tested this series on openSUSE 13.1.

Please review and apply for 4.5.


Olaf

Olaf Hering (5):
  tools/hotplug: move XENSTORED_MOUNT_CTX to sysconfig.xencommons
  tools/hotplug: use existing sysconfig file for xenconsoled
  tools/hotplug: remove EnvironmentFile from
    xen-qemu-dom0-disk-backend.service
  tools/hotplug: remove XENSTORED_ROOTDIR from service file
  tools/hotplug: support XENSTORED_TRACE in systemd

 tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 24 ++++++++++++++++++++--
 tools/hotplug/Linux/init.d/xencommons.in           |  5 +++--
 .../Linux/systemd/var-lib-xenstored.mount.in       |  3 +--
 .../systemd/xen-qemu-dom0-disk-backend.service.in  |  1 -
 tools/hotplug/Linux/systemd/xenconsoled.service.in |  7 ++-----
 tools/hotplug/Linux/systemd/xenstored.service.in   |  3 +--
 6 files changed, 29 insertions(+), 14 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:06:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwreC-0005zS-MN; Fri, 05 Dec 2014 12:06:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XwreB-0005zI-72
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:06:07 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	04/01-22819-EAF91845; Fri, 05 Dec 2014 12:06:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417781165!11746507!1
X-Originating-IP: [81.169.146.217]
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 20784 invoked from network); 5 Dec 2014 12:06:05 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:06:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417781165; l=1618;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=GfBraE/aAoLkkwD0XExQDOfhHIk=;
	b=jOvCj0u+nTfwr4+/EZRSengYQwWV2R29r5rBpkQsy/eih0TYBDM9cm0uzr4I164LjzZ
	lEYi4YxzBevLpLSBZhZMYpPYTxfxVow8/9xyALwdY7rzDC+dPI/g0lwmoWpCA6RFzqwA6
	hV5cglE9CfhjFMLQ2H0Bnc/Ryc50pDA6nXc=
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.2 AUTH) with ESMTPSA id D02cafqB5C62QBD
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:06:02 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 7F9885015E; Fri,  5 Dec 2014 13:06:02 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 13:05:47 +0100
Message-Id: <1417781152-9926-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 0/5] tools/hotplug: systemd changes 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>
MIME-Version: 1.0
Content-Type: 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 and Michael Young reported SELinux related failures in
var-lib-xenstored.mount. The first patch tries to address this by
makeing it easier to change the value of XENSTORED_MOUNT_CTX.

Its not clear to me if the mount option "context=" should be
adjustable by configure --with-selinux-mount-context=VAL to simplify
building via "make rpmball" for example. Looks like every new make
install or "rpm -U --force dist/xen.rpm" would require a readjustment of
XENSTORED_MOUNT_CTX without such new configure option.

The remaining patches are a result of reviewing the service files.
They reference non-existant sysconfig files. We should fix this before
the release of 4.5 to avoid stale sysconfig files if someone wants to
adjust the values.

I have tested this series on openSUSE 13.1.

Please review and apply for 4.5.


Olaf

Olaf Hering (5):
  tools/hotplug: move XENSTORED_MOUNT_CTX to sysconfig.xencommons
  tools/hotplug: use existing sysconfig file for xenconsoled
  tools/hotplug: remove EnvironmentFile from
    xen-qemu-dom0-disk-backend.service
  tools/hotplug: remove XENSTORED_ROOTDIR from service file
  tools/hotplug: support XENSTORED_TRACE in systemd

 tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 24 ++++++++++++++++++++--
 tools/hotplug/Linux/init.d/xencommons.in           |  5 +++--
 .../Linux/systemd/var-lib-xenstored.mount.in       |  3 +--
 .../systemd/xen-qemu-dom0-disk-backend.service.in  |  1 -
 tools/hotplug/Linux/systemd/xenconsoled.service.in |  7 ++-----
 tools/hotplug/Linux/systemd/xenstored.service.in   |  3 +--
 6 files changed, 29 insertions(+), 14 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:06:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwreI-00060Q-24; Fri, 05 Dec 2014 12:06:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XwreG-00060B-UL
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:06:13 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	F6/CF-02696-4BF91845; Fri, 05 Dec 2014 12:06:12 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417781171!13218258!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20517 invoked from network); 5 Dec 2014 12:06:11 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:06:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417781171; l=1900;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=bmIQ6U4soItx5Jf3J+PQ0FGQ6MQ=;
	b=ZRDxIgbnGWJhFLqWgI85SPTvju3rw1WzuTSVS1X2NtGPrW1BkkuWPzz5bvIduqhnvub
	fqoMZEvjyDETBsK69kYKW1fxk9WhKCscaVJBCdA0nHLwKnO8tBntuESA+koSkclEASJcL
	RncGQkpAn62GSX82IAdMJxCKIQFQM/nTXFA=
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.2 AUTH) with ESMTPSA id 602c6cqB5C68o2g
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:06:08 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 4941E5015E; Fri,  5 Dec 2014 13:06:04 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 13:05:48 +0100
Message-Id: <1417781152-9926-2-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to
	sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 non-SELinux system the mount option "context=none" works fine. But
with SELinux enabled a proper value has to be defined. To simplify the
required adjustment move XENSTORED_MOUNT_CTX from the service file to
the sysconfig file.

There is no need to require the creation of a new sysconfig file, just
reuse the existing /etc/sysconfig/xencommons file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/init.d/sysconfig.xencommons.in     | 7 +++++++
 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in | 3 +--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index c12fc8a..3a34b33 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -40,3 +40,10 @@
 
 # qemu path
 #QEMU_XEN=@LIBEXEC_BIN@/qemu-system-i386
+
+## Type: string
+## Default: "none"
+#
+# SELinux context for @XEN_LIB_STORED@ mount point.
+# see mount(8) for the meaning of the "context=" option
+XENSTORED_MOUNT_CTX=none
diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
index d5e04db..65e0b79 100644
--- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
+++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
@@ -6,8 +6,7 @@ ConditionPathExists=/proc/xen/capabilities
 RefuseManualStop=true
 
 [Mount]
-Environment=XENSTORED_MOUNT_CTX=none
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
+EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 What=xenstore
 Where=@XEN_LIB_STORED@
 Type=tmpfs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:06:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwreI-00060Q-24; Fri, 05 Dec 2014 12:06:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XwreG-00060B-UL
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:06:13 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	F6/CF-02696-4BF91845; Fri, 05 Dec 2014 12:06:12 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417781171!13218258!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20517 invoked from network); 5 Dec 2014 12:06:11 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:06:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417781171; l=1900;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=bmIQ6U4soItx5Jf3J+PQ0FGQ6MQ=;
	b=ZRDxIgbnGWJhFLqWgI85SPTvju3rw1WzuTSVS1X2NtGPrW1BkkuWPzz5bvIduqhnvub
	fqoMZEvjyDETBsK69kYKW1fxk9WhKCscaVJBCdA0nHLwKnO8tBntuESA+koSkclEASJcL
	RncGQkpAn62GSX82IAdMJxCKIQFQM/nTXFA=
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.2 AUTH) with ESMTPSA id 602c6cqB5C68o2g
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:06:08 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 4941E5015E; Fri,  5 Dec 2014 13:06:04 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 13:05:48 +0100
Message-Id: <1417781152-9926-2-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to
	sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 non-SELinux system the mount option "context=none" works fine. But
with SELinux enabled a proper value has to be defined. To simplify the
required adjustment move XENSTORED_MOUNT_CTX from the service file to
the sysconfig file.

There is no need to require the creation of a new sysconfig file, just
reuse the existing /etc/sysconfig/xencommons file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/init.d/sysconfig.xencommons.in     | 7 +++++++
 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in | 3 +--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index c12fc8a..3a34b33 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -40,3 +40,10 @@
 
 # qemu path
 #QEMU_XEN=@LIBEXEC_BIN@/qemu-system-i386
+
+## Type: string
+## Default: "none"
+#
+# SELinux context for @XEN_LIB_STORED@ mount point.
+# see mount(8) for the meaning of the "context=" option
+XENSTORED_MOUNT_CTX=none
diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
index d5e04db..65e0b79 100644
--- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
+++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
@@ -6,8 +6,7 @@ ConditionPathExists=/proc/xen/capabilities
 RefuseManualStop=true
 
 [Mount]
-Environment=XENSTORED_MOUNT_CTX=none
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
+EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 What=xenstore
 Where=@XEN_LIB_STORED@
 Type=tmpfs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:06:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:06:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwreO-000627-Fj; Fri, 05 Dec 2014 12:06:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XwreM-00061b-BW
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:06:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	27/B4-09842-9BF91845; Fri, 05 Dec 2014 12:06:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417781176!13668291!1
X-Originating-IP: [81.169.146.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30141 invoked from network); 5 Dec 2014 12:06:17 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:06:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417781176; l=4114;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=LdddRg+fp1/dRwkqCKRygKhKnCM=;
	b=qV8JXz5ASLTJCPCheFmWUbSmZT8WpKWKc76gb6DAY7IjaPZ7462t3fKJ/z3g3TGA8os
	w9FJRex6kP0ZSzeK8cyLn7/1fQKbIlFp5+YHTsSj6Au0v3UrUOXLJ6lJkQ/0VLLUda+h7
	6BkadA8nR9l/XmYw95lP1Y7SFU1sV2eP1io=
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.2 AUTH) with ESMTPSA id e00b8aqB5C6EPLL
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:06:14 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 59CA95015D; Fri,  5 Dec 2014 13:06:04 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 13:05:49 +0100
Message-Id: <1417781152-9926-3-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 2/5] tools/hotplug: use existing sysconfig file
	for xenconsoled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There is no need to require the creation of a new sysconfig file to
pass options to xenconsoled in the systemd service file. Reuse the
existing xencommons file. This file already contains the variable
XENCONSOLED_TRACE, which is used in the sysv runlevel script.

- Adjust systemd service file to use XENCONSOLED_TRACE instead of
  XENCONSOLED_LOG
- Move XENCONSOLED_ARGS and XENCONSOLED_LOG_DIR to the sysconfig file.
- Enable XENCONSOLED_TRACE and set its value to "none" to have a value
  for --log in the service file.
- Adjust the runlevel script to recognize also XENCONSOLED_ARGS and
  XENCONSOLED_LOG_DIR
- Adjust the runlevel script to handle XENCONSOLED_TRACE properly. If
  an old sysconfig file exist the XENCONSOLED_TRACE will remain empty.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 17 +++++++++++++++--
 tools/hotplug/Linux/init.d/xencommons.in           |  5 +++--
 tools/hotplug/Linux/systemd/xenconsoled.service.in |  7 ++-----
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index 3a34b33..6271c3e 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -2,8 +2,21 @@
 ## Type: string
 ## Default: "none"
 #
-# Log xenconsoled messages (cf xl dmesg)
-#XENCONSOLED_TRACE=[none|guest|hv|all]
+# Log xenconsoled messages (cf xl dmesg
+# This can be [none|guest|hv|all]
+XENCONSOLED_TRACE=none
+
+## Type: string
+## Default: ""
+#
+# Additional command line arguments for xenconsoled
+XENCONSOLED_ARGS=
+
+## Type: string
+## Default: "@XEN_LOG_DIR@/console"
+#
+# Output directory for xenconsoled logfiles.
+XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
 
 ## Type: string
 ## Default: xenstored
diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
index a1095c2..ddc8daa 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -95,8 +95,9 @@ do_start () {
 	fi
 
 	echo Starting xenconsoled...
-	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS=" --log=$XENCONSOLED_TRACE"
-	${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
+	test -z "$XENCONSOLED_LOG_DIR" || XENCONSOLED_LOG_DIR="--log-dir=${XENCONSOLED_LOG_DIR}"
+	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_TRACE=" --log=$XENCONSOLED_TRACE"
+	${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE ${XENCONSOLED_LOG_DIR} ${XENCONSOLED_TRACE} $XENCONSOLED_ARGS
 	echo Starting QEMU as disk backend for dom0
 	test -z "$QEMU_XEN" && QEMU_XEN="${LIBEXEC_BIN}/qemu-system-i386"
 	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize \
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index cb44cd6..9f533ff 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -6,14 +6,11 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=simple
-Environment=XENCONSOLED_ARGS=
-Environment=XENCONSOLED_LOG=none
-Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
+EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
 ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
-ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid --log=${XENCONSOLED_LOG} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
+ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid --log=${XENCONSOLED_TRACE} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
 
 [Install]
 WantedBy=multi-user.target

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:06:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:06:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwreO-000627-Fj; Fri, 05 Dec 2014 12:06:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XwreM-00061b-BW
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:06:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	27/B4-09842-9BF91845; Fri, 05 Dec 2014 12:06:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417781176!13668291!1
X-Originating-IP: [81.169.146.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30141 invoked from network); 5 Dec 2014 12:06:17 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:06:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417781176; l=4114;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=LdddRg+fp1/dRwkqCKRygKhKnCM=;
	b=qV8JXz5ASLTJCPCheFmWUbSmZT8WpKWKc76gb6DAY7IjaPZ7462t3fKJ/z3g3TGA8os
	w9FJRex6kP0ZSzeK8cyLn7/1fQKbIlFp5+YHTsSj6Au0v3UrUOXLJ6lJkQ/0VLLUda+h7
	6BkadA8nR9l/XmYw95lP1Y7SFU1sV2eP1io=
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.2 AUTH) with ESMTPSA id e00b8aqB5C6EPLL
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:06:14 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 59CA95015D; Fri,  5 Dec 2014 13:06:04 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 13:05:49 +0100
Message-Id: <1417781152-9926-3-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 2/5] tools/hotplug: use existing sysconfig file
	for xenconsoled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There is no need to require the creation of a new sysconfig file to
pass options to xenconsoled in the systemd service file. Reuse the
existing xencommons file. This file already contains the variable
XENCONSOLED_TRACE, which is used in the sysv runlevel script.

- Adjust systemd service file to use XENCONSOLED_TRACE instead of
  XENCONSOLED_LOG
- Move XENCONSOLED_ARGS and XENCONSOLED_LOG_DIR to the sysconfig file.
- Enable XENCONSOLED_TRACE and set its value to "none" to have a value
  for --log in the service file.
- Adjust the runlevel script to recognize also XENCONSOLED_ARGS and
  XENCONSOLED_LOG_DIR
- Adjust the runlevel script to handle XENCONSOLED_TRACE properly. If
  an old sysconfig file exist the XENCONSOLED_TRACE will remain empty.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 17 +++++++++++++++--
 tools/hotplug/Linux/init.d/xencommons.in           |  5 +++--
 tools/hotplug/Linux/systemd/xenconsoled.service.in |  7 ++-----
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index 3a34b33..6271c3e 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -2,8 +2,21 @@
 ## Type: string
 ## Default: "none"
 #
-# Log xenconsoled messages (cf xl dmesg)
-#XENCONSOLED_TRACE=[none|guest|hv|all]
+# Log xenconsoled messages (cf xl dmesg
+# This can be [none|guest|hv|all]
+XENCONSOLED_TRACE=none
+
+## Type: string
+## Default: ""
+#
+# Additional command line arguments for xenconsoled
+XENCONSOLED_ARGS=
+
+## Type: string
+## Default: "@XEN_LOG_DIR@/console"
+#
+# Output directory for xenconsoled logfiles.
+XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
 
 ## Type: string
 ## Default: xenstored
diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
index a1095c2..ddc8daa 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -95,8 +95,9 @@ do_start () {
 	fi
 
 	echo Starting xenconsoled...
-	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS=" --log=$XENCONSOLED_TRACE"
-	${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
+	test -z "$XENCONSOLED_LOG_DIR" || XENCONSOLED_LOG_DIR="--log-dir=${XENCONSOLED_LOG_DIR}"
+	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_TRACE=" --log=$XENCONSOLED_TRACE"
+	${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE ${XENCONSOLED_LOG_DIR} ${XENCONSOLED_TRACE} $XENCONSOLED_ARGS
 	echo Starting QEMU as disk backend for dom0
 	test -z "$QEMU_XEN" && QEMU_XEN="${LIBEXEC_BIN}/qemu-system-i386"
 	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize \
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index cb44cd6..9f533ff 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -6,14 +6,11 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=simple
-Environment=XENCONSOLED_ARGS=
-Environment=XENCONSOLED_LOG=none
-Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
+EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
 ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
-ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid --log=${XENCONSOLED_LOG} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
+ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid --log=${XENCONSOLED_TRACE} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
 
 [Install]
 WantedBy=multi-user.target

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:06:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwreX-00064n-Tb; Fri, 05 Dec 2014 12:06:29 +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 1XwreW-00064R-PF
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:06:28 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	16/4A-25727-4CF91845; Fri, 05 Dec 2014 12:06:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417781187!11291843!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29958 invoked from network); 5 Dec 2014 12:06:27 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:06:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417781187; l=1068;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=rpPOfsNAHj5jM5Z75DyDA1Ncrnk=;
	b=axBI2vucSg0TJxTbIHzLrvm659fAiV+uRNsKWlwIDMzLW10zvduiwWRghC3wQYdIRGa
	AHPjsSeuB0ox4CG51f0EfFc3bPMRhxwWjUJazmgLTuYBI5F99I2xZfIAOHQ5l2wE+z6n5
	ugnBbMzPAol5/6Uie3H3jxO1psOUmSlSX0Q=
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.2 AUTH) with ESMTPSA id I00484qB5C6JQMQ
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:06:19 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 750235015F; Fri,  5 Dec 2014 13:06:04 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 13:05:50 +0100
Message-Id: <1417781152-9926-4-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 3/5] tools/hotplug: remove EnvironmentFile from
	xen-qemu-dom0-disk-backend.service
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The references Environment file does not exist, and the service file
does not make use of variables anyway.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
 1 file changed, 1 deletion(-)

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 0a5807a..274cec0 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,7 +8,6 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=simple
-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@

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:06:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwreX-00064n-Tb; Fri, 05 Dec 2014 12:06:29 +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 1XwreW-00064R-PF
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:06:28 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	16/4A-25727-4CF91845; Fri, 05 Dec 2014 12:06:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417781187!11291843!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29958 invoked from network); 5 Dec 2014 12:06:27 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:06:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417781187; l=1068;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=rpPOfsNAHj5jM5Z75DyDA1Ncrnk=;
	b=axBI2vucSg0TJxTbIHzLrvm659fAiV+uRNsKWlwIDMzLW10zvduiwWRghC3wQYdIRGa
	AHPjsSeuB0ox4CG51f0EfFc3bPMRhxwWjUJazmgLTuYBI5F99I2xZfIAOHQ5l2wE+z6n5
	ugnBbMzPAol5/6Uie3H3jxO1psOUmSlSX0Q=
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.2 AUTH) with ESMTPSA id I00484qB5C6JQMQ
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:06:19 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 750235015F; Fri,  5 Dec 2014 13:06:04 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 13:05:50 +0100
Message-Id: <1417781152-9926-4-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 3/5] tools/hotplug: remove EnvironmentFile from
	xen-qemu-dom0-disk-backend.service
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The references Environment file does not exist, and the service file
does not make use of variables anyway.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
 1 file changed, 1 deletion(-)

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 0a5807a..274cec0 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,7 +8,6 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=simple
-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@

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:06:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1Xwree-00067H-A0; Fri, 05 Dec 2014 12:06:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xwred-00066t-Gn
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:06:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	83/55-09842-ACF91845; Fri, 05 Dec 2014 12:06:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417781192!13669821!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8071 invoked from network); 5 Dec 2014 12:06:32 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:06:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417781192; l=1275;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=FGrfz3UboIqWnv3SfLmqS7scDbM=;
	b=LoWu+qBI0s4X8LzP+TgyxQixxNLRStUCfhCH5FeYY6IhoX+7t3kPTZR1qTFeGKPQRTH
	yFqEy7Ua5a3GIrQFfnQsIDheiaz6xU5CmmOBEfkb3fHtiEa8Jd0Y7BlmSYSZ5QAaMx8qD
	WmiwPwOZ8jnP3Aeb9eeeioj+D7gH8J8XTHA=
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.2 AUTH) with ESMTPSA id y07aa6qB5C6UREw
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:06:30 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A6C2F50161; Fri,  5 Dec 2014 13:06:04 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 13:05:52 +0100
Message-Id: <1417781152-9926-6-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in
	systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The sysv runlevel script handles the boolean variable XENSTORED_TRACE
from sysconfig.xencommons to enable tracing. Recognize this also to
the systemd service file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenstored.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 0f0ac58..7e55f4f 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -14,7 +14,7 @@ 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@
-ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
+ExecStart=/bin/sh -c 'if test -n "${XENSTORED_TRACE}" ; then XENSTORED_ARGS="-T /var/log/xen/xenstored-trace.log" ; fi ; exec $XENSTORED --no-fork $$XENSTORED_ARGS'
 
 [Install]
 WantedBy=multi-user.target

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:06:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1Xwree-00067H-A0; Fri, 05 Dec 2014 12:06:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xwred-00066t-Gn
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:06:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	83/55-09842-ACF91845; Fri, 05 Dec 2014 12:06:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417781192!13669821!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8071 invoked from network); 5 Dec 2014 12:06:32 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:06:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417781192; l=1275;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=FGrfz3UboIqWnv3SfLmqS7scDbM=;
	b=LoWu+qBI0s4X8LzP+TgyxQixxNLRStUCfhCH5FeYY6IhoX+7t3kPTZR1qTFeGKPQRTH
	yFqEy7Ua5a3GIrQFfnQsIDheiaz6xU5CmmOBEfkb3fHtiEa8Jd0Y7BlmSYSZ5QAaMx8qD
	WmiwPwOZ8jnP3Aeb9eeeioj+D7gH8J8XTHA=
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.2 AUTH) with ESMTPSA id y07aa6qB5C6UREw
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:06:30 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A6C2F50161; Fri,  5 Dec 2014 13:06:04 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 13:05:52 +0100
Message-Id: <1417781152-9926-6-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in
	systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The sysv runlevel script handles the boolean variable XENSTORED_TRACE
from sysconfig.xencommons to enable tracing. Recognize this also to
the systemd service file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenstored.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 0f0ac58..7e55f4f 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -14,7 +14,7 @@ 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@
-ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
+ExecStart=/bin/sh -c 'if test -n "${XENSTORED_TRACE}" ; then XENSTORED_ARGS="-T /var/log/xen/xenstored-trace.log" ; fi ; exec $XENSTORED --no-fork $$XENSTORED_ARGS'
 
 [Install]
 WantedBy=multi-user.target

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:06:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:06:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwreo-0006C3-MS; Fri, 05 Dec 2014 12:06: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 1Xwren-0006BD-0P
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:06:45 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	11/4B-07724-4DF91845; Fri, 05 Dec 2014 12:06:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417781203!11247404!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25370 invoked from network); 5 Dec 2014 12:06:43 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:06:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417781203; l=1085;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=t8iWvxcLieVZ92ZFyeOh39CXlPM=;
	b=mHidrkOWy9kXObVRd771tP6ZEFh/0nQj4KhBp3fa8Rlf7P924S0GHYoY1l2eWblpvw1
	z9LVLZo5JxxhXAj45M4bKW/ZoQeFMI3WzJGwYji8WYJvk2B6El/3dXUGBkXBG04GaKPlQ
	MOf0He+uasecqgSqN2ewdKfFhQ4agfrzX8k=
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.2 AUTH) with ESMTPSA id z01b0bqB5C6OQJr
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:06:24 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 87C1E50160; Fri,  5 Dec 2014 13:06:04 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 13:05:51 +0100
Message-Id: <1417781152-9926-5-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 4/5] tools/hotplug: remove XENSTORED_ROOTDIR
	from service 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There is no need to export XENSTORED_ROOTDIR. This variable can be
enabled in sysconfig/xencommons. If the variable is unset xenstored
will automatically use @XEN_LIB_STORED@.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenstored.service.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 780bdd6..0f0ac58 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -9,7 +9,6 @@ ConditionPathExists=/proc/xen/capabilities
 [Service]
 Type=notify
 Environment=XENSTORED_ARGS=
-Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
 Environment=XENSTORED=@XENSTORED@
 EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:06:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:06:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwreo-0006C3-MS; Fri, 05 Dec 2014 12:06: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 1Xwren-0006BD-0P
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:06:45 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	11/4B-07724-4DF91845; Fri, 05 Dec 2014 12:06:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-31.messagelabs.com!1417781203!11247404!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25370 invoked from network); 5 Dec 2014 12:06:43 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:06:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417781203; l=1085;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=t8iWvxcLieVZ92ZFyeOh39CXlPM=;
	b=mHidrkOWy9kXObVRd771tP6ZEFh/0nQj4KhBp3fa8Rlf7P924S0GHYoY1l2eWblpvw1
	z9LVLZo5JxxhXAj45M4bKW/ZoQeFMI3WzJGwYji8WYJvk2B6El/3dXUGBkXBG04GaKPlQ
	MOf0He+uasecqgSqN2ewdKfFhQ4agfrzX8k=
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.2 AUTH) with ESMTPSA id z01b0bqB5C6OQJr
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:06:24 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 87C1E50160; Fri,  5 Dec 2014 13:06:04 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 13:05:51 +0100
Message-Id: <1417781152-9926-5-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 4/5] tools/hotplug: remove XENSTORED_ROOTDIR
	from service 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There is no need to export XENSTORED_ROOTDIR. This variable can be
enabled in sysconfig/xencommons. If the variable is unset xenstored
will automatically use @XEN_LIB_STORED@.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenstored.service.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 780bdd6..0f0ac58 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -9,7 +9,6 @@ ConditionPathExists=/proc/xen/capabilities
 [Service]
 Type=notify
 Environment=XENSTORED_ARGS=
-Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
 Environment=XENSTORED=@XENSTORED@
 EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:09:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:09:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwrh3-0006gG-DR; Fri, 05 Dec 2014 12:09:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xwrh2-0006fz-DJ
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 12:09:04 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	5F/E1-23865-F50A1845; Fri, 05 Dec 2014 12:09:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417781342!11193579!1
X-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 1571 invoked from network); 5 Dec 2014 12:09:03 -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; 5 Dec 2014 12:09:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 12:09:02 +0000
Message-Id: <5481AE6E020000780004D22C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 12:09:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <mdontu@bitdefender.com>
References: <1417712500-28009-1-git-send-email-mdontu@bitdefender.com>
In-Reply-To: <1417712500-28009-1-git-send-email-mdontu@bitdefender.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xmalloc: add support for checking the pool
 integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 18:01, <mdontu@bitdefender.com> wrote:
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -120,9 +120,120 @@ struct xmem_pool {
>      char name[MAX_POOL_NAME_LEN];
>  };
>  
> +static struct xmem_pool *xenpool;
> +
> +static inline void MAPPING_INSERT(unsigned long r, int *fl, int *sl);
> +
>  /*
>   * Helping functions
>   */
> +#ifndef NDEBUG
> +static int xmem_pool_check_size(const struct bhdr *b, int fl, int sl)
> +{
> +    while ( b )
> +    {
> +        int __fl;
> +        int __sl;
> +
> +        MAPPING_INSERT(b->size, &__fl, &__sl);
> +        if ( __fl != fl || __sl != sl )
> +        {
> +            printk(XENLOG_ERR "xmem_pool: for block %p size = %u, { fl = %d, sl = %d } should be { fl = %d, sl = %d }\n", b, b->size, fl, sl, __fl, __sl);

Long line. Only the format message alone is allowed to exceed 80
characters.

> +            return 0;
> +        }
> +        b = b->ptr.free_ptr.next;
> +    }
> +    return 1;
> +}
> +
> +/*
> + * This function must be called from a context where pool->lock is
> + * already acquired
> + */
> +#define xmem_pool_check_unlocked(__pool) __xmem_pool_check_unlocked(__FILE__, __LINE__, __pool)

No need for the double underscores on the macro parameter.

> +static int __xmem_pool_check_unlocked(const char *file, int line, const 
> struct xmem_pool *pool)
> +{
> +    int i;
> +    int woops = 0;
> +    static int once = 1;

bool_t

> +
> +    for ( i = 0; i < REAL_FLI; i++ )
> +    {
> +        int fl = ( pool->fl_bitmap & (1 << i) ) ? i : -1;

Bogus spaces inside parentheses.

> +
> +        if ( fl >= 0 )
> +        {
> +            int j;
> +            int bitmap_empty = 1;
> +            int matrix_empty = 1;

For any of the int-s here and above - can they really all become
negative? If not, they ought to be unsigned int or bool_t.

> +
> +            for ( j = 0; j < MAX_SLI; j++ )
> +            {
> +                int sl = ( pool->sl_bitmap[fl] & (1 << j) ) ? j : -1;
> +
> +                if ( sl < 0 )
> +                    continue;
> +
> +                if ( once && !pool->matrix[fl][sl] )
> +                {
> +                    /* The bitmap is corrupted */
> +                    printk(XENLOG_ERR "xmem_pool:%s:%d the TLSF bitmap is corrupted\n", file, line);
> +                    __warn((char *)file, line);

Please constify the first parameter of __warn() instead of adding
fragile casts. I also don't see why file and line need printing twice.

> +static int __xmem_pool_check_locked(const char *file, int line, struct 
> xmem_pool *pool)
> +{
> +    int err;
> +
> +    spin_lock(&pool->lock);
> +    err = __xmem_pool_check_unlocked(file, line, pool);

Inversed naming: The caller here should be _unlocked, and the
callee _locked.

> +#define xmem_pool_check_locked(__pool) do { if ( 0 && (__pool) ); } while (0)
> +#define xmem_pool_check_unlocked(__pool) do { if ( 0 && (__pool) ); } while (0)

((void)(pool)) or at least drop the "0 &&" - after all you _want_ the
macro argument to be evaluated (in order to carry out side effects).

> --- a/xen/include/xen/xmalloc.h
> +++ b/xen/include/xen/xmalloc.h
> @@ -123,4 +123,11 @@ unsigned long xmem_pool_get_used_size(struct xmem_pool 
> *pool);
>   */
>  unsigned long xmem_pool_get_total_size(struct xmem_pool *pool);
>  
> +#ifndef NDEBUG
> +#define xmem_pool_check() __xmem_pool_check(__FILE__, __LINE__)
> +int __xmem_pool_check(const char *file, int line);
> +#else
> +#define xmem_pool_check() do { if ( 0 ); } while (0)

((void)0)

or

do {} while (0)

Also perhaps __xmem_pool_check() should have a pool parameter,
with NULL meaning the default 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 Dec 05 12:09:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:09:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwrh3-0006gG-DR; Fri, 05 Dec 2014 12:09:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xwrh2-0006fz-DJ
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 12:09:04 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	5F/E1-23865-F50A1845; Fri, 05 Dec 2014 12:09:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417781342!11193579!1
X-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 1571 invoked from network); 5 Dec 2014 12:09:03 -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; 5 Dec 2014 12:09:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 12:09:02 +0000
Message-Id: <5481AE6E020000780004D22C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 12:09:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <mdontu@bitdefender.com>
References: <1417712500-28009-1-git-send-email-mdontu@bitdefender.com>
In-Reply-To: <1417712500-28009-1-git-send-email-mdontu@bitdefender.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xmalloc: add support for checking the pool
 integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 18:01, <mdontu@bitdefender.com> wrote:
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -120,9 +120,120 @@ struct xmem_pool {
>      char name[MAX_POOL_NAME_LEN];
>  };
>  
> +static struct xmem_pool *xenpool;
> +
> +static inline void MAPPING_INSERT(unsigned long r, int *fl, int *sl);
> +
>  /*
>   * Helping functions
>   */
> +#ifndef NDEBUG
> +static int xmem_pool_check_size(const struct bhdr *b, int fl, int sl)
> +{
> +    while ( b )
> +    {
> +        int __fl;
> +        int __sl;
> +
> +        MAPPING_INSERT(b->size, &__fl, &__sl);
> +        if ( __fl != fl || __sl != sl )
> +        {
> +            printk(XENLOG_ERR "xmem_pool: for block %p size = %u, { fl = %d, sl = %d } should be { fl = %d, sl = %d }\n", b, b->size, fl, sl, __fl, __sl);

Long line. Only the format message alone is allowed to exceed 80
characters.

> +            return 0;
> +        }
> +        b = b->ptr.free_ptr.next;
> +    }
> +    return 1;
> +}
> +
> +/*
> + * This function must be called from a context where pool->lock is
> + * already acquired
> + */
> +#define xmem_pool_check_unlocked(__pool) __xmem_pool_check_unlocked(__FILE__, __LINE__, __pool)

No need for the double underscores on the macro parameter.

> +static int __xmem_pool_check_unlocked(const char *file, int line, const 
> struct xmem_pool *pool)
> +{
> +    int i;
> +    int woops = 0;
> +    static int once = 1;

bool_t

> +
> +    for ( i = 0; i < REAL_FLI; i++ )
> +    {
> +        int fl = ( pool->fl_bitmap & (1 << i) ) ? i : -1;

Bogus spaces inside parentheses.

> +
> +        if ( fl >= 0 )
> +        {
> +            int j;
> +            int bitmap_empty = 1;
> +            int matrix_empty = 1;

For any of the int-s here and above - can they really all become
negative? If not, they ought to be unsigned int or bool_t.

> +
> +            for ( j = 0; j < MAX_SLI; j++ )
> +            {
> +                int sl = ( pool->sl_bitmap[fl] & (1 << j) ) ? j : -1;
> +
> +                if ( sl < 0 )
> +                    continue;
> +
> +                if ( once && !pool->matrix[fl][sl] )
> +                {
> +                    /* The bitmap is corrupted */
> +                    printk(XENLOG_ERR "xmem_pool:%s:%d the TLSF bitmap is corrupted\n", file, line);
> +                    __warn((char *)file, line);

Please constify the first parameter of __warn() instead of adding
fragile casts. I also don't see why file and line need printing twice.

> +static int __xmem_pool_check_locked(const char *file, int line, struct 
> xmem_pool *pool)
> +{
> +    int err;
> +
> +    spin_lock(&pool->lock);
> +    err = __xmem_pool_check_unlocked(file, line, pool);

Inversed naming: The caller here should be _unlocked, and the
callee _locked.

> +#define xmem_pool_check_locked(__pool) do { if ( 0 && (__pool) ); } while (0)
> +#define xmem_pool_check_unlocked(__pool) do { if ( 0 && (__pool) ); } while (0)

((void)(pool)) or at least drop the "0 &&" - after all you _want_ the
macro argument to be evaluated (in order to carry out side effects).

> --- a/xen/include/xen/xmalloc.h
> +++ b/xen/include/xen/xmalloc.h
> @@ -123,4 +123,11 @@ unsigned long xmem_pool_get_used_size(struct xmem_pool 
> *pool);
>   */
>  unsigned long xmem_pool_get_total_size(struct xmem_pool *pool);
>  
> +#ifndef NDEBUG
> +#define xmem_pool_check() __xmem_pool_check(__FILE__, __LINE__)
> +int __xmem_pool_check(const char *file, int line);
> +#else
> +#define xmem_pool_check() do { if ( 0 ); } while (0)

((void)0)

or

do {} while (0)

Also perhaps __xmem_pool_check() should have a pool parameter,
with NULL meaning the default 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 Dec 05 12:20:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwrrK-00079C-Is; Fri, 05 Dec 2014 12:19:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwrrJ-000797-O1
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 12:19:41 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	8A/6D-29352-CD2A1845; Fri, 05 Dec 2014 12:19:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417781980!11739371!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3230 invoked from network); 5 Dec 2014 12:19:40 -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; 5 Dec 2014 12:19:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 12:19:39 +0000
Message-Id: <5481B0EB020000780004D236@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 12:19:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
	<54818CA5020000780004D0B2@mail.emea.novell.com>
	<54819EDF.30500@citrix.com>
In-Reply-To: <54819EDF.30500@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>, TimDeegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 05.12.14 at 13:02, <andrew.cooper3@citrix.com> wrote:
> On 05/12/14 09:44, Jan Beulich wrote:
>>>>> On 03.12.14 at 17:04, <david.vrabel@citrix.com> wrote:
>>> The default limit for the number of PIRQs for hardware domains (dom0)
>>> is not sufficient for some (x86) systems.
>>>
>>> Since the pirq structures are individually and dynamically allocated,
>>> the limit for hardware domains may be increased to the number of
>>> possible IRQs.
>> I nevertheless disagree to moving the bound up to the Xen internal
>> limit unconditionally: What use does it have to allow hwdom to use
>> thousands of MSIs?
> 
> Because systems that big exist.  We have one.  In particular, it needs
> somewhere between 288 and 512 pirqs to scan the bus and bring up the
> physical functions alone.

This are hundreds, not thousands. I also heavily doubt that a system
needs any IRQs at all to scan the bus.

>> If a system got that many, the main purpose of
>> running Xen on it I would expect to be to hand various of the
>> respective devices to guests. Hence no need for hwdom to have
>> that many by default, even if this doesn't result in any extra
>> resource consumption.
>>
>> That said, I can see the current default of 256 being too low though.
>> Quite likely in the absence of a user specified value the default
>> ought to be derived from nr_irqs - nr_static_irqs rather than being
>> any fixed number. Considering the default used for nr_irqs, I'd think
>> along the lines of sqrt(num_present_cpus()) * NR_DYNAMIC_VECTORS
>> or dom0->max_vcpus * NR_DYNAMIC_VECTORS (or the minimum of
>> the two) for x86.
> 
> The hardware domain is trusted ultimately.  It can, amongst other
> things, rewrite the bootloader command line and replace xen.gz.  It can
> be trusted not to maliciously waste Xen resource.
> 
> Having an arbitrary restriction on the the hardware domains means only
> that, in the case the arbitrary limit is hit, system devices fail to
> function properly.  This is far more noticeable if the limit is hit
> during probe.  The admin can edit the bootloader and increase the limit,
> but only if the root disk was a driver lucky enough to get its
> interrupt, or the default network card got its interrupts.

There's no need to have disk access in order to add a boot option
- any reasonable boot loader ought to allow editing the command
lines.

> The limit serves no security or resource purpose, but has the chance of
> crippling the boot of the system, and making recovery hard or
> impossible.  On this justification alone, the limit should be removed.

But David's patch doesn't remove the limit, it just moves it as high as
is currently deemed reasonable. That may change, even if we can't
foresee it right now. I'm fine with proposing an alternative patch as
requested by David, but I'm not going to ack this one. If another
maintainer wants to commit it nevertheless, my disagreement here
isn't meant to be a veto...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:20:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwrrK-00079C-Is; Fri, 05 Dec 2014 12:19:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwrrJ-000797-O1
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 12:19:41 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	8A/6D-29352-CD2A1845; Fri, 05 Dec 2014 12:19:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417781980!11739371!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3230 invoked from network); 5 Dec 2014 12:19:40 -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; 5 Dec 2014 12:19:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 12:19:39 +0000
Message-Id: <5481B0EB020000780004D236@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 12:19:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com>
	<54818CA5020000780004D0B2@mail.emea.novell.com>
	<54819EDF.30500@citrix.com>
In-Reply-To: <54819EDF.30500@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>, TimDeegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1] xen: increase default number of PIRQs 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 05.12.14 at 13:02, <andrew.cooper3@citrix.com> wrote:
> On 05/12/14 09:44, Jan Beulich wrote:
>>>>> On 03.12.14 at 17:04, <david.vrabel@citrix.com> wrote:
>>> The default limit for the number of PIRQs for hardware domains (dom0)
>>> is not sufficient for some (x86) systems.
>>>
>>> Since the pirq structures are individually and dynamically allocated,
>>> the limit for hardware domains may be increased to the number of
>>> possible IRQs.
>> I nevertheless disagree to moving the bound up to the Xen internal
>> limit unconditionally: What use does it have to allow hwdom to use
>> thousands of MSIs?
> 
> Because systems that big exist.  We have one.  In particular, it needs
> somewhere between 288 and 512 pirqs to scan the bus and bring up the
> physical functions alone.

This are hundreds, not thousands. I also heavily doubt that a system
needs any IRQs at all to scan the bus.

>> If a system got that many, the main purpose of
>> running Xen on it I would expect to be to hand various of the
>> respective devices to guests. Hence no need for hwdom to have
>> that many by default, even if this doesn't result in any extra
>> resource consumption.
>>
>> That said, I can see the current default of 256 being too low though.
>> Quite likely in the absence of a user specified value the default
>> ought to be derived from nr_irqs - nr_static_irqs rather than being
>> any fixed number. Considering the default used for nr_irqs, I'd think
>> along the lines of sqrt(num_present_cpus()) * NR_DYNAMIC_VECTORS
>> or dom0->max_vcpus * NR_DYNAMIC_VECTORS (or the minimum of
>> the two) for x86.
> 
> The hardware domain is trusted ultimately.  It can, amongst other
> things, rewrite the bootloader command line and replace xen.gz.  It can
> be trusted not to maliciously waste Xen resource.
> 
> Having an arbitrary restriction on the the hardware domains means only
> that, in the case the arbitrary limit is hit, system devices fail to
> function properly.  This is far more noticeable if the limit is hit
> during probe.  The admin can edit the bootloader and increase the limit,
> but only if the root disk was a driver lucky enough to get its
> interrupt, or the default network card got its interrupts.

There's no need to have disk access in order to add a boot option
- any reasonable boot loader ought to allow editing the command
lines.

> The limit serves no security or resource purpose, but has the chance of
> crippling the boot of the system, and making recovery hard or
> impossible.  On this justification alone, the limit should be removed.

But David's patch doesn't remove the limit, it just moves it as high as
is currently deemed reasonable. That may change, even if we can't
foresee it right now. I'm fine with proposing an alternative patch as
requested by David, but I'm not going to ack this one. If another
maintainer wants to commit it nevertheless, my disagreement here
isn't meant to be a veto...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:20:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwrsB-0007ER-0R; Fri, 05 Dec 2014 12:20:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xwrs9-0007EI-A2
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:20:33 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F7/11-15461-013A1845; Fri, 05 Dec 2014 12:20:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417782030!13320849!1
X-Originating-IP: [66.165.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 4510 invoked from network); 5 Dec 2014 12:20:31 -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;
	5 Dec 2014 12:20:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200679977"
Received: from ukmail1.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, 5 Dec 2014 07:20: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 1Xwrre-0005N1-6W;
	Fri, 05 Dec 2014 12:20:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xwrrd-00071R-Pd;
	Fri, 05 Dec 2014 12:20:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.41713.481177.905257@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 12:20:01 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <1417781152-9926-2-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
	to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to sysconfig.xencommons"):
> On a non-SELinux system the mount option "context=none" works fine. But
> with SELinux enabled a proper value has to be defined. To simplify the
> required adjustment move XENSTORED_MOUNT_CTX from the service file to
> the sysconfig file.

This patch looks like just the hook.  It seems to be missing the part
where the actual selinux context is defined and plumbed through.


> There is no need to require the creation of a new sysconfig file, just
> reuse the existing /etc/sysconfig/xencommons file.

This seems to be an unrelated change ?  If not I confess I don't see
the connection.

> --- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> +++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
...
>  [Mount]
> -Environment=XENSTORED_MOUNT_CTX=none
> -EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> +EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons

And won't this break existing systems which have an
/etc/{default,sysconfig}/xenstored ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:20:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwrsB-0007ER-0R; Fri, 05 Dec 2014 12:20:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xwrs9-0007EI-A2
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:20:33 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F7/11-15461-013A1845; Fri, 05 Dec 2014 12:20:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417782030!13320849!1
X-Originating-IP: [66.165.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 4510 invoked from network); 5 Dec 2014 12:20:31 -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;
	5 Dec 2014 12:20:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200679977"
Received: from ukmail1.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, 5 Dec 2014 07:20: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 1Xwrre-0005N1-6W;
	Fri, 05 Dec 2014 12:20:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xwrrd-00071R-Pd;
	Fri, 05 Dec 2014 12:20:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.41713.481177.905257@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 12:20:01 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <1417781152-9926-2-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
	to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to sysconfig.xencommons"):
> On a non-SELinux system the mount option "context=none" works fine. But
> with SELinux enabled a proper value has to be defined. To simplify the
> required adjustment move XENSTORED_MOUNT_CTX from the service file to
> the sysconfig file.

This patch looks like just the hook.  It seems to be missing the part
where the actual selinux context is defined and plumbed through.


> There is no need to require the creation of a new sysconfig file, just
> reuse the existing /etc/sysconfig/xencommons file.

This seems to be an unrelated change ?  If not I confess I don't see
the connection.

> --- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> +++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
...
>  [Mount]
> -Environment=XENSTORED_MOUNT_CTX=none
> -EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> +EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons

And won't this break existing systems which have an
/etc/{default,sysconfig}/xenstored ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:22:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1Xwrtc-0007NV-F9; Fri, 05 Dec 2014 12:22: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 1Xwrtb-0007NN-Sx
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:22:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	56/C3-15461-B63A1845; Fri, 05 Dec 2014 12:22:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417782121!5634019!1
X-Originating-IP: [66.165.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 26752 invoked from network); 5 Dec 2014 12:22:02 -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 Dec 2014 12:22:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200680820"
Received: from ukmail1.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, 5 Dec 2014 07:22:00 -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 1XwrtY-0005QZ-HW;
	Fri, 05 Dec 2014 12:22:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwrtX-00072K-FT;
	Fri, 05 Dec 2014 12:21:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.41831.243767.976492@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 12:21:59 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <1417781152-9926-5-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-5-git-send-email-olaf@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] tools/hotplug: remove XENSTORED_ROOTDIR
	from service 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

Olaf Hering writes ("[PATCH 4/5] tools/hotplug: remove XENSTORED_ROOTDIR from service file"):
> There is no need to export XENSTORED_ROOTDIR. This variable can be
> enabled in sysconfig/xencommons. If the variable is unset xenstored
> will automatically use @XEN_LIB_STORED@.

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 Dec 05 12:22:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1Xwrtc-0007NV-F9; Fri, 05 Dec 2014 12:22: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 1Xwrtb-0007NN-Sx
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:22:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	56/C3-15461-B63A1845; Fri, 05 Dec 2014 12:22:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417782121!5634019!1
X-Originating-IP: [66.165.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 26752 invoked from network); 5 Dec 2014 12:22:02 -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 Dec 2014 12:22:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200680820"
Received: from ukmail1.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, 5 Dec 2014 07:22:00 -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 1XwrtY-0005QZ-HW;
	Fri, 05 Dec 2014 12:22:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwrtX-00072K-FT;
	Fri, 05 Dec 2014 12:21:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.41831.243767.976492@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 12:21:59 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <1417781152-9926-5-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-5-git-send-email-olaf@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] tools/hotplug: remove XENSTORED_ROOTDIR
	from service 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

Olaf Hering writes ("[PATCH 4/5] tools/hotplug: remove XENSTORED_ROOTDIR from service file"):
> There is no need to export XENSTORED_ROOTDIR. This variable can be
> enabled in sysconfig/xencommons. If the variable is unset xenstored
> will automatically use @XEN_LIB_STORED@.

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 Dec 05 12:24:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:24:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwrvc-0007cq-VU; Fri, 05 Dec 2014 12: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 1Xwrvb-0007cd-Lo
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 12:24:07 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	3F/65-18267-6E3A1845; Fri, 05 Dec 2014 12:24:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417782246!11298103!1
X-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 4620 invoked from network); 5 Dec 2014 12:24:06 -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; 5 Dec 2014 12:24:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 12:24:06 +0000
Message-Id: <5481B1F6020000780004D24A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 12:24:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Bob Liu" <bob.liu@oracle.com>
References: <546F1033.7030005@oracle.com> <54818221.1070804@oracle.com>
In-Reply-To: <54818221.1070804@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.campbell@citrix.com, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A good way to speed up the xl destroy time(guest
 page scrubbing)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 11:00, <bob.liu@oracle.com> wrote:
> 5. Potential workaround
> 5.1 Use per-cpu list in idle_loop()
> Delist a batch of pages from heap_list to a per-cpu list, then scrub the
> per-cpu list and free back to heap_list.
> 
> But Jan disagree with this solution:
> "You should really drop the idea of removing pages temporarily.
> All you need to do is make sure a page being allocated and getting
> simultaneously scrubbed by another CPU won't get passed to the
> caller until the scrubbing finished."

So you don't mention any downsides to this approach. If there are
any, please name them. If there aren't, what's the reason not to
go this route?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:24:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:24:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwrvc-0007cq-VU; Fri, 05 Dec 2014 12: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 1Xwrvb-0007cd-Lo
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 12:24:07 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	3F/65-18267-6E3A1845; Fri, 05 Dec 2014 12:24:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417782246!11298103!1
X-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 4620 invoked from network); 5 Dec 2014 12:24:06 -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; 5 Dec 2014 12:24:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 12:24:06 +0000
Message-Id: <5481B1F6020000780004D24A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 12:24:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Bob Liu" <bob.liu@oracle.com>
References: <546F1033.7030005@oracle.com> <54818221.1070804@oracle.com>
In-Reply-To: <54818221.1070804@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.campbell@citrix.com, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A good way to speed up the xl destroy time(guest
 page scrubbing)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 11:00, <bob.liu@oracle.com> wrote:
> 5. Potential workaround
> 5.1 Use per-cpu list in idle_loop()
> Delist a batch of pages from heap_list to a per-cpu list, then scrub the
> per-cpu list and free back to heap_list.
> 
> But Jan disagree with this solution:
> "You should really drop the idea of removing pages temporarily.
> All you need to do is make sure a page being allocated and getting
> simultaneously scrubbed by another CPU won't get passed to the
> caller until the scrubbing finished."

So you don't mention any downsides to this approach. If there are
any, please name them. If there aren't, what's the reason not to
go this route?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:24:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwrvz-0007gC-Bq; Fri, 05 Dec 2014 12: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.Jackson@citrix.com>) id 1Xwrvy-0007fx-4J
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:24:30 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	96/83-05632-DF3A1845; Fri, 05 Dec 2014 12:24:29 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417782267!11274771!1
X-Originating-IP: [66.165.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 31893 invoked from network); 5 Dec 2014 12:24:28 -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;
	5 Dec 2014 12:24:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200681608"
Received: from ukmail1.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, 5 Dec 2014 07: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 1Xwrvu-0005SR-0D;
	Fri, 05 Dec 2014 12:24:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xwrvt-00072g-OS;
	Fri, 05 Dec 2014 12:24:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.41977.399042.691409@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 12:24:25 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <1417781152-9926-6-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 5/5] tools/hotplug: support XENSTORED_TRACE in systemd"):
> The sysv runlevel script handles the boolean variable XENSTORED_TRACE
> from sysconfig.xencommons to enable tracing. Recognize this also to
> the systemd service file.
...
> -ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
> +ExecStart=/bin/sh -c 'if test -n "${XENSTORED_TRACE}" ; then XENSTORED_ARGS="-T /var/log/xen/xenstored-trace.log" ; fi ; exec $XENSTORED --no-fork $$XENSTORED_ARGS'

I'm afraid I'm not happy with the way that this duplicates logic
already found in /etc/init.d/xencommons.

Nacked-by: Ian Jackson <ian.jackson@eu.citrix.com>

I think the only way to make this work properly is to factor the
necessary parts out of init.d/xencommons into a new script which can
be used by both xencommons and systemd.  I'm not sure such a patch
would be appropriate for 4.5 at this stage.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:24:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwrvz-0007gC-Bq; Fri, 05 Dec 2014 12: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.Jackson@citrix.com>) id 1Xwrvy-0007fx-4J
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:24:30 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	96/83-05632-DF3A1845; Fri, 05 Dec 2014 12:24:29 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417782267!11274771!1
X-Originating-IP: [66.165.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 31893 invoked from network); 5 Dec 2014 12:24:28 -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;
	5 Dec 2014 12:24:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200681608"
Received: from ukmail1.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, 5 Dec 2014 07: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 1Xwrvu-0005SR-0D;
	Fri, 05 Dec 2014 12:24:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xwrvt-00072g-OS;
	Fri, 05 Dec 2014 12:24:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.41977.399042.691409@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 12:24:25 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <1417781152-9926-6-git-send-email-olaf@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 5/5] tools/hotplug: support XENSTORED_TRACE in systemd"):
> The sysv runlevel script handles the boolean variable XENSTORED_TRACE
> from sysconfig.xencommons to enable tracing. Recognize this also to
> the systemd service file.
...
> -ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
> +ExecStart=/bin/sh -c 'if test -n "${XENSTORED_TRACE}" ; then XENSTORED_ARGS="-T /var/log/xen/xenstored-trace.log" ; fi ; exec $XENSTORED --no-fork $$XENSTORED_ARGS'

I'm afraid I'm not happy with the way that this duplicates logic
already found in /etc/init.d/xencommons.

Nacked-by: Ian Jackson <ian.jackson@eu.citrix.com>

I think the only way to make this work properly is to factor the
necessary parts out of init.d/xencommons into a new script which can
be used by both xencommons and systemd.  I'm not sure such a patch
would be appropriate for 4.5 at this stage.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:26:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 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 1Xwrxq-0007rE-SJ; Fri, 05 Dec 2014 12:26:26 +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 1Xwrxo-0007qu-PC
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:26:25 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	4F/6B-26858-074A1845; Fri, 05 Dec 2014 12:26:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417782383!11345026!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28822 invoked from network); 5 Dec 2014 12:26:23 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:26:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417782383; l=1582;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=4sCSDfKuJeT2sQe5NheQGpAX/24=;
	b=Gd/R6g8MD0yjmPStKhFdnccRZ8RybvCDGdzivyumvaHD4T5LZbBnSStPfjO+tW5oClu
	MLrgCcBDhXFnyfIV37Xdd7qBHlSdndEuT+Pva6KU21/SEDmZePnozf3KgnWK9+7WoDOL1
	cEXBn+2pOKeJS+b/DEamUIFfdmGkqWmFRWY=
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.2 AUTH) with ESMTPSA id j00d3aqB5CQKQoR
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:26:20 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 2693A5015E; Fri,  5 Dec 2014 13:26:20 +0100 (CET)
Date: Fri, 5 Dec 2014 13:26:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141205122620.GA20558@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<21633.41713.481177.905257@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21633.41713.481177.905257@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Ian Jackson wrote:

> Olaf Hering writes ("[PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to sysconfig.xencommons"):
> > On a non-SELinux system the mount option "context=none" works fine. But
> > with SELinux enabled a proper value has to be defined. To simplify the
> > required adjustment move XENSTORED_MOUNT_CTX from the service file to
> > the sysconfig file.
> 
> This patch looks like just the hook.  It seems to be missing the part
> where the actual selinux context is defined and plumbed through.

The context in xen source is "none". As asked in the cover letter (which
unfortunately got send to just Konrad and xen-devel, no idea how to fix
that) a configure --with-something may be the way to inject it into the
sources, if required.

> > There is no need to require the creation of a new sysconfig file, just
> > reuse the existing /etc/sysconfig/xencommons file.
> 
> This seems to be an unrelated change ?  If not I confess I don't see
> the connection.

The context has to be defined somewhere. And that place is
sysconfig/xencommons.

> > --- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > +++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> ...
> >  [Mount]
> > -Environment=XENSTORED_MOUNT_CTX=none
> > -EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> > +EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
> 
> And won't this break existing systems which have an
> /etc/{default,sysconfig}/xenstored ?

Which systems would that be? That file is new in 4.5.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:26:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 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 1Xwrxq-0007rE-SJ; Fri, 05 Dec 2014 12:26:26 +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 1Xwrxo-0007qu-PC
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:26:25 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	4F/6B-26858-074A1845; Fri, 05 Dec 2014 12:26:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417782383!11345026!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28822 invoked from network); 5 Dec 2014 12:26:23 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:26:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417782383; l=1582;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=4sCSDfKuJeT2sQe5NheQGpAX/24=;
	b=Gd/R6g8MD0yjmPStKhFdnccRZ8RybvCDGdzivyumvaHD4T5LZbBnSStPfjO+tW5oClu
	MLrgCcBDhXFnyfIV37Xdd7qBHlSdndEuT+Pva6KU21/SEDmZePnozf3KgnWK9+7WoDOL1
	cEXBn+2pOKeJS+b/DEamUIFfdmGkqWmFRWY=
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.2 AUTH) with ESMTPSA id j00d3aqB5CQKQoR
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:26:20 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 2693A5015E; Fri,  5 Dec 2014 13:26:20 +0100 (CET)
Date: Fri, 5 Dec 2014 13:26:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141205122620.GA20558@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<21633.41713.481177.905257@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21633.41713.481177.905257@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Ian Jackson wrote:

> Olaf Hering writes ("[PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to sysconfig.xencommons"):
> > On a non-SELinux system the mount option "context=none" works fine. But
> > with SELinux enabled a proper value has to be defined. To simplify the
> > required adjustment move XENSTORED_MOUNT_CTX from the service file to
> > the sysconfig file.
> 
> This patch looks like just the hook.  It seems to be missing the part
> where the actual selinux context is defined and plumbed through.

The context in xen source is "none". As asked in the cover letter (which
unfortunately got send to just Konrad and xen-devel, no idea how to fix
that) a configure --with-something may be the way to inject it into the
sources, if required.

> > There is no need to require the creation of a new sysconfig file, just
> > reuse the existing /etc/sysconfig/xencommons file.
> 
> This seems to be an unrelated change ?  If not I confess I don't see
> the connection.

The context has to be defined somewhere. And that place is
sysconfig/xencommons.

> > --- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> > +++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
> ...
> >  [Mount]
> > -Environment=XENSTORED_MOUNT_CTX=none
> > -EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> > +EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
> 
> And won't this break existing systems which have an
> /etc/{default,sysconfig}/xenstored ?

Which systems would that be? That file is new in 4.5.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:28:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwrzV-00081c-BO; Fri, 05 Dec 2014 12:28: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 1XwrzT-00081V-Vy
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 12:28:08 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	2B/CD-29352-7D4A1845; Fri, 05 Dec 2014 12:28:07 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417782486!11752312!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 30957 invoked from network); 5 Dec 2014 12:28:06 -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; 5 Dec 2014 12:28:06 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3B4C6AC19;
	Fri,  5 Dec 2014 12:28: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
Date: Fri,  5 Dec 2014 13:28:04 +0100
Message-Id: <1417782484-31780-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] xen: introduce helper functions to do save read
	and write 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

Introduce two helper functions to savely read and write unsigned long
values from or to memory without crashing the system in case of access
failures.

These helpers can be used instead of open coded uses of __get_user()
and __put_user() avoiding the need to do casts to fix sparse warnings.

Use the helpers in page.h and p2m.c. This will fix the sparse
warnings when doing "make C=1".

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h | 16 +++++++++++++++-
 arch/x86/xen/p2m.c              |  2 +-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index f5d5de4..330352f 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -60,6 +60,20 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
 /*
+ * Helper functions to write or read unsigned long values to/from memory.
+ * To be used when accesses might fail.
+ */
+static inline int xen_safe_write_ulong(unsigned long *addr, unsigned long val)
+{
+	return __put_user(val, (unsigned long __user *)addr);
+}
+
+static inline int xen_safe_read_ulong(unsigned long *addr, unsigned long *val)
+{
+	return __get_user(*val, (unsigned long __user *)addr);
+}
+
+/*
  * 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.
@@ -125,7 +139,7 @@ static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
 	 * In such cases it doesn't matter what we return (we return garbage),
 	 * but we must handle the fault without crashing!
 	 */
-	ret = __get_user(pfn, &machine_to_phys_mapping[mfn]);
+	ret = xen_safe_read_ulong(&machine_to_phys_mapping[mfn], &pfn);
 	if (ret < 0)
 		return ~0;
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8b5db51..edbc7a6 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -625,7 +625,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
-	if (likely(!__put_user(mfn, xen_p2m_addr + pfn)))
+	if (likely(!xen_safe_write_ulong(xen_p2m_addr + pfn, mfn)))
 		return true;
 
 	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
-- 
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 Dec 05 12:28:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwrzV-00081c-BO; Fri, 05 Dec 2014 12:28: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 1XwrzT-00081V-Vy
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 12:28:08 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	2B/CD-29352-7D4A1845; Fri, 05 Dec 2014 12:28:07 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417782486!11752312!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 30957 invoked from network); 5 Dec 2014 12:28:06 -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; 5 Dec 2014 12:28:06 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3B4C6AC19;
	Fri,  5 Dec 2014 12:28: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
Date: Fri,  5 Dec 2014 13:28:04 +0100
Message-Id: <1417782484-31780-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] xen: introduce helper functions to do save read
	and write 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

Introduce two helper functions to savely read and write unsigned long
values from or to memory without crashing the system in case of access
failures.

These helpers can be used instead of open coded uses of __get_user()
and __put_user() avoiding the need to do casts to fix sparse warnings.

Use the helpers in page.h and p2m.c. This will fix the sparse
warnings when doing "make C=1".

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h | 16 +++++++++++++++-
 arch/x86/xen/p2m.c              |  2 +-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index f5d5de4..330352f 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -60,6 +60,20 @@ extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
 /*
+ * Helper functions to write or read unsigned long values to/from memory.
+ * To be used when accesses might fail.
+ */
+static inline int xen_safe_write_ulong(unsigned long *addr, unsigned long val)
+{
+	return __put_user(val, (unsigned long __user *)addr);
+}
+
+static inline int xen_safe_read_ulong(unsigned long *addr, unsigned long *val)
+{
+	return __get_user(*val, (unsigned long __user *)addr);
+}
+
+/*
  * 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.
@@ -125,7 +139,7 @@ static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
 	 * In such cases it doesn't matter what we return (we return garbage),
 	 * but we must handle the fault without crashing!
 	 */
-	ret = __get_user(pfn, &machine_to_phys_mapping[mfn]);
+	ret = xen_safe_read_ulong(&machine_to_phys_mapping[mfn], &pfn);
 	if (ret < 0)
 		return ~0;
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8b5db51..edbc7a6 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -625,7 +625,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 		return true;
 	}
 
-	if (likely(!__put_user(mfn, xen_p2m_addr + pfn)))
+	if (likely(!xen_safe_write_ulong(xen_p2m_addr + pfn, mfn)))
 		return true;
 
 	ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
-- 
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 Dec 05 12:30:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1Xws1x-0008It-2P; Fri, 05 Dec 2014 12:30:41 +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 1Xws1v-0008Il-7d
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:30:39 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	BF/05-02699-B65A1845; Fri, 05 Dec 2014 12:30:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417782634!13220008!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24704 invoked from network); 5 Dec 2014 12:30:35 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:30:35 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417782634; l=587;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=GThWd495Cl3G4B1mP66LBWpEqNI=;
	b=GaEe/h53ljzLRM1CSJnLg9tr6qL3n4kPcURYS4afJlD5A62oPe5MQ/wxcyxDSB4YTT7
	rJia6pLgSskBz2zXPJi7Jgxpjzniy+ouAvSR8UrzGGbgcB5VYabJOSn8D1004rqjeFlmZ
	y3fSGiPOvaUY3csIlCQmtzfD5m+D9w8cmQM=
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.2 AUTH) with ESMTPSA id y0165eqB5CUVTfL
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:30:31 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 8551F5015E; Fri,  5 Dec 2014 13:30:31 +0100 (CET)
Date: Fri, 5 Dec 2014 13:30:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141205123031.GB20558@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21633.41977.399042.691409@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Ian Jackson wrote:

> I think the only way to make this work properly is to factor the
> necessary parts out of init.d/xencommons into a new script which can
> be used by both xencommons and systemd.  I'm not sure such a patch
> would be appropriate for 4.5 at this stage.

Yes, a helper script to launch just xenstored would help. But which part
would do the final "exec"? Perhaps the sysv script has to fork a shell
like its done above. I will have a look at this. 

Are you opposed to the idea to support XENSTORED_TRACE for systemd right
in 4.5.0?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:30:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1Xws1x-0008It-2P; Fri, 05 Dec 2014 12:30:41 +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 1Xws1v-0008Il-7d
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:30:39 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	BF/05-02699-B65A1845; Fri, 05 Dec 2014 12:30:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417782634!13220008!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24704 invoked from network); 5 Dec 2014 12:30:35 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:30:35 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417782634; l=587;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=GThWd495Cl3G4B1mP66LBWpEqNI=;
	b=GaEe/h53ljzLRM1CSJnLg9tr6qL3n4kPcURYS4afJlD5A62oPe5MQ/wxcyxDSB4YTT7
	rJia6pLgSskBz2zXPJi7Jgxpjzniy+ouAvSR8UrzGGbgcB5VYabJOSn8D1004rqjeFlmZ
	y3fSGiPOvaUY3csIlCQmtzfD5m+D9w8cmQM=
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.2 AUTH) with ESMTPSA id y0165eqB5CUVTfL
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:30:31 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 8551F5015E; Fri,  5 Dec 2014 13:30:31 +0100 (CET)
Date: Fri, 5 Dec 2014 13:30:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141205123031.GB20558@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21633.41977.399042.691409@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Ian Jackson wrote:

> I think the only way to make this work properly is to factor the
> necessary parts out of init.d/xencommons into a new script which can
> be used by both xencommons and systemd.  I'm not sure such a patch
> would be appropriate for 4.5 at this stage.

Yes, a helper script to launch just xenstored would help. But which part
would do the final "exec"? Perhaps the sysv script has to fork a shell
like its done above. I will have a look at this. 

Are you opposed to the idea to support XENSTORED_TRACE for systemd right
in 4.5.0?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:33:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:33:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xws43-0000G6-JL; Fri, 05 Dec 2014 12:32:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xws42-0000Fy-2v
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:32:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E1/D7-09842-1F5A1845; Fri, 05 Dec 2014 12:32:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417782768!13693405!1
X-Originating-IP: [81.169.146.163]
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 1616 invoked from network); 5 Dec 2014 12:32:49 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:32:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417782768; l=309;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=aTVF9zbrl1mmHYUUb+sGbJoveV8=;
	b=J5Lp62koYMHos/TXVkQug1FED8U5b83PVV9zdf26wMg5hgvfEE/0MkrnQ0CV2zgDQSN
	l3GY2c2o7F4WOW0pV3+gydrs8I9gv550I9pEMZZ65ICG7yPmjWGoZahM6whcEFB2DCQMl
	aO/Y6+gKECnQgiPvZQQLxCu9IcZYYp0Uexs=
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.2 AUTH) with ESMTPSA id x00ea8qB5CWkR96
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:32:46 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id EC83E5015E; Fri,  5 Dec 2014 13:32:45 +0100 (CET)
Date: Fri, 5 Dec 2014 13:32:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141205123245.GC20558@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<21633.41713.481177.905257@mariner.uk.xensource.com>
	<20141205122620.GA20558@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205122620.GA20558@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Olaf Hering wrote:

> On Fri, Dec 05, Ian Jackson wrote:
> > And won't this break existing systems which have an
> > /etc/{default,sysconfig}/xenstored ?
> Which systems would that be? That file is new in 4.5.

... Not the file itself but the usage of a to-be-created file ...

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:33:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:33:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xws43-0000G6-JL; Fri, 05 Dec 2014 12:32:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xws42-0000Fy-2v
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:32:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E1/D7-09842-1F5A1845; Fri, 05 Dec 2014 12:32:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417782768!13693405!1
X-Originating-IP: [81.169.146.163]
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 1616 invoked from network); 5 Dec 2014 12:32:49 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 12:32:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417782768; l=309;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=aTVF9zbrl1mmHYUUb+sGbJoveV8=;
	b=J5Lp62koYMHos/TXVkQug1FED8U5b83PVV9zdf26wMg5hgvfEE/0MkrnQ0CV2zgDQSN
	l3GY2c2o7F4WOW0pV3+gydrs8I9gv550I9pEMZZ65ICG7yPmjWGoZahM6whcEFB2DCQMl
	aO/Y6+gKECnQgiPvZQQLxCu9IcZYYp0Uexs=
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.2 AUTH) with ESMTPSA id x00ea8qB5CWkR96
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 13:32:46 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id EC83E5015E; Fri,  5 Dec 2014 13:32:45 +0100 (CET)
Date: Fri, 5 Dec 2014 13:32:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141205123245.GC20558@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<21633.41713.481177.905257@mariner.uk.xensource.com>
	<20141205122620.GA20558@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205122620.GA20558@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Olaf Hering wrote:

> On Fri, Dec 05, Ian Jackson wrote:
> > And won't this break existing systems which have an
> > /etc/{default,sysconfig}/xenstored ?
> Which systems would that be? That file is new in 4.5.

... Not the file itself but the usage of a to-be-created file ...

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:43:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwsDW-0000cR-MS; Fri, 05 Dec 2014 12:42:38 +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 1XwsDV-0000cK-8a
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:42:37 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	AC/53-28865-C38A1845; Fri, 05 Dec 2014 12:42:36 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417783354!4181430!1
X-Originating-IP: [66.165.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 24299 invoked from network); 5 Dec 2014 12:42:35 -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;
	5 Dec 2014 12:42:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200687585"
Received: from ukmail1.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, 5 Dec 2014 07:42: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 1XwsDR-0005qS-LH;
	Fri, 05 Dec 2014 12:42:33 +0000
Date: Fri, 5 Dec 2014 12:42:33 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141205124233.GD31446@zion.uk.xensource.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
[...]
> > I think that's expected, because guest RX data path still uses grant_copy while
> > guest TX uses grant_map to do zero-copy transmit.
> 
> As far as I know, there are three main grant-related operations used in split device model: grant mapping, grant transfer and grant copy. 
> Grant transfer has not used now, and grant mapping and grant transfer both involve "TLB" refresh work for hypervisor, am I right?  Or only grant transfer has this overhead?

Transfer is not used so I can't tell. Grant unmap causes TLB flush.

I saw in an email the other day XenServer folks has some planned
improvement to avoid TLB flush in Xen to upstream in 4.6 window. I can't
speak for sure it will get upstreamed as I don't work on that.

> Does grant copy surely has more overhead than grant mapping? 
> 

At the very least the zero-copy TX path is faster than previous copying
path.

But speaking of the micro operation I'm not sure.

There was once persistent map prototype netback / netfront that
establishes a memory pool between FE and BE then use memcpy to copy
data. Unfortunately that prototype was not done right so the result was
not good.

> >From the code, I see that in TX, netback will do gnttab_batch_copy as well as gnttab_map_refs:
> 
> <code> //netback.c:xenvif_tx_action
> 	xenvif_tx_build_gops(queue, budget, &nr_cops, &nr_mops);
> 
> 	if (nr_cops == 0)
> 		return 0;
> 
> 	gnttab_batch_copy(queue->tx_copy_ops, nr_cops);
> 	if (nr_mops != 0) {
> 		ret = gnttab_map_refs(queue->tx_map_ops,
> 				      NULL,
> 				      queue->pages_to_map,
> 				      nr_mops);
> 		BUG_ON(ret);
> 	}
> </code>
> 

The copy is for the packet header. Mapping is for packet data.

We need to copy header from guest so that it doesn't change under
netback's feet.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:43:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwsDW-0000cR-MS; Fri, 05 Dec 2014 12:42:38 +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 1XwsDV-0000cK-8a
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:42:37 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	AC/53-28865-C38A1845; Fri, 05 Dec 2014 12:42:36 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417783354!4181430!1
X-Originating-IP: [66.165.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 24299 invoked from network); 5 Dec 2014 12:42:35 -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;
	5 Dec 2014 12:42:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200687585"
Received: from ukmail1.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, 5 Dec 2014 07:42: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 1XwsDR-0005qS-LH;
	Fri, 05 Dec 2014 12:42:33 +0000
Date: Fri, 5 Dec 2014 12:42:33 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141205124233.GD31446@zion.uk.xensource.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
[...]
> > I think that's expected, because guest RX data path still uses grant_copy while
> > guest TX uses grant_map to do zero-copy transmit.
> 
> As far as I know, there are three main grant-related operations used in split device model: grant mapping, grant transfer and grant copy. 
> Grant transfer has not used now, and grant mapping and grant transfer both involve "TLB" refresh work for hypervisor, am I right?  Or only grant transfer has this overhead?

Transfer is not used so I can't tell. Grant unmap causes TLB flush.

I saw in an email the other day XenServer folks has some planned
improvement to avoid TLB flush in Xen to upstream in 4.6 window. I can't
speak for sure it will get upstreamed as I don't work on that.

> Does grant copy surely has more overhead than grant mapping? 
> 

At the very least the zero-copy TX path is faster than previous copying
path.

But speaking of the micro operation I'm not sure.

There was once persistent map prototype netback / netfront that
establishes a memory pool between FE and BE then use memcpy to copy
data. Unfortunately that prototype was not done right so the result was
not good.

> >From the code, I see that in TX, netback will do gnttab_batch_copy as well as gnttab_map_refs:
> 
> <code> //netback.c:xenvif_tx_action
> 	xenvif_tx_build_gops(queue, budget, &nr_cops, &nr_mops);
> 
> 	if (nr_cops == 0)
> 		return 0;
> 
> 	gnttab_batch_copy(queue->tx_copy_ops, nr_cops);
> 	if (nr_mops != 0) {
> 		ret = gnttab_map_refs(queue->tx_map_ops,
> 				      NULL,
> 				      queue->pages_to_map,
> 				      nr_mops);
> 		BUG_ON(ret);
> 	}
> </code>
> 

The copy is for the packet header. Mapping is for packet data.

We need to copy header from guest so that it doesn't change under
netback's feet.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:43:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwsEV-0000gm-4X; Fri, 05 Dec 2014 12:43:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwsET-0000gY-Hm
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:43:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	45/39-15461-878A1845; Fri, 05 Dec 2014 12:43:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417783415!13680151!1
X-Originating-IP: [66.165.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 510 invoked from network); 5 Dec 2014 12:43:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 12:43:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200688121"
Received: from ukmail1.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, 5 Dec 2014 07:43: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 1XwsEQ-0005rV-7I;
	Fri, 05 Dec 2014 12:43:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwsEP-00075t-WA;
	Fri, 05 Dec 2014 12:43:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.43125.817078.380788@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 12:43:33 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141205122620.GA20558@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<21633.41713.481177.905257@mariner.uk.xensource.com>
	<20141205122620.GA20558@aepfle.de>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to sysconfig.xencommons"):
> On Fri, Dec 05, Ian Jackson wrote:
> > This patch looks like just the hook.  It seems to be missing the part
> > where the actual selinux context is defined and plumbed through.
> 
> The context in xen source is "none". As asked in the cover letter (which
> unfortunately got send to just Konrad and xen-devel, no idea how to fix
> that) a configure --with-something may be the way to inject it into the
> sources, if required.

I confess I don't know very much about selinux, but shouldn't we be
providing a reasonable default policy, rather than leaving it to the
distro or user to pass special options to configure ?  Or are things
in the selinux world so fragmented or fast-moving that such a generic
policy couldn't be written ?

> > > There is no need to require the creation of a new sysconfig file, just
> > > reuse the existing /etc/sysconfig/xencommons file.
> > 
> > This seems to be an unrelated change ?  If not I confess I don't see
> > the connection.
> 
> The context has to be defined somewhere. And that place is
> sysconfig/xencommons.

Oh, I see.  I think you should do this change as a pre-patch, along
with the abolition of
  /etc/{default,sysconfig}/{xenconsoled,xenstored}

Your patch 2/5 involving xenconsoled has a mixture of code motion and
other semantic changes, which makes it hard to review.

> > And won't this break existing systems which have an
> > /etc/{default,sysconfig}/xenstored ?
> 
> Which systems would that be? That file is new in 4.5.

Oh, good.  In that case we should abolish these ASAP - before 4.5.

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 Dec 05 12:43:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12: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 1XwsEV-0000gm-4X; Fri, 05 Dec 2014 12:43:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwsET-0000gY-Hm
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:43:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	45/39-15461-878A1845; Fri, 05 Dec 2014 12:43:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417783415!13680151!1
X-Originating-IP: [66.165.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 510 invoked from network); 5 Dec 2014 12:43:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 12:43:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200688121"
Received: from ukmail1.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, 5 Dec 2014 07:43: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 1XwsEQ-0005rV-7I;
	Fri, 05 Dec 2014 12:43:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwsEP-00075t-WA;
	Fri, 05 Dec 2014 12:43:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.43125.817078.380788@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 12:43:33 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141205122620.GA20558@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<21633.41713.481177.905257@mariner.uk.xensource.com>
	<20141205122620.GA20558@aepfle.de>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to sysconfig.xencommons"):
> On Fri, Dec 05, Ian Jackson wrote:
> > This patch looks like just the hook.  It seems to be missing the part
> > where the actual selinux context is defined and plumbed through.
> 
> The context in xen source is "none". As asked in the cover letter (which
> unfortunately got send to just Konrad and xen-devel, no idea how to fix
> that) a configure --with-something may be the way to inject it into the
> sources, if required.

I confess I don't know very much about selinux, but shouldn't we be
providing a reasonable default policy, rather than leaving it to the
distro or user to pass special options to configure ?  Or are things
in the selinux world so fragmented or fast-moving that such a generic
policy couldn't be written ?

> > > There is no need to require the creation of a new sysconfig file, just
> > > reuse the existing /etc/sysconfig/xencommons file.
> > 
> > This seems to be an unrelated change ?  If not I confess I don't see
> > the connection.
> 
> The context has to be defined somewhere. And that place is
> sysconfig/xencommons.

Oh, I see.  I think you should do this change as a pre-patch, along
with the abolition of
  /etc/{default,sysconfig}/{xenconsoled,xenstored}

Your patch 2/5 involving xenconsoled has a mixture of code motion and
other semantic changes, which makes it hard to review.

> > And won't this break existing systems which have an
> > /etc/{default,sysconfig}/xenstored ?
> 
> Which systems would that be? That file is new in 4.5.

Oh, good.  In that case we should abolish these ASAP - before 4.5.

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 Dec 05 12:49:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:49:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwsJh-0000vv-TM; Fri, 05 Dec 2014 12:49:01 +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 1XwsJg-0000vX-AS
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 12:49:00 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	21/40-17694-BB9A1845; Fri, 05 Dec 2014 12:48:59 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417783738!11375644!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25626 invoked from network); 5 Dec 2014 12:48:59 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 12:48:59 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so1298886wid.9
	for <xen-devel@lists.xensource.com>;
	Fri, 05 Dec 2014 04:48: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=lXQBIiDDJXLc8cn4uJ7uipgFEKHiN6uIfSeHeVzwsuo=;
	b=OW0krz2EqE1/Zto962XVn3xWxaisZSerdlW1uZ6MZzDOstISNQOmEfo+CJLZwu8d9Z
	Cg2q783/mNYJmki/XHMasPp2Te6SN7E42v1idQOZx5umP88RlUyI4RyNJThAAkqBc6HP
	HLvs7O059Mz7yxvfnj05cIesFuyLoDbvUC39tYPTAW9hDkKRi4KRCOREczqEICr4aUnh
	mTEMP4Xd6IgqfFiNYq5VKf6uD/jLLouiijFUYF+Owv1RbQaGEERhULUJR39sZz+KevbC
	eoOPVj7umZi7QDhDv3+my3ks7xDDQ/QZtLLqYUZqtgyTFDo7z0EdJWlgvspHMf9+ovm/
	cM0g==
X-Gm-Message-State: ALoCoQnR27HGYiAQcFhfZ7ckpsQYSoyi5ofloNjl3E5BWYVk/aDa+FPuh/pmC3z9+X9ufhFuwKxq
X-Received: by 10.180.21.140 with SMTP id v12mr4012932wie.44.1417783738375;
	Fri, 05 Dec 2014 04:48:58 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id p5sm2173735wix.7.2014.12.05.04.48.57
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 04:48:57 -0800 (PST)
Message-ID: <5481A9BA.1000009@linaro.org>
Date: Fri, 05 Dec 2014 12:48:58 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, 
	Anthony Wright <anthony@overnetdata.com>
References: <19758084.30.1417707380178.JavaMail.root@zimbra.overnetdata.com>
	<54808372.8090102@citrix.com>
In-Reply-To: <54808372.8090102@citrix.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.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-Transfer-Encoding: 7bit
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,

Maybe I'm misreading it, but it seems to me that netfront doesn't slice 
up the linear buffer at all, just blindly sends it. In xennet_start_xmit:

unsigned int offset = offset_in_page(data);
unsigned int len = skb_headlen(skb);
...
tx->offset = offset;
tx->size = len;

Although in the slot counting it calculates it correctly:
DIV_ROUND_UP(offset + len, PAGE_SIZE)

Am I missing something?

Zoli

On 04/12/14 15:53, David Vrabel wrote:
> On 04/12/14 15:36, Anthony Wright wrote:
>>> On 01/12/14 14:22, David Vrabel wrote:
>>> This VIF protocol is weird. The first slot contains a txreq with a
>>> size
>>> for the total length of the packet, subsequent slots have sizes for
>>> that
>>> fragment only.
>>>
>>> netback then has to calculate how long the first slot is, by
>>> subtracting
>>> all the size from the following slots.
>>>
>>> So something has gone wrong but it's not obvious what it is. Any
>>> chance
>>> you can dump the ring state when it happens?
>>
>> We think we've worked out how to dump the ring state, please see below.
>
> We need the full contents of the ring which isn't currently available
> via debugfs and I haven't had time to put together a debug patch to make
> it available.
>
> 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 Dec 05 12:49:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:49:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwsJh-0000vv-TM; Fri, 05 Dec 2014 12:49:01 +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 1XwsJg-0000vX-AS
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 12:49:00 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	21/40-17694-BB9A1845; Fri, 05 Dec 2014 12:48:59 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417783738!11375644!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25626 invoked from network); 5 Dec 2014 12:48:59 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 12:48:59 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so1298886wid.9
	for <xen-devel@lists.xensource.com>;
	Fri, 05 Dec 2014 04:48: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=lXQBIiDDJXLc8cn4uJ7uipgFEKHiN6uIfSeHeVzwsuo=;
	b=OW0krz2EqE1/Zto962XVn3xWxaisZSerdlW1uZ6MZzDOstISNQOmEfo+CJLZwu8d9Z
	Cg2q783/mNYJmki/XHMasPp2Te6SN7E42v1idQOZx5umP88RlUyI4RyNJThAAkqBc6HP
	HLvs7O059Mz7yxvfnj05cIesFuyLoDbvUC39tYPTAW9hDkKRi4KRCOREczqEICr4aUnh
	mTEMP4Xd6IgqfFiNYq5VKf6uD/jLLouiijFUYF+Owv1RbQaGEERhULUJR39sZz+KevbC
	eoOPVj7umZi7QDhDv3+my3ks7xDDQ/QZtLLqYUZqtgyTFDo7z0EdJWlgvspHMf9+ovm/
	cM0g==
X-Gm-Message-State: ALoCoQnR27HGYiAQcFhfZ7ckpsQYSoyi5ofloNjl3E5BWYVk/aDa+FPuh/pmC3z9+X9ufhFuwKxq
X-Received: by 10.180.21.140 with SMTP id v12mr4012932wie.44.1417783738375;
	Fri, 05 Dec 2014 04:48:58 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id p5sm2173735wix.7.2014.12.05.04.48.57
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 04:48:57 -0800 (PST)
Message-ID: <5481A9BA.1000009@linaro.org>
Date: Fri, 05 Dec 2014 12:48:58 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, 
	Anthony Wright <anthony@overnetdata.com>
References: <19758084.30.1417707380178.JavaMail.root@zimbra.overnetdata.com>
	<54808372.8090102@citrix.com>
In-Reply-To: <54808372.8090102@citrix.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.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-Transfer-Encoding: 7bit
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,

Maybe I'm misreading it, but it seems to me that netfront doesn't slice 
up the linear buffer at all, just blindly sends it. In xennet_start_xmit:

unsigned int offset = offset_in_page(data);
unsigned int len = skb_headlen(skb);
...
tx->offset = offset;
tx->size = len;

Although in the slot counting it calculates it correctly:
DIV_ROUND_UP(offset + len, PAGE_SIZE)

Am I missing something?

Zoli

On 04/12/14 15:53, David Vrabel wrote:
> On 04/12/14 15:36, Anthony Wright wrote:
>>> On 01/12/14 14:22, David Vrabel wrote:
>>> This VIF protocol is weird. The first slot contains a txreq with a
>>> size
>>> for the total length of the packet, subsequent slots have sizes for
>>> that
>>> fragment only.
>>>
>>> netback then has to calculate how long the first slot is, by
>>> subtracting
>>> all the size from the following slots.
>>>
>>> So something has gone wrong but it's not obvious what it is. Any
>>> chance
>>> you can dump the ring state when it happens?
>>
>> We think we've worked out how to dump the ring state, please see below.
>
> We need the full contents of the ring which isn't currently available
> via debugfs and I haven't had time to put together a debug patch to make
> it available.
>
> 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 Dec 05 12:51:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:51:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwsM6-00012N-MB; Fri, 05 Dec 2014 12:51:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwsM5-00012G-Tz
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:51:30 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	68/E2-31453-15AA1845; Fri, 05 Dec 2014 12:51:29 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417783887!11813283!1
X-Originating-IP: [66.165.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 7065 invoked from network); 5 Dec 2014 12:51:28 -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;
	5 Dec 2014 12:51:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200321011"
Received: from ukmail1.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, 5 Dec 2014 07:51: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 1XwsM1-0005zH-Uf;
	Fri, 05 Dec 2014 12:51:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwsM1-00076z-LX;
	Fri, 05 Dec 2014 12:51:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.43597.499751.694328@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 12:51:25 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141205123031.GB20558@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141205123031.GB20558@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in systemd"):
> On Fri, Dec 05, Ian Jackson wrote:
> > I think the only way to make this work properly is to factor the
> > necessary parts out of init.d/xencommons into a new script which can
> > be used by both xencommons and systemd.  I'm not sure such a patch
> > would be appropriate for 4.5 at this stage.
> 
> Yes, a helper script to launch just xenstored would help. But which part
> would do the final "exec"? Perhaps the sysv script has to fork a shell
> like its done above. I will have a look at this. 

If there's no other way to do it, you could have the helper script
take an argument (or a named (environment) parameter) to discover
whether to call exec.

> Are you opposed to the idea to support XENSTORED_TRACE for systemd right
> in 4.5.0?

Ideally I would like to support XENSTORED_TRACE for systemd in 4.5.0.

But I do not want to duplicate the functionality at all.  systemd
seems to make it difficult to support XENSTORED_TRACE without either
duplicating functionality or refactoring the existing init.d script.
(Indeed the very fact that XENSTORED_TRACE does not work with systemd
right now is due to the systemd startup of xenstored being decoupled
from the init script code which handles XENSTORED_TRACE.  I seem to
remember making some comments about this kind of thing at the time...)

And I am currently unconvinced that refactoring things at this stage
of the 4.5 release is appropriate.  But others may have a different
view.

Can systemd not launch these daemons by running the existing
xencommons et al init scripts ?  Obviously that won't give you all of
systemd's shiny features but IMO it ought to work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 12:51:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 12:51:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwsM6-00012N-MB; Fri, 05 Dec 2014 12:51:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwsM5-00012G-Tz
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 12:51:30 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	68/E2-31453-15AA1845; Fri, 05 Dec 2014 12:51:29 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417783887!11813283!1
X-Originating-IP: [66.165.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 7065 invoked from network); 5 Dec 2014 12:51:28 -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;
	5 Dec 2014 12:51:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200321011"
Received: from ukmail1.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, 5 Dec 2014 07:51: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 1XwsM1-0005zH-Uf;
	Fri, 05 Dec 2014 12:51:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwsM1-00076z-LX;
	Fri, 05 Dec 2014 12:51:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.43597.499751.694328@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 12:51:25 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141205123031.GB20558@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141205123031.GB20558@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in systemd"):
> On Fri, Dec 05, Ian Jackson wrote:
> > I think the only way to make this work properly is to factor the
> > necessary parts out of init.d/xencommons into a new script which can
> > be used by both xencommons and systemd.  I'm not sure such a patch
> > would be appropriate for 4.5 at this stage.
> 
> Yes, a helper script to launch just xenstored would help. But which part
> would do the final "exec"? Perhaps the sysv script has to fork a shell
> like its done above. I will have a look at this. 

If there's no other way to do it, you could have the helper script
take an argument (or a named (environment) parameter) to discover
whether to call exec.

> Are you opposed to the idea to support XENSTORED_TRACE for systemd right
> in 4.5.0?

Ideally I would like to support XENSTORED_TRACE for systemd in 4.5.0.

But I do not want to duplicate the functionality at all.  systemd
seems to make it difficult to support XENSTORED_TRACE without either
duplicating functionality or refactoring the existing init.d script.
(Indeed the very fact that XENSTORED_TRACE does not work with systemd
right now is due to the systemd startup of xenstored being decoupled
from the init script code which handles XENSTORED_TRACE.  I seem to
remember making some comments about this kind of thing at the time...)

And I am currently unconvinced that refactoring things at this stage
of the 4.5 release is appropriate.  But others may have a different
view.

Can systemd not launch these daemons by running the existing
xencommons et al init scripts ?  Obviously that won't give you all of
systemd's shiny features but IMO it ought to work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 13:28:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 13:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwsv0-0002Au-Ld; Fri, 05 Dec 2014 13:27:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xwsuz-0002An-G0
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 13:27:33 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	8D/4E-24859-4C2B1845; Fri, 05 Dec 2014 13:27:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417786052!7629712!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2912 invoked from network); 5 Dec 2014 13:27:32 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 13:27:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417786052; l=1087;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=ngKMvqFhyFyn1w3DJg4g8yv5Gvc=;
	b=yoo7X0HGb/kc/cW+Q9wLDslLkwhbWjWZlvC93pv0E234mBclFFaq/aM4lmt7lKzSOLA
	5o6ND5Zzg4tcpR5VKwNW9mOpzzBxCh0r9jBECn8/D+QlWP7LiM7Wcg7lCA/mnXKA5GRMe
	VRrXj5BobvB0PUVkD+RvYI/GOtFWZCpsweA=
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.2 AUTH) with ESMTPSA id z01be8qB5DRNR30
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 14:27:23 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A0F795015E; Fri,  5 Dec 2014 14:27:23 +0100 (CET)
Date: Fri, 5 Dec 2014 14:27:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141205132723.GA4010@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<21633.41713.481177.905257@mariner.uk.xensource.com>
	<20141205122620.GA20558@aepfle.de>
	<21633.43125.817078.380788@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21633.43125.817078.380788@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Ian Jackson wrote:

> Olaf Hering writes ("Re: [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to sysconfig.xencommons"):
> > On Fri, Dec 05, Ian Jackson wrote:
> > > This patch looks like just the hook.  It seems to be missing the part
> > > where the actual selinux context is defined and plumbed through.
> > 
> > The context in xen source is "none". As asked in the cover letter (which
> > unfortunately got send to just Konrad and xen-devel, no idea how to fix
> > that) a configure --with-something may be the way to inject it into the
> > sources, if required.
> 
> I confess I don't know very much about selinux, but shouldn't we be
> providing a reasonable default policy, rather than leaving it to the
> distro or user to pass special options to configure ?  Or are things
> in the selinux world so fragmented or fast-moving that such a generic
> policy couldn't be written ?

I know nothing about SELinux.  Not sure why a context= is required
anyway.  But I can find out next week if noone else has an idea how to
deal with SELinux.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 13:28:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 13:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwsv0-0002Au-Ld; Fri, 05 Dec 2014 13:27:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xwsuz-0002An-G0
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 13:27:33 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	8D/4E-24859-4C2B1845; Fri, 05 Dec 2014 13:27:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-31.messagelabs.com!1417786052!7629712!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2912 invoked from network); 5 Dec 2014 13:27:32 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 13:27:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417786052; l=1087;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=ngKMvqFhyFyn1w3DJg4g8yv5Gvc=;
	b=yoo7X0HGb/kc/cW+Q9wLDslLkwhbWjWZlvC93pv0E234mBclFFaq/aM4lmt7lKzSOLA
	5o6ND5Zzg4tcpR5VKwNW9mOpzzBxCh0r9jBECn8/D+QlWP7LiM7Wcg7lCA/mnXKA5GRMe
	VRrXj5BobvB0PUVkD+RvYI/GOtFWZCpsweA=
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.2 AUTH) with ESMTPSA id z01be8qB5DRNR30
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 14:27:23 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A0F795015E; Fri,  5 Dec 2014 14:27:23 +0100 (CET)
Date: Fri, 5 Dec 2014 14:27:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141205132723.GA4010@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<21633.41713.481177.905257@mariner.uk.xensource.com>
	<20141205122620.GA20558@aepfle.de>
	<21633.43125.817078.380788@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21633.43125.817078.380788@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Ian Jackson wrote:

> Olaf Hering writes ("Re: [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to sysconfig.xencommons"):
> > On Fri, Dec 05, Ian Jackson wrote:
> > > This patch looks like just the hook.  It seems to be missing the part
> > > where the actual selinux context is defined and plumbed through.
> > 
> > The context in xen source is "none". As asked in the cover letter (which
> > unfortunately got send to just Konrad and xen-devel, no idea how to fix
> > that) a configure --with-something may be the way to inject it into the
> > sources, if required.
> 
> I confess I don't know very much about selinux, but shouldn't we be
> providing a reasonable default policy, rather than leaving it to the
> distro or user to pass special options to configure ?  Or are things
> in the selinux world so fragmented or fast-moving that such a generic
> policy couldn't be written ?

I know nothing about SELinux.  Not sure why a context= is required
anyway.  But I can find out next week if noone else has an idea how to
deal with SELinux.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 13:31:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 13:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwsyn-0002KD-FD; Fri, 05 Dec 2014 13:31:29 +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 1Xwsyl-0002K5-Bn
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 13:31:27 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	46/14-23865-EA3B1845; Fri, 05 Dec 2014 13:31:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417786286!11368757!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30848 invoked from network); 5 Dec 2014 13:31:26 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 13:31:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417786286; l=358;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=OWV/TZ0ccFR10oyfS+IW8S1TZC8=;
	b=NPp47ZPyYSv2eUHUyDJe8TC59z78p1ToxUN0ANX5B6whkdY1z1UdbDnepCyQNQAu44O
	CMD+yY1C0uTEMbsulTG4EH6OrEWmdxF/3xIeUlilga9YlodQ5N1qBrUAHIcdEuwH9fWfT
	7Q/Qj2WK1a6bNP3ui5M/RPIEHxKiNUUK6bA=
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.2 AUTH) with ESMTPSA id a0776aqB5DVITKa
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 14:31:18 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 047215015E; Fri,  5 Dec 2014 14:31:17 +0100 (CET)
Date: Fri, 5 Dec 2014 14:31:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141205133117.GA4248@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141205123031.GB20558@aepfle.de>
	<21633.43597.499751.694328@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21633.43597.499751.694328@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Ian Jackson wrote:

> Can systemd not launch these daemons by running the existing
> xencommons et al init scripts ?  Obviously that won't give you all of
> systemd's shiny features but IMO it ought to work.

I think the point was to let systemd pass the file descriptors. Thats why
the service file does the "exec xenstored".

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 13:31:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 13:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwsyn-0002KD-FD; Fri, 05 Dec 2014 13:31:29 +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 1Xwsyl-0002K5-Bn
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 13:31:27 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	46/14-23865-EA3B1845; Fri, 05 Dec 2014 13:31:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417786286!11368757!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30848 invoked from network); 5 Dec 2014 13:31:26 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 13:31:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417786286; l=358;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=OWV/TZ0ccFR10oyfS+IW8S1TZC8=;
	b=NPp47ZPyYSv2eUHUyDJe8TC59z78p1ToxUN0ANX5B6whkdY1z1UdbDnepCyQNQAu44O
	CMD+yY1C0uTEMbsulTG4EH6OrEWmdxF/3xIeUlilga9YlodQ5N1qBrUAHIcdEuwH9fWfT
	7Q/Qj2WK1a6bNP3ui5M/RPIEHxKiNUUK6bA=
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.2 AUTH) with ESMTPSA id a0776aqB5DVITKa
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 14:31:18 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 047215015E; Fri,  5 Dec 2014 14:31:17 +0100 (CET)
Date: Fri, 5 Dec 2014 14:31:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141205133117.GA4248@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141205123031.GB20558@aepfle.de>
	<21633.43597.499751.694328@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21633.43597.499751.694328@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Ian Jackson wrote:

> Can systemd not launch these daemons by running the existing
> xencommons et al init scripts ?  Obviously that won't give you all of
> systemd's shiny features but IMO it ought to work.

I think the point was to let systemd pass the file descriptors. Thats why
the service file does the "exec xenstored".

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 13:47:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 13:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwtDa-0002wG-UY; Fri, 05 Dec 2014 13:46:46 +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 1XwtDZ-0002wB-CX
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 13:46:45 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	B2/2D-19763-447B1845; Fri, 05 Dec 2014 13:46:44 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417787201!6492596!1
X-Originating-IP: [64.18.0.139]
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 17057 invoked from network); 5 Dec 2014 13:46:43 -0000
Received: from exprod5og121.obsmtp.com (HELO exprod5og121.obsmtp.com)
	(64.18.0.139)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2014 13:46:43 -0000
Received: from mail-lb0-f179.google.com ([209.85.217.179]) (using TLSv1) by
	exprod5ob121.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVIG3QaQAy92V6nlKX+qopoHyUX4LwuRi@postini.com;
	Fri, 05 Dec 2014 05:46:43 PST
Received: by mail-lb0-f179.google.com with SMTP id z11so545680lbi.38
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 05:46:40 -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=8+ziDh9IdmjXNG+eYANLCI+ZWsI/mBFCPoilLCzOJFU=;
	b=hEtee86fMyWIrKFzppeRHWXbYLYwUXnGdMGxdvjT4kEydLuD567ieSEoqQsg7JQTJq
	myD0DxaYZO/aop77cvQHTF+C1reeyapvYlBv8xzZ0EBdVcWM1y8QwAZJfS9KFihRl13I
	+JykxIAn3e9+p2RDPcTJSgIFaMn9Iby797+q0=
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=8+ziDh9IdmjXNG+eYANLCI+ZWsI/mBFCPoilLCzOJFU=;
	b=j4DD/7uvUZOYJuXeuIGWOKRi1TiC0lD4GVcHTjiJF3LA9nBF9zCJhqjeGdGzbNXekD
	rHx8RaGheKsG4w8thBSG2rOkeZ4mWc60bNjOSqi5Bl02VrCcndpIqI1tB6ZqMuy9bEJN
	zr8JojH+LxSDmWJ3SmaUNnZS9VJp7zZKLFmfWpNfhY79ul2ow2YuEL60GkuxNlez9F4t
	HaxvTEIcVD1W3gSqD6LwAr0DypD1sRG/IZONSrDeTkRYRsbMP0ebK9/yDrNE5MZu/9NM
	u/ANxhLcgJ8sEjGxj6U91M61E+REvGVxIvGL28rGHBIz++NHUqVKB27A55ctjdYDB35i
	7p0A==
X-Gm-Message-State: ALoCoQnM1hkkOhkFlG8MBn+gi80c/MhXHG1NDccuGVUhTTyOgD9l9YPD4WJCnbwZLLFNys/lWhIXyca9BhOeE915XEwEW8z3ys8wnYfkr8BSBdWgygtVR4tDGB/YX4aab1IomS6qRSUx+lF2Ge4aFr4WUz1cfxUNpQ==
X-Received: by 10.112.234.201 with SMTP id ug9mr2926632lbc.79.1417787200000;
	Fri, 05 Dec 2014 05:46:40 -0800 (PST)
X-Received: by 10.112.234.201 with SMTP id ug9mr2926623lbc.79.1417787199919;
	Fri, 05 Dec 2014 05:46:39 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id l1sm7259339lae.11.2014.12.05.05.46.38
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Fri, 05 Dec 2014 05:46:39 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 15:46:36 +0200
Message-Id: <1417787196-3313-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] [PATCH] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UART is not able to receive bytes when idle mode is not
configured properly. When we use Xen with old Linux
Kernel (for example 3.8) this kernel configures UART
idle mode even if the UART node in device tree is absent.
So UART works normally in this case. But new Linux
Kernel (3.12 and upper) doesn't configure idle mode for
UART and UART can not work normally in this case.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/drivers/char/omap-uart.c | 3 +++
 xen/include/xen/8250-uart.h  | 4 ++++
 2 files changed, 7 insertions(+)

diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
index a798b8d..16d1454 100644
--- a/xen/drivers/char/omap-uart.c
+++ b/xen/drivers/char/omap-uart.c
@@ -195,6 +195,9 @@ static void __init omap_uart_init_preirq(struct serial_port *port)
     omap_write(uart, UART_MCR, UART_MCR_DTR|UART_MCR_RTS);
 
     omap_write(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
+
+    /* setup iddle mode */
+    omap_write(uart, UART_SYSC, OMAP_UART_SYSC_DEF_CONF);
 }
 
 static void __init omap_uart_init_postirq(struct serial_port *port)
diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
index a682bae..304b9dd 100644
--- a/xen/include/xen/8250-uart.h
+++ b/xen/include/xen/8250-uart.h
@@ -32,6 +32,7 @@
 #define UART_MCR          0x04    /* Modem control        */
 #define UART_LSR          0x05    /* line status          */
 #define UART_MSR          0x06    /* Modem status         */
+#define UART_SYSC         0x15    /* System configuration register */
 #define UART_USR          0x1f    /* Status register (DW) */
 #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
 #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
@@ -145,6 +146,9 @@
 /* SCR register bitmasks */
 #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 << 7)
 
+/* System configuration register */
+#define OMAP_UART_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is enabled */
+
 #endif /* __XEN_8250_UART_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 Fri Dec 05 13:47:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 13:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwtDa-0002wG-UY; Fri, 05 Dec 2014 13:46:46 +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 1XwtDZ-0002wB-CX
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 13:46:45 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	B2/2D-19763-447B1845; Fri, 05 Dec 2014 13:46:44 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417787201!6492596!1
X-Originating-IP: [64.18.0.139]
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 17057 invoked from network); 5 Dec 2014 13:46:43 -0000
Received: from exprod5og121.obsmtp.com (HELO exprod5og121.obsmtp.com)
	(64.18.0.139)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Dec 2014 13:46:43 -0000
Received: from mail-lb0-f179.google.com ([209.85.217.179]) (using TLSv1) by
	exprod5ob121.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVIG3QaQAy92V6nlKX+qopoHyUX4LwuRi@postini.com;
	Fri, 05 Dec 2014 05:46:43 PST
Received: by mail-lb0-f179.google.com with SMTP id z11so545680lbi.38
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 05:46:40 -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=8+ziDh9IdmjXNG+eYANLCI+ZWsI/mBFCPoilLCzOJFU=;
	b=hEtee86fMyWIrKFzppeRHWXbYLYwUXnGdMGxdvjT4kEydLuD567ieSEoqQsg7JQTJq
	myD0DxaYZO/aop77cvQHTF+C1reeyapvYlBv8xzZ0EBdVcWM1y8QwAZJfS9KFihRl13I
	+JykxIAn3e9+p2RDPcTJSgIFaMn9Iby797+q0=
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=8+ziDh9IdmjXNG+eYANLCI+ZWsI/mBFCPoilLCzOJFU=;
	b=j4DD/7uvUZOYJuXeuIGWOKRi1TiC0lD4GVcHTjiJF3LA9nBF9zCJhqjeGdGzbNXekD
	rHx8RaGheKsG4w8thBSG2rOkeZ4mWc60bNjOSqi5Bl02VrCcndpIqI1tB6ZqMuy9bEJN
	zr8JojH+LxSDmWJ3SmaUNnZS9VJp7zZKLFmfWpNfhY79ul2ow2YuEL60GkuxNlez9F4t
	HaxvTEIcVD1W3gSqD6LwAr0DypD1sRG/IZONSrDeTkRYRsbMP0ebK9/yDrNE5MZu/9NM
	u/ANxhLcgJ8sEjGxj6U91M61E+REvGVxIvGL28rGHBIz++NHUqVKB27A55ctjdYDB35i
	7p0A==
X-Gm-Message-State: ALoCoQnM1hkkOhkFlG8MBn+gi80c/MhXHG1NDccuGVUhTTyOgD9l9YPD4WJCnbwZLLFNys/lWhIXyca9BhOeE915XEwEW8z3ys8wnYfkr8BSBdWgygtVR4tDGB/YX4aab1IomS6qRSUx+lF2Ge4aFr4WUz1cfxUNpQ==
X-Received: by 10.112.234.201 with SMTP id ug9mr2926632lbc.79.1417787200000;
	Fri, 05 Dec 2014 05:46:40 -0800 (PST)
X-Received: by 10.112.234.201 with SMTP id ug9mr2926623lbc.79.1417787199919;
	Fri, 05 Dec 2014 05:46:39 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id l1sm7259339lae.11.2014.12.05.05.46.38
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Fri, 05 Dec 2014 05:46:39 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 15:46:36 +0200
Message-Id: <1417787196-3313-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] [PATCH] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UART is not able to receive bytes when idle mode is not
configured properly. When we use Xen with old Linux
Kernel (for example 3.8) this kernel configures UART
idle mode even if the UART node in device tree is absent.
So UART works normally in this case. But new Linux
Kernel (3.12 and upper) doesn't configure idle mode for
UART and UART can not work normally in this case.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
 xen/drivers/char/omap-uart.c | 3 +++
 xen/include/xen/8250-uart.h  | 4 ++++
 2 files changed, 7 insertions(+)

diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
index a798b8d..16d1454 100644
--- a/xen/drivers/char/omap-uart.c
+++ b/xen/drivers/char/omap-uart.c
@@ -195,6 +195,9 @@ static void __init omap_uart_init_preirq(struct serial_port *port)
     omap_write(uart, UART_MCR, UART_MCR_DTR|UART_MCR_RTS);
 
     omap_write(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
+
+    /* setup iddle mode */
+    omap_write(uart, UART_SYSC, OMAP_UART_SYSC_DEF_CONF);
 }
 
 static void __init omap_uart_init_postirq(struct serial_port *port)
diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
index a682bae..304b9dd 100644
--- a/xen/include/xen/8250-uart.h
+++ b/xen/include/xen/8250-uart.h
@@ -32,6 +32,7 @@
 #define UART_MCR          0x04    /* Modem control        */
 #define UART_LSR          0x05    /* line status          */
 #define UART_MSR          0x06    /* Modem status         */
+#define UART_SYSC         0x15    /* System configuration register */
 #define UART_USR          0x1f    /* Status register (DW) */
 #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
 #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
@@ -145,6 +146,9 @@
 /* SCR register bitmasks */
 #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 << 7)
 
+/* System configuration register */
+#define OMAP_UART_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is enabled */
+
 #endif /* __XEN_8250_UART_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 Fri Dec 05 13:51:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 13: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 1XwtIO-00035F-LR; Fri, 05 Dec 2014 13:51: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 1XwtIN-000357-MZ
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 13:51:43 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	12/2F-14214-E68B1845; Fri, 05 Dec 2014 13:51:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417787501!8906333!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31080 invoked from network); 5 Dec 2014 13:51:42 -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; 5 Dec 2014 13:51:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 13:51:41 +0000
Message-Id: <5481C67D020000780004D2D1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 13:51:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part784DA07D.2__="
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH] have architectures specify the number of PIRQs
 a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part784DA07D.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The current value of nr_static_irqs + 256 is often too small for larger
systems. Make it dependent on CPU count and number of IO-APIC pins on
x86, and (until it obtains PCI support) simply NR_IRQS on ARM.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
This is meant to be an alternative proposal to David's:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00421.html=
=20

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -596,13 +596,14 @@ Force or disable use of EFI runtime serv
 ### extra\_guest\_irqs
 > `=3D [<domU number>][,<dom0 number>]`
=20
-> Default: `32,256`
+> Default: `32,<variable>`
=20
 Change the number of PIRQs available for guests.  The optional first =
number is
 common for all domUs, while the optional second number (preceded by a =
comma)
 is for dom0.  Changing the setting for domU has no impact on dom0 and =
vice
 versa.  For example to change dom0 without changing domU, use
-`extra_guest_irqs=3D,512`
+`extra_guest_irqs=3D,512`.  The default value for Dom0 and an eventual =
separate
+hardware domain is architecture dependent.
=20
 ### flask\_enabled
 > `=3D <integer>`
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -101,7 +101,7 @@ static void __init parse_dom0_max_vcpus(
 }
 custom_param("dom0_max_vcpus", parse_dom0_max_vcpus);
=20
-struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
+unsigned int __init dom0_max_vcpus(void)
 {
     unsigned max_vcpus;
=20
@@ -113,6 +113,13 @@ struct vcpu *__init alloc_dom0_vcpu0(str
     if ( max_vcpus > MAX_VIRT_CPUS )
         max_vcpus =3D MAX_VIRT_CPUS;
=20
+    return max_vcpus;
+}
+
+struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
+{
+    unsigned int max_vcpus =3D dom0_max_vcpus();
+
     dom0->vcpu =3D xzalloc_array(struct vcpu *, max_vcpus);
     if ( !dom0->vcpu )
         return NULL;
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -33,6 +33,7 @@
 #include <asm/smp.h>
 #include <asm/desc.h>
 #include <asm/msi.h>
+#include <asm/setup.h>
 #include <mach_apic.h>
 #include <io_ports.h>
 #include <public/physdev.h>
@@ -2606,3 +2607,14 @@ void __init init_ioapic_mappings(void)
            nr_irqs_gsi, nr_irqs - nr_irqs_gsi);
 }
=20
+unsigned int arch_hwdom_irqs(domid_t domid)
+{
+    unsigned int n =3D fls(num_present_cpus());
+
+    if ( !domid )
+        n =3D min(n, dom0_max_vcpus());
+    n =3D min(nr_irqs_gsi + n * NR_DYNAMIC_VECTORS, nr_irqs);
+    printk("Dom%d has maximum %u PIRQs\n", domid, n);
+
+    return n;
+}
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -231,14 +231,14 @@ static int late_hwdom_init(struct domain
 #endif
 }
=20
-static unsigned int __read_mostly extra_dom0_irqs =3D 256;
+static unsigned int __read_mostly extra_hwdom_irqs;
 static unsigned int __read_mostly extra_domU_irqs =3D 32;
 static void __init parse_extra_guest_irqs(const char *s)
 {
     if ( isdigit(*s) )
         extra_domU_irqs =3D simple_strtoul(s, &s, 0);
     if ( *s =3D=3D ',' && isdigit(*++s) )
-        extra_dom0_irqs =3D simple_strtoul(s, &s, 0);
+        extra_hwdom_irqs =3D simple_strtoul(s, &s, 0);
 }
 custom_param("extra_guest_irqs", parse_extra_guest_irqs);
=20
@@ -326,7 +326,8 @@ struct domain *domain_create(
         if ( !is_hardware_domain(d) )
             d->nr_pirqs =3D nr_static_irqs + extra_domU_irqs;
         else
-            d->nr_pirqs =3D nr_static_irqs + extra_dom0_irqs;
+            d->nr_pirqs =3D extra_hwdom_irqs ? nr_static_irqs + extra_hwdo=
m_irqs
+                                           : arch_hwdom_irqs(domid);
         if ( d->nr_pirqs > nr_irqs )
             d->nr_pirqs =3D nr_irqs;
=20
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -21,10 +21,10 @@ struct arch_irq_desc {
=20
 #define NR_LOCAL_IRQS	32
 #define NR_IRQS		1024
-#define nr_irqs NR_IRQS
=20
 #define nr_irqs NR_IRQS
 #define nr_static_irqs NR_IRQS
+#define arch_hwdom_irqs(domid) NR_IRQS
=20
 struct irq_desc;
 struct irqaction;
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -35,6 +35,8 @@ int construct_dom0(
 unsigned long initial_images_nrpages(void);
 void discard_initial_images(void);
=20
+unsigned int dom0_max_vcpus(void);
+
 int xen_in_range(unsigned long mfn);
=20
 void microcode_grab_module(
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -168,4 +168,8 @@ static inline void set_native_irq_info(u
=20
 unsigned int set_desc_affinity(struct irq_desc *, const cpumask_t *);
=20
+#ifndef arch_hwdom_irqs
+unsigned int arch_hwdom_irqs(domid_t);
+#endif
+
 #endif /* __XEN_IRQ_H__ */



--=__Part784DA07D.2__=
Content-Type: text/plain; name="x86-bump-extra-Dom0-IRQs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-bump-extra-Dom0-IRQs.patch"

have architectures specify the number of PIRQs a hardware domain gets=0A=0A=
The current value of nr_static_irqs + 256 is often too small for larger=0As=
ystems. Make it dependent on CPU count and number of IO-APIC pins =
on=0Ax86, and (until it obtains PCI support) simply NR_IRQS on ARM.=0A=0ASi=
gned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0AThis is meant to be =
an alternative proposal to David's:=0Ahttp://lists.xenproject.org/archives/=
html/xen-devel/2014-12/msg00421.html=0A=0A--- a/docs/misc/xen-command-line.=
markdown=0A+++ b/docs/misc/xen-command-line.markdown=0A@@ -596,13 +596,14 =
@@ Force or disable use of EFI runtime serv=0A ### extra\_guest\_irqs=0A > =
`=3D [<domU number>][,<dom0 number>]`=0A =0A-> Default: `32,256`=0A+> =
Default: `32,<variable>`=0A =0A Change the number of PIRQs available for =
guests.  The optional first number is=0A common for all domUs, while the =
optional second number (preceded by a comma)=0A is for dom0.  Changing the =
setting for domU has no impact on dom0 and vice=0A versa.  For example to =
change dom0 without changing domU, use=0A-`extra_guest_irqs=3D,512`=0A+`ext=
ra_guest_irqs=3D,512`.  The default value for Dom0 and an eventual =
separate=0A+hardware domain is architecture dependent.=0A =0A ### =
flask\_enabled=0A > `=3D <integer>`=0A--- a/xen/arch/x86/domain_build.c=0A+=
++ b/xen/arch/x86/domain_build.c=0A@@ -101,7 +101,7 @@ static void __init =
parse_dom0_max_vcpus(=0A }=0A custom_param("dom0_max_vcpus", parse_dom0_max=
_vcpus);=0A =0A-struct vcpu *__init alloc_dom0_vcpu0(struct domain =
*dom0)=0A+unsigned int __init dom0_max_vcpus(void)=0A {=0A     unsigned =
max_vcpus;=0A =0A@@ -113,6 +113,13 @@ struct vcpu *__init alloc_dom0_vcpu0(=
str=0A     if ( max_vcpus > MAX_VIRT_CPUS )=0A         max_vcpus =3D =
MAX_VIRT_CPUS;=0A =0A+    return max_vcpus;=0A+}=0A+=0A+struct vcpu =
*__init alloc_dom0_vcpu0(struct domain *dom0)=0A+{=0A+    unsigned int =
max_vcpus =3D dom0_max_vcpus();=0A+=0A     dom0->vcpu =3D xzalloc_array(str=
uct vcpu *, max_vcpus);=0A     if ( !dom0->vcpu )=0A         return =
NULL;=0A--- a/xen/arch/x86/io_apic.c=0A+++ b/xen/arch/x86/io_apic.c=0A@@ =
-33,6 +33,7 @@=0A #include <asm/smp.h>=0A #include <asm/desc.h>=0A =
#include <asm/msi.h>=0A+#include <asm/setup.h>=0A #include <mach_apic.h>=0A=
 #include <io_ports.h>=0A #include <public/physdev.h>=0A@@ -2606,3 =
+2607,14 @@ void __init init_ioapic_mappings(void)=0A            nr_irqs_gs=
i, nr_irqs - nr_irqs_gsi);=0A }=0A =0A+unsigned int arch_hwdom_irqs(domid_t=
 domid)=0A+{=0A+    unsigned int n =3D fls(num_present_cpus());=0A+=0A+    =
if ( !domid )=0A+        n =3D min(n, dom0_max_vcpus());=0A+    n =3D =
min(nr_irqs_gsi + n * NR_DYNAMIC_VECTORS, nr_irqs);=0A+    printk("Dom%d =
has maximum %u PIRQs\n", domid, n);=0A+=0A+    return n;=0A+}=0A--- =
a/xen/common/domain.c=0A+++ b/xen/common/domain.c=0A@@ -231,14 +231,14 @@ =
static int late_hwdom_init(struct domain=0A #endif=0A }=0A =0A-static =
unsigned int __read_mostly extra_dom0_irqs =3D 256;=0A+static unsigned int =
__read_mostly extra_hwdom_irqs;=0A static unsigned int __read_mostly =
extra_domU_irqs =3D 32;=0A static void __init parse_extra_guest_irqs(const =
char *s)=0A {=0A     if ( isdigit(*s) )=0A         extra_domU_irqs =3D =
simple_strtoul(s, &s, 0);=0A     if ( *s =3D=3D ',' && isdigit(*++s) )=0A- =
       extra_dom0_irqs =3D simple_strtoul(s, &s, 0);=0A+        extra_hwdom=
_irqs =3D simple_strtoul(s, &s, 0);=0A }=0A custom_param("extra_guest_irqs"=
, parse_extra_guest_irqs);=0A =0A@@ -326,7 +326,8 @@ struct domain =
*domain_create(=0A         if ( !is_hardware_domain(d) )=0A             =
d->nr_pirqs =3D nr_static_irqs + extra_domU_irqs;=0A         else=0A-      =
      d->nr_pirqs =3D nr_static_irqs + extra_dom0_irqs;=0A+            =
d->nr_pirqs =3D extra_hwdom_irqs ? nr_static_irqs + extra_hwdom_irqs=0A+   =
                                        : arch_hwdom_irqs(domid);=0A       =
  if ( d->nr_pirqs > nr_irqs )=0A             d->nr_pirqs =3D nr_irqs;=0A =
=0A--- a/xen/include/asm-arm/irq.h=0A+++ b/xen/include/asm-arm/irq.h=0A@@ =
-21,10 +21,10 @@ struct arch_irq_desc {=0A =0A #define NR_LOCAL_IRQS	=
32=0A #define NR_IRQS		1024=0A-#define nr_irqs NR_IRQS=0A =0A =
#define nr_irqs NR_IRQS=0A #define nr_static_irqs NR_IRQS=0A+#define =
arch_hwdom_irqs(domid) NR_IRQS=0A =0A struct irq_desc;=0A struct irqaction;=
=0A--- a/xen/include/asm-x86/setup.h=0A+++ b/xen/include/asm-x86/setup.h=0A=
@@ -35,6 +35,8 @@ int construct_dom0(=0A unsigned long initial_images_nrpag=
es(void);=0A void discard_initial_images(void);=0A =0A+unsigned int =
dom0_max_vcpus(void);=0A+=0A int xen_in_range(unsigned long mfn);=0A =0A =
void microcode_grab_module(=0A--- a/xen/include/xen/irq.h=0A+++ b/xen/inclu=
de/xen/irq.h=0A@@ -168,4 +168,8 @@ static inline void set_native_irq_info(u=
=0A =0A unsigned int set_desc_affinity(struct irq_desc *, const cpumask_t =
*);=0A =0A+#ifndef arch_hwdom_irqs=0A+unsigned int arch_hwdom_irqs(domid_t)=
;=0A+#endif=0A+=0A #endif /* __XEN_IRQ_H__ */=0A
--=__Part784DA07D.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

--=__Part784DA07D.2__=--


From xen-devel-bounces@lists.xen.org Fri Dec 05 13:51:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 13: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 1XwtIO-00035F-LR; Fri, 05 Dec 2014 13:51: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 1XwtIN-000357-MZ
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 13:51:43 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	12/2F-14214-E68B1845; Fri, 05 Dec 2014 13:51:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417787501!8906333!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31080 invoked from network); 5 Dec 2014 13:51:42 -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; 5 Dec 2014 13:51:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 13:51:41 +0000
Message-Id: <5481C67D020000780004D2D1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 13:51:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part784DA07D.2__="
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH] have architectures specify the number of PIRQs
 a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part784DA07D.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The current value of nr_static_irqs + 256 is often too small for larger
systems. Make it dependent on CPU count and number of IO-APIC pins on
x86, and (until it obtains PCI support) simply NR_IRQS on ARM.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
This is meant to be an alternative proposal to David's:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00421.html=
=20

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -596,13 +596,14 @@ Force or disable use of EFI runtime serv
 ### extra\_guest\_irqs
 > `=3D [<domU number>][,<dom0 number>]`
=20
-> Default: `32,256`
+> Default: `32,<variable>`
=20
 Change the number of PIRQs available for guests.  The optional first =
number is
 common for all domUs, while the optional second number (preceded by a =
comma)
 is for dom0.  Changing the setting for domU has no impact on dom0 and =
vice
 versa.  For example to change dom0 without changing domU, use
-`extra_guest_irqs=3D,512`
+`extra_guest_irqs=3D,512`.  The default value for Dom0 and an eventual =
separate
+hardware domain is architecture dependent.
=20
 ### flask\_enabled
 > `=3D <integer>`
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -101,7 +101,7 @@ static void __init parse_dom0_max_vcpus(
 }
 custom_param("dom0_max_vcpus", parse_dom0_max_vcpus);
=20
-struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
+unsigned int __init dom0_max_vcpus(void)
 {
     unsigned max_vcpus;
=20
@@ -113,6 +113,13 @@ struct vcpu *__init alloc_dom0_vcpu0(str
     if ( max_vcpus > MAX_VIRT_CPUS )
         max_vcpus =3D MAX_VIRT_CPUS;
=20
+    return max_vcpus;
+}
+
+struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
+{
+    unsigned int max_vcpus =3D dom0_max_vcpus();
+
     dom0->vcpu =3D xzalloc_array(struct vcpu *, max_vcpus);
     if ( !dom0->vcpu )
         return NULL;
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -33,6 +33,7 @@
 #include <asm/smp.h>
 #include <asm/desc.h>
 #include <asm/msi.h>
+#include <asm/setup.h>
 #include <mach_apic.h>
 #include <io_ports.h>
 #include <public/physdev.h>
@@ -2606,3 +2607,14 @@ void __init init_ioapic_mappings(void)
            nr_irqs_gsi, nr_irqs - nr_irqs_gsi);
 }
=20
+unsigned int arch_hwdom_irqs(domid_t domid)
+{
+    unsigned int n =3D fls(num_present_cpus());
+
+    if ( !domid )
+        n =3D min(n, dom0_max_vcpus());
+    n =3D min(nr_irqs_gsi + n * NR_DYNAMIC_VECTORS, nr_irqs);
+    printk("Dom%d has maximum %u PIRQs\n", domid, n);
+
+    return n;
+}
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -231,14 +231,14 @@ static int late_hwdom_init(struct domain
 #endif
 }
=20
-static unsigned int __read_mostly extra_dom0_irqs =3D 256;
+static unsigned int __read_mostly extra_hwdom_irqs;
 static unsigned int __read_mostly extra_domU_irqs =3D 32;
 static void __init parse_extra_guest_irqs(const char *s)
 {
     if ( isdigit(*s) )
         extra_domU_irqs =3D simple_strtoul(s, &s, 0);
     if ( *s =3D=3D ',' && isdigit(*++s) )
-        extra_dom0_irqs =3D simple_strtoul(s, &s, 0);
+        extra_hwdom_irqs =3D simple_strtoul(s, &s, 0);
 }
 custom_param("extra_guest_irqs", parse_extra_guest_irqs);
=20
@@ -326,7 +326,8 @@ struct domain *domain_create(
         if ( !is_hardware_domain(d) )
             d->nr_pirqs =3D nr_static_irqs + extra_domU_irqs;
         else
-            d->nr_pirqs =3D nr_static_irqs + extra_dom0_irqs;
+            d->nr_pirqs =3D extra_hwdom_irqs ? nr_static_irqs + extra_hwdo=
m_irqs
+                                           : arch_hwdom_irqs(domid);
         if ( d->nr_pirqs > nr_irqs )
             d->nr_pirqs =3D nr_irqs;
=20
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -21,10 +21,10 @@ struct arch_irq_desc {
=20
 #define NR_LOCAL_IRQS	32
 #define NR_IRQS		1024
-#define nr_irqs NR_IRQS
=20
 #define nr_irqs NR_IRQS
 #define nr_static_irqs NR_IRQS
+#define arch_hwdom_irqs(domid) NR_IRQS
=20
 struct irq_desc;
 struct irqaction;
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -35,6 +35,8 @@ int construct_dom0(
 unsigned long initial_images_nrpages(void);
 void discard_initial_images(void);
=20
+unsigned int dom0_max_vcpus(void);
+
 int xen_in_range(unsigned long mfn);
=20
 void microcode_grab_module(
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -168,4 +168,8 @@ static inline void set_native_irq_info(u
=20
 unsigned int set_desc_affinity(struct irq_desc *, const cpumask_t *);
=20
+#ifndef arch_hwdom_irqs
+unsigned int arch_hwdom_irqs(domid_t);
+#endif
+
 #endif /* __XEN_IRQ_H__ */



--=__Part784DA07D.2__=
Content-Type: text/plain; name="x86-bump-extra-Dom0-IRQs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-bump-extra-Dom0-IRQs.patch"

have architectures specify the number of PIRQs a hardware domain gets=0A=0A=
The current value of nr_static_irqs + 256 is often too small for larger=0As=
ystems. Make it dependent on CPU count and number of IO-APIC pins =
on=0Ax86, and (until it obtains PCI support) simply NR_IRQS on ARM.=0A=0ASi=
gned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0AThis is meant to be =
an alternative proposal to David's:=0Ahttp://lists.xenproject.org/archives/=
html/xen-devel/2014-12/msg00421.html=0A=0A--- a/docs/misc/xen-command-line.=
markdown=0A+++ b/docs/misc/xen-command-line.markdown=0A@@ -596,13 +596,14 =
@@ Force or disable use of EFI runtime serv=0A ### extra\_guest\_irqs=0A > =
`=3D [<domU number>][,<dom0 number>]`=0A =0A-> Default: `32,256`=0A+> =
Default: `32,<variable>`=0A =0A Change the number of PIRQs available for =
guests.  The optional first number is=0A common for all domUs, while the =
optional second number (preceded by a comma)=0A is for dom0.  Changing the =
setting for domU has no impact on dom0 and vice=0A versa.  For example to =
change dom0 without changing domU, use=0A-`extra_guest_irqs=3D,512`=0A+`ext=
ra_guest_irqs=3D,512`.  The default value for Dom0 and an eventual =
separate=0A+hardware domain is architecture dependent.=0A =0A ### =
flask\_enabled=0A > `=3D <integer>`=0A--- a/xen/arch/x86/domain_build.c=0A+=
++ b/xen/arch/x86/domain_build.c=0A@@ -101,7 +101,7 @@ static void __init =
parse_dom0_max_vcpus(=0A }=0A custom_param("dom0_max_vcpus", parse_dom0_max=
_vcpus);=0A =0A-struct vcpu *__init alloc_dom0_vcpu0(struct domain =
*dom0)=0A+unsigned int __init dom0_max_vcpus(void)=0A {=0A     unsigned =
max_vcpus;=0A =0A@@ -113,6 +113,13 @@ struct vcpu *__init alloc_dom0_vcpu0(=
str=0A     if ( max_vcpus > MAX_VIRT_CPUS )=0A         max_vcpus =3D =
MAX_VIRT_CPUS;=0A =0A+    return max_vcpus;=0A+}=0A+=0A+struct vcpu =
*__init alloc_dom0_vcpu0(struct domain *dom0)=0A+{=0A+    unsigned int =
max_vcpus =3D dom0_max_vcpus();=0A+=0A     dom0->vcpu =3D xzalloc_array(str=
uct vcpu *, max_vcpus);=0A     if ( !dom0->vcpu )=0A         return =
NULL;=0A--- a/xen/arch/x86/io_apic.c=0A+++ b/xen/arch/x86/io_apic.c=0A@@ =
-33,6 +33,7 @@=0A #include <asm/smp.h>=0A #include <asm/desc.h>=0A =
#include <asm/msi.h>=0A+#include <asm/setup.h>=0A #include <mach_apic.h>=0A=
 #include <io_ports.h>=0A #include <public/physdev.h>=0A@@ -2606,3 =
+2607,14 @@ void __init init_ioapic_mappings(void)=0A            nr_irqs_gs=
i, nr_irqs - nr_irqs_gsi);=0A }=0A =0A+unsigned int arch_hwdom_irqs(domid_t=
 domid)=0A+{=0A+    unsigned int n =3D fls(num_present_cpus());=0A+=0A+    =
if ( !domid )=0A+        n =3D min(n, dom0_max_vcpus());=0A+    n =3D =
min(nr_irqs_gsi + n * NR_DYNAMIC_VECTORS, nr_irqs);=0A+    printk("Dom%d =
has maximum %u PIRQs\n", domid, n);=0A+=0A+    return n;=0A+}=0A--- =
a/xen/common/domain.c=0A+++ b/xen/common/domain.c=0A@@ -231,14 +231,14 @@ =
static int late_hwdom_init(struct domain=0A #endif=0A }=0A =0A-static =
unsigned int __read_mostly extra_dom0_irqs =3D 256;=0A+static unsigned int =
__read_mostly extra_hwdom_irqs;=0A static unsigned int __read_mostly =
extra_domU_irqs =3D 32;=0A static void __init parse_extra_guest_irqs(const =
char *s)=0A {=0A     if ( isdigit(*s) )=0A         extra_domU_irqs =3D =
simple_strtoul(s, &s, 0);=0A     if ( *s =3D=3D ',' && isdigit(*++s) )=0A- =
       extra_dom0_irqs =3D simple_strtoul(s, &s, 0);=0A+        extra_hwdom=
_irqs =3D simple_strtoul(s, &s, 0);=0A }=0A custom_param("extra_guest_irqs"=
, parse_extra_guest_irqs);=0A =0A@@ -326,7 +326,8 @@ struct domain =
*domain_create(=0A         if ( !is_hardware_domain(d) )=0A             =
d->nr_pirqs =3D nr_static_irqs + extra_domU_irqs;=0A         else=0A-      =
      d->nr_pirqs =3D nr_static_irqs + extra_dom0_irqs;=0A+            =
d->nr_pirqs =3D extra_hwdom_irqs ? nr_static_irqs + extra_hwdom_irqs=0A+   =
                                        : arch_hwdom_irqs(domid);=0A       =
  if ( d->nr_pirqs > nr_irqs )=0A             d->nr_pirqs =3D nr_irqs;=0A =
=0A--- a/xen/include/asm-arm/irq.h=0A+++ b/xen/include/asm-arm/irq.h=0A@@ =
-21,10 +21,10 @@ struct arch_irq_desc {=0A =0A #define NR_LOCAL_IRQS	=
32=0A #define NR_IRQS		1024=0A-#define nr_irqs NR_IRQS=0A =0A =
#define nr_irqs NR_IRQS=0A #define nr_static_irqs NR_IRQS=0A+#define =
arch_hwdom_irqs(domid) NR_IRQS=0A =0A struct irq_desc;=0A struct irqaction;=
=0A--- a/xen/include/asm-x86/setup.h=0A+++ b/xen/include/asm-x86/setup.h=0A=
@@ -35,6 +35,8 @@ int construct_dom0(=0A unsigned long initial_images_nrpag=
es(void);=0A void discard_initial_images(void);=0A =0A+unsigned int =
dom0_max_vcpus(void);=0A+=0A int xen_in_range(unsigned long mfn);=0A =0A =
void microcode_grab_module(=0A--- a/xen/include/xen/irq.h=0A+++ b/xen/inclu=
de/xen/irq.h=0A@@ -168,4 +168,8 @@ static inline void set_native_irq_info(u=
=0A =0A unsigned int set_desc_affinity(struct irq_desc *, const cpumask_t =
*);=0A =0A+#ifndef arch_hwdom_irqs=0A+unsigned int arch_hwdom_irqs(domid_t)=
;=0A+#endif=0A+=0A #endif /* __XEN_IRQ_H__ */=0A
--=__Part784DA07D.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

--=__Part784DA07D.2__=--


From xen-devel-bounces@lists.xen.org Fri Dec 05 14:02:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwtSo-0003km-QS; Fri, 05 Dec 2014 14:02:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwtSn-0003kh-LJ
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 14:02:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	35/56-25276-5FAB1845; Fri, 05 Dec 2014 14:02:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417788147!13677885!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 10417 invoked from network); 5 Dec 2014 14:02:28 -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;
	5 Dec 2014 14:02:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200719990"
Message-ID: <1417788145.22808.64.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Fri, 5 Dec 2014 14:02:25 +0000
In-Reply-To: <547F44F5020000660004100F@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>
	<1417189409.23604.62.camel@citrix.com>
	<547F44F5020000660004100F@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-12-02 at 23:14 -0700, Chun Yan Liu wrote:
> 
> >>> On 11/28/2014 at 11:43 PM, in message <1417189409.23604.62.camel@citrix.com>,
> Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> > 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.
>   
> The reason why I post such an overview here before sending next
> version is: I'm puzzled about what should be in libxl and what
> in toolstack after previous discussion. So posted here to seek
> some ideas or agreement first. It's not a full design, not break
> down to libxl and toolstack yet.

I guess I thought we had gotten closer to this than we actually have.

> > 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. 
> 
> About notification API, after looking at lvm, vhd-util and qcow2, 
> I don't think we need it. No extra work needs to do to handle 
> disk snapshot chain. 
> lvm: doesn't support snapshot of snapshot. 
> vhd-util: backing file chain, external snapshot. Don't need to 
>           delete the disk snapshot when deleting domain snapshot. 
> qcow2: 
> * internal disk snapshot: each snapshot increases the refcount 
>   of data, deleting snapshot only decrease the refcount, won't 
>   affect other snapshots. 
> * external disk snapshot: same as vhd-util, backing file chain. 
>   Don't need to delete disk snapshot when deleting domain snapshot.

You don't need to, but might a toolstack (or user) want to consolidate
anyway, e.g. to reduce chain length? (which might otherwise be overly
long.)

> > 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. 
> 
> Like delete a disk snapshot, xl can call external command to do that
> (e.g. qemu-img). But it's better to call qmp to do that.

The toolstack (xl or libvirt) doesn't have direct access to qmp, it
would have to go via a libxl API, for an Active domain at least.
qemu-img is the right answer for an Inactive domain.

Secondly, the disk snapshot has to happen while the domain is
paused/quiesced for consistency. This happens deep in the bowels of the
libxl save/restore code. So either libxl has to do the disk snapshots at
the same time or we need a callback to the toolstack in order for it to
make the snapshots.

> Anyway, if for domain snapshot create, we should put creating disk
> snapshot process in libxl, then for domain snapshot delete, we
> should put deleting disk snapshot process in libxl. That is, in libxl
> there should be:
> libxl_disk_snapshot_create (which handles creating disk snapshot)
> libxl_disk_snapshot_delete (which handles deleting disk snapshot)
> 
> Otherwise I would think it's weird to have in libxl:
> libxl_domain_snapshot_create (wrap saving memory [already has API] 
>                               and creating disk snapshot)
> libxl_disk_snapshot_delete (deleting disk snapshot)

The create and delete cases are subtly different, so it may be that the
API ends up asymmetric.

The create mechanism (whichever one it is) operates on a single Active
domain and is reasonably well defined.

The delete operation however can potentially operate on multiple Active
domains, e.g. 2 domains are running with a common ancestor snapshot
which is being removed.

How would the delete interface deal with this case? In particular
without libxl becoming involved in "storage management".

The reason I'm thinking of a "delete notify" style interface for Active
domains is that it then applies to a single Active domain at a time. If
multiple domains are affected by a snapshot deletion then the
notification is called multiple times.

> And about the snapshot json file store and retrieve, using
> gentype.py to autogenerate xx_to_json and xx_from_json functions
> is very convenient, there would be a group of functions
> set/get/update/delete_snapshot_metadata based on that.
> But I didn't see other such usage in xl, and it's not proper to 
> place in libxl. Anywhere could it be placed but used by xl? 
> Wei might have some ideas about this?

xl hasn't needed to use the autogeneration infrastructure to date, but
there's no reason why it couldn't do so if there was a need. Just create
xl_types.idl and hook it into the Makeile.

It would be harder to extend this to other toolstack, but I suspect we
don't need to.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:02:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwtSo-0003km-QS; Fri, 05 Dec 2014 14:02:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwtSn-0003kh-LJ
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 14:02:29 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	35/56-25276-5FAB1845; Fri, 05 Dec 2014 14:02:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417788147!13677885!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 10417 invoked from network); 5 Dec 2014 14:02:28 -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;
	5 Dec 2014 14:02:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200719990"
Message-ID: <1417788145.22808.64.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Fri, 5 Dec 2014 14:02:25 +0000
In-Reply-To: <547F44F5020000660004100F@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>
	<1417189409.23604.62.camel@citrix.com>
	<547F44F5020000660004100F@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-12-02 at 23:14 -0700, Chun Yan Liu wrote:
> 
> >>> On 11/28/2014 at 11:43 PM, in message <1417189409.23604.62.camel@citrix.com>,
> Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> > 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.
>   
> The reason why I post such an overview here before sending next
> version is: I'm puzzled about what should be in libxl and what
> in toolstack after previous discussion. So posted here to seek
> some ideas or agreement first. It's not a full design, not break
> down to libxl and toolstack yet.

I guess I thought we had gotten closer to this than we actually have.

> > 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. 
> 
> About notification API, after looking at lvm, vhd-util and qcow2, 
> I don't think we need it. No extra work needs to do to handle 
> disk snapshot chain. 
> lvm: doesn't support snapshot of snapshot. 
> vhd-util: backing file chain, external snapshot. Don't need to 
>           delete the disk snapshot when deleting domain snapshot. 
> qcow2: 
> * internal disk snapshot: each snapshot increases the refcount 
>   of data, deleting snapshot only decrease the refcount, won't 
>   affect other snapshots. 
> * external disk snapshot: same as vhd-util, backing file chain. 
>   Don't need to delete disk snapshot when deleting domain snapshot.

You don't need to, but might a toolstack (or user) want to consolidate
anyway, e.g. to reduce chain length? (which might otherwise be overly
long.)

> > 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. 
> 
> Like delete a disk snapshot, xl can call external command to do that
> (e.g. qemu-img). But it's better to call qmp to do that.

The toolstack (xl or libvirt) doesn't have direct access to qmp, it
would have to go via a libxl API, for an Active domain at least.
qemu-img is the right answer for an Inactive domain.

Secondly, the disk snapshot has to happen while the domain is
paused/quiesced for consistency. This happens deep in the bowels of the
libxl save/restore code. So either libxl has to do the disk snapshots at
the same time or we need a callback to the toolstack in order for it to
make the snapshots.

> Anyway, if for domain snapshot create, we should put creating disk
> snapshot process in libxl, then for domain snapshot delete, we
> should put deleting disk snapshot process in libxl. That is, in libxl
> there should be:
> libxl_disk_snapshot_create (which handles creating disk snapshot)
> libxl_disk_snapshot_delete (which handles deleting disk snapshot)
> 
> Otherwise I would think it's weird to have in libxl:
> libxl_domain_snapshot_create (wrap saving memory [already has API] 
>                               and creating disk snapshot)
> libxl_disk_snapshot_delete (deleting disk snapshot)

The create and delete cases are subtly different, so it may be that the
API ends up asymmetric.

The create mechanism (whichever one it is) operates on a single Active
domain and is reasonably well defined.

The delete operation however can potentially operate on multiple Active
domains, e.g. 2 domains are running with a common ancestor snapshot
which is being removed.

How would the delete interface deal with this case? In particular
without libxl becoming involved in "storage management".

The reason I'm thinking of a "delete notify" style interface for Active
domains is that it then applies to a single Active domain at a time. If
multiple domains are affected by a snapshot deletion then the
notification is called multiple times.

> And about the snapshot json file store and retrieve, using
> gentype.py to autogenerate xx_to_json and xx_from_json functions
> is very convenient, there would be a group of functions
> set/get/update/delete_snapshot_metadata based on that.
> But I didn't see other such usage in xl, and it's not proper to 
> place in libxl. Anywhere could it be placed but used by xl? 
> Wei might have some ideas about this?

xl hasn't needed to use the autogeneration infrastructure to date, but
there's no reason why it couldn't do so if there was a need. Just create
xl_types.idl and hook it into the Makeile.

It would be harder to extend this to other toolstack, but I suspect we
don't need to.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwtX5-0003sn-Gb; Fri, 05 Dec 2014 14:06: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 1XwtX3-0003si-Qq
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:06:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	89/EE-09842-DFBB1845; Fri, 05 Dec 2014 14:06:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417788412!10267510!1
X-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 19773 invoked from network); 5 Dec 2014 14:06:52 -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; 5 Dec 2014 14:06:52 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 14:06:52 +0000
Message-Id: <5481CA0D020000780004D2E8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 14:06:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEBDE33ED.2__="
Cc: Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] VMX: don't allow PVH to reach handle_pio() or
 handle_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartEBDE33ED.2__=
Content-Type: text/plain; charset=UTF-8
Content-Length: 668
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

PVH guests are not supposed to access I/O ports they weren't given
access to (there's nothing to handle emulation of such accesses).

Reported-by: Roger Pau Monn=C3=A9<roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Note: Only compile tested so far.

--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3082,6 +3082,9 @@ void vmx_vmexit_handler(struct cpu_user_
     }
 
     case EXIT_REASON_IO_INSTRUCTION:
+        if ( unlikely(is_pvh_vcpu(v)) )
+            goto exit_and_crash;
+
         __vmread(EXIT_QUALIFICATION, &exit_qualification);
         if ( exit_qualification & 0x10 )
         {



--=__PartEBDE33ED.2__=
Content-Type: text/plain; name="VMX-PVH-no-emulated-IO-ports.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="VMX-PVH-no-emulated-IO-ports.patch"

VMX: don't allow PVH to reach handle_pio() or handle_mmio()=0A=0APVH =
guests are not supposed to access I/O ports they weren't given=0Aaccess to =
(there's nothing to handle emulation of such accesses).=0A=0AReported-by: =
Roger Pau Monn=C3=A9<roger.pau@citrix.com>=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A---=0ANote: Only compile tested so far.=0A=0A--- =
a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vmx.c=0A@@ =
-3082,6 +3082,9 @@ void vmx_vmexit_handler(struct cpu_user_=0A     }=0A =
=0A     case EXIT_REASON_IO_INSTRUCTION:=0A+        if ( unlikely(is_pvh_vc=
pu(v)) )=0A+            goto exit_and_crash;=0A+=0A         __vmread(EXIT_Q=
UALIFICATION, &exit_qualification);=0A         if ( exit_qualification & =
0x10 )=0A         {=0A
--=__PartEBDE33ED.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

--=__PartEBDE33ED.2__=--


From xen-devel-bounces@lists.xen.org Fri Dec 05 14:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwtX5-0003sn-Gb; Fri, 05 Dec 2014 14:06: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 1XwtX3-0003si-Qq
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:06:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	89/EE-09842-DFBB1845; Fri, 05 Dec 2014 14:06:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1417788412!10267510!1
X-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 19773 invoked from network); 5 Dec 2014 14:06:52 -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; 5 Dec 2014 14:06:52 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 14:06:52 +0000
Message-Id: <5481CA0D020000780004D2E8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 14:06:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEBDE33ED.2__="
Cc: Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] VMX: don't allow PVH to reach handle_pio() or
 handle_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartEBDE33ED.2__=
Content-Type: text/plain; charset=UTF-8
Content-Length: 668
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

PVH guests are not supposed to access I/O ports they weren't given
access to (there's nothing to handle emulation of such accesses).

Reported-by: Roger Pau Monn=C3=A9<roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Note: Only compile tested so far.

--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3082,6 +3082,9 @@ void vmx_vmexit_handler(struct cpu_user_
     }
 
     case EXIT_REASON_IO_INSTRUCTION:
+        if ( unlikely(is_pvh_vcpu(v)) )
+            goto exit_and_crash;
+
         __vmread(EXIT_QUALIFICATION, &exit_qualification);
         if ( exit_qualification & 0x10 )
         {



--=__PartEBDE33ED.2__=
Content-Type: text/plain; name="VMX-PVH-no-emulated-IO-ports.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="VMX-PVH-no-emulated-IO-ports.patch"

VMX: don't allow PVH to reach handle_pio() or handle_mmio()=0A=0APVH =
guests are not supposed to access I/O ports they weren't given=0Aaccess to =
(there's nothing to handle emulation of such accesses).=0A=0AReported-by: =
Roger Pau Monn=C3=A9<roger.pau@citrix.com>=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A---=0ANote: Only compile tested so far.=0A=0A--- =
a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vmx.c=0A@@ =
-3082,6 +3082,9 @@ void vmx_vmexit_handler(struct cpu_user_=0A     }=0A =
=0A     case EXIT_REASON_IO_INSTRUCTION:=0A+        if ( unlikely(is_pvh_vc=
pu(v)) )=0A+            goto exit_and_crash;=0A+=0A         __vmread(EXIT_Q=
UALIFICATION, &exit_qualification);=0A         if ( exit_qualification & =
0x10 )=0A         {=0A
--=__PartEBDE33ED.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

--=__PartEBDE33ED.2__=--


From xen-devel-bounces@lists.xen.org Fri Dec 05 14:08:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwtYT-00040I-8D; Fri, 05 Dec 2014 14:08: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 1XwtYS-0003zi-Db
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:08:20 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	C6/DD-02696-35CB1845; Fri, 05 Dec 2014 14:08:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417788498!13258245!1
X-Originating-IP: [66.165.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 29179 invoked from network); 5 Dec 2014 14:08:19 -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 Dec 2014 14:08:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200351492"
Received: from ukmail1.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, 5 Dec 2014 09:08:07 -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 1XwtYE-0007IG-VI;
	Fri, 05 Dec 2014 14:08:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 5 Dec 2014 14:08:02 +0000
Message-ID: <1417788483-662-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: x86@kernel.org, linux-kernel@vger.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 Fri Dec 05 14:08:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwtYS-0003zw-HX; Fri, 05 Dec 2014 14:08:20 +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 1XwtYR-0003zW-Ey
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:08:19 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	66/50-17958-25CB1845; Fri, 05 Dec 2014 14:08:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417788496!11334253!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18686 invoked from network); 5 Dec 2014 14:08:18 -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;
	5 Dec 2014 14:08:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200351489"
Received: from ukmail1.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, 5 Dec 2014 09:08:07 -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 1XwtYE-0007IG-Sg;
	Fri, 05 Dec 2014 14:08:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 5 Dec 2014 14:08:00 +0000
Message-ID: <1417788483-662-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: x86@kernel.org, linux-kernel@vger.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 Fri Dec 05 14:08:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwtYS-000407-Se; Fri, 05 Dec 2014 14:08:20 +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 1XwtYS-0003zd-4r
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:08:20 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	B7/2B-25727-35CB1845; Fri, 05 Dec 2014 14:08:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417788496!11334253!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18786 invoked from network); 5 Dec 2014 14:08:18 -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;
	5 Dec 2014 14:08:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200351490"
Received: from ukmail1.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, 5 Dec 2014 09:08:07 -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 1XwtYE-0007IG-TP;
	Fri, 05 Dec 2014 14:08:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 5 Dec 2014 14:08:01 +0000
Message-ID: <1417788483-662-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
References: <1417788483-662-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, x86@kernel.org,
	linux-kernel@vger.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 Fri Dec 05 14:08:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwtYT-00040I-8D; Fri, 05 Dec 2014 14:08: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 1XwtYS-0003zi-Db
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:08:20 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	C6/DD-02696-35CB1845; Fri, 05 Dec 2014 14:08:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417788498!13258245!1
X-Originating-IP: [66.165.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 29179 invoked from network); 5 Dec 2014 14:08:19 -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 Dec 2014 14:08:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200351492"
Received: from ukmail1.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, 5 Dec 2014 09:08:07 -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 1XwtYE-0007IG-VI;
	Fri, 05 Dec 2014 14:08:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 5 Dec 2014 14:08:02 +0000
Message-ID: <1417788483-662-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: x86@kernel.org, linux-kernel@vger.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 Fri Dec 05 14:08:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwtYS-0003zj-4l; Fri, 05 Dec 2014 14:08:20 +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 1XwtYQ-0003zT-RK
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:08:18 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	F6/60-09284-25CB1845; Fri, 05 Dec 2014 14:08:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417788496!11334253!1
X-Originating-IP: [66.165.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 18598 invoked from network); 5 Dec 2014 14:08:17 -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;
	5 Dec 2014 14:08:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200351487"
Received: from ukmail1.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, 5 Dec 2014 09:08:07 -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 1XwtYE-0007IG-S2;
	Fri, 05 Dec 2014 14:08:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 5 Dec 2014 14:07:59 +0000
Message-ID: <1417788483-662-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: x86@kernel.org, linux-kernel@vger.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] [PATCHv5 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 a more suitable one.

Changes in v5:
- xen_swiotlb_get_required_mask() is x86 only.

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 Fri Dec 05 14:08:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwtYU-00040o-MD; Fri, 05 Dec 2014 14:08:22 +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 1XwtYS-0003zq-Rb
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:08:20 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	77/8B-07724-45CB1845; Fri, 05 Dec 2014 14:08:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417788496!11334253!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19299 invoked from network); 5 Dec 2014 14:08:19 -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;
	5 Dec 2014 14:08:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200351495"
Received: from ukmail1.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, 5 Dec 2014 09:08:07 -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 1XwtYE-0007IG-Vy;
	Fri, 05 Dec 2014 14:08:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 5 Dec 2014 14:08:03 +0000
Message-ID: <1417788483-662-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: x86@kernel.org, linux-kernel@vger.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 |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 0e98e5d..35774f8 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -18,6 +18,11 @@
 
 int xen_swiotlb __read_mostly;
 
+static u64 xen_swiotlb_get_required_mask(struct device *dev)
+{
+	return DMA_BIT_MASK(64);
+}
+
 static struct dma_map_ops xen_swiotlb_dma_ops = {
 	.mapping_error = xen_swiotlb_dma_mapping_error,
 	.alloc = xen_swiotlb_alloc_coherent,
@@ -31,6 +36,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,
 };
 
 /*
-- 
1.7.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 Dec 05 14:08:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwtYS-0003zw-HX; Fri, 05 Dec 2014 14:08:20 +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 1XwtYR-0003zW-Ey
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:08:19 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	66/50-17958-25CB1845; Fri, 05 Dec 2014 14:08:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417788496!11334253!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18686 invoked from network); 5 Dec 2014 14:08:18 -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;
	5 Dec 2014 14:08:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200351489"
Received: from ukmail1.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, 5 Dec 2014 09:08:07 -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 1XwtYE-0007IG-Sg;
	Fri, 05 Dec 2014 14:08:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 5 Dec 2014 14:08:00 +0000
Message-ID: <1417788483-662-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: x86@kernel.org, linux-kernel@vger.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 Fri Dec 05 14:08:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwtYS-0003zj-4l; Fri, 05 Dec 2014 14:08:20 +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 1XwtYQ-0003zT-RK
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:08:18 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	F6/60-09284-25CB1845; Fri, 05 Dec 2014 14:08:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417788496!11334253!1
X-Originating-IP: [66.165.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 18598 invoked from network); 5 Dec 2014 14:08:17 -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;
	5 Dec 2014 14:08:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200351487"
Received: from ukmail1.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, 5 Dec 2014 09:08:07 -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 1XwtYE-0007IG-S2;
	Fri, 05 Dec 2014 14:08:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 5 Dec 2014 14:07:59 +0000
Message-ID: <1417788483-662-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: x86@kernel.org, linux-kernel@vger.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] [PATCHv5 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 a more suitable one.

Changes in v5:
- xen_swiotlb_get_required_mask() is x86 only.

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 Fri Dec 05 14:08:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwtYS-000407-Se; Fri, 05 Dec 2014 14:08:20 +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 1XwtYS-0003zd-4r
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:08:20 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	B7/2B-25727-35CB1845; Fri, 05 Dec 2014 14:08:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417788496!11334253!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18786 invoked from network); 5 Dec 2014 14:08:18 -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;
	5 Dec 2014 14:08:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200351490"
Received: from ukmail1.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, 5 Dec 2014 09:08:07 -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 1XwtYE-0007IG-TP;
	Fri, 05 Dec 2014 14:08:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 5 Dec 2014 14:08:01 +0000
Message-ID: <1417788483-662-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
References: <1417788483-662-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, x86@kernel.org,
	linux-kernel@vger.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 Fri Dec 05 14:08:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwtYU-00040o-MD; Fri, 05 Dec 2014 14:08:22 +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 1XwtYS-0003zq-Rb
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:08:20 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	77/8B-07724-45CB1845; Fri, 05 Dec 2014 14:08:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417788496!11334253!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19299 invoked from network); 5 Dec 2014 14:08:19 -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;
	5 Dec 2014 14:08:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200351495"
Received: from ukmail1.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, 5 Dec 2014 09:08:07 -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 1XwtYE-0007IG-Vy;
	Fri, 05 Dec 2014 14:08:06 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 5 Dec 2014 14:08:03 +0000
Message-ID: <1417788483-662-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: x86@kernel.org, linux-kernel@vger.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 |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 0e98e5d..35774f8 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -18,6 +18,11 @@
 
 int xen_swiotlb __read_mostly;
 
+static u64 xen_swiotlb_get_required_mask(struct device *dev)
+{
+	return DMA_BIT_MASK(64);
+}
+
 static struct dma_map_ops xen_swiotlb_dma_ops = {
 	.mapping_error = xen_swiotlb_dma_mapping_error,
 	.alloc = xen_swiotlb_alloc_coherent,
@@ -31,6 +36,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,
 };
 
 /*
-- 
1.7.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 Dec 05 14:16:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:16:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwtfz-0004vd-QV; Fri, 05 Dec 2014 14:16:07 +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 1Xwtfy-0004vV-JD
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 14:16:06 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	D3/6F-09284-52EB1845; Fri, 05 Dec 2014 14:16:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417788964!11235703!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 3634 invoked from network); 5 Dec 2014 14:16:05 -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 Dec 2014 14:16:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200355372"
Message-ID: <5481BE20.9020001@citrix.com>
Date: Fri, 5 Dec 2014 14:16:00 +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: Zoltan Kiss <zoltan.kiss@linaro.org>, David Vrabel
	<david.vrabel@citrix.com>, Anthony Wright <anthony@overnetdata.com>
References: <19758084.30.1417707380178.JavaMail.root@zimbra.overnetdata.com>	<54808372.8090102@citrix.com>
	<5481A9BA.1000009@linaro.org>
In-Reply-To: <5481A9BA.1000009@linaro.org>
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.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 05/12/14 12:48, Zoltan Kiss wrote:
> Hi,
> 
> Maybe I'm misreading it, but it seems to me that netfront doesn't slice
> up the linear buffer at all, just blindly sends it. In xennet_start_xmit:

This is handled in the beginning of xennet_make_frags() (which I would
agree isn't not the obvious place for it).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:16:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:16:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwtfz-0004vd-QV; Fri, 05 Dec 2014 14:16:07 +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 1Xwtfy-0004vV-JD
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 14:16:06 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	D3/6F-09284-52EB1845; Fri, 05 Dec 2014 14:16:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1417788964!11235703!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 3634 invoked from network); 5 Dec 2014 14:16:05 -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 Dec 2014 14:16:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200355372"
Message-ID: <5481BE20.9020001@citrix.com>
Date: Fri, 5 Dec 2014 14:16:00 +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: Zoltan Kiss <zoltan.kiss@linaro.org>, David Vrabel
	<david.vrabel@citrix.com>, Anthony Wright <anthony@overnetdata.com>
References: <19758084.30.1417707380178.JavaMail.root@zimbra.overnetdata.com>	<54808372.8090102@citrix.com>
	<5481A9BA.1000009@linaro.org>
In-Reply-To: <5481A9BA.1000009@linaro.org>
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.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 05/12/14 12:48, Zoltan Kiss wrote:
> Hi,
> 
> Maybe I'm misreading it, but it seems to me that netfront doesn't slice
> up the linear buffer at all, just blindly sends it. In xennet_start_xmit:

This is handled in the beginning of xennet_make_frags() (which I would
agree isn't not the obvious place for it).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:20:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:20:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwtkS-00053t-GP; Fri, 05 Dec 2014 14:20:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XwtkR-00053m-RF
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 14:20:43 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	17/83-28865-B3FB1845; Fri, 05 Dec 2014 14:20:43 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417789242!6502757!1
X-Originating-IP: [74.125.82.52]
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 13779 invoked from network); 5 Dec 2014 14:20:42 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 14:20:42 -0000
Received: by mail-wg0-f52.google.com with SMTP id a1so1011177wgh.39
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 06:20: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=02Bvzw2CiXJ3xzt3V6hZQ1riJ+kNtu3qYMTLYw90ygo=;
	b=ddqZCCcno9GjINT2dKw5ecZOaFM7LnY/MrNjWmQyZYUmqWwmGJddf964MsF+/ovdR0
	aIYdvG9Kbqza5RGVWYv9NdKysEoQY+kgpDAnNNExFv4q/3aY3WEY6oewDmeLK9NLWG2s
	AuRs/NiaegwCHyhRMFfdsfHsIa7qnXwEYt539/3qRKO0JOCIoTwdPieH6XyrvHbrLcxg
	FbK73UIWlhE6UOPN+x672G54kyjUJLCK7xTkKxksAa6bkyC2+ypukzLdHZz1mPL317t4
	j5cBz5dki/3ZM8cY5gAcFJ+GKh10Q3KAhxAOtoDPuFd4X1E6H51OyrKVXOKrgRRuhC3n
	b2pg==
X-Gm-Message-State: ALoCoQn/VdKOddQMdjV3iEWUaurA78xpSLnuwhffGMAyA4SWQ2EURlEzND91iUVa26C+1OEJJOUY
X-Received: by 10.180.76.144 with SMTP id k16mr4460767wiw.3.1417789242426;
	Fri, 05 Dec 2014 06:20:42 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id j9sm13051195wjb.38.2014.12.05.06.20.40
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 06:20:41 -0800 (PST)
Message-ID: <5481BF35.2060800@linaro.org>
Date: Fri, 05 Dec 2014 14:20:37 +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: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>, 
	xen-devel@lists.xen.org
References: <1417787196-3313-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1417787196-3313-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Oleksandr,

On 05/12/14 13:46, Oleksandr Dmytryshyn wrote:
> UART is not able to receive bytes when idle mode is not
> configured properly. When we use Xen with old Linux
> Kernel (for example 3.8) this kernel configures UART
> idle mode even if the UART node in device tree is absent.

I don't understand how the kernel can configure the UART as the MMIO
range is not mapped. Is there another way to set the idle mode?

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 Dec 05 14:20:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:20:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwtkS-00053t-GP; Fri, 05 Dec 2014 14:20:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XwtkR-00053m-RF
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 14:20:43 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	17/83-28865-B3FB1845; Fri, 05 Dec 2014 14:20:43 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417789242!6502757!1
X-Originating-IP: [74.125.82.52]
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 13779 invoked from network); 5 Dec 2014 14:20:42 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 14:20:42 -0000
Received: by mail-wg0-f52.google.com with SMTP id a1so1011177wgh.39
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 06:20: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=02Bvzw2CiXJ3xzt3V6hZQ1riJ+kNtu3qYMTLYw90ygo=;
	b=ddqZCCcno9GjINT2dKw5ecZOaFM7LnY/MrNjWmQyZYUmqWwmGJddf964MsF+/ovdR0
	aIYdvG9Kbqza5RGVWYv9NdKysEoQY+kgpDAnNNExFv4q/3aY3WEY6oewDmeLK9NLWG2s
	AuRs/NiaegwCHyhRMFfdsfHsIa7qnXwEYt539/3qRKO0JOCIoTwdPieH6XyrvHbrLcxg
	FbK73UIWlhE6UOPN+x672G54kyjUJLCK7xTkKxksAa6bkyC2+ypukzLdHZz1mPL317t4
	j5cBz5dki/3ZM8cY5gAcFJ+GKh10Q3KAhxAOtoDPuFd4X1E6H51OyrKVXOKrgRRuhC3n
	b2pg==
X-Gm-Message-State: ALoCoQn/VdKOddQMdjV3iEWUaurA78xpSLnuwhffGMAyA4SWQ2EURlEzND91iUVa26C+1OEJJOUY
X-Received: by 10.180.76.144 with SMTP id k16mr4460767wiw.3.1417789242426;
	Fri, 05 Dec 2014 06:20:42 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id j9sm13051195wjb.38.2014.12.05.06.20.40
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 06:20:41 -0800 (PST)
Message-ID: <5481BF35.2060800@linaro.org>
Date: Fri, 05 Dec 2014 14:20:37 +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: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>, 
	xen-devel@lists.xen.org
References: <1417787196-3313-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1417787196-3313-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Oleksandr,

On 05/12/14 13:46, Oleksandr Dmytryshyn wrote:
> UART is not able to receive bytes when idle mode is not
> configured properly. When we use Xen with old Linux
> Kernel (for example 3.8) this kernel configures UART
> idle mode even if the UART node in device tree is absent.

I don't understand how the kernel can configure the UART as the MMIO
range is not mapped. Is there another way to set the idle mode?

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 Dec 05 14:28:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:28:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwtra-0005R4-D9; Fri, 05 Dec 2014 14:28: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 1XwtrY-0005Qz-N7
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:28:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2B/F7-15461-4F0C1845; Fri, 05 Dec 2014 14:28:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417789682!13676780!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16347 invoked from network); 5 Dec 2014 14:28:03 -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;
	5 Dec 2014 14:28:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200360475"
Message-ID: <1417789634.22808.66.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 5 Dec 2014 14:27:14 +0000
In-Reply-To: <5481C67D020000780004D2D1@mail.emea.novell.com>
References: <5481C67D020000780004D2D1@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>,
	Stefano Stabellini <stefano.stabellini@eu.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 <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 13:51 +0000, Jan Beulich wrote:
>  #define nr_static_irqs NR_IRQS
> +#define arch_hwdom_irqs(domid) NR_IRQS

FWIW gic_number_lines() is the ARM equivalent of getting the number of
GSIs.

*BUT* we don't actually use pirqs on ARM (everything goes via the
virtualised interrupt controller). So maybe we should be setting
nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
from an ARM person, so I'm fine with you making this NR_IRQS in the
meantime.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:28:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:28:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwtra-0005R4-D9; Fri, 05 Dec 2014 14:28: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 1XwtrY-0005Qz-N7
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:28:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	2B/F7-15461-4F0C1845; Fri, 05 Dec 2014 14:28:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417789682!13676780!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16347 invoked from network); 5 Dec 2014 14:28:03 -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;
	5 Dec 2014 14:28:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200360475"
Message-ID: <1417789634.22808.66.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 5 Dec 2014 14:27:14 +0000
In-Reply-To: <5481C67D020000780004D2D1@mail.emea.novell.com>
References: <5481C67D020000780004D2D1@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>,
	Stefano Stabellini <stefano.stabellini@eu.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 <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 13:51 +0000, Jan Beulich wrote:
>  #define nr_static_irqs NR_IRQS
> +#define arch_hwdom_irqs(domid) NR_IRQS

FWIW gic_number_lines() is the ARM equivalent of getting the number of
GSIs.

*BUT* we don't actually use pirqs on ARM (everything goes via the
virtualised interrupt controller). So maybe we should be setting
nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
from an ARM person, so I'm fine with you making this NR_IRQS in the
meantime.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:36:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwtzd-0005qG-G7; Fri, 05 Dec 2014 14:36: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 1Xwtzb-0005qB-PZ
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:36:23 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	17/95-25714-7E2C1845; Fri, 05 Dec 2014 14:36:23 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417790180!11822003!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9234 invoked from network); 5 Dec 2014 14:36: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;
	5 Dec 2014 14:36:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200364529"
Message-ID: <5481C2E2.1060306@citrix.com>
Date: Fri, 5 Dec 2014 14:36:18 +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: <5481A589020000780004D1E3@mail.emea.novell.com>
In-Reply-To: <5481A589020000780004D1E3@mail.emea.novell.com>
X-DLP: MIA1
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] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/12/14 11:31, Jan Beulich wrote:
> Andrew validly points out that even if these masks aren't a formal part
> of the hypercall interface, we aren't free to change them: A guest
> suspended for migration in the middle of a continuation would fail to
> work if resumed on a hypervisor using a different value. Hence add
> respective comments to their definitions.
>
> Additionally, to help future extensibility as well as in the spirit of
> reducing undefined behavior as much as possible, refuse hypercalls made
> with the respective bits non-zero when the respective sub-ops don't
> make use of those bits.
>
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

General principle looks good.  A couple of issues.

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4661,9 +4661,8 @@ int xenmem_add_to_physmap_one(
>  long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      int rc;
> -    int op = cmd & MEMOP_CMD_MASK;

This needs a blanket start_iter check, as do_memory_op() has not done so.

The ARM code also needs one, as the caller has applied partial checks.

>  
> -    switch ( op )
> +    switch ( cmd )
>      {
>      case XENMEM_set_memory_map:
>      {
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -906,9 +906,8 @@ long subarch_memory_op(unsigned long cmd
>      xen_pfn_t mfn, last_mfn;
>      unsigned int i;
>      long rc = 0;
> -    int op = cmd & MEMOP_CMD_MASK;

It is probably best to have a blanket check here even if
arch_memory_op() has a check.  It will reduce the chance of the check
being missed if/when arch_memory_op() gains a presentable subop.

>  
> -    switch ( op )
> +    switch ( cmd )
>      {
>      case XENMEM_machphys_mfn_list:
>          if ( copy_from_guest(&xmml, arg, 1) )
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -977,6 +992,9 @@ long do_memory_op(unsigned long cmd, XEN
>          unsigned int dom_vnodes, dom_vranges, dom_vcpus;
>          struct vnuma_info tmp;
>  
> +        if ( unlikely(start_extent) )
> +            return -ENOSYS;
> +
>          /*
>           * Guest passes nr_vnodes, number of regions and nr_vcpus thus
>           * we know how much memory guest has allocated.

XENMEM_get_vnumainfo needs a guard.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:36:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwtzd-0005qG-G7; Fri, 05 Dec 2014 14:36: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 1Xwtzb-0005qB-PZ
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:36:23 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	17/95-25714-7E2C1845; Fri, 05 Dec 2014 14:36:23 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417790180!11822003!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9234 invoked from network); 5 Dec 2014 14:36: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;
	5 Dec 2014 14:36:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200364529"
Message-ID: <5481C2E2.1060306@citrix.com>
Date: Fri, 5 Dec 2014 14:36:18 +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: <5481A589020000780004D1E3@mail.emea.novell.com>
In-Reply-To: <5481A589020000780004D1E3@mail.emea.novell.com>
X-DLP: MIA1
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] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/12/14 11:31, Jan Beulich wrote:
> Andrew validly points out that even if these masks aren't a formal part
> of the hypercall interface, we aren't free to change them: A guest
> suspended for migration in the middle of a continuation would fail to
> work if resumed on a hypervisor using a different value. Hence add
> respective comments to their definitions.
>
> Additionally, to help future extensibility as well as in the spirit of
> reducing undefined behavior as much as possible, refuse hypercalls made
> with the respective bits non-zero when the respective sub-ops don't
> make use of those bits.
>
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

General principle looks good.  A couple of issues.

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4661,9 +4661,8 @@ int xenmem_add_to_physmap_one(
>  long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      int rc;
> -    int op = cmd & MEMOP_CMD_MASK;

This needs a blanket start_iter check, as do_memory_op() has not done so.

The ARM code also needs one, as the caller has applied partial checks.

>  
> -    switch ( op )
> +    switch ( cmd )
>      {
>      case XENMEM_set_memory_map:
>      {
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -906,9 +906,8 @@ long subarch_memory_op(unsigned long cmd
>      xen_pfn_t mfn, last_mfn;
>      unsigned int i;
>      long rc = 0;
> -    int op = cmd & MEMOP_CMD_MASK;

It is probably best to have a blanket check here even if
arch_memory_op() has a check.  It will reduce the chance of the check
being missed if/when arch_memory_op() gains a presentable subop.

>  
> -    switch ( op )
> +    switch ( cmd )
>      {
>      case XENMEM_machphys_mfn_list:
>          if ( copy_from_guest(&xmml, arg, 1) )
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -977,6 +992,9 @@ long do_memory_op(unsigned long cmd, XEN
>          unsigned int dom_vnodes, dom_vranges, dom_vcpus;
>          struct vnuma_info tmp;
>  
> +        if ( unlikely(start_extent) )
> +            return -ENOSYS;
> +
>          /*
>           * Guest passes nr_vnodes, number of regions and nr_vcpus thus
>           * we know how much memory guest has allocated.

XENMEM_get_vnumainfo needs a guard.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:37:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwu0I-0005sq-TE; Fri, 05 Dec 2014 14:37:06 +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 1Xwu0I-0005sc-1k
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:37:06 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B6/10-22737-113C1845; Fri, 05 Dec 2014 14:37:05 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417790224!11780441!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26543 invoked from network); 5 Dec 2014 14:37:04 -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;
	5 Dec 2014 14:37:04 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so1596571wiv.8
	for <xen-devel@lists.xenproject.org>;
	Fri, 05 Dec 2014 06:37: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=STUMaK9key35q41q6vLxtRQ+CQ/DLcfihV/UZiPTwI4=;
	b=aj0zpza2HoWI8Ut7KAOJpkrAsqxKn2uiWWEWJ81Ts+rSCVHhqFPn8wHdD2KJB84VWO
	Kvmx/7p2lTcff55S2A/C0bNPl/NcQetFJSvWYRe4umJuIn1MbJQvSJQypXx7l5wLV21x
	RrC2EsJA2jpCqdP5ZQw26mnJj7IuNzRDmkvR+cRb6H2QYfk4B6sKqw38vwaxpqgMP4Oa
	6tM9dc6RXR9Ik4ffJmEmnvh9DceI50aIH0U6vbu2J6QyVaEVALMXThw/5jpSWE4/6Q+a
	Je5mPCkH7zwaaibd6t9a259RU+3Cmj0RFLdE7AkGgwk9+PUC6INf3QqLVne5/YiIve0H
	/HuQ==
X-Gm-Message-State: ALoCoQku4FhrnJkceOz+kMWaVx1Blwkodyd/SFNTNjG3Wvkc3bWzANkyuCY706VrACNaHXFTGKpe
X-Received: by 10.194.88.169 with SMTP id bh9mr4164773wjb.99.1417790224349;
	Fri, 05 Dec 2014 06:37:04 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	qg11sm2503981wic.17.2014.12.05.06.37.02 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 06:37:03 -0800 (PST)
Message-ID: <5481C30B.3020901@linaro.org>
Date: Fri, 05 Dec 2014 14:36:59 +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@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
In-Reply-To: <1417789634.22808.66.camel@eu.citrix.com>
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 05/12/14 14:27, Ian Campbell wrote:
> On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>>  #define nr_static_irqs NR_IRQS
>> +#define arch_hwdom_irqs(domid) NR_IRQS
> 
> FWIW gic_number_lines() is the ARM equivalent of getting the number of
> GSIs.
> 
> *BUT* we don't actually use pirqs on ARM (everything goes via the
> virtualised interrupt controller). So maybe we should be setting
> nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> from an ARM person, so I'm fine with you making this NR_IRQS in the
> meantime.

As we already know that PIRQ is not used on ARM, it would make sense to
use directly in this patch 0.

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 Dec 05 14:37:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwu0I-0005sq-TE; Fri, 05 Dec 2014 14:37:06 +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 1Xwu0I-0005sc-1k
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:37:06 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	B6/10-22737-113C1845; Fri, 05 Dec 2014 14:37:05 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-206.messagelabs.com!1417790224!11780441!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26543 invoked from network); 5 Dec 2014 14:37:04 -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;
	5 Dec 2014 14:37:04 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so1596571wiv.8
	for <xen-devel@lists.xenproject.org>;
	Fri, 05 Dec 2014 06:37: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=STUMaK9key35q41q6vLxtRQ+CQ/DLcfihV/UZiPTwI4=;
	b=aj0zpza2HoWI8Ut7KAOJpkrAsqxKn2uiWWEWJ81Ts+rSCVHhqFPn8wHdD2KJB84VWO
	Kvmx/7p2lTcff55S2A/C0bNPl/NcQetFJSvWYRe4umJuIn1MbJQvSJQypXx7l5wLV21x
	RrC2EsJA2jpCqdP5ZQw26mnJj7IuNzRDmkvR+cRb6H2QYfk4B6sKqw38vwaxpqgMP4Oa
	6tM9dc6RXR9Ik4ffJmEmnvh9DceI50aIH0U6vbu2J6QyVaEVALMXThw/5jpSWE4/6Q+a
	Je5mPCkH7zwaaibd6t9a259RU+3Cmj0RFLdE7AkGgwk9+PUC6INf3QqLVne5/YiIve0H
	/HuQ==
X-Gm-Message-State: ALoCoQku4FhrnJkceOz+kMWaVx1Blwkodyd/SFNTNjG3Wvkc3bWzANkyuCY706VrACNaHXFTGKpe
X-Received: by 10.194.88.169 with SMTP id bh9mr4164773wjb.99.1417790224349;
	Fri, 05 Dec 2014 06:37:04 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	qg11sm2503981wic.17.2014.12.05.06.37.02 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 06:37:03 -0800 (PST)
Message-ID: <5481C30B.3020901@linaro.org>
Date: Fri, 05 Dec 2014 14:36:59 +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@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
In-Reply-To: <1417789634.22808.66.camel@eu.citrix.com>
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 05/12/14 14:27, Ian Campbell wrote:
> On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>>  #define nr_static_irqs NR_IRQS
>> +#define arch_hwdom_irqs(domid) NR_IRQS
> 
> FWIW gic_number_lines() is the ARM equivalent of getting the number of
> GSIs.
> 
> *BUT* we don't actually use pirqs on ARM (everything goes via the
> virtualised interrupt controller). So maybe we should be setting
> nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> from an ARM person, so I'm fine with you making this NR_IRQS in the
> meantime.

As we already know that PIRQ is not used on ARM, it would make sense to
use directly in this patch 0.

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 Dec 05 14:43:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwu62-0006L5-Na; Fri, 05 Dec 2014 14:43: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 1Xwu61-0006L0-7R
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:43:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FD/9E-25276-474C1845; Fri, 05 Dec 2014 14:43:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417790578!13680511!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 31327 invoked from network); 5 Dec 2014 14:43: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;
	5 Dec 2014 14:42:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200367733"
Message-ID: <1417790527.22808.67.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Fri, 5 Dec 2014 14:42:07 +0000
In-Reply-To: <5481C30B.3020901@linaro.org>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com> <5481C30B.3020901@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Tim
	Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 14:36 +0000, Julien Grall wrote:
> Hi,
> 
> On 05/12/14 14:27, Ian Campbell wrote:
> > On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
> >>  #define nr_static_irqs NR_IRQS
> >> +#define arch_hwdom_irqs(domid) NR_IRQS
> > 
> > FWIW gic_number_lines() is the ARM equivalent of getting the number of
> > GSIs.
> > 
> > *BUT* we don't actually use pirqs on ARM (everything goes via the
> > virtualised interrupt controller). So maybe we should be setting
> > nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> > from an ARM person, so I'm fine with you making this NR_IRQS in the
> > meantime.
> 
> As we already know that PIRQ is not used on ARM, it would make sense to
> use directly in this patch 0.

Are you offering to give a tested-by if Jan posts such a patch?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:43:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwu62-0006L5-Na; Fri, 05 Dec 2014 14:43: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 1Xwu61-0006L0-7R
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:43:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FD/9E-25276-474C1845; Fri, 05 Dec 2014 14:43:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417790578!13680511!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 31327 invoked from network); 5 Dec 2014 14:43: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;
	5 Dec 2014 14:42:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200367733"
Message-ID: <1417790527.22808.67.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Fri, 5 Dec 2014 14:42:07 +0000
In-Reply-To: <5481C30B.3020901@linaro.org>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com> <5481C30B.3020901@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Tim
	Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 14:36 +0000, Julien Grall wrote:
> Hi,
> 
> On 05/12/14 14:27, Ian Campbell wrote:
> > On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
> >>  #define nr_static_irqs NR_IRQS
> >> +#define arch_hwdom_irqs(domid) NR_IRQS
> > 
> > FWIW gic_number_lines() is the ARM equivalent of getting the number of
> > GSIs.
> > 
> > *BUT* we don't actually use pirqs on ARM (everything goes via the
> > virtualised interrupt controller). So maybe we should be setting
> > nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> > from an ARM person, so I'm fine with you making this NR_IRQS in the
> > meantime.
> 
> As we already know that PIRQ is not used on ARM, it would make sense to
> use directly in this patch 0.

Are you offering to give a tested-by if Jan posts such a patch?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:47:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwuAM-0006Ti-Lz; Fri, 05 Dec 2014 14:47: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 1XwuAL-0006TX-3f
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:47:29 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	34/57-01660-085C1845; Fri, 05 Dec 2014 14:47:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417790847!6396942!1
X-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 10878 invoked from network); 5 Dec 2014 14:47:27 -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; 5 Dec 2014 14:47:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 14:47:27 +0000
Message-Id: <5481D38E020000780004D35C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 14:47:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5481A589020000780004D1E3@mail.emea.novell.com>
	<5481C2E2.1060306@citrix.com>
In-Reply-To: <5481C2E2.1060306@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 15:36, <andrew.cooper3@citrix.com> wrote:
> On 05/12/14 11:31, Jan Beulich wrote:
>> Andrew validly points out that even if these masks aren't a formal part
>> of the hypercall interface, we aren't free to change them: A guest
>> suspended for migration in the middle of a continuation would fail to
>> work if resumed on a hypervisor using a different value. Hence add
>> respective comments to their definitions.
>>
>> Additionally, to help future extensibility as well as in the spirit of
>> reducing undefined behavior as much as possible, refuse hypercalls made
>> with the respective bits non-zero when the respective sub-ops don't
>> make use of those bits.
>>
>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> General principle looks good.  A couple of issues.
> 
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -4661,9 +4661,8 @@ int xenmem_add_to_physmap_one(
>>  long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>  {
>>      int rc;
>> -    int op = cmd & MEMOP_CMD_MASK;
> 
> This needs a blanket start_iter check, as do_memory_op() has not done so.

Not sure what you're asking for - why is removing the masking not
sufficient?

> The ARM code also needs one, as the caller has applied partial checks.

The ARM code never applied a mask.

>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -977,6 +992,9 @@ long do_memory_op(unsigned long cmd, XEN
>>          unsigned int dom_vnodes, dom_vranges, dom_vcpus;
>>          struct vnuma_info tmp;
>>  
>> +        if ( unlikely(start_extent) )
>> +            return -ENOSYS;
>> +
>>          /*
>>           * Guest passes nr_vnodes, number of regions and nr_vcpus thus
>>           * we know how much memory guest has allocated.
> 
> XENMEM_get_vnumainfo needs a guard.

Again - I don't understand what you're asking for: The hunk above
is modifying the XENMEM_get_vnumainfo 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 Dec 05 14:47:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwuAM-0006Ti-Lz; Fri, 05 Dec 2014 14:47: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 1XwuAL-0006TX-3f
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:47:29 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	34/57-01660-085C1845; Fri, 05 Dec 2014 14:47:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1417790847!6396942!1
X-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 10878 invoked from network); 5 Dec 2014 14:47:27 -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; 5 Dec 2014 14:47:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 14:47:27 +0000
Message-Id: <5481D38E020000780004D35C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 14:47:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5481A589020000780004D1E3@mail.emea.novell.com>
	<5481C2E2.1060306@citrix.com>
In-Reply-To: <5481C2E2.1060306@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 15:36, <andrew.cooper3@citrix.com> wrote:
> On 05/12/14 11:31, Jan Beulich wrote:
>> Andrew validly points out that even if these masks aren't a formal part
>> of the hypercall interface, we aren't free to change them: A guest
>> suspended for migration in the middle of a continuation would fail to
>> work if resumed on a hypervisor using a different value. Hence add
>> respective comments to their definitions.
>>
>> Additionally, to help future extensibility as well as in the spirit of
>> reducing undefined behavior as much as possible, refuse hypercalls made
>> with the respective bits non-zero when the respective sub-ops don't
>> make use of those bits.
>>
>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> General principle looks good.  A couple of issues.
> 
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -4661,9 +4661,8 @@ int xenmem_add_to_physmap_one(
>>  long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>  {
>>      int rc;
>> -    int op = cmd & MEMOP_CMD_MASK;
> 
> This needs a blanket start_iter check, as do_memory_op() has not done so.

Not sure what you're asking for - why is removing the masking not
sufficient?

> The ARM code also needs one, as the caller has applied partial checks.

The ARM code never applied a mask.

>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -977,6 +992,9 @@ long do_memory_op(unsigned long cmd, XEN
>>          unsigned int dom_vnodes, dom_vranges, dom_vcpus;
>>          struct vnuma_info tmp;
>>  
>> +        if ( unlikely(start_extent) )
>> +            return -ENOSYS;
>> +
>>          /*
>>           * Guest passes nr_vnodes, number of regions and nr_vcpus thus
>>           * we know how much memory guest has allocated.
> 
> XENMEM_get_vnumainfo needs a guard.

Again - I don't understand what you're asking for: The hunk above
is modifying the XENMEM_get_vnumainfo 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 Dec 05 14:48:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwuBQ-0006Xn-5Y; Fri, 05 Dec 2014 14:48: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 1XwuBO-0006Xe-70
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:48:34 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	F7/B3-02696-1C5C1845; Fri, 05 Dec 2014 14:48:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417790912!13252871!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15436 invoked from network); 5 Dec 2014 14:48:32 -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 Dec 2014 14:48:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 14:48:32 +0000
Message-Id: <5481D3D1020000780004D35F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 14:48:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
In-Reply-To: <1417789634.22808.66.camel@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	IanJackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 15:27, <Ian.Campbell@eu.citrix.com> wrote:
> On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>>  #define nr_static_irqs NR_IRQS
>> +#define arch_hwdom_irqs(domid) NR_IRQS
> 
> FWIW gic_number_lines() is the ARM equivalent of getting the number of
> GSIs.
> 
> *BUT* we don't actually use pirqs on ARM (everything goes via the
> virtualised interrupt controller). So maybe we should be setting
> nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> from an ARM person, so I'm fine with you making this NR_IRQS in the
> meantime.

Considering Julien also asking for this, I don't mind changing this to
zero for ARM. Just let me know which way I can get this ack-ed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:48:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwuBQ-0006Xn-5Y; Fri, 05 Dec 2014 14:48: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 1XwuBO-0006Xe-70
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:48:34 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	F7/B3-02696-1C5C1845; Fri, 05 Dec 2014 14:48:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417790912!13252871!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15436 invoked from network); 5 Dec 2014 14:48:32 -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 Dec 2014 14:48:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 14:48:32 +0000
Message-Id: <5481D3D1020000780004D35F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 14:48:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
In-Reply-To: <1417789634.22808.66.camel@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	IanJackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 15:27, <Ian.Campbell@eu.citrix.com> wrote:
> On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>>  #define nr_static_irqs NR_IRQS
>> +#define arch_hwdom_irqs(domid) NR_IRQS
> 
> FWIW gic_number_lines() is the ARM equivalent of getting the number of
> GSIs.
> 
> *BUT* we don't actually use pirqs on ARM (everything goes via the
> virtualised interrupt controller). So maybe we should be setting
> nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> from an ARM person, so I'm fine with you making this NR_IRQS in the
> meantime.

Considering Julien also asking for this, I don't mind changing this to
zero for ARM. Just let me know which way I can get this ack-ed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:48:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:48:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuBd-0006Zn-L9; Fri, 05 Dec 2014 14:48:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XwuBc-0006ZZ-SY
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:48:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	10/7E-09842-0D5C1845; Fri, 05 Dec 2014 14:48:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417790926!13682415!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 6369 invoked from network); 5 Dec 2014 14:48:47 -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;
	5 Dec 2014 14:48:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200742752"
Message-ID: <5481C5CB.3010103@citrix.com>
Date: Fri, 5 Dec 2014 14:48:43 +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>, xen-devel <xen-devel@lists.xenproject.org>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
In-Reply-To: <5481C67D020000780004D2D1@mail.emea.novell.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	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: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 13:51, Jan Beulich wrote:
> The current value of nr_static_irqs + 256 is often too small for larger
> systems. Make it dependent on CPU count and number of IO-APIC pins on
> x86, and (until it obtains PCI support) simply NR_IRQS on ARM.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I obviously prefer the simpler version that removes an unnecessary
configuration option. But in the sense that this resolves the immediate
problem at least for the short to medium term:

Acked-by: David Vrabel <david.vrabel@citrix.com>

> +            d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs + extra_hwdom_irqs
> +                                           : arch_hwdom_irqs(domid);

This means if the user asks for 0 extra (by the command line) for hwdoms
they get the default which non-obvious.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:48:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:48:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuBd-0006Zn-L9; Fri, 05 Dec 2014 14:48:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XwuBc-0006ZZ-SY
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:48:48 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	10/7E-09842-0D5C1845; Fri, 05 Dec 2014 14:48:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417790926!13682415!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 6369 invoked from network); 5 Dec 2014 14:48:47 -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;
	5 Dec 2014 14:48:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200742752"
Message-ID: <5481C5CB.3010103@citrix.com>
Date: Fri, 5 Dec 2014 14:48:43 +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>, xen-devel <xen-devel@lists.xenproject.org>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
In-Reply-To: <5481C67D020000780004D2D1@mail.emea.novell.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	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: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 13:51, Jan Beulich wrote:
> The current value of nr_static_irqs + 256 is often too small for larger
> systems. Make it dependent on CPU count and number of IO-APIC pins on
> x86, and (until it obtains PCI support) simply NR_IRQS on ARM.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I obviously prefer the simpler version that removes an unnecessary
configuration option. But in the sense that this resolves the immediate
problem at least for the short to medium term:

Acked-by: David Vrabel <david.vrabel@citrix.com>

> +            d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs + extra_hwdom_irqs
> +                                           : arch_hwdom_irqs(domid);

This means if the user asks for 0 extra (by the command line) for hwdoms
they get the default which non-obvious.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:51:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuDw-0006oS-7m; Fri, 05 Dec 2014 14:51:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwuDu-0006oB-J3
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:51:10 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	73/BF-22777-D56C1845; Fri, 05 Dec 2014 14:51:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417791067!11782876!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 7463 invoked from network); 5 Dec 2014 14:51:09 -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 Dec 2014 14:51:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200372959"
Message-ID: <1417791061.22808.68.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 5 Dec 2014 14:51:01 +0000
In-Reply-To: <5481D3D1020000780004D35F@mail.emea.novell.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
	<5481D3D1020000780004D35F@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>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	IanJackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 14:48 +0000, Jan Beulich wrote:
> >>> On 05.12.14 at 15:27, <Ian.Campbell@eu.citrix.com> wrote:
> > On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
> >>  #define nr_static_irqs NR_IRQS
> >> +#define arch_hwdom_irqs(domid) NR_IRQS
> > 
> > FWIW gic_number_lines() is the ARM equivalent of getting the number of
> > GSIs.
> > 
> > *BUT* we don't actually use pirqs on ARM (everything goes via the
> > virtualised interrupt controller). So maybe we should be setting
> > nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> > from an ARM person, so I'm fine with you making this NR_IRQS in the
> > meantime.
> 
> Considering Julien also asking for this, I don't mind changing this to
> zero for ARM. Just let me know which way I can get this ack-ed.

If you are happy to provide a version using zero and Julien wants to
provide a tested-by then I'm fine with going that way.

I'm not happy taking that change untested though, and I don't expect you
to test it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:51:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuDw-0006oS-7m; Fri, 05 Dec 2014 14:51:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XwuDu-0006oB-J3
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:51:10 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	73/BF-22777-D56C1845; Fri, 05 Dec 2014 14:51:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417791067!11782876!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 7463 invoked from network); 5 Dec 2014 14:51:09 -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 Dec 2014 14:51:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200372959"
Message-ID: <1417791061.22808.68.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 5 Dec 2014 14:51:01 +0000
In-Reply-To: <5481D3D1020000780004D35F@mail.emea.novell.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
	<5481D3D1020000780004D35F@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>, Stefano
	Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	IanJackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 14:48 +0000, Jan Beulich wrote:
> >>> On 05.12.14 at 15:27, <Ian.Campbell@eu.citrix.com> wrote:
> > On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
> >>  #define nr_static_irqs NR_IRQS
> >> +#define arch_hwdom_irqs(domid) NR_IRQS
> > 
> > FWIW gic_number_lines() is the ARM equivalent of getting the number of
> > GSIs.
> > 
> > *BUT* we don't actually use pirqs on ARM (everything goes via the
> > virtualised interrupt controller). So maybe we should be setting
> > nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> > from an ARM person, so I'm fine with you making this NR_IRQS in the
> > meantime.
> 
> Considering Julien also asking for this, I don't mind changing this to
> zero for ARM. Just let me know which way I can get this ack-ed.

If you are happy to provide a version using zero and Julien wants to
provide a tested-by then I'm fine with going that way.

I'm not happy taking that change untested though, and I don't expect you
to test it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:51:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwuEK-0006sy-LJ; Fri, 05 Dec 2014 14:51:36 +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 1XwuEJ-0006se-Do
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:51:35 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3B/A2-15461-676C1845; Fri, 05 Dec 2014 14:51:34 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417791092!13367624!1
X-Originating-IP: [156.151.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 12093 invoked from network); 5 Dec 2014 14:51:34 -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; 5 Dec 2014 14:51:34 -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 sB5EpOYE031544
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 14:51:24 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
	sB5EpMTK006258
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 14:51:23 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
	sB5EpM2m017009; Fri, 5 Dec 2014 14:51:22 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 06:51:21 -0800
Date: Fri, 5 Dec 2014 15:51:17 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205145117.GX16236@olila.local.net-space.pl>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548038D5020000780004C9E8@mail.emea.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
> >>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
> > Hey,
> >
> > 1) Why is there in EFI code so many functions (e.g. efi_start(),
> >    efi_arch_edd(), ...) with local variables declared as a static?
> >    Though some of them have also regular local variables. I do not
> >    why it was decided that some of them must be the static and
> >    some of do not. It is a bit confusing. As I can see there is
> >    only one place which have to have local static (place_string()).
> >    Other seems to me as thing to save space on the stack but I do
> >    not think we need that. According to UEFI spec there will be
> >    "128 KiB or more of available stack space" when system runs in
> >    boot services mode. It is a lot of space. So, I think we can
> >    safely convert most of local static variables to normal local
> >    variables. Am I right?
>
> No. Consider what code results when you e.g. make an EFI_GUID
> instance non-static.

It could be quite big...

> > 2) I am going to add EDID support to EFI code. Should it be x86
> >    specific code or common one? As I can see EDID is defined as
> >    part of GOP so I think that EDID code should be placed in
> >    xen/common/efi/boot.c.
>
> Yes.

Granted!

> > 3) Should not we change xen/arch/*/efi/efi-boot.h to
> >    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
> >    code than definitions, declarations and short static
> >    functions. So, I think that it is more regular *.c file
> >    than header file.
>
> That's a matter of taste - I'd probably have made it .c too, but
> didn't mind it being .h as done by Roy (presumably on the basis
> that #include directives are preferred to have .h files as their
> operands). The only thing I regret is that I didn't ask for the
> pointless efi- prefix to be dropped.

As I can see a few people people agree to some extent with my suggestion.
Great! Sadly if we wish .c file than simple boot.c (as Jan suggested we can
drop efi- prefix) conflicts with exiting boot.c link. Is efi-boot.c OK?
Or maybe boot-arch.c? boot.h is OK for sure. Which one do you prefer?
Do you have better ideas?

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:51:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14: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 1XwuEK-0006sy-LJ; Fri, 05 Dec 2014 14:51:36 +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 1XwuEJ-0006se-Do
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:51:35 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3B/A2-15461-676C1845; Fri, 05 Dec 2014 14:51:34 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417791092!13367624!1
X-Originating-IP: [156.151.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 12093 invoked from network); 5 Dec 2014 14:51:34 -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; 5 Dec 2014 14:51:34 -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 sB5EpOYE031544
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 14:51:24 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
	sB5EpMTK006258
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 14:51:23 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
	sB5EpM2m017009; Fri, 5 Dec 2014 14:51:22 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 06:51:21 -0800
Date: Fri, 5 Dec 2014 15:51:17 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205145117.GX16236@olila.local.net-space.pl>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548038D5020000780004C9E8@mail.emea.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
> >>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
> > Hey,
> >
> > 1) Why is there in EFI code so many functions (e.g. efi_start(),
> >    efi_arch_edd(), ...) with local variables declared as a static?
> >    Though some of them have also regular local variables. I do not
> >    why it was decided that some of them must be the static and
> >    some of do not. It is a bit confusing. As I can see there is
> >    only one place which have to have local static (place_string()).
> >    Other seems to me as thing to save space on the stack but I do
> >    not think we need that. According to UEFI spec there will be
> >    "128 KiB or more of available stack space" when system runs in
> >    boot services mode. It is a lot of space. So, I think we can
> >    safely convert most of local static variables to normal local
> >    variables. Am I right?
>
> No. Consider what code results when you e.g. make an EFI_GUID
> instance non-static.

It could be quite big...

> > 2) I am going to add EDID support to EFI code. Should it be x86
> >    specific code or common one? As I can see EDID is defined as
> >    part of GOP so I think that EDID code should be placed in
> >    xen/common/efi/boot.c.
>
> Yes.

Granted!

> > 3) Should not we change xen/arch/*/efi/efi-boot.h to
> >    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
> >    code than definitions, declarations and short static
> >    functions. So, I think that it is more regular *.c file
> >    than header file.
>
> That's a matter of taste - I'd probably have made it .c too, but
> didn't mind it being .h as done by Roy (presumably on the basis
> that #include directives are preferred to have .h files as their
> operands). The only thing I regret is that I didn't ask for the
> pointless efi- prefix to be dropped.

As I can see a few people people agree to some extent with my suggestion.
Great! Sadly if we wish .c file than simple boot.c (as Jan suggested we can
drop efi- prefix) conflicts with exiting boot.c link. Is efi-boot.c OK?
Or maybe boot-arch.c? boot.h is OK for sure. Which one do you prefer?
Do you have better ideas?

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:52:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:52:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuF7-00071K-9k; Fri, 05 Dec 2014 14:52:25 +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 1XwuF5-000714-Nx
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:52:23 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	FB/A7-17735-6A6C1845; Fri, 05 Dec 2014 14:52:22 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417791140!11388417!1
X-Originating-IP: [156.151.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 11491 invoked from network); 5 Dec 2014 14:52:22 -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; 5 Dec 2014 14:52: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 sB5EqF8m032670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 14:52:16 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
	sB5EqENl020013
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 14:52:14 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
	sB5EqE33028612; Fri, 5 Dec 2014 14:52:14 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 06:52:13 -0800
Date: Fri, 5 Dec 2014 15:52:09 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141205145209.GY16236@olila.local.net-space.pl>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-3-git-send-email-daniel.kiper@oracle.com>
	<1417699555.22808.31.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417699555.22808.31.camel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org, keir@xen.org, ian.jackson@eu.citrix.com,
	jbeulich@suse.com, andrew.cooper3@citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 2/3] gitignore: ignore some
 files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 01:25:55PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 16:16 +0100, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>
> .gitignore updates seem harmless enough. so I've applied this and the
> third patch. Awaiting Konrad's verdict on the first.

Thanks!

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:52:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:52:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuF7-00071K-9k; Fri, 05 Dec 2014 14:52:25 +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 1XwuF5-000714-Nx
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:52:23 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	FB/A7-17735-6A6C1845; Fri, 05 Dec 2014 14:52:22 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417791140!11388417!1
X-Originating-IP: [156.151.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 11491 invoked from network); 5 Dec 2014 14:52:22 -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; 5 Dec 2014 14:52: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 sB5EqF8m032670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 14:52:16 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
	sB5EqENl020013
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 14:52:14 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
	sB5EqE33028612; Fri, 5 Dec 2014 14:52:14 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 06:52:13 -0800
Date: Fri, 5 Dec 2014 15:52:09 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141205145209.GY16236@olila.local.net-space.pl>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-3-git-send-email-daniel.kiper@oracle.com>
	<1417699555.22808.31.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417699555.22808.31.camel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org, keir@xen.org, ian.jackson@eu.citrix.com,
	jbeulich@suse.com, andrew.cooper3@citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 2/3] gitignore: ignore some
 files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 01:25:55PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 16:16 +0100, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>
> .gitignore updates seem harmless enough. so I've applied this and the
> third patch. Awaiting Konrad's verdict on the first.

Thanks!

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:53:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuFy-00079M-QI; Fri, 05 Dec 2014 14:53:18 +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 1XwuFw-000790-Pf
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:53:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AE/43-25276-CD6C1845; Fri, 05 Dec 2014 14:53:16 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417791194!13709485!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28328 invoked from network); 5 Dec 2014 14:53:15 -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; 5 Dec 2014 14:53:15 -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 sB5Er1iM014883
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 14:53:02 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
	sB5Er0hB022690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 14:53:01 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
	sB5Er0Be000523; Fri, 5 Dec 2014 14:53:00 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 06:52:59 -0800
Date: Fri, 5 Dec 2014 15:52:54 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20141205145254.GZ16236@olila.local.net-space.pl>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
	<20141202183620.GE32385@laptop.dumpdata.com>
	<20141205015340.GA19424@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205015340.GA19424@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
 target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 09:53:40PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> > > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> >
> > This usage scenario which I can see this being useful (and
> > I've tripped over this) is when you rebuild a new version
> > from the same repo. As in, this affects developers, but
>
>
> Lets get it in. It fixes an issues that I keep on tripping
> on and it is harmless enough that I don't see a way
> for this to cause any regressions.
>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Great! Thanks!

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:53:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuFy-00079M-QI; Fri, 05 Dec 2014 14:53:18 +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 1XwuFw-000790-Pf
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:53:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AE/43-25276-CD6C1845; Fri, 05 Dec 2014 14:53:16 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1417791194!13709485!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28328 invoked from network); 5 Dec 2014 14:53:15 -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; 5 Dec 2014 14:53:15 -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 sB5Er1iM014883
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 14:53:02 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
	sB5Er0hB022690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 14:53:01 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
	sB5Er0Be000523; Fri, 5 Dec 2014 14:53:00 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 06:52:59 -0800
Date: Fri, 5 Dec 2014 15:52:54 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20141205145254.GZ16236@olila.local.net-space.pl>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
	<20141202183620.GE32385@laptop.dumpdata.com>
	<20141205015340.GA19424@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205015340.GA19424@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
 target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 09:53:40PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> > > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> >
> > This usage scenario which I can see this being useful (and
> > I've tripped over this) is when you rebuild a new version
> > from the same repo. As in, this affects developers, but
>
>
> Lets get it in. It fixes an issues that I keep on tripping
> on and it is harmless enough that I don't see a way
> for this to cause any regressions.
>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Great! Thanks!

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:54:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuHH-0007Ks-A6; Fri, 05 Dec 2014 14:54: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 1XwuHF-0007Kh-Sp
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:54:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	60/55-25276-D27C1845; Fri, 05 Dec 2014 14:54:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417791276!13737328!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12221 invoked from network); 5 Dec 2014 14:54:36 -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; 5 Dec 2014 14:54:36 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 14:54:36 +0000
Message-Id: <5481D53D020000780004D381@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 14:54:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<5481C5CB.3010103@citrix.com>
In-Reply-To: <5481C5CB.3010103@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 15:48, <david.vrabel@citrix.com> wrote:
> On 05/12/14 13:51, Jan Beulich wrote:
>> +            d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs + extra_hwdom_irqs
>> +                                           : arch_hwdom_irqs(domid);
> 
> This means if the user asks for 0 extra (by the command line) for hwdoms
> they get the default which non-obvious.

I can certainly add another sentence saying so to the documentation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:54:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 14:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuHH-0007Ks-A6; Fri, 05 Dec 2014 14:54: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 1XwuHF-0007Kh-Sp
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 14:54:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	60/55-25276-D27C1845; Fri, 05 Dec 2014 14:54:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417791276!13737328!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12221 invoked from network); 5 Dec 2014 14:54:36 -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; 5 Dec 2014 14:54:36 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 14:54:36 +0000
Message-Id: <5481D53D020000780004D381@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 14:54:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<5481C5CB.3010103@citrix.com>
In-Reply-To: <5481C5CB.3010103@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 15:48, <david.vrabel@citrix.com> wrote:
> On 05/12/14 13:51, Jan Beulich wrote:
>> +            d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs + extra_hwdom_irqs
>> +                                           : arch_hwdom_irqs(domid);
> 
> This means if the user asks for 0 extra (by the command line) for hwdoms
> they get the default which non-obvious.

I can certainly add another sentence saying so to the documentation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 14:55:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 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 1XwuHn-0007QS-SD; Fri, 05 Dec 2014 14:55: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 1XwuHm-0007Q9-B8
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 14:55:10 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	43/0F-09284-D47C1845; Fri, 05 Dec 2014 14:55:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417791306!11365390!1
X-Originating-IP: [66.165.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 23509 invoked from network); 5 Dec 2014 14:55:08 -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 Dec 2014 14:55:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200745676"
Received: from ukmail1.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, 5 Dec 2014 09:55:05 -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 1XwuHg-00087r-CC;
	Fri, 05 Dec 2014 14:55:05 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 05 Dec
	2014 14:55:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 5 Dec 2014 14:55:04 +0000
Message-ID: <1417791304-26836-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417772967.22808.46.camel@citrix.com>
References: <1417772967.22808.46.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] ts-xen-build-prep: Install
	libxml-xpath-perl on build machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Required by latest libvirt, to build docs.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-xen-build-prep | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 05a7857..a7d0d03 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -177,7 +177,7 @@ sub prep () {
                                libglib2.0-dev liblzma-dev pkg-config
                                autoconf automake libtool xsltproc
                                libxml2-utils libxml2-dev libnl-dev
-                               libdevmapper-dev w3c-dtd-xhtml
+                               libdevmapper-dev w3c-dtd-xhtml libxml-xpath-perl
 			       ccache));
 
     target_cmd_root($ho, "chmod -R a+r /usr/share/git-core/templates");
-- 
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 Dec 05 14:55:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 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 1XwuHn-0007QS-SD; Fri, 05 Dec 2014 14:55: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 1XwuHm-0007Q9-B8
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 14:55:10 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	43/0F-09284-D47C1845; Fri, 05 Dec 2014 14:55:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417791306!11365390!1
X-Originating-IP: [66.165.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 23509 invoked from network); 5 Dec 2014 14:55:08 -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 Dec 2014 14:55:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200745676"
Received: from ukmail1.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, 5 Dec 2014 09:55:05 -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 1XwuHg-00087r-CC;
	Fri, 05 Dec 2014 14:55:05 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Fri, 05 Dec
	2014 14:55:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 5 Dec 2014 14:55:04 +0000
Message-ID: <1417791304-26836-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 2.1.1
In-Reply-To: <1417772967.22808.46.camel@citrix.com>
References: <1417772967.22808.46.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] ts-xen-build-prep: Install
	libxml-xpath-perl on build machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Required by latest libvirt, to build docs.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-xen-build-prep | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 05a7857..a7d0d03 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -177,7 +177,7 @@ sub prep () {
                                libglib2.0-dev liblzma-dev pkg-config
                                autoconf automake libtool xsltproc
                                libxml2-utils libxml2-dev libnl-dev
-                               libdevmapper-dev w3c-dtd-xhtml
+                               libdevmapper-dev w3c-dtd-xhtml libxml-xpath-perl
 			       ccache));
 
     target_cmd_root($ho, "chmod -R a+r /usr/share/git-core/templates");
-- 
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 Dec 05 15:00:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuMi-0007l9-Jn; Fri, 05 Dec 2014 15:00:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwuMg-0007l4-W6
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:00:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D2/BF-15461-E78C1845; Fri, 05 Dec 2014 15:00:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417791613!13722556!1
X-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 27957 invoked from network); 5 Dec 2014 15:00:13 -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; 5 Dec 2014 15:00:13 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:00:13 +0000
Message-Id: <5481D68E020000780004D3AD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:00:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<20141205145117.GX16236@olila.local.net-space.pl>
In-Reply-To: <20141205145117.GX16236@olila.local.net-space.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 15:51, <daniel.kiper@oracle.com> wrote:
> On Thu, Dec 04, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
>> >>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
>> > 3) Should not we change xen/arch/*/efi/efi-boot.h to
>> >    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
>> >    code than definitions, declarations and short static
>> >    functions. So, I think that it is more regular *.c file
>> >    than header file.
>>
>> That's a matter of taste - I'd probably have made it .c too, but
>> didn't mind it being .h as done by Roy (presumably on the basis
>> that #include directives are preferred to have .h files as their
>> operands). The only thing I regret is that I didn't ask for the
>> pointless efi- prefix to be dropped.
> 
> As I can see a few people people agree to some extent with my suggestion.
> Great! Sadly if we wish .c file than simple boot.c (as Jan suggested we can
> drop efi- prefix) conflicts with exiting boot.c link. Is efi-boot.c OK?
> Or maybe boot-arch.c? boot.h is OK for sure. Which one do you prefer?
> Do you have better ideas?

boot.h would be my preference given how things look like right now,
but I don't think this possibility of renaming warrants a much longer
discussion. Please also remember that renaming always implies more
cumbersome backporting, even if only slightly more.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:00:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuMi-0007l9-Jn; Fri, 05 Dec 2014 15:00:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwuMg-0007l4-W6
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:00:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D2/BF-15461-E78C1845; Fri, 05 Dec 2014 15:00:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417791613!13722556!1
X-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 27957 invoked from network); 5 Dec 2014 15:00:13 -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; 5 Dec 2014 15:00:13 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:00:13 +0000
Message-Id: <5481D68E020000780004D3AD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:00:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<20141205145117.GX16236@olila.local.net-space.pl>
In-Reply-To: <20141205145117.GX16236@olila.local.net-space.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 15:51, <daniel.kiper@oracle.com> wrote:
> On Thu, Dec 04, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
>> >>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
>> > 3) Should not we change xen/arch/*/efi/efi-boot.h to
>> >    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
>> >    code than definitions, declarations and short static
>> >    functions. So, I think that it is more regular *.c file
>> >    than header file.
>>
>> That's a matter of taste - I'd probably have made it .c too, but
>> didn't mind it being .h as done by Roy (presumably on the basis
>> that #include directives are preferred to have .h files as their
>> operands). The only thing I regret is that I didn't ask for the
>> pointless efi- prefix to be dropped.
> 
> As I can see a few people people agree to some extent with my suggestion.
> Great! Sadly if we wish .c file than simple boot.c (as Jan suggested we can
> drop efi- prefix) conflicts with exiting boot.c link. Is efi-boot.c OK?
> Or maybe boot-arch.c? boot.h is OK for sure. Which one do you prefer?
> Do you have better ideas?

boot.h would be my preference given how things look like right now,
but I don't think this possibility of renaming warrants a much longer
discussion. Please also remember that renaming always implies more
cumbersome backporting, even if only slightly more.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:01:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1XwuNt-0007qI-Pp; Fri, 05 Dec 2014 15:01:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XwuNs-0007q5-OJ
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:01:28 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E2/6A-09284-7C8C1845; Fri, 05 Dec 2014 15:01:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417791685!8945228!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 9125 invoked from network); 5 Dec 2014 15:01:27 -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;
	5 Dec 2014 15:01:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200748285"
Message-ID: <5481C8BC.4020906@citrix.com>
Date: Fri, 5 Dec 2014 15:01:16 +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: <5481A589020000780004D1E3@mail.emea.novell.com>
	<5481C2E2.1060306@citrix.com>
	<5481D38E020000780004D35C@mail.emea.novell.com>
In-Reply-To: <5481D38E020000780004D35C@mail.emea.novell.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/12/14 14:47, Jan Beulich wrote:
>>>> On 05.12.14 at 15:36, <andrew.cooper3@citrix.com> wrote:
>> On 05/12/14 11:31, Jan Beulich wrote:
>>> Andrew validly points out that even if these masks aren't a formal part
>>> of the hypercall interface, we aren't free to change them: A guest
>>> suspended for migration in the middle of a continuation would fail to
>>> work if resumed on a hypervisor using a different value. Hence add
>>> respective comments to their definitions.
>>>
>>> Additionally, to help future extensibility as well as in the spirit of
>>> reducing undefined behavior as much as possible, refuse hypercalls made
>>> with the respective bits non-zero when the respective sub-ops don't
>>> make use of those bits.
>>>
>>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> General principle looks good.  A couple of issues.
>>
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -4661,9 +4661,8 @@ int xenmem_add_to_physmap_one(
>>>  long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>  {
>>>      int rc;
>>> -    int op = cmd & MEMOP_CMD_MASK;
>> This needs a blanket start_iter check, as do_memory_op() has not done so.
> Not sure what you're asking for - why is removing the masking not
> sufficient?

There is no check to ensure that a non-preemptible arch_memoy_op is not
called with a non-zero start_iter.

This location needs something like

if ( cmd & ~MEMOP_CMD_MASK )
    return -ENOSYS;

>
>> The ARM code also needs one, as the caller has applied partial checks.
> The ARM code never applied a mask.

But the common code does, so the ARM code must follow suit for consistency.

Otherwise, we end up with ARM non-preemptible memory subops not failing
with -ENOSYS where primary memory ops would.

>
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -977,6 +992,9 @@ long do_memory_op(unsigned long cmd, XEN
>>>          unsigned int dom_vnodes, dom_vranges, dom_vcpus;
>>>          struct vnuma_info tmp;
>>>  
>>> +        if ( unlikely(start_extent) )
>>> +            return -ENOSYS;
>>> +
>>>          /*
>>>           * Guest passes nr_vnodes, number of regions and nr_vcpus thus
>>>           * we know how much memory guest has allocated.
>> XENMEM_get_vnumainfo needs a guard.
> Again - I don't understand what you're asking for: The hunk above
> is modifying the XENMEM_get_vnumainfo case.

My apologies - I can't see now why I identified get_vnumainfo as missing
a check.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:01:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1XwuNt-0007qI-Pp; Fri, 05 Dec 2014 15:01:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XwuNs-0007q5-OJ
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:01:28 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E2/6A-09284-7C8C1845; Fri, 05 Dec 2014 15:01:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417791685!8945228!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 9125 invoked from network); 5 Dec 2014 15:01:27 -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;
	5 Dec 2014 15:01:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200748285"
Message-ID: <5481C8BC.4020906@citrix.com>
Date: Fri, 5 Dec 2014 15:01:16 +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: <5481A589020000780004D1E3@mail.emea.novell.com>
	<5481C2E2.1060306@citrix.com>
	<5481D38E020000780004D35C@mail.emea.novell.com>
In-Reply-To: <5481D38E020000780004D35C@mail.emea.novell.com>
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/12/14 14:47, Jan Beulich wrote:
>>>> On 05.12.14 at 15:36, <andrew.cooper3@citrix.com> wrote:
>> On 05/12/14 11:31, Jan Beulich wrote:
>>> Andrew validly points out that even if these masks aren't a formal part
>>> of the hypercall interface, we aren't free to change them: A guest
>>> suspended for migration in the middle of a continuation would fail to
>>> work if resumed on a hypervisor using a different value. Hence add
>>> respective comments to their definitions.
>>>
>>> Additionally, to help future extensibility as well as in the spirit of
>>> reducing undefined behavior as much as possible, refuse hypercalls made
>>> with the respective bits non-zero when the respective sub-ops don't
>>> make use of those bits.
>>>
>>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> General principle looks good.  A couple of issues.
>>
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -4661,9 +4661,8 @@ int xenmem_add_to_physmap_one(
>>>  long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>  {
>>>      int rc;
>>> -    int op = cmd & MEMOP_CMD_MASK;
>> This needs a blanket start_iter check, as do_memory_op() has not done so.
> Not sure what you're asking for - why is removing the masking not
> sufficient?

There is no check to ensure that a non-preemptible arch_memoy_op is not
called with a non-zero start_iter.

This location needs something like

if ( cmd & ~MEMOP_CMD_MASK )
    return -ENOSYS;

>
>> The ARM code also needs one, as the caller has applied partial checks.
> The ARM code never applied a mask.

But the common code does, so the ARM code must follow suit for consistency.

Otherwise, we end up with ARM non-preemptible memory subops not failing
with -ENOSYS where primary memory ops would.

>
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -977,6 +992,9 @@ long do_memory_op(unsigned long cmd, XEN
>>>          unsigned int dom_vnodes, dom_vranges, dom_vcpus;
>>>          struct vnuma_info tmp;
>>>  
>>> +        if ( unlikely(start_extent) )
>>> +            return -ENOSYS;
>>> +
>>>          /*
>>>           * Guest passes nr_vnodes, number of regions and nr_vcpus thus
>>>           * we know how much memory guest has allocated.
>> XENMEM_get_vnumainfo needs a guard.
> Again - I don't understand what you're asking for: The hunk above
> is modifying the XENMEM_get_vnumainfo case.

My apologies - I can't see now why I identified get_vnumainfo as missing
a check.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:01:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:01:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuOH-0007tQ-6S; Fri, 05 Dec 2014 15:01:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwuOF-0007t7-28
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:01:51 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	97/13-15461-ED8C1845; Fri, 05 Dec 2014 15:01:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417791708!13739192!1
X-Originating-IP: [66.165.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 23814 invoked from network); 5 Dec 2014 15:01: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;
	5 Dec 2014 15:01:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200377975"
Received: from ukmail1.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, 5 Dec 2014 10:01: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 1XwuOB-0008Ee-RR;
	Fri, 05 Dec 2014 15:01:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwuOB-0007Ms-Jk;
	Fri, 05 Dec 2014 15:01:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.51419.429348.366753@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 15:01:47 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141205132723.GA4010@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<21633.41713.481177.905257@mariner.uk.xensource.com>
	<20141205122620.GA20558@aepfle.de>
	<21633.43125.817078.380788@mariner.uk.xensource.com>
	<20141205132723.GA4010@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to sysconfig.xencommons"):
> On Fri, Dec 05, Ian Jackson wrote:
> > I confess I don't know very much about selinux, but shouldn't we be
> > providing a reasonable default policy, rather than leaving it to the
> > distro or user to pass special options to configure ?  Or are things
> > in the selinux world so fragmented or fast-moving that such a generic
> > policy couldn't be written ?
> 
> I know nothing about SELinux.  Not sure why a context= is required
> anyway.  But I can find out next week if noone else has an idea how to
> deal with SELinux.

OK, thanks.

Anyway, I don't think this question should stand in the way of this
hunk of your patch, which is IMO obviously a move in the right
direction.

So if you shuffle things about as I suggested I will ack this hunk in
your next version of the series.

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 Dec 05 15:01:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:01:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuOH-0007tQ-6S; Fri, 05 Dec 2014 15:01:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwuOF-0007t7-28
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:01:51 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	97/13-15461-ED8C1845; Fri, 05 Dec 2014 15:01:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417791708!13739192!1
X-Originating-IP: [66.165.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 23814 invoked from network); 5 Dec 2014 15:01: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;
	5 Dec 2014 15:01:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200377975"
Received: from ukmail1.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, 5 Dec 2014 10:01: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 1XwuOB-0008Ee-RR;
	Fri, 05 Dec 2014 15:01:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwuOB-0007Ms-Jk;
	Fri, 05 Dec 2014 15:01:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.51419.429348.366753@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 15:01:47 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141205132723.GA4010@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<21633.41713.481177.905257@mariner.uk.xensource.com>
	<20141205122620.GA20558@aepfle.de>
	<21633.43125.817078.380788@mariner.uk.xensource.com>
	<20141205132723.GA4010@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX to sysconfig.xencommons"):
> On Fri, Dec 05, Ian Jackson wrote:
> > I confess I don't know very much about selinux, but shouldn't we be
> > providing a reasonable default policy, rather than leaving it to the
> > distro or user to pass special options to configure ?  Or are things
> > in the selinux world so fragmented or fast-moving that such a generic
> > policy couldn't be written ?
> 
> I know nothing about SELinux.  Not sure why a context= is required
> anyway.  But I can find out next week if noone else has an idea how to
> deal with SELinux.

OK, thanks.

Anyway, I don't think this question should stand in the way of this
hunk of your patch, which is IMO obviously a move in the right
direction.

So if you shuffle things about as I suggested I will ack this hunk in
your next version of the series.

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 Dec 05 15:05:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1XwuRL-0008Ci-Pq; Fri, 05 Dec 2014 15:05:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwuRK-0008Cb-Vo
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:05:03 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	B0/F9-27785-E99C1845; Fri, 05 Dec 2014 15:05:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417791901!13294187!1
X-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 7591 invoked from network); 5 Dec 2014 15:05:01 -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; 5 Dec 2014 15:05:01 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:05:01 +0000
Message-Id: <5481D7AD020000780004D3BF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:05:01 +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>
Subject: [Xen-devel] ucode=scan usefulness
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

having been surprised to find your cpio scanning code to not work I
had to realize that this can't possibly work when the initrd is
compressed. Considering that you found this useful nevertheless -
am I to imply that you're running with (and only considering) non-
compressed initrd? Are there plans to support compressed ones 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 Dec 05 15:05:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1XwuRL-0008Ci-Pq; Fri, 05 Dec 2014 15:05:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwuRK-0008Cb-Vo
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:05:03 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	B0/F9-27785-E99C1845; Fri, 05 Dec 2014 15:05:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417791901!13294187!1
X-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 7591 invoked from network); 5 Dec 2014 15:05:01 -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; 5 Dec 2014 15:05:01 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:05:01 +0000
Message-Id: <5481D7AD020000780004D3BF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:05:01 +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>
Subject: [Xen-devel] ucode=scan usefulness
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

having been surprised to find your cpio scanning code to not work I
had to realize that this can't possibly work when the initrd is
compressed. Considering that you found this useful nevertheless -
am I to imply that you're running with (and only considering) non-
compressed initrd? Are there plans to support compressed ones 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 Dec 05 15:11:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 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 1XwuXg-0008Ta-LQ; Fri, 05 Dec 2014 15:11:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwuXf-0008TV-MS
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 15:11:35 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	CD/00-28865-72BC1845; Fri, 05 Dec 2014 15:11:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417792292!8455790!1
X-Originating-IP: [66.165.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 19307 invoked from network); 5 Dec 2014 15:11:34 -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;
	5 Dec 2014 15:11:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200383307"
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, 5 Dec 2014 10:11: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 1XwuXT-00078s-9L;
	Fri, 05 Dec 2014 15:11:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwuXS-0002Zn-Vp;
	Fri, 05 Dec 2014 15:11:23 +0000
Date: Fri, 5 Dec 2014 15:11:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32089-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] 32089: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32089 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32089/

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

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
 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-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-qemuu-winxpsp3-vcpus1 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-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

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 Fri Dec 05 15:11:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 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 1XwuXg-0008Ta-LQ; Fri, 05 Dec 2014 15:11:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XwuXf-0008TV-MS
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 15:11:35 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	CD/00-28865-72BC1845; Fri, 05 Dec 2014 15:11:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417792292!8455790!1
X-Originating-IP: [66.165.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 19307 invoked from network); 5 Dec 2014 15:11:34 -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;
	5 Dec 2014 15:11:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200383307"
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, 5 Dec 2014 10:11: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 1XwuXT-00078s-9L;
	Fri, 05 Dec 2014 15:11:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XwuXS-0002Zn-Vp;
	Fri, 05 Dec 2014 15:11:23 +0000
Date: Fri, 5 Dec 2014 15:11:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32089-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] 32089: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32089 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32089/

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

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
 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-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-qemuu-winxpsp3-vcpus1 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-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

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 Fri Dec 05 15:16:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwucQ-0000OE-Gt; Fri, 05 Dec 2014 15:16: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 1XwucO-0000O8-Qf
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:16:28 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	87/8F-09842-C4CC1845; Fri, 05 Dec 2014 15:16:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417792587!13689012!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27519 invoked from network); 5 Dec 2014 15:16:27 -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; 5 Dec 2014 15:16:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:16:27 +0000
Message-Id: <5481DA5C020000780004D3DD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:16:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5481D7AD020000780004D3BF@mail.emea.novell.com>
In-Reply-To: <5481D7AD020000780004D3BF@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] ucode=scan usefulness
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 16:05, <JBeulich@suse.com> wrote:
> having been surprised to find your cpio scanning code to not work I
> had to realize that this can't possibly work when the initrd is
> compressed. Considering that you found this useful nevertheless -
> am I to imply that you're running with (and only considering) non-
> compressed initrd? Are there plans to support compressed ones too?

Never mind, I forgot that the blob gets prefixed uncompressed to
the compressed one, and got confused by seeing a fully compressed
image simply because the installer for some reason decided not to
install any microcode data.

Sorry for the noise,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:16:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwucQ-0000OE-Gt; Fri, 05 Dec 2014 15:16: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 1XwucO-0000O8-Qf
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:16:28 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	87/8F-09842-C4CC1845; Fri, 05 Dec 2014 15:16:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417792587!13689012!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27519 invoked from network); 5 Dec 2014 15:16:27 -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; 5 Dec 2014 15:16:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:16:27 +0000
Message-Id: <5481DA5C020000780004D3DD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:16:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5481D7AD020000780004D3BF@mail.emea.novell.com>
In-Reply-To: <5481D7AD020000780004D3BF@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] ucode=scan usefulness
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 16:05, <JBeulich@suse.com> wrote:
> having been surprised to find your cpio scanning code to not work I
> had to realize that this can't possibly work when the initrd is
> compressed. Considering that you found this useful nevertheless -
> am I to imply that you're running with (and only considering) non-
> compressed initrd? Are there plans to support compressed ones too?

Never mind, I forgot that the blob gets prefixed uncompressed to
the compressed one, and got confused by seeing a fully compressed
image simply because the installer for some reason decided not to
install any microcode data.

Sorry for the noise,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:18:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1Xwue2-0000WP-0v; Fri, 05 Dec 2014 15:18:10 +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 1Xwue0-0000WD-Pa
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:18:08 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	F7/8A-08051-0BCC1845; Fri, 05 Dec 2014 15:18:08 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417792687!7865383!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3201 invoked from network); 5 Dec 2014 15:18:07 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 15:18:07 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so1722626wib.16
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 07:18: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=mfdbZUgSz55ejAH8x/b8xw7JANL65f97kxpG+Kvh3DQ=;
	b=e9qlatxz71EFDPIy8KgtnGeGcyNCnpr1dfP9Hqu0CG4yj7j1iLXMIKrZXfnvx6h9V5
	NVK4vQ9Zz0mlFd96gNioXDzeihPx1MFpYCBzkDnlKv7NRGDHKcWubCLwjy7Q4m7gZdCC
	81v15MOnsF3h3v/bMPmMaB42QZrAL1zejc/VGjEWSxcaMb17SfkP4Dz3w9/mAhy8NVvm
	BjicyxmRKqWeJefMCKgQ4bBqHKizxaJetZrucIINFOm56IccsCWDKq9VG5ncNKmsX0lv
	aamcqHFkOla/OWqLd2KncsEBEG1JKYi+2lWPFwd7pqTnlPR+onK0cRBmOiq3ERgpH/8w
	vUpA==
X-Gm-Message-State: ALoCoQl0mbRqDuufvIwPOMt0kvBybOEtjOu6cDH/kXrPu/KKleahuSl/rq1u+bwZCTb0N0qUZUbB
X-Received: by 10.180.101.200 with SMTP id fi8mr4838518wib.77.1417792687158;
	Fri, 05 Dec 2014 07:18:07 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id n8sm45275858wjx.0.2014.12.05.07.18.05
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 07:18:06 -0800 (PST)
Message-ID: <5481CCAF.1040102@linaro.org>
Date: Fri, 05 Dec 2014 15:18:07 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>, 
	"Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>	<20141202110133.GA5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>	<20141202121151.GD5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>	<20141202155832.GH5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>	<20141204105021.GA16532@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
In-Reply-To: <20141205124233.GD31446@zion.uk.xensource.com>
Cc: "Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/14 12:42, Wei Liu wrote:
> On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
> [...]
>>> I think that's expected, because guest RX data path still uses grant_copy while
>>> guest TX uses grant_map to do zero-copy transmit.
>>
>> As far as I know, there are three main grant-related operations used in split device model: grant mapping, grant transfer and grant copy.
>> Grant transfer has not used now, and grant mapping and grant transfer both involve "TLB" refresh work for hypervisor, am I right?  Or only grant transfer has this overhead?
>
> Transfer is not used so I can't tell. Grant unmap causes TLB flush.
>
> I saw in an email the other day XenServer folks has some planned
> improvement to avoid TLB flush in Xen to upstream in 4.6 window. I can't
> speak for sure it will get upstreamed as I don't work on that.
>
>> Does grant copy surely has more overhead than grant mapping?
>>
>
> At the very least the zero-copy TX path is faster than previous copying
> path.
>
> But speaking of the micro operation I'm not sure.
>
> There was once persistent map prototype netback / netfront that
> establishes a memory pool between FE and BE then use memcpy to copy
> data. Unfortunately that prototype was not done right so the result was
> not good.
>
>> >From the code, I see that in TX, netback will do gnttab_batch_copy as well as gnttab_map_refs:
>>
>> <code> //netback.c:xenvif_tx_action
>> 	xenvif_tx_build_gops(queue, budget, &nr_cops, &nr_mops);
>>
>> 	if (nr_cops == 0)
>> 		return 0;
>>
>> 	gnttab_batch_copy(queue->tx_copy_ops, nr_cops);
>> 	if (nr_mops != 0) {
>> 		ret = gnttab_map_refs(queue->tx_map_ops,
>> 				      NULL,
>> 				      queue->pages_to_map,
>> 				      nr_mops);
>> 		BUG_ON(ret);
>> 	}
>> </code>
>>
>
> The copy is for the packet header. Mapping is for packet data.
>
> We need to copy header from guest so that it doesn't change under
> netback's feet.

It is also important because if the above mentioned "TLB flush 
avoidance" patch goes in to Xen, it will be important to grant copy the 
header rather than grant map plus memcpy. The latter is the old way, it 
touches the page so you can't avoid TLB flush.

>
> 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 Fri Dec 05 15:18:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1Xwue2-0000WP-0v; Fri, 05 Dec 2014 15:18:10 +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 1Xwue0-0000WD-Pa
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:18:08 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	F7/8A-08051-0BCC1845; Fri, 05 Dec 2014 15:18:08 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417792687!7865383!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3201 invoked from network); 5 Dec 2014 15:18:07 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 15:18:07 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so1722626wib.16
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 07:18: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=mfdbZUgSz55ejAH8x/b8xw7JANL65f97kxpG+Kvh3DQ=;
	b=e9qlatxz71EFDPIy8KgtnGeGcyNCnpr1dfP9Hqu0CG4yj7j1iLXMIKrZXfnvx6h9V5
	NVK4vQ9Zz0mlFd96gNioXDzeihPx1MFpYCBzkDnlKv7NRGDHKcWubCLwjy7Q4m7gZdCC
	81v15MOnsF3h3v/bMPmMaB42QZrAL1zejc/VGjEWSxcaMb17SfkP4Dz3w9/mAhy8NVvm
	BjicyxmRKqWeJefMCKgQ4bBqHKizxaJetZrucIINFOm56IccsCWDKq9VG5ncNKmsX0lv
	aamcqHFkOla/OWqLd2KncsEBEG1JKYi+2lWPFwd7pqTnlPR+onK0cRBmOiq3ERgpH/8w
	vUpA==
X-Gm-Message-State: ALoCoQl0mbRqDuufvIwPOMt0kvBybOEtjOu6cDH/kXrPu/KKleahuSl/rq1u+bwZCTb0N0qUZUbB
X-Received: by 10.180.101.200 with SMTP id fi8mr4838518wib.77.1417792687158;
	Fri, 05 Dec 2014 07:18:07 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id n8sm45275858wjx.0.2014.12.05.07.18.05
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 07:18:06 -0800 (PST)
Message-ID: <5481CCAF.1040102@linaro.org>
Date: Fri, 05 Dec 2014 15:18:07 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>, 
	"Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>	<20141202110133.GA5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>	<20141202121151.GD5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>	<20141202155832.GH5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>	<20141204105021.GA16532@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
In-Reply-To: <20141205124233.GD31446@zion.uk.xensource.com>
Cc: "Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/14 12:42, Wei Liu wrote:
> On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
> [...]
>>> I think that's expected, because guest RX data path still uses grant_copy while
>>> guest TX uses grant_map to do zero-copy transmit.
>>
>> As far as I know, there are three main grant-related operations used in split device model: grant mapping, grant transfer and grant copy.
>> Grant transfer has not used now, and grant mapping and grant transfer both involve "TLB" refresh work for hypervisor, am I right?  Or only grant transfer has this overhead?
>
> Transfer is not used so I can't tell. Grant unmap causes TLB flush.
>
> I saw in an email the other day XenServer folks has some planned
> improvement to avoid TLB flush in Xen to upstream in 4.6 window. I can't
> speak for sure it will get upstreamed as I don't work on that.
>
>> Does grant copy surely has more overhead than grant mapping?
>>
>
> At the very least the zero-copy TX path is faster than previous copying
> path.
>
> But speaking of the micro operation I'm not sure.
>
> There was once persistent map prototype netback / netfront that
> establishes a memory pool between FE and BE then use memcpy to copy
> data. Unfortunately that prototype was not done right so the result was
> not good.
>
>> >From the code, I see that in TX, netback will do gnttab_batch_copy as well as gnttab_map_refs:
>>
>> <code> //netback.c:xenvif_tx_action
>> 	xenvif_tx_build_gops(queue, budget, &nr_cops, &nr_mops);
>>
>> 	if (nr_cops == 0)
>> 		return 0;
>>
>> 	gnttab_batch_copy(queue->tx_copy_ops, nr_cops);
>> 	if (nr_mops != 0) {
>> 		ret = gnttab_map_refs(queue->tx_map_ops,
>> 				      NULL,
>> 				      queue->pages_to_map,
>> 				      nr_mops);
>> 		BUG_ON(ret);
>> 	}
>> </code>
>>
>
> The copy is for the packet header. Mapping is for packet data.
>
> We need to copy header from guest so that it doesn't change under
> netback's feet.

It is also important because if the above mentioned "TLB flush 
avoidance" patch goes in to Xen, it will be important to grant copy the 
header rather than grant map plus memcpy. The latter is the old way, it 
touches the page so you can't avoid TLB flush.

>
> 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 Fri Dec 05 15:18:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:18:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwueM-0000Za-Dt; Fri, 05 Dec 2014 15:18: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 1XwueL-0000ZH-5z
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:18:29 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	85/33-02702-4CCC1845; Fri, 05 Dec 2014 15:18:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417792707!13297921!1
X-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 28745 invoked from network); 5 Dec 2014 15:18:27 -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; 5 Dec 2014 15:18:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:18:27 +0000
Message-Id: <5481DAD4020000780004D3EA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:18:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5481A589020000780004D1E3@mail.emea.novell.com>
	<5481C2E2.1060306@citrix.com>
	<5481D38E020000780004D35C@mail.emea.novell.com>
	<5481C8BC.4020906@citrix.com>
In-Reply-To: <5481C8BC.4020906@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 16:01, <andrew.cooper3@citrix.com> wrote:
> On 05/12/14 14:47, Jan Beulich wrote:
>>>>> On 05.12.14 at 15:36, <andrew.cooper3@citrix.com> wrote:
>>> On 05/12/14 11:31, Jan Beulich wrote:
>>>> Andrew validly points out that even if these masks aren't a formal part
>>>> of the hypercall interface, we aren't free to change them: A guest
>>>> suspended for migration in the middle of a continuation would fail to
>>>> work if resumed on a hypervisor using a different value. Hence add
>>>> respective comments to their definitions.
>>>>
>>>> Additionally, to help future extensibility as well as in the spirit of
>>>> reducing undefined behavior as much as possible, refuse hypercalls made
>>>> with the respective bits non-zero when the respective sub-ops don't
>>>> make use of those bits.
>>>>
>>>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> General principle looks good.  A couple of issues.
>>>
>>>> --- a/xen/arch/x86/mm.c
>>>> +++ b/xen/arch/x86/mm.c
>>>> @@ -4661,9 +4661,8 @@ int xenmem_add_to_physmap_one(
>>>>  long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>>  {
>>>>      int rc;
>>>> -    int op = cmd & MEMOP_CMD_MASK;
>>> This needs a blanket start_iter check, as do_memory_op() has not done so.
>> Not sure what you're asking for - why is removing the masking not
>> sufficient?
> 
> There is no check to ensure that a non-preemptible arch_memoy_op is not
> called with a non-zero start_iter.
> 
> This location needs something like
> 
> if ( cmd & ~MEMOP_CMD_MASK )
>     return -ENOSYS;

I'm sorry - the default case of sub_arch_memory_op() will ensure
this.

>>> The ARM code also needs one, as the caller has applied partial checks.
>> The ARM code never applied a mask.
> 
> But the common code does, so the ARM code must follow suit for consistency.
> 
> Otherwise, we end up with ARM non-preemptible memory subops not failing
> with -ENOSYS where primary memory ops would.

Again, the default case results in -ENOSYS for any with the high
bits set.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:18:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:18:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwueM-0000Za-Dt; Fri, 05 Dec 2014 15:18: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 1XwueL-0000ZH-5z
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:18:29 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	85/33-02702-4CCC1845; Fri, 05 Dec 2014 15:18:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417792707!13297921!1
X-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 28745 invoked from network); 5 Dec 2014 15:18:27 -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; 5 Dec 2014 15:18:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:18:27 +0000
Message-Id: <5481DAD4020000780004D3EA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:18:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5481A589020000780004D1E3@mail.emea.novell.com>
	<5481C2E2.1060306@citrix.com>
	<5481D38E020000780004D35C@mail.emea.novell.com>
	<5481C8BC.4020906@citrix.com>
In-Reply-To: <5481C8BC.4020906@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 16:01, <andrew.cooper3@citrix.com> wrote:
> On 05/12/14 14:47, Jan Beulich wrote:
>>>>> On 05.12.14 at 15:36, <andrew.cooper3@citrix.com> wrote:
>>> On 05/12/14 11:31, Jan Beulich wrote:
>>>> Andrew validly points out that even if these masks aren't a formal part
>>>> of the hypercall interface, we aren't free to change them: A guest
>>>> suspended for migration in the middle of a continuation would fail to
>>>> work if resumed on a hypervisor using a different value. Hence add
>>>> respective comments to their definitions.
>>>>
>>>> Additionally, to help future extensibility as well as in the spirit of
>>>> reducing undefined behavior as much as possible, refuse hypercalls made
>>>> with the respective bits non-zero when the respective sub-ops don't
>>>> make use of those bits.
>>>>
>>>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> General principle looks good.  A couple of issues.
>>>
>>>> --- a/xen/arch/x86/mm.c
>>>> +++ b/xen/arch/x86/mm.c
>>>> @@ -4661,9 +4661,8 @@ int xenmem_add_to_physmap_one(
>>>>  long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>>  {
>>>>      int rc;
>>>> -    int op = cmd & MEMOP_CMD_MASK;
>>> This needs a blanket start_iter check, as do_memory_op() has not done so.
>> Not sure what you're asking for - why is removing the masking not
>> sufficient?
> 
> There is no check to ensure that a non-preemptible arch_memoy_op is not
> called with a non-zero start_iter.
> 
> This location needs something like
> 
> if ( cmd & ~MEMOP_CMD_MASK )
>     return -ENOSYS;

I'm sorry - the default case of sub_arch_memory_op() will ensure
this.

>>> The ARM code also needs one, as the caller has applied partial checks.
>> The ARM code never applied a mask.
> 
> But the common code does, so the ARM code must follow suit for consistency.
> 
> Otherwise, we end up with ARM non-preemptible memory subops not failing
> with -ENOSYS where primary memory ops would.

Again, the default case results in -ENOSYS for any with the high
bits set.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:21:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1Xwugj-0000zn-Vh; Fri, 05 Dec 2014 15:20:57 +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 1Xwugi-0000zC-Jp
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:20:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FD/81-25276-75DC1845; Fri, 05 Dec 2014 15:20:55 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417792855!13727464!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 22309 invoked from network); 5 Dec 2014 15:20:55 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 15:20:55 -0000
Received: by mail-wg0-f47.google.com with SMTP id n12so1161931wgh.6
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 07:20: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=hCfyOAskfru6dWHHvsTgic45H+VPXmjKT8rCsAeaX8c=;
	b=hOPSGp+K1h+9DmCJbKdo21pFxWw5e3GNpUF/U7YbSrG6pcM8wdMVvppITqpTm2iBz7
	r1z1cGRrDJlj21twLqIXNM7hIgIJTkioZMLVPfBU631erTdS/lkit2ui7sEensaE1m8h
	MOhsiWyorFH4K8Nvy0DfGM7G7HKPHpK93pB25A+UoEuEfZzU+fWF2YrpyEdehWx0vZv5
	HlDqSMOXKmM3baHWFn5irOL0nAeGe73vr1kaDupp9bdGaatzJVP8WAWF9A+bG64buHEZ
	vHOXdCYc5WlV3UOQuFOkOTBNIZopiHNuQaa2vMFC9lMDKarDN8A1XwQWWhmb/s7m1i65
	K8Tg==
X-Gm-Message-State: ALoCoQnOlkX0HOwsEahdi2dlmBkLeK12CSyvEIOZzh0H8nuxfHlp/ZUtQaEg3Pb7mCwyUcYu7Ndt
X-Received: by 10.194.189.138 with SMTP id gi10mr26162714wjc.86.1417792855117; 
	Fri, 05 Dec 2014 07:20:55 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id
	gl11sm19965246wjc.40.2014.12.05.07.20.53 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 07:20:54 -0800 (PST)
Message-ID: <5481CD57.607@linaro.org>
Date: Fri, 05 Dec 2014 15:20:55 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>	<20141202110133.GA5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>	<20141202121151.GD5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>	<20141202155832.GH5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
	<54806315.6010007@linaro.org>
	<3A6795EA1206904E94BEC8EF9DF109AE23933926@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE23933926@SZXEMA512-MBX.china.huawei.com>
Cc: jonathan.davies@citrix.com, "Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 04/12/14 14:31, Zhangleiqiang (Trump) wrote:
>> -----Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss@linaro.org]
>> Sent: Thursday, December 04, 2014 9:35 PM
>> To: Zhangleiqiang (Trump); Wei Liu; xen-devel@lists.xen.org
>> Cc: Xiaoding (B); Zhuangyuxin; zhangleiqiang; Luohao (brian); Yuzhou (C)
>> Subject: Re: [Xen-devel] Poor network performance between DomU with
>> multiqueue support
>>
>>
>>
>> On 04/12/14 12:09, Zhangleiqiang (Trump) wrote:
>>>> I think that's expected, because guest RX data path still uses
>>>> grant_copy while
>>>>> guest TX uses grant_map to do zero-copy transmit.
>>> As I understand, the RX process is as follows:
>>> 1. Phy NIC receive packet
>>> 2. XEN Hypervisor trigger interrupt to Dom0 3. Dom0' s NIC driver do
>>> the "RX" operation, and the packet is stored into SKB which is also
>>> owned/shared with netback
>> Not that easy. There is something between the NIC driver and netback which
>> directs the packets, e.g. the old bridge driver, ovs, or the IP stack of the kernel.
>>> 4. NetBack notify netfront through event channel that a packet is
>>> receiving 5. Netfront grant a buffer for receiving and notify netback
>>> the GR (if using grant-resue mechanism, netfront just notify the GR to
>>> netback) through IO Ring
>> It looks a bit confusing in the code, but netfront put "requests" on the ring
>> buffer, which contains the grant ref of the guest page where the backend can
>> copy. When the packet comes, netback consumes these requests and send
>> back a response telling the guest the grant copy of the packet finished, it can
>> start handling the data. (sending a response means it's placing a response in
>> the ring and trigger the event channel) And ideally netback should always have
>> requests in the ring, so it doesn't have to wait for the guest to fill it up.
>
>>> 6. NetBack do the grant_copy to copy packet from its SKB to the buffer
>>> referenced by GR, and notify netfront through event channel 7.
>>> Netfront copy the data from buffer to user-level app's SKB
>> Or wherever that SKB should go, yes. Like with any received packet on a real
>> network interface.
>>>
>>> Am I right? Why not using zero-copy transmit in guest RX data pash too ?
>> Because that means you are mapping that memory to the guest, and you won't
>> have any guarantee when the guest will release them. And netback can't just
>> unmap them forcibly after a timeout, because finding a correct timeout value
>> would be quite impossible.
>> A malicious/buggy/overloaded guest can hold on to Dom0 memory indefinitely,
>> but it even becomes worse if the memory came from another
>> guest: you can't shutdown that guest for example, until all its memory is
>> returned to him.
>
> Thanks for your detailed explanation about RX data path, I have get it, :)
>
> About the issue that poor performance between DomU to DomU, but high throughout between Dom0 to remote Dom0/DomU mentioned in my previous mail, do you have any idea about it?
>
> I am wondering if netfront/netback can be optimized to reach the 10Gbps throughout between DomUs running on different hosts connected with 10GE network. Currently, it seems like the TX is not the bottleneck, because we can reach the aggregate throughout of 9Gbps when sending packets from one DomU to other 3 DomUs running on different host. So I think the bottleneck maybe the RX, are you agreed with me?
>
> I am wondering what is the main reason that prevent RX to reach the higher throughout? Compared to KVM+virtio+vhost, which can reach high throughout, the RX has extra grantcopy operation, and the grantcopy operation may be one reason for it. Do you have any idea about it too?
It's quite sure that the grant copy is the bottleneck for a single queue 
RX traffic. I don't know what's the plan to help that, currently only a 
faster CPU can help you with that.

>
>>
>> Regards,
>>
>> Zoli

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:21:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1Xwugj-0000zn-Vh; Fri, 05 Dec 2014 15:20:57 +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 1Xwugi-0000zC-Jp
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:20:56 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FD/81-25276-75DC1845; Fri, 05 Dec 2014 15:20:55 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417792855!13727464!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 22309 invoked from network); 5 Dec 2014 15:20:55 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 15:20:55 -0000
Received: by mail-wg0-f47.google.com with SMTP id n12so1161931wgh.6
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 07:20: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=hCfyOAskfru6dWHHvsTgic45H+VPXmjKT8rCsAeaX8c=;
	b=hOPSGp+K1h+9DmCJbKdo21pFxWw5e3GNpUF/U7YbSrG6pcM8wdMVvppITqpTm2iBz7
	r1z1cGRrDJlj21twLqIXNM7hIgIJTkioZMLVPfBU631erTdS/lkit2ui7sEensaE1m8h
	MOhsiWyorFH4K8Nvy0DfGM7G7HKPHpK93pB25A+UoEuEfZzU+fWF2YrpyEdehWx0vZv5
	HlDqSMOXKmM3baHWFn5irOL0nAeGe73vr1kaDupp9bdGaatzJVP8WAWF9A+bG64buHEZ
	vHOXdCYc5WlV3UOQuFOkOTBNIZopiHNuQaa2vMFC9lMDKarDN8A1XwQWWhmb/s7m1i65
	K8Tg==
X-Gm-Message-State: ALoCoQnOlkX0HOwsEahdi2dlmBkLeK12CSyvEIOZzh0H8nuxfHlp/ZUtQaEg3Pb7mCwyUcYu7Ndt
X-Received: by 10.194.189.138 with SMTP id gi10mr26162714wjc.86.1417792855117; 
	Fri, 05 Dec 2014 07:20:55 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id
	gl11sm19965246wjc.40.2014.12.05.07.20.53 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 07:20:54 -0800 (PST)
Message-ID: <5481CD57.607@linaro.org>
Date: Fri, 05 Dec 2014 15:20:55 +0000
From: Zoltan Kiss <zoltan.kiss@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>	<20141202110133.GA5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>	<20141202121151.GD5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>	<20141202155832.GH5768@zion.uk.xensource.com>	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
	<54806315.6010007@linaro.org>
	<3A6795EA1206904E94BEC8EF9DF109AE23933926@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE23933926@SZXEMA512-MBX.china.huawei.com>
Cc: jonathan.davies@citrix.com, "Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 04/12/14 14:31, Zhangleiqiang (Trump) wrote:
>> -----Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss@linaro.org]
>> Sent: Thursday, December 04, 2014 9:35 PM
>> To: Zhangleiqiang (Trump); Wei Liu; xen-devel@lists.xen.org
>> Cc: Xiaoding (B); Zhuangyuxin; zhangleiqiang; Luohao (brian); Yuzhou (C)
>> Subject: Re: [Xen-devel] Poor network performance between DomU with
>> multiqueue support
>>
>>
>>
>> On 04/12/14 12:09, Zhangleiqiang (Trump) wrote:
>>>> I think that's expected, because guest RX data path still uses
>>>> grant_copy while
>>>>> guest TX uses grant_map to do zero-copy transmit.
>>> As I understand, the RX process is as follows:
>>> 1. Phy NIC receive packet
>>> 2. XEN Hypervisor trigger interrupt to Dom0 3. Dom0' s NIC driver do
>>> the "RX" operation, and the packet is stored into SKB which is also
>>> owned/shared with netback
>> Not that easy. There is something between the NIC driver and netback which
>> directs the packets, e.g. the old bridge driver, ovs, or the IP stack of the kernel.
>>> 4. NetBack notify netfront through event channel that a packet is
>>> receiving 5. Netfront grant a buffer for receiving and notify netback
>>> the GR (if using grant-resue mechanism, netfront just notify the GR to
>>> netback) through IO Ring
>> It looks a bit confusing in the code, but netfront put "requests" on the ring
>> buffer, which contains the grant ref of the guest page where the backend can
>> copy. When the packet comes, netback consumes these requests and send
>> back a response telling the guest the grant copy of the packet finished, it can
>> start handling the data. (sending a response means it's placing a response in
>> the ring and trigger the event channel) And ideally netback should always have
>> requests in the ring, so it doesn't have to wait for the guest to fill it up.
>
>>> 6. NetBack do the grant_copy to copy packet from its SKB to the buffer
>>> referenced by GR, and notify netfront through event channel 7.
>>> Netfront copy the data from buffer to user-level app's SKB
>> Or wherever that SKB should go, yes. Like with any received packet on a real
>> network interface.
>>>
>>> Am I right? Why not using zero-copy transmit in guest RX data pash too ?
>> Because that means you are mapping that memory to the guest, and you won't
>> have any guarantee when the guest will release them. And netback can't just
>> unmap them forcibly after a timeout, because finding a correct timeout value
>> would be quite impossible.
>> A malicious/buggy/overloaded guest can hold on to Dom0 memory indefinitely,
>> but it even becomes worse if the memory came from another
>> guest: you can't shutdown that guest for example, until all its memory is
>> returned to him.
>
> Thanks for your detailed explanation about RX data path, I have get it, :)
>
> About the issue that poor performance between DomU to DomU, but high throughout between Dom0 to remote Dom0/DomU mentioned in my previous mail, do you have any idea about it?
>
> I am wondering if netfront/netback can be optimized to reach the 10Gbps throughout between DomUs running on different hosts connected with 10GE network. Currently, it seems like the TX is not the bottleneck, because we can reach the aggregate throughout of 9Gbps when sending packets from one DomU to other 3 DomUs running on different host. So I think the bottleneck maybe the RX, are you agreed with me?
>
> I am wondering what is the main reason that prevent RX to reach the higher throughout? Compared to KVM+virtio+vhost, which can reach high throughout, the RX has extra grantcopy operation, and the grantcopy operation may be one reason for it. Do you have any idea about it too?
It's quite sure that the grant copy is the bottleneck for a single queue 
RX traffic. I don't know what's the plan to help that, currently only a 
faster CPU can help you with that.

>
>>
>> Regards,
>>
>> Zoli

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:24:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwujx-0001ZK-Ih; Fri, 05 Dec 2014 15:24:17 +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 1Xwujw-0001ZE-GP
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:24:16 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	8F/A7-25727-F1EC1845; Fri, 05 Dec 2014 15:24:15 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417793050!11395058!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 16446 invoked from network); 5 Dec 2014 15:24:11 -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;
	5 Dec 2014 15:24:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200760161"
Message-ID: <5481CE18.9020002@citrix.com>
Date: Fri, 5 Dec 2014 15:24:08 +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: <5481A589020000780004D1E3@mail.emea.novell.com>
	<5481C2E2.1060306@citrix.com>
	<5481D38E020000780004D35C@mail.emea.novell.com>
	<5481C8BC.4020906@citrix.com>
	<5481DAD4020000780004D3EA@mail.emea.novell.com>
In-Reply-To: <5481DAD4020000780004D3EA@mail.emea.novell.com>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/12/14 15:18, Jan Beulich wrote:
>>>> On 05.12.14 at 16:01, <andrew.cooper3@citrix.com> wrote:
>> On 05/12/14 14:47, Jan Beulich wrote:
>>>>>> On 05.12.14 at 15:36, <andrew.cooper3@citrix.com> wrote:
>>>> On 05/12/14 11:31, Jan Beulich wrote:
>>>>> Andrew validly points out that even if these masks aren't a formal part
>>>>> of the hypercall interface, we aren't free to change them: A guest
>>>>> suspended for migration in the middle of a continuation would fail to
>>>>> work if resumed on a hypervisor using a different value. Hence add
>>>>> respective comments to their definitions.
>>>>>
>>>>> Additionally, to help future extensibility as well as in the spirit of
>>>>> reducing undefined behavior as much as possible, refuse hypercalls made
>>>>> with the respective bits non-zero when the respective sub-ops don't
>>>>> make use of those bits.
>>>>>
>>>>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>> General principle looks good.  A couple of issues.
>>>>
>>>>> --- a/xen/arch/x86/mm.c
>>>>> +++ b/xen/arch/x86/mm.c
>>>>> @@ -4661,9 +4661,8 @@ int xenmem_add_to_physmap_one(
>>>>>  long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>>>  {
>>>>>      int rc;
>>>>> -    int op = cmd & MEMOP_CMD_MASK;
>>>> This needs a blanket start_iter check, as do_memory_op() has not done so.
>>> Not sure what you're asking for - why is removing the masking not
>>> sufficient?
>> There is no check to ensure that a non-preemptible arch_memoy_op is not
>> called with a non-zero start_iter.
>>
>> This location needs something like
>>
>> if ( cmd & ~MEMOP_CMD_MASK )
>>     return -ENOSYS;
> I'm sorry - the default case of sub_arch_memory_op() will ensure
> this.

Ah - I see now.  That is subtle.  Better remember to double check the
first patch which needs to add a preemptible subop.

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:24:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwujx-0001ZK-Ih; Fri, 05 Dec 2014 15:24:17 +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 1Xwujw-0001ZE-GP
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:24:16 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	8F/A7-25727-F1EC1845; Fri, 05 Dec 2014 15:24:15 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417793050!11395058!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 16446 invoked from network); 5 Dec 2014 15:24:11 -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;
	5 Dec 2014 15:24:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200760161"
Message-ID: <5481CE18.9020002@citrix.com>
Date: Fri, 5 Dec 2014 15:24:08 +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: <5481A589020000780004D1E3@mail.emea.novell.com>
	<5481C2E2.1060306@citrix.com>
	<5481D38E020000780004D35C@mail.emea.novell.com>
	<5481C8BC.4020906@citrix.com>
	<5481DAD4020000780004D3EA@mail.emea.novell.com>
In-Reply-To: <5481DAD4020000780004D3EA@mail.emea.novell.com>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/12/14 15:18, Jan Beulich wrote:
>>>> On 05.12.14 at 16:01, <andrew.cooper3@citrix.com> wrote:
>> On 05/12/14 14:47, Jan Beulich wrote:
>>>>>> On 05.12.14 at 15:36, <andrew.cooper3@citrix.com> wrote:
>>>> On 05/12/14 11:31, Jan Beulich wrote:
>>>>> Andrew validly points out that even if these masks aren't a formal part
>>>>> of the hypercall interface, we aren't free to change them: A guest
>>>>> suspended for migration in the middle of a continuation would fail to
>>>>> work if resumed on a hypervisor using a different value. Hence add
>>>>> respective comments to their definitions.
>>>>>
>>>>> Additionally, to help future extensibility as well as in the spirit of
>>>>> reducing undefined behavior as much as possible, refuse hypercalls made
>>>>> with the respective bits non-zero when the respective sub-ops don't
>>>>> make use of those bits.
>>>>>
>>>>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>> General principle looks good.  A couple of issues.
>>>>
>>>>> --- a/xen/arch/x86/mm.c
>>>>> +++ b/xen/arch/x86/mm.c
>>>>> @@ -4661,9 +4661,8 @@ int xenmem_add_to_physmap_one(
>>>>>  long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>>>  {
>>>>>      int rc;
>>>>> -    int op = cmd & MEMOP_CMD_MASK;
>>>> This needs a blanket start_iter check, as do_memory_op() has not done so.
>>> Not sure what you're asking for - why is removing the masking not
>>> sufficient?
>> There is no check to ensure that a non-preemptible arch_memoy_op is not
>> called with a non-zero start_iter.
>>
>> This location needs something like
>>
>> if ( cmd & ~MEMOP_CMD_MASK )
>>     return -ENOSYS;
> I'm sorry - the default case of sub_arch_memory_op() will ensure
> this.

Ah - I see now.  That is subtle.  Better remember to double check the
first patch which needs to add a preemptible subop.

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:26:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1Xwulg-0001fG-2Q; Fri, 05 Dec 2014 15:26: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 1Xwulf-0001f9-CC
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:26:03 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	5B/80-02699-A8EC1845; Fri, 05 Dec 2014 15:26:02 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417793161!13278528!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 515 invoked from network); 5 Dec 2014 15:26:02 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 15:26:02 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so1740281wib.1
	for <xen-devel@lists.xenproject.org>;
	Fri, 05 Dec 2014 07:26: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=ytDyVFKUJtp6cQ06pyDloOgAzz4k7t/CRHahRhPSkCo=;
	b=LNeIpbXnelZOIOHjRomSxMvit1PFHqnq5g//gJtIpANPPQNu2QXoAF+bOlbQ3lZg5Y
	wHgkk9/AbvrT5YfEmgRMHIfIomMkiTnbemperGZ/c8UfnzQ8HUrsOTXguRLDHldahBSm
	uLPSmDAO1tZRXF9j+/9mjnb4GP3CvG6/g98YWUNKtXBUF7Vh/Se01+hTyzR391dAfnwv
	xKmAy2ZvKdAyXShghh/K1KeVreLChLKDMTh4IVW70qv4i9QjKhsuQpfikAjmdugFjBsK
	FtUiVoniEk8I3cKcJ+C+5XyvvUDuyn+aZ57QTTN+HtuRG8ShpaCGpuAHd5c/EDb3QXpT
	tXbw==
X-Gm-Message-State: ALoCoQnFJwcpVQqe4jNL6jrwud3L49fgqjWBnHWW5JS53n+Zgj07a8iVCTnDDYsaVqGGFfjThQMT
X-Received: by 10.194.48.109 with SMTP id k13mr25553767wjn.7.1417793161702;
	Fri, 05 Dec 2014 07:26:01 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	bs2sm28123844wjc.43.2014.12.05.07.26.00 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 07:26:00 -0800 (PST)
Message-ID: <5481CE85.8010502@linaro.org>
Date: Fri, 05 Dec 2014 15:25:57 +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@eu.citrix.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>	
	<1417789634.22808.66.camel@eu.citrix.com>
	<5481C30B.3020901@linaro.org>
	<1417790527.22808.67.camel@eu.citrix.com>
In-Reply-To: <1417790527.22808.67.camel@eu.citrix.com>
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 14:42, Ian Campbell wrote:
> On Fri, 2014-12-05 at 14:36 +0000, Julien Grall wrote:
>> Hi,
>>
>> On 05/12/14 14:27, Ian Campbell wrote:
>>> On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>>>>  #define nr_static_irqs NR_IRQS
>>>> +#define arch_hwdom_irqs(domid) NR_IRQS
>>>
>>> FWIW gic_number_lines() is the ARM equivalent of getting the number of
>>> GSIs.
>>>
>>> *BUT* we don't actually use pirqs on ARM (everything goes via the
>>> virtualised interrupt controller). So maybe we should be setting
>>> nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
>>> from an ARM person, so I'm fine with you making this NR_IRQS in the
>>> meantime.
>>
>> As we already know that PIRQ is not used on ARM, it would make sense to
>> use directly in this patch 0.
> 
> Are you offering to give a tested-by if Jan posts such a patch?

nr_pirqs is used in 2 different place (without counting this setting):
	- event channel => We don't care on ARM as alloc_pirq_struct is
returning NULL
	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
AFAIU the pirq number is different on each domain. But we use it to
check permission on both domain. Shouldn't we translate the pirq to irq
for the current->domain?

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 Dec 05 15:26:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1Xwulg-0001fG-2Q; Fri, 05 Dec 2014 15:26: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 1Xwulf-0001f9-CC
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:26:03 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	5B/80-02699-A8EC1845; Fri, 05 Dec 2014 15:26:02 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417793161!13278528!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 515 invoked from network); 5 Dec 2014 15:26:02 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 15:26:02 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so1740281wib.1
	for <xen-devel@lists.xenproject.org>;
	Fri, 05 Dec 2014 07:26: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=ytDyVFKUJtp6cQ06pyDloOgAzz4k7t/CRHahRhPSkCo=;
	b=LNeIpbXnelZOIOHjRomSxMvit1PFHqnq5g//gJtIpANPPQNu2QXoAF+bOlbQ3lZg5Y
	wHgkk9/AbvrT5YfEmgRMHIfIomMkiTnbemperGZ/c8UfnzQ8HUrsOTXguRLDHldahBSm
	uLPSmDAO1tZRXF9j+/9mjnb4GP3CvG6/g98YWUNKtXBUF7Vh/Se01+hTyzR391dAfnwv
	xKmAy2ZvKdAyXShghh/K1KeVreLChLKDMTh4IVW70qv4i9QjKhsuQpfikAjmdugFjBsK
	FtUiVoniEk8I3cKcJ+C+5XyvvUDuyn+aZ57QTTN+HtuRG8ShpaCGpuAHd5c/EDb3QXpT
	tXbw==
X-Gm-Message-State: ALoCoQnFJwcpVQqe4jNL6jrwud3L49fgqjWBnHWW5JS53n+Zgj07a8iVCTnDDYsaVqGGFfjThQMT
X-Received: by 10.194.48.109 with SMTP id k13mr25553767wjn.7.1417793161702;
	Fri, 05 Dec 2014 07:26:01 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	bs2sm28123844wjc.43.2014.12.05.07.26.00 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 07:26:00 -0800 (PST)
Message-ID: <5481CE85.8010502@linaro.org>
Date: Fri, 05 Dec 2014 15:25:57 +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@eu.citrix.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>	
	<1417789634.22808.66.camel@eu.citrix.com>
	<5481C30B.3020901@linaro.org>
	<1417790527.22808.67.camel@eu.citrix.com>
In-Reply-To: <1417790527.22808.67.camel@eu.citrix.com>
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 14:42, Ian Campbell wrote:
> On Fri, 2014-12-05 at 14:36 +0000, Julien Grall wrote:
>> Hi,
>>
>> On 05/12/14 14:27, Ian Campbell wrote:
>>> On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>>>>  #define nr_static_irqs NR_IRQS
>>>> +#define arch_hwdom_irqs(domid) NR_IRQS
>>>
>>> FWIW gic_number_lines() is the ARM equivalent of getting the number of
>>> GSIs.
>>>
>>> *BUT* we don't actually use pirqs on ARM (everything goes via the
>>> virtualised interrupt controller). So maybe we should be setting
>>> nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
>>> from an ARM person, so I'm fine with you making this NR_IRQS in the
>>> meantime.
>>
>> As we already know that PIRQ is not used on ARM, it would make sense to
>> use directly in this patch 0.
> 
> Are you offering to give a tested-by if Jan posts such a patch?

nr_pirqs is used in 2 different place (without counting this setting):
	- event channel => We don't care on ARM as alloc_pirq_struct is
returning NULL
	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
AFAIU the pirq number is different on each domain. But we use it to
check permission on both domain. Shouldn't we translate the pirq to irq
for the current->domain?

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 Dec 05 15:35:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1XwuuP-000236-UK; Fri, 05 Dec 2014 15:35:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XwuuO-00022x-QG
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:35:04 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	66/27-22777-8A0D1845; Fri, 05 Dec 2014 15:35:04 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417793702!11813371!1
X-Originating-IP: [66.165.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 1090 invoked from network); 5 Dec 2014 15:35:03 -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 Dec 2014 15:35:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200765277"
Received: from ukmail1.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, 5 Dec 2014 10:35:01 -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 1XwuuL-0000Xd-1c;
	Fri, 05 Dec 2014 15:35:01 +0000
Date: Fri, 5 Dec 2014 15:35:01 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141205153500.GP1617@perard.uk.xensource.com>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417781152-9926-2-git-send-email-olaf@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
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 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 01:05:48PM +0100, Olaf Hering wrote:
> On a non-SELinux system the mount option "context=none" works fine.

That's not true. I've tested 'context=none' on ArchLinux which have no
support (or limited) for selinux, and the option give this error:
"tmpfs: Bad mount option context"

-- 
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 Dec 05 15:35:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1Xwuu6-00020h-Hm; Fri, 05 Dec 2014 15:34:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xwuu4-00020G-Kz
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 15:34:44 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	05/4C-26740-390D1845; Fri, 05 Dec 2014 15:34:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417793680!11335422!1
X-Originating-IP: [66.165.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 9553 invoked from network); 5 Dec 2014 15:34:41 -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;
	5 Dec 2014 15:34:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200394205"
Received: from ukmail1.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, 5 Dec 2014 10:34:39 -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 1Xwupw-0000Qe-GL;
	Fri, 05 Dec 2014 15:30:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xwupw-0007Vh-8h;
	Fri, 05 Dec 2014 15:30:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.53139.932159.520748@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 15:30:27 +0000
To: xen.org <Ian.Jackson@eu.citrix.com>
In-Reply-To: <osstest-31991-mainreport@xen.org>,
	<osstest-32089-mainreport@xen.org>
References: <osstest-32089-mainreport@xen.org>
	<osstest-31991-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.4-testing test] 31991: regressions - FAIL
	[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

xen.org writes ("[xen-4.4-testing test] 31991: regressions - FAIL"):
> flight 31991 xen-4.4-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31991/
> 
> 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

This is the swiotlb problem which is not a recent regression in Xen
4.3, but probably a gradually-regressing kernel problem.

> version targeted for testing:
>  xen                  a39f202031d7f1d8d9e14b8c3d7d11c812db253e

xen.org writes ("[xen-4.3-testing test] 32089: regressions - FAIL"):
> flight 32089 xen-4.3-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32089/
> 
> 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

Likewise.

> version targeted for testing:
>  xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a

In both of these cases, that was the only reason osstest didn't do a
push.  Following discussion with Jan on IRC, I am going to do a manual
force push of both trees.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:35:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1XwuuP-000236-UK; Fri, 05 Dec 2014 15:35:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XwuuO-00022x-QG
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:35:04 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	66/27-22777-8A0D1845; Fri, 05 Dec 2014 15:35:04 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1417793702!11813371!1
X-Originating-IP: [66.165.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 1090 invoked from network); 5 Dec 2014 15:35:03 -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 Dec 2014 15:35:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200765277"
Received: from ukmail1.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, 5 Dec 2014 10:35:01 -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 1XwuuL-0000Xd-1c;
	Fri, 05 Dec 2014 15:35:01 +0000
Date: Fri, 5 Dec 2014 15:35:01 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141205153500.GP1617@perard.uk.xensource.com>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417781152-9926-2-git-send-email-olaf@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
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 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 01:05:48PM +0100, Olaf Hering wrote:
> On a non-SELinux system the mount option "context=none" works fine.

That's not true. I've tested 'context=none' on ArchLinux which have no
support (or limited) for selinux, and the option give this error:
"tmpfs: Bad mount option context"

-- 
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 Dec 05 15:35:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1Xwuu6-00020h-Hm; Fri, 05 Dec 2014 15:34:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xwuu4-00020G-Kz
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 15:34:44 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	05/4C-26740-390D1845; Fri, 05 Dec 2014 15:34:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417793680!11335422!1
X-Originating-IP: [66.165.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 9553 invoked from network); 5 Dec 2014 15:34:41 -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;
	5 Dec 2014 15:34:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200394205"
Received: from ukmail1.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, 5 Dec 2014 10:34:39 -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 1Xwupw-0000Qe-GL;
	Fri, 05 Dec 2014 15:30:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xwupw-0007Vh-8h;
	Fri, 05 Dec 2014 15:30:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21633.53139.932159.520748@mariner.uk.xensource.com>
Date: Fri, 5 Dec 2014 15:30:27 +0000
To: xen.org <Ian.Jackson@eu.citrix.com>
In-Reply-To: <osstest-31991-mainreport@xen.org>,
	<osstest-32089-mainreport@xen.org>
References: <osstest-32089-mainreport@xen.org>
	<osstest-31991-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.4-testing test] 31991: regressions - FAIL
	[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

xen.org writes ("[xen-4.4-testing test] 31991: regressions - FAIL"):
> flight 31991 xen-4.4-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/31991/
> 
> 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

This is the swiotlb problem which is not a recent regression in Xen
4.3, but probably a gradually-regressing kernel problem.

> version targeted for testing:
>  xen                  a39f202031d7f1d8d9e14b8c3d7d11c812db253e

xen.org writes ("[xen-4.3-testing test] 32089: regressions - FAIL"):
> flight 32089 xen-4.3-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32089/
> 
> 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

Likewise.

> version targeted for testing:
>  xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a

In both of these cases, that was the only reason osstest didn't do a
push.  Following discussion with Jan on IRC, I am going to do a manual
force push of both trees.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:37:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:37:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuwT-0002PF-FC; Fri, 05 Dec 2014 15:37: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 1XwuwS-0002PA-1Q
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 15:37:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9F/9B-25276-721D1845; Fri, 05 Dec 2014 15:37:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417793829!13748071!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26732 invoked from network); 5 Dec 2014 15:37:10 -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; 5 Dec 2014 15:37:10 -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 sB5Fb5FC008936
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 15:37:06 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
	sB5Fb51U000526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 15:37:05 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
	sB5Fb5g5024760; Fri, 5 Dec 2014 15:37:05 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 07:37:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E5B2211F8C4; Fri,  5 Dec 2014 10:37:03 -0500 (EST)
Date: Fri, 5 Dec 2014 10:37:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "xen.org" <Ian.Jackson@eu.citrix.com>
Message-ID: <20141205153703.GA32494@laptop.dumpdata.com>
References: <osstest-32051-mainreport@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <osstest-32051-mainreport@xen.org>
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
Subject: Re: [Xen-devel] [xen-unstable test] 32051: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 10:12:18AM +0000, xen.org wrote:
> flight 32051 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32051/
> 
> Regressions :-(

There does not seem to be anything warranting that.

The failure is that this:


07 Z executing ssh ... osstest@10.80.250.27 cd /home/osstest/build.32051.build-amd64-pvops/linux && git rev-parse HEAD^0
2014-12-03 13:15:37 Z command timed out [30]: ssh -o StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100 -o PasswordAuthentication=no -o ChallengeResponseAuthentication=no -o UserKnownHostsFile=tmp/t.known_hosts_32051.build-amd64-pvops osstest@10.80.250.27 cd /home/osstest/build.32051.build-amd64-pvops/linux && git rev-parse HEAD^0
status (timed out) at Osstest/TestSupport.pm line 392.

Which taking more than 30 seconds is quite odd. But perhaps
it triggered git compression?

Oh wait, the ConnectionTimeout is 100 seconds but this failed in 30 seconds?

And the http://www.chiark.greenend.org.uk/~xensrcts/logs/32051/build-amd64-pvops/6.ts-logs-capture.log
was able to capture data - so the host did not crash.

?

> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-pvops             5 kernel-build              fail REGR. vs. 31986
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-i386-pair  18 guest-migrate/dst_host/src_host fail blocked in 31986
> 
> Tests which did not succeed, but are not blocking:
>  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-xl-pcipt-intel  1 build-check(1)               blocked  n/a
>  test-amd64-amd64-xl-sedf-pin  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-armhf-armhf-xl          10 migrate-support-check        fail   never pass
>  test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
>  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  1 build-check(1)             blocked n/a
>  test-amd64-amd64-xl-win7-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-pair         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-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-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
>  test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
>  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  1 build-check(1)               blocked  n/a
>  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  1 build-check(1)               blocked n/a
> 
> version targeted for testing:
>  xen                  4d1a77ba7ab94183c203226d3fe7ac1cd087c59b
> baseline version:
>  xen                  188336bb86d0992a2a034ece5f39eccc5d10f337
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Chunyan Liu <cyliu@suse.com>
>   Euan Harris <euan.harris@citrix.com>
>   Ian Campbell <ian.campbell@citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   M A Young <m.a.young@durham.ac.uk>
>   Michael Young <m.a.young@durham.ac.uk>
>   Razvan Cojocaru <rcojocaru@bitdefender.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                                            fail    
>  build-armhf-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  build-amd64-rumpuserxen                                      pass    
>  build-i386-rumpuserxen                                       pass    
>  test-amd64-amd64-xl                                          blocked 
>  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                    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-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-freebsd10-i386                               pass    
>  test-amd64-i386-rumpuserxen-i386                             pass    
>  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-armhf-armhf-libvirt                                     fail    
>  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.
> 
> ------------------------------------------------------------
> commit 4d1a77ba7ab94183c203226d3fe7ac1cd087c59b
> Author: Wei Liu <wei.liu2@citrix.com>
> Date:   Mon Dec 1 11:31:13 2014 +0000
> 
>     xl: fix two memory leaks
>     
>     Free strings returned by libxl_basename after used.
>     
>     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>
>     [ ijc -- s/basename/kernel_basename in parse_config_data to avoid
>              shadowing basename(3). ]
> 
> commit 276ba7806259c10b186c9cd9115078fb35b28bc7
> Author: Euan Harris <euan.harris@citrix.com>
> Date:   Mon Dec 1 14:27:06 2014 +0000
> 
>     libxl: Don't dereference null new_name pointer in libxl_domain_rename()
>     
>     libxl__domain_rename() unconditionally dereferences its new_name
>     parameter, to check whether it is an empty string.   Add a check to
>     avoid a segfault if new_name is null.
>     
>     Signed-off-by: Euan Harris <euan.harris@citrix.com>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> commit e3abab74598d96de87e3cbcaf1d567ac854e53cf
> Author: Wei Liu <wei.liu2@citrix.com>
> Date:   Mon Dec 1 11:31:12 2014 +0000
> 
>     libxl: un-constify return value of libxl_basename
>     
>     The string returned is malloc'ed but marked as "const".
>     
>     Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>     Cc: Ian Campbell <ian.campbell@citrix.com>
>     Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> commit e609bb983ea6e0a5a4d791cffccad0ce3712e12f
> Author: Chunyan Liu <cyliu@suse.com>
> Date:   Fri Nov 28 13:55:22 2014 +0800
> 
>     missing chunk of HVM direct kernel boot patch
>     
>     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>
>     Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> commit 13dc6bf0430eedc3422d81b87764c31e59a73b1f
> Author: Razvan Cojocaru <rcojocaru@bitdefender.com>
> Date:   Fri Nov 28 14:26:48 2014 +0200
> 
>     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.
>     
>     Suggested-by: Ian Campbell <Ian.Campbell@citrix.com>
>     Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>     Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> commit d36a3734a6abccd36a8050e19633af1671a2083d
> Author: M A Young <m.a.young@durham.ac.uk>
> Date:   Tue Dec 2 13:48:54 2014 +0000
> 
>     xl: fix migration failure with xl migrate --debug
>     
>     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>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> commit 1fed4af8d870e6fe4c4e2eceafaf8afba49fc169
> Author: Euan Harris <euan.harris@citrix.com>
> Date:   Mon Dec 1 10:47:33 2014 +0000
> 
>     libxl: libxl_domain_info: fix typo in error message
>     
>     Signed-off-by: Euan Harris <euan.harris@citrix.com>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> commit 04ae2f6837b35bcfb689baf15f493da626929fb5
> Author: Jan Beulich <jbeulich@suse.com>
> Date:   Tue Dec 2 12:48:01 2014 +0100
> 
>     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>
>     Signed-off-by: Tim Deegan <tim@xen.org>
>     Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> (qemu changes not included)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:37:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:37:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwuwT-0002PF-FC; Fri, 05 Dec 2014 15:37: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 1XwuwS-0002PA-1Q
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 15:37:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9F/9B-25276-721D1845; Fri, 05 Dec 2014 15:37:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417793829!13748071!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26732 invoked from network); 5 Dec 2014 15:37:10 -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; 5 Dec 2014 15:37:10 -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 sB5Fb5FC008936
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 15:37:06 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
	sB5Fb51U000526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 15:37:05 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
	sB5Fb5g5024760; Fri, 5 Dec 2014 15:37:05 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 07:37:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E5B2211F8C4; Fri,  5 Dec 2014 10:37:03 -0500 (EST)
Date: Fri, 5 Dec 2014 10:37:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "xen.org" <Ian.Jackson@eu.citrix.com>
Message-ID: <20141205153703.GA32494@laptop.dumpdata.com>
References: <osstest-32051-mainreport@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <osstest-32051-mainreport@xen.org>
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
Subject: Re: [Xen-devel] [xen-unstable test] 32051: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 04, 2014 at 10:12:18AM +0000, xen.org wrote:
> flight 32051 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32051/
> 
> Regressions :-(

There does not seem to be anything warranting that.

The failure is that this:


07 Z executing ssh ... osstest@10.80.250.27 cd /home/osstest/build.32051.build-amd64-pvops/linux && git rev-parse HEAD^0
2014-12-03 13:15:37 Z command timed out [30]: ssh -o StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100 -o PasswordAuthentication=no -o ChallengeResponseAuthentication=no -o UserKnownHostsFile=tmp/t.known_hosts_32051.build-amd64-pvops osstest@10.80.250.27 cd /home/osstest/build.32051.build-amd64-pvops/linux && git rev-parse HEAD^0
status (timed out) at Osstest/TestSupport.pm line 392.

Which taking more than 30 seconds is quite odd. But perhaps
it triggered git compression?

Oh wait, the ConnectionTimeout is 100 seconds but this failed in 30 seconds?

And the http://www.chiark.greenend.org.uk/~xensrcts/logs/32051/build-amd64-pvops/6.ts-logs-capture.log
was able to capture data - so the host did not crash.

?

> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-pvops             5 kernel-build              fail REGR. vs. 31986
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-i386-pair  18 guest-migrate/dst_host/src_host fail blocked in 31986
> 
> Tests which did not succeed, but are not blocking:
>  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-xl-pcipt-intel  1 build-check(1)               blocked  n/a
>  test-amd64-amd64-xl-sedf-pin  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-armhf-armhf-xl          10 migrate-support-check        fail   never pass
>  test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
>  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  1 build-check(1)             blocked n/a
>  test-amd64-amd64-xl-win7-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-pair         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-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-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
>  test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
>  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  1 build-check(1)               blocked  n/a
>  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  1 build-check(1)               blocked n/a
> 
> version targeted for testing:
>  xen                  4d1a77ba7ab94183c203226d3fe7ac1cd087c59b
> baseline version:
>  xen                  188336bb86d0992a2a034ece5f39eccc5d10f337
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Chunyan Liu <cyliu@suse.com>
>   Euan Harris <euan.harris@citrix.com>
>   Ian Campbell <ian.campbell@citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   M A Young <m.a.young@durham.ac.uk>
>   Michael Young <m.a.young@durham.ac.uk>
>   Razvan Cojocaru <rcojocaru@bitdefender.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                                            fail    
>  build-armhf-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  build-amd64-rumpuserxen                                      pass    
>  build-i386-rumpuserxen                                       pass    
>  test-amd64-amd64-xl                                          blocked 
>  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                    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-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-freebsd10-i386                               pass    
>  test-amd64-i386-rumpuserxen-i386                             pass    
>  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-armhf-armhf-libvirt                                     fail    
>  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.
> 
> ------------------------------------------------------------
> commit 4d1a77ba7ab94183c203226d3fe7ac1cd087c59b
> Author: Wei Liu <wei.liu2@citrix.com>
> Date:   Mon Dec 1 11:31:13 2014 +0000
> 
>     xl: fix two memory leaks
>     
>     Free strings returned by libxl_basename after used.
>     
>     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>
>     [ ijc -- s/basename/kernel_basename in parse_config_data to avoid
>              shadowing basename(3). ]
> 
> commit 276ba7806259c10b186c9cd9115078fb35b28bc7
> Author: Euan Harris <euan.harris@citrix.com>
> Date:   Mon Dec 1 14:27:06 2014 +0000
> 
>     libxl: Don't dereference null new_name pointer in libxl_domain_rename()
>     
>     libxl__domain_rename() unconditionally dereferences its new_name
>     parameter, to check whether it is an empty string.   Add a check to
>     avoid a segfault if new_name is null.
>     
>     Signed-off-by: Euan Harris <euan.harris@citrix.com>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> commit e3abab74598d96de87e3cbcaf1d567ac854e53cf
> Author: Wei Liu <wei.liu2@citrix.com>
> Date:   Mon Dec 1 11:31:12 2014 +0000
> 
>     libxl: un-constify return value of libxl_basename
>     
>     The string returned is malloc'ed but marked as "const".
>     
>     Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>     Cc: Ian Campbell <ian.campbell@citrix.com>
>     Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> commit e609bb983ea6e0a5a4d791cffccad0ce3712e12f
> Author: Chunyan Liu <cyliu@suse.com>
> Date:   Fri Nov 28 13:55:22 2014 +0800
> 
>     missing chunk of HVM direct kernel boot patch
>     
>     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>
>     Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> commit 13dc6bf0430eedc3422d81b87764c31e59a73b1f
> Author: Razvan Cojocaru <rcojocaru@bitdefender.com>
> Date:   Fri Nov 28 14:26:48 2014 +0200
> 
>     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.
>     
>     Suggested-by: Ian Campbell <Ian.Campbell@citrix.com>
>     Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>     Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> commit d36a3734a6abccd36a8050e19633af1671a2083d
> Author: M A Young <m.a.young@durham.ac.uk>
> Date:   Tue Dec 2 13:48:54 2014 +0000
> 
>     xl: fix migration failure with xl migrate --debug
>     
>     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>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> commit 1fed4af8d870e6fe4c4e2eceafaf8afba49fc169
> Author: Euan Harris <euan.harris@citrix.com>
> Date:   Mon Dec 1 10:47:33 2014 +0000
> 
>     libxl: libxl_domain_info: fix typo in error message
>     
>     Signed-off-by: Euan Harris <euan.harris@citrix.com>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> commit 04ae2f6837b35bcfb689baf15f493da626929fb5
> Author: Jan Beulich <jbeulich@suse.com>
> Date:   Tue Dec 2 12:48:01 2014 +0100
> 
>     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>
>     Signed-off-by: Tim Deegan <tim@xen.org>
>     Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> (qemu changes not included)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:42:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1Xwv1H-0002ny-6I; Fri, 05 Dec 2014 15:42: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 1Xwv1F-0002mv-Og
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:42:09 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	F0/B6-22819-152D1845; Fri, 05 Dec 2014 15:42:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417794128!4229798!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26305 invoked from network); 5 Dec 2014 15:42:08 -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; 5 Dec 2014 15:42:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:42:07 +0000
Message-Id: <5481E05F020000780004D430@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:42:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com> <5481C30B.3020901@linaro.org>
	<1417790527.22808.67.camel@eu.citrix.com> <5481CE85.8010502@linaro.org>
In-Reply-To: <5481CE85.8010502@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 16:25, <julien.grall@linaro.org> wrote:
> 	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
> AFAIU the pirq number is different on each domain. But we use it to
> check permission on both domain. Shouldn't we translate the pirq to irq
> for the current->domain?

Indeed, see also
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00219.html

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:42:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1Xwv1H-0002ny-6I; Fri, 05 Dec 2014 15:42: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 1Xwv1F-0002mv-Og
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:42:09 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	F0/B6-22819-152D1845; Fri, 05 Dec 2014 15:42:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417794128!4229798!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26305 invoked from network); 5 Dec 2014 15:42:08 -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; 5 Dec 2014 15:42:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:42:07 +0000
Message-Id: <5481E05F020000780004D430@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:42:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com> <5481C30B.3020901@linaro.org>
	<1417790527.22808.67.camel@eu.citrix.com> <5481CE85.8010502@linaro.org>
In-Reply-To: <5481CE85.8010502@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 16:25, <julien.grall@linaro.org> wrote:
> 	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
> AFAIU the pirq number is different on each domain. But we use it to
> check permission on both domain. Shouldn't we translate the pirq to irq
> for the current->domain?

Indeed, see also
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00219.html

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:47:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwv60-0002z3-To; Fri, 05 Dec 2014 15:47:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xwv60-0002yy-Bs
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:47:04 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	39/E9-02953-773D1845; Fri, 05 Dec 2014 15:47:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417794420!13275730!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 12454 invoked from network); 5 Dec 2014 15:47:03 -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 Dec 2014 15:47:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200400389"
Message-ID: <1417794376.22808.72.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 5 Dec 2014 15:46:16 +0000
In-Reply-To: <1417791304-26836-1-git-send-email-ian.campbell@citrix.com>
References: <1417772967.22808.46.camel@citrix.com>
	<1417791304-26836-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: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST] ts-xen-build-prep: Install
 libxml-xpath-perl on build machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-05 at 14:55 +0000, Ian Campbell wrote:
> Required by latest libvirt, to build docs.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Ian acked this on IRC and I have pushed it along with some other bits
and bobs floating around already acked. Specifically I have pushed to
pretest:
        0d8405e Add simple helper to update DI for all architectures.
        e7ed319 ts-kernel-build: enable CONFIG_IKCONFIG{_PROC}
        6184712 standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG
        a70253f ts-xen-build-prep: Install libxml-xpath-perl on build machines
        60670dd linux-next tests: Use correct branch for baseline



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:47:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwv60-0002z3-To; Fri, 05 Dec 2014 15:47:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xwv60-0002yy-Bs
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:47:04 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	39/E9-02953-773D1845; Fri, 05 Dec 2014 15:47:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417794420!13275730!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 12454 invoked from network); 5 Dec 2014 15:47:03 -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 Dec 2014 15:47:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200400389"
Message-ID: <1417794376.22808.72.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Fri, 5 Dec 2014 15:46:16 +0000
In-Reply-To: <1417791304-26836-1-git-send-email-ian.campbell@citrix.com>
References: <1417772967.22808.46.camel@citrix.com>
	<1417791304-26836-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: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST] ts-xen-build-prep: Install
 libxml-xpath-perl on build machines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-05 at 14:55 +0000, Ian Campbell wrote:
> Required by latest libvirt, to build docs.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Ian acked this on IRC and I have pushed it along with some other bits
and bobs floating around already acked. Specifically I have pushed to
pretest:
        0d8405e Add simple helper to update DI for all architectures.
        e7ed319 ts-kernel-build: enable CONFIG_IKCONFIG{_PROC}
        6184712 standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG
        a70253f ts-xen-build-prep: Install libxml-xpath-perl on build machines
        60670dd linux-next tests: Use correct branch for baseline



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:51:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:51:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwv9T-00037k-Hi; Fri, 05 Dec 2014 15:50:39 +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 1Xwv9R-00037e-Vx
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:50:38 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	D0/8D-02954-D44D1845; Fri, 05 Dec 2014 15:50:37 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417794635!9960381!1
X-Originating-IP: [156.151.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 25270 invoked from network); 5 Dec 2014 15:50:36 -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; 5 Dec 2014 15:50:36 -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 sB5FoT16012644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 15:50:30 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
	sB5FoSa7007463
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 15:50:29 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
	sB5FoSUg007444; Fri, 5 Dec 2014 15:50:28 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 07:50:28 -0800
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Fri,  5 Dec 2014 16:50:12 +0100
Message-Id: <1417794612-27702-1-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.7.10.4
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>, jbeulich@suse.com
Subject: [Xen-devel] [PATCH v2] console: increase initial conring 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>
MIME-Version: 1.0
Content-Type: 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 general initial conring size is sufficient. However, if log
level is increased on platforms which have e.g. huge number
of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
which has more than 200 entries in EFI memory map) then some
of earlier messages in console ring are overwritten. It means
that in case of issues deeper analysis can be hindered. Sadly
conring_size argument does not help because new console buffer
is allocated late on heap. It means that it is not possible to
allocate larger ring earlier. So, in this situation initial
conring size should be increased. My experiments showed that
even on not so big machines more than 26 KiB of free space are
needed for initial messages. In theory we could increase conring
size buffer to 32 KiB. However, I think that this value could be
too small for huge machines with large number of ACPI tables and
EFI memory regions. Hence, this patch increases initial conring
size to 64 KiB.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
This bug (or lack of feature if you prefer) should be fixed, as it
was pointed out by Jan Beulich and Olaf Hering, by allocating conring
earlier. I though about that before posting this patch (I did not
know beforehand about Olaf's work made in 2011). However, I stated
that it is too late to make so intrusive changes. So, I think we
should (sadly) apply this "band-aid" to 4.5 because, as you can see
in Xen-devel archive, this bug hits more and more people and they fix
this issue in the same way as I did in this patch. On the other hand
I agree that we should finally fix this issue in better way.
Hence, I am adding this thing to my TODO list.

v2 - suggestions/fixes:
   - update documentation
     (suggested by Andrew Cooper),
   - add rationale
     (suggested by Jan Beulich).
---
 docs/misc/xen-command-line.markdown |    2 +-
 xen/drivers/char/console.c          |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 0866df2..2ad2340 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -286,7 +286,7 @@ A typical setup for most situations might be `com1=115200,8n1`
 ### conring\_size
 > `= <size>`
 
-> Default: `conring_size=16k`
+> Default: `conring_size=64k`
 
 Specify the size of the console ring buffer.
 
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 2f03259..429d296 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -67,7 +67,7 @@ custom_param("console_timestamps", parse_console_timestamps);
 static uint32_t __initdata opt_conring_size;
 size_param("conring_size", opt_conring_size);
 
-#define _CONRING_SIZE 16384
+#define _CONRING_SIZE 65536
 #define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
 static char __initdata _conring[_CONRING_SIZE];
 static char *__read_mostly conring = _conring;
-- 
1.7.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 Dec 05 15:51:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:51:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwv9T-00037k-Hi; Fri, 05 Dec 2014 15:50:39 +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 1Xwv9R-00037e-Vx
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 15:50:38 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	D0/8D-02954-D44D1845; Fri, 05 Dec 2014 15:50:37 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417794635!9960381!1
X-Originating-IP: [156.151.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 25270 invoked from network); 5 Dec 2014 15:50:36 -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; 5 Dec 2014 15:50:36 -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 sB5FoT16012644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 15:50:30 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
	sB5FoSa7007463
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 15:50:29 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
	sB5FoSUg007444; Fri, 5 Dec 2014 15:50:28 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 07:50:28 -0800
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Date: Fri,  5 Dec 2014 16:50:12 +0100
Message-Id: <1417794612-27702-1-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.7.10.4
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>, jbeulich@suse.com
Subject: [Xen-devel] [PATCH v2] console: increase initial conring 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>
MIME-Version: 1.0
Content-Type: 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 general initial conring size is sufficient. However, if log
level is increased on platforms which have e.g. huge number
of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
which has more than 200 entries in EFI memory map) then some
of earlier messages in console ring are overwritten. It means
that in case of issues deeper analysis can be hindered. Sadly
conring_size argument does not help because new console buffer
is allocated late on heap. It means that it is not possible to
allocate larger ring earlier. So, in this situation initial
conring size should be increased. My experiments showed that
even on not so big machines more than 26 KiB of free space are
needed for initial messages. In theory we could increase conring
size buffer to 32 KiB. However, I think that this value could be
too small for huge machines with large number of ACPI tables and
EFI memory regions. Hence, this patch increases initial conring
size to 64 KiB.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
This bug (or lack of feature if you prefer) should be fixed, as it
was pointed out by Jan Beulich and Olaf Hering, by allocating conring
earlier. I though about that before posting this patch (I did not
know beforehand about Olaf's work made in 2011). However, I stated
that it is too late to make so intrusive changes. So, I think we
should (sadly) apply this "band-aid" to 4.5 because, as you can see
in Xen-devel archive, this bug hits more and more people and they fix
this issue in the same way as I did in this patch. On the other hand
I agree that we should finally fix this issue in better way.
Hence, I am adding this thing to my TODO list.

v2 - suggestions/fixes:
   - update documentation
     (suggested by Andrew Cooper),
   - add rationale
     (suggested by Jan Beulich).
---
 docs/misc/xen-command-line.markdown |    2 +-
 xen/drivers/char/console.c          |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 0866df2..2ad2340 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -286,7 +286,7 @@ A typical setup for most situations might be `com1=115200,8n1`
 ### conring\_size
 > `= <size>`
 
-> Default: `conring_size=16k`
+> Default: `conring_size=64k`
 
 Specify the size of the console ring buffer.
 
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 2f03259..429d296 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -67,7 +67,7 @@ custom_param("console_timestamps", parse_console_timestamps);
 static uint32_t __initdata opt_conring_size;
 size_param("conring_size", opt_conring_size);
 
-#define _CONRING_SIZE 16384
+#define _CONRING_SIZE 65536
 #define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
 static char __initdata _conring[_CONRING_SIZE];
 static char *__read_mostly conring = _conring;
-- 
1.7.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 Dec 05 15:51:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwvAf-0003Fc-4S; Fri, 05 Dec 2014 15:51:53 +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 1XwvAd-0003FQ-FP
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:51:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D1/92-25276-694D1845; Fri, 05 Dec 2014 15:51:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417794710!13756187!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23622 invoked from network); 5 Dec 2014 15:51:50 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 15:51:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417794710; l=740;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=cvoTQ/eClza2vkvxBK+nExGCb88=;
	b=xTmP1ZGeYsU3mTmb+3z9owzkMSztLHduoHQblQ7GLFmWIVbIbN5udcZJgvlV0dkkN+B
	nAHUDO9pG5TDNCgaMlXdBW0KGhXh6IoEsPlhcrP4aI+19Hw6bfXLP5SbCpWPYXCNmMRul
	ewO7XKt/oZoQRjKT6pmcMarzZabFRG5AR4E=
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.2 AUTH) with ESMTPSA id w07f90qB5FpoTz7
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 16:51:50 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 9A6345015E; Fri,  5 Dec 2014 16:51:49 +0100 (CET)
Date: Fri, 5 Dec 2014 16:51:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20141205155149.GA3065@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<20141205153500.GP1617@perard.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205153500.GP1617@perard.uk.xensource.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
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Anthony PERARD wrote:

> On Fri, Dec 05, 2014 at 01:05:48PM +0100, Olaf Hering wrote:
> > On a non-SELinux system the mount option "context=none" works fine.
> 
> That's not true. I've tested 'context=none' on ArchLinux which have no
> support (or limited) for selinux, and the option give this error:
> "tmpfs: Bad mount option context"

Appears to work for me, at least on SLE12. No idea how much SELinux they
put in there. My old 11.4 behaves the same. Perhaps your kernel lacks
certain functionality? I assome the error msg comes from the kernel.

root@bax:~ # mount -vt tmpfs xxx -o context=foo /mnt/
mount: xxx mounted on /mnt.
root@bax:~ # grep mnt /proc/mounts 
xxx /mnt tmpfs rw,relatime 0 0

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:51:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwvAf-0003Fc-4S; Fri, 05 Dec 2014 15:51:53 +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 1XwvAd-0003FQ-FP
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:51:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D1/92-25276-694D1845; Fri, 05 Dec 2014 15:51:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417794710!13756187!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23622 invoked from network); 5 Dec 2014 15:51:50 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 15:51:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417794710; l=740;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=cvoTQ/eClza2vkvxBK+nExGCb88=;
	b=xTmP1ZGeYsU3mTmb+3z9owzkMSztLHduoHQblQ7GLFmWIVbIbN5udcZJgvlV0dkkN+B
	nAHUDO9pG5TDNCgaMlXdBW0KGhXh6IoEsPlhcrP4aI+19Hw6bfXLP5SbCpWPYXCNmMRul
	ewO7XKt/oZoQRjKT6pmcMarzZabFRG5AR4E=
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.2 AUTH) with ESMTPSA id w07f90qB5FpoTz7
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 16:51:50 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 9A6345015E; Fri,  5 Dec 2014 16:51:49 +0100 (CET)
Date: Fri, 5 Dec 2014 16:51:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20141205155149.GA3065@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<20141205153500.GP1617@perard.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205153500.GP1617@perard.uk.xensource.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
Subject: Re: [Xen-devel] [PATCH 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Anthony PERARD wrote:

> On Fri, Dec 05, 2014 at 01:05:48PM +0100, Olaf Hering wrote:
> > On a non-SELinux system the mount option "context=none" works fine.
> 
> That's not true. I've tested 'context=none' on ArchLinux which have no
> support (or limited) for selinux, and the option give this error:
> "tmpfs: Bad mount option context"

Appears to work for me, at least on SLE12. No idea how much SELinux they
put in there. My old 11.4 behaves the same. Perhaps your kernel lacks
certain functionality? I assome the error msg comes from the kernel.

root@bax:~ # mount -vt tmpfs xxx -o context=foo /mnt/
mount: xxx mounted on /mnt.
root@bax:~ # grep mnt /proc/mounts 
xxx /mnt tmpfs rw,relatime 0 0

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:53:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1XwvCX-0003bx-L1; Fri, 05 Dec 2014 15:53: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 1XwvCW-0003bm-N4
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:53:48 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	D4/82-02699-C05D1845; Fri, 05 Dec 2014 15:53:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417794827!7873891!1
X-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 2660 invoked from network); 5 Dec 2014 15:53:47 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 15:53:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:53:46 +0000
Message-Id: <5481E31B020000780004D44D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:53:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] pci: Do not ignore device's PXM
	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 02.12.14 at 22:34, <boris.ostrovsky@oracle.com> wrote:
> If ACPI provides PXM data for IO devices then dom0 will pass it to
> hypervisor during PHYSDEVOP_pci_device_add call. This information,
> however, is currently ignored.
> 
> We should remember it (in the form of nodeID). We will also print it
> when user requests device information dump.

This on its own seems pretty little reason for changing the code;
considering that subsequent patches will at least convey the
information to the tool stack, maybe that should be mentioned
here as the primary reason for the change?

> @@ -597,13 +598,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          pdev_info.physfn.devfn = manage_pci_ext.physfn.devfn;
>          ret = pci_add_device(0, manage_pci_ext.bus,
>                               manage_pci_ext.devfn,
> -                             &pdev_info);
> +                             &pdev_info, NUMA_NO_NODE);
>          break;
>      }
>  
>      case PHYSDEVOP_pci_device_add: {
>          struct physdev_pci_device_add add;
>          struct pci_dev_info pdev_info;
> +        int node;

Here and everywhere else as applicable: unsigned int unless a
negative value is possible.

> @@ -618,7 +620,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          }
>          else
>              pdev_info.is_virtfn = 0;
> -        ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info);
> +
> +        if ( add.flags & XEN_PCI_DEV_PXM ) {

Coding style.

> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -568,7 +568,8 @@ static void pci_enable_acs(struct pci_dev *pdev)
>      pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl);
>  }
>  
> -int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
> +int pci_add_device(u16 seg, u8 bus, u8 devfn,
> +                   const struct pci_dev_info *info, const int node)

I don't see the need for the const.

> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -56,6 +56,8 @@ struct pci_dev {
>  
>      u8 phantom_stride;
>  
> +    int node; /* NUMA node */

I don't think we currently support node IDs wider than 8 bits.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:53:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1XwvCX-0003bx-L1; Fri, 05 Dec 2014 15:53: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 1XwvCW-0003bm-N4
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:53:48 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	D4/82-02699-C05D1845; Fri, 05 Dec 2014 15:53:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417794827!7873891!1
X-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 2660 invoked from network); 5 Dec 2014 15:53:47 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 15:53:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:53:46 +0000
Message-Id: <5481E31B020000780004D44D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:53:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] pci: Do not ignore device's PXM
	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 02.12.14 at 22:34, <boris.ostrovsky@oracle.com> wrote:
> If ACPI provides PXM data for IO devices then dom0 will pass it to
> hypervisor during PHYSDEVOP_pci_device_add call. This information,
> however, is currently ignored.
> 
> We should remember it (in the form of nodeID). We will also print it
> when user requests device information dump.

This on its own seems pretty little reason for changing the code;
considering that subsequent patches will at least convey the
information to the tool stack, maybe that should be mentioned
here as the primary reason for the change?

> @@ -597,13 +598,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          pdev_info.physfn.devfn = manage_pci_ext.physfn.devfn;
>          ret = pci_add_device(0, manage_pci_ext.bus,
>                               manage_pci_ext.devfn,
> -                             &pdev_info);
> +                             &pdev_info, NUMA_NO_NODE);
>          break;
>      }
>  
>      case PHYSDEVOP_pci_device_add: {
>          struct physdev_pci_device_add add;
>          struct pci_dev_info pdev_info;
> +        int node;

Here and everywhere else as applicable: unsigned int unless a
negative value is possible.

> @@ -618,7 +620,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          }
>          else
>              pdev_info.is_virtfn = 0;
> -        ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info);
> +
> +        if ( add.flags & XEN_PCI_DEV_PXM ) {

Coding style.

> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -568,7 +568,8 @@ static void pci_enable_acs(struct pci_dev *pdev)
>      pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl);
>  }
>  
> -int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
> +int pci_add_device(u16 seg, u8 bus, u8 devfn,
> +                   const struct pci_dev_info *info, const int node)

I don't see the need for the const.

> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -56,6 +56,8 @@ struct pci_dev {
>  
>      u8 phantom_stride;
>  
> +    int node; /* NUMA node */

I don't think we currently support node IDs wider than 8 bits.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:56:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:56:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwvEb-0003lQ-5N; Fri, 05 Dec 2014 15:55:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwvEa-0003lI-Fi
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:55:56 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	4E/85-17735-B85D1845; Fri, 05 Dec 2014 15:55:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417794955!11362578!1
X-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 5393 invoked from network); 5 Dec 2014 15: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; 5 Dec 2014 15:55:55 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:55:54 +0000
Message-Id: <5481E39B020000780004D450@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:55:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 02.12.14 at 22:34, <boris.ostrovsky@oracle.com> wrote:
> +struct xen_sysctl_iotopo {
> +    uint16_t seg;
> +    uint8_t bus;
> +    uint8_t devfn;
> +    uint32_t node;
> +};

This is PCI-centric without expressing in the name or layout. Perhaps
the first part should be a union from the very beginning?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:56:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15:56:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwvEb-0003lQ-5N; Fri, 05 Dec 2014 15:55:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwvEa-0003lI-Fi
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:55:56 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	4E/85-17735-B85D1845; Fri, 05 Dec 2014 15:55:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1417794955!11362578!1
X-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 5393 invoked from network); 5 Dec 2014 15: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; 5 Dec 2014 15:55:55 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:55:54 +0000
Message-Id: <5481E39B020000780004D450@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:55:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 02.12.14 at 22:34, <boris.ostrovsky@oracle.com> wrote:
> +struct xen_sysctl_iotopo {
> +    uint16_t seg;
> +    uint8_t bus;
> +    uint8_t devfn;
> +    uint32_t node;
> +};

This is PCI-centric without expressing in the name or layout. Perhaps
the first part should be a union from the very beginning?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:59:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1XwvHr-0003vJ-Oq; Fri, 05 Dec 2014 15:59:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwvHq-0003vC-He
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:59:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	54/C5-09842-556D1845; Fri, 05 Dec 2014 15:59:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417795157!13737243!1
X-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 3733 invoked from network); 5 Dec 2014 15:59:17 -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; 5 Dec 2014 15:59:17 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:59:16 +0000
Message-Id: <5481E465020000780004D46D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:59:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-4-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1417556050-23364-4-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 3/4] sysctl/libxl: Provide information about
 IO topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.12.14 at 22:34, <boris.ostrovsky@oracle.com> wrote:
> @@ -362,6 +363,35 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
>                                          u.topologyinfo.max_cpu_index) )
>                  ret = -EFAULT;
>          }
> +
> +        if ( !ret && !guest_handle_is_null(ti->iotopo) )
> +        {
> +            for ( i = 0; i < ti->max_devs; i++ )

Careful about long running loops here please.

Jan

> +            {
> +                xen_sysctl_iotopo_t iotopo;
> +                struct pci_dev *pdev;
> +
> +                if ( copy_from_guest_offset(&iotopo, ti->iotopo, i, 1) )
> +                {
> +                    ret = -EFAULT;
> +                    break;
> +                }
> +
> +                spin_lock(&pcidevs_lock);
> +                pdev = pci_get_pdev(iotopo.seg, iotopo.bus, iotopo.devfn);
> +                if ( !pdev || (pdev->node == NUMA_NO_NODE) )
> +                    iotopo.node = INVALID_TOPOLOGY_ID;
> +                else
> +                    iotopo.node = pdev->node;
> +                spin_unlock(&pcidevs_lock);
> +
> +                if ( copy_to_guest_offset(ti->iotopo, i, &iotopo, 1) )
> +                {
> +                    ret = -EFAULT;
> +                    break;
> +                }
> +            }
> +        }
>      }
>      break;
>  
> -- 
> 1.8.4.2




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 15:59:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 15: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 1XwvHr-0003vJ-Oq; Fri, 05 Dec 2014 15:59:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwvHq-0003vC-He
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 15:59:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	54/C5-09842-556D1845; Fri, 05 Dec 2014 15:59:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417795157!13737243!1
X-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 3733 invoked from network); 5 Dec 2014 15:59:17 -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; 5 Dec 2014 15:59:17 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 15:59:16 +0000
Message-Id: <5481E465020000780004D46D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 15:59:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-4-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1417556050-23364-4-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 3/4] sysctl/libxl: Provide information about
 IO topology
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.12.14 at 22:34, <boris.ostrovsky@oracle.com> wrote:
> @@ -362,6 +363,35 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
>                                          u.topologyinfo.max_cpu_index) )
>                  ret = -EFAULT;
>          }
> +
> +        if ( !ret && !guest_handle_is_null(ti->iotopo) )
> +        {
> +            for ( i = 0; i < ti->max_devs; i++ )

Careful about long running loops here please.

Jan

> +            {
> +                xen_sysctl_iotopo_t iotopo;
> +                struct pci_dev *pdev;
> +
> +                if ( copy_from_guest_offset(&iotopo, ti->iotopo, i, 1) )
> +                {
> +                    ret = -EFAULT;
> +                    break;
> +                }
> +
> +                spin_lock(&pcidevs_lock);
> +                pdev = pci_get_pdev(iotopo.seg, iotopo.bus, iotopo.devfn);
> +                if ( !pdev || (pdev->node == NUMA_NO_NODE) )
> +                    iotopo.node = INVALID_TOPOLOGY_ID;
> +                else
> +                    iotopo.node = pdev->node;
> +                spin_unlock(&pcidevs_lock);
> +
> +                if ( copy_to_guest_offset(ti->iotopo, i, &iotopo, 1) )
> +                {
> +                    ret = -EFAULT;
> +                    break;
> +                }
> +            }
> +        }
>      }
>      break;
>  
> -- 
> 1.8.4.2




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:03:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:03:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwvLy-0004iO-Ec; Fri, 05 Dec 2014 16:03: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 1XwvLx-0004iJ-1B
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:03:33 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	55/5F-14214-457D1845; Fri, 05 Dec 2014 16:03:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417795411!11809693!1
X-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 28570 invoked from network); 5 Dec 2014 16:03:31 -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; 5 Dec 2014 16:03:31 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 16:03:31 +0000
Message-Id: <5481E564020000780004D47B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 16:03:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<5481E39B020000780004D450@mail.emea.novell.com>
In-Reply-To: <5481E39B020000780004D450@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 05.12.14 at 16:55, <JBeulich@suse.com> wrote:
>>>> On 02.12.14 at 22:34, <boris.ostrovsky@oracle.com> wrote:
>> +struct xen_sysctl_iotopo {
>> +    uint16_t seg;
>> +    uint8_t bus;
>> +    uint8_t devfn;
>> +    uint32_t node;
>> +};
> 
> This is PCI-centric without expressing in the name or layout. Perhaps
> the first part should be a union from the very beginning?

And I wonder whether that supposed union part wouldn't be nicely
done using struct physdev_pci_device.

Additionally please add IN and OUT annotations. When I first saw
this I assumed they would all be OUT (in which case the long running
loop problem mentioned in the reply to one of the other patches
wouldn't have been there), matching their CPU counterpart...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:03:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:03:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwvLy-0004iO-Ec; Fri, 05 Dec 2014 16:03: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 1XwvLx-0004iJ-1B
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:03:33 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	55/5F-14214-457D1845; Fri, 05 Dec 2014 16:03:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417795411!11809693!1
X-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 28570 invoked from network); 5 Dec 2014 16:03:31 -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; 5 Dec 2014 16:03:31 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 16:03:31 +0000
Message-Id: <5481E564020000780004D47B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 16:03:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<5481E39B020000780004D450@mail.emea.novell.com>
In-Reply-To: <5481E39B020000780004D450@mail.emea.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 05.12.14 at 16:55, <JBeulich@suse.com> wrote:
>>>> On 02.12.14 at 22:34, <boris.ostrovsky@oracle.com> wrote:
>> +struct xen_sysctl_iotopo {
>> +    uint16_t seg;
>> +    uint8_t bus;
>> +    uint8_t devfn;
>> +    uint32_t node;
>> +};
> 
> This is PCI-centric without expressing in the name or layout. Perhaps
> the first part should be a union from the very beginning?

And I wonder whether that supposed union part wouldn't be nicely
done using struct physdev_pci_device.

Additionally please add IN and OUT annotations. When I first saw
this I assumed they would all be OUT (in which case the long running
loop problem mentioned in the reply to one of the other patches
wouldn't have been there), matching their CPU counterpart...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:05:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1XwvOE-0004oP-WC; Fri, 05 Dec 2014 16:05:54 +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 1XwvOE-0004oK-1j
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:05:54 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	1F/FF-27584-1E7D1845; Fri, 05 Dec 2014 16:05:53 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417795552!11838373!1
X-Originating-IP: [74.125.82.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8641 invoked from network); 5 Dec 2014 16:05:52 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 16:05:52 -0000
Received: by mail-wg0-f48.google.com with SMTP id y19so1275238wgg.35
	for <xen-devel@lists.xenproject.org>;
	Fri, 05 Dec 2014 08:05: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=wZWfe3qojc6rypj0R/O9PXzz0j5rRluEWbD0wE0kplw=;
	b=hyGt+/vtI7tDQ5bPJh3TwKAJNa60ui8hTBxA3F1gpkjAGPgt42uz/GTlEghlnBGB0j
	w+iuhhbZsq028n2r1tRZOwAGkX3uNEm1lEyJ3DVk+Uh7VAsErMxv2/LN5D6s3rVjgzIT
	lc5BKcQ2LWKv1SWDJ+kOduq57/huuM/YJkD5hlAaSMv+rbFJyKsfhMgkiitUt6s7sHWU
	prvGL0/aN2+yzywz/1w4my2DqfD6hnPtFev17MKFJcMS8+R3LNr755wkLfdyJgk50HPS
	ccJAbydOqQ96sXZVKweS8YOaC+i9wsneblQl163Y/cXmU0u5QlgDgSzZWNHCeTVS86Uo
	JWHw==
X-Gm-Message-State: ALoCoQlZcG+uMevx0L3GUHJ4OHML7hk7HV55G4CoOUPvTi1uotNC35oBmA6WKobFBO2TLDoRpSYJ
X-Received: by 10.194.161.202 with SMTP id xu10mr25724598wjb.4.1417795552622; 
	Fri, 05 Dec 2014 08:05:52 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id e16sm2811367wik.2.2014.12.05.08.05.51
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 08:05:51 -0800 (PST)
Message-ID: <5481D7DB.3040907@linaro.org>
Date: Fri, 05 Dec 2014 16:05:47 +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: Jan Beulich <JBeulich@suse.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
	<5481C30B.3020901@linaro.org>
	<1417790527.22808.67.camel@eu.citrix.com>
	<5481CE85.8010502@linaro.org>
	<5481E05F020000780004D430@mail.emea.novell.com>
In-Reply-To: <5481E05F020000780004D430@mail.emea.novell.com>
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 15:42, Jan Beulich wrote:
>>>> On 05.12.14 at 16:25, <julien.grall@linaro.org> wrote:
>> 	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
>> AFAIU the pirq number is different on each domain. But we use it to
>> check permission on both domain. Shouldn't we translate the pirq to irq
>> for the current->domain?
> 
> Indeed, see also
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00219.html

Do you plan to send a patch to resolve this problem?

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 Dec 05 16:05:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1XwvOE-0004oP-WC; Fri, 05 Dec 2014 16:05:54 +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 1XwvOE-0004oK-1j
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:05:54 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	1F/FF-27584-1E7D1845; Fri, 05 Dec 2014 16:05:53 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1417795552!11838373!1
X-Originating-IP: [74.125.82.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8641 invoked from network); 5 Dec 2014 16:05:52 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 16:05:52 -0000
Received: by mail-wg0-f48.google.com with SMTP id y19so1275238wgg.35
	for <xen-devel@lists.xenproject.org>;
	Fri, 05 Dec 2014 08:05: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=wZWfe3qojc6rypj0R/O9PXzz0j5rRluEWbD0wE0kplw=;
	b=hyGt+/vtI7tDQ5bPJh3TwKAJNa60ui8hTBxA3F1gpkjAGPgt42uz/GTlEghlnBGB0j
	w+iuhhbZsq028n2r1tRZOwAGkX3uNEm1lEyJ3DVk+Uh7VAsErMxv2/LN5D6s3rVjgzIT
	lc5BKcQ2LWKv1SWDJ+kOduq57/huuM/YJkD5hlAaSMv+rbFJyKsfhMgkiitUt6s7sHWU
	prvGL0/aN2+yzywz/1w4my2DqfD6hnPtFev17MKFJcMS8+R3LNr755wkLfdyJgk50HPS
	ccJAbydOqQ96sXZVKweS8YOaC+i9wsneblQl163Y/cXmU0u5QlgDgSzZWNHCeTVS86Uo
	JWHw==
X-Gm-Message-State: ALoCoQlZcG+uMevx0L3GUHJ4OHML7hk7HV55G4CoOUPvTi1uotNC35oBmA6WKobFBO2TLDoRpSYJ
X-Received: by 10.194.161.202 with SMTP id xu10mr25724598wjb.4.1417795552622; 
	Fri, 05 Dec 2014 08:05:52 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id e16sm2811367wik.2.2014.12.05.08.05.51
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 08:05:51 -0800 (PST)
Message-ID: <5481D7DB.3040907@linaro.org>
Date: Fri, 05 Dec 2014 16:05:47 +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: Jan Beulich <JBeulich@suse.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
	<5481C30B.3020901@linaro.org>
	<1417790527.22808.67.camel@eu.citrix.com>
	<5481CE85.8010502@linaro.org>
	<5481E05F020000780004D430@mail.emea.novell.com>
In-Reply-To: <5481E05F020000780004D430@mail.emea.novell.com>
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 15:42, Jan Beulich wrote:
>>>> On 05.12.14 at 16:25, <julien.grall@linaro.org> wrote:
>> 	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
>> AFAIU the pirq number is different on each domain. But we use it to
>> check permission on both domain. Shouldn't we translate the pirq to irq
>> for the current->domain?
> 
> Indeed, see also
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00219.html

Do you plan to send a patch to resolve this problem?

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 Dec 05 16:06:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:06:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwvPD-0004tn-E5; Fri, 05 Dec 2014 16:06:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XwvPB-0004tZ-Rg
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:06:53 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	F5/8F-31453-D18D1845; Fri, 05 Dec 2014 16:06:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417795611!11817685!1
X-Originating-IP: [66.165.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 632 invoked from network); 5 Dec 2014 16:06:52 -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;
	5 Dec 2014 16:06:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200411294"
Received: from ukmail1.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, 5 Dec 2014 11:06:15 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XwvOZ-0001Ff-B8;
	Fri, 05 Dec 2014 16:06:15 +0000
Date: Fri, 5 Dec 2014 16:06:15 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Message-ID: <20141205160615.GA24938@zion.uk.xensource.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415607424-15920-3-git-send-email-cyliu@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Ian.Jackson@citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	Ian.Campbell@citrix.com, 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

I have to admit I'm confused by the back and forth discussion. It's hard
to justify the design of new API without knowing what the constraints
and requirements are from your PoV.

Here are my two cents, not about details, but about general constraints.

There are two layers, one is user of libxl (clients -- xl, libvirt etc)
and libxl (the library itself).

1. it's better to *not* have storage management in libxl.

It's likely that clients can have their own management functionality
already.  I'm told that libvirt has that as well as XAPI. Having this
functionality in libxl is a bit redundant and requires lots of work
(enlighten libxl on what a disk looks like and call out to various
utilities).

2. it's *not* a requirement for xl to have the capability to manage
snapshots.

It's the same arguement that xl has no idea on how to manage snapshots
created by "xl save".  This should ease your concern on having to
duplicate code for libvirt and xl.  IMHO the xl only needs to have the
capability to create a snapshot and create a domain from a snapshot. The
downside is that now xl and libvirt are disconnected, but I think it's
fine. The arguement is that you're not allowed to run two toolstack on
the same host (think about xl and xend in previous releases).

Do these two constraints make your work easier (or harder)?

Regarding JSON API, as Ian said, feel free to hook it up to libxlu.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:06:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:06:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwvPD-0004tn-E5; Fri, 05 Dec 2014 16:06:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XwvPB-0004tZ-Rg
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:06:53 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	F5/8F-31453-D18D1845; Fri, 05 Dec 2014 16:06:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1417795611!11817685!1
X-Originating-IP: [66.165.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 632 invoked from network); 5 Dec 2014 16:06:52 -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;
	5 Dec 2014 16:06:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200411294"
Received: from ukmail1.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, 5 Dec 2014 11:06:15 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XwvOZ-0001Ff-B8;
	Fri, 05 Dec 2014 16:06:15 +0000
Date: Fri, 5 Dec 2014 16:06:15 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Message-ID: <20141205160615.GA24938@zion.uk.xensource.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415607424-15920-3-git-send-email-cyliu@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Ian.Jackson@citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	Ian.Campbell@citrix.com, 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

I have to admit I'm confused by the back and forth discussion. It's hard
to justify the design of new API without knowing what the constraints
and requirements are from your PoV.

Here are my two cents, not about details, but about general constraints.

There are two layers, one is user of libxl (clients -- xl, libvirt etc)
and libxl (the library itself).

1. it's better to *not* have storage management in libxl.

It's likely that clients can have their own management functionality
already.  I'm told that libvirt has that as well as XAPI. Having this
functionality in libxl is a bit redundant and requires lots of work
(enlighten libxl on what a disk looks like and call out to various
utilities).

2. it's *not* a requirement for xl to have the capability to manage
snapshots.

It's the same arguement that xl has no idea on how to manage snapshots
created by "xl save".  This should ease your concern on having to
duplicate code for libvirt and xl.  IMHO the xl only needs to have the
capability to create a snapshot and create a domain from a snapshot. The
downside is that now xl and libvirt are disconnected, but I think it's
fine. The arguement is that you're not allowed to run two toolstack on
the same host (think about xl and xend in previous releases).

Do these two constraints make your work easier (or harder)?

Regarding JSON API, as Ian said, feel free to hook it up to libxlu.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:09:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1XwvRa-000552-Vp; Fri, 05 Dec 2014 16:09:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XwvRZ-00054t-Ph
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:09:21 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	03/10-15461-1B8D1845; Fri, 05 Dec 2014 16:09:21 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417795759!13739741!1
X-Originating-IP: [66.165.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 14522 invoked from network); 5 Dec 2014 16:09:20 -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;
	5 Dec 2014 16:09:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200413513"
Received: from ukmail1.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, 5 Dec 2014 11:09:18 -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 1XwvRW-0001I4-FU;
	Fri, 05 Dec 2014 16:09:18 +0000
Date: Fri, 5 Dec 2014 16:09:18 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141205160918.GQ1617@perard.uk.xensource.com>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<20141205153500.GP1617@perard.uk.xensource.com>
	<20141205155149.GA3065@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205155149.GA3065@aepfle.de>
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 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 04:51:49PM +0100, Olaf Hering wrote:
> On Fri, Dec 05, Anthony PERARD wrote:
> 
> > On Fri, Dec 05, 2014 at 01:05:48PM +0100, Olaf Hering wrote:
> > > On a non-SELinux system the mount option "context=none" works fine.
> > 
> > That's not true. I've tested 'context=none' on ArchLinux which have no
> > support (or limited) for selinux, and the option give this error:
> > "tmpfs: Bad mount option context"
> 
> Appears to work for me, at least on SLE12. No idea how much SELinux they
> put in there. My old 11.4 behaves the same. Perhaps your kernel lacks
> certain functionality? I assome the error msg comes from the kernel.

Yes, the message comes from the kernel. I don't know what functionality
is needed to for the kernel to handle context=none, so I can't tell.
At least, there is not CONFIG_SECURITY_SELINUX in the config, but
CONFIG_SECURITY=y is set.

In anyway, I'll continue to edit the systemd unit to remove the context
option, that's not a big deal.

> root@bax:~ # mount -vt tmpfs xxx -o context=foo /mnt/
> mount: xxx mounted on /mnt.

$ sudo mount -vt tmpfs xxx -o context=foo /tmp/tmp.lhw79USQUe 
mount: wrong fs type, bad option, bad superblock on xxx,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
$ dmesg | tail -1
[1569927.987083] tmpfs: Bad mount option context

-- 
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 Dec 05 16:09:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1XwvRa-000552-Vp; Fri, 05 Dec 2014 16:09:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XwvRZ-00054t-Ph
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:09:21 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	03/10-15461-1B8D1845; Fri, 05 Dec 2014 16:09:21 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1417795759!13739741!1
X-Originating-IP: [66.165.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 14522 invoked from network); 5 Dec 2014 16:09:20 -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;
	5 Dec 2014 16:09:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200413513"
Received: from ukmail1.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, 5 Dec 2014 11:09:18 -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 1XwvRW-0001I4-FU;
	Fri, 05 Dec 2014 16:09:18 +0000
Date: Fri, 5 Dec 2014 16:09:18 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141205160918.GQ1617@perard.uk.xensource.com>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-2-git-send-email-olaf@aepfle.de>
	<20141205153500.GP1617@perard.uk.xensource.com>
	<20141205155149.GA3065@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205155149.GA3065@aepfle.de>
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 1/5] tools/hotplug: move XENSTORED_MOUNT_CTX
 to sysconfig.xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 04:51:49PM +0100, Olaf Hering wrote:
> On Fri, Dec 05, Anthony PERARD wrote:
> 
> > On Fri, Dec 05, 2014 at 01:05:48PM +0100, Olaf Hering wrote:
> > > On a non-SELinux system the mount option "context=none" works fine.
> > 
> > That's not true. I've tested 'context=none' on ArchLinux which have no
> > support (or limited) for selinux, and the option give this error:
> > "tmpfs: Bad mount option context"
> 
> Appears to work for me, at least on SLE12. No idea how much SELinux they
> put in there. My old 11.4 behaves the same. Perhaps your kernel lacks
> certain functionality? I assome the error msg comes from the kernel.

Yes, the message comes from the kernel. I don't know what functionality
is needed to for the kernel to handle context=none, so I can't tell.
At least, there is not CONFIG_SECURITY_SELINUX in the config, but
CONFIG_SECURITY=y is set.

In anyway, I'll continue to edit the systemd unit to remove the context
option, that's not a big deal.

> root@bax:~ # mount -vt tmpfs xxx -o context=foo /mnt/
> mount: xxx mounted on /mnt.

$ sudo mount -vt tmpfs xxx -o context=foo /tmp/tmp.lhw79USQUe 
mount: wrong fs type, bad option, bad superblock on xxx,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
$ dmesg | tail -1
[1569927.987083] tmpfs: Bad mount option context

-- 
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 Dec 05 16:12:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:12:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwvUA-0005MD-QO; Fri, 05 Dec 2014 16:12: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 1XwvUA-0005M7-2c
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:12:02 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	7E/2C-11581-159D1845; Fri, 05 Dec 2014 16:12:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417795917!11811457!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 20842 invoked from network); 5 Dec 2014 16:12:00 -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;
	5 Dec 2014 16:12:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200785793"
Message-ID: <1417795908.22808.73.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 5 Dec 2014 16:11:48 +0000
In-Reply-To: <20141205160615.GA24938@zion.uk.xensource.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@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@citrix.com, jfehlig@suse.com, Chunyan Liu <cyliu@suse.com>,
	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 Fri, 2014-12-05 at 16:06 +0000, Wei Liu wrote:
> Regarding JSON API, as Ian said, feel free to hook it up to libxlu.

*If* it is useful to multiple toolstacks but not suitable for libxl then
libxlu would be the right place.

As I understood things the need for JSON here was xl specific, and it is
IMHO fine for xl to also use the idl infrastructure, without needing to
launder it via libxlu.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:12:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:12:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwvUA-0005MD-QO; Fri, 05 Dec 2014 16:12: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 1XwvUA-0005M7-2c
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:12:02 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	7E/2C-11581-159D1845; Fri, 05 Dec 2014 16:12:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417795917!11811457!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 20842 invoked from network); 5 Dec 2014 16:12:00 -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;
	5 Dec 2014 16:12:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200785793"
Message-ID: <1417795908.22808.73.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 5 Dec 2014 16:11:48 +0000
In-Reply-To: <20141205160615.GA24938@zion.uk.xensource.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@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@citrix.com, jfehlig@suse.com, Chunyan Liu <cyliu@suse.com>,
	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 Fri, 2014-12-05 at 16:06 +0000, Wei Liu wrote:
> Regarding JSON API, as Ian said, feel free to hook it up to libxlu.

*If* it is useful to multiple toolstacks but not suitable for libxl then
libxlu would be the right place.

As I understood things the need for JSON here was xl specific, and it is
IMHO fine for xl to also use the idl infrastructure, without needing to
launder it via libxlu.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:12:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1XwvUr-0005ZO-7u; Fri, 05 Dec 2014 16:12: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 1XwvUq-0005XG-5y
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:12:44 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	ED/81-02954-B79D1845; Fri, 05 Dec 2014 16:12:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417795961!8654792!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32039 invoked from network); 5 Dec 2014 16:12:42 -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; 5 Dec 2014 16:12:42 -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 sB5GCPWA025815
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 16:12: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
	sB5GCOF3008902
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 16:12:24 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
	sB5GCO4v008888; Fri, 5 Dec 2014 16:12:24 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 08:12:23 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 867A711F94C; Fri,  5 Dec 2014 11:12:22 -0500 (EST)
Date: Fri, 5 Dec 2014 11:12:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141205161222.GC472@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-18-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-18-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 17/17] xen/vtd: re-enable USB device
 assignment if enable pci_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 05:24:35PM +0800, Tiejun Chen wrote:
> Before we refine RMRR mechanism, USB RMRR may conflict with guest bios
> region so we always ignore USB RMRR. Now this can be gone when we enable
> pci_force to check/reserve RMRR.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/drivers/passthrough/vtd/dmar.h  |  1 +
>  xen/drivers/passthrough/vtd/iommu.c | 12 ++++++++----
>  xen/drivers/passthrough/vtd/utils.c | 18 ++++++++++++++++++
>  3 files changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/dmar.h b/xen/drivers/passthrough/vtd/dmar.h
> index a57c0d4..832dc32 100644
> --- a/xen/drivers/passthrough/vtd/dmar.h
> +++ b/xen/drivers/passthrough/vtd/dmar.h
> @@ -132,6 +132,7 @@ do {                                                \
>  int vtd_hw_check(void);
>  void disable_pmr(struct iommu *iommu);
>  int is_usb_device(u16 seg, u8 bus, u8 devfn);
> +int is_reserve_device_memory(struct domain *d, u8 bus, u8 devfn);
>  int is_igd_drhd(struct acpi_drhd_unit *drhd);
>  
>  #endif /* _DMAR_H_ */
> diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
> index ba40209..1f1ceb7 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2264,9 +2264,11 @@ static int reassign_device_ownership(
>       * remove it from the hardware domain, because BIOS may use RMRR at
>       * booting time. Also account for the special casing of USB below (in
>       * intel_iommu_assign_device()).
> +     * But if we already check to reserve RMRR, this should be fine.
>       */
>      if ( !is_hardware_domain(source) &&
> -         !is_usb_device(pdev->seg, pdev->bus, pdev->devfn) )
> +         !is_usb_device(pdev->seg, pdev->bus, pdev->devfn) &&
> +         !is_reserve_device_memory(source, pdev->bus, pdev->devfn) )
>      {
>          const struct acpi_rmrr_unit *rmrr;
>          u16 bdf;
> @@ -2315,12 +2317,14 @@ static int intel_iommu_assign_device(
>      if ( ret )
>          return ret;
>  
> -    /* FIXME: Because USB RMRR conflicts with guest bios region,
> -     * ignore USB RMRR temporarily.
> +    /*
> +     * Because USB RMRR conflicts with guest bios region,
> +     * ignore USB RMRR temporarily in case of non-reserving-RMRR.
>       */
>      seg = pdev->seg;
>      bus = pdev->bus;
> -    if ( is_usb_device(seg, bus, pdev->devfn) )
> +    if ( is_usb_device(seg, bus, pdev->devfn) &&
> +         !is_reserve_device_memory(d, bus, pdev->devfn) )
>          return 0;
>  
>      /* Setup rmrr identity mapping */
> diff --git a/xen/drivers/passthrough/vtd/utils.c b/xen/drivers/passthrough/vtd/utils.c
> index a33564b..1045ac1 100644
> --- a/xen/drivers/passthrough/vtd/utils.c
> +++ b/xen/drivers/passthrough/vtd/utils.c
> @@ -36,6 +36,24 @@ int is_usb_device(u16 seg, u8 bus, u8 devfn)
>      return (class == 0xc03);
>  }
>  
> +int is_reserve_device_memory(struct domain *d, u8 bus, u8 devfn)
> +{
> +    int i = 0;
> +
> +    if ( d->arch.hvm_domain.pci_force == PCI_DEV_RDM_CHECK )
> +        return 1;

Ouch. What if the 'hvm_domain' is not there? Please check
first for that.
> +
> +    for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
> +    {
> +        if ( d->arch.hvm_domain.pcidevs[i].bus == bus &&
> +             d->arch.hvm_domain.pcidevs[i].devfn == devfn &&
> +             d->arch.hvm_domain.pcidevs[i].flags == PCI_DEV_RDM_CHECK )
> +        return 1;
> +    }
> +
> +    return 0;
> +}
> +
>  /* Disable vt-d protected memory registers. */
>  void disable_pmr(struct iommu *iommu)
>  {
> -- 
> 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 Dec 05 16:12:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1XwvUr-0005ZO-7u; Fri, 05 Dec 2014 16:12: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 1XwvUq-0005XG-5y
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:12:44 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	ED/81-02954-B79D1845; Fri, 05 Dec 2014 16:12:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417795961!8654792!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32039 invoked from network); 5 Dec 2014 16:12:42 -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; 5 Dec 2014 16:12:42 -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 sB5GCPWA025815
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 16:12: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
	sB5GCOF3008902
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 16:12:24 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
	sB5GCO4v008888; Fri, 5 Dec 2014 16:12:24 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 08:12:23 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 867A711F94C; Fri,  5 Dec 2014 11:12:22 -0500 (EST)
Date: Fri, 5 Dec 2014 11:12:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Message-ID: <20141205161222.GC472@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-18-git-send-email-tiejun.chen@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417425875-9634-18-git-send-email-tiejun.chen@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 17/17] xen/vtd: re-enable USB device
 assignment if enable pci_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 01, 2014 at 05:24:35PM +0800, Tiejun Chen wrote:
> Before we refine RMRR mechanism, USB RMRR may conflict with guest bios
> region so we always ignore USB RMRR. Now this can be gone when we enable
> pci_force to check/reserve RMRR.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
>  xen/drivers/passthrough/vtd/dmar.h  |  1 +
>  xen/drivers/passthrough/vtd/iommu.c | 12 ++++++++----
>  xen/drivers/passthrough/vtd/utils.c | 18 ++++++++++++++++++
>  3 files changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/dmar.h b/xen/drivers/passthrough/vtd/dmar.h
> index a57c0d4..832dc32 100644
> --- a/xen/drivers/passthrough/vtd/dmar.h
> +++ b/xen/drivers/passthrough/vtd/dmar.h
> @@ -132,6 +132,7 @@ do {                                                \
>  int vtd_hw_check(void);
>  void disable_pmr(struct iommu *iommu);
>  int is_usb_device(u16 seg, u8 bus, u8 devfn);
> +int is_reserve_device_memory(struct domain *d, u8 bus, u8 devfn);
>  int is_igd_drhd(struct acpi_drhd_unit *drhd);
>  
>  #endif /* _DMAR_H_ */
> diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
> index ba40209..1f1ceb7 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2264,9 +2264,11 @@ static int reassign_device_ownership(
>       * remove it from the hardware domain, because BIOS may use RMRR at
>       * booting time. Also account for the special casing of USB below (in
>       * intel_iommu_assign_device()).
> +     * But if we already check to reserve RMRR, this should be fine.
>       */
>      if ( !is_hardware_domain(source) &&
> -         !is_usb_device(pdev->seg, pdev->bus, pdev->devfn) )
> +         !is_usb_device(pdev->seg, pdev->bus, pdev->devfn) &&
> +         !is_reserve_device_memory(source, pdev->bus, pdev->devfn) )
>      {
>          const struct acpi_rmrr_unit *rmrr;
>          u16 bdf;
> @@ -2315,12 +2317,14 @@ static int intel_iommu_assign_device(
>      if ( ret )
>          return ret;
>  
> -    /* FIXME: Because USB RMRR conflicts with guest bios region,
> -     * ignore USB RMRR temporarily.
> +    /*
> +     * Because USB RMRR conflicts with guest bios region,
> +     * ignore USB RMRR temporarily in case of non-reserving-RMRR.
>       */
>      seg = pdev->seg;
>      bus = pdev->bus;
> -    if ( is_usb_device(seg, bus, pdev->devfn) )
> +    if ( is_usb_device(seg, bus, pdev->devfn) &&
> +         !is_reserve_device_memory(d, bus, pdev->devfn) )
>          return 0;
>  
>      /* Setup rmrr identity mapping */
> diff --git a/xen/drivers/passthrough/vtd/utils.c b/xen/drivers/passthrough/vtd/utils.c
> index a33564b..1045ac1 100644
> --- a/xen/drivers/passthrough/vtd/utils.c
> +++ b/xen/drivers/passthrough/vtd/utils.c
> @@ -36,6 +36,24 @@ int is_usb_device(u16 seg, u8 bus, u8 devfn)
>      return (class == 0xc03);
>  }
>  
> +int is_reserve_device_memory(struct domain *d, u8 bus, u8 devfn)
> +{
> +    int i = 0;
> +
> +    if ( d->arch.hvm_domain.pci_force == PCI_DEV_RDM_CHECK )
> +        return 1;

Ouch. What if the 'hvm_domain' is not there? Please check
first for that.
> +
> +    for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
> +    {
> +        if ( d->arch.hvm_domain.pcidevs[i].bus == bus &&
> +             d->arch.hvm_domain.pcidevs[i].devfn == devfn &&
> +             d->arch.hvm_domain.pcidevs[i].flags == PCI_DEV_RDM_CHECK )
> +        return 1;
> +    }
> +
> +    return 0;
> +}
> +
>  /* Disable vt-d protected memory registers. */
>  void disable_pmr(struct iommu *iommu)
>  {
> -- 
> 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 Dec 05 16:16:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1XwvY5-0005mV-S4; Fri, 05 Dec 2014 16:16: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 1XwvY4-0005mO-6K
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:16:04 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C7/91-09842-34AD1845; Fri, 05 Dec 2014 16:16:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417796161!13757182!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29100 invoked from network); 5 Dec 2014 16:16:02 -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; 5 Dec 2014 16:16: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 sB5GFNA8029941
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 16:15:24 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
	sB5GFJk9019182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 16:15:20 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
	sB5GFJuW019167; Fri, 5 Dec 2014 16:15:19 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 08:15:19 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0551B11F954; Fri,  5 Dec 2014 11:15:18 -0500 (EST)
Date: Fri, 5 Dec 2014 11:15:17 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141205161517.GE472@laptop.dumpdata.com>
References: <1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
	<20141204074756.GA4505@aepfle.de>
	<20141205021508.GB19424@andromeda.dapyr.net>
	<20141205074733.GA29524@aepfle.de>
	<20141205080307.GA31016@aepfle.de> <20141205082844.GA643@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205082844.GA643@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>, 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,
	M A Young <m.a.young@durham.ac.uk>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 09:28:44AM +0100, Olaf Hering wrote:
> On Fri, Dec 05, Olaf Hering wrote:
> 
> > So looking again at
> > tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in it seems that it
> > happens to work for me because XENSTORED_MOUNT_CTX is set within that
> > file. So if something happens to need a different value for
> > XENSTORED_MOUNT_CTX it has to be provided in the to-be-created config
> > file: EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> > This config file is not part of xen. 
> 
> And I wonder why a new config file has to be created, instead of just
> reusing the existing tools/hotplug/Linux/init.d/sysconfig.xencommons.in?

Right.
> 
> I will send out a few patches to adjust the EnvironmentFile handling.

Excellent. Will be happy to test them out.
> 
> Its just the question if a configure --with-selinux-mount-context=VAL is
> needed.

OK. That might be complicated in that the context could change between
bootup and run-time (I think that is what Michael told me).


> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 05 16:16:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1XwvY5-0005mV-S4; Fri, 05 Dec 2014 16:16: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 1XwvY4-0005mO-6K
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:16:04 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C7/91-09842-34AD1845; Fri, 05 Dec 2014 16:16:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417796161!13757182!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29100 invoked from network); 5 Dec 2014 16:16:02 -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; 5 Dec 2014 16:16: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 sB5GFNA8029941
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 16:15:24 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
	sB5GFJk9019182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 16:15:20 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
	sB5GFJuW019167; Fri, 5 Dec 2014 16:15:19 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 08:15:19 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0551B11F954; Fri,  5 Dec 2014 11:15:18 -0500 (EST)
Date: Fri, 5 Dec 2014 11:15:17 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141205161517.GE472@laptop.dumpdata.com>
References: <1417535095.29004.4.camel@citrix.com>
	<20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
	<20141204074756.GA4505@aepfle.de>
	<20141205021508.GB19424@andromeda.dapyr.net>
	<20141205074733.GA29524@aepfle.de>
	<20141205080307.GA31016@aepfle.de> <20141205082844.GA643@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205082844.GA643@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>, 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,
	M A Young <m.a.young@durham.ac.uk>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 09:28:44AM +0100, Olaf Hering wrote:
> On Fri, Dec 05, Olaf Hering wrote:
> 
> > So looking again at
> > tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in it seems that it
> > happens to work for me because XENSTORED_MOUNT_CTX is set within that
> > file. So if something happens to need a different value for
> > XENSTORED_MOUNT_CTX it has to be provided in the to-be-created config
> > file: EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
> > This config file is not part of xen. 
> 
> And I wonder why a new config file has to be created, instead of just
> reusing the existing tools/hotplug/Linux/init.d/sysconfig.xencommons.in?

Right.
> 
> I will send out a few patches to adjust the EnvironmentFile handling.

Excellent. Will be happy to test them out.
> 
> Its just the question if a configure --with-selinux-mount-context=VAL is
> needed.

OK. That might be complicated in that the context could change between
bootup and run-time (I think that is what Michael told me).


> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 05 16:21:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1Xwvcl-0005vB-JD; Fri, 05 Dec 2014 16:20:55 +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 1Xwvck-0005v6-3z
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:20:54 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	23/1A-25547-56BD1845; Fri, 05 Dec 2014 16:20:53 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417796452!11439892!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 27071 invoked from network); 5 Dec 2014 16:20:52 -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; 5 Dec 2014 16:20:52 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0DF20ABCA;
	Fri,  5 Dec 2014 16:20:52 +0000 (UTC)
Date: Fri, 5 Dec 2014 17:20:51 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141205162051.GK25677@wotan.suse.de>
References: <547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
	<547CB07C.1050507@citrix.com>
	<20141201223611.GM25677@wotan.suse.de> <547D9E56.50708@citrix.com>
	<20141203022833.GS25677@wotan.suse.de> <547E939F.40106@suse.com>
	<20141203193947.GD25677@wotan.suse.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141203193947.GD25677@wotan.suse.de>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	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>, Ingo Molnar <mingo@kernel.org>
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 Wed, Dec 03, 2014 at 08:39:47PM +0100, Luis R. Rodriguez wrote:
> On Wed, Dec 03, 2014 at 05:37:51AM +0100, Juergen Gross wrote:
> > On 12/03/2014 03:28 AM, Luis R. Rodriguez wrote:
> >> On Tue, Dec 02, 2014 at 11:11:18AM +0000, David Vrabel wrote:
> >>> On 01/12/14 22:36, Luis R. Rodriguez wrote:
> >>>>
> >>>> Then I do agree its a fair analogy (and find this obviously odd that how
> >>>> widespread cond_resched() is), we just don't have an equivalent for IRQ
> >>>> context, why not avoid the special check then and use this all the time in the
> >>>> middle of a hypercall on the return from an interrupt (e.g., the timer
> >>>> interrupt)?
> >>>
> >>> http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html
> >>
> >> OK thanks! That explains why we need some asm code but in that submission you
> >> still also had used is_preemptible_hypercall(regs) and in the new
> >> implementation you use a CPU variable xen_in_preemptible_hcall prior to calling
> >> preempt_schedule_irq(). I believe you added the CPU variable because
> >> preempt_schedule_irq() will preempt first without any checks if it should, I'm
> >> asking why not do something like cond_resched_irq() where we check with
> >> should_resched() prior to preempting and that way we can avoid having to use
> >> the CPU variable?
> >
> > Because that could preempt at any asynchronous interrupt making the
> > no-preempt kernel fully preemptive. 
> 
> OK yeah I see. That still doesn't negate the value of using something
> like cond_resched_irq() with a should_resched() on only critical hypercalls.
> The current implementation (patch by David) forces preemption without
> checking for should_resched() so it would preempt unnecessarily at least
> once.
> 
> > How would you know you are just
> > doing a critical hypercall which should be preempted?
> 
> You would not, you're right. I was just trying to see if we could generalize
> an API for this to avoid having users having to create their own CPU variables
> but this all seems very specialized as we want to use this on the timer
> so if we do generalize a cond_resched_irq() perhaps the documentation can
> warn about this type of case or abuse.

David's patch had the check only it was x86 based, if we use cond_resched_irq()
we can leave that aspect out to be done through asm inlines or it'll use the
generic shoudl_resched(), that should save some code on the asm implementations.

I have some patches now which generalizees this, I also have more information
about this can happen exactly, and a way to triggger it on small systems with
some hacks to emulate possibly backend behaviour on larger systems. In the worst
case this can be a dangerious situation to be in. I'll send some new RFTs.

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:21:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1Xwvcl-0005vB-JD; Fri, 05 Dec 2014 16:20:55 +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 1Xwvck-0005v6-3z
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:20:54 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	23/1A-25547-56BD1845; Fri, 05 Dec 2014 16:20:53 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417796452!11439892!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 27071 invoked from network); 5 Dec 2014 16:20:52 -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; 5 Dec 2014 16:20:52 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0DF20ABCA;
	Fri,  5 Dec 2014 16:20:52 +0000 (UTC)
Date: Fri, 5 Dec 2014 17:20:51 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141205162051.GK25677@wotan.suse.de>
References: <547C86BF.2040705@citrix.com>
	<CAB=NE6WPvCJnAfdbZqcw5pJtZrfxo0zQu6J2gpXp69G-UTtiUg@mail.gmail.com>
	<547C8F30.1010306@citrix.com>
	<20141201161905.GH25677@wotan.suse.de>
	<547CB07C.1050507@citrix.com>
	<20141201223611.GM25677@wotan.suse.de> <547D9E56.50708@citrix.com>
	<20141203022833.GS25677@wotan.suse.de> <547E939F.40106@suse.com>
	<20141203193947.GD25677@wotan.suse.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141203193947.GD25677@wotan.suse.de>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Joerg Roedel <jroedel@suse.de>, kvm@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>,
	Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	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>, Ingo Molnar <mingo@kernel.org>
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 Wed, Dec 03, 2014 at 08:39:47PM +0100, Luis R. Rodriguez wrote:
> On Wed, Dec 03, 2014 at 05:37:51AM +0100, Juergen Gross wrote:
> > On 12/03/2014 03:28 AM, Luis R. Rodriguez wrote:
> >> On Tue, Dec 02, 2014 at 11:11:18AM +0000, David Vrabel wrote:
> >>> On 01/12/14 22:36, Luis R. Rodriguez wrote:
> >>>>
> >>>> Then I do agree its a fair analogy (and find this obviously odd that how
> >>>> widespread cond_resched() is), we just don't have an equivalent for IRQ
> >>>> context, why not avoid the special check then and use this all the time in the
> >>>> middle of a hypercall on the return from an interrupt (e.g., the timer
> >>>> interrupt)?
> >>>
> >>> http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html
> >>
> >> OK thanks! That explains why we need some asm code but in that submission you
> >> still also had used is_preemptible_hypercall(regs) and in the new
> >> implementation you use a CPU variable xen_in_preemptible_hcall prior to calling
> >> preempt_schedule_irq(). I believe you added the CPU variable because
> >> preempt_schedule_irq() will preempt first without any checks if it should, I'm
> >> asking why not do something like cond_resched_irq() where we check with
> >> should_resched() prior to preempting and that way we can avoid having to use
> >> the CPU variable?
> >
> > Because that could preempt at any asynchronous interrupt making the
> > no-preempt kernel fully preemptive. 
> 
> OK yeah I see. That still doesn't negate the value of using something
> like cond_resched_irq() with a should_resched() on only critical hypercalls.
> The current implementation (patch by David) forces preemption without
> checking for should_resched() so it would preempt unnecessarily at least
> once.
> 
> > How would you know you are just
> > doing a critical hypercall which should be preempted?
> 
> You would not, you're right. I was just trying to see if we could generalize
> an API for this to avoid having users having to create their own CPU variables
> but this all seems very specialized as we want to use this on the timer
> so if we do generalize a cond_resched_irq() perhaps the documentation can
> warn about this type of case or abuse.

David's patch had the check only it was x86 based, if we use cond_resched_irq()
we can leave that aspect out to be done through asm inlines or it'll use the
generic shoudl_resched(), that should save some code on the asm implementations.

I have some patches now which generalizees this, I also have more information
about this can happen exactly, and a way to triggger it on small systems with
some hacks to emulate possibly backend behaviour on larger systems. In the worst
case this can be a dangerious situation to be in. I'll send some new RFTs.

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:21:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1XwvdS-0005y6-0f; Fri, 05 Dec 2014 16:21:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwvdQ-0005xy-TR
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:21:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	20/E9-09842-09BD1845; Fri, 05 Dec 2014 16:21:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417796495!6432019!1
X-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 3597 invoked from network); 5 Dec 2014 16:21:35 -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; 5 Dec 2014 16:21:35 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 16:21:35 +0000
Message-Id: <5481E99F020000780004D4A9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 16:21:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <1417794612-27702-1-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1417794612-27702-1-git-send-email-daniel.kiper@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] console: increase initial conring 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 05.12.14 at 16:50, <daniel.kiper@oracle.com> wrote:
> This bug (or lack of feature if you prefer) should be fixed, as it
> was pointed out by Jan Beulich and Olaf Hering, by allocating conring
> earlier. I though about that before posting this patch (I did not
> know beforehand about Olaf's work made in 2011). However, I stated
> that it is too late to make so intrusive changes.

I continue to disagree. If anything, I'd rather see us hide (e.g. behind
opt_cpu_info) some of the worst offenders causing the log to become
that large. Even if yielding a bigger patch, that would have less impact
functionality wise and likely benefit more people. Nor do I see the
change to move the allocation earlier all that intrusive.

But then again, considering that all you enlarge is an __initdata item,
perhaps this is acceptable.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:21:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1XwvdS-0005y6-0f; Fri, 05 Dec 2014 16:21:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwvdQ-0005xy-TR
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:21:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	20/E9-09842-09BD1845; Fri, 05 Dec 2014 16:21:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417796495!6432019!1
X-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 3597 invoked from network); 5 Dec 2014 16:21:35 -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; 5 Dec 2014 16:21:35 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 16:21:35 +0000
Message-Id: <5481E99F020000780004D4A9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 16:21:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <1417794612-27702-1-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1417794612-27702-1-git-send-email-daniel.kiper@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] console: increase initial conring 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 05.12.14 at 16:50, <daniel.kiper@oracle.com> wrote:
> This bug (or lack of feature if you prefer) should be fixed, as it
> was pointed out by Jan Beulich and Olaf Hering, by allocating conring
> earlier. I though about that before posting this patch (I did not
> know beforehand about Olaf's work made in 2011). However, I stated
> that it is too late to make so intrusive changes.

I continue to disagree. If anything, I'd rather see us hide (e.g. behind
opt_cpu_info) some of the worst offenders causing the log to become
that large. Even if yielding a bigger patch, that would have less impact
functionality wise and likely benefit more people. Nor do I see the
change to move the allocation earlier all that intrusive.

But then again, considering that all you enlarge is an __initdata item,
perhaps this is acceptable.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:22:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:22:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwvec-0006CB-FX; Fri, 05 Dec 2014 16:22: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 1Xwveb-0006Bx-26
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:22:49 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	AE/FE-22737-8DBD1845; Fri, 05 Dec 2014 16:22:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417796562!11810522!1
X-Originating-IP: [66.165.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 6742 invoked from network); 5 Dec 2014 16:22:46 -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;
	5 Dec 2014 16:22:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200792068"
Received: from ukmail1.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, 5 Dec 2014 11:22: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 1XwveR-0001Zn-Iw;
	Fri, 05 Dec 2014 16:22:39 +0000
Date: Fri, 5 Dec 2014 16:22:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141205162239.GB24938@zion.uk.xensource.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<1417795908.22808.73.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417795908.22808.73.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Ian.Jackson@citrix.com, jfehlig@suse.com, Wei Liu <wei.liu2@citrix.com>,
	Chunyan Liu <cyliu@suse.com>, 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 Fri, Dec 05, 2014 at 04:11:48PM +0000, Ian Campbell wrote:
> On Fri, 2014-12-05 at 16:06 +0000, Wei Liu wrote:
> > Regarding JSON API, as Ian said, feel free to hook it up to libxlu.
> 
> *If* it is useful to multiple toolstacks but not suitable for libxl then
> libxlu would be the right place.
> 
> As I understood things the need for JSON here was xl specific, and it is
> IMHO fine for xl to also use the idl infrastructure, without needing to
> launder it via libxlu.
> 

Hmm... I was think about if by any chance Chunyan wants to unify xl and
libvirt's knowledge of a domain snapshot, it can go into libxlu.

I'm no libvirt expert though. If libvirt doesn't need this then putting
it in xl is enough.

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 Dec 05 16:22:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:22:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwvec-0006CB-FX; Fri, 05 Dec 2014 16:22: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 1Xwveb-0006Bx-26
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:22:49 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	AE/FE-22737-8DBD1845; Fri, 05 Dec 2014 16:22:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1417796562!11810522!1
X-Originating-IP: [66.165.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 6742 invoked from network); 5 Dec 2014 16:22:46 -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;
	5 Dec 2014 16:22:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200792068"
Received: from ukmail1.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, 5 Dec 2014 11:22: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 1XwveR-0001Zn-Iw;
	Fri, 05 Dec 2014 16:22:39 +0000
Date: Fri, 5 Dec 2014 16:22:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141205162239.GB24938@zion.uk.xensource.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<1417795908.22808.73.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417795908.22808.73.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Ian.Jackson@citrix.com, jfehlig@suse.com, Wei Liu <wei.liu2@citrix.com>,
	Chunyan Liu <cyliu@suse.com>, 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 Fri, Dec 05, 2014 at 04:11:48PM +0000, Ian Campbell wrote:
> On Fri, 2014-12-05 at 16:06 +0000, Wei Liu wrote:
> > Regarding JSON API, as Ian said, feel free to hook it up to libxlu.
> 
> *If* it is useful to multiple toolstacks but not suitable for libxl then
> libxlu would be the right place.
> 
> As I understood things the need for JSON here was xl specific, and it is
> IMHO fine for xl to also use the idl infrastructure, without needing to
> launder it via libxlu.
> 

Hmm... I was think about if by any chance Chunyan wants to unify xl and
libvirt's knowledge of a domain snapshot, it can go into libxlu.

I'm no libvirt expert though. If libvirt doesn't need this then putting
it in xl is enough.

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 Dec 05 16:23:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1Xwvex-0006GB-SH; Fri, 05 Dec 2014 16:23: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 1Xwvew-0006Fr-F2
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:23:10 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	56/CA-23865-DEBD1845; Fri, 05 Dec 2014 16:23:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417796588!11427047!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26312 invoked from network); 5 Dec 2014 16:23:09 -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; 5 Dec 2014 16:23:09 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 16:23:08 +0000
Message-Id: <5481E9FC020000780004D4C3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 16:23:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Julien Grall" <julien.grall@linaro.org>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com> <5481C30B.3020901@linaro.org>
	<1417790527.22808.67.camel@eu.citrix.com> <5481CE85.8010502@linaro.org>
	<5481E05F020000780004D430@mail.emea.novell.com>
	<5481D7DB.3040907@linaro.org>
In-Reply-To: <5481D7DB.3040907@linaro.org>
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>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 17:05, <julien.grall@linaro.org> wrote:
> On 05/12/14 15:42, Jan Beulich wrote:
>>>>> On 05.12.14 at 16:25, <julien.grall@linaro.org> wrote:
>>> 	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
>>> AFAIU the pirq number is different on each domain. But we use it to
>>> check permission on both domain. Shouldn't we translate the pirq to irq
>>> for the current->domain?
>> 
>> Indeed, see also
>> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00219.html 
> 
> Do you plan to send a patch to resolve this problem?

So far I assumed Stefano would, as he was running into an issue
which iirc fixing this would help.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:23:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1Xwvex-0006GB-SH; Fri, 05 Dec 2014 16:23: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 1Xwvew-0006Fr-F2
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:23:10 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	56/CA-23865-DEBD1845; Fri, 05 Dec 2014 16:23:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1417796588!11427047!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26312 invoked from network); 5 Dec 2014 16:23:09 -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; 5 Dec 2014 16:23:09 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 16:23:08 +0000
Message-Id: <5481E9FC020000780004D4C3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 16:23:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Julien Grall" <julien.grall@linaro.org>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com> <5481C30B.3020901@linaro.org>
	<1417790527.22808.67.camel@eu.citrix.com> <5481CE85.8010502@linaro.org>
	<5481E05F020000780004D430@mail.emea.novell.com>
	<5481D7DB.3040907@linaro.org>
In-Reply-To: <5481D7DB.3040907@linaro.org>
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>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 17:05, <julien.grall@linaro.org> wrote:
> On 05/12/14 15:42, Jan Beulich wrote:
>>>>> On 05.12.14 at 16:25, <julien.grall@linaro.org> wrote:
>>> 	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
>>> AFAIU the pirq number is different on each domain. But we use it to
>>> check permission on both domain. Shouldn't we translate the pirq to irq
>>> for the current->domain?
>> 
>> Indeed, see also
>> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00219.html 
> 
> Do you plan to send a patch to resolve this problem?

So far I assumed Stefano would, as he was running into an issue
which iirc fixing this would help.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:25:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1Xwvgh-0006ZT-CH; Fri, 05 Dec 2014 16:24: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 1Xwvgg-0006ZL-Kk
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:24:58 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	00/DC-17958-95CD1845; Fri, 05 Dec 2014 16:24:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417796695!6963964!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7154 invoked from network); 5 Dec 2014 16:24:57 -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; 5 Dec 2014 16:24:57 -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 sB5GOshV010739
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 16:24:55 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
	sB5GOsKh001267
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 5 Dec 2014 16:24:54 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
	sB5GOrCo000315; Fri, 5 Dec 2014 16:24:53 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 08:24:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6C8F011F96B; Fri,  5 Dec 2014 11:24:52 -0500 (EST)
Date: Fri, 5 Dec 2014 11:24:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205162452.GF472@laptop.dumpdata.com>
References: <5481D7AD020000780004D3BF@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481D7AD020000780004D3BF@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>
Subject: Re: [Xen-devel] ucode=scan usefulness
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 03:05:01PM +0000, Jan Beulich wrote:
> Konrad,
> 
> having been surprised to find your cpio scanning code to not work I
> had to realize that this can't possibly work when the initrd is
> compressed. Considering that you found this useful nevertheless -

Heh. Right.

> am I to imply that you're running with (and only considering) non-
> compressed initrd? Are there plans to support compressed ones too?

I hadn't thought of that use-case as the vehicle to create the
payload is 'dracut'. And its mechanism is to prepend the uncompressed
cpio with microcode to the compressed cpio with normal initramfs.

Thought of course there is nothing stopping to have an compressed
initramfs _with_ the microcode blobs.

I will put this on the Xen 4.6 roadmap.

P.S.
Thought let me double-check that 'dracut' does not compress - it was
not doing that in Fedora 20.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:25:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1Xwvgh-0006ZT-CH; Fri, 05 Dec 2014 16:24: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 1Xwvgg-0006ZL-Kk
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:24:58 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	00/DC-17958-95CD1845; Fri, 05 Dec 2014 16:24:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417796695!6963964!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7154 invoked from network); 5 Dec 2014 16:24:57 -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; 5 Dec 2014 16:24:57 -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 sB5GOshV010739
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 16:24:55 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
	sB5GOsKh001267
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 5 Dec 2014 16:24:54 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
	sB5GOrCo000315; Fri, 5 Dec 2014 16:24:53 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 08:24:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6C8F011F96B; Fri,  5 Dec 2014 11:24:52 -0500 (EST)
Date: Fri, 5 Dec 2014 11:24:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205162452.GF472@laptop.dumpdata.com>
References: <5481D7AD020000780004D3BF@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481D7AD020000780004D3BF@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>
Subject: Re: [Xen-devel] ucode=scan usefulness
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 03:05:01PM +0000, Jan Beulich wrote:
> Konrad,
> 
> having been surprised to find your cpio scanning code to not work I
> had to realize that this can't possibly work when the initrd is
> compressed. Considering that you found this useful nevertheless -

Heh. Right.

> am I to imply that you're running with (and only considering) non-
> compressed initrd? Are there plans to support compressed ones too?

I hadn't thought of that use-case as the vehicle to create the
payload is 'dracut'. And its mechanism is to prepend the uncompressed
cpio with microcode to the compressed cpio with normal initramfs.

Thought of course there is nothing stopping to have an compressed
initramfs _with_ the microcode blobs.

I will put this on the Xen 4.6 roadmap.

P.S.
Thought let me double-check that 'dracut' does not compress - it was
not doing that in Fedora 20.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:27:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:27:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwviu-0006pO-49; Fri, 05 Dec 2014 16:27: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 1Xwvis-0006pI-U6
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:27:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E2/68-15461-2ECD1845; Fri, 05 Dec 2014 16:27:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417796832!13759526!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6975 invoked from network); 5 Dec 2014 16:27:13 -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; 5 Dec 2014 16:27: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 sB5GR8pT014135
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 16:27:09 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
	sB5GR6BB000477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 16:27:07 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
	sB5GR6Xt010274; Fri, 5 Dec 2014 16:27:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 08:27:05 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E722F11F974; Fri,  5 Dec 2014 11:27:04 -0500 (EST)
Date: Fri, 5 Dec 2014 11:27:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141205162704.GG472@laptop.dumpdata.com>
References: <20141204172511.GF43116@deinos.phlegethon.org>
	<54818706020000780004D07D@mail.emea.novell.com>
	<20141205094914.GC25082@deinos.phlegethon.org>
	<1417773296.22808.50.camel@citrix.com>
	<54818C13.8020207@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54818C13.8020207@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, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] PVH cleanups after 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 Fri, Dec 05, 2014 at 10:42:27AM +0000, Andrew Cooper wrote:
> On 05/12/14 09:54, Ian Campbell wrote:
> > On Fri, 2014-12-05 at 10:49 +0100, Tim Deegan wrote:
> >> At 09:20 +0000 on 05 Dec (1417767654), Jan Beulich wrote:
> >>>>>> On 04.12.14 at 18:25, <tim@xen.org> wrote:
> >>>> Potential feature flags, based on whiteboard notes at the session.
> >>>> Things that are 'Yes' in both columns might not need actual flags :)
> >>>>
> >>>>                      'HVM'       'PVH'
> >>>> 64bit hypercalls      Yes         Yes
> >>>> 32bit hypercalls      Yes         No
> >>> Iiuc the lack of support of 32-bit hypercalls is simply because PVH
> >>> guests aren't expected to use them as being always 64-bit right
> >>> now. I.e. I can't really see why we couldn't just enable them once
> >>> the 64-bit hypercall tables got combined, in which case we wouldn't
> >>> need a feature flag here either.
> >> Agreed -- I think the same will apply to a few other things, like shadow
> >> pagetables and some of the other MM tricks.  
> > Might we want to constrain a given PVH domain to only make 32- or 64-bit
> > hypercalls?
> >
> > Or do we consider already having crossed that bridge with HVM enough
> > reason to allow it for PVH? I'm wonder if that, even if it is
> > technically possible to support not, doing so might mitigate some
> > potential security issues down the line. There's obviously a tradeoff
> > against in-guest flexibility though.
> 
> Madating a 32/64bit split serves only to cause booting issues; you need
> to know a-priori what the eventual kernel is going to be before you
> build the domain. This is an awkward issue with PV domains which
> *really* wants not to apply to PVH as well.
> 
> PVH guests with the plan of "HVM - qemu" should be able to fully choose
> their operating mode, and allow for in-guest bootstrapping which is far
> superior from a security/isolation point of view than toolstack
> bootstrapping.

Or another use-case: kexec-ing from within an 64-bit PVH guest to an
32-bit PVH or vice-versa.

> 
> ~Andrew
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:27:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:27:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwviu-0006pO-49; Fri, 05 Dec 2014 16:27: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 1Xwvis-0006pI-U6
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:27:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E2/68-15461-2ECD1845; Fri, 05 Dec 2014 16:27:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1417796832!13759526!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6975 invoked from network); 5 Dec 2014 16:27:13 -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; 5 Dec 2014 16:27: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 sB5GR8pT014135
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 16:27:09 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
	sB5GR6BB000477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 16:27:07 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
	sB5GR6Xt010274; Fri, 5 Dec 2014 16:27:06 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 08:27:05 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E722F11F974; Fri,  5 Dec 2014 11:27:04 -0500 (EST)
Date: Fri, 5 Dec 2014 11:27:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141205162704.GG472@laptop.dumpdata.com>
References: <20141204172511.GF43116@deinos.phlegethon.org>
	<54818706020000780004D07D@mail.emea.novell.com>
	<20141205094914.GC25082@deinos.phlegethon.org>
	<1417773296.22808.50.camel@citrix.com>
	<54818C13.8020207@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54818C13.8020207@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, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] PVH cleanups after 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 Fri, Dec 05, 2014 at 10:42:27AM +0000, Andrew Cooper wrote:
> On 05/12/14 09:54, Ian Campbell wrote:
> > On Fri, 2014-12-05 at 10:49 +0100, Tim Deegan wrote:
> >> At 09:20 +0000 on 05 Dec (1417767654), Jan Beulich wrote:
> >>>>>> On 04.12.14 at 18:25, <tim@xen.org> wrote:
> >>>> Potential feature flags, based on whiteboard notes at the session.
> >>>> Things that are 'Yes' in both columns might not need actual flags :)
> >>>>
> >>>>                      'HVM'       'PVH'
> >>>> 64bit hypercalls      Yes         Yes
> >>>> 32bit hypercalls      Yes         No
> >>> Iiuc the lack of support of 32-bit hypercalls is simply because PVH
> >>> guests aren't expected to use them as being always 64-bit right
> >>> now. I.e. I can't really see why we couldn't just enable them once
> >>> the 64-bit hypercall tables got combined, in which case we wouldn't
> >>> need a feature flag here either.
> >> Agreed -- I think the same will apply to a few other things, like shadow
> >> pagetables and some of the other MM tricks.  
> > Might we want to constrain a given PVH domain to only make 32- or 64-bit
> > hypercalls?
> >
> > Or do we consider already having crossed that bridge with HVM enough
> > reason to allow it for PVH? I'm wonder if that, even if it is
> > technically possible to support not, doing so might mitigate some
> > potential security issues down the line. There's obviously a tradeoff
> > against in-guest flexibility though.
> 
> Madating a 32/64bit split serves only to cause booting issues; you need
> to know a-priori what the eventual kernel is going to be before you
> build the domain. This is an awkward issue with PV domains which
> *really* wants not to apply to PVH as well.
> 
> PVH guests with the plan of "HVM - qemu" should be able to fully choose
> their operating mode, and allow for in-guest bootstrapping which is far
> superior from a security/isolation point of view than toolstack
> bootstrapping.

Or another use-case: kexec-ing from within an 64-bit PVH guest to an
32-bit PVH or vice-versa.

> 
> ~Andrew
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:31:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwvmm-0006zZ-PO; Fri, 05 Dec 2014 16:31:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Xwvmk-0006zP-Ob
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:31:14 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	BA/25-22819-2DDD1845; Fri, 05 Dec 2014 16:31:14 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417797071!8472007!1
X-Originating-IP: [66.165.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 25645 invoked from network); 5 Dec 2014 16:31:13 -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;
	5 Dec 2014 16:31:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200425439"
Received: from ukmail1.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, 5 Dec 2014 11:30:30 -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 1Xwvm2-0001kz-96;
	Fri, 05 Dec 2014 16:30:30 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: <libvir-list@redhat.com>
Date: Fri, 5 Dec 2014 16:30:06 +0000
Message-ID: <1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] libxl: Set path to console on domain startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The path to the pty of a Xen PV console is set only in
virDomainOpenConsole. But this is done too late. A call to
virDomainGetXMLDesc done before OpenConsole will not have the path to
the pty, but a call after OpenConsole will.

e.g. of the current issue.
Starting a domain with '<console type="pty"/>'
Then:
virDomainGetXMLDesc():
  <devices>
    <console type='pty'>
      <target type='xen' port='0'/>
    </console>
  </devices>
virDomainOpenConsole()
virDomainGetXMLDesc():
  <devices>
    <console type='pty' tty='/dev/pts/30'>
      <source path='/dev/pts/30'/>
      <target type='xen' port='0'/>
    </console>
  </devices>

The patch intend to get the tty path on the first call of GetXMLDesc.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 src/libxl/libxl_domain.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 9c62291..de56054 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
     if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
         goto cleanup_dom;
 
+    if (vm->def->nconsoles) {
+        virDomainChrDefPtr chr = NULL;
+        chr = vm->def->consoles[0];
+        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
+            libxl_console_type console_type;
+            char *console = NULL;
+            console_type =
+                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
+                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
+            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
+                                        console_type, &console);
+            if (!ret)
+                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
+            VIR_FREE(console);
+        }
+    }
+
     if (!start_paused) {
         libxl_domain_unpause(priv->ctx, domid);
         virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED);
-- 
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 Dec 05 16:31:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwvmn-0006zg-4R; Fri, 05 Dec 2014 16:31:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Xwvml-0006zU-NV
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:31:15 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	3C/60-27584-3DDD1845; Fri, 05 Dec 2014 16:31:15 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417797071!8472007!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25726 invoked from network); 5 Dec 2014 16:31:14 -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;
	5 Dec 2014 16:31:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200425436"
Received: from ukmail1.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, 5 Dec 2014 11:30:30 -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 1Xwvm2-0001kz-7O;
	Fri, 05 Dec 2014 16:30:30 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: <libvir-list@redhat.com>
Date: Fri, 5 Dec 2014 16:30:05 +0000
Message-ID: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.1.3
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] libxl: Set path to console on domain startup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 trying to fix an issue when using OpenStack with libvirt+xen (libxenlight).
OpenStack cannot access the console output of a Xen PV guest, because the XML
generated by libvirt for a domain is missing the path to the pty. The path
actually appear in the XML once one call virDomainOpenConsole().

The patch intend to get the path to the pty without having to call
virDomainOpenConsole, so I've done the work in libxlDomainStart(). So I have a
few question:
Is libxlDomainStart will be called on restore/migrate/reboot?
I guest the function libxlDomainOpenConsole() would not need to do the same
work if the console path is settup properly.

There is a bug report about this:
https://bugzilla.redhat.com/show_bug.cgi?id=1170743

Regards,

Anthony PERARD (1):
  libxl: Set path to console on domain startup.

 src/libxl/libxl_domain.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

-- 
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 Dec 05 16:31:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwvmm-0006zZ-PO; Fri, 05 Dec 2014 16:31:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Xwvmk-0006zP-Ob
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:31:14 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	BA/25-22819-2DDD1845; Fri, 05 Dec 2014 16:31:14 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417797071!8472007!1
X-Originating-IP: [66.165.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 25645 invoked from network); 5 Dec 2014 16:31:13 -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;
	5 Dec 2014 16:31:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200425439"
Received: from ukmail1.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, 5 Dec 2014 11:30:30 -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 1Xwvm2-0001kz-96;
	Fri, 05 Dec 2014 16:30:30 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: <libvir-list@redhat.com>
Date: Fri, 5 Dec 2014 16:30:06 +0000
Message-ID: <1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] libxl: Set path to console on domain startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The path to the pty of a Xen PV console is set only in
virDomainOpenConsole. But this is done too late. A call to
virDomainGetXMLDesc done before OpenConsole will not have the path to
the pty, but a call after OpenConsole will.

e.g. of the current issue.
Starting a domain with '<console type="pty"/>'
Then:
virDomainGetXMLDesc():
  <devices>
    <console type='pty'>
      <target type='xen' port='0'/>
    </console>
  </devices>
virDomainOpenConsole()
virDomainGetXMLDesc():
  <devices>
    <console type='pty' tty='/dev/pts/30'>
      <source path='/dev/pts/30'/>
      <target type='xen' port='0'/>
    </console>
  </devices>

The patch intend to get the tty path on the first call of GetXMLDesc.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 src/libxl/libxl_domain.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 9c62291..de56054 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
     if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
         goto cleanup_dom;
 
+    if (vm->def->nconsoles) {
+        virDomainChrDefPtr chr = NULL;
+        chr = vm->def->consoles[0];
+        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
+            libxl_console_type console_type;
+            char *console = NULL;
+            console_type =
+                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
+                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
+            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
+                                        console_type, &console);
+            if (!ret)
+                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
+            VIR_FREE(console);
+        }
+    }
+
     if (!start_paused) {
         libxl_domain_unpause(priv->ctx, domid);
         virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED);
-- 
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 Dec 05 16:31:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwvmn-0006zg-4R; Fri, 05 Dec 2014 16:31:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Xwvml-0006zU-NV
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 16:31:15 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	3C/60-27584-3DDD1845; Fri, 05 Dec 2014 16:31:15 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1417797071!8472007!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25726 invoked from network); 5 Dec 2014 16:31:14 -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;
	5 Dec 2014 16:31:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200425436"
Received: from ukmail1.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, 5 Dec 2014 11:30:30 -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 1Xwvm2-0001kz-7O;
	Fri, 05 Dec 2014 16:30:30 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: <libvir-list@redhat.com>
Date: Fri, 5 Dec 2014 16:30:05 +0000
Message-ID: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.1.3
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] libxl: Set path to console on domain startup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 trying to fix an issue when using OpenStack with libvirt+xen (libxenlight).
OpenStack cannot access the console output of a Xen PV guest, because the XML
generated by libvirt for a domain is missing the path to the pty. The path
actually appear in the XML once one call virDomainOpenConsole().

The patch intend to get the path to the pty without having to call
virDomainOpenConsole, so I've done the work in libxlDomainStart(). So I have a
few question:
Is libxlDomainStart will be called on restore/migrate/reboot?
I guest the function libxlDomainOpenConsole() would not need to do the same
work if the console path is settup properly.

There is a bug report about this:
https://bugzilla.redhat.com/show_bug.cgi?id=1170743

Regards,

Anthony PERARD (1):
  libxl: Set path to console on domain startup.

 src/libxl/libxl_domain.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

-- 
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 Dec 05 16:34:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:34:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwvq9-0007VT-PC; Fri, 05 Dec 2014 16:34:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xwvq8-0007VL-Hx
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:34:44 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	9A/FA-28865-3AED1845; Fri, 05 Dec 2014 16:34:43 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417797281!11869599!1
X-Originating-IP: [66.165.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 31612 invoked from network); 5 Dec 2014 16:34:43 -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;
	5 Dec 2014 16:34:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200798405"
Received: from ukmail1.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, 5 Dec 2014 11:34: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 1Xwvq4-0001uS-Qz;
	Fri, 05 Dec 2014 16:34:40 +0000
Date: Fri, 5 Dec 2014 16:34:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <5481E9FC020000780004D4C3@mail.emea.novell.com>
Message-ID: <alpine.DEB.2.02.1412051632190.30971@kaball.uk.xensource.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
	<5481C30B.3020901@linaro.org>
	<1417790527.22808.67.camel@eu.citrix.com>
	<5481CE85.8010502@linaro.org>
	<5481E05F020000780004D430@mail.emea.novell.com>
	<5481D7DB.3040907@linaro.org>
	<5481E9FC020000780004D4C3@mail.emea.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 5 Dec 2014, Jan Beulich wrote:
> >>> On 05.12.14 at 17:05, <julien.grall@linaro.org> wrote:
> > On 05/12/14 15:42, Jan Beulich wrote:
> >>>>> On 05.12.14 at 16:25, <julien.grall@linaro.org> wrote:
> >>> 	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
> >>> AFAIU the pirq number is different on each domain. But we use it to
> >>> check permission on both domain. Shouldn't we translate the pirq to irq
> >>> for the current->domain?
> >> 
> >> Indeed, see also
> >> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00219.html 
> > 
> > Do you plan to send a patch to resolve this problem?
> 
> So far I assumed Stefano would, as he was running into an issue
> which iirc fixing this would help.

I was only interested in fixing a bug for the 4.5 release, this work is
not suitable for 4.5 and I don't know if I'll do it for 4.6.

Regarding the original bug I was trying to fix, I think the original
patch should go in as is:

http://marc.info/?i=alpine.DEB.2.02.1412011852390.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 Dec 05 16:34:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:34:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwvq9-0007VT-PC; Fri, 05 Dec 2014 16:34:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Xwvq8-0007VL-Hx
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:34:44 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	9A/FA-28865-3AED1845; Fri, 05 Dec 2014 16:34:43 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1417797281!11869599!1
X-Originating-IP: [66.165.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 31612 invoked from network); 5 Dec 2014 16:34:43 -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;
	5 Dec 2014 16:34:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200798405"
Received: from ukmail1.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, 5 Dec 2014 11:34: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 1Xwvq4-0001uS-Qz;
	Fri, 05 Dec 2014 16:34:40 +0000
Date: Fri, 5 Dec 2014 16:34:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <5481E9FC020000780004D4C3@mail.emea.novell.com>
Message-ID: <alpine.DEB.2.02.1412051632190.30971@kaball.uk.xensource.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
	<5481C30B.3020901@linaro.org>
	<1417790527.22808.67.camel@eu.citrix.com>
	<5481CE85.8010502@linaro.org>
	<5481E05F020000780004D430@mail.emea.novell.com>
	<5481D7DB.3040907@linaro.org>
	<5481E9FC020000780004D4C3@mail.emea.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 5 Dec 2014, Jan Beulich wrote:
> >>> On 05.12.14 at 17:05, <julien.grall@linaro.org> wrote:
> > On 05/12/14 15:42, Jan Beulich wrote:
> >>>>> On 05.12.14 at 16:25, <julien.grall@linaro.org> wrote:
> >>> 	- XEN_DOMCTL_irq_permission => I don't really understand this bits.
> >>> AFAIU the pirq number is different on each domain. But we use it to
> >>> check permission on both domain. Shouldn't we translate the pirq to irq
> >>> for the current->domain?
> >> 
> >> Indeed, see also
> >> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00219.html 
> > 
> > Do you plan to send a patch to resolve this problem?
> 
> So far I assumed Stefano would, as he was running into an issue
> which iirc fixing this would help.

I was only interested in fixing a bug for the 4.5 release, this work is
not suitable for 4.5 and I don't know if I'll do it for 4.6.

Regarding the original bug I was trying to fix, I think the original
patch should go in as is:

http://marc.info/?i=alpine.DEB.2.02.1412011852390.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 Dec 05 16:40:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwvvm-0007eS-Hb; Fri, 05 Dec 2014 16:40:34 +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 1Xwvvl-0007eN-3g
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:40:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4A/93-09842-000E1845; Fri, 05 Dec 2014 16:40:32 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417797630!13708347!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19308 invoked from network); 5 Dec 2014 16:40:31 -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; 5 Dec 2014 16:40: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 sB5GeNkG031397
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 16:40: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
	sB5GeMAS025645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 16:40:23 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
	sB5GeL6r025554; Fri, 5 Dec 2014 16:40:21 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 08:40:21 -0800
Date: Fri, 5 Dec 2014 17:40:16 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205164016.GB16236@olila.local.net-space.pl>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<20141205145117.GX16236@olila.local.net-space.pl>
	<5481D68E020000780004D3AD@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481D68E020000780004D3AD@mail.emea.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 03:00:14PM +0000, Jan Beulich wrote:
> >>> On 05.12.14 at 15:51, <daniel.kiper@oracle.com> wrote:
> > On Thu, Dec 04, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
> >> >>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
> >> > 3) Should not we change xen/arch/*/efi/efi-boot.h to
> >> >    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
> >> >    code than definitions, declarations and short static
> >> >    functions. So, I think that it is more regular *.c file
> >> >    than header file.
> >>
> >> That's a matter of taste - I'd probably have made it .c too, but
> >> didn't mind it being .h as done by Roy (presumably on the basis
> >> that #include directives are preferred to have .h files as their
> >> operands). The only thing I regret is that I didn't ask for the
> >> pointless efi- prefix to be dropped.
> >
> > As I can see a few people people agree to some extent with my suggestion.
> > Great! Sadly if we wish .c file than simple boot.c (as Jan suggested we can
> > drop efi- prefix) conflicts with exiting boot.c link. Is efi-boot.c OK?
> > Or maybe boot-arch.c? boot.h is OK for sure. Which one do you prefer?
> > Do you have better ideas?
>
> boot.h would be my preference given how things look like right now,

Granted!

> but I don't think this possibility of renaming warrants a much longer
> discussion. Please also remember that renaming always implies more
> cumbersome backporting, even if only slightly more.

I suppose that you are thinking about backporting my EFI + multiboot2
patches somewhere. If you wish I can rename this file after my patch
series or even later to take some fixes for bugs in my code not
discovered earlier. 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 Fri Dec 05 16:40:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwvvm-0007eS-Hb; Fri, 05 Dec 2014 16:40:34 +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 1Xwvvl-0007eN-3g
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:40:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4A/93-09842-000E1845; Fri, 05 Dec 2014 16:40:32 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1417797630!13708347!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19308 invoked from network); 5 Dec 2014 16:40:31 -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; 5 Dec 2014 16:40: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 sB5GeNkG031397
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 16:40: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
	sB5GeMAS025645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 16:40:23 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
	sB5GeL6r025554; Fri, 5 Dec 2014 16:40:21 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 08:40:21 -0800
Date: Fri, 5 Dec 2014 17:40:16 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205164016.GB16236@olila.local.net-space.pl>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<20141205145117.GX16236@olila.local.net-space.pl>
	<5481D68E020000780004D3AD@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481D68E020000780004D3AD@mail.emea.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 03:00:14PM +0000, Jan Beulich wrote:
> >>> On 05.12.14 at 15:51, <daniel.kiper@oracle.com> wrote:
> > On Thu, Dec 04, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
> >> >>> On 03.12.14 at 22:02, <daniel.kiper@oracle.com> wrote:
> >> > 3) Should not we change xen/arch/*/efi/efi-boot.h to
> >> >    xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
> >> >    code than definitions, declarations and short static
> >> >    functions. So, I think that it is more regular *.c file
> >> >    than header file.
> >>
> >> That's a matter of taste - I'd probably have made it .c too, but
> >> didn't mind it being .h as done by Roy (presumably on the basis
> >> that #include directives are preferred to have .h files as their
> >> operands). The only thing I regret is that I didn't ask for the
> >> pointless efi- prefix to be dropped.
> >
> > As I can see a few people people agree to some extent with my suggestion.
> > Great! Sadly if we wish .c file than simple boot.c (as Jan suggested we can
> > drop efi- prefix) conflicts with exiting boot.c link. Is efi-boot.c OK?
> > Or maybe boot-arch.c? boot.h is OK for sure. Which one do you prefer?
> > Do you have better ideas?
>
> boot.h would be my preference given how things look like right now,

Granted!

> but I don't think this possibility of renaming warrants a much longer
> discussion. Please also remember that renaming always implies more
> cumbersome backporting, even if only slightly more.

I suppose that you are thinking about backporting my EFI + multiboot2
patches somewhere. If you wish I can rename this file after my patch
series or even later to take some fixes for bugs in my code not
discovered earlier. 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 Fri Dec 05 16:40:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1Xwvw9-0007gG-Ua; Fri, 05 Dec 2014 16:40: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 1Xwvw7-0007fz-TB
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:40:55 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	BF/66-02696-710E1845; Fri, 05 Dec 2014 16:40:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417797652!13287142!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12432 invoked from network); 5 Dec 2014 16:40:54 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 16:40:54 -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 sB5GenWj031870
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 16:40: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
	sB5GemnG014861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 16:40:49 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
	sB5Gemqv014858; Fri, 5 Dec 2014 16:40:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 08:40:48 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5178311F9E2; Fri,  5 Dec 2014 11:40:47 -0500 (EST)
Date: Fri, 5 Dec 2014 11:40:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205164047.GA1584@laptop.dumpdata.com>
References: <1417794612-27702-1-git-send-email-daniel.kiper@oracle.com>
	<5481E99F020000780004D4A9@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481E99F020000780004D4A9@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	andrew.cooper3@citrix.com, Daniel Kiper <daniel.kiper@oracle.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] console: increase initial conring size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 04:21:35PM +0000, Jan Beulich wrote:
> >>> On 05.12.14 at 16:50, <daniel.kiper@oracle.com> wrote:
> > This bug (or lack of feature if you prefer) should be fixed, as it
> > was pointed out by Jan Beulich and Olaf Hering, by allocating conring
> > earlier. I though about that before posting this patch (I did not
> > know beforehand about Olaf's work made in 2011). However, I stated
> > that it is too late to make so intrusive changes.
> 
> I continue to disagree. If anything, I'd rather see us hide (e.g. behind
> opt_cpu_info) some of the worst offenders causing the log to become
> that large. Even if yielding a bigger patch, that would have less impact

Nowadays the worst offender is the EFI memmap which can be quite
big. We could hide it behind 'opt_efi_info' and only print out some
rather odd entries. But that would be 4.6 material, while this
patch nicely fixes it for 4.5.

> functionality wise and likely benefit more people. Nor do I see the
> change to move the allocation earlier all that intrusive.
> 
> But then again, considering that all you enlarge is an __initdata item,
> perhaps this is acceptable.

This has the other side-benefit that it will help us troubleshoot in
the field without having the customer try extra parameters to extend
the log data.

I am all up for less round-trip to troubleshoot issues and I can't
see this causing any regressions (unless we have some hard-coded EFL
section data).


> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:40:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1Xwvw9-0007gG-Ua; Fri, 05 Dec 2014 16:40: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 1Xwvw7-0007fz-TB
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:40:55 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	BF/66-02696-710E1845; Fri, 05 Dec 2014 16:40:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1417797652!13287142!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12432 invoked from network); 5 Dec 2014 16:40:54 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 16:40:54 -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 sB5GenWj031870
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 16:40: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
	sB5GemnG014861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 16:40:49 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
	sB5Gemqv014858; Fri, 5 Dec 2014 16:40:48 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 08:40:48 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 5178311F9E2; Fri,  5 Dec 2014 11:40:47 -0500 (EST)
Date: Fri, 5 Dec 2014 11:40:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205164047.GA1584@laptop.dumpdata.com>
References: <1417794612-27702-1-git-send-email-daniel.kiper@oracle.com>
	<5481E99F020000780004D4A9@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481E99F020000780004D4A9@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	andrew.cooper3@citrix.com, Daniel Kiper <daniel.kiper@oracle.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] console: increase initial conring size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 04:21:35PM +0000, Jan Beulich wrote:
> >>> On 05.12.14 at 16:50, <daniel.kiper@oracle.com> wrote:
> > This bug (or lack of feature if you prefer) should be fixed, as it
> > was pointed out by Jan Beulich and Olaf Hering, by allocating conring
> > earlier. I though about that before posting this patch (I did not
> > know beforehand about Olaf's work made in 2011). However, I stated
> > that it is too late to make so intrusive changes.
> 
> I continue to disagree. If anything, I'd rather see us hide (e.g. behind
> opt_cpu_info) some of the worst offenders causing the log to become
> that large. Even if yielding a bigger patch, that would have less impact

Nowadays the worst offender is the EFI memmap which can be quite
big. We could hide it behind 'opt_efi_info' and only print out some
rather odd entries. But that would be 4.6 material, while this
patch nicely fixes it for 4.5.

> functionality wise and likely benefit more people. Nor do I see the
> change to move the allocation earlier all that intrusive.
> 
> But then again, considering that all you enlarge is an __initdata item,
> perhaps this is acceptable.

This has the other side-benefit that it will help us troubleshoot in
the field without having the customer try extra parameters to extend
the log data.

I am all up for less round-trip to troubleshoot issues and I can't
see this causing any regressions (unless we have some hard-coded EFL
section data).


> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 16:55:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1XwwA9-0008Sg-DO; Fri, 05 Dec 2014 16:55: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 1XwwA8-0008Sb-IX
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:55:24 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	28/7C-20609-B73E1845; Fri, 05 Dec 2014 16:55:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417798523!13281119!1
X-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 19594 invoked from network); 5 Dec 2014 16:55:23 -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 Dec 2014 16:55:23 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 16:55:22 +0000
Message-Id: <5481F18C020000780004D535@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 16:55: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="=__Part3207EA6C.1__="
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part3207EA6C.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... when "conring_size=3D" was specified on the command line. We can't
really do this as early as we would want to when the option was not
specified, as the default depends on knowing the system CPU count. Yet
the parsing of the ACPI tables is one of the things that generates a
lot of output especially on large systems.

I didn't change ARM, as I wasn't sure how far ahead this call could be
pulled.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1187,6 +1187,7 @@ void __init noreturn __start_xen(unsigne
     }
=20
     vm_init();
+    console_init_mem();
     vesa_init();
=20
     softirq_init();
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -744,15 +744,14 @@ void __init console_init_preirq(void)
     }
 }
=20
-void __init console_init_postirq(void)
+void __init console_init_mem(void)
 {
     char *ring;
     unsigned int i, order, memflags;
-
-    serial_init_postirq();
+    unsigned long flags;
=20
     if ( !opt_conring_size )
-        opt_conring_size =3D num_present_cpus() << (9 + xenlog_lower_thres=
h);
+        return;
=20
     order =3D get_order_from_bytes(max(opt_conring_size, conring_size));
     memflags =3D MEMF_bits(crashinfo_maxaddr_bits);
@@ -763,17 +762,28 @@ void __init console_init_postirq(void)
     }
     opt_conring_size =3D PAGE_SIZE << order;
=20
-    spin_lock_irq(&console_lock);
+    spin_lock_irqsave(&console_lock, flags);
     for ( i =3D conringc ; i !=3D conringp; i++ )
         ring[i & (opt_conring_size - 1)] =3D conring[i & (conring_size - =
1)];
     conring =3D ring;
     smp_wmb(); /* Allow users of console_force_unlock() to see larger =
buffer. */
     conring_size =3D opt_conring_size;
-    spin_unlock_irq(&console_lock);
+    spin_unlock_irqrestore(&console_lock, flags);
=20
     printk("Allocated console ring of %u KiB.\n", opt_conring_size >> =
10);
 }
=20
+void __init console_init_postirq(void)
+{
+    serial_init_postirq();
+
+    if ( !opt_conring_size )
+        opt_conring_size =3D num_present_cpus() << (9 + xenlog_lower_thres=
h);
+
+    if ( conring =3D=3D _conring )
+        console_init_mem();
+}
+
 void __init console_endboot(void)
 {
     int i, j;
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -14,6 +14,7 @@ struct xen_sysctl_readconsole;
 long read_console_ring(struct xen_sysctl_readconsole *op);
=20
 void console_init_preirq(void);
+void console_init_mem(void);
 void console_init_postirq(void);
 void console_endboot(void);
 int console_has(const char *device);




--=__Part3207EA6C.1__=
Content-Type: text/plain; name="conring-alloc-earlier.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="conring-alloc-earlier.patch"

console: allocate ring buffer earlier=0A=0A... when "conring_size=3D" was =
specified on the command line. We can't=0Areally do this as early as we =
would want to when the option was not=0Aspecified, as the default depends =
on knowing the system CPU count. Yet=0Athe parsing of the ACPI tables is =
one of the things that generates a=0Alot of output especially on large =
systems.=0A=0AI didn't change ARM, as I wasn't sure how far ahead this =
call could be=0Apulled.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/setup.c=0A+++ b/xen/arch/x86/setup.c=0A@@ -1187,6 =
+1187,7 @@ void __init noreturn __start_xen(unsigne=0A     }=0A =0A     =
vm_init();=0A+    console_init_mem();=0A     vesa_init();=0A =0A     =
softirq_init();=0A--- a/xen/drivers/char/console.c=0A+++ b/xen/drivers/char=
/console.c=0A@@ -744,15 +744,14 @@ void __init console_init_preirq(void)=0A=
     }=0A }=0A =0A-void __init console_init_postirq(void)=0A+void __init =
console_init_mem(void)=0A {=0A     char *ring;=0A     unsigned int i, =
order, memflags;=0A-=0A-    serial_init_postirq();=0A+    unsigned long =
flags;=0A =0A     if ( !opt_conring_size )=0A-        opt_conring_size =3D =
num_present_cpus() << (9 + xenlog_lower_thresh);=0A+        return;=0A =0A =
    order =3D get_order_from_bytes(max(opt_conring_size, conring_size));=0A=
     memflags =3D MEMF_bits(crashinfo_maxaddr_bits);=0A@@ -763,17 +762,28 =
@@ void __init console_init_postirq(void)=0A     }=0A     opt_conring_size =
=3D PAGE_SIZE << order;=0A =0A-    spin_lock_irq(&console_lock);=0A+    =
spin_lock_irqsave(&console_lock, flags);=0A     for ( i =3D conringc ; i =
!=3D conringp; i++ )=0A         ring[i & (opt_conring_size - 1)] =3D =
conring[i & (conring_size - 1)];=0A     conring =3D ring;=0A     smp_wmb();=
 /* Allow users of console_force_unlock() to see larger buffer. */=0A     =
conring_size =3D opt_conring_size;=0A-    spin_unlock_irq(&console_lock);=
=0A+    spin_unlock_irqrestore(&console_lock, flags);=0A =0A     printk("Al=
located console ring of %u KiB.\n", opt_conring_size >> 10);=0A }=0A =
=0A+void __init console_init_postirq(void)=0A+{=0A+    serial_init_postirq(=
);=0A+=0A+    if ( !opt_conring_size )=0A+        opt_conring_size =3D =
num_present_cpus() << (9 + xenlog_lower_thresh);=0A+=0A+    if ( conring =
=3D=3D _conring )=0A+        console_init_mem();=0A+}=0A+=0A void __init =
console_endboot(void)=0A {=0A     int i, j;=0A--- a/xen/include/xen/console=
.h=0A+++ b/xen/include/xen/console.h=0A@@ -14,6 +14,7 @@ struct xen_sysctl_=
readconsole;=0A long read_console_ring(struct xen_sysctl_readconsole =
*op);=0A =0A void console_init_preirq(void);=0A+void console_init_mem(void)=
;=0A void console_init_postirq(void);=0A void console_endboot(void);=0A =
int console_has(const char *device);=0A
--=__Part3207EA6C.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

--=__Part3207EA6C.1__=--


From xen-devel-bounces@lists.xen.org Fri Dec 05 16:55:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 16: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 1XwwA9-0008Sg-DO; Fri, 05 Dec 2014 16:55: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 1XwwA8-0008Sb-IX
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:55:24 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	28/7C-20609-B73E1845; Fri, 05 Dec 2014 16:55:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1417798523!13281119!1
X-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 19594 invoked from network); 5 Dec 2014 16:55:23 -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 Dec 2014 16:55:23 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 16:55:22 +0000
Message-Id: <5481F18C020000780004D535@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 16:55: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="=__Part3207EA6C.1__="
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>, Tim Deegan <tim@xen.org>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part3207EA6C.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... when "conring_size=3D" was specified on the command line. We can't
really do this as early as we would want to when the option was not
specified, as the default depends on knowing the system CPU count. Yet
the parsing of the ACPI tables is one of the things that generates a
lot of output especially on large systems.

I didn't change ARM, as I wasn't sure how far ahead this call could be
pulled.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1187,6 +1187,7 @@ void __init noreturn __start_xen(unsigne
     }
=20
     vm_init();
+    console_init_mem();
     vesa_init();
=20
     softirq_init();
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -744,15 +744,14 @@ void __init console_init_preirq(void)
     }
 }
=20
-void __init console_init_postirq(void)
+void __init console_init_mem(void)
 {
     char *ring;
     unsigned int i, order, memflags;
-
-    serial_init_postirq();
+    unsigned long flags;
=20
     if ( !opt_conring_size )
-        opt_conring_size =3D num_present_cpus() << (9 + xenlog_lower_thres=
h);
+        return;
=20
     order =3D get_order_from_bytes(max(opt_conring_size, conring_size));
     memflags =3D MEMF_bits(crashinfo_maxaddr_bits);
@@ -763,17 +762,28 @@ void __init console_init_postirq(void)
     }
     opt_conring_size =3D PAGE_SIZE << order;
=20
-    spin_lock_irq(&console_lock);
+    spin_lock_irqsave(&console_lock, flags);
     for ( i =3D conringc ; i !=3D conringp; i++ )
         ring[i & (opt_conring_size - 1)] =3D conring[i & (conring_size - =
1)];
     conring =3D ring;
     smp_wmb(); /* Allow users of console_force_unlock() to see larger =
buffer. */
     conring_size =3D opt_conring_size;
-    spin_unlock_irq(&console_lock);
+    spin_unlock_irqrestore(&console_lock, flags);
=20
     printk("Allocated console ring of %u KiB.\n", opt_conring_size >> =
10);
 }
=20
+void __init console_init_postirq(void)
+{
+    serial_init_postirq();
+
+    if ( !opt_conring_size )
+        opt_conring_size =3D num_present_cpus() << (9 + xenlog_lower_thres=
h);
+
+    if ( conring =3D=3D _conring )
+        console_init_mem();
+}
+
 void __init console_endboot(void)
 {
     int i, j;
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -14,6 +14,7 @@ struct xen_sysctl_readconsole;
 long read_console_ring(struct xen_sysctl_readconsole *op);
=20
 void console_init_preirq(void);
+void console_init_mem(void);
 void console_init_postirq(void);
 void console_endboot(void);
 int console_has(const char *device);




--=__Part3207EA6C.1__=
Content-Type: text/plain; name="conring-alloc-earlier.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="conring-alloc-earlier.patch"

console: allocate ring buffer earlier=0A=0A... when "conring_size=3D" was =
specified on the command line. We can't=0Areally do this as early as we =
would want to when the option was not=0Aspecified, as the default depends =
on knowing the system CPU count. Yet=0Athe parsing of the ACPI tables is =
one of the things that generates a=0Alot of output especially on large =
systems.=0A=0AI didn't change ARM, as I wasn't sure how far ahead this =
call could be=0Apulled.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/setup.c=0A+++ b/xen/arch/x86/setup.c=0A@@ -1187,6 =
+1187,7 @@ void __init noreturn __start_xen(unsigne=0A     }=0A =0A     =
vm_init();=0A+    console_init_mem();=0A     vesa_init();=0A =0A     =
softirq_init();=0A--- a/xen/drivers/char/console.c=0A+++ b/xen/drivers/char=
/console.c=0A@@ -744,15 +744,14 @@ void __init console_init_preirq(void)=0A=
     }=0A }=0A =0A-void __init console_init_postirq(void)=0A+void __init =
console_init_mem(void)=0A {=0A     char *ring;=0A     unsigned int i, =
order, memflags;=0A-=0A-    serial_init_postirq();=0A+    unsigned long =
flags;=0A =0A     if ( !opt_conring_size )=0A-        opt_conring_size =3D =
num_present_cpus() << (9 + xenlog_lower_thresh);=0A+        return;=0A =0A =
    order =3D get_order_from_bytes(max(opt_conring_size, conring_size));=0A=
     memflags =3D MEMF_bits(crashinfo_maxaddr_bits);=0A@@ -763,17 +762,28 =
@@ void __init console_init_postirq(void)=0A     }=0A     opt_conring_size =
=3D PAGE_SIZE << order;=0A =0A-    spin_lock_irq(&console_lock);=0A+    =
spin_lock_irqsave(&console_lock, flags);=0A     for ( i =3D conringc ; i =
!=3D conringp; i++ )=0A         ring[i & (opt_conring_size - 1)] =3D =
conring[i & (conring_size - 1)];=0A     conring =3D ring;=0A     smp_wmb();=
 /* Allow users of console_force_unlock() to see larger buffer. */=0A     =
conring_size =3D opt_conring_size;=0A-    spin_unlock_irq(&console_lock);=
=0A+    spin_unlock_irqrestore(&console_lock, flags);=0A =0A     printk("Al=
located console ring of %u KiB.\n", opt_conring_size >> 10);=0A }=0A =
=0A+void __init console_init_postirq(void)=0A+{=0A+    serial_init_postirq(=
);=0A+=0A+    if ( !opt_conring_size )=0A+        opt_conring_size =3D =
num_present_cpus() << (9 + xenlog_lower_thresh);=0A+=0A+    if ( conring =
=3D=3D _conring )=0A+        console_init_mem();=0A+}=0A+=0A void __init =
console_endboot(void)=0A {=0A     int i, j;=0A--- a/xen/include/xen/console=
.h=0A+++ b/xen/include/xen/console.h=0A@@ -14,6 +14,7 @@ struct xen_sysctl_=
readconsole;=0A long read_console_ring(struct xen_sysctl_readconsole =
*op);=0A =0A void console_init_preirq(void);=0A+void console_init_mem(void)=
;=0A void console_init_postirq(void);=0A void console_endboot(void);=0A =
int console_has(const char *device);=0A
--=__Part3207EA6C.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

--=__Part3207EA6C.1__=--


From xen-devel-bounces@lists.xen.org Fri Dec 05 17:01:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:01:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwwFT-0000DV-Mx; Fri, 05 Dec 2014 17:00:55 +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 1XwwFS-0000DH-EC
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 17:00:54 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	6C/6E-11581-5C4E1845; Fri, 05 Dec 2014 17:00:53 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417798851!11851809!1
X-Originating-IP: [156.151.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 9238 invoked from network); 5 Dec 2014 17:00:53 -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; 5 Dec 2014 17:00:53 -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 sB5H0iL0009856
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 17:00:45 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
	sB5H0hdw008507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 17:00:44 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
	sB5H0huc008499; Fri, 5 Dec 2014 17:00: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, 05 Dec 2014 09:00:43 -0800
Message-ID: <5481E527.5090303@oracle.com>
Date: Fri, 05 Dec 2014 12:02:31 -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: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
	<5481E31B020000780004D44D@mail.emea.novell.com>
In-Reply-To: <5481E31B020000780004D44D@mail.emea.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] pci: Do not ignore device's PXM
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/05/2014 10:53 AM, Jan Beulich wrote:
>
>> --- a/xen/include/xen/pci.h
>> +++ b/xen/include/xen/pci.h
>> @@ -56,6 +56,8 @@ struct pci_dev {
>>   
>>       u8 phantom_stride;
>>   
>> +    int node; /* NUMA node */
> I don't think we currently support node IDs wider than 8 bits.
>

I used an int because pxm_to_node() returns an int. OTOH, pxm2node[], 
for which pxm_to_node() is essentially a wrapper, is a u8.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:01:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:01:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwwFS-0000DI-Ab; Fri, 05 Dec 2014 17:00:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwwFQ-0000DC-Ei
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 17:00:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	27/E1-25276-3C4E1845; Fri, 05 Dec 2014 17:00:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417798851!13751173!1
X-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 6396 invoked from network); 5 Dec 2014 17:00:51 -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; 5 Dec 2014 17:00:51 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 17:00:50 +0000
Message-Id: <5481F2D4020000780004D543@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 17:00:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<20141205145117.GX16236@olila.local.net-space.pl>
	<5481D68E020000780004D3AD@mail.emea.novell.com>
	<20141205164016.GB16236@olila.local.net-space.pl>
In-Reply-To: <20141205164016.GB16236@olila.local.net-space.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 17:40, <daniel.kiper@oracle.com> wrote:
> On Fri, Dec 05, 2014 at 03:00:14PM +0000, Jan Beulich wrote:
>> but I don't think this possibility of renaming warrants a much longer
>> discussion. Please also remember that renaming always implies more
>> cumbersome backporting, even if only slightly more.
> 
> I suppose that you are thinking about backporting my EFI + multiboot2
> patches somewhere.

Not really, I was just thinking about bug fixes in general.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:01:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:01:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwwFT-0000DV-Mx; Fri, 05 Dec 2014 17:00:55 +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 1XwwFS-0000DH-EC
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 17:00:54 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	6C/6E-11581-5C4E1845; Fri, 05 Dec 2014 17:00:53 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417798851!11851809!1
X-Originating-IP: [156.151.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 9238 invoked from network); 5 Dec 2014 17:00:53 -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; 5 Dec 2014 17:00:53 -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 sB5H0iL0009856
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 17:00:45 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
	sB5H0hdw008507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 17:00:44 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
	sB5H0huc008499; Fri, 5 Dec 2014 17:00: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, 05 Dec 2014 09:00:43 -0800
Message-ID: <5481E527.5090303@oracle.com>
Date: Fri, 05 Dec 2014 12:02:31 -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: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-2-git-send-email-boris.ostrovsky@oracle.com>
	<5481E31B020000780004D44D@mail.emea.novell.com>
In-Reply-To: <5481E31B020000780004D44D@mail.emea.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] pci: Do not ignore device's PXM
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/05/2014 10:53 AM, Jan Beulich wrote:
>
>> --- a/xen/include/xen/pci.h
>> +++ b/xen/include/xen/pci.h
>> @@ -56,6 +56,8 @@ struct pci_dev {
>>   
>>       u8 phantom_stride;
>>   
>> +    int node; /* NUMA node */
> I don't think we currently support node IDs wider than 8 bits.
>

I used an int because pxm_to_node() returns an int. OTOH, pxm2node[], 
for which pxm_to_node() is essentially a wrapper, is a u8.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:01:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:01:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwwFS-0000DI-Ab; Fri, 05 Dec 2014 17:00:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XwwFQ-0000DC-Ei
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 17:00:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	27/E1-25276-3C4E1845; Fri, 05 Dec 2014 17:00:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1417798851!13751173!1
X-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 6396 invoked from network); 5 Dec 2014 17:00:51 -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; 5 Dec 2014 17:00:51 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 05 Dec 2014 17:00:50 +0000
Message-Id: <5481F2D4020000780004D543@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 05 Dec 2014 17:00:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<20141205145117.GX16236@olila.local.net-space.pl>
	<5481D68E020000780004D3AD@mail.emea.novell.com>
	<20141205164016.GB16236@olila.local.net-space.pl>
In-Reply-To: <20141205164016.GB16236@olila.local.net-space.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 17:40, <daniel.kiper@oracle.com> wrote:
> On Fri, Dec 05, 2014 at 03:00:14PM +0000, Jan Beulich wrote:
>> but I don't think this possibility of renaming warrants a much longer
>> discussion. Please also remember that renaming always implies more
>> cumbersome backporting, even if only slightly more.
> 
> I suppose that you are thinking about backporting my EFI + multiboot2
> patches somewhere.

Not really, I was just thinking about bug fixes in general.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:03:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17: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 1XwwIH-0000gh-9W; Fri, 05 Dec 2014 17:03:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XwwIG-0000gZ-Hv
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 17:03:48 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	19/DB-26858-375E1845; Fri, 05 Dec 2014 17:03:47 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417799026!11396055!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20522 invoked from network); 5 Dec 2014 17:03:47 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-2.tower-31.messagelabs.com with SMTP;
	5 Dec 2014 17:03:47 -0000
X-TM-IMSS-Message-ID: <8a521616000801e1@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 8a521616000801e1 ;
	Fri, 5 Dec 2014 12:03:30 -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 sB5H3DHm011889; 
	Fri, 5 Dec 2014 12:03:23 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 12:03:07 -0500
Message-Id: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.9.3
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH for-4.5] flask/policy: Example policy updates
	for migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The example XSM policy was missing permission for dom0_t to migrate
domains; add these permissions.

Reported-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---

This has been tested with xl save/restore on a PV domain, which now
succeeds without producing AVC denials.

 tools/flask/policy/policy/modules/xen/xen.if | 11 +++++++----
 tools/flask/policy/policy/modules/xen/xen.te |  3 +++
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index fa69c9d..bf5e135 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -48,11 +48,13 @@ define(`create_domain_common', `
 	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
 			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 };
+			getaffinity setaffinity setvcpuextstate };
+	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
+			set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
+			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 };
+	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
 	allow $1 $2:grant setup;
 	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
 			setparam pcilevel trackdirtyvram nested };
@@ -80,7 +82,7 @@ define(`create_domain_build_label', `
 define(`manage_domain', `
 	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
 			getaddrsize pause unpause trigger shutdown destroy
-			setaffinity setdomainmaxmem getscheduler };
+			setaffinity setdomainmaxmem getscheduler resume };
     allow $1 $2:domain2 set_vnumainfo;
 ')
 
@@ -88,6 +90,7 @@ define(`manage_domain', `
 #   Allow creation of a snapshot or migration image from a domain
 #   (inbound migration is the same as domain creation)
 define(`migrate_domain_out', `
+	allow $1 domxen_t:mmu map_read;
 	allow $1 $2:hvm { gethvmc getparam irqlevel };
 	allow $1 $2:mmu { stat pageinfo map_read };
 	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index d214470..c0128aa 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -129,12 +129,14 @@ create_domain(dom0_t, domU_t)
 manage_domain(dom0_t, domU_t)
 domain_comms(dom0_t, domU_t)
 domain_comms(domU_t, domU_t)
+migrate_domain_out(dom0_t, domU_t)
 domain_self_comms(domU_t)
 
 declare_domain(isolated_domU_t)
 create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
+migrate_domain_out(dom0_t, isolated_domU_t)
 domain_self_comms(isolated_domU_t)
 
 # Declare a boolean that denies creation of prot_domU_t domains
@@ -142,6 +144,7 @@ gen_bool(prot_doms_locked, false)
 declare_domain(prot_domU_t)
 if (!prot_doms_locked) {
 	create_domain(dom0_t, prot_domU_t)
+	migrate_domain_out(dom0_t, prot_domU_t)
 }
 domain_comms(dom0_t, prot_domU_t)
 domain_comms(domU_t, prot_domU_t)
-- 
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 Dec 05 17:03:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17: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 1XwwIH-0000gh-9W; Fri, 05 Dec 2014 17:03:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1XwwIG-0000gZ-Hv
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 17:03:48 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	19/DB-26858-375E1845; Fri, 05 Dec 2014 17:03:47 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-31.messagelabs.com!1417799026!11396055!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20522 invoked from network); 5 Dec 2014 17:03:47 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-2.tower-31.messagelabs.com with SMTP;
	5 Dec 2014 17:03:47 -0000
X-TM-IMSS-Message-ID: <8a521616000801e1@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 8a521616000801e1 ;
	Fri, 5 Dec 2014 12:03:30 -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 sB5H3DHm011889; 
	Fri, 5 Dec 2014 12:03:23 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Fri,  5 Dec 2014 12:03:07 -0500
Message-Id: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.9.3
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH for-4.5] flask/policy: Example policy updates
	for migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The example XSM policy was missing permission for dom0_t to migrate
domains; add these permissions.

Reported-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---

This has been tested with xl save/restore on a PV domain, which now
succeeds without producing AVC denials.

 tools/flask/policy/policy/modules/xen/xen.if | 11 +++++++----
 tools/flask/policy/policy/modules/xen/xen.te |  3 +++
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index fa69c9d..bf5e135 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -48,11 +48,13 @@ define(`create_domain_common', `
 	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
 			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 };
+			getaffinity setaffinity setvcpuextstate };
+	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
+			set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
+			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 };
+	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
 	allow $1 $2:grant setup;
 	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
 			setparam pcilevel trackdirtyvram nested };
@@ -80,7 +82,7 @@ define(`create_domain_build_label', `
 define(`manage_domain', `
 	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
 			getaddrsize pause unpause trigger shutdown destroy
-			setaffinity setdomainmaxmem getscheduler };
+			setaffinity setdomainmaxmem getscheduler resume };
     allow $1 $2:domain2 set_vnumainfo;
 ')
 
@@ -88,6 +90,7 @@ define(`manage_domain', `
 #   Allow creation of a snapshot or migration image from a domain
 #   (inbound migration is the same as domain creation)
 define(`migrate_domain_out', `
+	allow $1 domxen_t:mmu map_read;
 	allow $1 $2:hvm { gethvmc getparam irqlevel };
 	allow $1 $2:mmu { stat pageinfo map_read };
 	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index d214470..c0128aa 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -129,12 +129,14 @@ create_domain(dom0_t, domU_t)
 manage_domain(dom0_t, domU_t)
 domain_comms(dom0_t, domU_t)
 domain_comms(domU_t, domU_t)
+migrate_domain_out(dom0_t, domU_t)
 domain_self_comms(domU_t)
 
 declare_domain(isolated_domU_t)
 create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
+migrate_domain_out(dom0_t, isolated_domU_t)
 domain_self_comms(isolated_domU_t)
 
 # Declare a boolean that denies creation of prot_domU_t domains
@@ -142,6 +144,7 @@ gen_bool(prot_doms_locked, false)
 declare_domain(prot_domU_t)
 if (!prot_doms_locked) {
 	create_domain(dom0_t, prot_domU_t)
+	migrate_domain_out(dom0_t, prot_domU_t)
 }
 domain_comms(dom0_t, prot_domU_t)
 domain_comms(domU_t, prot_domU_t)
-- 
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 Dec 05 17:09:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:09:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwwN6-0000sj-1B; Fri, 05 Dec 2014 17:08:48 +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 1XwwN4-0000se-Bq
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 17:08:46 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FA/9E-15461-D96E1845; Fri, 05 Dec 2014 17:08:45 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417799323!13772662!1
X-Originating-IP: [156.151.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 12090 invoked from network); 5 Dec 2014 17:08:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 17:08: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 sB5H8bXL020122
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 17:08: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
	sB5H8W3Z025263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 17:08:33 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
	sB5H8W45006818; Fri, 5 Dec 2014 17:08:32 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, 05 Dec 2014 09:08:32 -0800
Message-ID: <5481E6FC.1070905@oracle.com>
Date: Fri, 05 Dec 2014 12:10:20 -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: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<5481E39B020000780004D450@mail.emea.novell.com>
	<5481E564020000780004D47B@mail.emea.novell.com>
In-Reply-To: <5481E564020000780004D47B@mail.emea.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 12/05/2014 11:03 AM, Jan Beulich wrote:
>>>> On 05.12.14 at 16:55, <JBeulich@suse.com> wrote:
>>>>> On 02.12.14 at 22:34, <boris.ostrovsky@oracle.com> wrote:
>>> +struct xen_sysctl_iotopo {
>>> +    uint16_t seg;
>>> +    uint8_t bus;
>>> +    uint8_t devfn;
>>> +    uint32_t node;
>>> +};
>> This is PCI-centric without expressing in the name or layout.

xen_sysctl_pcitopo would be a better name.

>>   Perhaps
>> the first part should be a union from the very beginning?
> And I wonder whether that supposed union part wouldn't be nicely
> done using struct physdev_pci_device.

The do look strikingly similar ;-)

How would a union be useful here?

>
> Additionally please add IN and OUT annotations. When I first saw
> this I assumed they would all be OUT (in which case the long running
> loop problem mentioned in the reply to one of the other patches
> wouldn't have been there), matching their CPU counterpart...

I don't follow this. Are you saying that if ti->max_devs in patch 3/4 is 
an IN (which it is) then we don't have to guard for long-running loops?

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:09:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:09:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwwN6-0000sj-1B; Fri, 05 Dec 2014 17:08:48 +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 1XwwN4-0000se-Bq
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 17:08:46 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FA/9E-15461-D96E1845; Fri, 05 Dec 2014 17:08:45 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1417799323!13772662!1
X-Originating-IP: [156.151.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 12090 invoked from network); 5 Dec 2014 17:08:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 17:08: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 sB5H8bXL020122
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 17:08: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
	sB5H8W3Z025263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 17:08:33 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
	sB5H8W45006818; Fri, 5 Dec 2014 17:08:32 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, 05 Dec 2014 09:08:32 -0800
Message-ID: <5481E6FC.1070905@oracle.com>
Date: Fri, 05 Dec 2014 12:10:20 -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: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<5481E39B020000780004D450@mail.emea.novell.com>
	<5481E564020000780004D47B@mail.emea.novell.com>
In-Reply-To: <5481E564020000780004D47B@mail.emea.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 12/05/2014 11:03 AM, Jan Beulich wrote:
>>>> On 05.12.14 at 16:55, <JBeulich@suse.com> wrote:
>>>>> On 02.12.14 at 22:34, <boris.ostrovsky@oracle.com> wrote:
>>> +struct xen_sysctl_iotopo {
>>> +    uint16_t seg;
>>> +    uint8_t bus;
>>> +    uint8_t devfn;
>>> +    uint32_t node;
>>> +};
>> This is PCI-centric without expressing in the name or layout.

xen_sysctl_pcitopo would be a better name.

>>   Perhaps
>> the first part should be a union from the very beginning?
> And I wonder whether that supposed union part wouldn't be nicely
> done using struct physdev_pci_device.

The do look strikingly similar ;-)

How would a union be useful here?

>
> Additionally please add IN and OUT annotations. When I first saw
> this I assumed they would all be OUT (in which case the long running
> loop problem mentioned in the reply to one of the other patches
> wouldn't have been there), matching their CPU counterpart...

I don't follow this. Are you saying that if ti->max_devs in patch 3/4 is 
an IN (which it is) then we don't have to guard for long-running loops?

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:11:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:11:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwwPO-0000yx-Ik; Fri, 05 Dec 2014 17:11:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>)
	id 1XwwPN-0000yk-3O; Fri, 05 Dec 2014 17:11:09 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	12/11-15461-C27E1845; Fri, 05 Dec 2014 17:11:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417799467!13726191!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2712 invoked from network); 5 Dec 2014 17:11:07 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 17:11:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417799467; l=725;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=K7tgC50ndN+rATIreKIOkdRiUiA=;
	b=iXube5+2jckfmoWwKwsZHgm1rrHz5MRXFPw51ln56UAmaEgFynQhi351ZMYkvWqPw4q
	TLps0JAGykya4Dg32RWr6g4Hvs8pz+EC1B53qFOwmbnpqun4UZ7h3Ymbh5bq55FM7JXwb
	6/LfffTBn1kXAFoH6sBEIiorMnTMGxs4aNY=
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.2 AUTH) with ESMTPSA id n00af9qB5HB3Vzg
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 18:11:03 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 581575015E; Fri,  5 Dec 2014 18:11:03 +0100 (CET)
Date: Fri, 5 Dec 2014 18:11:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141205171102.GA24737@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202151708.GA23112@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, 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>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Olaf Hering wrote:

> On Tue, Dec 02, Ian Campbell wrote:
> 
> > On Mon, 2014-12-01 at 23:41 +0000, Mark Pryor wrote:
> > > list,
> > 
> > Thanks. If you've identified a buggy changeset then it is fine to post
> > to the devel lists. I've added a CC. I've also CCd everyone listed in
> > the commit which you've fingered.
> > 
> > Olaf, does this suggested change look correct? If so then can you turn
> > it into a patch please.
> 
> Yes, something like this (sed -i 's@socket@service@g' *.in):

But even with that change xendomains is hanging if it cant talk to
xenstored for whatever  reason. The result is that the sytem hangs
forever at shutdown. 

I will try to fix that for 4.5.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:11:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:11:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwwPO-0000yx-Ik; Fri, 05 Dec 2014 17:11:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>)
	id 1XwwPN-0000yk-3O; Fri, 05 Dec 2014 17:11:09 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	12/11-15461-C27E1845; Fri, 05 Dec 2014 17:11:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417799467!13726191!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2712 invoked from network); 5 Dec 2014 17:11:07 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 17:11:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417799467; l=725;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=K7tgC50ndN+rATIreKIOkdRiUiA=;
	b=iXube5+2jckfmoWwKwsZHgm1rrHz5MRXFPw51ln56UAmaEgFynQhi351ZMYkvWqPw4q
	TLps0JAGykya4Dg32RWr6g4Hvs8pz+EC1B53qFOwmbnpqun4UZ7h3Ymbh5bq55FM7JXwb
	6/LfffTBn1kXAFoH6sBEIiorMnTMGxs4aNY=
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.2 AUTH) with ESMTPSA id n00af9qB5HB3Vzg
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 5 Dec 2014 18:11:03 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 581575015E; Fri,  5 Dec 2014 18:11:03 +0100 (CET)
Date: Fri, 5 Dec 2014 18:11:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141205171102.GA24737@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141202151708.GA23112@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, 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>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, Olaf Hering wrote:

> On Tue, Dec 02, Ian Campbell wrote:
> 
> > On Mon, 2014-12-01 at 23:41 +0000, Mark Pryor wrote:
> > > list,
> > 
> > Thanks. If you've identified a buggy changeset then it is fine to post
> > to the devel lists. I've added a CC. I've also CCd everyone listed in
> > the commit which you've fingered.
> > 
> > Olaf, does this suggested change look correct? If so then can you turn
> > it into a patch please.
> 
> Yes, something like this (sed -i 's@socket@service@g' *.in):

But even with that change xendomains is hanging if it cant talk to
xenstored for whatever  reason. The result is that the sytem hangs
forever at shutdown. 

I will try to fix that for 4.5.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:19:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwwXR-0001bR-Aj; Fri, 05 Dec 2014 17:19: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 1XwwXP-0001bL-Mg
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 17:19:27 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	39/8F-23865-E19E1845; Fri, 05 Dec 2014 17:19:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417799964!11414203!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28244 invoked from network); 5 Dec 2014 17:19:26 -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; 5 Dec 2014 17:19:26 -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 sB5HJBUp018066
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 17:19:11 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
	sB5HJ9AZ014012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 17:19:10 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
	sB5HJ9i4000432; Fri, 5 Dec 2014 17:19:09 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 09:19:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B315011FA61; Fri,  5 Dec 2014 12:19:07 -0500 (EST)
Date: Fri, 5 Dec 2014 12:19:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141205171907.GD2301@laptop.dumpdata.com>
References: <1417776587-26018-1-git-send-email-olaf@aepfle.de>
	<1417776783.22808.55.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417776783.22808.55.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>, Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/xenstore: fix link error with
	libsystemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 10:53:03AM +0000, Ian Campbell wrote:
> On Fri, 2014-12-05 at 11:49 +0100, Olaf Hering wrote:
> > Linking fails with undefined reference to the used systemd functions.
> > Move LDFLAGS after the object files to fix the failure.
> > 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> This should go into 4.5.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> FWIW my suspicion is that this relates to toolstacks using --as-needed
> by default.
> 
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  tools/xenstore/Makefile | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> > index bff9b25..11b6a06 100644
> > --- a/tools/xenstore/Makefile
> > +++ b/tools/xenstore/Makefile
> > @@ -74,10 +74,10 @@ endif
> >  init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
> >  
> >  init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
> > -	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
> > +	$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
> >  
> >  xenstored: $(XENSTORED_OBJS)
> > -	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> > +	$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> >  
> >  xenstored.a: $(XENSTORED_OBJS)
> >  	$(AR) cr $@ $^
> > @@ -86,13 +86,13 @@ $(CLIENTS): xenstore
> >  	ln -f xenstore $@
> >  
> >  xenstore: xenstore_client.o $(LIBXENSTORE)
> > -	$(CC) $(LDFLAGS) $< $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> > +	$(CC) $< $(LDFLAGS) $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> >  
> >  xenstore-control: xenstore_control.o $(LIBXENSTORE)
> > -	$(CC) $(LDFLAGS) $< $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> > +	$(CC) $< $(LDFLAGS) $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> >  
> >  xs_tdb_dump: xs_tdb_dump.o utils.o tdb.o talloc.o
> > -	$(CC) $(LDFLAGS) $^ -o $@ $(APPEND_LDFLAGS)
> > +	$(CC) $^ $(LDFLAGS) -o $@ $(APPEND_LDFLAGS)
> >  
> >  libxenstore.so: libxenstore.so.$(MAJOR)
> >  	ln -sf $< $@
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:19:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwwXR-0001bR-Aj; Fri, 05 Dec 2014 17:19: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 1XwwXP-0001bL-Mg
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 17:19:27 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	39/8F-23865-E19E1845; Fri, 05 Dec 2014 17:19:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417799964!11414203!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28244 invoked from network); 5 Dec 2014 17:19:26 -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; 5 Dec 2014 17:19:26 -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 sB5HJBUp018066
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 17:19:11 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
	sB5HJ9AZ014012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 17:19:10 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
	sB5HJ9i4000432; Fri, 5 Dec 2014 17:19:09 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 09:19:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B315011FA61; Fri,  5 Dec 2014 12:19:07 -0500 (EST)
Date: Fri, 5 Dec 2014 12:19:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141205171907.GD2301@laptop.dumpdata.com>
References: <1417776587-26018-1-git-send-email-olaf@aepfle.de>
	<1417776783.22808.55.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417776783.22808.55.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>, Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/xenstore: fix link error with
	libsystemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 10:53:03AM +0000, Ian Campbell wrote:
> On Fri, 2014-12-05 at 11:49 +0100, Olaf Hering wrote:
> > Linking fails with undefined reference to the used systemd functions.
> > Move LDFLAGS after the object files to fix the failure.
> > 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> This should go into 4.5.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> FWIW my suspicion is that this relates to toolstacks using --as-needed
> by default.
> 
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  tools/xenstore/Makefile | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> > index bff9b25..11b6a06 100644
> > --- a/tools/xenstore/Makefile
> > +++ b/tools/xenstore/Makefile
> > @@ -74,10 +74,10 @@ endif
> >  init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
> >  
> >  init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
> > -	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
> > +	$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
> >  
> >  xenstored: $(XENSTORED_OBJS)
> > -	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> > +	$(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> >  
> >  xenstored.a: $(XENSTORED_OBJS)
> >  	$(AR) cr $@ $^
> > @@ -86,13 +86,13 @@ $(CLIENTS): xenstore
> >  	ln -f xenstore $@
> >  
> >  xenstore: xenstore_client.o $(LIBXENSTORE)
> > -	$(CC) $(LDFLAGS) $< $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> > +	$(CC) $< $(LDFLAGS) $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> >  
> >  xenstore-control: xenstore_control.o $(LIBXENSTORE)
> > -	$(CC) $(LDFLAGS) $< $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> > +	$(CC) $< $(LDFLAGS) $(LDLIBS_libxenstore) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> >  
> >  xs_tdb_dump: xs_tdb_dump.o utils.o tdb.o talloc.o
> > -	$(CC) $(LDFLAGS) $^ -o $@ $(APPEND_LDFLAGS)
> > +	$(CC) $^ $(LDFLAGS) -o $@ $(APPEND_LDFLAGS)
> >  
> >  libxenstore.so: libxenstore.so.$(MAJOR)
> >  	ln -sf $< $@
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:23:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:23:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwwax-0001t1-0S; Fri, 05 Dec 2014 17:23: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 1Xwwau-0001su-MX
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 17:23:04 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	A7/4C-27623-7F9E1845; Fri, 05 Dec 2014 17:23:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417800181!8976349!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26433 invoked from network); 5 Dec 2014 17:23:03 -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; 5 Dec 2014 17:23: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 sB5HMtSK022285
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 17:22:56 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
	sB5HMqWg004948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 17:22:53 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
	sB5HMqT2011112; Fri, 5 Dec 2014 17:22:52 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 09:22:51 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 94EFF11FA67; Fri,  5 Dec 2014 12:22:50 -0500 (EST)
Date: Fri, 5 Dec 2014 12:22:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141205172250.GA2895@laptop.dumpdata.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
	<1417707546.15750.100.camel@bling.home>
	<54818929.5000008@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54818929.5000008@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Alex Williamson <alex.williamson@redhat.com>,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 10:30:01AM +0000, David Vrabel wrote:
> On 04/12/14 15:39, Alex Williamson wrote:
> > 
> > I don't know what workaround you're talking about.  As devices are
> > released from the user, vfio-pci attempts to reset them.  If
> > pci_reset_function() returns success we mark the device clean, otherwise
> > it gets marked dirty.  Each time a device is released, if there are
> > dirty devices we test whether we can try a bus/slot reset to clean them.
> > In the case of assigning a GPU this typically means that the GPU or
> > audio function come through first, there's no reset mechanism so it gets
> > marked dirty, the next device comes through and we manage to try a bus
> > reset.  vfio-pci does not have any device specific resets, all
> > functionality is added to the PCI-core, thank-you-very-much.  I even
> > posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
> > bad so that pci_reset_function() won't claim that worked.  All VGA
> > access quirks are done in QEMU, the kernel doesn't have any business in
> > remapping config space over MMIO regions or trapping other config space
> > backdoors.
> 
> Thanks for the info Alex, I hadn't got around to actually looking and
> the vfio-pci code and was just going to what Sander said.
> 
> We probably do need to have a more in depth look at now PCI devices and
> handled by both the toolstack and pciback but in the short term I would
> like a simple solution that does not extend the ABI.

Could you enumerate the 'simple solution' then please? I am having
a frustrating time figuring out what it is that you are proposing.


> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:23:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:23:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwwax-0001t1-0S; Fri, 05 Dec 2014 17:23: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 1Xwwau-0001su-MX
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 17:23:04 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	A7/4C-27623-7F9E1845; Fri, 05 Dec 2014 17:23:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417800181!8976349!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26433 invoked from network); 5 Dec 2014 17:23:03 -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; 5 Dec 2014 17:23: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 sB5HMtSK022285
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 17:22:56 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
	sB5HMqWg004948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 17:22:53 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
	sB5HMqT2011112; Fri, 5 Dec 2014 17:22:52 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 09:22:51 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 94EFF11FA67; Fri,  5 Dec 2014 12:22:50 -0500 (EST)
Date: Fri, 5 Dec 2014 12:22:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141205172250.GA2895@laptop.dumpdata.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
	<1417707546.15750.100.camel@bling.home>
	<54818929.5000008@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54818929.5000008@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Alex Williamson <alex.williamson@redhat.com>,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 10:30:01AM +0000, David Vrabel wrote:
> On 04/12/14 15:39, Alex Williamson wrote:
> > 
> > I don't know what workaround you're talking about.  As devices are
> > released from the user, vfio-pci attempts to reset them.  If
> > pci_reset_function() returns success we mark the device clean, otherwise
> > it gets marked dirty.  Each time a device is released, if there are
> > dirty devices we test whether we can try a bus/slot reset to clean them.
> > In the case of assigning a GPU this typically means that the GPU or
> > audio function come through first, there's no reset mechanism so it gets
> > marked dirty, the next device comes through and we manage to try a bus
> > reset.  vfio-pci does not have any device specific resets, all
> > functionality is added to the PCI-core, thank-you-very-much.  I even
> > posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
> > bad so that pci_reset_function() won't claim that worked.  All VGA
> > access quirks are done in QEMU, the kernel doesn't have any business in
> > remapping config space over MMIO regions or trapping other config space
> > backdoors.
> 
> Thanks for the info Alex, I hadn't got around to actually looking and
> the vfio-pci code and was just going to what Sander said.
> 
> We probably do need to have a more in depth look at now PCI devices and
> handled by both the toolstack and pciback but in the short term I would
> like a simple solution that does not extend the ABI.

Could you enumerate the 'simple solution' then please? I am having
a frustrating time figuring out what it is that you are proposing.


> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:23:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:23:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwwb1-0001uV-Hx; Fri, 05 Dec 2014 17:23:11 +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 1Xwwb0-0001u9-Hm
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 17:23:10 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	DD/39-09284-DF9E1845; Fri, 05 Dec 2014 17:23:09 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417800187!11451674!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18320 invoked from network); 5 Dec 2014 17:23:08 -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; 5 Dec 2014 17:23: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 sB5HN3Xq022590
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 17:23:04 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
	sB5HN3Qc005535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 17:23:03 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
	sB5HN2de026082; Fri, 5 Dec 2014 17:23:02 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 09:23:02 -0800
Date: Fri, 5 Dec 2014 18:22:57 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205172257.GC16236@olila.local.net-space.pl>
References: <5481F18C020000780004D535@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481F18C020000780004D535@mail.emea.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 04:55:24PM +0000, Jan Beulich wrote:
> ... when "conring_size=" was specified on the command line. We can't
> really do this as early as we would want to when the option was not
> specified, as the default depends on knowing the system CPU count. Yet
> the parsing of the ACPI tables is one of the things that generates a
> lot of output especially on large systems.
>
> I didn't change ARM, as I wasn't sure how far ahead this call could be
> pulled.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Make sense for me but I think that we should have the same thing for ARM too.

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1187,6 +1187,7 @@ void __init noreturn __start_xen(unsigne
>      }
>
>      vm_init();
> +    console_init_mem();
>      vesa_init();
>
>      softirq_init();
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -744,15 +744,14 @@ void __init console_init_preirq(void)
>      }
>  }
>
> -void __init console_init_postirq(void)
> +void __init console_init_mem(void)
>  {
>      char *ring;
>      unsigned int i, order, memflags;
> -
> -    serial_init_postirq();
> +    unsigned long flags;
>
>      if ( !opt_conring_size )
> -        opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
> +        return;
>
>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
>      memflags = MEMF_bits(crashinfo_maxaddr_bits);
> @@ -763,17 +762,28 @@ void __init console_init_postirq(void)
>      }
>      opt_conring_size = PAGE_SIZE << order;
>
> -    spin_lock_irq(&console_lock);
> +    spin_lock_irqsave(&console_lock, flags);

I am not sure why are you change spin_lock_irq() to spin_lock_irqsave() here.
Could you explain this in commit message?

>      for ( i = conringc ; i != conringp; i++ )
>          ring[i & (opt_conring_size - 1)] = conring[i & (conring_size - 1)];
>      conring = ring;
>      smp_wmb(); /* Allow users of console_force_unlock() to see larger buffer. */
>      conring_size = opt_conring_size;
> -    spin_unlock_irq(&console_lock);
> +    spin_unlock_irqrestore(&console_lock, flags);

Ditto.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 17:23:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 17:23:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwwb1-0001uV-Hx; Fri, 05 Dec 2014 17:23:11 +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 1Xwwb0-0001u9-Hm
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 17:23:10 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	DD/39-09284-DF9E1845; Fri, 05 Dec 2014 17:23:09 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417800187!11451674!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18320 invoked from network); 5 Dec 2014 17:23:08 -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; 5 Dec 2014 17:23: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 sB5HN3Xq022590
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 17:23:04 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
	sB5HN3Qc005535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 17:23:03 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
	sB5HN2de026082; Fri, 5 Dec 2014 17:23:02 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 09:23:02 -0800
Date: Fri, 5 Dec 2014 18:22:57 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205172257.GC16236@olila.local.net-space.pl>
References: <5481F18C020000780004D535@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481F18C020000780004D535@mail.emea.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 04:55:24PM +0000, Jan Beulich wrote:
> ... when "conring_size=" was specified on the command line. We can't
> really do this as early as we would want to when the option was not
> specified, as the default depends on knowing the system CPU count. Yet
> the parsing of the ACPI tables is one of the things that generates a
> lot of output especially on large systems.
>
> I didn't change ARM, as I wasn't sure how far ahead this call could be
> pulled.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Make sense for me but I think that we should have the same thing for ARM too.

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1187,6 +1187,7 @@ void __init noreturn __start_xen(unsigne
>      }
>
>      vm_init();
> +    console_init_mem();
>      vesa_init();
>
>      softirq_init();
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -744,15 +744,14 @@ void __init console_init_preirq(void)
>      }
>  }
>
> -void __init console_init_postirq(void)
> +void __init console_init_mem(void)
>  {
>      char *ring;
>      unsigned int i, order, memflags;
> -
> -    serial_init_postirq();
> +    unsigned long flags;
>
>      if ( !opt_conring_size )
> -        opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
> +        return;
>
>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
>      memflags = MEMF_bits(crashinfo_maxaddr_bits);
> @@ -763,17 +762,28 @@ void __init console_init_postirq(void)
>      }
>      opt_conring_size = PAGE_SIZE << order;
>
> -    spin_lock_irq(&console_lock);
> +    spin_lock_irqsave(&console_lock, flags);

I am not sure why are you change spin_lock_irq() to spin_lock_irqsave() here.
Could you explain this in commit message?

>      for ( i = conringc ; i != conringp; i++ )
>          ring[i & (opt_conring_size - 1)] = conring[i & (conring_size - 1)];
>      conring = ring;
>      smp_wmb(); /* Allow users of console_force_unlock() to see larger buffer. */
>      conring_size = opt_conring_size;
> -    spin_unlock_irq(&console_lock);
> +    spin_unlock_irqrestore(&console_lock, flags);

Ditto.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 18:00:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 18:00:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwxAO-0003G5-Ln; Fri, 05 Dec 2014 17:59:44 +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 1XwxAM-0003Fy-QM
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 17:59:42 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	10/9C-15461-E82F1845; Fri, 05 Dec 2014 17:59:42 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417802380!13731960!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4764 invoked from network); 5 Dec 2014 17:59:41 -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; 5 Dec 2014 17:59: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 sB5HxX5P002852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 17:59:34 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
	sB5HxWi2023132
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 17:59:33 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
	sB5HxWnY023127; Fri, 5 Dec 2014 17:59:32 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 09:59:32 -0800
Date: Fri, 5 Dec 2014 18:59:27 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205175927.GF16236@olila.local.net-space.pl>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<20141205145117.GX16236@olila.local.net-space.pl>
	<5481D68E020000780004D3AD@mail.emea.novell.com>
	<20141205164016.GB16236@olila.local.net-space.pl>
	<5481F2D4020000780004D543@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481F2D4020000780004D543@mail.emea.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 05:00:52PM +0000, Jan Beulich wrote:
> >>> On 05.12.14 at 17:40, <daniel.kiper@oracle.com> wrote:
> > On Fri, Dec 05, 2014 at 03:00:14PM +0000, Jan Beulich wrote:
> >> but I don't think this possibility of renaming warrants a much longer
> >> discussion. Please also remember that renaming always implies more
> >> cumbersome backporting, even if only slightly more.
> >
> > I suppose that you are thinking about backporting my EFI + multiboot2
> > patches somewhere.
>
> Not really, I was just thinking about bug fixes in general.

OK. So, go or no go for efi-boot.h name change to boot.h (of course
after 4.5 release)? If yes then when? After or before my EFI + multiboot2
patches? I would like to know that in advance because I am going to
release first version next week.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 18:00:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 18:00:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwxAO-0003G5-Ln; Fri, 05 Dec 2014 17:59:44 +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 1XwxAM-0003Fy-QM
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 17:59:42 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	10/9C-15461-E82F1845; Fri, 05 Dec 2014 17:59:42 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417802380!13731960!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4764 invoked from network); 5 Dec 2014 17:59:41 -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; 5 Dec 2014 17:59: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 sB5HxX5P002852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 17:59:34 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
	sB5HxWi2023132
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 17:59:33 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
	sB5HxWnY023127; Fri, 5 Dec 2014 17:59:32 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 09:59:32 -0800
Date: Fri, 5 Dec 2014 18:59:27 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141205175927.GF16236@olila.local.net-space.pl>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<20141205145117.GX16236@olila.local.net-space.pl>
	<5481D68E020000780004D3AD@mail.emea.novell.com>
	<20141205164016.GB16236@olila.local.net-space.pl>
	<5481F2D4020000780004D543@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481F2D4020000780004D543@mail.emea.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 05:00:52PM +0000, Jan Beulich wrote:
> >>> On 05.12.14 at 17:40, <daniel.kiper@oracle.com> wrote:
> > On Fri, Dec 05, 2014 at 03:00:14PM +0000, Jan Beulich wrote:
> >> but I don't think this possibility of renaming warrants a much longer
> >> discussion. Please also remember that renaming always implies more
> >> cumbersome backporting, even if only slightly more.
> >
> > I suppose that you are thinking about backporting my EFI + multiboot2
> > patches somewhere.
>
> Not really, I was just thinking about bug fixes in general.

OK. So, go or no go for efi-boot.h name change to boot.h (of course
after 4.5 release)? If yes then when? After or before my EFI + multiboot2
patches? I would like to know that in advance because I am going to
release first version next week.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 18:04:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 18:04:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwxEU-0003jl-B2; Fri, 05 Dec 2014 18:03:58 +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 1XwxET-0003jg-Bx
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 18:03:57 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FF/2E-25276-C83F1845; Fri, 05 Dec 2014 18:03:56 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417802634!6450635!1
X-Originating-IP: [156.151.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 25134 invoked from network); 5 Dec 2014 18:03:55 -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; 5 Dec 2014 18:03:55 -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 sB5I3pwW022606
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 18:03:52 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
	sB5I3oLk009501
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 18:03:51 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
	sB5I3oe3016047; Fri, 5 Dec 2014 18:03:50 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, 05 Dec 2014 10:03:49 -0800
Message-ID: <5481F3F1.2010701@oracle.com>
Date: Fri, 05 Dec 2014 13:05:37 -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: Thanos Makatos <thanos.makatos@citrix.com>, xen-devel@lists.xenproject.org
References: <1417536806-22562-1-git-send-email-thanos.makatos@citrix.com>
In-Reply-To: <1417536806-22562-1-git-send-email-thanos.makatos@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH v2] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 11:13 AM, 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.
>
> Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>
> ---
>   drivers/xen/gntdev.c      |  171 +++++++++++++++++++++++++++++++++++++++++++++
>   include/uapi/xen/gntdev.h |   69 ++++++++++++++++++
>   2 files changed, 240 insertions(+)
>
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 51f4c95..7b4a8e0 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -705,6 +705,174 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u)
>   	return rc;
>   }
>   
> +static int gntdev_gcopy_batch(int nr_segments, unsigned long gcopy_cb,
> +		struct gntdev_grant_copy_segment __user *__segments, int dir,
> +		int src, int dst) {
> +
> +	static const int batch_size = PAGE_SIZE / (sizeof(struct page*) +
> +		sizeof(struct gnttab_copy) + sizeof(struct gntdev_grant_copy_segment));
> +	struct page **pages = (struct page **)gcopy_cb;
> +	struct gnttab_copy *batch = (struct gnttab_copy *)((unsigned long)pages +
> +			sizeof(struct page*) * batch_size);
> +	struct gntdev_grant_copy_segment *segments =
> +		(struct gntdev_grant_copy_segment *)((unsigned long)batch +
> +				sizeof(struct gnttab_copy) * batch_size);
> +	unsigned int nr_pinned = 0, nr_segs2cp = 0;
> +	int err = 0, i;
> +	const int write = dir == GNTCOPY_IOCTL_g2s;
> +
> +	nr_segments = min(nr_segments, batch_size);
> +
> +	if (unlikely(copy_from_user(segments, __segments,
> +			   sizeof(struct gntdev_grant_copy_segment) * nr_segments))) {
> +		pr_debug("failed to copy %d segments from user", nr_segments);
> +		err = -EFAULT;
> +		goto out;
> +	}
> +
> +	for (i = 0; i < nr_segments; i++) {
> +
> +		xen_pfn_t pgaddr;
> +		unsigned long start, offset;
> +		struct gntdev_grant_copy_segment *seg = &segments[i];
> +
> +		if (dir == GNTCOPY_IOCTL_s2g || dir == GNTCOPY_IOCTL_g2s) {
> +
> +			start = (unsigned long)seg->self.iov.iov_base & PAGE_MASK;
> +			offset = (unsigned long)seg->self.iov.iov_base & ~PAGE_MASK;
> +			if (unlikely(offset + seg->self.iov.iov_len > PAGE_SIZE)) {
> +				pr_warn("segments crossing page boundaries not yet "
> +						"implemented\n");
> +				err = -ENOSYS;
> +				goto out;
> +			}
> +
> +			err = get_user_pages_fast(start, 1, write, &pages[i]);
> +			if (unlikely(err != 1)) {
> +				pr_debug("failed to get user page %lu", start);
> +				err = -EFAULT;
> +				goto out;
> +			}
> +
> +			nr_pinned++;
> +
> +			pgaddr = pfn_to_mfn(page_to_pfn(pages[i]));
> +		}
> +
> +		nr_segs2cp++;
> +
> +		switch (dir) {
> +		case GNTCOPY_IOCTL_g2s: /* copy from guest */
> +			batch[i].len = seg->self.iov.iov_len;
> +			batch[i].source.u.ref = seg->self.ref;
> +			batch[i].source.domid = src;
> +			batch[i].source.offset = seg->self.offset;
> +			batch[i].dest.u.gmfn = pgaddr;
> +			batch[i].dest.domid = DOMID_SELF;
> +			batch[i].dest.offset = offset;
> +			batch[i].flags = GNTCOPY_source_gref;
> +			break;
> +		case GNTCOPY_IOCTL_s2g: /* copy to guest */
> +			batch[i].len = seg->self.iov.iov_len;
> +			batch[i].source.u.gmfn = pgaddr;
> +			batch[i].source.domid = DOMID_SELF;
> +			batch[i].source.offset = offset;
> +			batch[i].dest.u.ref = seg->self.ref;
> +			batch[i].dest.domid = dst;
> +			batch[i].dest.offset = seg->self.offset;
> +			batch[i].flags = GNTCOPY_dest_gref;
> +			break;
> +		case GNTCOPY_IOCTL_g2g: /* copy guest to guest */
> +			batch[i].len = seg->g2g.len;
> +			batch[i].source.u.ref = seg->g2g.src.ref;
> +			batch[i].source.domid = src;
> +			batch[i].source.offset = seg->g2g.src.offset;
> +			batch[i].dest.u.ref = seg->g2g.dst.ref;
> +			batch[i].dest.domid = dst;
> +			batch[i].dest.offset = seg->g2g.dst.offset;
> +			batch[i].flags = GNTCOPY_source_gref | GNTCOPY_dest_gref;
> +			break;
> +		default:
> +			pr_debug("invalid grant-copy direction %d\n", dir);
> +			err = -EINVAL;
> +			goto out;
> +		}
> +	}
> +
> +	gnttab_batch_copy(batch, nr_segs2cp);
> +	for (i = 0; i < nr_segs2cp; i++) {

Can nr_segs2cp be not equal to nr_segments here? If you got to this 
point you have gone through the full loop.

> +		err = put_user(batch[i].status, &__segments[i].status);
> +		if (unlikely(err)) {
> +			pr_debug("failed to copy error code %d to user: %d\n",
> +					batch[i].status, err);
> +			goto out;
> +		}
> +	}
> +
> +out:
> +	for (i = 0; i < nr_pinned; i++)
> +		put_page(pages[i]);
> +
> +	if (unlikely(err))
> +		return err;
> +
> +	return nr_segs2cp;

And I think here it can be either 0 (which is the case of an error) or 
nr_segments. If you error out of the 'for' loop you haven't actually 
copied anything, even though nr_segs2cp might be non-zero.


-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 18:04:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 18:04:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwxEU-0003jl-B2; Fri, 05 Dec 2014 18:03:58 +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 1XwxET-0003jg-Bx
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 18:03:57 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FF/2E-25276-C83F1845; Fri, 05 Dec 2014 18:03:56 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417802634!6450635!1
X-Originating-IP: [156.151.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 25134 invoked from network); 5 Dec 2014 18:03:55 -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; 5 Dec 2014 18:03:55 -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 sB5I3pwW022606
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 18:03:52 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
	sB5I3oLk009501
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 18:03:51 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
	sB5I3oe3016047; Fri, 5 Dec 2014 18:03:50 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, 05 Dec 2014 10:03:49 -0800
Message-ID: <5481F3F1.2010701@oracle.com>
Date: Fri, 05 Dec 2014 13:05:37 -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: Thanos Makatos <thanos.makatos@citrix.com>, xen-devel@lists.xenproject.org
References: <1417536806-22562-1-git-send-email-thanos.makatos@citrix.com>
In-Reply-To: <1417536806-22562-1-git-send-email-thanos.makatos@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH v2] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/02/2014 11:13 AM, 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.
>
> Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>
> ---
>   drivers/xen/gntdev.c      |  171 +++++++++++++++++++++++++++++++++++++++++++++
>   include/uapi/xen/gntdev.h |   69 ++++++++++++++++++
>   2 files changed, 240 insertions(+)
>
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 51f4c95..7b4a8e0 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -705,6 +705,174 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u)
>   	return rc;
>   }
>   
> +static int gntdev_gcopy_batch(int nr_segments, unsigned long gcopy_cb,
> +		struct gntdev_grant_copy_segment __user *__segments, int dir,
> +		int src, int dst) {
> +
> +	static const int batch_size = PAGE_SIZE / (sizeof(struct page*) +
> +		sizeof(struct gnttab_copy) + sizeof(struct gntdev_grant_copy_segment));
> +	struct page **pages = (struct page **)gcopy_cb;
> +	struct gnttab_copy *batch = (struct gnttab_copy *)((unsigned long)pages +
> +			sizeof(struct page*) * batch_size);
> +	struct gntdev_grant_copy_segment *segments =
> +		(struct gntdev_grant_copy_segment *)((unsigned long)batch +
> +				sizeof(struct gnttab_copy) * batch_size);
> +	unsigned int nr_pinned = 0, nr_segs2cp = 0;
> +	int err = 0, i;
> +	const int write = dir == GNTCOPY_IOCTL_g2s;
> +
> +	nr_segments = min(nr_segments, batch_size);
> +
> +	if (unlikely(copy_from_user(segments, __segments,
> +			   sizeof(struct gntdev_grant_copy_segment) * nr_segments))) {
> +		pr_debug("failed to copy %d segments from user", nr_segments);
> +		err = -EFAULT;
> +		goto out;
> +	}
> +
> +	for (i = 0; i < nr_segments; i++) {
> +
> +		xen_pfn_t pgaddr;
> +		unsigned long start, offset;
> +		struct gntdev_grant_copy_segment *seg = &segments[i];
> +
> +		if (dir == GNTCOPY_IOCTL_s2g || dir == GNTCOPY_IOCTL_g2s) {
> +
> +			start = (unsigned long)seg->self.iov.iov_base & PAGE_MASK;
> +			offset = (unsigned long)seg->self.iov.iov_base & ~PAGE_MASK;
> +			if (unlikely(offset + seg->self.iov.iov_len > PAGE_SIZE)) {
> +				pr_warn("segments crossing page boundaries not yet "
> +						"implemented\n");
> +				err = -ENOSYS;
> +				goto out;
> +			}
> +
> +			err = get_user_pages_fast(start, 1, write, &pages[i]);
> +			if (unlikely(err != 1)) {
> +				pr_debug("failed to get user page %lu", start);
> +				err = -EFAULT;
> +				goto out;
> +			}
> +
> +			nr_pinned++;
> +
> +			pgaddr = pfn_to_mfn(page_to_pfn(pages[i]));
> +		}
> +
> +		nr_segs2cp++;
> +
> +		switch (dir) {
> +		case GNTCOPY_IOCTL_g2s: /* copy from guest */
> +			batch[i].len = seg->self.iov.iov_len;
> +			batch[i].source.u.ref = seg->self.ref;
> +			batch[i].source.domid = src;
> +			batch[i].source.offset = seg->self.offset;
> +			batch[i].dest.u.gmfn = pgaddr;
> +			batch[i].dest.domid = DOMID_SELF;
> +			batch[i].dest.offset = offset;
> +			batch[i].flags = GNTCOPY_source_gref;
> +			break;
> +		case GNTCOPY_IOCTL_s2g: /* copy to guest */
> +			batch[i].len = seg->self.iov.iov_len;
> +			batch[i].source.u.gmfn = pgaddr;
> +			batch[i].source.domid = DOMID_SELF;
> +			batch[i].source.offset = offset;
> +			batch[i].dest.u.ref = seg->self.ref;
> +			batch[i].dest.domid = dst;
> +			batch[i].dest.offset = seg->self.offset;
> +			batch[i].flags = GNTCOPY_dest_gref;
> +			break;
> +		case GNTCOPY_IOCTL_g2g: /* copy guest to guest */
> +			batch[i].len = seg->g2g.len;
> +			batch[i].source.u.ref = seg->g2g.src.ref;
> +			batch[i].source.domid = src;
> +			batch[i].source.offset = seg->g2g.src.offset;
> +			batch[i].dest.u.ref = seg->g2g.dst.ref;
> +			batch[i].dest.domid = dst;
> +			batch[i].dest.offset = seg->g2g.dst.offset;
> +			batch[i].flags = GNTCOPY_source_gref | GNTCOPY_dest_gref;
> +			break;
> +		default:
> +			pr_debug("invalid grant-copy direction %d\n", dir);
> +			err = -EINVAL;
> +			goto out;
> +		}
> +	}
> +
> +	gnttab_batch_copy(batch, nr_segs2cp);
> +	for (i = 0; i < nr_segs2cp; i++) {

Can nr_segs2cp be not equal to nr_segments here? If you got to this 
point you have gone through the full loop.

> +		err = put_user(batch[i].status, &__segments[i].status);
> +		if (unlikely(err)) {
> +			pr_debug("failed to copy error code %d to user: %d\n",
> +					batch[i].status, err);
> +			goto out;
> +		}
> +	}
> +
> +out:
> +	for (i = 0; i < nr_pinned; i++)
> +		put_page(pages[i]);
> +
> +	if (unlikely(err))
> +		return err;
> +
> +	return nr_segs2cp;

And I think here it can be either 0 (which is the case of an error) or 
nr_segments. If you error out of the 'for' loop you haven't actually 
copied anything, even though nr_segs2cp might be non-zero.


-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 18:22:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 18:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwxW8-0004Qb-1e; Fri, 05 Dec 2014 18:22:12 +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 1XwxW6-0004QW-LM
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 18:22:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F8/6B-09842-2D7F1845; Fri, 05 Dec 2014 18:22:10 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417803729!13737132!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28411 invoked from network); 5 Dec 2014 18:22:09 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 18:22:09 -0000
Received: from dezo.moloch.sk (unknown [92.240.231.146])
	by mail.moloch.sk (Postfix) with ESMTPSA id B3BA8180AC28;
	Fri,  5 Dec 2014 19:22:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1417803728;
	bh=sISitOy2/HHFy3J9suxjQ1+tKo+Xmdyg+5WUTPcHwjo=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=p+ltSFWFrx7yjBdoLGET2RxBuar6+iUKgyYUx3E4+J1AcvJBNFMVtre9SGfD8DYHx
	9SyHo4Pwan5NkGW/WfP6ms8J39H76AWdPLKwQMkfOeuMnzEEb6sHYjPEBEtaaR6Gu2
	9FjeMTrWWUDu/zDP2X/YIkEdo7DZuFRL41JNcy+wpJDPZoDKSQzTgXTP2bZqFqS/U1
	HwS3xqsVO91qLJHubokMPHympgk8o/cuaFeWdYXgIos/MP9vVixbDlnHpIlL0Ebbz/
	7ElscBQRAOFkWaVSkRcOeq+tWHhQecKgCy3Up/ji3WJen6uBtyvclVXZyT4rxou8ab
	SGBSvhO/dAeoA==
Received: by dezo.moloch.sk (Postfix, from userid 1000)
	id 67217D05952E; Fri,  5 Dec 2014 19:22:08 +0100 (CET)
Date: Fri, 5 Dec 2014 19:22:08 +0100
From: Martin Lucina <martin@lucina.net>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141205182208.GC19077@dezo.moloch.sk>
Mail-Followup-To: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54807253.5000603@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.cooper3@citrix.com said:
> I think this is a very good idea, and I am completely in favour of it.
> 
> There are already-identified issues such as MiniOS leaking things like
> ARRAY_SIZE() into linked namespaces, which I havn't yet had enough tuits
> to fix.
> 
> I think splitting things like the stub libc away from the "MiniOS Xen
> Framework" is also a good idea.  Ideally, the result of a "MiniOS Build"
> would be a small set of .a's which can then be linked against some
> normal C to make a minios guest.  (How feasible this is in reality
> remains to be seen.)

The approach I used for rumprun-xen is to link all of MiniOS' object files
except the startfile into a final .o with "ld -r". This then allows me to
use "objcopy -w -GPREFIX..." to make all symbols in minios.o *except* those
starting with PREFIX local.

This has the advantage that I only had to rename symbols I really wanted to
keep global rather than going through all the MiniOS code adding "static"
in places where it was missing and sorting out the resulting
inter-dependencies.

> From a not-public-API point of view, all you have to worry about is that
> the existing minios stuff in xen.git, including the stubdom stuff,
> continues to work.  We have never made any guarantees to anyone using
> minios out-of-tree.

"Existing minios stuff" meaning the default build of extras/mini-os?

What's up with the -DHAVE_LIBC codepaths in mini-os? Who or what uses
these? Grepping around in stubdom/ doesn't come up with anything...

"Stubdom stuff" meaning the default build of stubdom/, plus the "make
c-stubdom" and "make caml-stubdom" examples documented in README?

Anything else? Sorry if this is obvious but I'm not that familiar with all
of xen.git.

Thanks,

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 18:22:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 18:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XwxW8-0004Qb-1e; Fri, 05 Dec 2014 18:22:12 +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 1XwxW6-0004QW-LM
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 18:22:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F8/6B-09842-2D7F1845; Fri, 05 Dec 2014 18:22:10 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417803729!13737132!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28411 invoked from network); 5 Dec 2014 18:22:09 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 18:22:09 -0000
Received: from dezo.moloch.sk (unknown [92.240.231.146])
	by mail.moloch.sk (Postfix) with ESMTPSA id B3BA8180AC28;
	Fri,  5 Dec 2014 19:22:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1417803728;
	bh=sISitOy2/HHFy3J9suxjQ1+tKo+Xmdyg+5WUTPcHwjo=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=p+ltSFWFrx7yjBdoLGET2RxBuar6+iUKgyYUx3E4+J1AcvJBNFMVtre9SGfD8DYHx
	9SyHo4Pwan5NkGW/WfP6ms8J39H76AWdPLKwQMkfOeuMnzEEb6sHYjPEBEtaaR6Gu2
	9FjeMTrWWUDu/zDP2X/YIkEdo7DZuFRL41JNcy+wpJDPZoDKSQzTgXTP2bZqFqS/U1
	HwS3xqsVO91qLJHubokMPHympgk8o/cuaFeWdYXgIos/MP9vVixbDlnHpIlL0Ebbz/
	7ElscBQRAOFkWaVSkRcOeq+tWHhQecKgCy3Up/ji3WJen6uBtyvclVXZyT4rxou8ab
	SGBSvhO/dAeoA==
Received: by dezo.moloch.sk (Postfix, from userid 1000)
	id 67217D05952E; Fri,  5 Dec 2014 19:22:08 +0100 (CET)
Date: Fri, 5 Dec 2014 19:22:08 +0100
From: Martin Lucina <martin@lucina.net>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141205182208.GC19077@dezo.moloch.sk>
Mail-Followup-To: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54807253.5000603@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy <anil@recoil.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.cooper3@citrix.com said:
> I think this is a very good idea, and I am completely in favour of it.
> 
> There are already-identified issues such as MiniOS leaking things like
> ARRAY_SIZE() into linked namespaces, which I havn't yet had enough tuits
> to fix.
> 
> I think splitting things like the stub libc away from the "MiniOS Xen
> Framework" is also a good idea.  Ideally, the result of a "MiniOS Build"
> would be a small set of .a's which can then be linked against some
> normal C to make a minios guest.  (How feasible this is in reality
> remains to be seen.)

The approach I used for rumprun-xen is to link all of MiniOS' object files
except the startfile into a final .o with "ld -r". This then allows me to
use "objcopy -w -GPREFIX..." to make all symbols in minios.o *except* those
starting with PREFIX local.

This has the advantage that I only had to rename symbols I really wanted to
keep global rather than going through all the MiniOS code adding "static"
in places where it was missing and sorting out the resulting
inter-dependencies.

> From a not-public-API point of view, all you have to worry about is that
> the existing minios stuff in xen.git, including the stubdom stuff,
> continues to work.  We have never made any guarantees to anyone using
> minios out-of-tree.

"Existing minios stuff" meaning the default build of extras/mini-os?

What's up with the -DHAVE_LIBC codepaths in mini-os? Who or what uses
these? Grepping around in stubdom/ doesn't come up with anything...

"Stubdom stuff" meaning the default build of stubdom/, plus the "make
c-stubdom" and "make caml-stubdom" examples documented in README?

Anything else? Sorry if this is obvious but I'm not that familiar with all
of xen.git.

Thanks,

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 18:27:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 18: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 1Xwxb9-0004YN-Pf; Fri, 05 Dec 2014 18:27:23 +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 1Xwxb8-0004YG-Fh
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 18:27:22 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	62/63-26740-909F1845; Fri, 05 Dec 2014 18:27:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417804039!8986343!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16629 invoked from network); 5 Dec 2014 18:27:20 -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; 5 Dec 2014 18:27: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 sB5IR6Jm003533
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 18:27: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
	sB5IR571022171
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 5 Dec 2014 18:27:06 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
	sB5IR4lC027188; Fri, 5 Dec 2014 18:27:04 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 10:27:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E895F11FAAF; Fri,  5 Dec 2014 13:27:02 -0500 (EST)
Date: Fri, 5 Dec 2014 13:27:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zoltan Kiss <zoltan.kiss@linaro.org>
Message-ID: <20141205182702.GA4754@laptop.dumpdata.com>
References: <3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
	<54806315.6010007@linaro.org>
	<3A6795EA1206904E94BEC8EF9DF109AE23933926@SZXEMA512-MBX.china.huawei.com>
	<5481CD57.607@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481CD57.607@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Zhangleiqiang \(Trump\)" <zhangleiqiang@huawei.com>,
	jonathan.davies@citrix.com, "Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 03:20:55PM +0000, Zoltan Kiss wrote:
> 
> 
> On 04/12/14 14:31, Zhangleiqiang (Trump) wrote:
> >>-----Original Message-----
> >>From: Zoltan Kiss [mailto:zoltan.kiss@linaro.org]
> >>Sent: Thursday, December 04, 2014 9:35 PM
> >>To: Zhangleiqiang (Trump); Wei Liu; xen-devel@lists.xen.org
> >>Cc: Xiaoding (B); Zhuangyuxin; zhangleiqiang; Luohao (brian); Yuzhou (C)
> >>Subject: Re: [Xen-devel] Poor network performance between DomU with
> >>multiqueue support
> >>
> >>
> >>
> >>On 04/12/14 12:09, Zhangleiqiang (Trump) wrote:
> >>>>I think that's expected, because guest RX data path still uses
> >>>>grant_copy while
> >>>>>guest TX uses grant_map to do zero-copy transmit.
> >>>As I understand, the RX process is as follows:
> >>>1. Phy NIC receive packet
> >>>2. XEN Hypervisor trigger interrupt to Dom0 3. Dom0' s NIC driver do
> >>>the "RX" operation, and the packet is stored into SKB which is also
> >>>owned/shared with netback
> >>Not that easy. There is something between the NIC driver and netback which
> >>directs the packets, e.g. the old bridge driver, ovs, or the IP stack of the kernel.
> >>>4. NetBack notify netfront through event channel that a packet is
> >>>receiving 5. Netfront grant a buffer for receiving and notify netback
> >>>the GR (if using grant-resue mechanism, netfront just notify the GR to
> >>>netback) through IO Ring
> >>It looks a bit confusing in the code, but netfront put "requests" on the ring
> >>buffer, which contains the grant ref of the guest page where the backend can
> >>copy. When the packet comes, netback consumes these requests and send
> >>back a response telling the guest the grant copy of the packet finished, it can
> >>start handling the data. (sending a response means it's placing a response in
> >>the ring and trigger the event channel) And ideally netback should always have
> >>requests in the ring, so it doesn't have to wait for the guest to fill it up.
> >
> >>>6. NetBack do the grant_copy to copy packet from its SKB to the buffer
> >>>referenced by GR, and notify netfront through event channel 7.
> >>>Netfront copy the data from buffer to user-level app's SKB
> >>Or wherever that SKB should go, yes. Like with any received packet on a real
> >>network interface.
> >>>
> >>>Am I right? Why not using zero-copy transmit in guest RX data pash too ?
> >>Because that means you are mapping that memory to the guest, and you won't
> >>have any guarantee when the guest will release them. And netback can't just
> >>unmap them forcibly after a timeout, because finding a correct timeout value
> >>would be quite impossible.
> >>A malicious/buggy/overloaded guest can hold on to Dom0 memory indefinitely,
> >>but it even becomes worse if the memory came from another
> >>guest: you can't shutdown that guest for example, until all its memory is
> >>returned to him.
> >
> >Thanks for your detailed explanation about RX data path, I have get it, :)
> >
> >About the issue that poor performance between DomU to DomU, but high throughout between Dom0 to remote Dom0/DomU mentioned in my previous mail, do you have any idea about it?
> >
> >I am wondering if netfront/netback can be optimized to reach the 10Gbps throughout between DomUs running on different hosts connected with 10GE network. Currently, it seems like the TX is not the bottleneck, because we can reach the aggregate throughout of 9Gbps when sending packets from one DomU to other 3 DomUs running on different host. So I think the bottleneck maybe the RX, are you agreed with me?
> >
> >I am wondering what is the main reason that prevent RX to reach the higher throughout? Compared to KVM+virtio+vhost, which can reach high throughout, the RX has extra grantcopy operation, and the grantcopy operation may be one reason for it. Do you have any idea about it too?
> It's quite sure that the grant copy is the bottleneck for a single queue RX
> traffic. I don't know what's the plan to help that, currently only a faster
> CPU can help you with that.

Could the Intel QuickData help with that?
> 
> >
> >>
> >>Regards,
> >>
> >>Zoli
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 05 18:27:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 18: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 1Xwxb9-0004YN-Pf; Fri, 05 Dec 2014 18:27:23 +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 1Xwxb8-0004YG-Fh
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 18:27:22 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	62/63-26740-909F1845; Fri, 05 Dec 2014 18:27:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1417804039!8986343!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16629 invoked from network); 5 Dec 2014 18:27:20 -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; 5 Dec 2014 18:27: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 sB5IR6Jm003533
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 18:27: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
	sB5IR571022171
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 5 Dec 2014 18:27:06 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
	sB5IR4lC027188; Fri, 5 Dec 2014 18:27:04 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 10:27:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E895F11FAAF; Fri,  5 Dec 2014 13:27:02 -0500 (EST)
Date: Fri, 5 Dec 2014 13:27:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zoltan Kiss <zoltan.kiss@linaro.org>
Message-ID: <20141205182702.GA4754@laptop.dumpdata.com>
References: <3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
	<54806315.6010007@linaro.org>
	<3A6795EA1206904E94BEC8EF9DF109AE23933926@SZXEMA512-MBX.china.huawei.com>
	<5481CD57.607@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481CD57.607@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Zhangleiqiang \(Trump\)" <zhangleiqiang@huawei.com>,
	jonathan.davies@citrix.com, "Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 03:20:55PM +0000, Zoltan Kiss wrote:
> 
> 
> On 04/12/14 14:31, Zhangleiqiang (Trump) wrote:
> >>-----Original Message-----
> >>From: Zoltan Kiss [mailto:zoltan.kiss@linaro.org]
> >>Sent: Thursday, December 04, 2014 9:35 PM
> >>To: Zhangleiqiang (Trump); Wei Liu; xen-devel@lists.xen.org
> >>Cc: Xiaoding (B); Zhuangyuxin; zhangleiqiang; Luohao (brian); Yuzhou (C)
> >>Subject: Re: [Xen-devel] Poor network performance between DomU with
> >>multiqueue support
> >>
> >>
> >>
> >>On 04/12/14 12:09, Zhangleiqiang (Trump) wrote:
> >>>>I think that's expected, because guest RX data path still uses
> >>>>grant_copy while
> >>>>>guest TX uses grant_map to do zero-copy transmit.
> >>>As I understand, the RX process is as follows:
> >>>1. Phy NIC receive packet
> >>>2. XEN Hypervisor trigger interrupt to Dom0 3. Dom0' s NIC driver do
> >>>the "RX" operation, and the packet is stored into SKB which is also
> >>>owned/shared with netback
> >>Not that easy. There is something between the NIC driver and netback which
> >>directs the packets, e.g. the old bridge driver, ovs, or the IP stack of the kernel.
> >>>4. NetBack notify netfront through event channel that a packet is
> >>>receiving 5. Netfront grant a buffer for receiving and notify netback
> >>>the GR (if using grant-resue mechanism, netfront just notify the GR to
> >>>netback) through IO Ring
> >>It looks a bit confusing in the code, but netfront put "requests" on the ring
> >>buffer, which contains the grant ref of the guest page where the backend can
> >>copy. When the packet comes, netback consumes these requests and send
> >>back a response telling the guest the grant copy of the packet finished, it can
> >>start handling the data. (sending a response means it's placing a response in
> >>the ring and trigger the event channel) And ideally netback should always have
> >>requests in the ring, so it doesn't have to wait for the guest to fill it up.
> >
> >>>6. NetBack do the grant_copy to copy packet from its SKB to the buffer
> >>>referenced by GR, and notify netfront through event channel 7.
> >>>Netfront copy the data from buffer to user-level app's SKB
> >>Or wherever that SKB should go, yes. Like with any received packet on a real
> >>network interface.
> >>>
> >>>Am I right? Why not using zero-copy transmit in guest RX data pash too ?
> >>Because that means you are mapping that memory to the guest, and you won't
> >>have any guarantee when the guest will release them. And netback can't just
> >>unmap them forcibly after a timeout, because finding a correct timeout value
> >>would be quite impossible.
> >>A malicious/buggy/overloaded guest can hold on to Dom0 memory indefinitely,
> >>but it even becomes worse if the memory came from another
> >>guest: you can't shutdown that guest for example, until all its memory is
> >>returned to him.
> >
> >Thanks for your detailed explanation about RX data path, I have get it, :)
> >
> >About the issue that poor performance between DomU to DomU, but high throughout between Dom0 to remote Dom0/DomU mentioned in my previous mail, do you have any idea about it?
> >
> >I am wondering if netfront/netback can be optimized to reach the 10Gbps throughout between DomUs running on different hosts connected with 10GE network. Currently, it seems like the TX is not the bottleneck, because we can reach the aggregate throughout of 9Gbps when sending packets from one DomU to other 3 DomUs running on different host. So I think the bottleneck maybe the RX, are you agreed with me?
> >
> >I am wondering what is the main reason that prevent RX to reach the higher throughout? Compared to KVM+virtio+vhost, which can reach high throughout, the RX has extra grantcopy operation, and the grantcopy operation may be one reason for it. Do you have any idea about it too?
> It's quite sure that the grant copy is the bottleneck for a single queue RX
> traffic. I don't know what's the plan to help that, currently only a faster
> CPU can help you with that.

Could the Intel QuickData help with that?
> 
> >
> >>
> >>Regards,
> >>
> >>Zoli
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 05 18:32:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 18: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 1XwxfZ-0004kV-Fa; Fri, 05 Dec 2014 18:31:57 +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 1XwxfX-0004kQ-RJ
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 18:31:55 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	DE/4E-02699-B1AF1845; Fri, 05 Dec 2014 18:31:55 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417804314!13340738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30663 invoked from network); 5 Dec 2014 18:31:54 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 18:31:54 -0000
Received: from dezo.moloch.sk (unknown [92.240.231.146])
	by mail.moloch.sk (Postfix) with ESMTPSA id C6508180AC28;
	Fri,  5 Dec 2014 19:31:53 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1417804313;
	bh=lFk0gtvDr7yuUwaWVfy0ikAWHIiSXXm37ynkDM5c3uI=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=tIvYTu3Aetk4IefanrzRdrh0SCmpycr+/DsjrkIVn1aakrGagDKRJuULtwN/kKApc
	LZit+ogerMQTPZh5CoZO4srI7MVuCjZXrkg1tPS8hxWEnVHzKtaMLvr113SOKihOQI
	7Xp0cI22jg7+bDttFqsNKiDMJVcLL7Sabc7QnphKNINc+MgA3tDDTswF6sm0azSNjP
	AJk759D5qr6WtG/ZOftLWV5M35bLAse3aFDPtQadYHaOLr7rR/BEAWaWqsYRwZH+pq
	YE9tA+ciPUWUUrbmqa/hKWSIGKbSg6f4vhZYqOdi0GFvCJjMRkGrMgyyKL54zs26GS
	c/Pc+HjzsWHiQ==
Received: by dezo.moloch.sk (Postfix, from userid 1000)
	id 80D99D05952E; Fri,  5 Dec 2014 19:31:53 +0100 (CET)
Date: Fri, 5 Dec 2014 19:31:53 +0100
From: Martin Lucina <martin@lucina.net>
To: Antti Kantee <pooka@iki.fi>
Message-ID: <20141205183153.GD19077@dezo.moloch.sk>
Mail-Followup-To: Antti Kantee <pooka@iki.fi>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5480E595.1010204@iki.fi>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy <anil@recoil.org>,
	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,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:
> I wonder if work is minimized if we attempt to merge before or after
> we (I?) take the carving knife for a second round in the rumprun-xen
> repo to minimize MiniOS to run only on top of itself.

Before, I think. Minimizing our copy of Mini-OS duplicates what we would
need to do to the upstream copy.

I think the steps are roughly as follows:

  a) split the current rumprun-xen build out of the Mini-OS Makefile.
  b) replace our fork of Mini-OS with the vanilla upstream Mini-OS.
  c) re-apply my work and your work, while checking things keep working
  with upstream xen.git, until we get rumprun-xen working again.

c) will leave us with a set of patches to upstream.

Does this make sense? It's a fair amount of work but mostly retracing steps
we've already done.

It'd help if we had a full list of "what exactly needs to keep working
upstream", see my other reply to Andrew. Maybe also osstest building and
running Mini-OS related tests off our branch while we do the work? (Ian:
ping? Doable?)

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 18:32:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 18: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 1XwxfZ-0004kV-Fa; Fri, 05 Dec 2014 18:31:57 +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 1XwxfX-0004kQ-RJ
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 18:31:55 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	DE/4E-02699-B1AF1845; Fri, 05 Dec 2014 18:31:55 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-15.tower-27.messagelabs.com!1417804314!13340738!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30663 invoked from network); 5 Dec 2014 18:31:54 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 18:31:54 -0000
Received: from dezo.moloch.sk (unknown [92.240.231.146])
	by mail.moloch.sk (Postfix) with ESMTPSA id C6508180AC28;
	Fri,  5 Dec 2014 19:31:53 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1417804313;
	bh=lFk0gtvDr7yuUwaWVfy0ikAWHIiSXXm37ynkDM5c3uI=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=tIvYTu3Aetk4IefanrzRdrh0SCmpycr+/DsjrkIVn1aakrGagDKRJuULtwN/kKApc
	LZit+ogerMQTPZh5CoZO4srI7MVuCjZXrkg1tPS8hxWEnVHzKtaMLvr113SOKihOQI
	7Xp0cI22jg7+bDttFqsNKiDMJVcLL7Sabc7QnphKNINc+MgA3tDDTswF6sm0azSNjP
	AJk759D5qr6WtG/ZOftLWV5M35bLAse3aFDPtQadYHaOLr7rR/BEAWaWqsYRwZH+pq
	YE9tA+ciPUWUUrbmqa/hKWSIGKbSg6f4vhZYqOdi0GFvCJjMRkGrMgyyKL54zs26GS
	c/Pc+HjzsWHiQ==
Received: by dezo.moloch.sk (Postfix, from userid 1000)
	id 80D99D05952E; Fri,  5 Dec 2014 19:31:53 +0100 (CET)
Date: Fri, 5 Dec 2014 19:31:53 +0100
From: Martin Lucina <martin@lucina.net>
To: Antti Kantee <pooka@iki.fi>
Message-ID: <20141205183153.GD19077@dezo.moloch.sk>
Mail-Followup-To: Antti Kantee <pooka@iki.fi>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5480E595.1010204@iki.fi>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy <anil@recoil.org>,
	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,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:
> I wonder if work is minimized if we attempt to merge before or after
> we (I?) take the carving knife for a second round in the rumprun-xen
> repo to minimize MiniOS to run only on top of itself.

Before, I think. Minimizing our copy of Mini-OS duplicates what we would
need to do to the upstream copy.

I think the steps are roughly as follows:

  a) split the current rumprun-xen build out of the Mini-OS Makefile.
  b) replace our fork of Mini-OS with the vanilla upstream Mini-OS.
  c) re-apply my work and your work, while checking things keep working
  with upstream xen.git, until we get rumprun-xen working again.

c) will leave us with a set of patches to upstream.

Does this make sense? It's a fair amount of work but mostly retracing steps
we've already done.

It'd help if we had a full list of "what exactly needs to keep working
upstream", see my other reply to Andrew. Maybe also osstest building and
running Mini-OS related tests off our branch while we do the work? (Ian:
ping? Doable?)

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 19:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 19: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 1XwyEj-00061L-KA; Fri, 05 Dec 2014 19:08:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkoch@verizon.com>) id 1XwyEi-00061G-3M
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 19:08:16 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	40/DB-26652-F9202845; Fri, 05 Dec 2014 19:08:15 +0000
X-Env-Sender: dkoch@verizon.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417806493!4259915!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25842 invoked from network); 5 Dec 2014 19:08:14 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 19:08:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dkoch@verizon.com; q=dns/txt; s=corp;
	t=1417806495; x=1449342495;
	h=date:from:to:cc:subject:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=HGNTyUlZcVIC+WFtrw0vsCohNRZBYg5F+NuKgu+n28I=;
	b=tmB5bKM7j5EzhW9L7swLyni6+UyX8K2ggNn/aNxBFmlcGISpVZ4AeWkn
	dIPbDVuIUdUBfK/zExWKiQl6gKsvgFtks1Z7V5rWhQvGidk/zza1XJLEb
	e0rTFsKs+bBo8rdPtjz6sy2DUF5Uv0nrtPvVmgz/zmuDiZjS60xdUxrsk k=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 05 Dec 2014 19:08:13 +0000
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,523,1413244800"; d="scan'208";a="922404382"
Received: from unknown (HELO yoyo) ([70.105.111.45])
	by fldsmtpi01.verizon.com with SMTP; 05 Dec 2014 19:08:11 +0000
Date: Fri, 5 Dec 2014 14:08:11 -0500
From: Don Koch <dkoch@verizon.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20141205140811.4faf0ab5c3001e1262bf1206@verizon.com>
In-Reply-To: <1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: Sylpheed 3.4.0beta6 (GTK+ 2.24.22; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Cc: libvir-list@redhat.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Not really familiar with libvirt, but...

On Fri, 5 Dec 2014 16:30:06 +0000
Anthony PERARD <anthony.perard@citrix.com> wrote:

> The path to the pty of a Xen PV console is set only in
> virDomainOpenConsole. But this is done too late. A call to
> virDomainGetXMLDesc done before OpenConsole will not have the path to
> the pty, but a call after OpenConsole will.
> 
> e.g. of the current issue.
> Starting a domain with '<console type="pty"/>'
> Then:
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty'>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> virDomainOpenConsole()
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty' tty='/dev/pts/30'>
>       <source path='/dev/pts/30'/>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> 
> The patch intend to get the tty path on the first call of GetXMLDesc.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  src/libxl/libxl_domain.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 9c62291..de56054 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
>      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
>          goto cleanup_dom;
>  
> +    if (vm->def->nconsoles) {
> +        virDomainChrDefPtr chr = NULL;

Pointless initializer. Possibly combine with following statement.

-d

> +        chr = vm->def->consoles[0];
> +        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
> +            libxl_console_type console_type;
> +            char *console = NULL;
> +            console_type =
> +                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
> +                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
> +            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
> +                                        console_type, &console);
> +            if (!ret)
> +                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
> +            VIR_FREE(console);
> +        }
> +    }
> +
>      if (!start_paused) {
>          libxl_domain_unpause(priv->ctx, domid);
>          virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED);
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 19:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 19: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 1XwyEj-00061L-KA; Fri, 05 Dec 2014 19:08:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkoch@verizon.com>) id 1XwyEi-00061G-3M
	for xen-devel@lists.xen.org; Fri, 05 Dec 2014 19:08:16 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	40/DB-26652-F9202845; Fri, 05 Dec 2014 19:08:15 +0000
X-Env-Sender: dkoch@verizon.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1417806493!4259915!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25842 invoked from network); 5 Dec 2014 19:08:14 -0000
Received: from omzsmtpe04.verizonbusiness.com (HELO
	omzsmtpe04.verizonbusiness.com) (199.249.25.207)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 19:08:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dkoch@verizon.com; q=dns/txt; s=corp;
	t=1417806495; x=1449342495;
	h=date:from:to:cc:subject:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=HGNTyUlZcVIC+WFtrw0vsCohNRZBYg5F+NuKgu+n28I=;
	b=tmB5bKM7j5EzhW9L7swLyni6+UyX8K2ggNn/aNxBFmlcGISpVZ4AeWkn
	dIPbDVuIUdUBfK/zExWKiQl6gKsvgFtks1Z7V5rWhQvGidk/zza1XJLEb
	e0rTFsKs+bBo8rdPtjz6sy2DUF5Uv0nrtPvVmgz/zmuDiZjS60xdUxrsk k=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by omzsmtpe04.verizonbusiness.com with ESMTP; 05 Dec 2014 19:08:13 +0000
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,523,1413244800"; d="scan'208";a="922404382"
Received: from unknown (HELO yoyo) ([70.105.111.45])
	by fldsmtpi01.verizon.com with SMTP; 05 Dec 2014 19:08:11 +0000
Date: Fri, 5 Dec 2014 14:08:11 -0500
From: Don Koch <dkoch@verizon.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20141205140811.4faf0ab5c3001e1262bf1206@verizon.com>
In-Reply-To: <1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: Sylpheed 3.4.0beta6 (GTK+ 2.24.22; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Cc: libvir-list@redhat.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Not really familiar with libvirt, but...

On Fri, 5 Dec 2014 16:30:06 +0000
Anthony PERARD <anthony.perard@citrix.com> wrote:

> The path to the pty of a Xen PV console is set only in
> virDomainOpenConsole. But this is done too late. A call to
> virDomainGetXMLDesc done before OpenConsole will not have the path to
> the pty, but a call after OpenConsole will.
> 
> e.g. of the current issue.
> Starting a domain with '<console type="pty"/>'
> Then:
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty'>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> virDomainOpenConsole()
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty' tty='/dev/pts/30'>
>       <source path='/dev/pts/30'/>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> 
> The patch intend to get the tty path on the first call of GetXMLDesc.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  src/libxl/libxl_domain.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 9c62291..de56054 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
>      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
>          goto cleanup_dom;
>  
> +    if (vm->def->nconsoles) {
> +        virDomainChrDefPtr chr = NULL;

Pointless initializer. Possibly combine with following statement.

-d

> +        chr = vm->def->consoles[0];
> +        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
> +            libxl_console_type console_type;
> +            char *console = NULL;
> +            console_type =
> +                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
> +                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
> +            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
> +                                        console_type, &console);
> +            if (!ret)
> +                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
> +            VIR_FREE(console);
> +        }
> +    }
> +
>      if (!start_paused) {
>          libxl_domain_unpause(priv->ctx, domid);
>          virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED);
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 19:37:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 19:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwyg8-0006zd-7C; Fri, 05 Dec 2014 19:36: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 1Xwyg6-0006zY-OF
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 19:36:34 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	98/DB-28296-14902845; Fri, 05 Dec 2014 19:36:33 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417808190!11432657!1
X-Originating-IP: [66.165.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 31281 invoked from network); 5 Dec 2014 19:36:32 -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 Dec 2014 19:36:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,523,1413244800"; d="scan'208";a="200511250"
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, 5 Dec 2014 14:36: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 1Xwyfh-0008Pp-Gs;
	Fri, 05 Dec 2014 19:36:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xwyfd-0005af-SL;
	Fri, 05 Dec 2014 19:36:08 +0000
Date: Fri, 5 Dec 2014 19:36:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32093-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 baseline test] 32093: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 32093 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32093/

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. 32051

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                 fail blocked in 32051

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-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-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-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                  3a80985b894f54eb3b2e143e4dea737cf139a517
baseline version:
 xen                  4d1a77ba7ab94183c203226d3fe7ac1cd087c59b

------------------------------------------------------------
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                                          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                                 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


Push not applicable.

------------------------------------------------------------
commit 3a80985b894f54eb3b2e143e4dea737cf139a517
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Wed Dec 3 10:31:22 2014 -0500

    Xen-4.5.0-rc3: Update tag for qemu-xen.
    
    QEMU-traditional has nothing new, so stay at rc1 there.
    
    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 Dec 05 19:37:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 19:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xwyg8-0006zd-7C; Fri, 05 Dec 2014 19:36: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 1Xwyg6-0006zY-OF
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 19:36:34 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	98/DB-28296-14902845; Fri, 05 Dec 2014 19:36:33 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1417808190!11432657!1
X-Originating-IP: [66.165.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 31281 invoked from network); 5 Dec 2014 19:36:32 -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 Dec 2014 19:36:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,523,1413244800"; d="scan'208";a="200511250"
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, 5 Dec 2014 14:36: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 1Xwyfh-0008Pp-Gs;
	Fri, 05 Dec 2014 19:36:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xwyfd-0005af-SL;
	Fri, 05 Dec 2014 19:36:08 +0000
Date: Fri, 5 Dec 2014 19:36:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32093-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 baseline test] 32093: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 32093 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32093/

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. 32051

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                 fail blocked in 32051

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-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-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-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                  3a80985b894f54eb3b2e143e4dea737cf139a517
baseline version:
 xen                  4d1a77ba7ab94183c203226d3fe7ac1cd087c59b

------------------------------------------------------------
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                                          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                                 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


Push not applicable.

------------------------------------------------------------
commit 3a80985b894f54eb3b2e143e4dea737cf139a517
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Wed Dec 3 10:31:22 2014 -0500

    Xen-4.5.0-rc3: Update tag for qemu-xen.
    
    QEMU-traditional has nothing new, so stay at rc1 there.
    
    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 Dec 05 21:30:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 21: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 1Xx0Rv-0001nx-B4; Fri, 05 Dec 2014 21:30:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1Xx0Ru-0001nq-Gr
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 21:30:02 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	82/11-02702-9D322845; Fri, 05 Dec 2014 21:30:01 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417814999!7919297!1
X-Originating-IP: [140.211.169.12]
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 25848 invoked from network); 5 Dec 2014 21:30:01 -0000
Received: from mail.linuxfoundation.org (HELO mail.linuxfoundation.org)
	(140.211.169.12)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 21:30:01 -0000
Received: from localhost (c-24-22-230-10.hsd1.wa.comcast.net [24.22.230.10])
	by mail.linuxfoundation.org (Postfix) with ESMTPSA id C6EFB997;
	Fri,  5 Dec 2014 21:29:58 +0000 (UTC)
Date: Fri, 5 Dec 2014 13:29:58 -0800
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141205212958.GA3012@kroah.com>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: 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] [PATCHv5 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 Fri, Dec 05, 2014 at 02:07:59PM +0000, David Vrabel wrote:
> 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 a more suitable one.
> 
> Changes in v5:
> - xen_swiotlb_get_required_mask() is x86 only.
> 
> 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

Why are you sending these to me?  Am I the DMA maintainer and forgot
about it?

/me digs in MAINTAINERS...

Nope, not me!  Patches are now deleted from my queue, go use
scripts/get_maintainer.pl like you should have done...

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 21:30:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 21: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 1Xx0Rj-0001nc-UY; Fri, 05 Dec 2014 21:29:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xx0Ri-0001nX-DI
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 21:29:50 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	53/7A-02712-BC322845; Fri, 05 Dec 2014 21:29:47 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417814985!13354365!1
X-Originating-IP: [66.165.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 14285 invoked from network); 5 Dec 2014 21:29:46 -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 Dec 2014 21:29:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,524,1413244800"; d="scan'208";a="200924005"
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, 5 Dec 2014 16:29: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 1Xx0Rb-0000Wh-Fm;
	Fri, 05 Dec 2014 21:29:43 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xx0Rb-0005sK-1r;
	Fri, 05 Dec 2014 21:29:43 +0000
Date: Fri, 5 Dec 2014 21:29:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32095-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] 32095: 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 32095 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32095/

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-sedf      8 debian-fixup                fail pass in 32055
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken pass in 32055
 test-amd64-amd64-pv          16 guest-stop         fail in 32055 pass in 32095
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 32055 pass in 32095

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 32055 like 31733

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-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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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-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
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail in 32055 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                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 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 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 Dec 05 21:30:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 21: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 1Xx0Rv-0001nx-B4; Fri, 05 Dec 2014 21:30:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1Xx0Ru-0001nq-Gr
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 21:30:02 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	82/11-02702-9D322845; Fri, 05 Dec 2014 21:30:01 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1417814999!7919297!1
X-Originating-IP: [140.211.169.12]
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 25848 invoked from network); 5 Dec 2014 21:30:01 -0000
Received: from mail.linuxfoundation.org (HELO mail.linuxfoundation.org)
	(140.211.169.12)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 21:30:01 -0000
Received: from localhost (c-24-22-230-10.hsd1.wa.comcast.net [24.22.230.10])
	by mail.linuxfoundation.org (Postfix) with ESMTPSA id C6EFB997;
	Fri,  5 Dec 2014 21:29:58 +0000 (UTC)
Date: Fri, 5 Dec 2014 13:29:58 -0800
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141205212958.GA3012@kroah.com>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: 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] [PATCHv5 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 Fri, Dec 05, 2014 at 02:07:59PM +0000, David Vrabel wrote:
> 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 a more suitable one.
> 
> Changes in v5:
> - xen_swiotlb_get_required_mask() is x86 only.
> 
> 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

Why are you sending these to me?  Am I the DMA maintainer and forgot
about it?

/me digs in MAINTAINERS...

Nope, not me!  Patches are now deleted from my queue, go use
scripts/get_maintainer.pl like you should have done...

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 21:30:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 21: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 1Xx0Rj-0001nc-UY; Fri, 05 Dec 2014 21:29:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xx0Ri-0001nX-DI
	for xen-devel@lists.xensource.com; Fri, 05 Dec 2014 21:29:50 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	53/7A-02712-BC322845; Fri, 05 Dec 2014 21:29:47 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417814985!13354365!1
X-Originating-IP: [66.165.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 14285 invoked from network); 5 Dec 2014 21:29:46 -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 Dec 2014 21:29:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,524,1413244800"; d="scan'208";a="200924005"
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, 5 Dec 2014 16:29: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 1Xx0Rb-0000Wh-Fm;
	Fri, 05 Dec 2014 21:29:43 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xx0Rb-0005sK-1r;
	Fri, 05 Dec 2014 21:29:43 +0000
Date: Fri, 5 Dec 2014 21:29:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32095-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] 32095: 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 32095 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32095/

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-sedf      8 debian-fixup                fail pass in 32055
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken pass in 32055
 test-amd64-amd64-pv          16 guest-stop         fail in 32055 pass in 32095
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 32055 pass in 32095

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-win7-amd64  7 windows-install      fail in 32055 like 31733

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-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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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-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
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail in 32055 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                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 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 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 Dec 05 21:31:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 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 1Xx0T9-0001ws-2P; Fri, 05 Dec 2014 21:31:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1Xx0T7-0001wb-1W
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 21:31:17 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	F8/C4-07724-42422845; Fri, 05 Dec 2014 21:31:16 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417815074!11450830!1
X-Originating-IP: [140.211.169.12]
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 20742 invoked from network); 5 Dec 2014 21:31:15 -0000
Received: from mail.linuxfoundation.org (HELO mail.linuxfoundation.org)
	(140.211.169.12)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 21:31:15 -0000
Received: from localhost (c-24-22-230-10.hsd1.wa.comcast.net [24.22.230.10])
	by mail.linuxfoundation.org (Postfix) with ESMTPSA id A12C5997;
	Fri,  5 Dec 2014 21:31:13 +0000 (UTC)
Date: Fri, 5 Dec 2014 13:31:13 -0800
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141205213113.GB3012@kroah.com>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
	<1417788483-662-2-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417788483-662-2-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: 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/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

On Fri, Dec 05, 2014 at 02:08:00PM +0000, David Vrabel wrote:
> 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 ++++++++--

Is this why you sent this to me?  The x86 maintainers should handle this
patch set, not me for a tiny 8 lines in just one of the files, sorry.

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 21:31:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 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 1Xx0T9-0001ws-2P; Fri, 05 Dec 2014 21:31:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1Xx0T7-0001wb-1W
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 21:31:17 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	F8/C4-07724-42422845; Fri, 05 Dec 2014 21:31:16 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-11.tower-31.messagelabs.com!1417815074!11450830!1
X-Originating-IP: [140.211.169.12]
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 20742 invoked from network); 5 Dec 2014 21:31:15 -0000
Received: from mail.linuxfoundation.org (HELO mail.linuxfoundation.org)
	(140.211.169.12)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Dec 2014 21:31:15 -0000
Received: from localhost (c-24-22-230-10.hsd1.wa.comcast.net [24.22.230.10])
	by mail.linuxfoundation.org (Postfix) with ESMTPSA id A12C5997;
	Fri,  5 Dec 2014 21:31:13 +0000 (UTC)
Date: Fri, 5 Dec 2014 13:31:13 -0800
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141205213113.GB3012@kroah.com>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
	<1417788483-662-2-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417788483-662-2-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: 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/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

On Fri, Dec 05, 2014 at 02:08:00PM +0000, David Vrabel wrote:
> 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 ++++++++--

Is this why you sent this to me?  The x86 maintainers should handle this
patch set, not me for a tiny 8 lines in just one of the files, sorry.

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 21:48:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 21: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 1Xx0j4-0002iT-Lj; Fri, 05 Dec 2014 21:47:46 +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 1Xx0j3-0002iO-Sp
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 21:47:46 +0000
Content-Length: 19020
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	D3/D3-28296-10822845; Fri, 05 Dec 2014 21:47:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417816062!11461423!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32149 invoked from network); 5 Dec 2014 21:47:43 -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 Dec 2014 21:47: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 sB5LiZj8000977
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 21:44:36 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
	sB5LiT5Q023659
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 21:44:29 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
	sB5LiSuk017392; Fri, 5 Dec 2014 21:44:28 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 13:44:28 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9412311FC84; Fri,  5 Dec 2014 16:44:24 -0500 (EST)
From: konrad.wilk@oracle.com
To: <tiejun.chen@intel.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>, <dario.faggioli@citrix.com>,
	<caobosimon@gmail.com>, <jgross@suse.com>, <olaf@aepfl.e.de>,
	<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>,
	<konrad.wilk@oracle.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>,
	"<"<boris.ostrovsky@oracle.com>, <m.a.young@durham.ac.uk>,
	<mcgrof@suse.com>
Message-Id: <20141205214424.9412311FC84@laptop.dumpdata.com>
Date: Fri,  5 Dec 2014 16:44:24 -0500 (EST)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] Xen 4.5 Development Update (RC3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://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="===============5612917496277460608=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5612917496277460608==
Content-Length: 19240
Content-Transfer-Encoding: quoted-printable

Feature patchsets that did not make it in by today have been put
on the deferred list.

Xen 4.5-rc3 was out on Wednesday (3rd). There are two known issues - with one
already in the tree (so will show up in RC4).

(see 'Known Issues' below) which are to be fixed by RC4 - 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_RC3_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

[ 'mmio_hole' fix it, but the ultimate way is to fix it in QEMU]

#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
#46 qemu-upstream: limitation on 4 emulated NICs prevents guest from starting unless PV override is used.

=3D Timeline =3D

We wer planning on a 9-month release cycle - but it is more like an
10 month.  Based on that, below are the estimated dates:


* Feature Freeze: 24th September 2014
* First RC: 24th October [Friday!]
* RC2: Nov 11th
* RC2 Test-day: Nov 13th
* RC3: Dec 3rd.
* RC3 Test-day: Dec 4th

 <=3D=3D=3D=3D WE ARE HERE =3D=3D=3D>

* RC4: Dec 15th
* RC4 Test-day: Dec 17th

 Release Date: Jan 7th.

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)
   v7 posted.
   Treating pieces as bug-fixes only.
   Low likehood of making it in Xen 4.5.
  -  Tiejun Chen

*  pygrub does not handle certain configurations. (done)
   went in after RC3
  -  Andrew Cooper and Boris Ostrovsky

=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

=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

*  HT enabled with credit has 7.9 per perf drop. (none)
   kernbench demonstrated it
   http://www.gossamer-threads.com/lists/xen/devel/339409
   This has existed since credit1 introduction.
  -  Dario Faggioli

=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

*  ucode=3Dscan also scan compressed initramfs (none)
  -  Konrad Rzeszutek Wilk

=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 

*  Regression in PCI passthrough of INTx legacy devices can trigger list corruption (good)
   Sander reported it. Two different types of patches available.
  -  Konrad Rzeszutek Wilk

*  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 

*  regression libxl bitmap handling during a restore.
  -  Boris Ostrovsky and Wei Liu
  -  done

*  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

*  vAPIC in PVHVM guests (Linux side) (done)
   Going in for 3.19
  -  Boris Ostrovsky



--===============5612917496277460608==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5612917496277460608==--

From xen-devel-bounces@lists.xen.org Fri Dec 05 21:48:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 21: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 1Xx0j4-0002iT-Lj; Fri, 05 Dec 2014 21:47:46 +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 1Xx0j3-0002iO-Sp
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 21:47:46 +0000
Content-Length: 19020
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	D3/D3-28296-10822845; Fri, 05 Dec 2014 21:47:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417816062!11461423!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32149 invoked from network); 5 Dec 2014 21:47:43 -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 Dec 2014 21:47: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 sB5LiZj8000977
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 5 Dec 2014 21:44:36 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
	sB5LiT5Q023659
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 5 Dec 2014 21:44:29 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
	sB5LiSuk017392; Fri, 5 Dec 2014 21:44:28 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 13:44:28 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9412311FC84; Fri,  5 Dec 2014 16:44:24 -0500 (EST)
From: konrad.wilk@oracle.com
To: <tiejun.chen@intel.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>, <dario.faggioli@citrix.com>,
	<caobosimon@gmail.com>, <jgross@suse.com>, <olaf@aepfl.e.de>,
	<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>,
	<konrad.wilk@oracle.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>,
	"<"<boris.ostrovsky@oracle.com>, <m.a.young@durham.ac.uk>,
	<mcgrof@suse.com>
Message-Id: <20141205214424.9412311FC84@laptop.dumpdata.com>
Date: Fri,  5 Dec 2014 16:44:24 -0500 (EST)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] Xen 4.5 Development Update (RC3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://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="===============5612917496277460608=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5612917496277460608==
Content-Length: 19240
Content-Transfer-Encoding: quoted-printable

Feature patchsets that did not make it in by today have been put
on the deferred list.

Xen 4.5-rc3 was out on Wednesday (3rd). There are two known issues - with one
already in the tree (so will show up in RC4).

(see 'Known Issues' below) which are to be fixed by RC4 - 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_RC3_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

[ 'mmio_hole' fix it, but the ultimate way is to fix it in QEMU]

#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
#46 qemu-upstream: limitation on 4 emulated NICs prevents guest from starting unless PV override is used.

=3D Timeline =3D

We wer planning on a 9-month release cycle - but it is more like an
10 month.  Based on that, below are the estimated dates:


* Feature Freeze: 24th September 2014
* First RC: 24th October [Friday!]
* RC2: Nov 11th
* RC2 Test-day: Nov 13th
* RC3: Dec 3rd.
* RC3 Test-day: Dec 4th

 <=3D=3D=3D=3D WE ARE HERE =3D=3D=3D>

* RC4: Dec 15th
* RC4 Test-day: Dec 17th

 Release Date: Jan 7th.

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)
   v7 posted.
   Treating pieces as bug-fixes only.
   Low likehood of making it in Xen 4.5.
  -  Tiejun Chen

*  pygrub does not handle certain configurations. (done)
   went in after RC3
  -  Andrew Cooper and Boris Ostrovsky

=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

=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

*  HT enabled with credit has 7.9 per perf drop. (none)
   kernbench demonstrated it
   http://www.gossamer-threads.com/lists/xen/devel/339409
   This has existed since credit1 introduction.
  -  Dario Faggioli

=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

*  ucode=3Dscan also scan compressed initramfs (none)
  -  Konrad Rzeszutek Wilk

=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 

*  Regression in PCI passthrough of INTx legacy devices can trigger list corruption (good)
   Sander reported it. Two different types of patches available.
  -  Konrad Rzeszutek Wilk

*  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 

*  regression libxl bitmap handling during a restore.
  -  Boris Ostrovsky and Wei Liu
  -  done

*  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

*  vAPIC in PVHVM guests (Linux side) (done)
   Going in for 3.19
  -  Boris Ostrovsky



--===============5612917496277460608==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5612917496277460608==--

From xen-devel-bounces@lists.xen.org Fri Dec 05 23:15:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 23:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xx25u-0005Dd-BB; Fri, 05 Dec 2014 23:15: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 1Xx25s-0005DT-VO
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 23:15:25 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	64/EC-27785-C8C32845; Fri, 05 Dec 2014 23:15:24 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417821322!8704929!1
X-Originating-IP: [209.85.216.48]
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 15511 invoked from network); 5 Dec 2014 23:15:23 -0000
Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com)
	(209.85.216.48)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 23:15:23 -0000
Received: by mail-qa0-f48.google.com with SMTP id v10so1141837qac.7
	for <xen-devel@lists.xenproject.org>;
	Fri, 05 Dec 2014 15:15:22 -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=K5Fp+tKAb/DiKIc8latp6xp4AoEG2/bdgPnVPX03YxQ=;
	b=OOmhLpBtagH3LJanIycjwh3VRXD8U6NR8Y3s3O3rbarpbl7sHKfjLnVOFL/7bEHuEZ
	xXrhgo1v9NdmPQeKRljARMIcqT1DH6KTcJHmDA0nhYoh6+1CQlVVgUCUpVEDv2wwZOT7
	6cYf0ZY2u3geGc/cwJsOlsUkyg48x/ufu1H9IOoFBbSbCwO5OXeaIhwOfe3mwwqTNXdj
	H7nZQIHCjNJ2oPyQwOT8dDbAcn//lcWT4UqZGQ0Q86+md54Ol2gp9jpU6wQ+fwutrXeb
	vNvDzCvm3voMkW0vWQEKhgj+Vkip5QrV3bnSJBMtcwp8euYQZUgjqfEhRv589wIeLSKU
	foVg==
MIME-Version: 1.0
X-Received: by 10.224.80.6 with SMTP id r6mr30060137qak.5.1417821322567; Fri,
	05 Dec 2014 15:15:22 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Fri, 5 Dec 2014 15:15:22 -0800 (PST)
Date: Fri, 5 Dec 2014 15:15:22 -0800
Message-ID: <CAAiw7Jm+aH7n4qOZcJQ4Wc+ocEugvPq+RWYHemwhOLmcd5+EGw@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: xen-devel <xen-devel@lists.xenproject.org>, xen-users@lists.xen.org, 
	manish.jaggi@caviumnetworks.com, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Julien Grall <julien.grall@linaro.org>, 
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: [Xen-devel] Steps to run XenServer on 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

Hi,

I am trying to find a tutorial to jumpstart installing XenServer / XCP
on an ARM 64bit platform.
Could the mailing list help.

-Regards
Manish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 05 23:15:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 05 Dec 2014 23:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xx25u-0005Dd-BB; Fri, 05 Dec 2014 23:15: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 1Xx25s-0005DT-VO
	for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 23:15:25 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	64/EC-27785-C8C32845; Fri, 05 Dec 2014 23:15:24 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417821322!8704929!1
X-Originating-IP: [209.85.216.48]
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 15511 invoked from network); 5 Dec 2014 23:15:23 -0000
Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com)
	(209.85.216.48)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Dec 2014 23:15:23 -0000
Received: by mail-qa0-f48.google.com with SMTP id v10so1141837qac.7
	for <xen-devel@lists.xenproject.org>;
	Fri, 05 Dec 2014 15:15:22 -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=K5Fp+tKAb/DiKIc8latp6xp4AoEG2/bdgPnVPX03YxQ=;
	b=OOmhLpBtagH3LJanIycjwh3VRXD8U6NR8Y3s3O3rbarpbl7sHKfjLnVOFL/7bEHuEZ
	xXrhgo1v9NdmPQeKRljARMIcqT1DH6KTcJHmDA0nhYoh6+1CQlVVgUCUpVEDv2wwZOT7
	6cYf0ZY2u3geGc/cwJsOlsUkyg48x/ufu1H9IOoFBbSbCwO5OXeaIhwOfe3mwwqTNXdj
	H7nZQIHCjNJ2oPyQwOT8dDbAcn//lcWT4UqZGQ0Q86+md54Ol2gp9jpU6wQ+fwutrXeb
	vNvDzCvm3voMkW0vWQEKhgj+Vkip5QrV3bnSJBMtcwp8euYQZUgjqfEhRv589wIeLSKU
	foVg==
MIME-Version: 1.0
X-Received: by 10.224.80.6 with SMTP id r6mr30060137qak.5.1417821322567; Fri,
	05 Dec 2014 15:15:22 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Fri, 5 Dec 2014 15:15:22 -0800 (PST)
Date: Fri, 5 Dec 2014 15:15:22 -0800
Message-ID: <CAAiw7Jm+aH7n4qOZcJQ4Wc+ocEugvPq+RWYHemwhOLmcd5+EGw@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: xen-devel <xen-devel@lists.xenproject.org>, xen-users@lists.xen.org, 
	manish.jaggi@caviumnetworks.com, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Julien Grall <julien.grall@linaro.org>, 
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: [Xen-devel] Steps to run XenServer on 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

Hi,

I am trying to find a tutorial to jumpstart installing XenServer / XCP
on an ARM 64bit platform.
Could the mailing list help.

-Regards
Manish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 06 00:05:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 00:05:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xx2s5-0007Ku-4V; Sat, 06 Dec 2014 00:05:13 +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 1Xx2s3-0007Kp-Lg
	for xen-devel@lists.xenproject.org; Sat, 06 Dec 2014 00:05:11 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	5D/E6-20609-63842845; Sat, 06 Dec 2014 00:05:10 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417824309!8708218!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12986 invoked from network); 6 Dec 2014 00:05:09 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 00:05:09 -0000
Received: by mail-wg0-f49.google.com with SMTP id n12so2144469wgh.8
	for <xen-devel@lists.xenproject.org>;
	Fri, 05 Dec 2014 16:05: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=fSMEcel+kflBWeFCzC6uwKYndtpx3lGCnZSCaL/e4lw=;
	b=H27yjgPyKkoaBkhoQMlOMc0L/0eOa44yyXVecfBBUdB0Ifsc9bNgcXbEyhlloqzD2+
	RGMqcKIgkcgHN8T6v0TZqyry2nzKEz4UL8aIFtJlvIQebcTudBXP/DUBul26BXHhITbq
	75bJ5l4aevDYJaphcEWLi48oIj4SNSRAxGKkrIxqlLAEBYWluDty5MGaOwxVaydhAnSG
	/iUno0G0Gt8RdcipnHODtd86A5NJwfvySptrPDliYHXFG44q8puwIK9FkfzQz1KVlQhX
	e3R56f1Dov2oyHMlvhx7edsf3Zw+1Hw4dAZst8ZyxWJfWf4HMcdhWeZjJvIoXU1nEOux
	eYMA==
X-Gm-Message-State: ALoCoQljajKZjMzlZ+9hYAXbcN2Mv5iPvSrmW0jLPLYGU/CUVBX/GFJesnLtXNmYhe/Zxg5OhQga
X-Received: by 10.180.12.75 with SMTP id w11mr7930858wib.9.1417824309306;
	Fri, 05 Dec 2014 16:05: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
	cp4sm46744911wjb.16.2014.12.05.16.05.07 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 16:05:08 -0800 (PST)
Message-ID: <54824832.9000607@linaro.org>
Date: Sat, 06 Dec 2014 00:05:06 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, 
	xen-devel <xen-devel@lists.xenproject.org>
References: <5481F18C020000780004D535@mail.emea.novell.com>
In-Reply-To: <5481F18C020000780004D535@mail.emea.novell.com>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 05/12/2014 16:55, Jan Beulich wrote:
  > I didn't change ARM, as I wasn't sure how far ahead this call could be
> pulled.

AFAIU, the new function only requires that the page table are setup 
(because of the alloc_xenheap_pages).

So console_init_mem could be called right after console_init_preirq.

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 Dec 06 00:05:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 00:05:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xx2s5-0007Ku-4V; Sat, 06 Dec 2014 00:05:13 +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 1Xx2s3-0007Kp-Lg
	for xen-devel@lists.xenproject.org; Sat, 06 Dec 2014 00:05:11 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	5D/E6-20609-63842845; Sat, 06 Dec 2014 00:05:10 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417824309!8708218!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12986 invoked from network); 6 Dec 2014 00:05:09 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 00:05:09 -0000
Received: by mail-wg0-f49.google.com with SMTP id n12so2144469wgh.8
	for <xen-devel@lists.xenproject.org>;
	Fri, 05 Dec 2014 16:05: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=fSMEcel+kflBWeFCzC6uwKYndtpx3lGCnZSCaL/e4lw=;
	b=H27yjgPyKkoaBkhoQMlOMc0L/0eOa44yyXVecfBBUdB0Ifsc9bNgcXbEyhlloqzD2+
	RGMqcKIgkcgHN8T6v0TZqyry2nzKEz4UL8aIFtJlvIQebcTudBXP/DUBul26BXHhITbq
	75bJ5l4aevDYJaphcEWLi48oIj4SNSRAxGKkrIxqlLAEBYWluDty5MGaOwxVaydhAnSG
	/iUno0G0Gt8RdcipnHODtd86A5NJwfvySptrPDliYHXFG44q8puwIK9FkfzQz1KVlQhX
	e3R56f1Dov2oyHMlvhx7edsf3Zw+1Hw4dAZst8ZyxWJfWf4HMcdhWeZjJvIoXU1nEOux
	eYMA==
X-Gm-Message-State: ALoCoQljajKZjMzlZ+9hYAXbcN2Mv5iPvSrmW0jLPLYGU/CUVBX/GFJesnLtXNmYhe/Zxg5OhQga
X-Received: by 10.180.12.75 with SMTP id w11mr7930858wib.9.1417824309306;
	Fri, 05 Dec 2014 16:05: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
	cp4sm46744911wjb.16.2014.12.05.16.05.07 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Dec 2014 16:05:08 -0800 (PST)
Message-ID: <54824832.9000607@linaro.org>
Date: Sat, 06 Dec 2014 00:05:06 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, 
	xen-devel <xen-devel@lists.xenproject.org>
References: <5481F18C020000780004D535@mail.emea.novell.com>
In-Reply-To: <5481F18C020000780004D535@mail.emea.novell.com>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 05/12/2014 16:55, Jan Beulich wrote:
  > I didn't change ARM, as I wasn't sure how far ahead this call could be
> pulled.

AFAIU, the new function only requires that the page table are setup 
(because of the alloc_xenheap_pages).

So console_init_mem could be called right after console_init_preirq.

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 Dec 06 00:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 00: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 1Xx3VH-0008Vm-KQ; Sat, 06 Dec 2014 00:45:43 +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 1Xx3VG-0008Vh-LH
	for xen-devel@lists.xen.org; Sat, 06 Dec 2014 00:45:42 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	2D/BC-26858-5B152845; Sat, 06 Dec 2014 00:45:41 +0000
X-Env-Sender: zir_blazer@hotmail.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417826728!11459919!1
X-Originating-IP: [65.55.90.208]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	FORGED_HOTMAIL_RCVD, ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDQyODIgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16228 invoked from network); 6 Dec 2014 00:45:30 -0000
Received: from snt004-omc4s5.hotmail.com (HELO SNT004-OMC4S5.hotmail.com)
	(65.55.90.208)
	by server-16.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Dec 2014 00:45:30 -0000
Received: from SNT151-W41 ([65.55.90.199]) by SNT004-OMC4S5.hotmail.com over
	TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); 
	Fri, 5 Dec 2014 16:45:28 -0800
X-TMN: [rfx9jvxepTcg47UT3TA7lnEEY8qQhKz4]
X-Originating-Email: [zir_blazer@hotmail.com]
Message-ID: <SNT151-W418A2CEE673F81B3E75E99F3660@phx.gbl>
From: Zir Blazer <zir_blazer@hotmail.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 5 Dec 2014 21:45:27 -0300
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Dec 2014 00:45:28.0041 (UTC)
	FILETIME=[EE060590:01D010ED]
Subject: [Xen-devel] Some questions regarding QEMU, UEFI, PCI/VGA Passthrough,
 and other things
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

While I am not a developer myself (I always sucked hard when it comes to re=
ad and write code), there are several capabilities of Xen and its supportin=
g Software which I'm always interesed in how they progress, more out of cur=
iosity than anything else. However, usually, documentation seems to backtra=
ck a lot what its currently implemented in code, and sometimes you catch a =
mail here with some useful data regarding a topic but later you don't hear =
about that any more, missing any progress, or because the whole topic was i=
nconclusive. So, this mail is pretty much a compilation of small questions =
of things I came across but didn't popped up later, but can serve to brains=
torm someone, which is why I believe it to be more useful for xen-devel tha=
n xen-users.


=A0 =A0QEMU
Because as a VGA Passthrough user I'm currently forced to use qemu-xen-trad=
itional (Through I hear some success about some users using qemu-xen in Xen=
 4.4, but I myself didn't had any luck with it), I'm stuck with an old QEMU=
 version. However, looking at changelog from latest versions I always see s=
ome interesing features, which as far that I know Xen doesn't currently inc=
orporate.


1a - One of the things that newer QEMU versions seems to be capable of doin=
g, is emulating the much newer Intel Q35 Chipset, instead of only the curre=
nt 440FX from the P5 Pentium era. Some data from Q35 emulation here:
www.linux-kvm.org/wiki/images/0/06/2012-forum-Q35.pdf
wiki.qemu.org/Features/Q35

I'm aware that newer doesn't neccesarily means better, specially because th=
e practical advantages of Q35 vs 440FX aren't very clear. There are several=
 new emulated features like an AHCI Controller and a PCIe Bus, which sounds=
 interesing on paper, but I don't know if they add any useful feature or in=
creases performance/compatibility. Some comments I read about the matter wr=
ongly stated that Q35 would be needed to do PCIe Passthrough, but this is c=
urrently possible on 440FX, through I don't know about the low level implem=
entation differences. I think most of the idea about Q35 is to make the VM =
look more closely to real Hardware, instead of looking like a ridiculous ob=
vious emulated platform.
In the case of the AHCI Controller, I suppose than the OS would need to inc=
lude Drivers for the controller during installation time, which if I recall=
 correctly both Windows Vista/7/8 and Linux should have, through for a Wind=
ows XP install the Q35 AHCI Controller Drivers should probabily need to be =
slipstreamed with nLite to an install ISO for it to work.


1b - Another experimental feature that recently popped in QEMU is IOMMU emu=
lation. Info here:
www.mulix.org/pubs/iommu/viommu.pdf
www.linux-kvm.org/wiki/images/4/4a/2010-forum-joro-pv-iommu.pdf

IOMMU emulation usefulness seems to be so you can do PCI Passthrough in a N=
ested Virtualization enviroment. At first sight this looked a bit useless, =
cause using a DomU to do PCI Passthrough with an emulated IOMMU sounds rath=
er too much overhead if you can simply emulate that device in the nested Do=
mU. However, I also read about the possibility of Xen using Hardware virtua=
lization for Dom0 instead of it being Paravirtualized. In that case, would =
it be possible to provide the IOMMU emulation layer to Dom0 so you could do=
 PCI Passthrough in platforms without proper support for it? It seems a rat=
her interesing idea.
I think it would also be useful to serve as an standarized debug platform f=
or IOMMU virtualization and passthrough, cause some years ago missing or ma=
lformed ACPI DMAR/IVRS tables were all over the place and getting IOMMU vir=
tualization working was pretty much random luck and at the mercy of the goo=
dwill of the Motherboard maker to fix their BIOSes.


=A0 =A0UEFI for DomUs
I managed to get this one working, but it seems to need some clarifications=
 here and there.

2a - As far that I know, if you add --enable-ovmf to ./configure before bui=
lding Xen, it downloads and builds some extra code from a OVMF repository w=
hich Xen maintains, through I don't know if its a snapshop of whatever the =
edk2 repository had at that time, or if it does includes custom patchs for =
the OVMF Firmware to work in Xen. Xen also has another ./configure option, =
--with-system-ovmf, which is supposed to be used to specify a path to provi=
de an OVMF Firmware binary. However, when I tried that option some months a=
go, I never managed to get it working, either using a package with a precom=
piled ovmf.bin from Arch Linux User Repository, or using another package wi=
th the source to compile it myself. Both binaries worked with standalone QE=
MU, through.
Besides than that parameter itself was quite hidden, there is absolutely no=
 info regarding if the provided OVMF binary has to comply with some special=
 requeriments, be it some custom patchs for OVMF so it works with Xen, if i=
t has to be a binary that only includes TianoCore, or the unified one that =
includes the NVRAM in a single file. In Arch Linux, for the Xen 4.4 package=
, the maintainer decided that the way to go for including OVMF support to X=
en was to use --enable-ovmf, cause at least it was possible to get it worki=
ng with some available patches. However, for both download and build times,=
 it would be better to simply distribute a working binary. Any ideas of why=
 --with-system-ovmf didn't worked for us?


2b - On successful Xen builds with OVMF support, something which I looked f=
or is the actual ovmf.bin file. So far, the only thing which I noticed is t=
hat the hvmloader is 2 MiB bigger that on non-OVMF builds. Is there any rea=
son why OVMF is build into the hvmloader instead of what happens to the oth=
er Firmware binaries, which are usually sitting in a directory as standalon=
e files?


2c - Something which I'm aware is that an OVMF binary can be in two formats=
: A unified binary that has both OVMF and NVRAM, or a OVMF binary with a se=
parate NVRAM (1.87 MiB + 128 KiB respectively). According to what I read ab=
out using OVMF with QEMU, it seems that if using a unified binary, you need=
 one per VM, cause the NVRAM content is different. I suppose than with the =
second option you have one OVMF Firmware binary and a 128 KB NVRAM per UEFI=
 VM. How does Xen handles this? If I recall correctly, I heared than it is =
currently volatile (NVRAM contents aren't saved on DomU shutdown).


2d - Is there any recorded experience or info regarding how a UEFI DomU wou=
ld behave with something like, say, Windows 8 with Fast Boot, or other UEFI=
 features for native systems? This is pretty much a "what if..." scenario t=
han something that I could really use.


=A0 =A0PCI/VGA Passthrough
It was four years ago when I learned about IOMMU virtualization making poss=
ible gaming in a VM via VGA Passthrough (First time I heared about that was=
 with some of Teo En Ming videos on Youtube), something which was quite exp=
erimental back at that time. Even currently, the only other Hypervisor or V=
MM that can compete with Xen in this area is QEMU with KVM VFIO, which also=
 has decent VGA Passthrough capabilities. While I'm aware that Xen is prett=
y much enterprise oriented, it was also the first to allow a power user to =
make a system based on Xen as Hypervisor and everything else virtualized, g=
etting nearly all the functionality of running native with the flexibility =
than virtualization offers, at the cost of some overhead, quircks and compl=
exity on usage. Its a pain to configure it the first time, but if you manag=
e to get it working, its wonderful. So far, this feature has created a smal=
l niche of power users that uses either Xen or QEMU KVM VFIO for virtualize=
d gaming, and I consider VGA Passthrough a quite major feature because it i=
s what allows such setups on the first place.


3a - On some of the Threads of the original guides I read about how to use =
Xen to do VGA Passthrough, you usually see the author and others users sayi=
ng that they didn't manage to get VGA Passthrough working on newer versions=
. This usually affected people that was doing the migration from the xm to =
xl toolstack, but also between some Xen versions (I reported a regression o=
n Xen 4.4 vs a fully working 4.3). Passthrough compatibility previously use=
d to be a Hardware-related pain cause it was extremely Motherboard and BIOS=
 dependant on an era where consumer Motherboards makers didn't paid attenti=
on to the IOMMU, but at least on the Intel Haswell platform support for IOM=
MU is starting to get more mainstream.
Considering than PCI/VGA Passthrough compatibility with a system or regress=
ions of it between Xen versions is pretty much a hit-or-miss, would it be p=
ossible to do something to get this feature under control? It seems like th=
is isn't deeply tested, or at least not with too many variables involved (H=
ard to do, cause they're A LOT). I believe that it should be possible to ha=
ve a few systems at hand which are know to work and representative of a Har=
dware platform tested against regression with different Video Cards, but it=
 sounds extremely time consuming to switch cards, reboot, test with differe=
nt DomUs OSes/Drivers, etc. At the moment, once you get a Computer/Distribu=
tion/Kernel/Xen/Toolstack/DomU OS/Drivers combination that works, you simpl=
y stick to it, so many early adopters of VGA Passthrough are still using ex=
tremely outdated versions. Even worse, for users of versions like 4.2 with =
xm, if they want to upgrade to 4.4 with xl and want to figure out why it do=
esn't work, it will be a royal pain in the butt to figure out what patch wa=
s introduced that breaks compatibility for them, so those early adopters ar=
e pretty much out of luck if they have to go through years worth of code an=
d version testing.


3b - Do someone knows what is the actual difference on Intel platforms rega=
rding VT-d support? As far that I know, the VT-d specification allows for m=
ultiple "DMA Remapping Engines", of which a Haswell Processor has two, one =
for its Integrated PCIe Controller and another for the Integrated GPU. You =
also have Chipsets, some of which according to Intel Ark support VT-d (Whic=
h I believe should be in the form of a third DMA Remapping Engine), like th=
e Q87 and C226, and those that don't like the H87 and Z87. Based on working=
 samples I have been lead to believe than a Processor supporting VT-d will =
provide the IOMMU capabilities for the devices connected to its own PCIe Sl=
ots regardless of what Chipset you're using (That's the reason why you can =
do Passthrough with only Processor VT-d support), I would believe the same =
holds true with a VT-d Chipset with a non VT-d Processor, through I didn't =
saw any working example of this.
When I was researching about this one year ago, Supermicro support said thi=
s to me:

Since Z87 chipset does not support VT-d, =A0onboard LAN will not support it=
 either because it is connected to PCH PCIe port. =A0One workaround is to u=
se a VT-d enabled PCIe device and plug it into CPU based PCIe-port on board=
. =A0Along with a VT-d enabled CPU the above workaround should work per Int=
el.

Based on this, there should be a not-very-well-documented quirck. The most =
common configuration for VGA Passthrough users is a VT-d supporting Process=
or with a consumer Motherboard, so basically, if you have a VT-d supporting=
 Processor like a Core i7 4790K, you can do Passthrough of the devices conn=
ected to the Processor PCIe Slots, and also of the ones connected to the Ch=
ipset if you apply that workaround (I don't know what does "VT-d enabled PC=
Ie device" means exactly). I recall seeing some people using VMWare ESXi co=
mmenting that they couldn't passthrough the integrated NIC even through som=
e a RAID Controller connected to the Processor could in such setups. Don't =
have link at hand about the matter, but I believe that reelevant for the qu=
estion.
Considering that if workarounded you would be using the Processor DMA Remap=
ping Engine for Chipset devices, is there any potential bottleneck or perfo=
rmance degradation there?


3c - There is a feature that enhances VT-d called ACS (Access Control Servi=
ce), related to IOMMU groups isolation. This feature seems to be excluded f=
rom consumer platforms, and support for it seems to already be on Xen wishl=
ist based on comments. Info here:
vfio.blogspot.com.ar/2014/08/iommu-groups-inside-and-out.html
comments.gmane.org/gmane.comp.emulators.xen.devel/212561

A curious thing is that if I check /sys/kernel/iommu_groups/ as stated on t=
he blog I find the folder empty (This is on Dom0, with a DomU with 2 passth=
roughed devices). I suppose it may be VFIO exclusive or something. Point is=
, after some googling I couldn't find a way to check for IOMMU groups, thro=
ugh Xen doesn't seem to manage that anyways. I think that it may be useful =
to get a layout of IOMMU groups to at least identify if passthrough issues =
could be related to that. Anyone can imagine current scenarios where this m=
ay break something or limit possible passthrough, why I have my IOMMU group=
s listing empty, and how to get such list?


3d - The new SATA Express and M.2 connectors combines SATA and some PCI Exp=
ress lanes on the same connector. Depending on implementation, the PCI Expr=
ess lanes could come from either the Chipset or the Processor. Considering =
than some people likes to passthrough the entire SATA Controller, how does =
it interacts with this frankenstein connector with the PCIe lanes coming fr=
om elsewhere? I'm curious.


=A0 =A0Miscelaneous Virtualization stuff


4a - There are several instances where the Software is trying to check if i=
t is under a virtualized enviroment or not. Examples which I recall having =
read about are some malware, which tries to hide if it detects that it is r=
unning virtualized (Cause it means that it is not your exploitable Average =
Joe computer), or according some comments I read, some Drivers like those o=
f NVIDIA to force you to use a Quadro for VGA Passthrough instead of a cons=
umer based GeForce. Is the goal of virtualization to reproduce the exact be=
haviator in a VM of a system running native, or just be functionally equiva=
lent? This is because as more Software appears that makes a distinction bet=
ween native and a VM, it seems that in the end it will be forcing VMs to lo=
ok and behave like a native system to maintain compatibility. While current=
ly such Software is pretty much a specific niche, it exist the possibility =
than it becomes a trend with the growing popularity of the cloud.
For example, one of the things that pretty much tells the whole history, is=
 the 440FX Chipset, because if you see that Chipset running anything but a =
P5 Pentium, you know you're running either emulated or virtualized. Also, i=
f I use an application like CPU-Z, it says than the BIOS Brand is Xen, Vers=
ion 4.3.3, which makes the status of the system as inside a VM also obvious=
. I think that based on the rare but existant Software pieces that attempts=
 to check if its running on a VM or not to decide behavior, at some point i=
n time a part of the virtualization segment will be playing a catching up g=
ame to mask being a VM from these types of applications. I suppose that a p=
ossible endgame for this topic would be where you have a VM that tries to r=
epresent accurately as possible the PCI Layout of a commercial Chipset (Whi=
ch I believe was one of the aims of QEMU Q35 emulation), and deliberately l=
ying and/or masking the Processor CPUID data, BIOS vendor, and other recogn=
izable things, to try to match what you would expect from a native system o=
f that Hardware generation.
This point could be questionable, cause making a perfect VM that is indisti=
nguishable from a native system could harm some vendors that may rely on id=
entifying if its running on a VM or not for enforcing licensing and the lik=
e.


4b - The only feature which I feel that Xen is missing from a home user per=
spective, is sound. As far that I know you can currently tell QEMU to emula=
te a Sound Card in a DomU, but there is no way to easily get the sound out =
of a DomU like other VMMs do. Some of the solutions I saw relied on either =
multiple passthroughed Sound Cards, or a PulseAudio Server adding massive s=
ound latency. While Xen is enterprise oriented where sound is unneeded, I r=
ecall hearing that this feature was getting considered, but didn't see any =
mention about it for months. How hard or complex it would be to add sound s=
upport to Xen? Is the way to do it decided? Could it take the form of using=
 Dom0 Drivers for the Sound Card to act as a mixer and some PV Drivers for =
the DomU like the ones currently available for the NIC and storage?


I hope someone finds my questions interesing to answer.

 		 	   		  =

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 06 00:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 00: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 1Xx3VH-0008Vm-KQ; Sat, 06 Dec 2014 00:45:43 +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 1Xx3VG-0008Vh-LH
	for xen-devel@lists.xen.org; Sat, 06 Dec 2014 00:45:42 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	2D/BC-26858-5B152845; Sat, 06 Dec 2014 00:45:41 +0000
X-Env-Sender: zir_blazer@hotmail.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417826728!11459919!1
X-Originating-IP: [65.55.90.208]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	FORGED_HOTMAIL_RCVD, ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDQyODIgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16228 invoked from network); 6 Dec 2014 00:45:30 -0000
Received: from snt004-omc4s5.hotmail.com (HELO SNT004-OMC4S5.hotmail.com)
	(65.55.90.208)
	by server-16.tower-31.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Dec 2014 00:45:30 -0000
Received: from SNT151-W41 ([65.55.90.199]) by SNT004-OMC4S5.hotmail.com over
	TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); 
	Fri, 5 Dec 2014 16:45:28 -0800
X-TMN: [rfx9jvxepTcg47UT3TA7lnEEY8qQhKz4]
X-Originating-Email: [zir_blazer@hotmail.com]
Message-ID: <SNT151-W418A2CEE673F81B3E75E99F3660@phx.gbl>
From: Zir Blazer <zir_blazer@hotmail.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 5 Dec 2014 21:45:27 -0300
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Dec 2014 00:45:28.0041 (UTC)
	FILETIME=[EE060590:01D010ED]
Subject: [Xen-devel] Some questions regarding QEMU, UEFI, PCI/VGA Passthrough,
 and other things
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

While I am not a developer myself (I always sucked hard when it comes to re=
ad and write code), there are several capabilities of Xen and its supportin=
g Software which I'm always interesed in how they progress, more out of cur=
iosity than anything else. However, usually, documentation seems to backtra=
ck a lot what its currently implemented in code, and sometimes you catch a =
mail here with some useful data regarding a topic but later you don't hear =
about that any more, missing any progress, or because the whole topic was i=
nconclusive. So, this mail is pretty much a compilation of small questions =
of things I came across but didn't popped up later, but can serve to brains=
torm someone, which is why I believe it to be more useful for xen-devel tha=
n xen-users.


=A0 =A0QEMU
Because as a VGA Passthrough user I'm currently forced to use qemu-xen-trad=
itional (Through I hear some success about some users using qemu-xen in Xen=
 4.4, but I myself didn't had any luck with it), I'm stuck with an old QEMU=
 version. However, looking at changelog from latest versions I always see s=
ome interesing features, which as far that I know Xen doesn't currently inc=
orporate.


1a - One of the things that newer QEMU versions seems to be capable of doin=
g, is emulating the much newer Intel Q35 Chipset, instead of only the curre=
nt 440FX from the P5 Pentium era. Some data from Q35 emulation here:
www.linux-kvm.org/wiki/images/0/06/2012-forum-Q35.pdf
wiki.qemu.org/Features/Q35

I'm aware that newer doesn't neccesarily means better, specially because th=
e practical advantages of Q35 vs 440FX aren't very clear. There are several=
 new emulated features like an AHCI Controller and a PCIe Bus, which sounds=
 interesing on paper, but I don't know if they add any useful feature or in=
creases performance/compatibility. Some comments I read about the matter wr=
ongly stated that Q35 would be needed to do PCIe Passthrough, but this is c=
urrently possible on 440FX, through I don't know about the low level implem=
entation differences. I think most of the idea about Q35 is to make the VM =
look more closely to real Hardware, instead of looking like a ridiculous ob=
vious emulated platform.
In the case of the AHCI Controller, I suppose than the OS would need to inc=
lude Drivers for the controller during installation time, which if I recall=
 correctly both Windows Vista/7/8 and Linux should have, through for a Wind=
ows XP install the Q35 AHCI Controller Drivers should probabily need to be =
slipstreamed with nLite to an install ISO for it to work.


1b - Another experimental feature that recently popped in QEMU is IOMMU emu=
lation. Info here:
www.mulix.org/pubs/iommu/viommu.pdf
www.linux-kvm.org/wiki/images/4/4a/2010-forum-joro-pv-iommu.pdf

IOMMU emulation usefulness seems to be so you can do PCI Passthrough in a N=
ested Virtualization enviroment. At first sight this looked a bit useless, =
cause using a DomU to do PCI Passthrough with an emulated IOMMU sounds rath=
er too much overhead if you can simply emulate that device in the nested Do=
mU. However, I also read about the possibility of Xen using Hardware virtua=
lization for Dom0 instead of it being Paravirtualized. In that case, would =
it be possible to provide the IOMMU emulation layer to Dom0 so you could do=
 PCI Passthrough in platforms without proper support for it? It seems a rat=
her interesing idea.
I think it would also be useful to serve as an standarized debug platform f=
or IOMMU virtualization and passthrough, cause some years ago missing or ma=
lformed ACPI DMAR/IVRS tables were all over the place and getting IOMMU vir=
tualization working was pretty much random luck and at the mercy of the goo=
dwill of the Motherboard maker to fix their BIOSes.


=A0 =A0UEFI for DomUs
I managed to get this one working, but it seems to need some clarifications=
 here and there.

2a - As far that I know, if you add --enable-ovmf to ./configure before bui=
lding Xen, it downloads and builds some extra code from a OVMF repository w=
hich Xen maintains, through I don't know if its a snapshop of whatever the =
edk2 repository had at that time, or if it does includes custom patchs for =
the OVMF Firmware to work in Xen. Xen also has another ./configure option, =
--with-system-ovmf, which is supposed to be used to specify a path to provi=
de an OVMF Firmware binary. However, when I tried that option some months a=
go, I never managed to get it working, either using a package with a precom=
piled ovmf.bin from Arch Linux User Repository, or using another package wi=
th the source to compile it myself. Both binaries worked with standalone QE=
MU, through.
Besides than that parameter itself was quite hidden, there is absolutely no=
 info regarding if the provided OVMF binary has to comply with some special=
 requeriments, be it some custom patchs for OVMF so it works with Xen, if i=
t has to be a binary that only includes TianoCore, or the unified one that =
includes the NVRAM in a single file. In Arch Linux, for the Xen 4.4 package=
, the maintainer decided that the way to go for including OVMF support to X=
en was to use --enable-ovmf, cause at least it was possible to get it worki=
ng with some available patches. However, for both download and build times,=
 it would be better to simply distribute a working binary. Any ideas of why=
 --with-system-ovmf didn't worked for us?


2b - On successful Xen builds with OVMF support, something which I looked f=
or is the actual ovmf.bin file. So far, the only thing which I noticed is t=
hat the hvmloader is 2 MiB bigger that on non-OVMF builds. Is there any rea=
son why OVMF is build into the hvmloader instead of what happens to the oth=
er Firmware binaries, which are usually sitting in a directory as standalon=
e files?


2c - Something which I'm aware is that an OVMF binary can be in two formats=
: A unified binary that has both OVMF and NVRAM, or a OVMF binary with a se=
parate NVRAM (1.87 MiB + 128 KiB respectively). According to what I read ab=
out using OVMF with QEMU, it seems that if using a unified binary, you need=
 one per VM, cause the NVRAM content is different. I suppose than with the =
second option you have one OVMF Firmware binary and a 128 KB NVRAM per UEFI=
 VM. How does Xen handles this? If I recall correctly, I heared than it is =
currently volatile (NVRAM contents aren't saved on DomU shutdown).


2d - Is there any recorded experience or info regarding how a UEFI DomU wou=
ld behave with something like, say, Windows 8 with Fast Boot, or other UEFI=
 features for native systems? This is pretty much a "what if..." scenario t=
han something that I could really use.


=A0 =A0PCI/VGA Passthrough
It was four years ago when I learned about IOMMU virtualization making poss=
ible gaming in a VM via VGA Passthrough (First time I heared about that was=
 with some of Teo En Ming videos on Youtube), something which was quite exp=
erimental back at that time. Even currently, the only other Hypervisor or V=
MM that can compete with Xen in this area is QEMU with KVM VFIO, which also=
 has decent VGA Passthrough capabilities. While I'm aware that Xen is prett=
y much enterprise oriented, it was also the first to allow a power user to =
make a system based on Xen as Hypervisor and everything else virtualized, g=
etting nearly all the functionality of running native with the flexibility =
than virtualization offers, at the cost of some overhead, quircks and compl=
exity on usage. Its a pain to configure it the first time, but if you manag=
e to get it working, its wonderful. So far, this feature has created a smal=
l niche of power users that uses either Xen or QEMU KVM VFIO for virtualize=
d gaming, and I consider VGA Passthrough a quite major feature because it i=
s what allows such setups on the first place.


3a - On some of the Threads of the original guides I read about how to use =
Xen to do VGA Passthrough, you usually see the author and others users sayi=
ng that they didn't manage to get VGA Passthrough working on newer versions=
. This usually affected people that was doing the migration from the xm to =
xl toolstack, but also between some Xen versions (I reported a regression o=
n Xen 4.4 vs a fully working 4.3). Passthrough compatibility previously use=
d to be a Hardware-related pain cause it was extremely Motherboard and BIOS=
 dependant on an era where consumer Motherboards makers didn't paid attenti=
on to the IOMMU, but at least on the Intel Haswell platform support for IOM=
MU is starting to get more mainstream.
Considering than PCI/VGA Passthrough compatibility with a system or regress=
ions of it between Xen versions is pretty much a hit-or-miss, would it be p=
ossible to do something to get this feature under control? It seems like th=
is isn't deeply tested, or at least not with too many variables involved (H=
ard to do, cause they're A LOT). I believe that it should be possible to ha=
ve a few systems at hand which are know to work and representative of a Har=
dware platform tested against regression with different Video Cards, but it=
 sounds extremely time consuming to switch cards, reboot, test with differe=
nt DomUs OSes/Drivers, etc. At the moment, once you get a Computer/Distribu=
tion/Kernel/Xen/Toolstack/DomU OS/Drivers combination that works, you simpl=
y stick to it, so many early adopters of VGA Passthrough are still using ex=
tremely outdated versions. Even worse, for users of versions like 4.2 with =
xm, if they want to upgrade to 4.4 with xl and want to figure out why it do=
esn't work, it will be a royal pain in the butt to figure out what patch wa=
s introduced that breaks compatibility for them, so those early adopters ar=
e pretty much out of luck if they have to go through years worth of code an=
d version testing.


3b - Do someone knows what is the actual difference on Intel platforms rega=
rding VT-d support? As far that I know, the VT-d specification allows for m=
ultiple "DMA Remapping Engines", of which a Haswell Processor has two, one =
for its Integrated PCIe Controller and another for the Integrated GPU. You =
also have Chipsets, some of which according to Intel Ark support VT-d (Whic=
h I believe should be in the form of a third DMA Remapping Engine), like th=
e Q87 and C226, and those that don't like the H87 and Z87. Based on working=
 samples I have been lead to believe than a Processor supporting VT-d will =
provide the IOMMU capabilities for the devices connected to its own PCIe Sl=
ots regardless of what Chipset you're using (That's the reason why you can =
do Passthrough with only Processor VT-d support), I would believe the same =
holds true with a VT-d Chipset with a non VT-d Processor, through I didn't =
saw any working example of this.
When I was researching about this one year ago, Supermicro support said thi=
s to me:

Since Z87 chipset does not support VT-d, =A0onboard LAN will not support it=
 either because it is connected to PCH PCIe port. =A0One workaround is to u=
se a VT-d enabled PCIe device and plug it into CPU based PCIe-port on board=
. =A0Along with a VT-d enabled CPU the above workaround should work per Int=
el.

Based on this, there should be a not-very-well-documented quirck. The most =
common configuration for VGA Passthrough users is a VT-d supporting Process=
or with a consumer Motherboard, so basically, if you have a VT-d supporting=
 Processor like a Core i7 4790K, you can do Passthrough of the devices conn=
ected to the Processor PCIe Slots, and also of the ones connected to the Ch=
ipset if you apply that workaround (I don't know what does "VT-d enabled PC=
Ie device" means exactly). I recall seeing some people using VMWare ESXi co=
mmenting that they couldn't passthrough the integrated NIC even through som=
e a RAID Controller connected to the Processor could in such setups. Don't =
have link at hand about the matter, but I believe that reelevant for the qu=
estion.
Considering that if workarounded you would be using the Processor DMA Remap=
ping Engine for Chipset devices, is there any potential bottleneck or perfo=
rmance degradation there?


3c - There is a feature that enhances VT-d called ACS (Access Control Servi=
ce), related to IOMMU groups isolation. This feature seems to be excluded f=
rom consumer platforms, and support for it seems to already be on Xen wishl=
ist based on comments. Info here:
vfio.blogspot.com.ar/2014/08/iommu-groups-inside-and-out.html
comments.gmane.org/gmane.comp.emulators.xen.devel/212561

A curious thing is that if I check /sys/kernel/iommu_groups/ as stated on t=
he blog I find the folder empty (This is on Dom0, with a DomU with 2 passth=
roughed devices). I suppose it may be VFIO exclusive or something. Point is=
, after some googling I couldn't find a way to check for IOMMU groups, thro=
ugh Xen doesn't seem to manage that anyways. I think that it may be useful =
to get a layout of IOMMU groups to at least identify if passthrough issues =
could be related to that. Anyone can imagine current scenarios where this m=
ay break something or limit possible passthrough, why I have my IOMMU group=
s listing empty, and how to get such list?


3d - The new SATA Express and M.2 connectors combines SATA and some PCI Exp=
ress lanes on the same connector. Depending on implementation, the PCI Expr=
ess lanes could come from either the Chipset or the Processor. Considering =
than some people likes to passthrough the entire SATA Controller, how does =
it interacts with this frankenstein connector with the PCIe lanes coming fr=
om elsewhere? I'm curious.


=A0 =A0Miscelaneous Virtualization stuff


4a - There are several instances where the Software is trying to check if i=
t is under a virtualized enviroment or not. Examples which I recall having =
read about are some malware, which tries to hide if it detects that it is r=
unning virtualized (Cause it means that it is not your exploitable Average =
Joe computer), or according some comments I read, some Drivers like those o=
f NVIDIA to force you to use a Quadro for VGA Passthrough instead of a cons=
umer based GeForce. Is the goal of virtualization to reproduce the exact be=
haviator in a VM of a system running native, or just be functionally equiva=
lent? This is because as more Software appears that makes a distinction bet=
ween native and a VM, it seems that in the end it will be forcing VMs to lo=
ok and behave like a native system to maintain compatibility. While current=
ly such Software is pretty much a specific niche, it exist the possibility =
than it becomes a trend with the growing popularity of the cloud.
For example, one of the things that pretty much tells the whole history, is=
 the 440FX Chipset, because if you see that Chipset running anything but a =
P5 Pentium, you know you're running either emulated or virtualized. Also, i=
f I use an application like CPU-Z, it says than the BIOS Brand is Xen, Vers=
ion 4.3.3, which makes the status of the system as inside a VM also obvious=
. I think that based on the rare but existant Software pieces that attempts=
 to check if its running on a VM or not to decide behavior, at some point i=
n time a part of the virtualization segment will be playing a catching up g=
ame to mask being a VM from these types of applications. I suppose that a p=
ossible endgame for this topic would be where you have a VM that tries to r=
epresent accurately as possible the PCI Layout of a commercial Chipset (Whi=
ch I believe was one of the aims of QEMU Q35 emulation), and deliberately l=
ying and/or masking the Processor CPUID data, BIOS vendor, and other recogn=
izable things, to try to match what you would expect from a native system o=
f that Hardware generation.
This point could be questionable, cause making a perfect VM that is indisti=
nguishable from a native system could harm some vendors that may rely on id=
entifying if its running on a VM or not for enforcing licensing and the lik=
e.


4b - The only feature which I feel that Xen is missing from a home user per=
spective, is sound. As far that I know you can currently tell QEMU to emula=
te a Sound Card in a DomU, but there is no way to easily get the sound out =
of a DomU like other VMMs do. Some of the solutions I saw relied on either =
multiple passthroughed Sound Cards, or a PulseAudio Server adding massive s=
ound latency. While Xen is enterprise oriented where sound is unneeded, I r=
ecall hearing that this feature was getting considered, but didn't see any =
mention about it for months. How hard or complex it would be to add sound s=
upport to Xen? Is the way to do it decided? Could it take the form of using=
 Dom0 Drivers for the Sound Card to act as a mixer and some PV Drivers for =
the DomU like the ones currently available for the NIC and storage?


I hope someone finds my questions interesing to answer.

 		 	   		  =

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 06 01:18:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 01:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xx40U-0004Y1-CC; Sat, 06 Dec 2014 01:17: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 1Xx40S-0004Xw-OY
	for xen-devel@lists.xensource.com; Sat, 06 Dec 2014 01:17:56 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	81/47-22819-34952845; Sat, 06 Dec 2014 01:17:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417828673!6577068!1
X-Originating-IP: [66.165.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 5500 invoked from network); 6 Dec 2014 01:17:54 -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;
	6 Dec 2014 01:17:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,526,1413244800"; d="scan'208";a="201037602"
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, 5 Dec 2014 20:17: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 1Xx40M-0001dR-Vm;
	Sat, 06 Dec 2014 01:17:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xx40M-0000F2-Qx;
	Sat, 06 Dec 2014 01:17:50 +0000
Date: Sat, 6 Dec 2014 01:17:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32096-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] 32096: 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 32096 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32096/

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 32029

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-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-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                54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5
baseline version:
 qemuu                0d7954c288e91b8a457f15a0a8e8244facf6594b

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@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                    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=54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5
+ . 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 54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5
+ branch=qemu-mainline
+ revision=54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5
+ . 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 54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   0d7954c..54f3a18  54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5 -> 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 Dec 06 01:18:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 01:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xx40U-0004Y1-CC; Sat, 06 Dec 2014 01:17: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 1Xx40S-0004Xw-OY
	for xen-devel@lists.xensource.com; Sat, 06 Dec 2014 01:17:56 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	81/47-22819-34952845; Sat, 06 Dec 2014 01:17:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417828673!6577068!1
X-Originating-IP: [66.165.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 5500 invoked from network); 6 Dec 2014 01:17:54 -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;
	6 Dec 2014 01:17:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,526,1413244800"; d="scan'208";a="201037602"
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, 5 Dec 2014 20:17: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 1Xx40M-0001dR-Vm;
	Sat, 06 Dec 2014 01:17:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xx40M-0000F2-Qx;
	Sat, 06 Dec 2014 01:17:50 +0000
Date: Sat, 6 Dec 2014 01:17:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32096-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] 32096: 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 32096 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32096/

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 32029

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-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-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                54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5
baseline version:
 qemuu                0d7954c288e91b8a457f15a0a8e8244facf6594b

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@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                    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=54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5
+ . 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 54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5
+ branch=qemu-mainline
+ revision=54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5
+ . 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 54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   0d7954c..54f3a18  54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5 -> 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 Dec 06 01:42:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 01:42:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xx4O1-0005bH-NP; Sat, 06 Dec 2014 01:42:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.kilari@gmail.com>) id 1Xx4O0-0005bC-Kh
	for xen-devel@lists.xen.org; Sat, 06 Dec 2014 01:42:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FE/BC-09842-7FE52845; Sat, 06 Dec 2014 01:42:15 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417830133!13805357!1
X-Originating-IP: [209.85.223.179]
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 4920 invoked from network); 6 Dec 2014 01:42:14 -0000
Received: from mail-ie0-f179.google.com (HELO mail-ie0-f179.google.com)
	(209.85.223.179)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 01:42:14 -0000
Received: by mail-ie0-f179.google.com with SMTP id rp18so1805897iec.38
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 17:42:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:cc:subject:date:message-id;
	bh=EMSJnTvWV2AvwTmVsG62vTgknPWwIP/JUJRG2ty3G54=;
	b=mc6SKO2uJ8rdJDx0abFhxaFzHZvzJar1gDXGrmkkjW88Z+I99B/xxaGNOgbyQKaBfi
	fCGIHFPifKvTWSXk0BiFe5jQFe1ktrLfb5gqUFpKgt+8iTff6HXAN/BGeLffpVvxGxSZ
	DoGPTR2W17/ns30XpApfEqDa6TARu8gQwY8zD2lNYqFGz0f1VTBKGqakkODWvTEWF1wy
	yOEJbjRugfFHmUtJFKWJhn0OnBW3W9SJtlVv8MoOrGdoR6UBf5B05UyaVEdRbOCe+k5g
	NlKx4p57Nsn18F51Alg3oaexATMJk0grJTH1PBRNgrkhWkwVGwBRBv5He5Z/nklfISN3
	CjtA==
X-Received: by 10.50.55.41 with SMTP id o9mr5306272igp.38.1417830133563;
	Fri, 05 Dec 2014 17:42:13 -0800 (PST)
Received: from cavium-Vostro-2520.caveonetworks.com (64.2.3.194.ptr.us.xo.net.
	[64.2.3.194])
	by mx.google.com with ESMTPSA id l2sm16635910ioe.34.2014.12.05.17.42.12
	for <multiple recipients>
	(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 05 Dec 2014 17:42:13 -0800 (PST)
From: vijay.kilari@gmail.com
To: Ian.Campbell@citrix.com, julien.grall@linaro.org,
	stefano.stabellini@eu.citrix.com, stefano.stabellini@citrix.com,
	tim@xen.org, xen-devel@lists.xen.org
Date: Sat,  6 Dec 2014 07:12:04 +0530
Message-Id: <1417830124-3914-1-git-send-email-vijay.kilari@gmail.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Prasun.Kapoor@caviumnetworks.com,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, vijay.kilari@gmail.com
Subject: [Xen-devel] [RFC PATCH] xen/arm: Manage uart TX interrupt correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>

On pl011.c when TX interrupt is received and
TX buffer is empty, TX interrupt is not disabled and
hence UART interrupt routine see TX interrupt always
in MIS register and cpu loops infinitly.

With this patch, mask and umask TX interrupt
when required

Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
---
 xen/drivers/char/pl011.c  |   18 ++++++++++++++++++
 xen/drivers/char/serial.c |   30 +++++++++++++++++++++++++++++-
 xen/include/xen/serial.h  |    4 ++++
 3 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..ad48df3 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -109,6 +109,8 @@ static void __init pl011_init_preirq(struct serial_port *port)
             panic("pl011: No Baud rate configured\n");
         uart->baud = (uart->clock_hz << 2) / divisor;
     }
+    /* Trigger RX interrupt at 1/2 full, TX interrupt at 7/8 empty */
+    pl011_write(uart, IFLS, (2<<3 | 0));
     /* This write must follow FBRD and IBRD writes. */
     pl011_write(uart, LCR_H, (uart->data_bits - 5) << 5
                             | FEN
@@ -197,6 +199,20 @@ static const struct vuart_info *pl011_vuart(struct serial_port *port)
     return &uart->vuart;
 }
 
+static void pl011_tx_stop(struct serial_port *port)
+{
+    struct pl011 *uart = port->uart;
+
+    pl011_write(uart, IMSC, pl011_read(uart, IMSC) & ~(TXI));
+}
+
+static void pl011_tx_start(struct serial_port *port)
+{
+    struct pl011 *uart = port->uart;
+
+    pl011_write(uart, IMSC, pl011_read(uart, IMSC) | (TXI));
+}
+
 static struct uart_driver __read_mostly pl011_driver = {
     .init_preirq  = pl011_init_preirq,
     .init_postirq = pl011_init_postirq,
@@ -207,6 +223,8 @@ static struct uart_driver __read_mostly pl011_driver = {
     .putc         = pl011_putc,
     .getc         = pl011_getc,
     .irq          = pl011_irq,
+    .start_tx     = pl011_tx_start,
+    .stop_tx      = pl011_tx_stop,
     .vuart_info   = pl011_vuart,
 };
 
diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
index 44026b1..d2ce8a8 100644
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -76,6 +76,19 @@ void serial_tx_interrupt(struct serial_port *port, struct cpu_user_regs *regs)
         cpu_relax();
     }
 
+    if ( port->txbufc == port->txbufp )
+    {
+        /* Disable TX. nothing to send */
+        if ( port->driver->stop_tx != NULL )
+            port->driver->stop_tx(port);
+        spin_unlock(&port->tx_lock);
+        goto out;
+    }
+    else
+    {
+        if ( port->driver->tx_ready(port) && (port->driver->start_tx != NULL) )
+            port->driver->start_tx(port);
+    }
     for ( i = 0, n = port->driver->tx_ready(port); i < n; i++ )
     {
         if ( port->txbufc == port->txbufp )
@@ -117,6 +130,9 @@ static void __serial_putc(struct serial_port *port, char c)
                     cpu_relax();
                 if ( n > 0 )
                 {
+                    /* Enable TX before sending chars */
+                    if ( port->driver->start_tx != NULL )
+                        port->driver->start_tx(port);
                     while ( n-- )
                         port->driver->putc(
                             port,
@@ -135,6 +151,9 @@ static void __serial_putc(struct serial_port *port, char c)
         if ( ((port->txbufp - port->txbufc) == 0) &&
              port->driver->tx_ready(port) > 0 )
         {
+            /* Enable TX before sending chars */
+            if ( port->driver->start_tx != NULL )
+                port->driver->start_tx(port);
             /* Buffer and UART FIFO are both empty, and port is available. */
             port->driver->putc(port, c);
         }
@@ -152,11 +171,18 @@ static void __serial_putc(struct serial_port *port, char c)
         while ( !(n = port->driver->tx_ready(port)) )
             cpu_relax();
         if ( n > 0 )
+        {
+            /* Enable TX before sending chars */
+            if ( port->driver->start_tx != NULL )
+                port->driver->start_tx(port);
             port->driver->putc(port, c);
+        }
     }
     else
     {
         /* Simple synchronous transmitter. */
+        if ( port->driver->start_tx != NULL )
+            port->driver->start_tx(port);
         port->driver->putc(port, c);
     }
 }
@@ -403,7 +429,9 @@ void serial_start_sync(int handle)
             if ( n < 0 )
                 /* port is unavailable and might not come up until reenabled by
                    dom0, we can't really do proper sync */
-                break;
+                break; 
+            if ( port->driver->start_tx != NULL )
+                port->driver->start_tx(port);
             port->driver->putc(
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);
         }
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 9f4451b..71e6ade 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -81,6 +81,10 @@ struct uart_driver {
     int  (*getc)(struct serial_port *, char *);
     /* Get IRQ number for this port's serial line: returns -1 if none. */
     int  (*irq)(struct serial_port *);
+    /* Unmask TX interrupt */
+    void  (*start_tx)(struct serial_port *);
+    /* Mask TX interrupt */
+    void  (*stop_tx)(struct serial_port *);
     /* Get serial information */
     const struct vuart_info *(*vuart_info)(struct serial_port *);
 };
-- 
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 Sat Dec 06 01:42:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 01:42:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xx4O1-0005bH-NP; Sat, 06 Dec 2014 01:42:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.kilari@gmail.com>) id 1Xx4O0-0005bC-Kh
	for xen-devel@lists.xen.org; Sat, 06 Dec 2014 01:42:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FE/BC-09842-7FE52845; Sat, 06 Dec 2014 01:42:15 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417830133!13805357!1
X-Originating-IP: [209.85.223.179]
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 4920 invoked from network); 6 Dec 2014 01:42:14 -0000
Received: from mail-ie0-f179.google.com (HELO mail-ie0-f179.google.com)
	(209.85.223.179)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 01:42:14 -0000
Received: by mail-ie0-f179.google.com with SMTP id rp18so1805897iec.38
	for <xen-devel@lists.xen.org>; Fri, 05 Dec 2014 17:42:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:cc:subject:date:message-id;
	bh=EMSJnTvWV2AvwTmVsG62vTgknPWwIP/JUJRG2ty3G54=;
	b=mc6SKO2uJ8rdJDx0abFhxaFzHZvzJar1gDXGrmkkjW88Z+I99B/xxaGNOgbyQKaBfi
	fCGIHFPifKvTWSXk0BiFe5jQFe1ktrLfb5gqUFpKgt+8iTff6HXAN/BGeLffpVvxGxSZ
	DoGPTR2W17/ns30XpApfEqDa6TARu8gQwY8zD2lNYqFGz0f1VTBKGqakkODWvTEWF1wy
	yOEJbjRugfFHmUtJFKWJhn0OnBW3W9SJtlVv8MoOrGdoR6UBf5B05UyaVEdRbOCe+k5g
	NlKx4p57Nsn18F51Alg3oaexATMJk0grJTH1PBRNgrkhWkwVGwBRBv5He5Z/nklfISN3
	CjtA==
X-Received: by 10.50.55.41 with SMTP id o9mr5306272igp.38.1417830133563;
	Fri, 05 Dec 2014 17:42:13 -0800 (PST)
Received: from cavium-Vostro-2520.caveonetworks.com (64.2.3.194.ptr.us.xo.net.
	[64.2.3.194])
	by mx.google.com with ESMTPSA id l2sm16635910ioe.34.2014.12.05.17.42.12
	for <multiple recipients>
	(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 05 Dec 2014 17:42:13 -0800 (PST)
From: vijay.kilari@gmail.com
To: Ian.Campbell@citrix.com, julien.grall@linaro.org,
	stefano.stabellini@eu.citrix.com, stefano.stabellini@citrix.com,
	tim@xen.org, xen-devel@lists.xen.org
Date: Sat,  6 Dec 2014 07:12:04 +0530
Message-Id: <1417830124-3914-1-git-send-email-vijay.kilari@gmail.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Prasun.Kapoor@caviumnetworks.com,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, vijay.kilari@gmail.com
Subject: [Xen-devel] [RFC PATCH] xen/arm: Manage uart TX interrupt correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>

On pl011.c when TX interrupt is received and
TX buffer is empty, TX interrupt is not disabled and
hence UART interrupt routine see TX interrupt always
in MIS register and cpu loops infinitly.

With this patch, mask and umask TX interrupt
when required

Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
---
 xen/drivers/char/pl011.c  |   18 ++++++++++++++++++
 xen/drivers/char/serial.c |   30 +++++++++++++++++++++++++++++-
 xen/include/xen/serial.h  |    4 ++++
 3 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..ad48df3 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -109,6 +109,8 @@ static void __init pl011_init_preirq(struct serial_port *port)
             panic("pl011: No Baud rate configured\n");
         uart->baud = (uart->clock_hz << 2) / divisor;
     }
+    /* Trigger RX interrupt at 1/2 full, TX interrupt at 7/8 empty */
+    pl011_write(uart, IFLS, (2<<3 | 0));
     /* This write must follow FBRD and IBRD writes. */
     pl011_write(uart, LCR_H, (uart->data_bits - 5) << 5
                             | FEN
@@ -197,6 +199,20 @@ static const struct vuart_info *pl011_vuart(struct serial_port *port)
     return &uart->vuart;
 }
 
+static void pl011_tx_stop(struct serial_port *port)
+{
+    struct pl011 *uart = port->uart;
+
+    pl011_write(uart, IMSC, pl011_read(uart, IMSC) & ~(TXI));
+}
+
+static void pl011_tx_start(struct serial_port *port)
+{
+    struct pl011 *uart = port->uart;
+
+    pl011_write(uart, IMSC, pl011_read(uart, IMSC) | (TXI));
+}
+
 static struct uart_driver __read_mostly pl011_driver = {
     .init_preirq  = pl011_init_preirq,
     .init_postirq = pl011_init_postirq,
@@ -207,6 +223,8 @@ static struct uart_driver __read_mostly pl011_driver = {
     .putc         = pl011_putc,
     .getc         = pl011_getc,
     .irq          = pl011_irq,
+    .start_tx     = pl011_tx_start,
+    .stop_tx      = pl011_tx_stop,
     .vuart_info   = pl011_vuart,
 };
 
diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
index 44026b1..d2ce8a8 100644
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -76,6 +76,19 @@ void serial_tx_interrupt(struct serial_port *port, struct cpu_user_regs *regs)
         cpu_relax();
     }
 
+    if ( port->txbufc == port->txbufp )
+    {
+        /* Disable TX. nothing to send */
+        if ( port->driver->stop_tx != NULL )
+            port->driver->stop_tx(port);
+        spin_unlock(&port->tx_lock);
+        goto out;
+    }
+    else
+    {
+        if ( port->driver->tx_ready(port) && (port->driver->start_tx != NULL) )
+            port->driver->start_tx(port);
+    }
     for ( i = 0, n = port->driver->tx_ready(port); i < n; i++ )
     {
         if ( port->txbufc == port->txbufp )
@@ -117,6 +130,9 @@ static void __serial_putc(struct serial_port *port, char c)
                     cpu_relax();
                 if ( n > 0 )
                 {
+                    /* Enable TX before sending chars */
+                    if ( port->driver->start_tx != NULL )
+                        port->driver->start_tx(port);
                     while ( n-- )
                         port->driver->putc(
                             port,
@@ -135,6 +151,9 @@ static void __serial_putc(struct serial_port *port, char c)
         if ( ((port->txbufp - port->txbufc) == 0) &&
              port->driver->tx_ready(port) > 0 )
         {
+            /* Enable TX before sending chars */
+            if ( port->driver->start_tx != NULL )
+                port->driver->start_tx(port);
             /* Buffer and UART FIFO are both empty, and port is available. */
             port->driver->putc(port, c);
         }
@@ -152,11 +171,18 @@ static void __serial_putc(struct serial_port *port, char c)
         while ( !(n = port->driver->tx_ready(port)) )
             cpu_relax();
         if ( n > 0 )
+        {
+            /* Enable TX before sending chars */
+            if ( port->driver->start_tx != NULL )
+                port->driver->start_tx(port);
             port->driver->putc(port, c);
+        }
     }
     else
     {
         /* Simple synchronous transmitter. */
+        if ( port->driver->start_tx != NULL )
+            port->driver->start_tx(port);
         port->driver->putc(port, c);
     }
 }
@@ -403,7 +429,9 @@ void serial_start_sync(int handle)
             if ( n < 0 )
                 /* port is unavailable and might not come up until reenabled by
                    dom0, we can't really do proper sync */
-                break;
+                break; 
+            if ( port->driver->start_tx != NULL )
+                port->driver->start_tx(port);
             port->driver->putc(
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);
         }
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 9f4451b..71e6ade 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -81,6 +81,10 @@ struct uart_driver {
     int  (*getc)(struct serial_port *, char *);
     /* Get IRQ number for this port's serial line: returns -1 if none. */
     int  (*irq)(struct serial_port *);
+    /* Unmask TX interrupt */
+    void  (*start_tx)(struct serial_port *);
+    /* Mask TX interrupt */
+    void  (*stop_tx)(struct serial_port *);
     /* Get serial information */
     const struct vuart_info *(*vuart_info)(struct serial_port *);
 };
-- 
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 Sat Dec 06 01:51:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 01:51:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xx4W8-0005lw-Mf; Sat, 06 Dec 2014 01:50:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xx4W7-0005lr-NI
	for xen-devel@lists.xenproject.org; Sat, 06 Dec 2014 01:50:39 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	8E/89-02954-FE062845; Sat, 06 Dec 2014 01:50:39 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417830636!13368799!1
X-Originating-IP: [156.151.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 6371 invoked from network); 6 Dec 2014 01:50:38 -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 Dec 2014 01:50: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 sB61oW3p020079
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 6 Dec 2014 01:50: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
	sB61oVDx021731
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 6 Dec 2014 01:50:32 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
	sB61oVHH021333; Sat, 6 Dec 2014 01:50:31 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 17:50:31 -0800
Date: Fri, 5 Dec 2014 17:50:30 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20141205175030.32cb60a1@mantra.us.oracle.com>
In-Reply-To: <5481CA0D020000780004D2E8@mail.emea.novell.com>
References: <5481CA0D020000780004D2E8@mail.emea.novell.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] VMX: don't allow PVH to reach handle_pio()
 or handle_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAwNSBEZWMgMjAxNCAxNDowNjo1MyArMDAwMAoiSmFuIEJldWxpY2giIDxKQmV1bGlj
aEBzdXNlLmNvbT4gd3JvdGU6Cgo+IFBWSCBndWVzdHMgYXJlIG5vdCBzdXBwb3NlZCB0byBhY2Nl
c3MgSS9PIHBvcnRzIHRoZXkgd2VyZW4ndCBnaXZlbgo+IGFjY2VzcyB0byAodGhlcmUncyBub3Ro
aW5nIHRvIGhhbmRsZSBlbXVsYXRpb24gb2Ygc3VjaCBhY2Nlc3NlcykuCj4gCj4gUmVwb3J0ZWQt
Ynk6IFJvZ2VyIFBhdSBNb25uw6k8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4gU2lnbmVkLW9mZi1i
eTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgo+IC0tLQo+IE5vdGU6IE9ubHkgY29t
cGlsZSB0ZXN0ZWQgc28gZmFyLgo+IAo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5j
Cj4gKysrIGIveGVuL2FyY2gveDg2L2h2bS92bXgvdm14LmMKPiBAQCAtMzA4Miw2ICszMDgyLDkg
QEAgdm9pZCB2bXhfdm1leGl0X2hhbmRsZXIoc3RydWN0IGNwdV91c2VyXwo+ICAgICAgfQo+ICAK
PiAgICAgIGNhc2UgRVhJVF9SRUFTT05fSU9fSU5TVFJVQ1RJT046Cj4gKyAgICAgICAgaWYgKCB1
bmxpa2VseShpc19wdmhfdmNwdSh2KSkgKQo+ICsgICAgICAgICAgICBnb3RvIGV4aXRfYW5kX2Ny
YXNoOwo+ICsKPiAgICAgICAgICBfX3ZtcmVhZChFWElUX1FVQUxJRklDQVRJT04sICZleGl0X3F1
YWxpZmljYXRpb24pOwo+ICAgICAgICAgIGlmICggZXhpdF9xdWFsaWZpY2F0aW9uICYgMHgxMCAp
Cj4gICAgICAgICAgewoKQWN0dWFsbHksIGhhbmRsZV9waW8oKSB3aWxsIGV2ZW50dWFsbHkgcmVh
Y2ggaGFuZGxlX3B2aF9pbygpIHdoaWNoCndvdWxkIGFjY2VzcyBjaGVjayB2aWEgYWRtaW5faW9f
b2theSwgc28gdGhhdCBwYXRoIHNob3VsZCBiZSBPSywKcmlnaHQ/Cgp0aGFua3MsCk11a2VzaAoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sat Dec 06 01:51:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 01:51:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xx4W8-0005lw-Mf; Sat, 06 Dec 2014 01:50:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xx4W7-0005lr-NI
	for xen-devel@lists.xenproject.org; Sat, 06 Dec 2014 01:50:39 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	8E/89-02954-FE062845; Sat, 06 Dec 2014 01:50:39 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1417830636!13368799!1
X-Originating-IP: [156.151.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 6371 invoked from network); 6 Dec 2014 01:50:38 -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 Dec 2014 01:50: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 sB61oW3p020079
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 6 Dec 2014 01:50: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
	sB61oVDx021731
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 6 Dec 2014 01:50:32 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
	sB61oVHH021333; Sat, 6 Dec 2014 01:50:31 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 05 Dec 2014 17:50:31 -0800
Date: Fri, 5 Dec 2014 17:50:30 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20141205175030.32cb60a1@mantra.us.oracle.com>
In-Reply-To: <5481CA0D020000780004D2E8@mail.emea.novell.com>
References: <5481CA0D020000780004D2E8@mail.emea.novell.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] VMX: don't allow PVH to reach handle_pio()
 or handle_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAwNSBEZWMgMjAxNCAxNDowNjo1MyArMDAwMAoiSmFuIEJldWxpY2giIDxKQmV1bGlj
aEBzdXNlLmNvbT4gd3JvdGU6Cgo+IFBWSCBndWVzdHMgYXJlIG5vdCBzdXBwb3NlZCB0byBhY2Nl
c3MgSS9PIHBvcnRzIHRoZXkgd2VyZW4ndCBnaXZlbgo+IGFjY2VzcyB0byAodGhlcmUncyBub3Ro
aW5nIHRvIGhhbmRsZSBlbXVsYXRpb24gb2Ygc3VjaCBhY2Nlc3NlcykuCj4gCj4gUmVwb3J0ZWQt
Ynk6IFJvZ2VyIFBhdSBNb25uw6k8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4gU2lnbmVkLW9mZi1i
eTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgo+IC0tLQo+IE5vdGU6IE9ubHkgY29t
cGlsZSB0ZXN0ZWQgc28gZmFyLgo+IAo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5j
Cj4gKysrIGIveGVuL2FyY2gveDg2L2h2bS92bXgvdm14LmMKPiBAQCAtMzA4Miw2ICszMDgyLDkg
QEAgdm9pZCB2bXhfdm1leGl0X2hhbmRsZXIoc3RydWN0IGNwdV91c2VyXwo+ICAgICAgfQo+ICAK
PiAgICAgIGNhc2UgRVhJVF9SRUFTT05fSU9fSU5TVFJVQ1RJT046Cj4gKyAgICAgICAgaWYgKCB1
bmxpa2VseShpc19wdmhfdmNwdSh2KSkgKQo+ICsgICAgICAgICAgICBnb3RvIGV4aXRfYW5kX2Ny
YXNoOwo+ICsKPiAgICAgICAgICBfX3ZtcmVhZChFWElUX1FVQUxJRklDQVRJT04sICZleGl0X3F1
YWxpZmljYXRpb24pOwo+ICAgICAgICAgIGlmICggZXhpdF9xdWFsaWZpY2F0aW9uICYgMHgxMCAp
Cj4gICAgICAgICAgewoKQWN0dWFsbHksIGhhbmRsZV9waW8oKSB3aWxsIGV2ZW50dWFsbHkgcmVh
Y2ggaGFuZGxlX3B2aF9pbygpIHdoaWNoCndvdWxkIGFjY2VzcyBjaGVjayB2aWEgYWRtaW5faW9f
b2theSwgc28gdGhhdCBwYXRoIHNob3VsZCBiZSBPSywKcmlnaHQ/Cgp0aGFua3MsCk11a2VzaAoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sat Dec 06 04:27:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 04: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 1Xx6wn-0001S7-Qt; Sat, 06 Dec 2014 04:26:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1Xx6wl-0001Rk-VL
	for Xen-devel@lists.xen.org; Sat, 06 Dec 2014 04:26:20 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	02/98-03148-B6582845; Sat, 06 Dec 2014 04:26:19 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417839976!13380401!2
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 28039 invoked from network); 6 Dec 2014 04:26:17 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-27.messagelabs.com with SMTP;
	6 Dec 2014 04:26:17 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 05 Dec 2014 20:25:58 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,527,1413270000"; d="scan'208";a="643334921"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by fmsmga002.fm.intel.com with ESMTP; 05 Dec 2014 20:25:56 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Sat,  6 Dec 2014 11:55:36 +0800
Message-Id: <1417838137-12473-2-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
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 v6 1/2] add a new p2m type class -
	P2M_DISCARD_WRITE_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Yu Zhang <yu.c.zhang@intel.com>

Currently, the P2M_RO_TYPES bears 2 meanings: one is
"_PAGE_RW bit is clear in their PTEs", and another is
to discard the write operations on these pages. This
patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
to bear the second meaning, so we can use this type
class instead of the P2M_RO_TYPES, to decide if a write
operation is to be ignored.

Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
Reviewed-by: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/hvm/hvm.c         | 16 +++-------------
 xen/arch/x86/mm/shadow/multi.c |  2 +-
 xen/include/asm-x86/p2m.h      |  5 +++++
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 51ffc90..967f822 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2837,7 +2837,7 @@ 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 && (p2m_is_discard_write(p2mt))) )
     {
         put_gfn(p2m->domain, gfn);
 
@@ -2882,16 +2882,6 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
         goto out_put_gfn;
     }
 
-    /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
-    if ( npfec.write_access && (p2mt == p2m_grant_map_ro) )
-    {
-        gdprintk(XENLOG_WARNING,
-                 "trying to write to read-only grant mapping\n");
-        hvm_inject_hw_exception(TRAP_gp_fault, 0);
-        rc = 1;
-        goto out_put_gfn;
-    }
-
     /* If we fell through, the vcpu will retry now that access restrictions have
      * been removed. It may fault again if the p2m entry type still requires so.
      * Otherwise, this is an error condition. */
@@ -3941,7 +3931,7 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( flags & HVMCOPY_to_guest )
         {
-            if ( p2mt == p2m_ram_ro )
+            if ( p2m_is_discard_write(p2mt) )
             {
                 static unsigned long lastpage;
                 if ( xchg(&lastpage, gfn) != gfn )
@@ -4035,7 +4025,7 @@ static enum hvm_copy_result __hvm_clear(paddr_t addr, int size)
 
         p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
-        if ( p2mt == p2m_ram_ro )
+        if ( p2m_is_discard_write(p2mt) )
         {
             static unsigned long lastpage;
             if ( xchg(&lastpage, gfn) != gfn )
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 225290e..94cf06d 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4575,7 +4575,7 @@ static mfn_t emulate_gva_to_mfn(struct vcpu *v,
     {
         return _mfn(BAD_GFN_TO_MFN);
     }
-    if ( p2m_is_readonly(p2mt) )
+    if ( p2m_is_discard_write(p2mt) )
     {
         put_page(page);
         return _mfn(READONLY_GFN);
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 5f7fe71..42de75d 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -113,6 +113,10 @@ typedef unsigned int p2m_query_t;
                       | p2m_to_mask(p2m_grant_map_ro)   \
                       | p2m_to_mask(p2m_ram_shared) )
 
+/* Write-discard types, which should discard the write operations */
+#define P2M_DISCARD_WRITE_TYPES (p2m_to_mask(p2m_ram_ro)     \
+                      | p2m_to_mask(p2m_grant_map_ro))
+
 /* Types that can be subject to bulk transitions. */
 #define P2M_CHANGEABLE_TYPES (p2m_to_mask(p2m_ram_rw) \
                               | p2m_to_mask(p2m_ram_logdirty) )
@@ -145,6 +149,7 @@ typedef unsigned int p2m_query_t;
 #define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
 #define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
 #define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
+#define p2m_is_discard_write(_t) (p2m_to_mask(_t) & P2M_DISCARD_WRITE_TYPES)
 #define p2m_is_changeable(_t) (p2m_to_mask(_t) & P2M_CHANGEABLE_TYPES)
 #define p2m_is_pod(_t) (p2m_to_mask(_t) & P2M_POD_TYPES)
 #define p2m_is_grant(_t) (p2m_to_mask(_t) & P2M_GRANT_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 Sat Dec 06 04:27:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 04: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 1Xx6wm-0001Rt-DG; Sat, 06 Dec 2014 04:26:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1Xx6wk-0001Re-9A
	for Xen-devel@lists.xen.org; Sat, 06 Dec 2014 04:26:18 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	70/98-03148-96582845; Sat, 06 Dec 2014 04:26:17 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417839976!13380401!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 28026 invoked from network); 6 Dec 2014 04:26:16 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-27.messagelabs.com with SMTP;
	6 Dec 2014 04:26:16 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 05 Dec 2014 20:25:55 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,527,1413270000"; d="scan'208";a="643334909"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by fmsmga002.fm.intel.com with ESMTP; 05 Dec 2014 20:25:53 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Sat,  6 Dec 2014 11:55:35 +0800
Message-Id: <1417838137-12473-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 v6 0/2] add new p2m type class and new p2m 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

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 added
a new p2m type, p2m_mmio_write_dm, to trap and emulate the write
operations 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_ram_ro types, write operations will not
trigger the device model, and will be discarded later in __hvm_copy();
while for the 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 v5:
 - Stricter type checks for p2m type transitions;
 - One code style change.

Changes from v4:
 - A new p2m type class, P2M_DISCARD_WRITE_TYPES, is added;
 - A new predicate, p2m_is_discard_write, is used in __hvm_copy()/
   __hvm_clear()/emulate_gva_to_mfn()/hvm_hap_nested_page_fault(),
   to discard the write operations;
 - The new p2m type, p2m_mmio_write_dm, is added to P2M_RO_TYPES;
 - Coding style changes;

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.

Yu Zhang (2):
  Add a new p2m type class - P2M_DISCARD_WRITE_TYPES
  add a new p2m type - p2m_mmio_write_dm

 xen/arch/x86/hvm/hvm.c          | 25 ++++++++++---------------
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/include/asm-x86/p2m.h       |  9 ++++++++-
 xen/include/public/hvm/hvm_op.h |  1 +
 6 files changed, 22 insertions(+), 17 deletions(-)

-- 
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 Sat Dec 06 04:27:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 04: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 1Xx6wn-0001S0-8E; Sat, 06 Dec 2014 04:26:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1Xx6wl-0001Rj-Iq
	for Xen-devel@lists.xen.org; Sat, 06 Dec 2014 04:26:19 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	7B/26-02696-A6582845; Sat, 06 Dec 2014 04:26:18 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417839977!13380402!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 28047 invoked from network); 6 Dec 2014 04:26:17 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-27.messagelabs.com with SMTP;
	6 Dec 2014 04:26:17 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 05 Dec 2014 20:26:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,527,1413270000"; d="scan'208";a="643334930"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by fmsmga002.fm.intel.com with ESMTP; 05 Dec 2014 20:25:58 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Sat,  6 Dec 2014 11:55:37 +0800
Message-Id: <1417838137-12473-3-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
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 v6 2/2] add a new p2m type - 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

From: Yu Zhang <yu.c.zhang@intel.com>

A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
model, and will be discarded later in __hvm_copy(); while for the
p2m_mmio_write_dm type pages, writes will go to the device model
via ioreq-server.

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          | 11 ++++++++---
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/include/asm-x86/p2m.h       |  4 +++-
 xen/include/public/hvm/hvm_op.h |  1 +
 5 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 967f822..25114fc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2837,7 +2837,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 && (p2m_is_discard_write(p2mt))) )
+         (npfec.write_access &&
+          (p2m_is_discard_write(p2mt) || (p2mt == p2m_mmio_write_dm))) )
     {
         put_gfn(p2m->domain, gfn);
 
@@ -5904,6 +5905,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
             get_gfn_query_unlocked(d, a.pfn, &t);
             if ( p2m_is_mmio(t) )
                 a.mem_type =  HVMMEM_mmio_dm;
+            else if ( t == p2m_mmio_write_dm )
+                a.mem_type = HVMMEM_mmio_write_dm;
             else if ( p2m_is_readonly(t) )
                 a.mem_type =  HVMMEM_ram_ro;
             else if ( p2m_is_ram(t) )
@@ -5931,7 +5934,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) )
@@ -5978,7 +5982,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
                 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 || a.hvmmem_type != HVMMEM_ram_rw) )
             {
                 put_gfn(d, pfn);
                 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 42de75d..2cf73ca 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 */
@@ -111,7 +112,8 @@ typedef unsigned int p2m_query_t;
 #define P2M_RO_TYPES (p2m_to_mask(p2m_ram_logdirty)     \
                       | p2m_to_mask(p2m_ram_ro)         \
                       | p2m_to_mask(p2m_grant_map_ro)   \
-                      | p2m_to_mask(p2m_ram_shared) )
+                      | p2m_to_mask(p2m_ram_shared)     \
+                      | p2m_to_mask(p2m_mmio_write_dm))
 
 /* Write-discard types, which should discard the write operations */
 #define P2M_DISCARD_WRITE_TYPES (p2m_to_mask(p2m_ram_ro)     \
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 Sat Dec 06 04:27:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 04: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 1Xx6wm-0001Rt-DG; Sat, 06 Dec 2014 04:26:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1Xx6wk-0001Re-9A
	for Xen-devel@lists.xen.org; Sat, 06 Dec 2014 04:26:18 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	70/98-03148-96582845; Sat, 06 Dec 2014 04:26:17 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417839976!13380401!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 28026 invoked from network); 6 Dec 2014 04:26:16 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-27.messagelabs.com with SMTP;
	6 Dec 2014 04:26:16 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 05 Dec 2014 20:25:55 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,527,1413270000"; d="scan'208";a="643334909"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by fmsmga002.fm.intel.com with ESMTP; 05 Dec 2014 20:25:53 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Sat,  6 Dec 2014 11:55:35 +0800
Message-Id: <1417838137-12473-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 v6 0/2] add new p2m type class and new p2m 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

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 added
a new p2m type, p2m_mmio_write_dm, to trap and emulate the write
operations 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_ram_ro types, write operations will not
trigger the device model, and will be discarded later in __hvm_copy();
while for the 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 v5:
 - Stricter type checks for p2m type transitions;
 - One code style change.

Changes from v4:
 - A new p2m type class, P2M_DISCARD_WRITE_TYPES, is added;
 - A new predicate, p2m_is_discard_write, is used in __hvm_copy()/
   __hvm_clear()/emulate_gva_to_mfn()/hvm_hap_nested_page_fault(),
   to discard the write operations;
 - The new p2m type, p2m_mmio_write_dm, is added to P2M_RO_TYPES;
 - Coding style changes;

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.

Yu Zhang (2):
  Add a new p2m type class - P2M_DISCARD_WRITE_TYPES
  add a new p2m type - p2m_mmio_write_dm

 xen/arch/x86/hvm/hvm.c          | 25 ++++++++++---------------
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/include/asm-x86/p2m.h       |  9 ++++++++-
 xen/include/public/hvm/hvm_op.h |  1 +
 6 files changed, 22 insertions(+), 17 deletions(-)

-- 
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 Sat Dec 06 04:27:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 04: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 1Xx6wn-0001S0-8E; Sat, 06 Dec 2014 04:26:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1Xx6wl-0001Rj-Iq
	for Xen-devel@lists.xen.org; Sat, 06 Dec 2014 04:26:19 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	7B/26-02696-A6582845; Sat, 06 Dec 2014 04:26:18 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417839977!13380402!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 28047 invoked from network); 6 Dec 2014 04:26:17 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-27.messagelabs.com with SMTP;
	6 Dec 2014 04:26:17 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 05 Dec 2014 20:26:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,527,1413270000"; d="scan'208";a="643334930"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by fmsmga002.fm.intel.com with ESMTP; 05 Dec 2014 20:25:58 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Sat,  6 Dec 2014 11:55:37 +0800
Message-Id: <1417838137-12473-3-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
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 v6 2/2] add a new p2m type - 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

From: Yu Zhang <yu.c.zhang@intel.com>

A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
model, and will be discarded later in __hvm_copy(); while for the
p2m_mmio_write_dm type pages, writes will go to the device model
via ioreq-server.

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          | 11 ++++++++---
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/include/asm-x86/p2m.h       |  4 +++-
 xen/include/public/hvm/hvm_op.h |  1 +
 5 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 967f822..25114fc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2837,7 +2837,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 && (p2m_is_discard_write(p2mt))) )
+         (npfec.write_access &&
+          (p2m_is_discard_write(p2mt) || (p2mt == p2m_mmio_write_dm))) )
     {
         put_gfn(p2m->domain, gfn);
 
@@ -5904,6 +5905,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
             get_gfn_query_unlocked(d, a.pfn, &t);
             if ( p2m_is_mmio(t) )
                 a.mem_type =  HVMMEM_mmio_dm;
+            else if ( t == p2m_mmio_write_dm )
+                a.mem_type = HVMMEM_mmio_write_dm;
             else if ( p2m_is_readonly(t) )
                 a.mem_type =  HVMMEM_ram_ro;
             else if ( p2m_is_ram(t) )
@@ -5931,7 +5934,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) )
@@ -5978,7 +5982,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
                 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 || a.hvmmem_type != HVMMEM_ram_rw) )
             {
                 put_gfn(d, pfn);
                 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 42de75d..2cf73ca 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 */
@@ -111,7 +112,8 @@ typedef unsigned int p2m_query_t;
 #define P2M_RO_TYPES (p2m_to_mask(p2m_ram_logdirty)     \
                       | p2m_to_mask(p2m_ram_ro)         \
                       | p2m_to_mask(p2m_grant_map_ro)   \
-                      | p2m_to_mask(p2m_ram_shared) )
+                      | p2m_to_mask(p2m_ram_shared)     \
+                      | p2m_to_mask(p2m_mmio_write_dm))
 
 /* Write-discard types, which should discard the write operations */
 #define P2M_DISCARD_WRITE_TYPES (p2m_to_mask(p2m_ram_ro)     \
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 Sat Dec 06 04:27:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 04: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 1Xx6wn-0001S7-Qt; Sat, 06 Dec 2014 04:26:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1Xx6wl-0001Rk-VL
	for Xen-devel@lists.xen.org; Sat, 06 Dec 2014 04:26:20 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	02/98-03148-B6582845; Sat, 06 Dec 2014 04:26:19 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1417839976!13380401!2
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 28039 invoked from network); 6 Dec 2014 04:26:17 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-27.messagelabs.com with SMTP;
	6 Dec 2014 04:26:17 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 05 Dec 2014 20:25:58 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,527,1413270000"; d="scan'208";a="643334921"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by fmsmga002.fm.intel.com with ESMTP; 05 Dec 2014 20:25:56 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Sat,  6 Dec 2014 11:55:36 +0800
Message-Id: <1417838137-12473-2-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
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 v6 1/2] add a new p2m type class -
	P2M_DISCARD_WRITE_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Yu Zhang <yu.c.zhang@intel.com>

Currently, the P2M_RO_TYPES bears 2 meanings: one is
"_PAGE_RW bit is clear in their PTEs", and another is
to discard the write operations on these pages. This
patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
to bear the second meaning, so we can use this type
class instead of the P2M_RO_TYPES, to decide if a write
operation is to be ignored.

Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
Reviewed-by: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/hvm/hvm.c         | 16 +++-------------
 xen/arch/x86/mm/shadow/multi.c |  2 +-
 xen/include/asm-x86/p2m.h      |  5 +++++
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 51ffc90..967f822 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2837,7 +2837,7 @@ 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 && (p2m_is_discard_write(p2mt))) )
     {
         put_gfn(p2m->domain, gfn);
 
@@ -2882,16 +2882,6 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
         goto out_put_gfn;
     }
 
-    /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
-    if ( npfec.write_access && (p2mt == p2m_grant_map_ro) )
-    {
-        gdprintk(XENLOG_WARNING,
-                 "trying to write to read-only grant mapping\n");
-        hvm_inject_hw_exception(TRAP_gp_fault, 0);
-        rc = 1;
-        goto out_put_gfn;
-    }
-
     /* If we fell through, the vcpu will retry now that access restrictions have
      * been removed. It may fault again if the p2m entry type still requires so.
      * Otherwise, this is an error condition. */
@@ -3941,7 +3931,7 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( flags & HVMCOPY_to_guest )
         {
-            if ( p2mt == p2m_ram_ro )
+            if ( p2m_is_discard_write(p2mt) )
             {
                 static unsigned long lastpage;
                 if ( xchg(&lastpage, gfn) != gfn )
@@ -4035,7 +4025,7 @@ static enum hvm_copy_result __hvm_clear(paddr_t addr, int size)
 
         p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
-        if ( p2mt == p2m_ram_ro )
+        if ( p2m_is_discard_write(p2mt) )
         {
             static unsigned long lastpage;
             if ( xchg(&lastpage, gfn) != gfn )
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 225290e..94cf06d 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4575,7 +4575,7 @@ static mfn_t emulate_gva_to_mfn(struct vcpu *v,
     {
         return _mfn(BAD_GFN_TO_MFN);
     }
-    if ( p2m_is_readonly(p2mt) )
+    if ( p2m_is_discard_write(p2mt) )
     {
         put_page(page);
         return _mfn(READONLY_GFN);
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 5f7fe71..42de75d 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -113,6 +113,10 @@ typedef unsigned int p2m_query_t;
                       | p2m_to_mask(p2m_grant_map_ro)   \
                       | p2m_to_mask(p2m_ram_shared) )
 
+/* Write-discard types, which should discard the write operations */
+#define P2M_DISCARD_WRITE_TYPES (p2m_to_mask(p2m_ram_ro)     \
+                      | p2m_to_mask(p2m_grant_map_ro))
+
 /* Types that can be subject to bulk transitions. */
 #define P2M_CHANGEABLE_TYPES (p2m_to_mask(p2m_ram_rw) \
                               | p2m_to_mask(p2m_ram_logdirty) )
@@ -145,6 +149,7 @@ typedef unsigned int p2m_query_t;
 #define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
 #define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
 #define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
+#define p2m_is_discard_write(_t) (p2m_to_mask(_t) & P2M_DISCARD_WRITE_TYPES)
 #define p2m_is_changeable(_t) (p2m_to_mask(_t) & P2M_CHANGEABLE_TYPES)
 #define p2m_is_pod(_t) (p2m_to_mask(_t) & P2M_POD_TYPES)
 #define p2m_is_grant(_t) (p2m_to_mask(_t) & P2M_GRANT_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 Sat Dec 06 06:14:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 06:14:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xx8d1-0004bZ-3H; Sat, 06 Dec 2014 06:14: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 1Xx8cy-0004bU-PW
	for xen-devel@lists.xensource.com; Sat, 06 Dec 2014 06:14:00 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	44/E4-27785-7AE92845; Sat, 06 Dec 2014 06:13:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417846437!13386417!1
X-Originating-IP: [66.165.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 16016 invoked from network); 6 Dec 2014 06:13:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 06:13:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,528,1413244800"; d="scan'208";a="201118217"
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, 6 Dec 2014 01:13: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 1Xx8cu-00033d-9B;
	Sat, 06 Dec 2014 06:13:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xx8cu-0003wZ-2J;
	Sat, 06 Dec 2014 06:13:56 +0000
Date: Sat, 6 Dec 2014 06:13:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32102-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 3494
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32102: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4042072277191401247=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4042072277191401247==
Content-Type: text/plain
Content-Length: 3107
Content-Transfer-Encoding: quoted-printable

flight 32102 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32102/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32005
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32005
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32005

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              9d31a0e4f6be9f90c0ccefa9b49463fb8da98a9c
baseline version:
 libvirt              ff018e686a8a412255bc34d3dc558a1bcf74fac5

------------------------------------------------------------
People who touched revisions under test:
  Cole Robinson <crobinso@redhat.com>
  Conrad Meyer <cse.cem@gmail.com>
  Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
  Daniel P. Berrange <berrange@redhat.com>
  Dmitry Guryanov <dguryanov@parallels.com>
  Erik Skultety <eskultet@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Laine Stump <laine@laine.org>
  Luyao Huang <lhuang@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>
  Shanzhi Yu <shyu@redhat.com>
  Wang Rui <moon.wangrui@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 610 lines long.)


--===============4042072277191401247==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4042072277191401247==--

From xen-devel-bounces@lists.xen.org Sat Dec 06 06:14:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 06:14:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xx8d1-0004bZ-3H; Sat, 06 Dec 2014 06:14: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 1Xx8cy-0004bU-PW
	for xen-devel@lists.xensource.com; Sat, 06 Dec 2014 06:14:00 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	44/E4-27785-7AE92845; Sat, 06 Dec 2014 06:13:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1417846437!13386417!1
X-Originating-IP: [66.165.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 16016 invoked from network); 6 Dec 2014 06:13:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 06:13:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,528,1413244800"; d="scan'208";a="201118217"
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, 6 Dec 2014 01:13: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 1Xx8cu-00033d-9B;
	Sat, 06 Dec 2014 06:13:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xx8cu-0003wZ-2J;
	Sat, 06 Dec 2014 06:13:56 +0000
Date: Sat, 6 Dec 2014 06:13:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32102-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 3494
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32102: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4042072277191401247=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4042072277191401247==
Content-Type: text/plain
Content-Length: 3107
Content-Transfer-Encoding: quoted-printable

flight 32102 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32102/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32005
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32005
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32005

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              9d31a0e4f6be9f90c0ccefa9b49463fb8da98a9c
baseline version:
 libvirt              ff018e686a8a412255bc34d3dc558a1bcf74fac5

------------------------------------------------------------
People who touched revisions under test:
  Cole Robinson <crobinso@redhat.com>
  Conrad Meyer <cse.cem@gmail.com>
  Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
  Daniel P. Berrange <berrange@redhat.com>
  Dmitry Guryanov <dguryanov@parallels.com>
  Erik Skultety <eskultet@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Laine Stump <laine@laine.org>
  Luyao Huang <lhuang@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>
  Shanzhi Yu <shyu@redhat.com>
  Wang Rui <moon.wangrui@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 610 lines long.)


--===============4042072277191401247==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4042072277191401247==--

From xen-devel-bounces@lists.xen.org Sat Dec 06 08:59:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 08:59:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxBCF-0000TO-HC; Sat, 06 Dec 2014 08:58:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sagun@nexchanges.com>) id 1XxBCE-0000TJ-BK
	for xen-devel@lists.xen.org; Sat, 06 Dec 2014 08:58:34 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	F2/C2-02957-935C2845; Sat, 06 Dec 2014 08:58:33 +0000
X-Env-Sender: sagun@nexchanges.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417856310!10053732!1
X-Originating-IP: [209.85.216.46]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23999 invoked from network); 6 Dec 2014 08:58:31 -0000
Received: from mail-qa0-f46.google.com (HELO mail-qa0-f46.google.com)
	(209.85.216.46)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 08:58:31 -0000
Received: by mail-qa0-f46.google.com with SMTP id n8so1475182qaq.33
	for <xen-devel@lists.xen.org>; Sat, 06 Dec 2014 00:58: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Yolc2DSVvTuNceHrB6Zfn9JNMFf+FVhgWSl/UchynHc=;
	b=fchm8NTiSKWiLVs8+W/t060o3kvh3TqNBcreiOo3cF+gBVTRVttJXI6UY9G7iJYY/Q
	tsw7ga7yX9JFvTZSC/vzFwRpFGtLKThdsKVe/KO8mgsNsEauulDkY3e610A3/NIUAvwI
	8IFTJ0I5tchKwLJ+cWqkexZGeg/sNCwhAlMvudNN7xL6vUZ2ZBrhZkvE/xdJ80yazApA
	3RpxQXQNNlgzNhhtgmE9F3N7PbOczSe5oCiKD8Dj8iUkzxlZNooJ+munpRpO+2ozbTn7
	CnnyvC4myQvgcUlbujpKGoJrkaJrVvxLUcsy4P9IScbAo1ztVAiDXQLnu2WnRnSHM+xE
	JouA==
X-Gm-Message-State: ALoCoQnbwn4UrdhPqrfLLcTD32gOqI/+HgsvKcznEwTgzazzqolcgqB8RZ2O/ThTgW1aeUB7/0GY
MIME-Version: 1.0
X-Received: by 10.224.160.212 with SMTP id o20mr34539536qax.57.1417856310485; 
	Sat, 06 Dec 2014 00:58:30 -0800 (PST)
Received: by 10.140.102.183 with HTTP; Sat, 6 Dec 2014 00:58:30 -0800 (PST)
In-Reply-To: <1417771940.22808.39.camel@citrix.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
	<1417688979.22808.6.camel@citrix.com>
	<CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@mail.gmail.com>
	<1417771940.22808.39.camel@citrix.com>
Date: Sat, 6 Dec 2014 14:28:30 +0530
Message-ID: <CALwCXQBKKtFT2qrgDmiKZck6mnYH22dJAb4PM9VfM=t8xuoCCA@mail.gmail.com>
From: Sagun Garg <sagun@nexchanges.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: julien.grall@linaro.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5652886166086085432=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5652886166086085432==
Content-Type: multipart/alternative; boundary=089e0149cc52bac0d30509886513

--089e0149cc52bac0d30509886513
Content-Type: text/plain; charset=UTF-8

On Fri, Dec 5, 2014 at 3:02 PM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> Please don't top post.
>
> On Fri, 2014-12-05 at 14:51 +0530, Sagun Garg wrote:
> > Thanks Ian for helping me with the links,
> >
> >
> > FYI, I found following link :
> > https://blog.xenproject.org/2014/04/01/virtualization-on-arm-with-xen/
> > (Here it suggests using Foundation Model and Linaro, basically an
> > emulator to get started) though the advanced emulators offered by ARM
> > are paid ones)
> >
> >
> > Would it be possible to install these ARM emulators on say AWS
> > Amazon / Digital Ocean with the free subscription to try and test
> > these out ?
>
> Those emulators will run on any x86 system, whether it is virtualised by
> Amazon/DO or not. They are quite CPU intensive though.
>
> >  Amazon uses Xen as the underlying virtualization technology and it
> > also uses custom kernels since last 2 years so coincidentally it might
> > just work though the question is how (I read this somewhere on a blog,
> > but I can't point a link to it as I don't remember it, but would you
> > know of such a tuturial / link where someone else has pursued the
> > same ?)
>
> Amazon offers x86 Xen, not ARM Xen. Xen does not do any kind of
> cross-architecture virtualisation (i.e. running ARM OSes on X86, or vice
> versa). So the fact that Amazon happens to run x86 Xen is of no use when
> you want to run ARM Xen.
>
> > or would you know of any "RISC as a Service with ARM processors" that
> > can be provisioned on demand like AWS where we can install XEN on ARM
> > directly ? Any cloud offering that can be used would be of great help.
>
> I'm not aware of any cloud service offering ARM at the moment.
>
> > Also I was wondering what are the risks / or rather shortcomings in
> > trying directly on the device Nexus / or any other ARM phone which has
> > been tested for the same.
>
> Not sure what sorts of risks you mean, I don't think there is anything
> Xen specific here, just the usual stuff with running an untested OS on
> any new platform.
>
> I don't know if Nexus devices are brickable, but if so then that might
> be an issue with trying any untested OS on them.
>
> Phones and the like aren't typically very good debug platforms (i.e. no
> serial, no JTAG etc) so running an untested OS on them can end up being
> hard (but not impossible) to debug if it doesn't work, that's why
> platforms such as the Arndale exist -- they are mobile phones with all
> the extra useful debug stuff brought out to headers.
>
> Ian.
>
>
>
Hi Ian,

Got your point on Arndale Board, the approach mentioned by Julien with the
hidden UART in Nexus is also an excellent insight. Though one will have to
build the debugUART for Xen linux provides it our of box.

I happened to come across this article :
http://www.datacenterknowledge.com/archives/2014/11/19/french-web-host-builds-bare-metal-arm-server-cloud/

This is a new on demand cloud service with ARMv7 chips enabled by
MARVEL(it's called physicalization instead of virtualization) they offer
ARMv7 bare metal as a service. This looks like on demand ARMv7 cloud based
servers. They are the first of it's kind and it seems they are planning to
price it lesser than Digital Ocean and AWS. The challenge is it's ARMv7 and
not v8.

Links
http://labs.online.net/press and http://labs.online.net/ Will it be ok to
install Xen on this? They are still in their trial mode.

Also I had a unrelated question, does Xen on Arm have  support for ELF
kernels (bzImage only). If yes can you please point out where discussions
relating to his are happening and if not any idea on whether there is going
to be support in near future?

-Sagun
<http://www.datacenterknowledge.com/archives/2014/11/19/french-web-host-builds-bare-metal-arm-server-cloud/>

--089e0149cc52bac0d30509886513
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 Fri, Dec 5, 2014 at 3:02 PM, Ian Campbell <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citri=
x.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">Please don&#39;t top post.<br>
<span class=3D""><br>
On Fri, 2014-12-05 at 14:51 +0530, Sagun Garg wrote:<br>
&gt; Thanks Ian for helping me with the links,<br>
&gt;<br>
&gt;<br>
&gt; FYI, I found following link :<br>
&gt; <a href=3D"https://blog.xenproject.org/2014/04/01/virtualization-on-ar=
m-with-xen/" target=3D"_blank">https://blog.xenproject.org/2014/04/01/virtu=
alization-on-arm-with-xen/</a><br>
&gt; (Here it suggests using Foundation Model and Linaro, basically an<br>
&gt; emulator to get started) though the advanced emulators offered by ARM<=
br>
&gt; are paid ones)<br>
&gt;<br>
&gt;<br>
&gt; Would it be possible to install these ARM emulators on say AWS<br>
&gt; Amazon / Digital Ocean with the free subscription to try and test<br>
&gt; these out ?<br>
<br>
</span>Those emulators will run on any x86 system, whether it is virtualise=
d by<br>
Amazon/DO or not. They are quite CPU intensive though.<br>
<span class=3D""><br>
&gt;=C2=A0 Amazon uses Xen as the underlying virtualization technology and =
it<br>
&gt; also uses custom kernels since last 2 years so coincidentally it might=
<br>
&gt; just work though the question is how (I read this somewhere on a blog,=
<br>
&gt; but I can&#39;t point a link to it as I don&#39;t remember it, but wou=
ld you<br>
&gt; know of such a tuturial / link where someone else has pursued the<br>
&gt; same ?)<br>
<br>
</span>Amazon offers x86 Xen, not ARM Xen. Xen does not do any kind of<br>
cross-architecture virtualisation (i.e. running ARM OSes on X86, or vice<br=
>
versa). So the fact that Amazon happens to run x86 Xen is of no use when<br=
>
you want to run ARM Xen.<br>
<span class=3D""><br>
&gt; or would you know of any &quot;RISC as a Service with ARM processors&q=
uot; that<br>
&gt; can be provisioned on demand like AWS where we can install XEN on ARM<=
br>
&gt; directly ? Any cloud offering that can be used would be of great help.=
<br>
<br>
</span>I&#39;m not aware of any cloud service offering ARM at the moment.<b=
r>
<span class=3D""><br>
&gt; Also I was wondering what are the risks / or rather shortcomings in<br=
>
&gt; trying directly on the device Nexus / or any other ARM phone which has=
<br>
&gt; been tested for the same.<br>
<br>
</span>Not sure what sorts of risks you mean, I don&#39;t think there is an=
ything<br>
Xen specific here, just the usual stuff with running an untested OS on<br>
any new platform.<br>
<br>
I don&#39;t know if Nexus devices are brickable, but if so then that might<=
br>
be an issue with trying any untested OS on them.<br>
<br>
Phones and the like aren&#39;t typically very good debug platforms (i.e. no=
<br>
serial, no JTAG etc) so running an untested OS on them can end up being<br>
hard (but not impossible) to debug if it doesn&#39;t work, that&#39;s why<b=
r>
platforms such as the Arndale exist -- they are mobile phones with all<br>
the extra useful debug stuff brought out to headers.<br>
<span class=3D""><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br></div><div class=3D"gmail_extra">Hi Ia=
n,<br><br></div><div class=3D"gmail_extra">Got your point on Arndale Board,=
 the approach mentioned by Julien with the hidden UART in Nexus is also an =
excellent insight. Though one will have to build the debugUART for Xen linu=
x provides it our of box. <br><br></div><div class=3D"gmail_extra">I happen=
ed to come across this article : <a href=3D"http://www.datacenterknowledge.=
com/archives/2014/11/19/french-web-host-builds-bare-metal-arm-server-cloud/=
" target=3D"_blank">http://www.datacenterknowledge.com/archives/2014/11/19/=
french-web-host-builds-bare-metal-arm-server-cloud/</a><br><br>This is a ne=
w on demand cloud service with ARMv7 chips enabled by MARVEL(it&#39;s=20
called physicalization instead of virtualization) they offer ARMv7 bare=20
metal as a service. This looks like on demand ARMv7 cloud based servers.
 They are the first of it&#39;s kind and it seems they are planning to pric=
e
 it lesser than Digital Ocean and AWS. The challenge is it&#39;s ARMv7 and =
not v8. <br><br>Links<br><a href=3D"http://labs.online.net/press" target=3D=
"_blank">http://labs.online.net/press</a> and <a href=3D"http://labs.online=
.net/" target=3D"_blank">http://labs.online.net/</a> Will it be ok to insta=
ll Xen on this? They are still in their trial mode. <br><br></div><div clas=
s=3D"gmail_extra">Also I had a unrelated question, does Xen on Arm have=C2=
=A0 support for ELF kernels (bzImage only). If yes can you please point out=
 where discussions relating to his are happening and if not any idea on whe=
ther there is going to be support in near future?<br><br></div><div class=
=3D"gmail_extra">-Sagun<br></div><div class=3D"gmail_extra"><a href=3D"http=
://www.datacenterknowledge.com/archives/2014/11/19/french-web-host-builds-b=
are-metal-arm-server-cloud/" target=3D"_blank"></a></div></div>

--089e0149cc52bac0d30509886513--


--===============5652886166086085432==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5652886166086085432==--


From xen-devel-bounces@lists.xen.org Sat Dec 06 08:59:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 08:59:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxBCF-0000TO-HC; Sat, 06 Dec 2014 08:58:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sagun@nexchanges.com>) id 1XxBCE-0000TJ-BK
	for xen-devel@lists.xen.org; Sat, 06 Dec 2014 08:58:34 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	F2/C2-02957-935C2845; Sat, 06 Dec 2014 08:58:33 +0000
X-Env-Sender: sagun@nexchanges.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417856310!10053732!1
X-Originating-IP: [209.85.216.46]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23999 invoked from network); 6 Dec 2014 08:58:31 -0000
Received: from mail-qa0-f46.google.com (HELO mail-qa0-f46.google.com)
	(209.85.216.46)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 08:58:31 -0000
Received: by mail-qa0-f46.google.com with SMTP id n8so1475182qaq.33
	for <xen-devel@lists.xen.org>; Sat, 06 Dec 2014 00:58: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Yolc2DSVvTuNceHrB6Zfn9JNMFf+FVhgWSl/UchynHc=;
	b=fchm8NTiSKWiLVs8+W/t060o3kvh3TqNBcreiOo3cF+gBVTRVttJXI6UY9G7iJYY/Q
	tsw7ga7yX9JFvTZSC/vzFwRpFGtLKThdsKVe/KO8mgsNsEauulDkY3e610A3/NIUAvwI
	8IFTJ0I5tchKwLJ+cWqkexZGeg/sNCwhAlMvudNN7xL6vUZ2ZBrhZkvE/xdJ80yazApA
	3RpxQXQNNlgzNhhtgmE9F3N7PbOczSe5oCiKD8Dj8iUkzxlZNooJ+munpRpO+2ozbTn7
	CnnyvC4myQvgcUlbujpKGoJrkaJrVvxLUcsy4P9IScbAo1ztVAiDXQLnu2WnRnSHM+xE
	JouA==
X-Gm-Message-State: ALoCoQnbwn4UrdhPqrfLLcTD32gOqI/+HgsvKcznEwTgzazzqolcgqB8RZ2O/ThTgW1aeUB7/0GY
MIME-Version: 1.0
X-Received: by 10.224.160.212 with SMTP id o20mr34539536qax.57.1417856310485; 
	Sat, 06 Dec 2014 00:58:30 -0800 (PST)
Received: by 10.140.102.183 with HTTP; Sat, 6 Dec 2014 00:58:30 -0800 (PST)
In-Reply-To: <1417771940.22808.39.camel@citrix.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
	<1417688979.22808.6.camel@citrix.com>
	<CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@mail.gmail.com>
	<1417771940.22808.39.camel@citrix.com>
Date: Sat, 6 Dec 2014 14:28:30 +0530
Message-ID: <CALwCXQBKKtFT2qrgDmiKZck6mnYH22dJAb4PM9VfM=t8xuoCCA@mail.gmail.com>
From: Sagun Garg <sagun@nexchanges.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: julien.grall@linaro.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5652886166086085432=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5652886166086085432==
Content-Type: multipart/alternative; boundary=089e0149cc52bac0d30509886513

--089e0149cc52bac0d30509886513
Content-Type: text/plain; charset=UTF-8

On Fri, Dec 5, 2014 at 3:02 PM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> Please don't top post.
>
> On Fri, 2014-12-05 at 14:51 +0530, Sagun Garg wrote:
> > Thanks Ian for helping me with the links,
> >
> >
> > FYI, I found following link :
> > https://blog.xenproject.org/2014/04/01/virtualization-on-arm-with-xen/
> > (Here it suggests using Foundation Model and Linaro, basically an
> > emulator to get started) though the advanced emulators offered by ARM
> > are paid ones)
> >
> >
> > Would it be possible to install these ARM emulators on say AWS
> > Amazon / Digital Ocean with the free subscription to try and test
> > these out ?
>
> Those emulators will run on any x86 system, whether it is virtualised by
> Amazon/DO or not. They are quite CPU intensive though.
>
> >  Amazon uses Xen as the underlying virtualization technology and it
> > also uses custom kernels since last 2 years so coincidentally it might
> > just work though the question is how (I read this somewhere on a blog,
> > but I can't point a link to it as I don't remember it, but would you
> > know of such a tuturial / link where someone else has pursued the
> > same ?)
>
> Amazon offers x86 Xen, not ARM Xen. Xen does not do any kind of
> cross-architecture virtualisation (i.e. running ARM OSes on X86, or vice
> versa). So the fact that Amazon happens to run x86 Xen is of no use when
> you want to run ARM Xen.
>
> > or would you know of any "RISC as a Service with ARM processors" that
> > can be provisioned on demand like AWS where we can install XEN on ARM
> > directly ? Any cloud offering that can be used would be of great help.
>
> I'm not aware of any cloud service offering ARM at the moment.
>
> > Also I was wondering what are the risks / or rather shortcomings in
> > trying directly on the device Nexus / or any other ARM phone which has
> > been tested for the same.
>
> Not sure what sorts of risks you mean, I don't think there is anything
> Xen specific here, just the usual stuff with running an untested OS on
> any new platform.
>
> I don't know if Nexus devices are brickable, but if so then that might
> be an issue with trying any untested OS on them.
>
> Phones and the like aren't typically very good debug platforms (i.e. no
> serial, no JTAG etc) so running an untested OS on them can end up being
> hard (but not impossible) to debug if it doesn't work, that's why
> platforms such as the Arndale exist -- they are mobile phones with all
> the extra useful debug stuff brought out to headers.
>
> Ian.
>
>
>
Hi Ian,

Got your point on Arndale Board, the approach mentioned by Julien with the
hidden UART in Nexus is also an excellent insight. Though one will have to
build the debugUART for Xen linux provides it our of box.

I happened to come across this article :
http://www.datacenterknowledge.com/archives/2014/11/19/french-web-host-builds-bare-metal-arm-server-cloud/

This is a new on demand cloud service with ARMv7 chips enabled by
MARVEL(it's called physicalization instead of virtualization) they offer
ARMv7 bare metal as a service. This looks like on demand ARMv7 cloud based
servers. They are the first of it's kind and it seems they are planning to
price it lesser than Digital Ocean and AWS. The challenge is it's ARMv7 and
not v8.

Links
http://labs.online.net/press and http://labs.online.net/ Will it be ok to
install Xen on this? They are still in their trial mode.

Also I had a unrelated question, does Xen on Arm have  support for ELF
kernels (bzImage only). If yes can you please point out where discussions
relating to his are happening and if not any idea on whether there is going
to be support in near future?

-Sagun
<http://www.datacenterknowledge.com/archives/2014/11/19/french-web-host-builds-bare-metal-arm-server-cloud/>

--089e0149cc52bac0d30509886513
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 Fri, Dec 5, 2014 at 3:02 PM, Ian Campbell <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citri=
x.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">Please don&#39;t top post.<br>
<span class=3D""><br>
On Fri, 2014-12-05 at 14:51 +0530, Sagun Garg wrote:<br>
&gt; Thanks Ian for helping me with the links,<br>
&gt;<br>
&gt;<br>
&gt; FYI, I found following link :<br>
&gt; <a href=3D"https://blog.xenproject.org/2014/04/01/virtualization-on-ar=
m-with-xen/" target=3D"_blank">https://blog.xenproject.org/2014/04/01/virtu=
alization-on-arm-with-xen/</a><br>
&gt; (Here it suggests using Foundation Model and Linaro, basically an<br>
&gt; emulator to get started) though the advanced emulators offered by ARM<=
br>
&gt; are paid ones)<br>
&gt;<br>
&gt;<br>
&gt; Would it be possible to install these ARM emulators on say AWS<br>
&gt; Amazon / Digital Ocean with the free subscription to try and test<br>
&gt; these out ?<br>
<br>
</span>Those emulators will run on any x86 system, whether it is virtualise=
d by<br>
Amazon/DO or not. They are quite CPU intensive though.<br>
<span class=3D""><br>
&gt;=C2=A0 Amazon uses Xen as the underlying virtualization technology and =
it<br>
&gt; also uses custom kernels since last 2 years so coincidentally it might=
<br>
&gt; just work though the question is how (I read this somewhere on a blog,=
<br>
&gt; but I can&#39;t point a link to it as I don&#39;t remember it, but wou=
ld you<br>
&gt; know of such a tuturial / link where someone else has pursued the<br>
&gt; same ?)<br>
<br>
</span>Amazon offers x86 Xen, not ARM Xen. Xen does not do any kind of<br>
cross-architecture virtualisation (i.e. running ARM OSes on X86, or vice<br=
>
versa). So the fact that Amazon happens to run x86 Xen is of no use when<br=
>
you want to run ARM Xen.<br>
<span class=3D""><br>
&gt; or would you know of any &quot;RISC as a Service with ARM processors&q=
uot; that<br>
&gt; can be provisioned on demand like AWS where we can install XEN on ARM<=
br>
&gt; directly ? Any cloud offering that can be used would be of great help.=
<br>
<br>
</span>I&#39;m not aware of any cloud service offering ARM at the moment.<b=
r>
<span class=3D""><br>
&gt; Also I was wondering what are the risks / or rather shortcomings in<br=
>
&gt; trying directly on the device Nexus / or any other ARM phone which has=
<br>
&gt; been tested for the same.<br>
<br>
</span>Not sure what sorts of risks you mean, I don&#39;t think there is an=
ything<br>
Xen specific here, just the usual stuff with running an untested OS on<br>
any new platform.<br>
<br>
I don&#39;t know if Nexus devices are brickable, but if so then that might<=
br>
be an issue with trying any untested OS on them.<br>
<br>
Phones and the like aren&#39;t typically very good debug platforms (i.e. no=
<br>
serial, no JTAG etc) so running an untested OS on them can end up being<br>
hard (but not impossible) to debug if it doesn&#39;t work, that&#39;s why<b=
r>
platforms such as the Arndale exist -- they are mobile phones with all<br>
the extra useful debug stuff brought out to headers.<br>
<span class=3D""><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br></div><div class=3D"gmail_extra">Hi Ia=
n,<br><br></div><div class=3D"gmail_extra">Got your point on Arndale Board,=
 the approach mentioned by Julien with the hidden UART in Nexus is also an =
excellent insight. Though one will have to build the debugUART for Xen linu=
x provides it our of box. <br><br></div><div class=3D"gmail_extra">I happen=
ed to come across this article : <a href=3D"http://www.datacenterknowledge.=
com/archives/2014/11/19/french-web-host-builds-bare-metal-arm-server-cloud/=
" target=3D"_blank">http://www.datacenterknowledge.com/archives/2014/11/19/=
french-web-host-builds-bare-metal-arm-server-cloud/</a><br><br>This is a ne=
w on demand cloud service with ARMv7 chips enabled by MARVEL(it&#39;s=20
called physicalization instead of virtualization) they offer ARMv7 bare=20
metal as a service. This looks like on demand ARMv7 cloud based servers.
 They are the first of it&#39;s kind and it seems they are planning to pric=
e
 it lesser than Digital Ocean and AWS. The challenge is it&#39;s ARMv7 and =
not v8. <br><br>Links<br><a href=3D"http://labs.online.net/press" target=3D=
"_blank">http://labs.online.net/press</a> and <a href=3D"http://labs.online=
.net/" target=3D"_blank">http://labs.online.net/</a> Will it be ok to insta=
ll Xen on this? They are still in their trial mode. <br><br></div><div clas=
s=3D"gmail_extra">Also I had a unrelated question, does Xen on Arm have=C2=
=A0 support for ELF kernels (bzImage only). If yes can you please point out=
 where discussions relating to his are happening and if not any idea on whe=
ther there is going to be support in near future?<br><br></div><div class=
=3D"gmail_extra">-Sagun<br></div><div class=3D"gmail_extra"><a href=3D"http=
://www.datacenterknowledge.com/archives/2014/11/19/french-web-host-builds-b=
are-metal-arm-server-cloud/" target=3D"_blank"></a></div></div>

--089e0149cc52bac0d30509886513--


--===============5652886166086085432==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5652886166086085432==--


From xen-devel-bounces@lists.xen.org Sat Dec 06 11:39:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 11:39:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxDh8-0004A8-EJ; Sat, 06 Dec 2014 11:38: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 1XxDh6-0004A3-BZ
	for xen-devel@lists.xensource.com; Sat, 06 Dec 2014 11:38:36 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	4D/E6-02707-BBAE2845; Sat, 06 Dec 2014 11:38:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417865912!9024560!1
X-Originating-IP: [66.165.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 32625 invoked from network); 6 Dec 2014 11:38:34 -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;
	6 Dec 2014 11:38:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,529,1413244800"; d="scan'208";a="200810748"
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, 6 Dec 2014 06:38: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 1XxDgY-0004ec-8o;
	Sat, 06 Dec 2014 11:38:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxDgX-0005Ul-O9;
	Sat, 06 Dec 2014 11:38:01 +0000
Date: Sat, 6 Dec 2014 11:38:01 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32099-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] 32099: 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 32099 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32099/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt       7 debian-install          fail baseline untested
 test-amd64-i386-xl            7 debian-install          fail baseline untested
 test-amd64-i386-xl-credit2    7 debian-install          fail baseline untested
 test-amd64-amd64-libvirt      7 debian-install          fail baseline untested
 test-amd64-i386-xl-multivcpu  7 debian-install          fail baseline untested
 test-amd64-amd64-xl           7 debian-install          fail baseline untested
 test-amd64-amd64-xl-sedf      7 debian-install          fail baseline untested
 test-armhf-armhf-libvirt      7 debian-install          fail baseline untested
 test-amd64-amd64-xl-sedf-pin  7 debian-install          fail baseline untested
 test-armhf-armhf-xl           7 debian-install          fail baseline untested
 test-amd64-amd64-pair        11 debian-install/dst_host fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-xl-pcipt-intel  7 debian-install       fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-pair         11 debian-install/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-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-qemut-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-vcpus1 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-i386-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-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-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-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass

version targeted for testing:
 linux                1ca7c606de868d172afb4eb65e04e290dbdb51ff
baseline version:
 linux                3a18ca061311f2f1ee9c44012f89c7436d392117

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 Dec 06 11:39:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 11:39:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxDh8-0004A8-EJ; Sat, 06 Dec 2014 11:38: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 1XxDh6-0004A3-BZ
	for xen-devel@lists.xensource.com; Sat, 06 Dec 2014 11:38:36 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	4D/E6-02707-BBAE2845; Sat, 06 Dec 2014 11:38:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417865912!9024560!1
X-Originating-IP: [66.165.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 32625 invoked from network); 6 Dec 2014 11:38:34 -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;
	6 Dec 2014 11:38:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,529,1413244800"; d="scan'208";a="200810748"
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, 6 Dec 2014 06:38: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 1XxDgY-0004ec-8o;
	Sat, 06 Dec 2014 11:38:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxDgX-0005Ul-O9;
	Sat, 06 Dec 2014 11:38:01 +0000
Date: Sat, 6 Dec 2014 11:38:01 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32099-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] 32099: 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 32099 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32099/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt       7 debian-install          fail baseline untested
 test-amd64-i386-xl            7 debian-install          fail baseline untested
 test-amd64-i386-xl-credit2    7 debian-install          fail baseline untested
 test-amd64-amd64-libvirt      7 debian-install          fail baseline untested
 test-amd64-i386-xl-multivcpu  7 debian-install          fail baseline untested
 test-amd64-amd64-xl           7 debian-install          fail baseline untested
 test-amd64-amd64-xl-sedf      7 debian-install          fail baseline untested
 test-armhf-armhf-libvirt      7 debian-install          fail baseline untested
 test-amd64-amd64-xl-sedf-pin  7 debian-install          fail baseline untested
 test-armhf-armhf-xl           7 debian-install          fail baseline untested
 test-amd64-amd64-pair        11 debian-install/dst_host fail baseline untested
 test-amd64-i386-rumpuserxen-i386  8 guest-start         fail baseline untested
 test-amd64-amd64-xl-pcipt-intel  7 debian-install       fail baseline untested
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start       fail baseline untested
 test-amd64-i386-pair         11 debian-install/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-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-qemut-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-vcpus1 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-i386-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-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-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-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass

version targeted for testing:
 linux                1ca7c606de868d172afb4eb65e04e290dbdb51ff
baseline version:
 linux                3a18ca061311f2f1ee9c44012f89c7436d392117

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 Dec 06 12:41:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 12:41:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxEf8-00067h-Em; Sat, 06 Dec 2014 12:40:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1XxEf7-00067c-Ni
	for xen-devel@lists.xen.org; Sat, 06 Dec 2014 12:40:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B5/A9-09842-549F2845; Sat, 06 Dec 2014 12:40:37 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417869636!5820368!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7742 invoked from network); 6 Dec 2014 12:40:36 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-2.tower-21.messagelabs.com with SMTP;
	6 Dec 2014 12:40:36 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id 86C93308187;
	Sat,  6 Dec 2014 14:40:34 +0200 (EET)
Message-ID: <5482F941.1020301@iki.fi>
Date: Sat, 06 Dec 2014 12:40:33 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org, 
	rumpkernel-users@lists.sourceforge.net, 
	Anil Madhavapeddy <anil@recoil.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
	<20141205183153.GD19077@dezo.moloch.sk>
In-Reply-To: <20141205183153.GD19077@dezo.moloch.sk>
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/14 18:31, Martin Lucina wrote:
> pooka@iki.fi said:
>> I wonder if work is minimized if we attempt to merge before or after
>> we (I?) take the carving knife for a second round in the rumprun-xen
>> repo to minimize MiniOS to run only on top of itself.
>
> Before, I think. Minimizing our copy of Mini-OS duplicates what we would
> need to do to the upstream copy.
>
> I think the steps are roughly as follows:
>
>    a) split the current rumprun-xen build out of the Mini-OS Makefile.
>    b) replace our fork of Mini-OS with the vanilla upstream Mini-OS.
>    c) re-apply my work and your work, while checking things keep working
>    with upstream xen.git, until we get rumprun-xen working again.
>
> c) will leave us with a set of patches to upstream.
>
> Does this make sense? It's a fair amount of work but mostly retracing steps
> we've already done.
>
> It'd help if we had a full list of "what exactly needs to keep working
> upstream", see my other reply to Andrew. Maybe also osstest building and
> running Mini-OS related tests off our branch while we do the work? (Ian:
> ping? Doable?)

It'd also help if we had a full list of "what exactly needs to be done 
to downstream".  That's why I'm not convinced by a list which ignores 
"d) perform the unknown steps to reach our goal" (which were painted in 
broad strokes in my previous mail).

Actually, it convinced me more of the opposite: wait before attempting 
full merge.  However, if someone's merge finger is twitching, a 
pseudo-merge with changes like the namespace protection and introducing 
a clean "libminios" split is nice.  But, again, is it more or less work 
doing that piecemeal or when all the puzzle pieces are known?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 06 12:41:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 12:41:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxEf8-00067h-Em; Sat, 06 Dec 2014 12:40:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1XxEf7-00067c-Ni
	for xen-devel@lists.xen.org; Sat, 06 Dec 2014 12:40:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B5/A9-09842-549F2845; Sat, 06 Dec 2014 12:40:37 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417869636!5820368!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7742 invoked from network); 6 Dec 2014 12:40:36 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-2.tower-21.messagelabs.com with SMTP;
	6 Dec 2014 12:40:36 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id 86C93308187;
	Sat,  6 Dec 2014 14:40:34 +0200 (EET)
Message-ID: <5482F941.1020301@iki.fi>
Date: Sat, 06 Dec 2014 12:40:33 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org, 
	rumpkernel-users@lists.sourceforge.net, 
	Anil Madhavapeddy <anil@recoil.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
	<20141205183153.GD19077@dezo.moloch.sk>
In-Reply-To: <20141205183153.GD19077@dezo.moloch.sk>
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/14 18:31, Martin Lucina wrote:
> pooka@iki.fi said:
>> I wonder if work is minimized if we attempt to merge before or after
>> we (I?) take the carving knife for a second round in the rumprun-xen
>> repo to minimize MiniOS to run only on top of itself.
>
> Before, I think. Minimizing our copy of Mini-OS duplicates what we would
> need to do to the upstream copy.
>
> I think the steps are roughly as follows:
>
>    a) split the current rumprun-xen build out of the Mini-OS Makefile.
>    b) replace our fork of Mini-OS with the vanilla upstream Mini-OS.
>    c) re-apply my work and your work, while checking things keep working
>    with upstream xen.git, until we get rumprun-xen working again.
>
> c) will leave us with a set of patches to upstream.
>
> Does this make sense? It's a fair amount of work but mostly retracing steps
> we've already done.
>
> It'd help if we had a full list of "what exactly needs to keep working
> upstream", see my other reply to Andrew. Maybe also osstest building and
> running Mini-OS related tests off our branch while we do the work? (Ian:
> ping? Doable?)

It'd also help if we had a full list of "what exactly needs to be done 
to downstream".  That's why I'm not convinced by a list which ignores 
"d) perform the unknown steps to reach our goal" (which were painted in 
broad strokes in my previous mail).

Actually, it convinced me more of the opposite: wait before attempting 
full merge.  However, if someone's merge finger is twitching, a 
pseudo-merge with changes like the namespace protection and introducing 
a clean "libminios" split is nice.  But, again, is it more or less work 
doing that piecemeal or when all the puzzle pieces are known?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 06 13:36:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 13: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 1XxFWL-0007hS-Uo; Sat, 06 Dec 2014 13:35:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marco.guazzone@gmail.com>) id 1XxFWK-0007hN-8K
	for xen-devel@lists.xen.org; Sat, 06 Dec 2014 13:35:36 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	DC/0A-20609-72603845; Sat, 06 Dec 2014 13:35:35 +0000
X-Env-Sender: marco.guazzone@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417872933!8768204!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15710 invoked from network); 6 Dec 2014 13:35:34 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 13:35:34 -0000
Received: by mail-vc0-f173.google.com with SMTP id im17so1082620vcb.4
	for <xen-devel@lists.xen.org>; Sat, 06 Dec 2014 05:35: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
	:content-type; bh=0MQ4LCiSOQGH/MGQrQXnBIal3PIChyrsSO12S9zlEfo=;
	b=mWg5oO/tBYR7CaJq9yfrczO4gTvcQVx5Ct83YeSkSOxMb+ttf/sedRhnGcp65dMzy1
	NYhMz3zErWVHUnvkyrStE7pnaLlf4DLiW61zY6MUUoLZkjkVBHwIHyRNTP8vvlP2pFRW
	ndJ10XZo65Bm8z7pf4IXnMCvy1flZY9jyVyfTVzIKQn0CH5oMG5vLn5/2jnV8TXV1wOS
	+HXFS+rILpiEaQBJyxNPYUUNV7GYiEAIK/mT2RDzayPwASmWQQy7fLARg6AEiefSCwD/
	DquLOSvvz1KqDDkPoEgUrJ8qgIXFay3vaOu59M6nN1BOrHx3E2jXENLyP+Q6TpqgpY/J
	QhHw==
MIME-Version: 1.0
X-Received: by 10.53.4.37 with SMTP id cb5mr12705305vdd.23.1417872933227; Sat,
	06 Dec 2014 05:35:33 -0800 (PST)
Received: by 10.31.59.202 with HTTP; Sat, 6 Dec 2014 05:35:33 -0800 (PST)
In-Reply-To: <CABbE_O5U95pQYpmEb-NkPRcX1pFG+40upQ2ywUTOmZBxK88NfA@mail.gmail.com>
References: <CABbE_O5U95pQYpmEb-NkPRcX1pFG+40upQ2ywUTOmZBxK88NfA@mail.gmail.com>
Date: Sat, 6 Dec 2014 14:35:33 +0100
Message-ID: <CABbE_O6uSoS6SrRFRsOq=VNW5dysKjKXzS+A2Jo8=o5BVftweQ@mail.gmail.com>
From: Marco Guazzone <marco.guazzone@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Fwd: How does domU memory allocation 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

Hello,

This is somewhat a cross-post. Sorry for this.
I've already posted this question to xen-users:
   http://lists.xenproject.org/archives/html/xen-users/2014-11/msg00087.html
but the only help I've obtained is to look at this graph:
   http://xenbits.xen.org/hg/staging/xen-unstable.hg/file/default/docs/misc/libxl_memory.txt

Unfortunately, I'm not able to interpret very well this graph as my
knowledge about Xen internals is very minimal.

So, as my last hope, I've decided to repost the message in this ML.
Can someone help me or, at least, point me to a doc written in human
language so as I can understand Xen memory allocation?

Thank you very much for your time

Cheers,

---------- Forwarded message ----------
From: Marco Guazzone <marco.guazzone@gmail.com>
Date: Fri, Nov 21, 2014 at 5:16 PM
Subject: How does domU memory allocation work?
To: xen-users@lists.xen.org


Hi,

I don't understand how Xen memory allocation works.

Suppose you create a HVM domU with:

maxmem = 3072
memory = 3072

Now, if I quey Xen I gen
* xl list:
    Name  ID   Mem VCPUs    State    Time(s)
    testvm   1  3067     1     -b----      12.8
* xenstore-ls:
    static-max = "3145728"
    target = "3137536"
     videoram = "8192"
*  xl top:
     MEM(k) MEM(%)  MAXMEM(k) MAXMEM(%)
     3141600        3.1         3146752              3.1

So, for the max memory, we have:

CFG_MAXMEM == XENSTORE_STATIC_MAX  <  XL_TOP_MAXMEM

While, for the current memory, we have:

XENSTORE_TARGET < XL_TOP_MEM < CFG_MEMORY < XL_LIST_MEM

I'm really confused.

Could you explain how it works?

Thank you very much.

Best,

-- Marco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 06 13:36:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 13: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 1XxFWL-0007hS-Uo; Sat, 06 Dec 2014 13:35:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marco.guazzone@gmail.com>) id 1XxFWK-0007hN-8K
	for xen-devel@lists.xen.org; Sat, 06 Dec 2014 13:35:36 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	DC/0A-20609-72603845; Sat, 06 Dec 2014 13:35:35 +0000
X-Env-Sender: marco.guazzone@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417872933!8768204!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15710 invoked from network); 6 Dec 2014 13:35:34 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 13:35:34 -0000
Received: by mail-vc0-f173.google.com with SMTP id im17so1082620vcb.4
	for <xen-devel@lists.xen.org>; Sat, 06 Dec 2014 05:35: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
	:content-type; bh=0MQ4LCiSOQGH/MGQrQXnBIal3PIChyrsSO12S9zlEfo=;
	b=mWg5oO/tBYR7CaJq9yfrczO4gTvcQVx5Ct83YeSkSOxMb+ttf/sedRhnGcp65dMzy1
	NYhMz3zErWVHUnvkyrStE7pnaLlf4DLiW61zY6MUUoLZkjkVBHwIHyRNTP8vvlP2pFRW
	ndJ10XZo65Bm8z7pf4IXnMCvy1flZY9jyVyfTVzIKQn0CH5oMG5vLn5/2jnV8TXV1wOS
	+HXFS+rILpiEaQBJyxNPYUUNV7GYiEAIK/mT2RDzayPwASmWQQy7fLARg6AEiefSCwD/
	DquLOSvvz1KqDDkPoEgUrJ8qgIXFay3vaOu59M6nN1BOrHx3E2jXENLyP+Q6TpqgpY/J
	QhHw==
MIME-Version: 1.0
X-Received: by 10.53.4.37 with SMTP id cb5mr12705305vdd.23.1417872933227; Sat,
	06 Dec 2014 05:35:33 -0800 (PST)
Received: by 10.31.59.202 with HTTP; Sat, 6 Dec 2014 05:35:33 -0800 (PST)
In-Reply-To: <CABbE_O5U95pQYpmEb-NkPRcX1pFG+40upQ2ywUTOmZBxK88NfA@mail.gmail.com>
References: <CABbE_O5U95pQYpmEb-NkPRcX1pFG+40upQ2ywUTOmZBxK88NfA@mail.gmail.com>
Date: Sat, 6 Dec 2014 14:35:33 +0100
Message-ID: <CABbE_O6uSoS6SrRFRsOq=VNW5dysKjKXzS+A2Jo8=o5BVftweQ@mail.gmail.com>
From: Marco Guazzone <marco.guazzone@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Fwd: How does domU memory allocation 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

Hello,

This is somewhat a cross-post. Sorry for this.
I've already posted this question to xen-users:
   http://lists.xenproject.org/archives/html/xen-users/2014-11/msg00087.html
but the only help I've obtained is to look at this graph:
   http://xenbits.xen.org/hg/staging/xen-unstable.hg/file/default/docs/misc/libxl_memory.txt

Unfortunately, I'm not able to interpret very well this graph as my
knowledge about Xen internals is very minimal.

So, as my last hope, I've decided to repost the message in this ML.
Can someone help me or, at least, point me to a doc written in human
language so as I can understand Xen memory allocation?

Thank you very much for your time

Cheers,

---------- Forwarded message ----------
From: Marco Guazzone <marco.guazzone@gmail.com>
Date: Fri, Nov 21, 2014 at 5:16 PM
Subject: How does domU memory allocation work?
To: xen-users@lists.xen.org


Hi,

I don't understand how Xen memory allocation works.

Suppose you create a HVM domU with:

maxmem = 3072
memory = 3072

Now, if I quey Xen I gen
* xl list:
    Name  ID   Mem VCPUs    State    Time(s)
    testvm   1  3067     1     -b----      12.8
* xenstore-ls:
    static-max = "3145728"
    target = "3137536"
     videoram = "8192"
*  xl top:
     MEM(k) MEM(%)  MAXMEM(k) MAXMEM(%)
     3141600        3.1         3146752              3.1

So, for the max memory, we have:

CFG_MAXMEM == XENSTORE_STATIC_MAX  <  XL_TOP_MAXMEM

While, for the current memory, we have:

XENSTORE_TARGET < XL_TOP_MEM < CFG_MEMORY < XL_LIST_MEM

I'm really confused.

Could you explain how it works?

Thank you very much.

Best,

-- Marco

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 06 15:28:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 15: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 1XxHGx-0001sa-OQ; Sat, 06 Dec 2014 15:27: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 1XxHGw-0001sV-9c
	for xen-devel@lists.xensource.com; Sat, 06 Dec 2014 15:27:50 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	26/EE-14727-47023845; Sat, 06 Dec 2014 15:27:48 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417879666!6624653!1
X-Originating-IP: [66.165.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 9936 invoked from network); 6 Dec 2014 15:27:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 15:27:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,529,1413244800"; d="scan'208";a="200862597"
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, 6 Dec 2014 10:27: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 1XxHGq-0005kp-OR;
	Sat, 06 Dec 2014 15:27:44 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxHGq-0005JP-Fv;
	Sat, 06 Dec 2014 15:27:44 +0000
Date: Sat, 6 Dec 2014 15:27:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32100-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] 32100: 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 32100 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32100/

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-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
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-xl-qemut-winxpsp3  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-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

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-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 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-amd64-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-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:
 linux                7cc78f8fa02c2485104b86434acbc1538a3bd807
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
718 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                            broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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)
broken-step test-amd64-amd64-xl-qemuu-winxpsp3 host-install(3)

Not pushing.

(No revision log; it would be 32058 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 Dec 06 15:28:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 15: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 1XxHGx-0001sa-OQ; Sat, 06 Dec 2014 15:27: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 1XxHGw-0001sV-9c
	for xen-devel@lists.xensource.com; Sat, 06 Dec 2014 15:27:50 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	26/EE-14727-47023845; Sat, 06 Dec 2014 15:27:48 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1417879666!6624653!1
X-Originating-IP: [66.165.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 9936 invoked from network); 6 Dec 2014 15:27:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 15:27:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,529,1413244800"; d="scan'208";a="200862597"
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, 6 Dec 2014 10:27: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 1XxHGq-0005kp-OR;
	Sat, 06 Dec 2014 15:27:44 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxHGq-0005JP-Fv;
	Sat, 06 Dec 2014 15:27:44 +0000
Date: Sat, 6 Dec 2014 15:27:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32100-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] 32100: 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 32100 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32100/

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-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
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start         fail REGR. vs. 31241
 test-amd64-i386-xl-qemut-winxpsp3  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-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

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-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 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-amd64-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-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:
 linux                7cc78f8fa02c2485104b86434acbc1538a3bd807
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
718 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                            broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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)
broken-step test-amd64-amd64-xl-qemuu-winxpsp3 host-install(3)

Not pushing.

(No revision log; it would be 32058 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 Dec 06 18:21:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 18:21:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxJyi-0006LI-IX; Sat, 06 Dec 2014 18:21:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XxJyh-0006LD-5h
	for xen-devel@lists.xensource.com; Sat, 06 Dec 2014 18:21:11 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	17/2A-25727-61943845; Sat, 06 Dec 2014 18:21:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417890066!11582366!1
X-Originating-IP: [66.165.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 15809 invoked from network); 6 Dec 2014 18:21:07 -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;
	6 Dec 2014 18:21:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,530,1413244800"; d="scan'208";a="200898509"
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, 6 Dec 2014 13:21: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 1XxJya-0006aK-Ev;
	Sat, 06 Dec 2014 18:21:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxJya-0006Qo-9L;
	Sat, 06 Dec 2014 18:21:04 +0000
Date: Sat, 6 Dec 2014 18:21:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32104-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] 32104: 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 32104 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32104/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 32071
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 32071
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 32071

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 32071
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32071

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-winxpsp3-vcpus1 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-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-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              56b252ea737c1514916d6df4493f89ff71322f60
baseline version:
 seabios              e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f

------------------------------------------------------------
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                                          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                    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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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                           broken  
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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-qemuu-winxpsp3 host-install(3)
broken-step test-amd64-amd64-xl host-install(3)
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit 56b252ea737c1514916d6df4493f89ff71322f60
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Wed Dec 3 12:22:14 2014 -0500

    Minor - be consistent in placement of .code16/32 in romlayout.S
    
    Place .code32 in those functions that need it, and make sure every
    function ends in .code16 mode.
    
    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

commit ca087779edbbc52e364dd901927dbe868ec085fc
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Sat Nov 29 13:04:46 2014 -0500

    floppy: Make sure to yield() during floppy PIO
    
    The floppy Programmed IO code really should yield while the controller
    is busy.
    
    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 Sat Dec 06 18:21:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 18:21:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxJyi-0006LI-IX; Sat, 06 Dec 2014 18:21:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XxJyh-0006LD-5h
	for xen-devel@lists.xensource.com; Sat, 06 Dec 2014 18:21:11 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	17/2A-25727-61943845; Sat, 06 Dec 2014 18:21:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1417890066!11582366!1
X-Originating-IP: [66.165.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 15809 invoked from network); 6 Dec 2014 18:21:07 -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;
	6 Dec 2014 18:21:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,530,1413244800"; d="scan'208";a="200898509"
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, 6 Dec 2014 13:21: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 1XxJya-0006aK-Ev;
	Sat, 06 Dec 2014 18:21:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxJya-0006Qo-9L;
	Sat, 06 Dec 2014 18:21:04 +0000
Date: Sat, 6 Dec 2014 18:21:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32104-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] 32104: 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 32104 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32104/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 32071
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 32071
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 32071

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 32071
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32071

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-winxpsp3-vcpus1 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-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-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              56b252ea737c1514916d6df4493f89ff71322f60
baseline version:
 seabios              e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f

------------------------------------------------------------
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                                          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                    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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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                           broken  
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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-qemuu-winxpsp3 host-install(3)
broken-step test-amd64-amd64-xl host-install(3)
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit 56b252ea737c1514916d6df4493f89ff71322f60
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Wed Dec 3 12:22:14 2014 -0500

    Minor - be consistent in placement of .code16/32 in romlayout.S
    
    Place .code32 in those functions that need it, and make sure every
    function ends in .code16 mode.
    
    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

commit ca087779edbbc52e364dd901927dbe868ec085fc
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Sat Nov 29 13:04:46 2014 -0500

    floppy: Make sure to yield() during floppy PIO
    
    The floppy Programmed IO code really should yield while the controller
    is busy.
    
    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 Sat Dec 06 21:36:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 21: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 1XxN0y-0002WM-5w; Sat, 06 Dec 2014 21:35:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XxN0v-0002WH-Ta
	for xen-devel@lists.xensource.com; Sat, 06 Dec 2014 21:35:42 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	31/9F-25276-DA673845; Sat, 06 Dec 2014 21:35:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417901739!13874952!1
X-Originating-IP: [66.165.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 588 invoked from network); 6 Dec 2014 21:35:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 21:35:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,530,1413244800"; d="scan'208";a="200933082"
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.210.2; Sat, 6 Dec 2014 16:35: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 1XxN0r-0007WZ-Js;
	Sat, 06 Dec 2014 21:35:37 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxN0r-0002Wg-DV;
	Sat, 06 Dec 2014 21:35:37 +0000
Date: Sat, 6 Dec 2014 21:35:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32106-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] 32106: 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 32106 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32106/

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-win7-amd64  3 host-install(3)          broken pass in 32086
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3)   broken pass in 32086

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-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
 build-i386-rumpuserxen      3 host-install(3) broken in 32086 blocked in 26303
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 32086 like 26261
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 17 leak-check/check fail in 32086 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           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-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-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-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)        blocked in 32086 n/a
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 32086 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 32086 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                     fail    
 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                         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                                broken  
 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-win7-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemut-win7-amd64 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 Dec 06 21:36:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Dec 2014 21: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 1XxN0y-0002WM-5w; Sat, 06 Dec 2014 21:35:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XxN0v-0002WH-Ta
	for xen-devel@lists.xensource.com; Sat, 06 Dec 2014 21:35:42 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	31/9F-25276-DA673845; Sat, 06 Dec 2014 21:35:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1417901739!13874952!1
X-Originating-IP: [66.165.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 588 invoked from network); 6 Dec 2014 21:35:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Dec 2014 21:35:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,530,1413244800"; d="scan'208";a="200933082"
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.210.2; Sat, 6 Dec 2014 16:35: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 1XxN0r-0007WZ-Js;
	Sat, 06 Dec 2014 21:35:37 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxN0r-0002Wg-DV;
	Sat, 06 Dec 2014 21:35:37 +0000
Date: Sat, 6 Dec 2014 21:35:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32106-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] 32106: 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 32106 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32106/

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-win7-amd64  3 host-install(3)          broken pass in 32086
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3)   broken pass in 32086

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-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
 build-i386-rumpuserxen      3 host-install(3) broken in 32086 blocked in 26303
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 32086 like 26261
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 17 leak-check/check fail in 32086 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           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-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-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-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)        blocked in 32086 n/a
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 32086 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 32086 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                     fail    
 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                         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                                broken  
 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-win7-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemut-win7-amd64 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 Sun Dec 07 03:08:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 03: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 1XxSBy-0006Fq-BI; Sun, 07 Dec 2014 03:07:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XxSBw-0006Fl-LQ
	for xen-devel@lists.xensource.com; Sun, 07 Dec 2014 03:07:24 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	05/01-22777-B64C3845; Sun, 07 Dec 2014 03:07:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417921641!11970606!1
X-Originating-IP: [66.165.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 4371 invoked from network); 7 Dec 2014 03:07:22 -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;
	7 Dec 2014 03:07:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,532,1413244800"; d="scan'208";a="201364728"
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.210.2; Sat, 6 Dec 2014 22:07: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 1XxSBr-0000ga-6a;
	Sun, 07 Dec 2014 03:07:19 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxSBr-0002Ra-0v;
	Sun, 07 Dec 2014 03:07:19 +0000
Date: Sun, 7 Dec 2014 03:07:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32110-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] 32110: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32110 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32110/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 31811
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31811

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      8 debian-fixup                fail pass in 32089
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-saverestore.2 fail pass in 32089

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      1 build-check(1)               blocked  n/a
 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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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-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-amd64-libvirt      9 guest-start           fail in 32089 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 32089 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                                          fail    
 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                                     blocked 
 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                                     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-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 Dec 07 03:08:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 03: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 1XxSBy-0006Fq-BI; Sun, 07 Dec 2014 03:07:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XxSBw-0006Fl-LQ
	for xen-devel@lists.xensource.com; Sun, 07 Dec 2014 03:07:24 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	05/01-22777-B64C3845; Sun, 07 Dec 2014 03:07:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1417921641!11970606!1
X-Originating-IP: [66.165.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 4371 invoked from network); 7 Dec 2014 03:07:22 -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;
	7 Dec 2014 03:07:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,532,1413244800"; d="scan'208";a="201364728"
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.210.2; Sat, 6 Dec 2014 22:07: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 1XxSBr-0000ga-6a;
	Sun, 07 Dec 2014 03:07:19 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxSBr-0002Ra-0v;
	Sun, 07 Dec 2014 03:07:19 +0000
Date: Sun, 7 Dec 2014 03:07:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32110-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] 32110: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32110 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32110/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 31811
 test-amd64-i386-pair   17 guest-migrate/src_host/dst_host fail REGR. vs. 31811

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      8 debian-fixup                fail pass in 32089
 test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-saverestore.2 fail pass in 32089

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      1 build-check(1)               blocked  n/a
 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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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-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-amd64-libvirt      9 guest-start           fail in 32089 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 32089 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                                          fail    
 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                                     blocked 
 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                                     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-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 Dec 07 06:40:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 06:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxVVk-0002kY-2Y; Sun, 07 Dec 2014 06:40: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 1XxVVi-0002kP-3m
	for xen-devel@lists.xensource.com; Sun, 07 Dec 2014 06:40:02 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	B2/34-28865-146F3845; Sun, 07 Dec 2014 06:40:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417934399!11937867!1
X-Originating-IP: [66.165.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 16177 invoked from network); 7 Dec 2014 06:40:00 -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 Dec 2014 06:40:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,532,1413244800"; d="scan'208";a="201013438"
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.210.2; Sun, 7 Dec 2014 01:39: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 1XxVVd-0001ks-Cv;
	Sun, 07 Dec 2014 06:39:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxVVd-0001JF-75;
	Sun, 07 Dec 2014 06:39:57 +0000
Date: Sun, 7 Dec 2014 06:39:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32122-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 3536
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32122: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1444154272093951116=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1444154272093951116==
Content-Type: text/plain
Content-Length: 3150
Content-Transfer-Encoding: quoted-printable

flight 32122 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32122/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32005
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32005
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32005

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              253319ced6e9e92992f59000e3810b7d3ab59750
baseline version:
 libvirt              ff018e686a8a412255bc34d3dc558a1bcf74fac5

------------------------------------------------------------
People who touched revisions under test:
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Cole Robinson <crobinso@redhat.com>
  Conrad Meyer <cse.cem@gmail.com>
  Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
  Daniel P. Berrange <berrange@redhat.com>
  Dmitry Guryanov <dguryanov@parallels.com>
  Erik Skultety <eskultet@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Laine Stump <laine@laine.org>
  Luyao Huang <lhuang@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>
  Shanzhi Yu <shyu@redhat.com>
  Wang Rui <moon.wangrui@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 760 lines long.)


--===============1444154272093951116==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1444154272093951116==--

From xen-devel-bounces@lists.xen.org Sun Dec 07 06:40:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 06:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxVVk-0002kY-2Y; Sun, 07 Dec 2014 06:40: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 1XxVVi-0002kP-3m
	for xen-devel@lists.xensource.com; Sun, 07 Dec 2014 06:40:02 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	B2/34-28865-146F3845; Sun, 07 Dec 2014 06:40:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1417934399!11937867!1
X-Originating-IP: [66.165.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 16177 invoked from network); 7 Dec 2014 06:40:00 -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 Dec 2014 06:40:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,532,1413244800"; d="scan'208";a="201013438"
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.210.2; Sun, 7 Dec 2014 01:39: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 1XxVVd-0001ks-Cv;
	Sun, 07 Dec 2014 06:39:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxVVd-0001JF-75;
	Sun, 07 Dec 2014 06:39:57 +0000
Date: Sun, 7 Dec 2014 06:39:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32122-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 3536
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32122: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1444154272093951116=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1444154272093951116==
Content-Type: text/plain
Content-Length: 3150
Content-Transfer-Encoding: quoted-printable

flight 32122 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32122/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32005
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32005
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32005

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              253319ced6e9e92992f59000e3810b7d3ab59750
baseline version:
 libvirt              ff018e686a8a412255bc34d3dc558a1bcf74fac5

------------------------------------------------------------
People who touched revisions under test:
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Cole Robinson <crobinso@redhat.com>
  Conrad Meyer <cse.cem@gmail.com>
  Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
  Daniel P. Berrange <berrange@redhat.com>
  Dmitry Guryanov <dguryanov@parallels.com>
  Erik Skultety <eskultet@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Laine Stump <laine@laine.org>
  Luyao Huang <lhuang@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>
  Shanzhi Yu <shyu@redhat.com>
  Wang Rui <moon.wangrui@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 760 lines long.)


--===============1444154272093951116==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1444154272093951116==--

From xen-devel-bounces@lists.xen.org Sun Dec 07 10:03:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 10:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxYgA-00089n-0b; Sun, 07 Dec 2014 10:03:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XxYg8-00089g-B2
	for xen-devel@lists.xensource.com; Sun, 07 Dec 2014 10:03:00 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	D0/88-27584-3D524845; Sun, 07 Dec 2014 10:02:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417946577!9090719!1
X-Originating-IP: [66.165.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 16099 invoked from network); 7 Dec 2014 10:02:58 -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 Dec 2014 10:02:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,533,1413244800"; d="scan'208";a="201427860"
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.210.2; Sun, 7 Dec 2014 05:02: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 1XxYg3-0002ji-NW;
	Sun, 07 Dec 2014 10:02:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxYg3-0000Im-Fj;
	Sun, 07 Dec 2014 10:02:55 +0000
Date: Sun, 7 Dec 2014 10:02:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32114-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] 32114: 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 32114 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32114/

Regressions :-(

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. 32093
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 32093
 build-armhf-pvops             4 host-build-prep           fail REGR. vs. 32093

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start              fail blocked in 32093
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32093

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      1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 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-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-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-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-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                  10e7747bca538205555e313574432f231070153b
baseline version:
 xen                  3a80985b894f54eb3b2e143e4dea737cf139a517

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Chunyan Liu <cyliu@suse.com>
  Daniel Kiper <daniel.kiper@oracle.com>
  Don Dugger <donald.d.dugger@intel.com>
  Euan Harris <euan.harris@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>
  Kevin Tian <kevin.tian@intel.com>
  M A Young <m.a.young@durham.ac.uk>
  Michael Young <m.a.young@durham.ac.uk>
  Olaf Hering <olaf@aepfle.de>
  Razvan Cojocaru <rcojocaru@bitdefender.com>
  Tim Deegan <tim@xen.org>
  Vitaly Kuznetsov <vkuznets@redhat.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                                            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                                 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                            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)
broken-step test-amd64-i386-xl-qemut-winxpsp3-vcpus1 host-install(3)

Not pushing.

(No revision log; it would be 368 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 Dec 07 10:03:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 10:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxYgA-00089n-0b; Sun, 07 Dec 2014 10:03:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XxYg8-00089g-B2
	for xen-devel@lists.xensource.com; Sun, 07 Dec 2014 10:03:00 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	D0/88-27584-3D524845; Sun, 07 Dec 2014 10:02:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1417946577!9090719!1
X-Originating-IP: [66.165.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 16099 invoked from network); 7 Dec 2014 10:02:58 -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 Dec 2014 10:02:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,533,1413244800"; d="scan'208";a="201427860"
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.210.2; Sun, 7 Dec 2014 05:02: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 1XxYg3-0002ji-NW;
	Sun, 07 Dec 2014 10:02:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxYg3-0000Im-Fj;
	Sun, 07 Dec 2014 10:02:55 +0000
Date: Sun, 7 Dec 2014 10:02:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32114-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] 32114: 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 32114 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32114/

Regressions :-(

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. 32093
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 32093
 build-armhf-pvops             4 host-build-prep           fail REGR. vs. 32093

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start              fail blocked in 32093
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32093

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      1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 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-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-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-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-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                  10e7747bca538205555e313574432f231070153b
baseline version:
 xen                  3a80985b894f54eb3b2e143e4dea737cf139a517

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Chunyan Liu <cyliu@suse.com>
  Daniel Kiper <daniel.kiper@oracle.com>
  Don Dugger <donald.d.dugger@intel.com>
  Euan Harris <euan.harris@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>
  Kevin Tian <kevin.tian@intel.com>
  M A Young <m.a.young@durham.ac.uk>
  Michael Young <m.a.young@durham.ac.uk>
  Olaf Hering <olaf@aepfle.de>
  Razvan Cojocaru <rcojocaru@bitdefender.com>
  Tim Deegan <tim@xen.org>
  Vitaly Kuznetsov <vkuznets@redhat.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                                            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                                 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                            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)
broken-step test-amd64-i386-xl-qemut-winxpsp3-vcpus1 host-install(3)

Not pushing.

(No revision log; it would be 368 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 Dec 07 12:32:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 12: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 1Xxb0P-0003QB-U2; Sun, 07 Dec 2014 12:32:05 +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 1Xxb0O-0003Q6-Fp
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 12:32:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	72/57-25276-3C844845; Sun, 07 Dec 2014 12:32:03 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417955522!6659475!1
X-Originating-IP: [62.142.5.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTA3ID0+IDk5ODc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11427 invoked from network); 7 Dec 2014 12:32:03 -0000
Received: from emh01.mail.saunalahti.fi (HELO emh01.mail.saunalahti.fi)
	(62.142.5.107)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2014 12:32:03 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 575189005B;
	Sun,  7 Dec 2014 14:32:01 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 22BB036C01F; Sun,  7 Dec 2014 14:32:01 +0200 (EET)
Date: Sun, 7 Dec 2014 14:32:00 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141207123200.GA12451@reaktio.net>
References: <1409199272-5155-1-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1409199272-5155-1-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Olaf Hering <olaf@aepfle.de>, ian.campbell@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH V5] Update pvSCSI protocol description /
 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

Hello,

Juergen/Olaf: Now that Xen PVSCSI drivers are in upstream Linux 3.18 kernel 
I was wondering if you guys also have plans to work on adding xl / libxl support for PVSCSI ? 


Thanks,

-- Pasi

On Thu, Aug 28, 2014 at 06:14:32AM +0200, Juergen Gross wrote:
> Update the protocol description of the pvSCSI framework used to pass through
> SCSI devices to a guest (pv or hvm).
> 
> The main changes are:
> - added comments
> - add support for larger SG-lists by putting them in an own granted page
> - deprecate VSCSIIF_ACT_SCSI_SG_PRESET action with related structures
> - add ref_rqid for action VSCSIIF_ACT_SCSI_ABORT to be able to specify the
>   request to abort
> - deprecate timeout_per_command as this really should be handled by the
>   backend in case of default settings or by the guest domain by aborting a
>   long running command
> 
> This update is related to the rework of the pvSCSI backend and frontend drivers
> in the Linux kernel. This interface version is included in that rework, too.
> 
> 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>
> ---
>  xen/include/public/io/vscsiif.h | 185 +++++++++++++++++++++++++++++++++++-----
>  1 file changed, 164 insertions(+), 21 deletions(-)
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 12:32:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 12: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 1Xxb0P-0003QB-U2; Sun, 07 Dec 2014 12:32:05 +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 1Xxb0O-0003Q6-Fp
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 12:32:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	72/57-25276-3C844845; Sun, 07 Dec 2014 12:32:03 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-21.messagelabs.com!1417955522!6659475!1
X-Originating-IP: [62.142.5.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTQyLjUuMTA3ID0+IDk5ODc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11427 invoked from network); 7 Dec 2014 12:32:03 -0000
Received: from emh01.mail.saunalahti.fi (HELO emh01.mail.saunalahti.fi)
	(62.142.5.107)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2014 12:32:03 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 575189005B;
	Sun,  7 Dec 2014 14:32:01 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 22BB036C01F; Sun,  7 Dec 2014 14:32:01 +0200 (EET)
Date: Sun, 7 Dec 2014 14:32:00 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141207123200.GA12451@reaktio.net>
References: <1409199272-5155-1-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1409199272-5155-1-git-send-email-jgross@suse.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Olaf Hering <olaf@aepfle.de>, ian.campbell@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH V5] Update pvSCSI protocol description /
 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

Hello,

Juergen/Olaf: Now that Xen PVSCSI drivers are in upstream Linux 3.18 kernel 
I was wondering if you guys also have plans to work on adding xl / libxl support for PVSCSI ? 


Thanks,

-- Pasi

On Thu, Aug 28, 2014 at 06:14:32AM +0200, Juergen Gross wrote:
> Update the protocol description of the pvSCSI framework used to pass through
> SCSI devices to a guest (pv or hvm).
> 
> The main changes are:
> - added comments
> - add support for larger SG-lists by putting them in an own granted page
> - deprecate VSCSIIF_ACT_SCSI_SG_PRESET action with related structures
> - add ref_rqid for action VSCSIIF_ACT_SCSI_ABORT to be able to specify the
>   request to abort
> - deprecate timeout_per_command as this really should be handled by the
>   backend in case of default settings or by the guest domain by aborting a
>   long running command
> 
> This update is related to the rework of the pvSCSI backend and frontend drivers
> in the Linux kernel. This interface version is included in that rework, too.
> 
> 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>
> ---
>  xen/include/public/io/vscsiif.h | 185 +++++++++++++++++++++++++++++++++++-----
>  1 file changed, 164 insertions(+), 21 deletions(-)
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 13:37:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 13:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxc0c-0004vm-0O; Sun, 07 Dec 2014 13:36: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 1Xxc0a-0004vh-Bj
	for xen-devel@lists.xensource.com; Sun, 07 Dec 2014 13:36:20 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	72/94-17958-3D754845; Sun, 07 Dec 2014 13:36:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417959377!11622266!1
X-Originating-IP: [66.165.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 26551 invoked from network); 7 Dec 2014 13:36:18 -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;
	7 Dec 2014 13:36:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,533,1413244800"; d="scan'208";a="201077078"
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.210.2; Sun, 7 Dec 2014 08:36: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 1Xxc0V-0003lj-BX;
	Sun, 07 Dec 2014 13:36:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xxc0U-0002Ov-VV;
	Sun, 07 Dec 2014 13:36:15 +0000
Date: Sun, 7 Dec 2014 13:36:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32117-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] 32117: 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 32117 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32117/

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 32096

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-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-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-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                d00e6cddc220de993573dfb5fd160ac72ccd49ab
baseline version:
 qemuu                54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5

------------------------------------------------------------
People who touched revisions under test:
  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                    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=d00e6cddc220de993573dfb5fd160ac72ccd49ab
+ . 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 d00e6cddc220de993573dfb5fd160ac72ccd49ab
+ branch=qemu-mainline
+ revision=d00e6cddc220de993573dfb5fd160ac72ccd49ab
+ . 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 d00e6cddc220de993573dfb5fd160ac72ccd49ab:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   54f3a18..d00e6cd  d00e6cddc220de993573dfb5fd160ac72ccd49ab -> 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 Sun Dec 07 13:37:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 13:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxc0c-0004vm-0O; Sun, 07 Dec 2014 13:36: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 1Xxc0a-0004vh-Bj
	for xen-devel@lists.xensource.com; Sun, 07 Dec 2014 13:36:20 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	72/94-17958-3D754845; Sun, 07 Dec 2014 13:36:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417959377!11622266!1
X-Originating-IP: [66.165.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 26551 invoked from network); 7 Dec 2014 13:36:18 -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;
	7 Dec 2014 13:36:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,533,1413244800"; d="scan'208";a="201077078"
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.210.2; Sun, 7 Dec 2014 08:36: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 1Xxc0V-0003lj-BX;
	Sun, 07 Dec 2014 13:36:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xxc0U-0002Ov-VV;
	Sun, 07 Dec 2014 13:36:15 +0000
Date: Sun, 7 Dec 2014 13:36:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32117-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] 32117: 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 32117 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32117/

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 32096

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-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-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-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                d00e6cddc220de993573dfb5fd160ac72ccd49ab
baseline version:
 qemuu                54f3a180a3d0b334c55d0f61d6e9fe5c7c6d42d5

------------------------------------------------------------
People who touched revisions under test:
  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                    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=d00e6cddc220de993573dfb5fd160ac72ccd49ab
+ . 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 d00e6cddc220de993573dfb5fd160ac72ccd49ab
+ branch=qemu-mainline
+ revision=d00e6cddc220de993573dfb5fd160ac72ccd49ab
+ . 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 d00e6cddc220de993573dfb5fd160ac72ccd49ab:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   54f3a18..d00e6cd  d00e6cddc220de993573dfb5fd160ac72ccd49ab -> 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 Sun Dec 07 13:44:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 13:44:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxc8f-0005I9-Vw; Sun, 07 Dec 2014 13:44:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bob.liu@oracle.com>) id 1Xxc8e-0005I3-MS
	for xen-devel@lists.xenproject.org; Sun, 07 Dec 2014 13:44:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B9/BD-25276-7C954845; Sun, 07 Dec 2014 13:44:39 +0000
X-Env-Sender: bob.liu@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417959876!13937740!1
X-Originating-IP: [156.151.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 15946 invoked from network); 7 Dec 2014 13:44:37 -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 Dec 2014 13:44:37 -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 sB7DiTp5010343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 7 Dec 2014 13:44:30 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
	sB7DiPxj013596
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 7 Dec 2014 13:44:26 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
	sB7DiPav013455; Sun, 7 Dec 2014 13:44:25 GMT
Received: from [192.168.3.8] (/218.82.189.246)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 07 Dec 2014 05:44:24 -0800
Message-ID: <5484597A.507@oracle.com>
Date: Sun, 07 Dec 2014 21:43:22 +0800
From: Bob Liu <bob.liu@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546F1033.7030005@oracle.com> <54818221.1070804@oracle.com>
	<5481B1F6020000780004D24A@mail.emea.novell.com>
In-Reply-To: <5481B1F6020000780004D24A@mail.emea.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.campbell@citrix.com, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A good way to speed up the xl destroy time(guest
	page scrubbing)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/05/2014 08:24 PM, Jan Beulich wrote:
>>>> On 05.12.14 at 11:00, <bob.liu@oracle.com> wrote:
>> 5. Potential workaround
>> 5.1 Use per-cpu list in idle_loop()
>> Delist a batch of pages from heap_list to a per-cpu list, then scrub the
>> per-cpu list and free back to heap_list.
>>
>> But Jan disagree with this solution:
>> "You should really drop the idea of removing pages temporarily.
>> All you need to do is make sure a page being allocated and getting
>> simultaneously scrubbed by another CPU won't get passed to the
>> caller until the scrubbing finished."
> 
> So you don't mention any downsides to this approach. If there are
> any, please name them. If there aren't, what's the reason not to
> go this route?

The reason was what you suggested was not very specific, I still have no
idea how to implement a patch which can "make sure a page being
allocated and getting simultaneously scrubbed by another CPU won't get
passed to the caller until the scrubbing finished".

Thanks,
-Bob

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 13:44:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 13:44:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxc8f-0005I9-Vw; Sun, 07 Dec 2014 13:44:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bob.liu@oracle.com>) id 1Xxc8e-0005I3-MS
	for xen-devel@lists.xenproject.org; Sun, 07 Dec 2014 13:44:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B9/BD-25276-7C954845; Sun, 07 Dec 2014 13:44:39 +0000
X-Env-Sender: bob.liu@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1417959876!13937740!1
X-Originating-IP: [156.151.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 15946 invoked from network); 7 Dec 2014 13:44:37 -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 Dec 2014 13:44:37 -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 sB7DiTp5010343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 7 Dec 2014 13:44:30 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
	sB7DiPxj013596
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 7 Dec 2014 13:44:26 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
	sB7DiPav013455; Sun, 7 Dec 2014 13:44:25 GMT
Received: from [192.168.3.8] (/218.82.189.246)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 07 Dec 2014 05:44:24 -0800
Message-ID: <5484597A.507@oracle.com>
Date: Sun, 07 Dec 2014 21:43:22 +0800
From: Bob Liu <bob.liu@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546F1033.7030005@oracle.com> <54818221.1070804@oracle.com>
	<5481B1F6020000780004D24A@mail.emea.novell.com>
In-Reply-To: <5481B1F6020000780004D24A@mail.emea.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.campbell@citrix.com, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A good way to speed up the xl destroy time(guest
	page scrubbing)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/05/2014 08:24 PM, Jan Beulich wrote:
>>>> On 05.12.14 at 11:00, <bob.liu@oracle.com> wrote:
>> 5. Potential workaround
>> 5.1 Use per-cpu list in idle_loop()
>> Delist a batch of pages from heap_list to a per-cpu list, then scrub the
>> per-cpu list and free back to heap_list.
>>
>> But Jan disagree with this solution:
>> "You should really drop the idea of removing pages temporarily.
>> All you need to do is make sure a page being allocated and getting
>> simultaneously scrubbed by another CPU won't get passed to the
>> caller until the scrubbing finished."
> 
> So you don't mention any downsides to this approach. If there are
> any, please name them. If there aren't, what's the reason not to
> go this route?

The reason was what you suggested was not very specific, I still have no
idea how to implement a patch which can "make sure a page being
allocated and getting simultaneously scrubbed by another CPU won't get
passed to the caller until the scrubbing finished".

Thanks,
-Bob

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 17:54:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 17: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 1Xxg28-00033d-G9; Sun, 07 Dec 2014 17:54:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1Xxg27-00033Y-B4
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 17:54:11 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	54/5D-17735-24494845; Sun, 07 Dec 2014 17:54:10 +0000
X-Env-Sender: SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417974849!7204637!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2820 invoked from network); 7 Dec 2014 17:54:09 -0000
Received: from domu-toccata.ens-lyon.fr (HELO sonata.ens-lyon.org)
	(140.77.166.138)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2014 17:54:09 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id E39E5200C5;
	Sun,  7 Dec 2014 18:54:08 +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 cfREJat0kHcv; Sun,  7 Dec 2014 18:54:08 +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 5D94D200C4;
	Sun,  7 Dec 2014 18:54:08 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1Xxg21-0005la-EE; Sun, 07 Dec 2014 18:54:05 +0100
Date: Sun, 7 Dec 2014 18:54:05 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141207175405.GO3141@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com>
	<20141205182208.GC19077@dezo.moloch.sk>
MIME-Version: 1.0
Content-Length: 622
Content-Disposition: inline
In-Reply-To: <20141205182208.GC19077@dezo.moloch.sk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

Martin Lucina, le Fri 05 Dec 2014 19:22:08 +0100, a =E9crit :
> What's up with the -DHAVE_LIBC codepaths in mini-os? Who or what uses
> these? Grepping around in stubdom/ doesn't come up with anything...

HAVE_LIBC gets defined by extra/mini-os/Config.mk when libc is y, and
libc is defined to $(stubdom), which is set to y from stubdom/Makefile

Basically everything in stubdom/ uses HAVE_LIBC.

I don't know where the qemu-stubdom part is currently stored, but it
uses it too.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 17:54:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 17: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 1Xxg28-00033d-G9; Sun, 07 Dec 2014 17:54:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1Xxg27-00033Y-B4
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 17:54:11 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	54/5D-17735-24494845; Sun, 07 Dec 2014 17:54:10 +0000
X-Env-Sender: SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-6.tower-31.messagelabs.com!1417974849!7204637!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2820 invoked from network); 7 Dec 2014 17:54:09 -0000
Received: from domu-toccata.ens-lyon.fr (HELO sonata.ens-lyon.org)
	(140.77.166.138)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2014 17:54:09 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id E39E5200C5;
	Sun,  7 Dec 2014 18:54:08 +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 cfREJat0kHcv; Sun,  7 Dec 2014 18:54:08 +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 5D94D200C4;
	Sun,  7 Dec 2014 18:54:08 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1Xxg21-0005la-EE; Sun, 07 Dec 2014 18:54:05 +0100
Date: Sun, 7 Dec 2014 18:54:05 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141207175405.GO3141@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com>
	<20141205182208.GC19077@dezo.moloch.sk>
MIME-Version: 1.0
Content-Length: 622
Content-Disposition: inline
In-Reply-To: <20141205182208.GC19077@dezo.moloch.sk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

Martin Lucina, le Fri 05 Dec 2014 19:22:08 +0100, a =E9crit :
> What's up with the -DHAVE_LIBC codepaths in mini-os? Who or what uses
> these? Grepping around in stubdom/ doesn't come up with anything...

HAVE_LIBC gets defined by extra/mini-os/Config.mk when libc is y, and
libc is defined to $(stubdom), which is set to y from stubdom/Makefile

Basically everything in stubdom/ uses HAVE_LIBC.

I don't know where the qemu-stubdom part is currently stored, but it
uses it too.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 17:56:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 17:56:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxg3s-00037a-W8; Sun, 07 Dec 2014 17:56:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1Xxg3r-00037Q-Bl
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 17:55:59 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	A0/D7-02953-EA494845; Sun, 07 Dec 2014 17:55:58 +0000
X-Env-Sender: SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417974957!13541617!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7503 invoked from network); 7 Dec 2014 17:55:58 -0000
Received: from domu-toccata.ens-lyon.fr (HELO sonata.ens-lyon.org)
	(140.77.166.138)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2014 17:55:58 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id BF146200C8;
	Sun,  7 Dec 2014 18:55:57 +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 3IPdbwKUt6ZH; Sun,  7 Dec 2014 18:55:57 +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 90B31200C6;
	Sun,  7 Dec 2014 18:55:57 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1Xxg3n-0005nH-7P; Sun, 07 Dec 2014 18:55:55 +0100
Date: Sun, 7 Dec 2014 18:55:55 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Antti Kantee <pooka@iki.fi>
Message-ID: <20141207175555.GP3141@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Antti Kantee <pooka@iki.fi>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
MIME-Version: 1.0
Content-Length: 438
Content-Disposition: inline
In-Reply-To: <5480E595.1010204@iki.fi>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy <anil@recoil.org>,
	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
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Antti Kantee, le Thu 04 Dec 2014 22:52:05 +0000, a =E9crit :
> Currently, the software stack in rumprun-xen is confusing
> because MiniOS partially uses libc

Which part of libc? MiniOS itself is very independent of libc, it only
ships a couple of things. We can probably happily #ifdef them if needed.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 17:56:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 17:56:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxg3s-00037a-W8; Sun, 07 Dec 2014 17:56:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1Xxg3r-00037Q-Bl
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 17:55:59 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	A0/D7-02953-EA494845; Sun, 07 Dec 2014 17:55:58 +0000
X-Env-Sender: SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-12.tower-27.messagelabs.com!1417974957!13541617!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7503 invoked from network); 7 Dec 2014 17:55:58 -0000
Received: from domu-toccata.ens-lyon.fr (HELO sonata.ens-lyon.org)
	(140.77.166.138)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2014 17:55:58 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id BF146200C8;
	Sun,  7 Dec 2014 18:55:57 +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 3IPdbwKUt6ZH; Sun,  7 Dec 2014 18:55:57 +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 90B31200C6;
	Sun,  7 Dec 2014 18:55:57 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1Xxg3n-0005nH-7P; Sun, 07 Dec 2014 18:55:55 +0100
Date: Sun, 7 Dec 2014 18:55:55 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Antti Kantee <pooka@iki.fi>
Message-ID: <20141207175555.GP3141@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Antti Kantee <pooka@iki.fi>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
MIME-Version: 1.0
Content-Length: 438
Content-Disposition: inline
In-Reply-To: <5480E595.1010204@iki.fi>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy <anil@recoil.org>,
	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
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Antti Kantee, le Thu 04 Dec 2014 22:52:05 +0000, a =E9crit :
> Currently, the software stack in rumprun-xen is confusing
> because MiniOS partially uses libc

Which part of libc? MiniOS itself is very independent of libc, it only
ships a couple of things. We can probably happily #ifdef them if needed.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 18:03:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 18: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 1XxgAU-0003cE-Rw; Sun, 07 Dec 2014 18:02:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1XxgAU-0003c9-1H
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 18:02:50 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9F/C4-25276-94694845; Sun, 07 Dec 2014 18:02:49 +0000
X-Env-Sender: SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417975368!13996445!1
X-Originating-IP: [140.77.166.138]
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 29408 invoked from network); 7 Dec 2014 18:02:48 -0000
Received: from sonata.ens-lyon.org (HELO sonata.ens-lyon.org) (140.77.166.138)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2014 18:02:48 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id 27AF8200D0;
	Sun,  7 Dec 2014 19:02:48 +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 T3NMeNENqMDv; Sun,  7 Dec 2014 19:02:48 +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 CDD8D200CE;
	Sun,  7 Dec 2014 19:02:47 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1XxgAP-0005uf-Mh; Sun, 07 Dec 2014 19:02:45 +0100
Date: Sun, 7 Dec 2014 19:02:45 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141207180245.GQ3141@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
MIME-Version: 1.0
Content-Length: 2492
Content-Disposition: inline
In-Reply-To: <20141204142757.GD11192@dezo.moloch.sk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

Martin Lucina, le Thu 04 Dec 2014 15:27:57 +0100, a =E9crit :
> - Is there a general interest in upstreaming this work?

I believe so.  That can only help people using minios.

> - 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.

That looks fine.

> - In the case of drivers, eg. init|shutdown_blkfront are renamed to
>   blkfront_*.

Right, good thing :)

> - 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.

That looks fine too.

> - 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.

The stubdom/ directory needs to be updated too, as well as the
qemu-stubdom directory (I unfortunately don't know where it is
maintained ATM).

> - Upstream Mini-OS provides things we (rumpkernel.org) don't need (stub
>   "libc", ...). If we are to move to upstream then we will need to do a
>   more general cleanup of Mini-OS to make these pluggable. Again, is there
>   upstream interest in this work?

Yes.  It should be feasible to make the tiny libc inside minios
pluggable, so you can plug things a better way for you. It's fine to
have #ifdefs in extra/mini-os/lib/

> - As there is no formal API for Mini-OS. My changes only address the
>   "public" functionality used by rumprun-xen. Other users mileage will
>   vary; who else should I coordinate with?

I guess anybody who will have seen this thread on this list :)

> - I have not namespaced macros such as local_irq_save(). Should this be
>   done? =


It should be fine not to do it.

>   Also, the driver namespaces have been preserved (since I was lazy), the=
se
>   should probably be renamed under the minios namespace; it's plausible
>   some day someone will try to link an application with a function called
>   blkfront_init().

I'd say that while we are breaking the existing API, let's do it for
good and rename the driver namespace too.

Providing a header with backward-compatibility renaming macros for all
of this would however be useful, to be nicer to out-of-tree users.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 18:03:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 18: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 1XxgAU-0003cE-Rw; Sun, 07 Dec 2014 18:02:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1XxgAU-0003c9-1H
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 18:02:50 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9F/C4-25276-94694845; Sun, 07 Dec 2014 18:02:49 +0000
X-Env-Sender: SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-8.tower-21.messagelabs.com!1417975368!13996445!1
X-Originating-IP: [140.77.166.138]
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 29408 invoked from network); 7 Dec 2014 18:02:48 -0000
Received: from sonata.ens-lyon.org (HELO sonata.ens-lyon.org) (140.77.166.138)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2014 18:02:48 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id 27AF8200D0;
	Sun,  7 Dec 2014 19:02:48 +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 T3NMeNENqMDv; Sun,  7 Dec 2014 19:02:48 +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 CDD8D200CE;
	Sun,  7 Dec 2014 19:02:47 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1XxgAP-0005uf-Mh; Sun, 07 Dec 2014 19:02:45 +0100
Date: Sun, 7 Dec 2014 19:02:45 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141207180245.GQ3141@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
MIME-Version: 1.0
Content-Length: 2492
Content-Disposition: inline
In-Reply-To: <20141204142757.GD11192@dezo.moloch.sk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

Martin Lucina, le Thu 04 Dec 2014 15:27:57 +0100, a =E9crit :
> - Is there a general interest in upstreaming this work?

I believe so.  That can only help people using minios.

> - 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.

That looks fine.

> - In the case of drivers, eg. init|shutdown_blkfront are renamed to
>   blkfront_*.

Right, good thing :)

> - 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.

That looks fine too.

> - 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.

The stubdom/ directory needs to be updated too, as well as the
qemu-stubdom directory (I unfortunately don't know where it is
maintained ATM).

> - Upstream Mini-OS provides things we (rumpkernel.org) don't need (stub
>   "libc", ...). If we are to move to upstream then we will need to do a
>   more general cleanup of Mini-OS to make these pluggable. Again, is there
>   upstream interest in this work?

Yes.  It should be feasible to make the tiny libc inside minios
pluggable, so you can plug things a better way for you. It's fine to
have #ifdefs in extra/mini-os/lib/

> - As there is no formal API for Mini-OS. My changes only address the
>   "public" functionality used by rumprun-xen. Other users mileage will
>   vary; who else should I coordinate with?

I guess anybody who will have seen this thread on this list :)

> - I have not namespaced macros such as local_irq_save(). Should this be
>   done? =


It should be fine not to do it.

>   Also, the driver namespaces have been preserved (since I was lazy), the=
se
>   should probably be renamed under the minios namespace; it's plausible
>   some day someone will try to link an application with a function called
>   blkfront_init().

I'd say that while we are breaking the existing API, let's do it for
good and rename the driver namespace too.

Providing a header with backward-compatibility renaming macros for all
of this would however be useful, to be nicer to out-of-tree users.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 18:03:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 18: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 1XxgBH-0003gR-Ft; Sun, 07 Dec 2014 18:03:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1XxgBG-0003gC-Ax
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 18:03:38 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	37/35-05632-97694845; Sun, 07 Dec 2014 18:03:37 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417975416!11641374!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24967 invoked from network); 7 Dec 2014 18:03:37 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-16.tower-31.messagelabs.com with SMTP;
	7 Dec 2014 18:03:37 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id F0FF7308940;
	Sun,  7 Dec 2014 20:03:34 +0200 (EET)
Message-ID: <54849675.6070008@iki.fi>
Date: Sun, 07 Dec 2014 18:03:33 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net, 
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
	<20141207175555.GP3141@type.youpi.perso.aquilenet.fr>
In-Reply-To: <20141207175555.GP3141@type.youpi.perso.aquilenet.fr>
Content-Length: 645
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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 07/12/14 17:55, Samuel Thibault wrote:
> Antti Kantee, le Thu 04 Dec 2014 22:52:05 +0000, a =E9crit :
>> Currently, the software stack in rumprun-xen is confusing
>> because MiniOS partially uses libc
>
> Which part of libc? MiniOS itself is very independent of libc, it only
> ships a couple of things. We can probably happily #ifdef them if needed.

I said it unclearly.  I meant the use of

#include <lotofthings.h> (e.g. string.h, stdio.h, etc)

I'd rather see a well-defined interface there instead of ifdefs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 18:03:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 18: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 1XxgBH-0003gR-Ft; Sun, 07 Dec 2014 18:03:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pooka@iki.fi>) id 1XxgBG-0003gC-Ax
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 18:03:38 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	37/35-05632-97694845; Sun, 07 Dec 2014 18:03:37 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-16.tower-31.messagelabs.com!1417975416!11641374!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24967 invoked from network); 7 Dec 2014 18:03:37 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-16.tower-31.messagelabs.com with SMTP;
	7 Dec 2014 18:03:37 -0000
Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8])
	by mail.cs.hut.fi (Postfix) with ESMTPS id F0FF7308940;
	Sun,  7 Dec 2014 20:03:34 +0200 (EET)
Message-ID: <54849675.6070008@iki.fi>
Date: Sun, 07 Dec 2014 18:03:33 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net, 
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
	<20141207175555.GP3141@type.youpi.perso.aquilenet.fr>
In-Reply-To: <20141207175555.GP3141@type.youpi.perso.aquilenet.fr>
Content-Length: 645
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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 07/12/14 17:55, Samuel Thibault wrote:
> Antti Kantee, le Thu 04 Dec 2014 22:52:05 +0000, a =E9crit :
>> Currently, the software stack in rumprun-xen is confusing
>> because MiniOS partially uses libc
>
> Which part of libc? MiniOS itself is very independent of libc, it only
> ships a couple of things. We can probably happily #ifdef them if needed.

I said it unclearly.  I meant the use of

#include <lotofthings.h> (e.g. string.h, stdio.h, etc)

I'd rather see a well-defined interface there instead of ifdefs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 18:09:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 18: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 1XxgGd-0003ul-9t; Sun, 07 Dec 2014 18:09:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1XxgGb-0003ug-Lv
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 18:09:09 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	F8/79-07724-4C794845; Sun, 07 Dec 2014 18:09:08 +0000
X-Env-Sender: SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417975748!11591881!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9115 invoked from network); 7 Dec 2014 18:09:08 -0000
Received: from sonata.ens-lyon.org (HELO sonata.ens-lyon.org) (140.77.166.138)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2014 18:09:08 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id 0BA3B200CE;
	Sun,  7 Dec 2014 19:09:08 +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 iWJsqNzLvSiQ; Sun,  7 Dec 2014 19:09:07 +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 9A7AF200C2;
	Sun,  7 Dec 2014 19:09:07 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1XxgGW-000649-DH; Sun, 07 Dec 2014 19:09:04 +0100
Date: Sun, 7 Dec 2014 19:09:04 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Antti Kantee <pooka@iki.fi>
Message-ID: <20141207180904.GS3141@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Antti Kantee <pooka@iki.fi>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
	<20141207175555.GP3141@type.youpi.perso.aquilenet.fr>
	<54849675.6070008@iki.fi>
MIME-Version: 1.0
Content-Length: 870
Content-Disposition: inline
In-Reply-To: <54849675.6070008@iki.fi>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy <anil@recoil.org>,
	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
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Antti Kantee, le Sun 07 Dec 2014 18:03:33 +0000, a =E9crit :
> On 07/12/14 17:55, Samuel Thibault wrote:
> >Antti Kantee, le Thu 04 Dec 2014 22:52:05 +0000, a =E9crit :
> >>Currently, the software stack in rumprun-xen is confusing
> >>because MiniOS partially uses libc
> >
> >Which part of libc? MiniOS itself is very independent of libc, it only
> >ships a couple of things. We can probably happily #ifdef them if needed.
> =

> I said it unclearly.  I meant the use of
> =

> #include <lotofthings.h> (e.g. string.h, stdio.h, etc)

?

minios itself doesn't do this when it's not compiled with HAVE_LIBC.
Building with HAVE_LIBC is really not a requirement for using mini-os.
For rump projects, I would expect not using it, notably.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 18:09:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 18: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 1XxgGd-0003ul-9t; Sun, 07 Dec 2014 18:09:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1XxgGb-0003ug-Lv
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 18:09:09 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	F8/79-07724-4C794845; Sun, 07 Dec 2014 18:09:08 +0000
X-Env-Sender: SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-4.tower-31.messagelabs.com!1417975748!11591881!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9115 invoked from network); 7 Dec 2014 18:09:08 -0000
Received: from sonata.ens-lyon.org (HELO sonata.ens-lyon.org) (140.77.166.138)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Dec 2014 18:09:08 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id 0BA3B200CE;
	Sun,  7 Dec 2014 19:09:08 +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 iWJsqNzLvSiQ; Sun,  7 Dec 2014 19:09:07 +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 9A7AF200C2;
	Sun,  7 Dec 2014 19:09:07 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1XxgGW-000649-DH; Sun, 07 Dec 2014 19:09:04 +0100
Date: Sun, 7 Dec 2014 19:09:04 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Antti Kantee <pooka@iki.fi>
Message-ID: <20141207180904.GS3141@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Antti Kantee <pooka@iki.fi>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
	<20141207175555.GP3141@type.youpi.perso.aquilenet.fr>
	<54849675.6070008@iki.fi>
MIME-Version: 1.0
Content-Length: 870
Content-Disposition: inline
In-Reply-To: <54849675.6070008@iki.fi>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy <anil@recoil.org>,
	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
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Antti Kantee, le Sun 07 Dec 2014 18:03:33 +0000, a =E9crit :
> On 07/12/14 17:55, Samuel Thibault wrote:
> >Antti Kantee, le Thu 04 Dec 2014 22:52:05 +0000, a =E9crit :
> >>Currently, the software stack in rumprun-xen is confusing
> >>because MiniOS partially uses libc
> >
> >Which part of libc? MiniOS itself is very independent of libc, it only
> >ships a couple of things. We can probably happily #ifdef them if needed.
> =

> I said it unclearly.  I meant the use of
> =

> #include <lotofthings.h> (e.g. string.h, stdio.h, etc)

?

minios itself doesn't do this when it's not compiled with HAVE_LIBC.
Building with HAVE_LIBC is really not a requirement for using mini-os.
For rump projects, I would expect not using it, notably.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 18:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 18:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxgL2-0004G9-01; Sun, 07 Dec 2014 18:13:44 +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 1XxgL1-0004G3-4u
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 18:13:43 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	8F/A7-02696-6D894845; Sun, 07 Dec 2014 18:13:42 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417976021!8885186!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28272 invoked from network); 7 Dec 2014 18:13:41 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-5.tower-27.messagelabs.com with SMTP;
	7 Dec 2014 18:13: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 D600B308956;
	Sun,  7 Dec 2014 20:13:39 +0200 (EET)
Message-ID: <548498D2.8000505@iki.fi>
Date: Sun, 07 Dec 2014 18:13:38 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net, 
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
	<20141207175555.GP3141@type.youpi.perso.aquilenet.fr>
	<54849675.6070008@iki.fi>
	<20141207180904.GS3141@type.youpi.perso.aquilenet.fr>
In-Reply-To: <20141207180904.GS3141@type.youpi.perso.aquilenet.fr>
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/14 18:09, Samuel Thibault wrote:
>> I said it unclearly.  I meant the use of
>>
>> #include <lotofthings.h> (e.g. string.h, stdio.h, etc)
>
> ?
>
> minios itself doesn't do this when it's not compiled with HAVE_LIBC.
> Building with HAVE_LIBC is really not a requirement for using mini-os.
> For rump projects, I would expect not using it, notably.

 From xen.git/extras/mini-os, irrespective of HAVE_LIBC:

netfront.c includes <errno.h>, kernel.c includes <fcntl.h>, pcifront.c 
includes <string.h> ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 18:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 18:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxgL2-0004G9-01; Sun, 07 Dec 2014 18:13:44 +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 1XxgL1-0004G3-4u
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 18:13:43 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	8F/A7-02696-6D894845; Sun, 07 Dec 2014 18:13:42 +0000
X-Env-Sender: pooka@iki.fi
X-Msg-Ref: server-5.tower-27.messagelabs.com!1417976021!8885186!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28272 invoked from network); 7 Dec 2014 18:13:41 -0000
Received: from mail.cs.hut.fi (HELO mail.cs.hut.fi) (130.233.192.7)
	by server-5.tower-27.messagelabs.com with SMTP;
	7 Dec 2014 18:13: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 D600B308956;
	Sun,  7 Dec 2014 20:13:39 +0200 (EET)
Message-ID: <548498D2.8000505@iki.fi>
Date: Sun, 07 Dec 2014 18:13:38 +0000
From: Antti Kantee <pooka@iki.fi>
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net, 
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
	<20141207175555.GP3141@type.youpi.perso.aquilenet.fr>
	<54849675.6070008@iki.fi>
	<20141207180904.GS3141@type.youpi.perso.aquilenet.fr>
In-Reply-To: <20141207180904.GS3141@type.youpi.perso.aquilenet.fr>
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/14 18:09, Samuel Thibault wrote:
>> I said it unclearly.  I meant the use of
>>
>> #include <lotofthings.h> (e.g. string.h, stdio.h, etc)
>
> ?
>
> minios itself doesn't do this when it's not compiled with HAVE_LIBC.
> Building with HAVE_LIBC is really not a requirement for using mini-os.
> For rump projects, I would expect not using it, notably.

 From xen.git/extras/mini-os, irrespective of HAVE_LIBC:

netfront.c includes <errno.h>, kernel.c includes <fcntl.h>, pcifront.c 
includes <string.h> ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 18:42:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 18:42:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxgm4-0004sg-FV; Sun, 07 Dec 2014 18:41:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1Xxgm3-0004sb-Cl
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 18:41:39 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	7A/AA-24859-26F94845; Sun, 07 Dec 2014 18:41:38 +0000
X-Env-Sender: SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417977697!11661166!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2242 invoked from network); 7 Dec 2014 18:41:38 -0000
Received: from domu-toccata.ens-lyon.fr (HELO sonata.ens-lyon.org)
	(140.77.166.138)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2014 18:41:38 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id 5C032200CE;
	Sun,  7 Dec 2014 19:41:37 +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 XcQSVXF4UoLG; Sun,  7 Dec 2014 19:41:37 +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 EB613200C8;
	Sun,  7 Dec 2014 19:41:36 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1Xxglx-0006wq-I5; Sun, 07 Dec 2014 19:41:33 +0100
Date: Sun, 7 Dec 2014 19:41:33 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Antti Kantee <pooka@iki.fi>
Message-ID: <20141207184133.GU3141@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Antti Kantee <pooka@iki.fi>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
	<20141207175555.GP3141@type.youpi.perso.aquilenet.fr>
	<54849675.6070008@iki.fi>
	<20141207180904.GS3141@type.youpi.perso.aquilenet.fr>
	<548498D2.8000505@iki.fi>
MIME-Version: 1.0
Content-Length: 719
Content-Disposition: inline
In-Reply-To: <548498D2.8000505@iki.fi>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy <anil@recoil.org>,
	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
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Antti Kantee, le Sun 07 Dec 2014 18:13:38 +0000, a =E9crit :
> On 07/12/14 18:09, Samuel Thibault wrote:
> >>I said it unclearly.  I meant the use of
> >>
> >>#include <lotofthings.h> (e.g. string.h, stdio.h, etc)
> >
> >?
> >
> >minios itself doesn't do this when it's not compiled with HAVE_LIBC.
> >Building with HAVE_LIBC is really not a requirement for using mini-os.
> >For rump projects, I would expect not using it, notably.
> =

> From xen.git/extras/mini-os, irrespective of HAVE_LIBC:
> =

> netfront.c includes <errno.h>,

That include should actually be #ifdef HAVE_LIBC

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 18:42:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 18:42:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxgm4-0004sg-FV; Sun, 07 Dec 2014 18:41:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1Xxgm3-0004sb-Cl
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 18:41:39 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	7A/AA-24859-26F94845; Sun, 07 Dec 2014 18:41:38 +0000
X-Env-Sender: SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-8.tower-31.messagelabs.com!1417977697!11661166!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2242 invoked from network); 7 Dec 2014 18:41:38 -0000
Received: from domu-toccata.ens-lyon.fr (HELO sonata.ens-lyon.org)
	(140.77.166.138)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2014 18:41:38 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id 5C032200CE;
	Sun,  7 Dec 2014 19:41:37 +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 XcQSVXF4UoLG; Sun,  7 Dec 2014 19:41:37 +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 EB613200C8;
	Sun,  7 Dec 2014 19:41:36 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1Xxglx-0006wq-I5; Sun, 07 Dec 2014 19:41:33 +0100
Date: Sun, 7 Dec 2014 19:41:33 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Antti Kantee <pooka@iki.fi>
Message-ID: <20141207184133.GU3141@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Antti Kantee <pooka@iki.fi>,
	Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org,
	rumpkernel-users@lists.sourceforge.net,
	Anil Madhavapeddy <anil@recoil.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <5480E595.1010204@iki.fi>
	<20141207175555.GP3141@type.youpi.perso.aquilenet.fr>
	<54849675.6070008@iki.fi>
	<20141207180904.GS3141@type.youpi.perso.aquilenet.fr>
	<548498D2.8000505@iki.fi>
MIME-Version: 1.0
Content-Length: 719
Content-Disposition: inline
In-Reply-To: <548498D2.8000505@iki.fi>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy <anil@recoil.org>,
	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
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Antti Kantee, le Sun 07 Dec 2014 18:13:38 +0000, a =E9crit :
> On 07/12/14 18:09, Samuel Thibault wrote:
> >>I said it unclearly.  I meant the use of
> >>
> >>#include <lotofthings.h> (e.g. string.h, stdio.h, etc)
> >
> >?
> >
> >minios itself doesn't do this when it's not compiled with HAVE_LIBC.
> >Building with HAVE_LIBC is really not a requirement for using mini-os.
> >For rump projects, I would expect not using it, notably.
> =

> From xen.git/extras/mini-os, irrespective of HAVE_LIBC:
> =

> netfront.c includes <errno.h>,

That include should actually be #ifdef HAVE_LIBC

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 19:37:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 19: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 1Xxhdp-0006XH-3R; Sun, 07 Dec 2014 19:37:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xxhdn-0006XC-Hl
	for xen-devel@lists.xensource.com; Sun, 07 Dec 2014 19:37:11 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	D8/89-27584-66CA4845; Sun, 07 Dec 2014 19:37:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417981028!11994926!1
X-Originating-IP: [66.165.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 20192 invoked from network); 7 Dec 2014 19:37:10 -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;
	7 Dec 2014 19:37:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,534,1413244800"; d="scan'208";a="201138871"
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.210.2; Sun, 7 Dec 2014 14:37: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 1Xxhdi-0005Uk-PN;
	Sun, 07 Dec 2014 19:37:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xxhdi-0006SX-8J;
	Sun, 07 Dec 2014 19:37:06 +0000
Date: Sun, 7 Dec 2014 19:37:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32124-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] 32124: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32124 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32124/

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-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
 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-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-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 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-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-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-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                56c67ce187a899f76c5f22dd30fd9cfc3d95a0c2
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
728 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 32274 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 Dec 07 19:37:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 19: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 1Xxhdp-0006XH-3R; Sun, 07 Dec 2014 19:37:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xxhdn-0006XC-Hl
	for xen-devel@lists.xensource.com; Sun, 07 Dec 2014 19:37:11 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	D8/89-27584-66CA4845; Sun, 07 Dec 2014 19:37:10 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1417981028!11994926!1
X-Originating-IP: [66.165.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 20192 invoked from network); 7 Dec 2014 19:37:10 -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;
	7 Dec 2014 19:37:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,534,1413244800"; d="scan'208";a="201138871"
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.210.2; Sun, 7 Dec 2014 14:37: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 1Xxhdi-0005Uk-PN;
	Sun, 07 Dec 2014 19:37:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xxhdi-0006SX-8J;
	Sun, 07 Dec 2014 19:37:06 +0000
Date: Sun, 7 Dec 2014 19:37:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32124-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] 32124: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32124 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32124/

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-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
 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-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-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 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-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-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-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                56c67ce187a899f76c5f22dd30fd9cfc3d95a0c2
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
728 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 32274 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 Dec 07 19:54:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 19:54:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxhtu-00076g-M1; Sun, 07 Dec 2014 19:53:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1Xxhts-00076b-EU
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 19:53:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1A/F3-25276-B40B4845; Sun, 07 Dec 2014 19:53:47 +0000
X-Env-Sender: SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417982026!5964749!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2675 invoked from network); 7 Dec 2014 19:53:47 -0000
Received: from domu-toccata.ens-lyon.fr (HELO sonata.ens-lyon.org)
	(140.77.166.138)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2014 19:53:47 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id 4D74B200D5;
	Sun,  7 Dec 2014 20:53:46 +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 UjuqxSQL75iZ; Sun,  7 Dec 2014 20:53:46 +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 C382B200D3;
	Sun,  7 Dec 2014 20:53:45 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1Xxhtn-0000S5-Hs; Sun, 07 Dec 2014 20:53:43 +0100
Date: Sun, 7 Dec 2014 20:53:43 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
Message-ID: <20141207195343.GC3141@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
References: <20141204135550.GC11192@dezo.moloch.sk>
MIME-Version: 1.0
Content-Length: 1897
Content-Disposition: inline
In-Reply-To: <20141204135550.GC11192@dezo.moloch.sk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Subject: Re: [Xen-devel] [PATCH] Mini-OS: netfront: Fix rx ring starvation
	in network_rx
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

Martin Lucina, le Thu 04 Dec 2014 14:55:50 +0100, a =E9crit :
> following is a patch against vanilla Mini-OS in upstream xen.git for a
> problem we have found in the netfront driver. When subjected to load
> network receive would freeze due to the rx ring running out of free
> request slots.

Oh, indeed nr_consumed seems to have been wrongly initialized.  Could
you submit a patch that only moves the nr_consumed =3D 0 initialization
and the bogus BUG_ON?

> -        if (rx->flags & NETRXF_extra_info)
> -        {
> -            printk("+++++++++++++++++++++ we have extras!\n");
> -            continue;
> -        }
> -
> -
> -        if (rx->status =3D=3D NETIF_RSP_NULL) continue;

I believe we want to keep them.  Or turn them into
if (rx->status !=3D NETIF_RSP_OKAY)
  continue;

the HAVE_LIBC codepath will be fine with the change.

> Further, I would like to clean this function up; the code is an impossible
> to follow mess. What I'd like to arrive at is at [2],

I agree with stuffing the "cons" initialization into the for loop, but:

> however this also needs(?) to address the -DHAVE_LIBC codepath.

Yes, and I introduced the "some" variable especially for this. The
idea was to implement a basic support for opening the device with a
tap behavior.  But we didn't want to introduce dynamic buffers to
store incoming packets.  In that case we don't run network_rx from the
interrupt, but netfront_select_handler instead, which will wake the
select() call, the application then calls netfront_receive(), which eats
exactly one packet only from the ring.  Thus the "some" variable in
order to break the loop when exactly one packet was eaten (and no, we
can't use break or set cons to rp, since that'd would eat 0 or more than
1 packets).

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 19:54:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 19:54:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxhtu-00076g-M1; Sun, 07 Dec 2014 19:53:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1Xxhts-00076b-EU
	for xen-devel@lists.xen.org; Sun, 07 Dec 2014 19:53:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1A/F3-25276-B40B4845; Sun, 07 Dec 2014 19:53:47 +0000
X-Env-Sender: SRS0=QwA2=A3=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-2.tower-21.messagelabs.com!1417982026!5964749!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2675 invoked from network); 7 Dec 2014 19:53:47 -0000
Received: from domu-toccata.ens-lyon.fr (HELO sonata.ens-lyon.org)
	(140.77.166.138)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Dec 2014 19:53:47 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id 4D74B200D5;
	Sun,  7 Dec 2014 20:53:46 +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 UjuqxSQL75iZ; Sun,  7 Dec 2014 20:53:46 +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 C382B200D3;
	Sun,  7 Dec 2014 20:53:45 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1Xxhtn-0000S5-Hs; Sun, 07 Dec 2014 20:53:43 +0100
Date: Sun, 7 Dec 2014 20:53:43 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
Message-ID: <20141207195343.GC3141@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
References: <20141204135550.GC11192@dezo.moloch.sk>
MIME-Version: 1.0
Content-Length: 1897
Content-Disposition: inline
In-Reply-To: <20141204135550.GC11192@dezo.moloch.sk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Subject: Re: [Xen-devel] [PATCH] Mini-OS: netfront: Fix rx ring starvation
	in network_rx
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

Martin Lucina, le Thu 04 Dec 2014 14:55:50 +0100, a =E9crit :
> following is a patch against vanilla Mini-OS in upstream xen.git for a
> problem we have found in the netfront driver. When subjected to load
> network receive would freeze due to the rx ring running out of free
> request slots.

Oh, indeed nr_consumed seems to have been wrongly initialized.  Could
you submit a patch that only moves the nr_consumed =3D 0 initialization
and the bogus BUG_ON?

> -        if (rx->flags & NETRXF_extra_info)
> -        {
> -            printk("+++++++++++++++++++++ we have extras!\n");
> -            continue;
> -        }
> -
> -
> -        if (rx->status =3D=3D NETIF_RSP_NULL) continue;

I believe we want to keep them.  Or turn them into
if (rx->status !=3D NETIF_RSP_OKAY)
  continue;

the HAVE_LIBC codepath will be fine with the change.

> Further, I would like to clean this function up; the code is an impossible
> to follow mess. What I'd like to arrive at is at [2],

I agree with stuffing the "cons" initialization into the for loop, but:

> however this also needs(?) to address the -DHAVE_LIBC codepath.

Yes, and I introduced the "some" variable especially for this. The
idea was to implement a basic support for opening the device with a
tap behavior.  But we didn't want to introduce dynamic buffers to
store incoming packets.  In that case we don't run network_rx from the
interrupt, but netfront_select_handler instead, which will wake the
select() call, the application then calls netfront_receive(), which eats
exactly one packet only from the ring.  Thus the "some" variable in
order to break the loop when exactly one packet was eaten (and no, we
can't use break or set cons to rp, since that'd would eat 0 or more than
1 packets).

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 20:16:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 20: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 1XxiFE-0007lU-Ky; Sun, 07 Dec 2014 20:15:52 +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 1XxiFD-0007lP-Uv
	for xen-devel@lists.xenproject.org; Sun, 07 Dec 2014 20:15:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	85/7A-15461-775B4845; Sun, 07 Dec 2014 20:15:51 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417983349!13978023!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27974 invoked from network); 7 Dec 2014 20:15:50 -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; 7 Dec 2014 20:15: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 sB7KFh0U028543
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 7 Dec 2014 20:15:45 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
	sB7KFgpL010161
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 7 Dec 2014 20:15:43 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
	sB7KFfd7014244; Sun, 7 Dec 2014 20:15:42 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 07 Dec 2014 12:15:41 -0800
Date: Sun, 7 Dec 2014 21:15:36 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141207201536.GG16236@olila.local.net-space.pl>
References: <5481F18C020000780004D535@mail.emea.novell.com>
	<20141205172257.GC16236@olila.local.net-space.pl>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205172257.GC16236@olila.local.net-space.pl>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 06:22:57PM +0100, Daniel Kiper wrote:
> On Fri, Dec 05, 2014 at 04:55:24PM +0000, Jan Beulich wrote:
> > ... when "conring_size=" was specified on the command line. We can't
> > really do this as early as we would want to when the option was not
> > specified, as the default depends on knowing the system CPU count. Yet
> > the parsing of the ACPI tables is one of the things that generates a
> > lot of output especially on large systems.
> >
> > I didn't change ARM, as I wasn't sure how far ahead this call could be
> > pulled.
> >
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> Make sense for me but I think that we should have the same thing for ARM too.

Hmmm... Even it is better I still think that your proposal is too intrusive
at this stage of 4.5 development. However, I think that Konrad has the last
word in that case.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 20:16:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 20: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 1XxiFE-0007lU-Ky; Sun, 07 Dec 2014 20:15:52 +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 1XxiFD-0007lP-Uv
	for xen-devel@lists.xenproject.org; Sun, 07 Dec 2014 20:15:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	85/7A-15461-775B4845; Sun, 07 Dec 2014 20:15:51 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1417983349!13978023!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27974 invoked from network); 7 Dec 2014 20:15:50 -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; 7 Dec 2014 20:15: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 sB7KFh0U028543
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 7 Dec 2014 20:15:45 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
	sB7KFgpL010161
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 7 Dec 2014 20:15:43 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
	sB7KFfd7014244; Sun, 7 Dec 2014 20:15:42 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 07 Dec 2014 12:15:41 -0800
Date: Sun, 7 Dec 2014 21:15:36 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141207201536.GG16236@olila.local.net-space.pl>
References: <5481F18C020000780004D535@mail.emea.novell.com>
	<20141205172257.GC16236@olila.local.net-space.pl>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205172257.GC16236@olila.local.net-space.pl>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, 2014 at 06:22:57PM +0100, Daniel Kiper wrote:
> On Fri, Dec 05, 2014 at 04:55:24PM +0000, Jan Beulich wrote:
> > ... when "conring_size=" was specified on the command line. We can't
> > really do this as early as we would want to when the option was not
> > specified, as the default depends on knowing the system CPU count. Yet
> > the parsing of the ACPI tables is one of the things that generates a
> > lot of output especially on large systems.
> >
> > I didn't change ARM, as I wasn't sure how far ahead this call could be
> > pulled.
> >
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> Make sense for me but I think that we should have the same thing for ARM too.

Hmmm... Even it is better I still think that your proposal is too intrusive
at this stage of 4.5 development. However, I think that Konrad has the last
word in that case.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 07 22:15:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 22: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 1Xxk6O-0002Ma-3m; Sun, 07 Dec 2014 22:14: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 1Xxk6N-0002MV-Jm
	for xen-devel@lists.xensource.com; Sun, 07 Dec 2014 22:14:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5B/DC-09842-A51D4845; Sun, 07 Dec 2014 22:14:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417990488!13662730!1
X-Originating-IP: [66.165.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 22990 invoked from network); 7 Dec 2014 22:14:49 -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 Dec 2014 22:14:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,534,1413244800"; d="scan'208";a="201169946"
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.210.2; Sun, 7 Dec 2014 17:14: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 1Xxk6I-0006FQ-JC;
	Sun, 07 Dec 2014 22:14:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xxk6I-0006BC-Ch;
	Sun, 07 Dec 2014 22:14:46 +0000
Date: Sun, 7 Dec 2014 22:14:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32126-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] 32126: 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 32126 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32126/

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 32071

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-winxpsp3-vcpus1 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-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-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-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              56b252ea737c1514916d6df4493f89ff71322f60
baseline version:
 seabios              e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f

------------------------------------------------------------
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


Pushing revision :

+ branch=seabios
+ revision=56b252ea737c1514916d6df4493f89ff71322f60
+ . 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 56b252ea737c1514916d6df4493f89ff71322f60
+ branch=seabios
+ revision=56b252ea737c1514916d6df4493f89ff71322f60
+ . 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 56b252ea737c1514916d6df4493f89ff71322f60:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   e5f4338..56b252e  56b252ea737c1514916d6df4493f89ff71322f60 -> 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 Dec 07 22:15:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 22: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 1Xxk6O-0002Ma-3m; Sun, 07 Dec 2014 22:14: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 1Xxk6N-0002MV-Jm
	for xen-devel@lists.xensource.com; Sun, 07 Dec 2014 22:14:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5B/DC-09842-A51D4845; Sun, 07 Dec 2014 22:14:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1417990488!13662730!1
X-Originating-IP: [66.165.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 22990 invoked from network); 7 Dec 2014 22:14:49 -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 Dec 2014 22:14:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,534,1413244800"; d="scan'208";a="201169946"
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.210.2; Sun, 7 Dec 2014 17:14: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 1Xxk6I-0006FQ-JC;
	Sun, 07 Dec 2014 22:14:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xxk6I-0006BC-Ch;
	Sun, 07 Dec 2014 22:14:46 +0000
Date: Sun, 7 Dec 2014 22:14:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32126-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] 32126: 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 32126 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32126/

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 32071

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-winxpsp3-vcpus1 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-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-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-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              56b252ea737c1514916d6df4493f89ff71322f60
baseline version:
 seabios              e5f43384be5cf5983f03e3f4c1cb7bbeaba2af3f

------------------------------------------------------------
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


Pushing revision :

+ branch=seabios
+ revision=56b252ea737c1514916d6df4493f89ff71322f60
+ . 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 56b252ea737c1514916d6df4493f89ff71322f60
+ branch=seabios
+ revision=56b252ea737c1514916d6df4493f89ff71322f60
+ . 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 56b252ea737c1514916d6df4493f89ff71322f60:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   e5f4338..56b252e  56b252ea737c1514916d6df4493f89ff71322f60 -> 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 Dec 07 23:58:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 23:58:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxliO-0004rv-0c; Sun, 07 Dec 2014 23:58:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XxliM-0004rq-Uc
	for xen-devel@lists.xenproject.org; Sun, 07 Dec 2014 23:58:11 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	C6/F8-02953-299E4845; Sun, 07 Dec 2014 23:58:10 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417996687!10217654!1
X-Originating-IP: [91.199.104.161]
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 24658 invoked from network); 7 Dec 2014 23:58:08 -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; 7 Dec 2014 23:58:08 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=ZOZhDtSPbg2aXL8EVY4umU6Ajd5mfQzRrvNzR8z4CGdyH9Cp4+qKBwT8518et+yqLMVCPA0LNVswhg7bjZnFzfLpJUR8XYLW17qIgleaV/cdTMLQRT6JUbbLgxvCNcylrMyjQhV3jGVafuUfwuFtU0cAx9LK8e4lYjJ/NVAKkGvdUHGxuFsF5l3D8SO5osjta4rLveeSafsL4IpIze7uS10cmoiKNySjxpVsiXIlqED91bI8z/PIHboBd8vZvLZAfbLzkTdOfqlLWrfpBFoV3BBvuGirIBicufI9aDgoIRnJKV5RLXva5pk0TuuSLoucXszP8jbLuEVG14OX2QKQPg==;
	h=Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:cc:subject:message-id:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	bh=Fu2ea0llJwiTj7vqaY6usxjB2K0=; b=Ab3wjrB3hg5gCT10KAd+hTHVXkoV
	6UNyQXsIE5zgFonjgx9YMoJ9SQIk5+vMHc1pVy80kdokdVYRjOeWh8q8cChzEpwp
	qM2EJK4AIpUOkTruVDTBvOEozR4C+WZHchYt0IbWXqjFHnAMyXbYsZfn7U+NuZ4t
	kPygmb5sOXWHElb+qSpeu4r1Go1SbdWjGUHQp2Wey3+Zi3zapNWVfdcbrnXA1Mez
	jIGaP5BrDvYRrkufJ24nzbJqP0hbWPDdFzKo5j9eiDsh8YvHRswijGibBcDeR7GE
	Fdf2x48D1fGw2qvpUoCxO0pdwtua2ncfDrVKC6Pen+UaZGL3ELap4dHcjQ==
Received: (qmail 27055 invoked from network); 8 Dec 2014 01:58: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;
	8 Dec 2014 01:58:06 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 7F58F80338
	for <xen-devel@lists.xenproject.org>;
	Mon,  8 Dec 2014 01:58:04 +0200 (EET)
Received: (qmail 27450 invoked from network); 8 Dec 2014 01:58:04 +0200
Received: from 5-12-114-134.residential.rdsnet.ro (HELO bitdefender.com)
	(mdontu@bitdefender.com@5.12.114.134)
	by smtp02.buh.bitdefender.net with SMTP; 8 Dec 2014 01:58:01 +0200
Date: Mon, 8 Dec 2014 01:58:01 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20141208015801.3ce41104@bitdefender.com>
In-Reply-To: <5481AE6E020000780004D22C@mail.emea.novell.com>
References: <1417712500-28009-1-git-send-email-mdontu@bitdefender.com>
	<5481AE6E020000780004D22C@mail.emea.novell.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.58171
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374349,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_SIDE_EFFECTS;
	NN_LEGIT_VALID_REPLY; NN_LEGIT_SUMM_400_WORDS; NN_NO_LINK_NMD;
	NN_LEGIT_BITDEFENDER; NN_LEGIT_S_SQARE_BRACKETS], SGN: [Enabled], URL:
	[Enabled], RTDA: [Enabled, Hit: No, Details: Error:
	onPost(20012)(400)], total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xmalloc: add support for checking the pool
 integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpZGF5IDA1IERlY2VtYmVyIDIwMTQgMTI6MDk6MDIgSmFuIEJldWxpY2ggd3JvdGU6Cj4g
Pj4+IE9uIDA0LjEyLjE0IGF0IDE4OjAxLCA8bWRvbnR1QGJpdGRlZmVuZGVyLmNvbT4gd3JvdGU6
Cj4gPiAtLS0gYS94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jCj4gPiArKysgYi94ZW4vY29tbW9u
L3htYWxsb2NfdGxzZi5jCj4gPiBAQCAtMTIwLDkgKzEyMCwxMjAgQEAgc3RydWN0IHhtZW1fcG9v
bCB7Cj4gPiAgICAgIGNoYXIgbmFtZVtNQVhfUE9PTF9OQU1FX0xFTl07Cj4gPiAgfTsKPiA+ICAK
PiA+ICtzdGF0aWMgc3RydWN0IHhtZW1fcG9vbCAqeGVucG9vbDsKPiA+ICsKPiA+ICtzdGF0aWMg
aW5saW5lIHZvaWQgTUFQUElOR19JTlNFUlQodW5zaWduZWQgbG9uZyByLCBpbnQgKmZsLCBpbnQg
KnNsKTsKPiA+ICsKPiA+ICAvKgo+ID4gICAqIEhlbHBpbmcgZnVuY3Rpb25zCj4gPiAgICovCj4g
PiArI2lmbmRlZiBOREVCVUcKPiA+ICtzdGF0aWMgaW50IHhtZW1fcG9vbF9jaGVja19zaXplKGNv
bnN0IHN0cnVjdCBiaGRyICpiLCBpbnQgZmwsIGludCBzbCkKPiA+ICt7Cj4gPiArICAgIHdoaWxl
ICggYiApCj4gPiArICAgIHsKPiA+ICsgICAgICAgIGludCBfX2ZsOwo+ID4gKyAgICAgICAgaW50
IF9fc2w7Cj4gPiArCj4gPiArICAgICAgICBNQVBQSU5HX0lOU0VSVChiLT5zaXplLCAmX19mbCwg
Jl9fc2wpOwo+ID4gKyAgICAgICAgaWYgKCBfX2ZsICE9IGZsIHx8IF9fc2wgIT0gc2wgKQo+ID4g
KyAgICAgICAgewo+ID4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4bWVtX3Bvb2w6
IGZvciBibG9jayAlcCBzaXplID0gJXUsIHsgZmwgPSAlZCwgc2wgPSAlZCB9IHNob3VsZCBiZSB7
IGZsID0gJWQsIHNsID0gJWQgfVxuIiwgYiwgYi0+c2l6ZSwgZmwsIHNsLCBfX2ZsLCBfX3NsKTsK
PiAKPiBMb25nIGxpbmUuIE9ubHkgdGhlIGZvcm1hdCBtZXNzYWdlIGFsb25lIGlzIGFsbG93ZWQg
dG8gZXhjZWVkIDgwCj4gY2hhcmFjdGVycy4KPiAKPiA+ICsgICAgICAgICAgICByZXR1cm4gMDsK
PiA+ICsgICAgICAgIH0KPiA+ICsgICAgICAgIGIgPSBiLT5wdHIuZnJlZV9wdHIubmV4dDsKPiA+
ICsgICAgfQo+ID4gKyAgICByZXR1cm4gMTsKPiA+ICt9Cj4gPiArCj4gPiArLyoKPiA+ICsgKiBU
aGlzIGZ1bmN0aW9uIG11c3QgYmUgY2FsbGVkIGZyb20gYSBjb250ZXh0IHdoZXJlIHBvb2wtPmxv
Y2sgaXMKPiA+ICsgKiBhbHJlYWR5IGFjcXVpcmVkCj4gPiArICovCj4gPiArI2RlZmluZSB4bWVt
X3Bvb2xfY2hlY2tfdW5sb2NrZWQoX19wb29sKSBfX3htZW1fcG9vbF9jaGVja191bmxvY2tlZChf
X0ZJTEVfXywgX19MSU5FX18sIF9fcG9vbCkKPiAKPiBObyBuZWVkIGZvciB0aGUgZG91YmxlIHVu
ZGVyc2NvcmVzIG9uIHRoZSBtYWNybyBwYXJhbWV0ZXIuCj4gCj4gPiArc3RhdGljIGludCBfX3ht
ZW1fcG9vbF9jaGVja191bmxvY2tlZChjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgY29uc3Qg
Cj4gPiBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ID4gK3sKPiA+ICsgICAgaW50IGk7Cj4gPiAr
ICAgIGludCB3b29wcyA9IDA7Cj4gPiArICAgIHN0YXRpYyBpbnQgb25jZSA9IDE7Cj4gCj4gYm9v
bF90Cj4gCj4gPiArCj4gPiArICAgIGZvciAoIGkgPSAwOyBpIDwgUkVBTF9GTEk7IGkrKyApCj4g
PiArICAgIHsKPiA+ICsgICAgICAgIGludCBmbCA9ICggcG9vbC0+ZmxfYml0bWFwICYgKDEgPDwg
aSkgKSA/IGkgOiAtMTsKPiAKPiBCb2d1cyBzcGFjZXMgaW5zaWRlIHBhcmVudGhlc2VzLgo+IAo+
ID4gKwo+ID4gKyAgICAgICAgaWYgKCBmbCA+PSAwICkKPiA+ICsgICAgICAgIHsKPiA+ICsgICAg
ICAgICAgICBpbnQgajsKPiA+ICsgICAgICAgICAgICBpbnQgYml0bWFwX2VtcHR5ID0gMTsKPiA+
ICsgICAgICAgICAgICBpbnQgbWF0cml4X2VtcHR5ID0gMTsKPiAKPiBGb3IgYW55IG9mIHRoZSBp
bnQtcyBoZXJlIGFuZCBhYm92ZSAtIGNhbiB0aGV5IHJlYWxseSBhbGwgYmVjb21lCj4gbmVnYXRp
dmU/IElmIG5vdCwgdGhleSBvdWdodCB0byBiZSB1bnNpZ25lZCBpbnQgb3IgYm9vbF90Lgo+IAo+
ID4gKwo+ID4gKyAgICAgICAgICAgIGZvciAoIGogPSAwOyBqIDwgTUFYX1NMSTsgaisrICkKPiA+
ICsgICAgICAgICAgICB7Cj4gPiArICAgICAgICAgICAgICAgIGludCBzbCA9ICggcG9vbC0+c2xf
Yml0bWFwW2ZsXSAmICgxIDw8IGopICkgPyBqIDogLTE7Cj4gPiArCj4gPiArICAgICAgICAgICAg
ICAgIGlmICggc2wgPCAwICkKPiA+ICsgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwo+ID4g
Kwo+ID4gKyAgICAgICAgICAgICAgICBpZiAoIG9uY2UgJiYgIXBvb2wtPm1hdHJpeFtmbF1bc2xd
ICkKPiA+ICsgICAgICAgICAgICAgICAgewo+ID4gKyAgICAgICAgICAgICAgICAgICAgLyogVGhl
IGJpdG1hcCBpcyBjb3JydXB0ZWQgKi8KPiA+ICsgICAgICAgICAgICAgICAgICAgIHByaW50ayhY
RU5MT0dfRVJSICJ4bWVtX3Bvb2w6JXM6JWQgdGhlIFRMU0YgYml0bWFwIGlzIGNvcnJ1cHRlZFxu
IiwgZmlsZSwgbGluZSk7Cj4gPiArICAgICAgICAgICAgICAgICAgICBfX3dhcm4oKGNoYXIgKilm
aWxlLCBsaW5lKTsKPiAKPiBQbGVhc2UgY29uc3RpZnkgdGhlIGZpcnN0IHBhcmFtZXRlciBvZiBf
X3dhcm4oKSBpbnN0ZWFkIG9mIGFkZGluZwo+IGZyYWdpbGUgY2FzdHMuIEkgYWxzbyBkb24ndCBz
ZWUgd2h5IGZpbGUgYW5kIGxpbmUgbmVlZCBwcmludGluZyB0d2ljZS4KPiAKPiA+ICtzdGF0aWMg
aW50IF9feG1lbV9wb29sX2NoZWNrX2xvY2tlZChjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwg
c3RydWN0IAo+ID4geG1lbV9wb29sICpwb29sKQo+ID4gK3sKPiA+ICsgICAgaW50IGVycjsKPiA+
ICsKPiA+ICsgICAgc3Bpbl9sb2NrKCZwb29sLT5sb2NrKTsKPiA+ICsgICAgZXJyID0gX194bWVt
X3Bvb2xfY2hlY2tfdW5sb2NrZWQoZmlsZSwgbGluZSwgcG9vbCk7Cj4gCj4gSW52ZXJzZWQgbmFt
aW5nOiBUaGUgY2FsbGVyIGhlcmUgc2hvdWxkIGJlIF91bmxvY2tlZCwgYW5kIHRoZQo+IGNhbGxl
ZSBfbG9ja2VkLgo+IAo+ID4gKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChfX3Bvb2wp
IGRvIHsgaWYgKCAwICYmIChfX3Bvb2wpICk7IH0gd2hpbGUgKDApCj4gPiArI2RlZmluZSB4bWVt
X3Bvb2xfY2hlY2tfdW5sb2NrZWQoX19wb29sKSBkbyB7IGlmICggMCAmJiAoX19wb29sKSApOyB9
IHdoaWxlICgwKQo+IAo+ICgodm9pZCkocG9vbCkpIG9yIGF0IGxlYXN0IGRyb3AgdGhlICIwICYm
IiAtIGFmdGVyIGFsbCB5b3UgX3dhbnRfIHRoZQo+IG1hY3JvIGFyZ3VtZW50IHRvIGJlIGV2YWx1
YXRlZCAoaW4gb3JkZXIgdG8gY2Fycnkgb3V0IHNpZGUgZWZmZWN0cykuCj4gCj4gPiAtLS0gYS94
ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCj4gPiArKysgYi94ZW4vaW5jbHVkZS94ZW4veG1hbGxv
Yy5oCj4gPiBAQCAtMTIzLDQgKzEyMywxMSBAQCB1bnNpZ25lZCBsb25nIHhtZW1fcG9vbF9nZXRf
dXNlZF9zaXplKHN0cnVjdCB4bWVtX3Bvb2wgCj4gPiAqcG9vbCk7Cj4gPiAgICovCj4gPiAgdW5z
aWduZWQgbG9uZyB4bWVtX3Bvb2xfZ2V0X3RvdGFsX3NpemUoc3RydWN0IHhtZW1fcG9vbCAqcG9v
bCk7Cj4gPiAgCj4gPiArI2lmbmRlZiBOREVCVUcKPiA+ICsjZGVmaW5lIHhtZW1fcG9vbF9jaGVj
aygpIF9feG1lbV9wb29sX2NoZWNrKF9fRklMRV9fLCBfX0xJTkVfXykKPiA+ICtpbnQgX194bWVt
X3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpOwo+ID4gKyNlbHNlCj4gPiAr
I2RlZmluZSB4bWVtX3Bvb2xfY2hlY2soKSBkbyB7IGlmICggMCApOyB9IHdoaWxlICgwKQo+IAo+
ICgodm9pZCkwKQo+IAo+IG9yCj4gCj4gZG8ge30gd2hpbGUgKDApCj4gCj4gQWxzbyBwZXJoYXBz
IF9feG1lbV9wb29sX2NoZWNrKCkgc2hvdWxkIGhhdmUgYSBwb29sIHBhcmFtZXRlciwKPiB3aXRo
IE5VTEwgbWVhbmluZyB0aGUgZGVmYXVsdCBvbmUuCj4gCgpUaGFuayB5b3UgZm9yIHlvdXIgcmV2
aWV3IEphbi4gSSdsbCBmb2xsb3cgdXAgd2l0aCBhbiB1cGRhdGUgc29vbiwgYXMKd2VsbCBhcyBh
IHBhdGNoIGZvciBfX3dhcm4oKSAoYW5kIF9fYnVnKCkgd2hpbGUgSSdtIGF0IGl0KS4KCi0tIApN
aWhhaSBET07ImlUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sun Dec 07 23:58:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Dec 2014 23:58:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxliO-0004rv-0c; Sun, 07 Dec 2014 23:58:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XxliM-0004rq-Uc
	for xen-devel@lists.xenproject.org; Sun, 07 Dec 2014 23:58:11 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	C6/F8-02953-299E4845; Sun, 07 Dec 2014 23:58:10 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1417996687!10217654!1
X-Originating-IP: [91.199.104.161]
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 24658 invoked from network); 7 Dec 2014 23:58:08 -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; 7 Dec 2014 23:58:08 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=ZOZhDtSPbg2aXL8EVY4umU6Ajd5mfQzRrvNzR8z4CGdyH9Cp4+qKBwT8518et+yqLMVCPA0LNVswhg7bjZnFzfLpJUR8XYLW17qIgleaV/cdTMLQRT6JUbbLgxvCNcylrMyjQhV3jGVafuUfwuFtU0cAx9LK8e4lYjJ/NVAKkGvdUHGxuFsF5l3D8SO5osjta4rLveeSafsL4IpIze7uS10cmoiKNySjxpVsiXIlqED91bI8z/PIHboBd8vZvLZAfbLzkTdOfqlLWrfpBFoV3BBvuGirIBicufI9aDgoIRnJKV5RLXva5pk0TuuSLoucXszP8jbLuEVG14OX2QKQPg==;
	h=Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:cc:subject:message-id:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	bh=Fu2ea0llJwiTj7vqaY6usxjB2K0=; b=Ab3wjrB3hg5gCT10KAd+hTHVXkoV
	6UNyQXsIE5zgFonjgx9YMoJ9SQIk5+vMHc1pVy80kdokdVYRjOeWh8q8cChzEpwp
	qM2EJK4AIpUOkTruVDTBvOEozR4C+WZHchYt0IbWXqjFHnAMyXbYsZfn7U+NuZ4t
	kPygmb5sOXWHElb+qSpeu4r1Go1SbdWjGUHQp2Wey3+Zi3zapNWVfdcbrnXA1Mez
	jIGaP5BrDvYRrkufJ24nzbJqP0hbWPDdFzKo5j9eiDsh8YvHRswijGibBcDeR7GE
	Fdf2x48D1fGw2qvpUoCxO0pdwtua2ncfDrVKC6Pen+UaZGL3ELap4dHcjQ==
Received: (qmail 27055 invoked from network); 8 Dec 2014 01:58: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;
	8 Dec 2014 01:58:06 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 7F58F80338
	for <xen-devel@lists.xenproject.org>;
	Mon,  8 Dec 2014 01:58:04 +0200 (EET)
Received: (qmail 27450 invoked from network); 8 Dec 2014 01:58:04 +0200
Received: from 5-12-114-134.residential.rdsnet.ro (HELO bitdefender.com)
	(mdontu@bitdefender.com@5.12.114.134)
	by smtp02.buh.bitdefender.net with SMTP; 8 Dec 2014 01:58:01 +0200
Date: Mon, 8 Dec 2014 01:58:01 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20141208015801.3ce41104@bitdefender.com>
In-Reply-To: <5481AE6E020000780004D22C@mail.emea.novell.com>
References: <1417712500-28009-1-git-send-email-mdontu@bitdefender.com>
	<5481AE6E020000780004D22C@mail.emea.novell.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.58171
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374349,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_SIDE_EFFECTS;
	NN_LEGIT_VALID_REPLY; NN_LEGIT_SUMM_400_WORDS; NN_NO_LINK_NMD;
	NN_LEGIT_BITDEFENDER; NN_LEGIT_S_SQARE_BRACKETS], SGN: [Enabled], URL:
	[Enabled], RTDA: [Enabled, Hit: No, Details: Error:
	onPost(20012)(400)], total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xmalloc: add support for checking the pool
 integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpZGF5IDA1IERlY2VtYmVyIDIwMTQgMTI6MDk6MDIgSmFuIEJldWxpY2ggd3JvdGU6Cj4g
Pj4+IE9uIDA0LjEyLjE0IGF0IDE4OjAxLCA8bWRvbnR1QGJpdGRlZmVuZGVyLmNvbT4gd3JvdGU6
Cj4gPiAtLS0gYS94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jCj4gPiArKysgYi94ZW4vY29tbW9u
L3htYWxsb2NfdGxzZi5jCj4gPiBAQCAtMTIwLDkgKzEyMCwxMjAgQEAgc3RydWN0IHhtZW1fcG9v
bCB7Cj4gPiAgICAgIGNoYXIgbmFtZVtNQVhfUE9PTF9OQU1FX0xFTl07Cj4gPiAgfTsKPiA+ICAK
PiA+ICtzdGF0aWMgc3RydWN0IHhtZW1fcG9vbCAqeGVucG9vbDsKPiA+ICsKPiA+ICtzdGF0aWMg
aW5saW5lIHZvaWQgTUFQUElOR19JTlNFUlQodW5zaWduZWQgbG9uZyByLCBpbnQgKmZsLCBpbnQg
KnNsKTsKPiA+ICsKPiA+ICAvKgo+ID4gICAqIEhlbHBpbmcgZnVuY3Rpb25zCj4gPiAgICovCj4g
PiArI2lmbmRlZiBOREVCVUcKPiA+ICtzdGF0aWMgaW50IHhtZW1fcG9vbF9jaGVja19zaXplKGNv
bnN0IHN0cnVjdCBiaGRyICpiLCBpbnQgZmwsIGludCBzbCkKPiA+ICt7Cj4gPiArICAgIHdoaWxl
ICggYiApCj4gPiArICAgIHsKPiA+ICsgICAgICAgIGludCBfX2ZsOwo+ID4gKyAgICAgICAgaW50
IF9fc2w7Cj4gPiArCj4gPiArICAgICAgICBNQVBQSU5HX0lOU0VSVChiLT5zaXplLCAmX19mbCwg
Jl9fc2wpOwo+ID4gKyAgICAgICAgaWYgKCBfX2ZsICE9IGZsIHx8IF9fc2wgIT0gc2wgKQo+ID4g
KyAgICAgICAgewo+ID4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4bWVtX3Bvb2w6
IGZvciBibG9jayAlcCBzaXplID0gJXUsIHsgZmwgPSAlZCwgc2wgPSAlZCB9IHNob3VsZCBiZSB7
IGZsID0gJWQsIHNsID0gJWQgfVxuIiwgYiwgYi0+c2l6ZSwgZmwsIHNsLCBfX2ZsLCBfX3NsKTsK
PiAKPiBMb25nIGxpbmUuIE9ubHkgdGhlIGZvcm1hdCBtZXNzYWdlIGFsb25lIGlzIGFsbG93ZWQg
dG8gZXhjZWVkIDgwCj4gY2hhcmFjdGVycy4KPiAKPiA+ICsgICAgICAgICAgICByZXR1cm4gMDsK
PiA+ICsgICAgICAgIH0KPiA+ICsgICAgICAgIGIgPSBiLT5wdHIuZnJlZV9wdHIubmV4dDsKPiA+
ICsgICAgfQo+ID4gKyAgICByZXR1cm4gMTsKPiA+ICt9Cj4gPiArCj4gPiArLyoKPiA+ICsgKiBU
aGlzIGZ1bmN0aW9uIG11c3QgYmUgY2FsbGVkIGZyb20gYSBjb250ZXh0IHdoZXJlIHBvb2wtPmxv
Y2sgaXMKPiA+ICsgKiBhbHJlYWR5IGFjcXVpcmVkCj4gPiArICovCj4gPiArI2RlZmluZSB4bWVt
X3Bvb2xfY2hlY2tfdW5sb2NrZWQoX19wb29sKSBfX3htZW1fcG9vbF9jaGVja191bmxvY2tlZChf
X0ZJTEVfXywgX19MSU5FX18sIF9fcG9vbCkKPiAKPiBObyBuZWVkIGZvciB0aGUgZG91YmxlIHVu
ZGVyc2NvcmVzIG9uIHRoZSBtYWNybyBwYXJhbWV0ZXIuCj4gCj4gPiArc3RhdGljIGludCBfX3ht
ZW1fcG9vbF9jaGVja191bmxvY2tlZChjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgY29uc3Qg
Cj4gPiBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ID4gK3sKPiA+ICsgICAgaW50IGk7Cj4gPiAr
ICAgIGludCB3b29wcyA9IDA7Cj4gPiArICAgIHN0YXRpYyBpbnQgb25jZSA9IDE7Cj4gCj4gYm9v
bF90Cj4gCj4gPiArCj4gPiArICAgIGZvciAoIGkgPSAwOyBpIDwgUkVBTF9GTEk7IGkrKyApCj4g
PiArICAgIHsKPiA+ICsgICAgICAgIGludCBmbCA9ICggcG9vbC0+ZmxfYml0bWFwICYgKDEgPDwg
aSkgKSA/IGkgOiAtMTsKPiAKPiBCb2d1cyBzcGFjZXMgaW5zaWRlIHBhcmVudGhlc2VzLgo+IAo+
ID4gKwo+ID4gKyAgICAgICAgaWYgKCBmbCA+PSAwICkKPiA+ICsgICAgICAgIHsKPiA+ICsgICAg
ICAgICAgICBpbnQgajsKPiA+ICsgICAgICAgICAgICBpbnQgYml0bWFwX2VtcHR5ID0gMTsKPiA+
ICsgICAgICAgICAgICBpbnQgbWF0cml4X2VtcHR5ID0gMTsKPiAKPiBGb3IgYW55IG9mIHRoZSBp
bnQtcyBoZXJlIGFuZCBhYm92ZSAtIGNhbiB0aGV5IHJlYWxseSBhbGwgYmVjb21lCj4gbmVnYXRp
dmU/IElmIG5vdCwgdGhleSBvdWdodCB0byBiZSB1bnNpZ25lZCBpbnQgb3IgYm9vbF90Lgo+IAo+
ID4gKwo+ID4gKyAgICAgICAgICAgIGZvciAoIGogPSAwOyBqIDwgTUFYX1NMSTsgaisrICkKPiA+
ICsgICAgICAgICAgICB7Cj4gPiArICAgICAgICAgICAgICAgIGludCBzbCA9ICggcG9vbC0+c2xf
Yml0bWFwW2ZsXSAmICgxIDw8IGopICkgPyBqIDogLTE7Cj4gPiArCj4gPiArICAgICAgICAgICAg
ICAgIGlmICggc2wgPCAwICkKPiA+ICsgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwo+ID4g
Kwo+ID4gKyAgICAgICAgICAgICAgICBpZiAoIG9uY2UgJiYgIXBvb2wtPm1hdHJpeFtmbF1bc2xd
ICkKPiA+ICsgICAgICAgICAgICAgICAgewo+ID4gKyAgICAgICAgICAgICAgICAgICAgLyogVGhl
IGJpdG1hcCBpcyBjb3JydXB0ZWQgKi8KPiA+ICsgICAgICAgICAgICAgICAgICAgIHByaW50ayhY
RU5MT0dfRVJSICJ4bWVtX3Bvb2w6JXM6JWQgdGhlIFRMU0YgYml0bWFwIGlzIGNvcnJ1cHRlZFxu
IiwgZmlsZSwgbGluZSk7Cj4gPiArICAgICAgICAgICAgICAgICAgICBfX3dhcm4oKGNoYXIgKilm
aWxlLCBsaW5lKTsKPiAKPiBQbGVhc2UgY29uc3RpZnkgdGhlIGZpcnN0IHBhcmFtZXRlciBvZiBf
X3dhcm4oKSBpbnN0ZWFkIG9mIGFkZGluZwo+IGZyYWdpbGUgY2FzdHMuIEkgYWxzbyBkb24ndCBz
ZWUgd2h5IGZpbGUgYW5kIGxpbmUgbmVlZCBwcmludGluZyB0d2ljZS4KPiAKPiA+ICtzdGF0aWMg
aW50IF9feG1lbV9wb29sX2NoZWNrX2xvY2tlZChjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwg
c3RydWN0IAo+ID4geG1lbV9wb29sICpwb29sKQo+ID4gK3sKPiA+ICsgICAgaW50IGVycjsKPiA+
ICsKPiA+ICsgICAgc3Bpbl9sb2NrKCZwb29sLT5sb2NrKTsKPiA+ICsgICAgZXJyID0gX194bWVt
X3Bvb2xfY2hlY2tfdW5sb2NrZWQoZmlsZSwgbGluZSwgcG9vbCk7Cj4gCj4gSW52ZXJzZWQgbmFt
aW5nOiBUaGUgY2FsbGVyIGhlcmUgc2hvdWxkIGJlIF91bmxvY2tlZCwgYW5kIHRoZQo+IGNhbGxl
ZSBfbG9ja2VkLgo+IAo+ID4gKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChfX3Bvb2wp
IGRvIHsgaWYgKCAwICYmIChfX3Bvb2wpICk7IH0gd2hpbGUgKDApCj4gPiArI2RlZmluZSB4bWVt
X3Bvb2xfY2hlY2tfdW5sb2NrZWQoX19wb29sKSBkbyB7IGlmICggMCAmJiAoX19wb29sKSApOyB9
IHdoaWxlICgwKQo+IAo+ICgodm9pZCkocG9vbCkpIG9yIGF0IGxlYXN0IGRyb3AgdGhlICIwICYm
IiAtIGFmdGVyIGFsbCB5b3UgX3dhbnRfIHRoZQo+IG1hY3JvIGFyZ3VtZW50IHRvIGJlIGV2YWx1
YXRlZCAoaW4gb3JkZXIgdG8gY2Fycnkgb3V0IHNpZGUgZWZmZWN0cykuCj4gCj4gPiAtLS0gYS94
ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCj4gPiArKysgYi94ZW4vaW5jbHVkZS94ZW4veG1hbGxv
Yy5oCj4gPiBAQCAtMTIzLDQgKzEyMywxMSBAQCB1bnNpZ25lZCBsb25nIHhtZW1fcG9vbF9nZXRf
dXNlZF9zaXplKHN0cnVjdCB4bWVtX3Bvb2wgCj4gPiAqcG9vbCk7Cj4gPiAgICovCj4gPiAgdW5z
aWduZWQgbG9uZyB4bWVtX3Bvb2xfZ2V0X3RvdGFsX3NpemUoc3RydWN0IHhtZW1fcG9vbCAqcG9v
bCk7Cj4gPiAgCj4gPiArI2lmbmRlZiBOREVCVUcKPiA+ICsjZGVmaW5lIHhtZW1fcG9vbF9jaGVj
aygpIF9feG1lbV9wb29sX2NoZWNrKF9fRklMRV9fLCBfX0xJTkVfXykKPiA+ICtpbnQgX194bWVt
X3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpOwo+ID4gKyNlbHNlCj4gPiAr
I2RlZmluZSB4bWVtX3Bvb2xfY2hlY2soKSBkbyB7IGlmICggMCApOyB9IHdoaWxlICgwKQo+IAo+
ICgodm9pZCkwKQo+IAo+IG9yCj4gCj4gZG8ge30gd2hpbGUgKDApCj4gCj4gQWxzbyBwZXJoYXBz
IF9feG1lbV9wb29sX2NoZWNrKCkgc2hvdWxkIGhhdmUgYSBwb29sIHBhcmFtZXRlciwKPiB3aXRo
IE5VTEwgbWVhbmluZyB0aGUgZGVmYXVsdCBvbmUuCj4gCgpUaGFuayB5b3UgZm9yIHlvdXIgcmV2
aWV3IEphbi4gSSdsbCBmb2xsb3cgdXAgd2l0aCBhbiB1cGRhdGUgc29vbiwgYXMKd2VsbCBhcyBh
IHBhdGNoIGZvciBfX3dhcm4oKSAoYW5kIF9fYnVnKCkgd2hpbGUgSSdtIGF0IGl0KS4KCi0tIApN
aWhhaSBET07ImlUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 00:20:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 00:20:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxm3F-0005ts-0M; Mon, 08 Dec 2014 00:19:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1Xxm3C-0005tl-UN
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 00:19:43 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	18/23-02702-E9EE4845; Mon, 08 Dec 2014 00:19:42 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417997980!13546769!1
X-Originating-IP: [91.199.104.161]
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 15886 invoked from network); 8 Dec 2014 00:19:41 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 00:19:41 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=gxixnG1uliIH1Ts506dlLTqNi1RIom2pKEiDjjPJssEvwo2Ah+wVXTWGv4pGb/4SPG/c/oRxLfjWkIqL3v0xU71T7nDsT8Ti8iwylDeFkTvD0I6kuqQot5U/MQXlHV0/msPxdAAGsOa+a/hT32dwu9w1Yxs4lF76xNHgrdkeD/b/495gzw4WVCMYWrgNxk1oUDq2LzCzpAehocGjYxu8vChore8GxtMHq8ik4AUz2LVm4cCingkEXNl3E0NjmJnluW3UH4Y7rLj1cPVMWB/wkyxXny5Wc+4KFhMdAOPZltGANw/jpKXs5HxrUwWOjePU6aNGW/pT66X3bCJzLAV4bw==;
	h=Received:Received:Received:Received:Received:From:To:Subject:Date:Message-Id:X-Mailer:MIME-Version: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=from:to
	:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=YaxTTVvORJ5kyv6jk5Mulq
	BExBk=; b=uSAwIwFw8kTSqXY1+UOmz3tVJB60EQmzkxGY/fS+m1QEasNFVUWclY
	RumE/yF/6TIkXO/+KJcbH0TLZkJV6L97Z8fEj5s7O7JRkrqSqswXhoyQl6JOS+cD
	SjVEpFWJFUFNoP2hI7eK/s2fijXD10euzYxR5iHsk28z2n83972FuTx7a+7WPQru
	AIzmpJSY8joy9j9m7Mpp0bVStCcvPpteT6t+xC4t45pVCj1eAdnoqf5tsF+kXHWl
	QMfJ1mRWjD5a4jg76uzHAK3+r/23dTIXHWYjMXgYpAEuEmlWhQ82uyHRCqi5qFst
	fY6Vg05FQYYf5LYB2bdXZLnYDcS0cOVw==
Received: (qmail 30460 invoked from network); 8 Dec 2014 02:19: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;
	8 Dec 2014 02:19:39 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id C95A380338
	for <xen-devel@lists.xenproject.org>;
	Mon,  8 Dec 2014 02:19:38 +0200 (EET)
Received: (qmail 27689 invoked from network); 8 Dec 2014 02:19:38 +0200
Received: from 5-12-114-134.residential.rdsnet.ro (HELO mdontu-l.dsd.ro)
	(mdontu@bitdefender.com@5.12.114.134)
	by smtp02.buh.bitdefender.net with SMTP; 8 Dec 2014 02:19:35 +0200
From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
To: xen-devel@lists.xenproject.org
Date: Mon,  8 Dec 2014 02:19:22 +0200
Message-Id: <1417997962-23853-1-git-send-email-mdontu@bitdefender.com>
X-Mailer: git-send-email 2.2.0
MIME-Version: 1.0
Content-Length: 2238
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.58171
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374349,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; 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: Error: onPost(20012)(400)], total: 0(775)
X-BitDefender-CF-Stamp: none
Subject: [Xen-devel] [PATCH] console: const-ify the arguments for __warn()
	and __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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Qm90aCBfX3dhcm4oKSBhbmQgX19idWcoKSB0YWtlIGFzIGZpcnN0IHBhcmFtZXRlciB0aGUgZmls
ZSBuYW1lIG9mIHRoZQpjdXJyZW50IGNvbXBpbGF0aW9uIHVuaXQgKF9fRklMRV9fKS4gTWFyayB0
aGF0IHBhcmFtZXRlciBhcyBjb25zdGFudCB0bwpiZXR0ZXIgcmVmbGVjdCB0aGF0LgoKU2lnbmVk
LW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0ZGVmZW5kZXIuY29tPgotLS0KIHhlbi9k
cml2ZXJzL2NoYXIvY29uc29sZS5jIHwgNCArKy0tCiB4ZW4vaW5jbHVkZS94ZW4vbGliLmggICAg
ICB8IDQgKystLQogMiBmaWxlcyBjaGFuZ2VkLCA0IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25z
KC0pCgpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvY2hhci9jb25zb2xlLmMgYi94ZW4vZHJpdmVy
cy9jaGFyL2NvbnNvbGUuYwppbmRleCAyZjAzMjU5Li43ODA3Y2YyIDEwMDY0NAotLS0gYS94ZW4v
ZHJpdmVycy9jaGFyL2NvbnNvbGUuYworKysgYi94ZW4vZHJpdmVycy9jaGFyL2NvbnNvbGUuYwpA
QCAtMTEzOCw3ICsxMTM4LDcgQEAgdm9pZCBwYW5pYyhjb25zdCBjaGFyICpmbXQsIC4uLikKICAg
ICAgICAgbWFjaGluZV9yZXN0YXJ0KDUwMDApOwogfQoKLXZvaWQgX19idWcoY2hhciAqZmlsZSwg
aW50IGxpbmUpCit2b2lkIF9fYnVnKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKQogewogICAg
IGNvbnNvbGVfc3RhcnRfc3luYygpOwogICAgIHByaW50aygiWGVuIEJVRyBhdCAlczolZFxuIiwg
ZmlsZSwgbGluZSk7CkBAIC0xMTQ2LDcgKzExNDYsNyBAQCB2b2lkIF9fYnVnKGNoYXIgKmZpbGUs
IGludCBsaW5lKQogICAgIHBhbmljKCJYZW4gQlVHIGF0ICVzOiVkIiwgZmlsZSwgbGluZSk7CiB9
Cgotdm9pZCBfX3dhcm4oY2hhciAqZmlsZSwgaW50IGxpbmUpCit2b2lkIF9fd2Fybihjb25zdCBj
aGFyICpmaWxlLCBpbnQgbGluZSkKIHsKICAgICBwcmludGsoIlhlbiBXQVJOIGF0ICVzOiVkXG4i
LCBmaWxlLCBsaW5lKTsKICAgICBkdW1wX2V4ZWN1dGlvbl9zdGF0ZSgpOwpkaWZmIC0tZ2l0IGEv
eGVuL2luY2x1ZGUveGVuL2xpYi5oIGIveGVuL2luY2x1ZGUveGVuL2xpYi5oCmluZGV4IGYxMWI0
OWUuLjhmOWNhZGIgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9saWIuaAorKysgYi94ZW4v
aW5jbHVkZS94ZW4vbGliLmgKQEAgLTgsOCArOCw4IEBACiAjaW5jbHVkZSA8eGVuL3N0cmluZy5o
PgogI2luY2x1ZGUgPGFzbS9idWcuaD4KCi12b2lkIG5vcmV0dXJuIF9fYnVnKGNoYXIgKmZpbGUs
IGludCBsaW5lKTsKLXZvaWQgX193YXJuKGNoYXIgKmZpbGUsIGludCBsaW5lKTsKK3ZvaWQgbm9y
ZXR1cm4gX19idWcoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpOwordm9pZCBfX3dhcm4oY29u
c3QgY2hhciAqZmlsZSwgaW50IGxpbmUpOwoKICNkZWZpbmUgQlVHX09OKHApICBkbyB7IGlmICh1
bmxpa2VseShwKSkgQlVHKCk7ICB9IHdoaWxlICgwKQogI2RlZmluZSBXQVJOX09OKHApIGRvIHsg
aWYgKHVubGlrZWx5KHApKSBXQVJOKCk7IH0gd2hpbGUgKDApCi0tCjIuMi4wCgoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 08 00:20:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 00:20:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxm3F-0005ts-0M; Mon, 08 Dec 2014 00:19:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1Xxm3C-0005tl-UN
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 00:19:43 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	18/23-02702-E9EE4845; Mon, 08 Dec 2014 00:19:42 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1417997980!13546769!1
X-Originating-IP: [91.199.104.161]
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 15886 invoked from network); 8 Dec 2014 00:19:41 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 00:19:41 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=gxixnG1uliIH1Ts506dlLTqNi1RIom2pKEiDjjPJssEvwo2Ah+wVXTWGv4pGb/4SPG/c/oRxLfjWkIqL3v0xU71T7nDsT8Ti8iwylDeFkTvD0I6kuqQot5U/MQXlHV0/msPxdAAGsOa+a/hT32dwu9w1Yxs4lF76xNHgrdkeD/b/495gzw4WVCMYWrgNxk1oUDq2LzCzpAehocGjYxu8vChore8GxtMHq8ik4AUz2LVm4cCingkEXNl3E0NjmJnluW3UH4Y7rLj1cPVMWB/wkyxXny5Wc+4KFhMdAOPZltGANw/jpKXs5HxrUwWOjePU6aNGW/pT66X3bCJzLAV4bw==;
	h=Received:Received:Received:Received:Received:From:To:Subject:Date:Message-Id:X-Mailer:MIME-Version: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=from:to
	:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=YaxTTVvORJ5kyv6jk5Mulq
	BExBk=; b=uSAwIwFw8kTSqXY1+UOmz3tVJB60EQmzkxGY/fS+m1QEasNFVUWclY
	RumE/yF/6TIkXO/+KJcbH0TLZkJV6L97Z8fEj5s7O7JRkrqSqswXhoyQl6JOS+cD
	SjVEpFWJFUFNoP2hI7eK/s2fijXD10euzYxR5iHsk28z2n83972FuTx7a+7WPQru
	AIzmpJSY8joy9j9m7Mpp0bVStCcvPpteT6t+xC4t45pVCj1eAdnoqf5tsF+kXHWl
	QMfJ1mRWjD5a4jg76uzHAK3+r/23dTIXHWYjMXgYpAEuEmlWhQ82uyHRCqi5qFst
	fY6Vg05FQYYf5LYB2bdXZLnYDcS0cOVw==
Received: (qmail 30460 invoked from network); 8 Dec 2014 02:19: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;
	8 Dec 2014 02:19:39 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id C95A380338
	for <xen-devel@lists.xenproject.org>;
	Mon,  8 Dec 2014 02:19:38 +0200 (EET)
Received: (qmail 27689 invoked from network); 8 Dec 2014 02:19:38 +0200
Received: from 5-12-114-134.residential.rdsnet.ro (HELO mdontu-l.dsd.ro)
	(mdontu@bitdefender.com@5.12.114.134)
	by smtp02.buh.bitdefender.net with SMTP; 8 Dec 2014 02:19:35 +0200
From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
To: xen-devel@lists.xenproject.org
Date: Mon,  8 Dec 2014 02:19:22 +0200
Message-Id: <1417997962-23853-1-git-send-email-mdontu@bitdefender.com>
X-Mailer: git-send-email 2.2.0
MIME-Version: 1.0
Content-Length: 2238
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.58171
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374349,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; 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: Error: onPost(20012)(400)], total: 0(775)
X-BitDefender-CF-Stamp: none
Subject: [Xen-devel] [PATCH] console: const-ify the arguments for __warn()
	and __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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Qm90aCBfX3dhcm4oKSBhbmQgX19idWcoKSB0YWtlIGFzIGZpcnN0IHBhcmFtZXRlciB0aGUgZmls
ZSBuYW1lIG9mIHRoZQpjdXJyZW50IGNvbXBpbGF0aW9uIHVuaXQgKF9fRklMRV9fKS4gTWFyayB0
aGF0IHBhcmFtZXRlciBhcyBjb25zdGFudCB0bwpiZXR0ZXIgcmVmbGVjdCB0aGF0LgoKU2lnbmVk
LW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0ZGVmZW5kZXIuY29tPgotLS0KIHhlbi9k
cml2ZXJzL2NoYXIvY29uc29sZS5jIHwgNCArKy0tCiB4ZW4vaW5jbHVkZS94ZW4vbGliLmggICAg
ICB8IDQgKystLQogMiBmaWxlcyBjaGFuZ2VkLCA0IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25z
KC0pCgpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvY2hhci9jb25zb2xlLmMgYi94ZW4vZHJpdmVy
cy9jaGFyL2NvbnNvbGUuYwppbmRleCAyZjAzMjU5Li43ODA3Y2YyIDEwMDY0NAotLS0gYS94ZW4v
ZHJpdmVycy9jaGFyL2NvbnNvbGUuYworKysgYi94ZW4vZHJpdmVycy9jaGFyL2NvbnNvbGUuYwpA
QCAtMTEzOCw3ICsxMTM4LDcgQEAgdm9pZCBwYW5pYyhjb25zdCBjaGFyICpmbXQsIC4uLikKICAg
ICAgICAgbWFjaGluZV9yZXN0YXJ0KDUwMDApOwogfQoKLXZvaWQgX19idWcoY2hhciAqZmlsZSwg
aW50IGxpbmUpCit2b2lkIF9fYnVnKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKQogewogICAg
IGNvbnNvbGVfc3RhcnRfc3luYygpOwogICAgIHByaW50aygiWGVuIEJVRyBhdCAlczolZFxuIiwg
ZmlsZSwgbGluZSk7CkBAIC0xMTQ2LDcgKzExNDYsNyBAQCB2b2lkIF9fYnVnKGNoYXIgKmZpbGUs
IGludCBsaW5lKQogICAgIHBhbmljKCJYZW4gQlVHIGF0ICVzOiVkIiwgZmlsZSwgbGluZSk7CiB9
Cgotdm9pZCBfX3dhcm4oY2hhciAqZmlsZSwgaW50IGxpbmUpCit2b2lkIF9fd2Fybihjb25zdCBj
aGFyICpmaWxlLCBpbnQgbGluZSkKIHsKICAgICBwcmludGsoIlhlbiBXQVJOIGF0ICVzOiVkXG4i
LCBmaWxlLCBsaW5lKTsKICAgICBkdW1wX2V4ZWN1dGlvbl9zdGF0ZSgpOwpkaWZmIC0tZ2l0IGEv
eGVuL2luY2x1ZGUveGVuL2xpYi5oIGIveGVuL2luY2x1ZGUveGVuL2xpYi5oCmluZGV4IGYxMWI0
OWUuLjhmOWNhZGIgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9saWIuaAorKysgYi94ZW4v
aW5jbHVkZS94ZW4vbGliLmgKQEAgLTgsOCArOCw4IEBACiAjaW5jbHVkZSA8eGVuL3N0cmluZy5o
PgogI2luY2x1ZGUgPGFzbS9idWcuaD4KCi12b2lkIG5vcmV0dXJuIF9fYnVnKGNoYXIgKmZpbGUs
IGludCBsaW5lKTsKLXZvaWQgX193YXJuKGNoYXIgKmZpbGUsIGludCBsaW5lKTsKK3ZvaWQgbm9y
ZXR1cm4gX19idWcoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpOwordm9pZCBfX3dhcm4oY29u
c3QgY2hhciAqZmlsZSwgaW50IGxpbmUpOwoKICNkZWZpbmUgQlVHX09OKHApICBkbyB7IGlmICh1
bmxpa2VseShwKSkgQlVHKCk7ICB9IHdoaWxlICgwKQogI2RlZmluZSBXQVJOX09OKHApIGRvIHsg
aWYgKHVubGlrZWx5KHApKSBXQVJOKCk7IH0gd2hpbGUgKDApCi0tCjIuMi4wCgoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 08 01:29:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 01: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 1Xxn8H-0003Fv-C3; Mon, 08 Dec 2014 01:29: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 1Xxn8F-0003Fq-Iq
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 01:28:59 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	3F/7F-19763-ADEF4845; Mon, 08 Dec 2014 01:28:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418002136!9142417!1
X-Originating-IP: [66.165.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 27691 invoked from network); 8 Dec 2014 01:28:57 -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;
	8 Dec 2014 01:28:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,535,1413244800"; d="scan'208";a="201204110"
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.210.2; Sun, 7 Dec 2014 20:28: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 1Xxn8A-0007BP-Mm;
	Mon, 08 Dec 2014 01:28:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xxn8A-0000ap-Fc;
	Mon, 08 Dec 2014 01:28:54 +0000
Date: Mon, 8 Dec 2014 01:28:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32129-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] 32129: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32129 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32129/

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 32106
 test-amd64-i386-xl-win7-amd64  3 host-install(3) broken in 32106 pass in 32129
 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken in 32106 pass in 32129

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-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail in 32106 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           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-qemut-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-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                         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 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 Dec 08 01:29:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 01: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 1Xxn8H-0003Fv-C3; Mon, 08 Dec 2014 01:29: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 1Xxn8F-0003Fq-Iq
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 01:28:59 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	3F/7F-19763-ADEF4845; Mon, 08 Dec 2014 01:28:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418002136!9142417!1
X-Originating-IP: [66.165.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 27691 invoked from network); 8 Dec 2014 01:28:57 -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;
	8 Dec 2014 01:28:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,535,1413244800"; d="scan'208";a="201204110"
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.210.2; Sun, 7 Dec 2014 20:28: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 1Xxn8A-0007BP-Mm;
	Mon, 08 Dec 2014 01:28:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xxn8A-0000ap-Fc;
	Mon, 08 Dec 2014 01:28:54 +0000
Date: Mon, 8 Dec 2014 01:28:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32129-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] 32129: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32129 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32129/

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 32106
 test-amd64-i386-xl-win7-amd64  3 host-install(3) broken in 32106 pass in 32129
 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken in 32106 pass in 32129

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-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail in 32106 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           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-qemut-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-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                         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 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 Dec 08 01:30:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 01:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxnA3-0003MS-Lh; Mon, 08 Dec 2014 01:30:51 +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 1XxnA2-0003ML-83
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 01:30:50 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6D/5C-25276-94FF4845; Mon, 08 Dec 2014 01:30:49 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418002244!13993118!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 8984 invoked from network); 8 Dec 2014 01:30:48 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-21.messagelabs.com with SMTP;
	8 Dec 2014 01:30:48 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 07 Dec 2014 17:30:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,535,1413270000"; d="scan'208";a="634177825"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by fmsmga001.fm.intel.com with ESMTP; 07 Dec 2014 17:30:38 -0800
Message-ID: <5484FF3E.5080604@intel.com>
Date: Mon, 08 Dec 2014 09:30: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.3.0
MIME-Version: 1.0
To: "Tian, Kevin" <kevin.tian@intel.com>, 
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, 
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Zhang, Yang Z" <yang.z.zhang@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610AB18@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610AB18@SHSMSX101.ccr.corp.intel.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/2 16:33, Tian, Kevin wrote:
>> From: Chen, Tiejun
>> Sent: Monday, December 01, 2014 5:24 PM
>>
>> This should be based on a new parameter globally, 'pci_rdmforce'.
>>
>> 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.
>
> since no one requires it, why bother adding it? better to just
> keep global option.

This originates from my preliminary thought. Here I hope we can extend 
this approach to enable this feature just for any specific device in 
hotplug case.

But yes, this definitely isn't mandatory now since we can take this in 
next step so I can remove this right now, and of course I assume there's 
no any objection from other guys.

>
>>
>> So this domctl provides an approach to control how to populate
>> reserved device memory by tools.
>>
>> Note we always post a message to user about this once we owns
>> RMRR.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---

[snip]

>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -90,6 +90,53 @@ 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;
>> +    uint32_t rdmforce = 0;
>> +
>> +    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].devfn = PCI_DEVFN(d_config->pcidevs[i].dev,
>> +
>> d_config->pcidevs[i].func);
>> +                pcidevs[i].bus = d_config->pcidevs[i].bus;
>> +                pcidevs[i].seg = d_config->pcidevs[i].domain;
>> +                pcidevs[i].flags = d_config->pcidevs[i].rdmforce &
>> +                                   PCI_DEV_RDM_CHECK;
>> +            }
>> +        }
>> +        else
>> +        {
>> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
>> +                               "Can't allocate for pcidevs.");
>> +            return -1;
>> +        }
>> +    }
>> +    rdmforce = libxl_defbool_val(d_config->b_info.rdmforce) ? 1 : 0;
>> +
>> +    /* Nothing to do. */
>> +    if ( !rdmforce && !d_config->num_pcidevs )
>> +        return 0;
>
> move check before creating pcidevs.
>

Okay,

@@ -99,40 +99,33 @@ int libxl__domain_device_setrdm(libxl__gc *gc,
      struct xen_guest_pcidev_info *pcidevs = NULL;
      uint32_t rdmforce = 0;

-    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].devfn = PCI_DEVFN(d_config->pcidevs[i].dev,
-                                             d_config->pcidevs[i].func);
-                pcidevs[i].bus = d_config->pcidevs[i].bus;
-                pcidevs[i].seg = d_config->pcidevs[i].domain;
-                pcidevs[i].flags = d_config->pcidevs[i].rdmforce &
-                                   PCI_DEV_RDM_CHECK;
-            }
-        }
-        else
-        {
-            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
-                               "Can't allocate for pcidevs.");
-            return -1;
-        }
-    }
      rdmforce = libxl_defbool_val(d_config->b_info.rdmforce) ? 1 : 0;
-
      /* Nothing to do. */
      if ( !rdmforce && !d_config->num_pcidevs )
          return 0;

+    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].devfn = PCI_DEVFN(d_config->pcidevs[i].dev,
+                                         d_config->pcidevs[i].func);
+            pcidevs[i].bus = d_config->pcidevs[i].bus;
+            pcidevs[i].seg = d_config->pcidevs[i].domain;
+        }
+    }
+    else
+    {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Can't allocate for pcidevs.");
+        return -1;
+    }
+
      ret = xc_domain_device_setrdm(ctx->xch, dm_domid,
                                    (uint32_t)d_config->num_pcidevs,
-                                  rdmforce,
+                                  rdmforce & PCI_DEV_RDM_CHECK,
                                    pcidevs);
-    if ( d_config->num_pcidevs )
-        free(pcidevs);
+    free(pcidevs);

      return ret;
  }


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 Dec 08 01:30:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 01:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxnA3-0003MS-Lh; Mon, 08 Dec 2014 01:30:51 +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 1XxnA2-0003ML-83
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 01:30:50 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6D/5C-25276-94FF4845; Mon, 08 Dec 2014 01:30:49 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418002244!13993118!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 8984 invoked from network); 8 Dec 2014 01:30:48 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-21.messagelabs.com with SMTP;
	8 Dec 2014 01:30:48 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 07 Dec 2014 17:30:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,535,1413270000"; d="scan'208";a="634177825"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by fmsmga001.fm.intel.com with ESMTP; 07 Dec 2014 17:30:38 -0800
Message-ID: <5484FF3E.5080604@intel.com>
Date: Mon, 08 Dec 2014 09:30: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.3.0
MIME-Version: 1.0
To: "Tian, Kevin" <kevin.tian@intel.com>, 
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, 
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Zhang, Yang Z" <yang.z.zhang@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610AB18@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610AB18@SHSMSX101.ccr.corp.intel.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/2 16:33, Tian, Kevin wrote:
>> From: Chen, Tiejun
>> Sent: Monday, December 01, 2014 5:24 PM
>>
>> This should be based on a new parameter globally, 'pci_rdmforce'.
>>
>> 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.
>
> since no one requires it, why bother adding it? better to just
> keep global option.

This originates from my preliminary thought. Here I hope we can extend 
this approach to enable this feature just for any specific device in 
hotplug case.

But yes, this definitely isn't mandatory now since we can take this in 
next step so I can remove this right now, and of course I assume there's 
no any objection from other guys.

>
>>
>> So this domctl provides an approach to control how to populate
>> reserved device memory by tools.
>>
>> Note we always post a message to user about this once we owns
>> RMRR.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---

[snip]

>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -90,6 +90,53 @@ 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;
>> +    uint32_t rdmforce = 0;
>> +
>> +    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].devfn = PCI_DEVFN(d_config->pcidevs[i].dev,
>> +
>> d_config->pcidevs[i].func);
>> +                pcidevs[i].bus = d_config->pcidevs[i].bus;
>> +                pcidevs[i].seg = d_config->pcidevs[i].domain;
>> +                pcidevs[i].flags = d_config->pcidevs[i].rdmforce &
>> +                                   PCI_DEV_RDM_CHECK;
>> +            }
>> +        }
>> +        else
>> +        {
>> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
>> +                               "Can't allocate for pcidevs.");
>> +            return -1;
>> +        }
>> +    }
>> +    rdmforce = libxl_defbool_val(d_config->b_info.rdmforce) ? 1 : 0;
>> +
>> +    /* Nothing to do. */
>> +    if ( !rdmforce && !d_config->num_pcidevs )
>> +        return 0;
>
> move check before creating pcidevs.
>

Okay,

@@ -99,40 +99,33 @@ int libxl__domain_device_setrdm(libxl__gc *gc,
      struct xen_guest_pcidev_info *pcidevs = NULL;
      uint32_t rdmforce = 0;

-    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].devfn = PCI_DEVFN(d_config->pcidevs[i].dev,
-                                             d_config->pcidevs[i].func);
-                pcidevs[i].bus = d_config->pcidevs[i].bus;
-                pcidevs[i].seg = d_config->pcidevs[i].domain;
-                pcidevs[i].flags = d_config->pcidevs[i].rdmforce &
-                                   PCI_DEV_RDM_CHECK;
-            }
-        }
-        else
-        {
-            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
-                               "Can't allocate for pcidevs.");
-            return -1;
-        }
-    }
      rdmforce = libxl_defbool_val(d_config->b_info.rdmforce) ? 1 : 0;
-
      /* Nothing to do. */
      if ( !rdmforce && !d_config->num_pcidevs )
          return 0;

+    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].devfn = PCI_DEVFN(d_config->pcidevs[i].dev,
+                                         d_config->pcidevs[i].func);
+            pcidevs[i].bus = d_config->pcidevs[i].bus;
+            pcidevs[i].seg = d_config->pcidevs[i].domain;
+        }
+    }
+    else
+    {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Can't allocate for pcidevs.");
+        return -1;
+    }
+
      ret = xc_domain_device_setrdm(ctx->xch, dm_domid,
                                    (uint32_t)d_config->num_pcidevs,
-                                  rdmforce,
+                                  rdmforce & PCI_DEV_RDM_CHECK,
                                    pcidevs);
-    if ( d_config->num_pcidevs )
-        free(pcidevs);
+    free(pcidevs);

      return ret;
  }


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 Dec 08 02:12:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 02: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 1XxnoD-000563-Ae; Mon, 08 Dec 2014 02:12:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1XxnoC-00055y-43
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 02:12:20 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	5A/D9-22777-30905845; Mon, 08 Dec 2014 02:12:19 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418004737!12022917!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 5558 invoked from network); 8 Dec 2014 02:12:18 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-206.messagelabs.com with SMTP;
	8 Dec 2014 02:12:18 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 07 Dec 2014 18:12:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,535,1413270000"; d="scan'208";a="643977820"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by fmsmga002.fm.intel.com with ESMTP; 07 Dec 2014 18:12:14 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 8 Dec 2014 10:11:51 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id
	14.03.0195.001; Mon, 8 Dec 2014 10:11:51 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [v4] libxc: Expose the 1GB pages cpuid flag to guest
Thread-Index: AQHQDz6aHN6mmrBrwkaQMp5zyWZGe5x+qWJggAAKFoCABkKjIA==
Date: Mon, 8 Dec 2014 02:11:51 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABFC398@SHSMSX104.ccr.corp.intel.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
	<1417175443.23604.18.camel@citrix.com>
	<20141202210941.GA1593@laptop.dumpdata.com>
	<1417599529.29004.16.camel@citrix.com>
	<20141203155744.GE3081@laptop.dumpdata.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABF82AB@SHSMSX104.ccr.corp.intel.com>
	<5480359B.1030609@citrix.com>
In-Reply-To: <5480359B.1030609@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>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Li, Liang Z" <liang.z.li@intel.com>,
	"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>
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

Andrew Cooper wrote on 2014-12-04:
> On 04/12/14 01:50, Zhang, Yang Z wrote:
>> Konrad Rzeszutek Wilk wrote on 2014-12-03:
>>> On Wed, Dec 03, 2014 at 09:38:49AM +0000, Ian Campbell wrote:
>>>> On Tue, 2014-12-02 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
>>>>> On Fri, Nov 28, 2014 at 11:50:43AM +0000, Ian Campbell wrote:
>>>>>> 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...
>>>>> Jan acked it.
>>>> For 4.5? Probably not. Have you release acked it? No. This seemed
>>>> like 4.6 material to me, or at least I've not seen any
>>>> mention/argument to the contrary.
>>> Correct. 4.6 please.
>> I think this more like a bug fixing than a feature. See our previous discussion.
> 
> It is allowing HVM guests to use a brand new hardware feature which
> was previously unavailable to them.

Actually, we have regular test case to cover 1G page size which exposing the 1G feature manually through config file. And we also have a bug to track this issue. So it more likes a bugfix to me. But you are right. It is a new feature from guest's point.

> 
> It is absolutely not a bugfix, and not appropriate for 4.5 at this
> point, but a good candidate for acceptance as soon as the 4.6 dev window opens.

Agree.

> 
> ~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 Mon Dec 08 02:12:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 02: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 1XxnoD-000563-Ae; Mon, 08 Dec 2014 02:12:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1XxnoC-00055y-43
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 02:12:20 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	5A/D9-22777-30905845; Mon, 08 Dec 2014 02:12:19 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418004737!12022917!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 5558 invoked from network); 8 Dec 2014 02:12:18 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-206.messagelabs.com with SMTP;
	8 Dec 2014 02:12:18 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 07 Dec 2014 18:12:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,535,1413270000"; d="scan'208";a="643977820"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by fmsmga002.fm.intel.com with ESMTP; 07 Dec 2014 18:12:14 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 8 Dec 2014 10:11:51 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by
	SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id
	14.03.0195.001; Mon, 8 Dec 2014 10:11:51 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [v4] libxc: Expose the 1GB pages cpuid flag to guest
Thread-Index: AQHQDz6aHN6mmrBrwkaQMp5zyWZGe5x+qWJggAAKFoCABkKjIA==
Date: Mon, 8 Dec 2014 02:11:51 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0ABFC398@SHSMSX104.ccr.corp.intel.com>
References: <1417171925-10102-1-git-send-email-liang.z.li@intel.com>
	<1417175443.23604.18.camel@citrix.com>
	<20141202210941.GA1593@laptop.dumpdata.com>
	<1417599529.29004.16.camel@citrix.com>
	<20141203155744.GE3081@laptop.dumpdata.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0ABF82AB@SHSMSX104.ccr.corp.intel.com>
	<5480359B.1030609@citrix.com>
In-Reply-To: <5480359B.1030609@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>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Li, Liang Z" <liang.z.li@intel.com>,
	"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>
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

Andrew Cooper wrote on 2014-12-04:
> On 04/12/14 01:50, Zhang, Yang Z wrote:
>> Konrad Rzeszutek Wilk wrote on 2014-12-03:
>>> On Wed, Dec 03, 2014 at 09:38:49AM +0000, Ian Campbell wrote:
>>>> On Tue, 2014-12-02 at 16:09 -0500, Konrad Rzeszutek Wilk wrote:
>>>>> On Fri, Nov 28, 2014 at 11:50:43AM +0000, Ian Campbell wrote:
>>>>>> 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...
>>>>> Jan acked it.
>>>> For 4.5? Probably not. Have you release acked it? No. This seemed
>>>> like 4.6 material to me, or at least I've not seen any
>>>> mention/argument to the contrary.
>>> Correct. 4.6 please.
>> I think this more like a bug fixing than a feature. See our previous discussion.
> 
> It is allowing HVM guests to use a brand new hardware feature which
> was previously unavailable to them.

Actually, we have regular test case to cover 1G page size which exposing the 1G feature manually through config file. And we also have a bug to track this issue. So it more likes a bugfix to me. But you are right. It is a new feature from guest's point.

> 
> It is absolutely not a bugfix, and not appropriate for 4.5 at this
> point, but a good candidate for acceptance as soon as the 4.6 dev window opens.

Agree.

> 
> ~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 Mon Dec 08 02:31:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 02: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 1Xxo6S-0005TA-7e; Mon, 08 Dec 2014 02:31:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1Xxo6Q-0005T5-5E
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 02:31:10 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	DC/DF-15461-D6D05845; Mon, 08 Dec 2014 02:31:09 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418005867!6725684!1
X-Originating-IP: [91.199.104.161]
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 28313 invoked from network); 8 Dec 2014 02:31:08 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 02:31:08 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=OmSLVIOVj3z3t1NBjLhtiCkMoEdJZERw55V/J5qttaLxdBhrqjTuWangjOmS90BugUor370NlF6IHpTvbt3yVZR4oTpWce0UautuacBa5cU7hMKgVj0f3vlJKQJ4rdWGYm++i56d+pq7SjdgmPKaG9pYn6BSOZ5Q6YuQXCa4L9yxE/+CW3C1ctofEUy8NnDhr4I2q68YiBwQq3Sn8jLDarudP57PEBMlPJSzBQDg55m+gAlOc8RyVG8N6JCpVCANeBuKGnPtZJZLvXN77no2Rzrvl1VgpKUSQxcZ/vdcVmI8CGxcXJg89TfUy8KTNxJPMHnbD4b6IgAOcwlHDO75rA==;
	h=Received:Received:Received:Received:Received:From:To:Subject:Date:Message-Id:X-Mailer:MIME-Version: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=from:to
	:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=413yeDXm4CTLOKDbqEHNRB
	ymXUk=; b=A5dR3oh6kqwQ09bxAp/bv95phvZGbuwZLkIFeunUkoKGowENW0TP+t
	l8ObviImjojlWmUFWBNcmP7PbsSvaFTQn38lbIO6taMWGUoE8+NeKT0HFxYAEfLN
	GU29yBaz1o6V5pZvaqK3M8aPgbGZyb+oa6+WBwX1wv6FpDWj3w1YKpd+q7hDqVSn
	SyvU0nAXFBiLleFAHuKMv5gBDG3DFLTA3o2/k5WqgD4C7iRTM8zsqb9Sj1NNL/Gr
	wF6tQmPFryGxpavunI6h4LfbcrKrwuZIPop+awI+m9ExKqXgE+lvLT01wvcApxVa
	OMbRH+SiB3JSnzBGqiFkJk2/u+E/6H5g==
Received: (qmail 17731 invoked from network); 8 Dec 2014 04:31:07 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	8 Dec 2014 04:31:07 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 2FE9480304
	for <xen-devel@lists.xenproject.org>;
	Mon,  8 Dec 2014 04:31:06 +0200 (EET)
Received: (qmail 28819 invoked from network); 8 Dec 2014 04:31:06 +0200
Received: from 5-12-114-134.residential.rdsnet.ro (HELO mdontu-l.dsd.ro)
	(mdontu@bitdefender.com@5.12.114.134)
	by smtp02.buh.bitdefender.net with SMTP; 8 Dec 2014 04:31:03 +0200
From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
To: xen-devel@lists.xenproject.org
Date: Mon,  8 Dec 2014 04:30:48 +0200
Message-Id: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
X-Mailer: git-send-email 2.2.0
MIME-Version: 1.0
Content-Length: 8316
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.58171
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374350,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; 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: Error: onPost(20012)(400)], total: 0(775)
X-BitDefender-CF-Stamp: none
Subject: [Xen-devel] [PATCH v2] xmalloc: add support for checking the pool
	integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SW1wbGVtZW50ZWQgeG1lbV9wb29sX2NoZWNrKCksIHhtZW1fcG9vbF9jaGVja19sb2NrZWQoKSBh
bmQKeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKCkgdG8gdmVyaXR5IHRoZSBpbnRlZ3JpdHkgb2Yg
dGhlIFRMU0YgbWF0cml4LgoKU2lnbmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0
ZGVmZW5kZXIuY29tPgoKLS0tCkNoYW5nZXMgc2luY2UgdjE6CiAtIGZpeGVkIHRoZSBjb2Rpbmdz
dHlsZQogLSBzd2FwZWQgX2xvY2tlZC9fdW5sb2NrZWQgbmFtaW5nCiAtIHJld29ya2VkIF9feG1l
bV9wb29sX2NoZWNrX2xvY2tlZCgpIGEgYml0CiAtIHVzZWQgYm9vbF90IHdoZXJlIGFwcHJvcHJp
YXRlCiAtIG1hZGUgeG1lbV9wb29sX2NoZWNrKCkgdGFrZSBhIHBvb2wgYXJndW1lbnQgd2hpY2gg
Y2FuIGJlIE5VTEwKLS0tCiB4ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jIHwgMTEwICsrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0KIHhlbi9pbmNsdWRlL3hlbi94
bWFsbG9jLmggfCAgIDcgKysrCiAyIGZpbGVzIGNoYW5nZWQsIDExNSBpbnNlcnRpb25zKCspLCAy
IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMgYi94
ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jCmluZGV4IGE1NzY5YzkuLjg2ODExODUgMTAwNjQ0Ci0t
LSBhL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMKKysrIGIveGVuL2NvbW1vbi94bWFsbG9jX3Rs
c2YuYwpAQCAtMTIwLDkgKzEyMCwxMTEgQEAgc3RydWN0IHhtZW1fcG9vbCB7CiAgICAgY2hhciBu
YW1lW01BWF9QT09MX05BTUVfTEVOXTsKIH07Cgorc3RhdGljIHN0cnVjdCB4bWVtX3Bvb2wgKnhl
bnBvb2w7CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBNQVBQSU5HX0lOU0VSVCh1bnNpZ25lZCBsb25n
IHIsIGludCAqZmwsIGludCAqc2wpOworCiAvKgogICogSGVscGluZyBmdW5jdGlvbnMKICAqLwor
I2lmbmRlZiBOREVCVUcKK3N0YXRpYyBib29sX3QgeG1lbV9wb29sX2NoZWNrX3NpemUoY29uc3Qg
c3RydWN0IGJoZHIgKmIsIGludCBmbCwgaW50IHNsKQoreworICAgIHdoaWxlICggYiApCisgICAg
eworICAgICAgICBpbnQgX19mbDsKKyAgICAgICAgaW50IF9fc2w7CisKKyAgICAgICAgTUFQUElO
R19JTlNFUlQoYi0+c2l6ZSwgJl9fZmwsICZfX3NsKTsKKyAgICAgICAgaWYgKCBfX2ZsICE9IGZs
IHx8IF9fc2wgIT0gc2wgKQorICAgICAgICB7CisgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VS
UiAieG1lbV9wb29sOiBmb3IgYmxvY2sgJXAgc2l6ZSA9ICV1LCB7IGZsID0gJWQsIHNsID0gJWQg
fSBzaG91bGQgYmUgeyBmbCA9ICVkLCBzbCA9ICVkIH1cbiIsCisgICAgICAgICAgICAgICAgICAg
YiwgYi0+c2l6ZSwgZmwsIHNsLCBfX2ZsLCBfX3NsKTsKKyAgICAgICAgICAgIHJldHVybiAwOwor
ICAgICAgICB9CisgICAgICAgIGIgPSBiLT5wdHIuZnJlZV9wdHIubmV4dDsKKyAgICB9CisgICAg
cmV0dXJuIDE7Cit9CisKKy8qCisgKiBUaGlzIGZ1bmN0aW9uIG11c3QgYmUgY2FsbGVkIGZyb20g
YSBjb250ZXh0IHdoZXJlIHBvb2wtPmxvY2sgaXMKKyAqIGFscmVhZHkgYWNxdWlyZWQuCisgKgor
ICogUmV0dXJucyB0cnVlIGlmIHRoZSBwb29sIGhhcyBiZWVuIGNvcnJ1cHRlZCwgZmFsc2Ugb3Ro
ZXJ3aXNlCisgKi8KKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKSBfX3htZW1f
cG9vbF9jaGVja19sb2NrZWQoX19GSUxFX18sIF9fTElORV9fLCBwb29sKQorc3RhdGljIGJvb2xf
dCBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsIGNv
bnN0IHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCit7CisgICAgaW50IGk7CisgICAgc3RhdGljIGJv
b2xfdCBvbmNlID0gMTsKKworICAgIGlmICggIW9uY2UgKQorICAgICAgICBnb3RvIG91dDsKKyAg
ICBmb3IgKCBpID0gMDsgaSA8IFJFQUxfRkxJOyBpKysgKQorICAgIHsKKyAgICAgICAgaW50IGZs
ID0gKHBvb2wtPmZsX2JpdG1hcCAmICgxIDw8IGkpKSA/IGkgOiAtMTsKKworICAgICAgICBpZiAo
IGZsID49IDAgKQorICAgICAgICB7CisgICAgICAgICAgICBpbnQgajsKKworICAgICAgICAgICAg
aWYgKCAhcG9vbC0+c2xfYml0bWFwW2ZsXSApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAg
ICAgcHJpbnRrKFhFTkxPR19FUlIgInhtZW1fcG9vbDogdGhlIFRMU0YgYml0bWFwIGlzIGNvcnJ1
cHRlZCAobm9uLWVtcHR5IEZMIHdpdGggZW1wdHkgU0wpXG4iKTsKKyAgICAgICAgICAgICAgICBf
X3dhcm4oZmlsZSwgbGluZSk7CisgICAgICAgICAgICAgICAgb25jZSA9IDA7CisgICAgICAgICAg
ICAgICAgYnJlYWs7CisgICAgICAgICAgICB9CisgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8
IE1BWF9TTEk7IGorKyApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgaW50IHNsID0g
KHBvb2wtPnNsX2JpdG1hcFtmbF0gJiAoMSA8PCBqKSkgPyBqIDogLTE7CisKKyAgICAgICAgICAg
ICAgICBpZiAoIHNsIDwgMCApCisgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOworICAgICAg
ICAgICAgICAgIGlmICggIXBvb2wtPm1hdHJpeFtmbF1bc2xdICkKKyAgICAgICAgICAgICAgICB7
CisgICAgICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4bWVtX3Bvb2w6IHRoZSBU
TFNGIGJpdG1hcCBpcyBjb3JydXB0ZWQgKG1hdHJpeFslZF1bJWRdIGlzIE5VTEwpXG4iLAorICAg
ICAgICAgICAgICAgICAgICAgICAgZmwsIHNsKTsKKyAgICAgICAgICAgICAgICAgICAgX193YXJu
KGZpbGUsIGxpbmUpOworICAgICAgICAgICAgICAgICAgICBvbmNlID0gMDsKKyAgICAgICAgICAg
ICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICAgICAgfQorICAgICAgICAgICAgICAgIGlmICgg
IXhtZW1fcG9vbF9jaGVja19zaXplKHBvb2wtPm1hdHJpeFtmbF1bc2xdLCBmbCwgc2wpICkKKyAg
ICAgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4
bWVtX3Bvb2w6IHRoZSBUTFNGIGNodW5rIG1hdHJpeCBpcyBjb3JydXB0ZWRcbiIpOworICAgICAg
ICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGluZSk7CisgICAgICAgICAgICAgICAgICAgIG9u
Y2UgPSAwOworICAgICAgICAgICAgICAgICAgICBicmVhazsKKyAgICAgICAgICAgICAgICB9Cisg
ICAgICAgICAgICB9CisgICAgICAgICAgICBpZiAoICFvbmNlICkKKyAgICAgICAgICAgICAgICBi
cmVhazsKKyAgICAgICAgfQorICAgIH0KK291dDoKKyAgICByZXR1cm4gIW9uY2U7Cit9CisKKyNk
ZWZpbmUgeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKHBvb2wpIF9feG1lbV9wb29sX2NoZWNrX3Vu
bG9ja2VkKF9fRklMRV9fLCBfX0xJTkVfXywgcG9vbCkKK3N0YXRpYyBib29sX3QgX194bWVtX3Bv
b2xfY2hlY2tfdW5sb2NrZWQoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsIHN0cnVjdCB4bWVt
X3Bvb2wgKnBvb2wpCit7CisgICAgYm9vbF90IG9vcHM7CisKKyAgICBzcGluX2xvY2soJnBvb2wt
PmxvY2spOworICAgIG9vcHMgPSBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoZmlsZSwgbGluZSwg
cG9vbCk7CisgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOworICAgIHJldHVybiBvb3BzOwor
fQorCitib29sX3QgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUs
IHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCit7CisgICAgcmV0dXJuIF9feG1lbV9wb29sX2NoZWNr
X3VubG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wgPyBwb29sIDogeGVucG9vbCk7Cit9CisjZWxzZQor
I2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpICgodm9pZCkocG9vbCkpCisjZGVm
aW5lIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChwb29sKSAoKHZvaWQpKHBvb2wpKQorI2VuZGlm
CgogLyoqCiAgKiBSZXR1cm5zIGluZGV4ZXMgKGZsLCBzbCkgb2YgdGhlIGxpc3QgdXNlZCB0byBz
ZXJ2ZSByZXF1ZXN0IG9mIHNpemUgcgpAQCAtMzgxLDYgKzQ4Myw4IEBAIHZvaWQgKnhtZW1fcG9v
bF9hbGxvYyh1bnNpZ25lZCBsb25nIHNpemUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCiAgICAg
aW50IGZsLCBzbDsKICAgICB1bnNpZ25lZCBsb25nIHRtcF9zaXplOwoKKyAgICB4bWVtX3Bvb2xf
Y2hlY2tfdW5sb2NrZWQocG9vbCk7CisKICAgICBpZiAoIHBvb2wtPmluaXRfcmVnaW9uID09IE5V
TEwgKQogICAgIHsKICAgICAgICAgaWYgKCAocmVnaW9uID0gcG9vbC0+Z2V0X21lbShwb29sLT5p
bml0X3NpemUpKSA9PSBOVUxMICkKQEAgLTQ0MiwxMSArNTQ2LDEzIEBAIHZvaWQgKnhtZW1fcG9v
bF9hbGxvYyh1bnNpZ25lZCBsb25nIHNpemUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCgogICAg
IHBvb2wtPnVzZWRfc2l6ZSArPSAoYi0+c2l6ZSAmIEJMT0NLX1NJWkVfTUFTSykgKyBCSERSX09W
RVJIRUFEOwoKKyAgICB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpOwogICAgIHNwaW5fdW5s
b2NrKCZwb29sLT5sb2NrKTsKICAgICByZXR1cm4gKHZvaWQgKiliLT5wdHIuYnVmZmVyOwoKICAg
ICAvKiBGYWlsZWQgYWxsb2MgKi8KICBvdXRfbG9ja2VkOgorICAgIHhtZW1fcG9vbF9jaGVja19s
b2NrZWQocG9vbCk7CiAgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwoKICBvdXQ6CkBAIC00
NjQsNiArNTcwLDcgQEAgdm9pZCB4bWVtX3Bvb2xfZnJlZSh2b2lkICpwdHIsIHN0cnVjdCB4bWVt
X3Bvb2wgKnBvb2wpCiAgICAgYiA9IChzdHJ1Y3QgYmhkciAqKSgoY2hhciAqKSBwdHIgLSBCSERS
X09WRVJIRUFEKTsKCiAgICAgc3Bpbl9sb2NrKCZwb29sLT5sb2NrKTsKKyAgICB4bWVtX3Bvb2xf
Y2hlY2tfbG9ja2VkKHBvb2wpOwogICAgIGItPnNpemUgfD0gRlJFRV9CTE9DSzsKICAgICBwb29s
LT51c2VkX3NpemUgLT0gKGItPnNpemUgJiBCTE9DS19TSVpFX01BU0spICsgQkhEUl9PVkVSSEVB
RDsKICAgICBiLT5wdHIuZnJlZV9wdHIgPSAoc3RydWN0IGZyZWVfcHRyKSB7IE5VTEwsIE5VTEx9
OwpAQCAtNTAwLDYgKzYwNyw3IEBAIHZvaWQgeG1lbV9wb29sX2ZyZWUodm9pZCAqcHRyLCBzdHJ1
Y3QgeG1lbV9wb29sICpwb29sKQogICAgIHRtcF9iLT5zaXplIHw9IFBSRVZfRlJFRTsKICAgICB0
bXBfYi0+cHJldl9oZHIgPSBiOwogIG91dDoKKyAgICB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBv
b2wpOwogICAgIHNwaW5fdW5sb2NrKCZwb29sLT5sb2NrKTsKIH0KCkBAIC01MTIsOCArNjIwLDYg
QEAgaW50IHhtZW1fcG9vbF9tYXhhbGxvYyhzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQogICogR2x1
ZSBmb3IgeG1hbGxvYygpLgogICovCgotc3RhdGljIHN0cnVjdCB4bWVtX3Bvb2wgKnhlbnBvb2w7
Ci0KIHN0YXRpYyB2b2lkICp4bWFsbG9jX3Bvb2xfZ2V0KHVuc2lnbmVkIGxvbmcgc2l6ZSkKIHsK
ICAgICBBU1NFUlQoc2l6ZSA9PSBQQUdFX1NJWkUpOwpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv
eGVuL3htYWxsb2MuaCBiL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKaW5kZXggMjRhOTlhYy4u
YWQ0ODkzMCAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaAorKysgYi94ZW4v
aW5jbHVkZS94ZW4veG1hbGxvYy5oCkBAIC0xMjMsNCArMTIzLDExIEBAIHVuc2lnbmVkIGxvbmcg
eG1lbV9wb29sX2dldF91c2VkX3NpemUoc3RydWN0IHhtZW1fcG9vbCAqcG9vbCk7CiAgKi8KIHVu
c2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF90b3RhbF9zaXplKHN0cnVjdCB4bWVtX3Bvb2wgKnBv
b2wpOwoKKyNpZm5kZWYgTkRFQlVHCisjZGVmaW5lIHhtZW1fcG9vbF9jaGVjayhwb29sKSBfX3ht
ZW1fcG9vbF9jaGVjayhfX0ZJTEVfXywgX19MSU5FX18sIHBvb2wpCitib29sX3QgX194bWVtX3Bv
b2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBv
b2wpOworI2Vsc2UKKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrKHBvb2wpICgodm9pZCkwKQorI2Vu
ZGlmCisKICNlbmRpZiAvKiBfX1hNQUxMT0NfSF9fICovCi0tCjIuMi4wCgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 08 02:31:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 02: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 1Xxo6S-0005TA-7e; Mon, 08 Dec 2014 02:31:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1Xxo6Q-0005T5-5E
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 02:31:10 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	DC/DF-15461-D6D05845; Mon, 08 Dec 2014 02:31:09 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418005867!6725684!1
X-Originating-IP: [91.199.104.161]
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 28313 invoked from network); 8 Dec 2014 02:31:08 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 02:31:08 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=OmSLVIOVj3z3t1NBjLhtiCkMoEdJZERw55V/J5qttaLxdBhrqjTuWangjOmS90BugUor370NlF6IHpTvbt3yVZR4oTpWce0UautuacBa5cU7hMKgVj0f3vlJKQJ4rdWGYm++i56d+pq7SjdgmPKaG9pYn6BSOZ5Q6YuQXCa4L9yxE/+CW3C1ctofEUy8NnDhr4I2q68YiBwQq3Sn8jLDarudP57PEBMlPJSzBQDg55m+gAlOc8RyVG8N6JCpVCANeBuKGnPtZJZLvXN77no2Rzrvl1VgpKUSQxcZ/vdcVmI8CGxcXJg89TfUy8KTNxJPMHnbD4b6IgAOcwlHDO75rA==;
	h=Received:Received:Received:Received:Received:From:To:Subject:Date:Message-Id:X-Mailer:MIME-Version: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=from:to
	:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=413yeDXm4CTLOKDbqEHNRB
	ymXUk=; b=A5dR3oh6kqwQ09bxAp/bv95phvZGbuwZLkIFeunUkoKGowENW0TP+t
	l8ObviImjojlWmUFWBNcmP7PbsSvaFTQn38lbIO6taMWGUoE8+NeKT0HFxYAEfLN
	GU29yBaz1o6V5pZvaqK3M8aPgbGZyb+oa6+WBwX1wv6FpDWj3w1YKpd+q7hDqVSn
	SyvU0nAXFBiLleFAHuKMv5gBDG3DFLTA3o2/k5WqgD4C7iRTM8zsqb9Sj1NNL/Gr
	wF6tQmPFryGxpavunI6h4LfbcrKrwuZIPop+awI+m9ExKqXgE+lvLT01wvcApxVa
	OMbRH+SiB3JSnzBGqiFkJk2/u+E/6H5g==
Received: (qmail 17731 invoked from network); 8 Dec 2014 04:31:07 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	8 Dec 2014 04:31:07 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 2FE9480304
	for <xen-devel@lists.xenproject.org>;
	Mon,  8 Dec 2014 04:31:06 +0200 (EET)
Received: (qmail 28819 invoked from network); 8 Dec 2014 04:31:06 +0200
Received: from 5-12-114-134.residential.rdsnet.ro (HELO mdontu-l.dsd.ro)
	(mdontu@bitdefender.com@5.12.114.134)
	by smtp02.buh.bitdefender.net with SMTP; 8 Dec 2014 04:31:03 +0200
From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
To: xen-devel@lists.xenproject.org
Date: Mon,  8 Dec 2014 04:30:48 +0200
Message-Id: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
X-Mailer: git-send-email 2.2.0
MIME-Version: 1.0
Content-Length: 8316
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.58171
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374350,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; 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: Error: onPost(20012)(400)], total: 0(775)
X-BitDefender-CF-Stamp: none
Subject: [Xen-devel] [PATCH v2] xmalloc: add support for checking the pool
	integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SW1wbGVtZW50ZWQgeG1lbV9wb29sX2NoZWNrKCksIHhtZW1fcG9vbF9jaGVja19sb2NrZWQoKSBh
bmQKeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKCkgdG8gdmVyaXR5IHRoZSBpbnRlZ3JpdHkgb2Yg
dGhlIFRMU0YgbWF0cml4LgoKU2lnbmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0
ZGVmZW5kZXIuY29tPgoKLS0tCkNoYW5nZXMgc2luY2UgdjE6CiAtIGZpeGVkIHRoZSBjb2Rpbmdz
dHlsZQogLSBzd2FwZWQgX2xvY2tlZC9fdW5sb2NrZWQgbmFtaW5nCiAtIHJld29ya2VkIF9feG1l
bV9wb29sX2NoZWNrX2xvY2tlZCgpIGEgYml0CiAtIHVzZWQgYm9vbF90IHdoZXJlIGFwcHJvcHJp
YXRlCiAtIG1hZGUgeG1lbV9wb29sX2NoZWNrKCkgdGFrZSBhIHBvb2wgYXJndW1lbnQgd2hpY2gg
Y2FuIGJlIE5VTEwKLS0tCiB4ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jIHwgMTEwICsrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0KIHhlbi9pbmNsdWRlL3hlbi94
bWFsbG9jLmggfCAgIDcgKysrCiAyIGZpbGVzIGNoYW5nZWQsIDExNSBpbnNlcnRpb25zKCspLCAy
IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMgYi94
ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jCmluZGV4IGE1NzY5YzkuLjg2ODExODUgMTAwNjQ0Ci0t
LSBhL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMKKysrIGIveGVuL2NvbW1vbi94bWFsbG9jX3Rs
c2YuYwpAQCAtMTIwLDkgKzEyMCwxMTEgQEAgc3RydWN0IHhtZW1fcG9vbCB7CiAgICAgY2hhciBu
YW1lW01BWF9QT09MX05BTUVfTEVOXTsKIH07Cgorc3RhdGljIHN0cnVjdCB4bWVtX3Bvb2wgKnhl
bnBvb2w7CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBNQVBQSU5HX0lOU0VSVCh1bnNpZ25lZCBsb25n
IHIsIGludCAqZmwsIGludCAqc2wpOworCiAvKgogICogSGVscGluZyBmdW5jdGlvbnMKICAqLwor
I2lmbmRlZiBOREVCVUcKK3N0YXRpYyBib29sX3QgeG1lbV9wb29sX2NoZWNrX3NpemUoY29uc3Qg
c3RydWN0IGJoZHIgKmIsIGludCBmbCwgaW50IHNsKQoreworICAgIHdoaWxlICggYiApCisgICAg
eworICAgICAgICBpbnQgX19mbDsKKyAgICAgICAgaW50IF9fc2w7CisKKyAgICAgICAgTUFQUElO
R19JTlNFUlQoYi0+c2l6ZSwgJl9fZmwsICZfX3NsKTsKKyAgICAgICAgaWYgKCBfX2ZsICE9IGZs
IHx8IF9fc2wgIT0gc2wgKQorICAgICAgICB7CisgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VS
UiAieG1lbV9wb29sOiBmb3IgYmxvY2sgJXAgc2l6ZSA9ICV1LCB7IGZsID0gJWQsIHNsID0gJWQg
fSBzaG91bGQgYmUgeyBmbCA9ICVkLCBzbCA9ICVkIH1cbiIsCisgICAgICAgICAgICAgICAgICAg
YiwgYi0+c2l6ZSwgZmwsIHNsLCBfX2ZsLCBfX3NsKTsKKyAgICAgICAgICAgIHJldHVybiAwOwor
ICAgICAgICB9CisgICAgICAgIGIgPSBiLT5wdHIuZnJlZV9wdHIubmV4dDsKKyAgICB9CisgICAg
cmV0dXJuIDE7Cit9CisKKy8qCisgKiBUaGlzIGZ1bmN0aW9uIG11c3QgYmUgY2FsbGVkIGZyb20g
YSBjb250ZXh0IHdoZXJlIHBvb2wtPmxvY2sgaXMKKyAqIGFscmVhZHkgYWNxdWlyZWQuCisgKgor
ICogUmV0dXJucyB0cnVlIGlmIHRoZSBwb29sIGhhcyBiZWVuIGNvcnJ1cHRlZCwgZmFsc2Ugb3Ro
ZXJ3aXNlCisgKi8KKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKSBfX3htZW1f
cG9vbF9jaGVja19sb2NrZWQoX19GSUxFX18sIF9fTElORV9fLCBwb29sKQorc3RhdGljIGJvb2xf
dCBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsIGNv
bnN0IHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCit7CisgICAgaW50IGk7CisgICAgc3RhdGljIGJv
b2xfdCBvbmNlID0gMTsKKworICAgIGlmICggIW9uY2UgKQorICAgICAgICBnb3RvIG91dDsKKyAg
ICBmb3IgKCBpID0gMDsgaSA8IFJFQUxfRkxJOyBpKysgKQorICAgIHsKKyAgICAgICAgaW50IGZs
ID0gKHBvb2wtPmZsX2JpdG1hcCAmICgxIDw8IGkpKSA/IGkgOiAtMTsKKworICAgICAgICBpZiAo
IGZsID49IDAgKQorICAgICAgICB7CisgICAgICAgICAgICBpbnQgajsKKworICAgICAgICAgICAg
aWYgKCAhcG9vbC0+c2xfYml0bWFwW2ZsXSApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAg
ICAgcHJpbnRrKFhFTkxPR19FUlIgInhtZW1fcG9vbDogdGhlIFRMU0YgYml0bWFwIGlzIGNvcnJ1
cHRlZCAobm9uLWVtcHR5IEZMIHdpdGggZW1wdHkgU0wpXG4iKTsKKyAgICAgICAgICAgICAgICBf
X3dhcm4oZmlsZSwgbGluZSk7CisgICAgICAgICAgICAgICAgb25jZSA9IDA7CisgICAgICAgICAg
ICAgICAgYnJlYWs7CisgICAgICAgICAgICB9CisgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8
IE1BWF9TTEk7IGorKyApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgaW50IHNsID0g
KHBvb2wtPnNsX2JpdG1hcFtmbF0gJiAoMSA8PCBqKSkgPyBqIDogLTE7CisKKyAgICAgICAgICAg
ICAgICBpZiAoIHNsIDwgMCApCisgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOworICAgICAg
ICAgICAgICAgIGlmICggIXBvb2wtPm1hdHJpeFtmbF1bc2xdICkKKyAgICAgICAgICAgICAgICB7
CisgICAgICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4bWVtX3Bvb2w6IHRoZSBU
TFNGIGJpdG1hcCBpcyBjb3JydXB0ZWQgKG1hdHJpeFslZF1bJWRdIGlzIE5VTEwpXG4iLAorICAg
ICAgICAgICAgICAgICAgICAgICAgZmwsIHNsKTsKKyAgICAgICAgICAgICAgICAgICAgX193YXJu
KGZpbGUsIGxpbmUpOworICAgICAgICAgICAgICAgICAgICBvbmNlID0gMDsKKyAgICAgICAgICAg
ICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICAgICAgfQorICAgICAgICAgICAgICAgIGlmICgg
IXhtZW1fcG9vbF9jaGVja19zaXplKHBvb2wtPm1hdHJpeFtmbF1bc2xdLCBmbCwgc2wpICkKKyAg
ICAgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4
bWVtX3Bvb2w6IHRoZSBUTFNGIGNodW5rIG1hdHJpeCBpcyBjb3JydXB0ZWRcbiIpOworICAgICAg
ICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGluZSk7CisgICAgICAgICAgICAgICAgICAgIG9u
Y2UgPSAwOworICAgICAgICAgICAgICAgICAgICBicmVhazsKKyAgICAgICAgICAgICAgICB9Cisg
ICAgICAgICAgICB9CisgICAgICAgICAgICBpZiAoICFvbmNlICkKKyAgICAgICAgICAgICAgICBi
cmVhazsKKyAgICAgICAgfQorICAgIH0KK291dDoKKyAgICByZXR1cm4gIW9uY2U7Cit9CisKKyNk
ZWZpbmUgeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKHBvb2wpIF9feG1lbV9wb29sX2NoZWNrX3Vu
bG9ja2VkKF9fRklMRV9fLCBfX0xJTkVfXywgcG9vbCkKK3N0YXRpYyBib29sX3QgX194bWVtX3Bv
b2xfY2hlY2tfdW5sb2NrZWQoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsIHN0cnVjdCB4bWVt
X3Bvb2wgKnBvb2wpCit7CisgICAgYm9vbF90IG9vcHM7CisKKyAgICBzcGluX2xvY2soJnBvb2wt
PmxvY2spOworICAgIG9vcHMgPSBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoZmlsZSwgbGluZSwg
cG9vbCk7CisgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOworICAgIHJldHVybiBvb3BzOwor
fQorCitib29sX3QgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUs
IHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCit7CisgICAgcmV0dXJuIF9feG1lbV9wb29sX2NoZWNr
X3VubG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wgPyBwb29sIDogeGVucG9vbCk7Cit9CisjZWxzZQor
I2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpICgodm9pZCkocG9vbCkpCisjZGVm
aW5lIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChwb29sKSAoKHZvaWQpKHBvb2wpKQorI2VuZGlm
CgogLyoqCiAgKiBSZXR1cm5zIGluZGV4ZXMgKGZsLCBzbCkgb2YgdGhlIGxpc3QgdXNlZCB0byBz
ZXJ2ZSByZXF1ZXN0IG9mIHNpemUgcgpAQCAtMzgxLDYgKzQ4Myw4IEBAIHZvaWQgKnhtZW1fcG9v
bF9hbGxvYyh1bnNpZ25lZCBsb25nIHNpemUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCiAgICAg
aW50IGZsLCBzbDsKICAgICB1bnNpZ25lZCBsb25nIHRtcF9zaXplOwoKKyAgICB4bWVtX3Bvb2xf
Y2hlY2tfdW5sb2NrZWQocG9vbCk7CisKICAgICBpZiAoIHBvb2wtPmluaXRfcmVnaW9uID09IE5V
TEwgKQogICAgIHsKICAgICAgICAgaWYgKCAocmVnaW9uID0gcG9vbC0+Z2V0X21lbShwb29sLT5p
bml0X3NpemUpKSA9PSBOVUxMICkKQEAgLTQ0MiwxMSArNTQ2LDEzIEBAIHZvaWQgKnhtZW1fcG9v
bF9hbGxvYyh1bnNpZ25lZCBsb25nIHNpemUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCgogICAg
IHBvb2wtPnVzZWRfc2l6ZSArPSAoYi0+c2l6ZSAmIEJMT0NLX1NJWkVfTUFTSykgKyBCSERSX09W
RVJIRUFEOwoKKyAgICB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpOwogICAgIHNwaW5fdW5s
b2NrKCZwb29sLT5sb2NrKTsKICAgICByZXR1cm4gKHZvaWQgKiliLT5wdHIuYnVmZmVyOwoKICAg
ICAvKiBGYWlsZWQgYWxsb2MgKi8KICBvdXRfbG9ja2VkOgorICAgIHhtZW1fcG9vbF9jaGVja19s
b2NrZWQocG9vbCk7CiAgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwoKICBvdXQ6CkBAIC00
NjQsNiArNTcwLDcgQEAgdm9pZCB4bWVtX3Bvb2xfZnJlZSh2b2lkICpwdHIsIHN0cnVjdCB4bWVt
X3Bvb2wgKnBvb2wpCiAgICAgYiA9IChzdHJ1Y3QgYmhkciAqKSgoY2hhciAqKSBwdHIgLSBCSERS
X09WRVJIRUFEKTsKCiAgICAgc3Bpbl9sb2NrKCZwb29sLT5sb2NrKTsKKyAgICB4bWVtX3Bvb2xf
Y2hlY2tfbG9ja2VkKHBvb2wpOwogICAgIGItPnNpemUgfD0gRlJFRV9CTE9DSzsKICAgICBwb29s
LT51c2VkX3NpemUgLT0gKGItPnNpemUgJiBCTE9DS19TSVpFX01BU0spICsgQkhEUl9PVkVSSEVB
RDsKICAgICBiLT5wdHIuZnJlZV9wdHIgPSAoc3RydWN0IGZyZWVfcHRyKSB7IE5VTEwsIE5VTEx9
OwpAQCAtNTAwLDYgKzYwNyw3IEBAIHZvaWQgeG1lbV9wb29sX2ZyZWUodm9pZCAqcHRyLCBzdHJ1
Y3QgeG1lbV9wb29sICpwb29sKQogICAgIHRtcF9iLT5zaXplIHw9IFBSRVZfRlJFRTsKICAgICB0
bXBfYi0+cHJldl9oZHIgPSBiOwogIG91dDoKKyAgICB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBv
b2wpOwogICAgIHNwaW5fdW5sb2NrKCZwb29sLT5sb2NrKTsKIH0KCkBAIC01MTIsOCArNjIwLDYg
QEAgaW50IHhtZW1fcG9vbF9tYXhhbGxvYyhzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQogICogR2x1
ZSBmb3IgeG1hbGxvYygpLgogICovCgotc3RhdGljIHN0cnVjdCB4bWVtX3Bvb2wgKnhlbnBvb2w7
Ci0KIHN0YXRpYyB2b2lkICp4bWFsbG9jX3Bvb2xfZ2V0KHVuc2lnbmVkIGxvbmcgc2l6ZSkKIHsK
ICAgICBBU1NFUlQoc2l6ZSA9PSBQQUdFX1NJWkUpOwpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv
eGVuL3htYWxsb2MuaCBiL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKaW5kZXggMjRhOTlhYy4u
YWQ0ODkzMCAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaAorKysgYi94ZW4v
aW5jbHVkZS94ZW4veG1hbGxvYy5oCkBAIC0xMjMsNCArMTIzLDExIEBAIHVuc2lnbmVkIGxvbmcg
eG1lbV9wb29sX2dldF91c2VkX3NpemUoc3RydWN0IHhtZW1fcG9vbCAqcG9vbCk7CiAgKi8KIHVu
c2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF90b3RhbF9zaXplKHN0cnVjdCB4bWVtX3Bvb2wgKnBv
b2wpOwoKKyNpZm5kZWYgTkRFQlVHCisjZGVmaW5lIHhtZW1fcG9vbF9jaGVjayhwb29sKSBfX3ht
ZW1fcG9vbF9jaGVjayhfX0ZJTEVfXywgX19MSU5FX18sIHBvb2wpCitib29sX3QgX194bWVtX3Bv
b2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBv
b2wpOworI2Vsc2UKKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrKHBvb2wpICgodm9pZCkwKQorI2Vu
ZGlmCisKICNlbmRpZiAvKiBfX1hNQUxMT0NfSF9fICovCi0tCjIuMi4wCgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 08 02:38:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 02:38:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxoDZ-0005pJ-4y; Mon, 08 Dec 2014 02:38:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XxoDX-0005pE-Sv
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 02:38:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6C/92-25276-72F05845; Mon, 08 Dec 2014 02:38:31 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418006309!14024382!1
X-Originating-IP: [91.199.104.161]
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 12478 invoked from network); 8 Dec 2014 02:38:30 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 02:38:30 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=TZex+ZTNXoI78WZ9HMu9Z3dt3/5e++meYjSWQQfOa2z8hVBx44phQ9WpS+ouSYqCZzWKYWAXOJ2pU8wjnTW2NANHGHhvhqOn50l8x3Wn3lZKS8zSegkRfuhEB6V0I/TvRCineE+Z/OyfO12kEnVvQfGq6c9Ezs9LaghYu5ujPBmDs9mA44TiU/Pg674ad5AuM85ePzZqMzt8QSKSCCzvuaPacrNGBuHX6Ogzbl+26ApK6WZK3KVaKDpRwp8+nFehIqdQbS5j9sAPfhv21zIFMHVzFSOaI0TTuOgChnJfmDWhZqxI/5q8fp3cTTVDOsMVCnoNdH5FM/+zgXEYtAU3eA==;
	h=Received:Received:Received:Received:Received:Date:From:To:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:subject:message-id:in-reply-to:references:mime-version
	:content-type:content-transfer-encoding; s=default; bh=pJoGjFu2i
	S2N3y97ZgU/kaZCGzU=; b=wydeOm+5eEMpHymr2nj1mEuD2Rp98C9NAJVW3JNw7
	gFJJ6NMcRBue7BiZPn7qzPTJkuHXWzfcjR/IPqMvPJQ12PyQGqc4SPIbTp0O4mkI
	cffC9X3Gt4eMQvnGM9ObE8lOYiaoB0U8aDE85o5VImQKu3oGgkWDB19hmnK5MjB0
	1MkJXewTe30OPJBeFeAW0RVfWJkND8YXJ8GOwAYiTi5rAIID3Qs2GT7SzkEFfA4i
	SdvyaX07ccbNDMOylQ8mfX+//EILgpx8NGoThNjcWPcsk1okcIMUUEBbtSTgbbeo
	DPtEwxg2juuD80HQaS8twC2N3vymtWCRjmrg87k3+oQtw==
Received: (qmail 18484 invoked from network); 8 Dec 2014 04:38:29 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	8 Dec 2014 04:38:29 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id D35B880304
	for <xen-devel@lists.xen.org>; Mon,  8 Dec 2014 04:38:28 +0200 (EET)
Received: (qmail 28862 invoked from network); 8 Dec 2014 04:38:28 +0200
Received: from 5-12-114-134.residential.rdsnet.ro (HELO bitdefender.com)
	(mdontu@bitdefender.com@5.12.114.134)
	by smtp02.buh.bitdefender.net with SMTP; 8 Dec 2014 04:38:26 +0200
Date: Mon, 8 Dec 2014 04:38:25 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: xen-devel@lists.xen.org
Message-ID: <20141208043825.00f5cbd9@bitdefender.com>
In-Reply-To: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
References: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.58171
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374350,
	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_LEGIT_BITDEFENDER;
	NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled],
	URL: [Enabled], RTDA: [Enabled, Hit: No, Details: Error:
	onPost(20012)(400)], total: 0(775)
X-BitDefender-CF-Stamp: none
Subject: Re: [Xen-devel] [PATCH v2] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCA4IERlYyAyMDE0IDA0OjMwOjQ4ICswMjAwIE1paGFpIERvbsibdSB3cm90ZToKPiBJ
bXBsZW1lbnRlZCB4bWVtX3Bvb2xfY2hlY2soKSwgeG1lbV9wb29sX2NoZWNrX2xvY2tlZCgpIGFu
ZAo+IHhtZW1fcG9vbF9jaGVja191bmxvY2tlZCgpIHRvIHZlcml0eSB0aGUgaW50ZWdyaXR5IG9m
IHRoZSBUTFNGIG1hdHJpeC4KPiAKPiBTaWduZWQtb2ZmLWJ5OiBNaWhhaSBEb27Im3UgPG1kb250
dUBiaXRkZWZlbmRlci5jb20+Cj4gCj4gLS0tCj4gQ2hhbmdlcyBzaW5jZSB2MToKPiAgLSBmaXhl
ZCB0aGUgY29kaW5nc3R5bGUKPiAgLSBzd2FwZWQgX2xvY2tlZC9fdW5sb2NrZWQgbmFtaW5nCj4g
IC0gcmV3b3JrZWQgX194bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKCkgYSBiaXQKPiAgLSB1c2VkIGJv
b2xfdCB3aGVyZSBhcHByb3ByaWF0ZQo+ICAtIG1hZGUgeG1lbV9wb29sX2NoZWNrKCkgdGFrZSBh
IHBvb2wgYXJndW1lbnQgd2hpY2ggY2FuIGJlIE5VTEwKPiAtLS0KPiAgeGVuL2NvbW1vbi94bWFs
bG9jX3Rsc2YuYyB8IDExMCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKystCj4gIHhlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmggfCAgIDcgKysrCj4gIDIgZmlsZXMg
Y2hhbmdlZCwgMTE1IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCj4gCj4gZGlmZiAtLWdp
dCBhL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMgYi94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5j
Cj4gaW5kZXggYTU3NjljOS4uODY4MTE4NSAxMDA2NDQKPiAtLS0gYS94ZW4vY29tbW9uL3htYWxs
b2NfdGxzZi5jCj4gKysrIGIveGVuL2NvbW1vbi94bWFsbG9jX3Rsc2YuYwo+IEBAIC0xMjAsOSAr
MTIwLDExMSBAQCBzdHJ1Y3QgeG1lbV9wb29sIHsKPiAgICAgIGNoYXIgbmFtZVtNQVhfUE9PTF9O
QU1FX0xFTl07Cj4gIH07Cj4gCj4gK3N0YXRpYyBzdHJ1Y3QgeG1lbV9wb29sICp4ZW5wb29sOwo+
ICsKPiArc3RhdGljIGlubGluZSB2b2lkIE1BUFBJTkdfSU5TRVJUKHVuc2lnbmVkIGxvbmcgciwg
aW50ICpmbCwgaW50ICpzbCk7Cj4gKwo+ICAvKgo+ICAgKiBIZWxwaW5nIGZ1bmN0aW9ucwo+ICAg
Ki8KPiArI2lmbmRlZiBOREVCVUcKPiArc3RhdGljIGJvb2xfdCB4bWVtX3Bvb2xfY2hlY2tfc2l6
ZShjb25zdCBzdHJ1Y3QgYmhkciAqYiwgaW50IGZsLCBpbnQgc2wpCj4gK3sKPiArICAgIHdoaWxl
ICggYiApCj4gKyAgICB7Cj4gKyAgICAgICAgaW50IF9fZmw7Cj4gKyAgICAgICAgaW50IF9fc2w7
Cj4gKwo+ICsgICAgICAgIE1BUFBJTkdfSU5TRVJUKGItPnNpemUsICZfX2ZsLCAmX19zbCk7Cj4g
KyAgICAgICAgaWYgKCBfX2ZsICE9IGZsIHx8IF9fc2wgIT0gc2wgKQo+ICsgICAgICAgIHsKPiAr
ICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInhtZW1fcG9vbDogZm9yIGJsb2NrICVwIHNp
emUgPSAldSwgeyBmbCA9ICVkLCBzbCA9ICVkIH0gc2hvdWxkIGJlIHsgZmwgPSAlZCwgc2wgPSAl
ZCB9XG4iLAo+ICsgICAgICAgICAgICAgICAgICAgYiwgYi0+c2l6ZSwgZmwsIHNsLCBfX2ZsLCBf
X3NsKTsKPiArICAgICAgICAgICAgcmV0dXJuIDA7Cj4gKyAgICAgICAgfQo+ICsgICAgICAgIGIg
PSBiLT5wdHIuZnJlZV9wdHIubmV4dDsKPiArICAgIH0KPiArICAgIHJldHVybiAxOwo+ICt9Cj4g
Kwo+ICsvKgo+ICsgKiBUaGlzIGZ1bmN0aW9uIG11c3QgYmUgY2FsbGVkIGZyb20gYSBjb250ZXh0
IHdoZXJlIHBvb2wtPmxvY2sgaXMKPiArICogYWxyZWFkeSBhY3F1aXJlZC4KPiArICoKPiArICog
UmV0dXJucyB0cnVlIGlmIHRoZSBwb29sIGhhcyBiZWVuIGNvcnJ1cHRlZCwgZmFsc2Ugb3RoZXJ3
aXNlCj4gKyAqLwo+ICsjZGVmaW5lIHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCkgX194bWVt
X3Bvb2xfY2hlY2tfbG9ja2VkKF9fRklMRV9fLCBfX0xJTkVfXywgcG9vbCkKPiArc3RhdGljIGJv
b2xfdCBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUs
IGNvbnN0IHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gK3sKPiArICAgIGludCBpOwo+ICsgICAg
c3RhdGljIGJvb2xfdCBvbmNlID0gMTsKPiArCj4gKyAgICBpZiAoICFvbmNlICkKPiArICAgICAg
ICBnb3RvIG91dDsKPiArICAgIGZvciAoIGkgPSAwOyBpIDwgUkVBTF9GTEk7IGkrKyApCj4gKyAg
ICB7Cj4gKyAgICAgICAgaW50IGZsID0gKHBvb2wtPmZsX2JpdG1hcCAmICgxIDw8IGkpKSA/IGkg
OiAtMTsKPiArCj4gKyAgICAgICAgaWYgKCBmbCA+PSAwICkKPiArICAgICAgICB7Cj4gKyAgICAg
ICAgICAgIGludCBqOwo+ICsKPiArICAgICAgICAgICAgaWYgKCAhcG9vbC0+c2xfYml0bWFwW2Zs
XSApCj4gKyAgICAgICAgICAgIHsKPiArICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJS
ICJ4bWVtX3Bvb2w6IHRoZSBUTFNGIGJpdG1hcCBpcyBjb3JydXB0ZWQgKG5vbi1lbXB0eSBGTCB3
aXRoIGVtcHR5IFNMKVxuIik7Cj4gKyAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGluZSk7
Cj4gKyAgICAgICAgICAgICAgICBvbmNlID0gMDsKPiArICAgICAgICAgICAgICAgIGJyZWFrOwo+
ICsgICAgICAgICAgICB9Cj4gKyAgICAgICAgICAgIGZvciAoIGogPSAwOyBqIDwgTUFYX1NMSTsg
aisrICkKPiArICAgICAgICAgICAgewo+ICsgICAgICAgICAgICAgICAgaW50IHNsID0gKHBvb2wt
PnNsX2JpdG1hcFtmbF0gJiAoMSA8PCBqKSkgPyBqIDogLTE7Cj4gKwo+ICsgICAgICAgICAgICAg
ICAgaWYgKCBzbCA8IDAgKQo+ICsgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwo+ICsgICAg
ICAgICAgICAgICAgaWYgKCAhcG9vbC0+bWF0cml4W2ZsXVtzbF0gKQo+ICsgICAgICAgICAgICAg
ICAgewo+ICsgICAgICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4bWVtX3Bvb2w6
IHRoZSBUTFNGIGJpdG1hcCBpcyBjb3JydXB0ZWQgKG1hdHJpeFslZF1bJWRdIGlzIE5VTEwpXG4i
LAo+ICsgICAgICAgICAgICAgICAgICAgICAgICBmbCwgc2wpOwo+ICsgICAgICAgICAgICAgICAg
ICAgIF9fd2FybihmaWxlLCBsaW5lKTsKPiArICAgICAgICAgICAgICAgICAgICBvbmNlID0gMDsK
PiArICAgICAgICAgICAgICAgICAgICBicmVhazsKPiArICAgICAgICAgICAgICAgIH0KPiArICAg
ICAgICAgICAgICAgIGlmICggIXhtZW1fcG9vbF9jaGVja19zaXplKHBvb2wtPm1hdHJpeFtmbF1b
c2xdLCBmbCwgc2wpICkKPiArICAgICAgICAgICAgICAgIHsKPiArICAgICAgICAgICAgICAgICAg
ICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9wb29sOiB0aGUgVExTRiBjaHVuayBtYXRyaXggaXMg
Y29ycnVwdGVkXG4iKTsKPiArICAgICAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGluZSk7
Cj4gKyAgICAgICAgICAgICAgICAgICAgb25jZSA9IDA7Cj4gKyAgICAgICAgICAgICAgICAgICAg
YnJlYWs7Cj4gKyAgICAgICAgICAgICAgICB9Cj4gKyAgICAgICAgICAgIH0KPiArICAgICAgICAg
ICAgaWYgKCAhb25jZSApCj4gKyAgICAgICAgICAgICAgICBicmVhazsKPiArICAgICAgICB9Cj4g
KyAgICB9Cj4gK291dDoKPiArICAgIHJldHVybiAhb25jZTsKPiArfQo+ICsKPiArI2RlZmluZSB4
bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQocG9vbCkgX194bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQo
X19GSUxFX18sIF9fTElORV9fLCBwb29sKQo+ICtzdGF0aWMgYm9vbF90IF9feG1lbV9wb29sX2No
ZWNrX3VubG9ja2VkKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBzdHJ1Y3QgeG1lbV9wb29s
ICpwb29sKQo+ICt7Cj4gKyAgICBib29sX3Qgb29wczsKPiArCj4gKyAgICBzcGluX2xvY2soJnBv
b2wtPmxvY2spOwo+ICsgICAgb29wcyA9IF9feG1lbV9wb29sX2NoZWNrX2xvY2tlZChmaWxlLCBs
aW5lLCBwb29sKTsKPiArICAgIHNwaW5fdW5sb2NrKCZwb29sLT5sb2NrKTsKPiArICAgIHJldHVy
biBvb3BzOwo+ICt9Cj4gKwo+ICtib29sX3QgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAq
ZmlsZSwgaW50IGxpbmUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gK3sKPiArICAgIHJldHVy
biBfX3htZW1fcG9vbF9jaGVja191bmxvY2tlZChmaWxlLCBsaW5lLCBwb29sID8gcG9vbCA6IHhl
bnBvb2wpOwo+ICt9Cj4gKyNlbHNlCj4gKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChw
b29sKSAoKHZvaWQpKHBvb2wpKQo+ICsjZGVmaW5lIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChw
b29sKSAoKHZvaWQpKHBvb2wpKQo+ICsjZW5kaWYKPiAKPiAgLyoqCj4gICAqIFJldHVybnMgaW5k
ZXhlcyAoZmwsIHNsKSBvZiB0aGUgbGlzdCB1c2VkIHRvIHNlcnZlIHJlcXVlc3Qgb2Ygc2l6ZSBy
Cj4gQEAgLTM4MSw2ICs0ODMsOCBAQCB2b2lkICp4bWVtX3Bvb2xfYWxsb2ModW5zaWduZWQgbG9u
ZyBzaXplLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ICAgICAgaW50IGZsLCBzbDsKPiAgICAg
IHVuc2lnbmVkIGxvbmcgdG1wX3NpemU7Cj4gCj4gKyAgICB4bWVtX3Bvb2xfY2hlY2tfdW5sb2Nr
ZWQocG9vbCk7Cj4gKwo+ICAgICAgaWYgKCBwb29sLT5pbml0X3JlZ2lvbiA9PSBOVUxMICkKPiAg
ICAgIHsKPiAgICAgICAgICBpZiAoIChyZWdpb24gPSBwb29sLT5nZXRfbWVtKHBvb2wtPmluaXRf
c2l6ZSkpID09IE5VTEwgKQo+IEBAIC00NDIsMTEgKzU0NiwxMyBAQCB2b2lkICp4bWVtX3Bvb2xf
YWxsb2ModW5zaWduZWQgbG9uZyBzaXplLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+IAo+ICAg
ICAgcG9vbC0+dXNlZF9zaXplICs9IChiLT5zaXplICYgQkxPQ0tfU0laRV9NQVNLKSArIEJIRFJf
T1ZFUkhFQUQ7Cj4gCj4gKyAgICB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpOwo+ICAgICAg
c3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwo+ICAgICAgcmV0dXJuICh2b2lkICopYi0+cHRyLmJ1
ZmZlcjsKPiAKPiAgICAgIC8qIEZhaWxlZCBhbGxvYyAqLwo+ICAgb3V0X2xvY2tlZDoKPiArICAg
IHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCk7Cj4gICAgICBzcGluX3VubG9jaygmcG9vbC0+
bG9jayk7Cj4gCj4gICBvdXQ6Cj4gQEAgLTQ2NCw2ICs1NzAsNyBAQCB2b2lkIHhtZW1fcG9vbF9m
cmVlKHZvaWQgKnB0ciwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAgICAgIGIgPSAoc3RydWN0
IGJoZHIgKikoKGNoYXIgKikgcHRyIC0gQkhEUl9PVkVSSEVBRCk7Cj4gCj4gICAgICBzcGluX2xv
Y2soJnBvb2wtPmxvY2spOwo+ICsgICAgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKTsKPiAg
ICAgIGItPnNpemUgfD0gRlJFRV9CTE9DSzsKPiAgICAgIHBvb2wtPnVzZWRfc2l6ZSAtPSAoYi0+
c2l6ZSAmIEJMT0NLX1NJWkVfTUFTSykgKyBCSERSX09WRVJIRUFEOwo+ICAgICAgYi0+cHRyLmZy
ZWVfcHRyID0gKHN0cnVjdCBmcmVlX3B0cikgeyBOVUxMLCBOVUxMfTsKPiBAQCAtNTAwLDYgKzYw
Nyw3IEBAIHZvaWQgeG1lbV9wb29sX2ZyZWUodm9pZCAqcHRyLCBzdHJ1Y3QgeG1lbV9wb29sICpw
b29sKQo+ICAgICAgdG1wX2ItPnNpemUgfD0gUFJFVl9GUkVFOwo+ICAgICAgdG1wX2ItPnByZXZf
aGRyID0gYjsKPiAgIG91dDoKPiArICAgIHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCk7Cj4g
ICAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7Cj4gIH0KPiAKPiBAQCAtNTEyLDggKzYyMCw2
IEBAIGludCB4bWVtX3Bvb2xfbWF4YWxsb2Moc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAgICog
R2x1ZSBmb3IgeG1hbGxvYygpLgo+ICAgKi8KPiAKPiAtc3RhdGljIHN0cnVjdCB4bWVtX3Bvb2wg
KnhlbnBvb2w7Cj4gLQo+ICBzdGF0aWMgdm9pZCAqeG1hbGxvY19wb29sX2dldCh1bnNpZ25lZCBs
b25nIHNpemUpCj4gIHsKPiAgICAgIEFTU0VSVChzaXplID09IFBBR0VfU0laRSk7Cj4gZGlmZiAt
LWdpdCBhL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmggYi94ZW4vaW5jbHVkZS94ZW4veG1hbGxv
Yy5oCj4gaW5kZXggMjRhOTlhYy4uYWQ0ODkzMCAxMDA2NDQKPiAtLS0gYS94ZW4vaW5jbHVkZS94
ZW4veG1hbGxvYy5oCj4gKysrIGIveGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaAo+IEBAIC0xMjMs
NCArMTIzLDExIEBAIHVuc2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF91c2VkX3NpemUoc3RydWN0
IHhtZW1fcG9vbCAqcG9vbCk7Cj4gICAqLwo+ICB1bnNpZ25lZCBsb25nIHhtZW1fcG9vbF9nZXRf
dG90YWxfc2l6ZShzdHJ1Y3QgeG1lbV9wb29sICpwb29sKTsKPiAKPiArI2lmbmRlZiBOREVCVUcK
PiArI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2socG9vbCkgX194bWVtX3Bvb2xfY2hlY2soX19GSUxF
X18sIF9fTElORV9fLCBwb29sKQo+ICtib29sX3QgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hh
ciAqZmlsZSwgaW50IGxpbmUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpOwo+ICsjZWxzZQo+ICsj
ZGVmaW5lIHhtZW1fcG9vbF9jaGVjayhwb29sKSAoKHZvaWQpMCkKPiArI2VuZGlmCj4gKwo+ICAj
ZW5kaWYgLyogX19YTUFMTE9DX0hfXyAqLwoKVGhpcyBwYXRjaCBkZXBlbmRzIG9uOgpodHRwOi8v
bGlzdHMueGVucHJvamVjdC5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxNC0xMi9tc2cw
MDgwOS5odG1sCgotLSAKTWloYWkgRE9OyJpVCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Dec 08 02:38:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 02:38:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxoDZ-0005pJ-4y; Mon, 08 Dec 2014 02:38:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XxoDX-0005pE-Sv
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 02:38:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6C/92-25276-72F05845; Mon, 08 Dec 2014 02:38:31 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418006309!14024382!1
X-Originating-IP: [91.199.104.161]
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 12478 invoked from network); 8 Dec 2014 02:38:30 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 02:38:30 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=TZex+ZTNXoI78WZ9HMu9Z3dt3/5e++meYjSWQQfOa2z8hVBx44phQ9WpS+ouSYqCZzWKYWAXOJ2pU8wjnTW2NANHGHhvhqOn50l8x3Wn3lZKS8zSegkRfuhEB6V0I/TvRCineE+Z/OyfO12kEnVvQfGq6c9Ezs9LaghYu5ujPBmDs9mA44TiU/Pg674ad5AuM85ePzZqMzt8QSKSCCzvuaPacrNGBuHX6Ogzbl+26ApK6WZK3KVaKDpRwp8+nFehIqdQbS5j9sAPfhv21zIFMHVzFSOaI0TTuOgChnJfmDWhZqxI/5q8fp3cTTVDOsMVCnoNdH5FM/+zgXEYtAU3eA==;
	h=Received:Received:Received:Received:Received:Date:From:To:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:subject:message-id:in-reply-to:references:mime-version
	:content-type:content-transfer-encoding; s=default; bh=pJoGjFu2i
	S2N3y97ZgU/kaZCGzU=; b=wydeOm+5eEMpHymr2nj1mEuD2Rp98C9NAJVW3JNw7
	gFJJ6NMcRBue7BiZPn7qzPTJkuHXWzfcjR/IPqMvPJQ12PyQGqc4SPIbTp0O4mkI
	cffC9X3Gt4eMQvnGM9ObE8lOYiaoB0U8aDE85o5VImQKu3oGgkWDB19hmnK5MjB0
	1MkJXewTe30OPJBeFeAW0RVfWJkND8YXJ8GOwAYiTi5rAIID3Qs2GT7SzkEFfA4i
	SdvyaX07ccbNDMOylQ8mfX+//EILgpx8NGoThNjcWPcsk1okcIMUUEBbtSTgbbeo
	DPtEwxg2juuD80HQaS8twC2N3vymtWCRjmrg87k3+oQtw==
Received: (qmail 18484 invoked from network); 8 Dec 2014 04:38:29 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	8 Dec 2014 04:38:29 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id D35B880304
	for <xen-devel@lists.xen.org>; Mon,  8 Dec 2014 04:38:28 +0200 (EET)
Received: (qmail 28862 invoked from network); 8 Dec 2014 04:38:28 +0200
Received: from 5-12-114-134.residential.rdsnet.ro (HELO bitdefender.com)
	(mdontu@bitdefender.com@5.12.114.134)
	by smtp02.buh.bitdefender.net with SMTP; 8 Dec 2014 04:38:26 +0200
Date: Mon, 8 Dec 2014 04:38:25 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: xen-devel@lists.xen.org
Message-ID: <20141208043825.00f5cbd9@bitdefender.com>
In-Reply-To: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
References: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.58171
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374350,
	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_LEGIT_BITDEFENDER;
	NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled],
	URL: [Enabled], RTDA: [Enabled, Hit: No, Details: Error:
	onPost(20012)(400)], total: 0(775)
X-BitDefender-CF-Stamp: none
Subject: Re: [Xen-devel] [PATCH v2] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCA4IERlYyAyMDE0IDA0OjMwOjQ4ICswMjAwIE1paGFpIERvbsibdSB3cm90ZToKPiBJ
bXBsZW1lbnRlZCB4bWVtX3Bvb2xfY2hlY2soKSwgeG1lbV9wb29sX2NoZWNrX2xvY2tlZCgpIGFu
ZAo+IHhtZW1fcG9vbF9jaGVja191bmxvY2tlZCgpIHRvIHZlcml0eSB0aGUgaW50ZWdyaXR5IG9m
IHRoZSBUTFNGIG1hdHJpeC4KPiAKPiBTaWduZWQtb2ZmLWJ5OiBNaWhhaSBEb27Im3UgPG1kb250
dUBiaXRkZWZlbmRlci5jb20+Cj4gCj4gLS0tCj4gQ2hhbmdlcyBzaW5jZSB2MToKPiAgLSBmaXhl
ZCB0aGUgY29kaW5nc3R5bGUKPiAgLSBzd2FwZWQgX2xvY2tlZC9fdW5sb2NrZWQgbmFtaW5nCj4g
IC0gcmV3b3JrZWQgX194bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKCkgYSBiaXQKPiAgLSB1c2VkIGJv
b2xfdCB3aGVyZSBhcHByb3ByaWF0ZQo+ICAtIG1hZGUgeG1lbV9wb29sX2NoZWNrKCkgdGFrZSBh
IHBvb2wgYXJndW1lbnQgd2hpY2ggY2FuIGJlIE5VTEwKPiAtLS0KPiAgeGVuL2NvbW1vbi94bWFs
bG9jX3Rsc2YuYyB8IDExMCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKystCj4gIHhlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmggfCAgIDcgKysrCj4gIDIgZmlsZXMg
Y2hhbmdlZCwgMTE1IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCj4gCj4gZGlmZiAtLWdp
dCBhL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMgYi94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5j
Cj4gaW5kZXggYTU3NjljOS4uODY4MTE4NSAxMDA2NDQKPiAtLS0gYS94ZW4vY29tbW9uL3htYWxs
b2NfdGxzZi5jCj4gKysrIGIveGVuL2NvbW1vbi94bWFsbG9jX3Rsc2YuYwo+IEBAIC0xMjAsOSAr
MTIwLDExMSBAQCBzdHJ1Y3QgeG1lbV9wb29sIHsKPiAgICAgIGNoYXIgbmFtZVtNQVhfUE9PTF9O
QU1FX0xFTl07Cj4gIH07Cj4gCj4gK3N0YXRpYyBzdHJ1Y3QgeG1lbV9wb29sICp4ZW5wb29sOwo+
ICsKPiArc3RhdGljIGlubGluZSB2b2lkIE1BUFBJTkdfSU5TRVJUKHVuc2lnbmVkIGxvbmcgciwg
aW50ICpmbCwgaW50ICpzbCk7Cj4gKwo+ICAvKgo+ICAgKiBIZWxwaW5nIGZ1bmN0aW9ucwo+ICAg
Ki8KPiArI2lmbmRlZiBOREVCVUcKPiArc3RhdGljIGJvb2xfdCB4bWVtX3Bvb2xfY2hlY2tfc2l6
ZShjb25zdCBzdHJ1Y3QgYmhkciAqYiwgaW50IGZsLCBpbnQgc2wpCj4gK3sKPiArICAgIHdoaWxl
ICggYiApCj4gKyAgICB7Cj4gKyAgICAgICAgaW50IF9fZmw7Cj4gKyAgICAgICAgaW50IF9fc2w7
Cj4gKwo+ICsgICAgICAgIE1BUFBJTkdfSU5TRVJUKGItPnNpemUsICZfX2ZsLCAmX19zbCk7Cj4g
KyAgICAgICAgaWYgKCBfX2ZsICE9IGZsIHx8IF9fc2wgIT0gc2wgKQo+ICsgICAgICAgIHsKPiAr
ICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInhtZW1fcG9vbDogZm9yIGJsb2NrICVwIHNp
emUgPSAldSwgeyBmbCA9ICVkLCBzbCA9ICVkIH0gc2hvdWxkIGJlIHsgZmwgPSAlZCwgc2wgPSAl
ZCB9XG4iLAo+ICsgICAgICAgICAgICAgICAgICAgYiwgYi0+c2l6ZSwgZmwsIHNsLCBfX2ZsLCBf
X3NsKTsKPiArICAgICAgICAgICAgcmV0dXJuIDA7Cj4gKyAgICAgICAgfQo+ICsgICAgICAgIGIg
PSBiLT5wdHIuZnJlZV9wdHIubmV4dDsKPiArICAgIH0KPiArICAgIHJldHVybiAxOwo+ICt9Cj4g
Kwo+ICsvKgo+ICsgKiBUaGlzIGZ1bmN0aW9uIG11c3QgYmUgY2FsbGVkIGZyb20gYSBjb250ZXh0
IHdoZXJlIHBvb2wtPmxvY2sgaXMKPiArICogYWxyZWFkeSBhY3F1aXJlZC4KPiArICoKPiArICog
UmV0dXJucyB0cnVlIGlmIHRoZSBwb29sIGhhcyBiZWVuIGNvcnJ1cHRlZCwgZmFsc2Ugb3RoZXJ3
aXNlCj4gKyAqLwo+ICsjZGVmaW5lIHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCkgX194bWVt
X3Bvb2xfY2hlY2tfbG9ja2VkKF9fRklMRV9fLCBfX0xJTkVfXywgcG9vbCkKPiArc3RhdGljIGJv
b2xfdCBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUs
IGNvbnN0IHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gK3sKPiArICAgIGludCBpOwo+ICsgICAg
c3RhdGljIGJvb2xfdCBvbmNlID0gMTsKPiArCj4gKyAgICBpZiAoICFvbmNlICkKPiArICAgICAg
ICBnb3RvIG91dDsKPiArICAgIGZvciAoIGkgPSAwOyBpIDwgUkVBTF9GTEk7IGkrKyApCj4gKyAg
ICB7Cj4gKyAgICAgICAgaW50IGZsID0gKHBvb2wtPmZsX2JpdG1hcCAmICgxIDw8IGkpKSA/IGkg
OiAtMTsKPiArCj4gKyAgICAgICAgaWYgKCBmbCA+PSAwICkKPiArICAgICAgICB7Cj4gKyAgICAg
ICAgICAgIGludCBqOwo+ICsKPiArICAgICAgICAgICAgaWYgKCAhcG9vbC0+c2xfYml0bWFwW2Zs
XSApCj4gKyAgICAgICAgICAgIHsKPiArICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJS
ICJ4bWVtX3Bvb2w6IHRoZSBUTFNGIGJpdG1hcCBpcyBjb3JydXB0ZWQgKG5vbi1lbXB0eSBGTCB3
aXRoIGVtcHR5IFNMKVxuIik7Cj4gKyAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGluZSk7
Cj4gKyAgICAgICAgICAgICAgICBvbmNlID0gMDsKPiArICAgICAgICAgICAgICAgIGJyZWFrOwo+
ICsgICAgICAgICAgICB9Cj4gKyAgICAgICAgICAgIGZvciAoIGogPSAwOyBqIDwgTUFYX1NMSTsg
aisrICkKPiArICAgICAgICAgICAgewo+ICsgICAgICAgICAgICAgICAgaW50IHNsID0gKHBvb2wt
PnNsX2JpdG1hcFtmbF0gJiAoMSA8PCBqKSkgPyBqIDogLTE7Cj4gKwo+ICsgICAgICAgICAgICAg
ICAgaWYgKCBzbCA8IDAgKQo+ICsgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwo+ICsgICAg
ICAgICAgICAgICAgaWYgKCAhcG9vbC0+bWF0cml4W2ZsXVtzbF0gKQo+ICsgICAgICAgICAgICAg
ICAgewo+ICsgICAgICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4bWVtX3Bvb2w6
IHRoZSBUTFNGIGJpdG1hcCBpcyBjb3JydXB0ZWQgKG1hdHJpeFslZF1bJWRdIGlzIE5VTEwpXG4i
LAo+ICsgICAgICAgICAgICAgICAgICAgICAgICBmbCwgc2wpOwo+ICsgICAgICAgICAgICAgICAg
ICAgIF9fd2FybihmaWxlLCBsaW5lKTsKPiArICAgICAgICAgICAgICAgICAgICBvbmNlID0gMDsK
PiArICAgICAgICAgICAgICAgICAgICBicmVhazsKPiArICAgICAgICAgICAgICAgIH0KPiArICAg
ICAgICAgICAgICAgIGlmICggIXhtZW1fcG9vbF9jaGVja19zaXplKHBvb2wtPm1hdHJpeFtmbF1b
c2xdLCBmbCwgc2wpICkKPiArICAgICAgICAgICAgICAgIHsKPiArICAgICAgICAgICAgICAgICAg
ICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9wb29sOiB0aGUgVExTRiBjaHVuayBtYXRyaXggaXMg
Y29ycnVwdGVkXG4iKTsKPiArICAgICAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGluZSk7
Cj4gKyAgICAgICAgICAgICAgICAgICAgb25jZSA9IDA7Cj4gKyAgICAgICAgICAgICAgICAgICAg
YnJlYWs7Cj4gKyAgICAgICAgICAgICAgICB9Cj4gKyAgICAgICAgICAgIH0KPiArICAgICAgICAg
ICAgaWYgKCAhb25jZSApCj4gKyAgICAgICAgICAgICAgICBicmVhazsKPiArICAgICAgICB9Cj4g
KyAgICB9Cj4gK291dDoKPiArICAgIHJldHVybiAhb25jZTsKPiArfQo+ICsKPiArI2RlZmluZSB4
bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQocG9vbCkgX194bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQo
X19GSUxFX18sIF9fTElORV9fLCBwb29sKQo+ICtzdGF0aWMgYm9vbF90IF9feG1lbV9wb29sX2No
ZWNrX3VubG9ja2VkKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBzdHJ1Y3QgeG1lbV9wb29s
ICpwb29sKQo+ICt7Cj4gKyAgICBib29sX3Qgb29wczsKPiArCj4gKyAgICBzcGluX2xvY2soJnBv
b2wtPmxvY2spOwo+ICsgICAgb29wcyA9IF9feG1lbV9wb29sX2NoZWNrX2xvY2tlZChmaWxlLCBs
aW5lLCBwb29sKTsKPiArICAgIHNwaW5fdW5sb2NrKCZwb29sLT5sb2NrKTsKPiArICAgIHJldHVy
biBvb3BzOwo+ICt9Cj4gKwo+ICtib29sX3QgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAq
ZmlsZSwgaW50IGxpbmUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gK3sKPiArICAgIHJldHVy
biBfX3htZW1fcG9vbF9jaGVja191bmxvY2tlZChmaWxlLCBsaW5lLCBwb29sID8gcG9vbCA6IHhl
bnBvb2wpOwo+ICt9Cj4gKyNlbHNlCj4gKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChw
b29sKSAoKHZvaWQpKHBvb2wpKQo+ICsjZGVmaW5lIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChw
b29sKSAoKHZvaWQpKHBvb2wpKQo+ICsjZW5kaWYKPiAKPiAgLyoqCj4gICAqIFJldHVybnMgaW5k
ZXhlcyAoZmwsIHNsKSBvZiB0aGUgbGlzdCB1c2VkIHRvIHNlcnZlIHJlcXVlc3Qgb2Ygc2l6ZSBy
Cj4gQEAgLTM4MSw2ICs0ODMsOCBAQCB2b2lkICp4bWVtX3Bvb2xfYWxsb2ModW5zaWduZWQgbG9u
ZyBzaXplLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ICAgICAgaW50IGZsLCBzbDsKPiAgICAg
IHVuc2lnbmVkIGxvbmcgdG1wX3NpemU7Cj4gCj4gKyAgICB4bWVtX3Bvb2xfY2hlY2tfdW5sb2Nr
ZWQocG9vbCk7Cj4gKwo+ICAgICAgaWYgKCBwb29sLT5pbml0X3JlZ2lvbiA9PSBOVUxMICkKPiAg
ICAgIHsKPiAgICAgICAgICBpZiAoIChyZWdpb24gPSBwb29sLT5nZXRfbWVtKHBvb2wtPmluaXRf
c2l6ZSkpID09IE5VTEwgKQo+IEBAIC00NDIsMTEgKzU0NiwxMyBAQCB2b2lkICp4bWVtX3Bvb2xf
YWxsb2ModW5zaWduZWQgbG9uZyBzaXplLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+IAo+ICAg
ICAgcG9vbC0+dXNlZF9zaXplICs9IChiLT5zaXplICYgQkxPQ0tfU0laRV9NQVNLKSArIEJIRFJf
T1ZFUkhFQUQ7Cj4gCj4gKyAgICB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpOwo+ICAgICAg
c3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwo+ICAgICAgcmV0dXJuICh2b2lkICopYi0+cHRyLmJ1
ZmZlcjsKPiAKPiAgICAgIC8qIEZhaWxlZCBhbGxvYyAqLwo+ICAgb3V0X2xvY2tlZDoKPiArICAg
IHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCk7Cj4gICAgICBzcGluX3VubG9jaygmcG9vbC0+
bG9jayk7Cj4gCj4gICBvdXQ6Cj4gQEAgLTQ2NCw2ICs1NzAsNyBAQCB2b2lkIHhtZW1fcG9vbF9m
cmVlKHZvaWQgKnB0ciwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAgICAgIGIgPSAoc3RydWN0
IGJoZHIgKikoKGNoYXIgKikgcHRyIC0gQkhEUl9PVkVSSEVBRCk7Cj4gCj4gICAgICBzcGluX2xv
Y2soJnBvb2wtPmxvY2spOwo+ICsgICAgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKTsKPiAg
ICAgIGItPnNpemUgfD0gRlJFRV9CTE9DSzsKPiAgICAgIHBvb2wtPnVzZWRfc2l6ZSAtPSAoYi0+
c2l6ZSAmIEJMT0NLX1NJWkVfTUFTSykgKyBCSERSX09WRVJIRUFEOwo+ICAgICAgYi0+cHRyLmZy
ZWVfcHRyID0gKHN0cnVjdCBmcmVlX3B0cikgeyBOVUxMLCBOVUxMfTsKPiBAQCAtNTAwLDYgKzYw
Nyw3IEBAIHZvaWQgeG1lbV9wb29sX2ZyZWUodm9pZCAqcHRyLCBzdHJ1Y3QgeG1lbV9wb29sICpw
b29sKQo+ICAgICAgdG1wX2ItPnNpemUgfD0gUFJFVl9GUkVFOwo+ICAgICAgdG1wX2ItPnByZXZf
aGRyID0gYjsKPiAgIG91dDoKPiArICAgIHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCk7Cj4g
ICAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7Cj4gIH0KPiAKPiBAQCAtNTEyLDggKzYyMCw2
IEBAIGludCB4bWVtX3Bvb2xfbWF4YWxsb2Moc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAgICog
R2x1ZSBmb3IgeG1hbGxvYygpLgo+ICAgKi8KPiAKPiAtc3RhdGljIHN0cnVjdCB4bWVtX3Bvb2wg
KnhlbnBvb2w7Cj4gLQo+ICBzdGF0aWMgdm9pZCAqeG1hbGxvY19wb29sX2dldCh1bnNpZ25lZCBs
b25nIHNpemUpCj4gIHsKPiAgICAgIEFTU0VSVChzaXplID09IFBBR0VfU0laRSk7Cj4gZGlmZiAt
LWdpdCBhL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmggYi94ZW4vaW5jbHVkZS94ZW4veG1hbGxv
Yy5oCj4gaW5kZXggMjRhOTlhYy4uYWQ0ODkzMCAxMDA2NDQKPiAtLS0gYS94ZW4vaW5jbHVkZS94
ZW4veG1hbGxvYy5oCj4gKysrIGIveGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaAo+IEBAIC0xMjMs
NCArMTIzLDExIEBAIHVuc2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF91c2VkX3NpemUoc3RydWN0
IHhtZW1fcG9vbCAqcG9vbCk7Cj4gICAqLwo+ICB1bnNpZ25lZCBsb25nIHhtZW1fcG9vbF9nZXRf
dG90YWxfc2l6ZShzdHJ1Y3QgeG1lbV9wb29sICpwb29sKTsKPiAKPiArI2lmbmRlZiBOREVCVUcK
PiArI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2socG9vbCkgX194bWVtX3Bvb2xfY2hlY2soX19GSUxF
X18sIF9fTElORV9fLCBwb29sKQo+ICtib29sX3QgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hh
ciAqZmlsZSwgaW50IGxpbmUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpOwo+ICsjZWxzZQo+ICsj
ZGVmaW5lIHhtZW1fcG9vbF9jaGVjayhwb29sKSAoKHZvaWQpMCkKPiArI2VuZGlmCj4gKwo+ICAj
ZW5kaWYgLyogX19YTUFMTE9DX0hfXyAqLwoKVGhpcyBwYXRjaCBkZXBlbmRzIG9uOgpodHRwOi8v
bGlzdHMueGVucHJvamVjdC5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxNC0xMi9tc2cw
MDgwOS5odG1sCgotLSAKTWloYWkgRE9OyJpVCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Dec 08 03:16:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 03: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 1Xxoo5-0007KU-Id; Mon, 08 Dec 2014 03:16:17 +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 1Xxoo4-0007KP-Cb
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 03:16:16 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	8B/A0-02696-FF715845; Mon, 08 Dec 2014 03:16:15 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418008573!13559187!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6327 invoked from network); 8 Dec 2014 03:16:13 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-2.tower-27.messagelabs.com with SMTP;
	8 Dec 2014 03:16:13 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 07 Dec 2014 19:14:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="495210711"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga003.jf.intel.com with ESMTP; 07 Dec 2014 19:12:33 -0800
Message-ID: <548517F7.6040106@intel.com>
Date: Mon, 08 Dec 2014 11:16: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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<20141202193943.GC357@laptop.dumpdata.com>
In-Reply-To: <20141202193943.GC357@laptop.dumpdata.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/3 3:39, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 05:24:20PM +0800, Tiejun Chen wrote:
>> This should be based on a new parameter globally, 'pci_rdmforce'.
>>
>> 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 this domctl provides an approach to control how to populate
>> reserved device memory by tools.
>>
>> Note we always post a message to user about this once we owns
>> RMRR.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   docs/man/xl.cfg.pod.5              |  6 +++++
>>   docs/misc/vtd.txt                  | 15 ++++++++++++
>>   tools/libxc/include/xenctrl.h      |  6 +++++
>>   tools/libxc/xc_domain.c            | 28 +++++++++++++++++++++++
>>   tools/libxl/libxl_create.c         |  3 +++
>>   tools/libxl/libxl_dm.c             | 47 ++++++++++++++++++++++++++++++++++++++
>>   tools/libxl/libxl_internal.h       |  4 ++++
>>   tools/libxl/libxl_types.idl        |  2 ++
>>   tools/libxl/libxlu_pci.c           |  2 ++
>>   tools/libxl/xl_cmdimpl.c           | 10 ++++++++
>
> In the past we had split the hypervisor and the
> toolstack patches in two. So that one could focus
> on the hypervisor ones first, and then in another
> patch on the toolstack.
>

Yes.

> But perhaps this was intended to be in one patch?

This change also involve docs so its little bit harder to understand the 
whole page if we split this.

>
>>   xen/drivers/passthrough/pci.c      | 39 +++++++++++++++++++++++++++++++
>>   xen/drivers/passthrough/vtd/dmar.c |  8 +++++++
>>   xen/include/asm-x86/hvm/domain.h   |  4 ++++
>
> I don't see ARM here? Should there be an ARM variant of this? If not

ARM doesn't need this feature.

> should the toolstack ones only run under x86?

And I think this shouldn't broken current ARM path as well. I mean this 
would return simply since ARM hasn't such a hypercall handler.

>
>>   xen/include/public/domctl.h        | 21 +++++++++++++++++
>>   xen/xsm/flask/hooks.c              |  1 +
>>   15 files changed, 196 insertions(+)
>>
>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
>> index 622ea53..9adc41e 100644
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -645,6 +645,12 @@ dom0 without confirmation.  Please use with care.
>>   D0-D3hot power management states for the PCI device. False (0) by
>>   default.
>>
>> +=item B<rdmforce=BOOLEAN>
>> +
>> +(HVM/x86 only) Specifies that the VM would force to check and try to
>
> s/force/forced/

I guess you're saying 'be forced'.

>> +reserve all reserved device memory, like RMRR, associated to the PCI
>> +device. False (0) by default.
>
> Not sure I understand. How would the VM be forced to do this? Or is
> it that the hvmloader would force to do this? And if it fails (as you

Yes.

> say 'try') ? What then?

In most cases we can reserve these regions but if these RMRR regions 
overlap with some fixed range, like guest BIOS, we can't succeed in this 
case.

>
>> +
>>   =back
>>
>>   =back
>> diff --git a/docs/misc/vtd.txt b/docs/misc/vtd.txt
>> index 9af0e99..23544d5 100644
>> --- a/docs/misc/vtd.txt
>> +++ b/docs/misc/vtd.txt
>> @@ -111,6 +111,21 @@ in the config file:
>>   To override for a specific device:
>>   	pci = [ '01:00.0,msitranslate=0', '03:00.0' ]
>>
>> +RDM, 'reserved device memory', for PCI Device Passthrough
>> +---------------------------------------------------------
>> +
>> +The BIOS controls some devices in terms of some reginos of memory used for
>
> Could you elaborate what 'some devices' are? Network cards? GPUs? What
> are the most commons ones.

Some legacy USB device to perform PS2 emulation, and GPU has a stolen 
memory as I remember.

>
> s/reginos/regions/

Fixed.

>
> And by regions you mean BAR regions?

No. I guess you want to know some background about RMRR :)

There's a good brief description in Linux:

What is RMRR?
-------------

There are some devices the BIOS controls, for e.g USB devices to perform
PS2 emulation. The regions of memory used for these devices are marked
reserved in the e820 map. When we turn on DMA translation, DMA to those
regions will fail. Hence BIOS uses RMRR to specify these regions along with
devices that need to access these regions. OS is expected to setup
unity mappings for these regions for these devices to access these regions.

>
>> +these devices. This kind of region should be reserved before creating a VM
>> +to make sure they are not occupied by RAM/MMIO to conflict, and also we can
>
> You said 'This' but here you are using the plural ' are'. IF you want it plural
> it needs to be 'These regions'

Thanks for your correction.

>> +create necessary IOMMU table successfully.
>> +
>> +To enable this globally, add "pci_rdmforce" in the config file:
>> +
>> +	pci_rdmforce = 1         (default is 0)
>
> The guest config file? Or /etc/xen/xl.conf ?

The guest config file. Here I just follow something about 
'pci_msitranslate' since they have that usage in common.

>
>> +
>> +Or just enable for a specific device:
>> +	pci = [ '01:00.0,rdmforce=1', '03:00.0' ]
>> +
>>
>>   Caveat on Conventional PCI Device Passthrough
>>   ---------------------------------------------
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h

[snip]

>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -34,6 +34,7 @@
>>   #include <xen/tasklet.h>
>>   #include <xsm/xsm.h>
>>   #include <asm/msi.h>
>> +#include <xen/stdbool.h>
>>
>>   struct pci_seg {
>>       struct list_head alldevs_list;
>> @@ -1553,6 +1554,44 @@ 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 = NULL;
>> +        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
>> +
>> +        if ( d == NULL )
>> +            return -ESRCH;
>> +
>
> What if this is called on an PV domain?

Currently we just support this in HVM, so I'd like to add this,

          if ( d == NULL )
              return -ESRCH;

+        ASSERT( is_hvm_domain(d) );
+

>
> You are also missing the XSM checks.

Just see this below.

>
> What if this is called multiple times. Is it OK to over-ride
> the 'pci_force' or should it stick once?

It should be fine since just xc/hvmloader need such an information while 
creating a VM.

And especially, currently we just call this one time to set. So why we 
need to call this again and again? I think if anyone want to extend such 
a case you're worrying, he should know any effect before he take a 
action, right?

>
>
>> +        d->arch.hvm_domain.pci_force =
>> +                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;
>
> Won't we crash here if this is called for PV guests?

After the line, 'ASSERT( is_hvm_domain(d) );', is added, this problem 
should be gone.

>
>> +        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;
>
> What if the 'num_pcidevs' has some bogus value. You need to check for that.

This value is grabbed from that existing interface, assign_device, so I 
mean this is already checked.

>
>
>> +        d->arch.hvm_domain.pcidevs = NULL;
>
> Please first free it. It might be that the toolstack
> is doing this a couple of times. You don't want to leak memory.
>

Okay,

+        if ( d->arch.hvm_domain.pcidevs )
+            xfree(d->arch.hvm_domain.pcidevs);

>
>> +
>> +        if ( xdsr->num_pcidevs )
>> +        {
>> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
>> +                                    xdsr->num_pcidevs);
>> +            if ( pcidevs == NULL )
>> +            {
>> +                rcu_unlock_domain(d);
>> +                return -ENOMEM;
>
> But you already have set 'num_pcidevs' to some value. This copying/check
> should be done before you modify 'd->arch.hvm_domain'...

This makes sense so I'll move down this fragment.

>> +            }
>> +
>> +            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
>> +                                 xdsr->num_pcidevs*sizeof(*pcidevs)) )
>> +            {
>> +                xfree(pcidevs);
>> +                rcu_unlock_domain(d);
>
> Ditto. You need to do these checks before you modify 'd->arch.hvm_domain'.
>
>> +                return -EFAULT;
>> +            }
>> +        }
>> +
>> +        d->arch.hvm_domain.pcidevs = pcidevs;
>> +        rcu_unlock_domain(d);
>> +    }
>> +        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 1152c3a..5e41e7a 100644
>> --- a/xen/drivers/passthrough/vtd/dmar.c
>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>> @@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>>                           "  RMRR region: base_addr %"PRIx64
>>                           " end_address %"PRIx64"\n",
>>                           rmrru->base_address, rmrru->end_address);
>> +            /*
>> +             * TODO: we may provide a precise paramter just to reserve
>
> s/paramter/parameter/

Fixed.

>> +             * RMRR range specific to one device.
>> +             */
>> +            dprintk(XENLOG_WARNING VTDPREFIX,
>> +                    "So please set pci_rdmforce to reserve these ranges"
>> +                    " if you need such a device in hotplug case.\n");

s/hotplug/passthrough

>
> 'Please set rdmforce to reserve ranges %lx->%lx if you plan to hotplug this device.'
>
> But then this is going to be a bit verbose, so perhaps:
>
> 'Ranges %lx-%lx need rdmforce to properly work.' ?

Its unnecessary to output range again since we already have such a print 
message here.

>
>> +
>>               acpi_register_rmrr_unit(rmrru);
>>           }
>>       }
>> diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
>> index 2757c7f..38530e5 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;
>>
>
> Maybe a comment explaining its purpose?

Okay.

/* Force to check/reserve Reserved Device Memory. */
     bool_t                  pci_force;

>
>> +    bool_t                  pci_force;
>> +    uint32_t                num_pcidevs;
>> +    struct xen_guest_pcidev_info      *pcidevs;
>> +
>
> You are also missing freeing of this in the hypervisor when the guest
> is destroyed. Please fix that.

You're right. I will go there next revision.

>
>>       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 57e2ed7..ba8970d 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -508,6 +508,25 @@ struct xen_domctl_get_device_group {
>>   typedef struct xen_domctl_get_device_group xen_domctl_get_device_group_t;
>>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_get_device_group_t);
>>
>> +/* Currently just one bit to indicate force to check Reserved Device Memory. */
>
> Not sure I understand. Did you mean:
>
> 'Check Reserved Device Memory'.

I can change this as '...force checking Reserved Device Memory.'

>
> What happens if you do not have this flag? What are the semantics
> of this hypercall - as in what will it mean.

If we have no this flag, these devices owned RMRR can't work in 
passthrough case.

>
>> +#define PCI_DEV_RDM_CHECK   0x1
>> +struct xen_guest_pcidev_info {
>> +    uint16_t    seg;
>> +    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;
>
> What is this 'flags' purpose compared to the 'pcidevs.flags'? Please
> explain.

I replied something to Kevin, and we just need a global flag so we can 
remove pcidevs.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);
>> +
>>   /* Pass-through interrupts: bind real irq -> hvm devfn. */
>>   /* XEN_DOMCTL_bind_pt_irq */
>>   /* XEN_DOMCTL_unbind_pt_irq */
>> @@ -1070,6 +1089,7 @@ struct xen_domctl {
>>   #define XEN_DOMCTL_setvnumainfo                  74
>>   #define XEN_DOMCTL_psr_cmt_op                    75
>>   #define XEN_DOMCTL_arm_configure_domain          76
>> +#define XEN_DOMCTL_set_rdm                       77
>>   #define XEN_DOMCTL_gdbsx_guestmemio            1000
>>   #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>>   #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
>> @@ -1135,6 +1155,7 @@ struct xen_domctl {
>>           struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>>           struct xen_domctl_vnuma             vnuma;
>>           struct xen_domctl_psr_cmt_op        psr_cmt_op;
>> +        struct xen_domctl_set_rdm           set_rdm;
>>           uint8_t                             pad[128];
>>       } u;
>>   };
>> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
>> index d48463f..5a760e2 100644
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -592,6 +592,7 @@ static int flask_domctl(struct domain *d, int cmd)
>>       case XEN_DOMCTL_test_assign_device:
>>       case XEN_DOMCTL_assign_device:
>>       case XEN_DOMCTL_deassign_device:
>> +    case XEN_DOMCTL_set_rdm:
>
> There is more to XSM than just this file..

But I don't see more other stuff, like XEN_DOMCTL_assign_device.

>
> Please compile with XSM enabled.

Anyway, I add XSM_ENABLE = y and FLASK_ENABLE = y in Config.mk then 
recompile, but looks good.

Anything I'm missing?

>>   #endif
>>           return 0;
>
>
> Also how does this work with 32-bit dom0s? Is there a need to use the
> compat layer?

Are you saying in xsm case? Others?

Actually this new DOMCTL is similar with XEN_DOMCTL_assign_device in 
some senses but I don't see such an issue you're pointing.

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 Dec 08 03:16:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 03: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 1Xxoo5-0007KU-Id; Mon, 08 Dec 2014 03:16:17 +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 1Xxoo4-0007KP-Cb
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 03:16:16 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	8B/A0-02696-FF715845; Mon, 08 Dec 2014 03:16:15 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418008573!13559187!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6327 invoked from network); 8 Dec 2014 03:16:13 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-2.tower-27.messagelabs.com with SMTP;
	8 Dec 2014 03:16:13 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 07 Dec 2014 19:14:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="495210711"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga003.jf.intel.com with ESMTP; 07 Dec 2014 19:12:33 -0800
Message-ID: <548517F7.6040106@intel.com>
Date: Mon, 08 Dec 2014 11:16: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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<20141202193943.GC357@laptop.dumpdata.com>
In-Reply-To: <20141202193943.GC357@laptop.dumpdata.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/3 3:39, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 05:24:20PM +0800, Tiejun Chen wrote:
>> This should be based on a new parameter globally, 'pci_rdmforce'.
>>
>> 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 this domctl provides an approach to control how to populate
>> reserved device memory by tools.
>>
>> Note we always post a message to user about this once we owns
>> RMRR.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   docs/man/xl.cfg.pod.5              |  6 +++++
>>   docs/misc/vtd.txt                  | 15 ++++++++++++
>>   tools/libxc/include/xenctrl.h      |  6 +++++
>>   tools/libxc/xc_domain.c            | 28 +++++++++++++++++++++++
>>   tools/libxl/libxl_create.c         |  3 +++
>>   tools/libxl/libxl_dm.c             | 47 ++++++++++++++++++++++++++++++++++++++
>>   tools/libxl/libxl_internal.h       |  4 ++++
>>   tools/libxl/libxl_types.idl        |  2 ++
>>   tools/libxl/libxlu_pci.c           |  2 ++
>>   tools/libxl/xl_cmdimpl.c           | 10 ++++++++
>
> In the past we had split the hypervisor and the
> toolstack patches in two. So that one could focus
> on the hypervisor ones first, and then in another
> patch on the toolstack.
>

Yes.

> But perhaps this was intended to be in one patch?

This change also involve docs so its little bit harder to understand the 
whole page if we split this.

>
>>   xen/drivers/passthrough/pci.c      | 39 +++++++++++++++++++++++++++++++
>>   xen/drivers/passthrough/vtd/dmar.c |  8 +++++++
>>   xen/include/asm-x86/hvm/domain.h   |  4 ++++
>
> I don't see ARM here? Should there be an ARM variant of this? If not

ARM doesn't need this feature.

> should the toolstack ones only run under x86?

And I think this shouldn't broken current ARM path as well. I mean this 
would return simply since ARM hasn't such a hypercall handler.

>
>>   xen/include/public/domctl.h        | 21 +++++++++++++++++
>>   xen/xsm/flask/hooks.c              |  1 +
>>   15 files changed, 196 insertions(+)
>>
>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
>> index 622ea53..9adc41e 100644
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -645,6 +645,12 @@ dom0 without confirmation.  Please use with care.
>>   D0-D3hot power management states for the PCI device. False (0) by
>>   default.
>>
>> +=item B<rdmforce=BOOLEAN>
>> +
>> +(HVM/x86 only) Specifies that the VM would force to check and try to
>
> s/force/forced/

I guess you're saying 'be forced'.

>> +reserve all reserved device memory, like RMRR, associated to the PCI
>> +device. False (0) by default.
>
> Not sure I understand. How would the VM be forced to do this? Or is
> it that the hvmloader would force to do this? And if it fails (as you

Yes.

> say 'try') ? What then?

In most cases we can reserve these regions but if these RMRR regions 
overlap with some fixed range, like guest BIOS, we can't succeed in this 
case.

>
>> +
>>   =back
>>
>>   =back
>> diff --git a/docs/misc/vtd.txt b/docs/misc/vtd.txt
>> index 9af0e99..23544d5 100644
>> --- a/docs/misc/vtd.txt
>> +++ b/docs/misc/vtd.txt
>> @@ -111,6 +111,21 @@ in the config file:
>>   To override for a specific device:
>>   	pci = [ '01:00.0,msitranslate=0', '03:00.0' ]
>>
>> +RDM, 'reserved device memory', for PCI Device Passthrough
>> +---------------------------------------------------------
>> +
>> +The BIOS controls some devices in terms of some reginos of memory used for
>
> Could you elaborate what 'some devices' are? Network cards? GPUs? What
> are the most commons ones.

Some legacy USB device to perform PS2 emulation, and GPU has a stolen 
memory as I remember.

>
> s/reginos/regions/

Fixed.

>
> And by regions you mean BAR regions?

No. I guess you want to know some background about RMRR :)

There's a good brief description in Linux:

What is RMRR?
-------------

There are some devices the BIOS controls, for e.g USB devices to perform
PS2 emulation. The regions of memory used for these devices are marked
reserved in the e820 map. When we turn on DMA translation, DMA to those
regions will fail. Hence BIOS uses RMRR to specify these regions along with
devices that need to access these regions. OS is expected to setup
unity mappings for these regions for these devices to access these regions.

>
>> +these devices. This kind of region should be reserved before creating a VM
>> +to make sure they are not occupied by RAM/MMIO to conflict, and also we can
>
> You said 'This' but here you are using the plural ' are'. IF you want it plural
> it needs to be 'These regions'

Thanks for your correction.

>> +create necessary IOMMU table successfully.
>> +
>> +To enable this globally, add "pci_rdmforce" in the config file:
>> +
>> +	pci_rdmforce = 1         (default is 0)
>
> The guest config file? Or /etc/xen/xl.conf ?

The guest config file. Here I just follow something about 
'pci_msitranslate' since they have that usage in common.

>
>> +
>> +Or just enable for a specific device:
>> +	pci = [ '01:00.0,rdmforce=1', '03:00.0' ]
>> +
>>
>>   Caveat on Conventional PCI Device Passthrough
>>   ---------------------------------------------
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h

[snip]

>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -34,6 +34,7 @@
>>   #include <xen/tasklet.h>
>>   #include <xsm/xsm.h>
>>   #include <asm/msi.h>
>> +#include <xen/stdbool.h>
>>
>>   struct pci_seg {
>>       struct list_head alldevs_list;
>> @@ -1553,6 +1554,44 @@ 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 = NULL;
>> +        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
>> +
>> +        if ( d == NULL )
>> +            return -ESRCH;
>> +
>
> What if this is called on an PV domain?

Currently we just support this in HVM, so I'd like to add this,

          if ( d == NULL )
              return -ESRCH;

+        ASSERT( is_hvm_domain(d) );
+

>
> You are also missing the XSM checks.

Just see this below.

>
> What if this is called multiple times. Is it OK to over-ride
> the 'pci_force' or should it stick once?

It should be fine since just xc/hvmloader need such an information while 
creating a VM.

And especially, currently we just call this one time to set. So why we 
need to call this again and again? I think if anyone want to extend such 
a case you're worrying, he should know any effect before he take a 
action, right?

>
>
>> +        d->arch.hvm_domain.pci_force =
>> +                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;
>
> Won't we crash here if this is called for PV guests?

After the line, 'ASSERT( is_hvm_domain(d) );', is added, this problem 
should be gone.

>
>> +        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;
>
> What if the 'num_pcidevs' has some bogus value. You need to check for that.

This value is grabbed from that existing interface, assign_device, so I 
mean this is already checked.

>
>
>> +        d->arch.hvm_domain.pcidevs = NULL;
>
> Please first free it. It might be that the toolstack
> is doing this a couple of times. You don't want to leak memory.
>

Okay,

+        if ( d->arch.hvm_domain.pcidevs )
+            xfree(d->arch.hvm_domain.pcidevs);

>
>> +
>> +        if ( xdsr->num_pcidevs )
>> +        {
>> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
>> +                                    xdsr->num_pcidevs);
>> +            if ( pcidevs == NULL )
>> +            {
>> +                rcu_unlock_domain(d);
>> +                return -ENOMEM;
>
> But you already have set 'num_pcidevs' to some value. This copying/check
> should be done before you modify 'd->arch.hvm_domain'...

This makes sense so I'll move down this fragment.

>> +            }
>> +
>> +            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
>> +                                 xdsr->num_pcidevs*sizeof(*pcidevs)) )
>> +            {
>> +                xfree(pcidevs);
>> +                rcu_unlock_domain(d);
>
> Ditto. You need to do these checks before you modify 'd->arch.hvm_domain'.
>
>> +                return -EFAULT;
>> +            }
>> +        }
>> +
>> +        d->arch.hvm_domain.pcidevs = pcidevs;
>> +        rcu_unlock_domain(d);
>> +    }
>> +        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 1152c3a..5e41e7a 100644
>> --- a/xen/drivers/passthrough/vtd/dmar.c
>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>> @@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>>                           "  RMRR region: base_addr %"PRIx64
>>                           " end_address %"PRIx64"\n",
>>                           rmrru->base_address, rmrru->end_address);
>> +            /*
>> +             * TODO: we may provide a precise paramter just to reserve
>
> s/paramter/parameter/

Fixed.

>> +             * RMRR range specific to one device.
>> +             */
>> +            dprintk(XENLOG_WARNING VTDPREFIX,
>> +                    "So please set pci_rdmforce to reserve these ranges"
>> +                    " if you need such a device in hotplug case.\n");

s/hotplug/passthrough

>
> 'Please set rdmforce to reserve ranges %lx->%lx if you plan to hotplug this device.'
>
> But then this is going to be a bit verbose, so perhaps:
>
> 'Ranges %lx-%lx need rdmforce to properly work.' ?

Its unnecessary to output range again since we already have such a print 
message here.

>
>> +
>>               acpi_register_rmrr_unit(rmrru);
>>           }
>>       }
>> diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
>> index 2757c7f..38530e5 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;
>>
>
> Maybe a comment explaining its purpose?

Okay.

/* Force to check/reserve Reserved Device Memory. */
     bool_t                  pci_force;

>
>> +    bool_t                  pci_force;
>> +    uint32_t                num_pcidevs;
>> +    struct xen_guest_pcidev_info      *pcidevs;
>> +
>
> You are also missing freeing of this in the hypervisor when the guest
> is destroyed. Please fix that.

You're right. I will go there next revision.

>
>>       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 57e2ed7..ba8970d 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -508,6 +508,25 @@ struct xen_domctl_get_device_group {
>>   typedef struct xen_domctl_get_device_group xen_domctl_get_device_group_t;
>>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_get_device_group_t);
>>
>> +/* Currently just one bit to indicate force to check Reserved Device Memory. */
>
> Not sure I understand. Did you mean:
>
> 'Check Reserved Device Memory'.

I can change this as '...force checking Reserved Device Memory.'

>
> What happens if you do not have this flag? What are the semantics
> of this hypercall - as in what will it mean.

If we have no this flag, these devices owned RMRR can't work in 
passthrough case.

>
>> +#define PCI_DEV_RDM_CHECK   0x1
>> +struct xen_guest_pcidev_info {
>> +    uint16_t    seg;
>> +    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;
>
> What is this 'flags' purpose compared to the 'pcidevs.flags'? Please
> explain.

I replied something to Kevin, and we just need a global flag so we can 
remove pcidevs.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);
>> +
>>   /* Pass-through interrupts: bind real irq -> hvm devfn. */
>>   /* XEN_DOMCTL_bind_pt_irq */
>>   /* XEN_DOMCTL_unbind_pt_irq */
>> @@ -1070,6 +1089,7 @@ struct xen_domctl {
>>   #define XEN_DOMCTL_setvnumainfo                  74
>>   #define XEN_DOMCTL_psr_cmt_op                    75
>>   #define XEN_DOMCTL_arm_configure_domain          76
>> +#define XEN_DOMCTL_set_rdm                       77
>>   #define XEN_DOMCTL_gdbsx_guestmemio            1000
>>   #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>>   #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
>> @@ -1135,6 +1155,7 @@ struct xen_domctl {
>>           struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>>           struct xen_domctl_vnuma             vnuma;
>>           struct xen_domctl_psr_cmt_op        psr_cmt_op;
>> +        struct xen_domctl_set_rdm           set_rdm;
>>           uint8_t                             pad[128];
>>       } u;
>>   };
>> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
>> index d48463f..5a760e2 100644
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -592,6 +592,7 @@ static int flask_domctl(struct domain *d, int cmd)
>>       case XEN_DOMCTL_test_assign_device:
>>       case XEN_DOMCTL_assign_device:
>>       case XEN_DOMCTL_deassign_device:
>> +    case XEN_DOMCTL_set_rdm:
>
> There is more to XSM than just this file..

But I don't see more other stuff, like XEN_DOMCTL_assign_device.

>
> Please compile with XSM enabled.

Anyway, I add XSM_ENABLE = y and FLASK_ENABLE = y in Config.mk then 
recompile, but looks good.

Anything I'm missing?

>>   #endif
>>           return 0;
>
>
> Also how does this work with 32-bit dom0s? Is there a need to use the
> compat layer?

Are you saying in xsm case? Others?

Actually this new DOMCTL is similar with XEN_DOMCTL_assign_device in 
some senses but I don't see such an issue you're pointing.

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 Dec 08 04:37:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 04: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 1Xxq3w-0000wU-RD; Mon, 08 Dec 2014 04:36:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <patel_mp@yahoo.co.in>) id 1Xxq3v-0000wN-9K
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 04:36:43 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	80/AE-27623-ADA25845; Mon, 08 Dec 2014 04:36:42 +0000
X-Env-Sender: patel_mp@yahoo.co.in
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418013397!11676998!1
X-Originating-IP: [106.10.149.8]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10265 invoked from network); 8 Dec 2014 04:36:40 -0000
Received: from nm12-vm8.bullet.mail.sg3.yahoo.com (HELO
	nm12-vm8.bullet.mail.sg3.yahoo.com) (106.10.149.8)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 04:36:40 -0000
Received: from [106.10.166.61] by nm12.bullet.mail.sg3.yahoo.com with NNFMP;
	08 Dec 2014 04:36:37 -0000
Received: from [106.10.151.171] by tm18.bullet.mail.sg3.yahoo.com with NNFMP;
	08 Dec 2014 04:36:36 -0000
Received: from [127.0.0.1] by omp1011.mail.sg3.yahoo.com with NNFMP;
	08 Dec 2014 04:36:36 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 985656.20944.bm@omp1011.mail.sg3.yahoo.com
Received: (qmail 87656 invoked by uid 60001); 8 Dec 2014 04:36:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024;
	t=1418013396; bh=0qciysYaK05wzvOuTs1d8huPuPlqFXa5ne4KSiKfdYo=;
	h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=iX1rzUdvI0XuCTLWhY4Iue6r4vxQ2f3wurVC/7NzAJMWMDItp52aFJOuHFsOXvww/Icm2et0wTe736G5muoq5ApBldUb3ufsgEkC5EcQG5LNtVcUBl9kQ3Nqo6HEOmTFraEIY8T6OH+OhaKXBy/JqvoL/T+FzLjd081/Bc4u42w=
X-YMail-OSG: n.1ybX0VM1kNJP84eFfaSufDEY7Yw.GiKwqPuKgohDkeipi
	MEF4blYWYyeTGacjEY9qUX.pkXUO7umx0bG4w9O8r1uXw0QNb3dIt_sE2Vr1
	2J1X5F8VyUZW2FOpMxaknauBU0snPQnRPtsgnaHbgLk1Dg3p55wJHXfx9HcB
	3l_xn67JYaUbInjhtkdEw1tUblvsNqk.6eyZzLmn4P2Q0NSlejegGTX7Gjsr
	EoblTjm2E8K1c9UtzvVif.9zrUqFH.z3.hRdh2CrC.R.sRPCyfzcuoZhN.8X
	kEFps1Jgf5QU0nKlQ4HpcRbwZBFCsQdE7DXFJRwhz4VRAUVdewbBMrTR3QYM
	kUAgjryZ3XBbXmTglCt0usBxXVTSHHzrh9E008FgMLbYgMn.Iah17SCl849c
	JOi2iXq_gVcO0t_TuyJ3YqaCNdoHXmkcbl.1Mp2dB0bKXqd4ZQ922soh8Qb7
	014gmoR4wNJgWBmQL5urfXJwGehs.zlQbkTjdLUbtsLknl14vBmbCdBC4Ci6
	j6UZ80a4FQM7uPuK8vtlVtEKeZe7AkXRnleEps.y.uvmF6gJ92x05P7E-
Received: from [202.129.240.131] by web190601.mail.sg3.yahoo.com via HTTP;
	Mon, 08 Dec 2014 12:36:36 SGT
X-Rocket-MIMEInfo: 002.001,
	CgogCmVycm9yIG9mIE1pZ3JhdGlvbiBmYWlsZWQgd2hlbiBtaWdyYXRpbmcgV2Vic2VydmVyIFZNIHdpdGggMTAwIGNvbm5lY2l0b25zIHVzaW5nIGh0dHBlcmYKCkZpcnN0IHRpbWUgaXQgZ2VuZXJhdHMgKGEgcGFydCBvZiBmb2xsd29pbmcgb3V0cHV0KToKCm1pZ3JhdGlvbiB0YXJnZXQ6IFRyYW5zZmVyIGNvbXBsZXRlLCByZXF1ZXN0aW5nIHBlcm1pc3Npb24gdG8gc3RhcnQgZG9tYWluLgptaWdyYXRpb24gc2VuZGVyOiBUYXJnZXQgaGFzIGFja25vd2xlZGdlZCB0cmFuc2Zlci4KbWlncmF0aW9uIHNlbmQBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.203.740
Message-ID: <1418013396.36972.YahooMailNeo@web190601.mail.sg3.yahoo.com>
Date: Mon, 8 Dec 2014 12:36:36 +0800
From: Minalkumar Patel <patel_mp@yahoo.co.in>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] error of VM Migration (xl toolstack) failed when
	migrating Webserver VM with 100 connecitons using httperf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Minalkumar Patel <patel_mp@yahoo.co.in>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5062347339745343632=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5062347339745343632==
Content-Type: multipart/alternative; boundary="-1762912605-465691142-1418013396=:36972"

---1762912605-465691142-1418013396=:36972
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0A=0A =0Aerror of Migration failed when migrating Webserver VM with 100 co=
nnecitons using httperf=0A=0AFirst time it generats (a part of follwoing ou=
tput):=0A=0Amigration target: Transfer complete, requesting permission to s=
tart domain.=0Amigration sender: Target has acknowledged transfer.=0Amigrat=
ion sender: Giving target permission to start.=0Amigration target: Got perm=
ission, starting domain.=0A[everything ok uptill now]=0Alibxl: error: libxl=
.c:321:libxl__domain_rename: domain with name "drbdvm1" already exists.=0Am=
igration target: Failure, destroying our copy.=0Amigration sender: Target r=
eports startup failure (status code 6).=0Amigration target: Cleanup OK, gra=
nting sender permission to resume.=0Amigration sender: Trying to resume at =
our end.=0Alibxl: debug: libxl.c:435:libxl_domain_resume: ao 0xa91bf0: crea=
te: how=3D(nil) callback=3D(nil) poller=3D0xa91c50=0Axc: error: Cannot resu=
me uncooperative HVM guests: Internal error         =0Alibxl: error: libxl.=
c:404:libxl__domain_resume: xc_domain_resume failed for domain 10: No such =
file or directory=0Alibxl: debug: libxl_event.c:1499:libxl__ao_complete: ao=
 0xa91bf0: complete, rc=3D-3=0Alibxl: debug: libxl.c:438:libxl_domain_resum=
e: ao 0xa91bf0: inprogress: poller=3D0xa91c50, flags=3Dic=0Alibxl: debug: l=
ibxl_event.c:1471:libxl__ao__destroy: ao 0xa91bf0: destroy =0AMigration fai=
led due to problems at target.=0A=0ASecond time it generates (a part of fol=
lwing output):=0A=0Axc: detail: Start last iteration=0A[everything ok uptil=
l now]                                           =0Alibxl: debug: libxl_dom=
.c:933:libxl__domain_suspend_common_callback: issuing PVHVM suspend request=
 via XenBus control node=0Alibxl: debug: libxl_dom.c:937:libxl__domain_susp=
end_common_callback: wait for the guest to acknowledge suspend request=0Ali=
bxl: error: libxl_dom.c:958:libxl__domain_suspend_common_callback: guest di=
dn't acknowledge suspend, cancelling request=0Alibxl: error: libxl_dom.c:98=
0:libxl__domain_suspend_common_callback: guest didn't acknowledge suspend, =
request cancelled=0Axc: error: Suspend request failed: Internal error      =
                       =0Axc: error: Domain appears not to have suspended: =
Internal error               =0Alibxl: debug: libxl_event.c:512:libxl__ev_x=
swatch_register: watch w=3D0x21c5f80 wpath=3D/local/domain/0/device-model/1=
0/logdirty/ret token=3D3/1: register slotnum=3D3=0Alibxl: debug: libxl_even=
t.c:457:watchfd_callback: watch w=3D0x21c5f80 wpath=3D/local/domain/0/devic=
e-model/10/logdirty/ret token=3D3/1: event epath=3D/local/domain/0/device-m=
odel/10/logdirty/ret=0Alibxl: debug: libxl_event.c:457:watchfd_callback: wa=
tch w=3D0x21c5f80 wpath=3D/local/domain/0/device-model/10/logdirty/ret toke=
n=3D3/1: event epath=3D/local/domain/0/device-model/10/logdirty/ret=0Alibxl=
: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=3D0x21c5f8=
0 wpath=3D/local/domain/0/device-model/10/logdirty/ret token=3D3/1: deregis=
ter slotnum=3D3=0Alibxl: debug: libxl_event.c:426:watchfd_callback: watch e=
path=3D/local/domain/0/device-model/10/logdirty/ret token=3D3/1: empty slot=
=0Axc: detail: Save exit rc=3D1                                            =
        =0Alibxl-save-helper: debug: complete r=3D1: No such device        =
                =0Alibxl: error: libxl_dom.c:1266:libxl__xc_domain_save_don=
e: saving domain: domain did not respond to suspend request: No such device=
=0Alibxl: debug: libxl_event.c:1499:libxl__ao_complete: ao 0x21c5bf0: compl=
ete, rc=3D-8=0Alibxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0x21=
c5bf0: destroy    =0Amigration sender: libxl_domain_suspend failed (rc=3D-8=
)=0Axc: error: 0-length read: Internal error=0Axc: error: read_exact_timed =
failed (read rc: 0, errno: 0): Internal error=0Axc: error: Error when readi=
ng batch size (0 =3D Success): Internal error=0Axc: error: Error when readi=
ng batch (0 =3D Success): Internal error=0Alibxl: error: libxl_create.c:820=
:libxl__xc_domain_restore_done: restoring domain: Resource temporarily unav=
ailable=0Alibxl: error: libxl_create.c:902:domcreate_rebuild_done: cannot (=
re-)build domain: -3=0Alibxl: error: libxl.c:1394:libxl__destroy_domid: non=
-existant domain 6=0Alibxl: error: libxl.c:1358:domain_destroy_callback: un=
able to destroy guest with domid 6=0Alibxl: error: libxl_create.c:1153:domc=
reate_destruction_cb: unable to destroy domain 6 following failed creation=
=0Amigration target: Domain creation failed (code -3).=0Alibxl: info: libxl=
_exec.c:118:libxl_report_child_exitstatus: migration target process [11104]=
 exited with error status 3=0AMigration failed, failed to suspend at sender=
.=0A=0A=0AWhat goes wrong please tell me?It also shows migration of Webserv=
er VM at destination  and it can be manually started and in worknig conditi=
on. But =0Aat sender, VM  is still continueing  webserver based httperf con=
nections and doesn't turn off....so i can have VM at both side ..why sender=
 is not stopping activity?=0A=0ARegards,
---1762912605-465691142-1418013396=:36972
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;fo=
nt-size:12px"><div style=3D"" class=3D""><span style=3D"" class=3D""><br st=
yle=3D""></span></div><div style=3D"" class=3D"">&nbsp;</div><div style=3D"=
" class=3D"">error of Migration failed when migrating Webserver VM with 100=
 connecitons using httperf<br style=3D"" class=3D""><br style=3D"" class=3D=
"">First time it generats (a part of follwoing output):<br style=3D"" class=
=3D""><br style=3D"" class=3D"">migration target: Transfer complete, reques=
ting permission to start domain.<br style=3D"" class=3D"">migration sender:=
 Target has acknowledged transfer.<br style=3D"" class=3D"">migration sende=
r: Giving target permission to start.<br style=3D"" class=3D"">migration ta=
rget: Got permission, starting domain.<br style=3D"" class=3D"">[everything=
 ok uptill now]<br style=3D"" class=3D"">libxl: error: libxl.c:321:libxl__d=
omain_rename: domain with name "drbdvm1" already
 exists.<br style=3D"" class=3D"">migration target: Failure, destroying our=
 copy.<br style=3D"" class=3D"">migration sender: Target reports startup fa=
ilure (status code 6).<br style=3D"" class=3D"">migration target: Cleanup O=
K, granting sender permission to resume.<br style=3D"" class=3D"">migration=
 sender: Trying to resume at our end.<br style=3D"" class=3D"">libxl: debug=
: libxl.c:435:libxl_domain_resume: ao 0xa91bf0: create: how=3D(nil) callbac=
k=3D(nil) poller=3D0xa91c50<br style=3D"" class=3D"">xc: error: Cannot resu=
me uncooperative HVM guests: Internal error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; <br style=3D"" class=3D"">libxl: error: libxl.c:404:libxl_=
_domain_resume: xc_domain_resume failed for domain 10: No such file or dire=
ctory<br style=3D"" class=3D"">libxl: debug: libxl_event.c:1499:libxl__ao_c=
omplete: ao 0xa91bf0: complete, rc=3D-3<br style=3D"" class=3D"">libxl: deb=
ug: libxl.c:438:libxl_domain_resume: ao 0xa91bf0: inprogress: poller=3D0xa9=
1c50, flags=3Dic<br style=3D""
 class=3D"">libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0xa91bf=
0: destroy <br style=3D"" class=3D"">Migration failed due to problems at ta=
rget.<br style=3D"" class=3D""><br style=3D"" class=3D"">Second time it gen=
erates (a part of follwing output):<br style=3D"" class=3D""><br style=3D""=
 class=3D"">xc: detail: Start last iteration<br style=3D"" class=3D"">[ever=
ything ok uptill now]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br style=3D"" class=3D"">=
libxl: debug: libxl_dom.c:933:libxl__domain_suspend_common_callback: issuin=
g PVHVM suspend request via XenBus control node<br style=3D"" class=3D"">li=
bxl: debug: libxl_dom.c:937:libxl__domain_suspend_common_callback: wait for=
 the guest to acknowledge suspend request<br style=3D"" class=3D"">libxl: e=
rror:
 libxl_dom.c:958:libxl__domain_suspend_common_callback: guest didn't acknow=
ledge suspend, cancelling request<br style=3D"" class=3D"">libxl: error: li=
bxl_dom.c:980:libxl__domain_suspend_common_callback: guest didn't acknowled=
ge suspend, request cancelled<br style=3D"" class=3D"">xc: error: Suspend r=
equest failed: Internal error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br style=3D"" class=3D"">x=
c: error: Domain appears not to have suspended: Internal error&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br=
 style=3D"" class=3D"">libxl: debug: libxl_event.c:512:libxl__ev_xswatch_re=
gister: watch w=3D0x21c5f80 wpath=3D/local/domain/0/device-model/10/logdirt=
y/ret token=3D3/1: register slotnum=3D3<br style=3D"" class=3D"">libxl: deb=
ug: libxl_event.c:457:watchfd_callback: watch w=3D0x21c5f80
 wpath=3D/local/domain/0/device-model/10/logdirty/ret token=3D3/1: event ep=
ath=3D/local/domain/0/device-model/10/logdirty/ret<br style=3D"" class=3D""=
>libxl: debug: libxl_event.c:457:watchfd_callback: watch w=3D0x21c5f80 wpat=
h=3D/local/domain/0/device-model/10/logdirty/ret token=3D3/1: event epath=
=3D/local/domain/0/device-model/10/logdirty/ret<br style=3D"" class=3D"">li=
bxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=3D0x21c=
5f80 wpath=3D/local/domain/0/device-model/10/logdirty/ret token=3D3/1: dere=
gister slotnum=3D3<br style=3D"" class=3D"">libxl: debug: libxl_event.c:426=
:watchfd_callback: watch epath=3D/local/domain/0/device-model/10/logdirty/r=
et token=3D3/1: empty slot<br style=3D"" class=3D"">xc: detail: Save exit
 rc=3D1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; <br style=3D"" class=3D"">libxl-save-helper: debug: complete =
r=3D1: No such device&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; <br style=3D"" class=3D"">libxl: error: libxl_dom.c:1266:libxl__x=
c_domain_save_done: saving domain: domain did not respond to suspend reques=
t: No such device<br style=3D"" class=3D"">libxl: debug: libxl_event.c:1499=
:libxl__ao_complete: ao 0x21c5bf0: complete, rc=3D-8<br style=3D"" class=3D=
"">libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0x21c5bf0: destr=
oy&nbsp;&nbsp;&nbsp; <br style=3D"" class=3D"">migration sender: libxl_doma=
in_suspend failed
 (rc=3D-8)<br style=3D"" class=3D"">xc: error: 0-length read: Internal erro=
r<br style=3D"" class=3D"">xc: error: read_exact_timed failed (read rc: 0, =
errno: 0): Internal error<br style=3D"" class=3D"">xc: error: Error when re=
ading batch size (0 =3D Success): Internal error<br style=3D"" class=3D"">x=
c: error: Error when reading batch (0 =3D Success): Internal error<br style=
=3D"" class=3D"">libxl: error: libxl_create.c:820:libxl__xc_domain_restore_=
done: restoring domain: Resource temporarily unavailable<br style=3D"" clas=
s=3D"">libxl: error: libxl_create.c:902:domcreate_rebuild_done: cannot (re-=
)build domain: -3<br style=3D"" class=3D"">libxl: error: libxl.c:1394:libxl=
__destroy_domid: non-existant domain 6<br style=3D"" class=3D"">libxl: erro=
r: libxl.c:1358:domain_destroy_callback: unable to destroy guest with domid=
 6<br style=3D"" class=3D"">libxl: error: libxl_create.c:1153:domcreate_des=
truction_cb: unable to destroy domain 6 following failed creation<br style=
=3D"" class=3D"">migration target:
 Domain creation failed (code -3).<br style=3D"" class=3D"">libxl: info: li=
bxl_exec.c:118:libxl_report_child_exitstatus: migration target process [111=
04] exited with error status 3<br style=3D"" class=3D"">Migration failed, f=
ailed to suspend at sender.<br style=3D"" class=3D""><br style=3D"" class=
=3D""><br style=3D"" class=3D"">What goes wrong please tell me?It also show=
s migration of Webserver VM at destination&nbsp; and it can be manually sta=
rted and in worknig condition. But <br style=3D"" class=3D"">at sender, VM&=
nbsp; is still continueing&nbsp; webserver based httperf connections and do=
esn't turn off....so i can have VM at both side ..why sender is not stoppin=
g activity?<br><br>Regards,<br style=3D"" class=3D""></div><div style=3D"" =
class=3D"">&nbsp;</div></div></body></html>
---1762912605-465691142-1418013396=:36972--


--===============5062347339745343632==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5062347339745343632==--


From xen-devel-bounces@lists.xen.org Mon Dec 08 04:37:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 04: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 1Xxq3w-0000wU-RD; Mon, 08 Dec 2014 04:36:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <patel_mp@yahoo.co.in>) id 1Xxq3v-0000wN-9K
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 04:36:43 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	80/AE-27623-ADA25845; Mon, 08 Dec 2014 04:36:42 +0000
X-Env-Sender: patel_mp@yahoo.co.in
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418013397!11676998!1
X-Originating-IP: [106.10.149.8]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10265 invoked from network); 8 Dec 2014 04:36:40 -0000
Received: from nm12-vm8.bullet.mail.sg3.yahoo.com (HELO
	nm12-vm8.bullet.mail.sg3.yahoo.com) (106.10.149.8)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 04:36:40 -0000
Received: from [106.10.166.61] by nm12.bullet.mail.sg3.yahoo.com with NNFMP;
	08 Dec 2014 04:36:37 -0000
Received: from [106.10.151.171] by tm18.bullet.mail.sg3.yahoo.com with NNFMP;
	08 Dec 2014 04:36:36 -0000
Received: from [127.0.0.1] by omp1011.mail.sg3.yahoo.com with NNFMP;
	08 Dec 2014 04:36:36 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 985656.20944.bm@omp1011.mail.sg3.yahoo.com
Received: (qmail 87656 invoked by uid 60001); 8 Dec 2014 04:36:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024;
	t=1418013396; bh=0qciysYaK05wzvOuTs1d8huPuPlqFXa5ne4KSiKfdYo=;
	h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=iX1rzUdvI0XuCTLWhY4Iue6r4vxQ2f3wurVC/7NzAJMWMDItp52aFJOuHFsOXvww/Icm2et0wTe736G5muoq5ApBldUb3ufsgEkC5EcQG5LNtVcUBl9kQ3Nqo6HEOmTFraEIY8T6OH+OhaKXBy/JqvoL/T+FzLjd081/Bc4u42w=
X-YMail-OSG: n.1ybX0VM1kNJP84eFfaSufDEY7Yw.GiKwqPuKgohDkeipi
	MEF4blYWYyeTGacjEY9qUX.pkXUO7umx0bG4w9O8r1uXw0QNb3dIt_sE2Vr1
	2J1X5F8VyUZW2FOpMxaknauBU0snPQnRPtsgnaHbgLk1Dg3p55wJHXfx9HcB
	3l_xn67JYaUbInjhtkdEw1tUblvsNqk.6eyZzLmn4P2Q0NSlejegGTX7Gjsr
	EoblTjm2E8K1c9UtzvVif.9zrUqFH.z3.hRdh2CrC.R.sRPCyfzcuoZhN.8X
	kEFps1Jgf5QU0nKlQ4HpcRbwZBFCsQdE7DXFJRwhz4VRAUVdewbBMrTR3QYM
	kUAgjryZ3XBbXmTglCt0usBxXVTSHHzrh9E008FgMLbYgMn.Iah17SCl849c
	JOi2iXq_gVcO0t_TuyJ3YqaCNdoHXmkcbl.1Mp2dB0bKXqd4ZQ922soh8Qb7
	014gmoR4wNJgWBmQL5urfXJwGehs.zlQbkTjdLUbtsLknl14vBmbCdBC4Ci6
	j6UZ80a4FQM7uPuK8vtlVtEKeZe7AkXRnleEps.y.uvmF6gJ92x05P7E-
Received: from [202.129.240.131] by web190601.mail.sg3.yahoo.com via HTTP;
	Mon, 08 Dec 2014 12:36:36 SGT
X-Rocket-MIMEInfo: 002.001,
	CgogCmVycm9yIG9mIE1pZ3JhdGlvbiBmYWlsZWQgd2hlbiBtaWdyYXRpbmcgV2Vic2VydmVyIFZNIHdpdGggMTAwIGNvbm5lY2l0b25zIHVzaW5nIGh0dHBlcmYKCkZpcnN0IHRpbWUgaXQgZ2VuZXJhdHMgKGEgcGFydCBvZiBmb2xsd29pbmcgb3V0cHV0KToKCm1pZ3JhdGlvbiB0YXJnZXQ6IFRyYW5zZmVyIGNvbXBsZXRlLCByZXF1ZXN0aW5nIHBlcm1pc3Npb24gdG8gc3RhcnQgZG9tYWluLgptaWdyYXRpb24gc2VuZGVyOiBUYXJnZXQgaGFzIGFja25vd2xlZGdlZCB0cmFuc2Zlci4KbWlncmF0aW9uIHNlbmQBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.203.740
Message-ID: <1418013396.36972.YahooMailNeo@web190601.mail.sg3.yahoo.com>
Date: Mon, 8 Dec 2014 12:36:36 +0800
From: Minalkumar Patel <patel_mp@yahoo.co.in>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] error of VM Migration (xl toolstack) failed when
	migrating Webserver VM with 100 connecitons using httperf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Minalkumar Patel <patel_mp@yahoo.co.in>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5062347339745343632=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5062347339745343632==
Content-Type: multipart/alternative; boundary="-1762912605-465691142-1418013396=:36972"

---1762912605-465691142-1418013396=:36972
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0A=0A =0Aerror of Migration failed when migrating Webserver VM with 100 co=
nnecitons using httperf=0A=0AFirst time it generats (a part of follwoing ou=
tput):=0A=0Amigration target: Transfer complete, requesting permission to s=
tart domain.=0Amigration sender: Target has acknowledged transfer.=0Amigrat=
ion sender: Giving target permission to start.=0Amigration target: Got perm=
ission, starting domain.=0A[everything ok uptill now]=0Alibxl: error: libxl=
.c:321:libxl__domain_rename: domain with name "drbdvm1" already exists.=0Am=
igration target: Failure, destroying our copy.=0Amigration sender: Target r=
eports startup failure (status code 6).=0Amigration target: Cleanup OK, gra=
nting sender permission to resume.=0Amigration sender: Trying to resume at =
our end.=0Alibxl: debug: libxl.c:435:libxl_domain_resume: ao 0xa91bf0: crea=
te: how=3D(nil) callback=3D(nil) poller=3D0xa91c50=0Axc: error: Cannot resu=
me uncooperative HVM guests: Internal error         =0Alibxl: error: libxl.=
c:404:libxl__domain_resume: xc_domain_resume failed for domain 10: No such =
file or directory=0Alibxl: debug: libxl_event.c:1499:libxl__ao_complete: ao=
 0xa91bf0: complete, rc=3D-3=0Alibxl: debug: libxl.c:438:libxl_domain_resum=
e: ao 0xa91bf0: inprogress: poller=3D0xa91c50, flags=3Dic=0Alibxl: debug: l=
ibxl_event.c:1471:libxl__ao__destroy: ao 0xa91bf0: destroy =0AMigration fai=
led due to problems at target.=0A=0ASecond time it generates (a part of fol=
lwing output):=0A=0Axc: detail: Start last iteration=0A[everything ok uptil=
l now]                                           =0Alibxl: debug: libxl_dom=
.c:933:libxl__domain_suspend_common_callback: issuing PVHVM suspend request=
 via XenBus control node=0Alibxl: debug: libxl_dom.c:937:libxl__domain_susp=
end_common_callback: wait for the guest to acknowledge suspend request=0Ali=
bxl: error: libxl_dom.c:958:libxl__domain_suspend_common_callback: guest di=
dn't acknowledge suspend, cancelling request=0Alibxl: error: libxl_dom.c:98=
0:libxl__domain_suspend_common_callback: guest didn't acknowledge suspend, =
request cancelled=0Axc: error: Suspend request failed: Internal error      =
                       =0Axc: error: Domain appears not to have suspended: =
Internal error               =0Alibxl: debug: libxl_event.c:512:libxl__ev_x=
swatch_register: watch w=3D0x21c5f80 wpath=3D/local/domain/0/device-model/1=
0/logdirty/ret token=3D3/1: register slotnum=3D3=0Alibxl: debug: libxl_even=
t.c:457:watchfd_callback: watch w=3D0x21c5f80 wpath=3D/local/domain/0/devic=
e-model/10/logdirty/ret token=3D3/1: event epath=3D/local/domain/0/device-m=
odel/10/logdirty/ret=0Alibxl: debug: libxl_event.c:457:watchfd_callback: wa=
tch w=3D0x21c5f80 wpath=3D/local/domain/0/device-model/10/logdirty/ret toke=
n=3D3/1: event epath=3D/local/domain/0/device-model/10/logdirty/ret=0Alibxl=
: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=3D0x21c5f8=
0 wpath=3D/local/domain/0/device-model/10/logdirty/ret token=3D3/1: deregis=
ter slotnum=3D3=0Alibxl: debug: libxl_event.c:426:watchfd_callback: watch e=
path=3D/local/domain/0/device-model/10/logdirty/ret token=3D3/1: empty slot=
=0Axc: detail: Save exit rc=3D1                                            =
        =0Alibxl-save-helper: debug: complete r=3D1: No such device        =
                =0Alibxl: error: libxl_dom.c:1266:libxl__xc_domain_save_don=
e: saving domain: domain did not respond to suspend request: No such device=
=0Alibxl: debug: libxl_event.c:1499:libxl__ao_complete: ao 0x21c5bf0: compl=
ete, rc=3D-8=0Alibxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0x21=
c5bf0: destroy    =0Amigration sender: libxl_domain_suspend failed (rc=3D-8=
)=0Axc: error: 0-length read: Internal error=0Axc: error: read_exact_timed =
failed (read rc: 0, errno: 0): Internal error=0Axc: error: Error when readi=
ng batch size (0 =3D Success): Internal error=0Axc: error: Error when readi=
ng batch (0 =3D Success): Internal error=0Alibxl: error: libxl_create.c:820=
:libxl__xc_domain_restore_done: restoring domain: Resource temporarily unav=
ailable=0Alibxl: error: libxl_create.c:902:domcreate_rebuild_done: cannot (=
re-)build domain: -3=0Alibxl: error: libxl.c:1394:libxl__destroy_domid: non=
-existant domain 6=0Alibxl: error: libxl.c:1358:domain_destroy_callback: un=
able to destroy guest with domid 6=0Alibxl: error: libxl_create.c:1153:domc=
reate_destruction_cb: unable to destroy domain 6 following failed creation=
=0Amigration target: Domain creation failed (code -3).=0Alibxl: info: libxl=
_exec.c:118:libxl_report_child_exitstatus: migration target process [11104]=
 exited with error status 3=0AMigration failed, failed to suspend at sender=
.=0A=0A=0AWhat goes wrong please tell me?It also shows migration of Webserv=
er VM at destination  and it can be manually started and in worknig conditi=
on. But =0Aat sender, VM  is still continueing  webserver based httperf con=
nections and doesn't turn off....so i can have VM at both side ..why sender=
 is not stopping activity?=0A=0ARegards,
---1762912605-465691142-1418013396=:36972
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;fo=
nt-size:12px"><div style=3D"" class=3D""><span style=3D"" class=3D""><br st=
yle=3D""></span></div><div style=3D"" class=3D"">&nbsp;</div><div style=3D"=
" class=3D"">error of Migration failed when migrating Webserver VM with 100=
 connecitons using httperf<br style=3D"" class=3D""><br style=3D"" class=3D=
"">First time it generats (a part of follwoing output):<br style=3D"" class=
=3D""><br style=3D"" class=3D"">migration target: Transfer complete, reques=
ting permission to start domain.<br style=3D"" class=3D"">migration sender:=
 Target has acknowledged transfer.<br style=3D"" class=3D"">migration sende=
r: Giving target permission to start.<br style=3D"" class=3D"">migration ta=
rget: Got permission, starting domain.<br style=3D"" class=3D"">[everything=
 ok uptill now]<br style=3D"" class=3D"">libxl: error: libxl.c:321:libxl__d=
omain_rename: domain with name "drbdvm1" already
 exists.<br style=3D"" class=3D"">migration target: Failure, destroying our=
 copy.<br style=3D"" class=3D"">migration sender: Target reports startup fa=
ilure (status code 6).<br style=3D"" class=3D"">migration target: Cleanup O=
K, granting sender permission to resume.<br style=3D"" class=3D"">migration=
 sender: Trying to resume at our end.<br style=3D"" class=3D"">libxl: debug=
: libxl.c:435:libxl_domain_resume: ao 0xa91bf0: create: how=3D(nil) callbac=
k=3D(nil) poller=3D0xa91c50<br style=3D"" class=3D"">xc: error: Cannot resu=
me uncooperative HVM guests: Internal error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; <br style=3D"" class=3D"">libxl: error: libxl.c:404:libxl_=
_domain_resume: xc_domain_resume failed for domain 10: No such file or dire=
ctory<br style=3D"" class=3D"">libxl: debug: libxl_event.c:1499:libxl__ao_c=
omplete: ao 0xa91bf0: complete, rc=3D-3<br style=3D"" class=3D"">libxl: deb=
ug: libxl.c:438:libxl_domain_resume: ao 0xa91bf0: inprogress: poller=3D0xa9=
1c50, flags=3Dic<br style=3D""
 class=3D"">libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0xa91bf=
0: destroy <br style=3D"" class=3D"">Migration failed due to problems at ta=
rget.<br style=3D"" class=3D""><br style=3D"" class=3D"">Second time it gen=
erates (a part of follwing output):<br style=3D"" class=3D""><br style=3D""=
 class=3D"">xc: detail: Start last iteration<br style=3D"" class=3D"">[ever=
ything ok uptill now]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br style=3D"" class=3D"">=
libxl: debug: libxl_dom.c:933:libxl__domain_suspend_common_callback: issuin=
g PVHVM suspend request via XenBus control node<br style=3D"" class=3D"">li=
bxl: debug: libxl_dom.c:937:libxl__domain_suspend_common_callback: wait for=
 the guest to acknowledge suspend request<br style=3D"" class=3D"">libxl: e=
rror:
 libxl_dom.c:958:libxl__domain_suspend_common_callback: guest didn't acknow=
ledge suspend, cancelling request<br style=3D"" class=3D"">libxl: error: li=
bxl_dom.c:980:libxl__domain_suspend_common_callback: guest didn't acknowled=
ge suspend, request cancelled<br style=3D"" class=3D"">xc: error: Suspend r=
equest failed: Internal error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br style=3D"" class=3D"">x=
c: error: Domain appears not to have suspended: Internal error&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br=
 style=3D"" class=3D"">libxl: debug: libxl_event.c:512:libxl__ev_xswatch_re=
gister: watch w=3D0x21c5f80 wpath=3D/local/domain/0/device-model/10/logdirt=
y/ret token=3D3/1: register slotnum=3D3<br style=3D"" class=3D"">libxl: deb=
ug: libxl_event.c:457:watchfd_callback: watch w=3D0x21c5f80
 wpath=3D/local/domain/0/device-model/10/logdirty/ret token=3D3/1: event ep=
ath=3D/local/domain/0/device-model/10/logdirty/ret<br style=3D"" class=3D""=
>libxl: debug: libxl_event.c:457:watchfd_callback: watch w=3D0x21c5f80 wpat=
h=3D/local/domain/0/device-model/10/logdirty/ret token=3D3/1: event epath=
=3D/local/domain/0/device-model/10/logdirty/ret<br style=3D"" class=3D"">li=
bxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=3D0x21c=
5f80 wpath=3D/local/domain/0/device-model/10/logdirty/ret token=3D3/1: dere=
gister slotnum=3D3<br style=3D"" class=3D"">libxl: debug: libxl_event.c:426=
:watchfd_callback: watch epath=3D/local/domain/0/device-model/10/logdirty/r=
et token=3D3/1: empty slot<br style=3D"" class=3D"">xc: detail: Save exit
 rc=3D1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; <br style=3D"" class=3D"">libxl-save-helper: debug: complete =
r=3D1: No such device&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; <br style=3D"" class=3D"">libxl: error: libxl_dom.c:1266:libxl__x=
c_domain_save_done: saving domain: domain did not respond to suspend reques=
t: No such device<br style=3D"" class=3D"">libxl: debug: libxl_event.c:1499=
:libxl__ao_complete: ao 0x21c5bf0: complete, rc=3D-8<br style=3D"" class=3D=
"">libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0x21c5bf0: destr=
oy&nbsp;&nbsp;&nbsp; <br style=3D"" class=3D"">migration sender: libxl_doma=
in_suspend failed
 (rc=3D-8)<br style=3D"" class=3D"">xc: error: 0-length read: Internal erro=
r<br style=3D"" class=3D"">xc: error: read_exact_timed failed (read rc: 0, =
errno: 0): Internal error<br style=3D"" class=3D"">xc: error: Error when re=
ading batch size (0 =3D Success): Internal error<br style=3D"" class=3D"">x=
c: error: Error when reading batch (0 =3D Success): Internal error<br style=
=3D"" class=3D"">libxl: error: libxl_create.c:820:libxl__xc_domain_restore_=
done: restoring domain: Resource temporarily unavailable<br style=3D"" clas=
s=3D"">libxl: error: libxl_create.c:902:domcreate_rebuild_done: cannot (re-=
)build domain: -3<br style=3D"" class=3D"">libxl: error: libxl.c:1394:libxl=
__destroy_domid: non-existant domain 6<br style=3D"" class=3D"">libxl: erro=
r: libxl.c:1358:domain_destroy_callback: unable to destroy guest with domid=
 6<br style=3D"" class=3D"">libxl: error: libxl_create.c:1153:domcreate_des=
truction_cb: unable to destroy domain 6 following failed creation<br style=
=3D"" class=3D"">migration target:
 Domain creation failed (code -3).<br style=3D"" class=3D"">libxl: info: li=
bxl_exec.c:118:libxl_report_child_exitstatus: migration target process [111=
04] exited with error status 3<br style=3D"" class=3D"">Migration failed, f=
ailed to suspend at sender.<br style=3D"" class=3D""><br style=3D"" class=
=3D""><br style=3D"" class=3D"">What goes wrong please tell me?It also show=
s migration of Webserver VM at destination&nbsp; and it can be manually sta=
rted and in worknig condition. But <br style=3D"" class=3D"">at sender, VM&=
nbsp; is still continueing&nbsp; webserver based httperf connections and do=
esn't turn off....so i can have VM at both side ..why sender is not stoppin=
g activity?<br><br>Regards,<br style=3D"" class=3D""></div><div style=3D"" =
class=3D"">&nbsp;</div></div></body></html>
---1762912605-465691142-1418013396=:36972--


--===============5062347339745343632==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5062347339745343632==--


From xen-devel-bounces@lists.xen.org Mon Dec 08 05:32:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 05: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 1Xxqvp-0002jK-SR; Mon, 08 Dec 2014 05:32: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 1Xxqvo-0002jF-NI
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 05:32:24 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	32/A9-02702-8E735845; Mon, 08 Dec 2014 05:32:24 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418016743!13590677!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 3083 invoked from network); 8 Dec 2014 05:32: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; 8 Dec 2014 05:32:23 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 88039AC40;
	Mon,  8 Dec 2014 05:32:21 +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
Date: Mon,  8 Dec 2014 06:32:19 +0100
Message-Id: <1418016739-19305-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] xen: annotate
	xen_set_identity_and_remap_chunk() with __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

Commit 5b8e7d80542487ff1bf17b4cf2922a01dee13d3a removed the __init
annotation from xen_set_identity_and_remap_chunk(). Add it again.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 12cd199..dfd77de 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -368,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 xen_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 *released)
-- 
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 Mon Dec 08 05:32:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 05: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 1Xxqvp-0002jK-SR; Mon, 08 Dec 2014 05:32: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 1Xxqvo-0002jF-NI
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 05:32:24 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	32/A9-02702-8E735845; Mon, 08 Dec 2014 05:32:24 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418016743!13590677!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 3083 invoked from network); 8 Dec 2014 05:32: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; 8 Dec 2014 05:32:23 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 88039AC40;
	Mon,  8 Dec 2014 05:32:21 +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
Date: Mon,  8 Dec 2014 06:32:19 +0100
Message-Id: <1418016739-19305-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] xen: annotate
	xen_set_identity_and_remap_chunk() with __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

Commit 5b8e7d80542487ff1bf17b4cf2922a01dee13d3a removed the __init
annotation from xen_set_identity_and_remap_chunk(). Add it again.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 12cd199..dfd77de 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -368,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 xen_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 *released)
-- 
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 Mon Dec 08 06:07:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 06: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 1XxrSu-0003dq-RN; Mon, 08 Dec 2014 06:06:36 +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 1XxrSs-0003dl-TL
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 06:06:35 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	D6/39-18267-AEF35845; Mon, 08 Dec 2014 06:06:34 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418018791!11722846!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21281 invoked from network); 8 Dec 2014 06:06:32 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-5.tower-31.messagelabs.com with SMTP;
	8 Dec 2014 06:06:32 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 07 Dec 2014 22:04:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,536,1413270000"; d="scan'208";a="650096380"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 07 Dec 2014 22:06:27 -0800
Message-ID: <54853FE3.9030703@intel.com>
Date: Mon, 08 Dec 2014 14:06:27 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<54808CC3020000780004CCC8@mail.emea.novell.com>
In-Reply-To: <54808CC3020000780004CCC8@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/4 23:33, Jan Beulich wrote:
>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -34,6 +34,7 @@
>>   #include <xen/tasklet.h>
>>   #include <xsm/xsm.h>
>>   #include <asm/msi.h>
>> +#include <xen/stdbool.h>
>
> Please don't - we use bool_t in the hypervisor, not bool. The header

Yes.

> only exists for source code shared with the tools.

Looks this could be fine,

d->arch.hvm_domain.pci_force = xdsr->flags & PCI_DEV_RDM_CHECK;

>
>> @@ -1553,6 +1554,44 @@ 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 = NULL;
>> +        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
>
> "d" gets passed into this function - no need to shadow the variable

You're right.

> and (wrongly) re-obtain the pointer.
>
>> +
>> +        if ( d == NULL )
>> +            return -ESRCH;
>> +
>> +        d->arch.hvm_domain.pci_force =
>> +                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;
>> +        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;
>
> You shouldn't set the count before setting the pointer.

Will reorder them.

>
>> +        d->arch.hvm_domain.pcidevs = NULL;
>> +
>> +        if ( xdsr->num_pcidevs )
>> +        {
>> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
>> +                                    xdsr->num_pcidevs);
>
> New domctl-s must not represent security risks: xdsr->num_pcidevs
> can be (almost) arbitrarily large - do you really want to allow such
> huge allocations? A reasonable upper bound could for example be

Sorry, as you know this num_pcidevs is from tools, and actually it share 
that result from that existing hypercall, assign_device, while parsing 
'pci=[]', so I couldn't understand why this can be (almost" arbitrarily 
large.

> the total number of PCI devices the hypervisor knows about.

I take a quick look at this but looks we have no this exact value that 
we can get directly.

>
>> +            if ( pcidevs == NULL )
>> +            {
>> +                rcu_unlock_domain(d);
>> +                return -ENOMEM;
>> +            }
>> +
>> +            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
>> +                                 xdsr->num_pcidevs*sizeof(*pcidevs)) )
>> +            {
>> +                xfree(pcidevs);
>> +                rcu_unlock_domain(d);
>> +                return -EFAULT;
>> +            }
>> +        }
>> +
>> +        d->arch.hvm_domain.pcidevs = pcidevs;
>
> If the operation gets issued more than once for a given domain,
> you're leaking the old pointer here. Overall should think a bit
> more about this multiple use case (or outright disallow it).

Currently this should be disallowed, so I will do this,

     case XEN_DOMCTL_set_rdm:
     {
         struct xen_domctl_set_rdm *xdsr = &domctl->u.set_rdm;
         struct xen_guest_pcidev_info *pcidevs = NULL;

         if ( d->arch.hvm_domain.pcidevs )
             break;
	...

>
>> --- a/xen/drivers/passthrough/vtd/dmar.c
>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>> @@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>>                           "  RMRR region: base_addr %"PRIx64
>>                           " end_address %"PRIx64"\n",
>>                           rmrru->base_address, rmrru->end_address);
>> +            /*
>> +             * TODO: we may provide a precise paramter just to reserve
>> +             * RMRR range specific to one device.
>> +             */
>> +            dprintk(XENLOG_WARNING VTDPREFIX,
>> +                    "So please set pci_rdmforce to reserve these ranges"
>> +                    " if you need such a device in hotplug case.\n");
>
> It makes no sense to use dprintk() here. I also don't see how this
> message relates to whatever may have been logged immediately
> before, so the wording ("So please set ...") is questionable. Nor is the
> reference to "hotplug case" meaningful here - in this context, only
> physical (host) device hotplug can be meant without further
> qualification. In the end I think trying to log something here is just
> wrong - simply drop the message and make sure whatever you want

Okay.

> to say can be found easily by looking elsewhere.

Maybe we can print something in case when we can't set those identified 
mapping successfully, but its too late...

>
>> --- 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;
>>
>> +    bool_t                  pci_force;
>> +    uint32_t                num_pcidevs;
>> +    struct xen_guest_pcidev_info      *pcidevs;
>
> Without a comment all these field names are pretty questionable.

Yeah, I try to add some comments,

     /* A global flag, we need to check/reserve all Reserved Device 
Memory. */
     bool_t                  pci_force;
     /*
      * If pci_force is 0, this represents how many pci devices we need
      * to check/reserve Reserved Device Memory.
      * If pci_force is 1, this is always 0.
      */
     uint32_t                num_pcidevs;
     /* This represents those pci devices instances when num_pcidevs != 
0. */
     struct xen_guest_pcidev_info      *pcidevs;

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 Dec 08 06:07:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 06: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 1XxrSu-0003dq-RN; Mon, 08 Dec 2014 06:06:36 +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 1XxrSs-0003dl-TL
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 06:06:35 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	D6/39-18267-AEF35845; Mon, 08 Dec 2014 06:06:34 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418018791!11722846!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21281 invoked from network); 8 Dec 2014 06:06:32 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-5.tower-31.messagelabs.com with SMTP;
	8 Dec 2014 06:06:32 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 07 Dec 2014 22:04:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,536,1413270000"; d="scan'208";a="650096380"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 07 Dec 2014 22:06:27 -0800
Message-ID: <54853FE3.9030703@intel.com>
Date: Mon, 08 Dec 2014 14:06:27 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<54808CC3020000780004CCC8@mail.emea.novell.com>
In-Reply-To: <54808CC3020000780004CCC8@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/4 23:33, Jan Beulich wrote:
>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -34,6 +34,7 @@
>>   #include <xen/tasklet.h>
>>   #include <xsm/xsm.h>
>>   #include <asm/msi.h>
>> +#include <xen/stdbool.h>
>
> Please don't - we use bool_t in the hypervisor, not bool. The header

Yes.

> only exists for source code shared with the tools.

Looks this could be fine,

d->arch.hvm_domain.pci_force = xdsr->flags & PCI_DEV_RDM_CHECK;

>
>> @@ -1553,6 +1554,44 @@ 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 = NULL;
>> +        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
>
> "d" gets passed into this function - no need to shadow the variable

You're right.

> and (wrongly) re-obtain the pointer.
>
>> +
>> +        if ( d == NULL )
>> +            return -ESRCH;
>> +
>> +        d->arch.hvm_domain.pci_force =
>> +                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;
>> +        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;
>
> You shouldn't set the count before setting the pointer.

Will reorder them.

>
>> +        d->arch.hvm_domain.pcidevs = NULL;
>> +
>> +        if ( xdsr->num_pcidevs )
>> +        {
>> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
>> +                                    xdsr->num_pcidevs);
>
> New domctl-s must not represent security risks: xdsr->num_pcidevs
> can be (almost) arbitrarily large - do you really want to allow such
> huge allocations? A reasonable upper bound could for example be

Sorry, as you know this num_pcidevs is from tools, and actually it share 
that result from that existing hypercall, assign_device, while parsing 
'pci=[]', so I couldn't understand why this can be (almost" arbitrarily 
large.

> the total number of PCI devices the hypervisor knows about.

I take a quick look at this but looks we have no this exact value that 
we can get directly.

>
>> +            if ( pcidevs == NULL )
>> +            {
>> +                rcu_unlock_domain(d);
>> +                return -ENOMEM;
>> +            }
>> +
>> +            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
>> +                                 xdsr->num_pcidevs*sizeof(*pcidevs)) )
>> +            {
>> +                xfree(pcidevs);
>> +                rcu_unlock_domain(d);
>> +                return -EFAULT;
>> +            }
>> +        }
>> +
>> +        d->arch.hvm_domain.pcidevs = pcidevs;
>
> If the operation gets issued more than once for a given domain,
> you're leaking the old pointer here. Overall should think a bit
> more about this multiple use case (or outright disallow it).

Currently this should be disallowed, so I will do this,

     case XEN_DOMCTL_set_rdm:
     {
         struct xen_domctl_set_rdm *xdsr = &domctl->u.set_rdm;
         struct xen_guest_pcidev_info *pcidevs = NULL;

         if ( d->arch.hvm_domain.pcidevs )
             break;
	...

>
>> --- a/xen/drivers/passthrough/vtd/dmar.c
>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>> @@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
>>                           "  RMRR region: base_addr %"PRIx64
>>                           " end_address %"PRIx64"\n",
>>                           rmrru->base_address, rmrru->end_address);
>> +            /*
>> +             * TODO: we may provide a precise paramter just to reserve
>> +             * RMRR range specific to one device.
>> +             */
>> +            dprintk(XENLOG_WARNING VTDPREFIX,
>> +                    "So please set pci_rdmforce to reserve these ranges"
>> +                    " if you need such a device in hotplug case.\n");
>
> It makes no sense to use dprintk() here. I also don't see how this
> message relates to whatever may have been logged immediately
> before, so the wording ("So please set ...") is questionable. Nor is the
> reference to "hotplug case" meaningful here - in this context, only
> physical (host) device hotplug can be meant without further
> qualification. In the end I think trying to log something here is just
> wrong - simply drop the message and make sure whatever you want

Okay.

> to say can be found easily by looking elsewhere.

Maybe we can print something in case when we can't set those identified 
mapping successfully, but its too late...

>
>> --- 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;
>>
>> +    bool_t                  pci_force;
>> +    uint32_t                num_pcidevs;
>> +    struct xen_guest_pcidev_info      *pcidevs;
>
> Without a comment all these field names are pretty questionable.

Yeah, I try to add some comments,

     /* A global flag, we need to check/reserve all Reserved Device 
Memory. */
     bool_t                  pci_force;
     /*
      * If pci_force is 0, this represents how many pci devices we need
      * to check/reserve Reserved Device Memory.
      * If pci_force is 1, this is always 0.
      */
     uint32_t                num_pcidevs;
     /* This represents those pci devices instances when num_pcidevs != 
0. */
     struct xen_guest_pcidev_info      *pcidevs;

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 Dec 08 06:18:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 06: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 1Xxrde-00043G-0t; Mon, 08 Dec 2014 06:17:42 +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 1Xxrdc-00043B-QJ
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 06:17:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	71/E3-09842-48245845; Mon, 08 Dec 2014 06:17:40 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418019456!6745819!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5827 invoked from network); 8 Dec 2014 06:17:38 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-21.messagelabs.com with SMTP;
	8 Dec 2014 06:17:38 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 07 Dec 2014 22:15:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,536,1413270000"; d="scan'208";a="650100115"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 07 Dec 2014 22:17:33 -0800
Message-ID: <5485427C.1070903@intel.com>
Date: Mon, 08 Dec 2014 14:17: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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, jbeulich@suse.com
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
	<20141202194709.GD357@laptop.dumpdata.com>
In-Reply-To: <20141202194709.GD357@laptop.dumpdata.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	tim@xen.org, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 03/17] introduce
	XENMEM_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/3 3:47, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 05:24:21PM +0800, Tiejun Chen wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>>
>> This is a prerequisite for punching holes into HVM and PVH guests' P2M
>> to allow passing through devices that are associated with (on VT-d)
>> RMRRs.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Acked-by: Kevin Tian <kevin.tian@intel.com>
>> ---

[snip]

>> @@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>           break;
>>       }
>>
>> +#ifdef HAS_PASSTHROUGH
>> +    case XENMEM_reserved_device_memory_map:
>> +    {
>> +        struct get_reserved_device_memory grdm;
>> +
>> +        if ( copy_from_guest(&grdm.map, arg, 1) ||
>> +             !guest_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
>> +            return -EFAULT;
>> +
>
> Shouldn't there be an XSM check here?

I'm not sure, and Jan should be the author for this patch, so Jan can 
give you a correct reply.

>
>> +        grdm.used_entries = 0;
>> +        rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
>> +                                              &grdm);
>> +
>
> Also since we doing an iteration over possible many nr_entries should
> we think about returning -EAGAIN to user-space so that it can retry?

Yes,

> (As in, have preemption baked in this hypercall)
>
>> +        if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>> +            rc = -ENOBUFS;

we have this return value.

Thanks
Tiejun

>> +        grdm.map.nr_entries = grdm.used_entries;
>> +        if ( __copy_to_guest(arg, &grdm.map, 1) )
>> +            rc = -EFAULT;
>> +
>> +        break;
>> +    }
>> +#endif
>> +
>>       default:
>>           rc = arch_memory_op(cmd, arg);
>>           break;
>> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
>> index cc12735..7c17e8d 100644
>> --- a/xen/drivers/passthrough/iommu.c
>> +++ b/xen/drivers/passthrough/iommu.c
>> @@ -344,6 +344,16 @@ void iommu_crash_shutdown(void)
>>       iommu_enabled = iommu_intremap = 0;
>>   }
>>
>> +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);
>> +}
>> +
>>   bool_t iommu_has_feature(struct domain *d, enum iommu_feature feature)
>>   {
>>       const struct hvm_iommu *hd = domain_hvm_iommu(d);
>> diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
>> index 5e41e7a..86cfad3 100644
>> --- a/xen/drivers/passthrough/vtd/dmar.c
>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>> @@ -901,3 +901,20 @@ int platform_supports_x2apic(void)
>>       unsigned int mask = ACPI_DMAR_INTR_REMAP | ACPI_DMAR_X2APIC_OPT_OUT;
>>       return cpu_has_x2apic && ((dmar_flags & mask) == ACPI_DMAR_INTR_REMAP);
>>   }
>> +
>> +int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>> +{
>> +    struct acpi_rmrr_unit *rmrr;
>> +    int rc = 0;
>> +
>> +    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;
>> +    }
>> +
>> +    return rc;
>> +}
>> diff --git a/xen/drivers/passthrough/vtd/extern.h b/xen/drivers/passthrough/vtd/extern.h
>> index 5524dba..f9ee9b0 100644
>> --- a/xen/drivers/passthrough/vtd/extern.h
>> +++ b/xen/drivers/passthrough/vtd/extern.h
>> @@ -75,6 +75,7 @@ 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);
>>
>>   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/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
>> index 19d8165..a38f201 100644
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> @@ -2491,6 +2491,7 @@ const struct iommu_ops intel_iommu_ops = {
>>       .crash_shutdown = vtd_crash_shutdown,
>>       .iotlb_flush = intel_iommu_iotlb_flush,
>>       .iotlb_flush_all = intel_iommu_iotlb_flush_all,
>> +    .get_reserved_device_memory = intel_iommu_get_reserved_device_memory,
>>       .dump_p2m_table = vtd_dump_p2m_table,
>>   };
>>
>> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
>> index 595f953..cee4535 100644
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -572,7 +572,29 @@ struct xen_vnuma_topology_info {
>>   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 */
>> +/*
>> + * For legacy reasons, some devices must be configured with special memory
>> + * regions to function correctly.  The guest must avoid using any of these
>> + * regions.
>> + */
>> +#define XENMEM_reserved_device_memory_map   27
>> +struct xen_reserved_device_memory {
>> +    xen_pfn_t start_pfn;
>> +    xen_ulong_t nr_pages;
>> +};
>> +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 {
>> +    /* IN/OUT */
>> +    unsigned int nr_entries;
>> +    /* OUT */
>> +    XEN_GUEST_HANDLE(xen_reserved_device_memory_t) buffer;
>> +};
>> +typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t);
>> +
>> +/* Next available subop number is 28 */
>>
>>   #endif /* __XEN_PUBLIC_MEMORY_H__ */
>>
>> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
>> index 8eb764a..409f6f8 100644
>> --- a/xen/include/xen/iommu.h
>> +++ b/xen/include/xen/iommu.h
>> @@ -120,6 +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);
>> +
>>   struct iommu_ops {
>>       int (*init)(struct domain *d);
>>       void (*hwdom_init)(struct domain *d);
>> @@ -156,12 +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 *);
>>       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 *);
>>
>>   void iommu_share_p2m_table(struct domain *d);
>>
>> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
>> index 41b3e35..42229fd 100644
>> --- a/xen/include/xlat.lst
>> +++ b/xen/include/xlat.lst
>> @@ -61,9 +61,10 @@
>>   !	memory_exchange			memory.h
>>   !	memory_map			memory.h
>>   !	memory_reservation		memory.h
>> -?	mem_access_op		memory.h
>> +?	mem_access_op			memory.h
>>   !	pod_target			memory.h
>>   !	remove_from_physmap		memory.h
>> +!	reserved_device_memory_map	memory.h
>>   ?	physdev_eoi			physdev.h
>>   ?	physdev_get_free_pirq		physdev.h
>>   ?	physdev_irq			physdev.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 Dec 08 06:18:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 06: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 1Xxrde-00043G-0t; Mon, 08 Dec 2014 06:17:42 +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 1Xxrdc-00043B-QJ
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 06:17:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	71/E3-09842-48245845; Mon, 08 Dec 2014 06:17:40 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418019456!6745819!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5827 invoked from network); 8 Dec 2014 06:17:38 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-21.messagelabs.com with SMTP;
	8 Dec 2014 06:17:38 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 07 Dec 2014 22:15:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,536,1413270000"; d="scan'208";a="650100115"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 07 Dec 2014 22:17:33 -0800
Message-ID: <5485427C.1070903@intel.com>
Date: Mon, 08 Dec 2014 14:17: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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, jbeulich@suse.com
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
	<20141202194709.GD357@laptop.dumpdata.com>
In-Reply-To: <20141202194709.GD357@laptop.dumpdata.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	tim@xen.org, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 03/17] introduce
	XENMEM_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/3 3:47, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 05:24:21PM +0800, Tiejun Chen wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>>
>> This is a prerequisite for punching holes into HVM and PVH guests' P2M
>> to allow passing through devices that are associated with (on VT-d)
>> RMRRs.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Acked-by: Kevin Tian <kevin.tian@intel.com>
>> ---

[snip]

>> @@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>           break;
>>       }
>>
>> +#ifdef HAS_PASSTHROUGH
>> +    case XENMEM_reserved_device_memory_map:
>> +    {
>> +        struct get_reserved_device_memory grdm;
>> +
>> +        if ( copy_from_guest(&grdm.map, arg, 1) ||
>> +             !guest_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
>> +            return -EFAULT;
>> +
>
> Shouldn't there be an XSM check here?

I'm not sure, and Jan should be the author for this patch, so Jan can 
give you a correct reply.

>
>> +        grdm.used_entries = 0;
>> +        rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
>> +                                              &grdm);
>> +
>
> Also since we doing an iteration over possible many nr_entries should
> we think about returning -EAGAIN to user-space so that it can retry?

Yes,

> (As in, have preemption baked in this hypercall)
>
>> +        if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>> +            rc = -ENOBUFS;

we have this return value.

Thanks
Tiejun

>> +        grdm.map.nr_entries = grdm.used_entries;
>> +        if ( __copy_to_guest(arg, &grdm.map, 1) )
>> +            rc = -EFAULT;
>> +
>> +        break;
>> +    }
>> +#endif
>> +
>>       default:
>>           rc = arch_memory_op(cmd, arg);
>>           break;
>> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
>> index cc12735..7c17e8d 100644
>> --- a/xen/drivers/passthrough/iommu.c
>> +++ b/xen/drivers/passthrough/iommu.c
>> @@ -344,6 +344,16 @@ void iommu_crash_shutdown(void)
>>       iommu_enabled = iommu_intremap = 0;
>>   }
>>
>> +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);
>> +}
>> +
>>   bool_t iommu_has_feature(struct domain *d, enum iommu_feature feature)
>>   {
>>       const struct hvm_iommu *hd = domain_hvm_iommu(d);
>> diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
>> index 5e41e7a..86cfad3 100644
>> --- a/xen/drivers/passthrough/vtd/dmar.c
>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>> @@ -901,3 +901,20 @@ int platform_supports_x2apic(void)
>>       unsigned int mask = ACPI_DMAR_INTR_REMAP | ACPI_DMAR_X2APIC_OPT_OUT;
>>       return cpu_has_x2apic && ((dmar_flags & mask) == ACPI_DMAR_INTR_REMAP);
>>   }
>> +
>> +int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>> +{
>> +    struct acpi_rmrr_unit *rmrr;
>> +    int rc = 0;
>> +
>> +    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;
>> +    }
>> +
>> +    return rc;
>> +}
>> diff --git a/xen/drivers/passthrough/vtd/extern.h b/xen/drivers/passthrough/vtd/extern.h
>> index 5524dba..f9ee9b0 100644
>> --- a/xen/drivers/passthrough/vtd/extern.h
>> +++ b/xen/drivers/passthrough/vtd/extern.h
>> @@ -75,6 +75,7 @@ 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);
>>
>>   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/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
>> index 19d8165..a38f201 100644
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> @@ -2491,6 +2491,7 @@ const struct iommu_ops intel_iommu_ops = {
>>       .crash_shutdown = vtd_crash_shutdown,
>>       .iotlb_flush = intel_iommu_iotlb_flush,
>>       .iotlb_flush_all = intel_iommu_iotlb_flush_all,
>> +    .get_reserved_device_memory = intel_iommu_get_reserved_device_memory,
>>       .dump_p2m_table = vtd_dump_p2m_table,
>>   };
>>
>> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
>> index 595f953..cee4535 100644
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -572,7 +572,29 @@ struct xen_vnuma_topology_info {
>>   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 */
>> +/*
>> + * For legacy reasons, some devices must be configured with special memory
>> + * regions to function correctly.  The guest must avoid using any of these
>> + * regions.
>> + */
>> +#define XENMEM_reserved_device_memory_map   27
>> +struct xen_reserved_device_memory {
>> +    xen_pfn_t start_pfn;
>> +    xen_ulong_t nr_pages;
>> +};
>> +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 {
>> +    /* IN/OUT */
>> +    unsigned int nr_entries;
>> +    /* OUT */
>> +    XEN_GUEST_HANDLE(xen_reserved_device_memory_t) buffer;
>> +};
>> +typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t);
>> +
>> +/* Next available subop number is 28 */
>>
>>   #endif /* __XEN_PUBLIC_MEMORY_H__ */
>>
>> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
>> index 8eb764a..409f6f8 100644
>> --- a/xen/include/xen/iommu.h
>> +++ b/xen/include/xen/iommu.h
>> @@ -120,6 +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);
>> +
>>   struct iommu_ops {
>>       int (*init)(struct domain *d);
>>       void (*hwdom_init)(struct domain *d);
>> @@ -156,12 +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 *);
>>       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 *);
>>
>>   void iommu_share_p2m_table(struct domain *d);
>>
>> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
>> index 41b3e35..42229fd 100644
>> --- a/xen/include/xlat.lst
>> +++ b/xen/include/xlat.lst
>> @@ -61,9 +61,10 @@
>>   !	memory_exchange			memory.h
>>   !	memory_map			memory.h
>>   !	memory_reservation		memory.h
>> -?	mem_access_op		memory.h
>> +?	mem_access_op			memory.h
>>   !	pod_target			memory.h
>>   !	remove_from_physmap		memory.h
>> +!	reserved_device_memory_map	memory.h
>>   ?	physdev_eoi			physdev.h
>>   ?	physdev_get_free_pirq		physdev.h
>>   ?	physdev_irq			physdev.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 Dec 08 06:22:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 06:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxrie-0004NY-Ru; Mon, 08 Dec 2014 06:22:52 +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 1Xxrie-0004NT-1g
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 06:22:52 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	4F/83-28296-BB345845; Mon, 08 Dec 2014 06:22:51 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418019766!11707167!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9214 invoked from network); 8 Dec 2014 06:22:50 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-31.messagelabs.com with SMTP;
	8 Dec 2014 06:22:50 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 07 Dec 2014 22:22:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,536,1413270000"; d="scan'208";a="650101561"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 07 Dec 2014 22:22:42 -0800
Message-ID: <548543B2.1000303@intel.com>
Date: Mon, 08 Dec 2014 14:22: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.3.0
MIME-Version: 1.0
To: "Tian, Kevin" <kevin.tian@intel.com>, 
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, 
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Zhang, Yang Z" <yang.z.zhang@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610AB50@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610AB50@SHSMSX101.ccr.corp.intel.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
	support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/2 16:46, Tian, Kevin wrote:
>> From: Chen, Tiejun
>> Sent: Monday, December 01, 2014 5:24 PM
>>
>> After we intend to expost that hypercall explicitly based on
>> XEN_DOMCTL_set_rdm, we need this rebase. I hope we can squash
>> this into that previous patch once Jan Ack this.
>
> better to merge together, since it's the right thing to do based on previous
> discussion.

As I said I will do this after this patch is acked.

>
> one question about 'd->arch.hvm_domain.pci_force'. My impression is
> that this flag enables force check, and while enabled, you'll always

Yes.

> do selected BDF filtering by default. However from below code, seems

No.

> pci_force is used to whether report all or selected regions. Am I reading
> it wrong?

	if ( d->arch.hvm_domain.pci_force )
	{
		...
	}
	else
	{
		for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
		...
	}

So by default, we first check d->arch.hvm_domain.pci_force without 
filtering all selected BDF :)

Thanks
Tiejun

>
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   xen/common/compat/memory.c         | 75
>> ++++++++++++++++++++++++++++++--------
>>   xen/common/memory.c                | 71
>> +++++++++++++++++++++++++++++-------
>>   xen/drivers/passthrough/vtd/dmar.c | 32 ++++++++++++----
>>   xen/include/public/memory.h        |  5 +++
>>   xen/include/xen/iommu.h            |  2 +-
>>   xen/include/xen/pci.h              |  2 +
>>   6 files changed, 148 insertions(+), 39 deletions(-)
>>
>> diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
>> index 60512fa..e6a256e 100644
>> --- a/xen/common/compat/memory.c
>> +++ b/xen/common/compat/memory.c
>> @@ -22,27 +22,66 @@ 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;
>> +    unsigned int i;
>> +    u32 sbdf;
>> +    struct compat_reserved_device_memory rdm = {
>> +        .start_pfn = start, .nr_pages = nr
>> +    };
>>
>> -    if ( grdm->used_entries < grdm->map.nr_entries )
>> -    {
>> -        struct compat_reserved_device_memory rdm = {
>> -            .start_pfn = start, .nr_pages = nr
>> -        };
>> +    if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>> +        return -ERANGE;
>>
>> -        if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>> -            return -ERANGE;
>> +    d = rcu_lock_domain_by_any_id(grdm->map.domid);
>> +    if ( d == NULL )
>> +        return -ESRCH;
>>
>> -        if ( __copy_to_compat_offset(grdm->map.buffer,
>> grdm->used_entries,
>> -                                     &rdm, 1) )
>> -            return -EFAULT;
>> +    if ( d )
>> +    {
>> +        if ( d->arch.hvm_domain.pci_force )
>> +        {
>> +            if ( grdm->used_entries < grdm->map.nr_entries )
>> +            {
>> +                if ( __copy_to_compat_offset(grdm->map.buffer,
>> +                                             grdm->used_entries,
>> +                                             &rdm, 1) )
>> +                {
>> +                    rcu_unlock_domain(d);
>> +                    return -EFAULT;
>> +                }
>> +            }
>> +            ++grdm->used_entries;
>> +        }
>> +        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 ( grdm->used_entries < grdm->map.nr_entries )
>> +                    {
>> +                        if
>> ( __copy_to_compat_offset(grdm->map.buffer,
>> +
>> grdm->used_entries,
>> +                                                     &rdm, 1) )
>> +                        {
>> +                            rcu_unlock_domain(d);
>> +                            return -EFAULT;
>> +                        }
>> +                    }
>> +                    ++grdm->used_entries;
>> +                }
>> +            }
>> +        }
>>       }
>>
>> -    ++grdm->used_entries;
>> -
>> +    rcu_unlock_domain(d);
>>       return 0;
>>   }
>>   #endif
>> @@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>
>>               if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>>                   rc = -ENOBUFS;
>> +
>>               grdm.map.nr_entries = grdm.used_entries;
>> -            if ( __copy_to_guest(compat, &grdm.map, 1) )
>> -                rc = -EFAULT;
>> +            if ( grdm.map.nr_entries )
>> +            {
>> +                if ( __copy_to_guest(compat, &grdm.map, 1) )
>> +                    rc = -EFAULT;
>> +            }
>>
>>               return rc;
>>           }
>> diff --git a/xen/common/memory.c b/xen/common/memory.c
>> index 4788acc..9ce82b1 100644
>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -698,24 +698,63 @@ 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;
>> +    unsigned int i;
>> +    u32 sbdf;
>> +    struct xen_reserved_device_memory rdm = {
>> +        .start_pfn = start, .nr_pages = nr
>> +    };
>>
>> -    if ( grdm->used_entries < grdm->map.nr_entries )
>> -    {
>> -        struct xen_reserved_device_memory rdm = {
>> -            .start_pfn = start, .nr_pages = nr
>> -        };
>> +    d = rcu_lock_domain_by_any_id(grdm->map.domid);
>> +    if ( d == NULL )
>> +        return -ESRCH;
>>
>> -        if ( __copy_to_guest_offset(grdm->map.buffer,
>> grdm->used_entries,
>> -                                    &rdm, 1) )
>> -            return -EFAULT;
>> +    if ( d )
>> +    {
>> +        if ( d->arch.hvm_domain.pci_force )
>> +        {
>> +            if ( grdm->used_entries < grdm->map.nr_entries )
>> +            {
>> +                if ( __copy_to_guest_offset(grdm->map.buffer,
>> +                                            grdm->used_entries,
>> +                                            &rdm, 1) )
>> +                {
>> +                    rcu_unlock_domain(d);
>> +                    return -EFAULT;
>> +                }
>> +            }
>> +            ++grdm->used_entries;
>> +        }
>> +        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 ( grdm->used_entries < grdm->map.nr_entries )
>> +                    {
>> +                        if ( __copy_to_guest_offset(grdm->map.buffer,
>> +
>> grdm->used_entries,
>> +                                                    &rdm, 1) )
>> +                        {
>> +                            rcu_unlock_domain(d);
>> +                            return -EFAULT;
>> +                        }
>> +                    }
>> +                    ++grdm->used_entries;
>> +                }
>> +            }
>> +        }
>>       }
>>
>> -    ++grdm->used_entries;
>> -
>> +    rcu_unlock_domain(d);
>>       return 0;
>>   }
>>   #endif
>> @@ -1144,9 +1183,13 @@ long do_memory_op(unsigned long cmd,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>
>>           if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>>               rc = -ENOBUFS;
>> +
>>           grdm.map.nr_entries = grdm.used_entries;
>> -        if ( __copy_to_guest(arg, &grdm.map, 1) )
>> -            rc = -EFAULT;
>> +        if ( grdm.map.nr_entries )
>> +        {
>> +            if ( __copy_to_guest(arg, &grdm.map, 1) )
>> +                rc = -EFAULT;
>> +        }
>>
>>           break;
>>       }
>> diff --git a/xen/drivers/passthrough/vtd/dmar.c
>> b/xen/drivers/passthrough/vtd/dmar.c
>> index 86cfad3..c5bc8d6 100644
>> --- a/xen/drivers/passthrough/vtd/dmar.c
>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>> @@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
>>
>>   int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void
>> *ctxt)
>>   {
>> -    struct acpi_rmrr_unit *rmrr;
>> +    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
>>       int rc = 0;
>> +    unsigned 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 ( 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;
>> +
>> +            /* Just go next. */
>> +            if ( !rc )
>> +                rmrr_cur = rmrr;
>> +
>> +            /* Now just return specific to user requirement. */
>> +            if ( rc > 0 )
>> +                return rc;
>> +        }
>>       }
>>
>> -    return rc;
>> +    return 0;
>>   }
>> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
>> index cee4535..0d0544e 100644
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -586,6 +586,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..8fc6d6d 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, u32 id, 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 5f295f3..d34205f 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;
>> --
>> 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 Dec 08 06:22:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 06:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxrie-0004NY-Ru; Mon, 08 Dec 2014 06:22:52 +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 1Xxrie-0004NT-1g
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 06:22:52 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	4F/83-28296-BB345845; Mon, 08 Dec 2014 06:22:51 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418019766!11707167!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9214 invoked from network); 8 Dec 2014 06:22:50 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-31.messagelabs.com with SMTP;
	8 Dec 2014 06:22:50 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 07 Dec 2014 22:22:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,536,1413270000"; d="scan'208";a="650101561"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 07 Dec 2014 22:22:42 -0800
Message-ID: <548543B2.1000303@intel.com>
Date: Mon, 08 Dec 2014 14:22: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.3.0
MIME-Version: 1.0
To: "Tian, Kevin" <kevin.tian@intel.com>, 
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, 
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Zhang, Yang Z" <yang.z.zhang@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610AB50@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610AB50@SHSMSX101.ccr.corp.intel.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
	support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/2 16:46, Tian, Kevin wrote:
>> From: Chen, Tiejun
>> Sent: Monday, December 01, 2014 5:24 PM
>>
>> After we intend to expost that hypercall explicitly based on
>> XEN_DOMCTL_set_rdm, we need this rebase. I hope we can squash
>> this into that previous patch once Jan Ack this.
>
> better to merge together, since it's the right thing to do based on previous
> discussion.

As I said I will do this after this patch is acked.

>
> one question about 'd->arch.hvm_domain.pci_force'. My impression is
> that this flag enables force check, and while enabled, you'll always

Yes.

> do selected BDF filtering by default. However from below code, seems

No.

> pci_force is used to whether report all or selected regions. Am I reading
> it wrong?

	if ( d->arch.hvm_domain.pci_force )
	{
		...
	}
	else
	{
		for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
		...
	}

So by default, we first check d->arch.hvm_domain.pci_force without 
filtering all selected BDF :)

Thanks
Tiejun

>
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   xen/common/compat/memory.c         | 75
>> ++++++++++++++++++++++++++++++--------
>>   xen/common/memory.c                | 71
>> +++++++++++++++++++++++++++++-------
>>   xen/drivers/passthrough/vtd/dmar.c | 32 ++++++++++++----
>>   xen/include/public/memory.h        |  5 +++
>>   xen/include/xen/iommu.h            |  2 +-
>>   xen/include/xen/pci.h              |  2 +
>>   6 files changed, 148 insertions(+), 39 deletions(-)
>>
>> diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
>> index 60512fa..e6a256e 100644
>> --- a/xen/common/compat/memory.c
>> +++ b/xen/common/compat/memory.c
>> @@ -22,27 +22,66 @@ 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;
>> +    unsigned int i;
>> +    u32 sbdf;
>> +    struct compat_reserved_device_memory rdm = {
>> +        .start_pfn = start, .nr_pages = nr
>> +    };
>>
>> -    if ( grdm->used_entries < grdm->map.nr_entries )
>> -    {
>> -        struct compat_reserved_device_memory rdm = {
>> -            .start_pfn = start, .nr_pages = nr
>> -        };
>> +    if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>> +        return -ERANGE;
>>
>> -        if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>> -            return -ERANGE;
>> +    d = rcu_lock_domain_by_any_id(grdm->map.domid);
>> +    if ( d == NULL )
>> +        return -ESRCH;
>>
>> -        if ( __copy_to_compat_offset(grdm->map.buffer,
>> grdm->used_entries,
>> -                                     &rdm, 1) )
>> -            return -EFAULT;
>> +    if ( d )
>> +    {
>> +        if ( d->arch.hvm_domain.pci_force )
>> +        {
>> +            if ( grdm->used_entries < grdm->map.nr_entries )
>> +            {
>> +                if ( __copy_to_compat_offset(grdm->map.buffer,
>> +                                             grdm->used_entries,
>> +                                             &rdm, 1) )
>> +                {
>> +                    rcu_unlock_domain(d);
>> +                    return -EFAULT;
>> +                }
>> +            }
>> +            ++grdm->used_entries;
>> +        }
>> +        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 ( grdm->used_entries < grdm->map.nr_entries )
>> +                    {
>> +                        if
>> ( __copy_to_compat_offset(grdm->map.buffer,
>> +
>> grdm->used_entries,
>> +                                                     &rdm, 1) )
>> +                        {
>> +                            rcu_unlock_domain(d);
>> +                            return -EFAULT;
>> +                        }
>> +                    }
>> +                    ++grdm->used_entries;
>> +                }
>> +            }
>> +        }
>>       }
>>
>> -    ++grdm->used_entries;
>> -
>> +    rcu_unlock_domain(d);
>>       return 0;
>>   }
>>   #endif
>> @@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>
>>               if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>>                   rc = -ENOBUFS;
>> +
>>               grdm.map.nr_entries = grdm.used_entries;
>> -            if ( __copy_to_guest(compat, &grdm.map, 1) )
>> -                rc = -EFAULT;
>> +            if ( grdm.map.nr_entries )
>> +            {
>> +                if ( __copy_to_guest(compat, &grdm.map, 1) )
>> +                    rc = -EFAULT;
>> +            }
>>
>>               return rc;
>>           }
>> diff --git a/xen/common/memory.c b/xen/common/memory.c
>> index 4788acc..9ce82b1 100644
>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -698,24 +698,63 @@ 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;
>> +    unsigned int i;
>> +    u32 sbdf;
>> +    struct xen_reserved_device_memory rdm = {
>> +        .start_pfn = start, .nr_pages = nr
>> +    };
>>
>> -    if ( grdm->used_entries < grdm->map.nr_entries )
>> -    {
>> -        struct xen_reserved_device_memory rdm = {
>> -            .start_pfn = start, .nr_pages = nr
>> -        };
>> +    d = rcu_lock_domain_by_any_id(grdm->map.domid);
>> +    if ( d == NULL )
>> +        return -ESRCH;
>>
>> -        if ( __copy_to_guest_offset(grdm->map.buffer,
>> grdm->used_entries,
>> -                                    &rdm, 1) )
>> -            return -EFAULT;
>> +    if ( d )
>> +    {
>> +        if ( d->arch.hvm_domain.pci_force )
>> +        {
>> +            if ( grdm->used_entries < grdm->map.nr_entries )
>> +            {
>> +                if ( __copy_to_guest_offset(grdm->map.buffer,
>> +                                            grdm->used_entries,
>> +                                            &rdm, 1) )
>> +                {
>> +                    rcu_unlock_domain(d);
>> +                    return -EFAULT;
>> +                }
>> +            }
>> +            ++grdm->used_entries;
>> +        }
>> +        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 ( grdm->used_entries < grdm->map.nr_entries )
>> +                    {
>> +                        if ( __copy_to_guest_offset(grdm->map.buffer,
>> +
>> grdm->used_entries,
>> +                                                    &rdm, 1) )
>> +                        {
>> +                            rcu_unlock_domain(d);
>> +                            return -EFAULT;
>> +                        }
>> +                    }
>> +                    ++grdm->used_entries;
>> +                }
>> +            }
>> +        }
>>       }
>>
>> -    ++grdm->used_entries;
>> -
>> +    rcu_unlock_domain(d);
>>       return 0;
>>   }
>>   #endif
>> @@ -1144,9 +1183,13 @@ long do_memory_op(unsigned long cmd,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>
>>           if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>>               rc = -ENOBUFS;
>> +
>>           grdm.map.nr_entries = grdm.used_entries;
>> -        if ( __copy_to_guest(arg, &grdm.map, 1) )
>> -            rc = -EFAULT;
>> +        if ( grdm.map.nr_entries )
>> +        {
>> +            if ( __copy_to_guest(arg, &grdm.map, 1) )
>> +                rc = -EFAULT;
>> +        }
>>
>>           break;
>>       }
>> diff --git a/xen/drivers/passthrough/vtd/dmar.c
>> b/xen/drivers/passthrough/vtd/dmar.c
>> index 86cfad3..c5bc8d6 100644
>> --- a/xen/drivers/passthrough/vtd/dmar.c
>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>> @@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
>>
>>   int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void
>> *ctxt)
>>   {
>> -    struct acpi_rmrr_unit *rmrr;
>> +    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
>>       int rc = 0;
>> +    unsigned 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 ( 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;
>> +
>> +            /* Just go next. */
>> +            if ( !rc )
>> +                rmrr_cur = rmrr;
>> +
>> +            /* Now just return specific to user requirement. */
>> +            if ( rc > 0 )
>> +                return rc;
>> +        }
>>       }
>>
>> -    return rc;
>> +    return 0;
>>   }
>> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
>> index cee4535..0d0544e 100644
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -586,6 +586,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..8fc6d6d 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, u32 id, 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 5f295f3..d34205f 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;
>> --
>> 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 Dec 08 06:35:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1XxruK-0004l0-MP; Mon, 08 Dec 2014 06:34:56 +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 1XxruJ-0004kv-GB
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 06:34:55 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	02/EF-27584-E8645845; Mon, 08 Dec 2014 06:34:54 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418020492!12042558!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15639 invoked from network); 8 Dec 2014 06:34:53 -0000
Received: from exprod5og113.obsmtp.com (HELO exprod5og113.obsmtp.com)
	(64.18.0.26)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2014 06:34:53 -0000
Received: from mail-qa0-f45.google.com ([209.85.216.45]) (using TLSv1) by
	exprod5ob113.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVIVGiz2KLuznxNz1Nm/Ib7wETRq1d4iu@postini.com;
	Sun, 07 Dec 2014 22:34:53 PST
Received: by mail-qa0-f45.google.com with SMTP id x12so2984841qac.18
	for <xen-devel@lists.xen.org>; Sun, 07 Dec 2014 22:34:51 -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=qXEHOhO3hco4rqAyrajUG7SG02+8jure3VMUJ1G+gjc=;
	b=UxZN5cYWeB5M/rID5aSNoTndLsH2UEPohmVvBdi7M3yTuVxijQblrFILKEf2w0Qtkd
	sUz9PysJcJ3Z5e8ydT/EM/nJtS1ZoQLRyRDvtnZu6p7pn4h6hXa6t7iZYW1T2Ms9IwsE
	krZy50p3D0PpvSDcaHdG3Mg5dy/NIqU50oE/U=
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=qXEHOhO3hco4rqAyrajUG7SG02+8jure3VMUJ1G+gjc=;
	b=hmZTnfvWSoH1sQpN5dIB5E3407KcKuG4K3hjyeWCvThOEiX/igsUry+WpVDGDwtSRk
	LYCiKh+kimhZJwXz+h9N3LP7e4wtKoDoubvhelUjJxHinN+RKvYEHhkjjdneMGlcm4zq
	Yisd7Mo8hoeOHJjYN0aDYLUejP6rUQFIQBif73jE2VVy1V3UMQUJRXkQGS40n8tQycjH
	eE7dMprNZs2cjCfiw0y0nZeZvrszqsRdHI5vBJl67G06/6ilHQlQzWwHko0nQE2bQl4R
	/hh5y57Dj6vh/QuHBHyYaWLAh+Y/dtjCBjY6EsYrU2whYmPzGryd2OOLZSMGikDysrvN
	QynQ==
X-Gm-Message-State: ALoCoQlFxtaLmmcivnOHw02ElF0AGbq7OYRDDWLYuIQQrFi0nHqXnNiYjk9/WDcPiyRmzVb5+StqbFER3skwNDx6632SHNtv7AYBkPtC2g0bdCchWPlxeyib4A0pjDXMcf9dLzzzF2T3HI3nuxjXdZK/idZtVhHbvg==
X-Received: by 10.224.60.196 with SMTP id q4mr49457767qah.63.1418020491294;
	Sun, 07 Dec 2014 22:34:51 -0800 (PST)
X-Received: by 10.224.60.196 with SMTP id q4mr49457752qah.63.1418020491179;
	Sun, 07 Dec 2014 22:34:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.93.69 with HTTP; Sun, 7 Dec 2014 22:34:30 -0800 (PST)
In-Reply-To: <5481BF35.2060800@linaro.org>
References: <1417787196-3313-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<5481BF35.2060800@linaro.org>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Mon, 8 Dec 2014 08:34:30 +0200
Message-ID: <CAN58jiuXwHNhQ+t27djHpH=EPhQs-D0uQ-bqxGpG0OBRK+BVLQ@mail.gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In our case We've added an additional fake node to the device tree with
UART MMIO range for Xen and Xen mapped this MMIO range
for the Kernel 3.8. By default UART has wrong configuration in OMAP.

Oleksandr Dmytryshyn | Product Engineering and Development
GlobalLogic
M +38.067.382.2525
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt


On Fri, Dec 5, 2014 at 4:20 PM, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Oleksandr,
>
> On 05/12/14 13:46, Oleksandr Dmytryshyn wrote:
>> UART is not able to receive bytes when idle mode is not
>> configured properly. When we use Xen with old Linux
>> Kernel (for example 3.8) this kernel configures UART
>> idle mode even if the UART node in device tree is absent.
>
> I don't understand how the kernel can configure the UART as the MMIO
> range is not mapped. Is there another way to set the idle mode?
>
> 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 Dec 08 06:35:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1XxruK-0004l0-MP; Mon, 08 Dec 2014 06:34:56 +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 1XxruJ-0004kv-GB
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 06:34:55 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	02/EF-27584-E8645845; Mon, 08 Dec 2014 06:34:54 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418020492!12042558!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15639 invoked from network); 8 Dec 2014 06:34:53 -0000
Received: from exprod5og113.obsmtp.com (HELO exprod5og113.obsmtp.com)
	(64.18.0.26)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2014 06:34:53 -0000
Received: from mail-qa0-f45.google.com ([209.85.216.45]) (using TLSv1) by
	exprod5ob113.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVIVGiz2KLuznxNz1Nm/Ib7wETRq1d4iu@postini.com;
	Sun, 07 Dec 2014 22:34:53 PST
Received: by mail-qa0-f45.google.com with SMTP id x12so2984841qac.18
	for <xen-devel@lists.xen.org>; Sun, 07 Dec 2014 22:34:51 -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=qXEHOhO3hco4rqAyrajUG7SG02+8jure3VMUJ1G+gjc=;
	b=UxZN5cYWeB5M/rID5aSNoTndLsH2UEPohmVvBdi7M3yTuVxijQblrFILKEf2w0Qtkd
	sUz9PysJcJ3Z5e8ydT/EM/nJtS1ZoQLRyRDvtnZu6p7pn4h6hXa6t7iZYW1T2Ms9IwsE
	krZy50p3D0PpvSDcaHdG3Mg5dy/NIqU50oE/U=
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=qXEHOhO3hco4rqAyrajUG7SG02+8jure3VMUJ1G+gjc=;
	b=hmZTnfvWSoH1sQpN5dIB5E3407KcKuG4K3hjyeWCvThOEiX/igsUry+WpVDGDwtSRk
	LYCiKh+kimhZJwXz+h9N3LP7e4wtKoDoubvhelUjJxHinN+RKvYEHhkjjdneMGlcm4zq
	Yisd7Mo8hoeOHJjYN0aDYLUejP6rUQFIQBif73jE2VVy1V3UMQUJRXkQGS40n8tQycjH
	eE7dMprNZs2cjCfiw0y0nZeZvrszqsRdHI5vBJl67G06/6ilHQlQzWwHko0nQE2bQl4R
	/hh5y57Dj6vh/QuHBHyYaWLAh+Y/dtjCBjY6EsYrU2whYmPzGryd2OOLZSMGikDysrvN
	QynQ==
X-Gm-Message-State: ALoCoQlFxtaLmmcivnOHw02ElF0AGbq7OYRDDWLYuIQQrFi0nHqXnNiYjk9/WDcPiyRmzVb5+StqbFER3skwNDx6632SHNtv7AYBkPtC2g0bdCchWPlxeyib4A0pjDXMcf9dLzzzF2T3HI3nuxjXdZK/idZtVhHbvg==
X-Received: by 10.224.60.196 with SMTP id q4mr49457767qah.63.1418020491294;
	Sun, 07 Dec 2014 22:34:51 -0800 (PST)
X-Received: by 10.224.60.196 with SMTP id q4mr49457752qah.63.1418020491179;
	Sun, 07 Dec 2014 22:34:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.93.69 with HTTP; Sun, 7 Dec 2014 22:34:30 -0800 (PST)
In-Reply-To: <5481BF35.2060800@linaro.org>
References: <1417787196-3313-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<5481BF35.2060800@linaro.org>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Mon, 8 Dec 2014 08:34:30 +0200
Message-ID: <CAN58jiuXwHNhQ+t27djHpH=EPhQs-D0uQ-bqxGpG0OBRK+BVLQ@mail.gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In our case We've added an additional fake node to the device tree with
UART MMIO range for Xen and Xen mapped this MMIO range
for the Kernel 3.8. By default UART has wrong configuration in OMAP.

Oleksandr Dmytryshyn | Product Engineering and Development
GlobalLogic
M +38.067.382.2525
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt


On Fri, Dec 5, 2014 at 4:20 PM, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Oleksandr,
>
> On 05/12/14 13:46, Oleksandr Dmytryshyn wrote:
>> UART is not able to receive bytes when idle mode is not
>> configured properly. When we use Xen with old Linux
>> Kernel (for example 3.8) this kernel configures UART
>> idle mode even if the UART node in device tree is absent.
>
> I don't understand how the kernel can configure the UART as the MMIO
> range is not mapped. Is there another way to set the idle mode?
>
> 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 Dec 08 06:51:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 06:51:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxs9j-00056O-6z; Mon, 08 Dec 2014 06:50:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1Xxs9h-00056J-Fm
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 06:50:49 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	62/90-25276-84A45845; Mon, 08 Dec 2014 06:50:48 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418021443!14033932!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 656 invoked from network); 8 Dec 2014 06:50:47 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 06:50:47 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AYI58952; Mon, 08 Dec 2014 14:50:26 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.62]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Mon, 8 Dec 2014 14:50:16 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Zoltan Kiss
	<zoltan.kiss@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIAAiqFg//+jdIAAEh4VUAAj3QuAAAaAAwAAjyHxcA==
Date: Mon, 8 Dec 2014 06:50:15 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2394B199@SZXEMA512-MBX.china.huawei.com>
References: <3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
	<54806315.6010007@linaro.org>
	<3A6795EA1206904E94BEC8EF9DF109AE23933926@SZXEMA512-MBX.china.huawei.com>
	<5481CD57.607@linaro.org> <20141205182702.GA4754@laptop.dumpdata.com>
In-Reply-To: <20141205182702.GA4754@laptop.dumpdata.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020202.54854A35.03CF, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.62,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2c17022d9804b70b5280b9a23b4c1bed
Cc: "jonathan.davies@citrix.com" <jonathan.davies@citrix.com>, "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Fri, Dec 05, 2014 at 03:20:55PM +0000, Zoltan Kiss wrote:
> >
> >
> > On 04/12/14 14:31, Zhangleiqiang (Trump) wrote:
> > >>-----Original Message-----
> > >>From: Zoltan Kiss [mailto:zoltan.kiss@linaro.org]
> > >>Sent: Thursday, December 04, 2014 9:35 PM
> > >>To: Zhangleiqiang (Trump); Wei Liu; xen-devel@lists.xen.org
> > >>Cc: Xiaoding (B); Zhuangyuxin; zhangleiqiang; Luohao (brian); Yuzhou
> > >>(C)
> > >>Subject: Re: [Xen-devel] Poor network performance between DomU with
> > >>multiqueue support
> > >>
> > >>
> > >>
> > >>On 04/12/14 12:09, Zhangleiqiang (Trump) wrote:
> > >>>>I think that's expected, because guest RX data path still uses
> > >>>>grant_copy while
> > >>>>>guest TX uses grant_map to do zero-copy transmit.
> > >>>As I understand, the RX process is as follows:
> > >>>1. Phy NIC receive packet
> > >>>2. XEN Hypervisor trigger interrupt to Dom0 3. Dom0' s NIC driver
> > >>>do the "RX" operation, and the packet is stored into SKB which is
> > >>>also owned/shared with netback
> > >>Not that easy. There is something between the NIC driver and netback
> > >>which directs the packets, e.g. the old bridge driver, ovs, or the IP stack of
> the kernel.
> > >>>4. NetBack notify netfront through event channel that a packet is
> > >>>receiving 5. Netfront grant a buffer for receiving and notify
> > >>>netback the GR (if using grant-resue mechanism, netfront just
> > >>>notify the GR to
> > >>>netback) through IO Ring
> > >>It looks a bit confusing in the code, but netfront put "requests" on
> > >>the ring buffer, which contains the grant ref of the guest page
> > >>where the backend can copy. When the packet comes, netback consumes
> > >>these requests and send back a response telling the guest the grant
> > >>copy of the packet finished, it can start handling the data.
> > >>(sending a response means it's placing a response in the ring and
> > >>trigger the event channel) And ideally netback should always have requests
> in the ring, so it doesn't have to wait for the guest to fill it up.
> > >
> > >>>6. NetBack do the grant_copy to copy packet from its SKB to the
> > >>>buffer referenced by GR, and notify netfront through event channel 7.
> > >>>Netfront copy the data from buffer to user-level app's SKB
> > >>Or wherever that SKB should go, yes. Like with any received packet
> > >>on a real network interface.
> > >>>
> > >>>Am I right? Why not using zero-copy transmit in guest RX data pash too ?
> > >>Because that means you are mapping that memory to the guest, and you
> > >>won't have any guarantee when the guest will release them. And
> > >>netback can't just unmap them forcibly after a timeout, because
> > >>finding a correct timeout value would be quite impossible.
> > >>A malicious/buggy/overloaded guest can hold on to Dom0 memory
> > >>indefinitely, but it even becomes worse if the memory came from
> > >>another
> > >>guest: you can't shutdown that guest for example, until all its
> > >>memory is returned to him.
> > >
> > >Thanks for your detailed explanation about RX data path, I have get
> > >it, :)
> > >
> > >About the issue that poor performance between DomU to DomU, but high
> throughout between Dom0 to remote Dom0/DomU mentioned in my previous
> mail, do you have any idea about it?
> > >
> > >I am wondering if netfront/netback can be optimized to reach the 10Gbps
> throughout between DomUs running on different hosts connected with 10GE
> network. Currently, it seems like the TX is not the bottleneck, because we can
> reach the aggregate throughout of 9Gbps when sending packets from one
> DomU to other 3 DomUs running on different host. So I think the bottleneck
> maybe the RX, are you agreed with me?
> > >
> > >I am wondering what is the main reason that prevent RX to reach the higher
> throughout? Compared to KVM+virtio+vhost, which can reach high throughout,
> the RX has extra grantcopy operation, and the grantcopy operation may be one
> reason for it. Do you have any idea about it too?
> > It's quite sure that the grant copy is the bottleneck for a single
> > queue RX traffic. I don't know what's the plan to help that, currently
> > only a faster CPU can help you with that.
> 
> Could the Intel QuickData help with that?

Thanks for your hit. 
I am looking for method which is independent on hardware. Because I have seen that virtio can reach the 10Gbps throughout, and I think PV network protocol which is the mainline of XEN should also reach the throughout. However, the testing results show that it is not ideal, so I am wondering what the possible reason is and if PV network protocol can be optimized.

> >
> > >
> > >>
> > >>Regards,
> > >>
> > >>Zoli
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Dec 08 06:51:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 06:51:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxs9j-00056O-6z; Mon, 08 Dec 2014 06:50:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1Xxs9h-00056J-Fm
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 06:50:49 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	62/90-25276-84A45845; Mon, 08 Dec 2014 06:50:48 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418021443!14033932!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 656 invoked from network); 8 Dec 2014 06:50:47 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 06:50:47 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AYI58952; Mon, 08 Dec 2014 14:50:26 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.62]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Mon, 8 Dec 2014 14:50:16 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Zoltan Kiss
	<zoltan.kiss@linaro.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIAAiqFg//+jdIAAEh4VUAAj3QuAAAaAAwAAjyHxcA==
Date: Mon, 8 Dec 2014 06:50:15 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2394B199@SZXEMA512-MBX.china.huawei.com>
References: <3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393371E@SZXEMA512-MBX.china.huawei.com>
	<54806315.6010007@linaro.org>
	<3A6795EA1206904E94BEC8EF9DF109AE23933926@SZXEMA512-MBX.china.huawei.com>
	<5481CD57.607@linaro.org> <20141205182702.GA4754@laptop.dumpdata.com>
In-Reply-To: <20141205182702.GA4754@laptop.dumpdata.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020202.54854A35.03CF, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.62,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2c17022d9804b70b5280b9a23b4c1bed
Cc: "jonathan.davies@citrix.com" <jonathan.davies@citrix.com>, "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Fri, Dec 05, 2014 at 03:20:55PM +0000, Zoltan Kiss wrote:
> >
> >
> > On 04/12/14 14:31, Zhangleiqiang (Trump) wrote:
> > >>-----Original Message-----
> > >>From: Zoltan Kiss [mailto:zoltan.kiss@linaro.org]
> > >>Sent: Thursday, December 04, 2014 9:35 PM
> > >>To: Zhangleiqiang (Trump); Wei Liu; xen-devel@lists.xen.org
> > >>Cc: Xiaoding (B); Zhuangyuxin; zhangleiqiang; Luohao (brian); Yuzhou
> > >>(C)
> > >>Subject: Re: [Xen-devel] Poor network performance between DomU with
> > >>multiqueue support
> > >>
> > >>
> > >>
> > >>On 04/12/14 12:09, Zhangleiqiang (Trump) wrote:
> > >>>>I think that's expected, because guest RX data path still uses
> > >>>>grant_copy while
> > >>>>>guest TX uses grant_map to do zero-copy transmit.
> > >>>As I understand, the RX process is as follows:
> > >>>1. Phy NIC receive packet
> > >>>2. XEN Hypervisor trigger interrupt to Dom0 3. Dom0' s NIC driver
> > >>>do the "RX" operation, and the packet is stored into SKB which is
> > >>>also owned/shared with netback
> > >>Not that easy. There is something between the NIC driver and netback
> > >>which directs the packets, e.g. the old bridge driver, ovs, or the IP stack of
> the kernel.
> > >>>4. NetBack notify netfront through event channel that a packet is
> > >>>receiving 5. Netfront grant a buffer for receiving and notify
> > >>>netback the GR (if using grant-resue mechanism, netfront just
> > >>>notify the GR to
> > >>>netback) through IO Ring
> > >>It looks a bit confusing in the code, but netfront put "requests" on
> > >>the ring buffer, which contains the grant ref of the guest page
> > >>where the backend can copy. When the packet comes, netback consumes
> > >>these requests and send back a response telling the guest the grant
> > >>copy of the packet finished, it can start handling the data.
> > >>(sending a response means it's placing a response in the ring and
> > >>trigger the event channel) And ideally netback should always have requests
> in the ring, so it doesn't have to wait for the guest to fill it up.
> > >
> > >>>6. NetBack do the grant_copy to copy packet from its SKB to the
> > >>>buffer referenced by GR, and notify netfront through event channel 7.
> > >>>Netfront copy the data from buffer to user-level app's SKB
> > >>Or wherever that SKB should go, yes. Like with any received packet
> > >>on a real network interface.
> > >>>
> > >>>Am I right? Why not using zero-copy transmit in guest RX data pash too ?
> > >>Because that means you are mapping that memory to the guest, and you
> > >>won't have any guarantee when the guest will release them. And
> > >>netback can't just unmap them forcibly after a timeout, because
> > >>finding a correct timeout value would be quite impossible.
> > >>A malicious/buggy/overloaded guest can hold on to Dom0 memory
> > >>indefinitely, but it even becomes worse if the memory came from
> > >>another
> > >>guest: you can't shutdown that guest for example, until all its
> > >>memory is returned to him.
> > >
> > >Thanks for your detailed explanation about RX data path, I have get
> > >it, :)
> > >
> > >About the issue that poor performance between DomU to DomU, but high
> throughout between Dom0 to remote Dom0/DomU mentioned in my previous
> mail, do you have any idea about it?
> > >
> > >I am wondering if netfront/netback can be optimized to reach the 10Gbps
> throughout between DomUs running on different hosts connected with 10GE
> network. Currently, it seems like the TX is not the bottleneck, because we can
> reach the aggregate throughout of 9Gbps when sending packets from one
> DomU to other 3 DomUs running on different host. So I think the bottleneck
> maybe the RX, are you agreed with me?
> > >
> > >I am wondering what is the main reason that prevent RX to reach the higher
> throughout? Compared to KVM+virtio+vhost, which can reach high throughout,
> the RX has extra grantcopy operation, and the grantcopy operation may be one
> reason for it. Do you have any idea about it too?
> > It's quite sure that the grant copy is the bottleneck for a single
> > queue RX traffic. I don't know what's the plan to help that, currently
> > only a faster CPU can help you with that.
> 
> Could the Intel QuickData help with that?

Thanks for your hit. 
I am looking for method which is independent on hardware. Because I have seen that virtio can reach the 10Gbps throughout, and I think PV network protocol which is the mainline of XEN should also reach the throughout. However, the testing results show that it is not ideal, so I am wondering what the possible reason is and if PV network protocol can be optimized.

> >
> > >
> > >>
> > >>Regards,
> > >>
> > >>Zoli
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Dec 08 06:55:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 06:55:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxsDt-0005Q5-UC; Mon, 08 Dec 2014 06:55:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XxsDs-0005Q0-7I
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 06:55:08 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	86/41-02702-B4B45845; Mon, 08 Dec 2014 06:55:07 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418021110!8166574!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23450 invoked from network); 8 Dec 2014 06:45:13 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 06:45:13 -0000
Received: from 172.24.2.119 (EHLO szxema411-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CFS59578; Mon, 08 Dec 2014 14:44:38 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.62]) by
	szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id
	14.03.0158.001; Mon, 8 Dec 2014 14:44:27 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIABdSnQgAA8hYCABNK9gA==
Date: Mon, 8 Dec 2014 06:44:26 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
In-Reply-To: <20141205124233.GD31446@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Zhangleiqiang \(Trump\)" <zhangleiqiang@huawei.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>, "Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
> [...]
> > > I think that's expected, because guest RX data path still uses
> > > grant_copy while guest TX uses grant_map to do zero-copy transmit.
> >
> > As far as I know, there are three main grant-related operations used in split
> device model: grant mapping, grant transfer and grant copy.
> > Grant transfer has not used now, and grant mapping and grant transfer both
> involve "TLB" refresh work for hypervisor, am I right?  Or only grant transfer
> has this overhead?
> 
> Transfer is not used so I can't tell. Grant unmap causes TLB flush.
> 
> I saw in an email the other day XenServer folks has some planned improvement
> to avoid TLB flush in Xen to upstream in 4.6 window. I can't speak for sure it will
> get upstreamed as I don't work on that.
> 
> > Does grant copy surely has more overhead than grant mapping?
> >
> 
> At the very least the zero-copy TX path is faster than previous copying path.
> 
> But speaking of the micro operation I'm not sure.
> 
> There was once persistent map prototype netback / netfront that establishes a
> memory pool between FE and BE then use memcpy to copy data. Unfortunately
> that prototype was not done right so the result was not good.

The newest mail about persistent grant I can find is sent from 16 Nov 2012 (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00832.html). Why is it not done right and not merged into upstream?

And I also search for virtio support in XEN, and I find that the one who are familiar with it is you, too, (http://wiki.xen.org/wiki/Virtio_On_Xen), :-). I am wondering what is the current state for virtio on XEN?

> > >From the code, I see that in TX, netback will do gnttab_batch_copy as well
> as gnttab_map_refs:
> >
> > <code> //netback.c:xenvif_tx_action
> > 	xenvif_tx_build_gops(queue, budget, &nr_cops, &nr_mops);
> >
> > 	if (nr_cops == 0)
> > 		return 0;
> >
> > 	gnttab_batch_copy(queue->tx_copy_ops, nr_cops);
> > 	if (nr_mops != 0) {
> > 		ret = gnttab_map_refs(queue->tx_map_ops,
> > 				      NULL,
> > 				      queue->pages_to_map,
> > 				      nr_mops);
> > 		BUG_ON(ret);
> > 	}
> > </code>
> >
> 
> The copy is for the packet header. Mapping is for packet data.
> 
> We need to copy header from guest so that it doesn't change under netback's
> feet.
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 06:55:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 06:55:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxsDt-0005Q5-UC; Mon, 08 Dec 2014 06:55:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XxsDs-0005Q0-7I
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 06:55:08 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	86/41-02702-B4B45845; Mon, 08 Dec 2014 06:55:07 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418021110!8166574!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23450 invoked from network); 8 Dec 2014 06:45:13 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 06:45:13 -0000
Received: from 172.24.2.119 (EHLO szxema411-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CFS59578; Mon, 08 Dec 2014 14:44:38 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.62]) by
	szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id
	14.03.0158.001; Mon, 8 Dec 2014 14:44:27 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIABdSnQgAA8hYCABNK9gA==
Date: Mon, 8 Dec 2014 06:44:26 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
References: <E14A34B5-F70E-42D4-9A0F-15052CC8A81E@gmail.com>
	<20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
In-Reply-To: <20141205124233.GD31446@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Zhangleiqiang \(Trump\)" <zhangleiqiang@huawei.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>, "Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
> [...]
> > > I think that's expected, because guest RX data path still uses
> > > grant_copy while guest TX uses grant_map to do zero-copy transmit.
> >
> > As far as I know, there are three main grant-related operations used in split
> device model: grant mapping, grant transfer and grant copy.
> > Grant transfer has not used now, and grant mapping and grant transfer both
> involve "TLB" refresh work for hypervisor, am I right?  Or only grant transfer
> has this overhead?
> 
> Transfer is not used so I can't tell. Grant unmap causes TLB flush.
> 
> I saw in an email the other day XenServer folks has some planned improvement
> to avoid TLB flush in Xen to upstream in 4.6 window. I can't speak for sure it will
> get upstreamed as I don't work on that.
> 
> > Does grant copy surely has more overhead than grant mapping?
> >
> 
> At the very least the zero-copy TX path is faster than previous copying path.
> 
> But speaking of the micro operation I'm not sure.
> 
> There was once persistent map prototype netback / netfront that establishes a
> memory pool between FE and BE then use memcpy to copy data. Unfortunately
> that prototype was not done right so the result was not good.

The newest mail about persistent grant I can find is sent from 16 Nov 2012 (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00832.html). Why is it not done right and not merged into upstream?

And I also search for virtio support in XEN, and I find that the one who are familiar with it is you, too, (http://wiki.xen.org/wiki/Virtio_On_Xen), :-). I am wondering what is the current state for virtio on XEN?

> > >From the code, I see that in TX, netback will do gnttab_batch_copy as well
> as gnttab_map_refs:
> >
> > <code> //netback.c:xenvif_tx_action
> > 	xenvif_tx_build_gops(queue, budget, &nr_cops, &nr_mops);
> >
> > 	if (nr_cops == 0)
> > 		return 0;
> >
> > 	gnttab_batch_copy(queue->tx_copy_ops, nr_cops);
> > 	if (nr_mops != 0) {
> > 		ret = gnttab_map_refs(queue->tx_map_ops,
> > 				      NULL,
> > 				      queue->pages_to_map,
> > 				      nr_mops);
> > 		BUG_ON(ret);
> > 	}
> > </code>
> >
> 
> The copy is for the packet header. Mapping is for packet data.
> 
> We need to copy header from guest so that it doesn't change under netback's
> feet.
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 07:09:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07: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 1XxsR0-0005x7-8u; Mon, 08 Dec 2014 07:08:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XxsQy-0005x2-37
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 07:08:40 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	37/E0-27584-77E45845; Mon, 08 Dec 2014 07:08:39 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418022517!12068726!1
X-Originating-IP: [66.165.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 12253 invoked from network); 8 Dec 2014 07:08:38 -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;
	8 Dec 2014 07:08:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,536,1413244800"; d="scan'208";a="201277176"
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.210.2; Mon, 8 Dec 2014 02:08:36 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XxsQu-0000Qq-0r;
	Mon, 08 Dec 2014 07:08:36 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxsQt-00086z-BS;
	Mon, 08 Dec 2014 07:08:35 +0000
Date: Mon, 8 Dec 2014 07:08:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32131-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11594
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 32131: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8121357602162000226=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8121357602162000226==
Content-Type: text/plain
Content-Length: 11356
Content-Transfer-Encoding: quoted-printable

flight 32131 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32131/

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. 31838
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install    fail REGR. vs. 31838

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31838

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-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-qemut-winxpsp3 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-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-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                356a3e1fde11190febb8ace3cdab8694848ed220
baseline version:
 linux                2dc2565902d3c24108c4b7101e91957fd068a242

------------------------------------------------------------
People who touched revisions under test:
  "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
  Aaro Koskinen <aaro.koskinen@iki.fi>
  Aaro Koskinen <aaro.koskinen@nsn.com>
  Aaron Ma <mapengyu@gmail.com>
  Alan Stern <stern@rowland.harvard.edu>
  Alex Deucher <alexander.deucher@amd.com>
  Alexey Khoroshilov <khoroshilov@ispras.ru>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Gospodarek <gospo@cumulusnetworks.com>
  Andy Lutomirski <luto@amacapital.net>
  Bart Van Assche <bvanassche@acm.org>
  Ben Sagal <bensagal@gmail.com>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Benjamin LaHaise <bcrl@kvack.org>
  Binyamin Sagal <bensagal@gmail.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bj=C3=B8rn Mork <bjorn@mork.no>
  Borislav Petkov <bp@suse.de>
  Brian Norris <computersforpeace@gmail.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Moore <chris.moore@emulex.com>
  Chris Webb <chris@arachsys.com>
  Christian S=C3=BCnkenberg <christian.suenkenberg@hfg-karlsruhe.de>
  Christoph Hellwig <hch@lst.de>
  Cong Wang <cwang@twopensource.com>
  Cong Wang <xiyou.wangcong@gmail.com>
  Cristina Ciocan <cristina.ciocan@intel.com>
  Daniel Lezcano <daniel.lezcano@linaro.org>
  Dave Hansen <dave.hansen@linux.intel.com>
  David Jeffery <djeffery@redhat.com>
  David S. Miller <davem@davemloft.net>
  Ding Tianhong <dingtianhong@huawei.com>
  Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
  Dmitry Torokhov <dmitry.torokhov@gmail.com>
  Fabio Estevam <fabio.estevam@freescale.com>
  Felipe Balbi <balbi@ti.com>
  Grant Likely <grant.likely@linaro.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Gregory CLEMENT <gregory.clement@free-electrons.com>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hans de Goede <hdegoede@redhat.com>
  Ingo Molnar <mingo@kernel.org>
  J. Bruce Fields <bfields@fieldses.org>
  J. Bruce Fields <bfields@redhat.com>
  Jane Zhou <a17711@motorola.com>
  Jason Cooper <jason@lakedaemon.net>
  Jeff Layton <jlayton@primarydata.com>
  Jeff Layton <jlayton@redhat.com>
  Jet Chen <jet.chen@intel.com>
  Jiri Bohac <jbohac@suse.cz>
  Johan Hovold <johan@kernel.org>
  John W. Linville <linville@tuxdriver.com>
  Jonathan Cameron <jic23@kernel.org>
  Jurgen Kramer <gtmkramer@xs4all.nl>
  Kamal Mostafa <kamal@canonical.com>
  Kees Cook <keescook@chromium.org>
  Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
  Larry Finger <Larry.Finger@lwfinger.net>
  Laurent Dufour <ldufour@linux.vnet.ibm.com>
  Liam Girdwood <liam.r.girdwood@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lu Baolu <baolu.lu@linux.intel.com>
  Marc Kleine-Budde <mkl@pengutronix.de>
  Mark Brown <broonie@kernel.org>
  Mark Rutland <mark.rutland@arm.com>
  Martin Hauke <mardnh@gmx.de>
  Mathias Krause <minipli@googlemail.com>
  Mathias Nyman <mathias.nyman@linux.intel.com>
  Matthias Fuchs <matthias.fuchs@esd.eu>
  Maurizio Lombardi <mlombard@redhat.com>
  Maxime Coquelin <maxime.coquelin@st.com>
  Maxime Ripard <maxime.ripard@free-electrons.com>
  Miaoqing Pan <miaoqing@qca.qualcomm.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Nadav Haklai <nadavh@marvell.com>
  Nicholas Bellinger <nab@linux-iscsi.org>
  Nikolay Aleksandrov <nikolay@redhat.com>
  Or Gerlitz <ogerlitz@mellanox.com>
  Panu Matilainen <pmatilai@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Preston Fick <pffick@gmail.com>
  Ralf Baechle <ralf@linux-mips.org>
  Rob Herring <robh@kernel.org>
  Robert Jarzmik <robert.jarzmik@free.fr>
  Roland Dreier <roland@purestorage.com>
  Russell King <rmk+kernel@arm.linux.org.uk>
  Sagi Grimberg <sagig@dev.mellanox.co.il>
  Sagi Grimberg <sagig@mellanox.com>
  Srikar Dronamraju <srikar@linux.vnet.ibm.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Sujith Manoharan <c_manoha@qca.qualcomm.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Gleixner <tglx@linutronix.de>
  Thomas K=C3=B6rper <thomas.koerper@esd.eu>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Thor Thayer <tthayer@opensource.altera.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Troy Clark <tclark@matrixorbital.ca>
  Veaceslav Falico <vfalico@gmail.com>
  Vincent BENAYOUN <vincent.benayoun@trust-in-soft.com>
  Vladimir Murzin <vladimir.murzin@arm.com>
  Vlastimil Setka <setka@vsis.cz>
  Will Deacon <will.deacon@arm.com>
  Yinghai Lu <yinghai@kernel.org>
  Yiwei Zhao <gbjc64@motorola.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                                          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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 1881 lines long.)


--===============8121357602162000226==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8121357602162000226==--

From xen-devel-bounces@lists.xen.org Mon Dec 08 07:09:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07: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 1XxsR0-0005x7-8u; Mon, 08 Dec 2014 07:08:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XxsQy-0005x2-37
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 07:08:40 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	37/E0-27584-77E45845; Mon, 08 Dec 2014 07:08:39 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418022517!12068726!1
X-Originating-IP: [66.165.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 12253 invoked from network); 8 Dec 2014 07:08:38 -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;
	8 Dec 2014 07:08:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,536,1413244800"; d="scan'208";a="201277176"
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.210.2; Mon, 8 Dec 2014 02:08:36 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1XxsQu-0000Qq-0r;
	Mon, 08 Dec 2014 07:08:36 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxsQt-00086z-BS;
	Mon, 08 Dec 2014 07:08:35 +0000
Date: Mon, 8 Dec 2014 07:08:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32131-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 11594
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 32131: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8121357602162000226=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8121357602162000226==
Content-Type: text/plain
Content-Length: 11356
Content-Transfer-Encoding: quoted-printable

flight 32131 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32131/

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. 31838
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install    fail REGR. vs. 31838

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31838

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-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-qemut-winxpsp3 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-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-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                356a3e1fde11190febb8ace3cdab8694848ed220
baseline version:
 linux                2dc2565902d3c24108c4b7101e91957fd068a242

------------------------------------------------------------
People who touched revisions under test:
  "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
  Aaro Koskinen <aaro.koskinen@iki.fi>
  Aaro Koskinen <aaro.koskinen@nsn.com>
  Aaron Ma <mapengyu@gmail.com>
  Alan Stern <stern@rowland.harvard.edu>
  Alex Deucher <alexander.deucher@amd.com>
  Alexey Khoroshilov <khoroshilov@ispras.ru>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Gospodarek <gospo@cumulusnetworks.com>
  Andy Lutomirski <luto@amacapital.net>
  Bart Van Assche <bvanassche@acm.org>
  Ben Sagal <bensagal@gmail.com>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Benjamin LaHaise <bcrl@kvack.org>
  Binyamin Sagal <bensagal@gmail.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bj=C3=B8rn Mork <bjorn@mork.no>
  Borislav Petkov <bp@suse.de>
  Brian Norris <computersforpeace@gmail.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Moore <chris.moore@emulex.com>
  Chris Webb <chris@arachsys.com>
  Christian S=C3=BCnkenberg <christian.suenkenberg@hfg-karlsruhe.de>
  Christoph Hellwig <hch@lst.de>
  Cong Wang <cwang@twopensource.com>
  Cong Wang <xiyou.wangcong@gmail.com>
  Cristina Ciocan <cristina.ciocan@intel.com>
  Daniel Lezcano <daniel.lezcano@linaro.org>
  Dave Hansen <dave.hansen@linux.intel.com>
  David Jeffery <djeffery@redhat.com>
  David S. Miller <davem@davemloft.net>
  Ding Tianhong <dingtianhong@huawei.com>
  Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
  Dmitry Torokhov <dmitry.torokhov@gmail.com>
  Fabio Estevam <fabio.estevam@freescale.com>
  Felipe Balbi <balbi@ti.com>
  Grant Likely <grant.likely@linaro.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Gregory CLEMENT <gregory.clement@free-electrons.com>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hans de Goede <hdegoede@redhat.com>
  Ingo Molnar <mingo@kernel.org>
  J. Bruce Fields <bfields@fieldses.org>
  J. Bruce Fields <bfields@redhat.com>
  Jane Zhou <a17711@motorola.com>
  Jason Cooper <jason@lakedaemon.net>
  Jeff Layton <jlayton@primarydata.com>
  Jeff Layton <jlayton@redhat.com>
  Jet Chen <jet.chen@intel.com>
  Jiri Bohac <jbohac@suse.cz>
  Johan Hovold <johan@kernel.org>
  John W. Linville <linville@tuxdriver.com>
  Jonathan Cameron <jic23@kernel.org>
  Jurgen Kramer <gtmkramer@xs4all.nl>
  Kamal Mostafa <kamal@canonical.com>
  Kees Cook <keescook@chromium.org>
  Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
  Larry Finger <Larry.Finger@lwfinger.net>
  Laurent Dufour <ldufour@linux.vnet.ibm.com>
  Liam Girdwood <liam.r.girdwood@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lu Baolu <baolu.lu@linux.intel.com>
  Marc Kleine-Budde <mkl@pengutronix.de>
  Mark Brown <broonie@kernel.org>
  Mark Rutland <mark.rutland@arm.com>
  Martin Hauke <mardnh@gmx.de>
  Mathias Krause <minipli@googlemail.com>
  Mathias Nyman <mathias.nyman@linux.intel.com>
  Matthias Fuchs <matthias.fuchs@esd.eu>
  Maurizio Lombardi <mlombard@redhat.com>
  Maxime Coquelin <maxime.coquelin@st.com>
  Maxime Ripard <maxime.ripard@free-electrons.com>
  Miaoqing Pan <miaoqing@qca.qualcomm.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Nadav Haklai <nadavh@marvell.com>
  Nicholas Bellinger <nab@linux-iscsi.org>
  Nikolay Aleksandrov <nikolay@redhat.com>
  Or Gerlitz <ogerlitz@mellanox.com>
  Panu Matilainen <pmatilai@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Preston Fick <pffick@gmail.com>
  Ralf Baechle <ralf@linux-mips.org>
  Rob Herring <robh@kernel.org>
  Robert Jarzmik <robert.jarzmik@free.fr>
  Roland Dreier <roland@purestorage.com>
  Russell King <rmk+kernel@arm.linux.org.uk>
  Sagi Grimberg <sagig@dev.mellanox.co.il>
  Sagi Grimberg <sagig@mellanox.com>
  Srikar Dronamraju <srikar@linux.vnet.ibm.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Sujith Manoharan <c_manoha@qca.qualcomm.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Gleixner <tglx@linutronix.de>
  Thomas K=C3=B6rper <thomas.koerper@esd.eu>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Thor Thayer <tthayer@opensource.altera.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Troy Clark <tclark@matrixorbital.ca>
  Veaceslav Falico <vfalico@gmail.com>
  Vincent BENAYOUN <vincent.benayoun@trust-in-soft.com>
  Vladimir Murzin <vladimir.murzin@arm.com>
  Vlastimil Setka <setka@vsis.cz>
  Will Deacon <will.deacon@arm.com>
  Yinghai Lu <yinghai@kernel.org>
  Yiwei Zhao <gbjc64@motorola.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                                          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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 1881 lines long.)


--===============8121357602162000226==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8121357602162000226==--

From xen-devel-bounces@lists.xen.org Mon Dec 08 07:11:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07:11:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxsU1-00065O-4q; Mon, 08 Dec 2014 07:11: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 1XxsU0-00065D-5k
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 07:11:48 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	04/27-22777-33F45845; Mon, 08 Dec 2014 07:11:47 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418022705!12066012!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23077 invoked from network); 8 Dec 2014 07:11:46 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-206.messagelabs.com with SMTP;
	8 Dec 2014 07:11:46 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 07 Dec 2014 23:09:54 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,536,1413270000"; d="scan'208";a="650117491"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 07 Dec 2014 23:11:42 -0800
Message-ID: <54854F2D.6060204@intel.com>
Date: Mon, 08 Dec 2014 15:11:41 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
In-Reply-To: <548090BA020000780004CCE6@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/4 23:50, Jan Beulich wrote:
>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> --- a/xen/common/compat/memory.c
>> +++ b/xen/common/compat/memory.c
>> @@ -22,27 +22,66 @@ 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;
>> +    unsigned int i;
>> +    u32 sbdf;
>> +    struct compat_reserved_device_memory rdm = {
>> +        .start_pfn = start, .nr_pages = nr
>> +    };
>>
>> -    if ( grdm->used_entries < grdm->map.nr_entries )
>> -    {
>> -        struct compat_reserved_device_memory rdm = {
>> -            .start_pfn = start, .nr_pages = nr
>> -        };
>> +    if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>> +        return -ERANGE;
>>
>> -        if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>> -            return -ERANGE;
>> +    d = rcu_lock_domain_by_any_id(grdm->map.domid);
>> +    if ( d == NULL )
>> +        return -ESRCH;
>
> So why are you doing this in the call back (potentially many times)
> instead of just once in compat_memory_op(), storing the pointer in
> the context structure?

Okay.

>
>>
>> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> -                                     &rdm, 1) )
>> -            return -EFAULT;
>> +    if ( d )
>> +    {
>> +        if ( d->arch.hvm_domain.pci_force )
>
> You didn't verify that the domain is a HVM/PVH one.

Is this, ASSERT(is_hvm_domain(grdm.domain)), correct?

>
>> +        {
>> +            if ( grdm->used_entries < grdm->map.nr_entries )
>> +            {
>> +                if ( __copy_to_compat_offset(grdm->map.buffer,
>> +                                             grdm->used_entries,
>> +                                             &rdm, 1) )
>> +                {
>> +                    rcu_unlock_domain(d);
>> +                    return -EFAULT;
>> +                }
>> +            }
>> +            ++grdm->used_entries;
>> +        }
>> +        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 ( grdm->used_entries < grdm->map.nr_entries )
>> +                    {
>> +                        if ( __copy_to_compat_offset(grdm->map.buffer,
>> +                                                     grdm->used_entries,
>> +                                                     &rdm, 1) )
>> +                        {
>> +                            rcu_unlock_domain(d);
>> +                            return -EFAULT;
>> +                        }
>> +                    }
>> +                    ++grdm->used_entries;
>
> break;

Added.

>
> Also trying to fold code identical on the if and else branches would
> seem pretty desirable.

Sorry, I can't see what I'm missing.

>
>> @@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>>
>>               if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>>                   rc = -ENOBUFS;
>> +
>>               grdm.map.nr_entries = grdm.used_entries;
>> -            if ( __copy_to_guest(compat, &grdm.map, 1) )
>> -                rc = -EFAULT;
>> +            if ( grdm.map.nr_entries )
>> +            {
>> +                if ( __copy_to_guest(compat, &grdm.map, 1) )
>> +                    rc = -EFAULT;
>> +            }
>
> Why do you need this change?

If we have no any entries, why do we still copy that?

>
>> --- a/xen/drivers/passthrough/vtd/dmar.c
>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>> @@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
>>
>>   int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>   {
>> -    struct acpi_rmrr_unit *rmrr;
>> +    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
>>       int rc = 0;
>> +    unsigned 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 ( 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;
>> +
>> +            /* Just go next. */
>> +            if ( !rc )
>> +                rmrr_cur = rmrr;
>> +
>> +            /* Now just return specific to user requirement. */
>> +            if ( rc > 0 )
>> +                return rc;
>
> Nice that you check for that, but I can't see this case occurring
> anymore. Did you lose some code? Also please don't write code

We have three scenarios here:

#1 rc < 0 means this is an error;
#2 rc = 0 means the tools caller don't know how many buffers it should 
construct, so we need to count all entries as 'nr_entries' to return.
#3 rc > 0 means in some cases, we need to return some specific values, 
like 1 to indicate we're hitting some RMRR range. Currently, we use gfn 
to check this in case of memory populating, ept violation handler and 
mem_access.

> more complicated than necessary. The above two if()s could be
>
>
> +            if ( rc > 0 )
> +                return rc;
> +
> +            rmrr_cur = rmrr;
>
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -586,6 +586,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 */
>
> Your addition lacks an IN annotation.

Are you saying something for 'nr_entries'? But I didn't introduce 
anything to change the original usage. Anyway, I try to improve this,

     /*
      * IN: on call the number of entries which can be stored in buffer.
      * OUT: on return the number of entries which have been stored in
      * buffer. If on call the number is less the number of all necessary
      * entries, on return the number of entries which is needed.
      */


>
>> --- 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))
>
> Missing several parentheses.
>

Okay,

#define PCI_SBDF(s,bdf) ((((s) & 0xffff) << 16) | ((bdf) & 0xffff))
#define PCI_SBDF2(s,b,df) ((((s) & 0xffff) << 16) | PCI_BDF2(b,df))


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 Dec 08 07:11:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07:11:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxsU1-00065O-4q; Mon, 08 Dec 2014 07:11: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 1XxsU0-00065D-5k
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 07:11:48 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	04/27-22777-33F45845; Mon, 08 Dec 2014 07:11:47 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418022705!12066012!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23077 invoked from network); 8 Dec 2014 07:11:46 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-206.messagelabs.com with SMTP;
	8 Dec 2014 07:11:46 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 07 Dec 2014 23:09:54 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,536,1413270000"; d="scan'208";a="650117491"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 07 Dec 2014 23:11:42 -0800
Message-ID: <54854F2D.6060204@intel.com>
Date: Mon, 08 Dec 2014 15:11:41 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
In-Reply-To: <548090BA020000780004CCE6@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/4 23:50, Jan Beulich wrote:
>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> --- a/xen/common/compat/memory.c
>> +++ b/xen/common/compat/memory.c
>> @@ -22,27 +22,66 @@ 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;
>> +    unsigned int i;
>> +    u32 sbdf;
>> +    struct compat_reserved_device_memory rdm = {
>> +        .start_pfn = start, .nr_pages = nr
>> +    };
>>
>> -    if ( grdm->used_entries < grdm->map.nr_entries )
>> -    {
>> -        struct compat_reserved_device_memory rdm = {
>> -            .start_pfn = start, .nr_pages = nr
>> -        };
>> +    if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>> +        return -ERANGE;
>>
>> -        if ( rdm.start_pfn != start || rdm.nr_pages != nr )
>> -            return -ERANGE;
>> +    d = rcu_lock_domain_by_any_id(grdm->map.domid);
>> +    if ( d == NULL )
>> +        return -ESRCH;
>
> So why are you doing this in the call back (potentially many times)
> instead of just once in compat_memory_op(), storing the pointer in
> the context structure?

Okay.

>
>>
>> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>> -                                     &rdm, 1) )
>> -            return -EFAULT;
>> +    if ( d )
>> +    {
>> +        if ( d->arch.hvm_domain.pci_force )
>
> You didn't verify that the domain is a HVM/PVH one.

Is this, ASSERT(is_hvm_domain(grdm.domain)), correct?

>
>> +        {
>> +            if ( grdm->used_entries < grdm->map.nr_entries )
>> +            {
>> +                if ( __copy_to_compat_offset(grdm->map.buffer,
>> +                                             grdm->used_entries,
>> +                                             &rdm, 1) )
>> +                {
>> +                    rcu_unlock_domain(d);
>> +                    return -EFAULT;
>> +                }
>> +            }
>> +            ++grdm->used_entries;
>> +        }
>> +        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 ( grdm->used_entries < grdm->map.nr_entries )
>> +                    {
>> +                        if ( __copy_to_compat_offset(grdm->map.buffer,
>> +                                                     grdm->used_entries,
>> +                                                     &rdm, 1) )
>> +                        {
>> +                            rcu_unlock_domain(d);
>> +                            return -EFAULT;
>> +                        }
>> +                    }
>> +                    ++grdm->used_entries;
>
> break;

Added.

>
> Also trying to fold code identical on the if and else branches would
> seem pretty desirable.

Sorry, I can't see what I'm missing.

>
>> @@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>>
>>               if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>>                   rc = -ENOBUFS;
>> +
>>               grdm.map.nr_entries = grdm.used_entries;
>> -            if ( __copy_to_guest(compat, &grdm.map, 1) )
>> -                rc = -EFAULT;
>> +            if ( grdm.map.nr_entries )
>> +            {
>> +                if ( __copy_to_guest(compat, &grdm.map, 1) )
>> +                    rc = -EFAULT;
>> +            }
>
> Why do you need this change?

If we have no any entries, why do we still copy that?

>
>> --- a/xen/drivers/passthrough/vtd/dmar.c
>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>> @@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
>>
>>   int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>   {
>> -    struct acpi_rmrr_unit *rmrr;
>> +    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
>>       int rc = 0;
>> +    unsigned 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 ( 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;
>> +
>> +            /* Just go next. */
>> +            if ( !rc )
>> +                rmrr_cur = rmrr;
>> +
>> +            /* Now just return specific to user requirement. */
>> +            if ( rc > 0 )
>> +                return rc;
>
> Nice that you check for that, but I can't see this case occurring
> anymore. Did you lose some code? Also please don't write code

We have three scenarios here:

#1 rc < 0 means this is an error;
#2 rc = 0 means the tools caller don't know how many buffers it should 
construct, so we need to count all entries as 'nr_entries' to return.
#3 rc > 0 means in some cases, we need to return some specific values, 
like 1 to indicate we're hitting some RMRR range. Currently, we use gfn 
to check this in case of memory populating, ept violation handler and 
mem_access.

> more complicated than necessary. The above two if()s could be
>
>
> +            if ( rc > 0 )
> +                return rc;
> +
> +            rmrr_cur = rmrr;
>
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -586,6 +586,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 */
>
> Your addition lacks an IN annotation.

Are you saying something for 'nr_entries'? But I didn't introduce 
anything to change the original usage. Anyway, I try to improve this,

     /*
      * IN: on call the number of entries which can be stored in buffer.
      * OUT: on return the number of entries which have been stored in
      * buffer. If on call the number is less the number of all necessary
      * entries, on return the number of entries which is needed.
      */


>
>> --- 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))
>
> Missing several parentheses.
>

Okay,

#define PCI_SBDF(s,bdf) ((((s) & 0xffff) << 16) | ((bdf) & 0xffff))
#define PCI_SBDF2(s,b,df) ((((s) & 0xffff) << 16) | PCI_BDF2(b,df))


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 Dec 08 07:25:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxsh6-0006eM-EH; Mon, 08 Dec 2014 07:25:20 +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 1Xxsh4-0006eH-QU
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 07:25:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	ED/B2-15461-E5255845; Mon, 08 Dec 2014 07:25:18 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418023516!14001435!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9280 invoked from network); 8 Dec 2014 07:25:16 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-21.messagelabs.com with SMTP;
	8 Dec 2014 07:25:16 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 07 Dec 2014 23:25:15 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,537,1413270000"; d="scan'208";a="650121394"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 07 Dec 2014 23:25:12 -0800
Message-ID: <54855258.5070509@intel.com>
Date: Mon, 08 Dec 2014 15:25: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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-6-git-send-email-tiejun.chen@intel.com>
	<20141202195017.GE357@laptop.dumpdata.com>
In-Reply-To: <20141202195017.GE357@laptop.dumpdata.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 05/17] tools/libxc: introduce hypercall
	for xc_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/3 3:50, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 05:24:23PM +0800, Tiejun Chen wrote:
>> We will introduce that hypercall xc_reserved_device_memory_map
>> approach to libxc.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   tools/libxc/include/xenctrl.h |  5 +++++
>>   tools/libxc/xc_domain.c       | 30 ++++++++++++++++++++++++++++++
>>   2 files changed, 35 insertions(+)
>>
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index 84012fe..a3aeac3 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -1294,6 +1294,11 @@ int xc_domain_set_memory_map(xc_interface *xch,
>>   int xc_get_machine_memory_map(xc_interface *xch,
>>                                 struct e820entry entries[],
>>                                 uint32_t max_entries);
>> +
>> +int xc_reserved_device_memory_map(xc_interface *xch,
>> +                                  uint32_t dom,
>> +                                  struct xen_reserved_device_memory entries[],
>> +                                  uint32_t *max_entries);
>>   #endif
>>   int xc_domain_set_time_offset(xc_interface *xch,
>>                                 uint32_t domid,
>> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
>> index 7fd43e9..09fd988 100644
>> --- a/tools/libxc/xc_domain.c
>> +++ b/tools/libxc/xc_domain.c
>> @@ -679,6 +679,36 @@ int xc_domain_set_memory_map(xc_interface *xch,
>>
>>       return rc;
>>   }
>> +
>> +int xc_reserved_device_memory_map(xc_interface *xch,
>> +                                  uint32_t domid,
>> +                                  struct xen_reserved_device_memory entries[],
>> +                                  uint32_t *max_entries)
>> +{
>> +    int rc;
>> +    struct xen_reserved_device_memory_map xrdmmap = {
>> +        .domid = domid,
>> +        .nr_entries = *max_entries
>> +    };
>> +    DECLARE_HYPERCALL_BOUNCE(entries,
>> +                             sizeof(struct xen_reserved_device_memory) *
>> +                             *max_entries, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
>> +
>> +    if ( xc_hypercall_bounce_pre(xch, entries) )
>> +        return -1;
>> +
>> +    set_xen_guest_handle(xrdmmap.buffer, entries);
>> +
>> +    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
>> +                      &xrdmmap, sizeof(xrdmmap));
>> +
>> +    xc_hypercall_bounce_post(xch, entries);
>> +
>> +    *max_entries = xrdmmap.nr_entries;
>> +
>
> I would bake the -EAGAIN support in here to loop here.
>
> See how the xc_domain_destroy does it.

Do you mean this change?

@@ -699,8 +699,10 @@ int xc_reserved_device_memory_map(xc_interface *xch,

      set_xen_guest_handle(xrdmmap.buffer, entries);

-    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
-                      &xrdmmap, sizeof(xrdmmap));
+    do {
+        rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
+                          &xrdmmap, sizeof(xrdmmap));
+    } while ( rc && (errno == EAGAIN) );

      xc_hypercall_bounce_post(xch, entries);

Thanks
Tiejun

>> +    return rc ? rc : xrdmmap.nr_entries;
>> +}
>> +
>>   int xc_get_machine_memory_map(xc_interface *xch,
>>                                 struct e820entry entries[],
>>                                 uint32_t max_entries)
>> --
>> 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 Dec 08 07:25:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxsh6-0006eM-EH; Mon, 08 Dec 2014 07:25:20 +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 1Xxsh4-0006eH-QU
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 07:25:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	ED/B2-15461-E5255845; Mon, 08 Dec 2014 07:25:18 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418023516!14001435!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9280 invoked from network); 8 Dec 2014 07:25:16 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-21.messagelabs.com with SMTP;
	8 Dec 2014 07:25:16 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 07 Dec 2014 23:25:15 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,537,1413270000"; d="scan'208";a="650121394"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 07 Dec 2014 23:25:12 -0800
Message-ID: <54855258.5070509@intel.com>
Date: Mon, 08 Dec 2014 15:25: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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-6-git-send-email-tiejun.chen@intel.com>
	<20141202195017.GE357@laptop.dumpdata.com>
In-Reply-To: <20141202195017.GE357@laptop.dumpdata.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 05/17] tools/libxc: introduce hypercall
	for xc_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/3 3:50, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 05:24:23PM +0800, Tiejun Chen wrote:
>> We will introduce that hypercall xc_reserved_device_memory_map
>> approach to libxc.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   tools/libxc/include/xenctrl.h |  5 +++++
>>   tools/libxc/xc_domain.c       | 30 ++++++++++++++++++++++++++++++
>>   2 files changed, 35 insertions(+)
>>
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index 84012fe..a3aeac3 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -1294,6 +1294,11 @@ int xc_domain_set_memory_map(xc_interface *xch,
>>   int xc_get_machine_memory_map(xc_interface *xch,
>>                                 struct e820entry entries[],
>>                                 uint32_t max_entries);
>> +
>> +int xc_reserved_device_memory_map(xc_interface *xch,
>> +                                  uint32_t dom,
>> +                                  struct xen_reserved_device_memory entries[],
>> +                                  uint32_t *max_entries);
>>   #endif
>>   int xc_domain_set_time_offset(xc_interface *xch,
>>                                 uint32_t domid,
>> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
>> index 7fd43e9..09fd988 100644
>> --- a/tools/libxc/xc_domain.c
>> +++ b/tools/libxc/xc_domain.c
>> @@ -679,6 +679,36 @@ int xc_domain_set_memory_map(xc_interface *xch,
>>
>>       return rc;
>>   }
>> +
>> +int xc_reserved_device_memory_map(xc_interface *xch,
>> +                                  uint32_t domid,
>> +                                  struct xen_reserved_device_memory entries[],
>> +                                  uint32_t *max_entries)
>> +{
>> +    int rc;
>> +    struct xen_reserved_device_memory_map xrdmmap = {
>> +        .domid = domid,
>> +        .nr_entries = *max_entries
>> +    };
>> +    DECLARE_HYPERCALL_BOUNCE(entries,
>> +                             sizeof(struct xen_reserved_device_memory) *
>> +                             *max_entries, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
>> +
>> +    if ( xc_hypercall_bounce_pre(xch, entries) )
>> +        return -1;
>> +
>> +    set_xen_guest_handle(xrdmmap.buffer, entries);
>> +
>> +    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
>> +                      &xrdmmap, sizeof(xrdmmap));
>> +
>> +    xc_hypercall_bounce_post(xch, entries);
>> +
>> +    *max_entries = xrdmmap.nr_entries;
>> +
>
> I would bake the -EAGAIN support in here to loop here.
>
> See how the xc_domain_destroy does it.

Do you mean this change?

@@ -699,8 +699,10 @@ int xc_reserved_device_memory_map(xc_interface *xch,

      set_xen_guest_handle(xrdmmap.buffer, entries);

-    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
-                      &xrdmmap, sizeof(xrdmmap));
+    do {
+        rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
+                          &xrdmmap, sizeof(xrdmmap));
+    } while ( rc && (errno == EAGAIN) );

      xc_hypercall_bounce_post(xch, entries);

Thanks
Tiejun

>> +    return rc ? rc : xrdmmap.nr_entries;
>> +}
>> +
>>   int xc_get_machine_memory_map(xc_interface *xch,
>>                                 struct e820entry entries[],
>>                                 uint32_t max_entries)
>> --
>> 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 Dec 08 07:35:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxsqV-0006zP-GL; Mon, 08 Dec 2014 07:35:03 +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 1XxsqU-0006zK-17
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 07:35:02 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	7B/F1-02696-5A455845; Mon, 08 Dec 2014 07:35:01 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418024098!13601582!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 12770 invoked from network); 8 Dec 2014 07:35:00 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 07:35:00 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 00:34:57 -0700
Message-Id: <5485C5170200006600081D20@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 00:34:47 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
In-Reply-To: <20141205160615.GA24938@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Ian.Campbell@citrix.com, 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 12/6/2014 at 12:06 AM, in message
<20141205160615.GA24938@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
wrote: 
> I have to admit I'm confused by the back and forth discussion. It's hard 
> to justify the design of new API without knowing what the constraints 
> and requirements are from your PoV. 
>  
> Here are my two cents, not about details, but about general constraints. 
>  
> There are two layers, one is user of libxl (clients -- xl, libvirt etc) 
> and libxl (the library itself). 
>  
> 1. it's better to *not* have storage management in libxl. 
>  
> It's likely that clients can have their own management functionality 
> already.  I'm told that libvirt has that as well as XAPI. Having this 
> functionality in libxl is a bit redundant and requires lots of work 
> (enlighten libxl on what a disk looks like and call out to various 
> utilities). 

Thanks Wei and Ian for your reply. We did have much discussion around
can/cannot (e.g. xl can finish disk snapshot?) and should/shouldnot
(e.g. disk snapshot process should not in xl? domain_snapshot_delete
should not in libxl?), and confusing because have different ideas. So,
settling it down is helpful.

Talking about libvirt, it does provide storage management but through
storage pools and volumes. But usually, we don't use storage pool/vol
but directly use backend files, then libvirt storage driver can not
manage them. And for libvirt vol, functionality in storage driver is
limited, at least 'snapshot' cannot be done. So, libvirt side also
needs to add codes to handle disk snapshot, quite like xl does.

Following the constraint that it's better NOT to supply disk snapshot
functions in libxl, then we let xl and libvirt do that by themselve
separately, that's OK.

Then I think NO new API needs to be exported in libxl, since:
* saving/restoring memory, there are already APIs.
* disk snapshot work is xl internal, can be put in xl (or xlu).
* handle JSON files is xl internal, can be put in xl.
(these are the main work vm snapshot handles).

Right?

This is quite different from previous document, so better to confirm.

>  
> 2. it's *not* a requirement for xl to have the capability to manage 
> snapshots. 
>  
> It's the same arguement that xl has no idea on how to manage snapshots 
> created by "xl save".  This should ease your concern on having to 
> duplicate code for libvirt and xl.  IMHO the xl only needs to have the 
> capability to create a snapshot and create a domain from a snapshot.

This way it's much easier since we don't need to maintain the snapshot
info in file and don't need to take care of snapshot chain. But I doubt if
that's good?
1. from user's side, it's a very common request to list all snapshots.
2. now for kvm, virsh supplies snapshot-create/delete/list/revert,
   Is it good the xl only supply snapshot-create/revert? After all,
   it's more complicated for user to take care of memory saving file
   and disk snapshot info then 'xl save' (user only needs to take
   care of memory state file).

> The 
> downside is that now xl and libvirt are disconnected, but I think it's 
> fine.

Two things here:
1. connect xl and libvirt, then will need to manage snapshot info in libxl (or
    libxlu) That's not preferred since the initial design. This is not the point
    we discuss here.
2. for xl only, list snapshots and delete snapshots, also need to manage
    snapshot info (in xl)

Considering manage snapshot info in xl, only question is about idl and
gentypes.py, expected structure is as following and expected to be saved
into json file, but it contains xl namespace and libxl namespace things,
gentypes.py will have problem. Better ideas?

typedef struct xl_domain_snapshot {
    char * name;
    char * description;
    uint64_t creation_time;
    char * memory_path;
    int num_disks;
    libxl_disk_snapshot *disks;
    char *parent;
    bool *current;
} xl_domain_snapshot;

Thanks a lot!
Chunyan

> The arguement is that you're not allowed to run two toolstack on 
> the same host (think about xl and xend in previous releases). 
>  
> Do these two constraints make your work easier (or harder)? 
>  
> Regarding JSON API, as Ian said, feel free to hook it up to libxlu. 
>  
> Wei. 
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 07:35:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxsqV-0006zP-GL; Mon, 08 Dec 2014 07:35:03 +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 1XxsqU-0006zK-17
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 07:35:02 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	7B/F1-02696-5A455845; Mon, 08 Dec 2014 07:35:01 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418024098!13601582!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 12770 invoked from network); 8 Dec 2014 07:35:00 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 07:35:00 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 00:34:57 -0700
Message-Id: <5485C5170200006600081D20@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 00:34:47 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
In-Reply-To: <20141205160615.GA24938@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Ian.Campbell@citrix.com, 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 12/6/2014 at 12:06 AM, in message
<20141205160615.GA24938@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
wrote: 
> I have to admit I'm confused by the back and forth discussion. It's hard 
> to justify the design of new API without knowing what the constraints 
> and requirements are from your PoV. 
>  
> Here are my two cents, not about details, but about general constraints. 
>  
> There are two layers, one is user of libxl (clients -- xl, libvirt etc) 
> and libxl (the library itself). 
>  
> 1. it's better to *not* have storage management in libxl. 
>  
> It's likely that clients can have their own management functionality 
> already.  I'm told that libvirt has that as well as XAPI. Having this 
> functionality in libxl is a bit redundant and requires lots of work 
> (enlighten libxl on what a disk looks like and call out to various 
> utilities). 

Thanks Wei and Ian for your reply. We did have much discussion around
can/cannot (e.g. xl can finish disk snapshot?) and should/shouldnot
(e.g. disk snapshot process should not in xl? domain_snapshot_delete
should not in libxl?), and confusing because have different ideas. So,
settling it down is helpful.

Talking about libvirt, it does provide storage management but through
storage pools and volumes. But usually, we don't use storage pool/vol
but directly use backend files, then libvirt storage driver can not
manage them. And for libvirt vol, functionality in storage driver is
limited, at least 'snapshot' cannot be done. So, libvirt side also
needs to add codes to handle disk snapshot, quite like xl does.

Following the constraint that it's better NOT to supply disk snapshot
functions in libxl, then we let xl and libvirt do that by themselve
separately, that's OK.

Then I think NO new API needs to be exported in libxl, since:
* saving/restoring memory, there are already APIs.
* disk snapshot work is xl internal, can be put in xl (or xlu).
* handle JSON files is xl internal, can be put in xl.
(these are the main work vm snapshot handles).

Right?

This is quite different from previous document, so better to confirm.

>  
> 2. it's *not* a requirement for xl to have the capability to manage 
> snapshots. 
>  
> It's the same arguement that xl has no idea on how to manage snapshots 
> created by "xl save".  This should ease your concern on having to 
> duplicate code for libvirt and xl.  IMHO the xl only needs to have the 
> capability to create a snapshot and create a domain from a snapshot.

This way it's much easier since we don't need to maintain the snapshot
info in file and don't need to take care of snapshot chain. But I doubt if
that's good?
1. from user's side, it's a very common request to list all snapshots.
2. now for kvm, virsh supplies snapshot-create/delete/list/revert,
   Is it good the xl only supply snapshot-create/revert? After all,
   it's more complicated for user to take care of memory saving file
   and disk snapshot info then 'xl save' (user only needs to take
   care of memory state file).

> The 
> downside is that now xl and libvirt are disconnected, but I think it's 
> fine.

Two things here:
1. connect xl and libvirt, then will need to manage snapshot info in libxl (or
    libxlu) That's not preferred since the initial design. This is not the point
    we discuss here.
2. for xl only, list snapshots and delete snapshots, also need to manage
    snapshot info (in xl)

Considering manage snapshot info in xl, only question is about idl and
gentypes.py, expected structure is as following and expected to be saved
into json file, but it contains xl namespace and libxl namespace things,
gentypes.py will have problem. Better ideas?

typedef struct xl_domain_snapshot {
    char * name;
    char * description;
    uint64_t creation_time;
    char * memory_path;
    int num_disks;
    libxl_disk_snapshot *disks;
    char *parent;
    bool *current;
} xl_domain_snapshot;

Thanks a lot!
Chunyan

> The arguement is that you're not allowed to run two toolstack on 
> the same host (think about xl and xend in previous releases). 
>  
> Do these two constraints make your work easier (or harder)? 
>  
> Regarding JSON API, as Ian said, feel free to hook it up to libxlu. 
>  
> Wei. 
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 07:49:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07:49:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxt4P-0007LF-4l; Mon, 08 Dec 2014 07:49:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1Xxt4O-0007LA-2s
	for Xen-devel@lists.xensource.com; Mon, 08 Dec 2014 07:49:24 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	72/A7-07724-30855845; Mon, 08 Dec 2014 07:49:23 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418024959!11738655!1
X-Originating-IP: [103.22.144.67]
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 31401 invoked from network); 8 Dec 2014 07:49:22 -0000
Received: from ozlabs.org (HELO ozlabs.org) (103.22.144.67)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 07:49:22 -0000
Received: from authenticated.ozlabs.org (localhost [127.0.0.1])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by ozlabs.org (Postfix) with ESMTPSA id EDEAC1400A0;
	Mon,  8 Dec 2014 18:49:16 +1100 (AEDT)
Date: Mon, 8 Dec 2014 18:49:08 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>, Xen Devel
	<Xen-devel@lists.xensource.com>, Olof Johansson <olof@lixom.net>, Arnd
	Bergmann <arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>
Message-ID: <20141208184908.27bfd605@canb.auug.org.au>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; i586-pc-linux-gnu)
MIME-Version: 1.0
Cc: Russell King <linux@arm.linux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org,
	linux-next@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] linux-next: manual merge of the xen-tip tree with the
	arm-soc tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1808194248610518263=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1808194248610518263==
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/keqifRXUMrFmd1v=HZ4il08"; protocol="application/pgp-signature"

--Sig_/keqifRXUMrFmd1v=HZ4il08
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in
arch/arm/include/asm/dma-mapping.h between commits a3a60f81ee6f
("dma-mapping: replace set_arch_dma_coherent_ops with
arch_setup_dma_ops") and 4bb25789ed28 ("arm: dma-mapping: plumb our
iommu mapping ops into arch_setup_dma_ops") from the arm-soc tree and
commit 3d5391ac6f5e ("arm: introduce is_device_dma_coherent") from the
xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

I also neede this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 8 Dec 2014 18:46:59 +1100
Subject: [PATCH] arm: introduce is_device_dma_coherent merge fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/mm/dma-mapping.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 09645f00bd17..43064cbe58f9 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2058,6 +2058,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_b=
ase, u64 size,
 	else
 		dma_ops =3D arm_get_dma_map_ops(coherent);
=20
+	dev->archdata.dma_coherent =3D coherent;
 	set_dma_ops(dev, dma_ops);
 }
=20
--=20
2.1.3

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/include/asm/dma-mapping.h
index 9410b7e548fc,e6e3446abdf6..000000000000
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@@ -121,13 -121,20 +121,19 @@@ static inline unsigned long dma_max_pfn
  }
  #define dma_max_pfn(dev) dma_max_pfn(dev)
 =20
 -static inline int set_arch_dma_coherent_ops(struct device *dev)
 -{
 -	dev->archdata.dma_coherent =3D true;
 -	set_dma_ops(dev, &arm_coherent_dma_ops);
 -	return 0;
 -}
 -#define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
 +#define arch_setup_dma_ops arch_setup_dma_ops
 +extern void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
 +			       struct iommu_ops *iommu, bool coherent);
 +
 +#define arch_teardown_dma_ops arch_teardown_dma_ops
 +extern void arch_teardown_dma_ops(struct device *dev);
 =20
+ /* do not use this function in a driver */
+ static inline bool is_device_dma_coherent(struct device *dev)
+ {
+ 	return dev->archdata.dma_coherent;
+ }
+=20
  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t padd=
r)
  {
  	unsigned int offset =3D paddr & ~PAGE_MASK;

--Sig_/keqifRXUMrFmd1v=HZ4il08
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUhVf8AAoJEMDTa8Ir7ZwVauYQAJaFQg2K5pLKsuzWje2mAv2r
P2fggQQrBBFC7MO8aWRlJlaz2i9kzkOOIZoJC5sIgSiWIWYptw8K8FPwh78UDHKh
YOXnlVSclL5KP35pok6sqIBNVpjug3DvNlP4ruIQu1BvSne7UZIhlLaLSDlCp7Lj
qybnlefodPOoJOLVOYwI+R2Wa0rhhNbM62PwySPvsvE004VjmdKDQqZvuTrlcezD
Tir3kGgnLkMp+pEVIPfdbkoWZqAjMpKHfRJ/cGM13As4A7BT9kbcI23Duh3Fhb5w
0+qJQW5rOYx/eeJAjKuCCDorcoXaRGNOrd1zKAFbf53HAn4ex/CDd3+/jpsOa0jU
JndBOIjjLcezwQyZZuU+T7Dxdtb/1dVxspLCiRsCkDv9dmljPaY6zDm7LYTIeAbV
+tKTgiPjC79Z7F18H/p2+VSDG9Y9+1A5S/4V+mbTyZdiHnUfKSLsFX1TKmlzQi78
8N99ki0aFKG1t9lHRZs1hfKhqWTLl/Z6I/XfL9i2mQ9talG0loFAzOorCHPy42X3
mpJf4ufiCWnKMJrBmh2mrnRBOQKyjjm9paNQ/LM2ip/9pBdMyl8MEooYGlD68xmG
HhJJeWQjXoU+Xxj8IxUWEG2LO1np55NuqJlzwJaiZ9rjl7zJ0pQAaCogjWdXicP6
k46Vdrjllr2oHULIaBoW
=AIpA
-----END PGP SIGNATURE-----

--Sig_/keqifRXUMrFmd1v=HZ4il08--


--===============1808194248610518263==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1808194248610518263==--


From xen-devel-bounces@lists.xen.org Mon Dec 08 07:49:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07:49:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxt4P-0007LF-4l; Mon, 08 Dec 2014 07:49:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1Xxt4O-0007LA-2s
	for Xen-devel@lists.xensource.com; Mon, 08 Dec 2014 07:49:24 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	72/A7-07724-30855845; Mon, 08 Dec 2014 07:49:23 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418024959!11738655!1
X-Originating-IP: [103.22.144.67]
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 31401 invoked from network); 8 Dec 2014 07:49:22 -0000
Received: from ozlabs.org (HELO ozlabs.org) (103.22.144.67)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 07:49:22 -0000
Received: from authenticated.ozlabs.org (localhost [127.0.0.1])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by ozlabs.org (Postfix) with ESMTPSA id EDEAC1400A0;
	Mon,  8 Dec 2014 18:49:16 +1100 (AEDT)
Date: Mon, 8 Dec 2014 18:49:08 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>, Xen Devel
	<Xen-devel@lists.xensource.com>, Olof Johansson <olof@lixom.net>, Arnd
	Bergmann <arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>
Message-ID: <20141208184908.27bfd605@canb.auug.org.au>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; i586-pc-linux-gnu)
MIME-Version: 1.0
Cc: Russell King <linux@arm.linux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org,
	linux-next@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] linux-next: manual merge of the xen-tip tree with the
	arm-soc tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1808194248610518263=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1808194248610518263==
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/keqifRXUMrFmd1v=HZ4il08"; protocol="application/pgp-signature"

--Sig_/keqifRXUMrFmd1v=HZ4il08
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in
arch/arm/include/asm/dma-mapping.h between commits a3a60f81ee6f
("dma-mapping: replace set_arch_dma_coherent_ops with
arch_setup_dma_ops") and 4bb25789ed28 ("arm: dma-mapping: plumb our
iommu mapping ops into arch_setup_dma_ops") from the arm-soc tree and
commit 3d5391ac6f5e ("arm: introduce is_device_dma_coherent") from the
xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

I also neede this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 8 Dec 2014 18:46:59 +1100
Subject: [PATCH] arm: introduce is_device_dma_coherent merge fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/mm/dma-mapping.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 09645f00bd17..43064cbe58f9 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2058,6 +2058,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_b=
ase, u64 size,
 	else
 		dma_ops =3D arm_get_dma_map_ops(coherent);
=20
+	dev->archdata.dma_coherent =3D coherent;
 	set_dma_ops(dev, dma_ops);
 }
=20
--=20
2.1.3

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/include/asm/dma-mapping.h
index 9410b7e548fc,e6e3446abdf6..000000000000
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@@ -121,13 -121,20 +121,19 @@@ static inline unsigned long dma_max_pfn
  }
  #define dma_max_pfn(dev) dma_max_pfn(dev)
 =20
 -static inline int set_arch_dma_coherent_ops(struct device *dev)
 -{
 -	dev->archdata.dma_coherent =3D true;
 -	set_dma_ops(dev, &arm_coherent_dma_ops);
 -	return 0;
 -}
 -#define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
 +#define arch_setup_dma_ops arch_setup_dma_ops
 +extern void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
 +			       struct iommu_ops *iommu, bool coherent);
 +
 +#define arch_teardown_dma_ops arch_teardown_dma_ops
 +extern void arch_teardown_dma_ops(struct device *dev);
 =20
+ /* do not use this function in a driver */
+ static inline bool is_device_dma_coherent(struct device *dev)
+ {
+ 	return dev->archdata.dma_coherent;
+ }
+=20
  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t padd=
r)
  {
  	unsigned int offset =3D paddr & ~PAGE_MASK;

--Sig_/keqifRXUMrFmd1v=HZ4il08
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUhVf8AAoJEMDTa8Ir7ZwVauYQAJaFQg2K5pLKsuzWje2mAv2r
P2fggQQrBBFC7MO8aWRlJlaz2i9kzkOOIZoJC5sIgSiWIWYptw8K8FPwh78UDHKh
YOXnlVSclL5KP35pok6sqIBNVpjug3DvNlP4ruIQu1BvSne7UZIhlLaLSDlCp7Lj
qybnlefodPOoJOLVOYwI+R2Wa0rhhNbM62PwySPvsvE004VjmdKDQqZvuTrlcezD
Tir3kGgnLkMp+pEVIPfdbkoWZqAjMpKHfRJ/cGM13As4A7BT9kbcI23Duh3Fhb5w
0+qJQW5rOYx/eeJAjKuCCDorcoXaRGNOrd1zKAFbf53HAn4ex/CDd3+/jpsOa0jU
JndBOIjjLcezwQyZZuU+T7Dxdtb/1dVxspLCiRsCkDv9dmljPaY6zDm7LYTIeAbV
+tKTgiPjC79Z7F18H/p2+VSDG9Y9+1A5S/4V+mbTyZdiHnUfKSLsFX1TKmlzQi78
8N99ki0aFKG1t9lHRZs1hfKhqWTLl/Z6I/XfL9i2mQ9talG0loFAzOorCHPy42X3
mpJf4ufiCWnKMJrBmh2mrnRBOQKyjjm9paNQ/LM2ip/9pBdMyl8MEooYGlD68xmG
HhJJeWQjXoU+Xxj8IxUWEG2LO1np55NuqJlzwJaiZ9rjl7zJ0pQAaCogjWdXicP6
k46Vdrjllr2oHULIaBoW
=AIpA
-----END PGP SIGNATURE-----

--Sig_/keqifRXUMrFmd1v=HZ4il08--


--===============1808194248610518263==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1808194248610518263==--


From xen-devel-bounces@lists.xen.org Mon Dec 08 07:49:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxt4v-0007NO-I4; Mon, 08 Dec 2014 07:49:57 +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 1Xxt4u-0007NE-AH
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 07:49:56 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	86/73-17735-32855845; Mon, 08 Dec 2014 07:49:55 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418024994!7989825!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 19539 invoked from network); 8 Dec 2014 07:49:54 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-31.messagelabs.com with SMTP;
	8 Dec 2014 07:49:54 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 07 Dec 2014 23:49:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="426377578"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by FMSMGA003.fm.intel.com with ESMTP; 07 Dec 2014 23:39:16 -0800
Message-ID: <5485581C.1060809@intel.com>
Date: Mon, 08 Dec 2014 15:49: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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-7-git-send-email-tiejun.chen@intel.com>
	<20141202195506.GF357@laptop.dumpdata.com>
In-Reply-To: <20141202195506.GF357@laptop.dumpdata.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 06/17] tools/libxc: check if modules
 space is overlapping with reserved device 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 2014/12/3 3:55, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 05:24:24PM +0800, Tiejun Chen wrote:
>> In case of reserved device memory overlapping with ram, it also probably
>
> s/also//

Fixed.

>> overlap with modules space so we need to check these reserved device
> s/overlap/overlaps/

Fixed.

>
> What is 'modules space'?

Please see modules_init(), and looks it includs acpi and smbios currently.

>
>> memory as well.
>
> s/reserved device memory/E820_RSV/ ?

I don't find we have such a definition.

>
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   tools/libxc/xc_hvm_build_x86.c | 94 +++++++++++++++++++++++++++++++++++-------
>>   1 file changed, 79 insertions(+), 15 deletions(-)
>>
>> diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
>> index c81a25b..ddcf06d 100644
>> --- a/tools/libxc/xc_hvm_build_x86.c
>> +++ b/tools/libxc/xc_hvm_build_x86.c
>> @@ -54,9 +54,82 @@
>>
>>   #define VGA_HOLE_SIZE (0x20)
>>
>> +/*
>> + * Check whether there exists mmio hole in the specified memory range.
>> + * Returns 1 if exists, else returns 0.
>> + */
>> +static int check_mmio_hole(uint64_t start, uint64_t memsize,
>> +                           uint64_t mmio_start, uint64_t mmio_size)
>> +{
>> +    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
>> +        return 0;
>> +    else
>> +        return 1;
>> +}
>> +
>> +/* Getting all reserved device memory map info. */
>> +static struct xen_reserved_device_memory
>> +*xc_get_reserved_device_memory_map(xc_interface *xch, unsigned int nr_entries,
>> +                                   uint32_t dom)
>> +{
>> +    struct xen_reserved_device_memory *xrdm = NULL;
>> +    int rc = xc_reserved_device_memory_map(xch, dom, xrdm, &nr_entries);
>> +
>> +    if ( rc < 0 )
>> +    {
>> +        if ( errno == ENOBUFS )
>> +        {
>> +            if ( (xrdm = malloc(nr_entries *
>> +                                sizeof(xen_reserved_device_memory_t))) == NULL )
>> +            {
>> +                PERROR("Could not allocate memory.");
>> +                return 0;
>> +            }
>> +            rc = xc_reserved_device_memory_map(xch, dom, xrdm, &nr_entries);
>> +            if ( rc )
>> +            {
>> +                PERROR("Could not get reserved device memory maps.");
>> +                free(xrdm);
>> +                return 0;
>
> Uhhh, is that the right error to return?
>
> Don't you mean ERR_PTR logic? Or 'return NULL' ?

OOPS, return NULL.

>
>
>> +            }
>> +        }
>> +        else
>> +            PERROR("Could not get reserved device memory maps.");
>> +    }
>> +
>> +    return xrdm;
>> +}
>> +
>> +static int xc_check_modules_space(xc_interface *xch, uint64_t *mstart_out,
>> +                                  uint64_t *mend_out, uint32_t dom)
>> +{
>> +    unsigned int i = 0, nr_entries = 0;
>> +    uint64_t rdm_start = 0, rdm_end = 0;
>> +    struct xen_reserved_device_memory *rdm_map =
>> +                        xc_get_reserved_device_memory_map(xch, nr_entries, dom);
>> +
>
> You need to check whether 'rdm_map' is NULL.

You're right.

Actually nr_entries is always 0 if rdm_map is NULL with my original 
design. But now this should be checked as you mentioned, so

+    if ( !rdm_map )
+        return 0;
+

>
>> +    for ( i = 0; i < nr_entries; i++ )
>> +    {
>> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << XC_PAGE_SHIFT;
>> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << XC_PAGE_SHIFT);
>> +
>> +        /* Just use check_mmio_hole() to check modules ranges. */
>> +        if ( check_mmio_hole(rdm_start,
>> +                             rdm_end - rdm_start,
>> +                             *mstart_out, *mend_out) )
>> +            return -1;
>> +    }
>> +
>> +    free(rdm_map);
>> +
>> +    return 0;
>> +}
>> +
>>   static int modules_init(struct xc_hvm_build_args *args,
>>                           uint64_t vend, struct elf_binary *elf,
>> -                        uint64_t *mstart_out, uint64_t *mend_out)
>> +                        uint64_t *mstart_out, uint64_t *mend_out,
>> +                        xc_interface *xch,
>> +                        uint32_t dom)
>>   {
>>   #define MODULE_ALIGN 1UL << 7
>>   #define MB_ALIGN     1UL << 20
>> @@ -80,6 +153,10 @@ static int modules_init(struct xc_hvm_build_args *args,
>>       if ( *mend_out > vend )
>>           return -1;
>>
>> +    /* Is it overlapping with reserved device memory? */
>> +    if ( xc_check_modules_space(xch, mstart_out, mend_out, dom) )
>> +        return -1;
>> +
>>       if ( args->acpi_module.length != 0 )
>>           args->acpi_module.guest_addr_out = *mstart_out;
>>       if ( args->smbios_module.length != 0 )
>> @@ -226,19 +303,6 @@ static int loadmodules(xc_interface *xch,
>>       return rc;
>>   }
>>
>> -/*
>> - * Check whether there exists mmio hole in the specified memory range.
>> - * Returns 1 if exists, else returns 0.
>> - */
>> -static int check_mmio_hole(uint64_t start, uint64_t memsize,
>> -                           uint64_t mmio_start, uint64_t mmio_size)
>> -{
>> -    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
>> -        return 0;
>> -    else
>> -        return 1;
>> -}
>> -
>
> This movement of 'check_mmio_hole' needs to be a seperate patch.

Okay.

Thanks
Tiejun

>
>>   static int setup_guest(xc_interface *xch,
>>                          uint32_t dom, struct xc_hvm_build_args *args,
>>                          char *image, unsigned long image_size)
>> @@ -282,7 +346,7 @@ static int setup_guest(xc_interface *xch,
>>           goto error_out;
>>       }
>>
>> -    if ( modules_init(args, v_end, &elf, &m_start, &m_end) != 0 )
>> +    if ( modules_init(args, v_end, &elf, &m_start, &m_end, xch, dom) != 0 )
>>       {
>>           ERROR("Insufficient space to load modules.");
>>           goto error_out;
>> --
>> 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 Dec 08 07:49:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxt4v-0007NO-I4; Mon, 08 Dec 2014 07:49:57 +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 1Xxt4u-0007NE-AH
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 07:49:56 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	86/73-17735-32855845; Mon, 08 Dec 2014 07:49:55 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418024994!7989825!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 19539 invoked from network); 8 Dec 2014 07:49:54 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-31.messagelabs.com with SMTP;
	8 Dec 2014 07:49:54 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 07 Dec 2014 23:49:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="426377578"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by FMSMGA003.fm.intel.com with ESMTP; 07 Dec 2014 23:39:16 -0800
Message-ID: <5485581C.1060809@intel.com>
Date: Mon, 08 Dec 2014 15:49: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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-7-git-send-email-tiejun.chen@intel.com>
	<20141202195506.GF357@laptop.dumpdata.com>
In-Reply-To: <20141202195506.GF357@laptop.dumpdata.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 06/17] tools/libxc: check if modules
 space is overlapping with reserved device 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 2014/12/3 3:55, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 05:24:24PM +0800, Tiejun Chen wrote:
>> In case of reserved device memory overlapping with ram, it also probably
>
> s/also//

Fixed.

>> overlap with modules space so we need to check these reserved device
> s/overlap/overlaps/

Fixed.

>
> What is 'modules space'?

Please see modules_init(), and looks it includs acpi and smbios currently.

>
>> memory as well.
>
> s/reserved device memory/E820_RSV/ ?

I don't find we have such a definition.

>
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   tools/libxc/xc_hvm_build_x86.c | 94 +++++++++++++++++++++++++++++++++++-------
>>   1 file changed, 79 insertions(+), 15 deletions(-)
>>
>> diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
>> index c81a25b..ddcf06d 100644
>> --- a/tools/libxc/xc_hvm_build_x86.c
>> +++ b/tools/libxc/xc_hvm_build_x86.c
>> @@ -54,9 +54,82 @@
>>
>>   #define VGA_HOLE_SIZE (0x20)
>>
>> +/*
>> + * Check whether there exists mmio hole in the specified memory range.
>> + * Returns 1 if exists, else returns 0.
>> + */
>> +static int check_mmio_hole(uint64_t start, uint64_t memsize,
>> +                           uint64_t mmio_start, uint64_t mmio_size)
>> +{
>> +    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
>> +        return 0;
>> +    else
>> +        return 1;
>> +}
>> +
>> +/* Getting all reserved device memory map info. */
>> +static struct xen_reserved_device_memory
>> +*xc_get_reserved_device_memory_map(xc_interface *xch, unsigned int nr_entries,
>> +                                   uint32_t dom)
>> +{
>> +    struct xen_reserved_device_memory *xrdm = NULL;
>> +    int rc = xc_reserved_device_memory_map(xch, dom, xrdm, &nr_entries);
>> +
>> +    if ( rc < 0 )
>> +    {
>> +        if ( errno == ENOBUFS )
>> +        {
>> +            if ( (xrdm = malloc(nr_entries *
>> +                                sizeof(xen_reserved_device_memory_t))) == NULL )
>> +            {
>> +                PERROR("Could not allocate memory.");
>> +                return 0;
>> +            }
>> +            rc = xc_reserved_device_memory_map(xch, dom, xrdm, &nr_entries);
>> +            if ( rc )
>> +            {
>> +                PERROR("Could not get reserved device memory maps.");
>> +                free(xrdm);
>> +                return 0;
>
> Uhhh, is that the right error to return?
>
> Don't you mean ERR_PTR logic? Or 'return NULL' ?

OOPS, return NULL.

>
>
>> +            }
>> +        }
>> +        else
>> +            PERROR("Could not get reserved device memory maps.");
>> +    }
>> +
>> +    return xrdm;
>> +}
>> +
>> +static int xc_check_modules_space(xc_interface *xch, uint64_t *mstart_out,
>> +                                  uint64_t *mend_out, uint32_t dom)
>> +{
>> +    unsigned int i = 0, nr_entries = 0;
>> +    uint64_t rdm_start = 0, rdm_end = 0;
>> +    struct xen_reserved_device_memory *rdm_map =
>> +                        xc_get_reserved_device_memory_map(xch, nr_entries, dom);
>> +
>
> You need to check whether 'rdm_map' is NULL.

You're right.

Actually nr_entries is always 0 if rdm_map is NULL with my original 
design. But now this should be checked as you mentioned, so

+    if ( !rdm_map )
+        return 0;
+

>
>> +    for ( i = 0; i < nr_entries; i++ )
>> +    {
>> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << XC_PAGE_SHIFT;
>> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages << XC_PAGE_SHIFT);
>> +
>> +        /* Just use check_mmio_hole() to check modules ranges. */
>> +        if ( check_mmio_hole(rdm_start,
>> +                             rdm_end - rdm_start,
>> +                             *mstart_out, *mend_out) )
>> +            return -1;
>> +    }
>> +
>> +    free(rdm_map);
>> +
>> +    return 0;
>> +}
>> +
>>   static int modules_init(struct xc_hvm_build_args *args,
>>                           uint64_t vend, struct elf_binary *elf,
>> -                        uint64_t *mstart_out, uint64_t *mend_out)
>> +                        uint64_t *mstart_out, uint64_t *mend_out,
>> +                        xc_interface *xch,
>> +                        uint32_t dom)
>>   {
>>   #define MODULE_ALIGN 1UL << 7
>>   #define MB_ALIGN     1UL << 20
>> @@ -80,6 +153,10 @@ static int modules_init(struct xc_hvm_build_args *args,
>>       if ( *mend_out > vend )
>>           return -1;
>>
>> +    /* Is it overlapping with reserved device memory? */
>> +    if ( xc_check_modules_space(xch, mstart_out, mend_out, dom) )
>> +        return -1;
>> +
>>       if ( args->acpi_module.length != 0 )
>>           args->acpi_module.guest_addr_out = *mstart_out;
>>       if ( args->smbios_module.length != 0 )
>> @@ -226,19 +303,6 @@ static int loadmodules(xc_interface *xch,
>>       return rc;
>>   }
>>
>> -/*
>> - * Check whether there exists mmio hole in the specified memory range.
>> - * Returns 1 if exists, else returns 0.
>> - */
>> -static int check_mmio_hole(uint64_t start, uint64_t memsize,
>> -                           uint64_t mmio_start, uint64_t mmio_size)
>> -{
>> -    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
>> -        return 0;
>> -    else
>> -        return 1;
>> -}
>> -
>
> This movement of 'check_mmio_hole' needs to be a seperate patch.

Okay.

Thanks
Tiejun

>
>>   static int setup_guest(xc_interface *xch,
>>                          uint32_t dom, struct xc_hvm_build_args *args,
>>                          char *image, unsigned long image_size)
>> @@ -282,7 +346,7 @@ static int setup_guest(xc_interface *xch,
>>           goto error_out;
>>       }
>>
>> -    if ( modules_init(args, v_end, &elf, &m_start, &m_end) != 0 )
>> +    if ( modules_init(args, v_end, &elf, &m_start, &m_end, xch, dom) != 0 )
>>       {
>>           ERROR("Insufficient space to load modules.");
>>           goto error_out;
>> --
>> 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 Dec 08 07:56:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07:56:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxtAW-0007pl-IY; Mon, 08 Dec 2014 07:55:44 +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 1XxtAU-0007pg-V7
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 07:55:43 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	D3/B1-23865-E7955845; Mon, 08 Dec 2014 07:55:42 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418025341!7275863!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1529 invoked from network); 8 Dec 2014 07:55:41 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-31.messagelabs.com with SMTP;
	8 Dec 2014 07:55:41 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 07 Dec 2014 23:55:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="426380001"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by FMSMGA003.fm.intel.com with ESMTP; 07 Dec 2014 23:44:57 -0800
Message-ID: <54855971.40401@intel.com>
Date: Mon, 08 Dec 2014 15:55: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.3.0
MIME-Version: 1.0
To: "Tian, Kevin" <kevin.tian@intel.com>, 
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, 
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Zhang, Yang Z" <yang.z.zhang@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610ABCD@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610ABCD@SHSMSX101.ccr.corp.intel.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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/12/2 16:59, Tian, Kevin wrote:
>> From: Chen, Tiejun
>> Sent: Monday, December 01, 2014 5:24 PM
>>
>> We need to use reserved device memory maps with multiple times, so
>> provide just one common function should be friend.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   tools/firmware/hvmloader/util.c | 59
>> +++++++++++++++++++++++++++++++++++++++++
>>   tools/firmware/hvmloader/util.h |  2 ++
>>   2 files changed, 61 insertions(+)
>>
>> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
>> index 80d822f..dd81fb6 100644
>> --- a/tools/firmware/hvmloader/util.c
>> +++ b/tools/firmware/hvmloader/util.c
>> @@ -22,11 +22,14 @@
>>   #include "config.h"
>>   #include "hypercall.h"
>>   #include "ctype.h"
>> +#include "errno.h"
>>   #include <stdint.h>
>>   #include <xen/xen.h>
>>   #include <xen/memory.h>
>>   #include <xen/sched.h>
>>
>> +struct xen_reserved_device_memory *rdm_map;
>> +
>>   void wrmsr(uint32_t idx, uint64_t v)
>>   {
>>       asm volatile (
>> @@ -828,6 +831,62 @@ int hpet_exists(unsigned long hpet_base)
>>       return ((hpet_id >> 16) == 0x8086);
>>   }
>>
>> +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 = {
>> +        .domid = DOMID_SELF,
>> +        .nr_entries = *max_entries
>> +    };
>> +
>> +    set_xen_guest_handle(xrdmmap.buffer, entries);
>> +
>> +    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map,
>> &xrdmmap);
>> +    *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)
>> +{
>> +    static unsigned int nr_entries = 0;
>> +    int rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
>> +
>
> if this function is aimed to be invoked once, just check wheher rdm_map
> is valid instead of always issuing a new call.

As I remember Jan thought this doesn't cost more even in multiple times.

>
>> +    if ( rc == -ENOBUFS )
>> +    {
>> +        rdm_map = mem_alloc(nr_entries*sizeof(struct
>> xen_reserved_device_memory),
>> +                            0);
>> +        if ( rdm_map )
>> +        {
>> +            rc = get_reserved_device_memory_map(rdm_map,
>> &nr_entries);
>> +            if ( rc )
>> +            {
>> +                printf("Could not get reserved dev memory info on
>> domain");
>> +                return 0;
>
> why return '0' at failure?

In out real case, we don't want to handle more since its already fine 
with one message.

Thanks
Tiejun

>
>> +            }
>> +        }
>> +        else
>> +        {
>> +            printf("No space to get reserved dev memory maps!\n");
>> +            return 0;
>> +        }
>> +    }
>> +    else if ( rc )
>> +    {
>> +        printf("Could not get reserved dev memory info on domain");
>> +        return 0;
>> +    }
>> +
>> +    return nr_entries;
>> +}
>> +
>>   /*
>>    * Local variables:
>>    * mode: C
>> diff --git a/tools/firmware/hvmloader/util.h
>> b/tools/firmware/hvmloader/util.h
>> index a70e4aa..e4f1851 100644
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
>> @@ -241,6 +241,8 @@ int build_e820_table(struct e820entry *e820,
>>                        unsigned int bios_image_base);
>>   void dump_e820_table(struct e820entry *e820, unsigned int nr);
>>
>> +unsigned int hvm_get_reserved_device_memory_map(void);
>> +
>>   #ifndef NDEBUG
>>   void perform_tests(void);
>>   #else
>> --
>> 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 Dec 08 07:56:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 07:56:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxtAW-0007pl-IY; Mon, 08 Dec 2014 07:55:44 +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 1XxtAU-0007pg-V7
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 07:55:43 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	D3/B1-23865-E7955845; Mon, 08 Dec 2014 07:55:42 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418025341!7275863!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1529 invoked from network); 8 Dec 2014 07:55:41 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-31.messagelabs.com with SMTP;
	8 Dec 2014 07:55:41 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 07 Dec 2014 23:55:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="426380001"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by FMSMGA003.fm.intel.com with ESMTP; 07 Dec 2014 23:44:57 -0800
Message-ID: <54855971.40401@intel.com>
Date: Mon, 08 Dec 2014 15:55: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.3.0
MIME-Version: 1.0
To: "Tian, Kevin" <kevin.tian@intel.com>, 
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, 
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Zhang, Yang Z" <yang.z.zhang@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610ABCD@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610ABCD@SHSMSX101.ccr.corp.intel.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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/12/2 16:59, Tian, Kevin wrote:
>> From: Chen, Tiejun
>> Sent: Monday, December 01, 2014 5:24 PM
>>
>> We need to use reserved device memory maps with multiple times, so
>> provide just one common function should be friend.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   tools/firmware/hvmloader/util.c | 59
>> +++++++++++++++++++++++++++++++++++++++++
>>   tools/firmware/hvmloader/util.h |  2 ++
>>   2 files changed, 61 insertions(+)
>>
>> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
>> index 80d822f..dd81fb6 100644
>> --- a/tools/firmware/hvmloader/util.c
>> +++ b/tools/firmware/hvmloader/util.c
>> @@ -22,11 +22,14 @@
>>   #include "config.h"
>>   #include "hypercall.h"
>>   #include "ctype.h"
>> +#include "errno.h"
>>   #include <stdint.h>
>>   #include <xen/xen.h>
>>   #include <xen/memory.h>
>>   #include <xen/sched.h>
>>
>> +struct xen_reserved_device_memory *rdm_map;
>> +
>>   void wrmsr(uint32_t idx, uint64_t v)
>>   {
>>       asm volatile (
>> @@ -828,6 +831,62 @@ int hpet_exists(unsigned long hpet_base)
>>       return ((hpet_id >> 16) == 0x8086);
>>   }
>>
>> +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 = {
>> +        .domid = DOMID_SELF,
>> +        .nr_entries = *max_entries
>> +    };
>> +
>> +    set_xen_guest_handle(xrdmmap.buffer, entries);
>> +
>> +    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map,
>> &xrdmmap);
>> +    *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)
>> +{
>> +    static unsigned int nr_entries = 0;
>> +    int rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
>> +
>
> if this function is aimed to be invoked once, just check wheher rdm_map
> is valid instead of always issuing a new call.

As I remember Jan thought this doesn't cost more even in multiple times.

>
>> +    if ( rc == -ENOBUFS )
>> +    {
>> +        rdm_map = mem_alloc(nr_entries*sizeof(struct
>> xen_reserved_device_memory),
>> +                            0);
>> +        if ( rdm_map )
>> +        {
>> +            rc = get_reserved_device_memory_map(rdm_map,
>> &nr_entries);
>> +            if ( rc )
>> +            {
>> +                printf("Could not get reserved dev memory info on
>> domain");
>> +                return 0;
>
> why return '0' at failure?

In out real case, we don't want to handle more since its already fine 
with one message.

Thanks
Tiejun

>
>> +            }
>> +        }
>> +        else
>> +        {
>> +            printf("No space to get reserved dev memory maps!\n");
>> +            return 0;
>> +        }
>> +    }
>> +    else if ( rc )
>> +    {
>> +        printf("Could not get reserved dev memory info on domain");
>> +        return 0;
>> +    }
>> +
>> +    return nr_entries;
>> +}
>> +
>>   /*
>>    * Local variables:
>>    * mode: C
>> diff --git a/tools/firmware/hvmloader/util.h
>> b/tools/firmware/hvmloader/util.h
>> index a70e4aa..e4f1851 100644
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
>> @@ -241,6 +241,8 @@ int build_e820_table(struct e820entry *e820,
>>                        unsigned int bios_image_base);
>>   void dump_e820_table(struct e820entry *e820, unsigned int nr);
>>
>> +unsigned int hvm_get_reserved_device_memory_map(void);
>> +
>>   #ifndef NDEBUG
>>   void perform_tests(void);
>>   #else
>> --
>> 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 Dec 08 07:56:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1XxtBE-0007t8-VH; Mon, 08 Dec 2014 07:56:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XxtBE-0007sy-6K
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 07:56:28 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	73/80-17694-BA955845; Mon, 08 Dec 2014 07:56:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418025387!11664187!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24554 invoked from network); 8 Dec 2014 07:56:27 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 07:56:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418025387; l=304;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Transfer-Encoding:Content-Disposition:
	Content-Type:MIME-Version:References:Subject:Cc:To:From:Date;
	bh=rkV9xYR7mAe26ImJaFuHtKqaPuU=;
	b=jG2LFrSuBrDaQpm6+KjuasLsDbMnMnJJ57MNFyLRDkmCVxNgPQ//XJq6tRRx3JmwY9G
	AsZb+OHT32JXItlKuKSByh/QrAJZFCzyQ5C/tjnHJUCpTWenmrTLAPEQbZEVXdlfkW8V2
	krJh7EJQ9pLQ/Lq380Kp7OBP4Rbd6Bstei0=
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.2 AUTH) with ESMTPSA id C06aeeqB87uIogm
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 08:56:18 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A2B4450158; Mon,  8 Dec 2014 08:56:17 +0100 (CET)
Date: Mon, 8 Dec 2014 08:56:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Pasi =?utf-8?B?S8Okcmtrw6RpbmVu?= <pasik@iki.fi>
Message-ID: <20141208075617.GA8556@aepfle.de>
References: <1409199272-5155-1-git-send-email-jgross@suse.com>
	<20141207123200.GA12451@reaktio.net>
MIME-Version: 1.0
Content-Length: 576
Content-Disposition: inline
In-Reply-To: <20141207123200.GA12451@reaktio.net>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Juergen Gross <jgross@suse.com>, ian.campbell@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH V5] Update pvSCSI protocol description /
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCBEZWMgMDcsIFBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlOgoKPiBIZWxsbywKPiAKPiBK
dWVyZ2VuL09sYWY6IE5vdyB0aGF0IFhlbiBQVlNDU0kgZHJpdmVycyBhcmUgaW4gdXBzdHJlYW0g
TGludXggMy4xOCBrZXJuZWwgCj4gSSB3YXMgd29uZGVyaW5nIGlmIHlvdSBndXlzIGFsc28gaGF2
ZSBwbGFucyB0byB3b3JrIG9uIGFkZGluZyB4bCAvIGxpYnhsIHN1cHBvcnQgZm9yIFBWU0NTSSA/
IAoKSXRzIHN0aWxsIG9uIHRoZSBUT0RPIGxpc3QuIFdpbGwgbW9zdCBsaWtlbHkgbWFrZSBpbnRv
IDQuNi4KCk9sYWYKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 07:56:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1XxtBE-0007t8-VH; Mon, 08 Dec 2014 07:56:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XxtBE-0007sy-6K
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 07:56:28 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	73/80-17694-BA955845; Mon, 08 Dec 2014 07:56:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418025387!11664187!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24554 invoked from network); 8 Dec 2014 07:56:27 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 07:56:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418025387; l=304;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Transfer-Encoding:Content-Disposition:
	Content-Type:MIME-Version:References:Subject:Cc:To:From:Date;
	bh=rkV9xYR7mAe26ImJaFuHtKqaPuU=;
	b=jG2LFrSuBrDaQpm6+KjuasLsDbMnMnJJ57MNFyLRDkmCVxNgPQ//XJq6tRRx3JmwY9G
	AsZb+OHT32JXItlKuKSByh/QrAJZFCzyQ5C/tjnHJUCpTWenmrTLAPEQbZEVXdlfkW8V2
	krJh7EJQ9pLQ/Lq380Kp7OBP4Rbd6Bstei0=
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.2 AUTH) with ESMTPSA id C06aeeqB87uIogm
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 08:56:18 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A2B4450158; Mon,  8 Dec 2014 08:56:17 +0100 (CET)
Date: Mon, 8 Dec 2014 08:56:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Pasi =?utf-8?B?S8Okcmtrw6RpbmVu?= <pasik@iki.fi>
Message-ID: <20141208075617.GA8556@aepfle.de>
References: <1409199272-5155-1-git-send-email-jgross@suse.com>
	<20141207123200.GA12451@reaktio.net>
MIME-Version: 1.0
Content-Length: 576
Content-Disposition: inline
In-Reply-To: <20141207123200.GA12451@reaktio.net>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Juergen Gross <jgross@suse.com>, ian.campbell@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH V5] Update pvSCSI protocol description /
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCBEZWMgMDcsIFBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlOgoKPiBIZWxsbywKPiAKPiBK
dWVyZ2VuL09sYWY6IE5vdyB0aGF0IFhlbiBQVlNDU0kgZHJpdmVycyBhcmUgaW4gdXBzdHJlYW0g
TGludXggMy4xOCBrZXJuZWwgCj4gSSB3YXMgd29uZGVyaW5nIGlmIHlvdSBndXlzIGFsc28gaGF2
ZSBwbGFucyB0byB3b3JrIG9uIGFkZGluZyB4bCAvIGxpYnhsIHN1cHBvcnQgZm9yIFBWU0NTSSA/
IAoKSXRzIHN0aWxsIG9uIHRoZSBUT0RPIGxpc3QuIFdpbGwgbW9zdCBsaWtlbHkgbWFrZSBpbnRv
IDQuNi4KCk9sYWYKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:10:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxtOA-0000LA-UQ; Mon, 08 Dec 2014 08:09:50 +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 1XxtO8-0000L5-Na
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 08:09:48 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	12/9F-20609-CCC55845; Mon, 08 Dec 2014 08:09:48 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418026180!13580777!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 4042 invoked from network); 8 Dec 2014 08:09:46 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-27.messagelabs.com with SMTP;
	8 Dec 2014 08:09:46 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 08 Dec 2014 00:09:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,537,1413270000"; d="scan'208";a="644102192"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by fmsmga002.fm.intel.com with ESMTP; 08 Dec 2014 00:09:29 -0800
Message-ID: <54855CB8.7010009@intel.com>
Date: Mon, 08 Dec 2014 16:09:28 +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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
	<20141202200100.GG357@laptop.dumpdata.com>
In-Reply-To: <20141202200100.GG357@laptop.dumpdata.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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/12/3 4:01, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 05:24:25PM +0800, Tiejun Chen wrote:
>> We need to use reserved device memory maps with multiple times, so
>> provide just one common function should be friend.
>
> We need to call reserved device memory maps hypercall
> (XENMEM_reserved_device_memory_map) many times, hence provide one common function.

Rephrased and thanks.

>
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   tools/firmware/hvmloader/util.c | 59 +++++++++++++++++++++++++++++++++++++++++
>>   tools/firmware/hvmloader/util.h |  2 ++
>>   2 files changed, 61 insertions(+)
>>
>> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
>> index 80d822f..dd81fb6 100644
>> --- a/tools/firmware/hvmloader/util.c
>> +++ b/tools/firmware/hvmloader/util.c
>> @@ -22,11 +22,14 @@
>>   #include "config.h"
>>   #include "hypercall.h"
>>   #include "ctype.h"
>> +#include "errno.h"
>>   #include <stdint.h>
>>   #include <xen/xen.h>
>>   #include <xen/memory.h>
>>   #include <xen/sched.h>
>>
>> +struct xen_reserved_device_memory *rdm_map;
>> +
>>   void wrmsr(uint32_t idx, uint64_t v)
>>   {
>>       asm volatile (
>> @@ -828,6 +831,62 @@ int hpet_exists(unsigned long hpet_base)
>>       return ((hpet_id >> 16) == 0x8086);
>>   }
>>
>> +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 = {
>> +        .domid = DOMID_SELF,
>> +        .nr_entries = *max_entries
>> +    };
>> +
>> +    set_xen_guest_handle(xrdmmap.buffer, entries);
>> +
>> +    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map, &xrdmmap);
>> +    *max_entries = xrdmmap.nr_entries;
>
> Don't you want to check rc first before altering 'max_entries' ?

-    *max_entries = xrdmmap.nr_entries;
+    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.
>
> That does not sound like the right error value. Why not a proper
> return value? At worst you can put 'nr_entries' as an parameter
> and return the error value.

Any caller to use hvm_get_reserved_device_memory_map() don't care that 
real return value, the caller can work just with a return value as 
unsigned int. '0' means we have nothing to do, '>0' should be good to 
handle.

>
>> + */
>> +unsigned int hvm_get_reserved_device_memory_map(void)
>> +{
>> +    static unsigned int nr_entries = 0;
>> +    int rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
>> +
>> +    if ( rc == -ENOBUFS )
>> +    {
>> +        rdm_map = mem_alloc(nr_entries*sizeof(struct xen_reserved_device_memory),
>
> That '*' being squashed looks wrong. Just make it bigger and don't worry about
> the 80 line.

-        rdm_map = mem_alloc(nr_entries*sizeof(struct 
xen_reserved_device_memory),
+        rdm_map = mem_alloc(nr_entries * sizeof(struct 
xen_reserved_device_memory),


Thanks
Tiejun

>
>> +                            0);
>> +        if ( rdm_map )
>> +        {
>> +            rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
>> +            if ( rc )
>> +            {
>> +                printf("Could not get reserved dev memory info on domain");
>> +                return 0;
>> +            }
>> +        }
>> +        else
>> +        {
>> +            printf("No space to get reserved dev memory maps!\n");
>> +            return 0;
>> +        }
>> +    }
>> +    else if ( rc )
>> +    {
>> +        printf("Could not get reserved dev memory info on domain");
>> +        return 0;
>> +    }
>> +
>> +    return nr_entries;
>> +}
>> +
>>   /*
>>    * Local variables:
>>    * mode: C
>> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
>> index a70e4aa..e4f1851 100644
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
>> @@ -241,6 +241,8 @@ int build_e820_table(struct e820entry *e820,
>>                        unsigned int bios_image_base);
>>   void dump_e820_table(struct e820entry *e820, unsigned int nr);
>>
>> +unsigned int hvm_get_reserved_device_memory_map(void);
>> +
>>   #ifndef NDEBUG
>>   void perform_tests(void);
>>   #else
>> --
>> 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 Dec 08 08:10:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxtOA-0000LA-UQ; Mon, 08 Dec 2014 08:09:50 +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 1XxtO8-0000L5-Na
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 08:09:48 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	12/9F-20609-CCC55845; Mon, 08 Dec 2014 08:09:48 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418026180!13580777!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 4042 invoked from network); 8 Dec 2014 08:09:46 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-27.messagelabs.com with SMTP;
	8 Dec 2014 08:09:46 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 08 Dec 2014 00:09:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,537,1413270000"; d="scan'208";a="644102192"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by fmsmga002.fm.intel.com with ESMTP; 08 Dec 2014 00:09:29 -0800
Message-ID: <54855CB8.7010009@intel.com>
Date: Mon, 08 Dec 2014 16:09:28 +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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
	<20141202200100.GG357@laptop.dumpdata.com>
In-Reply-To: <20141202200100.GG357@laptop.dumpdata.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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/12/3 4:01, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 05:24:25PM +0800, Tiejun Chen wrote:
>> We need to use reserved device memory maps with multiple times, so
>> provide just one common function should be friend.
>
> We need to call reserved device memory maps hypercall
> (XENMEM_reserved_device_memory_map) many times, hence provide one common function.

Rephrased and thanks.

>
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   tools/firmware/hvmloader/util.c | 59 +++++++++++++++++++++++++++++++++++++++++
>>   tools/firmware/hvmloader/util.h |  2 ++
>>   2 files changed, 61 insertions(+)
>>
>> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
>> index 80d822f..dd81fb6 100644
>> --- a/tools/firmware/hvmloader/util.c
>> +++ b/tools/firmware/hvmloader/util.c
>> @@ -22,11 +22,14 @@
>>   #include "config.h"
>>   #include "hypercall.h"
>>   #include "ctype.h"
>> +#include "errno.h"
>>   #include <stdint.h>
>>   #include <xen/xen.h>
>>   #include <xen/memory.h>
>>   #include <xen/sched.h>
>>
>> +struct xen_reserved_device_memory *rdm_map;
>> +
>>   void wrmsr(uint32_t idx, uint64_t v)
>>   {
>>       asm volatile (
>> @@ -828,6 +831,62 @@ int hpet_exists(unsigned long hpet_base)
>>       return ((hpet_id >> 16) == 0x8086);
>>   }
>>
>> +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 = {
>> +        .domid = DOMID_SELF,
>> +        .nr_entries = *max_entries
>> +    };
>> +
>> +    set_xen_guest_handle(xrdmmap.buffer, entries);
>> +
>> +    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map, &xrdmmap);
>> +    *max_entries = xrdmmap.nr_entries;
>
> Don't you want to check rc first before altering 'max_entries' ?

-    *max_entries = xrdmmap.nr_entries;
+    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.
>
> That does not sound like the right error value. Why not a proper
> return value? At worst you can put 'nr_entries' as an parameter
> and return the error value.

Any caller to use hvm_get_reserved_device_memory_map() don't care that 
real return value, the caller can work just with a return value as 
unsigned int. '0' means we have nothing to do, '>0' should be good to 
handle.

>
>> + */
>> +unsigned int hvm_get_reserved_device_memory_map(void)
>> +{
>> +    static unsigned int nr_entries = 0;
>> +    int rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
>> +
>> +    if ( rc == -ENOBUFS )
>> +    {
>> +        rdm_map = mem_alloc(nr_entries*sizeof(struct xen_reserved_device_memory),
>
> That '*' being squashed looks wrong. Just make it bigger and don't worry about
> the 80 line.

-        rdm_map = mem_alloc(nr_entries*sizeof(struct 
xen_reserved_device_memory),
+        rdm_map = mem_alloc(nr_entries * sizeof(struct 
xen_reserved_device_memory),


Thanks
Tiejun

>
>> +                            0);
>> +        if ( rdm_map )
>> +        {
>> +            rc = get_reserved_device_memory_map(rdm_map, &nr_entries);
>> +            if ( rc )
>> +            {
>> +                printf("Could not get reserved dev memory info on domain");
>> +                return 0;
>> +            }
>> +        }
>> +        else
>> +        {
>> +            printf("No space to get reserved dev memory maps!\n");
>> +            return 0;
>> +        }
>> +    }
>> +    else if ( rc )
>> +    {
>> +        printf("Could not get reserved dev memory info on domain");
>> +        return 0;
>> +    }
>> +
>> +    return nr_entries;
>> +}
>> +
>>   /*
>>    * Local variables:
>>    * mode: C
>> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
>> index a70e4aa..e4f1851 100644
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
>> @@ -241,6 +241,8 @@ int build_e820_table(struct e820entry *e820,
>>                        unsigned int bios_image_base);
>>   void dump_e820_table(struct e820entry *e820, unsigned int nr);
>>
>> +unsigned int hvm_get_reserved_device_memory_map(void);
>> +
>>   #ifndef NDEBUG
>>   void perform_tests(void);
>>   #else
>> --
>> 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 Dec 08 08:33:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:33:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxtl2-00016U-7b; Mon, 08 Dec 2014 08:33: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 1Xxtl0-00016P-Lr
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 08:33:26 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	F1/8C-02699-65265845; Mon, 08 Dec 2014 08:33:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418027605!13613499!1
X-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 25282 invoked from network); 8 Dec 2014 08:33:25 -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; 8 Dec 2014 08:33:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:33:24 +0000
Message-Id: <54857061020000780004D999@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:33:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<5481E39B020000780004D450@mail.emea.novell.com>
	<5481E564020000780004D47B@mail.emea.novell.com>
	<5481E6FC.1070905@oracle.com>
In-Reply-To: <5481E6FC.1070905@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 05.12.14 at 18:10, <boris.ostrovsky@oracle.com> wrote:
> On 12/05/2014 11:03 AM, Jan Beulich wrote:
>>>>> On 05.12.14 at 16:55, <JBeulich@suse.com> wrote:
>>>>>> On 02.12.14 at 22:34, <boris.ostrovsky@oracle.com> wrote:
>>>> +struct xen_sysctl_iotopo {
>>>> +    uint16_t seg;
>>>> +    uint8_t bus;
>>>> +    uint8_t devfn;
>>>> +    uint32_t node;
>>>> +};
>>> This is PCI-centric without expressing in the name or layout.
> 
> xen_sysctl_pcitopo would be a better name.
> 
>>>   Perhaps
>>> the first part should be a union from the very beginning?
>> And I wonder whether that supposed union part wouldn't be nicely
>> done using struct physdev_pci_device.
> 
> The do look strikingly similar ;-)
> 
> How would a union be useful here?

If this was left as iotopo, PCI would be one of potentially many I/O
variants, and hence a union would seem warranted. If you want to
rename it to pcitopo that of course would be pointless.

>> Additionally please add IN and OUT annotations. When I first saw
>> this I assumed they would all be OUT (in which case the long running
>> loop problem mentioned in the reply to one of the other patches
>> wouldn't have been there), matching their CPU counterpart...
> 
> I don't follow this. Are you saying that if ti->max_devs in patch 3/4 is 
> an IN (which it is) then we don't have to guard for long-running loops?

If they were all OUT then there wouldn't be a way for the entire
operation to be fooled into going over more devices than there are
in the system.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:33:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:33:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxtl2-00016U-7b; Mon, 08 Dec 2014 08:33: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 1Xxtl0-00016P-Lr
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 08:33:26 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	F1/8C-02699-65265845; Mon, 08 Dec 2014 08:33:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418027605!13613499!1
X-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 25282 invoked from network); 8 Dec 2014 08:33:25 -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; 8 Dec 2014 08:33:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:33:24 +0000
Message-Id: <54857061020000780004D999@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:33:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<5481E39B020000780004D450@mail.emea.novell.com>
	<5481E564020000780004D47B@mail.emea.novell.com>
	<5481E6FC.1070905@oracle.com>
In-Reply-To: <5481E6FC.1070905@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 05.12.14 at 18:10, <boris.ostrovsky@oracle.com> wrote:
> On 12/05/2014 11:03 AM, Jan Beulich wrote:
>>>>> On 05.12.14 at 16:55, <JBeulich@suse.com> wrote:
>>>>>> On 02.12.14 at 22:34, <boris.ostrovsky@oracle.com> wrote:
>>>> +struct xen_sysctl_iotopo {
>>>> +    uint16_t seg;
>>>> +    uint8_t bus;
>>>> +    uint8_t devfn;
>>>> +    uint32_t node;
>>>> +};
>>> This is PCI-centric without expressing in the name or layout.
> 
> xen_sysctl_pcitopo would be a better name.
> 
>>>   Perhaps
>>> the first part should be a union from the very beginning?
>> And I wonder whether that supposed union part wouldn't be nicely
>> done using struct physdev_pci_device.
> 
> The do look strikingly similar ;-)
> 
> How would a union be useful here?

If this was left as iotopo, PCI would be one of potentially many I/O
variants, and hence a union would seem warranted. If you want to
rename it to pcitopo that of course would be pointless.

>> Additionally please add IN and OUT annotations. When I first saw
>> this I assumed they would all be OUT (in which case the long running
>> loop problem mentioned in the reply to one of the other patches
>> wouldn't have been there), matching their CPU counterpart...
> 
> I don't follow this. Are you saying that if ti->max_devs in patch 3/4 is 
> an IN (which it is) then we don't have to guard for long-running loops?

If they were all OUT then there wouldn't be a way for the entire
operation to be fooled into going over more devices than there are
in the system.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:34:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08: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 1XxtmJ-0001B7-MF; Mon, 08 Dec 2014 08:34:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XxtmI-0001Az-Ll
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 08:34:46 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	4C/A7-28865-5A265845; Mon, 08 Dec 2014 08:34:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418027685!9181062!1
X-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 12960 invoked from network); 8 Dec 2014 08:34:45 -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; 8 Dec 2014 08:34:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:34:44 +0000
Message-Id: <548570B2020000780004D99C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:34:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Bob Liu" <bob.liu@oracle.com>
References: <546F1033.7030005@oracle.com> <54818221.1070804@oracle.com>
	<5481B1F6020000780004D24A@mail.emea.novell.com>
	<5484597A.507@oracle.com>
In-Reply-To: <5484597A.507@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.campbell@citrix.com, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A good way to speed up the xl destroy time(guest
 page scrubbing)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 14:43, <bob.liu@oracle.com> wrote:

> On 12/05/2014 08:24 PM, Jan Beulich wrote:
>>>>> On 05.12.14 at 11:00, <bob.liu@oracle.com> wrote:
>>> 5. Potential workaround
>>> 5.1 Use per-cpu list in idle_loop()
>>> Delist a batch of pages from heap_list to a per-cpu list, then scrub the
>>> per-cpu list and free back to heap_list.
>>>
>>> But Jan disagree with this solution:
>>> "You should really drop the idea of removing pages temporarily.
>>> All you need to do is make sure a page being allocated and getting
>>> simultaneously scrubbed by another CPU won't get passed to the
>>> caller until the scrubbing finished."
>> 
>> So you don't mention any downsides to this approach. If there are
>> any, please name them. If there aren't, what's the reason not to
>> go this route?
> 
> The reason was what you suggested was not very specific, I still have no
> idea how to implement a patch which can "make sure a page being
> allocated and getting simultaneously scrubbed by another CPU won't get
> passed to the caller until the scrubbing finished".

The scrubbing code would need to mark the page, and the allocation
code would need to spin on such marked pages until the mark clears.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:34:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08: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 1XxtmJ-0001B7-MF; Mon, 08 Dec 2014 08:34:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XxtmI-0001Az-Ll
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 08:34:46 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	4C/A7-28865-5A265845; Mon, 08 Dec 2014 08:34:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418027685!9181062!1
X-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 12960 invoked from network); 8 Dec 2014 08:34:45 -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; 8 Dec 2014 08:34:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:34:44 +0000
Message-Id: <548570B2020000780004D99C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:34:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Bob Liu" <bob.liu@oracle.com>
References: <546F1033.7030005@oracle.com> <54818221.1070804@oracle.com>
	<5481B1F6020000780004D24A@mail.emea.novell.com>
	<5484597A.507@oracle.com>
In-Reply-To: <5484597A.507@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.campbell@citrix.com, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A good way to speed up the xl destroy time(guest
 page scrubbing)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 14:43, <bob.liu@oracle.com> wrote:

> On 12/05/2014 08:24 PM, Jan Beulich wrote:
>>>>> On 05.12.14 at 11:00, <bob.liu@oracle.com> wrote:
>>> 5. Potential workaround
>>> 5.1 Use per-cpu list in idle_loop()
>>> Delist a batch of pages from heap_list to a per-cpu list, then scrub the
>>> per-cpu list and free back to heap_list.
>>>
>>> But Jan disagree with this solution:
>>> "You should really drop the idea of removing pages temporarily.
>>> All you need to do is make sure a page being allocated and getting
>>> simultaneously scrubbed by another CPU won't get passed to the
>>> caller until the scrubbing finished."
>> 
>> So you don't mention any downsides to this approach. If there are
>> any, please name them. If there aren't, what's the reason not to
>> go this route?
> 
> The reason was what you suggested was not very specific, I still have no
> idea how to implement a patch which can "make sure a page being
> allocated and getting simultaneously scrubbed by another CPU won't get
> passed to the caller until the scrubbing finished".

The scrubbing code would need to mark the page, and the allocation
code would need to spin on such marked pages until the mark clears.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:36:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:36:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxtnb-0001Ha-4c; Mon, 08 Dec 2014 08:36: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 1XxtnZ-0001HS-IE
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 08:36:05 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	65/63-03148-4F265845; Mon, 08 Dec 2014 08:36:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418027762!13521280!1
X-Originating-IP: [66.165.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 1338 invoked from network); 8 Dec 2014 08:36:03 -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;
	8 Dec 2014 08:36:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201691746"
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.210.2; Mon, 8 Dec 2014 03:36: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 1XxtnV-0000rP-3i;
	Mon, 08 Dec 2014 08:36:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxtnS-0008PK-UL;
	Mon, 08 Dec 2014 08:35:58 +0000
Date: Mon, 8 Dec 2014 08:35:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32137-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8807
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32137: 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="===============5411758760900114760=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5411758760900114760==
Content-Type: text/plain
Content-Length: 8548
Content-Transfer-Encoding: quoted-printable

flight 32137 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32137/

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              253319ced6e9e92992f59000e3810b7d3ab59750
baseline version:
 libvirt              ff018e686a8a412255bc34d3dc558a1bcf74fac5

------------------------------------------------------------
People who touched revisions under test:
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Cole Robinson <crobinso@redhat.com>
  Conrad Meyer <cse.cem@gmail.com>
  Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
  Daniel P. Berrange <berrange@redhat.com>
  Dmitry Guryanov <dguryanov@parallels.com>
  Erik Skultety <eskultet@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Laine Stump <laine@laine.org>
  Luyao Huang <lhuang@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>
  Shanzhi Yu <shyu@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=3D253319ced6e9e92992f59000e3810b7d3ab59750
+ . 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 253319ced6e9e92992f59000e3810b7d3ab59750
+ branch=3Dlibvirt
+ revision=3D253319ced6e9e92992f59000e3810b7d3ab59750
+ . 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 253319ced6e9e92992f59000e3810b7d3ab59750:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   ff018e6..253319c  253319ced6e9e92992f59000e3810b7d3ab59750 -> xen-tested-master


--===============5411758760900114760==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5411758760900114760==--

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:36:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:36:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxtnb-0001Ha-4c; Mon, 08 Dec 2014 08:36: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 1XxtnZ-0001HS-IE
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 08:36:05 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	65/63-03148-4F265845; Mon, 08 Dec 2014 08:36:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418027762!13521280!1
X-Originating-IP: [66.165.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 1338 invoked from network); 8 Dec 2014 08:36:03 -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;
	8 Dec 2014 08:36:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201691746"
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.210.2; Mon, 8 Dec 2014 03:36: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 1XxtnV-0000rP-3i;
	Mon, 08 Dec 2014 08:36:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XxtnS-0008PK-UL;
	Mon, 08 Dec 2014 08:35:58 +0000
Date: Mon, 8 Dec 2014 08:35:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32137-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8807
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32137: 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="===============5411758760900114760=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5411758760900114760==
Content-Type: text/plain
Content-Length: 8548
Content-Transfer-Encoding: quoted-printable

flight 32137 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32137/

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              253319ced6e9e92992f59000e3810b7d3ab59750
baseline version:
 libvirt              ff018e686a8a412255bc34d3dc558a1bcf74fac5

------------------------------------------------------------
People who touched revisions under test:
  Chen Fan <chen.fan.fnst@cn.fujitsu.com>
  Cole Robinson <crobinso@redhat.com>
  Conrad Meyer <cse.cem@gmail.com>
  Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
  Daniel P. Berrange <berrange@redhat.com>
  Dmitry Guryanov <dguryanov@parallels.com>
  Erik Skultety <eskultet@redhat.com>
  Ian Campbell <ian.campbell@citrix.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Laine Stump <laine@laine.org>
  Luyao Huang <lhuang@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>
  Shanzhi Yu <shyu@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=3D253319ced6e9e92992f59000e3810b7d3ab59750
+ . 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 253319ced6e9e92992f59000e3810b7d3ab59750
+ branch=3Dlibvirt
+ revision=3D253319ced6e9e92992f59000e3810b7d3ab59750
+ . 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 253319ced6e9e92992f59000e3810b7d3ab59750:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   ff018e6..253319c  253319ced6e9e92992f59000e3810b7d3ab59750 -> xen-tested-master


--===============5411758760900114760==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5411758760900114760==--

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:43:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:43:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxtue-0001kD-6v; Mon, 08 Dec 2014 08:43:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xxtuc-0001k8-L1
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 08:43:22 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	53/3D-02953-9A465845; Mon, 08 Dec 2014 08:43:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418028201!13599129!1
X-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 16026 invoked from network); 8 Dec 2014 08:43:21 -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; 8 Dec 2014 08:43:21 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:43:20 +0000
Message-Id: <548572B5020000780004D9BC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:43:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<54808CC3020000780004CCC8@mail.emea.novell.com>
	<54853FE3.9030703@intel.com>
In-Reply-To: <54853FE3.9030703@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 07:06, <tiejun.chen@intel.com> wrote:
> On 2014/12/4 23:33, Jan Beulich wrote:
>>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> Looks this could be fine,
> 
> d->arch.hvm_domain.pci_force = xdsr->flags & PCI_DEV_RDM_CHECK;

Which is correct only because PCI_DEV_RDM_CHECK happens to be
1. Such hidden dependencies shouldn't be introduced though, in
particular to avoid others then cloning the code for a flag that's not
1. The canonical form (found in many places throughout the treei

    d->arch.hvm_domain.pci_force = !!(xdsr->flags & PCI_DEV_RDM_CHECK);

>>> +        d->arch.hvm_domain.pcidevs = NULL;
>>> +
>>> +        if ( xdsr->num_pcidevs )
>>> +        {
>>> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
>>> +                                    xdsr->num_pcidevs);
>>
>> New domctl-s must not represent security risks: xdsr->num_pcidevs
>> can be (almost) arbitrarily large - do you really want to allow such
>> huge allocations? A reasonable upper bound could for example be
> 
> Sorry, as you know this num_pcidevs is from tools, and actually it share 
> that result from that existing hypercall, assign_device, while parsing 
> 'pci=[]', so I couldn't understand why this can be (almost" arbitrarily 
> large.

You imply well behaved tools, which you shouldn't when viewing
things from a security perspective.

>> the total number of PCI devices the hypervisor knows about.
> 
> I take a quick look at this but looks we have no this exact value that 
> we can get directly.

You need some upper bound. Whether you introduce a properly
maintained count or a suitable estimate thereof doesn't matter.

>>> --- 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;
>>>
>>> +    bool_t                  pci_force;
>>> +    uint32_t                num_pcidevs;
>>> +    struct xen_guest_pcidev_info      *pcidevs;
>>
>> Without a comment all these field names are pretty questionable.
> 
> Yeah, I try to add some comments,
> 
>      /* A global flag, we need to check/reserve all Reserved Device 
> Memory. */
>      bool_t                  pci_force;
>      /*
>       * If pci_force is 0, this represents how many pci devices we need
>       * to check/reserve Reserved Device Memory.
>       * If pci_force is 1, this is always 0.
>       */
>      uint32_t                num_pcidevs;
>      /* This represents those pci devices instances when num_pcidevs != 
> 0. */
>      struct xen_guest_pcidev_info      *pcidevs;

I really didn't necessarily mean individual comments - one for the whole
group would suffice.

Also I don't think pci_force is really the right name - all_pcidevs or
some such would seem more suitable following the entire series.
And finally, I'm generally advocating for avoiding redundant data
items - I'm sure this "all" notion can be encoded reasonable with
just the other two field (and a suitable checking macro).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:43:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:43:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxtue-0001kD-6v; Mon, 08 Dec 2014 08:43:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xxtuc-0001k8-L1
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 08:43:22 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	53/3D-02953-9A465845; Mon, 08 Dec 2014 08:43:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418028201!13599129!1
X-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 16026 invoked from network); 8 Dec 2014 08:43:21 -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; 8 Dec 2014 08:43:21 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:43:20 +0000
Message-Id: <548572B5020000780004D9BC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:43:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<54808CC3020000780004CCC8@mail.emea.novell.com>
	<54853FE3.9030703@intel.com>
In-Reply-To: <54853FE3.9030703@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 07:06, <tiejun.chen@intel.com> wrote:
> On 2014/12/4 23:33, Jan Beulich wrote:
>>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
> Looks this could be fine,
> 
> d->arch.hvm_domain.pci_force = xdsr->flags & PCI_DEV_RDM_CHECK;

Which is correct only because PCI_DEV_RDM_CHECK happens to be
1. Such hidden dependencies shouldn't be introduced though, in
particular to avoid others then cloning the code for a flag that's not
1. The canonical form (found in many places throughout the treei

    d->arch.hvm_domain.pci_force = !!(xdsr->flags & PCI_DEV_RDM_CHECK);

>>> +        d->arch.hvm_domain.pcidevs = NULL;
>>> +
>>> +        if ( xdsr->num_pcidevs )
>>> +        {
>>> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
>>> +                                    xdsr->num_pcidevs);
>>
>> New domctl-s must not represent security risks: xdsr->num_pcidevs
>> can be (almost) arbitrarily large - do you really want to allow such
>> huge allocations? A reasonable upper bound could for example be
> 
> Sorry, as you know this num_pcidevs is from tools, and actually it share 
> that result from that existing hypercall, assign_device, while parsing 
> 'pci=[]', so I couldn't understand why this can be (almost" arbitrarily 
> large.

You imply well behaved tools, which you shouldn't when viewing
things from a security perspective.

>> the total number of PCI devices the hypervisor knows about.
> 
> I take a quick look at this but looks we have no this exact value that 
> we can get directly.

You need some upper bound. Whether you introduce a properly
maintained count or a suitable estimate thereof doesn't matter.

>>> --- 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;
>>>
>>> +    bool_t                  pci_force;
>>> +    uint32_t                num_pcidevs;
>>> +    struct xen_guest_pcidev_info      *pcidevs;
>>
>> Without a comment all these field names are pretty questionable.
> 
> Yeah, I try to add some comments,
> 
>      /* A global flag, we need to check/reserve all Reserved Device 
> Memory. */
>      bool_t                  pci_force;
>      /*
>       * If pci_force is 0, this represents how many pci devices we need
>       * to check/reserve Reserved Device Memory.
>       * If pci_force is 1, this is always 0.
>       */
>      uint32_t                num_pcidevs;
>      /* This represents those pci devices instances when num_pcidevs != 
> 0. */
>      struct xen_guest_pcidev_info      *pcidevs;

I really didn't necessarily mean individual comments - one for the whole
group would suffice.

Also I don't think pci_force is really the right name - all_pcidevs or
some such would seem more suitable following the entire series.
And finally, I'm generally advocating for avoiding redundant data
items - I'm sure this "all" notion can be encoded reasonable with
just the other two field (and a suitable checking macro).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:45:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:45:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxtwv-0001qP-OK; Mon, 08 Dec 2014 08:45:45 +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 1Xxtwt-0001qC-RI
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 08:45:43 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	E2/73-23865-73565845; Mon, 08 Dec 2014 08:45:43 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418028340!9289346!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11333 invoked from network); 8 Dec 2014 08:45:42 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	8 Dec 2014 08:45:42 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 08 Dec 2014 00:43:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,537,1413270000"; d="scan'208";a="620292234"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga001.jf.intel.com with ESMTP; 08 Dec 2014 00:45:37 -0800
Message-ID: <54856530.7050206@intel.com>
Date: Mon, 08 Dec 2014 16:45:36 +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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>	<20141202200100.GG357@laptop.dumpdata.com>
	<54855CB8.7010009@intel.com>
In-Reply-To: <54855CB8.7010009@intel.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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/12/8 16:09, Chen, Tiejun wrote:
> On 2014/12/3 4:01, Konrad Rzeszutek Wilk wrote:
>> On Mon, Dec 01, 2014 at 05:24:25PM +0800, Tiejun Chen wrote:
>>> We need to use reserved device memory maps with multiple times, so
>>> provide just one common function should be friend.
>>
>> We need to call reserved device memory maps hypercall
>> (XENMEM_reserved_device_memory_map) many times, hence provide one
>> common function.
>
> Rephrased and thanks.
>
>>
>>>
>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>> ---
>>>   tools/firmware/hvmloader/util.c | 59
>>> +++++++++++++++++++++++++++++++++++++++++
>>>   tools/firmware/hvmloader/util.h |  2 ++
>>>   2 files changed, 61 insertions(+)
>>>
>>> diff --git a/tools/firmware/hvmloader/util.c
>>> b/tools/firmware/hvmloader/util.c
>>> index 80d822f..dd81fb6 100644
>>> --- a/tools/firmware/hvmloader/util.c
>>> +++ b/tools/firmware/hvmloader/util.c
>>> @@ -22,11 +22,14 @@
>>>   #include "config.h"
>>>   #include "hypercall.h"
>>>   #include "ctype.h"
>>> +#include "errno.h"
>>>   #include <stdint.h>
>>>   #include <xen/xen.h>
>>>   #include <xen/memory.h>
>>>   #include <xen/sched.h>
>>>
>>> +struct xen_reserved_device_memory *rdm_map;
>>> +
>>>   void wrmsr(uint32_t idx, uint64_t v)
>>>   {
>>>       asm volatile (
>>> @@ -828,6 +831,62 @@ int hpet_exists(unsigned long hpet_base)
>>>       return ((hpet_id >> 16) == 0x8086);
>>>   }
>>>
>>> +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 = {
>>> +        .domid = DOMID_SELF,
>>> +        .nr_entries = *max_entries
>>> +    };
>>> +
>>> +    set_xen_guest_handle(xrdmmap.buffer, entries);
>>> +
>>> +    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map,
>>> &xrdmmap);
>>> +    *max_entries = xrdmmap.nr_entries;
>>
>> Don't you want to check rc first before altering 'max_entries' ?
>
> -    *max_entries = xrdmmap.nr_entries;
> +    if ( rc == -ENOBUFS )
> +        *max_entries = xrdmmap.nr_entries;
>

Something remind me. That is, in all case we should set max_entries 
since now we don't count all RMRR ranges again. Instead, we may count 
those RMRR ranges associated to a assigned device but obviously, it may 
have no any RMRR. So we always should update max_entries as well.

Thanks
Tiejun

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 Dec 08 08:45:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:45:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxtwv-0001qP-OK; Mon, 08 Dec 2014 08:45:45 +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 1Xxtwt-0001qC-RI
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 08:45:43 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	E2/73-23865-73565845; Mon, 08 Dec 2014 08:45:43 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418028340!9289346!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11333 invoked from network); 8 Dec 2014 08:45:42 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	8 Dec 2014 08:45:42 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 08 Dec 2014 00:43:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,537,1413270000"; d="scan'208";a="620292234"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga001.jf.intel.com with ESMTP; 08 Dec 2014 00:45:37 -0800
Message-ID: <54856530.7050206@intel.com>
Date: Mon, 08 Dec 2014 16:45:36 +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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>	<20141202200100.GG357@laptop.dumpdata.com>
	<54855CB8.7010009@intel.com>
In-Reply-To: <54855CB8.7010009@intel.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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/12/8 16:09, Chen, Tiejun wrote:
> On 2014/12/3 4:01, Konrad Rzeszutek Wilk wrote:
>> On Mon, Dec 01, 2014 at 05:24:25PM +0800, Tiejun Chen wrote:
>>> We need to use reserved device memory maps with multiple times, so
>>> provide just one common function should be friend.
>>
>> We need to call reserved device memory maps hypercall
>> (XENMEM_reserved_device_memory_map) many times, hence provide one
>> common function.
>
> Rephrased and thanks.
>
>>
>>>
>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>> ---
>>>   tools/firmware/hvmloader/util.c | 59
>>> +++++++++++++++++++++++++++++++++++++++++
>>>   tools/firmware/hvmloader/util.h |  2 ++
>>>   2 files changed, 61 insertions(+)
>>>
>>> diff --git a/tools/firmware/hvmloader/util.c
>>> b/tools/firmware/hvmloader/util.c
>>> index 80d822f..dd81fb6 100644
>>> --- a/tools/firmware/hvmloader/util.c
>>> +++ b/tools/firmware/hvmloader/util.c
>>> @@ -22,11 +22,14 @@
>>>   #include "config.h"
>>>   #include "hypercall.h"
>>>   #include "ctype.h"
>>> +#include "errno.h"
>>>   #include <stdint.h>
>>>   #include <xen/xen.h>
>>>   #include <xen/memory.h>
>>>   #include <xen/sched.h>
>>>
>>> +struct xen_reserved_device_memory *rdm_map;
>>> +
>>>   void wrmsr(uint32_t idx, uint64_t v)
>>>   {
>>>       asm volatile (
>>> @@ -828,6 +831,62 @@ int hpet_exists(unsigned long hpet_base)
>>>       return ((hpet_id >> 16) == 0x8086);
>>>   }
>>>
>>> +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 = {
>>> +        .domid = DOMID_SELF,
>>> +        .nr_entries = *max_entries
>>> +    };
>>> +
>>> +    set_xen_guest_handle(xrdmmap.buffer, entries);
>>> +
>>> +    rc = hypercall_memory_op(XENMEM_reserved_device_memory_map,
>>> &xrdmmap);
>>> +    *max_entries = xrdmmap.nr_entries;
>>
>> Don't you want to check rc first before altering 'max_entries' ?
>
> -    *max_entries = xrdmmap.nr_entries;
> +    if ( rc == -ENOBUFS )
> +        *max_entries = xrdmmap.nr_entries;
>

Something remind me. That is, in all case we should set max_entries 
since now we don't count all RMRR ranges again. Instead, we may count 
those RMRR ranges associated to a assigned device but obviously, it may 
have no any RMRR. So we always should update max_entries as well.

Thanks
Tiejun

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 Dec 08 08:51:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08: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 1Xxu2M-00020z-H8; Mon, 08 Dec 2014 08:51: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 1Xxu2J-00020u-Oc
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 08:51:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B8/6B-25276-78665845; Mon, 08 Dec 2014 08:51:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418028678!13731281!1
X-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 13856 invoked from network); 8 Dec 2014 08:51:18 -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; 8 Dec 2014 08:51:18 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:51:17 +0000
Message-Id: <54857491020000780004D9D6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:51:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
In-Reply-To: <54854F2D.6060204@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 08:11, <tiejun.chen@intel.com> wrote:
> On 2014/12/4 23:50, Jan Beulich wrote:
>>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>>>
>>> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>>> -                                     &rdm, 1) )
>>> -            return -EFAULT;
>>> +    if ( d )
>>> +    {
>>> +        if ( d->arch.hvm_domain.pci_force )
>>
>> You didn't verify that the domain is a HVM/PVH one.
> 
> Is this, ASSERT(is_hvm_domain(grdm.domain)), correct?

Certainly not, or do you want to crash the hypervisor because of bad
tools input?

>>> +        {
>>> +            if ( grdm->used_entries < grdm->map.nr_entries )
>>> +            {
>>> +                if ( __copy_to_compat_offset(grdm->map.buffer,
>>> +                                             grdm->used_entries,
>>> +                                             &rdm, 1) )
>>> +                {
>>> +                    rcu_unlock_domain(d);
>>> +                    return -EFAULT;
>>> +                }
>>> +            }
>>> +            ++grdm->used_entries;
>>> +        }
>>> +        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 ( grdm->used_entries < grdm->map.nr_entries )
>>> +                    {
>>> +                        if ( __copy_to_compat_offset(grdm->map.buffer,
>>> +                                                     grdm->used_entries,
>>> +                                                     &rdm, 1) )
>>> +                        {
>>> +                            rcu_unlock_domain(d);
>>> +                            return -EFAULT;
>>> +                        }
>>> +                    }
>>> +                    ++grdm->used_entries;
>>
>> break;
> 
> Added.
> 
>>
>> Also trying to fold code identical on the if and else branches would
>> seem pretty desirable.
> 
> Sorry, I can't see what I'm missing.

The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
is identical and can be factored out pretty easily afaict.

>>> @@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) compat)
>>>
>>>               if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>>>                   rc = -ENOBUFS;
>>> +
>>>               grdm.map.nr_entries = grdm.used_entries;
>>> -            if ( __copy_to_guest(compat, &grdm.map, 1) )
>>> -                rc = -EFAULT;
>>> +            if ( grdm.map.nr_entries )
>>> +            {
>>> +                if ( __copy_to_guest(compat, &grdm.map, 1) )
>>> +                    rc = -EFAULT;
>>> +            }
>>
>> Why do you need this change?
> 
> If we have no any entries, why do we still copy that?

That's not only a pointless optimization (the counter question being
"Why add an extra conditional when the copying does no harm?"), but
also not subject of this patch. Additionally iirc the field is an IN/OUT,
i.e. when no entries were found you want to tell the caller so.

>>> --- a/xen/drivers/passthrough/vtd/dmar.c
>>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>>> @@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
>>>
>>>   int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>>   {
>>> -    struct acpi_rmrr_unit *rmrr;
>>> +    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
>>>       int rc = 0;
>>> +    unsigned 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 ( 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;
>>> +
>>> +            /* Just go next. */
>>> +            if ( !rc )
>>> +                rmrr_cur = rmrr;
>>> +
>>> +            /* Now just return specific to user requirement. */
>>> +            if ( rc > 0 )
>>> +                return rc;
>>
>> Nice that you check for that, but I can't see this case occurring
>> anymore. Did you lose some code? Also please don't write code
> 
> We have three scenarios here:
> 
> #1 rc < 0 means this is an error;
> #2 rc = 0 means the tools caller don't know how many buffers it should 
> construct, so we need to count all entries as 'nr_entries' to return.
> #3 rc > 0 means in some cases, we need to return some specific values, 
> like 1 to indicate we're hitting some RMRR range. Currently, we use gfn 
> to check this in case of memory populating, ept violation handler and 
> mem_access.

Yes, I saw that you make use of this in later patches. It just seemed
suspicious that you don't in this one.

>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -586,6 +586,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 */
>>
>> Your addition lacks an IN annotation.
> 
> Are you saying something for 'nr_entries'? But I didn't introduce 
> anything to change the original usage. Anyway, I try to improve this,
> 
>      /*
>       * IN: on call the number of entries which can be stored in buffer.
>       * OUT: on return the number of entries which have been stored in
>       * buffer. If on call the number is less the number of all necessary
>       * entries, on return the number of entries which is needed.
>       */
> 

No, I said "your addition lacks ...". And you addition is the "domid"
field.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:51:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08: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 1Xxu2M-00020z-H8; Mon, 08 Dec 2014 08:51: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 1Xxu2J-00020u-Oc
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 08:51:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B8/6B-25276-78665845; Mon, 08 Dec 2014 08:51:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418028678!13731281!1
X-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 13856 invoked from network); 8 Dec 2014 08:51:18 -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; 8 Dec 2014 08:51:18 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:51:17 +0000
Message-Id: <54857491020000780004D9D6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:51:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
In-Reply-To: <54854F2D.6060204@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 08:11, <tiejun.chen@intel.com> wrote:
> On 2014/12/4 23:50, Jan Beulich wrote:
>>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>>>
>>> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>>> -                                     &rdm, 1) )
>>> -            return -EFAULT;
>>> +    if ( d )
>>> +    {
>>> +        if ( d->arch.hvm_domain.pci_force )
>>
>> You didn't verify that the domain is a HVM/PVH one.
> 
> Is this, ASSERT(is_hvm_domain(grdm.domain)), correct?

Certainly not, or do you want to crash the hypervisor because of bad
tools input?

>>> +        {
>>> +            if ( grdm->used_entries < grdm->map.nr_entries )
>>> +            {
>>> +                if ( __copy_to_compat_offset(grdm->map.buffer,
>>> +                                             grdm->used_entries,
>>> +                                             &rdm, 1) )
>>> +                {
>>> +                    rcu_unlock_domain(d);
>>> +                    return -EFAULT;
>>> +                }
>>> +            }
>>> +            ++grdm->used_entries;
>>> +        }
>>> +        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 ( grdm->used_entries < grdm->map.nr_entries )
>>> +                    {
>>> +                        if ( __copy_to_compat_offset(grdm->map.buffer,
>>> +                                                     grdm->used_entries,
>>> +                                                     &rdm, 1) )
>>> +                        {
>>> +                            rcu_unlock_domain(d);
>>> +                            return -EFAULT;
>>> +                        }
>>> +                    }
>>> +                    ++grdm->used_entries;
>>
>> break;
> 
> Added.
> 
>>
>> Also trying to fold code identical on the if and else branches would
>> seem pretty desirable.
> 
> Sorry, I can't see what I'm missing.

The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
is identical and can be factored out pretty easily afaict.

>>> @@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) compat)
>>>
>>>               if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>>>                   rc = -ENOBUFS;
>>> +
>>>               grdm.map.nr_entries = grdm.used_entries;
>>> -            if ( __copy_to_guest(compat, &grdm.map, 1) )
>>> -                rc = -EFAULT;
>>> +            if ( grdm.map.nr_entries )
>>> +            {
>>> +                if ( __copy_to_guest(compat, &grdm.map, 1) )
>>> +                    rc = -EFAULT;
>>> +            }
>>
>> Why do you need this change?
> 
> If we have no any entries, why do we still copy that?

That's not only a pointless optimization (the counter question being
"Why add an extra conditional when the copying does no harm?"), but
also not subject of this patch. Additionally iirc the field is an IN/OUT,
i.e. when no entries were found you want to tell the caller so.

>>> --- a/xen/drivers/passthrough/vtd/dmar.c
>>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>>> @@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
>>>
>>>   int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>>   {
>>> -    struct acpi_rmrr_unit *rmrr;
>>> +    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
>>>       int rc = 0;
>>> +    unsigned 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 ( 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;
>>> +
>>> +            /* Just go next. */
>>> +            if ( !rc )
>>> +                rmrr_cur = rmrr;
>>> +
>>> +            /* Now just return specific to user requirement. */
>>> +            if ( rc > 0 )
>>> +                return rc;
>>
>> Nice that you check for that, but I can't see this case occurring
>> anymore. Did you lose some code? Also please don't write code
> 
> We have three scenarios here:
> 
> #1 rc < 0 means this is an error;
> #2 rc = 0 means the tools caller don't know how many buffers it should 
> construct, so we need to count all entries as 'nr_entries' to return.
> #3 rc > 0 means in some cases, we need to return some specific values, 
> like 1 to indicate we're hitting some RMRR range. Currently, we use gfn 
> to check this in case of memory populating, ept violation handler and 
> mem_access.

Yes, I saw that you make use of this in later patches. It just seemed
suspicious that you don't in this one.

>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -586,6 +586,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 */
>>
>> Your addition lacks an IN annotation.
> 
> Are you saying something for 'nr_entries'? But I didn't introduce 
> anything to change the original usage. Anyway, I try to improve this,
> 
>      /*
>       * IN: on call the number of entries which can be stored in buffer.
>       * OUT: on return the number of entries which have been stored in
>       * buffer. If on call the number is less the number of all necessary
>       * entries, on return the number of entries which is needed.
>       */
> 

No, I said "your addition lacks ...". And you addition is the "domid"
field.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:52:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxu3B-0002Gk-Ud; Mon, 08 Dec 2014 08:52:13 +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 1Xxu3A-0002GZ-MH
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 08:52:12 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C6/24-02696-BB665845; Mon, 08 Dec 2014 08:52:11 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418028730!13617217!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10913 invoked from network); 8 Dec 2014 08:52:11 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-27.messagelabs.com with SMTP;
	8 Dec 2014 08:52:11 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 08 Dec 2014 00:52:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,537,1413270000"; d="scan'208";a="650155728"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 08 Dec 2014 00:52:07 -0800
Message-ID: <548566B7.8080508@intel.com>
Date: Mon, 08 Dec 2014 16:52: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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
	<54809169020000780004CD03@mail.emea.novell.com>
In-Reply-To: <54809169020000780004CD03@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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/12/4 23:52, Jan Beulich wrote:
>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> We need to use reserved device memory maps with multiple times, so
>> provide just one common function should be friend.
>
> I'm not going to repeat earlier comments; the way this is done right
> now it's neither a proper runtime function nor a proper init time one.
>

Actually I tried to do this in runtime as I comments in patch head. But 
maybe you hope I should return rdm_map directly, and nr_entries as a 
in/out parameter, 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 Dec 08 08:52:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxu3B-0002Gk-Ud; Mon, 08 Dec 2014 08:52:13 +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 1Xxu3A-0002GZ-MH
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 08:52:12 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	C6/24-02696-BB665845; Mon, 08 Dec 2014 08:52:11 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418028730!13617217!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10913 invoked from network); 8 Dec 2014 08:52:11 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-27.messagelabs.com with SMTP;
	8 Dec 2014 08:52:11 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 08 Dec 2014 00:52:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,537,1413270000"; d="scan'208";a="650155728"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 08 Dec 2014 00:52:07 -0800
Message-ID: <548566B7.8080508@intel.com>
Date: Mon, 08 Dec 2014 16:52: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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
	<54809169020000780004CD03@mail.emea.novell.com>
In-Reply-To: <54809169020000780004CD03@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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/12/4 23:52, Jan Beulich wrote:
>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> We need to use reserved device memory maps with multiple times, so
>> provide just one common function should be friend.
>
> I'm not going to repeat earlier comments; the way this is done right
> now it's neither a proper runtime function nor a proper init time one.
>

Actually I tried to do this in runtime as I comments in patch head. But 
maybe you hope I should return rdm_map directly, and nr_entries as a 
in/out parameter, 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 Dec 08 08:52:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08: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 1Xxu3p-0002Lr-Bu; Mon, 08 Dec 2014 08:52: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 1Xxu3o-0002Lf-6V
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 08:52:52 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	2E/5E-02702-3E665845; Mon, 08 Dec 2014 08:52:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418028770!13617046!1
X-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 2072 invoked from network); 8 Dec 2014 08:52:50 -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; 8 Dec 2014 08:52:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:52:50 +0000
Message-Id: <548574ED020000780004D9D9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:52:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <5481F18C020000780004D535@mail.emea.novell.com>
	<54824832.9000607@linaro.org>
In-Reply-To: <54824832.9000607@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.12.14 at 01:05, <julien.grall@linaro.org> wrote:
> On 05/12/2014 16:55, Jan Beulich wrote:
>   > I didn't change ARM, as I wasn't sure how far ahead this call could be
>> pulled.
> 
> AFAIU, the new function only requires that the page table are setup 
> (because of the alloc_xenheap_pages).
> 
> So console_init_mem could be called right after console_init_preirq.

No, it requires that alloc_xenheap_pages() works, i.e. it surely can't
be placed before the end_boot_allocator() invocation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:52:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08: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 1Xxu3p-0002Lr-Bu; Mon, 08 Dec 2014 08:52: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 1Xxu3o-0002Lf-6V
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 08:52:52 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	2E/5E-02702-3E665845; Mon, 08 Dec 2014 08:52:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418028770!13617046!1
X-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 2072 invoked from network); 8 Dec 2014 08:52:50 -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; 8 Dec 2014 08:52:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:52:50 +0000
Message-Id: <548574ED020000780004D9D9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:52:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <5481F18C020000780004D535@mail.emea.novell.com>
	<54824832.9000607@linaro.org>
In-Reply-To: <54824832.9000607@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.12.14 at 01:05, <julien.grall@linaro.org> wrote:
> On 05/12/2014 16:55, Jan Beulich wrote:
>   > I didn't change ARM, as I wasn't sure how far ahead this call could be
>> pulled.
> 
> AFAIU, the new function only requires that the page table are setup 
> (because of the alloc_xenheap_pages).
> 
> So console_init_mem could be called right after console_init_preirq.

No, it requires that alloc_xenheap_pages() works, i.e. it surely can't
be placed before the end_boot_allocator() invocation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:54:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:54:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxu58-0002V6-Uz; Mon, 08 Dec 2014 08:54:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xxu56-0002Ur-Qk
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 08:54:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	78/B0-15461-43765845; Mon, 08 Dec 2014 08:54:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418028851!14046040!1
X-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 31704 invoked from network); 8 Dec 2014 08:54:11 -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; 8 Dec 2014 08:54:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:54:11 +0000
Message-Id: <54857540020000780004D9DC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:54:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <5481F18C020000780004D535@mail.emea.novell.com>
	<20141205172257.GC16236@olila.local.net-space.pl>
In-Reply-To: <20141205172257.GC16236@olila.local.net-space.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 18:22, <daniel.kiper@oracle.com> wrote:
> On Fri, Dec 05, 2014 at 04:55:24PM +0000, Jan Beulich wrote:
>> @@ -763,17 +762,28 @@ void __init console_init_postirq(void)
>>      }
>>      opt_conring_size = PAGE_SIZE << order;
>>
>> -    spin_lock_irq(&console_lock);
>> +    spin_lock_irqsave(&console_lock, flags);
> 
> I am not sure why are you change spin_lock_irq() to spin_lock_irqsave() 
> here.
> Could you explain this in commit message?

I think this is quite obvious in the context here: Previously this was
guaranteed to be called after interrupts were already enabled (hence
the _postirq name). That's not the case anymore, and thus we can't
blindly enable interrupts when releasing the lock.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:54:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:54:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxu58-0002V6-Uz; Mon, 08 Dec 2014 08:54:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xxu56-0002Ur-Qk
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 08:54:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	78/B0-15461-43765845; Mon, 08 Dec 2014 08:54:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418028851!14046040!1
X-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 31704 invoked from network); 8 Dec 2014 08:54:11 -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; 8 Dec 2014 08:54:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:54:11 +0000
Message-Id: <54857540020000780004D9DC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:54:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <5481F18C020000780004D535@mail.emea.novell.com>
	<20141205172257.GC16236@olila.local.net-space.pl>
In-Reply-To: <20141205172257.GC16236@olila.local.net-space.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 18:22, <daniel.kiper@oracle.com> wrote:
> On Fri, Dec 05, 2014 at 04:55:24PM +0000, Jan Beulich wrote:
>> @@ -763,17 +762,28 @@ void __init console_init_postirq(void)
>>      }
>>      opt_conring_size = PAGE_SIZE << order;
>>
>> -    spin_lock_irq(&console_lock);
>> +    spin_lock_irqsave(&console_lock, flags);
> 
> I am not sure why are you change spin_lock_irq() to spin_lock_irqsave() 
> here.
> Could you explain this in commit message?

I think this is quite obvious in the context here: Previously this was
guaranteed to be called after interrupts were already enabled (hence
the _postirq name). That's not the case anymore, and thus we can't
blindly enable interrupts when releasing the lock.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 08:56:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:56:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxu6t-0002gs-Em; Mon, 08 Dec 2014 08:56: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 1Xxu6s-0002gn-BY
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 08:56:02 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	57/55-23865-1A765845; Mon, 08 Dec 2014 08:56:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418028960!9291692!1
X-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 15184 invoked from network); 8 Dec 2014 08:56: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; 8 Dec 2014 08:56:01 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:56:00 +0000
Message-Id: <548575AD020000780004D9FF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:55:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<20141205145117.GX16236@olila.local.net-space.pl>
	<5481D68E020000780004D3AD@mail.emea.novell.com>
	<20141205164016.GB16236@olila.local.net-space.pl>
	<5481F2D4020000780004D543@mail.emea.novell.com>
	<20141205175927.GF16236@olila.local.net-space.pl>
In-Reply-To: <20141205175927.GF16236@olila.local.net-space.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 18:59, <daniel.kiper@oracle.com> wrote:
> On Fri, Dec 05, 2014 at 05:00:52PM +0000, Jan Beulich wrote:
>> >>> On 05.12.14 at 17:40, <daniel.kiper@oracle.com> wrote:
>> > On Fri, Dec 05, 2014 at 03:00:14PM +0000, Jan Beulich wrote:
>> >> but I don't think this possibility of renaming warrants a much longer
>> >> discussion. Please also remember that renaming always implies more
>> >> cumbersome backporting, even if only slightly more.
>> >
>> > I suppose that you are thinking about backporting my EFI + multiboot2
>> > patches somewhere.
>>
>> Not really, I was just thinking about bug fixes in general.
> 
> OK. So, go or no go for efi-boot.h name change to boot.h (of course
> after 4.5 release)? If yes then when? After or before my EFI + multiboot2
> patches? I would like to know that in advance because I am going to
> release first version next week.

I'd say a name change (and only that) should be done before
finishing 4.5 or only when (later) there's a real need to change 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 Dec 08 08:56:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 08:56:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxu6t-0002gs-Em; Mon, 08 Dec 2014 08:56: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 1Xxu6s-0002gn-BY
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 08:56:02 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	57/55-23865-1A765845; Mon, 08 Dec 2014 08:56:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418028960!9291692!1
X-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 15184 invoked from network); 8 Dec 2014 08:56: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; 8 Dec 2014 08:56:01 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 08:56:00 +0000
Message-Id: <548575AD020000780004D9FF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 08:55:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <20141203210225.GR16236@olila.local.net-space.pl>
	<548038D5020000780004C9E8@mail.emea.novell.com>
	<20141205145117.GX16236@olila.local.net-space.pl>
	<5481D68E020000780004D3AD@mail.emea.novell.com>
	<20141205164016.GB16236@olila.local.net-space.pl>
	<5481F2D4020000780004D543@mail.emea.novell.com>
	<20141205175927.GF16236@olila.local.net-space.pl>
In-Reply-To: <20141205175927.GF16236@olila.local.net-space.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, roy.franz@linaro.org,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] A few EFI code questions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.12.14 at 18:59, <daniel.kiper@oracle.com> wrote:
> On Fri, Dec 05, 2014 at 05:00:52PM +0000, Jan Beulich wrote:
>> >>> On 05.12.14 at 17:40, <daniel.kiper@oracle.com> wrote:
>> > On Fri, Dec 05, 2014 at 03:00:14PM +0000, Jan Beulich wrote:
>> >> but I don't think this possibility of renaming warrants a much longer
>> >> discussion. Please also remember that renaming always implies more
>> >> cumbersome backporting, even if only slightly more.
>> >
>> > I suppose that you are thinking about backporting my EFI + multiboot2
>> > patches somewhere.
>>
>> Not really, I was just thinking about bug fixes in general.
> 
> OK. So, go or no go for efi-boot.h name change to boot.h (of course
> after 4.5 release)? If yes then when? After or before my EFI + multiboot2
> patches? I would like to know that in advance because I am going to
> release first version next week.

I'd say a name change (and only that) should be done before
finishing 4.5 or only when (later) there's a real need to change 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 Dec 08 09:04:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09: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 1XxuF9-00038t-MR; Mon, 08 Dec 2014 09:04:35 +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 1XxuF8-00038o-4Y
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 09:04:34 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	6D/EE-02953-1A965845; Mon, 08 Dec 2014 09:04:33 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418029471!13597834!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32201 invoked from network); 8 Dec 2014 09:04:32 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-27.messagelabs.com with SMTP;
	8 Dec 2014 09:04:32 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 08 Dec 2014 01:04:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,537,1413270000"; d="scan'208";a="650161083"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 08 Dec 2014 01:04:28 -0800
Message-ID: <5485699B.9010103@intel.com>
Date: Mon, 08 Dec 2014 17:04:27 +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.3.0
MIME-Version: 1.0
To: "Tian, Kevin" <kevin.tian@intel.com>, 
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, 
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Zhang, Yang Z" <yang.z.zhang@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-9-git-send-email-tiejun.chen@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610ABFD@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610ABFD@SHSMSX101.ccr.corp.intel.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 08/17] hvmloader/mmio: reconcile guest
 mmio with reserved device 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 2014/12/2 17:11, Tian, Kevin wrote:
>> From: Chen, Tiejun
>> Sent: Monday, December 01, 2014 5:24 PM
>>
>> We need to make sure all mmio allocation don't overlap
>> any rdm, reserved device memory. Here we just skip
>> all reserved device memory range in mmio space.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   tools/firmware/hvmloader/pci.c  | 54
>> ++++++++++++++++++++++++++++++++++++++++-
>>   tools/firmware/hvmloader/util.c |  9 +++++++
>>   tools/firmware/hvmloader/util.h |  2 ++
>>   3 files changed, 64 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
>> index 4e8d803..fc22ab3 100644
>> --- a/tools/firmware/hvmloader/pci.c
>> +++ b/tools/firmware/hvmloader/pci.c
>> @@ -38,6 +38,30 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
>>   enum virtual_vga virtual_vga = VGA_none;
>>   unsigned long igd_opregion_pgbase = 0;
>>
>> +static unsigned int need_skip_rmrr;
>> +extern struct xen_reserved_device_memory *rdm_map;
>> +
>> +static unsigned int
>> +check_reserved_device_memory_map(uint64_t mmio_base, uint64_t
>> mmio_max)
>> +{
>> +    uint32_t i;
>> +    uint64_t rdm_start, rdm_end;
>> +    unsigned int nr_rdm_entries =
>> hvm_get_reserved_device_memory_map();
>> +
>> +    for ( i = 0; i < nr_rdm_entries; i++ )
>> +    {
>> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
>> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages <<
>> PAGE_SHIFT);
>> +        if ( check_rdm_hole_conflict(mmio_base, mmio_max -
>> mmio_base,
>> +                                     rdm_start, rdm_end -
>> rdm_start) )
>> +        {
>> +            need_skip_rmrr++;
>> +        }
>> +    }
>> +
>> +    return nr_rdm_entries;
>> +}
>> +
>
> I don't understand the use of need_skip_rmrr here. What does the counter actually
> mean here? Also the function is not well organized. Usually the value returned is
> the major purpose of the function, but it looks the function is actually for need_skip_rmrr.
> If it's the actual purpose, better to rename the function and move nr_rdm_entries
> directly in the outer function.

See online below.

>
>>   void pci_setup(void)
>>   {
>>       uint8_t is_64bar, using_64bar, bar64_relocate = 0;
>> @@ -59,8 +83,10 @@ void pci_setup(void)
>>           uint32_t bar_reg;
>>           uint64_t bar_sz;
>>       } *bars = (struct bars *)scratch_start;
>> -    unsigned int i, nr_bars = 0;
>> +    unsigned int i, j, nr_bars = 0;
>>       uint64_t mmio_hole_size = 0;
>> +    unsigned int nr_rdm_entries;
>> +    uint64_t rdm_start, rdm_end;
>>
>>       const char *s;
>>       /*
>> @@ -338,6 +364,14 @@ void pci_setup(void)
>>       io_resource.base = 0xc000;
>>       io_resource.max = 0x10000;
>>
>> +    /* Check low mmio range. */
>> +    nr_rdm_entries =
>> check_reserved_device_memory_map(mem_resource.base,
>> +
>> mem_resource.max);
>> +    /* Check high mmio range. */
>> +    if ( nr_rdm_entries )
>> +        nr_rdm_entries =
>> check_reserved_device_memory_map(high_mem_resource.base,
>> +
>> high_mem_resource.max);
>> +
>>       /* Assign iomem and ioport resources in descending order of size. */
>>       for ( i = 0; i < nr_bars; i++ )
>>       {
>> @@ -393,8 +427,26 @@ void pci_setup(void)
>>           }
>>
>>           base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
>> + reallocate_mmio:
>>           bar_data |= (uint32_t)base;
>>           bar_data_upper = (uint32_t)(base >> 32);
>> +
>> +        if ( need_skip_rmrr )
>> +        {
>> +            for ( j = 0; j < nr_rdm_entries; j++ )
>> +            {
>> +                rdm_start = (uint64_t)rdm_map[j].start_pfn <<
>> PAGE_SHIFT;
>> +                rdm_end = rdm_start + ((uint64_t)rdm_map[j].nr_pages
>> << PAGE_SHIFT);
>> +                if ( check_rdm_hole_conflict(base, bar_sz,
>> +                                             rdm_start, rdm_end -
>> rdm_start) )
>> +                {
>> +                    base = (rdm_end  + bar_sz - 1) & ~(uint64_t)(bar_sz
>> - 1);
>> +                    need_skip_rmrr--;
>> +                    goto reallocate_mmio;
>> +                }
>> +            }
>> +        }
>> +
>
> here is the point which I don't understand. what's required here is just to
> walk the rmrr entries for a given allocation, and if conflicting then move
> the base. Then how does need_skip_rmrr helps here? and why do you
> need pre-check on low/high region earlier?

We may have multiple RMRR entries but some of entries may overlap mmio. 
Here I use need_skip_rmrr to count this.

When we skip one RMRR entry to allocate a range for a pci device, we 
shouldn't check this entry again since this means we already cross that 
range, then we decrease need_skip_rmrr. Once need_skip_rmrr is changed 
as zero, even need_skip_rmrr is always zero, we should do nothing.

Thanks
Tiejun

>
>>           base += bar_sz;
>>
>>           if ( (base < resource->base) || (base > resource->max) )
>> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
>> index dd81fb6..8767897 100644
>> --- a/tools/firmware/hvmloader/util.c
>> +++ b/tools/firmware/hvmloader/util.c
>> @@ -887,6 +887,15 @@ unsigned int
>> hvm_get_reserved_device_memory_map(void)
>>       return nr_entries;
>>   }
>>
>> +int check_rdm_hole_conflict(uint64_t start, uint64_t size,
>> +                            uint64_t rdm_start, uint64_t rdm_size)
>> +{
>> +    if ( start + size <= rdm_start || start >= rdm_start + rdm_size )
>> +        return 0;
>> +    else
>> +        return 1;
>> +}
>> +
>>   /*
>>    * Local variables:
>>    * mode: C
>> diff --git a/tools/firmware/hvmloader/util.h
>> b/tools/firmware/hvmloader/util.h
>> index e4f1851..9b02f95 100644
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
>> @@ -242,6 +242,8 @@ int build_e820_table(struct e820entry *e820,
>>   void dump_e820_table(struct e820entry *e820, unsigned int nr);
>>
>>   unsigned int hvm_get_reserved_device_memory_map(void);
>> +int check_rdm_hole_conflict(uint64_t start, uint64_t size,
>> +                            uint64_t rdm_start, uint64_t rdm_size);
>>
>>   #ifndef NDEBUG
>>   void perform_tests(void);
>> --
>> 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 Dec 08 09:04:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09: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 1XxuF9-00038t-MR; Mon, 08 Dec 2014 09:04:35 +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 1XxuF8-00038o-4Y
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 09:04:34 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	6D/EE-02953-1A965845; Mon, 08 Dec 2014 09:04:33 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418029471!13597834!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32201 invoked from network); 8 Dec 2014 09:04:32 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-27.messagelabs.com with SMTP;
	8 Dec 2014 09:04:32 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 08 Dec 2014 01:04:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,537,1413270000"; d="scan'208";a="650161083"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by orsmga002.jf.intel.com with ESMTP; 08 Dec 2014 01:04:28 -0800
Message-ID: <5485699B.9010103@intel.com>
Date: Mon, 08 Dec 2014 17:04:27 +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.3.0
MIME-Version: 1.0
To: "Tian, Kevin" <kevin.tian@intel.com>, 
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, 
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, 
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"tim@xen.org" <tim@xen.org>, "Zhang, Yang Z" <yang.z.zhang@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-9-git-send-email-tiejun.chen@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12610ABFD@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12610ABFD@SHSMSX101.ccr.corp.intel.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [v8][PATCH 08/17] hvmloader/mmio: reconcile guest
 mmio with reserved device 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 2014/12/2 17:11, Tian, Kevin wrote:
>> From: Chen, Tiejun
>> Sent: Monday, December 01, 2014 5:24 PM
>>
>> We need to make sure all mmio allocation don't overlap
>> any rdm, reserved device memory. Here we just skip
>> all reserved device memory range in mmio space.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   tools/firmware/hvmloader/pci.c  | 54
>> ++++++++++++++++++++++++++++++++++++++++-
>>   tools/firmware/hvmloader/util.c |  9 +++++++
>>   tools/firmware/hvmloader/util.h |  2 ++
>>   3 files changed, 64 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
>> index 4e8d803..fc22ab3 100644
>> --- a/tools/firmware/hvmloader/pci.c
>> +++ b/tools/firmware/hvmloader/pci.c
>> @@ -38,6 +38,30 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
>>   enum virtual_vga virtual_vga = VGA_none;
>>   unsigned long igd_opregion_pgbase = 0;
>>
>> +static unsigned int need_skip_rmrr;
>> +extern struct xen_reserved_device_memory *rdm_map;
>> +
>> +static unsigned int
>> +check_reserved_device_memory_map(uint64_t mmio_base, uint64_t
>> mmio_max)
>> +{
>> +    uint32_t i;
>> +    uint64_t rdm_start, rdm_end;
>> +    unsigned int nr_rdm_entries =
>> hvm_get_reserved_device_memory_map();
>> +
>> +    for ( i = 0; i < nr_rdm_entries; i++ )
>> +    {
>> +        rdm_start = (uint64_t)rdm_map[i].start_pfn << PAGE_SHIFT;
>> +        rdm_end = rdm_start + ((uint64_t)rdm_map[i].nr_pages <<
>> PAGE_SHIFT);
>> +        if ( check_rdm_hole_conflict(mmio_base, mmio_max -
>> mmio_base,
>> +                                     rdm_start, rdm_end -
>> rdm_start) )
>> +        {
>> +            need_skip_rmrr++;
>> +        }
>> +    }
>> +
>> +    return nr_rdm_entries;
>> +}
>> +
>
> I don't understand the use of need_skip_rmrr here. What does the counter actually
> mean here? Also the function is not well organized. Usually the value returned is
> the major purpose of the function, but it looks the function is actually for need_skip_rmrr.
> If it's the actual purpose, better to rename the function and move nr_rdm_entries
> directly in the outer function.

See online below.

>
>>   void pci_setup(void)
>>   {
>>       uint8_t is_64bar, using_64bar, bar64_relocate = 0;
>> @@ -59,8 +83,10 @@ void pci_setup(void)
>>           uint32_t bar_reg;
>>           uint64_t bar_sz;
>>       } *bars = (struct bars *)scratch_start;
>> -    unsigned int i, nr_bars = 0;
>> +    unsigned int i, j, nr_bars = 0;
>>       uint64_t mmio_hole_size = 0;
>> +    unsigned int nr_rdm_entries;
>> +    uint64_t rdm_start, rdm_end;
>>
>>       const char *s;
>>       /*
>> @@ -338,6 +364,14 @@ void pci_setup(void)
>>       io_resource.base = 0xc000;
>>       io_resource.max = 0x10000;
>>
>> +    /* Check low mmio range. */
>> +    nr_rdm_entries =
>> check_reserved_device_memory_map(mem_resource.base,
>> +
>> mem_resource.max);
>> +    /* Check high mmio range. */
>> +    if ( nr_rdm_entries )
>> +        nr_rdm_entries =
>> check_reserved_device_memory_map(high_mem_resource.base,
>> +
>> high_mem_resource.max);
>> +
>>       /* Assign iomem and ioport resources in descending order of size. */
>>       for ( i = 0; i < nr_bars; i++ )
>>       {
>> @@ -393,8 +427,26 @@ void pci_setup(void)
>>           }
>>
>>           base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
>> + reallocate_mmio:
>>           bar_data |= (uint32_t)base;
>>           bar_data_upper = (uint32_t)(base >> 32);
>> +
>> +        if ( need_skip_rmrr )
>> +        {
>> +            for ( j = 0; j < nr_rdm_entries; j++ )
>> +            {
>> +                rdm_start = (uint64_t)rdm_map[j].start_pfn <<
>> PAGE_SHIFT;
>> +                rdm_end = rdm_start + ((uint64_t)rdm_map[j].nr_pages
>> << PAGE_SHIFT);
>> +                if ( check_rdm_hole_conflict(base, bar_sz,
>> +                                             rdm_start, rdm_end -
>> rdm_start) )
>> +                {
>> +                    base = (rdm_end  + bar_sz - 1) & ~(uint64_t)(bar_sz
>> - 1);
>> +                    need_skip_rmrr--;
>> +                    goto reallocate_mmio;
>> +                }
>> +            }
>> +        }
>> +
>
> here is the point which I don't understand. what's required here is just to
> walk the rmrr entries for a given allocation, and if conflicting then move
> the base. Then how does need_skip_rmrr helps here? and why do you
> need pre-check on low/high region earlier?

We may have multiple RMRR entries but some of entries may overlap mmio. 
Here I use need_skip_rmrr to count this.

When we skip one RMRR entry to allocate a range for a pci device, we 
shouldn't check this entry again since this means we already cross that 
range, then we decrease need_skip_rmrr. Once need_skip_rmrr is changed 
as zero, even need_skip_rmrr is always zero, we should do nothing.

Thanks
Tiejun

>
>>           base += bar_sz;
>>
>>           if ( (base < resource->base) || (base > resource->max) )
>> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
>> index dd81fb6..8767897 100644
>> --- a/tools/firmware/hvmloader/util.c
>> +++ b/tools/firmware/hvmloader/util.c
>> @@ -887,6 +887,15 @@ unsigned int
>> hvm_get_reserved_device_memory_map(void)
>>       return nr_entries;
>>   }
>>
>> +int check_rdm_hole_conflict(uint64_t start, uint64_t size,
>> +                            uint64_t rdm_start, uint64_t rdm_size)
>> +{
>> +    if ( start + size <= rdm_start || start >= rdm_start + rdm_size )
>> +        return 0;
>> +    else
>> +        return 1;
>> +}
>> +
>>   /*
>>    * Local variables:
>>    * mode: C
>> diff --git a/tools/firmware/hvmloader/util.h
>> b/tools/firmware/hvmloader/util.h
>> index e4f1851..9b02f95 100644
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
>> @@ -242,6 +242,8 @@ int build_e820_table(struct e820entry *e820,
>>   void dump_e820_table(struct e820entry *e820, unsigned int nr);
>>
>>   unsigned int hvm_get_reserved_device_memory_map(void);
>> +int check_rdm_hole_conflict(uint64_t start, uint64_t size,
>> +                            uint64_t rdm_start, uint64_t rdm_size);
>>
>>   #ifndef NDEBUG
>>   void perform_tests(void);
>> --
>> 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 Dec 08 09:07:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09: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 1XxuHk-0003FN-Ba; Mon, 08 Dec 2014 09:07:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XxuHi-0003FC-DZ
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 09:07:14 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	88/38-14214-14A65845; Mon, 08 Dec 2014 09:07:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418029631!12113961!1
X-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 31110 invoked from network); 8 Dec 2014 09:07:11 -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; 8 Dec 2014 09:07:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 09:07:10 +0000
Message-Id: <5485784B020000780004DA1C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 09:07:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mukesh Rathor" <mukesh.rathor@oracle.com>
References: <5481CA0D020000780004D2E8@mail.emea.novell.com>
	<20141205175030.32cb60a1@mantra.us.oracle.com>
In-Reply-To: <20141205175030.32cb60a1@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Length: 1593
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] VMX: don't allow PVH to reach handle_pio()
 or handle_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDA2LjEyLjE0IGF0IDAyOjUwLCA8bXVrZXNoLnJhdGhvckBvcmFjbGUuY29tPiB3cm90
ZToKPiBPbiBGcmksIDA1IERlYyAyMDE0IDE0OjA2OjUzICswMDAwCj4gIkphbiBCZXVsaWNoIiA8
SkJldWxpY2hAc3VzZS5jb20+IHdyb3RlOgo+IAo+PiBQVkggZ3Vlc3RzIGFyZSBub3Qgc3VwcG9z
ZWQgdG8gYWNjZXNzIEkvTyBwb3J0cyB0aGV5IHdlcmVuJ3QgZ2l2ZW4KPj4gYWNjZXNzIHRvICh0
aGVyZSdzIG5vdGhpbmcgdG8gaGFuZGxlIGVtdWxhdGlvbiBvZiBzdWNoIGFjY2Vzc2VzKS4KPj4g
Cj4+IFJlcG9ydGVkLWJ5OiBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBjaXRyaXguY29tPgo+
PiBTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Cj4+IC0tLQo+
PiBOb3RlOiBPbmx5IGNvbXBpbGUgdGVzdGVkIHNvIGZhci4KPj4gCj4+IC0tLSBhL3hlbi9hcmNo
L3g4Ni9odm0vdm14L3ZteC5jCj4+ICsrKyBiL3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5jCj4+
IEBAIC0zMDgyLDYgKzMwODIsOSBAQCB2b2lkIHZteF92bWV4aXRfaGFuZGxlcihzdHJ1Y3QgY3B1
X3VzZXJfCj4+ICAgICAgfQo+PiAgCj4+ICAgICAgY2FzZSBFWElUX1JFQVNPTl9JT19JTlNUUlVD
VElPTjoKPj4gKyAgICAgICAgaWYgKCB1bmxpa2VseShpc19wdmhfdmNwdSh2KSkgKQo+PiArICAg
ICAgICAgICAgZ290byBleGl0X2FuZF9jcmFzaDsKPj4gKwo+PiAgICAgICAgICBfX3ZtcmVhZChF
WElUX1FVQUxJRklDQVRJT04sICZleGl0X3F1YWxpZmljYXRpb24pOwo+PiAgICAgICAgICBpZiAo
IGV4aXRfcXVhbGlmaWNhdGlvbiAmIDB4MTAgKQo+PiAgICAgICAgICB7Cj4gCj4gQWN0dWFsbHks
IGhhbmRsZV9waW8oKSB3aWxsIGV2ZW50dWFsbHkgcmVhY2ggaGFuZGxlX3B2aF9pbygpIHdoaWNo
Cj4gd291bGQgYWNjZXNzIGNoZWNrIHZpYSBhZG1pbl9pb19va2F5LCBzbyB0aGF0IHBhdGggc2hv
dWxkIGJlIE9LLAo+IHJpZ2h0PwoKQWgsIHllcywgYXQgbGVhc3QgdGhhdCBjYXNlIHdhcyBhbHJl
YWR5IHRha2VuIGNhcmUgb2YuCgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 09:07:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09: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 1XxuHk-0003FN-Ba; Mon, 08 Dec 2014 09:07:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XxuHi-0003FC-DZ
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 09:07:14 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	88/38-14214-14A65845; Mon, 08 Dec 2014 09:07:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418029631!12113961!1
X-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 31110 invoked from network); 8 Dec 2014 09:07:11 -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; 8 Dec 2014 09:07:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 09:07:10 +0000
Message-Id: <5485784B020000780004DA1C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 09:07:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mukesh Rathor" <mukesh.rathor@oracle.com>
References: <5481CA0D020000780004D2E8@mail.emea.novell.com>
	<20141205175030.32cb60a1@mantra.us.oracle.com>
In-Reply-To: <20141205175030.32cb60a1@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Length: 1593
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] VMX: don't allow PVH to reach handle_pio()
 or handle_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDA2LjEyLjE0IGF0IDAyOjUwLCA8bXVrZXNoLnJhdGhvckBvcmFjbGUuY29tPiB3cm90
ZToKPiBPbiBGcmksIDA1IERlYyAyMDE0IDE0OjA2OjUzICswMDAwCj4gIkphbiBCZXVsaWNoIiA8
SkJldWxpY2hAc3VzZS5jb20+IHdyb3RlOgo+IAo+PiBQVkggZ3Vlc3RzIGFyZSBub3Qgc3VwcG9z
ZWQgdG8gYWNjZXNzIEkvTyBwb3J0cyB0aGV5IHdlcmVuJ3QgZ2l2ZW4KPj4gYWNjZXNzIHRvICh0
aGVyZSdzIG5vdGhpbmcgdG8gaGFuZGxlIGVtdWxhdGlvbiBvZiBzdWNoIGFjY2Vzc2VzKS4KPj4g
Cj4+IFJlcG9ydGVkLWJ5OiBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBjaXRyaXguY29tPgo+
PiBTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Cj4+IC0tLQo+
PiBOb3RlOiBPbmx5IGNvbXBpbGUgdGVzdGVkIHNvIGZhci4KPj4gCj4+IC0tLSBhL3hlbi9hcmNo
L3g4Ni9odm0vdm14L3ZteC5jCj4+ICsrKyBiL3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5jCj4+
IEBAIC0zMDgyLDYgKzMwODIsOSBAQCB2b2lkIHZteF92bWV4aXRfaGFuZGxlcihzdHJ1Y3QgY3B1
X3VzZXJfCj4+ICAgICAgfQo+PiAgCj4+ICAgICAgY2FzZSBFWElUX1JFQVNPTl9JT19JTlNUUlVD
VElPTjoKPj4gKyAgICAgICAgaWYgKCB1bmxpa2VseShpc19wdmhfdmNwdSh2KSkgKQo+PiArICAg
ICAgICAgICAgZ290byBleGl0X2FuZF9jcmFzaDsKPj4gKwo+PiAgICAgICAgICBfX3ZtcmVhZChF
WElUX1FVQUxJRklDQVRJT04sICZleGl0X3F1YWxpZmljYXRpb24pOwo+PiAgICAgICAgICBpZiAo
IGV4aXRfcXVhbGlmaWNhdGlvbiAmIDB4MTAgKQo+PiAgICAgICAgICB7Cj4gCj4gQWN0dWFsbHks
IGhhbmRsZV9waW8oKSB3aWxsIGV2ZW50dWFsbHkgcmVhY2ggaGFuZGxlX3B2aF9pbygpIHdoaWNo
Cj4gd291bGQgYWNjZXNzIGNoZWNrIHZpYSBhZG1pbl9pb19va2F5LCBzbyB0aGF0IHBhdGggc2hv
dWxkIGJlIE9LLAo+IHJpZ2h0PwoKQWgsIHllcywgYXQgbGVhc3QgdGhhdCBjYXNlIHdhcyBhbHJl
YWR5IHRha2VuIGNhcmUgb2YuCgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 09:11:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09:11:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxuLG-0003PJ-Vg; Mon, 08 Dec 2014 09:10: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 1XxuLF-0003PE-PZ
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 09:10:53 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	D2/CD-22819-D1B65845; Mon, 08 Dec 2014 09:10:53 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418029851!9189282!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12243 invoked from network); 8 Dec 2014 09:10:52 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-16.tower-206.messagelabs.com with SMTP;
	8 Dec 2014 09:10:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 08 Dec 2014 01:10:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,537,1413270000"; d="scan'208";a="634327448"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by fmsmga001.fm.intel.com with ESMTP; 08 Dec 2014 01:10:31 -0800
Message-ID: <54856B06.1020308@intel.com>
Date: Mon, 08 Dec 2014 17:10:30 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-9-git-send-email-tiejun.chen@intel.com>
	<54809437020000780004CD43@mail.emea.novell.com>
In-Reply-To: <54809437020000780004CD43@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 08/17] hvmloader/mmio: reconcile guest
 mmio with reserved device 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 2014/12/5 0:04, Jan Beulich wrote:
>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> We need to make sure all mmio allocation don't overlap
>> any rdm, reserved device memory. Here we just skip
>> all reserved device memory range in mmio space.
>
> I think someone else already suggested that this and patch 9 should

Who?

I just see Kevin commented something for this patch.

> be swapped, and the BAR allocation be changed to use the E820
> map as input. That may end up being a bigger change, but will yield
> ultimately better (and namely better maintainable) code.

Maybe you're saying some comments in patch9? I need to take a look.

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 Dec 08 09:11:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09:11:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxuLG-0003PJ-Vg; Mon, 08 Dec 2014 09:10: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 1XxuLF-0003PE-PZ
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 09:10:53 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	D2/CD-22819-D1B65845; Mon, 08 Dec 2014 09:10:53 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418029851!9189282!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12243 invoked from network); 8 Dec 2014 09:10:52 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-16.tower-206.messagelabs.com with SMTP;
	8 Dec 2014 09:10:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 08 Dec 2014 01:10:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,537,1413270000"; d="scan'208";a="634327448"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.117])
	([10.238.130.117])
	by fmsmga001.fm.intel.com with ESMTP; 08 Dec 2014 01:10:31 -0800
Message-ID: <54856B06.1020308@intel.com>
Date: Mon, 08 Dec 2014 17:10:30 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-9-git-send-email-tiejun.chen@intel.com>
	<54809437020000780004CD43@mail.emea.novell.com>
In-Reply-To: <54809437020000780004CD43@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 08/17] hvmloader/mmio: reconcile guest
 mmio with reserved device 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 2014/12/5 0:04, Jan Beulich wrote:
>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> We need to make sure all mmio allocation don't overlap
>> any rdm, reserved device memory. Here we just skip
>> all reserved device memory range in mmio space.
>
> I think someone else already suggested that this and patch 9 should

Who?

I just see Kevin commented something for this patch.

> be swapped, and the BAR allocation be changed to use the E820
> map as input. That may end up being a bigger change, but will yield
> ultimately better (and namely better maintainable) code.

Maybe you're saying some comments in patch9? I need to take a look.

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 Dec 08 09:12:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1XxuN1-0003hN-FU; Mon, 08 Dec 2014 09:12: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 1XxuN0-0003hF-Do
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 09:12:42 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	2D/0B-02702-98B65845; Mon, 08 Dec 2014 09:12:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418029960!13622182!1
X-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 31675 invoked from network); 8 Dec 2014 09:12:41 -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; 8 Dec 2014 09:12:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 09:12:40 +0000
Message-Id: <54857995020000780004DA2D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 09:12:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part47729B95.2__="
Cc: Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach handle_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part47729B95.2__=
Content-Type: text/plain; charset=UTF-8
Content-Length: 858
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

PVH guests accessing I/O ports via string ops is not supported yet.

Reported-by: Roger Pau Monn=C3=A9<roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: handle_pio() is already safe (pointed out by Mukesh), so only refuse
    entering handle_mmio().
Note: Only compile tested so far.

--- unstable.orig/xen/arch/x86/hvm/vmx/vmx.c	2014-11-27 09:37:27.000000000 +0100
+++ unstable/xen/arch/x86/hvm/vmx/vmx.c	2014-12-08 10:04:27.000000000 +0100
@@ -3086,7 +3086,8 @@ void vmx_vmexit_handler(struct cpu_user_
         if ( exit_qualification & 0x10 )
         {
             /* INS, OUTS */
-            if ( !handle_mmio() )
+            if ( unlikely(is_pvh_vcpu(v)) /* PVH fixme */ ||
+                 !handle_mmio() )
                 hvm_inject_hw_exception(TRAP_gp_fault, 0);
         }
         else



--=__Part47729B95.2__=
Content-Type: text/plain; name="VMX-PVH-no-emulated-IO-string-ops.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="VMX-PVH-no-emulated-IO-string-ops.patch"

PVH guests accessing I/O ports via string ops is not supported yet.=0A=0ARe=
ported-by: Roger Pau Monn=C3=A9<roger.pau@citrix.com>=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A---=0Av2: handle_pio() is already safe =
(pointed out by Mukesh), so only refuse=0A    entering handle_mmio().=0ANot=
e: Only compile tested so far.=0A=0A--- unstable.orig/xen/arch/x86/hvm/vmx/=
vmx.c	2014-11-27 09:37:27.000000000 +0100=0A+++ unstable/xen/arch/x86/hvm=
/vmx/vmx.c	2014-12-08 10:04:27.000000000 +0100=0A@@ -3086,7 +3086,8 =
@@ void vmx_vmexit_handler(struct cpu_user_=0A         if ( exit_qualificat=
ion & 0x10 )=0A         {=0A             /* INS, OUTS */=0A-            if =
( !handle_mmio() )=0A+            if ( unlikely(is_pvh_vcpu(v)) /* PVH =
fixme */ ||=0A+                 !handle_mmio() )=0A                 =
hvm_inject_hw_exception(TRAP_gp_fault, 0);=0A         }=0A         else=0A
--=__Part47729B95.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

--=__Part47729B95.2__=--


From xen-devel-bounces@lists.xen.org Mon Dec 08 09:12:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1XxuN1-0003hN-FU; Mon, 08 Dec 2014 09:12: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 1XxuN0-0003hF-Do
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 09:12:42 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	2D/0B-02702-98B65845; Mon, 08 Dec 2014 09:12:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418029960!13622182!1
X-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 31675 invoked from network); 8 Dec 2014 09:12:41 -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; 8 Dec 2014 09:12:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 09:12:40 +0000
Message-Id: <54857995020000780004DA2D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 09:12:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part47729B95.2__="
Cc: Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach handle_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part47729B95.2__=
Content-Type: text/plain; charset=UTF-8
Content-Length: 858
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

PVH guests accessing I/O ports via string ops is not supported yet.

Reported-by: Roger Pau Monn=C3=A9<roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: handle_pio() is already safe (pointed out by Mukesh), so only refuse
    entering handle_mmio().
Note: Only compile tested so far.

--- unstable.orig/xen/arch/x86/hvm/vmx/vmx.c	2014-11-27 09:37:27.000000000 +0100
+++ unstable/xen/arch/x86/hvm/vmx/vmx.c	2014-12-08 10:04:27.000000000 +0100
@@ -3086,7 +3086,8 @@ void vmx_vmexit_handler(struct cpu_user_
         if ( exit_qualification & 0x10 )
         {
             /* INS, OUTS */
-            if ( !handle_mmio() )
+            if ( unlikely(is_pvh_vcpu(v)) /* PVH fixme */ ||
+                 !handle_mmio() )
                 hvm_inject_hw_exception(TRAP_gp_fault, 0);
         }
         else



--=__Part47729B95.2__=
Content-Type: text/plain; name="VMX-PVH-no-emulated-IO-string-ops.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="VMX-PVH-no-emulated-IO-string-ops.patch"

PVH guests accessing I/O ports via string ops is not supported yet.=0A=0ARe=
ported-by: Roger Pau Monn=C3=A9<roger.pau@citrix.com>=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A---=0Av2: handle_pio() is already safe =
(pointed out by Mukesh), so only refuse=0A    entering handle_mmio().=0ANot=
e: Only compile tested so far.=0A=0A--- unstable.orig/xen/arch/x86/hvm/vmx/=
vmx.c	2014-11-27 09:37:27.000000000 +0100=0A+++ unstable/xen/arch/x86/hvm=
/vmx/vmx.c	2014-12-08 10:04:27.000000000 +0100=0A@@ -3086,7 +3086,8 =
@@ void vmx_vmexit_handler(struct cpu_user_=0A         if ( exit_qualificat=
ion & 0x10 )=0A         {=0A             /* INS, OUTS */=0A-            if =
( !handle_mmio() )=0A+            if ( unlikely(is_pvh_vcpu(v)) /* PVH =
fixme */ ||=0A+                 !handle_mmio() )=0A                 =
hvm_inject_hw_exception(TRAP_gp_fault, 0);=0A         }=0A         else=0A
--=__Part47729B95.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

--=__Part47729B95.2__=--


From xen-devel-bounces@lists.xen.org Mon Dec 08 09:19:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09:19:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxuT9-0003sy-9p; Mon, 08 Dec 2014 09: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 1XxuT7-0003st-TO
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 09:19:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B6/2B-25276-50D65845; Mon, 08 Dec 2014 09:19:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418030340!14079828!1
X-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 25716 invoked from network); 8 Dec 2014 09:19:00 -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; 8 Dec 2014 09:19:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 09:19:00 +0000
Message-Id: <54857B11020000780004DA4E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 09:18:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
	<54809169020000780004CD03@mail.emea.novell.com>
	<548566B7.8080508@intel.com>
In-Reply-To: <548566B7.8080508@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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 08.12.14 at 09:52, <tiejun.chen@intel.com> wrote:
> On 2014/12/4 23:52, Jan Beulich wrote:
>>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>>> We need to use reserved device memory maps with multiple times, so
>>> provide just one common function should be friend.
>>
>> I'm not going to repeat earlier comments; the way this is done right
>> now it's neither a proper runtime function nor a proper init time one.
>>
> 
> Actually I tried to do this in runtime as I comments in patch head. But 
> maybe you hope I should return rdm_map directly, and nr_entries as a 
> in/out parameter, right?

As said numerous times before - either you invoke the function
once (early on) and subsequently access the retrieved data via
global variables, or each invocation returns both the count and
the array (which, if any, of them via return value and which via
indirection is secondary).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 09:19:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09:19:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxuT9-0003sy-9p; Mon, 08 Dec 2014 09: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 1XxuT7-0003st-TO
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 09:19:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B6/2B-25276-50D65845; Mon, 08 Dec 2014 09:19:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418030340!14079828!1
X-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 25716 invoked from network); 8 Dec 2014 09:19:00 -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; 8 Dec 2014 09:19:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 09:19:00 +0000
Message-Id: <54857B11020000780004DA4E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 09:18:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-8-git-send-email-tiejun.chen@intel.com>
	<54809169020000780004CD03@mail.emea.novell.com>
	<548566B7.8080508@intel.com>
In-Reply-To: <548566B7.8080508@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 07/17] 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 08.12.14 at 09:52, <tiejun.chen@intel.com> wrote:
> On 2014/12/4 23:52, Jan Beulich wrote:
>>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>>> We need to use reserved device memory maps with multiple times, so
>>> provide just one common function should be friend.
>>
>> I'm not going to repeat earlier comments; the way this is done right
>> now it's neither a proper runtime function nor a proper init time one.
>>
> 
> Actually I tried to do this in runtime as I comments in patch head. But 
> maybe you hope I should return rdm_map directly, and nr_entries as a 
> in/out parameter, right?

As said numerous times before - either you invoke the function
once (early on) and subsequently access the retrieved data via
global variables, or each invocation returns both the count and
the array (which, if any, of them via return value and which via
indirection is secondary).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 09:28:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09: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 1XxucN-0004EU-D3; Mon, 08 Dec 2014 09:28:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bob.liu@oracle.com>) id 1XxucM-0004EP-4S
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 09:28:34 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	2D/B7-02699-14F65845; Mon, 08 Dec 2014 09:28:33 +0000
X-Env-Sender: bob.liu@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418030911!8974192!1
X-Originating-IP: [156.151.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 9539 invoked from network); 8 Dec 2014 09:28:32 -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; 8 Dec 2014 09:28: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 sB89SOVW023333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 09:28:25 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
	sB89SMGs015558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 09:28:24 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
	sB89SM3X015546; Mon, 8 Dec 2014 09:28:22 GMT
Received: from [192.168.3.8] (/218.82.189.246)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 01:28:22 -0800
Message-ID: <54856F30.7000407@oracle.com>
Date: Mon, 08 Dec 2014 17:28:16 +0800
From: Bob Liu <bob.liu@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546F1033.7030005@oracle.com> <54818221.1070804@oracle.com>
	<5481B1F6020000780004D24A@mail.emea.novell.com>
	<5484597A.507@oracle.com>
	<548570B2020000780004D99C@mail.emea.novell.com>
In-Reply-To: <548570B2020000780004D99C@mail.emea.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.campbell@citrix.com, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A good way to speed up the xl destroy time(guest
	page scrubbing)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/08/2014 04:34 PM, Jan Beulich wrote:
>>>> On 07.12.14 at 14:43, <bob.liu@oracle.com> wrote:
> 
>> On 12/05/2014 08:24 PM, Jan Beulich wrote:
>>>>>> On 05.12.14 at 11:00, <bob.liu@oracle.com> wrote:
>>>> 5. Potential workaround
>>>> 5.1 Use per-cpu list in idle_loop()
>>>> Delist a batch of pages from heap_list to a per-cpu list, then scrub the
>>>> per-cpu list and free back to heap_list.
>>>>
>>>> But Jan disagree with this solution:
>>>> "You should really drop the idea of removing pages temporarily.
>>>> All you need to do is make sure a page being allocated and getting
>>>> simultaneously scrubbed by another CPU won't get passed to the
>>>> caller until the scrubbing finished."
>>>
>>> So you don't mention any downsides to this approach. If there are
>>> any, please name them. If there aren't, what's the reason not to
>>> go this route?
>>
>> The reason was what you suggested was not very specific, I still have no
>> idea how to implement a patch which can "make sure a page being
>> allocated and getting simultaneously scrubbed by another CPU won't get
>> passed to the caller until the scrubbing finished".
> 
> The scrubbing code would need to mark the page, and the allocation
> code would need to spin on such marked pages until the mark clears.
> 

Thanks a lot, it's more clear!
Then do you think it is safe to iterate the heap list without spin lock
in the scrubbing code?

Konrad also suggested a similar way which was skip marked pages(instead
of spin) in the allocator, but I always got panic during
page_list_for_each(&heap_list) in the scrubbing code if without locking
the heap list.
The panic happend in page_list_next(), I think that's because alloc/free
path modified the heap list.

-- 
Regards,
-Bob

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 09:28:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09: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 1XxucN-0004EU-D3; Mon, 08 Dec 2014 09:28:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bob.liu@oracle.com>) id 1XxucM-0004EP-4S
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 09:28:34 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	2D/B7-02699-14F65845; Mon, 08 Dec 2014 09:28:33 +0000
X-Env-Sender: bob.liu@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418030911!8974192!1
X-Originating-IP: [156.151.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 9539 invoked from network); 8 Dec 2014 09:28:32 -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; 8 Dec 2014 09:28: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 sB89SOVW023333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 09:28:25 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
	sB89SMGs015558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 09:28:24 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
	sB89SM3X015546; Mon, 8 Dec 2014 09:28:22 GMT
Received: from [192.168.3.8] (/218.82.189.246)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 01:28:22 -0800
Message-ID: <54856F30.7000407@oracle.com>
Date: Mon, 08 Dec 2014 17:28:16 +0800
From: Bob Liu <bob.liu@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <546F1033.7030005@oracle.com> <54818221.1070804@oracle.com>
	<5481B1F6020000780004D24A@mail.emea.novell.com>
	<5484597A.507@oracle.com>
	<548570B2020000780004D99C@mail.emea.novell.com>
In-Reply-To: <548570B2020000780004D99C@mail.emea.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.campbell@citrix.com, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A good way to speed up the xl destroy time(guest
	page scrubbing)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/08/2014 04:34 PM, Jan Beulich wrote:
>>>> On 07.12.14 at 14:43, <bob.liu@oracle.com> wrote:
> 
>> On 12/05/2014 08:24 PM, Jan Beulich wrote:
>>>>>> On 05.12.14 at 11:00, <bob.liu@oracle.com> wrote:
>>>> 5. Potential workaround
>>>> 5.1 Use per-cpu list in idle_loop()
>>>> Delist a batch of pages from heap_list to a per-cpu list, then scrub the
>>>> per-cpu list and free back to heap_list.
>>>>
>>>> But Jan disagree with this solution:
>>>> "You should really drop the idea of removing pages temporarily.
>>>> All you need to do is make sure a page being allocated and getting
>>>> simultaneously scrubbed by another CPU won't get passed to the
>>>> caller until the scrubbing finished."
>>>
>>> So you don't mention any downsides to this approach. If there are
>>> any, please name them. If there aren't, what's the reason not to
>>> go this route?
>>
>> The reason was what you suggested was not very specific, I still have no
>> idea how to implement a patch which can "make sure a page being
>> allocated and getting simultaneously scrubbed by another CPU won't get
>> passed to the caller until the scrubbing finished".
> 
> The scrubbing code would need to mark the page, and the allocation
> code would need to spin on such marked pages until the mark clears.
> 

Thanks a lot, it's more clear!
Then do you think it is safe to iterate the heap list without spin lock
in the scrubbing code?

Konrad also suggested a similar way which was skip marked pages(instead
of spin) in the allocator, but I always got panic during
page_list_for_each(&heap_list) in the scrubbing code if without locking
the heap list.
The panic happend in page_list_next(), I think that's because alloc/free
path modified the heap list.

-- 
Regards,
-Bob

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 09:31:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxuf1-0004L1-VW; Mon, 08 Dec 2014 09:31:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xxuf0-0004Kt-Cb
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 09:31:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2F/62-09842-5EF65845; Mon, 08 Dec 2014 09:31:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418031077!14057007!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13427 invoked from network); 8 Dec 2014 09:31:17 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 09:31:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418031077; l=344;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=Tu6y4Niaz1gficXxy4UwT248bYU=;
	b=tO7ayNq8yLFtwSIBX+V7PvivzkkG1nAVLAY5pDwUKoqra5X860PJvI52LWFtCeR2x8D
	X/C6v7oR8HNbccUDnuKRGtQ5/yIb88ZZVpRpSW8EeANygLRAbiDoGGAbrlGWvehJCQ9E3
	8j1wgNfclHgmtsabFECzxpZp4Eibg9R096I=
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.3 AUTH) with ESMTPSA id f07bc8qB89VC0S0
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 10:31:12 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 3452E5015F; Mon,  8 Dec 2014 10:31:12 +0100 (CET)
Date: Mon, 8 Dec 2014 10:31:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141208093111.GA30291@aepfle.de>
References: <20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
	<20141204074756.GA4505@aepfle.de>
	<20141205021508.GB19424@andromeda.dapyr.net>
	<20141205074733.GA29524@aepfle.de>
	<20141205080307.GA31016@aepfle.de> <20141205082844.GA643@aepfle.de>
	<20141205161517.GE472@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205161517.GE472@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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.xen.org,
	M A Young <m.a.young@durham.ac.uk>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Konrad Rzeszutek Wilk wrote:

> OK. That might be complicated in that the context could change between
> bootup and run-time (I think that is what Michael told me).

The proper place to handle mount options is /etc/fstab. My version of
systemd is kind enough to use the values frm fstab for a given mount
point.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 09:31:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxuf1-0004L1-VW; Mon, 08 Dec 2014 09:31:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xxuf0-0004Kt-Cb
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 09:31:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2F/62-09842-5EF65845; Mon, 08 Dec 2014 09:31:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418031077!14057007!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13427 invoked from network); 8 Dec 2014 09:31:17 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 09:31:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418031077; l=344;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=Tu6y4Niaz1gficXxy4UwT248bYU=;
	b=tO7ayNq8yLFtwSIBX+V7PvivzkkG1nAVLAY5pDwUKoqra5X860PJvI52LWFtCeR2x8D
	X/C6v7oR8HNbccUDnuKRGtQ5/yIb88ZZVpRpSW8EeANygLRAbiDoGGAbrlGWvehJCQ9E3
	8j1wgNfclHgmtsabFECzxpZp4Eibg9R096I=
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.3 AUTH) with ESMTPSA id f07bc8qB89VC0S0
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 10:31:12 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 3452E5015F; Mon,  8 Dec 2014 10:31:12 +0100 (CET)
Date: Mon, 8 Dec 2014 10:31:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141208093111.GA30291@aepfle.de>
References: <20141202184240.GI32385@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412021846570.2643@procyon.dur.ac.uk>
	<20141203165410.GA2819@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412032105270.16535@procyon.dur.ac.uk>
	<20141204074756.GA4505@aepfle.de>
	<20141205021508.GB19424@andromeda.dapyr.net>
	<20141205074733.GA29524@aepfle.de>
	<20141205080307.GA31016@aepfle.de> <20141205082844.GA643@aepfle.de>
	<20141205161517.GE472@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205161517.GE472@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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.xen.org,
	M A Young <m.a.young@durham.ac.uk>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: update systemd dependency to
 use service instead of socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Konrad Rzeszutek Wilk wrote:

> OK. That might be complicated in that the context could change between
> bootup and run-time (I think that is what Michael told me).

The proper place to handle mount options is /etc/fstab. My version of
systemd is kind enough to use the values frm fstab for a given mount
point.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 09:37:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09:37:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxukP-0004kc-5P; Mon, 08 Dec 2014 09:36:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XxukO-0004kX-3f
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 09:36:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D5/9C-25276-33175845; Mon, 08 Dec 2014 09:36:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418031410!13743745!1
X-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 4835 invoked from network); 8 Dec 2014 09:36:50 -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; 8 Dec 2014 09:36:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 09:36:50 +0000
Message-Id: <54857F3D020000780004DA92@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 09:36:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Bob Liu" <bob.liu@oracle.com>
References: <546F1033.7030005@oracle.com> <54818221.1070804@oracle.com>
	<5481B1F6020000780004D24A@mail.emea.novell.com>
	<5484597A.507@oracle.com>
	<548570B2020000780004D99C@mail.emea.novell.com>
	<54856F30.7000407@oracle.com>
In-Reply-To: <54856F30.7000407@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.campbell@citrix.com, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A good way to speed up the xl destroy time(guest
 page scrubbing)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 10:28, <bob.liu@oracle.com> wrote:

> On 12/08/2014 04:34 PM, Jan Beulich wrote:
>>>>> On 07.12.14 at 14:43, <bob.liu@oracle.com> wrote:
>> 
>>> On 12/05/2014 08:24 PM, Jan Beulich wrote:
>>>>>>> On 05.12.14 at 11:00, <bob.liu@oracle.com> wrote:
>>>>> 5. Potential workaround
>>>>> 5.1 Use per-cpu list in idle_loop()
>>>>> Delist a batch of pages from heap_list to a per-cpu list, then scrub the
>>>>> per-cpu list and free back to heap_list.
>>>>>
>>>>> But Jan disagree with this solution:
>>>>> "You should really drop the idea of removing pages temporarily.
>>>>> All you need to do is make sure a page being allocated and getting
>>>>> simultaneously scrubbed by another CPU won't get passed to the
>>>>> caller until the scrubbing finished."
>>>>
>>>> So you don't mention any downsides to this approach. If there are
>>>> any, please name them. If there aren't, what's the reason not to
>>>> go this route?
>>>
>>> The reason was what you suggested was not very specific, I still have no
>>> idea how to implement a patch which can "make sure a page being
>>> allocated and getting simultaneously scrubbed by another CPU won't get
>>> passed to the caller until the scrubbing finished".
>> 
>> The scrubbing code would need to mark the page, and the allocation
>> code would need to spin on such marked pages until the mark clears.
>> 
> 
> Thanks a lot, it's more clear!
> Then do you think it is safe to iterate the heap list without spin lock
> in the scrubbing code?
> 
> Konrad also suggested a similar way which was skip marked pages(instead
> of spin) in the allocator, but I always got panic during
> page_list_for_each(&heap_list) in the scrubbing code if without locking
> the heap list.
> The panic happend in page_list_next(), I think that's because alloc/free
> path modified the heap list.

And which already answers your question above: No, it's not safe.
Switching to a read/write wouldn't necessarily either, so this won't
work without some other helper constructs.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 09:37:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09:37:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxukP-0004kc-5P; Mon, 08 Dec 2014 09:36:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XxukO-0004kX-3f
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 09:36:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D5/9C-25276-33175845; Mon, 08 Dec 2014 09:36:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418031410!13743745!1
X-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 4835 invoked from network); 8 Dec 2014 09:36:50 -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; 8 Dec 2014 09:36:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 09:36:50 +0000
Message-Id: <54857F3D020000780004DA92@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 09:36:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Bob Liu" <bob.liu@oracle.com>
References: <546F1033.7030005@oracle.com> <54818221.1070804@oracle.com>
	<5481B1F6020000780004D24A@mail.emea.novell.com>
	<5484597A.507@oracle.com>
	<548570B2020000780004D99C@mail.emea.novell.com>
	<54856F30.7000407@oracle.com>
In-Reply-To: <54856F30.7000407@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.campbell@citrix.com, xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] A good way to speed up the xl destroy time(guest
 page scrubbing)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 10:28, <bob.liu@oracle.com> wrote:

> On 12/08/2014 04:34 PM, Jan Beulich wrote:
>>>>> On 07.12.14 at 14:43, <bob.liu@oracle.com> wrote:
>> 
>>> On 12/05/2014 08:24 PM, Jan Beulich wrote:
>>>>>>> On 05.12.14 at 11:00, <bob.liu@oracle.com> wrote:
>>>>> 5. Potential workaround
>>>>> 5.1 Use per-cpu list in idle_loop()
>>>>> Delist a batch of pages from heap_list to a per-cpu list, then scrub the
>>>>> per-cpu list and free back to heap_list.
>>>>>
>>>>> But Jan disagree with this solution:
>>>>> "You should really drop the idea of removing pages temporarily.
>>>>> All you need to do is make sure a page being allocated and getting
>>>>> simultaneously scrubbed by another CPU won't get passed to the
>>>>> caller until the scrubbing finished."
>>>>
>>>> So you don't mention any downsides to this approach. If there are
>>>> any, please name them. If there aren't, what's the reason not to
>>>> go this route?
>>>
>>> The reason was what you suggested was not very specific, I still have no
>>> idea how to implement a patch which can "make sure a page being
>>> allocated and getting simultaneously scrubbed by another CPU won't get
>>> passed to the caller until the scrubbing finished".
>> 
>> The scrubbing code would need to mark the page, and the allocation
>> code would need to spin on such marked pages until the mark clears.
>> 
> 
> Thanks a lot, it's more clear!
> Then do you think it is safe to iterate the heap list without spin lock
> in the scrubbing code?
> 
> Konrad also suggested a similar way which was skip marked pages(instead
> of spin) in the allocator, but I always got panic during
> page_list_for_each(&heap_list) in the scrubbing code if without locking
> the heap list.
> The panic happend in page_list_next(), I think that's because alloc/free
> path modified the heap list.

And which already answers your question above: No, it's not safe.
Switching to a read/write wouldn't necessarily either, so this won't
work without some other helper constructs.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 09:48:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09:48:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxuvN-00056X-C2; Mon, 08 Dec 2014 09:48: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 1XxuvL-00056S-Pa
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 09:48:11 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	91/4C-03145-BD375845; Mon, 08 Dec 2014 09:48:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418032089!13637283!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 7091 invoked from network); 8 Dec 2014 09:48: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;
	8 Dec 2014 09:48:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201317348"
Message-ID: <1418032087.11028.5.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, 8 Dec 2014 09:48:07 +0000
In-Reply-To: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
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] flask/policy: Example policy
 updates for migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> The example XSM policy was missing permission for dom0_t to migrate
> domains; add these permissions.
> 
> Reported-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Konrad, we should take this for 4.5, in order to have a working example
XSM policy. There's 0 risk to non-XSM systems, or systems with custom
XSM policies and clear benefits to XSM systems using the example policy.

> ---
> 
> This has been tested with xl save/restore on a PV domain, which now
> succeeds without producing AVC denials.
> 
>  tools/flask/policy/policy/modules/xen/xen.if | 11 +++++++----
>  tools/flask/policy/policy/modules/xen/xen.te |  3 +++
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> index fa69c9d..bf5e135 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -48,11 +48,13 @@ define(`create_domain_common', `
>  	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
>  			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 };
> +			getaffinity setaffinity setvcpuextstate };
> +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
> +			set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
> +			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 };
> +	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
>  	allow $1 $2:grant setup;
>  	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
>  			setparam pcilevel trackdirtyvram nested };
> @@ -80,7 +82,7 @@ define(`create_domain_build_label', `
>  define(`manage_domain', `
>  	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
>  			getaddrsize pause unpause trigger shutdown destroy
> -			setaffinity setdomainmaxmem getscheduler };
> +			setaffinity setdomainmaxmem getscheduler resume };
>      allow $1 $2:domain2 set_vnumainfo;
>  ')
>  
> @@ -88,6 +90,7 @@ define(`manage_domain', `
>  #   Allow creation of a snapshot or migration image from a domain
>  #   (inbound migration is the same as domain creation)
>  define(`migrate_domain_out', `
> +	allow $1 domxen_t:mmu map_read;
>  	allow $1 $2:hvm { gethvmc getparam irqlevel };
>  	allow $1 $2:mmu { stat pageinfo map_read };
>  	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
> diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
> index d214470..c0128aa 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.te
> +++ b/tools/flask/policy/policy/modules/xen/xen.te
> @@ -129,12 +129,14 @@ create_domain(dom0_t, domU_t)
>  manage_domain(dom0_t, domU_t)
>  domain_comms(dom0_t, domU_t)
>  domain_comms(domU_t, domU_t)
> +migrate_domain_out(dom0_t, domU_t)
>  domain_self_comms(domU_t)
>  
>  declare_domain(isolated_domU_t)
>  create_domain(dom0_t, isolated_domU_t)
>  manage_domain(dom0_t, isolated_domU_t)
>  domain_comms(dom0_t, isolated_domU_t)
> +migrate_domain_out(dom0_t, isolated_domU_t)
>  domain_self_comms(isolated_domU_t)
>  
>  # Declare a boolean that denies creation of prot_domU_t domains
> @@ -142,6 +144,7 @@ gen_bool(prot_doms_locked, false)
>  declare_domain(prot_domU_t)
>  if (!prot_doms_locked) {
>  	create_domain(dom0_t, prot_domU_t)
> +	migrate_domain_out(dom0_t, prot_domU_t)
>  }
>  domain_comms(dom0_t, prot_domU_t)
>  domain_comms(domU_t, prot_domU_t)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 09:48:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09:48:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxuvN-00056X-C2; Mon, 08 Dec 2014 09:48: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 1XxuvL-00056S-Pa
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 09:48:11 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	91/4C-03145-BD375845; Mon, 08 Dec 2014 09:48:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418032089!13637283!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 7091 invoked from network); 8 Dec 2014 09:48: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;
	8 Dec 2014 09:48:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201317348"
Message-ID: <1418032087.11028.5.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, 8 Dec 2014 09:48:07 +0000
In-Reply-To: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
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] flask/policy: Example policy
 updates for migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> The example XSM policy was missing permission for dom0_t to migrate
> domains; add these permissions.
> 
> Reported-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Konrad, we should take this for 4.5, in order to have a working example
XSM policy. There's 0 risk to non-XSM systems, or systems with custom
XSM policies and clear benefits to XSM systems using the example policy.

> ---
> 
> This has been tested with xl save/restore on a PV domain, which now
> succeeds without producing AVC denials.
> 
>  tools/flask/policy/policy/modules/xen/xen.if | 11 +++++++----
>  tools/flask/policy/policy/modules/xen/xen.te |  3 +++
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> index fa69c9d..bf5e135 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -48,11 +48,13 @@ define(`create_domain_common', `
>  	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
>  			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 };
> +			getaffinity setaffinity setvcpuextstate };
> +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
> +			set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
> +			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 };
> +	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
>  	allow $1 $2:grant setup;
>  	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
>  			setparam pcilevel trackdirtyvram nested };
> @@ -80,7 +82,7 @@ define(`create_domain_build_label', `
>  define(`manage_domain', `
>  	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
>  			getaddrsize pause unpause trigger shutdown destroy
> -			setaffinity setdomainmaxmem getscheduler };
> +			setaffinity setdomainmaxmem getscheduler resume };
>      allow $1 $2:domain2 set_vnumainfo;
>  ')
>  
> @@ -88,6 +90,7 @@ define(`manage_domain', `
>  #   Allow creation of a snapshot or migration image from a domain
>  #   (inbound migration is the same as domain creation)
>  define(`migrate_domain_out', `
> +	allow $1 domxen_t:mmu map_read;
>  	allow $1 $2:hvm { gethvmc getparam irqlevel };
>  	allow $1 $2:mmu { stat pageinfo map_read };
>  	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
> diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
> index d214470..c0128aa 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.te
> +++ b/tools/flask/policy/policy/modules/xen/xen.te
> @@ -129,12 +129,14 @@ create_domain(dom0_t, domU_t)
>  manage_domain(dom0_t, domU_t)
>  domain_comms(dom0_t, domU_t)
>  domain_comms(domU_t, domU_t)
> +migrate_domain_out(dom0_t, domU_t)
>  domain_self_comms(domU_t)
>  
>  declare_domain(isolated_domU_t)
>  create_domain(dom0_t, isolated_domU_t)
>  manage_domain(dom0_t, isolated_domU_t)
>  domain_comms(dom0_t, isolated_domU_t)
> +migrate_domain_out(dom0_t, isolated_domU_t)
>  domain_self_comms(isolated_domU_t)
>  
>  # Declare a boolean that denies creation of prot_domU_t domains
> @@ -142,6 +144,7 @@ gen_bool(prot_doms_locked, false)
>  declare_domain(prot_domU_t)
>  if (!prot_doms_locked) {
>  	create_domain(dom0_t, prot_domU_t)
> +	migrate_domain_out(dom0_t, prot_domU_t)
>  }
>  domain_comms(dom0_t, prot_domU_t)
>  domain_comms(domU_t, prot_domU_t)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 09:56:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09: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 1Xxv2k-0005Ru-9n; Mon, 08 Dec 2014 09:55: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 1Xxv2j-0005Rp-Ez
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 09:55:49 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	9F/B8-26652-4A575845; Mon, 08 Dec 2014 09:55:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418032546!4495747!1
X-Originating-IP: [66.165.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 31423 invoked from network); 8 Dec 2014 09:55:47 -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;
	8 Dec 2014 09:55:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201715756"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 04:55:45 -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 1Xxv2e-0004Yx-4X;
	Mon, 08 Dec 2014 09:55:45 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 08 Dec
	2014 09:55:44 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 8 Dec 2014 09:55:44 +0000
Message-ID: <1418032544-28645-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] Add basic PVH flights.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These are the usual PV debian flights with pvh=1 added to the
configuration file.

A job is created for each of Intel and AMD, although obviously AMD is
expected to fail at the moment.

In my testing I got:
    (XEN) Attempt to create a PVH guest on a system without necessary hardware support
because my test box happens to be AMD.

I have confirmed that the pvh=1 option is correctly present in the
guest cfg for the new pvh job, and that no pvh= is present at all in
the existing test-amd64-amd64-xl job (which is expected and desired if
no pvh runvar is present).

Beyond that I've not tested this at all I fully expect even Intel to
fail in the first instance, due to issues such as lack of necessary
kernel options etc. I suggest to take this now and iterate on any
further changes.

For a xen-unstable flight this results in these runvars:
$ ./mg-show-flight-runvars pvh| grep -- -pvh | sort
test-amd64-amd64-xl-pvh-amd               all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,hvm-amd
test-amd64-amd64-xl-pvh-amd               arch                        amd64
test-amd64-amd64-xl-pvh-amd               buildjob                    build-amd64
test-amd64-amd64-xl-pvh-amd               debian_arch                 amd64
test-amd64-amd64-xl-pvh-amd               debian_kernkind             pvops
test-amd64-amd64-xl-pvh-amd               debian_pvh                  1
test-amd64-amd64-xl-pvh-amd               kernbuildjob                build-amd64-pvops
test-amd64-amd64-xl-pvh-amd               kernkind                    pvops
test-amd64-amd64-xl-pvh-amd               toolstack                   xl
test-amd64-amd64-xl-pvh-amd               xenbuildjob                 build-amd64
test-amd64-amd64-xl-pvh-intel             all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,hvm-intel
test-amd64-amd64-xl-pvh-intel             arch                        amd64
test-amd64-amd64-xl-pvh-intel             buildjob                    build-amd64
test-amd64-amd64-xl-pvh-intel             debian_arch                 amd64
test-amd64-amd64-xl-pvh-intel             debian_kernkind             pvops
test-amd64-amd64-xl-pvh-intel             debian_pvh                  1
test-amd64-amd64-xl-pvh-intel             kernbuildjob                build-amd64-pvops
test-amd64-amd64-xl-pvh-intel             kernkind                    pvops
test-amd64-amd64-xl-pvh-intel             toolstack                   xl
test-amd64-amd64-xl-pvh-intel             xenbuildjob                 build-amd64

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 make-flight     | 23 +++++++++++++++++++++++
 ts-debian-fixup |  6 ++++++
 2 files changed, 29 insertions(+)

diff --git a/make-flight b/make-flight
index 9963a46..a91f256 100755
--- a/make-flight
+++ b/make-flight
@@ -309,6 +309,17 @@ test_matrix_do_one () {
   *)               test_xend=n ;;
   esac
 
+  # PVH tests for versions >= 4.5 only
+  case "$xenbranch" in
+  xen-3.*-testing) test_pvh=n ;;
+  xen-4.0-testing) test_pvh=n ;;
+  xen-4.1-testing) test_pvh=n ;;
+  xen-4.2-testing) test_pvh=n ;;
+  xen-4.3-testing) test_pvh=n ;;
+  xen-4.4-testing) test_pvh=n ;;
+  *)               test_pvh=y ;;
+  esac
+
   do_rumpkernel_tests
 
   # xend PV guest test on x86 only
@@ -364,6 +375,18 @@ test_matrix_do_one () {
 
   fi
 
+  if [ x$test_pvh = xy -a $xenarch = amd64 -a $dom0arch = amd64 ]; then
+
+    for cpuvendor in amd intel; do
+
+      job_create_test test-$xenarch$kern-$dom0arch-xl-pvh-$cpuvendor \
+                test-debian xl $xenarch $dom0arch \
+                debian_pvh=1 $debian_runvars \
+                all_hostflags=$most_hostflags,hvm-$cpuvendor
+
+    done
+
+  fi
   do_passthrough_tests
 }
 
diff --git a/ts-debian-fixup b/ts-debian-fixup
index f001418..00477c5 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -118,6 +118,12 @@ sub otherfixupcfg () {
     $cfg =~ s/^vcpus.*//mg;
     $cfg .= "\nvcpus = $vcpus\n";
 
+    my $pvh = guest_var($gho,'pvh',undef);
+    if ($pvh) {
+	$cfg =~ s/^pvh.*//mg;
+	$cfg .= "\npvh=$pvh\n";
+    }
+
     # PCI passthrough
     # Look for runvars   <gn>_pcipassthrough_<devtype>=<hostident>
     # and pass through all matching devices from the specified host.
-- 
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 Mon Dec 08 09:56:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 09: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 1Xxv2k-0005Ru-9n; Mon, 08 Dec 2014 09:55: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 1Xxv2j-0005Rp-Ez
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 09:55:49 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	9F/B8-26652-4A575845; Mon, 08 Dec 2014 09:55:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418032546!4495747!1
X-Originating-IP: [66.165.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 31423 invoked from network); 8 Dec 2014 09:55:47 -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;
	8 Dec 2014 09:55:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201715756"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 04:55:45 -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 1Xxv2e-0004Yx-4X;
	Mon, 08 Dec 2014 09:55:45 +0000
Received: by zakaz.uk.xensource.com (sSMTP sendmail emulation); Mon, 08 Dec
	2014 09:55:44 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 8 Dec 2014 09:55:44 +0000
Message-ID: <1418032544-28645-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] Add basic PVH flights.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These are the usual PV debian flights with pvh=1 added to the
configuration file.

A job is created for each of Intel and AMD, although obviously AMD is
expected to fail at the moment.

In my testing I got:
    (XEN) Attempt to create a PVH guest on a system without necessary hardware support
because my test box happens to be AMD.

I have confirmed that the pvh=1 option is correctly present in the
guest cfg for the new pvh job, and that no pvh= is present at all in
the existing test-amd64-amd64-xl job (which is expected and desired if
no pvh runvar is present).

Beyond that I've not tested this at all I fully expect even Intel to
fail in the first instance, due to issues such as lack of necessary
kernel options etc. I suggest to take this now and iterate on any
further changes.

For a xen-unstable flight this results in these runvars:
$ ./mg-show-flight-runvars pvh| grep -- -pvh | sort
test-amd64-amd64-xl-pvh-amd               all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,hvm-amd
test-amd64-amd64-xl-pvh-amd               arch                        amd64
test-amd64-amd64-xl-pvh-amd               buildjob                    build-amd64
test-amd64-amd64-xl-pvh-amd               debian_arch                 amd64
test-amd64-amd64-xl-pvh-amd               debian_kernkind             pvops
test-amd64-amd64-xl-pvh-amd               debian_pvh                  1
test-amd64-amd64-xl-pvh-amd               kernbuildjob                build-amd64-pvops
test-amd64-amd64-xl-pvh-amd               kernkind                    pvops
test-amd64-amd64-xl-pvh-amd               toolstack                   xl
test-amd64-amd64-xl-pvh-amd               xenbuildjob                 build-amd64
test-amd64-amd64-xl-pvh-intel             all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,hvm-intel
test-amd64-amd64-xl-pvh-intel             arch                        amd64
test-amd64-amd64-xl-pvh-intel             buildjob                    build-amd64
test-amd64-amd64-xl-pvh-intel             debian_arch                 amd64
test-amd64-amd64-xl-pvh-intel             debian_kernkind             pvops
test-amd64-amd64-xl-pvh-intel             debian_pvh                  1
test-amd64-amd64-xl-pvh-intel             kernbuildjob                build-amd64-pvops
test-amd64-amd64-xl-pvh-intel             kernkind                    pvops
test-amd64-amd64-xl-pvh-intel             toolstack                   xl
test-amd64-amd64-xl-pvh-intel             xenbuildjob                 build-amd64

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 make-flight     | 23 +++++++++++++++++++++++
 ts-debian-fixup |  6 ++++++
 2 files changed, 29 insertions(+)

diff --git a/make-flight b/make-flight
index 9963a46..a91f256 100755
--- a/make-flight
+++ b/make-flight
@@ -309,6 +309,17 @@ test_matrix_do_one () {
   *)               test_xend=n ;;
   esac
 
+  # PVH tests for versions >= 4.5 only
+  case "$xenbranch" in
+  xen-3.*-testing) test_pvh=n ;;
+  xen-4.0-testing) test_pvh=n ;;
+  xen-4.1-testing) test_pvh=n ;;
+  xen-4.2-testing) test_pvh=n ;;
+  xen-4.3-testing) test_pvh=n ;;
+  xen-4.4-testing) test_pvh=n ;;
+  *)               test_pvh=y ;;
+  esac
+
   do_rumpkernel_tests
 
   # xend PV guest test on x86 only
@@ -364,6 +375,18 @@ test_matrix_do_one () {
 
   fi
 
+  if [ x$test_pvh = xy -a $xenarch = amd64 -a $dom0arch = amd64 ]; then
+
+    for cpuvendor in amd intel; do
+
+      job_create_test test-$xenarch$kern-$dom0arch-xl-pvh-$cpuvendor \
+                test-debian xl $xenarch $dom0arch \
+                debian_pvh=1 $debian_runvars \
+                all_hostflags=$most_hostflags,hvm-$cpuvendor
+
+    done
+
+  fi
   do_passthrough_tests
 }
 
diff --git a/ts-debian-fixup b/ts-debian-fixup
index f001418..00477c5 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -118,6 +118,12 @@ sub otherfixupcfg () {
     $cfg =~ s/^vcpus.*//mg;
     $cfg .= "\nvcpus = $vcpus\n";
 
+    my $pvh = guest_var($gho,'pvh',undef);
+    if ($pvh) {
+	$cfg =~ s/^pvh.*//mg;
+	$cfg .= "\npvh=$pvh\n";
+    }
+
     # PCI passthrough
     # Look for runvars   <gn>_pcipassthrough_<devtype>=<hostident>
     # and pass through all matching devices from the specified host.
-- 
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 Mon Dec 08 10:00:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxv7J-0005dx-0Y; Mon, 08 Dec 2014 10:00: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 1Xxv7H-0005ds-KZ
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:00:31 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	EF/F8-17735-EB675845; Mon, 08 Dec 2014 10:00:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418032830!11772561!1
X-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 28596 invoked from network); 8 Dec 2014 10:00:30 -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; 8 Dec 2014 10:00:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 10:00:29 +0000
Message-Id: <548584C9020000780004DAB2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 10:00:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>,<dgdegra@tycho.nsa.gov>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
	<20141202194709.GD357@laptop.dumpdata.com> <5485427C.1070903@intel.com>
In-Reply-To: <5485427C.1070903@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 03/17] introduce
 XENMEM_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 07:17, <tiejun.chen@intel.com> wrote:
> On 2014/12/3 3:47, Konrad Rzeszutek Wilk wrote:
>> On Mon, Dec 01, 2014 at 05:24:21PM +0800, Tiejun Chen wrote:
>>> @@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>           break;
>>>       }
>>>
>>> +#ifdef HAS_PASSTHROUGH
>>> +    case XENMEM_reserved_device_memory_map:
>>> +    {
>>> +        struct get_reserved_device_memory grdm;
>>> +
>>> +        if ( copy_from_guest(&grdm.map, arg, 1) ||
>>> +             !guest_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
>>> +            return -EFAULT;
>>> +
>>
>> Shouldn't there be an XSM check here?
> 
> I'm not sure, and Jan should be the author for this patch, so Jan can 
> give you a correct reply.

Hmm, not sure: Daniel, does an operation like this need an XSM
check? It's not clear whether the absence of such a check in e.g.
the handling of XENMEM_memory_map, XENMEM_machphys_mapping,
or XENMEM_maximum_ram_page is intentional (and can be used as
justification for it to be absent here too - after all the operation is for
a domain to find out information about only itself).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:00:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxv7J-0005dx-0Y; Mon, 08 Dec 2014 10:00: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 1Xxv7H-0005ds-KZ
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:00:31 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	EF/F8-17735-EB675845; Mon, 08 Dec 2014 10:00:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418032830!11772561!1
X-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 28596 invoked from network); 8 Dec 2014 10:00:30 -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; 8 Dec 2014 10:00:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 10:00:29 +0000
Message-Id: <548584C9020000780004DAB2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 10:00:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>,<dgdegra@tycho.nsa.gov>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
	<20141202194709.GD357@laptop.dumpdata.com> <5485427C.1070903@intel.com>
In-Reply-To: <5485427C.1070903@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 03/17] introduce
 XENMEM_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 07:17, <tiejun.chen@intel.com> wrote:
> On 2014/12/3 3:47, Konrad Rzeszutek Wilk wrote:
>> On Mon, Dec 01, 2014 at 05:24:21PM +0800, Tiejun Chen wrote:
>>> @@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>           break;
>>>       }
>>>
>>> +#ifdef HAS_PASSTHROUGH
>>> +    case XENMEM_reserved_device_memory_map:
>>> +    {
>>> +        struct get_reserved_device_memory grdm;
>>> +
>>> +        if ( copy_from_guest(&grdm.map, arg, 1) ||
>>> +             !guest_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
>>> +            return -EFAULT;
>>> +
>>
>> Shouldn't there be an XSM check here?
> 
> I'm not sure, and Jan should be the author for this patch, so Jan can 
> give you a correct reply.

Hmm, not sure: Daniel, does an operation like this need an XSM
check? It's not clear whether the absence of such a check in e.g.
the handling of XENMEM_memory_map, XENMEM_machphys_mapping,
or XENMEM_maximum_ram_page is intentional (and can be used as
justification for it to be absent here too - after all the operation is for
a domain to find out information about only itself).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:08:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxvEv-000608-03; Mon, 08 Dec 2014 10: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.Campbell@citrix.com>) id 1XxvEt-000603-5Q
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:08:23 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	67/A3-14727-69875845; Mon, 08 Dec 2014 10:08:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418033300!12084881!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 31205 invoked from network); 8 Dec 2014 10:08:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 10:08:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201720500"
Message-ID: <1418033298.11028.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Mon, 8 Dec 2014 10:08:18 +0000
In-Reply-To: <20141207175405.GO3141@type.youpi.perso.aquilenet.fr>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <20141205182208.GC19077@dezo.moloch.sk>
	<20141207175405.GO3141@type.youpi.perso.aquilenet.fr>
Organization: Citrix Systems, Inc.
Content-Length:1160
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy <anil@recoil.org>,
	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
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCAyMDE0LTEyLTA3IGF0IDE4OjU0ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gSGVsbG8sCj4gCj4gTWFydGluIEx1Y2luYSwgbGUgRnJpIDA1IERlYyAyMDE0IDE5OjIyOjA4
ICswMTAwLCBhIMOpY3JpdCA6Cj4gPiBXaGF0J3MgdXAgd2l0aCB0aGUgLURIQVZFX0xJQkMgY29k
ZXBhdGhzIGluIG1pbmktb3M/IFdobyBvciB3aGF0IHVzZXMKPiA+IHRoZXNlPyBHcmVwcGluZyBh
cm91bmQgaW4gc3R1YmRvbS8gZG9lc24ndCBjb21lIHVwIHdpdGggYW55dGhpbmcuLi4KPiAKPiBI
QVZFX0xJQkMgZ2V0cyBkZWZpbmVkIGJ5IGV4dHJhL21pbmktb3MvQ29uZmlnLm1rIHdoZW4gbGli
YyBpcyB5LCBhbmQKPiBsaWJjIGlzIGRlZmluZWQgdG8gJChzdHViZG9tKSwgd2hpY2ggaXMgc2V0
IHRvIHkgZnJvbSBzdHViZG9tL01ha2VmaWxlCj4gCj4gQmFzaWNhbGx5IGV2ZXJ5dGhpbmcgaW4g
c3R1YmRvbS8gdXNlcyBIQVZFX0xJQkMuCj4gCj4gSSBkb24ndCBrbm93IHdoZXJlIHRoZSBxZW11
LXN0dWJkb20gcGFydCBpcyBjdXJyZW50bHkgc3RvcmVkLCBidXQgaXQKPiB1c2VzIGl0IHRvby4K
CkkgdGhpbmsgaXRzIGluIHRoZSByZWd1bGFyIHFlbXUteGVuLXRyYWRpdGlvbmFsIGdpdCB0cmVl
IGFrYQpnaXQ6Ly94ZW5iaXRzLnhlbi5vcmcvcWVtdS14ZW4tdW5zdGFibGUuZ2l0LgoKVGhlcmUn
cyBpc24ndCBhbnkgc3R1YiBxZW11LXhlbi11cHN0cmVhbSB5ZXQuCgpJYW4uCgoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:08:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxvEv-000608-03; Mon, 08 Dec 2014 10: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.Campbell@citrix.com>) id 1XxvEt-000603-5Q
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:08:23 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	67/A3-14727-69875845; Mon, 08 Dec 2014 10:08:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418033300!12084881!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 31205 invoked from network); 8 Dec 2014 10:08:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 10:08:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201720500"
Message-ID: <1418033298.11028.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Mon, 8 Dec 2014 10:08:18 +0000
In-Reply-To: <20141207175405.GO3141@type.youpi.perso.aquilenet.fr>
References: <20141204142757.GD11192@dezo.moloch.sk>
	<54807253.5000603@citrix.com> <20141205182208.GC19077@dezo.moloch.sk>
	<20141207175405.GO3141@type.youpi.perso.aquilenet.fr>
Organization: Citrix Systems, Inc.
Content-Length:1160
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy <anil@recoil.org>,
	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
Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCAyMDE0LTEyLTA3IGF0IDE4OjU0ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gSGVsbG8sCj4gCj4gTWFydGluIEx1Y2luYSwgbGUgRnJpIDA1IERlYyAyMDE0IDE5OjIyOjA4
ICswMTAwLCBhIMOpY3JpdCA6Cj4gPiBXaGF0J3MgdXAgd2l0aCB0aGUgLURIQVZFX0xJQkMgY29k
ZXBhdGhzIGluIG1pbmktb3M/IFdobyBvciB3aGF0IHVzZXMKPiA+IHRoZXNlPyBHcmVwcGluZyBh
cm91bmQgaW4gc3R1YmRvbS8gZG9lc24ndCBjb21lIHVwIHdpdGggYW55dGhpbmcuLi4KPiAKPiBI
QVZFX0xJQkMgZ2V0cyBkZWZpbmVkIGJ5IGV4dHJhL21pbmktb3MvQ29uZmlnLm1rIHdoZW4gbGli
YyBpcyB5LCBhbmQKPiBsaWJjIGlzIGRlZmluZWQgdG8gJChzdHViZG9tKSwgd2hpY2ggaXMgc2V0
IHRvIHkgZnJvbSBzdHViZG9tL01ha2VmaWxlCj4gCj4gQmFzaWNhbGx5IGV2ZXJ5dGhpbmcgaW4g
c3R1YmRvbS8gdXNlcyBIQVZFX0xJQkMuCj4gCj4gSSBkb24ndCBrbm93IHdoZXJlIHRoZSBxZW11
LXN0dWJkb20gcGFydCBpcyBjdXJyZW50bHkgc3RvcmVkLCBidXQgaXQKPiB1c2VzIGl0IHRvby4K
CkkgdGhpbmsgaXRzIGluIHRoZSByZWd1bGFyIHFlbXUteGVuLXRyYWRpdGlvbmFsIGdpdCB0cmVl
IGFrYQpnaXQ6Ly94ZW5iaXRzLnhlbi5vcmcvcWVtdS14ZW4tdW5zdGFibGUuZ2l0LgoKVGhlcmUn
cyBpc24ndCBhbnkgc3R1YiBxZW11LXhlbi11cHN0cmVhbSB5ZXQuCgpJYW4uCgoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:13:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1XxvJW-0006LF-Mn; Mon, 08 Dec 2014 10:13: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 1XxvJV-0006LA-Cv
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:13:09 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	38/5E-29352-4B975845; Mon, 08 Dec 2014 10:13:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418033585!12083051!1
X-Originating-IP: [66.165.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 18299 invoked from network); 8 Dec 2014 10:13:06 -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;
	8 Dec 2014 10:13:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201326807"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 05:13: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 1XxvJQ-000573-6t;
	Mon, 08 Dec 2014 10:13:04 +0000
Date: Mon, 8 Dec 2014 10:13:04 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141208101304.GB17128@zion.uk.xensource.com>
References: <20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 06:44:26AM +0000, Zhangleiqiang (Trump) wrote:
> > On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
> > [...]
> > > > I think that's expected, because guest RX data path still uses
> > > > grant_copy while guest TX uses grant_map to do zero-copy transmit.
> > >
> > > As far as I know, there are three main grant-related operations used in split
> > device model: grant mapping, grant transfer and grant copy.
> > > Grant transfer has not used now, and grant mapping and grant transfer both
> > involve "TLB" refresh work for hypervisor, am I right?  Or only grant transfer
> > has this overhead?
> > 
> > Transfer is not used so I can't tell. Grant unmap causes TLB flush.
> > 
> > I saw in an email the other day XenServer folks has some planned improvement
> > to avoid TLB flush in Xen to upstream in 4.6 window. I can't speak for sure it will
> > get upstreamed as I don't work on that.
> > 
> > > Does grant copy surely has more overhead than grant mapping?
> > >
> > 
> > At the very least the zero-copy TX path is faster than previous copying path.
> > 
> > But speaking of the micro operation I'm not sure.
> > 
> > There was once persistent map prototype netback / netfront that establishes a
> > memory pool between FE and BE then use memcpy to copy data. Unfortunately
> > that prototype was not done right so the result was not good.
> 
> The newest mail about persistent grant I can find is sent from 16 Nov
> 2012
> (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00832.html).
> Why is it not done right and not merged into upstream?

AFAICT there's one more memcpy than necessary, i.e. frontend memcpy data
into the pool then backend memcpy data out of the pool, when backend
should be able to use the page in pool directly.

> 
> And I also search for virtio support in XEN, and I find that the one
> who are familiar with it is you, too,
> (http://wiki.xen.org/wiki/Virtio_On_Xen), :-). I am wondering what is
> the current state for virtio on XEN?

Yes, it was me. I never have the time to revisit that. I don't think we
support virtio network at the moment.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:13:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1XxvJW-0006LF-Mn; Mon, 08 Dec 2014 10:13: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 1XxvJV-0006LA-Cv
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:13:09 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	38/5E-29352-4B975845; Mon, 08 Dec 2014 10:13:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418033585!12083051!1
X-Originating-IP: [66.165.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 18299 invoked from network); 8 Dec 2014 10:13:06 -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;
	8 Dec 2014 10:13:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201326807"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 05:13: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 1XxvJQ-000573-6t;
	Mon, 08 Dec 2014 10:13:04 +0000
Date: Mon, 8 Dec 2014 10:13:04 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141208101304.GB17128@zion.uk.xensource.com>
References: <20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 06:44:26AM +0000, Zhangleiqiang (Trump) wrote:
> > On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
> > [...]
> > > > I think that's expected, because guest RX data path still uses
> > > > grant_copy while guest TX uses grant_map to do zero-copy transmit.
> > >
> > > As far as I know, there are three main grant-related operations used in split
> > device model: grant mapping, grant transfer and grant copy.
> > > Grant transfer has not used now, and grant mapping and grant transfer both
> > involve "TLB" refresh work for hypervisor, am I right?  Or only grant transfer
> > has this overhead?
> > 
> > Transfer is not used so I can't tell. Grant unmap causes TLB flush.
> > 
> > I saw in an email the other day XenServer folks has some planned improvement
> > to avoid TLB flush in Xen to upstream in 4.6 window. I can't speak for sure it will
> > get upstreamed as I don't work on that.
> > 
> > > Does grant copy surely has more overhead than grant mapping?
> > >
> > 
> > At the very least the zero-copy TX path is faster than previous copying path.
> > 
> > But speaking of the micro operation I'm not sure.
> > 
> > There was once persistent map prototype netback / netfront that establishes a
> > memory pool between FE and BE then use memcpy to copy data. Unfortunately
> > that prototype was not done right so the result was not good.
> 
> The newest mail about persistent grant I can find is sent from 16 Nov
> 2012
> (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00832.html).
> Why is it not done right and not merged into upstream?

AFAICT there's one more memcpy than necessary, i.e. frontend memcpy data
into the pool then backend memcpy data out of the pool, when backend
should be able to use the page in pool directly.

> 
> And I also search for virtio support in XEN, and I find that the one
> who are familiar with it is you, too,
> (http://wiki.xen.org/wiki/Virtio_On_Xen), :-). I am wondering what is
> the current state for virtio on XEN?

Yes, it was me. I never have the time to revisit that. I don't think we
support virtio network at the moment.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:15:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1XxvM0-0006RU-81; Mon, 08 Dec 2014 10:15:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XxvLz-0006RN-7t
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:15:43 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	B8/88-11581-E4A75845; Mon, 08 Dec 2014 10:15:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418033740!6792394!1
X-Originating-IP: [66.165.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 22955 invoked from network); 8 Dec 2014 10:15:41 -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;
	8 Dec 2014 10:15:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201724112"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 05:15: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 1Xxv5c-0004cx-47;
	Mon, 08 Dec 2014 09:58:48 +0000
Date: Mon, 8 Dec 2014 09:58:48 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141208095847.GA16573@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.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@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: Re: [Xen-devel] [PATCH v2 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

Ping?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:15:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1XxvM0-0006RU-81; Mon, 08 Dec 2014 10:15:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XxvLz-0006RN-7t
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:15:43 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	B8/88-11581-E4A75845; Mon, 08 Dec 2014 10:15:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418033740!6792394!1
X-Originating-IP: [66.165.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 22955 invoked from network); 8 Dec 2014 10:15:41 -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;
	8 Dec 2014 10:15:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201724112"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 05:15: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 1Xxv5c-0004cx-47;
	Mon, 08 Dec 2014 09:58:48 +0000
Date: Mon, 8 Dec 2014 09:58:48 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Message-ID: <20141208095847.GA16573@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417448023-27311-1-git-send-email-wei.liu2@citrix.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@citrix.com, ian.jackson@eu.citrix.com,
	JBeulich@suse.com, boris.ostrovsky@oracle.com, ufimtseva@gmail.com
Subject: Re: [Xen-devel] [PATCH v2 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

Ping?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:18:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1XxvOL-0006bn-4q; Mon, 08 Dec 2014 10:18: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 1XxvOI-0006bc-Uo
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:18:07 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	94/D4-25547-EDA75845; Mon, 08 Dec 2014 10:18:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418033885!8029999!1
X-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 19340 invoked from network); 8 Dec 2014 10:18:05 -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; 8 Dec 2014 10:18:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 10:18:05 +0000
Message-Id: <548588E9020000780004DAF4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 10:18:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Mihai=20Don=C8=9Bu?=" <mdontu@bitdefender.com>
References: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
In-Reply-To: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 03:30, <mdontu@bitdefender.com> wrote:
> +#ifndef NDEBUG
> +static bool_t xmem_pool_check_size(const struct bhdr *b, int fl, int sl)
> +{
> +    while ( b )
> +    {
> +        int __fl;
> +        int __sl;
> +
> +        MAPPING_INSERT(b->size, &__fl, &__sl);
> +        if ( __fl != fl || __sl != sl )
> +        {
> +            printk(XENLOG_ERR "xmem_pool: for block %p size = %u, { fl = %d, sl = %d } should be { fl = %d, sl = %d }\n",

Quoting my reply to v1: "Long line. Only the format message alone
is allowed to exceed 80 characters."

Also with there potentially being multiple pools, shouldn't all of the
log messages the patch issues be extended to allow identifying the
offending one?

> +bool_t __xmem_pool_check(const char *file, int line, struct xmem_pool *pool)
> +{
> +    return __xmem_pool_check_unlocked(file, line, pool ? pool : xenpool);

For brevity, the shorter "pool ?: xenpool" is generally preferable. The
only place using this is not allowed are the public headers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:18:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1XxvOL-0006bn-4q; Mon, 08 Dec 2014 10:18: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 1XxvOI-0006bc-Uo
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:18:07 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	94/D4-25547-EDA75845; Mon, 08 Dec 2014 10:18:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418033885!8029999!1
X-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 19340 invoked from network); 8 Dec 2014 10:18:05 -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; 8 Dec 2014 10:18:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 10:18:05 +0000
Message-Id: <548588E9020000780004DAF4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 10:18:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Mihai=20Don=C8=9Bu?=" <mdontu@bitdefender.com>
References: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
In-Reply-To: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 03:30, <mdontu@bitdefender.com> wrote:
> +#ifndef NDEBUG
> +static bool_t xmem_pool_check_size(const struct bhdr *b, int fl, int sl)
> +{
> +    while ( b )
> +    {
> +        int __fl;
> +        int __sl;
> +
> +        MAPPING_INSERT(b->size, &__fl, &__sl);
> +        if ( __fl != fl || __sl != sl )
> +        {
> +            printk(XENLOG_ERR "xmem_pool: for block %p size = %u, { fl = %d, sl = %d } should be { fl = %d, sl = %d }\n",

Quoting my reply to v1: "Long line. Only the format message alone
is allowed to exceed 80 characters."

Also with there potentially being multiple pools, shouldn't all of the
log messages the patch issues be extended to allow identifying the
offending one?

> +bool_t __xmem_pool_check(const char *file, int line, struct xmem_pool *pool)
> +{
> +    return __xmem_pool_check_unlocked(file, line, pool ? pool : xenpool);

For brevity, the shorter "pool ?: xenpool" is generally preferable. The
only place using this is not allowed are the public headers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:18:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1XxvOV-0006dU-HC; Mon, 08 Dec 2014 10:18:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XxvOU-0006dI-H9
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:18:18 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	5A/D8-17694-9EA75845; Mon, 08 Dec 2014 10:18:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418033897!11778579!1
X-Originating-IP: [81.169.146.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 32501 invoked from network); 8 Dec 2014 10:18:17 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 10:18:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418033897; l=915;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=uo9jjAYrJx5/hCq7BJ2li6CG8hU=;
	b=rSupLClnwWd47SsF7b/XAkmO9cT6wU6kmF8cBuN9GWbxhUpCX6+cICl/V+eGidFxnU1
	RefC6itrV8HmoKDoXt320EweFhdIigDQGmN812HzTjhH1dq6Is8CJM+pBIB32g7vGbGF0
	YR2vlz59TtD8sZioq5n+vREONyvTKBoCz/Y=
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.3 AUTH) with ESMTPSA id K0259bqB8AIE0zM
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 11:18:14 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id BDC0050162; Mon,  8 Dec 2014 11:18:13 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Mon,  8 Dec 2014 11:18:05 +0100
Message-Id: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a resend of this series, with just the low hanging fruits:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html

The mentioned wrapper to run xenstored from systemd without duplicate
functionality found in the sysv runlevel script will be send in another patch,
once it is ready.

Olaf

Olaf Hering (4):
  tools/hotplug: remove SELinux options from var-lib-xenstored.mount
  tools/hotplug: remove XENSTORED_ROOTDIR from service file
  tools/hotplug: remove EnvironmentFile from
    xen-qemu-dom0-disk-backend.service
  tools/hotplug: use xencommons as EnvironmentFile

 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 4 +---
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
 tools/hotplug/Linux/systemd/xenconsoled.service.in                | 2 +-
 tools/hotplug/Linux/systemd/xenstored.service.in                  | 1 -
 4 files changed, 2 insertions(+), 6 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:18:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1XxvOV-0006dU-HC; Mon, 08 Dec 2014 10:18:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XxvOU-0006dI-H9
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:18:18 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	5A/D8-17694-9EA75845; Mon, 08 Dec 2014 10:18:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418033897!11778579!1
X-Originating-IP: [81.169.146.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 32501 invoked from network); 8 Dec 2014 10:18:17 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 10:18:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418033897; l=915;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=uo9jjAYrJx5/hCq7BJ2li6CG8hU=;
	b=rSupLClnwWd47SsF7b/XAkmO9cT6wU6kmF8cBuN9GWbxhUpCX6+cICl/V+eGidFxnU1
	RefC6itrV8HmoKDoXt320EweFhdIigDQGmN812HzTjhH1dq6Is8CJM+pBIB32g7vGbGF0
	YR2vlz59TtD8sZioq5n+vREONyvTKBoCz/Y=
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.3 AUTH) with ESMTPSA id K0259bqB8AIE0zM
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 11:18:14 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id BDC0050162; Mon,  8 Dec 2014 11:18:13 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Mon,  8 Dec 2014 11:18:05 +0100
Message-Id: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a resend of this series, with just the low hanging fruits:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html

The mentioned wrapper to run xenstored from systemd without duplicate
functionality found in the sysv runlevel script will be send in another patch,
once it is ready.

Olaf

Olaf Hering (4):
  tools/hotplug: remove SELinux options from var-lib-xenstored.mount
  tools/hotplug: remove XENSTORED_ROOTDIR from service file
  tools/hotplug: remove EnvironmentFile from
    xen-qemu-dom0-disk-backend.service
  tools/hotplug: use xencommons as EnvironmentFile

 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 4 +---
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
 tools/hotplug/Linux/systemd/xenconsoled.service.in                | 2 +-
 tools/hotplug/Linux/systemd/xenstored.service.in                  | 1 -
 4 files changed, 2 insertions(+), 6 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:18:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1XxvOa-0006fD-TU; Mon, 08 Dec 2014 10:18:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XxvOa-0006em-1k
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:18:24 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A8/D1-09842-FEA75845; Mon, 08 Dec 2014 10:18:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418033902!10668518!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16070 invoked from network); 8 Dec 2014 10:18:22 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.219)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 10:18:22 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418033902; l=1185;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=4n3e34QMTSOUp1r6/nL0mwXfouE=;
	b=VkQcz/nem3iVoHeTXzIn/BlmZQDOahu/597IYrRzeJRplhMtGVIHWu21330WLedF8JT
	Yoh1cQjTV45wePd0bAetzuOkelUWy0FmmoK2dNHVW6MWxHYJFT1Xhqyr3zoQV3b626iiq
	haQQUXfIAxm1eYwaOc+ThQiMxqk9zlRPAeQ=
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.3 AUTH) with ESMTPSA id z01018qB8AIJ1RW
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 11:18:19 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0DD4C5015E; Mon,  8 Dec 2014 11:18:13 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Mon,  8 Dec 2014 11:18:09 +0100
Message-Id: <1418033889-11616-5-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 4/4] tools/hotplug: use xencommons as
	EnvironmentFile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The referenced sysconfig/xenconsoled does not exist. If anything needs to be
specified it has to go into the existing sysconfig/xencommons file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenconsoled.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index cb44cd6..74d0428 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -9,7 +9,7 @@ Type=simple
 Environment=XENCONSOLED_ARGS=
 Environment=XENCONSOLED_LOG=none
 Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
+EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
 ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:18:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1XxvOa-0006fD-TU; Mon, 08 Dec 2014 10:18:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XxvOa-0006em-1k
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:18:24 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A8/D1-09842-FEA75845; Mon, 08 Dec 2014 10:18:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418033902!10668518!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16070 invoked from network); 8 Dec 2014 10:18:22 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.219)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 10:18:22 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418033902; l=1185;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=4n3e34QMTSOUp1r6/nL0mwXfouE=;
	b=VkQcz/nem3iVoHeTXzIn/BlmZQDOahu/597IYrRzeJRplhMtGVIHWu21330WLedF8JT
	Yoh1cQjTV45wePd0bAetzuOkelUWy0FmmoK2dNHVW6MWxHYJFT1Xhqyr3zoQV3b626iiq
	haQQUXfIAxm1eYwaOc+ThQiMxqk9zlRPAeQ=
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.3 AUTH) with ESMTPSA id z01018qB8AIJ1RW
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 11:18:19 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0DD4C5015E; Mon,  8 Dec 2014 11:18:13 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Mon,  8 Dec 2014 11:18:09 +0100
Message-Id: <1418033889-11616-5-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 4/4] tools/hotplug: use xencommons as
	EnvironmentFile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The referenced sysconfig/xenconsoled does not exist. If anything needs to be
specified it has to go into the existing sysconfig/xencommons file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenconsoled.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index cb44cd6..74d0428 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -9,7 +9,7 @@ Type=simple
 Environment=XENCONSOLED_ARGS=
 Environment=XENCONSOLED_LOG=none
 Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
+EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
 ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:18:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1XxvOj-0006iE-9g; Mon, 08 Dec 2014 10:18:33 +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 1XxvOh-0006hZ-Oy
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:18:31 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	EF/43-02712-7FA75845; Mon, 08 Dec 2014 10:18:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418033907!13640967!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28872 invoked from network); 8 Dec 2014 10:18: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-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 10:18:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418033907; l=2294;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=wgybMdT4SKCmFrD1eOWCglVSukg=;
	b=qP/lfPYos8KXBSRcllkqcLToSCB/PaweDyk47aIo3NZ2QwPdTHdzJq4mVIEJsiyhy1B
	ApD9MYvju4qg+ziu1EY3gL++WTP6mnCDKe9rfZqwc7+Aqtr8dFV0ZIEu9WEHulLAvN/wV
	PK1w5tCCh8vb7vjXtjNnAwyjQsSTfGxv3oU=
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.3 AUTH) with ESMTPSA id j0139aqB8AIP1MX
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 11:18:25 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 2E0905016D; Mon,  8 Dec 2014 11:18:13 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Mon,  8 Dec 2014 11:18:06 +0100
Message-Id: <1418033889-11616-2-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>,
	M A Young <m.a.young@durham.ac.uk>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Subject: [Xen-devel] [PATCH 1/4] tools/hotplug: remove SELinux options from
	var-lib-xenstored.mount
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Using SELinux mount options per default breaks several systems. Either
the context= mount option is not known at all to the kernel, or the
default value "none" is unknown to SELinux. In both cases the unit will
fail.

The proper place to specify mount options is /etc/fstab. Appearently
systemd is kind enough to use values from there even if Options= or
What= is specified in a .mount file.

Remove XENSTORED_MOUNT_CTX, the reference to a non-existant
EnvironmentFile and trim default Options= for the mount point.

The removed code was first mentioned in the patch referenced below, with
the following description:
...
 * Some systems define the selinux context in the systemd Option for the
   /var/lib/xenstored tmpfs:
       Options=mode=755,context="system_u:object_r:xenstored_var_lib_t:s0"
   For the upstream version we remove that and let systems specify the context
   on their system /etc/default/xenstored or /etc/sysconfig/xenstored
   $XENSTORED_MOUNT_CTX variable
...
It is nowhere stated (on xen-devel) what "Some systems" means, which is
unfortunately common practice in nearly all opensource projects.
http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg02462.html

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
index d5e04db..11a7d50 100644
--- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
+++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
@@ -6,9 +6,7 @@ ConditionPathExists=/proc/xen/capabilities
 RefuseManualStop=true
 
 [Mount]
-Environment=XENSTORED_MOUNT_CTX=none
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
 What=xenstore
 Where=@XEN_LIB_STORED@
 Type=tmpfs
-Options=mode=755,context="$XENSTORED_MOUNT_CTX"
+Options=mode=755

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:18:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1XxvOj-0006iE-9g; Mon, 08 Dec 2014 10:18:33 +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 1XxvOh-0006hZ-Oy
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:18:31 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	EF/43-02712-7FA75845; Mon, 08 Dec 2014 10:18:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418033907!13640967!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28872 invoked from network); 8 Dec 2014 10:18: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-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 10:18:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418033907; l=2294;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=wgybMdT4SKCmFrD1eOWCglVSukg=;
	b=qP/lfPYos8KXBSRcllkqcLToSCB/PaweDyk47aIo3NZ2QwPdTHdzJq4mVIEJsiyhy1B
	ApD9MYvju4qg+ziu1EY3gL++WTP6mnCDKe9rfZqwc7+Aqtr8dFV0ZIEu9WEHulLAvN/wV
	PK1w5tCCh8vb7vjXtjNnAwyjQsSTfGxv3oU=
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.3 AUTH) with ESMTPSA id j0139aqB8AIP1MX
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 11:18:25 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 2E0905016D; Mon,  8 Dec 2014 11:18:13 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Mon,  8 Dec 2014 11:18:06 +0100
Message-Id: <1418033889-11616-2-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>,
	M A Young <m.a.young@durham.ac.uk>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Subject: [Xen-devel] [PATCH 1/4] tools/hotplug: remove SELinux options from
	var-lib-xenstored.mount
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Using SELinux mount options per default breaks several systems. Either
the context= mount option is not known at all to the kernel, or the
default value "none" is unknown to SELinux. In both cases the unit will
fail.

The proper place to specify mount options is /etc/fstab. Appearently
systemd is kind enough to use values from there even if Options= or
What= is specified in a .mount file.

Remove XENSTORED_MOUNT_CTX, the reference to a non-existant
EnvironmentFile and trim default Options= for the mount point.

The removed code was first mentioned in the patch referenced below, with
the following description:
...
 * Some systems define the selinux context in the systemd Option for the
   /var/lib/xenstored tmpfs:
       Options=mode=755,context="system_u:object_r:xenstored_var_lib_t:s0"
   For the upstream version we remove that and let systems specify the context
   on their system /etc/default/xenstored or /etc/sysconfig/xenstored
   $XENSTORED_MOUNT_CTX variable
...
It is nowhere stated (on xen-devel) what "Some systems" means, which is
unfortunately common practice in nearly all opensource projects.
http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg02462.html

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
index d5e04db..11a7d50 100644
--- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
+++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
@@ -6,9 +6,7 @@ ConditionPathExists=/proc/xen/capabilities
 RefuseManualStop=true
 
 [Mount]
-Environment=XENSTORED_MOUNT_CTX=none
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
 What=xenstore
 Where=@XEN_LIB_STORED@
 Type=tmpfs
-Options=mode=755,context="$XENSTORED_MOUNT_CTX"
+Options=mode=755

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:18:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:18:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxvOq-0006lq-Mc; Mon, 08 Dec 2014 10:18: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 1XxvOp-0006lB-TC
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:18:40 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	FB/E5-25547-FFA75845; Mon, 08 Dec 2014 10:18:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418033918!11778703!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3567 invoked from network); 8 Dec 2014 10:18:38 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 10:18:38 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418033918; l=1068;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=rpPOfsNAHj5jM5Z75DyDA1Ncrnk=;
	b=yjH6q/p3xsKpsN6PRc46DPAFAftJ7t09lBaVGnDhzKgG4+l/BbIsRQPbsQwbU9Q3tSS
	w5/1pEB3oKrfVEsxfRoN9dhv9nzeCpQjle35pen2kEcDirp5lorozIEb7ASEUGPNfGzoo
	IpP33pzurV9inXduGOBZTDYX7y2fmOLqRKc=
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.3 AUTH) with ESMTPSA id k066b0qB8AIZ17w
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 11:18:35 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 5C35150160; Mon,  8 Dec 2014 11:18:13 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Mon,  8 Dec 2014 11:18:08 +0100
Message-Id: <1418033889-11616-4-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 3/4] tools/hotplug: remove EnvironmentFile from
	xen-qemu-dom0-disk-backend.service
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The references Environment file does not exist, and the service file
does not make use of variables anyway.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
 1 file changed, 1 deletion(-)

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 0a5807a..274cec0 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,7 +8,6 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=simple
-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@

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:18:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:18:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxvOq-0006lq-Mc; Mon, 08 Dec 2014 10:18: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 1XxvOp-0006lB-TC
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:18:40 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	FB/E5-25547-FFA75845; Mon, 08 Dec 2014 10:18:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418033918!11778703!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3567 invoked from network); 8 Dec 2014 10:18:38 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 10:18:38 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418033918; l=1068;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=rpPOfsNAHj5jM5Z75DyDA1Ncrnk=;
	b=yjH6q/p3xsKpsN6PRc46DPAFAftJ7t09lBaVGnDhzKgG4+l/BbIsRQPbsQwbU9Q3tSS
	w5/1pEB3oKrfVEsxfRoN9dhv9nzeCpQjle35pen2kEcDirp5lorozIEb7ASEUGPNfGzoo
	IpP33pzurV9inXduGOBZTDYX7y2fmOLqRKc=
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.3 AUTH) with ESMTPSA id k066b0qB8AIZ17w
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 11:18:35 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 5C35150160; Mon,  8 Dec 2014 11:18:13 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Mon,  8 Dec 2014 11:18:08 +0100
Message-Id: <1418033889-11616-4-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 3/4] tools/hotplug: remove EnvironmentFile from
	xen-qemu-dom0-disk-backend.service
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The references Environment file does not exist, and the service file
does not make use of variables anyway.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
 1 file changed, 1 deletion(-)

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 0a5807a..274cec0 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,7 +8,6 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=simple
-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@

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:18:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:18:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxvP0-0006q5-5d; Mon, 08 Dec 2014 10:18:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XxvOy-0006pO-Tf
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:18:49 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	1A/BF-02696-80B75845; Mon, 08 Dec 2014 10:18:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418033927!13639788!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22928 invoked from network); 8 Dec 2014 10:18:47 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.219)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 10:18:47 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418033927; l=1136;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=eD0Zz+5TkteXfQAzF+liiVNQTYY=;
	b=fyBpYWfUzfzTMD/A/LyljtuVfJ3mnIRBppqgI2vc9PLd/VxFe4L0Gb5xictYEho8tiz
	CnoGWDPxzq6bPU8yYe5bUv6HcVviK3Nij70EjmdEiscxBHkSaH8zoP6zq3Wnsn+xngfCr
	M39OrCz1oq2QK4xZdpNL/yqrOvdj7JlE9qo=
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.3 AUTH) with ESMTPSA id D0255bqB8AIU0r9
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 11:18:30 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 4BFD65015F; Mon,  8 Dec 2014 11:18:13 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Mon,  8 Dec 2014 11:18:07 +0100
Message-Id: <1418033889-11616-3-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 2/4] tools/hotplug: remove XENSTORED_ROOTDIR
	from service 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There is no need to export XENSTORED_ROOTDIR. This variable can be
enabled in sysconfig/xencommons. If the variable is unset xenstored
will automatically use @XEN_LIB_STORED@.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenstored.service.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 780bdd6..0f0ac58 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -9,7 +9,6 @@ ConditionPathExists=/proc/xen/capabilities
 [Service]
 Type=notify
 Environment=XENSTORED_ARGS=
-Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
 Environment=XENSTORED=@XENSTORED@
 EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:18:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:18:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxvP0-0006q5-5d; Mon, 08 Dec 2014 10:18:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XxvOy-0006pO-Tf
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:18:49 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	1A/BF-02696-80B75845; Mon, 08 Dec 2014 10:18:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418033927!13639788!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22928 invoked from network); 8 Dec 2014 10:18:47 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.219)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 10:18:47 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418033927; l=1136;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=eD0Zz+5TkteXfQAzF+liiVNQTYY=;
	b=fyBpYWfUzfzTMD/A/LyljtuVfJ3mnIRBppqgI2vc9PLd/VxFe4L0Gb5xictYEho8tiz
	CnoGWDPxzq6bPU8yYe5bUv6HcVviK3Nij70EjmdEiscxBHkSaH8zoP6zq3Wnsn+xngfCr
	M39OrCz1oq2QK4xZdpNL/yqrOvdj7JlE9qo=
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.3 AUTH) with ESMTPSA id D0255bqB8AIU0r9
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 11:18:30 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 4BFD65015F; Mon,  8 Dec 2014 11:18:13 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Mon,  8 Dec 2014 11:18:07 +0100
Message-Id: <1418033889-11616-3-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH 2/4] tools/hotplug: remove XENSTORED_ROOTDIR
	from service 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There is no need to export XENSTORED_ROOTDIR. This variable can be
enabled in sysconfig/xencommons. If the variable is unset xenstored
will automatically use @XEN_LIB_STORED@.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenstored.service.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 780bdd6..0f0ac58 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -9,7 +9,6 @@ ConditionPathExists=/proc/xen/capabilities
 [Service]
 Type=notify
 Environment=XENSTORED_ARGS=
-Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
 Environment=XENSTORED=@XENSTORED@
 EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:19:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:19:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxvPu-00078h-LJ; Mon, 08 Dec 2014 10:19:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luis.henriques@canonical.com>) id 1XxvPt-00078B-1l
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:19:45 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	01/B9-27785-04B75845; Mon, 08 Dec 2014 10:19:44 +0000
X-Env-Sender: luis.henriques@canonical.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418033983!13641436!1
X-Originating-IP: [91.189.89.112]
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 26158 invoked from network); 8 Dec 2014 10:19:43 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Dec 2014 10:19:43 -0000
Received: from bl20-128-180.dsl.telepac.pt ([2.81.128.180] helo=localhost)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <luis.henriques@canonical.com>)
	id 1XxvPl-0007NE-5B; Mon, 08 Dec 2014 10:19:37 +0000
Date: Mon, 8 Dec 2014 10:19:36 +0000
From: Luis Henriques <luis.henriques@canonical.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20141208101936.GA7491@hercules>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>
	<547C2CFC.7060908@canonical.com>
MIME-Version: 1.0
Content-Length: 3330
Content-Disposition: inline
In-Reply-To: <547C2CFC.7060908@canonical.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, Kamal Mostafa <kamal@canonical.com>,
	linux-kernel@vger.kernel.org, Paul Durrant <paul.durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Zoltan Kiss <zoltan.kiss@citrix.com>, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
> On 11.08.2014 19:32, Zoltan Kiss wrote:
> > There is a long known problem with the netfront/netback interface: if t=
he guest
> > tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 rin=
g slots,
> > it gets dropped. The reason is that netback maps these slots to a frag =
in the
> > frags array, which is limited by size. Having so many slots can occur s=
ince
> > compound pages were introduced, as the ring protocol slice them up into
> > individual (non-compound) page aligned slots. The theoretical worst case
> > scenario looks like this (note, skbs are limited to 64 Kb here):
> > linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page bound=
ary,
> > using 2 slots
> > first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are =
at the
> > end and the beginning of a page, therefore they use 3 * 15 =3D 45 slots
> > last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 slots
> > Although I don't think this 51 slots skb can really happen, we need a s=
olution
> > which can deal with every scenario. In real life there is only a few sl=
ots
> > overdue, but usually it causes the TCP stream to be blocked, as the ret=
ry will
> > most likely have the same buffer layout.
> > This patch solves this problem by linearizing the packet. This is not t=
he
> > fastest way, and it can fail much easier as it tries to allocate a big =
linear
> > area for the whole packet, but probably easier by an order of magnitude=
 than
> > anything else. Probably this code path is not touched very frequently a=
nyway.
> > =

> > Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > Cc: Ian Campbell <Ian.Campbell@citrix.com>
> > Cc: Paul Durrant <paul.durrant@citrix.com>
> > Cc: netdev@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: xen-devel@lists.xenproject.org
> =

> This does not seem to be marked explicitly as stable. Has someone already=
 asked
> David Miller to put it on his stable queue? IMO it qualifies quite well a=
nd the
> actual change should be simple to pick/backport.
> =


Thank you Stefan, I'm queuing this for the next 3.16 kernel release.

Cheers,
--
Lu=EDs

> -Stefan
> =

> > =

> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 055222b..23359ae 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -628,9 +628,10 @@ static int xennet_start_xmit(struct sk_buff *skb, =
struct net_device *dev)
> >  	slots =3D DIV_ROUND_UP(offset + len, PAGE_SIZE) +
> >  		xennet_count_skb_frag_slots(skb);
> >  	if (unlikely(slots > MAX_SKB_FRAGS + 1)) {
> > -		net_alert_ratelimited(
> > -			"xennet: skb rides the rocket: %d slots\n", slots);
> > -		goto drop;
> > +		net_dbg_ratelimited("xennet: skb rides the rocket: %d slots, %d byte=
s\n",
> > +				    slots, skb->len);
> > +		if (skb_linearize(skb))
> > +			goto drop;
> >  	}
> >  =

> >  	spin_lock_irqsave(&queue->tx_lock, flags);
> > =

> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Dec 08 10:19:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:19:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxvPu-00078h-LJ; Mon, 08 Dec 2014 10:19:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luis.henriques@canonical.com>) id 1XxvPt-00078B-1l
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:19:45 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	01/B9-27785-04B75845; Mon, 08 Dec 2014 10:19:44 +0000
X-Env-Sender: luis.henriques@canonical.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418033983!13641436!1
X-Originating-IP: [91.189.89.112]
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 26158 invoked from network); 8 Dec 2014 10:19:43 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Dec 2014 10:19:43 -0000
Received: from bl20-128-180.dsl.telepac.pt ([2.81.128.180] helo=localhost)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <luis.henriques@canonical.com>)
	id 1XxvPl-0007NE-5B; Mon, 08 Dec 2014 10:19:37 +0000
Date: Mon, 8 Dec 2014 10:19:36 +0000
From: Luis Henriques <luis.henriques@canonical.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20141208101936.GA7491@hercules>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>
	<547C2CFC.7060908@canonical.com>
MIME-Version: 1.0
Content-Length: 3330
Content-Disposition: inline
In-Reply-To: <547C2CFC.7060908@canonical.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, Kamal Mostafa <kamal@canonical.com>,
	linux-kernel@vger.kernel.org, Paul Durrant <paul.durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Zoltan Kiss <zoltan.kiss@citrix.com>, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
> On 11.08.2014 19:32, Zoltan Kiss wrote:
> > There is a long known problem with the netfront/netback interface: if t=
he guest
> > tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 rin=
g slots,
> > it gets dropped. The reason is that netback maps these slots to a frag =
in the
> > frags array, which is limited by size. Having so many slots can occur s=
ince
> > compound pages were introduced, as the ring protocol slice them up into
> > individual (non-compound) page aligned slots. The theoretical worst case
> > scenario looks like this (note, skbs are limited to 64 Kb here):
> > linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page bound=
ary,
> > using 2 slots
> > first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are =
at the
> > end and the beginning of a page, therefore they use 3 * 15 =3D 45 slots
> > last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 slots
> > Although I don't think this 51 slots skb can really happen, we need a s=
olution
> > which can deal with every scenario. In real life there is only a few sl=
ots
> > overdue, but usually it causes the TCP stream to be blocked, as the ret=
ry will
> > most likely have the same buffer layout.
> > This patch solves this problem by linearizing the packet. This is not t=
he
> > fastest way, and it can fail much easier as it tries to allocate a big =
linear
> > area for the whole packet, but probably easier by an order of magnitude=
 than
> > anything else. Probably this code path is not touched very frequently a=
nyway.
> > =

> > Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > Cc: Ian Campbell <Ian.Campbell@citrix.com>
> > Cc: Paul Durrant <paul.durrant@citrix.com>
> > Cc: netdev@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: xen-devel@lists.xenproject.org
> =

> This does not seem to be marked explicitly as stable. Has someone already=
 asked
> David Miller to put it on his stable queue? IMO it qualifies quite well a=
nd the
> actual change should be simple to pick/backport.
> =


Thank you Stefan, I'm queuing this for the next 3.16 kernel release.

Cheers,
--
Lu=EDs

> -Stefan
> =

> > =

> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 055222b..23359ae 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -628,9 +628,10 @@ static int xennet_start_xmit(struct sk_buff *skb, =
struct net_device *dev)
> >  	slots =3D DIV_ROUND_UP(offset + len, PAGE_SIZE) +
> >  		xennet_count_skb_frag_slots(skb);
> >  	if (unlikely(slots > MAX_SKB_FRAGS + 1)) {
> > -		net_alert_ratelimited(
> > -			"xennet: skb rides the rocket: %d slots\n", slots);
> > -		goto drop;
> > +		net_dbg_ratelimited("xennet: skb rides the rocket: %d slots, %d byte=
s\n",
> > +				    slots, skb->len);
> > +		if (skb_linearize(skb))
> > +			goto drop;
> >  	}
> >  =

> >  	spin_lock_irqsave(&queue->tx_lock, flags);
> > =

> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Dec 08 10:19:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:19:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxvPy-00079x-1L; Mon, 08 Dec 2014 10:19: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 1XxvPx-00079d-Ha
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:19:49 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	18/05-14214-44B75845; Mon, 08 Dec 2014 10:19:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418033988!9207046!1
X-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 19119 invoked from network); 8 Dec 2014 10:19:48 -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; 8 Dec 2014 10:19:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 10:19:47 +0000
Message-Id: <54858950020000780004DAF7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 10:19:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<20141208095847.GA16573@zion.uk.xensource.com>
In-Reply-To: <20141208095847.GA16573@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 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 08.12.14 at 10:58, <wei.liu2@citrix.com> wrote:
> Ping?

Please be a little more patient - with this series not to go into 4.5,
there's no need to urgently review it. The hypervisor side parts sit
in my to-be-reviewed queue.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:19:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:19:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxvPy-00079x-1L; Mon, 08 Dec 2014 10:19: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 1XxvPx-00079d-Ha
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 10:19:49 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	18/05-14214-44B75845; Mon, 08 Dec 2014 10:19:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418033988!9207046!1
X-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 19119 invoked from network); 8 Dec 2014 10:19:48 -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; 8 Dec 2014 10:19:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 10:19:47 +0000
Message-Id: <54858950020000780004DAF7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 10:19:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<20141208095847.GA16573@zion.uk.xensource.com>
In-Reply-To: <20141208095847.GA16573@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 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 08.12.14 at 10:58, <wei.liu2@citrix.com> wrote:
> Ping?

Please be a little more patient - with this series not to go into 4.5,
there's no need to urgently review it. The hypervisor side parts sit
in my to-be-reviewed queue.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:22:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxvS0-0007mE-RD; Mon, 08 Dec 2014 10:21: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 1XxvRy-0007jO-Us
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:21:55 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	9B/0E-24859-2CB75845; Mon, 08 Dec 2014 10:21:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418034112!9314410!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22743 invoked from network); 8 Dec 2014 10:21: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;
	8 Dec 2014 10:21:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201726498"
Message-ID: <1418034110.30016.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: manish jaggi <manishjaggi.oss@gmail.com>
Date: Mon, 8 Dec 2014 10:21:50 +0000
In-Reply-To: <CAAiw7Jm+aH7n4qOZcJQ4Wc+ocEugvPq+RWYHemwhOLmcd5+EGw@mail.gmail.com>
References: <CAAiw7Jm+aH7n4qOZcJQ4Wc+ocEugvPq+RWYHemwhOLmcd5+EGw@mail.gmail.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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	manish.jaggi@caviumnetworks.com, xen-users@lists.xen.org,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Steps to run XenServer on 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-12-05 at 15:15 -0800, manish jaggi wrote:
> Hi,
> 
> I am trying to find a tutorial to jumpstart installing XenServer / XCP
> on an ARM 64bit platform.
> Could the mailing list help.

TTBOMK there has been no work done on an ARM64 port of XenServer/XCP at
this time and only minimal work done on ARM generally. If you want to
get this working then I think you are looking at doing a port (i.e. a
bunch of development work) not simply following an installation
tutorial.

However XenServer/XCP is developed separately from XenProject as Open
XenServer over at xenserver.org, I suggest one of the lists over there
would be the best place to start a discussion of a new arm64 port of
xenserver.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:22:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxvS0-0007mE-RD; Mon, 08 Dec 2014 10:21: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 1XxvRy-0007jO-Us
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:21:55 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	9B/0E-24859-2CB75845; Mon, 08 Dec 2014 10:21:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418034112!9314410!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22743 invoked from network); 8 Dec 2014 10:21: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;
	8 Dec 2014 10:21:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201726498"
Message-ID: <1418034110.30016.1.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: manish jaggi <manishjaggi.oss@gmail.com>
Date: Mon, 8 Dec 2014 10:21:50 +0000
In-Reply-To: <CAAiw7Jm+aH7n4qOZcJQ4Wc+ocEugvPq+RWYHemwhOLmcd5+EGw@mail.gmail.com>
References: <CAAiw7Jm+aH7n4qOZcJQ4Wc+ocEugvPq+RWYHemwhOLmcd5+EGw@mail.gmail.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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	manish.jaggi@caviumnetworks.com, xen-users@lists.xen.org,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Steps to run XenServer on 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-12-05 at 15:15 -0800, manish jaggi wrote:
> Hi,
> 
> I am trying to find a tutorial to jumpstart installing XenServer / XCP
> on an ARM 64bit platform.
> Could the mailing list help.

TTBOMK there has been no work done on an ARM64 port of XenServer/XCP at
this time and only minimal work done on ARM generally. If you want to
get this working then I think you are looking at doing a port (i.e. a
bunch of development work) not simply following an installation
tutorial.

However XenServer/XCP is developed separately from XenProject as Open
XenServer over at xenserver.org, I suggest one of the lists over there
would be the best place to start a discussion of a new arm64 port of
xenserver.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:29:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1XxvYd-0008Eo-B2; Mon, 08 Dec 2014 10:28:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XxvYc-0008Ej-Cb
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:28:46 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	81/C5-24124-D5D75845; Mon, 08 Dec 2014 10:28:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418034523!12134926!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 12598 invoked from network); 8 Dec 2014 10:28:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 10:28:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201332445"
Message-ID: <54857D59.2050605@citrix.com>
Date: Mon, 8 Dec 2014 10:28:41 +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: =?UTF-8?B?TWloYWkgRG9uyJt1?= <mdontu@bitdefender.com>,
	<xen-devel@lists.xenproject.org>
References: <1417997962-23853-1-git-send-email-mdontu@bitdefender.com>
In-Reply-To: <1417997962-23853-1-git-send-email-mdontu@bitdefender.com>
Content-Length: 2866
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH] console: const-ify the arguments for
 __warn() and __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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDgvMTIvMTQgMDA6MTksIE1paGFpIERvbsibdSB3cm90ZToKPiBCb3RoIF9fd2FybigpIGFu
ZCBfX2J1ZygpIHRha2UgYXMgZmlyc3QgcGFyYW1ldGVyIHRoZSBmaWxlIG5hbWUgb2YgdGhlCj4g
Y3VycmVudCBjb21waWxhdGlvbiB1bml0IChfX0ZJTEVfXykuIE1hcmsgdGhhdCBwYXJhbWV0ZXIg
YXMgY29uc3RhbnQgdG8KPiBiZXR0ZXIgcmVmbGVjdCB0aGF0Lgo+Cj4gU2lnbmVkLW9mZi1ieTog
TWloYWkgRG9uyJt1IDxtZG9udHVAYml0ZGVmZW5kZXIuY29tPgoKVGhpcyBzZWVtcyByZWFzb25h
YmxlLCBidXQgZm9yIDQuNiBhdCB0aGlzIHBvaW50LgoKUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29w
ZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+CgpJbiBmdXR1cmUsIHBsZWFzZSBDQyB0aGUg
cmVsZXZhbnQgbWFpbnRhaW5lcnMgKHNjcmlwcy9nZXRfbWFpbnRhaW5lci5wbApzaG91bGQgaGVs
cCkKCj4gLS0tCj4gIHhlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jIHwgNCArKy0tCj4gIHhlbi9p
bmNsdWRlL3hlbi9saWIuaCAgICAgIHwgNCArKy0tCj4gIDIgZmlsZXMgY2hhbmdlZCwgNCBpbnNl
cnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL2No
YXIvY29uc29sZS5jIGIveGVuL2RyaXZlcnMvY2hhci9jb25zb2xlLmMKPiBpbmRleCAyZjAzMjU5
Li43ODA3Y2YyIDEwMDY0NAo+IC0tLSBhL3hlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jCj4gKysr
IGIveGVuL2RyaXZlcnMvY2hhci9jb25zb2xlLmMKPiBAQCAtMTEzOCw3ICsxMTM4LDcgQEAgdm9p
ZCBwYW5pYyhjb25zdCBjaGFyICpmbXQsIC4uLikKPiAgICAgICAgICBtYWNoaW5lX3Jlc3RhcnQo
NTAwMCk7Cj4gIH0KPgo+IC12b2lkIF9fYnVnKGNoYXIgKmZpbGUsIGludCBsaW5lKQo+ICt2b2lk
IF9fYnVnKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKQo+ICB7Cj4gICAgICBjb25zb2xlX3N0
YXJ0X3N5bmMoKTsKPiAgICAgIHByaW50aygiWGVuIEJVRyBhdCAlczolZFxuIiwgZmlsZSwgbGlu
ZSk7Cj4gQEAgLTExNDYsNyArMTE0Niw3IEBAIHZvaWQgX19idWcoY2hhciAqZmlsZSwgaW50IGxp
bmUpCj4gICAgICBwYW5pYygiWGVuIEJVRyBhdCAlczolZCIsIGZpbGUsIGxpbmUpOwo+ICB9Cj4K
PiAtdm9pZCBfX3dhcm4oY2hhciAqZmlsZSwgaW50IGxpbmUpCj4gK3ZvaWQgX193YXJuKGNvbnN0
IGNoYXIgKmZpbGUsIGludCBsaW5lKQo+ICB7Cj4gICAgICBwcmludGsoIlhlbiBXQVJOIGF0ICVz
OiVkXG4iLCBmaWxlLCBsaW5lKTsKPiAgICAgIGR1bXBfZXhlY3V0aW9uX3N0YXRlKCk7Cj4gZGlm
ZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi9saWIuaCBiL3hlbi9pbmNsdWRlL3hlbi9saWIuaAo+
IGluZGV4IGYxMWI0OWUuLjhmOWNhZGIgMTAwNjQ0Cj4gLS0tIGEveGVuL2luY2x1ZGUveGVuL2xp
Yi5oCj4gKysrIGIveGVuL2luY2x1ZGUveGVuL2xpYi5oCj4gQEAgLTgsOCArOCw4IEBACj4gICNp
bmNsdWRlIDx4ZW4vc3RyaW5nLmg+Cj4gICNpbmNsdWRlIDxhc20vYnVnLmg+Cj4KPiAtdm9pZCBu
b3JldHVybiBfX2J1ZyhjaGFyICpmaWxlLCBpbnQgbGluZSk7Cj4gLXZvaWQgX193YXJuKGNoYXIg
KmZpbGUsIGludCBsaW5lKTsKPiArdm9pZCBub3JldHVybiBfX2J1Zyhjb25zdCBjaGFyICpmaWxl
LCBpbnQgbGluZSk7Cj4gK3ZvaWQgX193YXJuKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKTsK
Pgo+ICAjZGVmaW5lIEJVR19PTihwKSAgZG8geyBpZiAodW5saWtlbHkocCkpIEJVRygpOyAgfSB3
aGlsZSAoMCkKPiAgI2RlZmluZSBXQVJOX09OKHApIGRvIHsgaWYgKHVubGlrZWx5KHApKSBXQVJO
KCk7IH0gd2hpbGUgKDApCj4gLS0KPiAyLjIuMAo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:29:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1XxvYd-0008Eo-B2; Mon, 08 Dec 2014 10:28:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XxvYc-0008Ej-Cb
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:28:46 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	81/C5-24124-D5D75845; Mon, 08 Dec 2014 10:28:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418034523!12134926!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 12598 invoked from network); 8 Dec 2014 10:28:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 10:28:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201332445"
Message-ID: <54857D59.2050605@citrix.com>
Date: Mon, 8 Dec 2014 10:28:41 +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: =?UTF-8?B?TWloYWkgRG9uyJt1?= <mdontu@bitdefender.com>,
	<xen-devel@lists.xenproject.org>
References: <1417997962-23853-1-git-send-email-mdontu@bitdefender.com>
In-Reply-To: <1417997962-23853-1-git-send-email-mdontu@bitdefender.com>
Content-Length: 2866
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH] console: const-ify the arguments for
 __warn() and __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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDgvMTIvMTQgMDA6MTksIE1paGFpIERvbsibdSB3cm90ZToKPiBCb3RoIF9fd2FybigpIGFu
ZCBfX2J1ZygpIHRha2UgYXMgZmlyc3QgcGFyYW1ldGVyIHRoZSBmaWxlIG5hbWUgb2YgdGhlCj4g
Y3VycmVudCBjb21waWxhdGlvbiB1bml0IChfX0ZJTEVfXykuIE1hcmsgdGhhdCBwYXJhbWV0ZXIg
YXMgY29uc3RhbnQgdG8KPiBiZXR0ZXIgcmVmbGVjdCB0aGF0Lgo+Cj4gU2lnbmVkLW9mZi1ieTog
TWloYWkgRG9uyJt1IDxtZG9udHVAYml0ZGVmZW5kZXIuY29tPgoKVGhpcyBzZWVtcyByZWFzb25h
YmxlLCBidXQgZm9yIDQuNiBhdCB0aGlzIHBvaW50LgoKUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29w
ZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+CgpJbiBmdXR1cmUsIHBsZWFzZSBDQyB0aGUg
cmVsZXZhbnQgbWFpbnRhaW5lcnMgKHNjcmlwcy9nZXRfbWFpbnRhaW5lci5wbApzaG91bGQgaGVs
cCkKCj4gLS0tCj4gIHhlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jIHwgNCArKy0tCj4gIHhlbi9p
bmNsdWRlL3hlbi9saWIuaCAgICAgIHwgNCArKy0tCj4gIDIgZmlsZXMgY2hhbmdlZCwgNCBpbnNl
cnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL2No
YXIvY29uc29sZS5jIGIveGVuL2RyaXZlcnMvY2hhci9jb25zb2xlLmMKPiBpbmRleCAyZjAzMjU5
Li43ODA3Y2YyIDEwMDY0NAo+IC0tLSBhL3hlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jCj4gKysr
IGIveGVuL2RyaXZlcnMvY2hhci9jb25zb2xlLmMKPiBAQCAtMTEzOCw3ICsxMTM4LDcgQEAgdm9p
ZCBwYW5pYyhjb25zdCBjaGFyICpmbXQsIC4uLikKPiAgICAgICAgICBtYWNoaW5lX3Jlc3RhcnQo
NTAwMCk7Cj4gIH0KPgo+IC12b2lkIF9fYnVnKGNoYXIgKmZpbGUsIGludCBsaW5lKQo+ICt2b2lk
IF9fYnVnKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKQo+ICB7Cj4gICAgICBjb25zb2xlX3N0
YXJ0X3N5bmMoKTsKPiAgICAgIHByaW50aygiWGVuIEJVRyBhdCAlczolZFxuIiwgZmlsZSwgbGlu
ZSk7Cj4gQEAgLTExNDYsNyArMTE0Niw3IEBAIHZvaWQgX19idWcoY2hhciAqZmlsZSwgaW50IGxp
bmUpCj4gICAgICBwYW5pYygiWGVuIEJVRyBhdCAlczolZCIsIGZpbGUsIGxpbmUpOwo+ICB9Cj4K
PiAtdm9pZCBfX3dhcm4oY2hhciAqZmlsZSwgaW50IGxpbmUpCj4gK3ZvaWQgX193YXJuKGNvbnN0
IGNoYXIgKmZpbGUsIGludCBsaW5lKQo+ICB7Cj4gICAgICBwcmludGsoIlhlbiBXQVJOIGF0ICVz
OiVkXG4iLCBmaWxlLCBsaW5lKTsKPiAgICAgIGR1bXBfZXhlY3V0aW9uX3N0YXRlKCk7Cj4gZGlm
ZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi9saWIuaCBiL3hlbi9pbmNsdWRlL3hlbi9saWIuaAo+
IGluZGV4IGYxMWI0OWUuLjhmOWNhZGIgMTAwNjQ0Cj4gLS0tIGEveGVuL2luY2x1ZGUveGVuL2xp
Yi5oCj4gKysrIGIveGVuL2luY2x1ZGUveGVuL2xpYi5oCj4gQEAgLTgsOCArOCw4IEBACj4gICNp
bmNsdWRlIDx4ZW4vc3RyaW5nLmg+Cj4gICNpbmNsdWRlIDxhc20vYnVnLmg+Cj4KPiAtdm9pZCBu
b3JldHVybiBfX2J1ZyhjaGFyICpmaWxlLCBpbnQgbGluZSk7Cj4gLXZvaWQgX193YXJuKGNoYXIg
KmZpbGUsIGludCBsaW5lKTsKPiArdm9pZCBub3JldHVybiBfX2J1Zyhjb25zdCBjaGFyICpmaWxl
LCBpbnQgbGluZSk7Cj4gK3ZvaWQgX193YXJuKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKTsK
Pgo+ICAjZGVmaW5lIEJVR19PTihwKSAgZG8geyBpZiAodW5saWtlbHkocCkpIEJVRygpOyAgfSB3
aGlsZSAoMCkKPiAgI2RlZmluZSBXQVJOX09OKHApIGRvIHsgaWYgKHVubGlrZWx5KHApKSBXQVJO
KCk7IH0gd2hpbGUgKDApCj4gLS0KPiAyLjIuMAo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:33:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxvcy-0000C3-0z; Mon, 08 Dec 2014 10:33:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xxvcw-0000By-N6
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 10:33:14 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	51/30-02698-96E75845; Mon, 08 Dec 2014 10:33:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418034792!13655419!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 23684 invoked from network); 8 Dec 2014 10:33:13 -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;
	8 Dec 2014 10:33:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201334197"
Message-ID: <1418034790.30016.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 8 Dec 2014 10:33:10 +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.

Konrad did I miss you reply/ack here or has one yet to be given?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:33:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxvcy-0000C3-0z; Mon, 08 Dec 2014 10:33:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xxvcw-0000By-N6
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 10:33:14 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	51/30-02698-96E75845; Mon, 08 Dec 2014 10:33:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418034792!13655419!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 23684 invoked from network); 8 Dec 2014 10:33:13 -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;
	8 Dec 2014 10:33:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201334197"
Message-ID: <1418034790.30016.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 8 Dec 2014 10:33:10 +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.

Konrad did I miss you reply/ack here or has one yet to be given?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:33:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:33:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxvd7-0000Dl-Cy; Mon, 08 Dec 2014 10:33:25 +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 1Xxvd6-0000DW-3T
	for Xen-devel@lists.xensource.com; Mon, 08 Dec 2014 10:33:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	30/27-15461-37E75845; Mon, 08 Dec 2014 10:33:23 +0000
X-Env-Sender: will.deacon@arm.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418034802!14113430!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30613 invoked from network); 8 Dec 2014 10:33:22 -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;
	8 Dec 2014 10:33: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 C6C56AE;
	Mon,  8 Dec 2014 04:33:18 -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 79B5C5FAD7;
	Mon,  8 Dec 2014 04:33:16 -0600 (CST)
Received: from arm.com (edgewater-inn.cambridge.arm.com [10.1.203.36])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 981DF13F87A;
	Mon,  8 Dec 2014 04:33:14 -0600 (CST)
Date: Mon, 8 Dec 2014 10:33:29 +0000
From: Will Deacon <will.deacon@arm.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Message-ID: <20141208103328.GE27367@arm.com>
References: <20141208184908.27bfd605@canb.auug.org.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141208184908.27bfd605@canb.auug.org.au>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <Xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Olof Johansson <olof@lixom.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with
 the arm-soc tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 07:49:08AM +0000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xen-tip tree got a conflict in
> arch/arm/include/asm/dma-mapping.h between commits a3a60f81ee6f
> ("dma-mapping: replace set_arch_dma_coherent_ops with
> arch_setup_dma_ops") and 4bb25789ed28 ("arm: dma-mapping: plumb our
> iommu mapping ops into arch_setup_dma_ops") from the arm-soc tree and
> commit 3d5391ac6f5e ("arm: introduce is_device_dma_coherent") from the
> xen-tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> I also neede this merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 8 Dec 2014 18:46:59 +1100
> Subject: [PATCH] arm: introduce is_device_dma_coherent merge fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/arm/mm/dma-mapping.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 09645f00bd17..43064cbe58f9 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -2058,6 +2058,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>  	else
>  		dma_ops = arm_get_dma_map_ops(coherent);
>  
> +	dev->archdata.dma_coherent = coherent;
>  	set_dma_ops(dev, dma_ops);
>  }

Looks good to me.

Cheers,

Will

> -- 
> 2.1.3
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc arch/arm/include/asm/dma-mapping.h
> index 9410b7e548fc,e6e3446abdf6..000000000000
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@@ -121,13 -121,20 +121,19 @@@ static inline unsigned long dma_max_pfn
>   }
>   #define dma_max_pfn(dev) dma_max_pfn(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)
>  +#define arch_setup_dma_ops arch_setup_dma_ops
>  +extern void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>  +			       struct iommu_ops *iommu, bool coherent);
>  +
>  +#define arch_teardown_dma_ops arch_teardown_dma_ops
>  +extern void arch_teardown_dma_ops(struct device *dev);
>   
> + /* do not use this function in a driver */
> + 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;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:33:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:33:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxvd7-0000Dl-Cy; Mon, 08 Dec 2014 10:33:25 +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 1Xxvd6-0000DW-3T
	for Xen-devel@lists.xensource.com; Mon, 08 Dec 2014 10:33:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	30/27-15461-37E75845; Mon, 08 Dec 2014 10:33:23 +0000
X-Env-Sender: will.deacon@arm.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418034802!14113430!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30613 invoked from network); 8 Dec 2014 10:33:22 -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;
	8 Dec 2014 10:33: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 C6C56AE;
	Mon,  8 Dec 2014 04:33:18 -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 79B5C5FAD7;
	Mon,  8 Dec 2014 04:33:16 -0600 (CST)
Received: from arm.com (edgewater-inn.cambridge.arm.com [10.1.203.36])
	by collaborate-mta1.arm.com (Postfix) with ESMTPS id 981DF13F87A;
	Mon,  8 Dec 2014 04:33:14 -0600 (CST)
Date: Mon, 8 Dec 2014 10:33:29 +0000
From: Will Deacon <will.deacon@arm.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Message-ID: <20141208103328.GE27367@arm.com>
References: <20141208184908.27bfd605@canb.auug.org.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141208184908.27bfd605@canb.auug.org.au>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <Xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Olof Johansson <olof@lixom.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with
 the arm-soc tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 07:49:08AM +0000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xen-tip tree got a conflict in
> arch/arm/include/asm/dma-mapping.h between commits a3a60f81ee6f
> ("dma-mapping: replace set_arch_dma_coherent_ops with
> arch_setup_dma_ops") and 4bb25789ed28 ("arm: dma-mapping: plumb our
> iommu mapping ops into arch_setup_dma_ops") from the arm-soc tree and
> commit 3d5391ac6f5e ("arm: introduce is_device_dma_coherent") from the
> xen-tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> I also neede this merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 8 Dec 2014 18:46:59 +1100
> Subject: [PATCH] arm: introduce is_device_dma_coherent merge fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/arm/mm/dma-mapping.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 09645f00bd17..43064cbe58f9 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -2058,6 +2058,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>  	else
>  		dma_ops = arm_get_dma_map_ops(coherent);
>  
> +	dev->archdata.dma_coherent = coherent;
>  	set_dma_ops(dev, dma_ops);
>  }

Looks good to me.

Cheers,

Will

> -- 
> 2.1.3
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc arch/arm/include/asm/dma-mapping.h
> index 9410b7e548fc,e6e3446abdf6..000000000000
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@@ -121,13 -121,20 +121,19 @@@ static inline unsigned long dma_max_pfn
>   }
>   #define dma_max_pfn(dev) dma_max_pfn(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)
>  +#define arch_setup_dma_ops arch_setup_dma_ops
>  +extern void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>  +			       struct iommu_ops *iommu, bool coherent);
>  +
>  +#define arch_teardown_dma_ops arch_teardown_dma_ops
>  +extern void arch_teardown_dma_ops(struct device *dev);
>   
> + /* do not use this function in a driver */
> + 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;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:36:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxvfv-0000TK-Vn; Mon, 08 Dec 2014 10:36:19 +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 1Xxvfu-0000TD-Vs
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:36:19 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	04/3D-02712-22F75845; Mon, 08 Dec 2014 10:36:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418034976!13657897!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25538 invoked from network); 8 Dec 2014 10:36:17 -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;
	8 Dec 2014 10:36:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201731178"
Message-ID: <54857F1E.1010506@citrix.com>
Date: Mon, 8 Dec 2014 10:36:14 +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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
	<1417788483-662-2-git-send-email-david.vrabel@citrix.com>
	<20141205213113.GB3012@kroah.com>
In-Reply-To: <20141205213113.GB3012@kroah.com>
X-DLP: MIA2
Cc: 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/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

On 05/12/14 21:31, Greg Kroah-Hartman wrote:
> On Fri, Dec 05, 2014 at 02:08:00PM +0000, David Vrabel wrote:
>> 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 ++++++++--
> 
> Is this why you sent this to me?  The x86 maintainers should handle this
> patch set, not me for a tiny 8 lines in just one of the files, sorry.

This series will be merged via the Xen tree, but this patch still needs
your review or ack.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:36:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxvfv-0000TK-Vn; Mon, 08 Dec 2014 10:36:19 +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 1Xxvfu-0000TD-Vs
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:36:19 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	04/3D-02712-22F75845; Mon, 08 Dec 2014 10:36:18 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418034976!13657897!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25538 invoked from network); 8 Dec 2014 10:36:17 -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;
	8 Dec 2014 10:36:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201731178"
Message-ID: <54857F1E.1010506@citrix.com>
Date: Mon, 8 Dec 2014 10:36:14 +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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
	<1417788483-662-2-git-send-email-david.vrabel@citrix.com>
	<20141205213113.GB3012@kroah.com>
In-Reply-To: <20141205213113.GB3012@kroah.com>
X-DLP: MIA2
Cc: 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/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

On 05/12/14 21:31, Greg Kroah-Hartman wrote:
> On Fri, Dec 05, 2014 at 02:08:00PM +0000, David Vrabel wrote:
>> 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 ++++++++--
> 
> Is this why you sent this to me?  The x86 maintainers should handle this
> patch set, not me for a tiny 8 lines in just one of the files, sorry.

This series will be merged via the Xen tree, but this patch still needs
your review or ack.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:38:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1Xxvhn-0000bQ-G3; Mon, 08 Dec 2014 10:38: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 1Xxvhm-0000bI-J1
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:38:14 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2D/76-09842-59F75845; Mon, 08 Dec 2014 10:38:13 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418035092!14130348!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 485 invoked from network); 8 Dec 2014 10:38:13 -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;
	8 Dec 2014 10:38:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201335579"
Message-ID: <54857F91.3020002@citrix.com>
Date: Mon, 8 Dec 2014 10:38:09 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
	<1417707546.15750.100.camel@bling.home>
	<54818929.5000008@citrix.com>
	<20141205172250.GA2895@laptop.dumpdata.com>
In-Reply-To: <20141205172250.GA2895@laptop.dumpdata.com>
X-DLP: MIA2
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Alex Williamson <alex.williamson@redhat.com>,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 17:22, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 05, 2014 at 10:30:01AM +0000, David Vrabel wrote:
>> On 04/12/14 15:39, Alex Williamson wrote:
>>>
>>> I don't know what workaround you're talking about.  As devices are
>>> released from the user, vfio-pci attempts to reset them.  If
>>> pci_reset_function() returns success we mark the device clean, otherwise
>>> it gets marked dirty.  Each time a device is released, if there are
>>> dirty devices we test whether we can try a bus/slot reset to clean them.
>>> In the case of assigning a GPU this typically means that the GPU or
>>> audio function come through first, there's no reset mechanism so it gets
>>> marked dirty, the next device comes through and we manage to try a bus
>>> reset.  vfio-pci does not have any device specific resets, all
>>> functionality is added to the PCI-core, thank-you-very-much.  I even
>>> posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
>>> bad so that pci_reset_function() won't claim that worked.  All VGA
>>> access quirks are done in QEMU, the kernel doesn't have any business in
>>> remapping config space over MMIO regions or trapping other config space
>>> backdoors.
>>
>> Thanks for the info Alex, I hadn't got around to actually looking and
>> the vfio-pci code and was just going to what Sander said.
>>
>> We probably do need to have a more in depth look at now PCI devices and
>> handled by both the toolstack and pciback but in the short term I would
>> like a simple solution that does not extend the ABI.
> 
> Could you enumerate the 'simple solution' then please? I am having
> a frustrating time figuring out what it is that you are proposing.

I've posted it repeatedly.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:38:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1Xxvhn-0000bQ-G3; Mon, 08 Dec 2014 10:38: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 1Xxvhm-0000bI-J1
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:38:14 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	2D/76-09842-59F75845; Mon, 08 Dec 2014 10:38:13 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418035092!14130348!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 485 invoked from network); 8 Dec 2014 10:38:13 -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;
	8 Dec 2014 10:38:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201335579"
Message-ID: <54857F91.3020002@citrix.com>
Date: Mon, 8 Dec 2014 10:38:09 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201412041206.sB4C6XVQ009497@userz7022.oracle.com>
	<5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
	<1417707546.15750.100.camel@bling.home>
	<54818929.5000008@citrix.com>
	<20141205172250.GA2895@laptop.dumpdata.com>
In-Reply-To: <20141205172250.GA2895@laptop.dumpdata.com>
X-DLP: MIA2
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Alex Williamson <alex.williamson@redhat.com>,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 17:22, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 05, 2014 at 10:30:01AM +0000, David Vrabel wrote:
>> On 04/12/14 15:39, Alex Williamson wrote:
>>>
>>> I don't know what workaround you're talking about.  As devices are
>>> released from the user, vfio-pci attempts to reset them.  If
>>> pci_reset_function() returns success we mark the device clean, otherwise
>>> it gets marked dirty.  Each time a device is released, if there are
>>> dirty devices we test whether we can try a bus/slot reset to clean them.
>>> In the case of assigning a GPU this typically means that the GPU or
>>> audio function come through first, there's no reset mechanism so it gets
>>> marked dirty, the next device comes through and we manage to try a bus
>>> reset.  vfio-pci does not have any device specific resets, all
>>> functionality is added to the PCI-core, thank-you-very-much.  I even
>>> posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
>>> bad so that pci_reset_function() won't claim that worked.  All VGA
>>> access quirks are done in QEMU, the kernel doesn't have any business in
>>> remapping config space over MMIO regions or trapping other config space
>>> backdoors.
>>
>> Thanks for the info Alex, I hadn't got around to actually looking and
>> the vfio-pci code and was just going to what Sander said.
>>
>> We probably do need to have a more in depth look at now PCI devices and
>> handled by both the toolstack and pciback but in the short term I would
>> like a simple solution that does not extend the ABI.
> 
> Could you enumerate the 'simple solution' then please? I am having
> a frustrating time figuring out what it is that you are proposing.

I've posted it repeatedly.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:57:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1Xxw0S-0001Wt-U0; Mon, 08 Dec 2014 10:57:32 +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 1Xxw0R-0001Wn-Jl
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 10:57:31 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	67/3D-26652-A1485845; Mon, 08 Dec 2014 10:57:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418036247!4511767!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3297 invoked from network); 8 Dec 2014 10:57:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 10:57:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201736067"
Message-ID: <54858415.80408@citrix.com>
Date: Mon, 8 Dec 2014 10:57:25 +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: 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>
References: <1418016739-19305-1-git-send-email-jgross@suse.com>
In-Reply-To: <1418016739-19305-1-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH] xen: annotate
 xen_set_identity_and_remap_chunk() with __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 08/12/14 05:32, Juergen Gross wrote:
> Commit 5b8e7d80542487ff1bf17b4cf2922a01dee13d3a removed the __init
> annotation from xen_set_identity_and_remap_chunk(). Add it again.

Applied, thanks.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:57:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1Xxw0S-0001Wt-U0; Mon, 08 Dec 2014 10:57:32 +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 1Xxw0R-0001Wn-Jl
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 10:57:31 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	67/3D-26652-A1485845; Mon, 08 Dec 2014 10:57:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418036247!4511767!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3297 invoked from network); 8 Dec 2014 10:57:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 10:57:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201736067"
Message-ID: <54858415.80408@citrix.com>
Date: Mon, 8 Dec 2014 10:57:25 +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: 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>
References: <1418016739-19305-1-git-send-email-jgross@suse.com>
In-Reply-To: <1418016739-19305-1-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH] xen: annotate
 xen_set_identity_and_remap_chunk() with __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 08/12/14 05:32, Juergen Gross wrote:
> Commit 5b8e7d80542487ff1bf17b4cf2922a01dee13d3a removed the __init
> annotation from xen_set_identity_and_remap_chunk(). Add it again.

Applied, thanks.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 10:58:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1Xxw1R-0001bL-Bg; Mon, 08 Dec 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 1Xxw1Q-0001bB-7j
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 10:58:32 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	66/BE-25714-75485845; Mon, 08 Dec 2014 10:58:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418036309!4512013!1
X-Originating-IP: [66.165.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 11644 invoked from network); 8 Dec 2014 10:58:30 -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;
	8 Dec 2014 10:58:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201736305"
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.210.2; Mon, 8 Dec 2014 05:58: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 1Xxw1L-0001Xe-RS;
	Mon, 08 Dec 2014 10:58:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xxw1L-0004DB-Hb;
	Mon, 08 Dec 2014 10:58:27 +0000
Date: Mon, 8 Dec 2014 10:58:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32139-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] 32139: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32139 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32139/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           4 xen-install               fail REGR. vs. 32093
 build-armhf-pvops             4 host-build-prep  fail in 32114 REGR. vs. 32093

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  5 xen-boot                   fail pass in 32114
 test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 32114 pass in 32139
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 32114 pass in 32139

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32093
 test-amd64-amd64-xl-sedf-pin  9 guest-start     fail in 32114 blocked in 32093

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-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-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-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
 test-armhf-armhf-libvirt      1 build-check(1)            blocked in 32114 n/a
 test-armhf-armhf-xl           1 build-check(1)            blocked in 32114 n/a
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 32114 never pass

version targeted for testing:
 xen                  10e7747bca538205555e313574432f231070153b
baseline version:
 xen                  3a80985b894f54eb3b2e143e4dea737cf139a517

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Chunyan Liu <cyliu@suse.com>
  Daniel Kiper <daniel.kiper@oracle.com>
  Don Dugger <donald.d.dugger@intel.com>
  Euan Harris <euan.harris@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>
  Kevin Tian <kevin.tian@intel.com>
  M A Young <m.a.young@durham.ac.uk>
  Michael Young <m.a.young@durham.ac.uk>
  Olaf Hering <olaf@aepfle.de>
  Razvan Cojocaru <rcojocaru@bitdefender.com>
  Tim Deegan <tim@xen.org>
  Vitaly Kuznetsov <vkuznets@redhat.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


Not pushing.

(No revision log; it would be 368 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 Dec 08 10:58:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 10: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 1Xxw1R-0001bL-Bg; Mon, 08 Dec 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 1Xxw1Q-0001bB-7j
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 10:58:32 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	66/BE-25714-75485845; Mon, 08 Dec 2014 10:58:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418036309!4512013!1
X-Originating-IP: [66.165.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 11644 invoked from network); 8 Dec 2014 10:58:30 -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;
	8 Dec 2014 10:58:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201736305"
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.210.2; Mon, 8 Dec 2014 05:58: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 1Xxw1L-0001Xe-RS;
	Mon, 08 Dec 2014 10:58:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xxw1L-0004DB-Hb;
	Mon, 08 Dec 2014 10:58:27 +0000
Date: Mon, 8 Dec 2014 10:58:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32139-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] 32139: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32139 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32139/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           4 xen-install               fail REGR. vs. 32093
 build-armhf-pvops             4 host-build-prep  fail in 32114 REGR. vs. 32093

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  5 xen-boot                   fail pass in 32114
 test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 32114 pass in 32139
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 32114 pass in 32139

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32093
 test-amd64-amd64-xl-sedf-pin  9 guest-start     fail in 32114 blocked in 32093

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-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-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-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
 test-armhf-armhf-libvirt      1 build-check(1)            blocked in 32114 n/a
 test-armhf-armhf-xl           1 build-check(1)            blocked in 32114 n/a
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 32114 never pass

version targeted for testing:
 xen                  10e7747bca538205555e313574432f231070153b
baseline version:
 xen                  3a80985b894f54eb3b2e143e4dea737cf139a517

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Chunyan Liu <cyliu@suse.com>
  Daniel Kiper <daniel.kiper@oracle.com>
  Don Dugger <donald.d.dugger@intel.com>
  Euan Harris <euan.harris@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>
  Kevin Tian <kevin.tian@intel.com>
  M A Young <m.a.young@durham.ac.uk>
  Michael Young <m.a.young@durham.ac.uk>
  Olaf Hering <olaf@aepfle.de>
  Razvan Cojocaru <rcojocaru@bitdefender.com>
  Tim Deegan <tim@xen.org>
  Vitaly Kuznetsov <vkuznets@redhat.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


Not pushing.

(No revision log; it would be 368 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 Dec 08 11:02:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 11:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxw4z-00020z-5q; Mon, 08 Dec 2014 11:02:13 +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 1Xxw4x-0001za-C3
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 11:02:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BA/93-09842-23585845; Mon, 08 Dec 2014 11:02:10 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418036529!14082343!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11997 invoked from network); 8 Dec 2014 11:02:10 -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;
	8 Dec 2014 11:02:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201737593"
Message-ID: <5485852F.3080600@citrix.com>
Date: Mon, 8 Dec 2014 11:02:07 +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: Thanos Makatos <thanos.makatos@citrix.com>,
	<xen-devel@lists.xenproject.org>
References: <1417536806-22562-1-git-send-email-thanos.makatos@citrix.com>
In-Reply-To: <1417536806-22562-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 v2] 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/12/14 16:13, Thanos Makatos wrote:
>  
> +struct gntdev_grant_copy_segment {
> +
> +	union {
> +		/* copy from (to) self to (from) guest */
> +		struct {
> +			/*
> +			 * source address and length
> +			 */
> +			struct iovec iov;
> +
> +			/* the granted page */
> +			uint32_t ref;
> +
> +			/* offset in the granted page */
> +			uint16_t offset;
> +		} self;
> +
> +		/* copy from guest to guest */
> +		struct {
> +			uint16_t len;
> +
> +			struct {
> +				/* the granted page */
> +				uint32_t ref;
> +
> +				/* offset in the granted page */
> +				uint16_t offset;
> +			} src, dst;
> +		} g2g;
> +	};
> +
> +	/* grant copy result (GNTST_XXX) */
> +	int16_t status;
> +};

I asked for this ioctl to mirror the hypercall.

Which looks like:

struct gnttab_copy {
        /* IN parameters. */
        struct {
                union {
                        grant_ref_t ref;
                        xen_pfn_t   gmfn;
                } u;
                domid_t  domid;
                uint16_t offset;
        } source, dest;
        uint16_t      len;
        uint16_t      flags;          /* GNTCOPY_* */
        /* OUT parameters. */
        int16_t       status;
};

i.e., each operation specifies the domid of the source and destination
and whether it includes a ref or a virtual address.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 11:02:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 11:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxw4z-00020z-5q; Mon, 08 Dec 2014 11:02:13 +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 1Xxw4x-0001za-C3
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 11:02:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BA/93-09842-23585845; Mon, 08 Dec 2014 11:02:10 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418036529!14082343!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11997 invoked from network); 8 Dec 2014 11:02:10 -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;
	8 Dec 2014 11:02:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201737593"
Message-ID: <5485852F.3080600@citrix.com>
Date: Mon, 8 Dec 2014 11:02:07 +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: Thanos Makatos <thanos.makatos@citrix.com>,
	<xen-devel@lists.xenproject.org>
References: <1417536806-22562-1-git-send-email-thanos.makatos@citrix.com>
In-Reply-To: <1417536806-22562-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 v2] 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/12/14 16:13, Thanos Makatos wrote:
>  
> +struct gntdev_grant_copy_segment {
> +
> +	union {
> +		/* copy from (to) self to (from) guest */
> +		struct {
> +			/*
> +			 * source address and length
> +			 */
> +			struct iovec iov;
> +
> +			/* the granted page */
> +			uint32_t ref;
> +
> +			/* offset in the granted page */
> +			uint16_t offset;
> +		} self;
> +
> +		/* copy from guest to guest */
> +		struct {
> +			uint16_t len;
> +
> +			struct {
> +				/* the granted page */
> +				uint32_t ref;
> +
> +				/* offset in the granted page */
> +				uint16_t offset;
> +			} src, dst;
> +		} g2g;
> +	};
> +
> +	/* grant copy result (GNTST_XXX) */
> +	int16_t status;
> +};

I asked for this ioctl to mirror the hypercall.

Which looks like:

struct gnttab_copy {
        /* IN parameters. */
        struct {
                union {
                        grant_ref_t ref;
                        xen_pfn_t   gmfn;
                } u;
                domid_t  domid;
                uint16_t offset;
        } source, dest;
        uint16_t      len;
        uint16_t      flags;          /* GNTCOPY_* */
        /* OUT parameters. */
        int16_t       status;
};

i.e., each operation specifies the domid of the source and destination
and whether it includes a ref or a virtual address.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 11:11:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 11:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxwDp-0002G9-6X; Mon, 08 Dec 2014 11:11: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 1XxwDo-0002G4-Ix
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 11:11:20 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	8A/50-02954-75785845; Mon, 08 Dec 2014 11:11:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418037078!13630510!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5702 invoked from network); 8 Dec 2014 11:11:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 11:11:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201740009"
Message-ID: <54858753.1070801@citrix.com>
Date: Mon, 8 Dec 2014 11:11:15 +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: Luis Henriques <luis.henriques@canonical.com>, Stefan Bader
	<stefan.bader@canonical.com>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>	<547C2CFC.7060908@canonical.com>
	<20141208101936.GA7491@hercules>
In-Reply-To: <20141208101936.GA7491@hercules>
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, Kamal Mostafa <kamal@canonical.com>,
	linux-kernel@vger.kernel.org, Paul Durrant <paul.durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Zoltan Kiss <zoltan.kiss@citrix.com>, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 10:19, Luis Henriques wrote:
> On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>> There is a long known problem with the netfront/netback interface: if the guest
>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
>>> it gets dropped. The reason is that netback maps these slots to a frag in the
>>> frags array, which is limited by size. Having so many slots can occur since
>>> compound pages were introduced, as the ring protocol slice them up into
>>> individual (non-compound) page aligned slots. The theoretical worst case
>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
>>> using 2 slots
>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
>>> end and the beginning of a page, therefore they use 3 * 15 = 45 slots
>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
>>> Although I don't think this 51 slots skb can really happen, we need a solution
>>> which can deal with every scenario. In real life there is only a few slots
>>> overdue, but usually it causes the TCP stream to be blocked, as the retry will
>>> most likely have the same buffer layout.
>>> This patch solves this problem by linearizing the packet. This is not the
>>> fastest way, and it can fail much easier as it tries to allocate a big linear
>>> area for the whole packet, but probably easier by an order of magnitude than
>>> anything else. Probably this code path is not touched very frequently anyway.
>>>
>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>> Cc: netdev@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Cc: xen-devel@lists.xenproject.org
>>
>> This does not seem to be marked explicitly as stable. Has someone already asked
>> David Miller to put it on his stable queue? IMO it qualifies quite well and the
>> actual change should be simple to pick/backport.
>>
> 
> Thank you Stefan, I'm queuing this for the next 3.16 kernel release.

Don't backport this yes.  It's broken.  It produces malformed requests
and netback will report a fatal error and stop all traffic on the VIF.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 11:11:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 11:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxwDp-0002G9-6X; Mon, 08 Dec 2014 11:11: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 1XxwDo-0002G4-Ix
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 11:11:20 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	8A/50-02954-75785845; Mon, 08 Dec 2014 11:11:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418037078!13630510!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5702 invoked from network); 8 Dec 2014 11:11:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 11:11:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201740009"
Message-ID: <54858753.1070801@citrix.com>
Date: Mon, 8 Dec 2014 11:11:15 +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: Luis Henriques <luis.henriques@canonical.com>, Stefan Bader
	<stefan.bader@canonical.com>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>	<547C2CFC.7060908@canonical.com>
	<20141208101936.GA7491@hercules>
In-Reply-To: <20141208101936.GA7491@hercules>
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, Kamal Mostafa <kamal@canonical.com>,
	linux-kernel@vger.kernel.org, Paul Durrant <paul.durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Zoltan Kiss <zoltan.kiss@citrix.com>, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 10:19, Luis Henriques wrote:
> On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>> There is a long known problem with the netfront/netback interface: if the guest
>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
>>> it gets dropped. The reason is that netback maps these slots to a frag in the
>>> frags array, which is limited by size. Having so many slots can occur since
>>> compound pages were introduced, as the ring protocol slice them up into
>>> individual (non-compound) page aligned slots. The theoretical worst case
>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
>>> using 2 slots
>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
>>> end and the beginning of a page, therefore they use 3 * 15 = 45 slots
>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
>>> Although I don't think this 51 slots skb can really happen, we need a solution
>>> which can deal with every scenario. In real life there is only a few slots
>>> overdue, but usually it causes the TCP stream to be blocked, as the retry will
>>> most likely have the same buffer layout.
>>> This patch solves this problem by linearizing the packet. This is not the
>>> fastest way, and it can fail much easier as it tries to allocate a big linear
>>> area for the whole packet, but probably easier by an order of magnitude than
>>> anything else. Probably this code path is not touched very frequently anyway.
>>>
>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>> Cc: netdev@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Cc: xen-devel@lists.xenproject.org
>>
>> This does not seem to be marked explicitly as stable. Has someone already asked
>> David Miller to put it on his stable queue? IMO it qualifies quite well and the
>> actual change should be simple to pick/backport.
>>
> 
> Thank you Stefan, I'm queuing this for the next 3.16 kernel release.

Don't backport this yes.  It's broken.  It produces malformed requests
and netback will report a fatal error and stop all traffic on the VIF.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 11:12:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 11:12:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxwEl-0002Wk-Kh; Mon, 08 Dec 2014 11:12: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 1XxwEk-0002WY-FO
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 11:12:18 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	ED/6A-02957-19785845; Mon, 08 Dec 2014 11:12:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418037135!13667544!1
X-Originating-IP: [66.165.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 25916 invoked from network); 8 Dec 2014 11:12:16 -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;
	8 Dec 2014 11:12:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201740321"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 06:12:14 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XxwEg-0006vm-6s;
	Mon, 08 Dec 2014 11:12:14 +0000
Date: Mon, 8 Dec 2014 11:12:14 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Message-ID: <20141208111214.GC17128@zion.uk.xensource.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5485C5170200006600081D20@soto.provo.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian.Campbell@citrix.com,
	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, Dec 08, 2014 at 12:34:47AM -0700, Chun Yan Liu wrote:
> 
> 
> >>> On 12/6/2014 at 12:06 AM, in message
> <20141205160615.GA24938@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
> wrote: 
> > I have to admit I'm confused by the back and forth discussion. It's hard 
> > to justify the design of new API without knowing what the constraints 
> > and requirements are from your PoV. 
> >  
> > Here are my two cents, not about details, but about general constraints. 
> >  
> > There are two layers, one is user of libxl (clients -- xl, libvirt etc) 
> > and libxl (the library itself). 
> >  
> > 1. it's better to *not* have storage management in libxl. 
> >  
> > It's likely that clients can have their own management functionality 
> > already.  I'm told that libvirt has that as well as XAPI. Having this 
> > functionality in libxl is a bit redundant and requires lots of work 
> > (enlighten libxl on what a disk looks like and call out to various 
> > utilities). 
> 
> Thanks Wei and Ian for your reply. We did have much discussion around
> can/cannot (e.g. xl can finish disk snapshot?) and should/shouldnot
> (e.g. disk snapshot process should not in xl? domain_snapshot_delete
> should not in libxl?), and confusing because have different ideas. So,
> settling it down is helpful.
> 
> Talking about libvirt, it does provide storage management but through
> storage pools and volumes. But usually, we don't use storage pool/vol
> but directly use backend files, then libvirt storage driver can not
> manage them. And for libvirt vol, functionality in storage driver is
> limited, at least 'snapshot' cannot be done. So, libvirt side also
> needs to add codes to handle disk snapshot, quite like xl does.
> 

OK, so I take it that libvirt can be completely out the picture? I mean,
it's not a requirement for you to integrate with libvirt?

I was thinking a stack like this when I replied:

  libvirt: manages snapshot (including storage snapshot)
  libxl
  [other lower level stuffs]

While I read from your reply, libvirt doesn't have that functionality
(or very limited), so you would like to do things like:

  libvirt (or your homebrew toolstack)
  xl      (xl or libxl manages domain snapshots)
  libxl
  [other lower level stuffs]

That's why you spent loads of time discussing with Ian what should be
done where, right?

> Following the constraint that it's better NOT to supply disk snapshot
> functions in libxl, then we let xl and libvirt do that by themselve
> separately, that's OK.
> 
> Then I think NO new API needs to be exported in libxl, since:
> * saving/restoring memory, there are already APIs.

The principle is that if existing API doesn't work good enough for you
we will consider adding a new one.

We probably need a new API. If you want to do a live snapshot, we would
need to notify xl that we are in the middle of pausing and resuming a
domain. 

> * disk snapshot work is xl internal, can be put in xl (or xlu).
> * handle JSON files is xl internal, can be put in xl.

Yes.

> (these are the main work vm snapshot handles).
> 
> Right?
> 
> This is quite different from previous document, so better to confirm.
> 
> >  
> > 2. it's *not* a requirement for xl to have the capability to manage 
> > snapshots. 
> >  
> > It's the same arguement that xl has no idea on how to manage snapshots 
> > created by "xl save".  This should ease your concern on having to 
> > duplicate code for libvirt and xl.  IMHO the xl only needs to have the 
> > capability to create a snapshot and create a domain from a snapshot.
> 
> This way it's much easier since we don't need to maintain the snapshot
> info in file and don't need to take care of snapshot chain. But I doubt if
> that's good?
> 1. from user's side, it's a very common request to list all snapshots.
> 2. now for kvm, virsh supplies snapshot-create/delete/list/revert,
>    Is it good the xl only supply snapshot-create/revert? After all,
>    it's more complicated for user to take care of memory saving file
>    and disk snapshot info then 'xl save' (user only needs to take
>    care of memory state file).
> 

However the current architecture for libvirt to use libxl is like

  libvirt
  libxl
  [other lower level stuffs]

So implementing snapshot management in xl cannot work for you either.
It's not part of the current architecture.

Not that I'm against the idea of managing domain snapshot in xl, I'm
trying to reduce workload here.

> > The 
> > downside is that now xl and libvirt are disconnected, but I think it's 
> > fine.
> 
> Two things here:
> 1. connect xl and libvirt, then will need to manage snapshot info in libxl (or
>     libxlu) That's not preferred since the initial design. This is not the point
>     we discuss here.
> 2. for xl only, list snapshots and delete snapshots, also need to manage
>     snapshot info (in xl)
> 
> Considering manage snapshot info in xl, only question is about idl and
> gentypes.py, expected structure is as following and expected to be saved
> into json file, but it contains xl namespace and libxl namespace things,
> gentypes.py will have problem. Better ideas?
> 
> typedef struct xl_domain_snapshot {
>     char * name;
>     char * description;
>     uint64_t creation_time;
>     char * memory_path;
>     int num_disks;
>     libxl_disk_snapshot *disks;
>     char *parent;
>     bool *current;
> } xl_domain_snapshot;
> 

The libxl_disk_snapshot suggests that you still want storage management
inside libxl, which should probably be in libxlu?

  libvirt
  libxl libxlu
  [other lower level stuffs]

Wei.

> Thanks a lot!
> Chunyan
> 
> > The arguement is that you're not allowed to run two toolstack on 
> > the same host (think about xl and xend in previous releases). 
> >  
> > Do these two constraints make your work easier (or harder)? 
> >  
> > Regarding JSON API, as Ian said, feel free to hook it up to libxlu. 
> >  
> > Wei. 
> >  
> >  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 11:12:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 11:12:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxwEl-0002Wk-Kh; Mon, 08 Dec 2014 11:12: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 1XxwEk-0002WY-FO
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 11:12:18 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	ED/6A-02957-19785845; Mon, 08 Dec 2014 11:12:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418037135!13667544!1
X-Originating-IP: [66.165.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 25916 invoked from network); 8 Dec 2014 11:12:16 -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;
	8 Dec 2014 11:12:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,537,1413244800"; d="scan'208";a="201740321"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 06:12:14 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XxwEg-0006vm-6s;
	Mon, 08 Dec 2014 11:12:14 +0000
Date: Mon, 8 Dec 2014 11:12:14 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Message-ID: <20141208111214.GC17128@zion.uk.xensource.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5485C5170200006600081D20@soto.provo.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian.Campbell@citrix.com,
	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, Dec 08, 2014 at 12:34:47AM -0700, Chun Yan Liu wrote:
> 
> 
> >>> On 12/6/2014 at 12:06 AM, in message
> <20141205160615.GA24938@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
> wrote: 
> > I have to admit I'm confused by the back and forth discussion. It's hard 
> > to justify the design of new API without knowing what the constraints 
> > and requirements are from your PoV. 
> >  
> > Here are my two cents, not about details, but about general constraints. 
> >  
> > There are two layers, one is user of libxl (clients -- xl, libvirt etc) 
> > and libxl (the library itself). 
> >  
> > 1. it's better to *not* have storage management in libxl. 
> >  
> > It's likely that clients can have their own management functionality 
> > already.  I'm told that libvirt has that as well as XAPI. Having this 
> > functionality in libxl is a bit redundant and requires lots of work 
> > (enlighten libxl on what a disk looks like and call out to various 
> > utilities). 
> 
> Thanks Wei and Ian for your reply. We did have much discussion around
> can/cannot (e.g. xl can finish disk snapshot?) and should/shouldnot
> (e.g. disk snapshot process should not in xl? domain_snapshot_delete
> should not in libxl?), and confusing because have different ideas. So,
> settling it down is helpful.
> 
> Talking about libvirt, it does provide storage management but through
> storage pools and volumes. But usually, we don't use storage pool/vol
> but directly use backend files, then libvirt storage driver can not
> manage them. And for libvirt vol, functionality in storage driver is
> limited, at least 'snapshot' cannot be done. So, libvirt side also
> needs to add codes to handle disk snapshot, quite like xl does.
> 

OK, so I take it that libvirt can be completely out the picture? I mean,
it's not a requirement for you to integrate with libvirt?

I was thinking a stack like this when I replied:

  libvirt: manages snapshot (including storage snapshot)
  libxl
  [other lower level stuffs]

While I read from your reply, libvirt doesn't have that functionality
(or very limited), so you would like to do things like:

  libvirt (or your homebrew toolstack)
  xl      (xl or libxl manages domain snapshots)
  libxl
  [other lower level stuffs]

That's why you spent loads of time discussing with Ian what should be
done where, right?

> Following the constraint that it's better NOT to supply disk snapshot
> functions in libxl, then we let xl and libvirt do that by themselve
> separately, that's OK.
> 
> Then I think NO new API needs to be exported in libxl, since:
> * saving/restoring memory, there are already APIs.

The principle is that if existing API doesn't work good enough for you
we will consider adding a new one.

We probably need a new API. If you want to do a live snapshot, we would
need to notify xl that we are in the middle of pausing and resuming a
domain. 

> * disk snapshot work is xl internal, can be put in xl (or xlu).
> * handle JSON files is xl internal, can be put in xl.

Yes.

> (these are the main work vm snapshot handles).
> 
> Right?
> 
> This is quite different from previous document, so better to confirm.
> 
> >  
> > 2. it's *not* a requirement for xl to have the capability to manage 
> > snapshots. 
> >  
> > It's the same arguement that xl has no idea on how to manage snapshots 
> > created by "xl save".  This should ease your concern on having to 
> > duplicate code for libvirt and xl.  IMHO the xl only needs to have the 
> > capability to create a snapshot and create a domain from a snapshot.
> 
> This way it's much easier since we don't need to maintain the snapshot
> info in file and don't need to take care of snapshot chain. But I doubt if
> that's good?
> 1. from user's side, it's a very common request to list all snapshots.
> 2. now for kvm, virsh supplies snapshot-create/delete/list/revert,
>    Is it good the xl only supply snapshot-create/revert? After all,
>    it's more complicated for user to take care of memory saving file
>    and disk snapshot info then 'xl save' (user only needs to take
>    care of memory state file).
> 

However the current architecture for libvirt to use libxl is like

  libvirt
  libxl
  [other lower level stuffs]

So implementing snapshot management in xl cannot work for you either.
It's not part of the current architecture.

Not that I'm against the idea of managing domain snapshot in xl, I'm
trying to reduce workload here.

> > The 
> > downside is that now xl and libvirt are disconnected, but I think it's 
> > fine.
> 
> Two things here:
> 1. connect xl and libvirt, then will need to manage snapshot info in libxl (or
>     libxlu) That's not preferred since the initial design. This is not the point
>     we discuss here.
> 2. for xl only, list snapshots and delete snapshots, also need to manage
>     snapshot info (in xl)
> 
> Considering manage snapshot info in xl, only question is about idl and
> gentypes.py, expected structure is as following and expected to be saved
> into json file, but it contains xl namespace and libxl namespace things,
> gentypes.py will have problem. Better ideas?
> 
> typedef struct xl_domain_snapshot {
>     char * name;
>     char * description;
>     uint64_t creation_time;
>     char * memory_path;
>     int num_disks;
>     libxl_disk_snapshot *disks;
>     char *parent;
>     bool *current;
> } xl_domain_snapshot;
> 

The libxl_disk_snapshot suggests that you still want storage management
inside libxl, which should probably be in libxlu?

  libvirt
  libxl libxlu
  [other lower level stuffs]

Wei.

> Thanks a lot!
> Chunyan
> 
> > The arguement is that you're not allowed to run two toolstack on 
> > the same host (think about xl and xend in previous releases). 
> >  
> > Do these two constraints make your work easier (or harder)? 
> >  
> > Regarding JSON API, as Ian said, feel free to hook it up to libxlu. 
> >  
> > Wei. 
> >  
> >  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 11:21:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 11:21:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxwNY-0002kn-MF; Mon, 08 Dec 2014 11:21:24 +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 1XxwNW-0002ki-Ss
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 11:21:23 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	31/8C-08051-2B985845; Mon, 08 Dec 2014 11:21:22 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418037681!13643009!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21688 invoked from network); 8 Dec 2014 11:21:21 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Dec 2014 11:21:21 -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 1XxwNV-00019d-2G
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 11:21:21 +0000
Message-ID: <548589B0.8050608@canonical.com>
Date: Mon, 08 Dec 2014 12:21:20 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>	<547C2CFC.7060908@canonical.com>	<20141208101936.GA7491@hercules>
	<54858753.1070801@citrix.com>
In-Reply-To: <54858753.1070801@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3438314843841265013=="
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)
--===============3438314843841265013==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="ae4IRf2AAiRSmt6liaxUrJtTPeC8K8w8w"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ae4IRf2AAiRSmt6liaxUrJtTPeC8K8w8w
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 08.12.2014 12:11, David Vrabel wrote:
> On 08/12/14 10:19, Luis Henriques wrote:
>> On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
>>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>>> There is a long known problem with the netfront/netback interface: i=
f the guest
>>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 =
ring slots,
>>>> it gets dropped. The reason is that netback maps these slots to a fr=
ag in the
>>>> frags array, which is limited by size. Having so many slots can occu=
r since
>>>> compound pages were introduced, as the ring protocol slice them up i=
nto
>>>> individual (non-compound) page aligned slots. The theoretical worst =
case
>>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page bo=
undary,
>>>> using 2 slots
>>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes a=
re at the
>>>> end and the beginning of a page, therefore they use 3 * 15 =3D 45 sl=
ots
>>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 sl=
ots
>>>> Although I don't think this 51 slots skb can really happen, we need =
a solution
>>>> which can deal with every scenario. In real life there is only a few=
 slots
>>>> overdue, but usually it causes the TCP stream to be blocked, as the =
retry will
>>>> most likely have the same buffer layout.
>>>> This patch solves this problem by linearizing the packet. This is no=
t the
>>>> fastest way, and it can fail much easier as it tries to allocate a b=
ig linear
>>>> area for the whole packet, but probably easier by an order of magnit=
ude than
>>>> anything else. Probably this code path is not touched very frequentl=
y anyway.
>>>>
>>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>>> Cc: netdev@vger.kernel.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Cc: xen-devel@lists.xenproject.org
>>>
>>> This does not seem to be marked explicitly as stable. Has someone alr=
eady asked
>>> David Miller to put it on his stable queue? IMO it qualifies quite we=
ll and the
>>> actual change should be simple to pick/backport.
>>>
>>
>> Thank you Stefan, I'm queuing this for the next 3.16 kernel release.
>=20
> Don't backport this yes.  It's broken.  It produces malformed requests
> and netback will report a fatal error and stop all traffic on the VIF.

Thanks David. Did this just come up? I don't remember seeing any report o=
f the
regression. :/

-Stefan

>=20
> David
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--ae4IRf2AAiRSmt6liaxUrJtTPeC8K8w8w
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

iQIcBAEBCgAGBQJUhYmwAAoJEOhnXe7L7s6j75AP/31P2RjZBPGIhsVkf2s86tvn
WBpGgMWNfI37tG1PCoNZs6yS/NEjdmkGd5kWqwkshgjmzJdp8MGIXAx/OYPkWWMa
XVG4Vi233U3clTyhsY7azEk/ubzULIazB9mP5ZEG3v171bKgyrrgFcMjxBOU5pNJ
U0z42SNUADgOLI4GLw9UwvljwdORNosgH4a388vSG4tkUQcP9dkRNY4Ul2Oa5jV0
gd07DJ4CZOPzspfVRFJ7FtSCivCVPALCr6hvXBj+thpSGFMSKlyQ1OlEsUpApJ4O
s10487u0F1+QukphsjCp23ttkET+TbjpSyZLCK9DLIeR3rvgp4o/cqQ9TPBEE8F3
xel06ugijIt31fBM4Hb5wfFhWcphXzEnOaUZcnN+oojiGXGXXGru6pTfeUctmE/D
zLW7YInl+rWcUm69wJt5jz/h4u/zd/anogopQT/ifWdD8HhJluUX1GAPCqDJ3Bzq
HjHwCMIjxK3bXT86e03U3F0/VHjX/F42GUGmXW+sqKWispgCDyBWxYbTQ2+pPUxI
h6lzsMapov//4AYg3Tpwx7COBcIMuXbUquIP2AnChBFt5ZcOv5+w4r/5E7eMiKJ5
p3dKqAKbRTmq3uc0HB0ylxs20ORqbQMZFBTsJ+Ntu7eP8IMyKj7VKW/5xb1q+uom
w4QfV+KrcZtmlZ60puDC
=A4qa
-----END PGP SIGNATURE-----

--ae4IRf2AAiRSmt6liaxUrJtTPeC8K8w8w--


--===============3438314843841265013==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3438314843841265013==--


From xen-devel-bounces@lists.xen.org Mon Dec 08 11:21:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 11:21:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxwNY-0002kn-MF; Mon, 08 Dec 2014 11:21:24 +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 1XxwNW-0002ki-Ss
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 11:21:23 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	31/8C-08051-2B985845; Mon, 08 Dec 2014 11:21:22 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418037681!13643009!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21688 invoked from network); 8 Dec 2014 11:21:21 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Dec 2014 11:21:21 -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 1XxwNV-00019d-2G
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 11:21:21 +0000
Message-ID: <548589B0.8050608@canonical.com>
Date: Mon, 08 Dec 2014 12:21:20 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>	<547C2CFC.7060908@canonical.com>	<20141208101936.GA7491@hercules>
	<54858753.1070801@citrix.com>
In-Reply-To: <54858753.1070801@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3438314843841265013=="
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)
--===============3438314843841265013==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="ae4IRf2AAiRSmt6liaxUrJtTPeC8K8w8w"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ae4IRf2AAiRSmt6liaxUrJtTPeC8K8w8w
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 08.12.2014 12:11, David Vrabel wrote:
> On 08/12/14 10:19, Luis Henriques wrote:
>> On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
>>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>>> There is a long known problem with the netfront/netback interface: i=
f the guest
>>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 =
ring slots,
>>>> it gets dropped. The reason is that netback maps these slots to a fr=
ag in the
>>>> frags array, which is limited by size. Having so many slots can occu=
r since
>>>> compound pages were introduced, as the ring protocol slice them up i=
nto
>>>> individual (non-compound) page aligned slots. The theoretical worst =
case
>>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page bo=
undary,
>>>> using 2 slots
>>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes a=
re at the
>>>> end and the beginning of a page, therefore they use 3 * 15 =3D 45 sl=
ots
>>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 sl=
ots
>>>> Although I don't think this 51 slots skb can really happen, we need =
a solution
>>>> which can deal with every scenario. In real life there is only a few=
 slots
>>>> overdue, but usually it causes the TCP stream to be blocked, as the =
retry will
>>>> most likely have the same buffer layout.
>>>> This patch solves this problem by linearizing the packet. This is no=
t the
>>>> fastest way, and it can fail much easier as it tries to allocate a b=
ig linear
>>>> area for the whole packet, but probably easier by an order of magnit=
ude than
>>>> anything else. Probably this code path is not touched very frequentl=
y anyway.
>>>>
>>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>>> Cc: netdev@vger.kernel.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Cc: xen-devel@lists.xenproject.org
>>>
>>> This does not seem to be marked explicitly as stable. Has someone alr=
eady asked
>>> David Miller to put it on his stable queue? IMO it qualifies quite we=
ll and the
>>> actual change should be simple to pick/backport.
>>>
>>
>> Thank you Stefan, I'm queuing this for the next 3.16 kernel release.
>=20
> Don't backport this yes.  It's broken.  It produces malformed requests
> and netback will report a fatal error and stop all traffic on the VIF.

Thanks David. Did this just come up? I don't remember seeing any report o=
f the
regression. :/

-Stefan

>=20
> David
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--ae4IRf2AAiRSmt6liaxUrJtTPeC8K8w8w
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

iQIcBAEBCgAGBQJUhYmwAAoJEOhnXe7L7s6j75AP/31P2RjZBPGIhsVkf2s86tvn
WBpGgMWNfI37tG1PCoNZs6yS/NEjdmkGd5kWqwkshgjmzJdp8MGIXAx/OYPkWWMa
XVG4Vi233U3clTyhsY7azEk/ubzULIazB9mP5ZEG3v171bKgyrrgFcMjxBOU5pNJ
U0z42SNUADgOLI4GLw9UwvljwdORNosgH4a388vSG4tkUQcP9dkRNY4Ul2Oa5jV0
gd07DJ4CZOPzspfVRFJ7FtSCivCVPALCr6hvXBj+thpSGFMSKlyQ1OlEsUpApJ4O
s10487u0F1+QukphsjCp23ttkET+TbjpSyZLCK9DLIeR3rvgp4o/cqQ9TPBEE8F3
xel06ugijIt31fBM4Hb5wfFhWcphXzEnOaUZcnN+oojiGXGXXGru6pTfeUctmE/D
zLW7YInl+rWcUm69wJt5jz/h4u/zd/anogopQT/ifWdD8HhJluUX1GAPCqDJ3Bzq
HjHwCMIjxK3bXT86e03U3F0/VHjX/F42GUGmXW+sqKWispgCDyBWxYbTQ2+pPUxI
h6lzsMapov//4AYg3Tpwx7COBcIMuXbUquIP2AnChBFt5ZcOv5+w4r/5E7eMiKJ5
p3dKqAKbRTmq3uc0HB0ylxs20ORqbQMZFBTsJ+Ntu7eP8IMyKj7VKW/5xb1q+uom
w4QfV+KrcZtmlZ60puDC
=A4qa
-----END PGP SIGNATURE-----

--ae4IRf2AAiRSmt6liaxUrJtTPeC8K8w8w--


--===============3438314843841265013==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3438314843841265013==--


From xen-devel-bounces@lists.xen.org Mon Dec 08 11:24:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 11:24:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxwQn-00036R-Bs; Mon, 08 Dec 2014 11:24:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XxwQm-00036J-Rk
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 11:24:44 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	5F/8B-23865-B7A85845; Mon, 08 Dec 2014 11:24:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418037882!9331474!1
X-Originating-IP: [66.165.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 21202 invoked from network); 8 Dec 2014 11:24:43 -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;
	8 Dec 2014 11:24:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201743969"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 06:24: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 1XxwQF-0007Bt-OO;
	Mon, 08 Dec 2014 11:24:11 +0000
Date: Mon, 8 Dec 2014 11:24:11 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Message-ID: <20141208112411.GD17128@zion.uk.xensource.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
	<20141208111214.GC17128@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141208111214.GC17128@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian.Campbell@citrix.com,
	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, Dec 08, 2014 at 11:12:14AM +0000, Wei Liu wrote:
> On Mon, Dec 08, 2014 at 12:34:47AM -0700, Chun Yan Liu wrote:
> > 
> > 
> > >>> On 12/6/2014 at 12:06 AM, in message
> > <20141205160615.GA24938@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
> > wrote: 
> > > I have to admit I'm confused by the back and forth discussion. It's hard 
> > > to justify the design of new API without knowing what the constraints 
> > > and requirements are from your PoV. 
> > >  
> > > Here are my two cents, not about details, but about general constraints. 
> > >  
> > > There are two layers, one is user of libxl (clients -- xl, libvirt etc) 
> > > and libxl (the library itself). 
> > >  
> > > 1. it's better to *not* have storage management in libxl. 
> > >  
> > > It's likely that clients can have their own management functionality 
> > > already.  I'm told that libvirt has that as well as XAPI. Having this 
> > > functionality in libxl is a bit redundant and requires lots of work 
> > > (enlighten libxl on what a disk looks like and call out to various 
> > > utilities). 
> > 
> > Thanks Wei and Ian for your reply. We did have much discussion around
> > can/cannot (e.g. xl can finish disk snapshot?) and should/shouldnot
> > (e.g. disk snapshot process should not in xl? domain_snapshot_delete
> > should not in libxl?), and confusing because have different ideas. So,
> > settling it down is helpful.
> > 
> > Talking about libvirt, it does provide storage management but through
> > storage pools and volumes. But usually, we don't use storage pool/vol
> > but directly use backend files, then libvirt storage driver can not
> > manage them. And for libvirt vol, functionality in storage driver is
> > limited, at least 'snapshot' cannot be done. So, libvirt side also
> > needs to add codes to handle disk snapshot, quite like xl does.
> > 
> 
> OK, so I take it that libvirt can be completely out the picture? I mean,
> it's not a requirement for you to integrate with libvirt?
> 
> I was thinking a stack like this when I replied:
> 
>   libvirt: manages snapshot (including storage snapshot)
>   libxl
>   [other lower level stuffs]
> 
> While I read from your reply, libvirt doesn't have that functionality
> (or very limited), so you would like to do things like:
> 
>   libvirt (or your homebrew toolstack)
>   xl      (xl or libxl manages domain snapshots)
>   libxl
>   [other lower level stuffs]
> 

Note, I'm in no way endorsing this approach. This is my understanding
(or misunderstanding) of what you intended to do. I started drawing
pictures so that we can understand each other better.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 11:24:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 11:24:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxwQn-00036R-Bs; Mon, 08 Dec 2014 11:24:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XxwQm-00036J-Rk
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 11:24:44 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	5F/8B-23865-B7A85845; Mon, 08 Dec 2014 11:24:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418037882!9331474!1
X-Originating-IP: [66.165.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 21202 invoked from network); 8 Dec 2014 11:24:43 -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;
	8 Dec 2014 11:24:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201743969"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 06:24: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 1XxwQF-0007Bt-OO;
	Mon, 08 Dec 2014 11:24:11 +0000
Date: Mon, 8 Dec 2014 11:24:11 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Message-ID: <20141208112411.GD17128@zion.uk.xensource.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
	<20141208111214.GC17128@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141208111214.GC17128@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian.Campbell@citrix.com,
	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, Dec 08, 2014 at 11:12:14AM +0000, Wei Liu wrote:
> On Mon, Dec 08, 2014 at 12:34:47AM -0700, Chun Yan Liu wrote:
> > 
> > 
> > >>> On 12/6/2014 at 12:06 AM, in message
> > <20141205160615.GA24938@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
> > wrote: 
> > > I have to admit I'm confused by the back and forth discussion. It's hard 
> > > to justify the design of new API without knowing what the constraints 
> > > and requirements are from your PoV. 
> > >  
> > > Here are my two cents, not about details, but about general constraints. 
> > >  
> > > There are two layers, one is user of libxl (clients -- xl, libvirt etc) 
> > > and libxl (the library itself). 
> > >  
> > > 1. it's better to *not* have storage management in libxl. 
> > >  
> > > It's likely that clients can have their own management functionality 
> > > already.  I'm told that libvirt has that as well as XAPI. Having this 
> > > functionality in libxl is a bit redundant and requires lots of work 
> > > (enlighten libxl on what a disk looks like and call out to various 
> > > utilities). 
> > 
> > Thanks Wei and Ian for your reply. We did have much discussion around
> > can/cannot (e.g. xl can finish disk snapshot?) and should/shouldnot
> > (e.g. disk snapshot process should not in xl? domain_snapshot_delete
> > should not in libxl?), and confusing because have different ideas. So,
> > settling it down is helpful.
> > 
> > Talking about libvirt, it does provide storage management but through
> > storage pools and volumes. But usually, we don't use storage pool/vol
> > but directly use backend files, then libvirt storage driver can not
> > manage them. And for libvirt vol, functionality in storage driver is
> > limited, at least 'snapshot' cannot be done. So, libvirt side also
> > needs to add codes to handle disk snapshot, quite like xl does.
> > 
> 
> OK, so I take it that libvirt can be completely out the picture? I mean,
> it's not a requirement for you to integrate with libvirt?
> 
> I was thinking a stack like this when I replied:
> 
>   libvirt: manages snapshot (including storage snapshot)
>   libxl
>   [other lower level stuffs]
> 
> While I read from your reply, libvirt doesn't have that functionality
> (or very limited), so you would like to do things like:
> 
>   libvirt (or your homebrew toolstack)
>   xl      (xl or libxl manages domain snapshots)
>   libxl
>   [other lower level stuffs]
> 

Note, I'm in no way endorsing this approach. This is my understanding
(or misunderstanding) of what you intended to do. I started drawing
pictures so that we can understand each other better.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 11:31:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 11: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 1XxwX3-0003Ga-7M; Mon, 08 Dec 2014 11:31:13 +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 1XxwX2-0003GV-DA
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 11:31:12 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	32/43-27785-FFB85845; Mon, 08 Dec 2014 11:31:11 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418038269!13665864!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 32482 invoked from network); 8 Dec 2014 11:31:11 -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;
	8 Dec 2014 11:31:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201745782"
Message-ID: <54858BFC.2020906@citrix.com>
Date: Mon, 8 Dec 2014 11:31:08 +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: Stefan Bader <stefan.bader@canonical.com>, <xen-devel@lists.xen.org>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>	<547C2CFC.7060908@canonical.com>	<20141208101936.GA7491@hercules>	<54858753.1070801@citrix.com>
	<548589B0.8050608@canonical.com>
In-Reply-To: <548589B0.8050608@canonical.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 11:21, Stefan Bader wrote:
> On 08.12.2014 12:11, David Vrabel wrote:
>> On 08/12/14 10:19, Luis Henriques wrote:
>>> On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
>>>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>>>> There is a long known problem with the netfront/netback interface: if the guest
>>>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
>>>>> it gets dropped. The reason is that netback maps these slots to a frag in the
>>>>> frags array, which is limited by size. Having so many slots can occur since
>>>>> compound pages were introduced, as the ring protocol slice them up into
>>>>> individual (non-compound) page aligned slots. The theoretical worst case
>>>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
>>>>> using 2 slots
>>>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
>>>>> end and the beginning of a page, therefore they use 3 * 15 = 45 slots
>>>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
>>>>> Although I don't think this 51 slots skb can really happen, we need a solution
>>>>> which can deal with every scenario. In real life there is only a few slots
>>>>> overdue, but usually it causes the TCP stream to be blocked, as the retry will
>>>>> most likely have the same buffer layout.
>>>>> This patch solves this problem by linearizing the packet. This is not the
>>>>> fastest way, and it can fail much easier as it tries to allocate a big linear
>>>>> area for the whole packet, but probably easier by an order of magnitude than
>>>>> anything else. Probably this code path is not touched very frequently anyway.
>>>>>
>>>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>>>> Cc: netdev@vger.kernel.org
>>>>> Cc: linux-kernel@vger.kernel.org
>>>>> Cc: xen-devel@lists.xenproject.org
>>>>
>>>> This does not seem to be marked explicitly as stable. Has someone already asked
>>>> David Miller to put it on his stable queue? IMO it qualifies quite well and the
>>>> actual change should be simple to pick/backport.
>>>>
>>>
>>> Thank you Stefan, I'm queuing this for the next 3.16 kernel release.
>>
>> Don't backport this yes.  It's broken.  It produces malformed requests
>> and netback will report a fatal error and stop all traffic on the VIF.
> 
> Thanks David. Did this just come up? I don't remember seeing any report of the
> regression. :/

There's been a couple of reports on xen-devel recently with 3.17
frontends and I've just repro'd it (by always forcing a skb_linearize()
in netfront).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 11:31:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 11: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 1XxwX3-0003Ga-7M; Mon, 08 Dec 2014 11:31:13 +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 1XxwX2-0003GV-DA
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 11:31:12 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	32/43-27785-FFB85845; Mon, 08 Dec 2014 11:31:11 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418038269!13665864!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 32482 invoked from network); 8 Dec 2014 11:31:11 -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;
	8 Dec 2014 11:31:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201745782"
Message-ID: <54858BFC.2020906@citrix.com>
Date: Mon, 8 Dec 2014 11:31:08 +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: Stefan Bader <stefan.bader@canonical.com>, <xen-devel@lists.xen.org>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>	<547C2CFC.7060908@canonical.com>	<20141208101936.GA7491@hercules>	<54858753.1070801@citrix.com>
	<548589B0.8050608@canonical.com>
In-Reply-To: <548589B0.8050608@canonical.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 11:21, Stefan Bader wrote:
> On 08.12.2014 12:11, David Vrabel wrote:
>> On 08/12/14 10:19, Luis Henriques wrote:
>>> On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
>>>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>>>> There is a long known problem with the netfront/netback interface: if the guest
>>>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
>>>>> it gets dropped. The reason is that netback maps these slots to a frag in the
>>>>> frags array, which is limited by size. Having so many slots can occur since
>>>>> compound pages were introduced, as the ring protocol slice them up into
>>>>> individual (non-compound) page aligned slots. The theoretical worst case
>>>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
>>>>> using 2 slots
>>>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
>>>>> end and the beginning of a page, therefore they use 3 * 15 = 45 slots
>>>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
>>>>> Although I don't think this 51 slots skb can really happen, we need a solution
>>>>> which can deal with every scenario. In real life there is only a few slots
>>>>> overdue, but usually it causes the TCP stream to be blocked, as the retry will
>>>>> most likely have the same buffer layout.
>>>>> This patch solves this problem by linearizing the packet. This is not the
>>>>> fastest way, and it can fail much easier as it tries to allocate a big linear
>>>>> area for the whole packet, but probably easier by an order of magnitude than
>>>>> anything else. Probably this code path is not touched very frequently anyway.
>>>>>
>>>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>>>> Cc: netdev@vger.kernel.org
>>>>> Cc: linux-kernel@vger.kernel.org
>>>>> Cc: xen-devel@lists.xenproject.org
>>>>
>>>> This does not seem to be marked explicitly as stable. Has someone already asked
>>>> David Miller to put it on his stable queue? IMO it qualifies quite well and the
>>>> actual change should be simple to pick/backport.
>>>>
>>>
>>> Thank you Stefan, I'm queuing this for the next 3.16 kernel release.
>>
>> Don't backport this yes.  It's broken.  It produces malformed requests
>> and netback will report a fatal error and stop all traffic on the VIF.
> 
> Thanks David. Did this just come up? I don't remember seeing any report of the
> regression. :/

There's been a couple of reports on xen-devel recently with 3.17
frontends and I've just repro'd it (by always forcing a skb_linearize()
in netfront).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 11:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1Xxwpe-0003tp-6l; Mon, 08 Dec 2014 11:50: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 1Xxwpc-0003tk-IA
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 11:50:24 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	3F/FC-23865-F7095845; Mon, 08 Dec 2014 11:50:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418039423!11783533!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19628 invoked from network); 8 Dec 2014 11:50:23 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 11:50:23 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so6040130wgh.2
	for <xen-devel@lists.xenproject.org>;
	Mon, 08 Dec 2014 03:50: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=V51JjidhbvJFGL9RccVQwkwXsAE9Mxvu6moS/ywzVaA=;
	b=OwUhVemUAEXo45Y34TBI91k1oO4yhVR/UmF4PVbzRACy+kf6Yxl8gmRqkH/EC1siPC
	tDCNX6cWfrp1rQZalAHt3yn/K0TSowVafG4/+LlfZJ0GiJAo19s1l58WYPY1FYi3lS61
	Cz8OTCGyR1SQpsS2RTh0EcGD7yQceSOOMmAXeL9fyWAYfgNQ9HI1aXpOlJ/g8cGpHW+q
	oGlJIs7eVLM7IfzP45ize4hw1ZCySWM5ehDObx2wO+X8+3r63Yb92xzMgJ/dWbORuaVT
	gTPA/qKyMxb2rAmFiQS6stKffpfAmQnIv5xLmueQ4N00BBmPSkt1zX2/guAOWrDGlfm6
	kFfA==
X-Gm-Message-State: ALoCoQlpwavWOwUzRtNQ4OGjxyn40uD5L71Qth/H+BRVkv0R3hoFrLFXDfh54qamF/ChF1oXWZja
X-Received: by 10.194.185.68 with SMTP id fa4mr43543021wjc.83.1418039422688;
	Mon, 08 Dec 2014 03:50:22 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id mw7sm9485444wib.14.2014.12.08.03.50.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 08 Dec 2014 03:50:22 -0800 (PST)
Message-ID: <5485907A.2060208@linaro.org>
Date: Mon, 08 Dec 2014 11:50:18 +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: Jan Beulich <JBeulich@suse.com>
References: <5481F18C020000780004D535@mail.emea.novell.com>
	<54824832.9000607@linaro.org>
	<548574ED020000780004D9D9@mail.emea.novell.com>
In-Reply-To: <548574ED020000780004D9D9@mail.emea.novell.com>
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/12/14 08:52, Jan Beulich wrote:
>>>> On 06.12.14 at 01:05, <julien.grall@linaro.org> wrote:
>> On 05/12/2014 16:55, Jan Beulich wrote:
>>   > I didn't change ARM, as I wasn't sure how far ahead this call could be
>>> pulled.
>>
>> AFAIU, the new function only requires that the page table are setup 
>> (because of the alloc_xenheap_pages).
>>
>> So console_init_mem could be called right after console_init_preirq.
> 
> No, it requires that alloc_xenheap_pages() works, i.e. it surely can't
> be placed before the end_boot_allocator() invocation.

Which is the case with the place I was suggesting...

On ARM, end_boot_allocator is called in setup_mm which is called before
console_init_preirq.

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 Dec 08 11:50:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1Xxwpe-0003tp-6l; Mon, 08 Dec 2014 11:50: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 1Xxwpc-0003tk-IA
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 11:50:24 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	3F/FC-23865-F7095845; Mon, 08 Dec 2014 11:50:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418039423!11783533!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19628 invoked from network); 8 Dec 2014 11:50:23 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 11:50:23 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so6040130wgh.2
	for <xen-devel@lists.xenproject.org>;
	Mon, 08 Dec 2014 03:50: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=V51JjidhbvJFGL9RccVQwkwXsAE9Mxvu6moS/ywzVaA=;
	b=OwUhVemUAEXo45Y34TBI91k1oO4yhVR/UmF4PVbzRACy+kf6Yxl8gmRqkH/EC1siPC
	tDCNX6cWfrp1rQZalAHt3yn/K0TSowVafG4/+LlfZJ0GiJAo19s1l58WYPY1FYi3lS61
	Cz8OTCGyR1SQpsS2RTh0EcGD7yQceSOOMmAXeL9fyWAYfgNQ9HI1aXpOlJ/g8cGpHW+q
	oGlJIs7eVLM7IfzP45ize4hw1ZCySWM5ehDObx2wO+X8+3r63Yb92xzMgJ/dWbORuaVT
	gTPA/qKyMxb2rAmFiQS6stKffpfAmQnIv5xLmueQ4N00BBmPSkt1zX2/guAOWrDGlfm6
	kFfA==
X-Gm-Message-State: ALoCoQlpwavWOwUzRtNQ4OGjxyn40uD5L71Qth/H+BRVkv0R3hoFrLFXDfh54qamF/ChF1oXWZja
X-Received: by 10.194.185.68 with SMTP id fa4mr43543021wjc.83.1418039422688;
	Mon, 08 Dec 2014 03:50:22 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id mw7sm9485444wib.14.2014.12.08.03.50.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 08 Dec 2014 03:50:22 -0800 (PST)
Message-ID: <5485907A.2060208@linaro.org>
Date: Mon, 08 Dec 2014 11:50:18 +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: Jan Beulich <JBeulich@suse.com>
References: <5481F18C020000780004D535@mail.emea.novell.com>
	<54824832.9000607@linaro.org>
	<548574ED020000780004D9D9@mail.emea.novell.com>
In-Reply-To: <548574ED020000780004D9D9@mail.emea.novell.com>
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/12/14 08:52, Jan Beulich wrote:
>>>> On 06.12.14 at 01:05, <julien.grall@linaro.org> wrote:
>> On 05/12/2014 16:55, Jan Beulich wrote:
>>   > I didn't change ARM, as I wasn't sure how far ahead this call could be
>>> pulled.
>>
>> AFAIU, the new function only requires that the page table are setup 
>> (because of the alloc_xenheap_pages).
>>
>> So console_init_mem could be called right after console_init_preirq.
> 
> No, it requires that alloc_xenheap_pages() works, i.e. it surely can't
> be placed before the end_boot_allocator() invocation.

Which is the case with the place I was suggesting...

On ARM, end_boot_allocator is called in setup_mm which is called before
console_init_preirq.

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 Dec 08 12:00:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12:00:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxwz6-0004MK-TH; Mon, 08 Dec 2014 12:00:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xxwz4-0004M2-Rt
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 12:00:10 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	56/37-01660-AC295845; Mon, 08 Dec 2014 12:00:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418040007!12157975!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16208 invoked from network); 8 Dec 2014 12:00:09 -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;
	8 Dec 2014 12:00:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201355876"
Message-ID: <1418039984.30016.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>, Jim Fehlig <jfehlig@suse.com>
Date: Mon, 8 Dec 2014 11:59:44 +0000
In-Reply-To: <1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<1417797006-27963-2-git-send-email-anthony.perard@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, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 16:30 +0000, Anthony PERARD wrote:

Jim Fehlig maintains the libxl driver in libvirt, so you should CC him
(I've done so here...)

> The path to the pty of a Xen PV console is set only in
> virDomainOpenConsole. But this is done too late. A call to
> virDomainGetXMLDesc done before OpenConsole will not have the path to
> the pty, but a call after OpenConsole will.
> 
> e.g. of the current issue.
> Starting a domain with '<console type="pty"/>'
> Then:
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty'>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> virDomainOpenConsole()
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty' tty='/dev/pts/30'>
>       <source path='/dev/pts/30'/>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> 
> The patch intend to get the tty path on the first call of GetXMLDesc.

Doesn't it actually do it on domain start (which makes more sense to me
anyway).

> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  src/libxl/libxl_domain.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 9c62291..de56054 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
>      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
>          goto cleanup_dom;
>  
> +    if (vm->def->nconsoles) {
> +        virDomainChrDefPtr chr = NULL;
> +        chr = vm->def->consoles[0];
> +        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
> +            libxl_console_type console_type;
> +            char *console = NULL;
> +            console_type =
> +                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
> +                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
> +            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
> +                                        console_type, &console);
> +            if (!ret)
> +                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));

libxlDomainOpenConsole will strdup another (well, probably the same)
value here, causing a leak I think, so you'll need some check there too
I expect.

> +            VIR_FREE(console);
> +        }
> +    }
> +
>      if (!start_paused) {
>          libxl_domain_unpause(priv->ctx, domid);
>          virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 12:00:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12:00:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxwz6-0004MK-TH; Mon, 08 Dec 2014 12:00:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xxwz4-0004M2-Rt
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 12:00:10 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	56/37-01660-AC295845; Mon, 08 Dec 2014 12:00:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418040007!12157975!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16208 invoked from network); 8 Dec 2014 12:00:09 -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;
	8 Dec 2014 12:00:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201355876"
Message-ID: <1418039984.30016.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>, Jim Fehlig <jfehlig@suse.com>
Date: Mon, 8 Dec 2014 11:59:44 +0000
In-Reply-To: <1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<1417797006-27963-2-git-send-email-anthony.perard@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, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 16:30 +0000, Anthony PERARD wrote:

Jim Fehlig maintains the libxl driver in libvirt, so you should CC him
(I've done so here...)

> The path to the pty of a Xen PV console is set only in
> virDomainOpenConsole. But this is done too late. A call to
> virDomainGetXMLDesc done before OpenConsole will not have the path to
> the pty, but a call after OpenConsole will.
> 
> e.g. of the current issue.
> Starting a domain with '<console type="pty"/>'
> Then:
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty'>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> virDomainOpenConsole()
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty' tty='/dev/pts/30'>
>       <source path='/dev/pts/30'/>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> 
> The patch intend to get the tty path on the first call of GetXMLDesc.

Doesn't it actually do it on domain start (which makes more sense to me
anyway).

> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  src/libxl/libxl_domain.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 9c62291..de56054 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
>      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
>          goto cleanup_dom;
>  
> +    if (vm->def->nconsoles) {
> +        virDomainChrDefPtr chr = NULL;
> +        chr = vm->def->consoles[0];
> +        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
> +            libxl_console_type console_type;
> +            char *console = NULL;
> +            console_type =
> +                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
> +                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
> +            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
> +                                        console_type, &console);
> +            if (!ret)
> +                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));

libxlDomainOpenConsole will strdup another (well, probably the same)
value here, causing a leak I think, so you'll need some check there too
I expect.

> +            VIR_FREE(console);
> +        }
> +    }
> +
>      if (!start_paused) {
>          libxl_domain_unpause(priv->ctx, domid);
>          virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 12:02:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12: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 1Xxx1Z-0004XK-FN; Mon, 08 Dec 2014 12:02:45 +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 1Xxx1Y-0004XF-Mz
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 12:02:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	1C/92-09842-46395845; Mon, 08 Dec 2014 12:02:44 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418040163!14157054!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5901 invoked from network); 8 Dec 2014 12:02:43 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 12:02:43 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so4551852wiv.2
	for <xen-devel@lists.xen.org>; Mon, 08 Dec 2014 04:02: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=fNi84uEDHT8tXdhtlql35XhAvLuJO/7wQ/0wX0PbfTE=;
	b=mrFQKSLan5S+I+v+VHfeT2KKJ/7KXiK0jgNQLUa7AtVzTWglBxJIXyI7qksduliwCy
	OJacvY/I34H7x7BzLda1PVdp8jryesvUi8YBFDlTy1a52sC83FeMJOJB7/I1o09AYShT
	hz04ouc0gHle4XC2Xg+yP4AhPlpUM69BtUjE7cJpa/PXsAcWrQYvyI/e7B4PaoNNgm3d
	nP1eJrRKLxd6pN6xB1W4RRrQ7Dy+jNkYzDkByFcvV+ZT1+K3+O4ZnNKZMMHlCQGNUSAB
	ztfoj5ozSj9BiXpzJ+P+YoGF6WK1/uZtrZEwW0kbfvT7yL3ynpWDOzWsJSHLC3gczTLu
	nV3Q==
X-Gm-Message-State: ALoCoQlG76ogWToDFjWJEgwCdMtO2TysggasuArZqwmMye8hxAWkJ9GWRGXlVyY9nfJVVa7Nz7LF
X-Received: by 10.180.82.170 with SMTP id j10mr23838197wiy.35.1418040163374;
	Mon, 08 Dec 2014 04:02:43 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id u9sm56355814wjy.37.2014.12.08.04.02.42
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 08 Dec 2014 04:02:42 -0800 (PST)
Message-ID: <5485935E.4070103@linaro.org>
Date: Mon, 08 Dec 2014 12:02:38 +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: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
References: <1417787196-3313-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<5481BF35.2060800@linaro.org>
	<CAN58jiuXwHNhQ+t27djHpH=EPhQs-D0uQ-bqxGpG0OBRK+BVLQ@mail.gmail.com>
In-Reply-To: <CAN58jiuXwHNhQ+t27djHpH=EPhQs-D0uQ-bqxGpG0OBRK+BVLQ@mail.gmail.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Oleksandr,

Please avoid top-post.

On 08/12/14 06:34, Oleksandr Dmytryshyn wrote:
> In our case We've added an additional fake node to the device tree with
> UART MMIO range for Xen and Xen mapped this MMIO range
> for the Kernel 3.8. By default UART has wrong configuration in OMAP.

Ok. So it has to be configured properly with Kernel 3.8 too. Your commit
message suggests it works without any kind of workaround on this kernel
version with Xen upstream.

Can you update 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 Dec 08 12:02:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12: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 1Xxx1Z-0004XK-FN; Mon, 08 Dec 2014 12:02:45 +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 1Xxx1Y-0004XF-Mz
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 12:02:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	1C/92-09842-46395845; Mon, 08 Dec 2014 12:02:44 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418040163!14157054!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5901 invoked from network); 8 Dec 2014 12:02:43 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 12:02:43 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so4551852wiv.2
	for <xen-devel@lists.xen.org>; Mon, 08 Dec 2014 04:02: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=fNi84uEDHT8tXdhtlql35XhAvLuJO/7wQ/0wX0PbfTE=;
	b=mrFQKSLan5S+I+v+VHfeT2KKJ/7KXiK0jgNQLUa7AtVzTWglBxJIXyI7qksduliwCy
	OJacvY/I34H7x7BzLda1PVdp8jryesvUi8YBFDlTy1a52sC83FeMJOJB7/I1o09AYShT
	hz04ouc0gHle4XC2Xg+yP4AhPlpUM69BtUjE7cJpa/PXsAcWrQYvyI/e7B4PaoNNgm3d
	nP1eJrRKLxd6pN6xB1W4RRrQ7Dy+jNkYzDkByFcvV+ZT1+K3+O4ZnNKZMMHlCQGNUSAB
	ztfoj5ozSj9BiXpzJ+P+YoGF6WK1/uZtrZEwW0kbfvT7yL3ynpWDOzWsJSHLC3gczTLu
	nV3Q==
X-Gm-Message-State: ALoCoQlG76ogWToDFjWJEgwCdMtO2TysggasuArZqwmMye8hxAWkJ9GWRGXlVyY9nfJVVa7Nz7LF
X-Received: by 10.180.82.170 with SMTP id j10mr23838197wiy.35.1418040163374;
	Mon, 08 Dec 2014 04:02:43 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id u9sm56355814wjy.37.2014.12.08.04.02.42
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 08 Dec 2014 04:02:42 -0800 (PST)
Message-ID: <5485935E.4070103@linaro.org>
Date: Mon, 08 Dec 2014 12:02:38 +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: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
References: <1417787196-3313-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<5481BF35.2060800@linaro.org>
	<CAN58jiuXwHNhQ+t27djHpH=EPhQs-D0uQ-bqxGpG0OBRK+BVLQ@mail.gmail.com>
In-Reply-To: <CAN58jiuXwHNhQ+t27djHpH=EPhQs-D0uQ-bqxGpG0OBRK+BVLQ@mail.gmail.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Oleksandr,

Please avoid top-post.

On 08/12/14 06:34, Oleksandr Dmytryshyn wrote:
> In our case We've added an additional fake node to the device tree with
> UART MMIO range for Xen and Xen mapped this MMIO range
> for the Kernel 3.8. By default UART has wrong configuration in OMAP.

Ok. So it has to be configured properly with Kernel 3.8 too. Your commit
message suggests it works without any kind of workaround on this kernel
version with Xen upstream.

Can you update 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 Dec 08 12:03:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12: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 1Xxx1u-0004a8-S4; Mon, 08 Dec 2014 12:03:06 +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 1Xxx1t-0004Zs-VT
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 12:03:06 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	B6/4E-02696-97395845; Mon, 08 Dec 2014 12:03:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418040183!13669184!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11911 invoked from network); 8 Dec 2014 12:03: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;
	8 Dec 2014 12:03:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201753478"
Message-ID: <54859375.30209@citrix.com>
Date: Mon, 8 Dec 2014 12:03:01 +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: Anthony Wright <anthony@overnetdata.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <5478926A.80503@overnetdata.com>
In-Reply-To: <5478926A.80503@overnetdata.com>
X-DLP: MIA1
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/14 15:19, Anthony Wright wrote:
> 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.

Does this patch to netfront fix it?

8<---------------------------------------------
xen-netfront: use correct linear area after linearizing an skb

Commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d (xen-netfront: Fix
handling packets on compound pages with skb_linearize) attempted to
fix a problem where an skb that would have required too many slots
would be dropped causing TCP connections to stall.

However, it filled in the first slot using the original buffer and not
the new one and would use the wrong offset and grant access to the
wrong page.

Netback would notice the malformed request and stop all traffic on the
VIF, reporting:

    vif vif-3-0 vif3.0: txreq.offset: 85e, size: 4002, end: 6144
    vif vif-3-0 vif3.0: fatal error; disabling device

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netfront.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index ece8d18..eeed0ce 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -627,6 +627,9 @@ static int xennet_start_xmit(struct sk_buff *skb,
struct net_device *dev)
 				    slots, skb->len);
 		if (skb_linearize(skb))
 			goto drop;
+		data = skb->data;
+		offset = offset_in_page(data);
+		len = skb_headlen(skb);
 	}

 	spin_lock_irqsave(&queue->tx_lock, flags);
-- 
1.7.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 Dec 08 12:03:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12: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 1Xxx1u-0004a8-S4; Mon, 08 Dec 2014 12:03:06 +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 1Xxx1t-0004Zs-VT
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 12:03:06 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	B6/4E-02696-97395845; Mon, 08 Dec 2014 12:03:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418040183!13669184!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11911 invoked from network); 8 Dec 2014 12:03: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;
	8 Dec 2014 12:03:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201753478"
Message-ID: <54859375.30209@citrix.com>
Date: Mon, 8 Dec 2014 12:03:01 +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: Anthony Wright <anthony@overnetdata.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
References: <5478926A.80503@overnetdata.com>
In-Reply-To: <5478926A.80503@overnetdata.com>
X-DLP: MIA1
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/14 15:19, Anthony Wright wrote:
> 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.

Does this patch to netfront fix it?

8<---------------------------------------------
xen-netfront: use correct linear area after linearizing an skb

Commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d (xen-netfront: Fix
handling packets on compound pages with skb_linearize) attempted to
fix a problem where an skb that would have required too many slots
would be dropped causing TCP connections to stall.

However, it filled in the first slot using the original buffer and not
the new one and would use the wrong offset and grant access to the
wrong page.

Netback would notice the malformed request and stop all traffic on the
VIF, reporting:

    vif vif-3-0 vif3.0: txreq.offset: 85e, size: 4002, end: 6144
    vif vif-3-0 vif3.0: fatal error; disabling device

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netfront.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index ece8d18..eeed0ce 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -627,6 +627,9 @@ static int xennet_start_xmit(struct sk_buff *skb,
struct net_device *dev)
 				    slots, skb->len);
 		if (skb_linearize(skb))
 			goto drop;
+		data = skb->data;
+		offset = offset_in_page(data);
+		len = skb_headlen(skb);
 	}

 	spin_lock_irqsave(&queue->tx_lock, flags);
-- 
1.7.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 Dec 08 12:10:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12: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 1Xxx8P-000550-CC; Mon, 08 Dec 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 <iwj@xenbits.xen.org>)
	id 1Xxx8N-00054b-2R; Mon, 08 Dec 2014 12:09:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A8/81-25276-A0595845; Mon, 08 Dec 2014 12:09:46 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418040584!14139902!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30454 invoked from network); 8 Dec 2014 12:09:44 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Dec 2014 12:09:44 -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 1Xxx8D-0007o2-PP; Mon, 08 Dec 2014 12:09:37 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1Xxx8D-0000BD-C9; Mon, 08 Dec 2014 12:09:37 +0000
Date: Mon, 08 Dec 2014 12:09:37 +0000
Message-Id: <E1Xxx8D-0000BD-C9@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 114 (CVE-2014-9065,
 CVE-2014-9066) - p2m lock starvation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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-9065,CVE-2014-9066 / XSA-114
                              version 3

                       p2m lock starvation

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

The current read/write lock implementation is read-biased, which allows
a consistent stream of readers to starve writers indefinitely.  There
are certain rwlocks where guests are capable of applying arbitrary read
pressure.

IMPACT
======

A malicious guest administrator can deny service to other tasks.  If
the NMI watchdog is active, a timeout might be triggered, resulting in
a host crash.

VULNERABLE SYSTEMS
==================

Xen 4.2 and later systems are vulnerable.

Xen 4.1 and earlier are not vulnerable in normal configurations.  4.1
and earlier are vulnerable only insofar as features are used which
have already been explicitly discounted for security support purposes
(TMEM, see XSA-15; XSM-based radical disaggregation, see XSA-77).

Only x86 systems offer avenues for attacking this vulnerability.
ARM systems do not and are therefore not vulnerable.

MITIGATION
==========

There is no mitigation available for this issue.

CREDITS
=======

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue in
practice for most systems.  (CVE-2014-9065 refers to these fixed
cases.)

In some deployments, large guests (more than around 30-40 VCPUs) may
still be able to trigger intermittent problems; a complete fix to this
issue requires substantial structural changes and is planned for Xen
4.6.  (CVE-2014-9066 refers to these yet-to-be-fixed cases.)

xsa114.patch                 xen-unstable
xsa114-4.4.patch             Xen 4.4.x
xsa114-4.3.patch             Xen 4.3.x
xsa114-4.2.patch             Xen 4.2.x

$ sha256sum xsa114*.patch
d1c1a2d5d55bfe13ba99a9cb99b367a29389aa30f13ffacc02b465a006115b45  xsa114.patch
a7a57c49d65de7e3cd480476b0a935ddac9e9d941aa6ca65e87170411a7c1176  xsa114-4.2.patch
ae787074b857c40ab0059802846cb0152e24c937486968c769a9bfe8cbe3d10f  xsa114-4.3.patch
b35ed8710693163cc33772c36e4c17dc76e25a0b2025fff4a5aa3b46c459938a  xsa114-4.4.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUhZTQAAoJEIP+FMlX6CvZYUkH/A/SYzqnOXvSa0tF7penNFb9
NFwRBjTvddaTnB72UiIL6ca/3tV1la2cNpn+p4M+cGSuCwHV9QaEoRMtc6l77Yol
I1ApyZWHS3Qwv2zKDp5dozDcO5yiVuVj+Az1O9f3NCv6PsQvJxYugB/3JKUnhS60
ItmlwnxAEzRd0pvoG8zb7vdLKPyfJ9gYTW3OU50F13TbJEtIJ1ifzvCTC7zPv7da
phYy7NClS9a1QeXOnwRNyoL8hBZ6OWJYxG66+8P/s0SUtvTOuOoVJ510cAwfv4Fw
y96Ss+vfTu9u34GBaO/rTP5FkH1x9vptFGTIgjtDPZmwf30kCo4qyq3jnjyWKmM=
=V6/o
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa114.patch"
Content-Disposition: attachment; filename="xsa114.patch"
Content-Transfer-Encoding: base64

c3dpdGNoIHRvIHdyaXRlLWJpYXNlZCByL3cgbG9ja3MKClRoaXMgaXMgdG8g
aW1wcm92ZSBmYWlybmVzczogQSBwZXJtYW5lbnQgZmxvdyBvZiByZWFkIGFj
cXVpcmVzIGNhbgpvdGhlcndpc2UgbG9jayBvdXQgZXZlbnR1YWwgd3JpdGVy
cyBpbmRlZmluaXRlbHkuCgpUaGlzIGlzIFhTQS0xMTQgLyBDVkUtMjAxNC05
MDY1LgoKU2lnbmVkLW9mZi1ieTogS2VpciBGcmFzZXIgPGtlaXJAeGVuLm9y
Zz4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4KUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIz
QGNpdHJpeC5jb20+CgpHaXZlbiB0aGF0IHRoaXMgcGF0Y2ggaXMgYmFzaWNh
bGx5ICJoZXJlIGFyZSBzb21lIGJyYW5kIG5ldyByd2xvY2tzIiwKdGhlIENp
dHJpeCBYZW5TZXJ2ZXIgdGVhbSwgd2hvIGFzc2lzdGVkIHdpdGggcGF0Y2gg
ZGV2ZWxvcG1lbnQgYW5kCnRlc3RpbmcsIGNhcnJpZWQgb3V0IHRoZWlyIGNv
bXBsZXRlIHN1aXRlIG9mIHBlcmZvcm1hbmNlIHRlc3RzLCBhbmQKdGFyZ2V0
ZWQgdGVzdGluZyBiYXNlZCBhcm91bmQgdGhlIGlzc3VlIHdoaWNoIHRyaWdn
ZXJlZCB0aGlzCmludmVzdGlnYXRpb24uICBObyByZWdyZXNzaW9ucyBvciBj
b25jZXJucyB3aXRoIHRoZSBwYXRjaCB3ZXJlCmlkZW50aWZpZWQuICAtQW5k
cmV3IENvb3Blci4KClRlc3RlZC1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT4KCi0tLSBhL3hlbi9jb21tb24vc3Bpbmxv
Y2suYworKysgYi94ZW4vY29tbW9uL3NwaW5sb2NrLmMKQEAgLTI3MSwxMTIg
KzI3MSwxNTEgQEAgdm9pZCBfc3Bpbl91bmxvY2tfcmVjdXJzaXZlKHNwaW5s
b2NrX3QgKgogCiB2b2lkIF9yZWFkX2xvY2socndsb2NrX3QgKmxvY2spCiB7
CisgICAgdWludDMyX3QgeDsKKwogICAgIGNoZWNrX2xvY2soJmxvY2stPmRl
YnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3JlYWRfdHJ5bG9j
aygmbG9jay0+cmF3KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtl
bHkoX3Jhd19yd19pc193cml0ZV9sb2NrZWQoJmxvY2stPnJhdykpICkKKyAg
ICBkbyB7CisgICAgICAgIHdoaWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJX
X1dSSVRFX0ZMQUcgKQogICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0gICAg
fQorICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEp
ICE9IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBf
cmVhZF9sb2NrX2lycShyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgQVNTRVJUKGxvY2FsX2lycV9pc19lbmFibGVkKCkpOwog
ICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CiAgICAgY2hlY2tfbG9jaygmbG9j
ay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtlbHkoIV9yYXdfcmVhZF90
cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewotICAgICAgICBsb2NhbF9p
cnFfZW5hYmxlKCk7Ci0gICAgICAgIHdoaWxlICggbGlrZWx5KF9yYXdfcndf
aXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5yYXcpKSApCi0gICAgICAgICAgICBj
cHVfcmVsYXgoKTsKLSAgICAgICAgbG9jYWxfaXJxX2Rpc2FibGUoKTsKLSAg
ICB9CisgICAgZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykg
JiBSV19XUklURV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxv
Y2stPmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAg
Y3B1X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfZGlzYWJsZSgp
OworICAgICAgICB9CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2stPmxv
Y2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgpOwog
fQogCiB1bnNpZ25lZCBsb25nIF9yZWFkX2xvY2tfaXJxc2F2ZShyd2xvY2tf
dCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4OwogICAgIHVuc2lnbmVkIGxv
bmcgZmxhZ3M7CisKICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7CiAgICAg
Y2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtl
bHkoIV9yYXdfcmVhZF90cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewot
ICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7Ci0gICAgICAgIHdo
aWxlICggbGlrZWx5KF9yYXdfcndfaXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5y
YXcpKSApCi0gICAgICAgICAgICBjcHVfcmVsYXgoKTsKLSAgICAgICAgbG9j
YWxfaXJxX3NhdmUoZmxhZ3MpOwotICAgIH0KKyAgICBkbyB7CisgICAgICAg
IGlmICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAg
ICAgICB7CisgICAgICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CisgICAgICAgICAgICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19X
UklURV9GTEFHICkKKyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAg
ICAgICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgfQor
ICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEpICE9
IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gZmxh
Z3M7CiB9CiAKIGludCBfcmVhZF90cnlsb2NrKHJ3bG9ja190ICpsb2NrKQog
eworICAgIHVpbnQzMl90IHg7CisKICAgICBjaGVja19sb2NrKCZsb2NrLT5k
ZWJ1Zyk7Ci0gICAgaWYgKCAhX3Jhd19yZWFkX3RyeWxvY2soJmxvY2stPnJh
dykgKQotICAgICAgICByZXR1cm4gMDsKKyAgICBkbyB7CisgICAgICAgIGlm
ICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAg
ICAgICAgcmV0dXJuIDA7CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2st
PmxvY2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgp
OwogICAgIHJldHVybiAxOwogfQogCiB2b2lkIF9yZWFkX3VubG9jayhyd2xv
Y2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4LCB5OworCiAgICAgcHJl
ZW1wdF9lbmFibGUoKTsKLSAgICBfcmF3X3JlYWRfdW5sb2NrKCZsb2NrLT5y
YXcpOworICAgIHggPSBsb2NrLT5sb2NrOworICAgIHdoaWxlICggKHkgPSBj
bXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4LTEpKSAhPSB4ICkKKyAgICAgICAg
eCA9IHk7CiB9CiAKIHZvaWQgX3JlYWRfdW5sb2NrX2lycShyd2xvY2tfdCAq
bG9jaykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfcmVh
ZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxvY2sp
OwogICAgIGxvY2FsX2lycV9lbmFibGUoKTsKIH0KIAogdm9pZCBfcmVhZF91
bmxvY2tfaXJxcmVzdG9yZShyd2xvY2tfdCAqbG9jaywgdW5zaWduZWQgbG9u
ZyBmbGFncykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdf
cmVhZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxv
Y2spOwogICAgIGxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKIH0KIAogdm9p
ZCBfd3JpdGVfbG9jayhyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdo
aWxlICggdW5saWtlbHkoIV9yYXdfd3JpdGVfdHJ5bG9jaygmbG9jay0+cmF3
KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtlbHkoX3Jhd19yd19p
c19sb2NrZWQoJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIHdo
aWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQogICAg
ICAgICAgICAgY3B1X3JlbGF4KCk7CisgICAgfSB3aGlsZSAoIGNtcHhjaGco
JmxvY2stPmxvY2ssIHgsIHh8UldfV1JJVEVfRkxBRykgIT0geCApOworICAg
IHdoaWxlICggeCAhPSAwICkKKyAgICB7CisgICAgICAgIGNwdV9yZWxheCgp
OworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5SV19XUklURV9GTEFHOwog
ICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBfd3Jp
dGVfbG9ja19pcnEocndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3Qg
eDsKKwogICAgIEFTU0VSVChsb2NhbF9pcnFfaXNfZW5hYmxlZCgpKTsKICAg
ICBsb2NhbF9pcnFfZGlzYWJsZSgpOwogICAgIGNoZWNrX2xvY2soJmxvY2st
PmRlYnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3dyaXRlX3Ry
eWxvY2soJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIGlmICgg
KHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAgICB7
CisgICAgICAgICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CisgICAgICAgICAg
ICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklURV9GTEFHICkK
KyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAgICAgICAgICAgIGxv
Y2FsX2lycV9kaXNhYmxlKCk7CisgICAgICAgIH0KKyAgICB9IHdoaWxlICgg
Y21weGNoZygmbG9jay0+bG9jaywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4
ICk7CisgICAgd2hpbGUgKCB4ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3
X3J3X2lzX2xvY2tlZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1
X3JlbGF4KCk7Ci0gICAgICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CisgICAg
ICAgIGNwdV9yZWxheCgpOworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5S
V19XUklURV9GTEFHOwogICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsK
IH0KIAogdW5zaWduZWQgbG9uZyBfd3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9j
a190ICpsb2NrKQogeworICAgIHVpbnQzMl90IHg7CiAgICAgdW5zaWduZWQg
bG9uZyBmbGFnczsKKwogICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKICAg
ICBjaGVja19sb2NrKCZsb2NrLT5kZWJ1Zyk7Ci0gICAgd2hpbGUgKCB1bmxp
a2VseSghX3Jhd193cml0ZV90cnlsb2NrKCZsb2NrLT5yYXcpKSApCisgICAg
ZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklU
RV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9jYWxfaXJxX3Jl
c3RvcmUoZmxhZ3MpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxvY2st
PmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAgY3B1
X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7
CisgICAgICAgIH0KKyAgICB9IHdoaWxlICggY21weGNoZygmbG9jay0+bG9j
aywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4ICk7CisgICAgd2hpbGUgKCB4
ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh
Z3MpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3X3J3X2lzX2xvY2tl
ZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0g
ICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgY3B1X3Jl
bGF4KCk7CisgICAgICAgIHggPSBsb2NrLT5sb2NrICYgflJXX1dSSVRFX0ZM
QUc7CiAgICAgfQogICAgIHByZWVtcHRfZGlzYWJsZSgpOwogICAgIHJldHVy
biBmbGFnczsKQEAgLTM4NCw5ICs0MjMsMTMgQEAgdW5zaWduZWQgbG9uZyBf
d3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9jawogCiBpbnQgX3dyaXRlX3RyeWxv
Y2socndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3QgeDsKKwogICAg
IGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICBpZiAoICFfcmF3X3dy
aXRlX3RyeWxvY2soJmxvY2stPnJhdykgKQotICAgICAgICByZXR1cm4gMDsK
KyAgICBkbyB7CisgICAgICAgIGlmICggKHggPSBsb2NrLT5sb2NrKSAhPSAw
ICkKKyAgICAgICAgICAgIHJldHVybiAwOworICAgIH0gd2hpbGUgKCBjbXB4
Y2hnKCZsb2NrLT5sb2NrLCB4LCB4fFJXX1dSSVRFX0ZMQUcpICE9IHggKTsK
ICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gMTsKIH0KQEAg
LTM5NCwzMyArNDM3LDMyIEBAIGludCBfd3JpdGVfdHJ5bG9jayhyd2xvY2tf
dCAqbG9jaykKIHZvaWQgX3dyaXRlX3VubG9jayhyd2xvY2tfdCAqbG9jaykK
IHsKICAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfd3JpdGVfdW5s
b2NrKCZsb2NrLT5yYXcpOworICAgIGlmICggY21weGNoZygmbG9jay0+bG9j
aywgUldfV1JJVEVfRkxBRywgMCkgIT0gUldfV1JJVEVfRkxBRyApCisgICAg
ICAgIEJVRygpOwogfQogCiB2b2lkIF93cml0ZV91bmxvY2tfaXJxKHJ3bG9j
a190ICpsb2NrKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0gICAgX3Jh
d193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRlX3VubG9j
ayhsb2NrKTsKICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CiB9CiAKIHZvaWQg
X3dyaXRlX3VubG9ja19pcnFyZXN0b3JlKHJ3bG9ja190ICpsb2NrLCB1bnNp
Z25lZCBsb25nIGZsYWdzKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0g
ICAgX3Jhd193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRl
X3VubG9jayhsb2NrKTsKICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CiB9CiAKIGludCBfcndfaXNfbG9ja2VkKHJ3bG9ja190ICpsb2NrKQogewog
ICAgIGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICByZXR1cm4gX3Jh
d19yd19pc19sb2NrZWQoJmxvY2stPnJhdyk7CisgICAgcmV0dXJuIChsb2Nr
LT5sb2NrICE9IDApOyAvKiBhbnlvbmUgaW4gY3JpdGljYWwgc2VjdGlvbj8g
Ki8KIH0KIAogaW50IF9yd19pc193cml0ZV9sb2NrZWQocndsb2NrX3QgKmxv
Y2spCiB7CiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHJl
dHVybiBfcmF3X3J3X2lzX3dyaXRlX2xvY2tlZCgmbG9jay0+cmF3KTsKKyAg
ICByZXR1cm4gKGxvY2stPmxvY2sgPT0gUldfV1JJVEVfRkxBRyk7IC8qIHdy
aXRlciBpbiBjcml0aWNhbCBzZWN0aW9uPyAqLwogfQogCiAjaWZkZWYgTE9D
S19QUk9GSUxFCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vYXJtMzIvc3Bp
bmxvY2suaAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2FybTMyL3NwaW5s
b2NrLmgKQEAgLTU1LDg0ICs1NSw2IEBAIHN0YXRpYyBhbHdheXNfaW5saW5l
IGludCBfcmF3X3NwaW5fdHJ5bG8KICAgICB9CiB9CiAKLXR5cGVkZWYgc3Ry
dWN0IHsKLSAgICB2b2xhdGlsZSB1bnNpZ25lZCBpbnQgbG9jazsKLX0gcmF3
X3J3bG9ja190OwotCi0jZGVmaW5lIF9SQVdfUldfTE9DS19VTkxPQ0tFRCB7
IDAgfQotCi1zdGF0aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd19yZWFkX3Ry
eWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNpZ25lZCBsb25n
IHRtcCwgdG1wMiA9IDE7Ci0KLSAgICBfX2FzbV9fIF9fdm9sYXRpbGVfXygK
LSIxOiBsZHJleCAgICUwLCBbJTJdXG4iCi0iICAgYWRkcyAgICAlMCwgJTAs
ICMxXG4iCi0iICAgc3RyZXhwbCAlMSwgJTAsIFslMl1cbiIKLSAgICA6ICI9
JnIiICh0bXApLCAiK3IiICh0bXAyKQotICAgIDogInIiICgmcnctPmxvY2sp
Ci0gICAgOiAiY2MiKTsKLQotICAgIHNtcF9tYigpOwotICAgIHJldHVybiB0
bXAyID09IDA7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3
X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNp
Z25lZCBsb25nIHRtcDsKLQotICAgIF9fYXNtX18gX192b2xhdGlsZV9fKAot
IjE6IGxkcmV4ICAgJTAsIFslMV1cbiIKLSIgICB0ZXEgICAgICUwLCAjMFxu
IgotIiAgIHN0cmV4ZXEgJTAsICUyLCBbJTFdIgotICAgIDogIj0mciIgKHRt
cCkKLSAgICA6ICJyIiAoJnJ3LT5sb2NrKSwgInIiICgweDgwMDAwMDAwKQot
ICAgIDogImNjIik7Ci0KLSAgICBpZiAodG1wID09IDApIHsKLSAgICAgICAg
c21wX21iKCk7Ci0gICAgICAgIHJldHVybiAxOwotICAgIH0gZWxzZSB7Ci0g
ICAgICAgIHJldHVybiAwOwotICAgIH0KLX0KLQotc3RhdGljIGlubGluZSB2
b2lkIF9yYXdfcmVhZF91bmxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAg
ICB1bnNpZ25lZCBsb25nIHRtcCwgdG1wMjsKLQotICAgIHNtcF9tYigpOwot
Ci0gICAgX19hc21fXyBfX3ZvbGF0aWxlX18oCi0iMTogbGRyZXggICAlMCwg
WyUyXVxuIgotIiAgIHN1YiAgICAgJTAsICUwLCAjMVxuIgotIiAgIHN0cmV4
ICAgJTEsICUwLCBbJTJdXG4iCi0iICAgdGVxICAgICAlMSwgIzBcbiIKLSIg
ICBibmUgICAgIDFiIgotICAgIDogIj0mciIgKHRtcCksICI9JnIiICh0bXAy
KQotICAgIDogInIiICgmcnctPmxvY2spCi0gICAgOiAiY2MiKTsKLQotICAg
IGlmICh0bXAgPT0gMCkKLSAgICAgICAgZHNiX3NldigpOwotfQotCi1zdGF0
aWMgaW5saW5lIHZvaWQgX3Jhd193cml0ZV91bmxvY2socmF3X3J3bG9ja190
ICpydykKLXsKLSAgICBzbXBfbWIoKTsKLQotICAgIF9fYXNtX18gX192b2xh
dGlsZV9fKAotICAgICJzdHIgICAgJTEsIFslMF1cbiIKLSAgICA6Ci0gICAg
OiAiciIgKCZydy0+bG9jayksICJyIiAoMCkKLSAgICA6ICJjYyIpOwotCi0g
ICAgZHNiX3NldigpOwotfQotCi0jZGVmaW5lIF9yYXdfcndfaXNfbG9ja2Vk
KHgpICgoeCktPmxvY2sgIT0gMCkKLSNkZWZpbmUgX3Jhd19yd19pc193cml0
ZV9sb2NrZWQoeCkgKCh4KS0+bG9jayA9PSAweDgwMDAwMDAwKQotCiAjZW5k
aWYgLyogX19BU01fU1BJTkxPQ0tfSCAqLwogLyoKICAqIExvY2FsIHZhcmlh
YmxlczoKLS0tIGEveGVuL2luY2x1ZGUvYXNtLWFybS9hcm02NC9zcGlubG9j
ay5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vYXJtNjQvc3BpbmxvY2su
aApAQCAtNTIsNjkgKzUyLDYgQEAgc3RhdGljIGFsd2F5c19pbmxpbmUgaW50
IF9yYXdfc3Bpbl90cnlsbwogICAgIHJldHVybiAhdG1wOwogfQogCi10eXBl
ZGVmIHN0cnVjdCB7Ci0gICAgdm9sYXRpbGUgdW5zaWduZWQgaW50IGxvY2s7
Ci19IHJhd19yd2xvY2tfdDsKLQotI2RlZmluZSBfUkFXX1JXX0xPQ0tfVU5M
T0NLRUQgeyAwIH0KLQotc3RhdGljIGFsd2F5c19pbmxpbmUgaW50IF9yYXdf
cmVhZF90cnlsb2NrKHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgdW5zaWdu
ZWQgaW50IHRtcCwgdG1wMiA9IDE7Ci0KLSAgICBhc20gdm9sYXRpbGUoCi0g
ICAgICAgICIgICAgICAgbGRheHIgICAldzAsICUyXG4iCi0gICAgICAgICIg
ICAgICAgYWRkICAgICAldzAsICV3MCwgIzFcbiIKLSAgICAgICAgIiAgICAg
ICB0Ym56ICAgICV3MCwgIzMxLCAxZlxuIgotICAgICAgICAiICAgICAgIHN0
eHIgICAgJXcxLCAldzAsICUyXG4iCi0gICAgICAgICIxOlxuIgotICAgICAg
ICA6ICI9JnIiICh0bXApLCAiK3IiICh0bXAyKSwgIitRIiAocnctPmxvY2sp
Ci0gICAgICAgIDoKLSAgICAgICAgOiAibWVtb3J5Iik7Ci0KLSAgICByZXR1
cm4gIXRtcDI7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3
X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNp
Z25lZCBpbnQgdG1wOwotCi0gICAgYXNtIHZvbGF0aWxlKAotICAgICAgICAi
ICAgICAgIGxkYXhyICAgJXcwLCAlMVxuIgotICAgICAgICAiICAgICAgIGNi
bnogICAgJXcwLCAxZlxuIgotICAgICAgICAiICAgICAgIHN0eHIgICAgJXcw
LCAldzIsICUxXG4iCi0gICAgICAgICIxOlxuIgotICAgICAgICA6ICI9JnIi
ICh0bXApLCAiK1EiIChydy0+bG9jaykKLSAgICAgICAgOiAiciIgKDB4ODAw
MDAwMDApCi0gICAgICAgIDogIm1lbW9yeSIpOwotCi0gICAgcmV0dXJuICF0
bXA7Ci19Ci0KLXN0YXRpYyBpbmxpbmUgdm9pZCBfcmF3X3JlYWRfdW5sb2Nr
KHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgdW5zaWduZWQgaW50IHRtcCwg
dG1wMjsKLQotICAgIGFzbSB2b2xhdGlsZSgKLSAgICAgICAgIiAgICAxOiBs
ZHhyICAgICV3MCwgJTJcbiIKLSAgICAgICAgIiAgICAgICBzdWIgICAgICV3
MCwgJXcwLCAjMVxuIgotICAgICAgICAiICAgICAgIHN0bHhyICAgJXcxLCAl
dzAsICUyXG4iCi0gICAgICAgICIgICAgICAgY2JueiAgICAldzEsIDFiXG4i
Ci0gICAgICAgIDogIj0mciIgKHRtcCksICI9JnIiICh0bXAyKSwgIitRIiAo
cnctPmxvY2spCi0gICAgICAgIDoKLSAgICAgICAgOiAibWVtb3J5Iik7Ci19
Ci0KLXN0YXRpYyBpbmxpbmUgdm9pZCBfcmF3X3dyaXRlX3VubG9jayhyYXdf
cndsb2NrX3QgKnJ3KQotewotICAgIGFzbSB2b2xhdGlsZSgKLSAgICAgICAg
IiAgICAgICBzdGxyICAgICV3MSwgJTBcbiIKLSAgICAgICAgOiAiPVEiIChy
dy0+bG9jaykgOiAiciIgKDApIDogIm1lbW9yeSIpOwotfQotCi0jZGVmaW5l
IF9yYXdfcndfaXNfbG9ja2VkKHgpICgoeCktPmxvY2sgIT0gMCkKLSNkZWZp
bmUgX3Jhd19yd19pc193cml0ZV9sb2NrZWQoeCkgKCh4KS0+bG9jayA9PSAw
eDgwMDAwMDAwKQotCiAjZW5kaWYgLyogX19BU01fU1BJTkxPQ0tfSCAqLwog
LyoKICAqIExvY2FsIHZhcmlhYmxlczoKLS0tIGEveGVuL2luY2x1ZGUvYXNt
LXg4Ni9zcGlubG9jay5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvc3Bp
bmxvY2suaApAQCAtMzEsNTggKzMxLDQgQEAgc3RhdGljIGFsd2F5c19pbmxp
bmUgaW50IF9yYXdfc3Bpbl90cnlsbwogICAgIHJldHVybiAob2xkdmFsID4g
MCk7CiB9CiAKLXR5cGVkZWYgc3RydWN0IHsKLSAgICB2b2xhdGlsZSBpbnQg
bG9jazsKLX0gcmF3X3J3bG9ja190OwotCi0jZGVmaW5lIFJXX1dSSVRFX0JJ
QVMgMHg3ZmZmZmZmZgotI2RlZmluZSBfUkFXX1JXX0xPQ0tfVU5MT0NLRUQg
LyoocmF3X3J3bG9ja190KSovIHsgMCB9Ci0KLXN0YXRpYyBhbHdheXNfaW5s
aW5lIGludCBfcmF3X3JlYWRfdHJ5bG9jayhyYXdfcndsb2NrX3QgKnJ3KQot
ewotICAgIGludCBhY3F1aXJlZDsKLQotICAgIGFzbSB2b2xhdGlsZSAoCi0g
ICAgICAgICIgICAgbG9jazsgZGVjbCAlMCAgICAgICAgIFxuIgotICAgICAg
ICAiICAgIGpucyAyZiAgICAgICAgICAgICAgICBcbiIKLSNpZmRlZiBfX2Ns
YW5nX18gLyogY2xhbmcncyBidWlsdGluIGFzc2VtYmVyIGNhbid0IGRvIC5z
dWJzZWN0aW9uICovCi0gICAgICAgICIxOiAgLnB1c2hzZWN0aW9uIC5maXh1
cCxcImF4XCJcbiIKLSNlbHNlCi0gICAgICAgICIxOiAgLnN1YnNlY3Rpb24g
MSAgICAgICAgIFxuIgotI2VuZGlmCi0gICAgICAgICIyOiAgbG9jazsgaW5j
bCAlMCAgICAgICAgIFxuIgotICAgICAgICAiICAgIGRlY2wgJTEgICAgICAg
ICAgICAgICBcbiIKLSAgICAgICAgIiAgICBqbXAgMWIgICAgICAgICAgICAg
ICAgXG4iCi0jaWZkZWYgX19jbGFuZ19fCi0gICAgICAgICIgICAgLnBvcHNl
Y3Rpb24gICAgICAgICAgIFxuIgotI2Vsc2UKLSAgICAgICAgIiAgICAuc3Vi
c2VjdGlvbiAwICAgICAgICAgXG4iCi0jZW5kaWYKLSAgICAgICAgOiAiPW0i
IChydy0+bG9jayksICI9ciIgKGFjcXVpcmVkKSA6ICIxIiAoMSkgOiAibWVt
b3J5IiApOwotCi0gICAgcmV0dXJuIGFjcXVpcmVkOwotfQotCi1zdGF0aWMg
YWx3YXlzX2lubGluZSBpbnQgX3Jhd193cml0ZV90cnlsb2NrKHJhd19yd2xv
Y2tfdCAqcncpCi17Ci0gICAgcmV0dXJuIChjbXB4Y2hnKCZydy0+bG9jaywg
MCwgUldfV1JJVEVfQklBUykgPT0gMCk7Ci19Ci0KLXN0YXRpYyBhbHdheXNf
aW5saW5lIHZvaWQgX3Jhd19yZWFkX3VubG9jayhyYXdfcndsb2NrX3QgKnJ3
KQotewotICAgIGFzbSB2b2xhdGlsZSAoCi0gICAgICAgICJsb2NrIDsgaW5j
bCAlMCIKLSAgICAgICAgOiAiPW0iICgocncpLT5sb2NrKSA6IDogIm1lbW9y
eSIgKTsKLX0KLQotc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBfcmF3X3dy
aXRlX3VubG9jayhyYXdfcndsb2NrX3QgKnJ3KQotewotICAgIGFzbSB2b2xh
dGlsZSAoCi0gICAgICAgICJsb2NrIDsgc3VibCAlMSwlMCIKLSAgICAgICAg
OiAiPW0iICgocncpLT5sb2NrKSA6ICJpIiAoUldfV1JJVEVfQklBUykgOiAi
bWVtb3J5IiApOwotfQotCi0jZGVmaW5lIF9yYXdfcndfaXNfbG9ja2VkKHgp
ICgoeCktPmxvY2sgIT0gMCkKLSNkZWZpbmUgX3Jhd19yd19pc193cml0ZV9s
b2NrZWQoeCkgKCh4KS0+bG9jayA+IDApCi0KICNlbmRpZiAvKiBfX0FTTV9T
UElOTE9DS19IICovCi0tLSBhL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9jay5o
CisrKyBiL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9jay5oCkBAIC0xNDEsMTEg
KzE0MSwxMyBAQCB0eXBlZGVmIHN0cnVjdCBzcGlubG9jayB7CiAjZGVmaW5l
IHNwaW5fbG9ja19pbml0KGwpICgqKGwpID0gKHNwaW5sb2NrX3QpU1BJTl9M
T0NLX1VOTE9DS0VEKQogCiB0eXBlZGVmIHN0cnVjdCB7Ci0gICAgcmF3X3J3
bG9ja190IHJhdzsKKyAgICB2b2xhdGlsZSB1aW50MzJfdCBsb2NrOwogICAg
IHN0cnVjdCBsb2NrX2RlYnVnIGRlYnVnOwogfSByd2xvY2tfdDsKIAotI2Rl
ZmluZSBSV19MT0NLX1VOTE9DS0VEIHsgX1JBV19SV19MT0NLX1VOTE9DS0VE
LCBfTE9DS19ERUJVRyB9CisjZGVmaW5lIFJXX1dSSVRFX0ZMQUcgKDF1PDwz
MSkKKworI2RlZmluZSBSV19MT0NLX1VOTE9DS0VEIHsgMCwgX0xPQ0tfREVC
VUcgfQogI2RlZmluZSBERUZJTkVfUldMT0NLKGwpIHJ3bG9ja190IGwgPSBS
V19MT0NLX1VOTE9DS0VECiAjZGVmaW5lIHJ3bG9ja19pbml0KGwpICgqKGwp
ID0gKHJ3bG9ja190KVJXX0xPQ0tfVU5MT0NLRUQpCiAK

--=separator
Content-Type: application/octet-stream; name="xsa114-4.2.patch"
Content-Disposition: attachment; filename="xsa114-4.2.patch"
Content-Transfer-Encoding: base64

c3dpdGNoIHRvIHdyaXRlLWJpYXNlZCByL3cgbG9ja3MKClRoaXMgaXMgdG8g
aW1wcm92ZSBmYWlybmVzczogQSBwZXJtYW5lbnQgZmxvdyBvZiByZWFkIGFj
cXVpcmVzIGNhbgpvdGhlcndpc2UgbG9jayBvdXQgZXZlbnR1YWwgd3JpdGVy
cyBpbmRlZmluaXRlbHkuCgpUaGlzIGlzIFhTQS0xMTQgLyBDVkUtMjAxNC05
MDY1LgoKU2lnbmVkLW9mZi1ieTogS2VpciBGcmFzZXIgPGtlaXJAeGVuLm9y
Zz4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4KUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIz
QGNpdHJpeC5jb20+ClRlc3RlZC1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT4KCi0tLSBhL3hlbi9jb21tb24vc3Bpbmxv
Y2suYworKysgYi94ZW4vY29tbW9uL3NwaW5sb2NrLmMKQEAgLTI3MSwxMTIg
KzI3MSwxNTEgQEAgdm9pZCBfc3Bpbl91bmxvY2tfcmVjdXJzaXZlKHNwaW5s
b2NrX3QgKgogCiB2b2lkIF9yZWFkX2xvY2socndsb2NrX3QgKmxvY2spCiB7
CisgICAgdWludDMyX3QgeDsKKwogICAgIGNoZWNrX2xvY2soJmxvY2stPmRl
YnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3JlYWRfdHJ5bG9j
aygmbG9jay0+cmF3KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtl
bHkoX3Jhd19yd19pc193cml0ZV9sb2NrZWQoJmxvY2stPnJhdykpICkKKyAg
ICBkbyB7CisgICAgICAgIHdoaWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJX
X1dSSVRFX0ZMQUcgKQogICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0gICAg
fQorICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEp
ICE9IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBf
cmVhZF9sb2NrX2lycShyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgQVNTRVJUKGxvY2FsX2lycV9pc19lbmFibGVkKCkpOwog
ICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CiAgICAgY2hlY2tfbG9jaygmbG9j
ay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtlbHkoIV9yYXdfcmVhZF90
cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewotICAgICAgICBsb2NhbF9p
cnFfZW5hYmxlKCk7Ci0gICAgICAgIHdoaWxlICggbGlrZWx5KF9yYXdfcndf
aXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5yYXcpKSApCi0gICAgICAgICAgICBj
cHVfcmVsYXgoKTsKLSAgICAgICAgbG9jYWxfaXJxX2Rpc2FibGUoKTsKLSAg
ICB9CisgICAgZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykg
JiBSV19XUklURV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxv
Y2stPmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAg
Y3B1X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfZGlzYWJsZSgp
OworICAgICAgICB9CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2stPmxv
Y2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgpOwog
fQogCiB1bnNpZ25lZCBsb25nIF9yZWFkX2xvY2tfaXJxc2F2ZShyd2xvY2tf
dCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4OwogICAgIHVuc2lnbmVkIGxv
bmcgZmxhZ3M7CisKICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7CiAgICAg
Y2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtl
bHkoIV9yYXdfcmVhZF90cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewot
ICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7Ci0gICAgICAgIHdo
aWxlICggbGlrZWx5KF9yYXdfcndfaXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5y
YXcpKSApCi0gICAgICAgICAgICBjcHVfcmVsYXgoKTsKLSAgICAgICAgbG9j
YWxfaXJxX3NhdmUoZmxhZ3MpOwotICAgIH0KKyAgICBkbyB7CisgICAgICAg
IGlmICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAg
ICAgICB7CisgICAgICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CisgICAgICAgICAgICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19X
UklURV9GTEFHICkKKyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAg
ICAgICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgfQor
ICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEpICE9
IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gZmxh
Z3M7CiB9CiAKIGludCBfcmVhZF90cnlsb2NrKHJ3bG9ja190ICpsb2NrKQog
eworICAgIHVpbnQzMl90IHg7CisKICAgICBjaGVja19sb2NrKCZsb2NrLT5k
ZWJ1Zyk7Ci0gICAgaWYgKCAhX3Jhd19yZWFkX3RyeWxvY2soJmxvY2stPnJh
dykgKQotICAgICAgICByZXR1cm4gMDsKKyAgICBkbyB7CisgICAgICAgIGlm
ICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAg
ICAgICAgcmV0dXJuIDA7CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2st
PmxvY2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgp
OwogICAgIHJldHVybiAxOwogfQogCiB2b2lkIF9yZWFkX3VubG9jayhyd2xv
Y2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4LCB5OworCiAgICAgcHJl
ZW1wdF9lbmFibGUoKTsKLSAgICBfcmF3X3JlYWRfdW5sb2NrKCZsb2NrLT5y
YXcpOworICAgIHggPSBsb2NrLT5sb2NrOworICAgIHdoaWxlICggKHkgPSBj
bXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4LTEpKSAhPSB4ICkKKyAgICAgICAg
eCA9IHk7CiB9CiAKIHZvaWQgX3JlYWRfdW5sb2NrX2lycShyd2xvY2tfdCAq
bG9jaykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfcmVh
ZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxvY2sp
OwogICAgIGxvY2FsX2lycV9lbmFibGUoKTsKIH0KIAogdm9pZCBfcmVhZF91
bmxvY2tfaXJxcmVzdG9yZShyd2xvY2tfdCAqbG9jaywgdW5zaWduZWQgbG9u
ZyBmbGFncykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdf
cmVhZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxv
Y2spOwogICAgIGxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKIH0KIAogdm9p
ZCBfd3JpdGVfbG9jayhyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdo
aWxlICggdW5saWtlbHkoIV9yYXdfd3JpdGVfdHJ5bG9jaygmbG9jay0+cmF3
KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtlbHkoX3Jhd19yd19p
c19sb2NrZWQoJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIHdo
aWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQogICAg
ICAgICAgICAgY3B1X3JlbGF4KCk7CisgICAgfSB3aGlsZSAoIGNtcHhjaGco
JmxvY2stPmxvY2ssIHgsIHh8UldfV1JJVEVfRkxBRykgIT0geCApOworICAg
IHdoaWxlICggeCAhPSAwICkKKyAgICB7CisgICAgICAgIGNwdV9yZWxheCgp
OworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5SV19XUklURV9GTEFHOwog
ICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBfd3Jp
dGVfbG9ja19pcnEocndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3Qg
eDsKKwogICAgIEFTU0VSVChsb2NhbF9pcnFfaXNfZW5hYmxlZCgpKTsKICAg
ICBsb2NhbF9pcnFfZGlzYWJsZSgpOwogICAgIGNoZWNrX2xvY2soJmxvY2st
PmRlYnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3dyaXRlX3Ry
eWxvY2soJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIGlmICgg
KHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAgICB7
CisgICAgICAgICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CisgICAgICAgICAg
ICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklURV9GTEFHICkK
KyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAgICAgICAgICAgIGxv
Y2FsX2lycV9kaXNhYmxlKCk7CisgICAgICAgIH0KKyAgICB9IHdoaWxlICgg
Y21weGNoZygmbG9jay0+bG9jaywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4
ICk7CisgICAgd2hpbGUgKCB4ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3
X3J3X2lzX2xvY2tlZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1
X3JlbGF4KCk7Ci0gICAgICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CisgICAg
ICAgIGNwdV9yZWxheCgpOworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5S
V19XUklURV9GTEFHOwogICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsK
IH0KIAogdW5zaWduZWQgbG9uZyBfd3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9j
a190ICpsb2NrKQogeworICAgIHVpbnQzMl90IHg7CiAgICAgdW5zaWduZWQg
bG9uZyBmbGFnczsKKwogICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKICAg
ICBjaGVja19sb2NrKCZsb2NrLT5kZWJ1Zyk7Ci0gICAgd2hpbGUgKCB1bmxp
a2VseSghX3Jhd193cml0ZV90cnlsb2NrKCZsb2NrLT5yYXcpKSApCisgICAg
ZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklU
RV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9jYWxfaXJxX3Jl
c3RvcmUoZmxhZ3MpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxvY2st
PmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAgY3B1
X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7
CisgICAgICAgIH0KKyAgICB9IHdoaWxlICggY21weGNoZygmbG9jay0+bG9j
aywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4ICk7CisgICAgd2hpbGUgKCB4
ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh
Z3MpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3X3J3X2lzX2xvY2tl
ZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0g
ICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgY3B1X3Jl
bGF4KCk7CisgICAgICAgIHggPSBsb2NrLT5sb2NrICYgflJXX1dSSVRFX0ZM
QUc7CiAgICAgfQogICAgIHByZWVtcHRfZGlzYWJsZSgpOwogICAgIHJldHVy
biBmbGFnczsKQEAgLTM4NCw5ICs0MjMsMTMgQEAgdW5zaWduZWQgbG9uZyBf
d3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9jawogCiBpbnQgX3dyaXRlX3RyeWxv
Y2socndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3QgeDsKKwogICAg
IGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICBpZiAoICFfcmF3X3dy
aXRlX3RyeWxvY2soJmxvY2stPnJhdykgKQotICAgICAgICByZXR1cm4gMDsK
KyAgICBkbyB7CisgICAgICAgIGlmICggKHggPSBsb2NrLT5sb2NrKSAhPSAw
ICkKKyAgICAgICAgICAgIHJldHVybiAwOworICAgIH0gd2hpbGUgKCBjbXB4
Y2hnKCZsb2NrLT5sb2NrLCB4LCB4fFJXX1dSSVRFX0ZMQUcpICE9IHggKTsK
ICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gMTsKIH0KQEAg
LTM5NCwzMyArNDM3LDMyIEBAIGludCBfd3JpdGVfdHJ5bG9jayhyd2xvY2tf
dCAqbG9jaykKIHZvaWQgX3dyaXRlX3VubG9jayhyd2xvY2tfdCAqbG9jaykK
IHsKICAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfd3JpdGVfdW5s
b2NrKCZsb2NrLT5yYXcpOworICAgIGlmICggY21weGNoZygmbG9jay0+bG9j
aywgUldfV1JJVEVfRkxBRywgMCkgIT0gUldfV1JJVEVfRkxBRyApCisgICAg
ICAgIEJVRygpOwogfQogCiB2b2lkIF93cml0ZV91bmxvY2tfaXJxKHJ3bG9j
a190ICpsb2NrKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0gICAgX3Jh
d193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRlX3VubG9j
ayhsb2NrKTsKICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CiB9CiAKIHZvaWQg
X3dyaXRlX3VubG9ja19pcnFyZXN0b3JlKHJ3bG9ja190ICpsb2NrLCB1bnNp
Z25lZCBsb25nIGZsYWdzKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0g
ICAgX3Jhd193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRl
X3VubG9jayhsb2NrKTsKICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CiB9CiAKIGludCBfcndfaXNfbG9ja2VkKHJ3bG9ja190ICpsb2NrKQogewog
ICAgIGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICByZXR1cm4gX3Jh
d19yd19pc19sb2NrZWQoJmxvY2stPnJhdyk7CisgICAgcmV0dXJuIChsb2Nr
LT5sb2NrICE9IDApOyAvKiBhbnlvbmUgaW4gY3JpdGljYWwgc2VjdGlvbj8g
Ki8KIH0KIAogaW50IF9yd19pc193cml0ZV9sb2NrZWQocndsb2NrX3QgKmxv
Y2spCiB7CiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHJl
dHVybiBfcmF3X3J3X2lzX3dyaXRlX2xvY2tlZCgmbG9jay0+cmF3KTsKKyAg
ICByZXR1cm4gKGxvY2stPmxvY2sgPT0gUldfV1JJVEVfRkxBRyk7IC8qIHdy
aXRlciBpbiBjcml0aWNhbCBzZWN0aW9uPyAqLwogfQogCiAjaWZkZWYgTE9D
S19QUk9GSUxFCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vc3BpbmxvY2su
aAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL3NwaW5sb2NrLmgKQEAgLTU1
LDg0ICs1NSw2IEBAIHN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3X3Nw
aW5fdHJ5bG8KICAgICB9CiB9CiAKLXR5cGVkZWYgc3RydWN0IHsKLSAgICB2
b2xhdGlsZSB1bnNpZ25lZCBpbnQgbG9jazsKLX0gcmF3X3J3bG9ja190Owot
Ci0jZGVmaW5lIF9SQVdfUldfTE9DS19VTkxPQ0tFRCB7IDAgfQotCi1zdGF0
aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd19yZWFkX3RyeWxvY2socmF3X3J3
bG9ja190ICpydykKLXsKLSAgICB1bnNpZ25lZCBsb25nIHRtcCwgdG1wMiA9
IDE7Ci0KLSAgICBfX2FzbV9fIF9fdm9sYXRpbGVfXygKLSIxOiBsZHJleCAg
ICUwLCBbJTJdXG4iCi0iICAgYWRkcyAgICAlMCwgJTAsICMxXG4iCi0iICAg
c3RyZXhwbCAlMSwgJTAsIFslMl1cbiIKLSAgICA6ICI9JnIiICh0bXApLCAi
K3IiICh0bXAyKQotICAgIDogInIiICgmcnctPmxvY2spCi0gICAgOiAiY2Mi
KTsKLQotICAgIHNtcF9tYigpOwotICAgIHJldHVybiB0bXAyID09IDA7Ci19
Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3X3dyaXRlX3RyeWxv
Y2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNpZ25lZCBsb25nIHRt
cDsKLQotICAgIF9fYXNtX18gX192b2xhdGlsZV9fKAotIjE6IGxkcmV4ICAg
JTAsIFslMV1cbiIKLSIgICB0ZXEgICAgICUwLCAjMFxuIgotIiAgIHN0cmV4
ZXEgJTAsICUyLCBbJTFdIgotICAgIDogIj0mciIgKHRtcCkKLSAgICA6ICJy
IiAoJnJ3LT5sb2NrKSwgInIiICgweDgwMDAwMDAwKQotICAgIDogImNjIik7
Ci0KLSAgICBpZiAodG1wID09IDApIHsKLSAgICAgICAgc21wX21iKCk7Ci0g
ICAgICAgIHJldHVybiAxOwotICAgIH0gZWxzZSB7Ci0gICAgICAgIHJldHVy
biAwOwotICAgIH0KLX0KLQotc3RhdGljIGlubGluZSB2b2lkIF9yYXdfcmVh
ZF91bmxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNpZ25lZCBs
b25nIHRtcCwgdG1wMjsKLQotICAgIHNtcF9tYigpOwotCi0gICAgX19hc21f
XyBfX3ZvbGF0aWxlX18oCi0iMTogbGRyZXggICAlMCwgWyUyXVxuIgotIiAg
IHN1YiAgICAgJTAsICUwLCAjMVxuIgotIiAgIHN0cmV4ICAgJTEsICUwLCBb
JTJdXG4iCi0iICAgdGVxICAgICAlMSwgIzBcbiIKLSIgICBibmUgICAgIDFi
IgotICAgIDogIj0mciIgKHRtcCksICI9JnIiICh0bXAyKQotICAgIDogInIi
ICgmcnctPmxvY2spCi0gICAgOiAiY2MiKTsKLQotICAgIGlmICh0bXAgPT0g
MCkKLSAgICAgICAgZHNiX3NldigpOwotfQotCi1zdGF0aWMgaW5saW5lIHZv
aWQgX3Jhd193cml0ZV91bmxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAg
ICBzbXBfbWIoKTsKLQotICAgIF9fYXNtX18gX192b2xhdGlsZV9fKAotICAg
ICJzdHIgICAgJTEsIFslMF1cbiIKLSAgICA6Ci0gICAgOiAiciIgKCZydy0+
bG9jayksICJyIiAoMCkKLSAgICA6ICJjYyIpOwotCi0gICAgZHNiX3Nldigp
OwotfQotCi0jZGVmaW5lIF9yYXdfcndfaXNfbG9ja2VkKHgpICgoeCktPmxv
Y2sgIT0gMCkKLSNkZWZpbmUgX3Jhd19yd19pc193cml0ZV9sb2NrZWQoeCkg
KCh4KS0+bG9jayA9PSAweDgwMDAwMDAwKQotCiAjZW5kaWYgLyogX19BU01f
U1BJTkxPQ0tfSCAqLwogLyoKICAqIExvY2FsIHZhcmlhYmxlczoKLS0tIGEv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGlubG9jay5oCisrKyBiL3hlbi9pbmNs
dWRlL2FzbS14ODYvc3BpbmxvY2suaApAQCAtMzEsNTggKzMxLDQgQEAgc3Rh
dGljIGFsd2F5c19pbmxpbmUgaW50IF9yYXdfc3Bpbl90cnlsbwogICAgIHJl
dHVybiAob2xkdmFsID4gMCk7CiB9CiAKLXR5cGVkZWYgc3RydWN0IHsKLSAg
ICB2b2xhdGlsZSBpbnQgbG9jazsKLX0gcmF3X3J3bG9ja190OwotCi0jZGVm
aW5lIFJXX1dSSVRFX0JJQVMgMHg3ZmZmZmZmZgotI2RlZmluZSBfUkFXX1JX
X0xPQ0tfVU5MT0NLRUQgLyoocmF3X3J3bG9ja190KSovIHsgMCB9Ci0KLXN0
YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3X3JlYWRfdHJ5bG9jayhyYXdf
cndsb2NrX3QgKnJ3KQotewotICAgIGludCBhY3F1aXJlZDsKLQotICAgIGFz
bSB2b2xhdGlsZSAoCi0gICAgICAgICIgICAgbG9jazsgZGVjbCAlMCAgICAg
ICAgIFxuIgotICAgICAgICAiICAgIGpucyAyZiAgICAgICAgICAgICAgICBc
biIKLSNpZmRlZiBfX2NsYW5nX18gLyogY2xhbmcncyBidWlsdGluIGFzc2Vt
YmVyIGNhbid0IGRvIC5zdWJzZWN0aW9uICovCi0gICAgICAgICIxOiAgLnB1
c2hzZWN0aW9uIC5maXh1cCxcImF4XCJcbiIKLSNlbHNlCi0gICAgICAgICIx
OiAgLnN1YnNlY3Rpb24gMSAgICAgICAgIFxuIgotI2VuZGlmCi0gICAgICAg
ICIyOiAgbG9jazsgaW5jbCAlMCAgICAgICAgIFxuIgotICAgICAgICAiICAg
IGRlY2wgJTEgICAgICAgICAgICAgICBcbiIKLSAgICAgICAgIiAgICBqbXAg
MWIgICAgICAgICAgICAgICAgXG4iCi0jaWZkZWYgX19jbGFuZ19fCi0gICAg
ICAgICIgICAgLnBvcHNlY3Rpb24gICAgICAgICAgIFxuIgotI2Vsc2UKLSAg
ICAgICAgIiAgICAuc3Vic2VjdGlvbiAwICAgICAgICAgXG4iCi0jZW5kaWYK
LSAgICAgICAgOiAiPW0iIChydy0+bG9jayksICI9ciIgKGFjcXVpcmVkKSA6
ICIxIiAoMSkgOiAibWVtb3J5IiApOwotCi0gICAgcmV0dXJuIGFjcXVpcmVk
OwotfQotCi1zdGF0aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd193cml0ZV90
cnlsb2NrKHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgcmV0dXJuIChjbXB4
Y2hnKCZydy0+bG9jaywgMCwgUldfV1JJVEVfQklBUykgPT0gMCk7Ci19Ci0K
LXN0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgX3Jhd19yZWFkX3VubG9jayhy
YXdfcndsb2NrX3QgKnJ3KQotewotICAgIGFzbSB2b2xhdGlsZSAoCi0gICAg
ICAgICJsb2NrIDsgaW5jbCAlMCIKLSAgICAgICAgOiAiPW0iICgocncpLT5s
b2NrKSA6IDogIm1lbW9yeSIgKTsKLX0KLQotc3RhdGljIGFsd2F5c19pbmxp
bmUgdm9pZCBfcmF3X3dyaXRlX3VubG9jayhyYXdfcndsb2NrX3QgKnJ3KQot
ewotICAgIGFzbSB2b2xhdGlsZSAoCi0gICAgICAgICJsb2NrIDsgc3VibCAl
MSwlMCIKLSAgICAgICAgOiAiPW0iICgocncpLT5sb2NrKSA6ICJpIiAoUldf
V1JJVEVfQklBUykgOiAibWVtb3J5IiApOwotfQotCi0jZGVmaW5lIF9yYXdf
cndfaXNfbG9ja2VkKHgpICgoeCktPmxvY2sgIT0gMCkKLSNkZWZpbmUgX3Jh
d19yd19pc193cml0ZV9sb2NrZWQoeCkgKCh4KS0+bG9jayA+IDApCi0KICNl
bmRpZiAvKiBfX0FTTV9TUElOTE9DS19IICovCi0tLSBhL3hlbi9pbmNsdWRl
L3hlbi9zcGlubG9jay5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9j
ay5oCkBAIC0xNDEsMTEgKzE0MSwxMyBAQCB0eXBlZGVmIHN0cnVjdCBzcGlu
bG9jayB7CiAjZGVmaW5lIHNwaW5fbG9ja19pbml0KGwpICgqKGwpID0gKHNw
aW5sb2NrX3QpU1BJTl9MT0NLX1VOTE9DS0VEKQogCiB0eXBlZGVmIHN0cnVj
dCB7Ci0gICAgcmF3X3J3bG9ja190IHJhdzsKKyAgICB2b2xhdGlsZSB1aW50
MzJfdCBsb2NrOwogICAgIHN0cnVjdCBsb2NrX2RlYnVnIGRlYnVnOwogfSBy
d2xvY2tfdDsKIAotI2RlZmluZSBSV19MT0NLX1VOTE9DS0VEIHsgX1JBV19S
V19MT0NLX1VOTE9DS0VELCBfTE9DS19ERUJVRyB9CisjZGVmaW5lIFJXX1dS
SVRFX0ZMQUcgKDF1PDwzMSkKKworI2RlZmluZSBSV19MT0NLX1VOTE9DS0VE
IHsgMCwgX0xPQ0tfREVCVUcgfQogI2RlZmluZSBERUZJTkVfUldMT0NLKGwp
IHJ3bG9ja190IGwgPSBSV19MT0NLX1VOTE9DS0VECiAjZGVmaW5lIHJ3bG9j
a19pbml0KGwpICgqKGwpID0gKHJ3bG9ja190KVJXX0xPQ0tfVU5MT0NLRUQp
CiAK

--=separator
Content-Type: application/octet-stream; name="xsa114-4.3.patch"
Content-Disposition: attachment; filename="xsa114-4.3.patch"
Content-Transfer-Encoding: base64

c3dpdGNoIHRvIHdyaXRlLWJpYXNlZCByL3cgbG9ja3MKClRoaXMgaXMgdG8g
aW1wcm92ZSBmYWlybmVzczogQSBwZXJtYW5lbnQgZmxvdyBvZiByZWFkIGFj
cXVpcmVzIGNhbgpvdGhlcndpc2UgbG9jayBvdXQgZXZlbnR1YWwgd3JpdGVy
cyBpbmRlZmluaXRlbHkuCgpUaGlzIGlzIFhTQS0xMTQgLyBDVkUtMjAxNC05
MDY1LgoKU2lnbmVkLW9mZi1ieTogS2VpciBGcmFzZXIgPGtlaXJAeGVuLm9y
Zz4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4KUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIz
QGNpdHJpeC5jb20+ClRlc3RlZC1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT4KCi0tLSBhL3hlbi9jb21tb24vc3Bpbmxv
Y2suYworKysgYi94ZW4vY29tbW9uL3NwaW5sb2NrLmMKQEAgLTI3MSwxMTIg
KzI3MSwxNTEgQEAgdm9pZCBfc3Bpbl91bmxvY2tfcmVjdXJzaXZlKHNwaW5s
b2NrX3QgKgogCiB2b2lkIF9yZWFkX2xvY2socndsb2NrX3QgKmxvY2spCiB7
CisgICAgdWludDMyX3QgeDsKKwogICAgIGNoZWNrX2xvY2soJmxvY2stPmRl
YnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3JlYWRfdHJ5bG9j
aygmbG9jay0+cmF3KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtl
bHkoX3Jhd19yd19pc193cml0ZV9sb2NrZWQoJmxvY2stPnJhdykpICkKKyAg
ICBkbyB7CisgICAgICAgIHdoaWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJX
X1dSSVRFX0ZMQUcgKQogICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0gICAg
fQorICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEp
ICE9IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBf
cmVhZF9sb2NrX2lycShyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgQVNTRVJUKGxvY2FsX2lycV9pc19lbmFibGVkKCkpOwog
ICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CiAgICAgY2hlY2tfbG9jaygmbG9j
ay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtlbHkoIV9yYXdfcmVhZF90
cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewotICAgICAgICBsb2NhbF9p
cnFfZW5hYmxlKCk7Ci0gICAgICAgIHdoaWxlICggbGlrZWx5KF9yYXdfcndf
aXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5yYXcpKSApCi0gICAgICAgICAgICBj
cHVfcmVsYXgoKTsKLSAgICAgICAgbG9jYWxfaXJxX2Rpc2FibGUoKTsKLSAg
ICB9CisgICAgZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykg
JiBSV19XUklURV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxv
Y2stPmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAg
Y3B1X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfZGlzYWJsZSgp
OworICAgICAgICB9CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2stPmxv
Y2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgpOwog
fQogCiB1bnNpZ25lZCBsb25nIF9yZWFkX2xvY2tfaXJxc2F2ZShyd2xvY2tf
dCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4OwogICAgIHVuc2lnbmVkIGxv
bmcgZmxhZ3M7CisKICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7CiAgICAg
Y2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtl
bHkoIV9yYXdfcmVhZF90cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewot
ICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7Ci0gICAgICAgIHdo
aWxlICggbGlrZWx5KF9yYXdfcndfaXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5y
YXcpKSApCi0gICAgICAgICAgICBjcHVfcmVsYXgoKTsKLSAgICAgICAgbG9j
YWxfaXJxX3NhdmUoZmxhZ3MpOwotICAgIH0KKyAgICBkbyB7CisgICAgICAg
IGlmICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAg
ICAgICB7CisgICAgICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CisgICAgICAgICAgICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19X
UklURV9GTEFHICkKKyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAg
ICAgICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgfQor
ICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEpICE9
IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gZmxh
Z3M7CiB9CiAKIGludCBfcmVhZF90cnlsb2NrKHJ3bG9ja190ICpsb2NrKQog
eworICAgIHVpbnQzMl90IHg7CisKICAgICBjaGVja19sb2NrKCZsb2NrLT5k
ZWJ1Zyk7Ci0gICAgaWYgKCAhX3Jhd19yZWFkX3RyeWxvY2soJmxvY2stPnJh
dykgKQotICAgICAgICByZXR1cm4gMDsKKyAgICBkbyB7CisgICAgICAgIGlm
ICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAg
ICAgICAgcmV0dXJuIDA7CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2st
PmxvY2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgp
OwogICAgIHJldHVybiAxOwogfQogCiB2b2lkIF9yZWFkX3VubG9jayhyd2xv
Y2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4LCB5OworCiAgICAgcHJl
ZW1wdF9lbmFibGUoKTsKLSAgICBfcmF3X3JlYWRfdW5sb2NrKCZsb2NrLT5y
YXcpOworICAgIHggPSBsb2NrLT5sb2NrOworICAgIHdoaWxlICggKHkgPSBj
bXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4LTEpKSAhPSB4ICkKKyAgICAgICAg
eCA9IHk7CiB9CiAKIHZvaWQgX3JlYWRfdW5sb2NrX2lycShyd2xvY2tfdCAq
bG9jaykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfcmVh
ZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxvY2sp
OwogICAgIGxvY2FsX2lycV9lbmFibGUoKTsKIH0KIAogdm9pZCBfcmVhZF91
bmxvY2tfaXJxcmVzdG9yZShyd2xvY2tfdCAqbG9jaywgdW5zaWduZWQgbG9u
ZyBmbGFncykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdf
cmVhZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxv
Y2spOwogICAgIGxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKIH0KIAogdm9p
ZCBfd3JpdGVfbG9jayhyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdo
aWxlICggdW5saWtlbHkoIV9yYXdfd3JpdGVfdHJ5bG9jaygmbG9jay0+cmF3
KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtlbHkoX3Jhd19yd19p
c19sb2NrZWQoJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIHdo
aWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQogICAg
ICAgICAgICAgY3B1X3JlbGF4KCk7CisgICAgfSB3aGlsZSAoIGNtcHhjaGco
JmxvY2stPmxvY2ssIHgsIHh8UldfV1JJVEVfRkxBRykgIT0geCApOworICAg
IHdoaWxlICggeCAhPSAwICkKKyAgICB7CisgICAgICAgIGNwdV9yZWxheCgp
OworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5SV19XUklURV9GTEFHOwog
ICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBfd3Jp
dGVfbG9ja19pcnEocndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3Qg
eDsKKwogICAgIEFTU0VSVChsb2NhbF9pcnFfaXNfZW5hYmxlZCgpKTsKICAg
ICBsb2NhbF9pcnFfZGlzYWJsZSgpOwogICAgIGNoZWNrX2xvY2soJmxvY2st
PmRlYnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3dyaXRlX3Ry
eWxvY2soJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIGlmICgg
KHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAgICB7
CisgICAgICAgICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CisgICAgICAgICAg
ICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklURV9GTEFHICkK
KyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAgICAgICAgICAgIGxv
Y2FsX2lycV9kaXNhYmxlKCk7CisgICAgICAgIH0KKyAgICB9IHdoaWxlICgg
Y21weGNoZygmbG9jay0+bG9jaywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4
ICk7CisgICAgd2hpbGUgKCB4ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3
X3J3X2lzX2xvY2tlZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1
X3JlbGF4KCk7Ci0gICAgICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CisgICAg
ICAgIGNwdV9yZWxheCgpOworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5S
V19XUklURV9GTEFHOwogICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsK
IH0KIAogdW5zaWduZWQgbG9uZyBfd3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9j
a190ICpsb2NrKQogeworICAgIHVpbnQzMl90IHg7CiAgICAgdW5zaWduZWQg
bG9uZyBmbGFnczsKKwogICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKICAg
ICBjaGVja19sb2NrKCZsb2NrLT5kZWJ1Zyk7Ci0gICAgd2hpbGUgKCB1bmxp
a2VseSghX3Jhd193cml0ZV90cnlsb2NrKCZsb2NrLT5yYXcpKSApCisgICAg
ZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklU
RV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9jYWxfaXJxX3Jl
c3RvcmUoZmxhZ3MpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxvY2st
PmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAgY3B1
X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7
CisgICAgICAgIH0KKyAgICB9IHdoaWxlICggY21weGNoZygmbG9jay0+bG9j
aywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4ICk7CisgICAgd2hpbGUgKCB4
ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh
Z3MpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3X3J3X2lzX2xvY2tl
ZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0g
ICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgY3B1X3Jl
bGF4KCk7CisgICAgICAgIHggPSBsb2NrLT5sb2NrICYgflJXX1dSSVRFX0ZM
QUc7CiAgICAgfQogICAgIHByZWVtcHRfZGlzYWJsZSgpOwogICAgIHJldHVy
biBmbGFnczsKQEAgLTM4NCw5ICs0MjMsMTMgQEAgdW5zaWduZWQgbG9uZyBf
d3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9jawogCiBpbnQgX3dyaXRlX3RyeWxv
Y2socndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3QgeDsKKwogICAg
IGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICBpZiAoICFfcmF3X3dy
aXRlX3RyeWxvY2soJmxvY2stPnJhdykgKQotICAgICAgICByZXR1cm4gMDsK
KyAgICBkbyB7CisgICAgICAgIGlmICggKHggPSBsb2NrLT5sb2NrKSAhPSAw
ICkKKyAgICAgICAgICAgIHJldHVybiAwOworICAgIH0gd2hpbGUgKCBjbXB4
Y2hnKCZsb2NrLT5sb2NrLCB4LCB4fFJXX1dSSVRFX0ZMQUcpICE9IHggKTsK
ICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gMTsKIH0KQEAg
LTM5NCwzMyArNDM3LDMyIEBAIGludCBfd3JpdGVfdHJ5bG9jayhyd2xvY2tf
dCAqbG9jaykKIHZvaWQgX3dyaXRlX3VubG9jayhyd2xvY2tfdCAqbG9jaykK
IHsKICAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfd3JpdGVfdW5s
b2NrKCZsb2NrLT5yYXcpOworICAgIGlmICggY21weGNoZygmbG9jay0+bG9j
aywgUldfV1JJVEVfRkxBRywgMCkgIT0gUldfV1JJVEVfRkxBRyApCisgICAg
ICAgIEJVRygpOwogfQogCiB2b2lkIF93cml0ZV91bmxvY2tfaXJxKHJ3bG9j
a190ICpsb2NrKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0gICAgX3Jh
d193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRlX3VubG9j
ayhsb2NrKTsKICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CiB9CiAKIHZvaWQg
X3dyaXRlX3VubG9ja19pcnFyZXN0b3JlKHJ3bG9ja190ICpsb2NrLCB1bnNp
Z25lZCBsb25nIGZsYWdzKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0g
ICAgX3Jhd193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRl
X3VubG9jayhsb2NrKTsKICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CiB9CiAKIGludCBfcndfaXNfbG9ja2VkKHJ3bG9ja190ICpsb2NrKQogewog
ICAgIGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICByZXR1cm4gX3Jh
d19yd19pc19sb2NrZWQoJmxvY2stPnJhdyk7CisgICAgcmV0dXJuIChsb2Nr
LT5sb2NrICE9IDApOyAvKiBhbnlvbmUgaW4gY3JpdGljYWwgc2VjdGlvbj8g
Ki8KIH0KIAogaW50IF9yd19pc193cml0ZV9sb2NrZWQocndsb2NrX3QgKmxv
Y2spCiB7CiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHJl
dHVybiBfcmF3X3J3X2lzX3dyaXRlX2xvY2tlZCgmbG9jay0+cmF3KTsKKyAg
ICByZXR1cm4gKGxvY2stPmxvY2sgPT0gUldfV1JJVEVfRkxBRyk7IC8qIHdy
aXRlciBpbiBjcml0aWNhbCBzZWN0aW9uPyAqLwogfQogCiAjaWZkZWYgTE9D
S19QUk9GSUxFCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vYXJtMzIvc3Bp
bmxvY2suaAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2FybTMyL3NwaW5s
b2NrLmgKQEAgLTUyLDg0ICs1Miw2IEBAIHN0YXRpYyBhbHdheXNfaW5saW5l
IGludCBfcmF3X3NwaW5fdHJ5bG8KICAgICB9CiB9CiAKLXR5cGVkZWYgc3Ry
dWN0IHsKLSAgICB2b2xhdGlsZSB1bnNpZ25lZCBpbnQgbG9jazsKLX0gcmF3
X3J3bG9ja190OwotCi0jZGVmaW5lIF9SQVdfUldfTE9DS19VTkxPQ0tFRCB7
IDAgfQotCi1zdGF0aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd19yZWFkX3Ry
eWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNpZ25lZCBsb25n
IHRtcCwgdG1wMiA9IDE7Ci0KLSAgICBfX2FzbV9fIF9fdm9sYXRpbGVfXygK
LSIxOiBsZHJleCAgICUwLCBbJTJdXG4iCi0iICAgYWRkcyAgICAlMCwgJTAs
ICMxXG4iCi0iICAgc3RyZXhwbCAlMSwgJTAsIFslMl1cbiIKLSAgICA6ICI9
JnIiICh0bXApLCAiK3IiICh0bXAyKQotICAgIDogInIiICgmcnctPmxvY2sp
Ci0gICAgOiAiY2MiKTsKLQotICAgIHNtcF9tYigpOwotICAgIHJldHVybiB0
bXAyID09IDA7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3
X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNp
Z25lZCBsb25nIHRtcDsKLQotICAgIF9fYXNtX18gX192b2xhdGlsZV9fKAot
IjE6IGxkcmV4ICAgJTAsIFslMV1cbiIKLSIgICB0ZXEgICAgICUwLCAjMFxu
IgotIiAgIHN0cmV4ZXEgJTAsICUyLCBbJTFdIgotICAgIDogIj0mciIgKHRt
cCkKLSAgICA6ICJyIiAoJnJ3LT5sb2NrKSwgInIiICgweDgwMDAwMDAwKQot
ICAgIDogImNjIik7Ci0KLSAgICBpZiAodG1wID09IDApIHsKLSAgICAgICAg
c21wX21iKCk7Ci0gICAgICAgIHJldHVybiAxOwotICAgIH0gZWxzZSB7Ci0g
ICAgICAgIHJldHVybiAwOwotICAgIH0KLX0KLQotc3RhdGljIGlubGluZSB2
b2lkIF9yYXdfcmVhZF91bmxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAg
ICB1bnNpZ25lZCBsb25nIHRtcCwgdG1wMjsKLQotICAgIHNtcF9tYigpOwot
Ci0gICAgX19hc21fXyBfX3ZvbGF0aWxlX18oCi0iMTogbGRyZXggICAlMCwg
WyUyXVxuIgotIiAgIHN1YiAgICAgJTAsICUwLCAjMVxuIgotIiAgIHN0cmV4
ICAgJTEsICUwLCBbJTJdXG4iCi0iICAgdGVxICAgICAlMSwgIzBcbiIKLSIg
ICBibmUgICAgIDFiIgotICAgIDogIj0mciIgKHRtcCksICI9JnIiICh0bXAy
KQotICAgIDogInIiICgmcnctPmxvY2spCi0gICAgOiAiY2MiKTsKLQotICAg
IGlmICh0bXAgPT0gMCkKLSAgICAgICAgZHNiX3NldigpOwotfQotCi1zdGF0
aWMgaW5saW5lIHZvaWQgX3Jhd193cml0ZV91bmxvY2socmF3X3J3bG9ja190
ICpydykKLXsKLSAgICBzbXBfbWIoKTsKLQotICAgIF9fYXNtX18gX192b2xh
dGlsZV9fKAotICAgICJzdHIgICAgJTEsIFslMF1cbiIKLSAgICA6Ci0gICAg
OiAiciIgKCZydy0+bG9jayksICJyIiAoMCkKLSAgICA6ICJjYyIpOwotCi0g
ICAgZHNiX3NldigpOwotfQotCi0jZGVmaW5lIF9yYXdfcndfaXNfbG9ja2Vk
KHgpICgoeCktPmxvY2sgIT0gMCkKLSNkZWZpbmUgX3Jhd19yd19pc193cml0
ZV9sb2NrZWQoeCkgKCh4KS0+bG9jayA9PSAweDgwMDAwMDAwKQotCiAjZW5k
aWYgLyogX19BU01fU1BJTkxPQ0tfSCAqLwogLyoKICAqIExvY2FsIHZhcmlh
YmxlczoKLS0tIGEveGVuL2luY2x1ZGUvYXNtLWFybS9hcm02NC9zcGlubG9j
ay5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vYXJtNjQvc3BpbmxvY2su
aApAQCAtNTEsNjkgKzUxLDYgQEAgc3RhdGljIGFsd2F5c19pbmxpbmUgaW50
IF9yYXdfc3Bpbl90cnlsbwogICAgIHJldHVybiAhdG1wOwogfQogCi10eXBl
ZGVmIHN0cnVjdCB7Ci0gICAgdm9sYXRpbGUgdW5zaWduZWQgaW50IGxvY2s7
Ci19IHJhd19yd2xvY2tfdDsKLQotI2RlZmluZSBfUkFXX1JXX0xPQ0tfVU5M
T0NLRUQgeyAwIH0KLQotc3RhdGljIGFsd2F5c19pbmxpbmUgaW50IF9yYXdf
cmVhZF90cnlsb2NrKHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgdW5zaWdu
ZWQgaW50IHRtcCwgdG1wMiA9IDE7Ci0KLSAgICBhc20gdm9sYXRpbGUoCi0g
ICAgICAgICIgICAgICAgbGRheHIgICAldzAsIFslMl1cbiIKLSAgICAgICAg
IiAgICAgICBhZGQgICAgICV3MCwgJXcwLCAjMVxuIgotICAgICAgICAiICAg
ICAgIHRibnogICAgJXcwLCAjMzEsIDFmXG4iCi0gICAgICAgICIgICAgICAg
c3R4ciAgICAldzEsICV3MCwgWyUyXVxuIgotICAgICAgICAiMTpcbiIKLSAg
ICAgICAgOiAiPSZyIiAodG1wKSwgIityIiAodG1wMikKLSAgICAgICAgOiAi
ciIgKCZydy0+bG9jaykKLSAgICAgICAgOiAibWVtb3J5Iik7Ci0KLSAgICBy
ZXR1cm4gIXRtcDI7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBf
cmF3X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1
bnNpZ25lZCBpbnQgdG1wOwotCi0gICAgYXNtIHZvbGF0aWxlKAotICAgICAg
ICAiICAgICAgIGxkYXhyICAgJXcwLCBbJTFdXG4iCi0gICAgICAgICIgICAg
ICAgY2JueiAgICAldzAsIDFmXG4iCi0gICAgICAgICIgICAgICAgc3R4ciAg
ICAldzAsICV3MiwgWyUxXVxuIgotICAgICAgICAiMTpcbiIKLSAgICAgICAg
OiAiPSZyIiAodG1wKQotICAgICAgICA6ICJyIiAoJnJ3LT5sb2NrKSwgInIi
ICgweDgwMDAwMDAwKQotICAgICAgICA6ICJtZW1vcnkiKTsKLQotICAgIHJl
dHVybiAhdG1wOwotfQotCi1zdGF0aWMgaW5saW5lIHZvaWQgX3Jhd19yZWFk
X3VubG9jayhyYXdfcndsb2NrX3QgKnJ3KQotewotICAgIHVuc2lnbmVkIGlu
dCB0bXAsIHRtcDI7Ci0KLSAgICBhc20gdm9sYXRpbGUoCi0gICAgICAgICIx
OiAgICAgbGR4ciAgICAldzAsIFslMl1cbiIKLSAgICAgICAgIiAgICAgICBz
dWIgICAgICV3MCwgJXcwLCAjMVxuIgotICAgICAgICAiICAgICAgIHN0bHhy
ICAgJXcxLCAldzAsIFslMl1cbiIKLSAgICAgICAgIiAgICAgICBjYm56ICAg
ICV3MSwgMWJcbiIKLSAgICAgICAgOiAiPSZyIiAodG1wKSwgIj0mciIgKHRt
cDIpCi0gICAgICAgIDogInIiICgmcnctPmxvY2spCi0gICAgICAgIDogIm1l
bW9yeSIpOwotfQotCi1zdGF0aWMgaW5saW5lIHZvaWQgX3Jhd193cml0ZV91
bmxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICBhc20gdm9sYXRpbGUo
Ci0gICAgICAgICIgICAgICAgc3RsciAgICAldzEsIFslMF1cbiIKLSAgICAg
ICAgOiA6ICJyIiAoJnJ3LT5sb2NrKSwgInIiICgwKSA6ICJtZW1vcnkiKTsK
LX0KLQotI2RlZmluZSBfcmF3X3J3X2lzX2xvY2tlZCh4KSAoKHgpLT5sb2Nr
ICE9IDApCi0jZGVmaW5lIF9yYXdfcndfaXNfd3JpdGVfbG9ja2VkKHgpICgo
eCktPmxvY2sgPT0gMHg4MDAwMDAwMCkKLQogI2VuZGlmIC8qIF9fQVNNX1NQ
SU5MT0NLX0ggKi8KIC8qCiAgKiBMb2NhbCB2YXJpYWJsZXM6Ci0tLSBhL3hl
bi9pbmNsdWRlL2FzbS14ODYvc3BpbmxvY2suaAorKysgYi94ZW4vaW5jbHVk
ZS9hc20teDg2L3NwaW5sb2NrLmgKQEAgLTMxLDU4ICszMSw0IEBAIHN0YXRp
YyBhbHdheXNfaW5saW5lIGludCBfcmF3X3NwaW5fdHJ5bG8KICAgICByZXR1
cm4gKG9sZHZhbCA+IDApOwogfQogCi10eXBlZGVmIHN0cnVjdCB7Ci0gICAg
dm9sYXRpbGUgaW50IGxvY2s7Ci19IHJhd19yd2xvY2tfdDsKLQotI2RlZmlu
ZSBSV19XUklURV9CSUFTIDB4N2ZmZmZmZmYKLSNkZWZpbmUgX1JBV19SV19M
T0NLX1VOTE9DS0VEIC8qKHJhd19yd2xvY2tfdCkqLyB7IDAgfQotCi1zdGF0
aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd19yZWFkX3RyeWxvY2socmF3X3J3
bG9ja190ICpydykKLXsKLSAgICBpbnQgYWNxdWlyZWQ7Ci0KLSAgICBhc20g
dm9sYXRpbGUgKAotICAgICAgICAiICAgIGxvY2s7IGRlY2wgJTAgICAgICAg
ICBcbiIKLSAgICAgICAgIiAgICBqbnMgMmYgICAgICAgICAgICAgICAgXG4i
Ci0jaWZkZWYgX19jbGFuZ19fIC8qIGNsYW5nJ3MgYnVpbHRpbiBhc3NlbWJl
ciBjYW4ndCBkbyAuc3Vic2VjdGlvbiAqLwotICAgICAgICAiMTogIC5wdXNo
c2VjdGlvbiAuZml4dXAsXCJheFwiXG4iCi0jZWxzZQotICAgICAgICAiMTog
IC5zdWJzZWN0aW9uIDEgICAgICAgICBcbiIKLSNlbmRpZgotICAgICAgICAi
MjogIGxvY2s7IGluY2wgJTAgICAgICAgICBcbiIKLSAgICAgICAgIiAgICBk
ZWNsICUxICAgICAgICAgICAgICAgXG4iCi0gICAgICAgICIgICAgam1wIDFi
ICAgICAgICAgICAgICAgIFxuIgotI2lmZGVmIF9fY2xhbmdfXwotICAgICAg
ICAiICAgIC5wb3BzZWN0aW9uICAgICAgICAgICBcbiIKLSNlbHNlCi0gICAg
ICAgICIgICAgLnN1YnNlY3Rpb24gMCAgICAgICAgIFxuIgotI2VuZGlmCi0g
ICAgICAgIDogIj1tIiAocnctPmxvY2spLCAiPXIiIChhY3F1aXJlZCkgOiAi
MSIgKDEpIDogIm1lbW9yeSIgKTsKLQotICAgIHJldHVybiBhY3F1aXJlZDsK
LX0KLQotc3RhdGljIGFsd2F5c19pbmxpbmUgaW50IF9yYXdfd3JpdGVfdHJ5
bG9jayhyYXdfcndsb2NrX3QgKnJ3KQotewotICAgIHJldHVybiAoY21weGNo
ZygmcnctPmxvY2ssIDAsIFJXX1dSSVRFX0JJQVMpID09IDApOwotfQotCi1z
dGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIF9yYXdfcmVhZF91bmxvY2socmF3
X3J3bG9ja190ICpydykKLXsKLSAgICBhc20gdm9sYXRpbGUgKAotICAgICAg
ICAibG9jayA7IGluY2wgJTAiCi0gICAgICAgIDogIj1tIiAoKHJ3KS0+bG9j
aykgOiA6ICJtZW1vcnkiICk7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5l
IHZvaWQgX3Jhd193cml0ZV91bmxvY2socmF3X3J3bG9ja190ICpydykKLXsK
LSAgICBhc20gdm9sYXRpbGUgKAotICAgICAgICAibG9jayA7IHN1YmwgJTEs
JTAiCi0gICAgICAgIDogIj1tIiAoKHJ3KS0+bG9jaykgOiAiaSIgKFJXX1dS
SVRFX0JJQVMpIDogIm1lbW9yeSIgKTsKLX0KLQotI2RlZmluZSBfcmF3X3J3
X2lzX2xvY2tlZCh4KSAoKHgpLT5sb2NrICE9IDApCi0jZGVmaW5lIF9yYXdf
cndfaXNfd3JpdGVfbG9ja2VkKHgpICgoeCktPmxvY2sgPiAwKQotCiAjZW5k
aWYgLyogX19BU01fU1BJTkxPQ0tfSCAqLwotLS0gYS94ZW4vaW5jbHVkZS94
ZW4vc3BpbmxvY2suaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vc3BpbmxvY2su
aApAQCAtMTQxLDExICsxNDEsMTMgQEAgdHlwZWRlZiBzdHJ1Y3Qgc3Bpbmxv
Y2sgewogI2RlZmluZSBzcGluX2xvY2tfaW5pdChsKSAoKihsKSA9IChzcGlu
bG9ja190KVNQSU5fTE9DS19VTkxPQ0tFRCkKIAogdHlwZWRlZiBzdHJ1Y3Qg
ewotICAgIHJhd19yd2xvY2tfdCByYXc7CisgICAgdm9sYXRpbGUgdWludDMy
X3QgbG9jazsKICAgICBzdHJ1Y3QgbG9ja19kZWJ1ZyBkZWJ1ZzsKIH0gcnds
b2NrX3Q7CiAKLSNkZWZpbmUgUldfTE9DS19VTkxPQ0tFRCB7IF9SQVdfUldf
TE9DS19VTkxPQ0tFRCwgX0xPQ0tfREVCVUcgfQorI2RlZmluZSBSV19XUklU
RV9GTEFHICgxdTw8MzEpCisKKyNkZWZpbmUgUldfTE9DS19VTkxPQ0tFRCB7
IDAsIF9MT0NLX0RFQlVHIH0KICNkZWZpbmUgREVGSU5FX1JXTE9DSyhsKSBy
d2xvY2tfdCBsID0gUldfTE9DS19VTkxPQ0tFRAogI2RlZmluZSByd2xvY2tf
aW5pdChsKSAoKihsKSA9IChyd2xvY2tfdClSV19MT0NLX1VOTE9DS0VEKQog
Cg==

--=separator
Content-Type: application/octet-stream; name="xsa114-4.4.patch"
Content-Disposition: attachment; filename="xsa114-4.4.patch"
Content-Transfer-Encoding: base64

c3dpdGNoIHRvIHdyaXRlLWJpYXNlZCByL3cgbG9ja3MKClRoaXMgaXMgdG8g
aW1wcm92ZSBmYWlybmVzczogQSBwZXJtYW5lbnQgZmxvdyBvZiByZWFkIGFj
cXVpcmVzIGNhbgpvdGhlcndpc2UgbG9jayBvdXQgZXZlbnR1YWwgd3JpdGVy
cyBpbmRlZmluaXRlbHkuCgpUaGlzIGlzIFhTQS0xMTQgLyBDVkUtMjAxNC05
MDY1LgoKU2lnbmVkLW9mZi1ieTogS2VpciBGcmFzZXIgPGtlaXJAeGVuLm9y
Zz4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4KUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIz
QGNpdHJpeC5jb20+ClRlc3RlZC1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT4KCi0tLSBhL3hlbi9jb21tb24vc3Bpbmxv
Y2suYworKysgYi94ZW4vY29tbW9uL3NwaW5sb2NrLmMKQEAgLTI3MSwxMTIg
KzI3MSwxNTEgQEAgdm9pZCBfc3Bpbl91bmxvY2tfcmVjdXJzaXZlKHNwaW5s
b2NrX3QgKgogCiB2b2lkIF9yZWFkX2xvY2socndsb2NrX3QgKmxvY2spCiB7
CisgICAgdWludDMyX3QgeDsKKwogICAgIGNoZWNrX2xvY2soJmxvY2stPmRl
YnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3JlYWRfdHJ5bG9j
aygmbG9jay0+cmF3KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtl
bHkoX3Jhd19yd19pc193cml0ZV9sb2NrZWQoJmxvY2stPnJhdykpICkKKyAg
ICBkbyB7CisgICAgICAgIHdoaWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJX
X1dSSVRFX0ZMQUcgKQogICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0gICAg
fQorICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEp
ICE9IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBf
cmVhZF9sb2NrX2lycShyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgQVNTRVJUKGxvY2FsX2lycV9pc19lbmFibGVkKCkpOwog
ICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CiAgICAgY2hlY2tfbG9jaygmbG9j
ay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtlbHkoIV9yYXdfcmVhZF90
cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewotICAgICAgICBsb2NhbF9p
cnFfZW5hYmxlKCk7Ci0gICAgICAgIHdoaWxlICggbGlrZWx5KF9yYXdfcndf
aXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5yYXcpKSApCi0gICAgICAgICAgICBj
cHVfcmVsYXgoKTsKLSAgICAgICAgbG9jYWxfaXJxX2Rpc2FibGUoKTsKLSAg
ICB9CisgICAgZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykg
JiBSV19XUklURV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxv
Y2stPmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAg
Y3B1X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfZGlzYWJsZSgp
OworICAgICAgICB9CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2stPmxv
Y2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgpOwog
fQogCiB1bnNpZ25lZCBsb25nIF9yZWFkX2xvY2tfaXJxc2F2ZShyd2xvY2tf
dCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4OwogICAgIHVuc2lnbmVkIGxv
bmcgZmxhZ3M7CisKICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7CiAgICAg
Y2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtl
bHkoIV9yYXdfcmVhZF90cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewot
ICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7Ci0gICAgICAgIHdo
aWxlICggbGlrZWx5KF9yYXdfcndfaXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5y
YXcpKSApCi0gICAgICAgICAgICBjcHVfcmVsYXgoKTsKLSAgICAgICAgbG9j
YWxfaXJxX3NhdmUoZmxhZ3MpOwotICAgIH0KKyAgICBkbyB7CisgICAgICAg
IGlmICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAg
ICAgICB7CisgICAgICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CisgICAgICAgICAgICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19X
UklURV9GTEFHICkKKyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAg
ICAgICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgfQor
ICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEpICE9
IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gZmxh
Z3M7CiB9CiAKIGludCBfcmVhZF90cnlsb2NrKHJ3bG9ja190ICpsb2NrKQog
eworICAgIHVpbnQzMl90IHg7CisKICAgICBjaGVja19sb2NrKCZsb2NrLT5k
ZWJ1Zyk7Ci0gICAgaWYgKCAhX3Jhd19yZWFkX3RyeWxvY2soJmxvY2stPnJh
dykgKQotICAgICAgICByZXR1cm4gMDsKKyAgICBkbyB7CisgICAgICAgIGlm
ICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAg
ICAgICAgcmV0dXJuIDA7CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2st
PmxvY2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgp
OwogICAgIHJldHVybiAxOwogfQogCiB2b2lkIF9yZWFkX3VubG9jayhyd2xv
Y2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4LCB5OworCiAgICAgcHJl
ZW1wdF9lbmFibGUoKTsKLSAgICBfcmF3X3JlYWRfdW5sb2NrKCZsb2NrLT5y
YXcpOworICAgIHggPSBsb2NrLT5sb2NrOworICAgIHdoaWxlICggKHkgPSBj
bXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4LTEpKSAhPSB4ICkKKyAgICAgICAg
eCA9IHk7CiB9CiAKIHZvaWQgX3JlYWRfdW5sb2NrX2lycShyd2xvY2tfdCAq
bG9jaykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfcmVh
ZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxvY2sp
OwogICAgIGxvY2FsX2lycV9lbmFibGUoKTsKIH0KIAogdm9pZCBfcmVhZF91
bmxvY2tfaXJxcmVzdG9yZShyd2xvY2tfdCAqbG9jaywgdW5zaWduZWQgbG9u
ZyBmbGFncykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdf
cmVhZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxv
Y2spOwogICAgIGxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKIH0KIAogdm9p
ZCBfd3JpdGVfbG9jayhyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdo
aWxlICggdW5saWtlbHkoIV9yYXdfd3JpdGVfdHJ5bG9jaygmbG9jay0+cmF3
KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtlbHkoX3Jhd19yd19p
c19sb2NrZWQoJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIHdo
aWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQogICAg
ICAgICAgICAgY3B1X3JlbGF4KCk7CisgICAgfSB3aGlsZSAoIGNtcHhjaGco
JmxvY2stPmxvY2ssIHgsIHh8UldfV1JJVEVfRkxBRykgIT0geCApOworICAg
IHdoaWxlICggeCAhPSAwICkKKyAgICB7CisgICAgICAgIGNwdV9yZWxheCgp
OworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5SV19XUklURV9GTEFHOwog
ICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBfd3Jp
dGVfbG9ja19pcnEocndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3Qg
eDsKKwogICAgIEFTU0VSVChsb2NhbF9pcnFfaXNfZW5hYmxlZCgpKTsKICAg
ICBsb2NhbF9pcnFfZGlzYWJsZSgpOwogICAgIGNoZWNrX2xvY2soJmxvY2st
PmRlYnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3dyaXRlX3Ry
eWxvY2soJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIGlmICgg
KHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAgICB7
CisgICAgICAgICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CisgICAgICAgICAg
ICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklURV9GTEFHICkK
KyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAgICAgICAgICAgIGxv
Y2FsX2lycV9kaXNhYmxlKCk7CisgICAgICAgIH0KKyAgICB9IHdoaWxlICgg
Y21weGNoZygmbG9jay0+bG9jaywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4
ICk7CisgICAgd2hpbGUgKCB4ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3
X3J3X2lzX2xvY2tlZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1
X3JlbGF4KCk7Ci0gICAgICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CisgICAg
ICAgIGNwdV9yZWxheCgpOworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5S
V19XUklURV9GTEFHOwogICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsK
IH0KIAogdW5zaWduZWQgbG9uZyBfd3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9j
a190ICpsb2NrKQogeworICAgIHVpbnQzMl90IHg7CiAgICAgdW5zaWduZWQg
bG9uZyBmbGFnczsKKwogICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKICAg
ICBjaGVja19sb2NrKCZsb2NrLT5kZWJ1Zyk7Ci0gICAgd2hpbGUgKCB1bmxp
a2VseSghX3Jhd193cml0ZV90cnlsb2NrKCZsb2NrLT5yYXcpKSApCisgICAg
ZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklU
RV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9jYWxfaXJxX3Jl
c3RvcmUoZmxhZ3MpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxvY2st
PmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAgY3B1
X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7
CisgICAgICAgIH0KKyAgICB9IHdoaWxlICggY21weGNoZygmbG9jay0+bG9j
aywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4ICk7CisgICAgd2hpbGUgKCB4
ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh
Z3MpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3X3J3X2lzX2xvY2tl
ZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0g
ICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgY3B1X3Jl
bGF4KCk7CisgICAgICAgIHggPSBsb2NrLT5sb2NrICYgflJXX1dSSVRFX0ZM
QUc7CiAgICAgfQogICAgIHByZWVtcHRfZGlzYWJsZSgpOwogICAgIHJldHVy
biBmbGFnczsKQEAgLTM4NCw5ICs0MjMsMTMgQEAgdW5zaWduZWQgbG9uZyBf
d3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9jawogCiBpbnQgX3dyaXRlX3RyeWxv
Y2socndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3QgeDsKKwogICAg
IGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICBpZiAoICFfcmF3X3dy
aXRlX3RyeWxvY2soJmxvY2stPnJhdykgKQotICAgICAgICByZXR1cm4gMDsK
KyAgICBkbyB7CisgICAgICAgIGlmICggKHggPSBsb2NrLT5sb2NrKSAhPSAw
ICkKKyAgICAgICAgICAgIHJldHVybiAwOworICAgIH0gd2hpbGUgKCBjbXB4
Y2hnKCZsb2NrLT5sb2NrLCB4LCB4fFJXX1dSSVRFX0ZMQUcpICE9IHggKTsK
ICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gMTsKIH0KQEAg
LTM5NCwzMyArNDM3LDMyIEBAIGludCBfd3JpdGVfdHJ5bG9jayhyd2xvY2tf
dCAqbG9jaykKIHZvaWQgX3dyaXRlX3VubG9jayhyd2xvY2tfdCAqbG9jaykK
IHsKICAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfd3JpdGVfdW5s
b2NrKCZsb2NrLT5yYXcpOworICAgIGlmICggY21weGNoZygmbG9jay0+bG9j
aywgUldfV1JJVEVfRkxBRywgMCkgIT0gUldfV1JJVEVfRkxBRyApCisgICAg
ICAgIEJVRygpOwogfQogCiB2b2lkIF93cml0ZV91bmxvY2tfaXJxKHJ3bG9j
a190ICpsb2NrKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0gICAgX3Jh
d193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRlX3VubG9j
ayhsb2NrKTsKICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CiB9CiAKIHZvaWQg
X3dyaXRlX3VubG9ja19pcnFyZXN0b3JlKHJ3bG9ja190ICpsb2NrLCB1bnNp
Z25lZCBsb25nIGZsYWdzKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0g
ICAgX3Jhd193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRl
X3VubG9jayhsb2NrKTsKICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CiB9CiAKIGludCBfcndfaXNfbG9ja2VkKHJ3bG9ja190ICpsb2NrKQogewog
ICAgIGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICByZXR1cm4gX3Jh
d19yd19pc19sb2NrZWQoJmxvY2stPnJhdyk7CisgICAgcmV0dXJuIChsb2Nr
LT5sb2NrICE9IDApOyAvKiBhbnlvbmUgaW4gY3JpdGljYWwgc2VjdGlvbj8g
Ki8KIH0KIAogaW50IF9yd19pc193cml0ZV9sb2NrZWQocndsb2NrX3QgKmxv
Y2spCiB7CiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHJl
dHVybiBfcmF3X3J3X2lzX3dyaXRlX2xvY2tlZCgmbG9jay0+cmF3KTsKKyAg
ICByZXR1cm4gKGxvY2stPmxvY2sgPT0gUldfV1JJVEVfRkxBRyk7IC8qIHdy
aXRlciBpbiBjcml0aWNhbCBzZWN0aW9uPyAqLwogfQogCiAjaWZkZWYgTE9D
S19QUk9GSUxFCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vYXJtMzIvc3Bp
bmxvY2suaAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2FybTMyL3NwaW5s
b2NrLmgKQEAgLTU1LDg0ICs1NSw2IEBAIHN0YXRpYyBhbHdheXNfaW5saW5l
IGludCBfcmF3X3NwaW5fdHJ5bG8KICAgICB9CiB9CiAKLXR5cGVkZWYgc3Ry
dWN0IHsKLSAgICB2b2xhdGlsZSB1bnNpZ25lZCBpbnQgbG9jazsKLX0gcmF3
X3J3bG9ja190OwotCi0jZGVmaW5lIF9SQVdfUldfTE9DS19VTkxPQ0tFRCB7
IDAgfQotCi1zdGF0aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd19yZWFkX3Ry
eWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNpZ25lZCBsb25n
IHRtcCwgdG1wMiA9IDE7Ci0KLSAgICBfX2FzbV9fIF9fdm9sYXRpbGVfXygK
LSIxOiBsZHJleCAgICUwLCBbJTJdXG4iCi0iICAgYWRkcyAgICAlMCwgJTAs
ICMxXG4iCi0iICAgc3RyZXhwbCAlMSwgJTAsIFslMl1cbiIKLSAgICA6ICI9
JnIiICh0bXApLCAiK3IiICh0bXAyKQotICAgIDogInIiICgmcnctPmxvY2sp
Ci0gICAgOiAiY2MiKTsKLQotICAgIHNtcF9tYigpOwotICAgIHJldHVybiB0
bXAyID09IDA7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3
X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNp
Z25lZCBsb25nIHRtcDsKLQotICAgIF9fYXNtX18gX192b2xhdGlsZV9fKAot
IjE6IGxkcmV4ICAgJTAsIFslMV1cbiIKLSIgICB0ZXEgICAgICUwLCAjMFxu
IgotIiAgIHN0cmV4ZXEgJTAsICUyLCBbJTFdIgotICAgIDogIj0mciIgKHRt
cCkKLSAgICA6ICJyIiAoJnJ3LT5sb2NrKSwgInIiICgweDgwMDAwMDAwKQot
ICAgIDogImNjIik7Ci0KLSAgICBpZiAodG1wID09IDApIHsKLSAgICAgICAg
c21wX21iKCk7Ci0gICAgICAgIHJldHVybiAxOwotICAgIH0gZWxzZSB7Ci0g
ICAgICAgIHJldHVybiAwOwotICAgIH0KLX0KLQotc3RhdGljIGlubGluZSB2
b2lkIF9yYXdfcmVhZF91bmxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAg
ICB1bnNpZ25lZCBsb25nIHRtcCwgdG1wMjsKLQotICAgIHNtcF9tYigpOwot
Ci0gICAgX19hc21fXyBfX3ZvbGF0aWxlX18oCi0iMTogbGRyZXggICAlMCwg
WyUyXVxuIgotIiAgIHN1YiAgICAgJTAsICUwLCAjMVxuIgotIiAgIHN0cmV4
ICAgJTEsICUwLCBbJTJdXG4iCi0iICAgdGVxICAgICAlMSwgIzBcbiIKLSIg
ICBibmUgICAgIDFiIgotICAgIDogIj0mciIgKHRtcCksICI9JnIiICh0bXAy
KQotICAgIDogInIiICgmcnctPmxvY2spCi0gICAgOiAiY2MiKTsKLQotICAg
IGlmICh0bXAgPT0gMCkKLSAgICAgICAgZHNiX3NldigpOwotfQotCi1zdGF0
aWMgaW5saW5lIHZvaWQgX3Jhd193cml0ZV91bmxvY2socmF3X3J3bG9ja190
ICpydykKLXsKLSAgICBzbXBfbWIoKTsKLQotICAgIF9fYXNtX18gX192b2xh
dGlsZV9fKAotICAgICJzdHIgICAgJTEsIFslMF1cbiIKLSAgICA6Ci0gICAg
OiAiciIgKCZydy0+bG9jayksICJyIiAoMCkKLSAgICA6ICJjYyIpOwotCi0g
ICAgZHNiX3NldigpOwotfQotCi0jZGVmaW5lIF9yYXdfcndfaXNfbG9ja2Vk
KHgpICgoeCktPmxvY2sgIT0gMCkKLSNkZWZpbmUgX3Jhd19yd19pc193cml0
ZV9sb2NrZWQoeCkgKCh4KS0+bG9jayA9PSAweDgwMDAwMDAwKQotCiAjZW5k
aWYgLyogX19BU01fU1BJTkxPQ0tfSCAqLwogLyoKICAqIExvY2FsIHZhcmlh
YmxlczoKLS0tIGEveGVuL2luY2x1ZGUvYXNtLWFybS9hcm02NC9zcGlubG9j
ay5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vYXJtNjQvc3BpbmxvY2su
aApAQCAtNTIsNjkgKzUyLDYgQEAgc3RhdGljIGFsd2F5c19pbmxpbmUgaW50
IF9yYXdfc3Bpbl90cnlsbwogICAgIHJldHVybiAhdG1wOwogfQogCi10eXBl
ZGVmIHN0cnVjdCB7Ci0gICAgdm9sYXRpbGUgdW5zaWduZWQgaW50IGxvY2s7
Ci19IHJhd19yd2xvY2tfdDsKLQotI2RlZmluZSBfUkFXX1JXX0xPQ0tfVU5M
T0NLRUQgeyAwIH0KLQotc3RhdGljIGFsd2F5c19pbmxpbmUgaW50IF9yYXdf
cmVhZF90cnlsb2NrKHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgdW5zaWdu
ZWQgaW50IHRtcCwgdG1wMiA9IDE7Ci0KLSAgICBhc20gdm9sYXRpbGUoCi0g
ICAgICAgICIgICAgICAgbGRheHIgICAldzAsICUyXG4iCi0gICAgICAgICIg
ICAgICAgYWRkICAgICAldzAsICV3MCwgIzFcbiIKLSAgICAgICAgIiAgICAg
ICB0Ym56ICAgICV3MCwgIzMxLCAxZlxuIgotICAgICAgICAiICAgICAgIHN0
eHIgICAgJXcxLCAldzAsICUyXG4iCi0gICAgICAgICIxOlxuIgotICAgICAg
ICA6ICI9JnIiICh0bXApLCAiK3IiICh0bXAyKSwgIitRIiAocnctPmxvY2sp
Ci0gICAgICAgIDoKLSAgICAgICAgOiAiY2MiLCAibWVtb3J5Iik7Ci0KLSAg
ICByZXR1cm4gIXRtcDI7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGlu
dCBfcmF3X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAg
ICB1bnNpZ25lZCBpbnQgdG1wOwotCi0gICAgYXNtIHZvbGF0aWxlKAotICAg
ICAgICAiICAgICAgIGxkYXhyICAgJXcwLCAlMVxuIgotICAgICAgICAiICAg
ICAgIGNibnogICAgJXcwLCAxZlxuIgotICAgICAgICAiICAgICAgIHN0eHIg
ICAgJXcwLCAldzIsICUxXG4iCi0gICAgICAgICIxOlxuIgotICAgICAgICA6
ICI9JnIiICh0bXApLCAiK1EiIChydy0+bG9jaykKLSAgICAgICAgOiAiciIg
KDB4ODAwMDAwMDApCi0gICAgICAgIDogImNjIiwgIm1lbW9yeSIpOwotCi0g
ICAgcmV0dXJuICF0bXA7Ci19Ci0KLXN0YXRpYyBpbmxpbmUgdm9pZCBfcmF3
X3JlYWRfdW5sb2NrKHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgdW5zaWdu
ZWQgaW50IHRtcCwgdG1wMjsKLQotICAgIGFzbSB2b2xhdGlsZSgKLSAgICAg
ICAgIiAgICAxOiBsZHhyICAgICV3MCwgJTJcbiIKLSAgICAgICAgIiAgICAg
ICBzdWIgICAgICV3MCwgJXcwLCAjMVxuIgotICAgICAgICAiICAgICAgIHN0
bHhyICAgJXcxLCAldzAsICUyXG4iCi0gICAgICAgICIgICAgICAgY2JueiAg
ICAldzEsIDFiXG4iCi0gICAgICAgIDogIj0mciIgKHRtcCksICI9JnIiICh0
bXAyKSwgIitRIiAocnctPmxvY2spCi0gICAgICAgIDoKLSAgICAgICAgOiAi
Y2MiLCAibWVtb3J5Iik7Ci19Ci0KLXN0YXRpYyBpbmxpbmUgdm9pZCBfcmF3
X3dyaXRlX3VubG9jayhyYXdfcndsb2NrX3QgKnJ3KQotewotICAgIGFzbSB2
b2xhdGlsZSgKLSAgICAgICAgIiAgICAgICBzdGxyICAgICV3MSwgJTBcbiIK
LSAgICAgICAgOiAiPVEiIChydy0+bG9jaykgOiAiciIgKDApIDogIm1lbW9y
eSIpOwotfQotCi0jZGVmaW5lIF9yYXdfcndfaXNfbG9ja2VkKHgpICgoeCkt
PmxvY2sgIT0gMCkKLSNkZWZpbmUgX3Jhd19yd19pc193cml0ZV9sb2NrZWQo
eCkgKCh4KS0+bG9jayA9PSAweDgwMDAwMDAwKQotCiAjZW5kaWYgLyogX19B
U01fU1BJTkxPQ0tfSCAqLwogLyoKICAqIExvY2FsIHZhcmlhYmxlczoKLS0t
IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGlubG9jay5oCisrKyBiL3hlbi9p
bmNsdWRlL2FzbS14ODYvc3BpbmxvY2suaApAQCAtMzEsNTggKzMxLDQgQEAg
c3RhdGljIGFsd2F5c19pbmxpbmUgaW50IF9yYXdfc3Bpbl90cnlsbwogICAg
IHJldHVybiAob2xkdmFsID4gMCk7CiB9CiAKLXR5cGVkZWYgc3RydWN0IHsK
LSAgICB2b2xhdGlsZSBpbnQgbG9jazsKLX0gcmF3X3J3bG9ja190OwotCi0j
ZGVmaW5lIFJXX1dSSVRFX0JJQVMgMHg3ZmZmZmZmZgotI2RlZmluZSBfUkFX
X1JXX0xPQ0tfVU5MT0NLRUQgLyoocmF3X3J3bG9ja190KSovIHsgMCB9Ci0K
LXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3X3JlYWRfdHJ5bG9jayhy
YXdfcndsb2NrX3QgKnJ3KQotewotICAgIGludCBhY3F1aXJlZDsKLQotICAg
IGFzbSB2b2xhdGlsZSAoCi0gICAgICAgICIgICAgbG9jazsgZGVjbCAlMCAg
ICAgICAgIFxuIgotICAgICAgICAiICAgIGpucyAyZiAgICAgICAgICAgICAg
ICBcbiIKLSNpZmRlZiBfX2NsYW5nX18gLyogY2xhbmcncyBidWlsdGluIGFz
c2VtYmVyIGNhbid0IGRvIC5zdWJzZWN0aW9uICovCi0gICAgICAgICIxOiAg
LnB1c2hzZWN0aW9uIC5maXh1cCxcImF4XCJcbiIKLSNlbHNlCi0gICAgICAg
ICIxOiAgLnN1YnNlY3Rpb24gMSAgICAgICAgIFxuIgotI2VuZGlmCi0gICAg
ICAgICIyOiAgbG9jazsgaW5jbCAlMCAgICAgICAgIFxuIgotICAgICAgICAi
ICAgIGRlY2wgJTEgICAgICAgICAgICAgICBcbiIKLSAgICAgICAgIiAgICBq
bXAgMWIgICAgICAgICAgICAgICAgXG4iCi0jaWZkZWYgX19jbGFuZ19fCi0g
ICAgICAgICIgICAgLnBvcHNlY3Rpb24gICAgICAgICAgIFxuIgotI2Vsc2UK
LSAgICAgICAgIiAgICAuc3Vic2VjdGlvbiAwICAgICAgICAgXG4iCi0jZW5k
aWYKLSAgICAgICAgOiAiPW0iIChydy0+bG9jayksICI9ciIgKGFjcXVpcmVk
KSA6ICIxIiAoMSkgOiAibWVtb3J5IiApOwotCi0gICAgcmV0dXJuIGFjcXVp
cmVkOwotfQotCi1zdGF0aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd193cml0
ZV90cnlsb2NrKHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgcmV0dXJuIChj
bXB4Y2hnKCZydy0+bG9jaywgMCwgUldfV1JJVEVfQklBUykgPT0gMCk7Ci19
Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgX3Jhd19yZWFkX3VubG9j
ayhyYXdfcndsb2NrX3QgKnJ3KQotewotICAgIGFzbSB2b2xhdGlsZSAoCi0g
ICAgICAgICJsb2NrIDsgaW5jbCAlMCIKLSAgICAgICAgOiAiPW0iICgocncp
LT5sb2NrKSA6IDogIm1lbW9yeSIgKTsKLX0KLQotc3RhdGljIGFsd2F5c19p
bmxpbmUgdm9pZCBfcmF3X3dyaXRlX3VubG9jayhyYXdfcndsb2NrX3QgKnJ3
KQotewotICAgIGFzbSB2b2xhdGlsZSAoCi0gICAgICAgICJsb2NrIDsgc3Vi
bCAlMSwlMCIKLSAgICAgICAgOiAiPW0iICgocncpLT5sb2NrKSA6ICJpIiAo
UldfV1JJVEVfQklBUykgOiAibWVtb3J5IiApOwotfQotCi0jZGVmaW5lIF9y
YXdfcndfaXNfbG9ja2VkKHgpICgoeCktPmxvY2sgIT0gMCkKLSNkZWZpbmUg
X3Jhd19yd19pc193cml0ZV9sb2NrZWQoeCkgKCh4KS0+bG9jayA+IDApCi0K
ICNlbmRpZiAvKiBfX0FTTV9TUElOTE9DS19IICovCi0tLSBhL3hlbi9pbmNs
dWRlL3hlbi9zcGlubG9jay5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9zcGlu
bG9jay5oCkBAIC0xNDEsMTEgKzE0MSwxMyBAQCB0eXBlZGVmIHN0cnVjdCBz
cGlubG9jayB7CiAjZGVmaW5lIHNwaW5fbG9ja19pbml0KGwpICgqKGwpID0g
KHNwaW5sb2NrX3QpU1BJTl9MT0NLX1VOTE9DS0VEKQogCiB0eXBlZGVmIHN0
cnVjdCB7Ci0gICAgcmF3X3J3bG9ja190IHJhdzsKKyAgICB2b2xhdGlsZSB1
aW50MzJfdCBsb2NrOwogICAgIHN0cnVjdCBsb2NrX2RlYnVnIGRlYnVnOwog
fSByd2xvY2tfdDsKIAotI2RlZmluZSBSV19MT0NLX1VOTE9DS0VEIHsgX1JB
V19SV19MT0NLX1VOTE9DS0VELCBfTE9DS19ERUJVRyB9CisjZGVmaW5lIFJX
X1dSSVRFX0ZMQUcgKDF1PDwzMSkKKworI2RlZmluZSBSV19MT0NLX1VOTE9D
S0VEIHsgMCwgX0xPQ0tfREVCVUcgfQogI2RlZmluZSBERUZJTkVfUldMT0NL
KGwpIHJ3bG9ja190IGwgPSBSV19MT0NLX1VOTE9DS0VECiAjZGVmaW5lIHJ3
bG9ja19pbml0KGwpICgqKGwpID0gKHJ3bG9ja190KVJXX0xPQ0tfVU5MT0NL
RUQpCiAK

--=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 Mon Dec 08 12:10:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12: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 1Xxx8P-000550-CC; Mon, 08 Dec 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 <iwj@xenbits.xen.org>)
	id 1Xxx8N-00054b-2R; Mon, 08 Dec 2014 12:09:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A8/81-25276-A0595845; Mon, 08 Dec 2014 12:09:46 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418040584!14139902!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30454 invoked from network); 8 Dec 2014 12:09:44 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Dec 2014 12:09:44 -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 1Xxx8D-0007o2-PP; Mon, 08 Dec 2014 12:09:37 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1Xxx8D-0000BD-C9; Mon, 08 Dec 2014 12:09:37 +0000
Date: Mon, 08 Dec 2014 12:09:37 +0000
Message-Id: <E1Xxx8D-0000BD-C9@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 114 (CVE-2014-9065,
 CVE-2014-9066) - p2m lock starvation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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-9065,CVE-2014-9066 / XSA-114
                              version 3

                       p2m lock starvation

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

The current read/write lock implementation is read-biased, which allows
a consistent stream of readers to starve writers indefinitely.  There
are certain rwlocks where guests are capable of applying arbitrary read
pressure.

IMPACT
======

A malicious guest administrator can deny service to other tasks.  If
the NMI watchdog is active, a timeout might be triggered, resulting in
a host crash.

VULNERABLE SYSTEMS
==================

Xen 4.2 and later systems are vulnerable.

Xen 4.1 and earlier are not vulnerable in normal configurations.  4.1
and earlier are vulnerable only insofar as features are used which
have already been explicitly discounted for security support purposes
(TMEM, see XSA-15; XSM-based radical disaggregation, see XSA-77).

Only x86 systems offer avenues for attacking this vulnerability.
ARM systems do not and are therefore not vulnerable.

MITIGATION
==========

There is no mitigation available for this issue.

CREDITS
=======

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue in
practice for most systems.  (CVE-2014-9065 refers to these fixed
cases.)

In some deployments, large guests (more than around 30-40 VCPUs) may
still be able to trigger intermittent problems; a complete fix to this
issue requires substantial structural changes and is planned for Xen
4.6.  (CVE-2014-9066 refers to these yet-to-be-fixed cases.)

xsa114.patch                 xen-unstable
xsa114-4.4.patch             Xen 4.4.x
xsa114-4.3.patch             Xen 4.3.x
xsa114-4.2.patch             Xen 4.2.x

$ sha256sum xsa114*.patch
d1c1a2d5d55bfe13ba99a9cb99b367a29389aa30f13ffacc02b465a006115b45  xsa114.patch
a7a57c49d65de7e3cd480476b0a935ddac9e9d941aa6ca65e87170411a7c1176  xsa114-4.2.patch
ae787074b857c40ab0059802846cb0152e24c937486968c769a9bfe8cbe3d10f  xsa114-4.3.patch
b35ed8710693163cc33772c36e4c17dc76e25a0b2025fff4a5aa3b46c459938a  xsa114-4.4.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUhZTQAAoJEIP+FMlX6CvZYUkH/A/SYzqnOXvSa0tF7penNFb9
NFwRBjTvddaTnB72UiIL6ca/3tV1la2cNpn+p4M+cGSuCwHV9QaEoRMtc6l77Yol
I1ApyZWHS3Qwv2zKDp5dozDcO5yiVuVj+Az1O9f3NCv6PsQvJxYugB/3JKUnhS60
ItmlwnxAEzRd0pvoG8zb7vdLKPyfJ9gYTW3OU50F13TbJEtIJ1ifzvCTC7zPv7da
phYy7NClS9a1QeXOnwRNyoL8hBZ6OWJYxG66+8P/s0SUtvTOuOoVJ510cAwfv4Fw
y96Ss+vfTu9u34GBaO/rTP5FkH1x9vptFGTIgjtDPZmwf30kCo4qyq3jnjyWKmM=
=V6/o
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa114.patch"
Content-Disposition: attachment; filename="xsa114.patch"
Content-Transfer-Encoding: base64

c3dpdGNoIHRvIHdyaXRlLWJpYXNlZCByL3cgbG9ja3MKClRoaXMgaXMgdG8g
aW1wcm92ZSBmYWlybmVzczogQSBwZXJtYW5lbnQgZmxvdyBvZiByZWFkIGFj
cXVpcmVzIGNhbgpvdGhlcndpc2UgbG9jayBvdXQgZXZlbnR1YWwgd3JpdGVy
cyBpbmRlZmluaXRlbHkuCgpUaGlzIGlzIFhTQS0xMTQgLyBDVkUtMjAxNC05
MDY1LgoKU2lnbmVkLW9mZi1ieTogS2VpciBGcmFzZXIgPGtlaXJAeGVuLm9y
Zz4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4KUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIz
QGNpdHJpeC5jb20+CgpHaXZlbiB0aGF0IHRoaXMgcGF0Y2ggaXMgYmFzaWNh
bGx5ICJoZXJlIGFyZSBzb21lIGJyYW5kIG5ldyByd2xvY2tzIiwKdGhlIENp
dHJpeCBYZW5TZXJ2ZXIgdGVhbSwgd2hvIGFzc2lzdGVkIHdpdGggcGF0Y2gg
ZGV2ZWxvcG1lbnQgYW5kCnRlc3RpbmcsIGNhcnJpZWQgb3V0IHRoZWlyIGNv
bXBsZXRlIHN1aXRlIG9mIHBlcmZvcm1hbmNlIHRlc3RzLCBhbmQKdGFyZ2V0
ZWQgdGVzdGluZyBiYXNlZCBhcm91bmQgdGhlIGlzc3VlIHdoaWNoIHRyaWdn
ZXJlZCB0aGlzCmludmVzdGlnYXRpb24uICBObyByZWdyZXNzaW9ucyBvciBj
b25jZXJucyB3aXRoIHRoZSBwYXRjaCB3ZXJlCmlkZW50aWZpZWQuICAtQW5k
cmV3IENvb3Blci4KClRlc3RlZC1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT4KCi0tLSBhL3hlbi9jb21tb24vc3Bpbmxv
Y2suYworKysgYi94ZW4vY29tbW9uL3NwaW5sb2NrLmMKQEAgLTI3MSwxMTIg
KzI3MSwxNTEgQEAgdm9pZCBfc3Bpbl91bmxvY2tfcmVjdXJzaXZlKHNwaW5s
b2NrX3QgKgogCiB2b2lkIF9yZWFkX2xvY2socndsb2NrX3QgKmxvY2spCiB7
CisgICAgdWludDMyX3QgeDsKKwogICAgIGNoZWNrX2xvY2soJmxvY2stPmRl
YnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3JlYWRfdHJ5bG9j
aygmbG9jay0+cmF3KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtl
bHkoX3Jhd19yd19pc193cml0ZV9sb2NrZWQoJmxvY2stPnJhdykpICkKKyAg
ICBkbyB7CisgICAgICAgIHdoaWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJX
X1dSSVRFX0ZMQUcgKQogICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0gICAg
fQorICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEp
ICE9IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBf
cmVhZF9sb2NrX2lycShyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgQVNTRVJUKGxvY2FsX2lycV9pc19lbmFibGVkKCkpOwog
ICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CiAgICAgY2hlY2tfbG9jaygmbG9j
ay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtlbHkoIV9yYXdfcmVhZF90
cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewotICAgICAgICBsb2NhbF9p
cnFfZW5hYmxlKCk7Ci0gICAgICAgIHdoaWxlICggbGlrZWx5KF9yYXdfcndf
aXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5yYXcpKSApCi0gICAgICAgICAgICBj
cHVfcmVsYXgoKTsKLSAgICAgICAgbG9jYWxfaXJxX2Rpc2FibGUoKTsKLSAg
ICB9CisgICAgZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykg
JiBSV19XUklURV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxv
Y2stPmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAg
Y3B1X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfZGlzYWJsZSgp
OworICAgICAgICB9CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2stPmxv
Y2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgpOwog
fQogCiB1bnNpZ25lZCBsb25nIF9yZWFkX2xvY2tfaXJxc2F2ZShyd2xvY2tf
dCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4OwogICAgIHVuc2lnbmVkIGxv
bmcgZmxhZ3M7CisKICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7CiAgICAg
Y2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtl
bHkoIV9yYXdfcmVhZF90cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewot
ICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7Ci0gICAgICAgIHdo
aWxlICggbGlrZWx5KF9yYXdfcndfaXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5y
YXcpKSApCi0gICAgICAgICAgICBjcHVfcmVsYXgoKTsKLSAgICAgICAgbG9j
YWxfaXJxX3NhdmUoZmxhZ3MpOwotICAgIH0KKyAgICBkbyB7CisgICAgICAg
IGlmICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAg
ICAgICB7CisgICAgICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CisgICAgICAgICAgICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19X
UklURV9GTEFHICkKKyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAg
ICAgICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgfQor
ICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEpICE9
IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gZmxh
Z3M7CiB9CiAKIGludCBfcmVhZF90cnlsb2NrKHJ3bG9ja190ICpsb2NrKQog
eworICAgIHVpbnQzMl90IHg7CisKICAgICBjaGVja19sb2NrKCZsb2NrLT5k
ZWJ1Zyk7Ci0gICAgaWYgKCAhX3Jhd19yZWFkX3RyeWxvY2soJmxvY2stPnJh
dykgKQotICAgICAgICByZXR1cm4gMDsKKyAgICBkbyB7CisgICAgICAgIGlm
ICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAg
ICAgICAgcmV0dXJuIDA7CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2st
PmxvY2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgp
OwogICAgIHJldHVybiAxOwogfQogCiB2b2lkIF9yZWFkX3VubG9jayhyd2xv
Y2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4LCB5OworCiAgICAgcHJl
ZW1wdF9lbmFibGUoKTsKLSAgICBfcmF3X3JlYWRfdW5sb2NrKCZsb2NrLT5y
YXcpOworICAgIHggPSBsb2NrLT5sb2NrOworICAgIHdoaWxlICggKHkgPSBj
bXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4LTEpKSAhPSB4ICkKKyAgICAgICAg
eCA9IHk7CiB9CiAKIHZvaWQgX3JlYWRfdW5sb2NrX2lycShyd2xvY2tfdCAq
bG9jaykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfcmVh
ZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxvY2sp
OwogICAgIGxvY2FsX2lycV9lbmFibGUoKTsKIH0KIAogdm9pZCBfcmVhZF91
bmxvY2tfaXJxcmVzdG9yZShyd2xvY2tfdCAqbG9jaywgdW5zaWduZWQgbG9u
ZyBmbGFncykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdf
cmVhZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxv
Y2spOwogICAgIGxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKIH0KIAogdm9p
ZCBfd3JpdGVfbG9jayhyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdo
aWxlICggdW5saWtlbHkoIV9yYXdfd3JpdGVfdHJ5bG9jaygmbG9jay0+cmF3
KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtlbHkoX3Jhd19yd19p
c19sb2NrZWQoJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIHdo
aWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQogICAg
ICAgICAgICAgY3B1X3JlbGF4KCk7CisgICAgfSB3aGlsZSAoIGNtcHhjaGco
JmxvY2stPmxvY2ssIHgsIHh8UldfV1JJVEVfRkxBRykgIT0geCApOworICAg
IHdoaWxlICggeCAhPSAwICkKKyAgICB7CisgICAgICAgIGNwdV9yZWxheCgp
OworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5SV19XUklURV9GTEFHOwog
ICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBfd3Jp
dGVfbG9ja19pcnEocndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3Qg
eDsKKwogICAgIEFTU0VSVChsb2NhbF9pcnFfaXNfZW5hYmxlZCgpKTsKICAg
ICBsb2NhbF9pcnFfZGlzYWJsZSgpOwogICAgIGNoZWNrX2xvY2soJmxvY2st
PmRlYnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3dyaXRlX3Ry
eWxvY2soJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIGlmICgg
KHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAgICB7
CisgICAgICAgICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CisgICAgICAgICAg
ICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklURV9GTEFHICkK
KyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAgICAgICAgICAgIGxv
Y2FsX2lycV9kaXNhYmxlKCk7CisgICAgICAgIH0KKyAgICB9IHdoaWxlICgg
Y21weGNoZygmbG9jay0+bG9jaywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4
ICk7CisgICAgd2hpbGUgKCB4ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3
X3J3X2lzX2xvY2tlZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1
X3JlbGF4KCk7Ci0gICAgICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CisgICAg
ICAgIGNwdV9yZWxheCgpOworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5S
V19XUklURV9GTEFHOwogICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsK
IH0KIAogdW5zaWduZWQgbG9uZyBfd3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9j
a190ICpsb2NrKQogeworICAgIHVpbnQzMl90IHg7CiAgICAgdW5zaWduZWQg
bG9uZyBmbGFnczsKKwogICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKICAg
ICBjaGVja19sb2NrKCZsb2NrLT5kZWJ1Zyk7Ci0gICAgd2hpbGUgKCB1bmxp
a2VseSghX3Jhd193cml0ZV90cnlsb2NrKCZsb2NrLT5yYXcpKSApCisgICAg
ZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklU
RV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9jYWxfaXJxX3Jl
c3RvcmUoZmxhZ3MpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxvY2st
PmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAgY3B1
X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7
CisgICAgICAgIH0KKyAgICB9IHdoaWxlICggY21weGNoZygmbG9jay0+bG9j
aywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4ICk7CisgICAgd2hpbGUgKCB4
ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh
Z3MpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3X3J3X2lzX2xvY2tl
ZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0g
ICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgY3B1X3Jl
bGF4KCk7CisgICAgICAgIHggPSBsb2NrLT5sb2NrICYgflJXX1dSSVRFX0ZM
QUc7CiAgICAgfQogICAgIHByZWVtcHRfZGlzYWJsZSgpOwogICAgIHJldHVy
biBmbGFnczsKQEAgLTM4NCw5ICs0MjMsMTMgQEAgdW5zaWduZWQgbG9uZyBf
d3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9jawogCiBpbnQgX3dyaXRlX3RyeWxv
Y2socndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3QgeDsKKwogICAg
IGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICBpZiAoICFfcmF3X3dy
aXRlX3RyeWxvY2soJmxvY2stPnJhdykgKQotICAgICAgICByZXR1cm4gMDsK
KyAgICBkbyB7CisgICAgICAgIGlmICggKHggPSBsb2NrLT5sb2NrKSAhPSAw
ICkKKyAgICAgICAgICAgIHJldHVybiAwOworICAgIH0gd2hpbGUgKCBjbXB4
Y2hnKCZsb2NrLT5sb2NrLCB4LCB4fFJXX1dSSVRFX0ZMQUcpICE9IHggKTsK
ICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gMTsKIH0KQEAg
LTM5NCwzMyArNDM3LDMyIEBAIGludCBfd3JpdGVfdHJ5bG9jayhyd2xvY2tf
dCAqbG9jaykKIHZvaWQgX3dyaXRlX3VubG9jayhyd2xvY2tfdCAqbG9jaykK
IHsKICAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfd3JpdGVfdW5s
b2NrKCZsb2NrLT5yYXcpOworICAgIGlmICggY21weGNoZygmbG9jay0+bG9j
aywgUldfV1JJVEVfRkxBRywgMCkgIT0gUldfV1JJVEVfRkxBRyApCisgICAg
ICAgIEJVRygpOwogfQogCiB2b2lkIF93cml0ZV91bmxvY2tfaXJxKHJ3bG9j
a190ICpsb2NrKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0gICAgX3Jh
d193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRlX3VubG9j
ayhsb2NrKTsKICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CiB9CiAKIHZvaWQg
X3dyaXRlX3VubG9ja19pcnFyZXN0b3JlKHJ3bG9ja190ICpsb2NrLCB1bnNp
Z25lZCBsb25nIGZsYWdzKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0g
ICAgX3Jhd193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRl
X3VubG9jayhsb2NrKTsKICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CiB9CiAKIGludCBfcndfaXNfbG9ja2VkKHJ3bG9ja190ICpsb2NrKQogewog
ICAgIGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICByZXR1cm4gX3Jh
d19yd19pc19sb2NrZWQoJmxvY2stPnJhdyk7CisgICAgcmV0dXJuIChsb2Nr
LT5sb2NrICE9IDApOyAvKiBhbnlvbmUgaW4gY3JpdGljYWwgc2VjdGlvbj8g
Ki8KIH0KIAogaW50IF9yd19pc193cml0ZV9sb2NrZWQocndsb2NrX3QgKmxv
Y2spCiB7CiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHJl
dHVybiBfcmF3X3J3X2lzX3dyaXRlX2xvY2tlZCgmbG9jay0+cmF3KTsKKyAg
ICByZXR1cm4gKGxvY2stPmxvY2sgPT0gUldfV1JJVEVfRkxBRyk7IC8qIHdy
aXRlciBpbiBjcml0aWNhbCBzZWN0aW9uPyAqLwogfQogCiAjaWZkZWYgTE9D
S19QUk9GSUxFCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vYXJtMzIvc3Bp
bmxvY2suaAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2FybTMyL3NwaW5s
b2NrLmgKQEAgLTU1LDg0ICs1NSw2IEBAIHN0YXRpYyBhbHdheXNfaW5saW5l
IGludCBfcmF3X3NwaW5fdHJ5bG8KICAgICB9CiB9CiAKLXR5cGVkZWYgc3Ry
dWN0IHsKLSAgICB2b2xhdGlsZSB1bnNpZ25lZCBpbnQgbG9jazsKLX0gcmF3
X3J3bG9ja190OwotCi0jZGVmaW5lIF9SQVdfUldfTE9DS19VTkxPQ0tFRCB7
IDAgfQotCi1zdGF0aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd19yZWFkX3Ry
eWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNpZ25lZCBsb25n
IHRtcCwgdG1wMiA9IDE7Ci0KLSAgICBfX2FzbV9fIF9fdm9sYXRpbGVfXygK
LSIxOiBsZHJleCAgICUwLCBbJTJdXG4iCi0iICAgYWRkcyAgICAlMCwgJTAs
ICMxXG4iCi0iICAgc3RyZXhwbCAlMSwgJTAsIFslMl1cbiIKLSAgICA6ICI9
JnIiICh0bXApLCAiK3IiICh0bXAyKQotICAgIDogInIiICgmcnctPmxvY2sp
Ci0gICAgOiAiY2MiKTsKLQotICAgIHNtcF9tYigpOwotICAgIHJldHVybiB0
bXAyID09IDA7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3
X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNp
Z25lZCBsb25nIHRtcDsKLQotICAgIF9fYXNtX18gX192b2xhdGlsZV9fKAot
IjE6IGxkcmV4ICAgJTAsIFslMV1cbiIKLSIgICB0ZXEgICAgICUwLCAjMFxu
IgotIiAgIHN0cmV4ZXEgJTAsICUyLCBbJTFdIgotICAgIDogIj0mciIgKHRt
cCkKLSAgICA6ICJyIiAoJnJ3LT5sb2NrKSwgInIiICgweDgwMDAwMDAwKQot
ICAgIDogImNjIik7Ci0KLSAgICBpZiAodG1wID09IDApIHsKLSAgICAgICAg
c21wX21iKCk7Ci0gICAgICAgIHJldHVybiAxOwotICAgIH0gZWxzZSB7Ci0g
ICAgICAgIHJldHVybiAwOwotICAgIH0KLX0KLQotc3RhdGljIGlubGluZSB2
b2lkIF9yYXdfcmVhZF91bmxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAg
ICB1bnNpZ25lZCBsb25nIHRtcCwgdG1wMjsKLQotICAgIHNtcF9tYigpOwot
Ci0gICAgX19hc21fXyBfX3ZvbGF0aWxlX18oCi0iMTogbGRyZXggICAlMCwg
WyUyXVxuIgotIiAgIHN1YiAgICAgJTAsICUwLCAjMVxuIgotIiAgIHN0cmV4
ICAgJTEsICUwLCBbJTJdXG4iCi0iICAgdGVxICAgICAlMSwgIzBcbiIKLSIg
ICBibmUgICAgIDFiIgotICAgIDogIj0mciIgKHRtcCksICI9JnIiICh0bXAy
KQotICAgIDogInIiICgmcnctPmxvY2spCi0gICAgOiAiY2MiKTsKLQotICAg
IGlmICh0bXAgPT0gMCkKLSAgICAgICAgZHNiX3NldigpOwotfQotCi1zdGF0
aWMgaW5saW5lIHZvaWQgX3Jhd193cml0ZV91bmxvY2socmF3X3J3bG9ja190
ICpydykKLXsKLSAgICBzbXBfbWIoKTsKLQotICAgIF9fYXNtX18gX192b2xh
dGlsZV9fKAotICAgICJzdHIgICAgJTEsIFslMF1cbiIKLSAgICA6Ci0gICAg
OiAiciIgKCZydy0+bG9jayksICJyIiAoMCkKLSAgICA6ICJjYyIpOwotCi0g
ICAgZHNiX3NldigpOwotfQotCi0jZGVmaW5lIF9yYXdfcndfaXNfbG9ja2Vk
KHgpICgoeCktPmxvY2sgIT0gMCkKLSNkZWZpbmUgX3Jhd19yd19pc193cml0
ZV9sb2NrZWQoeCkgKCh4KS0+bG9jayA9PSAweDgwMDAwMDAwKQotCiAjZW5k
aWYgLyogX19BU01fU1BJTkxPQ0tfSCAqLwogLyoKICAqIExvY2FsIHZhcmlh
YmxlczoKLS0tIGEveGVuL2luY2x1ZGUvYXNtLWFybS9hcm02NC9zcGlubG9j
ay5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vYXJtNjQvc3BpbmxvY2su
aApAQCAtNTIsNjkgKzUyLDYgQEAgc3RhdGljIGFsd2F5c19pbmxpbmUgaW50
IF9yYXdfc3Bpbl90cnlsbwogICAgIHJldHVybiAhdG1wOwogfQogCi10eXBl
ZGVmIHN0cnVjdCB7Ci0gICAgdm9sYXRpbGUgdW5zaWduZWQgaW50IGxvY2s7
Ci19IHJhd19yd2xvY2tfdDsKLQotI2RlZmluZSBfUkFXX1JXX0xPQ0tfVU5M
T0NLRUQgeyAwIH0KLQotc3RhdGljIGFsd2F5c19pbmxpbmUgaW50IF9yYXdf
cmVhZF90cnlsb2NrKHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgdW5zaWdu
ZWQgaW50IHRtcCwgdG1wMiA9IDE7Ci0KLSAgICBhc20gdm9sYXRpbGUoCi0g
ICAgICAgICIgICAgICAgbGRheHIgICAldzAsICUyXG4iCi0gICAgICAgICIg
ICAgICAgYWRkICAgICAldzAsICV3MCwgIzFcbiIKLSAgICAgICAgIiAgICAg
ICB0Ym56ICAgICV3MCwgIzMxLCAxZlxuIgotICAgICAgICAiICAgICAgIHN0
eHIgICAgJXcxLCAldzAsICUyXG4iCi0gICAgICAgICIxOlxuIgotICAgICAg
ICA6ICI9JnIiICh0bXApLCAiK3IiICh0bXAyKSwgIitRIiAocnctPmxvY2sp
Ci0gICAgICAgIDoKLSAgICAgICAgOiAibWVtb3J5Iik7Ci0KLSAgICByZXR1
cm4gIXRtcDI7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3
X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNp
Z25lZCBpbnQgdG1wOwotCi0gICAgYXNtIHZvbGF0aWxlKAotICAgICAgICAi
ICAgICAgIGxkYXhyICAgJXcwLCAlMVxuIgotICAgICAgICAiICAgICAgIGNi
bnogICAgJXcwLCAxZlxuIgotICAgICAgICAiICAgICAgIHN0eHIgICAgJXcw
LCAldzIsICUxXG4iCi0gICAgICAgICIxOlxuIgotICAgICAgICA6ICI9JnIi
ICh0bXApLCAiK1EiIChydy0+bG9jaykKLSAgICAgICAgOiAiciIgKDB4ODAw
MDAwMDApCi0gICAgICAgIDogIm1lbW9yeSIpOwotCi0gICAgcmV0dXJuICF0
bXA7Ci19Ci0KLXN0YXRpYyBpbmxpbmUgdm9pZCBfcmF3X3JlYWRfdW5sb2Nr
KHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgdW5zaWduZWQgaW50IHRtcCwg
dG1wMjsKLQotICAgIGFzbSB2b2xhdGlsZSgKLSAgICAgICAgIiAgICAxOiBs
ZHhyICAgICV3MCwgJTJcbiIKLSAgICAgICAgIiAgICAgICBzdWIgICAgICV3
MCwgJXcwLCAjMVxuIgotICAgICAgICAiICAgICAgIHN0bHhyICAgJXcxLCAl
dzAsICUyXG4iCi0gICAgICAgICIgICAgICAgY2JueiAgICAldzEsIDFiXG4i
Ci0gICAgICAgIDogIj0mciIgKHRtcCksICI9JnIiICh0bXAyKSwgIitRIiAo
cnctPmxvY2spCi0gICAgICAgIDoKLSAgICAgICAgOiAibWVtb3J5Iik7Ci19
Ci0KLXN0YXRpYyBpbmxpbmUgdm9pZCBfcmF3X3dyaXRlX3VubG9jayhyYXdf
cndsb2NrX3QgKnJ3KQotewotICAgIGFzbSB2b2xhdGlsZSgKLSAgICAgICAg
IiAgICAgICBzdGxyICAgICV3MSwgJTBcbiIKLSAgICAgICAgOiAiPVEiIChy
dy0+bG9jaykgOiAiciIgKDApIDogIm1lbW9yeSIpOwotfQotCi0jZGVmaW5l
IF9yYXdfcndfaXNfbG9ja2VkKHgpICgoeCktPmxvY2sgIT0gMCkKLSNkZWZp
bmUgX3Jhd19yd19pc193cml0ZV9sb2NrZWQoeCkgKCh4KS0+bG9jayA9PSAw
eDgwMDAwMDAwKQotCiAjZW5kaWYgLyogX19BU01fU1BJTkxPQ0tfSCAqLwog
LyoKICAqIExvY2FsIHZhcmlhYmxlczoKLS0tIGEveGVuL2luY2x1ZGUvYXNt
LXg4Ni9zcGlubG9jay5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvc3Bp
bmxvY2suaApAQCAtMzEsNTggKzMxLDQgQEAgc3RhdGljIGFsd2F5c19pbmxp
bmUgaW50IF9yYXdfc3Bpbl90cnlsbwogICAgIHJldHVybiAob2xkdmFsID4g
MCk7CiB9CiAKLXR5cGVkZWYgc3RydWN0IHsKLSAgICB2b2xhdGlsZSBpbnQg
bG9jazsKLX0gcmF3X3J3bG9ja190OwotCi0jZGVmaW5lIFJXX1dSSVRFX0JJ
QVMgMHg3ZmZmZmZmZgotI2RlZmluZSBfUkFXX1JXX0xPQ0tfVU5MT0NLRUQg
LyoocmF3X3J3bG9ja190KSovIHsgMCB9Ci0KLXN0YXRpYyBhbHdheXNfaW5s
aW5lIGludCBfcmF3X3JlYWRfdHJ5bG9jayhyYXdfcndsb2NrX3QgKnJ3KQot
ewotICAgIGludCBhY3F1aXJlZDsKLQotICAgIGFzbSB2b2xhdGlsZSAoCi0g
ICAgICAgICIgICAgbG9jazsgZGVjbCAlMCAgICAgICAgIFxuIgotICAgICAg
ICAiICAgIGpucyAyZiAgICAgICAgICAgICAgICBcbiIKLSNpZmRlZiBfX2Ns
YW5nX18gLyogY2xhbmcncyBidWlsdGluIGFzc2VtYmVyIGNhbid0IGRvIC5z
dWJzZWN0aW9uICovCi0gICAgICAgICIxOiAgLnB1c2hzZWN0aW9uIC5maXh1
cCxcImF4XCJcbiIKLSNlbHNlCi0gICAgICAgICIxOiAgLnN1YnNlY3Rpb24g
MSAgICAgICAgIFxuIgotI2VuZGlmCi0gICAgICAgICIyOiAgbG9jazsgaW5j
bCAlMCAgICAgICAgIFxuIgotICAgICAgICAiICAgIGRlY2wgJTEgICAgICAg
ICAgICAgICBcbiIKLSAgICAgICAgIiAgICBqbXAgMWIgICAgICAgICAgICAg
ICAgXG4iCi0jaWZkZWYgX19jbGFuZ19fCi0gICAgICAgICIgICAgLnBvcHNl
Y3Rpb24gICAgICAgICAgIFxuIgotI2Vsc2UKLSAgICAgICAgIiAgICAuc3Vi
c2VjdGlvbiAwICAgICAgICAgXG4iCi0jZW5kaWYKLSAgICAgICAgOiAiPW0i
IChydy0+bG9jayksICI9ciIgKGFjcXVpcmVkKSA6ICIxIiAoMSkgOiAibWVt
b3J5IiApOwotCi0gICAgcmV0dXJuIGFjcXVpcmVkOwotfQotCi1zdGF0aWMg
YWx3YXlzX2lubGluZSBpbnQgX3Jhd193cml0ZV90cnlsb2NrKHJhd19yd2xv
Y2tfdCAqcncpCi17Ci0gICAgcmV0dXJuIChjbXB4Y2hnKCZydy0+bG9jaywg
MCwgUldfV1JJVEVfQklBUykgPT0gMCk7Ci19Ci0KLXN0YXRpYyBhbHdheXNf
aW5saW5lIHZvaWQgX3Jhd19yZWFkX3VubG9jayhyYXdfcndsb2NrX3QgKnJ3
KQotewotICAgIGFzbSB2b2xhdGlsZSAoCi0gICAgICAgICJsb2NrIDsgaW5j
bCAlMCIKLSAgICAgICAgOiAiPW0iICgocncpLT5sb2NrKSA6IDogIm1lbW9y
eSIgKTsKLX0KLQotc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBfcmF3X3dy
aXRlX3VubG9jayhyYXdfcndsb2NrX3QgKnJ3KQotewotICAgIGFzbSB2b2xh
dGlsZSAoCi0gICAgICAgICJsb2NrIDsgc3VibCAlMSwlMCIKLSAgICAgICAg
OiAiPW0iICgocncpLT5sb2NrKSA6ICJpIiAoUldfV1JJVEVfQklBUykgOiAi
bWVtb3J5IiApOwotfQotCi0jZGVmaW5lIF9yYXdfcndfaXNfbG9ja2VkKHgp
ICgoeCktPmxvY2sgIT0gMCkKLSNkZWZpbmUgX3Jhd19yd19pc193cml0ZV9s
b2NrZWQoeCkgKCh4KS0+bG9jayA+IDApCi0KICNlbmRpZiAvKiBfX0FTTV9T
UElOTE9DS19IICovCi0tLSBhL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9jay5o
CisrKyBiL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9jay5oCkBAIC0xNDEsMTEg
KzE0MSwxMyBAQCB0eXBlZGVmIHN0cnVjdCBzcGlubG9jayB7CiAjZGVmaW5l
IHNwaW5fbG9ja19pbml0KGwpICgqKGwpID0gKHNwaW5sb2NrX3QpU1BJTl9M
T0NLX1VOTE9DS0VEKQogCiB0eXBlZGVmIHN0cnVjdCB7Ci0gICAgcmF3X3J3
bG9ja190IHJhdzsKKyAgICB2b2xhdGlsZSB1aW50MzJfdCBsb2NrOwogICAg
IHN0cnVjdCBsb2NrX2RlYnVnIGRlYnVnOwogfSByd2xvY2tfdDsKIAotI2Rl
ZmluZSBSV19MT0NLX1VOTE9DS0VEIHsgX1JBV19SV19MT0NLX1VOTE9DS0VE
LCBfTE9DS19ERUJVRyB9CisjZGVmaW5lIFJXX1dSSVRFX0ZMQUcgKDF1PDwz
MSkKKworI2RlZmluZSBSV19MT0NLX1VOTE9DS0VEIHsgMCwgX0xPQ0tfREVC
VUcgfQogI2RlZmluZSBERUZJTkVfUldMT0NLKGwpIHJ3bG9ja190IGwgPSBS
V19MT0NLX1VOTE9DS0VECiAjZGVmaW5lIHJ3bG9ja19pbml0KGwpICgqKGwp
ID0gKHJ3bG9ja190KVJXX0xPQ0tfVU5MT0NLRUQpCiAK

--=separator
Content-Type: application/octet-stream; name="xsa114-4.2.patch"
Content-Disposition: attachment; filename="xsa114-4.2.patch"
Content-Transfer-Encoding: base64

c3dpdGNoIHRvIHdyaXRlLWJpYXNlZCByL3cgbG9ja3MKClRoaXMgaXMgdG8g
aW1wcm92ZSBmYWlybmVzczogQSBwZXJtYW5lbnQgZmxvdyBvZiByZWFkIGFj
cXVpcmVzIGNhbgpvdGhlcndpc2UgbG9jayBvdXQgZXZlbnR1YWwgd3JpdGVy
cyBpbmRlZmluaXRlbHkuCgpUaGlzIGlzIFhTQS0xMTQgLyBDVkUtMjAxNC05
MDY1LgoKU2lnbmVkLW9mZi1ieTogS2VpciBGcmFzZXIgPGtlaXJAeGVuLm9y
Zz4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4KUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIz
QGNpdHJpeC5jb20+ClRlc3RlZC1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT4KCi0tLSBhL3hlbi9jb21tb24vc3Bpbmxv
Y2suYworKysgYi94ZW4vY29tbW9uL3NwaW5sb2NrLmMKQEAgLTI3MSwxMTIg
KzI3MSwxNTEgQEAgdm9pZCBfc3Bpbl91bmxvY2tfcmVjdXJzaXZlKHNwaW5s
b2NrX3QgKgogCiB2b2lkIF9yZWFkX2xvY2socndsb2NrX3QgKmxvY2spCiB7
CisgICAgdWludDMyX3QgeDsKKwogICAgIGNoZWNrX2xvY2soJmxvY2stPmRl
YnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3JlYWRfdHJ5bG9j
aygmbG9jay0+cmF3KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtl
bHkoX3Jhd19yd19pc193cml0ZV9sb2NrZWQoJmxvY2stPnJhdykpICkKKyAg
ICBkbyB7CisgICAgICAgIHdoaWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJX
X1dSSVRFX0ZMQUcgKQogICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0gICAg
fQorICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEp
ICE9IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBf
cmVhZF9sb2NrX2lycShyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgQVNTRVJUKGxvY2FsX2lycV9pc19lbmFibGVkKCkpOwog
ICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CiAgICAgY2hlY2tfbG9jaygmbG9j
ay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtlbHkoIV9yYXdfcmVhZF90
cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewotICAgICAgICBsb2NhbF9p
cnFfZW5hYmxlKCk7Ci0gICAgICAgIHdoaWxlICggbGlrZWx5KF9yYXdfcndf
aXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5yYXcpKSApCi0gICAgICAgICAgICBj
cHVfcmVsYXgoKTsKLSAgICAgICAgbG9jYWxfaXJxX2Rpc2FibGUoKTsKLSAg
ICB9CisgICAgZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykg
JiBSV19XUklURV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxv
Y2stPmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAg
Y3B1X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfZGlzYWJsZSgp
OworICAgICAgICB9CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2stPmxv
Y2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgpOwog
fQogCiB1bnNpZ25lZCBsb25nIF9yZWFkX2xvY2tfaXJxc2F2ZShyd2xvY2tf
dCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4OwogICAgIHVuc2lnbmVkIGxv
bmcgZmxhZ3M7CisKICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7CiAgICAg
Y2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtl
bHkoIV9yYXdfcmVhZF90cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewot
ICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7Ci0gICAgICAgIHdo
aWxlICggbGlrZWx5KF9yYXdfcndfaXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5y
YXcpKSApCi0gICAgICAgICAgICBjcHVfcmVsYXgoKTsKLSAgICAgICAgbG9j
YWxfaXJxX3NhdmUoZmxhZ3MpOwotICAgIH0KKyAgICBkbyB7CisgICAgICAg
IGlmICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAg
ICAgICB7CisgICAgICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CisgICAgICAgICAgICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19X
UklURV9GTEFHICkKKyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAg
ICAgICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgfQor
ICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEpICE9
IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gZmxh
Z3M7CiB9CiAKIGludCBfcmVhZF90cnlsb2NrKHJ3bG9ja190ICpsb2NrKQog
eworICAgIHVpbnQzMl90IHg7CisKICAgICBjaGVja19sb2NrKCZsb2NrLT5k
ZWJ1Zyk7Ci0gICAgaWYgKCAhX3Jhd19yZWFkX3RyeWxvY2soJmxvY2stPnJh
dykgKQotICAgICAgICByZXR1cm4gMDsKKyAgICBkbyB7CisgICAgICAgIGlm
ICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAg
ICAgICAgcmV0dXJuIDA7CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2st
PmxvY2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgp
OwogICAgIHJldHVybiAxOwogfQogCiB2b2lkIF9yZWFkX3VubG9jayhyd2xv
Y2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4LCB5OworCiAgICAgcHJl
ZW1wdF9lbmFibGUoKTsKLSAgICBfcmF3X3JlYWRfdW5sb2NrKCZsb2NrLT5y
YXcpOworICAgIHggPSBsb2NrLT5sb2NrOworICAgIHdoaWxlICggKHkgPSBj
bXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4LTEpKSAhPSB4ICkKKyAgICAgICAg
eCA9IHk7CiB9CiAKIHZvaWQgX3JlYWRfdW5sb2NrX2lycShyd2xvY2tfdCAq
bG9jaykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfcmVh
ZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxvY2sp
OwogICAgIGxvY2FsX2lycV9lbmFibGUoKTsKIH0KIAogdm9pZCBfcmVhZF91
bmxvY2tfaXJxcmVzdG9yZShyd2xvY2tfdCAqbG9jaywgdW5zaWduZWQgbG9u
ZyBmbGFncykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdf
cmVhZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxv
Y2spOwogICAgIGxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKIH0KIAogdm9p
ZCBfd3JpdGVfbG9jayhyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdo
aWxlICggdW5saWtlbHkoIV9yYXdfd3JpdGVfdHJ5bG9jaygmbG9jay0+cmF3
KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtlbHkoX3Jhd19yd19p
c19sb2NrZWQoJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIHdo
aWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQogICAg
ICAgICAgICAgY3B1X3JlbGF4KCk7CisgICAgfSB3aGlsZSAoIGNtcHhjaGco
JmxvY2stPmxvY2ssIHgsIHh8UldfV1JJVEVfRkxBRykgIT0geCApOworICAg
IHdoaWxlICggeCAhPSAwICkKKyAgICB7CisgICAgICAgIGNwdV9yZWxheCgp
OworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5SV19XUklURV9GTEFHOwog
ICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBfd3Jp
dGVfbG9ja19pcnEocndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3Qg
eDsKKwogICAgIEFTU0VSVChsb2NhbF9pcnFfaXNfZW5hYmxlZCgpKTsKICAg
ICBsb2NhbF9pcnFfZGlzYWJsZSgpOwogICAgIGNoZWNrX2xvY2soJmxvY2st
PmRlYnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3dyaXRlX3Ry
eWxvY2soJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIGlmICgg
KHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAgICB7
CisgICAgICAgICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CisgICAgICAgICAg
ICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklURV9GTEFHICkK
KyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAgICAgICAgICAgIGxv
Y2FsX2lycV9kaXNhYmxlKCk7CisgICAgICAgIH0KKyAgICB9IHdoaWxlICgg
Y21weGNoZygmbG9jay0+bG9jaywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4
ICk7CisgICAgd2hpbGUgKCB4ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3
X3J3X2lzX2xvY2tlZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1
X3JlbGF4KCk7Ci0gICAgICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CisgICAg
ICAgIGNwdV9yZWxheCgpOworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5S
V19XUklURV9GTEFHOwogICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsK
IH0KIAogdW5zaWduZWQgbG9uZyBfd3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9j
a190ICpsb2NrKQogeworICAgIHVpbnQzMl90IHg7CiAgICAgdW5zaWduZWQg
bG9uZyBmbGFnczsKKwogICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKICAg
ICBjaGVja19sb2NrKCZsb2NrLT5kZWJ1Zyk7Ci0gICAgd2hpbGUgKCB1bmxp
a2VseSghX3Jhd193cml0ZV90cnlsb2NrKCZsb2NrLT5yYXcpKSApCisgICAg
ZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklU
RV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9jYWxfaXJxX3Jl
c3RvcmUoZmxhZ3MpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxvY2st
PmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAgY3B1
X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7
CisgICAgICAgIH0KKyAgICB9IHdoaWxlICggY21weGNoZygmbG9jay0+bG9j
aywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4ICk7CisgICAgd2hpbGUgKCB4
ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh
Z3MpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3X3J3X2lzX2xvY2tl
ZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0g
ICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgY3B1X3Jl
bGF4KCk7CisgICAgICAgIHggPSBsb2NrLT5sb2NrICYgflJXX1dSSVRFX0ZM
QUc7CiAgICAgfQogICAgIHByZWVtcHRfZGlzYWJsZSgpOwogICAgIHJldHVy
biBmbGFnczsKQEAgLTM4NCw5ICs0MjMsMTMgQEAgdW5zaWduZWQgbG9uZyBf
d3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9jawogCiBpbnQgX3dyaXRlX3RyeWxv
Y2socndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3QgeDsKKwogICAg
IGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICBpZiAoICFfcmF3X3dy
aXRlX3RyeWxvY2soJmxvY2stPnJhdykgKQotICAgICAgICByZXR1cm4gMDsK
KyAgICBkbyB7CisgICAgICAgIGlmICggKHggPSBsb2NrLT5sb2NrKSAhPSAw
ICkKKyAgICAgICAgICAgIHJldHVybiAwOworICAgIH0gd2hpbGUgKCBjbXB4
Y2hnKCZsb2NrLT5sb2NrLCB4LCB4fFJXX1dSSVRFX0ZMQUcpICE9IHggKTsK
ICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gMTsKIH0KQEAg
LTM5NCwzMyArNDM3LDMyIEBAIGludCBfd3JpdGVfdHJ5bG9jayhyd2xvY2tf
dCAqbG9jaykKIHZvaWQgX3dyaXRlX3VubG9jayhyd2xvY2tfdCAqbG9jaykK
IHsKICAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfd3JpdGVfdW5s
b2NrKCZsb2NrLT5yYXcpOworICAgIGlmICggY21weGNoZygmbG9jay0+bG9j
aywgUldfV1JJVEVfRkxBRywgMCkgIT0gUldfV1JJVEVfRkxBRyApCisgICAg
ICAgIEJVRygpOwogfQogCiB2b2lkIF93cml0ZV91bmxvY2tfaXJxKHJ3bG9j
a190ICpsb2NrKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0gICAgX3Jh
d193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRlX3VubG9j
ayhsb2NrKTsKICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CiB9CiAKIHZvaWQg
X3dyaXRlX3VubG9ja19pcnFyZXN0b3JlKHJ3bG9ja190ICpsb2NrLCB1bnNp
Z25lZCBsb25nIGZsYWdzKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0g
ICAgX3Jhd193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRl
X3VubG9jayhsb2NrKTsKICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CiB9CiAKIGludCBfcndfaXNfbG9ja2VkKHJ3bG9ja190ICpsb2NrKQogewog
ICAgIGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICByZXR1cm4gX3Jh
d19yd19pc19sb2NrZWQoJmxvY2stPnJhdyk7CisgICAgcmV0dXJuIChsb2Nr
LT5sb2NrICE9IDApOyAvKiBhbnlvbmUgaW4gY3JpdGljYWwgc2VjdGlvbj8g
Ki8KIH0KIAogaW50IF9yd19pc193cml0ZV9sb2NrZWQocndsb2NrX3QgKmxv
Y2spCiB7CiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHJl
dHVybiBfcmF3X3J3X2lzX3dyaXRlX2xvY2tlZCgmbG9jay0+cmF3KTsKKyAg
ICByZXR1cm4gKGxvY2stPmxvY2sgPT0gUldfV1JJVEVfRkxBRyk7IC8qIHdy
aXRlciBpbiBjcml0aWNhbCBzZWN0aW9uPyAqLwogfQogCiAjaWZkZWYgTE9D
S19QUk9GSUxFCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vc3BpbmxvY2su
aAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL3NwaW5sb2NrLmgKQEAgLTU1
LDg0ICs1NSw2IEBAIHN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3X3Nw
aW5fdHJ5bG8KICAgICB9CiB9CiAKLXR5cGVkZWYgc3RydWN0IHsKLSAgICB2
b2xhdGlsZSB1bnNpZ25lZCBpbnQgbG9jazsKLX0gcmF3X3J3bG9ja190Owot
Ci0jZGVmaW5lIF9SQVdfUldfTE9DS19VTkxPQ0tFRCB7IDAgfQotCi1zdGF0
aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd19yZWFkX3RyeWxvY2socmF3X3J3
bG9ja190ICpydykKLXsKLSAgICB1bnNpZ25lZCBsb25nIHRtcCwgdG1wMiA9
IDE7Ci0KLSAgICBfX2FzbV9fIF9fdm9sYXRpbGVfXygKLSIxOiBsZHJleCAg
ICUwLCBbJTJdXG4iCi0iICAgYWRkcyAgICAlMCwgJTAsICMxXG4iCi0iICAg
c3RyZXhwbCAlMSwgJTAsIFslMl1cbiIKLSAgICA6ICI9JnIiICh0bXApLCAi
K3IiICh0bXAyKQotICAgIDogInIiICgmcnctPmxvY2spCi0gICAgOiAiY2Mi
KTsKLQotICAgIHNtcF9tYigpOwotICAgIHJldHVybiB0bXAyID09IDA7Ci19
Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3X3dyaXRlX3RyeWxv
Y2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNpZ25lZCBsb25nIHRt
cDsKLQotICAgIF9fYXNtX18gX192b2xhdGlsZV9fKAotIjE6IGxkcmV4ICAg
JTAsIFslMV1cbiIKLSIgICB0ZXEgICAgICUwLCAjMFxuIgotIiAgIHN0cmV4
ZXEgJTAsICUyLCBbJTFdIgotICAgIDogIj0mciIgKHRtcCkKLSAgICA6ICJy
IiAoJnJ3LT5sb2NrKSwgInIiICgweDgwMDAwMDAwKQotICAgIDogImNjIik7
Ci0KLSAgICBpZiAodG1wID09IDApIHsKLSAgICAgICAgc21wX21iKCk7Ci0g
ICAgICAgIHJldHVybiAxOwotICAgIH0gZWxzZSB7Ci0gICAgICAgIHJldHVy
biAwOwotICAgIH0KLX0KLQotc3RhdGljIGlubGluZSB2b2lkIF9yYXdfcmVh
ZF91bmxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNpZ25lZCBs
b25nIHRtcCwgdG1wMjsKLQotICAgIHNtcF9tYigpOwotCi0gICAgX19hc21f
XyBfX3ZvbGF0aWxlX18oCi0iMTogbGRyZXggICAlMCwgWyUyXVxuIgotIiAg
IHN1YiAgICAgJTAsICUwLCAjMVxuIgotIiAgIHN0cmV4ICAgJTEsICUwLCBb
JTJdXG4iCi0iICAgdGVxICAgICAlMSwgIzBcbiIKLSIgICBibmUgICAgIDFi
IgotICAgIDogIj0mciIgKHRtcCksICI9JnIiICh0bXAyKQotICAgIDogInIi
ICgmcnctPmxvY2spCi0gICAgOiAiY2MiKTsKLQotICAgIGlmICh0bXAgPT0g
MCkKLSAgICAgICAgZHNiX3NldigpOwotfQotCi1zdGF0aWMgaW5saW5lIHZv
aWQgX3Jhd193cml0ZV91bmxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAg
ICBzbXBfbWIoKTsKLQotICAgIF9fYXNtX18gX192b2xhdGlsZV9fKAotICAg
ICJzdHIgICAgJTEsIFslMF1cbiIKLSAgICA6Ci0gICAgOiAiciIgKCZydy0+
bG9jayksICJyIiAoMCkKLSAgICA6ICJjYyIpOwotCi0gICAgZHNiX3Nldigp
OwotfQotCi0jZGVmaW5lIF9yYXdfcndfaXNfbG9ja2VkKHgpICgoeCktPmxv
Y2sgIT0gMCkKLSNkZWZpbmUgX3Jhd19yd19pc193cml0ZV9sb2NrZWQoeCkg
KCh4KS0+bG9jayA9PSAweDgwMDAwMDAwKQotCiAjZW5kaWYgLyogX19BU01f
U1BJTkxPQ0tfSCAqLwogLyoKICAqIExvY2FsIHZhcmlhYmxlczoKLS0tIGEv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGlubG9jay5oCisrKyBiL3hlbi9pbmNs
dWRlL2FzbS14ODYvc3BpbmxvY2suaApAQCAtMzEsNTggKzMxLDQgQEAgc3Rh
dGljIGFsd2F5c19pbmxpbmUgaW50IF9yYXdfc3Bpbl90cnlsbwogICAgIHJl
dHVybiAob2xkdmFsID4gMCk7CiB9CiAKLXR5cGVkZWYgc3RydWN0IHsKLSAg
ICB2b2xhdGlsZSBpbnQgbG9jazsKLX0gcmF3X3J3bG9ja190OwotCi0jZGVm
aW5lIFJXX1dSSVRFX0JJQVMgMHg3ZmZmZmZmZgotI2RlZmluZSBfUkFXX1JX
X0xPQ0tfVU5MT0NLRUQgLyoocmF3X3J3bG9ja190KSovIHsgMCB9Ci0KLXN0
YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3X3JlYWRfdHJ5bG9jayhyYXdf
cndsb2NrX3QgKnJ3KQotewotICAgIGludCBhY3F1aXJlZDsKLQotICAgIGFz
bSB2b2xhdGlsZSAoCi0gICAgICAgICIgICAgbG9jazsgZGVjbCAlMCAgICAg
ICAgIFxuIgotICAgICAgICAiICAgIGpucyAyZiAgICAgICAgICAgICAgICBc
biIKLSNpZmRlZiBfX2NsYW5nX18gLyogY2xhbmcncyBidWlsdGluIGFzc2Vt
YmVyIGNhbid0IGRvIC5zdWJzZWN0aW9uICovCi0gICAgICAgICIxOiAgLnB1
c2hzZWN0aW9uIC5maXh1cCxcImF4XCJcbiIKLSNlbHNlCi0gICAgICAgICIx
OiAgLnN1YnNlY3Rpb24gMSAgICAgICAgIFxuIgotI2VuZGlmCi0gICAgICAg
ICIyOiAgbG9jazsgaW5jbCAlMCAgICAgICAgIFxuIgotICAgICAgICAiICAg
IGRlY2wgJTEgICAgICAgICAgICAgICBcbiIKLSAgICAgICAgIiAgICBqbXAg
MWIgICAgICAgICAgICAgICAgXG4iCi0jaWZkZWYgX19jbGFuZ19fCi0gICAg
ICAgICIgICAgLnBvcHNlY3Rpb24gICAgICAgICAgIFxuIgotI2Vsc2UKLSAg
ICAgICAgIiAgICAuc3Vic2VjdGlvbiAwICAgICAgICAgXG4iCi0jZW5kaWYK
LSAgICAgICAgOiAiPW0iIChydy0+bG9jayksICI9ciIgKGFjcXVpcmVkKSA6
ICIxIiAoMSkgOiAibWVtb3J5IiApOwotCi0gICAgcmV0dXJuIGFjcXVpcmVk
OwotfQotCi1zdGF0aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd193cml0ZV90
cnlsb2NrKHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgcmV0dXJuIChjbXB4
Y2hnKCZydy0+bG9jaywgMCwgUldfV1JJVEVfQklBUykgPT0gMCk7Ci19Ci0K
LXN0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgX3Jhd19yZWFkX3VubG9jayhy
YXdfcndsb2NrX3QgKnJ3KQotewotICAgIGFzbSB2b2xhdGlsZSAoCi0gICAg
ICAgICJsb2NrIDsgaW5jbCAlMCIKLSAgICAgICAgOiAiPW0iICgocncpLT5s
b2NrKSA6IDogIm1lbW9yeSIgKTsKLX0KLQotc3RhdGljIGFsd2F5c19pbmxp
bmUgdm9pZCBfcmF3X3dyaXRlX3VubG9jayhyYXdfcndsb2NrX3QgKnJ3KQot
ewotICAgIGFzbSB2b2xhdGlsZSAoCi0gICAgICAgICJsb2NrIDsgc3VibCAl
MSwlMCIKLSAgICAgICAgOiAiPW0iICgocncpLT5sb2NrKSA6ICJpIiAoUldf
V1JJVEVfQklBUykgOiAibWVtb3J5IiApOwotfQotCi0jZGVmaW5lIF9yYXdf
cndfaXNfbG9ja2VkKHgpICgoeCktPmxvY2sgIT0gMCkKLSNkZWZpbmUgX3Jh
d19yd19pc193cml0ZV9sb2NrZWQoeCkgKCh4KS0+bG9jayA+IDApCi0KICNl
bmRpZiAvKiBfX0FTTV9TUElOTE9DS19IICovCi0tLSBhL3hlbi9pbmNsdWRl
L3hlbi9zcGlubG9jay5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9zcGlubG9j
ay5oCkBAIC0xNDEsMTEgKzE0MSwxMyBAQCB0eXBlZGVmIHN0cnVjdCBzcGlu
bG9jayB7CiAjZGVmaW5lIHNwaW5fbG9ja19pbml0KGwpICgqKGwpID0gKHNw
aW5sb2NrX3QpU1BJTl9MT0NLX1VOTE9DS0VEKQogCiB0eXBlZGVmIHN0cnVj
dCB7Ci0gICAgcmF3X3J3bG9ja190IHJhdzsKKyAgICB2b2xhdGlsZSB1aW50
MzJfdCBsb2NrOwogICAgIHN0cnVjdCBsb2NrX2RlYnVnIGRlYnVnOwogfSBy
d2xvY2tfdDsKIAotI2RlZmluZSBSV19MT0NLX1VOTE9DS0VEIHsgX1JBV19S
V19MT0NLX1VOTE9DS0VELCBfTE9DS19ERUJVRyB9CisjZGVmaW5lIFJXX1dS
SVRFX0ZMQUcgKDF1PDwzMSkKKworI2RlZmluZSBSV19MT0NLX1VOTE9DS0VE
IHsgMCwgX0xPQ0tfREVCVUcgfQogI2RlZmluZSBERUZJTkVfUldMT0NLKGwp
IHJ3bG9ja190IGwgPSBSV19MT0NLX1VOTE9DS0VECiAjZGVmaW5lIHJ3bG9j
a19pbml0KGwpICgqKGwpID0gKHJ3bG9ja190KVJXX0xPQ0tfVU5MT0NLRUQp
CiAK

--=separator
Content-Type: application/octet-stream; name="xsa114-4.3.patch"
Content-Disposition: attachment; filename="xsa114-4.3.patch"
Content-Transfer-Encoding: base64

c3dpdGNoIHRvIHdyaXRlLWJpYXNlZCByL3cgbG9ja3MKClRoaXMgaXMgdG8g
aW1wcm92ZSBmYWlybmVzczogQSBwZXJtYW5lbnQgZmxvdyBvZiByZWFkIGFj
cXVpcmVzIGNhbgpvdGhlcndpc2UgbG9jayBvdXQgZXZlbnR1YWwgd3JpdGVy
cyBpbmRlZmluaXRlbHkuCgpUaGlzIGlzIFhTQS0xMTQgLyBDVkUtMjAxNC05
MDY1LgoKU2lnbmVkLW9mZi1ieTogS2VpciBGcmFzZXIgPGtlaXJAeGVuLm9y
Zz4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4KUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIz
QGNpdHJpeC5jb20+ClRlc3RlZC1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT4KCi0tLSBhL3hlbi9jb21tb24vc3Bpbmxv
Y2suYworKysgYi94ZW4vY29tbW9uL3NwaW5sb2NrLmMKQEAgLTI3MSwxMTIg
KzI3MSwxNTEgQEAgdm9pZCBfc3Bpbl91bmxvY2tfcmVjdXJzaXZlKHNwaW5s
b2NrX3QgKgogCiB2b2lkIF9yZWFkX2xvY2socndsb2NrX3QgKmxvY2spCiB7
CisgICAgdWludDMyX3QgeDsKKwogICAgIGNoZWNrX2xvY2soJmxvY2stPmRl
YnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3JlYWRfdHJ5bG9j
aygmbG9jay0+cmF3KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtl
bHkoX3Jhd19yd19pc193cml0ZV9sb2NrZWQoJmxvY2stPnJhdykpICkKKyAg
ICBkbyB7CisgICAgICAgIHdoaWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJX
X1dSSVRFX0ZMQUcgKQogICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0gICAg
fQorICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEp
ICE9IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBf
cmVhZF9sb2NrX2lycShyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgQVNTRVJUKGxvY2FsX2lycV9pc19lbmFibGVkKCkpOwog
ICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CiAgICAgY2hlY2tfbG9jaygmbG9j
ay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtlbHkoIV9yYXdfcmVhZF90
cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewotICAgICAgICBsb2NhbF9p
cnFfZW5hYmxlKCk7Ci0gICAgICAgIHdoaWxlICggbGlrZWx5KF9yYXdfcndf
aXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5yYXcpKSApCi0gICAgICAgICAgICBj
cHVfcmVsYXgoKTsKLSAgICAgICAgbG9jYWxfaXJxX2Rpc2FibGUoKTsKLSAg
ICB9CisgICAgZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykg
JiBSV19XUklURV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxv
Y2stPmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAg
Y3B1X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfZGlzYWJsZSgp
OworICAgICAgICB9CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2stPmxv
Y2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgpOwog
fQogCiB1bnNpZ25lZCBsb25nIF9yZWFkX2xvY2tfaXJxc2F2ZShyd2xvY2tf
dCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4OwogICAgIHVuc2lnbmVkIGxv
bmcgZmxhZ3M7CisKICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7CiAgICAg
Y2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtl
bHkoIV9yYXdfcmVhZF90cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewot
ICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7Ci0gICAgICAgIHdo
aWxlICggbGlrZWx5KF9yYXdfcndfaXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5y
YXcpKSApCi0gICAgICAgICAgICBjcHVfcmVsYXgoKTsKLSAgICAgICAgbG9j
YWxfaXJxX3NhdmUoZmxhZ3MpOwotICAgIH0KKyAgICBkbyB7CisgICAgICAg
IGlmICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAg
ICAgICB7CisgICAgICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CisgICAgICAgICAgICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19X
UklURV9GTEFHICkKKyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAg
ICAgICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgfQor
ICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEpICE9
IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gZmxh
Z3M7CiB9CiAKIGludCBfcmVhZF90cnlsb2NrKHJ3bG9ja190ICpsb2NrKQog
eworICAgIHVpbnQzMl90IHg7CisKICAgICBjaGVja19sb2NrKCZsb2NrLT5k
ZWJ1Zyk7Ci0gICAgaWYgKCAhX3Jhd19yZWFkX3RyeWxvY2soJmxvY2stPnJh
dykgKQotICAgICAgICByZXR1cm4gMDsKKyAgICBkbyB7CisgICAgICAgIGlm
ICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAg
ICAgICAgcmV0dXJuIDA7CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2st
PmxvY2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgp
OwogICAgIHJldHVybiAxOwogfQogCiB2b2lkIF9yZWFkX3VubG9jayhyd2xv
Y2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4LCB5OworCiAgICAgcHJl
ZW1wdF9lbmFibGUoKTsKLSAgICBfcmF3X3JlYWRfdW5sb2NrKCZsb2NrLT5y
YXcpOworICAgIHggPSBsb2NrLT5sb2NrOworICAgIHdoaWxlICggKHkgPSBj
bXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4LTEpKSAhPSB4ICkKKyAgICAgICAg
eCA9IHk7CiB9CiAKIHZvaWQgX3JlYWRfdW5sb2NrX2lycShyd2xvY2tfdCAq
bG9jaykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfcmVh
ZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxvY2sp
OwogICAgIGxvY2FsX2lycV9lbmFibGUoKTsKIH0KIAogdm9pZCBfcmVhZF91
bmxvY2tfaXJxcmVzdG9yZShyd2xvY2tfdCAqbG9jaywgdW5zaWduZWQgbG9u
ZyBmbGFncykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdf
cmVhZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxv
Y2spOwogICAgIGxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKIH0KIAogdm9p
ZCBfd3JpdGVfbG9jayhyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdo
aWxlICggdW5saWtlbHkoIV9yYXdfd3JpdGVfdHJ5bG9jaygmbG9jay0+cmF3
KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtlbHkoX3Jhd19yd19p
c19sb2NrZWQoJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIHdo
aWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQogICAg
ICAgICAgICAgY3B1X3JlbGF4KCk7CisgICAgfSB3aGlsZSAoIGNtcHhjaGco
JmxvY2stPmxvY2ssIHgsIHh8UldfV1JJVEVfRkxBRykgIT0geCApOworICAg
IHdoaWxlICggeCAhPSAwICkKKyAgICB7CisgICAgICAgIGNwdV9yZWxheCgp
OworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5SV19XUklURV9GTEFHOwog
ICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBfd3Jp
dGVfbG9ja19pcnEocndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3Qg
eDsKKwogICAgIEFTU0VSVChsb2NhbF9pcnFfaXNfZW5hYmxlZCgpKTsKICAg
ICBsb2NhbF9pcnFfZGlzYWJsZSgpOwogICAgIGNoZWNrX2xvY2soJmxvY2st
PmRlYnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3dyaXRlX3Ry
eWxvY2soJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIGlmICgg
KHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAgICB7
CisgICAgICAgICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CisgICAgICAgICAg
ICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklURV9GTEFHICkK
KyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAgICAgICAgICAgIGxv
Y2FsX2lycV9kaXNhYmxlKCk7CisgICAgICAgIH0KKyAgICB9IHdoaWxlICgg
Y21weGNoZygmbG9jay0+bG9jaywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4
ICk7CisgICAgd2hpbGUgKCB4ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3
X3J3X2lzX2xvY2tlZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1
X3JlbGF4KCk7Ci0gICAgICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CisgICAg
ICAgIGNwdV9yZWxheCgpOworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5S
V19XUklURV9GTEFHOwogICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsK
IH0KIAogdW5zaWduZWQgbG9uZyBfd3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9j
a190ICpsb2NrKQogeworICAgIHVpbnQzMl90IHg7CiAgICAgdW5zaWduZWQg
bG9uZyBmbGFnczsKKwogICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKICAg
ICBjaGVja19sb2NrKCZsb2NrLT5kZWJ1Zyk7Ci0gICAgd2hpbGUgKCB1bmxp
a2VseSghX3Jhd193cml0ZV90cnlsb2NrKCZsb2NrLT5yYXcpKSApCisgICAg
ZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklU
RV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9jYWxfaXJxX3Jl
c3RvcmUoZmxhZ3MpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxvY2st
PmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAgY3B1
X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7
CisgICAgICAgIH0KKyAgICB9IHdoaWxlICggY21weGNoZygmbG9jay0+bG9j
aywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4ICk7CisgICAgd2hpbGUgKCB4
ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh
Z3MpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3X3J3X2lzX2xvY2tl
ZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0g
ICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgY3B1X3Jl
bGF4KCk7CisgICAgICAgIHggPSBsb2NrLT5sb2NrICYgflJXX1dSSVRFX0ZM
QUc7CiAgICAgfQogICAgIHByZWVtcHRfZGlzYWJsZSgpOwogICAgIHJldHVy
biBmbGFnczsKQEAgLTM4NCw5ICs0MjMsMTMgQEAgdW5zaWduZWQgbG9uZyBf
d3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9jawogCiBpbnQgX3dyaXRlX3RyeWxv
Y2socndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3QgeDsKKwogICAg
IGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICBpZiAoICFfcmF3X3dy
aXRlX3RyeWxvY2soJmxvY2stPnJhdykgKQotICAgICAgICByZXR1cm4gMDsK
KyAgICBkbyB7CisgICAgICAgIGlmICggKHggPSBsb2NrLT5sb2NrKSAhPSAw
ICkKKyAgICAgICAgICAgIHJldHVybiAwOworICAgIH0gd2hpbGUgKCBjbXB4
Y2hnKCZsb2NrLT5sb2NrLCB4LCB4fFJXX1dSSVRFX0ZMQUcpICE9IHggKTsK
ICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gMTsKIH0KQEAg
LTM5NCwzMyArNDM3LDMyIEBAIGludCBfd3JpdGVfdHJ5bG9jayhyd2xvY2tf
dCAqbG9jaykKIHZvaWQgX3dyaXRlX3VubG9jayhyd2xvY2tfdCAqbG9jaykK
IHsKICAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfd3JpdGVfdW5s
b2NrKCZsb2NrLT5yYXcpOworICAgIGlmICggY21weGNoZygmbG9jay0+bG9j
aywgUldfV1JJVEVfRkxBRywgMCkgIT0gUldfV1JJVEVfRkxBRyApCisgICAg
ICAgIEJVRygpOwogfQogCiB2b2lkIF93cml0ZV91bmxvY2tfaXJxKHJ3bG9j
a190ICpsb2NrKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0gICAgX3Jh
d193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRlX3VubG9j
ayhsb2NrKTsKICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CiB9CiAKIHZvaWQg
X3dyaXRlX3VubG9ja19pcnFyZXN0b3JlKHJ3bG9ja190ICpsb2NrLCB1bnNp
Z25lZCBsb25nIGZsYWdzKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0g
ICAgX3Jhd193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRl
X3VubG9jayhsb2NrKTsKICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CiB9CiAKIGludCBfcndfaXNfbG9ja2VkKHJ3bG9ja190ICpsb2NrKQogewog
ICAgIGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICByZXR1cm4gX3Jh
d19yd19pc19sb2NrZWQoJmxvY2stPnJhdyk7CisgICAgcmV0dXJuIChsb2Nr
LT5sb2NrICE9IDApOyAvKiBhbnlvbmUgaW4gY3JpdGljYWwgc2VjdGlvbj8g
Ki8KIH0KIAogaW50IF9yd19pc193cml0ZV9sb2NrZWQocndsb2NrX3QgKmxv
Y2spCiB7CiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHJl
dHVybiBfcmF3X3J3X2lzX3dyaXRlX2xvY2tlZCgmbG9jay0+cmF3KTsKKyAg
ICByZXR1cm4gKGxvY2stPmxvY2sgPT0gUldfV1JJVEVfRkxBRyk7IC8qIHdy
aXRlciBpbiBjcml0aWNhbCBzZWN0aW9uPyAqLwogfQogCiAjaWZkZWYgTE9D
S19QUk9GSUxFCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vYXJtMzIvc3Bp
bmxvY2suaAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2FybTMyL3NwaW5s
b2NrLmgKQEAgLTUyLDg0ICs1Miw2IEBAIHN0YXRpYyBhbHdheXNfaW5saW5l
IGludCBfcmF3X3NwaW5fdHJ5bG8KICAgICB9CiB9CiAKLXR5cGVkZWYgc3Ry
dWN0IHsKLSAgICB2b2xhdGlsZSB1bnNpZ25lZCBpbnQgbG9jazsKLX0gcmF3
X3J3bG9ja190OwotCi0jZGVmaW5lIF9SQVdfUldfTE9DS19VTkxPQ0tFRCB7
IDAgfQotCi1zdGF0aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd19yZWFkX3Ry
eWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNpZ25lZCBsb25n
IHRtcCwgdG1wMiA9IDE7Ci0KLSAgICBfX2FzbV9fIF9fdm9sYXRpbGVfXygK
LSIxOiBsZHJleCAgICUwLCBbJTJdXG4iCi0iICAgYWRkcyAgICAlMCwgJTAs
ICMxXG4iCi0iICAgc3RyZXhwbCAlMSwgJTAsIFslMl1cbiIKLSAgICA6ICI9
JnIiICh0bXApLCAiK3IiICh0bXAyKQotICAgIDogInIiICgmcnctPmxvY2sp
Ci0gICAgOiAiY2MiKTsKLQotICAgIHNtcF9tYigpOwotICAgIHJldHVybiB0
bXAyID09IDA7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3
X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNp
Z25lZCBsb25nIHRtcDsKLQotICAgIF9fYXNtX18gX192b2xhdGlsZV9fKAot
IjE6IGxkcmV4ICAgJTAsIFslMV1cbiIKLSIgICB0ZXEgICAgICUwLCAjMFxu
IgotIiAgIHN0cmV4ZXEgJTAsICUyLCBbJTFdIgotICAgIDogIj0mciIgKHRt
cCkKLSAgICA6ICJyIiAoJnJ3LT5sb2NrKSwgInIiICgweDgwMDAwMDAwKQot
ICAgIDogImNjIik7Ci0KLSAgICBpZiAodG1wID09IDApIHsKLSAgICAgICAg
c21wX21iKCk7Ci0gICAgICAgIHJldHVybiAxOwotICAgIH0gZWxzZSB7Ci0g
ICAgICAgIHJldHVybiAwOwotICAgIH0KLX0KLQotc3RhdGljIGlubGluZSB2
b2lkIF9yYXdfcmVhZF91bmxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAg
ICB1bnNpZ25lZCBsb25nIHRtcCwgdG1wMjsKLQotICAgIHNtcF9tYigpOwot
Ci0gICAgX19hc21fXyBfX3ZvbGF0aWxlX18oCi0iMTogbGRyZXggICAlMCwg
WyUyXVxuIgotIiAgIHN1YiAgICAgJTAsICUwLCAjMVxuIgotIiAgIHN0cmV4
ICAgJTEsICUwLCBbJTJdXG4iCi0iICAgdGVxICAgICAlMSwgIzBcbiIKLSIg
ICBibmUgICAgIDFiIgotICAgIDogIj0mciIgKHRtcCksICI9JnIiICh0bXAy
KQotICAgIDogInIiICgmcnctPmxvY2spCi0gICAgOiAiY2MiKTsKLQotICAg
IGlmICh0bXAgPT0gMCkKLSAgICAgICAgZHNiX3NldigpOwotfQotCi1zdGF0
aWMgaW5saW5lIHZvaWQgX3Jhd193cml0ZV91bmxvY2socmF3X3J3bG9ja190
ICpydykKLXsKLSAgICBzbXBfbWIoKTsKLQotICAgIF9fYXNtX18gX192b2xh
dGlsZV9fKAotICAgICJzdHIgICAgJTEsIFslMF1cbiIKLSAgICA6Ci0gICAg
OiAiciIgKCZydy0+bG9jayksICJyIiAoMCkKLSAgICA6ICJjYyIpOwotCi0g
ICAgZHNiX3NldigpOwotfQotCi0jZGVmaW5lIF9yYXdfcndfaXNfbG9ja2Vk
KHgpICgoeCktPmxvY2sgIT0gMCkKLSNkZWZpbmUgX3Jhd19yd19pc193cml0
ZV9sb2NrZWQoeCkgKCh4KS0+bG9jayA9PSAweDgwMDAwMDAwKQotCiAjZW5k
aWYgLyogX19BU01fU1BJTkxPQ0tfSCAqLwogLyoKICAqIExvY2FsIHZhcmlh
YmxlczoKLS0tIGEveGVuL2luY2x1ZGUvYXNtLWFybS9hcm02NC9zcGlubG9j
ay5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vYXJtNjQvc3BpbmxvY2su
aApAQCAtNTEsNjkgKzUxLDYgQEAgc3RhdGljIGFsd2F5c19pbmxpbmUgaW50
IF9yYXdfc3Bpbl90cnlsbwogICAgIHJldHVybiAhdG1wOwogfQogCi10eXBl
ZGVmIHN0cnVjdCB7Ci0gICAgdm9sYXRpbGUgdW5zaWduZWQgaW50IGxvY2s7
Ci19IHJhd19yd2xvY2tfdDsKLQotI2RlZmluZSBfUkFXX1JXX0xPQ0tfVU5M
T0NLRUQgeyAwIH0KLQotc3RhdGljIGFsd2F5c19pbmxpbmUgaW50IF9yYXdf
cmVhZF90cnlsb2NrKHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgdW5zaWdu
ZWQgaW50IHRtcCwgdG1wMiA9IDE7Ci0KLSAgICBhc20gdm9sYXRpbGUoCi0g
ICAgICAgICIgICAgICAgbGRheHIgICAldzAsIFslMl1cbiIKLSAgICAgICAg
IiAgICAgICBhZGQgICAgICV3MCwgJXcwLCAjMVxuIgotICAgICAgICAiICAg
ICAgIHRibnogICAgJXcwLCAjMzEsIDFmXG4iCi0gICAgICAgICIgICAgICAg
c3R4ciAgICAldzEsICV3MCwgWyUyXVxuIgotICAgICAgICAiMTpcbiIKLSAg
ICAgICAgOiAiPSZyIiAodG1wKSwgIityIiAodG1wMikKLSAgICAgICAgOiAi
ciIgKCZydy0+bG9jaykKLSAgICAgICAgOiAibWVtb3J5Iik7Ci0KLSAgICBy
ZXR1cm4gIXRtcDI7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBf
cmF3X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1
bnNpZ25lZCBpbnQgdG1wOwotCi0gICAgYXNtIHZvbGF0aWxlKAotICAgICAg
ICAiICAgICAgIGxkYXhyICAgJXcwLCBbJTFdXG4iCi0gICAgICAgICIgICAg
ICAgY2JueiAgICAldzAsIDFmXG4iCi0gICAgICAgICIgICAgICAgc3R4ciAg
ICAldzAsICV3MiwgWyUxXVxuIgotICAgICAgICAiMTpcbiIKLSAgICAgICAg
OiAiPSZyIiAodG1wKQotICAgICAgICA6ICJyIiAoJnJ3LT5sb2NrKSwgInIi
ICgweDgwMDAwMDAwKQotICAgICAgICA6ICJtZW1vcnkiKTsKLQotICAgIHJl
dHVybiAhdG1wOwotfQotCi1zdGF0aWMgaW5saW5lIHZvaWQgX3Jhd19yZWFk
X3VubG9jayhyYXdfcndsb2NrX3QgKnJ3KQotewotICAgIHVuc2lnbmVkIGlu
dCB0bXAsIHRtcDI7Ci0KLSAgICBhc20gdm9sYXRpbGUoCi0gICAgICAgICIx
OiAgICAgbGR4ciAgICAldzAsIFslMl1cbiIKLSAgICAgICAgIiAgICAgICBz
dWIgICAgICV3MCwgJXcwLCAjMVxuIgotICAgICAgICAiICAgICAgIHN0bHhy
ICAgJXcxLCAldzAsIFslMl1cbiIKLSAgICAgICAgIiAgICAgICBjYm56ICAg
ICV3MSwgMWJcbiIKLSAgICAgICAgOiAiPSZyIiAodG1wKSwgIj0mciIgKHRt
cDIpCi0gICAgICAgIDogInIiICgmcnctPmxvY2spCi0gICAgICAgIDogIm1l
bW9yeSIpOwotfQotCi1zdGF0aWMgaW5saW5lIHZvaWQgX3Jhd193cml0ZV91
bmxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICBhc20gdm9sYXRpbGUo
Ci0gICAgICAgICIgICAgICAgc3RsciAgICAldzEsIFslMF1cbiIKLSAgICAg
ICAgOiA6ICJyIiAoJnJ3LT5sb2NrKSwgInIiICgwKSA6ICJtZW1vcnkiKTsK
LX0KLQotI2RlZmluZSBfcmF3X3J3X2lzX2xvY2tlZCh4KSAoKHgpLT5sb2Nr
ICE9IDApCi0jZGVmaW5lIF9yYXdfcndfaXNfd3JpdGVfbG9ja2VkKHgpICgo
eCktPmxvY2sgPT0gMHg4MDAwMDAwMCkKLQogI2VuZGlmIC8qIF9fQVNNX1NQ
SU5MT0NLX0ggKi8KIC8qCiAgKiBMb2NhbCB2YXJpYWJsZXM6Ci0tLSBhL3hl
bi9pbmNsdWRlL2FzbS14ODYvc3BpbmxvY2suaAorKysgYi94ZW4vaW5jbHVk
ZS9hc20teDg2L3NwaW5sb2NrLmgKQEAgLTMxLDU4ICszMSw0IEBAIHN0YXRp
YyBhbHdheXNfaW5saW5lIGludCBfcmF3X3NwaW5fdHJ5bG8KICAgICByZXR1
cm4gKG9sZHZhbCA+IDApOwogfQogCi10eXBlZGVmIHN0cnVjdCB7Ci0gICAg
dm9sYXRpbGUgaW50IGxvY2s7Ci19IHJhd19yd2xvY2tfdDsKLQotI2RlZmlu
ZSBSV19XUklURV9CSUFTIDB4N2ZmZmZmZmYKLSNkZWZpbmUgX1JBV19SV19M
T0NLX1VOTE9DS0VEIC8qKHJhd19yd2xvY2tfdCkqLyB7IDAgfQotCi1zdGF0
aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd19yZWFkX3RyeWxvY2socmF3X3J3
bG9ja190ICpydykKLXsKLSAgICBpbnQgYWNxdWlyZWQ7Ci0KLSAgICBhc20g
dm9sYXRpbGUgKAotICAgICAgICAiICAgIGxvY2s7IGRlY2wgJTAgICAgICAg
ICBcbiIKLSAgICAgICAgIiAgICBqbnMgMmYgICAgICAgICAgICAgICAgXG4i
Ci0jaWZkZWYgX19jbGFuZ19fIC8qIGNsYW5nJ3MgYnVpbHRpbiBhc3NlbWJl
ciBjYW4ndCBkbyAuc3Vic2VjdGlvbiAqLwotICAgICAgICAiMTogIC5wdXNo
c2VjdGlvbiAuZml4dXAsXCJheFwiXG4iCi0jZWxzZQotICAgICAgICAiMTog
IC5zdWJzZWN0aW9uIDEgICAgICAgICBcbiIKLSNlbmRpZgotICAgICAgICAi
MjogIGxvY2s7IGluY2wgJTAgICAgICAgICBcbiIKLSAgICAgICAgIiAgICBk
ZWNsICUxICAgICAgICAgICAgICAgXG4iCi0gICAgICAgICIgICAgam1wIDFi
ICAgICAgICAgICAgICAgIFxuIgotI2lmZGVmIF9fY2xhbmdfXwotICAgICAg
ICAiICAgIC5wb3BzZWN0aW9uICAgICAgICAgICBcbiIKLSNlbHNlCi0gICAg
ICAgICIgICAgLnN1YnNlY3Rpb24gMCAgICAgICAgIFxuIgotI2VuZGlmCi0g
ICAgICAgIDogIj1tIiAocnctPmxvY2spLCAiPXIiIChhY3F1aXJlZCkgOiAi
MSIgKDEpIDogIm1lbW9yeSIgKTsKLQotICAgIHJldHVybiBhY3F1aXJlZDsK
LX0KLQotc3RhdGljIGFsd2F5c19pbmxpbmUgaW50IF9yYXdfd3JpdGVfdHJ5
bG9jayhyYXdfcndsb2NrX3QgKnJ3KQotewotICAgIHJldHVybiAoY21weGNo
ZygmcnctPmxvY2ssIDAsIFJXX1dSSVRFX0JJQVMpID09IDApOwotfQotCi1z
dGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIF9yYXdfcmVhZF91bmxvY2socmF3
X3J3bG9ja190ICpydykKLXsKLSAgICBhc20gdm9sYXRpbGUgKAotICAgICAg
ICAibG9jayA7IGluY2wgJTAiCi0gICAgICAgIDogIj1tIiAoKHJ3KS0+bG9j
aykgOiA6ICJtZW1vcnkiICk7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5l
IHZvaWQgX3Jhd193cml0ZV91bmxvY2socmF3X3J3bG9ja190ICpydykKLXsK
LSAgICBhc20gdm9sYXRpbGUgKAotICAgICAgICAibG9jayA7IHN1YmwgJTEs
JTAiCi0gICAgICAgIDogIj1tIiAoKHJ3KS0+bG9jaykgOiAiaSIgKFJXX1dS
SVRFX0JJQVMpIDogIm1lbW9yeSIgKTsKLX0KLQotI2RlZmluZSBfcmF3X3J3
X2lzX2xvY2tlZCh4KSAoKHgpLT5sb2NrICE9IDApCi0jZGVmaW5lIF9yYXdf
cndfaXNfd3JpdGVfbG9ja2VkKHgpICgoeCktPmxvY2sgPiAwKQotCiAjZW5k
aWYgLyogX19BU01fU1BJTkxPQ0tfSCAqLwotLS0gYS94ZW4vaW5jbHVkZS94
ZW4vc3BpbmxvY2suaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vc3BpbmxvY2su
aApAQCAtMTQxLDExICsxNDEsMTMgQEAgdHlwZWRlZiBzdHJ1Y3Qgc3Bpbmxv
Y2sgewogI2RlZmluZSBzcGluX2xvY2tfaW5pdChsKSAoKihsKSA9IChzcGlu
bG9ja190KVNQSU5fTE9DS19VTkxPQ0tFRCkKIAogdHlwZWRlZiBzdHJ1Y3Qg
ewotICAgIHJhd19yd2xvY2tfdCByYXc7CisgICAgdm9sYXRpbGUgdWludDMy
X3QgbG9jazsKICAgICBzdHJ1Y3QgbG9ja19kZWJ1ZyBkZWJ1ZzsKIH0gcnds
b2NrX3Q7CiAKLSNkZWZpbmUgUldfTE9DS19VTkxPQ0tFRCB7IF9SQVdfUldf
TE9DS19VTkxPQ0tFRCwgX0xPQ0tfREVCVUcgfQorI2RlZmluZSBSV19XUklU
RV9GTEFHICgxdTw8MzEpCisKKyNkZWZpbmUgUldfTE9DS19VTkxPQ0tFRCB7
IDAsIF9MT0NLX0RFQlVHIH0KICNkZWZpbmUgREVGSU5FX1JXTE9DSyhsKSBy
d2xvY2tfdCBsID0gUldfTE9DS19VTkxPQ0tFRAogI2RlZmluZSByd2xvY2tf
aW5pdChsKSAoKihsKSA9IChyd2xvY2tfdClSV19MT0NLX1VOTE9DS0VEKQog
Cg==

--=separator
Content-Type: application/octet-stream; name="xsa114-4.4.patch"
Content-Disposition: attachment; filename="xsa114-4.4.patch"
Content-Transfer-Encoding: base64

c3dpdGNoIHRvIHdyaXRlLWJpYXNlZCByL3cgbG9ja3MKClRoaXMgaXMgdG8g
aW1wcm92ZSBmYWlybmVzczogQSBwZXJtYW5lbnQgZmxvdyBvZiByZWFkIGFj
cXVpcmVzIGNhbgpvdGhlcndpc2UgbG9jayBvdXQgZXZlbnR1YWwgd3JpdGVy
cyBpbmRlZmluaXRlbHkuCgpUaGlzIGlzIFhTQS0xMTQgLyBDVkUtMjAxNC05
MDY1LgoKU2lnbmVkLW9mZi1ieTogS2VpciBGcmFzZXIgPGtlaXJAeGVuLm9y
Zz4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4KUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIz
QGNpdHJpeC5jb20+ClRlc3RlZC1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT4KCi0tLSBhL3hlbi9jb21tb24vc3Bpbmxv
Y2suYworKysgYi94ZW4vY29tbW9uL3NwaW5sb2NrLmMKQEAgLTI3MSwxMTIg
KzI3MSwxNTEgQEAgdm9pZCBfc3Bpbl91bmxvY2tfcmVjdXJzaXZlKHNwaW5s
b2NrX3QgKgogCiB2b2lkIF9yZWFkX2xvY2socndsb2NrX3QgKmxvY2spCiB7
CisgICAgdWludDMyX3QgeDsKKwogICAgIGNoZWNrX2xvY2soJmxvY2stPmRl
YnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3JlYWRfdHJ5bG9j
aygmbG9jay0+cmF3KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtl
bHkoX3Jhd19yd19pc193cml0ZV9sb2NrZWQoJmxvY2stPnJhdykpICkKKyAg
ICBkbyB7CisgICAgICAgIHdoaWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJX
X1dSSVRFX0ZMQUcgKQogICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0gICAg
fQorICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEp
ICE9IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBf
cmVhZF9sb2NrX2lycShyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgQVNTRVJUKGxvY2FsX2lycV9pc19lbmFibGVkKCkpOwog
ICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CiAgICAgY2hlY2tfbG9jaygmbG9j
ay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtlbHkoIV9yYXdfcmVhZF90
cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewotICAgICAgICBsb2NhbF9p
cnFfZW5hYmxlKCk7Ci0gICAgICAgIHdoaWxlICggbGlrZWx5KF9yYXdfcndf
aXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5yYXcpKSApCi0gICAgICAgICAgICBj
cHVfcmVsYXgoKTsKLSAgICAgICAgbG9jYWxfaXJxX2Rpc2FibGUoKTsKLSAg
ICB9CisgICAgZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykg
JiBSV19XUklURV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxv
Y2stPmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAg
Y3B1X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfZGlzYWJsZSgp
OworICAgICAgICB9CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2stPmxv
Y2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgpOwog
fQogCiB1bnNpZ25lZCBsb25nIF9yZWFkX2xvY2tfaXJxc2F2ZShyd2xvY2tf
dCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4OwogICAgIHVuc2lnbmVkIGxv
bmcgZmxhZ3M7CisKICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7CiAgICAg
Y2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdoaWxlICggdW5saWtl
bHkoIV9yYXdfcmVhZF90cnlsb2NrKCZsb2NrLT5yYXcpKSApCi0gICAgewot
ICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7Ci0gICAgICAgIHdo
aWxlICggbGlrZWx5KF9yYXdfcndfaXNfd3JpdGVfbG9ja2VkKCZsb2NrLT5y
YXcpKSApCi0gICAgICAgICAgICBjcHVfcmVsYXgoKTsKLSAgICAgICAgbG9j
YWxfaXJxX3NhdmUoZmxhZ3MpOwotICAgIH0KKyAgICBkbyB7CisgICAgICAg
IGlmICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAg
ICAgICB7CisgICAgICAgICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CisgICAgICAgICAgICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19X
UklURV9GTEFHICkKKyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAg
ICAgICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgfQor
ICAgIH0gd2hpbGUgKCBjbXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4KzEpICE9
IHggKTsKICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gZmxh
Z3M7CiB9CiAKIGludCBfcmVhZF90cnlsb2NrKHJ3bG9ja190ICpsb2NrKQog
eworICAgIHVpbnQzMl90IHg7CisKICAgICBjaGVja19sb2NrKCZsb2NrLT5k
ZWJ1Zyk7Ci0gICAgaWYgKCAhX3Jhd19yZWFkX3RyeWxvY2soJmxvY2stPnJh
dykgKQotICAgICAgICByZXR1cm4gMDsKKyAgICBkbyB7CisgICAgICAgIGlm
ICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAg
ICAgICAgcmV0dXJuIDA7CisgICAgfSB3aGlsZSAoIGNtcHhjaGcoJmxvY2st
PmxvY2ssIHgsIHgrMSkgIT0geCApOwogICAgIHByZWVtcHRfZGlzYWJsZSgp
OwogICAgIHJldHVybiAxOwogfQogCiB2b2lkIF9yZWFkX3VubG9jayhyd2xv
Y2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJfdCB4LCB5OworCiAgICAgcHJl
ZW1wdF9lbmFibGUoKTsKLSAgICBfcmF3X3JlYWRfdW5sb2NrKCZsb2NrLT5y
YXcpOworICAgIHggPSBsb2NrLT5sb2NrOworICAgIHdoaWxlICggKHkgPSBj
bXB4Y2hnKCZsb2NrLT5sb2NrLCB4LCB4LTEpKSAhPSB4ICkKKyAgICAgICAg
eCA9IHk7CiB9CiAKIHZvaWQgX3JlYWRfdW5sb2NrX2lycShyd2xvY2tfdCAq
bG9jaykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfcmVh
ZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxvY2sp
OwogICAgIGxvY2FsX2lycV9lbmFibGUoKTsKIH0KIAogdm9pZCBfcmVhZF91
bmxvY2tfaXJxcmVzdG9yZShyd2xvY2tfdCAqbG9jaywgdW5zaWduZWQgbG9u
ZyBmbGFncykKIHsKLSAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdf
cmVhZF91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3JlYWRfdW5sb2NrKGxv
Y2spOwogICAgIGxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKIH0KIAogdm9p
ZCBfd3JpdGVfbG9jayhyd2xvY2tfdCAqbG9jaykKIHsKKyAgICB1aW50MzJf
dCB4OworCiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHdo
aWxlICggdW5saWtlbHkoIV9yYXdfd3JpdGVfdHJ5bG9jaygmbG9jay0+cmF3
KSkgKQotICAgIHsKLSAgICAgICAgd2hpbGUgKCBsaWtlbHkoX3Jhd19yd19p
c19sb2NrZWQoJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIHdo
aWxlICggKHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQogICAg
ICAgICAgICAgY3B1X3JlbGF4KCk7CisgICAgfSB3aGlsZSAoIGNtcHhjaGco
JmxvY2stPmxvY2ssIHgsIHh8UldfV1JJVEVfRkxBRykgIT0geCApOworICAg
IHdoaWxlICggeCAhPSAwICkKKyAgICB7CisgICAgICAgIGNwdV9yZWxheCgp
OworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5SV19XUklURV9GTEFHOwog
ICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKIH0KIAogdm9pZCBfd3Jp
dGVfbG9ja19pcnEocndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3Qg
eDsKKwogICAgIEFTU0VSVChsb2NhbF9pcnFfaXNfZW5hYmxlZCgpKTsKICAg
ICBsb2NhbF9pcnFfZGlzYWJsZSgpOwogICAgIGNoZWNrX2xvY2soJmxvY2st
PmRlYnVnKTsKLSAgICB3aGlsZSAoIHVubGlrZWx5KCFfcmF3X3dyaXRlX3Ry
eWxvY2soJmxvY2stPnJhdykpICkKKyAgICBkbyB7CisgICAgICAgIGlmICgg
KHggPSBsb2NrLT5sb2NrKSAmIFJXX1dSSVRFX0ZMQUcgKQorICAgICAgICB7
CisgICAgICAgICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CisgICAgICAgICAg
ICB3aGlsZSAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklURV9GTEFHICkK
KyAgICAgICAgICAgICAgICBjcHVfcmVsYXgoKTsKKyAgICAgICAgICAgIGxv
Y2FsX2lycV9kaXNhYmxlKCk7CisgICAgICAgIH0KKyAgICB9IHdoaWxlICgg
Y21weGNoZygmbG9jay0+bG9jaywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4
ICk7CisgICAgd2hpbGUgKCB4ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9j
YWxfaXJxX2VuYWJsZSgpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3
X3J3X2lzX2xvY2tlZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1
X3JlbGF4KCk7Ci0gICAgICAgIGxvY2FsX2lycV9kaXNhYmxlKCk7CisgICAg
ICAgIGNwdV9yZWxheCgpOworICAgICAgICB4ID0gbG9jay0+bG9jayAmIH5S
V19XUklURV9GTEFHOwogICAgIH0KICAgICBwcmVlbXB0X2Rpc2FibGUoKTsK
IH0KIAogdW5zaWduZWQgbG9uZyBfd3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9j
a190ICpsb2NrKQogeworICAgIHVpbnQzMl90IHg7CiAgICAgdW5zaWduZWQg
bG9uZyBmbGFnczsKKwogICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKICAg
ICBjaGVja19sb2NrKCZsb2NrLT5kZWJ1Zyk7Ci0gICAgd2hpbGUgKCB1bmxp
a2VseSghX3Jhd193cml0ZV90cnlsb2NrKCZsb2NrLT5yYXcpKSApCisgICAg
ZG8geworICAgICAgICBpZiAoICh4ID0gbG9jay0+bG9jaykgJiBSV19XUklU
RV9GTEFHICkKKyAgICAgICAgeworICAgICAgICAgICAgbG9jYWxfaXJxX3Jl
c3RvcmUoZmxhZ3MpOworICAgICAgICAgICAgd2hpbGUgKCAoeCA9IGxvY2st
PmxvY2spICYgUldfV1JJVEVfRkxBRyApCisgICAgICAgICAgICAgICAgY3B1
X3JlbGF4KCk7CisgICAgICAgICAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7
CisgICAgICAgIH0KKyAgICB9IHdoaWxlICggY21weGNoZygmbG9jay0+bG9j
aywgeCwgeHxSV19XUklURV9GTEFHKSAhPSB4ICk7CisgICAgd2hpbGUgKCB4
ICE9IDAgKQogICAgIHsKLSAgICAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh
Z3MpOwotICAgICAgICB3aGlsZSAoIGxpa2VseShfcmF3X3J3X2lzX2xvY2tl
ZCgmbG9jay0+cmF3KSkgKQotICAgICAgICAgICAgY3B1X3JlbGF4KCk7Ci0g
ICAgICAgIGxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKyAgICAgICAgY3B1X3Jl
bGF4KCk7CisgICAgICAgIHggPSBsb2NrLT5sb2NrICYgflJXX1dSSVRFX0ZM
QUc7CiAgICAgfQogICAgIHByZWVtcHRfZGlzYWJsZSgpOwogICAgIHJldHVy
biBmbGFnczsKQEAgLTM4NCw5ICs0MjMsMTMgQEAgdW5zaWduZWQgbG9uZyBf
d3JpdGVfbG9ja19pcnFzYXZlKHJ3bG9jawogCiBpbnQgX3dyaXRlX3RyeWxv
Y2socndsb2NrX3QgKmxvY2spCiB7CisgICAgdWludDMyX3QgeDsKKwogICAg
IGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICBpZiAoICFfcmF3X3dy
aXRlX3RyeWxvY2soJmxvY2stPnJhdykgKQotICAgICAgICByZXR1cm4gMDsK
KyAgICBkbyB7CisgICAgICAgIGlmICggKHggPSBsb2NrLT5sb2NrKSAhPSAw
ICkKKyAgICAgICAgICAgIHJldHVybiAwOworICAgIH0gd2hpbGUgKCBjbXB4
Y2hnKCZsb2NrLT5sb2NrLCB4LCB4fFJXX1dSSVRFX0ZMQUcpICE9IHggKTsK
ICAgICBwcmVlbXB0X2Rpc2FibGUoKTsKICAgICByZXR1cm4gMTsKIH0KQEAg
LTM5NCwzMyArNDM3LDMyIEBAIGludCBfd3JpdGVfdHJ5bG9jayhyd2xvY2tf
dCAqbG9jaykKIHZvaWQgX3dyaXRlX3VubG9jayhyd2xvY2tfdCAqbG9jaykK
IHsKICAgICBwcmVlbXB0X2VuYWJsZSgpOwotICAgIF9yYXdfd3JpdGVfdW5s
b2NrKCZsb2NrLT5yYXcpOworICAgIGlmICggY21weGNoZygmbG9jay0+bG9j
aywgUldfV1JJVEVfRkxBRywgMCkgIT0gUldfV1JJVEVfRkxBRyApCisgICAg
ICAgIEJVRygpOwogfQogCiB2b2lkIF93cml0ZV91bmxvY2tfaXJxKHJ3bG9j
a190ICpsb2NrKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0gICAgX3Jh
d193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRlX3VubG9j
ayhsb2NrKTsKICAgICBsb2NhbF9pcnFfZW5hYmxlKCk7CiB9CiAKIHZvaWQg
X3dyaXRlX3VubG9ja19pcnFyZXN0b3JlKHJ3bG9ja190ICpsb2NrLCB1bnNp
Z25lZCBsb25nIGZsYWdzKQogewotICAgIHByZWVtcHRfZW5hYmxlKCk7Ci0g
ICAgX3Jhd193cml0ZV91bmxvY2soJmxvY2stPnJhdyk7CisgICAgX3dyaXRl
X3VubG9jayhsb2NrKTsKICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7
CiB9CiAKIGludCBfcndfaXNfbG9ja2VkKHJ3bG9ja190ICpsb2NrKQogewog
ICAgIGNoZWNrX2xvY2soJmxvY2stPmRlYnVnKTsKLSAgICByZXR1cm4gX3Jh
d19yd19pc19sb2NrZWQoJmxvY2stPnJhdyk7CisgICAgcmV0dXJuIChsb2Nr
LT5sb2NrICE9IDApOyAvKiBhbnlvbmUgaW4gY3JpdGljYWwgc2VjdGlvbj8g
Ki8KIH0KIAogaW50IF9yd19pc193cml0ZV9sb2NrZWQocndsb2NrX3QgKmxv
Y2spCiB7CiAgICAgY2hlY2tfbG9jaygmbG9jay0+ZGVidWcpOwotICAgIHJl
dHVybiBfcmF3X3J3X2lzX3dyaXRlX2xvY2tlZCgmbG9jay0+cmF3KTsKKyAg
ICByZXR1cm4gKGxvY2stPmxvY2sgPT0gUldfV1JJVEVfRkxBRyk7IC8qIHdy
aXRlciBpbiBjcml0aWNhbCBzZWN0aW9uPyAqLwogfQogCiAjaWZkZWYgTE9D
S19QUk9GSUxFCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vYXJtMzIvc3Bp
bmxvY2suaAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2FybTMyL3NwaW5s
b2NrLmgKQEAgLTU1LDg0ICs1NSw2IEBAIHN0YXRpYyBhbHdheXNfaW5saW5l
IGludCBfcmF3X3NwaW5fdHJ5bG8KICAgICB9CiB9CiAKLXR5cGVkZWYgc3Ry
dWN0IHsKLSAgICB2b2xhdGlsZSB1bnNpZ25lZCBpbnQgbG9jazsKLX0gcmF3
X3J3bG9ja190OwotCi0jZGVmaW5lIF9SQVdfUldfTE9DS19VTkxPQ0tFRCB7
IDAgfQotCi1zdGF0aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd19yZWFkX3Ry
eWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNpZ25lZCBsb25n
IHRtcCwgdG1wMiA9IDE7Ci0KLSAgICBfX2FzbV9fIF9fdm9sYXRpbGVfXygK
LSIxOiBsZHJleCAgICUwLCBbJTJdXG4iCi0iICAgYWRkcyAgICAlMCwgJTAs
ICMxXG4iCi0iICAgc3RyZXhwbCAlMSwgJTAsIFslMl1cbiIKLSAgICA6ICI9
JnIiICh0bXApLCAiK3IiICh0bXAyKQotICAgIDogInIiICgmcnctPmxvY2sp
Ci0gICAgOiAiY2MiKTsKLQotICAgIHNtcF9tYigpOwotICAgIHJldHVybiB0
bXAyID09IDA7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3
X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAgICB1bnNp
Z25lZCBsb25nIHRtcDsKLQotICAgIF9fYXNtX18gX192b2xhdGlsZV9fKAot
IjE6IGxkcmV4ICAgJTAsIFslMV1cbiIKLSIgICB0ZXEgICAgICUwLCAjMFxu
IgotIiAgIHN0cmV4ZXEgJTAsICUyLCBbJTFdIgotICAgIDogIj0mciIgKHRt
cCkKLSAgICA6ICJyIiAoJnJ3LT5sb2NrKSwgInIiICgweDgwMDAwMDAwKQot
ICAgIDogImNjIik7Ci0KLSAgICBpZiAodG1wID09IDApIHsKLSAgICAgICAg
c21wX21iKCk7Ci0gICAgICAgIHJldHVybiAxOwotICAgIH0gZWxzZSB7Ci0g
ICAgICAgIHJldHVybiAwOwotICAgIH0KLX0KLQotc3RhdGljIGlubGluZSB2
b2lkIF9yYXdfcmVhZF91bmxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAg
ICB1bnNpZ25lZCBsb25nIHRtcCwgdG1wMjsKLQotICAgIHNtcF9tYigpOwot
Ci0gICAgX19hc21fXyBfX3ZvbGF0aWxlX18oCi0iMTogbGRyZXggICAlMCwg
WyUyXVxuIgotIiAgIHN1YiAgICAgJTAsICUwLCAjMVxuIgotIiAgIHN0cmV4
ICAgJTEsICUwLCBbJTJdXG4iCi0iICAgdGVxICAgICAlMSwgIzBcbiIKLSIg
ICBibmUgICAgIDFiIgotICAgIDogIj0mciIgKHRtcCksICI9JnIiICh0bXAy
KQotICAgIDogInIiICgmcnctPmxvY2spCi0gICAgOiAiY2MiKTsKLQotICAg
IGlmICh0bXAgPT0gMCkKLSAgICAgICAgZHNiX3NldigpOwotfQotCi1zdGF0
aWMgaW5saW5lIHZvaWQgX3Jhd193cml0ZV91bmxvY2socmF3X3J3bG9ja190
ICpydykKLXsKLSAgICBzbXBfbWIoKTsKLQotICAgIF9fYXNtX18gX192b2xh
dGlsZV9fKAotICAgICJzdHIgICAgJTEsIFslMF1cbiIKLSAgICA6Ci0gICAg
OiAiciIgKCZydy0+bG9jayksICJyIiAoMCkKLSAgICA6ICJjYyIpOwotCi0g
ICAgZHNiX3NldigpOwotfQotCi0jZGVmaW5lIF9yYXdfcndfaXNfbG9ja2Vk
KHgpICgoeCktPmxvY2sgIT0gMCkKLSNkZWZpbmUgX3Jhd19yd19pc193cml0
ZV9sb2NrZWQoeCkgKCh4KS0+bG9jayA9PSAweDgwMDAwMDAwKQotCiAjZW5k
aWYgLyogX19BU01fU1BJTkxPQ0tfSCAqLwogLyoKICAqIExvY2FsIHZhcmlh
YmxlczoKLS0tIGEveGVuL2luY2x1ZGUvYXNtLWFybS9hcm02NC9zcGlubG9j
ay5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vYXJtNjQvc3BpbmxvY2su
aApAQCAtNTIsNjkgKzUyLDYgQEAgc3RhdGljIGFsd2F5c19pbmxpbmUgaW50
IF9yYXdfc3Bpbl90cnlsbwogICAgIHJldHVybiAhdG1wOwogfQogCi10eXBl
ZGVmIHN0cnVjdCB7Ci0gICAgdm9sYXRpbGUgdW5zaWduZWQgaW50IGxvY2s7
Ci19IHJhd19yd2xvY2tfdDsKLQotI2RlZmluZSBfUkFXX1JXX0xPQ0tfVU5M
T0NLRUQgeyAwIH0KLQotc3RhdGljIGFsd2F5c19pbmxpbmUgaW50IF9yYXdf
cmVhZF90cnlsb2NrKHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgdW5zaWdu
ZWQgaW50IHRtcCwgdG1wMiA9IDE7Ci0KLSAgICBhc20gdm9sYXRpbGUoCi0g
ICAgICAgICIgICAgICAgbGRheHIgICAldzAsICUyXG4iCi0gICAgICAgICIg
ICAgICAgYWRkICAgICAldzAsICV3MCwgIzFcbiIKLSAgICAgICAgIiAgICAg
ICB0Ym56ICAgICV3MCwgIzMxLCAxZlxuIgotICAgICAgICAiICAgICAgIHN0
eHIgICAgJXcxLCAldzAsICUyXG4iCi0gICAgICAgICIxOlxuIgotICAgICAg
ICA6ICI9JnIiICh0bXApLCAiK3IiICh0bXAyKSwgIitRIiAocnctPmxvY2sp
Ci0gICAgICAgIDoKLSAgICAgICAgOiAiY2MiLCAibWVtb3J5Iik7Ci0KLSAg
ICByZXR1cm4gIXRtcDI7Ci19Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIGlu
dCBfcmF3X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpydykKLXsKLSAg
ICB1bnNpZ25lZCBpbnQgdG1wOwotCi0gICAgYXNtIHZvbGF0aWxlKAotICAg
ICAgICAiICAgICAgIGxkYXhyICAgJXcwLCAlMVxuIgotICAgICAgICAiICAg
ICAgIGNibnogICAgJXcwLCAxZlxuIgotICAgICAgICAiICAgICAgIHN0eHIg
ICAgJXcwLCAldzIsICUxXG4iCi0gICAgICAgICIxOlxuIgotICAgICAgICA6
ICI9JnIiICh0bXApLCAiK1EiIChydy0+bG9jaykKLSAgICAgICAgOiAiciIg
KDB4ODAwMDAwMDApCi0gICAgICAgIDogImNjIiwgIm1lbW9yeSIpOwotCi0g
ICAgcmV0dXJuICF0bXA7Ci19Ci0KLXN0YXRpYyBpbmxpbmUgdm9pZCBfcmF3
X3JlYWRfdW5sb2NrKHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgdW5zaWdu
ZWQgaW50IHRtcCwgdG1wMjsKLQotICAgIGFzbSB2b2xhdGlsZSgKLSAgICAg
ICAgIiAgICAxOiBsZHhyICAgICV3MCwgJTJcbiIKLSAgICAgICAgIiAgICAg
ICBzdWIgICAgICV3MCwgJXcwLCAjMVxuIgotICAgICAgICAiICAgICAgIHN0
bHhyICAgJXcxLCAldzAsICUyXG4iCi0gICAgICAgICIgICAgICAgY2JueiAg
ICAldzEsIDFiXG4iCi0gICAgICAgIDogIj0mciIgKHRtcCksICI9JnIiICh0
bXAyKSwgIitRIiAocnctPmxvY2spCi0gICAgICAgIDoKLSAgICAgICAgOiAi
Y2MiLCAibWVtb3J5Iik7Ci19Ci0KLXN0YXRpYyBpbmxpbmUgdm9pZCBfcmF3
X3dyaXRlX3VubG9jayhyYXdfcndsb2NrX3QgKnJ3KQotewotICAgIGFzbSB2
b2xhdGlsZSgKLSAgICAgICAgIiAgICAgICBzdGxyICAgICV3MSwgJTBcbiIK
LSAgICAgICAgOiAiPVEiIChydy0+bG9jaykgOiAiciIgKDApIDogIm1lbW9y
eSIpOwotfQotCi0jZGVmaW5lIF9yYXdfcndfaXNfbG9ja2VkKHgpICgoeCkt
PmxvY2sgIT0gMCkKLSNkZWZpbmUgX3Jhd19yd19pc193cml0ZV9sb2NrZWQo
eCkgKCh4KS0+bG9jayA9PSAweDgwMDAwMDAwKQotCiAjZW5kaWYgLyogX19B
U01fU1BJTkxPQ0tfSCAqLwogLyoKICAqIExvY2FsIHZhcmlhYmxlczoKLS0t
IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGlubG9jay5oCisrKyBiL3hlbi9p
bmNsdWRlL2FzbS14ODYvc3BpbmxvY2suaApAQCAtMzEsNTggKzMxLDQgQEAg
c3RhdGljIGFsd2F5c19pbmxpbmUgaW50IF9yYXdfc3Bpbl90cnlsbwogICAg
IHJldHVybiAob2xkdmFsID4gMCk7CiB9CiAKLXR5cGVkZWYgc3RydWN0IHsK
LSAgICB2b2xhdGlsZSBpbnQgbG9jazsKLX0gcmF3X3J3bG9ja190OwotCi0j
ZGVmaW5lIFJXX1dSSVRFX0JJQVMgMHg3ZmZmZmZmZgotI2RlZmluZSBfUkFX
X1JXX0xPQ0tfVU5MT0NLRUQgLyoocmF3X3J3bG9ja190KSovIHsgMCB9Ci0K
LXN0YXRpYyBhbHdheXNfaW5saW5lIGludCBfcmF3X3JlYWRfdHJ5bG9jayhy
YXdfcndsb2NrX3QgKnJ3KQotewotICAgIGludCBhY3F1aXJlZDsKLQotICAg
IGFzbSB2b2xhdGlsZSAoCi0gICAgICAgICIgICAgbG9jazsgZGVjbCAlMCAg
ICAgICAgIFxuIgotICAgICAgICAiICAgIGpucyAyZiAgICAgICAgICAgICAg
ICBcbiIKLSNpZmRlZiBfX2NsYW5nX18gLyogY2xhbmcncyBidWlsdGluIGFz
c2VtYmVyIGNhbid0IGRvIC5zdWJzZWN0aW9uICovCi0gICAgICAgICIxOiAg
LnB1c2hzZWN0aW9uIC5maXh1cCxcImF4XCJcbiIKLSNlbHNlCi0gICAgICAg
ICIxOiAgLnN1YnNlY3Rpb24gMSAgICAgICAgIFxuIgotI2VuZGlmCi0gICAg
ICAgICIyOiAgbG9jazsgaW5jbCAlMCAgICAgICAgIFxuIgotICAgICAgICAi
ICAgIGRlY2wgJTEgICAgICAgICAgICAgICBcbiIKLSAgICAgICAgIiAgICBq
bXAgMWIgICAgICAgICAgICAgICAgXG4iCi0jaWZkZWYgX19jbGFuZ19fCi0g
ICAgICAgICIgICAgLnBvcHNlY3Rpb24gICAgICAgICAgIFxuIgotI2Vsc2UK
LSAgICAgICAgIiAgICAuc3Vic2VjdGlvbiAwICAgICAgICAgXG4iCi0jZW5k
aWYKLSAgICAgICAgOiAiPW0iIChydy0+bG9jayksICI9ciIgKGFjcXVpcmVk
KSA6ICIxIiAoMSkgOiAibWVtb3J5IiApOwotCi0gICAgcmV0dXJuIGFjcXVp
cmVkOwotfQotCi1zdGF0aWMgYWx3YXlzX2lubGluZSBpbnQgX3Jhd193cml0
ZV90cnlsb2NrKHJhd19yd2xvY2tfdCAqcncpCi17Ci0gICAgcmV0dXJuIChj
bXB4Y2hnKCZydy0+bG9jaywgMCwgUldfV1JJVEVfQklBUykgPT0gMCk7Ci19
Ci0KLXN0YXRpYyBhbHdheXNfaW5saW5lIHZvaWQgX3Jhd19yZWFkX3VubG9j
ayhyYXdfcndsb2NrX3QgKnJ3KQotewotICAgIGFzbSB2b2xhdGlsZSAoCi0g
ICAgICAgICJsb2NrIDsgaW5jbCAlMCIKLSAgICAgICAgOiAiPW0iICgocncp
LT5sb2NrKSA6IDogIm1lbW9yeSIgKTsKLX0KLQotc3RhdGljIGFsd2F5c19p
bmxpbmUgdm9pZCBfcmF3X3dyaXRlX3VubG9jayhyYXdfcndsb2NrX3QgKnJ3
KQotewotICAgIGFzbSB2b2xhdGlsZSAoCi0gICAgICAgICJsb2NrIDsgc3Vi
bCAlMSwlMCIKLSAgICAgICAgOiAiPW0iICgocncpLT5sb2NrKSA6ICJpIiAo
UldfV1JJVEVfQklBUykgOiAibWVtb3J5IiApOwotfQotCi0jZGVmaW5lIF9y
YXdfcndfaXNfbG9ja2VkKHgpICgoeCktPmxvY2sgIT0gMCkKLSNkZWZpbmUg
X3Jhd19yd19pc193cml0ZV9sb2NrZWQoeCkgKCh4KS0+bG9jayA+IDApCi0K
ICNlbmRpZiAvKiBfX0FTTV9TUElOTE9DS19IICovCi0tLSBhL3hlbi9pbmNs
dWRlL3hlbi9zcGlubG9jay5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi9zcGlu
bG9jay5oCkBAIC0xNDEsMTEgKzE0MSwxMyBAQCB0eXBlZGVmIHN0cnVjdCBz
cGlubG9jayB7CiAjZGVmaW5lIHNwaW5fbG9ja19pbml0KGwpICgqKGwpID0g
KHNwaW5sb2NrX3QpU1BJTl9MT0NLX1VOTE9DS0VEKQogCiB0eXBlZGVmIHN0
cnVjdCB7Ci0gICAgcmF3X3J3bG9ja190IHJhdzsKKyAgICB2b2xhdGlsZSB1
aW50MzJfdCBsb2NrOwogICAgIHN0cnVjdCBsb2NrX2RlYnVnIGRlYnVnOwog
fSByd2xvY2tfdDsKIAotI2RlZmluZSBSV19MT0NLX1VOTE9DS0VEIHsgX1JB
V19SV19MT0NLX1VOTE9DS0VELCBfTE9DS19ERUJVRyB9CisjZGVmaW5lIFJX
X1dSSVRFX0ZMQUcgKDF1PDwzMSkKKworI2RlZmluZSBSV19MT0NLX1VOTE9D
S0VEIHsgMCwgX0xPQ0tfREVCVUcgfQogI2RlZmluZSBERUZJTkVfUldMT0NL
KGwpIHJ3bG9ja190IGwgPSBSV19MT0NLX1VOTE9DS0VECiAjZGVmaW5lIHJ3
bG9ja19pbml0KGwpICgqKGwpID0gKHJ3bG9ja190KVJXX0xPQ0tfVU5MT0NL
RUQpCiAK

--=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 Mon Dec 08 12:31:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxxSf-0006JP-1H; Mon, 08 Dec 2014 12:30:45 +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 1XxxSc-0006JH-Qq
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 12:30:43 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	2E/8F-14727-2F995845; Mon, 08 Dec 2014 12:30:42 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418041841!8768832!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 499 invoked from network); 8 Dec 2014 12:30:41 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-15.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Dec 2014 12:30:41 -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 1XxxSZ-0003ae-PR; Mon, 08 Dec 2014 12:30:39 +0000
Message-ID: <548599EE.4000204@canonical.com>
Date: Mon, 08 Dec 2014 13:30:38 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>	<547C2CFC.7060908@canonical.com>	<20141208101936.GA7491@hercules>	<54858753.1070801@citrix.com>
	<548589B0.8050608@canonical.com> <54858BFC.2020906@citrix.com>
In-Reply-To: <54858BFC.2020906@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8681200982878047249=="
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)
--===============8681200982878047249==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="f7iA47JQTeHghJ9oOxmoFewQk37w8ALJa"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--f7iA47JQTeHghJ9oOxmoFewQk37w8ALJa
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 08.12.2014 12:31, David Vrabel wrote:
> On 08/12/14 11:21, Stefan Bader wrote:
>> On 08.12.2014 12:11, David Vrabel wrote:
>>> On 08/12/14 10:19, Luis Henriques wrote:
>>>> On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
>>>>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>>>>> There is a long known problem with the netfront/netback interface:=
 if the guest
>>>>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + =
1 ring slots,
>>>>>> it gets dropped. The reason is that netback maps these slots to a =
frag in the
>>>>>> frags array, which is limited by size. Having so many slots can oc=
cur since
>>>>>> compound pages were introduced, as the ring protocol slice them up=
 into
>>>>>> individual (non-compound) page aligned slots. The theoretical wors=
t case
>>>>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>>>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page =
boundary,
>>>>>> using 2 slots
>>>>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes=
 are at the
>>>>>> end and the beginning of a page, therefore they use 3 * 15 =3D 45 =
slots
>>>>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 =
slots
>>>>>> Although I don't think this 51 slots skb can really happen, we nee=
d a solution
>>>>>> which can deal with every scenario. In real life there is only a f=
ew slots
>>>>>> overdue, but usually it causes the TCP stream to be blocked, as th=
e retry will
>>>>>> most likely have the same buffer layout.
>>>>>> This patch solves this problem by linearizing the packet. This is =
not the
>>>>>> fastest way, and it can fail much easier as it tries to allocate a=
 big linear
>>>>>> area for the whole packet, but probably easier by an order of magn=
itude than
>>>>>> anything else. Probably this code path is not touched very frequen=
tly anyway.
>>>>>>
>>>>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>>>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>>>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>>>>> Cc: netdev@vger.kernel.org
>>>>>> Cc: linux-kernel@vger.kernel.org
>>>>>> Cc: xen-devel@lists.xenproject.org
>>>>>
>>>>> This does not seem to be marked explicitly as stable. Has someone a=
lready asked
>>>>> David Miller to put it on his stable queue? IMO it qualifies quite =
well and the
>>>>> actual change should be simple to pick/backport.
>>>>>
>>>>
>>>> Thank you Stefan, I'm queuing this for the next 3.16 kernel release.=

>>>
>>> Don't backport this yes.  It's broken.  It produces malformed request=
s
>>> and netback will report a fatal error and stop all traffic on the VIF=
=2E
>>
>> Thanks David. Did this just come up? I don't remember seeing any repor=
t of the
>> regression. :/
>=20
> There's been a couple of reports on xen-devel recently with 3.17
> frontends and I've just repro'd it (by always forcing a skb_linearize()=

> in netfront).

Ah ok. Found at least one now (plus your fixup proposal). Too long ago to=

remember for sure but I thought the change was tested by reporters. Could=
 be
that I only had tried the approach I was working on back then (which was =
more
complicated trying to replace individual frags by aligned copies). :( And=
 on our
devel we have not yet switched to past 3.16. Hope I can squeeze in some t=
esting
there.

-Stefan
>=20
> David
>=20



--f7iA47JQTeHghJ9oOxmoFewQk37w8ALJa
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

iQIcBAEBCgAGBQJUhZnuAAoJEOhnXe7L7s6jJScQAIBUR+QoWXOaZFdhS3HarkGU
SD5UlLLRLHJLQmbpVxfN7pggd8VFW5bLA0f5r8kffSOmuMf7Zm86Y4KGaO5k+qG7
cPvYkv8rrJUY1kRGsVv/9y3IsA3ppR/mKT9E/5ow+o2AGdmBONKTjMuSJwXjId6A
wfq5M0RNSRlAnWrAbdYbBQZo50gMW+UgW7d5JfvigRfNMVGT6BJrD6MteWW9p4+P
NlMpangg1O1wUbo1UZwItszdxovBWz2qkm0qsUgNI9bvBMIlGd4voO1da3mraeN8
LWnpAQVyU8wTVgG6TNX3S+cnq4Bd8J3MR9TIyqMrqBPMw+YqI4NgXGJSa6NwyOc4
mpEZoFC/uaE8Nf28gj+FqtDejWt5ZUmnQLBQdUN32e+U80VZBwJ7DlzRbh0+WO16
BlI2lqAorCxpz9Z1eKSQwx7w2Bm7Kylxnrg0hCA/smIOBZdZolOaH7op6qDyTsKE
IqbjUxeR4a0KtNxz0L4W6+2TpHZEwlN3uiFffF6ORjBevB6mkRufLMF3slJ3z7ju
QHWMFHNWxXOse8IFgBqFG/fNkC0664GACejuIU3bm4nsFls7Wv9QvpzSWzTvKbtO
tgjm/gsmzXVOOrMQjKwbIVYreBvTrQjnPpndtFo+YF28YsguMdUGuJdtN+WBPDoX
hyPtAR/GBSecbCEZFfQl
=e9Bj
-----END PGP SIGNATURE-----

--f7iA47JQTeHghJ9oOxmoFewQk37w8ALJa--


--===============8681200982878047249==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8681200982878047249==--


From xen-devel-bounces@lists.xen.org Mon Dec 08 12:31:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxxSf-0006JP-1H; Mon, 08 Dec 2014 12:30:45 +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 1XxxSc-0006JH-Qq
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 12:30:43 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	2E/8F-14727-2F995845; Mon, 08 Dec 2014 12:30:42 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418041841!8768832!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 499 invoked from network); 8 Dec 2014 12:30:41 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-15.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Dec 2014 12:30:41 -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 1XxxSZ-0003ae-PR; Mon, 08 Dec 2014 12:30:39 +0000
Message-ID: <548599EE.4000204@canonical.com>
Date: Mon, 08 Dec 2014 13:30:38 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>	<547C2CFC.7060908@canonical.com>	<20141208101936.GA7491@hercules>	<54858753.1070801@citrix.com>
	<548589B0.8050608@canonical.com> <54858BFC.2020906@citrix.com>
In-Reply-To: <54858BFC.2020906@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8681200982878047249=="
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)
--===============8681200982878047249==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="f7iA47JQTeHghJ9oOxmoFewQk37w8ALJa"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--f7iA47JQTeHghJ9oOxmoFewQk37w8ALJa
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 08.12.2014 12:31, David Vrabel wrote:
> On 08/12/14 11:21, Stefan Bader wrote:
>> On 08.12.2014 12:11, David Vrabel wrote:
>>> On 08/12/14 10:19, Luis Henriques wrote:
>>>> On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
>>>>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>>>>> There is a long known problem with the netfront/netback interface:=
 if the guest
>>>>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + =
1 ring slots,
>>>>>> it gets dropped. The reason is that netback maps these slots to a =
frag in the
>>>>>> frags array, which is limited by size. Having so many slots can oc=
cur since
>>>>>> compound pages were introduced, as the ring protocol slice them up=
 into
>>>>>> individual (non-compound) page aligned slots. The theoretical wors=
t case
>>>>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>>>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page =
boundary,
>>>>>> using 2 slots
>>>>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes=
 are at the
>>>>>> end and the beginning of a page, therefore they use 3 * 15 =3D 45 =
slots
>>>>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 =
slots
>>>>>> Although I don't think this 51 slots skb can really happen, we nee=
d a solution
>>>>>> which can deal with every scenario. In real life there is only a f=
ew slots
>>>>>> overdue, but usually it causes the TCP stream to be blocked, as th=
e retry will
>>>>>> most likely have the same buffer layout.
>>>>>> This patch solves this problem by linearizing the packet. This is =
not the
>>>>>> fastest way, and it can fail much easier as it tries to allocate a=
 big linear
>>>>>> area for the whole packet, but probably easier by an order of magn=
itude than
>>>>>> anything else. Probably this code path is not touched very frequen=
tly anyway.
>>>>>>
>>>>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>>>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>>>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>>>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>>>>> Cc: netdev@vger.kernel.org
>>>>>> Cc: linux-kernel@vger.kernel.org
>>>>>> Cc: xen-devel@lists.xenproject.org
>>>>>
>>>>> This does not seem to be marked explicitly as stable. Has someone a=
lready asked
>>>>> David Miller to put it on his stable queue? IMO it qualifies quite =
well and the
>>>>> actual change should be simple to pick/backport.
>>>>>
>>>>
>>>> Thank you Stefan, I'm queuing this for the next 3.16 kernel release.=

>>>
>>> Don't backport this yes.  It's broken.  It produces malformed request=
s
>>> and netback will report a fatal error and stop all traffic on the VIF=
=2E
>>
>> Thanks David. Did this just come up? I don't remember seeing any repor=
t of the
>> regression. :/
>=20
> There's been a couple of reports on xen-devel recently with 3.17
> frontends and I've just repro'd it (by always forcing a skb_linearize()=

> in netfront).

Ah ok. Found at least one now (plus your fixup proposal). Too long ago to=

remember for sure but I thought the change was tested by reporters. Could=
 be
that I only had tried the approach I was working on back then (which was =
more
complicated trying to replace individual frags by aligned copies). :( And=
 on our
devel we have not yet switched to past 3.16. Hope I can squeeze in some t=
esting
there.

-Stefan
>=20
> David
>=20



--f7iA47JQTeHghJ9oOxmoFewQk37w8ALJa
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

iQIcBAEBCgAGBQJUhZnuAAoJEOhnXe7L7s6jJScQAIBUR+QoWXOaZFdhS3HarkGU
SD5UlLLRLHJLQmbpVxfN7pggd8VFW5bLA0f5r8kffSOmuMf7Zm86Y4KGaO5k+qG7
cPvYkv8rrJUY1kRGsVv/9y3IsA3ppR/mKT9E/5ow+o2AGdmBONKTjMuSJwXjId6A
wfq5M0RNSRlAnWrAbdYbBQZo50gMW+UgW7d5JfvigRfNMVGT6BJrD6MteWW9p4+P
NlMpangg1O1wUbo1UZwItszdxovBWz2qkm0qsUgNI9bvBMIlGd4voO1da3mraeN8
LWnpAQVyU8wTVgG6TNX3S+cnq4Bd8J3MR9TIyqMrqBPMw+YqI4NgXGJSa6NwyOc4
mpEZoFC/uaE8Nf28gj+FqtDejWt5ZUmnQLBQdUN32e+U80VZBwJ7DlzRbh0+WO16
BlI2lqAorCxpz9Z1eKSQwx7w2Bm7Kylxnrg0hCA/smIOBZdZolOaH7op6qDyTsKE
IqbjUxeR4a0KtNxz0L4W6+2TpHZEwlN3uiFffF6ORjBevB6mkRufLMF3slJ3z7ju
QHWMFHNWxXOse8IFgBqFG/fNkC0664GACejuIU3bm4nsFls7Wv9QvpzSWzTvKbtO
tgjm/gsmzXVOOrMQjKwbIVYreBvTrQjnPpndtFo+YF28YsguMdUGuJdtN+WBPDoX
hyPtAR/GBSecbCEZFfQl
=e9Bj
-----END PGP SIGNATURE-----

--f7iA47JQTeHghJ9oOxmoFewQk37w8ALJa--


--===============8681200982878047249==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8681200982878047249==--


From xen-devel-bounces@lists.xen.org Mon Dec 08 12:38:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12:38:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxxZO-0006i1-Tr; Mon, 08 Dec 2014 12:37:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XxxZN-0006hw-VW
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 12:37:42 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	9B/43-24859-59B95845; Mon, 08 Dec 2014 12:37:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418042260!11778600!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30016 invoked from network); 8 Dec 2014 12:37:40 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 12:37:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418042260; l=8395;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=z8SBQZTeKQ+sLoVmGEsj9auih+Q=;
	b=pEIGPOFI4Qcsy1hBbJ0dWdkSPF+42OlTifxBWR4NKYtDAFIEvfeWyckN2SjJlBXlZsL
	re8debv6Jgaouwm1hLPZUHgYNvE3VxUgQsVpelhqkeeQi/oJoYzuSx5YvttCNAeUaJbvN
	fk9uf/KYBAYulDsPboh8H7X3ZXqLmI75XeU=
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.3 AUTH) with ESMTPSA id z07ad5qB8Cbb2qN
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 13:37:37 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0C9255015F; Mon,  8 Dec 2014 13:37:36 +0100 (CET)
Date: Mon, 8 Dec 2014 13:37:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141208123736.GA3691@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21633.41977.399042.691409@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Ian Jackson wrote:

> I think the only way to make this work properly is to factor the
> necessary parts out of init.d/xencommons into a new script which can
> be used by both xencommons and systemd.  I'm not sure such a patch
> would be appropriate for 4.5 at this stage.

I came up with this, it appears to work in my testing. Will do more
testing later today.

Olaf
---
 .gitignore                                       |  1 +
 tools/configure                                  |  3 +-
 tools/configure.ac                               |  1 +
 tools/hotplug/Linux/Makefile                     |  2 ++
 tools/hotplug/Linux/init.d/xencommons.in         | 24 +------------
 tools/hotplug/Linux/systemd/xenstored.service.in |  7 +---
 tools/hotplug/Linux/xenstored.sh.in              | 44 ++++++++++++++++++++++++
 7 files changed, 52 insertions(+), 30 deletions(-)
 create mode 100644 tools/hotplug/Linux/xenstored.sh.in

diff --git a/.gitignore b/.gitignore
index 8c8c06f..7e6884a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -153,6 +153,7 @@ tools/hotplug/Linux/vif-setup
 tools/hotplug/Linux/xen-backend.rules
 tools/hotplug/Linux/xen-hotplug-common.sh
 tools/hotplug/Linux/xendomains
+tools/hotplug/Linux/xenstored.sh
 tools/hotplug/NetBSD/rc.d/xencommons
 tools/include/xen/*
 tools/include/xen-foreign/*.(c|h|size)
diff --git a/tools/configure b/tools/configure
index b0aea0a..e72876c 100755
--- a/tools/configure
+++ b/tools/configure
@@ -2276,7 +2276,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 
 
-ac_config_files="$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket hotplug/Linux/vif-setup hotplug/Linux/xen-backend.rules hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons"
+ac_config_files="$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket hotplug/Linux/vif-setup hotplug/Linux/xen-backend.rules hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/Linux/xenstored.sh hotplug/NetBSD/rc.d/xencommons"
 
 ac_config_headers="$ac_config_headers config.h"
 
@@ -9585,6 +9585,7 @@ do
     "hotplug/Linux/xen-backend.rules") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xen-backend.rules" ;;
     "hotplug/Linux/xen-hotplug-common.sh") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xen-hotplug-common.sh" ;;
     "hotplug/Linux/xendomains") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xendomains" ;;
+    "hotplug/Linux/xenstored.sh") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xenstored.sh" ;;
     "hotplug/NetBSD/rc.d/xencommons") CONFIG_FILES="$CONFIG_FILES hotplug/NetBSD/rc.d/xencommons" ;;
     "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;;
 
diff --git a/tools/configure.ac b/tools/configure.ac
index 1ac63a3..8f198e8 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -26,6 +26,7 @@ hotplug/Linux/vif-setup
 hotplug/Linux/xen-backend.rules
 hotplug/Linux/xen-hotplug-common.sh
 hotplug/Linux/xendomains
+hotplug/Linux/xenstored.sh
 hotplug/NetBSD/rc.d/xencommons
 ])
 AC_CONFIG_HEADERS([config.h])
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 1706c05..e9a1ef0 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -2,6 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 # Init scripts.
+XENSTORED_LIBEXEC = xenstored.sh
 XENDOMAINS_INITD = init.d/xendomains
 XENDOMAINS_LIBEXEC = xendomains
 XENDOMAINS_SYSCONFIG = init.d/sysconfig.xendomains
@@ -51,6 +52,7 @@ install-initd:
 	[ -d $(DESTDIR)$(INITD_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(INITD_DIR)
 	[ -d $(DESTDIR)$(SYSCONFIG_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(SYSCONFIG_DIR)
 	[ -d $(DESTDIR)$(LIBEXEC_BIN) ] || $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
+	$(INSTALL_PROG) $(XENSTORED_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)
 	$(INSTALL_PROG) $(XENDOMAINS_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)
 	$(INSTALL_PROG) $(XENDOMAINS_INITD) $(DESTDIR)$(INITD_DIR)
 	$(INSTALL_DATA) $(XENDOMAINS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xendomains
diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
index a1095c2..d03dd59 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -18,7 +18,6 @@
 # Description:       Starts and stops the daemons neeeded for xl/xend
 ### END INIT INFO
 
-XENSTORED=@XENSTORED@
 BACKEND_MODULES="@LINUX_BACKEND_MODULES@"
 
 . @XEN_SCRIPT_DIR@/hotplugpath.sh
@@ -64,28 +63,7 @@ do_start () {
 
 	if ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1`
 	then
-		test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
-		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
-		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
-
-		if [ -n "$XENSTORED" ] ; then
-		    echo -n Starting $XENSTORED...
-		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
-		else
-		    echo "No xenstored found"
-		    exit 1
-		fi
-
-		# Wait for xenstored to actually come up, timing out after 30 seconds
-                while [ $time -lt $timeout ] && ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1` ; do
-                    echo -n .
-		    time=$(($time+1))
-                    sleep 1
-                done
-		echo
-
-		# Exit if we timed out
-		if ! [ $time -lt $timeout ] ; then
+		if ! ${LIBEXEC_BIN}/xenstored.sh --opt --pid-file --opt /var/run/xenstored.pid ; then
 		    echo Could not start xenstored
 		    exit 1
 		fi
diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 0f0ac58..01f5726 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -8,13 +8,8 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=notify
-Environment=XENSTORED_ARGS=
-Environment=XENSTORED=@XENSTORED@
-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@
-ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
+ExecStart=-@LIBEXEC_BIN@/xenstored.sh --exec --opt "--no-fork"
 
 [Install]
 WantedBy=multi-user.target
diff --git a/tools/hotplug/Linux/xenstored.sh.in b/tools/hotplug/Linux/xenstored.sh.in
new file mode 100644
index 0000000..11caf25
--- /dev/null
+++ b/tools/hotplug/Linux/xenstored.sh.in
@@ -0,0 +1,44 @@
+#!/bin/bash
+do_exec=
+ret=1
+declare -a opts
+while test $# -gt 0
+do
+    case "$1" in
+    --exec)
+        do_exec="exec"
+    ;;
+    --opt)
+        opts=(${opts[@]} "$2")
+        shift
+    ;;
+    esac
+    shift
+done
+
+. @XEN_SCRIPT_DIR@/hotplugpath.sh
+
+XENSTORED=@XENSTORED@
+XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
+
+xencommons_config=@CONFIG_DIR@/@CONFIG_LEAF_DIR@
+test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
+
+rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
+test -z "$XENSTORED_TRACE" || XENSTORED_TRACE_ARGS=" -T /var/log/xen/xenstored-trace.log"
+
+echo -n Starting $XENSTORED...
+if $do_exec $XENSTORED ${opts[@]} $XENSTORED_TRACE_ARGS $XENSTORED_ARGS
+then
+    # Wait for xenstored to actually come up, timing out after 30 seconds
+    while [ $time -lt $timeout ] && ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1` ; do
+        echo -n .
+        time=$(($time+1))
+        sleep 1
+    done
+    echo
+    if [ $time -lt $timeout ]; then
+        ret=0
+    fi
+fi
+exit ${ret}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 12:38:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12:38:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxxZO-0006i1-Tr; Mon, 08 Dec 2014 12:37:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XxxZN-0006hw-VW
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 12:37:42 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	9B/43-24859-59B95845; Mon, 08 Dec 2014 12:37:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418042260!11778600!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30016 invoked from network); 8 Dec 2014 12:37:40 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 12:37:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418042260; l=8395;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=z8SBQZTeKQ+sLoVmGEsj9auih+Q=;
	b=pEIGPOFI4Qcsy1hBbJ0dWdkSPF+42OlTifxBWR4NKYtDAFIEvfeWyckN2SjJlBXlZsL
	re8debv6Jgaouwm1hLPZUHgYNvE3VxUgQsVpelhqkeeQi/oJoYzuSx5YvttCNAeUaJbvN
	fk9uf/KYBAYulDsPboh8H7X3ZXqLmI75XeU=
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.3 AUTH) with ESMTPSA id z07ad5qB8Cbb2qN
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 13:37:37 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0C9255015F; Mon,  8 Dec 2014 13:37:36 +0100 (CET)
Date: Mon, 8 Dec 2014 13:37:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141208123736.GA3691@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21633.41977.399042.691409@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Ian Jackson wrote:

> I think the only way to make this work properly is to factor the
> necessary parts out of init.d/xencommons into a new script which can
> be used by both xencommons and systemd.  I'm not sure such a patch
> would be appropriate for 4.5 at this stage.

I came up with this, it appears to work in my testing. Will do more
testing later today.

Olaf
---
 .gitignore                                       |  1 +
 tools/configure                                  |  3 +-
 tools/configure.ac                               |  1 +
 tools/hotplug/Linux/Makefile                     |  2 ++
 tools/hotplug/Linux/init.d/xencommons.in         | 24 +------------
 tools/hotplug/Linux/systemd/xenstored.service.in |  7 +---
 tools/hotplug/Linux/xenstored.sh.in              | 44 ++++++++++++++++++++++++
 7 files changed, 52 insertions(+), 30 deletions(-)
 create mode 100644 tools/hotplug/Linux/xenstored.sh.in

diff --git a/.gitignore b/.gitignore
index 8c8c06f..7e6884a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -153,6 +153,7 @@ tools/hotplug/Linux/vif-setup
 tools/hotplug/Linux/xen-backend.rules
 tools/hotplug/Linux/xen-hotplug-common.sh
 tools/hotplug/Linux/xendomains
+tools/hotplug/Linux/xenstored.sh
 tools/hotplug/NetBSD/rc.d/xencommons
 tools/include/xen/*
 tools/include/xen-foreign/*.(c|h|size)
diff --git a/tools/configure b/tools/configure
index b0aea0a..e72876c 100755
--- a/tools/configure
+++ b/tools/configure
@@ -2276,7 +2276,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 
 
-ac_config_files="$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket hotplug/Linux/vif-setup hotplug/Linux/xen-backend.rules hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons"
+ac_config_files="$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket hotplug/Linux/vif-setup hotplug/Linux/xen-backend.rules hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/Linux/xenstored.sh hotplug/NetBSD/rc.d/xencommons"
 
 ac_config_headers="$ac_config_headers config.h"
 
@@ -9585,6 +9585,7 @@ do
     "hotplug/Linux/xen-backend.rules") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xen-backend.rules" ;;
     "hotplug/Linux/xen-hotplug-common.sh") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xen-hotplug-common.sh" ;;
     "hotplug/Linux/xendomains") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xendomains" ;;
+    "hotplug/Linux/xenstored.sh") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xenstored.sh" ;;
     "hotplug/NetBSD/rc.d/xencommons") CONFIG_FILES="$CONFIG_FILES hotplug/NetBSD/rc.d/xencommons" ;;
     "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;;
 
diff --git a/tools/configure.ac b/tools/configure.ac
index 1ac63a3..8f198e8 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -26,6 +26,7 @@ hotplug/Linux/vif-setup
 hotplug/Linux/xen-backend.rules
 hotplug/Linux/xen-hotplug-common.sh
 hotplug/Linux/xendomains
+hotplug/Linux/xenstored.sh
 hotplug/NetBSD/rc.d/xencommons
 ])
 AC_CONFIG_HEADERS([config.h])
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 1706c05..e9a1ef0 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -2,6 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 # Init scripts.
+XENSTORED_LIBEXEC = xenstored.sh
 XENDOMAINS_INITD = init.d/xendomains
 XENDOMAINS_LIBEXEC = xendomains
 XENDOMAINS_SYSCONFIG = init.d/sysconfig.xendomains
@@ -51,6 +52,7 @@ install-initd:
 	[ -d $(DESTDIR)$(INITD_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(INITD_DIR)
 	[ -d $(DESTDIR)$(SYSCONFIG_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(SYSCONFIG_DIR)
 	[ -d $(DESTDIR)$(LIBEXEC_BIN) ] || $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
+	$(INSTALL_PROG) $(XENSTORED_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)
 	$(INSTALL_PROG) $(XENDOMAINS_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)
 	$(INSTALL_PROG) $(XENDOMAINS_INITD) $(DESTDIR)$(INITD_DIR)
 	$(INSTALL_DATA) $(XENDOMAINS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xendomains
diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
index a1095c2..d03dd59 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -18,7 +18,6 @@
 # Description:       Starts and stops the daemons neeeded for xl/xend
 ### END INIT INFO
 
-XENSTORED=@XENSTORED@
 BACKEND_MODULES="@LINUX_BACKEND_MODULES@"
 
 . @XEN_SCRIPT_DIR@/hotplugpath.sh
@@ -64,28 +63,7 @@ do_start () {
 
 	if ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1`
 	then
-		test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
-		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
-		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
-
-		if [ -n "$XENSTORED" ] ; then
-		    echo -n Starting $XENSTORED...
-		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
-		else
-		    echo "No xenstored found"
-		    exit 1
-		fi
-
-		# Wait for xenstored to actually come up, timing out after 30 seconds
-                while [ $time -lt $timeout ] && ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1` ; do
-                    echo -n .
-		    time=$(($time+1))
-                    sleep 1
-                done
-		echo
-
-		# Exit if we timed out
-		if ! [ $time -lt $timeout ] ; then
+		if ! ${LIBEXEC_BIN}/xenstored.sh --opt --pid-file --opt /var/run/xenstored.pid ; then
 		    echo Could not start xenstored
 		    exit 1
 		fi
diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 0f0ac58..01f5726 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -8,13 +8,8 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=notify
-Environment=XENSTORED_ARGS=
-Environment=XENSTORED=@XENSTORED@
-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@
-ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
+ExecStart=-@LIBEXEC_BIN@/xenstored.sh --exec --opt "--no-fork"
 
 [Install]
 WantedBy=multi-user.target
diff --git a/tools/hotplug/Linux/xenstored.sh.in b/tools/hotplug/Linux/xenstored.sh.in
new file mode 100644
index 0000000..11caf25
--- /dev/null
+++ b/tools/hotplug/Linux/xenstored.sh.in
@@ -0,0 +1,44 @@
+#!/bin/bash
+do_exec=
+ret=1
+declare -a opts
+while test $# -gt 0
+do
+    case "$1" in
+    --exec)
+        do_exec="exec"
+    ;;
+    --opt)
+        opts=(${opts[@]} "$2")
+        shift
+    ;;
+    esac
+    shift
+done
+
+. @XEN_SCRIPT_DIR@/hotplugpath.sh
+
+XENSTORED=@XENSTORED@
+XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
+
+xencommons_config=@CONFIG_DIR@/@CONFIG_LEAF_DIR@
+test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
+
+rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
+test -z "$XENSTORED_TRACE" || XENSTORED_TRACE_ARGS=" -T /var/log/xen/xenstored-trace.log"
+
+echo -n Starting $XENSTORED...
+if $do_exec $XENSTORED ${opts[@]} $XENSTORED_TRACE_ARGS $XENSTORED_ARGS
+then
+    # Wait for xenstored to actually come up, timing out after 30 seconds
+    while [ $time -lt $timeout ] && ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1` ; do
+        echo -n .
+        time=$(($time+1))
+        sleep 1
+    done
+    echo
+    if [ $time -lt $timeout ]; then
+        ret=0
+    fi
+fi
+exit ${ret}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 12:43:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12:43:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxxew-0006st-Oa; Mon, 08 Dec 2014 12:43:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xxxev-0006so-MS
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 12:43:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	88/5B-25276-CEC95845; Mon, 08 Dec 2014 12:43:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418042602!6109834!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 18082 invoked from network); 8 Dec 2014 12:43:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 12:43:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201765374"
Message-ID: <1418042600.2827.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sagun Garg <sagun@nexchanges.com>
Date: Mon, 8 Dec 2014 12:43:20 +0000
In-Reply-To: <CALwCXQBKKtFT2qrgDmiKZck6mnYH22dJAb4PM9VfM=t8xuoCCA@mail.gmail.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
	<1417688979.22808.6.camel@citrix.com>
	<CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@mail.gmail.com>
	<1417771940.22808.39.camel@citrix.com>
	<CALwCXQBKKtFT2qrgDmiKZck6mnYH22dJAb4PM9VfM=t8xuoCCA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: julien.grall@linaro.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2014-12-06 at 14:28 +0530, Sagun Garg wrote:

> Links
> http://labs.online.net/press and http://labs.online.net/ Will it be ok
> to install Xen on this? They are still in their trial mode. 

I'm not aware of anyone having run Xen on a marvel chipset, but in
principal a port should be doable for someone who is interested. I
obviously can't comment on the features of this particular service wrt
installing and running your own OSes. 

> Also I had a unrelated question, does Xen on Arm have  support for ELF
> kernels (bzImage only). If yes can you please point out where
> discussions relating to his are happening and if not any idea on
> whether there is going to be support in near future?

bzImage is an x86 specific concept (and one which is somewhat orthogonal
to ELF at that).

On ARM we currently support kernels in the ARM Linux zImage format.

There have been some people looking at direct ELF loading, but I think
anyone who started down that path eventually decided that sticking a
zImage header on the front of a raw binary kernel was easier. AFAIK
noone is still looking into ELF.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 12:43:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12:43:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxxew-0006st-Oa; Mon, 08 Dec 2014 12:43:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xxxev-0006so-MS
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 12:43:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	88/5B-25276-CEC95845; Mon, 08 Dec 2014 12:43:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418042602!6109834!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 18082 invoked from network); 8 Dec 2014 12:43:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 12:43:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201765374"
Message-ID: <1418042600.2827.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sagun Garg <sagun@nexchanges.com>
Date: Mon, 8 Dec 2014 12:43:20 +0000
In-Reply-To: <CALwCXQBKKtFT2qrgDmiKZck6mnYH22dJAb4PM9VfM=t8xuoCCA@mail.gmail.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
	<1417688979.22808.6.camel@citrix.com>
	<CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@mail.gmail.com>
	<1417771940.22808.39.camel@citrix.com>
	<CALwCXQBKKtFT2qrgDmiKZck6mnYH22dJAb4PM9VfM=t8xuoCCA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: julien.grall@linaro.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2014-12-06 at 14:28 +0530, Sagun Garg wrote:

> Links
> http://labs.online.net/press and http://labs.online.net/ Will it be ok
> to install Xen on this? They are still in their trial mode. 

I'm not aware of anyone having run Xen on a marvel chipset, but in
principal a port should be doable for someone who is interested. I
obviously can't comment on the features of this particular service wrt
installing and running your own OSes. 

> Also I had a unrelated question, does Xen on Arm have  support for ELF
> kernels (bzImage only). If yes can you please point out where
> discussions relating to his are happening and if not any idea on
> whether there is going to be support in near future?

bzImage is an x86 specific concept (and one which is somewhat orthogonal
to ELF at that).

On ARM we currently support kernels in the ARM Linux zImage format.

There have been some people looking at direct ELF loading, but I think
anyone who started down that path eventually decided that sticking a
zImage header on the front of a raw binary kernel was easier. AFAIK
noone is still looking into ELF.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 12:47:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12:47:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxxiX-0007C6-CV; Mon, 08 Dec 2014 12:47: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 1XxxiV-0007Bu-B9
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 12:47:07 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	CE/EB-02699-ACD95845; Mon, 08 Dec 2014 12:47:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418042824!13678766!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 11359 invoked from network); 8 Dec 2014 12:47: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;
	8 Dec 2014 12:47:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201369610"
Message-ID: <1418042822.2827.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sagun Garg <sagun@nexchanges.com>
Date: Mon, 8 Dec 2014 12:47:02 +0000
In-Reply-To: <CALwCXQBxLZnX1JX10JDEtA7whUZohFSb2jutNghU33SEwZ3gJQ@mail.gmail.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
	<1417688979.22808.6.camel@citrix.com>
	<CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@mail.gmail.com>
	<1417771940.22808.39.camel@citrix.com>
	<CALwCXQBKKtFT2qrgDmiKZck6mnYH22dJAb4PM9VfM=t8xuoCCA@mail.gmail.com>
	<CALwCXQBxLZnX1JX10JDEtA7whUZohFSb2jutNghU33SEwZ3gJQ@mail.gmail.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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2014-12-07 at 15:00 +0530, Sagun Garg wrote:

> Hi Ian/Julien,

You only mailed me, not Julien or the list. Given you addressed it to
Julien I have assumed that the lack of CC was in error and added both
back. Please keep things on the list in future.

> I happened to find this link :
> http://sourceforge.net/projects/embeddedxen/?source=typ_redirect
> 
> 
> This looks like Xen on ARM ( For Nexus 5). 

It is a separate project. It is certainly nothing to do with the "Xen
ARM with Virtualization Extensions" stuff maintained in mainline Xen and
on this list.

I don't know what, if any, relationship it has with the "Xen ARM (PV)"
port. In any case none of the people involved are active on this list,
you would have to ask them what it was all about.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 12:47:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 12:47:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxxiX-0007C6-CV; Mon, 08 Dec 2014 12:47: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 1XxxiV-0007Bu-B9
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 12:47:07 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	CE/EB-02699-ACD95845; Mon, 08 Dec 2014 12:47:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418042824!13678766!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 11359 invoked from network); 8 Dec 2014 12:47: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;
	8 Dec 2014 12:47:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201369610"
Message-ID: <1418042822.2827.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sagun Garg <sagun@nexchanges.com>
Date: Mon, 8 Dec 2014 12:47:02 +0000
In-Reply-To: <CALwCXQBxLZnX1JX10JDEtA7whUZohFSb2jutNghU33SEwZ3gJQ@mail.gmail.com>
References: <CALwCXQCmYi4HpLs3xXCPhs3_SrfLF_HGdrUKUjuJ7e8LgCfj5g@mail.gmail.com>
	<1417688979.22808.6.camel@citrix.com>
	<CALwCXQCd-RKXPcLuP+uEa_-g-wmjTm5-2n9YB2oA6RSyJLii4g@mail.gmail.com>
	<1417771940.22808.39.camel@citrix.com>
	<CALwCXQBKKtFT2qrgDmiKZck6mnYH22dJAb4PM9VfM=t8xuoCCA@mail.gmail.com>
	<CALwCXQBxLZnX1JX10JDEtA7whUZohFSb2jutNghU33SEwZ3gJQ@mail.gmail.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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Install Xen on ARM in a bare metal fashion on a
 Nexus Phone/Tablet or an ARM emulator
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2014-12-07 at 15:00 +0530, Sagun Garg wrote:

> Hi Ian/Julien,

You only mailed me, not Julien or the list. Given you addressed it to
Julien I have assumed that the lack of CC was in error and added both
back. Please keep things on the list in future.

> I happened to find this link :
> http://sourceforge.net/projects/embeddedxen/?source=typ_redirect
> 
> 
> This looks like Xen on ARM ( For Nexus 5). 

It is a separate project. It is certainly nothing to do with the "Xen
ARM with Virtualization Extensions" stuff maintained in mainline Xen and
on this list.

I don't know what, if any, relationship it has with the "Xen ARM (PV)"
port. In any case none of the people involved are active on this list,
you would have to ask them what it was all about.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 13:09:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1Xxy3O-0007jt-A4; Mon, 08 Dec 2014 13:08:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1Xxy3M-0007jo-Eq
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 13:08:40 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	32/54-07724-7D2A5845; Mon, 08 Dec 2014 13:08:39 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418044115!11808357!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21596 invoked from network); 8 Dec 2014 13:08:38 -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;
	8 Dec 2014 13:08:38 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDR03689; Mon, 08 Dec 2014 21:08:27 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.62]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Mon, 8 Dec 2014 21:08:18 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIABdSnQgAA8hYCABNK9gP//un4AABZULrA=
Date: Mon, 8 Dec 2014 13:08:18 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2394C523@SZXEMA512-MBX.china.huawei.com>
References: <20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
	<20141208101304.GB17128@zion.uk.xensource.com>
In-Reply-To: <20141208101304.GB17128@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Mon, Dec 08, 2014 at 06:44:26AM +0000, Zhangleiqiang (Trump) wrote:
> > > On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
> > > [...]
> > > > > I think that's expected, because guest RX data path still uses
> > > > > grant_copy while guest TX uses grant_map to do zero-copy transmit.
> > > >
> > > > As far as I know, there are three main grant-related operations
> > > > used in split
> > > device model: grant mapping, grant transfer and grant copy.
> > > > Grant transfer has not used now, and grant mapping and grant
> > > > transfer both
> > > involve "TLB" refresh work for hypervisor, am I right?  Or only
> > > grant transfer has this overhead?
> > >
> > > Transfer is not used so I can't tell. Grant unmap causes TLB flush.
> > >
> > > I saw in an email the other day XenServer folks has some planned
> > > improvement to avoid TLB flush in Xen to upstream in 4.6 window. I
> > > can't speak for sure it will get upstreamed as I don't work on that.
> > >
> > > > Does grant copy surely has more overhead than grant mapping?
> > > >
> > >
> > > At the very least the zero-copy TX path is faster than previous copying path.
> > >
> > > But speaking of the micro operation I'm not sure.
> > >
> > > There was once persistent map prototype netback / netfront that
> > > establishes a memory pool between FE and BE then use memcpy to copy
> > > data. Unfortunately that prototype was not done right so the result was not
> good.
> >
> > The newest mail about persistent grant I can find is sent from 16 Nov
> > 2012
> > (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00832.html).
> > Why is it not done right and not merged into upstream?
> 
> AFAICT there's one more memcpy than necessary, i.e. frontend memcpy data
> into the pool then backend memcpy data out of the pool, when backend should
> be able to use the page in pool directly.

Memcpy should cheaper than grant_copy because the former needs not the "hypercall" which will cause "VM Exit" to "XEN Hypervisor", am I right? For RX path, using memcpy based on persistent grant table may have higher performance than using grant copy now.

I have seen "move grant copy to guest" and "Fix grant copy alignment problem" as optimization methods used in "NetChannel2" (http://www-archive.xenproject.org/files/xensummit_fall07/16_JoseRenatoSantos.pdf). Unfortunately, NetChannel2 seems not be supported from 2.6.32. Do you know them and are them be helpful for RX path optimization under current upstream implementation?

By the way, after rethinking the testing results for multi-queue pv (kernel 3.17.4+XEN 4.4) implementation, I find that when using four queues for netback/netfront, there will be about 3 netback process running with high CPU usage on receive Dom0 (about 85% usage per process running on one CPU core), and the aggregate throughout is only about 5Gbps. I doubt that there may be some bug or pitfall in current multi-queue implementation, because for 5Gbps throughout, occurring about all of 3 CPU core for packet receiving is somehow abnormal.

> >
> > And I also search for virtio support in XEN, and I find that the one
> > who are familiar with it is you, too,
> > (http://wiki.xen.org/wiki/Virtio_On_Xen), :-). I am wondering what is
> > the current state for virtio on XEN?
> 
> Yes, it was me. I never have the time to revisit that. I don't think we support
> virtio network at the moment.
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 13:09:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 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 1Xxy3O-0007jt-A4; Mon, 08 Dec 2014 13:08:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1Xxy3M-0007jo-Eq
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 13:08:40 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	32/54-07724-7D2A5845; Mon, 08 Dec 2014 13:08:39 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418044115!11808357!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21596 invoked from network); 8 Dec 2014 13:08:38 -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;
	8 Dec 2014 13:08:38 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDR03689; Mon, 08 Dec 2014 21:08:27 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.62]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Mon, 8 Dec 2014 21:08:18 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIABdSnQgAA8hYCABNK9gP//un4AABZULrA=
Date: Mon, 8 Dec 2014 13:08:18 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2394C523@SZXEMA512-MBX.china.huawei.com>
References: <20141202110133.GA5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23931FA1@SZXEMA512-MBX.china.huawei.com>
	<20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
	<20141208101304.GB17128@zion.uk.xensource.com>
In-Reply-To: <20141208101304.GB17128@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Mon, Dec 08, 2014 at 06:44:26AM +0000, Zhangleiqiang (Trump) wrote:
> > > On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
> > > [...]
> > > > > I think that's expected, because guest RX data path still uses
> > > > > grant_copy while guest TX uses grant_map to do zero-copy transmit.
> > > >
> > > > As far as I know, there are three main grant-related operations
> > > > used in split
> > > device model: grant mapping, grant transfer and grant copy.
> > > > Grant transfer has not used now, and grant mapping and grant
> > > > transfer both
> > > involve "TLB" refresh work for hypervisor, am I right?  Or only
> > > grant transfer has this overhead?
> > >
> > > Transfer is not used so I can't tell. Grant unmap causes TLB flush.
> > >
> > > I saw in an email the other day XenServer folks has some planned
> > > improvement to avoid TLB flush in Xen to upstream in 4.6 window. I
> > > can't speak for sure it will get upstreamed as I don't work on that.
> > >
> > > > Does grant copy surely has more overhead than grant mapping?
> > > >
> > >
> > > At the very least the zero-copy TX path is faster than previous copying path.
> > >
> > > But speaking of the micro operation I'm not sure.
> > >
> > > There was once persistent map prototype netback / netfront that
> > > establishes a memory pool between FE and BE then use memcpy to copy
> > > data. Unfortunately that prototype was not done right so the result was not
> good.
> >
> > The newest mail about persistent grant I can find is sent from 16 Nov
> > 2012
> > (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00832.html).
> > Why is it not done right and not merged into upstream?
> 
> AFAICT there's one more memcpy than necessary, i.e. frontend memcpy data
> into the pool then backend memcpy data out of the pool, when backend should
> be able to use the page in pool directly.

Memcpy should cheaper than grant_copy because the former needs not the "hypercall" which will cause "VM Exit" to "XEN Hypervisor", am I right? For RX path, using memcpy based on persistent grant table may have higher performance than using grant copy now.

I have seen "move grant copy to guest" and "Fix grant copy alignment problem" as optimization methods used in "NetChannel2" (http://www-archive.xenproject.org/files/xensummit_fall07/16_JoseRenatoSantos.pdf). Unfortunately, NetChannel2 seems not be supported from 2.6.32. Do you know them and are them be helpful for RX path optimization under current upstream implementation?

By the way, after rethinking the testing results for multi-queue pv (kernel 3.17.4+XEN 4.4) implementation, I find that when using four queues for netback/netfront, there will be about 3 netback process running with high CPU usage on receive Dom0 (about 85% usage per process running on one CPU core), and the aggregate throughout is only about 5Gbps. I doubt that there may be some bug or pitfall in current multi-queue implementation, because for 5Gbps throughout, occurring about all of 3 CPU core for packet receiving is somehow abnormal.

> >
> > And I also search for virtio support in XEN, and I find that the one
> > who are familiar with it is you, too,
> > (http://wiki.xen.org/wiki/Virtio_On_Xen), :-). I am wondering what is
> > the current state for virtio on XEN?
> 
> Yes, it was me. I never have the time to revisit that. I don't think we support
> virtio network at the moment.
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 13:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 13:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxyS4-0000GT-MR; Mon, 08 Dec 2014 13:34: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 1XxyS2-0000GO-Jj
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 13:34:11 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	DE/EC-01660-1D8A5845; Mon, 08 Dec 2014 13:34:09 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418045639!6731671!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12758 invoked from network); 8 Dec 2014 13:34:06 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2014 13:34:06 -0000
Received: from mail-qa0-f50.google.com ([209.85.216.50]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVIWox3YEZyNjTrFr5simt31vcQ6uzMBq@postini.com;
	Mon, 08 Dec 2014 05:34:06 PST
Received: by mail-qa0-f50.google.com with SMTP id w8so3278485qac.37
	for <xen-devel@lists.xen.org>; Mon, 08 Dec 2014 05:33: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=SQkawgvHdrgq0zPtODvpBw7ofpirSas2AfBChsJ+OWE=;
	b=bbwfDQtZWY63gFUTjKjgLtDdYXz8WX5D9rP7e0Djm0dby54Y2FXk4zWIEOre/wuLnC
	umEUrF9PSfO+qgdL8lLPdnqGYbQhDhRP1gbRFa4fnMedwYIGkcQoGu+C2rwMgp4H5cbB
	yk9E4AyXqI/Gnr9Wci3E8Sxrp0Vf8LqoLwjXM=
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=SQkawgvHdrgq0zPtODvpBw7ofpirSas2AfBChsJ+OWE=;
	b=GDXCvUmW79fvI2ljKMVmNyE7qkEOA7bTZDUcFBMrDLY+eEZ8mtMau4+D0Z2aEg47Ib
	8KT4O5fRBp0sIgx65d/mGpXI5JQfR9/nkOqTb8QWW/sIvABe1HGxbbnnTVINrWWj5bhL
	KMvc1Mq8VCGsjQQLGuqWSWVAsl0LT6P5VmOV26PUtVA5Bw4jcGCoXdJQYGnp2bD7C5QV
	Aq/Wf5zNX85AsNS1IH+3LZtKK+iedBJQXngkvg/CbxS4h4y8F7NDfgOoqmOHoVXjb+0f
	X6F+yaIJ0Jev3kPLbcnm8yJUocrYqekq1TlXMfgMg/3BaPlfNp2xNBomb0F2owjk71P2
	lGyg==
X-Gm-Message-State: ALoCoQmOUguQ/bWcE9wnz/0litbgKFbXElOAgbHEDmBPOdhZrqPFkcr68Rg5s4H2OyKRGl/q1xPlflaCCYILVgZatWoweY+NI+SKAlr5rXFyopPgc63/mfc+Fs/gBdSkwJgk5oPMj3gjB3La0USD8M3lBIZWkzWr1g==
X-Received: by 10.224.29.134 with SMTP id q6mr51259917qac.73.1418045623419;
	Mon, 08 Dec 2014 05:33:43 -0800 (PST)
X-Received: by 10.224.29.134 with SMTP id q6mr51259899qac.73.1418045623328;
	Mon, 08 Dec 2014 05:33:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.93.69 with HTTP; Mon, 8 Dec 2014 05:33:23 -0800 (PST)
In-Reply-To: <5485935E.4070103@linaro.org>
References: <1417787196-3313-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<5481BF35.2060800@linaro.org>
	<CAN58jiuXwHNhQ+t27djHpH=EPhQs-D0uQ-bqxGpG0OBRK+BVLQ@mail.gmail.com>
	<5485935E.4070103@linaro.org>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Mon, 8 Dec 2014 15:33:23 +0200
Message-ID: <CAN58jis_HaJg9xEocBCcCv1zH669MDCZw15HK0Gzi6+QjjJtjg@mail.gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 8, 2014 at 2:02 PM, Julien Grall <julien.grall@linaro.org> wrote:
>
> Hi Oleksandr,
>
> Please avoid top-post.
>
> On 08/12/14 06:34, Oleksandr Dmytryshyn wrote:
> > In our case We've added an additional fake node to the device tree with
> > UART MMIO range for Xen and Xen mapped this MMIO range
> > for the Kernel 3.8. By default UART has wrong configuration in OMAP.
>
> Ok. So it has to be configured properly with Kernel 3.8 too. Your commit
> message suggests it works without any kind of workaround on this kernel
> version with Xen upstream.
>
> Can you update the commit message?
I'll do this.

> 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 Dec 08 13:34:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 13:34:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxyS4-0000GT-MR; Mon, 08 Dec 2014 13:34: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 1XxyS2-0000GO-Jj
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 13:34:11 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	DE/EC-01660-1D8A5845; Mon, 08 Dec 2014 13:34:09 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418045639!6731671!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12758 invoked from network); 8 Dec 2014 13:34:06 -0000
Received: from exprod5og105.obsmtp.com (HELO exprod5og105.obsmtp.com)
	(64.18.0.180)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2014 13:34:06 -0000
Received: from mail-qa0-f50.google.com ([209.85.216.50]) (using TLSv1) by
	exprod5ob105.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVIWox3YEZyNjTrFr5simt31vcQ6uzMBq@postini.com;
	Mon, 08 Dec 2014 05:34:06 PST
Received: by mail-qa0-f50.google.com with SMTP id w8so3278485qac.37
	for <xen-devel@lists.xen.org>; Mon, 08 Dec 2014 05:33: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=SQkawgvHdrgq0zPtODvpBw7ofpirSas2AfBChsJ+OWE=;
	b=bbwfDQtZWY63gFUTjKjgLtDdYXz8WX5D9rP7e0Djm0dby54Y2FXk4zWIEOre/wuLnC
	umEUrF9PSfO+qgdL8lLPdnqGYbQhDhRP1gbRFa4fnMedwYIGkcQoGu+C2rwMgp4H5cbB
	yk9E4AyXqI/Gnr9Wci3E8Sxrp0Vf8LqoLwjXM=
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=SQkawgvHdrgq0zPtODvpBw7ofpirSas2AfBChsJ+OWE=;
	b=GDXCvUmW79fvI2ljKMVmNyE7qkEOA7bTZDUcFBMrDLY+eEZ8mtMau4+D0Z2aEg47Ib
	8KT4O5fRBp0sIgx65d/mGpXI5JQfR9/nkOqTb8QWW/sIvABe1HGxbbnnTVINrWWj5bhL
	KMvc1Mq8VCGsjQQLGuqWSWVAsl0LT6P5VmOV26PUtVA5Bw4jcGCoXdJQYGnp2bD7C5QV
	Aq/Wf5zNX85AsNS1IH+3LZtKK+iedBJQXngkvg/CbxS4h4y8F7NDfgOoqmOHoVXjb+0f
	X6F+yaIJ0Jev3kPLbcnm8yJUocrYqekq1TlXMfgMg/3BaPlfNp2xNBomb0F2owjk71P2
	lGyg==
X-Gm-Message-State: ALoCoQmOUguQ/bWcE9wnz/0litbgKFbXElOAgbHEDmBPOdhZrqPFkcr68Rg5s4H2OyKRGl/q1xPlflaCCYILVgZatWoweY+NI+SKAlr5rXFyopPgc63/mfc+Fs/gBdSkwJgk5oPMj3gjB3La0USD8M3lBIZWkzWr1g==
X-Received: by 10.224.29.134 with SMTP id q6mr51259917qac.73.1418045623419;
	Mon, 08 Dec 2014 05:33:43 -0800 (PST)
X-Received: by 10.224.29.134 with SMTP id q6mr51259899qac.73.1418045623328;
	Mon, 08 Dec 2014 05:33:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.93.69 with HTTP; Mon, 8 Dec 2014 05:33:23 -0800 (PST)
In-Reply-To: <5485935E.4070103@linaro.org>
References: <1417787196-3313-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<5481BF35.2060800@linaro.org>
	<CAN58jiuXwHNhQ+t27djHpH=EPhQs-D0uQ-bqxGpG0OBRK+BVLQ@mail.gmail.com>
	<5485935E.4070103@linaro.org>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Mon, 8 Dec 2014 15:33:23 +0200
Message-ID: <CAN58jis_HaJg9xEocBCcCv1zH669MDCZw15HK0Gzi6+QjjJtjg@mail.gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 8, 2014 at 2:02 PM, Julien Grall <julien.grall@linaro.org> wrote:
>
> Hi Oleksandr,
>
> Please avoid top-post.
>
> On 08/12/14 06:34, Oleksandr Dmytryshyn wrote:
> > In our case We've added an additional fake node to the device tree with
> > UART MMIO range for Xen and Xen mapped this MMIO range
> > for the Kernel 3.8. By default UART has wrong configuration in OMAP.
>
> Ok. So it has to be configured properly with Kernel 3.8 too. Your commit
> message suggests it works without any kind of workaround on this kernel
> version with Xen upstream.
>
> Can you update the commit message?
I'll do this.

> 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 Dec 08 13:46:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 13:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxydt-0000ej-VZ; Mon, 08 Dec 2014 13:46:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xxyds-0000ee-HT
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 13:46:24 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	F1/DD-05632-FABA5845; Mon, 08 Dec 2014 13:46:23 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418046381!7375411!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 693 invoked from network); 8 Dec 2014 13:46:22 -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;
	8 Dec 2014 13:46:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201786579"
Message-ID: <5485ABAA.8050803@citrix.com>
Date: Mon, 8 Dec 2014 13:46:18 +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: Zir Blazer <zir_blazer@hotmail.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <SNT151-W418A2CEE673F81B3E75E99F3660@phx.gbl>
In-Reply-To: <SNT151-W418A2CEE673F81B3E75E99F3660@phx.gbl>
X-DLP: MIA2
Subject: Re: [Xen-devel] Some questions regarding QEMU, UEFI,
 PCI/VGA Passthrough, and other things
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 06/12/14 00:45, Zir Blazer wrote:

Replying somewhat out of order:

> I hope someone finds my questions interesing to answer.

It is certainly an interesting read - I will answer what I can.

> While I am not a developer myself (I always sucked hard when it comes to =
read and write code), there are several capabilities of Xen and its support=
ing Software which I'm always interesed in how they progress, more out of c=
uriosity than anything else. However, usually, documentation seems to backt=
rack a lot what its currently implemented in code, and sometimes you catch =
a mail here with some useful data regarding a topic but later you don't hea=
r about that any more, missing any progress, or because the whole topic was=
 inconclusive. So, this mail is pretty much a compilation of small question=
s of things I came across but didn't popped up later, but can serve to brai=
nstorm someone, which is why I believe it to be more useful for xen-devel t=
han xen-users.

This is indeed more appropriate for xen-devel.  Documentation is
certainly something we are poor at.  The monthly documentation days are
helping to counter this, but it is slow going.

>    QEMU
> Because as a VGA Passthrough user I'm currently forced to use qemu-xen-tr=
aditional (Through I hear some success about some users using qemu-xen in X=
en 4.4, but I myself didn't had any luck with it), I'm stuck with an old QE=
MU version. However, looking at changelog from latest versions I always see=
 some interesing features, which as far that I know Xen doesn't currently i=
ncorporate.
>
>
> 1a - One of the things that newer QEMU versions seems to be capable of do=
ing, is emulating the much newer Intel Q35 Chipset, instead of only the cur=
rent 440FX from the P5 Pentium era. Some data from Q35 emulation here:
> www.linux-kvm.org/wiki/images/0/06/2012-forum-Q35.pdf
> wiki.qemu.org/Features/Q35
>
> I'm aware that newer doesn't neccesarily means better, specially because =
the practical advantages of Q35 vs 440FX aren't very clear. There are sever=
al new emulated features like an AHCI Controller and a PCIe Bus, which soun=
ds interesing on paper, but I don't know if they add any useful feature or =
increases performance/compatibility. Some comments I read about the matter =
wrongly stated that Q35 would be needed to do PCIe Passthrough, but this is=
 currently possible on 440FX, through I don't know about the low level impl=
ementation differences. I think most of the idea about Q35 is to make the V=
M look more closely to real Hardware, instead of looking like a ridiculous =
obvious emulated platform.
> In the case of the AHCI Controller, I suppose than the OS would need to i=
nclude Drivers for the controller during installation time, which if I reca=
ll correctly both Windows Vista/7/8 and Linux should have, through for a Wi=
ndows XP install the Q35 AHCI Controller Drivers should probabily need to b=
e slipstreamed with nLite to an install ISO for it to work.

Qemu traditional with PCI passthrough of a PCIe device makes a PCI
topology which couldn't possibly work electrically speaking.  It ends up
with a PCIe device on a PCI bus with other PCI devices.  It works well
enough because operating systems have to cope with completely bogus
firmware information.

Q35 is certainly newer, and offers a different set of devices which will
be far more commonly found in more modern systems.  Whether this
constitutes "better" is purely subjective.

> A curious thing is that if I check /sys/kernel/iommu_groups/ as stated on=
 the blog I find the folder empty (This is on Dom0, with a DomU with 2 pass=
throughed devices). I suppose it may be VFIO exclusive or something. Point =
is, after some googling I couldn't find a way to check for IOMMU groups, th=
rough Xen doesn't seem to manage that anyways. I think that it may be usefu=
l to get a layout of IOMMU groups to at least identify if passthrough issue=
s could be related to that. Anyone can imagine current scenarios where this=
 may break something or limit possible passthrough, why I have my IOMMU gro=
ups listing empty, and how to get such list?

Xen has no concept of iommu_groups, and the dom0 kernel doesn't have
blanket permissions to poke around in the system topology, which is
probably why the dom0 kernel doesn't list any.  (In particular, dom0
can't see the ACPI DMAR table as Xen hides it from dom0.)  Try booting
your dom0 kernel as native and seeing whether the groups become populated.

Having read up on iommu_groups, they are a concept Xen should gain, and
"passing through a device" would turn into "passing through an
iommu_group".  Currently, the toolstack (and by implication, admin) can
set up anything it want, even when it doesn't make sense in the
slightest, and the results are a subtly or completely broken device. =

There are also several errata which would cause lots of PCIe devices to
consolidate into the same iommu_group.

IOMMU groups certainly wouldn't fix all passthrough issues, but it would
remove one avenue of being able to set up a known-invalid configurations.

> 1b - Another experimental feature that recently popped in QEMU is IOMMU e=
mulation. Info here:
> www.mulix.org/pubs/iommu/viommu.pdf
> www.linux-kvm.org/wiki/images/4/4a/2010-forum-joro-pv-iommu.pdf
>
> IOMMU emulation usefulness seems to be so you can do PCI Passthrough in a=
 Nested Virtualization enviroment. At first sight this looked a bit useless=
, cause using a DomU to do PCI Passthrough with an emulated IOMMU sounds ra=
ther too much overhead if you can simply emulate that device in the nested =
DomU. However, I also read about the possibility of Xen using Hardware virt=
ualization for Dom0 instead of it being Paravirtualized. In that case, woul=
d it be possible to provide the IOMMU emulation layer to Dom0 so you could =
do PCI Passthrough in platforms without proper support for it? It seems a r=
ather interesing idea.
> I think it would also be useful to serve as an standarized debug platform=
 for IOMMU virtualization and passthrough, cause some years ago missing or =
malformed ACPI DMAR/IVRS tables were all over the place and getting IOMMU v=
irtualization working was pretty much random luck and at the mercy of the g=
oodwill of the Motherboard maker to fix their BIOSes.

IOMMU emulation without IOMMU hardware can only possibly work in
combination with completely emulated devices.

IOMMU emulation in combination with IOMMU hardware could be made to work
if Xen changes its current model of only having a single IOMMU root per
domain.

The IOMMU architecture is basically just some sets of pagetables, and
each device gets a "cr3".  Currently, Xen has one single set of
pagetables for each domain needing the IOMMU, and every device assigned
to that domain gets the same set of tables.  It is perfectly possible to
have each device assigned to a domain using a different set of tables,
for intra-vm isolation, or nested pci passthrough, but this would
require a change in Xens interface (and a reasonably large quantity of
tuits)

>    UEFI for DomUs
> I managed to get this one working, but it seems to need some clarificatio=
ns here and there.
>
> 2a - As far that I know, if you add --enable-ovmf to ./configure before b=
uilding Xen, it downloads and builds some extra code from a OVMF repository=
 which Xen maintains, through I don't know if its a snapshop of whatever th=
e edk2 repository had at that time, or if it does includes custom patchs fo=
r the OVMF Firmware to work in Xen. Xen also has another ./configure option=
, --with-system-ovmf, which is supposed to be used to specify a path to pro=
vide an OVMF Firmware binary. However, when I tried that option some months=
 ago, I never managed to get it working, either using a package with a prec=
ompiled ovmf.bin from Arch Linux User Repository, or using another package =
with the source to compile it myself. Both binaries worked with standalone =
QEMU, through.
> Besides than that parameter itself was quite hidden, there is absolutely =
no info regarding if the provided OVMF binary has to comply with some speci=
al requeriments, be it some custom patchs for OVMF so it works with Xen, if=
 it has to be a binary that only includes TianoCore, or the unified one tha=
t includes the NVRAM in a single file. In Arch Linux, for the Xen 4.4 packa=
ge, the maintainer decided that the way to go for including OVMF support to=
 Xen was to use --enable-ovmf, cause at least it was possible to get it wor=
king with some available patches. However, for both download and build time=
s, it would be better to simply distribute a working binary. Any ideas of w=
hy --with-system-ovmf didn't worked for us?
>
>
> 2b - On successful Xen builds with OVMF support, something which I looked=
 for is the actual ovmf.bin file. So far, the only thing which I noticed is=
 that the hvmloader is 2 MiB bigger that on non-OVMF builds. Is there any r=
eason why OVMF is build into the hvmloader instead of what happens to the o=
ther Firmware binaries, which are usually sitting in a directory as standal=
one files?

(answering 2a and 2b together)

ovmf is currently unconditionally compiled into hvmloader, which is why
it gets 2MB bigger.  I believe --with-system-ovmf=3D (and
-with-system-seabios for that matter) needs the system ovmf available in
the build environment to be linked into hvmloader.

For a separate project, I have a usecase for hvmloader itself being a
multiboot image.  This would allow the use of multiboot modules, which
would be far more flexible than compiling all the binaries into
hvmloader itself.  In particular, when a system qemu updates its system
seabios/ovmf, hvmloader could use the updated bioses rather than the
linked bioses.

> 2c - Something which I'm aware is that an OVMF binary can be in two forma=
ts: A unified binary that has both OVMF and NVRAM, or a OVMF binary with a =
separate NVRAM (1.87 MiB + 128 KiB respectively). According to what I read =
about using OVMF with QEMU, it seems that if using a unified binary, you ne=
ed one per VM, cause the NVRAM content is different. I suppose than with th=
e second option you have one OVMF Firmware binary and a 128 KB NVRAM per UE=
FI VM. How does Xen handles this? If I recall correctly, I heared than it i=
s currently volatile (NVRAM contents aren't saved on DomU shutdown).

Currently nothing is saved.  With mutliboot modules and in particular,
separate multiboot modules for the main OVMF binary and a small nvram,
it would be possible to specify "nvram =3D /path/to/nvram.bin" in your
vm.cfg and gain proper nvram which persists across reboot.

> 2d - Is there any recorded experience or info regarding how a UEFI DomU w=
ould behave with something like, say, Windows 8 with Fast Boot, or other UE=
FI features for native systems? This is pretty much a "what if..." scenario=
 than something that I could really use.

I believe Anthony has managed to get this working with a Xenified OVMF?

>    PCI/VGA Passthrough
> It was four years ago when I learned about IOMMU virtualization making po=
ssible gaming in a VM via VGA Passthrough (First time I heared about that w=
as with some of Teo En Ming videos on Youtube), something which was quite e=
xperimental back at that time. Even currently, the only other Hypervisor or=
 VMM that can compete with Xen in this area is QEMU with KVM VFIO, which al=
so has decent VGA Passthrough capabilities. While I'm aware that Xen is pre=
tty much enterprise oriented, it was also the first to allow a power user t=
o make a system based on Xen as Hypervisor and everything else virtualized,=
 getting nearly all the functionality of running native with the flexibilit=
y than virtualization offers, at the cost of some overhead, quircks and com=
plexity on usage. Its a pain to configure it the first time, but if you man=
age to get it working, its wonderful. So far, this feature has created a sm=
all niche of power users that uses either Xen or QEMU KVM VFIO for virtuali=
zed gaming, and I consider VGA Passthrough a quite major feature because it=
 is what allows such setups on the first place.

I wouldn=92t necessarily say that Xen is specifically enterprise
orientated.  However, Xen is certainly harder to set up and use than
alternatives, which does raise the bar to start using it.

>
>
> 3a - On some of the Threads of the original guides I read about how to us=
e Xen to do VGA Passthrough, you usually see the author and others users sa=
ying that they didn't manage to get VGA Passthrough working on newer versio=
ns. This usually affected people that was doing the migration from the xm t=
o xl toolstack, but also between some Xen versions (I reported a regression=
 on Xen 4.4 vs a fully working 4.3). Passthrough compatibility previously u=
sed to be a Hardware-related pain cause it was extremely Motherboard and BI=
OS dependant on an era where consumer Motherboards makers didn't paid atten=
tion to the IOMMU, but at least on the Intel Haswell platform support for I=
OMMU is starting to get more mainstream.
> Considering than PCI/VGA Passthrough compatibility with a system or regre=
ssions of it between Xen versions is pretty much a hit-or-miss, would it be=
 possible to do something to get this feature under control? It seems like =
this isn't deeply tested, or at least not with too many variables involved =
(Hard to do, cause they're A LOT). I believe that it should be possible to =
have a few systems at hand which are know to work and representative of a H=
ardware platform tested against regression with different Video Cards, but =
it sounds extremely time consuming to switch cards, reboot, test with diffe=
rent DomUs OSes/Drivers, etc. At the moment, once you get a Computer/Distri=
bution/Kernel/Xen/Toolstack/DomU OS/Drivers combination that works, you sim=
ply stick to it, so many early adopters of VGA Passthrough are still using =
extremely outdated versions. Even worse, for users of versions like 4.2 wit=
h xm, if they want to upgrade to 4.4 with xl and want to figure out why it =
doesn't work, it will be a royal pain in the butt to figure out what patch =
was introduced that breaks compatibility for them, so those early adopters =
are pretty much out of luck if they have to go through years worth of code =
and version testing.

PCI Passthrough is in an awkward position.  I am not aware of any
dedicates testing that the stable/master branches get, and it is
surprisingly difficult to automate.  It would certainly be nice for
passthrough to get some form of dedicated testing, but currently the
best we have is users like yourself complaining when it breaks.  This is
certainly a situation which needs improving.

In XenServer, we support passthrough in a very restricted set of
circumstances, because there are simply too many system quirks (that we
know about, let alone those we don't) for us to be comfortable
supporting it in general.  Furthermore, our testing only covers the
version of Xen we are using in trunk, which is generally the latest stable.

>
>
> 3b - Do someone knows what is the actual difference on Intel platforms re=
garding VT-d support? As far that I know, the VT-d specification allows for=
 multiple "DMA Remapping Engines", of which a Haswell Processor has two, on=
e for its Integrated PCIe Controller and another for the Integrated GPU. Yo=
u also have Chipsets, some of which according to Intel Ark support VT-d (Wh=
ich I believe should be in the form of a third DMA Remapping Engine), like =
the Q87 and C226, and those that don't like the H87 and Z87. Based on worki=
ng samples I have been lead to believe than a Processor supporting VT-d wil=
l provide the IOMMU capabilities for the devices connected to its own PCIe =
Slots regardless of what Chipset you're using (That's the reason why you ca=
n do Passthrough with only Processor VT-d support), I would believe the sam=
e holds true with a VT-d Chipset with a non VT-d Processor, through I didn'=
t saw any working example of this.
> When I was researching about this one year ago, Supermicro support said t=
his to me:
>
> Since Z87 chipset does not support VT-d,  onboard LAN will not support it=
 either because it is connected to PCH PCIe port.  One workaround is to use=
 a VT-d enabled PCIe device and plug it into CPU based PCIe-port on board. =
 Along with a VT-d enabled CPU the above workaround should work per Intel.
>
> Based on this, there should be a not-very-well-documented quirck. The mos=
t common configuration for VGA Passthrough users is a VT-d supporting Proce=
ssor with a consumer Motherboard, so basically, if you have a VT-d supporti=
ng Processor like a Core i7 4790K, you can do Passthrough of the devices co=
nnected to the Processor PCIe Slots, and also of the ones connected to the =
Chipset if you apply that workaround (I don't know what does "VT-d enabled =
PCIe device" means exactly). I recall seeing some people using VMWare ESXi =
commenting that they couldn't passthrough the integrated NIC even through s=
ome a RAID Controller connected to the Processor could in such setups. Don'=
t have link at hand about the matter, but I believe that reelevant for the =
question.
> Considering that if workarounded you would be using the Processor DMA Rem=
apping Engine for Chipset devices, is there any potential bottleneck or per=
formance degradation there?

The only reasonable interpretation that stands a chance of working is a
PCIe device with an IOMMU on it, but I am not aware of any such device,
or whether it would actually work.

It is certainly possible to have more than one IOMMU.  Servers typically
have one per socket and one for the chipset.  This doesn't necessarily
mean that all devices are covered by IOMMUs.

>
>
> 3c - There is a feature that enhances VT-d called ACS (Access Control Ser=
vice), related to IOMMU groups isolation. This feature seems to be excluded=
 from consumer platforms, and support for it seems to already be on Xen wis=
hlist based on comments. Info here:
> vfio.blogspot.com.ar/2014/08/iommu-groups-inside-and-out.html
> comments.gmane.org/gmane.comp.emulators.xen.devel/212561

ACS is required to fix issues caused by optimisation permitted under the
PCIe spec, which are invalid in combination with IOMMU.  The main one is
peer-to-peer DMA which permits a switch to complete peer-to-peer traffic
without forwarding it upstream.  This is wrong between two devices with
different IOMMU mappings, and ACS provides an override to say "forward
everything upstream - the IOMMU will make it go in different directions".

Presence or lack of ACS certainly does affect whether devices behind a
PCIe switch can safely be isolated into different IOMMU contexts.

>
>
> 3d - The new SATA Express and M.2 connectors combines SATA and some PCI E=
xpress lanes on the same connector. Depending on implementation, the PCI Ex=
press lanes could come from either the Chipset or the Processor. Considerin=
g than some people likes to passthrough the entire SATA Controller, how doe=
s it interacts with this frankenstein connector with the PCIe lanes coming =
from elsewhere? I'm curious.

No idea, but I suspect it would appear as a different device, separate
to the SATA controller.

>
>
>    Miscelaneous Virtualization stuff
>
>
> 4a - There are several instances where the Software is trying to check if=
 it is under a virtualized enviroment or not. Examples which I recall havin=
g read about are some malware, which tries to hide if it detects that it is=
 running virtualized (Cause it means that it is not your exploitable Averag=
e Joe computer), or according some comments I read, some Drivers like those=
 of NVIDIA to force you to use a Quadro for VGA Passthrough instead of a co=
nsumer based GeForce. Is the goal of virtualization to reproduce the exact =
behaviator in a VM of a system running native, or just be functionally equi=
valent? This is because as more Software appears that makes a distinction b=
etween native and a VM, it seems that in the end it will be forcing VMs to =
look and behave like a native system to maintain compatibility. While curre=
ntly such Software is pretty much a specific niche, it exist the possibilit=
y than it becomes a trend with the growing popularity of the cloud.
> For example, one of the things that pretty much tells the whole history, =
is the 440FX Chipset, because if you see that Chipset running anything but =
a P5 Pentium, you know you're running either emulated or virtualized. Also,=
 if I use an application like CPU-Z, it says than the BIOS Brand is Xen, Ve=
rsion 4.3.3, which makes the status of the system as inside a VM also obvio=
us. I think that based on the rare but existant Software pieces that attemp=
ts to check if its running on a VM or not to decide behavior, at some point=
 in time a part of the virtualization segment will be playing a catching up=
 game to mask being a VM from these types of applications. I suppose that a=
 possible endgame for this topic would be where you have a VM that tries to=
 represent accurately as possible the PCI Layout of a commercial Chipset (W=
hich I believe was one of the aims of QEMU Q35 emulation), and deliberately=
 lying and/or masking the Processor CPUID data, BIOS vendor, and other reco=
gnizable things, to try to match what you would expect from a native system=
 of that Hardware generation.
> This point could be questionable, cause making a perfect VM that is indis=
tinguishable from a native system could harm some vendors that may rely on =
identifying if its running on a VM or not for enforcing licensing and the l=
ike.

I would go so far as to say that the majority of people using
virtualisation want something which works (for varying definitions of
'works'), and is as fast as possible.  Making an HVM guest
indistinguishable from a real computer is a very difficult task, and one
which I don't believe is practical to achieve.  An OS which is really
trying to identify a virtualised environment can even make a guess by
timing certain operations which would vmexit for emulation purposes.

>
>
> 4b - The only feature which I feel that Xen is missing from a home user p=
erspective, is sound. As far that I know you can currently tell QEMU to emu=
late a Sound Card in a DomU, but there is no way to easily get the sound ou=
t of a DomU like other VMMs do. Some of the solutions I saw relied on eithe=
r multiple passthroughed Sound Cards, or a PulseAudio Server adding massive=
 sound latency. While Xen is enterprise oriented where sound is unneeded, I=
 recall hearing that this feature was getting considered, but didn't see an=
y mention about it for months. How hard or complex it would be to add sound=
 support to Xen? Is the way to do it decided? Could it take the form of usi=
ng Dom0 Drivers for the Sound Card to act as a mixer and some PV Drivers fo=
r the DomU like the ones currently available for the NIC and storage?
>

Sorry, I don't have any useful input here, other than "that would be nice".

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 13:46:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 13:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxydt-0000ej-VZ; Mon, 08 Dec 2014 13:46:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xxyds-0000ee-HT
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 13:46:24 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	F1/DD-05632-FABA5845; Mon, 08 Dec 2014 13:46:23 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418046381!7375411!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 693 invoked from network); 8 Dec 2014 13:46:22 -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;
	8 Dec 2014 13:46:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201786579"
Message-ID: <5485ABAA.8050803@citrix.com>
Date: Mon, 8 Dec 2014 13:46:18 +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: Zir Blazer <zir_blazer@hotmail.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
References: <SNT151-W418A2CEE673F81B3E75E99F3660@phx.gbl>
In-Reply-To: <SNT151-W418A2CEE673F81B3E75E99F3660@phx.gbl>
X-DLP: MIA2
Subject: Re: [Xen-devel] Some questions regarding QEMU, UEFI,
 PCI/VGA Passthrough, and other things
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 06/12/14 00:45, Zir Blazer wrote:

Replying somewhat out of order:

> I hope someone finds my questions interesing to answer.

It is certainly an interesting read - I will answer what I can.

> While I am not a developer myself (I always sucked hard when it comes to =
read and write code), there are several capabilities of Xen and its support=
ing Software which I'm always interesed in how they progress, more out of c=
uriosity than anything else. However, usually, documentation seems to backt=
rack a lot what its currently implemented in code, and sometimes you catch =
a mail here with some useful data regarding a topic but later you don't hea=
r about that any more, missing any progress, or because the whole topic was=
 inconclusive. So, this mail is pretty much a compilation of small question=
s of things I came across but didn't popped up later, but can serve to brai=
nstorm someone, which is why I believe it to be more useful for xen-devel t=
han xen-users.

This is indeed more appropriate for xen-devel.  Documentation is
certainly something we are poor at.  The monthly documentation days are
helping to counter this, but it is slow going.

>    QEMU
> Because as a VGA Passthrough user I'm currently forced to use qemu-xen-tr=
aditional (Through I hear some success about some users using qemu-xen in X=
en 4.4, but I myself didn't had any luck with it), I'm stuck with an old QE=
MU version. However, looking at changelog from latest versions I always see=
 some interesing features, which as far that I know Xen doesn't currently i=
ncorporate.
>
>
> 1a - One of the things that newer QEMU versions seems to be capable of do=
ing, is emulating the much newer Intel Q35 Chipset, instead of only the cur=
rent 440FX from the P5 Pentium era. Some data from Q35 emulation here:
> www.linux-kvm.org/wiki/images/0/06/2012-forum-Q35.pdf
> wiki.qemu.org/Features/Q35
>
> I'm aware that newer doesn't neccesarily means better, specially because =
the practical advantages of Q35 vs 440FX aren't very clear. There are sever=
al new emulated features like an AHCI Controller and a PCIe Bus, which soun=
ds interesing on paper, but I don't know if they add any useful feature or =
increases performance/compatibility. Some comments I read about the matter =
wrongly stated that Q35 would be needed to do PCIe Passthrough, but this is=
 currently possible on 440FX, through I don't know about the low level impl=
ementation differences. I think most of the idea about Q35 is to make the V=
M look more closely to real Hardware, instead of looking like a ridiculous =
obvious emulated platform.
> In the case of the AHCI Controller, I suppose than the OS would need to i=
nclude Drivers for the controller during installation time, which if I reca=
ll correctly both Windows Vista/7/8 and Linux should have, through for a Wi=
ndows XP install the Q35 AHCI Controller Drivers should probabily need to b=
e slipstreamed with nLite to an install ISO for it to work.

Qemu traditional with PCI passthrough of a PCIe device makes a PCI
topology which couldn't possibly work electrically speaking.  It ends up
with a PCIe device on a PCI bus with other PCI devices.  It works well
enough because operating systems have to cope with completely bogus
firmware information.

Q35 is certainly newer, and offers a different set of devices which will
be far more commonly found in more modern systems.  Whether this
constitutes "better" is purely subjective.

> A curious thing is that if I check /sys/kernel/iommu_groups/ as stated on=
 the blog I find the folder empty (This is on Dom0, with a DomU with 2 pass=
throughed devices). I suppose it may be VFIO exclusive or something. Point =
is, after some googling I couldn't find a way to check for IOMMU groups, th=
rough Xen doesn't seem to manage that anyways. I think that it may be usefu=
l to get a layout of IOMMU groups to at least identify if passthrough issue=
s could be related to that. Anyone can imagine current scenarios where this=
 may break something or limit possible passthrough, why I have my IOMMU gro=
ups listing empty, and how to get such list?

Xen has no concept of iommu_groups, and the dom0 kernel doesn't have
blanket permissions to poke around in the system topology, which is
probably why the dom0 kernel doesn't list any.  (In particular, dom0
can't see the ACPI DMAR table as Xen hides it from dom0.)  Try booting
your dom0 kernel as native and seeing whether the groups become populated.

Having read up on iommu_groups, they are a concept Xen should gain, and
"passing through a device" would turn into "passing through an
iommu_group".  Currently, the toolstack (and by implication, admin) can
set up anything it want, even when it doesn't make sense in the
slightest, and the results are a subtly or completely broken device. =

There are also several errata which would cause lots of PCIe devices to
consolidate into the same iommu_group.

IOMMU groups certainly wouldn't fix all passthrough issues, but it would
remove one avenue of being able to set up a known-invalid configurations.

> 1b - Another experimental feature that recently popped in QEMU is IOMMU e=
mulation. Info here:
> www.mulix.org/pubs/iommu/viommu.pdf
> www.linux-kvm.org/wiki/images/4/4a/2010-forum-joro-pv-iommu.pdf
>
> IOMMU emulation usefulness seems to be so you can do PCI Passthrough in a=
 Nested Virtualization enviroment. At first sight this looked a bit useless=
, cause using a DomU to do PCI Passthrough with an emulated IOMMU sounds ra=
ther too much overhead if you can simply emulate that device in the nested =
DomU. However, I also read about the possibility of Xen using Hardware virt=
ualization for Dom0 instead of it being Paravirtualized. In that case, woul=
d it be possible to provide the IOMMU emulation layer to Dom0 so you could =
do PCI Passthrough in platforms without proper support for it? It seems a r=
ather interesing idea.
> I think it would also be useful to serve as an standarized debug platform=
 for IOMMU virtualization and passthrough, cause some years ago missing or =
malformed ACPI DMAR/IVRS tables were all over the place and getting IOMMU v=
irtualization working was pretty much random luck and at the mercy of the g=
oodwill of the Motherboard maker to fix their BIOSes.

IOMMU emulation without IOMMU hardware can only possibly work in
combination with completely emulated devices.

IOMMU emulation in combination with IOMMU hardware could be made to work
if Xen changes its current model of only having a single IOMMU root per
domain.

The IOMMU architecture is basically just some sets of pagetables, and
each device gets a "cr3".  Currently, Xen has one single set of
pagetables for each domain needing the IOMMU, and every device assigned
to that domain gets the same set of tables.  It is perfectly possible to
have each device assigned to a domain using a different set of tables,
for intra-vm isolation, or nested pci passthrough, but this would
require a change in Xens interface (and a reasonably large quantity of
tuits)

>    UEFI for DomUs
> I managed to get this one working, but it seems to need some clarificatio=
ns here and there.
>
> 2a - As far that I know, if you add --enable-ovmf to ./configure before b=
uilding Xen, it downloads and builds some extra code from a OVMF repository=
 which Xen maintains, through I don't know if its a snapshop of whatever th=
e edk2 repository had at that time, or if it does includes custom patchs fo=
r the OVMF Firmware to work in Xen. Xen also has another ./configure option=
, --with-system-ovmf, which is supposed to be used to specify a path to pro=
vide an OVMF Firmware binary. However, when I tried that option some months=
 ago, I never managed to get it working, either using a package with a prec=
ompiled ovmf.bin from Arch Linux User Repository, or using another package =
with the source to compile it myself. Both binaries worked with standalone =
QEMU, through.
> Besides than that parameter itself was quite hidden, there is absolutely =
no info regarding if the provided OVMF binary has to comply with some speci=
al requeriments, be it some custom patchs for OVMF so it works with Xen, if=
 it has to be a binary that only includes TianoCore, or the unified one tha=
t includes the NVRAM in a single file. In Arch Linux, for the Xen 4.4 packa=
ge, the maintainer decided that the way to go for including OVMF support to=
 Xen was to use --enable-ovmf, cause at least it was possible to get it wor=
king with some available patches. However, for both download and build time=
s, it would be better to simply distribute a working binary. Any ideas of w=
hy --with-system-ovmf didn't worked for us?
>
>
> 2b - On successful Xen builds with OVMF support, something which I looked=
 for is the actual ovmf.bin file. So far, the only thing which I noticed is=
 that the hvmloader is 2 MiB bigger that on non-OVMF builds. Is there any r=
eason why OVMF is build into the hvmloader instead of what happens to the o=
ther Firmware binaries, which are usually sitting in a directory as standal=
one files?

(answering 2a and 2b together)

ovmf is currently unconditionally compiled into hvmloader, which is why
it gets 2MB bigger.  I believe --with-system-ovmf=3D (and
-with-system-seabios for that matter) needs the system ovmf available in
the build environment to be linked into hvmloader.

For a separate project, I have a usecase for hvmloader itself being a
multiboot image.  This would allow the use of multiboot modules, which
would be far more flexible than compiling all the binaries into
hvmloader itself.  In particular, when a system qemu updates its system
seabios/ovmf, hvmloader could use the updated bioses rather than the
linked bioses.

> 2c - Something which I'm aware is that an OVMF binary can be in two forma=
ts: A unified binary that has both OVMF and NVRAM, or a OVMF binary with a =
separate NVRAM (1.87 MiB + 128 KiB respectively). According to what I read =
about using OVMF with QEMU, it seems that if using a unified binary, you ne=
ed one per VM, cause the NVRAM content is different. I suppose than with th=
e second option you have one OVMF Firmware binary and a 128 KB NVRAM per UE=
FI VM. How does Xen handles this? If I recall correctly, I heared than it i=
s currently volatile (NVRAM contents aren't saved on DomU shutdown).

Currently nothing is saved.  With mutliboot modules and in particular,
separate multiboot modules for the main OVMF binary and a small nvram,
it would be possible to specify "nvram =3D /path/to/nvram.bin" in your
vm.cfg and gain proper nvram which persists across reboot.

> 2d - Is there any recorded experience or info regarding how a UEFI DomU w=
ould behave with something like, say, Windows 8 with Fast Boot, or other UE=
FI features for native systems? This is pretty much a "what if..." scenario=
 than something that I could really use.

I believe Anthony has managed to get this working with a Xenified OVMF?

>    PCI/VGA Passthrough
> It was four years ago when I learned about IOMMU virtualization making po=
ssible gaming in a VM via VGA Passthrough (First time I heared about that w=
as with some of Teo En Ming videos on Youtube), something which was quite e=
xperimental back at that time. Even currently, the only other Hypervisor or=
 VMM that can compete with Xen in this area is QEMU with KVM VFIO, which al=
so has decent VGA Passthrough capabilities. While I'm aware that Xen is pre=
tty much enterprise oriented, it was also the first to allow a power user t=
o make a system based on Xen as Hypervisor and everything else virtualized,=
 getting nearly all the functionality of running native with the flexibilit=
y than virtualization offers, at the cost of some overhead, quircks and com=
plexity on usage. Its a pain to configure it the first time, but if you man=
age to get it working, its wonderful. So far, this feature has created a sm=
all niche of power users that uses either Xen or QEMU KVM VFIO for virtuali=
zed gaming, and I consider VGA Passthrough a quite major feature because it=
 is what allows such setups on the first place.

I wouldn=92t necessarily say that Xen is specifically enterprise
orientated.  However, Xen is certainly harder to set up and use than
alternatives, which does raise the bar to start using it.

>
>
> 3a - On some of the Threads of the original guides I read about how to us=
e Xen to do VGA Passthrough, you usually see the author and others users sa=
ying that they didn't manage to get VGA Passthrough working on newer versio=
ns. This usually affected people that was doing the migration from the xm t=
o xl toolstack, but also between some Xen versions (I reported a regression=
 on Xen 4.4 vs a fully working 4.3). Passthrough compatibility previously u=
sed to be a Hardware-related pain cause it was extremely Motherboard and BI=
OS dependant on an era where consumer Motherboards makers didn't paid atten=
tion to the IOMMU, but at least on the Intel Haswell platform support for I=
OMMU is starting to get more mainstream.
> Considering than PCI/VGA Passthrough compatibility with a system or regre=
ssions of it between Xen versions is pretty much a hit-or-miss, would it be=
 possible to do something to get this feature under control? It seems like =
this isn't deeply tested, or at least not with too many variables involved =
(Hard to do, cause they're A LOT). I believe that it should be possible to =
have a few systems at hand which are know to work and representative of a H=
ardware platform tested against regression with different Video Cards, but =
it sounds extremely time consuming to switch cards, reboot, test with diffe=
rent DomUs OSes/Drivers, etc. At the moment, once you get a Computer/Distri=
bution/Kernel/Xen/Toolstack/DomU OS/Drivers combination that works, you sim=
ply stick to it, so many early adopters of VGA Passthrough are still using =
extremely outdated versions. Even worse, for users of versions like 4.2 wit=
h xm, if they want to upgrade to 4.4 with xl and want to figure out why it =
doesn't work, it will be a royal pain in the butt to figure out what patch =
was introduced that breaks compatibility for them, so those early adopters =
are pretty much out of luck if they have to go through years worth of code =
and version testing.

PCI Passthrough is in an awkward position.  I am not aware of any
dedicates testing that the stable/master branches get, and it is
surprisingly difficult to automate.  It would certainly be nice for
passthrough to get some form of dedicated testing, but currently the
best we have is users like yourself complaining when it breaks.  This is
certainly a situation which needs improving.

In XenServer, we support passthrough in a very restricted set of
circumstances, because there are simply too many system quirks (that we
know about, let alone those we don't) for us to be comfortable
supporting it in general.  Furthermore, our testing only covers the
version of Xen we are using in trunk, which is generally the latest stable.

>
>
> 3b - Do someone knows what is the actual difference on Intel platforms re=
garding VT-d support? As far that I know, the VT-d specification allows for=
 multiple "DMA Remapping Engines", of which a Haswell Processor has two, on=
e for its Integrated PCIe Controller and another for the Integrated GPU. Yo=
u also have Chipsets, some of which according to Intel Ark support VT-d (Wh=
ich I believe should be in the form of a third DMA Remapping Engine), like =
the Q87 and C226, and those that don't like the H87 and Z87. Based on worki=
ng samples I have been lead to believe than a Processor supporting VT-d wil=
l provide the IOMMU capabilities for the devices connected to its own PCIe =
Slots regardless of what Chipset you're using (That's the reason why you ca=
n do Passthrough with only Processor VT-d support), I would believe the sam=
e holds true with a VT-d Chipset with a non VT-d Processor, through I didn'=
t saw any working example of this.
> When I was researching about this one year ago, Supermicro support said t=
his to me:
>
> Since Z87 chipset does not support VT-d,  onboard LAN will not support it=
 either because it is connected to PCH PCIe port.  One workaround is to use=
 a VT-d enabled PCIe device and plug it into CPU based PCIe-port on board. =
 Along with a VT-d enabled CPU the above workaround should work per Intel.
>
> Based on this, there should be a not-very-well-documented quirck. The mos=
t common configuration for VGA Passthrough users is a VT-d supporting Proce=
ssor with a consumer Motherboard, so basically, if you have a VT-d supporti=
ng Processor like a Core i7 4790K, you can do Passthrough of the devices co=
nnected to the Processor PCIe Slots, and also of the ones connected to the =
Chipset if you apply that workaround (I don't know what does "VT-d enabled =
PCIe device" means exactly). I recall seeing some people using VMWare ESXi =
commenting that they couldn't passthrough the integrated NIC even through s=
ome a RAID Controller connected to the Processor could in such setups. Don'=
t have link at hand about the matter, but I believe that reelevant for the =
question.
> Considering that if workarounded you would be using the Processor DMA Rem=
apping Engine for Chipset devices, is there any potential bottleneck or per=
formance degradation there?

The only reasonable interpretation that stands a chance of working is a
PCIe device with an IOMMU on it, but I am not aware of any such device,
or whether it would actually work.

It is certainly possible to have more than one IOMMU.  Servers typically
have one per socket and one for the chipset.  This doesn't necessarily
mean that all devices are covered by IOMMUs.

>
>
> 3c - There is a feature that enhances VT-d called ACS (Access Control Ser=
vice), related to IOMMU groups isolation. This feature seems to be excluded=
 from consumer platforms, and support for it seems to already be on Xen wis=
hlist based on comments. Info here:
> vfio.blogspot.com.ar/2014/08/iommu-groups-inside-and-out.html
> comments.gmane.org/gmane.comp.emulators.xen.devel/212561

ACS is required to fix issues caused by optimisation permitted under the
PCIe spec, which are invalid in combination with IOMMU.  The main one is
peer-to-peer DMA which permits a switch to complete peer-to-peer traffic
without forwarding it upstream.  This is wrong between two devices with
different IOMMU mappings, and ACS provides an override to say "forward
everything upstream - the IOMMU will make it go in different directions".

Presence or lack of ACS certainly does affect whether devices behind a
PCIe switch can safely be isolated into different IOMMU contexts.

>
>
> 3d - The new SATA Express and M.2 connectors combines SATA and some PCI E=
xpress lanes on the same connector. Depending on implementation, the PCI Ex=
press lanes could come from either the Chipset or the Processor. Considerin=
g than some people likes to passthrough the entire SATA Controller, how doe=
s it interacts with this frankenstein connector with the PCIe lanes coming =
from elsewhere? I'm curious.

No idea, but I suspect it would appear as a different device, separate
to the SATA controller.

>
>
>    Miscelaneous Virtualization stuff
>
>
> 4a - There are several instances where the Software is trying to check if=
 it is under a virtualized enviroment or not. Examples which I recall havin=
g read about are some malware, which tries to hide if it detects that it is=
 running virtualized (Cause it means that it is not your exploitable Averag=
e Joe computer), or according some comments I read, some Drivers like those=
 of NVIDIA to force you to use a Quadro for VGA Passthrough instead of a co=
nsumer based GeForce. Is the goal of virtualization to reproduce the exact =
behaviator in a VM of a system running native, or just be functionally equi=
valent? This is because as more Software appears that makes a distinction b=
etween native and a VM, it seems that in the end it will be forcing VMs to =
look and behave like a native system to maintain compatibility. While curre=
ntly such Software is pretty much a specific niche, it exist the possibilit=
y than it becomes a trend with the growing popularity of the cloud.
> For example, one of the things that pretty much tells the whole history, =
is the 440FX Chipset, because if you see that Chipset running anything but =
a P5 Pentium, you know you're running either emulated or virtualized. Also,=
 if I use an application like CPU-Z, it says than the BIOS Brand is Xen, Ve=
rsion 4.3.3, which makes the status of the system as inside a VM also obvio=
us. I think that based on the rare but existant Software pieces that attemp=
ts to check if its running on a VM or not to decide behavior, at some point=
 in time a part of the virtualization segment will be playing a catching up=
 game to mask being a VM from these types of applications. I suppose that a=
 possible endgame for this topic would be where you have a VM that tries to=
 represent accurately as possible the PCI Layout of a commercial Chipset (W=
hich I believe was one of the aims of QEMU Q35 emulation), and deliberately=
 lying and/or masking the Processor CPUID data, BIOS vendor, and other reco=
gnizable things, to try to match what you would expect from a native system=
 of that Hardware generation.
> This point could be questionable, cause making a perfect VM that is indis=
tinguishable from a native system could harm some vendors that may rely on =
identifying if its running on a VM or not for enforcing licensing and the l=
ike.

I would go so far as to say that the majority of people using
virtualisation want something which works (for varying definitions of
'works'), and is as fast as possible.  Making an HVM guest
indistinguishable from a real computer is a very difficult task, and one
which I don't believe is practical to achieve.  An OS which is really
trying to identify a virtualised environment can even make a guess by
timing certain operations which would vmexit for emulation purposes.

>
>
> 4b - The only feature which I feel that Xen is missing from a home user p=
erspective, is sound. As far that I know you can currently tell QEMU to emu=
late a Sound Card in a DomU, but there is no way to easily get the sound ou=
t of a DomU like other VMMs do. Some of the solutions I saw relied on eithe=
r multiple passthroughed Sound Cards, or a PulseAudio Server adding massive=
 sound latency. While Xen is enterprise oriented where sound is unneeded, I=
 recall hearing that this feature was getting considered, but didn't see an=
y mention about it for months. How hard or complex it would be to add sound=
 support to Xen? Is the way to do it decided? Could it take the form of usi=
ng Dom0 Drivers for the Sound Card to act as a mixer and some PV Drivers fo=
r the DomU like the ones currently available for the NIC and storage?
>

Sorry, I don't have any useful input here, other than "that would be nice".

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 13:47:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 13:47:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxyej-0000ht-DG; Mon, 08 Dec 2014 13:47: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 1Xxyeh-0000hX-5t
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 13:47:15 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DA/E7-25276-2EBA5845; Mon, 08 Dec 2014 13:47:14 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418046433!10727472!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16031 invoked from network); 8 Dec 2014 13:47:14 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 13:47:14 -0000
Received: by mail-wg0-f50.google.com with SMTP id k14so6168625wgh.23
	for <xen-devel@lists.xen.org>; Mon, 08 Dec 2014 05:47: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=ltkgk6X0yrdJLZ+QMoxwxQL988fNx/RI6ATLPVfU69M=;
	b=dtXuUbNn2SG9O0kC+ckuaxf7RWhfE4hoj8MnqGBNyBNAbi5bB3VOda3hLjtVoammzU
	8qyo6G/lohjHax3mvBQCm0n9tcsvA9EB90DA6+3L0blmAcYrRW3tIzZ0b/Xbl+X8YSkp
	a20PmWvb+YRs4ekcyYKbhYv+lhALhDJNOYUUMcTDXSX5u5takIt0l2y0BqfW+V8kT94m
	NTl1DCo7cqa2JdjKoDhufegn4E4Y8S244xjCpxaB7ZtfVjUdVg0+KXySqJuxe1L/cRSi
	YWmrnpBfsPe85oBy8iI+8rMZSn+5m2bDb1hYp1ik5pQd4eKIIjH1brTQEy1s5I6kpDuW
	hrSQ==
X-Gm-Message-State: ALoCoQlUvn/pkvQi0gLOcpvjizXAMi9Xh1meJ5zmjVqxoU+G3yARpf0ZpwyxFqDb+rRXJGB+U3Tb
X-Received: by 10.180.74.236 with SMTP id x12mr24522296wiv.40.1418046433759;
	Mon, 08 Dec 2014 05:47:13 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	rx8sm56682777wjb.30.2014.12.08.05.47.12 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 08 Dec 2014 05:47:12 -0800 (PST)
Message-ID: <5485ABDD.10301@linaro.org>
Date: Mon, 08 Dec 2014 13:47:09 +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: vijay.kilari@gmail.com, Ian.Campbell@citrix.com, 
	stefano.stabellini@eu.citrix.com, stefano.stabellini@citrix.com, 
	tim@xen.org, xen-devel@lists.xen.org
References: <1417830124-3914-1-git-send-email-vijay.kilari@gmail.com>
In-Reply-To: <1417830124-3914-1-git-send-email-vijay.kilari@gmail.com>
Cc: Prasun.Kapoor@caviumnetworks.com, vijaya.kumar@caviumnetworks.com,
	manish.jaggi@caviumnetworks.com
Subject: Re: [Xen-devel] [RFC PATCH] xen/arm: Manage uart TX interrupt
	correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Vijay,

You are fixing the pl011 driver, not all the UART. So the commit title
should at least contain the word "pl011".

On 06/12/14 01:42, vijay.kilari@gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> 
> On pl011.c when TX interrupt is received and

Why do you give the filename rather than the UART?

> TX buffer is empty, TX interrupt is not disabled and
> hence UART interrupt routine see TX interrupt always
> in MIS register and cpu loops infinitly.

I'm sorry to say that, but this sentence is difficult to understand.

> With this patch, mask and umask TX interrupt

s/umask/unmask

> when required

You need to explain when it's required...

> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> ---
>  xen/drivers/char/pl011.c  |   18 ++++++++++++++++++
>  xen/drivers/char/serial.c |   30 +++++++++++++++++++++++++++++-
>  xen/include/xen/serial.h  |    4 ++++
>  3 files changed, 51 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
> index dd19ce8..ad48df3 100644
> --- a/xen/drivers/char/pl011.c
> +++ b/xen/drivers/char/pl011.c
> @@ -109,6 +109,8 @@ static void __init pl011_init_preirq(struct serial_port *port)
>              panic("pl011: No Baud rate configured\n");
>          uart->baud = (uart->clock_hz << 2) / divisor;
>      }
> +    /* Trigger RX interrupt at 1/2 full, TX interrupt at 7/8 empty */
> +    pl011_write(uart, IFLS, (2<<3 | 0));

The RX change seems to come from nowhere. You have to explain why you
need it in the commit message.

As you add start_tx/stop_tx, I don't think this has to be kept.

[..]

> diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
> index 44026b1..d2ce8a8 100644
> --- a/xen/drivers/char/serial.c
> +++ b/xen/drivers/char/serial.c
> @@ -76,6 +76,19 @@ void serial_tx_interrupt(struct serial_port *port, struct cpu_user_regs *regs)
>          cpu_relax();
>      }
>  
> +    if ( port->txbufc == port->txbufp )
> +    {
> +        /* Disable TX. nothing to send */
> +        if ( port->driver->stop_tx != NULL )
> +            port->driver->stop_tx(port);

Can you introduce helpers for both stop_tx and start_tx? It would avoid
to add if ( ... ) port->driver->...( ) every time.

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 Dec 08 13:47:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 13:47:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxyej-0000iE-UM; Mon, 08 Dec 2014 13:47: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 1Xxyei-0000he-6S
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 13:47:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	22/F7-25276-3EBA5845; Mon, 08 Dec 2014 13:47:15 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418046433!14138848!1
X-Originating-IP: [66.165.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 17864 invoked from network); 8 Dec 2014 13:47:14 -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;
	8 Dec 2014 13:47:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201389766"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 08:47: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 1Xxyee-0001eW-7l;
	Mon, 08 Dec 2014 13:47:12 +0000
Date: Mon, 8 Dec 2014 13:46:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1418034110.30016.1.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1412081346150.30971@kaball.uk.xensource.com>
References: <CAAiw7Jm+aH7n4qOZcJQ4Wc+ocEugvPq+RWYHemwhOLmcd5+EGw@mail.gmail.com>
	<1418034110.30016.1.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>,
	manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, xen-users@lists.xen.org,
	xen-devel <xen-devel@lists.xenproject.org>,
	manish jaggi <manishjaggi.oss@gmail.com>
Subject: Re: [Xen-devel] Steps to run XenServer on 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 Mon, 8 Dec 2014, Ian Campbell wrote:
> On Fri, 2014-12-05 at 15:15 -0800, manish jaggi wrote:
> > Hi,
> > 
> > I am trying to find a tutorial to jumpstart installing XenServer / XCP
> > on an ARM 64bit platform.
> > Could the mailing list help.
> 
> TTBOMK there has been no work done on an ARM64 port of XenServer/XCP at
> this time and only minimal work done on ARM generally. If you want to
> get this working then I think you are looking at doing a port (i.e. a
> bunch of development work) not simply following an installation
> tutorial.
> 
> However XenServer/XCP is developed separately from XenProject as Open
> XenServer over at xenserver.org, I suggest one of the lists over there
> would be the best place to start a discussion of a new arm64 port of
> xenserver.

I think you might want to subscribe to xs-devel@lists.xenserver.org and
start the discussion there, see: 

http://xenserver.org/discuss-virtualization/mailing-lists.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 13:47:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 13:47:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxyej-0000iE-UM; Mon, 08 Dec 2014 13:47: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 1Xxyei-0000he-6S
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 13:47:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	22/F7-25276-3EBA5845; Mon, 08 Dec 2014 13:47:15 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418046433!14138848!1
X-Originating-IP: [66.165.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 17864 invoked from network); 8 Dec 2014 13:47:14 -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;
	8 Dec 2014 13:47:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201389766"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 08:47: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 1Xxyee-0001eW-7l;
	Mon, 08 Dec 2014 13:47:12 +0000
Date: Mon, 8 Dec 2014 13:46:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1418034110.30016.1.camel@citrix.com>
Message-ID: <alpine.DEB.2.02.1412081346150.30971@kaball.uk.xensource.com>
References: <CAAiw7Jm+aH7n4qOZcJQ4Wc+ocEugvPq+RWYHemwhOLmcd5+EGw@mail.gmail.com>
	<1418034110.30016.1.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>,
	manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, xen-users@lists.xen.org,
	xen-devel <xen-devel@lists.xenproject.org>,
	manish jaggi <manishjaggi.oss@gmail.com>
Subject: Re: [Xen-devel] Steps to run XenServer on 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 Mon, 8 Dec 2014, Ian Campbell wrote:
> On Fri, 2014-12-05 at 15:15 -0800, manish jaggi wrote:
> > Hi,
> > 
> > I am trying to find a tutorial to jumpstart installing XenServer / XCP
> > on an ARM 64bit platform.
> > Could the mailing list help.
> 
> TTBOMK there has been no work done on an ARM64 port of XenServer/XCP at
> this time and only minimal work done on ARM generally. If you want to
> get this working then I think you are looking at doing a port (i.e. a
> bunch of development work) not simply following an installation
> tutorial.
> 
> However XenServer/XCP is developed separately from XenProject as Open
> XenServer over at xenserver.org, I suggest one of the lists over there
> would be the best place to start a discussion of a new arm64 port of
> xenserver.

I think you might want to subscribe to xs-devel@lists.xenserver.org and
start the discussion there, see: 

http://xenserver.org/discuss-virtualization/mailing-lists.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 13:47:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 13:47:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxyej-0000ht-DG; Mon, 08 Dec 2014 13:47: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 1Xxyeh-0000hX-5t
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 13:47:15 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DA/E7-25276-2EBA5845; Mon, 08 Dec 2014 13:47:14 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418046433!10727472!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16031 invoked from network); 8 Dec 2014 13:47:14 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 13:47:14 -0000
Received: by mail-wg0-f50.google.com with SMTP id k14so6168625wgh.23
	for <xen-devel@lists.xen.org>; Mon, 08 Dec 2014 05:47: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=ltkgk6X0yrdJLZ+QMoxwxQL988fNx/RI6ATLPVfU69M=;
	b=dtXuUbNn2SG9O0kC+ckuaxf7RWhfE4hoj8MnqGBNyBNAbi5bB3VOda3hLjtVoammzU
	8qyo6G/lohjHax3mvBQCm0n9tcsvA9EB90DA6+3L0blmAcYrRW3tIzZ0b/Xbl+X8YSkp
	a20PmWvb+YRs4ekcyYKbhYv+lhALhDJNOYUUMcTDXSX5u5takIt0l2y0BqfW+V8kT94m
	NTl1DCo7cqa2JdjKoDhufegn4E4Y8S244xjCpxaB7ZtfVjUdVg0+KXySqJuxe1L/cRSi
	YWmrnpBfsPe85oBy8iI+8rMZSn+5m2bDb1hYp1ik5pQd4eKIIjH1brTQEy1s5I6kpDuW
	hrSQ==
X-Gm-Message-State: ALoCoQlUvn/pkvQi0gLOcpvjizXAMi9Xh1meJ5zmjVqxoU+G3yARpf0ZpwyxFqDb+rRXJGB+U3Tb
X-Received: by 10.180.74.236 with SMTP id x12mr24522296wiv.40.1418046433759;
	Mon, 08 Dec 2014 05:47:13 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	rx8sm56682777wjb.30.2014.12.08.05.47.12 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 08 Dec 2014 05:47:12 -0800 (PST)
Message-ID: <5485ABDD.10301@linaro.org>
Date: Mon, 08 Dec 2014 13:47:09 +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: vijay.kilari@gmail.com, Ian.Campbell@citrix.com, 
	stefano.stabellini@eu.citrix.com, stefano.stabellini@citrix.com, 
	tim@xen.org, xen-devel@lists.xen.org
References: <1417830124-3914-1-git-send-email-vijay.kilari@gmail.com>
In-Reply-To: <1417830124-3914-1-git-send-email-vijay.kilari@gmail.com>
Cc: Prasun.Kapoor@caviumnetworks.com, vijaya.kumar@caviumnetworks.com,
	manish.jaggi@caviumnetworks.com
Subject: Re: [Xen-devel] [RFC PATCH] xen/arm: Manage uart TX interrupt
	correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Vijay,

You are fixing the pl011 driver, not all the UART. So the commit title
should at least contain the word "pl011".

On 06/12/14 01:42, vijay.kilari@gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> 
> On pl011.c when TX interrupt is received and

Why do you give the filename rather than the UART?

> TX buffer is empty, TX interrupt is not disabled and
> hence UART interrupt routine see TX interrupt always
> in MIS register and cpu loops infinitly.

I'm sorry to say that, but this sentence is difficult to understand.

> With this patch, mask and umask TX interrupt

s/umask/unmask

> when required

You need to explain when it's required...

> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> ---
>  xen/drivers/char/pl011.c  |   18 ++++++++++++++++++
>  xen/drivers/char/serial.c |   30 +++++++++++++++++++++++++++++-
>  xen/include/xen/serial.h  |    4 ++++
>  3 files changed, 51 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
> index dd19ce8..ad48df3 100644
> --- a/xen/drivers/char/pl011.c
> +++ b/xen/drivers/char/pl011.c
> @@ -109,6 +109,8 @@ static void __init pl011_init_preirq(struct serial_port *port)
>              panic("pl011: No Baud rate configured\n");
>          uart->baud = (uart->clock_hz << 2) / divisor;
>      }
> +    /* Trigger RX interrupt at 1/2 full, TX interrupt at 7/8 empty */
> +    pl011_write(uart, IFLS, (2<<3 | 0));

The RX change seems to come from nowhere. You have to explain why you
need it in the commit message.

As you add start_tx/stop_tx, I don't think this has to be kept.

[..]

> diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
> index 44026b1..d2ce8a8 100644
> --- a/xen/drivers/char/serial.c
> +++ b/xen/drivers/char/serial.c
> @@ -76,6 +76,19 @@ void serial_tx_interrupt(struct serial_port *port, struct cpu_user_regs *regs)
>          cpu_relax();
>      }
>  
> +    if ( port->txbufc == port->txbufp )
> +    {
> +        /* Disable TX. nothing to send */
> +        if ( port->driver->stop_tx != NULL )
> +            port->driver->stop_tx(port);

Can you introduce helpers for both stop_tx and start_tx? It would avoid
to add if ( ... ) port->driver->...( ) every time.

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 Dec 08 13:52:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 13:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxyjE-0001Gd-8T; Mon, 08 Dec 2014 13:51: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 1XxyjD-0001FQ-DM
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 13:51:55 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	54/F4-02957-AFCA5845; Mon, 08 Dec 2014 13:51:54 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418046711!13674812!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15319 invoked from network); 8 Dec 2014 13:51:53 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 13:51:53 -0000
Received: from mail-lb0-f175.google.com ([209.85.217.175]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVIWs93bFMp+h4+B+7lzLp8KEkDOTVyYa@postini.com;
	Mon, 08 Dec 2014 05:51:53 PST
Received: by mail-lb0-f175.google.com with SMTP id u10so3833233lbd.34
	for <xen-devel@lists.xen.org>; Mon, 08 Dec 2014 05:51: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;
	bh=q1WvxvNREMDB2GPNVE00NdlhDQRfcmueCoJgPlgidUU=;
	b=OFUTWXYimFvp2r5J6MTt3vMaFaIV3EuOH2XG68bScJvPbdGwl/4bYqXGHoXSWnWvnI
	earfJ73YjxnlBuzQBuDeBUcCHdwZTSreBv1JhQhrNICCNHmR58Q0BZ/zDmvOb2OUU0by
	+mcIrJKc2UuSeThpEd1nwuQFRF82HrfbO8YuM=
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=q1WvxvNREMDB2GPNVE00NdlhDQRfcmueCoJgPlgidUU=;
	b=QKTVfKNJoieIKCk8a4/Dm4LlTxLpRzFYRYPI4s8eDKvFqWXVpUhLVABtA0xF5PuVTH
	6LCg9u02G6d6EQZ0SdnVXoFx9lxzUc80MJuHssXswEC6UCB5vo8+5P1+xH2y/fRYBPKC
	0wMimOCEfpPm5+BFgsWPDJNKlJvwfnZ/FK8O8HPjgoQm+iaVdIiQufbrhS4hlZ9ZD6Ft
	pejHoIM6bpt1KPru8KvApFqa/jSN3JCXkh+WGXLDORLQ+Vhbhmf5lyBEh2eKA0Zyle55
	YC3ADoOJlE6bHNua2EMu2PpRZspJWmfRR0GaKMM6euQsPRoswdEOivcL4XgXSytGeLsP
	hpFA==
X-Gm-Message-State: ALoCoQlNrgw+0X/QVbKKeLiQ1Fjidwnia8WChT0TNxdn7XQMKdgKwtMuSukEDRRZesMWlcMRd8NL8tPat/LQguzQUnrhan8xlgWiMAjGyFZ4gmiatG2uEQUAHPq2fUzqh5Puf/e85KBHxx+FaF7b8nTLy3KaR3QcHw==
X-Received: by 10.152.88.44 with SMTP id bd12mr16278013lab.88.1418046709920;
	Mon, 08 Dec 2014 05:51:49 -0800 (PST)
X-Received: by 10.152.88.44 with SMTP id bd12mr16278000lab.88.1418046709825;
	Mon, 08 Dec 2014 05:51:49 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id a1sm3934547lbi.11.2014.12.08.05.51.48
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Mon, 08 Dec 2014 05:51:49 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Mon,  8 Dec 2014 15:51:47 +0200
Message-Id: <1418046707-6900-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] [PATCH v2] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UART is not able to receive bytes when idle mode is not
configured properly. When we use Xen with old Linux
Kernel (for example 3.8) this kernel configures hwmods
for all devices even if the device tree nodes for those
devices is absent in device tree. Thus UART idle mode
is configured too. The fake node for the UART should
be added to the device tree because the MMIO range
is not mapped by Xen. So UART works normally in this
case. But new Linux Kernel (3.12 and upper) doesn't
configure idle mode for UART and UART can not work
normally in this case.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
Changed since v1:
 * corrected commit message

 xen/drivers/char/omap-uart.c | 3 +++
 xen/include/xen/8250-uart.h  | 4 ++++
 2 files changed, 7 insertions(+)

diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
index a798b8d..16d1454 100644
--- a/xen/drivers/char/omap-uart.c
+++ b/xen/drivers/char/omap-uart.c
@@ -195,6 +195,9 @@ static void __init omap_uart_init_preirq(struct serial_port *port)
     omap_write(uart, UART_MCR, UART_MCR_DTR|UART_MCR_RTS);
 
     omap_write(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
+
+    /* setup iddle mode */
+    omap_write(uart, UART_SYSC, OMAP_UART_SYSC_DEF_CONF);
 }
 
 static void __init omap_uart_init_postirq(struct serial_port *port)
diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
index a682bae..304b9dd 100644
--- a/xen/include/xen/8250-uart.h
+++ b/xen/include/xen/8250-uart.h
@@ -32,6 +32,7 @@
 #define UART_MCR          0x04    /* Modem control        */
 #define UART_LSR          0x05    /* line status          */
 #define UART_MSR          0x06    /* Modem status         */
+#define UART_SYSC         0x15    /* System configuration register */
 #define UART_USR          0x1f    /* Status register (DW) */
 #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
 #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
@@ -145,6 +146,9 @@
 /* SCR register bitmasks */
 #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 << 7)
 
+/* System configuration register */
+#define OMAP_UART_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is enabled */
+
 #endif /* __XEN_8250_UART_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 Dec 08 13:52:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 13:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxyjE-0001Gd-8T; Mon, 08 Dec 2014 13:51: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 1XxyjD-0001FQ-DM
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 13:51:55 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	54/F4-02957-AFCA5845; Mon, 08 Dec 2014 13:51:54 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418046711!13674812!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15319 invoked from network); 8 Dec 2014 13:51:53 -0000
Received: from exprod5og111.obsmtp.com (HELO exprod5og111.obsmtp.com)
	(64.18.0.22)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 13:51:53 -0000
Received: from mail-lb0-f175.google.com ([209.85.217.175]) (using TLSv1) by
	exprod5ob111.postini.com ([64.18.4.12]) with SMTP
	ID DSNKVIWs93bFMp+h4+B+7lzLp8KEkDOTVyYa@postini.com;
	Mon, 08 Dec 2014 05:51:53 PST
Received: by mail-lb0-f175.google.com with SMTP id u10so3833233lbd.34
	for <xen-devel@lists.xen.org>; Mon, 08 Dec 2014 05:51: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;
	bh=q1WvxvNREMDB2GPNVE00NdlhDQRfcmueCoJgPlgidUU=;
	b=OFUTWXYimFvp2r5J6MTt3vMaFaIV3EuOH2XG68bScJvPbdGwl/4bYqXGHoXSWnWvnI
	earfJ73YjxnlBuzQBuDeBUcCHdwZTSreBv1JhQhrNICCNHmR58Q0BZ/zDmvOb2OUU0by
	+mcIrJKc2UuSeThpEd1nwuQFRF82HrfbO8YuM=
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=q1WvxvNREMDB2GPNVE00NdlhDQRfcmueCoJgPlgidUU=;
	b=QKTVfKNJoieIKCk8a4/Dm4LlTxLpRzFYRYPI4s8eDKvFqWXVpUhLVABtA0xF5PuVTH
	6LCg9u02G6d6EQZ0SdnVXoFx9lxzUc80MJuHssXswEC6UCB5vo8+5P1+xH2y/fRYBPKC
	0wMimOCEfpPm5+BFgsWPDJNKlJvwfnZ/FK8O8HPjgoQm+iaVdIiQufbrhS4hlZ9ZD6Ft
	pejHoIM6bpt1KPru8KvApFqa/jSN3JCXkh+WGXLDORLQ+Vhbhmf5lyBEh2eKA0Zyle55
	YC3ADoOJlE6bHNua2EMu2PpRZspJWmfRR0GaKMM6euQsPRoswdEOivcL4XgXSytGeLsP
	hpFA==
X-Gm-Message-State: ALoCoQlNrgw+0X/QVbKKeLiQ1Fjidwnia8WChT0TNxdn7XQMKdgKwtMuSukEDRRZesMWlcMRd8NL8tPat/LQguzQUnrhan8xlgWiMAjGyFZ4gmiatG2uEQUAHPq2fUzqh5Puf/e85KBHxx+FaF7b8nTLy3KaR3QcHw==
X-Received: by 10.152.88.44 with SMTP id bd12mr16278013lab.88.1418046709920;
	Mon, 08 Dec 2014 05:51:49 -0800 (PST)
X-Received: by 10.152.88.44 with SMTP id bd12mr16278000lab.88.1418046709825;
	Mon, 08 Dec 2014 05:51:49 -0800 (PST)
Received: from localhost ([195.238.92.241])
	by mx.google.com with ESMTPSA id a1sm3934547lbi.11.2014.12.08.05.51.48
	for <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Mon, 08 Dec 2014 05:51:49 -0800 (PST)
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
To: xen-devel@lists.xen.org
Date: Mon,  8 Dec 2014 15:51:47 +0200
Message-Id: <1418046707-6900-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] [PATCH v2] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UART is not able to receive bytes when idle mode is not
configured properly. When we use Xen with old Linux
Kernel (for example 3.8) this kernel configures hwmods
for all devices even if the device tree nodes for those
devices is absent in device tree. Thus UART idle mode
is configured too. The fake node for the UART should
be added to the device tree because the MMIO range
is not mapped by Xen. So UART works normally in this
case. But new Linux Kernel (3.12 and upper) doesn't
configure idle mode for UART and UART can not work
normally in this case.

Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
---
Changed since v1:
 * corrected commit message

 xen/drivers/char/omap-uart.c | 3 +++
 xen/include/xen/8250-uart.h  | 4 ++++
 2 files changed, 7 insertions(+)

diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
index a798b8d..16d1454 100644
--- a/xen/drivers/char/omap-uart.c
+++ b/xen/drivers/char/omap-uart.c
@@ -195,6 +195,9 @@ static void __init omap_uart_init_preirq(struct serial_port *port)
     omap_write(uart, UART_MCR, UART_MCR_DTR|UART_MCR_RTS);
 
     omap_write(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
+
+    /* setup iddle mode */
+    omap_write(uart, UART_SYSC, OMAP_UART_SYSC_DEF_CONF);
 }
 
 static void __init omap_uart_init_postirq(struct serial_port *port)
diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
index a682bae..304b9dd 100644
--- a/xen/include/xen/8250-uart.h
+++ b/xen/include/xen/8250-uart.h
@@ -32,6 +32,7 @@
 #define UART_MCR          0x04    /* Modem control        */
 #define UART_LSR          0x05    /* line status          */
 #define UART_MSR          0x06    /* Modem status         */
+#define UART_SYSC         0x15    /* System configuration register */
 #define UART_USR          0x1f    /* Status register (DW) */
 #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
 #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
@@ -145,6 +146,9 @@
 /* SCR register bitmasks */
 #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 << 7)
 
+/* System configuration register */
+#define OMAP_UART_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is enabled */
+
 #endif /* __XEN_8250_UART_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 Dec 08 13:55:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 13:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxymr-0001c6-Tr; Mon, 08 Dec 2014 13:55:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xxymr-0001c1-0d
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 13:55:41 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	49/EA-20609-CDDA5845; Mon, 08 Dec 2014 13:55:40 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418046936!13711528!1
X-Originating-IP: [66.165.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 599 invoked from network); 8 Dec 2014 13:55:37 -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;
	8 Dec 2014 13:55:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201789656"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 08:55: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 1Xxymk-0001qE-Vj;
	Mon, 08 Dec 2014 13:55:34 +0000
Date: Mon, 8 Dec 2014 13:55:34 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141208135534.GA21374@zion.uk.xensource.com>
References: <20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
	<20141208101304.GB17128@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394C523@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2394C523@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 01:08:18PM +0000, Zhangleiqiang (Trump) wrote:
> > On Mon, Dec 08, 2014 at 06:44:26AM +0000, Zhangleiqiang (Trump) wrote:
> > > > On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
> > > > [...]
> > > > > > I think that's expected, because guest RX data path still uses
> > > > > > grant_copy while guest TX uses grant_map to do zero-copy transmit.
> > > > >
> > > > > As far as I know, there are three main grant-related operations
> > > > > used in split
> > > > device model: grant mapping, grant transfer and grant copy.
> > > > > Grant transfer has not used now, and grant mapping and grant
> > > > > transfer both
> > > > involve "TLB" refresh work for hypervisor, am I right?  Or only
> > > > grant transfer has this overhead?
> > > >
> > > > Transfer is not used so I can't tell. Grant unmap causes TLB flush.
> > > >
> > > > I saw in an email the other day XenServer folks has some planned
> > > > improvement to avoid TLB flush in Xen to upstream in 4.6 window. I
> > > > can't speak for sure it will get upstreamed as I don't work on that.
> > > >
> > > > > Does grant copy surely has more overhead than grant mapping?
> > > > >
> > > >
> > > > At the very least the zero-copy TX path is faster than previous copying path.
> > > >
> > > > But speaking of the micro operation I'm not sure.
> > > >
> > > > There was once persistent map prototype netback / netfront that
> > > > establishes a memory pool between FE and BE then use memcpy to copy
> > > > data. Unfortunately that prototype was not done right so the result was not
> > good.
> > >
> > > The newest mail about persistent grant I can find is sent from 16 Nov
> > > 2012
> > > (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00832.html).
> > > Why is it not done right and not merged into upstream?
> > 
> > AFAICT there's one more memcpy than necessary, i.e. frontend memcpy data
> > into the pool then backend memcpy data out of the pool, when backend should
> > be able to use the page in pool directly.
> 
> Memcpy should cheaper than grant_copy because the former needs not the
> "hypercall" which will cause "VM Exit" to "XEN Hypervisor", am I
> right? For RX path, using memcpy based on persistent grant table may
> have higher performance than using grant copy now.

In theory yes. Unfortunately nobody has benchmarked that properly.

If you're interested in doing work on optimising RX performance, you
might want to sync up with XenServer folks?

> 
> I have seen "move grant copy to guest" and "Fix grant copy alignment
> problem" as optimization methods used in "NetChannel2"
> (http://www-archive.xenproject.org/files/xensummit_fall07/16_JoseRenatoSantos.pdf).
> Unfortunately, NetChannel2 seems not be supported from 2.6.32. Do you
> know them and are them be helpful for RX path optimization under
> current upstream implementation?

Not sure, that's long before I ever started working on Xen.

> 
> By the way, after rethinking the testing results for multi-queue pv
> (kernel 3.17.4+XEN 4.4) implementation, I find that when using four
> queues for netback/netfront, there will be about 3 netback process
> running with high CPU usage on receive Dom0 (about 85% usage per
> process running on one CPU core), and the aggregate throughout is only
> about 5Gbps. I doubt that there may be some bug or pitfall in current
> multi-queue implementation, because for 5Gbps throughout, occurring
> about all of 3 CPU core for packet receiving is somehow abnormal.
> 

3.17.4 doesn't contain David Vrabel's fixes.

Look for 
  bc96f648df1bbc2729abbb84513cf4f64273a1f1
  f48da8b14d04ca87ffcffe68829afd45f926ec6a
  ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e
in David Miller's net tree.

BTW there are some improvement planned for 4.6: "[Xen-devel] [PATCH v3
0/2] gnttab: Improve scaleability". This is orthogonal to the problem
you're trying to solve but it should help improve performance in
general.


Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 13:55:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 13:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxymr-0001c6-Tr; Mon, 08 Dec 2014 13:55:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xxymr-0001c1-0d
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 13:55:41 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	49/EA-20609-CDDA5845; Mon, 08 Dec 2014 13:55:40 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418046936!13711528!1
X-Originating-IP: [66.165.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 599 invoked from network); 8 Dec 2014 13:55:37 -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;
	8 Dec 2014 13:55:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201789656"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 08:55: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 1Xxymk-0001qE-Vj;
	Mon, 08 Dec 2014 13:55:34 +0000
Date: Mon, 8 Dec 2014 13:55:34 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Message-ID: <20141208135534.GA21374@zion.uk.xensource.com>
References: <20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
	<20141208101304.GB17128@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394C523@SZXEMA512-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2394C523@SZXEMA512-MBX.china.huawei.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 01:08:18PM +0000, Zhangleiqiang (Trump) wrote:
> > On Mon, Dec 08, 2014 at 06:44:26AM +0000, Zhangleiqiang (Trump) wrote:
> > > > On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
> > > > [...]
> > > > > > I think that's expected, because guest RX data path still uses
> > > > > > grant_copy while guest TX uses grant_map to do zero-copy transmit.
> > > > >
> > > > > As far as I know, there are three main grant-related operations
> > > > > used in split
> > > > device model: grant mapping, grant transfer and grant copy.
> > > > > Grant transfer has not used now, and grant mapping and grant
> > > > > transfer both
> > > > involve "TLB" refresh work for hypervisor, am I right?  Or only
> > > > grant transfer has this overhead?
> > > >
> > > > Transfer is not used so I can't tell. Grant unmap causes TLB flush.
> > > >
> > > > I saw in an email the other day XenServer folks has some planned
> > > > improvement to avoid TLB flush in Xen to upstream in 4.6 window. I
> > > > can't speak for sure it will get upstreamed as I don't work on that.
> > > >
> > > > > Does grant copy surely has more overhead than grant mapping?
> > > > >
> > > >
> > > > At the very least the zero-copy TX path is faster than previous copying path.
> > > >
> > > > But speaking of the micro operation I'm not sure.
> > > >
> > > > There was once persistent map prototype netback / netfront that
> > > > establishes a memory pool between FE and BE then use memcpy to copy
> > > > data. Unfortunately that prototype was not done right so the result was not
> > good.
> > >
> > > The newest mail about persistent grant I can find is sent from 16 Nov
> > > 2012
> > > (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00832.html).
> > > Why is it not done right and not merged into upstream?
> > 
> > AFAICT there's one more memcpy than necessary, i.e. frontend memcpy data
> > into the pool then backend memcpy data out of the pool, when backend should
> > be able to use the page in pool directly.
> 
> Memcpy should cheaper than grant_copy because the former needs not the
> "hypercall" which will cause "VM Exit" to "XEN Hypervisor", am I
> right? For RX path, using memcpy based on persistent grant table may
> have higher performance than using grant copy now.

In theory yes. Unfortunately nobody has benchmarked that properly.

If you're interested in doing work on optimising RX performance, you
might want to sync up with XenServer folks?

> 
> I have seen "move grant copy to guest" and "Fix grant copy alignment
> problem" as optimization methods used in "NetChannel2"
> (http://www-archive.xenproject.org/files/xensummit_fall07/16_JoseRenatoSantos.pdf).
> Unfortunately, NetChannel2 seems not be supported from 2.6.32. Do you
> know them and are them be helpful for RX path optimization under
> current upstream implementation?

Not sure, that's long before I ever started working on Xen.

> 
> By the way, after rethinking the testing results for multi-queue pv
> (kernel 3.17.4+XEN 4.4) implementation, I find that when using four
> queues for netback/netfront, there will be about 3 netback process
> running with high CPU usage on receive Dom0 (about 85% usage per
> process running on one CPU core), and the aggregate throughout is only
> about 5Gbps. I doubt that there may be some bug or pitfall in current
> multi-queue implementation, because for 5Gbps throughout, occurring
> about all of 3 CPU core for packet receiving is somehow abnormal.
> 

3.17.4 doesn't contain David Vrabel's fixes.

Look for 
  bc96f648df1bbc2729abbb84513cf4f64273a1f1
  f48da8b14d04ca87ffcffe68829afd45f926ec6a
  ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e
in David Miller's net tree.

BTW there are some improvement planned for 4.6: "[Xen-devel] [PATCH v3
0/2] gnttab: Improve scaleability". This is orthogonal to the problem
you're trying to solve but it should help improve performance in
general.


Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 14:08:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 14:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxyz2-0002Is-QG; Mon, 08 Dec 2014 14:08: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 1Xxyz2-0002In-AG
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 14:08:16 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	0F/96-02957-FC0B5845; Mon, 08 Dec 2014 14:08:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418047693!13711426!1
X-Originating-IP: [66.165.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 8835 invoked from network); 8 Dec 2014 14:08:14 -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;
	8 Dec 2014 14:08:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201795959"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 09:08: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 1Xxyyt-00025r-GI;
	Mon, 08 Dec 2014 14:08:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xxyyt-0007F0-4V;
	Mon, 08 Dec 2014 14:08:07 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Mon, 8 Dec 2014 14:08:05 +0000
Message-ID: <1418047685-27801-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] TestSupport: use timeout(1)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If a command we run times out, the machinery in tcmdex() will arrange
for the ts-* script to spot the timeout, and stop waiting for it.

However it is also necessary for the command we ran to die.  It has a
copy of the owner daemon fd, so if it doesn't, our resources won't get
freed.  In sufficiently exciting bugs, our allocation might continue
indefinitely, while a subprocess of ours hangs on after we are long
gone.

timeout(1) does not print a message when the process times out (!)  So
we can't do away with the logic in tcmdex().  We set the timeout(1)
timeout to 30s more than our own timeout, so that tcmdex() will time
out first and print a message.

We could use alarm(1) as we do in Osstest/Serial/sympathy.pm but that
program isn't packaged and its unsophisticated approach is not really
appropriate for arbitrary nonconsenting programs.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index a3b6936..ca680c0 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -388,7 +388,10 @@ sub sshopts () {
 sub tcmdex {
     my ($timeout,$stdout,$cmd,$optsref,@args) = @_;
     logm("executing $cmd ... @args");
-    my $r= cmd($timeout,$stdout, $cmd,@$optsref,@args);
+    # We use timeout(1) as a backstop, in case $cmd doesn't die.  We
+    # need $cmd to die because we won't release the resources we own
+    # until all of our children are dead.
+    my $r= cmd($timeout,$stdout, 'timeout',$timeout+30, $cmd,@$optsref,@args);
     $r and die "status $r";
 }
 
-- 
1.7.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 Dec 08 14:08:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 14:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxyz2-0002Is-QG; Mon, 08 Dec 2014 14:08: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 1Xxyz2-0002In-AG
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 14:08:16 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	0F/96-02957-FC0B5845; Mon, 08 Dec 2014 14:08:15 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418047693!13711426!1
X-Originating-IP: [66.165.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 8835 invoked from network); 8 Dec 2014 14:08:14 -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;
	8 Dec 2014 14:08:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201795959"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 09:08: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 1Xxyyt-00025r-GI;
	Mon, 08 Dec 2014 14:08:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xxyyt-0007F0-4V;
	Mon, 08 Dec 2014 14:08:07 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Mon, 8 Dec 2014 14:08:05 +0000
Message-ID: <1418047685-27801-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] TestSupport: use timeout(1)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If a command we run times out, the machinery in tcmdex() will arrange
for the ts-* script to spot the timeout, and stop waiting for it.

However it is also necessary for the command we ran to die.  It has a
copy of the owner daemon fd, so if it doesn't, our resources won't get
freed.  In sufficiently exciting bugs, our allocation might continue
indefinitely, while a subprocess of ours hangs on after we are long
gone.

timeout(1) does not print a message when the process times out (!)  So
we can't do away with the logic in tcmdex().  We set the timeout(1)
timeout to 30s more than our own timeout, so that tcmdex() will time
out first and print a message.

We could use alarm(1) as we do in Osstest/Serial/sympathy.pm but that
program isn't packaged and its unsophisticated approach is not really
appropriate for arbitrary nonconsenting programs.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index a3b6936..ca680c0 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -388,7 +388,10 @@ sub sshopts () {
 sub tcmdex {
     my ($timeout,$stdout,$cmd,$optsref,@args) = @_;
     logm("executing $cmd ... @args");
-    my $r= cmd($timeout,$stdout, $cmd,@$optsref,@args);
+    # We use timeout(1) as a backstop, in case $cmd doesn't die.  We
+    # need $cmd to die because we won't release the resources we own
+    # until all of our children are dead.
+    my $r= cmd($timeout,$stdout, 'timeout',$timeout+30, $cmd,@$optsref,@args);
     $r and die "status $r";
 }
 
-- 
1.7.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 Dec 08 14:17:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 14: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 1Xxz7D-0002mZ-PH; Mon, 08 Dec 2014 14:16:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xxz7C-0002mU-JZ
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 14:16:42 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	B1/6D-02696-9C2B5845; Mon, 08 Dec 2014 14:16:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418048199!13682642!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 22589 invoked from network); 8 Dec 2014 14:16:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 14:16:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201402232"
Message-ID: <1418048197.2827.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 8 Dec 2014 14:16:37 +0000
In-Reply-To: <1418047685-27801-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1418047685-27801-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] TestSupport: use timeout(1)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-08 at 14:08 +0000, Ian Jackson wrote:
> If a command we run times out, the machinery in tcmdex() will arrange
> for the ts-* script to spot the timeout, and stop waiting for it.
> 
> However it is also necessary for the command we ran to die.  It has a
> copy of the owner daemon fd, so if it doesn't, our resources won't get
> freed.  In sufficiently exciting bugs, our allocation might continue
> indefinitely, while a subprocess of ours hangs on after we are long
> gone.
> 
> timeout(1) does not print a message when the process times out (!)  So
> we can't do away with the logic in tcmdex().

I think you mean s/tcmdex/cmd/ in a few places here, since cmd() is
where all the existing timeout stuff is.

>   We set the timeout(1)
> timeout to 30s more than our own timeout, so that tcmdex() will time
> out first and print a message.
> 
> We could use alarm(1) as we do in Osstest/Serial/sympathy.pm but that
> program isn't packaged and its unsophisticated approach is not really
> appropriate for arbitrary nonconsenting programs.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Apart from that niggle:
Acked-by: Ian Campbell <ian.campbell@citrix.com>


> ---
>  Osstest/TestSupport.pm |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index a3b6936..ca680c0 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -388,7 +388,10 @@ sub sshopts () {
>  sub tcmdex {
>      my ($timeout,$stdout,$cmd,$optsref,@args) = @_;
>      logm("executing $cmd ... @args");
> -    my $r= cmd($timeout,$stdout, $cmd,@$optsref,@args);
> +    # We use timeout(1) as a backstop, in case $cmd doesn't die.  We
> +    # need $cmd to die because we won't release the resources we own
> +    # until all of our children are dead.
> +    my $r= cmd($timeout,$stdout, 'timeout',$timeout+30, $cmd,@$optsref,@args);
>      $r and die "status $r";
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 14:17:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 14: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 1Xxz7D-0002mZ-PH; Mon, 08 Dec 2014 14:16:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xxz7C-0002mU-JZ
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 14:16:42 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	B1/6D-02696-9C2B5845; Mon, 08 Dec 2014 14:16:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418048199!13682642!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 22589 invoked from network); 8 Dec 2014 14:16:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 14:16:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,538,1413244800"; d="scan'208";a="201402232"
Message-ID: <1418048197.2827.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 8 Dec 2014 14:16:37 +0000
In-Reply-To: <1418047685-27801-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1418047685-27801-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] TestSupport: use timeout(1)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-08 at 14:08 +0000, Ian Jackson wrote:
> If a command we run times out, the machinery in tcmdex() will arrange
> for the ts-* script to spot the timeout, and stop waiting for it.
> 
> However it is also necessary for the command we ran to die.  It has a
> copy of the owner daemon fd, so if it doesn't, our resources won't get
> freed.  In sufficiently exciting bugs, our allocation might continue
> indefinitely, while a subprocess of ours hangs on after we are long
> gone.
> 
> timeout(1) does not print a message when the process times out (!)  So
> we can't do away with the logic in tcmdex().

I think you mean s/tcmdex/cmd/ in a few places here, since cmd() is
where all the existing timeout stuff is.

>   We set the timeout(1)
> timeout to 30s more than our own timeout, so that tcmdex() will time
> out first and print a message.
> 
> We could use alarm(1) as we do in Osstest/Serial/sympathy.pm but that
> program isn't packaged and its unsophisticated approach is not really
> appropriate for arbitrary nonconsenting programs.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Apart from that niggle:
Acked-by: Ian Campbell <ian.campbell@citrix.com>


> ---
>  Osstest/TestSupport.pm |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index a3b6936..ca680c0 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -388,7 +388,10 @@ sub sshopts () {
>  sub tcmdex {
>      my ($timeout,$stdout,$cmd,$optsref,@args) = @_;
>      logm("executing $cmd ... @args");
> -    my $r= cmd($timeout,$stdout, $cmd,@$optsref,@args);
> +    # We use timeout(1) as a backstop, in case $cmd doesn't die.  We
> +    # need $cmd to die because we won't release the resources we own
> +    # until all of our children are dead.
> +    my $r= cmd($timeout,$stdout, 'timeout',$timeout+30, $cmd,@$optsref,@args);
>      $r and die "status $r";
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 14:18:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 14: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 1Xxz8R-0002rU-7j; Mon, 08 Dec 2014 14:17:59 +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 1Xxz8Q-0002rM-36
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 14:17:58 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	27/38-02954-513B5845; Mon, 08 Dec 2014 14:17:57 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418048274!13714289!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1984 invoked from network); 8 Dec 2014 14:17:56 -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; 8 Dec 2014 14:17:56 -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 sB8EHo5Q007203
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 8 Dec 2014 09:17:51 -0500
Received: from vitty.brq.redhat.com (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 sB8EHmpE008555; Mon, 8 Dec 2014 09:17:49 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon,  8 Dec 2014 15:17:47 +0100
Message-Id: <1418048267-18509-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Andrew Jones <drjones@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen/blkfront: remove redundant flush_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

flush_op is unambiguously defined by feature_flush:
    REQ_FUA | REQ_FLUSH -> BLKIF_OP_WRITE_BARRIER
    REQ_FLUSH -> BLKIF_OP_FLUSH_DISKCACHE
    0 -> 0
and thus can be removed. This is just a cleanup.

The patch was suggested by Boris Ostrovsky.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
The patch is supposed to be applied after "xen/blkfront: improve protection
against issuing unsupported REQ_FUA".
---
 drivers/block/xen-blkfront.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2e6c103..d1ee233 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -126,7 +126,6 @@ struct blkfront_info
 	unsigned int persistent_gnts_c;
 	unsigned long shadow_free;
 	unsigned int feature_flush;
-	unsigned int flush_op;
 	unsigned int feature_discard:1;
 	unsigned int feature_secdiscard:1;
 	unsigned int discard_granularity;
@@ -479,7 +478,14 @@ static int blkif_queue_request(struct request *req)
 				 * way.  (It's also a FLUSH+FUA, since it is
 				 * guaranteed ordered WRT previous writes.)
 				 */
-				ring_req->operation = info->flush_op;
+				if (unlikely(info->feature_flush & REQ_FUA))
+					ring_req->operation =
+						BLKIF_OP_WRITE_BARRIER;
+				else if (likely(info->feature_flush))
+					ring_req->operation =
+						BLKIF_OP_FLUSH_DISKCACHE;
+				else
+					ring_req->operation = 0;
 			}
 			ring_req->u.rw.nr_segments = nseg;
 		}
@@ -691,8 +697,8 @@ static void xlvbd_flush(struct blkfront_info *info)
 	blk_queue_flush(info->rq, info->feature_flush);
 	printk(KERN_INFO "blkfront: %s: %s: %s %s %s %s %s\n",
 	       info->gd->disk_name,
-	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
+	       info->feature_flush == (REQ_FLUSH | REQ_FUA) ?
+		"barrier" : (info->feature_flush == REQ_FLUSH ?
 		"flush diskcache" : "barrier or flush"),
 	       info->feature_flush ? "enabled;" : "disabled;",
 	       "persistent grants:",
@@ -1190,7 +1196,6 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 				if (error == -EOPNOTSUPP)
 					error = 0;
 				info->feature_flush = 0;
-				info->flush_op = 0;
 				xlvbd_flush(info);
 			}
 			/* fall through */
@@ -1810,7 +1815,6 @@ static void blkfront_connect(struct blkfront_info *info)
 		physical_sector_size = sector_size;
 
 	info->feature_flush = 0;
-	info->flush_op = 0;
 
 	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			    "feature-barrier", "%d", &barrier,
@@ -1823,10 +1827,8 @@ static void blkfront_connect(struct blkfront_info *info)
 	 *
 	 * If there are barriers, then we use flush.
 	 */
-	if (!err && barrier) {
+	if (!err && barrier)
 		info->feature_flush = REQ_FLUSH | REQ_FUA;
-		info->flush_op = BLKIF_OP_WRITE_BARRIER;
-	}
 	/*
 	 * And if there is "feature-flush-cache" use that above
 	 * barriers.
@@ -1835,10 +1837,8 @@ static void blkfront_connect(struct blkfront_info *info)
 			    "feature-flush-cache", "%d", &flush,
 			    NULL);
 
-	if (!err && flush) {
+	if (!err && flush)
 		info->feature_flush = REQ_FLUSH;
-		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
-	}
 
 	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			    "feature-discard", "%d", &discard,
-- 
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 Dec 08 14:18:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 14: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 1Xxz8R-0002rU-7j; Mon, 08 Dec 2014 14:17:59 +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 1Xxz8Q-0002rM-36
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 14:17:58 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	27/38-02954-513B5845; Mon, 08 Dec 2014 14:17:57 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418048274!13714289!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1984 invoked from network); 8 Dec 2014 14:17:56 -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; 8 Dec 2014 14:17:56 -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 sB8EHo5Q007203
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 8 Dec 2014 09:17:51 -0500
Received: from vitty.brq.redhat.com (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 sB8EHmpE008555; Mon, 8 Dec 2014 09:17:49 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon,  8 Dec 2014 15:17:47 +0100
Message-Id: <1418048267-18509-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Andrew Jones <drjones@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen/blkfront: remove redundant flush_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

flush_op is unambiguously defined by feature_flush:
    REQ_FUA | REQ_FLUSH -> BLKIF_OP_WRITE_BARRIER
    REQ_FLUSH -> BLKIF_OP_FLUSH_DISKCACHE
    0 -> 0
and thus can be removed. This is just a cleanup.

The patch was suggested by Boris Ostrovsky.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
The patch is supposed to be applied after "xen/blkfront: improve protection
against issuing unsupported REQ_FUA".
---
 drivers/block/xen-blkfront.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2e6c103..d1ee233 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -126,7 +126,6 @@ struct blkfront_info
 	unsigned int persistent_gnts_c;
 	unsigned long shadow_free;
 	unsigned int feature_flush;
-	unsigned int flush_op;
 	unsigned int feature_discard:1;
 	unsigned int feature_secdiscard:1;
 	unsigned int discard_granularity;
@@ -479,7 +478,14 @@ static int blkif_queue_request(struct request *req)
 				 * way.  (It's also a FLUSH+FUA, since it is
 				 * guaranteed ordered WRT previous writes.)
 				 */
-				ring_req->operation = info->flush_op;
+				if (unlikely(info->feature_flush & REQ_FUA))
+					ring_req->operation =
+						BLKIF_OP_WRITE_BARRIER;
+				else if (likely(info->feature_flush))
+					ring_req->operation =
+						BLKIF_OP_FLUSH_DISKCACHE;
+				else
+					ring_req->operation = 0;
 			}
 			ring_req->u.rw.nr_segments = nseg;
 		}
@@ -691,8 +697,8 @@ static void xlvbd_flush(struct blkfront_info *info)
 	blk_queue_flush(info->rq, info->feature_flush);
 	printk(KERN_INFO "blkfront: %s: %s: %s %s %s %s %s\n",
 	       info->gd->disk_name,
-	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
+	       info->feature_flush == (REQ_FLUSH | REQ_FUA) ?
+		"barrier" : (info->feature_flush == REQ_FLUSH ?
 		"flush diskcache" : "barrier or flush"),
 	       info->feature_flush ? "enabled;" : "disabled;",
 	       "persistent grants:",
@@ -1190,7 +1196,6 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 				if (error == -EOPNOTSUPP)
 					error = 0;
 				info->feature_flush = 0;
-				info->flush_op = 0;
 				xlvbd_flush(info);
 			}
 			/* fall through */
@@ -1810,7 +1815,6 @@ static void blkfront_connect(struct blkfront_info *info)
 		physical_sector_size = sector_size;
 
 	info->feature_flush = 0;
-	info->flush_op = 0;
 
 	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			    "feature-barrier", "%d", &barrier,
@@ -1823,10 +1827,8 @@ static void blkfront_connect(struct blkfront_info *info)
 	 *
 	 * If there are barriers, then we use flush.
 	 */
-	if (!err && barrier) {
+	if (!err && barrier)
 		info->feature_flush = REQ_FLUSH | REQ_FUA;
-		info->flush_op = BLKIF_OP_WRITE_BARRIER;
-	}
 	/*
 	 * And if there is "feature-flush-cache" use that above
 	 * barriers.
@@ -1835,10 +1837,8 @@ static void blkfront_connect(struct blkfront_info *info)
 			    "feature-flush-cache", "%d", &flush,
 			    NULL);
 
-	if (!err && flush) {
+	if (!err && flush)
 		info->feature_flush = REQ_FLUSH;
-		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
-	}
 
 	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			    "feature-discard", "%d", &discard,
-- 
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 Dec 08 14:55:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 14:55:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxzhx-00044e-J2; Mon, 08 Dec 2014 14:54: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 1Xxzhw-00044Z-QG
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 14:54:40 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CC/DB-15461-0BBB5845; Mon, 08 Dec 2014 14:54:40 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418050477!14157368!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6610 invoked from network); 8 Dec 2014 14:54:38 -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; 8 Dec 2014 14:54: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 sB8EsWfa003535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 14:54: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
	sB8EsSkJ007984
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Dec 2014 14:54:28 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
	sB8EsQUS010388; Mon, 8 Dec 2014 14:54: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, 08 Dec 2014 06:54:26 -0800
Message-ID: <5485BC13.3030403@oracle.com>
Date: Mon, 08 Dec 2014 09:56: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: Jan Beulich <JBeulich@suse.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<5481E39B020000780004D450@mail.emea.novell.com>
	<5481E564020000780004D47B@mail.emea.novell.com>
	<5481E6FC.1070905@oracle.com>
	<54857061020000780004D999@mail.emea.novell.com>
In-Reply-To: <54857061020000780004D999@mail.emea.novell.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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


>>> Additionally please add IN and OUT annotations. When I first saw
>>> this I assumed they would all be OUT (in which case the long running
>>> loop problem mentioned in the reply to one of the other patches
>>> wouldn't have been there), matching their CPU counterpart...
>> I don't follow this. Are you saying that if ti->max_devs in patch 3/4 is
>> an IN (which it is) then we don't have to guard for long-running loops?
> If they were all OUT then there wouldn't be a way for the entire
> operation to be fooled into going over more devices than there are
> in the system.

Assuming I add continuations to the loop, too many devices wouldn't be a 
problem for the hypervisor, would it? If an unreasonable number is 
provided then eventually copy_from_guest() will fault.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 14:55:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 14:55:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xxzhx-00044e-J2; Mon, 08 Dec 2014 14:54: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 1Xxzhw-00044Z-QG
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 14:54:40 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CC/DB-15461-0BBB5845; Mon, 08 Dec 2014 14:54:40 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418050477!14157368!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6610 invoked from network); 8 Dec 2014 14:54:38 -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; 8 Dec 2014 14:54: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 sB8EsWfa003535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 14:54: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
	sB8EsSkJ007984
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Dec 2014 14:54:28 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
	sB8EsQUS010388; Mon, 8 Dec 2014 14:54: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, 08 Dec 2014 06:54:26 -0800
Message-ID: <5485BC13.3030403@oracle.com>
Date: Mon, 08 Dec 2014 09:56: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: Jan Beulich <JBeulich@suse.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<5481E39B020000780004D450@mail.emea.novell.com>
	<5481E564020000780004D47B@mail.emea.novell.com>
	<5481E6FC.1070905@oracle.com>
	<54857061020000780004D999@mail.emea.novell.com>
In-Reply-To: <54857061020000780004D999@mail.emea.novell.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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


>>> Additionally please add IN and OUT annotations. When I first saw
>>> this I assumed they would all be OUT (in which case the long running
>>> loop problem mentioned in the reply to one of the other patches
>>> wouldn't have been there), matching their CPU counterpart...
>> I don't follow this. Are you saying that if ti->max_devs in patch 3/4 is
>> an IN (which it is) then we don't have to guard for long-running loops?
> If they were all OUT then there wouldn't be a way for the entire
> operation to be fooled into going over more devices than there are
> in the system.

Assuming I add continuations to the loop, too many devices wouldn't be a 
problem for the hypervisor, would it? If an unreasonable number is 
provided then eventually copy_from_guest() will fault.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 15:11:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxzyD-0004Vn-7k; Mon, 08 Dec 2014 15:11:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XxzyB-0004Vi-PA
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:11:27 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	B1/49-29352-F9FB5845; Mon, 08 Dec 2014 15:11:27 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418051484!12206342!1
X-Originating-IP: [66.165.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 30640 invoked from network); 8 Dec 2014 15:11: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;
	8 Dec 2014 15:11:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201825625"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 10:11:07 -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 1Xxzxr-0003GX-JE;
	Mon, 08 Dec 2014 15:11:07 +0000
Date: Mon, 8 Dec 2014 15:11:07 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141208151107.GB1900@perard.uk.xensource.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
	<1418039984.30016.15.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418039984.30016.15.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Set path to console on domain
	startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 11:59:44AM +0000, Ian Campbell wrote:
> On Fri, 2014-12-05 at 16:30 +0000, Anthony PERARD wrote:
> 
> Jim Fehlig maintains the libxl driver in libvirt, so you should CC him
> (I've done so here...)

Thanks.

> > The path to the pty of a Xen PV console is set only in
> > virDomainOpenConsole. But this is done too late. A call to
> > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > the pty, but a call after OpenConsole will.
> > 
> > e.g. of the current issue.
> > Starting a domain with '<console type="pty"/>'
> > Then:
> > virDomainGetXMLDesc():
> >   <devices>
> >     <console type='pty'>
> >       <target type='xen' port='0'/>
> >     </console>
> >   </devices>
> > virDomainOpenConsole()
> > virDomainGetXMLDesc():
> >   <devices>
> >     <console type='pty' tty='/dev/pts/30'>
> >       <source path='/dev/pts/30'/>
> >       <target type='xen' port='0'/>
> >     </console>
> >   </devices>
> > 
> > The patch intend to get the tty path on the first call of GetXMLDesc.
> 
> Doesn't it actually do it on domain start (which makes more sense to me
> anyway).

Just a wording issue. I meant: Have GetXMLDesc always return the path to
the tty.

> > 
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > ---
> >  src/libxl/libxl_domain.c | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > index 9c62291..de56054 100644
> > --- a/src/libxl/libxl_domain.c
> > +++ b/src/libxl/libxl_domain.c
> > @@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> >          goto cleanup_dom;
> >  
> > +    if (vm->def->nconsoles) {
> > +        virDomainChrDefPtr chr = NULL;
> > +        chr = vm->def->consoles[0];
> > +        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
> > +            libxl_console_type console_type;
> > +            char *console = NULL;
> > +            console_type =
> > +                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
> > +                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
> > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
> > +                                        console_type, &console);
> > +            if (!ret)
> > +                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
> 
> libxlDomainOpenConsole will strdup another (well, probably the same)
> value here, causing a leak I think, so you'll need some check there too
> I expect.

So, if OpenConsole is call twice, there will also be a leak? Or maybe it
can not be called twice.

Anyway, I though from the use of VIR_STRDUP there that it was safe to
call VIR_STRDUP several times and it well free the destination. I might
be wrong.

> > +            VIR_FREE(console);
> > +        }
> > +    }
> > +
> >      if (!start_paused) {
> >          libxl_domain_unpause(priv->ctx, domid);
> >          virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED);

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 15:11:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XxzyD-0004Vn-7k; Mon, 08 Dec 2014 15:11:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XxzyB-0004Vi-PA
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:11:27 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	B1/49-29352-F9FB5845; Mon, 08 Dec 2014 15:11:27 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418051484!12206342!1
X-Originating-IP: [66.165.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 30640 invoked from network); 8 Dec 2014 15:11: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;
	8 Dec 2014 15:11:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201825625"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 10:11:07 -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 1Xxzxr-0003GX-JE;
	Mon, 08 Dec 2014 15:11:07 +0000
Date: Mon, 8 Dec 2014 15:11:07 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141208151107.GB1900@perard.uk.xensource.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
	<1418039984.30016.15.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418039984.30016.15.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Set path to console on domain
	startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 11:59:44AM +0000, Ian Campbell wrote:
> On Fri, 2014-12-05 at 16:30 +0000, Anthony PERARD wrote:
> 
> Jim Fehlig maintains the libxl driver in libvirt, so you should CC him
> (I've done so here...)

Thanks.

> > The path to the pty of a Xen PV console is set only in
> > virDomainOpenConsole. But this is done too late. A call to
> > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > the pty, but a call after OpenConsole will.
> > 
> > e.g. of the current issue.
> > Starting a domain with '<console type="pty"/>'
> > Then:
> > virDomainGetXMLDesc():
> >   <devices>
> >     <console type='pty'>
> >       <target type='xen' port='0'/>
> >     </console>
> >   </devices>
> > virDomainOpenConsole()
> > virDomainGetXMLDesc():
> >   <devices>
> >     <console type='pty' tty='/dev/pts/30'>
> >       <source path='/dev/pts/30'/>
> >       <target type='xen' port='0'/>
> >     </console>
> >   </devices>
> > 
> > The patch intend to get the tty path on the first call of GetXMLDesc.
> 
> Doesn't it actually do it on domain start (which makes more sense to me
> anyway).

Just a wording issue. I meant: Have GetXMLDesc always return the path to
the tty.

> > 
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > ---
> >  src/libxl/libxl_domain.c | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > index 9c62291..de56054 100644
> > --- a/src/libxl/libxl_domain.c
> > +++ b/src/libxl/libxl_domain.c
> > @@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> >          goto cleanup_dom;
> >  
> > +    if (vm->def->nconsoles) {
> > +        virDomainChrDefPtr chr = NULL;
> > +        chr = vm->def->consoles[0];
> > +        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
> > +            libxl_console_type console_type;
> > +            char *console = NULL;
> > +            console_type =
> > +                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
> > +                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
> > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
> > +                                        console_type, &console);
> > +            if (!ret)
> > +                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
> 
> libxlDomainOpenConsole will strdup another (well, probably the same)
> value here, causing a leak I think, so you'll need some check there too
> I expect.

So, if OpenConsole is call twice, there will also be a leak? Or maybe it
can not be called twice.

Anyway, I though from the use of VIR_STRDUP there that it was safe to
call VIR_STRDUP several times and it well free the destination. I might
be wrong.

> > +            VIR_FREE(console);
> > +        }
> > +    }
> > +
> >      if (!start_paused) {
> >          libxl_domain_unpause(priv->ctx, domid);
> >          virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED);

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 15:14:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15:14:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy01B-0004sR-TX; Mon, 08 Dec 2014 15:14:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xy01A-0004sL-Jj
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:14:32 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	00/EF-02576-750C5845; Mon, 08 Dec 2014 15:14:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418051668!13733730!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 1076 invoked from network); 8 Dec 2014 15:14:29 -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;
	8 Dec 2014 15:14:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201827258"
Message-ID: <1418051666.2827.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 8 Dec 2014 15:14:26 +0000
In-Reply-To: <20141208151107.GB1900@perard.uk.xensource.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
	<1418039984.30016.15.camel@citrix.com>
	<20141208151107.GB1900@perard.uk.xensource.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>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-08 at 15:11 +0000, Anthony PERARD wrote:
> > > The patch intend to get the tty path on the first call of GetXMLDesc.
> > 
> > Doesn't it actually do it on domain start (which makes more sense to me
> > anyway).
> 
> Just a wording issue. I meant: Have GetXMLDesc always return the path to
> the tty.
> 

Ah, yes, I get what you meant now.

> > > 
> > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > > ---
> > >  src/libxl/libxl_domain.c | 17 +++++++++++++++++
> > >  1 file changed, 17 insertions(+)
> > > 
> > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > index 9c62291..de56054 100644
> > > --- a/src/libxl/libxl_domain.c
> > > +++ b/src/libxl/libxl_domain.c
> > > @@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> > >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > >          goto cleanup_dom;
> > >  
> > > +    if (vm->def->nconsoles) {
> > > +        virDomainChrDefPtr chr = NULL;
> > > +        chr = vm->def->consoles[0];
> > > +        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
> > > +            libxl_console_type console_type;
> > > +            char *console = NULL;
> > > +            console_type =
> > > +                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
> > > +                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
> > > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
> > > +                                        console_type, &console);
> > > +            if (!ret)
> > > +                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
> > 
> > libxlDomainOpenConsole will strdup another (well, probably the same)
> > value here, causing a leak I think, so you'll need some check there too
> > I expect.
> 
> So, if OpenConsole is call twice, there will also be a leak? Or maybe it
> can not be called twice.

I'm not sure, there may be an existing issue here I suppose.

> Anyway, I though from the use of VIR_STRDUP there that it was safe to
> call VIR_STRDUP several times and it well free the destination. I might
> be wrong.

I wondered about that, but AFAICS VIR_STRDUP is a wrapper around
virStrdup and virStrdup doesn't free any existing destination.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 15:14:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15:14:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy01B-0004sR-TX; Mon, 08 Dec 2014 15:14:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xy01A-0004sL-Jj
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:14:32 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	00/EF-02576-750C5845; Mon, 08 Dec 2014 15:14:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418051668!13733730!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 1076 invoked from network); 8 Dec 2014 15:14:29 -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;
	8 Dec 2014 15:14:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201827258"
Message-ID: <1418051666.2827.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 8 Dec 2014 15:14:26 +0000
In-Reply-To: <20141208151107.GB1900@perard.uk.xensource.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
	<1418039984.30016.15.camel@citrix.com>
	<20141208151107.GB1900@perard.uk.xensource.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>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-08 at 15:11 +0000, Anthony PERARD wrote:
> > > The patch intend to get the tty path on the first call of GetXMLDesc.
> > 
> > Doesn't it actually do it on domain start (which makes more sense to me
> > anyway).
> 
> Just a wording issue. I meant: Have GetXMLDesc always return the path to
> the tty.
> 

Ah, yes, I get what you meant now.

> > > 
> > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > > ---
> > >  src/libxl/libxl_domain.c | 17 +++++++++++++++++
> > >  1 file changed, 17 insertions(+)
> > > 
> > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > index 9c62291..de56054 100644
> > > --- a/src/libxl/libxl_domain.c
> > > +++ b/src/libxl/libxl_domain.c
> > > @@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> > >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > >          goto cleanup_dom;
> > >  
> > > +    if (vm->def->nconsoles) {
> > > +        virDomainChrDefPtr chr = NULL;
> > > +        chr = vm->def->consoles[0];
> > > +        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
> > > +            libxl_console_type console_type;
> > > +            char *console = NULL;
> > > +            console_type =
> > > +                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
> > > +                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
> > > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
> > > +                                        console_type, &console);
> > > +            if (!ret)
> > > +                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
> > 
> > libxlDomainOpenConsole will strdup another (well, probably the same)
> > value here, causing a leak I think, so you'll need some check there too
> > I expect.
> 
> So, if OpenConsole is call twice, there will also be a leak? Or maybe it
> can not be called twice.

I'm not sure, there may be an existing issue here I suppose.

> Anyway, I though from the use of VIR_STRDUP there that it was safe to
> call VIR_STRDUP several times and it well free the destination. I might
> be wrong.

I wondered about that, but AFAICS VIR_STRDUP is a wrapper around
virStrdup and virStrdup doesn't free any existing destination.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 15:19:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15:19:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy05a-00052P-KF; Mon, 08 Dec 2014 15:19:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xy05Z-00052K-2f
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:19:05 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	F4/6A-28296-861C5845; Mon, 08 Dec 2014 15:19:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418051943!11842585!1
X-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 14228 invoked from network); 8 Dec 2014 15:19:03 -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; 8 Dec 2014 15:19:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 15:19:03 +0000
Message-Id: <5485CF74020000780004DD52@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 15:19:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<5481E39B020000780004D450@mail.emea.novell.com>
	<5481E564020000780004D47B@mail.emea.novell.com>
	<5481E6FC.1070905@oracle.com>
	<54857061020000780004D999@mail.emea.novell.com>
	<5485BC13.3030403@oracle.com>
In-Reply-To: <5485BC13.3030403@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 08.12.14 at 15:56, <boris.ostrovsky@oracle.com> wrote:

>>>> Additionally please add IN and OUT annotations. When I first saw
>>>> this I assumed they would all be OUT (in which case the long running
>>>> loop problem mentioned in the reply to one of the other patches
>>>> wouldn't have been there), matching their CPU counterpart...
>>> I don't follow this. Are you saying that if ti->max_devs in patch 3/4 is
>>> an IN (which it is) then we don't have to guard for long-running loops?
>> If they were all OUT then there wouldn't be a way for the entire
>> operation to be fooled into going over more devices than there are
>> in the system.
> 
> Assuming I add continuations to the loop, too many devices wouldn't be a 
> problem for the hypervisor, would it? If an unreasonable number is 
> provided then eventually copy_from_guest() will fault.

Continuations would address the concern, but it doesn't seem like
their use is really warranted 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 Dec 08 15:19:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15:19:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy05a-00052P-KF; Mon, 08 Dec 2014 15:19:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xy05Z-00052K-2f
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:19:05 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	F4/6A-28296-861C5845; Mon, 08 Dec 2014 15:19:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418051943!11842585!1
X-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 14228 invoked from network); 8 Dec 2014 15:19:03 -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; 8 Dec 2014 15:19:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 15:19:03 +0000
Message-Id: <5485CF74020000780004DD52@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 15:19:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>
	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>
	<5481E39B020000780004D450@mail.emea.novell.com>
	<5481E564020000780004D47B@mail.emea.novell.com>
	<5481E6FC.1070905@oracle.com>
	<54857061020000780004D999@mail.emea.novell.com>
	<5485BC13.3030403@oracle.com>
In-Reply-To: <5485BC13.3030403@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 08.12.14 at 15:56, <boris.ostrovsky@oracle.com> wrote:

>>>> Additionally please add IN and OUT annotations. When I first saw
>>>> this I assumed they would all be OUT (in which case the long running
>>>> loop problem mentioned in the reply to one of the other patches
>>>> wouldn't have been there), matching their CPU counterpart...
>>> I don't follow this. Are you saying that if ti->max_devs in patch 3/4 is
>>> an IN (which it is) then we don't have to guard for long-running loops?
>> If they were all OUT then there wouldn't be a way for the entire
>> operation to be fooled into going over more devices than there are
>> in the system.
> 
> Assuming I add continuations to the loop, too many devices wouldn't be a 
> problem for the hypervisor, would it? If an unreasonable number is 
> provided then eventually copy_from_guest() will fault.

Continuations would address the concern, but it doesn't seem like
their use is really warranted 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 Dec 08 15:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15: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 1Xy0Gm-0005Pk-Pz; Mon, 08 Dec 2014 15:30:40 +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 1Xy0Gl-0005Pf-CP
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:30:39 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	1A/A1-28296-E14C5845; Mon, 08 Dec 2014 15:30:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418052636!11828391!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 13440 invoked from network); 8 Dec 2014 15:30:37 -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;
	8 Dec 2014 15:30:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201836097"
Message-ID: <5485C3FB.2030402@citrix.com>
Date: Mon, 8 Dec 2014 15:30:03 +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>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>	<5481E39B020000780004D450@mail.emea.novell.com>	<5481E564020000780004D47B@mail.emea.novell.com>	<5481E6FC.1070905@oracle.com>	<54857061020000780004D999@mail.emea.novell.com>	<5485BC13.3030403@oracle.com>
	<5485CF74020000780004DD52@mail.emea.novell.com>
In-Reply-To: <5485CF74020000780004DD52@mail.emea.novell.com>
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 08/12/14 15:19, Jan Beulich wrote:
>>>> On 08.12.14 at 15:56, <boris.ostrovsky@oracle.com> wrote:
>>>>> Additionally please add IN and OUT annotations. When I first saw
>>>>> this I assumed they would all be OUT (in which case the long running
>>>>> loop problem mentioned in the reply to one of the other patches
>>>>> wouldn't have been there), matching their CPU counterpart...
>>>> I don't follow this. Are you saying that if ti->max_devs in patch 3/4 is
>>>> an IN (which it is) then we don't have to guard for long-running loops?
>>> If they were all OUT then there wouldn't be a way for the entire
>>> operation to be fooled into going over more devices than there are
>>> in the system.
>> Assuming I add continuations to the loop, too many devices wouldn't be a 
>> problem for the hypervisor, would it? If an unreasonable number is 
>> provided then eventually copy_from_guest() will fault.
> Continuations would address the concern, but it doesn't seem like
> their use is really warranted here.

It depends.  I have one server I have to hand looks like:

[root@mpx1 ~]# lspci | wc -l
1759

(And I believe this one isn't fully populated with devices.)

A continuation is possibly warranted in a case like this, particularly
if an HVM domain is making this hypercall.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 15:31:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15: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 1Xy0Gm-0005Pk-Pz; Mon, 08 Dec 2014 15:30:40 +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 1Xy0Gl-0005Pf-CP
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:30:39 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	1A/A1-28296-E14C5845; Mon, 08 Dec 2014 15:30:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418052636!11828391!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 13440 invoked from network); 8 Dec 2014 15:30:37 -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;
	8 Dec 2014 15:30:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201836097"
Message-ID: <5485C3FB.2030402@citrix.com>
Date: Mon, 8 Dec 2014 15:30:03 +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>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>
References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com>	<1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com>	<5481E39B020000780004D450@mail.emea.novell.com>	<5481E564020000780004D47B@mail.emea.novell.com>	<5481E6FC.1070905@oracle.com>	<54857061020000780004D999@mail.emea.novell.com>	<5485BC13.3030403@oracle.com>
	<5485CF74020000780004DD52@mail.emea.novell.com>
In-Reply-To: <5485CF74020000780004DD52@mail.emea.novell.com>
X-DLP: MIA2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] sysctl/libxl: Add interface for
 returning IO topology 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 08/12/14 15:19, Jan Beulich wrote:
>>>> On 08.12.14 at 15:56, <boris.ostrovsky@oracle.com> wrote:
>>>>> Additionally please add IN and OUT annotations. When I first saw
>>>>> this I assumed they would all be OUT (in which case the long running
>>>>> loop problem mentioned in the reply to one of the other patches
>>>>> wouldn't have been there), matching their CPU counterpart...
>>>> I don't follow this. Are you saying that if ti->max_devs in patch 3/4 is
>>>> an IN (which it is) then we don't have to guard for long-running loops?
>>> If they were all OUT then there wouldn't be a way for the entire
>>> operation to be fooled into going over more devices than there are
>>> in the system.
>> Assuming I add continuations to the loop, too many devices wouldn't be a 
>> problem for the hypervisor, would it? If an unreasonable number is 
>> provided then eventually copy_from_guest() will fault.
> Continuations would address the concern, but it doesn't seem like
> their use is really warranted here.

It depends.  I have one server I have to hand looks like:

[root@mpx1 ~]# lspci | wc -l
1759

(And I believe this one isn't fully populated with devices.)

A continuation is possibly warranted in a case like this, particularly
if an HVM domain is making this hypercall.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 15:40:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15: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 1Xy0Q8-0005nN-1Y; Mon, 08 Dec 2014 15:40:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jtomko@redhat.com>) id 1Xy0Q6-0005nI-J8
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:40:18 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	92/B6-26740-166C5845; Mon, 08 Dec 2014 15:40:17 +0000
X-Env-Sender: jtomko@redhat.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418053215!11854022!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25870 invoked from network); 8 Dec 2014 15:40:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 15:40:17 -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 sB8FeAPV027582
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 8 Dec 2014 10:40:11 -0500
Received: from [10.34.129.182] ([10.34.129.182])
	by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB8Fe7IT016892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 8 Dec 2014 10:40:08 -0500
Message-ID: <5485C654.7030503@redhat.com>
Date: Mon, 08 Dec 2014 16:40:04 +0100
From: =?ISO-8859-1?Q?J=E1n_Tomko?= <jtomko@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.8.0
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>, libvir-list@redhat.com
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
X-Enigmail-Version: 1.6
OpenPGP: id=74FF0269
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH] libxl: Set path to console on
	domain startup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1030475881297333872=="
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)
--===============1030475881297333872==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="kOCt4G4TwdwAkMiRseHMVPwhfwHFaF6HW"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--kOCt4G4TwdwAkMiRseHMVPwhfwHFaF6HW
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 12/05/2014 05:30 PM, Anthony PERARD wrote:
> Hi,
>=20
> I'm trying to fix an issue when using OpenStack with libvirt+xen (libxe=
nlight).
> OpenStack cannot access the console output of a Xen PV guest, because t=
he XML
> generated by libvirt for a domain is missing the path to the pty. The p=
ath
> actually appear in the XML once one call virDomainOpenConsole().
>=20
> The patch intend to get the path to the pty without having to call
> virDomainOpenConsole, so I've done the work in libxlDomainStart(). So I=
 have a
> few question:
> Is libxlDomainStart will be called on restore/migrate/reboot?
> I guest the function libxlDomainOpenConsole() would not need to do the =
same
> work if the console path is settup properly.
>=20
> There is a bug report about this:
> https://bugzilla.redhat.com/show_bug.cgi?id=3D1170743
>=20

Hi,

you can leave the bugzilla link in the commit message, if somebody ever n=
eeds
more context.

(And the patch looks good to me, but I'm no libxl expert)

Jan

> Regards,
>=20
> Anthony PERARD (1):
>   libxl: Set path to console on domain startup.
>=20
>  src/libxl/libxl_domain.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>=20



--kOCt4G4TwdwAkMiRseHMVPwhfwHFaF6HW
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

iQIcBAEBAgAGBQJUhcZXAAoJEMr6XT10/wJpSM0P/iW3gq31fF+yXHKO0mIrjsyj
fFTID334byHBW48yMGFsTlR3xdYhNJUgLmOsVdn4NAwlnI8ffFSaH88Q0oebOdlp
MDy4mVYlZX8kb5gTL8tE3t2hvX++x4c8NjxKtkYbpLW/UzERbp4Q56+2qx9mJhWy
N1Y3jmkh8rmoZXDm5B3jSn9GpicmloR2T+VJwbXF9k3zaKApHl7ecDEynqQUcDFK
YzoruXb114F6wcLwNu92Y3zeL1jW5zSOhsfXUfoEUjgtBZRlHE9EKJ376kUa2bqQ
8pKKnilL0Sjgi12GVlT+79XUa36k8w/7xuBIzWGMiNzTNQEgR5zKaxOdft2/S37U
WMjHHBTWvBqo29iZAr7pVW3PYMd+rWCLR/FkA1EkFvOYXXLNPpgGvj2mLZsE3tfB
10M+pbVZOsiQXqe5X5+e/0zDTR2alq6pjQl6YlfmktZ8eFVDs/ESfiFk6dsG0kIU
l/4aSVBKtUjTbI9/P01HQbOq9aOnnAp2UXCCavZRkv0B9rA4D0+U6z+v2BtyZUVO
QY6eNL9Rvm5HpTsCTyx58jgbNCV1aRmgUAXieHENyKMpi5pfKFFPXdrUHEHr6oGC
/iymt86rdAbnbFDh0RS64Kv8ZhS/SUUe/T6aD5/y/RXaB8yHu00RNoNBrJUsD5bu
f0tTGPPN68L8ampdnd99
=y2Ba
-----END PGP SIGNATURE-----

--kOCt4G4TwdwAkMiRseHMVPwhfwHFaF6HW--


--===============1030475881297333872==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1030475881297333872==--


From xen-devel-bounces@lists.xen.org Mon Dec 08 15:40:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15: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 1Xy0Q8-0005nN-1Y; Mon, 08 Dec 2014 15:40:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jtomko@redhat.com>) id 1Xy0Q6-0005nI-J8
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:40:18 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	92/B6-26740-166C5845; Mon, 08 Dec 2014 15:40:17 +0000
X-Env-Sender: jtomko@redhat.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418053215!11854022!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25870 invoked from network); 8 Dec 2014 15:40:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 15:40:17 -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 sB8FeAPV027582
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 8 Dec 2014 10:40:11 -0500
Received: from [10.34.129.182] ([10.34.129.182])
	by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sB8Fe7IT016892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 8 Dec 2014 10:40:08 -0500
Message-ID: <5485C654.7030503@redhat.com>
Date: Mon, 08 Dec 2014 16:40:04 +0100
From: =?ISO-8859-1?Q?J=E1n_Tomko?= <jtomko@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.8.0
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>, libvir-list@redhat.com
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
X-Enigmail-Version: 1.6
OpenPGP: id=74FF0269
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH] libxl: Set path to console on
	domain startup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1030475881297333872=="
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)
--===============1030475881297333872==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="kOCt4G4TwdwAkMiRseHMVPwhfwHFaF6HW"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--kOCt4G4TwdwAkMiRseHMVPwhfwHFaF6HW
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 12/05/2014 05:30 PM, Anthony PERARD wrote:
> Hi,
>=20
> I'm trying to fix an issue when using OpenStack with libvirt+xen (libxe=
nlight).
> OpenStack cannot access the console output of a Xen PV guest, because t=
he XML
> generated by libvirt for a domain is missing the path to the pty. The p=
ath
> actually appear in the XML once one call virDomainOpenConsole().
>=20
> The patch intend to get the path to the pty without having to call
> virDomainOpenConsole, so I've done the work in libxlDomainStart(). So I=
 have a
> few question:
> Is libxlDomainStart will be called on restore/migrate/reboot?
> I guest the function libxlDomainOpenConsole() would not need to do the =
same
> work if the console path is settup properly.
>=20
> There is a bug report about this:
> https://bugzilla.redhat.com/show_bug.cgi?id=3D1170743
>=20

Hi,

you can leave the bugzilla link in the commit message, if somebody ever n=
eeds
more context.

(And the patch looks good to me, but I'm no libxl expert)

Jan

> Regards,
>=20
> Anthony PERARD (1):
>   libxl: Set path to console on domain startup.
>=20
>  src/libxl/libxl_domain.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>=20



--kOCt4G4TwdwAkMiRseHMVPwhfwHFaF6HW
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

iQIcBAEBAgAGBQJUhcZXAAoJEMr6XT10/wJpSM0P/iW3gq31fF+yXHKO0mIrjsyj
fFTID334byHBW48yMGFsTlR3xdYhNJUgLmOsVdn4NAwlnI8ffFSaH88Q0oebOdlp
MDy4mVYlZX8kb5gTL8tE3t2hvX++x4c8NjxKtkYbpLW/UzERbp4Q56+2qx9mJhWy
N1Y3jmkh8rmoZXDm5B3jSn9GpicmloR2T+VJwbXF9k3zaKApHl7ecDEynqQUcDFK
YzoruXb114F6wcLwNu92Y3zeL1jW5zSOhsfXUfoEUjgtBZRlHE9EKJ376kUa2bqQ
8pKKnilL0Sjgi12GVlT+79XUa36k8w/7xuBIzWGMiNzTNQEgR5zKaxOdft2/S37U
WMjHHBTWvBqo29iZAr7pVW3PYMd+rWCLR/FkA1EkFvOYXXLNPpgGvj2mLZsE3tfB
10M+pbVZOsiQXqe5X5+e/0zDTR2alq6pjQl6YlfmktZ8eFVDs/ESfiFk6dsG0kIU
l/4aSVBKtUjTbI9/P01HQbOq9aOnnAp2UXCCavZRkv0B9rA4D0+U6z+v2BtyZUVO
QY6eNL9Rvm5HpTsCTyx58jgbNCV1aRmgUAXieHENyKMpi5pfKFFPXdrUHEHr6oGC
/iymt86rdAbnbFDh0RS64Kv8ZhS/SUUe/T6aD5/y/RXaB8yHu00RNoNBrJUsD5bu
f0tTGPPN68L8ampdnd99
=y2Ba
-----END PGP SIGNATURE-----

--kOCt4G4TwdwAkMiRseHMVPwhfwHFaF6HW--


--===============1030475881297333872==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1030475881297333872==--


From xen-devel-bounces@lists.xen.org Mon Dec 08 15:47:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15:47:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy0Wm-0006AR-6T; Mon, 08 Dec 2014 15:47: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 1Xy0Wl-0006AM-Be
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:47:11 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	91/11-25276-EF7C5845; Mon, 08 Dec 2014 15:47:10 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418053628!14162160!1
X-Originating-IP: [209.85.220.176]
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 2428 invoked from network); 8 Dec 2014 15:47:09 -0000
Received: from mail-vc0-f176.google.com (HELO mail-vc0-f176.google.com)
	(209.85.220.176)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 15:47:09 -0000
Received: by mail-vc0-f176.google.com with SMTP id hq12so2209997vcb.21
	for <xen-devel@lists.xen.org>; Mon, 08 Dec 2014 07:47:08 -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:cc:content-type;
	bh=GlOW19dSWPFscXRWXfcycQDB8U0vK+jQ/UWGX4BM4h0=;
	b=CYt7/fBZ4faTfjM+Sbh0mz4/nHk45pumpEix0ByVrOr2k8s+/GmpusukbqdCUqmpNg
	dySaw7IwR17AHDhA4jVX3weLtc9/2Q0dGJToLrqr4/YhHkisGlWuvIHi7qiUxZkr4pQ8
	yTQFqUXqhbGYPKgXsAwjSNHYahADuBHoXVXm+Jz4ZV/TK675po8RU0d7mR8VXgg6Y8qa
	qKDR6XfldoDLDrtB4vUOKQRYmQRA5nsuSG9ix0MYI7dwL5WN6EJQIwJEJXaCDqpTKArV
	cvSljgT/4jQ/a9Y/ERjsNpe69xzQ8RBR9fcyBi3AobwNKFFqRjdWRtxhcN2qhV4Np+t9
	UqVQ==
MIME-Version: 1.0
X-Received: by 10.52.29.84 with SMTP id i20mr20969989vdh.1.1418053628134; Mon,
	08 Dec 2014 07:47:08 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Mon, 8 Dec 2014 07:47:08 -0800 (PST)
Date: Mon, 8 Dec 2014 15:47:08 +0000
Message-ID: <CAHt6W4da7s=UcxucNnfYvWD8cMvVHSuQUiYWPTNu_V7X1ejq9w@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.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>
Content-Type: multipart/mixed; boundary=20cf307cff10c7241f0509b65662
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] Porting 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--20cf307cff10c7241f0509b65662
Content-Type: text/plain; charset=UTF-8

Hi,
  while I was porting D01 platform
(https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
trying to describe the step I made and problems I encountered hoping
it could useful to other people. The idea is to put such documentation
in a wiki page or in the docs directory.

Let me know what do you think.

Regards,
  Frediano

--20cf307cff10c7241f0509b65662
Content-Type: text/plain; charset=US-ASCII; name="porting.txt"
Content-Disposition: attachment; filename="porting.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i3g0hry30

UG9ydGluZyBhIG5ldyBBUk0gcGxhdGZvcm0gdG8gWGVuCj09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PQoKQVJNIHBsYXRmb3JtcyBhcmUgcXVpdGUgZGlmZmVyZW50IG9uZSBmcm9tIGVh
Y2ggYW5vdGhlci4gVGhpcyBjYW4gYWZmZWN0IFhlbgpwb3J0aW5nOgotIGludGVycnVwdCBjb250
cm9sbGVyIChHSUMgb24gQVJNKSBoYXZlIGRpZmZlcmVudCB2ZXJzaW9uOwotIGludGVycnVwdHMg
bnVtYmVycyBkb2VzIG5vdCBoYXZlIG1hbnkgc3RhbmRhcmRzIChiZXNpZGUgQ1BVIG9uZXMgY2Fs
bGVkIFNHSXMpOwotIGV2ZXJ5IHBsYXRmb3JtcyBoYXZlIGRpZmZlcmVudCBhZGRyZXNzZXMgZm9y
IGRldmljZXM7Ci0gZGV2aWNlcyBsaXN0IGNhbiBiZSBxdWl0ZSBkaWZmZXJlbnQuCgpBcyBhIHN0
YXJ0IHlvdSBzaG91bGQgcmVhZCBwYWdlcyBbMV0gYW5kIFsyXSBmcm9tIHRoZSB3aWtpLgoKT25l
IGNvbmNlcHQgeW91IGhhdmUgdG8gbGVhcm4gaXMgKGF0IGxlYXN0IGN1cnJlbnRseSkgdGhlIGRl
dmljZSB0cmVlIChEVCBmb3IKc2hvcnQsIHdoaWNoIGNhbiBiZSBmb3VuZCBhcyBzb3VyY2UgaW4g
LmR0cyBmaWxlcyBpbiBhcmNoL2FybS9ib290L2R0cyBMaW51eApkaXJlY3RvcnksIC5mZHQgb3Ig
LmR0YiBmb3IgY29tcGlsZWQgdmVyc2lvbnMpLgpEZXZpY2UgdHJlZSBpcyBhIHNwZWNpZmljYXRp
b24gdGhhdCBhbGxvdyB0byBkZXNjcmliZSBkZXZpY2UgY29uZmlndXJhdGlvbnMuIEFzCmRldmlj
ZSBsaXN0IGlzIG5vdCBzdGFuZGFyZCBEVCBjb250YWlucyBkZXNjcmlwdGlvbiBvZiBhbGwgZGV2
aWNlcyBmcm9tIG1lbW9yeQp0byBDUFVzLCBzeXN0ZW0gYm9hcmQsIElPIGRldmljZXMgYW5kIHNv
IG9uLiBJbmZvcm1hdGlvbiBjYW4gYmUgSS9PIHJhbmdlcyAoaW4KQVJNIEkvTyBpcyBtZW1vcnkg
bWFwcGVkIHNvIHRoZXJlIGFyZSBub3QgdGhlIHBvcnQgY29uY2VwdCB5b3UgY2FuIGZpbmQgb24K
SW50ZWwpLCBpbnRlcnJ1cHRzLCBkZXZpY2UgdHlwZSwgY2xvY2sgYXR0YWNoZWQgYW5kIG1hbnkg
bW9yZS4gRFQgc3BlY2lmaWNhdGlvbgphcmUgcXVpdGUgZXh0ZW5zaWJsZSBhbmQgYWxsb3cgZm9y
IGluc3RhbmNlIHRvIGhhdmUgaW5mb3JtYXRpb24gbGlrZSBrZXJuZWwKY29tbWFuZCBsaW5lIHRv
by4gWW91IGNhbiBmaW5kIHF1aXRlIGEgbG90IG9mIGluZm9ybWF0aW9uIG9uIERUIGluCkRvY3Vt
ZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncyBMaW51eCBkaXJlY3RvcnkgKHNwZWNpZmljYWxs
eSB0aGVyZSBpcyBhbiBhcm0Kc3ViLWRpcmVjdG9yeSkuCgpBbm90aGVyIGJpZyBkaWZmZXJlbmNl
IGlzIHRoZSBib290IHByb2Nlc3MuIFVuZm9ydHVuYXRlbHkgaXMgbm90IHN0aWxsIHdlbGwKZGVm
aW5lZCBhcyBJbnRlbCBvbmUuIEZvciBpbnN0YW5jZSBYZW4gdXNlIG11bHRpYm9vdCBidXQgbXVs
dGlib290IGlzIG5vdCBzdGlsbApzdGFuZGFyZCBvbiBBUk0gc28gY2FuIGJlIHF1aXRlIHBhaW5m
dWwuCgpIYXBwaWx5IFhlbiByZXF1aXJlIHZlcnkgZmV3IGRldmljZXMgaW4gb3JkZXIgdG8gd29y
aywgYXMgc3RhdGVkIGluIFsyXToKLSBHSUM7Ci0gZ2VuZXJpYyB0aW1lcnM7Ci0gU01NVTsKLSBv
bmUgVUFSVC4KCk5vdywgZm9ydHVuYXRlbHkgdGltZXJzIGFyZSBub3cgcXVpdGUgc3RhbmRhcmQg
YW5kIHRoZSBpbnRlcmZhY2UgdG8gdXNlIHRoZW0KdXNlIENQVSByZWdpc3RlcnMuCgoKVUFSVAot
LS0tCgpVQVJUIGlzIHRoZSBmaXJzdCBkZXZpY2UgeW91IHNob3VsZCBpbXBsZW1lbnQuIFRoZSBy
ZWFzb24gaXMgc2ltcGxlLCBpdCBhbGxvd3MKeW91IHRvIHNlZSBzb21ldGhpbmcgZnJvbSB0aGUg
YmVnaW5uaW5nISAgRm9ydHVuYXRlbHkgYSBsb3Qgb2YgYm9hcmRzIGltcGxlbWVudAp0aGUgc3Rh
bmRhcmQgKG9yIGNvbXBhdGlibGUpIDgyNTAuIEF0IHRoZSBiZWdpbm5pbmcgeW91IHNob3VsZCB0
cnkgdG8gbWFrZSB0aGUKImVhcmx5IHByaW50ayIgd29yay4gRWFybHkgcHJpbnRrIGlzIGluaXRp
YWxpc2VkIHZlcnkgc29vbiAoanVzdCBhZnRlciBmZXcKYXNzZW1ibHkgbGluZXMpLiBJZiB5b3Ug
aGF2ZSBhIGRyaXZlciBhbGwgeW91IG5lZWQgaXMgdG8gc2V0dXAgbWVtb3J5IHJhbmdlcyBhbmQK
ZGV2aWNlIHR5cGUgYW5kIGJvb3QgWGVuLgoKVG8gbWFrZSBvdXIgVUFSVCB3b3JrIEkganVzdCBk
aWQgdGhpcyBjaGFuZ2UgdG8geGVuL2FyY2gvYXJtL1J1bGVzLm1rCihjaGFuZ2VzZXQgNWFkNzFh
NmVlZmM5YjA5ZmU3NDU4ZGVkNWI4NmI2OWZjYzU3NDM2Yyk6CgogICBFQVJMWV9QUklOVEtfQkFV
RCA6PSAxMTUyMDAKICAgRUFSTFlfVUFSVF9CQVNFX0FERFJFU1MgOj0gMHg3ZmY4MDAwMAogICBl
bmRpZgogICtpZmVxICgkKENPTkZJR19FQVJMWV9QUklOVEspLCBoaXAwNC1kMDEpCiAgK0VBUkxZ
X1BSSU5US19JTkMgOj0gODI1MAogICtFQVJMWV9QUklOVEtfQkFVRCA6PSAxMTUyMDAKICArRUFS
TFlfVUFSVF9CQVNFX0FERFJFU1MgOj0gMHhFNDAwNzAwMAogICtFQVJMWV9VQVJUX1JFR19TSElG
VCA6PSAyCiAgK2VuZGlmCgogICBpZm5lcSAoJChFQVJMWV9QUklOVEtfSU5DKSwpCiAgIEVBUkxZ
X1BSSU5USyA6PSB5CgpUbyBlbmFibGUgZWFybHkgcHJpbnRrIChhZnRlciBpbXBsZW1lbnRpbmcg
dGhlIHJpZ2h0IGNvZGUpLCB5b3UgY2FuIGhhdmUKc29tZXRoaW5nIGxpa2UgdGhpcyBpbiB5b3Vy
IC5jb25maWc6CgogIGRlYnVnIDo9IHkKICBDT05GSUdfRUFSTFlfUFJJTlRLIDo9IGhpcDA0LWQw
MQoKKGhpcDA0LWQwMSBpcyB0aGUgc3RyaW5nIGRlY2lkZWQgZm9yIG91ciBwbGF0Zm9ybSkuCgpF
YXJseSBwcmludGsgZGV2aWNlcyBhcmUgaW1wbGVtZW50ZWQgaW4geGVuL2FyY2gvYXJtL2FybTMy
IGFuZAp4ZW4vYXJjaC9hcm0vYXJtNjQgZGlyZWN0b3JpZXMgaW4gZmlsZXMgbGlrZSBkZWJ1Zy08
TkFNRT4uaW5jLgpNb3JlIGRvY3VtZW50YXRpb24gb24gZG9jcy9taXNjL2FybS9lYXJseS1wcmlu
dGsudHh0IGZpbGUuCgoKWGVuIGJvb3RpbmcKLS0tLS0tLS0tLS0KCkFzIHNhaWQgYmVmb3JlIHN0
YXJ0aW5nIFhlbiBjYW4gYmUgcXVpdGUgdHJpY2t5LiBIb3dldmVyIHRvIHN0YXJ0IHlvdSBjYW4g
Zm9jdXMKb24ganVzdCB0aGUgaHlwZXJ2aXNvci4gIElmIHlvdSBjYW4gYm9vdCBMaW51eCAoYW5k
IHlvdSByZWFsbHkgc2hvdWxkIG1ha2UgaXQKd29yayBiZWZvcmUgdHJ5aW5nIFhlbikgeW91IGNh
biByZXBsYWNlIHRoZSBrZXJuZWwgd2l0aCB0aGUgWGVuIGh5cGVydmlzb3IKKHhlbi94ZW4gZmls
ZSkgYW5kIFhlbiB3aWxsIHN0YXJ0LiBTbyB5b3UgY2FuIHRlc3QgaWYgc2VyaWFsIGFuZCBDUFVz
IGFyZQp3b3JraW5nLgoKTm93IHRoYXQgYm9vdCBsb2FkZXIgaXMgY29uZmlndXJlZCBhbmQgVUFS
VCBpcyB3b3JraW5nIHlvdSBzaG91bGQgc2VlIFhlbgpib290aW5nIGFuZCB0cnkgdG8gZG8gc29t
ZXRoaW5nISAgQnV0IHdpdGhvdXQgdGhlIEZEVCBYZW4gd29uJ3QgZG8gbXVjaC4KCgpEVEIgZmls
ZQotLS0tLS0tLQoKWGVuIG9uIEFSTSByZXF1aXJlIGEgaW5pdGlhbCBGRFQgdGhhdCBkZXNjcmli
ZSB5b3VyIGhhcmR3YXJlIGluIG9yZGVyIHRvIGhhbmRsZQp5b3VyIHBsYXRmb3JtLiAgSWYgeW91
IHdlcmUgYWJsZSB0byBsb2FkIHRoZSBGRFQgd2hpbGUgYm9vdGluZyB0aGUgTGludXgga2VybmVs
CnlvdSBjYW4gdXNlIHRoZSBzYW1lIHdheSBhbmQgc2FtZSBGRFQuICBBbm90aGVyIHdheSAod2hp
Y2ggSSB1c2VkKSBpcyB0byBlbWJlZAp0aGUgRkRUIGZpbGUgaW50byBYZW4uIEluIG15IC5jb25m
aWcgZmlsZSBJIGhhdmUgYSBsaW5lIGxpa2UKCiAgQ09ORklHX0RUQl9GSUxFIDo9ICQoWEVOX1JP
T1QpL2hpcDA0LWQwMS5kdGIKCnRoaXMgd2lsbCBlbWJlZCBoaXAwNC1kMDEuZHRiIGZpbGUgaW50
byBYZW4gKGluIG91ciBjYXNlIHRoZSBEVEIgZmlsZSB3YXMKZ2VuZXJhdGVkIGNvbXBpbGluZyBM
aW51eCB3aGlsZSBvbiBvdGhlciBjYXNlcyBpcyBhbHJlYWR5IHByb3ZpZGVkIGJ5IHRoZQpmaXJt
d2FyZSkuCgpOb3cgd2l0aCBGRFQgc29ydGVkIG91dCB5b3Ugc2hvdWxkIHNlZSBYZW4gZG9pbmcg
c29tZSBtb3JlIHByb2dyZXNzZXMuCgpOb3RlOiBpZiB5b3UgYXJlIHVzaW5nIGVhcmx5IHByaW50
ayBhZnRlciBhIHdoaWxlIFhlbiB3aWxsIHRyeSB0byBzZXR1cCB0aGUKc2VyaWFsIGFnYWluIHVz
aW5nIHRoZSBjb21tYW5kIGxpbmUuIEluIG15IGNhc2UgZm9yIHNvbWUgcmVhc29ucyBhdCB0aGUK
YmVnaW5uaW5nIHRoaXMgc2V0dXAgY2F1c2VkIHNlcmlhbCB0byBnbyBzaWxlbnQsIHRoZSB0ZW1w
b3Jhcnkgc29sdXRpb24gaWYgdG8Kbm90IHBhc3MgYSBjb21tYW5kIGxpbmUgdG8gWGVuICh3aGlj
aCB0aGUgZGVmYXVsdCBEVCBkb2VzIG5vdCBwcm92aWRlKS4gVXNpbmcKdGhpcyB0cmljayBJIHdh
cyBhYmxlIHRvIHByb2dyZXNzIHNvbWUgbW9yZS4KClRoaXMgaXMgdGhlIGNoYW5nZSB0byBhZGQg
dGhlIFhlbiBjb21tYW5kIGxpbmUgdG8gdGhlIERUUyBJIG1hZGU6CgogICAgIGNob3NlbiB7CiAg
ICAgICBsaW51eCxpbml0cmQtc3RhcnQgPSA8MCAweDEwZDAwMDAwPjsKICAgICAgIGxpbnV4LGlu
aXRyZC1lbmQgPSA8MCAweDEyNTAwMDAwPjsKICArICAgIHhlbix4ZW4tYm9vdGFyZ3MgPSAiY29u
c29sZT1kdHVhcnQgZHR1YXJ0PXNlcmlhbDAiOwogICAgIH07CgpTZWUgZG9jcy9taXNjL2FybS9i
b290aW5nLnR4dCBhbmQgZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dCBmb3IK
bW9yZSBpbmZvcm1hdGlvbi4KCgpQbGF0Zm9ybQotLS0tLS0tLQoKVGhlIG5leHQgdGhpbmcgdGhh
dCBwcm9iYWJseSB3aWxsIGZhaWwgaXMgdGhlIHBsYXRmb3JtIHNldHRpbmcgdXAuIFRvIGluaXRp
YWxpc2UKU01QIHlvdSBuZWVkIHNvbWUgY29kZSBzcGVjaWZpYyB0byB5b3VyIHBsYXRmb3JtIHVu
IGxlc3MgeW91ciBib2FyZCBzdXBwb3J0ClBTQ0kgc3RhbmRhcmQgKHlvdSBzaG91bGQgZmluZCBz
b21lIHBzY2kgc3RyaW5nIG9uIGR0cyBmaWxlcykuIEhhcHBpbHkgb24KeGVuL2FyY2gvYXJtL3Bs
YXRmb3JtcyB0aGVyZSBhcmUgbWFueSBleGFtcGxlcy4gTWFpbmx5IHRoZSBjb2RlIHJlcXVpcmUg
c29tZQp0d2VhayBmb3Igc2V0dGluZyB1cCB0aGUgYWRkaXRpb25hbCBDUFVzLiBZb3UgY2FuIHNr
aXAgYXQgdGhlIGJlZ2lubmluZyB0aGUKcmVzdGFydCBjb2RlIGJ1dCB5b3Ugc2hvdWxkIHNvcnQg
b3V0IHByb2Nlc3NvcnMgaW5pdGlhbGlzYXRpb24uIFRoZSBvdGhlciBDUFVzCmFyZSBzdGFydGVk
IHdpdGggYSBTR0kgKFNvZnR3YXJlIEdlbmVyYXRlZCBJbnRlcnJ1cHQpIGJ1dCB5b3UgYWxzbyBu
ZWVkIHRvIHNldAp0aGUgc3RhcnQgZW50cnkgb2YgdGhlIENQVXMuIFRoaXMgaXMgbm90IHN0YW5k
YXJkIGFuZCByZXF1aXJlIHNwZWNpZmljIGNvZGUuClRvIGltcGxlbWVudCBtaW5lIEkgbG9va2Vk
IGF0IExpbnV4IHNvdXJjZXMgYW5kIGNoYW5nZXNldHMgZm9yIHRoZSBwbGF0Zm9ybS4KCgpHSUMK
LS0tCgpOb3cgaWYgeW91ciBHSUMgaXMgY29tcGF0aWJsZSB0byBzdGFuZGFyZCBvbmVzIChHSUN2
MiBvciBHSUN2MykgeW91IGNhbiBqdXN0IGFkZAp5b3VyIGNvbXBhdGlibGUgc3RyaW5nIChpdCdz
IGEgc3RyaW5nIHlvdSBmaW5kIGluIHRoZSBEVCB0byBzYXkgdGhlCmNvbXBhdGliaWxpdHkgb2Yg
ZWFjaCBkZXZpY2UpIHRvIHRoZSBsaXN0IGFuZCBYZW4gc2hvdWxkIGluaXRpYWxpc2UgYW5kIHRy
eSB0bwpsb2FkIHRoZSBrZXJuZWwuCgpUbyBhZGQgb3VyIEdJQyB0byB0aGUgR0lDdjIgbGlzdCB3
ZSBkaWQgdGhpcyBjaGFuZ2UgdG8KeGVuL2luY2x1ZGUvYXNtLWFybS9naWMuaDoKCiAgICNkZWZp
bmUgRFRfQ09NUEFUX0dJQ180MDAgICAgICAgICAgICAiYXJtLGdpYy00MDAiCiAgICNkZWZpbmUg
RFRfQ09NUEFUX0dJQ19DT1JURVhfQTE1ICAgICAiYXJtLGNvcnRleC1hMTUtZ2ljIgogICAjZGVm
aW5lIERUX0NPTVBBVF9HSUNfQ09SVEVYX0E3ICAgICAgImFybSxjb3J0ZXgtYTctZ2ljIgogICsj
ZGVmaW5lIERUX0NPTVBBVF9HSUNfSElQMDQgICAgICAgICAgImhpc2lsaWNvbixoaXAwNC1pbnRj
IgoKICAgI2RlZmluZSBEVF9NQVRDSF9HSUNfVjIgRFRfTUFUQ0hfQ09NUEFUSUJMRShEVF9DT01Q
QVRfR0lDX0NPUlRFWF9BMTUpLCBcCiAgICAgICAgICAgICAgICAgICAgICAgICAgIERUX01BVENI
X0NPTVBBVElCTEUoRFRfQ09NUEFUX0dJQ19DT1JURVhfQTcpLCBcCiAgLSAgICAgICAgICAgICAg
ICAgICAgICAgIERUX01BVENIX0NPTVBBVElCTEUoRFRfQ09NUEFUX0dJQ180MDApCiAgKyAgICAg
ICAgICAgICAgICAgICAgICAgIERUX01BVENIX0NPTVBBVElCTEUoRFRfQ09NUEFUX0dJQ180MDAp
LCBcCiAgKyAgICAgICAgICAgICAgICAgICAgICAgIERUX01BVENIX0NPTVBBVElCTEUoRFRfQ09N
UEFUX0dJQ19ISVAwNCkKCiAgICNkZWZpbmUgRFRfQ09NUEFUX0dJQ19WMyAgICAgICAgICAgICAi
YXJtLGdpYy12MyIKClVuZm9ydHVuYXRlbHkgb3VyIEdJQyB3YXMgbm90IGZ1bGx5IGNvbXBhdGli
bGUgc28gaXQgcmVxdWlyZWQgY2hhbmdlcyB0byBzb3VyY2UKKHhlbi9hcmNoL2FybS9naWMtdjIu
YykuCgoKRG9tMCBrZXJuZWwKLS0tLS0tLS0tLS0KCklmIHlvdSByZWFjaCB0aGlzIHBvaW50IHlv
dSBwdXQgdGhlIGh5cGVydmlzb3IgaW4gcGxhY2Ugb2YgdGhlIGtlcm5lbCBzbyB3aGVyZQpzaG91
bGQgWGVuIHRha2UgdGhlIGtlcm5lbCB0byBzZXR1cCBkb20wPyBSZW1lbWJlcjogWEVOIElTIE5P
VCBBIEJPT1QgTE9BREVSLiBJdApoYXMgbm8gZHJpdmVyIGZvciBkaXNrIG9yIG5ldHdvcmsgc28g
dGhlIGtlcm5lbCBtdXN0IGJlIGFscmVhZHkgaW4gbWVtb3J5LAp1c3VhbGx5IGxvYWRlZCBieSB0
aGUgYm9vdCBsb2FkZXIuIEluIG15IGNhc2UgSSB1c2VkIGFub3RoZXIgdHJpY2sgcmVwbGFjaW5n
IHRoZQppbml0cmQgd2l0aCB0aGUga2VybmVsLiBBcyB0aGUgYm9vdCBsb2FkZXIgd2FzIG5vdCB3
b3JraW5nIGZvciBtZSB0aGUgZmlybXdhcmUKdGFrZSBrZXJuZWwgYW5kIGluaXRyZCBmcm9tIHNw
ZWNpZmljIHBhcnQgb2YgYm9hcmQgZmxhc2ggbWVtb3J5LiBTbyB0aGUgdHJpY2sKd2FzOgotIGxv
YWQga2VybmVsIGludG8gaW5pdHJkIHNlY3Rpb24gb2YgZmxhc2g7Ci0gY2hhbmdlIEZEVCB0byBw
b2ludCB0byBpbml0cmQgbWVtb3J5IHBvcnRpb24gKHNhbWUgbG9jYXRpb24gdXNlZCB0byBwcm92
aWRlCiAgaW5pdHJkIHRvIGtlcm5lbCBhcmUgdXNlZCB0byBwcm92aWRlIGtlcm5lbCB0byB4ZW4p
LgoKVGhpcyBpcyB0aGUgY2hhbmdlIEkgbWFkZSBpbiBEVFMgZmlsZSB0byBwdXQgdGhlIExpbnV4
IGtlcm5lbCBpbiB0aGUgaW5pdHJkCnBhcnRpdGlvbjoKCiAgICAgY2hvc2VuIHsKICAtICAgIGxp
bnV4LGluaXRyZC1zdGFydCA9IDwwIDB4MTBkMDAwMDA+OwogIC0gICAgbGludXgsaW5pdHJkLWVu
ZCA9IDwwIDB4MTI1MDAwMDA+OwogICsgICAgI2FkZHJlc3MtY2VsbHMgPSA8MT47CiAgKyAgICAj
c2l6ZS1jZWxscyA9IDwxPjsKICArCiAgKyAgICB4ZW4seGVuLWJvb3RhcmdzID0gImNvbnNvbGU9
ZHR1YXJ0IGR0dWFydD1zZXJpYWwwIjsKICArICAgIHhlbixkb20wLWJvb3RhcmdzID0gImNvbnNv
bGU9aHZjMCBlYXJseXByaW50ayByb290PS9kZXYvc2RhMiBydyBsb2dsZXZlbD03IjsKICArICAg
IG1vZHVsZUAweDEwZDAwMDAwIHsKICArICAgICAgICBjb21wYXRpYmxlID0gInhlbixsaW51eC1r
ZXJuZWwiLCAieGVuLG11bHRpYm9vdC1tb2R1bGUiOwogICsgICAgICAgIHJlZyA9IDwweDEwZDAw
MDAwIDB4MzAwMDAwPjsKICArICAgIH07CiAgICAgfTsKCkFzIHlvdSBjYW4gc2VlIHRoZSBzdGFy
dCBvZiBtb2R1bGVAMHgxMGQwMDAwMCBpcyB0aGUgc2FtZSBvZiBvbGQgaW5pdHJkLiBBbHNvCm5v
dGUgdGhhdCB0aGUgc2l6ZSBvZiB0aGUgYXJlYSBpcyBzbWFsbGVyLiBUaGlzIGFzIFhlbiB3b3Vs
ZCB0cnkgdG8gbG9hZApldmVyeXRoaW5nIGZhaWxpbmcuIEp1c3QgcHV0IHNvbWUgdmFsdWUgYmln
Z2VyIHRoYW4geW91ciBrZXJuZWwgYnV0IG5vdCB0b28KbXVjaCAoMHgzMDAwMDAgaXMgMyBNQiku
CgpOb3RlIHRoYXQgdGhlIGtlcm5lbCB5b3UgYm9vdCBpbnNpZGUgWGVuIGNhbiBiZSBkaWZmZXJl
bnQgZnJvbSB0aGUga2VybmVsCmJvb3RlZCBvbiBiYXJlIG1ldGFsLiBBcyBbMV0gc3RhdGUgKCJE
b20wIGtlcm5lbCIgc2VjdGlvbik6Ci0geW91IG11c3QgZW5hYmxlIFhlbiBpbiB0aGUga2VybmVs
IGNvbmZpZ3VyYXRpb24uIFNlZSBbM10gZm9yIG9wdGlvbnMgdG8KICBlbmFibGU7Ci0geW91IG11
c3QgZGlzYWJsZSBEVEIgaW5jbHVzaW9uIGlmIGVuYWJsZWQuIFhlbiBkbyBzb21lIHR3ZWFrIG9u
IHRoZSBEVEIgaW4KICBvcmRlciB0byBhdm9pZCBjb25mbGljdHMuIElmIGtlcm5lbCB1c2UganVz
dCBiYXJlIG1ldGFsIGNvbmZpZ3VyYXRpb24gYmFkCiAgdGhpbmdzIGFyZSBnb2luZyB0byBoYXBw
ZW4uCgoKRGVidWdnaW5nIHRoZSBrZXJuZWwKLS0tLS0tLS0tLS0tLS0tLS0tLS0KCkNoZWNraW5n
IGludGVycnVwdHMuIFVuZm9ydHVuYXRlbHkgSSBsb3N0IGEgbG90IG9mIHRpbWUgKDIvMyBkYXlz
KSB3aXRoCmludGVycnVwdHMuIExpbnV4IHdhcyBub3QgZ2V0dGluZyBpbnRlcnJ1cHRzIGR1ZSB0
byBhIGNoYW5nZSBpbiBHSUNIIHJlZ2lzdGVycy4KSWYgeW91IGhhdmUgYSBzdGFuZGFyZCBHSUMg
cHJvYmFibHkgeW91IHdvbid0IGhhdmUgdGhpcyBwcm9ibGVtIGJ1dCBpcyB1c2VmdWwgdG8KdW5k
ZXJzdGFuZCB0aGUgYmVoYXZpb3VyIGFzIGludGVycnVwdHMgY2FuIGJlIHZlcnkgZGlmZmljdWx0
IHRvIGRlYnVnIGFuZCBzb3J0Cm91dC4gTGludXgga2VybmVsIHdhcyBib290aW5nIHF1aXRlIGZp
bmUgYnV0IHN1ZGRlbmx5IGl0IHN0b3BwZWQuIFVzaW5nIFhlbgpjb25zb2xlIEkgd2FzIGFibGUg
dG8gc2VlIHJlZ2lzdGVyIHN0YXRlIGFuZCBDUFVzIHdhcyBpZGxlLiBCZWZvcmUKdW5kZXJzdGFu
ZGluZyB0aGF0IGludGVycnVwdHMgd2FzIG5vdCB3b3JraW5nIEkgdG9vayBhIGxvdCBvZiBkZWJ1
Z2dpbmcgY29kZQphbmQgcmVzdGFydHMuCgpJbiBBUk0gaW50ZXJydXB0cyBnb3QgbWFpbmx5IGRp
c3BhdGNoZWQgYnkgYSBzaW5nbGUgZnVuY3Rpb24gKGNvZGUgZm9yIG15CnBsYXRmb3JtIHdhcyBp
biAuL2FyY2gvYXJtL2tlcm5lbC9lbnRyeS1hcm12LlMpLiBCYXNpY2FsbHkgYSBmdW5jdGlvbiBy
ZWdpc3RlcmVkCndpdGggc2V0X2hhbmRsZV9pcnEgaXMgY2FsbGVkIChpbiBteSBjYXNlIGJ5IGdp
Y19pbml0X2Jhc2VzIGluCmRyaXZlcnMvaXJxY2hpcC9pcnEtZ2ljLmMpLiBQdXR0aW5nIHNvbWUg
ZGVidWdnaW5nIGNvZGUgaGVyZSB3YXMgdGhlIGZpbmFsIHByb3ZlCmZvciBpbnRlcnJ1cHRzIHBy
b2JsZW1zLgoKT25jZSB0aGUgR0lDIHdhcyBmaXhlZCBkb20wIHN0YXJ0IGJvb3RpbmcgcXVpdGUg
ZmluZSBiZXNpZGUgc29tZSBzbWFsbCBpc3N1ZXM6Ci0gYSBzbWFsbCBjcmFzaCBvZiBzb21lIGRy
aXZlcnMgYXMgbm90IGluY2x1ZGVkIGluIHRoZSBpbml0aWFsIERUQiwgc29sdmVkCiAgZGlzYWJs
aW5nIGl0OwotIGV0aGVybmV0IGRyaXZlciB3YXMgbm90IHdvcmtpbmcsIHNvbHZlZCBhZGRpbmcg
YSBjYWxsIHRvCiAgZG1hX2NvZXJjZV9tYXNrX2FuZF9jb2hlcmVudCB0byBzZXQgRE1BIGJpdG1h
c2sgY29ycmVjdGx5LgpJIHdvbid0IGdvIGludG8gZGV0YWlscyBvbiB0aGVzZSBwYXJ0IGFzIHRo
ZXkgYXJlIG1vcmUgcmVsYXRlZCB0byBMaW51eCBrZXJuZWwKdGhhbiB0byBYZW4uCgoKUmVmZXJl
bmNlcwotLS0tLS0tLS0tClsxXSBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuX0FSTV93aXRo
X1ZpcnR1YWxpemF0aW9uX0V4dGVuc2lvbnMKWzJdIGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9Y
ZW5fQVJNX3dpdGhfVmlydHVhbGl6YXRpb25fRXh0ZW5zaW9uc193aGl0ZXBhcGVyClszXSBodHRw
Oi8vd2lraS54ZW4ub3JnL3dpa2kvTWFpbmxpbmVfTGludXhfS2VybmVsX0NvbmZpZ3MK
--20cf307cff10c7241f0509b65662
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--20cf307cff10c7241f0509b65662--


From xen-devel-bounces@lists.xen.org Mon Dec 08 15:47:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15:47:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy0Wm-0006AR-6T; Mon, 08 Dec 2014 15:47: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 1Xy0Wl-0006AM-Be
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:47:11 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	91/11-25276-EF7C5845; Mon, 08 Dec 2014 15:47:10 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418053628!14162160!1
X-Originating-IP: [209.85.220.176]
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 2428 invoked from network); 8 Dec 2014 15:47:09 -0000
Received: from mail-vc0-f176.google.com (HELO mail-vc0-f176.google.com)
	(209.85.220.176)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 15:47:09 -0000
Received: by mail-vc0-f176.google.com with SMTP id hq12so2209997vcb.21
	for <xen-devel@lists.xen.org>; Mon, 08 Dec 2014 07:47:08 -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:cc:content-type;
	bh=GlOW19dSWPFscXRWXfcycQDB8U0vK+jQ/UWGX4BM4h0=;
	b=CYt7/fBZ4faTfjM+Sbh0mz4/nHk45pumpEix0ByVrOr2k8s+/GmpusukbqdCUqmpNg
	dySaw7IwR17AHDhA4jVX3weLtc9/2Q0dGJToLrqr4/YhHkisGlWuvIHi7qiUxZkr4pQ8
	yTQFqUXqhbGYPKgXsAwjSNHYahADuBHoXVXm+Jz4ZV/TK675po8RU0d7mR8VXgg6Y8qa
	qKDR6XfldoDLDrtB4vUOKQRYmQRA5nsuSG9ix0MYI7dwL5WN6EJQIwJEJXaCDqpTKArV
	cvSljgT/4jQ/a9Y/ERjsNpe69xzQ8RBR9fcyBi3AobwNKFFqRjdWRtxhcN2qhV4Np+t9
	UqVQ==
MIME-Version: 1.0
X-Received: by 10.52.29.84 with SMTP id i20mr20969989vdh.1.1418053628134; Mon,
	08 Dec 2014 07:47:08 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Mon, 8 Dec 2014 07:47:08 -0800 (PST)
Date: Mon, 8 Dec 2014 15:47:08 +0000
Message-ID: <CAHt6W4da7s=UcxucNnfYvWD8cMvVHSuQUiYWPTNu_V7X1ejq9w@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.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>
Content-Type: multipart/mixed; boundary=20cf307cff10c7241f0509b65662
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] Porting 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--20cf307cff10c7241f0509b65662
Content-Type: text/plain; charset=UTF-8

Hi,
  while I was porting D01 platform
(https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
trying to describe the step I made and problems I encountered hoping
it could useful to other people. The idea is to put such documentation
in a wiki page or in the docs directory.

Let me know what do you think.

Regards,
  Frediano

--20cf307cff10c7241f0509b65662
Content-Type: text/plain; charset=US-ASCII; name="porting.txt"
Content-Disposition: attachment; filename="porting.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i3g0hry30

UG9ydGluZyBhIG5ldyBBUk0gcGxhdGZvcm0gdG8gWGVuCj09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PQoKQVJNIHBsYXRmb3JtcyBhcmUgcXVpdGUgZGlmZmVyZW50IG9uZSBmcm9tIGVh
Y2ggYW5vdGhlci4gVGhpcyBjYW4gYWZmZWN0IFhlbgpwb3J0aW5nOgotIGludGVycnVwdCBjb250
cm9sbGVyIChHSUMgb24gQVJNKSBoYXZlIGRpZmZlcmVudCB2ZXJzaW9uOwotIGludGVycnVwdHMg
bnVtYmVycyBkb2VzIG5vdCBoYXZlIG1hbnkgc3RhbmRhcmRzIChiZXNpZGUgQ1BVIG9uZXMgY2Fs
bGVkIFNHSXMpOwotIGV2ZXJ5IHBsYXRmb3JtcyBoYXZlIGRpZmZlcmVudCBhZGRyZXNzZXMgZm9y
IGRldmljZXM7Ci0gZGV2aWNlcyBsaXN0IGNhbiBiZSBxdWl0ZSBkaWZmZXJlbnQuCgpBcyBhIHN0
YXJ0IHlvdSBzaG91bGQgcmVhZCBwYWdlcyBbMV0gYW5kIFsyXSBmcm9tIHRoZSB3aWtpLgoKT25l
IGNvbmNlcHQgeW91IGhhdmUgdG8gbGVhcm4gaXMgKGF0IGxlYXN0IGN1cnJlbnRseSkgdGhlIGRl
dmljZSB0cmVlIChEVCBmb3IKc2hvcnQsIHdoaWNoIGNhbiBiZSBmb3VuZCBhcyBzb3VyY2UgaW4g
LmR0cyBmaWxlcyBpbiBhcmNoL2FybS9ib290L2R0cyBMaW51eApkaXJlY3RvcnksIC5mZHQgb3Ig
LmR0YiBmb3IgY29tcGlsZWQgdmVyc2lvbnMpLgpEZXZpY2UgdHJlZSBpcyBhIHNwZWNpZmljYXRp
b24gdGhhdCBhbGxvdyB0byBkZXNjcmliZSBkZXZpY2UgY29uZmlndXJhdGlvbnMuIEFzCmRldmlj
ZSBsaXN0IGlzIG5vdCBzdGFuZGFyZCBEVCBjb250YWlucyBkZXNjcmlwdGlvbiBvZiBhbGwgZGV2
aWNlcyBmcm9tIG1lbW9yeQp0byBDUFVzLCBzeXN0ZW0gYm9hcmQsIElPIGRldmljZXMgYW5kIHNv
IG9uLiBJbmZvcm1hdGlvbiBjYW4gYmUgSS9PIHJhbmdlcyAoaW4KQVJNIEkvTyBpcyBtZW1vcnkg
bWFwcGVkIHNvIHRoZXJlIGFyZSBub3QgdGhlIHBvcnQgY29uY2VwdCB5b3UgY2FuIGZpbmQgb24K
SW50ZWwpLCBpbnRlcnJ1cHRzLCBkZXZpY2UgdHlwZSwgY2xvY2sgYXR0YWNoZWQgYW5kIG1hbnkg
bW9yZS4gRFQgc3BlY2lmaWNhdGlvbgphcmUgcXVpdGUgZXh0ZW5zaWJsZSBhbmQgYWxsb3cgZm9y
IGluc3RhbmNlIHRvIGhhdmUgaW5mb3JtYXRpb24gbGlrZSBrZXJuZWwKY29tbWFuZCBsaW5lIHRv
by4gWW91IGNhbiBmaW5kIHF1aXRlIGEgbG90IG9mIGluZm9ybWF0aW9uIG9uIERUIGluCkRvY3Vt
ZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncyBMaW51eCBkaXJlY3RvcnkgKHNwZWNpZmljYWxs
eSB0aGVyZSBpcyBhbiBhcm0Kc3ViLWRpcmVjdG9yeSkuCgpBbm90aGVyIGJpZyBkaWZmZXJlbmNl
IGlzIHRoZSBib290IHByb2Nlc3MuIFVuZm9ydHVuYXRlbHkgaXMgbm90IHN0aWxsIHdlbGwKZGVm
aW5lZCBhcyBJbnRlbCBvbmUuIEZvciBpbnN0YW5jZSBYZW4gdXNlIG11bHRpYm9vdCBidXQgbXVs
dGlib290IGlzIG5vdCBzdGlsbApzdGFuZGFyZCBvbiBBUk0gc28gY2FuIGJlIHF1aXRlIHBhaW5m
dWwuCgpIYXBwaWx5IFhlbiByZXF1aXJlIHZlcnkgZmV3IGRldmljZXMgaW4gb3JkZXIgdG8gd29y
aywgYXMgc3RhdGVkIGluIFsyXToKLSBHSUM7Ci0gZ2VuZXJpYyB0aW1lcnM7Ci0gU01NVTsKLSBv
bmUgVUFSVC4KCk5vdywgZm9ydHVuYXRlbHkgdGltZXJzIGFyZSBub3cgcXVpdGUgc3RhbmRhcmQg
YW5kIHRoZSBpbnRlcmZhY2UgdG8gdXNlIHRoZW0KdXNlIENQVSByZWdpc3RlcnMuCgoKVUFSVAot
LS0tCgpVQVJUIGlzIHRoZSBmaXJzdCBkZXZpY2UgeW91IHNob3VsZCBpbXBsZW1lbnQuIFRoZSBy
ZWFzb24gaXMgc2ltcGxlLCBpdCBhbGxvd3MKeW91IHRvIHNlZSBzb21ldGhpbmcgZnJvbSB0aGUg
YmVnaW5uaW5nISAgRm9ydHVuYXRlbHkgYSBsb3Qgb2YgYm9hcmRzIGltcGxlbWVudAp0aGUgc3Rh
bmRhcmQgKG9yIGNvbXBhdGlibGUpIDgyNTAuIEF0IHRoZSBiZWdpbm5pbmcgeW91IHNob3VsZCB0
cnkgdG8gbWFrZSB0aGUKImVhcmx5IHByaW50ayIgd29yay4gRWFybHkgcHJpbnRrIGlzIGluaXRp
YWxpc2VkIHZlcnkgc29vbiAoanVzdCBhZnRlciBmZXcKYXNzZW1ibHkgbGluZXMpLiBJZiB5b3Ug
aGF2ZSBhIGRyaXZlciBhbGwgeW91IG5lZWQgaXMgdG8gc2V0dXAgbWVtb3J5IHJhbmdlcyBhbmQK
ZGV2aWNlIHR5cGUgYW5kIGJvb3QgWGVuLgoKVG8gbWFrZSBvdXIgVUFSVCB3b3JrIEkganVzdCBk
aWQgdGhpcyBjaGFuZ2UgdG8geGVuL2FyY2gvYXJtL1J1bGVzLm1rCihjaGFuZ2VzZXQgNWFkNzFh
NmVlZmM5YjA5ZmU3NDU4ZGVkNWI4NmI2OWZjYzU3NDM2Yyk6CgogICBFQVJMWV9QUklOVEtfQkFV
RCA6PSAxMTUyMDAKICAgRUFSTFlfVUFSVF9CQVNFX0FERFJFU1MgOj0gMHg3ZmY4MDAwMAogICBl
bmRpZgogICtpZmVxICgkKENPTkZJR19FQVJMWV9QUklOVEspLCBoaXAwNC1kMDEpCiAgK0VBUkxZ
X1BSSU5US19JTkMgOj0gODI1MAogICtFQVJMWV9QUklOVEtfQkFVRCA6PSAxMTUyMDAKICArRUFS
TFlfVUFSVF9CQVNFX0FERFJFU1MgOj0gMHhFNDAwNzAwMAogICtFQVJMWV9VQVJUX1JFR19TSElG
VCA6PSAyCiAgK2VuZGlmCgogICBpZm5lcSAoJChFQVJMWV9QUklOVEtfSU5DKSwpCiAgIEVBUkxZ
X1BSSU5USyA6PSB5CgpUbyBlbmFibGUgZWFybHkgcHJpbnRrIChhZnRlciBpbXBsZW1lbnRpbmcg
dGhlIHJpZ2h0IGNvZGUpLCB5b3UgY2FuIGhhdmUKc29tZXRoaW5nIGxpa2UgdGhpcyBpbiB5b3Vy
IC5jb25maWc6CgogIGRlYnVnIDo9IHkKICBDT05GSUdfRUFSTFlfUFJJTlRLIDo9IGhpcDA0LWQw
MQoKKGhpcDA0LWQwMSBpcyB0aGUgc3RyaW5nIGRlY2lkZWQgZm9yIG91ciBwbGF0Zm9ybSkuCgpF
YXJseSBwcmludGsgZGV2aWNlcyBhcmUgaW1wbGVtZW50ZWQgaW4geGVuL2FyY2gvYXJtL2FybTMy
IGFuZAp4ZW4vYXJjaC9hcm0vYXJtNjQgZGlyZWN0b3JpZXMgaW4gZmlsZXMgbGlrZSBkZWJ1Zy08
TkFNRT4uaW5jLgpNb3JlIGRvY3VtZW50YXRpb24gb24gZG9jcy9taXNjL2FybS9lYXJseS1wcmlu
dGsudHh0IGZpbGUuCgoKWGVuIGJvb3RpbmcKLS0tLS0tLS0tLS0KCkFzIHNhaWQgYmVmb3JlIHN0
YXJ0aW5nIFhlbiBjYW4gYmUgcXVpdGUgdHJpY2t5LiBIb3dldmVyIHRvIHN0YXJ0IHlvdSBjYW4g
Zm9jdXMKb24ganVzdCB0aGUgaHlwZXJ2aXNvci4gIElmIHlvdSBjYW4gYm9vdCBMaW51eCAoYW5k
IHlvdSByZWFsbHkgc2hvdWxkIG1ha2UgaXQKd29yayBiZWZvcmUgdHJ5aW5nIFhlbikgeW91IGNh
biByZXBsYWNlIHRoZSBrZXJuZWwgd2l0aCB0aGUgWGVuIGh5cGVydmlzb3IKKHhlbi94ZW4gZmls
ZSkgYW5kIFhlbiB3aWxsIHN0YXJ0LiBTbyB5b3UgY2FuIHRlc3QgaWYgc2VyaWFsIGFuZCBDUFVz
IGFyZQp3b3JraW5nLgoKTm93IHRoYXQgYm9vdCBsb2FkZXIgaXMgY29uZmlndXJlZCBhbmQgVUFS
VCBpcyB3b3JraW5nIHlvdSBzaG91bGQgc2VlIFhlbgpib290aW5nIGFuZCB0cnkgdG8gZG8gc29t
ZXRoaW5nISAgQnV0IHdpdGhvdXQgdGhlIEZEVCBYZW4gd29uJ3QgZG8gbXVjaC4KCgpEVEIgZmls
ZQotLS0tLS0tLQoKWGVuIG9uIEFSTSByZXF1aXJlIGEgaW5pdGlhbCBGRFQgdGhhdCBkZXNjcmli
ZSB5b3VyIGhhcmR3YXJlIGluIG9yZGVyIHRvIGhhbmRsZQp5b3VyIHBsYXRmb3JtLiAgSWYgeW91
IHdlcmUgYWJsZSB0byBsb2FkIHRoZSBGRFQgd2hpbGUgYm9vdGluZyB0aGUgTGludXgga2VybmVs
CnlvdSBjYW4gdXNlIHRoZSBzYW1lIHdheSBhbmQgc2FtZSBGRFQuICBBbm90aGVyIHdheSAod2hp
Y2ggSSB1c2VkKSBpcyB0byBlbWJlZAp0aGUgRkRUIGZpbGUgaW50byBYZW4uIEluIG15IC5jb25m
aWcgZmlsZSBJIGhhdmUgYSBsaW5lIGxpa2UKCiAgQ09ORklHX0RUQl9GSUxFIDo9ICQoWEVOX1JP
T1QpL2hpcDA0LWQwMS5kdGIKCnRoaXMgd2lsbCBlbWJlZCBoaXAwNC1kMDEuZHRiIGZpbGUgaW50
byBYZW4gKGluIG91ciBjYXNlIHRoZSBEVEIgZmlsZSB3YXMKZ2VuZXJhdGVkIGNvbXBpbGluZyBM
aW51eCB3aGlsZSBvbiBvdGhlciBjYXNlcyBpcyBhbHJlYWR5IHByb3ZpZGVkIGJ5IHRoZQpmaXJt
d2FyZSkuCgpOb3cgd2l0aCBGRFQgc29ydGVkIG91dCB5b3Ugc2hvdWxkIHNlZSBYZW4gZG9pbmcg
c29tZSBtb3JlIHByb2dyZXNzZXMuCgpOb3RlOiBpZiB5b3UgYXJlIHVzaW5nIGVhcmx5IHByaW50
ayBhZnRlciBhIHdoaWxlIFhlbiB3aWxsIHRyeSB0byBzZXR1cCB0aGUKc2VyaWFsIGFnYWluIHVz
aW5nIHRoZSBjb21tYW5kIGxpbmUuIEluIG15IGNhc2UgZm9yIHNvbWUgcmVhc29ucyBhdCB0aGUK
YmVnaW5uaW5nIHRoaXMgc2V0dXAgY2F1c2VkIHNlcmlhbCB0byBnbyBzaWxlbnQsIHRoZSB0ZW1w
b3Jhcnkgc29sdXRpb24gaWYgdG8Kbm90IHBhc3MgYSBjb21tYW5kIGxpbmUgdG8gWGVuICh3aGlj
aCB0aGUgZGVmYXVsdCBEVCBkb2VzIG5vdCBwcm92aWRlKS4gVXNpbmcKdGhpcyB0cmljayBJIHdh
cyBhYmxlIHRvIHByb2dyZXNzIHNvbWUgbW9yZS4KClRoaXMgaXMgdGhlIGNoYW5nZSB0byBhZGQg
dGhlIFhlbiBjb21tYW5kIGxpbmUgdG8gdGhlIERUUyBJIG1hZGU6CgogICAgIGNob3NlbiB7CiAg
ICAgICBsaW51eCxpbml0cmQtc3RhcnQgPSA8MCAweDEwZDAwMDAwPjsKICAgICAgIGxpbnV4LGlu
aXRyZC1lbmQgPSA8MCAweDEyNTAwMDAwPjsKICArICAgIHhlbix4ZW4tYm9vdGFyZ3MgPSAiY29u
c29sZT1kdHVhcnQgZHR1YXJ0PXNlcmlhbDAiOwogICAgIH07CgpTZWUgZG9jcy9taXNjL2FybS9i
b290aW5nLnR4dCBhbmQgZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dCBmb3IK
bW9yZSBpbmZvcm1hdGlvbi4KCgpQbGF0Zm9ybQotLS0tLS0tLQoKVGhlIG5leHQgdGhpbmcgdGhh
dCBwcm9iYWJseSB3aWxsIGZhaWwgaXMgdGhlIHBsYXRmb3JtIHNldHRpbmcgdXAuIFRvIGluaXRp
YWxpc2UKU01QIHlvdSBuZWVkIHNvbWUgY29kZSBzcGVjaWZpYyB0byB5b3VyIHBsYXRmb3JtIHVu
IGxlc3MgeW91ciBib2FyZCBzdXBwb3J0ClBTQ0kgc3RhbmRhcmQgKHlvdSBzaG91bGQgZmluZCBz
b21lIHBzY2kgc3RyaW5nIG9uIGR0cyBmaWxlcykuIEhhcHBpbHkgb24KeGVuL2FyY2gvYXJtL3Bs
YXRmb3JtcyB0aGVyZSBhcmUgbWFueSBleGFtcGxlcy4gTWFpbmx5IHRoZSBjb2RlIHJlcXVpcmUg
c29tZQp0d2VhayBmb3Igc2V0dGluZyB1cCB0aGUgYWRkaXRpb25hbCBDUFVzLiBZb3UgY2FuIHNr
aXAgYXQgdGhlIGJlZ2lubmluZyB0aGUKcmVzdGFydCBjb2RlIGJ1dCB5b3Ugc2hvdWxkIHNvcnQg
b3V0IHByb2Nlc3NvcnMgaW5pdGlhbGlzYXRpb24uIFRoZSBvdGhlciBDUFVzCmFyZSBzdGFydGVk
IHdpdGggYSBTR0kgKFNvZnR3YXJlIEdlbmVyYXRlZCBJbnRlcnJ1cHQpIGJ1dCB5b3UgYWxzbyBu
ZWVkIHRvIHNldAp0aGUgc3RhcnQgZW50cnkgb2YgdGhlIENQVXMuIFRoaXMgaXMgbm90IHN0YW5k
YXJkIGFuZCByZXF1aXJlIHNwZWNpZmljIGNvZGUuClRvIGltcGxlbWVudCBtaW5lIEkgbG9va2Vk
IGF0IExpbnV4IHNvdXJjZXMgYW5kIGNoYW5nZXNldHMgZm9yIHRoZSBwbGF0Zm9ybS4KCgpHSUMK
LS0tCgpOb3cgaWYgeW91ciBHSUMgaXMgY29tcGF0aWJsZSB0byBzdGFuZGFyZCBvbmVzIChHSUN2
MiBvciBHSUN2MykgeW91IGNhbiBqdXN0IGFkZAp5b3VyIGNvbXBhdGlibGUgc3RyaW5nIChpdCdz
IGEgc3RyaW5nIHlvdSBmaW5kIGluIHRoZSBEVCB0byBzYXkgdGhlCmNvbXBhdGliaWxpdHkgb2Yg
ZWFjaCBkZXZpY2UpIHRvIHRoZSBsaXN0IGFuZCBYZW4gc2hvdWxkIGluaXRpYWxpc2UgYW5kIHRy
eSB0bwpsb2FkIHRoZSBrZXJuZWwuCgpUbyBhZGQgb3VyIEdJQyB0byB0aGUgR0lDdjIgbGlzdCB3
ZSBkaWQgdGhpcyBjaGFuZ2UgdG8KeGVuL2luY2x1ZGUvYXNtLWFybS9naWMuaDoKCiAgICNkZWZp
bmUgRFRfQ09NUEFUX0dJQ180MDAgICAgICAgICAgICAiYXJtLGdpYy00MDAiCiAgICNkZWZpbmUg
RFRfQ09NUEFUX0dJQ19DT1JURVhfQTE1ICAgICAiYXJtLGNvcnRleC1hMTUtZ2ljIgogICAjZGVm
aW5lIERUX0NPTVBBVF9HSUNfQ09SVEVYX0E3ICAgICAgImFybSxjb3J0ZXgtYTctZ2ljIgogICsj
ZGVmaW5lIERUX0NPTVBBVF9HSUNfSElQMDQgICAgICAgICAgImhpc2lsaWNvbixoaXAwNC1pbnRj
IgoKICAgI2RlZmluZSBEVF9NQVRDSF9HSUNfVjIgRFRfTUFUQ0hfQ09NUEFUSUJMRShEVF9DT01Q
QVRfR0lDX0NPUlRFWF9BMTUpLCBcCiAgICAgICAgICAgICAgICAgICAgICAgICAgIERUX01BVENI
X0NPTVBBVElCTEUoRFRfQ09NUEFUX0dJQ19DT1JURVhfQTcpLCBcCiAgLSAgICAgICAgICAgICAg
ICAgICAgICAgIERUX01BVENIX0NPTVBBVElCTEUoRFRfQ09NUEFUX0dJQ180MDApCiAgKyAgICAg
ICAgICAgICAgICAgICAgICAgIERUX01BVENIX0NPTVBBVElCTEUoRFRfQ09NUEFUX0dJQ180MDAp
LCBcCiAgKyAgICAgICAgICAgICAgICAgICAgICAgIERUX01BVENIX0NPTVBBVElCTEUoRFRfQ09N
UEFUX0dJQ19ISVAwNCkKCiAgICNkZWZpbmUgRFRfQ09NUEFUX0dJQ19WMyAgICAgICAgICAgICAi
YXJtLGdpYy12MyIKClVuZm9ydHVuYXRlbHkgb3VyIEdJQyB3YXMgbm90IGZ1bGx5IGNvbXBhdGli
bGUgc28gaXQgcmVxdWlyZWQgY2hhbmdlcyB0byBzb3VyY2UKKHhlbi9hcmNoL2FybS9naWMtdjIu
YykuCgoKRG9tMCBrZXJuZWwKLS0tLS0tLS0tLS0KCklmIHlvdSByZWFjaCB0aGlzIHBvaW50IHlv
dSBwdXQgdGhlIGh5cGVydmlzb3IgaW4gcGxhY2Ugb2YgdGhlIGtlcm5lbCBzbyB3aGVyZQpzaG91
bGQgWGVuIHRha2UgdGhlIGtlcm5lbCB0byBzZXR1cCBkb20wPyBSZW1lbWJlcjogWEVOIElTIE5P
VCBBIEJPT1QgTE9BREVSLiBJdApoYXMgbm8gZHJpdmVyIGZvciBkaXNrIG9yIG5ldHdvcmsgc28g
dGhlIGtlcm5lbCBtdXN0IGJlIGFscmVhZHkgaW4gbWVtb3J5LAp1c3VhbGx5IGxvYWRlZCBieSB0
aGUgYm9vdCBsb2FkZXIuIEluIG15IGNhc2UgSSB1c2VkIGFub3RoZXIgdHJpY2sgcmVwbGFjaW5n
IHRoZQppbml0cmQgd2l0aCB0aGUga2VybmVsLiBBcyB0aGUgYm9vdCBsb2FkZXIgd2FzIG5vdCB3
b3JraW5nIGZvciBtZSB0aGUgZmlybXdhcmUKdGFrZSBrZXJuZWwgYW5kIGluaXRyZCBmcm9tIHNw
ZWNpZmljIHBhcnQgb2YgYm9hcmQgZmxhc2ggbWVtb3J5LiBTbyB0aGUgdHJpY2sKd2FzOgotIGxv
YWQga2VybmVsIGludG8gaW5pdHJkIHNlY3Rpb24gb2YgZmxhc2g7Ci0gY2hhbmdlIEZEVCB0byBw
b2ludCB0byBpbml0cmQgbWVtb3J5IHBvcnRpb24gKHNhbWUgbG9jYXRpb24gdXNlZCB0byBwcm92
aWRlCiAgaW5pdHJkIHRvIGtlcm5lbCBhcmUgdXNlZCB0byBwcm92aWRlIGtlcm5lbCB0byB4ZW4p
LgoKVGhpcyBpcyB0aGUgY2hhbmdlIEkgbWFkZSBpbiBEVFMgZmlsZSB0byBwdXQgdGhlIExpbnV4
IGtlcm5lbCBpbiB0aGUgaW5pdHJkCnBhcnRpdGlvbjoKCiAgICAgY2hvc2VuIHsKICAtICAgIGxp
bnV4LGluaXRyZC1zdGFydCA9IDwwIDB4MTBkMDAwMDA+OwogIC0gICAgbGludXgsaW5pdHJkLWVu
ZCA9IDwwIDB4MTI1MDAwMDA+OwogICsgICAgI2FkZHJlc3MtY2VsbHMgPSA8MT47CiAgKyAgICAj
c2l6ZS1jZWxscyA9IDwxPjsKICArCiAgKyAgICB4ZW4seGVuLWJvb3RhcmdzID0gImNvbnNvbGU9
ZHR1YXJ0IGR0dWFydD1zZXJpYWwwIjsKICArICAgIHhlbixkb20wLWJvb3RhcmdzID0gImNvbnNv
bGU9aHZjMCBlYXJseXByaW50ayByb290PS9kZXYvc2RhMiBydyBsb2dsZXZlbD03IjsKICArICAg
IG1vZHVsZUAweDEwZDAwMDAwIHsKICArICAgICAgICBjb21wYXRpYmxlID0gInhlbixsaW51eC1r
ZXJuZWwiLCAieGVuLG11bHRpYm9vdC1tb2R1bGUiOwogICsgICAgICAgIHJlZyA9IDwweDEwZDAw
MDAwIDB4MzAwMDAwPjsKICArICAgIH07CiAgICAgfTsKCkFzIHlvdSBjYW4gc2VlIHRoZSBzdGFy
dCBvZiBtb2R1bGVAMHgxMGQwMDAwMCBpcyB0aGUgc2FtZSBvZiBvbGQgaW5pdHJkLiBBbHNvCm5v
dGUgdGhhdCB0aGUgc2l6ZSBvZiB0aGUgYXJlYSBpcyBzbWFsbGVyLiBUaGlzIGFzIFhlbiB3b3Vs
ZCB0cnkgdG8gbG9hZApldmVyeXRoaW5nIGZhaWxpbmcuIEp1c3QgcHV0IHNvbWUgdmFsdWUgYmln
Z2VyIHRoYW4geW91ciBrZXJuZWwgYnV0IG5vdCB0b28KbXVjaCAoMHgzMDAwMDAgaXMgMyBNQiku
CgpOb3RlIHRoYXQgdGhlIGtlcm5lbCB5b3UgYm9vdCBpbnNpZGUgWGVuIGNhbiBiZSBkaWZmZXJl
bnQgZnJvbSB0aGUga2VybmVsCmJvb3RlZCBvbiBiYXJlIG1ldGFsLiBBcyBbMV0gc3RhdGUgKCJE
b20wIGtlcm5lbCIgc2VjdGlvbik6Ci0geW91IG11c3QgZW5hYmxlIFhlbiBpbiB0aGUga2VybmVs
IGNvbmZpZ3VyYXRpb24uIFNlZSBbM10gZm9yIG9wdGlvbnMgdG8KICBlbmFibGU7Ci0geW91IG11
c3QgZGlzYWJsZSBEVEIgaW5jbHVzaW9uIGlmIGVuYWJsZWQuIFhlbiBkbyBzb21lIHR3ZWFrIG9u
IHRoZSBEVEIgaW4KICBvcmRlciB0byBhdm9pZCBjb25mbGljdHMuIElmIGtlcm5lbCB1c2UganVz
dCBiYXJlIG1ldGFsIGNvbmZpZ3VyYXRpb24gYmFkCiAgdGhpbmdzIGFyZSBnb2luZyB0byBoYXBw
ZW4uCgoKRGVidWdnaW5nIHRoZSBrZXJuZWwKLS0tLS0tLS0tLS0tLS0tLS0tLS0KCkNoZWNraW5n
IGludGVycnVwdHMuIFVuZm9ydHVuYXRlbHkgSSBsb3N0IGEgbG90IG9mIHRpbWUgKDIvMyBkYXlz
KSB3aXRoCmludGVycnVwdHMuIExpbnV4IHdhcyBub3QgZ2V0dGluZyBpbnRlcnJ1cHRzIGR1ZSB0
byBhIGNoYW5nZSBpbiBHSUNIIHJlZ2lzdGVycy4KSWYgeW91IGhhdmUgYSBzdGFuZGFyZCBHSUMg
cHJvYmFibHkgeW91IHdvbid0IGhhdmUgdGhpcyBwcm9ibGVtIGJ1dCBpcyB1c2VmdWwgdG8KdW5k
ZXJzdGFuZCB0aGUgYmVoYXZpb3VyIGFzIGludGVycnVwdHMgY2FuIGJlIHZlcnkgZGlmZmljdWx0
IHRvIGRlYnVnIGFuZCBzb3J0Cm91dC4gTGludXgga2VybmVsIHdhcyBib290aW5nIHF1aXRlIGZp
bmUgYnV0IHN1ZGRlbmx5IGl0IHN0b3BwZWQuIFVzaW5nIFhlbgpjb25zb2xlIEkgd2FzIGFibGUg
dG8gc2VlIHJlZ2lzdGVyIHN0YXRlIGFuZCBDUFVzIHdhcyBpZGxlLiBCZWZvcmUKdW5kZXJzdGFu
ZGluZyB0aGF0IGludGVycnVwdHMgd2FzIG5vdCB3b3JraW5nIEkgdG9vayBhIGxvdCBvZiBkZWJ1
Z2dpbmcgY29kZQphbmQgcmVzdGFydHMuCgpJbiBBUk0gaW50ZXJydXB0cyBnb3QgbWFpbmx5IGRp
c3BhdGNoZWQgYnkgYSBzaW5nbGUgZnVuY3Rpb24gKGNvZGUgZm9yIG15CnBsYXRmb3JtIHdhcyBp
biAuL2FyY2gvYXJtL2tlcm5lbC9lbnRyeS1hcm12LlMpLiBCYXNpY2FsbHkgYSBmdW5jdGlvbiBy
ZWdpc3RlcmVkCndpdGggc2V0X2hhbmRsZV9pcnEgaXMgY2FsbGVkIChpbiBteSBjYXNlIGJ5IGdp
Y19pbml0X2Jhc2VzIGluCmRyaXZlcnMvaXJxY2hpcC9pcnEtZ2ljLmMpLiBQdXR0aW5nIHNvbWUg
ZGVidWdnaW5nIGNvZGUgaGVyZSB3YXMgdGhlIGZpbmFsIHByb3ZlCmZvciBpbnRlcnJ1cHRzIHBy
b2JsZW1zLgoKT25jZSB0aGUgR0lDIHdhcyBmaXhlZCBkb20wIHN0YXJ0IGJvb3RpbmcgcXVpdGUg
ZmluZSBiZXNpZGUgc29tZSBzbWFsbCBpc3N1ZXM6Ci0gYSBzbWFsbCBjcmFzaCBvZiBzb21lIGRy
aXZlcnMgYXMgbm90IGluY2x1ZGVkIGluIHRoZSBpbml0aWFsIERUQiwgc29sdmVkCiAgZGlzYWJs
aW5nIGl0OwotIGV0aGVybmV0IGRyaXZlciB3YXMgbm90IHdvcmtpbmcsIHNvbHZlZCBhZGRpbmcg
YSBjYWxsIHRvCiAgZG1hX2NvZXJjZV9tYXNrX2FuZF9jb2hlcmVudCB0byBzZXQgRE1BIGJpdG1h
c2sgY29ycmVjdGx5LgpJIHdvbid0IGdvIGludG8gZGV0YWlscyBvbiB0aGVzZSBwYXJ0IGFzIHRo
ZXkgYXJlIG1vcmUgcmVsYXRlZCB0byBMaW51eCBrZXJuZWwKdGhhbiB0byBYZW4uCgoKUmVmZXJl
bmNlcwotLS0tLS0tLS0tClsxXSBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuX0FSTV93aXRo
X1ZpcnR1YWxpemF0aW9uX0V4dGVuc2lvbnMKWzJdIGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9Y
ZW5fQVJNX3dpdGhfVmlydHVhbGl6YXRpb25fRXh0ZW5zaW9uc193aGl0ZXBhcGVyClszXSBodHRw
Oi8vd2lraS54ZW4ub3JnL3dpa2kvTWFpbmxpbmVfTGludXhfS2VybmVsX0NvbmZpZ3MK
--20cf307cff10c7241f0509b65662
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--20cf307cff10c7241f0509b65662--


From xen-devel-bounces@lists.xen.org Mon Dec 08 15:52:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15: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 1Xy0bh-0006Q2-4C; Mon, 08 Dec 2014 15:52: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 1Xy0bf-0006Pb-C0
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:52:15 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	2C/81-27785-E29C5845; Mon, 08 Dec 2014 15:52:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418053932!10388883!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3878 invoked from network); 8 Dec 2014 15:52:13 -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; 8 Dec 2014 15:52: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 sB8Fq6BV021218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 15:52:07 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
	sB8Fq5tA009444
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 15:52:05 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
	sB8Fq48s002393; Mon, 8 Dec 2014 15:52:04 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 07:52:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0FB6D1201D6; Mon,  8 Dec 2014 10:52:06 -0500 (EST)
Date: Mon, 8 Dec 2014 10:52:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141208155205.GC7745@laptop.dumpdata.com>
References: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1418032087.11028.5.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418032087.11028.5.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] flask/policy: Example policy
 updates for migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 09:48:07AM +0000, Ian Campbell wrote:
> On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> > The example XSM policy was missing permission for dom0_t to migrate
> > domains; add these permissions.
> > 
> > Reported-by: Wei Liu <wei.liu2@citrix.com>
> > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Konrad, we should take this for 4.5, in order to have a working example
> XSM policy. There's 0 risk to non-XSM systems, or systems with custom

Thought this looks like it never worked in the past then? As in, this
is not a regression but a bug that had existed for quite a while?

> XSM policies and clear benefits to XSM systems using the example policy.
> 
> > ---
> > 
> > This has been tested with xl save/restore on a PV domain, which now
> > succeeds without producing AVC denials.
> > 
> >  tools/flask/policy/policy/modules/xen/xen.if | 11 +++++++----
> >  tools/flask/policy/policy/modules/xen/xen.te |  3 +++
> >  2 files changed, 10 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> > index fa69c9d..bf5e135 100644
> > --- a/tools/flask/policy/policy/modules/xen/xen.if
> > +++ b/tools/flask/policy/policy/modules/xen/xen.if
> > @@ -48,11 +48,13 @@ define(`create_domain_common', `
> >  	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
> >  			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 };
> > +			getaffinity setaffinity setvcpuextstate };
> > +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
> > +			set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
> > +			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 };
> > +	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
> >  	allow $1 $2:grant setup;
> >  	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
> >  			setparam pcilevel trackdirtyvram nested };
> > @@ -80,7 +82,7 @@ define(`create_domain_build_label', `
> >  define(`manage_domain', `
> >  	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
> >  			getaddrsize pause unpause trigger shutdown destroy
> > -			setaffinity setdomainmaxmem getscheduler };
> > +			setaffinity setdomainmaxmem getscheduler resume };
> >      allow $1 $2:domain2 set_vnumainfo;
> >  ')
> >  
> > @@ -88,6 +90,7 @@ define(`manage_domain', `
> >  #   Allow creation of a snapshot or migration image from a domain
> >  #   (inbound migration is the same as domain creation)
> >  define(`migrate_domain_out', `
> > +	allow $1 domxen_t:mmu map_read;
> >  	allow $1 $2:hvm { gethvmc getparam irqlevel };
> >  	allow $1 $2:mmu { stat pageinfo map_read };
> >  	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
> > diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
> > index d214470..c0128aa 100644
> > --- a/tools/flask/policy/policy/modules/xen/xen.te
> > +++ b/tools/flask/policy/policy/modules/xen/xen.te
> > @@ -129,12 +129,14 @@ create_domain(dom0_t, domU_t)
> >  manage_domain(dom0_t, domU_t)
> >  domain_comms(dom0_t, domU_t)
> >  domain_comms(domU_t, domU_t)
> > +migrate_domain_out(dom0_t, domU_t)
> >  domain_self_comms(domU_t)
> >  
> >  declare_domain(isolated_domU_t)
> >  create_domain(dom0_t, isolated_domU_t)
> >  manage_domain(dom0_t, isolated_domU_t)
> >  domain_comms(dom0_t, isolated_domU_t)
> > +migrate_domain_out(dom0_t, isolated_domU_t)
> >  domain_self_comms(isolated_domU_t)
> >  
> >  # Declare a boolean that denies creation of prot_domU_t domains
> > @@ -142,6 +144,7 @@ gen_bool(prot_doms_locked, false)
> >  declare_domain(prot_domU_t)
> >  if (!prot_doms_locked) {
> >  	create_domain(dom0_t, prot_domU_t)
> > +	migrate_domain_out(dom0_t, prot_domU_t)
> >  }
> >  domain_comms(dom0_t, prot_domU_t)
> >  domain_comms(domU_t, prot_domU_t)
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 15:52:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15: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 1Xy0bh-0006Q2-4C; Mon, 08 Dec 2014 15:52: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 1Xy0bf-0006Pb-C0
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:52:15 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	2C/81-27785-E29C5845; Mon, 08 Dec 2014 15:52:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418053932!10388883!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3878 invoked from network); 8 Dec 2014 15:52:13 -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; 8 Dec 2014 15:52: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 sB8Fq6BV021218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 15:52:07 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
	sB8Fq5tA009444
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 15:52:05 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
	sB8Fq48s002393; Mon, 8 Dec 2014 15:52:04 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 07:52:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0FB6D1201D6; Mon,  8 Dec 2014 10:52:06 -0500 (EST)
Date: Mon, 8 Dec 2014 10:52:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141208155205.GC7745@laptop.dumpdata.com>
References: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1418032087.11028.5.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418032087.11028.5.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] flask/policy: Example policy
 updates for migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 09:48:07AM +0000, Ian Campbell wrote:
> On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> > The example XSM policy was missing permission for dom0_t to migrate
> > domains; add these permissions.
> > 
> > Reported-by: Wei Liu <wei.liu2@citrix.com>
> > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Konrad, we should take this for 4.5, in order to have a working example
> XSM policy. There's 0 risk to non-XSM systems, or systems with custom

Thought this looks like it never worked in the past then? As in, this
is not a regression but a bug that had existed for quite a while?

> XSM policies and clear benefits to XSM systems using the example policy.
> 
> > ---
> > 
> > This has been tested with xl save/restore on a PV domain, which now
> > succeeds without producing AVC denials.
> > 
> >  tools/flask/policy/policy/modules/xen/xen.if | 11 +++++++----
> >  tools/flask/policy/policy/modules/xen/xen.te |  3 +++
> >  2 files changed, 10 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> > index fa69c9d..bf5e135 100644
> > --- a/tools/flask/policy/policy/modules/xen/xen.if
> > +++ b/tools/flask/policy/policy/modules/xen/xen.if
> > @@ -48,11 +48,13 @@ define(`create_domain_common', `
> >  	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
> >  			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 };
> > +			getaffinity setaffinity setvcpuextstate };
> > +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
> > +			set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
> > +			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 };
> > +	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
> >  	allow $1 $2:grant setup;
> >  	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
> >  			setparam pcilevel trackdirtyvram nested };
> > @@ -80,7 +82,7 @@ define(`create_domain_build_label', `
> >  define(`manage_domain', `
> >  	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
> >  			getaddrsize pause unpause trigger shutdown destroy
> > -			setaffinity setdomainmaxmem getscheduler };
> > +			setaffinity setdomainmaxmem getscheduler resume };
> >      allow $1 $2:domain2 set_vnumainfo;
> >  ')
> >  
> > @@ -88,6 +90,7 @@ define(`manage_domain', `
> >  #   Allow creation of a snapshot or migration image from a domain
> >  #   (inbound migration is the same as domain creation)
> >  define(`migrate_domain_out', `
> > +	allow $1 domxen_t:mmu map_read;
> >  	allow $1 $2:hvm { gethvmc getparam irqlevel };
> >  	allow $1 $2:mmu { stat pageinfo map_read };
> >  	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
> > diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
> > index d214470..c0128aa 100644
> > --- a/tools/flask/policy/policy/modules/xen/xen.te
> > +++ b/tools/flask/policy/policy/modules/xen/xen.te
> > @@ -129,12 +129,14 @@ create_domain(dom0_t, domU_t)
> >  manage_domain(dom0_t, domU_t)
> >  domain_comms(dom0_t, domU_t)
> >  domain_comms(domU_t, domU_t)
> > +migrate_domain_out(dom0_t, domU_t)
> >  domain_self_comms(domU_t)
> >  
> >  declare_domain(isolated_domU_t)
> >  create_domain(dom0_t, isolated_domU_t)
> >  manage_domain(dom0_t, isolated_domU_t)
> >  domain_comms(dom0_t, isolated_domU_t)
> > +migrate_domain_out(dom0_t, isolated_domU_t)
> >  domain_self_comms(isolated_domU_t)
> >  
> >  # Declare a boolean that denies creation of prot_domU_t domains
> > @@ -142,6 +144,7 @@ gen_bool(prot_doms_locked, false)
> >  declare_domain(prot_domU_t)
> >  if (!prot_doms_locked) {
> >  	create_domain(dom0_t, prot_domU_t)
> > +	migrate_domain_out(dom0_t, prot_domU_t)
> >  }
> >  domain_comms(dom0_t, prot_domU_t)
> >  domain_comms(domU_t, prot_domU_t)
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 15:53:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15:53:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy0cG-0006ch-JP; Mon, 08 Dec 2014 15:52: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 1Xy0cF-0006cH-LX
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:52:51 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	B1/58-02702-359C5845; Mon, 08 Dec 2014 15:52:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418053968!13731540!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21206 invoked from network); 8 Dec 2014 15:52:49 -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; 8 Dec 2014 15:52: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 sB8FqbbC021883
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 15:52: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
	sB8FqZK6005071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 15:52:36 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
	sB8FqZvt005058; Mon, 8 Dec 2014 15:52:35 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 07:52:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 429B91201D9; Mon,  8 Dec 2014 10:52:36 -0500 (EST)
Date: Mon, 8 Dec 2014 10:52:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141208155236.GD7745@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-6-git-send-email-tiejun.chen@intel.com>
	<20141202195017.GE357@laptop.dumpdata.com>
	<54855258.5070509@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54855258.5070509@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 05/17] tools/libxc: introduce hypercall
 for xc_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 03:25:12PM +0800, Chen, Tiejun wrote:
> On 2014/12/3 3:50, Konrad Rzeszutek Wilk wrote:
> >On Mon, Dec 01, 2014 at 05:24:23PM +0800, Tiejun Chen wrote:
> >>We will introduce that hypercall xc_reserved_device_memory_map
> >>approach to libxc.
> >>
> >>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>---
> >>  tools/libxc/include/xenctrl.h |  5 +++++
> >>  tools/libxc/xc_domain.c       | 30 ++++++++++++++++++++++++++++++
> >>  2 files changed, 35 insertions(+)
> >>
> >>diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> >>index 84012fe..a3aeac3 100644
> >>--- a/tools/libxc/include/xenctrl.h
> >>+++ b/tools/libxc/include/xenctrl.h
> >>@@ -1294,6 +1294,11 @@ int xc_domain_set_memory_map(xc_interface *xch,
> >>  int xc_get_machine_memory_map(xc_interface *xch,
> >>                                struct e820entry entries[],
> >>                                uint32_t max_entries);
> >>+
> >>+int xc_reserved_device_memory_map(xc_interface *xch,
> >>+                                  uint32_t dom,
> >>+                                  struct xen_reserved_device_memory entries[],
> >>+                                  uint32_t *max_entries);
> >>  #endif
> >>  int xc_domain_set_time_offset(xc_interface *xch,
> >>                                uint32_t domid,
> >>diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> >>index 7fd43e9..09fd988 100644
> >>--- a/tools/libxc/xc_domain.c
> >>+++ b/tools/libxc/xc_domain.c
> >>@@ -679,6 +679,36 @@ int xc_domain_set_memory_map(xc_interface *xch,
> >>
> >>      return rc;
> >>  }
> >>+
> >>+int xc_reserved_device_memory_map(xc_interface *xch,
> >>+                                  uint32_t domid,
> >>+                                  struct xen_reserved_device_memory entries[],
> >>+                                  uint32_t *max_entries)
> >>+{
> >>+    int rc;
> >>+    struct xen_reserved_device_memory_map xrdmmap = {
> >>+        .domid = domid,
> >>+        .nr_entries = *max_entries
> >>+    };
> >>+    DECLARE_HYPERCALL_BOUNCE(entries,
> >>+                             sizeof(struct xen_reserved_device_memory) *
> >>+                             *max_entries, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
> >>+
> >>+    if ( xc_hypercall_bounce_pre(xch, entries) )
> >>+        return -1;
> >>+
> >>+    set_xen_guest_handle(xrdmmap.buffer, entries);
> >>+
> >>+    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
> >>+                      &xrdmmap, sizeof(xrdmmap));
> >>+
> >>+    xc_hypercall_bounce_post(xch, entries);
> >>+
> >>+    *max_entries = xrdmmap.nr_entries;
> >>+
> >
> >I would bake the -EAGAIN support in here to loop here.
> >
> >See how the xc_domain_destroy does it.
> 
> Do you mean this change?
> 
> @@ -699,8 +699,10 @@ int xc_reserved_device_memory_map(xc_interface *xch,
> 
>      set_xen_guest_handle(xrdmmap.buffer, entries);
> 
> -    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
> -                      &xrdmmap, sizeof(xrdmmap));
> +    do {
> +        rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
> +                          &xrdmmap, sizeof(xrdmmap));
> +    } while ( rc && (errno == EAGAIN) );

Yes.
> 
>      xc_hypercall_bounce_post(xch, entries);
> 
> Thanks
> Tiejun
> 
> >>+    return rc ? rc : xrdmmap.nr_entries;
> >>+}
> >>+
> >>  int xc_get_machine_memory_map(xc_interface *xch,
> >>                                struct e820entry entries[],
> >>                                uint32_t max_entries)
> >>--
> >>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 Dec 08 15:53:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15:53:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy0cG-0006ch-JP; Mon, 08 Dec 2014 15:52: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 1Xy0cF-0006cH-LX
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:52:51 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	B1/58-02702-359C5845; Mon, 08 Dec 2014 15:52:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418053968!13731540!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21206 invoked from network); 8 Dec 2014 15:52:49 -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; 8 Dec 2014 15:52: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 sB8FqbbC021883
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 15:52: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
	sB8FqZK6005071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 15:52:36 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
	sB8FqZvt005058; Mon, 8 Dec 2014 15:52:35 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 07:52:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 429B91201D9; Mon,  8 Dec 2014 10:52:36 -0500 (EST)
Date: Mon, 8 Dec 2014 10:52:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141208155236.GD7745@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-6-git-send-email-tiejun.chen@intel.com>
	<20141202195017.GE357@laptop.dumpdata.com>
	<54855258.5070509@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54855258.5070509@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 05/17] tools/libxc: introduce hypercall
 for xc_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 03:25:12PM +0800, Chen, Tiejun wrote:
> On 2014/12/3 3:50, Konrad Rzeszutek Wilk wrote:
> >On Mon, Dec 01, 2014 at 05:24:23PM +0800, Tiejun Chen wrote:
> >>We will introduce that hypercall xc_reserved_device_memory_map
> >>approach to libxc.
> >>
> >>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>---
> >>  tools/libxc/include/xenctrl.h |  5 +++++
> >>  tools/libxc/xc_domain.c       | 30 ++++++++++++++++++++++++++++++
> >>  2 files changed, 35 insertions(+)
> >>
> >>diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> >>index 84012fe..a3aeac3 100644
> >>--- a/tools/libxc/include/xenctrl.h
> >>+++ b/tools/libxc/include/xenctrl.h
> >>@@ -1294,6 +1294,11 @@ int xc_domain_set_memory_map(xc_interface *xch,
> >>  int xc_get_machine_memory_map(xc_interface *xch,
> >>                                struct e820entry entries[],
> >>                                uint32_t max_entries);
> >>+
> >>+int xc_reserved_device_memory_map(xc_interface *xch,
> >>+                                  uint32_t dom,
> >>+                                  struct xen_reserved_device_memory entries[],
> >>+                                  uint32_t *max_entries);
> >>  #endif
> >>  int xc_domain_set_time_offset(xc_interface *xch,
> >>                                uint32_t domid,
> >>diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> >>index 7fd43e9..09fd988 100644
> >>--- a/tools/libxc/xc_domain.c
> >>+++ b/tools/libxc/xc_domain.c
> >>@@ -679,6 +679,36 @@ int xc_domain_set_memory_map(xc_interface *xch,
> >>
> >>      return rc;
> >>  }
> >>+
> >>+int xc_reserved_device_memory_map(xc_interface *xch,
> >>+                                  uint32_t domid,
> >>+                                  struct xen_reserved_device_memory entries[],
> >>+                                  uint32_t *max_entries)
> >>+{
> >>+    int rc;
> >>+    struct xen_reserved_device_memory_map xrdmmap = {
> >>+        .domid = domid,
> >>+        .nr_entries = *max_entries
> >>+    };
> >>+    DECLARE_HYPERCALL_BOUNCE(entries,
> >>+                             sizeof(struct xen_reserved_device_memory) *
> >>+                             *max_entries, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
> >>+
> >>+    if ( xc_hypercall_bounce_pre(xch, entries) )
> >>+        return -1;
> >>+
> >>+    set_xen_guest_handle(xrdmmap.buffer, entries);
> >>+
> >>+    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
> >>+                      &xrdmmap, sizeof(xrdmmap));
> >>+
> >>+    xc_hypercall_bounce_post(xch, entries);
> >>+
> >>+    *max_entries = xrdmmap.nr_entries;
> >>+
> >
> >I would bake the -EAGAIN support in here to loop here.
> >
> >See how the xc_domain_destroy does it.
> 
> Do you mean this change?
> 
> @@ -699,8 +699,10 @@ int xc_reserved_device_memory_map(xc_interface *xch,
> 
>      set_xen_guest_handle(xrdmmap.buffer, entries);
> 
> -    rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
> -                      &xrdmmap, sizeof(xrdmmap));
> +    do {
> +        rc = do_memory_op(xch, XENMEM_reserved_device_memory_map,
> +                          &xrdmmap, sizeof(xrdmmap));
> +    } while ( rc && (errno == EAGAIN) );

Yes.
> 
>      xc_hypercall_bounce_post(xch, entries);
> 
> Thanks
> Tiejun
> 
> >>+    return rc ? rc : xrdmmap.nr_entries;
> >>+}
> >>+
> >>  int xc_get_machine_memory_map(xc_interface *xch,
> >>                                struct e820entry entries[],
> >>                                uint32_t max_entries)
> >>--
> >>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 Dec 08 15:54:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15:54:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy0db-0006jw-31; Mon, 08 Dec 2014 15:54:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xy0dZ-0006jg-C1
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:54:13 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	26/51-02576-4A9C5845; Mon, 08 Dec 2014 15:54:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418054049!13715747!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 26422 invoked from network); 8 Dec 2014 15:54:11 -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 Dec 2014 15:54:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201848689"
Message-ID: <1418054046.2827.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 8 Dec 2014 15:54:06 +0000
In-Reply-To: <20141208155205.GC7745@laptop.dumpdata.com>
References: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1418032087.11028.5.camel@citrix.com>
	<20141208155205.GC7745@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] flask/policy: Example policy
 updates for migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-08 at 10:52 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 08, 2014 at 09:48:07AM +0000, Ian Campbell wrote:
> > On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> > > The example XSM policy was missing permission for dom0_t to migrate
> > > domains; add these permissions.
> > > 
> > > Reported-by: Wei Liu <wei.liu2@citrix.com>
> > > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Konrad, we should take this for 4.5, in order to have a working example
> > XSM policy. There's 0 risk to non-XSM systems, or systems with custom
> 
> Thought this looks like it never worked in the past then? As in, this
> is not a regression but a bug that had existed for quite a while?

AIUI it has worked in the past, i.e. I remember applying other series
from Daniel to fix it for previous releases. This patch is the policy
catching up with the developments during 4.5.

> 
> > XSM policies and clear benefits to XSM systems using the example policy.
> > 
> > > ---
> > > 
> > > This has been tested with xl save/restore on a PV domain, which now
> > > succeeds without producing AVC denials.
> > > 
> > >  tools/flask/policy/policy/modules/xen/xen.if | 11 +++++++----
> > >  tools/flask/policy/policy/modules/xen/xen.te |  3 +++
> > >  2 files changed, 10 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> > > index fa69c9d..bf5e135 100644
> > > --- a/tools/flask/policy/policy/modules/xen/xen.if
> > > +++ b/tools/flask/policy/policy/modules/xen/xen.if
> > > @@ -48,11 +48,13 @@ define(`create_domain_common', `
> > >  	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
> > >  			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 };
> > > +			getaffinity setaffinity setvcpuextstate };
> > > +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
> > > +			set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
> > > +			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 };
> > > +	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
> > >  	allow $1 $2:grant setup;
> > >  	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
> > >  			setparam pcilevel trackdirtyvram nested };
> > > @@ -80,7 +82,7 @@ define(`create_domain_build_label', `
> > >  define(`manage_domain', `
> > >  	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
> > >  			getaddrsize pause unpause trigger shutdown destroy
> > > -			setaffinity setdomainmaxmem getscheduler };
> > > +			setaffinity setdomainmaxmem getscheduler resume };
> > >      allow $1 $2:domain2 set_vnumainfo;
> > >  ')
> > >  
> > > @@ -88,6 +90,7 @@ define(`manage_domain', `
> > >  #   Allow creation of a snapshot or migration image from a domain
> > >  #   (inbound migration is the same as domain creation)
> > >  define(`migrate_domain_out', `
> > > +	allow $1 domxen_t:mmu map_read;
> > >  	allow $1 $2:hvm { gethvmc getparam irqlevel };
> > >  	allow $1 $2:mmu { stat pageinfo map_read };
> > >  	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
> > > diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
> > > index d214470..c0128aa 100644
> > > --- a/tools/flask/policy/policy/modules/xen/xen.te
> > > +++ b/tools/flask/policy/policy/modules/xen/xen.te
> > > @@ -129,12 +129,14 @@ create_domain(dom0_t, domU_t)
> > >  manage_domain(dom0_t, domU_t)
> > >  domain_comms(dom0_t, domU_t)
> > >  domain_comms(domU_t, domU_t)
> > > +migrate_domain_out(dom0_t, domU_t)
> > >  domain_self_comms(domU_t)
> > >  
> > >  declare_domain(isolated_domU_t)
> > >  create_domain(dom0_t, isolated_domU_t)
> > >  manage_domain(dom0_t, isolated_domU_t)
> > >  domain_comms(dom0_t, isolated_domU_t)
> > > +migrate_domain_out(dom0_t, isolated_domU_t)
> > >  domain_self_comms(isolated_domU_t)
> > >  
> > >  # Declare a boolean that denies creation of prot_domU_t domains
> > > @@ -142,6 +144,7 @@ gen_bool(prot_doms_locked, false)
> > >  declare_domain(prot_domU_t)
> > >  if (!prot_doms_locked) {
> > >  	create_domain(dom0_t, prot_domU_t)
> > > +	migrate_domain_out(dom0_t, prot_domU_t)
> > >  }
> > >  domain_comms(dom0_t, prot_domU_t)
> > >  domain_comms(domU_t, prot_domU_t)
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 15:54:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15:54:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy0db-0006jw-31; Mon, 08 Dec 2014 15:54:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xy0dZ-0006jg-C1
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:54:13 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	26/51-02576-4A9C5845; Mon, 08 Dec 2014 15:54:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418054049!13715747!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 26422 invoked from network); 8 Dec 2014 15:54:11 -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 Dec 2014 15:54:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201848689"
Message-ID: <1418054046.2827.18.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 8 Dec 2014 15:54:06 +0000
In-Reply-To: <20141208155205.GC7745@laptop.dumpdata.com>
References: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1418032087.11028.5.camel@citrix.com>
	<20141208155205.GC7745@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] flask/policy: Example policy
 updates for migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-08 at 10:52 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 08, 2014 at 09:48:07AM +0000, Ian Campbell wrote:
> > On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> > > The example XSM policy was missing permission for dom0_t to migrate
> > > domains; add these permissions.
> > > 
> > > Reported-by: Wei Liu <wei.liu2@citrix.com>
> > > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Konrad, we should take this for 4.5, in order to have a working example
> > XSM policy. There's 0 risk to non-XSM systems, or systems with custom
> 
> Thought this looks like it never worked in the past then? As in, this
> is not a regression but a bug that had existed for quite a while?

AIUI it has worked in the past, i.e. I remember applying other series
from Daniel to fix it for previous releases. This patch is the policy
catching up with the developments during 4.5.

> 
> > XSM policies and clear benefits to XSM systems using the example policy.
> > 
> > > ---
> > > 
> > > This has been tested with xl save/restore on a PV domain, which now
> > > succeeds without producing AVC denials.
> > > 
> > >  tools/flask/policy/policy/modules/xen/xen.if | 11 +++++++----
> > >  tools/flask/policy/policy/modules/xen/xen.te |  3 +++
> > >  2 files changed, 10 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> > > index fa69c9d..bf5e135 100644
> > > --- a/tools/flask/policy/policy/modules/xen/xen.if
> > > +++ b/tools/flask/policy/policy/modules/xen/xen.if
> > > @@ -48,11 +48,13 @@ define(`create_domain_common', `
> > >  	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
> > >  			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 };
> > > +			getaffinity setaffinity setvcpuextstate };
> > > +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
> > > +			set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
> > > +			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 };
> > > +	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
> > >  	allow $1 $2:grant setup;
> > >  	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
> > >  			setparam pcilevel trackdirtyvram nested };
> > > @@ -80,7 +82,7 @@ define(`create_domain_build_label', `
> > >  define(`manage_domain', `
> > >  	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
> > >  			getaddrsize pause unpause trigger shutdown destroy
> > > -			setaffinity setdomainmaxmem getscheduler };
> > > +			setaffinity setdomainmaxmem getscheduler resume };
> > >      allow $1 $2:domain2 set_vnumainfo;
> > >  ')
> > >  
> > > @@ -88,6 +90,7 @@ define(`manage_domain', `
> > >  #   Allow creation of a snapshot or migration image from a domain
> > >  #   (inbound migration is the same as domain creation)
> > >  define(`migrate_domain_out', `
> > > +	allow $1 domxen_t:mmu map_read;
> > >  	allow $1 $2:hvm { gethvmc getparam irqlevel };
> > >  	allow $1 $2:mmu { stat pageinfo map_read };
> > >  	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
> > > diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
> > > index d214470..c0128aa 100644
> > > --- a/tools/flask/policy/policy/modules/xen/xen.te
> > > +++ b/tools/flask/policy/policy/modules/xen/xen.te
> > > @@ -129,12 +129,14 @@ create_domain(dom0_t, domU_t)
> > >  manage_domain(dom0_t, domU_t)
> > >  domain_comms(dom0_t, domU_t)
> > >  domain_comms(domU_t, domU_t)
> > > +migrate_domain_out(dom0_t, domU_t)
> > >  domain_self_comms(domU_t)
> > >  
> > >  declare_domain(isolated_domU_t)
> > >  create_domain(dom0_t, isolated_domU_t)
> > >  manage_domain(dom0_t, isolated_domU_t)
> > >  domain_comms(dom0_t, isolated_domU_t)
> > > +migrate_domain_out(dom0_t, isolated_domU_t)
> > >  domain_self_comms(isolated_domU_t)
> > >  
> > >  # Declare a boolean that denies creation of prot_domU_t domains
> > > @@ -142,6 +144,7 @@ gen_bool(prot_doms_locked, false)
> > >  declare_domain(prot_domU_t)
> > >  if (!prot_doms_locked) {
> > >  	create_domain(dom0_t, prot_domU_t)
> > > +	migrate_domain_out(dom0_t, prot_domU_t)
> > >  }
> > >  domain_comms(dom0_t, prot_domU_t)
> > >  domain_comms(domU_t, prot_domU_t)
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 15:58:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15: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 1Xy0hE-0006yp-Ne; Mon, 08 Dec 2014 15:58:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xy0hD-0006yk-7D
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:57:59 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	A1/1A-14727-68AC5845; Mon, 08 Dec 2014 15:57:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418054267!12152701!1
X-Originating-IP: [156.151.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 6215 invoked from network); 8 Dec 2014 15:57:48 -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; 8 Dec 2014 15:57: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 sB8FvacK028300
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 15:57:37 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
	sB8FvY55028075
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 15:57:35 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
	sB8FvXZg004219; Mon, 8 Dec 2014 15:57:33 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 07:57:33 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4B4B11201EC; Mon,  8 Dec 2014 10:57:34 -0500 (EST)
Date: Mon, 8 Dec 2014 10:57:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141208155734.GE7745@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<20141202193943.GC357@laptop.dumpdata.com>
	<548517F7.6040106@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548517F7.6040106@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 11:16:07AM +0800, Chen, Tiejun wrote:
> 
> On 2014/12/3 3:39, Konrad Rzeszutek Wilk wrote:
> >On Mon, Dec 01, 2014 at 05:24:20PM +0800, Tiejun Chen wrote:
> >>This should be based on a new parameter globally, 'pci_rdmforce'.
> >>
> >>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 this domctl provides an approach to control how to populate
> >>reserved device memory by tools.
> >>
> >>Note we always post a message to user about this once we owns
> >>RMRR.
> >>
> >>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>---
> >>  docs/man/xl.cfg.pod.5              |  6 +++++
> >>  docs/misc/vtd.txt                  | 15 ++++++++++++
> >>  tools/libxc/include/xenctrl.h      |  6 +++++
> >>  tools/libxc/xc_domain.c            | 28 +++++++++++++++++++++++
> >>  tools/libxl/libxl_create.c         |  3 +++
> >>  tools/libxl/libxl_dm.c             | 47 ++++++++++++++++++++++++++++++++++++++
> >>  tools/libxl/libxl_internal.h       |  4 ++++
> >>  tools/libxl/libxl_types.idl        |  2 ++
> >>  tools/libxl/libxlu_pci.c           |  2 ++
> >>  tools/libxl/xl_cmdimpl.c           | 10 ++++++++
> >
> >In the past we had split the hypervisor and the
> >toolstack patches in two. So that one could focus
> >on the hypervisor ones first, and then in another
> >patch on the toolstack.
> >
> 
> Yes.
> 
> >But perhaps this was intended to be in one patch?
> 
> This change also involve docs so its little bit harder to understand the
> whole page if we split this.
> 
> >
> >>  xen/drivers/passthrough/pci.c      | 39 +++++++++++++++++++++++++++++++
> >>  xen/drivers/passthrough/vtd/dmar.c |  8 +++++++
> >>  xen/include/asm-x86/hvm/domain.h   |  4 ++++
> >
> >I don't see ARM here? Should there be an ARM variant of this? If not
> 
> ARM doesn't need this feature.
> 
> >should the toolstack ones only run under x86?
> 
> And I think this shouldn't broken current ARM path as well. I mean this
> would return simply since ARM hasn't such a hypercall handler.
> 
> >
> >>  xen/include/public/domctl.h        | 21 +++++++++++++++++
> >>  xen/xsm/flask/hooks.c              |  1 +
> >>  15 files changed, 196 insertions(+)
> >>
> >>diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> >>index 622ea53..9adc41e 100644
> >>--- a/docs/man/xl.cfg.pod.5
> >>+++ b/docs/man/xl.cfg.pod.5
> >>@@ -645,6 +645,12 @@ dom0 without confirmation.  Please use with care.
> >>  D0-D3hot power management states for the PCI device. False (0) by
> >>  default.
> >>
> >>+=item B<rdmforce=BOOLEAN>
> >>+
> >>+(HVM/x86 only) Specifies that the VM would force to check and try to
> >
> >s/force/forced/
> 
> I guess you're saying 'be forced'.
> 
> >>+reserve all reserved device memory, like RMRR, associated to the PCI
> >>+device. False (0) by default.
> >
> >Not sure I understand. How would the VM be forced to do this? Or is
> >it that the hvmloader would force to do this? And if it fails (as you
> 
> Yes.
> 
> >say 'try') ? What then?
> 
> In most cases we can reserve these regions but if these RMRR regions overlap
> with some fixed range, like guest BIOS, we can't succeed in this case.
> 
> >
> >>+
> >>  =back
> >>
> >>  =back
> >>diff --git a/docs/misc/vtd.txt b/docs/misc/vtd.txt
> >>index 9af0e99..23544d5 100644
> >>--- a/docs/misc/vtd.txt
> >>+++ b/docs/misc/vtd.txt
> >>@@ -111,6 +111,21 @@ in the config file:
> >>  To override for a specific device:
> >>  	pci = [ '01:00.0,msitranslate=0', '03:00.0' ]
> >>
> >>+RDM, 'reserved device memory', for PCI Device Passthrough
> >>+---------------------------------------------------------
> >>+
> >>+The BIOS controls some devices in terms of some reginos of memory used for
> >
> >Could you elaborate what 'some devices' are? Network cards? GPUs? What
> >are the most commons ones.
> 
> Some legacy USB device to perform PS2 emulation, and GPU has a stolen memory
> as I remember.
> 
> >
> >s/reginos/regions/
> 
> Fixed.
> 
> >
> >And by regions you mean BAR regions?
> 
> No. I guess you want to know some background about RMRR :)
> 
> There's a good brief description in Linux:
> 
> What is RMRR?
> -------------
> 
> There are some devices the BIOS controls, for e.g USB devices to perform
> PS2 emulation. The regions of memory used for these devices are marked
> reserved in the e820 map. When we turn on DMA translation, DMA to those
> regions will fail. Hence BIOS uses RMRR to specify these regions along with
> devices that need to access these regions. OS is expected to setup
> unity mappings for these regions for these devices to access these regions.
> 
> >
> >>+these devices. This kind of region should be reserved before creating a VM
> >>+to make sure they are not occupied by RAM/MMIO to conflict, and also we can
> >
> >You said 'This' but here you are using the plural ' are'. IF you want it plural
> >it needs to be 'These regions'
> 
> Thanks for your correction.
> 
> >>+create necessary IOMMU table successfully.
> >>+
> >>+To enable this globally, add "pci_rdmforce" in the config file:
> >>+
> >>+	pci_rdmforce = 1         (default is 0)
> >
> >The guest config file? Or /etc/xen/xl.conf ?
> 
> The guest config file. Here I just follow something about 'pci_msitranslate'
> since they have that usage in common.
> 
> >
> >>+
> >>+Or just enable for a specific device:
> >>+	pci = [ '01:00.0,rdmforce=1', '03:00.0' ]
> >>+
> >>
> >>  Caveat on Conventional PCI Device Passthrough
> >>  ---------------------------------------------
> >>diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> 
> [snip]
> 
> >>--- a/xen/drivers/passthrough/pci.c
> >>+++ b/xen/drivers/passthrough/pci.c
> >>@@ -34,6 +34,7 @@
> >>  #include <xen/tasklet.h>
> >>  #include <xsm/xsm.h>
> >>  #include <asm/msi.h>
> >>+#include <xen/stdbool.h>
> >>
> >>  struct pci_seg {
> >>      struct list_head alldevs_list;
> >>@@ -1553,6 +1554,44 @@ 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 = NULL;
> >>+        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
> >>+
> >>+        if ( d == NULL )
> >>+            return -ESRCH;
> >>+
> >
> >What if this is called on an PV domain?
> 
> Currently we just support this in HVM, so I'd like to add this,
> 
>          if ( d == NULL )
>              return -ESRCH;
> 
> +        ASSERT( is_hvm_domain(d) );
> +

No. Please don't crash the hypervisor.

Just return -ENOSYS or such when done for PV guests.

> 
> >
> >You are also missing the XSM checks.
> 
> Just see this below.
> 
> >
> >What if this is called multiple times. Is it OK to over-ride
> >the 'pci_force' or should it stick once?
> 
> It should be fine since just xc/hvmloader need such an information while
> creating a VM.
> 
> And especially, currently we just call this one time to set. So why we need
> to call this again and again? I think if anyone want to extend such a case
> you're worrying, he should know any effect before he take a action, right?

Program defensively and also think about preemption. If this call end up
being preempted you might need to call it again. Or if the third-party
toolstack use this operation and call this with wacky values?
> 
> >
> >
> >>+        d->arch.hvm_domain.pci_force =
> >>+                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;
> >
> >Won't we crash here if this is called for PV guests?
> 
> After the line, 'ASSERT( is_hvm_domain(d) );', is added, this problem should
> be gone.

No it won't be. You will just crash the hypervisor.

Please please put yourself in the mind that the toolstack can (and will)
have bugs.
> 
> >
> >>+        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;
> >
> >What if the 'num_pcidevs' has some bogus value. You need to check for that.
> 
> This value is grabbed from that existing interface, assign_device, so I mean
> this is already checked.
> 
> >
> >
> >>+        d->arch.hvm_domain.pcidevs = NULL;
> >
> >Please first free it. It might be that the toolstack
> >is doing this a couple of times. You don't want to leak memory.
> >
> 
> Okay,
> 
> +        if ( d->arch.hvm_domain.pcidevs )
> +            xfree(d->arch.hvm_domain.pcidevs);
> 
> >
> >>+
> >>+        if ( xdsr->num_pcidevs )
> >>+        {
> >>+            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
> >>+                                    xdsr->num_pcidevs);
> >>+            if ( pcidevs == NULL )
> >>+            {
> >>+                rcu_unlock_domain(d);
> >>+                return -ENOMEM;
> >
> >But you already have set 'num_pcidevs' to some value. This copying/check
> >should be done before you modify 'd->arch.hvm_domain'...
> 
> This makes sense so I'll move down this fragment.
> 
> >>+            }
> >>+
> >>+            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
> >>+                                 xdsr->num_pcidevs*sizeof(*pcidevs)) )
> >>+            {
> >>+                xfree(pcidevs);
> >>+                rcu_unlock_domain(d);
> >
> >Ditto. You need to do these checks before you modify 'd->arch.hvm_domain'.
> >
> >>+                return -EFAULT;
> >>+            }
> >>+        }
> >>+
> >>+        d->arch.hvm_domain.pcidevs = pcidevs;
> >>+        rcu_unlock_domain(d);
> >>+    }
> >>+        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 1152c3a..5e41e7a 100644
> >>--- a/xen/drivers/passthrough/vtd/dmar.c
> >>+++ b/xen/drivers/passthrough/vtd/dmar.c
> >>@@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
> >>                          "  RMRR region: base_addr %"PRIx64
> >>                          " end_address %"PRIx64"\n",
> >>                          rmrru->base_address, rmrru->end_address);
> >>+            /*
> >>+             * TODO: we may provide a precise paramter just to reserve
> >
> >s/paramter/parameter/
> 
> Fixed.
> 
> >>+             * RMRR range specific to one device.
> >>+             */
> >>+            dprintk(XENLOG_WARNING VTDPREFIX,
> >>+                    "So please set pci_rdmforce to reserve these ranges"
> >>+                    " if you need such a device in hotplug case.\n");
> 
> s/hotplug/passthrough
> 
> >
> >'Please set rdmforce to reserve ranges %lx->%lx if you plan to hotplug this device.'
> >
> >But then this is going to be a bit verbose, so perhaps:
> >
> >'Ranges %lx-%lx need rdmforce to properly work.' ?
> 
> Its unnecessary to output range again since we already have such a print
> message here.
> 
> >
> >>+
> >>              acpi_register_rmrr_unit(rmrru);
> >>          }
> >>      }
> >>diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
> >>index 2757c7f..38530e5 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;
> >>
> >
> >Maybe a comment explaining its purpose?
> 
> Okay.
> 
> /* Force to check/reserve Reserved Device Memory. */
>     bool_t                  pci_force;
> 
> >
> >>+    bool_t                  pci_force;
> >>+    uint32_t                num_pcidevs;
> >>+    struct xen_guest_pcidev_info      *pcidevs;
> >>+
> >
> >You are also missing freeing of this in the hypervisor when the guest
> >is destroyed. Please fix that.
> 
> You're right. I will go there next revision.
> 
> >
> >>      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 57e2ed7..ba8970d 100644
> >>--- a/xen/include/public/domctl.h
> >>+++ b/xen/include/public/domctl.h
> >>@@ -508,6 +508,25 @@ struct xen_domctl_get_device_group {
> >>  typedef struct xen_domctl_get_device_group xen_domctl_get_device_group_t;
> >>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_get_device_group_t);
> >>
> >>+/* Currently just one bit to indicate force to check Reserved Device Memory. */
> >
> >Not sure I understand. Did you mean:
> >
> >'Check Reserved Device Memory'.
> 
> I can change this as '...force checking Reserved Device Memory.'
> 
> >
> >What happens if you do not have this flag? What are the semantics
> >of this hypercall - as in what will it mean.
> 
> If we have no this flag, these devices owned RMRR can't work in passthrough
> case.
> 
> >
> >>+#define PCI_DEV_RDM_CHECK   0x1
> >>+struct xen_guest_pcidev_info {
> >>+    uint16_t    seg;
> >>+    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;
> >
> >What is this 'flags' purpose compared to the 'pcidevs.flags'? Please
> >explain.
> 
> I replied something to Kevin, and we just need a global flag so we can
> remove pcidevs.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);
> >>+
> >>  /* Pass-through interrupts: bind real irq -> hvm devfn. */
> >>  /* XEN_DOMCTL_bind_pt_irq */
> >>  /* XEN_DOMCTL_unbind_pt_irq */
> >>@@ -1070,6 +1089,7 @@ struct xen_domctl {
> >>  #define XEN_DOMCTL_setvnumainfo                  74
> >>  #define XEN_DOMCTL_psr_cmt_op                    75
> >>  #define XEN_DOMCTL_arm_configure_domain          76
> >>+#define XEN_DOMCTL_set_rdm                       77
> >>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
> >>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
> >>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> >>@@ -1135,6 +1155,7 @@ struct xen_domctl {
> >>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
> >>          struct xen_domctl_vnuma             vnuma;
> >>          struct xen_domctl_psr_cmt_op        psr_cmt_op;
> >>+        struct xen_domctl_set_rdm           set_rdm;
> >>          uint8_t                             pad[128];
> >>      } u;
> >>  };
> >>diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> >>index d48463f..5a760e2 100644
> >>--- a/xen/xsm/flask/hooks.c
> >>+++ b/xen/xsm/flask/hooks.c
> >>@@ -592,6 +592,7 @@ static int flask_domctl(struct domain *d, int cmd)
> >>      case XEN_DOMCTL_test_assign_device:
> >>      case XEN_DOMCTL_assign_device:
> >>      case XEN_DOMCTL_deassign_device:
> >>+    case XEN_DOMCTL_set_rdm:
> >
> >There is more to XSM than just this file..
> 
> But I don't see more other stuff, like XEN_DOMCTL_assign_device.
> 
> >
> >Please compile with XSM enabled.
> 
> Anyway, I add XSM_ENABLE = y and FLASK_ENABLE = y in Config.mk then
> recompile, but looks good.
> 
> Anything I'm missing?

Ah, then it is fine!

> 
> >>  #endif
> >>          return 0;
> >
> >
> >Also how does this work with 32-bit dom0s? Is there a need to use the
> >compat layer?
> 
> Are you saying in xsm case? Others?
> 
> Actually this new DOMCTL is similar with XEN_DOMCTL_assign_device in some
> senses but I don't see such an issue you're pointing.

I was thinking about the compat layer and making sure it works properly.
> 
> 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 Dec 08 15:58:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 15: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 1Xy0hE-0006yp-Ne; Mon, 08 Dec 2014 15:58:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xy0hD-0006yk-7D
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 15:57:59 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	A1/1A-14727-68AC5845; Mon, 08 Dec 2014 15:57:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418054267!12152701!1
X-Originating-IP: [156.151.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 6215 invoked from network); 8 Dec 2014 15:57:48 -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; 8 Dec 2014 15:57: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 sB8FvacK028300
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 15:57:37 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
	sB8FvY55028075
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 15:57:35 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
	sB8FvXZg004219; Mon, 8 Dec 2014 15:57:33 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 07:57:33 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4B4B11201EC; Mon,  8 Dec 2014 10:57:34 -0500 (EST)
Date: Mon, 8 Dec 2014 10:57:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141208155734.GE7745@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<20141202193943.GC357@laptop.dumpdata.com>
	<548517F7.6040106@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548517F7.6040106@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 11:16:07AM +0800, Chen, Tiejun wrote:
> 
> On 2014/12/3 3:39, Konrad Rzeszutek Wilk wrote:
> >On Mon, Dec 01, 2014 at 05:24:20PM +0800, Tiejun Chen wrote:
> >>This should be based on a new parameter globally, 'pci_rdmforce'.
> >>
> >>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 this domctl provides an approach to control how to populate
> >>reserved device memory by tools.
> >>
> >>Note we always post a message to user about this once we owns
> >>RMRR.
> >>
> >>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>---
> >>  docs/man/xl.cfg.pod.5              |  6 +++++
> >>  docs/misc/vtd.txt                  | 15 ++++++++++++
> >>  tools/libxc/include/xenctrl.h      |  6 +++++
> >>  tools/libxc/xc_domain.c            | 28 +++++++++++++++++++++++
> >>  tools/libxl/libxl_create.c         |  3 +++
> >>  tools/libxl/libxl_dm.c             | 47 ++++++++++++++++++++++++++++++++++++++
> >>  tools/libxl/libxl_internal.h       |  4 ++++
> >>  tools/libxl/libxl_types.idl        |  2 ++
> >>  tools/libxl/libxlu_pci.c           |  2 ++
> >>  tools/libxl/xl_cmdimpl.c           | 10 ++++++++
> >
> >In the past we had split the hypervisor and the
> >toolstack patches in two. So that one could focus
> >on the hypervisor ones first, and then in another
> >patch on the toolstack.
> >
> 
> Yes.
> 
> >But perhaps this was intended to be in one patch?
> 
> This change also involve docs so its little bit harder to understand the
> whole page if we split this.
> 
> >
> >>  xen/drivers/passthrough/pci.c      | 39 +++++++++++++++++++++++++++++++
> >>  xen/drivers/passthrough/vtd/dmar.c |  8 +++++++
> >>  xen/include/asm-x86/hvm/domain.h   |  4 ++++
> >
> >I don't see ARM here? Should there be an ARM variant of this? If not
> 
> ARM doesn't need this feature.
> 
> >should the toolstack ones only run under x86?
> 
> And I think this shouldn't broken current ARM path as well. I mean this
> would return simply since ARM hasn't such a hypercall handler.
> 
> >
> >>  xen/include/public/domctl.h        | 21 +++++++++++++++++
> >>  xen/xsm/flask/hooks.c              |  1 +
> >>  15 files changed, 196 insertions(+)
> >>
> >>diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> >>index 622ea53..9adc41e 100644
> >>--- a/docs/man/xl.cfg.pod.5
> >>+++ b/docs/man/xl.cfg.pod.5
> >>@@ -645,6 +645,12 @@ dom0 without confirmation.  Please use with care.
> >>  D0-D3hot power management states for the PCI device. False (0) by
> >>  default.
> >>
> >>+=item B<rdmforce=BOOLEAN>
> >>+
> >>+(HVM/x86 only) Specifies that the VM would force to check and try to
> >
> >s/force/forced/
> 
> I guess you're saying 'be forced'.
> 
> >>+reserve all reserved device memory, like RMRR, associated to the PCI
> >>+device. False (0) by default.
> >
> >Not sure I understand. How would the VM be forced to do this? Or is
> >it that the hvmloader would force to do this? And if it fails (as you
> 
> Yes.
> 
> >say 'try') ? What then?
> 
> In most cases we can reserve these regions but if these RMRR regions overlap
> with some fixed range, like guest BIOS, we can't succeed in this case.
> 
> >
> >>+
> >>  =back
> >>
> >>  =back
> >>diff --git a/docs/misc/vtd.txt b/docs/misc/vtd.txt
> >>index 9af0e99..23544d5 100644
> >>--- a/docs/misc/vtd.txt
> >>+++ b/docs/misc/vtd.txt
> >>@@ -111,6 +111,21 @@ in the config file:
> >>  To override for a specific device:
> >>  	pci = [ '01:00.0,msitranslate=0', '03:00.0' ]
> >>
> >>+RDM, 'reserved device memory', for PCI Device Passthrough
> >>+---------------------------------------------------------
> >>+
> >>+The BIOS controls some devices in terms of some reginos of memory used for
> >
> >Could you elaborate what 'some devices' are? Network cards? GPUs? What
> >are the most commons ones.
> 
> Some legacy USB device to perform PS2 emulation, and GPU has a stolen memory
> as I remember.
> 
> >
> >s/reginos/regions/
> 
> Fixed.
> 
> >
> >And by regions you mean BAR regions?
> 
> No. I guess you want to know some background about RMRR :)
> 
> There's a good brief description in Linux:
> 
> What is RMRR?
> -------------
> 
> There are some devices the BIOS controls, for e.g USB devices to perform
> PS2 emulation. The regions of memory used for these devices are marked
> reserved in the e820 map. When we turn on DMA translation, DMA to those
> regions will fail. Hence BIOS uses RMRR to specify these regions along with
> devices that need to access these regions. OS is expected to setup
> unity mappings for these regions for these devices to access these regions.
> 
> >
> >>+these devices. This kind of region should be reserved before creating a VM
> >>+to make sure they are not occupied by RAM/MMIO to conflict, and also we can
> >
> >You said 'This' but here you are using the plural ' are'. IF you want it plural
> >it needs to be 'These regions'
> 
> Thanks for your correction.
> 
> >>+create necessary IOMMU table successfully.
> >>+
> >>+To enable this globally, add "pci_rdmforce" in the config file:
> >>+
> >>+	pci_rdmforce = 1         (default is 0)
> >
> >The guest config file? Or /etc/xen/xl.conf ?
> 
> The guest config file. Here I just follow something about 'pci_msitranslate'
> since they have that usage in common.
> 
> >
> >>+
> >>+Or just enable for a specific device:
> >>+	pci = [ '01:00.0,rdmforce=1', '03:00.0' ]
> >>+
> >>
> >>  Caveat on Conventional PCI Device Passthrough
> >>  ---------------------------------------------
> >>diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> 
> [snip]
> 
> >>--- a/xen/drivers/passthrough/pci.c
> >>+++ b/xen/drivers/passthrough/pci.c
> >>@@ -34,6 +34,7 @@
> >>  #include <xen/tasklet.h>
> >>  #include <xsm/xsm.h>
> >>  #include <asm/msi.h>
> >>+#include <xen/stdbool.h>
> >>
> >>  struct pci_seg {
> >>      struct list_head alldevs_list;
> >>@@ -1553,6 +1554,44 @@ 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 = NULL;
> >>+        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
> >>+
> >>+        if ( d == NULL )
> >>+            return -ESRCH;
> >>+
> >
> >What if this is called on an PV domain?
> 
> Currently we just support this in HVM, so I'd like to add this,
> 
>          if ( d == NULL )
>              return -ESRCH;
> 
> +        ASSERT( is_hvm_domain(d) );
> +

No. Please don't crash the hypervisor.

Just return -ENOSYS or such when done for PV guests.

> 
> >
> >You are also missing the XSM checks.
> 
> Just see this below.
> 
> >
> >What if this is called multiple times. Is it OK to over-ride
> >the 'pci_force' or should it stick once?
> 
> It should be fine since just xc/hvmloader need such an information while
> creating a VM.
> 
> And especially, currently we just call this one time to set. So why we need
> to call this again and again? I think if anyone want to extend such a case
> you're worrying, he should know any effect before he take a action, right?

Program defensively and also think about preemption. If this call end up
being preempted you might need to call it again. Or if the third-party
toolstack use this operation and call this with wacky values?
> 
> >
> >
> >>+        d->arch.hvm_domain.pci_force =
> >>+                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;
> >
> >Won't we crash here if this is called for PV guests?
> 
> After the line, 'ASSERT( is_hvm_domain(d) );', is added, this problem should
> be gone.

No it won't be. You will just crash the hypervisor.

Please please put yourself in the mind that the toolstack can (and will)
have bugs.
> 
> >
> >>+        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;
> >
> >What if the 'num_pcidevs' has some bogus value. You need to check for that.
> 
> This value is grabbed from that existing interface, assign_device, so I mean
> this is already checked.
> 
> >
> >
> >>+        d->arch.hvm_domain.pcidevs = NULL;
> >
> >Please first free it. It might be that the toolstack
> >is doing this a couple of times. You don't want to leak memory.
> >
> 
> Okay,
> 
> +        if ( d->arch.hvm_domain.pcidevs )
> +            xfree(d->arch.hvm_domain.pcidevs);
> 
> >
> >>+
> >>+        if ( xdsr->num_pcidevs )
> >>+        {
> >>+            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
> >>+                                    xdsr->num_pcidevs);
> >>+            if ( pcidevs == NULL )
> >>+            {
> >>+                rcu_unlock_domain(d);
> >>+                return -ENOMEM;
> >
> >But you already have set 'num_pcidevs' to some value. This copying/check
> >should be done before you modify 'd->arch.hvm_domain'...
> 
> This makes sense so I'll move down this fragment.
> 
> >>+            }
> >>+
> >>+            if ( copy_from_guest(pcidevs, xdsr->pcidevs,
> >>+                                 xdsr->num_pcidevs*sizeof(*pcidevs)) )
> >>+            {
> >>+                xfree(pcidevs);
> >>+                rcu_unlock_domain(d);
> >
> >Ditto. You need to do these checks before you modify 'd->arch.hvm_domain'.
> >
> >>+                return -EFAULT;
> >>+            }
> >>+        }
> >>+
> >>+        d->arch.hvm_domain.pcidevs = pcidevs;
> >>+        rcu_unlock_domain(d);
> >>+    }
> >>+        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 1152c3a..5e41e7a 100644
> >>--- a/xen/drivers/passthrough/vtd/dmar.c
> >>+++ b/xen/drivers/passthrough/vtd/dmar.c
> >>@@ -674,6 +674,14 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
> >>                          "  RMRR region: base_addr %"PRIx64
> >>                          " end_address %"PRIx64"\n",
> >>                          rmrru->base_address, rmrru->end_address);
> >>+            /*
> >>+             * TODO: we may provide a precise paramter just to reserve
> >
> >s/paramter/parameter/
> 
> Fixed.
> 
> >>+             * RMRR range specific to one device.
> >>+             */
> >>+            dprintk(XENLOG_WARNING VTDPREFIX,
> >>+                    "So please set pci_rdmforce to reserve these ranges"
> >>+                    " if you need such a device in hotplug case.\n");
> 
> s/hotplug/passthrough
> 
> >
> >'Please set rdmforce to reserve ranges %lx->%lx if you plan to hotplug this device.'
> >
> >But then this is going to be a bit verbose, so perhaps:
> >
> >'Ranges %lx-%lx need rdmforce to properly work.' ?
> 
> Its unnecessary to output range again since we already have such a print
> message here.
> 
> >
> >>+
> >>              acpi_register_rmrr_unit(rmrru);
> >>          }
> >>      }
> >>diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
> >>index 2757c7f..38530e5 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;
> >>
> >
> >Maybe a comment explaining its purpose?
> 
> Okay.
> 
> /* Force to check/reserve Reserved Device Memory. */
>     bool_t                  pci_force;
> 
> >
> >>+    bool_t                  pci_force;
> >>+    uint32_t                num_pcidevs;
> >>+    struct xen_guest_pcidev_info      *pcidevs;
> >>+
> >
> >You are also missing freeing of this in the hypervisor when the guest
> >is destroyed. Please fix that.
> 
> You're right. I will go there next revision.
> 
> >
> >>      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 57e2ed7..ba8970d 100644
> >>--- a/xen/include/public/domctl.h
> >>+++ b/xen/include/public/domctl.h
> >>@@ -508,6 +508,25 @@ struct xen_domctl_get_device_group {
> >>  typedef struct xen_domctl_get_device_group xen_domctl_get_device_group_t;
> >>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_get_device_group_t);
> >>
> >>+/* Currently just one bit to indicate force to check Reserved Device Memory. */
> >
> >Not sure I understand. Did you mean:
> >
> >'Check Reserved Device Memory'.
> 
> I can change this as '...force checking Reserved Device Memory.'
> 
> >
> >What happens if you do not have this flag? What are the semantics
> >of this hypercall - as in what will it mean.
> 
> If we have no this flag, these devices owned RMRR can't work in passthrough
> case.
> 
> >
> >>+#define PCI_DEV_RDM_CHECK   0x1
> >>+struct xen_guest_pcidev_info {
> >>+    uint16_t    seg;
> >>+    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;
> >
> >What is this 'flags' purpose compared to the 'pcidevs.flags'? Please
> >explain.
> 
> I replied something to Kevin, and we just need a global flag so we can
> remove pcidevs.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);
> >>+
> >>  /* Pass-through interrupts: bind real irq -> hvm devfn. */
> >>  /* XEN_DOMCTL_bind_pt_irq */
> >>  /* XEN_DOMCTL_unbind_pt_irq */
> >>@@ -1070,6 +1089,7 @@ struct xen_domctl {
> >>  #define XEN_DOMCTL_setvnumainfo                  74
> >>  #define XEN_DOMCTL_psr_cmt_op                    75
> >>  #define XEN_DOMCTL_arm_configure_domain          76
> >>+#define XEN_DOMCTL_set_rdm                       77
> >>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
> >>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
> >>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> >>@@ -1135,6 +1155,7 @@ struct xen_domctl {
> >>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
> >>          struct xen_domctl_vnuma             vnuma;
> >>          struct xen_domctl_psr_cmt_op        psr_cmt_op;
> >>+        struct xen_domctl_set_rdm           set_rdm;
> >>          uint8_t                             pad[128];
> >>      } u;
> >>  };
> >>diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> >>index d48463f..5a760e2 100644
> >>--- a/xen/xsm/flask/hooks.c
> >>+++ b/xen/xsm/flask/hooks.c
> >>@@ -592,6 +592,7 @@ static int flask_domctl(struct domain *d, int cmd)
> >>      case XEN_DOMCTL_test_assign_device:
> >>      case XEN_DOMCTL_assign_device:
> >>      case XEN_DOMCTL_deassign_device:
> >>+    case XEN_DOMCTL_set_rdm:
> >
> >There is more to XSM than just this file..
> 
> But I don't see more other stuff, like XEN_DOMCTL_assign_device.
> 
> >
> >Please compile with XSM enabled.
> 
> Anyway, I add XSM_ENABLE = y and FLASK_ENABLE = y in Config.mk then
> recompile, but looks good.
> 
> Anything I'm missing?

Ah, then it is fine!

> 
> >>  #endif
> >>          return 0;
> >
> >
> >Also how does this work with 32-bit dom0s? Is there a need to use the
> >compat layer?
> 
> Are you saying in xsm case? Others?
> 
> Actually this new DOMCTL is similar with XEN_DOMCTL_assign_device in some
> senses but I don't see such an issue you're pointing.

I was thinking about the compat layer and making sure it works properly.
> 
> 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 Dec 08 16:00:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16: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 1Xy0jF-0007Nz-K4; Mon, 08 Dec 2014 16:00:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1Xy0jE-0007I3-3b
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 16:00:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	17/E3-25276-30BC5845; Mon, 08 Dec 2014 16:00:03 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418054402!14203462!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 22261 invoked from network); 8 Dec 2014 16:00:02 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 16:00:02 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=Jdjx00K/9waeaZd05l2ZEbsjYcVwl7arRf1eopMvAi6MzjXSjKnfXnMLc1zDzpnN5d9j5pmUjoXTfsfVrj+docljLS6ZSS1VGlR0NQ/TvvU5lTxPQC5Cx5IEb8UkxRRHp32wzJ7tsBdmXg/jzumZ48tK+2qlTC3kLgAbrQjXJR6LVTnjh6XiH9KT2okKt5ZFFvpvwqWhzYmHrIIS/iZwz1rK6v3+r18H62bia54t9aFibc4gz5afc5dR/evjMdmaz+k8M+Qz5XMyaX2H07Okf1jtB3X7AVVbR4KxpFQz9fOsijVHDXItg8BZ6ElcQsEtgumTOu7CNesTXdOsaRctKA==;
	h=Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:cc:subject:message-id:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	bh=ZdLoo0MqP0/4N+/3gppubmDWfg4=; b=ahf4vP3w+czyq0PwxKX2hdxp62eM
	oHe8Y/Oa5/12DcVcgxiQ6Rw7K4M1svmGvY8CvQ1nbWuCUrEu/MhbMjQ82KmL/TcX
	rO/kHHJwNSsHnzOronv9OB9py8YWuAFXxD6iXY6AOdd9I6itTJphNX8pRVxBVXB1
	6ydfhR8merpeJlUCpfoibqQOFz702V0X/0xyWWSm038uj6qr5irJ3g6Z0N4RW3WO
	1Q1UH+JLf6yT6m5PAPWTjhzN3tpZTs3X2CPQH4GVrGZXDfgdBDCfzfcCDS7vZava
	D2EyhYsjH377wyl2sYXD2U9FDn/y/U9gzGKiQAMZ93hWKrxEPpCiMMFp4A==
Received: (qmail 25572 invoked from network); 8 Dec 2014 18:00:01 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	8 Dec 2014 18:00:01 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 509BB80361
	for <xen-devel@lists.xenproject.org>;
	Mon,  8 Dec 2014 18:00:01 +0200 (EET)
Received: (qmail 11326 invoked from network); 8 Dec 2014 18:00:01 +0200
Received: from unknown (HELO bitdefender.com)
	(mdontu@bitdefender.com@195.210.5.22)
	by smtp02.buh.bitdefender.net with SMTP; 8 Dec 2014 18:00:01 +0200
Date: Mon, 8 Dec 2014 18:00:01 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20141208180001.086cb5e6@bitdefender.com>
In-Reply-To: <548588E9020000780004DAF4@mail.emea.novell.com>
References: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
	<548588E9020000780004DAF4@mail.emea.novell.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.58177
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374382,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_LARGISH_BIGGISH;
	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: v2.1.2; Id: 2m1ghdn.198l25704.r74l],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uZGF5IDA4IERlY2VtYmVyIDIwMTQgMTA6MTg6MDEgSmFuIEJldWxpY2ggd3JvdGU6Cj4g
Pj4+IE9uIDA4LjEyLjE0IGF0IDAzOjMwLCA8bWRvbnR1QGJpdGRlZmVuZGVyLmNvbT4gd3JvdGU6
Cj4gPiArI2lmbmRlZiBOREVCVUcKPiA+ICtzdGF0aWMgYm9vbF90IHhtZW1fcG9vbF9jaGVja19z
aXplKGNvbnN0IHN0cnVjdCBiaGRyICpiLCBpbnQgZmwsIGludCBzbCkKPiA+ICt7Cj4gPiArICAg
IHdoaWxlICggYiApCj4gPiArICAgIHsKPiA+ICsgICAgICAgIGludCBfX2ZsOwo+ID4gKyAgICAg
ICAgaW50IF9fc2w7Cj4gPiArCj4gPiArICAgICAgICBNQVBQSU5HX0lOU0VSVChiLT5zaXplLCAm
X19mbCwgJl9fc2wpOwo+ID4gKyAgICAgICAgaWYgKCBfX2ZsICE9IGZsIHx8IF9fc2wgIT0gc2wg
KQo+ID4gKyAgICAgICAgewo+ID4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4bWVt
X3Bvb2w6IGZvciBibG9jayAlcCBzaXplID0gJXUsIHsgZmwgPSAlZCwgc2wgPSAlZCB9IHNob3Vs
ZCBiZSB7IGZsID0gJWQsIHNsID0gJWQgfVxuIiwKPiAKPiBRdW90aW5nIG15IHJlcGx5IHRvIHYx
OiAiTG9uZyBsaW5lLiBPbmx5IHRoZSBmb3JtYXQgbWVzc2FnZSBhbG9uZQo+IGlzIGFsbG93ZWQg
dG8gZXhjZWVkIDgwIGNoYXJhY3RlcnMuIgo+IAoKSnVzdCBzbyBJIGRvbid0IHNlbmQgYW5vdGhl
ciBmYXVsdHkgcGF0Y2gsIHlvdSB3b3VsZCBzZWUgdGhhdCBwcmludGsoKQpiZWluZzoKCiAgcHJp
bnRrKFhFTkxPR19FUlIKICAgICAgICAgInhtZW1fcG9vbDogZm9yIGJsb2NrICVwIHNpemUgPSAl
dSwgeyBmbCA9ICVkLCBzbCA9ICVkIH0gc2hvdWxkIGJlIHsgZmwgPSAlZCwgc2wgPSAlZCB9XG4i
LAogICAgICAgICBiLCBiLT5zaXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOwoKPwoKPiBBbHNvIHdp
dGggdGhlcmUgcG90ZW50aWFsbHkgYmVpbmcgbXVsdGlwbGUgcG9vbHMsIHNob3VsZG4ndCBhbGwg
b2YgdGhlCj4gbG9nIG1lc3NhZ2VzIHRoZSBwYXRjaCBpc3N1ZXMgYmUgZXh0ZW5kZWQgdG8gYWxs
b3cgaWRlbnRpZnlpbmcgdGhlCj4gb2ZmZW5kaW5nIG9uZT8KPiAKCkkgdGhpbmsgSSBjYW4gaW5z
ZXJ0IHRoZSBwb29sIG5hbWUgaW4gdGhhdCBtZXNzYWdlIHRvby4gU29tZXRoaW5nIGxpa2U6Cgog
IHByaW50ayhYRU5MT0dfRVJSCiAgICAgICAgICJ4bWVtX3Bvb2w6ICVzOiBmb3IgYmxvY2sgWy4u
Ll1cbiIsCiAgICAgICAgIHBvb2wtPm5hbWUsIGIsIGItPnNpemUgWy4uLl0pOwoKd291bGQgZG8/
IEEgcXVpY2sgcHJldmlldzoKClsyMDE0LTEyLTA0IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3
MTI1XSB4bWVtX3Bvb2w6IHhtYWxsb2M6IGZvciBibG9jayBmZmZmODMwNDAwNGZiOWIwIHNpemUg
PSAwLCB7IGZsID0gMywgc2wgPSA5IH0gc2hvdWxkIGJlIHsgZmwgPSAwLCBzbCA9IDAgfQpbMjAx
NC0xMi0wNCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzEyN10geG1lbV9wb29sOiB4bWFsbG9j
OiB0aGUgVExTRiBjaHVuayBtYXRyaXggaXMgY29ycnVwdGVkCgo+ID4gK2Jvb2xfdCBfX3htZW1f
cG9vbF9jaGVjayhjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgc3RydWN0IHhtZW1fcG9vbCAq
cG9vbCkKPiA+ICt7Cj4gPiArICAgIHJldHVybiBfX3htZW1fcG9vbF9jaGVja191bmxvY2tlZChm
aWxlLCBsaW5lLCBwb29sID8gcG9vbCA6IHhlbnBvb2wpOwo+IAo+IEZvciBicmV2aXR5LCB0aGUg
c2hvcnRlciAicG9vbCA/OiB4ZW5wb29sIiBpcyBnZW5lcmFsbHkgcHJlZmVyYWJsZS4gVGhlCj4g
b25seSBwbGFjZSB1c2luZyB0aGlzIGlzIG5vdCBhbGxvd2VkIGFyZSB0aGUgcHVibGljIGhlYWRl
cnMuCj4gCgpXaWxsIGRvLgoKVGhhbmsgeW91LAoKLS0gCk1paGFpIERPTsiaVQoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:00:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16: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 1Xy0jF-0007Nz-K4; Mon, 08 Dec 2014 16:00:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1Xy0jE-0007I3-3b
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 16:00:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	17/E3-25276-30BC5845; Mon, 08 Dec 2014 16:00:03 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418054402!14203462!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 22261 invoked from network); 8 Dec 2014 16:00:02 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 16:00:02 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=Jdjx00K/9waeaZd05l2ZEbsjYcVwl7arRf1eopMvAi6MzjXSjKnfXnMLc1zDzpnN5d9j5pmUjoXTfsfVrj+docljLS6ZSS1VGlR0NQ/TvvU5lTxPQC5Cx5IEb8UkxRRHp32wzJ7tsBdmXg/jzumZ48tK+2qlTC3kLgAbrQjXJR6LVTnjh6XiH9KT2okKt5ZFFvpvwqWhzYmHrIIS/iZwz1rK6v3+r18H62bia54t9aFibc4gz5afc5dR/evjMdmaz+k8M+Qz5XMyaX2H07Okf1jtB3X7AVVbR4KxpFQz9fOsijVHDXItg8BZ6ElcQsEtgumTOu7CNesTXdOsaRctKA==;
	h=Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:cc:subject:message-id:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	bh=ZdLoo0MqP0/4N+/3gppubmDWfg4=; b=ahf4vP3w+czyq0PwxKX2hdxp62eM
	oHe8Y/Oa5/12DcVcgxiQ6Rw7K4M1svmGvY8CvQ1nbWuCUrEu/MhbMjQ82KmL/TcX
	rO/kHHJwNSsHnzOronv9OB9py8YWuAFXxD6iXY6AOdd9I6itTJphNX8pRVxBVXB1
	6ydfhR8merpeJlUCpfoibqQOFz702V0X/0xyWWSm038uj6qr5irJ3g6Z0N4RW3WO
	1Q1UH+JLf6yT6m5PAPWTjhzN3tpZTs3X2CPQH4GVrGZXDfgdBDCfzfcCDS7vZava
	D2EyhYsjH377wyl2sYXD2U9FDn/y/U9gzGKiQAMZ93hWKrxEPpCiMMFp4A==
Received: (qmail 25572 invoked from network); 8 Dec 2014 18:00:01 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	8 Dec 2014 18:00:01 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 509BB80361
	for <xen-devel@lists.xenproject.org>;
	Mon,  8 Dec 2014 18:00:01 +0200 (EET)
Received: (qmail 11326 invoked from network); 8 Dec 2014 18:00:01 +0200
Received: from unknown (HELO bitdefender.com)
	(mdontu@bitdefender.com@195.210.5.22)
	by smtp02.buh.bitdefender.net with SMTP; 8 Dec 2014 18:00:01 +0200
Date: Mon, 8 Dec 2014 18:00:01 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20141208180001.086cb5e6@bitdefender.com>
In-Reply-To: <548588E9020000780004DAF4@mail.emea.novell.com>
References: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
	<548588E9020000780004DAF4@mail.emea.novell.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.58177
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374382,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; NN_LARGISH_BIGGISH;
	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: v2.1.2; Id: 2m1ghdn.198l25704.r74l],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uZGF5IDA4IERlY2VtYmVyIDIwMTQgMTA6MTg6MDEgSmFuIEJldWxpY2ggd3JvdGU6Cj4g
Pj4+IE9uIDA4LjEyLjE0IGF0IDAzOjMwLCA8bWRvbnR1QGJpdGRlZmVuZGVyLmNvbT4gd3JvdGU6
Cj4gPiArI2lmbmRlZiBOREVCVUcKPiA+ICtzdGF0aWMgYm9vbF90IHhtZW1fcG9vbF9jaGVja19z
aXplKGNvbnN0IHN0cnVjdCBiaGRyICpiLCBpbnQgZmwsIGludCBzbCkKPiA+ICt7Cj4gPiArICAg
IHdoaWxlICggYiApCj4gPiArICAgIHsKPiA+ICsgICAgICAgIGludCBfX2ZsOwo+ID4gKyAgICAg
ICAgaW50IF9fc2w7Cj4gPiArCj4gPiArICAgICAgICBNQVBQSU5HX0lOU0VSVChiLT5zaXplLCAm
X19mbCwgJl9fc2wpOwo+ID4gKyAgICAgICAgaWYgKCBfX2ZsICE9IGZsIHx8IF9fc2wgIT0gc2wg
KQo+ID4gKyAgICAgICAgewo+ID4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4bWVt
X3Bvb2w6IGZvciBibG9jayAlcCBzaXplID0gJXUsIHsgZmwgPSAlZCwgc2wgPSAlZCB9IHNob3Vs
ZCBiZSB7IGZsID0gJWQsIHNsID0gJWQgfVxuIiwKPiAKPiBRdW90aW5nIG15IHJlcGx5IHRvIHYx
OiAiTG9uZyBsaW5lLiBPbmx5IHRoZSBmb3JtYXQgbWVzc2FnZSBhbG9uZQo+IGlzIGFsbG93ZWQg
dG8gZXhjZWVkIDgwIGNoYXJhY3RlcnMuIgo+IAoKSnVzdCBzbyBJIGRvbid0IHNlbmQgYW5vdGhl
ciBmYXVsdHkgcGF0Y2gsIHlvdSB3b3VsZCBzZWUgdGhhdCBwcmludGsoKQpiZWluZzoKCiAgcHJp
bnRrKFhFTkxPR19FUlIKICAgICAgICAgInhtZW1fcG9vbDogZm9yIGJsb2NrICVwIHNpemUgPSAl
dSwgeyBmbCA9ICVkLCBzbCA9ICVkIH0gc2hvdWxkIGJlIHsgZmwgPSAlZCwgc2wgPSAlZCB9XG4i
LAogICAgICAgICBiLCBiLT5zaXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOwoKPwoKPiBBbHNvIHdp
dGggdGhlcmUgcG90ZW50aWFsbHkgYmVpbmcgbXVsdGlwbGUgcG9vbHMsIHNob3VsZG4ndCBhbGwg
b2YgdGhlCj4gbG9nIG1lc3NhZ2VzIHRoZSBwYXRjaCBpc3N1ZXMgYmUgZXh0ZW5kZWQgdG8gYWxs
b3cgaWRlbnRpZnlpbmcgdGhlCj4gb2ZmZW5kaW5nIG9uZT8KPiAKCkkgdGhpbmsgSSBjYW4gaW5z
ZXJ0IHRoZSBwb29sIG5hbWUgaW4gdGhhdCBtZXNzYWdlIHRvby4gU29tZXRoaW5nIGxpa2U6Cgog
IHByaW50ayhYRU5MT0dfRVJSCiAgICAgICAgICJ4bWVtX3Bvb2w6ICVzOiBmb3IgYmxvY2sgWy4u
Ll1cbiIsCiAgICAgICAgIHBvb2wtPm5hbWUsIGIsIGItPnNpemUgWy4uLl0pOwoKd291bGQgZG8/
IEEgcXVpY2sgcHJldmlldzoKClsyMDE0LTEyLTA0IDE1OjQxOjIzXSAoWEVOKSBbIDEzNzQuNTA3
MTI1XSB4bWVtX3Bvb2w6IHhtYWxsb2M6IGZvciBibG9jayBmZmZmODMwNDAwNGZiOWIwIHNpemUg
PSAwLCB7IGZsID0gMywgc2wgPSA5IH0gc2hvdWxkIGJlIHsgZmwgPSAwLCBzbCA9IDAgfQpbMjAx
NC0xMi0wNCAxNTo0MToyM10gKFhFTikgWyAxMzc0LjUwNzEyN10geG1lbV9wb29sOiB4bWFsbG9j
OiB0aGUgVExTRiBjaHVuayBtYXRyaXggaXMgY29ycnVwdGVkCgo+ID4gK2Jvb2xfdCBfX3htZW1f
cG9vbF9jaGVjayhjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgc3RydWN0IHhtZW1fcG9vbCAq
cG9vbCkKPiA+ICt7Cj4gPiArICAgIHJldHVybiBfX3htZW1fcG9vbF9jaGVja191bmxvY2tlZChm
aWxlLCBsaW5lLCBwb29sID8gcG9vbCA6IHhlbnBvb2wpOwo+IAo+IEZvciBicmV2aXR5LCB0aGUg
c2hvcnRlciAicG9vbCA/OiB4ZW5wb29sIiBpcyBnZW5lcmFsbHkgcHJlZmVyYWJsZS4gVGhlCj4g
b25seSBwbGFjZSB1c2luZyB0aGlzIGlzIG5vdCBhbGxvd2VkIGFyZSB0aGUgcHVibGljIGhlYWRl
cnMuCj4gCgpXaWxsIGRvLgoKVGhhbmsgeW91LAoKLS0gCk1paGFpIERPTsiaVQoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:04:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:04:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy0nJ-0007uO-Ci; Mon, 08 Dec 2014 16:04:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xy0nI-0007u0-8m
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 16:04:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AB/41-09842-FFBC5845; Mon, 08 Dec 2014 16:04:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418054653!14204664!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23921 invoked from network); 8 Dec 2014 16:04:15 -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; 8 Dec 2014 16:04:15 -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 sB8G43aL007051
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 16:04: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
	sB8G41W6002050
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 16:04:03 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
	sB8G41hP022621; Mon, 8 Dec 2014 16:04:01 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 08:04:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1D7301201FC; Mon,  8 Dec 2014 11:04:02 -0500 (EST)
Date: Mon, 8 Dec 2014 11:04:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141208160402.GF7745@laptop.dumpdata.com>
References: <5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
	<1417707546.15750.100.camel@bling.home>
	<54818929.5000008@citrix.com>
	<20141205172250.GA2895@laptop.dumpdata.com>
	<54857F91.3020002@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54857F91.3020002@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Alex Williamson <alex.williamson@redhat.com>,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 10:38:09AM +0000, David Vrabel wrote:
> On 05/12/14 17:22, Konrad Rzeszutek Wilk wrote:
> > On Fri, Dec 05, 2014 at 10:30:01AM +0000, David Vrabel wrote:
> >> On 04/12/14 15:39, Alex Williamson wrote:
> >>>
> >>> I don't know what workaround you're talking about.  As devices are
> >>> released from the user, vfio-pci attempts to reset them.  If
> >>> pci_reset_function() returns success we mark the device clean, otherwise
> >>> it gets marked dirty.  Each time a device is released, if there are
> >>> dirty devices we test whether we can try a bus/slot reset to clean them.
> >>> In the case of assigning a GPU this typically means that the GPU or
> >>> audio function come through first, there's no reset mechanism so it gets
> >>> marked dirty, the next device comes through and we manage to try a bus
> >>> reset.  vfio-pci does not have any device specific resets, all
> >>> functionality is added to the PCI-core, thank-you-very-much.  I even
> >>> posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
> >>> bad so that pci_reset_function() won't claim that worked.  All VGA
> >>> access quirks are done in QEMU, the kernel doesn't have any business in
> >>> remapping config space over MMIO regions or trapping other config space
> >>> backdoors.
> >>
> >> Thanks for the info Alex, I hadn't got around to actually looking and
> >> the vfio-pci code and was just going to what Sander said.
> >>
> >> We probably do need to have a more in depth look at now PCI devices and
> >> handled by both the toolstack and pciback but in the short term I would
> >> like a simple solution that does not extend the ABI.
> > 
> > Could you enumerate the 'simple solution' then please? I am having
> > a frustrating time figuring out what it is that you are proposing.
> 
> I've posted it repeatedly.

Are you referring to http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg01270.html
which is still waiting for your feedback?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:04:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:04:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy0nJ-0007uO-Ci; Mon, 08 Dec 2014 16:04:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xy0nI-0007u0-8m
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 16:04:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AB/41-09842-FFBC5845; Mon, 08 Dec 2014 16:04:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418054653!14204664!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23921 invoked from network); 8 Dec 2014 16:04:15 -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; 8 Dec 2014 16:04:15 -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 sB8G43aL007051
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 16:04: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
	sB8G41W6002050
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 16:04:03 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
	sB8G41hP022621; Mon, 8 Dec 2014 16:04:01 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 08:04:01 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 1D7301201FC; Mon,  8 Dec 2014 11:04:02 -0500 (EST)
Date: Mon, 8 Dec 2014 11:04:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141208160402.GF7745@laptop.dumpdata.com>
References: <5480528F.8010106@citrix.com>
	<1107877503.20141204141054@eikelenboom.it>
	<548064EA.8090905@citrix.com>
	<308719815.20141204150909@eikelenboom.it>
	<5480702F.2060004@citrix.com>
	<1578910783.20141204155025@eikelenboom.it>
	<1417707546.15750.100.camel@bling.home>
	<54818929.5000008@citrix.com>
	<20141205172250.GA2895@laptop.dumpdata.com>
	<54857F91.3020002@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54857F91.3020002@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Alex Williamson <alex.williamson@redhat.com>,
	bhelgaas@google.com, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset
 slot or bus with 'do_flr' SysFS attribute
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 10:38:09AM +0000, David Vrabel wrote:
> On 05/12/14 17:22, Konrad Rzeszutek Wilk wrote:
> > On Fri, Dec 05, 2014 at 10:30:01AM +0000, David Vrabel wrote:
> >> On 04/12/14 15:39, Alex Williamson wrote:
> >>>
> >>> I don't know what workaround you're talking about.  As devices are
> >>> released from the user, vfio-pci attempts to reset them.  If
> >>> pci_reset_function() returns success we mark the device clean, otherwise
> >>> it gets marked dirty.  Each time a device is released, if there are
> >>> dirty devices we test whether we can try a bus/slot reset to clean them.
> >>> In the case of assigning a GPU this typically means that the GPU or
> >>> audio function come through first, there's no reset mechanism so it gets
> >>> marked dirty, the next device comes through and we manage to try a bus
> >>> reset.  vfio-pci does not have any device specific resets, all
> >>> functionality is added to the PCI-core, thank-you-very-much.  I even
> >>> posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
> >>> bad so that pci_reset_function() won't claim that worked.  All VGA
> >>> access quirks are done in QEMU, the kernel doesn't have any business in
> >>> remapping config space over MMIO regions or trapping other config space
> >>> backdoors.
> >>
> >> Thanks for the info Alex, I hadn't got around to actually looking and
> >> the vfio-pci code and was just going to what Sander said.
> >>
> >> We probably do need to have a more in depth look at now PCI devices and
> >> handled by both the toolstack and pciback but in the short term I would
> >> like a simple solution that does not extend the ABI.
> > 
> > Could you enumerate the 'simple solution' then please? I am having
> > a frustrating time figuring out what it is that you are proposing.
> 
> I've posted it repeatedly.

Are you referring to http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg01270.html
which is still waiting for your feedback?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:06:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:06:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy0pl-000826-Ty; Mon, 08 Dec 2014 16:06: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 1Xy0pj-00081w-U6
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 16:06:48 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	BE/0B-27785-79CC5845; Mon, 08 Dec 2014 16:06:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418054804!13746633!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 20145 invoked from network); 8 Dec 2014 16:06:46 -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;
	8 Dec 2014 16:06:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201457833"
Message-ID: <1418054695.2827.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mihai =?UTF-8?Q?Don=C8=9Bu?= <mdontu@bitdefender.com>
Date: Mon, 8 Dec 2014 16:04:55 +0000
In-Reply-To: <20141208180001.086cb5e6@bitdefender.com>
References: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
	<548588E9020000780004DAF4@mail.emea.novell.com>
	<20141208180001.086cb5e6@bitdefender.com>
Organization: Citrix Systems, Inc.
Content-Length: 1796
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDE0LTEyLTA4IGF0IDE4OjAwICswMjAwLCBNaWhhaSBEb27Im3Ugd3JvdGU6Cj4g
T24gTW9uZGF5IDA4IERlY2VtYmVyIDIwMTQgMTA6MTg6MDEgSmFuIEJldWxpY2ggd3JvdGU6Cj4g
PiA+Pj4gT24gMDguMTIuMTQgYXQgMDM6MzAsIDxtZG9udHVAYml0ZGVmZW5kZXIuY29tPiB3cm90
ZToKPiA+ID4gKyNpZm5kZWYgTkRFQlVHCj4gPiA+ICtzdGF0aWMgYm9vbF90IHhtZW1fcG9vbF9j
aGVja19zaXplKGNvbnN0IHN0cnVjdCBiaGRyICpiLCBpbnQgZmwsIGludCBzbCkKPiA+ID4gK3sK
PiA+ID4gKyAgICB3aGlsZSAoIGIgKQo+ID4gPiArICAgIHsKPiA+ID4gKyAgICAgICAgaW50IF9f
Zmw7Cj4gPiA+ICsgICAgICAgIGludCBfX3NsOwo+ID4gPiArCj4gPiA+ICsgICAgICAgIE1BUFBJ
TkdfSU5TRVJUKGItPnNpemUsICZfX2ZsLCAmX19zbCk7Cj4gPiA+ICsgICAgICAgIGlmICggX19m
bCAhPSBmbCB8fCBfX3NsICE9IHNsICkKPiA+ID4gKyAgICAgICAgewo+ID4gPiArICAgICAgICAg
ICAgcHJpbnRrKFhFTkxPR19FUlIgInhtZW1fcG9vbDogZm9yIGJsb2NrICVwIHNpemUgPSAldSwg
eyBmbCA9ICVkLCBzbCA9ICVkIH0gc2hvdWxkIGJlIHsgZmwgPSAlZCwgc2wgPSAlZCB9XG4iLAo+
ID4gCj4gPiBRdW90aW5nIG15IHJlcGx5IHRvIHYxOiAiTG9uZyBsaW5lLiBPbmx5IHRoZSBmb3Jt
YXQgbWVzc2FnZSBhbG9uZQo+ID4gaXMgYWxsb3dlZCB0byBleGNlZWQgODAgY2hhcmFjdGVycy4i
Cj4gPiAKPiAKPiBKdXN0IHNvIEkgZG9uJ3Qgc2VuZCBhbm90aGVyIGZhdWx0eSBwYXRjaCwgeW91
IHdvdWxkIHNlZSB0aGF0IHByaW50aygpCj4gYmVpbmc6Cj4gCj4gICBwcmludGsoWEVOTE9HX0VS
Ugo+ICAgICAgICAgICJ4bWVtX3Bvb2w6IGZvciBibG9jayAlcCBzaXplID0gJXUsIHsgZmwgPSAl
ZCwgc2wgPSAlZCB9IHNob3VsZCBiZSB7IGZsID0gJWQsIHNsID0gJWQgfVxuIiwKPiAgICAgICAg
ICBiLCBiLT5zaXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOwo+IAo+ID8KClRoZSBsb2cgbWVzc2Fn
ZSBoZXJlIGlzIGdvaW5nIHRvIGJlIHN1YnN0YW50aWFsbHkgbW9yZSB0aGFuIDgwCmNoYXJhY3Rl
cnMgKHRoZSBmb3JtYXQgc3RyaW5nIGJ5IGl0c2VsZiBhbHJlYWR5IGlzKS4gQ291bGQgeW91IGZp
bmQgYQptb3JlIGNvbXBhY3QgcmVwcmVzZW50YXRpb24gb2YgdGhlIHVzZWZ1bCBpbmZvPwoKSWFu
LgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:06:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:06:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy0pl-000826-Ty; Mon, 08 Dec 2014 16:06: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 1Xy0pj-00081w-U6
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 16:06:48 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	BE/0B-27785-79CC5845; Mon, 08 Dec 2014 16:06:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418054804!13746633!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 20145 invoked from network); 8 Dec 2014 16:06:46 -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;
	8 Dec 2014 16:06:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201457833"
Message-ID: <1418054695.2827.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mihai =?UTF-8?Q?Don=C8=9Bu?= <mdontu@bitdefender.com>
Date: Mon, 8 Dec 2014 16:04:55 +0000
In-Reply-To: <20141208180001.086cb5e6@bitdefender.com>
References: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
	<548588E9020000780004DAF4@mail.emea.novell.com>
	<20141208180001.086cb5e6@bitdefender.com>
Organization: Citrix Systems, Inc.
Content-Length: 1796
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDE0LTEyLTA4IGF0IDE4OjAwICswMjAwLCBNaWhhaSBEb27Im3Ugd3JvdGU6Cj4g
T24gTW9uZGF5IDA4IERlY2VtYmVyIDIwMTQgMTA6MTg6MDEgSmFuIEJldWxpY2ggd3JvdGU6Cj4g
PiA+Pj4gT24gMDguMTIuMTQgYXQgMDM6MzAsIDxtZG9udHVAYml0ZGVmZW5kZXIuY29tPiB3cm90
ZToKPiA+ID4gKyNpZm5kZWYgTkRFQlVHCj4gPiA+ICtzdGF0aWMgYm9vbF90IHhtZW1fcG9vbF9j
aGVja19zaXplKGNvbnN0IHN0cnVjdCBiaGRyICpiLCBpbnQgZmwsIGludCBzbCkKPiA+ID4gK3sK
PiA+ID4gKyAgICB3aGlsZSAoIGIgKQo+ID4gPiArICAgIHsKPiA+ID4gKyAgICAgICAgaW50IF9f
Zmw7Cj4gPiA+ICsgICAgICAgIGludCBfX3NsOwo+ID4gPiArCj4gPiA+ICsgICAgICAgIE1BUFBJ
TkdfSU5TRVJUKGItPnNpemUsICZfX2ZsLCAmX19zbCk7Cj4gPiA+ICsgICAgICAgIGlmICggX19m
bCAhPSBmbCB8fCBfX3NsICE9IHNsICkKPiA+ID4gKyAgICAgICAgewo+ID4gPiArICAgICAgICAg
ICAgcHJpbnRrKFhFTkxPR19FUlIgInhtZW1fcG9vbDogZm9yIGJsb2NrICVwIHNpemUgPSAldSwg
eyBmbCA9ICVkLCBzbCA9ICVkIH0gc2hvdWxkIGJlIHsgZmwgPSAlZCwgc2wgPSAlZCB9XG4iLAo+
ID4gCj4gPiBRdW90aW5nIG15IHJlcGx5IHRvIHYxOiAiTG9uZyBsaW5lLiBPbmx5IHRoZSBmb3Jt
YXQgbWVzc2FnZSBhbG9uZQo+ID4gaXMgYWxsb3dlZCB0byBleGNlZWQgODAgY2hhcmFjdGVycy4i
Cj4gPiAKPiAKPiBKdXN0IHNvIEkgZG9uJ3Qgc2VuZCBhbm90aGVyIGZhdWx0eSBwYXRjaCwgeW91
IHdvdWxkIHNlZSB0aGF0IHByaW50aygpCj4gYmVpbmc6Cj4gCj4gICBwcmludGsoWEVOTE9HX0VS
Ugo+ICAgICAgICAgICJ4bWVtX3Bvb2w6IGZvciBibG9jayAlcCBzaXplID0gJXUsIHsgZmwgPSAl
ZCwgc2wgPSAlZCB9IHNob3VsZCBiZSB7IGZsID0gJWQsIHNsID0gJWQgfVxuIiwKPiAgICAgICAg
ICBiLCBiLT5zaXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOwo+IAo+ID8KClRoZSBsb2cgbWVzc2Fn
ZSBoZXJlIGlzIGdvaW5nIHRvIGJlIHN1YnN0YW50aWFsbHkgbW9yZSB0aGFuIDgwCmNoYXJhY3Rl
cnMgKHRoZSBmb3JtYXQgc3RyaW5nIGJ5IGl0c2VsZiBhbHJlYWR5IGlzKS4gQ291bGQgeW91IGZp
bmQgYQptb3JlIGNvbXBhY3QgcmVwcmVzZW50YXRpb24gb2YgdGhlIHVzZWZ1bCBpbmZvPwoKSWFu
LgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:07:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16: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 1Xy0qc-00087K-BY; Mon, 08 Dec 2014 16:07: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 1Xy0qb-000879-Ef
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 16:07:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EF/E6-09842-CCCC5845; Mon, 08 Dec 2014 16:07:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418054859!13852741!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6748 invoked from network); 8 Dec 2014 16:07:40 -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; 8 Dec 2014 16:07:40 -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 sB8G7VXQ012458
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 16:07:32 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
	sB8G7UO0008741
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Dec 2014 16:07: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
	sB8G7T3G012280; Mon, 8 Dec 2014 16:07:30 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 08:07:29 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4EBC512020C; Mon,  8 Dec 2014 11:07:30 -0500 (EST)
Date: Mon, 8 Dec 2014 11:07:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141208160730.GH7745@laptop.dumpdata.com>
References: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1418032087.11028.5.camel@citrix.com>
	<20141208155205.GC7745@laptop.dumpdata.com>
	<1418054046.2827.18.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418054046.2827.18.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] flask/policy: Example policy
 updates for migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 03:54:06PM +0000, Ian Campbell wrote:
> On Mon, 2014-12-08 at 10:52 -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Dec 08, 2014 at 09:48:07AM +0000, Ian Campbell wrote:
> > > On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> > > > The example XSM policy was missing permission for dom0_t to migrate
> > > > domains; add these permissions.
> > > > 
> > > > Reported-by: Wei Liu <wei.liu2@citrix.com>
> > > > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > > 
> > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > Konrad, we should take this for 4.5, in order to have a working example
> > > XSM policy. There's 0 risk to non-XSM systems, or systems with custom
> > 
> > Thought this looks like it never worked in the past then? As in, this
> > is not a regression but a bug that had existed for quite a while?
> 
> AIUI it has worked in the past, i.e. I remember applying other series
> from Daniel to fix it for previous releases. This patch is the policy
> catching up with the developments during 4.5.

OK then definilty RElease-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks!
> 
> > 
> > > XSM policies and clear benefits to XSM systems using the example policy.
> > > 
> > > > ---
> > > > 
> > > > This has been tested with xl save/restore on a PV domain, which now
> > > > succeeds without producing AVC denials.
> > > > 
> > > >  tools/flask/policy/policy/modules/xen/xen.if | 11 +++++++----
> > > >  tools/flask/policy/policy/modules/xen/xen.te |  3 +++
> > > >  2 files changed, 10 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> > > > index fa69c9d..bf5e135 100644
> > > > --- a/tools/flask/policy/policy/modules/xen/xen.if
> > > > +++ b/tools/flask/policy/policy/modules/xen/xen.if
> > > > @@ -48,11 +48,13 @@ define(`create_domain_common', `
> > > >  	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
> > > >  			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 };
> > > > +			getaffinity setaffinity setvcpuextstate };
> > > > +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
> > > > +			set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
> > > > +			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 };
> > > > +	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
> > > >  	allow $1 $2:grant setup;
> > > >  	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
> > > >  			setparam pcilevel trackdirtyvram nested };
> > > > @@ -80,7 +82,7 @@ define(`create_domain_build_label', `
> > > >  define(`manage_domain', `
> > > >  	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
> > > >  			getaddrsize pause unpause trigger shutdown destroy
> > > > -			setaffinity setdomainmaxmem getscheduler };
> > > > +			setaffinity setdomainmaxmem getscheduler resume };
> > > >      allow $1 $2:domain2 set_vnumainfo;
> > > >  ')
> > > >  
> > > > @@ -88,6 +90,7 @@ define(`manage_domain', `
> > > >  #   Allow creation of a snapshot or migration image from a domain
> > > >  #   (inbound migration is the same as domain creation)
> > > >  define(`migrate_domain_out', `
> > > > +	allow $1 domxen_t:mmu map_read;
> > > >  	allow $1 $2:hvm { gethvmc getparam irqlevel };
> > > >  	allow $1 $2:mmu { stat pageinfo map_read };
> > > >  	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
> > > > diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
> > > > index d214470..c0128aa 100644
> > > > --- a/tools/flask/policy/policy/modules/xen/xen.te
> > > > +++ b/tools/flask/policy/policy/modules/xen/xen.te
> > > > @@ -129,12 +129,14 @@ create_domain(dom0_t, domU_t)
> > > >  manage_domain(dom0_t, domU_t)
> > > >  domain_comms(dom0_t, domU_t)
> > > >  domain_comms(domU_t, domU_t)
> > > > +migrate_domain_out(dom0_t, domU_t)
> > > >  domain_self_comms(domU_t)
> > > >  
> > > >  declare_domain(isolated_domU_t)
> > > >  create_domain(dom0_t, isolated_domU_t)
> > > >  manage_domain(dom0_t, isolated_domU_t)
> > > >  domain_comms(dom0_t, isolated_domU_t)
> > > > +migrate_domain_out(dom0_t, isolated_domU_t)
> > > >  domain_self_comms(isolated_domU_t)
> > > >  
> > > >  # Declare a boolean that denies creation of prot_domU_t domains
> > > > @@ -142,6 +144,7 @@ gen_bool(prot_doms_locked, false)
> > > >  declare_domain(prot_domU_t)
> > > >  if (!prot_doms_locked) {
> > > >  	create_domain(dom0_t, prot_domU_t)
> > > > +	migrate_domain_out(dom0_t, prot_domU_t)
> > > >  }
> > > >  domain_comms(dom0_t, prot_domU_t)
> > > >  domain_comms(domU_t, prot_domU_t)
> > > 
> > > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:07:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16: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 1Xy0qc-00087K-BY; Mon, 08 Dec 2014 16:07: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 1Xy0qb-000879-Ef
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 16:07:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EF/E6-09842-CCCC5845; Mon, 08 Dec 2014 16:07:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418054859!13852741!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6748 invoked from network); 8 Dec 2014 16:07:40 -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; 8 Dec 2014 16:07:40 -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 sB8G7VXQ012458
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 16:07:32 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
	sB8G7UO0008741
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Dec 2014 16:07: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
	sB8G7T3G012280; Mon, 8 Dec 2014 16:07:30 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 08:07:29 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4EBC512020C; Mon,  8 Dec 2014 11:07:30 -0500 (EST)
Date: Mon, 8 Dec 2014 11:07:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141208160730.GH7745@laptop.dumpdata.com>
References: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1418032087.11028.5.camel@citrix.com>
	<20141208155205.GC7745@laptop.dumpdata.com>
	<1418054046.2827.18.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418054046.2827.18.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] flask/policy: Example policy
 updates for migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 03:54:06PM +0000, Ian Campbell wrote:
> On Mon, 2014-12-08 at 10:52 -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Dec 08, 2014 at 09:48:07AM +0000, Ian Campbell wrote:
> > > On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> > > > The example XSM policy was missing permission for dom0_t to migrate
> > > > domains; add these permissions.
> > > > 
> > > > Reported-by: Wei Liu <wei.liu2@citrix.com>
> > > > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > > 
> > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > Konrad, we should take this for 4.5, in order to have a working example
> > > XSM policy. There's 0 risk to non-XSM systems, or systems with custom
> > 
> > Thought this looks like it never worked in the past then? As in, this
> > is not a regression but a bug that had existed for quite a while?
> 
> AIUI it has worked in the past, i.e. I remember applying other series
> from Daniel to fix it for previous releases. This patch is the policy
> catching up with the developments during 4.5.

OK then definilty RElease-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks!
> 
> > 
> > > XSM policies and clear benefits to XSM systems using the example policy.
> > > 
> > > > ---
> > > > 
> > > > This has been tested with xl save/restore on a PV domain, which now
> > > > succeeds without producing AVC denials.
> > > > 
> > > >  tools/flask/policy/policy/modules/xen/xen.if | 11 +++++++----
> > > >  tools/flask/policy/policy/modules/xen/xen.te |  3 +++
> > > >  2 files changed, 10 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
> > > > index fa69c9d..bf5e135 100644
> > > > --- a/tools/flask/policy/policy/modules/xen/xen.if
> > > > +++ b/tools/flask/policy/policy/modules/xen/xen.if
> > > > @@ -48,11 +48,13 @@ define(`create_domain_common', `
> > > >  	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
> > > >  			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 };
> > > > +			getaffinity setaffinity setvcpuextstate };
> > > > +	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
> > > > +			set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
> > > > +			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 };
> > > > +	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
> > > >  	allow $1 $2:grant setup;
> > > >  	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
> > > >  			setparam pcilevel trackdirtyvram nested };
> > > > @@ -80,7 +82,7 @@ define(`create_domain_build_label', `
> > > >  define(`manage_domain', `
> > > >  	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
> > > >  			getaddrsize pause unpause trigger shutdown destroy
> > > > -			setaffinity setdomainmaxmem getscheduler };
> > > > +			setaffinity setdomainmaxmem getscheduler resume };
> > > >      allow $1 $2:domain2 set_vnumainfo;
> > > >  ')
> > > >  
> > > > @@ -88,6 +90,7 @@ define(`manage_domain', `
> > > >  #   Allow creation of a snapshot or migration image from a domain
> > > >  #   (inbound migration is the same as domain creation)
> > > >  define(`migrate_domain_out', `
> > > > +	allow $1 domxen_t:mmu map_read;
> > > >  	allow $1 $2:hvm { gethvmc getparam irqlevel };
> > > >  	allow $1 $2:mmu { stat pageinfo map_read };
> > > >  	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
> > > > diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
> > > > index d214470..c0128aa 100644
> > > > --- a/tools/flask/policy/policy/modules/xen/xen.te
> > > > +++ b/tools/flask/policy/policy/modules/xen/xen.te
> > > > @@ -129,12 +129,14 @@ create_domain(dom0_t, domU_t)
> > > >  manage_domain(dom0_t, domU_t)
> > > >  domain_comms(dom0_t, domU_t)
> > > >  domain_comms(domU_t, domU_t)
> > > > +migrate_domain_out(dom0_t, domU_t)
> > > >  domain_self_comms(domU_t)
> > > >  
> > > >  declare_domain(isolated_domU_t)
> > > >  create_domain(dom0_t, isolated_domU_t)
> > > >  manage_domain(dom0_t, isolated_domU_t)
> > > >  domain_comms(dom0_t, isolated_domU_t)
> > > > +migrate_domain_out(dom0_t, isolated_domU_t)
> > > >  domain_self_comms(isolated_domU_t)
> > > >  
> > > >  # Declare a boolean that denies creation of prot_domU_t domains
> > > > @@ -142,6 +144,7 @@ gen_bool(prot_doms_locked, false)
> > > >  declare_domain(prot_domU_t)
> > > >  if (!prot_doms_locked) {
> > > >  	create_domain(dom0_t, prot_domU_t)
> > > > +	migrate_domain_out(dom0_t, prot_domU_t)
> > > >  }
> > > >  domain_comms(dom0_t, prot_domU_t)
> > > >  domain_comms(domU_t, prot_domU_t)
> > > 
> > > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:18:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:18:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy11C-00008x-I7; Mon, 08 Dec 2014 16:18:38 +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 1Xy11A-00008s-PR
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 16:18:36 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EE/90-25276-C5FC5845; Mon, 08 Dec 2014 16:18:36 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418055513!14196359!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6892 invoked from network); 8 Dec 2014 16:18:35 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2014 16:18:35 -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
	sB8GIMAA008889
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 8 Dec 2014 11:18:22 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sB8GILuW008887;
	Mon, 8 Dec 2014 11:18:21 -0500
Date: Mon, 8 Dec 2014 12:18:21 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141208161821.GA8810@andromeda.dapyr.net>
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>
	<1417179939.23604.43.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417179939.23604.43.camel@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.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

On Fri, Nov 28, 2014 at 01:05:39PM +0000, Ian Campbell wrote:
> 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>

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 Mon Dec 08 16:18:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:18:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy11C-00008x-I7; Mon, 08 Dec 2014 16:18:38 +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 1Xy11A-00008s-PR
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 16:18:36 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EE/90-25276-C5FC5845; Mon, 08 Dec 2014 16:18:36 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418055513!14196359!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6892 invoked from network); 8 Dec 2014 16:18:35 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2014 16:18:35 -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
	sB8GIMAA008889
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 8 Dec 2014 11:18:22 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sB8GILuW008887;
	Mon, 8 Dec 2014 11:18:21 -0500
Date: Mon, 8 Dec 2014 12:18:21 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141208161821.GA8810@andromeda.dapyr.net>
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>
	<1417179939.23604.43.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417179939.23604.43.camel@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.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

On Fri, Nov 28, 2014 at 01:05:39PM +0000, Ian Campbell wrote:
> 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>

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 Mon Dec 08 16:20:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy13K-0000Ez-2S; Mon, 08 Dec 2014 16:20: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 1Xy13I-0000Ep-Fv
	for Xen-devel@lists.xen.org; Mon, 08 Dec 2014 16:20:48 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	7E/D2-27785-FDFC5845; Mon, 08 Dec 2014 16:20:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418055647!13750210!1
X-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 24381 invoked from network); 8 Dec 2014 16:20:47 -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; 8 Dec 2014 16:20:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 16:20:46 +0000
Message-Id: <5485DDEA020000780004DDD4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 16:20:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yu Zhang" <yu.c.zhang@linux.intel.com>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417838137-12473-3-git-send-email-yu.c.zhang@linux.intel.com>
In-Reply-To: <1417838137-12473-3-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 v6 2/2] add a new p2m type -
	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 06.12.14 at 04:55, <yu.c.zhang@linux.intel.com> wrote:
> From: Yu Zhang <yu.c.zhang@intel.com>
> 
> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
> the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
> model, and will be discarded later in __hvm_copy(); while for the
> p2m_mmio_write_dm type pages, writes will go to the device model
> via ioreq-server.
> 
> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
> Signed-off-by: Wei Ye <wei.ye@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 Mon Dec 08 16:20:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy13K-0000Ez-2S; Mon, 08 Dec 2014 16:20: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 1Xy13I-0000Ep-Fv
	for Xen-devel@lists.xen.org; Mon, 08 Dec 2014 16:20:48 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	7E/D2-27785-FDFC5845; Mon, 08 Dec 2014 16:20:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418055647!13750210!1
X-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 24381 invoked from network); 8 Dec 2014 16:20:47 -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; 8 Dec 2014 16:20:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 16:20:46 +0000
Message-Id: <5485DDEA020000780004DDD4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 16:20:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yu Zhang" <yu.c.zhang@linux.intel.com>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417838137-12473-3-git-send-email-yu.c.zhang@linux.intel.com>
In-Reply-To: <1417838137-12473-3-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 v6 2/2] add a new p2m type -
	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 06.12.14 at 04:55, <yu.c.zhang@linux.intel.com> wrote:
> From: Yu Zhang <yu.c.zhang@intel.com>
> 
> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
> the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
> model, and will be discarded later in __hvm_copy(); while for the
> p2m_mmio_write_dm type pages, writes will go to the device model
> via ioreq-server.
> 
> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
> Signed-off-by: Wei Ye <wei.ye@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 Mon Dec 08 16:23:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:23:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy15t-0000ea-PJ; Mon, 08 Dec 2014 16:23: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 1Xy15t-0000eT-Ap
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 16:23:29 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	81/B1-14727-080D5845; Mon, 08 Dec 2014 16:23:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418055808!6772550!1
X-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 30087 invoked from network); 8 Dec 2014 16:23:28 -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; 8 Dec 2014 16:23:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 16:23:27 +0000
Message-Id: <5485DE8B020000780004DDEA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 16:23:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Mihai=20Don=C8=9Bu?=" <mdontu@bitdefender.com>
References: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
	<548588E9020000780004DAF4@mail.emea.novell.com>
	<20141208180001.086cb5e6@bitdefender.com>
In-Reply-To: <20141208180001.086cb5e6@bitdefender.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 17:00, <mdontu@bitdefender.com> wrote:
> On Monday 08 December 2014 10:18:01 Jan Beulich wrote:
>> >>> On 08.12.14 at 03:30, <mdontu@bitdefender.com> wrote:
>> > +#ifndef NDEBUG
>> > +static bool_t xmem_pool_check_size(const struct bhdr *b, int fl, int sl)
>> > +{
>> > +    while ( b )
>> > +    {
>> > +        int __fl;
>> > +        int __sl;
>> > +
>> > +        MAPPING_INSERT(b->size, &__fl, &__sl);
>> > +        if ( __fl != fl || __sl != sl )
>> > +        {
>> > +            printk(XENLOG_ERR "xmem_pool: for block %p size = %u, { fl = 
> %d, sl = %d } should be { fl = %d, sl = %d }\n",
>> 
>> Quoting my reply to v1: "Long line. Only the format message alone
>> is allowed to exceed 80 characters."
>> 
> 
> Just so I don't send another faulty patch, you would see that printk()
> being:
> 
>   printk(XENLOG_ERR
>          "xmem_pool: for block %p size = %u, { fl = %d, sl = %d } should be { fl = %d, sl = %d }\n",
>          b, b->size, fl, sl, __fl, __sl);
> 
> ?

Yes. And I'd also recommend removing the spaces around the =
characters in the format string. Considering the message being a
debugging one, perhaps the two pairs could be printed without
any extras, i.e. just {x,y}.

>> Also with there potentially being multiple pools, shouldn't all of the
>> log messages the patch issues be extended to allow identifying the
>> offending one?
>> 
> 
> I think I can insert the pool name in that message too. Something like:
> 
>   printk(XENLOG_ERR
>          "xmem_pool: %s: for block [...]\n",
>          pool->name, b, b->size [...]);
> 
> would do? A quick preview:

Yes. I very think that's what the name's for after all.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:23:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:23:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy15t-0000ea-PJ; Mon, 08 Dec 2014 16:23: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 1Xy15t-0000eT-Ap
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 16:23:29 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	81/B1-14727-080D5845; Mon, 08 Dec 2014 16:23:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418055808!6772550!1
X-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 30087 invoked from network); 8 Dec 2014 16:23:28 -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; 8 Dec 2014 16:23:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 16:23:27 +0000
Message-Id: <5485DE8B020000780004DDEA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 16:23:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Mihai=20Don=C8=9Bu?=" <mdontu@bitdefender.com>
References: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
	<548588E9020000780004DAF4@mail.emea.novell.com>
	<20141208180001.086cb5e6@bitdefender.com>
In-Reply-To: <20141208180001.086cb5e6@bitdefender.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 17:00, <mdontu@bitdefender.com> wrote:
> On Monday 08 December 2014 10:18:01 Jan Beulich wrote:
>> >>> On 08.12.14 at 03:30, <mdontu@bitdefender.com> wrote:
>> > +#ifndef NDEBUG
>> > +static bool_t xmem_pool_check_size(const struct bhdr *b, int fl, int sl)
>> > +{
>> > +    while ( b )
>> > +    {
>> > +        int __fl;
>> > +        int __sl;
>> > +
>> > +        MAPPING_INSERT(b->size, &__fl, &__sl);
>> > +        if ( __fl != fl || __sl != sl )
>> > +        {
>> > +            printk(XENLOG_ERR "xmem_pool: for block %p size = %u, { fl = 
> %d, sl = %d } should be { fl = %d, sl = %d }\n",
>> 
>> Quoting my reply to v1: "Long line. Only the format message alone
>> is allowed to exceed 80 characters."
>> 
> 
> Just so I don't send another faulty patch, you would see that printk()
> being:
> 
>   printk(XENLOG_ERR
>          "xmem_pool: for block %p size = %u, { fl = %d, sl = %d } should be { fl = %d, sl = %d }\n",
>          b, b->size, fl, sl, __fl, __sl);
> 
> ?

Yes. And I'd also recommend removing the spaces around the =
characters in the format string. Considering the message being a
debugging one, perhaps the two pairs could be printed without
any extras, i.e. just {x,y}.

>> Also with there potentially being multiple pools, shouldn't all of the
>> log messages the patch issues be extended to allow identifying the
>> offending one?
>> 
> 
> I think I can insert the pool name in that message too. Something like:
> 
>   printk(XENLOG_ERR
>          "xmem_pool: %s: for block [...]\n",
>          pool->name, b, b->size [...]);
> 
> would do? A quick preview:

Yes. I very think that's what the name's for after all.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:29:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy1B4-0000oP-HS; Mon, 08 Dec 2014 16:28:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1Xy1B2-0000oK-Sp
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 16:28:49 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	D1/7F-18267-0C1D5845; Mon, 08 Dec 2014 16:28:48 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418056126!11897266!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 18543 invoked from network); 8 Dec 2014 16:28:47 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 16:28:47 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=GV+0ywV84Did++Yrzwya3KitqEvj5zwHaKzR4eblXVGJ7lJ6xztD32hIYlyZ6ioYdlEivol1R+gf3WBu1xvSLWWNl69ePWDziUJUaPhqpVpqmeyNdvwftck2valnotv9tlXJ1NStCiYfkYmViOeCoaV0Q57WBYtrEKoza+G+42q1CFqVpH3HJtLdvdM+plmikXixIoXDZIdtshovfZV+6yBanGbMMNOF1ljhZ617257jkhE2AFmYtKMd9bJZ25JFM68zsjrzdMrJf8uabVFggSWIoyGCjluuuzv4x7nBPHdAq4Kfx1s7v8ysMvrlbrllAD7hkVZnWTtra1t1S7r4Jg==;
	h=Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:cc:subject:message-id:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	bh=TctbZFFgxuf2PtrTDhNVVuAwuh4=; b=iJ0O2QKpHMjOoITkBmBQ5FYHonml
	pm+obMguH0S0J3qudbY9P+oOW+jwJSZ2UslryhWwWQSsxubJX4ruEyMx5+su2Qz7
	DqN2qrjLy1o0W+lwqJy0gPVNV3IFuDCQBVkXeAGIBzzmpWndxcFa2o3D6xgFjQlD
	0vvsB9dwmo6C6UaTFG8TmLGE5ELkUYpRw0a3XK/vfKrok061de1nz83yGa+AjlRB
	cMJBaIisPi5beGcFOGNK4ZwbeszvKFYxsLKGFsc2g3xs6Ak86s34yA+eRYX73HEg
	UDPvg/VNCl8hP+5/N6w1ITJCYqfCFAUEVS9MiQqhgzdF2WcMjZrs0XjN5Q==
Received: (qmail 31730 invoked from network); 8 Dec 2014 18:28:45 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	8 Dec 2014 18:28:45 +0200
Received: from smtp01.buh.bitdefender.com (unknown [10.17.80.75])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id A1BCD80361
	for <xen-devel@lists.xenproject.org>;
	Mon,  8 Dec 2014 18:28:45 +0200 (EET)
Received: (qmail 19399 invoked from network); 8 Dec 2014 18:28:45 +0200
Received: from unknown (HELO bitdefender.com) (mdontu@bitdefender.com@unknown)
	by unknown with SMTP; 8 Dec 2014 18:28:45 +0200
Date: Mon, 8 Dec 2014 18:28:45 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141208182845.4e7313f7@bitdefender.com>
In-Reply-To: <1418054695.2827.20.camel@citrix.com>
References: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
	<548588E9020000780004DAF4@mail.emea.novell.com>
	<20141208180001.086cb5e6@bitdefender.com>
	<1418054695.2827.20.camel@citrix.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp01.buh.bitdefender.com, sigver: 7.58177
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374383,
	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], SGN: [Enabled], URL: [Enabled], RTDA:
	[Enabled, Hit: No, Details: v2.1.2; Id: 2m1ghdn.198la3edo.5mqf],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: xen-devel@lists.xenproject.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uZGF5IDA4IERlY2VtYmVyIDIwMTQgMTY6MDQ6NTUgSWFuIENhbXBiZWxsIHdyb3RlOgo+
IE9uIE1vbiwgMjAxNC0xMi0wOCBhdCAxODowMCArMDIwMCwgTWloYWkgRG9uyJt1IHdyb3RlOgo+
ID4gT24gTW9uZGF5IDA4IERlY2VtYmVyIDIwMTQgMTA6MTg6MDEgSmFuIEJldWxpY2ggd3JvdGU6
Cj4gPiA+ID4+PiBPbiAwOC4xMi4xNCBhdCAwMzozMCwgPG1kb250dUBiaXRkZWZlbmRlci5jb20+
IHdyb3RlOgo+ID4gPiA+ICsjaWZuZGVmIE5ERUJVRwo+ID4gPiA+ICtzdGF0aWMgYm9vbF90IHht
ZW1fcG9vbF9jaGVja19zaXplKGNvbnN0IHN0cnVjdCBiaGRyICpiLCBpbnQgZmwsIGludCBzbCkK
PiA+ID4gPiArewo+ID4gPiA+ICsgICAgd2hpbGUgKCBiICkKPiA+ID4gPiArICAgIHsKPiA+ID4g
PiArICAgICAgICBpbnQgX19mbDsKPiA+ID4gPiArICAgICAgICBpbnQgX19zbDsKPiA+ID4gPiAr
Cj4gPiA+ID4gKyAgICAgICAgTUFQUElOR19JTlNFUlQoYi0+c2l6ZSwgJl9fZmwsICZfX3NsKTsK
PiA+ID4gPiArICAgICAgICBpZiAoIF9fZmwgIT0gZmwgfHwgX19zbCAhPSBzbCApCj4gPiA+ID4g
KyAgICAgICAgewo+ID4gPiA+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9w
b29sOiBmb3IgYmxvY2sgJXAgc2l6ZSA9ICV1LCB7IGZsID0gJWQsIHNsID0gJWQgfSBzaG91bGQg
YmUgeyBmbCA9ICVkLCBzbCA9ICVkIH1cbiIsCj4gPiA+IAo+ID4gPiBRdW90aW5nIG15IHJlcGx5
IHRvIHYxOiAiTG9uZyBsaW5lLiBPbmx5IHRoZSBmb3JtYXQgbWVzc2FnZSBhbG9uZQo+ID4gPiBp
cyBhbGxvd2VkIHRvIGV4Y2VlZCA4MCBjaGFyYWN0ZXJzLiIKPiA+ID4gCj4gPiAKPiA+IEp1c3Qg
c28gSSBkb24ndCBzZW5kIGFub3RoZXIgZmF1bHR5IHBhdGNoLCB5b3Ugd291bGQgc2VlIHRoYXQg
cHJpbnRrKCkKPiA+IGJlaW5nOgo+ID4gCj4gPiAgIHByaW50ayhYRU5MT0dfRVJSCj4gPiAgICAg
ICAgICAieG1lbV9wb29sOiBmb3IgYmxvY2sgJXAgc2l6ZSA9ICV1LCB7IGZsID0gJWQsIHNsID0g
JWQgfSBzaG91bGQgYmUgeyBmbCA9ICVkLCBzbCA9ICVkIH1cbiIsCj4gPiAgICAgICAgICBiLCBi
LT5zaXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOwo+ID4gCj4gPiA/Cj4gCj4gVGhlIGxvZyBtZXNz
YWdlIGhlcmUgaXMgZ29pbmcgdG8gYmUgc3Vic3RhbnRpYWxseSBtb3JlIHRoYW4gODAKPiBjaGFy
YWN0ZXJzICh0aGUgZm9ybWF0IHN0cmluZyBieSBpdHNlbGYgYWxyZWFkeSBpcykuIENvdWxkIHlv
dSBmaW5kIGEKPiBtb3JlIGNvbXBhY3QgcmVwcmVzZW50YXRpb24gb2YgdGhlIHVzZWZ1bCBpbmZv
Pwo+IAoKQWghIEkgc2VlLiBJIGFwb2xvZ2l6ZSBmb3IgYmVpbmcgc28gc2xvdy4gOi0pIEhvdyBh
Ym91dDoKCnByaW50ayhYRU5MT0dfRVJSICJ4bWVtX3Bvb2w6ICVzOiBtaXNwbGFjZWQgYmxvY2sg
JXA6JXUgKHslZCwlZH0gLT4geyVkLCVkfSlcbiIsCiAgICAgICBwb29sLT5uYW1lLCBiLCBiLT5z
aXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOyAKCkxvb2tzIGEgYml0IGNyeXB0aWMsIGJ1dCB0aGUg
VExTRiBpdHNlbGYgaXMgcHJldHR5IGNvbXBsZXggYW5kIGZvcgpicmF2ZSBzb3VscyB3aXNoaW5n
IHRvIGRlYnVnIGl0LCB0aGUgbWVzc2FnZSBmb3JtYXQgd2lsbCBiZSB0aGUgbGFzdAp0aGluZyBv
biB0aGVpciBtaW5kcy4gOi0pCgpQcmV2aWV3OgoKWzIwMTQtMTItMDQgMTU6NDE6MjNdIChYRU4p
IFsgMTM3NC41MDcxMjVdIHhtZW1fcG9vbDogeG1hbGxvYzogbWlzcGxhY2VkIGJsb2NrIGZmZmY4
MzA0MDA0ZmI5YjA6MCAoezMsOX0gLT4gezAsMH0pClsyMDE0LTEyLTA0IDE1OjQxOjIzXSAoWEVO
KSBbIDEzNzQuNTA3MTI3XSB4bWVtX3Bvb2w6IHhtYWxsb2M6IHRoZSBUTFNGIGNodW5rIG1hdHJp
eCBpcyBjb3JydXB0ZWQKClRoYW5rcywKCi0tIApNaWhhaSBET07ImlUKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:29:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy1B4-0000oP-HS; Mon, 08 Dec 2014 16:28:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1Xy1B2-0000oK-Sp
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 16:28:49 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	D1/7F-18267-0C1D5845; Mon, 08 Dec 2014 16:28:48 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418056126!11897266!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 18543 invoked from network); 8 Dec 2014 16:28:47 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 16:28:47 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=GV+0ywV84Did++Yrzwya3KitqEvj5zwHaKzR4eblXVGJ7lJ6xztD32hIYlyZ6ioYdlEivol1R+gf3WBu1xvSLWWNl69ePWDziUJUaPhqpVpqmeyNdvwftck2valnotv9tlXJ1NStCiYfkYmViOeCoaV0Q57WBYtrEKoza+G+42q1CFqVpH3HJtLdvdM+plmikXixIoXDZIdtshovfZV+6yBanGbMMNOF1ljhZ617257jkhE2AFmYtKMd9bJZ25JFM68zsjrzdMrJf8uabVFggSWIoyGCjluuuzv4x7nBPHdAq4Kfx1s7v8ysMvrlbrllAD7hkVZnWTtra1t1S7r4Jg==;
	h=Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:cc:subject:message-id:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	bh=TctbZFFgxuf2PtrTDhNVVuAwuh4=; b=iJ0O2QKpHMjOoITkBmBQ5FYHonml
	pm+obMguH0S0J3qudbY9P+oOW+jwJSZ2UslryhWwWQSsxubJX4ruEyMx5+su2Qz7
	DqN2qrjLy1o0W+lwqJy0gPVNV3IFuDCQBVkXeAGIBzzmpWndxcFa2o3D6xgFjQlD
	0vvsB9dwmo6C6UaTFG8TmLGE5ELkUYpRw0a3XK/vfKrok061de1nz83yGa+AjlRB
	cMJBaIisPi5beGcFOGNK4ZwbeszvKFYxsLKGFsc2g3xs6Ak86s34yA+eRYX73HEg
	UDPvg/VNCl8hP+5/N6w1ITJCYqfCFAUEVS9MiQqhgzdF2WcMjZrs0XjN5Q==
Received: (qmail 31730 invoked from network); 8 Dec 2014 18:28:45 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	8 Dec 2014 18:28:45 +0200
Received: from smtp01.buh.bitdefender.com (unknown [10.17.80.75])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id A1BCD80361
	for <xen-devel@lists.xenproject.org>;
	Mon,  8 Dec 2014 18:28:45 +0200 (EET)
Received: (qmail 19399 invoked from network); 8 Dec 2014 18:28:45 +0200
Received: from unknown (HELO bitdefender.com) (mdontu@bitdefender.com@unknown)
	by unknown with SMTP; 8 Dec 2014 18:28:45 +0200
Date: Mon, 8 Dec 2014 18:28:45 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141208182845.4e7313f7@bitdefender.com>
In-Reply-To: <1418054695.2827.20.camel@citrix.com>
References: <1418005848-17447-1-git-send-email-mdontu@bitdefender.com>
	<548588E9020000780004DAF4@mail.emea.novell.com>
	<20141208180001.086cb5e6@bitdefender.com>
	<1418054695.2827.20.camel@citrix.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp01.buh.bitdefender.com, sigver: 7.58177
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374383,
	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], SGN: [Enabled], URL: [Enabled], RTDA:
	[Enabled, Hit: No, Details: v2.1.2; Id: 2m1ghdn.198la3edo.5mqf],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: xen-devel@lists.xenproject.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uZGF5IDA4IERlY2VtYmVyIDIwMTQgMTY6MDQ6NTUgSWFuIENhbXBiZWxsIHdyb3RlOgo+
IE9uIE1vbiwgMjAxNC0xMi0wOCBhdCAxODowMCArMDIwMCwgTWloYWkgRG9uyJt1IHdyb3RlOgo+
ID4gT24gTW9uZGF5IDA4IERlY2VtYmVyIDIwMTQgMTA6MTg6MDEgSmFuIEJldWxpY2ggd3JvdGU6
Cj4gPiA+ID4+PiBPbiAwOC4xMi4xNCBhdCAwMzozMCwgPG1kb250dUBiaXRkZWZlbmRlci5jb20+
IHdyb3RlOgo+ID4gPiA+ICsjaWZuZGVmIE5ERUJVRwo+ID4gPiA+ICtzdGF0aWMgYm9vbF90IHht
ZW1fcG9vbF9jaGVja19zaXplKGNvbnN0IHN0cnVjdCBiaGRyICpiLCBpbnQgZmwsIGludCBzbCkK
PiA+ID4gPiArewo+ID4gPiA+ICsgICAgd2hpbGUgKCBiICkKPiA+ID4gPiArICAgIHsKPiA+ID4g
PiArICAgICAgICBpbnQgX19mbDsKPiA+ID4gPiArICAgICAgICBpbnQgX19zbDsKPiA+ID4gPiAr
Cj4gPiA+ID4gKyAgICAgICAgTUFQUElOR19JTlNFUlQoYi0+c2l6ZSwgJl9fZmwsICZfX3NsKTsK
PiA+ID4gPiArICAgICAgICBpZiAoIF9fZmwgIT0gZmwgfHwgX19zbCAhPSBzbCApCj4gPiA+ID4g
KyAgICAgICAgewo+ID4gPiA+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9w
b29sOiBmb3IgYmxvY2sgJXAgc2l6ZSA9ICV1LCB7IGZsID0gJWQsIHNsID0gJWQgfSBzaG91bGQg
YmUgeyBmbCA9ICVkLCBzbCA9ICVkIH1cbiIsCj4gPiA+IAo+ID4gPiBRdW90aW5nIG15IHJlcGx5
IHRvIHYxOiAiTG9uZyBsaW5lLiBPbmx5IHRoZSBmb3JtYXQgbWVzc2FnZSBhbG9uZQo+ID4gPiBp
cyBhbGxvd2VkIHRvIGV4Y2VlZCA4MCBjaGFyYWN0ZXJzLiIKPiA+ID4gCj4gPiAKPiA+IEp1c3Qg
c28gSSBkb24ndCBzZW5kIGFub3RoZXIgZmF1bHR5IHBhdGNoLCB5b3Ugd291bGQgc2VlIHRoYXQg
cHJpbnRrKCkKPiA+IGJlaW5nOgo+ID4gCj4gPiAgIHByaW50ayhYRU5MT0dfRVJSCj4gPiAgICAg
ICAgICAieG1lbV9wb29sOiBmb3IgYmxvY2sgJXAgc2l6ZSA9ICV1LCB7IGZsID0gJWQsIHNsID0g
JWQgfSBzaG91bGQgYmUgeyBmbCA9ICVkLCBzbCA9ICVkIH1cbiIsCj4gPiAgICAgICAgICBiLCBi
LT5zaXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOwo+ID4gCj4gPiA/Cj4gCj4gVGhlIGxvZyBtZXNz
YWdlIGhlcmUgaXMgZ29pbmcgdG8gYmUgc3Vic3RhbnRpYWxseSBtb3JlIHRoYW4gODAKPiBjaGFy
YWN0ZXJzICh0aGUgZm9ybWF0IHN0cmluZyBieSBpdHNlbGYgYWxyZWFkeSBpcykuIENvdWxkIHlv
dSBmaW5kIGEKPiBtb3JlIGNvbXBhY3QgcmVwcmVzZW50YXRpb24gb2YgdGhlIHVzZWZ1bCBpbmZv
Pwo+IAoKQWghIEkgc2VlLiBJIGFwb2xvZ2l6ZSBmb3IgYmVpbmcgc28gc2xvdy4gOi0pIEhvdyBh
Ym91dDoKCnByaW50ayhYRU5MT0dfRVJSICJ4bWVtX3Bvb2w6ICVzOiBtaXNwbGFjZWQgYmxvY2sg
JXA6JXUgKHslZCwlZH0gLT4geyVkLCVkfSlcbiIsCiAgICAgICBwb29sLT5uYW1lLCBiLCBiLT5z
aXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOyAKCkxvb2tzIGEgYml0IGNyeXB0aWMsIGJ1dCB0aGUg
VExTRiBpdHNlbGYgaXMgcHJldHR5IGNvbXBsZXggYW5kIGZvcgpicmF2ZSBzb3VscyB3aXNoaW5n
IHRvIGRlYnVnIGl0LCB0aGUgbWVzc2FnZSBmb3JtYXQgd2lsbCBiZSB0aGUgbGFzdAp0aGluZyBv
biB0aGVpciBtaW5kcy4gOi0pCgpQcmV2aWV3OgoKWzIwMTQtMTItMDQgMTU6NDE6MjNdIChYRU4p
IFsgMTM3NC41MDcxMjVdIHhtZW1fcG9vbDogeG1hbGxvYzogbWlzcGxhY2VkIGJsb2NrIGZmZmY4
MzA0MDA0ZmI5YjA6MCAoezMsOX0gLT4gezAsMH0pClsyMDE0LTEyLTA0IDE1OjQxOjIzXSAoWEVO
KSBbIDEzNzQuNTA3MTI3XSB4bWVtX3Bvb2w6IHhtYWxsb2M6IHRoZSBUTFNGIGNodW5rIG1hdHJp
eCBpcyBjb3JydXB0ZWQKClRoYW5rcywKCi0tIApNaWhhaSBET07ImlUKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:46:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16: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 1Xy1S9-0001Qs-7Y; Mon, 08 Dec 2014 16:46:29 +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 1Xy1S7-0001Qn-9i
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 16:46:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	05/D6-25276-2E5D5845; Mon, 08 Dec 2014 16:46:26 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418057185!13861511!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20226 invoked from network); 8 Dec 2014 16:46:25 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-3.tower-21.messagelabs.com with SMTP;
	8 Dec 2014 16:46:25 -0000
X-TM-IMSS-Message-ID: <75e32e990008789f@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 75e32e990008789f ;
	Mon, 8 Dec 2014 11:46:44 -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 sB8GjjtA008779; 
	Mon, 8 Dec 2014 11:45:56 -0500
Message-ID: <5485D5B9.60303@tycho.nsa.gov>
Date: Mon, 08 Dec 2014 11:45:45 -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: Jan Beulich <JBeulich@suse.com>, Tiejun Chen <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
	<20141202194709.GD357@laptop.dumpdata.com>
	<5485427C.1070903@intel.com>
	<548584C9020000780004DAB2@mail.emea.novell.com>
In-Reply-To: <548584C9020000780004DAB2@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 03/17] introduce
	XENMEM_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/08/2014 05:00 AM, Jan Beulich wrote:
>>>> On 08.12.14 at 07:17, <tiejun.chen@intel.com> wrote:
>> On 2014/12/3 3:47, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Dec 01, 2014 at 05:24:21PM +0800, Tiejun Chen wrote:
>>>> @@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>>            break;
>>>>        }
>>>>
>>>> +#ifdef HAS_PASSTHROUGH
>>>> +    case XENMEM_reserved_device_memory_map:
>>>> +    {
>>>> +        struct get_reserved_device_memory grdm;
>>>> +
>>>> +        if ( copy_from_guest(&grdm.map, arg, 1) ||
>>>> +             !guest_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
>>>> +            return -EFAULT;
>>>> +
>>>
>>> Shouldn't there be an XSM check here?
>>
>> I'm not sure, and Jan should be the author for this patch, so Jan can
>> give you a correct reply.
>
> Hmm, not sure: Daniel, does an operation like this need an XSM
> check? It's not clear whether the absence of such a check in e.g.
> the handling of XENMEM_memory_map, XENMEM_machphys_mapping,
> or XENMEM_maximum_ram_page is intentional (and can be used as
> justification for it to be absent here too - after all the operation is for
> a domain to find out information about only itself).
>
> Jan

I can see a possible reason why an XSM check might be needed here, but
I'm not sufficiently clear on what reserved device memory is to tell
for sure.  My best guess is that it is not needed.

 From my reading of this patchset, this hypercall just identifies regions
of memory that are reserved, similar to exposing the host's e820 map to a
guest.  That seems similar enough to the other XENMEM_* leaks that it is
acceptable to also allow it.  If there is a reason that it would be useful
to hide this, adding hooks to all these locations so that only domains
that use passthrough devices (and therefore need to know about the host
system's memory) will have access is probably the best option.

If a guest who has control of a passthrough device can cause these
reserved ranges to change, then there may be reason to prevent others
from querying them, but that doesn't appear to be the case here.

-- 
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 Dec 08 16:46:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16: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 1Xy1S9-0001Qs-7Y; Mon, 08 Dec 2014 16:46:29 +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 1Xy1S7-0001Qn-9i
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 16:46:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	05/D6-25276-2E5D5845; Mon, 08 Dec 2014 16:46:26 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418057185!13861511!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20226 invoked from network); 8 Dec 2014 16:46:25 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-3.tower-21.messagelabs.com with SMTP;
	8 Dec 2014 16:46:25 -0000
X-TM-IMSS-Message-ID: <75e32e990008789f@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 75e32e990008789f ;
	Mon, 8 Dec 2014 11:46:44 -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 sB8GjjtA008779; 
	Mon, 8 Dec 2014 11:45:56 -0500
Message-ID: <5485D5B9.60303@tycho.nsa.gov>
Date: Mon, 08 Dec 2014 11:45:45 -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: Jan Beulich <JBeulich@suse.com>, Tiejun Chen <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
	<20141202194709.GD357@laptop.dumpdata.com>
	<5485427C.1070903@intel.com>
	<548584C9020000780004DAB2@mail.emea.novell.com>
In-Reply-To: <548584C9020000780004DAB2@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 03/17] introduce
	XENMEM_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/08/2014 05:00 AM, Jan Beulich wrote:
>>>> On 08.12.14 at 07:17, <tiejun.chen@intel.com> wrote:
>> On 2014/12/3 3:47, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Dec 01, 2014 at 05:24:21PM +0800, Tiejun Chen wrote:
>>>> @@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>>            break;
>>>>        }
>>>>
>>>> +#ifdef HAS_PASSTHROUGH
>>>> +    case XENMEM_reserved_device_memory_map:
>>>> +    {
>>>> +        struct get_reserved_device_memory grdm;
>>>> +
>>>> +        if ( copy_from_guest(&grdm.map, arg, 1) ||
>>>> +             !guest_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
>>>> +            return -EFAULT;
>>>> +
>>>
>>> Shouldn't there be an XSM check here?
>>
>> I'm not sure, and Jan should be the author for this patch, so Jan can
>> give you a correct reply.
>
> Hmm, not sure: Daniel, does an operation like this need an XSM
> check? It's not clear whether the absence of such a check in e.g.
> the handling of XENMEM_memory_map, XENMEM_machphys_mapping,
> or XENMEM_maximum_ram_page is intentional (and can be used as
> justification for it to be absent here too - after all the operation is for
> a domain to find out information about only itself).
>
> Jan

I can see a possible reason why an XSM check might be needed here, but
I'm not sufficiently clear on what reserved device memory is to tell
for sure.  My best guess is that it is not needed.

 From my reading of this patchset, this hypercall just identifies regions
of memory that are reserved, similar to exposing the host's e820 map to a
guest.  That seems similar enough to the other XENMEM_* leaks that it is
acceptable to also allow it.  If there is a reason that it would be useful
to hide this, adding hooks to all these locations so that only domains
that use passthrough devices (and therefore need to know about the host
system's memory) will have access is probably the best option.

If a guest who has control of a passthrough device can cause these
reserved ranges to change, then there may be reason to prevent others
from querying them, but that doesn't appear to be the case here.

-- 
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 Dec 08 16:54:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:54:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy1ZP-0001nt-43; Mon, 08 Dec 2014 16:53:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Xy1ZO-0001no-Av
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 16:53:58 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	06/C8-22819-5A7D5845; Mon, 08 Dec 2014 16:53:57 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418057632!6890087!1
X-Originating-IP: [66.165.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 17551 invoked from network); 8 Dec 2014 16:53:56 -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;
	8 Dec 2014 16:53:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201482303"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 11:51:26 -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 1Xy1Ms-00050E-Gd;
	Mon, 08 Dec 2014 16:41:02 +0000
Date: Mon, 8 Dec 2014 16:41:02 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: =?iso-8859-1?B?SuFu?= Tomko <jtomko@redhat.com>
Message-ID: <20141208164102.GC1900@perard.uk.xensource.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<5485C654.7030503@redhat.com>
MIME-Version: 1.0
Content-Length: 1270
Content-Disposition: inline
In-Reply-To: <5485C654.7030503@redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH] libxl: Set path to console on
	domain startup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 08, 2014 at 04:40:04PM +0100, J=E1n Tomko wrote:
> On 12/05/2014 05:30 PM, Anthony PERARD wrote:
> > Hi,
> > =

> > I'm trying to fix an issue when using OpenStack with libvirt+xen (libxe=
nlight).
> > OpenStack cannot access the console output of a Xen PV guest, because t=
he XML
> > generated by libvirt for a domain is missing the path to the pty. The p=
ath
> > actually appear in the XML once one call virDomainOpenConsole().
> > =

> > The patch intend to get the path to the pty without having to call
> > virDomainOpenConsole, so I've done the work in libxlDomainStart(). So I=
 have a
> > few question:
> > Is libxlDomainStart will be called on restore/migrate/reboot?
> > I guest the function libxlDomainOpenConsole() would not need to do the =
same
> > work if the console path is settup properly.
> > =

> > There is a bug report about this:
> > https://bugzilla.redhat.com/show_bug.cgi?id=3D1170743
> > =

> =

> Hi,
> =

> you can leave the bugzilla link in the commit message, if somebody ever n=
eeds
> more context.

Ok.

> (And the patch looks good to me, but I'm no libxl expert)

Thanks,

-- =

Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:54:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16:54:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy1ZP-0001nt-43; Mon, 08 Dec 2014 16:53:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Xy1ZO-0001no-Av
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 16:53:58 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	06/C8-22819-5A7D5845; Mon, 08 Dec 2014 16:53:57 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418057632!6890087!1
X-Originating-IP: [66.165.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 17551 invoked from network); 8 Dec 2014 16:53:56 -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;
	8 Dec 2014 16:53:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201482303"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 11:51:26 -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 1Xy1Ms-00050E-Gd;
	Mon, 08 Dec 2014 16:41:02 +0000
Date: Mon, 8 Dec 2014 16:41:02 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: =?iso-8859-1?B?SuFu?= Tomko <jtomko@redhat.com>
Message-ID: <20141208164102.GC1900@perard.uk.xensource.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<5485C654.7030503@redhat.com>
MIME-Version: 1.0
Content-Length: 1270
Content-Disposition: inline
In-Reply-To: <5485C654.7030503@redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH] libxl: Set path to console on
	domain startup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 08, 2014 at 04:40:04PM +0100, J=E1n Tomko wrote:
> On 12/05/2014 05:30 PM, Anthony PERARD wrote:
> > Hi,
> > =

> > I'm trying to fix an issue when using OpenStack with libvirt+xen (libxe=
nlight).
> > OpenStack cannot access the console output of a Xen PV guest, because t=
he XML
> > generated by libvirt for a domain is missing the path to the pty. The p=
ath
> > actually appear in the XML once one call virDomainOpenConsole().
> > =

> > The patch intend to get the path to the pty without having to call
> > virDomainOpenConsole, so I've done the work in libxlDomainStart(). So I=
 have a
> > few question:
> > Is libxlDomainStart will be called on restore/migrate/reboot?
> > I guest the function libxlDomainOpenConsole() would not need to do the =
same
> > work if the console path is settup properly.
> > =

> > There is a bug report about this:
> > https://bugzilla.redhat.com/show_bug.cgi?id=3D1170743
> > =

> =

> Hi,
> =

> you can leave the bugzilla link in the commit message, if somebody ever n=
eeds
> more context.

Ok.

> (And the patch looks good to me, but I'm no libxl expert)

Thanks,

-- =

Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:54:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16: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 1Xy1a6-0001r0-HS; Mon, 08 Dec 2014 16:54:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xy1a5-0001qr-LY
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 16:54:41 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	AD/9C-02712-0D7D5845; Mon, 08 Dec 2014 16:54:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418057680!13710458!1
X-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 10194 invoked from network); 8 Dec 2014 16:54:40 -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; 8 Dec 2014 16:54:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 16:54:39 +0000
Message-Id: <5485E5DB020000780004DE0B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 16:54:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>,
	"Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
	<20141202194709.GD357@laptop.dumpdata.com> <5485427C.1070903@intel.com>
	<548584C9020000780004DAB2@mail.emea.novell.com>
	<5485D5B9.60303@tycho.nsa.gov>
In-Reply-To: <5485D5B9.60303@tycho.nsa.gov>
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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 03/17] introduce
 XENMEM_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 17:45, <dgdegra@tycho.nsa.gov> wrote:
> If a guest who has control of a passthrough device can cause these
> reserved ranges to change, then there may be reason to prevent others
> from querying them, but that doesn't appear to be the case here.

Right, in that case we definitely would need a check.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 16:54:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 16: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 1Xy1a6-0001r0-HS; Mon, 08 Dec 2014 16:54:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xy1a5-0001qr-LY
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 16:54:41 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	AD/9C-02712-0D7D5845; Mon, 08 Dec 2014 16:54:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418057680!13710458!1
X-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 10194 invoked from network); 8 Dec 2014 16:54:40 -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; 8 Dec 2014 16:54:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 16:54:39 +0000
Message-Id: <5485E5DB020000780004DE0B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 16:54:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>,
	"Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-4-git-send-email-tiejun.chen@intel.com>
	<20141202194709.GD357@laptop.dumpdata.com> <5485427C.1070903@intel.com>
	<548584C9020000780004DAB2@mail.emea.novell.com>
	<5485D5B9.60303@tycho.nsa.gov>
In-Reply-To: <5485D5B9.60303@tycho.nsa.gov>
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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 03/17] introduce
 XENMEM_reserved_device_memory_map
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 17:45, <dgdegra@tycho.nsa.gov> wrote:
> If a guest who has control of a passthrough device can cause these
> reserved ranges to change, then there may be reason to prevent others
> from querying them, but that doesn't appear to be the case here.

Right, in that case we definitely would need a check.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 17:02:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 17: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 1Xy1gm-00026i-Eg; Mon, 08 Dec 2014 17:01: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 1Xy1gk-00026d-QU
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 17:01:34 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	FA/CF-25714-E69D5845; Mon, 08 Dec 2014 17:01:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418058093!4599819!1
X-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 1072 invoked from network); 8 Dec 2014 17:01:33 -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; 8 Dec 2014 17:01:33 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 17:01:33 +0000
Message-Id: <5485E779020000780004DE1F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 17:01:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-2-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417448023-27311-2-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 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 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/numa.c
> +++ b/xen/arch/x86/numa.c
> @@ -363,10 +363,13 @@ EXPORT_SYMBOL(node_data);
>  static void dump_numa(unsigned char key)
>  {
>      s_time_t now = NOW();
> -    int i;
> +    unsigned int i, j, n;
> +    int err;
>      struct domain *d;
>      struct page_info *page;
>      unsigned int page_num_node[MAX_NUMNODES];
> +    uint64_t mem;
> +    struct vnuma_info *vnuma;

If this can be const, it should be in a pure dumping function.

> @@ -408,6 +411,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, "%3u",
> +                    vnuma->vnode_to_pnode[i]);
> +            if ( err < 0 || vnuma->vnode_to_pnode[i] == NUMA_NO_NODE )
> +                strlcpy(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("%16"PRIu64" MB: %#016"PRIx64" - %#016"PRIx64"\n",

Am I misremembering that these were just "0x%"PRIx64 originally?
I ask because converting to the 0-padded fixed width form makes
no sense together with the # modifier. For these ranges I think it's
quite obvious that the numbers are hex, so I'd suggest dropping
the #s without replacement. And to be honest I'm also against
printing duplicate information: The memory range already specifies
how much memory this is.

> +                           mem >> 20,
> +                           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("%3d\n", j);
> +                    else if ( !(n % 8) && n != 0 )
> +                        printk("%17d ", j);
> +                    else
> +                        printk("%3d ", j);
> +                    n++;
> +                }

Please consider very-many-vCPU guests here - see Andrew's commit
9cf71226 ("process softirqs while dumping domains").

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 17:02:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 17: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 1Xy1gm-00026i-Eg; Mon, 08 Dec 2014 17:01: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 1Xy1gk-00026d-QU
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 17:01:34 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	FA/CF-25714-E69D5845; Mon, 08 Dec 2014 17:01:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418058093!4599819!1
X-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 1072 invoked from network); 8 Dec 2014 17:01:33 -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; 8 Dec 2014 17:01:33 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 17:01:33 +0000
Message-Id: <5485E779020000780004DE1F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 17:01:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-2-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417448023-27311-2-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 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 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/numa.c
> +++ b/xen/arch/x86/numa.c
> @@ -363,10 +363,13 @@ EXPORT_SYMBOL(node_data);
>  static void dump_numa(unsigned char key)
>  {
>      s_time_t now = NOW();
> -    int i;
> +    unsigned int i, j, n;
> +    int err;
>      struct domain *d;
>      struct page_info *page;
>      unsigned int page_num_node[MAX_NUMNODES];
> +    uint64_t mem;
> +    struct vnuma_info *vnuma;

If this can be const, it should be in a pure dumping function.

> @@ -408,6 +411,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, "%3u",
> +                    vnuma->vnode_to_pnode[i]);
> +            if ( err < 0 || vnuma->vnode_to_pnode[i] == NUMA_NO_NODE )
> +                strlcpy(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("%16"PRIu64" MB: %#016"PRIx64" - %#016"PRIx64"\n",

Am I misremembering that these were just "0x%"PRIx64 originally?
I ask because converting to the 0-padded fixed width form makes
no sense together with the # modifier. For these ranges I think it's
quite obvious that the numbers are hex, so I'd suggest dropping
the #s without replacement. And to be honest I'm also against
printing duplicate information: The memory range already specifies
how much memory this is.

> +                           mem >> 20,
> +                           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("%3d\n", j);
> +                    else if ( !(n % 8) && n != 0 )
> +                        printk("%17d ", j);
> +                    else
> +                        printk("%3d ", j);
> +                    n++;
> +                }

Please consider very-many-vCPU guests here - see Andrew's commit
9cf71226 ("process softirqs while dumping domains").

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 17:05:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 17: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 1Xy1kW-0002SC-3h; Mon, 08 Dec 2014 17:05:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xy1kU-0002S7-Qx
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 17:05:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F6/AF-15461-65AD5845; Mon, 08 Dec 2014 17:05:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418058325!14194370!1
X-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 15045 invoked from network); 8 Dec 2014 17:05: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; 8 Dec 2014 17:05:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 17:05:25 +0000
Message-Id: <5485E863020000780004DE27@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 17:05:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-3-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417448023-27311-3-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 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 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -302,6 +302,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          {
>          case 0:
>              fi.submap = 0;
> +            fi.submap |= (1U << XENFEAT_memory_op_vnode_supported);

Why don't you just replace the assignment above?

> --- 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,

Coding style.

With these fixed,
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 Mon Dec 08 17:05:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 17: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 1Xy1kW-0002SC-3h; Mon, 08 Dec 2014 17:05:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xy1kU-0002S7-Qx
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 17:05:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F6/AF-15461-65AD5845; Mon, 08 Dec 2014 17:05:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418058325!14194370!1
X-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 15045 invoked from network); 8 Dec 2014 17:05: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; 8 Dec 2014 17:05:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 17:05:25 +0000
Message-Id: <5485E863020000780004DE27@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 17:05:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-3-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417448023-27311-3-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 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 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -302,6 +302,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          {
>          case 0:
>              fi.submap = 0;
> +            fi.submap |= (1U << XENFEAT_memory_op_vnode_supported);

Why don't you just replace the assignment above?

> --- 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,

Coding style.

With these fixed,
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 Mon Dec 08 17:20:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 17: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 1Xy1yV-0002sa-N5; Mon, 08 Dec 2014 17:19:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>)
	id 1Xy1yU-0002sS-G1; Mon, 08 Dec 2014 17:19:54 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	12/98-14727-9BDD5845; Mon, 08 Dec 2014 17:19:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418059192!12233698!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5999 invoked from network); 8 Dec 2014 17:19:53 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 17:19:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418059192; l=1477;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=vBYYMZZw9Ll/EIfkTJbFyUXSvEs=;
	b=nE3c0Ar0h6tVlPNkwuC08qAL8PF3GH3lwfTDFVdh/SQvd8U9MvUz4pMSiHB8gr6WuBz
	X5E33iM+6KJcwebeTuuTPxifx00PBPNrBlTnOQpnDSUqzfme5juEgoky4IZu0AnTBa/Ok
	fOGdWg5TsdJuV21vR5eQDueNiU5JmnLnGSU=
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.3 AUTH) with ESMTPSA id I01b23qB8HJo2gy
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 18:19:50 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id CF6BB5015F; Mon,  8 Dec 2014 18:19:49 +0100 (CET)
Date: Mon, 8 Dec 2014 18:19:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141208171949.GA1819@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<20141205171102.GA24737@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205171102.GA24737@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, 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>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Olaf Hering wrote:

> But even with that change xendomains is hanging if it cant talk to
> xenstored for whatever  reason. The result is that the sytem hangs
> forever at shutdown. 

This looks like a bug in the tools. xl or xenstore-ls hang forever if xenstored
disappears. Looks like xs_open() is the culprit. The socket functions fail,
then it attempts to use xs_domain_dev() which happens to succeed.  Only
xenstore-ls has the '-s' option to force operating on a socket.  I wonder why
libxl does not pass XS_OPEN_SOCKETONLY? It just uses the wrappers for xs_open.

Can xenstored run in another domain?

Olaf

18:02:43.522767 stat("/var/run/xenstored/socket", {st_mode=S_IFSOCK|0600, st_size=0, ...}) = 0
18:02:43.522864 socket(PF_LOCAL, SOCK_STREAM, 0) = 3
18:02:43.522964 fcntl(3, F_GETFD)       = 0
18:02:43.523035 fcntl(3, F_SETFD, FD_CLOEXEC) = 0
18:02:43.523117 connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/xenstored/socket"}, 110) = -1 ECONNREFUSED (Connection refused)
18:02:43.523224 close(3)                = 0
18:02:43.523305 stat("/proc/xen/xenbus", {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
18:02:43.523393 open("/proc/xen/xenbus", O_RDWR) = 3
18:02:43.523562 brk(0)                  = 0x250c000
18:02:43.523638 brk(0x252d000)          = 0x252d000
18:02:43.523748 rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, 0x7fc9518e3200}, {SIG_DFL, [], 0}, 8) = 0
18:02:43.523834 write(3, "\1\0\0\0\0\0\0\0\0\0\0\0\2\0\0\0", 16) = 16
18:02:43.523938 write(3, "/\0", 2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 17:20:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 17: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 1Xy1yV-0002sa-N5; Mon, 08 Dec 2014 17:19:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>)
	id 1Xy1yU-0002sS-G1; Mon, 08 Dec 2014 17:19:54 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	12/98-14727-9BDD5845; Mon, 08 Dec 2014 17:19:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418059192!12233698!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5999 invoked from network); 8 Dec 2014 17:19:53 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 17:19:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418059192; l=1477;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=vBYYMZZw9Ll/EIfkTJbFyUXSvEs=;
	b=nE3c0Ar0h6tVlPNkwuC08qAL8PF3GH3lwfTDFVdh/SQvd8U9MvUz4pMSiHB8gr6WuBz
	X5E33iM+6KJcwebeTuuTPxifx00PBPNrBlTnOQpnDSUqzfme5juEgoky4IZu0AnTBa/Ok
	fOGdWg5TsdJuV21vR5eQDueNiU5JmnLnGSU=
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.3 AUTH) with ESMTPSA id I01b23qB8HJo2gy
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 18:19:50 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id CF6BB5015F; Mon,  8 Dec 2014 18:19:49 +0100 (CET)
Date: Mon, 8 Dec 2014 18:19:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141208171949.GA1819@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<20141205171102.GA24737@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141205171102.GA24737@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, 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>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 05, Olaf Hering wrote:

> But even with that change xendomains is hanging if it cant talk to
> xenstored for whatever  reason. The result is that the sytem hangs
> forever at shutdown. 

This looks like a bug in the tools. xl or xenstore-ls hang forever if xenstored
disappears. Looks like xs_open() is the culprit. The socket functions fail,
then it attempts to use xs_domain_dev() which happens to succeed.  Only
xenstore-ls has the '-s' option to force operating on a socket.  I wonder why
libxl does not pass XS_OPEN_SOCKETONLY? It just uses the wrappers for xs_open.

Can xenstored run in another domain?

Olaf

18:02:43.522767 stat("/var/run/xenstored/socket", {st_mode=S_IFSOCK|0600, st_size=0, ...}) = 0
18:02:43.522864 socket(PF_LOCAL, SOCK_STREAM, 0) = 3
18:02:43.522964 fcntl(3, F_GETFD)       = 0
18:02:43.523035 fcntl(3, F_SETFD, FD_CLOEXEC) = 0
18:02:43.523117 connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/xenstored/socket"}, 110) = -1 ECONNREFUSED (Connection refused)
18:02:43.523224 close(3)                = 0
18:02:43.523305 stat("/proc/xen/xenbus", {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
18:02:43.523393 open("/proc/xen/xenbus", O_RDWR) = 3
18:02:43.523562 brk(0)                  = 0x250c000
18:02:43.523638 brk(0x252d000)          = 0x252d000
18:02:43.523748 rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, 0x7fc9518e3200}, {SIG_DFL, [], 0}, 8) = 0
18:02:43.523834 write(3, "\1\0\0\0\0\0\0\0\0\0\0\0\2\0\0\0", 16) = 16
18:02:43.523938 write(3, "/\0", 2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 17:23:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 17:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy21h-0003Iw-TY; Mon, 08 Dec 2014 17:23:13 +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 1Xy21g-0003Ik-U2; Mon, 08 Dec 2014 17:23:13 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	F6/B7-02957-08ED5845; Mon, 08 Dec 2014 17:23:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418059389!13747852!1
X-Originating-IP: [66.165.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 3865 invoked from network); 8 Dec 2014 17:23: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;
	8 Dec 2014 17:23:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201892409"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 12:23: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 1Xy21b-0005qN-Pr;
	Mon, 08 Dec 2014 17:23:07 +0000
Date: Mon, 8 Dec 2014 17:23:07 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141208172307.GA25749@zion.uk.xensource.com>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<20141205171102.GA24737@aepfle.de>
	<20141208171949.GA1819@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141208171949.GA1819@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.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>,
	xen-devel <xen-devel@lists.xen.org>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 06:19:49PM +0100, Olaf Hering wrote:
> On Fri, Dec 05, Olaf Hering wrote:
> 
> > But even with that change xendomains is hanging if it cant talk to
> > xenstored for whatever  reason. The result is that the sytem hangs
> > forever at shutdown. 
> 
> This looks like a bug in the tools. xl or xenstore-ls hang forever if xenstored
> disappears. Looks like xs_open() is the culprit. The socket functions fail,
> then it attempts to use xs_domain_dev() which happens to succeed.  Only
> xenstore-ls has the '-s' option to force operating on a socket.  I wonder why
> libxl does not pass XS_OPEN_SOCKETONLY? It just uses the wrappers for xs_open.
> 
> Can xenstored run in another domain?
> 

I think we have xenstored stubdom in tree, don't we?

> Olaf
> 
> 18:02:43.522767 stat("/var/run/xenstored/socket", {st_mode=S_IFSOCK|0600, st_size=0, ...}) = 0
> 18:02:43.522864 socket(PF_LOCAL, SOCK_STREAM, 0) = 3
> 18:02:43.522964 fcntl(3, F_GETFD)       = 0
> 18:02:43.523035 fcntl(3, F_SETFD, FD_CLOEXEC) = 0
> 18:02:43.523117 connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/xenstored/socket"}, 110) = -1 ECONNREFUSED (Connection refused)
> 18:02:43.523224 close(3)                = 0
> 18:02:43.523305 stat("/proc/xen/xenbus", {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
> 18:02:43.523393 open("/proc/xen/xenbus", O_RDWR) = 3
> 18:02:43.523562 brk(0)                  = 0x250c000
> 18:02:43.523638 brk(0x252d000)          = 0x252d000
> 18:02:43.523748 rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, 0x7fc9518e3200}, {SIG_DFL, [], 0}, 8) = 0
> 18:02:43.523834 write(3, "\1\0\0\0\0\0\0\0\0\0\0\0\2\0\0\0", 16) = 16
> 18:02:43.523938 write(3, "/\0", 2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 17:23:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 17:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy21h-0003Iw-TY; Mon, 08 Dec 2014 17:23:13 +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 1Xy21g-0003Ik-U2; Mon, 08 Dec 2014 17:23:13 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	F6/B7-02957-08ED5845; Mon, 08 Dec 2014 17:23:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418059389!13747852!1
X-Originating-IP: [66.165.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 3865 invoked from network); 8 Dec 2014 17:23: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;
	8 Dec 2014 17:23:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201892409"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 12:23: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 1Xy21b-0005qN-Pr;
	Mon, 08 Dec 2014 17:23:07 +0000
Date: Mon, 8 Dec 2014 17:23:07 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141208172307.GA25749@zion.uk.xensource.com>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<20141205171102.GA24737@aepfle.de>
	<20141208171949.GA1819@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141208171949.GA1819@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.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>,
	xen-devel <xen-devel@lists.xen.org>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 06:19:49PM +0100, Olaf Hering wrote:
> On Fri, Dec 05, Olaf Hering wrote:
> 
> > But even with that change xendomains is hanging if it cant talk to
> > xenstored for whatever  reason. The result is that the sytem hangs
> > forever at shutdown. 
> 
> This looks like a bug in the tools. xl or xenstore-ls hang forever if xenstored
> disappears. Looks like xs_open() is the culprit. The socket functions fail,
> then it attempts to use xs_domain_dev() which happens to succeed.  Only
> xenstore-ls has the '-s' option to force operating on a socket.  I wonder why
> libxl does not pass XS_OPEN_SOCKETONLY? It just uses the wrappers for xs_open.
> 
> Can xenstored run in another domain?
> 

I think we have xenstored stubdom in tree, don't we?

> Olaf
> 
> 18:02:43.522767 stat("/var/run/xenstored/socket", {st_mode=S_IFSOCK|0600, st_size=0, ...}) = 0
> 18:02:43.522864 socket(PF_LOCAL, SOCK_STREAM, 0) = 3
> 18:02:43.522964 fcntl(3, F_GETFD)       = 0
> 18:02:43.523035 fcntl(3, F_SETFD, FD_CLOEXEC) = 0
> 18:02:43.523117 connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/xenstored/socket"}, 110) = -1 ECONNREFUSED (Connection refused)
> 18:02:43.523224 close(3)                = 0
> 18:02:43.523305 stat("/proc/xen/xenbus", {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
> 18:02:43.523393 open("/proc/xen/xenbus", O_RDWR) = 3
> 18:02:43.523562 brk(0)                  = 0x250c000
> 18:02:43.523638 brk(0x252d000)          = 0x252d000
> 18:02:43.523748 rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, 0x7fc9518e3200}, {SIG_DFL, [], 0}, 8) = 0
> 18:02:43.523834 write(3, "\1\0\0\0\0\0\0\0\0\0\0\0\2\0\0\0", 16) = 16
> 18:02:43.523938 write(3, "/\0", 2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 17:37:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 17:37:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy2FJ-0004AJ-0u; Mon, 08 Dec 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 <olaf@aepfle.de>)
	id 1Xy2FG-0004AB-MR; Mon, 08 Dec 2014 17:37:15 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	51/D1-03148-9C1E5845; Mon, 08 Dec 2014 17:37:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418060233!13750366!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21642 invoked from network); 8 Dec 2014 17:37:13 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 17:37:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418060233; l=306;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=8P6g5tBShu1lpVtM1qP+EHPEIJM=;
	b=ckmSpPDoO7of3TJHkTQkYHQtVBbJX1xY0TrS7mT2HSXELyy1cCoK1OBML7ZEv1B7mDY
	Gj5TwLImFZMnIEK8nxtXGWR/teKOm7JprdEy/xUQrkO+OFBU24pRwHfFIlITLSHvY0k37
	mehltpb3U1U3B6rJCFPPKMI3yL/njcbLnPs=
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.3 AUTH) with ESMTPSA id Y00e89qB8Hb93G3
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 18:37:09 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0F95C5015F; Mon,  8 Dec 2014 18:37:08 +0100 (CET)
Date: Mon, 8 Dec 2014 18:37:08 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141208173708.GA6679@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<20141205171102.GA24737@aepfle.de>
	<20141208171949.GA1819@aepfle.de>
	<20141208172307.GA25749@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141208172307.GA25749@zion.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, Wei Liu wrote:

> I think we have xenstored stubdom in tree, don't we?

If we do, isnt that a "special" setup which does not appear all by
its own? If so, shouldnt there be some config file knob to let xs_open
use socket only unless told otherwise by the to-be-created knob?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 17:37:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 17:37:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy2FJ-0004AJ-0u; Mon, 08 Dec 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 <olaf@aepfle.de>)
	id 1Xy2FG-0004AB-MR; Mon, 08 Dec 2014 17:37:15 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	51/D1-03148-9C1E5845; Mon, 08 Dec 2014 17:37:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418060233!13750366!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21642 invoked from network); 8 Dec 2014 17:37:13 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 17:37:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418060233; l=306;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=8P6g5tBShu1lpVtM1qP+EHPEIJM=;
	b=ckmSpPDoO7of3TJHkTQkYHQtVBbJX1xY0TrS7mT2HSXELyy1cCoK1OBML7ZEv1B7mDY
	Gj5TwLImFZMnIEK8nxtXGWR/teKOm7JprdEy/xUQrkO+OFBU24pRwHfFIlITLSHvY0k37
	mehltpb3U1U3B6rJCFPPKMI3yL/njcbLnPs=
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.3 AUTH) with ESMTPSA id Y00e89qB8Hb93G3
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 8 Dec 2014 18:37:09 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0F95C5015F; Mon,  8 Dec 2014 18:37:08 +0100 (CET)
Date: Mon, 8 Dec 2014 18:37:08 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141208173708.GA6679@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<20141205171102.GA24737@aepfle.de>
	<20141208171949.GA1819@aepfle.de>
	<20141208172307.GA25749@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141208172307.GA25749@zion.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, Wei Liu wrote:

> I think we have xenstored stubdom in tree, don't we?

If we do, isnt that a "special" setup which does not appear all by
its own? If so, shouldnt there be some config file knob to let xs_open
use socket only unless told otherwise by the to-be-created knob?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 17:49:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 17: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 1Xy2Qd-0004pe-Q8; Mon, 08 Dec 2014 17:48: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 1Xy2Qb-0004pS-UM; Mon, 08 Dec 2014 17:48:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	87/8C-25276-984E5845; Mon, 08 Dec 2014 17:48:57 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418060935!14214791!1
X-Originating-IP: [66.165.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 29307 invoked from network); 8 Dec 2014 17:48: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;
	8 Dec 2014 17:48:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201902635"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 12:48: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 1Xy2QY-0006Hs-Ew;
	Mon, 08 Dec 2014 17:48:54 +0000
Date: Mon, 8 Dec 2014 17:48:54 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141208174854.GB25749@zion.uk.xensource.com>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<20141205171102.GA24737@aepfle.de>
	<20141208171949.GA1819@aepfle.de>
	<20141208172307.GA25749@zion.uk.xensource.com>
	<20141208173708.GA6679@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141208173708.GA6679@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.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>,
	xen-devel <xen-devel@lists.xen.org>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 06:37:08PM +0100, Olaf Hering wrote:
> On Mon, Dec 08, Wei Liu wrote:
> 
> > I think we have xenstored stubdom in tree, don't we?
> 
> If we do, isnt that a "special" setup which does not appear all by
> its own? If so, shouldnt there be some config file knob to let xs_open
> use socket only unless told otherwise by the to-be-created knob?
> 

At the very least it needs to run init-xenstore-domain to set it up. I
have no idea how this supposes to work though. Maybe other people have
better idea.

However I think the problem you're seeing is due to xenstored exits too
early, which should be fixable by rearranging the shutdown order? I.e.
xenstored shuts down after xendomains.

Wei.

> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 17:49:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 17: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 1Xy2Qd-0004pe-Q8; Mon, 08 Dec 2014 17:48: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 1Xy2Qb-0004pS-UM; Mon, 08 Dec 2014 17:48:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	87/8C-25276-984E5845; Mon, 08 Dec 2014 17:48:57 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418060935!14214791!1
X-Originating-IP: [66.165.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 29307 invoked from network); 8 Dec 2014 17:48: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;
	8 Dec 2014 17:48:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="scan'208";a="201902635"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 8 Dec 2014 12:48: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 1Xy2QY-0006Hs-Ew;
	Mon, 08 Dec 2014 17:48:54 +0000
Date: Mon, 8 Dec 2014 17:48:54 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141208174854.GB25749@zion.uk.xensource.com>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<20141205171102.GA24737@aepfle.de>
	<20141208171949.GA1819@aepfle.de>
	<20141208172307.GA25749@zion.uk.xensource.com>
	<20141208173708.GA6679@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141208173708.GA6679@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.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>,
	xen-devel <xen-devel@lists.xen.org>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 06:37:08PM +0100, Olaf Hering wrote:
> On Mon, Dec 08, Wei Liu wrote:
> 
> > I think we have xenstored stubdom in tree, don't we?
> 
> If we do, isnt that a "special" setup which does not appear all by
> its own? If so, shouldnt there be some config file knob to let xs_open
> use socket only unless told otherwise by the to-be-created knob?
> 

At the very least it needs to run init-xenstore-domain to set it up. I
have no idea how this supposes to work though. Maybe other people have
better idea.

However I think the problem you're seeing is due to xenstored exits too
early, which should be fixable by rearranging the shutdown order? I.e.
xenstored shuts down after xendomains.

Wei.

> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 18:57:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 18: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 1Xy3Um-0007Er-P1; Mon, 08 Dec 2014 18:57:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xy3Um-0007Em-1L
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 18:57:20 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C3/88-29352-F84F5845; Mon, 08 Dec 2014 18:57:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418065033!12245856!1
X-Originating-IP: [66.165.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 20693 invoked from network); 8 Dec 2014 18:57:18 -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;
	8 Dec 2014 18:57:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,540,1413244800"; d="scan'208";a="201936507"
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.210.2; Mon, 8 Dec 2014 13:57: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 1Xy3US-0003ry-FT;
	Mon, 08 Dec 2014 18:57:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xy3US-0005X7-42;
	Mon, 08 Dec 2014 18:57:00 +0000
Date: Mon, 8 Dec 2014 18:57:00 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32146-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] 32146: 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 32146 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32146/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          fbf232c42ae2dea512a2c34b154e1d63f3dad3c4
baseline version:
 rumpuserxen          66b09d00078908e61d0f0c1b87fc140ed8c91e06

------------------------------------------------------------
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=fbf232c42ae2dea512a2c34b154e1d63f3dad3c4
+ . 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 fbf232c42ae2dea512a2c34b154e1d63f3dad3c4
+ branch=rumpuserxen
+ revision=fbf232c42ae2dea512a2c34b154e1d63f3dad3c4
+ . 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 fbf232c42ae2dea512a2c34b154e1d63f3dad3c4:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   66b09d0..fbf232c  fbf232c42ae2dea512a2c34b154e1d63f3dad3c4 -> 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 Dec 08 18:57:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 18: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 1Xy3Um-0007Er-P1; Mon, 08 Dec 2014 18:57:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xy3Um-0007Em-1L
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 18:57:20 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C3/88-29352-F84F5845; Mon, 08 Dec 2014 18:57:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418065033!12245856!1
X-Originating-IP: [66.165.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 20693 invoked from network); 8 Dec 2014 18:57:18 -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;
	8 Dec 2014 18:57:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,540,1413244800"; d="scan'208";a="201936507"
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.210.2; Mon, 8 Dec 2014 13:57: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 1Xy3US-0003ry-FT;
	Mon, 08 Dec 2014 18:57:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xy3US-0005X7-42;
	Mon, 08 Dec 2014 18:57:00 +0000
Date: Mon, 8 Dec 2014 18:57:00 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32146-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] 32146: 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 32146 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32146/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          fbf232c42ae2dea512a2c34b154e1d63f3dad3c4
baseline version:
 rumpuserxen          66b09d00078908e61d0f0c1b87fc140ed8c91e06

------------------------------------------------------------
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=fbf232c42ae2dea512a2c34b154e1d63f3dad3c4
+ . 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 fbf232c42ae2dea512a2c34b154e1d63f3dad3c4
+ branch=rumpuserxen
+ revision=fbf232c42ae2dea512a2c34b154e1d63f3dad3c4
+ . 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 fbf232c42ae2dea512a2c34b154e1d63f3dad3c4:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   66b09d0..fbf232c  fbf232c42ae2dea512a2c34b154e1d63f3dad3c4 -> 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 Dec 08 19:03:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 19:03:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy3ax-0007dw-JR; Mon, 08 Dec 2014 19:03:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xy3aw-0007dr-LH
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 19:03:42 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	1C/FA-14214-D06F5845; Mon, 08 Dec 2014 19:03:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418065419!12190326!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 10451 invoked from network); 8 Dec 2014 19:03:41 -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;
	8 Dec 2014 19:03:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,540,1413244800"; d="scan'208";a="201939553"
Message-ID: <5485F5F7.6040206@citrix.com>
Date: Mon, 8 Dec 2014 19:03: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: Xen-devel List <xen-devel@lists.xen.org>
X-DLP: MIA1
Subject: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Over the weekend, XenServer testing managed to run a side-by-side test
of XenServer trunk and XenServer experimental xen-4.5.  These are
identical other than the version of Xen (and associated libraries) in
use, i.e. identical dom0 kernel, Xapi toolstack and dom0 userspace,
other than as linked against newer Xen libraries.

The Xen-4.5 tests were on top of c/s e6c3d371d4 "systemd: use pkg-config
to determine systemd library availability"

There are a few notable issues exposed:

XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it didn't in
xen-4.4, given identical parameters.  The hypercall gained an extra
permission check as part of 0561e1f01e.  Our usecase here is a daemon in
dom0 mapping guest RAM to emulate a graphics card, but I currently don't
see how that is incompatible with the new permissions check.

Migrations from older Xens to Xen-4.5 fairly reliably crash domains (90%
of the time, both PV and HVM guests).  This includes migrates from older
XenServers using the legacy->v2 migration code which is confirmed-good
in "upgrade to Xen-4.4" case.  The migration v2 code in use is identical.

We have certain machines which are showing reliable failure to boot
under Xen-4.5, where they worked with 4.4.  Symptoms range from the dom0
kernel crashing before printing anything, to complaining that the initrd
is corrupt when attempting to decompress.  This appears to be hardware
specific.


I will be looking into all of these issues, to identify whether they are
indeed regressions in xen-4.5, or whether I have make some mistakes
forward porting our patch queue.

Unfortunately, our PCI Passthrough testing has been blocked behind other
regressions which have crept in recently, meaning that both sets of
tests were equally affected, and no 4.4 vs 4.5 comparison has been
possible at this time.  I hope this will be fixed by the next time I run
a similar pair of tests.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 19:03:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 19:03:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy3ax-0007dw-JR; Mon, 08 Dec 2014 19:03:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xy3aw-0007dr-LH
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 19:03:42 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	1C/FA-14214-D06F5845; Mon, 08 Dec 2014 19:03:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418065419!12190326!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 10451 invoked from network); 8 Dec 2014 19:03:41 -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;
	8 Dec 2014 19:03:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,540,1413244800"; d="scan'208";a="201939553"
Message-ID: <5485F5F7.6040206@citrix.com>
Date: Mon, 8 Dec 2014 19:03: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: Xen-devel List <xen-devel@lists.xen.org>
X-DLP: MIA1
Subject: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Over the weekend, XenServer testing managed to run a side-by-side test
of XenServer trunk and XenServer experimental xen-4.5.  These are
identical other than the version of Xen (and associated libraries) in
use, i.e. identical dom0 kernel, Xapi toolstack and dom0 userspace,
other than as linked against newer Xen libraries.

The Xen-4.5 tests were on top of c/s e6c3d371d4 "systemd: use pkg-config
to determine systemd library availability"

There are a few notable issues exposed:

XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it didn't in
xen-4.4, given identical parameters.  The hypercall gained an extra
permission check as part of 0561e1f01e.  Our usecase here is a daemon in
dom0 mapping guest RAM to emulate a graphics card, but I currently don't
see how that is incompatible with the new permissions check.

Migrations from older Xens to Xen-4.5 fairly reliably crash domains (90%
of the time, both PV and HVM guests).  This includes migrates from older
XenServers using the legacy->v2 migration code which is confirmed-good
in "upgrade to Xen-4.4" case.  The migration v2 code in use is identical.

We have certain machines which are showing reliable failure to boot
under Xen-4.5, where they worked with 4.4.  Symptoms range from the dom0
kernel crashing before printing anything, to complaining that the initrd
is corrupt when attempting to decompress.  This appears to be hardware
specific.


I will be looking into all of these issues, to identify whether they are
indeed regressions in xen-4.5, or whether I have make some mistakes
forward porting our patch queue.

Unfortunately, our PCI Passthrough testing has been blocked behind other
regressions which have crept in recently, meaning that both sets of
tests were equally affected, and no 4.4 vs 4.5 comparison has been
possible at this time.  I hope this will be fixed by the next time I run
a similar pair of tests.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 19:26:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 19:26:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy3wL-0008Hl-Hz; Mon, 08 Dec 2014 19:25:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Xy3wJ-0008Hg-Oh
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 19:25:47 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	A3/62-02954-B3BF5845; Mon, 08 Dec 2014 19:25:47 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418066744!13753179!1
X-Originating-IP: [137.65.248.124]
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 2137 invoked from network); 8 Dec 2014 19:25:46 -0000
Received: from inet-orm.provo.novell.com (HELO mail.novell.com)
	(137.65.248.124)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 19:25:46 -0000
Received: from [137.65.222.146] ([137.65.222.146])
	by mail.novell.com with ESMTP (NOT encrypted);
	Mon, 08 Dec 2014 11:55:39 -0700
Message-ID: <5485F42A.5070604@suse.com>
Date: Mon, 08 Dec 2014 11:55:38 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
Cc: libvir-list@redhat.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH] libxl: Set path to console on
	domain startup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD wrote:
> Hi,
>
> I'm trying to fix an issue when using OpenStack with libvirt+xen (libxenlight).
> OpenStack cannot access the console output of a Xen PV guest, because the XML
> generated by libvirt for a domain is missing the path to the pty. The path
> actually appear in the XML once one call virDomainOpenConsole().
>
> The patch intend to get the path to the pty without having to call
> virDomainOpenConsole, so I've done the work in libxlDomainStart(). So I have a
> few question:
> Is libxlDomainStart will be called on restore/migrate/reboot?
>   

Yes.

> I guest the function libxlDomainOpenConsole() would not need to do the same
> work if the console path is settup properly.
>   

Yes, agreed.

Regards,
Jim


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 19:26:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 19:26:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy3wN-0008I9-2f; Mon, 08 Dec 2014 19:25:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Xy3wM-0008Hr-BF
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 19:25:50 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	49/5F-14214-D3BF5845; Mon, 08 Dec 2014 19:25:49 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418066747!8851965!1
X-Originating-IP: [137.65.248.124]
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 16780 invoked from network); 8 Dec 2014 19:25:48 -0000
Received: from inet-orm.provo.novell.com (HELO mail.novell.com)
	(137.65.248.124)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2014 19:25:48 -0000
Received: from [137.65.222.146] ([137.65.222.146])
	by mail.novell.com with ESMTP (NOT encrypted);
	Mon, 08 Dec 2014 12:03:42 -0700
Message-ID: <5485F608.1080005@suse.com>
Date: Mon, 08 Dec 2014 12:03:36 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
Cc: libvir-list@redhat.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH] libxl: Set path to console on
	domain startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD wrote:
> The path to the pty of a Xen PV console is set only in
> virDomainOpenConsole. But this is done too late. A call to
> virDomainGetXMLDesc done before OpenConsole will not have the path to
> the pty, but a call after OpenConsole will.
>   

Hi Anthony,

Thanks for the patch. Can you address the comments made by others, my
comments below, and provide a V2?

> e.g. of the current issue.
> Starting a domain with '<console type="pty"/>'
> Then:
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty'>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> virDomainOpenConsole()
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty' tty='/dev/pts/30'>
>       <source path='/dev/pts/30'/>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
>
> The patch intend to get the tty path on the first call of GetXMLDesc.
>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  src/libxl/libxl_domain.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 9c62291..de56054 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
>      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
>          goto cleanup_dom;
>  
> +    if (vm->def->nconsoles) {
> +        virDomainChrDefPtr chr = NULL;
> +        chr = vm->def->consoles[0];
> +        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
> +            libxl_console_type console_type;
> +            char *console = NULL;
> +            console_type =
> +                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
> +                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
> +            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
> +                                        console_type, &console);
> +            if (!ret)
> +                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
>   

VIR_STRDUP will not free an existing value. You should VIR_FREE first,
which btw can handle a NULL argument. And since you're initializing
source.data.file.path when starting the domain, I think we can drop the
similar code in libxlDomainOpenConsole().

Regards,
Jim

> +            VIR_FREE(console);
> +        }
> +    }
> +
>      if (!start_paused) {
>          libxl_domain_unpause(priv->ctx, domid);
>          virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED);
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 19:26:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 19:26:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy3wL-0008Hl-Hz; Mon, 08 Dec 2014 19:25:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Xy3wJ-0008Hg-Oh
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 19:25:47 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	A3/62-02954-B3BF5845; Mon, 08 Dec 2014 19:25:47 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418066744!13753179!1
X-Originating-IP: [137.65.248.124]
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 2137 invoked from network); 8 Dec 2014 19:25:46 -0000
Received: from inet-orm.provo.novell.com (HELO mail.novell.com)
	(137.65.248.124)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 19:25:46 -0000
Received: from [137.65.222.146] ([137.65.222.146])
	by mail.novell.com with ESMTP (NOT encrypted);
	Mon, 08 Dec 2014 11:55:39 -0700
Message-ID: <5485F42A.5070604@suse.com>
Date: Mon, 08 Dec 2014 11:55:38 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
Cc: libvir-list@redhat.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH] libxl: Set path to console on
	domain startup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD wrote:
> Hi,
>
> I'm trying to fix an issue when using OpenStack with libvirt+xen (libxenlight).
> OpenStack cannot access the console output of a Xen PV guest, because the XML
> generated by libvirt for a domain is missing the path to the pty. The path
> actually appear in the XML once one call virDomainOpenConsole().
>
> The patch intend to get the path to the pty without having to call
> virDomainOpenConsole, so I've done the work in libxlDomainStart(). So I have a
> few question:
> Is libxlDomainStart will be called on restore/migrate/reboot?
>   

Yes.

> I guest the function libxlDomainOpenConsole() would not need to do the same
> work if the console path is settup properly.
>   

Yes, agreed.

Regards,
Jim


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 19:26:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 19:26:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy3wN-0008I9-2f; Mon, 08 Dec 2014 19:25:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Xy3wM-0008Hr-BF
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 19:25:50 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	49/5F-14214-D3BF5845; Mon, 08 Dec 2014 19:25:49 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418066747!8851965!1
X-Originating-IP: [137.65.248.124]
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 16780 invoked from network); 8 Dec 2014 19:25:48 -0000
Received: from inet-orm.provo.novell.com (HELO mail.novell.com)
	(137.65.248.124)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Dec 2014 19:25:48 -0000
Received: from [137.65.222.146] ([137.65.222.146])
	by mail.novell.com with ESMTP (NOT encrypted);
	Mon, 08 Dec 2014 12:03:42 -0700
Message-ID: <5485F608.1080005@suse.com>
Date: Mon, 08 Dec 2014 12:03:36 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
Cc: libvir-list@redhat.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH] libxl: Set path to console on
	domain startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD wrote:
> The path to the pty of a Xen PV console is set only in
> virDomainOpenConsole. But this is done too late. A call to
> virDomainGetXMLDesc done before OpenConsole will not have the path to
> the pty, but a call after OpenConsole will.
>   

Hi Anthony,

Thanks for the patch. Can you address the comments made by others, my
comments below, and provide a V2?

> e.g. of the current issue.
> Starting a domain with '<console type="pty"/>'
> Then:
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty'>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> virDomainOpenConsole()
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty' tty='/dev/pts/30'>
>       <source path='/dev/pts/30'/>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
>
> The patch intend to get the tty path on the first call of GetXMLDesc.
>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  src/libxl/libxl_domain.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 9c62291..de56054 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
>      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
>          goto cleanup_dom;
>  
> +    if (vm->def->nconsoles) {
> +        virDomainChrDefPtr chr = NULL;
> +        chr = vm->def->consoles[0];
> +        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
> +            libxl_console_type console_type;
> +            char *console = NULL;
> +            console_type =
> +                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
> +                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
> +            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
> +                                        console_type, &console);
> +            if (!ret)
> +                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
>   

VIR_STRDUP will not free an existing value. You should VIR_FREE first,
which btw can handle a NULL argument. And since you're initializing
source.data.file.path when starting the domain, I think we can drop the
similar code in libxlDomainOpenConsole().

Regards,
Jim

> +            VIR_FREE(console);
> +        }
> +    }
> +
>      if (!start_paused) {
>          libxl_domain_unpause(priv->ctx, domid);
>          virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED);
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 19:33:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 19:33:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy43x-0000OU-0u; Mon, 08 Dec 2014 19:33: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 1Xy43v-0000OP-F4
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 19:33:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	73/89-15461-21DF5845; Mon, 08 Dec 2014 19:33:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418067213!14202912!1
X-Originating-IP: [66.165.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 13533 invoked from network); 8 Dec 2014 19:33:37 -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;
	8 Dec 2014 19:33:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,540,1413244800"; d="scan'208";a="201953376"
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.210.2; Mon, 8 Dec 2014 14:31: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 1Xy42A-00042b-Fl;
	Mon, 08 Dec 2014 19:31:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xy429-0007K5-RJ;
	Mon, 08 Dec 2014 19:31:49 +0000
Date: Mon, 8 Dec 2014 19:31:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32141-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] 32141: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32141 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32141/

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-xl-qemut-debianhvm-amd64 15 guest-start.2 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-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-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 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-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-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-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                19b022572b9e0fa8ce5490db888714ecb2b1293e
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
736 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                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 32551 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 Dec 08 19:33:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 19:33:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy43x-0000OU-0u; Mon, 08 Dec 2014 19:33: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 1Xy43v-0000OP-F4
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 19:33:39 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	73/89-15461-21DF5845; Mon, 08 Dec 2014 19:33:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418067213!14202912!1
X-Originating-IP: [66.165.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 13533 invoked from network); 8 Dec 2014 19:33:37 -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;
	8 Dec 2014 19:33:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,540,1413244800"; d="scan'208";a="201953376"
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.210.2; Mon, 8 Dec 2014 14:31: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 1Xy42A-00042b-Fl;
	Mon, 08 Dec 2014 19:31:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xy429-0007K5-RJ;
	Mon, 08 Dec 2014 19:31:49 +0000
Date: Mon, 8 Dec 2014 19:31:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32141-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] 32141: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32141 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32141/

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-xl-qemut-debianhvm-amd64 15 guest-start.2 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-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-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 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-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-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-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                19b022572b9e0fa8ce5490db888714ecb2b1293e
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
736 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                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 32551 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 Dec 08 20:01:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 20: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 1Xy4U9-00019P-GW; Mon, 08 Dec 2014 20:00: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 1Xy4U7-00019I-Vz
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 20:00:44 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	A3/D3-02699-B6306845; Mon, 08 Dec 2014 20:00:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418068838!9121013!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9333 invoked from network); 8 Dec 2014 20:00:40 -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; 8 Dec 2014 20:00: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 sB8K0ZJk029467
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 20:00: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
	sB8K0YHp025412
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Dec 2014 20:00:34 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
	sB8K0XEL025347; Mon, 8 Dec 2014 20:00:34 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 12:00:33 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8982A122255; Mon,  8 Dec 2014 15:00:34 -0500 (EST)
Date: Mon, 8 Dec 2014 15:00:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141208200034.GA3891@laptop.dumpdata.com>
References: <5485F5F7.6040206@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5485F5F7.6040206@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 07:03:19PM +0000, Andrew Cooper wrote:
> Hi,

Hey Andrew!
> 
> Over the weekend, XenServer testing managed to run a side-by-side test
> of XenServer trunk and XenServer experimental xen-4.5.  These are
> identical other than the version of Xen (and associated libraries) in
> use, i.e. identical dom0 kernel, Xapi toolstack and dom0 userspace,
> other than as linked against newer Xen libraries.
> 
> The Xen-4.5 tests were on top of c/s e6c3d371d4 "systemd: use pkg-config
> to determine systemd library availability"
> 
> There are a few notable issues exposed:
> 
> XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it didn't in
> xen-4.4, given identical parameters.  The hypercall gained an extra
> permission check as part of 0561e1f01e.  Our usecase here is a daemon in
> dom0 mapping guest RAM to emulate a graphics card, but I currently don't
> see how that is incompatible with the new permissions check.

I presume the daemon also does 'XEN_DOMCTL_iomem_permission' to grant
the other domain access to its RAM? And before it makes the
XEN_DOMCTL_memory_mapping hypercall.

> 
> Migrations from older Xens to Xen-4.5 fairly reliably crash domains (90%
> of the time, both PV and HVM guests).  This includes migrates from older
> XenServers using the legacy->v2 migration code which is confirmed-good
> in "upgrade to Xen-4.4" case.  The migration v2 code in use is identical.

The XenServer is not using the in-the-tree migration system except in
the older version of XenServer right?
> 
> We have certain machines which are showing reliable failure to boot
> under Xen-4.5, where they worked with 4.4.  Symptoms range from the dom0
> kernel crashing before printing anything, to complaining that the initrd
> is corrupt when attempting to decompress.  This appears to be hardware
> specific.

Hardware specific is good. Could you give some ideas of what make/model
this is?

> 
> 
> I will be looking into all of these issues, to identify whether they are
> indeed regressions in xen-4.5, or whether I have make some mistakes
> forward porting our patch queue.

OK
> 
> Unfortunately, our PCI Passthrough testing has been blocked behind other
> regressions which have crept in recently, meaning that both sets of
> tests were equally affected, and no 4.4 vs 4.5 comparison has been
> possible at this time.  I hope this will be fixed by the next time I run
> a similar pair of tests.

<nods> 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 Mon Dec 08 20:01:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 20: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 1Xy4U9-00019P-GW; Mon, 08 Dec 2014 20:00: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 1Xy4U7-00019I-Vz
	for xen-devel@lists.xen.org; Mon, 08 Dec 2014 20:00:44 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	A3/D3-02699-B6306845; Mon, 08 Dec 2014 20:00:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418068838!9121013!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9333 invoked from network); 8 Dec 2014 20:00:40 -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; 8 Dec 2014 20:00: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 sB8K0ZJk029467
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 20:00: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
	sB8K0YHp025412
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Dec 2014 20:00:34 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
	sB8K0XEL025347; Mon, 8 Dec 2014 20:00:34 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 12:00:33 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8982A122255; Mon,  8 Dec 2014 15:00:34 -0500 (EST)
Date: Mon, 8 Dec 2014 15:00:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141208200034.GA3891@laptop.dumpdata.com>
References: <5485F5F7.6040206@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5485F5F7.6040206@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 07:03:19PM +0000, Andrew Cooper wrote:
> Hi,

Hey Andrew!
> 
> Over the weekend, XenServer testing managed to run a side-by-side test
> of XenServer trunk and XenServer experimental xen-4.5.  These are
> identical other than the version of Xen (and associated libraries) in
> use, i.e. identical dom0 kernel, Xapi toolstack and dom0 userspace,
> other than as linked against newer Xen libraries.
> 
> The Xen-4.5 tests were on top of c/s e6c3d371d4 "systemd: use pkg-config
> to determine systemd library availability"
> 
> There are a few notable issues exposed:
> 
> XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it didn't in
> xen-4.4, given identical parameters.  The hypercall gained an extra
> permission check as part of 0561e1f01e.  Our usecase here is a daemon in
> dom0 mapping guest RAM to emulate a graphics card, but I currently don't
> see how that is incompatible with the new permissions check.

I presume the daemon also does 'XEN_DOMCTL_iomem_permission' to grant
the other domain access to its RAM? And before it makes the
XEN_DOMCTL_memory_mapping hypercall.

> 
> Migrations from older Xens to Xen-4.5 fairly reliably crash domains (90%
> of the time, both PV and HVM guests).  This includes migrates from older
> XenServers using the legacy->v2 migration code which is confirmed-good
> in "upgrade to Xen-4.4" case.  The migration v2 code in use is identical.

The XenServer is not using the in-the-tree migration system except in
the older version of XenServer right?
> 
> We have certain machines which are showing reliable failure to boot
> under Xen-4.5, where they worked with 4.4.  Symptoms range from the dom0
> kernel crashing before printing anything, to complaining that the initrd
> is corrupt when attempting to decompress.  This appears to be hardware
> specific.

Hardware specific is good. Could you give some ideas of what make/model
this is?

> 
> 
> I will be looking into all of these issues, to identify whether they are
> indeed regressions in xen-4.5, or whether I have make some mistakes
> forward porting our patch queue.

OK
> 
> Unfortunately, our PCI Passthrough testing has been blocked behind other
> regressions which have crept in recently, meaning that both sets of
> tests were equally affected, and no 4.4 vs 4.5 comparison has been
> possible at this time.  I hope this will be fixed by the next time I run
> a similar pair of tests.

<nods> 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 Mon Dec 08 20:46:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 20:46:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy5Bw-0002cj-5o; Mon, 08 Dec 2014 20:46: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 1Xy5Bu-0002ce-AH
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 20:45:58 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	94/11-29352-50E06845; Mon, 08 Dec 2014 20:45:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418071553!12200040!1
X-Originating-IP: [66.165.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 10359 invoked from network); 8 Dec 2014 20:45: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;
	8 Dec 2014 20:45:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,540,1413244800"; d="scan'208";a="201985471"
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.210.2; Mon, 8 Dec 2014 15:45: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 1Xy5Bm-0004OT-NF;
	Mon, 08 Dec 2014 20:45:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xy5Bm-0006h8-Bz;
	Mon, 08 Dec 2014 20:45:50 +0000
Date: Mon, 8 Dec 2014 20:45:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32144-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] 32144: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32144 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32144/

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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           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-qemut-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-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                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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 34178 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 Dec 08 20:46:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 20:46:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy5Bw-0002cj-5o; Mon, 08 Dec 2014 20:46: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 1Xy5Bu-0002ce-AH
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 20:45:58 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	94/11-29352-50E06845; Mon, 08 Dec 2014 20:45:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418071553!12200040!1
X-Originating-IP: [66.165.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 10359 invoked from network); 8 Dec 2014 20:45: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;
	8 Dec 2014 20:45:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,540,1413244800"; d="scan'208";a="201985471"
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.210.2; Mon, 8 Dec 2014 15:45: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 1Xy5Bm-0004OT-NF;
	Mon, 08 Dec 2014 20:45:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xy5Bm-0006h8-Bz;
	Mon, 08 Dec 2014 20:45:50 +0000
Date: Mon, 8 Dec 2014 20:45:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32144-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] 32144: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32144 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32144/

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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           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-qemut-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-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                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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 34178 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 Dec 08 20:46:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 20:46:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy5Cp-0002fu-KD; Mon, 08 Dec 2014 20:46: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 1Xy5Co-0002ff-9v
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 20:46:54 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	BF/5E-23865-D3E06845; Mon, 08 Dec 2014 20:46:53 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418071611!11913743!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29436 invoked from network); 8 Dec 2014 20:46:52 -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; 8 Dec 2014 20:46:52 -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 sB8KkkH4019475
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 20:46:47 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
	sB8KkioO018605
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 20:46:44 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
	sB8KkhY6018577; Mon, 8 Dec 2014 20:46: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 ; Mon, 08 Dec 2014 12:46:43 -0800
Message-ID: <54860EA4.7090705@oracle.com>
Date: Mon, 08 Dec 2014 15:48:36 -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: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1418048267-18509-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418048267-18509-1-git-send-email-vkuznets@redhat.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xenproject.org, Andrew Jones <drjones@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: remove redundant flush_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/08/2014 09:17 AM, Vitaly Kuznetsov wrote:
> flush_op is unambiguously defined by feature_flush:
>      REQ_FUA | REQ_FLUSH -> BLKIF_OP_WRITE_BARRIER
>      REQ_FLUSH -> BLKIF_OP_FLUSH_DISKCACHE
>      0 -> 0
> and thus can be removed. This is just a cleanup.
>
> The patch was suggested by Boris Ostrovsky.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> The patch is supposed to be applied after "xen/blkfront: improve protection
> against issuing unsupported REQ_FUA".
> ---
>   drivers/block/xen-blkfront.c | 24 ++++++++++++------------
>   1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2e6c103..d1ee233 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -126,7 +126,6 @@ struct blkfront_info
>   	unsigned int persistent_gnts_c;
>   	unsigned long shadow_free;
>   	unsigned int feature_flush;
> -	unsigned int flush_op;
>   	unsigned int feature_discard:1;
>   	unsigned int feature_secdiscard:1;
>   	unsigned int discard_granularity;
> @@ -479,7 +478,14 @@ static int blkif_queue_request(struct request *req)
>   				 * way.  (It's also a FLUSH+FUA, since it is
>   				 * guaranteed ordered WRT previous writes.)
>   				 */
> -				ring_req->operation = info->flush_op;
> +				if (unlikely(info->feature_flush & REQ_FUA))
> +					ring_req->operation =
> +						BLKIF_OP_WRITE_BARRIER;
> +				else if (likely(info->feature_flush))
> +					ring_req->operation =
> +						BLKIF_OP_FLUSH_DISKCACHE;

To better future-proof it against new flags maybe something like

     switch ( info->feature_flush & (REQ_FLUSH|REQ_FUA) ) {
            case REQ_FLUSH|REQ_FUA: ...
            case REQ_FLUSH: ...
            default: ...

or the if/else equivalent?


> +				else
> +					ring_req->operation = 0;
>   			}
>   			ring_req->u.rw.nr_segments = nseg;
>   		}
> @@ -691,8 +697,8 @@ static void xlvbd_flush(struct blkfront_info *info)
>   	blk_queue_flush(info->rq, info->feature_flush);
>   	printk(KERN_INFO "blkfront: %s: %s: %s %s %s %s %s\n",
>   	       info->gd->disk_name,
> -	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
> +	       info->feature_flush == (REQ_FLUSH | REQ_FUA) ?
> +		"barrier" : (info->feature_flush == REQ_FLUSH ?

And something similar here?

Thanks.
-boris


>   		"flush diskcache" : "barrier or flush"),
>   	       info->feature_flush ? "enabled;" : "disabled;",
>   	       "persistent grants:",
> @@ -1190,7 +1196,6 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>   				if (error == -EOPNOTSUPP)
>   					error = 0;
>   				info->feature_flush = 0;
> -				info->flush_op = 0;
>   				xlvbd_flush(info);
>   			}
>   			/* fall through */
> @@ -1810,7 +1815,6 @@ static void blkfront_connect(struct blkfront_info *info)
>   		physical_sector_size = sector_size;
>   
>   	info->feature_flush = 0;
> -	info->flush_op = 0;
>   
>   	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
>   			    "feature-barrier", "%d", &barrier,
> @@ -1823,10 +1827,8 @@ static void blkfront_connect(struct blkfront_info *info)
>   	 *
>   	 * If there are barriers, then we use flush.
>   	 */
> -	if (!err && barrier) {
> +	if (!err && barrier)
>   		info->feature_flush = REQ_FLUSH | REQ_FUA;
> -		info->flush_op = BLKIF_OP_WRITE_BARRIER;
> -	}
>   	/*
>   	 * And if there is "feature-flush-cache" use that above
>   	 * barriers.
> @@ -1835,10 +1837,8 @@ static void blkfront_connect(struct blkfront_info *info)
>   			    "feature-flush-cache", "%d", &flush,
>   			    NULL);
>   
> -	if (!err && flush) {
> +	if (!err && flush)
>   		info->feature_flush = REQ_FLUSH;
> -		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
> -	}
>   
>   	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
>   			    "feature-discard", "%d", &discard,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 20:46:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 20:46:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy5Cp-0002fu-KD; Mon, 08 Dec 2014 20:46: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 1Xy5Co-0002ff-9v
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 20:46:54 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	BF/5E-23865-D3E06845; Mon, 08 Dec 2014 20:46:53 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418071611!11913743!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29436 invoked from network); 8 Dec 2014 20:46:52 -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; 8 Dec 2014 20:46:52 -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 sB8KkkH4019475
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 20:46:47 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
	sB8KkioO018605
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 20:46:44 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
	sB8KkhY6018577; Mon, 8 Dec 2014 20:46: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 ; Mon, 08 Dec 2014 12:46:43 -0800
Message-ID: <54860EA4.7090705@oracle.com>
Date: Mon, 08 Dec 2014 15:48:36 -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: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1418048267-18509-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418048267-18509-1-git-send-email-vkuznets@redhat.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xenproject.org, Andrew Jones <drjones@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: remove redundant flush_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/08/2014 09:17 AM, Vitaly Kuznetsov wrote:
> flush_op is unambiguously defined by feature_flush:
>      REQ_FUA | REQ_FLUSH -> BLKIF_OP_WRITE_BARRIER
>      REQ_FLUSH -> BLKIF_OP_FLUSH_DISKCACHE
>      0 -> 0
> and thus can be removed. This is just a cleanup.
>
> The patch was suggested by Boris Ostrovsky.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> The patch is supposed to be applied after "xen/blkfront: improve protection
> against issuing unsupported REQ_FUA".
> ---
>   drivers/block/xen-blkfront.c | 24 ++++++++++++------------
>   1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2e6c103..d1ee233 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -126,7 +126,6 @@ struct blkfront_info
>   	unsigned int persistent_gnts_c;
>   	unsigned long shadow_free;
>   	unsigned int feature_flush;
> -	unsigned int flush_op;
>   	unsigned int feature_discard:1;
>   	unsigned int feature_secdiscard:1;
>   	unsigned int discard_granularity;
> @@ -479,7 +478,14 @@ static int blkif_queue_request(struct request *req)
>   				 * way.  (It's also a FLUSH+FUA, since it is
>   				 * guaranteed ordered WRT previous writes.)
>   				 */
> -				ring_req->operation = info->flush_op;
> +				if (unlikely(info->feature_flush & REQ_FUA))
> +					ring_req->operation =
> +						BLKIF_OP_WRITE_BARRIER;
> +				else if (likely(info->feature_flush))
> +					ring_req->operation =
> +						BLKIF_OP_FLUSH_DISKCACHE;

To better future-proof it against new flags maybe something like

     switch ( info->feature_flush & (REQ_FLUSH|REQ_FUA) ) {
            case REQ_FLUSH|REQ_FUA: ...
            case REQ_FLUSH: ...
            default: ...

or the if/else equivalent?


> +				else
> +					ring_req->operation = 0;
>   			}
>   			ring_req->u.rw.nr_segments = nseg;
>   		}
> @@ -691,8 +697,8 @@ static void xlvbd_flush(struct blkfront_info *info)
>   	blk_queue_flush(info->rq, info->feature_flush);
>   	printk(KERN_INFO "blkfront: %s: %s: %s %s %s %s %s\n",
>   	       info->gd->disk_name,
> -	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
> +	       info->feature_flush == (REQ_FLUSH | REQ_FUA) ?
> +		"barrier" : (info->feature_flush == REQ_FLUSH ?

And something similar here?

Thanks.
-boris


>   		"flush diskcache" : "barrier or flush"),
>   	       info->feature_flush ? "enabled;" : "disabled;",
>   	       "persistent grants:",
> @@ -1190,7 +1196,6 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>   				if (error == -EOPNOTSUPP)
>   					error = 0;
>   				info->feature_flush = 0;
> -				info->flush_op = 0;
>   				xlvbd_flush(info);
>   			}
>   			/* fall through */
> @@ -1810,7 +1815,6 @@ static void blkfront_connect(struct blkfront_info *info)
>   		physical_sector_size = sector_size;
>   
>   	info->feature_flush = 0;
> -	info->flush_op = 0;
>   
>   	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
>   			    "feature-barrier", "%d", &barrier,
> @@ -1823,10 +1827,8 @@ static void blkfront_connect(struct blkfront_info *info)
>   	 *
>   	 * If there are barriers, then we use flush.
>   	 */
> -	if (!err && barrier) {
> +	if (!err && barrier)
>   		info->feature_flush = REQ_FLUSH | REQ_FUA;
> -		info->flush_op = BLKIF_OP_WRITE_BARRIER;
> -	}
>   	/*
>   	 * And if there is "feature-flush-cache" use that above
>   	 * barriers.
> @@ -1835,10 +1837,8 @@ static void blkfront_connect(struct blkfront_info *info)
>   			    "feature-flush-cache", "%d", &flush,
>   			    NULL);
>   
> -	if (!err && flush) {
> +	if (!err && flush)
>   		info->feature_flush = REQ_FLUSH;
> -		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
> -	}
>   
>   	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
>   			    "feature-discard", "%d", &discard,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 21:28:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 21: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 1Xy5qP-0003xf-E1; Mon, 08 Dec 2014 21:27: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 1Xy5qN-0003xa-Jr
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 21:27:47 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	C0/D5-17958-2D716845; Mon, 08 Dec 2014 21:27:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418074064!11818021!1
X-Originating-IP: [156.151.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 22811 invoked from network); 8 Dec 2014 21:27:45 -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; 8 Dec 2014 21:27: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 sB8LRgWu027927
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 8 Dec 2014 21:27:43 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
	sB8LRf0Q010826
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 8 Dec 2014 21:27:42 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
	sB8LRfgs005671
	for <xen-devel@lists.xensource.com>; Mon, 8 Dec 2014 21:27:41 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 13:27:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0AE83122350; Mon,  8 Dec 2014 16:27:40 -0500 (EST)
Date: Mon, 8 Dec 2014 16:27:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20141208212739.GA7226@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]
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Subject: [Xen-devel] Xen  4.5.0rc3 + Linux v3.18 + dom0pvh=1 = BOOM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 what I get with Xen 4.5.0-rc3. I hadn't yet dug in the
details except that I thought the v3.18 had the correct
fix for PVH (It sure looks to have it).

Cc-ing Elena as she has a similar issue.

 Xen 4.5.0-rc-lK
(XEN) Xen version 4.5.0-rc-lK (konrad@oracle.com) (gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)) debug=y Mon Dec  8 16:00:18 EST 2014
(XEN) Latest ChangeSet: Mon Dec 8 15:52:40 2014 -0500 git:82b9031
(XEN) Bootloader: EFI
(XEN) Command line: console=vga,com1 com1=115200,8n1 loglvl=all iommu=verbose guest_loglvl=all dom0pvh=1
(XEN) Video information:
(XEN)  VGA is graphics mode 1920x1080, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) EFI RAM map:
(XEN)  0000000000000000 - 0000000000058000 (usable)
(XEN)  0000000000058000 - 0000000000059000 (reserved)
(XEN)  0000000000059000 - 000000000009f000 (usable)
(XEN)  000000000009f000 - 00000000000a0000 (reserved)
(XEN)  0000000000100000 - 00000000c2dcb000 (usable)
(XEN)  00000000c2dcb000 - 00000000c2dd2000 (ACPI NVS)
(XEN)  00000000c2dd2000 - 00000000c321a000 (usable)
(XEN)  00000000c321a000 - 00000000c36bc000 (reserved)
(XEN)  00000000c36bc000 - 00000000d48ed000 (usable)
(XEN)  00000000d48ed000 - 00000000d4979000 (reserved)
(XEN)  00000000d4979000 - 00000000d49db000 (ACPI data)
(XEN)  00000000d49db000 - 00000000d56f4000 (ACPI NVS)
(XEN)  00000000d56f4000 - 00000000d5fff000 (reserved)
(XEN)  00000000d5fff000 - 00000000d6000000 (usable)
(XEN)  00000000d7000000 - 00000000df200000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed00000 - 00000000fed04000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000041ee00000 (usable)
(XEN) ACPI: RSDP D498C000, 0024 (r2 LENOVO)
(XEN) ACPI: XSDT D498C098, 00AC (r1 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: FACP D49A3980, 010C (r5 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: DSDT D498C1D0, 177B0 (r2 LENOVO TC-FB        1A10 INTL 20120711)
(XEN) ACPI: FACS D56F2F80, 0040
(XEN) ACPI: APIC D49A3A90, 0092 (r3 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: FPDT D49A3B28, 0044 (r1 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: FIDT D49A3B70, 009C (r1 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: TCPA D49A3C10, 0032 (r2 LENOVO TC-FB        1A10 MSFT  1000013)
(XEN) ACPI: SLIC D49A3C48, 0176 (r1 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: MSDM D49A3DC0, 0055 (r3 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: SSDT D49A3E18, 0539 (r1 LENOVO TC-FB        1A10 INTL 20120711)
(XEN) ACPI: SSDT D49A4358, 0AD8 (r1 LENOVO TC-FB        1A10 INTL 20120711)
(XEN) ACPI: MCFG D49A4E30, 003C (r1 LENOVO TC-FB        1A10 MSFT       97)
(XEN) ACPI: HPET D49A4E70, 0038 (r1 LENOVO TC-FB        1A10 AMI.        5)
(XEN) ACPI: SSDT D49A4EA8, 036D (r1 LENOVO TC-FB        1A10 INTL 20120711)
(XEN) ACPI: SSDT D49A5218, 3528 (r1 LENOVO TC-FB        1A10 INTL 20091112)
(XEN) ACPI: ASF! D49A8740, 00A5 (r32 LENOVO TC-FB        1A10 TFSM    F4240)
(XEN) ACPI: BGRT D49A87E8, 0038 (r0 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: LUFT D49A8820, 32000 (r1 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: DMAR D49DA820, 00B8 (r1 LENOVO TC-FB        1A10 INTL        1)
(XEN) System RAM: 16177MB (16566156kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000041ee00000
(XEN) Domain heap initialised
(XEN) vesafb: framebuffer at 0xe0000000, mapped to 0xffff82c000201000, using 8128k, total 8128k
(XEN) vesafb: mode is 1920x1080x32, linelength=7680, font 8x16
(XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
(XEN) Couldn't initialize a 1920x1080 framebuffer early.
(XEN) SMBIOS 2.8 present.
(XEN) DMI 2.7 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1808
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1804,1:0], pm1x_evt[1:1800,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - d56f2f80/0000000000000000, using 32
(XEN) ACPI:             wakeup_vec[d56f2f8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)
(XEN) Processor #1 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)
(XEN) Processor #3 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)
(XEN) Processor #5 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
(XEN) Processor #7 7:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) [VT-D]dmar.c:788: Host address width 39
(XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:472:   dmaru->address = fed90000
(XEN) [VT-D]iommu.c:1146: drhd->address = fed90000 iommu->reg = ffff82c0009f2000
(XEN) [VT-D]iommu.c:1148: cap = c0000020660462 ecap = f0101a
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:02.0
(XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:472:   dmaru->address = fed91000
(XEN) [VT-D]iommu.c:1146: drhd->address = fed91000 iommu->reg = ffff82c0009f4000
(XEN) [VT-D]iommu.c:1148: cap = d2008020660462 ecap = f010da
(XEN) [VT-D]dmar.c:397:  IOAPIC: 0000:f0:1f.0
(XEN) [VT-D]dmar.c:361:  MSI HPET: 0000:f0:0f.0
(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:1d.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:14.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr d5e6b000 end_address d5e91fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:02.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr d7000000 end_address df1fffff
(XEN) ERST table was not found
(XEN) ACPI: BGRT: invalidating v1 image at 0xc8809018
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 1528 MSI/MSI-X
(XEN) Switched to APIC driver x2apic_cluster.
(XEN) XSM Framework v1.0.0 initialized
(XEN) Flask:  Initializing.
(XEN) AVC INITIALIZED
(XEN) Flask:  Starting in permissive mode.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3392.259 MHz processor.
(XEN) EFI memory map:
(XEN)  0000000000000-0000000007fff type=3 attr=000000000000000f
(XEN)  0000000008000-0000000057fff type=7 attr=000000000000000f
(XEN)  0000000058000-0000000058fff type=0 attr=000000000000000f
(XEN)  0000000059000-000000005bfff type=7 attr=000000000000000f
(XEN)  000000005c000-000000005efff type=2 attr=000000000000000f
(XEN)  000000005f000-000000005ffff type=4 attr=000000000000000f
(XEN)  0000000060000-000000009efff type=3 attr=000000000000000f
(XEN)  000000009f000-000000009ffff type=0 attr=000000000000000f
(XEN)  0000000100000-00000007fffff type=7 attr=000000000000000f
(XEN)  0000000800000-00000008fffff type=4 attr=000000000000000f
(XEN)  0000000900000-00000bd5fbfff type=7 attr=000000000000000f
(XEN)  00000bd5fc000-00000bf7d8fff type=2 attr=000000000000000f
(XEN)  00000bf7d9000-00000c163efff type=7 attr=000000000000000f
(XEN)  00000c163f000-00000c1bcafff type=2 attr=000000000000000f
(XEN)  00000c1bcb000-00000c2dcafff type=1 attr=000000000000000f
(XEN)  00000c2dcb000-00000c2dd1fff type=10 attr=000000000000000f
(XEN)  00000c2dd2000-00000c2f25fff type=4 attr=000000000000000f
(XEN)  00000c2f26000-00000c31cdfff type=3 attr=000000000000000f
(XEN)  00000c31ce000-00000c31d8fff type=4 attr=000000000000000f
(XEN)  00000c31d9000-00000c31e0fff type=3 attr=000000000000000f
(XEN)  00000c31e1000-00000c31e2fff type=4 attr=000000000000000f
(XEN)  00000c31e3000-00000c31e6fff type=3 attr=000000000000000f
(XEN)  00000c31e7000-00000c31fbfff type=4 attr=000000000000000f
(XEN)  00000c31fc000-00000c320dfff type=3 attr=000000000000000f
(XEN)  00000c320e000-00000c3219fff type=4 attr=000000000000000f
(XEN)  00000c321a000-00000c36bbfff type=6 attr=800000000000000f
(XEN)  00000c36bc000-00000c36c8fff type=4 attr=000000000000000f
(XEN)  00000c36c9000-00000c6e8dfff type=7 attr=000000000000000f
(XEN)  00000c6e8e000-00000c84e8fff type=4 attr=000000000000000f
(XEN)  00000c84e9000-00000c84eefff type=7 attr=000000000000000f
(XEN)  00000c84ef000-00000c8977fff type=4 attr=000000000000000f
(XEN)  00000c8978000-00000c897afff type=7 attr=000000000000000f
(XEN)  00000c897b000-00000d3eb0fff type=4 attr=000000000000000f
(XEN)  00000d3eb1000-00000d43d3fff type=7 attr=000000000000000f
(XEN)  00000d43d4000-00000d48ecfff type=3 attr=000000000000000f
(XEN)  00000d48ed000-00000d490afff type=0 attr=000000000000000f
(XEN)  00000d490b000-00000d4978fff type=0 attr=000000000000000f
(XEN)  00000d4979000-00000d498bfff type=9 attr=000000000000000f
(XEN)  00000d498c000-00000d49dafff type=9 attr=000000000000000f
(XEN)  00000d49db000-00000d4c7ffff type=10 attr=000000000000000f
(XEN)  00000d4c80000-00000d56f3fff type=10 attr=000000000000000f
(XEN)  00000d56f4000-00000d5d23fff type=6 attr=800000000000000f
(XEN)  00000d5d24000-00000d5ebffff type=6 attr=800000000000000f
(XEN)  00000d5ec0000-00000d5ec1fff type=6 attr=800000000000000f
(XEN)  00000d5ec2000-00000d5f61fff type=6 attr=800000000000000f
(XEN)  00000d5f62000-00000d5f80fff type=5 attr=800000000000000f
(XEN)  00000d5f81000-00000d5ffefff type=5 attr=800000000000000f
(XEN)  00000d5fff000-00000d5ffffff type=4 attr=000000000000000f
(XEN)  0000100000000-000041edfffff type=7 attr=000000000000000f
(XEN)  00000d7000000-00000df1fffff type=0 attr=0000000000000000
(XEN)  00000f8000000-00000fbffffff type=11 attr=8000000000000001
(XEN)  00000fec00000-00000fec00fff type=11 attr=8000000000000001
(XEN)  00000fed00000-00000fed03fff type=11 attr=8000000000000001
(XEN)  00000fed1c000-00000fed1ffff type=11 attr=8000000000000001
(XEN)  00000fee00000-00000fee00fff type=11 attr=8000000000000001
(XEN)  00000ff000000-00000ffffffff type=11 attr=8000000000000001
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(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 ffff82d080446dd0 -> ffff82d080447e20
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB.
(XEN) Intel VT-d iommu 1 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 enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
(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=0 pin2=0
(XEN) TSC deadline timer enabled
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 64 KiB.
(XEN) mwait-idle: MWAIT substates: 0x42120
(XEN) mwait-idle: v0.4 model 0x3c
(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)  - VMCS shadowing
(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 8 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=0xb2e000
(XEN) elf_parse_binary: phdr: paddr=0x1c00000 memsz=0x130000
(XEN) elf_parse_binary: phdr: paddr=0x1d30000 memsz=0x149c0
(XEN) elf_parse_binary: phdr: paddr=0x1d45000 memsz=0x537000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x227c000
(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 = 0xffffffff81d451f0
(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: MOD_START_PFN = 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        = 0xffffffff8227c000
(XEN)     virt_entry       = 0xffffffff81d451f0
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x227c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000400000000->0000000408000000 (4010843 pages to be allocated)
(XEN)  Init. ramdisk: 000000041cd23000->000000041edfffcb
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff8227c000
(XEN)  Init. ramdisk: 0000000000000000->0000000000000000
(XEN)  Phys-Mach map: ffffffff8227c000->ffffffff841661c0
(XEN)  Start info:    ffffffff84167000->ffffffff841684b4
(XEN)  Page tables:   ffffffff84169000->ffffffff8418e000
(XEN)  Boot stack:    ffffffff8418e000->ffffffff8418f000
(XEN)  TOTAL:         ffffffff80000000->ffffffff84400000
(XEN)  ENTRY ADDRESS: ffffffff81d451f0
(XEN) Dom0 has maximum 8 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff81b2e000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81c00000 -> 0xffffffff81d30000
(XEN) elf_load_binary: phdr 2 at 0xffffffff81d30000 -> 0xffffffff81d449c0
(XEN) elf_load_binary: phdr 3 at 0xffffffff81d45000 -> 0xffffffff81eab000
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:00:00.0 map
(XEN) Bogus DMIBAR 0xfed18001 on 0000:00:00.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:02.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:03.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:14.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:16.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:16.3
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:19.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1a.0
(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: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:2105: IOMMU: mapping reserved region failed
(XEN) [VT-D]iommu.c:739: iommu_enable_translation: iommu->reg = ffff82c0009f2000
(XEN) [VT-D]iommu.c:739: iommu_enable_translation: iommu->reg = ffff82c0009f4000
(XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs
(XEN) .................................done.
(XEN) Initial low memory virq threshold set at 0x1 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 316kB init memory.
mapping kernel into physical memory
about to get started...
(XEN) irq.c:380: Dom0 callback via changed to Direct Vector 0xf3
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.18.0 (konrad@localhost.localdomain) (gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC) ) #1 SMP Mon Dec 8 15:01:03 EST 2014
[    0.000000] Command line: root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root console=hvc0 console=tty0
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x0000000000057fff] usable
[    0.000000] Xen: [mem 0x0000000000058000-0x0000000000058fff] reserved
[    0.000000] Xen: [mem 0x0000000000059000-0x000000000009efff] usable
[    0.000000] Xen: [mem 0x000000000009f000-0x000000000009ffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000c2dcafff] usable
[    0.000000] Xen: [mem 0x00000000c2dcb000-0x00000000c2dd1fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000c2dd2000-0x00000000c3219fff] usable
[    0.000000] Xen: [mem 0x00000000c321a000-0x00000000c36bbfff] reserved
[    0.000000] Xen: [mem 0x00000000c36bc000-0x00000000d48ecfff] usable
[    0.000000] Xen: [mem 0x00000000d48ed000-0x00000000d4978fff] reserved
[    0.000000] Xen: [mem 0x00000000d4979000-0x00000000d49dafff] ACPI data
[    0.000000] Xen: [mem 0x00000000d49db000-0x00000000d56f3fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000d56f4000-0x00000000d5ffefff] reserved
[    0.000000] Xen: [mem 0x00000000d5fff000-0x00000000d5ffffff] usable
[    0.000000] Xen: [mem 0x00000000d7000000-0x00000000df1fffff] reserved
[    0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fed00000-0x00000000fed03fff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000409054fff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] efi: EFI v2.31 by American Megatrends
[    0.000000] efi:  ACPI=0xd498c000  ACPI 2.0=0xd498c000  SMBIOS=0xf0480  MPS=0xfca90 
[    0.000000] SMBIOS 2.8 present.
[    0.000000] e820: last_pfn = 0x409055 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xd6000 max_arch_pfn = 0x400000000
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000] init_memory_mapping: [mem 0x408e00000-0x408ffffff]
[    0.000000] init_memory_mapping: [mem 0x408000000-0x408dfffff]
[    0.000000] init_memory_mapping: [mem 0x400000000-0x407ffffff]
[    0.000000] init_memory_mapping: [mem 0x00100000-0xc2dcafff]
[    0.000000] init_memory_mapping: [mem 0xc2dd2000-0xc3219fff]
[    0.000000] init_memory_mapping: [mem 0xc36bc000-0xd48ecfff]
[    0.000000] init_memory_mapping: [mem 0xd5fff000-0xd5ffffff]
[    0.000000] init_memory_mapping: [mem 0x100000000-0x3ffffffff]
[    0.000000] init_memory_mapping: [mem 0x409000000-0x409054fff]
[    0.000000] RAMDISK: [mem 0x08000000-0x0a0dcfff]
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000D498C000 000024 (v02 LENOVO)
[    0.000000] ACPI: XSDT 0x00000000D498C098 0000AC (v01 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: FACP 0x00000000D49A3980 00010C (v05 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: DSDT 0x00000000D498C1D0 0177B0 (v02 LENOVO TC-FB    00001A10 INTL 20120711)
[    0.000000] ACPI: FACS 0x00000000D56F2F80 000040
[    0.000000] ACPI: APIC 0x00000000D49A3A90 000092 (v03 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: FPDT 0x00000000D49A3B28 000044 (v01 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: FIDT 0x00000000D49A3B70 00009C (v01 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: TCPA 0x00000000D49A3C10 000032 (v02 LENOVO TC-FB    00001A10 MSFT 01000013)
[    0.000000] ACPI: SLIC 0x00000000D49A3C48 000176 (v01 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: MSDM 0x00000000D49A3DC0 000055 (v03 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: SSDT 0x00000000D49A3E18 000539 (v01 LENOVO TC-FB    00001A10 INTL 20120711)
[    0.000000] ACPI: SSDT 0x00000000D49A4358 000AD8 (v01 LENOVO TC-FB    00001A10 INTL 20120711)
[    0.000000] ACPI: MCFG 0x00000000D49A4E30 00003C (v01 LENOVO TC-FB    00001A10 MSFT 00000097)
[    0.000000] ACPI: HPET 0x00000000D49A4E70 000038 (v01 LENOVO TC-FB    00001A10 AMI. 00000005)
[    0.000000] ACPI: SSDT 0x00000000D49A4EA8 00036D (v01 LENOVO TC-FB    00001A10 INTL 20120711)
[    0.000000] ACPI: SSDT 0x00000000D49A5218 003528 (v01 LENOVO TC-FB    00001A10 INTL 20091112)
[    0.000000] ACPI: ASF! 0x00000000D49A8740 0000A5 (v32 LENOVO TC-FB    00001A10 TFSM 000F4240)
[    0.000000] ACPI: BGRT 0x00000000D49A87E8 000038 (v00 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: LUFT 0x00000000D49A8820 032000 (v01 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: XMAR 0x00000000D49DA820 0000B8 (v01 LENOVO TC-FB    00001A10 INTL 00000001)
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x0000000409054fff]
[    0.000000] NODE_DATA(0) allocated [mem 0x409041000-0x409054fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x409054fff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x00057fff]
[    0.000000]   node   0: [mem 0x00059000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0xc2dcafff]
[    0.000000]   node   0: [mem 0xc2dd2000-0xc3219fff]
[    0.000000]   node   0: [mem 0xc36bc000-0xd48ecfff]
[    0.000000]   node   0: [mem 0xd5fff000-0xd5ffffff]
[    0.000000]   node   0: [mem 0x100000000-0x409054fff]
[    0.000000] Initmem setup node 0 [mem 0x00001000-0x409054fff]
[    0.000000] Reserving Intel graphics stolen memory at 0xd7200000-0xdf1fffff
[    0.000000] ACPI: PM-Timer IO Port: 0x1808
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 8 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[    0.000000] PM: Registered nosave memory: [mem 0x00058000-0x00058fff]
[    0.000000] PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
[    0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000fffff]
[    0.000000] PM: Registered nosave memory: [mem 0xc2dcb000-0xc2dd1fff]
[    0.000000] PM: Registered nosave memory: [mem 0xc321a000-0xc36bbfff]
[    0.000000] PM: Registered nosave memory: [mem 0xd48ed000-0xd4978fff]
[    0.000000] PM: Registered nosave memory: [mem 0xd4979000-0xd49dafff]
[    0.000000] PM: Registered nosave memory: [mem 0xd49db000-0xd56f3fff]
[    0.000000] PM: Registered nosave memory: [mem 0xd56f4000-0xd5ffefff]
[    0.000000] PM: Registered nosave memory: [mem 0xd6000000-0xd6ffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xd7000000-0xdf1fffff]
[    0.000000] PM: Registered nosave memory: [mem 0xdf200000-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-0xfec00fff]
[    0.000000] PM: Registered nosave memory: [mem 0xfec01000-0xfecfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfed00000-0xfed03fff]
[    0.000000] PM: Registered nosave memory: [mem 0xfed04000-0xfed1bfff]
[    0.000000] PM: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfed20000-0xfedfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfee00fff]
[    0.000000] PM: Registered nosave memory: [mem 0xfee01000-0xfeffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xff000000-0xffffffff]
[    0.000000] e820: [mem 0xdf200000-0xf7ffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel with PVH extensions on Xen
[    0.000000] Xen version: 4.5.0-rc-lK
[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 30 pages/cpu @ffff880408c00000 s84416 r8192 d30272 u262144
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 3988686
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root console=hvc0 console=tty0
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340 using standard form
[    0.000000] software IO TLB [mem 0x3f4c00000-0x3f8c00000] (64MB) mapped at [ffff8803f4c00000-ffff8803f8bfffff]
[    0.000000] Memory: 15802608K/16208092K available (7645K kernel code, 1209K rwdata, 3256K rodata, 1480K init, 1476K bss, 405484K reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] NR_IRQS:4352 nr_irqs:488 0
[    0.000000] xen:events: Using 2-level ABI
[    0.000000] xen: sci override: global_irq=9 trigger=0 polarity=0
[    0.000000] xen: acpi sci 9
[    0.000000] xen map irq failed -12
[    0.000000] xen map irq failed -12
[    0.000000] xen map irq failed -12
[    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled
[    0.000000] 	Offload RCU callbacks from all CPUs
[    0.000000] 	Offload RCU callbacks from CPUs: 0-7.
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] console [hvc0] enabled
[    0.000000] allocated 65536000 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[    0.000000] installing Xen timer for CPU 0
[    0.000000] tsc: Detected 3392.258 MHz processor
[    8.712301] Calibrating delay loop (skipped), value calculated using timer frequency.. 6784.51 BogoMIPS (lpj=3392258)
[    8.712315] pid_max: default: 32768 minimum: 301
[    8.712327] ACPI: Core revision 20140926
[    8.727587] ACPI: All ACPI Tables successfully acquired
[    8.729155] Security Framework initialized
[    8.729166] SELinux:  Initializing.
[    8.729937] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes)
[    8.732172] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[    8.733059] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes)
[    8.733083] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes)
[    8.733337] Initializing cgroup subsys memory
[    8.733349] Initializing cgroup subsys devices
[    8.733357] Initializing cgroup subsys freezer
[    8.733363] Initializing cgroup subsys net_cls
[    8.733384] Initializing cgroup subsys blkio
[    8.733391] Initializing cgroup subsys perf_event
[    8.733399] Initializing cgroup subsys net_prio
[    8.733406] Initializing cgroup subsys hugetlb
[    8.733456] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[    8.733456] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[    8.733473] CPU: Physical Processor ID: 0
[    8.733478] CPU: Processor Core ID: 0
[    8.734203] mce: CPU supports 2 MCE banks
[    8.734220] Last level iTLB entries: 4KB 1024, 2MB 1024, 4MB 1024
[    8.734220] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 1024, 1GB 4
[    8.734479] Freeing SMP alternatives memory: 32K (ffffffff81ea2000 - ffffffff81eaa000)
[    8.736948] Ignoring BGRT: invalid status 0 (expected 1)
[    8.736955] ftrace: allocating 27387 entries in 107 pages
[    8.755651] cpu 0 spinlock event irq 25
[    8.760281] Performance Events: unsupported p6 CPU model 60 no PMU driver, software events only.
[    8.761247] NMI watchdog: disabled (cpu0): hardware events not enabled
[    8.761307] installing Xen timer for CPU 1
[    8.761324] cpu 1 spinlock event irq 32
[    8.761336] ------------[ cut here ]------------
[    8.761342] kernel BUG at arch/x86/xen/smp.c:438!
[    8.761348] invalid opcode: 0000 [#1] SMP 
[    8.761355] Modules linked in:
[    8.761362] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0 #1
[    8.761369] Hardware name: LENOVO 10A6S09R01/SHARKBAY, BIOS FBKTA1AUS 10/22/2014
[    8.761377] task: ffff8803ef058000 ti: ffff8803ef060000 task.ti: ffff8803ef060000
[    8.761386] RIP: 0010:[<ffffffff810114c5>]  [<ffffffff810114c5>] xen_cpu_up+0x4c5/0x4d0
[    8.761396] RSP: 0000:ffff8803ef063dd8  EFLAGS: 00010282
[    8.761402] RAX: fffffffffffffff4 RBX: 0000000000000001 RCX: 0000000000000001
[    8.761410] RDX: ffff8803ef7ba000 RSI: 0000000000000001 RDI: 0000000000000000
[    8.761418] RBP: ffff8803ef063e18 R08: 0000000000016b80 R09: ffff880408803200
[    8.761426] R10: ffffffff810110cb R11: 00000000000000f7 R12: 0000000000000001
[    8.761434] R13: 000000000000cda0 R14: ffff8803ef05f080 R15: ffff8803ef7ba000
[    8.761443] FS:  0000000000000000(0000) GS:ffff880408c00000(0000) knlGS:0000000000000000
[    8.761451] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    8.761458] CR2: 0000000000000000 CR3: 0000000001c11000 CR4: 00000000000406f0
[    8.761467] Stack:
[    8.761470]  0000000000000001 0000000000000000 0000000000000001 0000000000000000
[    8.761482]  0000000000000001 0000000000000001 0000000000000000 ffff8803ef05f080
[    8.761495]  ffff8803ef063e68 ffffffff810997dc 0000001500000007 00000000498d3401
[    8.761507] Call Trace:
[    8.761513]  [<ffffffff810997dc>] _cpu_up+0x15c/0x1a0
[    8.761520]  [<ffffffff810998aa>] cpu_up+0x8a/0xb0
[    8.761526]  [<ffffffff81d6abf2>] smp_init+0x66/0x81
[    8.761533]  [<ffffffff81d46166>] kernel_init_freeable+0x137/0x25d
[    8.761542]  [<ffffffff81760320>] ? rest_init+0x80/0x80
[    8.761549]  [<ffffffff8176032e>] kernel_init+0xe/0xf0
[    8.761556]  [<ffffffff8177237c>] ret_from_fork+0x7c/0xb0
[    8.761563]  [<ffffffff81760320>] ? rest_init+0x80/0x80
[    8.761569] Code: 9c ff ff 48 ba 00 00 00 00 00 00 00 40 48 0b 55 c0 48 bf 00 f0 ff ff ff 87 ff ff 48 39 d0 0f 85 4f fe ff ff e9 35 fe ff ff 0f 0b <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 81 fe fb 00 
[    8.761675] RIP  [<ffffffff810114c5>] xen_cpu_up+0x4c5/0x4d0
[    8.761683]  RSP <ffff8803ef063dd8>
[    8.761695] ---[ end trace 802ba5db34514b28 ]---
[    8.761706] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    8.761706] 
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 21:28:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 21: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 1Xy5qP-0003xf-E1; Mon, 08 Dec 2014 21:27: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 1Xy5qN-0003xa-Jr
	for xen-devel@lists.xensource.com; Mon, 08 Dec 2014 21:27:47 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	C0/D5-17958-2D716845; Mon, 08 Dec 2014 21:27:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418074064!11818021!1
X-Originating-IP: [156.151.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 22811 invoked from network); 8 Dec 2014 21:27:45 -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; 8 Dec 2014 21:27: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 sB8LRgWu027927
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 8 Dec 2014 21:27:43 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
	sB8LRf0Q010826
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 8 Dec 2014 21:27:42 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
	sB8LRfgs005671
	for <xen-devel@lists.xensource.com>; Mon, 8 Dec 2014 21:27:41 GMT
Received: from laptop.dumpdata.com (/10.137.177.176)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 13:27:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0AE83122350; Mon,  8 Dec 2014 16:27:40 -0500 (EST)
Date: Mon, 8 Dec 2014 16:27:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20141208212739.GA7226@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]
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Subject: [Xen-devel] Xen  4.5.0rc3 + Linux v3.18 + dom0pvh=1 = BOOM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 what I get with Xen 4.5.0-rc3. I hadn't yet dug in the
details except that I thought the v3.18 had the correct
fix for PVH (It sure looks to have it).

Cc-ing Elena as she has a similar issue.

 Xen 4.5.0-rc-lK
(XEN) Xen version 4.5.0-rc-lK (konrad@oracle.com) (gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)) debug=y Mon Dec  8 16:00:18 EST 2014
(XEN) Latest ChangeSet: Mon Dec 8 15:52:40 2014 -0500 git:82b9031
(XEN) Bootloader: EFI
(XEN) Command line: console=vga,com1 com1=115200,8n1 loglvl=all iommu=verbose guest_loglvl=all dom0pvh=1
(XEN) Video information:
(XEN)  VGA is graphics mode 1920x1080, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) EFI RAM map:
(XEN)  0000000000000000 - 0000000000058000 (usable)
(XEN)  0000000000058000 - 0000000000059000 (reserved)
(XEN)  0000000000059000 - 000000000009f000 (usable)
(XEN)  000000000009f000 - 00000000000a0000 (reserved)
(XEN)  0000000000100000 - 00000000c2dcb000 (usable)
(XEN)  00000000c2dcb000 - 00000000c2dd2000 (ACPI NVS)
(XEN)  00000000c2dd2000 - 00000000c321a000 (usable)
(XEN)  00000000c321a000 - 00000000c36bc000 (reserved)
(XEN)  00000000c36bc000 - 00000000d48ed000 (usable)
(XEN)  00000000d48ed000 - 00000000d4979000 (reserved)
(XEN)  00000000d4979000 - 00000000d49db000 (ACPI data)
(XEN)  00000000d49db000 - 00000000d56f4000 (ACPI NVS)
(XEN)  00000000d56f4000 - 00000000d5fff000 (reserved)
(XEN)  00000000d5fff000 - 00000000d6000000 (usable)
(XEN)  00000000d7000000 - 00000000df200000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed00000 - 00000000fed04000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000041ee00000 (usable)
(XEN) ACPI: RSDP D498C000, 0024 (r2 LENOVO)
(XEN) ACPI: XSDT D498C098, 00AC (r1 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: FACP D49A3980, 010C (r5 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: DSDT D498C1D0, 177B0 (r2 LENOVO TC-FB        1A10 INTL 20120711)
(XEN) ACPI: FACS D56F2F80, 0040
(XEN) ACPI: APIC D49A3A90, 0092 (r3 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: FPDT D49A3B28, 0044 (r1 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: FIDT D49A3B70, 009C (r1 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: TCPA D49A3C10, 0032 (r2 LENOVO TC-FB        1A10 MSFT  1000013)
(XEN) ACPI: SLIC D49A3C48, 0176 (r1 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: MSDM D49A3DC0, 0055 (r3 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: SSDT D49A3E18, 0539 (r1 LENOVO TC-FB        1A10 INTL 20120711)
(XEN) ACPI: SSDT D49A4358, 0AD8 (r1 LENOVO TC-FB        1A10 INTL 20120711)
(XEN) ACPI: MCFG D49A4E30, 003C (r1 LENOVO TC-FB        1A10 MSFT       97)
(XEN) ACPI: HPET D49A4E70, 0038 (r1 LENOVO TC-FB        1A10 AMI.        5)
(XEN) ACPI: SSDT D49A4EA8, 036D (r1 LENOVO TC-FB        1A10 INTL 20120711)
(XEN) ACPI: SSDT D49A5218, 3528 (r1 LENOVO TC-FB        1A10 INTL 20091112)
(XEN) ACPI: ASF! D49A8740, 00A5 (r32 LENOVO TC-FB        1A10 TFSM    F4240)
(XEN) ACPI: BGRT D49A87E8, 0038 (r0 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: LUFT D49A8820, 32000 (r1 LENOVO TC-FB        1A10 AMI     10013)
(XEN) ACPI: DMAR D49DA820, 00B8 (r1 LENOVO TC-FB        1A10 INTL        1)
(XEN) System RAM: 16177MB (16566156kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000041ee00000
(XEN) Domain heap initialised
(XEN) vesafb: framebuffer at 0xe0000000, mapped to 0xffff82c000201000, using 8128k, total 8128k
(XEN) vesafb: mode is 1920x1080x32, linelength=7680, font 8x16
(XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
(XEN) Couldn't initialize a 1920x1080 framebuffer early.
(XEN) SMBIOS 2.8 present.
(XEN) DMI 2.7 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1808
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1804,1:0], pm1x_evt[1:1800,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - d56f2f80/0000000000000000, using 32
(XEN) ACPI:             wakeup_vec[d56f2f8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)
(XEN) Processor #1 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)
(XEN) Processor #3 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)
(XEN) Processor #5 7:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
(XEN) Processor #7 7:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) [VT-D]dmar.c:788: Host address width 39
(XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:472:   dmaru->address = fed90000
(XEN) [VT-D]iommu.c:1146: drhd->address = fed90000 iommu->reg = ffff82c0009f2000
(XEN) [VT-D]iommu.c:1148: cap = c0000020660462 ecap = f0101a
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:02.0
(XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:472:   dmaru->address = fed91000
(XEN) [VT-D]iommu.c:1146: drhd->address = fed91000 iommu->reg = ffff82c0009f4000
(XEN) [VT-D]iommu.c:1148: cap = d2008020660462 ecap = f010da
(XEN) [VT-D]dmar.c:397:  IOAPIC: 0000:f0:1f.0
(XEN) [VT-D]dmar.c:361:  MSI HPET: 0000:f0:0f.0
(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:1d.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:14.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr d5e6b000 end_address d5e91fff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:02.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr d7000000 end_address df1fffff
(XEN) ERST table was not found
(XEN) ACPI: BGRT: invalidating v1 image at 0xc8809018
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 1528 MSI/MSI-X
(XEN) Switched to APIC driver x2apic_cluster.
(XEN) XSM Framework v1.0.0 initialized
(XEN) Flask:  Initializing.
(XEN) AVC INITIALIZED
(XEN) Flask:  Starting in permissive mode.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3392.259 MHz processor.
(XEN) EFI memory map:
(XEN)  0000000000000-0000000007fff type=3 attr=000000000000000f
(XEN)  0000000008000-0000000057fff type=7 attr=000000000000000f
(XEN)  0000000058000-0000000058fff type=0 attr=000000000000000f
(XEN)  0000000059000-000000005bfff type=7 attr=000000000000000f
(XEN)  000000005c000-000000005efff type=2 attr=000000000000000f
(XEN)  000000005f000-000000005ffff type=4 attr=000000000000000f
(XEN)  0000000060000-000000009efff type=3 attr=000000000000000f
(XEN)  000000009f000-000000009ffff type=0 attr=000000000000000f
(XEN)  0000000100000-00000007fffff type=7 attr=000000000000000f
(XEN)  0000000800000-00000008fffff type=4 attr=000000000000000f
(XEN)  0000000900000-00000bd5fbfff type=7 attr=000000000000000f
(XEN)  00000bd5fc000-00000bf7d8fff type=2 attr=000000000000000f
(XEN)  00000bf7d9000-00000c163efff type=7 attr=000000000000000f
(XEN)  00000c163f000-00000c1bcafff type=2 attr=000000000000000f
(XEN)  00000c1bcb000-00000c2dcafff type=1 attr=000000000000000f
(XEN)  00000c2dcb000-00000c2dd1fff type=10 attr=000000000000000f
(XEN)  00000c2dd2000-00000c2f25fff type=4 attr=000000000000000f
(XEN)  00000c2f26000-00000c31cdfff type=3 attr=000000000000000f
(XEN)  00000c31ce000-00000c31d8fff type=4 attr=000000000000000f
(XEN)  00000c31d9000-00000c31e0fff type=3 attr=000000000000000f
(XEN)  00000c31e1000-00000c31e2fff type=4 attr=000000000000000f
(XEN)  00000c31e3000-00000c31e6fff type=3 attr=000000000000000f
(XEN)  00000c31e7000-00000c31fbfff type=4 attr=000000000000000f
(XEN)  00000c31fc000-00000c320dfff type=3 attr=000000000000000f
(XEN)  00000c320e000-00000c3219fff type=4 attr=000000000000000f
(XEN)  00000c321a000-00000c36bbfff type=6 attr=800000000000000f
(XEN)  00000c36bc000-00000c36c8fff type=4 attr=000000000000000f
(XEN)  00000c36c9000-00000c6e8dfff type=7 attr=000000000000000f
(XEN)  00000c6e8e000-00000c84e8fff type=4 attr=000000000000000f
(XEN)  00000c84e9000-00000c84eefff type=7 attr=000000000000000f
(XEN)  00000c84ef000-00000c8977fff type=4 attr=000000000000000f
(XEN)  00000c8978000-00000c897afff type=7 attr=000000000000000f
(XEN)  00000c897b000-00000d3eb0fff type=4 attr=000000000000000f
(XEN)  00000d3eb1000-00000d43d3fff type=7 attr=000000000000000f
(XEN)  00000d43d4000-00000d48ecfff type=3 attr=000000000000000f
(XEN)  00000d48ed000-00000d490afff type=0 attr=000000000000000f
(XEN)  00000d490b000-00000d4978fff type=0 attr=000000000000000f
(XEN)  00000d4979000-00000d498bfff type=9 attr=000000000000000f
(XEN)  00000d498c000-00000d49dafff type=9 attr=000000000000000f
(XEN)  00000d49db000-00000d4c7ffff type=10 attr=000000000000000f
(XEN)  00000d4c80000-00000d56f3fff type=10 attr=000000000000000f
(XEN)  00000d56f4000-00000d5d23fff type=6 attr=800000000000000f
(XEN)  00000d5d24000-00000d5ebffff type=6 attr=800000000000000f
(XEN)  00000d5ec0000-00000d5ec1fff type=6 attr=800000000000000f
(XEN)  00000d5ec2000-00000d5f61fff type=6 attr=800000000000000f
(XEN)  00000d5f62000-00000d5f80fff type=5 attr=800000000000000f
(XEN)  00000d5f81000-00000d5ffefff type=5 attr=800000000000000f
(XEN)  00000d5fff000-00000d5ffffff type=4 attr=000000000000000f
(XEN)  0000100000000-000041edfffff type=7 attr=000000000000000f
(XEN)  00000d7000000-00000df1fffff type=0 attr=0000000000000000
(XEN)  00000f8000000-00000fbffffff type=11 attr=8000000000000001
(XEN)  00000fec00000-00000fec00fff type=11 attr=8000000000000001
(XEN)  00000fed00000-00000fed03fff type=11 attr=8000000000000001
(XEN)  00000fed1c000-00000fed1ffff type=11 attr=8000000000000001
(XEN)  00000fee00000-00000fee00fff type=11 attr=8000000000000001
(XEN)  00000ff000000-00000ffffffff type=11 attr=8000000000000001
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(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 ffff82d080446dd0 -> ffff82d080447e20
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB.
(XEN) Intel VT-d iommu 1 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 enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
(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=0 pin2=0
(XEN) TSC deadline timer enabled
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 64 KiB.
(XEN) mwait-idle: MWAIT substates: 0x42120
(XEN) mwait-idle: v0.4 model 0x3c
(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)  - VMCS shadowing
(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 8 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=0xb2e000
(XEN) elf_parse_binary: phdr: paddr=0x1c00000 memsz=0x130000
(XEN) elf_parse_binary: phdr: paddr=0x1d30000 memsz=0x149c0
(XEN) elf_parse_binary: phdr: paddr=0x1d45000 memsz=0x537000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x227c000
(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 = 0xffffffff81d451f0
(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: MOD_START_PFN = 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        = 0xffffffff8227c000
(XEN)     virt_entry       = 0xffffffff81d451f0
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x227c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000400000000->0000000408000000 (4010843 pages to be allocated)
(XEN)  Init. ramdisk: 000000041cd23000->000000041edfffcb
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff8227c000
(XEN)  Init. ramdisk: 0000000000000000->0000000000000000
(XEN)  Phys-Mach map: ffffffff8227c000->ffffffff841661c0
(XEN)  Start info:    ffffffff84167000->ffffffff841684b4
(XEN)  Page tables:   ffffffff84169000->ffffffff8418e000
(XEN)  Boot stack:    ffffffff8418e000->ffffffff8418f000
(XEN)  TOTAL:         ffffffff80000000->ffffffff84400000
(XEN)  ENTRY ADDRESS: ffffffff81d451f0
(XEN) Dom0 has maximum 8 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff81b2e000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81c00000 -> 0xffffffff81d30000
(XEN) elf_load_binary: phdr 2 at 0xffffffff81d30000 -> 0xffffffff81d449c0
(XEN) elf_load_binary: phdr 3 at 0xffffffff81d45000 -> 0xffffffff81eab000
(XEN) [VT-D]iommu.c:1430: d0:Hostbridge: skip 0000:00:00.0 map
(XEN) Bogus DMIBAR 0xfed18001 on 0000:00:00.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:02.0
(XEN) [VT-D]iommu.c:1444: d0:PCIe: map 0000:00:03.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:14.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:16.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:16.3
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:19.0
(XEN) [VT-D]iommu.c:1456: d0:PCI: map 0000:00:1a.0
(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: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:2105: IOMMU: mapping reserved region failed
(XEN) [VT-D]iommu.c:739: iommu_enable_translation: iommu->reg = ffff82c0009f2000
(XEN) [VT-D]iommu.c:739: iommu_enable_translation: iommu->reg = ffff82c0009f4000
(XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs
(XEN) .................................done.
(XEN) Initial low memory virq threshold set at 0x1 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 316kB init memory.
mapping kernel into physical memory
about to get started...
(XEN) irq.c:380: Dom0 callback via changed to Direct Vector 0xf3
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.18.0 (konrad@localhost.localdomain) (gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC) ) #1 SMP Mon Dec 8 15:01:03 EST 2014
[    0.000000] Command line: root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root console=hvc0 console=tty0
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x0000000000057fff] usable
[    0.000000] Xen: [mem 0x0000000000058000-0x0000000000058fff] reserved
[    0.000000] Xen: [mem 0x0000000000059000-0x000000000009efff] usable
[    0.000000] Xen: [mem 0x000000000009f000-0x000000000009ffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000c2dcafff] usable
[    0.000000] Xen: [mem 0x00000000c2dcb000-0x00000000c2dd1fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000c2dd2000-0x00000000c3219fff] usable
[    0.000000] Xen: [mem 0x00000000c321a000-0x00000000c36bbfff] reserved
[    0.000000] Xen: [mem 0x00000000c36bc000-0x00000000d48ecfff] usable
[    0.000000] Xen: [mem 0x00000000d48ed000-0x00000000d4978fff] reserved
[    0.000000] Xen: [mem 0x00000000d4979000-0x00000000d49dafff] ACPI data
[    0.000000] Xen: [mem 0x00000000d49db000-0x00000000d56f3fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000d56f4000-0x00000000d5ffefff] reserved
[    0.000000] Xen: [mem 0x00000000d5fff000-0x00000000d5ffffff] usable
[    0.000000] Xen: [mem 0x00000000d7000000-0x00000000df1fffff] reserved
[    0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fed00000-0x00000000fed03fff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000409054fff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] efi: EFI v2.31 by American Megatrends
[    0.000000] efi:  ACPI=0xd498c000  ACPI 2.0=0xd498c000  SMBIOS=0xf0480  MPS=0xfca90 
[    0.000000] SMBIOS 2.8 present.
[    0.000000] e820: last_pfn = 0x409055 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xd6000 max_arch_pfn = 0x400000000
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000] init_memory_mapping: [mem 0x408e00000-0x408ffffff]
[    0.000000] init_memory_mapping: [mem 0x408000000-0x408dfffff]
[    0.000000] init_memory_mapping: [mem 0x400000000-0x407ffffff]
[    0.000000] init_memory_mapping: [mem 0x00100000-0xc2dcafff]
[    0.000000] init_memory_mapping: [mem 0xc2dd2000-0xc3219fff]
[    0.000000] init_memory_mapping: [mem 0xc36bc000-0xd48ecfff]
[    0.000000] init_memory_mapping: [mem 0xd5fff000-0xd5ffffff]
[    0.000000] init_memory_mapping: [mem 0x100000000-0x3ffffffff]
[    0.000000] init_memory_mapping: [mem 0x409000000-0x409054fff]
[    0.000000] RAMDISK: [mem 0x08000000-0x0a0dcfff]
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000D498C000 000024 (v02 LENOVO)
[    0.000000] ACPI: XSDT 0x00000000D498C098 0000AC (v01 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: FACP 0x00000000D49A3980 00010C (v05 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: DSDT 0x00000000D498C1D0 0177B0 (v02 LENOVO TC-FB    00001A10 INTL 20120711)
[    0.000000] ACPI: FACS 0x00000000D56F2F80 000040
[    0.000000] ACPI: APIC 0x00000000D49A3A90 000092 (v03 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: FPDT 0x00000000D49A3B28 000044 (v01 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: FIDT 0x00000000D49A3B70 00009C (v01 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: TCPA 0x00000000D49A3C10 000032 (v02 LENOVO TC-FB    00001A10 MSFT 01000013)
[    0.000000] ACPI: SLIC 0x00000000D49A3C48 000176 (v01 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: MSDM 0x00000000D49A3DC0 000055 (v03 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: SSDT 0x00000000D49A3E18 000539 (v01 LENOVO TC-FB    00001A10 INTL 20120711)
[    0.000000] ACPI: SSDT 0x00000000D49A4358 000AD8 (v01 LENOVO TC-FB    00001A10 INTL 20120711)
[    0.000000] ACPI: MCFG 0x00000000D49A4E30 00003C (v01 LENOVO TC-FB    00001A10 MSFT 00000097)
[    0.000000] ACPI: HPET 0x00000000D49A4E70 000038 (v01 LENOVO TC-FB    00001A10 AMI. 00000005)
[    0.000000] ACPI: SSDT 0x00000000D49A4EA8 00036D (v01 LENOVO TC-FB    00001A10 INTL 20120711)
[    0.000000] ACPI: SSDT 0x00000000D49A5218 003528 (v01 LENOVO TC-FB    00001A10 INTL 20091112)
[    0.000000] ACPI: ASF! 0x00000000D49A8740 0000A5 (v32 LENOVO TC-FB    00001A10 TFSM 000F4240)
[    0.000000] ACPI: BGRT 0x00000000D49A87E8 000038 (v00 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: LUFT 0x00000000D49A8820 032000 (v01 LENOVO TC-FB    00001A10 AMI  00010013)
[    0.000000] ACPI: XMAR 0x00000000D49DA820 0000B8 (v01 LENOVO TC-FB    00001A10 INTL 00000001)
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x0000000409054fff]
[    0.000000] NODE_DATA(0) allocated [mem 0x409041000-0x409054fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x409054fff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x00057fff]
[    0.000000]   node   0: [mem 0x00059000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0xc2dcafff]
[    0.000000]   node   0: [mem 0xc2dd2000-0xc3219fff]
[    0.000000]   node   0: [mem 0xc36bc000-0xd48ecfff]
[    0.000000]   node   0: [mem 0xd5fff000-0xd5ffffff]
[    0.000000]   node   0: [mem 0x100000000-0x409054fff]
[    0.000000] Initmem setup node 0 [mem 0x00001000-0x409054fff]
[    0.000000] Reserving Intel graphics stolen memory at 0xd7200000-0xdf1fffff
[    0.000000] ACPI: PM-Timer IO Port: 0x1808
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 8 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[    0.000000] PM: Registered nosave memory: [mem 0x00058000-0x00058fff]
[    0.000000] PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
[    0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000fffff]
[    0.000000] PM: Registered nosave memory: [mem 0xc2dcb000-0xc2dd1fff]
[    0.000000] PM: Registered nosave memory: [mem 0xc321a000-0xc36bbfff]
[    0.000000] PM: Registered nosave memory: [mem 0xd48ed000-0xd4978fff]
[    0.000000] PM: Registered nosave memory: [mem 0xd4979000-0xd49dafff]
[    0.000000] PM: Registered nosave memory: [mem 0xd49db000-0xd56f3fff]
[    0.000000] PM: Registered nosave memory: [mem 0xd56f4000-0xd5ffefff]
[    0.000000] PM: Registered nosave memory: [mem 0xd6000000-0xd6ffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xd7000000-0xdf1fffff]
[    0.000000] PM: Registered nosave memory: [mem 0xdf200000-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-0xfec00fff]
[    0.000000] PM: Registered nosave memory: [mem 0xfec01000-0xfecfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfed00000-0xfed03fff]
[    0.000000] PM: Registered nosave memory: [mem 0xfed04000-0xfed1bfff]
[    0.000000] PM: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfed20000-0xfedfffff]
[    0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfee00fff]
[    0.000000] PM: Registered nosave memory: [mem 0xfee01000-0xfeffffff]
[    0.000000] PM: Registered nosave memory: [mem 0xff000000-0xffffffff]
[    0.000000] e820: [mem 0xdf200000-0xf7ffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel with PVH extensions on Xen
[    0.000000] Xen version: 4.5.0-rc-lK
[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 30 pages/cpu @ffff880408c00000 s84416 r8192 d30272 u262144
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 3988686
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root console=hvc0 console=tty0
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340 using standard form
[    0.000000] software IO TLB [mem 0x3f4c00000-0x3f8c00000] (64MB) mapped at [ffff8803f4c00000-ffff8803f8bfffff]
[    0.000000] Memory: 15802608K/16208092K available (7645K kernel code, 1209K rwdata, 3256K rodata, 1480K init, 1476K bss, 405484K reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] NR_IRQS:4352 nr_irqs:488 0
[    0.000000] xen:events: Using 2-level ABI
[    0.000000] xen: sci override: global_irq=9 trigger=0 polarity=0
[    0.000000] xen: acpi sci 9
[    0.000000] xen map irq failed -12
[    0.000000] xen map irq failed -12
[    0.000000] xen map irq failed -12
[    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled
[    0.000000] 	Offload RCU callbacks from all CPUs
[    0.000000] 	Offload RCU callbacks from CPUs: 0-7.
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] console [hvc0] enabled
[    0.000000] allocated 65536000 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[    0.000000] installing Xen timer for CPU 0
[    0.000000] tsc: Detected 3392.258 MHz processor
[    8.712301] Calibrating delay loop (skipped), value calculated using timer frequency.. 6784.51 BogoMIPS (lpj=3392258)
[    8.712315] pid_max: default: 32768 minimum: 301
[    8.712327] ACPI: Core revision 20140926
[    8.727587] ACPI: All ACPI Tables successfully acquired
[    8.729155] Security Framework initialized
[    8.729166] SELinux:  Initializing.
[    8.729937] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes)
[    8.732172] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[    8.733059] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes)
[    8.733083] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes)
[    8.733337] Initializing cgroup subsys memory
[    8.733349] Initializing cgroup subsys devices
[    8.733357] Initializing cgroup subsys freezer
[    8.733363] Initializing cgroup subsys net_cls
[    8.733384] Initializing cgroup subsys blkio
[    8.733391] Initializing cgroup subsys perf_event
[    8.733399] Initializing cgroup subsys net_prio
[    8.733406] Initializing cgroup subsys hugetlb
[    8.733456] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[    8.733456] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[    8.733473] CPU: Physical Processor ID: 0
[    8.733478] CPU: Processor Core ID: 0
[    8.734203] mce: CPU supports 2 MCE banks
[    8.734220] Last level iTLB entries: 4KB 1024, 2MB 1024, 4MB 1024
[    8.734220] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 1024, 1GB 4
[    8.734479] Freeing SMP alternatives memory: 32K (ffffffff81ea2000 - ffffffff81eaa000)
[    8.736948] Ignoring BGRT: invalid status 0 (expected 1)
[    8.736955] ftrace: allocating 27387 entries in 107 pages
[    8.755651] cpu 0 spinlock event irq 25
[    8.760281] Performance Events: unsupported p6 CPU model 60 no PMU driver, software events only.
[    8.761247] NMI watchdog: disabled (cpu0): hardware events not enabled
[    8.761307] installing Xen timer for CPU 1
[    8.761324] cpu 1 spinlock event irq 32
[    8.761336] ------------[ cut here ]------------
[    8.761342] kernel BUG at arch/x86/xen/smp.c:438!
[    8.761348] invalid opcode: 0000 [#1] SMP 
[    8.761355] Modules linked in:
[    8.761362] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0 #1
[    8.761369] Hardware name: LENOVO 10A6S09R01/SHARKBAY, BIOS FBKTA1AUS 10/22/2014
[    8.761377] task: ffff8803ef058000 ti: ffff8803ef060000 task.ti: ffff8803ef060000
[    8.761386] RIP: 0010:[<ffffffff810114c5>]  [<ffffffff810114c5>] xen_cpu_up+0x4c5/0x4d0
[    8.761396] RSP: 0000:ffff8803ef063dd8  EFLAGS: 00010282
[    8.761402] RAX: fffffffffffffff4 RBX: 0000000000000001 RCX: 0000000000000001
[    8.761410] RDX: ffff8803ef7ba000 RSI: 0000000000000001 RDI: 0000000000000000
[    8.761418] RBP: ffff8803ef063e18 R08: 0000000000016b80 R09: ffff880408803200
[    8.761426] R10: ffffffff810110cb R11: 00000000000000f7 R12: 0000000000000001
[    8.761434] R13: 000000000000cda0 R14: ffff8803ef05f080 R15: ffff8803ef7ba000
[    8.761443] FS:  0000000000000000(0000) GS:ffff880408c00000(0000) knlGS:0000000000000000
[    8.761451] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    8.761458] CR2: 0000000000000000 CR3: 0000000001c11000 CR4: 00000000000406f0
[    8.761467] Stack:
[    8.761470]  0000000000000001 0000000000000000 0000000000000001 0000000000000000
[    8.761482]  0000000000000001 0000000000000001 0000000000000000 ffff8803ef05f080
[    8.761495]  ffff8803ef063e68 ffffffff810997dc 0000001500000007 00000000498d3401
[    8.761507] Call Trace:
[    8.761513]  [<ffffffff810997dc>] _cpu_up+0x15c/0x1a0
[    8.761520]  [<ffffffff810998aa>] cpu_up+0x8a/0xb0
[    8.761526]  [<ffffffff81d6abf2>] smp_init+0x66/0x81
[    8.761533]  [<ffffffff81d46166>] kernel_init_freeable+0x137/0x25d
[    8.761542]  [<ffffffff81760320>] ? rest_init+0x80/0x80
[    8.761549]  [<ffffffff8176032e>] kernel_init+0xe/0xf0
[    8.761556]  [<ffffffff8177237c>] ret_from_fork+0x7c/0xb0
[    8.761563]  [<ffffffff81760320>] ? rest_init+0x80/0x80
[    8.761569] Code: 9c ff ff 48 ba 00 00 00 00 00 00 00 40 48 0b 55 c0 48 bf 00 f0 ff ff ff 87 ff ff 48 39 d0 0f 85 4f fe ff ff e9 35 fe ff ff 0f 0b <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 81 fe fb 00 
[    8.761675] RIP  [<ffffffff810114c5>] xen_cpu_up+0x4c5/0x4d0
[    8.761683]  RSP <ffff8803ef063dd8>
[    8.761695] ---[ end trace 802ba5db34514b28 ]---
[    8.761706] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    8.761706] 
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 08 22:13:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 22: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 1Xy6YF-0005KL-Ee; Mon, 08 Dec 2014 22:13:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xy6YE-0005KG-4I
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 22:13:06 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	74/DD-27785-17226845; Mon, 08 Dec 2014 22:13:05 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418076783!13783361!1
X-Originating-IP: [156.151.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 29215 invoked from network); 8 Dec 2014 22:13:04 -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; 8 Dec 2014 22:13: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 sB8MChf5013186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 22:12: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
	sB8MCf00011091
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 22:12:42 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
	sB8MCeYP011214; Mon, 8 Dec 2014 22:12:41 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 14:12:40 -0800
Date: Mon, 8 Dec 2014 14:12:39 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20141208141239.409fbeda@mantra.us.oracle.com>
In-Reply-To: <54857995020000780004DA2D@mail.emea.novell.com>
References: <54857995020000780004DA2D@mail.emea.novell.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
	handle_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAwOCBEZWMgMjAxNCAwOToxMjozNyArMDAwMAoiSmFuIEJldWxpY2giIDxKQmV1bGlj
aEBzdXNlLmNvbT4gd3JvdGU6Cgo+IFBWSCBndWVzdHMgYWNjZXNzaW5nIEkvTyBwb3J0cyB2aWEg
c3RyaW5nIG9wcyBpcyBub3Qgc3VwcG9ydGVkIHlldC4KPiAKPiBSZXBvcnRlZC1ieTogUm9nZXIg
UGF1IE1vbm7DqTxyb2dlci5wYXVAY2l0cml4LmNvbT4KPiBTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+Cj4gLS0tCj4gdjI6IGhhbmRsZV9waW8oKSBpcyBhbHJl
YWR5IHNhZmUgKHBvaW50ZWQgb3V0IGJ5IE11a2VzaCksIHNvIG9ubHkKPiByZWZ1c2UgZW50ZXJp
bmcgaGFuZGxlX21taW8oKS4KPiBOb3RlOiBPbmx5IGNvbXBpbGUgdGVzdGVkIHNvIGZhci4KPiAK
PiAtLS0gdW5zdGFibGUub3JpZy94ZW4vYXJjaC94ODYvaHZtL3ZteC92bXguYwkyMDE0LTExLTI3
Cj4gMDk6Mzc6MjcuMDAwMDAwMDAwICswMTAwICsrKwo+IHVuc3RhYmxlL3hlbi9hcmNoL3g4Ni9o
dm0vdm14L3ZteC5jCTIwMTQtMTItMDgKPiAxMDowNDoyNy4wMDAwMDAwMDAgKzAxMDAgQEAgLTMw
ODYsNyArMzA4Niw4IEBAIHZvaWQKPiB2bXhfdm1leGl0X2hhbmRsZXIoc3RydWN0IGNwdV91c2Vy
XyBpZiAoIGV4aXRfcXVhbGlmaWNhdGlvbiAmIDB4MTAgKSB7Cj4gICAgICAgICAgICAgIC8qIElO
UywgT1VUUyAqLwo+IC0gICAgICAgICAgICBpZiAoICFoYW5kbGVfbW1pbygpICkKPiArICAgICAg
ICAgICAgaWYgKCB1bmxpa2VseShpc19wdmhfdmNwdSh2KSkgLyogUFZIIGZpeG1lICovIHx8Cj4g
KyAgICAgICAgICAgICAgICAgIWhhbmRsZV9tbWlvKCkgKQo+ICAgICAgICAgICAgICAgICAgaHZt
X2luamVjdF9od19leGNlcHRpb24oVFJBUF9ncF9mYXVsdCwgMCk7Cj4gICAgICAgICAgfQo+ICAg
ICAgICAgIGVsc2UKPiAKCkdvb2QgaWRlYSwgYW5kIGlmIG5lZWRlZDoKCkFja2VkLWJ5OiBNdWtl
c2ggUmF0aG9yIDxtdWtlc2gucmF0aG9yQG9yYWNsZS5jb20+CgoKdGhhbmtzCk11a2VzaAoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 22:13:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 22: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 1Xy6YF-0005KL-Ee; Mon, 08 Dec 2014 22:13:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xy6YE-0005KG-4I
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 22:13:06 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	74/DD-27785-17226845; Mon, 08 Dec 2014 22:13:05 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418076783!13783361!1
X-Originating-IP: [156.151.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 29215 invoked from network); 8 Dec 2014 22:13:04 -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; 8 Dec 2014 22:13: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 sB8MChf5013186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Dec 2014 22:12: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
	sB8MCf00011091
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 8 Dec 2014 22:12:42 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
	sB8MCeYP011214; Mon, 8 Dec 2014 22:12:41 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Dec 2014 14:12:40 -0800
Date: Mon, 8 Dec 2014 14:12:39 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20141208141239.409fbeda@mantra.us.oracle.com>
In-Reply-To: <54857995020000780004DA2D@mail.emea.novell.com>
References: <54857995020000780004DA2D@mail.emea.novell.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
	handle_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAwOCBEZWMgMjAxNCAwOToxMjozNyArMDAwMAoiSmFuIEJldWxpY2giIDxKQmV1bGlj
aEBzdXNlLmNvbT4gd3JvdGU6Cgo+IFBWSCBndWVzdHMgYWNjZXNzaW5nIEkvTyBwb3J0cyB2aWEg
c3RyaW5nIG9wcyBpcyBub3Qgc3VwcG9ydGVkIHlldC4KPiAKPiBSZXBvcnRlZC1ieTogUm9nZXIg
UGF1IE1vbm7DqTxyb2dlci5wYXVAY2l0cml4LmNvbT4KPiBTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+Cj4gLS0tCj4gdjI6IGhhbmRsZV9waW8oKSBpcyBhbHJl
YWR5IHNhZmUgKHBvaW50ZWQgb3V0IGJ5IE11a2VzaCksIHNvIG9ubHkKPiByZWZ1c2UgZW50ZXJp
bmcgaGFuZGxlX21taW8oKS4KPiBOb3RlOiBPbmx5IGNvbXBpbGUgdGVzdGVkIHNvIGZhci4KPiAK
PiAtLS0gdW5zdGFibGUub3JpZy94ZW4vYXJjaC94ODYvaHZtL3ZteC92bXguYwkyMDE0LTExLTI3
Cj4gMDk6Mzc6MjcuMDAwMDAwMDAwICswMTAwICsrKwo+IHVuc3RhYmxlL3hlbi9hcmNoL3g4Ni9o
dm0vdm14L3ZteC5jCTIwMTQtMTItMDgKPiAxMDowNDoyNy4wMDAwMDAwMDAgKzAxMDAgQEAgLTMw
ODYsNyArMzA4Niw4IEBAIHZvaWQKPiB2bXhfdm1leGl0X2hhbmRsZXIoc3RydWN0IGNwdV91c2Vy
XyBpZiAoIGV4aXRfcXVhbGlmaWNhdGlvbiAmIDB4MTAgKSB7Cj4gICAgICAgICAgICAgIC8qIElO
UywgT1VUUyAqLwo+IC0gICAgICAgICAgICBpZiAoICFoYW5kbGVfbW1pbygpICkKPiArICAgICAg
ICAgICAgaWYgKCB1bmxpa2VseShpc19wdmhfdmNwdSh2KSkgLyogUFZIIGZpeG1lICovIHx8Cj4g
KyAgICAgICAgICAgICAgICAgIWhhbmRsZV9tbWlvKCkgKQo+ICAgICAgICAgICAgICAgICAgaHZt
X2luamVjdF9od19leGNlcHRpb24oVFJBUF9ncF9mYXVsdCwgMCk7Cj4gICAgICAgICAgfQo+ICAg
ICAgICAgIGVsc2UKPiAKCkdvb2QgaWRlYSwgYW5kIGlmIG5lZWRlZDoKCkFja2VkLWJ5OiBNdWtl
c2ggUmF0aG9yIDxtdWtlc2gucmF0aG9yQG9yYWNsZS5jb20+CgoKdGhhbmtzCk11a2VzaAoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Dec 08 23:05:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 23: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 1Xy7Mi-0006q8-65; Mon, 08 Dec 2014 23:05:16 +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 1Xy7Mg-0006q1-S6
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 23:05:14 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	06/1E-09842-AAE26845; Mon, 08 Dec 2014 23:05:14 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418079912!13912196!1
X-Originating-IP: [209.85.220.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28267 invoked from network); 8 Dec 2014 23:05:13 -0000
Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com)
	(209.85.220.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 23:05:13 -0000
Received: by mail-pa0-f43.google.com with SMTP id kx10so6143065pab.2
	for <xen-devel@lists.xenproject.org>;
	Mon, 08 Dec 2014 15:05:12 -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:in-reply-to:references;
	bh=qAoUi6wE0dpwsf7vx7EbHJTFmBqV6cH4505NGA21jqU=;
	b=chQJx5VxRomdh2+JemYRbzU/v1Y/2NHyH9rAc8VKWhu721xJYRn/abzkvqIzI8H68V
	DGDf6T8oxwFz/SE5Q2Uxi2MU3rgTKJHf1By2f18T5bwTv8UoqvnyHBc7x2mSaHXpFchp
	2pCoSXNJUkRrQ//oxPhUOY3ALcVT+FRcH8H34JIhake3Flnxl4T0WE3GWBwX05UR0LWu
	aWbQuykyFbcBCwadyK3k6XxTaVl8gkm929UDBjLftIYVq2NgqIPoZcewJPvZJZqAaNuC
	8eRh3eYbjYUfhspFV3VYJpjOj5Po0uotx8xsHvUJW59u2ppqutv4RO06KBlKwOEaS7kE
	5ZOg==
X-Received: by 10.70.5.68 with SMTP id q4mr25395058pdq.116.1418079912298;
	Mon, 08 Dec 2014 15:05:12 -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 h1sm37604070pat.6.2014.12.08.15.05.08
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 08 Dec 2014 15:05:10 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Mon, 08 Dec 2014 15:05:07 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: hpa@zytor.com,
	josh@joshtriplett.org,
	sam@ravnborg.org
Date: Mon,  8 Dec 2014 15:04:59 -0800
Message-Id: <1418079900-4640-2-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, fengguang.wu@intel.com,
	levinsasha928@gmail.com, David Rientjes <rientjes@google.com>,
	xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>,
	David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v3 1/2] x86, platform,
	kconfig: clarify kvmconfig is for kvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

We'll be adding options for xen as well.

Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: penberg@kernel.org
Cc: levinsasha928@gmail.com
Cc: mtosatti@redhat.com
Cc: fengguang.wu@intel.com
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 scripts/kconfig/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 9645c07..ff612b0 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -141,7 +141,7 @@ help:
 	@echo  '  randconfig	  - New config with random answer to all options'
 	@echo  '  listnewconfig   - List new options'
 	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
-	@echo  '  kvmconfig	  - Enable additional options for guest kernel support'
+	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
 	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
 
 # lxdialog stuff
-- 
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 Mon Dec 08 23:05:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 23: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 1Xy7Mn-0006qW-I9; Mon, 08 Dec 2014 23:05:21 +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 1Xy7Mm-0006qK-42
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 23:05:20 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	70/2E-09842-FAE26845; Mon, 08 Dec 2014 23:05:19 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418079917!14240686!1
X-Originating-IP: [209.85.192.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8008 invoked from network); 8 Dec 2014 23:05:18 -0000
Received: from mail-pd0-f182.google.com (HELO mail-pd0-f182.google.com)
	(209.85.192.182)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 23:05:18 -0000
Received: by mail-pd0-f182.google.com with SMTP id p10so1632756pdj.41
	for <xen-devel@lists.xenproject.org>;
	Mon, 08 Dec 2014 15:05:17 -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:in-reply-to:references;
	bh=u+aAi3P8QHV0vPsRNfvAORvbsmq48ddixqW5CdZMEGI=;
	b=d2WHHBfTjttmUioDxMcwrZ6HOxCaoGQkhyUOlh1CEqnH35FVgFnFHybq6Otvf+GDI5
	AJgpQBKBsz2b3QHgmv/UuyV9xMPw3A1NnxIE0eotFucGjFeF61vosEH7GaoelT3WQR3j
	3GoQzBkkaiu1Z8RwG3Frj/CyDx6ng+aIn262NYMFoFKre24B1Ay0uBn6V6Ds9Kr4nFja
	xQs2eWIP32FDcIuJanEfrHcc16Qol9KeOgz3SJBMxXg2tX2DznrZ4thwDWqI4MO+BLFY
	lZO1syWJehY2mx3+qElxqWFUKbI241s4kjse55vD17Ns3mwrFU1eBohMac1ioj0xf9Tf
	k7xg==
X-Received: by 10.70.123.227 with SMTP id md3mr24987880pdb.80.1418079917082;
	Mon, 08 Dec 2014 15:05:17 -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 b1sm37603048pat.2.2014.12.08.15.05.13
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 08 Dec 2014 15:05:15 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Mon, 08 Dec 2014 15:05:12 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: hpa@zytor.com,
	josh@joshtriplett.org,
	sam@ravnborg.org
Date: Mon,  8 Dec 2014 15:05:00 -0800
Message-Id: <1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, fengguang.wu@intel.com,
	levinsasha928@gmail.com, David Rientjes <rientjes@google.com>,
	xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>,
	David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen,
	kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

This lets you build a kernel which can support xen dom0
or xen guests by just using:

   make xenconfig

on both x86 and arm64 kernels. This also splits out the
options which are available currently to be built with x86
and 'make ARCH=arm64' under a shared config.

Technically xen supports a dom0 kernel and also a guest
kernel configuration but upon review with the xen team
since we don't have many dom0 options its best to just
combine these two into one.

Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: penberg@kernel.org
Cc: levinsasha928@gmail.com
Cc: mtosatti@redhat.com
Cc: fengguang.wu@intel.com
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 arch/x86/configs/xen.config |  6 ++++++
 kernel/configs/xen.config   | 32 ++++++++++++++++++++++++++++++++
 scripts/kconfig/Makefile    |  5 +++++
 3 files changed, 43 insertions(+)
 create mode 100644 arch/x86/configs/xen.config
 create mode 100644 kernel/configs/xen.config

diff --git a/arch/x86/configs/xen.config b/arch/x86/configs/xen.config
new file mode 100644
index 0000000..b97e893
--- /dev/null
+++ b/arch/x86/configs/xen.config
@@ -0,0 +1,6 @@
+# x86 xen specific config options
+CONFIG_XEN_PVHVM=y
+CONFIG_XEN_MAX_DOMAIN_MEMORY=500
+CONFIG_XEN_SAVE_RESTORE=y
+# CONFIG_XEN_DEBUG_FS is not set
+CONFIG_XEN_PVH=y
diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
new file mode 100644
index 0000000..0d0eb6d
--- /dev/null
+++ b/kernel/configs/xen.config
@@ -0,0 +1,32 @@
+# generic config
+CONFIG_XEN=y
+CONFIG_XEN_DOM0=y
+CONFIG_PCI_XEN=y
+CONFIG_XEN_PCIDEV_FRONTEND=m
+CONFIG_XEN_BLKDEV_FRONTEND=m
+CONFIG_XEN_BLKDEV_BACKEND=m
+CONFIG_XEN_NETDEV_FRONTEND=m
+CONFIG_XEN_NETDEV_BACKEND=m
+CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
+CONFIG_HVC_XEN=y
+CONFIG_HVC_XEN_FRONTEND=y
+CONFIG_TCG_XEN=m
+CONFIG_XEN_WDT=m
+CONFIG_XEN_FBDEV_FRONTEND=y
+CONFIG_XEN_BALLOON=y
+CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
+CONFIG_XEN_SCRUB_PAGES=y
+CONFIG_XEN_DEV_EVTCHN=m
+CONFIG_XEN_BACKEND=y
+CONFIG_XENFS=m
+CONFIG_XEN_COMPAT_XENFS=y
+CONFIG_XEN_SYS_HYPERVISOR=y
+CONFIG_XEN_XENBUS_FRONTEND=y
+CONFIG_XEN_GNTDEV=m
+CONFIG_XEN_GRANT_DEV_ALLOC=m
+CONFIG_SWIOTLB_XEN=y
+CONFIG_XEN_PCIDEV_BACKEND=m
+CONFIG_XEN_PRIVCMD=m
+CONFIG_XEN_ACPI_PROCESSOR=m
+CONFIG_XEN_MCE_LOG=y
+CONFIG_XEN_HAVE_PVMMU=y
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index ff612b0..f4a8f89 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -117,6 +117,10 @@ PHONY += kvmconfig
 kvmconfig:
 	$(call mergeconfig,kvm_guest)
 
+PHONY += xenconfig
+xenconfig:
+	$(call mergeconfig,xen)
+
 PHONY += tinyconfig
 tinyconfig: allnoconfig
 	$(call mergeconfig,tiny)
@@ -142,6 +146,7 @@ help:
 	@echo  '  listnewconfig   - List new options'
 	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
 	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
+	@echo  '  xenconfig       - Enable additional options for xen dom0 and guest kernel support'
 	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
 
 # lxdialog stuff
-- 
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 Mon Dec 08 23:05:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 23: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 1Xy7Mc-0006pu-QP; Mon, 08 Dec 2014 23:05:10 +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 1Xy7Mb-0006pp-V7
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 23:05:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DC/0E-09842-5AE26845; Mon, 08 Dec 2014 23:05:09 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418079907!14284233!1
X-Originating-IP: [209.85.220.51]
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 20425 invoked from network); 8 Dec 2014 23:05:08 -0000
Received: from mail-pa0-f51.google.com (HELO mail-pa0-f51.google.com)
	(209.85.220.51)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 23:05:08 -0000
Received: by mail-pa0-f51.google.com with SMTP id ey11so6147447pad.38
	for <xen-devel@lists.xenproject.org>;
	Mon, 08 Dec 2014 15:05:07 -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=PM12+p6mac/ckzmw6a2N+deqtNTTjuTltsrEVMnkBb0=;
	b=tQ5QpMOAIgwRu/GwiZVZp2PkQWuDsL19YNYrlTf9lWswUV82kQwpGW/aED8VpjPr/l
	JWQ/FK7XndcV4QOvl5b++p9aTtHYSQPzZBk6b8JZ3F8ro3jKlSFCVeII9BEciWsrj3cp
	fSLMBujZiWaLC3x5BRU1zftIZVdH8G7gB1ik4/TmUo3UMrN45tIs1RToSL9u5Ex0K38z
	kCkAer8l6Hs9+vSst69YT3RQQH2YI+dKdB9rwd2tvUjEPEuwBHxwvU9t0mWuLdKNfXtY
	fgUbxqcjjscWdyvANefStjAANLCIiDExeB/bQIoEoRitax/iUNp2WFLYBF3uXxQi7OqP
	kFcA==
X-Received: by 10.68.235.5 with SMTP id ui5mr47743806pbc.152.1418079907165;
	Mon, 08 Dec 2014 15:05:07 -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 w1sm20421788pdf.38.2014.12.08.15.05.03
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 08 Dec 2014 15:05:05 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Mon, 08 Dec 2014 15:05:02 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: hpa@zytor.com,
	josh@joshtriplett.org,
	sam@ravnborg.org
Date: Mon,  8 Dec 2014 15:04:58 -0800
Message-Id: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
Cc: kvm@vger.kernel.org, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	bpoirier@suse.de
Subject: [Xen-devel] [PATCH v3 0/2]: x86/arm64: add xenconfig
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

This is based on some old set I had lying around. The virtconfig
changes I had proposed a while ago got merged and reused for
tinyconfig, this adapts my original set to use the new mergeconfig.

Not sure who's tree this should go through, last time these were
lost in space and only the non-xen things got cherry picked later,
who's tree should this go through?

Luis R. Rodriguez (2):
  x86, platform, xen, kconfig: clarify kvmconfig is for kvm
  x86, arm, platform, xen, kconfig: add xen defconfig helper

 arch/x86/configs/xen.config |  6 ++++++
 kernel/configs/xen.config   | 32 ++++++++++++++++++++++++++++++++
 scripts/kconfig/Makefile    |  7 ++++++-
 3 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/configs/xen.config
 create mode 100644 kernel/configs/xen.config

-- 
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 Mon Dec 08 23:05:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 23: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 1Xy7Mn-0006qW-I9; Mon, 08 Dec 2014 23:05:21 +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 1Xy7Mm-0006qK-42
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 23:05:20 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	70/2E-09842-FAE26845; Mon, 08 Dec 2014 23:05:19 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418079917!14240686!1
X-Originating-IP: [209.85.192.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8008 invoked from network); 8 Dec 2014 23:05:18 -0000
Received: from mail-pd0-f182.google.com (HELO mail-pd0-f182.google.com)
	(209.85.192.182)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 23:05:18 -0000
Received: by mail-pd0-f182.google.com with SMTP id p10so1632756pdj.41
	for <xen-devel@lists.xenproject.org>;
	Mon, 08 Dec 2014 15:05:17 -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:in-reply-to:references;
	bh=u+aAi3P8QHV0vPsRNfvAORvbsmq48ddixqW5CdZMEGI=;
	b=d2WHHBfTjttmUioDxMcwrZ6HOxCaoGQkhyUOlh1CEqnH35FVgFnFHybq6Otvf+GDI5
	AJgpQBKBsz2b3QHgmv/UuyV9xMPw3A1NnxIE0eotFucGjFeF61vosEH7GaoelT3WQR3j
	3GoQzBkkaiu1Z8RwG3Frj/CyDx6ng+aIn262NYMFoFKre24B1Ay0uBn6V6Ds9Kr4nFja
	xQs2eWIP32FDcIuJanEfrHcc16Qol9KeOgz3SJBMxXg2tX2DznrZ4thwDWqI4MO+BLFY
	lZO1syWJehY2mx3+qElxqWFUKbI241s4kjse55vD17Ns3mwrFU1eBohMac1ioj0xf9Tf
	k7xg==
X-Received: by 10.70.123.227 with SMTP id md3mr24987880pdb.80.1418079917082;
	Mon, 08 Dec 2014 15:05:17 -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 b1sm37603048pat.2.2014.12.08.15.05.13
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 08 Dec 2014 15:05:15 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Mon, 08 Dec 2014 15:05:12 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: hpa@zytor.com,
	josh@joshtriplett.org,
	sam@ravnborg.org
Date: Mon,  8 Dec 2014 15:05:00 -0800
Message-Id: <1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, fengguang.wu@intel.com,
	levinsasha928@gmail.com, David Rientjes <rientjes@google.com>,
	xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>,
	David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen,
	kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

This lets you build a kernel which can support xen dom0
or xen guests by just using:

   make xenconfig

on both x86 and arm64 kernels. This also splits out the
options which are available currently to be built with x86
and 'make ARCH=arm64' under a shared config.

Technically xen supports a dom0 kernel and also a guest
kernel configuration but upon review with the xen team
since we don't have many dom0 options its best to just
combine these two into one.

Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: penberg@kernel.org
Cc: levinsasha928@gmail.com
Cc: mtosatti@redhat.com
Cc: fengguang.wu@intel.com
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 arch/x86/configs/xen.config |  6 ++++++
 kernel/configs/xen.config   | 32 ++++++++++++++++++++++++++++++++
 scripts/kconfig/Makefile    |  5 +++++
 3 files changed, 43 insertions(+)
 create mode 100644 arch/x86/configs/xen.config
 create mode 100644 kernel/configs/xen.config

diff --git a/arch/x86/configs/xen.config b/arch/x86/configs/xen.config
new file mode 100644
index 0000000..b97e893
--- /dev/null
+++ b/arch/x86/configs/xen.config
@@ -0,0 +1,6 @@
+# x86 xen specific config options
+CONFIG_XEN_PVHVM=y
+CONFIG_XEN_MAX_DOMAIN_MEMORY=500
+CONFIG_XEN_SAVE_RESTORE=y
+# CONFIG_XEN_DEBUG_FS is not set
+CONFIG_XEN_PVH=y
diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
new file mode 100644
index 0000000..0d0eb6d
--- /dev/null
+++ b/kernel/configs/xen.config
@@ -0,0 +1,32 @@
+# generic config
+CONFIG_XEN=y
+CONFIG_XEN_DOM0=y
+CONFIG_PCI_XEN=y
+CONFIG_XEN_PCIDEV_FRONTEND=m
+CONFIG_XEN_BLKDEV_FRONTEND=m
+CONFIG_XEN_BLKDEV_BACKEND=m
+CONFIG_XEN_NETDEV_FRONTEND=m
+CONFIG_XEN_NETDEV_BACKEND=m
+CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
+CONFIG_HVC_XEN=y
+CONFIG_HVC_XEN_FRONTEND=y
+CONFIG_TCG_XEN=m
+CONFIG_XEN_WDT=m
+CONFIG_XEN_FBDEV_FRONTEND=y
+CONFIG_XEN_BALLOON=y
+CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
+CONFIG_XEN_SCRUB_PAGES=y
+CONFIG_XEN_DEV_EVTCHN=m
+CONFIG_XEN_BACKEND=y
+CONFIG_XENFS=m
+CONFIG_XEN_COMPAT_XENFS=y
+CONFIG_XEN_SYS_HYPERVISOR=y
+CONFIG_XEN_XENBUS_FRONTEND=y
+CONFIG_XEN_GNTDEV=m
+CONFIG_XEN_GRANT_DEV_ALLOC=m
+CONFIG_SWIOTLB_XEN=y
+CONFIG_XEN_PCIDEV_BACKEND=m
+CONFIG_XEN_PRIVCMD=m
+CONFIG_XEN_ACPI_PROCESSOR=m
+CONFIG_XEN_MCE_LOG=y
+CONFIG_XEN_HAVE_PVMMU=y
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index ff612b0..f4a8f89 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -117,6 +117,10 @@ PHONY += kvmconfig
 kvmconfig:
 	$(call mergeconfig,kvm_guest)
 
+PHONY += xenconfig
+xenconfig:
+	$(call mergeconfig,xen)
+
 PHONY += tinyconfig
 tinyconfig: allnoconfig
 	$(call mergeconfig,tiny)
@@ -142,6 +146,7 @@ help:
 	@echo  '  listnewconfig   - List new options'
 	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
 	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
+	@echo  '  xenconfig       - Enable additional options for xen dom0 and guest kernel support'
 	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
 
 # lxdialog stuff
-- 
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 Mon Dec 08 23:05:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 23: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 1Xy7Mc-0006pu-QP; Mon, 08 Dec 2014 23:05:10 +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 1Xy7Mb-0006pp-V7
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 23:05:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DC/0E-09842-5AE26845; Mon, 08 Dec 2014 23:05:09 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418079907!14284233!1
X-Originating-IP: [209.85.220.51]
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 20425 invoked from network); 8 Dec 2014 23:05:08 -0000
Received: from mail-pa0-f51.google.com (HELO mail-pa0-f51.google.com)
	(209.85.220.51)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 23:05:08 -0000
Received: by mail-pa0-f51.google.com with SMTP id ey11so6147447pad.38
	for <xen-devel@lists.xenproject.org>;
	Mon, 08 Dec 2014 15:05:07 -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=PM12+p6mac/ckzmw6a2N+deqtNTTjuTltsrEVMnkBb0=;
	b=tQ5QpMOAIgwRu/GwiZVZp2PkQWuDsL19YNYrlTf9lWswUV82kQwpGW/aED8VpjPr/l
	JWQ/FK7XndcV4QOvl5b++p9aTtHYSQPzZBk6b8JZ3F8ro3jKlSFCVeII9BEciWsrj3cp
	fSLMBujZiWaLC3x5BRU1zftIZVdH8G7gB1ik4/TmUo3UMrN45tIs1RToSL9u5Ex0K38z
	kCkAer8l6Hs9+vSst69YT3RQQH2YI+dKdB9rwd2tvUjEPEuwBHxwvU9t0mWuLdKNfXtY
	fgUbxqcjjscWdyvANefStjAANLCIiDExeB/bQIoEoRitax/iUNp2WFLYBF3uXxQi7OqP
	kFcA==
X-Received: by 10.68.235.5 with SMTP id ui5mr47743806pbc.152.1418079907165;
	Mon, 08 Dec 2014 15:05:07 -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 w1sm20421788pdf.38.2014.12.08.15.05.03
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 08 Dec 2014 15:05:05 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Mon, 08 Dec 2014 15:05:02 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: hpa@zytor.com,
	josh@joshtriplett.org,
	sam@ravnborg.org
Date: Mon,  8 Dec 2014 15:04:58 -0800
Message-Id: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
Cc: kvm@vger.kernel.org, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	bpoirier@suse.de
Subject: [Xen-devel] [PATCH v3 0/2]: x86/arm64: add xenconfig
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

This is based on some old set I had lying around. The virtconfig
changes I had proposed a while ago got merged and reused for
tinyconfig, this adapts my original set to use the new mergeconfig.

Not sure who's tree this should go through, last time these were
lost in space and only the non-xen things got cherry picked later,
who's tree should this go through?

Luis R. Rodriguez (2):
  x86, platform, xen, kconfig: clarify kvmconfig is for kvm
  x86, arm, platform, xen, kconfig: add xen defconfig helper

 arch/x86/configs/xen.config |  6 ++++++
 kernel/configs/xen.config   | 32 ++++++++++++++++++++++++++++++++
 scripts/kconfig/Makefile    |  7 ++++++-
 3 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/configs/xen.config
 create mode 100644 kernel/configs/xen.config

-- 
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 Mon Dec 08 23:05:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 23: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 1Xy7Mi-0006q8-65; Mon, 08 Dec 2014 23:05:16 +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 1Xy7Mg-0006q1-S6
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 23:05:14 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	06/1E-09842-AAE26845; Mon, 08 Dec 2014 23:05:14 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418079912!13912196!1
X-Originating-IP: [209.85.220.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28267 invoked from network); 8 Dec 2014 23:05:13 -0000
Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com)
	(209.85.220.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Dec 2014 23:05:13 -0000
Received: by mail-pa0-f43.google.com with SMTP id kx10so6143065pab.2
	for <xen-devel@lists.xenproject.org>;
	Mon, 08 Dec 2014 15:05:12 -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:in-reply-to:references;
	bh=qAoUi6wE0dpwsf7vx7EbHJTFmBqV6cH4505NGA21jqU=;
	b=chQJx5VxRomdh2+JemYRbzU/v1Y/2NHyH9rAc8VKWhu721xJYRn/abzkvqIzI8H68V
	DGDf6T8oxwFz/SE5Q2Uxi2MU3rgTKJHf1By2f18T5bwTv8UoqvnyHBc7x2mSaHXpFchp
	2pCoSXNJUkRrQ//oxPhUOY3ALcVT+FRcH8H34JIhake3Flnxl4T0WE3GWBwX05UR0LWu
	aWbQuykyFbcBCwadyK3k6XxTaVl8gkm929UDBjLftIYVq2NgqIPoZcewJPvZJZqAaNuC
	8eRh3eYbjYUfhspFV3VYJpjOj5Po0uotx8xsHvUJW59u2ppqutv4RO06KBlKwOEaS7kE
	5ZOg==
X-Received: by 10.70.5.68 with SMTP id q4mr25395058pdq.116.1418079912298;
	Mon, 08 Dec 2014 15:05:12 -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 h1sm37604070pat.6.2014.12.08.15.05.08
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 08 Dec 2014 15:05:10 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Mon, 08 Dec 2014 15:05:07 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: hpa@zytor.com,
	josh@joshtriplett.org,
	sam@ravnborg.org
Date: Mon,  8 Dec 2014 15:04:59 -0800
Message-Id: <1418079900-4640-2-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, fengguang.wu@intel.com,
	levinsasha928@gmail.com, David Rientjes <rientjes@google.com>,
	xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>,
	David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v3 1/2] x86, platform,
	kconfig: clarify kvmconfig is for kvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

We'll be adding options for xen as well.

Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: penberg@kernel.org
Cc: levinsasha928@gmail.com
Cc: mtosatti@redhat.com
Cc: fengguang.wu@intel.com
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 scripts/kconfig/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 9645c07..ff612b0 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -141,7 +141,7 @@ help:
 	@echo  '  randconfig	  - New config with random answer to all options'
 	@echo  '  listnewconfig   - List new options'
 	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
-	@echo  '  kvmconfig	  - Enable additional options for guest kernel support'
+	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
 	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
 
 # lxdialog stuff
-- 
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 Mon Dec 08 23:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 23: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 1Xy87x-0008Ux-MG; Mon, 08 Dec 2014 23:54:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xy87w-0008Us-6Y
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 23:54:04 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	14/B1-17735-B1A36845; Mon, 08 Dec 2014 23:54:03 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418082842!11919699!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32445 invoked from network); 8 Dec 2014 23:54:02 -0000
Received: from relay5-d.mail.gandi.net (HELO relay5-d.mail.gandi.net)
	(217.70.183.197)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 23:54:02 -0000
Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146])
	by relay5-d.mail.gandi.net (Postfix) with ESMTP id 6872841C062;
	Tue,  9 Dec 2014 00:54:02 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net
Received: from relay5-d.mail.gandi.net ([217.70.183.197])
	by mfilter18-d.gandi.net (mfilter18-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id aFiqIScrxGiY; Tue,  9 Dec 2014 00:54:01 +0100 (CET)
X-Originating-IP: 50.43.43.148
Received: from thin (static-50-43-43-148.bvtn.or.frontiernet.net
	[50.43.43.148]) (Authenticated sender: josh@joshtriplett.org)
	by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 51C6A41C05C;
	Tue,  9 Dec 2014 00:53:56 +0100 (CET)
Date: Mon, 8 Dec 2014 15:53:54 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Message-ID: <20141208235354.GC15837@thin>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: kvm@vger.kernel.org, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	xen-devel@lists.xenproject.org, sam@ravnborg.org, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v3 0/2]: x86/arm64: add xenconfig
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 03:04:58PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> This is based on some old set I had lying around. The virtconfig
> changes I had proposed a while ago got merged and reused for
> tinyconfig, this adapts my original set to use the new mergeconfig.
> 
> Not sure who's tree this should go through, last time these were
> lost in space and only the non-xen things got cherry picked later,
> who's tree should this go through?
> 
> Luis R. Rodriguez (2):
>   x86, platform, xen, kconfig: clarify kvmconfig is for kvm
>   x86, arm, platform, xen, kconfig: add xen defconfig helper

For both:
Reviewed-by: Josh Triplett <josh@joshtriplett.org>

>  arch/x86/configs/xen.config |  6 ++++++
>  kernel/configs/xen.config   | 32 ++++++++++++++++++++++++++++++++
>  scripts/kconfig/Makefile    |  7 ++++++-
>  3 files changed, 44 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/configs/xen.config
>  create mode 100644 kernel/configs/xen.config
> 
> -- 
> 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 Mon Dec 08 23:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Dec 2014 23: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 1Xy87x-0008Ux-MG; Mon, 08 Dec 2014 23:54:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1Xy87w-0008Us-6Y
	for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 23:54:04 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	14/B1-17735-B1A36845; Mon, 08 Dec 2014 23:54:03 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418082842!11919699!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32445 invoked from network); 8 Dec 2014 23:54:02 -0000
Received: from relay5-d.mail.gandi.net (HELO relay5-d.mail.gandi.net)
	(217.70.183.197)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Dec 2014 23:54:02 -0000
Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146])
	by relay5-d.mail.gandi.net (Postfix) with ESMTP id 6872841C062;
	Tue,  9 Dec 2014 00:54:02 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net
Received: from relay5-d.mail.gandi.net ([217.70.183.197])
	by mfilter18-d.gandi.net (mfilter18-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id aFiqIScrxGiY; Tue,  9 Dec 2014 00:54:01 +0100 (CET)
X-Originating-IP: 50.43.43.148
Received: from thin (static-50-43-43-148.bvtn.or.frontiernet.net
	[50.43.43.148]) (Authenticated sender: josh@joshtriplett.org)
	by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 51C6A41C05C;
	Tue,  9 Dec 2014 00:53:56 +0100 (CET)
Date: Mon, 8 Dec 2014 15:53:54 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Message-ID: <20141208235354.GC15837@thin>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: kvm@vger.kernel.org, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	xen-devel@lists.xenproject.org, sam@ravnborg.org, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v3 0/2]: x86/arm64: add xenconfig
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 03:04:58PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> This is based on some old set I had lying around. The virtconfig
> changes I had proposed a while ago got merged and reused for
> tinyconfig, this adapts my original set to use the new mergeconfig.
> 
> Not sure who's tree this should go through, last time these were
> lost in space and only the non-xen things got cherry picked later,
> who's tree should this go through?
> 
> Luis R. Rodriguez (2):
>   x86, platform, xen, kconfig: clarify kvmconfig is for kvm
>   x86, arm, platform, xen, kconfig: add xen defconfig helper

For both:
Reviewed-by: Josh Triplett <josh@joshtriplett.org>

>  arch/x86/configs/xen.config |  6 ++++++
>  kernel/configs/xen.config   | 32 ++++++++++++++++++++++++++++++++
>  scripts/kconfig/Makefile    |  7 ++++++-
>  3 files changed, 44 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/configs/xen.config
>  create mode 100644 kernel/configs/xen.config
> 
> -- 
> 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 Tue Dec 09 00:22:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 00: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 1Xy8YQ-00019C-5x; Tue, 09 Dec 2014 00:21:26 +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 1Xy8YN-000197-VD
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 00:21:24 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A3/DD-25276-38046845; Tue, 09 Dec 2014 00:21:23 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418084482!14272855!1
X-Originating-IP: [131.111.8.140]
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 6823 invoked from network); 9 Dec 2014 00:21:22 -0000
Received: from ppsw-40.csi.cam.ac.uk (HELO ppsw-40.csi.cam.ac.uk)
	(131.111.8.140)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 00:21:22 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-82-25-227-239.glfd.adsl.virginm.net
	([82.25.227.239]:57363 helo=[192.168.1.193])
	by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1Xy8YL-00079n-kW (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 09 Dec 2014 00:21:21 +0000
Message-ID: <54864081.6090606@citrix.com>
Date: Tue, 09 Dec 2014 00:21: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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <5485F5F7.6040206@citrix.com>
	<20141208200034.GA3891@laptop.dumpdata.com>
In-Reply-To: <20141208200034.GA3891@laptop.dumpdata.com>
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/12/2014 20:00, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 08, 2014 at 07:03:19PM +0000, Andrew Cooper wrote:
>> Hi,
> Hey Andrew!
>> Over the weekend, XenServer testing managed to run a side-by-side test
>> of XenServer trunk and XenServer experimental xen-4.5.  These are
>> identical other than the version of Xen (and associated libraries) in
>> use, i.e. identical dom0 kernel, Xapi toolstack and dom0 userspace,
>> other than as linked against newer Xen libraries.
>>
>> The Xen-4.5 tests were on top of c/s e6c3d371d4 "systemd: use pkg-config
>> to determine systemd library availability"
>>
>> There are a few notable issues exposed:
>>
>> XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it didn't in
>> xen-4.4, given identical parameters.  The hypercall gained an extra
>> permission check as part of 0561e1f01e.  Our usecase here is a daemon in
>> dom0 mapping guest RAM to emulate a graphics card, but I currently don't
>> see how that is incompatible with the new permissions check.
> I presume the daemon also does 'XEN_DOMCTL_iomem_permission' to grant
> the other domain access to its RAM? And before it makes the
> XEN_DOMCTL_memory_mapping hypercall.

This is purely an implementer of the ioreq server infrastructure
providing an emulated set of BARs in the guest as qemu would, but
without using dom0 map-foreign powers.  The gfn ranges in question are
regular guest RAM as far as I am aware, and should not require any
special io permissions.

Either way, the identified changeset has apparently caused a regression,
but I am not yet certain whether it is legitimately disabling something
which should not have worked in the first place, or whether it is a
change which needs reconsidering.

>
>> Migrations from older Xens to Xen-4.5 fairly reliably crash domains (90%
>> of the time, both PV and HVM guests).  This includes migrates from older
>> XenServers using the legacy->v2 migration code which is confirmed-good
>> in "upgrade to Xen-4.4" case.  The migration v2 code in use is identical.
> The XenServer is not using the in-the-tree migration system except in
> the older version of XenServer right?

XenServer expermental-4.5 is strictly using migration v2, including
upgrade from legacy, but as far as I am aware identical migration v2 as
our current Xen-4.4 trunk which works fine for all tests.

>> We have certain machines which are showing reliable failure to boot
>> under Xen-4.5, where they worked with 4.4.  Symptoms range from the dom0
>> kernel crashing before printing anything, to complaining that the initrd
>> is corrupt when attempting to decompress.  This appears to be hardware
>> specific.
> Hardware specific is good. Could you give some ideas of what make/model
> this is?

They are all IBM blades to the best of my knowledge, which are a similar
system to the hardware which gave me 1ed7679 to debug, so I am hoping it
is a latent BIOS issue and not a Xen 4.5 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 Dec 09 00:22:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 00: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 1Xy8YQ-00019C-5x; Tue, 09 Dec 2014 00:21:26 +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 1Xy8YN-000197-VD
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 00:21:24 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A3/DD-25276-38046845; Tue, 09 Dec 2014 00:21:23 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418084482!14272855!1
X-Originating-IP: [131.111.8.140]
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 6823 invoked from network); 9 Dec 2014 00:21:22 -0000
Received: from ppsw-40.csi.cam.ac.uk (HELO ppsw-40.csi.cam.ac.uk)
	(131.111.8.140)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 00:21:22 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-82-25-227-239.glfd.adsl.virginm.net
	([82.25.227.239]:57363 helo=[192.168.1.193])
	by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1Xy8YL-00079n-kW (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 09 Dec 2014 00:21:21 +0000
Message-ID: <54864081.6090606@citrix.com>
Date: Tue, 09 Dec 2014 00:21: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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <5485F5F7.6040206@citrix.com>
	<20141208200034.GA3891@laptop.dumpdata.com>
In-Reply-To: <20141208200034.GA3891@laptop.dumpdata.com>
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/12/2014 20:00, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 08, 2014 at 07:03:19PM +0000, Andrew Cooper wrote:
>> Hi,
> Hey Andrew!
>> Over the weekend, XenServer testing managed to run a side-by-side test
>> of XenServer trunk and XenServer experimental xen-4.5.  These are
>> identical other than the version of Xen (and associated libraries) in
>> use, i.e. identical dom0 kernel, Xapi toolstack and dom0 userspace,
>> other than as linked against newer Xen libraries.
>>
>> The Xen-4.5 tests were on top of c/s e6c3d371d4 "systemd: use pkg-config
>> to determine systemd library availability"
>>
>> There are a few notable issues exposed:
>>
>> XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it didn't in
>> xen-4.4, given identical parameters.  The hypercall gained an extra
>> permission check as part of 0561e1f01e.  Our usecase here is a daemon in
>> dom0 mapping guest RAM to emulate a graphics card, but I currently don't
>> see how that is incompatible with the new permissions check.
> I presume the daemon also does 'XEN_DOMCTL_iomem_permission' to grant
> the other domain access to its RAM? And before it makes the
> XEN_DOMCTL_memory_mapping hypercall.

This is purely an implementer of the ioreq server infrastructure
providing an emulated set of BARs in the guest as qemu would, but
without using dom0 map-foreign powers.  The gfn ranges in question are
regular guest RAM as far as I am aware, and should not require any
special io permissions.

Either way, the identified changeset has apparently caused a regression,
but I am not yet certain whether it is legitimately disabling something
which should not have worked in the first place, or whether it is a
change which needs reconsidering.

>
>> Migrations from older Xens to Xen-4.5 fairly reliably crash domains (90%
>> of the time, both PV and HVM guests).  This includes migrates from older
>> XenServers using the legacy->v2 migration code which is confirmed-good
>> in "upgrade to Xen-4.4" case.  The migration v2 code in use is identical.
> The XenServer is not using the in-the-tree migration system except in
> the older version of XenServer right?

XenServer expermental-4.5 is strictly using migration v2, including
upgrade from legacy, but as far as I am aware identical migration v2 as
our current Xen-4.4 trunk which works fine for all tests.

>> We have certain machines which are showing reliable failure to boot
>> under Xen-4.5, where they worked with 4.4.  Symptoms range from the dom0
>> kernel crashing before printing anything, to complaining that the initrd
>> is corrupt when attempting to decompress.  This appears to be hardware
>> specific.
> Hardware specific is good. Could you give some ideas of what make/model
> this is?

They are all IBM blades to the best of my knowledge, which are a similar
system to the hardware which gave me 1ed7679 to debug, so I am hoping it
is a latent BIOS issue and not a Xen 4.5 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 Dec 09 01:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 01:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy9GU-0006UF-BA; Tue, 09 Dec 2014 01:06:58 +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 1Xy9GS-0006UA-Gs
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 01:06:56 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	6D/E9-22819-F2B46845; Tue, 09 Dec 2014 01:06:55 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418087213!12250449!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 18437 invoked from network); 9 Dec 2014 01:06:54 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-206.messagelabs.com with SMTP;
	9 Dec 2014 01:06:54 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 08 Dec 2014 17:05:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,541,1413270000"; d="scan'208";a="650618471"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.208])
	([10.238.128.208])
	by orsmga002.jf.intel.com with ESMTP; 08 Dec 2014 17:06:36 -0800
Message-ID: <54864B1C.6020701@intel.com>
Date: Tue, 09 Dec 2014 09:06:36 +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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<20141202193943.GC357@laptop.dumpdata.com>
	<548517F7.6040106@intel.com>
	<20141208155734.GE7745@laptop.dumpdata.com>
In-Reply-To: <20141208155734.GE7745@laptop.dumpdata.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/drivers/passthrough/pci.c
>>>> +++ b/xen/drivers/passthrough/pci.c
>>>> @@ -34,6 +34,7 @@
>>>>   #include <xen/tasklet.h>
>>>>   #include <xsm/xsm.h>
>>>>   #include <asm/msi.h>
>>>> +#include <xen/stdbool.h>
>>>>
>>>>   struct pci_seg {
>>>>       struct list_head alldevs_list;
>>>> @@ -1553,6 +1554,44 @@ 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 = NULL;
>>>> +        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
>>>> +
>>>> +        if ( d == NULL )
>>>> +            return -ESRCH;
>>>> +
>>>
>>> What if this is called on an PV domain?
>>
>> Currently we just support this in HVM, so I'd like to add this,
>>
>>           if ( d == NULL )
>>               return -ESRCH;
>>
>> +        ASSERT( is_hvm_domain(d) );
>> +
>
> No. Please don't crash the hypervisor.

Okay.

>
> Just return -ENOSYS or such when done for PV guests.

So,

+        if ( !is_hvm_domain(d) )
+            return -ENOSYS;

>
>>
>>>
>>> You are also missing the XSM checks.
>>
>> Just see this below.
>>
>>>
>>> What if this is called multiple times. Is it OK to over-ride
>>> the 'pci_force' or should it stick once?
>>
>> It should be fine since just xc/hvmloader need such an information while
>> creating a VM.
>>
>> And especially, currently we just call this one time to set. So why we need
>> to call this again and again? I think if anyone want to extend such a case
>> you're worrying, he should know any effect before he take a action, right?
>
> Program defensively and also think about preemption. If this call end up

Do you think we need a fine grain way, like lock here?

> being preempted you might need to call it again. Or if the third-party
> toolstack use this operation and call this with wacky values?

Maybe can the following address this enough,

     case XEN_DOMCTL_set_rdm:
     {
         struct xen_domctl_set_rdm *xdsr = &domctl->u.set_rdm;
         struct xen_guest_pcidev_info *pcidevs = NULL;

         if ( d->arch.hvm_domain.pcidevs )
             break;

         if ( !is_hvm_domain(d) )
             return -ENOSYS;
	...

>>
>>>
>>>
>>>> +        d->arch.hvm_domain.pci_force =
>>>> +                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;
>>>
>>> Won't we crash here if this is called for PV guests?
>>
>> After the line, 'ASSERT( is_hvm_domain(d) );', is added, this problem should
>> be gone.
>
> No it won't be. You will just crash the hypervisor.
>
> Please please put yourself in the mind that the toolstack can (and will)
> have bugs.

Thanks for your reminder.

>>
>>>
>>>> +        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;
>>>
>>> What if the 'num_pcidevs' has some bogus value. You need to check for that.
>>

[snip]

>>>>           return 0;
>>>
>>>
>>> Also how does this work with 32-bit dom0s? Is there a need to use the
>>> compat layer?
>>
>> Are you saying in xsm case? Others?
>>
>> Actually this new DOMCTL is similar with XEN_DOMCTL_assign_device in some
>> senses but I don't see such an issue you're pointing.
>
> I was thinking about the compat layer and making sure it works properly.

Do we really need this consideration? I mean I referred to that existing 
XEN_DOMCTL_assign_device to implement this new DOMCTL, but looks there's 
nothing related to this point.

Or could you make your thought clear to me with an exiting example? Then 
I can take a look at what exactly should be taken in my new DOMCTL since 
I'm a fresh man to work out this properly inside xen.

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 Dec 09 01:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 01:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xy9GU-0006UF-BA; Tue, 09 Dec 2014 01:06:58 +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 1Xy9GS-0006UA-Gs
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 01:06:56 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	6D/E9-22819-F2B46845; Tue, 09 Dec 2014 01:06:55 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418087213!12250449!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 18437 invoked from network); 9 Dec 2014 01:06:54 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-206.messagelabs.com with SMTP;
	9 Dec 2014 01:06:54 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 08 Dec 2014 17:05:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,541,1413270000"; d="scan'208";a="650618471"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.208])
	([10.238.128.208])
	by orsmga002.jf.intel.com with ESMTP; 08 Dec 2014 17:06:36 -0800
Message-ID: <54864B1C.6020701@intel.com>
Date: Tue, 09 Dec 2014 09:06:36 +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.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<20141202193943.GC357@laptop.dumpdata.com>
	<548517F7.6040106@intel.com>
	<20141208155734.GE7745@laptop.dumpdata.com>
In-Reply-To: <20141208155734.GE7745@laptop.dumpdata.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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/drivers/passthrough/pci.c
>>>> +++ b/xen/drivers/passthrough/pci.c
>>>> @@ -34,6 +34,7 @@
>>>>   #include <xen/tasklet.h>
>>>>   #include <xsm/xsm.h>
>>>>   #include <asm/msi.h>
>>>> +#include <xen/stdbool.h>
>>>>
>>>>   struct pci_seg {
>>>>       struct list_head alldevs_list;
>>>> @@ -1553,6 +1554,44 @@ 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 = NULL;
>>>> +        struct domain *d = rcu_lock_domain_by_any_id(domctl->domain);
>>>> +
>>>> +        if ( d == NULL )
>>>> +            return -ESRCH;
>>>> +
>>>
>>> What if this is called on an PV domain?
>>
>> Currently we just support this in HVM, so I'd like to add this,
>>
>>           if ( d == NULL )
>>               return -ESRCH;
>>
>> +        ASSERT( is_hvm_domain(d) );
>> +
>
> No. Please don't crash the hypervisor.

Okay.

>
> Just return -ENOSYS or such when done for PV guests.

So,

+        if ( !is_hvm_domain(d) )
+            return -ENOSYS;

>
>>
>>>
>>> You are also missing the XSM checks.
>>
>> Just see this below.
>>
>>>
>>> What if this is called multiple times. Is it OK to over-ride
>>> the 'pci_force' or should it stick once?
>>
>> It should be fine since just xc/hvmloader need such an information while
>> creating a VM.
>>
>> And especially, currently we just call this one time to set. So why we need
>> to call this again and again? I think if anyone want to extend such a case
>> you're worrying, he should know any effect before he take a action, right?
>
> Program defensively and also think about preemption. If this call end up

Do you think we need a fine grain way, like lock here?

> being preempted you might need to call it again. Or if the third-party
> toolstack use this operation and call this with wacky values?

Maybe can the following address this enough,

     case XEN_DOMCTL_set_rdm:
     {
         struct xen_domctl_set_rdm *xdsr = &domctl->u.set_rdm;
         struct xen_guest_pcidev_info *pcidevs = NULL;

         if ( d->arch.hvm_domain.pcidevs )
             break;

         if ( !is_hvm_domain(d) )
             return -ENOSYS;
	...

>>
>>>
>>>
>>>> +        d->arch.hvm_domain.pci_force =
>>>> +                            xdsr->flags & PCI_DEV_RDM_CHECK ? true : false;
>>>
>>> Won't we crash here if this is called for PV guests?
>>
>> After the line, 'ASSERT( is_hvm_domain(d) );', is added, this problem should
>> be gone.
>
> No it won't be. You will just crash the hypervisor.
>
> Please please put yourself in the mind that the toolstack can (and will)
> have bugs.

Thanks for your reminder.

>>
>>>
>>>> +        d->arch.hvm_domain.num_pcidevs = xdsr->num_pcidevs;
>>>
>>> What if the 'num_pcidevs' has some bogus value. You need to check for that.
>>

[snip]

>>>>           return 0;
>>>
>>>
>>> Also how does this work with 32-bit dom0s? Is there a need to use the
>>> compat layer?
>>
>> Are you saying in xsm case? Others?
>>
>> Actually this new DOMCTL is similar with XEN_DOMCTL_assign_device in some
>> senses but I don't see such an issue you're pointing.
>
> I was thinking about the compat layer and making sure it works properly.

Do we really need this consideration? I mean I referred to that existing 
XEN_DOMCTL_assign_device to implement this new DOMCTL, but looks there's 
nothing related to this point.

Or could you make your thought clear to me with an exiting example? Then 
I can take a look at what exactly should be taken in my new DOMCTL since 
I'm a fresh man to work out this properly inside xen.

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 Dec 09 02:04:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 02: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 1XyA9J-0008SQ-TX; Tue, 09 Dec 2014 02:03:37 +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 1XyA9H-0008SK-9p
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 02:03:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	07/E1-09842-67856845; Tue, 09 Dec 2014 02:03:34 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418090612!14282439!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11261 invoked from network); 9 Dec 2014 02:03:33 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-10.tower-21.messagelabs.com with SMTP;
	9 Dec 2014 02:03:33 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 08 Dec 2014 18:01:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,541,1413270000"; d="scan'208";a="620743565"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga001.jf.intel.com with ESMTP; 08 Dec 2014 18:03:27 -0800
Message-ID: <54865820.2010501@linux.intel.com>
Date: Tue, 09 Dec 2014 10:02:08 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Xen-devel@lists.xen.org, kevin.tian@intel.com, tim@xen.org, 
	JBeulich@suse.com
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
In-Reply-To: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com, donald.d.dugger@intel.com,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v6 0/2] add new p2m type class and new p2m
 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

Hi Tim & Jan,

   Thank you very much for your review.
   And could you please also help me about how to get an ACK? I'm not 
sure what's the next action I need to take. :-)

B.R.
Yu

On 12/6/2014 11:55 AM, Yu Zhang wrote:
> 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 added
> a new p2m type, p2m_mmio_write_dm, to trap and emulate the write
> operations 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_ram_ro types, write operations will not
> trigger the device model, and will be discarded later in __hvm_copy();
> while for the 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 v5:
>   - Stricter type checks for p2m type transitions;
>   - One code style change.
>
> Changes from v4:
>   - A new p2m type class, P2M_DISCARD_WRITE_TYPES, is added;
>   - A new predicate, p2m_is_discard_write, is used in __hvm_copy()/
>     __hvm_clear()/emulate_gva_to_mfn()/hvm_hap_nested_page_fault(),
>     to discard the write operations;
>   - The new p2m type, p2m_mmio_write_dm, is added to P2M_RO_TYPES;
>   - Coding style changes;
>
> 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.
>
> Yu Zhang (2):
>    Add a new p2m type class - P2M_DISCARD_WRITE_TYPES
>    add a new p2m type - p2m_mmio_write_dm
>
>   xen/arch/x86/hvm/hvm.c          | 25 ++++++++++---------------
>   xen/arch/x86/mm/p2m-ept.c       |  1 +
>   xen/arch/x86/mm/p2m-pt.c        |  1 +
>   xen/arch/x86/mm/shadow/multi.c  |  2 +-
>   xen/include/asm-x86/p2m.h       |  9 ++++++++-
>   xen/include/public/hvm/hvm_op.h |  1 +
>   6 files changed, 22 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 Tue Dec 09 02:04:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 02: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 1XyA9J-0008SQ-TX; Tue, 09 Dec 2014 02:03:37 +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 1XyA9H-0008SK-9p
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 02:03:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	07/E1-09842-67856845; Tue, 09 Dec 2014 02:03:34 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418090612!14282439!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11261 invoked from network); 9 Dec 2014 02:03:33 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-10.tower-21.messagelabs.com with SMTP;
	9 Dec 2014 02:03:33 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 08 Dec 2014 18:01:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,541,1413270000"; d="scan'208";a="620743565"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga001.jf.intel.com with ESMTP; 08 Dec 2014 18:03:27 -0800
Message-ID: <54865820.2010501@linux.intel.com>
Date: Tue, 09 Dec 2014 10:02:08 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Xen-devel@lists.xen.org, kevin.tian@intel.com, tim@xen.org, 
	JBeulich@suse.com
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
In-Reply-To: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	ian.jackson@eu.citrix.com, donald.d.dugger@intel.com,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v6 0/2] add new p2m type class and new p2m
 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

Hi Tim & Jan,

   Thank you very much for your review.
   And could you please also help me about how to get an ACK? I'm not 
sure what's the next action I need to take. :-)

B.R.
Yu

On 12/6/2014 11:55 AM, Yu Zhang wrote:
> 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 added
> a new p2m type, p2m_mmio_write_dm, to trap and emulate the write
> operations 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_ram_ro types, write operations will not
> trigger the device model, and will be discarded later in __hvm_copy();
> while for the 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 v5:
>   - Stricter type checks for p2m type transitions;
>   - One code style change.
>
> Changes from v4:
>   - A new p2m type class, P2M_DISCARD_WRITE_TYPES, is added;
>   - A new predicate, p2m_is_discard_write, is used in __hvm_copy()/
>     __hvm_clear()/emulate_gva_to_mfn()/hvm_hap_nested_page_fault(),
>     to discard the write operations;
>   - The new p2m type, p2m_mmio_write_dm, is added to P2M_RO_TYPES;
>   - Coding style changes;
>
> 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.
>
> Yu Zhang (2):
>    Add a new p2m type class - P2M_DISCARD_WRITE_TYPES
>    add a new p2m type - p2m_mmio_write_dm
>
>   xen/arch/x86/hvm/hvm.c          | 25 ++++++++++---------------
>   xen/arch/x86/mm/p2m-ept.c       |  1 +
>   xen/arch/x86/mm/p2m-pt.c        |  1 +
>   xen/arch/x86/mm/shadow/multi.c  |  2 +-
>   xen/include/asm-x86/p2m.h       |  9 ++++++++-
>   xen/include/public/hvm/hvm_op.h |  1 +
>   6 files changed, 22 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 Tue Dec 09 02:38:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 02:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyAgn-0000va-Vt; Tue, 09 Dec 2014 02:38:13 +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 1XyAgm-0000vV-Tl
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 02:38:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1D/AE-15461-49066845; Tue, 09 Dec 2014 02:38:12 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418092690!14220949!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 25570 invoked from network); 9 Dec 2014 02:38:11 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-21.messagelabs.com with SMTP;
	9 Dec 2014 02:38:11 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 08 Dec 2014 18:38:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,542,1413270000"; d="scan'208";a="634757269"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.208])
	([10.238.128.208])
	by fmsmga001.fm.intel.com with ESMTP; 08 Dec 2014 18:38:08 -0800
Message-ID: <5486608F.1050700@intel.com>
Date: Tue, 09 Dec 2014 10:38: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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<54808CC3020000780004CCC8@mail.emea.novell.com>
	<54853FE3.9030703@intel.com>
	<548572B5020000780004D9BC@mail.emea.novell.com>
In-Reply-To: <548572B5020000780004D9BC@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/8 16:43, Jan Beulich wrote:
>>>> On 08.12.14 at 07:06, <tiejun.chen@intel.com> wrote:
>> On 2014/12/4 23:33, Jan Beulich wrote:
>>>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> Looks this could be fine,
>>
>> d->arch.hvm_domain.pci_force = xdsr->flags & PCI_DEV_RDM_CHECK;
>
> Which is correct only because PCI_DEV_RDM_CHECK happens to be
> 1. Such hidden dependencies shouldn't be introduced though, in
> particular to avoid others then cloning the code for a flag that's not
> 1. The canonical form (found in many places throughout the treei

Right.

>
>      d->arch.hvm_domain.pci_force = !!(xdsr->flags & PCI_DEV_RDM_CHECK);

Fixed.

>
>>>> +        d->arch.hvm_domain.pcidevs = NULL;
>>>> +
>>>> +        if ( xdsr->num_pcidevs )
>>>> +        {
>>>> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
>>>> +                                    xdsr->num_pcidevs);
>>>
>>> New domctl-s must not represent security risks: xdsr->num_pcidevs
>>> can be (almost) arbitrarily large - do you really want to allow such
>>> huge allocations? A reasonable upper bound could for example be
>>
>> Sorry, as you know this num_pcidevs is from tools, and actually it share
>> that result from that existing hypercall, assign_device, while parsing
>> 'pci=[]', so I couldn't understand why this can be (almost" arbitrarily
>> large.
>
> You imply well behaved tools, which you shouldn't when viewing
> things from a security perspective.
>
>>> the total number of PCI devices the hypervisor knows about.
>>
>> I take a quick look at this but looks we have no this exact value that
>> we can get directly.
>
> You need some upper bound. Whether you introduce a properly

In theory, we may have at most the number, domain(16bit) x bus(8bit) x 
device(5bit) x function(3bit), 2^16 x 2^8 x 2^5 x 2^3 = 0x1000000, so 
could we define a macro like this,

#define PCI_DEVICES_NUM_UP 0x1000000

> maintained count or a suitable estimate thereof doesn't matter.
>
>>>> --- 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 */

[snip]

>
> I really didn't necessarily mean individual comments - one for the whole
> group would suffice.
>
> Also I don't think pci_force is really the right name - all_pcidevs or
> some such would seem more suitable following the entire series.
> And finally, I'm generally advocating for avoiding redundant data
> items - I'm sure this "all" notion can be encoded reasonable with
> just the other two field (and a suitable checking macro).

Yeah.

>

Are you saying this way?

#define PCI_DEVS_NUM_UP 0x1000000
#define ALL_PCI_DEVS    (0x1 << 31)

#define is_all_pcidevs(d)  ((d)->arch.hvm_domain.num_pcidevs & ALL_PCI_DEVS)
#define is_valid_pcidevs_num(d)  \
     ((d)->arch.hvm_domain.num_pcidevs <= PCI_DEVS_NUM_UP)

     /*
      * num_pcidevs:
      * bit31 indicates if all devices need to be checked/reserved
      * Reserved Device Memory.
      * bit30 ~ bit25 are reserved now.
      * bit24 ~ bit0 represent actually how many pci devices we
      * need to check/reserve Reserved Device Memory. They are
      * valid just when bit31 is zero.
      *
      * pcidevs represent these pci device instances associated to
      * bit42 ~ bit0.
      */
     uint32_t                num_pcidevs;
     struct xen_guest_pcidev_info      *pcidevs;

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 Dec 09 02:38:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 02:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyAgn-0000va-Vt; Tue, 09 Dec 2014 02:38:13 +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 1XyAgm-0000vV-Tl
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 02:38:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1D/AE-15461-49066845; Tue, 09 Dec 2014 02:38:12 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418092690!14220949!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 25570 invoked from network); 9 Dec 2014 02:38:11 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-21.messagelabs.com with SMTP;
	9 Dec 2014 02:38:11 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 08 Dec 2014 18:38:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,542,1413270000"; d="scan'208";a="634757269"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.208])
	([10.238.128.208])
	by fmsmga001.fm.intel.com with ESMTP; 08 Dec 2014 18:38:08 -0800
Message-ID: <5486608F.1050700@intel.com>
Date: Tue, 09 Dec 2014 10:38: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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<54808CC3020000780004CCC8@mail.emea.novell.com>
	<54853FE3.9030703@intel.com>
	<548572B5020000780004D9BC@mail.emea.novell.com>
In-Reply-To: <548572B5020000780004D9BC@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/8 16:43, Jan Beulich wrote:
>>>> On 08.12.14 at 07:06, <tiejun.chen@intel.com> wrote:
>> On 2014/12/4 23:33, Jan Beulich wrote:
>>>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>> Looks this could be fine,
>>
>> d->arch.hvm_domain.pci_force = xdsr->flags & PCI_DEV_RDM_CHECK;
>
> Which is correct only because PCI_DEV_RDM_CHECK happens to be
> 1. Such hidden dependencies shouldn't be introduced though, in
> particular to avoid others then cloning the code for a flag that's not
> 1. The canonical form (found in many places throughout the treei

Right.

>
>      d->arch.hvm_domain.pci_force = !!(xdsr->flags & PCI_DEV_RDM_CHECK);

Fixed.

>
>>>> +        d->arch.hvm_domain.pcidevs = NULL;
>>>> +
>>>> +        if ( xdsr->num_pcidevs )
>>>> +        {
>>>> +            pcidevs = xmalloc_array(xen_guest_pcidev_info_t,
>>>> +                                    xdsr->num_pcidevs);
>>>
>>> New domctl-s must not represent security risks: xdsr->num_pcidevs
>>> can be (almost) arbitrarily large - do you really want to allow such
>>> huge allocations? A reasonable upper bound could for example be
>>
>> Sorry, as you know this num_pcidevs is from tools, and actually it share
>> that result from that existing hypercall, assign_device, while parsing
>> 'pci=[]', so I couldn't understand why this can be (almost" arbitrarily
>> large.
>
> You imply well behaved tools, which you shouldn't when viewing
> things from a security perspective.
>
>>> the total number of PCI devices the hypervisor knows about.
>>
>> I take a quick look at this but looks we have no this exact value that
>> we can get directly.
>
> You need some upper bound. Whether you introduce a properly

In theory, we may have at most the number, domain(16bit) x bus(8bit) x 
device(5bit) x function(3bit), 2^16 x 2^8 x 2^5 x 2^3 = 0x1000000, so 
could we define a macro like this,

#define PCI_DEVICES_NUM_UP 0x1000000

> maintained count or a suitable estimate thereof doesn't matter.
>
>>>> --- 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 */

[snip]

>
> I really didn't necessarily mean individual comments - one for the whole
> group would suffice.
>
> Also I don't think pci_force is really the right name - all_pcidevs or
> some such would seem more suitable following the entire series.
> And finally, I'm generally advocating for avoiding redundant data
> items - I'm sure this "all" notion can be encoded reasonable with
> just the other two field (and a suitable checking macro).

Yeah.

>

Are you saying this way?

#define PCI_DEVS_NUM_UP 0x1000000
#define ALL_PCI_DEVS    (0x1 << 31)

#define is_all_pcidevs(d)  ((d)->arch.hvm_domain.num_pcidevs & ALL_PCI_DEVS)
#define is_valid_pcidevs_num(d)  \
     ((d)->arch.hvm_domain.num_pcidevs <= PCI_DEVS_NUM_UP)

     /*
      * num_pcidevs:
      * bit31 indicates if all devices need to be checked/reserved
      * Reserved Device Memory.
      * bit30 ~ bit25 are reserved now.
      * bit24 ~ bit0 represent actually how many pci devices we
      * need to check/reserve Reserved Device Memory. They are
      * valid just when bit31 is zero.
      *
      * pcidevs represent these pci device instances associated to
      * bit42 ~ bit0.
      */
     uint32_t                num_pcidevs;
     struct xen_guest_pcidev_info      *pcidevs;

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 Dec 09 02:52:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 02:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyAuS-0001Ya-Ik; Tue, 09 Dec 2014 02:52:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XyAuQ-0001YV-NZ
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 02:52:18 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	12/4A-26858-1E366845; Tue, 09 Dec 2014 02:52:17 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418093533!11882114!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12704 invoked from network); 9 Dec 2014 02:52:16 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 02:52:16 -0000
Received: from 172.24.2.119 (EHLO szxema411-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AYK46500; Tue, 09 Dec 2014 10:52:03 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.62]) by
	szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id
	14.03.0158.001; Tue, 9 Dec 2014 10:51:56 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIABdSnQgAA8hYCABNK9gP//un4AABZULrD//4uJAP/+or6A
Date: Tue, 9 Dec 2014 02:51:55 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2394DA29@SZXEMA512-MBX.china.huawei.com>
References: <20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
	<20141208101304.GB17128@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394C523@SZXEMA512-MBX.china.huawei.com>
	<20141208135534.GA21374@zion.uk.xensource.com>
In-Reply-To: <20141208135534.GA21374@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020205.548663D4.006C, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.62,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2c17022d9804b70b5280b9a23b4c1bed
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Mon, Dec 08, 2014 at 01:08:18PM +0000, Zhangleiqiang (Trump) wrote:
> > > On Mon, Dec 08, 2014 at 06:44:26AM +0000, Zhangleiqiang (Trump) wrote:
> > > > > On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump)
> wrote:
> > > > > [...]
> > > >
> > > > The newest mail about persistent grant I can find is sent from 16
> > > > Nov
> > > > 2012
> > > > (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00832.html).
> > > > Why is it not done right and not merged into upstream?
> > >
> > > AFAICT there's one more memcpy than necessary, i.e. frontend memcpy
> > > data into the pool then backend memcpy data out of the pool, when
> > > backend should be able to use the page in pool directly.
> >
> > Memcpy should cheaper than grant_copy because the former needs not the
> > "hypercall" which will cause "VM Exit" to "XEN Hypervisor", am I
> > right? For RX path, using memcpy based on persistent grant table may
> > have higher performance than using grant copy now.
> 
> In theory yes. Unfortunately nobody has benchmarked that properly.
> 
> If you're interested in doing work on optimising RX performance, you might
> want to sync up with XenServer folks?

What is the recommended way to have a discussion with XenServer folks? Through the forum of XenServer or the standalone mailing list? I find the most of discussions in forum are the production of XenServer.

> >
> > I have seen "move grant copy to guest" and "Fix grant copy alignment
> > problem" as optimization methods used in "NetChannel2"
> >
> (http://www-archive.xenproject.org/files/xensummit_fall07/16_JoseRenatoSa
> ntos.pdf).
> > Unfortunately, NetChannel2 seems not be supported from 2.6.32. Do you
> > know them and are them be helpful for RX path optimization under
> > current upstream implementation?
> 
> Not sure, that's long before I ever started working on Xen.
> 
> >
> > By the way, after rethinking the testing results for multi-queue pv
> > (kernel 3.17.4+XEN 4.4) implementation, I find that when using four
> > queues for netback/netfront, there will be about 3 netback process
> > running with high CPU usage on receive Dom0 (about 85% usage per
> > process running on one CPU core), and the aggregate throughout is only
> > about 5Gbps. I doubt that there may be some bug or pitfall in current
> > multi-queue implementation, because for 5Gbps throughout, occurring
> > about all of 3 CPU core for packet receiving is somehow abnormal.
> >
> 
> 3.17.4 doesn't contain David Vrabel's fixes.
> 
> Look for
>   bc96f648df1bbc2729abbb84513cf4f64273a1f1
>   f48da8b14d04ca87ffcffe68829afd45f926ec6a
>   ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e
> in David Miller's net tree.
> 
> BTW there are some improvement planned for 4.6: "[Xen-devel] [PATCH v3 0/2]
> gnttab: Improve scaleability". This is orthogonal to the problem you're trying to
> solve but it should help improve performance in general.

Thanks for your pointer, it is helpful.

> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 02:52:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 02:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyAuS-0001Ya-Ik; Tue, 09 Dec 2014 02:52:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XyAuQ-0001YV-NZ
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 02:52:18 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	12/4A-26858-1E366845; Tue, 09 Dec 2014 02:52:17 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418093533!11882114!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12704 invoked from network); 9 Dec 2014 02:52:16 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 02:52:16 -0000
Received: from 172.24.2.119 (EHLO szxema411-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AYK46500; Tue, 09 Dec 2014 10:52:03 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.62]) by
	szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id
	14.03.0158.001; Tue, 9 Dec 2014 10:51:56 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIABdSnQgAA8hYCABNK9gP//un4AABZULrD//4uJAP/+or6A
Date: Tue, 9 Dec 2014 02:51:55 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2394DA29@SZXEMA512-MBX.china.huawei.com>
References: <20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
	<20141208101304.GB17128@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394C523@SZXEMA512-MBX.china.huawei.com>
	<20141208135534.GA21374@zion.uk.xensource.com>
In-Reply-To: <20141208135534.GA21374@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020205.548663D4.006C, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.62,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2c17022d9804b70b5280b9a23b4c1bed
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Mon, Dec 08, 2014 at 01:08:18PM +0000, Zhangleiqiang (Trump) wrote:
> > > On Mon, Dec 08, 2014 at 06:44:26AM +0000, Zhangleiqiang (Trump) wrote:
> > > > > On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump)
> wrote:
> > > > > [...]
> > > >
> > > > The newest mail about persistent grant I can find is sent from 16
> > > > Nov
> > > > 2012
> > > > (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00832.html).
> > > > Why is it not done right and not merged into upstream?
> > >
> > > AFAICT there's one more memcpy than necessary, i.e. frontend memcpy
> > > data into the pool then backend memcpy data out of the pool, when
> > > backend should be able to use the page in pool directly.
> >
> > Memcpy should cheaper than grant_copy because the former needs not the
> > "hypercall" which will cause "VM Exit" to "XEN Hypervisor", am I
> > right? For RX path, using memcpy based on persistent grant table may
> > have higher performance than using grant copy now.
> 
> In theory yes. Unfortunately nobody has benchmarked that properly.
> 
> If you're interested in doing work on optimising RX performance, you might
> want to sync up with XenServer folks?

What is the recommended way to have a discussion with XenServer folks? Through the forum of XenServer or the standalone mailing list? I find the most of discussions in forum are the production of XenServer.

> >
> > I have seen "move grant copy to guest" and "Fix grant copy alignment
> > problem" as optimization methods used in "NetChannel2"
> >
> (http://www-archive.xenproject.org/files/xensummit_fall07/16_JoseRenatoSa
> ntos.pdf).
> > Unfortunately, NetChannel2 seems not be supported from 2.6.32. Do you
> > know them and are them be helpful for RX path optimization under
> > current upstream implementation?
> 
> Not sure, that's long before I ever started working on Xen.
> 
> >
> > By the way, after rethinking the testing results for multi-queue pv
> > (kernel 3.17.4+XEN 4.4) implementation, I find that when using four
> > queues for netback/netfront, there will be about 3 netback process
> > running with high CPU usage on receive Dom0 (about 85% usage per
> > process running on one CPU core), and the aggregate throughout is only
> > about 5Gbps. I doubt that there may be some bug or pitfall in current
> > multi-queue implementation, because for 5Gbps throughout, occurring
> > about all of 3 CPU core for packet receiving is somehow abnormal.
> >
> 
> 3.17.4 doesn't contain David Vrabel's fixes.
> 
> Look for
>   bc96f648df1bbc2729abbb84513cf4f64273a1f1
>   f48da8b14d04ca87ffcffe68829afd45f926ec6a
>   ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e
> in David Miller's net tree.
> 
> BTW there are some improvement planned for 4.6: "[Xen-devel] [PATCH v3 0/2]
> gnttab: Improve scaleability". This is orthogonal to the problem you're trying to
> solve but it should help improve performance in general.

Thanks for your pointer, it is helpful.

> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 04:41:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 04: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 1XyCb6-0004LN-PI; Tue, 09 Dec 2014 04:40:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.kilari@gmail.com>) id 1XyCb4-0004LI-Mt
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 04:40:26 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	D5/6D-02954-93D76845; Tue, 09 Dec 2014 04:40:25 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418100023!13782810!1
X-Originating-IP: [209.85.223.180]
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 32622 invoked from network); 9 Dec 2014 04:40:24 -0000
Received: from mail-ie0-f180.google.com (HELO mail-ie0-f180.google.com)
	(209.85.223.180)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 04:40:24 -0000
Received: by mail-ie0-f180.google.com with SMTP id rp18so5936098iec.11
	for <xen-devel@lists.xen.org>; Mon, 08 Dec 2014 20:40:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:cc:subject:date:message-id;
	bh=qhyThZIIOcIm848i6lzeeW6slnP8LfRTHQRfaGdtnBA=;
	b=WYLSP1CcXEYJXPvKRfEp4fan5AOv7aeCBn15eO/9qlZ0bwdtL4piyPAOgWiUfkGOcs
	KOuYZFHO+aTs+Puu2ZnTSCo98qDHDIskWXfFuYTKcaRaaLpV0szveJavxqrbdefYLRSG
	rSnhC5KCT3jVTcmwZxmQKCSeogDoGDOXn70a6r2TV6WSEfUJH4Ax32Izg5ONtCSbjYWo
	/05lwKE2Xhf6/OeVVylXbOVOuHujvy4E+ZGK7LcMwQ97QyywNacQ42rCIbuuXv8YiUWh
	ntK5dWBmrnzGDlO2A0Zi8lV+g1ZtTsnZzu9/CziJWWo4fOxOO08oCTzAxv8Yv1HAPG0z
	niYA==
X-Received: by 10.50.119.195 with SMTP id kw3mr594658igb.5.1418100023471;
	Mon, 08 Dec 2014 20:40:23 -0800 (PST)
Received: from cavium-Vostro-2520.hil-sjccahw.sjc.wayport.net
	(ip-64-134-223-126.public.wayport.net. [64.134.223.126])
	by mx.google.com with ESMTPSA id ik2sm368069igb.9.2014.12.08.20.40.22
	for <multiple recipients>
	(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 08 Dec 2014 20:40:23 -0800 (PST)
From: vijay.kilari@gmail.com
To: Ian.Campbell@citrix.com, julien.grall@linaro.org,
	stefano.stabellini@eu.citrix.com, stefano.stabellini@citrix.com,
	tim@xen.org, xen-devel@lists.xen.org
Date: Tue,  9 Dec 2014 10:09:55 +0530
Message-Id: <1418099995-22777-1-git-send-email-vijay.kilari@gmail.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Prasun.Kapoor@caviumnetworks.com, manish.jaggi@caviumnetworks.com,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, vijay.kilari@gmail.com
Subject: [Xen-devel] [PATCH v1] xen/arm: Manage pl011 uart TX interrupt
	correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>

In pl011.c, when TX interrupt is received
serial_tx_interrupt() is called to push next
characters. If TX buffer is empty, serial_tx_interrupt()
does not disable TX interrupt and hence pl011 UART
irq handler pl011_interrupt() always sees TX interrupt
status set in MIS register and cpu does not come out of
UART irq handler.

With this patch, mask TX interrupt by writing 0 to
IMSC register when TX buffer is empty and unmask by
writing 1 to IMSC register before sending characters.

Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
---
 xen/drivers/char/pl011.c  |   16 ++++++++++++++++
 xen/drivers/char/serial.c |   34 ++++++++++++++++++++++++++++++++++
 xen/include/xen/serial.h  |    4 ++++
 3 files changed, 54 insertions(+)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..57274d9 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -197,6 +197,20 @@ static const struct vuart_info *pl011_vuart(struct serial_port *port)
     return &uart->vuart;
 }
 
+static void pl011_tx_stop(struct serial_port *port)
+{
+    struct pl011 *uart = port->uart;
+
+    pl011_write(uart, IMSC, pl011_read(uart, IMSC) & ~(TXI));
+}
+
+static void pl011_tx_start(struct serial_port *port)
+{
+    struct pl011 *uart = port->uart;
+
+    pl011_write(uart, IMSC, pl011_read(uart, IMSC) | (TXI));
+}
+
 static struct uart_driver __read_mostly pl011_driver = {
     .init_preirq  = pl011_init_preirq,
     .init_postirq = pl011_init_postirq,
@@ -207,6 +221,8 @@ static struct uart_driver __read_mostly pl011_driver = {
     .putc         = pl011_putc,
     .getc         = pl011_getc,
     .irq          = pl011_irq,
+    .start_tx     = pl011_tx_start,
+    .stop_tx      = pl011_tx_stop,
     .vuart_info   = pl011_vuart,
 };
 
diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
index 44026b1..c583a48 100644
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -31,6 +31,18 @@ static struct serial_port com[SERHND_IDX + 1] = {
 
 static bool_t __read_mostly post_irq;
 
+static inline void serial_start_tx(struct serial_port *port)
+{
+    if ( port->driver->start_tx != NULL )
+        port->driver->start_tx(port);
+}
+
+static inline void serial_stop_tx(struct serial_port *port)
+{
+    if ( port->driver->stop_tx != NULL )
+        port->driver->stop_tx(port);
+}
+
 void serial_rx_interrupt(struct serial_port *port, struct cpu_user_regs *regs)
 {
     char c;
@@ -76,6 +88,18 @@ void serial_tx_interrupt(struct serial_port *port, struct cpu_user_regs *regs)
         cpu_relax();
     }
 
+    if ( port->txbufc == port->txbufp )
+    {
+        /* Disable TX. nothing to send */
+        serial_stop_tx(port);
+        spin_unlock(&port->tx_lock);
+        goto out;
+    }
+    else
+    {
+        if ( port->driver->tx_ready(port) )
+            serial_start_tx(port);
+    }
     for ( i = 0, n = port->driver->tx_ready(port); i < n; i++ )
     {
         if ( port->txbufc == port->txbufp )
@@ -117,6 +141,8 @@ static void __serial_putc(struct serial_port *port, char c)
                     cpu_relax();
                 if ( n > 0 )
                 {
+                    /* Enable TX before sending chars */
+                    serial_start_tx(port);
                     while ( n-- )
                         port->driver->putc(
                             port,
@@ -135,6 +161,8 @@ static void __serial_putc(struct serial_port *port, char c)
         if ( ((port->txbufp - port->txbufc) == 0) &&
              port->driver->tx_ready(port) > 0 )
         {
+            /* Enable TX before sending chars */
+            serial_start_tx(port);
             /* Buffer and UART FIFO are both empty, and port is available. */
             port->driver->putc(port, c);
         }
@@ -152,11 +180,16 @@ static void __serial_putc(struct serial_port *port, char c)
         while ( !(n = port->driver->tx_ready(port)) )
             cpu_relax();
         if ( n > 0 )
+        {
+            /* Enable TX before sending chars */
+            serial_start_tx(port);
             port->driver->putc(port, c);
+        }
     }
     else
     {
         /* Simple synchronous transmitter. */
+        serial_start_tx(port);
         port->driver->putc(port, c);
     }
 }
@@ -404,6 +437,7 @@ void serial_start_sync(int handle)
                 /* port is unavailable and might not come up until reenabled by
                    dom0, we can't really do proper sync */
                 break;
+            serial_start_tx(port);
             port->driver->putc(
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);
         }
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 9f4451b..71e6ade 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -81,6 +81,10 @@ struct uart_driver {
     int  (*getc)(struct serial_port *, char *);
     /* Get IRQ number for this port's serial line: returns -1 if none. */
     int  (*irq)(struct serial_port *);
+    /* Unmask TX interrupt */
+    void  (*start_tx)(struct serial_port *);
+    /* Mask TX interrupt */
+    void  (*stop_tx)(struct serial_port *);
     /* Get serial information */
     const struct vuart_info *(*vuart_info)(struct serial_port *);
 };
-- 
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 Dec 09 04:41:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 04: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 1XyCb6-0004LN-PI; Tue, 09 Dec 2014 04:40:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.kilari@gmail.com>) id 1XyCb4-0004LI-Mt
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 04:40:26 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	D5/6D-02954-93D76845; Tue, 09 Dec 2014 04:40:25 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418100023!13782810!1
X-Originating-IP: [209.85.223.180]
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 32622 invoked from network); 9 Dec 2014 04:40:24 -0000
Received: from mail-ie0-f180.google.com (HELO mail-ie0-f180.google.com)
	(209.85.223.180)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 04:40:24 -0000
Received: by mail-ie0-f180.google.com with SMTP id rp18so5936098iec.11
	for <xen-devel@lists.xen.org>; Mon, 08 Dec 2014 20:40:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:cc:subject:date:message-id;
	bh=qhyThZIIOcIm848i6lzeeW6slnP8LfRTHQRfaGdtnBA=;
	b=WYLSP1CcXEYJXPvKRfEp4fan5AOv7aeCBn15eO/9qlZ0bwdtL4piyPAOgWiUfkGOcs
	KOuYZFHO+aTs+Puu2ZnTSCo98qDHDIskWXfFuYTKcaRaaLpV0szveJavxqrbdefYLRSG
	rSnhC5KCT3jVTcmwZxmQKCSeogDoGDOXn70a6r2TV6WSEfUJH4Ax32Izg5ONtCSbjYWo
	/05lwKE2Xhf6/OeVVylXbOVOuHujvy4E+ZGK7LcMwQ97QyywNacQ42rCIbuuXv8YiUWh
	ntK5dWBmrnzGDlO2A0Zi8lV+g1ZtTsnZzu9/CziJWWo4fOxOO08oCTzAxv8Yv1HAPG0z
	niYA==
X-Received: by 10.50.119.195 with SMTP id kw3mr594658igb.5.1418100023471;
	Mon, 08 Dec 2014 20:40:23 -0800 (PST)
Received: from cavium-Vostro-2520.hil-sjccahw.sjc.wayport.net
	(ip-64-134-223-126.public.wayport.net. [64.134.223.126])
	by mx.google.com with ESMTPSA id ik2sm368069igb.9.2014.12.08.20.40.22
	for <multiple recipients>
	(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 08 Dec 2014 20:40:23 -0800 (PST)
From: vijay.kilari@gmail.com
To: Ian.Campbell@citrix.com, julien.grall@linaro.org,
	stefano.stabellini@eu.citrix.com, stefano.stabellini@citrix.com,
	tim@xen.org, xen-devel@lists.xen.org
Date: Tue,  9 Dec 2014 10:09:55 +0530
Message-Id: <1418099995-22777-1-git-send-email-vijay.kilari@gmail.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Prasun.Kapoor@caviumnetworks.com, manish.jaggi@caviumnetworks.com,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, vijay.kilari@gmail.com
Subject: [Xen-devel] [PATCH v1] xen/arm: Manage pl011 uart TX interrupt
	correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>

In pl011.c, when TX interrupt is received
serial_tx_interrupt() is called to push next
characters. If TX buffer is empty, serial_tx_interrupt()
does not disable TX interrupt and hence pl011 UART
irq handler pl011_interrupt() always sees TX interrupt
status set in MIS register and cpu does not come out of
UART irq handler.

With this patch, mask TX interrupt by writing 0 to
IMSC register when TX buffer is empty and unmask by
writing 1 to IMSC register before sending characters.

Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
---
 xen/drivers/char/pl011.c  |   16 ++++++++++++++++
 xen/drivers/char/serial.c |   34 ++++++++++++++++++++++++++++++++++
 xen/include/xen/serial.h  |    4 ++++
 3 files changed, 54 insertions(+)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..57274d9 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -197,6 +197,20 @@ static const struct vuart_info *pl011_vuart(struct serial_port *port)
     return &uart->vuart;
 }
 
+static void pl011_tx_stop(struct serial_port *port)
+{
+    struct pl011 *uart = port->uart;
+
+    pl011_write(uart, IMSC, pl011_read(uart, IMSC) & ~(TXI));
+}
+
+static void pl011_tx_start(struct serial_port *port)
+{
+    struct pl011 *uart = port->uart;
+
+    pl011_write(uart, IMSC, pl011_read(uart, IMSC) | (TXI));
+}
+
 static struct uart_driver __read_mostly pl011_driver = {
     .init_preirq  = pl011_init_preirq,
     .init_postirq = pl011_init_postirq,
@@ -207,6 +221,8 @@ static struct uart_driver __read_mostly pl011_driver = {
     .putc         = pl011_putc,
     .getc         = pl011_getc,
     .irq          = pl011_irq,
+    .start_tx     = pl011_tx_start,
+    .stop_tx      = pl011_tx_stop,
     .vuart_info   = pl011_vuart,
 };
 
diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
index 44026b1..c583a48 100644
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -31,6 +31,18 @@ static struct serial_port com[SERHND_IDX + 1] = {
 
 static bool_t __read_mostly post_irq;
 
+static inline void serial_start_tx(struct serial_port *port)
+{
+    if ( port->driver->start_tx != NULL )
+        port->driver->start_tx(port);
+}
+
+static inline void serial_stop_tx(struct serial_port *port)
+{
+    if ( port->driver->stop_tx != NULL )
+        port->driver->stop_tx(port);
+}
+
 void serial_rx_interrupt(struct serial_port *port, struct cpu_user_regs *regs)
 {
     char c;
@@ -76,6 +88,18 @@ void serial_tx_interrupt(struct serial_port *port, struct cpu_user_regs *regs)
         cpu_relax();
     }
 
+    if ( port->txbufc == port->txbufp )
+    {
+        /* Disable TX. nothing to send */
+        serial_stop_tx(port);
+        spin_unlock(&port->tx_lock);
+        goto out;
+    }
+    else
+    {
+        if ( port->driver->tx_ready(port) )
+            serial_start_tx(port);
+    }
     for ( i = 0, n = port->driver->tx_ready(port); i < n; i++ )
     {
         if ( port->txbufc == port->txbufp )
@@ -117,6 +141,8 @@ static void __serial_putc(struct serial_port *port, char c)
                     cpu_relax();
                 if ( n > 0 )
                 {
+                    /* Enable TX before sending chars */
+                    serial_start_tx(port);
                     while ( n-- )
                         port->driver->putc(
                             port,
@@ -135,6 +161,8 @@ static void __serial_putc(struct serial_port *port, char c)
         if ( ((port->txbufp - port->txbufc) == 0) &&
              port->driver->tx_ready(port) > 0 )
         {
+            /* Enable TX before sending chars */
+            serial_start_tx(port);
             /* Buffer and UART FIFO are both empty, and port is available. */
             port->driver->putc(port, c);
         }
@@ -152,11 +180,16 @@ static void __serial_putc(struct serial_port *port, char c)
         while ( !(n = port->driver->tx_ready(port)) )
             cpu_relax();
         if ( n > 0 )
+        {
+            /* Enable TX before sending chars */
+            serial_start_tx(port);
             port->driver->putc(port, c);
+        }
     }
     else
     {
         /* Simple synchronous transmitter. */
+        serial_start_tx(port);
         port->driver->putc(port, c);
     }
 }
@@ -404,6 +437,7 @@ void serial_start_sync(int handle)
                 /* port is unavailable and might not come up until reenabled by
                    dom0, we can't really do proper sync */
                 break;
+            serial_start_tx(port);
             port->driver->putc(
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);
         }
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 9f4451b..71e6ade 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -81,6 +81,10 @@ struct uart_driver {
     int  (*getc)(struct serial_port *, char *);
     /* Get IRQ number for this port's serial line: returns -1 if none. */
     int  (*irq)(struct serial_port *);
+    /* Unmask TX interrupt */
+    void  (*start_tx)(struct serial_port *);
+    /* Mask TX interrupt */
+    void  (*stop_tx)(struct serial_port *);
     /* Get serial information */
     const struct vuart_info *(*vuart_info)(struct serial_port *);
 };
-- 
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 Dec 09 04:44:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 04: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 1XyCec-0004gx-Dt; Tue, 09 Dec 2014 04: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.Jackson@citrix.com>) id 1XyCea-0004gr-S2
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 04:44:05 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	CD/A6-20609-41E76845; Tue, 09 Dec 2014 04:44:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418100242!13832091!1
X-Originating-IP: [66.165.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 22407 invoked from network); 9 Dec 2014 04:44:03 -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;
	9 Dec 2014 04:44:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,542,1413244800"; d="scan'208";a="202123598"
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.210.2; Mon, 8 Dec 2014 23:43: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 1XyCeS-00078O-9D;
	Tue, 09 Dec 2014 04:43:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyCeS-0000eM-2s;
	Tue, 09 Dec 2014 04:43:56 +0000
Date: Tue, 9 Dec 2014 04:43:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32149-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 17818
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 32149: 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="===============7162750112060972432=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7162750112060972432==
Content-Type: text/plain
Content-Length: 17723
Content-Transfer-Encoding: quoted-printable

flight 32149 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32149/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail pass in 32131
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 32131
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot   fail in 32131 pass in 32149
 test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail in 32131 pass in 32149

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31838

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-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-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-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-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-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-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 32131 never pass

version targeted for testing:
 linux                356a3e1fde11190febb8ace3cdab8694848ed220
baseline version:
 linux                2dc2565902d3c24108c4b7101e91957fd068a242

------------------------------------------------------------
People who touched revisions under test:
  "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
  Aaro Koskinen <aaro.koskinen@iki.fi>
  Aaro Koskinen <aaro.koskinen@nsn.com>
  Aaron Ma <mapengyu@gmail.com>
  Alan Stern <stern@rowland.harvard.edu>
  Alex Deucher <alexander.deucher@amd.com>
  Alexey Khoroshilov <khoroshilov@ispras.ru>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Gospodarek <gospo@cumulusnetworks.com>
  Andy Lutomirski <luto@amacapital.net>
  Bart Van Assche <bvanassche@acm.org>
  Ben Sagal <bensagal@gmail.com>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Benjamin LaHaise <bcrl@kvack.org>
  Binyamin Sagal <bensagal@gmail.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bj=C3=B8rn Mork <bjorn@mork.no>
  Borislav Petkov <bp@suse.de>
  Brian Norris <computersforpeace@gmail.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Moore <chris.moore@emulex.com>
  Chris Webb <chris@arachsys.com>
  Christian S=C3=BCnkenberg <christian.suenkenberg@hfg-karlsruhe.de>
  Christoph Hellwig <hch@lst.de>
  Cong Wang <cwang@twopensource.com>
  Cong Wang <xiyou.wangcong@gmail.com>
  Cristina Ciocan <cristina.ciocan@intel.com>
  Daniel Lezcano <daniel.lezcano@linaro.org>
  Dave Hansen <dave.hansen@linux.intel.com>
  David Jeffery <djeffery@redhat.com>
  David S. Miller <davem@davemloft.net>
  Ding Tianhong <dingtianhong@huawei.com>
  Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
  Dmitry Torokhov <dmitry.torokhov@gmail.com>
  Fabio Estevam <fabio.estevam@freescale.com>
  Felipe Balbi <balbi@ti.com>
  Grant Likely <grant.likely@linaro.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Gregory CLEMENT <gregory.clement@free-electrons.com>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hans de Goede <hdegoede@redhat.com>
  Ingo Molnar <mingo@kernel.org>
  J. Bruce Fields <bfields@fieldses.org>
  J. Bruce Fields <bfields@redhat.com>
  Jane Zhou <a17711@motorola.com>
  Jason Cooper <jason@lakedaemon.net>
  Jeff Layton <jlayton@primarydata.com>
  Jeff Layton <jlayton@redhat.com>
  Jet Chen <jet.chen@intel.com>
  Jiri Bohac <jbohac@suse.cz>
  Johan Hovold <johan@kernel.org>
  John W. Linville <linville@tuxdriver.com>
  Jonathan Cameron <jic23@kernel.org>
  Jurgen Kramer <gtmkramer@xs4all.nl>
  Kamal Mostafa <kamal@canonical.com>
  Kees Cook <keescook@chromium.org>
  Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
  Larry Finger <Larry.Finger@lwfinger.net>
  Laurent Dufour <ldufour@linux.vnet.ibm.com>
  Liam Girdwood <liam.r.girdwood@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lu Baolu <baolu.lu@linux.intel.com>
  Marc Kleine-Budde <mkl@pengutronix.de>
  Mark Brown <broonie@kernel.org>
  Mark Rutland <mark.rutland@arm.com>
  Martin Hauke <mardnh@gmx.de>
  Mathias Krause <minipli@googlemail.com>
  Mathias Nyman <mathias.nyman@linux.intel.com>
  Matthias Fuchs <matthias.fuchs@esd.eu>
  Maurizio Lombardi <mlombard@redhat.com>
  Maxime Coquelin <maxime.coquelin@st.com>
  Maxime Ripard <maxime.ripard@free-electrons.com>
  Miaoqing Pan <miaoqing@qca.qualcomm.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Nadav Haklai <nadavh@marvell.com>
  Nicholas Bellinger <nab@linux-iscsi.org>
  Nikolay Aleksandrov <nikolay@redhat.com>
  Or Gerlitz <ogerlitz@mellanox.com>
  Panu Matilainen <pmatilai@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Preston Fick <pffick@gmail.com>
  Ralf Baechle <ralf@linux-mips.org>
  Rob Herring <robh@kernel.org>
  Robert Jarzmik <robert.jarzmik@free.fr>
  Roland Dreier <roland@purestorage.com>
  Russell King <rmk+kernel@arm.linux.org.uk>
  Sagi Grimberg <sagig@dev.mellanox.co.il>
  Sagi Grimberg <sagig@mellanox.com>
  Srikar Dronamraju <srikar@linux.vnet.ibm.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Sujith Manoharan <c_manoha@qca.qualcomm.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Gleixner <tglx@linutronix.de>
  Thomas K=C3=B6rper <thomas.koerper@esd.eu>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Thor Thayer <tthayer@opensource.altera.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Troy Clark <tclark@matrixorbital.ca>
  Veaceslav Falico <vfalico@gmail.com>
  Vincent BENAYOUN <vincent.benayoun@trust-in-soft.com>
  Vladimir Murzin <vladimir.murzin@arm.com>
  Vlastimil Setka <setka@vsis.cz>
  Will Deacon <will.deacon@arm.com>
  Yinghai Lu <yinghai@kernel.org>
  Yiwei Zhao <gbjc64@motorola.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                                          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-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=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlinux-3.14
+ revision=3D356a3e1fde11190febb8ace3cdab8694848ed220
+ . 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 linux-3.14 356a3e1fde11190febb8ace3cdab8694848ed220
+ branch=3Dlinux-3.14
+ revision=3D356a3e1fde11190febb8ace3cdab8694848ed220
+ . 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=3Dlinux
+ xenbranch=3Dxen-unstable
+ '[' xlinux =3D xlinux ']'
+ linuxbranch=3Dlinux-3.14
+ '[' 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://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git =3D x ']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git =3D 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=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 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 356a3e1fde11190febb8ace3cdab8694848ed220:tested/linux-3.14
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   2dc2565..356a3e1  356a3e1fde11190febb8ace3cdab8694848ed220 -> tested/linux-3.14
+ exit 0


--===============7162750112060972432==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7162750112060972432==--

From xen-devel-bounces@lists.xen.org Tue Dec 09 04:44:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 04: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 1XyCec-0004gx-Dt; Tue, 09 Dec 2014 04: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.Jackson@citrix.com>) id 1XyCea-0004gr-S2
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 04:44:05 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	CD/A6-20609-41E76845; Tue, 09 Dec 2014 04:44:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418100242!13832091!1
X-Originating-IP: [66.165.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 22407 invoked from network); 9 Dec 2014 04:44:03 -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;
	9 Dec 2014 04:44:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,542,1413244800"; d="scan'208";a="202123598"
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.210.2; Mon, 8 Dec 2014 23:43: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 1XyCeS-00078O-9D;
	Tue, 09 Dec 2014 04:43:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyCeS-0000eM-2s;
	Tue, 09 Dec 2014 04:43:56 +0000
Date: Tue, 9 Dec 2014 04:43:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32149-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 17818
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.14 test] 32149: 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="===============7162750112060972432=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7162750112060972432==
Content-Type: text/plain
Content-Length: 17723
Content-Transfer-Encoding: quoted-printable

flight 32149 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32149/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail pass in 32131
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 32131
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot   fail in 32131 pass in 32149
 test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail in 32131 pass in 32149

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31838

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-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-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-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-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-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-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 32131 never pass

version targeted for testing:
 linux                356a3e1fde11190febb8ace3cdab8694848ed220
baseline version:
 linux                2dc2565902d3c24108c4b7101e91957fd068a242

------------------------------------------------------------
People who touched revisions under test:
  "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
  Aaro Koskinen <aaro.koskinen@iki.fi>
  Aaro Koskinen <aaro.koskinen@nsn.com>
  Aaron Ma <mapengyu@gmail.com>
  Alan Stern <stern@rowland.harvard.edu>
  Alex Deucher <alexander.deucher@amd.com>
  Alexey Khoroshilov <khoroshilov@ispras.ru>
  Andrew Morton <akpm@linux-foundation.org>
  Andy Gospodarek <gospo@cumulusnetworks.com>
  Andy Lutomirski <luto@amacapital.net>
  Bart Van Assche <bvanassche@acm.org>
  Ben Sagal <bensagal@gmail.com>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Benjamin LaHaise <bcrl@kvack.org>
  Binyamin Sagal <bensagal@gmail.com>
  Bjorn Helgaas <bhelgaas@google.com>
  Bj=C3=B8rn Mork <bjorn@mork.no>
  Borislav Petkov <bp@suse.de>
  Brian Norris <computersforpeace@gmail.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
  Chris J Arges <chris.j.arges@canonical.com>
  Chris Moore <chris.moore@emulex.com>
  Chris Webb <chris@arachsys.com>
  Christian S=C3=BCnkenberg <christian.suenkenberg@hfg-karlsruhe.de>
  Christoph Hellwig <hch@lst.de>
  Cong Wang <cwang@twopensource.com>
  Cong Wang <xiyou.wangcong@gmail.com>
  Cristina Ciocan <cristina.ciocan@intel.com>
  Daniel Lezcano <daniel.lezcano@linaro.org>
  Dave Hansen <dave.hansen@linux.intel.com>
  David Jeffery <djeffery@redhat.com>
  David S. Miller <davem@davemloft.net>
  Ding Tianhong <dingtianhong@huawei.com>
  Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
  Dmitry Torokhov <dmitry.torokhov@gmail.com>
  Fabio Estevam <fabio.estevam@freescale.com>
  Felipe Balbi <balbi@ti.com>
  Grant Likely <grant.likely@linaro.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Gregory CLEMENT <gregory.clement@free-electrons.com>
  Gu Zheng <guz.fnst@cn.fujitsu.com>
  Hans de Goede <hdegoede@redhat.com>
  Ingo Molnar <mingo@kernel.org>
  J. Bruce Fields <bfields@fieldses.org>
  J. Bruce Fields <bfields@redhat.com>
  Jane Zhou <a17711@motorola.com>
  Jason Cooper <jason@lakedaemon.net>
  Jeff Layton <jlayton@primarydata.com>
  Jeff Layton <jlayton@redhat.com>
  Jet Chen <jet.chen@intel.com>
  Jiri Bohac <jbohac@suse.cz>
  Johan Hovold <johan@kernel.org>
  John W. Linville <linville@tuxdriver.com>
  Jonathan Cameron <jic23@kernel.org>
  Jurgen Kramer <gtmkramer@xs4all.nl>
  Kamal Mostafa <kamal@canonical.com>
  Kees Cook <keescook@chromium.org>
  Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
  Larry Finger <Larry.Finger@lwfinger.net>
  Laurent Dufour <ldufour@linux.vnet.ibm.com>
  Liam Girdwood <liam.r.girdwood@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lu Baolu <baolu.lu@linux.intel.com>
  Marc Kleine-Budde <mkl@pengutronix.de>
  Mark Brown <broonie@kernel.org>
  Mark Rutland <mark.rutland@arm.com>
  Martin Hauke <mardnh@gmx.de>
  Mathias Krause <minipli@googlemail.com>
  Mathias Nyman <mathias.nyman@linux.intel.com>
  Matthias Fuchs <matthias.fuchs@esd.eu>
  Maurizio Lombardi <mlombard@redhat.com>
  Maxime Coquelin <maxime.coquelin@st.com>
  Maxime Ripard <maxime.ripard@free-electrons.com>
  Miaoqing Pan <miaoqing@qca.qualcomm.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Nadav Haklai <nadavh@marvell.com>
  Nicholas Bellinger <nab@linux-iscsi.org>
  Nikolay Aleksandrov <nikolay@redhat.com>
  Or Gerlitz <ogerlitz@mellanox.com>
  Panu Matilainen <pmatilai@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Zijlstra (Intel) <peterz@infradead.org>
  Preston Fick <pffick@gmail.com>
  Ralf Baechle <ralf@linux-mips.org>
  Rob Herring <robh@kernel.org>
  Robert Jarzmik <robert.jarzmik@free.fr>
  Roland Dreier <roland@purestorage.com>
  Russell King <rmk+kernel@arm.linux.org.uk>
  Sagi Grimberg <sagig@dev.mellanox.co.il>
  Sagi Grimberg <sagig@mellanox.com>
  Srikar Dronamraju <srikar@linux.vnet.ibm.com>
  Stanislaw Gruszka <sgruszka@redhat.com>
  Sujith Manoharan <c_manoha@qca.qualcomm.com>
  Takashi Iwai <tiwai@suse.de>
  Thomas Gleixner <tglx@linutronix.de>
  Thomas K=C3=B6rper <thomas.koerper@esd.eu>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Thor Thayer <tthayer@opensource.altera.com>
  Trond Myklebust <trond.myklebust@primarydata.com>
  Troy Clark <tclark@matrixorbital.ca>
  Veaceslav Falico <vfalico@gmail.com>
  Vincent BENAYOUN <vincent.benayoun@trust-in-soft.com>
  Vladimir Murzin <vladimir.murzin@arm.com>
  Vlastimil Setka <setka@vsis.cz>
  Will Deacon <will.deacon@arm.com>
  Yinghai Lu <yinghai@kernel.org>
  Yiwei Zhao <gbjc64@motorola.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                                          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-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=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlinux-3.14
+ revision=3D356a3e1fde11190febb8ace3cdab8694848ed220
+ . 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 linux-3.14 356a3e1fde11190febb8ace3cdab8694848ed220
+ branch=3Dlinux-3.14
+ revision=3D356a3e1fde11190febb8ace3cdab8694848ed220
+ . 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=3Dlinux
+ xenbranch=3Dxen-unstable
+ '[' xlinux =3D xlinux ']'
+ linuxbranch=3Dlinux-3.14
+ '[' 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://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git =3D x ']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git =3D 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=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 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 356a3e1fde11190febb8ace3cdab8694848ed220:tested/linux-3.14
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   2dc2565..356a3e1  356a3e1fde11190febb8ace3cdab8694848ed220 -> tested/linux-3.14
+ exit 0


--===============7162750112060972432==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7162750112060972432==--

From xen-devel-bounces@lists.xen.org Tue Dec 09 05:05:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 05: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 1XyCyg-0005bB-Kn; Tue, 09 Dec 2014 05:04: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 1XyCyf-0005b6-9Z
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 05:04:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	68/5D-09842-0F286845; Tue, 09 Dec 2014 05:04:48 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418101485!6987401!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 12383 invoked from network); 9 Dec 2014 05:04:47 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 05:04:47 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 22:04:45 -0700
Message-Id: <5486F36502000066000825D5@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 22:04:37 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
	<20141208111214.GC17128@zion.uk.xensource.com>
In-Reply-To: <20141208111214.GC17128@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Ian.Campbell@citrix.com, 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 12/8/2014 at 07:12 PM, in message
<20141208111214.GC17128@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
wrote: 
> On Mon, Dec 08, 2014 at 12:34:47AM -0700, Chun Yan Liu wrote: 
> >  
> >  
> > >>> On 12/6/2014 at 12:06 AM, in message 
> > <20141205160615.GA24938@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com> 
> > wrote:  
> > > I have to admit I'm confused by the back and forth discussion. It's hard  
> > > to justify the design of new API without knowing what the constraints  
> > > and requirements are from your PoV.  
> > >   
> > > Here are my two cents, not about details, but about general constraints.  
> > >   
> > > There are two layers, one is user of libxl (clients -- xl, libvirt etc)  
> > > and libxl (the library itself).  
> > >   
> > > 1. it's better to *not* have storage management in libxl.  
> > >   
> > > It's likely that clients can have their own management functionality  
> > > already.  I'm told that libvirt has that as well as XAPI. Having this  
> > > functionality in libxl is a bit redundant and requires lots of work  
> > > (enlighten libxl on what a disk looks like and call out to various  
> > > utilities).  
> >  
> > Thanks Wei and Ian for your reply. We did have much discussion around 
> > can/cannot (e.g. xl can finish disk snapshot?) and should/shouldnot 
> > (e.g. disk snapshot process should not in xl? domain_snapshot_delete 
> > should not in libxl?), and confusing because have different ideas. So, 
> > settling it down is helpful. 
> >  
> > Talking about libvirt, it does provide storage management but through 
> > storage pools and volumes. But usually, we don't use storage pool/vol 
> > but directly use backend files, then libvirt storage driver can not 
> > manage them. And for libvirt vol, functionality in storage driver is 
> > limited, at least 'snapshot' cannot be done. So, libvirt side also 
> > needs to add codes to handle disk snapshot, quite like xl does. 
> >  
>  
> OK, so I take it that libvirt can be completely out the picture? I mean, 
> it's not a requirement for you to integrate with libvirt? 
>  
> I was thinking a stack like this when I replied: 
>  
>   libvirt: manages snapshot (including storage snapshot) 
>   libxl 
>   [other lower level stuffs] 
>  
> While I read from your reply, libvirt doesn't have that functionality 
> (or very limited), so you would like to do things like: 
>  
>   libvirt (or your homebrew toolstack) 
>   xl      (xl or libxl manages domain snapshots) 
>   libxl 
>   [other lower level stuffs] 
>  
> That's why you spent loads of time discussing with Ian what should be 
> done where, right? 

Partly. At least for domain disk snapshot create/delete, I prefer using
qmp commands instead of calling qemu-img one by one. Using qmp
commands, libvirt will need libxl's help. Of course, if libxl doesn't
supply that, libvirt can call qemu-img to each disk one by one,
not preferred but can do.

>  
> > Following the constraint that it's better NOT to supply disk snapshot 
> > functions in libxl, then we let xl and libvirt do that by themselve 
> > separately, that's OK. 
> >  
> > Then I think NO new API needs to be exported in libxl, since: 
> > * saving/restoring memory, there are already APIs. 
>  
> The principle is that if existing API doesn't work good enough for you 
> we will consider adding a new one. 
>  
> We probably need a new API. If you want to do a live snapshot, we would 
> need to notify xl that we are in the middle of pausing and resuming a 
> domain.  

This is where we discussed a lot. Do we really need
libxl_domain_snapshot_create API? or does xl can do the work?

Even for live snapshot, after calling libxl_domain_suspend with LIVE flags,
memory is saved and domain is paused. xl then can call disk snapshot
functions to finish disk snapshots, after all of that, call libxl_domain_unpause
to unpause the domain. So I don't think xl has any trouble to do that.
In case there is some misunderstanding, please point out.

>  
> > * disk snapshot work is xl internal, can be put in xl (or xlu). 
> > * handle JSON files is xl internal, can be put in xl. 
>  
> Yes. 
>  
> > (these are the main work vm snapshot handles). 
> >  
> > Right? 
> >  
> > This is quite different from previous document, so better to confirm. 
> >  
> > >   
> > > 2. it's *not* a requirement for xl to have the capability to manage  
> > > snapshots.  
> > >   
> > > It's the same arguement that xl has no idea on how to manage snapshots  
> > > created by "xl save".  This should ease your concern on having to  
> > > duplicate code for libvirt and xl.  IMHO the xl only needs to have the  
> > > capability to create a snapshot and create a domain from a snapshot. 
> >  
> > This way it's much easier since we don't need to maintain the snapshot 
> > info in file and don't need to take care of snapshot chain. But I doubt if 
> > that's good? 
> > 1. from user's side, it's a very common request to list all snapshots. 
> > 2. now for kvm, virsh supplies snapshot-create/delete/list/revert, 
> >    Is it good the xl only supply snapshot-create/revert? After all, 
> >    it's more complicated for user to take care of memory saving file 
> >    and disk snapshot info then 'xl save' (user only needs to take 
> >    care of memory state file). 
> >  
>  
> However the current architecture for libvirt to use libxl is like 
>  
>   libvirt 
>   libxl 
>   [other lower level stuffs] 
>  
> So implementing snapshot management in xl cannot work for you either. 
> It's not part of the current architecture.

You are right. I understand you are trying to suggest a way to ease the job.
Here just to make clear this way is really better and finally acceptable? :-)
Just IMO, I think xl snapshot-list is wanted, that means managing snapshots
in xl is needed.

>  
> Not that I'm against the idea of managing domain snapshot in xl, I'm 
> trying to reduce workload here. 
>  
> > > The  
> > > downside is that now xl and libvirt are disconnected, but I think it's  
> > > fine. 
> >  
> > Two things here: 
> > 1. connect xl and libvirt, then will need to manage snapshot info in libxl  
> (or 
> >     libxlu) That's not preferred since the initial design. This is not the  
> point 
> >     we discuss here. 
> > 2. for xl only, list snapshots and delete snapshots, also need to manage 
> >     snapshot info (in xl) 
> >  
> > Considering manage snapshot info in xl, only question is about idl and 
> > gentypes.py, expected structure is as following and expected to be saved 
> > into json file, but it contains xl namespace and libxl namespace things, 
> > gentypes.py will have problem. Better ideas? 
> >  
> > typedef struct xl_domain_snapshot { 
> >     char * name; 
> >     char * description; 
> >     uint64_t creation_time; 
> >     char * memory_path; 
> >     int num_disks; 
> >     libxl_disk_snapshot *disks; 
> >     char *parent; 
> >     bool *current; 
> > } xl_domain_snapshot; 
> >  
>  
> The libxl_disk_snapshot suggests that you still want storage management 
> inside libxl, which should probably be in libxlu? 

Yeah. I may put it in libxlu. Question is the same, cross two name spaces. But
now I think we can turn a way to do it. In xl_domain_snapshot, define
xl_disk_snapshot, then before calling libxlu API, turning it into
libxlu_disk_snapshot.

Thanks for your concern and suggestions. Appreciate it a lot! 
- Chunyan

>  
>   libvirt 
>   libxl libxlu 
>   [other lower level stuffs] 
>  
> Wei. 
>  
> > Thanks a lot! 
> > Chunyan 
> >  
> > > The arguement is that you're not allowed to run two toolstack on  
> > > the same host (think about xl and xend in previous releases).  
> > >   
> > > Do these two constraints make your work easier (or harder)?  
> > >   
> > > Regarding JSON API, as Ian said, feel free to hook it up to libxlu.  
> > >   
> > > Wei.  
> > >   
> > >   
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 05:05:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 05: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 1XyCyg-0005bB-Kn; Tue, 09 Dec 2014 05:04: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 1XyCyf-0005b6-9Z
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 05:04:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	68/5D-09842-0F286845; Tue, 09 Dec 2014 05:04:48 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418101485!6987401!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 12383 invoked from network); 9 Dec 2014 05:04:47 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 05:04:47 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 08 Dec 2014 22:04:45 -0700
Message-Id: <5486F36502000066000825D5@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 08 Dec 2014 22:04:37 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
	<20141208111214.GC17128@zion.uk.xensource.com>
In-Reply-To: <20141208111214.GC17128@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Ian.Campbell@citrix.com, 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 12/8/2014 at 07:12 PM, in message
<20141208111214.GC17128@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
wrote: 
> On Mon, Dec 08, 2014 at 12:34:47AM -0700, Chun Yan Liu wrote: 
> >  
> >  
> > >>> On 12/6/2014 at 12:06 AM, in message 
> > <20141205160615.GA24938@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com> 
> > wrote:  
> > > I have to admit I'm confused by the back and forth discussion. It's hard  
> > > to justify the design of new API without knowing what the constraints  
> > > and requirements are from your PoV.  
> > >   
> > > Here are my two cents, not about details, but about general constraints.  
> > >   
> > > There are two layers, one is user of libxl (clients -- xl, libvirt etc)  
> > > and libxl (the library itself).  
> > >   
> > > 1. it's better to *not* have storage management in libxl.  
> > >   
> > > It's likely that clients can have their own management functionality  
> > > already.  I'm told that libvirt has that as well as XAPI. Having this  
> > > functionality in libxl is a bit redundant and requires lots of work  
> > > (enlighten libxl on what a disk looks like and call out to various  
> > > utilities).  
> >  
> > Thanks Wei and Ian for your reply. We did have much discussion around 
> > can/cannot (e.g. xl can finish disk snapshot?) and should/shouldnot 
> > (e.g. disk snapshot process should not in xl? domain_snapshot_delete 
> > should not in libxl?), and confusing because have different ideas. So, 
> > settling it down is helpful. 
> >  
> > Talking about libvirt, it does provide storage management but through 
> > storage pools and volumes. But usually, we don't use storage pool/vol 
> > but directly use backend files, then libvirt storage driver can not 
> > manage them. And for libvirt vol, functionality in storage driver is 
> > limited, at least 'snapshot' cannot be done. So, libvirt side also 
> > needs to add codes to handle disk snapshot, quite like xl does. 
> >  
>  
> OK, so I take it that libvirt can be completely out the picture? I mean, 
> it's not a requirement for you to integrate with libvirt? 
>  
> I was thinking a stack like this when I replied: 
>  
>   libvirt: manages snapshot (including storage snapshot) 
>   libxl 
>   [other lower level stuffs] 
>  
> While I read from your reply, libvirt doesn't have that functionality 
> (or very limited), so you would like to do things like: 
>  
>   libvirt (or your homebrew toolstack) 
>   xl      (xl or libxl manages domain snapshots) 
>   libxl 
>   [other lower level stuffs] 
>  
> That's why you spent loads of time discussing with Ian what should be 
> done where, right? 

Partly. At least for domain disk snapshot create/delete, I prefer using
qmp commands instead of calling qemu-img one by one. Using qmp
commands, libvirt will need libxl's help. Of course, if libxl doesn't
supply that, libvirt can call qemu-img to each disk one by one,
not preferred but can do.

>  
> > Following the constraint that it's better NOT to supply disk snapshot 
> > functions in libxl, then we let xl and libvirt do that by themselve 
> > separately, that's OK. 
> >  
> > Then I think NO new API needs to be exported in libxl, since: 
> > * saving/restoring memory, there are already APIs. 
>  
> The principle is that if existing API doesn't work good enough for you 
> we will consider adding a new one. 
>  
> We probably need a new API. If you want to do a live snapshot, we would 
> need to notify xl that we are in the middle of pausing and resuming a 
> domain.  

This is where we discussed a lot. Do we really need
libxl_domain_snapshot_create API? or does xl can do the work?

Even for live snapshot, after calling libxl_domain_suspend with LIVE flags,
memory is saved and domain is paused. xl then can call disk snapshot
functions to finish disk snapshots, after all of that, call libxl_domain_unpause
to unpause the domain. So I don't think xl has any trouble to do that.
In case there is some misunderstanding, please point out.

>  
> > * disk snapshot work is xl internal, can be put in xl (or xlu). 
> > * handle JSON files is xl internal, can be put in xl. 
>  
> Yes. 
>  
> > (these are the main work vm snapshot handles). 
> >  
> > Right? 
> >  
> > This is quite different from previous document, so better to confirm. 
> >  
> > >   
> > > 2. it's *not* a requirement for xl to have the capability to manage  
> > > snapshots.  
> > >   
> > > It's the same arguement that xl has no idea on how to manage snapshots  
> > > created by "xl save".  This should ease your concern on having to  
> > > duplicate code for libvirt and xl.  IMHO the xl only needs to have the  
> > > capability to create a snapshot and create a domain from a snapshot. 
> >  
> > This way it's much easier since we don't need to maintain the snapshot 
> > info in file and don't need to take care of snapshot chain. But I doubt if 
> > that's good? 
> > 1. from user's side, it's a very common request to list all snapshots. 
> > 2. now for kvm, virsh supplies snapshot-create/delete/list/revert, 
> >    Is it good the xl only supply snapshot-create/revert? After all, 
> >    it's more complicated for user to take care of memory saving file 
> >    and disk snapshot info then 'xl save' (user only needs to take 
> >    care of memory state file). 
> >  
>  
> However the current architecture for libvirt to use libxl is like 
>  
>   libvirt 
>   libxl 
>   [other lower level stuffs] 
>  
> So implementing snapshot management in xl cannot work for you either. 
> It's not part of the current architecture.

You are right. I understand you are trying to suggest a way to ease the job.
Here just to make clear this way is really better and finally acceptable? :-)
Just IMO, I think xl snapshot-list is wanted, that means managing snapshots
in xl is needed.

>  
> Not that I'm against the idea of managing domain snapshot in xl, I'm 
> trying to reduce workload here. 
>  
> > > The  
> > > downside is that now xl and libvirt are disconnected, but I think it's  
> > > fine. 
> >  
> > Two things here: 
> > 1. connect xl and libvirt, then will need to manage snapshot info in libxl  
> (or 
> >     libxlu) That's not preferred since the initial design. This is not the  
> point 
> >     we discuss here. 
> > 2. for xl only, list snapshots and delete snapshots, also need to manage 
> >     snapshot info (in xl) 
> >  
> > Considering manage snapshot info in xl, only question is about idl and 
> > gentypes.py, expected structure is as following and expected to be saved 
> > into json file, but it contains xl namespace and libxl namespace things, 
> > gentypes.py will have problem. Better ideas? 
> >  
> > typedef struct xl_domain_snapshot { 
> >     char * name; 
> >     char * description; 
> >     uint64_t creation_time; 
> >     char * memory_path; 
> >     int num_disks; 
> >     libxl_disk_snapshot *disks; 
> >     char *parent; 
> >     bool *current; 
> > } xl_domain_snapshot; 
> >  
>  
> The libxl_disk_snapshot suggests that you still want storage management 
> inside libxl, which should probably be in libxlu? 

Yeah. I may put it in libxlu. Question is the same, cross two name spaces. But
now I think we can turn a way to do it. In xl_domain_snapshot, define
xl_disk_snapshot, then before calling libxlu API, turning it into
libxlu_disk_snapshot.

Thanks for your concern and suggestions. Appreciate it a lot! 
- Chunyan

>  
>   libvirt 
>   libxl libxlu 
>   [other lower level stuffs] 
>  
> Wei. 
>  
> > Thanks a lot! 
> > Chunyan 
> >  
> > > The arguement is that you're not allowed to run two toolstack on  
> > > the same host (think about xl and xend in previous releases).  
> > >   
> > > Do these two constraints make your work easier (or harder)?  
> > >   
> > > Regarding JSON API, as Ian said, feel free to hook it up to libxlu.  
> > >   
> > > Wei.  
> > >   
> > >   
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 07:29:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 07: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 1XyFEI-00010J-Jp; Tue, 09 Dec 2014 07:29:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyFEG-00010E-Qu
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 07:29:04 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	30/DD-09842-0C4A6845; Tue, 09 Dec 2014 07:29:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418110143!14317160!1
X-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 26493 invoked from network); 9 Dec 2014 07:29:03 -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; 9 Dec 2014 07:29:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 07:29:02 +0000
Message-Id: <5486B2CC020000780004DF61@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 07:29:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<54808CC3020000780004CCC8@mail.emea.novell.com>
	<54853FE3.9030703@intel.com>
	<548572B5020000780004D9BC@mail.emea.novell.com>
	<5486608F.1050700@intel.com>
In-Reply-To: <5486608F.1050700@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 03:38, <tiejun.chen@intel.com> wrote:
> On 2014/12/8 16:43, Jan Beulich wrote:
>>>>> On 08.12.14 at 07:06, <tiejun.chen@intel.com> wrote:
>>> I take a quick look at this but looks we have no this exact value that
>>> we can get directly.
>>
>> You need some upper bound. Whether you introduce a properly
> 
> In theory, we may have at most the number, domain(16bit) x bus(8bit) x 
> device(5bit) x function(3bit), 2^16 x 2^8 x 2^5 x 2^3 = 0x1000000, so 
> could we define a macro like this,
> 
> #define PCI_DEVICES_NUM_UP 0x1000000

16+8+5+3 = 32 for me. And an upper bound of 4G is surely not
useful here in any 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 Dec 09 07:29:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 07: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 1XyFEI-00010J-Jp; Tue, 09 Dec 2014 07:29:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyFEG-00010E-Qu
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 07:29:04 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	30/DD-09842-0C4A6845; Tue, 09 Dec 2014 07:29:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418110143!14317160!1
X-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 26493 invoked from network); 9 Dec 2014 07:29:03 -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; 9 Dec 2014 07:29:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 07:29:02 +0000
Message-Id: <5486B2CC020000780004DF61@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 07:29:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<54808CC3020000780004CCC8@mail.emea.novell.com>
	<54853FE3.9030703@intel.com>
	<548572B5020000780004D9BC@mail.emea.novell.com>
	<5486608F.1050700@intel.com>
In-Reply-To: <5486608F.1050700@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 03:38, <tiejun.chen@intel.com> wrote:
> On 2014/12/8 16:43, Jan Beulich wrote:
>>>>> On 08.12.14 at 07:06, <tiejun.chen@intel.com> wrote:
>>> I take a quick look at this but looks we have no this exact value that
>>> we can get directly.
>>
>> You need some upper bound. Whether you introduce a properly
> 
> In theory, we may have at most the number, domain(16bit) x bus(8bit) x 
> device(5bit) x function(3bit), 2^16 x 2^8 x 2^5 x 2^3 = 0x1000000, so 
> could we define a macro like this,
> 
> #define PCI_DEVICES_NUM_UP 0x1000000

16+8+5+3 = 32 for me. And an upper bound of 4G is surely not
useful here in any 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 Dec 09 07:47:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 07: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 1XyFVs-0001jy-6I; Tue, 09 Dec 2014 07:47:16 +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 1XyFVq-0001jq-NV
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 07:47:14 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	67/52-14214-109A6845; Tue, 09 Dec 2014 07:47:13 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418111231!4679376!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21262 invoked from network); 9 Dec 2014 07:47:12 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-206.messagelabs.com with SMTP;
	9 Dec 2014 07:47:12 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga101.jf.intel.com with ESMTP; 08 Dec 2014 23:47:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="495886284"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.208])
	([10.238.128.208])
	by orsmga003.jf.intel.com with ESMTP; 08 Dec 2014 23:43:27 -0800
Message-ID: <5486A8FB.4080402@intel.com>
Date: Tue, 09 Dec 2014 15:47: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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
In-Reply-To: <54857491020000780004D9D6@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/8 16:51, Jan Beulich wrote:
>>>> On 08.12.14 at 08:11, <tiejun.chen@intel.com> wrote:
>> On 2014/12/4 23:50, Jan Beulich wrote:
>>>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>>>>
>>>> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>>>> -                                     &rdm, 1) )
>>>> -            return -EFAULT;
>>>> +    if ( d )
>>>> +    {
>>>> +        if ( d->arch.hvm_domain.pci_force )
>>>
>>> You didn't verify that the domain is a HVM/PVH one.
>>
>> Is this, ASSERT(is_hvm_domain(grdm.domain)), correct?
>
> Certainly not, or do you want to crash the hypervisor because of bad
> tools input?

Based on konrad's hint, I hope this should work for you,

+        if ( !is_hvm_domain(d) )
+            return -ENOSYS;

>
>>>> +        {
>>>> +            if ( grdm->used_entries < grdm->map.nr_entries )
>>>> +            {
>>>> +                if ( __copy_to_compat_offset(grdm->map.buffer,
>>>> +                                             grdm->used_entries,
>>>> +                                             &rdm, 1) )
>>>> +                {
>>>> +                    rcu_unlock_domain(d);
>>>> +                    return -EFAULT;
>>>> +                }
>>>> +            }
>>>> +            ++grdm->used_entries;
>>>> +        }
>>>> +        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 ( grdm->used_entries < grdm->map.nr_entries )
>>>> +                    {
>>>> +                        if ( __copy_to_compat_offset(grdm->map.buffer,
>>>> +                                                     grdm->used_entries,
>>>> +                                                     &rdm, 1) )
>>>> +                        {
>>>> +                            rcu_unlock_domain(d);
>>>> +                            return -EFAULT;
>>>> +                        }
>>>> +                    }
>>>> +                    ++grdm->used_entries;
>>>
>>> break;
>>
>> Added.
>>
>>>
>>> Also trying to fold code identical on the if and else branches would
>>> seem pretty desirable.
>>
>> Sorry, I can't see what I'm missing.
>
> The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
> is identical and can be factored out pretty easily afaict.

What about this?

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,
                                       u32 id, void *ctxt)
{
     struct get_reserved_device_memory *grdm = ctxt;
     struct domain *d = grdm->domain;
     unsigned int i, hit_one = 0;
     u32 sbdf;
     struct xen_reserved_device_memory rdm = {
         .start_pfn = start, .nr_pages = nr
     };

     if ( !d->arch.hvm_domain.pci_force )
     {
         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 )
             {
                 hit_one = 1;
                 break;
             }
         }

         if ( !hit_one )
             return 0;
     }

     if ( grdm->used_entries < grdm->map.nr_entries )
     {
         if ( __copy_to_guest_offset(grdm->map.buffer,
                                     grdm->used_entries,
                                     &rdm, 1) )
             return -EFAULT;
     }

     ++grdm->used_entries;

     return 0;
}

>
>>>> @@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>>>
>>>>                if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>>>>                    rc = -ENOBUFS;
>>>> +
>>>>                grdm.map.nr_entries = grdm.used_entries;
>>>> -            if ( __copy_to_guest(compat, &grdm.map, 1) )
>>>> -                rc = -EFAULT;
>>>> +            if ( grdm.map.nr_entries )
>>>> +            {
>>>> +                if ( __copy_to_guest(compat, &grdm.map, 1) )
>>>> +                    rc = -EFAULT;
>>>> +            }
>>>
>>> Why do you need this change?
>>
>> If we have no any entries, why do we still copy that?
>
> That's not only a pointless optimization (the counter question being
> "Why add an extra conditional when the copying does no harm?"), but
> also not subject of this patch. Additionally iirc the field is an IN/OUT,
> i.e. when no entries were found you want to tell the caller so.

Right so I will recover that.

>
>>>> --- a/xen/drivers/passthrough/vtd/dmar.c
>>>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>>>> @@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
>>>>
>>>>    int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>>>    {
>>>> -    struct acpi_rmrr_unit *rmrr;
>>>> +    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
>>>>        int rc = 0;
>>>> +    unsigned 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 ( 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;
>>>> +
>>>> +            /* Just go next. */
>>>> +            if ( !rc )
>>>> +                rmrr_cur = rmrr;
>>>> +
>>>> +            /* Now just return specific to user requirement. */
>>>> +            if ( rc > 0 )
>>>> +                return rc;
>>>
>>> Nice that you check for that, but I can't see this case occurring
>>> anymore. Did you lose some code? Also please don't write code
>>
>> We have three scenarios here:
>>
>> #1 rc < 0 means this is an error;
>> #2 rc = 0 means the tools caller don't know how many buffers it should
>> construct, so we need to count all entries as 'nr_entries' to return.
>> #3 rc > 0 means in some cases, we need to return some specific values,
>> like 1 to indicate we're hitting some RMRR range. Currently, we use gfn
>> to check this in case of memory populating, ept violation handler and
>> mem_access.
>
> Yes, I saw that you make use of this in later patches. It just seemed
> suspicious that you don't in this one.
>
>>>> --- a/xen/include/public/memory.h
>>>> +++ b/xen/include/public/memory.h
>>>> @@ -586,6 +586,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 */
>>>
>>> Your addition lacks an IN annotation.
>>
>> Are you saying something for 'nr_entries'? But I didn't introduce
>> anything to change the original usage. Anyway, I try to improve this,
>>
>>       /*
>>        * IN: on call the number of entries which can be stored in buffer.
>>        * OUT: on return the number of entries which have been stored in
>>        * buffer. If on call the number is less the number of all necessary
>>        * entries, on return the number of entries which is needed.
>>        */
>>
>
> No, I said "your addition lacks ...". And you addition is the "domid"
> field.
>

Sorry I'm misunderstanding this.

struct xen_reserved_device_memory_map {
     /*
      * IN: Domain whose reservation is being changed.
      * Unprivileged domains can specify only DOMID_SELF.
      */
     domid_t        domid;
     /* IN/OUT */
     unsigned int nr_entries;
     /* OUT */
     XEN_GUEST_HANDLE(xen_reserved_device_memory_t) buffer;
};

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 Dec 09 07:47:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 07: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 1XyFVs-0001jy-6I; Tue, 09 Dec 2014 07:47:16 +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 1XyFVq-0001jq-NV
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 07:47:14 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	67/52-14214-109A6845; Tue, 09 Dec 2014 07:47:13 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418111231!4679376!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21262 invoked from network); 9 Dec 2014 07:47:12 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-206.messagelabs.com with SMTP;
	9 Dec 2014 07:47:12 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga101.jf.intel.com with ESMTP; 08 Dec 2014 23:47:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="495886284"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.208])
	([10.238.128.208])
	by orsmga003.jf.intel.com with ESMTP; 08 Dec 2014 23:43:27 -0800
Message-ID: <5486A8FB.4080402@intel.com>
Date: Tue, 09 Dec 2014 15:47: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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
In-Reply-To: <54857491020000780004D9D6@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/8 16:51, Jan Beulich wrote:
>>>> On 08.12.14 at 08:11, <tiejun.chen@intel.com> wrote:
>> On 2014/12/4 23:50, Jan Beulich wrote:
>>>>>> On 01.12.14 at 10:24, <tiejun.chen@intel.com> wrote:
>>>>
>>>> -        if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>>>> -                                     &rdm, 1) )
>>>> -            return -EFAULT;
>>>> +    if ( d )
>>>> +    {
>>>> +        if ( d->arch.hvm_domain.pci_force )
>>>
>>> You didn't verify that the domain is a HVM/PVH one.
>>
>> Is this, ASSERT(is_hvm_domain(grdm.domain)), correct?
>
> Certainly not, or do you want to crash the hypervisor because of bad
> tools input?

Based on konrad's hint, I hope this should work for you,

+        if ( !is_hvm_domain(d) )
+            return -ENOSYS;

>
>>>> +        {
>>>> +            if ( grdm->used_entries < grdm->map.nr_entries )
>>>> +            {
>>>> +                if ( __copy_to_compat_offset(grdm->map.buffer,
>>>> +                                             grdm->used_entries,
>>>> +                                             &rdm, 1) )
>>>> +                {
>>>> +                    rcu_unlock_domain(d);
>>>> +                    return -EFAULT;
>>>> +                }
>>>> +            }
>>>> +            ++grdm->used_entries;
>>>> +        }
>>>> +        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 ( grdm->used_entries < grdm->map.nr_entries )
>>>> +                    {
>>>> +                        if ( __copy_to_compat_offset(grdm->map.buffer,
>>>> +                                                     grdm->used_entries,
>>>> +                                                     &rdm, 1) )
>>>> +                        {
>>>> +                            rcu_unlock_domain(d);
>>>> +                            return -EFAULT;
>>>> +                        }
>>>> +                    }
>>>> +                    ++grdm->used_entries;
>>>
>>> break;
>>
>> Added.
>>
>>>
>>> Also trying to fold code identical on the if and else branches would
>>> seem pretty desirable.
>>
>> Sorry, I can't see what I'm missing.
>
> The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
> is identical and can be factored out pretty easily afaict.

What about this?

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,
                                       u32 id, void *ctxt)
{
     struct get_reserved_device_memory *grdm = ctxt;
     struct domain *d = grdm->domain;
     unsigned int i, hit_one = 0;
     u32 sbdf;
     struct xen_reserved_device_memory rdm = {
         .start_pfn = start, .nr_pages = nr
     };

     if ( !d->arch.hvm_domain.pci_force )
     {
         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 )
             {
                 hit_one = 1;
                 break;
             }
         }

         if ( !hit_one )
             return 0;
     }

     if ( grdm->used_entries < grdm->map.nr_entries )
     {
         if ( __copy_to_guest_offset(grdm->map.buffer,
                                     grdm->used_entries,
                                     &rdm, 1) )
             return -EFAULT;
     }

     ++grdm->used_entries;

     return 0;
}

>
>>>> @@ -319,9 +358,13 @@ int compat_memory_op(unsigned int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>>>
>>>>                if ( !rc && grdm.map.nr_entries < grdm.used_entries )
>>>>                    rc = -ENOBUFS;
>>>> +
>>>>                grdm.map.nr_entries = grdm.used_entries;
>>>> -            if ( __copy_to_guest(compat, &grdm.map, 1) )
>>>> -                rc = -EFAULT;
>>>> +            if ( grdm.map.nr_entries )
>>>> +            {
>>>> +                if ( __copy_to_guest(compat, &grdm.map, 1) )
>>>> +                    rc = -EFAULT;
>>>> +            }
>>>
>>> Why do you need this change?
>>
>> If we have no any entries, why do we still copy that?
>
> That's not only a pointless optimization (the counter question being
> "Why add an extra conditional when the copying does no harm?"), but
> also not subject of this patch. Additionally iirc the field is an IN/OUT,
> i.e. when no entries were found you want to tell the caller so.

Right so I will recover that.

>
>>>> --- a/xen/drivers/passthrough/vtd/dmar.c
>>>> +++ b/xen/drivers/passthrough/vtd/dmar.c
>>>> @@ -904,17 +904,33 @@ int platform_supports_x2apic(void)
>>>>
>>>>    int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>>>>    {
>>>> -    struct acpi_rmrr_unit *rmrr;
>>>> +    struct acpi_rmrr_unit *rmrr, *rmrr_cur = NULL;
>>>>        int rc = 0;
>>>> +    unsigned 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 ( 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;
>>>> +
>>>> +            /* Just go next. */
>>>> +            if ( !rc )
>>>> +                rmrr_cur = rmrr;
>>>> +
>>>> +            /* Now just return specific to user requirement. */
>>>> +            if ( rc > 0 )
>>>> +                return rc;
>>>
>>> Nice that you check for that, but I can't see this case occurring
>>> anymore. Did you lose some code? Also please don't write code
>>
>> We have three scenarios here:
>>
>> #1 rc < 0 means this is an error;
>> #2 rc = 0 means the tools caller don't know how many buffers it should
>> construct, so we need to count all entries as 'nr_entries' to return.
>> #3 rc > 0 means in some cases, we need to return some specific values,
>> like 1 to indicate we're hitting some RMRR range. Currently, we use gfn
>> to check this in case of memory populating, ept violation handler and
>> mem_access.
>
> Yes, I saw that you make use of this in later patches. It just seemed
> suspicious that you don't in this one.
>
>>>> --- a/xen/include/public/memory.h
>>>> +++ b/xen/include/public/memory.h
>>>> @@ -586,6 +586,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 */
>>>
>>> Your addition lacks an IN annotation.
>>
>> Are you saying something for 'nr_entries'? But I didn't introduce
>> anything to change the original usage. Anyway, I try to improve this,
>>
>>       /*
>>        * IN: on call the number of entries which can be stored in buffer.
>>        * OUT: on return the number of entries which have been stored in
>>        * buffer. If on call the number is less the number of all necessary
>>        * entries, on return the number of entries which is needed.
>>        */
>>
>
> No, I said "your addition lacks ...". And you addition is the "domid"
> field.
>

Sorry I'm misunderstanding this.

struct xen_reserved_device_memory_map {
     /*
      * IN: Domain whose reservation is being changed.
      * Unprivileged domains can specify only DOMID_SELF.
      */
     domid_t        domid;
     /* IN/OUT */
     unsigned int nr_entries;
     /* OUT */
     XEN_GUEST_HANDLE(xen_reserved_device_memory_t) buffer;
};

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 Dec 09 08:19:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 08:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyG10-0003HV-Re; Tue, 09 Dec 2014 08:19: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 1XyG0z-0003HQ-P4
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 08:19:25 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	2B/03-02712-D80B6845; Tue, 09 Dec 2014 08:19:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418113164!13825142!1
X-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 10158 invoked from network); 9 Dec 2014 08:19:24 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 08:19:24 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 08:19:23 +0000
Message-Id: <5486BE99020000780004DF8A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 08:19:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
In-Reply-To: <5486A8FB.4080402@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 08:47, <tiejun.chen@intel.com> wrote:
> On 2014/12/8 16:51, Jan Beulich wrote:
>> The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
>> is identical and can be factored out pretty easily afaict.
> 
> What about this?
> 
> 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,
>                                        u32 id, void *ctxt)
> {
>      struct get_reserved_device_memory *grdm = ctxt;
>      struct domain *d = grdm->domain;
>      unsigned int i, hit_one = 0;
>      u32 sbdf;
>      struct xen_reserved_device_memory rdm = {
>          .start_pfn = start, .nr_pages = nr
>      };
> 
>      if ( !d->arch.hvm_domain.pci_force )
>      {
>          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 )
>              {
>                  hit_one = 1;
>                  break;
>              }
>          }
> 
>          if ( !hit_one )
>              return 0;
>      }

Why do you always pick other than the simplest possible solution?
You don't need a separate variable here, you can simply check
whether i reached d->arch.hvm_domain.num_pcidevs after the
loop. And even if you added a variable, it would want to be a
bool_t one with the way you use 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 Dec 09 08:19:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 08:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyG10-0003HV-Re; Tue, 09 Dec 2014 08:19: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 1XyG0z-0003HQ-P4
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 08:19:25 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	2B/03-02712-D80B6845; Tue, 09 Dec 2014 08:19:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418113164!13825142!1
X-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 10158 invoked from network); 9 Dec 2014 08:19:24 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 08:19:24 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 08:19:23 +0000
Message-Id: <5486BE99020000780004DF8A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 08:19:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
In-Reply-To: <5486A8FB.4080402@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 08:47, <tiejun.chen@intel.com> wrote:
> On 2014/12/8 16:51, Jan Beulich wrote:
>> The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
>> is identical and can be factored out pretty easily afaict.
> 
> What about this?
> 
> 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,
>                                        u32 id, void *ctxt)
> {
>      struct get_reserved_device_memory *grdm = ctxt;
>      struct domain *d = grdm->domain;
>      unsigned int i, hit_one = 0;
>      u32 sbdf;
>      struct xen_reserved_device_memory rdm = {
>          .start_pfn = start, .nr_pages = nr
>      };
> 
>      if ( !d->arch.hvm_domain.pci_force )
>      {
>          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 )
>              {
>                  hit_one = 1;
>                  break;
>              }
>          }
> 
>          if ( !hit_one )
>              return 0;
>      }

Why do you always pick other than the simplest possible solution?
You don't need a separate variable here, you can simply check
whether i reached d->arch.hvm_domain.num_pcidevs after the
loop. And even if you added a variable, it would want to be a
bool_t one with the way you use 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 Dec 09 08:31:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 08: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 1XyGCY-0003en-1U; Tue, 09 Dec 2014 08:31: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 1XyGCW-0003ei-SI
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 08:31:20 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	31/06-16982-753B6845; Tue, 09 Dec 2014 08:31:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418113879!11948887!1
X-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 24374 invoked from network); 9 Dec 2014 08:31: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; 9 Dec 2014 08:31:19 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 08:31:18 +0000
Message-Id: <5486C164020000780004DF97@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 08:31:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zhang Yu" <yu.c.zhang@linux.intel.com>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54865820.2010501@linux.intel.com>
In-Reply-To: <54865820.2010501@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 v6 0/2] add new p2m type class and new p2m
 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 09.12.14 at 03:02, <yu.c.zhang@linux.intel.com> wrote:
>    Thank you very much for your review.
>    And could you please also help me about how to get an ACK? I'm not 
> sure what's the next action I need to take. :-)

I don't think you need to take any action at this point. The second
patch will need Tim's ack, yes, but that's nothing to worry about
(yet), since even with his ack the two patches wouldn't go in until
after 4.5 got branched off of staging.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 08:31:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 08: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 1XyGCY-0003en-1U; Tue, 09 Dec 2014 08:31: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 1XyGCW-0003ei-SI
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 08:31:20 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	31/06-16982-753B6845; Tue, 09 Dec 2014 08:31:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418113879!11948887!1
X-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 24374 invoked from network); 9 Dec 2014 08:31: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; 9 Dec 2014 08:31:19 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 08:31:18 +0000
Message-Id: <5486C164020000780004DF97@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 08:31:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zhang Yu" <yu.c.zhang@linux.intel.com>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54865820.2010501@linux.intel.com>
In-Reply-To: <54865820.2010501@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 v6 0/2] add new p2m type class and new p2m
 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 09.12.14 at 03:02, <yu.c.zhang@linux.intel.com> wrote:
>    Thank you very much for your review.
>    And could you please also help me about how to get an ACK? I'm not 
> sure what's the next action I need to take. :-)

I don't think you need to take any action at this point. The second
patch will need Tim's ack, yes, but that's nothing to worry about
(yet), since even with his ack the two patches wouldn't go in until
after 4.5 got branched off of staging.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 08:34:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 08: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 1XyGF9-00041f-Be; Tue, 09 Dec 2014 08:34:03 +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 1XyGF6-000419-TX; Tue, 09 Dec 2014 08:34:01 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B5/8A-09842-8F3B6845; Tue, 09 Dec 2014 08:34:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418114039!14292801!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10256 invoked from network); 9 Dec 2014 08:33:59 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 08:33:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418114039; l=399;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=7heqegxVfNiKFiSrmvaD+2xhA44=;
	b=tDJrD+Io1q7R3ckzEH05I1GWNxRrFDc704d1q/dosTQRWvjZABOPaGOPV6DbBLAzdYM
	2RXfHHvIaJtkUnuP/uSGnlDQKMcE5L6olPET/R4x2LoNh0YZNt5O5TlTLFSpJpe2r/dRR
	F9k75PoLLo6GwAiNtlW43OvQDKVtrfNZmJE=
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.3 AUTH) with ESMTPSA id x0251cqB98Xv8vo
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 9 Dec 2014 09:33:57 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A43375015E; Tue,  9 Dec 2014 09:33:56 +0100 (CET)
Date: Tue, 9 Dec 2014 09:33:56 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141209083356.GA21664@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<20141205171102.GA24737@aepfle.de>
	<20141208171949.GA1819@aepfle.de>
	<20141208172307.GA25749@zion.uk.xensource.com>
	<20141208173708.GA6679@aepfle.de>
	<20141208174854.GB25749@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141208174854.GB25749@zion.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, Wei Liu wrote:

> However I think the problem you're seeing is due to xenstored exits too
> early, which should be fixable by rearranging the shutdown order? I.e.
> xenstored shuts down after xendomains.

True, and this is addressed by 268b8f1.

Perhaps a crashed or otherwise unavailable xenstored isnt such a problem
because its like that since a very long time.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 08:34:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 08: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 1XyGF7-00041G-4l; Tue, 09 Dec 2014 08:34:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyGF6-000417-7o
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 08:34:00 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	FB/AA-28865-7F3B6845; Tue, 09 Dec 2014 08:33:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418114038!4689601!1
X-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 21190 invoked from network); 9 Dec 2014 08:33:59 -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; 9 Dec 2014 08:33:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 08:33:58 +0000
Message-Id: <5486C204020000780004DF9A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 08:33:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<20141202193943.GC357@laptop.dumpdata.com> <548517F7.6040106@intel.com>
	<20141208155734.GE7745@laptop.dumpdata.com>
	<54864B1C.6020701@intel.com>
In-Reply-To: <54864B1C.6020701@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 02:06, <tiejun.chen@intel.com> wrote:
>>>> Also how does this work with 32-bit dom0s? Is there a need to use the
>>>> compat layer?
>>>
>>> Are you saying in xsm case? Others?
>>>
>>> Actually this new DOMCTL is similar with XEN_DOMCTL_assign_device in some
>>> senses but I don't see such an issue you're pointing.
>>
>> I was thinking about the compat layer and making sure it works properly.
> 
> Do we really need this consideration? I mean I referred to that existing 
> XEN_DOMCTL_assign_device to implement this new DOMCTL, but looks there's 
> nothing related to this point.
> 
> Or could you make your thought clear to me with an exiting example? Then 
> I can take a look at what exactly should be taken in my new DOMCTL since 
> I'm a fresh man to work out this properly inside xen.

I think Konrad got a little confused here - domctl-s intentionally are
structured so that they don't need a compat translation layer.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 08:34:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 08: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 1XyGF9-00041f-Be; Tue, 09 Dec 2014 08:34:03 +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 1XyGF6-000419-TX; Tue, 09 Dec 2014 08:34:01 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	B5/8A-09842-8F3B6845; Tue, 09 Dec 2014 08:34:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418114039!14292801!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10256 invoked from network); 9 Dec 2014 08:33:59 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 08:33:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418114039; l=399;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=7heqegxVfNiKFiSrmvaD+2xhA44=;
	b=tDJrD+Io1q7R3ckzEH05I1GWNxRrFDc704d1q/dosTQRWvjZABOPaGOPV6DbBLAzdYM
	2RXfHHvIaJtkUnuP/uSGnlDQKMcE5L6olPET/R4x2LoNh0YZNt5O5TlTLFSpJpe2r/dRR
	F9k75PoLLo6GwAiNtlW43OvQDKVtrfNZmJE=
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.3 AUTH) with ESMTPSA id x0251cqB98Xv8vo
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 9 Dec 2014 09:33:57 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A43375015E; Tue,  9 Dec 2014 09:33:56 +0100 (CET)
Date: Tue, 9 Dec 2014 09:33:56 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141209083356.GA21664@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<20141205171102.GA24737@aepfle.de>
	<20141208171949.GA1819@aepfle.de>
	<20141208172307.GA25749@zion.uk.xensource.com>
	<20141208173708.GA6679@aepfle.de>
	<20141208174854.GB25749@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141208174854.GB25749@zion.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Mark Pryor <tlviewer@yahoo.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, Wei Liu wrote:

> However I think the problem you're seeing is due to xenstored exits too
> early, which should be fixable by rearranging the shutdown order? I.e.
> xenstored shuts down after xendomains.

True, and this is addressed by 268b8f1.

Perhaps a crashed or otherwise unavailable xenstored isnt such a problem
because its like that since a very long time.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 08:34:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 08: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 1XyGF7-00041G-4l; Tue, 09 Dec 2014 08:34:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyGF6-000417-7o
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 08:34:00 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	FB/AA-28865-7F3B6845; Tue, 09 Dec 2014 08:33:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418114038!4689601!1
X-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 21190 invoked from network); 9 Dec 2014 08:33:59 -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; 9 Dec 2014 08:33:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 08:33:58 +0000
Message-Id: <5486C204020000780004DF9A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 08:33:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<20141202193943.GC357@laptop.dumpdata.com> <548517F7.6040106@intel.com>
	<20141208155734.GE7745@laptop.dumpdata.com>
	<54864B1C.6020701@intel.com>
In-Reply-To: <54864B1C.6020701@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 02:06, <tiejun.chen@intel.com> wrote:
>>>> Also how does this work with 32-bit dom0s? Is there a need to use the
>>>> compat layer?
>>>
>>> Are you saying in xsm case? Others?
>>>
>>> Actually this new DOMCTL is similar with XEN_DOMCTL_assign_device in some
>>> senses but I don't see such an issue you're pointing.
>>
>> I was thinking about the compat layer and making sure it works properly.
> 
> Do we really need this consideration? I mean I referred to that existing 
> XEN_DOMCTL_assign_device to implement this new DOMCTL, but looks there's 
> nothing related to this point.
> 
> Or could you make your thought clear to me with an exiting example? Then 
> I can take a look at what exactly should be taken in my new DOMCTL since 
> I'm a fresh man to work out this properly inside xen.

I think Konrad got a little confused here - domctl-s intentionally are
structured so that they don't need a compat translation layer.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 08:47:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 08: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 1XyGRM-0004o8-7L; Tue, 09 Dec 2014 08:46: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 1XyGRL-0004o2-Ij
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 08:46:39 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	68/4F-02697-EE6B6845; Tue, 09 Dec 2014 08:46:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418114798!12278724!1
X-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 7497 invoked from network); 9 Dec 2014 08:46:38 -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; 9 Dec 2014 08:46:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 08:46:37 +0000
Message-Id: <5486C4FB020000780004DFBF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 08:46:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5485F5F7.6040206@citrix.com>
In-Reply-To: <5485F5F7.6040206@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.12.14 at 20:03, <andrew.cooper3@citrix.com> wrote:
> XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it didn't in
> xen-4.4, given identical parameters.  The hypercall gained an extra
> permission check as part of 0561e1f01e.  Our usecase here is a daemon in
> dom0 mapping guest RAM to emulate a graphics card, but I currently don't
> see how that is incompatible with the new permissions check.

This seems quite obvious: The added check makes sure that what gets
mapped is I/O memory both domains have access to, yet you say the
daemon maps guest RAM. What I can't see is why you need this
hypercall in this case - given what you say it's certainly not meant for
the daemon to map memory into the guest? Mapping guest RAM ought
to work via the privcmd kernel interface.

> We have certain machines which are showing reliable failure to boot
> under Xen-4.5, where they worked with 4.4.  Symptoms range from the dom0
> kernel crashing before printing anything, to complaining that the initrd
> is corrupt when attempting to decompress.  This appears to be hardware
> specific.

Any chance this is C-state related, just like narrowed down to for
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00228.html?
I.e. Westmere Xeons being affected? If not, this would seem rather
worrying to me (read: a release blocker). And even if so, a workaround
would be minimally needed. Otoh you didn't report so for earlier RCs -
was that just because the testing scope was more narrow then, or can
we imply that this is a recently introduced regression?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 08:47:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 08: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 1XyGRM-0004o8-7L; Tue, 09 Dec 2014 08:46: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 1XyGRL-0004o2-Ij
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 08:46:39 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	68/4F-02697-EE6B6845; Tue, 09 Dec 2014 08:46:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418114798!12278724!1
X-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 7497 invoked from network); 9 Dec 2014 08:46:38 -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; 9 Dec 2014 08:46:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 08:46:37 +0000
Message-Id: <5486C4FB020000780004DFBF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 08:46:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5485F5F7.6040206@citrix.com>
In-Reply-To: <5485F5F7.6040206@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.12.14 at 20:03, <andrew.cooper3@citrix.com> wrote:
> XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it didn't in
> xen-4.4, given identical parameters.  The hypercall gained an extra
> permission check as part of 0561e1f01e.  Our usecase here is a daemon in
> dom0 mapping guest RAM to emulate a graphics card, but I currently don't
> see how that is incompatible with the new permissions check.

This seems quite obvious: The added check makes sure that what gets
mapped is I/O memory both domains have access to, yet you say the
daemon maps guest RAM. What I can't see is why you need this
hypercall in this case - given what you say it's certainly not meant for
the daemon to map memory into the guest? Mapping guest RAM ought
to work via the privcmd kernel interface.

> We have certain machines which are showing reliable failure to boot
> under Xen-4.5, where they worked with 4.4.  Symptoms range from the dom0
> kernel crashing before printing anything, to complaining that the initrd
> is corrupt when attempting to decompress.  This appears to be hardware
> specific.

Any chance this is C-state related, just like narrowed down to for
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00228.html?
I.e. Westmere Xeons being affected? If not, this would seem rather
worrying to me (read: a release blocker). And even if so, a workaround
would be minimally needed. Otoh you didn't report so for earlier RCs -
was that just because the testing scope was more narrow then, or can
we imply that this is a recently introduced regression?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 08:57:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 08: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 1XyGbm-00053g-JG; Tue, 09 Dec 2014 08:57:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyGbl-00053b-Ql
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 08:57:25 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	AB/A8-25714-579B6845; Tue, 09 Dec 2014 08:57:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418115427!4695017!1
X-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 29691 invoked from network); 9 Dec 2014 08:57:07 -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; 9 Dec 2014 08:57:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 08:57:07 +0000
Message-Id: <5486C771020000780004DFCD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 08:57:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5485F5F7.6040206@citrix.com>
	<20141208200034.GA3891@laptop.dumpdata.com>
	<54864081.6090606@citrix.com>
In-Reply-To: <54864081.6090606@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 01:21, <andrew.cooper3@citrix.com> wrote:
> On 08/12/2014 20:00, Konrad Rzeszutek Wilk wrote:
>> On Mon, Dec 08, 2014 at 07:03:19PM +0000, Andrew Cooper wrote:
>>> XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it didn't in
>>> xen-4.4, given identical parameters.  The hypercall gained an extra
>>> permission check as part of 0561e1f01e.  Our usecase here is a daemon in
>>> dom0 mapping guest RAM to emulate a graphics card, but I currently don't
>>> see how that is incompatible with the new permissions check.
>> I presume the daemon also does 'XEN_DOMCTL_iomem_permission' to grant
>> the other domain access to its RAM? And before it makes the
>> XEN_DOMCTL_memory_mapping hypercall.
> 
> This is purely an implementer of the ioreq server infrastructure
> providing an emulated set of BARs in the guest as qemu would, but
> without using dom0 map-foreign powers.  The gfn ranges in question are
> regular guest RAM as far as I am aware, and should not require any
> special io permissions.
> 
> Either way, the identified changeset has apparently caused a regression,
> but I am not yet certain whether it is legitimately disabling something
> which should not have worked in the first place, or whether it is a
> change which needs reconsidering.

Actually I think this is still too lax: When we set up Dom0's iomem
permissions, we blindly add all memory, when we should only add
all I/O memory (or better, exclude all RAM). Iiuc such a change
would similarly break your daemon, without need for Arianna's.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 08:57:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 08: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 1XyGbm-00053g-JG; Tue, 09 Dec 2014 08:57:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyGbl-00053b-Ql
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 08:57:25 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	AB/A8-25714-579B6845; Tue, 09 Dec 2014 08:57:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418115427!4695017!1
X-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 29691 invoked from network); 9 Dec 2014 08:57:07 -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; 9 Dec 2014 08:57:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 08:57:07 +0000
Message-Id: <5486C771020000780004DFCD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 08:57:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5485F5F7.6040206@citrix.com>
	<20141208200034.GA3891@laptop.dumpdata.com>
	<54864081.6090606@citrix.com>
In-Reply-To: <54864081.6090606@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 01:21, <andrew.cooper3@citrix.com> wrote:
> On 08/12/2014 20:00, Konrad Rzeszutek Wilk wrote:
>> On Mon, Dec 08, 2014 at 07:03:19PM +0000, Andrew Cooper wrote:
>>> XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it didn't in
>>> xen-4.4, given identical parameters.  The hypercall gained an extra
>>> permission check as part of 0561e1f01e.  Our usecase here is a daemon in
>>> dom0 mapping guest RAM to emulate a graphics card, but I currently don't
>>> see how that is incompatible with the new permissions check.
>> I presume the daemon also does 'XEN_DOMCTL_iomem_permission' to grant
>> the other domain access to its RAM? And before it makes the
>> XEN_DOMCTL_memory_mapping hypercall.
> 
> This is purely an implementer of the ioreq server infrastructure
> providing an emulated set of BARs in the guest as qemu would, but
> without using dom0 map-foreign powers.  The gfn ranges in question are
> regular guest RAM as far as I am aware, and should not require any
> special io permissions.
> 
> Either way, the identified changeset has apparently caused a regression,
> but I am not yet certain whether it is legitimately disabling something
> which should not have worked in the first place, or whether it is a
> change which needs reconsidering.

Actually I think this is still too lax: When we set up Dom0's iomem
permissions, we blindly add all memory, when we should only add
all I/O memory (or better, exclude all RAM). Iiuc such a change
would similarly break your daemon, without need for Arianna's.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 09:03:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:03:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGh4-0005gR-D3; Tue, 09 Dec 2014 09:02:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyGh2-0005gM-IL
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 09:02:52 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E8/30-09842-BBAB6845; Tue, 09 Dec 2014 09:02:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418115771!14358969!1
X-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 32417 invoked from network); 9 Dec 2014 09:02:51 -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; 9 Dec 2014 09:02:51 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 09:02:51 +0000
Message-Id: <5486C8C9020000780004DFDC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 09:02:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20141208212739.GA7226@laptop.dumpdata.com>
In-Reply-To: <20141208212739.GA7226@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen  4.5.0rc3 + Linux v3.18 + dom0pvh=1 = BOOM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 22:27, <konrad.wilk@oracle.com> wrote:
> [    8.761336] ------------[ cut here ]------------
> [    8.761342] kernel BUG at arch/x86/xen/smp.c:438!

	if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
		BUG();

> [    8.761348] invalid opcode: 0000 [#1] SMP 
> [    8.761355] Modules linked in:
> [    8.761362] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0 #1
> [    8.761369] Hardware name: LENOVO 10A6S09R01/SHARKBAY, BIOS FBKTA1AUS 10/22/2014
> [    8.761377] task: ffff8803ef058000 ti: ffff8803ef060000 task.ti: ffff8803ef060000
> [    8.761386] RIP: 0010:[<ffffffff810114c5>]  [<ffffffff810114c5>] xen_cpu_up+0x4c5/0x4d0
> [    8.761396] RSP: 0000:ffff8803ef063dd8  EFLAGS: 00010282
> [    8.761402] RAX: fffffffffffffff4 RBX: 0000000000000001 RCX: 0000000000000001

-ENOMEM

Very strange. I suppose that Dom0 kernel doesn't exhaust all of the
hypervisor's memory?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 09:03:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:03:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGh4-0005gR-D3; Tue, 09 Dec 2014 09:02:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyGh2-0005gM-IL
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 09:02:52 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E8/30-09842-BBAB6845; Tue, 09 Dec 2014 09:02:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418115771!14358969!1
X-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 32417 invoked from network); 9 Dec 2014 09:02:51 -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; 9 Dec 2014 09:02:51 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 09:02:51 +0000
Message-Id: <5486C8C9020000780004DFDC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 09:02:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20141208212739.GA7226@laptop.dumpdata.com>
In-Reply-To: <20141208212739.GA7226@laptop.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen  4.5.0rc3 + Linux v3.18 + dom0pvh=1 = BOOM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 22:27, <konrad.wilk@oracle.com> wrote:
> [    8.761336] ------------[ cut here ]------------
> [    8.761342] kernel BUG at arch/x86/xen/smp.c:438!

	if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
		BUG();

> [    8.761348] invalid opcode: 0000 [#1] SMP 
> [    8.761355] Modules linked in:
> [    8.761362] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0 #1
> [    8.761369] Hardware name: LENOVO 10A6S09R01/SHARKBAY, BIOS FBKTA1AUS 10/22/2014
> [    8.761377] task: ffff8803ef058000 ti: ffff8803ef060000 task.ti: ffff8803ef060000
> [    8.761386] RIP: 0010:[<ffffffff810114c5>]  [<ffffffff810114c5>] xen_cpu_up+0x4c5/0x4d0
> [    8.761396] RSP: 0000:ffff8803ef063dd8  EFLAGS: 00010282
> [    8.761402] RAX: fffffffffffffff4 RBX: 0000000000000001 RCX: 0000000000000001

-ENOMEM

Very strange. I suppose that Dom0 kernel doesn't exhaust all of the
hypervisor's memory?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 09:04:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGiK-0005lH-89; Tue, 09 Dec 2014 09:04:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XyGiJ-0005l3-IJ
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:04:11 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	00/8C-25276-A0BB6845; Tue, 09 Dec 2014 09:04:10 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418115844!10899418!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10346 invoked from network); 9 Dec 2014 09:04:09 -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;
	9 Dec 2014 09:04:09 -0000
Received: from 172.24.2.119 (EHLO SZXEMA412-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDT03593; Tue, 09 Dec 2014 17:03:41 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.62]) by
	SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id
	14.03.0158.001; Tue, 9 Dec 2014 17:03:31 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIABdSnQgAA8hYCABNK9gP//un4AABZULrD//4uJAP/+OkDQ
Date: Tue, 9 Dec 2014 09:03:30 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2394DB98@SZXEMA512-MBX.china.huawei.com>
References: <20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
	<20141208101304.GB17128@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394C523@SZXEMA512-MBX.china.huawei.com>
	<20141208135534.GA21374@zion.uk.xensource.com>
In-Reply-To: <20141208135534.GA21374@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Mon, Dec 08, 2014 at 01:08:18PM +0000, Zhangleiqiang (Trump) wrote:
> > > On Mon, Dec 08, 2014 at 06:44:26AM +0000, Zhangleiqiang (Trump) wrote:
> > > > > On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump)
> wrote:
> > > > > [...]
> > By the way, after rethinking the testing results for multi-queue pv
> > (kernel 3.17.4+XEN 4.4) implementation, I find that when using four
> > queues for netback/netfront, there will be about 3 netback process
> > running with high CPU usage on receive Dom0 (about 85% usage per
> > process running on one CPU core), and the aggregate throughout is only
> > about 5Gbps. I doubt that there may be some bug or pitfall in current
> > multi-queue implementation, because for 5Gbps throughout, occurring
> > about all of 3 CPU core for packet receiving is somehow abnormal.
> >
> 
> 3.17.4 doesn't contain David Vrabel's fixes.
> 
> Look for
>   bc96f648df1bbc2729abbb84513cf4f64273a1f1
>   f48da8b14d04ca87ffcffe68829afd45f926ec6a
>   ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e
> in David Miller's net tree.

I have tried to testing with 3.18-rc5 which including these patches, however, it seems that the problem mentioned is not improved. There are still 3 netback receive processes each of which uses about 85% of CPU core.

> BTW there are some improvement planned for 4.6: "[Xen-devel] [PATCH v3 0/2]
> gnttab: Improve scaleability". This is orthogonal to the problem you're trying to
> solve but it should help improve performance in general.
> 
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 09:04:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGiJ-0005l8-Rj; Tue, 09 Dec 2014 09:04:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maomingya928@gmail.com>) id 1XyGiH-0005km-Ll
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:04:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FC/6C-25276-80BB6845; Tue, 09 Dec 2014 09:04:08 +0000
X-Env-Sender: maomingya928@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418115846!10899432!1
X-Originating-IP: [209.85.220.65]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10128 invoked from network); 9 Dec 2014 09:04:07 -0000
Received: from mail-pa0-f65.google.com (HELO mail-pa0-f65.google.com)
	(209.85.220.65)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 09:04:07 -0000
Received: by mail-pa0-f65.google.com with SMTP id et14so77800pad.0
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 01:04:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:subject:date:message-id:reply-to:user-agent:mime-version
	:content-type; bh=8Y9tsWGYR5/4VjFYXBpA1ASXc8EXvGt2DXSFd6NE5W8=;
	b=yitgyzh7KsTe9Au8gL9b5zQnxse2drgIqNUmt0mtvwImRNBzhxc66yviKhEsuwMuzH
	Qu45aXvKsaRn+qvYEwqP+0pBSYefu9KVjLsMYKuaYakQtJeNN61jqy6yQb28WgjLj1LJ
	OgdK3OS0bwI4TAKhJAGatKYK/63tQ50k6GO1ErCt5fnWEH9No9cCCv51DRHVsiqdcW5I
	oizVGJtTePo/9cbjME4O5HlzNFD7/YNhiAfw48YwGkVW/LnMaZ9D5IzdOI7mgw4Wf6HU
	usoXbnxFgnqPMFhWoQ+R//7WuA9atXKhXScRDMUyM6moTWJsY9ltok0DRvAYZwXiWGcb
	aIUw==
X-Received: by 10.70.48.166 with SMTP id m6mr29556115pdn.22.1418115844912;
	Tue, 09 Dec 2014 01:04:04 -0800 (PST)
Received: from [10.0.0.159] ([202.55.91.114])
	by mx.google.com with ESMTPSA id xq4sm865378pbb.21.2014.12.09.01.04.03
	for <xen-devel@lists.xen.org>
	(version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 09 Dec 2014 01:04:04 -0800 (PST)
From: "Mao Mingya" <maomingya928@gmail.com>
To: xen-devel@lists.xen.org
Date: Tue, 09 Dec 2014 09:04:00 +0000
Message-Id: <em1b3974e2-00ae-4a0a-89c1-d7218d4a1497@sgp1030c>
User-Agent: eM_Client/6.0.21040.0
Mime-Version: 1.0
Subject: [Xen-devel] help on qemu-xen for arch arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mao Mingya <maomingya928@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2074963247083072528=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2074963247083072528==
Content-Type: multipart/alternative;
 boundary="------=_MB0A97FC30-9D8D-4328-8661-97C83938EB58"


--------=_MB0A97FC30-9D8D-4328-8661-97C83938EB58
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I am trying to cross compile the qemu-xen for arm.

Followed the link below
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompil=
ing#Target_Environment

Built with the command
"CONFIG_SITE=3D/etc/dpkg-cross/cross-config.armhf ./configure=20
--build=3Dx86_64-unknown-linux-gnu --host=3Darm-linux-gnueabihf
--with-system-qemu"
" make dist-tools CROSS_COMPILE=3Darm-linux-gnueabihf-=20
XEN_TARGET_ARCH=3Darm32 "

I did not find the build process download and compile the qemu-xen as=20
described it in this link.
http://wiki.xen.org/wiki/QEMU_Upstream

Does anybody help on how to cross-compile the qemu-xen for arm?

Regards,
Mao
--------=_MB0A97FC30-9D8D-4328-8661-97C83938EB58
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<STYLE id=3DeMClientCss>
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; paddin=
g-top: 0px; }
.plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weigh=
t: normal; font-style: normal; }
a img { border: 0px; }body {font-family: Tahoma;font-size: 12pt;}
.plain pre, .plain tt {font-family: Tahoma;font-size: 12pt;}</STYLE>
</HEAD>
<BODY>I am trying to cross compile the qemu-xen for arm. <BR>&nbsp;<BR>Foll=
owed the link below <BR><A href=3D"http://wiki.xen.org/wiki/Xen_ARM_with_Vi=
rtualization_Extensions/CrossCompiling#Target_Environment">http://wiki.xen.=
org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling#Target_Envir=
onment</A> <BR>&nbsp;<BR>Built with the command <BR>"CONFIG_SITE=3D/etc/dpk=
g-cross/cross-config.armhf ./configure --build=3Dx86_64-unknown-linux-gnu=
 --host=3Darm-linux-gnueabihf <BR>--with-system-qemu" <BR>" make dist-tools=
 CROSS_COMPILE=3Darm-linux-gnueabihf- XEN_TARGET_ARCH=3Darm32 " <BR>&nbsp;<=
BR>I did not find the build process download and compile the qemu-xen as=
 described it in this link. <BR><A href=3D"http://wiki.xen.org/wiki/QEMU_Up=
stream">http://wiki.xen.org/wiki/QEMU_Upstream</A> <BR>&nbsp;<BR>Does anybo=
dy help on how to cross-compile the qemu-xen for arm? <BR>&nbsp;<BR>Regards=
, <BR>Mao </BODY></HTML>
--------=_MB0A97FC30-9D8D-4328-8661-97C83938EB58--



--===============2074963247083072528==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2074963247083072528==--



From xen-devel-bounces@lists.xen.org Tue Dec 09 09:04:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGiK-0005lH-89; Tue, 09 Dec 2014 09:04:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1XyGiJ-0005l3-IJ
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:04:11 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	00/8C-25276-A0BB6845; Tue, 09 Dec 2014 09:04:10 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418115844!10899418!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10346 invoked from network); 9 Dec 2014 09:04:09 -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;
	9 Dec 2014 09:04:09 -0000
Received: from 172.24.2.119 (EHLO SZXEMA412-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CDT03593; Tue, 09 Dec 2014 17:03:41 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.62]) by
	SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id
	14.03.0158.001; Tue, 9 Dec 2014 17:03:31 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] Poor network performance between DomU with
	multiqueue support
Thread-Index: AQHQDh95ofp9r8yimUqbpVEX+wSvTJx8Li7g//+BxYCAAK5KQP//kQwAgAH961CAANCjgIABdSnQgAA8hYCABNK9gP//un4AABZULrD//4uJAP/+OkDQ
Date: Tue, 9 Dec 2014 09:03:30 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE2394DB98@SZXEMA512-MBX.china.huawei.com>
References: <20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
	<20141208101304.GB17128@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394C523@SZXEMA512-MBX.china.huawei.com>
	<20141208135534.GA21374@zion.uk.xensource.com>
In-Reply-To: <20141208135534.GA21374@zion.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Xiaoding \(B\)" <xiaoding1@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>, "Yuzhou
	\(C\)" <vitas.yuzhou@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Mon, Dec 08, 2014 at 01:08:18PM +0000, Zhangleiqiang (Trump) wrote:
> > > On Mon, Dec 08, 2014 at 06:44:26AM +0000, Zhangleiqiang (Trump) wrote:
> > > > > On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump)
> wrote:
> > > > > [...]
> > By the way, after rethinking the testing results for multi-queue pv
> > (kernel 3.17.4+XEN 4.4) implementation, I find that when using four
> > queues for netback/netfront, there will be about 3 netback process
> > running with high CPU usage on receive Dom0 (about 85% usage per
> > process running on one CPU core), and the aggregate throughout is only
> > about 5Gbps. I doubt that there may be some bug or pitfall in current
> > multi-queue implementation, because for 5Gbps throughout, occurring
> > about all of 3 CPU core for packet receiving is somehow abnormal.
> >
> 
> 3.17.4 doesn't contain David Vrabel's fixes.
> 
> Look for
>   bc96f648df1bbc2729abbb84513cf4f64273a1f1
>   f48da8b14d04ca87ffcffe68829afd45f926ec6a
>   ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e
> in David Miller's net tree.

I have tried to testing with 3.18-rc5 which including these patches, however, it seems that the problem mentioned is not improved. There are still 3 netback receive processes each of which uses about 85% of CPU core.

> BTW there are some improvement planned for 4.6: "[Xen-devel] [PATCH v3 0/2]
> gnttab: Improve scaleability". This is orthogonal to the problem you're trying to
> solve but it should help improve performance in general.
> 
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 09:04:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGiJ-0005l8-Rj; Tue, 09 Dec 2014 09:04:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maomingya928@gmail.com>) id 1XyGiH-0005km-Ll
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:04:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FC/6C-25276-80BB6845; Tue, 09 Dec 2014 09:04:08 +0000
X-Env-Sender: maomingya928@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418115846!10899432!1
X-Originating-IP: [209.85.220.65]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10128 invoked from network); 9 Dec 2014 09:04:07 -0000
Received: from mail-pa0-f65.google.com (HELO mail-pa0-f65.google.com)
	(209.85.220.65)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 09:04:07 -0000
Received: by mail-pa0-f65.google.com with SMTP id et14so77800pad.0
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 01:04:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:subject:date:message-id:reply-to:user-agent:mime-version
	:content-type; bh=8Y9tsWGYR5/4VjFYXBpA1ASXc8EXvGt2DXSFd6NE5W8=;
	b=yitgyzh7KsTe9Au8gL9b5zQnxse2drgIqNUmt0mtvwImRNBzhxc66yviKhEsuwMuzH
	Qu45aXvKsaRn+qvYEwqP+0pBSYefu9KVjLsMYKuaYakQtJeNN61jqy6yQb28WgjLj1LJ
	OgdK3OS0bwI4TAKhJAGatKYK/63tQ50k6GO1ErCt5fnWEH9No9cCCv51DRHVsiqdcW5I
	oizVGJtTePo/9cbjME4O5HlzNFD7/YNhiAfw48YwGkVW/LnMaZ9D5IzdOI7mgw4Wf6HU
	usoXbnxFgnqPMFhWoQ+R//7WuA9atXKhXScRDMUyM6moTWJsY9ltok0DRvAYZwXiWGcb
	aIUw==
X-Received: by 10.70.48.166 with SMTP id m6mr29556115pdn.22.1418115844912;
	Tue, 09 Dec 2014 01:04:04 -0800 (PST)
Received: from [10.0.0.159] ([202.55.91.114])
	by mx.google.com with ESMTPSA id xq4sm865378pbb.21.2014.12.09.01.04.03
	for <xen-devel@lists.xen.org>
	(version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 09 Dec 2014 01:04:04 -0800 (PST)
From: "Mao Mingya" <maomingya928@gmail.com>
To: xen-devel@lists.xen.org
Date: Tue, 09 Dec 2014 09:04:00 +0000
Message-Id: <em1b3974e2-00ae-4a0a-89c1-d7218d4a1497@sgp1030c>
User-Agent: eM_Client/6.0.21040.0
Mime-Version: 1.0
Subject: [Xen-devel] help on qemu-xen for arch arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mao Mingya <maomingya928@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2074963247083072528=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2074963247083072528==
Content-Type: multipart/alternative;
 boundary="------=_MB0A97FC30-9D8D-4328-8661-97C83938EB58"


--------=_MB0A97FC30-9D8D-4328-8661-97C83938EB58
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I am trying to cross compile the qemu-xen for arm.

Followed the link below
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompil=
ing#Target_Environment

Built with the command
"CONFIG_SITE=3D/etc/dpkg-cross/cross-config.armhf ./configure=20
--build=3Dx86_64-unknown-linux-gnu --host=3Darm-linux-gnueabihf
--with-system-qemu"
" make dist-tools CROSS_COMPILE=3Darm-linux-gnueabihf-=20
XEN_TARGET_ARCH=3Darm32 "

I did not find the build process download and compile the qemu-xen as=20
described it in this link.
http://wiki.xen.org/wiki/QEMU_Upstream

Does anybody help on how to cross-compile the qemu-xen for arm?

Regards,
Mao
--------=_MB0A97FC30-9D8D-4328-8661-97C83938EB58
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<STYLE id=3DeMClientCss>
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; paddin=
g-top: 0px; }
.plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weigh=
t: normal; font-style: normal; }
a img { border: 0px; }body {font-family: Tahoma;font-size: 12pt;}
.plain pre, .plain tt {font-family: Tahoma;font-size: 12pt;}</STYLE>
</HEAD>
<BODY>I am trying to cross compile the qemu-xen for arm. <BR>&nbsp;<BR>Foll=
owed the link below <BR><A href=3D"http://wiki.xen.org/wiki/Xen_ARM_with_Vi=
rtualization_Extensions/CrossCompiling#Target_Environment">http://wiki.xen.=
org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling#Target_Envir=
onment</A> <BR>&nbsp;<BR>Built with the command <BR>"CONFIG_SITE=3D/etc/dpk=
g-cross/cross-config.armhf ./configure --build=3Dx86_64-unknown-linux-gnu=
 --host=3Darm-linux-gnueabihf <BR>--with-system-qemu" <BR>" make dist-tools=
 CROSS_COMPILE=3Darm-linux-gnueabihf- XEN_TARGET_ARCH=3Darm32 " <BR>&nbsp;<=
BR>I did not find the build process download and compile the qemu-xen as=
 described it in this link. <BR><A href=3D"http://wiki.xen.org/wiki/QEMU_Up=
stream">http://wiki.xen.org/wiki/QEMU_Upstream</A> <BR>&nbsp;<BR>Does anybo=
dy help on how to cross-compile the qemu-xen for arm? <BR>&nbsp;<BR>Regards=
, <BR>Mao </BODY></HTML>
--------=_MB0A97FC30-9D8D-4328-8661-97C83938EB58--



--===============2074963247083072528==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2074963247083072528==--



From xen-devel-bounces@lists.xen.org Tue Dec 09 09:07:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09: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 1XyGl5-00063G-Qt; Tue, 09 Dec 2014 09:07:03 +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 1XyGl4-000635-7j
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 09:07:02 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	A8/D3-09284-5BBB6845; Tue, 09 Dec 2014 09:07:01 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418116020!11859506!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16655 invoked from network); 9 Dec 2014 09:07:01 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 09:07:01 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so231206wgh.2
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 01:07: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=5LPT1NMIiJTJL0sryGopIFFdCBV4LYfkuwSyXZVqS6U=;
	b=H3p5xmvVmwuHHDNosJhnfQFHVPxo8aB8qV8fS/8NL2GQ0Z2KFj4uBQkv0p4AHXmq8R
	lWJ6B7ZGZhKT9KL3SxMVOldRkszzf+BPYTTdG/qmvhypb14+e31J+o1Xs3xp+BjgXcrB
	6s7hq8H/8Y868ZtgmR/F+osEiNJ2X2x+Syeui9O6qc3Ev7z95GZPeo+BF205eMwwv3Z0
	uiiif1MGE/8wTdjAzhyYiFMdso40nSpVdd8M820iZsusKT35h5SgvZv6obQd3t42dDQ0
	bmItw62eouG6358PVphf9dRAfZ6jghG0fcEZ0Q30JkeIcRmZzKw37Px8CMzD/UvNDwPB
	uAag==
X-Gm-Message-State: ALoCoQkcppNlEQD8MKs3VofHVy64YDRmubngtuFdBYNDxu26pZUZvuJnyNLIrBXht94s4OJAtMec
X-Received: by 10.194.57.43 with SMTP id f11mr3077887wjq.6.1418116020489;
	Tue, 09 Dec 2014 01:07:00 -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
	eu15sm1346634wid.18.2014.12.09.01.06.58 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 09 Dec 2014 01:06:59 -0800 (PST)
Message-ID: <5486BBB1.3040405@linaro.org>
Date: Tue, 09 Dec 2014 09:06: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.3.0
MIME-Version: 1.0
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>, hpa@zytor.com, 
	josh@joshtriplett.org, sam@ravnborg.org
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
	<1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
In-Reply-To: <1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, bpoirier@suse.de,
	Borislav Petkov <bp@suse.de>, levinsasha928@gmail.com,
	David Rientjes <rientjes@google.com>,
	xen-devel@lists.xenproject.org, fengguang.wu@intel.com,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Luis,

On 08/12/2014 23:05, Luis R. Rodriguez wrote:
> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
> new file mode 100644
> index 0000000..0d0eb6d
> --- /dev/null
> +++ b/kernel/configs/xen.config
> +CONFIG_XEN_MCE_LOG=y

MCE is x86 specific.

> +CONFIG_XEN_HAVE_PVMMU=y

We don't have PVMMU support on ARM. Shouldn't you move this config in 
architecture specific 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 Tue Dec 09 09:07:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09: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 1XyGl5-00063G-Qt; Tue, 09 Dec 2014 09:07:03 +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 1XyGl4-000635-7j
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 09:07:02 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	A8/D3-09284-5BBB6845; Tue, 09 Dec 2014 09:07:01 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418116020!11859506!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16655 invoked from network); 9 Dec 2014 09:07:01 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 09:07:01 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so231206wgh.2
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 01:07: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=5LPT1NMIiJTJL0sryGopIFFdCBV4LYfkuwSyXZVqS6U=;
	b=H3p5xmvVmwuHHDNosJhnfQFHVPxo8aB8qV8fS/8NL2GQ0Z2KFj4uBQkv0p4AHXmq8R
	lWJ6B7ZGZhKT9KL3SxMVOldRkszzf+BPYTTdG/qmvhypb14+e31J+o1Xs3xp+BjgXcrB
	6s7hq8H/8Y868ZtgmR/F+osEiNJ2X2x+Syeui9O6qc3Ev7z95GZPeo+BF205eMwwv3Z0
	uiiif1MGE/8wTdjAzhyYiFMdso40nSpVdd8M820iZsusKT35h5SgvZv6obQd3t42dDQ0
	bmItw62eouG6358PVphf9dRAfZ6jghG0fcEZ0Q30JkeIcRmZzKw37Px8CMzD/UvNDwPB
	uAag==
X-Gm-Message-State: ALoCoQkcppNlEQD8MKs3VofHVy64YDRmubngtuFdBYNDxu26pZUZvuJnyNLIrBXht94s4OJAtMec
X-Received: by 10.194.57.43 with SMTP id f11mr3077887wjq.6.1418116020489;
	Tue, 09 Dec 2014 01:07:00 -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
	eu15sm1346634wid.18.2014.12.09.01.06.58 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 09 Dec 2014 01:06:59 -0800 (PST)
Message-ID: <5486BBB1.3040405@linaro.org>
Date: Tue, 09 Dec 2014 09:06: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.3.0
MIME-Version: 1.0
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>, hpa@zytor.com, 
	josh@joshtriplett.org, sam@ravnborg.org
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
	<1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
In-Reply-To: <1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, bpoirier@suse.de,
	Borislav Petkov <bp@suse.de>, levinsasha928@gmail.com,
	David Rientjes <rientjes@google.com>,
	xen-devel@lists.xenproject.org, fengguang.wu@intel.com,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Luis,

On 08/12/2014 23:05, Luis R. Rodriguez wrote:
> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
> new file mode 100644
> index 0000000..0d0eb6d
> --- /dev/null
> +++ b/kernel/configs/xen.config
> +CONFIG_XEN_MCE_LOG=y

MCE is x86 specific.

> +CONFIG_XEN_HAVE_PVMMU=y

We don't have PVMMU support on ARM. Shouldn't you move this config in 
architecture specific 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 Tue Dec 09 09:10:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGnj-0006Dt-Tn; Tue, 09 Dec 2014 09:09:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyGnj-0006DX-6i
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:09:47 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	F4/0C-03148-95CB6845; Tue, 09 Dec 2014 09:09:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418116184!10520334!1
X-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 4885 invoked from network); 9 Dec 2014 09:09: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; 9 Dec 2014 09:09:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 09:09:44 +0000
Message-Id: <5486CA66020000780004DFF4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 09:09:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-12-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417448023-27311-12-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 11/19] xen: handle XENMEMF_get_vnumainfo
 in compat_memory_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> @@ -273,6 +276,33 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>              break;
>          }
>  
> +        case XENMEM_get_vnumainfo:
> +	{

Hard tab.

> +            enum XLAT_vnuma_topology_info_vdistance vdistance =
> +                XLAT_vnuma_topology_info_vdistance_h;
> +            enum XLAT_vnuma_topology_info_vcpu_to_vnode vcpu_to_vnode =
> +                XLAT_vnuma_topology_info_vcpu_to_vnode_h;
> +            enum XLAT_vnuma_topology_info_vmemrange vmemrange =
> +                XLAT_vnuma_topology_info_vmemrange_h;
> +
> +            if ( copy_from_guest(&cmp.vnuma, compat, 1) )
> +                return -EFAULT;
> +
> +#define XLAT_vnuma_topology_info_HNDL_vdistance_h(_d_, _s_)		\
> +            guest_from_compat_handle((_d_)->vdistance.h, (_s_)->vdistance.h)
> +#define XLAT_vnuma_topology_info_HNDL_vcpu_to_vnode_h(_d_, _s_)		\
> +            guest_from_compat_handle((_d_)->vcpu_to_vnode.h, (_s_)->vcpu_to_vnode.h)
> +#define XLAT_vnuma_topology_info_HNDL_vmemrange_h(_d_, _s_)		\
> +            guest_from_compat_handle((_d_)->vmemrange.h, (_s_)->vmemrange.h)
> +
> +            XLAT_vnuma_topology_info(nat.vnuma, &cmp.vnuma);
> +
> +#undef XLAT_vnuma_topology_info_HNDL_vdistance_h
> +#undef XLAT_vnuma_topology_info_HNDL_vcpu_to_vnode_h
> +#undef XLAT_vnuma_topology_info_HNDL_vmemrange_h
> +            break;
> +	}

Again.

With these two fixed and the subject adjusted to name the sub-op
correctly,
Reviewed-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 Dec 09 09:10:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGnj-0006Dl-Hz; Tue, 09 Dec 2014 09:09:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <groen692@grosc.com>) id 1XyGni-0006DY-6o
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:09:46 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	81/82-19763-95CB6845; Tue, 09 Dec 2014 09:09:45 +0000
X-Env-Sender: groen692@grosc.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418116183!6989710!1
X-Originating-IP: [74.50.18.10]
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 20209 invoked from network); 9 Dec 2014 09:09:45 -0000
Received: from carp.lunarservers.com (HELO carp.lunarservers.com) (74.50.18.10)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2014 09:09:45 -0000
Received: from [194.219.126.84] (port=52157 helo=[172.16.0.20])
	by carp.lunarservers.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128)
	(Exim 4.82) (envelope-from <groen692@grosc.com>)
	id 1XyGnc-00029l-Bq; Tue, 09 Dec 2014 01:09:40 -0800
Message-ID: <5486BC53.2080608@grosc.com>
Date: Tue, 09 Dec 2014 10:09:39 +0100
From: Jeroen Groenewegen van der Weyden <groen692@grosc.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>, 
	Jan Beulich <JBeulich@suse.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>
	<CAFLBxZZ5itYWTDsnkGHzy0_4SWU6QMXnVpkYAFMOH+wG+5MKJQ@mail.gmail.com>
In-Reply-To: <CAFLBxZZ5itYWTDsnkGHzy0_4SWU6QMXnVpkYAFMOH+wG+5MKJQ@mail.gmail.com>
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - carp.lunarservers.com
X-AntiAbuse: Original Domain - lists.xen.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - grosc.com
X-Get-Message-Sender-Via: carp.lunarservers.com: authenticated_id:
	servicedesk@grosc.com
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
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-Transfer-Encoding: 7bit
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,

Did anyone find the time yet? I'm still more then willing testing any 
patches.

BR,
Jeroen.

George Dunlap schreef op 3-11-2014 om 12:16:
> 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 Tue Dec 09 09:10:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGnj-0006Dt-Tn; Tue, 09 Dec 2014 09:09:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyGnj-0006DX-6i
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:09:47 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	F4/0C-03148-95CB6845; Tue, 09 Dec 2014 09:09:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418116184!10520334!1
X-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 4885 invoked from network); 9 Dec 2014 09:09: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; 9 Dec 2014 09:09:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 09:09:44 +0000
Message-Id: <5486CA66020000780004DFF4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 09:09:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-12-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417448023-27311-12-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 11/19] xen: handle XENMEMF_get_vnumainfo
 in compat_memory_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> @@ -273,6 +276,33 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>              break;
>          }
>  
> +        case XENMEM_get_vnumainfo:
> +	{

Hard tab.

> +            enum XLAT_vnuma_topology_info_vdistance vdistance =
> +                XLAT_vnuma_topology_info_vdistance_h;
> +            enum XLAT_vnuma_topology_info_vcpu_to_vnode vcpu_to_vnode =
> +                XLAT_vnuma_topology_info_vcpu_to_vnode_h;
> +            enum XLAT_vnuma_topology_info_vmemrange vmemrange =
> +                XLAT_vnuma_topology_info_vmemrange_h;
> +
> +            if ( copy_from_guest(&cmp.vnuma, compat, 1) )
> +                return -EFAULT;
> +
> +#define XLAT_vnuma_topology_info_HNDL_vdistance_h(_d_, _s_)		\
> +            guest_from_compat_handle((_d_)->vdistance.h, (_s_)->vdistance.h)
> +#define XLAT_vnuma_topology_info_HNDL_vcpu_to_vnode_h(_d_, _s_)		\
> +            guest_from_compat_handle((_d_)->vcpu_to_vnode.h, (_s_)->vcpu_to_vnode.h)
> +#define XLAT_vnuma_topology_info_HNDL_vmemrange_h(_d_, _s_)		\
> +            guest_from_compat_handle((_d_)->vmemrange.h, (_s_)->vmemrange.h)
> +
> +            XLAT_vnuma_topology_info(nat.vnuma, &cmp.vnuma);
> +
> +#undef XLAT_vnuma_topology_info_HNDL_vdistance_h
> +#undef XLAT_vnuma_topology_info_HNDL_vcpu_to_vnode_h
> +#undef XLAT_vnuma_topology_info_HNDL_vmemrange_h
> +            break;
> +	}

Again.

With these two fixed and the subject adjusted to name the sub-op
correctly,
Reviewed-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 Dec 09 09:10:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGnj-0006Dl-Hz; Tue, 09 Dec 2014 09:09:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <groen692@grosc.com>) id 1XyGni-0006DY-6o
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:09:46 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	81/82-19763-95CB6845; Tue, 09 Dec 2014 09:09:45 +0000
X-Env-Sender: groen692@grosc.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418116183!6989710!1
X-Originating-IP: [74.50.18.10]
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 20209 invoked from network); 9 Dec 2014 09:09:45 -0000
Received: from carp.lunarservers.com (HELO carp.lunarservers.com) (74.50.18.10)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2014 09:09:45 -0000
Received: from [194.219.126.84] (port=52157 helo=[172.16.0.20])
	by carp.lunarservers.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128)
	(Exim 4.82) (envelope-from <groen692@grosc.com>)
	id 1XyGnc-00029l-Bq; Tue, 09 Dec 2014 01:09:40 -0800
Message-ID: <5486BC53.2080608@grosc.com>
Date: Tue, 09 Dec 2014 10:09:39 +0100
From: Jeroen Groenewegen van der Weyden <groen692@grosc.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>, 
	Jan Beulich <JBeulich@suse.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>
	<CAFLBxZZ5itYWTDsnkGHzy0_4SWU6QMXnVpkYAFMOH+wG+5MKJQ@mail.gmail.com>
In-Reply-To: <CAFLBxZZ5itYWTDsnkGHzy0_4SWU6QMXnVpkYAFMOH+wG+5MKJQ@mail.gmail.com>
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - carp.lunarservers.com
X-AntiAbuse: Original Domain - lists.xen.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - grosc.com
X-Get-Message-Sender-Via: carp.lunarservers.com: authenticated_id:
	servicedesk@grosc.com
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
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-Transfer-Encoding: 7bit
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,

Did anyone find the time yet? I'm still more then willing testing any 
patches.

BR,
Jeroen.

George Dunlap schreef op 3-11-2014 om 12:16:
> 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 Tue Dec 09 09:12:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09: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 1XyGqA-0006WV-Et; Tue, 09 Dec 2014 09:12:18 +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 1XyGq8-0006WG-PK
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:12:16 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	96/5B-22737-0FCB6845; Tue, 09 Dec 2014 09:12:16 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418116334!12275168!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1576 invoked from network); 9 Dec 2014 09:12:15 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-206.messagelabs.com with SMTP;
	9 Dec 2014 09:12:15 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 09 Dec 2014 01:12:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,543,1413270000"; d="scan'208";a="620875906"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.208])
	([10.238.128.208])
	by orsmga001.jf.intel.com with ESMTP; 09 Dec 2014 01:12:08 -0800
Message-ID: <5486BCE8.3010900@intel.com>
Date: Tue, 09 Dec 2014 17:12:08 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
In-Reply-To: <5486BE99020000780004DF8A@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/9 16:19, Jan Beulich wrote:
>>>> On 09.12.14 at 08:47, <tiejun.chen@intel.com> wrote:
>> On 2014/12/8 16:51, Jan Beulich wrote:
>>> The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
>>> is identical and can be factored out pretty easily afaict.
>>
>> What about this?
>>
>> 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,
>>                                         u32 id, void *ctxt)
>> {
>>       struct get_reserved_device_memory *grdm = ctxt;
>>       struct domain *d = grdm->domain;
>>       unsigned int i, hit_one = 0;
>>       u32 sbdf;
>>       struct xen_reserved_device_memory rdm = {
>>           .start_pfn = start, .nr_pages = nr
>>       };
>>
>>       if ( !d->arch.hvm_domain.pci_force )
>>       {
>>           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 )
>>               {
>>                   hit_one = 1;
>>                   break;
>>               }
>>           }
>>
>>           if ( !hit_one )
>>               return 0;
>>       }
>
> Why do you always pick other than the simplest possible solution?

I don't intend it to be, but I may go a complicated way, even a wrong 
way, based on my understanding. But as one main maintainer, if you 
always say to me in such a reproachful word more than once, I have to 
consider you may hint constantly I'm not a suitable candidate to finish 
this. Its fair to me, I'd really like to quit this to ask my manager if 
it can deliver to other guy to make sure this can move forward.

> You don't need a separate variable here, you can simply check
> whether i reached d->arch.hvm_domain.num_pcidevs after the
> loop. And even if you added a variable, it would want to be a

Are you saying this?

	if ( i == d->arch.hvm_domain.num_pcidevs )
		return 0;

But if the last one happens to one hit, 'i' is equal to 
d->arch.hvm_domain.num_pcidevs.

Thanks
Tiejun

> bool_t one with the way you use 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 Dec 09 09:12:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09: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 1XyGqA-0006WV-Et; Tue, 09 Dec 2014 09:12:18 +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 1XyGq8-0006WG-PK
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:12:16 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	96/5B-22737-0FCB6845; Tue, 09 Dec 2014 09:12:16 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418116334!12275168!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1576 invoked from network); 9 Dec 2014 09:12:15 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-206.messagelabs.com with SMTP;
	9 Dec 2014 09:12:15 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 09 Dec 2014 01:12:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,543,1413270000"; d="scan'208";a="620875906"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.208])
	([10.238.128.208])
	by orsmga001.jf.intel.com with ESMTP; 09 Dec 2014 01:12:08 -0800
Message-ID: <5486BCE8.3010900@intel.com>
Date: Tue, 09 Dec 2014 17:12:08 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
In-Reply-To: <5486BE99020000780004DF8A@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/9 16:19, Jan Beulich wrote:
>>>> On 09.12.14 at 08:47, <tiejun.chen@intel.com> wrote:
>> On 2014/12/8 16:51, Jan Beulich wrote:
>>> The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
>>> is identical and can be factored out pretty easily afaict.
>>
>> What about this?
>>
>> 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,
>>                                         u32 id, void *ctxt)
>> {
>>       struct get_reserved_device_memory *grdm = ctxt;
>>       struct domain *d = grdm->domain;
>>       unsigned int i, hit_one = 0;
>>       u32 sbdf;
>>       struct xen_reserved_device_memory rdm = {
>>           .start_pfn = start, .nr_pages = nr
>>       };
>>
>>       if ( !d->arch.hvm_domain.pci_force )
>>       {
>>           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 )
>>               {
>>                   hit_one = 1;
>>                   break;
>>               }
>>           }
>>
>>           if ( !hit_one )
>>               return 0;
>>       }
>
> Why do you always pick other than the simplest possible solution?

I don't intend it to be, but I may go a complicated way, even a wrong 
way, based on my understanding. But as one main maintainer, if you 
always say to me in such a reproachful word more than once, I have to 
consider you may hint constantly I'm not a suitable candidate to finish 
this. Its fair to me, I'd really like to quit this to ask my manager if 
it can deliver to other guy to make sure this can move forward.

> You don't need a separate variable here, you can simply check
> whether i reached d->arch.hvm_domain.num_pcidevs after the
> loop. And even if you added a variable, it would want to be a

Are you saying this?

	if ( i == d->arch.hvm_domain.num_pcidevs )
		return 0;

But if the last one happens to one hit, 'i' is equal to 
d->arch.hvm_domain.num_pcidevs.

Thanks
Tiejun

> bool_t one with the way you use 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 Dec 09 09:12:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09: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 1XyGqI-0006YD-RX; Tue, 09 Dec 2014 09:12:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyGqH-0006Xb-KJ
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 09:12:25 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	27/D7-25547-8FCB6845; Tue, 09 Dec 2014 09:12:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418116344!11991303!1
X-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 21361 invoked from network); 9 Dec 2014 09:12:24 -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; 9 Dec 2014 09:12:24 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 09:12:23 +0000
Message-Id: <5486CB05020000780004DFF7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 09:12:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <1417794612-27702-1-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1417794612-27702-1-git-send-email-daniel.kiper@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] console: increase initial conring 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 05.12.14 at 16:50, <daniel.kiper@oracle.com> wrote:
> In general initial conring size is sufficient. However, if log
> level is increased on platforms which have e.g. huge number
> of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
> which has more than 200 entries in EFI memory map) then some
> of earlier messages in console ring are overwritten. It means
> that in case of issues deeper analysis can be hindered. Sadly
> conring_size argument does not help because new console buffer
> is allocated late on heap. It means that it is not possible to
> allocate larger ring earlier. So, in this situation initial
> conring size should be increased. My experiments showed that
> even on not so big machines more than 26 KiB of free space are
> needed for initial messages. In theory we could increase conring
> size buffer to 32 KiB. However, I think that this value could be
> too small for huge machines with large number of ACPI tables and
> EFI memory regions. Hence, this patch increases initial conring
> size to 64 KiB.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

Actually meanwhile I spotted a (minor) downside to this approach:
It raises the lower limit of the permanent ring size to 64k 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 Dec 09 09:12:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09: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 1XyGqI-0006YD-RX; Tue, 09 Dec 2014 09:12:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyGqH-0006Xb-KJ
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 09:12:25 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	27/D7-25547-8FCB6845; Tue, 09 Dec 2014 09:12:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418116344!11991303!1
X-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 21361 invoked from network); 9 Dec 2014 09:12:24 -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; 9 Dec 2014 09:12:24 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 09:12:23 +0000
Message-Id: <5486CB05020000780004DFF7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 09:12:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <1417794612-27702-1-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1417794612-27702-1-git-send-email-daniel.kiper@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] console: increase initial conring 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 05.12.14 at 16:50, <daniel.kiper@oracle.com> wrote:
> In general initial conring size is sufficient. However, if log
> level is increased on platforms which have e.g. huge number
> of memory regions (I have an IBM System x3550 M2 with 8 GiB RAM
> which has more than 200 entries in EFI memory map) then some
> of earlier messages in console ring are overwritten. It means
> that in case of issues deeper analysis can be hindered. Sadly
> conring_size argument does not help because new console buffer
> is allocated late on heap. It means that it is not possible to
> allocate larger ring earlier. So, in this situation initial
> conring size should be increased. My experiments showed that
> even on not so big machines more than 26 KiB of free space are
> needed for initial messages. In theory we could increase conring
> size buffer to 32 KiB. However, I think that this value could be
> too small for huge machines with large number of ACPI tables and
> EFI memory regions. Hence, this patch increases initial conring
> size to 64 KiB.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

Actually meanwhile I spotted a (minor) downside to this approach:
It raises the lower limit of the permanent ring size to 64k 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 Dec 09 09:18:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:18:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGvd-00070D-La; Tue, 09 Dec 2014 09:17: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 1XyGvc-000708-Um
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:17:57 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	88/37-25714-44EB6845; Tue, 09 Dec 2014 09:17:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418116675!4701057!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24304 invoked from network); 9 Dec 2014 09:17:55 -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; 9 Dec 2014 09:17:55 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 09:17:55 +0000
Message-Id: <5486CC51020000780004E01A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 09:17:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeroen Groenewegen van der Weyden" <groen692@grosc.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>
	<CAFLBxZZ5itYWTDsnkGHzy0_4SWU6QMXnVpkYAFMOH+wG+5MKJQ@mail.gmail.com>
	<5486BC53.2080608@grosc.com>
In-Reply-To: <5486BC53.2080608@grosc.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Eddie Dong <eddie.dong@intel.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 09.12.14 at 10:09, <groen692@grosc.com> wrote:
> Did anyone find the time yet? I'm still more then willing testing any 
> patches.

Just yesterday we were told by Intel that they still can't foresee when
they will find time.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 09:18:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:18:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGvd-00070D-La; Tue, 09 Dec 2014 09:17: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 1XyGvc-000708-Um
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:17:57 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	88/37-25714-44EB6845; Tue, 09 Dec 2014 09:17:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418116675!4701057!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24304 invoked from network); 9 Dec 2014 09:17:55 -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; 9 Dec 2014 09:17:55 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 09:17:55 +0000
Message-Id: <5486CC51020000780004E01A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 09:17:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeroen Groenewegen van der Weyden" <groen692@grosc.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>
	<CAFLBxZZ5itYWTDsnkGHzy0_4SWU6QMXnVpkYAFMOH+wG+5MKJQ@mail.gmail.com>
	<5486BC53.2080608@grosc.com>
In-Reply-To: <5486BC53.2080608@grosc.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Eddie Dong <eddie.dong@intel.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 09.12.14 at 10:09, <groen692@grosc.com> wrote:
> Did anyone find the time yet? I'm still more then willing testing any 
> patches.

Just yesterday we were told by Intel that they still can't foresee when
they will find time.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 09:21:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:21:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGz7-0007AI-CU; Tue, 09 Dec 2014 09:21: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 1XyGz5-0007AA-K2
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:21:31 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	20/C9-09842-A1FB6845; Tue, 09 Dec 2014 09:21:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418116888!14316307!1
X-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 20799 invoked from network); 9 Dec 2014 09:21:28 -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; 9 Dec 2014 09:21:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 09:21:27 +0000
Message-Id: <5486CD25020000780004E026@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 09:21:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<5486BCE8.3010900@intel.com>
In-Reply-To: <5486BCE8.3010900@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 10:12, <tiejun.chen@intel.com> wrote:
> On 2014/12/9 16:19, Jan Beulich wrote:
>>>>> On 09.12.14 at 08:47, <tiejun.chen@intel.com> wrote:
>>> On 2014/12/8 16:51, Jan Beulich wrote:
>>>> The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
>>>> is identical and can be factored out pretty easily afaict.
>>>
>>> What about this?
>>>
>>> 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,
>>>                                         u32 id, void *ctxt)
>>> {
>>>       struct get_reserved_device_memory *grdm = ctxt;
>>>       struct domain *d = grdm->domain;
>>>       unsigned int i, hit_one = 0;
>>>       u32 sbdf;
>>>       struct xen_reserved_device_memory rdm = {
>>>           .start_pfn = start, .nr_pages = nr
>>>       };
>>>
>>>       if ( !d->arch.hvm_domain.pci_force )
>>>       {
>>>           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 )
>>>               {
>>>                   hit_one = 1;
>>>                   break;
>>>               }
>>>           }
>>>
>>>           if ( !hit_one )
>>>               return 0;
>>>       }
>>
>> Why do you always pick other than the simplest possible solution?
> 
> I don't intend it to be, but I may go a complicated way, even a wrong 
> way, based on my understanding. But as one main maintainer, if you 
> always say to me in such a reproachful word more than once, I have to 
> consider you may hint constantly I'm not a suitable candidate to finish 
> this. Its fair to me, I'd really like to quit this to ask my manager if 
> it can deliver to other guy to make sure this can move forward.
> 
>> You don't need a separate variable here, you can simply check
>> whether i reached d->arch.hvm_domain.num_pcidevs after the
>> loop. And even if you added a variable, it would want to be a
> 
> Are you saying this?
> 
> 	if ( i == d->arch.hvm_domain.num_pcidevs )
> 		return 0;

Yes. Or use >=.

> But if the last one happens to one hit, 'i' is equal to 
> d->arch.hvm_domain.num_pcidevs.

No, when the last one hits, i == d->arch.hvm_domain.num_pcidevs - 1.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 09:21:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:21:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyGz7-0007AI-CU; Tue, 09 Dec 2014 09:21: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 1XyGz5-0007AA-K2
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:21:31 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	20/C9-09842-A1FB6845; Tue, 09 Dec 2014 09:21:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418116888!14316307!1
X-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 20799 invoked from network); 9 Dec 2014 09:21:28 -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; 9 Dec 2014 09:21:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 09:21:27 +0000
Message-Id: <5486CD25020000780004E026@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 09:21:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<5486BCE8.3010900@intel.com>
In-Reply-To: <5486BCE8.3010900@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 10:12, <tiejun.chen@intel.com> wrote:
> On 2014/12/9 16:19, Jan Beulich wrote:
>>>>> On 09.12.14 at 08:47, <tiejun.chen@intel.com> wrote:
>>> On 2014/12/8 16:51, Jan Beulich wrote:
>>>> The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
>>>> is identical and can be factored out pretty easily afaict.
>>>
>>> What about this?
>>>
>>> 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,
>>>                                         u32 id, void *ctxt)
>>> {
>>>       struct get_reserved_device_memory *grdm = ctxt;
>>>       struct domain *d = grdm->domain;
>>>       unsigned int i, hit_one = 0;
>>>       u32 sbdf;
>>>       struct xen_reserved_device_memory rdm = {
>>>           .start_pfn = start, .nr_pages = nr
>>>       };
>>>
>>>       if ( !d->arch.hvm_domain.pci_force )
>>>       {
>>>           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 )
>>>               {
>>>                   hit_one = 1;
>>>                   break;
>>>               }
>>>           }
>>>
>>>           if ( !hit_one )
>>>               return 0;
>>>       }
>>
>> Why do you always pick other than the simplest possible solution?
> 
> I don't intend it to be, but I may go a complicated way, even a wrong 
> way, based on my understanding. But as one main maintainer, if you 
> always say to me in such a reproachful word more than once, I have to 
> consider you may hint constantly I'm not a suitable candidate to finish 
> this. Its fair to me, I'd really like to quit this to ask my manager if 
> it can deliver to other guy to make sure this can move forward.
> 
>> You don't need a separate variable here, you can simply check
>> whether i reached d->arch.hvm_domain.num_pcidevs after the
>> loop. And even if you added a variable, it would want to be a
> 
> Are you saying this?
> 
> 	if ( i == d->arch.hvm_domain.num_pcidevs )
> 		return 0;

Yes. Or use >=.

> But if the last one happens to one hit, 'i' is equal to 
> d->arch.hvm_domain.num_pcidevs.

No, when the last one hits, i == d->arch.hvm_domain.num_pcidevs - 1.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 09:36:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:36:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyHCn-0007nZ-P9; Tue, 09 Dec 2014 09:35:41 +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 1XyHCl-0007nU-LN
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:35:39 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	F4/16-25727-A62C6845; Tue, 09 Dec 2014 09:35:38 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418117737!12014606!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 24775 invoked from network); 9 Dec 2014 09:35:38 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-31.messagelabs.com with SMTP;
	9 Dec 2014 09:35:38 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 09 Dec 2014 01:34:17 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,543,1413270000"; d="scan'208";a="620884300"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.208])
	([10.238.128.208])
	by orsmga001.jf.intel.com with ESMTP; 09 Dec 2014 01:35:34 -0800
Message-ID: <5486C265.9040205@intel.com>
Date: Tue, 09 Dec 2014 17:35: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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<5486BCE8.3010900@intel.com>
	<5486CD25020000780004E026@mail.emea.novell.com>
In-Reply-To: <5486CD25020000780004E026@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/9 17:21, Jan Beulich wrote:
>>>> On 09.12.14 at 10:12, <tiejun.chen@intel.com> wrote:
>> On 2014/12/9 16:19, Jan Beulich wrote:
>>>>>> On 09.12.14 at 08:47, <tiejun.chen@intel.com> wrote:
>>>> On 2014/12/8 16:51, Jan Beulich wrote:
>>>>> The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
>>>>> is identical and can be factored out pretty easily afaict.
>>>>
>>>> What about this?
>>>>
>>>> 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,
>>>>                                          u32 id, void *ctxt)
>>>> {
>>>>        struct get_reserved_device_memory *grdm = ctxt;
>>>>        struct domain *d = grdm->domain;
>>>>        unsigned int i, hit_one = 0;
>>>>        u32 sbdf;
>>>>        struct xen_reserved_device_memory rdm = {
>>>>            .start_pfn = start, .nr_pages = nr
>>>>        };
>>>>
>>>>        if ( !d->arch.hvm_domain.pci_force )
>>>>        {
>>>>            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 )
>>>>                {
>>>>                    hit_one = 1;
>>>>                    break;
>>>>                }
>>>>            }
>>>>
>>>>            if ( !hit_one )
>>>>                return 0;
>>>>        }
>>>
>>> Why do you always pick other than the simplest possible solution?
>>
>> I don't intend it to be, but I may go a complicated way, even a wrong
>> way, based on my understanding. But as one main maintainer, if you
>> always say to me in such a reproachful word more than once, I have to
>> consider you may hint constantly I'm not a suitable candidate to finish
>> this. Its fair to me, I'd really like to quit this to ask my manager if
>> it can deliver to other guy to make sure this can move forward.
>>
>>> You don't need a separate variable here, you can simply check
>>> whether i reached d->arch.hvm_domain.num_pcidevs after the
>>> loop. And even if you added a variable, it would want to be a
>>
>> Are you saying this?
>>
>> 	if ( i == d->arch.hvm_domain.num_pcidevs )
>> 		return 0;
>
> Yes. Or use >=.

Okay.

>
>> But if the last one happens to one hit, 'i' is equal to
>> d->arch.hvm_domain.num_pcidevs.
>
> No, when the last one hits, i == d->arch.hvm_domain.num_pcidevs - 1.
>

You're 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 Tue Dec 09 09:36:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:36:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyHCn-0007nZ-P9; Tue, 09 Dec 2014 09:35:41 +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 1XyHCl-0007nU-LN
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:35:39 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	F4/16-25727-A62C6845; Tue, 09 Dec 2014 09:35:38 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418117737!12014606!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 24775 invoked from network); 9 Dec 2014 09:35:38 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-31.messagelabs.com with SMTP;
	9 Dec 2014 09:35:38 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 09 Dec 2014 01:34:17 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,543,1413270000"; d="scan'208";a="620884300"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.208])
	([10.238.128.208])
	by orsmga001.jf.intel.com with ESMTP; 09 Dec 2014 01:35:34 -0800
Message-ID: <5486C265.9040205@intel.com>
Date: Tue, 09 Dec 2014 17:35: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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<5486BCE8.3010900@intel.com>
	<5486CD25020000780004E026@mail.emea.novell.com>
In-Reply-To: <5486CD25020000780004E026@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/9 17:21, Jan Beulich wrote:
>>>> On 09.12.14 at 10:12, <tiejun.chen@intel.com> wrote:
>> On 2014/12/9 16:19, Jan Beulich wrote:
>>>>>> On 09.12.14 at 08:47, <tiejun.chen@intel.com> wrote:
>>>> On 2014/12/8 16:51, Jan Beulich wrote:
>>>>> The whole "if-copy-unlock-and-return-EFAULT-otherwise-increment"
>>>>> is identical and can be factored out pretty easily afaict.
>>>>
>>>> What about this?
>>>>
>>>> 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,
>>>>                                          u32 id, void *ctxt)
>>>> {
>>>>        struct get_reserved_device_memory *grdm = ctxt;
>>>>        struct domain *d = grdm->domain;
>>>>        unsigned int i, hit_one = 0;
>>>>        u32 sbdf;
>>>>        struct xen_reserved_device_memory rdm = {
>>>>            .start_pfn = start, .nr_pages = nr
>>>>        };
>>>>
>>>>        if ( !d->arch.hvm_domain.pci_force )
>>>>        {
>>>>            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 )
>>>>                {
>>>>                    hit_one = 1;
>>>>                    break;
>>>>                }
>>>>            }
>>>>
>>>>            if ( !hit_one )
>>>>                return 0;
>>>>        }
>>>
>>> Why do you always pick other than the simplest possible solution?
>>
>> I don't intend it to be, but I may go a complicated way, even a wrong
>> way, based on my understanding. But as one main maintainer, if you
>> always say to me in such a reproachful word more than once, I have to
>> consider you may hint constantly I'm not a suitable candidate to finish
>> this. Its fair to me, I'd really like to quit this to ask my manager if
>> it can deliver to other guy to make sure this can move forward.
>>
>>> You don't need a separate variable here, you can simply check
>>> whether i reached d->arch.hvm_domain.num_pcidevs after the
>>> loop. And even if you added a variable, it would want to be a
>>
>> Are you saying this?
>>
>> 	if ( i == d->arch.hvm_domain.num_pcidevs )
>> 		return 0;
>
> Yes. Or use >=.

Okay.

>
>> But if the last one happens to one hit, 'i' is equal to
>> d->arch.hvm_domain.num_pcidevs.
>
> No, when the last one hits, i == d->arch.hvm_domain.num_pcidevs - 1.
>

You're 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 Tue Dec 09 09:52:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyHSS-0008CX-AQ; Tue, 09 Dec 2014 09:51: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 1XyHSR-0008CS-EC
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:51:51 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	37/B7-05632-636C6845; Tue, 09 Dec 2014 09:51:50 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418118709!12014291!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7701 invoked from network); 9 Dec 2014 09:51:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 09:51:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,543,1413244800"; d="scan'208";a="27655249"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
Thread-Index: AQHQExocwcjzGsZkOUqthQ4j+f4MKJyGDEkAgABI3ICAAK/GQA==
Date: Tue, 9 Dec 2014 09:51:48 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD02578569D@AMSPEX01CL01.citrite.net>
References: <5485F5F7.6040206@citrix.com>
	<20141208200034.GA3891@laptop.dumpdata.com>
	<54864081.6090606@citrix.com>
In-Reply-To: <54864081.6090606@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 List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Andrew Cooper
> Sent: 09 December 2014 00:21
> To: Konrad Rzeszutek Wilk
> Cc: Xen-devel List
> Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
> 
> On 08/12/2014 20:00, Konrad Rzeszutek Wilk wrote:
> > On Mon, Dec 08, 2014 at 07:03:19PM +0000, Andrew Cooper wrote:
> >> Hi,
> > Hey Andrew!
> >> Over the weekend, XenServer testing managed to run a side-by-side test
> >> of XenServer trunk and XenServer experimental xen-4.5.  These are
> >> identical other than the version of Xen (and associated libraries) in
> >> use, i.e. identical dom0 kernel, Xapi toolstack and dom0 userspace,
> >> other than as linked against newer Xen libraries.
> >>
> >> The Xen-4.5 tests were on top of c/s e6c3d371d4 "systemd: use pkg-
> config
> >> to determine systemd library availability"
> >>
> >> There are a few notable issues exposed:
> >>
> >> XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it
> didn't in
> >> xen-4.4, given identical parameters.  The hypercall gained an extra
> >> permission check as part of 0561e1f01e.  Our usecase here is a daemon in
> >> dom0 mapping guest RAM to emulate a graphics card, but I currently don't
> >> see how that is incompatible with the new permissions check.
> > I presume the daemon also does 'XEN_DOMCTL_iomem_permission' to
> grant
> > the other domain access to its RAM? And before it makes the
> > XEN_DOMCTL_memory_mapping hypercall.
> 
> This is purely an implementer of the ioreq server infrastructure
> providing an emulated set of BARs in the guest as qemu would, but
> without using dom0 map-foreign powers.  The gfn ranges in question are
> regular guest RAM as far as I am aware, and should not require any
> special io permissions.

IIRC the ranges in question are sections of BAR on the GPU which the dom0 code is trying to inject into the guest.

  Paul

> 
> Either way, the identified changeset has apparently caused a regression,
> but I am not yet certain whether it is legitimately disabling something
> which should not have worked in the first place, or whether it is a
> change which needs reconsidering.
> 
> >
> >> Migrations from older Xens to Xen-4.5 fairly reliably crash domains (90%
> >> of the time, both PV and HVM guests).  This includes migrates from older
> >> XenServers using the legacy->v2 migration code which is confirmed-good
> >> in "upgrade to Xen-4.4" case.  The migration v2 code in use is identical.
> > The XenServer is not using the in-the-tree migration system except in
> > the older version of XenServer right?
> 
> XenServer expermental-4.5 is strictly using migration v2, including
> upgrade from legacy, but as far as I am aware identical migration v2 as
> our current Xen-4.4 trunk which works fine for all tests.
> 
> >> We have certain machines which are showing reliable failure to boot
> >> under Xen-4.5, where they worked with 4.4.  Symptoms range from the
> dom0
> >> kernel crashing before printing anything, to complaining that the initrd
> >> is corrupt when attempting to decompress.  This appears to be hardware
> >> specific.
> > Hardware specific is good. Could you give some ideas of what make/model
> > this is?
> 
> They are all IBM blades to the best of my knowledge, which are a similar
> system to the hardware which gave me 1ed7679 to debug, so I am hoping it
> is a latent BIOS issue and not a Xen 4.5 issue.
> 
> ~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 Tue Dec 09 09:52:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyHSS-0008CX-AQ; Tue, 09 Dec 2014 09:51: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 1XyHSR-0008CS-EC
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 09:51:51 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	37/B7-05632-636C6845; Tue, 09 Dec 2014 09:51:50 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418118709!12014291!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7701 invoked from network); 9 Dec 2014 09:51:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 09:51:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,543,1413244800"; d="scan'208";a="27655249"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
Thread-Index: AQHQExocwcjzGsZkOUqthQ4j+f4MKJyGDEkAgABI3ICAAK/GQA==
Date: Tue, 9 Dec 2014 09:51:48 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD02578569D@AMSPEX01CL01.citrite.net>
References: <5485F5F7.6040206@citrix.com>
	<20141208200034.GA3891@laptop.dumpdata.com>
	<54864081.6090606@citrix.com>
In-Reply-To: <54864081.6090606@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 List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Andrew Cooper
> Sent: 09 December 2014 00:21
> To: Konrad Rzeszutek Wilk
> Cc: Xen-devel List
> Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
> 
> On 08/12/2014 20:00, Konrad Rzeszutek Wilk wrote:
> > On Mon, Dec 08, 2014 at 07:03:19PM +0000, Andrew Cooper wrote:
> >> Hi,
> > Hey Andrew!
> >> Over the weekend, XenServer testing managed to run a side-by-side test
> >> of XenServer trunk and XenServer experimental xen-4.5.  These are
> >> identical other than the version of Xen (and associated libraries) in
> >> use, i.e. identical dom0 kernel, Xapi toolstack and dom0 userspace,
> >> other than as linked against newer Xen libraries.
> >>
> >> The Xen-4.5 tests were on top of c/s e6c3d371d4 "systemd: use pkg-
> config
> >> to determine systemd library availability"
> >>
> >> There are a few notable issues exposed:
> >>
> >> XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it
> didn't in
> >> xen-4.4, given identical parameters.  The hypercall gained an extra
> >> permission check as part of 0561e1f01e.  Our usecase here is a daemon in
> >> dom0 mapping guest RAM to emulate a graphics card, but I currently don't
> >> see how that is incompatible with the new permissions check.
> > I presume the daemon also does 'XEN_DOMCTL_iomem_permission' to
> grant
> > the other domain access to its RAM? And before it makes the
> > XEN_DOMCTL_memory_mapping hypercall.
> 
> This is purely an implementer of the ioreq server infrastructure
> providing an emulated set of BARs in the guest as qemu would, but
> without using dom0 map-foreign powers.  The gfn ranges in question are
> regular guest RAM as far as I am aware, and should not require any
> special io permissions.

IIRC the ranges in question are sections of BAR on the GPU which the dom0 code is trying to inject into the guest.

  Paul

> 
> Either way, the identified changeset has apparently caused a regression,
> but I am not yet certain whether it is legitimately disabling something
> which should not have worked in the first place, or whether it is a
> change which needs reconsidering.
> 
> >
> >> Migrations from older Xens to Xen-4.5 fairly reliably crash domains (90%
> >> of the time, both PV and HVM guests).  This includes migrates from older
> >> XenServers using the legacy->v2 migration code which is confirmed-good
> >> in "upgrade to Xen-4.4" case.  The migration v2 code in use is identical.
> > The XenServer is not using the in-the-tree migration system except in
> > the older version of XenServer right?
> 
> XenServer expermental-4.5 is strictly using migration v2, including
> upgrade from legacy, but as far as I am aware identical migration v2 as
> our current Xen-4.4 trunk which works fine for all tests.
> 
> >> We have certain machines which are showing reliable failure to boot
> >> under Xen-4.5, where they worked with 4.4.  Symptoms range from the
> dom0
> >> kernel crashing before printing anything, to complaining that the initrd
> >> is corrupt when attempting to decompress.  This appears to be hardware
> >> specific.
> > Hardware specific is good. Could you give some ideas of what make/model
> > this is?
> 
> They are all IBM blades to the best of my knowledge, which are a similar
> system to the hardware which gave me 1ed7679 to debug, so I am hoping it
> is a latent BIOS issue and not a Xen 4.5 issue.
> 
> ~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 Tue Dec 09 09:55:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09: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 1XyHVW-0008Rq-Rf; Tue, 09 Dec 2014 09:55:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luis.henriques@canonical.com>) id 1XyHVV-0008Rl-5V
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 09:55:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	92/E5-25276-4F6C6845; Tue, 09 Dec 2014 09:55:00 +0000
X-Env-Sender: luis.henriques@canonical.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418118899!14355867!1
X-Originating-IP: [91.189.89.112]
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 17931 invoked from network); 9 Dec 2014 09:54:59 -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;
	9 Dec 2014 09:54:59 -0000
Received: from bl20-128-180.dsl.telepac.pt ([2.81.128.180] helo=localhost)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <luis.henriques@canonical.com>)
	id 1XyHVO-00007f-H9; Tue, 09 Dec 2014 09:54:54 +0000
Date: Tue, 9 Dec 2014 09:54:53 +0000
From: Luis Henriques <luis.henriques@canonical.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141209095453.GA7783@hercules>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>
	<547C2CFC.7060908@canonical.com> <20141208101936.GA7491@hercules>
	<54858753.1070801@citrix.com>
MIME-Version: 1.0
Content-Length: 2772
Content-Disposition: inline
In-Reply-To: <54858753.1070801@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, Kamal Mostafa <kamal@canonical.com>,
	linux-kernel@vger.kernel.org, Stefan Bader <stefan.bader@canonical.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Zoltan Kiss <zoltan.kiss@citrix.com>, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 08, 2014 at 11:11:15AM +0000, David Vrabel wrote:
> On 08/12/14 10:19, Luis Henriques wrote:
> > On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
> >> On 11.08.2014 19:32, Zoltan Kiss wrote:
> >>> There is a long known problem with the netfront/netback interface: if=
 the guest
> >>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 r=
ing slots,
> >>> it gets dropped. The reason is that netback maps these slots to a fra=
g in the
> >>> frags array, which is limited by size. Having so many slots can occur=
 since
> >>> compound pages were introduced, as the ring protocol slice them up in=
to
> >>> individual (non-compound) page aligned slots. The theoretical worst c=
ase
> >>> scenario looks like this (note, skbs are limited to 64 Kb here):
> >>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page bou=
ndary,
> >>> using 2 slots
> >>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes ar=
e at the
> >>> end and the beginning of a page, therefore they use 3 * 15 =3D 45 slo=
ts
> >>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 slo=
ts
> >>> Although I don't think this 51 slots skb can really happen, we need a=
 solution
> >>> which can deal with every scenario. In real life there is only a few =
slots
> >>> overdue, but usually it causes the TCP stream to be blocked, as the r=
etry will
> >>> most likely have the same buffer layout.
> >>> This patch solves this problem by linearizing the packet. This is not=
 the
> >>> fastest way, and it can fail much easier as it tries to allocate a bi=
g linear
> >>> area for the whole packet, but probably easier by an order of magnitu=
de than
> >>> anything else. Probably this code path is not touched very frequently=
 anyway.
> >>>
> >>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> >>> Cc: Wei Liu <wei.liu2@citrix.com>
> >>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> >>> Cc: Paul Durrant <paul.durrant@citrix.com>
> >>> Cc: netdev@vger.kernel.org
> >>> Cc: linux-kernel@vger.kernel.org
> >>> Cc: xen-devel@lists.xenproject.org
> >>
> >> This does not seem to be marked explicitly as stable. Has someone alre=
ady asked
> >> David Miller to put it on his stable queue? IMO it qualifies quite wel=
l and the
> >> actual change should be simple to pick/backport.
> >>
> > =

> > Thank you Stefan, I'm queuing this for the next 3.16 kernel release.
> =

> Don't backport this yes.  It's broken.  It produces malformed requests
> and netback will report a fatal error and stop all traffic on the VIF.
> =

> David

Ok, thank you.  I've dropped it already.

Cheers,
--
Lu=EDs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 09:55:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 09: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 1XyHVW-0008Rq-Rf; Tue, 09 Dec 2014 09:55:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luis.henriques@canonical.com>) id 1XyHVV-0008Rl-5V
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 09:55:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	92/E5-25276-4F6C6845; Tue, 09 Dec 2014 09:55:00 +0000
X-Env-Sender: luis.henriques@canonical.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418118899!14355867!1
X-Originating-IP: [91.189.89.112]
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 17931 invoked from network); 9 Dec 2014 09:54:59 -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;
	9 Dec 2014 09:54:59 -0000
Received: from bl20-128-180.dsl.telepac.pt ([2.81.128.180] helo=localhost)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <luis.henriques@canonical.com>)
	id 1XyHVO-00007f-H9; Tue, 09 Dec 2014 09:54:54 +0000
Date: Tue, 9 Dec 2014 09:54:53 +0000
From: Luis Henriques <luis.henriques@canonical.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141209095453.GA7783@hercules>
References: <1407778343-13622-1-git-send-email-zoltan.kiss@citrix.com>
	<547C2CFC.7060908@canonical.com> <20141208101936.GA7491@hercules>
	<54858753.1070801@citrix.com>
MIME-Version: 1.0
Content-Length: 2772
Content-Disposition: inline
In-Reply-To: <54858753.1070801@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, Kamal Mostafa <kamal@canonical.com>,
	linux-kernel@vger.kernel.org, Stefan Bader <stefan.bader@canonical.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Zoltan Kiss <zoltan.kiss@citrix.com>, xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on
 compound pages with skb_linearize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 08, 2014 at 11:11:15AM +0000, David Vrabel wrote:
> On 08/12/14 10:19, Luis Henriques wrote:
> > On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
> >> On 11.08.2014 19:32, Zoltan Kiss wrote:
> >>> There is a long known problem with the netfront/netback interface: if=
 the guest
> >>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 r=
ing slots,
> >>> it gets dropped. The reason is that netback maps these slots to a fra=
g in the
> >>> frags array, which is limited by size. Having so many slots can occur=
 since
> >>> compound pages were introduced, as the ring protocol slice them up in=
to
> >>> individual (non-compound) page aligned slots. The theoretical worst c=
ase
> >>> scenario looks like this (note, skbs are limited to 64 Kb here):
> >>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page bou=
ndary,
> >>> using 2 slots
> >>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes ar=
e at the
> >>> end and the beginning of a page, therefore they use 3 * 15 =3D 45 slo=
ts
> >>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 slo=
ts
> >>> Although I don't think this 51 slots skb can really happen, we need a=
 solution
> >>> which can deal with every scenario. In real life there is only a few =
slots
> >>> overdue, but usually it causes the TCP stream to be blocked, as the r=
etry will
> >>> most likely have the same buffer layout.
> >>> This patch solves this problem by linearizing the packet. This is not=
 the
> >>> fastest way, and it can fail much easier as it tries to allocate a bi=
g linear
> >>> area for the whole packet, but probably easier by an order of magnitu=
de than
> >>> anything else. Probably this code path is not touched very frequently=
 anyway.
> >>>
> >>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> >>> Cc: Wei Liu <wei.liu2@citrix.com>
> >>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> >>> Cc: Paul Durrant <paul.durrant@citrix.com>
> >>> Cc: netdev@vger.kernel.org
> >>> Cc: linux-kernel@vger.kernel.org
> >>> Cc: xen-devel@lists.xenproject.org
> >>
> >> This does not seem to be marked explicitly as stable. Has someone alre=
ady asked
> >> David Miller to put it on his stable queue? IMO it qualifies quite wel=
l and the
> >> actual change should be simple to pick/backport.
> >>
> > =

> > Thank you Stefan, I'm queuing this for the next 3.16 kernel release.
> =

> Don't backport this yes.  It's broken.  It produces malformed requests
> and netback will report a fatal error and stop all traffic on the VIF.
> =

> David

Ok, thank you.  I've dropped it already.

Cheers,
--
Lu=EDs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:05:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHfC-0000cH-3Z; Tue, 09 Dec 2014 10:05:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maomingya928@gmail.com>) id 1XyHfA-0000cC-Md
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:05:00 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	2C/41-08051-B49C6845; Tue, 09 Dec 2014 10:04:59 +0000
X-Env-Sender: maomingya928@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418119497!13787669!1
X-Originating-IP: [209.85.220.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18483 invoked from network); 9 Dec 2014 10:04:58 -0000
Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com)
	(209.85.220.50)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 10:04:58 -0000
Received: by mail-pa0-f50.google.com with SMTP id bj1so266969pad.23
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 02:04:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:subject:date:message-id:reply-to:user-agent:mime-version
	:content-type; bh=e97TD452rZEAE917BF7Sig8bH9kYDXth+tlReWbwdOk=;
	b=dpfGdhcNddb3PqSJYLNO5W7m3HwcYFw2Y8IK0HhT/nhpqi14dy7GA3q2vwqBBoss6X
	GtDRjsbHa4fuNuX4YTJA4B80u/jk00du+Fe/fjtzXY8quW0hvUNH7yBfauUHZeBQlrIX
	WTcs1nd4UqpARxW4+Go2iQtX3tTk8xWbkWkyOEyLkz63bhAZr7np/5uJ7/p1LwoORwAv
	v+EcUP0kldS103BOeowtNvQNueKue1pMkNYIDDdKuWzw3ntjLxILJCmQNsA9cshdwTPI
	ptMfPuZuiWyPYh0P9a98A6igQT4xNhcAPxet5MagjS9jDpXtFXH/vEGs4d61YW2lBX+K
	Zgyw==
X-Received: by 10.70.50.1 with SMTP id y1mr29664205pdn.12.1418119496731;
	Tue, 09 Dec 2014 02:04:56 -0800 (PST)
Received: from [10.0.0.159] ([202.55.91.114])
	by mx.google.com with ESMTPSA id ps2sm1005390pdb.62.2014.12.09.02.04.55
	for <xen-devel@lists.xen.org>
	(version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 09 Dec 2014 02:04:56 -0800 (PST)
From: "Mao Mingya" <maomingya928@gmail.com>
To: xen-devel@lists.xen.org
Date: Tue, 09 Dec 2014 10:04:53 +0000
Message-Id: <em7c138492-1609-4e0c-9557-b64977f33550@sgp1030c>
User-Agent: eM_Client/6.0.21040.0
Mime-Version: 1.0
Subject: [Xen-devel] arch arm qemu compile erro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mao Mingya <maomingya928@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6127009299567732613=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6127009299567732613==
Content-Type: multipart/alternative;
 boundary="------=_MB3D62EC16-2B12-4488-94C7-5CC10D02E320"


--------=_MB3D62EC16-2B12-4488-94C7-5CC10D02E320
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

While I tried to cross compile the qemu for xen with the following=20
command:
"make dist-stubdom CROSS_COMPILE=3Darm-linux-gnueabihf-=20
XEN_TARGET_ARCH=3Darm32"

I got an error complain about the " ./extras/mini-os/arch/arm32/arch.mk:=
=20
No such file or directory " is missing.

My xen source version is on "Xen-4.5.0-rc3"

Is the build process for xen broken? or some ./configure needed?

Regards,
Mao

--------=_MB3D62EC16-2B12-4488-94C7-5CC10D02E320
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<STYLE id=3DeMClientCss>
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; paddin=
g-top: 0px; }
.plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weigh=
t: normal; font-style: normal; }
a img { border: 0px; }body {font-family: Tahoma;font-size: 12pt;}
.plain pre, .plain tt {font-family: Tahoma;font-size: 12pt;}</STYLE>
</HEAD>
<BODY>
<DIV>While I tried to cross&nbsp;compile the&nbsp;qemu for xen with the =
following command:</DIV>
<DIV>"make dist-stubdom CROSS_COMPILE=3Darm-linux-gnueabihf- XEN_TARGET_ARC=
H=3Darm32"</DIV>
<DIV>&nbsp;</DIV>
<DIV>I got an error complain about the " ./extras/mini-os/arch/arm32/arch.m=
k: No such file or directory " is missing.</DIV>
<DIV>&nbsp;</DIV>
<DIV>My xen source version is on "Xen-4.5.0-rc3"</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is the build process for xen broken? or some ./configure needed?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>Mao</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>
--------=_MB3D62EC16-2B12-4488-94C7-5CC10D02E320--



--===============6127009299567732613==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6127009299567732613==--



From xen-devel-bounces@lists.xen.org Tue Dec 09 10:05:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHfK-0000ck-FG; Tue, 09 Dec 2014 10:05: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 1XyHfJ-0000cb-HT
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:05:09 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5B/2E-15461-459C6845; Tue, 09 Dec 2014 10:05:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418119507!14320326!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 9963 invoked from network); 9 Dec 2014 10:05:08 -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;
	9 Dec 2014 10:05:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,543,1413244800"; d="scan'208";a="202205246"
Message-ID: <1418119502.1428.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Date: Tue, 9 Dec 2014 10:05:02 +0000
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2394DA29@SZXEMA512-MBX.china.huawei.com>
References: <20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
	<20141208101304.GB17128@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394C523@SZXEMA512-MBX.china.huawei.com>
	<20141208135534.GA21374@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394DA29@SZXEMA512-MBX.china.huawei.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou	\(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-09 at 02:51 +0000, Zhangleiqiang (Trump) wrote:
> What is the recommended way to have a discussion with XenServer folks?
> Through the forum of XenServer or the standalone mailing list? I find
> the most of discussions in forum are the production of XenServer.

AIUI development == list, users == forums.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:05:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHfC-0000cH-3Z; Tue, 09 Dec 2014 10:05:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maomingya928@gmail.com>) id 1XyHfA-0000cC-Md
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:05:00 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	2C/41-08051-B49C6845; Tue, 09 Dec 2014 10:04:59 +0000
X-Env-Sender: maomingya928@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418119497!13787669!1
X-Originating-IP: [209.85.220.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18483 invoked from network); 9 Dec 2014 10:04:58 -0000
Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com)
	(209.85.220.50)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 10:04:58 -0000
Received: by mail-pa0-f50.google.com with SMTP id bj1so266969pad.23
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 02:04:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:subject:date:message-id:reply-to:user-agent:mime-version
	:content-type; bh=e97TD452rZEAE917BF7Sig8bH9kYDXth+tlReWbwdOk=;
	b=dpfGdhcNddb3PqSJYLNO5W7m3HwcYFw2Y8IK0HhT/nhpqi14dy7GA3q2vwqBBoss6X
	GtDRjsbHa4fuNuX4YTJA4B80u/jk00du+Fe/fjtzXY8quW0hvUNH7yBfauUHZeBQlrIX
	WTcs1nd4UqpARxW4+Go2iQtX3tTk8xWbkWkyOEyLkz63bhAZr7np/5uJ7/p1LwoORwAv
	v+EcUP0kldS103BOeowtNvQNueKue1pMkNYIDDdKuWzw3ntjLxILJCmQNsA9cshdwTPI
	ptMfPuZuiWyPYh0P9a98A6igQT4xNhcAPxet5MagjS9jDpXtFXH/vEGs4d61YW2lBX+K
	Zgyw==
X-Received: by 10.70.50.1 with SMTP id y1mr29664205pdn.12.1418119496731;
	Tue, 09 Dec 2014 02:04:56 -0800 (PST)
Received: from [10.0.0.159] ([202.55.91.114])
	by mx.google.com with ESMTPSA id ps2sm1005390pdb.62.2014.12.09.02.04.55
	for <xen-devel@lists.xen.org>
	(version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 09 Dec 2014 02:04:56 -0800 (PST)
From: "Mao Mingya" <maomingya928@gmail.com>
To: xen-devel@lists.xen.org
Date: Tue, 09 Dec 2014 10:04:53 +0000
Message-Id: <em7c138492-1609-4e0c-9557-b64977f33550@sgp1030c>
User-Agent: eM_Client/6.0.21040.0
Mime-Version: 1.0
Subject: [Xen-devel] arch arm qemu compile erro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mao Mingya <maomingya928@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6127009299567732613=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6127009299567732613==
Content-Type: multipart/alternative;
 boundary="------=_MB3D62EC16-2B12-4488-94C7-5CC10D02E320"


--------=_MB3D62EC16-2B12-4488-94C7-5CC10D02E320
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

While I tried to cross compile the qemu for xen with the following=20
command:
"make dist-stubdom CROSS_COMPILE=3Darm-linux-gnueabihf-=20
XEN_TARGET_ARCH=3Darm32"

I got an error complain about the " ./extras/mini-os/arch/arm32/arch.mk:=
=20
No such file or directory " is missing.

My xen source version is on "Xen-4.5.0-rc3"

Is the build process for xen broken? or some ./configure needed?

Regards,
Mao

--------=_MB3D62EC16-2B12-4488-94C7-5CC10D02E320
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<STYLE id=3DeMClientCss>
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; paddin=
g-top: 0px; }
.plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weigh=
t: normal; font-style: normal; }
a img { border: 0px; }body {font-family: Tahoma;font-size: 12pt;}
.plain pre, .plain tt {font-family: Tahoma;font-size: 12pt;}</STYLE>
</HEAD>
<BODY>
<DIV>While I tried to cross&nbsp;compile the&nbsp;qemu for xen with the =
following command:</DIV>
<DIV>"make dist-stubdom CROSS_COMPILE=3Darm-linux-gnueabihf- XEN_TARGET_ARC=
H=3Darm32"</DIV>
<DIV>&nbsp;</DIV>
<DIV>I got an error complain about the " ./extras/mini-os/arch/arm32/arch.m=
k: No such file or directory " is missing.</DIV>
<DIV>&nbsp;</DIV>
<DIV>My xen source version is on "Xen-4.5.0-rc3"</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is the build process for xen broken? or some ./configure needed?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>Mao</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>
--------=_MB3D62EC16-2B12-4488-94C7-5CC10D02E320--



--===============6127009299567732613==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6127009299567732613==--



From xen-devel-bounces@lists.xen.org Tue Dec 09 10:05:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHfK-0000ck-FG; Tue, 09 Dec 2014 10:05: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 1XyHfJ-0000cb-HT
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:05:09 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5B/2E-15461-459C6845; Tue, 09 Dec 2014 10:05:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418119507!14320326!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 9963 invoked from network); 9 Dec 2014 10:05:08 -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;
	9 Dec 2014 10:05:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,543,1413244800"; d="scan'208";a="202205246"
Message-ID: <1418119502.1428.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
Date: Tue, 9 Dec 2014 10:05:02 +0000
In-Reply-To: <3A6795EA1206904E94BEC8EF9DF109AE2394DA29@SZXEMA512-MBX.china.huawei.com>
References: <20141202121151.GD5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393216B@SZXEMA512-MBX.china.huawei.com>
	<20141202155832.GH5768@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2393301C@SZXEMA512-MBX.china.huawei.com>
	<20141204105021.GA16532@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE23933CDA@SZXEMA512-MBX.china.huawei.com>
	<20141205124233.GD31446@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394A187@SZXEMA512-MBX.china.huawei.com>
	<20141208101304.GB17128@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394C523@SZXEMA512-MBX.china.huawei.com>
	<20141208135534.GA21374@zion.uk.xensource.com>
	<3A6795EA1206904E94BEC8EF9DF109AE2394DA29@SZXEMA512-MBX.china.huawei.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.7-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "Luohao
	\(brian\)" <brian.luohao@huawei.com>, Wei Liu <wei.liu2@citrix.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	zhangleiqiang <zhangleiqiang@gmail.com>,
	"Yuzhou	\(C\)" <vitas.yuzhou@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: Re: [Xen-devel] Poor network performance between DomU with
 multiqueue support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-09 at 02:51 +0000, Zhangleiqiang (Trump) wrote:
> What is the recommended way to have a discussion with XenServer folks?
> Through the forum of XenServer or the standalone mailing list? I find
> the most of discussions in forum are the production of XenServer.

AIUI development == list, users == forums.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:06:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHgq-0000mX-Uj; Tue, 09 Dec 2014 10:06: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 1XyHgo-0000mF-Di
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:06:43 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	4D/79-09284-1B9C6845; Tue, 09 Dec 2014 10:06:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418119599!12009022!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 8704 invoked from network); 9 Dec 2014 10:06:41 -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;
	9 Dec 2014 10:06:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,543,1413244800"; d="scan'208";a="201805479"
Message-ID: <1418119597.1428.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mao Mingya <maomingya928@gmail.com>
Date: Tue, 9 Dec 2014 10:06:37 +0000
In-Reply-To: <em1b3974e2-00ae-4a0a-89c1-d7218d4a1497@sgp1030c>
References: <em1b3974e2-00ae-4a0a-89c1-d7218d4a1497@sgp1030c>
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] help on qemu-xen for arch arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-09 at 09:04 +0000, Mao Mingya wrote:
> --with-system-qemu" 

--with-system-qemu means "use the qemu which is already installed on the
system". IOW it means "do not build a qemu".
 
> I did not find the build process download and compile the qemu-xen as
> described it in this link. 

Correct, you have asked it not to.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:06:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHgq-0000mX-Uj; Tue, 09 Dec 2014 10:06: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 1XyHgo-0000mF-Di
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:06:43 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	4D/79-09284-1B9C6845; Tue, 09 Dec 2014 10:06:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418119599!12009022!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 8704 invoked from network); 9 Dec 2014 10:06:41 -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;
	9 Dec 2014 10:06:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,543,1413244800"; d="scan'208";a="201805479"
Message-ID: <1418119597.1428.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mao Mingya <maomingya928@gmail.com>
Date: Tue, 9 Dec 2014 10:06:37 +0000
In-Reply-To: <em1b3974e2-00ae-4a0a-89c1-d7218d4a1497@sgp1030c>
References: <em1b3974e2-00ae-4a0a-89c1-d7218d4a1497@sgp1030c>
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] help on qemu-xen for arch arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-09 at 09:04 +0000, Mao Mingya wrote:
> --with-system-qemu" 

--with-system-qemu means "use the qemu which is already installed on the
system". IOW it means "do not build a qemu".
 
> I did not find the build process download and compile the qemu-xen as
> described it in this link. 

Correct, you have asked it not to.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:12:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10:12:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyHlY-00011A-LS; Tue, 09 Dec 2014 10:11:36 +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 1XyHlX-000115-5H
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:11:35 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	1E/E7-02712-6DAC6845; Tue, 09 Dec 2014 10:11:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418119893!13858083!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 2880 invoked from network); 9 Dec 2014 10:11:33 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 10:11:33 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XyHl9-000KMB-EB; Tue, 09 Dec 2014 10:11:11 +0000
Date: Tue, 9 Dec 2014 11:11:11 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141209101111.GA75319@deinos.phlegethon.org>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5486BE99020000780004DF8A@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: kevin.tian@intel.com, 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,
	Tiejun Chen <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:19 +0000 on 09 Dec (1418109561), Jan Beulich wrote:
> Why do you always pick other than the simplest possible solution?

Jan, please don't make personal comments like this in code review.  It
can only offend and demoralize contributors, and deter other people
from joining in.

I understand that it can be frustrating, and I'm sure I have lashed
out at people on-list in the past.  But remember that people who are
new to the project need time to learn, and keep the comments to the
code itself.

I can see that this series has been going for a long time, and is
still getting hung up on coding style issues.  Might it be useful to
have a round of internal review from some of the more xen-experienced
engineers at Intel before Jan looks at it again?

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 Dec 09 10:12:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10:12:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyHlY-00011A-LS; Tue, 09 Dec 2014 10:11:36 +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 1XyHlX-000115-5H
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:11:35 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	1E/E7-02712-6DAC6845; Tue, 09 Dec 2014 10:11:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418119893!13858083!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 2880 invoked from network); 9 Dec 2014 10:11:33 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 10:11:33 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XyHl9-000KMB-EB; Tue, 09 Dec 2014 10:11:11 +0000
Date: Tue, 9 Dec 2014 11:11:11 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141209101111.GA75319@deinos.phlegethon.org>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5486BE99020000780004DF8A@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: kevin.tian@intel.com, 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,
	Tiejun Chen <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:19 +0000 on 09 Dec (1418109561), Jan Beulich wrote:
> Why do you always pick other than the simplest possible solution?

Jan, please don't make personal comments like this in code review.  It
can only offend and demoralize contributors, and deter other people
from joining in.

I understand that it can be frustrating, and I'm sure I have lashed
out at people on-list in the past.  But remember that people who are
new to the project need time to learn, and keep the comments to the
code itself.

I can see that this series has been going for a long time, and is
still getting hung up on coding style issues.  Might it be useful to
have a round of internal review from some of the more xen-experienced
engineers at Intel before Jan looks at it again?

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 Dec 09 10:12:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHmH-00015p-2d; Tue, 09 Dec 2014 10:12:21 +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 1XyHmF-00015f-BA
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:12:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9E/6F-15461-20BC6845; Tue, 09 Dec 2014 10:12:18 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418119937!14297349!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7877 invoked from network); 9 Dec 2014 10:12:17 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-21.messagelabs.com with SMTP;
	9 Dec 2014 10:12:17 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 09 Dec 2014 02:10:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,543,1413270000"; d="scan'208";a="650832139"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga002.jf.intel.com with ESMTP; 09 Dec 2014 02:12:14 -0800
Message-ID: <5486CAAF.9070807@linux.intel.com>
Date: Tue, 09 Dec 2014 18:10:55 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Paul.Durrant@citrix.com, keir@xen.org, tim@xen.org, 
	JBeulich@suse.com, kevin.tian@intel.com, Xen-devel@lists.xen.org
Subject: [Xen-devel] One question about the hypercall to translate gfn to
	mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

   As you can see, we are pushing our XenGT patches to the upstream. One 
feature we need in xen is to translate guests' gfn to mfn in XenGT dom0 
device model.

   Here we may have 2 similar solutions:
   1> Paul told me(and thank you, Paul :)) that there used to be a 
hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in 
commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was no 
usage at that time. So solution 1 is to revert this commit. However, 
since this hypercall was removed ages ago, the reverting met many 
conflicts, i.e. the gmfn_to_mfn is no longer used in x86, etc.

   2> In our project, we defined a new hypercall 
XENMEM_get_mfn_from_pfn, which has a similar implementation like the 
previous XENMEM_translate_gpfn_list. One of the major differences is 
that this newly defined one is only for x86(called in arch_memory_op), 
so we do not have to worry about the arm side.

   Does anyone has any suggestions about this?
   Thanks in advance. :)

B.R.
Yu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:12:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHmH-00015p-2d; Tue, 09 Dec 2014 10:12:21 +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 1XyHmF-00015f-BA
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:12:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9E/6F-15461-20BC6845; Tue, 09 Dec 2014 10:12:18 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418119937!14297349!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7877 invoked from network); 9 Dec 2014 10:12:17 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-21.messagelabs.com with SMTP;
	9 Dec 2014 10:12:17 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 09 Dec 2014 02:10:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,543,1413270000"; d="scan'208";a="650832139"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga002.jf.intel.com with ESMTP; 09 Dec 2014 02:12:14 -0800
Message-ID: <5486CAAF.9070807@linux.intel.com>
Date: Tue, 09 Dec 2014 18:10:55 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Paul.Durrant@citrix.com, keir@xen.org, tim@xen.org, 
	JBeulich@suse.com, kevin.tian@intel.com, Xen-devel@lists.xen.org
Subject: [Xen-devel] One question about the hypercall to translate gfn to
	mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

   As you can see, we are pushing our XenGT patches to the upstream. One 
feature we need in xen is to translate guests' gfn to mfn in XenGT dom0 
device model.

   Here we may have 2 similar solutions:
   1> Paul told me(and thank you, Paul :)) that there used to be a 
hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in 
commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was no 
usage at that time. So solution 1 is to revert this commit. However, 
since this hypercall was removed ages ago, the reverting met many 
conflicts, i.e. the gmfn_to_mfn is no longer used in x86, etc.

   2> In our project, we defined a new hypercall 
XENMEM_get_mfn_from_pfn, which has a similar implementation like the 
previous XENMEM_translate_gpfn_list. One of the major differences is 
that this newly defined one is only for x86(called in arch_memory_op), 
so we do not have to worry about the arm side.

   Does anyone has any suggestions about this?
   Thanks in advance. :)

B.R.
Yu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:15:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHoz-0001VI-Lx; Tue, 09 Dec 2014 10:15:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XyHoz-0001V7-2O
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:15:09 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	A5/50-02699-BABC6845; Tue, 09 Dec 2014 10:15:07 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418120104!13855955!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7801 invoked from network); 9 Dec 2014 10:15:05 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-27.messagelabs.com with SMTP;
	9 Dec 2014 10:15:05 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 09 Dec 2014 02:14:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,543,1413270000"; d="scan'208";a="650833121"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga002.jf.intel.com with ESMTP; 09 Dec 2014 02:14:50 -0800
Message-ID: <5486CB4B.5090801@linux.intel.com>
Date: Tue, 09 Dec 2014 18:13:31 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>	<54865820.2010501@linux.intel.com>
	<5486C164020000780004DF97@mail.emea.novell.com>
In-Reply-To: <5486C164020000780004DF97@mail.emea.novell.com>
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 v6 0/2] add new p2m type class and new p2m
 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 12/9/2014 4:31 PM, Jan Beulich wrote:
>>>> On 09.12.14 at 03:02, <yu.c.zhang@linux.intel.com> wrote:
>>     Thank you very much for your review.
>>     And could you please also help me about how to get an ACK? I'm not
>> sure what's the next action I need to take. :-)
>
> I don't think you need to take any action at this point. The second
> patch will need Tim's ack, yes, but that's nothing to worry about
> (yet), since even with his ack the two patches wouldn't go in until
> after 4.5 got branched off of staging.
>
Got it, and thanks!

Yu

> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:15:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHoz-0001VI-Lx; Tue, 09 Dec 2014 10:15:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XyHoz-0001V7-2O
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:15:09 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	A5/50-02699-BABC6845; Tue, 09 Dec 2014 10:15:07 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418120104!13855955!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7801 invoked from network); 9 Dec 2014 10:15:05 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-27.messagelabs.com with SMTP;
	9 Dec 2014 10:15:05 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 09 Dec 2014 02:14:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,543,1413270000"; d="scan'208";a="650833121"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga002.jf.intel.com with ESMTP; 09 Dec 2014 02:14:50 -0800
Message-ID: <5486CB4B.5090801@linux.intel.com>
Date: Tue, 09 Dec 2014 18:13:31 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>	<54865820.2010501@linux.intel.com>
	<5486C164020000780004DF97@mail.emea.novell.com>
In-Reply-To: <5486C164020000780004DF97@mail.emea.novell.com>
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 v6 0/2] add new p2m type class and new p2m
 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 12/9/2014 4:31 PM, Jan Beulich wrote:
>>>> On 09.12.14 at 03:02, <yu.c.zhang@linux.intel.com> wrote:
>>     Thank you very much for your review.
>>     And could you please also help me about how to get an ACK? I'm not
>> sure what's the next action I need to take. :-)
>
> I don't think you need to take any action at this point. The second
> patch will need Tim's ack, yes, but that's nothing to worry about
> (yet), since even with his ack the two patches wouldn't go in until
> after 4.5 got branched off of staging.
>
Got it, and thanks!

Yu

> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:19:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10:19:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyHt0-0001ek-B5; Tue, 09 Dec 2014 10:19:18 +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 1XyHsz-0001ef-7r
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:19:17 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	D6/C8-22777-4ACC6845; Tue, 09 Dec 2014 10:19:16 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418120355!7010997!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22706 invoked from network); 9 Dec 2014 10:19:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 10:19:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,543,1413244800"; d="scan'208";a="27657959"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>, "Keir (Xen.org)" <keir@xen.org>, 
	"Tim (Xen.org)" <tim@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Kevin Tian <kevin.tian@intel.com>, "Xen-devel@lists.xen.org"
	<Xen-devel@lists.xen.org>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijD3J3fQrwFk2EUD3dyNOBb5yHCshQ
Date: Tue, 9 Dec 2014 10:19:14 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
References: <5486CAAF.9070807@linux.intel.com>
In-Reply-To: <5486CAAF.9070807@linux.intel.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] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Yu, Zhang [mailto:yu.c.zhang@linux.intel.com]
> Sent: 09 December 2014 10:11
> To: Paul Durrant; Keir (Xen.org); Tim (Xen.org); JBeulich@suse.com; Kevin
> Tian; Xen-devel@lists.xen.org
> Subject: One question about the hypercall to translate gfn to mfn.
> 
> Hi all,
> 
>    As you can see, we are pushing our XenGT patches to the upstream. One
> feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> device model.
> 
>    Here we may have 2 similar solutions:
>    1> Paul told me(and thank you, Paul :)) that there used to be a
> hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was
> no
> usage at that time. So solution 1 is to revert this commit. However,
> since this hypercall was removed ages ago, the reverting met many
> conflicts, i.e. the gmfn_to_mfn is no longer used in x86, etc.
> 
>    2> In our project, we defined a new hypercall
> XENMEM_get_mfn_from_pfn, which has a similar implementation like the
> previous XENMEM_translate_gpfn_list. One of the major differences is
> that this newly defined one is only for x86(called in arch_memory_op),
> so we do not have to worry about the arm side.
> 
>    Does anyone has any suggestions about this?

IIUC what is needed is a means to IOMMU map a gfn in the service domain (dom0 for the moment) such that it can be accessed by the GPU. I think use of an raw mfn value currently works only because dom0 is using a 1:1 IOMMU mapping scheme. Is my understanding correct, or do you really need raw mfn values?

  Paul

>    Thanks in advance. :)
> 
> B.R.
> Yu
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:19:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10:19:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyHt0-0001ek-B5; Tue, 09 Dec 2014 10:19:18 +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 1XyHsz-0001ef-7r
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:19:17 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	D6/C8-22777-4ACC6845; Tue, 09 Dec 2014 10:19:16 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418120355!7010997!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22706 invoked from network); 9 Dec 2014 10:19:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 10:19:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,543,1413244800"; d="scan'208";a="27657959"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>, "Keir (Xen.org)" <keir@xen.org>, 
	"Tim (Xen.org)" <tim@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Kevin Tian <kevin.tian@intel.com>, "Xen-devel@lists.xen.org"
	<Xen-devel@lists.xen.org>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijD3J3fQrwFk2EUD3dyNOBb5yHCshQ
Date: Tue, 9 Dec 2014 10:19:14 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
References: <5486CAAF.9070807@linux.intel.com>
In-Reply-To: <5486CAAF.9070807@linux.intel.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] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Yu, Zhang [mailto:yu.c.zhang@linux.intel.com]
> Sent: 09 December 2014 10:11
> To: Paul Durrant; Keir (Xen.org); Tim (Xen.org); JBeulich@suse.com; Kevin
> Tian; Xen-devel@lists.xen.org
> Subject: One question about the hypercall to translate gfn to mfn.
> 
> Hi all,
> 
>    As you can see, we are pushing our XenGT patches to the upstream. One
> feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> device model.
> 
>    Here we may have 2 similar solutions:
>    1> Paul told me(and thank you, Paul :)) that there used to be a
> hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was
> no
> usage at that time. So solution 1 is to revert this commit. However,
> since this hypercall was removed ages ago, the reverting met many
> conflicts, i.e. the gmfn_to_mfn is no longer used in x86, etc.
> 
>    2> In our project, we defined a new hypercall
> XENMEM_get_mfn_from_pfn, which has a similar implementation like the
> previous XENMEM_translate_gpfn_list. One of the major differences is
> that this newly defined one is only for x86(called in arch_memory_op),
> so we do not have to worry about the arm side.
> 
>    Does anyone has any suggestions about this?

IIUC what is needed is a means to IOMMU map a gfn in the service domain (dom0 for the moment) such that it can be accessed by the GPU. I think use of an raw mfn value currently works only because dom0 is using a 1:1 IOMMU mapping scheme. Is my understanding correct, or do you really need raw mfn values?

  Paul

>    Thanks in advance. :)
> 
> B.R.
> Yu
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:21:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHub-0001ls-Vd; Tue, 09 Dec 2014 10:20:57 +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 1XyHua-0001lj-NL
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:20:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BD/02-15461-80DC6845; Tue, 09 Dec 2014 10:20:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418120455!14300164!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 24032 invoked from network); 9 Dec 2014 10:20:55 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 10:20:55 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XyHuK-000KYz-Ct; Tue, 09 Dec 2014 10:20:40 +0000
Date: Tue, 9 Dec 2014 11:20:40 +0100
From: Tim Deegan <tim@xen.org>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Message-ID: <20141209102040.GB75319@deinos.phlegethon.org>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54865820.2010501@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54865820.2010501@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, JBeulich@suse.com,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v6 0/2] add new p2m type class and new p2m
 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

At 10:02 +0800 on 09 Dec (1418115728), Yu, Zhang wrote:
> Hi Tim & Jan,
> 
>    Thank you very much for your review.
>    And could you please also help me about how to get an ACK? I'm not 
> sure what's the next action I need to take. :-)

I'll review it on Thursday; I'll probably ack it then, since the
changes from v5 should be simple enough.  As Jan says, it won't be
committed until after 4.5 has been branched anyway.

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 Dec 09 10:21:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHub-0001ls-Vd; Tue, 09 Dec 2014 10:20:57 +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 1XyHua-0001lj-NL
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:20:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	BD/02-15461-80DC6845; Tue, 09 Dec 2014 10:20:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418120455!14300164!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 24032 invoked from network); 9 Dec 2014 10:20:55 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 10:20:55 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XyHuK-000KYz-Ct; Tue, 09 Dec 2014 10:20:40 +0000
Date: Tue, 9 Dec 2014 11:20:40 +0100
From: Tim Deegan <tim@xen.org>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Message-ID: <20141209102040.GB75319@deinos.phlegethon.org>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
	<54865820.2010501@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54865820.2010501@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, JBeulich@suse.com,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v6 0/2] add new p2m type class and new p2m
 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

At 10:02 +0800 on 09 Dec (1418115728), Yu, Zhang wrote:
> Hi Tim & Jan,
> 
>    Thank you very much for your review.
>    And could you please also help me about how to get an ACK? I'm not 
> sure what's the next action I need to take. :-)

I'll review it on Thursday; I'll probably ack it then, since the
changes from v5 should be simple enough.  As Jan says, it won't be
committed until after 4.5 has been branched anyway.

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 Dec 09 10:22:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHvp-0001sD-FU; Tue, 09 Dec 2014 10:22: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 1XyHvo-0001s4-Dy
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:22:12 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	F5/63-01660-35DC6845; Tue, 09 Dec 2014 10:22:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418120530!12350279!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17711 invoked from network); 9 Dec 2014 10:22:11 -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; 9 Dec 2014 10:22:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 10:22:10 +0000
Message-Id: <5486DB5E020000780004E09A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 10:22:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>,"Tim Deegan" <tim@xen.org>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
In-Reply-To: <20141209101111.GA75319@deinos.phlegethon.org>
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, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 11:11, <tim@xen.org> wrote:
> At 08:19 +0000 on 09 Dec (1418109561), Jan Beulich wrote:
>> Why do you always pick other than the simplest possible solution?
> 
> Jan, please don't make personal comments like this in code review.  It
> can only offend and demoralize contributors, and deter other people
> from joining in.

I apologize - I shouldn't have permitted myself to do so.

> I understand that it can be frustrating, and I'm sure I have lashed
> out at people on-list in the past.  But remember that people who are
> new to the project need time to learn, and keep the comments to the
> code itself.
> 
> I can see that this series has been going for a long time, and is
> still getting hung up on coding style issues.  Might it be useful to
> have a round of internal review from some of the more xen-experienced
> engineers at Intel before Jan looks at it again?

I've been suggesting something along those lines a number of times,
with (apparently) no success at all.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:22:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyHvp-0001sD-FU; Tue, 09 Dec 2014 10:22: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 1XyHvo-0001s4-Dy
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:22:12 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	F5/63-01660-35DC6845; Tue, 09 Dec 2014 10:22:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418120530!12350279!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17711 invoked from network); 9 Dec 2014 10:22:11 -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; 9 Dec 2014 10:22:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 10:22:10 +0000
Message-Id: <5486DB5E020000780004E09A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 10:22:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>,"Tim Deegan" <tim@xen.org>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
In-Reply-To: <20141209101111.GA75319@deinos.phlegethon.org>
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, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 11:11, <tim@xen.org> wrote:
> At 08:19 +0000 on 09 Dec (1418109561), Jan Beulich wrote:
>> Why do you always pick other than the simplest possible solution?
> 
> Jan, please don't make personal comments like this in code review.  It
> can only offend and demoralize contributors, and deter other people
> from joining in.

I apologize - I shouldn't have permitted myself to do so.

> I understand that it can be frustrating, and I'm sure I have lashed
> out at people on-list in the past.  But remember that people who are
> new to the project need time to learn, and keep the comments to the
> code itself.
> 
> I can see that this series has been going for a long time, and is
> still getting hung up on coding style issues.  Might it be useful to
> have a round of internal review from some of the more xen-experienced
> engineers at Intel before Jan looks at it again?

I've been suggesting something along those lines a number of times,
with (apparently) no success at all.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:24:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyHy5-00024Z-0D; Tue, 09 Dec 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 <vianom@gmail.com>) id 1XyHy3-00024R-EN
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:24:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	01/F9-15461-EDDC6845; Tue, 09 Dec 2014 10:24:30 +0000
X-Env-Sender: vianom@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418120670!14366424!1
X-Originating-IP: [74.125.82.49]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 311 invoked from network); 9 Dec 2014 10:24:30 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 10:24:30 -0000
Received: by mail-wg0-f49.google.com with SMTP id n12so397056wgh.8
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 02:24:30 -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=ldYjr0QOrY2194lymXZXo5iyxZLAHFrZxWzEPC8HA04=;
	b=Ilr8aYHHKF9qTbKDbaCAo6FsiEeaW+y4WJFZ7oTVsmpLxSkYxBjB4zrpbeLJ+xlJPb
	h7JZQX00DK5Z5HV82hvVVmjB1vtow/RKf655EQi9Hrc00THN3rDEZE/2cDEH1PjLq/EO
	gnL3Yh0RLzKy1AAls3WHOuA5duEulMfIah05FBXqYwii2H0OcXl//ZsyFh8OA1wxsmMt
	OgLCajFrwlBPwb031DtEUdPaP1lfbPdylZGsAKk5n8L4SijRnrWm4aw9FhvNOYwDfSAU
	147+8KSpTuSg2W4n48TP9GCfe9UT5a9egGHIa7R7C82PXEW745udT2+uuW+Vghpvqyj5
	XZbg==
MIME-Version: 1.0
X-Received: by 10.194.90.244 with SMTP id bz20mr3498398wjb.125.1418120670005; 
	Tue, 09 Dec 2014 02:24:30 -0800 (PST)
Received: by 10.216.35.1 with HTTP; Tue, 9 Dec 2014 02:24:29 -0800 (PST)
Date: Tue, 9 Dec 2014 11:24:29 +0100
Message-ID: <CAE9jt3-u_9gWOkZG7oCrGPuTqwCujfmLALtyz8keDKW921g0NQ@mail.gmail.com>
From: leon zawodowiec <vianom@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Time in Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4923902433692772432=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4923902433692772432==
Content-Type: multipart/alternative; boundary=047d7bfd090ac8ce210509c5f238

--047d7bfd090ac8ce210509c5f238
Content-Type: text/plain; charset=UTF-8

Hello,


I'm using Xen 4.2 on CentOS kernel - 3.10.56-11.el6.centos.alt.x86_64
I need to interfere in Xen source code, I would like to ask several
questions:


- How to set tsc_mode to 1 using virt-manager or virt-install tool - or
should I do it in different way?
- Where in code (Xen 4.2) can I find part responsible for time emulation
(while tsc_mode=1)
- Where can I find code in Xen which sends the current time to kernel

Thank you for responses

--047d7bfd090ac8ce210509c5f238
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,<br><br><br></div><div>I&#39;m using Xen 4.2 on=
 CentOS kernel - <span class=3D"im">3.10.56-11.el6.centos.alt.x86_64<br></s=
pan></div><div><span class=3D"im">I need to interfere in Xen source code, I=
 would like to ask several questions:<br><br><br></span></div><div><span cl=
ass=3D"im">- How to set tsc_mode to 1 using virt-manager or virt-install to=
ol - or should I do it in different way?<br></span></div><div><span class=
=3D"im">- Where in code (Xen 4.2) can I find part responsible for time emul=
ation (while tsc_mode=3D1)<br></span></div><div><span class=3D"im">- Where =
can I find code in Xen which sends the current time to kernel<br><br></span=
></div><div><span class=3D"im">Thank you for responses<br></span></div></di=
v>

--047d7bfd090ac8ce210509c5f238--


--===============4923902433692772432==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4923902433692772432==--


From xen-devel-bounces@lists.xen.org Tue Dec 09 10:24:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyHy5-00024Z-0D; Tue, 09 Dec 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 <vianom@gmail.com>) id 1XyHy3-00024R-EN
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:24:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	01/F9-15461-EDDC6845; Tue, 09 Dec 2014 10:24:30 +0000
X-Env-Sender: vianom@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418120670!14366424!1
X-Originating-IP: [74.125.82.49]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 311 invoked from network); 9 Dec 2014 10:24:30 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 10:24:30 -0000
Received: by mail-wg0-f49.google.com with SMTP id n12so397056wgh.8
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 02:24:30 -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=ldYjr0QOrY2194lymXZXo5iyxZLAHFrZxWzEPC8HA04=;
	b=Ilr8aYHHKF9qTbKDbaCAo6FsiEeaW+y4WJFZ7oTVsmpLxSkYxBjB4zrpbeLJ+xlJPb
	h7JZQX00DK5Z5HV82hvVVmjB1vtow/RKf655EQi9Hrc00THN3rDEZE/2cDEH1PjLq/EO
	gnL3Yh0RLzKy1AAls3WHOuA5duEulMfIah05FBXqYwii2H0OcXl//ZsyFh8OA1wxsmMt
	OgLCajFrwlBPwb031DtEUdPaP1lfbPdylZGsAKk5n8L4SijRnrWm4aw9FhvNOYwDfSAU
	147+8KSpTuSg2W4n48TP9GCfe9UT5a9egGHIa7R7C82PXEW745udT2+uuW+Vghpvqyj5
	XZbg==
MIME-Version: 1.0
X-Received: by 10.194.90.244 with SMTP id bz20mr3498398wjb.125.1418120670005; 
	Tue, 09 Dec 2014 02:24:30 -0800 (PST)
Received: by 10.216.35.1 with HTTP; Tue, 9 Dec 2014 02:24:29 -0800 (PST)
Date: Tue, 9 Dec 2014 11:24:29 +0100
Message-ID: <CAE9jt3-u_9gWOkZG7oCrGPuTqwCujfmLALtyz8keDKW921g0NQ@mail.gmail.com>
From: leon zawodowiec <vianom@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Time in Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4923902433692772432=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4923902433692772432==
Content-Type: multipart/alternative; boundary=047d7bfd090ac8ce210509c5f238

--047d7bfd090ac8ce210509c5f238
Content-Type: text/plain; charset=UTF-8

Hello,


I'm using Xen 4.2 on CentOS kernel - 3.10.56-11.el6.centos.alt.x86_64
I need to interfere in Xen source code, I would like to ask several
questions:


- How to set tsc_mode to 1 using virt-manager or virt-install tool - or
should I do it in different way?
- Where in code (Xen 4.2) can I find part responsible for time emulation
(while tsc_mode=1)
- Where can I find code in Xen which sends the current time to kernel

Thank you for responses

--047d7bfd090ac8ce210509c5f238
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,<br><br><br></div><div>I&#39;m using Xen 4.2 on=
 CentOS kernel - <span class=3D"im">3.10.56-11.el6.centos.alt.x86_64<br></s=
pan></div><div><span class=3D"im">I need to interfere in Xen source code, I=
 would like to ask several questions:<br><br><br></span></div><div><span cl=
ass=3D"im">- How to set tsc_mode to 1 using virt-manager or virt-install to=
ol - or should I do it in different way?<br></span></div><div><span class=
=3D"im">- Where in code (Xen 4.2) can I find part responsible for time emul=
ation (while tsc_mode=3D1)<br></span></div><div><span class=3D"im">- Where =
can I find code in Xen which sends the current time to kernel<br><br></span=
></div><div><span class=3D"im">Thank you for responses<br></span></div></di=
v>

--047d7bfd090ac8ce210509c5f238--


--===============4923902433692772432==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4923902433692772432==--


From xen-devel-bounces@lists.xen.org Tue Dec 09 10:33:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10:33:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyI6B-0002kB-3W; Tue, 09 Dec 2014 10:32: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 1XyI69-0002k6-Tj
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:32:54 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	D3/E1-05632-5DFC6845; Tue, 09 Dec 2014 10:32:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418121171!12008653!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 23409 invoked from network); 9 Dec 2014 10:32:52 -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;
	9 Dec 2014 10:32:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201813890"
Message-ID: <1418121168.14361.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mao Mingya <maomingya928@gmail.com>
Date: Tue, 9 Dec 2014 10:32:48 +0000
In-Reply-To: <em7c138492-1609-4e0c-9557-b64977f33550@sgp1030c>
References: <em7c138492-1609-4e0c-9557-b64977f33550@sgp1030c>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] arch arm qemu compile erro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-09 at 10:04 +0000, Mao Mingya wrote:
> While I tried to cross compile the qemu for xen with the following
> command:
> "make dist-stubdom CROSS_COMPILE=arm-linux-gnueabihf-
> XEN_TARGET_ARCH=arm32"
>  
> I got an error complain about the
> " ./extras/mini-os/arch/arm32/arch.mk: No such file or directory " is
> missing.
>  
> My xen source version is on "Xen-4.5.0-rc3"
>  
> Is the build process for xen broken? or some ./configure needed?

stubdoms are not supported on ARM right 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 Dec 09 10:33:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10:33:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyI6B-0002kB-3W; Tue, 09 Dec 2014 10:32: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 1XyI69-0002k6-Tj
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:32:54 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	D3/E1-05632-5DFC6845; Tue, 09 Dec 2014 10:32:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418121171!12008653!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 23409 invoked from network); 9 Dec 2014 10:32:52 -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;
	9 Dec 2014 10:32:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201813890"
Message-ID: <1418121168.14361.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mao Mingya <maomingya928@gmail.com>
Date: Tue, 9 Dec 2014 10:32:48 +0000
In-Reply-To: <em7c138492-1609-4e0c-9557-b64977f33550@sgp1030c>
References: <em7c138492-1609-4e0c-9557-b64977f33550@sgp1030c>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] arch arm qemu compile erro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-09 at 10:04 +0000, Mao Mingya wrote:
> While I tried to cross compile the qemu for xen with the following
> command:
> "make dist-stubdom CROSS_COMPILE=arm-linux-gnueabihf-
> XEN_TARGET_ARCH=arm32"
>  
> I got an error complain about the
> " ./extras/mini-os/arch/arm32/arch.mk: No such file or directory " is
> missing.
>  
> My xen source version is on "Xen-4.5.0-rc3"
>  
> Is the build process for xen broken? or some ./configure needed?

stubdoms are not supported on ARM right 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 Dec 09 10:33:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyI6v-0002nO-Gh; Tue, 09 Dec 2014 10:33:41 +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 1XyI6u-0002nH-V7
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:33:41 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	DE/38-14214-400D6845; Tue, 09 Dec 2014 10:33:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418121218!6903897!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 23771 invoked from network); 9 Dec 2014 10:33:39 -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;
	9 Dec 2014 10:33:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201814179"
Message-ID: <5486CFFF.7080400@citrix.com>
Date: Tue, 9 Dec 2014 10:33:35 +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: <5485F5F7.6040206@citrix.com>
	<5486C4FB020000780004DFBF@mail.emea.novell.com>
In-Reply-To: <5486C4FB020000780004DFBF@mail.emea.novell.com>
X-DLP: MIA2
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/12/14 08:46, Jan Beulich wrote:
>> We have certain machines which are showing reliable failure to boot
>> under Xen-4.5, where they worked with 4.4.  Symptoms range from the dom0
>> kernel crashing before printing anything, to complaining that the initrd
>> is corrupt when attempting to decompress.  This appears to be hardware
>> specific.
> Any chance this is C-state related, just like narrowed down to for
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00228.html?
> I.e. Westmere Xeons being affected? If not, this would seem rather
> worrying to me (read: a release blocker). And even if so, a workaround
> would be minimally needed. Otoh you didn't report so for earlier RCs -
> was that just because the testing scope was more narrow then, or can
> we imply that this is a recently introduced regression?
>
> Jan
>

I very much doubt it.  We blanket set max cstate to 1 on that era of
hardware, because the existing workarounds in Xen still experimentally
don't work.

https://github.com/xenserver/xen-4.4.pg/blob/master/detect-nehalem-c-state.patch

The first system I am looking at with a view to fixing is a SandyBridge
EN IBM Blade.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:33:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyI6v-0002nO-Gh; Tue, 09 Dec 2014 10:33:41 +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 1XyI6u-0002nH-V7
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:33:41 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	DE/38-14214-400D6845; Tue, 09 Dec 2014 10:33:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418121218!6903897!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 23771 invoked from network); 9 Dec 2014 10:33:39 -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;
	9 Dec 2014 10:33:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201814179"
Message-ID: <5486CFFF.7080400@citrix.com>
Date: Tue, 9 Dec 2014 10:33:35 +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: <5485F5F7.6040206@citrix.com>
	<5486C4FB020000780004DFBF@mail.emea.novell.com>
In-Reply-To: <5486C4FB020000780004DFBF@mail.emea.novell.com>
X-DLP: MIA2
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/12/14 08:46, Jan Beulich wrote:
>> We have certain machines which are showing reliable failure to boot
>> under Xen-4.5, where they worked with 4.4.  Symptoms range from the dom0
>> kernel crashing before printing anything, to complaining that the initrd
>> is corrupt when attempting to decompress.  This appears to be hardware
>> specific.
> Any chance this is C-state related, just like narrowed down to for
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00228.html?
> I.e. Westmere Xeons being affected? If not, this would seem rather
> worrying to me (read: a release blocker). And even if so, a workaround
> would be minimally needed. Otoh you didn't report so for earlier RCs -
> was that just because the testing scope was more narrow then, or can
> we imply that this is a recently introduced regression?
>
> Jan
>

I very much doubt it.  We blanket set max cstate to 1 on that era of
hardware, because the existing workarounds in Xen still experimentally
don't work.

https://github.com/xenserver/xen-4.4.pg/blob/master/detect-nehalem-c-state.patch

The first system I am looking at with a view to fixing is a SandyBridge
EN IBM Blade.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:39:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyIBp-00030z-7q; Tue, 09 Dec 2014 10:38: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 1XyIBn-00030n-VH
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:38:44 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	3D/89-02696-331D6845; Tue, 09 Dec 2014 10:38:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418121522!13904759!1
X-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 8234 invoked from network); 9 Dec 2014 10:38: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; 9 Dec 2014 10:38:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 10:38:41 +0000
Message-Id: <5486DF3E020000780004E0CF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 10:38:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zhang Yu" <yu.c.zhang@linux.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
In-Reply-To: <5486CAAF.9070807@linux.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, kevin.tian@intel.com, Paul.Durrant@citrix.com, keir@xen.org,
	Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 11:10, <yu.c.zhang@linux.intel.com> wrote:
>    As you can see, we are pushing our XenGT patches to the upstream. One 
> feature we need in xen is to translate guests' gfn to mfn in XenGT dom0 
> device model.
> 
>    Here we may have 2 similar solutions:
>    1> Paul told me(and thank you, Paul :)) that there used to be a 
> hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in 
> commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was no 
> usage at that time. So solution 1 is to revert this commit. However, 
> since this hypercall was removed ages ago, the reverting met many 
> conflicts, i.e. the gmfn_to_mfn is no longer used in x86, etc.
> 
>    2> In our project, we defined a new hypercall 
> XENMEM_get_mfn_from_pfn, which has a similar implementation like the 
> previous XENMEM_translate_gpfn_list. One of the major differences is 
> that this newly defined one is only for x86(called in arch_memory_op), 
> so we do not have to worry about the arm side.
> 
>    Does anyone has any suggestions about this?

Out of the two 1 seems preferable. But without background (see also
Paul's reply) it's hard to tell whether that's what you want/need.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:39:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyIBq-000316-Jk; Tue, 09 Dec 2014 10:38:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XyIBo-00030r-Tf
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:38:45 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	F4/CA-03148-331D6845; Tue, 09 Dec 2014 10:38:43 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418121522!10550141!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19815 invoked from network); 9 Dec 2014 10:38:43 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-11.tower-27.messagelabs.com with SMTP;
	9 Dec 2014 10:38:43 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 09 Dec 2014 02:36:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="495950466"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga003.jf.intel.com with ESMTP; 09 Dec 2014 02:34:57 -0800
Message-ID: <5486D0DD.1000902@linux.intel.com>
Date: Tue, 09 Dec 2014 18:37:17 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>, "Keir (Xen.org)" <keir@xen.org>,
	"Tim (Xen.org)" <tim@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>, 
	Kevin Tian <kevin.tian@intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/9/2014 6:19 PM, Paul Durrant wrote:
> I think use of an raw mfn value currently works only because dom0 is using a 1:1 IOMMU mapping scheme. Is my understanding correct, or do you really need raw mfn values?
Thanks for your quick response, Paul.
Well, not exactly for this case. :)
In XenGT, our need to translate gfn to mfn is for GPU's page table, 
which contains the translation between graphic address and the memory 
address. This page table is maintained by GPU drivers, and our service 
domain need to have a method to translate the guest physical addresses 
written by the vGPU into host physical ones.
We do not use IOMMU in XenGT and therefore this translation may not 
necessarily be a 1:1 mapping.

B.R.
Yu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:39:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyIBp-00030z-7q; Tue, 09 Dec 2014 10:38: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 1XyIBn-00030n-VH
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:38:44 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	3D/89-02696-331D6845; Tue, 09 Dec 2014 10:38:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418121522!13904759!1
X-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 8234 invoked from network); 9 Dec 2014 10:38: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; 9 Dec 2014 10:38:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 10:38:41 +0000
Message-Id: <5486DF3E020000780004E0CF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 10:38:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zhang Yu" <yu.c.zhang@linux.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
In-Reply-To: <5486CAAF.9070807@linux.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, kevin.tian@intel.com, Paul.Durrant@citrix.com, keir@xen.org,
	Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 11:10, <yu.c.zhang@linux.intel.com> wrote:
>    As you can see, we are pushing our XenGT patches to the upstream. One 
> feature we need in xen is to translate guests' gfn to mfn in XenGT dom0 
> device model.
> 
>    Here we may have 2 similar solutions:
>    1> Paul told me(and thank you, Paul :)) that there used to be a 
> hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in 
> commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was no 
> usage at that time. So solution 1 is to revert this commit. However, 
> since this hypercall was removed ages ago, the reverting met many 
> conflicts, i.e. the gmfn_to_mfn is no longer used in x86, etc.
> 
>    2> In our project, we defined a new hypercall 
> XENMEM_get_mfn_from_pfn, which has a similar implementation like the 
> previous XENMEM_translate_gpfn_list. One of the major differences is 
> that this newly defined one is only for x86(called in arch_memory_op), 
> so we do not have to worry about the arm side.
> 
>    Does anyone has any suggestions about this?

Out of the two 1 seems preferable. But without background (see also
Paul's reply) it's hard to tell whether that's what you want/need.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:39:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10: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 1XyIBq-000316-Jk; Tue, 09 Dec 2014 10:38:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XyIBo-00030r-Tf
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:38:45 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	F4/CA-03148-331D6845; Tue, 09 Dec 2014 10:38:43 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418121522!10550141!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19815 invoked from network); 9 Dec 2014 10:38:43 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-11.tower-27.messagelabs.com with SMTP;
	9 Dec 2014 10:38:43 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 09 Dec 2014 02:36:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="495950466"
Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.145.47])
	([10.238.145.47])
	by orsmga003.jf.intel.com with ESMTP; 09 Dec 2014 02:34:57 -0800
Message-ID: <5486D0DD.1000902@linux.intel.com>
Date: Tue, 09 Dec 2014 18:37:17 +0800
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>, "Keir (Xen.org)" <keir@xen.org>,
	"Tim (Xen.org)" <tim@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>, 
	Kevin Tian <kevin.tian@intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 12/9/2014 6:19 PM, Paul Durrant wrote:
> I think use of an raw mfn value currently works only because dom0 is using a 1:1 IOMMU mapping scheme. Is my understanding correct, or do you really need raw mfn values?
Thanks for your quick response, Paul.
Well, not exactly for this case. :)
In XenGT, our need to translate gfn to mfn is for GPU's page table, 
which contains the translation between graphic address and the memory 
address. This page table is maintained by GPU drivers, and our service 
domain need to have a method to translate the guest physical addresses 
written by the vGPU into host physical ones.
We do not use IOMMU in XenGT and therefore this translation may not 
necessarily be a 1:1 mapping.

B.R.
Yu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:47:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyIJi-0003XT-Hj; Tue, 09 Dec 2014 10:46:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XyIJg-0003XO-If
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:46:52 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	18/7A-09842-B13D6845; Tue, 09 Dec 2014 10:46:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418122011!14308348!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 5827 invoked from network); 9 Dec 2014 10:46:51 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 10:46:51 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XyIJN-000L0j-JG; Tue, 09 Dec 2014 10:46:33 +0000
Date: Tue, 9 Dec 2014 11:46:33 +0100
From: Tim Deegan <tim@xen.org>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Message-ID: <20141209104633.GC75319@deinos.phlegethon.org>
References: <5486CAAF.9070807@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5486CAAF.9070807@linux.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: kevin.tian@intel.com, Paul.Durrant@citrix.com, keir@xen.org,
	JBeulich@suse.com, Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> Hi all,
> 
>    As you can see, we are pushing our XenGT patches to the upstream. One 
> feature we need in xen is to translate guests' gfn to mfn in XenGT dom0 
> device model.
> 
>    Here we may have 2 similar solutions:
>    1> Paul told me(and thank you, Paul :)) that there used to be a 
> hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in 
> commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was no 
> usage at that time.

It's been suggested before that we should revive this hypercall, and I
don't think it's a good idea.  Whenever a domain needs to know the
actual MFN of another domain's memory it's usually because the
security model is problematic.  In particular, finding the MFN is
usually followed by a brute-force mapping from a dom0 process, or by
passing the MFN to a device for unprotected DMA.

These days DMA access should be protected by IOMMUs, or else
the device drivers (and associated tools) are effectively inside the
hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
presumably present on anything new enough to run XenGT?).

So I think the interface we need here is a please-map-this-gfn one,
like the existing grant-table ops (which already do what you need by
returning an address suitable for DMA).  If adding a grant entry for
every frame of the framebuffer within the guest is too much, maybe we
can make a new interface for the guest to grant access to larger areas.

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 Dec 09 10:47:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyIJi-0003XT-Hj; Tue, 09 Dec 2014 10:46:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XyIJg-0003XO-If
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:46:52 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	18/7A-09842-B13D6845; Tue, 09 Dec 2014 10:46:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418122011!14308348!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 5827 invoked from network); 9 Dec 2014 10:46:51 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 10:46:51 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XyIJN-000L0j-JG; Tue, 09 Dec 2014 10:46:33 +0000
Date: Tue, 9 Dec 2014 11:46:33 +0100
From: Tim Deegan <tim@xen.org>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Message-ID: <20141209104633.GC75319@deinos.phlegethon.org>
References: <5486CAAF.9070807@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5486CAAF.9070807@linux.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: kevin.tian@intel.com, Paul.Durrant@citrix.com, keir@xen.org,
	JBeulich@suse.com, Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> Hi all,
> 
>    As you can see, we are pushing our XenGT patches to the upstream. One 
> feature we need in xen is to translate guests' gfn to mfn in XenGT dom0 
> device model.
> 
>    Here we may have 2 similar solutions:
>    1> Paul told me(and thank you, Paul :)) that there used to be a 
> hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in 
> commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was no 
> usage at that time.

It's been suggested before that we should revive this hypercall, and I
don't think it's a good idea.  Whenever a domain needs to know the
actual MFN of another domain's memory it's usually because the
security model is problematic.  In particular, finding the MFN is
usually followed by a brute-force mapping from a dom0 process, or by
passing the MFN to a device for unprotected DMA.

These days DMA access should be protected by IOMMUs, or else
the device drivers (and associated tools) are effectively inside the
hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
presumably present on anything new enough to run XenGT?).

So I think the interface we need here is a please-map-this-gfn one,
like the existing grant-table ops (which already do what you need by
returning an address suitable for DMA).  If adding a grant entry for
every frame of the framebuffer within the guest is too much, maybe we
can make a new interface for the guest to grant access to larger areas.

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 Dec 09 10:50:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10:50:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyIMr-0003eN-4h; Tue, 09 Dec 2014 10:50:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyIMq-0003eB-2k
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:50:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	26/21-09842-FD3D6845; Tue, 09 Dec 2014 10:50:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418122206!14344680!1
X-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 15784 invoked from network); 9 Dec 2014 10:50:06 -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; 9 Dec 2014 10:50:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 10:50:06 +0000
Message-Id: <5486E1EA020000780004E108@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 10:50:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zhang Yu" <yu.c.zhang@linux.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
In-Reply-To: <5486D0DD.1000902@linux.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Kevin Tian <kevin.tian@intel.com>,
	Paul Durrant <Paul.Durrant@citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 11:37, <yu.c.zhang@linux.intel.com> wrote:
> On 12/9/2014 6:19 PM, Paul Durrant wrote:
>> I think use of an raw mfn value currently works only because dom0 is using a 
> 1:1 IOMMU mapping scheme. Is my understanding correct, or do you really need 
> raw mfn values?
> Thanks for your quick response, Paul.
> Well, not exactly for this case. :)
> In XenGT, our need to translate gfn to mfn is for GPU's page table, 
> which contains the translation between graphic address and the memory 
> address. This page table is maintained by GPU drivers, and our service 
> domain need to have a method to translate the guest physical addresses 
> written by the vGPU into host physical ones.
> We do not use IOMMU in XenGT and therefore this translation may not 
> necessarily be a 1:1 mapping.

Hmm, that suggests you indeed need raw MFNs, which in turn seems
problematic wrt PVH Dom0 (or you'd need a GFN->GMFN translation
layer). But while you don't use the IOMMU yourself, I suppose the GPU
accesses still don't bypass the IOMMU? In which case all you'd need
returned is a frame number that guarantees that after IOMMU
translation it refers to the correct MFN, i.e. still allowing for your Dom0
driver to simply set aside a part of its PFN space, asking Xen to
(IOMMU-)map the necessary guest frames into there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:50:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 10:50:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyIMr-0003eN-4h; Tue, 09 Dec 2014 10:50:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyIMq-0003eB-2k
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:50:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	26/21-09842-FD3D6845; Tue, 09 Dec 2014 10:50:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418122206!14344680!1
X-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 15784 invoked from network); 9 Dec 2014 10:50:06 -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; 9 Dec 2014 10:50:06 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 10:50:06 +0000
Message-Id: <5486E1EA020000780004E108@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 10:50:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Zhang Yu" <yu.c.zhang@linux.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
In-Reply-To: <5486D0DD.1000902@linux.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Kevin Tian <kevin.tian@intel.com>,
	Paul Durrant <Paul.Durrant@citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 11:37, <yu.c.zhang@linux.intel.com> wrote:
> On 12/9/2014 6:19 PM, Paul Durrant wrote:
>> I think use of an raw mfn value currently works only because dom0 is using a 
> 1:1 IOMMU mapping scheme. Is my understanding correct, or do you really need 
> raw mfn values?
> Thanks for your quick response, Paul.
> Well, not exactly for this case. :)
> In XenGT, our need to translate gfn to mfn is for GPU's page table, 
> which contains the translation between graphic address and the memory 
> address. This page table is maintained by GPU drivers, and our service 
> domain need to have a method to translate the guest physical addresses 
> written by the vGPU into host physical ones.
> We do not use IOMMU in XenGT and therefore this translation may not 
> necessarily be a 1:1 mapping.

Hmm, that suggests you indeed need raw MFNs, which in turn seems
problematic wrt PVH Dom0 (or you'd need a GFN->GMFN translation
layer). But while you don't use the IOMMU yourself, I suppose the GPU
accesses still don't bypass the IOMMU? In which case all you'd need
returned is a frame number that guarantees that after IOMMU
translation it refers to the correct MFN, i.e. still allowing for your Dom0
driver to simply set aside a part of its PFN space, asking Xen to
(IOMMU-)map the necessary guest frames into there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 10:51:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyIOO-0003mI-RB; Tue, 09 Dec 2014 10:51:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1XyIOM-0003m5-VQ
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:51:43 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	89/79-01660-D34D6845; Tue, 09 Dec 2014 10:51:41 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418122299!12302723!1
X-Originating-IP: [66.165.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 28263 invoked from network); 9 Dec 2014 10:51:40 -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 Dec 2014 10:51:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201818797"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 05:51:38 -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 1XyIOI-000823-9D	for
	xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:51:38 +0000
Message-ID: <5486D43A.7070504@citrix.com>
Date: Tue, 9 Dec 2014 10:51:38 +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: <5486CAAF.9070807@linux.intel.com>	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
In-Reply-To: <5486D0DD.1000902@linux.intel.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/12/14 10:37, Yu, Zhang wrote:
> 
> 
> On 12/9/2014 6:19 PM, Paul Durrant wrote:
>> I think use of an raw mfn value currently works only because dom0 is
>> using a 1:1 IOMMU mapping scheme. Is my understanding correct, or do
>> you really need raw mfn values?
> Thanks for your quick response, Paul.
> Well, not exactly for this case. :)
> In XenGT, our need to translate gfn to mfn is for GPU's page table,
> which contains the translation between graphic address and the memory
> address. This page table is maintained by GPU drivers, and our service
> domain need to have a method to translate the guest physical addresses
> written by the vGPU into host physical ones.
> We do not use IOMMU in XenGT and therefore this translation may not
> necessarily be a 1:1 mapping.

XenGT must use the IOMMU mappings that Xen has setup for the domain
which owns the GPU. Currently Dom0 own's the GPU and so it's IOMMU
mappings match the MFN's addresses. I suspect XenGT will not work if Xen
is booted with iommu=dom0-strict.

Malcolm

> 
> B.R.
> Yu
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 09 10:51:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyIOO-0003mI-RB; Tue, 09 Dec 2014 10:51:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1XyIOM-0003m5-VQ
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:51:43 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	89/79-01660-D34D6845; Tue, 09 Dec 2014 10:51:41 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418122299!12302723!1
X-Originating-IP: [66.165.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 28263 invoked from network); 9 Dec 2014 10:51:40 -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 Dec 2014 10:51:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201818797"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 05:51:38 -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 1XyIOI-000823-9D	for
	xen-devel@lists.xen.org; Tue, 09 Dec 2014 10:51:38 +0000
Message-ID: <5486D43A.7070504@citrix.com>
Date: Tue, 9 Dec 2014 10:51:38 +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: <5486CAAF.9070807@linux.intel.com>	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
In-Reply-To: <5486D0DD.1000902@linux.intel.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/12/14 10:37, Yu, Zhang wrote:
> 
> 
> On 12/9/2014 6:19 PM, Paul Durrant wrote:
>> I think use of an raw mfn value currently works only because dom0 is
>> using a 1:1 IOMMU mapping scheme. Is my understanding correct, or do
>> you really need raw mfn values?
> Thanks for your quick response, Paul.
> Well, not exactly for this case. :)
> In XenGT, our need to translate gfn to mfn is for GPU's page table,
> which contains the translation between graphic address and the memory
> address. This page table is maintained by GPU drivers, and our service
> domain need to have a method to translate the guest physical addresses
> written by the vGPU into host physical ones.
> We do not use IOMMU in XenGT and therefore this translation may not
> necessarily be a 1:1 mapping.

XenGT must use the IOMMU mappings that Xen has setup for the domain
which owns the GPU. Currently Dom0 own's the GPU and so it's IOMMU
mappings match the MFN's addresses. I suspect XenGT will not work if Xen
is booted with iommu=dom0-strict.

Malcolm

> 
> B.R.
> Yu
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 09 11:00:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:00:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyIWH-0004F1-Pg; Tue, 09 Dec 2014 10:59:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyIWF-0004Ew-Im
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 10:59:51 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	19/32-15461-626D6845; Tue, 09 Dec 2014 10:59:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418122789!14352014!1
X-Originating-IP: [66.165.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 3192 invoked from network); 9 Dec 2014 10:59:50 -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;
	9 Dec 2014 10:59:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="202220969"
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.210.2; Tue, 9 Dec 2014 05:59: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 1XyIVi-0000YS-NG;
	Tue, 09 Dec 2014 10:59:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyIVi-0001uk-HK;
	Tue, 09 Dec 2014 10:59:18 +0000
Date: Tue, 9 Dec 2014 10:59:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32152-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] 32152: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32152 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32152/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt       5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 32100
 test-amd64-amd64-libvirt      5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 32100
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32100
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 32100
 test-armhf-armhf-libvirt      7 debian-install            fail REGR. vs. 32100
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32100
 test-amd64-i386-freebsd10-amd64  5 xen-boot               fail REGR. vs. 32100
 test-amd64-i386-freebsd10-i386  5 xen-boot                fail REGR. vs. 32100
 test-armhf-armhf-xl           7 debian-install            fail REGR. vs. 32100
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot           fail REGR. vs. 32100
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32100
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32100
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 32100
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32100
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32100
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot           fail REGR. vs. 32100
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 32100
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 32100
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 32100
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32100
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32100
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 32100
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot            fail REGR. vs. 32100
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot          fail REGR. vs. 32100
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32100
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32100
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 32100
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 32100
 test-amd64-i386-xl-winxpsp3   5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot             fail REGR. vs. 32100
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 32100
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 32100
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32100
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 32100
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 32100
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot            fail REGR. vs. 32100

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 32100
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot            fail blocked in 32100
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 32100
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot           fail blocked in 32100

version targeted for testing:
 linux                8191d07dbb16ae88cc2bc475584b9f185f02795f
baseline version:
 linux                7cc78f8fa02c2485104b86434acbc1538a3bd807

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 Tue Dec 09 11:00:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:00:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyIWH-0004F1-Pg; Tue, 09 Dec 2014 10:59:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyIWF-0004Ew-Im
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 10:59:51 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	19/32-15461-626D6845; Tue, 09 Dec 2014 10:59:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418122789!14352014!1
X-Originating-IP: [66.165.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 3192 invoked from network); 9 Dec 2014 10:59:50 -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;
	9 Dec 2014 10:59:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="202220969"
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.210.2; Tue, 9 Dec 2014 05:59: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 1XyIVi-0000YS-NG;
	Tue, 09 Dec 2014 10:59:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyIVi-0001uk-HK;
	Tue, 09 Dec 2014 10:59:18 +0000
Date: Tue, 9 Dec 2014 10:59:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32152-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] 32152: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32152 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32152/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt       5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 32100
 test-amd64-amd64-libvirt      5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 32100
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32100
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 32100
 test-armhf-armhf-libvirt      7 debian-install            fail REGR. vs. 32100
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32100
 test-amd64-i386-freebsd10-amd64  5 xen-boot               fail REGR. vs. 32100
 test-amd64-i386-freebsd10-i386  5 xen-boot                fail REGR. vs. 32100
 test-armhf-armhf-xl           7 debian-install            fail REGR. vs. 32100
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot           fail REGR. vs. 32100
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32100
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32100
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 32100
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32100
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32100
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot           fail REGR. vs. 32100
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 32100
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 32100
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 32100
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32100
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32100
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 32100
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot            fail REGR. vs. 32100
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot          fail REGR. vs. 32100
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32100
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32100
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 32100
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 32100
 test-amd64-i386-xl-winxpsp3   5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot             fail REGR. vs. 32100
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 32100
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 32100
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32100
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 32100
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 32100
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot            fail REGR. vs. 32100

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 32100
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 32100
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot            fail blocked in 32100
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 32100
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot           fail blocked in 32100

version targeted for testing:
 linux                8191d07dbb16ae88cc2bc475584b9f185f02795f
baseline version:
 linux                7cc78f8fa02c2485104b86434acbc1538a3bd807

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 Tue Dec 09 11:02:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11: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 1XyIYj-0004Q9-K7; Tue, 09 Dec 2014 11:02:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyIYi-0004Q3-3v
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:02:24 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	49/E5-27584-FB6D6845; Tue, 09 Dec 2014 11:02:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418122942!8964883!1
X-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 20388 invoked from network); 9 Dec 2014 11:02:22 -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; 9 Dec 2014 11:02:22 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 11:02:22 +0000
Message-Id: <5486E4CA020000780004E125@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 11:02:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "leon zawodowiec" <vianom@gmail.com>
References: <CAE9jt3-u_9gWOkZG7oCrGPuTqwCujfmLALtyz8keDKW921g0NQ@mail.gmail.com>
In-Reply-To: <CAE9jt3-u_9gWOkZG7oCrGPuTqwCujfmLALtyz8keDKW921g0NQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Time in Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 11:24, <vianom@gmail.com> wrote:
> - Where in code (Xen 4.2) can I find part responsible for time emulation
> (while tsc_mode=1)

xen/arch/x86/time.c:tsc_set_info() is where things get set up.

> - Where can I find code in Xen which sends the current time to kernel

xen/arch/x86/time.c:__update_vcpu_system_time()

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:02:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11: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 1XyIYj-0004Q9-K7; Tue, 09 Dec 2014 11:02:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyIYi-0004Q3-3v
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:02:24 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	49/E5-27584-FB6D6845; Tue, 09 Dec 2014 11:02:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418122942!8964883!1
X-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 20388 invoked from network); 9 Dec 2014 11:02:22 -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; 9 Dec 2014 11:02:22 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 11:02:22 +0000
Message-Id: <5486E4CA020000780004E125@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 11:02:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "leon zawodowiec" <vianom@gmail.com>
References: <CAE9jt3-u_9gWOkZG7oCrGPuTqwCujfmLALtyz8keDKW921g0NQ@mail.gmail.com>
In-Reply-To: <CAE9jt3-u_9gWOkZG7oCrGPuTqwCujfmLALtyz8keDKW921g0NQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Time in Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 11:24, <vianom@gmail.com> wrote:
> - Where in code (Xen 4.2) can I find part responsible for time emulation
> (while tsc_mode=1)

xen/arch/x86/time.c:tsc_set_info() is where things get set up.

> - Where can I find code in Xen which sends the current time to kernel

xen/arch/x86/time.c:__update_vcpu_system_time()

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:05:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyIbb-0004nM-6m; Tue, 09 Dec 2014 11:05:23 +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 1XyIbZ-0004nF-4n
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:05:21 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	5E/03-27623-077D6845; Tue, 09 Dec 2014 11:05:20 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418123119!7593709!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30593 invoked from network); 9 Dec 2014 11:05:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 11:05:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="27660731"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>, "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijD3J3fQrwFk2EUD3dyNOBb5yHAtaAgAARbAA=
Date: Tue, 9 Dec 2014 11:05:07 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
In-Reply-To: <20141209104633.GC75319@deinos.phlegethon.org>
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: Kevin Tian <kevin.tian@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: 09 December 2014 10:47
> To: Yu, Zhang
> Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> devel@lists.xen.org
> Subject: Re: One question about the hypercall to translate gfn to mfn.
> 
> At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > Hi all,
> >
> >    As you can see, we are pushing our XenGT patches to the upstream. One
> > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > device model.
> >
> >    Here we may have 2 similar solutions:
> >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was
> no
> > usage at that time.
> 
> It's been suggested before that we should revive this hypercall, and I
> don't think it's a good idea.  Whenever a domain needs to know the
> actual MFN of another domain's memory it's usually because the
> security model is problematic.  In particular, finding the MFN is
> usually followed by a brute-force mapping from a dom0 process, or by
> passing the MFN to a device for unprotected DMA.
> 
> These days DMA access should be protected by IOMMUs, or else
> the device drivers (and associated tools) are effectively inside the
> hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> presumably present on anything new enough to run XenGT?).
> 
> So I think the interface we need here is a please-map-this-gfn one,
> like the existing grant-table ops (which already do what you need by
> returning an address suitable for DMA).  If adding a grant entry for
> every frame of the framebuffer within the guest is too much, maybe we
> can make a new interface for the guest to grant access to larger areas.
> 

IIUC the in-guest driver is Xen-unaware so any grant entry would have to be put in the guests table by the tools, which would entail some form of flexibly sized reserved range of grant entries otherwise any PV driver that are present in the guest would merrily clobber the new grant entries.
A domain can already priv map a gfn into the MMU, so I think we just need an equivalent for the IOMMU.

  Paul

> 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 Dec 09 11:05:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyIbb-0004nM-6m; Tue, 09 Dec 2014 11:05:23 +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 1XyIbZ-0004nF-4n
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:05:21 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	5E/03-27623-077D6845; Tue, 09 Dec 2014 11:05:20 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418123119!7593709!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30593 invoked from network); 9 Dec 2014 11:05:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 11:05:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="27660731"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>, "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijD3J3fQrwFk2EUD3dyNOBb5yHAtaAgAARbAA=
Date: Tue, 9 Dec 2014 11:05:07 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
In-Reply-To: <20141209104633.GC75319@deinos.phlegethon.org>
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: Kevin Tian <kevin.tian@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: 09 December 2014 10:47
> To: Yu, Zhang
> Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> devel@lists.xen.org
> Subject: Re: One question about the hypercall to translate gfn to mfn.
> 
> At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > Hi all,
> >
> >    As you can see, we are pushing our XenGT patches to the upstream. One
> > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > device model.
> >
> >    Here we may have 2 similar solutions:
> >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was
> no
> > usage at that time.
> 
> It's been suggested before that we should revive this hypercall, and I
> don't think it's a good idea.  Whenever a domain needs to know the
> actual MFN of another domain's memory it's usually because the
> security model is problematic.  In particular, finding the MFN is
> usually followed by a brute-force mapping from a dom0 process, or by
> passing the MFN to a device for unprotected DMA.
> 
> These days DMA access should be protected by IOMMUs, or else
> the device drivers (and associated tools) are effectively inside the
> hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> presumably present on anything new enough to run XenGT?).
> 
> So I think the interface we need here is a please-map-this-gfn one,
> like the existing grant-table ops (which already do what you need by
> returning an address suitable for DMA).  If adding a grant entry for
> every frame of the framebuffer within the guest is too much, maybe we
> can make a new interface for the guest to grant access to larger areas.
> 

IIUC the in-guest driver is Xen-unaware so any grant entry would have to be put in the guests table by the tools, which would entail some form of flexibly sized reserved range of grant entries otherwise any PV driver that are present in the guest would merrily clobber the new grant entries.
A domain can already priv map a gfn into the MMU, so I think we just need an equivalent for the IOMMU.

  Paul

> 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 Dec 09 11:11:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyIhC-00050a-5I; Tue, 09 Dec 2014 11:11:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyIhB-00050U-5R
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:11:09 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	33/80-27623-CC8D6845; Tue, 09 Dec 2014 11:11:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418123466!8306305!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 18239 invoked from network); 9 Dec 2014 11:11: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;
	9 Dec 2014 11:11:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201824438"
Message-ID: <1418123464.14361.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Tue, 9 Dec 2014 11:11:04 +0000
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Kevin Tian <kevin.tian@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-09 at 11:05 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Tim Deegan [mailto:tim@xen.org]
> > Sent: 09 December 2014 10:47
> > To: Yu, Zhang
> > Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> > devel@lists.xen.org
> > Subject: Re: One question about the hypercall to translate gfn to mfn.
> > 
> > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > Hi all,
> > >
> > >    As you can see, we are pushing our XenGT patches to the upstream. One
> > > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > > device model.
> > >
> > >    Here we may have 2 similar solutions:
> > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was
> > no
> > > usage at that time.
> > 
> > It's been suggested before that we should revive this hypercall, and I
> > don't think it's a good idea.  Whenever a domain needs to know the
> > actual MFN of another domain's memory it's usually because the
> > security model is problematic.  In particular, finding the MFN is
> > usually followed by a brute-force mapping from a dom0 process, or by
> > passing the MFN to a device for unprotected DMA.
> > 
> > These days DMA access should be protected by IOMMUs, or else
> > the device drivers (and associated tools) are effectively inside the
> > hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> > presumably present on anything new enough to run XenGT?).
> > 
> > So I think the interface we need here is a please-map-this-gfn one,
> > like the existing grant-table ops (which already do what you need by
> > returning an address suitable for DMA).  If adding a grant entry for
> > every frame of the framebuffer within the guest is too much, maybe we
> > can make a new interface for the guest to grant access to larger areas.
> > 
> 
> IIUC the in-guest driver is Xen-unaware so any grant entry would have
> to be put in the guests table by the tools, which would entail some
> form of flexibly sized reserved range of grant entries otherwise any
> PV driver that are present in the guest would merrily clobber the new
> grant entries.
> A domain can already priv map a gfn into the MMU, so I think we just
>  need an equivalent for the IOMMU.

I'm not sure I'm fully understanding what's going on here, but is a
variant of XENMEM_add_to_physmap+XENMAPSPACE_gmfn_foreign which also
returns a DMA handle a plausible solution?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:11:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyIhC-00050a-5I; Tue, 09 Dec 2014 11:11:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyIhB-00050U-5R
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:11:09 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	33/80-27623-CC8D6845; Tue, 09 Dec 2014 11:11:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418123466!8306305!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 18239 invoked from network); 9 Dec 2014 11:11: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;
	9 Dec 2014 11:11:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201824438"
Message-ID: <1418123464.14361.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Tue, 9 Dec 2014 11:11:04 +0000
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Kevin Tian <kevin.tian@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-09 at 11:05 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Tim Deegan [mailto:tim@xen.org]
> > Sent: 09 December 2014 10:47
> > To: Yu, Zhang
> > Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> > devel@lists.xen.org
> > Subject: Re: One question about the hypercall to translate gfn to mfn.
> > 
> > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > Hi all,
> > >
> > >    As you can see, we are pushing our XenGT patches to the upstream. One
> > > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > > device model.
> > >
> > >    Here we may have 2 similar solutions:
> > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was
> > no
> > > usage at that time.
> > 
> > It's been suggested before that we should revive this hypercall, and I
> > don't think it's a good idea.  Whenever a domain needs to know the
> > actual MFN of another domain's memory it's usually because the
> > security model is problematic.  In particular, finding the MFN is
> > usually followed by a brute-force mapping from a dom0 process, or by
> > passing the MFN to a device for unprotected DMA.
> > 
> > These days DMA access should be protected by IOMMUs, or else
> > the device drivers (and associated tools) are effectively inside the
> > hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> > presumably present on anything new enough to run XenGT?).
> > 
> > So I think the interface we need here is a please-map-this-gfn one,
> > like the existing grant-table ops (which already do what you need by
> > returning an address suitable for DMA).  If adding a grant entry for
> > every frame of the framebuffer within the guest is too much, maybe we
> > can make a new interface for the guest to grant access to larger areas.
> > 
> 
> IIUC the in-guest driver is Xen-unaware so any grant entry would have
> to be put in the guests table by the tools, which would entail some
> form of flexibly sized reserved range of grant entries otherwise any
> PV driver that are present in the guest would merrily clobber the new
> grant entries.
> A domain can already priv map a gfn into the MMU, so I think we just
>  need an equivalent for the IOMMU.

I'm not sure I'm fully understanding what's going on here, but is a
variant of XENMEM_add_to_physmap+XENMAPSPACE_gmfn_foreign which also
returns a DMA handle a plausible solution?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:12:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11: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 1XyIi4-00054s-J1; Tue, 09 Dec 2014 11:12: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 1XyIi3-00054i-7R
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:12:03 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	15/E7-31453-209D6845; Tue, 09 Dec 2014 11:12:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418123520!8197778!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 27308 invoked from network); 9 Dec 2014 11:12:01 -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;
	9 Dec 2014 11:12:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="202224751"
Message-ID: <1418123518.14361.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Tue, 9 Dec 2014 11:11:58 +0000
In-Reply-To: <5486F36502000066000825D5@soto.provo.novell.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
	<20141208111214.GC17128@zion.uk.xensource.com>
	<5486F36502000066000825D5@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, 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, 2014-12-08 at 22:04 -0700, Chun Yan Liu wrote:
> Partly. At least for domain disk snapshot create/delete, I prefer using
> qmp commands instead of calling qemu-img one by one. Using qmp
> commands, libvirt will need libxl's help. Of course, if libxl doesn't
> supply that, libvirt can call qemu-img to each disk one by one,
> not preferred but can do.

You can't use qmp unless the domain is active, for an inactive domain
there is no qemu to talk to, so you have to use qemu-img anyway in that
case. Does libvirt not have existing code to do all this sort of thing?
(I thought so, but it turns out I may be wrong, see below).

And for an active domain I expect that *must* use qmp, since it seems
unlikely that you can go around changing things under the feet of an
active process (maybe I'm wrong?).

> > > Following the constraint that it's better NOT to supply disk snapshot 
> > > functions in libxl, then we let xl and libvirt do that by themselve 
> > > separately, that's OK. 
> > >  
> > > Then I think NO new API needs to be exported in libxl, since: 
> > > * saving/restoring memory, there are already APIs. 
> >  
> > The principle is that if existing API doesn't work good enough for you 
> > we will consider adding a new one. 
> >  
> > We probably need a new API. If you want to do a live snapshot, we would 
> > need to notify xl that we are in the middle of pausing and resuming a 
> > domain.  
> 
> This is where we discussed a lot. Do we really need
> libxl_domain_snapshot_create API? or does xl can do the work?
> 
> Even for live snapshot, after calling libxl_domain_suspend with LIVE flags,
> memory is saved and domain is paused. xl then can call disk snapshot
> functions to finish disk snapshots, after all of that, call libxl_domain_unpause
> to unpause the domain. So I don't think xl has any trouble to do that.
> In case there is some misunderstanding, please point out.

My mistake, I incorrectly remembered that libxl_domain_suspend would
destroy (for save or migate) or resume (for checkpoint) the guest before
returning. Having refreshed my memory I see that you are correct: it
returns with the domain paused and it is up to the toolstack to resume
or destroy it as it wishes. Sorry for the confusion.

Given that it does seem like the toolstack could indeed take the
disksnapshots itself without an additional API.

> > However the current architecture for libvirt to use libxl is like 
> >  
> >   libvirt 
> >   libxl 
> >   [other lower level stuffs] 
> >  
> > So implementing snapshot management in xl cannot work for you either. 
> > It's not part of the current architecture.

This is correct, xl should not be involved in a libvirt control stack,
it is orthogonal.

> You are right. I understand you are trying to suggest a way to ease the job.
> Here just to make clear this way is really better and finally acceptable? :-)
> Just IMO, I think xl snapshot-list is wanted, that means managing snapshots
> in xl is needed.

The xl idiom is that you do this sort of operation with existing CLI
commands e.g. ls /var/lib/vm-images/*.qcow2, lvs, qemu-img etc.

Adding snapshot-list to xl would be a whole load of work to create a
bunch of infrastructure which you do not need to do.

My understanding was that your primary aim here was to enable snapshots
via libvirt and that xl support was just a nice to have. Is that right?

> > Not that I'm against the idea of managing domain snapshot in xl, I'm 
> > trying to reduce workload here. 
> >  
> > > > The  
> > > > downside is that now xl and libvirt are disconnected, but I think it's  
> > > > fine. 
> > >  
> > > Two things here: 
> > > 1. connect xl and libvirt, then will need to manage snapshot info in libxl  
> > (or 
> > >     libxlu) That's not preferred since the initial design. This is not the  
> > point 
> > >     we discuss here. 
> > > 2. for xl only, list snapshots and delete snapshots, also need to manage 
> > >     snapshot info (in xl) 
> > >  
> > > Considering manage snapshot info in xl, only question is about idl and 
> > > gentypes.py, expected structure is as following and expected to be saved 
> > > into json file, but it contains xl namespace and libxl namespace things, 
> > > gentypes.py will have problem. Better ideas? 
> > >  
> > > typedef struct xl_domain_snapshot { 
> > >     char * name; 
> > >     char * description; 
> > >     uint64_t creation_time; 
> > >     char * memory_path; 
> > >     int num_disks; 
> > >     libxl_disk_snapshot *disks; 
> > >     char *parent; 
> > >     bool *current; 
> > > } xl_domain_snapshot; 
> > >  
> >  
> > The libxl_disk_snapshot suggests that you still want storage management 
> > inside libxl, which should probably be in libxlu? 
> 
> Yeah. I may put it in libxlu.

This depends on who the consumers of this datastructure are:

If xl only -> put it in xl itself.
If libvirt+xl -> put it in libxlu.

My understanding was that libvirt already has data structures for
dealing with snapshots, but this was based entirely on the commands
listed by:
        virsh help | grep -E pool-\|snapshot-
which seemed to me to be pretty feature rich and suggested that libvirt
has a great deal of support for storage and snapshot management already.

If libvirt already has generic infrastructure for managing snapshots
this then IMHO you should use it, not reimplement it on the Xen side
(whether in libxl, libxlu or xl), the additions to Xen should be limited
to providing the underlying functionality which libvirt's generic code
requires from the backend.

However, Wei has suggested to me that perhaps libvirt's snapshotting
capabilities are not as generic internally as I might have imaged and
that it is up to each backend driver to reinvent things, is that true?

If Wei's suggestion is correct then it may turn out that it is useful to
put some of the new generic code which you would need to write into
libxlu.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:12:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11: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 1XyIi4-00054s-J1; Tue, 09 Dec 2014 11:12: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 1XyIi3-00054i-7R
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:12:03 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	15/E7-31453-209D6845; Tue, 09 Dec 2014 11:12:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418123520!8197778!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 27308 invoked from network); 9 Dec 2014 11:12:01 -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;
	9 Dec 2014 11:12:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="202224751"
Message-ID: <1418123518.14361.20.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Tue, 9 Dec 2014 11:11:58 +0000
In-Reply-To: <5486F36502000066000825D5@soto.provo.novell.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
	<20141208111214.GC17128@zion.uk.xensource.com>
	<5486F36502000066000825D5@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, 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, 2014-12-08 at 22:04 -0700, Chun Yan Liu wrote:
> Partly. At least for domain disk snapshot create/delete, I prefer using
> qmp commands instead of calling qemu-img one by one. Using qmp
> commands, libvirt will need libxl's help. Of course, if libxl doesn't
> supply that, libvirt can call qemu-img to each disk one by one,
> not preferred but can do.

You can't use qmp unless the domain is active, for an inactive domain
there is no qemu to talk to, so you have to use qemu-img anyway in that
case. Does libvirt not have existing code to do all this sort of thing?
(I thought so, but it turns out I may be wrong, see below).

And for an active domain I expect that *must* use qmp, since it seems
unlikely that you can go around changing things under the feet of an
active process (maybe I'm wrong?).

> > > Following the constraint that it's better NOT to supply disk snapshot 
> > > functions in libxl, then we let xl and libvirt do that by themselve 
> > > separately, that's OK. 
> > >  
> > > Then I think NO new API needs to be exported in libxl, since: 
> > > * saving/restoring memory, there are already APIs. 
> >  
> > The principle is that if existing API doesn't work good enough for you 
> > we will consider adding a new one. 
> >  
> > We probably need a new API. If you want to do a live snapshot, we would 
> > need to notify xl that we are in the middle of pausing and resuming a 
> > domain.  
> 
> This is where we discussed a lot. Do we really need
> libxl_domain_snapshot_create API? or does xl can do the work?
> 
> Even for live snapshot, after calling libxl_domain_suspend with LIVE flags,
> memory is saved and domain is paused. xl then can call disk snapshot
> functions to finish disk snapshots, after all of that, call libxl_domain_unpause
> to unpause the domain. So I don't think xl has any trouble to do that.
> In case there is some misunderstanding, please point out.

My mistake, I incorrectly remembered that libxl_domain_suspend would
destroy (for save or migate) or resume (for checkpoint) the guest before
returning. Having refreshed my memory I see that you are correct: it
returns with the domain paused and it is up to the toolstack to resume
or destroy it as it wishes. Sorry for the confusion.

Given that it does seem like the toolstack could indeed take the
disksnapshots itself without an additional API.

> > However the current architecture for libvirt to use libxl is like 
> >  
> >   libvirt 
> >   libxl 
> >   [other lower level stuffs] 
> >  
> > So implementing snapshot management in xl cannot work for you either. 
> > It's not part of the current architecture.

This is correct, xl should not be involved in a libvirt control stack,
it is orthogonal.

> You are right. I understand you are trying to suggest a way to ease the job.
> Here just to make clear this way is really better and finally acceptable? :-)
> Just IMO, I think xl snapshot-list is wanted, that means managing snapshots
> in xl is needed.

The xl idiom is that you do this sort of operation with existing CLI
commands e.g. ls /var/lib/vm-images/*.qcow2, lvs, qemu-img etc.

Adding snapshot-list to xl would be a whole load of work to create a
bunch of infrastructure which you do not need to do.

My understanding was that your primary aim here was to enable snapshots
via libvirt and that xl support was just a nice to have. Is that right?

> > Not that I'm against the idea of managing domain snapshot in xl, I'm 
> > trying to reduce workload here. 
> >  
> > > > The  
> > > > downside is that now xl and libvirt are disconnected, but I think it's  
> > > > fine. 
> > >  
> > > Two things here: 
> > > 1. connect xl and libvirt, then will need to manage snapshot info in libxl  
> > (or 
> > >     libxlu) That's not preferred since the initial design. This is not the  
> > point 
> > >     we discuss here. 
> > > 2. for xl only, list snapshots and delete snapshots, also need to manage 
> > >     snapshot info (in xl) 
> > >  
> > > Considering manage snapshot info in xl, only question is about idl and 
> > > gentypes.py, expected structure is as following and expected to be saved 
> > > into json file, but it contains xl namespace and libxl namespace things, 
> > > gentypes.py will have problem. Better ideas? 
> > >  
> > > typedef struct xl_domain_snapshot { 
> > >     char * name; 
> > >     char * description; 
> > >     uint64_t creation_time; 
> > >     char * memory_path; 
> > >     int num_disks; 
> > >     libxl_disk_snapshot *disks; 
> > >     char *parent; 
> > >     bool *current; 
> > > } xl_domain_snapshot; 
> > >  
> >  
> > The libxl_disk_snapshot suggests that you still want storage management 
> > inside libxl, which should probably be in libxlu? 
> 
> Yeah. I may put it in libxlu.

This depends on who the consumers of this datastructure are:

If xl only -> put it in xl itself.
If libvirt+xl -> put it in libxlu.

My understanding was that libvirt already has data structures for
dealing with snapshots, but this was based entirely on the commands
listed by:
        virsh help | grep -E pool-\|snapshot-
which seemed to me to be pretty feature rich and suggested that libvirt
has a great deal of support for storage and snapshot management already.

If libvirt already has generic infrastructure for managing snapshots
this then IMHO you should use it, not reimplement it on the Xen side
(whether in libxl, libxlu or xl), the additions to Xen should be limited
to providing the underlying functionality which libvirt's generic code
requires from the backend.

However, Wei has suggested to me that perhaps libvirt's snapshotting
capabilities are not as generic internally as I might have imaged and
that it is up to each backend driver to reinvent things, is that true?

If Wei's suggestion is correct then it may turn out that it is useful to
put some of the new generic code which you would need to write into
libxlu.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:17:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:17:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyImy-0005VQ-Hf; Tue, 09 Dec 2014 11:17:08 +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 1XyImw-0005VC-B0
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:17:06 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	67/AE-26858-13AD6845; Tue, 09 Dec 2014 11:17:05 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418123824!9594896!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7085 invoked from network); 9 Dec 2014 11:17:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 11:17:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="27661389"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQE5ijD3J3fQrwFk2EUD3dyNOBb5yHAtaAgAARbAD///VuAIAAEfsA
Date: Tue, 9 Dec 2014 11:17:03 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
In-Reply-To: <1418123464.14361.19.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: Kevin Tian <kevin.tian@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 09 December 2014 11:11
> To: Paul Durrant
> Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); JBeulich@suse.com;
> Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] One question about the hypercall to translate gfn to
> mfn.
> 
> On Tue, 2014-12-09 at 11:05 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Tim Deegan [mailto:tim@xen.org]
> > > Sent: 09 December 2014 10:47
> > > To: Yu, Zhang
> > > Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> > > devel@lists.xen.org
> > > Subject: Re: One question about the hypercall to translate gfn to mfn.
> > >
> > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > > Hi all,
> > > >
> > > >    As you can see, we are pushing our XenGT patches to the upstream.
> One
> > > > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > > > device model.
> > > >
> > > >    Here we may have 2 similar solutions:
> > > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there
> was
> > > no
> > > > usage at that time.
> > >
> > > It's been suggested before that we should revive this hypercall, and I
> > > don't think it's a good idea.  Whenever a domain needs to know the
> > > actual MFN of another domain's memory it's usually because the
> > > security model is problematic.  In particular, finding the MFN is
> > > usually followed by a brute-force mapping from a dom0 process, or by
> > > passing the MFN to a device for unprotected DMA.
> > >
> > > These days DMA access should be protected by IOMMUs, or else
> > > the device drivers (and associated tools) are effectively inside the
> > > hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> > > presumably present on anything new enough to run XenGT?).
> > >
> > > So I think the interface we need here is a please-map-this-gfn one,
> > > like the existing grant-table ops (which already do what you need by
> > > returning an address suitable for DMA).  If adding a grant entry for
> > > every frame of the framebuffer within the guest is too much, maybe we
> > > can make a new interface for the guest to grant access to larger areas.
> > >
> >
> > IIUC the in-guest driver is Xen-unaware so any grant entry would have
> > to be put in the guests table by the tools, which would entail some
> > form of flexibly sized reserved range of grant entries otherwise any
> > PV driver that are present in the guest would merrily clobber the new
> > grant entries.
> > A domain can already priv map a gfn into the MMU, so I think we just
> >  need an equivalent for the IOMMU.
> 
> I'm not sure I'm fully understanding what's going on here, but is a
> variant of XENMEM_add_to_physmap+XENMAPSPACE_gmfn_foreign which
> also
> returns a DMA handle a plausible solution?
> 

I think we want be able to avoid setting up a PTE in the MMU since it's not needed in most (or perhaps all?) cases.

  Paul

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:17:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:17:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyImy-0005VQ-Hf; Tue, 09 Dec 2014 11:17:08 +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 1XyImw-0005VC-B0
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:17:06 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	67/AE-26858-13AD6845; Tue, 09 Dec 2014 11:17:05 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418123824!9594896!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7085 invoked from network); 9 Dec 2014 11:17:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 11:17:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="27661389"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQE5ijD3J3fQrwFk2EUD3dyNOBb5yHAtaAgAARbAD///VuAIAAEfsA
Date: Tue, 9 Dec 2014 11:17:03 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
In-Reply-To: <1418123464.14361.19.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: Kevin Tian <kevin.tian@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 09 December 2014 11:11
> To: Paul Durrant
> Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); JBeulich@suse.com;
> Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] One question about the hypercall to translate gfn to
> mfn.
> 
> On Tue, 2014-12-09 at 11:05 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Tim Deegan [mailto:tim@xen.org]
> > > Sent: 09 December 2014 10:47
> > > To: Yu, Zhang
> > > Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> > > devel@lists.xen.org
> > > Subject: Re: One question about the hypercall to translate gfn to mfn.
> > >
> > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > > Hi all,
> > > >
> > > >    As you can see, we are pushing our XenGT patches to the upstream.
> One
> > > > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > > > device model.
> > > >
> > > >    Here we may have 2 similar solutions:
> > > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there
> was
> > > no
> > > > usage at that time.
> > >
> > > It's been suggested before that we should revive this hypercall, and I
> > > don't think it's a good idea.  Whenever a domain needs to know the
> > > actual MFN of another domain's memory it's usually because the
> > > security model is problematic.  In particular, finding the MFN is
> > > usually followed by a brute-force mapping from a dom0 process, or by
> > > passing the MFN to a device for unprotected DMA.
> > >
> > > These days DMA access should be protected by IOMMUs, or else
> > > the device drivers (and associated tools) are effectively inside the
> > > hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> > > presumably present on anything new enough to run XenGT?).
> > >
> > > So I think the interface we need here is a please-map-this-gfn one,
> > > like the existing grant-table ops (which already do what you need by
> > > returning an address suitable for DMA).  If adding a grant entry for
> > > every frame of the framebuffer within the guest is too much, maybe we
> > > can make a new interface for the guest to grant access to larger areas.
> > >
> >
> > IIUC the in-guest driver is Xen-unaware so any grant entry would have
> > to be put in the guests table by the tools, which would entail some
> > form of flexibly sized reserved range of grant entries otherwise any
> > PV driver that are present in the guest would merrily clobber the new
> > grant entries.
> > A domain can already priv map a gfn into the MMU, so I think we just
> >  need an equivalent for the IOMMU.
> 
> I'm not sure I'm fully understanding what's going on here, but is a
> variant of XENMEM_add_to_physmap+XENMAPSPACE_gmfn_foreign which
> also
> returns a DMA handle a plausible solution?
> 

I think we want be able to avoid setting up a PTE in the MMU since it's not needed in most (or perhaps all?) cases.

  Paul

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:22:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:22:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyIru-0005hl-8Y; Tue, 09 Dec 2014 11:22:14 +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 1XyIrt-0005hg-Be
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:22:13 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	11/AC-22777-46BD6845; Tue, 09 Dec 2014 11:22:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418124130!8200505!1
X-Originating-IP: [66.165.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 15027 invoked from network); 9 Dec 2014 11:22:11 -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;
	9 Dec 2014 11:22:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201827171"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 06:22: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 1XyIrp-0000L1-Lj;
	Tue, 09 Dec 2014 11:22:09 +0000
Date: Tue, 9 Dec 2014 11:22:09 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141209112209.GC25749@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-2-git-send-email-wei.liu2@citrix.com>
	<5485E779020000780004DE1F@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5485E779020000780004DE1F@mail.emea.novell.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@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 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 Mon, Dec 08, 2014 at 05:01:29PM +0000, Jan Beulich wrote:
[...]
> > +        for ( i = 0; i < vnuma->nr_vnodes; i++ )
> > +        {
> > +            err = snprintf(keyhandler_scratch, 12, "%3u",
> > +                    vnuma->vnode_to_pnode[i]);
> > +            if ( err < 0 || vnuma->vnode_to_pnode[i] == NUMA_NO_NODE )
> > +                strlcpy(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("%16"PRIu64" MB: %#016"PRIx64" - %#016"PRIx64"\n",
> 
> Am I misremembering that these were just "0x%"PRIx64 originally?

Yes.

> I ask because converting to the 0-padded fixed width form makes
> no sense together with the # modifier. For these ranges I think it's

OK.

> quite obvious that the numbers are hex, so I'd suggest dropping
> the #s without replacement. And to be honest I'm also against
> printing duplicate information: The memory range already specifies
> how much memory this is.
> 

Is this what you want?

+                if ( vnuma->vmemrange[j].nid == i )
+                {
+                    printk("         %016"PRIx64" - %016"PRIx64"\n",
+                           vnuma->vmemrange[j].start,
+                           vnuma->vmemrange[j].end);
+                }

And it prints out something like:

(XEN)      2 vnodes, 2 vcpus:
(XEN)        vnode    0 - pnode   0
(XEN)          0000000000000000 - 00000000bb800000
(XEN)        vcpus:   0

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:22:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:22:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyIru-0005hl-8Y; Tue, 09 Dec 2014 11:22:14 +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 1XyIrt-0005hg-Be
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:22:13 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	11/AC-22777-46BD6845; Tue, 09 Dec 2014 11:22:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418124130!8200505!1
X-Originating-IP: [66.165.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 15027 invoked from network); 9 Dec 2014 11:22:11 -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;
	9 Dec 2014 11:22:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201827171"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 06:22: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 1XyIrp-0000L1-Lj;
	Tue, 09 Dec 2014 11:22:09 +0000
Date: Tue, 9 Dec 2014 11:22:09 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141209112209.GC25749@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-2-git-send-email-wei.liu2@citrix.com>
	<5485E779020000780004DE1F@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5485E779020000780004DE1F@mail.emea.novell.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@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 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 Mon, Dec 08, 2014 at 05:01:29PM +0000, Jan Beulich wrote:
[...]
> > +        for ( i = 0; i < vnuma->nr_vnodes; i++ )
> > +        {
> > +            err = snprintf(keyhandler_scratch, 12, "%3u",
> > +                    vnuma->vnode_to_pnode[i]);
> > +            if ( err < 0 || vnuma->vnode_to_pnode[i] == NUMA_NO_NODE )
> > +                strlcpy(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("%16"PRIu64" MB: %#016"PRIx64" - %#016"PRIx64"\n",
> 
> Am I misremembering that these were just "0x%"PRIx64 originally?

Yes.

> I ask because converting to the 0-padded fixed width form makes
> no sense together with the # modifier. For these ranges I think it's

OK.

> quite obvious that the numbers are hex, so I'd suggest dropping
> the #s without replacement. And to be honest I'm also against
> printing duplicate information: The memory range already specifies
> how much memory this is.
> 

Is this what you want?

+                if ( vnuma->vmemrange[j].nid == i )
+                {
+                    printk("         %016"PRIx64" - %016"PRIx64"\n",
+                           vnuma->vmemrange[j].start,
+                           vnuma->vmemrange[j].end);
+                }

And it prints out something like:

(XEN)      2 vnodes, 2 vcpus:
(XEN)        vnode    0 - pnode   0
(XEN)          0000000000000000 - 00000000bb800000
(XEN)        vcpus:   0

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:23:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyIsj-00061T-MF; Tue, 09 Dec 2014 11:23: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 1XyIsi-00061F-8Z
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 11:23:04 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	F0/96-19763-79BD6845; Tue, 09 Dec 2014 11:23:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418124181!6917797!1
X-Originating-IP: [66.165.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 8154 invoked from network); 9 Dec 2014 11:23: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;
	9 Dec 2014 11:23:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="202227477"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 06:23:00 -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 1XyIse-0000M6-AQ;
	Tue, 09 Dec 2014 11:23:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyIsd-0002xD-MM;
	Tue, 09 Dec 2014 11:22:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21638.56211.381241.397871@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 11:22:59 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417186350.23604.54.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>
	<21624.35587.721780.498045@mariner.uk.xensource.com>
	<1417186350.23604.54.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 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 Fri, 2014-11-28 at 14:47 +0000, Ian Jackson wrote:
> > 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?

Yes.

> > 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.

Should I take this as an ack ?

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 Dec 09 11:23:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyIsj-00061T-MF; Tue, 09 Dec 2014 11:23: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 1XyIsi-00061F-8Z
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 11:23:04 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	F0/96-19763-79BD6845; Tue, 09 Dec 2014 11:23:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418124181!6917797!1
X-Originating-IP: [66.165.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 8154 invoked from network); 9 Dec 2014 11:23: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;
	9 Dec 2014 11:23:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="202227477"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 06:23:00 -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 1XyIse-0000M6-AQ;
	Tue, 09 Dec 2014 11:23:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyIsd-0002xD-MM;
	Tue, 09 Dec 2014 11:22:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21638.56211.381241.397871@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 11:22:59 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417186350.23604.54.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>
	<21624.35587.721780.498045@mariner.uk.xensource.com>
	<1417186350.23604.54.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 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 Fri, 2014-11-28 at 14:47 +0000, Ian Jackson wrote:
> > 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?

Yes.

> > 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.

Should I take this as an ack ?

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 Dec 09 11:23:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11: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 1XyIt6-00067I-3b; Tue, 09 Dec 2014 11:23: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 1XyIt4-00066m-6h
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:23:26 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	8A/E5-02953-DABD6845; Tue, 09 Dec 2014 11:23:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418124204!13918603!1
X-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 7216 invoked from network); 9 Dec 2014 11:23:24 -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; 9 Dec 2014 11:23:24 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 11:23:24 +0000
Message-Id: <5486E9B8020000780004E163@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 11:23:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul Durrant" <Paul.Durrant@citrix.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	Zhang Yu <yu.c.zhang@linux.intel.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 12:17, <Paul.Durrant@citrix.com> wrote:
> I think we want be able to avoid setting up a PTE in the MMU since it's not 
> needed in most (or perhaps all?) cases.

With shared page tables, there's no way to do one without the other.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:23:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11: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 1XyIt6-00067I-3b; Tue, 09 Dec 2014 11:23: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 1XyIt4-00066m-6h
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:23:26 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	8A/E5-02953-DABD6845; Tue, 09 Dec 2014 11:23:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418124204!13918603!1
X-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 7216 invoked from network); 9 Dec 2014 11:23:24 -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; 9 Dec 2014 11:23:24 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 11:23:24 +0000
Message-Id: <5486E9B8020000780004E163@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 11:23:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul Durrant" <Paul.Durrant@citrix.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	Zhang Yu <yu.c.zhang@linux.intel.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 12:17, <Paul.Durrant@citrix.com> wrote:
> I think we want be able to avoid setting up a PTE in the MMU since it's not 
> needed in most (or perhaps all?) cases.

With shared page tables, there's no way to do one without the other.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:28:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:28:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyIxv-0006PA-Rk; Tue, 09 Dec 2014 11:28:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1XyIxu-0006P5-T1
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:28:27 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	3A/EF-28865-ADCD6845; Tue, 09 Dec 2014 11:28:26 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418124503!12305646!1
X-Originating-IP: [66.165.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 10216 invoked from network); 9 Dec 2014 11:28:25 -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;
	9 Dec 2014 11:28:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201828820"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 06:28:23 -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 1XyIxq-0000TZ-S0	for
	xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:28:22 +0000
Message-ID: <5486DCD6.5000302@citrix.com>
Date: Tue, 9 Dec 2014 11:28:22 +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: <5486CAAF.9070807@linux.intel.com>	<20141209104633.GC75319@deinos.phlegethon.org>	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>	<1418123464.14361.19.camel@citrix.com>	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
	<5486E9B8020000780004E163@mail.emea.novell.com>
In-Reply-To: <5486E9B8020000780004E163@mail.emea.novell.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/12/14 11:23, Jan Beulich wrote:
>>>> On 09.12.14 at 12:17, <Paul.Durrant@citrix.com> wrote:
>> I think we want be able to avoid setting up a PTE in the MMU since it's not 
>> needed in most (or perhaps all?) cases.
> 
> With shared page tables, there's no way to do one without the other.
> 
Interestingly the IOMMU in front of the Intel GPU is only capable of
handling 4k pages and so we wouldn't end up with share page tables being
used.

For other PCI device's then shared page tables will be a problem.

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 Tue Dec 09 11:28:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:28:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyIxv-0006PA-Rk; Tue, 09 Dec 2014 11:28:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1XyIxu-0006P5-T1
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:28:27 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	3A/EF-28865-ADCD6845; Tue, 09 Dec 2014 11:28:26 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418124503!12305646!1
X-Originating-IP: [66.165.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 10216 invoked from network); 9 Dec 2014 11:28:25 -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;
	9 Dec 2014 11:28:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201828820"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 06:28:23 -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 1XyIxq-0000TZ-S0	for
	xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:28:22 +0000
Message-ID: <5486DCD6.5000302@citrix.com>
Date: Tue, 9 Dec 2014 11:28:22 +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: <5486CAAF.9070807@linux.intel.com>	<20141209104633.GC75319@deinos.phlegethon.org>	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>	<1418123464.14361.19.camel@citrix.com>	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
	<5486E9B8020000780004E163@mail.emea.novell.com>
In-Reply-To: <5486E9B8020000780004E163@mail.emea.novell.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/12/14 11:23, Jan Beulich wrote:
>>>> On 09.12.14 at 12:17, <Paul.Durrant@citrix.com> wrote:
>> I think we want be able to avoid setting up a PTE in the MMU since it's not 
>> needed in most (or perhaps all?) cases.
> 
> With shared page tables, there's no way to do one without the other.
> 
Interestingly the IOMMU in front of the Intel GPU is only capable of
handling 4k pages and so we wouldn't end up with share page tables being
used.

For other PCI device's then shared page tables will be a problem.

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 Tue Dec 09 11:29:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11: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 1XyIyd-0006Sh-8k; Tue, 09 Dec 2014 11:29:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyIyb-0006SO-Kh
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:29:09 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	CF/1F-22819-40DD6845; Tue, 09 Dec 2014 11:29:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418124546!12305828!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 17632 invoked from network); 9 Dec 2014 11:29:08 -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;
	9 Dec 2014 11:29:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201829040"
Message-ID: <1418124543.14361.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Tue, 9 Dec 2014 11:29:03 +0000
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Kevin Tian <kevin.tian@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-09 at 11:17 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 09 December 2014 11:11
> > To: Paul Durrant
> > Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); JBeulich@suse.com;
> > Xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] One question about the hypercall to translate gfn to
> > mfn.
> > 
> > On Tue, 2014-12-09 at 11:05 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Tim Deegan [mailto:tim@xen.org]
> > > > Sent: 09 December 2014 10:47
> > > > To: Yu, Zhang
> > > > Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> > > > devel@lists.xen.org
> > > > Subject: Re: One question about the hypercall to translate gfn to mfn.
> > > >
> > > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > > > Hi all,
> > > > >
> > > > >    As you can see, we are pushing our XenGT patches to the upstream.
> > One
> > > > > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > > > > device model.
> > > > >
> > > > >    Here we may have 2 similar solutions:
> > > > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > > > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > > > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there
> > was
> > > > no
> > > > > usage at that time.
> > > >
> > > > It's been suggested before that we should revive this hypercall, and I
> > > > don't think it's a good idea.  Whenever a domain needs to know the
> > > > actual MFN of another domain's memory it's usually because the
> > > > security model is problematic.  In particular, finding the MFN is
> > > > usually followed by a brute-force mapping from a dom0 process, or by
> > > > passing the MFN to a device for unprotected DMA.
> > > >
> > > > These days DMA access should be protected by IOMMUs, or else
> > > > the device drivers (and associated tools) are effectively inside the
> > > > hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> > > > presumably present on anything new enough to run XenGT?).
> > > >
> > > > So I think the interface we need here is a please-map-this-gfn one,
> > > > like the existing grant-table ops (which already do what you need by
> > > > returning an address suitable for DMA).  If adding a grant entry for
> > > > every frame of the framebuffer within the guest is too much, maybe we
> > > > can make a new interface for the guest to grant access to larger areas.
> > > >
> > >
> > > IIUC the in-guest driver is Xen-unaware so any grant entry would have
> > > to be put in the guests table by the tools, which would entail some
> > > form of flexibly sized reserved range of grant entries otherwise any
> > > PV driver that are present in the guest would merrily clobber the new
> > > grant entries.
> > > A domain can already priv map a gfn into the MMU, so I think we just
> > >  need an equivalent for the IOMMU.
> > 
> > I'm not sure I'm fully understanding what's going on here, but is a
> > variant of XENMEM_add_to_physmap+XENMAPSPACE_gmfn_foreign which
> > also
> > returns a DMA handle a plausible solution?
> > 
> 
> I think we want be able to avoid setting up a PTE in the MMU since
> it's not needed in most (or perhaps all?) cases.

Another (wildly under-informed) thought then:

A while back Global logic proposed (for ARM) an infrastructure for
allowing dom0 drivers to maintain a set of iommu like pagetables under
hypervisor supervision (they called these "remoteprocessor iommu").

I didn't fully grok what it was at the time, let alone remember the
details properly now, but AIUI it was essentially a framework for
allowing a simple Xen side driver to provide PV-MMU-like update
operations for a set of PTs which were not the main-processor's PTs,
with validation etc.

See http://thread.gmane.org/gmane.comp.emulators.xen.devel/212945

The introductory email even mentions GPUs...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:29:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11: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 1XyIyd-0006Sh-8k; Tue, 09 Dec 2014 11:29:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyIyb-0006SO-Kh
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:29:09 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	CF/1F-22819-40DD6845; Tue, 09 Dec 2014 11:29:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418124546!12305828!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 17632 invoked from network); 9 Dec 2014 11:29:08 -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;
	9 Dec 2014 11:29:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201829040"
Message-ID: <1418124543.14361.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Tue, 9 Dec 2014 11:29:03 +0000
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Kevin Tian <kevin.tian@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-09 at 11:17 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 09 December 2014 11:11
> > To: Paul Durrant
> > Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); JBeulich@suse.com;
> > Xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] One question about the hypercall to translate gfn to
> > mfn.
> > 
> > On Tue, 2014-12-09 at 11:05 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Tim Deegan [mailto:tim@xen.org]
> > > > Sent: 09 December 2014 10:47
> > > > To: Yu, Zhang
> > > > Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> > > > devel@lists.xen.org
> > > > Subject: Re: One question about the hypercall to translate gfn to mfn.
> > > >
> > > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > > > Hi all,
> > > > >
> > > > >    As you can see, we are pushing our XenGT patches to the upstream.
> > One
> > > > > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > > > > device model.
> > > > >
> > > > >    Here we may have 2 similar solutions:
> > > > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > > > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > > > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there
> > was
> > > > no
> > > > > usage at that time.
> > > >
> > > > It's been suggested before that we should revive this hypercall, and I
> > > > don't think it's a good idea.  Whenever a domain needs to know the
> > > > actual MFN of another domain's memory it's usually because the
> > > > security model is problematic.  In particular, finding the MFN is
> > > > usually followed by a brute-force mapping from a dom0 process, or by
> > > > passing the MFN to a device for unprotected DMA.
> > > >
> > > > These days DMA access should be protected by IOMMUs, or else
> > > > the device drivers (and associated tools) are effectively inside the
> > > > hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> > > > presumably present on anything new enough to run XenGT?).
> > > >
> > > > So I think the interface we need here is a please-map-this-gfn one,
> > > > like the existing grant-table ops (which already do what you need by
> > > > returning an address suitable for DMA).  If adding a grant entry for
> > > > every frame of the framebuffer within the guest is too much, maybe we
> > > > can make a new interface for the guest to grant access to larger areas.
> > > >
> > >
> > > IIUC the in-guest driver is Xen-unaware so any grant entry would have
> > > to be put in the guests table by the tools, which would entail some
> > > form of flexibly sized reserved range of grant entries otherwise any
> > > PV driver that are present in the guest would merrily clobber the new
> > > grant entries.
> > > A domain can already priv map a gfn into the MMU, so I think we just
> > >  need an equivalent for the IOMMU.
> > 
> > I'm not sure I'm fully understanding what's going on here, but is a
> > variant of XENMEM_add_to_physmap+XENMAPSPACE_gmfn_foreign which
> > also
> > returns a DMA handle a plausible solution?
> > 
> 
> I think we want be able to avoid setting up a PTE in the MMU since
> it's not needed in most (or perhaps all?) cases.

Another (wildly under-informed) thought then:

A while back Global logic proposed (for ARM) an infrastructure for
allowing dom0 drivers to maintain a set of iommu like pagetables under
hypervisor supervision (they called these "remoteprocessor iommu").

I didn't fully grok what it was at the time, let alone remember the
details properly now, but AIUI it was essentially a framework for
allowing a simple Xen side driver to provide PV-MMU-like update
operations for a set of PTs which were not the main-processor's PTs,
with validation etc.

See http://thread.gmane.org/gmane.comp.emulators.xen.devel/212945

The introductory email even mentions GPUs...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:32:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:32:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJ1N-0006dW-RK; Tue, 09 Dec 2014 11:32: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 1XyJ1M-0006dN-8L
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 11:32:00 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	FD/C2-26858-FADD6845; Tue, 09 Dec 2014 11:31:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418124717!12029277!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 32423 invoked from network); 9 Dec 2014 11:31:59 -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;
	9 Dec 2014 11:31:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201829968"
Message-ID: <1418124715.14361.29.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 9 Dec 2014 11:31:55 +0000
In-Reply-To: <21638.56211.381241.397871@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>
	<1417186350.23604.54.camel@citrix.com>
	<21638.56211.381241.397871@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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 Tue, 2014-12-09 at 11:22 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 5/6] libxl: events: Deregister evtchn fd when not needed"):
> > On Fri, 2014-11-28 at 14:47 +0000, Ian Jackson wrote:
> > > 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?
> 
> Yes.
> 
> > > 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.
> 
> Should I take this as an ack ?

There were other comments further down my original review which you
haven't answered. I don't think they were (all) predicated on a
particular answer to the first question (although some were).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:32:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:32:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJ1N-0006dW-RK; Tue, 09 Dec 2014 11:32: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 1XyJ1M-0006dN-8L
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 11:32:00 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	FD/C2-26858-FADD6845; Tue, 09 Dec 2014 11:31:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418124717!12029277!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 32423 invoked from network); 9 Dec 2014 11:31:59 -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;
	9 Dec 2014 11:31:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201829968"
Message-ID: <1418124715.14361.29.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 9 Dec 2014 11:31:55 +0000
In-Reply-To: <21638.56211.381241.397871@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>
	<1417186350.23604.54.camel@citrix.com>
	<21638.56211.381241.397871@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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 Tue, 2014-12-09 at 11:22 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 5/6] libxl: events: Deregister evtchn fd when not needed"):
> > On Fri, 2014-11-28 at 14:47 +0000, Ian Jackson wrote:
> > > 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?
> 
> Yes.
> 
> > > 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.
> 
> Should I take this as an ack ?

There were other comments further down my original review which you
haven't answered. I don't think they were (all) predicated on a
particular answer to the first question (although some were).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:39:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJ7n-00076G-TH; Tue, 09 Dec 2014 11:38:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyJ7m-00076B-Iu
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:38:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	85/30-25276-D3FD6845; Tue, 09 Dec 2014 11:38:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418125117!7078119!1
X-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 11576 invoked from network); 9 Dec 2014 11:38: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; 9 Dec 2014 11:38:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 11:38:35 +0000
Message-Id: <5486ED48020000780004E1A0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 11:38:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-2-git-send-email-wei.liu2@citrix.com>
	<5485E779020000780004DE1F@mail.emea.novell.com>
	<20141209112209.GC25749@zion.uk.xensource.com>
In-Reply-To: <20141209112209.GC25749@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 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 09.12.14 at 12:22, <wei.liu2@citrix.com> wrote:
> Is this what you want?
> 
> +                if ( vnuma->vmemrange[j].nid == i )
> +                {
> +                    printk("         %016"PRIx64" - %016"PRIx64"\n",
> +                           vnuma->vmemrange[j].start,
> +                           vnuma->vmemrange[j].end);
> +                }
> 
> And it prints out something like:
> 
> (XEN)      2 vnodes, 2 vcpus:
> (XEN)        vnode    0 - pnode   0
> (XEN)          0000000000000000 - 00000000bb800000
> (XEN)        vcpus:   0

This looks fine, yes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:39:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJ7n-00076G-TH; Tue, 09 Dec 2014 11:38:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyJ7m-00076B-Iu
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:38:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	85/30-25276-D3FD6845; Tue, 09 Dec 2014 11:38:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418125117!7078119!1
X-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 11576 invoked from network); 9 Dec 2014 11:38: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; 9 Dec 2014 11:38:37 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 11:38:35 +0000
Message-Id: <5486ED48020000780004E1A0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 11:38:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-2-git-send-email-wei.liu2@citrix.com>
	<5485E779020000780004DE1F@mail.emea.novell.com>
	<20141209112209.GC25749@zion.uk.xensource.com>
In-Reply-To: <20141209112209.GC25749@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 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 09.12.14 at 12:22, <wei.liu2@citrix.com> wrote:
> Is this what you want?
> 
> +                if ( vnuma->vmemrange[j].nid == i )
> +                {
> +                    printk("         %016"PRIx64" - %016"PRIx64"\n",
> +                           vnuma->vmemrange[j].start,
> +                           vnuma->vmemrange[j].end);
> +                }
> 
> And it prints out something like:
> 
> (XEN)      2 vnodes, 2 vcpus:
> (XEN)        vnode    0 - pnode   0
> (XEN)          0000000000000000 - 00000000bb800000
> (XEN)        vcpus:   0

This looks fine, yes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:44:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:44:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJCx-0007V3-M1; Tue, 09 Dec 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 <Paul.Durrant@citrix.com>) id 1XyJCv-0007Uy-Ug
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:43:58 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	31/25-14727-D70E6845; Tue, 09 Dec 2014 11:43:57 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418125436!12319493!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13980 invoked from network); 9 Dec 2014 11:43:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 11:43:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="27662590"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQE5ijD3J3fQrwFk2EUD3dyNOBb5yHAtaAgAARbAD///VuAIAAEfsA///zC4CAABO6YA==
Date: Tue, 9 Dec 2014 11:43:54 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD0257859BB@AMSPEX01CL01.citrite.net>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
	<1418124543.14361.27.camel@citrix.com>
In-Reply-To: <1418124543.14361.27.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: Kevin Tian <kevin.tian@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 09 December 2014 11:29
> To: Paul Durrant
> Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); JBeulich@suse.com;
> Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] One question about the hypercall to translate gfn to
> mfn.
> 
> On Tue, 2014-12-09 at 11:17 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 09 December 2014 11:11
> > > To: Paul Durrant
> > > Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org);
> JBeulich@suse.com;
> > > Xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] One question about the hypercall to translate
> gfn to
> > > mfn.
> > >
> > > On Tue, 2014-12-09 at 11:05 +0000, Paul Durrant wrote:
> > > > > -----Original Message-----
> > > > > From: Tim Deegan [mailto:tim@xen.org]
> > > > > Sent: 09 December 2014 10:47
> > > > > To: Yu, Zhang
> > > > > Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> > > > > devel@lists.xen.org
> > > > > Subject: Re: One question about the hypercall to translate gfn to mfn.
> > > > >
> > > > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > > > > Hi all,
> > > > > >
> > > > > >    As you can see, we are pushing our XenGT patches to the
> upstream.
> > > One
> > > > > > feature we need in xen is to translate guests' gfn to mfn in XenGT
> dom0
> > > > > > device model.
> > > > > >
> > > > > >    Here we may have 2 similar solutions:
> > > > > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > > > > hypercall, XENMEM_translate_gpfn_list, which was removed by
> Keir in
> > > > > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because
> there
> > > was
> > > > > no
> > > > > > usage at that time.
> > > > >
> > > > > It's been suggested before that we should revive this hypercall, and I
> > > > > don't think it's a good idea.  Whenever a domain needs to know the
> > > > > actual MFN of another domain's memory it's usually because the
> > > > > security model is problematic.  In particular, finding the MFN is
> > > > > usually followed by a brute-force mapping from a dom0 process, or by
> > > > > passing the MFN to a device for unprotected DMA.
> > > > >
> > > > > These days DMA access should be protected by IOMMUs, or else
> > > > > the device drivers (and associated tools) are effectively inside the
> > > > > hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> > > > > presumably present on anything new enough to run XenGT?).
> > > > >
> > > > > So I think the interface we need here is a please-map-this-gfn one,
> > > > > like the existing grant-table ops (which already do what you need by
> > > > > returning an address suitable for DMA).  If adding a grant entry for
> > > > > every frame of the framebuffer within the guest is too much, maybe
> we
> > > > > can make a new interface for the guest to grant access to larger areas.
> > > > >
> > > >
> > > > IIUC the in-guest driver is Xen-unaware so any grant entry would have
> > > > to be put in the guests table by the tools, which would entail some
> > > > form of flexibly sized reserved range of grant entries otherwise any
> > > > PV driver that are present in the guest would merrily clobber the new
> > > > grant entries.
> > > > A domain can already priv map a gfn into the MMU, so I think we just
> > > >  need an equivalent for the IOMMU.
> > >
> > > I'm not sure I'm fully understanding what's going on here, but is a
> > > variant of XENMEM_add_to_physmap+XENMAPSPACE_gmfn_foreign
> which
> > > also
> > > returns a DMA handle a plausible solution?
> > >
> >
> > I think we want be able to avoid setting up a PTE in the MMU since
> > it's not needed in most (or perhaps all?) cases.
> 
> Another (wildly under-informed) thought then:
> 
> A while back Global logic proposed (for ARM) an infrastructure for
> allowing dom0 drivers to maintain a set of iommu like pagetables under
> hypervisor supervision (they called these "remoteprocessor iommu").
> 
> I didn't fully grok what it was at the time, let alone remember the
> details properly now, but AIUI it was essentially a framework for
> allowing a simple Xen side driver to provide PV-MMU-like update
> operations for a set of PTs which were not the main-processor's PTs,
> with validation etc.
> 
> See http://thread.gmane.org/gmane.comp.emulators.xen.devel/212945
> 
> The introductory email even mentions GPUs...
> 

That series does indeed seem to be very relevant.

  Paul

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:44:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:44:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJCx-0007V3-M1; Tue, 09 Dec 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 <Paul.Durrant@citrix.com>) id 1XyJCv-0007Uy-Ug
	for Xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:43:58 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	31/25-14727-D70E6845; Tue, 09 Dec 2014 11:43:57 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418125436!12319493!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13980 invoked from network); 9 Dec 2014 11:43:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 11:43:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="27662590"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQE5ijD3J3fQrwFk2EUD3dyNOBb5yHAtaAgAARbAD///VuAIAAEfsA///zC4CAABO6YA==
Date: Tue, 9 Dec 2014 11:43:54 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD0257859BB@AMSPEX01CL01.citrite.net>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
	<1418124543.14361.27.camel@citrix.com>
In-Reply-To: <1418124543.14361.27.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: Kevin Tian <kevin.tian@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 09 December 2014 11:29
> To: Paul Durrant
> Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); JBeulich@suse.com;
> Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] One question about the hypercall to translate gfn to
> mfn.
> 
> On Tue, 2014-12-09 at 11:17 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 09 December 2014 11:11
> > > To: Paul Durrant
> > > Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org);
> JBeulich@suse.com;
> > > Xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] One question about the hypercall to translate
> gfn to
> > > mfn.
> > >
> > > On Tue, 2014-12-09 at 11:05 +0000, Paul Durrant wrote:
> > > > > -----Original Message-----
> > > > > From: Tim Deegan [mailto:tim@xen.org]
> > > > > Sent: 09 December 2014 10:47
> > > > > To: Yu, Zhang
> > > > > Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> > > > > devel@lists.xen.org
> > > > > Subject: Re: One question about the hypercall to translate gfn to mfn.
> > > > >
> > > > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > > > > Hi all,
> > > > > >
> > > > > >    As you can see, we are pushing our XenGT patches to the
> upstream.
> > > One
> > > > > > feature we need in xen is to translate guests' gfn to mfn in XenGT
> dom0
> > > > > > device model.
> > > > > >
> > > > > >    Here we may have 2 similar solutions:
> > > > > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > > > > hypercall, XENMEM_translate_gpfn_list, which was removed by
> Keir in
> > > > > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because
> there
> > > was
> > > > > no
> > > > > > usage at that time.
> > > > >
> > > > > It's been suggested before that we should revive this hypercall, and I
> > > > > don't think it's a good idea.  Whenever a domain needs to know the
> > > > > actual MFN of another domain's memory it's usually because the
> > > > > security model is problematic.  In particular, finding the MFN is
> > > > > usually followed by a brute-force mapping from a dom0 process, or by
> > > > > passing the MFN to a device for unprotected DMA.
> > > > >
> > > > > These days DMA access should be protected by IOMMUs, or else
> > > > > the device drivers (and associated tools) are effectively inside the
> > > > > hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> > > > > presumably present on anything new enough to run XenGT?).
> > > > >
> > > > > So I think the interface we need here is a please-map-this-gfn one,
> > > > > like the existing grant-table ops (which already do what you need by
> > > > > returning an address suitable for DMA).  If adding a grant entry for
> > > > > every frame of the framebuffer within the guest is too much, maybe
> we
> > > > > can make a new interface for the guest to grant access to larger areas.
> > > > >
> > > >
> > > > IIUC the in-guest driver is Xen-unaware so any grant entry would have
> > > > to be put in the guests table by the tools, which would entail some
> > > > form of flexibly sized reserved range of grant entries otherwise any
> > > > PV driver that are present in the guest would merrily clobber the new
> > > > grant entries.
> > > > A domain can already priv map a gfn into the MMU, so I think we just
> > > >  need an equivalent for the IOMMU.
> > >
> > > I'm not sure I'm fully understanding what's going on here, but is a
> > > variant of XENMEM_add_to_physmap+XENMAPSPACE_gmfn_foreign
> which
> > > also
> > > returns a DMA handle a plausible solution?
> > >
> >
> > I think we want be able to avoid setting up a PTE in the MMU since
> > it's not needed in most (or perhaps all?) cases.
> 
> Another (wildly under-informed) thought then:
> 
> A while back Global logic proposed (for ARM) an infrastructure for
> allowing dom0 drivers to maintain a set of iommu like pagetables under
> hypervisor supervision (they called these "remoteprocessor iommu").
> 
> I didn't fully grok what it was at the time, let alone remember the
> details properly now, but AIUI it was essentially a framework for
> allowing a simple Xen side driver to provide PV-MMU-like update
> operations for a set of PTs which were not the main-processor's PTs,
> with validation etc.
> 
> See http://thread.gmane.org/gmane.comp.emulators.xen.devel/212945
> 
> The introductory email even mentions GPUs...
> 

That series does indeed seem to be very relevant.

  Paul

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:47:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:47:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJG3-0007cG-8b; Tue, 09 Dec 2014 11:47: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 1XyJG1-0007cB-7z
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 11:47:09 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	BD/3D-27623-C31E6845; Tue, 09 Dec 2014 11:47:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418125627!9604926!1
X-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 1195 invoked from network); 9 Dec 2014 11:47:07 -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; 9 Dec 2014 11:47:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 11:47:07 +0000
Message-Id: <5486EF48020000780004E1B8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 11:47:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>,
	"Ian Campbell" <Ian.Campbell@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, netdev@vger.kernel.org
Subject: [Xen-devel] [PATCH] netback: don't store invalid vif 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

When xenvif_alloc() fails, it returns a non-NULL error indicator. To
avoid eventual races, we shouldn't store that into struct backend_info
as readers of it only check for NULL.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -404,6 +404,7 @@ static int backend_create_xenvif(struct 
 	int err;
 	long handle;
 	struct xenbus_device *dev = be->dev;
+	struct xenvif *vif;
 
 	if (be->vif != NULL)
 		return 0;
@@ -414,13 +415,13 @@ static int backend_create_xenvif(struct 
 		return (err < 0) ? err : -EINVAL;
 	}
 
-	be->vif = xenvif_alloc(&dev->dev, dev->otherend_id, handle);
-	if (IS_ERR(be->vif)) {
-		err = PTR_ERR(be->vif);
-		be->vif = NULL;
+	vif = xenvif_alloc(&dev->dev, dev->otherend_id, handle);
+	if (IS_ERR(vif)) {
+		err = PTR_ERR(vif);
 		xenbus_dev_fatal(dev, err, "creating interface");
 		return err;
 	}
+	be->vif = vif;
 
 	kobject_uevent(&dev->dev.kobj, KOBJ_ONLINE);
 	return 0;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:47:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:47:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJG3-0007cG-8b; Tue, 09 Dec 2014 11:47: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 1XyJG1-0007cB-7z
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 11:47:09 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	BD/3D-27623-C31E6845; Tue, 09 Dec 2014 11:47:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418125627!9604926!1
X-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 1195 invoked from network); 9 Dec 2014 11:47:07 -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; 9 Dec 2014 11:47:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 11:47:07 +0000
Message-Id: <5486EF48020000780004E1B8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 11:47:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>,
	"Ian Campbell" <Ian.Campbell@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>, netdev@vger.kernel.org
Subject: [Xen-devel] [PATCH] netback: don't store invalid vif 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

When xenvif_alloc() fails, it returns a non-NULL error indicator. To
avoid eventual races, we shouldn't store that into struct backend_info
as readers of it only check for NULL.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -404,6 +404,7 @@ static int backend_create_xenvif(struct 
 	int err;
 	long handle;
 	struct xenbus_device *dev = be->dev;
+	struct xenvif *vif;
 
 	if (be->vif != NULL)
 		return 0;
@@ -414,13 +415,13 @@ static int backend_create_xenvif(struct 
 		return (err < 0) ? err : -EINVAL;
 	}
 
-	be->vif = xenvif_alloc(&dev->dev, dev->otherend_id, handle);
-	if (IS_ERR(be->vif)) {
-		err = PTR_ERR(be->vif);
-		be->vif = NULL;
+	vif = xenvif_alloc(&dev->dev, dev->otherend_id, handle);
+	if (IS_ERR(vif)) {
+		err = PTR_ERR(vif);
 		xenbus_dev_fatal(dev, err, "creating interface");
 		return err;
 	}
+	be->vif = vif;
 
 	kobject_uevent(&dev->dev.kobj, KOBJ_ONLINE);
 	return 0;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:47:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:47:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJGc-0007gd-Kw; Tue, 09 Dec 2014 11:47:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XyJGb-0007gS-EG
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:47:45 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	EE/33-15461-061E6845; Tue, 09 Dec 2014 11:47:44 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418125662!14352864!1
X-Originating-IP: [66.165.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 20090 invoked from network); 9 Dec 2014 11:47:44 -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;
	9 Dec 2014 11:47:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201833616"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 06:47:41 -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 1XyJGX-0000sC-DR;
	Tue, 09 Dec 2014 11:47:41 +0000
Date: Tue, 9 Dec 2014 11:47:41 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Message-ID: <20141209114741.GD1900@perard.uk.xensource.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
	<5485F608.1080005@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5485F608.1080005@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH] libxl: Set path to console on
	domain startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 12:03:36PM -0700, Jim Fehlig wrote:
> Anthony PERARD wrote:
> > The path to the pty of a Xen PV console is set only in
> > virDomainOpenConsole. But this is done too late. A call to
> > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > the pty, but a call after OpenConsole will.
> >   
> 
> Hi Anthony,
> 
> Thanks for the patch. Can you address the comments made by others, my
> comments below, and provide a V2?

Will do.

> > e.g. of the current issue.
> > Starting a domain with '<console type="pty"/>'
> > Then:
> > virDomainGetXMLDesc():
> >   <devices>
> >     <console type='pty'>
> >       <target type='xen' port='0'/>
> >     </console>
> >   </devices>
> > virDomainOpenConsole()
> > virDomainGetXMLDesc():
> >   <devices>
> >     <console type='pty' tty='/dev/pts/30'>
> >       <source path='/dev/pts/30'/>
> >       <target type='xen' port='0'/>
> >     </console>
> >   </devices>
> >
> > The patch intend to get the tty path on the first call of GetXMLDesc.
> >
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > ---
> >  src/libxl/libxl_domain.c | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > index 9c62291..de56054 100644
> > --- a/src/libxl/libxl_domain.c
> > +++ b/src/libxl/libxl_domain.c
> > @@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> >          goto cleanup_dom;
> >  
> > +    if (vm->def->nconsoles) {
> > +        virDomainChrDefPtr chr = NULL;
> > +        chr = vm->def->consoles[0];
> > +        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
> > +            libxl_console_type console_type;
> > +            char *console = NULL;
> > +            console_type =
> > +                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
> > +                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
> > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
> > +                                        console_type, &console);
> > +            if (!ret)
> > +                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
> >   
> 
> VIR_STRDUP will not free an existing value. You should VIR_FREE first,
> which btw can handle a NULL argument. And since you're initializing
> source.data.file.path when starting the domain, I think we can drop the
> similar code in libxlDomainOpenConsole().

I will do that.
Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:47:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:47:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJGc-0007gd-Kw; Tue, 09 Dec 2014 11:47:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XyJGb-0007gS-EG
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 11:47:45 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	EE/33-15461-061E6845; Tue, 09 Dec 2014 11:47:44 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418125662!14352864!1
X-Originating-IP: [66.165.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 20090 invoked from network); 9 Dec 2014 11:47:44 -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;
	9 Dec 2014 11:47:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="201833616"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 06:47:41 -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 1XyJGX-0000sC-DR;
	Tue, 09 Dec 2014 11:47:41 +0000
Date: Tue, 9 Dec 2014 11:47:41 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Message-ID: <20141209114741.GD1900@perard.uk.xensource.com>
References: <1417797006-27963-1-git-send-email-anthony.perard@citrix.com>
	<1417797006-27963-2-git-send-email-anthony.perard@citrix.com>
	<5485F608.1080005@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5485F608.1080005@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [libvirt] [PATCH] libxl: Set path to console on
	domain startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 12:03:36PM -0700, Jim Fehlig wrote:
> Anthony PERARD wrote:
> > The path to the pty of a Xen PV console is set only in
> > virDomainOpenConsole. But this is done too late. A call to
> > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > the pty, but a call after OpenConsole will.
> >   
> 
> Hi Anthony,
> 
> Thanks for the patch. Can you address the comments made by others, my
> comments below, and provide a V2?

Will do.

> > e.g. of the current issue.
> > Starting a domain with '<console type="pty"/>'
> > Then:
> > virDomainGetXMLDesc():
> >   <devices>
> >     <console type='pty'>
> >       <target type='xen' port='0'/>
> >     </console>
> >   </devices>
> > virDomainOpenConsole()
> > virDomainGetXMLDesc():
> >   <devices>
> >     <console type='pty' tty='/dev/pts/30'>
> >       <source path='/dev/pts/30'/>
> >       <target type='xen' port='0'/>
> >     </console>
> >   </devices>
> >
> > The patch intend to get the tty path on the first call of GetXMLDesc.
> >
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > ---
> >  src/libxl/libxl_domain.c | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > index 9c62291..de56054 100644
> > --- a/src/libxl/libxl_domain.c
> > +++ b/src/libxl/libxl_domain.c
> > @@ -1290,6 +1290,23 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> >          goto cleanup_dom;
> >  
> > +    if (vm->def->nconsoles) {
> > +        virDomainChrDefPtr chr = NULL;
> > +        chr = vm->def->consoles[0];
> > +        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
> > +            libxl_console_type console_type;
> > +            char *console = NULL;
> > +            console_type =
> > +                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
> > +                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
> > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
> > +                                        console_type, &console);
> > +            if (!ret)
> > +                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
> >   
> 
> VIR_STRDUP will not free an existing value. You should VIR_FREE first,
> which btw can handle a NULL argument. And since you're initializing
> source.data.file.path when starting the domain, I think we can drop the
> similar code in libxlDomainOpenConsole().

I will do that.
Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 11:51:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJKG-0007u8-9l; Tue, 09 Dec 2014 11:51:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1XyJKE-0007u3-S1
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 11:51:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B7/5A-15461-242E6845; Tue, 09 Dec 2014 11:51:30 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418125888!14408439!1
X-Originating-IP: [209.85.216.50]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26841 invoked from network); 9 Dec 2014 11:51:29 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 11:51:29 -0000
Received: by mail-qa0-f50.google.com with SMTP id w8so227196qac.37
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 03:51:28 -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=nPXicgu1gYgABDea8uoxJYXEGcEWG2keKIXflILn8Q0=;
	b=gbBljUijWS2OtwAUOHgyIrr0NKPhZENVy/vO/9/kSMp5ynvy9lhLRaNIMsliCQml4Y
	Bnp71F2nfPR9YxZhg34cUNzFn2HjE27L5jiUh+X2s4fHWITnWAd7pEtvSle7jDDt1jhR
	mPahQf5BBmIy/UzidBjSvTMRV7RTGy7weX8FSuf8JazE+KsONdJs99adEVlR0Z+jdzhG
	uQcAfAusaRbneyTVvi/xjEzAE7pFDOkeHe/4ZSRB156AOkNUvU8qz0elhSsbxy82caUq
	hpjOLWJk3QGe9Ei+9fiRQUziQ1oGDfuHQKPQgCj+LI0EbbZ13HV20m7JJpjhmlPob+6J
	CVBw==
MIME-Version: 1.0
X-Received: by 10.140.30.163 with SMTP id d32mr4135169qgd.105.1418125887972;
	Tue, 09 Dec 2014 03:51:27 -0800 (PST)
Received: by 10.140.84.137 with HTTP; Tue, 9 Dec 2014 03:51:27 -0800 (PST)
Date: Tue, 9 Dec 2014 11:51:27 +0000
Message-ID: <CAOqnZH5=Jk+e0M_MdZFYhu4ecric6biy3wgtyb9c63wbYvDAAg@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: xen-devel <xen-devel@lists.xenproject.org>, 
	Sarah Conway <sconway@linuxfoundation.org>
Subject: [Xen-devel] Konrad R Wilk's Xen Project Committer Status confirmed
 (+ some governance policy concerns)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3735269891236837977=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3735269891236837977==
Content-Type: multipart/alternative; boundary=001a113a964cccb0220509c72978

--001a113a964cccb0220509c72978
Content-Type: text/plain; charset=UTF-8

Hi all,

I wanted to to summarize the outcome of the vote for Konrad's committer
status. We had 4 votes in favor and one abstained. Which means Konrad is
confirmed.

A number of concerns were raised, e.g. shouldn't other maintainers (e.g.
George Dunlap as past release manager, or Stefano Stabellini) also be
nominated as a committer. This could be relatively easily fixed, but
requires one of the other committers to make a nomination.

Concerns about the definition of the committer role were raised. In
summary, the governance policy today defines the committer role purely in
terms of a maintainer with write access. However the role is actually also
about being entrusted with the safety, governance and the stewardship of
the project. This is implied in the governance document, but not spelled
out.

Tim Deegan, described the issue quite well:

"It's clear from the governance document that the committers are expected
to resolve disagreements that the maintainers and contributors can't sort
out between themselves.

So maybe we should have a discussion about separating the roles of
committer-with-tree-access and committer-for-governance?  For me, the set
of people who should be settling disputes is a subset of the set of people
I would trust with push access to xen.git. IOW I'm a little wary of
creating a group of people who make technical decisions but aren't
themselves technical."

This concern does not apply to Konrad, who has excellent standing in the
community and has been actively involved in design, development and review
inside the hypervisor.

We don't need to resolve this issue before the 4.5 release. I think we
should roll this up with a general review of our governance in spring. When
I wrote up the contributor training document (see
http://www.slideshare.net/xen_com_mgr/xen-project-contributor-training-part-2-processes-and-conventions-v10),
it became clear that there are a number of conventions that are not well
documented. These don't necessarily need to be part of the governance, but
the governance document should probably link to some of our conventions.

Best Regards
Lars

--001a113a964cccb0220509c72978
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>I wanted to to summarize the ou=
tcome of the vote for Konrad&#39;s committer status. We had 4 votes in favo=
r and one abstained. Which means Konrad is confirmed.</div><div><br></div><=
div>A number of concerns were raised, e.g. shouldn&#39;t other maintainers =
(e.g. George Dunlap as past release manager, or Stefano Stabellini) also be=
 nominated as a committer. This could be relatively easily fixed, but requi=
res one of the other committers to make a nomination.=C2=A0</div><div><br><=
/div><div>Concerns about the definition of the committer role were raised. =
In summary, the governance policy today defines the committer role purely i=
n terms of a maintainer with write access. However the role is actually als=
o about being entrusted with the safety, governance and the stewardship of =
the project. This is implied in the governance document, but not spelled ou=
t.</div><div><br></div><div>Tim Deegan, described the issue quite well:</di=
v><div><br></div><div>&quot;It&#39;s clear from the governance document tha=
t the committers are expected to resolve disagreements that the maintainers=
 and contributors can&#39;t sort out between themselves. =C2=A0</div><div><=
br></div><div>So maybe we should have a discussion about separating the rol=
es of committer-with-tree-access and committer-for-governance?=C2=A0 For me=
, the set of people who should be settling disputes is a subset of the set =
of people I would trust with push access to xen.git. IOW I&#39;m a little w=
ary of creating a group of people who make technical decisions but aren&#39=
;t themselves technical.&quot;</div><div><br></div><div>This concern does n=
ot apply to Konrad, who has excellent standing in the community and has bee=
n actively involved in design, development and review inside the hypervisor=
.</div><div><br></div><div>We don&#39;t need to resolve this issue before t=
he 4.5 release. I think we should roll this up with a general review of our=
 governance in spring. When I wrote up the contributor training document (s=
ee <a href=3D"http://www.slideshare.net/xen_com_mgr/xen-project-contributor=
-training-part-2-processes-and-conventions-v10">http://www.slideshare.net/x=
en_com_mgr/xen-project-contributor-training-part-2-processes-and-convention=
s-v10</a>), it became clear that there are a number of conventions that are=
 not well documented. These don&#39;t necessarily need to be part of the go=
vernance, but the governance document should probably link to some of our c=
onventions.</div><div><br></div><div>Best Regards</div><div>Lars</div></div=
>

--001a113a964cccb0220509c72978--


--===============3735269891236837977==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3735269891236837977==--


From xen-devel-bounces@lists.xen.org Tue Dec 09 11:51:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 11:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJKG-0007u8-9l; Tue, 09 Dec 2014 11:51:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1XyJKE-0007u3-S1
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 11:51:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B7/5A-15461-242E6845; Tue, 09 Dec 2014 11:51:30 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418125888!14408439!1
X-Originating-IP: [209.85.216.50]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26841 invoked from network); 9 Dec 2014 11:51:29 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 11:51:29 -0000
Received: by mail-qa0-f50.google.com with SMTP id w8so227196qac.37
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 03:51:28 -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=nPXicgu1gYgABDea8uoxJYXEGcEWG2keKIXflILn8Q0=;
	b=gbBljUijWS2OtwAUOHgyIrr0NKPhZENVy/vO/9/kSMp5ynvy9lhLRaNIMsliCQml4Y
	Bnp71F2nfPR9YxZhg34cUNzFn2HjE27L5jiUh+X2s4fHWITnWAd7pEtvSle7jDDt1jhR
	mPahQf5BBmIy/UzidBjSvTMRV7RTGy7weX8FSuf8JazE+KsONdJs99adEVlR0Z+jdzhG
	uQcAfAusaRbneyTVvi/xjEzAE7pFDOkeHe/4ZSRB156AOkNUvU8qz0elhSsbxy82caUq
	hpjOLWJk3QGe9Ei+9fiRQUziQ1oGDfuHQKPQgCj+LI0EbbZ13HV20m7JJpjhmlPob+6J
	CVBw==
MIME-Version: 1.0
X-Received: by 10.140.30.163 with SMTP id d32mr4135169qgd.105.1418125887972;
	Tue, 09 Dec 2014 03:51:27 -0800 (PST)
Received: by 10.140.84.137 with HTTP; Tue, 9 Dec 2014 03:51:27 -0800 (PST)
Date: Tue, 9 Dec 2014 11:51:27 +0000
Message-ID: <CAOqnZH5=Jk+e0M_MdZFYhu4ecric6biy3wgtyb9c63wbYvDAAg@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: xen-devel <xen-devel@lists.xenproject.org>, 
	Sarah Conway <sconway@linuxfoundation.org>
Subject: [Xen-devel] Konrad R Wilk's Xen Project Committer Status confirmed
 (+ some governance policy concerns)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3735269891236837977=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3735269891236837977==
Content-Type: multipart/alternative; boundary=001a113a964cccb0220509c72978

--001a113a964cccb0220509c72978
Content-Type: text/plain; charset=UTF-8

Hi all,

I wanted to to summarize the outcome of the vote for Konrad's committer
status. We had 4 votes in favor and one abstained. Which means Konrad is
confirmed.

A number of concerns were raised, e.g. shouldn't other maintainers (e.g.
George Dunlap as past release manager, or Stefano Stabellini) also be
nominated as a committer. This could be relatively easily fixed, but
requires one of the other committers to make a nomination.

Concerns about the definition of the committer role were raised. In
summary, the governance policy today defines the committer role purely in
terms of a maintainer with write access. However the role is actually also
about being entrusted with the safety, governance and the stewardship of
the project. This is implied in the governance document, but not spelled
out.

Tim Deegan, described the issue quite well:

"It's clear from the governance document that the committers are expected
to resolve disagreements that the maintainers and contributors can't sort
out between themselves.

So maybe we should have a discussion about separating the roles of
committer-with-tree-access and committer-for-governance?  For me, the set
of people who should be settling disputes is a subset of the set of people
I would trust with push access to xen.git. IOW I'm a little wary of
creating a group of people who make technical decisions but aren't
themselves technical."

This concern does not apply to Konrad, who has excellent standing in the
community and has been actively involved in design, development and review
inside the hypervisor.

We don't need to resolve this issue before the 4.5 release. I think we
should roll this up with a general review of our governance in spring. When
I wrote up the contributor training document (see
http://www.slideshare.net/xen_com_mgr/xen-project-contributor-training-part-2-processes-and-conventions-v10),
it became clear that there are a number of conventions that are not well
documented. These don't necessarily need to be part of the governance, but
the governance document should probably link to some of our conventions.

Best Regards
Lars

--001a113a964cccb0220509c72978
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>I wanted to to summarize the ou=
tcome of the vote for Konrad&#39;s committer status. We had 4 votes in favo=
r and one abstained. Which means Konrad is confirmed.</div><div><br></div><=
div>A number of concerns were raised, e.g. shouldn&#39;t other maintainers =
(e.g. George Dunlap as past release manager, or Stefano Stabellini) also be=
 nominated as a committer. This could be relatively easily fixed, but requi=
res one of the other committers to make a nomination.=C2=A0</div><div><br><=
/div><div>Concerns about the definition of the committer role were raised. =
In summary, the governance policy today defines the committer role purely i=
n terms of a maintainer with write access. However the role is actually als=
o about being entrusted with the safety, governance and the stewardship of =
the project. This is implied in the governance document, but not spelled ou=
t.</div><div><br></div><div>Tim Deegan, described the issue quite well:</di=
v><div><br></div><div>&quot;It&#39;s clear from the governance document tha=
t the committers are expected to resolve disagreements that the maintainers=
 and contributors can&#39;t sort out between themselves. =C2=A0</div><div><=
br></div><div>So maybe we should have a discussion about separating the rol=
es of committer-with-tree-access and committer-for-governance?=C2=A0 For me=
, the set of people who should be settling disputes is a subset of the set =
of people I would trust with push access to xen.git. IOW I&#39;m a little w=
ary of creating a group of people who make technical decisions but aren&#39=
;t themselves technical.&quot;</div><div><br></div><div>This concern does n=
ot apply to Konrad, who has excellent standing in the community and has bee=
n actively involved in design, development and review inside the hypervisor=
.</div><div><br></div><div>We don&#39;t need to resolve this issue before t=
he 4.5 release. I think we should roll this up with a general review of our=
 governance in spring. When I wrote up the contributor training document (s=
ee <a href=3D"http://www.slideshare.net/xen_com_mgr/xen-project-contributor=
-training-part-2-processes-and-conventions-v10">http://www.slideshare.net/x=
en_com_mgr/xen-project-contributor-training-part-2-processes-and-convention=
s-v10</a>), it became clear that there are a number of conventions that are=
 not well documented. These don&#39;t necessarily need to be part of the go=
vernance, but the governance document should probably link to some of our c=
onventions.</div><div><br></div><div>Best Regards</div><div>Lars</div></div=
>

--001a113a964cccb0220509c72978--


--===============3735269891236837977==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3735269891236837977==--


From xen-devel-bounces@lists.xen.org Tue Dec 09 12:07:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 12:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJZM-000086-JA; Tue, 09 Dec 2014 12:07:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XyJZL-00007y-Mi
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 12:07:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	72/89-15461-BE5E6845; Tue, 09 Dec 2014 12:07:07 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418126826!14416635!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10313 invoked from network); 9 Dec 2014 12:07:06 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 12:07:06 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418126826; l=1211;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=wrugNBmWVQZBmDjylL4a1AkaY5Q=;
	b=VfAFfA4SuLFHz7YBIVRUtcgj/epXHqHnrWMTyZF2xaVaY8U3CG1Vq9hSh1ebQDXCcOF
	Y7v6g9LUmKrbi+hb6iV1HCxw4zBiWZvhBKgcd4ct5+OLHvNdV9hRm9lI1h5c6CgLZoVRq
	NBhFhp7boGbq2gKYdQH+TdZwXZE/gApJokk=
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.3 AUTH) with ESMTPSA id x04cfcqB9C730I4
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 9 Dec 2014 13:07:03 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id E565D5015F; Tue,  9 Dec 2014 13:07:02 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Tue,  9 Dec 2014 13:06:55 +0100
Message-Id: <1418126815-5708-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH] tools/hotplug: xendomains.service depends on
	network
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Starting domains during boot will most likely require network for the
local bridge and it may need access to remote filesystems. Add ordering
tags to systemd service file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---

This should go into 4.5 to avoid failures if xendomains is scheduled before
remote mounts are fully available.

 tools/hotplug/Linux/systemd/xendomains.service.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
index 9962671..66e2065 100644
--- a/tools/hotplug/Linux/systemd/xendomains.service.in
+++ b/tools/hotplug/Linux/systemd/xendomains.service.in
@@ -2,6 +2,8 @@
 Description=Xendomains - start and stop guests on boot and shutdown
 Requires=proc-xen.mount xenstored.service
 After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
+After=network-online.target
+After=remote-fs.target
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 12:07:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 12:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJZM-000086-JA; Tue, 09 Dec 2014 12:07:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XyJZL-00007y-Mi
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 12:07:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	72/89-15461-BE5E6845; Tue, 09 Dec 2014 12:07:07 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418126826!14416635!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10313 invoked from network); 9 Dec 2014 12:07:06 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 12:07:06 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418126826; l=1211;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=wrugNBmWVQZBmDjylL4a1AkaY5Q=;
	b=VfAFfA4SuLFHz7YBIVRUtcgj/epXHqHnrWMTyZF2xaVaY8U3CG1Vq9hSh1ebQDXCcOF
	Y7v6g9LUmKrbi+hb6iV1HCxw4zBiWZvhBKgcd4ct5+OLHvNdV9hRm9lI1h5c6CgLZoVRq
	NBhFhp7boGbq2gKYdQH+TdZwXZE/gApJokk=
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.3 AUTH) with ESMTPSA id x04cfcqB9C730I4
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 9 Dec 2014 13:07:03 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id E565D5015F; Tue,  9 Dec 2014 13:07:02 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Tue,  9 Dec 2014 13:06:55 +0100
Message-Id: <1418126815-5708-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
Cc: Olaf Hering <olaf@aepfle.de>, 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>
Subject: [Xen-devel] [PATCH] tools/hotplug: xendomains.service depends on
	network
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Starting domains during boot will most likely require network for the
local bridge and it may need access to remote filesystems. Add ordering
tags to systemd service file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---

This should go into 4.5 to avoid failures if xendomains is scheduled before
remote mounts are fully available.

 tools/hotplug/Linux/systemd/xendomains.service.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
index 9962671..66e2065 100644
--- a/tools/hotplug/Linux/systemd/xendomains.service.in
+++ b/tools/hotplug/Linux/systemd/xendomains.service.in
@@ -2,6 +2,8 @@
 Description=Xendomains - start and stop guests on boot and shutdown
 Requires=proc-xen.mount xenstored.service
 After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
+After=network-online.target
+After=remote-fs.target
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 12:08:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 12:08:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJao-0000ED-2E; Tue, 09 Dec 2014 12:08:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyJam-0000E3-Fw
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 12:08:36 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	58/09-27623-346E6845; Tue, 09 Dec 2014 12:08:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418126909!12021386!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 7298 invoked from network); 9 Dec 2014 12:08:30 -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 Dec 2014 12:08:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="202240874"
Message-ID: <1418126905.14361.30.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 9 Dec 2014 12:08:25 +0000
In-Reply-To: <5486EF48020000780004E1B8@mail.emea.novell.com>
References: <5486EF48020000780004E1B8@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	netdev@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] netback: don't store invalid vif 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, 2014-12-09 at 11:47 +0000, Jan Beulich wrote:
> When xenvif_alloc() fails, it returns a non-NULL error indicator. To
> avoid eventual races, we shouldn't store that into struct backend_info
> as readers of it only check for NULL.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Ian Campbell <ian.campbell@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 Tue Dec 09 12:08:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 12:08:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyJao-0000ED-2E; Tue, 09 Dec 2014 12:08:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyJam-0000E3-Fw
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 12:08:36 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	58/09-27623-346E6845; Tue, 09 Dec 2014 12:08:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418126909!12021386!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 7298 invoked from network); 9 Dec 2014 12:08:30 -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 Dec 2014 12:08:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="202240874"
Message-ID: <1418126905.14361.30.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 9 Dec 2014 12:08:25 +0000
In-Reply-To: <5486EF48020000780004E1B8@mail.emea.novell.com>
References: <5486EF48020000780004E1B8@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>,
	netdev@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] netback: don't store invalid vif 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, 2014-12-09 at 11:47 +0000, Jan Beulich wrote:
> When xenvif_alloc() fails, it returns a non-NULL error indicator. To
> avoid eventual races, we shouldn't store that into struct backend_info
> as readers of it only check for NULL.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Ian Campbell <ian.campbell@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 Tue Dec 09 12:35:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 12:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyK0E-0001TG-CZ; Tue, 09 Dec 2014 12:34:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1XyK0C-0001TB-Kp
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 12:34:52 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	68/3C-27584-B6CE6845; Tue, 09 Dec 2014 12:34:51 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418128490!12333565!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12114 invoked from network); 9 Dec 2014 12:34:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 12:34:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="27665017"
From: Thanos Makatos <thanos.makatos@citrix.com>
To: 'Boris Ostrovsky' <boris.ostrovsky@oracle.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Thread-Topic: [Xen-devel] [PATCH v2] introduce grant copy for user land
Thread-Index: AQHQDkrqA4IZn9sKnUusrl0ipWJWwJyBPsuAgAX7cHA=
Date: Tue, 9 Dec 2014 12:34:49 +0000
Message-ID: <2368A3FCF9F7214298E53C823B0A48EC042D0C1B@AMSPEX01CL02.citrite.net>
References: <1417536806-22562-1-git-send-email-thanos.makatos@citrix.com>
	<5481F3F1.2010701@oracle.com>
In-Reply-To: <5481F3F1.2010701@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: David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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

> -----Original Message-----
> From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]
> Sent: 05 December 2014 6:06 PM
> To: Thanos Makatos; xen-devel@lists.xenproject.org
> Cc: David Vrabel
> Subject: Re: [Xen-devel] [PATCH v2] introduce grant copy for user land
> 
> On 12/02/2014 11:13 AM, 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.
> >
> > Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>
> > ---
> >   drivers/xen/gntdev.c      |  171
> +++++++++++++++++++++++++++++++++++++++++++++
> >   include/uapi/xen/gntdev.h |   69 ++++++++++++++++++
> >   2 files changed, 240 insertions(+)
> >
> > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> > index 51f4c95..7b4a8e0 100644
> > --- a/drivers/xen/gntdev.c
> > +++ b/drivers/xen/gntdev.c
> > @@ -705,6 +705,174 @@ static long gntdev_ioctl_notify(struct gntdev_priv
> *priv, void __user *u)
> >   	return rc;
> >   }
> >
> > +static int gntdev_gcopy_batch(int nr_segments, unsigned long gcopy_cb,
> > +		struct gntdev_grant_copy_segment __user *__segments,
> int dir,
> > +		int src, int dst) {
> > +
> > +	static const int batch_size = PAGE_SIZE / (sizeof(struct page*) +
> > +		sizeof(struct gnttab_copy) + sizeof(struct
> gntdev_grant_copy_segment));
> > +	struct page **pages = (struct page **)gcopy_cb;
> > +	struct gnttab_copy *batch = (struct gnttab_copy *)((unsigned
> long)pages +
> > +			sizeof(struct page*) * batch_size);
> > +	struct gntdev_grant_copy_segment *segments =
> > +		(struct gntdev_grant_copy_segment *)((unsigned
> long)batch +
> > +				sizeof(struct gnttab_copy) * batch_size);
> > +	unsigned int nr_pinned = 0, nr_segs2cp = 0;
> > +	int err = 0, i;
> > +	const int write = dir == GNTCOPY_IOCTL_g2s;
> > +
> > +	nr_segments = min(nr_segments, batch_size);
> > +
> > +	if (unlikely(copy_from_user(segments, __segments,
> > +			   sizeof(struct gntdev_grant_copy_segment) *
> nr_segments))) {
> > +		pr_debug("failed to copy %d segments from user",
> nr_segments);
> > +		err = -EFAULT;
> > +		goto out;
> > +	}
> > +
> > +	for (i = 0; i < nr_segments; i++) {
> > +
> > +		xen_pfn_t pgaddr;
> > +		unsigned long start, offset;
> > +		struct gntdev_grant_copy_segment *seg = &segments[i];
> > +
> > +		if (dir == GNTCOPY_IOCTL_s2g || dir ==
> GNTCOPY_IOCTL_g2s) {
> > +
> > +			start = (unsigned long)seg->self.iov.iov_base &
> PAGE_MASK;
> > +			offset = (unsigned long)seg->self.iov.iov_base &
> ~PAGE_MASK;
> > +			if (unlikely(offset + seg->self.iov.iov_len >
> PAGE_SIZE)) {
> > +				pr_warn("segments crossing page
> boundaries not yet "
> > +						"implemented\n");
> > +				err = -ENOSYS;
> > +				goto out;
> > +			}
> > +
> > +			err = get_user_pages_fast(start, 1, write, &pages[i]);
> > +			if (unlikely(err != 1)) {
> > +				pr_debug("failed to get user page %lu",
> start);
> > +				err = -EFAULT;
> > +				goto out;
> > +			}
> > +
> > +			nr_pinned++;
> > +
> > +			pgaddr = pfn_to_mfn(page_to_pfn(pages[i]));
> > +		}
> > +
> > +		nr_segs2cp++;
> > +
> > +		switch (dir) {
> > +		case GNTCOPY_IOCTL_g2s: /* copy from guest */
> > +			batch[i].len = seg->self.iov.iov_len;
> > +			batch[i].source.u.ref = seg->self.ref;
> > +			batch[i].source.domid = src;
> > +			batch[i].source.offset = seg->self.offset;
> > +			batch[i].dest.u.gmfn = pgaddr;
> > +			batch[i].dest.domid = DOMID_SELF;
> > +			batch[i].dest.offset = offset;
> > +			batch[i].flags = GNTCOPY_source_gref;
> > +			break;
> > +		case GNTCOPY_IOCTL_s2g: /* copy to guest */
> > +			batch[i].len = seg->self.iov.iov_len;
> > +			batch[i].source.u.gmfn = pgaddr;
> > +			batch[i].source.domid = DOMID_SELF;
> > +			batch[i].source.offset = offset;
> > +			batch[i].dest.u.ref = seg->self.ref;
> > +			batch[i].dest.domid = dst;
> > +			batch[i].dest.offset = seg->self.offset;
> > +			batch[i].flags = GNTCOPY_dest_gref;
> > +			break;
> > +		case GNTCOPY_IOCTL_g2g: /* copy guest to guest */
> > +			batch[i].len = seg->g2g.len;
> > +			batch[i].source.u.ref = seg->g2g.src.ref;
> > +			batch[i].source.domid = src;
> > +			batch[i].source.offset = seg->g2g.src.offset;
> > +			batch[i].dest.u.ref = seg->g2g.dst.ref;
> > +			batch[i].dest.domid = dst;
> > +			batch[i].dest.offset = seg->g2g.dst.offset;
> > +			batch[i].flags = GNTCOPY_source_gref |
> GNTCOPY_dest_gref;
> > +			break;
> > +		default:
> > +			pr_debug("invalid grant-copy direction %d\n", dir);
> > +			err = -EINVAL;
> > +			goto out;
> > +		}
> > +	}
> > +
> > +	gnttab_batch_copy(batch, nr_segs2cp);
> > +	for (i = 0; i < nr_segs2cp; i++) {
> 
> Can nr_segs2cp be not equal to nr_segments here? If you got to this
> point you have gone through the full loop.

Correct.

> > +		err = put_user(batch[i].status, &__segments[i].status);
> > +		if (unlikely(err)) {
> > +			pr_debug("failed to copy error code %d to
> user: %d\n",
> > +					batch[i].status, err);
> > +			goto out;
> > +		}
> > +	}
> > +
> > +out:
> > +	for (i = 0; i < nr_pinned; i++)
> > +		put_page(pages[i]);
> > +
> > +	if (unlikely(err))
> > +		return err;
> > +
> > +	return nr_segs2cp;
> 
> And I think here it can be either 0 (which is the case of an error) or
> nr_segments. If you error out of the 'for' loop you haven't actually
> copied anything, even though nr_segs2cp might be non-zero.

If an error has occurred, "err" will be returned so the value of either "nr_segs2cp" or "nr_segments" is irrelevant. If no error occurs, then we have copied "nr_segments", therefore this is what we should return. I think I got something wrong and I thought there was some corner case so that why we needed an extra variable, but it doesn't seem to be the case. I'll replace "nr_segments" with "nr_segments".

> -boris
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 12:35:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 12:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyK0Q-0001TZ-Rt; Tue, 09 Dec 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 <Ian.Campbell@citrix.com>) id 1XyK0P-0001TR-Os
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 12:35:05 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	33/55-24124-97CE6845; Tue, 09 Dec 2014 12:35:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418128502!12331550!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5881 invoked from network); 9 Dec 2014 12:35:04 -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;
	9 Dec 2014 12:35:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="202248653"
Message-ID: <1418128477.14361.38.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 9 Dec 2014 12:34:37 +0000
In-Reply-To: <1417533160.24320.54.camel@citrix.com>
References: <201411271512.sARFC11l001276@userz7022.oracle.com>
	<CAFLBxZZKBf70oH7yUC9JDU7U3Ca5SAt6vWcNfnMy566KEPQS4w@mail.gmail.com>
	<1417533160.24320.54.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Tim Deegan <tim@xen.org>,
	"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 Tue, 2014-12-02 at 15:12 +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 15:10 +0000, George Dunlap wrote:
> > On Thu, Nov 27, 2014 at 3:11 PM, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> > >
> > > On Nov 27, 2014 6:59 AM, Tim Deegan <tim@xen.org> wrote:
> > >>
> > >> 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
> > >
> > > +1 too.
> 
> > OK, that's +4 and no minuses after 5 days.  How long to I have to wait?  :-)
> 
> http://www.xenproject.org/help/contribution-guidelines.html says seven
> days...

The time for voting has now passed. There were several +1s and no
objections and so George has been granted access to the Coverity
repository.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 12:35:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 12:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyK0E-0001TG-CZ; Tue, 09 Dec 2014 12:34:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1XyK0C-0001TB-Kp
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 12:34:52 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	68/3C-27584-B6CE6845; Tue, 09 Dec 2014 12:34:51 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418128490!12333565!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12114 invoked from network); 9 Dec 2014 12:34:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 12:34:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="27665017"
From: Thanos Makatos <thanos.makatos@citrix.com>
To: 'Boris Ostrovsky' <boris.ostrovsky@oracle.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Thread-Topic: [Xen-devel] [PATCH v2] introduce grant copy for user land
Thread-Index: AQHQDkrqA4IZn9sKnUusrl0ipWJWwJyBPsuAgAX7cHA=
Date: Tue, 9 Dec 2014 12:34:49 +0000
Message-ID: <2368A3FCF9F7214298E53C823B0A48EC042D0C1B@AMSPEX01CL02.citrite.net>
References: <1417536806-22562-1-git-send-email-thanos.makatos@citrix.com>
	<5481F3F1.2010701@oracle.com>
In-Reply-To: <5481F3F1.2010701@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: David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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

> -----Original Message-----
> From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]
> Sent: 05 December 2014 6:06 PM
> To: Thanos Makatos; xen-devel@lists.xenproject.org
> Cc: David Vrabel
> Subject: Re: [Xen-devel] [PATCH v2] introduce grant copy for user land
> 
> On 12/02/2014 11:13 AM, 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.
> >
> > Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>
> > ---
> >   drivers/xen/gntdev.c      |  171
> +++++++++++++++++++++++++++++++++++++++++++++
> >   include/uapi/xen/gntdev.h |   69 ++++++++++++++++++
> >   2 files changed, 240 insertions(+)
> >
> > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> > index 51f4c95..7b4a8e0 100644
> > --- a/drivers/xen/gntdev.c
> > +++ b/drivers/xen/gntdev.c
> > @@ -705,6 +705,174 @@ static long gntdev_ioctl_notify(struct gntdev_priv
> *priv, void __user *u)
> >   	return rc;
> >   }
> >
> > +static int gntdev_gcopy_batch(int nr_segments, unsigned long gcopy_cb,
> > +		struct gntdev_grant_copy_segment __user *__segments,
> int dir,
> > +		int src, int dst) {
> > +
> > +	static const int batch_size = PAGE_SIZE / (sizeof(struct page*) +
> > +		sizeof(struct gnttab_copy) + sizeof(struct
> gntdev_grant_copy_segment));
> > +	struct page **pages = (struct page **)gcopy_cb;
> > +	struct gnttab_copy *batch = (struct gnttab_copy *)((unsigned
> long)pages +
> > +			sizeof(struct page*) * batch_size);
> > +	struct gntdev_grant_copy_segment *segments =
> > +		(struct gntdev_grant_copy_segment *)((unsigned
> long)batch +
> > +				sizeof(struct gnttab_copy) * batch_size);
> > +	unsigned int nr_pinned = 0, nr_segs2cp = 0;
> > +	int err = 0, i;
> > +	const int write = dir == GNTCOPY_IOCTL_g2s;
> > +
> > +	nr_segments = min(nr_segments, batch_size);
> > +
> > +	if (unlikely(copy_from_user(segments, __segments,
> > +			   sizeof(struct gntdev_grant_copy_segment) *
> nr_segments))) {
> > +		pr_debug("failed to copy %d segments from user",
> nr_segments);
> > +		err = -EFAULT;
> > +		goto out;
> > +	}
> > +
> > +	for (i = 0; i < nr_segments; i++) {
> > +
> > +		xen_pfn_t pgaddr;
> > +		unsigned long start, offset;
> > +		struct gntdev_grant_copy_segment *seg = &segments[i];
> > +
> > +		if (dir == GNTCOPY_IOCTL_s2g || dir ==
> GNTCOPY_IOCTL_g2s) {
> > +
> > +			start = (unsigned long)seg->self.iov.iov_base &
> PAGE_MASK;
> > +			offset = (unsigned long)seg->self.iov.iov_base &
> ~PAGE_MASK;
> > +			if (unlikely(offset + seg->self.iov.iov_len >
> PAGE_SIZE)) {
> > +				pr_warn("segments crossing page
> boundaries not yet "
> > +						"implemented\n");
> > +				err = -ENOSYS;
> > +				goto out;
> > +			}
> > +
> > +			err = get_user_pages_fast(start, 1, write, &pages[i]);
> > +			if (unlikely(err != 1)) {
> > +				pr_debug("failed to get user page %lu",
> start);
> > +				err = -EFAULT;
> > +				goto out;
> > +			}
> > +
> > +			nr_pinned++;
> > +
> > +			pgaddr = pfn_to_mfn(page_to_pfn(pages[i]));
> > +		}
> > +
> > +		nr_segs2cp++;
> > +
> > +		switch (dir) {
> > +		case GNTCOPY_IOCTL_g2s: /* copy from guest */
> > +			batch[i].len = seg->self.iov.iov_len;
> > +			batch[i].source.u.ref = seg->self.ref;
> > +			batch[i].source.domid = src;
> > +			batch[i].source.offset = seg->self.offset;
> > +			batch[i].dest.u.gmfn = pgaddr;
> > +			batch[i].dest.domid = DOMID_SELF;
> > +			batch[i].dest.offset = offset;
> > +			batch[i].flags = GNTCOPY_source_gref;
> > +			break;
> > +		case GNTCOPY_IOCTL_s2g: /* copy to guest */
> > +			batch[i].len = seg->self.iov.iov_len;
> > +			batch[i].source.u.gmfn = pgaddr;
> > +			batch[i].source.domid = DOMID_SELF;
> > +			batch[i].source.offset = offset;
> > +			batch[i].dest.u.ref = seg->self.ref;
> > +			batch[i].dest.domid = dst;
> > +			batch[i].dest.offset = seg->self.offset;
> > +			batch[i].flags = GNTCOPY_dest_gref;
> > +			break;
> > +		case GNTCOPY_IOCTL_g2g: /* copy guest to guest */
> > +			batch[i].len = seg->g2g.len;
> > +			batch[i].source.u.ref = seg->g2g.src.ref;
> > +			batch[i].source.domid = src;
> > +			batch[i].source.offset = seg->g2g.src.offset;
> > +			batch[i].dest.u.ref = seg->g2g.dst.ref;
> > +			batch[i].dest.domid = dst;
> > +			batch[i].dest.offset = seg->g2g.dst.offset;
> > +			batch[i].flags = GNTCOPY_source_gref |
> GNTCOPY_dest_gref;
> > +			break;
> > +		default:
> > +			pr_debug("invalid grant-copy direction %d\n", dir);
> > +			err = -EINVAL;
> > +			goto out;
> > +		}
> > +	}
> > +
> > +	gnttab_batch_copy(batch, nr_segs2cp);
> > +	for (i = 0; i < nr_segs2cp; i++) {
> 
> Can nr_segs2cp be not equal to nr_segments here? If you got to this
> point you have gone through the full loop.

Correct.

> > +		err = put_user(batch[i].status, &__segments[i].status);
> > +		if (unlikely(err)) {
> > +			pr_debug("failed to copy error code %d to
> user: %d\n",
> > +					batch[i].status, err);
> > +			goto out;
> > +		}
> > +	}
> > +
> > +out:
> > +	for (i = 0; i < nr_pinned; i++)
> > +		put_page(pages[i]);
> > +
> > +	if (unlikely(err))
> > +		return err;
> > +
> > +	return nr_segs2cp;
> 
> And I think here it can be either 0 (which is the case of an error) or
> nr_segments. If you error out of the 'for' loop you haven't actually
> copied anything, even though nr_segs2cp might be non-zero.

If an error has occurred, "err" will be returned so the value of either "nr_segs2cp" or "nr_segments" is irrelevant. If no error occurs, then we have copied "nr_segments", therefore this is what we should return. I think I got something wrong and I thought there was some corner case so that why we needed an extra variable, but it doesn't seem to be the case. I'll replace "nr_segments" with "nr_segments".

> -boris
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 12:35:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 12:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyK0Q-0001TZ-Rt; Tue, 09 Dec 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 <Ian.Campbell@citrix.com>) id 1XyK0P-0001TR-Os
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 12:35:05 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	33/55-24124-97CE6845; Tue, 09 Dec 2014 12:35:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418128502!12331550!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5881 invoked from network); 9 Dec 2014 12:35:04 -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;
	9 Dec 2014 12:35:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,544,1413244800"; d="scan'208";a="202248653"
Message-ID: <1418128477.14361.38.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 9 Dec 2014 12:34:37 +0000
In-Reply-To: <1417533160.24320.54.camel@citrix.com>
References: <201411271512.sARFC11l001276@userz7022.oracle.com>
	<CAFLBxZZKBf70oH7yUC9JDU7U3Ca5SAt6vWcNfnMy566KEPQS4w@mail.gmail.com>
	<1417533160.24320.54.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Tim Deegan <tim@xen.org>,
	"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 Tue, 2014-12-02 at 15:12 +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 15:10 +0000, George Dunlap wrote:
> > On Thu, Nov 27, 2014 at 3:11 PM, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> > >
> > > On Nov 27, 2014 6:59 AM, Tim Deegan <tim@xen.org> wrote:
> > >>
> > >> 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
> > >
> > > +1 too.
> 
> > OK, that's +4 and no minuses after 5 days.  How long to I have to wait?  :-)
> 
> http://www.xenproject.org/help/contribution-guidelines.html says seven
> days...

The time for voting has now passed. There were several +1s and no
objections and so George has been granted access to the Coverity
repository.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:09:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14: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 1XyLT6-0004Ny-4m; Tue, 09 Dec 2014 14:08:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XyLT4-0004Nt-TP
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:08:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D5/A8-25276-D6207845; Tue, 09 Dec 2014 14:08:45 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418134124!14433601!1
X-Originating-IP: [66.165.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 21716 invoked from network); 9 Dec 2014 14:08:45 -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;
	9 Dec 2014 14:08:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201885198"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 09:07: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 1XyLOn-0003Mu-CG;
	Tue, 09 Dec 2014 14:04:21 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 9 Dec 2014 14:04:19 +0000
Message-ID: <1418133859-27763-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] libxl: Tell qemu to use raw format when
	using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 libxl unconditinally passes the underlying file format
to qemu in the device string.  However, when tapdisk is in use,
tapdisk handles the underlying format and presents qemu with
effectively a raw disk.  When qemu looks at the tapdisk block device
and doesn't find the image format it was looking for, it will fail.

This effectively means that tapdisk cannot be used with HVM domains at
the moment except for raw files.

Instead, if we're using a tapdisk backend, tell qemu to use a raw file
format.

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 exception justification: This fixes a bug in functionality, in
that at the moment HVM guests cannot boot with tapdisk and vhd format.

This is not a regression in xl functionality per se, since (AFAICT)
this has never worked.  However, given that 4.5 is the first release
without xend, this *does* represent a regression in functionality for
Xen as a whole (since before people using hvm guest with vhd on blktap
could use xend).

The fix is very simple and should only affect codepaths that already
don't work, so the risk of regressions should be very low.

While preparing this patch, I also noticed that cdroms will ignore the
backend parameter and treat everything as a file.  This is a bug but I
think it's a much less important one to address this late in the
release cycle.
---
 tools/libxl/libxl_dm.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index b25b574..10f3090 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -797,11 +797,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                     continue;
                 }
 
-                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP)
+                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP) {
+                    format = qemu_disk_format_string(LIBXL_DISK_FORMAT_RAW);
                     pdev_path = libxl__blktap_devpath(gc, disks[i].pdev_path,
                                                       disks[i].format);
-                else
+                } else {
                     pdev_path = disks[i].pdev_path;
+                }
+
 
                 /*
                  * Explicit sd disks are passed through as is.
-- 
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 Dec 09 14:09:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14: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 1XyLT6-0004Ny-4m; Tue, 09 Dec 2014 14:08:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XyLT4-0004Nt-TP
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:08:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D5/A8-25276-D6207845; Tue, 09 Dec 2014 14:08:45 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418134124!14433601!1
X-Originating-IP: [66.165.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 21716 invoked from network); 9 Dec 2014 14:08:45 -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;
	9 Dec 2014 14:08:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201885198"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 09:07: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 1XyLOn-0003Mu-CG;
	Tue, 09 Dec 2014 14:04:21 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 9 Dec 2014 14:04:19 +0000
Message-ID: <1418133859-27763-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] libxl: Tell qemu to use raw format when
	using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 libxl unconditinally passes the underlying file format
to qemu in the device string.  However, when tapdisk is in use,
tapdisk handles the underlying format and presents qemu with
effectively a raw disk.  When qemu looks at the tapdisk block device
and doesn't find the image format it was looking for, it will fail.

This effectively means that tapdisk cannot be used with HVM domains at
the moment except for raw files.

Instead, if we're using a tapdisk backend, tell qemu to use a raw file
format.

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 exception justification: This fixes a bug in functionality, in
that at the moment HVM guests cannot boot with tapdisk and vhd format.

This is not a regression in xl functionality per se, since (AFAICT)
this has never worked.  However, given that 4.5 is the first release
without xend, this *does* represent a regression in functionality for
Xen as a whole (since before people using hvm guest with vhd on blktap
could use xend).

The fix is very simple and should only affect codepaths that already
don't work, so the risk of regressions should be very low.

While preparing this patch, I also noticed that cdroms will ignore the
backend parameter and treat everything as a file.  This is a bug but I
think it's a much less important one to address this late in the
release cycle.
---
 tools/libxl/libxl_dm.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index b25b574..10f3090 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -797,11 +797,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                     continue;
                 }
 
-                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP)
+                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP) {
+                    format = qemu_disk_format_string(LIBXL_DISK_FORMAT_RAW);
                     pdev_path = libxl__blktap_devpath(gc, disks[i].pdev_path,
                                                       disks[i].format);
-                else
+                } else {
                     pdev_path = disks[i].pdev_path;
+                }
+
 
                 /*
                  * Explicit sd disks are passed through as is.
-- 
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 Dec 09 14:11:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyLVA-0004TW-Ld; Tue, 09 Dec 2014 14:10:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XyLV9-0004TL-Is
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:10:55 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	25/70-08051-6E207845; Tue, 09 Dec 2014 14:10:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418134241!10611349!1
X-Originating-IP: [66.165.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 21316 invoked from network); 9 Dec 2014 14:10:43 -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;
	9 Dec 2014 14:10:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201886159"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 09:09:14 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XyLTV-0003Xs-Oo;
	Tue, 09 Dec 2014 14:09:13 +0000
Date: Tue, 9 Dec 2014 14:09:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141209140913.GD25749@zion.uk.xensource.com>
References: <1418126815-5708-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418126815-5708-1-git-send-email-olaf@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: xendomains.service depends
	on network
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 01:06:55PM +0100, Olaf Hering wrote:
> Starting domains during boot will most likely require network for the
> local bridge and it may need access to remote filesystems. Add ordering
> tags to systemd service file.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Wei Liu <wei.liu2@citrix.com>

> ---
> 
> This should go into 4.5 to avoid failures if xendomains is scheduled before
> remote mounts are fully available.
> 
>  tools/hotplug/Linux/systemd/xendomains.service.in | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
> index 9962671..66e2065 100644
> --- a/tools/hotplug/Linux/systemd/xendomains.service.in
> +++ b/tools/hotplug/Linux/systemd/xendomains.service.in
> @@ -2,6 +2,8 @@
>  Description=Xendomains - start and stop guests on boot and shutdown
>  Requires=proc-xen.mount xenstored.service
>  After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
> +After=network-online.target
> +After=remote-fs.target
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:11:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyLVA-0004TW-Ld; Tue, 09 Dec 2014 14:10:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XyLV9-0004TL-Is
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:10:55 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	25/70-08051-6E207845; Tue, 09 Dec 2014 14:10:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418134241!10611349!1
X-Originating-IP: [66.165.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 21316 invoked from network); 9 Dec 2014 14:10:43 -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;
	9 Dec 2014 14:10:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201886159"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 09:09:14 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1XyLTV-0003Xs-Oo;
	Tue, 09 Dec 2014 14:09:13 +0000
Date: Tue, 9 Dec 2014 14:09:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141209140913.GD25749@zion.uk.xensource.com>
References: <1418126815-5708-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418126815-5708-1-git-send-email-olaf@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: xendomains.service depends
	on network
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 01:06:55PM +0100, Olaf Hering wrote:
> Starting domains during boot will most likely require network for the
> local bridge and it may need access to remote filesystems. Add ordering
> tags to systemd service file.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Wei Liu <wei.liu2@citrix.com>

> ---
> 
> This should go into 4.5 to avoid failures if xendomains is scheduled before
> remote mounts are fully available.
> 
>  tools/hotplug/Linux/systemd/xendomains.service.in | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
> index 9962671..66e2065 100644
> --- a/tools/hotplug/Linux/systemd/xendomains.service.in
> +++ b/tools/hotplug/Linux/systemd/xendomains.service.in
> @@ -2,6 +2,8 @@
>  Description=Xendomains - start and stop guests on boot and shutdown
>  Requires=proc-xen.mount xenstored.service
>  After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
> +After=network-online.target
> +After=remote-fs.target
>  ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:25:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyLj8-0005Di-3T; Tue, 09 Dec 2014 14:25:22 +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 1XyLj6-0005Dd-U1
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 14:25:21 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	9D/F2-28865-05607845; Tue, 09 Dec 2014 14:25:20 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418135117!12352123!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12305 invoked from network); 9 Dec 2014 14:25:19 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 14:25:19 -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 sB9EPEU8012054
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 9 Dec 2014 09:25:15 -0500
Received: from vitty.brq.redhat.com (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 sB9EPBC8003928; Tue, 9 Dec 2014 09:25:12 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Tue,  9 Dec 2014 15:25:10 +0100
Message-Id: <1418135110-7194-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <54860EA4.7090705@oracle.com>
References: <54860EA4.7090705@oracle.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: xen-devel@lists.xenproject.org, Andrew Jones <drjones@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH v2] xen/blkfront: remove redundant flush_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

flush_op is unambiguously defined by feature_flush:
    REQ_FUA | REQ_FLUSH -> BLKIF_OP_WRITE_BARRIER
    REQ_FLUSH -> BLKIF_OP_FLUSH_DISKCACHE
    0 -> 0
and thus can be removed. This is just a cleanup.

The patch was suggested by Boris Ostrovsky.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
Changes from v1:
   Future-proof feature_flush against new flags [Boris Ostrovsky].

The patch is supposed to be applied after "xen/blkfront: improve protection
against issuing unsupported REQ_FUA".
---
 drivers/block/xen-blkfront.c | 51 +++++++++++++++++++++++++++-----------------
 1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2e6c103..2236c6f 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -126,7 +126,6 @@ struct blkfront_info
 	unsigned int persistent_gnts_c;
 	unsigned long shadow_free;
 	unsigned int feature_flush;
-	unsigned int flush_op;
 	unsigned int feature_discard:1;
 	unsigned int feature_secdiscard:1;
 	unsigned int discard_granularity;
@@ -479,7 +478,19 @@ static int blkif_queue_request(struct request *req)
 				 * way.  (It's also a FLUSH+FUA, since it is
 				 * guaranteed ordered WRT previous writes.)
 				 */
-				ring_req->operation = info->flush_op;
+				switch (info->feature_flush &
+					((REQ_FLUSH|REQ_FUA))) {
+				case REQ_FLUSH|REQ_FUA:
+					ring_req->operation =
+						BLKIF_OP_WRITE_BARRIER;
+					break;
+				case REQ_FLUSH:
+					ring_req->operation =
+						BLKIF_OP_FLUSH_DISKCACHE;
+					break;
+				default:
+					ring_req->operation = 0;
+				}
 			}
 			ring_req->u.rw.nr_segments = nseg;
 		}
@@ -685,20 +696,26 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size,
 	return 0;
 }
 
+static const char *flush_info(unsigned int feature_flush)
+{
+	switch (feature_flush & ((REQ_FLUSH | REQ_FUA))) {
+	case REQ_FLUSH|REQ_FUA:
+		return "barrier: enabled;";
+	case REQ_FLUSH:
+		return "flush diskcache: enabled;";
+	default:
+		return "barrier or flush: disabled;";
+	}
+}
 
 static void xlvbd_flush(struct blkfront_info *info)
 {
 	blk_queue_flush(info->rq, info->feature_flush);
-	printk(KERN_INFO "blkfront: %s: %s: %s %s %s %s %s\n",
-	       info->gd->disk_name,
-	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
-		"flush diskcache" : "barrier or flush"),
-	       info->feature_flush ? "enabled;" : "disabled;",
-	       "persistent grants:",
-	       info->feature_persistent ? "enabled;" : "disabled;",
-	       "indirect descriptors:",
-	       info->max_indirect_segments ? "enabled;" : "disabled;");
+	pr_info("blkfront: %s: %s %s %s %s %s\n",
+		info->gd->disk_name, flush_info(info->feature_flush),
+		"persistent grants:", info->feature_persistent ?
+		"enabled;" : "disabled;", "indirect descriptors:",
+		info->max_indirect_segments ? "enabled;" : "disabled;");
 }
 
 static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
@@ -1190,7 +1207,6 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 				if (error == -EOPNOTSUPP)
 					error = 0;
 				info->feature_flush = 0;
-				info->flush_op = 0;
 				xlvbd_flush(info);
 			}
 			/* fall through */
@@ -1810,7 +1826,6 @@ static void blkfront_connect(struct blkfront_info *info)
 		physical_sector_size = sector_size;
 
 	info->feature_flush = 0;
-	info->flush_op = 0;
 
 	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			    "feature-barrier", "%d", &barrier,
@@ -1823,10 +1838,8 @@ static void blkfront_connect(struct blkfront_info *info)
 	 *
 	 * If there are barriers, then we use flush.
 	 */
-	if (!err && barrier) {
+	if (!err && barrier)
 		info->feature_flush = REQ_FLUSH | REQ_FUA;
-		info->flush_op = BLKIF_OP_WRITE_BARRIER;
-	}
 	/*
 	 * And if there is "feature-flush-cache" use that above
 	 * barriers.
@@ -1835,10 +1848,8 @@ static void blkfront_connect(struct blkfront_info *info)
 			    "feature-flush-cache", "%d", &flush,
 			    NULL);
 
-	if (!err && flush) {
+	if (!err && flush)
 		info->feature_flush = REQ_FLUSH;
-		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
-	}
 
 	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			    "feature-discard", "%d", &discard,
-- 
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 Dec 09 14:25:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyLj8-0005Di-3T; Tue, 09 Dec 2014 14:25:22 +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 1XyLj6-0005Dd-U1
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 14:25:21 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	9D/F2-28865-05607845; Tue, 09 Dec 2014 14:25:20 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418135117!12352123!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12305 invoked from network); 9 Dec 2014 14:25:19 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 14:25:19 -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 sB9EPEU8012054
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 9 Dec 2014 09:25:15 -0500
Received: from vitty.brq.redhat.com (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 sB9EPBC8003928; Tue, 9 Dec 2014 09:25:12 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Tue,  9 Dec 2014 15:25:10 +0100
Message-Id: <1418135110-7194-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <54860EA4.7090705@oracle.com>
References: <54860EA4.7090705@oracle.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Cc: xen-devel@lists.xenproject.org, Andrew Jones <drjones@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH v2] xen/blkfront: remove redundant flush_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

flush_op is unambiguously defined by feature_flush:
    REQ_FUA | REQ_FLUSH -> BLKIF_OP_WRITE_BARRIER
    REQ_FLUSH -> BLKIF_OP_FLUSH_DISKCACHE
    0 -> 0
and thus can be removed. This is just a cleanup.

The patch was suggested by Boris Ostrovsky.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
Changes from v1:
   Future-proof feature_flush against new flags [Boris Ostrovsky].

The patch is supposed to be applied after "xen/blkfront: improve protection
against issuing unsupported REQ_FUA".
---
 drivers/block/xen-blkfront.c | 51 +++++++++++++++++++++++++++-----------------
 1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2e6c103..2236c6f 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -126,7 +126,6 @@ struct blkfront_info
 	unsigned int persistent_gnts_c;
 	unsigned long shadow_free;
 	unsigned int feature_flush;
-	unsigned int flush_op;
 	unsigned int feature_discard:1;
 	unsigned int feature_secdiscard:1;
 	unsigned int discard_granularity;
@@ -479,7 +478,19 @@ static int blkif_queue_request(struct request *req)
 				 * way.  (It's also a FLUSH+FUA, since it is
 				 * guaranteed ordered WRT previous writes.)
 				 */
-				ring_req->operation = info->flush_op;
+				switch (info->feature_flush &
+					((REQ_FLUSH|REQ_FUA))) {
+				case REQ_FLUSH|REQ_FUA:
+					ring_req->operation =
+						BLKIF_OP_WRITE_BARRIER;
+					break;
+				case REQ_FLUSH:
+					ring_req->operation =
+						BLKIF_OP_FLUSH_DISKCACHE;
+					break;
+				default:
+					ring_req->operation = 0;
+				}
 			}
 			ring_req->u.rw.nr_segments = nseg;
 		}
@@ -685,20 +696,26 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size,
 	return 0;
 }
 
+static const char *flush_info(unsigned int feature_flush)
+{
+	switch (feature_flush & ((REQ_FLUSH | REQ_FUA))) {
+	case REQ_FLUSH|REQ_FUA:
+		return "barrier: enabled;";
+	case REQ_FLUSH:
+		return "flush diskcache: enabled;";
+	default:
+		return "barrier or flush: disabled;";
+	}
+}
 
 static void xlvbd_flush(struct blkfront_info *info)
 {
 	blk_queue_flush(info->rq, info->feature_flush);
-	printk(KERN_INFO "blkfront: %s: %s: %s %s %s %s %s\n",
-	       info->gd->disk_name,
-	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
-		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
-		"flush diskcache" : "barrier or flush"),
-	       info->feature_flush ? "enabled;" : "disabled;",
-	       "persistent grants:",
-	       info->feature_persistent ? "enabled;" : "disabled;",
-	       "indirect descriptors:",
-	       info->max_indirect_segments ? "enabled;" : "disabled;");
+	pr_info("blkfront: %s: %s %s %s %s %s\n",
+		info->gd->disk_name, flush_info(info->feature_flush),
+		"persistent grants:", info->feature_persistent ?
+		"enabled;" : "disabled;", "indirect descriptors:",
+		info->max_indirect_segments ? "enabled;" : "disabled;");
 }
 
 static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
@@ -1190,7 +1207,6 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 				if (error == -EOPNOTSUPP)
 					error = 0;
 				info->feature_flush = 0;
-				info->flush_op = 0;
 				xlvbd_flush(info);
 			}
 			/* fall through */
@@ -1810,7 +1826,6 @@ static void blkfront_connect(struct blkfront_info *info)
 		physical_sector_size = sector_size;
 
 	info->feature_flush = 0;
-	info->flush_op = 0;
 
 	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			    "feature-barrier", "%d", &barrier,
@@ -1823,10 +1838,8 @@ static void blkfront_connect(struct blkfront_info *info)
 	 *
 	 * If there are barriers, then we use flush.
 	 */
-	if (!err && barrier) {
+	if (!err && barrier)
 		info->feature_flush = REQ_FLUSH | REQ_FUA;
-		info->flush_op = BLKIF_OP_WRITE_BARRIER;
-	}
 	/*
 	 * And if there is "feature-flush-cache" use that above
 	 * barriers.
@@ -1835,10 +1848,8 @@ static void blkfront_connect(struct blkfront_info *info)
 			    "feature-flush-cache", "%d", &flush,
 			    NULL);
 
-	if (!err && flush) {
+	if (!err && flush)
 		info->feature_flush = REQ_FLUSH;
-		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
-	}
 
 	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			    "feature-discard", "%d", &discard,
-- 
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 Dec 09 14:28:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyLlY-0005LB-QJ; Tue, 09 Dec 2014 14:27: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 1XyLlX-0005L3-7n
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:27:51 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	97/6D-02697-6E607845; Tue, 09 Dec 2014 14:27:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418135267!12354061!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 15462 invoked from network); 9 Dec 2014 14:27:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 14:27:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201895752"
Message-ID: <1418135262.14361.65.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, 9 Dec 2014 14:27:42 +0000
In-Reply-To: <1417174620.23604.12.camel@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>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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 Fri, 2014-11-28 at 11:37 +0000, 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.

Konrad, given
http://article.gmane.org/gmane.comp.emulators.xen.devel/224881 does this
have a release ack?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:28:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyLlY-0005LB-QJ; Tue, 09 Dec 2014 14:27: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 1XyLlX-0005L3-7n
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:27:51 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	97/6D-02697-6E607845; Tue, 09 Dec 2014 14:27:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418135267!12354061!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 15462 invoked from network); 9 Dec 2014 14:27:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 14:27:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201895752"
Message-ID: <1418135262.14361.65.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, 9 Dec 2014 14:27:42 +0000
In-Reply-To: <1417174620.23604.12.camel@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>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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 Fri, 2014-11-28 at 11:37 +0000, 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.

Konrad, given
http://article.gmane.org/gmane.comp.emulators.xen.devel/224881 does this
have a release ack?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:31:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:31:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyLoT-0005Uw-CM; Tue, 09 Dec 2014 14:30: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 1XyLoR-0005Um-I3
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:30:51 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	C7/1E-27584-A9707845; Tue, 09 Dec 2014 14:30:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418135447!12354892!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13629 invoked from network); 9 Dec 2014 14:30:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 14:30:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201896941"
Message-ID: <54870780.7040801@citrix.com>
Date: Tue, 9 Dec 2014 14:30: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: Ian Campbell <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.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>
	<1418135262.14361.65.camel@citrix.com>
In-Reply-To: <1418135262.14361.65.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 09/12/14 14:27, Ian Campbell wrote:
> On Fri, 2014-11-28 at 11:37 +0000, 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.
> Konrad, given
> http://article.gmane.org/gmane.comp.emulators.xen.devel/224881 does this
> have a release ack?
>
> Ian.
>

I can resubmit with a clearer description if that would help clarity,
but the code is correct for the fixes (not fantastically well) described.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:31:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:31:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyLoT-0005Uw-CM; Tue, 09 Dec 2014 14:30: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 1XyLoR-0005Um-I3
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:30:51 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	C7/1E-27584-A9707845; Tue, 09 Dec 2014 14:30:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418135447!12354892!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13629 invoked from network); 9 Dec 2014 14:30:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 14:30:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201896941"
Message-ID: <54870780.7040801@citrix.com>
Date: Tue, 9 Dec 2014 14:30: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: Ian Campbell <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.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>
	<1418135262.14361.65.camel@citrix.com>
In-Reply-To: <1418135262.14361.65.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 09/12/14 14:27, Ian Campbell wrote:
> On Fri, 2014-11-28 at 11:37 +0000, 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.
> Konrad, given
> http://article.gmane.org/gmane.comp.emulators.xen.devel/224881 does this
> have a release ack?
>
> Ian.
>

I can resubmit with a clearer description if that would help clarity,
but the code is correct for the fixes (not fantastically well) described.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:32:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:32:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyLq1-0005rh-Rm; Tue, 09 Dec 2014 14:32:29 +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 1XyLq0-0005rZ-DB
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:32:28 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	DD/61-18267-BF707845; Tue, 09 Dec 2014 14:32:27 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418135545!7658116!1
X-Originating-IP: [66.165.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 12638 invoked from network); 9 Dec 2014 14:32:27 -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;
	9 Dec 2014 14:32:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201898094"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 09:32: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 1XyLpw-00041V-9g;
	Tue, 09 Dec 2014 14:32:24 +0000
Date: Tue, 9 Dec 2014 14:32:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20141209143224.GE25749@zion.uk.xensource.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418133859-27763-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] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 02:04:19PM +0000, George Dunlap wrote:
> At the moment libxl unconditinally passes the underlying file format
> to qemu in the device string.  However, when tapdisk is in use,
> tapdisk handles the underlying format and presents qemu with
> effectively a raw disk.  When qemu looks at the tapdisk block device
> and doesn't find the image format it was looking for, it will fail.
> 
> This effectively means that tapdisk cannot be used with HVM domains at
> the moment except for raw files.
> 
> Instead, if we're using a tapdisk backend, tell qemu to use a raw file
> format.
> 
> 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>
> 

Acked-by: Wei Liu <wei.liu2@citrix.com>

> Release exception justification: This fixes a bug in functionality, in
> that at the moment HVM guests cannot boot with tapdisk and vhd format.
> 
> This is not a regression in xl functionality per se, since (AFAICT)
> this has never worked.  However, given that 4.5 is the first release
> without xend, this *does* represent a regression in functionality for
> Xen as a whole (since before people using hvm guest with vhd on blktap
> could use xend).
> 
> The fix is very simple and should only affect codepaths that already
> don't work, so the risk of regressions should be very low.
> 
> While preparing this patch, I also noticed that cdroms will ignore the
> backend parameter and treat everything as a file.  This is a bug but I
> think it's a much less important one to address this late in the
> release cycle.

We should create a bug tracker entry for this.

> ---
>  tools/libxl/libxl_dm.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index b25b574..10f3090 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -797,11 +797,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                      continue;
>                  }
>  
> -                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP)
> +                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP) {
> +                    format = qemu_disk_format_string(LIBXL_DISK_FORMAT_RAW);
>                      pdev_path = libxl__blktap_devpath(gc, disks[i].pdev_path,
>                                                        disks[i].format);
> -                else
> +                } else {
>                      pdev_path = disks[i].pdev_path;
> +                }
> +

Minor nit, extra blank line, but this alone doesn't warrant a resend.

>  
>                  /*
>                   * Explicit sd disks are passed through as is.
> -- 
> 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 Dec 09 14:32:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:32:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyLq1-0005rh-Rm; Tue, 09 Dec 2014 14:32:29 +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 1XyLq0-0005rZ-DB
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:32:28 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	DD/61-18267-BF707845; Tue, 09 Dec 2014 14:32:27 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418135545!7658116!1
X-Originating-IP: [66.165.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 12638 invoked from network); 9 Dec 2014 14:32:27 -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;
	9 Dec 2014 14:32:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201898094"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 09:32: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 1XyLpw-00041V-9g;
	Tue, 09 Dec 2014 14:32:24 +0000
Date: Tue, 9 Dec 2014 14:32:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20141209143224.GE25749@zion.uk.xensource.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418133859-27763-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] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 02:04:19PM +0000, George Dunlap wrote:
> At the moment libxl unconditinally passes the underlying file format
> to qemu in the device string.  However, when tapdisk is in use,
> tapdisk handles the underlying format and presents qemu with
> effectively a raw disk.  When qemu looks at the tapdisk block device
> and doesn't find the image format it was looking for, it will fail.
> 
> This effectively means that tapdisk cannot be used with HVM domains at
> the moment except for raw files.
> 
> Instead, if we're using a tapdisk backend, tell qemu to use a raw file
> format.
> 
> 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>
> 

Acked-by: Wei Liu <wei.liu2@citrix.com>

> Release exception justification: This fixes a bug in functionality, in
> that at the moment HVM guests cannot boot with tapdisk and vhd format.
> 
> This is not a regression in xl functionality per se, since (AFAICT)
> this has never worked.  However, given that 4.5 is the first release
> without xend, this *does* represent a regression in functionality for
> Xen as a whole (since before people using hvm guest with vhd on blktap
> could use xend).
> 
> The fix is very simple and should only affect codepaths that already
> don't work, so the risk of regressions should be very low.
> 
> While preparing this patch, I also noticed that cdroms will ignore the
> backend parameter and treat everything as a file.  This is a bug but I
> think it's a much less important one to address this late in the
> release cycle.

We should create a bug tracker entry for this.

> ---
>  tools/libxl/libxl_dm.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index b25b574..10f3090 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -797,11 +797,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                      continue;
>                  }
>  
> -                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP)
> +                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP) {
> +                    format = qemu_disk_format_string(LIBXL_DISK_FORMAT_RAW);
>                      pdev_path = libxl__blktap_devpath(gc, disks[i].pdev_path,
>                                                        disks[i].format);
> -                else
> +                } else {
>                      pdev_path = disks[i].pdev_path;
> +                }
> +

Minor nit, extra blank line, but this alone doesn't warrant a resend.

>  
>                  /*
>                   * Explicit sd disks are passed through as is.
> -- 
> 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 Dec 09 14:33:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyLqv-0005wk-9Z; Tue, 09 Dec 2014 14:33:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XyLqu-0005wX-01
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:33:24 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	22/B3-18267-33807845; Tue, 09 Dec 2014 14:33:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418135602!9655440!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26888 invoked from network); 9 Dec 2014 14:33:22 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 14:33:22 -0000
Received: by mail-wg0-f49.google.com with SMTP id n12so982217wgh.22
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 06:33:22 -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=zv6b0ts4IHkNE9XTrWAcQTVSEtV5ud6CYmp3MNC6ECI=;
	b=YvgWcVZokX+4C7tAbCe6PUSCygQhAjD0XWoQYaJC+TM3JhZLxrfcFUJHz4Ba4J/CPu
	vNl/ABO9BNp+Z2HddT0raXZfurA+HAggb9FHkML6u6VbiFVJGgAyFaqcoQY3aSLGm3WW
	16eFGXGPVedp9g7pKHKTMdE6vPWM9Abk5GcW8BoHxp+3jsJgsKIehAy7nZIRYZ4IWVJM
	kze7PLwlGiAVmsLQ90XCdbwg9xt27TJ+NR626/NWDNtQ5NbHUgUsIyCsdTaBU3JwN4Nh
	1EF0xr94a7A++yI+4TFy3voKAmgCxmOUp8SSS5X+OxP/DksBV97M10GLx54E3yfWeWaG
	1zpA==
MIME-Version: 1.0
X-Received: by 10.180.8.7 with SMTP id n7mr4765759wia.11.1418135599834; Tue,
	09 Dec 2014 06:33:19 -0800 (PST)
Received: by 10.194.163.70 with HTTP; Tue, 9 Dec 2014 06:33:19 -0800 (PST)
In-Reply-To: <1418013396.36972.YahooMailNeo@web190601.mail.sg3.yahoo.com>
References: <1418013396.36972.YahooMailNeo@web190601.mail.sg3.yahoo.com>
Date: Tue, 9 Dec 2014 14:33:19 +0000
X-Google-Sender-Auth: XtxseTRKGsdxwYUa8MBkjenfe9U
Message-ID: <CAFLBxZbWei03Dm_tnHfeEic9rKkEfx+4Uaa4+HMTJjZohSL6NA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Minalkumar Patel <patel_mp@yahoo.co.in>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] error of VM Migration (xl toolstack) failed when
 migrating Webserver VM with 100 connecitons using httperf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 8, 2014 at 4:36 AM, Minalkumar Patel <patel_mp@yahoo.co.in> wrote:
>
>
> error of Migration failed when migrating Webserver VM with 100 connecitons
> using httperf

Thanks for the bug report.  Can you please include more information
about your setup?

At very least the output of "xl info", your domain config file, and
preferrably your serial console output as well; or the output of
"dmesg" if you have no serial console.

See here for more details:
 http://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project

Thanks,

 -George

>
> First time it generats (a part of follwoing output):
>
> migration target: Transfer complete, requesting permission to start domain.
> migration sender: Target has acknowledged transfer.
> migration sender: Giving target permission to start.
> migration target: Got permission, starting domain.
> [everything ok uptill now]
> libxl: error: libxl.c:321:libxl__domain_rename: domain with name "drbdvm1"
> already exists.
> migration target: Failure, destroying our copy.
> migration sender: Target reports startup failure (status code 6).
> migration target: Cleanup OK, granting sender permission to resume.
> migration sender: Trying to resume at our end.
> libxl: debug: libxl.c:435:libxl_domain_resume: ao 0xa91bf0: create:
> how=(nil) callback=(nil) poller=0xa91c50
> xc: error: Cannot resume uncooperative HVM guests: Internal error
> libxl: error: libxl.c:404:libxl__domain_resume: xc_domain_resume failed for
> domain 10: No such file or directory
> libxl: debug: libxl_event.c:1499:libxl__ao_complete: ao 0xa91bf0: complete,
> rc=-3
> libxl: debug: libxl.c:438:libxl_domain_resume: ao 0xa91bf0: inprogress:
> poller=0xa91c50, flags=ic
> libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0xa91bf0: destroy
> Migration failed due to problems at target.
>
> Second time it generates (a part of follwing output):
>
> xc: detail: Start last iteration
> [everything ok uptill now]
> libxl: debug: libxl_dom.c:933:libxl__domain_suspend_common_callback: issuing
> PVHVM suspend request via XenBus control node
> libxl: debug: libxl_dom.c:937:libxl__domain_suspend_common_callback: wait
> for the guest to acknowledge suspend request
> libxl: error: libxl_dom.c:958:libxl__domain_suspend_common_callback: guest
> didn't acknowledge suspend, cancelling request
> libxl: error: libxl_dom.c:980:libxl__domain_suspend_common_callback: guest
> didn't acknowledge suspend, request cancelled
> xc: error: Suspend request failed: Internal error
> xc: error: Domain appears not to have suspended: Internal error
> libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch
> w=0x21c5f80 wpath=/local/domain/0/device-model/10/logdirty/ret token=3/1:
> register slotnum=3
> libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x21c5f80
> wpath=/local/domain/0/device-model/10/logdirty/ret token=3/1: event
> epath=/local/domain/0/device-model/10/logdirty/ret
> libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x21c5f80
> wpath=/local/domain/0/device-model/10/logdirty/ret token=3/1: event
> epath=/local/domain/0/device-model/10/logdirty/ret
> libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch
> w=0x21c5f80 wpath=/local/domain/0/device-model/10/logdirty/ret token=3/1:
> deregister slotnum=3
> libxl: debug: libxl_event.c:426:watchfd_callback: watch
> epath=/local/domain/0/device-model/10/logdirty/ret token=3/1: empty slot
> xc: detail: Save exit rc=1
> libxl-save-helper: debug: complete r=1: No such device
> libxl: error: libxl_dom.c:1266:libxl__xc_domain_save_done: saving domain:
> domain did not respond to suspend request: No such device
> libxl: debug: libxl_event.c:1499:libxl__ao_complete: ao 0x21c5bf0: complete,
> rc=-8
> libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0x21c5bf0: destroy
> migration sender: libxl_domain_suspend failed (rc=-8)
> xc: error: 0-length read: Internal error
> xc: error: read_exact_timed failed (read rc: 0, errno: 0): Internal error
> xc: error: Error when reading batch size (0 = Success): Internal error
> xc: error: Error when reading batch (0 = Success): Internal error
> libxl: error: libxl_create.c:820:libxl__xc_domain_restore_done: restoring
> domain: Resource temporarily unavailable
> libxl: error: libxl_create.c:902:domcreate_rebuild_done: cannot (re-)build
> domain: -3
> libxl: error: libxl.c:1394:libxl__destroy_domid: non-existant domain 6
> libxl: error: libxl.c:1358:domain_destroy_callback: unable to destroy guest
> with domid 6
> libxl: error: libxl_create.c:1153:domcreate_destruction_cb: unable to
> destroy domain 6 following failed creation
> migration target: Domain creation failed (code -3).
> libxl: info: libxl_exec.c:118:libxl_report_child_exitstatus: migration
> target process [11104] exited with error status 3
> Migration failed, failed to suspend at sender.
>
>
> What goes wrong please tell me?It also shows migration of Webserver VM at
> destination  and it can be manually started and in worknig condition. But
> at sender, VM  is still continueing  webserver based httperf connections and
> doesn't turn off....so i can have VM at both side ..why sender is not
> stopping activity?
>
> Regards,
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 09 14:33:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyLqv-0005wk-9Z; Tue, 09 Dec 2014 14:33:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1XyLqu-0005wX-01
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:33:24 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	22/B3-18267-33807845; Tue, 09 Dec 2014 14:33:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418135602!9655440!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26888 invoked from network); 9 Dec 2014 14:33:22 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 14:33:22 -0000
Received: by mail-wg0-f49.google.com with SMTP id n12so982217wgh.22
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 06:33:22 -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=zv6b0ts4IHkNE9XTrWAcQTVSEtV5ud6CYmp3MNC6ECI=;
	b=YvgWcVZokX+4C7tAbCe6PUSCygQhAjD0XWoQYaJC+TM3JhZLxrfcFUJHz4Ba4J/CPu
	vNl/ABO9BNp+Z2HddT0raXZfurA+HAggb9FHkML6u6VbiFVJGgAyFaqcoQY3aSLGm3WW
	16eFGXGPVedp9g7pKHKTMdE6vPWM9Abk5GcW8BoHxp+3jsJgsKIehAy7nZIRYZ4IWVJM
	kze7PLwlGiAVmsLQ90XCdbwg9xt27TJ+NR626/NWDNtQ5NbHUgUsIyCsdTaBU3JwN4Nh
	1EF0xr94a7A++yI+4TFy3voKAmgCxmOUp8SSS5X+OxP/DksBV97M10GLx54E3yfWeWaG
	1zpA==
MIME-Version: 1.0
X-Received: by 10.180.8.7 with SMTP id n7mr4765759wia.11.1418135599834; Tue,
	09 Dec 2014 06:33:19 -0800 (PST)
Received: by 10.194.163.70 with HTTP; Tue, 9 Dec 2014 06:33:19 -0800 (PST)
In-Reply-To: <1418013396.36972.YahooMailNeo@web190601.mail.sg3.yahoo.com>
References: <1418013396.36972.YahooMailNeo@web190601.mail.sg3.yahoo.com>
Date: Tue, 9 Dec 2014 14:33:19 +0000
X-Google-Sender-Auth: XtxseTRKGsdxwYUa8MBkjenfe9U
Message-ID: <CAFLBxZbWei03Dm_tnHfeEic9rKkEfx+4Uaa4+HMTJjZohSL6NA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Minalkumar Patel <patel_mp@yahoo.co.in>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] error of VM Migration (xl toolstack) failed when
 migrating Webserver VM with 100 connecitons using httperf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 8, 2014 at 4:36 AM, Minalkumar Patel <patel_mp@yahoo.co.in> wrote:
>
>
> error of Migration failed when migrating Webserver VM with 100 connecitons
> using httperf

Thanks for the bug report.  Can you please include more information
about your setup?

At very least the output of "xl info", your domain config file, and
preferrably your serial console output as well; or the output of
"dmesg" if you have no serial console.

See here for more details:
 http://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project

Thanks,

 -George

>
> First time it generats (a part of follwoing output):
>
> migration target: Transfer complete, requesting permission to start domain.
> migration sender: Target has acknowledged transfer.
> migration sender: Giving target permission to start.
> migration target: Got permission, starting domain.
> [everything ok uptill now]
> libxl: error: libxl.c:321:libxl__domain_rename: domain with name "drbdvm1"
> already exists.
> migration target: Failure, destroying our copy.
> migration sender: Target reports startup failure (status code 6).
> migration target: Cleanup OK, granting sender permission to resume.
> migration sender: Trying to resume at our end.
> libxl: debug: libxl.c:435:libxl_domain_resume: ao 0xa91bf0: create:
> how=(nil) callback=(nil) poller=0xa91c50
> xc: error: Cannot resume uncooperative HVM guests: Internal error
> libxl: error: libxl.c:404:libxl__domain_resume: xc_domain_resume failed for
> domain 10: No such file or directory
> libxl: debug: libxl_event.c:1499:libxl__ao_complete: ao 0xa91bf0: complete,
> rc=-3
> libxl: debug: libxl.c:438:libxl_domain_resume: ao 0xa91bf0: inprogress:
> poller=0xa91c50, flags=ic
> libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0xa91bf0: destroy
> Migration failed due to problems at target.
>
> Second time it generates (a part of follwing output):
>
> xc: detail: Start last iteration
> [everything ok uptill now]
> libxl: debug: libxl_dom.c:933:libxl__domain_suspend_common_callback: issuing
> PVHVM suspend request via XenBus control node
> libxl: debug: libxl_dom.c:937:libxl__domain_suspend_common_callback: wait
> for the guest to acknowledge suspend request
> libxl: error: libxl_dom.c:958:libxl__domain_suspend_common_callback: guest
> didn't acknowledge suspend, cancelling request
> libxl: error: libxl_dom.c:980:libxl__domain_suspend_common_callback: guest
> didn't acknowledge suspend, request cancelled
> xc: error: Suspend request failed: Internal error
> xc: error: Domain appears not to have suspended: Internal error
> libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch
> w=0x21c5f80 wpath=/local/domain/0/device-model/10/logdirty/ret token=3/1:
> register slotnum=3
> libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x21c5f80
> wpath=/local/domain/0/device-model/10/logdirty/ret token=3/1: event
> epath=/local/domain/0/device-model/10/logdirty/ret
> libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x21c5f80
> wpath=/local/domain/0/device-model/10/logdirty/ret token=3/1: event
> epath=/local/domain/0/device-model/10/logdirty/ret
> libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch
> w=0x21c5f80 wpath=/local/domain/0/device-model/10/logdirty/ret token=3/1:
> deregister slotnum=3
> libxl: debug: libxl_event.c:426:watchfd_callback: watch
> epath=/local/domain/0/device-model/10/logdirty/ret token=3/1: empty slot
> xc: detail: Save exit rc=1
> libxl-save-helper: debug: complete r=1: No such device
> libxl: error: libxl_dom.c:1266:libxl__xc_domain_save_done: saving domain:
> domain did not respond to suspend request: No such device
> libxl: debug: libxl_event.c:1499:libxl__ao_complete: ao 0x21c5bf0: complete,
> rc=-8
> libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0x21c5bf0: destroy
> migration sender: libxl_domain_suspend failed (rc=-8)
> xc: error: 0-length read: Internal error
> xc: error: read_exact_timed failed (read rc: 0, errno: 0): Internal error
> xc: error: Error when reading batch size (0 = Success): Internal error
> xc: error: Error when reading batch (0 = Success): Internal error
> libxl: error: libxl_create.c:820:libxl__xc_domain_restore_done: restoring
> domain: Resource temporarily unavailable
> libxl: error: libxl_create.c:902:domcreate_rebuild_done: cannot (re-)build
> domain: -3
> libxl: error: libxl.c:1394:libxl__destroy_domid: non-existant domain 6
> libxl: error: libxl.c:1358:domain_destroy_callback: unable to destroy guest
> with domid 6
> libxl: error: libxl_create.c:1153:domcreate_destruction_cb: unable to
> destroy domain 6 following failed creation
> migration target: Domain creation failed (code -3).
> libxl: info: libxl_exec.c:118:libxl_report_child_exitstatus: migration
> target process [11104] exited with error status 3
> Migration failed, failed to suspend at sender.
>
>
> What goes wrong please tell me?It also shows migration of Webserver VM at
> destination  and it can be manually started and in worknig condition. But
> at sender, VM  is still continueing  webserver based httperf connections and
> doesn't turn off....so i can have VM at both side ..why sender is not
> stopping activity?
>
> Regards,
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 09 14:34:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14: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 1XyLrz-000646-OV; Tue, 09 Dec 2014 14:34:31 +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 1XyLry-00063o-G2
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:34:30 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	3E/6D-02712-57807845; Tue, 09 Dec 2014 14:34:29 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418135666!13962940!1
X-Originating-IP: [66.165.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 31840 invoked from network); 9 Dec 2014 14:34:27 -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;
	9 Dec 2014 14:34:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201899321"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 09:34:25 -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 1XyLrt-00043U-7t;
	Tue, 09 Dec 2014 14:34:25 +0000
Message-ID: <54870870.2040309@eu.citrix.com>
Date: Tue, 9 Dec 2014 14:34:24 +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: Wei Liu <wei.liu2@citrix.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
	<20141209143224.GE25749@zion.uk.xensource.com>
In-Reply-To: <20141209143224.GE25749@zion.uk.xensource.com>
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/09/2014 02:32 PM, Wei Liu wrote:
> On Tue, Dec 09, 2014 at 02:04:19PM +0000, George Dunlap wrote:
>> At the moment libxl unconditinally passes the underlying file format
>> to qemu in the device string.  However, when tapdisk is in use,
>> tapdisk handles the underlying format and presents qemu with
>> effectively a raw disk.  When qemu looks at the tapdisk block device
>> and doesn't find the image format it was looking for, it will fail.
>>
>> This effectively means that tapdisk cannot be used with HVM domains at
>> the moment except for raw files.
>>
>> Instead, if we're using a tapdisk backend, tell qemu to use a raw file
>> format.
>>
>> 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>
>>
> 
> Acked-by: Wei Liu <wei.liu2@citrix.com>
> 
>> Release exception justification: This fixes a bug in functionality, in
>> that at the moment HVM guests cannot boot with tapdisk and vhd format.
>>
>> This is not a regression in xl functionality per se, since (AFAICT)
>> this has never worked.  However, given that 4.5 is the first release
>> without xend, this *does* represent a regression in functionality for
>> Xen as a whole (since before people using hvm guest with vhd on blktap
>> could use xend).
>>
>> The fix is very simple and should only affect codepaths that already
>> don't work, so the risk of regressions should be very low.
>>
>> While preparing this patch, I also noticed that cdroms will ignore the
>> backend parameter and treat everything as a file.  This is a bug but I
>> think it's a much less important one to address this late in the
>> release cycle.
> 
> We should create a bug tracker entry for this.
> 
>> ---
>>  tools/libxl/libxl_dm.c | 7 +++++--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index b25b574..10f3090 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -797,11 +797,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>>                      continue;
>>                  }
>>  
>> -                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP)
>> +                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP) {
>> +                    format = qemu_disk_format_string(LIBXL_DISK_FORMAT_RAW);
>>                      pdev_path = libxl__blktap_devpath(gc, disks[i].pdev_path,
>>                                                        disks[i].format);
>> -                else
>> +                } else {
>>                      pdev_path = disks[i].pdev_path;
>> +                }
>> +
> 
> Minor nit, extra blank line, but this alone doesn't warrant a resend.

Yes, I noticed this as soon as I sent it. :-/

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:34:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14: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 1XyLrz-000646-OV; Tue, 09 Dec 2014 14:34:31 +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 1XyLry-00063o-G2
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:34:30 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	3E/6D-02712-57807845; Tue, 09 Dec 2014 14:34:29 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418135666!13962940!1
X-Originating-IP: [66.165.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 31840 invoked from network); 9 Dec 2014 14:34:27 -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;
	9 Dec 2014 14:34:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201899321"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 09:34:25 -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 1XyLrt-00043U-7t;
	Tue, 09 Dec 2014 14:34:25 +0000
Message-ID: <54870870.2040309@eu.citrix.com>
Date: Tue, 9 Dec 2014 14:34:24 +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: Wei Liu <wei.liu2@citrix.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
	<20141209143224.GE25749@zion.uk.xensource.com>
In-Reply-To: <20141209143224.GE25749@zion.uk.xensource.com>
X-DLP: MIA1
Cc: Ian Jackson <ian.jackson@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/09/2014 02:32 PM, Wei Liu wrote:
> On Tue, Dec 09, 2014 at 02:04:19PM +0000, George Dunlap wrote:
>> At the moment libxl unconditinally passes the underlying file format
>> to qemu in the device string.  However, when tapdisk is in use,
>> tapdisk handles the underlying format and presents qemu with
>> effectively a raw disk.  When qemu looks at the tapdisk block device
>> and doesn't find the image format it was looking for, it will fail.
>>
>> This effectively means that tapdisk cannot be used with HVM domains at
>> the moment except for raw files.
>>
>> Instead, if we're using a tapdisk backend, tell qemu to use a raw file
>> format.
>>
>> 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>
>>
> 
> Acked-by: Wei Liu <wei.liu2@citrix.com>
> 
>> Release exception justification: This fixes a bug in functionality, in
>> that at the moment HVM guests cannot boot with tapdisk and vhd format.
>>
>> This is not a regression in xl functionality per se, since (AFAICT)
>> this has never worked.  However, given that 4.5 is the first release
>> without xend, this *does* represent a regression in functionality for
>> Xen as a whole (since before people using hvm guest with vhd on blktap
>> could use xend).
>>
>> The fix is very simple and should only affect codepaths that already
>> don't work, so the risk of regressions should be very low.
>>
>> While preparing this patch, I also noticed that cdroms will ignore the
>> backend parameter and treat everything as a file.  This is a bug but I
>> think it's a much less important one to address this late in the
>> release cycle.
> 
> We should create a bug tracker entry for this.
> 
>> ---
>>  tools/libxl/libxl_dm.c | 7 +++++--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index b25b574..10f3090 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -797,11 +797,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>>                      continue;
>>                  }
>>  
>> -                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP)
>> +                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP) {
>> +                    format = qemu_disk_format_string(LIBXL_DISK_FORMAT_RAW);
>>                      pdev_path = libxl__blktap_devpath(gc, disks[i].pdev_path,
>>                                                        disks[i].format);
>> -                else
>> +                } else {
>>                      pdev_path = disks[i].pdev_path;
>> +                }
>> +
> 
> Minor nit, extra blank line, but this alone doesn't warrant a resend.

Yes, I noticed this as soon as I sent it. :-/

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:36:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:36:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyLtI-0006D7-7P; Tue, 09 Dec 2014 14:35: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 1XyLtG-0006Cu-UP
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 14:35:51 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	E5/35-02702-5C807845; Tue, 09 Dec 2014 14:35:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418135747!13955956!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 13138 invoked from network); 9 Dec 2014 14:35:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 14:35:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202302551"
Message-ID: <1418135737.14361.71.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Date: Tue, 9 Dec 2014 14:35:37 +0000
In-Reply-To: <1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, keir@xen.org, ian.jackson@eu.citrix.com,
	jbeulich@suse.com, andrew.cooper3@citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
 target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 16:16 +0100, Daniel Kiper wrote:

> +distclean:
> +	rm -f Linux/init.d/sysconfig.xencommons Linux/init.d/xencommons NetBSD/rc.d/xencommons

Configure generates a boatload more things than this, see e.g. 

$ grep hotplug/ tools/configure.ac 

Perhaps the answer would be to recurse into tools/hotplug/* and refactor
the existing XEN_SCRIPTS to have the generated stuff in XEN_SCRIPTS_GEN
instead and XEN_SCRIPTS += $(XEN_SCRIPTS). The on distclean remove the
XEN_SCRIPTS_GEN ones.

It's not ideal, but at least it puts the distclean logic in the same
place as the logic to install the files, if not their generation, which
at least increases the chance of someone adding it to the right place.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:36:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:36:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyLtI-0006D7-7P; Tue, 09 Dec 2014 14:35: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 1XyLtG-0006Cu-UP
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 14:35:51 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	E5/35-02702-5C807845; Tue, 09 Dec 2014 14:35:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418135747!13955956!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 13138 invoked from network); 9 Dec 2014 14:35:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 14:35:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202302551"
Message-ID: <1418135737.14361.71.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Date: Tue, 9 Dec 2014 14:35:37 +0000
In-Reply-To: <1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, keir@xen.org, ian.jackson@eu.citrix.com,
	jbeulich@suse.com, andrew.cooper3@citrix.com
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
 target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-02 at 16:16 +0100, Daniel Kiper wrote:

> +distclean:
> +	rm -f Linux/init.d/sysconfig.xencommons Linux/init.d/xencommons NetBSD/rc.d/xencommons

Configure generates a boatload more things than this, see e.g. 

$ grep hotplug/ tools/configure.ac 

Perhaps the answer would be to recurse into tools/hotplug/* and refactor
the existing XEN_SCRIPTS to have the generated stuff in XEN_SCRIPTS_GEN
instead and XEN_SCRIPTS += $(XEN_SCRIPTS). The on distclean remove the
XEN_SCRIPTS_GEN ones.

It's not ideal, but at least it puts the distclean logic in the same
place as the logic to install the files, if not their generation, which
at least increases the chance of someone adding it to the right place.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:48:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:48:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyM4e-0006kR-EZ; Tue, 09 Dec 2014 14:47: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 1XyM4d-0006kM-Cx
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:47:35 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	01/A8-02696-68B07845; Tue, 09 Dec 2014 14:47:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418136452!13959458!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11674 invoked from network); 9 Dec 2014 14:47:33 -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;
	9 Dec 2014 14:47:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202308090"
Message-ID: <1418136450.14361.82.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>, "Konrad
	Rzeszutek Wilk" <konrad.wilk@oracle.com>
Date: Tue, 9 Dec 2014 14:47:30 +0000
In-Reply-To: <1418046707-6900-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1418046707-6900-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-08 at 15:51 +0200, Oleksandr Dmytryshyn wrote:
> UART is not able to receive bytes when idle mode is not
> configured properly. When we use Xen with old Linux
> Kernel (for example 3.8) this kernel configures hwmods
> for all devices even if the device tree nodes for those
> devices is absent in device tree. Thus UART idle mode
> is configured too. The fake node for the UART should
> be added to the device tree because the MMIO range
> is not mapped by Xen. So UART works normally in this
> case. But new Linux Kernel (3.12 and upper) doesn't
> configure idle mode for UART and UART can not work
> normally in this case.

I think the focus is too much on the hack done with 3.8 to make this
work rather than on the fix being made here itself. The hack is only
really of peripheral/historic interest.

How about instead:

        The UART is not able to receive bytes when idle mode is not
        configured properly, therefore setup the UART with autoidle and
        wakeup enabled.
        
You could stop here or if you really want to cover the old hack you
could go on to say:
     
        Older Linux kernels (for example 3.8) configures hwmods for all
        devices even if the device tree nodes for those devices is
        absent in device tree, thus UART idle mode is configured too.
        With such kernels we can workaround the issue by adding a fake
        node in the UART containing this MMIO range, which is therefore
        mapped by Xen to dom0, which reconfigures the UART, causing
        things to work normally.
        
        Newer Linux Kernels (3.12 and beyond) do not configure idle mode
        for UART and so this hack no longer works.
        
If you are happy with the proposed wording (and indicate whether you
want both bits or just the first) then, subject to Konrad giving a
release Ack I'd be happy with this for 4.5 and I'll change the commit
log as I go.

Konrad, this is a bug fix for a particular piece of hardware, it can't
affect anything other than the OMAP ARM platform.


> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>

> ---
> Changed since v1:
>  * corrected commit message
> 
>  xen/drivers/char/omap-uart.c | 3 +++
>  xen/include/xen/8250-uart.h  | 4 ++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
> index a798b8d..16d1454 100644
> --- a/xen/drivers/char/omap-uart.c
> +++ b/xen/drivers/char/omap-uart.c
> @@ -195,6 +195,9 @@ static void __init omap_uart_init_preirq(struct serial_port *port)
>      omap_write(uart, UART_MCR, UART_MCR_DTR|UART_MCR_RTS);
>  
>      omap_write(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
> +
> +    /* setup iddle mode */
> +    omap_write(uart, UART_SYSC, OMAP_UART_SYSC_DEF_CONF);
>  }
>  
>  static void __init omap_uart_init_postirq(struct serial_port *port)
> diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
> index a682bae..304b9dd 100644
> --- a/xen/include/xen/8250-uart.h
> +++ b/xen/include/xen/8250-uart.h
> @@ -32,6 +32,7 @@
>  #define UART_MCR          0x04    /* Modem control        */
>  #define UART_LSR          0x05    /* line status          */
>  #define UART_MSR          0x06    /* Modem status         */
> +#define UART_SYSC         0x15    /* System configuration register */
>  #define UART_USR          0x1f    /* Status register (DW) */
>  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
>  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
> @@ -145,6 +146,9 @@
>  /* SCR register bitmasks */
>  #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 << 7)
>  
> +/* System configuration register */
> +#define OMAP_UART_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is enabled */
> +
>  #endif /* __XEN_8250_UART_H__ */
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:48:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:48:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyM4e-0006kR-EZ; Tue, 09 Dec 2014 14:47: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 1XyM4d-0006kM-Cx
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:47:35 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	01/A8-02696-68B07845; Tue, 09 Dec 2014 14:47:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418136452!13959458!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11674 invoked from network); 9 Dec 2014 14:47:33 -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;
	9 Dec 2014 14:47:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202308090"
Message-ID: <1418136450.14361.82.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>, "Konrad
	Rzeszutek Wilk" <konrad.wilk@oracle.com>
Date: Tue, 9 Dec 2014 14:47:30 +0000
In-Reply-To: <1418046707-6900-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
References: <1418046707-6900-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Stefano Stabellini <stefano.stabellini@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-08 at 15:51 +0200, Oleksandr Dmytryshyn wrote:
> UART is not able to receive bytes when idle mode is not
> configured properly. When we use Xen with old Linux
> Kernel (for example 3.8) this kernel configures hwmods
> for all devices even if the device tree nodes for those
> devices is absent in device tree. Thus UART idle mode
> is configured too. The fake node for the UART should
> be added to the device tree because the MMIO range
> is not mapped by Xen. So UART works normally in this
> case. But new Linux Kernel (3.12 and upper) doesn't
> configure idle mode for UART and UART can not work
> normally in this case.

I think the focus is too much on the hack done with 3.8 to make this
work rather than on the fix being made here itself. The hack is only
really of peripheral/historic interest.

How about instead:

        The UART is not able to receive bytes when idle mode is not
        configured properly, therefore setup the UART with autoidle and
        wakeup enabled.
        
You could stop here or if you really want to cover the old hack you
could go on to say:
     
        Older Linux kernels (for example 3.8) configures hwmods for all
        devices even if the device tree nodes for those devices is
        absent in device tree, thus UART idle mode is configured too.
        With such kernels we can workaround the issue by adding a fake
        node in the UART containing this MMIO range, which is therefore
        mapped by Xen to dom0, which reconfigures the UART, causing
        things to work normally.
        
        Newer Linux Kernels (3.12 and beyond) do not configure idle mode
        for UART and so this hack no longer works.
        
If you are happy with the proposed wording (and indicate whether you
want both bits or just the first) then, subject to Konrad giving a
release Ack I'd be happy with this for 4.5 and I'll change the commit
log as I go.

Konrad, this is a bug fix for a particular piece of hardware, it can't
affect anything other than the OMAP ARM platform.


> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>

> ---
> Changed since v1:
>  * corrected commit message
> 
>  xen/drivers/char/omap-uart.c | 3 +++
>  xen/include/xen/8250-uart.h  | 4 ++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
> index a798b8d..16d1454 100644
> --- a/xen/drivers/char/omap-uart.c
> +++ b/xen/drivers/char/omap-uart.c
> @@ -195,6 +195,9 @@ static void __init omap_uart_init_preirq(struct serial_port *port)
>      omap_write(uart, UART_MCR, UART_MCR_DTR|UART_MCR_RTS);
>  
>      omap_write(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
> +
> +    /* setup iddle mode */
> +    omap_write(uart, UART_SYSC, OMAP_UART_SYSC_DEF_CONF);
>  }
>  
>  static void __init omap_uart_init_postirq(struct serial_port *port)
> diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
> index a682bae..304b9dd 100644
> --- a/xen/include/xen/8250-uart.h
> +++ b/xen/include/xen/8250-uart.h
> @@ -32,6 +32,7 @@
>  #define UART_MCR          0x04    /* Modem control        */
>  #define UART_LSR          0x05    /* line status          */
>  #define UART_MSR          0x06    /* Modem status         */
> +#define UART_SYSC         0x15    /* System configuration register */
>  #define UART_USR          0x1f    /* Status register (DW) */
>  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
>  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
> @@ -145,6 +146,9 @@
>  /* SCR register bitmasks */
>  #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 << 7)
>  
> +/* System configuration register */
> +#define OMAP_UART_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is enabled */
> +
>  #endif /* __XEN_8250_UART_H__ */
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:48:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:48:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyM5U-0006o7-1u; Tue, 09 Dec 2014 14:48: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 1XyM5S-0006nv-GI
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:48:26 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	C0/13-02954-9BB07845; Tue, 09 Dec 2014 14:48:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418136503!13960503!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 23746 invoked from network); 9 Dec 2014 14:48:25 -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;
	9 Dec 2014 14:48:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201906051"
Message-ID: <1418136501.14361.83.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Tue, 9 Dec 2014 14:48:21 +0000
In-Reply-To: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
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] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-09 at 14:04 +0000, George Dunlap wrote:
> At the moment libxl unconditinally passes the underlying file format
> to qemu in the device string.  However, when tapdisk is in use,
> tapdisk handles the underlying format and presents qemu with
> effectively a raw disk.  When qemu looks at the tapdisk block device
> and doesn't find the image format it was looking for, it will fail.
> 
> This effectively means that tapdisk cannot be used with HVM domains at
> the moment except for raw files.
> 
> Instead, if we're using a tapdisk backend, tell qemu to use a raw file
> format.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@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 exception justification:

I agree with your reasoning.

>  This fixes a bug in functionality, in
> that at the moment HVM guests cannot boot with tapdisk and vhd format.
> 
> This is not a regression in xl functionality per se, since (AFAICT)
> this has never worked.  However, given that 4.5 is the first release
> without xend, this *does* represent a regression in functionality for
> Xen as a whole (since before people using hvm guest with vhd on blktap
> could use xend).
> 
> The fix is very simple and should only affect codepaths that already
> don't work, so the risk of regressions should be very low.
> 
> While preparing this patch, I also noticed that cdroms will ignore the
> backend parameter and treat everything as a file.  This is a bug but I
> think it's a much less important one to address this late in the
> release cycle.
> ---
>  tools/libxl/libxl_dm.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index b25b574..10f3090 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -797,11 +797,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                      continue;
>                  }
>  
> -                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP)
> +                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP) {
> +                    format = qemu_disk_format_string(LIBXL_DISK_FORMAT_RAW);
>                      pdev_path = libxl__blktap_devpath(gc, disks[i].pdev_path,
>                                                        disks[i].format);
> -                else
> +                } else {
>                      pdev_path = disks[i].pdev_path;
> +                }
> +
>  
>                  /*
>                   * Explicit sd disks are passed through as is.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 14:48:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 14:48:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyM5U-0006o7-1u; Tue, 09 Dec 2014 14:48: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 1XyM5S-0006nv-GI
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 14:48:26 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	C0/13-02954-9BB07845; Tue, 09 Dec 2014 14:48:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418136503!13960503!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 23746 invoked from network); 9 Dec 2014 14:48:25 -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;
	9 Dec 2014 14:48:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201906051"
Message-ID: <1418136501.14361.83.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Tue, 9 Dec 2014 14:48:21 +0000
In-Reply-To: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
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] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-09 at 14:04 +0000, George Dunlap wrote:
> At the moment libxl unconditinally passes the underlying file format
> to qemu in the device string.  However, when tapdisk is in use,
> tapdisk handles the underlying format and presents qemu with
> effectively a raw disk.  When qemu looks at the tapdisk block device
> and doesn't find the image format it was looking for, it will fail.
> 
> This effectively means that tapdisk cannot be used with HVM domains at
> the moment except for raw files.
> 
> Instead, if we're using a tapdisk backend, tell qemu to use a raw file
> format.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@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 exception justification:

I agree with your reasoning.

>  This fixes a bug in functionality, in
> that at the moment HVM guests cannot boot with tapdisk and vhd format.
> 
> This is not a regression in xl functionality per se, since (AFAICT)
> this has never worked.  However, given that 4.5 is the first release
> without xend, this *does* represent a regression in functionality for
> Xen as a whole (since before people using hvm guest with vhd on blktap
> could use xend).
> 
> The fix is very simple and should only affect codepaths that already
> don't work, so the risk of regressions should be very low.
> 
> While preparing this patch, I also noticed that cdroms will ignore the
> backend parameter and treat everything as a file.  This is a bug but I
> think it's a much less important one to address this late in the
> release cycle.
> ---
>  tools/libxl/libxl_dm.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index b25b574..10f3090 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -797,11 +797,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                      continue;
>                  }
>  
> -                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP)
> +                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP) {
> +                    format = qemu_disk_format_string(LIBXL_DISK_FORMAT_RAW);
>                      pdev_path = libxl__blktap_devpath(gc, disks[i].pdev_path,
>                                                        disks[i].format);
> -                else
> +                } else {
>                      pdev_path = disks[i].pdev_path;
> +                }
> +
>  
>                  /*
>                   * Explicit sd disks are passed through as is.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:02:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15:02:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyMIF-0007Yz-6n; Tue, 09 Dec 2014 15:01:39 +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 1XyMID-0007YR-Jw
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:01:37 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	1E/E1-17958-0DE07845; Tue, 09 Dec 2014 15:01:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418137293!12093051!1
X-Originating-IP: [66.165.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 24654 invoked from network); 9 Dec 2014 15:01:35 -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;
	9 Dec 2014 15:01:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201911856"
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.210.2; Tue, 9 Dec 2014 10:01: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 1XyMHu-0001j1-OY;
	Tue, 09 Dec 2014 15:01:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyMHu-0001TR-JI;
	Tue, 09 Dec 2014 15:01:18 +0000
Date: Tue, 9 Dec 2014 15:01:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32153-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] 32153: tolerable trouble:
	broken/fail/pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32153 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32153/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt      3 host-install(3)           broken pass in 32139
 test-armhf-armhf-xl           4 xen-install        fail in 32139 pass in 32153
 test-amd64-i386-xl-win7-amd64  5 xen-boot          fail in 32139 pass in 32153

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32093

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-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-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-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-i386-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-libvirt      9 guest-start           fail in 32139 never pass

version targeted for testing:
 xen                  10e7747bca538205555e313574432f231070153b
baseline version:
 xen                  3a80985b894f54eb3b2e143e4dea737cf139a517

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Chunyan Liu <cyliu@suse.com>
  Daniel Kiper <daniel.kiper@oracle.com>
  Don Dugger <donald.d.dugger@intel.com>
  Euan Harris <euan.harris@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>
  Kevin Tian <kevin.tian@intel.com>
  M A Young <m.a.young@durham.ac.uk>
  Michael Young <m.a.young@durham.ac.uk>
  Olaf Hering <olaf@aepfle.de>
  Razvan Cojocaru <rcojocaru@bitdefender.com>
  Tim Deegan <tim@xen.org>
  Vitaly Kuznetsov <vkuznets@redhat.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                                          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                                     broken  
 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-libvirt host-install(3)

Pushing revision :

+ branch=xen-unstable
+ revision=10e7747bca538205555e313574432f231070153b
+ . 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 10e7747bca538205555e313574432f231070153b
+ branch=xen-unstable
+ revision=10e7747bca538205555e313574432f231070153b
+ . 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 10e7747bca538205555e313574432f231070153b:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   3a80985..10e7747  10e7747bca538205555e313574432f231070153b -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:02:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15:02:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyMIF-0007Yz-6n; Tue, 09 Dec 2014 15:01:39 +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 1XyMID-0007YR-Jw
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:01:37 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	1E/E1-17958-0DE07845; Tue, 09 Dec 2014 15:01:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418137293!12093051!1
X-Originating-IP: [66.165.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 24654 invoked from network); 9 Dec 2014 15:01:35 -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;
	9 Dec 2014 15:01:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201911856"
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.210.2; Tue, 9 Dec 2014 10:01: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 1XyMHu-0001j1-OY;
	Tue, 09 Dec 2014 15:01:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyMHu-0001TR-JI;
	Tue, 09 Dec 2014 15:01:18 +0000
Date: Tue, 9 Dec 2014 15:01:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32153-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] 32153: tolerable trouble:
	broken/fail/pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32153 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32153/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt      3 host-install(3)           broken pass in 32139
 test-armhf-armhf-xl           4 xen-install        fail in 32139 pass in 32153
 test-amd64-i386-xl-win7-amd64  5 xen-boot          fail in 32139 pass in 32153

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32093

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-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-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-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-i386-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-libvirt      9 guest-start           fail in 32139 never pass

version targeted for testing:
 xen                  10e7747bca538205555e313574432f231070153b
baseline version:
 xen                  3a80985b894f54eb3b2e143e4dea737cf139a517

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Chunyan Liu <cyliu@suse.com>
  Daniel Kiper <daniel.kiper@oracle.com>
  Don Dugger <donald.d.dugger@intel.com>
  Euan Harris <euan.harris@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>
  Kevin Tian <kevin.tian@intel.com>
  M A Young <m.a.young@durham.ac.uk>
  Michael Young <m.a.young@durham.ac.uk>
  Olaf Hering <olaf@aepfle.de>
  Razvan Cojocaru <rcojocaru@bitdefender.com>
  Tim Deegan <tim@xen.org>
  Vitaly Kuznetsov <vkuznets@redhat.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                                          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                                     broken  
 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-libvirt host-install(3)

Pushing revision :

+ branch=xen-unstable
+ revision=10e7747bca538205555e313574432f231070153b
+ . 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 10e7747bca538205555e313574432f231070153b
+ branch=xen-unstable
+ revision=10e7747bca538205555e313574432f231070153b
+ . 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 10e7747bca538205555e313574432f231070153b:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   3a80985..10e7747  10e7747bca538205555e313574432f231070153b -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyMOo-0008Kh-Ch; Tue, 09 Dec 2014 15:08:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyMOm-0008Kc-LS
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 15:08:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	78/49-15461-76017845; Tue, 09 Dec 2014 15:08:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418137700!14386087!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 30325 invoked from network); 9 Dec 2014 15:08: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;
	9 Dec 2014 15:08:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201914984"
Message-ID: <1418137591.19809.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 9 Dec 2014 15:06:31 +0000
In-Reply-To: <20141205171907.GD2301@laptop.dumpdata.com>
References: <1417776587-26018-1-git-send-email-olaf@aepfle.de>
	<1417776783.22808.55.camel@citrix.com>
	<20141205171907.GD2301@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/xenstore: fix link error with
	libsystemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 12:19 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 05, 2014 at 10:53:03AM +0000, Ian Campbell wrote:
> > On Fri, 2014-12-05 at 11:49 +0100, Olaf Hering wrote:
> > > Linking fails with undefined reference to the used systemd functions.
> > > Move LDFLAGS after the object files to fix the failure.
> > > 
> > > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > This should go into 4.5.
> 
> 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 Dec 09 15:08:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyMOo-0008Kh-Ch; Tue, 09 Dec 2014 15:08:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyMOm-0008Kc-LS
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 15:08:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	78/49-15461-76017845; Tue, 09 Dec 2014 15:08:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418137700!14386087!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 30325 invoked from network); 9 Dec 2014 15:08: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;
	9 Dec 2014 15:08:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201914984"
Message-ID: <1418137591.19809.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 9 Dec 2014 15:06:31 +0000
In-Reply-To: <20141205171907.GD2301@laptop.dumpdata.com>
References: <1417776587-26018-1-git-send-email-olaf@aepfle.de>
	<1417776783.22808.55.camel@citrix.com>
	<20141205171907.GD2301@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/xenstore: fix link error with
	libsystemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 12:19 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 05, 2014 at 10:53:03AM +0000, Ian Campbell wrote:
> > On Fri, 2014-12-05 at 11:49 +0100, Olaf Hering wrote:
> > > Linking fails with undefined reference to the used systemd functions.
> > > Move LDFLAGS after the object files to fix the failure.
> > > 
> > > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > This should go into 4.5.
> 
> 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 Dec 09 15:09:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyMPS-0008NC-QH; Tue, 09 Dec 2014 15:09: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 1XyMPQ-0008N4-Ty
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 15:09:05 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	03/6B-02576-09017845; Tue, 09 Dec 2014 15:09:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418137741!13956233!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16873 invoked from network); 9 Dec 2014 15:09:03 -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;
	9 Dec 2014 15:09:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201915372"
Message-ID: <1418137618.19809.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 9 Dec 2014 15:06:58 +0000
In-Reply-To: <1417776878.22808.56.camel@citrix.com>
References: <1417721215-32639-1-git-send-email-julien.grall@linaro.org>
	<20141204193434.GB6225@laptop.dumpdata.com>
	<1417776878.22808.56.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Correct the opcode for
 BUG_INSTR on arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-05 at 10:54 +0000, Ian Campbell wrote:
> > > Not sure, why I dropped the 0 when I implemented the patch...
> > > This is a bug fixed for Xen 4.5. This is only affected ARM32 where the
> > > BUG opcode was malformed.
> > > 
> > > With the malformed opcode, the ASSERT/BUG_ON is skipped and the
> > > processor may execute another patch (because the compiler has optimized
> > 
> > s/patch/path/ ?
> 
> Will fix on commit.

Oh, this isn't in the main body of the commit log.
> 
> > > due the unreachable in both macro).
> > > 
> > > The code modified is only executed when Xen is in bad state.
> > 
> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied (with no changes).



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:09:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyMPU-0008Nd-7y; Tue, 09 Dec 2014 15:09: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 1XyMPS-0008NB-Sg
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 15:09:06 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	96/58-02707-29017845; Tue, 09 Dec 2014 15:09:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418137743!8261684!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3543 invoked from network); 9 Dec 2014 15:09:05 -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;
	9 Dec 2014 15:09:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202318345"
Message-ID: <1418137631.19809.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 9 Dec 2014 15:07:11 +0000
In-Reply-To: <20141208160730.GH7745@laptop.dumpdata.com>
References: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1418032087.11028.5.camel@citrix.com>
	<20141208155205.GC7745@laptop.dumpdata.com>
	<1418054046.2827.18.camel@citrix.com>
	<20141208160730.GH7745@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] flask/policy: Example policy
 updates for migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-08 at 11:07 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 08, 2014 at 03:54:06PM +0000, Ian Campbell wrote:
> > On Mon, 2014-12-08 at 10:52 -0500, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Dec 08, 2014 at 09:48:07AM +0000, Ian Campbell wrote:
> > > > On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> > > > > The example XSM policy was missing permission for dom0_t to migrate
> > > > > domains; add these permissions.
> > > > > 
> > > > > Reported-by: Wei Liu <wei.liu2@citrix.com>
> > > > > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > > > 
> > > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > > > 
> > > > Konrad, we should take this for 4.5, in order to have a working example
> > > > XSM policy. There's 0 risk to non-XSM systems, or systems with custom
> > > 
> > > Thought this looks like it never worked in the past then? As in, this
> > > is not a regression but a bug that had existed for quite a while?
> > 
> > AIUI it has worked in the past, i.e. I remember applying other series
> > from Daniel to fix it for previous releases. This patch is the policy
> > catching up with the developments during 4.5.
> 
> OK then definilty 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 Tue Dec 09 15:09:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyMPS-0008NC-QH; Tue, 09 Dec 2014 15:09: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 1XyMPQ-0008N4-Ty
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 15:09:05 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	03/6B-02576-09017845; Tue, 09 Dec 2014 15:09:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418137741!13956233!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16873 invoked from network); 9 Dec 2014 15:09:03 -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;
	9 Dec 2014 15:09:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201915372"
Message-ID: <1418137618.19809.4.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 9 Dec 2014 15:06:58 +0000
In-Reply-To: <1417776878.22808.56.camel@citrix.com>
References: <1417721215-32639-1-git-send-email-julien.grall@linaro.org>
	<20141204193434.GB6225@laptop.dumpdata.com>
	<1417776878.22808.56.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for-4.5] xen/arm: Correct the opcode for
 BUG_INSTR on arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-05 at 10:54 +0000, Ian Campbell wrote:
> > > Not sure, why I dropped the 0 when I implemented the patch...
> > > This is a bug fixed for Xen 4.5. This is only affected ARM32 where the
> > > BUG opcode was malformed.
> > > 
> > > With the malformed opcode, the ASSERT/BUG_ON is skipped and the
> > > processor may execute another patch (because the compiler has optimized
> > 
> > s/patch/path/ ?
> 
> Will fix on commit.

Oh, this isn't in the main body of the commit log.
> 
> > > due the unreachable in both macro).
> > > 
> > > The code modified is only executed when Xen is in bad state.
> > 
> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied (with no changes).



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:09:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyMPU-0008Nd-7y; Tue, 09 Dec 2014 15:09: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 1XyMPS-0008NB-Sg
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 15:09:06 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	96/58-02707-29017845; Tue, 09 Dec 2014 15:09:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418137743!8261684!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3543 invoked from network); 9 Dec 2014 15:09:05 -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;
	9 Dec 2014 15:09:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202318345"
Message-ID: <1418137631.19809.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 9 Dec 2014 15:07:11 +0000
In-Reply-To: <20141208160730.GH7745@laptop.dumpdata.com>
References: <1417798987-10325-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1418032087.11028.5.camel@citrix.com>
	<20141208155205.GC7745@laptop.dumpdata.com>
	<1418054046.2827.18.camel@citrix.com>
	<20141208160730.GH7745@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] flask/policy: Example policy
 updates for migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-08 at 11:07 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 08, 2014 at 03:54:06PM +0000, Ian Campbell wrote:
> > On Mon, 2014-12-08 at 10:52 -0500, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Dec 08, 2014 at 09:48:07AM +0000, Ian Campbell wrote:
> > > > On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> > > > > The example XSM policy was missing permission for dom0_t to migrate
> > > > > domains; add these permissions.
> > > > > 
> > > > > Reported-by: Wei Liu <wei.liu2@citrix.com>
> > > > > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > > > 
> > > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > > > 
> > > > Konrad, we should take this for 4.5, in order to have a working example
> > > > XSM policy. There's 0 risk to non-XSM systems, or systems with custom
> > > 
> > > Thought this looks like it never worked in the past then? As in, this
> > > is not a regression but a bug that had existed for quite a while?
> > 
> > AIUI it has worked in the past, i.e. I remember applying other series
> > from Daniel to fix it for previous releases. This patch is the policy
> > catching up with the developments during 4.5.
> 
> OK then definilty 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 Tue Dec 09 15:26:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyMfQ-0000ss-5I; Tue, 09 Dec 2014 15:25:36 +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 1XyMfO-0000rs-5J
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 15:25:34 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	31/03-02953-D6417845; Tue, 09 Dec 2014 15:25:33 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418138730!13880307!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21344 invoked from network); 9 Dec 2014 15:25:32 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 15:25:32 -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 DSNKVIcUaVjpHgX8+l1ZZEOLiC00kTwikZXJ@postini.com;
	Tue, 09 Dec 2014 07:25:31 PST
Received: by mail-qc0-f178.google.com with SMTP id b13so614910qcw.23
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 07:25: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=i73Nm7jbekb/EmHKfeRf/8dzcFQ70iorgW1zzUMsFAw=;
	b=YrSh5P0zW7owewys4QwgTCIQCw3g2Qb7n9qiV4Xtd9BAuHfsH6liuCp7OXG6AREW6O
	vFKCJ2zzB4nKh/s/h5nLp+Ma0VYvC8Mw65Hf8MnVJU33dS0KcR1Ax5rBUdE/1UX9PDQJ
	aDLOKYzMjpueIQPTIcrmrHKIOUHF7rc9fd/XE=
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=i73Nm7jbekb/EmHKfeRf/8dzcFQ70iorgW1zzUMsFAw=;
	b=NsAsI8xhDDQvP/Rm19+32iSSht2XZp7xbelStNWaC/7qSeQManEKxqcNoovd169Tq8
	2vqg+i1mL57CPvYoPzfHvcKxWUgh1TJlflFzd/DOc5wl9jJ9IDrdqS8LAwMRbrYrTYon
	7WtVrqaxlzEh5zw1nCXQ3WfN8Ud5byspX0cuDehGQAiPVuzzTcAsEESPjN1h8ZaFJJLh
	4Gr/tzMhl27x/0LXEkhDVwFAT7KK+eOWGorsdYYEqIv/ijOY+8rUHSqCZ7jNSFcwhVA6
	rs9JiYPIWlzkFCYQkNrh2/76LNPoIGt94XTTu3VFdXmTepwm/+Nyd0u+YJVq7qEhGtsH
	xsdA==
X-Gm-Message-State: ALoCoQm/2DXzNCBCfBCdylNtSrzkQTd0UFHXVBk1QI6kGgeK6tHzVKzQBxUbP5lnZiR2p1hCERJlHEWV3f1eoUJLpSbnfeGmXMKRVr1vAkcGJL1i6YNRiYh85bF0n+jj06fJfD76Ljq1i+fcpC3IXU1SxVZKHstg3Q==
X-Received: by 10.229.63.71 with SMTP id a7mr6612129qci.24.1418138729216;
	Tue, 09 Dec 2014 07:25:29 -0800 (PST)
X-Received: by 10.229.63.71 with SMTP id a7mr6612093qci.24.1418138729032; Tue,
	09 Dec 2014 07:25:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.93.69 with HTTP; Tue, 9 Dec 2014 07:25:08 -0800 (PST)
In-Reply-To: <1418136450.14361.82.camel@citrix.com>
References: <1418046707-6900-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1418136450.14361.82.camel@citrix.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Tue, 9 Dec 2014 17:25:08 +0200
Message-ID: <CAN58jisYpvQLDwCmcg0CFHf_HurgtwtHVkH3=QyOP-JjgBczOA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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] [PATCH v2] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 9, 2014 at 4:47 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2014-12-08 at 15:51 +0200, Oleksandr Dmytryshyn wrote:
>> UART is not able to receive bytes when idle mode is not
>> configured properly. When we use Xen with old Linux
>> Kernel (for example 3.8) this kernel configures hwmods
>> for all devices even if the device tree nodes for those
>> devices is absent in device tree. Thus UART idle mode
>> is configured too. The fake node for the UART should
>> be added to the device tree because the MMIO range
>> is not mapped by Xen. So UART works normally in this
>> case. But new Linux Kernel (3.12 and upper) doesn't
>> configure idle mode for UART and UART can not work
>> normally in this case.
>
> I think the focus is too much on the hack done with 3.8 to make this
> work rather than on the fix being made here itself. The hack is only
> really of peripheral/historic interest.
>
> How about instead:
>
>         The UART is not able to receive bytes when idle mode is not
>         configured properly, therefore setup the UART with autoidle and
>         wakeup enabled.
>
> You could stop here or if you really want to cover the old hack you
> could go on to say:
>
>         Older Linux kernels (for example 3.8) configures hwmods for all
>         devices even if the device tree nodes for those devices is
>         absent in device tree, thus UART idle mode is configured too.
>         With such kernels we can workaround the issue by adding a fake
>         node in the UART containing this MMIO range, which is therefore
>         mapped by Xen to dom0, which reconfigures the UART, causing
>         things to work normally.
>
>         Newer Linux Kernels (3.12 and beyond) do not configure idle mode
>         for UART and so this hack no longer works.
>
> If you are happy with the proposed wording (and indicate whether you
> want both bits or just the first) then, subject to Konrad giving a
> release Ack I'd be happy with this for 4.5 and I'll change the commit
> log as I go.
I'm fully happy with proposed wording (and want the both bits to be used)

> Konrad, this is a bug fix for a particular piece of hardware, it can't
> affect anything other than the OMAP ARM platform.
>
>
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>
>> ---
>> Changed since v1:
>>  * corrected commit message
>>
>>  xen/drivers/char/omap-uart.c | 3 +++
>>  xen/include/xen/8250-uart.h  | 4 ++++
>>  2 files changed, 7 insertions(+)
>>
>> diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
>> index a798b8d..16d1454 100644
>> --- a/xen/drivers/char/omap-uart.c
>> +++ b/xen/drivers/char/omap-uart.c
>> @@ -195,6 +195,9 @@ static void __init omap_uart_init_preirq(struct serial_port *port)
>>      omap_write(uart, UART_MCR, UART_MCR_DTR|UART_MCR_RTS);
>>
>>      omap_write(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
>> +
>> +    /* setup iddle mode */
>> +    omap_write(uart, UART_SYSC, OMAP_UART_SYSC_DEF_CONF);
>>  }
>>
>>  static void __init omap_uart_init_postirq(struct serial_port *port)
>> diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
>> index a682bae..304b9dd 100644
>> --- a/xen/include/xen/8250-uart.h
>> +++ b/xen/include/xen/8250-uart.h
>> @@ -32,6 +32,7 @@
>>  #define UART_MCR          0x04    /* Modem control        */
>>  #define UART_LSR          0x05    /* line status          */
>>  #define UART_MSR          0x06    /* Modem status         */
>> +#define UART_SYSC         0x15    /* System configuration register */
>>  #define UART_USR          0x1f    /* Status register (DW) */
>>  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
>>  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
>> @@ -145,6 +146,9 @@
>>  /* SCR register bitmasks */
>>  #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 << 7)
>>
>> +/* System configuration register */
>> +#define OMAP_UART_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is enabled */
>> +
>>  #endif /* __XEN_8250_UART_H__ */
>>
>>  /*
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:26:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyMfQ-0000ss-5I; Tue, 09 Dec 2014 15:25:36 +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 1XyMfO-0000rs-5J
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 15:25:34 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	31/03-02953-D6417845; Tue, 09 Dec 2014 15:25:33 +0000
X-Env-Sender: oleksandr.dmytryshyn@globallogic.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418138730!13880307!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21344 invoked from network); 9 Dec 2014 15:25:32 -0000
Received: from exprod5og122.obsmtp.com (HELO exprod5og122.obsmtp.com)
	(64.18.0.192)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 15:25:32 -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 DSNKVIcUaVjpHgX8+l1ZZEOLiC00kTwikZXJ@postini.com;
	Tue, 09 Dec 2014 07:25:31 PST
Received: by mail-qc0-f178.google.com with SMTP id b13so614910qcw.23
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 07:25: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=i73Nm7jbekb/EmHKfeRf/8dzcFQ70iorgW1zzUMsFAw=;
	b=YrSh5P0zW7owewys4QwgTCIQCw3g2Qb7n9qiV4Xtd9BAuHfsH6liuCp7OXG6AREW6O
	vFKCJ2zzB4nKh/s/h5nLp+Ma0VYvC8Mw65Hf8MnVJU33dS0KcR1Ax5rBUdE/1UX9PDQJ
	aDLOKYzMjpueIQPTIcrmrHKIOUHF7rc9fd/XE=
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=i73Nm7jbekb/EmHKfeRf/8dzcFQ70iorgW1zzUMsFAw=;
	b=NsAsI8xhDDQvP/Rm19+32iSSht2XZp7xbelStNWaC/7qSeQManEKxqcNoovd169Tq8
	2vqg+i1mL57CPvYoPzfHvcKxWUgh1TJlflFzd/DOc5wl9jJ9IDrdqS8LAwMRbrYrTYon
	7WtVrqaxlzEh5zw1nCXQ3WfN8Ud5byspX0cuDehGQAiPVuzzTcAsEESPjN1h8ZaFJJLh
	4Gr/tzMhl27x/0LXEkhDVwFAT7KK+eOWGorsdYYEqIv/ijOY+8rUHSqCZ7jNSFcwhVA6
	rs9JiYPIWlzkFCYQkNrh2/76LNPoIGt94XTTu3VFdXmTepwm/+Nyd0u+YJVq7qEhGtsH
	xsdA==
X-Gm-Message-State: ALoCoQm/2DXzNCBCfBCdylNtSrzkQTd0UFHXVBk1QI6kGgeK6tHzVKzQBxUbP5lnZiR2p1hCERJlHEWV3f1eoUJLpSbnfeGmXMKRVr1vAkcGJL1i6YNRiYh85bF0n+jj06fJfD76Ljq1i+fcpC3IXU1SxVZKHstg3Q==
X-Received: by 10.229.63.71 with SMTP id a7mr6612129qci.24.1418138729216;
	Tue, 09 Dec 2014 07:25:29 -0800 (PST)
X-Received: by 10.229.63.71 with SMTP id a7mr6612093qci.24.1418138729032; Tue,
	09 Dec 2014 07:25:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.93.69 with HTTP; Tue, 9 Dec 2014 07:25:08 -0800 (PST)
In-Reply-To: <1418136450.14361.82.camel@citrix.com>
References: <1418046707-6900-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1418136450.14361.82.camel@citrix.com>
From: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date: Tue, 9 Dec 2014 17:25:08 +0200
Message-ID: <CAN58jisYpvQLDwCmcg0CFHf_HurgtwtHVkH3=QyOP-JjgBczOA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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] [PATCH v2] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 9, 2014 at 4:47 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2014-12-08 at 15:51 +0200, Oleksandr Dmytryshyn wrote:
>> UART is not able to receive bytes when idle mode is not
>> configured properly. When we use Xen with old Linux
>> Kernel (for example 3.8) this kernel configures hwmods
>> for all devices even if the device tree nodes for those
>> devices is absent in device tree. Thus UART idle mode
>> is configured too. The fake node for the UART should
>> be added to the device tree because the MMIO range
>> is not mapped by Xen. So UART works normally in this
>> case. But new Linux Kernel (3.12 and upper) doesn't
>> configure idle mode for UART and UART can not work
>> normally in this case.
>
> I think the focus is too much on the hack done with 3.8 to make this
> work rather than on the fix being made here itself. The hack is only
> really of peripheral/historic interest.
>
> How about instead:
>
>         The UART is not able to receive bytes when idle mode is not
>         configured properly, therefore setup the UART with autoidle and
>         wakeup enabled.
>
> You could stop here or if you really want to cover the old hack you
> could go on to say:
>
>         Older Linux kernels (for example 3.8) configures hwmods for all
>         devices even if the device tree nodes for those devices is
>         absent in device tree, thus UART idle mode is configured too.
>         With such kernels we can workaround the issue by adding a fake
>         node in the UART containing this MMIO range, which is therefore
>         mapped by Xen to dom0, which reconfigures the UART, causing
>         things to work normally.
>
>         Newer Linux Kernels (3.12 and beyond) do not configure idle mode
>         for UART and so this hack no longer works.
>
> If you are happy with the proposed wording (and indicate whether you
> want both bits or just the first) then, subject to Konrad giving a
> release Ack I'd be happy with this for 4.5 and I'll change the commit
> log as I go.
I'm fully happy with proposed wording (and want the both bits to be used)

> Konrad, this is a bug fix for a particular piece of hardware, it can't
> affect anything other than the OMAP ARM platform.
>
>
>> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
>
>> ---
>> Changed since v1:
>>  * corrected commit message
>>
>>  xen/drivers/char/omap-uart.c | 3 +++
>>  xen/include/xen/8250-uart.h  | 4 ++++
>>  2 files changed, 7 insertions(+)
>>
>> diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
>> index a798b8d..16d1454 100644
>> --- a/xen/drivers/char/omap-uart.c
>> +++ b/xen/drivers/char/omap-uart.c
>> @@ -195,6 +195,9 @@ static void __init omap_uart_init_preirq(struct serial_port *port)
>>      omap_write(uart, UART_MCR, UART_MCR_DTR|UART_MCR_RTS);
>>
>>      omap_write(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
>> +
>> +    /* setup iddle mode */
>> +    omap_write(uart, UART_SYSC, OMAP_UART_SYSC_DEF_CONF);
>>  }
>>
>>  static void __init omap_uart_init_postirq(struct serial_port *port)
>> diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
>> index a682bae..304b9dd 100644
>> --- a/xen/include/xen/8250-uart.h
>> +++ b/xen/include/xen/8250-uart.h
>> @@ -32,6 +32,7 @@
>>  #define UART_MCR          0x04    /* Modem control        */
>>  #define UART_LSR          0x05    /* line status          */
>>  #define UART_MSR          0x06    /* Modem status         */
>> +#define UART_SYSC         0x15    /* System configuration register */
>>  #define UART_USR          0x1f    /* Status register (DW) */
>>  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
>>  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
>> @@ -145,6 +146,9 @@
>>  /* SCR register bitmasks */
>>  #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 << 7)
>>
>> +/* System configuration register */
>> +#define OMAP_UART_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is enabled */
>> +
>>  #endif /* __XEN_8250_UART_H__ */
>>
>>  /*
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:32:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyMm8-0001ND-D3; Tue, 09 Dec 2014 15:32:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1XyMm7-0001Mt-DO
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 15:32:31 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	91/03-22819-E0617845; Tue, 09 Dec 2014 15:32:30 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418139148!8267549!1
X-Originating-IP: [140.211.169.12]
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 31975 invoked from network); 9 Dec 2014 15:32:30 -0000
Received: from mail.linuxfoundation.org (HELO mail.linuxfoundation.org)
	(140.211.169.12)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2014 15:32:30 -0000
Received: from localhost (c-76-24-48-141.hsd1.nh.comcast.net [76.24.48.141])
	by mail.linuxfoundation.org (Postfix) with ESMTPSA id B734FA7A;
	Tue,  9 Dec 2014 15:32:27 +0000 (UTC)
Date: Tue, 9 Dec 2014 10:32:26 -0500
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141209153226.GA29841@kroah.com>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
	<1417788483-662-2-git-send-email-david.vrabel@citrix.com>
	<20141205213113.GB3012@kroah.com> <54857F1E.1010506@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54857F1E.1010506@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: 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/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

On Mon, Dec 08, 2014 at 10:36:14AM +0000, David Vrabel wrote:
> On 05/12/14 21:31, Greg Kroah-Hartman wrote:
> > On Fri, Dec 05, 2014 at 02:08:00PM +0000, David Vrabel wrote:
> >> 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 ++++++++--
> > 
> > Is this why you sent this to me?  The x86 maintainers should handle this
> > patch set, not me for a tiny 8 lines in just one of the files, sorry.
> 
> This series will be merged via the Xen tree, but this patch still needs
> your review or ack.

How about waiting until after the merge window and resending it, asking
for that, instead of making me guess :)

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:32:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyMm4-0001ML-12; Tue, 09 Dec 2014 15:32:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyMm1-0001LH-WA
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 15:32:26 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	11/00-02957-90617845; Tue, 09 Dec 2014 15:32:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418139142!13981364!1
X-Originating-IP: [66.165.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 17542 invoked from network); 9 Dec 2014 15:32:24 -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;
	9 Dec 2014 15:32:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201931582"
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.210.2;
	Tue, 9 Dec 2014 10:25: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 1XyMfK-0005Kf-2F;
	Tue, 09 Dec 2014 15:25:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyMfJ-0004Az-Pf;
	Tue, 09 Dec 2014 15:25:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21639.5225.596115.600016@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 15:25:29 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
In-Reply-To: <1417600430.11243.1.camel@citrix.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com>
	<547DC617.8020107@citrix.com>
	<CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
	<1417600430.11243.1.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ed Swierk <eswierk@skyportsystems.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with bison 3.0"):
> There was a point in time where the prevailing version of bison (or
> maybe flex) in stable distro releases had a bug which meant these files
> could not be regenerated easily on common distros. I don't recall the
> details well enough to know if that time has now passed. Perhaps Ian J
> does.

We use (essential) features found only in non-ancient versions of
bison and flex.  The last time it was proposed to remove these
pregenerated files, there were complaints from people who were using
six-year-old bison and flex.

I think we should prioritise compatibility with new versions of bison
and flex, and retain the pregenerated versions of people with
incompatibly old version.

I think for 4.5 we should:

 * Regenerate the flex files with current wheezy's flex.  (I have
   reviewed the diff in the generated code.  It produces trivial
   changes which add declarations of xlu__cfg_yyget_column and
   xlu__cfg_yyset_column, but no code body changes - see below.)

 * Take the patch from Ed and regenerate the bison files too.


Konrad: can we have two freeze exceptions please ?

Risk analysis for Ed's patch:

Not taking the patch hurts systems with bison 2.7.1 or later:

  - Affected systems include Debian jessie, which will be
    released during the lifetime of 4.5.

  - Bison 2.7.1 was released in April 2013, a year and
    a half ago.  So any system which is less than 18 months out of
    date suffers pain from not updating.

Taking the patch hurts systems with old bison:

  - Bison 2.4.1 is known to work and was released in December 2008.
    So systems which suffer pain from updating are using at least
    4-year-old bison.

  - I have not investigated whether there are even older bison
    versions which are still OK with updating.

On the affected systems:

  - Attempts to build actually-from-source, or with modified
    bison input, will definitely fail.

  - Some proportion of other builds will fail anyway due to
    timestamp skew.


Risk analysis for regenerating with current wheezy's flex:

There doesn't seem to be any actual change in the generated code apart
from a few new function declarations and changes to #line directives.
So the risk of breakage is small.  Furthermore:

Not taking the patch now means that our flex file will be out of date
and may be regenerated and updated accidentally (or need to be
regenerated) at some point in the future.  That means that (a)
whatever risk of breakage we are taking might be discovered at an
inconvenient time (b) additional build system trouble might result
from an out of date file.


There isn't AFAICT a necessary connection between these two but we
normally regenerate both the bison and flex files together, if
necessary, before making any changes to the input files.

Thanks,
Ian.



diff --git a/tools/libxl/libxlu_cfg_l.c b/tools/libxl/libxlu_cfg_l.c
index df352aa..450863a 100644
--- a/tools/libxl/libxlu_cfg_l.c
+++ b/tools/libxl/libxlu_cfg_l.c
@@ -610,6 +610,10 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner );
 
 void xlu__cfg_yyset_lineno (int line_number ,yyscan_t yyscanner );
 
+int xlu__cfg_yyget_column  (yyscan_t yyscanner );
+
+void xlu__cfg_yyset_column (int column_no ,yyscan_t yyscanner );
+
 YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner );
 
 void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
@@ -762,7 +766,7 @@ YY_DECL
 #line 53 "libxlu_cfg_l.l"
 
 
-#line 766 "libxlu_cfg_l.c"
+#line 770 "libxlu_cfg_l.c"
 
     yylval = yylval_param;
 
@@ -971,7 +975,7 @@ YY_RULE_SETUP
 #line 104 "libxlu_cfg_l.l"
 YY_FATAL_ERROR( "flex scanner jammed" );
 	YY_BREAK
-#line 975 "libxlu_cfg_l.c"
+#line 979 "libxlu_cfg_l.c"
 case YY_STATE_EOF(INITIAL):
 case YY_STATE_EOF(lexerr):
 	yyterminate();
diff --git a/tools/libxl/libxlu_cfg_l.h b/tools/libxl/libxlu_cfg_l.h
index 4078302..151064e 100644
--- a/tools/libxl/libxlu_cfg_l.h
+++ b/tools/libxl/libxlu_cfg_l.h
@@ -276,6 +276,10 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner );
 
 void xlu__cfg_yyset_lineno (int line_number ,yyscan_t yyscanner );
 
+int xlu__cfg_yyget_column  (yyscan_t yyscanner );
+
+void xlu__cfg_yyset_column (int column_no ,yyscan_t yyscanner );
+
 YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner );
 
 void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
@@ -352,6 +356,6 @@ extern int xlu__cfg_yylex \
 
 #line 104 "libxlu_cfg_l.l"
 
-#line 356 "libxlu_cfg_l.h"
+#line 360 "libxlu_cfg_l.h"
 #undef xlu__cfg_yyIN_HEADER
 #endif /* xlu__cfg_yyHEADER_H */
diff --git a/tools/libxl/libxlu_disk_l.c b/tools/libxl/libxlu_disk_l.c
index 2c6e8e3..beea7f9 100644
--- a/tools/libxl/libxlu_disk_l.c
+++ b/tools/libxl/libxlu_disk_l.c
@@ -1011,6 +1011,10 @@ int xlu__disk_yyget_lineno (yyscan_t yyscanner );
 
 void xlu__disk_yyset_lineno (int line_number ,yyscan_t yyscanner );
 
+int xlu__disk_yyget_column  (yyscan_t yyscanner );
+
+void xlu__disk_yyset_column (int column_no ,yyscan_t yyscanner );
+
 /* Macros after this point can all be overridden by user definitions in
  * section 1.
  */
@@ -1155,7 +1159,7 @@ YY_DECL
 
  /*----- the scanner rules which do the parsing -----*/
 
-#line 1159 "libxlu_disk_l.c"
+#line 1163 "libxlu_disk_l.c"
 
 	if ( !yyg->yy_init )
 		{
@@ -1498,7 +1502,7 @@ YY_RULE_SETUP
 #line 259 "libxlu_disk_l.l"
 YY_FATAL_ERROR( "flex scanner jammed" );
 	YY_BREAK
-#line 1502 "libxlu_disk_l.c"
+#line 1506 "libxlu_disk_l.c"
 			case YY_STATE_EOF(INITIAL):
 			case YY_STATE_EOF(LEXERR):
 				yyterminate();
diff --git a/tools/libxl/libxlu_disk_l.h b/tools/libxl/libxlu_disk_l.h
index 08f60e5..f615582 100644
--- a/tools/libxl/libxlu_disk_l.h
+++ b/tools/libxl/libxlu_disk_l.h
@@ -280,6 +280,10 @@ int xlu__disk_yyget_lineno (yyscan_t yyscanner );
 
 void xlu__disk_yyset_lineno (int line_number ,yyscan_t yyscanner );
 
+int xlu__disk_yyget_column  (yyscan_t yyscanner );
+
+void xlu__disk_yyset_column (int column_no ,yyscan_t yyscanner );
+
 /* Macros after this point can all be overridden by user definitions in
  * section 1.
  */
@@ -346,6 +350,6 @@ extern int xlu__disk_yylex (yyscan_t yyscanner);
 
 #line 259 "libxlu_disk_l.l"
 
-#line 350 "libxlu_disk_l.h"
+#line 354 "libxlu_disk_l.h"
 #undef xlu__disk_yyIN_HEADER
 #endif /* xlu__disk_yyHEADER_H */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:32:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyMm8-0001ND-D3; Tue, 09 Dec 2014 15:32:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1XyMm7-0001Mt-DO
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 15:32:31 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	91/03-22819-E0617845; Tue, 09 Dec 2014 15:32:30 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418139148!8267549!1
X-Originating-IP: [140.211.169.12]
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 31975 invoked from network); 9 Dec 2014 15:32:30 -0000
Received: from mail.linuxfoundation.org (HELO mail.linuxfoundation.org)
	(140.211.169.12)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Dec 2014 15:32:30 -0000
Received: from localhost (c-76-24-48-141.hsd1.nh.comcast.net [76.24.48.141])
	by mail.linuxfoundation.org (Postfix) with ESMTPSA id B734FA7A;
	Tue,  9 Dec 2014 15:32:27 +0000 (UTC)
Date: Tue, 9 Dec 2014 10:32:26 -0500
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141209153226.GA29841@kroah.com>
References: <1417788483-662-1-git-send-email-david.vrabel@citrix.com>
	<1417788483-662-2-git-send-email-david.vrabel@citrix.com>
	<20141205213113.GB3012@kroah.com> <54857F1E.1010506@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54857F1E.1010506@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: 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/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

On Mon, Dec 08, 2014 at 10:36:14AM +0000, David Vrabel wrote:
> On 05/12/14 21:31, Greg Kroah-Hartman wrote:
> > On Fri, Dec 05, 2014 at 02:08:00PM +0000, David Vrabel wrote:
> >> 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 ++++++++--
> > 
> > Is this why you sent this to me?  The x86 maintainers should handle this
> > patch set, not me for a tiny 8 lines in just one of the files, sorry.
> 
> This series will be merged via the Xen tree, but this patch still needs
> your review or ack.

How about waiting until after the merge window and resending it, asking
for that, instead of making me guess :)

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:32:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyMm4-0001ML-12; Tue, 09 Dec 2014 15:32:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyMm1-0001LH-WA
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 15:32:26 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	11/00-02957-90617845; Tue, 09 Dec 2014 15:32:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418139142!13981364!1
X-Originating-IP: [66.165.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 17542 invoked from network); 9 Dec 2014 15:32:24 -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;
	9 Dec 2014 15:32:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201931582"
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.210.2;
	Tue, 9 Dec 2014 10:25: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 1XyMfK-0005Kf-2F;
	Tue, 09 Dec 2014 15:25:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyMfJ-0004Az-Pf;
	Tue, 09 Dec 2014 15:25:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21639.5225.596115.600016@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 15:25:29 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
In-Reply-To: <1417600430.11243.1.camel@citrix.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com>
	<547DC617.8020107@citrix.com>
	<CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
	<1417600430.11243.1.camel@citrix.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ed Swierk <eswierk@skyportsystems.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with bison 3.0"):
> There was a point in time where the prevailing version of bison (or
> maybe flex) in stable distro releases had a bug which meant these files
> could not be regenerated easily on common distros. I don't recall the
> details well enough to know if that time has now passed. Perhaps Ian J
> does.

We use (essential) features found only in non-ancient versions of
bison and flex.  The last time it was proposed to remove these
pregenerated files, there were complaints from people who were using
six-year-old bison and flex.

I think we should prioritise compatibility with new versions of bison
and flex, and retain the pregenerated versions of people with
incompatibly old version.

I think for 4.5 we should:

 * Regenerate the flex files with current wheezy's flex.  (I have
   reviewed the diff in the generated code.  It produces trivial
   changes which add declarations of xlu__cfg_yyget_column and
   xlu__cfg_yyset_column, but no code body changes - see below.)

 * Take the patch from Ed and regenerate the bison files too.


Konrad: can we have two freeze exceptions please ?

Risk analysis for Ed's patch:

Not taking the patch hurts systems with bison 2.7.1 or later:

  - Affected systems include Debian jessie, which will be
    released during the lifetime of 4.5.

  - Bison 2.7.1 was released in April 2013, a year and
    a half ago.  So any system which is less than 18 months out of
    date suffers pain from not updating.

Taking the patch hurts systems with old bison:

  - Bison 2.4.1 is known to work and was released in December 2008.
    So systems which suffer pain from updating are using at least
    4-year-old bison.

  - I have not investigated whether there are even older bison
    versions which are still OK with updating.

On the affected systems:

  - Attempts to build actually-from-source, or with modified
    bison input, will definitely fail.

  - Some proportion of other builds will fail anyway due to
    timestamp skew.


Risk analysis for regenerating with current wheezy's flex:

There doesn't seem to be any actual change in the generated code apart
from a few new function declarations and changes to #line directives.
So the risk of breakage is small.  Furthermore:

Not taking the patch now means that our flex file will be out of date
and may be regenerated and updated accidentally (or need to be
regenerated) at some point in the future.  That means that (a)
whatever risk of breakage we are taking might be discovered at an
inconvenient time (b) additional build system trouble might result
from an out of date file.


There isn't AFAICT a necessary connection between these two but we
normally regenerate both the bison and flex files together, if
necessary, before making any changes to the input files.

Thanks,
Ian.



diff --git a/tools/libxl/libxlu_cfg_l.c b/tools/libxl/libxlu_cfg_l.c
index df352aa..450863a 100644
--- a/tools/libxl/libxlu_cfg_l.c
+++ b/tools/libxl/libxlu_cfg_l.c
@@ -610,6 +610,10 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner );
 
 void xlu__cfg_yyset_lineno (int line_number ,yyscan_t yyscanner );
 
+int xlu__cfg_yyget_column  (yyscan_t yyscanner );
+
+void xlu__cfg_yyset_column (int column_no ,yyscan_t yyscanner );
+
 YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner );
 
 void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
@@ -762,7 +766,7 @@ YY_DECL
 #line 53 "libxlu_cfg_l.l"
 
 
-#line 766 "libxlu_cfg_l.c"
+#line 770 "libxlu_cfg_l.c"
 
     yylval = yylval_param;
 
@@ -971,7 +975,7 @@ YY_RULE_SETUP
 #line 104 "libxlu_cfg_l.l"
 YY_FATAL_ERROR( "flex scanner jammed" );
 	YY_BREAK
-#line 975 "libxlu_cfg_l.c"
+#line 979 "libxlu_cfg_l.c"
 case YY_STATE_EOF(INITIAL):
 case YY_STATE_EOF(lexerr):
 	yyterminate();
diff --git a/tools/libxl/libxlu_cfg_l.h b/tools/libxl/libxlu_cfg_l.h
index 4078302..151064e 100644
--- a/tools/libxl/libxlu_cfg_l.h
+++ b/tools/libxl/libxlu_cfg_l.h
@@ -276,6 +276,10 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner );
 
 void xlu__cfg_yyset_lineno (int line_number ,yyscan_t yyscanner );
 
+int xlu__cfg_yyget_column  (yyscan_t yyscanner );
+
+void xlu__cfg_yyset_column (int column_no ,yyscan_t yyscanner );
+
 YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner );
 
 void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
@@ -352,6 +356,6 @@ extern int xlu__cfg_yylex \
 
 #line 104 "libxlu_cfg_l.l"
 
-#line 356 "libxlu_cfg_l.h"
+#line 360 "libxlu_cfg_l.h"
 #undef xlu__cfg_yyIN_HEADER
 #endif /* xlu__cfg_yyHEADER_H */
diff --git a/tools/libxl/libxlu_disk_l.c b/tools/libxl/libxlu_disk_l.c
index 2c6e8e3..beea7f9 100644
--- a/tools/libxl/libxlu_disk_l.c
+++ b/tools/libxl/libxlu_disk_l.c
@@ -1011,6 +1011,10 @@ int xlu__disk_yyget_lineno (yyscan_t yyscanner );
 
 void xlu__disk_yyset_lineno (int line_number ,yyscan_t yyscanner );
 
+int xlu__disk_yyget_column  (yyscan_t yyscanner );
+
+void xlu__disk_yyset_column (int column_no ,yyscan_t yyscanner );
+
 /* Macros after this point can all be overridden by user definitions in
  * section 1.
  */
@@ -1155,7 +1159,7 @@ YY_DECL
 
  /*----- the scanner rules which do the parsing -----*/
 
-#line 1159 "libxlu_disk_l.c"
+#line 1163 "libxlu_disk_l.c"
 
 	if ( !yyg->yy_init )
 		{
@@ -1498,7 +1502,7 @@ YY_RULE_SETUP
 #line 259 "libxlu_disk_l.l"
 YY_FATAL_ERROR( "flex scanner jammed" );
 	YY_BREAK
-#line 1502 "libxlu_disk_l.c"
+#line 1506 "libxlu_disk_l.c"
 			case YY_STATE_EOF(INITIAL):
 			case YY_STATE_EOF(LEXERR):
 				yyterminate();
diff --git a/tools/libxl/libxlu_disk_l.h b/tools/libxl/libxlu_disk_l.h
index 08f60e5..f615582 100644
--- a/tools/libxl/libxlu_disk_l.h
+++ b/tools/libxl/libxlu_disk_l.h
@@ -280,6 +280,10 @@ int xlu__disk_yyget_lineno (yyscan_t yyscanner );
 
 void xlu__disk_yyset_lineno (int line_number ,yyscan_t yyscanner );
 
+int xlu__disk_yyget_column  (yyscan_t yyscanner );
+
+void xlu__disk_yyset_column (int column_no ,yyscan_t yyscanner );
+
 /* Macros after this point can all be overridden by user definitions in
  * section 1.
  */
@@ -346,6 +350,6 @@ extern int xlu__disk_yylex (yyscan_t yyscanner);
 
 #line 259 "libxlu_disk_l.l"
 
-#line 350 "libxlu_disk_l.h"
+#line 354 "libxlu_disk_l.h"
 #undef xlu__disk_yyIN_HEADER
 #endif /* xlu__disk_yyHEADER_H */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:33:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyMmk-0001V4-Qr; Tue, 09 Dec 2014 15:33:10 +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 1XyMmj-0001Un-ND
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 15:33:09 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	9F/97-18267-43617845; Tue, 09 Dec 2014 15:33:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418139186!12118235!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1329 invoked from network); 9 Dec 2014 15:33:08 -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; 9 Dec 2014 15:33: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 sB9FX0Sj030964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Dec 2014 15:33: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
	sB9FWxoW003853
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 9 Dec 2014 15:32:59 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
	sB9FWxll003839; Tue, 9 Dec 2014 15:32:59 GMT
Received: from laptop.dumpdata.com (/10.154.136.116)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Dec 2014 07:32:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BD28B12269A; Tue,  9 Dec 2014 10:32:57 -0500 (EST)
Date: Tue, 9 Dec 2014 10:32:57 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141209153257.GA9585@laptop.dumpdata.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
	<1418135737.14361.71.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418135737.14361.71.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
 target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 02:35:37PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 16:16 +0100, Daniel Kiper wrote:
> 
> > +distclean:
> > +	rm -f Linux/init.d/sysconfig.xencommons Linux/init.d/xencommons NetBSD/rc.d/xencommons
> 
> Configure generates a boatload more things than this, see e.g. 
> 
> $ grep hotplug/ tools/configure.ac 
> 
> Perhaps the answer would be to recurse into tools/hotplug/* and refactor
> the existing XEN_SCRIPTS to have the generated stuff in XEN_SCRIPTS_GEN
> instead and XEN_SCRIPTS += $(XEN_SCRIPTS). The on distclean remove the
> XEN_SCRIPTS_GEN ones.
> 
> It's not ideal, but at least it puts the distclean logic in the same
> place as the logic to install the files, if not their generation, which
> at least increases the chance of someone adding it to the right place.

Daniel pointed to me that the two other patches that were committed
solve the problem of seeing those auto-generated files sticking (and
forcing one to use git checkout XYZ -f).

So this small patch can be ditched in favour of the more encompassing
design that you have sketched out.

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 Tue Dec 09 15:33:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyMmk-0001V4-Qr; Tue, 09 Dec 2014 15:33:10 +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 1XyMmj-0001Un-ND
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 15:33:09 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	9F/97-18267-43617845; Tue, 09 Dec 2014 15:33:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418139186!12118235!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1329 invoked from network); 9 Dec 2014 15:33:08 -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; 9 Dec 2014 15:33: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 sB9FX0Sj030964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Dec 2014 15:33: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
	sB9FWxoW003853
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 9 Dec 2014 15:32:59 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
	sB9FWxll003839; Tue, 9 Dec 2014 15:32:59 GMT
Received: from laptop.dumpdata.com (/10.154.136.116)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Dec 2014 07:32:58 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BD28B12269A; Tue,  9 Dec 2014 10:32:57 -0500 (EST)
Date: Tue, 9 Dec 2014 10:32:57 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141209153257.GA9585@laptop.dumpdata.com>
References: <1417533390-29035-1-git-send-email-daniel.kiper@oracle.com>
	<1417533390-29035-2-git-send-email-daniel.kiper@oracle.com>
	<1418135737.14361.71.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418135737.14361.71.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: keir@xen.org, andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian.jackson@eu.citrix.com, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for-xen-4.5 1/3] tools/hotplug: distclean
 target should remove files generated by configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 02:35:37PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-02 at 16:16 +0100, Daniel Kiper wrote:
> 
> > +distclean:
> > +	rm -f Linux/init.d/sysconfig.xencommons Linux/init.d/xencommons NetBSD/rc.d/xencommons
> 
> Configure generates a boatload more things than this, see e.g. 
> 
> $ grep hotplug/ tools/configure.ac 
> 
> Perhaps the answer would be to recurse into tools/hotplug/* and refactor
> the existing XEN_SCRIPTS to have the generated stuff in XEN_SCRIPTS_GEN
> instead and XEN_SCRIPTS += $(XEN_SCRIPTS). The on distclean remove the
> XEN_SCRIPTS_GEN ones.
> 
> It's not ideal, but at least it puts the distclean logic in the same
> place as the logic to install the files, if not their generation, which
> at least increases the chance of someone adding it to the right place.

Daniel pointed to me that the two other patches that were committed
solve the problem of seeing those auto-generated files sticking (and
forcing one to use git checkout XYZ -f).

So this small patch can be ditched in favour of the more encompassing
design that you have sketched out.

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 Tue Dec 09 15:47:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyN0g-0002Jj-8k; Tue, 09 Dec 2014 15:47:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XyN0e-0002Jb-LP
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 15:47:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	03/ED-25276-49917845; Tue, 09 Dec 2014 15:47:32 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418140048!14461488!1
X-Originating-IP: [66.165.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 2238 invoked from network); 9 Dec 2014 15:47:31 -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;
	9 Dec 2014 15:47:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201943859"
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.210.2;
	Tue, 9 Dec 2014 10:40:29 -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 1XyMtp-0005hP-1G;
	Tue, 09 Dec 2014 15:40:29 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: <libvir-list@redhat.com>
Date: Tue, 9 Dec 2014 15:39:59 +0000
Message-ID: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.1.3
MIME-Version: 1.0
X-DLP: MIA2
Cc: Anthony PERARD <anthony.perard@citrix.com>, Jim Fehlig <jfehlig@suse.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The path to the pty of a Xen PV console is set only in
virDomainOpenConsole. But this is done too late. A call to
virDomainGetXMLDesc done before OpenConsole will not have the path to
the pty, but a call after OpenConsole will.

e.g. of the current issue.
Starting a domain with '<console type="pty"/>'
Then:
virDomainGetXMLDesc():
  <devices>
    <console type='pty'>
      <target type='xen' port='0'/>
    </console>
  </devices>
virDomainOpenConsole()
virDomainGetXMLDesc():
  <devices>
    <console type='pty' tty='/dev/pts/30'>
      <source path='/dev/pts/30'/>
      <target type='xen' port='0'/>
    </console>
  </devices>

The patch intend to have the TTY path on the first call of GetXMLDesc.
This is done by setting up the path at domain start up instead of in
OpenConsole.

https://bugzilla.redhat.com/show_bug.cgi?id=1170743

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
Change in V2:
  Adding bug report link.
  Reword the last part of the patch description.
  Cleanup the code.
  Use VIR_FREE before VIR_STRDUP.
  Remove the code from OpenConsole as it is now a duplicate.
---
 src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
 src/libxl/libxl_driver.c | 15 ---------------
 2 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 9c62291..325de79 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
     if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
         goto cleanup_dom;
 
+    if (vm->def->nconsoles) {
+        virDomainChrDefPtr chr = vm->def->consoles[0];
+        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
+            libxl_console_type console_type;
+            char *console = NULL;
+
+            console_type =
+                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
+                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
+            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
+                                        chr->target.port, console_type,
+                                        &console);
+            if (!ret) {
+                VIR_FREE(chr->source.data.file.path);
+                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
+            }
+            VIR_FREE(console);
+        }
+    }
+
     if (!start_paused) {
         libxl_domain_unpause(priv->ctx, domid);
         virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED);
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 53c87ce..e79afac 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -3957,10 +3957,8 @@ libxlDomainOpenConsole(virDomainPtr dom,
 {
     virDomainObjPtr vm = NULL;
     int ret = -1;
-    libxl_console_type console_type;
     virDomainChrDefPtr chr = NULL;
     libxlDomainObjPrivatePtr priv;
-    char *console = NULL;
 
     virCheckFlags(VIR_DOMAIN_CONSOLE_FORCE, -1);
 
@@ -4002,18 +4000,6 @@ libxlDomainOpenConsole(virDomainPtr dom,
         goto cleanup;
     }
 
-    console_type =
-        (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
-                            LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
-
-    ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
-                                console_type, &console);
-    if (ret)
-        goto cleanup;
-
-    if (VIR_STRDUP(chr->source.data.file.path, console) < 0)
-        goto cleanup;
-
     /* handle mutually exclusive access to console devices */
     ret = virChrdevOpen(priv->devs,
                         &chr->source,
@@ -4027,7 +4013,6 @@ libxlDomainOpenConsole(virDomainPtr dom,
     }
 
  cleanup:
-    VIR_FREE(console);
     if (vm)
         virObjectUnlock(vm);
     return ret;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:47:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyN0g-0002Jj-8k; Tue, 09 Dec 2014 15:47:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1XyN0e-0002Jb-LP
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 15:47:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	03/ED-25276-49917845; Tue, 09 Dec 2014 15:47:32 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418140048!14461488!1
X-Originating-IP: [66.165.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 2238 invoked from network); 9 Dec 2014 15:47:31 -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;
	9 Dec 2014 15:47:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201943859"
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.210.2;
	Tue, 9 Dec 2014 10:40:29 -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 1XyMtp-0005hP-1G;
	Tue, 09 Dec 2014 15:40:29 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: <libvir-list@redhat.com>
Date: Tue, 9 Dec 2014 15:39:59 +0000
Message-ID: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 2.1.3
MIME-Version: 1.0
X-DLP: MIA2
Cc: Anthony PERARD <anthony.perard@citrix.com>, Jim Fehlig <jfehlig@suse.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The path to the pty of a Xen PV console is set only in
virDomainOpenConsole. But this is done too late. A call to
virDomainGetXMLDesc done before OpenConsole will not have the path to
the pty, but a call after OpenConsole will.

e.g. of the current issue.
Starting a domain with '<console type="pty"/>'
Then:
virDomainGetXMLDesc():
  <devices>
    <console type='pty'>
      <target type='xen' port='0'/>
    </console>
  </devices>
virDomainOpenConsole()
virDomainGetXMLDesc():
  <devices>
    <console type='pty' tty='/dev/pts/30'>
      <source path='/dev/pts/30'/>
      <target type='xen' port='0'/>
    </console>
  </devices>

The patch intend to have the TTY path on the first call of GetXMLDesc.
This is done by setting up the path at domain start up instead of in
OpenConsole.

https://bugzilla.redhat.com/show_bug.cgi?id=1170743

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
Change in V2:
  Adding bug report link.
  Reword the last part of the patch description.
  Cleanup the code.
  Use VIR_FREE before VIR_STRDUP.
  Remove the code from OpenConsole as it is now a duplicate.
---
 src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
 src/libxl/libxl_driver.c | 15 ---------------
 2 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 9c62291..325de79 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
     if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
         goto cleanup_dom;
 
+    if (vm->def->nconsoles) {
+        virDomainChrDefPtr chr = vm->def->consoles[0];
+        if (chr && chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) {
+            libxl_console_type console_type;
+            char *console = NULL;
+
+            console_type =
+                (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
+                 LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
+            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
+                                        chr->target.port, console_type,
+                                        &console);
+            if (!ret) {
+                VIR_FREE(chr->source.data.file.path);
+                ignore_value(VIR_STRDUP(chr->source.data.file.path, console));
+            }
+            VIR_FREE(console);
+        }
+    }
+
     if (!start_paused) {
         libxl_domain_unpause(priv->ctx, domid);
         virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED);
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 53c87ce..e79afac 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -3957,10 +3957,8 @@ libxlDomainOpenConsole(virDomainPtr dom,
 {
     virDomainObjPtr vm = NULL;
     int ret = -1;
-    libxl_console_type console_type;
     virDomainChrDefPtr chr = NULL;
     libxlDomainObjPrivatePtr priv;
-    char *console = NULL;
 
     virCheckFlags(VIR_DOMAIN_CONSOLE_FORCE, -1);
 
@@ -4002,18 +4000,6 @@ libxlDomainOpenConsole(virDomainPtr dom,
         goto cleanup;
     }
 
-    console_type =
-        (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
-                            LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV);
-
-    ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port,
-                                console_type, &console);
-    if (ret)
-        goto cleanup;
-
-    if (VIR_STRDUP(chr->source.data.file.path, console) < 0)
-        goto cleanup;
-
     /* handle mutually exclusive access to console devices */
     ret = virChrdevOpen(priv->devs,
                         &chr->source,
@@ -4027,7 +4013,6 @@ libxlDomainOpenConsole(virDomainPtr dom,
     }
 
  cleanup:
-    VIR_FREE(console);
     if (vm)
         virObjectUnlock(vm);
     return ret;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:55:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyN7s-0002wI-An; Tue, 09 Dec 2014 15:55:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyN7r-0002wD-Cl
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:54:59 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	50/C9-22737-25B17845; Tue, 09 Dec 2014 15:54:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418140494!12376647!1
X-Originating-IP: [66.165.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 29643 invoked from network); 9 Dec 2014 15:54:57 -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;
	9 Dec 2014 15:54:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201948941"
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.210.2;
	Tue, 9 Dec 2014 10:48: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 1XyN1y-0005r3-Qq;
	Tue, 09 Dec 2014 15:48:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN1y-0005Ul-Ii;
	Tue, 09 Dec 2014 15:48:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21639.6630.4115.163134@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 15:48:54 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417179851.23604.41.camel@citrix.com>,
	<1418124715.14361.29.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>
	<21624.35587.721780.498045@mariner.uk.xensource.com>
	<1417186350.23604.54.camel@citrix.com>
	<21638.56211.381241.397871@mariner.uk.xensource.com>
	<1418124715.14361.29.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,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: events: Deregister evtchn fd
	when not needed [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 5/6] libxl: events: Deregister evtchn fd when not needed"):
> There were other comments further down my original review which you
> haven't answered. I don't think they were (all) predicated on a
> particular answer to the first question (although some were).

Sorry, I didn't see those buried in down the patch ...

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:
> > @@ -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?

Good point.

> > @@ -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?

In fact, I should check libxl__ev_fd_isregistered.  That makes the
fragment idempotent.  I'm surprised this worked for you as it was...

> >      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.

Given the change above, I don't think it matters, because if
evev->waiting, all of the other stuff is definitely already set up
anyway.  It is clearest to put the new initialisation fragment next to
the existing one.

I will resend with the two changes above.  The diff between the
previous version of this patch and the forthcoming new one is below.

Thanks for the careful review.

Ian.


diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 716f318..a36e6d9 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;
+    int rc, fd;
 
     if (CTX->xce)
         return 0;
@@ -733,10 +733,10 @@ int libxl__ctx_evtchn_init(libxl__gc *gc) {
         goto out;
     }
 
-    CTX->evtchn_fd = xc_evtchn_fd(xce);
-    assert(CTX->evtchn_fd >= 0);
+    fd = xc_evtchn_fd(xce);
+    assert(fd >= 0);
 
-    rc = libxl_fd_set_nonblock(CTX, CTX->evtchn_fd, 1);
+    rc = libxl_fd_set_nonblock(CTX, fd, 1);
     if (rc) goto out;
 
     CTX->xce = xce;
@@ -763,9 +763,11 @@ int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
     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 (!libxl__ev_fd_isregistered(&CTX->evtchn_efd)) {
+        rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd, evtchn_fd_callback,
+                                   xc_evtchn_fd(CTX->xce), POLLIN);
+        if (rc) goto out;
+    }
 
     if (evev->waiting)
         return 0;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2eeba1e..9695f18 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -359,7 +359,6 @@ 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)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:55:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyN7z-0002wm-Mk; Tue, 09 Dec 2014 15:55: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 1XyN7y-0002wc-EB
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:55:06 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	9C/66-02696-95B17845; Tue, 09 Dec 2014 15:55:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418140502!8545986!1
X-Originating-IP: [66.165.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 27889 invoked from network); 9 Dec 2014 15:55: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;
	9 Dec 2014 15:55:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202355649"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7m-0005zJ-3R;
	Tue, 09 Dec 2014 15:54:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7l-0005XL-RP;
	Tue, 09 Dec 2014 15:54:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:46 +0000
Message-ID: <1418140489-21196-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-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 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 Tue Dec 09 15:55:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyN7s-0002wI-An; Tue, 09 Dec 2014 15:55:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyN7r-0002wD-Cl
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:54:59 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	50/C9-22737-25B17845; Tue, 09 Dec 2014 15:54:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418140494!12376647!1
X-Originating-IP: [66.165.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 29643 invoked from network); 9 Dec 2014 15:54:57 -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;
	9 Dec 2014 15:54:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201948941"
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.210.2;
	Tue, 9 Dec 2014 10:48: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 1XyN1y-0005r3-Qq;
	Tue, 09 Dec 2014 15:48:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN1y-0005Ul-Ii;
	Tue, 09 Dec 2014 15:48:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21639.6630.4115.163134@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 15:48:54 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1417179851.23604.41.camel@citrix.com>,
	<1418124715.14361.29.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>
	<21624.35587.721780.498045@mariner.uk.xensource.com>
	<1417186350.23604.54.camel@citrix.com>
	<21638.56211.381241.397871@mariner.uk.xensource.com>
	<1418124715.14361.29.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,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] libxl: events: Deregister evtchn fd
	when not needed [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 5/6] libxl: events: Deregister evtchn fd when not needed"):
> There were other comments further down my original review which you
> haven't answered. I don't think they were (all) predicated on a
> particular answer to the first question (although some were).

Sorry, I didn't see those buried in down the patch ...

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:
> > @@ -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?

Good point.

> > @@ -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?

In fact, I should check libxl__ev_fd_isregistered.  That makes the
fragment idempotent.  I'm surprised this worked for you as it was...

> >      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.

Given the change above, I don't think it matters, because if
evev->waiting, all of the other stuff is definitely already set up
anyway.  It is clearest to put the new initialisation fragment next to
the existing one.

I will resend with the two changes above.  The diff between the
previous version of this patch and the forthcoming new one is below.

Thanks for the careful review.

Ian.


diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 716f318..a36e6d9 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;
+    int rc, fd;
 
     if (CTX->xce)
         return 0;
@@ -733,10 +733,10 @@ int libxl__ctx_evtchn_init(libxl__gc *gc) {
         goto out;
     }
 
-    CTX->evtchn_fd = xc_evtchn_fd(xce);
-    assert(CTX->evtchn_fd >= 0);
+    fd = xc_evtchn_fd(xce);
+    assert(fd >= 0);
 
-    rc = libxl_fd_set_nonblock(CTX, CTX->evtchn_fd, 1);
+    rc = libxl_fd_set_nonblock(CTX, fd, 1);
     if (rc) goto out;
 
     CTX->xce = xce;
@@ -763,9 +763,11 @@ int libxl__ev_evtchn_wait(libxl__gc *gc, libxl__ev_evtchn *evev)
     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 (!libxl__ev_fd_isregistered(&CTX->evtchn_efd)) {
+        rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd, evtchn_fd_callback,
+                                   xc_evtchn_fd(CTX->xce), POLLIN);
+        if (rc) goto out;
+    }
 
     if (evev->waiting)
         return 0;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2eeba1e..9695f18 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -359,7 +359,6 @@ 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)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:55:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyN7z-0002wm-Mk; Tue, 09 Dec 2014 15:55: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 1XyN7y-0002wc-EB
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:55:06 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	9C/66-02696-95B17845; Tue, 09 Dec 2014 15:55:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418140502!8545986!1
X-Originating-IP: [66.165.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 27889 invoked from network); 9 Dec 2014 15:55: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;
	9 Dec 2014 15:55:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202355649"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7m-0005zJ-3R;
	Tue, 09 Dec 2014 15:54:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7l-0005XL-RP;
	Tue, 09 Dec 2014 15:54:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:46 +0000
Message-ID: <1418140489-21196-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-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 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 Tue Dec 09 15:57:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyN9d-00037H-6S; Tue, 09 Dec 2014 15:56:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyN9b-000374-Cc
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 15:56:47 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	B6/1E-23865-EBB17845; Tue, 09 Dec 2014 15:56:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418140602!8394633!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 14263 invoked from network); 9 Dec 2014 15:56: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;
	9 Dec 2014 15:56:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202356337"
Message-ID: <1418140562.19809.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Tue, 9 Dec 2014 15:56:02 +0000
In-Reply-To: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-09 at 15:39 +0000, Anthony PERARD wrote:
> The path to the pty of a Xen PV console is set only in
> virDomainOpenConsole. But this is done too late. A call to
> virDomainGetXMLDesc done before OpenConsole will not have the path to
> the pty, but a call after OpenConsole will.
> 
> e.g. of the current issue.
> Starting a domain with '<console type="pty"/>'
> Then:
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty'>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> virDomainOpenConsole()
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty' tty='/dev/pts/30'>
>       <source path='/dev/pts/30'/>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> 
> The patch intend to have the TTY path on the first call of GetXMLDesc.
> This is done by setting up the path at domain start up instead of in
> OpenConsole.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> ---
> Change in V2:
>   Adding bug report link.
>   Reword the last part of the patch description.
>   Cleanup the code.
>   Use VIR_FREE before VIR_STRDUP.
>   Remove the code from OpenConsole as it is now a duplicate.
> ---
>  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
>  src/libxl/libxl_driver.c | 15 ---------------
>  2 files changed, 20 insertions(+), 15 deletions(-)
> 
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 9c62291..325de79 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
>      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
>          goto cleanup_dom;
>  
> +    if (vm->def->nconsoles) {
> +        virDomainChrDefPtr chr = vm->def->consoles[0];

Given vm->def->nconsoles should we loop and do them all?

Also, and I really should know the answer to this (and sorry for not
thinking of it earlier), but:

> +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> +                                        chr->target.port, console_type,
> +                                        &console);

Might this race against xenconsoled writing the node to xenstore and
therefore be prone to failing when starting multiple guests all at once?

Is there a hook which is called on virsh dumpxml which could update
things on the fly (i.e. lookup the console iff it isn't already set)?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:57:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15: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 1XyN9d-00037H-6S; Tue, 09 Dec 2014 15:56:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyN9b-000374-Cc
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 15:56:47 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	B6/1E-23865-EBB17845; Tue, 09 Dec 2014 15:56:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418140602!8394633!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 14263 invoked from network); 9 Dec 2014 15:56: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;
	9 Dec 2014 15:56:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202356337"
Message-ID: <1418140562.19809.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Tue, 9 Dec 2014 15:56:02 +0000
In-Reply-To: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-09 at 15:39 +0000, Anthony PERARD wrote:
> The path to the pty of a Xen PV console is set only in
> virDomainOpenConsole. But this is done too late. A call to
> virDomainGetXMLDesc done before OpenConsole will not have the path to
> the pty, but a call after OpenConsole will.
> 
> e.g. of the current issue.
> Starting a domain with '<console type="pty"/>'
> Then:
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty'>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> virDomainOpenConsole()
> virDomainGetXMLDesc():
>   <devices>
>     <console type='pty' tty='/dev/pts/30'>
>       <source path='/dev/pts/30'/>
>       <target type='xen' port='0'/>
>     </console>
>   </devices>
> 
> The patch intend to have the TTY path on the first call of GetXMLDesc.
> This is done by setting up the path at domain start up instead of in
> OpenConsole.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> ---
> Change in V2:
>   Adding bug report link.
>   Reword the last part of the patch description.
>   Cleanup the code.
>   Use VIR_FREE before VIR_STRDUP.
>   Remove the code from OpenConsole as it is now a duplicate.
> ---
>  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
>  src/libxl/libxl_driver.c | 15 ---------------
>  2 files changed, 20 insertions(+), 15 deletions(-)
> 
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 9c62291..325de79 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
>      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
>          goto cleanup_dom;
>  
> +    if (vm->def->nconsoles) {
> +        virDomainChrDefPtr chr = vm->def->consoles[0];

Given vm->def->nconsoles should we loop and do them all?

Also, and I really should know the answer to this (and sorry for not
thinking of it earlier), but:

> +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> +                                        chr->target.port, console_type,
> +                                        &console);

Might this race against xenconsoled writing the node to xenstore and
therefore be prone to failing when starting multiple guests all at once?

Is there a hook which is called on virsh dumpxml which could update
things on the fly (i.e. lookup the console iff it isn't already set)?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 15:58:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15:58:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNAQ-0003DN-KX; Tue, 09 Dec 2014 15:57: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 1XyNAP-0003Cv-0h
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:57:37 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	72/36-19763-0FB17845; Tue, 09 Dec 2014 15:57:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418140653!12393315!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 19460 invoked from network); 9 Dec 2014 15:57:35 -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;
	9 Dec 2014 15:57:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202356892"
Message-ID: <1418140618.19809.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 9 Dec 2014 15:56:58 +0000
In-Reply-To: <1418140489-21196-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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 Tue, 2014-12-09 at 15:54 +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.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@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 Tue Dec 09 15:58:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 15:58:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNAQ-0003DN-KX; Tue, 09 Dec 2014 15:57: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 1XyNAP-0003Cv-0h
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:57:37 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	72/36-19763-0FB17845; Tue, 09 Dec 2014 15:57:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418140653!12393315!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 19460 invoked from network); 9 Dec 2014 15:57:35 -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;
	9 Dec 2014 15:57:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202356892"
Message-ID: <1418140618.19809.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 9 Dec 2014 15:56:58 +0000
In-Reply-To: <1418140489-21196-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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 Tue, 2014-12-09 at 15:54 +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.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@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 Tue Dec 09 16:00:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNCU-0003SY-Jt; Tue, 09 Dec 2014 15:59: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 1XyNCS-0003Qp-Ao
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:59:44 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	E4/B5-02576-F6C17845; Tue, 09 Dec 2014 15:59:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418140776!13986559!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23569 invoked from network); 9 Dec 2014 15:59:42 -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;
	9 Dec 2014 15:59:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201952279"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7m-0005zM-AJ;
	Tue, 09 Dec 2014 15:54:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7m-0005XQ-2i;
	Tue, 09 Dec 2014 15:54:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:47 +0000
Message-ID: <1418140489-21196-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-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 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 a238621..8f06043 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 Tue Dec 09 16:00:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNCT-0003Rz-Tk; Tue, 09 Dec 2014 15:59:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyNCS-0003Qi-4R
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:59:44 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	E6/E9-24859-F6C17845; Tue, 09 Dec 2014 15:59:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418140778!12037115!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4183 invoked from network); 9 Dec 2014 15:59:42 -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;
	9 Dec 2014 15:59:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201952240"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7m-0005zS-Ob;
	Tue, 09 Dec 2014 15:54:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7m-0005Xa-GY;
	Tue, 09 Dec 2014 15:54:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:49 +0000
Message-ID: <1418140489-21196-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-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 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 a36e6d9..0d874d9 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1219,6 +1219,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 Tue Dec 09 16:00:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNCT-0003RL-85; Tue, 09 Dec 2014 15:59:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyNCR-0003QW-Fm
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:59:43 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	4B/26-02957-E6C17845; Tue, 09 Dec 2014 15:59:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418140776!13986559!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23523 invoked from network); 9 Dec 2014 15:59:42 -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;
	9 Dec 2014 15:59:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201952227"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7m-0005zP-HF;
	Tue, 09 Dec 2014 15:54:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7m-0005XV-9g;
	Tue, 09 Dec 2014 15:54:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:48 +0000
Message-ID: <1418140489-21196-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-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>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---
v2: Do not bother putting evtchn_fd in the ctx; instead, get it
     from xc_evtchn_fd when we need it.  (Cosmetic.)
    Do not register the evtchn fd multiple times: check it's not
     registered before we call libxl__ev_fd_register.  (Bugfix.)
---
 tools/libxl/libxl.c       |    4 +---
 tools/libxl/libxl_event.c |   21 +++++++++++++++++----
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 8f06043..50a8928 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..a36e6d9 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -739,10 +739,6 @@ int libxl__ctx_evtchn_init(libxl__gc *gc) {
     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);
-    if (rc) goto out;
-
     CTX->xce = xce;
     return 0;
 
@@ -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,15 @@ 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;
+
+    if (!libxl__ev_fd_isregistered(&CTX->evtchn_efd)) {
+        rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd, evtchn_fd_callback,
+                                   xc_evtchn_fd(CTX->xce), POLLIN);
+        if (rc) goto out;
+    }
+
     if (evev->waiting)
         return 0;
 
@@ -773,6 +784,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 +798,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);
 }
 
 /*
-- 
1.7.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 Dec 09 16:00:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNCR-0003QX-5M; Tue, 09 Dec 2014 15:59: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 1XyNCP-0003QJ-W2
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:59:42 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	5D/16-02957-D6C17845; Tue, 09 Dec 2014 15:59:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418140776!13986559!1
X-Originating-IP: [66.165.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 23429 invoked from network); 9 Dec 2014 15:59:40 -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;
	9 Dec 2014 15:59:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201952214"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7l-0005zA-DG;
	Tue, 09 Dec 2014 15:54:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7l-0005X7-4e;
	Tue, 09 Dec 2014 15:54:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:43 +0000
Message-ID: <1418140489-21196-1-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: <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 Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 v2 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.


The changes in version 2 of the series are:
  * Fix bogus non-idempotent of evtchn_efd.  (Bug in the patch.)
  * Do not put evtchn_fd in the ctx.  (Style improvement.)


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.

Version 1 of this series was:
 Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
which I have transferred into this version.


Version 1 had:
 Tested-by: Ian Campbell <ian.campbell@citrix.com>
but that does not apply any more from patch 5 onwards since patch 5
has changed.

Ian C, do you still have the setup you used to test v1 ?

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 Dec 09 16:00:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNCS-0003R0-Ha; Tue, 09 Dec 2014 15:59: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 1XyNCQ-0003QQ-Pk
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:59:42 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	C6/7E-03148-E6C17845; Tue, 09 Dec 2014 15:59:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418140776!13986559!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23485 invoked from network); 9 Dec 2014 15:59:41 -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;
	9 Dec 2014 15:59:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201952216"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7l-0005zD-Kk;
	Tue, 09 Dec 2014 15:54:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7l-0005XB-CS;
	Tue, 09 Dec 2014 15:54:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:44 +0000
Message-ID: <1418140489-21196-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-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 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/libxl/libxl.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 74c00dc..55ef535 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 Tue Dec 09 16:00:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNCS-0003RB-Sr; Tue, 09 Dec 2014 15:59:44 +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 1XyNCR-0003QR-A0
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:59:43 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	E5/25-17694-E6C17845; Tue, 09 Dec 2014 15:59:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418140778!12037115!1
X-Originating-IP: [66.165.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 4057 invoked from network); 9 Dec 2014 15:59:42 -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;
	9 Dec 2014 15:59:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201952221"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7l-0005zG-S6;
	Tue, 09 Dec 2014 15:54:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7l-0005XG-Jq;
	Tue, 09 Dec 2014 15:54:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:45 +0000
Message-ID: <1418140489-21196-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-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 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 55ef535..a238621 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 a38f695..9695f18 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 Tue Dec 09 16:00:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNCT-0003RL-85; Tue, 09 Dec 2014 15:59:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyNCR-0003QW-Fm
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:59:43 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	4B/26-02957-E6C17845; Tue, 09 Dec 2014 15:59:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418140776!13986559!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23523 invoked from network); 9 Dec 2014 15:59:42 -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;
	9 Dec 2014 15:59:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201952227"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7m-0005zP-HF;
	Tue, 09 Dec 2014 15:54:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7m-0005XV-9g;
	Tue, 09 Dec 2014 15:54:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:48 +0000
Message-ID: <1418140489-21196-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-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>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---
v2: Do not bother putting evtchn_fd in the ctx; instead, get it
     from xc_evtchn_fd when we need it.  (Cosmetic.)
    Do not register the evtchn fd multiple times: check it's not
     registered before we call libxl__ev_fd_register.  (Bugfix.)
---
 tools/libxl/libxl.c       |    4 +---
 tools/libxl/libxl_event.c |   21 +++++++++++++++++----
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 8f06043..50a8928 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..a36e6d9 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -739,10 +739,6 @@ int libxl__ctx_evtchn_init(libxl__gc *gc) {
     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);
-    if (rc) goto out;
-
     CTX->xce = xce;
     return 0;
 
@@ -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,15 @@ 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;
+
+    if (!libxl__ev_fd_isregistered(&CTX->evtchn_efd)) {
+        rc = libxl__ev_fd_register(gc, &CTX->evtchn_efd, evtchn_fd_callback,
+                                   xc_evtchn_fd(CTX->xce), POLLIN);
+        if (rc) goto out;
+    }
+
     if (evev->waiting)
         return 0;
 
@@ -773,6 +784,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 +798,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);
 }
 
 /*
-- 
1.7.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 Dec 09 16:00:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNCR-0003QX-5M; Tue, 09 Dec 2014 15:59: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 1XyNCP-0003QJ-W2
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:59:42 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	5D/16-02957-D6C17845; Tue, 09 Dec 2014 15:59:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418140776!13986559!1
X-Originating-IP: [66.165.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 23429 invoked from network); 9 Dec 2014 15:59:40 -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;
	9 Dec 2014 15:59:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201952214"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7l-0005zA-DG;
	Tue, 09 Dec 2014 15:54:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7l-0005X7-4e;
	Tue, 09 Dec 2014 15:54:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:43 +0000
Message-ID: <1418140489-21196-1-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: <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 Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH for-4.5 v2 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.


The changes in version 2 of the series are:
  * Fix bogus non-idempotent of evtchn_efd.  (Bug in the patch.)
  * Do not put evtchn_fd in the ctx.  (Style improvement.)


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.

Version 1 of this series was:
 Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
which I have transferred into this version.


Version 1 had:
 Tested-by: Ian Campbell <ian.campbell@citrix.com>
but that does not apply any more from patch 5 onwards since patch 5
has changed.

Ian C, do you still have the setup you used to test v1 ?

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 Dec 09 16:00:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNCU-0003SY-Jt; Tue, 09 Dec 2014 15:59: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 1XyNCS-0003Qp-Ao
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:59:44 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	E4/B5-02576-F6C17845; Tue, 09 Dec 2014 15:59:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418140776!13986559!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23569 invoked from network); 9 Dec 2014 15:59:42 -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;
	9 Dec 2014 15:59:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201952279"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7m-0005zM-AJ;
	Tue, 09 Dec 2014 15:54:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7m-0005XQ-2i;
	Tue, 09 Dec 2014 15:54:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:47 +0000
Message-ID: <1418140489-21196-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-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 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 a238621..8f06043 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 Tue Dec 09 16:00:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNCS-0003R0-Ha; Tue, 09 Dec 2014 15:59: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 1XyNCQ-0003QQ-Pk
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:59:42 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	C6/7E-03148-E6C17845; Tue, 09 Dec 2014 15:59:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418140776!13986559!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23485 invoked from network); 9 Dec 2014 15:59:41 -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;
	9 Dec 2014 15:59:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201952216"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7l-0005zD-Kk;
	Tue, 09 Dec 2014 15:54:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7l-0005XB-CS;
	Tue, 09 Dec 2014 15:54:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:44 +0000
Message-ID: <1418140489-21196-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-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 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/libxl/libxl.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 74c00dc..55ef535 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 Tue Dec 09 16:00:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNCS-0003RB-Sr; Tue, 09 Dec 2014 15:59:44 +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 1XyNCR-0003QR-A0
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:59:43 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	E5/25-17694-E6C17845; Tue, 09 Dec 2014 15:59:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418140778!12037115!1
X-Originating-IP: [66.165.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 4057 invoked from network); 9 Dec 2014 15:59:42 -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;
	9 Dec 2014 15:59:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201952221"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7l-0005zG-S6;
	Tue, 09 Dec 2014 15:54:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7l-0005XG-Jq;
	Tue, 09 Dec 2014 15:54:53 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:45 +0000
Message-ID: <1418140489-21196-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-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 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 55ef535..a238621 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 a38f695..9695f18 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 Tue Dec 09 16:00:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNCT-0003Rz-Tk; Tue, 09 Dec 2014 15:59:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyNCS-0003Qi-4R
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 15:59:44 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	E6/E9-24859-F6C17845; Tue, 09 Dec 2014 15:59:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418140778!12037115!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4183 invoked from network); 9 Dec 2014 15:59:42 -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;
	9 Dec 2014 15:59:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="201952240"
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.210.2;
	Tue, 9 Dec 2014 10:54: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 1XyN7m-0005zS-Ob;
	Tue, 09 Dec 2014 15:54:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyN7m-0005Xa-GY;
	Tue, 09 Dec 2014 15:54:54 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 9 Dec 2014 15:54:49 +0000
Message-ID: <1418140489-21196-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-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 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 a36e6d9..0d874d9 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1219,6 +1219,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 Tue Dec 09 16:01:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:01:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNDz-0004Fa-UM; Tue, 09 Dec 2014 16:01:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyNDy-0004F9-Px
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 16:01:18 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	A3/6C-26858-ECC17845; Tue, 09 Dec 2014 16:01:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418140873!12111208!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 19096 invoked from network); 9 Dec 2014 16:01:16 -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;
	9 Dec 2014 16:01:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202358501"
Message-ID: <1418140797.19809.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 9 Dec 2014 15:59:57 +0000
In-Reply-To: <1418140489-21196-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
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

On Tue, 2014-12-09 at 15:54 +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 Tue Dec 09 16:01:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:01:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNDz-0004Fa-UM; Tue, 09 Dec 2014 16:01:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyNDy-0004F9-Px
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 16:01:18 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	A3/6C-26858-ECC17845; Tue, 09 Dec 2014 16:01:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418140873!12111208!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 19096 invoked from network); 9 Dec 2014 16:01:16 -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;
	9 Dec 2014 16:01:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202358501"
Message-ID: <1418140797.19809.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 9 Dec 2014 15:59:57 +0000
In-Reply-To: <1418140489-21196-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
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

On Tue, 2014-12-09 at 15:54 +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 Tue Dec 09 16:11:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:11:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNMs-0005AD-33; Tue, 09 Dec 2014 16:10: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 1XyNMq-0005A8-CG
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:10:28 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	1C/93-02699-3FE17845; Tue, 09 Dec 2014 16:10:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418141424!13982560!1
X-Originating-IP: [66.165.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 12346 invoked from network); 9 Dec 2014 16:10:26 -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;
	9 Dec 2014 16:10:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202364406"
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.210.2;
	Tue, 9 Dec 2014 11:09: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 1XyNM4-0006Fb-H9;
	Tue, 09 Dec 2014 16:09:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyNM3-0005eC-G2;
	Tue, 09 Dec 2014 16:09:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21639.7875.160312.349247@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 16:09:39 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141208123736.GA3691@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in systemd"):
> On Fri, Dec 05, Ian Jackson wrote:
> > I think the only way to make this work properly is to factor the
> > necessary parts out of init.d/xencommons into a new script which can
> > be used by both xencommons and systemd.  I'm not sure such a patch
> > would be appropriate for 4.5 at this stage.
> 
> I came up with this, it appears to work in my testing. Will do more
> testing later today.

Thanks.  I think this is going in roughly the right direction.

But: I think the script is rather over-engineered, and that it ought
to be in /etc.

> +	$(INSTALL_PROG) $(XENSTORED_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)

Sysadmins might want to edit the script to do something we haven't
thought of.  So it should be in /etc where they can do so.

> diff --git a/tools/hotplug/Linux/xenstored.sh.in b/tools/hotplug/Linux/xenstored.sh.in
> new file mode 100644
> index 0000000..11caf25
> --- /dev/null
> +++ b/tools/hotplug/Linux/xenstored.sh.in
...
> +    case "$1" in
> +    --exec)
> +        do_exec="exec"
> +    ;;
> +    --opt)
> +        opts=(${opts[@]} "$2")
> +        shift
> +    ;;
> +    esac
> +    shift
> +done

I don't think this script wants to contain an option parser!

> +. @XEN_SCRIPT_DIR@/hotplugpath.sh
...
> +test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
...
> +    # Wait for xenstored to actually come up, timing out after 30 seconds
> +    while [ $time -lt $timeout ] && ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1` ; do

I would have expected this new script to contain only the
functionality which was previously both in (a) the systemd unit and
(b) the traditional init script, and which you are removing from both
those places.  So I think you should be able to say "no ultimate
functional change" in your commit message.

The systemd unit doesn't currently contain anything messing about with
xenstore-read to detect when xenstored is working.  Is that a bug that
was previously in the systemd unit, or is it a mistake in your patch
that this is added here ?

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 Dec 09 16:11:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:11:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNMs-0005AD-33; Tue, 09 Dec 2014 16:10: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 1XyNMq-0005A8-CG
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:10:28 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	1C/93-02699-3FE17845; Tue, 09 Dec 2014 16:10:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418141424!13982560!1
X-Originating-IP: [66.165.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 12346 invoked from network); 9 Dec 2014 16:10:26 -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;
	9 Dec 2014 16:10:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202364406"
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.210.2;
	Tue, 9 Dec 2014 11:09: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 1XyNM4-0006Fb-H9;
	Tue, 09 Dec 2014 16:09:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyNM3-0005eC-G2;
	Tue, 09 Dec 2014 16:09:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21639.7875.160312.349247@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 16:09:39 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141208123736.GA3691@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in systemd"):
> On Fri, Dec 05, Ian Jackson wrote:
> > I think the only way to make this work properly is to factor the
> > necessary parts out of init.d/xencommons into a new script which can
> > be used by both xencommons and systemd.  I'm not sure such a patch
> > would be appropriate for 4.5 at this stage.
> 
> I came up with this, it appears to work in my testing. Will do more
> testing later today.

Thanks.  I think this is going in roughly the right direction.

But: I think the script is rather over-engineered, and that it ought
to be in /etc.

> +	$(INSTALL_PROG) $(XENSTORED_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)

Sysadmins might want to edit the script to do something we haven't
thought of.  So it should be in /etc where they can do so.

> diff --git a/tools/hotplug/Linux/xenstored.sh.in b/tools/hotplug/Linux/xenstored.sh.in
> new file mode 100644
> index 0000000..11caf25
> --- /dev/null
> +++ b/tools/hotplug/Linux/xenstored.sh.in
...
> +    case "$1" in
> +    --exec)
> +        do_exec="exec"
> +    ;;
> +    --opt)
> +        opts=(${opts[@]} "$2")
> +        shift
> +    ;;
> +    esac
> +    shift
> +done

I don't think this script wants to contain an option parser!

> +. @XEN_SCRIPT_DIR@/hotplugpath.sh
...
> +test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
...
> +    # Wait for xenstored to actually come up, timing out after 30 seconds
> +    while [ $time -lt $timeout ] && ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1` ; do

I would have expected this new script to contain only the
functionality which was previously both in (a) the systemd unit and
(b) the traditional init script, and which you are removing from both
those places.  So I think you should be able to say "no ultimate
functional change" in your commit message.

The systemd unit doesn't currently contain anything messing about with
xenstore-read to detect when xenstored is working.  Is that a bug that
was previously in the systemd unit, or is it a mistake in your patch
that this is added here ?

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 Dec 09 16:12:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNOQ-0005Hd-HZ; Tue, 09 Dec 2014 16:12: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 1XyNOP-0005Gg-Mi; Tue, 09 Dec 2014 16:12:05 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	42/F4-02954-45F17845; Tue, 09 Dec 2014 16:12:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418141521!13999955!1
X-Originating-IP: [66.165.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 4119 invoked from network); 9 Dec 2014 16:12: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;
	9 Dec 2014 16:12:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202365217"
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.210.2;
	Tue, 9 Dec 2014 11:10:38 -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 1XyNN0-0006GS-N2;
	Tue, 09 Dec 2014 16:10:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyNN0-0005eN-Fi;
	Tue, 09 Dec 2014 16:10:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21639.7934.287371.334691@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 16:10:38 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141209083356.GA21664@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<20141205171102.GA24737@aepfle.de>
	<20141208171949.GA1819@aepfle.de>
	<20141208172307.GA25749@zion.uk.xensource.com>
	<20141208173708.GA6679@aepfle.de>
	<20141208174854.GB25749@zion.uk.xensource.com>
	<20141209083356.GA21664@aepfle.de>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd shutdown hangs the OS"):
> Perhaps a crashed or otherwise unavailable xenstored isnt such a problem
> because its like that since a very long time.

Without xenstored, the system is basically hosed.  And it's not really
restartable.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:12:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNOQ-0005Hd-HZ; Tue, 09 Dec 2014 16:12: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 1XyNOP-0005Gg-Mi; Tue, 09 Dec 2014 16:12:05 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	42/F4-02954-45F17845; Tue, 09 Dec 2014 16:12:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418141521!13999955!1
X-Originating-IP: [66.165.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 4119 invoked from network); 9 Dec 2014 16:12: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;
	9 Dec 2014 16:12:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="scan'208";a="202365217"
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.210.2;
	Tue, 9 Dec 2014 11:10:38 -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 1XyNN0-0006GS-N2;
	Tue, 09 Dec 2014 16:10:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyNN0-0005eN-Fi;
	Tue, 09 Dec 2014 16:10:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21639.7934.287371.334691@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 16:10:38 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141209083356.GA21664@aepfle.de>
References: <948996368.3219599.1417477301121.JavaMail.yahoo@jws10637.mail.bf1.yahoo.com>
	<1417512564.15063.4.camel@citrix.com>
	<20141202151708.GA23112@aepfle.de>
	<20141205171102.GA24737@aepfle.de>
	<20141208171949.GA1819@aepfle.de>
	<20141208172307.GA25749@zion.uk.xensource.com>
	<20141208173708.GA6679@aepfle.de>
	<20141208174854.GB25749@zion.uk.xensource.com>
	<20141209083356.GA21664@aepfle.de>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: Mark Pryor <tlviewer@yahoo.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>, Xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd
 shutdown hangs the OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [Xen-users] 4.5 git: regression in xen systemd shutdown hangs the OS"):
> Perhaps a crashed or otherwise unavailable xenstored isnt such a problem
> because its like that since a very long time.

Without xenstored, the system is basically hosed.  And it's not really
restartable.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:18:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16: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 1XyNUG-0005sg-1q; Tue, 09 Dec 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 <Ian.Jackson@citrix.com>) id 1XyNUE-0005sb-LA
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 16:18:06 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	9F/68-14214-DB027845; Tue, 09 Dec 2014 16:18:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418141883!4816064!1
X-Originating-IP: [66.165.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 4434 invoked from network); 9 Dec 2014 16:18:05 -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;
	9 Dec 2014 16:18:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="201963882"
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.210.2;
	Tue, 9 Dec 2014 11:13: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 1XyNPr-0006K3-L0;
	Tue, 09 Dec 2014 16:13:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyNPr-0005fl-CO;
	Tue, 09 Dec 2014 16:13:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21639.8111.194804.899468@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 16:13:35 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1418140797.19809.16.camel@citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-3-git-send-email-ian.jackson@eu.citrix.com>
	<1418140797.19809.16.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 Tue, 2014-12-09 at 15:54 +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:
...
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.  In fact you had acked this already but somehow I have dropped
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 Dec 09 16:18:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16: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 1XyNUG-0005sg-1q; Tue, 09 Dec 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 <Ian.Jackson@citrix.com>) id 1XyNUE-0005sb-LA
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 16:18:06 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	9F/68-14214-DB027845; Tue, 09 Dec 2014 16:18:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418141883!4816064!1
X-Originating-IP: [66.165.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 4434 invoked from network); 9 Dec 2014 16:18:05 -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;
	9 Dec 2014 16:18:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="201963882"
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.210.2;
	Tue, 9 Dec 2014 11:13: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 1XyNPr-0006K3-L0;
	Tue, 09 Dec 2014 16:13:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyNPr-0005fl-CO;
	Tue, 09 Dec 2014 16:13:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21639.8111.194804.899468@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 16:13:35 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1418140797.19809.16.camel@citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-3-git-send-email-ian.jackson@eu.citrix.com>
	<1418140797.19809.16.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 Tue, 2014-12-09 at 15:54 +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:
...
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.  In fact you had acked this already but somehow I have dropped
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 Dec 09 16:21:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNX3-00063W-Qu; Tue, 09 Dec 2014 16:21: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 1XyNX2-00063N-Ul
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:21:01 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7C/5C-09842-C6127845; Tue, 09 Dec 2014 16:21:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418142057!14471097!1
X-Originating-IP: [156.151.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 11236 invoked from network); 9 Dec 2014 16:20:59 -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; 9 Dec 2014 16:20: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 sB9GKpOt032720
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Dec 2014 16:20:51 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
	sB9GKnid026520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 9 Dec 2014 16:20:50 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
	sB9GKnPn007508; Tue, 9 Dec 2014 16:20:49 GMT
Received: from laptop.dumpdata.com (/10.154.136.116)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Dec 2014 08:20:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 48C08122743; Tue,  9 Dec 2014 11:20:48 -0500 (EST)
Date: Tue, 9 Dec 2014 11:20:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141209162048.GB9585@laptop.dumpdata.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>
	<1418135262.14361.65.camel@citrix.com>
	<54870780.7040801@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54870780.7040801@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@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 Tue, Dec 09, 2014 at 02:30:24PM +0000, Andrew Cooper wrote:
> On 09/12/14 14:27, Ian Campbell wrote:
> > On Fri, 2014-11-28 at 11:37 +0000, 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.
> > Konrad, given
> > http://article.gmane.org/gmane.comp.emulators.xen.devel/224881 does this
> > have a release ack?
> >
> > Ian.
> >
> 
> I can resubmit with a clearer description if that would help clarity,
> but the code is correct for the fixes (not fantastically well) described.

Please do - that is all I was waiting for. 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 Tue Dec 09 16:21:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNX3-00063W-Qu; Tue, 09 Dec 2014 16:21: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 1XyNX2-00063N-Ul
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:21:01 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7C/5C-09842-C6127845; Tue, 09 Dec 2014 16:21:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418142057!14471097!1
X-Originating-IP: [156.151.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 11236 invoked from network); 9 Dec 2014 16:20:59 -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; 9 Dec 2014 16:20: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 sB9GKpOt032720
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Dec 2014 16:20:51 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
	sB9GKnid026520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 9 Dec 2014 16:20:50 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
	sB9GKnPn007508; Tue, 9 Dec 2014 16:20:49 GMT
Received: from laptop.dumpdata.com (/10.154.136.116)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Dec 2014 08:20:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 48C08122743; Tue,  9 Dec 2014 11:20:48 -0500 (EST)
Date: Tue, 9 Dec 2014 11:20:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141209162048.GB9585@laptop.dumpdata.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>
	<1418135262.14361.65.camel@citrix.com>
	<54870780.7040801@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54870780.7040801@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@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 Tue, Dec 09, 2014 at 02:30:24PM +0000, Andrew Cooper wrote:
> On 09/12/14 14:27, Ian Campbell wrote:
> > On Fri, 2014-11-28 at 11:37 +0000, 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.
> > Konrad, given
> > http://article.gmane.org/gmane.comp.emulators.xen.devel/224881 does this
> > have a release ack?
> >
> > Ian.
> >
> 
> I can resubmit with a clearer description if that would help clarity,
> but the code is correct for the fixes (not fantastically well) described.

Please do - that is all I was waiting for. 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 Tue Dec 09 16:26:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16: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 1XyNcF-0006Oj-Kg; Tue, 09 Dec 2014 16:26:23 +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 1XyNcE-0006Oc-DP
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:26:22 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	78/B7-17958-DA227845; Tue, 09 Dec 2014 16:26:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418142379!12098706!1
X-Originating-IP: [156.151.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 30455 invoked from network); 9 Dec 2014 16:26:21 -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; 9 Dec 2014 16:26:21 -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 sB9GQD6o008017
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Dec 2014 16:26:14 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
	sB9GQ41b028320
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 9 Dec 2014 16:26:05 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
	sB9GQ4DG018682; Tue, 9 Dec 2014 16:26:04 GMT
Received: from laptop.dumpdata.com (/10.154.136.116)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Dec 2014 08:26:03 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E5277122798; Tue,  9 Dec 2014 11:26:02 -0500 (EST)
Date: Tue, 9 Dec 2014 11:26:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Message-ID: <20141209162602.GA10129@laptop.dumpdata.com>
References: <1418046707-6900-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1418136450.14361.82.camel@citrix.com>
	<CAN58jisYpvQLDwCmcg0CFHf_HurgtwtHVkH3=QyOP-JjgBczOA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN58jisYpvQLDwCmcg0CFHf_HurgtwtHVkH3=QyOP-JjgBczOA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
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] [PATCH v2] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 05:25:08PM +0200, Oleksandr Dmytryshyn wrote:
> On Tue, Dec 9, 2014 at 4:47 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2014-12-08 at 15:51 +0200, Oleksandr Dmytryshyn wrote:
> >> UART is not able to receive bytes when idle mode is not
> >> configured properly. When we use Xen with old Linux
> >> Kernel (for example 3.8) this kernel configures hwmods
> >> for all devices even if the device tree nodes for those
> >> devices is absent in device tree. Thus UART idle mode
> >> is configured too. The fake node for the UART should
> >> be added to the device tree because the MMIO range
> >> is not mapped by Xen. So UART works normally in this
> >> case. But new Linux Kernel (3.12 and upper) doesn't
> >> configure idle mode for UART and UART can not work
> >> normally in this case.
> >
> > I think the focus is too much on the hack done with 3.8 to make this
> > work rather than on the fix being made here itself. The hack is only
> > really of peripheral/historic interest.
> >
> > How about instead:
> >
> >         The UART is not able to receive bytes when idle mode is not
> >         configured properly, therefore setup the UART with autoidle and
> >         wakeup enabled.
> >
> > You could stop here or if you really want to cover the old hack you
> > could go on to say:
> >
> >         Older Linux kernels (for example 3.8) configures hwmods for all
> >         devices even if the device tree nodes for those devices is
> >         absent in device tree, thus UART idle mode is configured too.
> >         With such kernels we can workaround the issue by adding a fake
> >         node in the UART containing this MMIO range, which is therefore
> >         mapped by Xen to dom0, which reconfigures the UART, causing
> >         things to work normally.
> >
> >         Newer Linux Kernels (3.12 and beyond) do not configure idle mode
> >         for UART and so this hack no longer works.
> >
> > If you are happy with the proposed wording (and indicate whether you
> > want both bits or just the first) then, subject to Konrad giving a
> > release Ack I'd be happy with this for 4.5 and I'll change the commit
> > log as I go.
> I'm fully happy with proposed wording (and want the both bits to be used)
> 
> > Konrad, this is a bug fix for a particular piece of hardware, it can't
> > affect anything other than the OMAP ARM platform.

OK, RElease-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >
> >
> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >
> >> ---
> >> Changed since v1:
> >>  * corrected commit message
> >>
> >>  xen/drivers/char/omap-uart.c | 3 +++
> >>  xen/include/xen/8250-uart.h  | 4 ++++
> >>  2 files changed, 7 insertions(+)
> >>
> >> diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
> >> index a798b8d..16d1454 100644
> >> --- a/xen/drivers/char/omap-uart.c
> >> +++ b/xen/drivers/char/omap-uart.c
> >> @@ -195,6 +195,9 @@ static void __init omap_uart_init_preirq(struct serial_port *port)
> >>      omap_write(uart, UART_MCR, UART_MCR_DTR|UART_MCR_RTS);
> >>
> >>      omap_write(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
> >> +
> >> +    /* setup iddle mode */
> >> +    omap_write(uart, UART_SYSC, OMAP_UART_SYSC_DEF_CONF);
> >>  }
> >>
> >>  static void __init omap_uart_init_postirq(struct serial_port *port)
> >> diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
> >> index a682bae..304b9dd 100644
> >> --- a/xen/include/xen/8250-uart.h
> >> +++ b/xen/include/xen/8250-uart.h
> >> @@ -32,6 +32,7 @@
> >>  #define UART_MCR          0x04    /* Modem control        */
> >>  #define UART_LSR          0x05    /* line status          */
> >>  #define UART_MSR          0x06    /* Modem status         */
> >> +#define UART_SYSC         0x15    /* System configuration register */
> >>  #define UART_USR          0x1f    /* Status register (DW) */
> >>  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
> >>  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
> >> @@ -145,6 +146,9 @@
> >>  /* SCR register bitmasks */
> >>  #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 << 7)
> >>
> >> +/* System configuration register */
> >> +#define OMAP_UART_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is enabled */
> >> +
> >>  #endif /* __XEN_8250_UART_H__ */
> >>
> >>  /*
> >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:26:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16: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 1XyNcF-0006Oj-Kg; Tue, 09 Dec 2014 16:26:23 +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 1XyNcE-0006Oc-DP
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:26:22 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	78/B7-17958-DA227845; Tue, 09 Dec 2014 16:26:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418142379!12098706!1
X-Originating-IP: [156.151.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 30455 invoked from network); 9 Dec 2014 16:26:21 -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; 9 Dec 2014 16:26:21 -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 sB9GQD6o008017
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Dec 2014 16:26:14 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
	sB9GQ41b028320
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 9 Dec 2014 16:26:05 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
	sB9GQ4DG018682; Tue, 9 Dec 2014 16:26:04 GMT
Received: from laptop.dumpdata.com (/10.154.136.116)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Dec 2014 08:26:03 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E5277122798; Tue,  9 Dec 2014 11:26:02 -0500 (EST)
Date: Tue, 9 Dec 2014 11:26:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Message-ID: <20141209162602.GA10129@laptop.dumpdata.com>
References: <1418046707-6900-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1418136450.14361.82.camel@citrix.com>
	<CAN58jisYpvQLDwCmcg0CFHf_HurgtwtHVkH3=QyOP-JjgBczOA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN58jisYpvQLDwCmcg0CFHf_HurgtwtHVkH3=QyOP-JjgBczOA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
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] [PATCH v2] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 05:25:08PM +0200, Oleksandr Dmytryshyn wrote:
> On Tue, Dec 9, 2014 at 4:47 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2014-12-08 at 15:51 +0200, Oleksandr Dmytryshyn wrote:
> >> UART is not able to receive bytes when idle mode is not
> >> configured properly. When we use Xen with old Linux
> >> Kernel (for example 3.8) this kernel configures hwmods
> >> for all devices even if the device tree nodes for those
> >> devices is absent in device tree. Thus UART idle mode
> >> is configured too. The fake node for the UART should
> >> be added to the device tree because the MMIO range
> >> is not mapped by Xen. So UART works normally in this
> >> case. But new Linux Kernel (3.12 and upper) doesn't
> >> configure idle mode for UART and UART can not work
> >> normally in this case.
> >
> > I think the focus is too much on the hack done with 3.8 to make this
> > work rather than on the fix being made here itself. The hack is only
> > really of peripheral/historic interest.
> >
> > How about instead:
> >
> >         The UART is not able to receive bytes when idle mode is not
> >         configured properly, therefore setup the UART with autoidle and
> >         wakeup enabled.
> >
> > You could stop here or if you really want to cover the old hack you
> > could go on to say:
> >
> >         Older Linux kernels (for example 3.8) configures hwmods for all
> >         devices even if the device tree nodes for those devices is
> >         absent in device tree, thus UART idle mode is configured too.
> >         With such kernels we can workaround the issue by adding a fake
> >         node in the UART containing this MMIO range, which is therefore
> >         mapped by Xen to dom0, which reconfigures the UART, causing
> >         things to work normally.
> >
> >         Newer Linux Kernels (3.12 and beyond) do not configure idle mode
> >         for UART and so this hack no longer works.
> >
> > If you are happy with the proposed wording (and indicate whether you
> > want both bits or just the first) then, subject to Konrad giving a
> > release Ack I'd be happy with this for 4.5 and I'll change the commit
> > log as I go.
> I'm fully happy with proposed wording (and want the both bits to be used)
> 
> > Konrad, this is a bug fix for a particular piece of hardware, it can't
> > affect anything other than the OMAP ARM platform.

OK, RElease-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >
> >
> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
> >
> >> ---
> >> Changed since v1:
> >>  * corrected commit message
> >>
> >>  xen/drivers/char/omap-uart.c | 3 +++
> >>  xen/include/xen/8250-uart.h  | 4 ++++
> >>  2 files changed, 7 insertions(+)
> >>
> >> diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
> >> index a798b8d..16d1454 100644
> >> --- a/xen/drivers/char/omap-uart.c
> >> +++ b/xen/drivers/char/omap-uart.c
> >> @@ -195,6 +195,9 @@ static void __init omap_uart_init_preirq(struct serial_port *port)
> >>      omap_write(uart, UART_MCR, UART_MCR_DTR|UART_MCR_RTS);
> >>
> >>      omap_write(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
> >> +
> >> +    /* setup iddle mode */
> >> +    omap_write(uart, UART_SYSC, OMAP_UART_SYSC_DEF_CONF);
> >>  }
> >>
> >>  static void __init omap_uart_init_postirq(struct serial_port *port)
> >> diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
> >> index a682bae..304b9dd 100644
> >> --- a/xen/include/xen/8250-uart.h
> >> +++ b/xen/include/xen/8250-uart.h
> >> @@ -32,6 +32,7 @@
> >>  #define UART_MCR          0x04    /* Modem control        */
> >>  #define UART_LSR          0x05    /* line status          */
> >>  #define UART_MSR          0x06    /* Modem status         */
> >> +#define UART_SYSC         0x15    /* System configuration register */
> >>  #define UART_USR          0x1f    /* Status register (DW) */
> >>  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
> >>  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
> >> @@ -145,6 +146,9 @@
> >>  /* SCR register bitmasks */
> >>  #define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 << 7)
> >>
> >> +/* System configuration register */
> >> +#define OMAP_UART_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is enabled */
> >> +
> >>  #endif /* __XEN_8250_UART_H__ */
> >>
> >>  /*
> >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:28:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16: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 1XyNdb-0006bd-3i; Tue, 09 Dec 2014 16:27:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XyNdZ-0006bV-5c
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:27:45 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	CE/FE-25276-00327845; Tue, 09 Dec 2014 16:27:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418142463!14407275!1
X-Originating-IP: [81.169.146.220]
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 14506 invoked from network); 9 Dec 2014 16:27:44 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 16:27:44 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418142463; l=1869;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=fXgrrOIwVU+ha9zHbmlL1cIbbKc=;
	b=XZp7di9vIBamBq5bInx26kSVyD1bX4zBUosljVizeQDb3zYolBkuU3W6cihnpnEAz5V
	CplG6iq83Wbc/LTYaYzUp7X9nFdqFZbtyIPxt4RnlVyDQOp/yd4Fnzjez7UoOgeAgykD1
	tIEoSkcP34y6BelLOmsjFN+3i2KRJARJJOw=
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.3 AUTH) with ESMTPSA id j074acqB9GRe34L
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 9 Dec 2014 17:27:40 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 3D9D45015F; Tue,  9 Dec 2014 17:27:40 +0100 (CET)
Date: Tue, 9 Dec 2014 17:27:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141209162740.GA14288@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21639.7875.160312.349247@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, Ian Jackson wrote:

> Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in systemd"):
> > On Fri, Dec 05, Ian Jackson wrote:
> > > I think the only way to make this work properly is to factor the
> > > necessary parts out of init.d/xencommons into a new script which can
> > > be used by both xencommons and systemd.  I'm not sure such a patch
> > > would be appropriate for 4.5 at this stage.
> > 
> > I came up with this, it appears to work in my testing. Will do more
> > testing later today.
> 
> Thanks.  I think this is going in roughly the right direction.
> 
> But: I think the script is rather over-engineered, and that it ought
> to be in /etc.

Why should the wrapper be in /etc?!
xendomains isnt in /etc either.

> > +	$(INSTALL_PROG) $(XENSTORED_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)
> 
> Sysadmins might want to edit the script to do something we haven't
> thought of.  So it should be in /etc where they can do so.

So they should mail here if they find substantial functionality missing.
Until then they continue to not enable xencommons and run their own
startup script.

> I don't think this script wants to contain an option parser!

How should it handle exec vs. no-exec? Just a single yes/no knob, so
essentially sysv vs systemd?

> The systemd unit doesn't currently contain anything messing about with
> xenstore-read to detect when xenstored is working.  Is that a bug that
> was previously in the systemd unit, or is it a mistake in your patch
> that this is added here ?

No idea how long it takes to have a functional xenstored after running
it. Perhaps the forking has some overhead and it returns earlier than it
can process requests. If thats the reason why the loop exists in the
sysv runlevel script then that loop should be used only without --no-fork.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:28:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16: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 1XyNdb-0006bd-3i; Tue, 09 Dec 2014 16:27:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XyNdZ-0006bV-5c
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:27:45 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	CE/FE-25276-00327845; Tue, 09 Dec 2014 16:27:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418142463!14407275!1
X-Originating-IP: [81.169.146.220]
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 14506 invoked from network); 9 Dec 2014 16:27:44 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 16:27:44 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418142463; l=1869;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=fXgrrOIwVU+ha9zHbmlL1cIbbKc=;
	b=XZp7di9vIBamBq5bInx26kSVyD1bX4zBUosljVizeQDb3zYolBkuU3W6cihnpnEAz5V
	CplG6iq83Wbc/LTYaYzUp7X9nFdqFZbtyIPxt4RnlVyDQOp/yd4Fnzjez7UoOgeAgykD1
	tIEoSkcP34y6BelLOmsjFN+3i2KRJARJJOw=
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.3 AUTH) with ESMTPSA id j074acqB9GRe34L
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 9 Dec 2014 17:27:40 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 3D9D45015F; Tue,  9 Dec 2014 17:27:40 +0100 (CET)
Date: Tue, 9 Dec 2014 17:27:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141209162740.GA14288@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21639.7875.160312.349247@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, Ian Jackson wrote:

> Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in systemd"):
> > On Fri, Dec 05, Ian Jackson wrote:
> > > I think the only way to make this work properly is to factor the
> > > necessary parts out of init.d/xencommons into a new script which can
> > > be used by both xencommons and systemd.  I'm not sure such a patch
> > > would be appropriate for 4.5 at this stage.
> > 
> > I came up with this, it appears to work in my testing. Will do more
> > testing later today.
> 
> Thanks.  I think this is going in roughly the right direction.
> 
> But: I think the script is rather over-engineered, and that it ought
> to be in /etc.

Why should the wrapper be in /etc?!
xendomains isnt in /etc either.

> > +	$(INSTALL_PROG) $(XENSTORED_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)
> 
> Sysadmins might want to edit the script to do something we haven't
> thought of.  So it should be in /etc where they can do so.

So they should mail here if they find substantial functionality missing.
Until then they continue to not enable xencommons and run their own
startup script.

> I don't think this script wants to contain an option parser!

How should it handle exec vs. no-exec? Just a single yes/no knob, so
essentially sysv vs systemd?

> The systemd unit doesn't currently contain anything messing about with
> xenstore-read to detect when xenstored is working.  Is that a bug that
> was previously in the systemd unit, or is it a mistake in your patch
> that this is added here ?

No idea how long it takes to have a functional xenstored after running
it. Perhaps the forking has some overhead and it returns earlier than it
can process requests. If thats the reason why the loop exists in the
sysv runlevel script then that loop should be used only without --no-fork.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:37:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16: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 1XyNmR-0007L8-Mj; Tue, 09 Dec 2014 16:36:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XyNmQ-0007Kz-Ba
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:36:54 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	98/EC-09284-52527845; Tue, 09 Dec 2014 16:36:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418143011!12000676!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9014 invoked from network); 9 Dec 2014 16:36:53 -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; 9 Dec 2014 16:36:53 -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 sB9Gae62031177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Dec 2014 16:36:41 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
	sB9GadIg022515
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 9 Dec 2014 16:36:40 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
	sB9Gada4006217; Tue, 9 Dec 2014 16:36:39 GMT
Received: from laptop.dumpdata.com (/10.154.136.116)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Dec 2014 08:36:39 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EBE001227A6; Tue,  9 Dec 2014 11:36:37 -0500 (EST)
Date: Tue, 9 Dec 2014 11:36:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141209163637.GB10129@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<20141202193943.GC357@laptop.dumpdata.com>
	<548517F7.6040106@intel.com>
	<20141208155734.GE7745@laptop.dumpdata.com>
	<54864B1C.6020701@intel.com>
	<5486C204020000780004DF9A@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5486C204020000780004DF9A@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	yang.z.zhang@intel.com, Tiejun Chen <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 08:33:56AM +0000, Jan Beulich wrote:
> >>> On 09.12.14 at 02:06, <tiejun.chen@intel.com> wrote:
> >>>> Also how does this work with 32-bit dom0s? Is there a need to use the
> >>>> compat layer?
> >>>
> >>> Are you saying in xsm case? Others?
> >>>
> >>> Actually this new DOMCTL is similar with XEN_DOMCTL_assign_device in some
> >>> senses but I don't see such an issue you're pointing.
> >>
> >> I was thinking about the compat layer and making sure it works properly.
> > 
> > Do we really need this consideration? I mean I referred to that existing 
> > XEN_DOMCTL_assign_device to implement this new DOMCTL, but looks there's 
> > nothing related to this point.
> > 
> > Or could you make your thought clear to me with an exiting example? Then 
> > I can take a look at what exactly should be taken in my new DOMCTL since 
> > I'm a fresh man to work out this properly inside xen.
> 
> I think Konrad got a little confused here - domctl-s intentionally are
> structured so that they don't need a compat translation layer.

Ah! Thank you for that reminder!
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:37:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16: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 1XyNmR-0007L8-Mj; Tue, 09 Dec 2014 16:36:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XyNmQ-0007Kz-Ba
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:36:54 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	98/EC-09284-52527845; Tue, 09 Dec 2014 16:36:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418143011!12000676!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9014 invoked from network); 9 Dec 2014 16:36:53 -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; 9 Dec 2014 16:36:53 -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 sB9Gae62031177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Dec 2014 16:36:41 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
	sB9GadIg022515
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 9 Dec 2014 16:36:40 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
	sB9Gada4006217; Tue, 9 Dec 2014 16:36:39 GMT
Received: from laptop.dumpdata.com (/10.154.136.116)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Dec 2014 08:36:39 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EBE001227A6; Tue,  9 Dec 2014 11:36:37 -0500 (EST)
Date: Tue, 9 Dec 2014 11:36:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141209163637.GB10129@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-3-git-send-email-tiejun.chen@intel.com>
	<20141202193943.GC357@laptop.dumpdata.com>
	<548517F7.6040106@intel.com>
	<20141208155734.GE7745@laptop.dumpdata.com>
	<54864B1C.6020701@intel.com>
	<5486C204020000780004DF9A@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5486C204020000780004DF9A@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	yang.z.zhang@intel.com, Tiejun Chen <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 02/17] introduce XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 08:33:56AM +0000, Jan Beulich wrote:
> >>> On 09.12.14 at 02:06, <tiejun.chen@intel.com> wrote:
> >>>> Also how does this work with 32-bit dom0s? Is there a need to use the
> >>>> compat layer?
> >>>
> >>> Are you saying in xsm case? Others?
> >>>
> >>> Actually this new DOMCTL is similar with XEN_DOMCTL_assign_device in some
> >>> senses but I don't see such an issue you're pointing.
> >>
> >> I was thinking about the compat layer and making sure it works properly.
> > 
> > Do we really need this consideration? I mean I referred to that existing 
> > XEN_DOMCTL_assign_device to implement this new DOMCTL, but looks there's 
> > nothing related to this point.
> > 
> > Or could you make your thought clear to me with an exiting example? Then 
> > I can take a look at what exactly should be taken in my new DOMCTL since 
> > I'm a fresh man to work out this properly inside xen.
> 
> I think Konrad got a little confused here - domctl-s intentionally are
> structured so that they don't need a compat translation layer.

Ah! Thank you for that reminder!
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:47:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNvr-0007xG-Ak; Tue, 09 Dec 2014 16:46:39 +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 1XyNvp-0007ww-PX
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 16:46:37 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	60/41-24859-D6727845; Tue, 09 Dec 2014 16:46:37 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418143596!12082258!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 19276 invoked from network); 9 Dec 2014 16:46:36 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-4.tower-31.messagelabs.com with SMTP;
	9 Dec 2014 16:46:36 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id CA2FB16410B;
	Tue,  9 Dec 2014 16:46:24 +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 Y76pxD9z+5MZ; Tue,  9 Dec 2014 16:46:08 +0000 (GMT)
Received: from [10.0.2.15] (unknown [192.168.1.39])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id D73D8161F9B;
	Tue,  9 Dec 2014 16:46:07 +0000 (GMT)
Message-ID: <5487274F.2090700@overnetdata.com>
Date: Tue, 09 Dec 2014 16:46:07 +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: David Vrabel <david.vrabel@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <5478926A.80503@overnetdata.com> <54859375.30209@citrix.com>
In-Reply-To: <54859375.30209@citrix.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 08/12/2014 12:03, David Vrabel wrote:
> Does this patch to netfront fix it?
>
> 8<---------------------------------------------
> xen-netfront: use correct linear area after linearizing an skb
>
> Commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d (xen-netfront: Fix
> handling packets on compound pages with skb_linearize) attempted to
> fix a problem where an skb that would have required too many slots
> would be dropped causing TCP connections to stall.
>
> However, it filled in the first slot using the original buffer and not
> the new one and would use the wrong offset and grant access to the
> wrong page.
>
> Netback would notice the malformed request and stop all traffic on the
> VIF, reporting:
>
>     vif vif-3-0 vif3.0: txreq.offset: 85e, size: 4002, end: 6144
>     vif vif-3-0 vif3.0: fatal error; disabling device
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  drivers/net/xen-netfront.c |    3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index ece8d18..eeed0ce 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -627,6 +627,9 @@ static int xennet_start_xmit(struct sk_buff *skb,
> struct net_device *dev)
>  				    slots, skb->len);
>  		if (skb_linearize(skb))
>  			goto drop;
> +		data = skb->data;
> +		offset = offset_in_page(data);
> +		len = skb_headlen(skb);
>  	}
>
>  	spin_lock_irqsave(&queue->tx_lock, flags);
The patch seems to have worked. Before we'd managed to reproduce the
problem in under 10 seconds, with the patch we haven't seen the problem
on the test or production systems.

Thank you.

Anthony.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:47:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNvh-0007w9-Ot; Tue, 09 Dec 2014 16:46:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyNvg-0007w3-7t
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:46:28 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	36/9E-26740-36727845; Tue, 09 Dec 2014 16:46:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418143586!8408393!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4053 invoked from network); 9 Dec 2014 16:46:26 -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; 9 Dec 2014 16:46:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 16:46:26 +0000
Message-Id: <5487356E020000780004E362@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 16:46:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-13-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417448023-27311-13-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 12/19] hvmloader: retrieve vNUMA
 information from 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 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> @@ -261,6 +262,8 @@ int main(void)
>  
>      init_hypercalls();
>  
> +    init_vnuma_info();

This is very early, and I don't think it needs to be - I guess it could be
done right before doing ACPI stuff?

> --- /dev/null
> +++ b/tools/firmware/hvmloader/vnuma.c
> @@ -0,0 +1,84 @@
> +/*
> + * vnuma.c: obtain vNUMA information from hypervisor
> + *
> + * Copyright (c) 2014 Wei Liu, Citrix Systems (R&D) Ltd.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *    notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *    notice, this list of conditions and the following disclaimer in the
> + *    documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED.  IN NO EVENT SHALL AUTHOR 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 "util.h"
> +#include "hypercall.h"
> +#include "vnuma.h"
> +#include <errno.h>

This is the system header, not the Xen one. See the discussion at
http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg03206.html
and perhaps build on the resulting patch
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00013.html.

> +
> +unsigned int nr_vnodes, nr_vmemranges;
> +unsigned int *vcpu_to_vnode, *vdistance;
> +xen_vmemrange_t *vmemrange;
> +
> +void init_vnuma_info(void)
> +{
> +    int rc, retry = 0;
> +    struct xen_vnuma_topology_info vnuma_topo = {
> +        .domid = DOMID_SELF,
> +    };
> +
> +    vcpu_to_vnode = scratch_alloc(sizeof(uint32_t) * hvm_info->nr_vcpus, 0);
> +    vdistance = scratch_alloc(sizeof(uint32_t) * MAX_VDISTANCE, 0);
> +    vmemrange = scratch_alloc(sizeof(xen_vmemrange_t) * MAX_VMEMRANGES, 0);
> +
> +    vnuma_topo.nr_vnodes = MAX_VNODES;
> +    vnuma_topo.nr_vcpus = hvm_info->nr_vcpus;
> +    vnuma_topo.nr_vmemranges = MAX_VMEMRANGES;
> +
> +    set_xen_guest_handle(vnuma_topo.vdistance.h, vdistance);
> +    set_xen_guest_handle(vnuma_topo.vcpu_to_vnode.h, vcpu_to_vnode);
> +    set_xen_guest_handle(vnuma_topo.vmemrange.h, vmemrange);
> +
> +    rc = hypercall_memory_op(XENMEM_get_vnumainfo, &vnuma_topo);
> +    while ( rc == -EAGAIN && retry < 10 )
> +    {
> +        rc = hypercall_memory_op(XENMEM_get_vnumainfo, &vnuma_topo);
> +        retry++;
> +    }
> +    if ( rc < 0 )
> +    {
> +        printf("Failed to retrieve vNUMA information, rc = %d\n", rc);
> +        goto out;

return;

> +    }
> +
> +    nr_vnodes = vnuma_topo.nr_vnodes;
> +    nr_vmemranges = vnuma_topo.nr_vmemranges;
> +
> +out:
> +    return;

Drop these two (or really three) unnecessary lines please.

> --- /dev/null
> +++ b/tools/firmware/hvmloader/vnuma.h
> @@ -0,0 +1,56 @@
> +/******************************************************************************
> + * vnuma.h
> + *
> + * Copyright (c) 2014, Wei Liu
> + *
> + * 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 __HVMLOADER_VNUMA_H__
> +#define __HVMLOADER_VNUMA_H__
> +
> +#include <xen/memory.h>
> +
> +#define MAX_VNODES     64
> +#define MAX_VDISTANCE  (MAX_VNODES * MAX_VNODES)
> +#define MAX_VMEMRANGES (MAX_VNODES * 2)

These look arbitrary - please add a (brief) comment giving some
rationale so that people needing to change them know eventual
consequences. Would it perhaps make sense to derive
MAX_VNODES from HVM_MAX_VCPUS? Additionally I think the
code wouldn't become much more difficult if you didn't build in
static upper limits.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:47:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNvr-0007xG-Ak; Tue, 09 Dec 2014 16:46:39 +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 1XyNvp-0007ww-PX
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 16:46:37 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	60/41-24859-D6727845; Tue, 09 Dec 2014 16:46:37 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418143596!12082258!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 19276 invoked from network); 9 Dec 2014 16:46:36 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-4.tower-31.messagelabs.com with SMTP;
	9 Dec 2014 16:46:36 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id CA2FB16410B;
	Tue,  9 Dec 2014 16:46:24 +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 Y76pxD9z+5MZ; Tue,  9 Dec 2014 16:46:08 +0000 (GMT)
Received: from [10.0.2.15] (unknown [192.168.1.39])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id D73D8161F9B;
	Tue,  9 Dec 2014 16:46:07 +0000 (GMT)
Message-ID: <5487274F.2090700@overnetdata.com>
Date: Tue, 09 Dec 2014 16:46:07 +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: David Vrabel <david.vrabel@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <5478926A.80503@overnetdata.com> <54859375.30209@citrix.com>
In-Reply-To: <54859375.30209@citrix.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 08/12/2014 12:03, David Vrabel wrote:
> Does this patch to netfront fix it?
>
> 8<---------------------------------------------
> xen-netfront: use correct linear area after linearizing an skb
>
> Commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d (xen-netfront: Fix
> handling packets on compound pages with skb_linearize) attempted to
> fix a problem where an skb that would have required too many slots
> would be dropped causing TCP connections to stall.
>
> However, it filled in the first slot using the original buffer and not
> the new one and would use the wrong offset and grant access to the
> wrong page.
>
> Netback would notice the malformed request and stop all traffic on the
> VIF, reporting:
>
>     vif vif-3-0 vif3.0: txreq.offset: 85e, size: 4002, end: 6144
>     vif vif-3-0 vif3.0: fatal error; disabling device
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  drivers/net/xen-netfront.c |    3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index ece8d18..eeed0ce 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -627,6 +627,9 @@ static int xennet_start_xmit(struct sk_buff *skb,
> struct net_device *dev)
>  				    slots, skb->len);
>  		if (skb_linearize(skb))
>  			goto drop;
> +		data = skb->data;
> +		offset = offset_in_page(data);
> +		len = skb_headlen(skb);
>  	}
>
>  	spin_lock_irqsave(&queue->tx_lock, flags);
The patch seems to have worked. Before we'd managed to reproduce the
problem in under 10 seconds, with the patch we haven't seen the problem
on the test or production systems.

Thank you.

Anthony.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:47:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyNvh-0007w9-Ot; Tue, 09 Dec 2014 16:46:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyNvg-0007w3-7t
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:46:28 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	36/9E-26740-36727845; Tue, 09 Dec 2014 16:46:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418143586!8408393!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4053 invoked from network); 9 Dec 2014 16:46:26 -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; 9 Dec 2014 16:46:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 16:46:26 +0000
Message-Id: <5487356E020000780004E362@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 16:46:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-13-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417448023-27311-13-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 12/19] hvmloader: retrieve vNUMA
 information from 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 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> @@ -261,6 +262,8 @@ int main(void)
>  
>      init_hypercalls();
>  
> +    init_vnuma_info();

This is very early, and I don't think it needs to be - I guess it could be
done right before doing ACPI stuff?

> --- /dev/null
> +++ b/tools/firmware/hvmloader/vnuma.c
> @@ -0,0 +1,84 @@
> +/*
> + * vnuma.c: obtain vNUMA information from hypervisor
> + *
> + * Copyright (c) 2014 Wei Liu, Citrix Systems (R&D) Ltd.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *    notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *    notice, this list of conditions and the following disclaimer in the
> + *    documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED.  IN NO EVENT SHALL AUTHOR 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 "util.h"
> +#include "hypercall.h"
> +#include "vnuma.h"
> +#include <errno.h>

This is the system header, not the Xen one. See the discussion at
http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg03206.html
and perhaps build on the resulting patch
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00013.html.

> +
> +unsigned int nr_vnodes, nr_vmemranges;
> +unsigned int *vcpu_to_vnode, *vdistance;
> +xen_vmemrange_t *vmemrange;
> +
> +void init_vnuma_info(void)
> +{
> +    int rc, retry = 0;
> +    struct xen_vnuma_topology_info vnuma_topo = {
> +        .domid = DOMID_SELF,
> +    };
> +
> +    vcpu_to_vnode = scratch_alloc(sizeof(uint32_t) * hvm_info->nr_vcpus, 0);
> +    vdistance = scratch_alloc(sizeof(uint32_t) * MAX_VDISTANCE, 0);
> +    vmemrange = scratch_alloc(sizeof(xen_vmemrange_t) * MAX_VMEMRANGES, 0);
> +
> +    vnuma_topo.nr_vnodes = MAX_VNODES;
> +    vnuma_topo.nr_vcpus = hvm_info->nr_vcpus;
> +    vnuma_topo.nr_vmemranges = MAX_VMEMRANGES;
> +
> +    set_xen_guest_handle(vnuma_topo.vdistance.h, vdistance);
> +    set_xen_guest_handle(vnuma_topo.vcpu_to_vnode.h, vcpu_to_vnode);
> +    set_xen_guest_handle(vnuma_topo.vmemrange.h, vmemrange);
> +
> +    rc = hypercall_memory_op(XENMEM_get_vnumainfo, &vnuma_topo);
> +    while ( rc == -EAGAIN && retry < 10 )
> +    {
> +        rc = hypercall_memory_op(XENMEM_get_vnumainfo, &vnuma_topo);
> +        retry++;
> +    }
> +    if ( rc < 0 )
> +    {
> +        printf("Failed to retrieve vNUMA information, rc = %d\n", rc);
> +        goto out;

return;

> +    }
> +
> +    nr_vnodes = vnuma_topo.nr_vnodes;
> +    nr_vmemranges = vnuma_topo.nr_vmemranges;
> +
> +out:
> +    return;

Drop these two (or really three) unnecessary lines please.

> --- /dev/null
> +++ b/tools/firmware/hvmloader/vnuma.h
> @@ -0,0 +1,56 @@
> +/******************************************************************************
> + * vnuma.h
> + *
> + * Copyright (c) 2014, Wei Liu
> + *
> + * 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 __HVMLOADER_VNUMA_H__
> +#define __HVMLOADER_VNUMA_H__
> +
> +#include <xen/memory.h>
> +
> +#define MAX_VNODES     64
> +#define MAX_VDISTANCE  (MAX_VNODES * MAX_VNODES)
> +#define MAX_VMEMRANGES (MAX_VNODES * 2)

These look arbitrary - please add a (brief) comment giving some
rationale so that people needing to change them know eventual
consequences. Would it perhaps make sense to derive
MAX_VNODES from HVM_MAX_VCPUS? Additionally I think the
code wouldn't become much more difficult if you didn't build in
static upper limits.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16: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 1XyO2o-0008QD-86; Tue, 09 Dec 2014 16:53: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 1XyO2n-0008Q8-3I
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:53:49 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	EB/D5-02696-81927845; Tue, 09 Dec 2014 16:53:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418144023!8560864!1
X-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 9802 invoked from network); 9 Dec 2014 16:53:43 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 16:53:43 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 16:53:43 +0000
Message-Id: <54873724020000780004E37B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 16:53:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 13/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 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> @@ -203,6 +204,65 @@ 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) * nr_vmemranges;
> +
> +    p = mem_alloc(size, 16);
> +    if (!p) return NULL;

Coding style (despite you likely copied it from elsewhere).

> +
> +    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   = vcpu_to_vnode[i];
> +        processor->apic_id  = LAPIC_ID(i);
> +        processor->flags    = ACPI_LOCAL_APIC_AFFIN_ENABLED;
> +        processor++;
> +    }
> +
> +    memory = (struct acpi_20_srat_memory *)processor;
> +    for ( i = 0; i < nr_vmemranges; i++ )
> +    {
> +        mem = vmemrange[i].end - vmemrange[i].start;

Do you really need this helper variable?

> +        memset(memory, 0, sizeof(*memory));
> +        memory->type          = ACPI_MEMORY_AFFINITY;
> +        memory->length        = sizeof(*memory);
> +        memory->domain        = vmemrange[i].nid;
> +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
> +        memory->base_address  = vmemrange[i].start;
> +        memory->mem_length    = mem;
> +        memory++;
> +    }
> +
> +    srat->header.length = size;

Mind checking size == memory - p here?

> @@ -346,6 +407,16 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
>          }
>      }
>  
> +    /* SRAT */
> +    if ( nr_vnodes > 0 )
> +    {
> +        srat = construct_srat();
> +        if (srat)

Coding style again.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:54:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16: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 1XyO2o-0008QD-86; Tue, 09 Dec 2014 16:53: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 1XyO2n-0008Q8-3I
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:53:49 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	EB/D5-02696-81927845; Tue, 09 Dec 2014 16:53:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418144023!8560864!1
X-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 9802 invoked from network); 9 Dec 2014 16:53:43 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 16:53:43 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 16:53:43 +0000
Message-Id: <54873724020000780004E37B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 16:53:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 13/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 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> @@ -203,6 +204,65 @@ 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) * nr_vmemranges;
> +
> +    p = mem_alloc(size, 16);
> +    if (!p) return NULL;

Coding style (despite you likely copied it from elsewhere).

> +
> +    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   = vcpu_to_vnode[i];
> +        processor->apic_id  = LAPIC_ID(i);
> +        processor->flags    = ACPI_LOCAL_APIC_AFFIN_ENABLED;
> +        processor++;
> +    }
> +
> +    memory = (struct acpi_20_srat_memory *)processor;
> +    for ( i = 0; i < nr_vmemranges; i++ )
> +    {
> +        mem = vmemrange[i].end - vmemrange[i].start;

Do you really need this helper variable?

> +        memset(memory, 0, sizeof(*memory));
> +        memory->type          = ACPI_MEMORY_AFFINITY;
> +        memory->length        = sizeof(*memory);
> +        memory->domain        = vmemrange[i].nid;
> +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
> +        memory->base_address  = vmemrange[i].start;
> +        memory->mem_length    = mem;
> +        memory++;
> +    }
> +
> +    srat->header.length = size;

Mind checking size == memory - p here?

> @@ -346,6 +407,16 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
>          }
>      }
>  
> +    /* SRAT */
> +    if ( nr_vnodes > 0 )
> +    {
> +        srat = construct_srat();
> +        if (srat)

Coding style again.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:54:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyO3I-0008S5-LC; Tue, 09 Dec 2014 16:54:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XyO3H-0008Ru-63
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:54:19 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	95/A5-27584-A3927845; Tue, 09 Dec 2014 16:54:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418144053!12406173!1
X-Originating-IP: [66.165.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 14822 invoked from network); 9 Dec 2014 16:54:16 -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;
	9 Dec 2014 16:54:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="201981378"
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.210.2;
	Tue, 9 Dec 2014 11:43:24 -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
	1XyNsh-0006pJ-NQ; Tue, 09 Dec 2014 16:43:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Tue, 9 Dec 2014 16:43:22 +0000
Message-ID: <1418143402-29674-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <20141209162048.GB9585@laptop.dumpdata.com>
References: <20141209162048.GB9585@laptop.dumpdata.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 v2 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.

Coverity also complains about passing a non-NUL terminated string to
xc_flask_context_to_sid().  xc_flask_context_to_sid() doesn't actually take a
NUL terminated string, but it does take a char* which, in context, used to be
a string, which is why Coverity complains.

One solution would be to use strdup(ctx) which is simpler than a
strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated
string being used with xc_flask_context_to_sid().

However, ctx is strictly an input to the hypercall and is not mutated along
the way.  Both these issues can be fixed, and the error logic simplified, by
not duplicating ctx in the first place.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-IDs: 1055305 1055721
Acked-by: 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>

---
v2: Expand the commit message.  No code change
---
 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 f83e33d..2aa0dc7 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -2125,8 +2125,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;
 
@@ -2136,28 +2134,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 Tue Dec 09 16:54:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 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 1XyO3I-0008S5-LC; Tue, 09 Dec 2014 16:54:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XyO3H-0008Ru-63
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:54:19 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	95/A5-27584-A3927845; Tue, 09 Dec 2014 16:54:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418144053!12406173!1
X-Originating-IP: [66.165.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 14822 invoked from network); 9 Dec 2014 16:54:16 -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;
	9 Dec 2014 16:54:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="201981378"
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.210.2;
	Tue, 9 Dec 2014 11:43:24 -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
	1XyNsh-0006pJ-NQ; Tue, 09 Dec 2014 16:43:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Tue, 9 Dec 2014 16:43:22 +0000
Message-ID: <1418143402-29674-1-git-send-email-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <20141209162048.GB9585@laptop.dumpdata.com>
References: <20141209162048.GB9585@laptop.dumpdata.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 v2 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.

Coverity also complains about passing a non-NUL terminated string to
xc_flask_context_to_sid().  xc_flask_context_to_sid() doesn't actually take a
NUL terminated string, but it does take a char* which, in context, used to be
a string, which is why Coverity complains.

One solution would be to use strdup(ctx) which is simpler than a
strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated
string being used with xc_flask_context_to_sid().

However, ctx is strictly an input to the hypercall and is not mutated along
the way.  Both these issues can be fixed, and the error logic simplified, by
not duplicating ctx in the first place.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-IDs: 1055305 1055721
Acked-by: 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>

---
v2: Expand the commit message.  No code change
---
 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 f83e33d..2aa0dc7 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -2125,8 +2125,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;
 
@@ -2136,28 +2134,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 Tue Dec 09 16:57:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:57:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyO6D-0000DH-84; Tue, 09 Dec 2014 16:57: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 1XyO6B-0000D4-Qs
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:57:19 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	9B/29-02697-FE927845; Tue, 09 Dec 2014 16:57:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418144238!7115682!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11926 invoked from network); 9 Dec 2014 16:57:18 -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; 9 Dec 2014 16:57:18 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 16:57:18 +0000
Message-Id: <548737FA020000780004E38B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 16:57:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-15-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417448023-27311-15-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 14/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 01.12.14 at 16:33, <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;

unsigned int please. Plus similar coding style issues further down as in
the previous patch.

> @@ -415,6 +448,11 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
>              table_ptrs[nr_tables++] = (unsigned long)srat;
>          else
>              printf("Failed to build SRAT, skipping...\n");
> +        slit = construct_slit();
> +        if (srat)

DYM slit?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 16:57:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 16:57:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyO6D-0000DH-84; Tue, 09 Dec 2014 16:57: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 1XyO6B-0000D4-Qs
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:57:19 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	9B/29-02697-FE927845; Tue, 09 Dec 2014 16:57:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418144238!7115682!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11926 invoked from network); 9 Dec 2014 16:57:18 -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; 9 Dec 2014 16:57:18 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 16:57:18 +0000
Message-Id: <548737FA020000780004E38B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 16:57:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-15-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1417448023-27311-15-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 14/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 01.12.14 at 16:33, <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;

unsigned int please. Plus similar coding style issues further down as in
the previous patch.

> @@ -415,6 +448,11 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
>              table_ptrs[nr_tables++] = (unsigned long)srat;
>          else
>              printf("Failed to build SRAT, skipping...\n");
> +        slit = construct_slit();
> +        if (srat)

DYM slit?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:00:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17:00:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyO8k-0000Vi-Q4; Tue, 09 Dec 2014 16:59: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 1XyO8j-0000Vb-QS
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:59:57 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	7A/07-17958-D8A27845; Tue, 09 Dec 2014 16:59:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418144394!12170756!1
X-Originating-IP: [66.165.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 16996 invoked from network); 9 Dec 2014 16:59:56 -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 Dec 2014 16:59:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="201982859"
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.210.2;
	Tue, 9 Dec 2014 11:46: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 1XyNw5-0006tx-2g;
	Tue, 09 Dec 2014 16:46:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyNw4-0005oe-RE;
	Tue, 09 Dec 2014 16:46:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21639.10108.666942.407514@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 16:46:52 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141209162740.GA14288@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in systemd"):
> On Tue, Dec 09, Ian Jackson wrote:
> > But: I think the script is rather over-engineered, and that it ought
> > to be in /etc.
> 
> Why should the wrapper be in /etc?!

Because it is the last chance the admin has to adjust how xenstored is
run, which they ought to be able to do.

> xendomains isnt in /etc either.

xendomains is rather different.

> > > +	$(INSTALL_PROG) $(XENSTORED_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)
> > 
> > Sysadmins might want to edit the script to do something we haven't
> > thought of.  So it should be in /etc where they can do so.
> 
> So they should mail here if they find substantial functionality missing.

That is no good because it doesn't allow them to make the change
immediately on their own system, in a way that won't be overwritten by
their system's package manager.

> Until then they continue to not enable xencommons and run their own
> startup script.

That is not a practical suggestion.

Bottom line: as relevant maintainer, I'm afraid I'm going to insist
that this script be in /etc.


> > I don't think this script wants to contain an option parser!
> 
> How should it handle exec vs. no-exec? Just a single yes/no knob, so
> essentially sysv vs systemd?

I was imagining a "named parameter" as SuS calls them.  One or both
the sites which run this wrapper script would pass an environment
variable.  Something like this in the script:

  $xenstored_do_exec $XENSTORED "$@" $XENSTORED_TRACE_ARGS $XENSTORED_ARGS

where the systemd unit simply sets `xenstored_do_exec=exec'.


> > The systemd unit doesn't currently contain anything messing about with
> > xenstore-read to detect when xenstored is working.  Is that a bug that
> > was previously in the systemd unit, or is it a mistake in your patch
> > that this is added here ?
> 
> No idea how long it takes to have a functional xenstored after running
> it. Perhaps the forking has some overhead and it returns earlier than it
> can process requests. If thats the reason why the loop exists in the
> sysv runlevel script then that loop should be used only without --no-fork.

I think it is up to you as the person proposing a change to explain
what the situation is and why your change is justified.  It's not
really satisfactory for a maintainer or reviewer to ask questions of a
submitter and get simply `I'm not sure ... perhaps ...' without some
kind of acknowledgement that more information (and perhaps research)
is needed before we can establish how the code should look.

In this case that means I think you should find out whether the lack
of this xenstore-read polling loop is actually a bug in the existing
systemd unit.  If (as I suspect) this is not a bug, then your code
motion should not change this aspect of the operation under systemd.

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 Dec 09 17:00:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17:00:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyO8k-0000Vi-Q4; Tue, 09 Dec 2014 16:59: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 1XyO8j-0000Vb-QS
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 16:59:57 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	7A/07-17958-D8A27845; Tue, 09 Dec 2014 16:59:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418144394!12170756!1
X-Originating-IP: [66.165.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 16996 invoked from network); 9 Dec 2014 16:59:56 -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 Dec 2014 16:59:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="201982859"
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.210.2;
	Tue, 9 Dec 2014 11:46: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 1XyNw5-0006tx-2g;
	Tue, 09 Dec 2014 16:46:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyNw4-0005oe-RE;
	Tue, 09 Dec 2014 16:46:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21639.10108.666942.407514@mariner.uk.xensource.com>
Date: Tue, 9 Dec 2014 16:46:52 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141209162740.GA14288@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in systemd"):
> On Tue, Dec 09, Ian Jackson wrote:
> > But: I think the script is rather over-engineered, and that it ought
> > to be in /etc.
> 
> Why should the wrapper be in /etc?!

Because it is the last chance the admin has to adjust how xenstored is
run, which they ought to be able to do.

> xendomains isnt in /etc either.

xendomains is rather different.

> > > +	$(INSTALL_PROG) $(XENSTORED_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)
> > 
> > Sysadmins might want to edit the script to do something we haven't
> > thought of.  So it should be in /etc where they can do so.
> 
> So they should mail here if they find substantial functionality missing.

That is no good because it doesn't allow them to make the change
immediately on their own system, in a way that won't be overwritten by
their system's package manager.

> Until then they continue to not enable xencommons and run their own
> startup script.

That is not a practical suggestion.

Bottom line: as relevant maintainer, I'm afraid I'm going to insist
that this script be in /etc.


> > I don't think this script wants to contain an option parser!
> 
> How should it handle exec vs. no-exec? Just a single yes/no knob, so
> essentially sysv vs systemd?

I was imagining a "named parameter" as SuS calls them.  One or both
the sites which run this wrapper script would pass an environment
variable.  Something like this in the script:

  $xenstored_do_exec $XENSTORED "$@" $XENSTORED_TRACE_ARGS $XENSTORED_ARGS

where the systemd unit simply sets `xenstored_do_exec=exec'.


> > The systemd unit doesn't currently contain anything messing about with
> > xenstore-read to detect when xenstored is working.  Is that a bug that
> > was previously in the systemd unit, or is it a mistake in your patch
> > that this is added here ?
> 
> No idea how long it takes to have a functional xenstored after running
> it. Perhaps the forking has some overhead and it returns earlier than it
> can process requests. If thats the reason why the loop exists in the
> sysv runlevel script then that loop should be used only without --no-fork.

I think it is up to you as the person proposing a change to explain
what the situation is and why your change is justified.  It's not
really satisfactory for a maintainer or reviewer to ask questions of a
submitter and get simply `I'm not sure ... perhaps ...' without some
kind of acknowledgement that more information (and perhaps research)
is needed before we can establish how the code should look.

In this case that means I think you should find out whether the lack
of this xenstore-read polling loop is actually a bug in the existing
systemd unit.  If (as I suspect) this is not a bug, then your code
motion should not change this aspect of the operation under systemd.

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 Dec 09 17:14:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyOLa-00015G-EC; Tue, 09 Dec 2014 17:13:14 +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 1XyOLY-00015B-Ta
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:13:13 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	DF/3F-22777-8AD27845; Tue, 09 Dec 2014 17:13:12 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418145189!12457328!1
X-Originating-IP: [66.165.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 22127 invoked from network); 9 Dec 2014 17:13:11 -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;
	9 Dec 2014 17:13:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="201990422"
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.210.2; Tue, 9 Dec 2014
	12:01:56 -0500
Message-ID: <54872B02.50300@citrix.com>
Date: Tue, 9 Dec 2014 18:01:54 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <54857995020000780004DA2D@mail.emea.novell.com>
In-Reply-To: <54857995020000780004DA2D@mail.emea.novell.com>
Content-Length:1135
X-DLP: MIA2
Cc: Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
	handle_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RWwgMDgvMTIvMTQgYSBsZXMgMTAuMTIsIEphbiBCZXVsaWNoIGhhIGVzY3JpdDoKPiBQVkggZ3Vl
c3RzIGFjY2Vzc2luZyBJL08gcG9ydHMgdmlhIHN0cmluZyBvcHMgaXMgbm90IHN1cHBvcnRlZCB5
ZXQuCj4gCj4gUmVwb3J0ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6k8cm9nZXIucGF1QGNpdHJpeC5j
b20+Cj4gU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoKVGhp
cyBsb29rcyBmaW5lIHRvIG1lIChhdCBsZWFzdCBpdCBkb2Vzbid0IGJyZWFrIHRoZSBleGlzdGlu
ZyBJTi9PVVQKdXNlcnMpLCBhbmQgc2VlbXMgdGhlIGJlc3Qgc29sdXRpb24gNC41IHdpc2U6CgpB
Y2tlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CgpGb3IgNC42
IEkgdGhpbmsgd2UgbmVlZCB0byBzdGFydCB1c2luZyBhIGRpZmZlcmVudCBodm1faW9fYml0bWFw
IGZvciBQVkgKRG9tMCB0aGF0IGFsbG93cyBkaXJlY3QgYWNjZXNzIHRvIHRoZSBJTyBwb3J0cywg
YnlwYXNzaW5nIHRoZSB2bWV4aXQgYW5kCnNpbXBsaWZ5aW5nIHRoZSBjb2RlIGluIFhlbiAodGhp
cyB3b3VsZCBhbHNvIGZpeCBJTlMvT1VUUykuIFN0aWxsIG5vdApzdXJlIHdoYXQgc2hvdWxkIGJl
IGRvbmUgZm9yIFBWSCBEb21Vcywgc3BlY2lhbGx5IHdoZW4gUFZIIGdhaW5zIHN1cHBvcnQKZm9y
IHBjaS1wYXNzdGhyb3VnaC4KClJvZ2VyLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:14:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyOLa-00015G-EC; Tue, 09 Dec 2014 17:13:14 +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 1XyOLY-00015B-Ta
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:13:13 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	DF/3F-22777-8AD27845; Tue, 09 Dec 2014 17:13:12 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418145189!12457328!1
X-Originating-IP: [66.165.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 22127 invoked from network); 9 Dec 2014 17:13:11 -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;
	9 Dec 2014 17:13:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="201990422"
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.210.2; Tue, 9 Dec 2014
	12:01:56 -0500
Message-ID: <54872B02.50300@citrix.com>
Date: Tue, 9 Dec 2014 18:01:54 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <54857995020000780004DA2D@mail.emea.novell.com>
In-Reply-To: <54857995020000780004DA2D@mail.emea.novell.com>
Content-Length:1135
X-DLP: MIA2
Cc: Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
	handle_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RWwgMDgvMTIvMTQgYSBsZXMgMTAuMTIsIEphbiBCZXVsaWNoIGhhIGVzY3JpdDoKPiBQVkggZ3Vl
c3RzIGFjY2Vzc2luZyBJL08gcG9ydHMgdmlhIHN0cmluZyBvcHMgaXMgbm90IHN1cHBvcnRlZCB5
ZXQuCj4gCj4gUmVwb3J0ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6k8cm9nZXIucGF1QGNpdHJpeC5j
b20+Cj4gU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoKVGhp
cyBsb29rcyBmaW5lIHRvIG1lIChhdCBsZWFzdCBpdCBkb2Vzbid0IGJyZWFrIHRoZSBleGlzdGlu
ZyBJTi9PVVQKdXNlcnMpLCBhbmQgc2VlbXMgdGhlIGJlc3Qgc29sdXRpb24gNC41IHdpc2U6CgpB
Y2tlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CgpGb3IgNC42
IEkgdGhpbmsgd2UgbmVlZCB0byBzdGFydCB1c2luZyBhIGRpZmZlcmVudCBodm1faW9fYml0bWFw
IGZvciBQVkgKRG9tMCB0aGF0IGFsbG93cyBkaXJlY3QgYWNjZXNzIHRvIHRoZSBJTyBwb3J0cywg
YnlwYXNzaW5nIHRoZSB2bWV4aXQgYW5kCnNpbXBsaWZ5aW5nIHRoZSBjb2RlIGluIFhlbiAodGhp
cyB3b3VsZCBhbHNvIGZpeCBJTlMvT1VUUykuIFN0aWxsIG5vdApzdXJlIHdoYXQgc2hvdWxkIGJl
IGRvbmUgZm9yIFBWSCBEb21Vcywgc3BlY2lhbGx5IHdoZW4gUFZIIGdhaW5zIHN1cHBvcnQKZm9y
IHBjaS1wYXNzdGhyb3VnaC4KClJvZ2VyLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:20:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17: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 1XyORw-0001GQ-9o; Tue, 09 Dec 2014 17:19:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyORu-0001GL-4u
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:19:46 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	0E/F0-07724-13F27845; Tue, 09 Dec 2014 17:19:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418145584!12090741!1
X-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 16609 invoked from network); 9 Dec 2014 17:19:45 -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; 9 Dec 2014 17:19:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 17:19:44 +0000
Message-Id: <54873D3D020000780004E3D4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 17:19:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <54857995020000780004DA2D@mail.emea.novell.com>
	<54872B02.50300@citrix.com>
In-Reply-To: <54872B02.50300@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
	handle_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 09.12.14 at 18:01, <roger.pau@citrix.com> wrote:
> For 4.6 I think we need to start using a different hvm_io_bitmap for PVH
> Dom0 that allows direct access to the IO ports, bypassing the vmexit and
> simplifying the code in Xen (this would also fix INS/OUTS). Still not
> sure what should be done for PVH DomUs, specially when PVH gains support
> for pci-passthrough.

With the difficulty being that for PV the hypervisor intentionally
intercepts accesses to some of the ports, so we can't blindly
allow PVH access to all the ports its allowed access to.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:20:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17: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 1XyORw-0001GQ-9o; Tue, 09 Dec 2014 17:19:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyORu-0001GL-4u
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:19:46 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	0E/F0-07724-13F27845; Tue, 09 Dec 2014 17:19:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418145584!12090741!1
X-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 16609 invoked from network); 9 Dec 2014 17:19:45 -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; 9 Dec 2014 17:19:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 17:19:44 +0000
Message-Id: <54873D3D020000780004E3D4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 17:19:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <54857995020000780004DA2D@mail.emea.novell.com>
	<54872B02.50300@citrix.com>
In-Reply-To: <54872B02.50300@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
	handle_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 09.12.14 at 18:01, <roger.pau@citrix.com> wrote:
> For 4.6 I think we need to start using a different hvm_io_bitmap for PVH
> Dom0 that allows direct access to the IO ports, bypassing the vmexit and
> simplifying the code in Xen (this would also fix INS/OUTS). Still not
> sure what should be done for PVH DomUs, specially when PVH gains support
> for pci-passthrough.

With the difficulty being that for PV the hypervisor intentionally
intercepts accesses to some of the ports, so we can't blindly
allow PVH access to all the ports its allowed access to.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:28:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17:28:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyOa7-0001ya-98; Tue, 09 Dec 2014 17:28:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <bp@suse.de>)
	id 1XyOa6-0001yV-Dz
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:28:14 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	47/83-03145-D2137845; Tue, 09 Dec 2014 17:28:13 +0000
X-Env-Sender: bp@suse.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418146092!13968026!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24087 invoked from network); 9 Dec 2014 17:28:13 -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; 9 Dec 2014 17:28:13 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 085BCAC06;
	Tue,  9 Dec 2014 17:28:11 +0000 (UTC)
Received: by pd.tnic (Postfix, from userid 1000)
	id BCE1E1002DF; Tue,  9 Dec 2014 18:28:08 +0100 (CET)
Date: Tue, 9 Dec 2014 18:28:08 +0100
From: Borislav Petkov <bp@suse.de>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Message-ID: <20141209172808.GD4147@pd.tnic>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
	<1418079900-4640-2-git-send-email-mcgrof@do-not-panic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418079900-4640-2-git-send-email-mcgrof@do-not-panic.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Michal Marek <mmarek@suse.cz>, David Rientjes <rientjes@google.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	josh@joshtriplett.org, linux-kernel@vger.kernel.org,
	Pekka Enberg <penberg@kernel.org>, mtosatti@redhat.com,
	levinsasha928@gmail.com, hpa@zytor.com,
	xen-devel@lists.xenproject.org, fengguang.wu@intel.com,
	sam@ravnborg.org, David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v3 1/2] x86, platform,
 kconfig: clarify kvmconfig is for kvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 03:04:59PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> We'll be adding options for xen as well.
> 
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Pekka Enberg <penberg@kernel.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Michal Marek <mmarek@suse.cz>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: penberg@kernel.org
> Cc: levinsasha928@gmail.com
> Cc: mtosatti@redhat.com
> Cc: fengguang.wu@intel.com
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xenproject.org
> Acked-by: David Rientjes <rientjes@google.com>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>  scripts/kconfig/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index 9645c07..ff612b0 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -141,7 +141,7 @@ help:
>  	@echo  '  randconfig	  - New config with random answer to all options'
>  	@echo  '  listnewconfig   - List new options'
>  	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
> -	@echo  '  kvmconfig	  - Enable additional options for guest kernel support'
> +	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
>  	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
>  
>  # lxdialog stuff

Acked-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:28:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17:28:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyOa7-0001ya-98; Tue, 09 Dec 2014 17:28:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <bp@suse.de>)
	id 1XyOa6-0001yV-Dz
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:28:14 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	47/83-03145-D2137845; Tue, 09 Dec 2014 17:28:13 +0000
X-Env-Sender: bp@suse.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418146092!13968026!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24087 invoked from network); 9 Dec 2014 17:28:13 -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; 9 Dec 2014 17:28:13 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 085BCAC06;
	Tue,  9 Dec 2014 17:28:11 +0000 (UTC)
Received: by pd.tnic (Postfix, from userid 1000)
	id BCE1E1002DF; Tue,  9 Dec 2014 18:28:08 +0100 (CET)
Date: Tue, 9 Dec 2014 18:28:08 +0100
From: Borislav Petkov <bp@suse.de>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Message-ID: <20141209172808.GD4147@pd.tnic>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
	<1418079900-4640-2-git-send-email-mcgrof@do-not-panic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418079900-4640-2-git-send-email-mcgrof@do-not-panic.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Michal Marek <mmarek@suse.cz>, David Rientjes <rientjes@google.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	josh@joshtriplett.org, linux-kernel@vger.kernel.org,
	Pekka Enberg <penberg@kernel.org>, mtosatti@redhat.com,
	levinsasha928@gmail.com, hpa@zytor.com,
	xen-devel@lists.xenproject.org, fengguang.wu@intel.com,
	sam@ravnborg.org, David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v3 1/2] x86, platform,
 kconfig: clarify kvmconfig is for kvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 08, 2014 at 03:04:59PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> We'll be adding options for xen as well.
> 
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Pekka Enberg <penberg@kernel.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Michal Marek <mmarek@suse.cz>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: penberg@kernel.org
> Cc: levinsasha928@gmail.com
> Cc: mtosatti@redhat.com
> Cc: fengguang.wu@intel.com
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xenproject.org
> Acked-by: David Rientjes <rientjes@google.com>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>  scripts/kconfig/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index 9645c07..ff612b0 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -141,7 +141,7 @@ help:
>  	@echo  '  randconfig	  - New config with random answer to all options'
>  	@echo  '  listnewconfig   - List new options'
>  	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
> -	@echo  '  kvmconfig	  - Enable additional options for guest kernel support'
> +	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
>  	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
>  
>  # lxdialog stuff

Acked-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:29:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17: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 1XyOb3-00023q-Sr; Tue, 09 Dec 2014 17:29: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 1XyOb2-00023P-E1
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:29:12 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	D7/28-26652-76137845; Tue, 09 Dec 2014 17:29:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418146150!12396603!1
X-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 11880 invoked from network); 9 Dec 2014 17:29:11 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 17:29:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 17:29:10 +0000
Message-Id: <54873F74020000780004E442@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 17:29:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <1708243085.20141209172445@eikelenboom.it>
In-Reply-To: <1708243085.20141209172445@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: irq.c:xxxx: dom1: forcing unbind of
	pirq 40
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 17:24, <linux@eikelenboom.it> wrote:
> Currently i'm running Xen-unstable with Stefano's libxl fixup patches (not 
> doing 
> reset due to qmp race, switching order of xc_domain_irq_permission and 
> xc_physdev_unmap_pirq)
> and with a kernel with Konrad's 3.19 patch series. 
> 
> Although i have seen these messages before, so i don't know if it is a 
> recent 
> regression (don't think so). 
> 
> I still see these in xl dmesg when shutting down guests with pci 
> passthrough:
> "irq.c:xxxx: dom1: forcing unbind of pirq 40"
> 
> It seems to cleanup ok afterwards, but from the sound warning it shouldn't 
> get
> to that point. I get these for both PV and HVM guests.

These messages simply indicate that the guest didn't do some
expected cleanup itself. I see these too when Dom0 shuts down,
at least for certain drivers. For HVM arguably qemu might know
better and tear things down properly, but in no event are these
messages - when occurring in connection with a guest going
down - indications of a problem. We could even see to lower their
severity or suppress them altogether when the domain is known
to be dying (you may want to check whether ->is_dying is already
set at that point).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:29:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17: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 1XyOb3-00023q-Sr; Tue, 09 Dec 2014 17:29: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 1XyOb2-00023P-E1
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:29:12 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	D7/28-26652-76137845; Tue, 09 Dec 2014 17:29:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418146150!12396603!1
X-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 11880 invoked from network); 9 Dec 2014 17:29:11 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 17:29:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 17:29:10 +0000
Message-Id: <54873F74020000780004E442@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 17:29:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <1708243085.20141209172445@eikelenboom.it>
In-Reply-To: <1708243085.20141209172445@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: irq.c:xxxx: dom1: forcing unbind of
	pirq 40
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 17:24, <linux@eikelenboom.it> wrote:
> Currently i'm running Xen-unstable with Stefano's libxl fixup patches (not 
> doing 
> reset due to qmp race, switching order of xc_domain_irq_permission and 
> xc_physdev_unmap_pirq)
> and with a kernel with Konrad's 3.19 patch series. 
> 
> Although i have seen these messages before, so i don't know if it is a 
> recent 
> regression (don't think so). 
> 
> I still see these in xl dmesg when shutting down guests with pci 
> passthrough:
> "irq.c:xxxx: dom1: forcing unbind of pirq 40"
> 
> It seems to cleanup ok afterwards, but from the sound warning it shouldn't 
> get
> to that point. I get these for both PV and HVM guests.

These messages simply indicate that the guest didn't do some
expected cleanup itself. I see these too when Dom0 shuts down,
at least for certain drivers. For HVM arguably qemu might know
better and tear things down properly, but in no event are these
messages - when occurring in connection with a guest going
down - indications of a problem. We could even see to lower their
severity or suppress them altogether when the domain is known
to be dying (you may want to check whether ->is_dying is already
set at that point).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:35:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17:35:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyOgU-0002ap-LV; Tue, 09 Dec 2014 17:34: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 1XyOgT-0002ak-AT
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:34:49 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E6/D8-27584-8B237845; Tue, 09 Dec 2014 17:34:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418146487!4831433!1
X-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 7661 invoked from network); 9 Dec 2014 17:34:47 -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; 9 Dec 2014 17:34:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 17:34:47 +0000
Message-Id: <548740C4020000780004E471@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 17:34:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2D18F3A4.1__="
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part2D18F3A4.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... when "conring_size=3D" was specified on the command line. We can't
really do this as early as we would want to when the option was not
specified, as the default depends on knowing the system CPU count. Yet
the parsing of the ACPI tables is one of the things that generates a
lot of output especially on large systems.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Also adjust ARM (as requested by Julien). Rename new function to
    console_init_ring().

--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -745,6 +745,7 @@ void __init start_xen(unsigned long boot
=20
     dt_uart_init();
     console_init_preirq();
+    console_init_ring();
=20
     system_state =3D SYS_STATE_boot;
=20
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1187,6 +1187,7 @@ void __init noreturn __start_xen(unsigne
     }
=20
     vm_init();
+    console_init_ring();
     vesa_init();
=20
     softirq_init();
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -744,15 +744,14 @@ void __init console_init_preirq(void)
     }
 }
=20
-void __init console_init_postirq(void)
+void __init console_init_ring(void)
 {
     char *ring;
     unsigned int i, order, memflags;
-
-    serial_init_postirq();
+    unsigned long flags;
=20
     if ( !opt_conring_size )
-        opt_conring_size =3D num_present_cpus() << (9 + xenlog_lower_thres=
h);
+        return;
=20
     order =3D get_order_from_bytes(max(opt_conring_size, conring_size));
     memflags =3D MEMF_bits(crashinfo_maxaddr_bits);
@@ -763,17 +762,30 @@ void __init console_init_postirq(void)
     }
     opt_conring_size =3D PAGE_SIZE << order;
=20
-    spin_lock_irq(&console_lock);
+    spin_lock_irqsave(&console_lock, flags);
     for ( i =3D conringc ; i !=3D conringp; i++ )
         ring[i & (opt_conring_size - 1)] =3D conring[i & (conring_size - =
1)];
     conring =3D ring;
     smp_wmb(); /* Allow users of console_force_unlock() to see larger =
buffer. */
     conring_size =3D opt_conring_size;
-    spin_unlock_irq(&console_lock);
+    spin_unlock_irqrestore(&console_lock, flags);
=20
     printk("Allocated console ring of %u KiB.\n", opt_conring_size >> =
10);
 }
=20
+void __init console_init_postirq(void)
+{
+    serial_init_postirq();
+
+    if ( conring !=3D _conring )
+        return;
+
+    if ( !opt_conring_size )
+        opt_conring_size =3D num_present_cpus() << (9 + xenlog_lower_thres=
h);
+
+    console_init_ring();
+}
+
 void __init console_endboot(void)
 {
     int i, j;
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -14,6 +14,7 @@ struct xen_sysctl_readconsole;
 long read_console_ring(struct xen_sysctl_readconsole *op);
=20
 void console_init_preirq(void);
+void console_init_ring(void);
 void console_init_postirq(void);
 void console_endboot(void);
 int console_has(const char *device);




--=__Part2D18F3A4.1__=
Content-Type: text/plain; name="conring-alloc-earlier.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="conring-alloc-earlier.patch"

console: allocate ring buffer earlier=0A=0A... when "conring_size=3D" was =
specified on the command line. We can't=0Areally do this as early as we =
would want to when the option was not=0Aspecified, as the default depends =
on knowing the system CPU count. Yet=0Athe parsing of the ACPI tables is =
one of the things that generates a=0Alot of output especially on large =
systems.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0Av2: =
Also adjust ARM (as requested by Julien). Rename new function to=0A    =
console_init_ring().=0A=0A--- a/xen/arch/arm/setup.c=0A+++ b/xen/arch/arm/s=
etup.c=0A@@ -745,6 +745,7 @@ void __init start_xen(unsigned long boot=0A =
=0A     dt_uart_init();=0A     console_init_preirq();=0A+    console_init_r=
ing();=0A =0A     system_state =3D SYS_STATE_boot;=0A =0A--- a/xen/arch/x86=
/setup.c=0A+++ b/xen/arch/x86/setup.c=0A@@ -1187,6 +1187,7 @@ void __init =
noreturn __start_xen(unsigne=0A     }=0A =0A     vm_init();=0A+    =
console_init_ring();=0A     vesa_init();=0A =0A     softirq_init();=0A--- =
a/xen/drivers/char/console.c=0A+++ b/xen/drivers/char/console.c=0A@@ =
-744,15 +744,14 @@ void __init console_init_preirq(void)=0A     }=0A }=0A =
=0A-void __init console_init_postirq(void)=0A+void __init console_init_ring=
(void)=0A {=0A     char *ring;=0A     unsigned int i, order, memflags;=0A-=
=0A-    serial_init_postirq();=0A+    unsigned long flags;=0A =0A     if ( =
!opt_conring_size )=0A-        opt_conring_size =3D num_present_cpus() << =
(9 + xenlog_lower_thresh);=0A+        return;=0A =0A     order =3D =
get_order_from_bytes(max(opt_conring_size, conring_size));=0A     memflags =
=3D MEMF_bits(crashinfo_maxaddr_bits);=0A@@ -763,17 +762,30 @@ void __init =
console_init_postirq(void)=0A     }=0A     opt_conring_size =3D PAGE_SIZE =
<< order;=0A =0A-    spin_lock_irq(&console_lock);=0A+    spin_lock_irqsave=
(&console_lock, flags);=0A     for ( i =3D conringc ; i !=3D conringp; i++ =
)=0A         ring[i & (opt_conring_size - 1)] =3D conring[i & (conring_size=
 - 1)];=0A     conring =3D ring;=0A     smp_wmb(); /* Allow users of =
console_force_unlock() to see larger buffer. */=0A     conring_size =3D =
opt_conring_size;=0A-    spin_unlock_irq(&console_lock);=0A+    spin_unlock=
_irqrestore(&console_lock, flags);=0A =0A     printk("Allocated console =
ring of %u KiB.\n", opt_conring_size >> 10);=0A }=0A =0A+void __init =
console_init_postirq(void)=0A+{=0A+    serial_init_postirq();=0A+=0A+    =
if ( conring !=3D _conring )=0A+        return;=0A+=0A+    if ( !opt_conrin=
g_size )=0A+        opt_conring_size =3D num_present_cpus() << (9 + =
xenlog_lower_thresh);=0A+=0A+    console_init_ring();=0A+}=0A+=0A void =
__init console_endboot(void)=0A {=0A     int i, j;=0A--- a/xen/include/xen/=
console.h=0A+++ b/xen/include/xen/console.h=0A@@ -14,6 +14,7 @@ struct =
xen_sysctl_readconsole;=0A long read_console_ring(struct xen_sysctl_readcon=
sole *op);=0A =0A void console_init_preirq(void);=0A+void console_init_ring=
(void);=0A void console_init_postirq(void);=0A void console_endboot(void);=
=0A int console_has(const char *device);=0A
--=__Part2D18F3A4.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

--=__Part2D18F3A4.1__=--


From xen-devel-bounces@lists.xen.org Tue Dec 09 17:35:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17:35:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyOgU-0002ap-LV; Tue, 09 Dec 2014 17:34: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 1XyOgT-0002ak-AT
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:34:49 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E6/D8-27584-8B237845; Tue, 09 Dec 2014 17:34:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418146487!4831433!1
X-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 7661 invoked from network); 9 Dec 2014 17:34:47 -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; 9 Dec 2014 17:34:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 17:34:47 +0000
Message-Id: <548740C4020000780004E471@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 17:34:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2D18F3A4.1__="
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part2D18F3A4.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... when "conring_size=3D" was specified on the command line. We can't
really do this as early as we would want to when the option was not
specified, as the default depends on knowing the system CPU count. Yet
the parsing of the ACPI tables is one of the things that generates a
lot of output especially on large systems.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Also adjust ARM (as requested by Julien). Rename new function to
    console_init_ring().

--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -745,6 +745,7 @@ void __init start_xen(unsigned long boot
=20
     dt_uart_init();
     console_init_preirq();
+    console_init_ring();
=20
     system_state =3D SYS_STATE_boot;
=20
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1187,6 +1187,7 @@ void __init noreturn __start_xen(unsigne
     }
=20
     vm_init();
+    console_init_ring();
     vesa_init();
=20
     softirq_init();
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -744,15 +744,14 @@ void __init console_init_preirq(void)
     }
 }
=20
-void __init console_init_postirq(void)
+void __init console_init_ring(void)
 {
     char *ring;
     unsigned int i, order, memflags;
-
-    serial_init_postirq();
+    unsigned long flags;
=20
     if ( !opt_conring_size )
-        opt_conring_size =3D num_present_cpus() << (9 + xenlog_lower_thres=
h);
+        return;
=20
     order =3D get_order_from_bytes(max(opt_conring_size, conring_size));
     memflags =3D MEMF_bits(crashinfo_maxaddr_bits);
@@ -763,17 +762,30 @@ void __init console_init_postirq(void)
     }
     opt_conring_size =3D PAGE_SIZE << order;
=20
-    spin_lock_irq(&console_lock);
+    spin_lock_irqsave(&console_lock, flags);
     for ( i =3D conringc ; i !=3D conringp; i++ )
         ring[i & (opt_conring_size - 1)] =3D conring[i & (conring_size - =
1)];
     conring =3D ring;
     smp_wmb(); /* Allow users of console_force_unlock() to see larger =
buffer. */
     conring_size =3D opt_conring_size;
-    spin_unlock_irq(&console_lock);
+    spin_unlock_irqrestore(&console_lock, flags);
=20
     printk("Allocated console ring of %u KiB.\n", opt_conring_size >> =
10);
 }
=20
+void __init console_init_postirq(void)
+{
+    serial_init_postirq();
+
+    if ( conring !=3D _conring )
+        return;
+
+    if ( !opt_conring_size )
+        opt_conring_size =3D num_present_cpus() << (9 + xenlog_lower_thres=
h);
+
+    console_init_ring();
+}
+
 void __init console_endboot(void)
 {
     int i, j;
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -14,6 +14,7 @@ struct xen_sysctl_readconsole;
 long read_console_ring(struct xen_sysctl_readconsole *op);
=20
 void console_init_preirq(void);
+void console_init_ring(void);
 void console_init_postirq(void);
 void console_endboot(void);
 int console_has(const char *device);




--=__Part2D18F3A4.1__=
Content-Type: text/plain; name="conring-alloc-earlier.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="conring-alloc-earlier.patch"

console: allocate ring buffer earlier=0A=0A... when "conring_size=3D" was =
specified on the command line. We can't=0Areally do this as early as we =
would want to when the option was not=0Aspecified, as the default depends =
on knowing the system CPU count. Yet=0Athe parsing of the ACPI tables is =
one of the things that generates a=0Alot of output especially on large =
systems.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0Av2: =
Also adjust ARM (as requested by Julien). Rename new function to=0A    =
console_init_ring().=0A=0A--- a/xen/arch/arm/setup.c=0A+++ b/xen/arch/arm/s=
etup.c=0A@@ -745,6 +745,7 @@ void __init start_xen(unsigned long boot=0A =
=0A     dt_uart_init();=0A     console_init_preirq();=0A+    console_init_r=
ing();=0A =0A     system_state =3D SYS_STATE_boot;=0A =0A--- a/xen/arch/x86=
/setup.c=0A+++ b/xen/arch/x86/setup.c=0A@@ -1187,6 +1187,7 @@ void __init =
noreturn __start_xen(unsigne=0A     }=0A =0A     vm_init();=0A+    =
console_init_ring();=0A     vesa_init();=0A =0A     softirq_init();=0A--- =
a/xen/drivers/char/console.c=0A+++ b/xen/drivers/char/console.c=0A@@ =
-744,15 +744,14 @@ void __init console_init_preirq(void)=0A     }=0A }=0A =
=0A-void __init console_init_postirq(void)=0A+void __init console_init_ring=
(void)=0A {=0A     char *ring;=0A     unsigned int i, order, memflags;=0A-=
=0A-    serial_init_postirq();=0A+    unsigned long flags;=0A =0A     if ( =
!opt_conring_size )=0A-        opt_conring_size =3D num_present_cpus() << =
(9 + xenlog_lower_thresh);=0A+        return;=0A =0A     order =3D =
get_order_from_bytes(max(opt_conring_size, conring_size));=0A     memflags =
=3D MEMF_bits(crashinfo_maxaddr_bits);=0A@@ -763,17 +762,30 @@ void __init =
console_init_postirq(void)=0A     }=0A     opt_conring_size =3D PAGE_SIZE =
<< order;=0A =0A-    spin_lock_irq(&console_lock);=0A+    spin_lock_irqsave=
(&console_lock, flags);=0A     for ( i =3D conringc ; i !=3D conringp; i++ =
)=0A         ring[i & (opt_conring_size - 1)] =3D conring[i & (conring_size=
 - 1)];=0A     conring =3D ring;=0A     smp_wmb(); /* Allow users of =
console_force_unlock() to see larger buffer. */=0A     conring_size =3D =
opt_conring_size;=0A-    spin_unlock_irq(&console_lock);=0A+    spin_unlock=
_irqrestore(&console_lock, flags);=0A =0A     printk("Allocated console =
ring of %u KiB.\n", opt_conring_size >> 10);=0A }=0A =0A+void __init =
console_init_postirq(void)=0A+{=0A+    serial_init_postirq();=0A+=0A+    =
if ( conring !=3D _conring )=0A+        return;=0A+=0A+    if ( !opt_conrin=
g_size )=0A+        opt_conring_size =3D num_present_cpus() << (9 + =
xenlog_lower_thresh);=0A+=0A+    console_init_ring();=0A+}=0A+=0A void =
__init console_endboot(void)=0A {=0A     int i, j;=0A--- a/xen/include/xen/=
console.h=0A+++ b/xen/include/xen/console.h=0A@@ -14,6 +14,7 @@ struct =
xen_sysctl_readconsole;=0A long read_console_ring(struct xen_sysctl_readcon=
sole *op);=0A =0A void console_init_preirq(void);=0A+void console_init_ring=
(void);=0A void console_init_postirq(void);=0A void console_endboot(void);=
=0A int console_has(const char *device);=0A
--=__Part2D18F3A4.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

--=__Part2D18F3A4.1__=--


From xen-devel-bounces@lists.xen.org Tue Dec 09 17:50:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17: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 1XyOvG-00030v-NZ; Tue, 09 Dec 2014 17:50:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1XyOvE-00030p-SY
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:50:04 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	51/CE-26858-C4637845; Tue, 09 Dec 2014 17:50:04 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418147402!12164866!1
X-Originating-IP: [66.165.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 7603 invoked from network); 9 Dec 2014 17:50:03 -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;
	9 Dec 2014 17:50:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="202415775"
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.210.2; Tue, 9 Dec 2014
	12:49:58 -0500
Message-ID: <54873645.9070204@citrix.com>
Date: Tue, 9 Dec 2014 18:49:57 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <54857995020000780004DA2D@mail.emea.novell.com>	<54872B02.50300@citrix.com>
	<54873D3D020000780004E3D4@mail.emea.novell.com>
In-Reply-To: <54873D3D020000780004E3D4@mail.emea.novell.com>
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
	handle_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

El 09/12/14 a les 18.19, Jan Beulich ha escrit:
>>>> On 09.12.14 at 18:01, <roger.pau@citrix.com> wrote:
>> For 4.6 I think we need to start using a different hvm_io_bitmap for PVH
>> Dom0 that allows direct access to the IO ports, bypassing the vmexit and
>> simplifying the code in Xen (this would also fix INS/OUTS). Still not
>> sure what should be done for PVH DomUs, specially when PVH gains support
>> for pci-passthrough.
> 
> With the difficulty being that for PV the hypervisor intentionally
> intercepts accesses to some of the ports, so we can't blindly
> allow PVH access to all the ports its allowed access to.

I assume this is mainly for DomUs but not for Dom0? Or should PVH Dom0
access to the IO space also be filtered and emulated for some ports?

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:50:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17: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 1XyOvG-00030v-NZ; Tue, 09 Dec 2014 17:50:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1XyOvE-00030p-SY
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:50:04 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	51/CE-26858-C4637845; Tue, 09 Dec 2014 17:50:04 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418147402!12164866!1
X-Originating-IP: [66.165.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 7603 invoked from network); 9 Dec 2014 17:50:03 -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;
	9 Dec 2014 17:50:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="202415775"
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.210.2; Tue, 9 Dec 2014
	12:49:58 -0500
Message-ID: <54873645.9070204@citrix.com>
Date: Tue, 9 Dec 2014 18:49:57 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <54857995020000780004DA2D@mail.emea.novell.com>	<54872B02.50300@citrix.com>
	<54873D3D020000780004E3D4@mail.emea.novell.com>
In-Reply-To: <54873D3D020000780004E3D4@mail.emea.novell.com>
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
	handle_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

El 09/12/14 a les 18.19, Jan Beulich ha escrit:
>>>> On 09.12.14 at 18:01, <roger.pau@citrix.com> wrote:
>> For 4.6 I think we need to start using a different hvm_io_bitmap for PVH
>> Dom0 that allows direct access to the IO ports, bypassing the vmexit and
>> simplifying the code in Xen (this would also fix INS/OUTS). Still not
>> sure what should be done for PVH DomUs, specially when PVH gains support
>> for pci-passthrough.
> 
> With the difficulty being that for PV the hypervisor intentionally
> intercepts accesses to some of the ports, so we can't blindly
> allow PVH access to all the ports its allowed access to.

I assume this is mainly for DomUs but not for Dom0? Or should PVH Dom0
access to the IO space also be filtered and emulated for some ports?

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:55:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17: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 1XyP0c-0003aL-GD; Tue, 09 Dec 2014 17:55:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XyP0a-0003aE-7H
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:55:36 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	B0/38-02698-79737845; Tue, 09 Dec 2014 17:55:35 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418147734!14022954!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 14305 invoked from network); 9 Dec 2014 17:55:34 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 17:55:34 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=PBeA4KjYUdFyu4RFW4phwTiwK7OCKZ5Vu/7rsul+Fe1SpeuBmEhCUFhp0OQoaiRqCYdH6WsbkHmHwApu7fco9uAkojdEM82qyTU+rqoACE/zq2FmDKJY32j6rkSGgn6XqCEP0Zm3Zd3pUdapF4PDWgY4ZhOL0nY/b36sxyxVuHrJF4orij/OHutg+Mr6/C5ohC3kh+nUN59BHarfMhyuSEMArX412Oit8VCj95z6912VzM+UC/gnX4Jpz/1tgY/DUSUFab3Q51Pnaoco/rGdHZ/5FFOMx+yj3SwtugCXzPRuhOGSsUDb34tX1nEFcfmJlKuzc/7FUAa1tWQy+BmFJw==;
	h=Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:cc:subject:message-id:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	bh=amwDWu33+KUKwFZwWAYN+lCl25k=; b=Nw5p/C4KD7g+vaMpnLxUgOfsh7h6
	5/WsrspzaNH4bgy+JMb1uAyjMM8mrS/b0hcYevVXNYFBQmr+h7Tq/MieKAKTIZ70
	Vz5NyJqHdEuoP478DJe/tg8dcwtJTAdNsKsbTCNzeUdAQSmKM+wb4tnCHmlicS3I
	yEu1WrkpNXd6D4rZEdP0WzlJpmQvA+xhlce1gLCP30kC5LPTTYFn4LwT3e0m+hfY
	3EpToZtpjrKSjZAn/KPFRBqpkt1RMnjpsuXmvyFNkpokbJQYWUKypd5pL/pJTYKf
	8TAhgcJUJTd24W8Sn5QzaxdC9CwxRV/t75BeAFnNrrMU4K2tmqMWgFTm+g==
Received: (qmail 20012 invoked from network); 9 Dec 2014 19:55:33 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	9 Dec 2014 19:55:33 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id EE54D8040D
	for <xen-devel@lists.xenproject.org>;
	Tue,  9 Dec 2014 19:55:32 +0200 (EET)
Received: (qmail 24051 invoked from network); 9 Dec 2014 19:55:32 +0200
Received: from unknown (HELO bitdefender.com)
	(mdontu@bitdefender.com@91.199.104.6)
	by smtp03.buh.bitdefender.org with SMTP; 9 Dec 2014 19:55:30 +0200
Date: Tue, 9 Dec 2014 19:55:30 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141209195530.54a60a14@bitdefender.com>
In-Reply-To: <54857D59.2050605@citrix.com>
References: <1417997962-23853-1-git-send-email-mdontu@bitdefender.com>
	<54857D59.2050605@citrix.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.58196
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374439,
	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], SGN: [Enabled], URL: [Enabled], RTDA:
	[Enabled, Hit: No, Details: v2.1.2; Id: 2m1ghdo.198la42sk.5fcbt],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] console: const-ify the arguments for
 __warn() and __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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uZGF5IDA4IERlY2VtYmVyIDIwMTQgMTA6Mjg6NDEgQW5kcmV3IENvb3BlciB3cm90ZToK
PiBPbiAwOC8xMi8xNCAwMDoxOSwgTWloYWkgRG9uyJt1IHdyb3RlOgo+ID4gQm90aCBfX3dhcm4o
KSBhbmQgX19idWcoKSB0YWtlIGFzIGZpcnN0IHBhcmFtZXRlciB0aGUgZmlsZSBuYW1lIG9mIHRo
ZQo+ID4gY3VycmVudCBjb21waWxhdGlvbiB1bml0IChfX0ZJTEVfXykuIE1hcmsgdGhhdCBwYXJh
bWV0ZXIgYXMgY29uc3RhbnQgdG8KPiA+IGJldHRlciByZWZsZWN0IHRoYXQuCj4gPgo+ID4gU2ln
bmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0ZGVmZW5kZXIuY29tPgo+IAo+IFRo
aXMgc2VlbXMgcmVhc29uYWJsZSwgYnV0IGZvciA0LjYgYXQgdGhpcyBwb2ludC4KPiAKPiBSZXZp
ZXdlZC1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KPiAKPiBJ
biBmdXR1cmUsIHBsZWFzZSBDQyB0aGUgcmVsZXZhbnQgbWFpbnRhaW5lcnMgKHNjcmlwcy9nZXRf
bWFpbnRhaW5lci5wbAo+IHNob3VsZCBoZWxwKQoKVGhhbmsgeW91IEFuZHJldy4KClNob3VsZCBJ
IHJlc2VuZCB0aGUgcGF0Y2ggd2l0aCB5b3VyIFJldmlld2VkLWJ5IGFuZCB0aGUgcHJvcGVyIHBl
b3BsZSBpbgpDQz8KCj4gPiAtLS0KPiA+ICB4ZW4vZHJpdmVycy9jaGFyL2NvbnNvbGUuYyB8IDQg
KystLQo+ID4gIHhlbi9pbmNsdWRlL3hlbi9saWIuaCAgICAgIHwgNCArKy0tCj4gPiAgMiBmaWxl
cyBjaGFuZ2VkLCA0IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pCj4gPgo+ID4gZGlmZiAt
LWdpdCBhL3hlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jIGIveGVuL2RyaXZlcnMvY2hhci9jb25z
b2xlLmMKPiA+IGluZGV4IDJmMDMyNTkuLjc4MDdjZjIgMTAwNjQ0Cj4gPiAtLS0gYS94ZW4vZHJp
dmVycy9jaGFyL2NvbnNvbGUuYwo+ID4gKysrIGIveGVuL2RyaXZlcnMvY2hhci9jb25zb2xlLmMK
PiA+IEBAIC0xMTM4LDcgKzExMzgsNyBAQCB2b2lkIHBhbmljKGNvbnN0IGNoYXIgKmZtdCwgLi4u
KQo+ID4gICAgICAgICAgbWFjaGluZV9yZXN0YXJ0KDUwMDApOwo+ID4gIH0KPiA+Cj4gPiAtdm9p
ZCBfX2J1ZyhjaGFyICpmaWxlLCBpbnQgbGluZSkKPiA+ICt2b2lkIF9fYnVnKGNvbnN0IGNoYXIg
KmZpbGUsIGludCBsaW5lKQo+ID4gIHsKPiA+ICAgICAgY29uc29sZV9zdGFydF9zeW5jKCk7Cj4g
PiAgICAgIHByaW50aygiWGVuIEJVRyBhdCAlczolZFxuIiwgZmlsZSwgbGluZSk7Cj4gPiBAQCAt
MTE0Niw3ICsxMTQ2LDcgQEAgdm9pZCBfX2J1ZyhjaGFyICpmaWxlLCBpbnQgbGluZSkKPiA+ICAg
ICAgcGFuaWMoIlhlbiBCVUcgYXQgJXM6JWQiLCBmaWxlLCBsaW5lKTsKPiA+ICB9Cj4gPgo+ID4g
LXZvaWQgX193YXJuKGNoYXIgKmZpbGUsIGludCBsaW5lKQo+ID4gK3ZvaWQgX193YXJuKGNvbnN0
IGNoYXIgKmZpbGUsIGludCBsaW5lKQo+ID4gIHsKPiA+ICAgICAgcHJpbnRrKCJYZW4gV0FSTiBh
dCAlczolZFxuIiwgZmlsZSwgbGluZSk7Cj4gPiAgICAgIGR1bXBfZXhlY3V0aW9uX3N0YXRlKCk7
Cj4gPiBkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL2xpYi5oIGIveGVuL2luY2x1ZGUveGVu
L2xpYi5oCj4gPiBpbmRleCBmMTFiNDllLi44ZjljYWRiIDEwMDY0NAo+ID4gLS0tIGEveGVuL2lu
Y2x1ZGUveGVuL2xpYi5oCj4gPiArKysgYi94ZW4vaW5jbHVkZS94ZW4vbGliLmgKPiA+IEBAIC04
LDggKzgsOCBAQAo+ID4gICNpbmNsdWRlIDx4ZW4vc3RyaW5nLmg+Cj4gPiAgI2luY2x1ZGUgPGFz
bS9idWcuaD4KPiA+Cj4gPiAtdm9pZCBub3JldHVybiBfX2J1ZyhjaGFyICpmaWxlLCBpbnQgbGlu
ZSk7Cj4gPiAtdm9pZCBfX3dhcm4oY2hhciAqZmlsZSwgaW50IGxpbmUpOwo+ID4gK3ZvaWQgbm9y
ZXR1cm4gX19idWcoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpOwo+ID4gK3ZvaWQgX193YXJu
KGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKTsKPiA+Cj4gPiAgI2RlZmluZSBCVUdfT04ocCkg
IGRvIHsgaWYgKHVubGlrZWx5KHApKSBCVUcoKTsgIH0gd2hpbGUgKDApCj4gPiAgI2RlZmluZSBX
QVJOX09OKHApIGRvIHsgaWYgKHVubGlrZWx5KHApKSBXQVJOKCk7IH0gd2hpbGUgKDApCgotLSAK
TWloYWkgRE9OyJpVCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:55:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17: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 1XyP0c-0003aL-GD; Tue, 09 Dec 2014 17:55:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XyP0a-0003aE-7H
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 17:55:36 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	B0/38-02698-79737845; Tue, 09 Dec 2014 17:55:35 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418147734!14022954!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 14305 invoked from network); 9 Dec 2014 17:55:34 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Dec 2014 17:55:34 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=PBeA4KjYUdFyu4RFW4phwTiwK7OCKZ5Vu/7rsul+Fe1SpeuBmEhCUFhp0OQoaiRqCYdH6WsbkHmHwApu7fco9uAkojdEM82qyTU+rqoACE/zq2FmDKJY32j6rkSGgn6XqCEP0Zm3Zd3pUdapF4PDWgY4ZhOL0nY/b36sxyxVuHrJF4orij/OHutg+Mr6/C5ohC3kh+nUN59BHarfMhyuSEMArX412Oit8VCj95z6912VzM+UC/gnX4Jpz/1tgY/DUSUFab3Q51Pnaoco/rGdHZ/5FFOMx+yj3SwtugCXzPRuhOGSsUDb34tX1nEFcfmJlKuzc/7FUAa1tWQy+BmFJw==;
	h=Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:cc:subject:message-id:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	bh=amwDWu33+KUKwFZwWAYN+lCl25k=; b=Nw5p/C4KD7g+vaMpnLxUgOfsh7h6
	5/WsrspzaNH4bgy+JMb1uAyjMM8mrS/b0hcYevVXNYFBQmr+h7Tq/MieKAKTIZ70
	Vz5NyJqHdEuoP478DJe/tg8dcwtJTAdNsKsbTCNzeUdAQSmKM+wb4tnCHmlicS3I
	yEu1WrkpNXd6D4rZEdP0WzlJpmQvA+xhlce1gLCP30kC5LPTTYFn4LwT3e0m+hfY
	3EpToZtpjrKSjZAn/KPFRBqpkt1RMnjpsuXmvyFNkpokbJQYWUKypd5pL/pJTYKf
	8TAhgcJUJTd24W8Sn5QzaxdC9CwxRV/t75BeAFnNrrMU4K2tmqMWgFTm+g==
Received: (qmail 20012 invoked from network); 9 Dec 2014 19:55:33 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	9 Dec 2014 19:55:33 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id EE54D8040D
	for <xen-devel@lists.xenproject.org>;
	Tue,  9 Dec 2014 19:55:32 +0200 (EET)
Received: (qmail 24051 invoked from network); 9 Dec 2014 19:55:32 +0200
Received: from unknown (HELO bitdefender.com)
	(mdontu@bitdefender.com@91.199.104.6)
	by smtp03.buh.bitdefender.org with SMTP; 9 Dec 2014 19:55:30 +0200
Date: Tue, 9 Dec 2014 19:55:30 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141209195530.54a60a14@bitdefender.com>
In-Reply-To: <54857D59.2050605@citrix.com>
References: <1417997962-23853-1-git-send-email-mdontu@bitdefender.com>
	<54857D59.2050605@citrix.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.58196
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374439,
	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], SGN: [Enabled], URL: [Enabled], RTDA:
	[Enabled, Hit: No, Details: v2.1.2; Id: 2m1ghdo.198la42sk.5fcbt],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] console: const-ify the arguments for
 __warn() and __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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uZGF5IDA4IERlY2VtYmVyIDIwMTQgMTA6Mjg6NDEgQW5kcmV3IENvb3BlciB3cm90ZToK
PiBPbiAwOC8xMi8xNCAwMDoxOSwgTWloYWkgRG9uyJt1IHdyb3RlOgo+ID4gQm90aCBfX3dhcm4o
KSBhbmQgX19idWcoKSB0YWtlIGFzIGZpcnN0IHBhcmFtZXRlciB0aGUgZmlsZSBuYW1lIG9mIHRo
ZQo+ID4gY3VycmVudCBjb21waWxhdGlvbiB1bml0IChfX0ZJTEVfXykuIE1hcmsgdGhhdCBwYXJh
bWV0ZXIgYXMgY29uc3RhbnQgdG8KPiA+IGJldHRlciByZWZsZWN0IHRoYXQuCj4gPgo+ID4gU2ln
bmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0ZGVmZW5kZXIuY29tPgo+IAo+IFRo
aXMgc2VlbXMgcmVhc29uYWJsZSwgYnV0IGZvciA0LjYgYXQgdGhpcyBwb2ludC4KPiAKPiBSZXZp
ZXdlZC1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KPiAKPiBJ
biBmdXR1cmUsIHBsZWFzZSBDQyB0aGUgcmVsZXZhbnQgbWFpbnRhaW5lcnMgKHNjcmlwcy9nZXRf
bWFpbnRhaW5lci5wbAo+IHNob3VsZCBoZWxwKQoKVGhhbmsgeW91IEFuZHJldy4KClNob3VsZCBJ
IHJlc2VuZCB0aGUgcGF0Y2ggd2l0aCB5b3VyIFJldmlld2VkLWJ5IGFuZCB0aGUgcHJvcGVyIHBl
b3BsZSBpbgpDQz8KCj4gPiAtLS0KPiA+ICB4ZW4vZHJpdmVycy9jaGFyL2NvbnNvbGUuYyB8IDQg
KystLQo+ID4gIHhlbi9pbmNsdWRlL3hlbi9saWIuaCAgICAgIHwgNCArKy0tCj4gPiAgMiBmaWxl
cyBjaGFuZ2VkLCA0IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pCj4gPgo+ID4gZGlmZiAt
LWdpdCBhL3hlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jIGIveGVuL2RyaXZlcnMvY2hhci9jb25z
b2xlLmMKPiA+IGluZGV4IDJmMDMyNTkuLjc4MDdjZjIgMTAwNjQ0Cj4gPiAtLS0gYS94ZW4vZHJp
dmVycy9jaGFyL2NvbnNvbGUuYwo+ID4gKysrIGIveGVuL2RyaXZlcnMvY2hhci9jb25zb2xlLmMK
PiA+IEBAIC0xMTM4LDcgKzExMzgsNyBAQCB2b2lkIHBhbmljKGNvbnN0IGNoYXIgKmZtdCwgLi4u
KQo+ID4gICAgICAgICAgbWFjaGluZV9yZXN0YXJ0KDUwMDApOwo+ID4gIH0KPiA+Cj4gPiAtdm9p
ZCBfX2J1ZyhjaGFyICpmaWxlLCBpbnQgbGluZSkKPiA+ICt2b2lkIF9fYnVnKGNvbnN0IGNoYXIg
KmZpbGUsIGludCBsaW5lKQo+ID4gIHsKPiA+ICAgICAgY29uc29sZV9zdGFydF9zeW5jKCk7Cj4g
PiAgICAgIHByaW50aygiWGVuIEJVRyBhdCAlczolZFxuIiwgZmlsZSwgbGluZSk7Cj4gPiBAQCAt
MTE0Niw3ICsxMTQ2LDcgQEAgdm9pZCBfX2J1ZyhjaGFyICpmaWxlLCBpbnQgbGluZSkKPiA+ICAg
ICAgcGFuaWMoIlhlbiBCVUcgYXQgJXM6JWQiLCBmaWxlLCBsaW5lKTsKPiA+ICB9Cj4gPgo+ID4g
LXZvaWQgX193YXJuKGNoYXIgKmZpbGUsIGludCBsaW5lKQo+ID4gK3ZvaWQgX193YXJuKGNvbnN0
IGNoYXIgKmZpbGUsIGludCBsaW5lKQo+ID4gIHsKPiA+ICAgICAgcHJpbnRrKCJYZW4gV0FSTiBh
dCAlczolZFxuIiwgZmlsZSwgbGluZSk7Cj4gPiAgICAgIGR1bXBfZXhlY3V0aW9uX3N0YXRlKCk7
Cj4gPiBkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL2xpYi5oIGIveGVuL2luY2x1ZGUveGVu
L2xpYi5oCj4gPiBpbmRleCBmMTFiNDllLi44ZjljYWRiIDEwMDY0NAo+ID4gLS0tIGEveGVuL2lu
Y2x1ZGUveGVuL2xpYi5oCj4gPiArKysgYi94ZW4vaW5jbHVkZS94ZW4vbGliLmgKPiA+IEBAIC04
LDggKzgsOCBAQAo+ID4gICNpbmNsdWRlIDx4ZW4vc3RyaW5nLmg+Cj4gPiAgI2luY2x1ZGUgPGFz
bS9idWcuaD4KPiA+Cj4gPiAtdm9pZCBub3JldHVybiBfX2J1ZyhjaGFyICpmaWxlLCBpbnQgbGlu
ZSk7Cj4gPiAtdm9pZCBfX3dhcm4oY2hhciAqZmlsZSwgaW50IGxpbmUpOwo+ID4gK3ZvaWQgbm9y
ZXR1cm4gX19idWcoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpOwo+ID4gK3ZvaWQgX193YXJu
KGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKTsKPiA+Cj4gPiAgI2RlZmluZSBCVUdfT04ocCkg
IGRvIHsgaWYgKHVubGlrZWx5KHApKSBCVUcoKTsgIH0gd2hpbGUgKDApCj4gPiAgI2RlZmluZSBX
QVJOX09OKHApIGRvIHsgaWYgKHVubGlrZWx5KHApKSBXQVJOKCk7IH0gd2hpbGUgKDApCgotLSAK
TWloYWkgRE9OyJpVCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:56:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17: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 1XyP1n-0003rF-V8; Tue, 09 Dec 2014 17:56: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 1XyP1n-0003r6-6e
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 17:56:51 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	AB/5A-25727-2E737845; Tue, 09 Dec 2014 17:56:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418147807!9709787!1
X-Originating-IP: [66.165.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 26633 invoked from network); 9 Dec 2014 17:56: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;
	9 Dec 2014 17:56:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="202016315"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 12:52: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 1XyOxm-0008GF-JV;
	Tue, 09 Dec 2014 17:52:42 +0000
Date: Tue, 9 Dec 2014 17:52:42 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141209175242.GF25749@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-13-git-send-email-wei.liu2@citrix.com>
	<5487356E020000780004E362@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5487356E020000780004E362@mail.emea.novell.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@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 12/19] hvmloader: retrieve vNUMA
 information from 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, Dec 09, 2014 at 04:46:22PM +0000, Jan Beulich wrote:
> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> > @@ -261,6 +262,8 @@ int main(void)
> >  
> >      init_hypercalls();
> >  
> > +    init_vnuma_info();
> 
> This is very early, and I don't think it needs to be - I guess it could be
> done right before doing ACPI stuff?
> 

Yes, it can be moved right before ACPI stuff.

> > --- /dev/null
> > +++ b/tools/firmware/hvmloader/vnuma.c
> > @@ -0,0 +1,84 @@
> > +/*
> > + * vnuma.c: obtain vNUMA information from hypervisor
> > + *
> > + * Copyright (c) 2014 Wei Liu, Citrix Systems (R&D) Ltd.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + *    notice, this list of conditions and the following disclaimer.
> > + * 2. Redistributions in binary form must reproduce the above copyright
> > + *    notice, this list of conditions and the following disclaimer in the
> > + *    documentation and/or other materials provided with the distribution.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> > + * ARE DISCLAIMED.  IN NO EVENT SHALL AUTHOR 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 "util.h"
> > +#include "hypercall.h"
> > +#include "vnuma.h"
> > +#include <errno.h>
> 
> This is the system header, not the Xen one. See the discussion at
> http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg03206.html
> and perhaps build on the resulting patch
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00013.html.
> 

I will cherry pick that patch and build on top of it.

> > +
> > +unsigned int nr_vnodes, nr_vmemranges;
> > +unsigned int *vcpu_to_vnode, *vdistance;
> > +xen_vmemrange_t *vmemrange;
> > +
[...]
> > + */
> > +
> > +#ifndef __HVMLOADER_VNUMA_H__
> > +#define __HVMLOADER_VNUMA_H__
> > +
> > +#include <xen/memory.h>
> > +
> > +#define MAX_VNODES     64
> > +#define MAX_VDISTANCE  (MAX_VNODES * MAX_VNODES)
> > +#define MAX_VMEMRANGES (MAX_VNODES * 2)
> 
> These look arbitrary - please add a (brief) comment giving some
> rationale so that people needing to change them know eventual
> consequences. Would it perhaps make sense to derive
> MAX_VNODES from HVM_MAX_VCPUS? Additionally I think the

I don't think these two have very strong connection though.

And I remember you saying HVM_MAX_VCPUS will be removed.

> code wouldn't become much more difficult if you didn't build in
> static upper limits.
> 

Yes I can make two hypercalls. First one to retrieve the number of nodes
/ vmemranges configured, allocate memory then fill in those arrays with
second hypercall.

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 17:56:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 17: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 1XyP1n-0003rF-V8; Tue, 09 Dec 2014 17:56: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 1XyP1n-0003r6-6e
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 17:56:51 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	AB/5A-25727-2E737845; Tue, 09 Dec 2014 17:56:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418147807!9709787!1
X-Originating-IP: [66.165.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 26633 invoked from network); 9 Dec 2014 17:56: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;
	9 Dec 2014 17:56:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="202016315"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 12:52: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 1XyOxm-0008GF-JV;
	Tue, 09 Dec 2014 17:52:42 +0000
Date: Tue, 9 Dec 2014 17:52:42 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141209175242.GF25749@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-13-git-send-email-wei.liu2@citrix.com>
	<5487356E020000780004E362@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5487356E020000780004E362@mail.emea.novell.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@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 12/19] hvmloader: retrieve vNUMA
 information from 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, Dec 09, 2014 at 04:46:22PM +0000, Jan Beulich wrote:
> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> > @@ -261,6 +262,8 @@ int main(void)
> >  
> >      init_hypercalls();
> >  
> > +    init_vnuma_info();
> 
> This is very early, and I don't think it needs to be - I guess it could be
> done right before doing ACPI stuff?
> 

Yes, it can be moved right before ACPI stuff.

> > --- /dev/null
> > +++ b/tools/firmware/hvmloader/vnuma.c
> > @@ -0,0 +1,84 @@
> > +/*
> > + * vnuma.c: obtain vNUMA information from hypervisor
> > + *
> > + * Copyright (c) 2014 Wei Liu, Citrix Systems (R&D) Ltd.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + *    notice, this list of conditions and the following disclaimer.
> > + * 2. Redistributions in binary form must reproduce the above copyright
> > + *    notice, this list of conditions and the following disclaimer in the
> > + *    documentation and/or other materials provided with the distribution.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> > + * ARE DISCLAIMED.  IN NO EVENT SHALL AUTHOR 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 "util.h"
> > +#include "hypercall.h"
> > +#include "vnuma.h"
> > +#include <errno.h>
> 
> This is the system header, not the Xen one. See the discussion at
> http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg03206.html
> and perhaps build on the resulting patch
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00013.html.
> 

I will cherry pick that patch and build on top of it.

> > +
> > +unsigned int nr_vnodes, nr_vmemranges;
> > +unsigned int *vcpu_to_vnode, *vdistance;
> > +xen_vmemrange_t *vmemrange;
> > +
[...]
> > + */
> > +
> > +#ifndef __HVMLOADER_VNUMA_H__
> > +#define __HVMLOADER_VNUMA_H__
> > +
> > +#include <xen/memory.h>
> > +
> > +#define MAX_VNODES     64
> > +#define MAX_VDISTANCE  (MAX_VNODES * MAX_VNODES)
> > +#define MAX_VMEMRANGES (MAX_VNODES * 2)
> 
> These look arbitrary - please add a (brief) comment giving some
> rationale so that people needing to change them know eventual
> consequences. Would it perhaps make sense to derive
> MAX_VNODES from HVM_MAX_VCPUS? Additionally I think the

I don't think these two have very strong connection though.

And I remember you saying HVM_MAX_VCPUS will be removed.

> code wouldn't become much more difficult if you didn't build in
> static upper limits.
> 

Yes I can make two hypercalls. First one to retrieve the number of nodes
/ vmemranges configured, allocate memory then fill in those arrays with
second hypercall.

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 18:05:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 18: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 1XyPAH-0004T9-Vc; Tue, 09 Dec 2014 18:05:37 +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 1XyPAH-0004T4-4T
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 18:05:37 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	8E/25-11581-0F937845; Tue, 09 Dec 2014 18:05:36 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418148335!12418485!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32746 invoked from network); 9 Dec 2014 18:05:36 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 9 Dec 2014 18:05:36 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:51879 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 1XyPA7-0007yr-Gk; Tue, 09 Dec 2014 19:05:27 +0100
Date: Tue, 9 Dec 2014 19:05:32 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <2010536337.20141209190532@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <54873F74020000780004E442@mail.emea.novell.com>
References: <1708243085.20141209172445@eikelenboom.it>
	<54873F74020000780004E442@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: irq.c:xxxx: dom1: forcing unbind of
	pirq 40
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 9, 2014, 6:29:08 PM, you wrote:

>>>> On 09.12.14 at 17:24, <linux@eikelenboom.it> wrote:
>> Currently i'm running Xen-unstable with Stefano's libxl fixup patches (not 
>> doing 
>> reset due to qmp race, switching order of xc_domain_irq_permission and 
>> xc_physdev_unmap_pirq)
>> and with a kernel with Konrad's 3.19 patch series. 
>> 
>> Although i have seen these messages before, so i don't know if it is a 
>> recent 
>> regression (don't think so). 
>> 
>> I still see these in xl dmesg when shutting down guests with pci 
>> passthrough:
>> "irq.c:xxxx: dom1: forcing unbind of pirq 40"
>> 
>> It seems to cleanup ok afterwards, but from the sound warning it shouldn't 
>> get
>> to that point. I get these for both PV and HVM guests.

> These messages simply indicate that the guest didn't do some
> expected cleanup itself.

OK, the thing is that at present is does this on every shutdown of guests with 
pci-passthrough, all running a recent kernel. That hasn't always been that way 
as far as i can remember. I will see if i have some old 
guest kernels and see if i get the same there.

> I see these too when Dom0 shuts down,
> at least for certain drivers. For HVM arguably qemu might know
> better and tear things down properly, but in no event are these
> messages - when occurring in connection with a guest going
> down - indications of a problem. We could even see to lower their
> severity or suppress them altogether when the domain is known
> to be dying (you may want to check whether ->is_dying is already
> set at that point).

Just tested, but for both PV and HVM when it enters "unmap_domain_pirq" 
d->is_dying ? 1 : 0 returns 0.

> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 18:05:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 18: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 1XyPAH-0004T9-Vc; Tue, 09 Dec 2014 18:05:37 +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 1XyPAH-0004T4-4T
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 18:05:37 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	8E/25-11581-0F937845; Tue, 09 Dec 2014 18:05:36 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418148335!12418485!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32746 invoked from network); 9 Dec 2014 18:05:36 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 9 Dec 2014 18:05:36 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:51879 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 1XyPA7-0007yr-Gk; Tue, 09 Dec 2014 19:05:27 +0100
Date: Tue, 9 Dec 2014 19:05:32 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <2010536337.20141209190532@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <54873F74020000780004E442@mail.emea.novell.com>
References: <1708243085.20141209172445@eikelenboom.it>
	<54873F74020000780004E442@mail.emea.novell.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: irq.c:xxxx: dom1: forcing unbind of
	pirq 40
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 9, 2014, 6:29:08 PM, you wrote:

>>>> On 09.12.14 at 17:24, <linux@eikelenboom.it> wrote:
>> Currently i'm running Xen-unstable with Stefano's libxl fixup patches (not 
>> doing 
>> reset due to qmp race, switching order of xc_domain_irq_permission and 
>> xc_physdev_unmap_pirq)
>> and with a kernel with Konrad's 3.19 patch series. 
>> 
>> Although i have seen these messages before, so i don't know if it is a 
>> recent 
>> regression (don't think so). 
>> 
>> I still see these in xl dmesg when shutting down guests with pci 
>> passthrough:
>> "irq.c:xxxx: dom1: forcing unbind of pirq 40"
>> 
>> It seems to cleanup ok afterwards, but from the sound warning it shouldn't 
>> get
>> to that point. I get these for both PV and HVM guests.

> These messages simply indicate that the guest didn't do some
> expected cleanup itself.

OK, the thing is that at present is does this on every shutdown of guests with 
pci-passthrough, all running a recent kernel. That hasn't always been that way 
as far as i can remember. I will see if i have some old 
guest kernels and see if i get the same there.

> I see these too when Dom0 shuts down,
> at least for certain drivers. For HVM arguably qemu might know
> better and tear things down properly, but in no event are these
> messages - when occurring in connection with a guest going
> down - indications of a problem. We could even see to lower their
> severity or suppress them altogether when the domain is known
> to be dying (you may want to check whether ->is_dying is already
> set at that point).

Just tested, but for both PV and HVM when it enters "unmap_domain_pirq" 
d->is_dying ? 1 : 0 returns 0.

> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 18:07:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 18:07:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyPBh-0004Yf-JH; Tue, 09 Dec 2014 18:07:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XyPBg-0004YU-73
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 18:07:04 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	27/86-17958-74A37845; Tue, 09 Dec 2014 18:07:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418148421!12167340!1
X-Originating-IP: [66.165.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 454 invoked from network); 9 Dec 2014 18:07: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;
	9 Dec 2014 18:07:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="202423520"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 13:06: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 1XyPBZ-0008W9-Cv;
	Tue, 09 Dec 2014 18:06:57 +0000
Date: Tue, 9 Dec 2014 18:06:57 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141209180657.GG25749@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
	<54873724020000780004E37B@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54873724020000780004E37B@mail.emea.novell.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@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 13/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 Tue, Dec 09, 2014 at 04:53:40PM +0000, Jan Beulich wrote:
> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> > @@ -203,6 +204,65 @@ 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) * nr_vmemranges;
> > +
> > +    p = mem_alloc(size, 16);
> > +    if (!p) return NULL;
> 
> Coding style (despite you likely copied it from elsewhere).
> 

Fixed.

> > +
> > +    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   = vcpu_to_vnode[i];
> > +        processor->apic_id  = LAPIC_ID(i);
> > +        processor->flags    = ACPI_LOCAL_APIC_AFFIN_ENABLED;
> > +        processor++;
> > +    }
> > +
> > +    memory = (struct acpi_20_srat_memory *)processor;
> > +    for ( i = 0; i < nr_vmemranges; i++ )
> > +    {
> > +        mem = vmemrange[i].end - vmemrange[i].start;
> 
> Do you really need this helper variable?
> 

Removed.

> > +        memset(memory, 0, sizeof(*memory));
> > +        memory->type          = ACPI_MEMORY_AFFINITY;
> > +        memory->length        = sizeof(*memory);
> > +        memory->domain        = vmemrange[i].nid;
> > +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
> > +        memory->base_address  = vmemrange[i].start;
> > +        memory->mem_length    = mem;
> > +        memory++;
> > +    }
> > +
> > +    srat->header.length = size;
> 
> Mind checking size == memory - p here?
> 

Why? There doesn't seem to be anything that would cause memory -p !=
size in between during runtime.

> > @@ -346,6 +407,16 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
> >          }
> >      }
> >  
> > +    /* SRAT */
> > +    if ( nr_vnodes > 0 )
> > +    {
> > +        srat = construct_srat();
> > +        if (srat)
> 
> Coding style again.
> 

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 Tue Dec 09 18:07:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 18:07:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyPBh-0004Yf-JH; Tue, 09 Dec 2014 18:07:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XyPBg-0004YU-73
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 18:07:04 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	27/86-17958-74A37845; Tue, 09 Dec 2014 18:07:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418148421!12167340!1
X-Originating-IP: [66.165.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 454 invoked from network); 9 Dec 2014 18:07: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;
	9 Dec 2014 18:07:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="202423520"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 13:06: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 1XyPBZ-0008W9-Cv;
	Tue, 09 Dec 2014 18:06:57 +0000
Date: Tue, 9 Dec 2014 18:06:57 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141209180657.GG25749@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
	<54873724020000780004E37B@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54873724020000780004E37B@mail.emea.novell.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@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 13/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 Tue, Dec 09, 2014 at 04:53:40PM +0000, Jan Beulich wrote:
> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> > @@ -203,6 +204,65 @@ 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) * nr_vmemranges;
> > +
> > +    p = mem_alloc(size, 16);
> > +    if (!p) return NULL;
> 
> Coding style (despite you likely copied it from elsewhere).
> 

Fixed.

> > +
> > +    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   = vcpu_to_vnode[i];
> > +        processor->apic_id  = LAPIC_ID(i);
> > +        processor->flags    = ACPI_LOCAL_APIC_AFFIN_ENABLED;
> > +        processor++;
> > +    }
> > +
> > +    memory = (struct acpi_20_srat_memory *)processor;
> > +    for ( i = 0; i < nr_vmemranges; i++ )
> > +    {
> > +        mem = vmemrange[i].end - vmemrange[i].start;
> 
> Do you really need this helper variable?
> 

Removed.

> > +        memset(memory, 0, sizeof(*memory));
> > +        memory->type          = ACPI_MEMORY_AFFINITY;
> > +        memory->length        = sizeof(*memory);
> > +        memory->domain        = vmemrange[i].nid;
> > +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
> > +        memory->base_address  = vmemrange[i].start;
> > +        memory->mem_length    = mem;
> > +        memory++;
> > +    }
> > +
> > +    srat->header.length = size;
> 
> Mind checking size == memory - p here?
> 

Why? There doesn't seem to be anything that would cause memory -p !=
size in between during runtime.

> > @@ -346,6 +407,16 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
> >          }
> >      }
> >  
> > +    /* SRAT */
> > +    if ( nr_vnodes > 0 )
> > +    {
> > +        srat = construct_srat();
> > +        if (srat)
> 
> Coding style again.
> 

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 Tue Dec 09 18:09:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 18:09:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyPDt-0004hW-3t; Tue, 09 Dec 2014 18:09:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XyPDs-0004hO-3g
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 18:09:20 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	37/7C-22819-FCA37845; Tue, 09 Dec 2014 18:09:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418148557!12402677!1
X-Originating-IP: [66.165.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 4034 invoked from network); 9 Dec 2014 18:09:18 -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;
	9 Dec 2014 18:09:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="202424749"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 13:09: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 1XyPDo-000072-HQ;
	Tue, 09 Dec 2014 18:09:16 +0000
Date: Tue, 9 Dec 2014 18:09:16 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141209180916.GH25749@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-15-git-send-email-wei.liu2@citrix.com>
	<548737FA020000780004E38B@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548737FA020000780004E38B@mail.emea.novell.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@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 14/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 Tue, Dec 09, 2014 at 04:57:14PM +0000, Jan Beulich wrote:
> >>> On 01.12.14 at 16:33, <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;
> 
> unsigned int please. Plus similar coding style issues further down as in
> the previous patch.
> 

Fixed.

> > @@ -415,6 +448,11 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
> >              table_ptrs[nr_tables++] = (unsigned long)srat;
> >          else
> >              printf("Failed to build SRAT, skipping...\n");
> > +        slit = construct_slit();
> > +        if (srat)
> 
> DYM slit?
> 

Yes. :-/

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 18:09:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 18:09:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyPDt-0004hW-3t; Tue, 09 Dec 2014 18:09:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XyPDs-0004hO-3g
	for xen-devel@lists.xen.org; Tue, 09 Dec 2014 18:09:20 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	37/7C-22819-FCA37845; Tue, 09 Dec 2014 18:09:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418148557!12402677!1
X-Originating-IP: [66.165.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 4034 invoked from network); 9 Dec 2014 18:09:18 -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;
	9 Dec 2014 18:09:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="202424749"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 13:09: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 1XyPDo-000072-HQ;
	Tue, 09 Dec 2014 18:09:16 +0000
Date: Tue, 9 Dec 2014 18:09:16 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141209180916.GH25749@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-15-git-send-email-wei.liu2@citrix.com>
	<548737FA020000780004E38B@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548737FA020000780004E38B@mail.emea.novell.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@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 14/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 Tue, Dec 09, 2014 at 04:57:14PM +0000, Jan Beulich wrote:
> >>> On 01.12.14 at 16:33, <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;
> 
> unsigned int please. Plus similar coding style issues further down as in
> the previous patch.
> 

Fixed.

> > @@ -415,6 +448,11 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
> >              table_ptrs[nr_tables++] = (unsigned long)srat;
> >          else
> >              printf("Failed to build SRAT, skipping...\n");
> > +        slit = construct_slit();
> > +        if (srat)
> 
> DYM slit?
> 

Yes. :-/

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 18:44:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 18: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 1XyPl9-0005jy-14; Tue, 09 Dec 2014 18:43:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XyPl7-0005jt-Sh
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 18:43:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0C/1F-09842-DD247845; Tue, 09 Dec 2014 18:43:41 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418150619!14516712!1
X-Originating-IP: [66.165.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 10944 invoked from network); 9 Dec 2014 18:43:40 -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;
	9 Dec 2014 18:43:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="202043762"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 13:43:38 -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 1XyPl4-0000os-EF;
	Tue, 09 Dec 2014 18:43:38 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <netdev@vger.kernel.org>
Date: Tue, 9 Dec 2014 18:43:28 +0000
Message-ID: <1418150608-26180-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,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCHv1 net] xen-netfront: use correct linear area
	after linearizing an skb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 97a6d1bb2b658ac85ed88205ccd1ab809899884d (xen-netfront: Fix
handling packets on compound pages with skb_linearize) attempted to
fix a problem where an skb that would have required too many slots
would be dropped causing TCP connections to stall.

However, it filled in the first slot using the original buffer and not
the new one and would use the wrong offset and grant access to the
wrong page.

Netback would notice the malformed request and stop all traffic on the
VIF, reporting:

    vif vif-3-0 vif3.0: txreq.offset: 85e, size: 4002, end: 6144
    vif vif-3-0 vif3.0: fatal error; disabling device

Reported-by: Anthony Wright <anthony@overnetdata.com>
Tested-by: Anthony Wright <anthony@overnetdata.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netfront.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index ece8d18..eeed0ce 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -627,6 +627,9 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 				    slots, skb->len);
 		if (skb_linearize(skb))
 			goto drop;
+		data = skb->data;
+		offset = offset_in_page(data);
+		len = skb_headlen(skb);
 	}
 
 	spin_lock_irqsave(&queue->tx_lock, flags);
-- 
1.7.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 Dec 09 18:44:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 18: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 1XyPl9-0005jy-14; Tue, 09 Dec 2014 18:43:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1XyPl7-0005jt-Sh
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 18:43:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0C/1F-09842-DD247845; Tue, 09 Dec 2014 18:43:41 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418150619!14516712!1
X-Originating-IP: [66.165.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 10944 invoked from network); 9 Dec 2014 18:43:40 -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;
	9 Dec 2014 18:43:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="202043762"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 9 Dec 2014 13:43:38 -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 1XyPl4-0000os-EF;
	Tue, 09 Dec 2014 18:43:38 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <netdev@vger.kernel.org>
Date: Tue, 9 Dec 2014 18:43:28 +0000
Message-ID: <1418150608-26180-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,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCHv1 net] xen-netfront: use correct linear area
	after linearizing an skb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 97a6d1bb2b658ac85ed88205ccd1ab809899884d (xen-netfront: Fix
handling packets on compound pages with skb_linearize) attempted to
fix a problem where an skb that would have required too many slots
would be dropped causing TCP connections to stall.

However, it filled in the first slot using the original buffer and not
the new one and would use the wrong offset and grant access to the
wrong page.

Netback would notice the malformed request and stop all traffic on the
VIF, reporting:

    vif vif-3-0 vif3.0: txreq.offset: 85e, size: 4002, end: 6144
    vif vif-3-0 vif3.0: fatal error; disabling device

Reported-by: Anthony Wright <anthony@overnetdata.com>
Tested-by: Anthony Wright <anthony@overnetdata.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netfront.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index ece8d18..eeed0ce 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -627,6 +627,9 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 				    slots, skb->len);
 		if (skb_linearize(skb))
 			goto drop;
+		data = skb->data;
+		offset = offset_in_page(data);
+		len = skb_headlen(skb);
 	}
 
 	spin_lock_irqsave(&queue->tx_lock, flags);
-- 
1.7.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 Dec 09 19:19:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 19: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 1XyQJD-0007e4-Gv; Tue, 09 Dec 2014 19:18:55 +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 1XyQJC-0007dz-Dv
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 19:18:54 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	41/8D-02699-D1B47845; Tue, 09 Dec 2014 19:18:53 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418152733!13984258!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25413 invoked from network); 9 Dec 2014 19:18:53 -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; 9 Dec 2014 19:18:53 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52660 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 1XyQJ2-0005LY-OR; Tue, 09 Dec 2014 20:18:44 +0100
Date: Tue, 9 Dec 2014 20:18:49 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <292142873.20141209201849@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <2010536337.20141209190532@eikelenboom.it>
References: <1708243085.20141209172445@eikelenboom.it>
	<54873F74020000780004E442@mail.emea.novell.com>
	<2010536337.20141209190532@eikelenboom.it>
MIME-Version: 1.0
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: irq.c:xxxx: dom1: forcing unbind of
	pirq 40
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 9, 2014, 7:05:32 PM, you wrote:


> Tuesday, December 9, 2014, 6:29:08 PM, you wrote:

>>>>> On 09.12.14 at 17:24, <linux@eikelenboom.it> wrote:
>>> Currently i'm running Xen-unstable with Stefano's libxl fixup patches (not 
>>> doing 
>>> reset due to qmp race, switching order of xc_domain_irq_permission and 
>>> xc_physdev_unmap_pirq)
>>> and with a kernel with Konrad's 3.19 patch series. 
>>> 
>>> Although i have seen these messages before, so i don't know if it is a 
>>> recent 
>>> regression (don't think so). 
>>> 
>>> I still see these in xl dmesg when shutting down guests with pci 
>>> passthrough:
>>> "irq.c:xxxx: dom1: forcing unbind of pirq 40"
>>> 
>>> It seems to cleanup ok afterwards, but from the sound warning it shouldn't 
>>> get
>>> to that point. I get these for both PV and HVM guests.

>> These messages simply indicate that the guest didn't do some
>> expected cleanup itself.

> OK, the thing is that at present is does this on every shutdown of guests with 
> pci-passthrough, all running a recent kernel. That hasn't always been that way 
> as far as i can remember. I will see if i have some old 
> guest kernels and see if i get the same there.

The most ancient i had around was 3.12, tested on the PV guest, but no 
difference.

>> I see these too when Dom0 shuts down,
>> at least for certain drivers. For HVM arguably qemu might know
>> better and tear things down properly, but in no event are these
>> messages - when occurring in connection with a guest going
>> down - indications of a problem. We could even see to lower their
>> severity or suppress them altogether when the domain is known
>> to be dying (you may want to check whether ->is_dying is already
>> set at that point).

> Just tested, but for both PV and HVM when it enters "unmap_domain_pirq" 
d->>is_dying ? 1 : 0 returns 0.

>> Jan







_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 19:19:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 19: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 1XyQJD-0007e4-Gv; Tue, 09 Dec 2014 19:18:55 +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 1XyQJC-0007dz-Dv
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 19:18:54 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	41/8D-02699-D1B47845; Tue, 09 Dec 2014 19:18:53 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418152733!13984258!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25413 invoked from network); 9 Dec 2014 19:18:53 -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; 9 Dec 2014 19:18:53 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:52660 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 1XyQJ2-0005LY-OR; Tue, 09 Dec 2014 20:18:44 +0100
Date: Tue, 9 Dec 2014 20:18:49 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <292142873.20141209201849@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <2010536337.20141209190532@eikelenboom.it>
References: <1708243085.20141209172445@eikelenboom.it>
	<54873F74020000780004E442@mail.emea.novell.com>
	<2010536337.20141209190532@eikelenboom.it>
MIME-Version: 1.0
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: irq.c:xxxx: dom1: forcing unbind of
	pirq 40
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 9, 2014, 7:05:32 PM, you wrote:


> Tuesday, December 9, 2014, 6:29:08 PM, you wrote:

>>>>> On 09.12.14 at 17:24, <linux@eikelenboom.it> wrote:
>>> Currently i'm running Xen-unstable with Stefano's libxl fixup patches (not 
>>> doing 
>>> reset due to qmp race, switching order of xc_domain_irq_permission and 
>>> xc_physdev_unmap_pirq)
>>> and with a kernel with Konrad's 3.19 patch series. 
>>> 
>>> Although i have seen these messages before, so i don't know if it is a 
>>> recent 
>>> regression (don't think so). 
>>> 
>>> I still see these in xl dmesg when shutting down guests with pci 
>>> passthrough:
>>> "irq.c:xxxx: dom1: forcing unbind of pirq 40"
>>> 
>>> It seems to cleanup ok afterwards, but from the sound warning it shouldn't 
>>> get
>>> to that point. I get these for both PV and HVM guests.

>> These messages simply indicate that the guest didn't do some
>> expected cleanup itself.

> OK, the thing is that at present is does this on every shutdown of guests with 
> pci-passthrough, all running a recent kernel. That hasn't always been that way 
> as far as i can remember. I will see if i have some old 
> guest kernels and see if i get the same there.

The most ancient i had around was 3.12, tested on the PV guest, but no 
difference.

>> I see these too when Dom0 shuts down,
>> at least for certain drivers. For HVM arguably qemu might know
>> better and tear things down properly, but in no event are these
>> messages - when occurring in connection with a guest going
>> down - indications of a problem. We could even see to lower their
>> severity or suppress them altogether when the domain is known
>> to be dying (you may want to check whether ->is_dying is already
>> set at that point).

> Just tested, but for both PV and HVM when it enters "unmap_domain_pirq" 
d->>is_dying ? 1 : 0 returns 0.

>> Jan







_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 20:23:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 20:23:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyRJZ-0001du-52; Tue, 09 Dec 2014 20:23:21 +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 1XyRJX-0001dk-Gq
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 20:23:19 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	7D/07-22737-63A57845; Tue, 09 Dec 2014 20:23:18 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418156598!12428033!1
X-Originating-IP: [209.85.217.178]
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 18236 invoked from network); 9 Dec 2014 20:23:18 -0000
Received: from mail-lb0-f178.google.com (HELO mail-lb0-f178.google.com)
	(209.85.217.178)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 20:23:18 -0000
Received: by mail-lb0-f178.google.com with SMTP id f15so1305327lbj.9
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 12:23:18 -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=56pISJdsixPpUyVreJ7qC4zyMq5w11ibOHtUkLdcO7M=;
	b=Teea04KWXYDTuwYyOAsUoJjV9efAcRZy+B8tsSPmXTlfI3Y4ZYk3PnttpzNkNbdnDJ
	4ZIKEpIEmaBflEC6sTQN2QnDycKxvlmZXBROoumxxkllK1RNUxRTiTd6Tzwx1WcN2XKO
	q9BzSz4ImVRC+zZWmBuBcDzfZP//WkJ2fnbrytAyPuxgdhVFR3w80aaoqPTJilHnRn+d
	F+7+8dlRBweZTu5dbbxVHxnk7Tj0+kU1Mcy/nOg6YCCwiTbQSyuaI7xldF4UHKuaMVSb
	KyacL+dCJo7OZ0QceJVGzon2lnOpm63jfzeTT4aLAalBE+AQGnbeAWHavhHmNdejLj96
	WN8Q==
X-Received: by 10.112.73.102 with SMTP id k6mr194496lbv.75.1418156597858; Tue,
	09 Dec 2014 12:23:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.203.232 with HTTP; Tue, 9 Dec 2014 12:22:57 -0800 (PST)
In-Reply-To: <CAB=NE6V+kLaZePAzHim0VxGsd8ew6dS7kN=H=awwz1dpHy5VJw@mail.gmail.com>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
	<1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
	<5486BBB1.3040405@linaro.org>
	<CAB=NE6V+kLaZePAzHim0VxGsd8ew6dS7kN=H=awwz1dpHy5VJw@mail.gmail.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Date: Tue, 9 Dec 2014 12:22:57 -0800
X-Google-Sender-Auth: cAUNwiPDa9yMAH9cKrpUHQv1mYE
Message-ID: <CAB=NE6XaT34DDGio16dyRqxPu25XE0PZYOX2n+6+GabPFXih0g@mail.gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Michal Marek <mmarek@suse.cz>, x86@kernel.org,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	Randy Dunlap <rdunlap@infradead.org>, josh@joshtriplett.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pekka Enberg <penberg@kernel.org>, mtosatti@redhat.com,
	Benjamin Poirier <bpoirier@suse.de>, Borislav Petkov <bp@suse.de>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	David Rientjes <rientjes@google.com>,
	Fengguang Wu <fengguang.wu@intel.com>, sam@ravnborg.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 9, 2014 at 12:22 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> If you are sure then yes.

Likewise here.

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 20:23:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 20:23:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyRJM-0001dU-PB; Tue, 09 Dec 2014 20:23:08 +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 1XyRJL-0001dM-LG
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 20:23:07 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	31/42-25714-A2A57845; Tue, 09 Dec 2014 20:23:06 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418156585!9083965!1
X-Originating-IP: [209.85.215.46]
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 5118 invoked from network); 9 Dec 2014 20:23:06 -0000
Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com)
	(209.85.215.46)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 20:23:06 -0000
Received: by mail-la0-f46.google.com with SMTP id q1so1223277lam.19
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 12:23:05 -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=Bar8kGjpvU8hDp0jDhEXPT0AtTBbTUcHrX0dvx7YhCk=;
	b=WAxnzNQgvK7PEJD8b9m0zR9UbOsd9TJ25CP84ZIEhco8G141cGkyfXJW50M4OPuZuV
	3Oca0IuIQc4sGIDeDPFJCa7dSqd73AlIlGK+BUy2MpVcBvh8KdyuDvXE7BjpLc70miXD
	AuDny7APH+7oetwDxrLi6HIgbFqOyY0ZsE6UFDNS7qDZQQpkP4dBZPcSxUXp9QQPakkK
	xVAWg5xRphDU8nSCWwDbv9A/1bQboYU5AWv0ltI/sKqgyS+852oDRzhsYR2X3jr35sY1
	CqAmS3tcd8YXvHa2DafqLUd9n2s8kIq4V5XschqcqC3DqmWd6CnRcCBT7lWUxpjerHE9
	jEjg==
X-Received: by 10.112.150.71 with SMTP id ug7mr194604lbb.73.1418156585490;
	Tue, 09 Dec 2014 12:23:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.203.232 with HTTP; Tue, 9 Dec 2014 12:22:45 -0800 (PST)
In-Reply-To: <5486BBB1.3040405@linaro.org>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
	<1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
	<5486BBB1.3040405@linaro.org>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Date: Tue, 9 Dec 2014 12:22:45 -0800
X-Google-Sender-Auth: Qm5wyVhoJHtgGr9v8t94HIEIzRU
Message-ID: <CAB=NE6V+kLaZePAzHim0VxGsd8ew6dS7kN=H=awwz1dpHy5VJw@mail.gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Michal Marek <mmarek@suse.cz>, x86@kernel.org,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	Randy Dunlap <rdunlap@infradead.org>, josh@joshtriplett.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pekka Enberg <penberg@kernel.org>, mtosatti@redhat.com,
	Benjamin Poirier <bpoirier@suse.de>, Borislav Petkov <bp@suse.de>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	David Rientjes <rientjes@google.com>,
	Fengguang Wu <fengguang.wu@intel.com>, sam@ravnborg.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall <julien.grall@linaro.org> wrote:
> Hello Luis,
>
> On 08/12/2014 23:05, Luis R. Rodriguez wrote:
>>
>> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
>> new file mode 100644
>> index 0000000..0d0eb6d
>> --- /dev/null
>> +++ b/kernel/configs/xen.config
>> +CONFIG_XEN_MCE_LOG=y
>
>
> MCE is x86 specific.

That's what I thought too but its available for arm64, so should we
fix that Kconfig to depend on x86?

>> +CONFIG_XEN_HAVE_PVMMU=y
>
>
> We don't have PVMMU support on ARM. Shouldn't you move this config in
> architecture specific code?

If you are sure then yes.

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 20:23:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 20:23:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyRJZ-0001du-52; Tue, 09 Dec 2014 20:23:21 +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 1XyRJX-0001dk-Gq
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 20:23:19 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	7D/07-22737-63A57845; Tue, 09 Dec 2014 20:23:18 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418156598!12428033!1
X-Originating-IP: [209.85.217.178]
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 18236 invoked from network); 9 Dec 2014 20:23:18 -0000
Received: from mail-lb0-f178.google.com (HELO mail-lb0-f178.google.com)
	(209.85.217.178)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 20:23:18 -0000
Received: by mail-lb0-f178.google.com with SMTP id f15so1305327lbj.9
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 12:23:18 -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=56pISJdsixPpUyVreJ7qC4zyMq5w11ibOHtUkLdcO7M=;
	b=Teea04KWXYDTuwYyOAsUoJjV9efAcRZy+B8tsSPmXTlfI3Y4ZYk3PnttpzNkNbdnDJ
	4ZIKEpIEmaBflEC6sTQN2QnDycKxvlmZXBROoumxxkllK1RNUxRTiTd6Tzwx1WcN2XKO
	q9BzSz4ImVRC+zZWmBuBcDzfZP//WkJ2fnbrytAyPuxgdhVFR3w80aaoqPTJilHnRn+d
	F+7+8dlRBweZTu5dbbxVHxnk7Tj0+kU1Mcy/nOg6YCCwiTbQSyuaI7xldF4UHKuaMVSb
	KyacL+dCJo7OZ0QceJVGzon2lnOpm63jfzeTT4aLAalBE+AQGnbeAWHavhHmNdejLj96
	WN8Q==
X-Received: by 10.112.73.102 with SMTP id k6mr194496lbv.75.1418156597858; Tue,
	09 Dec 2014 12:23:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.203.232 with HTTP; Tue, 9 Dec 2014 12:22:57 -0800 (PST)
In-Reply-To: <CAB=NE6V+kLaZePAzHim0VxGsd8ew6dS7kN=H=awwz1dpHy5VJw@mail.gmail.com>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
	<1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
	<5486BBB1.3040405@linaro.org>
	<CAB=NE6V+kLaZePAzHim0VxGsd8ew6dS7kN=H=awwz1dpHy5VJw@mail.gmail.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Date: Tue, 9 Dec 2014 12:22:57 -0800
X-Google-Sender-Auth: cAUNwiPDa9yMAH9cKrpUHQv1mYE
Message-ID: <CAB=NE6XaT34DDGio16dyRqxPu25XE0PZYOX2n+6+GabPFXih0g@mail.gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Michal Marek <mmarek@suse.cz>, x86@kernel.org,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	Randy Dunlap <rdunlap@infradead.org>, josh@joshtriplett.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pekka Enberg <penberg@kernel.org>, mtosatti@redhat.com,
	Benjamin Poirier <bpoirier@suse.de>, Borislav Petkov <bp@suse.de>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	David Rientjes <rientjes@google.com>,
	Fengguang Wu <fengguang.wu@intel.com>, sam@ravnborg.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 9, 2014 at 12:22 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> If you are sure then yes.

Likewise here.

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 20:23:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 20:23:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyRJM-0001dU-PB; Tue, 09 Dec 2014 20:23:08 +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 1XyRJL-0001dM-LG
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 20:23:07 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	31/42-25714-A2A57845; Tue, 09 Dec 2014 20:23:06 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418156585!9083965!1
X-Originating-IP: [209.85.215.46]
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 5118 invoked from network); 9 Dec 2014 20:23:06 -0000
Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com)
	(209.85.215.46)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 20:23:06 -0000
Received: by mail-la0-f46.google.com with SMTP id q1so1223277lam.19
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 12:23:05 -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=Bar8kGjpvU8hDp0jDhEXPT0AtTBbTUcHrX0dvx7YhCk=;
	b=WAxnzNQgvK7PEJD8b9m0zR9UbOsd9TJ25CP84ZIEhco8G141cGkyfXJW50M4OPuZuV
	3Oca0IuIQc4sGIDeDPFJCa7dSqd73AlIlGK+BUy2MpVcBvh8KdyuDvXE7BjpLc70miXD
	AuDny7APH+7oetwDxrLi6HIgbFqOyY0ZsE6UFDNS7qDZQQpkP4dBZPcSxUXp9QQPakkK
	xVAWg5xRphDU8nSCWwDbv9A/1bQboYU5AWv0ltI/sKqgyS+852oDRzhsYR2X3jr35sY1
	CqAmS3tcd8YXvHa2DafqLUd9n2s8kIq4V5XschqcqC3DqmWd6CnRcCBT7lWUxpjerHE9
	jEjg==
X-Received: by 10.112.150.71 with SMTP id ug7mr194604lbb.73.1418156585490;
	Tue, 09 Dec 2014 12:23:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.203.232 with HTTP; Tue, 9 Dec 2014 12:22:45 -0800 (PST)
In-Reply-To: <5486BBB1.3040405@linaro.org>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
	<1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
	<5486BBB1.3040405@linaro.org>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Date: Tue, 9 Dec 2014 12:22:45 -0800
X-Google-Sender-Auth: Qm5wyVhoJHtgGr9v8t94HIEIzRU
Message-ID: <CAB=NE6V+kLaZePAzHim0VxGsd8ew6dS7kN=H=awwz1dpHy5VJw@mail.gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Michal Marek <mmarek@suse.cz>, x86@kernel.org,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	Randy Dunlap <rdunlap@infradead.org>, josh@joshtriplett.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pekka Enberg <penberg@kernel.org>, mtosatti@redhat.com,
	Benjamin Poirier <bpoirier@suse.de>, Borislav Petkov <bp@suse.de>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	David Rientjes <rientjes@google.com>,
	Fengguang Wu <fengguang.wu@intel.com>, sam@ravnborg.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall <julien.grall@linaro.org> wrote:
> Hello Luis,
>
> On 08/12/2014 23:05, Luis R. Rodriguez wrote:
>>
>> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
>> new file mode 100644
>> index 0000000..0d0eb6d
>> --- /dev/null
>> +++ b/kernel/configs/xen.config
>> +CONFIG_XEN_MCE_LOG=y
>
>
> MCE is x86 specific.

That's what I thought too but its available for arm64, so should we
fix that Kconfig to depend on x86?

>> +CONFIG_XEN_HAVE_PVMMU=y
>
>
> We don't have PVMMU support on ARM. Shouldn't you move this config in
> architecture specific code?

If you are sure then yes.

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 20:38:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 20: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 1XyRXe-00020j-Mc; Tue, 09 Dec 2014 20:37: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 1XyRXc-00020e-LK
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 20:37:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F3/0E-25276-0AD57845; Tue, 09 Dec 2014 20:37:52 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418157471!14501359!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5381 invoked from network); 9 Dec 2014 20:37:51 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 20:37:51 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so1889302wgg.28
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 12:37: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=ZiQSVcqIzqksfdAb1mfka8iMQ8XJnIYGxJQU93Ls7Os=;
	b=BvH1Ko4GDWwGpi+CtswKhCGLqtgWiUmGYBL652sMIjrx6RO91UZ9sskXE2AM+sVEAp
	Y5Urlm4wAspnuNibGI272ZEJOPjaEtugIAMW0cBE6BiU1Qv4knvt+W6HZQdi3NLZ0TFe
	zwcIw5B2dpwOi3eftdwzmQfBLNtTHfkp376NZ1sR8MxMx2xc1WGaXpCwr2TBUikpyOTe
	8cIP1zdZ1vp/vVYCq5FrdNWlLvFexu6TvS3YcFNk9VwmKNQlFQdZReb40K5NNvosA4E4
	retXZ9h+Gy6WIovAC0OHIqMEswt8vSuCaYEgTfCsR1vbcqO8+T74Twjec9vFZLB9S7iZ
	ws3Q==
X-Gm-Message-State: ALoCoQnLsrRDjnzU3bHfIJIsEWyiMu3Pmbh/Y22PamB4QQxvU+aNqTjXTylC1grU9X2mIkjxEnu0
X-Received: by 10.181.8.193 with SMTP id dm1mr371523wid.55.1418157471025;
	Tue, 09 Dec 2014 12:37:51 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	dm10sm15255828wib.18.2014.12.09.12.37.49 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 09 Dec 2014 12:37:50 -0800 (PST)
Message-ID: <54875D99.6070301@linaro.org>
Date: Tue, 09 Dec 2014 20:37:45 +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: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
	<1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
	<5486BBB1.3040405@linaro.org>
	<CAB=NE6V+kLaZePAzHim0VxGsd8ew6dS7kN=H=awwz1dpHy5VJw@mail.gmail.com>
In-Reply-To: <CAB=NE6V+kLaZePAzHim0VxGsd8ew6dS7kN=H=awwz1dpHy5VJw@mail.gmail.com>
Cc: Michal Marek <mmarek@suse.cz>, x86@kernel.org,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	Randy Dunlap <rdunlap@infradead.org>, josh@joshtriplett.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pekka Enberg <penberg@kernel.org>, mtosatti@redhat.com,
	Benjamin Poirier <bpoirier@suse.de>, Borislav Petkov <bp@suse.de>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	David Rientjes <rientjes@google.com>,
	Fengguang Wu <fengguang.wu@intel.com>, sam@ravnborg.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/12/14 20:22, Luis R. Rodriguez wrote:
> On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall <julien.grall@linaro.org> wrote:
>> Hello Luis,
>>
>> On 08/12/2014 23:05, Luis R. Rodriguez wrote:
>>>
>>> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
>>> new file mode 100644
>>> index 0000000..0d0eb6d
>>> --- /dev/null
>>> +++ b/kernel/configs/xen.config
>>> +CONFIG_XEN_MCE_LOG=y
>>
>>
>> MCE is x86 specific.
> 
> That's what I thought too but its available for arm64, so should we
> fix that Kconfig to depend on x86?

Are you sure? On the Linus's repo I have:

config XEN_MCE_LOG
        bool "Xen platform mcelog"
        depends on XEN_DOM0 && X86_64 && X86_MCE

Anyway, the MCE interface in the hypervisor is implemented in arch/x86
not in common code.

>>> +CONFIG_XEN_HAVE_PVMMU=y
>>
>>
>> We don't have PVMMU support on ARM. Shouldn't you move this config in
>> architecture specific code?
> 
> If you are sure then yes.

I'm 100% sure. MMU is handled by the hardware on ARM.

Thinking a bit more about this option. CONFIG_XEN_HAVE_PVMMU can't be
selected by the user. It's automatically added per platform (for
instance see arch/x86/xen/Kconfig).

So maybe it should not even appear in the one of the fragment configs?

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 Dec 09 20:38:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 20: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 1XyRXe-00020j-Mc; Tue, 09 Dec 2014 20:37: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 1XyRXc-00020e-LK
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 20:37:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F3/0E-25276-0AD57845; Tue, 09 Dec 2014 20:37:52 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418157471!14501359!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5381 invoked from network); 9 Dec 2014 20:37:51 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 20:37:51 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so1889302wgg.28
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 12:37: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=ZiQSVcqIzqksfdAb1mfka8iMQ8XJnIYGxJQU93Ls7Os=;
	b=BvH1Ko4GDWwGpi+CtswKhCGLqtgWiUmGYBL652sMIjrx6RO91UZ9sskXE2AM+sVEAp
	Y5Urlm4wAspnuNibGI272ZEJOPjaEtugIAMW0cBE6BiU1Qv4knvt+W6HZQdi3NLZ0TFe
	zwcIw5B2dpwOi3eftdwzmQfBLNtTHfkp376NZ1sR8MxMx2xc1WGaXpCwr2TBUikpyOTe
	8cIP1zdZ1vp/vVYCq5FrdNWlLvFexu6TvS3YcFNk9VwmKNQlFQdZReb40K5NNvosA4E4
	retXZ9h+Gy6WIovAC0OHIqMEswt8vSuCaYEgTfCsR1vbcqO8+T74Twjec9vFZLB9S7iZ
	ws3Q==
X-Gm-Message-State: ALoCoQnLsrRDjnzU3bHfIJIsEWyiMu3Pmbh/Y22PamB4QQxvU+aNqTjXTylC1grU9X2mIkjxEnu0
X-Received: by 10.181.8.193 with SMTP id dm1mr371523wid.55.1418157471025;
	Tue, 09 Dec 2014 12:37:51 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	dm10sm15255828wib.18.2014.12.09.12.37.49 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 09 Dec 2014 12:37:50 -0800 (PST)
Message-ID: <54875D99.6070301@linaro.org>
Date: Tue, 09 Dec 2014 20:37:45 +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: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
	<1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
	<5486BBB1.3040405@linaro.org>
	<CAB=NE6V+kLaZePAzHim0VxGsd8ew6dS7kN=H=awwz1dpHy5VJw@mail.gmail.com>
In-Reply-To: <CAB=NE6V+kLaZePAzHim0VxGsd8ew6dS7kN=H=awwz1dpHy5VJw@mail.gmail.com>
Cc: Michal Marek <mmarek@suse.cz>, x86@kernel.org,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	Randy Dunlap <rdunlap@infradead.org>, josh@joshtriplett.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pekka Enberg <penberg@kernel.org>, mtosatti@redhat.com,
	Benjamin Poirier <bpoirier@suse.de>, Borislav Petkov <bp@suse.de>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	David Rientjes <rientjes@google.com>,
	Fengguang Wu <fengguang.wu@intel.com>, sam@ravnborg.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/12/14 20:22, Luis R. Rodriguez wrote:
> On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall <julien.grall@linaro.org> wrote:
>> Hello Luis,
>>
>> On 08/12/2014 23:05, Luis R. Rodriguez wrote:
>>>
>>> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
>>> new file mode 100644
>>> index 0000000..0d0eb6d
>>> --- /dev/null
>>> +++ b/kernel/configs/xen.config
>>> +CONFIG_XEN_MCE_LOG=y
>>
>>
>> MCE is x86 specific.
> 
> That's what I thought too but its available for arm64, so should we
> fix that Kconfig to depend on x86?

Are you sure? On the Linus's repo I have:

config XEN_MCE_LOG
        bool "Xen platform mcelog"
        depends on XEN_DOM0 && X86_64 && X86_MCE

Anyway, the MCE interface in the hypervisor is implemented in arch/x86
not in common code.

>>> +CONFIG_XEN_HAVE_PVMMU=y
>>
>>
>> We don't have PVMMU support on ARM. Shouldn't you move this config in
>> architecture specific code?
> 
> If you are sure then yes.

I'm 100% sure. MMU is handled by the hardware on ARM.

Thinking a bit more about this option. CONFIG_XEN_HAVE_PVMMU can't be
selected by the user. It's automatically added per platform (for
instance see arch/x86/xen/Kconfig).

So maybe it should not even appear in the one of the fragment configs?

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 Dec 09 20:55:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 20:55:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyRoF-0002yR-HO; Tue, 09 Dec 2014 20:55:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XyRoE-0002yK-2m
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 20:55:02 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	DE/FE-22737-5A167845; Tue, 09 Dec 2014 20:55:01 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418158499!12437553!1
X-Originating-IP: [156.151.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 11741 invoked from network); 9 Dec 2014 20:55:00 -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; 9 Dec 2014 20:55:00 -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 sB9KstjG003362
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Dec 2014 20:54:57 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
	sB9KssHR003563
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Dec 2014 20:54:55 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
	sB9KsrlI021578; Tue, 9 Dec 2014 20:54:54 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, 09 Dec 2014 12:54:53 -0800
Message-ID: <5487620E.8060807@oracle.com>
Date: Tue, 09 Dec 2014 15:56:46 -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: Vitaly Kuznetsov <vkuznets@redhat.com>
References: <54860EA4.7090705@oracle.com>
	<1418135110-7194-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418135110-7194-1-git-send-email-vkuznets@redhat.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org, Andrew Jones <drjones@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v2] xen/blkfront: remove redundant flush_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/09/2014 09:25 AM, Vitaly Kuznetsov wrote:
> flush_op is unambiguously defined by feature_flush:
>      REQ_FUA | REQ_FLUSH -> BLKIF_OP_WRITE_BARRIER
>      REQ_FLUSH -> BLKIF_OP_FLUSH_DISKCACHE
>      0 -> 0
> and thus can be removed. This is just a cleanup.
>
> The patch was suggested by Boris Ostrovsky.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


> ---
> Changes from v1:
>     Future-proof feature_flush against new flags [Boris Ostrovsky].
>
> The patch is supposed to be applied after "xen/blkfront: improve protection
> against issuing unsupported REQ_FUA".
> ---
>   drivers/block/xen-blkfront.c | 51 +++++++++++++++++++++++++++-----------------
>   1 file changed, 31 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2e6c103..2236c6f 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -126,7 +126,6 @@ struct blkfront_info
>   	unsigned int persistent_gnts_c;
>   	unsigned long shadow_free;
>   	unsigned int feature_flush;
> -	unsigned int flush_op;
>   	unsigned int feature_discard:1;
>   	unsigned int feature_secdiscard:1;
>   	unsigned int discard_granularity;
> @@ -479,7 +478,19 @@ static int blkif_queue_request(struct request *req)
>   				 * way.  (It's also a FLUSH+FUA, since it is
>   				 * guaranteed ordered WRT previous writes.)
>   				 */
> -				ring_req->operation = info->flush_op;
> +				switch (info->feature_flush &
> +					((REQ_FLUSH|REQ_FUA))) {
> +				case REQ_FLUSH|REQ_FUA:
> +					ring_req->operation =
> +						BLKIF_OP_WRITE_BARRIER;
> +					break;
> +				case REQ_FLUSH:
> +					ring_req->operation =
> +						BLKIF_OP_FLUSH_DISKCACHE;
> +					break;
> +				default:
> +					ring_req->operation = 0;
> +				}
>   			}
>   			ring_req->u.rw.nr_segments = nseg;
>   		}
> @@ -685,20 +696,26 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size,
>   	return 0;
>   }
>   
> +static const char *flush_info(unsigned int feature_flush)
> +{
> +	switch (feature_flush & ((REQ_FLUSH | REQ_FUA))) {
> +	case REQ_FLUSH|REQ_FUA:
> +		return "barrier: enabled;";
> +	case REQ_FLUSH:
> +		return "flush diskcache: enabled;";
> +	default:
> +		return "barrier or flush: disabled;";
> +	}
> +}
>   
>   static void xlvbd_flush(struct blkfront_info *info)
>   {
>   	blk_queue_flush(info->rq, info->feature_flush);
> -	printk(KERN_INFO "blkfront: %s: %s: %s %s %s %s %s\n",
> -	       info->gd->disk_name,
> -	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
> -		"flush diskcache" : "barrier or flush"),
> -	       info->feature_flush ? "enabled;" : "disabled;",
> -	       "persistent grants:",
> -	       info->feature_persistent ? "enabled;" : "disabled;",
> -	       "indirect descriptors:",
> -	       info->max_indirect_segments ? "enabled;" : "disabled;");
> +	pr_info("blkfront: %s: %s %s %s %s %s\n",
> +		info->gd->disk_name, flush_info(info->feature_flush),
> +		"persistent grants:", info->feature_persistent ?
> +		"enabled;" : "disabled;", "indirect descriptors:",
> +		info->max_indirect_segments ? "enabled;" : "disabled;");
>   }
>   
>   static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
> @@ -1190,7 +1207,6 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>   				if (error == -EOPNOTSUPP)
>   					error = 0;
>   				info->feature_flush = 0;
> -				info->flush_op = 0;
>   				xlvbd_flush(info);
>   			}
>   			/* fall through */
> @@ -1810,7 +1826,6 @@ static void blkfront_connect(struct blkfront_info *info)
>   		physical_sector_size = sector_size;
>   
>   	info->feature_flush = 0;
> -	info->flush_op = 0;
>   
>   	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
>   			    "feature-barrier", "%d", &barrier,
> @@ -1823,10 +1838,8 @@ static void blkfront_connect(struct blkfront_info *info)
>   	 *
>   	 * If there are barriers, then we use flush.
>   	 */
> -	if (!err && barrier) {
> +	if (!err && barrier)
>   		info->feature_flush = REQ_FLUSH | REQ_FUA;
> -		info->flush_op = BLKIF_OP_WRITE_BARRIER;
> -	}
>   	/*
>   	 * And if there is "feature-flush-cache" use that above
>   	 * barriers.
> @@ -1835,10 +1848,8 @@ static void blkfront_connect(struct blkfront_info *info)
>   			    "feature-flush-cache", "%d", &flush,
>   			    NULL);
>   
> -	if (!err && flush) {
> +	if (!err && flush)
>   		info->feature_flush = REQ_FLUSH;
> -		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
> -	}
>   
>   	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
>   			    "feature-discard", "%d", &discard,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 20:55:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 20:55:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyRoF-0002yR-HO; Tue, 09 Dec 2014 20:55:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1XyRoE-0002yK-2m
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 20:55:02 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	DE/FE-22737-5A167845; Tue, 09 Dec 2014 20:55:01 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418158499!12437553!1
X-Originating-IP: [156.151.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 11741 invoked from network); 9 Dec 2014 20:55:00 -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; 9 Dec 2014 20:55:00 -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 sB9KstjG003362
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Dec 2014 20:54:57 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
	sB9KssHR003563
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Dec 2014 20:54:55 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
	sB9KsrlI021578; Tue, 9 Dec 2014 20:54:54 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, 09 Dec 2014 12:54:53 -0800
Message-ID: <5487620E.8060807@oracle.com>
Date: Tue, 09 Dec 2014 15:56:46 -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: Vitaly Kuznetsov <vkuznets@redhat.com>
References: <54860EA4.7090705@oracle.com>
	<1418135110-7194-1-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418135110-7194-1-git-send-email-vkuznets@redhat.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org, Andrew Jones <drjones@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v2] xen/blkfront: remove redundant flush_op
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/09/2014 09:25 AM, Vitaly Kuznetsov wrote:
> flush_op is unambiguously defined by feature_flush:
>      REQ_FUA | REQ_FLUSH -> BLKIF_OP_WRITE_BARRIER
>      REQ_FLUSH -> BLKIF_OP_FLUSH_DISKCACHE
>      0 -> 0
> and thus can be removed. This is just a cleanup.
>
> The patch was suggested by Boris Ostrovsky.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


> ---
> Changes from v1:
>     Future-proof feature_flush against new flags [Boris Ostrovsky].
>
> The patch is supposed to be applied after "xen/blkfront: improve protection
> against issuing unsupported REQ_FUA".
> ---
>   drivers/block/xen-blkfront.c | 51 +++++++++++++++++++++++++++-----------------
>   1 file changed, 31 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2e6c103..2236c6f 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -126,7 +126,6 @@ struct blkfront_info
>   	unsigned int persistent_gnts_c;
>   	unsigned long shadow_free;
>   	unsigned int feature_flush;
> -	unsigned int flush_op;
>   	unsigned int feature_discard:1;
>   	unsigned int feature_secdiscard:1;
>   	unsigned int discard_granularity;
> @@ -479,7 +478,19 @@ static int blkif_queue_request(struct request *req)
>   				 * way.  (It's also a FLUSH+FUA, since it is
>   				 * guaranteed ordered WRT previous writes.)
>   				 */
> -				ring_req->operation = info->flush_op;
> +				switch (info->feature_flush &
> +					((REQ_FLUSH|REQ_FUA))) {
> +				case REQ_FLUSH|REQ_FUA:
> +					ring_req->operation =
> +						BLKIF_OP_WRITE_BARRIER;
> +					break;
> +				case REQ_FLUSH:
> +					ring_req->operation =
> +						BLKIF_OP_FLUSH_DISKCACHE;
> +					break;
> +				default:
> +					ring_req->operation = 0;
> +				}
>   			}
>   			ring_req->u.rw.nr_segments = nseg;
>   		}
> @@ -685,20 +696,26 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size,
>   	return 0;
>   }
>   
> +static const char *flush_info(unsigned int feature_flush)
> +{
> +	switch (feature_flush & ((REQ_FLUSH | REQ_FUA))) {
> +	case REQ_FLUSH|REQ_FUA:
> +		return "barrier: enabled;";
> +	case REQ_FLUSH:
> +		return "flush diskcache: enabled;";
> +	default:
> +		return "barrier or flush: disabled;";
> +	}
> +}
>   
>   static void xlvbd_flush(struct blkfront_info *info)
>   {
>   	blk_queue_flush(info->rq, info->feature_flush);
> -	printk(KERN_INFO "blkfront: %s: %s: %s %s %s %s %s\n",
> -	       info->gd->disk_name,
> -	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> -		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
> -		"flush diskcache" : "barrier or flush"),
> -	       info->feature_flush ? "enabled;" : "disabled;",
> -	       "persistent grants:",
> -	       info->feature_persistent ? "enabled;" : "disabled;",
> -	       "indirect descriptors:",
> -	       info->max_indirect_segments ? "enabled;" : "disabled;");
> +	pr_info("blkfront: %s: %s %s %s %s %s\n",
> +		info->gd->disk_name, flush_info(info->feature_flush),
> +		"persistent grants:", info->feature_persistent ?
> +		"enabled;" : "disabled;", "indirect descriptors:",
> +		info->max_indirect_segments ? "enabled;" : "disabled;");
>   }
>   
>   static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
> @@ -1190,7 +1207,6 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>   				if (error == -EOPNOTSUPP)
>   					error = 0;
>   				info->feature_flush = 0;
> -				info->flush_op = 0;
>   				xlvbd_flush(info);
>   			}
>   			/* fall through */
> @@ -1810,7 +1826,6 @@ static void blkfront_connect(struct blkfront_info *info)
>   		physical_sector_size = sector_size;
>   
>   	info->feature_flush = 0;
> -	info->flush_op = 0;
>   
>   	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
>   			    "feature-barrier", "%d", &barrier,
> @@ -1823,10 +1838,8 @@ static void blkfront_connect(struct blkfront_info *info)
>   	 *
>   	 * If there are barriers, then we use flush.
>   	 */
> -	if (!err && barrier) {
> +	if (!err && barrier)
>   		info->feature_flush = REQ_FLUSH | REQ_FUA;
> -		info->flush_op = BLKIF_OP_WRITE_BARRIER;
> -	}
>   	/*
>   	 * And if there is "feature-flush-cache" use that above
>   	 * barriers.
> @@ -1835,10 +1848,8 @@ static void blkfront_connect(struct blkfront_info *info)
>   			    "feature-flush-cache", "%d", &flush,
>   			    NULL);
>   
> -	if (!err && flush) {
> +	if (!err && flush)
>   		info->feature_flush = REQ_FLUSH;
> -		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
> -	}
>   
>   	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
>   			    "feature-discard", "%d", &discard,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 22:12:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 22: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 1XyT0g-0005NM-Tf; Tue, 09 Dec 2014 22:11: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 1XyT0f-0005NH-Tb
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 22:11:58 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	C6/FB-11581-DA377845; Tue, 09 Dec 2014 22:11:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418163114!12447602!1
X-Originating-IP: [66.165.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 18855 invoked from network); 9 Dec 2014 22:11:56 -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;
	9 Dec 2014 22:11:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,548,1413244800"; d="scan'208";a="202543252"
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.210.2; Tue, 9 Dec 2014 17:11: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 1XyT0b-0003nQ-LA;
	Tue, 09 Dec 2014 22:11:53 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyT0b-0007O2-FX;
	Tue, 09 Dec 2014 22:11:53 +0000
Date: Tue, 9 Dec 2014 22:11:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32180-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] 32180: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32180 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32180/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32137
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32137
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32137

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              8a408b869ce343f953a7ca564598985504b9aa7f
baseline version:
 libvirt              253319ced6e9e92992f59000e3810b7d3ab59750

------------------------------------------------------------
People who touched revisions under test:
  Christophe Fergeau <cfergeau@redhat.com>
  Eric Blake <eblake@redhat.com>
  Kyle DeFrancia <kdef@linux.vnet.ibm.com>
  Laine Stump <laine@laine.org>
  Martin Kletzander <mkletzan@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 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


Not pushing.

(No revision log; it would be 430 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 Dec 09 22:12:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 22: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 1XyT0g-0005NM-Tf; Tue, 09 Dec 2014 22:11: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 1XyT0f-0005NH-Tb
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 22:11:58 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	C6/FB-11581-DA377845; Tue, 09 Dec 2014 22:11:57 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418163114!12447602!1
X-Originating-IP: [66.165.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 18855 invoked from network); 9 Dec 2014 22:11:56 -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;
	9 Dec 2014 22:11:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,548,1413244800"; d="scan'208";a="202543252"
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.210.2; Tue, 9 Dec 2014 17:11: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 1XyT0b-0003nQ-LA;
	Tue, 09 Dec 2014 22:11:53 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyT0b-0007O2-FX;
	Tue, 09 Dec 2014 22:11:53 +0000
Date: Tue, 9 Dec 2014 22:11:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32180-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] 32180: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32180 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32180/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32137
 build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32137
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32137

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a

version targeted for testing:
 libvirt              8a408b869ce343f953a7ca564598985504b9aa7f
baseline version:
 libvirt              253319ced6e9e92992f59000e3810b7d3ab59750

------------------------------------------------------------
People who touched revisions under test:
  Christophe Fergeau <cfergeau@redhat.com>
  Eric Blake <eblake@redhat.com>
  Kyle DeFrancia <kdef@linux.vnet.ibm.com>
  Laine Stump <laine@laine.org>
  Martin Kletzander <mkletzan@redhat.com>
  Peter Krempa <pkrempa@redhat.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 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


Not pushing.

(No revision log; it would be 430 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 Dec 09 22:39:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 22: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 1XyTRJ-000626-J0; Tue, 09 Dec 2014 22:39:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1XyTRI-000621-Pv
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 22:39:28 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	94/5E-19763-02A77845; Tue, 09 Dec 2014 22:39:28 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418164766!12493511!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20713 invoked from network); 9 Dec 2014 22:39:26 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-7.tower-206.messagelabs.com with SMTP;
	9 Dec 2014 22:39:26 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 5399516410B;
	Tue,  9 Dec 2014 22:39:26 +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 6kn9I29Tcu84; Tue,  9 Dec 2014 22:39:14 +0000 (GMT)
Received: from [10.0.2.15] (82-68-241-78.dsl.in-addr.zen.co.uk [82.68.241.78])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 0F171161F9B;
	Tue,  9 Dec 2014 22:39:13 +0000 (GMT)
Message-ID: <54877A10.7080808@overnetdata.com>
Date: Tue, 09 Dec 2014 22:39:12 +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: Siegmann Joseph <jsiegman@luxotticaretail.com>
References: <E3A471111497714D953FBC6F551B7AA7B6BD43C9@USALMELXP004.LUXGROUP.NET>
In-Reply-To: <E3A471111497714D953FBC6F551B7AA7B6BD43C9@USALMELXP004.LUXGROUP.NET>
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: multipart/mixed; boundary="===============8605637865855182851=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8605637865855182851==
Content-Type: multipart/alternative;
 boundary="------------030009080104000509080505"

This is a multi-part message in MIME format.
--------------030009080104000509080505
Content-Type: text/plain; charset=windows-1252
Content-Length: 325
Content-Transfer-Encoding: quoted-printable

On 09/12/2014 22:30, Siegmann Joseph wrote:
>
> Would you mind sharing what it would take to correct this issue=85 is
> there a file I could just replace until a patch is released=3F
>
We simply applied David Vrabel's patch from 8/12/14 to a stock 3.17.3
kernel we were running in the DomU and it fixed the problem.

--------------030009080104000509080505
Content-Type: text/html; charset=windows-1252
Content-Length: 2207
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 09/12/2014 22:30, Siegmann Joseph
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:E3A471111497714D953FBC6F551B7AA7B6BD43C9@USALMELXP004.LUXGROUP.NET"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html;
        charset=3Dwindows-1252">
      <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
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]-->
      <div class=3D"WordSection1">
        <p class=3D"MsoNormal">Would you mind sharing what it would take
          to correct this issue=85 is there a file I could just replace
          until a patch is released=3F<o:p></o:p></p>
      </div>
    </blockquote>
    We simply applied David Vrabel's patch from 8/12/14 to a stock
    3.17.3 kernel we were running in the DomU and it fixed the problem.<br>
  </body>
</html>

--------------030009080104000509080505--


--===============8605637865855182851==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8605637865855182851==--


From xen-devel-bounces@lists.xen.org Tue Dec 09 22:39:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 22: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 1XyTRJ-000626-J0; Tue, 09 Dec 2014 22:39:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1XyTRI-000621-Pv
	for xen-devel@lists.xensource.com; Tue, 09 Dec 2014 22:39:28 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	94/5E-19763-02A77845; Tue, 09 Dec 2014 22:39:28 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418164766!12493511!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20713 invoked from network); 9 Dec 2014 22:39:26 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-7.tower-206.messagelabs.com with SMTP;
	9 Dec 2014 22:39:26 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id 5399516410B;
	Tue,  9 Dec 2014 22:39:26 +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 6kn9I29Tcu84; Tue,  9 Dec 2014 22:39:14 +0000 (GMT)
Received: from [10.0.2.15] (82-68-241-78.dsl.in-addr.zen.co.uk [82.68.241.78])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 0F171161F9B;
	Tue,  9 Dec 2014 22:39:13 +0000 (GMT)
Message-ID: <54877A10.7080808@overnetdata.com>
Date: Tue, 09 Dec 2014 22:39:12 +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: Siegmann Joseph <jsiegman@luxotticaretail.com>
References: <E3A471111497714D953FBC6F551B7AA7B6BD43C9@USALMELXP004.LUXGROUP.NET>
In-Reply-To: <E3A471111497714D953FBC6F551B7AA7B6BD43C9@USALMELXP004.LUXGROUP.NET>
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: multipart/mixed; boundary="===============8605637865855182851=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8605637865855182851==
Content-Type: multipart/alternative;
 boundary="------------030009080104000509080505"

This is a multi-part message in MIME format.
--------------030009080104000509080505
Content-Type: text/plain; charset=windows-1252
Content-Length: 325
Content-Transfer-Encoding: quoted-printable

On 09/12/2014 22:30, Siegmann Joseph wrote:
>
> Would you mind sharing what it would take to correct this issue=85 is
> there a file I could just replace until a patch is released=3F
>
We simply applied David Vrabel's patch from 8/12/14 to a stock 3.17.3
kernel we were running in the DomU and it fixed the problem.

--------------030009080104000509080505
Content-Type: text/html; charset=windows-1252
Content-Length: 2207
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 09/12/2014 22:30, Siegmann Joseph
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:E3A471111497714D953FBC6F551B7AA7B6BD43C9@USALMELXP004.LUXGROUP.NET"
      type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html;
        charset=3Dwindows-1252">
      <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
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]-->
      <div class=3D"WordSection1">
        <p class=3D"MsoNormal">Would you mind sharing what it would take
          to correct this issue=85 is there a file I could just replace
          until a patch is released=3F<o:p></o:p></p>
      </div>
    </blockquote>
    We simply applied David Vrabel's patch from 8/12/14 to a stock
    3.17.3 kernel we were running in the DomU and it fixed the problem.<br>
  </body>
</html>

--------------030009080104000509080505--


--===============8605637865855182851==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8605637865855182851==--


From xen-devel-bounces@lists.xen.org Tue Dec 09 23:28:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 23:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyUBg-0007kq-6N; Tue, 09 Dec 2014 23:27:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1XyUBf-0007kl-Ct
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 23:27:23 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	38/CB-09284-A5587845; Tue, 09 Dec 2014 23:27:22 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418167641!12194551!1
X-Originating-IP: [209.85.217.176]
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 1950 invoked from network); 9 Dec 2014 23:27:21 -0000
Received: from mail-lb0-f176.google.com (HELO mail-lb0-f176.google.com)
	(209.85.217.176)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 23:27:21 -0000
Received: by mail-lb0-f176.google.com with SMTP id p9so1391522lbv.7
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 15:27:20 -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=wjgNHP/ekB874qZvjp00L9871QNvJ2QjGl3emU0silw=;
	b=OK1HaMGI/lkfKEBAzTQtCL08LZSZAKbWBgNYcFiYQQ2tVDTDo4V43CUuSaJG5rC+da
	08O3KT4JOAVOuP/kPH0GPmHiFI5HiimJEotKfnrXxPCSBt9nKiGlvNWUWnb1eAfTzXLv
	XSzZuILcCffOIOmupjOdGazk/9MGrKhWOkLdx5+vylHtwR24JQ7QIhTEnRFHND2A9x/6
	FjOZRwy84tJCM6tDgxmdOqmiLAJIw4Ug6Pmg1dlvk+2r4xCoqc3kOgVUPKMADRATWBdM
	aRl4UoEh9CGf3kgtowhuZthPNXYUdQPIAGQBlXFQId6LlSh/EdEZYBcA+wvy2bLNApqJ
	0Juw==
X-Received: by 10.112.64.10 with SMTP id k10mr977246lbs.72.1418167640663; Tue,
	09 Dec 2014 15:27:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.203.232 with HTTP; Tue, 9 Dec 2014 15:27:00 -0800 (PST)
In-Reply-To: <54875D99.6070301@linaro.org>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
	<1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
	<5486BBB1.3040405@linaro.org>
	<CAB=NE6V+kLaZePAzHim0VxGsd8ew6dS7kN=H=awwz1dpHy5VJw@mail.gmail.com>
	<54875D99.6070301@linaro.org>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Date: Tue, 9 Dec 2014 15:27:00 -0800
X-Google-Sender-Auth: UbsU3D83yuLv8vbBt1BeOH27czw
Message-ID: <CAB=NE6UCQXzUVU2tpZxiYXEp+77rtsfhFpLFKvb8371iK8FJBA@mail.gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Michal Marek <mmarek@suse.cz>, x86@kernel.org,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	Randy Dunlap <rdunlap@infradead.org>, josh@joshtriplett.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pekka Enberg <penberg@kernel.org>, mtosatti@redhat.com,
	Benjamin Poirier <bpoirier@suse.de>, Borislav Petkov <bp@suse.de>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	David Rientjes <rientjes@google.com>,
	Fengguang Wu <fengguang.wu@intel.com>, sam@ravnborg.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 9, 2014 at 12:37 PM, Julien Grall <julien.grall@linaro.org> wrote:
> On 09/12/14 20:22, Luis R. Rodriguez wrote:
>> On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall <julien.grall@linaro.org> wrote:
>>> Hello Luis,
>>>
>>> On 08/12/2014 23:05, Luis R. Rodriguez wrote:
>>>>
>>>> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
>>>> new file mode 100644
>>>> index 0000000..0d0eb6d
>>>> --- /dev/null
>>>> +++ b/kernel/configs/xen.config
>>>> +CONFIG_XEN_MCE_LOG=y
>>>
>>>
>>> MCE is x86 specific.
>>
>> That's what I thought too but its available for arm64, so should we
>> fix that Kconfig to depend on x86?
>
> Are you sure? On the Linus's repo I have:
>
> config XEN_MCE_LOG
>         bool "Xen platform mcelog"
>         depends on XEN_DOM0 && X86_64 && X86_MCE
>
> Anyway, the MCE interface in the hypervisor is implemented in arch/x86
> not in common code.

OK I'll move to x86.

>>>> +CONFIG_XEN_HAVE_PVMMU=y
>>>
>>>
>>> We don't have PVMMU support on ARM. Shouldn't you move this config in
>>> architecture specific code?
>>
>> If you are sure then yes.
>
> I'm 100% sure. MMU is handled by the hardware on ARM.
>
> Thinking a bit more about this option. CONFIG_XEN_HAVE_PVMMU can't be
> selected by the user. It's automatically added per platform (for
> instance see arch/x86/xen/Kconfig).
>
> So maybe it should not even appear in the one of the fragment configs?

And I'll remove this one.

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 23:28:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 23:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyUBg-0007kq-6N; Tue, 09 Dec 2014 23:27:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1XyUBf-0007kl-Ct
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 23:27:23 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	38/CB-09284-A5587845; Tue, 09 Dec 2014 23:27:22 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418167641!12194551!1
X-Originating-IP: [209.85.217.176]
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 1950 invoked from network); 9 Dec 2014 23:27:21 -0000
Received: from mail-lb0-f176.google.com (HELO mail-lb0-f176.google.com)
	(209.85.217.176)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 23:27:21 -0000
Received: by mail-lb0-f176.google.com with SMTP id p9so1391522lbv.7
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 15:27:20 -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=wjgNHP/ekB874qZvjp00L9871QNvJ2QjGl3emU0silw=;
	b=OK1HaMGI/lkfKEBAzTQtCL08LZSZAKbWBgNYcFiYQQ2tVDTDo4V43CUuSaJG5rC+da
	08O3KT4JOAVOuP/kPH0GPmHiFI5HiimJEotKfnrXxPCSBt9nKiGlvNWUWnb1eAfTzXLv
	XSzZuILcCffOIOmupjOdGazk/9MGrKhWOkLdx5+vylHtwR24JQ7QIhTEnRFHND2A9x/6
	FjOZRwy84tJCM6tDgxmdOqmiLAJIw4Ug6Pmg1dlvk+2r4xCoqc3kOgVUPKMADRATWBdM
	aRl4UoEh9CGf3kgtowhuZthPNXYUdQPIAGQBlXFQId6LlSh/EdEZYBcA+wvy2bLNApqJ
	0Juw==
X-Received: by 10.112.64.10 with SMTP id k10mr977246lbs.72.1418167640663; Tue,
	09 Dec 2014 15:27:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.203.232 with HTTP; Tue, 9 Dec 2014 15:27:00 -0800 (PST)
In-Reply-To: <54875D99.6070301@linaro.org>
References: <1418079900-4640-1-git-send-email-mcgrof@do-not-panic.com>
	<1418079900-4640-3-git-send-email-mcgrof@do-not-panic.com>
	<5486BBB1.3040405@linaro.org>
	<CAB=NE6V+kLaZePAzHim0VxGsd8ew6dS7kN=H=awwz1dpHy5VJw@mail.gmail.com>
	<54875D99.6070301@linaro.org>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Date: Tue, 9 Dec 2014 15:27:00 -0800
X-Google-Sender-Auth: UbsU3D83yuLv8vbBt1BeOH27czw
Message-ID: <CAB=NE6UCQXzUVU2tpZxiYXEp+77rtsfhFpLFKvb8371iK8FJBA@mail.gmail.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Michal Marek <mmarek@suse.cz>, x86@kernel.org,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	Randy Dunlap <rdunlap@infradead.org>, josh@joshtriplett.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pekka Enberg <penberg@kernel.org>, mtosatti@redhat.com,
	Benjamin Poirier <bpoirier@suse.de>, Borislav Petkov <bp@suse.de>,
	Sasha Levin <levinsasha928@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>,
	David Rientjes <rientjes@google.com>,
	Fengguang Wu <fengguang.wu@intel.com>, sam@ravnborg.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 9, 2014 at 12:37 PM, Julien Grall <julien.grall@linaro.org> wrote:
> On 09/12/14 20:22, Luis R. Rodriguez wrote:
>> On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall <julien.grall@linaro.org> wrote:
>>> Hello Luis,
>>>
>>> On 08/12/2014 23:05, Luis R. Rodriguez wrote:
>>>>
>>>> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
>>>> new file mode 100644
>>>> index 0000000..0d0eb6d
>>>> --- /dev/null
>>>> +++ b/kernel/configs/xen.config
>>>> +CONFIG_XEN_MCE_LOG=y
>>>
>>>
>>> MCE is x86 specific.
>>
>> That's what I thought too but its available for arm64, so should we
>> fix that Kconfig to depend on x86?
>
> Are you sure? On the Linus's repo I have:
>
> config XEN_MCE_LOG
>         bool "Xen platform mcelog"
>         depends on XEN_DOM0 && X86_64 && X86_MCE
>
> Anyway, the MCE interface in the hypervisor is implemented in arch/x86
> not in common code.

OK I'll move to x86.

>>>> +CONFIG_XEN_HAVE_PVMMU=y
>>>
>>>
>>> We don't have PVMMU support on ARM. Shouldn't you move this config in
>>> architecture specific code?
>>
>> If you are sure then yes.
>
> I'm 100% sure. MMU is handled by the hardware on ARM.
>
> Thinking a bit more about this option. CONFIG_XEN_HAVE_PVMMU can't be
> selected by the user. It's automatically added per platform (for
> instance see arch/x86/xen/Kconfig).
>
> So maybe it should not even appear in the one of the fragment configs?

And I'll remove this one.

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 23:30:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 23: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 1XyUEf-0007qo-Pn; Tue, 09 Dec 2014 23:30:29 +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 1XyUEe-0007qj-Ow
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 23:30:28 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	99/93-22819-41687845; Tue, 09 Dec 2014 23:30:28 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418167827!12497283!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28708 invoked from network); 9 Dec 2014 23:30:27 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-7.tower-206.messagelabs.com with SMTP;
	9 Dec 2014 23:30:27 -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 1C64D5838F1;
	Tue,  9 Dec 2014 15:30:26 -0800 (PST)
Date: Tue, 09 Dec 2014 18:30:25 -0500 (EST)
Message-Id: <20141209.183025.2098328465942240354.davem@davemloft.net>
To: JBeulich@suse.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <5486EF48020000780004E1B8@mail.emea.novell.com>
References: <5486EF48020000780004E1B8@mail.emea.novell.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]);
	Tue, 09 Dec 2014 15:30:26 -0800 (PST)
Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xenproject.org,
	wei.liu2@citrix.com, netdev@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] netback: don't store invalid vif 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

From: "Jan Beulich" <JBeulich@suse.com>
Date: Tue, 09 Dec 2014 11:47:04 +0000

> When xenvif_alloc() fails, it returns a non-NULL error indicator. To
> avoid eventual races, we shouldn't store that into struct backend_info
> as readers of it only check for NULL.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Applied, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 23:30:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 23: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 1XyUEf-0007qo-Pn; Tue, 09 Dec 2014 23:30:29 +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 1XyUEe-0007qj-Ow
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 23:30:28 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	99/93-22819-41687845; Tue, 09 Dec 2014 23:30:28 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418167827!12497283!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28708 invoked from network); 9 Dec 2014 23:30:27 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-7.tower-206.messagelabs.com with SMTP;
	9 Dec 2014 23:30:27 -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 1C64D5838F1;
	Tue,  9 Dec 2014 15:30:26 -0800 (PST)
Date: Tue, 09 Dec 2014 18:30:25 -0500 (EST)
Message-Id: <20141209.183025.2098328465942240354.davem@davemloft.net>
To: JBeulich@suse.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <5486EF48020000780004E1B8@mail.emea.novell.com>
References: <5486EF48020000780004E1B8@mail.emea.novell.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]);
	Tue, 09 Dec 2014 15:30:26 -0800 (PST)
Cc: Ian.Campbell@eu.citrix.com, xen-devel@lists.xenproject.org,
	wei.liu2@citrix.com, netdev@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] netback: don't store invalid vif 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

From: "Jan Beulich" <JBeulich@suse.com>
Date: Tue, 09 Dec 2014 11:47:04 +0000

> When xenvif_alloc() fails, it returns a non-NULL error indicator. To
> avoid eventual races, we shouldn't store that into struct backend_info
> as readers of it only check for NULL.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Applied, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 09 23:36:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 23:36:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyUJt-0008Gv-IA; Tue, 09 Dec 2014 23:35:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1XyUJs-0008Gq-7A
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 23:35:52 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	F6/3E-07724-75787845; Tue, 09 Dec 2014 23:35:51 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418168149!7754493!1
X-Originating-IP: [209.85.192.174]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26359 invoked from network); 9 Dec 2014 23:35:50 -0000
Received: from mail-pd0-f174.google.com (HELO mail-pd0-f174.google.com)
	(209.85.192.174)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 23:35:50 -0000
Received: by mail-pd0-f174.google.com with SMTP id fp1so1516816pdb.5
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 15:35:48 -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:in-reply-to:references;
	bh=L7wykJ3qYwUtqToE+NhW3i7jfRFOa28MKFVgNGRsa/Q=;
	b=n3YfmU7IttnpdIGmdEcbsv5MLtu71ThZCHJEOspIFfgR/LERQv5tPCRCaXNlKbymNJ
	EViMHw9jTiIrVKcBlTEDqq499VLhyqK6Akt7opSm/GzBkSagS8Tw3jPRmsERTdlLYvqs
	beWPEn6aieTFns1fVlSnXRS5IMMT9sI2lTSdgJ7Uqg2Jjtk6RJb+0qepj8+bKn/f09zo
	6R1hFQ5IyQSF+/8AcYIYcU8UTJfVB7FVpMUpdWFAivdVUUPi4Vw6hug6/lci8haou0RZ
	rgZkT697i0HW9g+NQ2BM3WKbkmfjMeiApjYJvuPRxMh8QWK84bsotFkeMmt1M8OUgj3y
	a6qg==
X-Received: by 10.67.4.65 with SMTP id cc1mr1466372pad.87.1418168148837;
	Tue, 09 Dec 2014 15:35:48 -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 v8sm2391184pdp.94.2014.12.09.15.35.45
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 09 Dec 2014 15:35:47 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Tue, 09 Dec 2014 15:35:44 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: hpa@zytor.com,
	josh@joshtriplett.org,
	sam@ravnborg.org
Date: Tue,  9 Dec 2014 15:35:37 -0800
Message-Id: <1418168138-6425-2-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
References: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, fengguang.wu@intel.com,
	levinsasha928@gmail.com, David Rientjes <rientjes@google.com>,
	xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>,
	David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v2 1/2] x86, platform, xen,
	kconfig: clarify kvmconfig is for kvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

We'll be adding options for xen as well.

Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: penberg@kernel.org
Cc: levinsasha928@gmail.com
Cc: mtosatti@redhat.com
Cc: fengguang.wu@intel.com
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 scripts/kconfig/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 9645c07..ff612b0 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -141,7 +141,7 @@ help:
 	@echo  '  randconfig	  - New config with random answer to all options'
 	@echo  '  listnewconfig   - List new options'
 	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
-	@echo  '  kvmconfig	  - Enable additional options for guest kernel support'
+	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
 	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
 
 # lxdialog stuff
-- 
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 Tue Dec 09 23:36:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 23:36:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyUJy-0008IG-Hu; Tue, 09 Dec 2014 23:35:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1XyUJx-0008HW-4k
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 23:35:57 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	B7/2E-02576-C5787845; Tue, 09 Dec 2014 23:35:56 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418168154!14052783!1
X-Originating-IP: [209.85.220.54]
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 3927 invoked from network); 9 Dec 2014 23:35:55 -0000
Received: from mail-pa0-f54.google.com (HELO mail-pa0-f54.google.com)
	(209.85.220.54)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 23:35:55 -0000
Received: by mail-pa0-f54.google.com with SMTP id fb1so1549009pad.13
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 15:35:54 -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=9K2gDImKUVNTurrlFRfaZK/11I3AbbtfwnnQwZ464uY=;
	b=o9Rz8myOY6VOsHeUTgDtKqgLsX8GOHtzOAh51WlFz0kXX2+ZNUvGqZNuEWcbGkH8cl
	IAavsbaICbOpiqL1cyLMLfUgby6SM8a45W13wj/vidQyyuRaSQA2ou1pRQ1UjT9+lFkz
	tjv8EI15k0Qne0waxZpgoDsFMUrhi34a2rwG7rciw6iPJWW9Polblc85bP7vsSIFoJ4F
	KUaqEauakDsB1xiNBnhal4sT4ys9QnsAI6e399McXzo3kTallGo3eYSAY6SSXVWG2pL/
	O3hgNPum6p2m4pgdPtZ3Z+d8w6prZP7bTQlLegNfnil674Ce7odIQD2hilkUE98YLm/g
	kmOg==
X-Received: by 10.67.24.99 with SMTP id ih3mr1417822pad.101.1418168143900;
	Tue, 09 Dec 2014 15:35:43 -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 vy1sm2472402pac.20.2014.12.09.15.35.40
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 09 Dec 2014 15:35:42 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Tue, 09 Dec 2014 15:35:39 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: hpa@zytor.com,
	josh@joshtriplett.org,
	sam@ravnborg.org
Date: Tue,  9 Dec 2014 15:35:36 -0800
Message-Id: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
Cc: kvm@vger.kernel.org, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	bpoirier@suse.de
Subject: [Xen-devel] [PATCH v2 0/2] x86/arm64: add xenconfig
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

This v2 addreses some minor feedback on patch 2, and just
mends in the review tags.

Luis R. Rodriguez (2):
  x86, platform, xen, kconfig: clarify kvmconfig is for kvm
  x86, arm, platform, xen, kconfig: add xen defconfig helper

 arch/x86/configs/xen.config |  7 +++++++
 kernel/configs/xen.config   | 30 ++++++++++++++++++++++++++++++
 scripts/kconfig/Makefile    |  7 ++++++-
 3 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/configs/xen.config
 create mode 100644 kernel/configs/xen.config

-- 
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 Tue Dec 09 23:36:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 23:36:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyUJy-0008IG-Hu; Tue, 09 Dec 2014 23:35:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1XyUJx-0008HW-4k
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 23:35:57 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	B7/2E-02576-C5787845; Tue, 09 Dec 2014 23:35:56 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418168154!14052783!1
X-Originating-IP: [209.85.220.54]
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 3927 invoked from network); 9 Dec 2014 23:35:55 -0000
Received: from mail-pa0-f54.google.com (HELO mail-pa0-f54.google.com)
	(209.85.220.54)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 23:35:55 -0000
Received: by mail-pa0-f54.google.com with SMTP id fb1so1549009pad.13
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 15:35:54 -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=9K2gDImKUVNTurrlFRfaZK/11I3AbbtfwnnQwZ464uY=;
	b=o9Rz8myOY6VOsHeUTgDtKqgLsX8GOHtzOAh51WlFz0kXX2+ZNUvGqZNuEWcbGkH8cl
	IAavsbaICbOpiqL1cyLMLfUgby6SM8a45W13wj/vidQyyuRaSQA2ou1pRQ1UjT9+lFkz
	tjv8EI15k0Qne0waxZpgoDsFMUrhi34a2rwG7rciw6iPJWW9Polblc85bP7vsSIFoJ4F
	KUaqEauakDsB1xiNBnhal4sT4ys9QnsAI6e399McXzo3kTallGo3eYSAY6SSXVWG2pL/
	O3hgNPum6p2m4pgdPtZ3Z+d8w6prZP7bTQlLegNfnil674Ce7odIQD2hilkUE98YLm/g
	kmOg==
X-Received: by 10.67.24.99 with SMTP id ih3mr1417822pad.101.1418168143900;
	Tue, 09 Dec 2014 15:35:43 -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 vy1sm2472402pac.20.2014.12.09.15.35.40
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 09 Dec 2014 15:35:42 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Tue, 09 Dec 2014 15:35:39 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: hpa@zytor.com,
	josh@joshtriplett.org,
	sam@ravnborg.org
Date: Tue,  9 Dec 2014 15:35:36 -0800
Message-Id: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
Cc: kvm@vger.kernel.org, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	bpoirier@suse.de
Subject: [Xen-devel] [PATCH v2 0/2] x86/arm64: add xenconfig
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

This v2 addreses some minor feedback on patch 2, and just
mends in the review tags.

Luis R. Rodriguez (2):
  x86, platform, xen, kconfig: clarify kvmconfig is for kvm
  x86, arm, platform, xen, kconfig: add xen defconfig helper

 arch/x86/configs/xen.config |  7 +++++++
 kernel/configs/xen.config   | 30 ++++++++++++++++++++++++++++++
 scripts/kconfig/Makefile    |  7 ++++++-
 3 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/configs/xen.config
 create mode 100644 kernel/configs/xen.config

-- 
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 Tue Dec 09 23:36:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 23:36:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyUJy-0008Hu-3q; Tue, 09 Dec 2014 23:35: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 1XyUJw-0008HS-LV
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 23:35:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AE/8E-15461-C5787845; Tue, 09 Dec 2014 23:35:56 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418168154!14179445!1
X-Originating-IP: [209.85.220.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1188 invoked from network); 9 Dec 2014 23:35:55 -0000
Received: from mail-pa0-f42.google.com (HELO mail-pa0-f42.google.com)
	(209.85.220.42)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 23:35:55 -0000
Received: by mail-pa0-f42.google.com with SMTP id et14so1537713pad.29
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 15:35:53 -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:in-reply-to:references;
	bh=swYojo2O+xCU3QeUdre9fKoDoNtN66YDB4WV1AucF2Y=;
	b=OTF2rAVHbkgDgCKs3m21ReW6H7lA4/n2MxtSsK9sbAUorjNWApJSLdCyf/kh008C0H
	+KqPJniR0J0sgleHyA8JDkme7KSPYNcU0zxc/mXz4l7IFO1xuGWJ/UMri7HvkNV5IZCZ
	dabVbhoplaKImilNpXmH54tBJRZadZMthttFXmpxYqGhtm773Zz8lIm5hoAoNcIeuk3M
	naW6REQCif5g/5ba5/lpeVO61LmcUCXQMGHA7DOsQzFN+1zcuq6cvL7kP+s0BMutnSGS
	TQTdSXgzAoJW4h8fOhN9xOyPE/bwo547/l2YYWv/0mQMjn92Lo7T2ekQ1FwfToMkhCl6
	V+0A==
X-Received: by 10.68.132.105 with SMTP id ot9mr1554408pbb.45.1418168153727;
	Tue, 09 Dec 2014 15:35:53 -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 fb3sm2392354pbc.82.2014.12.09.15.35.49
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 09 Dec 2014 15:35:52 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Tue, 09 Dec 2014 15:35:48 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: hpa@zytor.com,
	josh@joshtriplett.org,
	sam@ravnborg.org
Date: Tue,  9 Dec 2014 15:35:38 -0800
Message-Id: <1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
References: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, fengguang.wu@intel.com,
	levinsasha928@gmail.com, David Rientjes <rientjes@google.com>,
	xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>,
	David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v2 2/2] x86, arm, platform, xen,
	kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

This lets you build a kernel which can support xen dom0
or xen guests by just using:

   make xenconfig

on both x86 and arm64 kernels. This also splits out the
options which are available currently to be built with x86
and 'make ARCH=arm64' under a shared config.

Technically xen supports a dom0 kernel and also a guest
kernel configuration but upon review with the xen team
since we don't have many dom0 options its best to just
combine these two into one.

Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: penberg@kernel.org
Cc: levinsasha928@gmail.com
Cc: mtosatti@redhat.com
Cc: fengguang.wu@intel.com
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 arch/x86/configs/xen.config |  7 +++++++
 kernel/configs/xen.config   | 30 ++++++++++++++++++++++++++++++
 scripts/kconfig/Makefile    |  5 +++++
 3 files changed, 42 insertions(+)
 create mode 100644 arch/x86/configs/xen.config
 create mode 100644 kernel/configs/xen.config

diff --git a/arch/x86/configs/xen.config b/arch/x86/configs/xen.config
new file mode 100644
index 0000000..92b8587f
--- /dev/null
+++ b/arch/x86/configs/xen.config
@@ -0,0 +1,7 @@
+# x86 xen specific config options
+CONFIG_XEN_PVHVM=y
+CONFIG_XEN_MAX_DOMAIN_MEMORY=500
+CONFIG_XEN_SAVE_RESTORE=y
+# CONFIG_XEN_DEBUG_FS is not set
+CONFIG_XEN_PVH=y
+CONFIG_XEN_MCE_LOG=y
diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
new file mode 100644
index 0000000..d2ec010
--- /dev/null
+++ b/kernel/configs/xen.config
@@ -0,0 +1,30 @@
+# generic config
+CONFIG_XEN=y
+CONFIG_XEN_DOM0=y
+CONFIG_PCI_XEN=y
+CONFIG_XEN_PCIDEV_FRONTEND=m
+CONFIG_XEN_BLKDEV_FRONTEND=m
+CONFIG_XEN_BLKDEV_BACKEND=m
+CONFIG_XEN_NETDEV_FRONTEND=m
+CONFIG_XEN_NETDEV_BACKEND=m
+CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
+CONFIG_HVC_XEN=y
+CONFIG_HVC_XEN_FRONTEND=y
+CONFIG_TCG_XEN=m
+CONFIG_XEN_WDT=m
+CONFIG_XEN_FBDEV_FRONTEND=y
+CONFIG_XEN_BALLOON=y
+CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
+CONFIG_XEN_SCRUB_PAGES=y
+CONFIG_XEN_DEV_EVTCHN=m
+CONFIG_XEN_BACKEND=y
+CONFIG_XENFS=m
+CONFIG_XEN_COMPAT_XENFS=y
+CONFIG_XEN_SYS_HYPERVISOR=y
+CONFIG_XEN_XENBUS_FRONTEND=y
+CONFIG_XEN_GNTDEV=m
+CONFIG_XEN_GRANT_DEV_ALLOC=m
+CONFIG_SWIOTLB_XEN=y
+CONFIG_XEN_PCIDEV_BACKEND=m
+CONFIG_XEN_PRIVCMD=m
+CONFIG_XEN_ACPI_PROCESSOR=m
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index ff612b0..f4a8f89 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -117,6 +117,10 @@ PHONY += kvmconfig
 kvmconfig:
 	$(call mergeconfig,kvm_guest)
 
+PHONY += xenconfig
+xenconfig:
+	$(call mergeconfig,xen)
+
 PHONY += tinyconfig
 tinyconfig: allnoconfig
 	$(call mergeconfig,tiny)
@@ -142,6 +146,7 @@ help:
 	@echo  '  listnewconfig   - List new options'
 	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
 	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
+	@echo  '  xenconfig       - Enable additional options for xen dom0 and guest kernel support'
 	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
 
 # lxdialog stuff
-- 
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 Tue Dec 09 23:36:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 23:36:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyUJt-0008Gv-IA; Tue, 09 Dec 2014 23:35:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1XyUJs-0008Gq-7A
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 23:35:52 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	F6/3E-07724-75787845; Tue, 09 Dec 2014 23:35:51 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418168149!7754493!1
X-Originating-IP: [209.85.192.174]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26359 invoked from network); 9 Dec 2014 23:35:50 -0000
Received: from mail-pd0-f174.google.com (HELO mail-pd0-f174.google.com)
	(209.85.192.174)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 23:35:50 -0000
Received: by mail-pd0-f174.google.com with SMTP id fp1so1516816pdb.5
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 15:35:48 -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:in-reply-to:references;
	bh=L7wykJ3qYwUtqToE+NhW3i7jfRFOa28MKFVgNGRsa/Q=;
	b=n3YfmU7IttnpdIGmdEcbsv5MLtu71ThZCHJEOspIFfgR/LERQv5tPCRCaXNlKbymNJ
	EViMHw9jTiIrVKcBlTEDqq499VLhyqK6Akt7opSm/GzBkSagS8Tw3jPRmsERTdlLYvqs
	beWPEn6aieTFns1fVlSnXRS5IMMT9sI2lTSdgJ7Uqg2Jjtk6RJb+0qepj8+bKn/f09zo
	6R1hFQ5IyQSF+/8AcYIYcU8UTJfVB7FVpMUpdWFAivdVUUPi4Vw6hug6/lci8haou0RZ
	rgZkT697i0HW9g+NQ2BM3WKbkmfjMeiApjYJvuPRxMh8QWK84bsotFkeMmt1M8OUgj3y
	a6qg==
X-Received: by 10.67.4.65 with SMTP id cc1mr1466372pad.87.1418168148837;
	Tue, 09 Dec 2014 15:35:48 -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 v8sm2391184pdp.94.2014.12.09.15.35.45
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 09 Dec 2014 15:35:47 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Tue, 09 Dec 2014 15:35:44 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: hpa@zytor.com,
	josh@joshtriplett.org,
	sam@ravnborg.org
Date: Tue,  9 Dec 2014 15:35:37 -0800
Message-Id: <1418168138-6425-2-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
References: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, fengguang.wu@intel.com,
	levinsasha928@gmail.com, David Rientjes <rientjes@google.com>,
	xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>,
	David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v2 1/2] x86, platform, xen,
	kconfig: clarify kvmconfig is for kvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

We'll be adding options for xen as well.

Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: penberg@kernel.org
Cc: levinsasha928@gmail.com
Cc: mtosatti@redhat.com
Cc: fengguang.wu@intel.com
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 scripts/kconfig/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 9645c07..ff612b0 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -141,7 +141,7 @@ help:
 	@echo  '  randconfig	  - New config with random answer to all options'
 	@echo  '  listnewconfig   - List new options'
 	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
-	@echo  '  kvmconfig	  - Enable additional options for guest kernel support'
+	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
 	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
 
 # lxdialog stuff
-- 
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 Tue Dec 09 23:36:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Dec 2014 23:36:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyUJy-0008Hu-3q; Tue, 09 Dec 2014 23:35: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 1XyUJw-0008HS-LV
	for xen-devel@lists.xenproject.org; Tue, 09 Dec 2014 23:35:56 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AE/8E-15461-C5787845; Tue, 09 Dec 2014 23:35:56 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418168154!14179445!1
X-Originating-IP: [209.85.220.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1188 invoked from network); 9 Dec 2014 23:35:55 -0000
Received: from mail-pa0-f42.google.com (HELO mail-pa0-f42.google.com)
	(209.85.220.42)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Dec 2014 23:35:55 -0000
Received: by mail-pa0-f42.google.com with SMTP id et14so1537713pad.29
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 15:35:53 -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:in-reply-to:references;
	bh=swYojo2O+xCU3QeUdre9fKoDoNtN66YDB4WV1AucF2Y=;
	b=OTF2rAVHbkgDgCKs3m21ReW6H7lA4/n2MxtSsK9sbAUorjNWApJSLdCyf/kh008C0H
	+KqPJniR0J0sgleHyA8JDkme7KSPYNcU0zxc/mXz4l7IFO1xuGWJ/UMri7HvkNV5IZCZ
	dabVbhoplaKImilNpXmH54tBJRZadZMthttFXmpxYqGhtm773Zz8lIm5hoAoNcIeuk3M
	naW6REQCif5g/5ba5/lpeVO61LmcUCXQMGHA7DOsQzFN+1zcuq6cvL7kP+s0BMutnSGS
	TQTdSXgzAoJW4h8fOhN9xOyPE/bwo547/l2YYWv/0mQMjn92Lo7T2ekQ1FwfToMkhCl6
	V+0A==
X-Received: by 10.68.132.105 with SMTP id ot9mr1554408pbb.45.1418168153727;
	Tue, 09 Dec 2014 15:35:53 -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 fb3sm2392354pbc.82.2014.12.09.15.35.49
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 09 Dec 2014 15:35:52 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Tue, 09 Dec 2014 15:35:48 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: hpa@zytor.com,
	josh@joshtriplett.org,
	sam@ravnborg.org
Date: Tue,  9 Dec 2014 15:35:38 -0800
Message-Id: <1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
References: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, fengguang.wu@intel.com,
	levinsasha928@gmail.com, David Rientjes <rientjes@google.com>,
	xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>,
	David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v2 2/2] x86, arm, platform, xen,
	kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

This lets you build a kernel which can support xen dom0
or xen guests by just using:

   make xenconfig

on both x86 and arm64 kernels. This also splits out the
options which are available currently to be built with x86
and 'make ARCH=arm64' under a shared config.

Technically xen supports a dom0 kernel and also a guest
kernel configuration but upon review with the xen team
since we don't have many dom0 options its best to just
combine these two into one.

Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: penberg@kernel.org
Cc: levinsasha928@gmail.com
Cc: mtosatti@redhat.com
Cc: fengguang.wu@intel.com
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 arch/x86/configs/xen.config |  7 +++++++
 kernel/configs/xen.config   | 30 ++++++++++++++++++++++++++++++
 scripts/kconfig/Makefile    |  5 +++++
 3 files changed, 42 insertions(+)
 create mode 100644 arch/x86/configs/xen.config
 create mode 100644 kernel/configs/xen.config

diff --git a/arch/x86/configs/xen.config b/arch/x86/configs/xen.config
new file mode 100644
index 0000000..92b8587f
--- /dev/null
+++ b/arch/x86/configs/xen.config
@@ -0,0 +1,7 @@
+# x86 xen specific config options
+CONFIG_XEN_PVHVM=y
+CONFIG_XEN_MAX_DOMAIN_MEMORY=500
+CONFIG_XEN_SAVE_RESTORE=y
+# CONFIG_XEN_DEBUG_FS is not set
+CONFIG_XEN_PVH=y
+CONFIG_XEN_MCE_LOG=y
diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
new file mode 100644
index 0000000..d2ec010
--- /dev/null
+++ b/kernel/configs/xen.config
@@ -0,0 +1,30 @@
+# generic config
+CONFIG_XEN=y
+CONFIG_XEN_DOM0=y
+CONFIG_PCI_XEN=y
+CONFIG_XEN_PCIDEV_FRONTEND=m
+CONFIG_XEN_BLKDEV_FRONTEND=m
+CONFIG_XEN_BLKDEV_BACKEND=m
+CONFIG_XEN_NETDEV_FRONTEND=m
+CONFIG_XEN_NETDEV_BACKEND=m
+CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
+CONFIG_HVC_XEN=y
+CONFIG_HVC_XEN_FRONTEND=y
+CONFIG_TCG_XEN=m
+CONFIG_XEN_WDT=m
+CONFIG_XEN_FBDEV_FRONTEND=y
+CONFIG_XEN_BALLOON=y
+CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
+CONFIG_XEN_SCRUB_PAGES=y
+CONFIG_XEN_DEV_EVTCHN=m
+CONFIG_XEN_BACKEND=y
+CONFIG_XENFS=m
+CONFIG_XEN_COMPAT_XENFS=y
+CONFIG_XEN_SYS_HYPERVISOR=y
+CONFIG_XEN_XENBUS_FRONTEND=y
+CONFIG_XEN_GNTDEV=m
+CONFIG_XEN_GRANT_DEV_ALLOC=m
+CONFIG_SWIOTLB_XEN=y
+CONFIG_XEN_PCIDEV_BACKEND=m
+CONFIG_XEN_PRIVCMD=m
+CONFIG_XEN_ACPI_PROCESSOR=m
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index ff612b0..f4a8f89 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -117,6 +117,10 @@ PHONY += kvmconfig
 kvmconfig:
 	$(call mergeconfig,kvm_guest)
 
+PHONY += xenconfig
+xenconfig:
+	$(call mergeconfig,xen)
+
 PHONY += tinyconfig
 tinyconfig: allnoconfig
 	$(call mergeconfig,tiny)
@@ -142,6 +146,7 @@ help:
 	@echo  '  listnewconfig   - List new options'
 	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
 	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
+	@echo  '  xenconfig       - Enable additional options for xen dom0 and guest kernel support'
 	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
 
 # lxdialog stuff
-- 
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 Dec 10 00:37:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 00: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 1XyVGu-0002IN-GH; Wed, 10 Dec 2014 00:36: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 1XyVGs-0002II-Un
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 00:36:51 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	D1/89-02576-2A597845; Wed, 10 Dec 2014 00:36:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418171808!10712592!1
X-Originating-IP: [66.165.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 1873 invoked from network); 10 Dec 2014 00:36:49 -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;
	10 Dec 2014 00:36:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,548,1413244800"; d="scan'208";a="202200423"
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.210.2; Tue, 9 Dec 2014 19:36: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 1XyVGo-0004V6-Ns;
	Wed, 10 Dec 2014 00:36:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyVGo-0000xl-IN;
	Wed, 10 Dec 2014 00:36:46 +0000
Date: Wed, 10 Dec 2014 00:36:46 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32181-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] 32181: 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 32181 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32181/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          b0b7b13cadc971e8c5745880dcbb92bc2185765b
baseline version:
 rumpuserxen          fbf232c42ae2dea512a2c34b154e1d63f3dad3c4

------------------------------------------------------------
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=b0b7b13cadc971e8c5745880dcbb92bc2185765b
+ . 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 b0b7b13cadc971e8c5745880dcbb92bc2185765b
+ branch=rumpuserxen
+ revision=b0b7b13cadc971e8c5745880dcbb92bc2185765b
+ . 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 b0b7b13cadc971e8c5745880dcbb92bc2185765b:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   fbf232c..b0b7b13  b0b7b13cadc971e8c5745880dcbb92bc2185765b -> 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 Dec 10 00:37:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 00: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 1XyVGu-0002IN-GH; Wed, 10 Dec 2014 00:36: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 1XyVGs-0002II-Un
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 00:36:51 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	D1/89-02576-2A597845; Wed, 10 Dec 2014 00:36:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418171808!10712592!1
X-Originating-IP: [66.165.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 1873 invoked from network); 10 Dec 2014 00:36:49 -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;
	10 Dec 2014 00:36:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,548,1413244800"; d="scan'208";a="202200423"
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.210.2; Tue, 9 Dec 2014 19:36: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 1XyVGo-0004V6-Ns;
	Wed, 10 Dec 2014 00:36:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyVGo-0000xl-IN;
	Wed, 10 Dec 2014 00:36:46 +0000
Date: Wed, 10 Dec 2014 00:36:46 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32181-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] 32181: 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 32181 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32181/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          b0b7b13cadc971e8c5745880dcbb92bc2185765b
baseline version:
 rumpuserxen          fbf232c42ae2dea512a2c34b154e1d63f3dad3c4

------------------------------------------------------------
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=b0b7b13cadc971e8c5745880dcbb92bc2185765b
+ . 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 b0b7b13cadc971e8c5745880dcbb92bc2185765b
+ branch=rumpuserxen
+ revision=b0b7b13cadc971e8c5745880dcbb92bc2185765b
+ . 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 b0b7b13cadc971e8c5745880dcbb92bc2185765b:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   fbf232c..b0b7b13  b0b7b13cadc971e8c5745880dcbb92bc2185765b -> 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 Dec 10 00:41:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 00:41:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyVL5-0002QA-5q; Wed, 10 Dec 2014 00:41:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1XyVL4-0002Q4-Mb
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 00:41:10 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	E9/C4-16982-5A697845; Wed, 10 Dec 2014 00:41:09 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418172068!12148246!1
X-Originating-IP: [217.70.183.197]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25941 invoked from network); 10 Dec 2014 00:41:09 -0000
Received: from relay5-d.mail.gandi.net (HELO relay5-d.mail.gandi.net)
	(217.70.183.197)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 00:41:09 -0000
Received: from mfilter9-d.gandi.net (mfilter9-d.gandi.net [217.70.178.138])
	by relay5-d.mail.gandi.net (Postfix) with ESMTP id CED9241C06F;
	Wed, 10 Dec 2014 01:41:08 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter9-d.gandi.net
Received: from relay5-d.mail.gandi.net ([217.70.183.197])
	by mfilter9-d.gandi.net (mfilter9-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id pAip-3LmTcy7; Wed, 10 Dec 2014 01:41:07 +0100 (CET)
X-Originating-IP: 50.43.43.148
Received: from thin (static-50-43-43-148.bvtn.or.frontiernet.net
	[50.43.43.148]) (Authenticated sender: josh@joshtriplett.org)
	by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 9DF2441C056;
	Wed, 10 Dec 2014 01:40:57 +0100 (CET)
Date: Tue, 9 Dec 2014 16:40:55 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Message-ID: <20141210004054.GA3073@thin>
References: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
	<1418168138-6425-2-git-send-email-mcgrof@do-not-panic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418168138-6425-2-git-send-email-mcgrof@do-not-panic.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Michal Marek <mmarek@suse.cz>, David Rientjes <rientjes@google.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, fengguang.wu@intel.com,
	levinsasha928@gmail.com, hpa@zytor.com,
	xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>,
	sam@ravnborg.org, David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 1/2] x86, platform, xen,
 kconfig: clarify kvmconfig is for kvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 03:35:37PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> We'll be adding options for xen as well.
> 
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Pekka Enberg <penberg@kernel.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Michal Marek <mmarek@suse.cz>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: penberg@kernel.org
> Cc: levinsasha928@gmail.com
> Cc: mtosatti@redhat.com
> Cc: fengguang.wu@intel.com
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xenproject.org
> Acked-by: David Rientjes <rientjes@google.com>
> Acked-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>

Reviewed-by: Josh Triplett <josh@joshtriplett.org>

>  scripts/kconfig/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index 9645c07..ff612b0 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -141,7 +141,7 @@ help:
>  	@echo  '  randconfig	  - New config with random answer to all options'
>  	@echo  '  listnewconfig   - List new options'
>  	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
> -	@echo  '  kvmconfig	  - Enable additional options for guest kernel support'
> +	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
>  	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
>  
>  # lxdialog stuff
> -- 
> 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 Dec 10 00:41:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 00:41:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyVL5-0002QA-5q; Wed, 10 Dec 2014 00:41:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <josh@joshtriplett.org>) id 1XyVL4-0002Q4-Mb
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 00:41:10 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	E9/C4-16982-5A697845; Wed, 10 Dec 2014 00:41:09 +0000
X-Env-Sender: josh@joshtriplett.org
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418172068!12148246!1
X-Originating-IP: [217.70.183.197]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25941 invoked from network); 10 Dec 2014 00:41:09 -0000
Received: from relay5-d.mail.gandi.net (HELO relay5-d.mail.gandi.net)
	(217.70.183.197)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 00:41:09 -0000
Received: from mfilter9-d.gandi.net (mfilter9-d.gandi.net [217.70.178.138])
	by relay5-d.mail.gandi.net (Postfix) with ESMTP id CED9241C06F;
	Wed, 10 Dec 2014 01:41:08 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter9-d.gandi.net
Received: from relay5-d.mail.gandi.net ([217.70.183.197])
	by mfilter9-d.gandi.net (mfilter9-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id pAip-3LmTcy7; Wed, 10 Dec 2014 01:41:07 +0100 (CET)
X-Originating-IP: 50.43.43.148
Received: from thin (static-50-43-43-148.bvtn.or.frontiernet.net
	[50.43.43.148]) (Authenticated sender: josh@joshtriplett.org)
	by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 9DF2441C056;
	Wed, 10 Dec 2014 01:40:57 +0100 (CET)
Date: Tue, 9 Dec 2014 16:40:55 -0800
From: Josh Triplett <josh@joshtriplett.org>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Message-ID: <20141210004054.GA3073@thin>
References: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
	<1418168138-6425-2-git-send-email-mcgrof@do-not-panic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418168138-6425-2-git-send-email-mcgrof@do-not-panic.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Michal Marek <mmarek@suse.cz>, David Rientjes <rientjes@google.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, fengguang.wu@intel.com,
	levinsasha928@gmail.com, hpa@zytor.com,
	xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>,
	sam@ravnborg.org, David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 1/2] x86, platform, xen,
 kconfig: clarify kvmconfig is for kvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 03:35:37PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> We'll be adding options for xen as well.
> 
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Pekka Enberg <penberg@kernel.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Michal Marek <mmarek@suse.cz>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: penberg@kernel.org
> Cc: levinsasha928@gmail.com
> Cc: mtosatti@redhat.com
> Cc: fengguang.wu@intel.com
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xenproject.org
> Acked-by: David Rientjes <rientjes@google.com>
> Acked-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>

Reviewed-by: Josh Triplett <josh@joshtriplett.org>

>  scripts/kconfig/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index 9645c07..ff612b0 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -141,7 +141,7 @@ help:
>  	@echo  '  randconfig	  - New config with random answer to all options'
>  	@echo  '  listnewconfig   - List new options'
>  	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
> -	@echo  '  kvmconfig	  - Enable additional options for guest kernel support'
> +	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
>  	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
>  
>  # lxdialog stuff
> -- 
> 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 Dec 10 01:08:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 01:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyVkv-0007MI-Nk; Wed, 10 Dec 2014 01:07:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XyVku-0007MD-1w
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 01:07:52 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	73/9F-08051-7EC97845; Wed, 10 Dec 2014 01:07:51 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418173669!9406463!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14254 invoked from network); 10 Dec 2014 01:07:50 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-27.messagelabs.com with SMTP;
	10 Dec 2014 01:07:50 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 09 Dec 2014 17:07:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,549,1413270000"; d="scan'208";a="651282031"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by orsmga002.jf.intel.com with ESMTP; 09 Dec 2014 17:07:46 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 09:07:45 +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; Wed, 10 Dec 2014 09:07:45 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Zhang Yu <yu.c.zhang@linux.intel.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGhdsAgAAFC4CAAAOQAIABdNew
Date: Wed, 10 Dec 2014 01:07:43 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
In-Reply-To: <5486E1EA020000780004E108@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 \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, December 09, 2014 6:50 PM
> 
> >>> On 09.12.14 at 11:37, <yu.c.zhang@linux.intel.com> wrote:
> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
> >> I think use of an raw mfn value currently works only because dom0 is using
> a
> > 1:1 IOMMU mapping scheme. Is my understanding correct, or do you really
> need
> > raw mfn values?
> > Thanks for your quick response, Paul.
> > Well, not exactly for this case. :)
> > In XenGT, our need to translate gfn to mfn is for GPU's page table,
> > which contains the translation between graphic address and the memory
> > address. This page table is maintained by GPU drivers, and our service
> > domain need to have a method to translate the guest physical addresses
> > written by the vGPU into host physical ones.
> > We do not use IOMMU in XenGT and therefore this translation may not
> > necessarily be a 1:1 mapping.
> 
> Hmm, that suggests you indeed need raw MFNs, which in turn seems
> problematic wrt PVH Dom0 (or you'd need a GFN->GMFN translation
> layer). But while you don't use the IOMMU yourself, I suppose the GPU
> accesses still don't bypass the IOMMU? In which case all you'd need
> returned is a frame number that guarantees that after IOMMU
> translation it refers to the correct MFN, i.e. still allowing for your Dom0
> driver to simply set aside a part of its PFN space, asking Xen to
> (IOMMU-)map the necessary guest frames into there.
> 

No. What we require is the raw MFNs. One IOMMU device entry can't
point to multiple VM's page tables, so that's why XenGT needs to use
software shadow GPU page table to implement the sharing. Note it's
not for dom0 to access the MFN. It's for dom0 to setup the correct
shadow GPU page table, so a VM can access the graphics memory
in a controlled way.

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 Dec 10 01:08:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 01:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyVkv-0007MI-Nk; Wed, 10 Dec 2014 01:07:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XyVku-0007MD-1w
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 01:07:52 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	73/9F-08051-7EC97845; Wed, 10 Dec 2014 01:07:51 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418173669!9406463!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14254 invoked from network); 10 Dec 2014 01:07:50 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-27.messagelabs.com with SMTP;
	10 Dec 2014 01:07:50 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 09 Dec 2014 17:07:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,549,1413270000"; d="scan'208";a="651282031"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by orsmga002.jf.intel.com with ESMTP; 09 Dec 2014 17:07:46 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 09:07:45 +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; Wed, 10 Dec 2014 09:07:45 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Zhang Yu <yu.c.zhang@linux.intel.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGhdsAgAAFC4CAAAOQAIABdNew
Date: Wed, 10 Dec 2014 01:07:43 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
In-Reply-To: <5486E1EA020000780004E108@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 \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, December 09, 2014 6:50 PM
> 
> >>> On 09.12.14 at 11:37, <yu.c.zhang@linux.intel.com> wrote:
> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
> >> I think use of an raw mfn value currently works only because dom0 is using
> a
> > 1:1 IOMMU mapping scheme. Is my understanding correct, or do you really
> need
> > raw mfn values?
> > Thanks for your quick response, Paul.
> > Well, not exactly for this case. :)
> > In XenGT, our need to translate gfn to mfn is for GPU's page table,
> > which contains the translation between graphic address and the memory
> > address. This page table is maintained by GPU drivers, and our service
> > domain need to have a method to translate the guest physical addresses
> > written by the vGPU into host physical ones.
> > We do not use IOMMU in XenGT and therefore this translation may not
> > necessarily be a 1:1 mapping.
> 
> Hmm, that suggests you indeed need raw MFNs, which in turn seems
> problematic wrt PVH Dom0 (or you'd need a GFN->GMFN translation
> layer). But while you don't use the IOMMU yourself, I suppose the GPU
> accesses still don't bypass the IOMMU? In which case all you'd need
> returned is a frame number that guarantees that after IOMMU
> translation it refers to the correct MFN, i.e. still allowing for your Dom0
> driver to simply set aside a part of its PFN space, asking Xen to
> (IOMMU-)map the necessary guest frames into there.
> 

No. What we require is the raw MFNs. One IOMMU device entry can't
point to multiple VM's page tables, so that's why XenGT needs to use
software shadow GPU page table to implement the sharing. Note it's
not for dom0 to access the MFN. It's for dom0 to setup the correct
shadow GPU page table, so a VM can access the graphics memory
in a controlled way.

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 Dec 10 01:16:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 01:16:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyVss-0007kA-Ml; Wed, 10 Dec 2014 01:16:06 +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 1XyVsq-0007k5-SH
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 01:16:04 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	04/FC-25547-4DE97845; Wed, 10 Dec 2014 01:16:04 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418174161!12191761!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24372 invoked from network); 10 Dec 2014 01:16:03 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 01:16:03 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 09 Dec 2014 17:15:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,549,1413270000"; d="scan'208";a="651285419"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga002.jf.intel.com with ESMTP; 09 Dec 2014 17:15:45 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 09:14:23 +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; Wed, 10 Dec 2014 09:14:22 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>, "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAF26eA=
Date: Wed, 10 Dec 2014 01:14:21 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
In-Reply-To: <20141209104633.GC75319@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: "Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	"keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Tuesday, December 09, 2014 6:47 PM
> 
> At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > Hi all,
> >
> >    As you can see, we are pushing our XenGT patches to the upstream. One
> > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > device model.
> >
> >    Here we may have 2 similar solutions:
> >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was
> no
> > usage at that time.
> 
> It's been suggested before that we should revive this hypercall, and I
> don't think it's a good idea.  Whenever a domain needs to know the
> actual MFN of another domain's memory it's usually because the
> security model is problematic.  In particular, finding the MFN is
> usually followed by a brute-force mapping from a dom0 process, or by
> passing the MFN to a device for unprotected DMA.

In our case it's not because the security model is problematic. It's 
because GPU virtualization is done in Dom0 while the memory virtualization
is done in hypervisor. We need a means to query GPFN->MFN so we can
setup shadow GPU page table in Dom0 correctly, for a VM.

> 
> These days DMA access should be protected by IOMMUs, or else
> the device drivers (and associated tools) are effectively inside the
> hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> presumably present on anything new enough to run XenGT?).

yes, IOMMU protect DMA accesses in a device-agnostic way. But in
our case, IOMMU can't be used because it's only for exclusively
assigned case, as I replied in another mail. And to reduce the hypervisor
TCB, we put device model in Dom0 which is why a interface is required
to connect p2m information.

> 
> So I think the interface we need here is a please-map-this-gfn one,
> like the existing grant-table ops (which already do what you need by
> returning an address suitable for DMA).  If adding a grant entry for
> every frame of the framebuffer within the guest is too much, maybe we
> can make a new interface for the guest to grant access to larger areas.

A please-map-this-gfn interface assumes the logic behind lies in Xen
hypervisor, e.g. managing CPU page table or IOMMU entry. However
here the management of GPU page table is in Dom0, and what we
want is a please-tell-me-mfn-for-a-gpfn interface, so we can translate
from gpfn in guest GPU PTE to a mfn in shadow GPU PTE. 

Hope this makes the requirement clearer.

> 
> 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 Dec 10 01:16:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 01:16:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyVss-0007kA-Ml; Wed, 10 Dec 2014 01:16:06 +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 1XyVsq-0007k5-SH
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 01:16:04 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	04/FC-25547-4DE97845; Wed, 10 Dec 2014 01:16:04 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418174161!12191761!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24372 invoked from network); 10 Dec 2014 01:16:03 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 01:16:03 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 09 Dec 2014 17:15:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,549,1413270000"; d="scan'208";a="651285419"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga002.jf.intel.com with ESMTP; 09 Dec 2014 17:15:45 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 09:14:23 +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; Wed, 10 Dec 2014 09:14:22 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>, "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAF26eA=
Date: Wed, 10 Dec 2014 01:14:21 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
In-Reply-To: <20141209104633.GC75319@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: "Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	"keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Tuesday, December 09, 2014 6:47 PM
> 
> At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > Hi all,
> >
> >    As you can see, we are pushing our XenGT patches to the upstream. One
> > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > device model.
> >
> >    Here we may have 2 similar solutions:
> >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was
> no
> > usage at that time.
> 
> It's been suggested before that we should revive this hypercall, and I
> don't think it's a good idea.  Whenever a domain needs to know the
> actual MFN of another domain's memory it's usually because the
> security model is problematic.  In particular, finding the MFN is
> usually followed by a brute-force mapping from a dom0 process, or by
> passing the MFN to a device for unprotected DMA.

In our case it's not because the security model is problematic. It's 
because GPU virtualization is done in Dom0 while the memory virtualization
is done in hypervisor. We need a means to query GPFN->MFN so we can
setup shadow GPU page table in Dom0 correctly, for a VM.

> 
> These days DMA access should be protected by IOMMUs, or else
> the device drivers (and associated tools) are effectively inside the
> hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> presumably present on anything new enough to run XenGT?).

yes, IOMMU protect DMA accesses in a device-agnostic way. But in
our case, IOMMU can't be used because it's only for exclusively
assigned case, as I replied in another mail. And to reduce the hypervisor
TCB, we put device model in Dom0 which is why a interface is required
to connect p2m information.

> 
> So I think the interface we need here is a please-map-this-gfn one,
> like the existing grant-table ops (which already do what you need by
> returning an address suitable for DMA).  If adding a grant entry for
> every frame of the framebuffer within the guest is too much, maybe we
> can make a new interface for the guest to grant access to larger areas.

A please-map-this-gfn interface assumes the logic behind lies in Xen
hypervisor, e.g. managing CPU page table or IOMMU entry. However
here the management of GPU page table is in Dom0, and what we
want is a please-tell-me-mfn-for-a-gpfn interface, so we can translate
from gpfn in guest GPU PTE to a mfn in shadow GPU PTE. 

Hope this makes the requirement clearer.

> 
> 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 Dec 10 01:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 01: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 1XyVzA-000845-SP; Wed, 10 Dec 2014 01:22:36 +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 1XyVz9-00082D-EU
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 01:22:35 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	E2/9C-26740-A50A7845; Wed, 10 Dec 2014 01:22:34 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418174553!9765619!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8913 invoked from network); 10 Dec 2014 01:22:33 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 01:22:33 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 09 Dec 2014 17:20:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="496368041"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by orsmga003.jf.intel.com with ESMTP; 09 Dec 2014 17:18:25 -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, 10 Dec 2014 09:22:08 +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, 10 Dec 2014 09:22:07 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Malcolm Crossley <malcolm.crossley@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGhdsAgAAFC4CAAAQDAIABd1pg
Date: Wed, 10 Dec 2014 01:22:07 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126114CD7@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com> <5486D43A.7070504@citrix.com>
In-Reply-To: <5486D43A.7070504@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
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Malcolm Crossley
> Sent: Tuesday, December 09, 2014 6:52 PM
> 
> On 09/12/14 10:37, Yu, Zhang wrote:
> >
> >
> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
> >> I think use of an raw mfn value currently works only because dom0 is
> >> using a 1:1 IOMMU mapping scheme. Is my understanding correct, or do
> >> you really need raw mfn values?
> > Thanks for your quick response, Paul.
> > Well, not exactly for this case. :)
> > In XenGT, our need to translate gfn to mfn is for GPU's page table,
> > which contains the translation between graphic address and the memory
> > address. This page table is maintained by GPU drivers, and our service
> > domain need to have a method to translate the guest physical addresses
> > written by the vGPU into host physical ones.
> > We do not use IOMMU in XenGT and therefore this translation may not
> > necessarily be a 1:1 mapping.
> 
> XenGT must use the IOMMU mappings that Xen has setup for the domain
> which owns the GPU. Currently Dom0 own's the GPU and so it's IOMMU
> mappings match the MFN's addresses. I suspect XenGT will not work if Xen
> is booted with iommu=dom0-strict.
> 

This is a good point. So yes in this case IOMMU is still active which contains
a 1:1 IOMMU mapping table, but it's a separate thing from the interface
discussed here, which is about setup a shadow GPU page table for other VM's
graphics memory accesses. 

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 Dec 10 01:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 01: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 1XyVzA-000845-SP; Wed, 10 Dec 2014 01:22:36 +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 1XyVz9-00082D-EU
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 01:22:35 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	E2/9C-26740-A50A7845; Wed, 10 Dec 2014 01:22:34 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418174553!9765619!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8913 invoked from network); 10 Dec 2014 01:22:33 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 01:22:33 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 09 Dec 2014 17:20:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="496368041"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by orsmga003.jf.intel.com with ESMTP; 09 Dec 2014 17:18:25 -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, 10 Dec 2014 09:22:08 +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, 10 Dec 2014 09:22:07 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Malcolm Crossley <malcolm.crossley@citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGhdsAgAAFC4CAAAQDAIABd1pg
Date: Wed, 10 Dec 2014 01:22:07 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126114CD7@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com> <5486D43A.7070504@citrix.com>
In-Reply-To: <5486D43A.7070504@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
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Malcolm Crossley
> Sent: Tuesday, December 09, 2014 6:52 PM
> 
> On 09/12/14 10:37, Yu, Zhang wrote:
> >
> >
> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
> >> I think use of an raw mfn value currently works only because dom0 is
> >> using a 1:1 IOMMU mapping scheme. Is my understanding correct, or do
> >> you really need raw mfn values?
> > Thanks for your quick response, Paul.
> > Well, not exactly for this case. :)
> > In XenGT, our need to translate gfn to mfn is for GPU's page table,
> > which contains the translation between graphic address and the memory
> > address. This page table is maintained by GPU drivers, and our service
> > domain need to have a method to translate the guest physical addresses
> > written by the vGPU into host physical ones.
> > We do not use IOMMU in XenGT and therefore this translation may not
> > necessarily be a 1:1 mapping.
> 
> XenGT must use the IOMMU mappings that Xen has setup for the domain
> which owns the GPU. Currently Dom0 own's the GPU and so it's IOMMU
> mappings match the MFN's addresses. I suspect XenGT will not work if Xen
> is booted with iommu=dom0-strict.
> 

This is a good point. So yes in this case IOMMU is still active which contains
a 1:1 IOMMU mapping table, but it's a separate thing from the interface
discussed here, which is about setup a shadow GPU page table for other VM's
graphics memory accesses. 

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 Dec 10 01:49:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 01:49:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyWOC-0000Oq-69; Wed, 10 Dec 2014 01:48:28 +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 1XyWOA-0000Ol-Td
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 01:48:27 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	87/85-26740-A66A7845; Wed, 10 Dec 2014 01:48:26 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418176103!7768329!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 5848 invoked from network); 10 Dec 2014 01:48:23 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 01:48:23 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 09 Dec 2014 17:48:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,549,1413270000"; d="scan'208";a="645182200"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by fmsmga002.fm.intel.com with ESMTP; 09 Dec 2014 17:48:17 -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, 10 Dec 2014 09:48:14 +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, 10 Dec 2014 09:48:12 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAAFMICAAAGqAIAAAayAgAADWoCAAAQmAIABb3PA
Date: Wed, 10 Dec 2014 01:48:12 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126114D11@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
	<1418124543.14361.27.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD0257859BB@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0257859BB@AMSPEX01CL01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Yu, Zhang" <yu.c.zhang@linux.intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Paul Durrant [mailto:Paul.Durrant@citrix.com]
> Sent: Tuesday, December 09, 2014 7:44 PM
> 
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 09 December 2014 11:29
> > To: Paul Durrant
> > Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); JBeulich@suse.com;
> > Xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] One question about the hypercall to translate gfn to
> > mfn.
> >
> > On Tue, 2014-12-09 at 11:17 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 09 December 2014 11:11
> > > > To: Paul Durrant
> > > > Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org);
> > JBeulich@suse.com;
> > > > Xen-devel@lists.xen.org
> > > > Subject: Re: [Xen-devel] One question about the hypercall to translate
> > gfn to
> > > > mfn.
> > > >
> > > > On Tue, 2014-12-09 at 11:05 +0000, Paul Durrant wrote:
> > > > > > -----Original Message-----
> > > > > > From: Tim Deegan [mailto:tim@xen.org]
> > > > > > Sent: 09 December 2014 10:47
> > > > > > To: Yu, Zhang
> > > > > > Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> > > > > > devel@lists.xen.org
> > > > > > Subject: Re: One question about the hypercall to translate gfn to mfn.
> > > > > >
> > > > > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > >    As you can see, we are pushing our XenGT patches to the
> > upstream.
> > > > One
> > > > > > > feature we need in xen is to translate guests' gfn to mfn in XenGT
> > dom0
> > > > > > > device model.
> > > > > > >
> > > > > > >    Here we may have 2 similar solutions:
> > > > > > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > > > > > hypercall, XENMEM_translate_gpfn_list, which was removed by
> > Keir in
> > > > > > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because
> > there
> > > > was
> > > > > > no
> > > > > > > usage at that time.
> > > > > >
> > > > > > It's been suggested before that we should revive this hypercall, and I
> > > > > > don't think it's a good idea.  Whenever a domain needs to know the
> > > > > > actual MFN of another domain's memory it's usually because the
> > > > > > security model is problematic.  In particular, finding the MFN is
> > > > > > usually followed by a brute-force mapping from a dom0 process, or
> by
> > > > > > passing the MFN to a device for unprotected DMA.
> > > > > >
> > > > > > These days DMA access should be protected by IOMMUs, or else
> > > > > > the device drivers (and associated tools) are effectively inside the
> > > > > > hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> > > > > > presumably present on anything new enough to run XenGT?).
> > > > > >
> > > > > > So I think the interface we need here is a please-map-this-gfn one,
> > > > > > like the existing grant-table ops (which already do what you need by
> > > > > > returning an address suitable for DMA).  If adding a grant entry for
> > > > > > every frame of the framebuffer within the guest is too much, maybe
> > we
> > > > > > can make a new interface for the guest to grant access to larger
> areas.
> > > > > >
> > > > >
> > > > > IIUC the in-guest driver is Xen-unaware so any grant entry would have
> > > > > to be put in the guests table by the tools, which would entail some
> > > > > form of flexibly sized reserved range of grant entries otherwise any
> > > > > PV driver that are present in the guest would merrily clobber the new
> > > > > grant entries.
> > > > > A domain can already priv map a gfn into the MMU, so I think we just
> > > > >  need an equivalent for the IOMMU.
> > > >
> > > > I'm not sure I'm fully understanding what's going on here, but is a
> > > > variant of XENMEM_add_to_physmap+XENMAPSPACE_gmfn_foreign
> > which
> > > > also
> > > > returns a DMA handle a plausible solution?
> > > >
> > >
> > > I think we want be able to avoid setting up a PTE in the MMU since
> > > it's not needed in most (or perhaps all?) cases.
> >
> > Another (wildly under-informed) thought then:
> >
> > A while back Global logic proposed (for ARM) an infrastructure for
> > allowing dom0 drivers to maintain a set of iommu like pagetables under
> > hypervisor supervision (they called these "remoteprocessor iommu").
> >
> > I didn't fully grok what it was at the time, let alone remember the
> > details properly now, but AIUI it was essentially a framework for
> > allowing a simple Xen side driver to provide PV-MMU-like update
> > operations for a set of PTs which were not the main-processor's PTs,
> > with validation etc.
> >
> > See http://thread.gmane.org/gmane.comp.emulators.xen.devel/212945
> >
> > The introductory email even mentions GPUs...
> >
> 
> That series does indeed seem to be very relevant.
> 
>   Paul

I'm not familiar with Arm architecture, but based on a brief reading it's
for the assigned case where the MMU is exclusive owned by a VM, so
some type of MMU virtualization is required and it's straightforward.

However XenGT is a shared GPU usage:

- a global GPU page table is partitioned among VMs. a shared shadow
global page table is maintained, containing translations for multiple
VMs simultaneously based on partitioning information
- multiple per-process GPU page tables are created by each VM, and
multiple shadow per-process GPU page tables are created correspondingly.
shadow page table is switched when doing GPU context switch, same as
what we did for CPU shadow page table.

So you can see above shared MMU virtualization usage is very GPU
specific, that's why we didn't put in Xen hypervisor, and thus additional
interface is required to get p2m mapping to assist our shadow GPU
page table usage.

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 Dec 10 01:49:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 01:49:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyWOC-0000Oq-69; Wed, 10 Dec 2014 01:48:28 +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 1XyWOA-0000Ol-Td
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 01:48:27 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	87/85-26740-A66A7845; Wed, 10 Dec 2014 01:48:26 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418176103!7768329!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 5848 invoked from network); 10 Dec 2014 01:48:23 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 01:48:23 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 09 Dec 2014 17:48:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,549,1413270000"; d="scan'208";a="645182200"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
	by fmsmga002.fm.intel.com with ESMTP; 09 Dec 2014 17:48:17 -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, 10 Dec 2014 09:48:14 +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, 10 Dec 2014 09:48:12 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAAFMICAAAGqAIAAAayAgAADWoCAAAQmAIABb3PA
Date: Wed, 10 Dec 2014 01:48:12 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126114D11@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
	<1418124543.14361.27.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD0257859BB@AMSPEX01CL01.citrite.net>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0257859BB@AMSPEX01CL01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Yu, Zhang" <yu.c.zhang@linux.intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Paul Durrant [mailto:Paul.Durrant@citrix.com]
> Sent: Tuesday, December 09, 2014 7:44 PM
> 
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 09 December 2014 11:29
> > To: Paul Durrant
> > Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); JBeulich@suse.com;
> > Xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] One question about the hypercall to translate gfn to
> > mfn.
> >
> > On Tue, 2014-12-09 at 11:17 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 09 December 2014 11:11
> > > > To: Paul Durrant
> > > > Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org);
> > JBeulich@suse.com;
> > > > Xen-devel@lists.xen.org
> > > > Subject: Re: [Xen-devel] One question about the hypercall to translate
> > gfn to
> > > > mfn.
> > > >
> > > > On Tue, 2014-12-09 at 11:05 +0000, Paul Durrant wrote:
> > > > > > -----Original Message-----
> > > > > > From: Tim Deegan [mailto:tim@xen.org]
> > > > > > Sent: 09 December 2014 10:47
> > > > > > To: Yu, Zhang
> > > > > > Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen-
> > > > > > devel@lists.xen.org
> > > > > > Subject: Re: One question about the hypercall to translate gfn to mfn.
> > > > > >
> > > > > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > >    As you can see, we are pushing our XenGT patches to the
> > upstream.
> > > > One
> > > > > > > feature we need in xen is to translate guests' gfn to mfn in XenGT
> > dom0
> > > > > > > device model.
> > > > > > >
> > > > > > >    Here we may have 2 similar solutions:
> > > > > > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > > > > > hypercall, XENMEM_translate_gpfn_list, which was removed by
> > Keir in
> > > > > > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because
> > there
> > > > was
> > > > > > no
> > > > > > > usage at that time.
> > > > > >
> > > > > > It's been suggested before that we should revive this hypercall, and I
> > > > > > don't think it's a good idea.  Whenever a domain needs to know the
> > > > > > actual MFN of another domain's memory it's usually because the
> > > > > > security model is problematic.  In particular, finding the MFN is
> > > > > > usually followed by a brute-force mapping from a dom0 process, or
> by
> > > > > > passing the MFN to a device for unprotected DMA.
> > > > > >
> > > > > > These days DMA access should be protected by IOMMUs, or else
> > > > > > the device drivers (and associated tools) are effectively inside the
> > > > > > hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
> > > > > > presumably present on anything new enough to run XenGT?).
> > > > > >
> > > > > > So I think the interface we need here is a please-map-this-gfn one,
> > > > > > like the existing grant-table ops (which already do what you need by
> > > > > > returning an address suitable for DMA).  If adding a grant entry for
> > > > > > every frame of the framebuffer within the guest is too much, maybe
> > we
> > > > > > can make a new interface for the guest to grant access to larger
> areas.
> > > > > >
> > > > >
> > > > > IIUC the in-guest driver is Xen-unaware so any grant entry would have
> > > > > to be put in the guests table by the tools, which would entail some
> > > > > form of flexibly sized reserved range of grant entries otherwise any
> > > > > PV driver that are present in the guest would merrily clobber the new
> > > > > grant entries.
> > > > > A domain can already priv map a gfn into the MMU, so I think we just
> > > > >  need an equivalent for the IOMMU.
> > > >
> > > > I'm not sure I'm fully understanding what's going on here, but is a
> > > > variant of XENMEM_add_to_physmap+XENMAPSPACE_gmfn_foreign
> > which
> > > > also
> > > > returns a DMA handle a plausible solution?
> > > >
> > >
> > > I think we want be able to avoid setting up a PTE in the MMU since
> > > it's not needed in most (or perhaps all?) cases.
> >
> > Another (wildly under-informed) thought then:
> >
> > A while back Global logic proposed (for ARM) an infrastructure for
> > allowing dom0 drivers to maintain a set of iommu like pagetables under
> > hypervisor supervision (they called these "remoteprocessor iommu").
> >
> > I didn't fully grok what it was at the time, let alone remember the
> > details properly now, but AIUI it was essentially a framework for
> > allowing a simple Xen side driver to provide PV-MMU-like update
> > operations for a set of PTs which were not the main-processor's PTs,
> > with validation etc.
> >
> > See http://thread.gmane.org/gmane.comp.emulators.xen.devel/212945
> >
> > The introductory email even mentions GPUs...
> >
> 
> That series does indeed seem to be very relevant.
> 
>   Paul

I'm not familiar with Arm architecture, but based on a brief reading it's
for the assigned case where the MMU is exclusive owned by a VM, so
some type of MMU virtualization is required and it's straightforward.

However XenGT is a shared GPU usage:

- a global GPU page table is partitioned among VMs. a shared shadow
global page table is maintained, containing translations for multiple
VMs simultaneously based on partitioning information
- multiple per-process GPU page tables are created by each VM, and
multiple shadow per-process GPU page tables are created correspondingly.
shadow page table is switched when doing GPU context switch, same as
what we did for CPU shadow page table.

So you can see above shared MMU virtualization usage is very GPU
specific, that's why we didn't put in Xen hypervisor, and thus additional
interface is required to get p2m mapping to assist our shadow GPU
page table usage.

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 Dec 10 01:59:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 01:59:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyWYi-0000nb-Ba; Wed, 10 Dec 2014 01:59:20 +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 1XyWYh-0000nW-RS
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 01:59:19 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EF/4B-09842-7F8A7845; Wed, 10 Dec 2014 01:59:19 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418176758!7236530!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 4388 invoked from network); 10 Dec 2014 01:59:18 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 01:59:18 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga102.jf.intel.com with ESMTP; 09 Dec 2014 17:57:55 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="496382491"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.177])
	([10.238.128.177])
	by orsmga003.jf.intel.com with ESMTP; 09 Dec 2014 17:55:29 -0800
Message-ID: <5487A8F0.2010701@intel.com>
Date: Wed, 10 Dec 2014 09:59: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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Tim Deegan <tim@xen.org>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<5486DB5E020000780004E09A@mail.emea.novell.com>
In-Reply-To: <5486DB5E020000780004E09A@mail.emea.novell.com>
Cc: kevin.tian@intel.com, 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] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/9 18:22, Jan Beulich wrote:
>>>> On 09.12.14 at 11:11, <tim@xen.org> wrote:
>> At 08:19 +0000 on 09 Dec (1418109561), Jan Beulich wrote:
>>> Why do you always pick other than the simplest possible solution?
>>
>> Jan, please don't make personal comments like this in code review.  It
>> can only offend and demoralize contributors, and deter other people
>> from joining in.
>
> I apologize - I shouldn't have permitted myself to do so.
>
>> I understand that it can be frustrating, and I'm sure I have lashed

Actually myself also have this same feeling but this really isn't 
helpful to step forward.

>> out at people on-list in the past.  But remember that people who are
>> new to the project need time to learn, and keep the comments to the
>> code itself.
>>
>> I can see that this series has been going for a long time, and is
>> still getting hung up on coding style issues.  Might it be useful to

Something is my fault here. Although I learn more about Xen from this 
series constantly, looks its hard to cover this big thread with that 
reasonable code under Xen circumstance. This is also why I claimed I 
can't do this right from the start.

And additionally, even some initial designs are not very clear or argued 
between us, so when we discuss something during each revision, it bring 
a new thought again...

>> have a round of internal review from some of the more xen-experienced
>> engineers at Intel before Jan looks at it again?
>
> I've been suggesting something along those lines a number of times,
> with (apparently) no success at all.
>

Actually we had a little bit discussion internal and some guys really 
brought me some comments previously, but I think they're too busy to 
review each patch carefully one line by one line, especially if I bring 
something new to address yours comments just in the process of public 
review.

Anyway, now let me ask if this can deliver to other suitable guy. As I 
said previously I really would like to quit if this can step next properly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 01:59:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 01:59:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyWYi-0000nb-Ba; Wed, 10 Dec 2014 01:59:20 +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 1XyWYh-0000nW-RS
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 01:59:19 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EF/4B-09842-7F8A7845; Wed, 10 Dec 2014 01:59:19 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418176758!7236530!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 4388 invoked from network); 10 Dec 2014 01:59:18 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 01:59:18 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga102.jf.intel.com with ESMTP; 09 Dec 2014 17:57:55 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="496382491"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.177])
	([10.238.128.177])
	by orsmga003.jf.intel.com with ESMTP; 09 Dec 2014 17:55:29 -0800
Message-ID: <5487A8F0.2010701@intel.com>
Date: Wed, 10 Dec 2014 09:59: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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, Tim Deegan <tim@xen.org>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<5486DB5E020000780004E09A@mail.emea.novell.com>
In-Reply-To: <5486DB5E020000780004E09A@mail.emea.novell.com>
Cc: kevin.tian@intel.com, 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] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/9 18:22, Jan Beulich wrote:
>>>> On 09.12.14 at 11:11, <tim@xen.org> wrote:
>> At 08:19 +0000 on 09 Dec (1418109561), Jan Beulich wrote:
>>> Why do you always pick other than the simplest possible solution?
>>
>> Jan, please don't make personal comments like this in code review.  It
>> can only offend and demoralize contributors, and deter other people
>> from joining in.
>
> I apologize - I shouldn't have permitted myself to do so.
>
>> I understand that it can be frustrating, and I'm sure I have lashed

Actually myself also have this same feeling but this really isn't 
helpful to step forward.

>> out at people on-list in the past.  But remember that people who are
>> new to the project need time to learn, and keep the comments to the
>> code itself.
>>
>> I can see that this series has been going for a long time, and is
>> still getting hung up on coding style issues.  Might it be useful to

Something is my fault here. Although I learn more about Xen from this 
series constantly, looks its hard to cover this big thread with that 
reasonable code under Xen circumstance. This is also why I claimed I 
can't do this right from the start.

And additionally, even some initial designs are not very clear or argued 
between us, so when we discuss something during each revision, it bring 
a new thought again...

>> have a round of internal review from some of the more xen-experienced
>> engineers at Intel before Jan looks at it again?
>
> I've been suggesting something along those lines a number of times,
> with (apparently) no success at all.
>

Actually we had a little bit discussion internal and some guys really 
brought me some comments previously, but I think they're too busy to 
review each patch carefully one line by one line, especially if I bring 
something new to address yours comments just in the process of public 
review.

Anyway, now let me ask if this can deliver to other suitable guy. As I 
said previously I really would like to quit if this can step next properly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 02:42:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 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 1XyXE6-0002Yy-0O; Wed, 10 Dec 2014 02:42:06 +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 1XyXE4-0002WG-5O
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 02:42:04 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	13/4A-02576-BF2B7845; Wed, 10 Dec 2014 02:42:03 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418179322!14028953!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15290 invoked from network); 10 Dec 2014 02:42:02 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-7.tower-27.messagelabs.com with SMTP;
	10 Dec 2014 02:42:02 -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 161FD58414D;
	Tue,  9 Dec 2014 18:42:00 -0800 (PST)
Date: Tue, 09 Dec 2014 21:41:59 -0500 (EST)
Message-Id: <20141209.214159.1151143350544712995.davem@davemloft.net>
To: david.vrabel@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1418150608-26180-1-git-send-email-david.vrabel@citrix.com>
References: <1418150608-26180-1-git-send-email-david.vrabel@citrix.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]);
	Tue, 09 Dec 2014 18:42:01 -0800 (PST)
Cc: netdev@vger.kernel.org, boris.ostrovsky@oracle.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net] xen-netfront: use correct linear area
 after linearizing an skb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Tue, 9 Dec 2014 18:43:28 +0000

> Commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d (xen-netfront: Fix
> handling packets on compound pages with skb_linearize) attempted to
> fix a problem where an skb that would have required too many slots
> would be dropped causing TCP connections to stall.
> 
> However, it filled in the first slot using the original buffer and not
> the new one and would use the wrong offset and grant access to the
> wrong page.
> 
> Netback would notice the malformed request and stop all traffic on the
> VIF, reporting:
> 
>     vif vif-3-0 vif3.0: txreq.offset: 85e, size: 4002, end: 6144
>     vif vif-3-0 vif3.0: fatal error; disabling device
> 
> Reported-by: Anthony Wright <anthony@overnetdata.com>
> Tested-by: Anthony Wright <anthony@overnetdata.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Applied and queued up for -stable, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 02:42:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 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 1XyXE6-0002Yy-0O; Wed, 10 Dec 2014 02:42:06 +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 1XyXE4-0002WG-5O
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 02:42:04 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	13/4A-02576-BF2B7845; Wed, 10 Dec 2014 02:42:03 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418179322!14028953!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15290 invoked from network); 10 Dec 2014 02:42:02 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-7.tower-27.messagelabs.com with SMTP;
	10 Dec 2014 02:42:02 -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 161FD58414D;
	Tue,  9 Dec 2014 18:42:00 -0800 (PST)
Date: Tue, 09 Dec 2014 21:41:59 -0500 (EST)
Message-Id: <20141209.214159.1151143350544712995.davem@davemloft.net>
To: david.vrabel@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1418150608-26180-1-git-send-email-david.vrabel@citrix.com>
References: <1418150608-26180-1-git-send-email-david.vrabel@citrix.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]);
	Tue, 09 Dec 2014 18:42:01 -0800 (PST)
Cc: netdev@vger.kernel.org, boris.ostrovsky@oracle.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net] xen-netfront: use correct linear area
 after linearizing an skb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Tue, 9 Dec 2014 18:43:28 +0000

> Commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d (xen-netfront: Fix
> handling packets on compound pages with skb_linearize) attempted to
> fix a problem where an skb that would have required too many slots
> would be dropped causing TCP connections to stall.
> 
> However, it filled in the first slot using the original buffer and not
> the new one and would use the wrong offset and grant access to the
> wrong page.
> 
> Netback would notice the malformed request and stop all traffic on the
> VIF, reporting:
> 
>     vif vif-3-0 vif3.0: txreq.offset: 85e, size: 4002, end: 6144
>     vif vif-3-0 vif3.0: fatal error; disabling device
> 
> Reported-by: Anthony Wright <anthony@overnetdata.com>
> Tested-by: Anthony Wright <anthony@overnetdata.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Applied and queued up for -stable, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 03:19:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 03: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 1XyXnC-0003a9-3O; Wed, 10 Dec 2014 03:18: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 1XyXn9-0003a4-Vj
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 03:18:20 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	F6/B3-14727-B7BB7845; Wed, 10 Dec 2014 03:18:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418181496!12469696!1
X-Originating-IP: [66.165.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 32721 invoked from network); 10 Dec 2014 03:18:17 -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;
	10 Dec 2014 03:18:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,549,1413244800"; d="scan'208";a="202645075"
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.210.2; Tue, 9 Dec 2014 22:18: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 1XyXn2-0005I5-Rw;
	Wed, 10 Dec 2014 03:18:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyXn2-0004uf-L5;
	Wed, 10 Dec 2014 03:18:12 +0000
Date: Wed, 10 Dec 2014 03:18:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32163-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] 32163: 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 32163 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32163/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 32110
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 guest-localmigrate fail REGR. vs. 32110
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 32110
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 32110
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 32110

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 32110
 test-amd64-amd64-xl-sedf      7 debian-install            fail REGR. vs. 32110
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32110
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 31934

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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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                  145c8ced0de02d0ad37743eb42b116e40f13e97e
baseline version:
 xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@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                           broken  
 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                    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                                broken  
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-i386-rumpuserxen-i386                             blocked 
 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                                 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                                     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-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-pcipt-intel host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-xl-win7-amd64 host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)

Not pushing.

------------------------------------------------------------
commit 145c8ced0de02d0ad37743eb42b116e40f13e97e
Author: Keir Fraser <keir@xen.org>
Date:   Mon Dec 8 15:30:17 2014 +0100

    switch to write-biased r/w locks
    
    This is to improve fairness: A permanent flow of read acquires can
    otherwise lock out eventual writers indefinitely.
    
    This is CVE-2014-9065 / XSA-114.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
    master date: 2014-12-08 14:45:46 +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 Dec 10 03:19:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 03: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 1XyXnC-0003a9-3O; Wed, 10 Dec 2014 03:18: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 1XyXn9-0003a4-Vj
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 03:18:20 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	F6/B3-14727-B7BB7845; Wed, 10 Dec 2014 03:18:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418181496!12469696!1
X-Originating-IP: [66.165.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 32721 invoked from network); 10 Dec 2014 03:18:17 -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;
	10 Dec 2014 03:18:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,549,1413244800"; d="scan'208";a="202645075"
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.210.2; Tue, 9 Dec 2014 22:18: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 1XyXn2-0005I5-Rw;
	Wed, 10 Dec 2014 03:18:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyXn2-0004uf-L5;
	Wed, 10 Dec 2014 03:18:12 +0000
Date: Wed, 10 Dec 2014 03:18:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32163-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] 32163: 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 32163 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32163/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 32110
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 guest-localmigrate fail REGR. vs. 32110
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 32110
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 32110
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 32110

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 32110
 test-amd64-amd64-xl-sedf      7 debian-install            fail REGR. vs. 32110
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32110
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 31934

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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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                  145c8ced0de02d0ad37743eb42b116e40f13e97e
baseline version:
 xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@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                           broken  
 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                    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                                broken  
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               broken  
 test-amd64-i386-rumpuserxen-i386                             blocked 
 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                                 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                                     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-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-pcipt-intel host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-xl-win7-amd64 host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)

Not pushing.

------------------------------------------------------------
commit 145c8ced0de02d0ad37743eb42b116e40f13e97e
Author: Keir Fraser <keir@xen.org>
Date:   Mon Dec 8 15:30:17 2014 +0100

    switch to write-biased r/w locks
    
    This is to improve fairness: A permanent flow of read acquires can
    otherwise lock out eventual writers indefinitely.
    
    This is CVE-2014-9065 / XSA-114.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
    master date: 2014-12-08 14:45:46 +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 Dec 10 03:40:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 03:40:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyY83-0004Hc-Rh; Wed, 10 Dec 2014 03:39:55 +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 1XyY82-0004HX-1j
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 03:39:54 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D2/5D-09842-980C7845; Wed, 10 Dec 2014 03:39:53 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418182791!14555828!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 12913 invoked from network); 10 Dec 2014 03:39:51 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 03:39:51 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 09 Dec 2014 19:39:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,549,1413270000"; d="scan'208";a="635342762"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by fmsmga001.fm.intel.com with ESMTP; 09 Dec 2014 19:39:48 -0800
Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 11:39:47 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 11:39:46 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.67]) with mapi id
	14.03.0195.001; Wed, 10 Dec 2014 11:39:45 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
	support XEN_DOMCTL_set_rdm
Thread-Index: AQHQE5h0ZLDY7ZdMpU2g0ypuvrX7qZyIH8Ag
Date: Wed, 10 Dec 2014 03:39:44 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
In-Reply-To: <20141209101111.GA75319@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@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Tuesday, December 09, 2014 6:11 PM
> 
> At 08:19 +0000 on 09 Dec (1418109561), Jan Beulich wrote:
> > Why do you always pick other than the simplest possible solution?
> 
> Jan, please don't make personal comments like this in code review.  It
> can only offend and demoralize contributors, and deter other people
> from joining in.
> 
> I understand that it can be frustrating, and I'm sure I have lashed
> out at people on-list in the past.  But remember that people who are
> new to the project need time to learn, and keep the comments to the
> code itself.
> 
> I can see that this series has been going for a long time, and is
> still getting hung up on coding style issues.  Might it be useful to
> have a round of internal review from some of the more xen-experienced
> engineers at Intel before Jan looks at it again?
> 

Thanks Tim. Some of my thoughts:

1. It's more efficient for new people to start from a small, well-defined task
in one area, and then spanning to adjacent areas gradually. Patience must 
be given by the community to help them grow;

2. Unfortunately this RMRR effort grows from original two patches (very VT-d
focused) to now v8 17 patches spanning many areas (including hypercall, mmu, 
domain builder, hvmloader, etc.), and thus imposing both long learning curve
and lots of frustrations being no achievement returned. Though having a complete
solution is desired, we need to help split the big task into step-by-step approach 
as long as:
	- the overall design is agreed
	- each step is self-contained 
	- each step won't be wasted moving forward. 
That way new people can see incremental achievements, instead of being hit 
down before final success. 

Take this RMRR for example. Maybe we can split into steps like:

	step-1: setup RMRR identify mapping in hypervisor. fail if confliction. no
user space changes
	step-2: expose RMRR knowledge to userspace and detect confliction in
domain builder and hvmloader
	step-3: reconcile e820/mmio to avoid confliction in a best effort
	step-4: miscellaneous enhancements, each can be ACK-ed individually:
		- handle guest CPU access to RMRR regions
		- handle conflicting RMRR regions
		- handle group RMRRs
		- re-enable USB device assignment

That way Tiejun can focus on a self-contained task at one time, and then observe
continuous acknowledgements for his work. We don't need to claim RMRR fully
ready in Xen until last patch is accepted, but that at least provides a way to ack
new people when working on complex features and also allow for partial usage 
on his work.

3. Maintainers sometimes didn't give definitive guidance to the new people, 
and the high-level design is not closed in the 1st place. e.g. when I thought this v8
version has everyone agreed on the design, there's another comment from Jan
about using XENMEM_set_memory_map might be better, while back to Aug.
when Tiejun raised that option the answer is "I'm not sure". Note I understand
as a maintainer he might not have definite answers for all opens. But w/o a
definitive guide new people may waste lots of effort on chasing a wrong option,
which is definitely frustrating. 

So I'd suggest for such non-trivial task for a new people, all maintainers in 
involved areas (xen, mmu, tools, vtd, etc) should first spend time to agree 
on the high level design. At that stage, let's skip the coding problems to save
both time. After agreed design, then we can help the new people to improve 
the coding to reach check-in criteria, which then becomes a converging process.

for this RMRR issue, let's close the design first, and then use staged approach
to get this patch series in.

4. Regarding to coding style, Intel will definitely help our new people internally,
and we also like all the discussion happened publicly, to also benefit from the
community, especially regarding to current scope extended out of VT-d area. 
In the meantime, if w/ above suggestions, our new people can then focus on 
incremental deliverables and then pay more attention to coding styles. 

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 Dec 10 03:40:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 03:40:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyY83-0004Hc-Rh; Wed, 10 Dec 2014 03:39:55 +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 1XyY82-0004HX-1j
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 03:39:54 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D2/5D-09842-980C7845; Wed, 10 Dec 2014 03:39:53 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418182791!14555828!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 12913 invoked from network); 10 Dec 2014 03:39:51 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 03:39:51 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 09 Dec 2014 19:39:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,549,1413270000"; d="scan'208";a="635342762"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by fmsmga001.fm.intel.com with ESMTP; 09 Dec 2014 19:39:48 -0800
Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by
	pgsmsx105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 11:39:47 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 11:39:46 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.67]) with mapi id
	14.03.0195.001; Wed, 10 Dec 2014 11:39:45 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
	support XEN_DOMCTL_set_rdm
Thread-Index: AQHQE5h0ZLDY7ZdMpU2g0ypuvrX7qZyIH8Ag
Date: Wed, 10 Dec 2014 03:39:44 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
In-Reply-To: <20141209101111.GA75319@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@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Tuesday, December 09, 2014 6:11 PM
> 
> At 08:19 +0000 on 09 Dec (1418109561), Jan Beulich wrote:
> > Why do you always pick other than the simplest possible solution?
> 
> Jan, please don't make personal comments like this in code review.  It
> can only offend and demoralize contributors, and deter other people
> from joining in.
> 
> I understand that it can be frustrating, and I'm sure I have lashed
> out at people on-list in the past.  But remember that people who are
> new to the project need time to learn, and keep the comments to the
> code itself.
> 
> I can see that this series has been going for a long time, and is
> still getting hung up on coding style issues.  Might it be useful to
> have a round of internal review from some of the more xen-experienced
> engineers at Intel before Jan looks at it again?
> 

Thanks Tim. Some of my thoughts:

1. It's more efficient for new people to start from a small, well-defined task
in one area, and then spanning to adjacent areas gradually. Patience must 
be given by the community to help them grow;

2. Unfortunately this RMRR effort grows from original two patches (very VT-d
focused) to now v8 17 patches spanning many areas (including hypercall, mmu, 
domain builder, hvmloader, etc.), and thus imposing both long learning curve
and lots of frustrations being no achievement returned. Though having a complete
solution is desired, we need to help split the big task into step-by-step approach 
as long as:
	- the overall design is agreed
	- each step is self-contained 
	- each step won't be wasted moving forward. 
That way new people can see incremental achievements, instead of being hit 
down before final success. 

Take this RMRR for example. Maybe we can split into steps like:

	step-1: setup RMRR identify mapping in hypervisor. fail if confliction. no
user space changes
	step-2: expose RMRR knowledge to userspace and detect confliction in
domain builder and hvmloader
	step-3: reconcile e820/mmio to avoid confliction in a best effort
	step-4: miscellaneous enhancements, each can be ACK-ed individually:
		- handle guest CPU access to RMRR regions
		- handle conflicting RMRR regions
		- handle group RMRRs
		- re-enable USB device assignment

That way Tiejun can focus on a self-contained task at one time, and then observe
continuous acknowledgements for his work. We don't need to claim RMRR fully
ready in Xen until last patch is accepted, but that at least provides a way to ack
new people when working on complex features and also allow for partial usage 
on his work.

3. Maintainers sometimes didn't give definitive guidance to the new people, 
and the high-level design is not closed in the 1st place. e.g. when I thought this v8
version has everyone agreed on the design, there's another comment from Jan
about using XENMEM_set_memory_map might be better, while back to Aug.
when Tiejun raised that option the answer is "I'm not sure". Note I understand
as a maintainer he might not have definite answers for all opens. But w/o a
definitive guide new people may waste lots of effort on chasing a wrong option,
which is definitely frustrating. 

So I'd suggest for such non-trivial task for a new people, all maintainers in 
involved areas (xen, mmu, tools, vtd, etc) should first spend time to agree 
on the high level design. At that stage, let's skip the coding problems to save
both time. After agreed design, then we can help the new people to improve 
the coding to reach check-in criteria, which then becomes a converging process.

for this RMRR issue, let's close the design first, and then use staged approach
to get this patch series in.

4. Regarding to coding style, Intel will definitely help our new people internally,
and we also like all the discussion happened publicly, to also benefit from the
community, especially regarding to current scope extended out of VT-d area. 
In the meantime, if w/ above suggestions, our new people can then focus on 
incremental deliverables and then pay more attention to coding styles. 

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 Dec 10 03:47:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 03: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 1XyYF1-0004gy-P8; Wed, 10 Dec 2014 03:47:07 +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 1XyYF0-0004gt-4e
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 03:47:06 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	F7/9E-05632-832C7845; Wed, 10 Dec 2014 03:47:04 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418183221!9778532!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 10770 invoked from network); 10 Dec 2014 03:47:03 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 03:47:03 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 20:47:00 -0700
Message-Id: <548832AD0200006600082E25@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 20:46:53 -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>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
	<20141208111214.GC17128@zion.uk.xensource.com>
	<5486F36502000066000825D5@soto.provo.novell.com>
	<1418123518.14361.20.camel@citrix.com>
In-Reply-To: <1418123518.14361.20.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, 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 12/9/2014 at 07:11 PM, in message <1418123518.14361.20.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Mon, 2014-12-08 at 22:04 -0700, Chun Yan Liu wrote: 
> > Partly. At least for domain disk snapshot create/delete, I prefer using 
> > qmp commands instead of calling qemu-img one by one. Using qmp 
> > commands, libvirt will need libxl's help. Of course, if libxl doesn't 
> > supply that, libvirt can call qemu-img to each disk one by one, 
> > not preferred but can do. 
>  
> You can't use qmp unless the domain is active, for an inactive domain 
> there is no qemu to talk to, so you have to use qemu-img anyway in that 
> case. Does libvirt not have existing code to do all this sort of thing? 
> (I thought so, but it turns out I may be wrong, see below). 

No. Even inlibvirt/qemu_driver (for kvm), it does the work itself through
qemu monitor commands.

>  
> And for an active domain I expect that *must* use qmp, since it seems 
> unlikely that you can go around changing things under the feet of an 
> active process (maybe I'm wrong?).

For active domain, I tried 'qemu-img snapshot' after pausing a domain,
the commands succeeded. But I also think using qmp commands is better
since qemu supplies transaction qmp, it avoids the trouble to roll back
status when using qemu-img to do disk snapshot one by one but only part of
disks succeed.

So, if disk snapshot functions can be provided to both libvirt and xl usage,
it's very helpful to libvirt side. In this way, I may prefer to put disk snapshot
functions to libxlu.

>  
> > > > Following the constraint that it's better NOT to supply disk snapshot  
> > > > functions in libxl, then we let xl and libvirt do that by themselve  
> > > > separately, that's OK.  
> > > >   
> > > > Then I think NO new API needs to be exported in libxl, since:  
> > > > * saving/restoring memory, there are already APIs.  
> > >   
> > > The principle is that if existing API doesn't work good enough for you  
> > > we will consider adding a new one.  
> > >   
> > > We probably need a new API. If you want to do a live snapshot, we would  
> > > need to notify xl that we are in the middle of pausing and resuming a  
> > > domain.   
> >  
> > This is where we discussed a lot. Do we really need 
> > libxl_domain_snapshot_create API? or does xl can do the work? 
> >  
> > Even for live snapshot, after calling libxl_domain_suspend with LIVE flags, 
> > memory is saved and domain is paused. xl then can call disk snapshot 
> > functions to finish disk snapshots, after all of that, call  
> libxl_domain_unpause 
> > to unpause the domain. So I don't think xl has any trouble to do that. 
> > In case there is some misunderstanding, please point out. 
>  
> My mistake, I incorrectly remembered that libxl_domain_suspend would 
> destroy (for save or migate) or resume (for checkpoint) the guest before 
> returning. Having refreshed my memory I see that you are correct: it 
> returns with the domain paused and it is up to the toolstack to resume 
> or destroy it as it wishes. Sorry for the confusion. 
>  
> Given that it does seem like the toolstack could indeed take the 
> disksnapshots itself without an additional API. 
>  
> > > However the current architecture for libvirt to use libxl is like  
> > >   
> > >   libvirt  
> > >   libxl  
> > >   [other lower level stuffs]  
> > >   
> > > So implementing snapshot management in xl cannot work for you either.  
> > > It's not part of the current architecture. 
>  
> This is correct, xl should not be involved in a libvirt control stack, 
> it is orthogonal. 
>  
> > You are right. I understand you are trying to suggest a way to ease the  
> job. 
> > Here just to make clear this way is really better and finally acceptable?  
> :-) 
> > Just IMO, I think xl snapshot-list is wanted, that means managing snapshots 
> > in xl is needed. 
>  
> The xl idiom is that you do this sort of operation with existing CLI 
> commands e.g. ls /var/lib/vm-images/*.qcow2, lvs, qemu-img etc. 
>  
> Adding snapshot-list to xl would be a whole load of work to create a 
> bunch of infrastructure which you do not need to do. 
>  
> My understanding was that your primary aim here was to enable snapshots 
> via libvirt and that xl support was just a nice to have. Is that right? 

We hope both :-)

Libvirt side already has some codes as I know and hopes to integrate with
libxl to enable snapshots. Of course the two toolstacks can have some
differences in commands, that's OK.

Libvirt side, to use unified virsh commands, it will supply
snapshot-create/delete/revert/list.

Xl side, if it's better to supply snapshot-create/revert, we can implement
like that. Then it IS much easier since no need to manage snapshots in xl,
then no save/retrieve json file things and no snapshot chain things. Do
we want/decide to follow this?

>  
> > > Not that I'm against the idea of managing domain snapshot in xl, I'm  
> > > trying to reduce workload here.  
> > >   
> > > > > The   
> > > > > downside is that now xl and libvirt are disconnected, but I think it's   
> > > > > fine.  
> > > >   
> > > > Two things here:  
> > > > 1. connect xl and libvirt, then will need to manage snapshot info in  
> libxl   
> > > (or  
> > > >     libxlu) That's not preferred since the initial design. This is not  
> the   
> > > point  
> > > >     we discuss here.  
> > > > 2. for xl only, list snapshots and delete snapshots, also need to manage  
> > > >     snapshot info (in xl)  
> > > >   
> > > > Considering manage snapshot info in xl, only question is about idl and  
> > > > gentypes.py, expected structure is as following and expected to be saved  
> > > > into json file, but it contains xl namespace and libxl namespace things,  
> > > > gentypes.py will have problem. Better ideas?  
> > > >   
> > > > typedef struct xl_domain_snapshot {  
> > > >     char * name;  
> > > >     char * description;  
> > > >     uint64_t creation_time;  
> > > >     char * memory_path;  
> > > >     int num_disks;  
> > > >     libxl_disk_snapshot *disks;  
> > > >     char *parent;  
> > > >     bool *current;  
> > > > } xl_domain_snapshot;  
> > > >   
> > >   
> > > The libxl_disk_snapshot suggests that you still want storage management  
> > > inside libxl, which should probably be in libxlu?  
> >  
> > Yeah. I may put it in libxlu. 
>  
> This depends on who the consumers of this datastructure are: 
>  
> If xl only -> put it in xl itself. 
> If libvirt+xl -> put it in libxlu. 
>  
> My understanding was that libvirt already has data structures for 
> dealing with snapshots, but this was based entirely on the commands 
> listed by: 
>         virsh help | grep -E pool-\|snapshot- 
> which seemed to me to be pretty feature rich and suggested that libvirt 
> has a great deal of support for storage and snapshot management already. 
>  

Oh, I didn't say clearly. Here we  mean libxl_disk_snapshot should be
libxlu_disk_snapshot, that is, disk snapshot functions better in libxlu.
Not mean xl_domain_snapshot. If managing snapshots, it will be in xl.
Libvirt has its own data structures about managing domain snapshots.

Thanks,
Chunyan

> If libvirt already has generic infrastructure for managing snapshots 
> this then IMHO you should use it, not reimplement it on the Xen side 
> (whether in libxl, libxlu or xl), the additions to Xen should be limited 
> to providing the underlying functionality which libvirt's generic code 
> requires from the backend. 
>  
> However, Wei has suggested to me that perhaps libvirt's snapshotting 
> capabilities are not as generic internally as I might have imaged and 
> that it is up to each backend driver to reinvent things, is that true? 
>  
> If Wei's suggestion is correct then it may turn out that it is useful to 
> put some of the new generic code which you would need to write into 
> libxlu. 
>  
> Ian. 
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 03:47:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 03: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 1XyYF1-0004gy-P8; Wed, 10 Dec 2014 03:47:07 +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 1XyYF0-0004gt-4e
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 03:47:06 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	F7/9E-05632-832C7845; Wed, 10 Dec 2014 03:47:04 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418183221!9778532!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 10770 invoked from network); 10 Dec 2014 03:47:03 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 03:47:03 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Tue, 09 Dec 2014 20:47:00 -0700
Message-Id: <548832AD0200006600082E25@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 09 Dec 2014 20:46:53 -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>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
	<20141208111214.GC17128@zion.uk.xensource.com>
	<5486F36502000066000825D5@soto.provo.novell.com>
	<1418123518.14361.20.camel@citrix.com>
In-Reply-To: <1418123518.14361.20.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, 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 12/9/2014 at 07:11 PM, in message <1418123518.14361.20.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Mon, 2014-12-08 at 22:04 -0700, Chun Yan Liu wrote: 
> > Partly. At least for domain disk snapshot create/delete, I prefer using 
> > qmp commands instead of calling qemu-img one by one. Using qmp 
> > commands, libvirt will need libxl's help. Of course, if libxl doesn't 
> > supply that, libvirt can call qemu-img to each disk one by one, 
> > not preferred but can do. 
>  
> You can't use qmp unless the domain is active, for an inactive domain 
> there is no qemu to talk to, so you have to use qemu-img anyway in that 
> case. Does libvirt not have existing code to do all this sort of thing? 
> (I thought so, but it turns out I may be wrong, see below). 

No. Even inlibvirt/qemu_driver (for kvm), it does the work itself through
qemu monitor commands.

>  
> And for an active domain I expect that *must* use qmp, since it seems 
> unlikely that you can go around changing things under the feet of an 
> active process (maybe I'm wrong?).

For active domain, I tried 'qemu-img snapshot' after pausing a domain,
the commands succeeded. But I also think using qmp commands is better
since qemu supplies transaction qmp, it avoids the trouble to roll back
status when using qemu-img to do disk snapshot one by one but only part of
disks succeed.

So, if disk snapshot functions can be provided to both libvirt and xl usage,
it's very helpful to libvirt side. In this way, I may prefer to put disk snapshot
functions to libxlu.

>  
> > > > Following the constraint that it's better NOT to supply disk snapshot  
> > > > functions in libxl, then we let xl and libvirt do that by themselve  
> > > > separately, that's OK.  
> > > >   
> > > > Then I think NO new API needs to be exported in libxl, since:  
> > > > * saving/restoring memory, there are already APIs.  
> > >   
> > > The principle is that if existing API doesn't work good enough for you  
> > > we will consider adding a new one.  
> > >   
> > > We probably need a new API. If you want to do a live snapshot, we would  
> > > need to notify xl that we are in the middle of pausing and resuming a  
> > > domain.   
> >  
> > This is where we discussed a lot. Do we really need 
> > libxl_domain_snapshot_create API? or does xl can do the work? 
> >  
> > Even for live snapshot, after calling libxl_domain_suspend with LIVE flags, 
> > memory is saved and domain is paused. xl then can call disk snapshot 
> > functions to finish disk snapshots, after all of that, call  
> libxl_domain_unpause 
> > to unpause the domain. So I don't think xl has any trouble to do that. 
> > In case there is some misunderstanding, please point out. 
>  
> My mistake, I incorrectly remembered that libxl_domain_suspend would 
> destroy (for save or migate) or resume (for checkpoint) the guest before 
> returning. Having refreshed my memory I see that you are correct: it 
> returns with the domain paused and it is up to the toolstack to resume 
> or destroy it as it wishes. Sorry for the confusion. 
>  
> Given that it does seem like the toolstack could indeed take the 
> disksnapshots itself without an additional API. 
>  
> > > However the current architecture for libvirt to use libxl is like  
> > >   
> > >   libvirt  
> > >   libxl  
> > >   [other lower level stuffs]  
> > >   
> > > So implementing snapshot management in xl cannot work for you either.  
> > > It's not part of the current architecture. 
>  
> This is correct, xl should not be involved in a libvirt control stack, 
> it is orthogonal. 
>  
> > You are right. I understand you are trying to suggest a way to ease the  
> job. 
> > Here just to make clear this way is really better and finally acceptable?  
> :-) 
> > Just IMO, I think xl snapshot-list is wanted, that means managing snapshots 
> > in xl is needed. 
>  
> The xl idiom is that you do this sort of operation with existing CLI 
> commands e.g. ls /var/lib/vm-images/*.qcow2, lvs, qemu-img etc. 
>  
> Adding snapshot-list to xl would be a whole load of work to create a 
> bunch of infrastructure which you do not need to do. 
>  
> My understanding was that your primary aim here was to enable snapshots 
> via libvirt and that xl support was just a nice to have. Is that right? 

We hope both :-)

Libvirt side already has some codes as I know and hopes to integrate with
libxl to enable snapshots. Of course the two toolstacks can have some
differences in commands, that's OK.

Libvirt side, to use unified virsh commands, it will supply
snapshot-create/delete/revert/list.

Xl side, if it's better to supply snapshot-create/revert, we can implement
like that. Then it IS much easier since no need to manage snapshots in xl,
then no save/retrieve json file things and no snapshot chain things. Do
we want/decide to follow this?

>  
> > > Not that I'm against the idea of managing domain snapshot in xl, I'm  
> > > trying to reduce workload here.  
> > >   
> > > > > The   
> > > > > downside is that now xl and libvirt are disconnected, but I think it's   
> > > > > fine.  
> > > >   
> > > > Two things here:  
> > > > 1. connect xl and libvirt, then will need to manage snapshot info in  
> libxl   
> > > (or  
> > > >     libxlu) That's not preferred since the initial design. This is not  
> the   
> > > point  
> > > >     we discuss here.  
> > > > 2. for xl only, list snapshots and delete snapshots, also need to manage  
> > > >     snapshot info (in xl)  
> > > >   
> > > > Considering manage snapshot info in xl, only question is about idl and  
> > > > gentypes.py, expected structure is as following and expected to be saved  
> > > > into json file, but it contains xl namespace and libxl namespace things,  
> > > > gentypes.py will have problem. Better ideas?  
> > > >   
> > > > typedef struct xl_domain_snapshot {  
> > > >     char * name;  
> > > >     char * description;  
> > > >     uint64_t creation_time;  
> > > >     char * memory_path;  
> > > >     int num_disks;  
> > > >     libxl_disk_snapshot *disks;  
> > > >     char *parent;  
> > > >     bool *current;  
> > > > } xl_domain_snapshot;  
> > > >   
> > >   
> > > The libxl_disk_snapshot suggests that you still want storage management  
> > > inside libxl, which should probably be in libxlu?  
> >  
> > Yeah. I may put it in libxlu. 
>  
> This depends on who the consumers of this datastructure are: 
>  
> If xl only -> put it in xl itself. 
> If libvirt+xl -> put it in libxlu. 
>  
> My understanding was that libvirt already has data structures for 
> dealing with snapshots, but this was based entirely on the commands 
> listed by: 
>         virsh help | grep -E pool-\|snapshot- 
> which seemed to me to be pretty feature rich and suggested that libvirt 
> has a great deal of support for storage and snapshot management already. 
>  

Oh, I didn't say clearly. Here we  mean libxl_disk_snapshot should be
libxlu_disk_snapshot, that is, disk snapshot functions better in libxlu.
Not mean xl_domain_snapshot. If managing snapshots, it will be in xl.
Libvirt has its own data structures about managing domain snapshots.

Thanks,
Chunyan

> If libvirt already has generic infrastructure for managing snapshots 
> this then IMHO you should use it, not reimplement it on the Xen side 
> (whether in libxl, libxlu or xl), the additions to Xen should be limited 
> to providing the underlying functionality which libvirt's generic code 
> requires from the backend. 
>  
> However, Wei has suggested to me that perhaps libvirt's snapshotting 
> capabilities are not as generic internally as I might have imaged and 
> that it is up to each backend driver to reinvent things, is that true? 
>  
> If Wei's suggestion is correct then it may turn out that it is useful to 
> put some of the new generic code which you would need to write into 
> libxlu. 
>  
> Ian. 
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 03:54:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 03: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 1XyYLs-00055J-Pr; Wed, 10 Dec 2014 03:54:12 +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 1XyYLs-00055E-1g
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 03:54:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4C/52-25276-3E3C7845; Wed, 10 Dec 2014 03:54:11 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418183648!14572872!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11080 invoked from network); 10 Dec 2014 03:54:10 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2014 03:54:10 -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
	sBA3s5RB001834
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 9 Dec 2014 22:54:05 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sBA3s5EI001832;
	Tue, 9 Dec 2014 22:54:05 -0500
Date: Tue, 9 Dec 2014 23:54:05 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Message-ID: <20141210035405.GA1511@andromeda.dapyr.net>
References: <CAOqnZH5=Jk+e0M_MdZFYhu4ecric6biy3wgtyb9c63wbYvDAAg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOqnZH5=Jk+e0M_MdZFYhu4ecric6biy3wgtyb9c63wbYvDAAg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: Sarah Conway <sconway@linuxfoundation.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Konrad R Wilk's Xen Project Committer Status
	confirmed (+ some governance policy concerns)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 11:51:27AM +0000, Lars Kurth wrote:
> Hi all,
> 
> I wanted to to summarize the outcome of the vote for Konrad's committer
> status. We had 4 votes in favor and one abstained. Which means Konrad is
> confirmed.

Thank you!

I wished I had an acceptance speech prepared!! But in lieu of that I
want to thank for the trust and the regard the community has of me.

Again, thank you!

I am quite thankfull and am thrilled to be able to make a difference!
> 
> A number of concerns were raised, e.g. shouldn't other maintainers (e.g.
> George Dunlap as past release manager, or Stefano Stabellini) also be
> nominated as a committer. This could be relatively easily fixed, but
> requires one of the other committers to make a nomination.
> 
> Concerns about the definition of the committer role were raised. In
> summary, the governance policy today defines the committer role purely in
> terms of a maintainer with write access. However the role is actually also
> about being entrusted with the safety, governance and the stewardship of
> the project. This is implied in the governance document, but not spelled
> out.
> 
> Tim Deegan, described the issue quite well:
> 
> "It's clear from the governance document that the committers are expected
> to resolve disagreements that the maintainers and contributors can't sort
> out between themselves.
> 
> So maybe we should have a discussion about separating the roles of
> committer-with-tree-access and committer-for-governance?  For me, the set
> of people who should be settling disputes is a subset of the set of people
> I would trust with push access to xen.git. IOW I'm a little wary of
> creating a group of people who make technical decisions but aren't
> themselves technical."
> 
> This concern does not apply to Konrad, who has excellent standing in the
> community and has been actively involved in design, development and review
> inside the hypervisor.

Thank you for those kind words!
> 
> We don't need to resolve this issue before the 4.5 release. I think we
> should roll this up with a general review of our governance in spring. When
> I wrote up the contributor training document (see
> http://www.slideshare.net/xen_com_mgr/xen-project-contributor-training-part-2-processes-and-conventions-v10),
> it became clear that there are a number of conventions that are not well
> documented. These don't necessarily need to be part of the governance, but
> the governance document should probably link to some of our conventions.

<nods>
> 
> 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 Wed Dec 10 03:54:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 03: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 1XyYLs-00055J-Pr; Wed, 10 Dec 2014 03:54:12 +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 1XyYLs-00055E-1g
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 03:54:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4C/52-25276-3E3C7845; Wed, 10 Dec 2014 03:54:11 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418183648!14572872!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11080 invoked from network); 10 Dec 2014 03:54:10 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2014 03:54:10 -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
	sBA3s5RB001834
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 9 Dec 2014 22:54:05 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id sBA3s5EI001832;
	Tue, 9 Dec 2014 22:54:05 -0500
Date: Tue, 9 Dec 2014 23:54:05 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Message-ID: <20141210035405.GA1511@andromeda.dapyr.net>
References: <CAOqnZH5=Jk+e0M_MdZFYhu4ecric6biy3wgtyb9c63wbYvDAAg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOqnZH5=Jk+e0M_MdZFYhu4ecric6biy3wgtyb9c63wbYvDAAg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: Sarah Conway <sconway@linuxfoundation.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Konrad R Wilk's Xen Project Committer Status
	confirmed (+ some governance policy concerns)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 11:51:27AM +0000, Lars Kurth wrote:
> Hi all,
> 
> I wanted to to summarize the outcome of the vote for Konrad's committer
> status. We had 4 votes in favor and one abstained. Which means Konrad is
> confirmed.

Thank you!

I wished I had an acceptance speech prepared!! But in lieu of that I
want to thank for the trust and the regard the community has of me.

Again, thank you!

I am quite thankfull and am thrilled to be able to make a difference!
> 
> A number of concerns were raised, e.g. shouldn't other maintainers (e.g.
> George Dunlap as past release manager, or Stefano Stabellini) also be
> nominated as a committer. This could be relatively easily fixed, but
> requires one of the other committers to make a nomination.
> 
> Concerns about the definition of the committer role were raised. In
> summary, the governance policy today defines the committer role purely in
> terms of a maintainer with write access. However the role is actually also
> about being entrusted with the safety, governance and the stewardship of
> the project. This is implied in the governance document, but not spelled
> out.
> 
> Tim Deegan, described the issue quite well:
> 
> "It's clear from the governance document that the committers are expected
> to resolve disagreements that the maintainers and contributors can't sort
> out between themselves.
> 
> So maybe we should have a discussion about separating the roles of
> committer-with-tree-access and committer-for-governance?  For me, the set
> of people who should be settling disputes is a subset of the set of people
> I would trust with push access to xen.git. IOW I'm a little wary of
> creating a group of people who make technical decisions but aren't
> themselves technical."
> 
> This concern does not apply to Konrad, who has excellent standing in the
> community and has been actively involved in design, development and review
> inside the hypervisor.

Thank you for those kind words!
> 
> We don't need to resolve this issue before the 4.5 release. I think we
> should roll this up with a general review of our governance in spring. When
> I wrote up the contributor training document (see
> http://www.slideshare.net/xen_com_mgr/xen-project-contributor-training-part-2-processes-and-conventions-v10),
> it became clear that there are a number of conventions that are not well
> documented. These don't necessarily need to be part of the governance, but
> the governance document should probably link to some of our conventions.

<nods>
> 
> 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 Wed Dec 10 04:19:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 04: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 1XyYjt-00073b-V7; Wed, 10 Dec 2014 04:19:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyYjs-00073W-QZ
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 04:19:01 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	16/03-18267-3B9C7845; Wed, 10 Dec 2014 04:18:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418185131!7781656!1
X-Originating-IP: [66.165.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 11073 invoked from network); 10 Dec 2014 04:18:58 -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 Dec 2014 04:18:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,549,1413244800"; d="scan'208";a="202254972"
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.210.2; Tue, 9 Dec 2014 23:18: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 1XyYjf-0005aD-36;
	Wed, 10 Dec 2014 04:18:47 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyYje-0002Bk-Oy;
	Wed, 10 Dec 2014 04:18:46 +0000
Date: Wed, 10 Dec 2014 04:18:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32172-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] 32172: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32172 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32172/

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. 26303
 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail in 32144 REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl            5 xen-boot                    fail pass in 32144

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 in 32144 like 26303

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1)             blocked n/a
 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  1 build-check(1)               blocked  n/a
 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      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf      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           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-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-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-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-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-pair         1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 32144 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 32144 never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 32144 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 32144 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 32144 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop      fail in 32144 never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          blocked 
 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                    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-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-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 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-armhf-armhf-libvirt                                     fail    
 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 34178 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 Dec 10 04:19:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 04: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 1XyYjt-00073b-V7; Wed, 10 Dec 2014 04:19:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyYjs-00073W-QZ
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 04:19:01 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	16/03-18267-3B9C7845; Wed, 10 Dec 2014 04:18:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418185131!7781656!1
X-Originating-IP: [66.165.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 11073 invoked from network); 10 Dec 2014 04:18:58 -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 Dec 2014 04:18:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,549,1413244800"; d="scan'208";a="202254972"
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.210.2; Tue, 9 Dec 2014 23:18: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 1XyYjf-0005aD-36;
	Wed, 10 Dec 2014 04:18:47 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyYje-0002Bk-Oy;
	Wed, 10 Dec 2014 04:18:46 +0000
Date: Wed, 10 Dec 2014 04:18:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32172-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] 32172: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32172 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32172/

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. 26303
 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail in 32144 REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl            5 xen-boot                    fail pass in 32144

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 in 32144 like 26303

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1)             blocked n/a
 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  1 build-check(1)               blocked  n/a
 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      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-sedf      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           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-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-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-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-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-pair         1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 32144 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 32144 never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 32144 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 32144 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 32144 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop      fail in 32144 never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          blocked 
 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                    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-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-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 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-armhf-armhf-libvirt                                     fail    
 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 34178 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 Dec 10 04:48:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 04:48:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyZBq-00083C-3m; Wed, 10 Dec 2014 04:47:54 +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 1XyZBp-000833-3w
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 04:47:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B1/04-25276-870D7845; Wed, 10 Dec 2014 04:47:52 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418186871!14522823!1
X-Originating-IP: [209.85.216.47]
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 24516 invoked from network); 10 Dec 2014 04:47:51 -0000
Received: from mail-qa0-f47.google.com (HELO mail-qa0-f47.google.com)
	(209.85.216.47)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 04:47:51 -0000
Received: by mail-qa0-f47.google.com with SMTP id s7so1469445qap.20
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 20:47: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=cOAcZbua8OsLCFXRjgqqvNi+QxVyr579zpPum0VwZZU=;
	b=cT/g8M+4NsNZIb1aEbSBhDkLCCvx6qayqgWsKSJUGTVqPw5+Z4F+QDRjSeqmGkSqrD
	fD+D0bp8ZaMz5HOTNeVx/d9POc3iu+ngh1gD8jbrQ1GlsfuuP4cX8mUKvEy0J89BvuVA
	RL8ZhUrpeeBrIw7GGCPxLX3/2+WZSwRzNgHbFy48kUvTHMDF1NKNFHq7A2zfcRHi1Dns
	hwUKR69FBQ61K6eGZ15Bh9jCO1YG2WtQKEXNKsNF2ImfpA+dHiS4IKlanSSyGRTFch4C
	TDtodKqHl/rySAMR6vcVjZa4SLDKMGR/00s0CtF/1uHGaPJtLbYUBE7lRoBJtqpVT6W/
	8CzA==
MIME-Version: 1.0
X-Received: by 10.224.88.8 with SMTP id y8mr4350756qal.47.1418186870794; Tue,
	09 Dec 2014 20:47:50 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Tue, 9 Dec 2014 20:47:50 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1412081346150.30971@kaball.uk.xensource.com>
References: <CAAiw7Jm+aH7n4qOZcJQ4Wc+ocEugvPq+RWYHemwhOLmcd5+EGw@mail.gmail.com>
	<1418034110.30016.1.camel@citrix.com>
	<alpine.DEB.2.02.1412081346150.30971@kaball.uk.xensource.com>
Date: Tue, 9 Dec 2014 20:47:50 -0800
Message-ID: <CAAiw7J=ehEiXiLgcueTZCgXSAowEcGBS1LShvCGVfTMY1yCPqA@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, xen-users@lists.xen.org,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Steps to run XenServer on 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 8 December 2014 at 05:46, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 8 Dec 2014, Ian Campbell wrote:
>> On Fri, 2014-12-05 at 15:15 -0800, manish jaggi wrote:
>> > Hi,
>> >
>> > I am trying to find a tutorial to jumpstart installing XenServer / XCP
>> > on an ARM 64bit platform.
>> > Could the mailing list help.
>>
>> TTBOMK there has been no work done on an ARM64 port of XenServer/XCP at
>> this time and only minimal work done on ARM generally. If you want to
>> get this working then I think you are looking at doing a port (i.e. a
>> bunch of development work) not simply following an installation
>> tutorial.
>>
>> However XenServer/XCP is developed separately from XenProject as Open
>> XenServer over at xenserver.org, I suggest one of the lists over there
>> would be the best place to start a discussion of a new arm64 port of
>> xenserver.
>
Just for my curiosity is XenServer/XCP on ARMv8 important for Citrix ?
> I think you might want to subscribe to xs-devel@lists.xenserver.org and
> start the discussion there, see:
>
> http://xenserver.org/discuss-virtualization/mailing-lists.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 04:48:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 04:48:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyZBq-00083C-3m; Wed, 10 Dec 2014 04:47:54 +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 1XyZBp-000833-3w
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 04:47:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B1/04-25276-870D7845; Wed, 10 Dec 2014 04:47:52 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418186871!14522823!1
X-Originating-IP: [209.85.216.47]
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 24516 invoked from network); 10 Dec 2014 04:47:51 -0000
Received: from mail-qa0-f47.google.com (HELO mail-qa0-f47.google.com)
	(209.85.216.47)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 04:47:51 -0000
Received: by mail-qa0-f47.google.com with SMTP id s7so1469445qap.20
	for <xen-devel@lists.xenproject.org>;
	Tue, 09 Dec 2014 20:47: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=cOAcZbua8OsLCFXRjgqqvNi+QxVyr579zpPum0VwZZU=;
	b=cT/g8M+4NsNZIb1aEbSBhDkLCCvx6qayqgWsKSJUGTVqPw5+Z4F+QDRjSeqmGkSqrD
	fD+D0bp8ZaMz5HOTNeVx/d9POc3iu+ngh1gD8jbrQ1GlsfuuP4cX8mUKvEy0J89BvuVA
	RL8ZhUrpeeBrIw7GGCPxLX3/2+WZSwRzNgHbFy48kUvTHMDF1NKNFHq7A2zfcRHi1Dns
	hwUKR69FBQ61K6eGZ15Bh9jCO1YG2WtQKEXNKsNF2ImfpA+dHiS4IKlanSSyGRTFch4C
	TDtodKqHl/rySAMR6vcVjZa4SLDKMGR/00s0CtF/1uHGaPJtLbYUBE7lRoBJtqpVT6W/
	8CzA==
MIME-Version: 1.0
X-Received: by 10.224.88.8 with SMTP id y8mr4350756qal.47.1418186870794; Tue,
	09 Dec 2014 20:47:50 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Tue, 9 Dec 2014 20:47:50 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1412081346150.30971@kaball.uk.xensource.com>
References: <CAAiw7Jm+aH7n4qOZcJQ4Wc+ocEugvPq+RWYHemwhOLmcd5+EGw@mail.gmail.com>
	<1418034110.30016.1.camel@citrix.com>
	<alpine.DEB.2.02.1412081346150.30971@kaball.uk.xensource.com>
Date: Tue, 9 Dec 2014 20:47:50 -0800
Message-ID: <CAAiw7J=ehEiXiLgcueTZCgXSAowEcGBS1LShvCGVfTMY1yCPqA@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, xen-users@lists.xen.org,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Steps to run XenServer on 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 8 December 2014 at 05:46, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 8 Dec 2014, Ian Campbell wrote:
>> On Fri, 2014-12-05 at 15:15 -0800, manish jaggi wrote:
>> > Hi,
>> >
>> > I am trying to find a tutorial to jumpstart installing XenServer / XCP
>> > on an ARM 64bit platform.
>> > Could the mailing list help.
>>
>> TTBOMK there has been no work done on an ARM64 port of XenServer/XCP at
>> this time and only minimal work done on ARM generally. If you want to
>> get this working then I think you are looking at doing a port (i.e. a
>> bunch of development work) not simply following an installation
>> tutorial.
>>
>> However XenServer/XCP is developed separately from XenProject as Open
>> XenServer over at xenserver.org, I suggest one of the lists over there
>> would be the best place to start a discussion of a new arm64 port of
>> xenserver.
>
Just for my curiosity is XenServer/XCP on ARMv8 important for Citrix ?
> I think you might want to subscribe to xs-devel@lists.xenserver.org and
> start the discussion there, see:
>
> http://xenserver.org/discuss-virtualization/mailing-lists.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 04:59:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 04:59:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyZMS-0000ET-UY; Wed, 10 Dec 2014 04:58: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 1XyZMR-0000EO-HQ
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 04:58:51 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	5C/1F-09284-A03D7845; Wed, 10 Dec 2014 04:58:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418187526!12238938!1
X-Originating-IP: [66.165.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 24922 invoked from network); 10 Dec 2014 04:58:47 -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;
	10 Dec 2014 04:58:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,550,1413244800"; d="scan'208";a="202264240"
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.210.2; Tue, 9 Dec 2014 23:58: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 1XyZLo-0005m8-Bx;
	Wed, 10 Dec 2014 04:58:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyZLo-0003GB-6c;
	Wed, 10 Dec 2014 04:58:12 +0000
Date: Wed, 10 Dec 2014 04:58:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32171-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] 32171: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32171 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32171/

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-qemut-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 31241
 test-amd64-i386-xl-qemut-debianhvm-amd64 13 guest-localmigrate/x10 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-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-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 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-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-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-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                b2776bf7149bddd1f4161f14f79520f17fc1d71d
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
736 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                     fail    
 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                         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 32613 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 Dec 10 04:59:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 04:59:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyZMS-0000ET-UY; Wed, 10 Dec 2014 04:58: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 1XyZMR-0000EO-HQ
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 04:58:51 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	5C/1F-09284-A03D7845; Wed, 10 Dec 2014 04:58:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418187526!12238938!1
X-Originating-IP: [66.165.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 24922 invoked from network); 10 Dec 2014 04:58:47 -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;
	10 Dec 2014 04:58:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,550,1413244800"; d="scan'208";a="202264240"
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.210.2; Tue, 9 Dec 2014 23:58: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 1XyZLo-0005m8-Bx;
	Wed, 10 Dec 2014 04:58:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyZLo-0003GB-6c;
	Wed, 10 Dec 2014 04:58:12 +0000
Date: Wed, 10 Dec 2014 04:58:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32171-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] 32171: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32171 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32171/

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-qemut-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 31241
 test-amd64-i386-xl-qemut-debianhvm-amd64 13 guest-localmigrate/x10 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-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-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 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-vcpus1 14 guest-stop               fail never pass
 test-amd64-amd64-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-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                b2776bf7149bddd1f4161f14f79520f17fc1d71d
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
736 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                     fail    
 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                         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 32613 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 Dec 10 05:07:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 05:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyZUs-0000sJ-VX; Wed, 10 Dec 2014 05:07:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XyZUs-0000sE-Jm
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 05:07:34 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	B7/40-02957-615D7845; Wed, 10 Dec 2014 05:07:34 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418188052!14091376!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 9223 invoked from network); 10 Dec 2014 05:07:33 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-8.tower-27.messagelabs.com with SMTP;
	10 Dec 2014 05:07:33 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 09 Dec 2014 21:07:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="427197635"
Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103])
	by FMSMGA003.fm.intel.com with ESMTP; 09 Dec 2014 20:56:47 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 13:07:26 +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; Wed, 10 Dec 2014 13:07:24 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
Thread-Topic: [PATCH v2] VMX: don't allow PVH to reach handle_mmio()
Thread-Index: AQHQEsdNCDzJbkWENU+RaLo5B23uMZyISLzA
Date: Wed, 10 Dec 2014 05:07:23 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126115014@SHSMSX101.ccr.corp.intel.com>
References: <54857995020000780004DA2D@mail.emea.novell.com>
In-Reply-To: <54857995020000780004DA2D@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: "Dong, Eddie" <eddie.dong@intel.com>, "Nakajima,
	Jun" <jun.nakajima@intel.com>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
	handle_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PiBGcm9tOiBKYW4gQmV1bGljaCBbbWFpbHRvOkpCZXVsaWNoQHN1c2UuY29tXQ0KPiBTZW50OiBN
b25kYXksIERlY2VtYmVyIDA4LCAyMDE0IDU6MTMgUE0NCj4gDQo+IFBWSCBndWVzdHMgYWNjZXNz
aW5nIEkvTyBwb3J0cyB2aWEgc3RyaW5nIG9wcyBpcyBub3Qgc3VwcG9ydGVkIHlldC4NCj4gDQo+
IFJlcG9ydGVkLWJ5OiBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KPiBT
aWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQoNCkFja2VkLWJ5
OiBLZXZpbiBUaWFuIDxrZXZpbi50aWFuQGludGVsLmNvbT4NCg0KPiAtLS0NCj4gdjI6IGhhbmRs
ZV9waW8oKSBpcyBhbHJlYWR5IHNhZmUgKHBvaW50ZWQgb3V0IGJ5IE11a2VzaCksIHNvIG9ubHkg
cmVmdXNlDQo+ICAgICBlbnRlcmluZyBoYW5kbGVfbW1pbygpLg0KPiBOb3RlOiBPbmx5IGNvbXBp
bGUgdGVzdGVkIHNvIGZhci4NCj4gDQo+IC0tLSB1bnN0YWJsZS5vcmlnL3hlbi9hcmNoL3g4Ni9o
dm0vdm14L3ZteC5jCTIwMTQtMTEtMjcNCj4gMDk6Mzc6MjcuMDAwMDAwMDAwICswMTAwDQo+ICsr
KyB1bnN0YWJsZS94ZW4vYXJjaC94ODYvaHZtL3ZteC92bXguYwkyMDE0LTEyLTA4DQo+IDEwOjA0
OjI3LjAwMDAwMDAwMCArMDEwMA0KPiBAQCAtMzA4Niw3ICszMDg2LDggQEAgdm9pZCB2bXhfdm1l
eGl0X2hhbmRsZXIoc3RydWN0IGNwdV91c2VyXw0KPiAgICAgICAgICBpZiAoIGV4aXRfcXVhbGlm
aWNhdGlvbiAmIDB4MTAgKQ0KPiAgICAgICAgICB7DQo+ICAgICAgICAgICAgICAvKiBJTlMsIE9V
VFMgKi8NCj4gLSAgICAgICAgICAgIGlmICggIWhhbmRsZV9tbWlvKCkgKQ0KPiArICAgICAgICAg
ICAgaWYgKCB1bmxpa2VseShpc19wdmhfdmNwdSh2KSkgLyogUFZIIGZpeG1lICovIHx8DQo+ICsg
ICAgICAgICAgICAgICAgICFoYW5kbGVfbW1pbygpICkNCj4gICAgICAgICAgICAgICAgICBodm1f
aW5qZWN0X2h3X2V4Y2VwdGlvbihUUkFQX2dwX2ZhdWx0LCAwKTsNCj4gICAgICAgICAgfQ0KPiAg
ICAgICAgICBlbHNlDQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Dec 10 05:07:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 05:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyZUs-0000sJ-VX; Wed, 10 Dec 2014 05:07:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1XyZUs-0000sE-Jm
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 05:07:34 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	B7/40-02957-615D7845; Wed, 10 Dec 2014 05:07:34 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418188052!14091376!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 9223 invoked from network); 10 Dec 2014 05:07:33 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-8.tower-27.messagelabs.com with SMTP;
	10 Dec 2014 05:07:33 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 09 Dec 2014 21:07:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="427197635"
Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103])
	by FMSMGA003.fm.intel.com with ESMTP; 09 Dec 2014 20:56:47 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 13:07:26 +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; Wed, 10 Dec 2014 13:07:24 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
Thread-Topic: [PATCH v2] VMX: don't allow PVH to reach handle_mmio()
Thread-Index: AQHQEsdNCDzJbkWENU+RaLo5B23uMZyISLzA
Date: Wed, 10 Dec 2014 05:07:23 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126115014@SHSMSX101.ccr.corp.intel.com>
References: <54857995020000780004DA2D@mail.emea.novell.com>
In-Reply-To: <54857995020000780004DA2D@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: "Dong, Eddie" <eddie.dong@intel.com>, "Nakajima,
	Jun" <jun.nakajima@intel.com>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
	handle_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PiBGcm9tOiBKYW4gQmV1bGljaCBbbWFpbHRvOkpCZXVsaWNoQHN1c2UuY29tXQ0KPiBTZW50OiBN
b25kYXksIERlY2VtYmVyIDA4LCAyMDE0IDU6MTMgUE0NCj4gDQo+IFBWSCBndWVzdHMgYWNjZXNz
aW5nIEkvTyBwb3J0cyB2aWEgc3RyaW5nIG9wcyBpcyBub3Qgc3VwcG9ydGVkIHlldC4NCj4gDQo+
IFJlcG9ydGVkLWJ5OiBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KPiBT
aWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQoNCkFja2VkLWJ5
OiBLZXZpbiBUaWFuIDxrZXZpbi50aWFuQGludGVsLmNvbT4NCg0KPiAtLS0NCj4gdjI6IGhhbmRs
ZV9waW8oKSBpcyBhbHJlYWR5IHNhZmUgKHBvaW50ZWQgb3V0IGJ5IE11a2VzaCksIHNvIG9ubHkg
cmVmdXNlDQo+ICAgICBlbnRlcmluZyBoYW5kbGVfbW1pbygpLg0KPiBOb3RlOiBPbmx5IGNvbXBp
bGUgdGVzdGVkIHNvIGZhci4NCj4gDQo+IC0tLSB1bnN0YWJsZS5vcmlnL3hlbi9hcmNoL3g4Ni9o
dm0vdm14L3ZteC5jCTIwMTQtMTEtMjcNCj4gMDk6Mzc6MjcuMDAwMDAwMDAwICswMTAwDQo+ICsr
KyB1bnN0YWJsZS94ZW4vYXJjaC94ODYvaHZtL3ZteC92bXguYwkyMDE0LTEyLTA4DQo+IDEwOjA0
OjI3LjAwMDAwMDAwMCArMDEwMA0KPiBAQCAtMzA4Niw3ICszMDg2LDggQEAgdm9pZCB2bXhfdm1l
eGl0X2hhbmRsZXIoc3RydWN0IGNwdV91c2VyXw0KPiAgICAgICAgICBpZiAoIGV4aXRfcXVhbGlm
aWNhdGlvbiAmIDB4MTAgKQ0KPiAgICAgICAgICB7DQo+ICAgICAgICAgICAgICAvKiBJTlMsIE9V
VFMgKi8NCj4gLSAgICAgICAgICAgIGlmICggIWhhbmRsZV9tbWlvKCkgKQ0KPiArICAgICAgICAg
ICAgaWYgKCB1bmxpa2VseShpc19wdmhfdmNwdSh2KSkgLyogUFZIIGZpeG1lICovIHx8DQo+ICsg
ICAgICAgICAgICAgICAgICFoYW5kbGVfbW1pbygpICkNCj4gICAgICAgICAgICAgICAgICBodm1f
aW5qZWN0X2h3X2V4Y2VwdGlvbihUUkFQX2dwX2ZhdWx0LCAwKTsNCj4gICAgICAgICAgfQ0KPiAg
ICAgICAgICBlbHNlDQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Dec 10 06:01:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 06:01:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyaK4-0002QT-8e; Wed, 10 Dec 2014 06:00:28 +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 1XyaK2-0002QO-HG
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 06:00:26 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	56/55-27785-971E7845; Wed, 10 Dec 2014 06:00:25 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418191223!14077495!1
X-Originating-IP: [209.85.192.169]
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 32122 invoked from network); 10 Dec 2014 06:00:24 -0000
Received: from mail-pd0-f169.google.com (HELO mail-pd0-f169.google.com)
	(209.85.192.169)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 06:00:24 -0000
Received: by mail-pd0-f169.google.com with SMTP id z10so2108876pdj.28
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 22:00:23 -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=KnRWyVSbdTyb8y268I3DIY71r3kquSt3PJj1Tdvggn8=;
	b=rWi4e5JR86ChY89nJq0+dPH9arCQ0/ml/Ajr3IPvIT+x0ZdqqWkexBQTrD3Cmeu5M4
	1KDCTpIWcItNw6Hgng5Kq8zI3T/NZlnDKHzwPvvvcPdmI8Viz+sRQZClPOLauRzGL1Gh
	KRsm8wXiCmup7iWcyUVMzz5Trgy4h1O85yH9kiVxDNz48EGQ7Es9eaVHZn+HuwCXq+Tk
	lS2Tv5AAL/qtsynhzmrn3JDKEoYRt4ndmwVl4RDyvYj5TvB/LfanenY1KqOy1xa+TbDn
	eETGSGuEYeKRmRp00kE3N+PFHcFdWcjbkBtnwFXaLpLg2ZxSzvLYu2jNnqzJAyhOwBav
	LXRQ==
X-Received: by 10.68.203.226 with SMTP id kt2mr3596810pbc.141.1418191222434;
	Tue, 09 Dec 2014 22:00:22 -0800 (PST)
Received: from mswilson@gmail.com (54-240-196-169.amazon.com. [54.240.196.169])
	by mx.google.com with ESMTPSA id m5sm3073031pdp.53.2014.12.09.22.00.19
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 09 Dec 2014 22:00:21 -0800 (PST)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
	Tue, 09 Dec 2014 22:00:18 -0800
Date: Tue, 9 Dec 2014 22:00:18 -0800
From: Matt Wilson <msw@linux.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545BE7DF.2090803@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	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 Thu, Nov 06, 2014 at 09:27:59PM +0000, Andrew Cooper wrote:
> 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.

Sorry for chiming in late...

That's not strictly true. You can use the processor index in ACPI.

> 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)

This is absolutely the wrong thing to do. If a guest OS is doing this,
it is doing the wrong thing. FreeBSD went down this erroneous path...

See http://lists.xen.org/archives/html/xen-devel/2013-05/msg03156.html

> >
> >> 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.

No, don't assume anything about APIC IDs mapping to Xen virtual
processor index. This will break things on EC2 instances that expose
proper CPU topology through CPUID, and this does *not* follow the
"index * 2" formula.

> >> 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.

And the Xen vCPU index can be determined by the processor object IDs
in DSDT.

--msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 06:01:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 06:01:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyaK4-0002QT-8e; Wed, 10 Dec 2014 06:00:28 +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 1XyaK2-0002QO-HG
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 06:00:26 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	56/55-27785-971E7845; Wed, 10 Dec 2014 06:00:25 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418191223!14077495!1
X-Originating-IP: [209.85.192.169]
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 32122 invoked from network); 10 Dec 2014 06:00:24 -0000
Received: from mail-pd0-f169.google.com (HELO mail-pd0-f169.google.com)
	(209.85.192.169)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 06:00:24 -0000
Received: by mail-pd0-f169.google.com with SMTP id z10so2108876pdj.28
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 22:00:23 -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=KnRWyVSbdTyb8y268I3DIY71r3kquSt3PJj1Tdvggn8=;
	b=rWi4e5JR86ChY89nJq0+dPH9arCQ0/ml/Ajr3IPvIT+x0ZdqqWkexBQTrD3Cmeu5M4
	1KDCTpIWcItNw6Hgng5Kq8zI3T/NZlnDKHzwPvvvcPdmI8Viz+sRQZClPOLauRzGL1Gh
	KRsm8wXiCmup7iWcyUVMzz5Trgy4h1O85yH9kiVxDNz48EGQ7Es9eaVHZn+HuwCXq+Tk
	lS2Tv5AAL/qtsynhzmrn3JDKEoYRt4ndmwVl4RDyvYj5TvB/LfanenY1KqOy1xa+TbDn
	eETGSGuEYeKRmRp00kE3N+PFHcFdWcjbkBtnwFXaLpLg2ZxSzvLYu2jNnqzJAyhOwBav
	LXRQ==
X-Received: by 10.68.203.226 with SMTP id kt2mr3596810pbc.141.1418191222434;
	Tue, 09 Dec 2014 22:00:22 -0800 (PST)
Received: from mswilson@gmail.com (54-240-196-169.amazon.com. [54.240.196.169])
	by mx.google.com with ESMTPSA id m5sm3073031pdp.53.2014.12.09.22.00.19
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 09 Dec 2014 22:00:21 -0800 (PST)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
	Tue, 09 Dec 2014 22:00:18 -0800
Date: Tue, 9 Dec 2014 22:00:18 -0800
From: Matt Wilson <msw@linux.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <545BE7DF.2090803@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	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 Thu, Nov 06, 2014 at 09:27:59PM +0000, Andrew Cooper wrote:
> 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.

Sorry for chiming in late...

That's not strictly true. You can use the processor index in ACPI.

> 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)

This is absolutely the wrong thing to do. If a guest OS is doing this,
it is doing the wrong thing. FreeBSD went down this erroneous path...

See http://lists.xen.org/archives/html/xen-devel/2013-05/msg03156.html

> >
> >> 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.

No, don't assume anything about APIC IDs mapping to Xen virtual
processor index. This will break things on EC2 instances that expose
proper CPU topology through CPUID, and this does *not* follow the
"index * 2" formula.

> >> 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.

And the Xen vCPU index can be determined by the processor object IDs
in DSDT.

--msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 07:10:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 07: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 1XybOx-0004wc-Qs; Wed, 10 Dec 2014 07:09:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maomingya928@gmail.com>) id 1XybOv-0004wX-NL
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 07:09:33 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	2D/88-27785-DA1F7845; Wed, 10 Dec 2014 07:09:33 +0000
X-Env-Sender: maomingya928@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418195370!10749741!1
X-Originating-IP: [209.85.220.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20459 invoked from network); 10 Dec 2014 07:09:32 -0000
Received: from mail-pa0-f42.google.com (HELO mail-pa0-f42.google.com)
	(209.85.220.42)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 07:09:32 -0000
Received: by mail-pa0-f42.google.com with SMTP id et14so2242136pad.15
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 23:09:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent
	:mime-version:content-type:content-transfer-encoding;
	bh=AdTW34ZCsl3O3NiHUX/g+BNCUJ56o0EHNNGlSvWN+Ko=;
	b=HbDUoliVdKoJPAEYPlfSzV6+beIyLEAGNWr2KoCsP3eCwob2gfN+PQzCQsLqQVBIAt
	FIQFcoLHE7OhFSuS1pkg1pbsrkjxaUAkBvNQos9YFmoV015gLOInFsZoZjbxshTFAm5M
	JnqhDAbawavxOtpqe+KeQWWfn6Ph1Aa+8PtRhqbqA8cZ8+2EAtpMJWadd9E5hOZzIjJk
	P3McBJ6nhRkD1RGVRyF/E6EoC/on7WE3NIltPdaVBweP3QB1CxKCVHTqVuOjeflOEm0u
	XNf2fRvg4SxAWgL8XBioBjmSbmxNiT/+gdXoES+Ts2fWd0y0jfgmuh4WQo0VANPTBqfV
	gKuQ==
X-Received: by 10.66.90.201 with SMTP id by9mr4339309pab.148.1418195370383;
	Tue, 09 Dec 2014 23:09:30 -0800 (PST)
Received: from [10.0.1.100] ([202.55.93.170])
	by mx.google.com with ESMTPSA id eo4sm3215107pbb.87.2014.12.09.23.09.28
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 09 Dec 2014 23:09:29 -0800 (PST)
From: "Mao Mingya" <maomingya928@gmail.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
Date: Wed, 10 Dec 2014 07:09:26 +0000
Message-Id: <em21df949d-ecc3-45dc-a652-b160516de8f7@sgp1030c>
In-Reply-To: <1418121168.14361.0.camel@citrix.com>
User-Agent: eM_Client/6.0.21040.0
Mime-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] arch arm qemu compile erro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mao Mingya <maomingya928@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>From the the arch arm, since the stubdom is not supported now. Does the 
device to be shared between doms have to be pv front/backend structure.

To run the Linux on Dom0 and DomU. Could the qemu and pv backend run in 
the Dom0 at the same time?
     For example: for network, block device, serial console, the pv 
backend provides the device drive for DomU linux
     while qemu provides all other devices driver for DomU linux.

Regards,
Mao


------ Original Message ------
From: "Ian Campbell" <Ian.Campbell@citrix.com>
To: "Mao Mingya" <maomingya928@gmail.com>
Cc: xen-devel@lists.xen.org
Sent: 9/12/2014 6:32:48 PM
Subject: Re: [Xen-devel] arch arm qemu compile erro

>On Tue, 2014-12-09 at 10:04 +0000, Mao Mingya wrote:
>>  While I tried to cross compile the qemu for xen with the following
>>  command:
>>  "make dist-stubdom CROSS_COMPILE=arm-linux-gnueabihf-
>>  XEN_TARGET_ARCH=arm32"
>>
>>  I got an error complain about the
>>  " ./extras/mini-os/arch/arm32/arch.mk: No such file or directory " is
>>  missing.
>>
>>  My xen source version is on "Xen-4.5.0-rc3"
>>
>>  Is the build process for xen broken? or some ./configure needed?
>
>stubdoms are not supported on ARM right now.
>
>Ian.
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 07:10:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 07: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 1XybOx-0004wc-Qs; Wed, 10 Dec 2014 07:09:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maomingya928@gmail.com>) id 1XybOv-0004wX-NL
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 07:09:33 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	2D/88-27785-DA1F7845; Wed, 10 Dec 2014 07:09:33 +0000
X-Env-Sender: maomingya928@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418195370!10749741!1
X-Originating-IP: [209.85.220.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20459 invoked from network); 10 Dec 2014 07:09:32 -0000
Received: from mail-pa0-f42.google.com (HELO mail-pa0-f42.google.com)
	(209.85.220.42)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 07:09:32 -0000
Received: by mail-pa0-f42.google.com with SMTP id et14so2242136pad.15
	for <xen-devel@lists.xen.org>; Tue, 09 Dec 2014 23:09:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent
	:mime-version:content-type:content-transfer-encoding;
	bh=AdTW34ZCsl3O3NiHUX/g+BNCUJ56o0EHNNGlSvWN+Ko=;
	b=HbDUoliVdKoJPAEYPlfSzV6+beIyLEAGNWr2KoCsP3eCwob2gfN+PQzCQsLqQVBIAt
	FIQFcoLHE7OhFSuS1pkg1pbsrkjxaUAkBvNQos9YFmoV015gLOInFsZoZjbxshTFAm5M
	JnqhDAbawavxOtpqe+KeQWWfn6Ph1Aa+8PtRhqbqA8cZ8+2EAtpMJWadd9E5hOZzIjJk
	P3McBJ6nhRkD1RGVRyF/E6EoC/on7WE3NIltPdaVBweP3QB1CxKCVHTqVuOjeflOEm0u
	XNf2fRvg4SxAWgL8XBioBjmSbmxNiT/+gdXoES+Ts2fWd0y0jfgmuh4WQo0VANPTBqfV
	gKuQ==
X-Received: by 10.66.90.201 with SMTP id by9mr4339309pab.148.1418195370383;
	Tue, 09 Dec 2014 23:09:30 -0800 (PST)
Received: from [10.0.1.100] ([202.55.93.170])
	by mx.google.com with ESMTPSA id eo4sm3215107pbb.87.2014.12.09.23.09.28
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 09 Dec 2014 23:09:29 -0800 (PST)
From: "Mao Mingya" <maomingya928@gmail.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
Date: Wed, 10 Dec 2014 07:09:26 +0000
Message-Id: <em21df949d-ecc3-45dc-a652-b160516de8f7@sgp1030c>
In-Reply-To: <1418121168.14361.0.camel@citrix.com>
User-Agent: eM_Client/6.0.21040.0
Mime-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] arch arm qemu compile erro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mao Mingya <maomingya928@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>From the the arch arm, since the stubdom is not supported now. Does the 
device to be shared between doms have to be pv front/backend structure.

To run the Linux on Dom0 and DomU. Could the qemu and pv backend run in 
the Dom0 at the same time?
     For example: for network, block device, serial console, the pv 
backend provides the device drive for DomU linux
     while qemu provides all other devices driver for DomU linux.

Regards,
Mao


------ Original Message ------
From: "Ian Campbell" <Ian.Campbell@citrix.com>
To: "Mao Mingya" <maomingya928@gmail.com>
Cc: xen-devel@lists.xen.org
Sent: 9/12/2014 6:32:48 PM
Subject: Re: [Xen-devel] arch arm qemu compile erro

>On Tue, 2014-12-09 at 10:04 +0000, Mao Mingya wrote:
>>  While I tried to cross compile the qemu for xen with the following
>>  command:
>>  "make dist-stubdom CROSS_COMPILE=arm-linux-gnueabihf-
>>  XEN_TARGET_ARCH=arm32"
>>
>>  I got an error complain about the
>>  " ./extras/mini-os/arch/arm32/arch.mk: No such file or directory " is
>>  missing.
>>
>>  My xen source version is on "Xen-4.5.0-rc3"
>>
>>  Is the build process for xen broken? or some ./configure needed?
>
>stubdoms are not supported on ARM right now.
>
>Ian.
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 08:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycJY-0007BL-8t; Wed, 10 Dec 2014 08:08:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XycJW-0007Ak-0y
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:08:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E4/56-15461-16FF7845; Wed, 10 Dec 2014 08:08:01 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418198877!6550709!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29749 invoked from network); 10 Dec 2014 08:07:59 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 08:07:59 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Dec 2014 00:07:58 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="651422616"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga002.jf.intel.com with ESMTP; 10 Dec 2014 00:07:56 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 16:07:37 +0800
Message-Id: <1418198860-29802-2-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
References: <1418198860-29802-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 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 preparing and installing L1 guest VM inside L0 system
on testhost machine.

---
 Osstest/Debian.pm      |   27 ++++++++++++++++++---------
 Osstest/TestSupport.pm |   31 ++++++++++++++++++++++++++-----
 sg-run-job             |    5 +++++
 ts-debian-hvm-install  |   34 ++++++++++++++++++++++++----------
 4 files changed, 73 insertions(+), 24 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..a671d20 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
@@ -34,6 +35,7 @@ BEGIN {
     @EXPORT      = qw(debian_boot_setup
                       %preseed_cmds
                       preseed_base
+                      setupboot_grub2
                       preseed_create
                       preseed_hook_command preseed_hook_installscript
                       di_installcmdline_core
@@ -286,15 +288,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 +322,25 @@ 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\S+)/) {
+#	    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 a3b6936..1e47039 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 @_;
@@ -717,6 +727,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};
@@ -937,7 +948,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);
@@ -1465,7 +1476,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'
@@ -2063,4 +2074,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..8dcf7af 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-debian-hvm-install + host + nested + nested_L1
+}
+
 proc test-guest-migr {g} {
     if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
 
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 37eade2..6dcec3c 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -28,22 +28,24 @@ 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;
+our ($whhost,$gn,$nested_L1,$guesthost) = @ARGV;
 $whhost ||= 'host';
-$gn ||= 'debianhvm';
-
+$nested_L1 ||= '';
+if ($nested_L1 eq 'nested_L1') {
+    $gn ||= 'nested';
+    $guesthost ||= "$gn.l1.osstest";
+} else {
+    $gn ||= 'debianhvm';
+    $guesthost= "$gn.guest.osstest";
+}
 our $ho= selecthost($whhost);
-
+our $disk_mb= 50000;
 # guest memory size will be set based on host free memory, see below
 our $ram_mb;
-our $disk_mb= 10000;
-
-our $guesthost= "$gn.guest.osstest";
 our $gho;
 
 our $toolstack= toolstack()->{Command};
 
-
 sub preseed () {
 
     my $preseed_file = preseed_base('wheezy','',());
@@ -63,7 +65,7 @@ d-i partman-auto/expert_recipe string \\
                         use_filesystem{ } filesystem{ vfat } \\
                         mountpoint{ /boot/efi } \\
                 . \\
-                5000 50 5000 ext4 \\
+                25000 50 25000 ext4 \\
                         method{ format } format{ } \\
                         use_filesystem{ } filesystem{ ext4 } \\
                         mountpoint{ / } \\
@@ -155,6 +157,8 @@ sub prep () {
     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);
@@ -176,6 +180,8 @@ my $ram_minslop = 100;
 my $ram_lots = 5000;
 if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
     $ram_mb = $ram_lots;
+} elsif ($nested_L1 eq 'nested_L1') {
+    $ram_mb = 2048;
 } else {
     $ram_mb = 768;
 }
@@ -192,7 +198,15 @@ if ($stage<2) {
     guest_destroy($ho,$gho);
 }
 
-guest_editconfig_nocd($gho,$emptyiso);
+if ($nested_L1 eq 'nested_L1') {
+    guest_editconfig_cd($gho);
+} else {
+    guest_editconfig_nocd($gho,$emptyiso);
+}
 guest_create($gho,$toolstack);
 guest_await_dhcp_tcp($gho,300);
 guest_check_up($gho);
+if ($nested_L1 eq 'nested_L1') {
+    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 Wed Dec 10 08:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycJa-0007C4-8C; Wed, 10 Dec 2014 08:08:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XycJZ-0007Ba-63
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:08:05 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FB/35-25276-46FF7845; Wed, 10 Dec 2014 08:08:04 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418198877!6550709!4
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30139 invoked from network); 10 Dec 2014 08:08:02 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 08:08:02 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Dec 2014 00:08:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="651422652"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga002.jf.intel.com with ESMTP; 10 Dec 2014 00:08:00 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 16:07:39 +0800
Message-Id: <1418198860-29802-4-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
References: <1418198860-29802-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 testcase 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 e513bd1..85f7b22 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-debian-hvm-install + host + nested + nested_L1
     run-ts . = ts-xen-install + host + nested + nested_build
+    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 Wed Dec 10 08:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycJW-0007B6-SR; Wed, 10 Dec 2014 08:08: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 1XycJU-0007Ab-O7
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 08:08:00 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	7F/3D-29352-06FF7845; Wed, 10 Dec 2014 08:08:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418198879!7204473!1
X-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 29086 invoked from network); 10 Dec 2014 08:07:59 -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; 10 Dec 2014 08:07:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 08:07:58 +0000
Message-Id: <54880D6B020000780004E6AA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 08:07:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part0F3AD14B.1__="
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: [Xen-devel] [PATCH] domctl: fix IRQ permission granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part0F3AD14B.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
wasn't really consistent in one respect: The granting of access to an
IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
domains. In fact it is wrong to assume that a translation is already/
still in place at the time access is being granted/revoked.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
=20
     case XEN_DOMCTL_irq_permission:
     {
-        unsigned int pirq =3D op->u.irq_permission.pirq;
+        unsigned int pirq =3D op->u.irq_permission.pirq, irq;
         int allow =3D op->u.irq_permission.allow_access;
=20
         if ( pirq >=3D d->nr_pirqs )
             ret =3D -EINVAL;
-        else if ( !pirq_access_permitted(current->domain, pirq) ||
+        else if ( !(irq =3D pirq_access_permitted(current->domain, pirq)) =
||
                   xsm_irq_permission(XSM_HOOK, d, pirq, allow) )
             ret =3D -EPERM;
         else if ( allow )
-            ret =3D pirq_permit_access(d, pirq);
+            ret =3D irq_permit_access(d, irq);
         else
-            ret =3D pirq_deny_access(d, pirq);
+            ret =3D irq_deny_access(d, irq);
     }
     break;
=20
--- a/xen/include/xen/iocap.h
+++ b/xen/include/xen/iocap.h
@@ -28,22 +28,11 @@
 #define irq_access_permitted(d, i)                      \
     rangeset_contains_singleton((d)->irq_caps, i)
=20
-#define pirq_permit_access(d, i) ({                     \
-    struct domain *d__ =3D (d);                           \
-    int i__ =3D domain_pirq_to_irq(d__, i);               \
-    i__ > 0 ? rangeset_add_singleton(d__->irq_caps, i__)\
-            : -EINVAL;                                  \
-})
-#define pirq_deny_access(d, i) ({                       \
-    struct domain *d__ =3D (d);                           \
-    int i__ =3D domain_pirq_to_irq(d__, i);               \
-    i__ > 0 ? rangeset_remove_singleton(d__->irq_caps, i__)\
-            : -EINVAL;                                  \
-})
 #define pirq_access_permitted(d, i) ({                  \
     struct domain *d__ =3D (d);                           \
-    rangeset_contains_singleton(d__->irq_caps,          \
-                                domain_pirq_to_irq(d__, i));\
+    int irq__ =3D domain_pirq_to_irq(d__, i);             \
+    irq__ > 0 && irq_access_permitted(d__, irq__)       \
+    ? irq__ : 0;                                        \
 })
=20
 #endif /* __XEN_IOCAP_H__ */




--=__Part0F3AD14B.1__=
Content-Type: text/plain; name="domctl-irq-permission.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="domctl-irq-permission.patch"

domctl: fix IRQ permission granting/revocation=0A=0ACommit 545607eb3c =
("x86: fix various issues with handling guest IRQs")=0Awasn't really =
consistent in one respect: The granting of access to an=0AIRQ shouldn't =
assume the pIRQ->IRQ translation to be the same in both=0Adomains. In fact =
it is wrong to assume that a translation is already/=0Astill in place at =
the time access is being granted/revoked.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/common/domctl.c=0A+++ b/xen/common/domct=
l.c=0A@@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe=0A =
=0A     case XEN_DOMCTL_irq_permission:=0A     {=0A-        unsigned int =
pirq =3D op->u.irq_permission.pirq;=0A+        unsigned int pirq =3D =
op->u.irq_permission.pirq, irq;=0A         int allow =3D op->u.irq_permissi=
on.allow_access;=0A =0A         if ( pirq >=3D d->nr_pirqs )=0A            =
 ret =3D -EINVAL;=0A-        else if ( !pirq_access_permitted(current->doma=
in, pirq) ||=0A+        else if ( !(irq =3D pirq_access_permitted(current->=
domain, pirq)) ||=0A                   xsm_irq_permission(XSM_HOOK, d, =
pirq, allow) )=0A             ret =3D -EPERM;=0A         else if ( allow =
)=0A-            ret =3D pirq_permit_access(d, pirq);=0A+            ret =
=3D irq_permit_access(d, irq);=0A         else=0A-            ret =3D =
pirq_deny_access(d, pirq);=0A+            ret =3D irq_deny_access(d, =
irq);=0A     }=0A     break;=0A =0A--- a/xen/include/xen/iocap.h=0A+++ =
b/xen/include/xen/iocap.h=0A@@ -28,22 +28,11 @@=0A #define irq_access_permi=
tted(d, i)                      \=0A     rangeset_contains_singleton((d)->i=
rq_caps, i)=0A =0A-#define pirq_permit_access(d, i) ({                     =
\=0A-    struct domain *d__ =3D (d);                           \=0A-    =
int i__ =3D domain_pirq_to_irq(d__, i);               \=0A-    i__ > 0 ? =
rangeset_add_singleton(d__->irq_caps, i__)\=0A-            : -EINVAL;      =
                            \=0A-})=0A-#define pirq_deny_access(d, i) ({   =
                    \=0A-    struct domain *d__ =3D (d);                   =
        \=0A-    int i__ =3D domain_pirq_to_irq(d__, i);               =
\=0A-    i__ > 0 ? rangeset_remove_singleton(d__->irq_caps, i__)\=0A-      =
      : -EINVAL;                                  \=0A-})=0A #define =
pirq_access_permitted(d, i) ({                  \=0A     struct domain =
*d__ =3D (d);                           \=0A-    rangeset_contains_singleto=
n(d__->irq_caps,          \=0A-                                domain_pirq_=
to_irq(d__, i));\=0A+    int irq__ =3D domain_pirq_to_irq(d__, i);         =
    \=0A+    irq__ > 0 && irq_access_permitted(d__, irq__)       \=0A+    =
? irq__ : 0;                                        \=0A })=0A =0A #endif =
/* __XEN_IOCAP_H__ */=0A
--=__Part0F3AD14B.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

--=__Part0F3AD14B.1__=--


From xen-devel-bounces@lists.xen.org Wed Dec 10 08:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycJW-0007B6-SR; Wed, 10 Dec 2014 08:08: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 1XycJU-0007Ab-O7
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 08:08:00 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	7F/3D-29352-06FF7845; Wed, 10 Dec 2014 08:08:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418198879!7204473!1
X-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 29086 invoked from network); 10 Dec 2014 08:07:59 -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; 10 Dec 2014 08:07:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 08:07:58 +0000
Message-Id: <54880D6B020000780004E6AA@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 08:07:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part0F3AD14B.1__="
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: [Xen-devel] [PATCH] domctl: fix IRQ permission granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part0F3AD14B.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
wasn't really consistent in one respect: The granting of access to an
IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
domains. In fact it is wrong to assume that a translation is already/
still in place at the time access is being granted/revoked.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
=20
     case XEN_DOMCTL_irq_permission:
     {
-        unsigned int pirq =3D op->u.irq_permission.pirq;
+        unsigned int pirq =3D op->u.irq_permission.pirq, irq;
         int allow =3D op->u.irq_permission.allow_access;
=20
         if ( pirq >=3D d->nr_pirqs )
             ret =3D -EINVAL;
-        else if ( !pirq_access_permitted(current->domain, pirq) ||
+        else if ( !(irq =3D pirq_access_permitted(current->domain, pirq)) =
||
                   xsm_irq_permission(XSM_HOOK, d, pirq, allow) )
             ret =3D -EPERM;
         else if ( allow )
-            ret =3D pirq_permit_access(d, pirq);
+            ret =3D irq_permit_access(d, irq);
         else
-            ret =3D pirq_deny_access(d, pirq);
+            ret =3D irq_deny_access(d, irq);
     }
     break;
=20
--- a/xen/include/xen/iocap.h
+++ b/xen/include/xen/iocap.h
@@ -28,22 +28,11 @@
 #define irq_access_permitted(d, i)                      \
     rangeset_contains_singleton((d)->irq_caps, i)
=20
-#define pirq_permit_access(d, i) ({                     \
-    struct domain *d__ =3D (d);                           \
-    int i__ =3D domain_pirq_to_irq(d__, i);               \
-    i__ > 0 ? rangeset_add_singleton(d__->irq_caps, i__)\
-            : -EINVAL;                                  \
-})
-#define pirq_deny_access(d, i) ({                       \
-    struct domain *d__ =3D (d);                           \
-    int i__ =3D domain_pirq_to_irq(d__, i);               \
-    i__ > 0 ? rangeset_remove_singleton(d__->irq_caps, i__)\
-            : -EINVAL;                                  \
-})
 #define pirq_access_permitted(d, i) ({                  \
     struct domain *d__ =3D (d);                           \
-    rangeset_contains_singleton(d__->irq_caps,          \
-                                domain_pirq_to_irq(d__, i));\
+    int irq__ =3D domain_pirq_to_irq(d__, i);             \
+    irq__ > 0 && irq_access_permitted(d__, irq__)       \
+    ? irq__ : 0;                                        \
 })
=20
 #endif /* __XEN_IOCAP_H__ */




--=__Part0F3AD14B.1__=
Content-Type: text/plain; name="domctl-irq-permission.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="domctl-irq-permission.patch"

domctl: fix IRQ permission granting/revocation=0A=0ACommit 545607eb3c =
("x86: fix various issues with handling guest IRQs")=0Awasn't really =
consistent in one respect: The granting of access to an=0AIRQ shouldn't =
assume the pIRQ->IRQ translation to be the same in both=0Adomains. In fact =
it is wrong to assume that a translation is already/=0Astill in place at =
the time access is being granted/revoked.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/common/domctl.c=0A+++ b/xen/common/domct=
l.c=0A@@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe=0A =
=0A     case XEN_DOMCTL_irq_permission:=0A     {=0A-        unsigned int =
pirq =3D op->u.irq_permission.pirq;=0A+        unsigned int pirq =3D =
op->u.irq_permission.pirq, irq;=0A         int allow =3D op->u.irq_permissi=
on.allow_access;=0A =0A         if ( pirq >=3D d->nr_pirqs )=0A            =
 ret =3D -EINVAL;=0A-        else if ( !pirq_access_permitted(current->doma=
in, pirq) ||=0A+        else if ( !(irq =3D pirq_access_permitted(current->=
domain, pirq)) ||=0A                   xsm_irq_permission(XSM_HOOK, d, =
pirq, allow) )=0A             ret =3D -EPERM;=0A         else if ( allow =
)=0A-            ret =3D pirq_permit_access(d, pirq);=0A+            ret =
=3D irq_permit_access(d, irq);=0A         else=0A-            ret =3D =
pirq_deny_access(d, pirq);=0A+            ret =3D irq_deny_access(d, =
irq);=0A     }=0A     break;=0A =0A--- a/xen/include/xen/iocap.h=0A+++ =
b/xen/include/xen/iocap.h=0A@@ -28,22 +28,11 @@=0A #define irq_access_permi=
tted(d, i)                      \=0A     rangeset_contains_singleton((d)->i=
rq_caps, i)=0A =0A-#define pirq_permit_access(d, i) ({                     =
\=0A-    struct domain *d__ =3D (d);                           \=0A-    =
int i__ =3D domain_pirq_to_irq(d__, i);               \=0A-    i__ > 0 ? =
rangeset_add_singleton(d__->irq_caps, i__)\=0A-            : -EINVAL;      =
                            \=0A-})=0A-#define pirq_deny_access(d, i) ({   =
                    \=0A-    struct domain *d__ =3D (d);                   =
        \=0A-    int i__ =3D domain_pirq_to_irq(d__, i);               =
\=0A-    i__ > 0 ? rangeset_remove_singleton(d__->irq_caps, i__)\=0A-      =
      : -EINVAL;                                  \=0A-})=0A #define =
pirq_access_permitted(d, i) ({                  \=0A     struct domain =
*d__ =3D (d);                           \=0A-    rangeset_contains_singleto=
n(d__->irq_caps,          \=0A-                                domain_pirq_=
to_irq(d__, i));\=0A+    int irq__ =3D domain_pirq_to_irq(d__, i);         =
    \=0A+    irq__ > 0 && irq_access_permitted(d__, irq__)       \=0A+    =
? irq__ : 0;                                        \=0A })=0A =0A #endif =
/* __XEN_IOCAP_H__ */=0A
--=__Part0F3AD14B.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

--=__Part0F3AD14B.1__=--


From xen-devel-bounces@lists.xen.org Wed Dec 10 08:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycJb-0007CW-LF; Wed, 10 Dec 2014 08:08:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XycJa-0007C1-DG
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:08:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C6/F8-09842-56FF7845; Wed, 10 Dec 2014 08:08:05 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418198884!14551606!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32604 invoked from network); 10 Dec 2014 08:08:04 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 08:08:04 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Dec 2014 00:08:03 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="651422673"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga002.jf.intel.com with ESMTP; 10 Dec 2014 00:08:02 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 16:07:40 +0800
Message-Id: <1418198860-29802-5-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
References: <1418198860-29802-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 into
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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..b65f0b5 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=v3.16                                         \
+                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 Wed Dec 10 08:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycJW-0007Al-AK; Wed, 10 Dec 2014 08:08:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XycJU-0007Aa-Hw
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:08:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	34/B8-09842-F5FF7845; Wed, 10 Dec 2014 08:07:59 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418198877!6550709!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29523 invoked from network); 10 Dec 2014 08:07:59 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 08:07:59 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Dec 2014 00:07:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="651422600"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga002.jf.intel.com with ESMTP; 10 Dec 2014 00:07:52 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 16:07:36 +0800
Message-Id: <1418198860-29802-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(version_3) again 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

----------------------------------------------------------------
longtao.pang (4):
      Add nested testcase of preparing and installing L1 guest VM 
      Build XEN and HVM Dom0 kernel for L1 guest VM
      Add nested testcase of installing L2 guest VM
      Insert nested test job name and runvars

 Osstest/Debian.pm      |   27 +++++---
 Osstest/TestSupport.pm |   31 +++++++--
 make-flight            |   19 ++++++
 mfi-common             |    8 +++
 sg-run-job             |    8 +++
 ts-debian-hvm-install  |   34 +++++++---
 ts-debian-install      |  166 +++++++++++++++++++++++++++++++++++++-----------
 ts-xen-install         |  149 +++++++++++++++++++++++++++++++------------
 8 files changed, 343 insertions(+), 99 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 08:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycJY-0007BW-MF; Wed, 10 Dec 2014 08:08:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XycJX-0007Aw-5R
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:08:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7D/25-25276-26FF7845; Wed, 10 Dec 2014 08:08:02 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418198877!6550709!3
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29979 invoked from network); 10 Dec 2014 08:08:01 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 08:08:01 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Dec 2014 00:08:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="651422627"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga002.jf.intel.com with ESMTP; 10 Dec 2014 00:07:58 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 16:07:38 +0800
Message-Id: <1418198860-29802-3-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
References: <1418198860-29802-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] Build 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-xen-install |  149 +++++++++++++++++++++++++++++++++++++++++---------------
 2 files changed, 111 insertions(+), 39 deletions(-)

diff --git a/sg-run-job b/sg-run-job
index 8dcf7af..e513bd1 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-debian-hvm-install + host + nested + nested_L1
+    run-ts . = ts-xen-install + host + nested + nested_build
 }
 
 proc test-guest-migr {g} {
diff --git a/ts-xen-install b/ts-xen-install
index 4d34d1f..c175d6d 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -28,19 +28,25 @@ use Osstest::CXFabric;
 my $checkmode= 0;
 
 tsreadconfig();
-
+our $w_ho;
 our @hos;
-
-if (@ARGV and $ARGV[0] eq '--check') {
-    $checkmode= 1;
-    shift @ARGV;
-    logm("checking builds are done...");
+our ($whhost,$gn,$nested_build) = @ARGV;
+$nested_build ||= '';
+if ($nested_build eq 'nested_build') {
+    $whhost ||= 'host';
+    $gn ||= 'nested';
 } else {
-    if (!@ARGV) {
-	push @ARGV, 'host';
-    }
-    foreach my $k (@ARGV) {
-        push @hos, selecthost($k);
+    if (@ARGV and $ARGV[0] eq '--check') {
+        $checkmode= 1;
+        shift @ARGV;
+        logm("checking builds are done...");
+    } else {
+        if (!@ARGV) {
+            push @ARGV, 'host';
+        }
+        foreach my $k (@ARGV) {
+            push @hos, selecthost($k);
+        }
     }
 }
 
@@ -49,18 +55,18 @@ our $ho;
 my %distpath;
 
 sub packages () {
-    target_install_packages($ho,
+    target_install_packages($w_ho,
                             qw(bridge-utils vncsnapshot libaio1 libpixman-1-0
                                libsdl1.2debian libglib2.0-0 liblzma5));
-    target_install_packages($ho,
+    target_install_packages($w_ho,
 			    $ho->{Suite} =~ /squeeze/ ? "libyajl1" : "libyajl2");
     if ($ho->{Suite} !~ m/lenny|squeeze/) {
-        target_install_packages($ho, 'libfdt1');
+        target_install_packages($w_ho, 'libfdt1');
     }
     if ($r{arch} eq 'i386') {
-	target_install_packages($ho, 'libc6-xen');
+	target_install_packages($w_ho, 'libc6-xen');
     }
-    target_install_packages($ho, @{toolstack()->{ExtraPackages}})
+    target_install_packages($w_ho, @{toolstack()->{ExtraPackages}})
         if toolstack()->{ExtraPackages};
 }
 
@@ -69,14 +75,14 @@ sub extract () {
     push @parts, 'libvirt' if $r{toolstack} eq "libvirt";
 
     foreach my $part (@parts) {
-        target_extract_jobdistpath($ho, $part, "path_${part}dist",
+        target_extract_jobdistpath($w_ho, $part, "path_${part}dist",
 				   $r{"${part}buildjob"}, \%distpath);
     }
-    target_cmd_root($ho, '/sbin/ldconfig');
+    target_cmd_root($w_ho, '/sbin/ldconfig');
 }
 
 sub adjustconfig () {
-    target_editfile_root($ho, "/etc/xen/xend-config.sxp",
+    target_editfile_root($w_ho, "/etc/xen/xend-config.sxp",
 			 "xend-config.sxp", sub {
 	my (@domains) = (qw(localhost localhost.localdomain),
 			 ".".$c{DnsDomain}, ".".$c{TestHostDomain});
@@ -108,13 +114,13 @@ sub adjustconfig () {
                         /etc/sysconfig/xencommons
                         /etc/default/xend
                         /etc/sysconfig/xend)) {
-        next unless target_file_exists($ho, $try);
+        next unless target_file_exists($w_ho, $try);
         $trace_config_file= $try;
         last;
     }
     die unless defined $trace_config_file;
 
-    target_editfile_root($ho, $trace_config_file, sub {
+    target_editfile_root($w_ho, $trace_config_file, sub {
         my $prnow;
         $prnow= sub {
             print EO "XENCONSOLED_TRACE=guest\n" or die $!;
@@ -128,7 +134,7 @@ sub adjustconfig () {
         $prnow->();
     });
 
-    target_cmd_root($ho, 'mkdir -p /var/log/xen/console');
+    target_cmd_root($w_ho, 'mkdir -p /var/log/xen/console');
 
     setup_cxfabric($ho);
 }
@@ -156,19 +162,19 @@ sub setupboot () {
     $xenhopt .= " $append" if defined $append;
 
     my @hooks;
-
+    
     if (host_involves_pcipassthrough($ho)) {
         push @hooks, {
             EditBootOptions => sub {
                 my ($ho,$hopt,$kopt) = @_;
                 $$hopt .= ' iommu=on';
                 my $hide= ' xen-pciback.hide='. join '',map { "($_->{Bdf})" }
-                    host_get_pcipassthrough_devs($ho);
+                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($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
@@ -182,7 +188,7 @@ sub setupinitd () {
     my $ts= toolstack();
     my $xencommons= '/etc/init.d/xencommons';
     my $have_xencommons=
-        !!target_cmd_output_root($ho, <<END);
+        !!target_cmd_output_root($w_ho, <<END);
  if test -f $xencommons && ! grep 'FOR USE WITH LIBXL' $xencommons >/dev/null
  then
    echo y
@@ -211,7 +217,33 @@ END
         $updatercd->($initd,93) if defined $initd;
         $updatercd->('xenbridge',38) if $ts->{OldSeparateBridgeInitd};
     }
-    target_cmd_root($ho, $cmd);
+    target_cmd_root($w_ho, $cmd);
+}
+
+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");
 }
 
 sub nodhcp () {
@@ -322,17 +354,56 @@ sub forbidden () {
 END
 }
 
-if ($checkmode) {
-    extract();
-} else {
-    die if @hos > 1;
-    $ho= $hos[0];
-    
+if ($nested_build eq 'nested_build') {
+    our $gho;
+    $ho= selecthost($whhost);
+    $gho= selectguest($gn,$ho);
+    $w_ho = $gho;
+    store_runvar("$gho->{Guest}_kernkind",$r{'kernkind'});
+    $gho->{Suite}=$ho->{Suite};
+
+    guest_check_ip($gho);
     packages();
     extract();
-    forbidden();
     adjustconfig();
-    setupboot();
-    setupinitd();
-    nodhcp();
+    my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
+    my $bootloader;
+    $bootloader=setupboot_grub2($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
+
+    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);
+
+    
+} else {
+
+    if ($checkmode) {
+        extract();
+    } else {
+        die if @hos > 1;
+        $ho= $hos[0];
+        $w_ho = $ho;
+        packages();
+        extract();
+        forbidden();
+        adjustconfig();
+        setupboot();
+        setupinitd();
+        nodhcp();
+    }
 }
-- 
1.7.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 Dec 10 08:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycJY-0007BL-8t; Wed, 10 Dec 2014 08:08:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XycJW-0007Ak-0y
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:08:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E4/56-15461-16FF7845; Wed, 10 Dec 2014 08:08:01 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418198877!6550709!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29749 invoked from network); 10 Dec 2014 08:07:59 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 08:07:59 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Dec 2014 00:07:58 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="651422616"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga002.jf.intel.com with ESMTP; 10 Dec 2014 00:07:56 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 16:07:37 +0800
Message-Id: <1418198860-29802-2-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
References: <1418198860-29802-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 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 preparing and installing L1 guest VM inside L0 system
on testhost machine.

---
 Osstest/Debian.pm      |   27 ++++++++++++++++++---------
 Osstest/TestSupport.pm |   31 ++++++++++++++++++++++++++-----
 sg-run-job             |    5 +++++
 ts-debian-hvm-install  |   34 ++++++++++++++++++++++++----------
 4 files changed, 73 insertions(+), 24 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..a671d20 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
@@ -34,6 +35,7 @@ BEGIN {
     @EXPORT      = qw(debian_boot_setup
                       %preseed_cmds
                       preseed_base
+                      setupboot_grub2
                       preseed_create
                       preseed_hook_command preseed_hook_installscript
                       di_installcmdline_core
@@ -286,15 +288,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 +322,25 @@ 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\S+)/) {
+#	    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 a3b6936..1e47039 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 @_;
@@ -717,6 +727,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};
@@ -937,7 +948,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);
@@ -1465,7 +1476,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'
@@ -2063,4 +2074,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..8dcf7af 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-debian-hvm-install + host + nested + nested_L1
+}
+
 proc test-guest-migr {g} {
     if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
 
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 37eade2..6dcec3c 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -28,22 +28,24 @@ 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;
+our ($whhost,$gn,$nested_L1,$guesthost) = @ARGV;
 $whhost ||= 'host';
-$gn ||= 'debianhvm';
-
+$nested_L1 ||= '';
+if ($nested_L1 eq 'nested_L1') {
+    $gn ||= 'nested';
+    $guesthost ||= "$gn.l1.osstest";
+} else {
+    $gn ||= 'debianhvm';
+    $guesthost= "$gn.guest.osstest";
+}
 our $ho= selecthost($whhost);
-
+our $disk_mb= 50000;
 # guest memory size will be set based on host free memory, see below
 our $ram_mb;
-our $disk_mb= 10000;
-
-our $guesthost= "$gn.guest.osstest";
 our $gho;
 
 our $toolstack= toolstack()->{Command};
 
-
 sub preseed () {
 
     my $preseed_file = preseed_base('wheezy','',());
@@ -63,7 +65,7 @@ d-i partman-auto/expert_recipe string \\
                         use_filesystem{ } filesystem{ vfat } \\
                         mountpoint{ /boot/efi } \\
                 . \\
-                5000 50 5000 ext4 \\
+                25000 50 25000 ext4 \\
                         method{ format } format{ } \\
                         use_filesystem{ } filesystem{ ext4 } \\
                         mountpoint{ / } \\
@@ -155,6 +157,8 @@ sub prep () {
     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);
@@ -176,6 +180,8 @@ my $ram_minslop = 100;
 my $ram_lots = 5000;
 if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
     $ram_mb = $ram_lots;
+} elsif ($nested_L1 eq 'nested_L1') {
+    $ram_mb = 2048;
 } else {
     $ram_mb = 768;
 }
@@ -192,7 +198,15 @@ if ($stage<2) {
     guest_destroy($ho,$gho);
 }
 
-guest_editconfig_nocd($gho,$emptyiso);
+if ($nested_L1 eq 'nested_L1') {
+    guest_editconfig_cd($gho);
+} else {
+    guest_editconfig_nocd($gho,$emptyiso);
+}
 guest_create($gho,$toolstack);
 guest_await_dhcp_tcp($gho,300);
 guest_check_up($gho);
+if ($nested_L1 eq 'nested_L1') {
+    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 Wed Dec 10 08:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycJW-0007Al-AK; Wed, 10 Dec 2014 08:08:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XycJU-0007Aa-Hw
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:08:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	34/B8-09842-F5FF7845; Wed, 10 Dec 2014 08:07:59 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418198877!6550709!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29523 invoked from network); 10 Dec 2014 08:07:59 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 08:07:59 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Dec 2014 00:07:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="651422600"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga002.jf.intel.com with ESMTP; 10 Dec 2014 00:07:52 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 16:07:36 +0800
Message-Id: <1418198860-29802-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(version_3) again 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

----------------------------------------------------------------
longtao.pang (4):
      Add nested testcase of preparing and installing L1 guest VM 
      Build XEN and HVM Dom0 kernel for L1 guest VM
      Add nested testcase of installing L2 guest VM
      Insert nested test job name and runvars

 Osstest/Debian.pm      |   27 +++++---
 Osstest/TestSupport.pm |   31 +++++++--
 make-flight            |   19 ++++++
 mfi-common             |    8 +++
 sg-run-job             |    8 +++
 ts-debian-hvm-install  |   34 +++++++---
 ts-debian-install      |  166 +++++++++++++++++++++++++++++++++++++-----------
 ts-xen-install         |  149 +++++++++++++++++++++++++++++++------------
 8 files changed, 343 insertions(+), 99 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 08:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycJa-0007C4-8C; Wed, 10 Dec 2014 08:08:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XycJZ-0007Ba-63
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:08:05 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FB/35-25276-46FF7845; Wed, 10 Dec 2014 08:08:04 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418198877!6550709!4
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30139 invoked from network); 10 Dec 2014 08:08:02 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 08:08:02 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Dec 2014 00:08:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="651422652"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga002.jf.intel.com with ESMTP; 10 Dec 2014 00:08:00 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 16:07:39 +0800
Message-Id: <1418198860-29802-4-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
References: <1418198860-29802-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 testcase 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 e513bd1..85f7b22 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-debian-hvm-install + host + nested + nested_L1
     run-ts . = ts-xen-install + host + nested + nested_build
+    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 Wed Dec 10 08:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycJY-0007BW-MF; Wed, 10 Dec 2014 08:08:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XycJX-0007Aw-5R
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:08:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	7D/25-25276-26FF7845; Wed, 10 Dec 2014 08:08:02 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418198877!6550709!3
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29979 invoked from network); 10 Dec 2014 08:08:01 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 08:08:01 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Dec 2014 00:08:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="651422627"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga002.jf.intel.com with ESMTP; 10 Dec 2014 00:07:58 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 16:07:38 +0800
Message-Id: <1418198860-29802-3-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
References: <1418198860-29802-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] Build 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-xen-install |  149 +++++++++++++++++++++++++++++++++++++++++---------------
 2 files changed, 111 insertions(+), 39 deletions(-)

diff --git a/sg-run-job b/sg-run-job
index 8dcf7af..e513bd1 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-debian-hvm-install + host + nested + nested_L1
+    run-ts . = ts-xen-install + host + nested + nested_build
 }
 
 proc test-guest-migr {g} {
diff --git a/ts-xen-install b/ts-xen-install
index 4d34d1f..c175d6d 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -28,19 +28,25 @@ use Osstest::CXFabric;
 my $checkmode= 0;
 
 tsreadconfig();
-
+our $w_ho;
 our @hos;
-
-if (@ARGV and $ARGV[0] eq '--check') {
-    $checkmode= 1;
-    shift @ARGV;
-    logm("checking builds are done...");
+our ($whhost,$gn,$nested_build) = @ARGV;
+$nested_build ||= '';
+if ($nested_build eq 'nested_build') {
+    $whhost ||= 'host';
+    $gn ||= 'nested';
 } else {
-    if (!@ARGV) {
-	push @ARGV, 'host';
-    }
-    foreach my $k (@ARGV) {
-        push @hos, selecthost($k);
+    if (@ARGV and $ARGV[0] eq '--check') {
+        $checkmode= 1;
+        shift @ARGV;
+        logm("checking builds are done...");
+    } else {
+        if (!@ARGV) {
+            push @ARGV, 'host';
+        }
+        foreach my $k (@ARGV) {
+            push @hos, selecthost($k);
+        }
     }
 }
 
@@ -49,18 +55,18 @@ our $ho;
 my %distpath;
 
 sub packages () {
-    target_install_packages($ho,
+    target_install_packages($w_ho,
                             qw(bridge-utils vncsnapshot libaio1 libpixman-1-0
                                libsdl1.2debian libglib2.0-0 liblzma5));
-    target_install_packages($ho,
+    target_install_packages($w_ho,
 			    $ho->{Suite} =~ /squeeze/ ? "libyajl1" : "libyajl2");
     if ($ho->{Suite} !~ m/lenny|squeeze/) {
-        target_install_packages($ho, 'libfdt1');
+        target_install_packages($w_ho, 'libfdt1');
     }
     if ($r{arch} eq 'i386') {
-	target_install_packages($ho, 'libc6-xen');
+	target_install_packages($w_ho, 'libc6-xen');
     }
-    target_install_packages($ho, @{toolstack()->{ExtraPackages}})
+    target_install_packages($w_ho, @{toolstack()->{ExtraPackages}})
         if toolstack()->{ExtraPackages};
 }
 
@@ -69,14 +75,14 @@ sub extract () {
     push @parts, 'libvirt' if $r{toolstack} eq "libvirt";
 
     foreach my $part (@parts) {
-        target_extract_jobdistpath($ho, $part, "path_${part}dist",
+        target_extract_jobdistpath($w_ho, $part, "path_${part}dist",
 				   $r{"${part}buildjob"}, \%distpath);
     }
-    target_cmd_root($ho, '/sbin/ldconfig');
+    target_cmd_root($w_ho, '/sbin/ldconfig');
 }
 
 sub adjustconfig () {
-    target_editfile_root($ho, "/etc/xen/xend-config.sxp",
+    target_editfile_root($w_ho, "/etc/xen/xend-config.sxp",
 			 "xend-config.sxp", sub {
 	my (@domains) = (qw(localhost localhost.localdomain),
 			 ".".$c{DnsDomain}, ".".$c{TestHostDomain});
@@ -108,13 +114,13 @@ sub adjustconfig () {
                         /etc/sysconfig/xencommons
                         /etc/default/xend
                         /etc/sysconfig/xend)) {
-        next unless target_file_exists($ho, $try);
+        next unless target_file_exists($w_ho, $try);
         $trace_config_file= $try;
         last;
     }
     die unless defined $trace_config_file;
 
-    target_editfile_root($ho, $trace_config_file, sub {
+    target_editfile_root($w_ho, $trace_config_file, sub {
         my $prnow;
         $prnow= sub {
             print EO "XENCONSOLED_TRACE=guest\n" or die $!;
@@ -128,7 +134,7 @@ sub adjustconfig () {
         $prnow->();
     });
 
-    target_cmd_root($ho, 'mkdir -p /var/log/xen/console');
+    target_cmd_root($w_ho, 'mkdir -p /var/log/xen/console');
 
     setup_cxfabric($ho);
 }
@@ -156,19 +162,19 @@ sub setupboot () {
     $xenhopt .= " $append" if defined $append;
 
     my @hooks;
-
+    
     if (host_involves_pcipassthrough($ho)) {
         push @hooks, {
             EditBootOptions => sub {
                 my ($ho,$hopt,$kopt) = @_;
                 $$hopt .= ' iommu=on';
                 my $hide= ' xen-pciback.hide='. join '',map { "($_->{Bdf})" }
-                    host_get_pcipassthrough_devs($ho);
+                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($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
@@ -182,7 +188,7 @@ sub setupinitd () {
     my $ts= toolstack();
     my $xencommons= '/etc/init.d/xencommons';
     my $have_xencommons=
-        !!target_cmd_output_root($ho, <<END);
+        !!target_cmd_output_root($w_ho, <<END);
  if test -f $xencommons && ! grep 'FOR USE WITH LIBXL' $xencommons >/dev/null
  then
    echo y
@@ -211,7 +217,33 @@ END
         $updatercd->($initd,93) if defined $initd;
         $updatercd->('xenbridge',38) if $ts->{OldSeparateBridgeInitd};
     }
-    target_cmd_root($ho, $cmd);
+    target_cmd_root($w_ho, $cmd);
+}
+
+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");
 }
 
 sub nodhcp () {
@@ -322,17 +354,56 @@ sub forbidden () {
 END
 }
 
-if ($checkmode) {
-    extract();
-} else {
-    die if @hos > 1;
-    $ho= $hos[0];
-    
+if ($nested_build eq 'nested_build') {
+    our $gho;
+    $ho= selecthost($whhost);
+    $gho= selectguest($gn,$ho);
+    $w_ho = $gho;
+    store_runvar("$gho->{Guest}_kernkind",$r{'kernkind'});
+    $gho->{Suite}=$ho->{Suite};
+
+    guest_check_ip($gho);
     packages();
     extract();
-    forbidden();
     adjustconfig();
-    setupboot();
-    setupinitd();
-    nodhcp();
+    my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
+    my $bootloader;
+    $bootloader=setupboot_grub2($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
+
+    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);
+
+    
+} else {
+
+    if ($checkmode) {
+        extract();
+    } else {
+        die if @hos > 1;
+        $ho= $hos[0];
+        $w_ho = $ho;
+        packages();
+        extract();
+        forbidden();
+        adjustconfig();
+        setupboot();
+        setupinitd();
+        nodhcp();
+    }
 }
-- 
1.7.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 Dec 10 08:08:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycJb-0007CW-LF; Wed, 10 Dec 2014 08:08:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <longtaox.pang@intel.com>) id 1XycJa-0007C1-DG
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:08:06 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C6/F8-09842-56FF7845; Wed, 10 Dec 2014 08:08:05 +0000
X-Env-Sender: longtaox.pang@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418198884!14551606!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32604 invoked from network); 10 Dec 2014 08:08:04 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 08:08:04 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 10 Dec 2014 00:08:03 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="651422673"
Received: from unknown (HELO OSSTEST.tsp.org) ([10.239.48.107])
	by orsmga002.jf.intel.com with ESMTP; 10 Dec 2014 00:08:02 -0800
From: "longtao.pang" <longtaox.pang@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 16:07:40 +0800
Message-Id: <1418198860-29802-5-git-send-email-longtaox.pang@intel.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
References: <1418198860-29802-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 into
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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..b65f0b5 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=v3.16                                         \
+                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 Wed Dec 10 08:17:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycSV-0008H8-Nc; Wed, 10 Dec 2014 08:17:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XycSV-0008H3-6r
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 08:17:19 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	B8/38-03148-D8108845; Wed, 10 Dec 2014 08:17:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418199437!14101728!1
X-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 8321 invoked from network); 10 Dec 2014 08:17:17 -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 Dec 2014 08:17:17 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 08:17:16 +0000
Message-Id: <54880F9B020000780004E6CC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 08:17:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <1708243085.20141209172445@eikelenboom.it>
	<54873F74020000780004E442@mail.emea.novell.com>
	<2010536337.20141209190532@eikelenboom.it>
In-Reply-To: <2010536337.20141209190532@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: irq.c:xxxx: dom1: forcing unbind of
	pirq 40
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 19:05, <linux@eikelenboom.it> wrote:
> Tuesday, December 9, 2014, 6:29:08 PM, you wrote:
>> I see these too when Dom0 shuts down,
>> at least for certain drivers. For HVM arguably qemu might know
>> better and tear things down properly, but in no event are these
>> messages - when occurring in connection with a guest going
>> down - indications of a problem. We could even see to lower their
>> severity or suppress them altogether when the domain is known
>> to be dying (you may want to check whether ->is_dying is already
>> set at that point).
> 
> Just tested, but for both PV and HVM when it enters "unmap_domain_pirq" 
> d->is_dying ? 1 : 0 returns 0.

Thanks for confirming - that's what I vaguely recalled from when
having added that warning.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 08:17:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XycSV-0008H8-Nc; Wed, 10 Dec 2014 08:17:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XycSV-0008H3-6r
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 08:17:19 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	B8/38-03148-D8108845; Wed, 10 Dec 2014 08:17:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418199437!14101728!1
X-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 8321 invoked from network); 10 Dec 2014 08:17:17 -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 Dec 2014 08:17:17 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 08:17:16 +0000
Message-Id: <54880F9B020000780004E6CC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 08:17:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <1708243085.20141209172445@eikelenboom.it>
	<54873F74020000780004E442@mail.emea.novell.com>
	<2010536337.20141209190532@eikelenboom.it>
In-Reply-To: <2010536337.20141209190532@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen-unstable: irq.c:xxxx: dom1: forcing unbind of
	pirq 40
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.12.14 at 19:05, <linux@eikelenboom.it> wrote:
> Tuesday, December 9, 2014, 6:29:08 PM, you wrote:
>> I see these too when Dom0 shuts down,
>> at least for certain drivers. For HVM arguably qemu might know
>> better and tear things down properly, but in no event are these
>> messages - when occurring in connection with a guest going
>> down - indications of a problem. We could even see to lower their
>> severity or suppress them altogether when the domain is known
>> to be dying (you may want to check whether ->is_dying is already
>> set at that point).
> 
> Just tested, but for both PV and HVM when it enters "unmap_domain_pirq" 
> d->is_dying ? 1 : 0 returns 0.

Thanks for confirming - that's what I vaguely recalled from when
having added that warning.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 08:19:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XycUk-0008NG-7x; Wed, 10 Dec 2014 08:19: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 1XycUi-0008NA-V9
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:19:37 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	CD/99-23865-81208845; Wed, 10 Dec 2014 08:19:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418199573!12125800!1
X-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 6527 invoked from network); 10 Dec 2014 08:19:34 -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; 10 Dec 2014 08:19:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 08:19:32 +0000
Message-Id: <54881021020000780004E6D3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 08:19:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-13-git-send-email-wei.liu2@citrix.com>
	<5487356E020000780004E362@mail.emea.novell.com>
	<20141209175242.GF25749@zion.uk.xensource.com>
In-Reply-To: <20141209175242.GF25749@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 12/19] hvmloader: retrieve vNUMA
 information from 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 09.12.14 at 18:52, <wei.liu2@citrix.com> wrote:
> On Tue, Dec 09, 2014 at 04:46:22PM +0000, Jan Beulich wrote:
>> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
>> > + */
>> > +
>> > +#ifndef __HVMLOADER_VNUMA_H__
>> > +#define __HVMLOADER_VNUMA_H__
>> > +
>> > +#include <xen/memory.h>
>> > +
>> > +#define MAX_VNODES     64
>> > +#define MAX_VDISTANCE  (MAX_VNODES * MAX_VNODES)
>> > +#define MAX_VMEMRANGES (MAX_VNODES * 2)
>> 
>> These look arbitrary - please add a (brief) comment giving some
>> rationale so that people needing to change them know eventual
>> consequences. Would it perhaps make sense to derive
>> MAX_VNODES from HVM_MAX_VCPUS? Additionally I think the
> 
> I don't think these two have very strong connection though.
> 
> And I remember you saying HVM_MAX_VCPUS will be removed.

Removed? I recall myself saying increased...

>> code wouldn't become much more difficult if you didn't build in
>> static upper limits.
>> 
> 
> Yes I can make two hypercalls. First one to retrieve the number of nodes
> / vmemranges configured, allocate memory then fill in those arrays with
> second hypercall.

That'd be great, as it would eliminate the point above at once.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 08:19:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XycUk-0008NG-7x; Wed, 10 Dec 2014 08:19: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 1XycUi-0008NA-V9
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:19:37 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	CD/99-23865-81208845; Wed, 10 Dec 2014 08:19:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418199573!12125800!1
X-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 6527 invoked from network); 10 Dec 2014 08:19:34 -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; 10 Dec 2014 08:19:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 08:19:32 +0000
Message-Id: <54881021020000780004E6D3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 08:19:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-13-git-send-email-wei.liu2@citrix.com>
	<5487356E020000780004E362@mail.emea.novell.com>
	<20141209175242.GF25749@zion.uk.xensource.com>
In-Reply-To: <20141209175242.GF25749@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 12/19] hvmloader: retrieve vNUMA
 information from 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 09.12.14 at 18:52, <wei.liu2@citrix.com> wrote:
> On Tue, Dec 09, 2014 at 04:46:22PM +0000, Jan Beulich wrote:
>> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
>> > + */
>> > +
>> > +#ifndef __HVMLOADER_VNUMA_H__
>> > +#define __HVMLOADER_VNUMA_H__
>> > +
>> > +#include <xen/memory.h>
>> > +
>> > +#define MAX_VNODES     64
>> > +#define MAX_VDISTANCE  (MAX_VNODES * MAX_VNODES)
>> > +#define MAX_VMEMRANGES (MAX_VNODES * 2)
>> 
>> These look arbitrary - please add a (brief) comment giving some
>> rationale so that people needing to change them know eventual
>> consequences. Would it perhaps make sense to derive
>> MAX_VNODES from HVM_MAX_VCPUS? Additionally I think the
> 
> I don't think these two have very strong connection though.
> 
> And I remember you saying HVM_MAX_VCPUS will be removed.

Removed? I recall myself saying increased...

>> code wouldn't become much more difficult if you didn't build in
>> static upper limits.
>> 
> 
> Yes I can make two hypercalls. First one to retrieve the number of nodes
> / vmemranges configured, allocate memory then fill in those arrays with
> second hypercall.

That'd be great, as it would eliminate the point above at once.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 08:20:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08:20:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XycVo-0008TM-MF; Wed, 10 Dec 2014 08:20: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 1XycVn-0008T8-HR
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:20:43 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	37/8F-14727-A5208845; Wed, 10 Dec 2014 08:20:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418199642!9146988!1
X-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 4501 invoked from network); 10 Dec 2014 08:20: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; 10 Dec 2014 08:20:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 08:20:41 +0000
Message-Id: <54881066020000780004E6D6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 08:20:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
	<54873724020000780004E37B@mail.emea.novell.com>
	<20141209180657.GG25749@zion.uk.xensource.com>
In-Reply-To: <20141209180657.GG25749@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 13/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 09.12.14 at 19:06, <wei.liu2@citrix.com> wrote:
> On Tue, Dec 09, 2014 at 04:53:40PM +0000, Jan Beulich wrote:
>> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
>> > +        memset(memory, 0, sizeof(*memory));
>> > +        memory->type          = ACPI_MEMORY_AFFINITY;
>> > +        memory->length        = sizeof(*memory);
>> > +        memory->domain        = vmemrange[i].nid;
>> > +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
>> > +        memory->base_address  = vmemrange[i].start;
>> > +        memory->mem_length    = mem;
>> > +        memory++;
>> > +    }
>> > +
>> > +    srat->header.length = size;
>> 
>> Mind checking size == memory - p here?
>> 
> 
> Why? There doesn't seem to be anything that would cause memory -p !=
> size in between during runtime.

Except for that original calculation being wrong - that's what I would
mean such a check to verify.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 08:20:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08:20:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XycVo-0008TM-MF; Wed, 10 Dec 2014 08:20: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 1XycVn-0008T8-HR
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:20:43 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	37/8F-14727-A5208845; Wed, 10 Dec 2014 08:20:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418199642!9146988!1
X-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 4501 invoked from network); 10 Dec 2014 08:20: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; 10 Dec 2014 08:20:42 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 08:20:41 +0000
Message-Id: <54881066020000780004E6D6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 08:20:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
	<54873724020000780004E37B@mail.emea.novell.com>
	<20141209180657.GG25749@zion.uk.xensource.com>
In-Reply-To: <20141209180657.GG25749@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 13/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 09.12.14 at 19:06, <wei.liu2@citrix.com> wrote:
> On Tue, Dec 09, 2014 at 04:53:40PM +0000, Jan Beulich wrote:
>> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
>> > +        memset(memory, 0, sizeof(*memory));
>> > +        memory->type          = ACPI_MEMORY_AFFINITY;
>> > +        memory->length        = sizeof(*memory);
>> > +        memory->domain        = vmemrange[i].nid;
>> > +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
>> > +        memory->base_address  = vmemrange[i].start;
>> > +        memory->mem_length    = mem;
>> > +        memory++;
>> > +    }
>> > +
>> > +    srat->header.length = size;
>> 
>> Mind checking size == memory - p here?
>> 
> 
> Why? There doesn't seem to be anything that would cause memory -p !=
> size in between during runtime.

Except for that original calculation being wrong - that's what I would
mean such a check to verify.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 08:39:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08:39:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xycnn-0000mr-Dc; Wed, 10 Dec 2014 08:39:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xycnm-0000mm-4i
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:39:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F1/41-25276-4B608845; Wed, 10 Dec 2014 08:39:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418200756!14599028!1
X-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 3770 invoked from network); 10 Dec 2014 08:39:16 -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; 10 Dec 2014 08:39:16 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 08:39:15 +0000
Message-Id: <548814C2020000780004E6F9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 08:39:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>,
	"Zhang Yu" <yu.c.zhang@linux.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.12.14 at 02:07, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Tuesday, December 09, 2014 6:50 PM
>> 
>> >>> On 09.12.14 at 11:37, <yu.c.zhang@linux.intel.com> wrote:
>> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
>> >> I think use of an raw mfn value currently works only because dom0 is using
>> a
>> > 1:1 IOMMU mapping scheme. Is my understanding correct, or do you really
>> need
>> > raw mfn values?
>> > Thanks for your quick response, Paul.
>> > Well, not exactly for this case. :)
>> > In XenGT, our need to translate gfn to mfn is for GPU's page table,
>> > which contains the translation between graphic address and the memory
>> > address. This page table is maintained by GPU drivers, and our service
>> > domain need to have a method to translate the guest physical addresses
>> > written by the vGPU into host physical ones.
>> > We do not use IOMMU in XenGT and therefore this translation may not
>> > necessarily be a 1:1 mapping.
>> 
>> Hmm, that suggests you indeed need raw MFNs, which in turn seems
>> problematic wrt PVH Dom0 (or you'd need a GFN->GMFN translation
>> layer). But while you don't use the IOMMU yourself, I suppose the GPU
>> accesses still don't bypass the IOMMU? In which case all you'd need
>> returned is a frame number that guarantees that after IOMMU
>> translation it refers to the correct MFN, i.e. still allowing for your Dom0
>> driver to simply set aside a part of its PFN space, asking Xen to
>> (IOMMU-)map the necessary guest frames into there.
>> 
> 
> No. What we require is the raw MFNs. One IOMMU device entry can't
> point to multiple VM's page tables, so that's why XenGT needs to use
> software shadow GPU page table to implement the sharing. Note it's
> not for dom0 to access the MFN. It's for dom0 to setup the correct
> shadow GPU page table, so a VM can access the graphics memory
> in a controlled way.

So what's the translation flow here: driver -> GPU -> IOMMU ->
hardware or driver -> IOMMU -> GPU -> hardware? Or do things get
set up for the GPU to bypass the IOMMU altogether?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 08:39:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08:39:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xycnn-0000mr-Dc; Wed, 10 Dec 2014 08:39:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xycnm-0000mm-4i
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:39:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F1/41-25276-4B608845; Wed, 10 Dec 2014 08:39:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418200756!14599028!1
X-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 3770 invoked from network); 10 Dec 2014 08:39:16 -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; 10 Dec 2014 08:39:16 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 08:39:15 +0000
Message-Id: <548814C2020000780004E6F9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 08:39:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>,
	"Zhang Yu" <yu.c.zhang@linux.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.12.14 at 02:07, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Tuesday, December 09, 2014 6:50 PM
>> 
>> >>> On 09.12.14 at 11:37, <yu.c.zhang@linux.intel.com> wrote:
>> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
>> >> I think use of an raw mfn value currently works only because dom0 is using
>> a
>> > 1:1 IOMMU mapping scheme. Is my understanding correct, or do you really
>> need
>> > raw mfn values?
>> > Thanks for your quick response, Paul.
>> > Well, not exactly for this case. :)
>> > In XenGT, our need to translate gfn to mfn is for GPU's page table,
>> > which contains the translation between graphic address and the memory
>> > address. This page table is maintained by GPU drivers, and our service
>> > domain need to have a method to translate the guest physical addresses
>> > written by the vGPU into host physical ones.
>> > We do not use IOMMU in XenGT and therefore this translation may not
>> > necessarily be a 1:1 mapping.
>> 
>> Hmm, that suggests you indeed need raw MFNs, which in turn seems
>> problematic wrt PVH Dom0 (or you'd need a GFN->GMFN translation
>> layer). But while you don't use the IOMMU yourself, I suppose the GPU
>> accesses still don't bypass the IOMMU? In which case all you'd need
>> returned is a frame number that guarantees that after IOMMU
>> translation it refers to the correct MFN, i.e. still allowing for your Dom0
>> driver to simply set aside a part of its PFN space, asking Xen to
>> (IOMMU-)map the necessary guest frames into there.
>> 
> 
> No. What we require is the raw MFNs. One IOMMU device entry can't
> point to multiple VM's page tables, so that's why XenGT needs to use
> software shadow GPU page table to implement the sharing. Note it's
> not for dom0 to access the MFN. It's for dom0 to setup the correct
> shadow GPU page table, so a VM can access the graphics memory
> in a controlled way.

So what's the translation flow here: driver -> GPU -> IOMMU ->
hardware or driver -> IOMMU -> GPU -> hardware? Or do things get
set up for the GPU to bypass the IOMMU altogether?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 08:42:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08:42:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XycqR-0000xE-00; Wed, 10 Dec 2014 08:42: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 1XycqQ-0000x7-0U
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 08:42:02 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	BF/97-17735-95708845; Wed, 10 Dec 2014 08:42:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418200919!7824000!1
X-Originating-IP: [66.165.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 14413 invoked from network); 10 Dec 2014 08:42:00 -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 Dec 2014 08:42:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202318629"
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.210.2; Wed, 10 Dec 2014 03:41: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 1XycqL-0006tP-JX;
	Wed, 10 Dec 2014 08:41:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XycqL-00024Q-Dj;
	Wed, 10 Dec 2014 08:41:57 +0000
Date: Wed, 10 Dec 2014 08:41:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32162-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] 32162: 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 32162 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32162/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 31897
 build-amd64-rumpuserxen       3 host-install(3)         broken REGR. vs. 31897
 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 31897
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 31897

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair         17 guest-migrate/src_host/dst_host fail like 31897
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31897

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-amd64-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
 build-i386-rumpuserxen        5 rumpuserxen-build            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-qemut-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-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-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-i386-i386-xl-qemuu-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

version targeted for testing:
 xen                  353de6b221c2d0fb59edfceb1f535357e4d84825
baseline version:
 xen                  3e5c06aeea1ff91c3f2247baae372936b67cf411

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      broken  
 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                     broken  
 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                         broken  
 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                                        fail    
 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-i386-qemut-rhel6hvm-intel host-install(3)
broken-step build-amd64-rumpuserxen host-install(3)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit 353de6b221c2d0fb59edfceb1f535357e4d84825
Author: Keir Fraser <keir@xen.org>
Date:   Mon Dec 8 15:32:04 2014 +0100

    switch to write-biased r/w locks
    
    This is to improve fairness: A permanent flow of read acquires can
    otherwise lock out eventual writers indefinitely.
    
    This is CVE-2014-9065 / XSA-114.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
    master date: 2014-12-08 14:45:46 +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 Dec 10 08:42:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08:42:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XycqR-0000xE-00; Wed, 10 Dec 2014 08:42: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 1XycqQ-0000x7-0U
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 08:42:02 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	BF/97-17735-95708845; Wed, 10 Dec 2014 08:42:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418200919!7824000!1
X-Originating-IP: [66.165.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 14413 invoked from network); 10 Dec 2014 08:42:00 -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 Dec 2014 08:42:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202318629"
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.210.2; Wed, 10 Dec 2014 03:41: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 1XycqL-0006tP-JX;
	Wed, 10 Dec 2014 08:41:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XycqL-00024Q-Dj;
	Wed, 10 Dec 2014 08:41:57 +0000
Date: Wed, 10 Dec 2014 08:41:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32162-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] 32162: 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 32162 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32162/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 31897
 build-amd64-rumpuserxen       3 host-install(3)         broken REGR. vs. 31897
 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 31897
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 31897

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair         17 guest-migrate/src_host/dst_host fail like 31897
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31897

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-amd64-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
 build-i386-rumpuserxen        5 rumpuserxen-build            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-qemut-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-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-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-i386-i386-xl-qemuu-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

version targeted for testing:
 xen                  353de6b221c2d0fb59edfceb1f535357e4d84825
baseline version:
 xen                  3e5c06aeea1ff91c3f2247baae372936b67cf411

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      broken  
 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                     broken  
 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                         broken  
 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                                        fail    
 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-i386-qemut-rhel6hvm-intel host-install(3)
broken-step build-amd64-rumpuserxen host-install(3)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit 353de6b221c2d0fb59edfceb1f535357e4d84825
Author: Keir Fraser <keir@xen.org>
Date:   Mon Dec 8 15:32:04 2014 +0100

    switch to write-biased r/w locks
    
    This is to improve fairness: A permanent flow of read acquires can
    otherwise lock out eventual writers indefinitely.
    
    This is CVE-2014-9065 / XSA-114.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
    master date: 2014-12-08 14:45:46 +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 Dec 10 08:49:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08:49:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xycxg-0001LY-4W; Wed, 10 Dec 2014 08:49:32 +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 1Xycxe-0001LT-4u
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:49:30 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	42/0F-22777-91908845; Wed, 10 Dec 2014 08:49:29 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418201368!12524966!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 16044 invoked from network); 10 Dec 2014 08:49:28 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-206.messagelabs.com with SMTP;
	10 Dec 2014 08:49:28 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga102.jf.intel.com with ESMTP; 10 Dec 2014 00:48:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="496517558"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
	by orsmga003.jf.intel.com with ESMTP; 10 Dec 2014 00:45:38 -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; Wed, 10 Dec 2014 16:47:57 +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, 10 Dec 2014 16:47:56 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Zhang Yu <yu.c.zhang@linux.intel.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGhdsAgAAFC4CAAAOQAIABdNew///48wCAAIZgkA==
Date: Wed, 10 Dec 2014 08:47:56 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126115303@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
	<548814C2020000780004E6F9@mail.emea.novell.com>
In-Reply-To: <548814C2020000780004E6F9@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 \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, December 10, 2014 4:39 PM
> 
> >>> On 10.12.14 at 02:07, <kevin.tian@intel.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Tuesday, December 09, 2014 6:50 PM
> >>
> >> >>> On 09.12.14 at 11:37, <yu.c.zhang@linux.intel.com> wrote:
> >> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
> >> >> I think use of an raw mfn value currently works only because dom0 is
> using
> >> a
> >> > 1:1 IOMMU mapping scheme. Is my understanding correct, or do you
> really
> >> need
> >> > raw mfn values?
> >> > Thanks for your quick response, Paul.
> >> > Well, not exactly for this case. :)
> >> > In XenGT, our need to translate gfn to mfn is for GPU's page table,
> >> > which contains the translation between graphic address and the memory
> >> > address. This page table is maintained by GPU drivers, and our service
> >> > domain need to have a method to translate the guest physical addresses
> >> > written by the vGPU into host physical ones.
> >> > We do not use IOMMU in XenGT and therefore this translation may not
> >> > necessarily be a 1:1 mapping.
> >>
> >> Hmm, that suggests you indeed need raw MFNs, which in turn seems
> >> problematic wrt PVH Dom0 (or you'd need a GFN->GMFN translation
> >> layer). But while you don't use the IOMMU yourself, I suppose the GPU
> >> accesses still don't bypass the IOMMU? In which case all you'd need
> >> returned is a frame number that guarantees that after IOMMU
> >> translation it refers to the correct MFN, i.e. still allowing for your Dom0
> >> driver to simply set aside a part of its PFN space, asking Xen to
> >> (IOMMU-)map the necessary guest frames into there.
> >>
> >
> > No. What we require is the raw MFNs. One IOMMU device entry can't
> > point to multiple VM's page tables, so that's why XenGT needs to use
> > software shadow GPU page table to implement the sharing. Note it's
> > not for dom0 to access the MFN. It's for dom0 to setup the correct
> > shadow GPU page table, so a VM can access the graphics memory
> > in a controlled way.
> 
> So what's the translation flow here: driver -> GPU -> IOMMU ->
> hardware or driver -> IOMMU -> GPU -> hardware? Or do things get
> set up for the GPU to bypass the IOMMU altogether?
> 

two translation paths in assigned case:

1. [direct CPU access from VM], with partitioned PCI aperture
resource, every VM can access a portion of PCI aperture directly.

- CPU page table/EPT: CPU virtual address->PCI aperture
- PCI aperture - bar base = Graphics Memory Address (GMA)
- GPU page table: GMA -> GPA (as programmed by guest)
- IOMMU: GPA -> MPA

2. [GPU access through GPU command operands], with GPU scheduling,
every VM's command buffer will be fetched by GPU in a time-shared
manner.

- GPU page table: GMA->GPA
- IOMMU: GPA->MPA

In our case, IOMMU is setup with 1:1 identity table for dom0. So 
when GPU may access GPAs from different VMs, we can't count on
IOMMU which can only serve one mapping for one device (unless 
we have SR-IOV). 

That's why we need shadow GPU page table in dom0, and need a
p2m query call to translate from GPA -> MPA:

- shadow GPU page table: GMA->MPA
- IOMMU: MPA->MPA (for dom0)

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 Dec 10 08:49:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08:49:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xycxg-0001LY-4W; Wed, 10 Dec 2014 08:49:32 +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 1Xycxe-0001LT-4u
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:49:30 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	42/0F-22777-91908845; Wed, 10 Dec 2014 08:49:29 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418201368!12524966!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 16044 invoked from network); 10 Dec 2014 08:49:28 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-206.messagelabs.com with SMTP;
	10 Dec 2014 08:49:28 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga102.jf.intel.com with ESMTP; 10 Dec 2014 00:48:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="496517558"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
	by orsmga003.jf.intel.com with ESMTP; 10 Dec 2014 00:45:38 -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; Wed, 10 Dec 2014 16:47:57 +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, 10 Dec 2014 16:47:56 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Zhang Yu <yu.c.zhang@linux.intel.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGhdsAgAAFC4CAAAOQAIABdNew///48wCAAIZgkA==
Date: Wed, 10 Dec 2014 08:47:56 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126115303@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
	<548814C2020000780004E6F9@mail.emea.novell.com>
In-Reply-To: <548814C2020000780004E6F9@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 \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, December 10, 2014 4:39 PM
> 
> >>> On 10.12.14 at 02:07, <kevin.tian@intel.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Tuesday, December 09, 2014 6:50 PM
> >>
> >> >>> On 09.12.14 at 11:37, <yu.c.zhang@linux.intel.com> wrote:
> >> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
> >> >> I think use of an raw mfn value currently works only because dom0 is
> using
> >> a
> >> > 1:1 IOMMU mapping scheme. Is my understanding correct, or do you
> really
> >> need
> >> > raw mfn values?
> >> > Thanks for your quick response, Paul.
> >> > Well, not exactly for this case. :)
> >> > In XenGT, our need to translate gfn to mfn is for GPU's page table,
> >> > which contains the translation between graphic address and the memory
> >> > address. This page table is maintained by GPU drivers, and our service
> >> > domain need to have a method to translate the guest physical addresses
> >> > written by the vGPU into host physical ones.
> >> > We do not use IOMMU in XenGT and therefore this translation may not
> >> > necessarily be a 1:1 mapping.
> >>
> >> Hmm, that suggests you indeed need raw MFNs, which in turn seems
> >> problematic wrt PVH Dom0 (or you'd need a GFN->GMFN translation
> >> layer). But while you don't use the IOMMU yourself, I suppose the GPU
> >> accesses still don't bypass the IOMMU? In which case all you'd need
> >> returned is a frame number that guarantees that after IOMMU
> >> translation it refers to the correct MFN, i.e. still allowing for your Dom0
> >> driver to simply set aside a part of its PFN space, asking Xen to
> >> (IOMMU-)map the necessary guest frames into there.
> >>
> >
> > No. What we require is the raw MFNs. One IOMMU device entry can't
> > point to multiple VM's page tables, so that's why XenGT needs to use
> > software shadow GPU page table to implement the sharing. Note it's
> > not for dom0 to access the MFN. It's for dom0 to setup the correct
> > shadow GPU page table, so a VM can access the graphics memory
> > in a controlled way.
> 
> So what's the translation flow here: driver -> GPU -> IOMMU ->
> hardware or driver -> IOMMU -> GPU -> hardware? Or do things get
> set up for the GPU to bypass the IOMMU altogether?
> 

two translation paths in assigned case:

1. [direct CPU access from VM], with partitioned PCI aperture
resource, every VM can access a portion of PCI aperture directly.

- CPU page table/EPT: CPU virtual address->PCI aperture
- PCI aperture - bar base = Graphics Memory Address (GMA)
- GPU page table: GMA -> GPA (as programmed by guest)
- IOMMU: GPA -> MPA

2. [GPU access through GPU command operands], with GPU scheduling,
every VM's command buffer will be fetched by GPU in a time-shared
manner.

- GPU page table: GMA->GPA
- IOMMU: GPA->MPA

In our case, IOMMU is setup with 1:1 identity table for dom0. So 
when GPU may access GPAs from different VMs, we can't count on
IOMMU which can only serve one mapping for one device (unless 
we have SR-IOV). 

That's why we need shadow GPU page table in dom0, and need a
p2m query call to translate from GPA -> MPA:

- shadow GPU page table: GMA->MPA
- IOMMU: MPA->MPA (for dom0)

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 Dec 10 08:51:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XyczC-0001Qh-Jn; Wed, 10 Dec 2014 08:51:06 +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 1XyczA-0001QX-9X
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:51:04 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	B2/18-26740-77908845; Wed, 10 Dec 2014 08:51:03 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418201461!12296996!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13598 invoked from network); 10 Dec 2014 08:51:02 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 08:51:02 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 10 Dec 2014 00:51:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="635436173"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by fmsmga001.fm.intel.com with ESMTP; 10 Dec 2014 00:50:58 -0800
Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 16:50:32 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 16:50:31 +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, 10 Dec 2014 16:50:30 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Zhang Yu <yu.c.zhang@linux.intel.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGhdsAgAAFC4CAAAOQAIABdNew///48wCAAIZgkIAAAmuw
Date: Wed, 10 Dec 2014 08:50:30 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126115312@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
	<548814C2020000780004E6F9@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 \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tian, Kevin
> Sent: Wednesday, December 10, 2014 4:48 PM
> 
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: Wednesday, December 10, 2014 4:39 PM
> >
> > >>> On 10.12.14 at 02:07, <kevin.tian@intel.com> wrote:
> > >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> > >> Sent: Tuesday, December 09, 2014 6:50 PM
> > >>
> > >> >>> On 09.12.14 at 11:37, <yu.c.zhang@linux.intel.com> wrote:
> > >> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
> > >> >> I think use of an raw mfn value currently works only because dom0 is
> > using
> > >> a
> > >> > 1:1 IOMMU mapping scheme. Is my understanding correct, or do you
> > really
> > >> need
> > >> > raw mfn values?
> > >> > Thanks for your quick response, Paul.
> > >> > Well, not exactly for this case. :)
> > >> > In XenGT, our need to translate gfn to mfn is for GPU's page table,
> > >> > which contains the translation between graphic address and the
> memory
> > >> > address. This page table is maintained by GPU drivers, and our service
> > >> > domain need to have a method to translate the guest physical
> addresses
> > >> > written by the vGPU into host physical ones.
> > >> > We do not use IOMMU in XenGT and therefore this translation may not
> > >> > necessarily be a 1:1 mapping.
> > >>
> > >> Hmm, that suggests you indeed need raw MFNs, which in turn seems
> > >> problematic wrt PVH Dom0 (or you'd need a GFN->GMFN translation
> > >> layer). But while you don't use the IOMMU yourself, I suppose the GPU
> > >> accesses still don't bypass the IOMMU? In which case all you'd need
> > >> returned is a frame number that guarantees that after IOMMU
> > >> translation it refers to the correct MFN, i.e. still allowing for your Dom0
> > >> driver to simply set aside a part of its PFN space, asking Xen to
> > >> (IOMMU-)map the necessary guest frames into there.
> > >>
> > >
> > > No. What we require is the raw MFNs. One IOMMU device entry can't
> > > point to multiple VM's page tables, so that's why XenGT needs to use
> > > software shadow GPU page table to implement the sharing. Note it's
> > > not for dom0 to access the MFN. It's for dom0 to setup the correct
> > > shadow GPU page table, so a VM can access the graphics memory
> > > in a controlled way.
> >
> > So what's the translation flow here: driver -> GPU -> IOMMU ->
> > hardware or driver -> IOMMU -> GPU -> hardware? Or do things get
> > set up for the GPU to bypass the IOMMU altogether?
> >
> 
> two translation paths in assigned case:
> 
> 1. [direct CPU access from VM], with partitioned PCI aperture
> resource, every VM can access a portion of PCI aperture directly.

sorry the above description is for XenGT shared case, and the 
below translation is for VT-d assigned case. Just put there to indicate
the necessity of same translation path in XenGT.

> 
> - CPU page table/EPT: CPU virtual address->PCI aperture
> - PCI aperture - bar base = Graphics Memory Address (GMA)
> - GPU page table: GMA -> GPA (as programmed by guest)
> - IOMMU: GPA -> MPA
> 
> 2. [GPU access through GPU command operands], with GPU scheduling,
> every VM's command buffer will be fetched by GPU in a time-shared
> manner.
> 
> - GPU page table: GMA->GPA
> - IOMMU: GPA->MPA
> 
> In our case, IOMMU is setup with 1:1 identity table for dom0. So
> when GPU may access GPAs from different VMs, we can't count on
> IOMMU which can only serve one mapping for one device (unless
> we have SR-IOV).
> 
> That's why we need shadow GPU page table in dom0, and need a
> p2m query call to translate from GPA -> MPA:
> 
> - shadow GPU page table: GMA->MPA
> - IOMMU: MPA->MPA (for dom0)
> 
> 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 Dec 10 08:51:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 08: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 1XyczC-0001Qh-Jn; Wed, 10 Dec 2014 08:51:06 +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 1XyczA-0001QX-9X
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 08:51:04 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	B2/18-26740-77908845; Wed, 10 Dec 2014 08:51:03 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418201461!12296996!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13598 invoked from network); 10 Dec 2014 08:51:02 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 08:51:02 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 10 Dec 2014 00:51:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="635436173"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by fmsmga001.fm.intel.com with ESMTP; 10 Dec 2014 00:50:58 -0800
Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 16:50:32 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 16:50:31 +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, 10 Dec 2014 16:50:30 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Zhang Yu <yu.c.zhang@linux.intel.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGhdsAgAAFC4CAAAOQAIABdNew///48wCAAIZgkIAAAmuw
Date: Wed, 10 Dec 2014 08:50:30 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126115312@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
	<548814C2020000780004E6F9@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 \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tian, Kevin
> Sent: Wednesday, December 10, 2014 4:48 PM
> 
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: Wednesday, December 10, 2014 4:39 PM
> >
> > >>> On 10.12.14 at 02:07, <kevin.tian@intel.com> wrote:
> > >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> > >> Sent: Tuesday, December 09, 2014 6:50 PM
> > >>
> > >> >>> On 09.12.14 at 11:37, <yu.c.zhang@linux.intel.com> wrote:
> > >> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
> > >> >> I think use of an raw mfn value currently works only because dom0 is
> > using
> > >> a
> > >> > 1:1 IOMMU mapping scheme. Is my understanding correct, or do you
> > really
> > >> need
> > >> > raw mfn values?
> > >> > Thanks for your quick response, Paul.
> > >> > Well, not exactly for this case. :)
> > >> > In XenGT, our need to translate gfn to mfn is for GPU's page table,
> > >> > which contains the translation between graphic address and the
> memory
> > >> > address. This page table is maintained by GPU drivers, and our service
> > >> > domain need to have a method to translate the guest physical
> addresses
> > >> > written by the vGPU into host physical ones.
> > >> > We do not use IOMMU in XenGT and therefore this translation may not
> > >> > necessarily be a 1:1 mapping.
> > >>
> > >> Hmm, that suggests you indeed need raw MFNs, which in turn seems
> > >> problematic wrt PVH Dom0 (or you'd need a GFN->GMFN translation
> > >> layer). But while you don't use the IOMMU yourself, I suppose the GPU
> > >> accesses still don't bypass the IOMMU? In which case all you'd need
> > >> returned is a frame number that guarantees that after IOMMU
> > >> translation it refers to the correct MFN, i.e. still allowing for your Dom0
> > >> driver to simply set aside a part of its PFN space, asking Xen to
> > >> (IOMMU-)map the necessary guest frames into there.
> > >>
> > >
> > > No. What we require is the raw MFNs. One IOMMU device entry can't
> > > point to multiple VM's page tables, so that's why XenGT needs to use
> > > software shadow GPU page table to implement the sharing. Note it's
> > > not for dom0 to access the MFN. It's for dom0 to setup the correct
> > > shadow GPU page table, so a VM can access the graphics memory
> > > in a controlled way.
> >
> > So what's the translation flow here: driver -> GPU -> IOMMU ->
> > hardware or driver -> IOMMU -> GPU -> hardware? Or do things get
> > set up for the GPU to bypass the IOMMU altogether?
> >
> 
> two translation paths in assigned case:
> 
> 1. [direct CPU access from VM], with partitioned PCI aperture
> resource, every VM can access a portion of PCI aperture directly.

sorry the above description is for XenGT shared case, and the 
below translation is for VT-d assigned case. Just put there to indicate
the necessity of same translation path in XenGT.

> 
> - CPU page table/EPT: CPU virtual address->PCI aperture
> - PCI aperture - bar base = Graphics Memory Address (GMA)
> - GPU page table: GMA -> GPA (as programmed by guest)
> - IOMMU: GPA -> MPA
> 
> 2. [GPU access through GPU command operands], with GPU scheduling,
> every VM's command buffer will be fetched by GPU in a time-shared
> manner.
> 
> - GPU page table: GMA->GPA
> - IOMMU: GPA->MPA
> 
> In our case, IOMMU is setup with 1:1 identity table for dom0. So
> when GPU may access GPAs from different VMs, we can't count on
> IOMMU which can only serve one mapping for one device (unless
> we have SR-IOV).
> 
> That's why we need shadow GPU page table in dom0, and need a
> p2m query call to translate from GPA -> MPA:
> 
> - shadow GPU page table: GMA->MPA
> - IOMMU: MPA->MPA (for dom0)
> 
> 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 Dec 10 09:01:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09: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 1Xyd91-0001wN-6s; Wed, 10 Dec 2014 09:01: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 1Xyd8z-0001wI-7L
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 09:01:13 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	47/83-02696-8DB08845; Wed, 10 Dec 2014 09:01:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418202070!14102156!1
X-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 19928 invoked from network); 10 Dec 2014 09:01:10 -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; 10 Dec 2014 09:01:10 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 09:01:09 +0000
Message-Id: <548819E3020000780004E726@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 09:01:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114F15@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 Deegan <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>, Tiejun Chen <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 04:39, <kevin.tian@intel.com> wrote:
> 1. It's more efficient for new people to start from a small, well-defined 
> task
> in one area, and then spanning to adjacent areas gradually. Patience must 
> be given by the community to help them grow;

Yes. But if a large item like the RMRR one is being picked, this is a
recipe for failure.

> 2. Unfortunately this RMRR effort grows from original two patches (very VT-d
> focused) to now v8 17 patches spanning many areas (including hypercall, mmu, 
> domain builder, hvmloader, etc.), and thus imposing both long learning curve
> and lots of frustrations being no achievement returned. Though having a 
> complete
> solution is desired, we need to help split the big task into step-by-step 
> approach 
> as long as:
> 	- the overall design is agreed
> 	- each step is self-contained 
> 	- each step won't be wasted moving forward. 
> That way new people can see incremental achievements, instead of being hit 
> down before final success. 
> 
> Take this RMRR for example. Maybe we can split into steps like:
> 
> 	step-1: setup RMRR identify mapping in hypervisor. fail if confliction. no
> user space changes
> 	step-2: expose RMRR knowledge to userspace and detect confliction in
> domain builder and hvmloader
> 	step-3: reconcile e820/mmio to avoid confliction in a best effort
> 	step-4: miscellaneous enhancements, each can be ACK-ed individually:
> 		- handle guest CPU access to RMRR regions
> 		- handle conflicting RMRR regions
> 		- handle group RMRRs
> 		- re-enable USB device assignment
> 
> That way Tiejun can focus on a self-contained task at one time, and then 
> observe
> continuous acknowledgements for his work. We don't need to claim RMRR fully
> ready in Xen until last patch is accepted, but that at least provides a way 
> to ack
> new people when working on complex features and also allow for partial usage 
> on his work.

If only this wouldn't result in regressions when done in steps (like you
outlined above, or likely also if split up in any other ways). Having to
do this in one go is the price you/we have to pay for this not having
got done properly from the beginning.

> 3. Maintainers sometimes didn't give definitive guidance to the new people, 
> and the high-level design is not closed in the 1st place. e.g. when I thought 
> this v8
> version has everyone agreed on the design, there's another comment from Jan
> about using XENMEM_set_memory_map might be better, while back to Aug.
> when Tiejun raised that option the answer is "I'm not sure". Note I 
> understand
> as a maintainer he might not have definite answers for all opens. But w/o a
> definitive guide new people may waste lots of effort on chasing a wrong 
> option,
> which is definitely frustrating. 

Main problem being that the maintainers to help here are primarily you,
and only then me or others - after all this is a VT-d only problem, not a
general IOMMU one. The fact that non-VT-d code gets touched doesn't
matter when considering just the design. And that's why I had asked
Tiejun to work with the two of you on getting the basis right. I don't
know how much of that possibly happened without the public seeing it,
but the results seem to suggest not all that much.

> So I'd suggest for such non-trivial task for a new people, all maintainers in 
> involved areas (xen, mmu, tools, vtd, etc) should first spend time to agree 
> on the high level design. At that stage, let's skip the coding problems to 
> save
> both time. After agreed design, then we can help the new people to improve 
> the coding to reach check-in criteria, which then becomes a converging 
> process.
> 
> for this RMRR issue, let's close the design first, and then use staged 
> approach
> to get this patch series in.

Yes please. Till now (as said many times before) the only route I see
without grounds up design considerations is to disable pass-through for
devices associated with RMRRs. The longer the current situation lasts,
the more I'm tempted to put together a patch to do just that.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:01:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09: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 1Xyd91-0001wN-6s; Wed, 10 Dec 2014 09:01: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 1Xyd8z-0001wI-7L
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 09:01:13 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	47/83-02696-8DB08845; Wed, 10 Dec 2014 09:01:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418202070!14102156!1
X-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 19928 invoked from network); 10 Dec 2014 09:01:10 -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; 10 Dec 2014 09:01:10 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 09:01:09 +0000
Message-Id: <548819E3020000780004E726@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 09:01:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114F15@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 Deegan <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>, Tiejun Chen <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 04:39, <kevin.tian@intel.com> wrote:
> 1. It's more efficient for new people to start from a small, well-defined 
> task
> in one area, and then spanning to adjacent areas gradually. Patience must 
> be given by the community to help them grow;

Yes. But if a large item like the RMRR one is being picked, this is a
recipe for failure.

> 2. Unfortunately this RMRR effort grows from original two patches (very VT-d
> focused) to now v8 17 patches spanning many areas (including hypercall, mmu, 
> domain builder, hvmloader, etc.), and thus imposing both long learning curve
> and lots of frustrations being no achievement returned. Though having a 
> complete
> solution is desired, we need to help split the big task into step-by-step 
> approach 
> as long as:
> 	- the overall design is agreed
> 	- each step is self-contained 
> 	- each step won't be wasted moving forward. 
> That way new people can see incremental achievements, instead of being hit 
> down before final success. 
> 
> Take this RMRR for example. Maybe we can split into steps like:
> 
> 	step-1: setup RMRR identify mapping in hypervisor. fail if confliction. no
> user space changes
> 	step-2: expose RMRR knowledge to userspace and detect confliction in
> domain builder and hvmloader
> 	step-3: reconcile e820/mmio to avoid confliction in a best effort
> 	step-4: miscellaneous enhancements, each can be ACK-ed individually:
> 		- handle guest CPU access to RMRR regions
> 		- handle conflicting RMRR regions
> 		- handle group RMRRs
> 		- re-enable USB device assignment
> 
> That way Tiejun can focus on a self-contained task at one time, and then 
> observe
> continuous acknowledgements for his work. We don't need to claim RMRR fully
> ready in Xen until last patch is accepted, but that at least provides a way 
> to ack
> new people when working on complex features and also allow for partial usage 
> on his work.

If only this wouldn't result in regressions when done in steps (like you
outlined above, or likely also if split up in any other ways). Having to
do this in one go is the price you/we have to pay for this not having
got done properly from the beginning.

> 3. Maintainers sometimes didn't give definitive guidance to the new people, 
> and the high-level design is not closed in the 1st place. e.g. when I thought 
> this v8
> version has everyone agreed on the design, there's another comment from Jan
> about using XENMEM_set_memory_map might be better, while back to Aug.
> when Tiejun raised that option the answer is "I'm not sure". Note I 
> understand
> as a maintainer he might not have definite answers for all opens. But w/o a
> definitive guide new people may waste lots of effort on chasing a wrong 
> option,
> which is definitely frustrating. 

Main problem being that the maintainers to help here are primarily you,
and only then me or others - after all this is a VT-d only problem, not a
general IOMMU one. The fact that non-VT-d code gets touched doesn't
matter when considering just the design. And that's why I had asked
Tiejun to work with the two of you on getting the basis right. I don't
know how much of that possibly happened without the public seeing it,
but the results seem to suggest not all that much.

> So I'd suggest for such non-trivial task for a new people, all maintainers in 
> involved areas (xen, mmu, tools, vtd, etc) should first spend time to agree 
> on the high level design. At that stage, let's skip the coding problems to 
> save
> both time. After agreed design, then we can help the new people to improve 
> the coding to reach check-in criteria, which then becomes a converging 
> process.
> 
> for this RMRR issue, let's close the design first, and then use staged 
> approach
> to get this patch series in.

Yes please. Till now (as said many times before) the only route I see
without grounds up design considerations is to disable pass-through for
devices associated with RMRRs. The longer the current situation lasts,
the more I'm tempted to put together a patch to do just that.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:07:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09: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 1XydFC-0002Kq-1H; Wed, 10 Dec 2014 09:07: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 1XydFA-0002Kl-JN
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 09:07:36 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	A1/29-29352-75D08845; Wed, 10 Dec 2014 09:07:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418202455!12556479!1
X-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 6906 invoked from network); 10 Dec 2014 09:07:35 -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; 10 Dec 2014 09:07:35 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 09:07:34 +0000
Message-Id: <54881B65020000780004E733@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 09:07:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <54857995020000780004DA2D@mail.emea.novell.com>
	<54872B02.50300@citrix.com>
	<54873D3D020000780004E3D4@mail.emea.novell.com>
	<54873645.9070204@citrix.com>
In-Reply-To: <54873645.9070204@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	JunNakajima <jun.nakajima@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
 handle_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 09.12.14 at 18:49, <roger.pau@citrix.com> wrote:
> El 09/12/14 a les 18.19, Jan Beulich ha escrit:
>>>>> On 09.12.14 at 18:01, <roger.pau@citrix.com> wrote:
>>> For 4.6 I think we need to start using a different hvm_io_bitmap for PVH
>>> Dom0 that allows direct access to the IO ports, bypassing the vmexit and
>>> simplifying the code in Xen (this would also fix INS/OUTS). Still not
>>> sure what should be done for PVH DomUs, specially when PVH gains support
>>> for pci-passthrough.
>> 
>> With the difficulty being that for PV the hypervisor intentionally
>> intercepts accesses to some of the ports, so we can't blindly
>> allow PVH access to all the ports its allowed access to.
> 
> I assume this is mainly for DomUs but not for Dom0? Or should PVH Dom0
> access to the IO space also be filtered and emulated for some ports?

It should indeed - just look at guest_io_read() and guest_io_write().
I.e. an eventual PVH specific bitmap would need to be populated
based on what admin_io_okay() returns (instead of
ioports_access_permitted()), carefully taking into consideration the
possible access widths.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:07:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09: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 1XydFC-0002Kq-1H; Wed, 10 Dec 2014 09:07: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 1XydFA-0002Kl-JN
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 09:07:36 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	A1/29-29352-75D08845; Wed, 10 Dec 2014 09:07:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418202455!12556479!1
X-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 6906 invoked from network); 10 Dec 2014 09:07:35 -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; 10 Dec 2014 09:07:35 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 09:07:34 +0000
Message-Id: <54881B65020000780004E733@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 09:07:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <54857995020000780004DA2D@mail.emea.novell.com>
	<54872B02.50300@citrix.com>
	<54873D3D020000780004E3D4@mail.emea.novell.com>
	<54873645.9070204@citrix.com>
In-Reply-To: <54873645.9070204@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Kevin Tian <kevin.tian@intel.com>, Eddie Dong <eddie.dong@intel.com>,
	JunNakajima <jun.nakajima@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
 handle_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 09.12.14 at 18:49, <roger.pau@citrix.com> wrote:
> El 09/12/14 a les 18.19, Jan Beulich ha escrit:
>>>>> On 09.12.14 at 18:01, <roger.pau@citrix.com> wrote:
>>> For 4.6 I think we need to start using a different hvm_io_bitmap for PVH
>>> Dom0 that allows direct access to the IO ports, bypassing the vmexit and
>>> simplifying the code in Xen (this would also fix INS/OUTS). Still not
>>> sure what should be done for PVH DomUs, specially when PVH gains support
>>> for pci-passthrough.
>> 
>> With the difficulty being that for PV the hypervisor intentionally
>> intercepts accesses to some of the ports, so we can't blindly
>> allow PVH access to all the ports its allowed access to.
> 
> I assume this is mainly for DomUs but not for Dom0? Or should PVH Dom0
> access to the IO space also be filtered and emulated for some ports?

It should indeed - just look at guest_io_read() and guest_io_write().
I.e. an eventual PVH specific bitmap would need to be populated
based on what admin_io_okay() returns (instead of
ioports_access_permitted()), carefully taking into consideration the
possible access widths.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:15:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XydMz-0002jF-W2; Wed, 10 Dec 2014 09:15:41 +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 1XydMy-0002jA-Rp
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 09:15:41 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	18/62-11581-C3F08845; Wed, 10 Dec 2014 09:15:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418202939!12515164!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14041 invoked from network); 10 Dec 2014 09:15:39 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2014 09:15:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418202939; l=1810;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=vWa04w3KBJCDrlyispcJmfSLd90=;
	b=hm6WgnpcUh2WL7BsSrS2a5fZIOxZb/SYSOTOycp04h2XcCnTOZlxamMHS7InEKAQ5Yo
	+P0rixYNOpZWN4eO97MSdh7XI0ZJVUdGflW7RIAh4MNNRkTiwVTq+SfYNVDDLNW24inFH
	P9O7nQM/xSFIbop33Xt00id1EKaXmXgsa+g=
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.3 AUTH) with ESMTPSA id j07be5qBA9FZ8tl
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 10 Dec 2014 10:15:35 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 05AD85015F; Wed, 10 Dec 2014 10:15:34 +0100 (CET)
Date: Wed, 10 Dec 2014 10:15:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141210091534.GA24974@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21639.10108.666942.407514@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, Ian Jackson wrote:

> Bottom line: as relevant maintainer, I'm afraid I'm going to insist
> that this script be in /etc.

I dont agree with the reasoning, but to get this done:
Which place would that be, XEN_SCRIPT_DIR?

> > > I don't think this script wants to contain an option parser!
> > 
> > How should it handle exec vs. no-exec? Just a single yes/no knob, so
> > essentially sysv vs systemd?
> 
> I was imagining a "named parameter" as SuS calls them.  One or both
> the sites which run this wrapper script would pass an environment
> variable.  Something like this in the script:
> 
>   $xenstored_do_exec $XENSTORED "$@" $XENSTORED_TRACE_ARGS $XENSTORED_ARGS
> 
> where the systemd unit simply sets `xenstored_do_exec=exec'.

Ok, I will implement this.

> In this case that means I think you should find out whether the lack
> of this xenstore-read polling loop is actually a bug in the existing
> systemd unit.  If (as I suspect) this is not a bug, then your code
> motion should not change this aspect of the operation under systemd.

I think any daemon needs some time until its operational. In case of
xenstored there are users which expect its functionality right away,
such as xen-init-dom0 and the other tools launched by xencommons. Thats
likely the reason why the loop is there, and the commit msg of f706d9e9a
confirms that. With systemd we can only hope that it handles this
properly with its socket passing functionality. If not, the startup code
could be done like I did in my patch do avoid code duplication in a
to-be-added ExecStartPost=.

And the "is xenstored ready?" check in my current implementation would
not work anyway because once the shell does exec it will not run the
following code which does the "xenstore-read -s".

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:15:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XydMz-0002jF-W2; Wed, 10 Dec 2014 09:15:41 +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 1XydMy-0002jA-Rp
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 09:15:41 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	18/62-11581-C3F08845; Wed, 10 Dec 2014 09:15:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418202939!12515164!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14041 invoked from network); 10 Dec 2014 09:15:39 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Dec 2014 09:15:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418202939; l=1810;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=vWa04w3KBJCDrlyispcJmfSLd90=;
	b=hm6WgnpcUh2WL7BsSrS2a5fZIOxZb/SYSOTOycp04h2XcCnTOZlxamMHS7InEKAQ5Yo
	+P0rixYNOpZWN4eO97MSdh7XI0ZJVUdGflW7RIAh4MNNRkTiwVTq+SfYNVDDLNW24inFH
	P9O7nQM/xSFIbop33Xt00id1EKaXmXgsa+g=
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.3 AUTH) with ESMTPSA id j07be5qBA9FZ8tl
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 10 Dec 2014 10:15:35 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 05AD85015F; Wed, 10 Dec 2014 10:15:34 +0100 (CET)
Date: Wed, 10 Dec 2014 10:15:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141210091534.GA24974@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21639.10108.666942.407514@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, Ian Jackson wrote:

> Bottom line: as relevant maintainer, I'm afraid I'm going to insist
> that this script be in /etc.

I dont agree with the reasoning, but to get this done:
Which place would that be, XEN_SCRIPT_DIR?

> > > I don't think this script wants to contain an option parser!
> > 
> > How should it handle exec vs. no-exec? Just a single yes/no knob, so
> > essentially sysv vs systemd?
> 
> I was imagining a "named parameter" as SuS calls them.  One or both
> the sites which run this wrapper script would pass an environment
> variable.  Something like this in the script:
> 
>   $xenstored_do_exec $XENSTORED "$@" $XENSTORED_TRACE_ARGS $XENSTORED_ARGS
> 
> where the systemd unit simply sets `xenstored_do_exec=exec'.

Ok, I will implement this.

> In this case that means I think you should find out whether the lack
> of this xenstore-read polling loop is actually a bug in the existing
> systemd unit.  If (as I suspect) this is not a bug, then your code
> motion should not change this aspect of the operation under systemd.

I think any daemon needs some time until its operational. In case of
xenstored there are users which expect its functionality right away,
such as xen-init-dom0 and the other tools launched by xencommons. Thats
likely the reason why the loop is there, and the commit msg of f706d9e9a
confirms that. With systemd we can only hope that it handles this
properly with its socket passing functionality. If not, the startup code
could be done like I did in my patch do avoid code duplication in a
to-be-added ExecStartPost=.

And the "is xenstored ready?" check in my current implementation would
not work anyway because once the shell does exec it will not run the
following code which does the "xenstore-read -s".

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:16:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09: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 1XydO3-0002n9-EN; Wed, 10 Dec 2014 09:16:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XydO2-0002n0-9c
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 09:16:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	73/BA-09842-D7F08845; Wed, 10 Dec 2014 09:16:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418203004!14584183!1
X-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 18041 invoked from network); 10 Dec 2014 09:16:45 -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; 10 Dec 2014 09:16:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 09:16:44 +0000
Message-Id: <54881D8A020000780004E73E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 09:16:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>,
	"Zhang Yu" <yu.c.zhang@linux.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
	<548814C2020000780004E6F9@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126115303@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126115303@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.12.14 at 09:47, <kevin.tian@intel.com> wrote:
> two translation paths in assigned case:
> 
> 1. [direct CPU access from VM], with partitioned PCI aperture
> resource, every VM can access a portion of PCI aperture directly.
> 
> - CPU page table/EPT: CPU virtual address->PCI aperture
> - PCI aperture - bar base = Graphics Memory Address (GMA)
> - GPU page table: GMA -> GPA (as programmed by guest)
> - IOMMU: GPA -> MPA
> 
> 2. [GPU access through GPU command operands], with GPU scheduling,
> every VM's command buffer will be fetched by GPU in a time-shared
> manner.
> 
> - GPU page table: GMA->GPA
> - IOMMU: GPA->MPA
> 
> In our case, IOMMU is setup with 1:1 identity table for dom0. So 
> when GPU may access GPAs from different VMs, we can't count on
> IOMMU which can only serve one mapping for one device (unless 
> we have SR-IOV). 
> 
> That's why we need shadow GPU page table in dom0, and need a
> p2m query call to translate from GPA -> MPA:
> 
> - shadow GPU page table: GMA->MPA
> - IOMMU: MPA->MPA (for dom0)

I still can't see why the Dom0 translation has to remain 1:1, i.e.
why Xen couldn't return some "arbitrary" GPA for the query in
question here, setting up a suitable GPA->MPA translation. (I put
arbitrary in quotes because this of course must not conflict with
GPAs already or possibly in use by Dom0.) And I can only stress
again that you shouldn't leave out PVH (where the IOMMU already
isn't set up with all 1:1 mappings) from these considerations.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:16:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09: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 1XydO3-0002n9-EN; Wed, 10 Dec 2014 09:16:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XydO2-0002n0-9c
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 09:16:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	73/BA-09842-D7F08845; Wed, 10 Dec 2014 09:16:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418203004!14584183!1
X-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 18041 invoked from network); 10 Dec 2014 09:16:45 -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; 10 Dec 2014 09:16:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 09:16:44 +0000
Message-Id: <54881D8A020000780004E73E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 09:16:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>,
	"Zhang Yu" <yu.c.zhang@linux.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
	<548814C2020000780004E6F9@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126115303@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126115303@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.12.14 at 09:47, <kevin.tian@intel.com> wrote:
> two translation paths in assigned case:
> 
> 1. [direct CPU access from VM], with partitioned PCI aperture
> resource, every VM can access a portion of PCI aperture directly.
> 
> - CPU page table/EPT: CPU virtual address->PCI aperture
> - PCI aperture - bar base = Graphics Memory Address (GMA)
> - GPU page table: GMA -> GPA (as programmed by guest)
> - IOMMU: GPA -> MPA
> 
> 2. [GPU access through GPU command operands], with GPU scheduling,
> every VM's command buffer will be fetched by GPU in a time-shared
> manner.
> 
> - GPU page table: GMA->GPA
> - IOMMU: GPA->MPA
> 
> In our case, IOMMU is setup with 1:1 identity table for dom0. So 
> when GPU may access GPAs from different VMs, we can't count on
> IOMMU which can only serve one mapping for one device (unless 
> we have SR-IOV). 
> 
> That's why we need shadow GPU page table in dom0, and need a
> p2m query call to translate from GPA -> MPA:
> 
> - shadow GPU page table: GMA->MPA
> - IOMMU: MPA->MPA (for dom0)

I still can't see why the Dom0 translation has to remain 1:1, i.e.
why Xen couldn't return some "arbitrary" GPA for the query in
question here, setting up a suitable GPA->MPA translation. (I put
arbitrary in quotes because this of course must not conflict with
GPAs already or possibly in use by Dom0.) And I can only stress
again that you shouldn't leave out PVH (where the IOMMU already
isn't set up with all 1:1 mappings) from these considerations.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:30:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09:30:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XydaH-0003IK-TF; Wed, 10 Dec 2014 09:29:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XydaG-0003IF-49
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 09:29:24 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	10/FA-17958-37218845; Wed, 10 Dec 2014 09:29:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418203761!12272495!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 22695 invoked from network); 10 Dec 2014 09:29:22 -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 Dec 2014 09:29:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202332410"
Message-ID: <1418203727.19809.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <Ian.Jackson@eu.citrix.com>
Date: Wed, 10 Dec 2014 09:28:47 +0000
In-Reply-To: <osstest-32180-mainreport@xen.org>
References: <osstest-32180-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [libvirt test] 32180: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-09 at 22:11 +0000, xen.org wrote:
> flight 32180 libvirt real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32180/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32137
>  build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32137
>  build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32137

util/virnetdevbridge.c: In function 'virNetDevBridgeFDBAddDel':
util/virnetdevbridge.c:958:26: error: 'NTF_SELF' undeclared (first use in this function)
util/virnetdevbridge.c:958:26: note: each undeclared identifier is reported only once for each function it appears in
util/virnetdevbridge.c:960:26: error: 'NTF_MASTER' undeclared (first use in this function)

Already fixed upstream.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:30:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09:30:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XydaH-0003IK-TF; Wed, 10 Dec 2014 09:29:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XydaG-0003IF-49
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 09:29:24 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	10/FA-17958-37218845; Wed, 10 Dec 2014 09:29:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418203761!12272495!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 22695 invoked from network); 10 Dec 2014 09:29:22 -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 Dec 2014 09:29:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202332410"
Message-ID: <1418203727.19809.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <Ian.Jackson@eu.citrix.com>
Date: Wed, 10 Dec 2014 09:28:47 +0000
In-Reply-To: <osstest-32180-mainreport@xen.org>
References: <osstest-32180-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [libvirt test] 32180: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-09 at 22:11 +0000, xen.org wrote:
> flight 32180 libvirt real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32180/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-libvirt            5 libvirt-build             fail REGR. vs. 32137
>  build-amd64-libvirt           5 libvirt-build             fail REGR. vs. 32137
>  build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 32137

util/virnetdevbridge.c: In function 'virNetDevBridgeFDBAddDel':
util/virnetdevbridge.c:958:26: error: 'NTF_SELF' undeclared (first use in this function)
util/virnetdevbridge.c:958:26: note: each undeclared identifier is reported only once for each function it appears in
util/virnetdevbridge.c:960:26: error: 'NTF_MASTER' undeclared (first use in this function)

Already fixed upstream.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:47:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09:47:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xydri-00040k-Mu; Wed, 10 Dec 2014 09:47:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xydrh-00040f-2Q
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 09:47:25 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	73/66-09284-CA618845; Wed, 10 Dec 2014 09:47:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418204841!12286218!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 24232 invoked from network); 10 Dec 2014 09:47:23 -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;
	10 Dec 2014 09:47:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202337816"
Message-ID: <1418204839.19809.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mao Mingya <maomingya928@gmail.com>
Date: Wed, 10 Dec 2014 09:47:19 +0000
In-Reply-To: <em21df949d-ecc3-45dc-a652-b160516de8f7@sgp1030c>
References: <em21df949d-ecc3-45dc-a652-b160516de8f7@sgp1030c>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] arch arm qemu compile erro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't top post.

On Wed, 2014-12-10 at 07:09 +0000, Mao Mingya wrote:
> From the the arch arm, since the stubdom is not supported now. Does the 
> device to be shared between doms have to be pv front/backend structure.

Yes.

There is no equivalent to the x86 "hvm" type guest, i.e. one which looks
to the guest like a real system, in the ARM version of Xen. On x86
stub-qemu is primarily about providing these emulated system devices in
a sandboxed environment. There are no emulated devices on ARM hence no
need for qemu for this purpose, hence no stubdomains.

qemu has a "second hat" when in a Xen system, which is that it can
provide certain PV backends, we do use it for this purpose on ARM.

> To run the Linux on Dom0 and DomU. Could the qemu and pv backend run in 
> the Dom0 at the same time?

Yes.

>      For example: for network, block device, serial console, the pv 
> backend provides the device drive for DomU linux
>      while qemu provides all other devices driver for DomU linux.

Yes, qemu can be used to provide PV backends for: disk (using qdisk),
framebuffer, kbd and mouse.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:47:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09:47:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xydri-00040k-Mu; Wed, 10 Dec 2014 09:47:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Xydrh-00040f-2Q
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 09:47:25 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	73/66-09284-CA618845; Wed, 10 Dec 2014 09:47:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418204841!12286218!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 24232 invoked from network); 10 Dec 2014 09:47:23 -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;
	10 Dec 2014 09:47:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202337816"
Message-ID: <1418204839.19809.30.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mao Mingya <maomingya928@gmail.com>
Date: Wed, 10 Dec 2014 09:47:19 +0000
In-Reply-To: <em21df949d-ecc3-45dc-a652-b160516de8f7@sgp1030c>
References: <em21df949d-ecc3-45dc-a652-b160516de8f7@sgp1030c>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] arch arm qemu compile erro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't top post.

On Wed, 2014-12-10 at 07:09 +0000, Mao Mingya wrote:
> From the the arch arm, since the stubdom is not supported now. Does the 
> device to be shared between doms have to be pv front/backend structure.

Yes.

There is no equivalent to the x86 "hvm" type guest, i.e. one which looks
to the guest like a real system, in the ARM version of Xen. On x86
stub-qemu is primarily about providing these emulated system devices in
a sandboxed environment. There are no emulated devices on ARM hence no
need for qemu for this purpose, hence no stubdomains.

qemu has a "second hat" when in a Xen system, which is that it can
provide certain PV backends, we do use it for this purpose on ARM.

> To run the Linux on Dom0 and DomU. Could the qemu and pv backend run in 
> the Dom0 at the same time?

Yes.

>      For example: for network, block device, serial console, the pv 
> backend provides the device drive for DomU linux
>      while qemu provides all other devices driver for DomU linux.

Yes, qemu can be used to provide PV backends for: disk (using qdisk),
framebuffer, kbd and mouse.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:52:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09: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 1XydwP-0004CU-Dh; Wed, 10 Dec 2014 09:52: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 1XydwN-0004CP-RE
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 09:52:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A7/E4-25276-EC718845; Wed, 10 Dec 2014 09:52:14 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418205133!14553911!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 17478 invoked from network); 10 Dec 2014 09:52:14 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 09:52:14 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 10 Dec 2014 01:52:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="427273089"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by FMSMGA003.fm.intel.com with ESMTP; 10 Dec 2014 01:41:29 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 17:51:31 +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, 10 Dec 2014 17:51:30 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Zhang Yu <yu.c.zhang@linux.intel.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGhdsAgAAFC4CAAAOQAIABdNew///48wCAAIZgkP//hBgAgACN+FA=
Date: Wed, 10 Dec 2014 09:51:29 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611542D@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
	<548814C2020000780004E6F9@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126115303@SHSMSX101.ccr.corp.intel.com>
	<54881D8A020000780004E73E@mail.emea.novell.com>
In-Reply-To: <54881D8A020000780004E73E@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 \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, December 10, 2014 5:17 PM
> 
> >>> On 10.12.14 at 09:47, <kevin.tian@intel.com> wrote:
> > two translation paths in assigned case:
> >
> > 1. [direct CPU access from VM], with partitioned PCI aperture
> > resource, every VM can access a portion of PCI aperture directly.
> >
> > - CPU page table/EPT: CPU virtual address->PCI aperture
> > - PCI aperture - bar base = Graphics Memory Address (GMA)
> > - GPU page table: GMA -> GPA (as programmed by guest)
> > - IOMMU: GPA -> MPA
> >
> > 2. [GPU access through GPU command operands], with GPU scheduling,
> > every VM's command buffer will be fetched by GPU in a time-shared
> > manner.
> >
> > - GPU page table: GMA->GPA
> > - IOMMU: GPA->MPA
> >
> > In our case, IOMMU is setup with 1:1 identity table for dom0. So
> > when GPU may access GPAs from different VMs, we can't count on
> > IOMMU which can only serve one mapping for one device (unless
> > we have SR-IOV).
> >
> > That's why we need shadow GPU page table in dom0, and need a
> > p2m query call to translate from GPA -> MPA:
> >
> > - shadow GPU page table: GMA->MPA
> > - IOMMU: MPA->MPA (for dom0)
> 
> I still can't see why the Dom0 translation has to remain 1:1, i.e.
> why Xen couldn't return some "arbitrary" GPA for the query in
> question here, setting up a suitable GPA->MPA translation. (I put
> arbitrary in quotes because this of course must not conflict with
> GPAs already or possibly in use by Dom0.) And I can only stress
> again that you shouldn't leave out PVH (where the IOMMU already
> isn't set up with all 1:1 mappings) from these considerations.
> 

It's interesting that you think IOMMU can be used in such situation.

what do you mean by "arbitrary" GPA here? and It's not just about 
conflicting with Dom0's GPA, it's about confliction in all VM's GPAs 
when you hosting them through one IOMMU page table, and there's 
no way to prevent this definitely since GPAs are picked by VMs 
themselves.

I don't think we can support PVH here if IOMMU is not 1:1 mapping.

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 Dec 10 09:52:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09: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 1XydwP-0004CU-Dh; Wed, 10 Dec 2014 09:52: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 1XydwN-0004CP-RE
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 09:52:16 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A7/E4-25276-EC718845; Wed, 10 Dec 2014 09:52:14 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418205133!14553911!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 17478 invoked from network); 10 Dec 2014 09:52:14 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-21.messagelabs.com with SMTP;
	10 Dec 2014 09:52:14 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 10 Dec 2014 01:52:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="427273089"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by FMSMGA003.fm.intel.com with ESMTP; 10 Dec 2014 01:41:29 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Wed, 10 Dec 2014 17:51:31 +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, 10 Dec 2014 17:51:30 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Zhang Yu <yu.c.zhang@linux.intel.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGhdsAgAAFC4CAAAOQAIABdNew///48wCAAIZgkP//hBgAgACN+FA=
Date: Wed, 10 Dec 2014 09:51:29 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611542D@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
	<548814C2020000780004E6F9@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126115303@SHSMSX101.ccr.corp.intel.com>
	<54881D8A020000780004E73E@mail.emea.novell.com>
In-Reply-To: <54881D8A020000780004E73E@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 \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, December 10, 2014 5:17 PM
> 
> >>> On 10.12.14 at 09:47, <kevin.tian@intel.com> wrote:
> > two translation paths in assigned case:
> >
> > 1. [direct CPU access from VM], with partitioned PCI aperture
> > resource, every VM can access a portion of PCI aperture directly.
> >
> > - CPU page table/EPT: CPU virtual address->PCI aperture
> > - PCI aperture - bar base = Graphics Memory Address (GMA)
> > - GPU page table: GMA -> GPA (as programmed by guest)
> > - IOMMU: GPA -> MPA
> >
> > 2. [GPU access through GPU command operands], with GPU scheduling,
> > every VM's command buffer will be fetched by GPU in a time-shared
> > manner.
> >
> > - GPU page table: GMA->GPA
> > - IOMMU: GPA->MPA
> >
> > In our case, IOMMU is setup with 1:1 identity table for dom0. So
> > when GPU may access GPAs from different VMs, we can't count on
> > IOMMU which can only serve one mapping for one device (unless
> > we have SR-IOV).
> >
> > That's why we need shadow GPU page table in dom0, and need a
> > p2m query call to translate from GPA -> MPA:
> >
> > - shadow GPU page table: GMA->MPA
> > - IOMMU: MPA->MPA (for dom0)
> 
> I still can't see why the Dom0 translation has to remain 1:1, i.e.
> why Xen couldn't return some "arbitrary" GPA for the query in
> question here, setting up a suitable GPA->MPA translation. (I put
> arbitrary in quotes because this of course must not conflict with
> GPAs already or possibly in use by Dom0.) And I can only stress
> again that you shouldn't leave out PVH (where the IOMMU already
> isn't set up with all 1:1 mappings) from these considerations.
> 

It's interesting that you think IOMMU can be used in such situation.

what do you mean by "arbitrary" GPA here? and It's not just about 
conflicting with Dom0's GPA, it's about confliction in all VM's GPAs 
when you hosting them through one IOMMU page table, and there's 
no way to prevent this definitely since GPAs are picked by VMs 
themselves.

I don't think we can support PVH here if IOMMU is not 1:1 mapping.

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 Dec 10 09:53:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09:53:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XydxS-0004Pd-Rz; Wed, 10 Dec 2014 09:53: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 1XydxR-0004PS-7N
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 09:53:21 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	64/C4-02699-01818845; Wed, 10 Dec 2014 09:53:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418205198!10789980!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 11700 invoked from network); 10 Dec 2014 09:53:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 09:53:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202339840"
Message-ID: <1418205196.19809.34.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 10 Dec 2014 09:53:16 +0000
In-Reply-To: <54880D6B020000780004E6AA@mail.emea.novell.com>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 08:07 +0000, Jan Beulich wrote:
> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> wasn't really consistent in one respect: The granting of access to an
> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> domains. In fact it is wrong to assume that a translation is already/
> still in place at the time access is being granted/revoked.

Specifically you need to do the translation using the mapping of the
domain doing the granting, not the domain being granted too, correct?

It takes a little bit of thought to figure out which domain to check
here, it would be worth a sentence or two explaining why this is the
right one.

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  
>      case XEN_DOMCTL_irq_permission:
>      {
> -        unsigned int pirq = op->u.irq_permission.pirq;
> +        unsigned int pirq = op->u.irq_permission.pirq, irq;
>          int allow = op->u.irq_permission.allow_access;
>  
>          if ( pirq >= d->nr_pirqs )
>              ret = -EINVAL;
> -        else if ( !pirq_access_permitted(current->domain, pirq) ||
> +        else if ( !(irq = pirq_access_permitted(current->domain, pirq)) ||

I find hiding an assignment inside the second condition in a chain of
if's to be rather obfuscated. Doing an assignment in a standalone if
statement is one thing, this is going to far IMHO.

Also, you range check pirq against d->nr_pirqs but then translate it
against current->domain, is that correct?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:53:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09:53:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XydxS-0004Pd-Rz; Wed, 10 Dec 2014 09:53: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 1XydxR-0004PS-7N
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 09:53:21 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	64/C4-02699-01818845; Wed, 10 Dec 2014 09:53:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418205198!10789980!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 11700 invoked from network); 10 Dec 2014 09:53:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 09:53:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202339840"
Message-ID: <1418205196.19809.34.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 10 Dec 2014 09:53:16 +0000
In-Reply-To: <54880D6B020000780004E6AA@mail.emea.novell.com>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xenproject.org>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 08:07 +0000, Jan Beulich wrote:
> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> wasn't really consistent in one respect: The granting of access to an
> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> domains. In fact it is wrong to assume that a translation is already/
> still in place at the time access is being granted/revoked.

Specifically you need to do the translation using the mapping of the
domain doing the granting, not the domain being granted too, correct?

It takes a little bit of thought to figure out which domain to check
here, it would be worth a sentence or two explaining why this is the
right one.

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  
>      case XEN_DOMCTL_irq_permission:
>      {
> -        unsigned int pirq = op->u.irq_permission.pirq;
> +        unsigned int pirq = op->u.irq_permission.pirq, irq;
>          int allow = op->u.irq_permission.allow_access;
>  
>          if ( pirq >= d->nr_pirqs )
>              ret = -EINVAL;
> -        else if ( !pirq_access_permitted(current->domain, pirq) ||
> +        else if ( !(irq = pirq_access_permitted(current->domain, pirq)) ||

I find hiding an assignment inside the second condition in a chain of
if's to be rather obfuscated. Doing an assignment in a standalone if
statement is one thing, this is going to far IMHO.

Also, you range check pirq against d->nr_pirqs but then translate it
against current->domain, is that correct?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 09:58:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09: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 1Xye2X-0004ge-Jo; Wed, 10 Dec 2014 09:58:37 +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 1Xye2W-0004gZ-Mk
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 09:58:36 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	CE/3C-25727-B4918845; Wed, 10 Dec 2014 09:58:35 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418205513!12271308!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 4574 invoked from network); 10 Dec 2014 09:58:34 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 09:58:34 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 10 Dec 2014 01:58:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="635463694"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by fmsmga001.fm.intel.com with ESMTP; 10 Dec 2014 01:58:31 -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, 10 Dec 2014 17:58:01 +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, 10 Dec 2014 17:57:59 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
	support XEN_DOMCTL_set_rdm
Thread-Index: AQHQE5h0ZLDY7ZdMpU2g0ypuvrX7qZyIH8Ag///inYCAAJOp8A==
Date: Wed, 10 Dec 2014 09:57:59 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126115463@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
	<548819E3020000780004E726@mail.emea.novell.com>
In-Reply-To: <548819E3020000780004E726@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: "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 Deegan <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>, "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, December 10, 2014 5:01 PM
> 
> >>> On 10.12.14 at 04:39, <kevin.tian@intel.com> wrote:
> > 1. It's more efficient for new people to start from a small, well-defined
> > task
> > in one area, and then spanning to adjacent areas gradually. Patience must
> > be given by the community to help them grow;
> 
> Yes. But if a large item like the RMRR one is being picked, this is a
> recipe for failure.

RMRR is already there, just broken. Here what we are doing is to fix it. Regarding
to that, as long as the small item doesn't cause new failures or regressions, it
should be fine.

> 
> > 2. Unfortunately this RMRR effort grows from original two patches (very
> VT-d
> > focused) to now v8 17 patches spanning many areas (including hypercall,
> mmu,
> > domain builder, hvmloader, etc.), and thus imposing both long learning curve
> > and lots of frustrations being no achievement returned. Though having a
> > complete
> > solution is desired, we need to help split the big task into step-by-step
> > approach
> > as long as:
> > 	- the overall design is agreed
> > 	- each step is self-contained
> > 	- each step won't be wasted moving forward.
> > That way new people can see incremental achievements, instead of being hit
> > down before final success.
> >
> > Take this RMRR for example. Maybe we can split into steps like:
> >
> > 	step-1: setup RMRR identify mapping in hypervisor. fail if confliction. no
> > user space changes
> > 	step-2: expose RMRR knowledge to userspace and detect confliction in
> > domain builder and hvmloader
> > 	step-3: reconcile e820/mmio to avoid confliction in a best effort
> > 	step-4: miscellaneous enhancements, each can be ACK-ed individually:
> > 		- handle guest CPU access to RMRR regions
> > 		- handle conflicting RMRR regions
> > 		- handle group RMRRs
> > 		- re-enable USB device assignment
> >
> > That way Tiejun can focus on a self-contained task at one time, and then
> > observe
> > continuous acknowledgements for his work. We don't need to claim RMRR
> fully
> > ready in Xen until last patch is accepted, but that at least provides a way
> > to ack
> > new people when working on complex features and also allow for partial
> usage
> > on his work.
> 
> If only this wouldn't result in regressions when done in steps (like you
> outlined above, or likely also if split up in any other ways). Having to
> do this in one go is the price you/we have to pay for this not having
> got done properly from the beginning.

then let's sit down to clear the design first before going to review the detail.

> 
> > 3. Maintainers sometimes didn't give definitive guidance to the new people,
> > and the high-level design is not closed in the 1st place. e.g. when I thought
> > this v8
> > version has everyone agreed on the design, there's another comment from
> Jan
> > about using XENMEM_set_memory_map might be better, while back to Aug.
> > when Tiejun raised that option the answer is "I'm not sure". Note I
> > understand
> > as a maintainer he might not have definite answers for all opens. But w/o a
> > definitive guide new people may waste lots of effort on chasing a wrong
> > option,
> > which is definitely frustrating.
> 
> Main problem being that the maintainers to help here are primarily you,
> and only then me or others - after all this is a VT-d only problem, not a
> general IOMMU one. The fact that non-VT-d code gets touched doesn't
> matter when considering just the design. And that's why I had asked
> Tiejun to work with the two of you on getting the basis right. I don't
> know how much of that possibly happened without the public seeing it,
> but the results seem to suggest not all that much.

We worked with Tiejun on the design, and some level of code review (not much
as you did since it touches lots of different areas), and the version he sent out is 
what we discussed to be a right way to go. But since you tempt to have 
spontaneous different opinions in each series, let's close that first. We'll work
with Tiejun to send a design review request separately, and let's see how it works
and whether it may be split into small steps.

and... as you already noted, when 'RMRR' is a VT feature, the majority code
touched in the patch series are not in VT-d space. Somehow I view this is a
general feature development, i.e. how to reserve a resource from guest 
physical space. RMRR is just one client of this feature, and there could be
others. In such case, we need all the maintainers in corresponding areas to
help, meant you as the general maintainer, meant Tim for mmu part, and
meant Ian for domain builder part, etc... Regarding to design, we need all
on the table and come to agreement.

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 Dec 10 09:58:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 09: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 1Xye2X-0004ge-Jo; Wed, 10 Dec 2014 09:58:37 +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 1Xye2W-0004gZ-Mk
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 09:58:36 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	CE/3C-25727-B4918845; Wed, 10 Dec 2014 09:58:35 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418205513!12271308!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 4574 invoked from network); 10 Dec 2014 09:58:34 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 09:58:34 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 10 Dec 2014 01:58:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="635463694"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by fmsmga001.fm.intel.com with ESMTP; 10 Dec 2014 01:58:31 -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, 10 Dec 2014 17:58:01 +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, 10 Dec 2014 17:57:59 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
	support XEN_DOMCTL_set_rdm
Thread-Index: AQHQE5h0ZLDY7ZdMpU2g0ypuvrX7qZyIH8Ag///inYCAAJOp8A==
Date: Wed, 10 Dec 2014 09:57:59 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126115463@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
	<548819E3020000780004E726@mail.emea.novell.com>
In-Reply-To: <548819E3020000780004E726@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: "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 Deegan <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>, "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, December 10, 2014 5:01 PM
> 
> >>> On 10.12.14 at 04:39, <kevin.tian@intel.com> wrote:
> > 1. It's more efficient for new people to start from a small, well-defined
> > task
> > in one area, and then spanning to adjacent areas gradually. Patience must
> > be given by the community to help them grow;
> 
> Yes. But if a large item like the RMRR one is being picked, this is a
> recipe for failure.

RMRR is already there, just broken. Here what we are doing is to fix it. Regarding
to that, as long as the small item doesn't cause new failures or regressions, it
should be fine.

> 
> > 2. Unfortunately this RMRR effort grows from original two patches (very
> VT-d
> > focused) to now v8 17 patches spanning many areas (including hypercall,
> mmu,
> > domain builder, hvmloader, etc.), and thus imposing both long learning curve
> > and lots of frustrations being no achievement returned. Though having a
> > complete
> > solution is desired, we need to help split the big task into step-by-step
> > approach
> > as long as:
> > 	- the overall design is agreed
> > 	- each step is self-contained
> > 	- each step won't be wasted moving forward.
> > That way new people can see incremental achievements, instead of being hit
> > down before final success.
> >
> > Take this RMRR for example. Maybe we can split into steps like:
> >
> > 	step-1: setup RMRR identify mapping in hypervisor. fail if confliction. no
> > user space changes
> > 	step-2: expose RMRR knowledge to userspace and detect confliction in
> > domain builder and hvmloader
> > 	step-3: reconcile e820/mmio to avoid confliction in a best effort
> > 	step-4: miscellaneous enhancements, each can be ACK-ed individually:
> > 		- handle guest CPU access to RMRR regions
> > 		- handle conflicting RMRR regions
> > 		- handle group RMRRs
> > 		- re-enable USB device assignment
> >
> > That way Tiejun can focus on a self-contained task at one time, and then
> > observe
> > continuous acknowledgements for his work. We don't need to claim RMRR
> fully
> > ready in Xen until last patch is accepted, but that at least provides a way
> > to ack
> > new people when working on complex features and also allow for partial
> usage
> > on his work.
> 
> If only this wouldn't result in regressions when done in steps (like you
> outlined above, or likely also if split up in any other ways). Having to
> do this in one go is the price you/we have to pay for this not having
> got done properly from the beginning.

then let's sit down to clear the design first before going to review the detail.

> 
> > 3. Maintainers sometimes didn't give definitive guidance to the new people,
> > and the high-level design is not closed in the 1st place. e.g. when I thought
> > this v8
> > version has everyone agreed on the design, there's another comment from
> Jan
> > about using XENMEM_set_memory_map might be better, while back to Aug.
> > when Tiejun raised that option the answer is "I'm not sure". Note I
> > understand
> > as a maintainer he might not have definite answers for all opens. But w/o a
> > definitive guide new people may waste lots of effort on chasing a wrong
> > option,
> > which is definitely frustrating.
> 
> Main problem being that the maintainers to help here are primarily you,
> and only then me or others - after all this is a VT-d only problem, not a
> general IOMMU one. The fact that non-VT-d code gets touched doesn't
> matter when considering just the design. And that's why I had asked
> Tiejun to work with the two of you on getting the basis right. I don't
> know how much of that possibly happened without the public seeing it,
> but the results seem to suggest not all that much.

We worked with Tiejun on the design, and some level of code review (not much
as you did since it touches lots of different areas), and the version he sent out is 
what we discussed to be a right way to go. But since you tempt to have 
spontaneous different opinions in each series, let's close that first. We'll work
with Tiejun to send a design review request separately, and let's see how it works
and whether it may be split into small steps.

and... as you already noted, when 'RMRR' is a VT feature, the majority code
touched in the patch series are not in VT-d space. Somehow I view this is a
general feature development, i.e. how to reserve a resource from guest 
physical space. RMRR is just one client of this feature, and there could be
others. In such case, we need all the maintainers in corresponding areas to
help, meant you as the general maintainer, meant Tim for mmu part, and
meant Ian for domain builder part, etc... Regarding to design, we need all
on the table and come to agreement.

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 Dec 10 10:01:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10: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 1Xye4q-0004qn-4q; Wed, 10 Dec 2014 10:01: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 1Xye4o-0004qg-Ja
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 10:00:58 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	B8/58-02698-9D918845; Wed, 10 Dec 2014 10:00:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418205656!14104872!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11418 invoked from network); 10 Dec 2014 10:00:57 -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; 10 Dec 2014 10:00:57 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 10:00:56 +0000
Message-Id: <548827E5020000780004E780@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 10:00:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
	<1418205196.19809.34.camel@eu.citrix.com>
In-Reply-To: <1418205196.19809.34.camel@eu.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>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 10:53, <Ian.Campbell@eu.citrix.com> wrote:
> On Wed, 2014-12-10 at 08:07 +0000, Jan Beulich wrote:
>> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
>> wasn't really consistent in one respect: The granting of access to an
>> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
>> domains. In fact it is wrong to assume that a translation is already/
>> still in place at the time access is being granted/revoked.
> 
> Specifically you need to do the translation using the mapping of the
> domain doing the granting, not the domain being granted too, correct?
> 
> It takes a little bit of thought to figure out which domain to check
> here, it would be worth a sentence or two explaining why this is the
> right one.

Would

"What is wanted is to translate the incoming pIRQ to an IRQ for
 the invoking domain (as the pIRQ is the only notion the invoking
 domain has of the IRQ), and grant the subject domain access to
 the resulting IRQ."

make this more clear without being purely redundant with the code?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:01:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10: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 1Xye4q-0004qn-4q; Wed, 10 Dec 2014 10:01: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 1Xye4o-0004qg-Ja
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 10:00:58 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	B8/58-02698-9D918845; Wed, 10 Dec 2014 10:00:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418205656!14104872!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11418 invoked from network); 10 Dec 2014 10:00:57 -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; 10 Dec 2014 10:00:57 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 10:00:56 +0000
Message-Id: <548827E5020000780004E780@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 10:00:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
	<1418205196.19809.34.camel@eu.citrix.com>
In-Reply-To: <1418205196.19809.34.camel@eu.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>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 10:53, <Ian.Campbell@eu.citrix.com> wrote:
> On Wed, 2014-12-10 at 08:07 +0000, Jan Beulich wrote:
>> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
>> wasn't really consistent in one respect: The granting of access to an
>> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
>> domains. In fact it is wrong to assume that a translation is already/
>> still in place at the time access is being granted/revoked.
> 
> Specifically you need to do the translation using the mapping of the
> domain doing the granting, not the domain being granted too, correct?
> 
> It takes a little bit of thought to figure out which domain to check
> here, it would be worth a sentence or two explaining why this is the
> right one.

Would

"What is wanted is to translate the incoming pIRQ to an IRQ for
 the invoking domain (as the pIRQ is the only notion the invoking
 domain has of the IRQ), and grant the subject domain access to
 the resulting IRQ."

make this more clear without being purely redundant with the code?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:02:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:02:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xye62-000519-LA; Wed, 10 Dec 2014 10:02: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 1Xye61-000511-DY
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:02:13 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	47/C6-31453-42A18845; Wed, 10 Dec 2014 10:02:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418205730!12508323!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 28233 invoked from network); 10 Dec 2014 10:02:12 -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;
	10 Dec 2014 10:02:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202342395"
Message-ID: <1418205728.19809.40.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 10 Dec 2014 10:02:08 +0000
In-Reply-To: <20141210091534.GA24974@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 10:15 +0100, Olaf Hering wrote:
> > I was imagining a "named parameter" as SuS calls them.  One or both
> > the sites which run this wrapper script would pass an environment
> > variable.  Something like this in the script:
> > 
> >   $xenstored_do_exec $XENSTORED "$@" $XENSTORED_TRACE_ARGS $XENSTORED_ARGS
> > 
> > where the systemd unit simply sets `xenstored_do_exec=exec'.
> 
> Ok, I will implement this.

I'm not sure why we don't want to exec in both cases, making this whole
problem moot.

> > In this case that means I think you should find out whether the lack
> > of this xenstore-read polling loop is actually a bug in the existing
> > systemd unit.  If (as I suspect) this is not a bug, then your code
> > motion should not change this aspect of the operation under systemd.
> 
> I think any daemon needs some time until its operational. In case of
> xenstored there are users which expect its functionality right away,
> such as xen-init-dom0 and the other tools launched by xencommons. Thats
> likely the reason why the loop is there, and the commit msg of f706d9e9a
> confirms that. With systemd we can only hope that it handles this
> properly with its socket passing functionality.

I think we should assume that socket activation is working properly, or
else what is the point of socket activation? If it is buggy then we
should fix it, not add hacks to the wrapper or unit files.

That results in a wrapper which unconditionally execs, the systemd unit
just calls that while the sysv script runs the wrapper and then does the
xenstore-read -s loop. 

>  If not, the startup code
> could be done like I did in my patch do avoid code duplication in a
> to-be-added ExecStartPost=.
> 
> And the "is xenstored ready?" check in my current implementation would
> not work anyway because once the shell does exec it will not run the
> following code which does the "xenstore-read -s".

Separately from the above I wonder if it might be worth moving the
xenstore readiness check into the xen-init-dom0 helper and having most
things which currently depend on xenstore actually depend on the
"dom0-is-ready" unit, which itself depends on xenstored, qemu-dom0 and
whatever else is supposed to be ready in a dom0?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:02:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:02:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xye62-000519-LA; Wed, 10 Dec 2014 10:02: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 1Xye61-000511-DY
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:02:13 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	47/C6-31453-42A18845; Wed, 10 Dec 2014 10:02:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418205730!12508323!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 28233 invoked from network); 10 Dec 2014 10:02:12 -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;
	10 Dec 2014 10:02:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202342395"
Message-ID: <1418205728.19809.40.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 10 Dec 2014 10:02:08 +0000
In-Reply-To: <20141210091534.GA24974@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 10:15 +0100, Olaf Hering wrote:
> > I was imagining a "named parameter" as SuS calls them.  One or both
> > the sites which run this wrapper script would pass an environment
> > variable.  Something like this in the script:
> > 
> >   $xenstored_do_exec $XENSTORED "$@" $XENSTORED_TRACE_ARGS $XENSTORED_ARGS
> > 
> > where the systemd unit simply sets `xenstored_do_exec=exec'.
> 
> Ok, I will implement this.

I'm not sure why we don't want to exec in both cases, making this whole
problem moot.

> > In this case that means I think you should find out whether the lack
> > of this xenstore-read polling loop is actually a bug in the existing
> > systemd unit.  If (as I suspect) this is not a bug, then your code
> > motion should not change this aspect of the operation under systemd.
> 
> I think any daemon needs some time until its operational. In case of
> xenstored there are users which expect its functionality right away,
> such as xen-init-dom0 and the other tools launched by xencommons. Thats
> likely the reason why the loop is there, and the commit msg of f706d9e9a
> confirms that. With systemd we can only hope that it handles this
> properly with its socket passing functionality.

I think we should assume that socket activation is working properly, or
else what is the point of socket activation? If it is buggy then we
should fix it, not add hacks to the wrapper or unit files.

That results in a wrapper which unconditionally execs, the systemd unit
just calls that while the sysv script runs the wrapper and then does the
xenstore-read -s loop. 

>  If not, the startup code
> could be done like I did in my patch do avoid code duplication in a
> to-be-added ExecStartPost=.
> 
> And the "is xenstored ready?" check in my current implementation would
> not work anyway because once the shell does exec it will not run the
> following code which does the "xenstore-read -s".

Separately from the above I wonder if it might be worth moving the
xenstore readiness check into the xen-init-dom0 helper and having most
things which currently depend on xenstore actually depend on the
"dom0-is-ready" unit, which itself depends on xenstored, qemu-dom0 and
whatever else is supposed to be ready in a dom0?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:07:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyeB5-0005RY-J0; Wed, 10 Dec 2014 10:07: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 1XyeB4-0005RT-K9
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:07:26 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	93/C5-28296-D5B18845; Wed, 10 Dec 2014 10:07:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418206045!7850885!1
X-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 30573 invoked from network); 10 Dec 2014 10:07:25 -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; 10 Dec 2014 10:07:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 10:07:24 +0000
Message-Id: <5488296A020000780004E794@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 10:07:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>,
	"Zhang Yu" <yu.c.zhang@linux.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
	<548814C2020000780004E6F9@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126115303@SHSMSX101.ccr.corp.intel.com>
	<54881D8A020000780004E73E@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611542D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611542D@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.12.14 at 10:51, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Wednesday, December 10, 2014 5:17 PM
>> 
>> >>> On 10.12.14 at 09:47, <kevin.tian@intel.com> wrote:
>> > two translation paths in assigned case:
>> >
>> > 1. [direct CPU access from VM], with partitioned PCI aperture
>> > resource, every VM can access a portion of PCI aperture directly.
>> >
>> > - CPU page table/EPT: CPU virtual address->PCI aperture
>> > - PCI aperture - bar base = Graphics Memory Address (GMA)
>> > - GPU page table: GMA -> GPA (as programmed by guest)
>> > - IOMMU: GPA -> MPA
>> >
>> > 2. [GPU access through GPU command operands], with GPU scheduling,
>> > every VM's command buffer will be fetched by GPU in a time-shared
>> > manner.
>> >
>> > - GPU page table: GMA->GPA
>> > - IOMMU: GPA->MPA
>> >
>> > In our case, IOMMU is setup with 1:1 identity table for dom0. So
>> > when GPU may access GPAs from different VMs, we can't count on
>> > IOMMU which can only serve one mapping for one device (unless
>> > we have SR-IOV).
>> >
>> > That's why we need shadow GPU page table in dom0, and need a
>> > p2m query call to translate from GPA -> MPA:
>> >
>> > - shadow GPU page table: GMA->MPA
>> > - IOMMU: MPA->MPA (for dom0)
>> 
>> I still can't see why the Dom0 translation has to remain 1:1, i.e.
>> why Xen couldn't return some "arbitrary" GPA for the query in
>> question here, setting up a suitable GPA->MPA translation. (I put
>> arbitrary in quotes because this of course must not conflict with
>> GPAs already or possibly in use by Dom0.) And I can only stress
>> again that you shouldn't leave out PVH (where the IOMMU already
>> isn't set up with all 1:1 mappings) from these considerations.
>> 
> 
> It's interesting that you think IOMMU can be used in such situation.
> 
> what do you mean by "arbitrary" GPA here? and It's not just about 
> conflicting with Dom0's GPA, it's about confliction in all VM's GPAs 
> when you hosting them through one IOMMU page table, and there's 
> no way to prevent this definitely since GPAs are picked by VMs 
> themselves.

As long as for the involved DomU-s the physical address comes in
ways similar to PCI device BARs (which they're capable to deal with),
that's not a problem imo. For Dom0, just like BARs may get assigned
while bringing up PCI devices, a "virtual" BAR could be invented here.

> I don't think we can support PVH here if IOMMU is not 1:1 mapping.

That would make XenGT quite a bit less useful going forward. But
otoh don't you only care about certain MMIO regions to be 1:1
mapped? That's the case for PVH Dom0 too, iirc.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:07:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyeB5-0005RY-J0; Wed, 10 Dec 2014 10:07: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 1XyeB4-0005RT-K9
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:07:26 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	93/C5-28296-D5B18845; Wed, 10 Dec 2014 10:07:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418206045!7850885!1
X-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 30573 invoked from network); 10 Dec 2014 10:07:25 -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; 10 Dec 2014 10:07:25 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 10:07:24 +0000
Message-Id: <5488296A020000780004E794@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 10:07:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>,
	"Zhang Yu" <yu.c.zhang@linux.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>
	<5486D0DD.1000902@linux.intel.com>
	<5486E1EA020000780004E108@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>
	<548814C2020000780004E6F9@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126115303@SHSMSX101.ccr.corp.intel.com>
	<54881D8A020000780004E73E@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611542D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611542D@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.12.14 at 10:51, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Wednesday, December 10, 2014 5:17 PM
>> 
>> >>> On 10.12.14 at 09:47, <kevin.tian@intel.com> wrote:
>> > two translation paths in assigned case:
>> >
>> > 1. [direct CPU access from VM], with partitioned PCI aperture
>> > resource, every VM can access a portion of PCI aperture directly.
>> >
>> > - CPU page table/EPT: CPU virtual address->PCI aperture
>> > - PCI aperture - bar base = Graphics Memory Address (GMA)
>> > - GPU page table: GMA -> GPA (as programmed by guest)
>> > - IOMMU: GPA -> MPA
>> >
>> > 2. [GPU access through GPU command operands], with GPU scheduling,
>> > every VM's command buffer will be fetched by GPU in a time-shared
>> > manner.
>> >
>> > - GPU page table: GMA->GPA
>> > - IOMMU: GPA->MPA
>> >
>> > In our case, IOMMU is setup with 1:1 identity table for dom0. So
>> > when GPU may access GPAs from different VMs, we can't count on
>> > IOMMU which can only serve one mapping for one device (unless
>> > we have SR-IOV).
>> >
>> > That's why we need shadow GPU page table in dom0, and need a
>> > p2m query call to translate from GPA -> MPA:
>> >
>> > - shadow GPU page table: GMA->MPA
>> > - IOMMU: MPA->MPA (for dom0)
>> 
>> I still can't see why the Dom0 translation has to remain 1:1, i.e.
>> why Xen couldn't return some "arbitrary" GPA for the query in
>> question here, setting up a suitable GPA->MPA translation. (I put
>> arbitrary in quotes because this of course must not conflict with
>> GPAs already or possibly in use by Dom0.) And I can only stress
>> again that you shouldn't leave out PVH (where the IOMMU already
>> isn't set up with all 1:1 mappings) from these considerations.
>> 
> 
> It's interesting that you think IOMMU can be used in such situation.
> 
> what do you mean by "arbitrary" GPA here? and It's not just about 
> conflicting with Dom0's GPA, it's about confliction in all VM's GPAs 
> when you hosting them through one IOMMU page table, and there's 
> no way to prevent this definitely since GPAs are picked by VMs 
> themselves.

As long as for the involved DomU-s the physical address comes in
ways similar to PCI device BARs (which they're capable to deal with),
that's not a problem imo. For Dom0, just like BARs may get assigned
while bringing up PCI devices, a "virtual" BAR could be invented here.

> I don't think we can support PVH here if IOMMU is not 1:1 mapping.

That would make XenGT quite a bit less useful going forward. But
otoh don't you only care about certain MMIO regions to be 1:1
mapped? That's the case for PVH Dom0 too, iirc.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:08:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:08:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyeCL-0005WJ-1E; Wed, 10 Dec 2014 10:08:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XyeCJ-0005W9-Vx
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:08:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	48/0D-15461-AAB18845; Wed, 10 Dec 2014 10:08:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418206122!14624758!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7106 invoked from network); 10 Dec 2014 10:08:42 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 10:08:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418206122; l=377;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=MqTcU4bR8RnHEkgbrf7hCslsXt4=;
	b=qgYCh1o3A0a5Xd8p2Y9qPzyJyYc2Ytf+DgN9NV/+zzXk98Q7wlkLCNF4jzOGqXqp1bt
	Ytlx4L2nLR1Wt6CpqwodPXFDJqBt85iCUfwc6jOrhGIDVLHIE8YdyuUJQ7sRhMPb5jv4B
	ySdFMebfyGF0giw6zCuDC+NpcLGR5aqoULY=
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.3 AUTH) with ESMTPSA id V07867qBAA8cB0c
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 10 Dec 2014 11:08:38 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 729915015F; Wed, 10 Dec 2014 11:08:38 +0100 (CET)
Date: Wed, 10 Dec 2014 11:08:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210100838.GA5367@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418205728.19809.40.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, Ian Campbell wrote:

> I'm not sure why we don't want to exec in both cases, making this whole
> problem moot.

Good point!

That will probably work because sysv lets xenstored do the fork, so the
script will return to its caller. In systemd case --no-fork is passed so
the started process will become xenstored, which is expected by systemd.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:08:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:08:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyeCL-0005WJ-1E; Wed, 10 Dec 2014 10:08:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XyeCJ-0005W9-Vx
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:08:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	48/0D-15461-AAB18845; Wed, 10 Dec 2014 10:08:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418206122!14624758!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7106 invoked from network); 10 Dec 2014 10:08:42 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 10:08:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418206122; l=377;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=MqTcU4bR8RnHEkgbrf7hCslsXt4=;
	b=qgYCh1o3A0a5Xd8p2Y9qPzyJyYc2Ytf+DgN9NV/+zzXk98Q7wlkLCNF4jzOGqXqp1bt
	Ytlx4L2nLR1Wt6CpqwodPXFDJqBt85iCUfwc6jOrhGIDVLHIE8YdyuUJQ7sRhMPb5jv4B
	ySdFMebfyGF0giw6zCuDC+NpcLGR5aqoULY=
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.3 AUTH) with ESMTPSA id V07867qBAA8cB0c
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 10 Dec 2014 11:08:38 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 729915015F; Wed, 10 Dec 2014 11:08:38 +0100 (CET)
Date: Wed, 10 Dec 2014 11:08:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210100838.GA5367@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418205728.19809.40.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, Ian Campbell wrote:

> I'm not sure why we don't want to exec in both cases, making this whole
> problem moot.

Good point!

That will probably work because sysv lets xenstored do the fork, so the
script will return to its caller. In systemd case --no-fork is passed so
the started process will become xenstored, which is expected by systemd.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:11:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:11:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyeFO-0005jn-K7; Wed, 10 Dec 2014 10:11: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 1XyeFN-0005jc-5v
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:11:53 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	2D/06-02576-94C18845; Wed, 10 Dec 2014 10:11:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418206279!14131579!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 7977 invoked from network); 10 Dec 2014 10:11: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;
	10 Dec 2014 10:11:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202344894"
Message-ID: <1418206277.19809.48.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Date: Wed, 10 Dec 2014 10:11:17 +0000
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114D11@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
	<1418124543.14361.27.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD0257859BB@AMSPEX01CL01.citrite.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114D11@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-12-10 at 01:48 +0000, Tian, Kevin wrote:
> I'm not familiar with Arm architecture, but based on a brief reading it's
> for the assigned case where the MMU is exclusive owned by a VM, so
> some type of MMU virtualization is required and it's straightforward.

> However XenGT is a shared GPU usage:
> 
> - a global GPU page table is partitioned among VMs. a shared shadow
> global page table is maintained, containing translations for multiple
> VMs simultaneously based on partitioning information
> - multiple per-process GPU page tables are created by each VM, and
> multiple shadow per-process GPU page tables are created correspondingly.
> shadow page table is switched when doing GPU context switch, same as
> what we did for CPU shadow page table.

None of that sounds to me to be impossible to do in the remoteproc
model, perhaps it needs some extensions from its initial core feature
set but I see no reason why it couldn't maintain multiple sets of page
tables, each tagged with an owning domain (for validation purposes) and
a mechanism to switch between them, or to be able to manage partitioning
of the GPU address space.

> So you can see above shared MMU virtualization usage is very GPU
> specific,

AIUI remoteproc is specific to a particular h/w device too, i.e. there
is a device specific stub in the hypervisor which essentially knows how
to implement set_pte for that bit of h/w, with appropriate safety and
validation, as well as a write_cr3 type operation.

>  that's why we didn't put in Xen hypervisor, and thus additional
> interface is required to get p2m mapping to assist our shadow GPU
> page table usage.

There is a great reluctance among several maintainers to expose real
hardware MFNs to VMs (including dom0 and backend driver domains).

I think you need to think very carefully about possible ways of avoiding
the need for this. Yes, this might require some changes to your current
mode/design.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:11:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:11:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyeFO-0005jn-K7; Wed, 10 Dec 2014 10:11: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 1XyeFN-0005jc-5v
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:11:53 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	2D/06-02576-94C18845; Wed, 10 Dec 2014 10:11:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418206279!14131579!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 7977 invoked from network); 10 Dec 2014 10:11: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;
	10 Dec 2014 10:11:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202344894"
Message-ID: <1418206277.19809.48.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Date: Wed, 10 Dec 2014 10:11:17 +0000
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114D11@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
	<1418124543.14361.27.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD0257859BB@AMSPEX01CL01.citrite.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114D11@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-12-10 at 01:48 +0000, Tian, Kevin wrote:
> I'm not familiar with Arm architecture, but based on a brief reading it's
> for the assigned case where the MMU is exclusive owned by a VM, so
> some type of MMU virtualization is required and it's straightforward.

> However XenGT is a shared GPU usage:
> 
> - a global GPU page table is partitioned among VMs. a shared shadow
> global page table is maintained, containing translations for multiple
> VMs simultaneously based on partitioning information
> - multiple per-process GPU page tables are created by each VM, and
> multiple shadow per-process GPU page tables are created correspondingly.
> shadow page table is switched when doing GPU context switch, same as
> what we did for CPU shadow page table.

None of that sounds to me to be impossible to do in the remoteproc
model, perhaps it needs some extensions from its initial core feature
set but I see no reason why it couldn't maintain multiple sets of page
tables, each tagged with an owning domain (for validation purposes) and
a mechanism to switch between them, or to be able to manage partitioning
of the GPU address space.

> So you can see above shared MMU virtualization usage is very GPU
> specific,

AIUI remoteproc is specific to a particular h/w device too, i.e. there
is a device specific stub in the hypervisor which essentially knows how
to implement set_pte for that bit of h/w, with appropriate safety and
validation, as well as a write_cr3 type operation.

>  that's why we didn't put in Xen hypervisor, and thus additional
> interface is required to get p2m mapping to assist our shadow GPU
> page table usage.

There is a great reluctance among several maintainers to expose real
hardware MFNs to VMs (including dom0 and backend driver domains).

I think you need to think very carefully about possible ways of avoiding
the need for this. Yes, this might require some changes to your current
mode/design.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:12:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10: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 1XyeFq-0005nA-13; Wed, 10 Dec 2014 10:12: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 1XyeFo-0005mu-Sl
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 10:12:21 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	3D/AB-22819-48C18845; Wed, 10 Dec 2014 10:12:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418206338!12574451!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 24215 invoked from network); 10 Dec 2014 10:12:19 -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 Dec 2014 10:12:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202751722"
Message-ID: <1418206335.19809.49.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 10 Dec 2014 10:12:15 +0000
In-Reply-To: <548827E5020000780004E780@mail.emea.novell.com>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
	<1418205196.19809.34.camel@eu.citrix.com>
	<548827E5020000780004E780@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 10:00 +0000, Jan Beulich wrote:
> >>> On 10.12.14 at 10:53, <Ian.Campbell@eu.citrix.com> wrote:
> > On Wed, 2014-12-10 at 08:07 +0000, Jan Beulich wrote:
> >> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> >> wasn't really consistent in one respect: The granting of access to an
> >> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> >> domains. In fact it is wrong to assume that a translation is already/
> >> still in place at the time access is being granted/revoked.
> > 
> > Specifically you need to do the translation using the mapping of the
> > domain doing the granting, not the domain being granted too, correct?
> > 
> > It takes a little bit of thought to figure out which domain to check
> > here, it would be worth a sentence or two explaining why this is the
> > right one.
> 
> Would
> 
> "What is wanted is to translate the incoming pIRQ to an IRQ for
>  the invoking domain (as the pIRQ is the only notion the invoking
>  domain has of the IRQ), and grant the subject domain access to
>  the resulting IRQ."
> 
> make this more clear without being purely redundant with the code?

Yes, thanks.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:12:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10: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 1XyeFq-0005nA-13; Wed, 10 Dec 2014 10:12: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 1XyeFo-0005mu-Sl
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 10:12:21 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	3D/AB-22819-48C18845; Wed, 10 Dec 2014 10:12:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418206338!12574451!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 24215 invoked from network); 10 Dec 2014 10:12:19 -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 Dec 2014 10:12:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202751722"
Message-ID: <1418206335.19809.49.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 10 Dec 2014 10:12:15 +0000
In-Reply-To: <548827E5020000780004E780@mail.emea.novell.com>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
	<1418205196.19809.34.camel@eu.citrix.com>
	<548827E5020000780004E780@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 10:00 +0000, Jan Beulich wrote:
> >>> On 10.12.14 at 10:53, <Ian.Campbell@eu.citrix.com> wrote:
> > On Wed, 2014-12-10 at 08:07 +0000, Jan Beulich wrote:
> >> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> >> wasn't really consistent in one respect: The granting of access to an
> >> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> >> domains. In fact it is wrong to assume that a translation is already/
> >> still in place at the time access is being granted/revoked.
> > 
> > Specifically you need to do the translation using the mapping of the
> > domain doing the granting, not the domain being granted too, correct?
> > 
> > It takes a little bit of thought to figure out which domain to check
> > here, it would be worth a sentence or two explaining why this is the
> > right one.
> 
> Would
> 
> "What is wanted is to translate the incoming pIRQ to an IRQ for
>  the invoking domain (as the pIRQ is the only notion the invoking
>  domain has of the IRQ), and grant the subject domain access to
>  the resulting IRQ."
> 
> make this more clear without being purely redundant with the code?

Yes, thanks.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:20:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyeND-0006H5-V9; Wed, 10 Dec 2014 10:19:59 +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 1XyeNC-0006H0-Vj
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 10:19:59 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	A6/12-02576-D4E18845; Wed, 10 Dec 2014 10:19:57 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418206796!14111310!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30938 invoked from network); 10 Dec 2014 10:19:57 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 10:19:57 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so4594892wiv.8
	for <xen-devel@lists.xenproject.org>;
	Wed, 10 Dec 2014 02:19: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=Pzam70+7dQR2zSjRbFD/ysTemR/hZAPXDHVcaXE9BME=;
	b=XuwxXGjjxmgKGPI1HRYf9/8jh0Zs/QrG3lkvvdw4LCS7wbYGh6BJ7L2qrEOvwFXqV3
	p6ImGGJs+UqQ/R7G8mGfHmdzWyaWBh2JrmwVa6Sqd7aUpkNoIGxXAccSR2AEsQirx1Vi
	1XrBVWd+7qw2UVU1tOpKuviKK5VUNTR/8Z+y1+xEaj23SeQBA3hpGf8tYO9wUMB3YMBh
	hDzYvcn4Rh36HNMKN0UJi+O7wnhspFrgeb9hon3fGlSAXgVHGdXPRtY7z+E0xQqJjZ2O
	xIiupWyBNz48TDKcJxMcvKsZ6BU41WTyPaBK9JrP3DRXcP1LGrI6HxyMiC+X6IN6f/5u
	YJyA==
X-Gm-Message-State: ALoCoQlHPXCTnukh4CyolMi1PBttTZCWLxafrp1mOvaVA1iTidU+kit/5OFVu6ChGRxMEIiNX8CX
X-Received: by 10.194.83.42 with SMTP id n10mr4902809wjy.133.1418206795317;
	Wed, 10 Dec 2014 02:19:55 -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 u1sm6492175wif.6.2014.12.10.02.19.53
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 02:19:54 -0800 (PST)
Message-ID: <54881E49.7090009@linaro.org>
Date: Wed, 10 Dec 2014 10:19:53 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, 
	xen-devel <xen-devel@lists.xenproject.org>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
In-Reply-To: <54880D6B020000780004E6AA@mail.emea.novell.com>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 10/12/2014 08:07, Jan Beulich wrote:
> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> wasn't really consistent in one respect: The granting of access to an
> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> domains. In fact it is wrong to assume that a translation is already/
> still in place at the time access is being granted/revoked.

With the change to the interface, some part of libxl may misuse 
xc_domain_irq_permission. For instance in tools/libxl/libxl_create.c:

1178         ret = irq >= 0 ? xc_physdev_map_pirq(CTX->xch, domid, irq, 
&irq)

We get the PIRQ of domain domid in irq.

1179                        : -EOVERFLOW;
1180         if (!ret)
1181             ret = xc_domain_irq_permission(CTX->xch, domid, irq,
1)

Here, the PIRQ of the current domain should be passed. Fortunately, for 
this specific case, the PIRQs are the same. But this is confusing.

>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>
>       case XEN_DOMCTL_irq_permission:
>       {
> -        unsigned int pirq = op->u.irq_permission.pirq;
> +        unsigned int pirq = op->u.irq_permission.pirq, irq;
>           int allow = op->u.irq_permission.allow_access;
>
>           if ( pirq >= d->nr_pirqs )
>               ret = -EINVAL;
> -        else if ( !pirq_access_permitted(current->domain, pirq) ||
> +        else if ( !(irq = pirq_access_permitted(current->domain, pirq)) ||
>                     xsm_irq_permission(XSM_HOOK, d, pirq, allow) )

As the pirq may not be the same in domain d, the XSM permission is wrong 
here.

In anycase, it looks weird to use pirq here because the guy who defines 
the policy may not know the PIRQ value.

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 Dec 10 10:20:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyeND-0006H5-V9; Wed, 10 Dec 2014 10:19:59 +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 1XyeNC-0006H0-Vj
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 10:19:59 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	A6/12-02576-D4E18845; Wed, 10 Dec 2014 10:19:57 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418206796!14111310!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30938 invoked from network); 10 Dec 2014 10:19:57 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 10:19:57 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so4594892wiv.8
	for <xen-devel@lists.xenproject.org>;
	Wed, 10 Dec 2014 02:19: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=Pzam70+7dQR2zSjRbFD/ysTemR/hZAPXDHVcaXE9BME=;
	b=XuwxXGjjxmgKGPI1HRYf9/8jh0Zs/QrG3lkvvdw4LCS7wbYGh6BJ7L2qrEOvwFXqV3
	p6ImGGJs+UqQ/R7G8mGfHmdzWyaWBh2JrmwVa6Sqd7aUpkNoIGxXAccSR2AEsQirx1Vi
	1XrBVWd+7qw2UVU1tOpKuviKK5VUNTR/8Z+y1+xEaj23SeQBA3hpGf8tYO9wUMB3YMBh
	hDzYvcn4Rh36HNMKN0UJi+O7wnhspFrgeb9hon3fGlSAXgVHGdXPRtY7z+E0xQqJjZ2O
	xIiupWyBNz48TDKcJxMcvKsZ6BU41WTyPaBK9JrP3DRXcP1LGrI6HxyMiC+X6IN6f/5u
	YJyA==
X-Gm-Message-State: ALoCoQlHPXCTnukh4CyolMi1PBttTZCWLxafrp1mOvaVA1iTidU+kit/5OFVu6ChGRxMEIiNX8CX
X-Received: by 10.194.83.42 with SMTP id n10mr4902809wjy.133.1418206795317;
	Wed, 10 Dec 2014 02:19:55 -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 u1sm6492175wif.6.2014.12.10.02.19.53
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 02:19:54 -0800 (PST)
Message-ID: <54881E49.7090009@linaro.org>
Date: Wed, 10 Dec 2014 10:19:53 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>, 
	xen-devel <xen-devel@lists.xenproject.org>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
In-Reply-To: <54880D6B020000780004E6AA@mail.emea.novell.com>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 10/12/2014 08:07, Jan Beulich wrote:
> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> wasn't really consistent in one respect: The granting of access to an
> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> domains. In fact it is wrong to assume that a translation is already/
> still in place at the time access is being granted/revoked.

With the change to the interface, some part of libxl may misuse 
xc_domain_irq_permission. For instance in tools/libxl/libxl_create.c:

1178         ret = irq >= 0 ? xc_physdev_map_pirq(CTX->xch, domid, irq, 
&irq)

We get the PIRQ of domain domid in irq.

1179                        : -EOVERFLOW;
1180         if (!ret)
1181             ret = xc_domain_irq_permission(CTX->xch, domid, irq,
1)

Here, the PIRQ of the current domain should be passed. Fortunately, for 
this specific case, the PIRQs are the same. But this is confusing.

>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>
>       case XEN_DOMCTL_irq_permission:
>       {
> -        unsigned int pirq = op->u.irq_permission.pirq;
> +        unsigned int pirq = op->u.irq_permission.pirq, irq;
>           int allow = op->u.irq_permission.allow_access;
>
>           if ( pirq >= d->nr_pirqs )
>               ret = -EINVAL;
> -        else if ( !pirq_access_permitted(current->domain, pirq) ||
> +        else if ( !(irq = pirq_access_permitted(current->domain, pirq)) ||
>                     xsm_irq_permission(XSM_HOOK, d, pirq, allow) )

As the pirq may not be the same in domain d, the XSM permission is wrong 
here.

In anycase, it looks weird to use pirq here because the guy who defines 
the policy may not know the PIRQ value.

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 Dec 10 10:30:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 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 1XyeWn-0006gr-1z; Wed, 10 Dec 2014 10:29: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 1XyeWl-0006gm-RU
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:29:51 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	24/82-22737-F9028845; Wed, 10 Dec 2014 10:29:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418207390!7130210!1
X-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 26318 invoked from network); 10 Dec 2014 10:29:50 -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; 10 Dec 2014 10:29:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 10:29:49 +0000
Message-Id: <54882EAA020000780004E7DE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 10:29:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Matt Wilson" <msw@linux.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
	<20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
In-Reply-To: <20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Keir Fraser <keir@xen.org>, 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 10.12.14 at 07:00, <msw@linux.com> wrote:
> On Thu, Nov 06, 2014 at 09:27:59PM +0000, Andrew Cooper wrote:
>> 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.
> 
> Sorry for chiming in late...
> 
> That's not strictly true. You can use the processor index in ACPI.

Not really, no. The ACPI tables get created by hvmloader, without
regard to Xen vCPU numbering afaict.

>> >> 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.
> 
> No, don't assume anything about APIC IDs mapping to Xen virtual
> processor index. This will break things on EC2 instances that expose
> proper CPU topology through CPUID, and this does *not* follow the
> "index * 2" formula.

Hmm, you say "no" first, but the rest of your statement seems to
agree with what Andrew was saying...

>> >> 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.
> 
> And the Xen vCPU index can be determined by the processor object IDs
> in DSDT.

I hope you don't have code doing so, as such an association isn't
pinned down anywhere in the ABI afaik.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:30:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 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 1XyeWn-0006gr-1z; Wed, 10 Dec 2014 10:29: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 1XyeWl-0006gm-RU
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:29:51 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	24/82-22737-F9028845; Wed, 10 Dec 2014 10:29:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418207390!7130210!1
X-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 26318 invoked from network); 10 Dec 2014 10:29:50 -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; 10 Dec 2014 10:29:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 10:29:49 +0000
Message-Id: <54882EAA020000780004E7DE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 10:29:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Matt Wilson" <msw@linux.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
	<20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
In-Reply-To: <20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Keir Fraser <keir@xen.org>, 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 10.12.14 at 07:00, <msw@linux.com> wrote:
> On Thu, Nov 06, 2014 at 09:27:59PM +0000, Andrew Cooper wrote:
>> 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.
> 
> Sorry for chiming in late...
> 
> That's not strictly true. You can use the processor index in ACPI.

Not really, no. The ACPI tables get created by hvmloader, without
regard to Xen vCPU numbering afaict.

>> >> 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.
> 
> No, don't assume anything about APIC IDs mapping to Xen virtual
> processor index. This will break things on EC2 instances that expose
> proper CPU topology through CPUID, and this does *not* follow the
> "index * 2" formula.

Hmm, you say "no" first, but the rest of your statement seems to
agree with what Andrew was saying...

>> >> 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.
> 
> And the Xen vCPU index can be determined by the processor object IDs
> in DSDT.

I hope you don't have code doing so, as such an association isn't
pinned down anywhere in the ABI afaik.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:36:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:36:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyed6-00076I-DV; Wed, 10 Dec 2014 10:36:24 +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 1Xyed4-00075w-Qo
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:36:22 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	52/8C-17735-62228845; Wed, 10 Dec 2014 10:36:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418207780!12314199!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 14779 invoked from network); 10 Dec 2014 10:36:21 -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 Dec 2014 10:36:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202758494"
Message-ID: <54882222.7090005@citrix.com>
Date: Wed, 10 Dec 2014 10:36:18 +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: Matt Wilson <msw@linux.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
	<20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
In-Reply-To: <20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	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 10/12/14 06:00, Matt Wilson wrote:
> On Thu, Nov 06, 2014 at 09:27:59PM +0000, Andrew Cooper wrote:
>> 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.
> Sorry for chiming in late...
>
> That's not strictly true. You can use the processor index in ACPI.

The LAPIC objects in the MADT/APIC table?  That is still constructed
with the broken LAPIC_ID = 2 * processor_id logic.

>
>> 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)
> This is absolutely the wrong thing to do. If a guest OS is doing this,
> it is doing the wrong thing. FreeBSD went down this erroneous path...
>
> See http://lists.xen.org/archives/html/xen-devel/2013-05/msg03156.html
>
>>>> 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.
> No, don't assume anything about APIC IDs mapping to Xen virtual
> processor index. This will break things on EC2 instances that expose
> proper CPU topology through CPUID, and this does *not* follow the
> "index * 2" formula.
>
>>>> 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.
> And the Xen vCPU index can be determined by the processor object IDs
> in DSDT.

The processor object IDs have no requirement in the spec to be in order,
or contiguous.  A DSDT processor object refers back to the MADT, which
in turn still has the broken logic.

Also, any solution using ACPI tables is going to be an issue for PVH guests.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:36:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:36:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyed6-00076I-DV; Wed, 10 Dec 2014 10:36:24 +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 1Xyed4-00075w-Qo
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:36:22 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	52/8C-17735-62228845; Wed, 10 Dec 2014 10:36:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418207780!12314199!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 14779 invoked from network); 10 Dec 2014 10:36:21 -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 Dec 2014 10:36:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202758494"
Message-ID: <54882222.7090005@citrix.com>
Date: Wed, 10 Dec 2014 10:36:18 +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: Matt Wilson <msw@linux.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
	<20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
In-Reply-To: <20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
X-DLP: MIA2
Cc: xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	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 10/12/14 06:00, Matt Wilson wrote:
> On Thu, Nov 06, 2014 at 09:27:59PM +0000, Andrew Cooper wrote:
>> 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.
> Sorry for chiming in late...
>
> That's not strictly true. You can use the processor index in ACPI.

The LAPIC objects in the MADT/APIC table?  That is still constructed
with the broken LAPIC_ID = 2 * processor_id logic.

>
>> 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)
> This is absolutely the wrong thing to do. If a guest OS is doing this,
> it is doing the wrong thing. FreeBSD went down this erroneous path...
>
> See http://lists.xen.org/archives/html/xen-devel/2013-05/msg03156.html
>
>>>> 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.
> No, don't assume anything about APIC IDs mapping to Xen virtual
> processor index. This will break things on EC2 instances that expose
> proper CPU topology through CPUID, and this does *not* follow the
> "index * 2" formula.
>
>>>> 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.
> And the Xen vCPU index can be determined by the processor object IDs
> in DSDT.

The processor object IDs have no requirement in the spec to be in order,
or contiguous.  A DSDT processor object refers back to the MADT, which
in turn still has the broken logic.

Also, any solution using ACPI tables is going to be an issue for PVH guests.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:36:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:36:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyed5-000761-T1; Wed, 10 Dec 2014 10:36:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xyed4-00075r-3k
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:36:22 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FB/64-15461-52228845; Wed, 10 Dec 2014 10:36:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418207780!6592854!1
X-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 16130 invoked from network); 10 Dec 2014 10:36:20 -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; 10 Dec 2014 10:36:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 10:36:20 +0000
Message-Id: <54883031020000780004E7EC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 10:36:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.12.14 at 02:14, <kevin.tian@intel.com> wrote:
>>  From: Tim Deegan [mailto:tim@xen.org]
>> It's been suggested before that we should revive this hypercall, and I
>> don't think it's a good idea.  Whenever a domain needs to know the
>> actual MFN of another domain's memory it's usually because the
>> security model is problematic.  In particular, finding the MFN is
>> usually followed by a brute-force mapping from a dom0 process, or by
>> passing the MFN to a device for unprotected DMA.
> 
> In our case it's not because the security model is problematic. It's 
> because GPU virtualization is done in Dom0 while the memory virtualization
> is done in hypervisor.

Which by itself is a questionable design decision.

> We need a means to query GPFN->MFN so we can
> setup shadow GPU page table in Dom0 correctly, for a VM.
> 
>> 
>> These days DMA access should be protected by IOMMUs, or else
>> the device drivers (and associated tools) are effectively inside the
>> hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
>> presumably present on anything new enough to run XenGT?).
> 
> yes, IOMMU protect DMA accesses in a device-agnostic way. But in
> our case, IOMMU can't be used because it's only for exclusively
> assigned case, as I replied in another mail. And to reduce the hypervisor
> TCB, we put device model in Dom0 which is why a interface is required
> to connect p2m information.
> 
>> 
>> So I think the interface we need here is a please-map-this-gfn one,
>> like the existing grant-table ops (which already do what you need by
>> returning an address suitable for DMA).  If adding a grant entry for
>> every frame of the framebuffer within the guest is too much, maybe we
>> can make a new interface for the guest to grant access to larger areas.
> 
> A please-map-this-gfn interface assumes the logic behind lies in Xen
> hypervisor, e.g. managing CPU page table or IOMMU entry. However
> here the management of GPU page table is in Dom0, and what we
> want is a please-tell-me-mfn-for-a-gpfn interface, so we can translate
> from gpfn in guest GPU PTE to a mfn in shadow GPU PTE. 

As said before, what needs to be put in the GPU PTE depends on
what the subsequent IOMMU translation would do to the address.
It's not a hard requirement for the IOMMU to pass through all
addresses for Dom0, so we have room to isolate things if possible.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:36:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:36:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyed5-000761-T1; Wed, 10 Dec 2014 10:36:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xyed4-00075r-3k
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:36:22 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FB/64-15461-52228845; Wed, 10 Dec 2014 10:36:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418207780!6592854!1
X-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 16130 invoked from network); 10 Dec 2014 10:36:20 -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; 10 Dec 2014 10:36:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 10:36:20 +0000
Message-Id: <54883031020000780004E7EC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 10:36:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.12.14 at 02:14, <kevin.tian@intel.com> wrote:
>>  From: Tim Deegan [mailto:tim@xen.org]
>> It's been suggested before that we should revive this hypercall, and I
>> don't think it's a good idea.  Whenever a domain needs to know the
>> actual MFN of another domain's memory it's usually because the
>> security model is problematic.  In particular, finding the MFN is
>> usually followed by a brute-force mapping from a dom0 process, or by
>> passing the MFN to a device for unprotected DMA.
> 
> In our case it's not because the security model is problematic. It's 
> because GPU virtualization is done in Dom0 while the memory virtualization
> is done in hypervisor.

Which by itself is a questionable design decision.

> We need a means to query GPFN->MFN so we can
> setup shadow GPU page table in Dom0 correctly, for a VM.
> 
>> 
>> These days DMA access should be protected by IOMMUs, or else
>> the device drivers (and associated tools) are effectively inside the
>> hypervisor's TCB.  Luckily on x86 IOMMUs are widely available (and
>> presumably present on anything new enough to run XenGT?).
> 
> yes, IOMMU protect DMA accesses in a device-agnostic way. But in
> our case, IOMMU can't be used because it's only for exclusively
> assigned case, as I replied in another mail. And to reduce the hypervisor
> TCB, we put device model in Dom0 which is why a interface is required
> to connect p2m information.
> 
>> 
>> So I think the interface we need here is a please-map-this-gfn one,
>> like the existing grant-table ops (which already do what you need by
>> returning an address suitable for DMA).  If adding a grant entry for
>> every frame of the framebuffer within the guest is too much, maybe we
>> can make a new interface for the guest to grant access to larger areas.
> 
> A please-map-this-gfn interface assumes the logic behind lies in Xen
> hypervisor, e.g. managing CPU page table or IOMMU entry. However
> here the management of GPU page table is in Dom0, and what we
> want is a please-tell-me-mfn-for-a-gpfn interface, so we can translate
> from gpfn in guest GPU PTE to a mfn in shadow GPU PTE. 

As said before, what needs to be put in the GPU PTE depends on
what the subsequent IOMMU translation would do to the address.
It's not a hard requirement for the IOMMU to pass through all
addresses for Dom0, so we have room to isolate things if possible.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:46:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10: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 1XyemR-0007fM-Fu; Wed, 10 Dec 2014 10:46:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyemQ-0007fH-B9
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 10:46:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	63/B8-15461-96428845; Wed, 10 Dec 2014 10:46:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418208359!14624214!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 13066 invoked from network); 10 Dec 2014 10:46: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;
	10 Dec 2014 10:46:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202760846"
Message-ID: <1418208357.3505.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 10 Dec 2014 10:45:57 +0000
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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 v2 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 Tue, 2014-12-09 at 15:54 +0000, Ian Jackson wrote:
> Version 1 had:
>  Tested-by: Ian Campbell <ian.campbell@citrix.com>
> but that does not apply any more from patch 5 onwards since patch 5
> has changed.
> 
> Ian C, do you still have the setup you used to test v1 ?

Yes, and I've just rerun with this new version of the patches and it was
fine, so the tested-by can stand.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:46:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10: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 1XyemW-0007fp-Si; Wed, 10 Dec 2014 10:46:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyemV-0007fV-08
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 10:46:07 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	5C/7F-25714-E6428845; Wed, 10 Dec 2014 10:46:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418208365!7246355!1
X-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 21144 invoked from network); 10 Dec 2014 10:46:05 -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; 10 Dec 2014 10:46:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 10:46:05 +0000
Message-Id: <5488327B020000780004E80A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 10:46:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
	<54881E49.7090009@linaro.org>
In-Reply-To: <54881E49.7090009@linaro.org>
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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
 granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 11:19, <julien.grall@linaro.org> wrote:
> Hi Jan,
> 
> On 10/12/2014 08:07, Jan Beulich wrote:
>> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
>> wasn't really consistent in one respect: The granting of access to an
>> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
>> domains. In fact it is wrong to assume that a translation is already/
>> still in place at the time access is being granted/revoked.
> 
> With the change to the interface, some part of libxl may misuse 
> xc_domain_irq_permission. For instance in tools/libxl/libxl_create.c:
> 
> 1178         ret = irq >= 0 ? xc_physdev_map_pirq(CTX->xch, domid, irq, 
> &irq)
> 
> We get the PIRQ of domain domid in irq.
> 
> 1179                        : -EOVERFLOW;
> 1180         if (!ret)
> 1181             ret = xc_domain_irq_permission(CTX->xch, domid, irq,
> 1)
> 
> Here, the PIRQ of the current domain should be passed. Fortunately, for 
> this specific case, the PIRQs are the same. But this is confusing.

Agreed, but I'd leave it to the tools maintainers to clean this up.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:46:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10: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 1XyemR-0007fM-Fu; Wed, 10 Dec 2014 10:46:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyemQ-0007fH-B9
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 10:46:02 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	63/B8-15461-96428845; Wed, 10 Dec 2014 10:46:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418208359!14624214!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 13066 invoked from network); 10 Dec 2014 10:46: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;
	10 Dec 2014 10:46:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,551,1413244800"; d="scan'208";a="202760846"
Message-ID: <1418208357.3505.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 10 Dec 2014 10:45:57 +0000
In-Reply-To: <1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1417112870-31894-1-git-send-email-ian.jackson@eu.citrix.com>
	<1418140489-21196-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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 v2 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 Tue, 2014-12-09 at 15:54 +0000, Ian Jackson wrote:
> Version 1 had:
>  Tested-by: Ian Campbell <ian.campbell@citrix.com>
> but that does not apply any more from patch 5 onwards since patch 5
> has changed.
> 
> Ian C, do you still have the setup you used to test v1 ?

Yes, and I've just rerun with this new version of the patches and it was
fine, so the tested-by can stand.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:46:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10: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 1XyemW-0007fp-Si; Wed, 10 Dec 2014 10:46:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XyemV-0007fV-08
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 10:46:07 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	5C/7F-25714-E6428845; Wed, 10 Dec 2014 10:46:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418208365!7246355!1
X-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 21144 invoked from network); 10 Dec 2014 10:46:05 -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; 10 Dec 2014 10:46:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 10:46:05 +0000
Message-Id: <5488327B020000780004E80A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 10:46:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
	<54881E49.7090009@linaro.org>
In-Reply-To: <54881E49.7090009@linaro.org>
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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
 granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 11:19, <julien.grall@linaro.org> wrote:
> Hi Jan,
> 
> On 10/12/2014 08:07, Jan Beulich wrote:
>> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
>> wasn't really consistent in one respect: The granting of access to an
>> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
>> domains. In fact it is wrong to assume that a translation is already/
>> still in place at the time access is being granted/revoked.
> 
> With the change to the interface, some part of libxl may misuse 
> xc_domain_irq_permission. For instance in tools/libxl/libxl_create.c:
> 
> 1178         ret = irq >= 0 ? xc_physdev_map_pirq(CTX->xch, domid, irq, 
> &irq)
> 
> We get the PIRQ of domain domid in irq.
> 
> 1179                        : -EOVERFLOW;
> 1180         if (!ret)
> 1181             ret = xc_domain_irq_permission(CTX->xch, domid, irq,
> 1)
> 
> Here, the PIRQ of the current domain should be passed. Fortunately, for 
> this specific case, the PIRQs are the same. But this is confusing.

Agreed, but I'd leave it to the tools maintainers to clean this up.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:55:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:55:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyev0-0008D2-Rw; Wed, 10 Dec 2014 10:54:54 +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 1Xyeuz-0008Cx-LE
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:54:53 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	99/97-27623-C7628845; Wed, 10 Dec 2014 10:54:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418208890!12302337!1
X-Originating-IP: [66.165.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 32298 invoked from network); 10 Dec 2014 10:54:52 -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;
	10 Dec 2014 10:54:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202763424"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 05:54: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 1Xyeuv-0004av-Rv;
	Wed, 10 Dec 2014 10:54:49 +0000
Date: Wed, 10 Dec 2014 10:54:49 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141210105449.GA15588@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
	<54873724020000780004E37B@mail.emea.novell.com>
	<20141209180657.GG25749@zion.uk.xensource.com>
	<54881066020000780004E6D6@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54881066020000780004E6D6@mail.emea.novell.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@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 13/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 Wed, Dec 10, 2014 at 08:20:38AM +0000, Jan Beulich wrote:
> >>> On 09.12.14 at 19:06, <wei.liu2@citrix.com> wrote:
> > On Tue, Dec 09, 2014 at 04:53:40PM +0000, Jan Beulich wrote:
> >> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> >> > +        memset(memory, 0, sizeof(*memory));
> >> > +        memory->type          = ACPI_MEMORY_AFFINITY;
> >> > +        memory->length        = sizeof(*memory);
> >> > +        memory->domain        = vmemrange[i].nid;
> >> > +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
> >> > +        memory->base_address  = vmemrange[i].start;
> >> > +        memory->mem_length    = mem;
> >> > +        memory++;
> >> > +    }
> >> > +
> >> > +    srat->header.length = size;
> >> 
> >> Mind checking size == memory - p here?
> >> 
> > 
> > Why? There doesn't seem to be anything that would cause memory -p !=
> > size in between during runtime.
> 
> Except for that original calculation being wrong - that's what I would
> mean such a check to verify.
> 

Do you mean the code is wrong? I don't think so.

Even if I have 

+    if ( ((unsigned long)memory) - ((unsigned long)p) != size )
+        return NULL;
+

Hvmloader doesn't complain, i.e. I don't see error message printed out
in the construct_secondary_tables.

Anyway, if the above snippet is what you want, I can add it.

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 Dec 10 10:55:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10:55:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyev0-0008D2-Rw; Wed, 10 Dec 2014 10:54:54 +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 1Xyeuz-0008Cx-LE
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:54:53 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	99/97-27623-C7628845; Wed, 10 Dec 2014 10:54:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418208890!12302337!1
X-Originating-IP: [66.165.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 32298 invoked from network); 10 Dec 2014 10:54:52 -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;
	10 Dec 2014 10:54:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202763424"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 05:54: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 1Xyeuv-0004av-Rv;
	Wed, 10 Dec 2014 10:54:49 +0000
Date: Wed, 10 Dec 2014 10:54:49 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141210105449.GA15588@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
	<54873724020000780004E37B@mail.emea.novell.com>
	<20141209180657.GG25749@zion.uk.xensource.com>
	<54881066020000780004E6D6@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54881066020000780004E6D6@mail.emea.novell.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@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 13/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 Wed, Dec 10, 2014 at 08:20:38AM +0000, Jan Beulich wrote:
> >>> On 09.12.14 at 19:06, <wei.liu2@citrix.com> wrote:
> > On Tue, Dec 09, 2014 at 04:53:40PM +0000, Jan Beulich wrote:
> >> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> >> > +        memset(memory, 0, sizeof(*memory));
> >> > +        memory->type          = ACPI_MEMORY_AFFINITY;
> >> > +        memory->length        = sizeof(*memory);
> >> > +        memory->domain        = vmemrange[i].nid;
> >> > +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
> >> > +        memory->base_address  = vmemrange[i].start;
> >> > +        memory->mem_length    = mem;
> >> > +        memory++;
> >> > +    }
> >> > +
> >> > +    srat->header.length = size;
> >> 
> >> Mind checking size == memory - p here?
> >> 
> > 
> > Why? There doesn't seem to be anything that would cause memory -p !=
> > size in between during runtime.
> 
> Except for that original calculation being wrong - that's what I would
> mean such a check to verify.
> 

Do you mean the code is wrong? I don't think so.

Even if I have 

+    if ( ((unsigned long)memory) - ((unsigned long)p) != size )
+        return NULL;
+

Hvmloader doesn't complain, i.e. I don't see error message printed out
in the construct_secondary_tables.

Anyway, if the above snippet is what you want, I can add it.

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 Dec 10 10:55:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10: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 1XyevX-0008FE-8n; Wed, 10 Dec 2014 10:55: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 1XyevW-0008F6-DW
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:55:26 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	55/72-02699-D9628845; Wed, 10 Dec 2014 10:55:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418208924!14147080!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15973 invoked from network); 10 Dec 2014 10:55:24 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 10:55:24 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XyevB-000II8-KA; Wed, 10 Dec 2014 10:55:05 +0000
Date: Wed, 10 Dec 2014 11:55:05 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141210105505.GA64596@deinos.phlegethon.org>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 01:14 +0000 on 10 Dec (1418170461), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:tim@xen.org]
> > Sent: Tuesday, December 09, 2014 6:47 PM
> > 
> > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > Hi all,
> > >
> > >    As you can see, we are pushing our XenGT patches to the upstream. One
> > > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > > device model.
> > >
> > >    Here we may have 2 similar solutions:
> > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was
> > no
> > > usage at that time.
> > 
> > It's been suggested before that we should revive this hypercall, and I
> > don't think it's a good idea.  Whenever a domain needs to know the
> > actual MFN of another domain's memory it's usually because the
> > security model is problematic.  In particular, finding the MFN is
> > usually followed by a brute-force mapping from a dom0 process, or by
> > passing the MFN to a device for unprotected DMA.
> 
> In our case it's not because the security model is problematic. It's 
> because GPU virtualization is done in Dom0 while the memory virtualization
> is done in hypervisor. We need a means to query GPFN->MFN so we can
> setup shadow GPU page table in Dom0 correctly, for a VM.

I don't think we understand each other.  Let me try to explain what I
mean.  My apologies if this sounds patronising; I'm just trying to be
as clear as I can.

It is Xen's job to isolate VMs from each other.  As part of that, Xen
uses the MMU, nested paging, and IOMMUs to control access to RAM.  Any
software component that can pass a raw MFN to hardware breaks that
isolation, because Xen has no way of controlling what that component
can do (including taking over the hypervisor).  This is why I am
afraid when developers ask for GFN->MFN translation functions.

So if the XenGT model allowed the backend component to (cause the GPU
to) perform arbitrary DMA without IOMMU checks, then that component
would have complete access to the system and (from a security pov)
might as well be running in the hypervisor.  That would be very
problematic, but AFAICT that's not what's going on.  From your reply
on the other thread it seems like the GPU is behind the IOMMU, so
that's OK. :)

When the backend component gets a GFN from the guest, it wants an
address that it can give to the GPU for DMA that will map the right
memory.  That address must be mapped in the IOMMU tables that the GPU
will be using, which means the IOMMU tables of the backend domain,
IIUC[1].  So the hypercall it needs is not "give me the MFN that matches
this GFN" but "please map this GFN into my IOMMU tables".

Asking for the MFN will only work if the backend domain's IOMMU
tables have an existing 1:1 r/w mapping of all guest RAM, which
happens to be the case if the backend component is in dom0 _and_ dom0
is PV _and_ we're not using strict IOMMU tables.  Restricting XenGT to
work in only those circumstances would be short-sighted, not only
because it would mean XenGT could never work as a driver domain, but
also because it seems like PVH dom0 is going to be the default at some
point.

If the existing hypercalls that make IOMMU mappings are not right for
XenGT then we can absolutely consider adding some more.  But we need
to talk about what policy Xen will enforce on the mapping requests.
If the shared backend is allowed to map any page of any VM, then it
can easily take control of any VM on the host (even though the IOMMU
will prevent it from taking over the hypervisor itself).  The
absolute minumum we should allow here is some toolstack-controlled
list of which VMs the XenGT backend is serving, so that it can refuse
to map other VMs' memory (like an extension of IS_PRIV_FOR, which does
this job for Qemu).

I would also strongly advise using privilege separation in the backend
between the GPUPT shadow code (which needs mapping rights and is
trusted to maintain isolation between the VMs that are sharing the
GPU) and the rest of the XenGT backend (which doesn't/isn't).  But
that's outside my remit as a hypervisor maintainer so it goes no
further than an "I told you so". :)

Cheers,

Tim.

[1] That is, AIUI this GPU doesn't context-switch which set of IOMMU
    tables it's using for DMA, SR-IOV-style, and that's why you need a
    software component in the first place.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 10:55:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 10: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 1XyevX-0008FE-8n; Wed, 10 Dec 2014 10:55: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 1XyevW-0008F6-DW
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 10:55:26 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	55/72-02699-D9628845; Wed, 10 Dec 2014 10:55:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418208924!14147080!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15973 invoked from network); 10 Dec 2014 10:55:24 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 10:55:24 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XyevB-000II8-KA; Wed, 10 Dec 2014 10:55:05 +0000
Date: Wed, 10 Dec 2014 11:55:05 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141210105505.GA64596@deinos.phlegethon.org>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 01:14 +0000 on 10 Dec (1418170461), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:tim@xen.org]
> > Sent: Tuesday, December 09, 2014 6:47 PM
> > 
> > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > Hi all,
> > >
> > >    As you can see, we are pushing our XenGT patches to the upstream. One
> > > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > > device model.
> > >
> > >    Here we may have 2 similar solutions:
> > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there was
> > no
> > > usage at that time.
> > 
> > It's been suggested before that we should revive this hypercall, and I
> > don't think it's a good idea.  Whenever a domain needs to know the
> > actual MFN of another domain's memory it's usually because the
> > security model is problematic.  In particular, finding the MFN is
> > usually followed by a brute-force mapping from a dom0 process, or by
> > passing the MFN to a device for unprotected DMA.
> 
> In our case it's not because the security model is problematic. It's 
> because GPU virtualization is done in Dom0 while the memory virtualization
> is done in hypervisor. We need a means to query GPFN->MFN so we can
> setup shadow GPU page table in Dom0 correctly, for a VM.

I don't think we understand each other.  Let me try to explain what I
mean.  My apologies if this sounds patronising; I'm just trying to be
as clear as I can.

It is Xen's job to isolate VMs from each other.  As part of that, Xen
uses the MMU, nested paging, and IOMMUs to control access to RAM.  Any
software component that can pass a raw MFN to hardware breaks that
isolation, because Xen has no way of controlling what that component
can do (including taking over the hypervisor).  This is why I am
afraid when developers ask for GFN->MFN translation functions.

So if the XenGT model allowed the backend component to (cause the GPU
to) perform arbitrary DMA without IOMMU checks, then that component
would have complete access to the system and (from a security pov)
might as well be running in the hypervisor.  That would be very
problematic, but AFAICT that's not what's going on.  From your reply
on the other thread it seems like the GPU is behind the IOMMU, so
that's OK. :)

When the backend component gets a GFN from the guest, it wants an
address that it can give to the GPU for DMA that will map the right
memory.  That address must be mapped in the IOMMU tables that the GPU
will be using, which means the IOMMU tables of the backend domain,
IIUC[1].  So the hypercall it needs is not "give me the MFN that matches
this GFN" but "please map this GFN into my IOMMU tables".

Asking for the MFN will only work if the backend domain's IOMMU
tables have an existing 1:1 r/w mapping of all guest RAM, which
happens to be the case if the backend component is in dom0 _and_ dom0
is PV _and_ we're not using strict IOMMU tables.  Restricting XenGT to
work in only those circumstances would be short-sighted, not only
because it would mean XenGT could never work as a driver domain, but
also because it seems like PVH dom0 is going to be the default at some
point.

If the existing hypercalls that make IOMMU mappings are not right for
XenGT then we can absolutely consider adding some more.  But we need
to talk about what policy Xen will enforce on the mapping requests.
If the shared backend is allowed to map any page of any VM, then it
can easily take control of any VM on the host (even though the IOMMU
will prevent it from taking over the hypervisor itself).  The
absolute minumum we should allow here is some toolstack-controlled
list of which VMs the XenGT backend is serving, so that it can refuse
to map other VMs' memory (like an extension of IS_PRIV_FOR, which does
this job for Qemu).

I would also strongly advise using privilege separation in the backend
between the GPUPT shadow code (which needs mapping rights and is
trusted to maintain isolation between the VMs that are sharing the
GPU) and the rest of the XenGT backend (which doesn't/isn't).  But
that's outside my remit as a hypervisor maintainer so it goes no
further than an "I told you so". :)

Cheers,

Tim.

[1] That is, AIUI this GPU doesn't context-switch which set of IOMMU
    tables it's using for DMA, SR-IOV-style, and that's why you need a
    software component in the first place.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 11:06:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 11: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 1Xyf5g-0000Lh-De; Wed, 10 Dec 2014 11:05:56 +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 1Xyf5e-0000Lc-ID
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 11:05:54 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	E6/5B-23865-11928845; Wed, 10 Dec 2014 11:05:53 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418209551!9873244!1
X-Originating-IP: [66.165.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 6783 invoked from network); 10 Dec 2014 11:05: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;
	10 Dec 2014 11:05:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202766038"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 06:04:35 -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 1Xyf4N-0004sq-Cm	for
	xen-devel@lists.xen.org; Wed, 10 Dec 2014 11:04:35 +0000
Message-ID: <548828C3.2020804@citrix.com>
Date: Wed, 10 Dec 2014 11:04:35 +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: <5486CAAF.9070807@linux.intel.com>	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>	<5486D0DD.1000902@linux.intel.com>	<5486E1EA020000780004E108@mail.emea.novell.com>	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>	<548814C2020000780004E6F9@mail.emea.novell.com>	<AADFC41AFE54684AB9EE6CBC0274A5D126115303@SHSMSX101.ccr.corp.intel.com>	<54881D8A020000780004E73E@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611542D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611542D@SHSMSX101.ccr.corp.intel.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/12/14 09:51, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Wednesday, December 10, 2014 5:17 PM
>>
>>>>> On 10.12.14 at 09:47, <kevin.tian@intel.com> wrote:
>>> two translation paths in assigned case:
>>>
>>> 1. [direct CPU access from VM], with partitioned PCI aperture
>>> resource, every VM can access a portion of PCI aperture directly.
>>>
>>> - CPU page table/EPT: CPU virtual address->PCI aperture
>>> - PCI aperture - bar base = Graphics Memory Address (GMA)
>>> - GPU page table: GMA -> GPA (as programmed by guest)
>>> - IOMMU: GPA -> MPA
>>>
>>> 2. [GPU access through GPU command operands], with GPU scheduling,
>>> every VM's command buffer will be fetched by GPU in a time-shared
>>> manner.
>>>
>>> - GPU page table: GMA->GPA
>>> - IOMMU: GPA->MPA
>>>
>>> In our case, IOMMU is setup with 1:1 identity table for dom0. So
>>> when GPU may access GPAs from different VMs, we can't count on
>>> IOMMU which can only serve one mapping for one device (unless
>>> we have SR-IOV).
>>>
>>> That's why we need shadow GPU page table in dom0, and need a
>>> p2m query call to translate from GPA -> MPA:
>>>
>>> - shadow GPU page table: GMA->MPA
>>> - IOMMU: MPA->MPA (for dom0)
>>
>> I still can't see why the Dom0 translation has to remain 1:1, i.e.
>> why Xen couldn't return some "arbitrary" GPA for the query in
>> question here, setting up a suitable GPA->MPA translation. (I put
>> arbitrary in quotes because this of course must not conflict with
>> GPAs already or possibly in use by Dom0.) And I can only stress
>> again that you shouldn't leave out PVH (where the IOMMU already
>> isn't set up with all 1:1 mappings) from these considerations.
>>
> 
> It's interesting that you think IOMMU can be used in such situation.
> 
> what do you mean by "arbitrary" GPA here? and It's not just about 
> conflicting with Dom0's GPA, it's about confliction in all VM's GPAs 
> when you hosting them through one IOMMU page table, and there's 
> no way to prevent this definitely since GPAs are picked by VMs 
> themselves.
> 
> I don't think we can support PVH here if IOMMU is not 1:1 mapping.
> 

I agree with Jan, there doesn't need to be a fixed 1:1 mapping between
IOMMU and MFN's addresses.

I think all that's required is that there is an IOMMU mapping for the
GPU device connected to dom0 (or driver domain) which allows guest
memory to be accessed by the GPU. This IOMMU address is what is
programmed into shadow GPU page table, I refer to this address as Bus
frame number(BFN) in the PV IOMMU design document.

- shadow GPU page table: GMA->BFN
- IOMMU: BFN->MPA


IOMMU's can almost always address more than the host physical RAM so we
can create IOMMU mappings above the top of host physical RAM in order to
have IOMMU mappings of guest RAM.

The PV-IOMMU design allows the guest to have control of the IOMMU
address space. In theory it could be extended to have permission checks
for mapping guest MFN's and have a mapping interface which takes a domid
and a GMFN. That way the driver domain does not need to know the actual
MFN's being used.

The guest itself (CPU) accesses the GPU via outbound MMIO mappings so we
don't need to be concerned with address translation in that direction.

I think getting Xen to allocate IOMMU mappings for a driver domain will
be problematic for PV based driver domains because the M2P for PV
domains is not kept strictly upto date with what the guest is using for
P2M and so it will be difficult/impossible to determine which addresses
are not in use.

Similarly it may be difficult to HVM guests because P2M mapping are
outbound (CPU to rest of host) and determining what addresses are
suitable for inbound access (rest of host to memory) may be difficult.
I.E should MMIO outbound address space be used for inbound IOMMU mappings?

I hope I've not caused more confusion.

Malcolm

> Thanks
> Kevin
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 10 11:06:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 11: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 1Xyf5g-0000Lh-De; Wed, 10 Dec 2014 11:05:56 +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 1Xyf5e-0000Lc-ID
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 11:05:54 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	E6/5B-23865-11928845; Wed, 10 Dec 2014 11:05:53 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418209551!9873244!1
X-Originating-IP: [66.165.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 6783 invoked from network); 10 Dec 2014 11:05: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;
	10 Dec 2014 11:05:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202766038"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 06:04:35 -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 1Xyf4N-0004sq-Cm	for
	xen-devel@lists.xen.org; Wed, 10 Dec 2014 11:04:35 +0000
Message-ID: <548828C3.2020804@citrix.com>
Date: Wed, 10 Dec 2014 11:04:35 +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: <5486CAAF.9070807@linux.intel.com>	<9AAE0902D5BC7E449B7C8E4E778ABCD02578573A@AMSPEX01CL01.citrite.net>	<5486D0DD.1000902@linux.intel.com>	<5486E1EA020000780004E108@mail.emea.novell.com>	<AADFC41AFE54684AB9EE6CBC0274A5D126114C7D@SHSMSX101.ccr.corp.intel.com>	<548814C2020000780004E6F9@mail.emea.novell.com>	<AADFC41AFE54684AB9EE6CBC0274A5D126115303@SHSMSX101.ccr.corp.intel.com>	<54881D8A020000780004E73E@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611542D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611542D@SHSMSX101.ccr.corp.intel.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/12/14 09:51, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Wednesday, December 10, 2014 5:17 PM
>>
>>>>> On 10.12.14 at 09:47, <kevin.tian@intel.com> wrote:
>>> two translation paths in assigned case:
>>>
>>> 1. [direct CPU access from VM], with partitioned PCI aperture
>>> resource, every VM can access a portion of PCI aperture directly.
>>>
>>> - CPU page table/EPT: CPU virtual address->PCI aperture
>>> - PCI aperture - bar base = Graphics Memory Address (GMA)
>>> - GPU page table: GMA -> GPA (as programmed by guest)
>>> - IOMMU: GPA -> MPA
>>>
>>> 2. [GPU access through GPU command operands], with GPU scheduling,
>>> every VM's command buffer will be fetched by GPU in a time-shared
>>> manner.
>>>
>>> - GPU page table: GMA->GPA
>>> - IOMMU: GPA->MPA
>>>
>>> In our case, IOMMU is setup with 1:1 identity table for dom0. So
>>> when GPU may access GPAs from different VMs, we can't count on
>>> IOMMU which can only serve one mapping for one device (unless
>>> we have SR-IOV).
>>>
>>> That's why we need shadow GPU page table in dom0, and need a
>>> p2m query call to translate from GPA -> MPA:
>>>
>>> - shadow GPU page table: GMA->MPA
>>> - IOMMU: MPA->MPA (for dom0)
>>
>> I still can't see why the Dom0 translation has to remain 1:1, i.e.
>> why Xen couldn't return some "arbitrary" GPA for the query in
>> question here, setting up a suitable GPA->MPA translation. (I put
>> arbitrary in quotes because this of course must not conflict with
>> GPAs already or possibly in use by Dom0.) And I can only stress
>> again that you shouldn't leave out PVH (where the IOMMU already
>> isn't set up with all 1:1 mappings) from these considerations.
>>
> 
> It's interesting that you think IOMMU can be used in such situation.
> 
> what do you mean by "arbitrary" GPA here? and It's not just about 
> conflicting with Dom0's GPA, it's about confliction in all VM's GPAs 
> when you hosting them through one IOMMU page table, and there's 
> no way to prevent this definitely since GPAs are picked by VMs 
> themselves.
> 
> I don't think we can support PVH here if IOMMU is not 1:1 mapping.
> 

I agree with Jan, there doesn't need to be a fixed 1:1 mapping between
IOMMU and MFN's addresses.

I think all that's required is that there is an IOMMU mapping for the
GPU device connected to dom0 (or driver domain) which allows guest
memory to be accessed by the GPU. This IOMMU address is what is
programmed into shadow GPU page table, I refer to this address as Bus
frame number(BFN) in the PV IOMMU design document.

- shadow GPU page table: GMA->BFN
- IOMMU: BFN->MPA


IOMMU's can almost always address more than the host physical RAM so we
can create IOMMU mappings above the top of host physical RAM in order to
have IOMMU mappings of guest RAM.

The PV-IOMMU design allows the guest to have control of the IOMMU
address space. In theory it could be extended to have permission checks
for mapping guest MFN's and have a mapping interface which takes a domid
and a GMFN. That way the driver domain does not need to know the actual
MFN's being used.

The guest itself (CPU) accesses the GPU via outbound MMIO mappings so we
don't need to be concerned with address translation in that direction.

I think getting Xen to allocate IOMMU mappings for a driver domain will
be problematic for PV based driver domains because the M2P for PV
domains is not kept strictly upto date with what the guest is using for
P2M and so it will be difficult/impossible to determine which addresses
are not in use.

Similarly it may be difficult to HVM guests because P2M mapping are
outbound (CPU to rest of host) and determining what addresses are
suitable for inbound access (rest of host to memory) may be difficult.
I.E should MMIO outbound address space be used for inbound IOMMU mappings?

I hope I've not caused more confusion.

Malcolm

> Thanks
> Kevin
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 10 11:06:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 11:06:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyf69-0000O4-QP; Wed, 10 Dec 2014 11:06: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 1Xyf68-0000Nq-DV
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 11:06:24 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	21/26-09284-F2928845; Wed, 10 Dec 2014 11:06:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418209583!12314998!1
X-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 24401 invoked from network); 10 Dec 2014 11:06:23 -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; 10 Dec 2014 11:06:23 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 11:06:22 +0000
Message-Id: <5488373C020000780004E836@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 11:06:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
	<54873724020000780004E37B@mail.emea.novell.com>
	<20141209180657.GG25749@zion.uk.xensource.com>
	<54881066020000780004E6D6@mail.emea.novell.com>
	<20141210105449.GA15588@zion.uk.xensource.com>
In-Reply-To: <20141210105449.GA15588@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 13/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 10.12.14 at 11:54, <wei.liu2@citrix.com> wrote:
> On Wed, Dec 10, 2014 at 08:20:38AM +0000, Jan Beulich wrote:
>> >>> On 09.12.14 at 19:06, <wei.liu2@citrix.com> wrote:
>> > On Tue, Dec 09, 2014 at 04:53:40PM +0000, Jan Beulich wrote:
>> >> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
>> >> > +        memset(memory, 0, sizeof(*memory));
>> >> > +        memory->type          = ACPI_MEMORY_AFFINITY;
>> >> > +        memory->length        = sizeof(*memory);
>> >> > +        memory->domain        = vmemrange[i].nid;
>> >> > +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
>> >> > +        memory->base_address  = vmemrange[i].start;
>> >> > +        memory->mem_length    = mem;
>> >> > +        memory++;
>> >> > +    }
>> >> > +
>> >> > +    srat->header.length = size;
>> >> 
>> >> Mind checking size == memory - p here?
>> >> 
>> > 
>> > Why? There doesn't seem to be anything that would cause memory -p !=
>> > size in between during runtime.
>> 
>> Except for that original calculation being wrong - that's what I would
>> mean such a check to verify.
>> 
> 
> Do you mean the code is wrong? I don't think so.

No, the code looks right. It's just that two disconnected
calculations easily get out of sync when someone later changes
them.

> Even if I have 
> 
> +    if ( ((unsigned long)memory) - ((unsigned long)p) != size )
> +        return NULL;
> +
> 
> Hvmloader doesn't complain, i.e. I don't see error message printed out
> in the construct_secondary_tables.
> 
> Anyway, if the above snippet is what you want, I can add it.

I was actually more after a BUG_ON() / ASSERT() kind of thing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 11:06:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 11:06:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyf69-0000O4-QP; Wed, 10 Dec 2014 11:06: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 1Xyf68-0000Nq-DV
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 11:06:24 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	21/26-09284-F2928845; Wed, 10 Dec 2014 11:06:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418209583!12314998!1
X-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 24401 invoked from network); 10 Dec 2014 11:06:23 -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; 10 Dec 2014 11:06:23 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 11:06:22 +0000
Message-Id: <5488373C020000780004E836@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 11:06:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
	<54873724020000780004E37B@mail.emea.novell.com>
	<20141209180657.GG25749@zion.uk.xensource.com>
	<54881066020000780004E6D6@mail.emea.novell.com>
	<20141210105449.GA15588@zion.uk.xensource.com>
In-Reply-To: <20141210105449.GA15588@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 13/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 10.12.14 at 11:54, <wei.liu2@citrix.com> wrote:
> On Wed, Dec 10, 2014 at 08:20:38AM +0000, Jan Beulich wrote:
>> >>> On 09.12.14 at 19:06, <wei.liu2@citrix.com> wrote:
>> > On Tue, Dec 09, 2014 at 04:53:40PM +0000, Jan Beulich wrote:
>> >> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
>> >> > +        memset(memory, 0, sizeof(*memory));
>> >> > +        memory->type          = ACPI_MEMORY_AFFINITY;
>> >> > +        memory->length        = sizeof(*memory);
>> >> > +        memory->domain        = vmemrange[i].nid;
>> >> > +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
>> >> > +        memory->base_address  = vmemrange[i].start;
>> >> > +        memory->mem_length    = mem;
>> >> > +        memory++;
>> >> > +    }
>> >> > +
>> >> > +    srat->header.length = size;
>> >> 
>> >> Mind checking size == memory - p here?
>> >> 
>> > 
>> > Why? There doesn't seem to be anything that would cause memory -p !=
>> > size in between during runtime.
>> 
>> Except for that original calculation being wrong - that's what I would
>> mean such a check to verify.
>> 
> 
> Do you mean the code is wrong? I don't think so.

No, the code looks right. It's just that two disconnected
calculations easily get out of sync when someone later changes
them.

> Even if I have 
> 
> +    if ( ((unsigned long)memory) - ((unsigned long)p) != size )
> +        return NULL;
> +
> 
> Hvmloader doesn't complain, i.e. I don't see error message printed out
> in the construct_secondary_tables.
> 
> Anyway, if the above snippet is what you want, I can add it.

I was actually more after a BUG_ON() / ASSERT() kind of thing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 11:10:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 11:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyf9z-0000eL-KX; Wed, 10 Dec 2014 11:10: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 1Xyf9y-0000eG-Au
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 11:10:22 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	25/72-02699-D1A28845; Wed, 10 Dec 2014 11:10:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418209819!14061935!1
X-Originating-IP: [66.165.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 22520 invoked from network); 10 Dec 2014 11:10:20 -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 Dec 2014 11:10:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202767523"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 06:10: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 1Xyf9u-0004zZ-ED;
	Wed, 10 Dec 2014 11:10:18 +0000
Date: Wed, 10 Dec 2014 11:10:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141210111018.GB15588@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
	<54873724020000780004E37B@mail.emea.novell.com>
	<20141209180657.GG25749@zion.uk.xensource.com>
	<54881066020000780004E6D6@mail.emea.novell.com>
	<20141210105449.GA15588@zion.uk.xensource.com>
	<5488373C020000780004E836@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5488373C020000780004E836@mail.emea.novell.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@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 13/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 Wed, Dec 10, 2014 at 11:06:20AM +0000, Jan Beulich wrote:
> >>> On 10.12.14 at 11:54, <wei.liu2@citrix.com> wrote:
> > On Wed, Dec 10, 2014 at 08:20:38AM +0000, Jan Beulich wrote:
> >> >>> On 09.12.14 at 19:06, <wei.liu2@citrix.com> wrote:
> >> > On Tue, Dec 09, 2014 at 04:53:40PM +0000, Jan Beulich wrote:
> >> >> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> >> >> > +        memset(memory, 0, sizeof(*memory));
> >> >> > +        memory->type          = ACPI_MEMORY_AFFINITY;
> >> >> > +        memory->length        = sizeof(*memory);
> >> >> > +        memory->domain        = vmemrange[i].nid;
> >> >> > +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
> >> >> > +        memory->base_address  = vmemrange[i].start;
> >> >> > +        memory->mem_length    = mem;
> >> >> > +        memory++;
> >> >> > +    }
> >> >> > +
> >> >> > +    srat->header.length = size;
> >> >> 
> >> >> Mind checking size == memory - p here?
> >> >> 
> >> > 
> >> > Why? There doesn't seem to be anything that would cause memory -p !=
> >> > size in between during runtime.
> >> 
> >> Except for that original calculation being wrong - that's what I would
> >> mean such a check to verify.
> >> 
> > 
> > Do you mean the code is wrong? I don't think so.
> 
> No, the code looks right. It's just that two disconnected
> calculations easily get out of sync when someone later changes
> them.
> 

I see.

> > Even if I have 
> > 
> > +    if ( ((unsigned long)memory) - ((unsigned long)p) != size )
> > +        return NULL;
> > +
> > 
> > Hvmloader doesn't complain, i.e. I don't see error message printed out
> > in the construct_secondary_tables.
> > 
> > Anyway, if the above snippet is what you want, I can add it.
> 
> I was actually more after a BUG_ON() / ASSERT() kind of thing.

Ack.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 11:10:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 11:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyf9z-0000eL-KX; Wed, 10 Dec 2014 11:10: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 1Xyf9y-0000eG-Au
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 11:10:22 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	25/72-02699-D1A28845; Wed, 10 Dec 2014 11:10:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418209819!14061935!1
X-Originating-IP: [66.165.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 22520 invoked from network); 10 Dec 2014 11:10:20 -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 Dec 2014 11:10:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202767523"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 06:10: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 1Xyf9u-0004zZ-ED;
	Wed, 10 Dec 2014 11:10:18 +0000
Date: Wed, 10 Dec 2014 11:10:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141210111018.GB15588@zion.uk.xensource.com>
References: <1417448023-27311-1-git-send-email-wei.liu2@citrix.com>
	<1417448023-27311-14-git-send-email-wei.liu2@citrix.com>
	<54873724020000780004E37B@mail.emea.novell.com>
	<20141209180657.GG25749@zion.uk.xensource.com>
	<54881066020000780004E6D6@mail.emea.novell.com>
	<20141210105449.GA15588@zion.uk.xensource.com>
	<5488373C020000780004E836@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5488373C020000780004E836@mail.emea.novell.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@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, ufimtseva@gmail.com, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH v2 13/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 Wed, Dec 10, 2014 at 11:06:20AM +0000, Jan Beulich wrote:
> >>> On 10.12.14 at 11:54, <wei.liu2@citrix.com> wrote:
> > On Wed, Dec 10, 2014 at 08:20:38AM +0000, Jan Beulich wrote:
> >> >>> On 09.12.14 at 19:06, <wei.liu2@citrix.com> wrote:
> >> > On Tue, Dec 09, 2014 at 04:53:40PM +0000, Jan Beulich wrote:
> >> >> >>> On 01.12.14 at 16:33, <wei.liu2@citrix.com> wrote:
> >> >> > +        memset(memory, 0, sizeof(*memory));
> >> >> > +        memory->type          = ACPI_MEMORY_AFFINITY;
> >> >> > +        memory->length        = sizeof(*memory);
> >> >> > +        memory->domain        = vmemrange[i].nid;
> >> >> > +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
> >> >> > +        memory->base_address  = vmemrange[i].start;
> >> >> > +        memory->mem_length    = mem;
> >> >> > +        memory++;
> >> >> > +    }
> >> >> > +
> >> >> > +    srat->header.length = size;
> >> >> 
> >> >> Mind checking size == memory - p here?
> >> >> 
> >> > 
> >> > Why? There doesn't seem to be anything that would cause memory -p !=
> >> > size in between during runtime.
> >> 
> >> Except for that original calculation being wrong - that's what I would
> >> mean such a check to verify.
> >> 
> > 
> > Do you mean the code is wrong? I don't think so.
> 
> No, the code looks right. It's just that two disconnected
> calculations easily get out of sync when someone later changes
> them.
> 

I see.

> > Even if I have 
> > 
> > +    if ( ((unsigned long)memory) - ((unsigned long)p) != size )
> > +        return NULL;
> > +
> > 
> > Hvmloader doesn't complain, i.e. I don't see error message printed out
> > in the construct_secondary_tables.
> > 
> > Anyway, if the above snippet is what you want, I can add it.
> 
> I was actually more after a BUG_ON() / ASSERT() kind of thing.

Ack.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 11:10:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 11: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 1XyfA8-0000fS-0I; Wed, 10 Dec 2014 11:10:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyfA6-0000fA-0e
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 11:10:30 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	88/AA-15461-52A28845; Wed, 10 Dec 2014 11:10:29 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418209825!14662791!1
X-Originating-IP: [66.165.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 6924 invoked from network); 10 Dec 2014 11:10:26 -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 Dec 2014 11:10:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202767547"
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.210.2; Wed, 10 Dec 2014 06:10: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 1XyfA0-0007bp-2e;
	Wed, 10 Dec 2014 11:10:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xyf9z-0004zo-NJ;
	Wed, 10 Dec 2014 11:10:23 +0000
Date: Wed, 10 Dec 2014 11:10:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32164-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] 32164: 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 32164 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32164/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install            fail REGR. vs. 32095
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32095

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-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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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                  8029dc43f4b232968168ca5bbd0ef47589243140
baseline version:
 xen                  a39f202031d7f1d8d9e14b8c3d7d11c812db253e

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@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                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-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=8029dc43f4b232968168ca5bbd0ef47589243140
+ . 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 8029dc43f4b232968168ca5bbd0ef47589243140
+ branch=xen-4.4-testing
+ revision=8029dc43f4b232968168ca5bbd0ef47589243140
+ . 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 8029dc43f4b232968168ca5bbd0ef47589243140:stable-4.4
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   a39f202..8029dc4  8029dc43f4b232968168ca5bbd0ef47589243140 -> 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 Dec 10 11:10:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 11: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 1XyfA8-0000fS-0I; Wed, 10 Dec 2014 11:10:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyfA6-0000fA-0e
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 11:10:30 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	88/AA-15461-52A28845; Wed, 10 Dec 2014 11:10:29 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418209825!14662791!1
X-Originating-IP: [66.165.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 6924 invoked from network); 10 Dec 2014 11:10:26 -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 Dec 2014 11:10:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202767547"
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.210.2; Wed, 10 Dec 2014 06:10: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 1XyfA0-0007bp-2e;
	Wed, 10 Dec 2014 11:10:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xyf9z-0004zo-NJ;
	Wed, 10 Dec 2014 11:10:23 +0000
Date: Wed, 10 Dec 2014 11:10:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32164-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] 32164: 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 32164 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32164/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install            fail REGR. vs. 32095
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32095

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-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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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                  8029dc43f4b232968168ca5bbd0ef47589243140
baseline version:
 xen                  a39f202031d7f1d8d9e14b8c3d7d11c812db253e

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@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                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-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=8029dc43f4b232968168ca5bbd0ef47589243140
+ . 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 8029dc43f4b232968168ca5bbd0ef47589243140
+ branch=xen-4.4-testing
+ revision=8029dc43f4b232968168ca5bbd0ef47589243140
+ . 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 8029dc43f4b232968168ca5bbd0ef47589243140:stable-4.4
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   a39f202..8029dc4  8029dc43f4b232968168ca5bbd0ef47589243140 -> 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 Dec 10 11:12:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 11:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyfC7-0000uP-Mk; Wed, 10 Dec 2014 11:12:35 +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 1XyfC7-0000uJ-5K
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 11:12:35 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	69/F5-02953-2AA28845; Wed, 10 Dec 2014 11:12:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418209953!10815416!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 1783 invoked from network); 10 Dec 2014 11:12:33 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 11:12:33 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XyfBl-000Ib5-PQ; Wed, 10 Dec 2014 11:12:13 +0000
Date: Wed, 10 Dec 2014 12:12:13 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141210111213.GB64596@deinos.phlegethon.org>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.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@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Kevin,

Thanks for taking the time to work through this.

At 03:39 +0000 on 10 Dec (1418179184), Tian, Kevin wrote:
> 1. It's more efficient for new people to start from a small, well-defined task
> in one area, and then spanning to adjacent areas gradually. Patience must 
> be given by the community to help them grow;
> 
> 2. Unfortunately this RMRR effort grows from original two patches (very VT-d
> focused) to now v8 17 patches spanning many areas (including hypercall, mmu, 
> domain builder, hvmloader, etc.), and thus imposing both long learning curve
> and lots of frustrations being no achievement returned. Though having a complete
> solution is desired, we need to help split the big task into step-by-step approach 
> as long as:
> 	- the overall design is agreed
> 	- each step is self-contained 
> 	- each step won't be wasted moving forward. 
> That way new people can see incremental achievements, instead of being hit 
> down before final success. 
> 
> Take this RMRR for example. Maybe we can split into steps like:
> 
> 	step-1: setup RMRR identify mapping in hypervisor. fail if confliction. no
> user space changes
> 	step-2: expose RMRR knowledge to userspace and detect confliction in
> domain builder and hvmloader
> 	step-3: reconcile e820/mmio to avoid confliction in a best effort
> 	step-4: miscellaneous enhancements, each can be ACK-ed individually:
> 		- handle guest CPU access to RMRR regions
> 		- handle conflicting RMRR regions
> 		- handle group RMRRs
> 		- re-enable USB device assignment
> 
> That way Tiejun can focus on a self-contained task at one time, and then observe
> continuous acknowledgements for his work. We don't need to claim RMRR fully
> ready in Xen until last patch is accepted, but that at least provides a way to ack
> new people when working on complex features and also allow for partial usage 
> on his work.

We had this discussion before and I think it was clear that the
maintainers in general are unhappy with a partial solution.  OTOH, if
we can agree on the roadmap, and Intel will commit to seeing the work
through, it might be possible.  I think Jan is the man to convince
here. :)

Now since the code's not going to be in 4.5 anyway, it should be
possible to _develop_ it in this manner, possibly in a private branch,
even if the early stages aren't getting applied immediately.  We
should be able to set up an rmrr branch on the public servers if that
helps.  But again, that relies on having a design worked out in
advance that both developers and maintainers are (within reason)
committed to.

> 3. Maintainers sometimes didn't give definitive guidance to the new people, 
> and the high-level design is not closed in the 1st place. e.g. when I thought this v8
> version has everyone agreed on the design, there's another comment from Jan
> about using XENMEM_set_memory_map might be better, while back to Aug.
> when Tiejun raised that option the answer is "I'm not sure". Note I understand
> as a maintainer he might not have definite answers for all opens. But w/o a
> definitive guide new people may waste lots of effort on chasing a wrong option,
> which is definitely frustrating. 

This is definitely a problem, and indeed frustrating for the
developers.  We had similar difficulties with PVH development, where
even though we planned the architecture up-front, once the code was
written it became clear that a different approach would have been
better.  I'm not sure what we can do here to make it more likely that
we get the design right first time.

I do think that figuring out the design in advance makes these
projects much smoother, and it's something we're seeing more of.  For
example David Vrabel's designs for the new event channel interface, or
indeed the design doc he wrote about grant table locking, where review
at the design stage may have avoided a bunch of implementation effort
altogether.

> So I'd suggest for such non-trivial task for a new people, all maintainers in 
> involved areas (xen, mmu, tools, vtd, etc) should first spend time to agree 
> on the high level design. At that stage, let's skip the coding problems to save
> both time.

That sounds like a very good idea to me.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 11:12:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 11:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyfC7-0000uP-Mk; Wed, 10 Dec 2014 11:12:35 +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 1XyfC7-0000uJ-5K
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 11:12:35 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	69/F5-02953-2AA28845; Wed, 10 Dec 2014 11:12:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418209953!10815416!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 1783 invoked from network); 10 Dec 2014 11:12:33 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 11:12:33 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XyfBl-000Ib5-PQ; Wed, 10 Dec 2014 11:12:13 +0000
Date: Wed, 10 Dec 2014 12:12:13 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141210111213.GB64596@deinos.phlegethon.org>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.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@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Kevin,

Thanks for taking the time to work through this.

At 03:39 +0000 on 10 Dec (1418179184), Tian, Kevin wrote:
> 1. It's more efficient for new people to start from a small, well-defined task
> in one area, and then spanning to adjacent areas gradually. Patience must 
> be given by the community to help them grow;
> 
> 2. Unfortunately this RMRR effort grows from original two patches (very VT-d
> focused) to now v8 17 patches spanning many areas (including hypercall, mmu, 
> domain builder, hvmloader, etc.), and thus imposing both long learning curve
> and lots of frustrations being no achievement returned. Though having a complete
> solution is desired, we need to help split the big task into step-by-step approach 
> as long as:
> 	- the overall design is agreed
> 	- each step is self-contained 
> 	- each step won't be wasted moving forward. 
> That way new people can see incremental achievements, instead of being hit 
> down before final success. 
> 
> Take this RMRR for example. Maybe we can split into steps like:
> 
> 	step-1: setup RMRR identify mapping in hypervisor. fail if confliction. no
> user space changes
> 	step-2: expose RMRR knowledge to userspace and detect confliction in
> domain builder and hvmloader
> 	step-3: reconcile e820/mmio to avoid confliction in a best effort
> 	step-4: miscellaneous enhancements, each can be ACK-ed individually:
> 		- handle guest CPU access to RMRR regions
> 		- handle conflicting RMRR regions
> 		- handle group RMRRs
> 		- re-enable USB device assignment
> 
> That way Tiejun can focus on a self-contained task at one time, and then observe
> continuous acknowledgements for his work. We don't need to claim RMRR fully
> ready in Xen until last patch is accepted, but that at least provides a way to ack
> new people when working on complex features and also allow for partial usage 
> on his work.

We had this discussion before and I think it was clear that the
maintainers in general are unhappy with a partial solution.  OTOH, if
we can agree on the roadmap, and Intel will commit to seeing the work
through, it might be possible.  I think Jan is the man to convince
here. :)

Now since the code's not going to be in 4.5 anyway, it should be
possible to _develop_ it in this manner, possibly in a private branch,
even if the early stages aren't getting applied immediately.  We
should be able to set up an rmrr branch on the public servers if that
helps.  But again, that relies on having a design worked out in
advance that both developers and maintainers are (within reason)
committed to.

> 3. Maintainers sometimes didn't give definitive guidance to the new people, 
> and the high-level design is not closed in the 1st place. e.g. when I thought this v8
> version has everyone agreed on the design, there's another comment from Jan
> about using XENMEM_set_memory_map might be better, while back to Aug.
> when Tiejun raised that option the answer is "I'm not sure". Note I understand
> as a maintainer he might not have definite answers for all opens. But w/o a
> definitive guide new people may waste lots of effort on chasing a wrong option,
> which is definitely frustrating. 

This is definitely a problem, and indeed frustrating for the
developers.  We had similar difficulties with PVH development, where
even though we planned the architecture up-front, once the code was
written it became clear that a different approach would have been
better.  I'm not sure what we can do here to make it more likely that
we get the design right first time.

I do think that figuring out the design in advance makes these
projects much smoother, and it's something we're seeing more of.  For
example David Vrabel's designs for the new event channel interface, or
indeed the design doc he wrote about grant table locking, where review
at the design stage may have avoided a bunch of implementation effort
altogether.

> So I'd suggest for such non-trivial task for a new people, all maintainers in 
> involved areas (xen, mmu, tools, vtd, etc) should first spend time to agree 
> on the high level design. At that stage, let's skip the coding problems to save
> both time.

That sounds like a very good idea to me.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 12:15:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12: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 1XygAB-0003JR-JX; Wed, 10 Dec 2014 12:14:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XygA9-0003JM-TP
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 12:14:38 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	C8/09-18267-D2938845; Wed, 10 Dec 2014 12:14:37 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418213676!12338568!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 12249 invoked from network); 10 Dec 2014 12:14:36 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 12:14:36 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=QDdEsgHuAO+SjfgI1PMXTyJVZ3Ss+uSKNgoxUb/Nb2FAqIxSR4VtM01QzXOm1ntrQpCdgSLV82qXfyvAUUCrwXPaHoP6FnljokHflRIj1QhEFLccyzJXd8cODHiCNf6qCgCEYd4I0l7e/5xau/frxaOums/7WcC7eDSVi1mLlfCJVEkmhz2iAF8/+6HNmBEkkpH2eOZcb/5d2UUecmBrAYAUuVC2MDJkogv+hGoA0LW8CbT4MWe+DQWEepW2OlvjHx9i69ok+ooFmBPM4jePAGHC6taivd5y/CMyHiKnW0SnW6CBU8zw+3UdSnKZ3JpKr3XrM1RvmdeNaz3EGODTQA==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:MIME-Version: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=from:to
	:cc:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=zzVTyyIUpWTPtQkdLSJOJK
	nE9UQ=; b=DpyF15y9jIT35xL9TEZquLC6K43/Hrh0r06/lC7gC72HEyodnDsUY9
	bS7Eh/AZGg3Y3D73+WeEQuwnoHcdRBg1QAOZDXR2tAMill2LzBZY0QLKOCkGbu6A
	ekNW78RCF7midf2ouhPwH5EXaCy/GPRc6bbNHItEzSvpFG/ybe0aF8wfT6Rb/hoQ
	A4BgGpwfeAcXeUViLIKvfceIEtHyw66//77xTGcEwPJ53B17aM+cYeKv+8lyihKr
	x2LWKkSZAaqO2SFntqgsBa92A2SnXOnXnrG/gvipznkMmmFLotwOkLdRmgdv1FuP
	uRRLy9i7WB36Ze8HJMOlaeaFwR3fztOg==
Received: (qmail 7685 invoked from network); 10 Dec 2014 14:14:35 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	10 Dec 2014 14:14:35 +0200
Received: from smtp01.buh.bitdefender.com (unknown [10.17.80.75])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 403B280414
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 14:14:35 +0200 (EET)
Received: (qmail 7121 invoked from network); 10 Dec 2014 14:14:35 +0200
Received: from unknown (HELO mdontu-l.dsd.bitdefender.biz)
	(mdontu@bitdefender.com@unknown)
	by unknown with SMTP; 10 Dec 2014 14:14:34 +0200
From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 14:13:58 +0200
Message-Id: <1418213638-14896-1-git-send-email-mdontu@bitdefender.com>
X-Mailer: git-send-email 2.2.0
MIME-Version: 1.0
Content-Length: 8815
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp01.buh.bitdefender.com, sigver: 7.58209
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374467,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; 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.1.2; Id: 2m1ghdn.198ps9lci.9hfd],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: [Xen-devel] [PATCH v3] xmalloc: add support for checking the pool
	integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SW1wbGVtZW50ZWQgeG1lbV9wb29sX2NoZWNrKCksIHhtZW1fcG9vbF9jaGVja19sb2NrZWQoKSBh
bmQKeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKCkgdG8gdmVyaXR5IHRoZSBpbnRlZ3JpdHkgb2Yg
dGhlIFRMU0YgbWF0cml4LgoKU2lnbmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0
ZGVmZW5kZXIuY29tPgoKLS0tCkNoYW5nZXMgc2luY2UgdjI6CiAtIHByaW50IHRoZSBuYW1lIG9m
IHRoZSBjb3JydXB0ZWQgcG9vbAogLSBhZGp1c3RlZCB0aGUgbWVzc2FnZXMgdG8gYmV0dGVyIGZp
dCB3aXRoaW4gODAgY29sdW1ucwogLSBtaW5vciBzdHlsZSBjaGFuZ2UgKGEgPyBhIDogYiAtPiBh
ID86IGIpCgpDaGFuZ2VzIHNpbmNlIHYxOgogLSBmaXhlZCB0aGUgY29kaW5nc3R5bGUKIC0gc3dh
cGVkIF9sb2NrZWQvX3VubG9ja2VkIG5hbWluZwogLSByZXdvcmtlZCBfX3htZW1fcG9vbF9jaGVj
a19sb2NrZWQoKSBhIGJpdAogLSB1c2VkIGJvb2xfdCB3aGVyZSBhcHByb3ByaWF0ZQogLSBtYWRl
IHhtZW1fcG9vbF9jaGVjaygpIHRha2UgYSBwb29sIGFyZ3VtZW50IHdoaWNoIGNhbiBiZSBOVUxM
Ci0tLQogeGVuL2NvbW1vbi94bWFsbG9jX3Rsc2YuYyB8IDExNyArKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKystCiB4ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oIHwg
ICA3ICsrKwogMiBmaWxlcyBjaGFuZ2VkLCAxMjIgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMo
LSkKCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jIGIveGVuL2NvbW1vbi94
bWFsbG9jX3Rsc2YuYwppbmRleCBhNTc2OWM5Li4xZGVhMTM3IDEwMDY0NAotLS0gYS94ZW4vY29t
bW9uL3htYWxsb2NfdGxzZi5jCisrKyBiL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMKQEAgLTEy
MCw5ICsxMjAsMTE4IEBAIHN0cnVjdCB4bWVtX3Bvb2wgewogICAgIGNoYXIgbmFtZVtNQVhfUE9P
TF9OQU1FX0xFTl07CiB9OwogCitzdGF0aWMgc3RydWN0IHhtZW1fcG9vbCAqeGVucG9vbDsKKwor
c3RhdGljIGlubGluZSB2b2lkIE1BUFBJTkdfSU5TRVJUKHVuc2lnbmVkIGxvbmcgciwgaW50ICpm
bCwgaW50ICpzbCk7CisKIC8qCiAgKiBIZWxwaW5nIGZ1bmN0aW9ucwogICovCisjaWZuZGVmIE5E
RUJVRworc3RhdGljIGJvb2xfdCB4bWVtX3Bvb2xfY2hlY2tfc2l6ZShjb25zdCBzdHJ1Y3QgeG1l
bV9wb29sICpwb29sLCBpbnQgZmwsIGludCBzbCkKK3sKKyAgICBjb25zdCBzdHJ1Y3QgYmhkciAq
YiA9IHBvb2wtPm1hdHJpeFtmbF1bc2xdOworCisgICAgd2hpbGUgKCBiICkKKyAgICB7CisgICAg
ICAgIGludCBfX2ZsOworICAgICAgICBpbnQgX19zbDsKKworICAgICAgICBNQVBQSU5HX0lOU0VS
VChiLT5zaXplLCAmX19mbCwgJl9fc2wpOworICAgICAgICBpZiAoIF9fZmwgIT0gZmwgfHwgX19z
bCAhPSBzbCApCisgICAgICAgIHsKKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSCisgICAg
ICAgICAgICAgICAgICAgInhtZW1fcG9vbDogJXM6IG1pc3BsYWNlZCBibG9jayAlcDoldSAoeyVk
LCVkfSAtPiB7JWQsJWR9KVxuIiwKKyAgICAgICAgICAgICAgICAgICBwb29sLT5uYW1lLCBiLCBi
LT5zaXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOworICAgICAgICAgICAgcmV0dXJuIDA7CisgICAg
ICAgIH0KKyAgICAgICAgYiA9IGItPnB0ci5mcmVlX3B0ci5uZXh0OworICAgIH0KKyAgICByZXR1
cm4gMTsKK30KKworLyoKKyAqIFRoaXMgZnVuY3Rpb24gbXVzdCBiZSBjYWxsZWQgZnJvbSBhIGNv
bnRleHQgd2hlcmUgcG9vbC0+bG9jayBpcworICogYWxyZWFkeSBhY3F1aXJlZC4KKyAqCisgKiBS
ZXR1cm5zIHRydWUgaWYgdGhlIHBvb2wgaGFzIGJlZW4gY29ycnVwdGVkLCBmYWxzZSBvdGhlcndp
c2UKKyAqLworI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpIF9feG1lbV9wb29s
X2NoZWNrX2xvY2tlZChfX0ZJTEVfXywgX19MSU5FX18sIHBvb2wpCitzdGF0aWMgYm9vbF90IF9f
eG1lbV9wb29sX2NoZWNrX2xvY2tlZChjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgY29uc3Qg
c3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKK3sKKyAgICBpbnQgaTsKKyAgICBzdGF0aWMgYm9vbF90
IG9uY2UgPSAxOworCisgICAgaWYgKCAhb25jZSApCisgICAgICAgIGdvdG8gb3V0OworICAgIGZv
ciAoIGkgPSAwOyBpIDwgUkVBTF9GTEk7IGkrKyApCisgICAgeworICAgICAgICBpbnQgZmwgPSAo
cG9vbC0+ZmxfYml0bWFwICYgKDEgPDwgaSkpID8gaSA6IC0xOworCisgICAgICAgIGlmICggZmwg
Pj0gMCApCisgICAgICAgIHsKKyAgICAgICAgICAgIGludCBqOworCisgICAgICAgICAgICBpZiAo
ICFwb29sLT5zbF9iaXRtYXBbZmxdICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICBw
cmludGsoWEVOTE9HX0VSUgorICAgICAgICAgICAgICAgICAgICAgICAieG1lbV9wb29sOiAlczog
dGhlIFRMU0YgYml0bWFwIGlzIGNvcnJ1cHRlZCAobm9uLWVtcHR5IEZMIHdpdGggZW1wdHkgU0wp
XG4iLAorICAgICAgICAgICAgICAgICAgICAgICBwb29sLT5uYW1lKTsKKyAgICAgICAgICAgICAg
ICBfX3dhcm4oZmlsZSwgbGluZSk7CisgICAgICAgICAgICAgICAgb25jZSA9IDA7CisgICAgICAg
ICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICB9CisgICAgICAgICAgICBmb3IgKCBqID0gMDsg
aiA8IE1BWF9TTEk7IGorKyApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgaW50IHNs
ID0gKHBvb2wtPnNsX2JpdG1hcFtmbF0gJiAoMSA8PCBqKSkgPyBqIDogLTE7CisKKyAgICAgICAg
ICAgICAgICBpZiAoIHNsIDwgMCApCisgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOworICAg
ICAgICAgICAgICAgIGlmICggIXBvb2wtPm1hdHJpeFtmbF1bc2xdICkKKyAgICAgICAgICAgICAg
ICB7CisgICAgICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAieG1lbV9wb29sOiAlczogdGhlIFRMU0YgYml0bWFwIGlzIGNvcnJ1cHRl
ZCAobWF0cml4WyVkXVslZF0gaXMgTlVMTClcbiIsCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICBwb29sLT5uYW1lLCBmbCwgc2wpOworICAgICAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwg
bGluZSk7CisgICAgICAgICAgICAgICAgICAgIG9uY2UgPSAwOworICAgICAgICAgICAgICAgICAg
ICBicmVhazsKKyAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgaWYgKCAheG1lbV9w
b29sX2NoZWNrX3NpemUocG9vbCwgZmwsIHNsKSApCisgICAgICAgICAgICAgICAgeworICAgICAg
ICAgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9wb29sOiAlczogdGhlIFRMU0Yg
Y2h1bmsgbWF0cml4IGlzIGNvcnJ1cHRlZFxuIiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
IHBvb2wtPm5hbWUpOworICAgICAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGluZSk7Cisg
ICAgICAgICAgICAgICAgICAgIG9uY2UgPSAwOworICAgICAgICAgICAgICAgICAgICBicmVhazsK
KyAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICB9CisgICAgICAgICAgICBpZiAoICFvbmNl
ICkKKyAgICAgICAgICAgICAgICBicmVhazsKKyAgICAgICAgfQorICAgIH0KK291dDoKKyAgICBy
ZXR1cm4gIW9uY2U7Cit9CisKKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKHBvb2wp
IF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKF9fRklMRV9fLCBfX0xJTkVfXywgcG9vbCkKK3N0
YXRpYyBib29sX3QgX194bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoY29uc3QgY2hhciAqZmlsZSwg
aW50IGxpbmUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCit7CisgICAgYm9vbF90IG9vcHM7CisK
KyAgICBzcGluX2xvY2soJnBvb2wtPmxvY2spOworICAgIG9vcHMgPSBfX3htZW1fcG9vbF9jaGVj
a19sb2NrZWQoZmlsZSwgbGluZSwgcG9vbCk7CisgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2sp
OworICAgIHJldHVybiBvb3BzOworfQorCitib29sX3QgX194bWVtX3Bvb2xfY2hlY2soY29uc3Qg
Y2hhciAqZmlsZSwgaW50IGxpbmUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCit7CisgICAgcmV0
dXJuIF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wgPzogeGVucG9v
bCk7Cit9CisjZWxzZQorI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpICgodm9p
ZCkocG9vbCkpCisjZGVmaW5lIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChwb29sKSAoKHZvaWQp
KHBvb2wpKQorI2VuZGlmCiAKIC8qKgogICogUmV0dXJucyBpbmRleGVzIChmbCwgc2wpIG9mIHRo
ZSBsaXN0IHVzZWQgdG8gc2VydmUgcmVxdWVzdCBvZiBzaXplIHIKQEAgLTM4MSw2ICs0OTAsOCBA
QCB2b2lkICp4bWVtX3Bvb2xfYWxsb2ModW5zaWduZWQgbG9uZyBzaXplLCBzdHJ1Y3QgeG1lbV9w
b29sICpwb29sKQogICAgIGludCBmbCwgc2w7CiAgICAgdW5zaWduZWQgbG9uZyB0bXBfc2l6ZTsK
IAorICAgIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChwb29sKTsKKwogICAgIGlmICggcG9vbC0+
aW5pdF9yZWdpb24gPT0gTlVMTCApCiAgICAgewogICAgICAgICBpZiAoIChyZWdpb24gPSBwb29s
LT5nZXRfbWVtKHBvb2wtPmluaXRfc2l6ZSkpID09IE5VTEwgKQpAQCAtNDQyLDExICs1NTMsMTMg
QEAgdm9pZCAqeG1lbV9wb29sX2FsbG9jKHVuc2lnbmVkIGxvbmcgc2l6ZSwgc3RydWN0IHhtZW1f
cG9vbCAqcG9vbCkKIAogICAgIHBvb2wtPnVzZWRfc2l6ZSArPSAoYi0+c2l6ZSAmIEJMT0NLX1NJ
WkVfTUFTSykgKyBCSERSX09WRVJIRUFEOwogCisgICAgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChw
b29sKTsKICAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7CiAgICAgcmV0dXJuICh2b2lkICop
Yi0+cHRyLmJ1ZmZlcjsKIAogICAgIC8qIEZhaWxlZCBhbGxvYyAqLwogIG91dF9sb2NrZWQ6Cisg
ICAgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKTsKICAgICBzcGluX3VubG9jaygmcG9vbC0+
bG9jayk7CiAKICBvdXQ6CkBAIC00NjQsNiArNTc3LDcgQEAgdm9pZCB4bWVtX3Bvb2xfZnJlZSh2
b2lkICpwdHIsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCiAgICAgYiA9IChzdHJ1Y3QgYmhkciAq
KSgoY2hhciAqKSBwdHIgLSBCSERSX09WRVJIRUFEKTsKIAogICAgIHNwaW5fbG9jaygmcG9vbC0+
bG9jayk7CisgICAgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKTsKICAgICBiLT5zaXplIHw9
IEZSRUVfQkxPQ0s7CiAgICAgcG9vbC0+dXNlZF9zaXplIC09IChiLT5zaXplICYgQkxPQ0tfU0la
RV9NQVNLKSArIEJIRFJfT1ZFUkhFQUQ7CiAgICAgYi0+cHRyLmZyZWVfcHRyID0gKHN0cnVjdCBm
cmVlX3B0cikgeyBOVUxMLCBOVUxMfTsKQEAgLTUwMCw2ICs2MTQsNyBAQCB2b2lkIHhtZW1fcG9v
bF9mcmVlKHZvaWQgKnB0ciwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKICAgICB0bXBfYi0+c2l6
ZSB8PSBQUkVWX0ZSRUU7CiAgICAgdG1wX2ItPnByZXZfaGRyID0gYjsKICBvdXQ6CisgICAgeG1l
bV9wb29sX2NoZWNrX2xvY2tlZChwb29sKTsKICAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7
CiB9CiAKQEAgLTUxMiw4ICs2MjcsNiBAQCBpbnQgeG1lbV9wb29sX21heGFsbG9jKHN0cnVjdCB4
bWVtX3Bvb2wgKnBvb2wpCiAgKiBHbHVlIGZvciB4bWFsbG9jKCkuCiAgKi8KIAotc3RhdGljIHN0
cnVjdCB4bWVtX3Bvb2wgKnhlbnBvb2w7Ci0KIHN0YXRpYyB2b2lkICp4bWFsbG9jX3Bvb2xfZ2V0
KHVuc2lnbmVkIGxvbmcgc2l6ZSkKIHsKICAgICBBU1NFUlQoc2l6ZSA9PSBQQUdFX1NJWkUpOwpk
aWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaCBiL3hlbi9pbmNsdWRlL3hlbi94
bWFsbG9jLmgKaW5kZXggMjRhOTlhYy4uYWQ0ODkzMCAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUv
eGVuL3htYWxsb2MuaAorKysgYi94ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCkBAIC0xMjMsNCAr
MTIzLDExIEBAIHVuc2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF91c2VkX3NpemUoc3RydWN0IHht
ZW1fcG9vbCAqcG9vbCk7CiAgKi8KIHVuc2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF90b3RhbF9z
aXplKHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpOwogCisjaWZuZGVmIE5ERUJVRworI2RlZmluZSB4
bWVtX3Bvb2xfY2hlY2socG9vbCkgX194bWVtX3Bvb2xfY2hlY2soX19GSUxFX18sIF9fTElORV9f
LCBwb29sKQorYm9vbF90IF9feG1lbV9wb29sX2NoZWNrKGNvbnN0IGNoYXIgKmZpbGUsIGludCBs
aW5lLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKTsKKyNlbHNlCisjZGVmaW5lIHhtZW1fcG9vbF9j
aGVjayhwb29sKSAoKHZvaWQpMCkKKyNlbmRpZgorCiAjZW5kaWYgLyogX19YTUFMTE9DX0hfXyAq
LwotLSAKMi4yLjAKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Dec 10 12:15:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12: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 1XygAB-0003JR-JX; Wed, 10 Dec 2014 12:14:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XygA9-0003JM-TP
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 12:14:38 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	C8/09-18267-D2938845; Wed, 10 Dec 2014 12:14:37 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418213676!12338568!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 12249 invoked from network); 10 Dec 2014 12:14:36 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 12:14:36 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=QDdEsgHuAO+SjfgI1PMXTyJVZ3Ss+uSKNgoxUb/Nb2FAqIxSR4VtM01QzXOm1ntrQpCdgSLV82qXfyvAUUCrwXPaHoP6FnljokHflRIj1QhEFLccyzJXd8cODHiCNf6qCgCEYd4I0l7e/5xau/frxaOums/7WcC7eDSVi1mLlfCJVEkmhz2iAF8/+6HNmBEkkpH2eOZcb/5d2UUecmBrAYAUuVC2MDJkogv+hGoA0LW8CbT4MWe+DQWEepW2OlvjHx9i69ok+ooFmBPM4jePAGHC6taivd5y/CMyHiKnW0SnW6CBU8zw+3UdSnKZ3JpKr3XrM1RvmdeNaz3EGODTQA==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:MIME-Version: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=from:to
	:cc:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=zzVTyyIUpWTPtQkdLSJOJK
	nE9UQ=; b=DpyF15y9jIT35xL9TEZquLC6K43/Hrh0r06/lC7gC72HEyodnDsUY9
	bS7Eh/AZGg3Y3D73+WeEQuwnoHcdRBg1QAOZDXR2tAMill2LzBZY0QLKOCkGbu6A
	ekNW78RCF7midf2ouhPwH5EXaCy/GPRc6bbNHItEzSvpFG/ybe0aF8wfT6Rb/hoQ
	A4BgGpwfeAcXeUViLIKvfceIEtHyw66//77xTGcEwPJ53B17aM+cYeKv+8lyihKr
	x2LWKkSZAaqO2SFntqgsBa92A2SnXOnXnrG/gvipznkMmmFLotwOkLdRmgdv1FuP
	uRRLy9i7WB36Ze8HJMOlaeaFwR3fztOg==
Received: (qmail 7685 invoked from network); 10 Dec 2014 14:14:35 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	10 Dec 2014 14:14:35 +0200
Received: from smtp01.buh.bitdefender.com (unknown [10.17.80.75])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 403B280414
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 14:14:35 +0200 (EET)
Received: (qmail 7121 invoked from network); 10 Dec 2014 14:14:35 +0200
Received: from unknown (HELO mdontu-l.dsd.bitdefender.biz)
	(mdontu@bitdefender.com@unknown)
	by unknown with SMTP; 10 Dec 2014 14:14:34 +0200
From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 14:13:58 +0200
Message-Id: <1418213638-14896-1-git-send-email-mdontu@bitdefender.com>
X-Mailer: git-send-email 2.2.0
MIME-Version: 1.0
Content-Length: 8815
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp01.buh.bitdefender.com, sigver: 7.58209
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374467,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; 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.1.2; Id: 2m1ghdn.198ps9lci.9hfd],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: [Xen-devel] [PATCH v3] xmalloc: add support for checking the pool
	integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SW1wbGVtZW50ZWQgeG1lbV9wb29sX2NoZWNrKCksIHhtZW1fcG9vbF9jaGVja19sb2NrZWQoKSBh
bmQKeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKCkgdG8gdmVyaXR5IHRoZSBpbnRlZ3JpdHkgb2Yg
dGhlIFRMU0YgbWF0cml4LgoKU2lnbmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0
ZGVmZW5kZXIuY29tPgoKLS0tCkNoYW5nZXMgc2luY2UgdjI6CiAtIHByaW50IHRoZSBuYW1lIG9m
IHRoZSBjb3JydXB0ZWQgcG9vbAogLSBhZGp1c3RlZCB0aGUgbWVzc2FnZXMgdG8gYmV0dGVyIGZp
dCB3aXRoaW4gODAgY29sdW1ucwogLSBtaW5vciBzdHlsZSBjaGFuZ2UgKGEgPyBhIDogYiAtPiBh
ID86IGIpCgpDaGFuZ2VzIHNpbmNlIHYxOgogLSBmaXhlZCB0aGUgY29kaW5nc3R5bGUKIC0gc3dh
cGVkIF9sb2NrZWQvX3VubG9ja2VkIG5hbWluZwogLSByZXdvcmtlZCBfX3htZW1fcG9vbF9jaGVj
a19sb2NrZWQoKSBhIGJpdAogLSB1c2VkIGJvb2xfdCB3aGVyZSBhcHByb3ByaWF0ZQogLSBtYWRl
IHhtZW1fcG9vbF9jaGVjaygpIHRha2UgYSBwb29sIGFyZ3VtZW50IHdoaWNoIGNhbiBiZSBOVUxM
Ci0tLQogeGVuL2NvbW1vbi94bWFsbG9jX3Rsc2YuYyB8IDExNyArKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKystCiB4ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oIHwg
ICA3ICsrKwogMiBmaWxlcyBjaGFuZ2VkLCAxMjIgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMo
LSkKCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jIGIveGVuL2NvbW1vbi94
bWFsbG9jX3Rsc2YuYwppbmRleCBhNTc2OWM5Li4xZGVhMTM3IDEwMDY0NAotLS0gYS94ZW4vY29t
bW9uL3htYWxsb2NfdGxzZi5jCisrKyBiL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMKQEAgLTEy
MCw5ICsxMjAsMTE4IEBAIHN0cnVjdCB4bWVtX3Bvb2wgewogICAgIGNoYXIgbmFtZVtNQVhfUE9P
TF9OQU1FX0xFTl07CiB9OwogCitzdGF0aWMgc3RydWN0IHhtZW1fcG9vbCAqeGVucG9vbDsKKwor
c3RhdGljIGlubGluZSB2b2lkIE1BUFBJTkdfSU5TRVJUKHVuc2lnbmVkIGxvbmcgciwgaW50ICpm
bCwgaW50ICpzbCk7CisKIC8qCiAgKiBIZWxwaW5nIGZ1bmN0aW9ucwogICovCisjaWZuZGVmIE5E
RUJVRworc3RhdGljIGJvb2xfdCB4bWVtX3Bvb2xfY2hlY2tfc2l6ZShjb25zdCBzdHJ1Y3QgeG1l
bV9wb29sICpwb29sLCBpbnQgZmwsIGludCBzbCkKK3sKKyAgICBjb25zdCBzdHJ1Y3QgYmhkciAq
YiA9IHBvb2wtPm1hdHJpeFtmbF1bc2xdOworCisgICAgd2hpbGUgKCBiICkKKyAgICB7CisgICAg
ICAgIGludCBfX2ZsOworICAgICAgICBpbnQgX19zbDsKKworICAgICAgICBNQVBQSU5HX0lOU0VS
VChiLT5zaXplLCAmX19mbCwgJl9fc2wpOworICAgICAgICBpZiAoIF9fZmwgIT0gZmwgfHwgX19z
bCAhPSBzbCApCisgICAgICAgIHsKKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSCisgICAg
ICAgICAgICAgICAgICAgInhtZW1fcG9vbDogJXM6IG1pc3BsYWNlZCBibG9jayAlcDoldSAoeyVk
LCVkfSAtPiB7JWQsJWR9KVxuIiwKKyAgICAgICAgICAgICAgICAgICBwb29sLT5uYW1lLCBiLCBi
LT5zaXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOworICAgICAgICAgICAgcmV0dXJuIDA7CisgICAg
ICAgIH0KKyAgICAgICAgYiA9IGItPnB0ci5mcmVlX3B0ci5uZXh0OworICAgIH0KKyAgICByZXR1
cm4gMTsKK30KKworLyoKKyAqIFRoaXMgZnVuY3Rpb24gbXVzdCBiZSBjYWxsZWQgZnJvbSBhIGNv
bnRleHQgd2hlcmUgcG9vbC0+bG9jayBpcworICogYWxyZWFkeSBhY3F1aXJlZC4KKyAqCisgKiBS
ZXR1cm5zIHRydWUgaWYgdGhlIHBvb2wgaGFzIGJlZW4gY29ycnVwdGVkLCBmYWxzZSBvdGhlcndp
c2UKKyAqLworI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpIF9feG1lbV9wb29s
X2NoZWNrX2xvY2tlZChfX0ZJTEVfXywgX19MSU5FX18sIHBvb2wpCitzdGF0aWMgYm9vbF90IF9f
eG1lbV9wb29sX2NoZWNrX2xvY2tlZChjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgY29uc3Qg
c3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKK3sKKyAgICBpbnQgaTsKKyAgICBzdGF0aWMgYm9vbF90
IG9uY2UgPSAxOworCisgICAgaWYgKCAhb25jZSApCisgICAgICAgIGdvdG8gb3V0OworICAgIGZv
ciAoIGkgPSAwOyBpIDwgUkVBTF9GTEk7IGkrKyApCisgICAgeworICAgICAgICBpbnQgZmwgPSAo
cG9vbC0+ZmxfYml0bWFwICYgKDEgPDwgaSkpID8gaSA6IC0xOworCisgICAgICAgIGlmICggZmwg
Pj0gMCApCisgICAgICAgIHsKKyAgICAgICAgICAgIGludCBqOworCisgICAgICAgICAgICBpZiAo
ICFwb29sLT5zbF9iaXRtYXBbZmxdICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICBw
cmludGsoWEVOTE9HX0VSUgorICAgICAgICAgICAgICAgICAgICAgICAieG1lbV9wb29sOiAlczog
dGhlIFRMU0YgYml0bWFwIGlzIGNvcnJ1cHRlZCAobm9uLWVtcHR5IEZMIHdpdGggZW1wdHkgU0wp
XG4iLAorICAgICAgICAgICAgICAgICAgICAgICBwb29sLT5uYW1lKTsKKyAgICAgICAgICAgICAg
ICBfX3dhcm4oZmlsZSwgbGluZSk7CisgICAgICAgICAgICAgICAgb25jZSA9IDA7CisgICAgICAg
ICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICB9CisgICAgICAgICAgICBmb3IgKCBqID0gMDsg
aiA8IE1BWF9TTEk7IGorKyApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgaW50IHNs
ID0gKHBvb2wtPnNsX2JpdG1hcFtmbF0gJiAoMSA8PCBqKSkgPyBqIDogLTE7CisKKyAgICAgICAg
ICAgICAgICBpZiAoIHNsIDwgMCApCisgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOworICAg
ICAgICAgICAgICAgIGlmICggIXBvb2wtPm1hdHJpeFtmbF1bc2xdICkKKyAgICAgICAgICAgICAg
ICB7CisgICAgICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAieG1lbV9wb29sOiAlczogdGhlIFRMU0YgYml0bWFwIGlzIGNvcnJ1cHRl
ZCAobWF0cml4WyVkXVslZF0gaXMgTlVMTClcbiIsCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICBwb29sLT5uYW1lLCBmbCwgc2wpOworICAgICAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwg
bGluZSk7CisgICAgICAgICAgICAgICAgICAgIG9uY2UgPSAwOworICAgICAgICAgICAgICAgICAg
ICBicmVhazsKKyAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgaWYgKCAheG1lbV9w
b29sX2NoZWNrX3NpemUocG9vbCwgZmwsIHNsKSApCisgICAgICAgICAgICAgICAgeworICAgICAg
ICAgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9wb29sOiAlczogdGhlIFRMU0Yg
Y2h1bmsgbWF0cml4IGlzIGNvcnJ1cHRlZFxuIiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
IHBvb2wtPm5hbWUpOworICAgICAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGluZSk7Cisg
ICAgICAgICAgICAgICAgICAgIG9uY2UgPSAwOworICAgICAgICAgICAgICAgICAgICBicmVhazsK
KyAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICB9CisgICAgICAgICAgICBpZiAoICFvbmNl
ICkKKyAgICAgICAgICAgICAgICBicmVhazsKKyAgICAgICAgfQorICAgIH0KK291dDoKKyAgICBy
ZXR1cm4gIW9uY2U7Cit9CisKKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKHBvb2wp
IF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKF9fRklMRV9fLCBfX0xJTkVfXywgcG9vbCkKK3N0
YXRpYyBib29sX3QgX194bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoY29uc3QgY2hhciAqZmlsZSwg
aW50IGxpbmUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCit7CisgICAgYm9vbF90IG9vcHM7CisK
KyAgICBzcGluX2xvY2soJnBvb2wtPmxvY2spOworICAgIG9vcHMgPSBfX3htZW1fcG9vbF9jaGVj
a19sb2NrZWQoZmlsZSwgbGluZSwgcG9vbCk7CisgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2sp
OworICAgIHJldHVybiBvb3BzOworfQorCitib29sX3QgX194bWVtX3Bvb2xfY2hlY2soY29uc3Qg
Y2hhciAqZmlsZSwgaW50IGxpbmUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCit7CisgICAgcmV0
dXJuIF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wgPzogeGVucG9v
bCk7Cit9CisjZWxzZQorI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpICgodm9p
ZCkocG9vbCkpCisjZGVmaW5lIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChwb29sKSAoKHZvaWQp
KHBvb2wpKQorI2VuZGlmCiAKIC8qKgogICogUmV0dXJucyBpbmRleGVzIChmbCwgc2wpIG9mIHRo
ZSBsaXN0IHVzZWQgdG8gc2VydmUgcmVxdWVzdCBvZiBzaXplIHIKQEAgLTM4MSw2ICs0OTAsOCBA
QCB2b2lkICp4bWVtX3Bvb2xfYWxsb2ModW5zaWduZWQgbG9uZyBzaXplLCBzdHJ1Y3QgeG1lbV9w
b29sICpwb29sKQogICAgIGludCBmbCwgc2w7CiAgICAgdW5zaWduZWQgbG9uZyB0bXBfc2l6ZTsK
IAorICAgIHhtZW1fcG9vbF9jaGVja191bmxvY2tlZChwb29sKTsKKwogICAgIGlmICggcG9vbC0+
aW5pdF9yZWdpb24gPT0gTlVMTCApCiAgICAgewogICAgICAgICBpZiAoIChyZWdpb24gPSBwb29s
LT5nZXRfbWVtKHBvb2wtPmluaXRfc2l6ZSkpID09IE5VTEwgKQpAQCAtNDQyLDExICs1NTMsMTMg
QEAgdm9pZCAqeG1lbV9wb29sX2FsbG9jKHVuc2lnbmVkIGxvbmcgc2l6ZSwgc3RydWN0IHhtZW1f
cG9vbCAqcG9vbCkKIAogICAgIHBvb2wtPnVzZWRfc2l6ZSArPSAoYi0+c2l6ZSAmIEJMT0NLX1NJ
WkVfTUFTSykgKyBCSERSX09WRVJIRUFEOwogCisgICAgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChw
b29sKTsKICAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7CiAgICAgcmV0dXJuICh2b2lkICop
Yi0+cHRyLmJ1ZmZlcjsKIAogICAgIC8qIEZhaWxlZCBhbGxvYyAqLwogIG91dF9sb2NrZWQ6Cisg
ICAgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKTsKICAgICBzcGluX3VubG9jaygmcG9vbC0+
bG9jayk7CiAKICBvdXQ6CkBAIC00NjQsNiArNTc3LDcgQEAgdm9pZCB4bWVtX3Bvb2xfZnJlZSh2
b2lkICpwdHIsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCiAgICAgYiA9IChzdHJ1Y3QgYmhkciAq
KSgoY2hhciAqKSBwdHIgLSBCSERSX09WRVJIRUFEKTsKIAogICAgIHNwaW5fbG9jaygmcG9vbC0+
bG9jayk7CisgICAgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKTsKICAgICBiLT5zaXplIHw9
IEZSRUVfQkxPQ0s7CiAgICAgcG9vbC0+dXNlZF9zaXplIC09IChiLT5zaXplICYgQkxPQ0tfU0la
RV9NQVNLKSArIEJIRFJfT1ZFUkhFQUQ7CiAgICAgYi0+cHRyLmZyZWVfcHRyID0gKHN0cnVjdCBm
cmVlX3B0cikgeyBOVUxMLCBOVUxMfTsKQEAgLTUwMCw2ICs2MTQsNyBAQCB2b2lkIHhtZW1fcG9v
bF9mcmVlKHZvaWQgKnB0ciwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKICAgICB0bXBfYi0+c2l6
ZSB8PSBQUkVWX0ZSRUU7CiAgICAgdG1wX2ItPnByZXZfaGRyID0gYjsKICBvdXQ6CisgICAgeG1l
bV9wb29sX2NoZWNrX2xvY2tlZChwb29sKTsKICAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7
CiB9CiAKQEAgLTUxMiw4ICs2MjcsNiBAQCBpbnQgeG1lbV9wb29sX21heGFsbG9jKHN0cnVjdCB4
bWVtX3Bvb2wgKnBvb2wpCiAgKiBHbHVlIGZvciB4bWFsbG9jKCkuCiAgKi8KIAotc3RhdGljIHN0
cnVjdCB4bWVtX3Bvb2wgKnhlbnBvb2w7Ci0KIHN0YXRpYyB2b2lkICp4bWFsbG9jX3Bvb2xfZ2V0
KHVuc2lnbmVkIGxvbmcgc2l6ZSkKIHsKICAgICBBU1NFUlQoc2l6ZSA9PSBQQUdFX1NJWkUpOwpk
aWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaCBiL3hlbi9pbmNsdWRlL3hlbi94
bWFsbG9jLmgKaW5kZXggMjRhOTlhYy4uYWQ0ODkzMCAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUv
eGVuL3htYWxsb2MuaAorKysgYi94ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCkBAIC0xMjMsNCAr
MTIzLDExIEBAIHVuc2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF91c2VkX3NpemUoc3RydWN0IHht
ZW1fcG9vbCAqcG9vbCk7CiAgKi8KIHVuc2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF90b3RhbF9z
aXplKHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpOwogCisjaWZuZGVmIE5ERUJVRworI2RlZmluZSB4
bWVtX3Bvb2xfY2hlY2socG9vbCkgX194bWVtX3Bvb2xfY2hlY2soX19GSUxFX18sIF9fTElORV9f
LCBwb29sKQorYm9vbF90IF9feG1lbV9wb29sX2NoZWNrKGNvbnN0IGNoYXIgKmZpbGUsIGludCBs
aW5lLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKTsKKyNlbHNlCisjZGVmaW5lIHhtZW1fcG9vbF9j
aGVjayhwb29sKSAoKHZvaWQpMCkKKyNlbmRpZgorCiAjZW5kaWYgLyogX19YTUFMTE9DX0hfXyAq
LwotLSAKMi4yLjAKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Dec 10 12:20:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12:20:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XygFN-0003RO-CU; Wed, 10 Dec 2014 12:20: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 1XygFM-0003RI-9n
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 12:20:00 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	63/C1-27584-F6A38845; Wed, 10 Dec 2014 12:19:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418213997!12611680!1
X-Originating-IP: [66.165.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 5680 invoked from network); 10 Dec 2014 12:19:58 -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 Dec 2014 12:19:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202787567"
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.210.2; Wed, 10 Dec 2014 07:19: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 1XygFG-0007wj-Gs;
	Wed, 10 Dec 2014 12:19:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XygFG-0008A6-BL;
	Wed, 10 Dec 2014 12:19:54 +0000
Date: Wed, 10 Dec 2014 12:19:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32194-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] 32194: 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 32194 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32194/

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 32117

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-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-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-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        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                45e1611de8be0eae55967694dd6e627c2dc354f2
baseline version:
 qemuu                d00e6cddc220de993573dfb5fd160ac72ccd49ab

------------------------------------------------------------
People who touched revisions under test:
  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                    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=45e1611de8be0eae55967694dd6e627c2dc354f2
+ . 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 45e1611de8be0eae55967694dd6e627c2dc354f2
+ branch=qemu-mainline
+ revision=45e1611de8be0eae55967694dd6e627c2dc354f2
+ . 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 45e1611de8be0eae55967694dd6e627c2dc354f2:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   d00e6cd..45e1611  45e1611de8be0eae55967694dd6e627c2dc354f2 -> 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 Dec 10 12:20:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12:20:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XygFN-0003RO-CU; Wed, 10 Dec 2014 12:20: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 1XygFM-0003RI-9n
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 12:20:00 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	63/C1-27584-F6A38845; Wed, 10 Dec 2014 12:19:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418213997!12611680!1
X-Originating-IP: [66.165.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 5680 invoked from network); 10 Dec 2014 12:19:58 -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 Dec 2014 12:19:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202787567"
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.210.2; Wed, 10 Dec 2014 07:19: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 1XygFG-0007wj-Gs;
	Wed, 10 Dec 2014 12:19:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XygFG-0008A6-BL;
	Wed, 10 Dec 2014 12:19:54 +0000
Date: Wed, 10 Dec 2014 12:19:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32194-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] 32194: 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 32194 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32194/

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 32117

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-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-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-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        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                45e1611de8be0eae55967694dd6e627c2dc354f2
baseline version:
 qemuu                d00e6cddc220de993573dfb5fd160ac72ccd49ab

------------------------------------------------------------
People who touched revisions under test:
  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                    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=45e1611de8be0eae55967694dd6e627c2dc354f2
+ . 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 45e1611de8be0eae55967694dd6e627c2dc354f2
+ branch=qemu-mainline
+ revision=45e1611de8be0eae55967694dd6e627c2dc354f2
+ . 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 45e1611de8be0eae55967694dd6e627c2dc354f2:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   d00e6cd..45e1611  45e1611de8be0eae55967694dd6e627c2dc354f2 -> 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 Dec 10 12:23:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12: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 1XygIJ-0003kz-V3; Wed, 10 Dec 2014 12:23:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XygII-0003kp-JM
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 12:23:02 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	EB/10-23865-52B38845; Wed, 10 Dec 2014 12:23:01 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418214179!8611032!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 31877 invoked from network); 10 Dec 2014 12:22:59 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 12:22:59 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=FUa46v1zjTK2MGxMH8qdpbWf8NQEqeYr5OxwFaCka+5Kb8uTt9byLCJzyYY/isSkPfUZ4qvOkUzkmbW8ESpA3i1mlR5GP1eCl6CPJr1PgRbplBB4UbxtSckShlTcTi86IZont8WtOnS1ozSG7+KeBscwtIGI0pfEjJIv5KnuO8l/g/IhCzR6jnstOhc2dy1VfQclEPP1Fxnoq/US+fgeZDoKn3FhQl6WlA4j/AgYxsuJRt6shEMgFt5q+fn5DY8ySPR8BGXAG+cDFNbZwN3hWtighYuJa1ifeJsFnW/0vq0awZegsrd+FByAwo5XBNN8kOOTiLChncIzeaGR0eSqmw==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:MIME-Version: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=from:to
	:cc:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=EvIhKF+GbvKuAcqWX6oz9f
	UITIU=; b=3NNgNYPokY9xgcRQ2Zxc378vIwLQNs230KizEPMAOdZ8LE2zE7uYhg
	qw7yn/6wr6jtkmCfRiGgk0oVtvGHhb/ZWi2oR8FxPgSY5lzVTvcr4RZkR4O682lk
	IYcnKNYsVHPapJuXYp0A29LT+XfU9u+S4iIS2pY2Pn+W1Puwk5RX7AF/BERuxO1X
	Y/5wmYhOBLhzn+t9nC0M4GqufcLyJHR+SIo2SFIrTZKrucdqQKRpByFbVauvH/Lo
	gvoSgSY5OqPSdkH6onz4HjEz0LxLW0rc7/MPAEiVPVsyrbGEIsJLdkeiu+pUznFT
	H4eKF3sdY1RTnp8GLCpnB9etynrj8Xyw==
Received: (qmail 10284 invoked from network); 10 Dec 2014 14:22:59 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	10 Dec 2014 14:22:59 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id D565E80355
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 14:22:58 +0200 (EET)
Received: (qmail 17800 invoked from network); 10 Dec 2014 14:22:58 +0200
Received: from unknown (HELO mdontu-l.dsd.bitdefender.biz)
	(mdontu@bitdefender.com@91.199.104.6)
	by smtp03.buh.bitdefender.org with SMTP; 10 Dec 2014 14:22:58 +0200
From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 14:22:36 +0200
Message-Id: <1418214156-15182-1-git-send-email-mdontu@bitdefender.com>
X-Mailer: git-send-email 2.2.0
MIME-Version: 1.0
Content-Length: 2319
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.58209
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374468,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; 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.1.2; Id: 2m1ghdo.198ps9t1t.aart],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, jbeulich@suse.com
Subject: [Xen-devel] [PATCH] console: const-ify the arguments for __warn()
	and __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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Qm90aCBfX3dhcm4oKSBhbmQgX19idWcoKSB0YWtlIGFzIGZpcnN0IHBhcmFtZXRlciB0aGUgZmls
ZSBuYW1lIG9mIHRoZQpjdXJyZW50IGNvbXBpbGF0aW9uIHVuaXQgKF9fRklMRV9fKS4gTWFyayB0
aGF0IHBhcmFtZXRlciBhcyBjb25zdGFudCB0bwpiZXR0ZXIgcmVmbGVjdCB0aGF0LgoKU2lnbmVk
LW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0ZGVmZW5kZXIuY29tPgpSZXZpZXdlZC1i
eTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KLS0tCiB4ZW4vZHJp
dmVycy9jaGFyL2NvbnNvbGUuYyB8IDQgKystLQogeGVuL2luY2x1ZGUveGVuL2xpYi5oICAgICAg
fCA0ICsrLS0KIDIgZmlsZXMgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygt
KQoKZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jIGIveGVuL2RyaXZlcnMv
Y2hhci9jb25zb2xlLmMKaW5kZXggMmYwMzI1OS4uNzgwN2NmMiAxMDA2NDQKLS0tIGEveGVuL2Ry
aXZlcnMvY2hhci9jb25zb2xlLmMKKysrIGIveGVuL2RyaXZlcnMvY2hhci9jb25zb2xlLmMKQEAg
LTExMzgsNyArMTEzOCw3IEBAIHZvaWQgcGFuaWMoY29uc3QgY2hhciAqZm10LCAuLi4pCiAgICAg
ICAgIG1hY2hpbmVfcmVzdGFydCg1MDAwKTsKIH0KIAotdm9pZCBfX2J1ZyhjaGFyICpmaWxlLCBp
bnQgbGluZSkKK3ZvaWQgX19idWcoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpCiB7CiAgICAg
Y29uc29sZV9zdGFydF9zeW5jKCk7CiAgICAgcHJpbnRrKCJYZW4gQlVHIGF0ICVzOiVkXG4iLCBm
aWxlLCBsaW5lKTsKQEAgLTExNDYsNyArMTE0Niw3IEBAIHZvaWQgX19idWcoY2hhciAqZmlsZSwg
aW50IGxpbmUpCiAgICAgcGFuaWMoIlhlbiBCVUcgYXQgJXM6JWQiLCBmaWxlLCBsaW5lKTsKIH0K
IAotdm9pZCBfX3dhcm4oY2hhciAqZmlsZSwgaW50IGxpbmUpCit2b2lkIF9fd2Fybihjb25zdCBj
aGFyICpmaWxlLCBpbnQgbGluZSkKIHsKICAgICBwcmludGsoIlhlbiBXQVJOIGF0ICVzOiVkXG4i
LCBmaWxlLCBsaW5lKTsKICAgICBkdW1wX2V4ZWN1dGlvbl9zdGF0ZSgpOwpkaWZmIC0tZ2l0IGEv
eGVuL2luY2x1ZGUveGVuL2xpYi5oIGIveGVuL2luY2x1ZGUveGVuL2xpYi5oCmluZGV4IGYxMWI0
OWUuLjhmOWNhZGIgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9saWIuaAorKysgYi94ZW4v
aW5jbHVkZS94ZW4vbGliLmgKQEAgLTgsOCArOCw4IEBACiAjaW5jbHVkZSA8eGVuL3N0cmluZy5o
PgogI2luY2x1ZGUgPGFzbS9idWcuaD4KIAotdm9pZCBub3JldHVybiBfX2J1ZyhjaGFyICpmaWxl
LCBpbnQgbGluZSk7Ci12b2lkIF9fd2FybihjaGFyICpmaWxlLCBpbnQgbGluZSk7Cit2b2lkIG5v
cmV0dXJuIF9fYnVnKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKTsKK3ZvaWQgX193YXJuKGNv
bnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKTsKIAogI2RlZmluZSBCVUdfT04ocCkgIGRvIHsgaWYg
KHVubGlrZWx5KHApKSBCVUcoKTsgIH0gd2hpbGUgKDApCiAjZGVmaW5lIFdBUk5fT04ocCkgZG8g
eyBpZiAodW5saWtlbHkocCkpIFdBUk4oKTsgfSB3aGlsZSAoMCkKLS0gCjIuMi4wCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Dec 10 12:23:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12: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 1XygIJ-0003kz-V3; Wed, 10 Dec 2014 12:23:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XygII-0003kp-JM
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 12:23:02 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	EB/10-23865-52B38845; Wed, 10 Dec 2014 12:23:01 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418214179!8611032!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 31877 invoked from network); 10 Dec 2014 12:22:59 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 12:22:59 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=FUa46v1zjTK2MGxMH8qdpbWf8NQEqeYr5OxwFaCka+5Kb8uTt9byLCJzyYY/isSkPfUZ4qvOkUzkmbW8ESpA3i1mlR5GP1eCl6CPJr1PgRbplBB4UbxtSckShlTcTi86IZont8WtOnS1ozSG7+KeBscwtIGI0pfEjJIv5KnuO8l/g/IhCzR6jnstOhc2dy1VfQclEPP1Fxnoq/US+fgeZDoKn3FhQl6WlA4j/AgYxsuJRt6shEMgFt5q+fn5DY8ySPR8BGXAG+cDFNbZwN3hWtighYuJa1ifeJsFnW/0vq0awZegsrd+FByAwo5XBNN8kOOTiLChncIzeaGR0eSqmw==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:MIME-Version: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=from:to
	:cc:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=EvIhKF+GbvKuAcqWX6oz9f
	UITIU=; b=3NNgNYPokY9xgcRQ2Zxc378vIwLQNs230KizEPMAOdZ8LE2zE7uYhg
	qw7yn/6wr6jtkmCfRiGgk0oVtvGHhb/ZWi2oR8FxPgSY5lzVTvcr4RZkR4O682lk
	IYcnKNYsVHPapJuXYp0A29LT+XfU9u+S4iIS2pY2Pn+W1Puwk5RX7AF/BERuxO1X
	Y/5wmYhOBLhzn+t9nC0M4GqufcLyJHR+SIo2SFIrTZKrucdqQKRpByFbVauvH/Lo
	gvoSgSY5OqPSdkH6onz4HjEz0LxLW0rc7/MPAEiVPVsyrbGEIsJLdkeiu+pUznFT
	H4eKF3sdY1RTnp8GLCpnB9etynrj8Xyw==
Received: (qmail 10284 invoked from network); 10 Dec 2014 14:22:59 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	10 Dec 2014 14:22:59 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id D565E80355
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 14:22:58 +0200 (EET)
Received: (qmail 17800 invoked from network); 10 Dec 2014 14:22:58 +0200
Received: from unknown (HELO mdontu-l.dsd.bitdefender.biz)
	(mdontu@bitdefender.com@91.199.104.6)
	by smtp03.buh.bitdefender.org with SMTP; 10 Dec 2014 14:22:58 +0200
From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 14:22:36 +0200
Message-Id: <1418214156-15182-1-git-send-email-mdontu@bitdefender.com>
X-Mailer: git-send-email 2.2.0
MIME-Version: 1.0
Content-Length: 2319
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.58209
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374468,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; 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.1.2; Id: 2m1ghdo.198ps9t1t.aart],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, tim@xen.org, jbeulich@suse.com
Subject: [Xen-devel] [PATCH] console: const-ify the arguments for __warn()
	and __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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Qm90aCBfX3dhcm4oKSBhbmQgX19idWcoKSB0YWtlIGFzIGZpcnN0IHBhcmFtZXRlciB0aGUgZmls
ZSBuYW1lIG9mIHRoZQpjdXJyZW50IGNvbXBpbGF0aW9uIHVuaXQgKF9fRklMRV9fKS4gTWFyayB0
aGF0IHBhcmFtZXRlciBhcyBjb25zdGFudCB0bwpiZXR0ZXIgcmVmbGVjdCB0aGF0LgoKU2lnbmVk
LW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0ZGVmZW5kZXIuY29tPgpSZXZpZXdlZC1i
eTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KLS0tCiB4ZW4vZHJp
dmVycy9jaGFyL2NvbnNvbGUuYyB8IDQgKystLQogeGVuL2luY2x1ZGUveGVuL2xpYi5oICAgICAg
fCA0ICsrLS0KIDIgZmlsZXMgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygt
KQoKZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jIGIveGVuL2RyaXZlcnMv
Y2hhci9jb25zb2xlLmMKaW5kZXggMmYwMzI1OS4uNzgwN2NmMiAxMDA2NDQKLS0tIGEveGVuL2Ry
aXZlcnMvY2hhci9jb25zb2xlLmMKKysrIGIveGVuL2RyaXZlcnMvY2hhci9jb25zb2xlLmMKQEAg
LTExMzgsNyArMTEzOCw3IEBAIHZvaWQgcGFuaWMoY29uc3QgY2hhciAqZm10LCAuLi4pCiAgICAg
ICAgIG1hY2hpbmVfcmVzdGFydCg1MDAwKTsKIH0KIAotdm9pZCBfX2J1ZyhjaGFyICpmaWxlLCBp
bnQgbGluZSkKK3ZvaWQgX19idWcoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpCiB7CiAgICAg
Y29uc29sZV9zdGFydF9zeW5jKCk7CiAgICAgcHJpbnRrKCJYZW4gQlVHIGF0ICVzOiVkXG4iLCBm
aWxlLCBsaW5lKTsKQEAgLTExNDYsNyArMTE0Niw3IEBAIHZvaWQgX19idWcoY2hhciAqZmlsZSwg
aW50IGxpbmUpCiAgICAgcGFuaWMoIlhlbiBCVUcgYXQgJXM6JWQiLCBmaWxlLCBsaW5lKTsKIH0K
IAotdm9pZCBfX3dhcm4oY2hhciAqZmlsZSwgaW50IGxpbmUpCit2b2lkIF9fd2Fybihjb25zdCBj
aGFyICpmaWxlLCBpbnQgbGluZSkKIHsKICAgICBwcmludGsoIlhlbiBXQVJOIGF0ICVzOiVkXG4i
LCBmaWxlLCBsaW5lKTsKICAgICBkdW1wX2V4ZWN1dGlvbl9zdGF0ZSgpOwpkaWZmIC0tZ2l0IGEv
eGVuL2luY2x1ZGUveGVuL2xpYi5oIGIveGVuL2luY2x1ZGUveGVuL2xpYi5oCmluZGV4IGYxMWI0
OWUuLjhmOWNhZGIgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi9saWIuaAorKysgYi94ZW4v
aW5jbHVkZS94ZW4vbGliLmgKQEAgLTgsOCArOCw4IEBACiAjaW5jbHVkZSA8eGVuL3N0cmluZy5o
PgogI2luY2x1ZGUgPGFzbS9idWcuaD4KIAotdm9pZCBub3JldHVybiBfX2J1ZyhjaGFyICpmaWxl
LCBpbnQgbGluZSk7Ci12b2lkIF9fd2FybihjaGFyICpmaWxlLCBpbnQgbGluZSk7Cit2b2lkIG5v
cmV0dXJuIF9fYnVnKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKTsKK3ZvaWQgX193YXJuKGNv
bnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKTsKIAogI2RlZmluZSBCVUdfT04ocCkgIGRvIHsgaWYg
KHVubGlrZWx5KHApKSBCVUcoKTsgIH0gd2hpbGUgKDApCiAjZGVmaW5lIFdBUk5fT04ocCkgZG8g
eyBpZiAodW5saWtlbHkocCkpIFdBUk4oKTsgfSB3aGlsZSAoMCkKLS0gCjIuMi4wCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Dec 10 12:27:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XygMW-0003wA-QM; Wed, 10 Dec 2014 12:27:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XygMV-0003w5-Fr
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 12:27:23 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	DE/52-27623-A2C38845; Wed, 10 Dec 2014 12:27:22 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418214441!7898452!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 11966 invoked from network); 10 Dec 2014 12:27:21 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 12:27:21 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=qukhS57TqVXSKICr6L6ODRiyzR2jPEyh2vQc77QdVCJ0H7QXCud1WcN9YNxoviNVyVSMKHj30EVe6N9lRsOltyfFzHcoBjn57mGKFnGgOebUOimtJQRuQrdqZ1T6LjlZte1amCapxoWquiSfSCt9caiWCOaUozvWsdwmni56/zPvASak6MiSioMYnI38+olwAX2VonfD7166Sj0WR79Ah1qWQmiV2hq3MBMp2qqzv7UF+x0eLnzES1WQaBcxbGMnnvaS+uiKU4+S4Aajl9cGuo68AxR8/WaUQ663Db7sp2NSVLHuUxseJtEXiVZlR9VZjWZRSVdRm8JFRFc29LapkA==;
	h=Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:cc:subject:message-id:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	bh=tQs9TI2eYjd23D+/bV0YMOAedGw=; b=B43t3WP3HCqme/Bu9Jl70Ul7EaVj
	67MnAEbSkomUtdVwZ1/m0YFDzHZ3nZvOLmtunYiABYDKn8JIw9OeujfOV50oiGHZ
	dWGVyCDPiCiFvA1/xLjjwTILNcA/7zjtuIZBxSm12fQIqC8lqfjVuFP2pJXaSWd1
	fa6NvbyJ6qZF8Ut4a/gGmbugYmJkybM+4SgS/OFZZYOT9cL9qU133rPsw5bdoIQE
	MehvkPnx1sEanlMC9gxmkcjv2+h4p0RHaQ3dNmgBnsgcoi37EsrgwUa0zfPnojET
	mz7uXsDykLOw2MGc0U3o8pdu4yXYKrq80JLmfEfk3TUQ8tu9lMXGvIjd+Q==
Received: (qmail 11260 invoked from network); 10 Dec 2014 14:27:21 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	10 Dec 2014 14:27:21 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id E4A2C80414
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 14:27:20 +0200 (EET)
Received: (qmail 17880 invoked from network); 10 Dec 2014 14:27:20 +0200
Received: from unknown (HELO bitdefender.com)
	(mdontu@bitdefender.com@91.199.104.6)
	by smtp03.buh.bitdefender.org with SMTP; 10 Dec 2014 14:27:18 +0200
Date: Wed, 10 Dec 2014 14:27:18 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: xen-devel@lists.xen.org
Message-ID: <20141210142718.0ea5bc1a@bitdefender.com>
In-Reply-To: <1418213638-14896-1-git-send-email-mdontu@bitdefender.com>
References: <1418213638-14896-1-git-send-email-mdontu@bitdefender.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.58209
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374468,
	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_LEGIT_BITDEFENDER;
	NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled],
	URL: [Enabled], RTDA: [Enabled, Hit: No, Details: v2.1.2; Id:
	2m1ghdo.198ps9t1t.amob], total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: ian.jackson@eu.citrix.com, keir@xen.org, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v3] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAxMCBEZWMgMjAxNCAxNDoxMzo1OCArMDIwMCBNaWhhaSBEb27Im3Ugd3JvdGU6Cj4g
SW1wbGVtZW50ZWQgeG1lbV9wb29sX2NoZWNrKCksIHhtZW1fcG9vbF9jaGVja19sb2NrZWQoKSBh
bmQKPiB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoKSB0byB2ZXJpdHkgdGhlIGludGVncml0eSBv
ZiB0aGUgVExTRiBtYXRyaXguCj4gCj4gU2lnbmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9u
dHVAYml0ZGVmZW5kZXIuY29tPgo+IAo+IC0tLQo+IENoYW5nZXMgc2luY2UgdjI6Cj4gIC0gcHJp
bnQgdGhlIG5hbWUgb2YgdGhlIGNvcnJ1cHRlZCBwb29sCj4gIC0gYWRqdXN0ZWQgdGhlIG1lc3Nh
Z2VzIHRvIGJldHRlciBmaXQgd2l0aGluIDgwIGNvbHVtbnMKPiAgLSBtaW5vciBzdHlsZSBjaGFu
Z2UgKGEgPyBhIDogYiAtPiBhID86IGIpCj4gCj4gQ2hhbmdlcyBzaW5jZSB2MToKPiAgLSBmaXhl
ZCB0aGUgY29kaW5nc3R5bGUKPiAgLSBzd2FwZWQgX2xvY2tlZC9fdW5sb2NrZWQgbmFtaW5nCj4g
IC0gcmV3b3JrZWQgX194bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKCkgYSBiaXQKPiAgLSB1c2VkIGJv
b2xfdCB3aGVyZSBhcHByb3ByaWF0ZQo+ICAtIG1hZGUgeG1lbV9wb29sX2NoZWNrKCkgdGFrZSBh
IHBvb2wgYXJndW1lbnQgd2hpY2ggY2FuIGJlIE5VTEwKPiAtLS0KPiAgeGVuL2NvbW1vbi94bWFs
bG9jX3Rsc2YuYyB8IDExNyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKystCj4gIHhlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmggfCAgIDcgKysrCj4gIDIgZmlsZXMg
Y2hhbmdlZCwgMTIyIGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCj4gCj4gZGlmZiAtLWdp
dCBhL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMgYi94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5j
Cj4gaW5kZXggYTU3NjljOS4uMWRlYTEzNyAxMDA2NDQKPiAtLS0gYS94ZW4vY29tbW9uL3htYWxs
b2NfdGxzZi5jCj4gKysrIGIveGVuL2NvbW1vbi94bWFsbG9jX3Rsc2YuYwo+IEBAIC0xMjAsOSAr
MTIwLDExOCBAQCBzdHJ1Y3QgeG1lbV9wb29sIHsKPiAgICAgIGNoYXIgbmFtZVtNQVhfUE9PTF9O
QU1FX0xFTl07Cj4gIH07Cj4gIAo+ICtzdGF0aWMgc3RydWN0IHhtZW1fcG9vbCAqeGVucG9vbDsK
PiArCj4gK3N0YXRpYyBpbmxpbmUgdm9pZCBNQVBQSU5HX0lOU0VSVCh1bnNpZ25lZCBsb25nIHIs
IGludCAqZmwsIGludCAqc2wpOwo+ICsKPiAgLyoKPiAgICogSGVscGluZyBmdW5jdGlvbnMKPiAg
ICovCj4gKyNpZm5kZWYgTkRFQlVHCj4gK3N0YXRpYyBib29sX3QgeG1lbV9wb29sX2NoZWNrX3Np
emUoY29uc3Qgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCwgaW50IGZsLCBpbnQgc2wpCj4gK3sKPiAr
ICAgIGNvbnN0IHN0cnVjdCBiaGRyICpiID0gcG9vbC0+bWF0cml4W2ZsXVtzbF07Cj4gKwo+ICsg
ICAgd2hpbGUgKCBiICkKPiArICAgIHsKPiArICAgICAgICBpbnQgX19mbDsKPiArICAgICAgICBp
bnQgX19zbDsKPiArCj4gKyAgICAgICAgTUFQUElOR19JTlNFUlQoYi0+c2l6ZSwgJl9fZmwsICZf
X3NsKTsKPiArICAgICAgICBpZiAoIF9fZmwgIT0gZmwgfHwgX19zbCAhPSBzbCApCj4gKyAgICAg
ICAgewo+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUgo+ICsgICAgICAgICAgICAgICAg
ICAgInhtZW1fcG9vbDogJXM6IG1pc3BsYWNlZCBibG9jayAlcDoldSAoeyVkLCVkfSAtPiB7JWQs
JWR9KVxuIiwKPiArICAgICAgICAgICAgICAgICAgIHBvb2wtPm5hbWUsIGIsIGItPnNpemUsIGZs
LCBzbCwgX19mbCwgX19zbCk7Cj4gKyAgICAgICAgICAgIHJldHVybiAwOwo+ICsgICAgICAgIH0K
PiArICAgICAgICBiID0gYi0+cHRyLmZyZWVfcHRyLm5leHQ7Cj4gKyAgICB9Cj4gKyAgICByZXR1
cm4gMTsKPiArfQo+ICsKPiArLyoKPiArICogVGhpcyBmdW5jdGlvbiBtdXN0IGJlIGNhbGxlZCBm
cm9tIGEgY29udGV4dCB3aGVyZSBwb29sLT5sb2NrIGlzCj4gKyAqIGFscmVhZHkgYWNxdWlyZWQu
Cj4gKyAqCj4gKyAqIFJldHVybnMgdHJ1ZSBpZiB0aGUgcG9vbCBoYXMgYmVlbiBjb3JydXB0ZWQs
IGZhbHNlIG90aGVyd2lzZQo+ICsgKi8KPiArI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfbG9ja2Vk
KHBvb2wpIF9feG1lbV9wb29sX2NoZWNrX2xvY2tlZChfX0ZJTEVfXywgX19MSU5FX18sIHBvb2wp
Cj4gK3N0YXRpYyBib29sX3QgX194bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKGNvbnN0IGNoYXIgKmZp
bGUsIGludCBsaW5lLCBjb25zdCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ICt7Cj4gKyAgICBp
bnQgaTsKPiArICAgIHN0YXRpYyBib29sX3Qgb25jZSA9IDE7Cj4gKwo+ICsgICAgaWYgKCAhb25j
ZSApCj4gKyAgICAgICAgZ290byBvdXQ7Cj4gKyAgICBmb3IgKCBpID0gMDsgaSA8IFJFQUxfRkxJ
OyBpKysgKQo+ICsgICAgewo+ICsgICAgICAgIGludCBmbCA9IChwb29sLT5mbF9iaXRtYXAgJiAo
MSA8PCBpKSkgPyBpIDogLTE7Cj4gKwo+ICsgICAgICAgIGlmICggZmwgPj0gMCApCj4gKyAgICAg
ICAgewo+ICsgICAgICAgICAgICBpbnQgajsKPiArCj4gKyAgICAgICAgICAgIGlmICggIXBvb2wt
PnNsX2JpdG1hcFtmbF0gKQo+ICsgICAgICAgICAgICB7Cj4gKyAgICAgICAgICAgICAgICBwcmlu
dGsoWEVOTE9HX0VSUgo+ICsgICAgICAgICAgICAgICAgICAgICAgICJ4bWVtX3Bvb2w6ICVzOiB0
aGUgVExTRiBiaXRtYXAgaXMgY29ycnVwdGVkIChub24tZW1wdHkgRkwgd2l0aCBlbXB0eSBTTClc
biIsCj4gKyAgICAgICAgICAgICAgICAgICAgICAgcG9vbC0+bmFtZSk7Cj4gKyAgICAgICAgICAg
ICAgICBfX3dhcm4oZmlsZSwgbGluZSk7Cj4gKyAgICAgICAgICAgICAgICBvbmNlID0gMDsKPiAr
ICAgICAgICAgICAgICAgIGJyZWFrOwo+ICsgICAgICAgICAgICB9Cj4gKyAgICAgICAgICAgIGZv
ciAoIGogPSAwOyBqIDwgTUFYX1NMSTsgaisrICkKPiArICAgICAgICAgICAgewo+ICsgICAgICAg
ICAgICAgICAgaW50IHNsID0gKHBvb2wtPnNsX2JpdG1hcFtmbF0gJiAoMSA8PCBqKSkgPyBqIDog
LTE7Cj4gKwo+ICsgICAgICAgICAgICAgICAgaWYgKCBzbCA8IDAgKQo+ICsgICAgICAgICAgICAg
ICAgICAgIGNvbnRpbnVlOwo+ICsgICAgICAgICAgICAgICAgaWYgKCAhcG9vbC0+bWF0cml4W2Zs
XVtzbF0gKQo+ICsgICAgICAgICAgICAgICAgewo+ICsgICAgICAgICAgICAgICAgICAgIHByaW50
ayhYRU5MT0dfRVJSCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICJ4bWVtX3Bvb2w6ICVz
OiB0aGUgVExTRiBiaXRtYXAgaXMgY29ycnVwdGVkIChtYXRyaXhbJWRdWyVkXSBpcyBOVUxMKVxu
IiwKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgcG9vbC0+bmFtZSwgZmwsIHNsKTsKPiAr
ICAgICAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGluZSk7Cj4gKyAgICAgICAgICAgICAg
ICAgICAgb25jZSA9IDA7Cj4gKyAgICAgICAgICAgICAgICAgICAgYnJlYWs7Cj4gKyAgICAgICAg
ICAgICAgICB9Cj4gKyAgICAgICAgICAgICAgICBpZiAoICF4bWVtX3Bvb2xfY2hlY2tfc2l6ZShw
b29sLCBmbCwgc2wpICkKPiArICAgICAgICAgICAgICAgIHsKPiArICAgICAgICAgICAgICAgICAg
ICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9wb29sOiAlczogdGhlIFRMU0YgY2h1bmsgbWF0cml4
IGlzIGNvcnJ1cHRlZFxuIiwKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgcG9vbC0+bmFt
ZSk7Cj4gKyAgICAgICAgICAgICAgICAgICAgX193YXJuKGZpbGUsIGxpbmUpOwo+ICsgICAgICAg
ICAgICAgICAgICAgIG9uY2UgPSAwOwo+ICsgICAgICAgICAgICAgICAgICAgIGJyZWFrOwo+ICsg
ICAgICAgICAgICAgICAgfQo+ICsgICAgICAgICAgICB9Cj4gKyAgICAgICAgICAgIGlmICggIW9u
Y2UgKQo+ICsgICAgICAgICAgICAgICAgYnJlYWs7Cj4gKyAgICAgICAgfQo+ICsgICAgfQo+ICtv
dXQ6Cj4gKyAgICByZXR1cm4gIW9uY2U7Cj4gK30KPiArCj4gKyNkZWZpbmUgeG1lbV9wb29sX2No
ZWNrX3VubG9ja2VkKHBvb2wpIF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKF9fRklMRV9fLCBf
X0xJTkVfXywgcG9vbCkKPiArc3RhdGljIGJvb2xfdCBfX3htZW1fcG9vbF9jaGVja191bmxvY2tl
ZChjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAr
ewo+ICsgICAgYm9vbF90IG9vcHM7Cj4gKwo+ICsgICAgc3Bpbl9sb2NrKCZwb29sLT5sb2NrKTsK
PiArICAgIG9vcHMgPSBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoZmlsZSwgbGluZSwgcG9vbCk7
Cj4gKyAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7Cj4gKyAgICByZXR1cm4gb29wczsKPiAr
fQo+ICsKPiArYm9vbF90IF9feG1lbV9wb29sX2NoZWNrKGNvbnN0IGNoYXIgKmZpbGUsIGludCBs
aW5lLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ICt7Cj4gKyAgICByZXR1cm4gX194bWVtX3Bv
b2xfY2hlY2tfdW5sb2NrZWQoZmlsZSwgbGluZSwgcG9vbCA/OiB4ZW5wb29sKTsKPiArfQo+ICsj
ZWxzZQo+ICsjZGVmaW5lIHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCkgKCh2b2lkKShwb29s
KSkKPiArI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQocG9vbCkgKCh2b2lkKShwb29s
KSkKPiArI2VuZGlmCj4gIAo+ICAvKioKPiAgICogUmV0dXJucyBpbmRleGVzIChmbCwgc2wpIG9m
IHRoZSBsaXN0IHVzZWQgdG8gc2VydmUgcmVxdWVzdCBvZiBzaXplIHIKPiBAQCAtMzgxLDYgKzQ5
MCw4IEBAIHZvaWQgKnhtZW1fcG9vbF9hbGxvYyh1bnNpZ25lZCBsb25nIHNpemUsIHN0cnVjdCB4
bWVtX3Bvb2wgKnBvb2wpCj4gICAgICBpbnQgZmwsIHNsOwo+ICAgICAgdW5zaWduZWQgbG9uZyB0
bXBfc2l6ZTsKPiAgCj4gKyAgICB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQocG9vbCk7Cj4gKwo+
ICAgICAgaWYgKCBwb29sLT5pbml0X3JlZ2lvbiA9PSBOVUxMICkKPiAgICAgIHsKPiAgICAgICAg
ICBpZiAoIChyZWdpb24gPSBwb29sLT5nZXRfbWVtKHBvb2wtPmluaXRfc2l6ZSkpID09IE5VTEwg
KQo+IEBAIC00NDIsMTEgKzU1MywxMyBAQCB2b2lkICp4bWVtX3Bvb2xfYWxsb2ModW5zaWduZWQg
bG9uZyBzaXplLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ICAKPiAgICAgIHBvb2wtPnVzZWRf
c2l6ZSArPSAoYi0+c2l6ZSAmIEJMT0NLX1NJWkVfTUFTSykgKyBCSERSX09WRVJIRUFEOwo+ICAK
PiArICAgIHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCk7Cj4gICAgICBzcGluX3VubG9jaygm
cG9vbC0+bG9jayk7Cj4gICAgICByZXR1cm4gKHZvaWQgKiliLT5wdHIuYnVmZmVyOwo+ICAKPiAg
ICAgIC8qIEZhaWxlZCBhbGxvYyAqLwo+ICAgb3V0X2xvY2tlZDoKPiArICAgIHhtZW1fcG9vbF9j
aGVja19sb2NrZWQocG9vbCk7Cj4gICAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7Cj4gIAo+
ICAgb3V0Ogo+IEBAIC00NjQsNiArNTc3LDcgQEAgdm9pZCB4bWVtX3Bvb2xfZnJlZSh2b2lkICpw
dHIsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gICAgICBiID0gKHN0cnVjdCBiaGRyICopKChj
aGFyICopIHB0ciAtIEJIRFJfT1ZFUkhFQUQpOwo+ICAKPiAgICAgIHNwaW5fbG9jaygmcG9vbC0+
bG9jayk7Cj4gKyAgICB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpOwo+ICAgICAgYi0+c2l6
ZSB8PSBGUkVFX0JMT0NLOwo+ICAgICAgcG9vbC0+dXNlZF9zaXplIC09IChiLT5zaXplICYgQkxP
Q0tfU0laRV9NQVNLKSArIEJIRFJfT1ZFUkhFQUQ7Cj4gICAgICBiLT5wdHIuZnJlZV9wdHIgPSAo
c3RydWN0IGZyZWVfcHRyKSB7IE5VTEwsIE5VTEx9Owo+IEBAIC01MDAsNiArNjE0LDcgQEAgdm9p
ZCB4bWVtX3Bvb2xfZnJlZSh2b2lkICpwdHIsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gICAg
ICB0bXBfYi0+c2l6ZSB8PSBQUkVWX0ZSRUU7Cj4gICAgICB0bXBfYi0+cHJldl9oZHIgPSBiOwo+
ICAgb3V0Ogo+ICsgICAgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKTsKPiAgICAgIHNwaW5f
dW5sb2NrKCZwb29sLT5sb2NrKTsKPiAgfQo+ICAKPiBAQCAtNTEyLDggKzYyNyw2IEBAIGludCB4
bWVtX3Bvb2xfbWF4YWxsb2Moc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAgICogR2x1ZSBmb3Ig
eG1hbGxvYygpLgo+ICAgKi8KPiAgCj4gLXN0YXRpYyBzdHJ1Y3QgeG1lbV9wb29sICp4ZW5wb29s
Owo+IC0KPiAgc3RhdGljIHZvaWQgKnhtYWxsb2NfcG9vbF9nZXQodW5zaWduZWQgbG9uZyBzaXpl
KQo+ICB7Cj4gICAgICBBU1NFUlQoc2l6ZSA9PSBQQUdFX1NJWkUpOwo+IGRpZmYgLS1naXQgYS94
ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oIGIveGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaAo+IGlu
ZGV4IDI0YTk5YWMuLmFkNDg5MzAgMTAwNjQ0Cj4gLS0tIGEveGVuL2luY2x1ZGUveGVuL3htYWxs
b2MuaAo+ICsrKyBiL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKPiBAQCAtMTIzLDQgKzEyMywx
MSBAQCB1bnNpZ25lZCBsb25nIHhtZW1fcG9vbF9nZXRfdXNlZF9zaXplKHN0cnVjdCB4bWVtX3Bv
b2wgKnBvb2wpOwo+ICAgKi8KPiAgdW5zaWduZWQgbG9uZyB4bWVtX3Bvb2xfZ2V0X3RvdGFsX3Np
emUoc3RydWN0IHhtZW1fcG9vbCAqcG9vbCk7Cj4gIAo+ICsjaWZuZGVmIE5ERUJVRwo+ICsjZGVm
aW5lIHhtZW1fcG9vbF9jaGVjayhwb29sKSBfX3htZW1fcG9vbF9jaGVjayhfX0ZJTEVfXywgX19M
SU5FX18sIHBvb2wpCj4gK2Jvb2xfdCBfX3htZW1fcG9vbF9jaGVjayhjb25zdCBjaGFyICpmaWxl
LCBpbnQgbGluZSwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCk7Cj4gKyNlbHNlCj4gKyNkZWZpbmUg
eG1lbV9wb29sX2NoZWNrKHBvb2wpICgodm9pZCkwKQo+ICsjZW5kaWYKPiArCj4gICNlbmRpZiAv
KiBfX1hNQUxMT0NfSF9fICovCgooc2hvdWxkJ3ZlIGNyZWF0ZWQgYSBzZXJpZXMpCgpUaGlzIHBh
dGNoIGRlcGVuZHMgb246Cmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9hcmNoaXZlcy9odG1s
L3hlbi1kZXZlbC8yMDE0LTEyL21zZzAxMTM1Lmh0bWwKClRoYW4geW91LAoKLS0gCk1paGFpIERP
TsiaVQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Dec 10 12:27:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XygMW-0003wA-QM; Wed, 10 Dec 2014 12:27:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1XygMV-0003w5-Fr
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 12:27:23 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	DE/52-27623-A2C38845; Wed, 10 Dec 2014 12:27:22 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418214441!7898452!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 11966 invoked from network); 10 Dec 2014 12:27:21 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 12:27:21 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=qukhS57TqVXSKICr6L6ODRiyzR2jPEyh2vQc77QdVCJ0H7QXCud1WcN9YNxoviNVyVSMKHj30EVe6N9lRsOltyfFzHcoBjn57mGKFnGgOebUOimtJQRuQrdqZ1T6LjlZte1amCapxoWquiSfSCt9caiWCOaUozvWsdwmni56/zPvASak6MiSioMYnI38+olwAX2VonfD7166Sj0WR79Ah1qWQmiV2hq3MBMp2qqzv7UF+x0eLnzES1WQaBcxbGMnnvaS+uiKU4+S4Aajl9cGuo68AxR8/WaUQ663Db7sp2NSVLHuUxseJtEXiVZlR9VZjWZRSVdRm8JFRFc29LapkA==;
	h=Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version: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=date
	:from:to:cc:subject:message-id:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	bh=tQs9TI2eYjd23D+/bV0YMOAedGw=; b=B43t3WP3HCqme/Bu9Jl70Ul7EaVj
	67MnAEbSkomUtdVwZ1/m0YFDzHZ3nZvOLmtunYiABYDKn8JIw9OeujfOV50oiGHZ
	dWGVyCDPiCiFvA1/xLjjwTILNcA/7zjtuIZBxSm12fQIqC8lqfjVuFP2pJXaSWd1
	fa6NvbyJ6qZF8Ut4a/gGmbugYmJkybM+4SgS/OFZZYOT9cL9qU133rPsw5bdoIQE
	MehvkPnx1sEanlMC9gxmkcjv2+h4p0RHaQ3dNmgBnsgcoi37EsrgwUa0zfPnojET
	mz7uXsDykLOw2MGc0U3o8pdu4yXYKrq80JLmfEfk3TUQ8tu9lMXGvIjd+Q==
Received: (qmail 11260 invoked from network); 10 Dec 2014 14:27:21 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	10 Dec 2014 14:27:21 +0200
Received: from smtp03.buh.bitdefender.org (unknown [10.17.80.77])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id E4A2C80414
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 14:27:20 +0200 (EET)
Received: (qmail 17880 invoked from network); 10 Dec 2014 14:27:20 +0200
Received: from unknown (HELO bitdefender.com)
	(mdontu@bitdefender.com@91.199.104.6)
	by smtp03.buh.bitdefender.org with SMTP; 10 Dec 2014 14:27:18 +0200
Date: Wed, 10 Dec 2014 14:27:18 +0200
From: Mihai =?UTF-8?B?RG9uyJt1?= <mdontu@bitdefender.com>
To: xen-devel@lists.xen.org
Message-ID: <20141210142718.0ea5bc1a@bitdefender.com>
In-Reply-To: <1418213638-14896-1-git-send-email-mdontu@bitdefender.com>
References: <1418213638-14896-1-git-send-email-mdontu@bitdefender.com>
Organization: Bitdefender
MIME-Version: 1.0
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp03.buh.bitdefender.org, sigver: 7.58209
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374468,
	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_LEGIT_BITDEFENDER;
	NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled],
	URL: [Enabled], RTDA: [Enabled, Hit: No, Details: v2.1.2; Id:
	2m1ghdo.198ps9t1t.amob], total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: ian.jackson@eu.citrix.com, keir@xen.org, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v3] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAxMCBEZWMgMjAxNCAxNDoxMzo1OCArMDIwMCBNaWhhaSBEb27Im3Ugd3JvdGU6Cj4g
SW1wbGVtZW50ZWQgeG1lbV9wb29sX2NoZWNrKCksIHhtZW1fcG9vbF9jaGVja19sb2NrZWQoKSBh
bmQKPiB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoKSB0byB2ZXJpdHkgdGhlIGludGVncml0eSBv
ZiB0aGUgVExTRiBtYXRyaXguCj4gCj4gU2lnbmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9u
dHVAYml0ZGVmZW5kZXIuY29tPgo+IAo+IC0tLQo+IENoYW5nZXMgc2luY2UgdjI6Cj4gIC0gcHJp
bnQgdGhlIG5hbWUgb2YgdGhlIGNvcnJ1cHRlZCBwb29sCj4gIC0gYWRqdXN0ZWQgdGhlIG1lc3Nh
Z2VzIHRvIGJldHRlciBmaXQgd2l0aGluIDgwIGNvbHVtbnMKPiAgLSBtaW5vciBzdHlsZSBjaGFu
Z2UgKGEgPyBhIDogYiAtPiBhID86IGIpCj4gCj4gQ2hhbmdlcyBzaW5jZSB2MToKPiAgLSBmaXhl
ZCB0aGUgY29kaW5nc3R5bGUKPiAgLSBzd2FwZWQgX2xvY2tlZC9fdW5sb2NrZWQgbmFtaW5nCj4g
IC0gcmV3b3JrZWQgX194bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKCkgYSBiaXQKPiAgLSB1c2VkIGJv
b2xfdCB3aGVyZSBhcHByb3ByaWF0ZQo+ICAtIG1hZGUgeG1lbV9wb29sX2NoZWNrKCkgdGFrZSBh
IHBvb2wgYXJndW1lbnQgd2hpY2ggY2FuIGJlIE5VTEwKPiAtLS0KPiAgeGVuL2NvbW1vbi94bWFs
bG9jX3Rsc2YuYyB8IDExNyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKystCj4gIHhlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmggfCAgIDcgKysrCj4gIDIgZmlsZXMg
Y2hhbmdlZCwgMTIyIGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCj4gCj4gZGlmZiAtLWdp
dCBhL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMgYi94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5j
Cj4gaW5kZXggYTU3NjljOS4uMWRlYTEzNyAxMDA2NDQKPiAtLS0gYS94ZW4vY29tbW9uL3htYWxs
b2NfdGxzZi5jCj4gKysrIGIveGVuL2NvbW1vbi94bWFsbG9jX3Rsc2YuYwo+IEBAIC0xMjAsOSAr
MTIwLDExOCBAQCBzdHJ1Y3QgeG1lbV9wb29sIHsKPiAgICAgIGNoYXIgbmFtZVtNQVhfUE9PTF9O
QU1FX0xFTl07Cj4gIH07Cj4gIAo+ICtzdGF0aWMgc3RydWN0IHhtZW1fcG9vbCAqeGVucG9vbDsK
PiArCj4gK3N0YXRpYyBpbmxpbmUgdm9pZCBNQVBQSU5HX0lOU0VSVCh1bnNpZ25lZCBsb25nIHIs
IGludCAqZmwsIGludCAqc2wpOwo+ICsKPiAgLyoKPiAgICogSGVscGluZyBmdW5jdGlvbnMKPiAg
ICovCj4gKyNpZm5kZWYgTkRFQlVHCj4gK3N0YXRpYyBib29sX3QgeG1lbV9wb29sX2NoZWNrX3Np
emUoY29uc3Qgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCwgaW50IGZsLCBpbnQgc2wpCj4gK3sKPiAr
ICAgIGNvbnN0IHN0cnVjdCBiaGRyICpiID0gcG9vbC0+bWF0cml4W2ZsXVtzbF07Cj4gKwo+ICsg
ICAgd2hpbGUgKCBiICkKPiArICAgIHsKPiArICAgICAgICBpbnQgX19mbDsKPiArICAgICAgICBp
bnQgX19zbDsKPiArCj4gKyAgICAgICAgTUFQUElOR19JTlNFUlQoYi0+c2l6ZSwgJl9fZmwsICZf
X3NsKTsKPiArICAgICAgICBpZiAoIF9fZmwgIT0gZmwgfHwgX19zbCAhPSBzbCApCj4gKyAgICAg
ICAgewo+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUgo+ICsgICAgICAgICAgICAgICAg
ICAgInhtZW1fcG9vbDogJXM6IG1pc3BsYWNlZCBibG9jayAlcDoldSAoeyVkLCVkfSAtPiB7JWQs
JWR9KVxuIiwKPiArICAgICAgICAgICAgICAgICAgIHBvb2wtPm5hbWUsIGIsIGItPnNpemUsIGZs
LCBzbCwgX19mbCwgX19zbCk7Cj4gKyAgICAgICAgICAgIHJldHVybiAwOwo+ICsgICAgICAgIH0K
PiArICAgICAgICBiID0gYi0+cHRyLmZyZWVfcHRyLm5leHQ7Cj4gKyAgICB9Cj4gKyAgICByZXR1
cm4gMTsKPiArfQo+ICsKPiArLyoKPiArICogVGhpcyBmdW5jdGlvbiBtdXN0IGJlIGNhbGxlZCBm
cm9tIGEgY29udGV4dCB3aGVyZSBwb29sLT5sb2NrIGlzCj4gKyAqIGFscmVhZHkgYWNxdWlyZWQu
Cj4gKyAqCj4gKyAqIFJldHVybnMgdHJ1ZSBpZiB0aGUgcG9vbCBoYXMgYmVlbiBjb3JydXB0ZWQs
IGZhbHNlIG90aGVyd2lzZQo+ICsgKi8KPiArI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfbG9ja2Vk
KHBvb2wpIF9feG1lbV9wb29sX2NoZWNrX2xvY2tlZChfX0ZJTEVfXywgX19MSU5FX18sIHBvb2wp
Cj4gK3N0YXRpYyBib29sX3QgX194bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKGNvbnN0IGNoYXIgKmZp
bGUsIGludCBsaW5lLCBjb25zdCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ICt7Cj4gKyAgICBp
bnQgaTsKPiArICAgIHN0YXRpYyBib29sX3Qgb25jZSA9IDE7Cj4gKwo+ICsgICAgaWYgKCAhb25j
ZSApCj4gKyAgICAgICAgZ290byBvdXQ7Cj4gKyAgICBmb3IgKCBpID0gMDsgaSA8IFJFQUxfRkxJ
OyBpKysgKQo+ICsgICAgewo+ICsgICAgICAgIGludCBmbCA9IChwb29sLT5mbF9iaXRtYXAgJiAo
MSA8PCBpKSkgPyBpIDogLTE7Cj4gKwo+ICsgICAgICAgIGlmICggZmwgPj0gMCApCj4gKyAgICAg
ICAgewo+ICsgICAgICAgICAgICBpbnQgajsKPiArCj4gKyAgICAgICAgICAgIGlmICggIXBvb2wt
PnNsX2JpdG1hcFtmbF0gKQo+ICsgICAgICAgICAgICB7Cj4gKyAgICAgICAgICAgICAgICBwcmlu
dGsoWEVOTE9HX0VSUgo+ICsgICAgICAgICAgICAgICAgICAgICAgICJ4bWVtX3Bvb2w6ICVzOiB0
aGUgVExTRiBiaXRtYXAgaXMgY29ycnVwdGVkIChub24tZW1wdHkgRkwgd2l0aCBlbXB0eSBTTClc
biIsCj4gKyAgICAgICAgICAgICAgICAgICAgICAgcG9vbC0+bmFtZSk7Cj4gKyAgICAgICAgICAg
ICAgICBfX3dhcm4oZmlsZSwgbGluZSk7Cj4gKyAgICAgICAgICAgICAgICBvbmNlID0gMDsKPiAr
ICAgICAgICAgICAgICAgIGJyZWFrOwo+ICsgICAgICAgICAgICB9Cj4gKyAgICAgICAgICAgIGZv
ciAoIGogPSAwOyBqIDwgTUFYX1NMSTsgaisrICkKPiArICAgICAgICAgICAgewo+ICsgICAgICAg
ICAgICAgICAgaW50IHNsID0gKHBvb2wtPnNsX2JpdG1hcFtmbF0gJiAoMSA8PCBqKSkgPyBqIDog
LTE7Cj4gKwo+ICsgICAgICAgICAgICAgICAgaWYgKCBzbCA8IDAgKQo+ICsgICAgICAgICAgICAg
ICAgICAgIGNvbnRpbnVlOwo+ICsgICAgICAgICAgICAgICAgaWYgKCAhcG9vbC0+bWF0cml4W2Zs
XVtzbF0gKQo+ICsgICAgICAgICAgICAgICAgewo+ICsgICAgICAgICAgICAgICAgICAgIHByaW50
ayhYRU5MT0dfRVJSCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICJ4bWVtX3Bvb2w6ICVz
OiB0aGUgVExTRiBiaXRtYXAgaXMgY29ycnVwdGVkIChtYXRyaXhbJWRdWyVkXSBpcyBOVUxMKVxu
IiwKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgcG9vbC0+bmFtZSwgZmwsIHNsKTsKPiAr
ICAgICAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGluZSk7Cj4gKyAgICAgICAgICAgICAg
ICAgICAgb25jZSA9IDA7Cj4gKyAgICAgICAgICAgICAgICAgICAgYnJlYWs7Cj4gKyAgICAgICAg
ICAgICAgICB9Cj4gKyAgICAgICAgICAgICAgICBpZiAoICF4bWVtX3Bvb2xfY2hlY2tfc2l6ZShw
b29sLCBmbCwgc2wpICkKPiArICAgICAgICAgICAgICAgIHsKPiArICAgICAgICAgICAgICAgICAg
ICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9wb29sOiAlczogdGhlIFRMU0YgY2h1bmsgbWF0cml4
IGlzIGNvcnJ1cHRlZFxuIiwKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgcG9vbC0+bmFt
ZSk7Cj4gKyAgICAgICAgICAgICAgICAgICAgX193YXJuKGZpbGUsIGxpbmUpOwo+ICsgICAgICAg
ICAgICAgICAgICAgIG9uY2UgPSAwOwo+ICsgICAgICAgICAgICAgICAgICAgIGJyZWFrOwo+ICsg
ICAgICAgICAgICAgICAgfQo+ICsgICAgICAgICAgICB9Cj4gKyAgICAgICAgICAgIGlmICggIW9u
Y2UgKQo+ICsgICAgICAgICAgICAgICAgYnJlYWs7Cj4gKyAgICAgICAgfQo+ICsgICAgfQo+ICtv
dXQ6Cj4gKyAgICByZXR1cm4gIW9uY2U7Cj4gK30KPiArCj4gKyNkZWZpbmUgeG1lbV9wb29sX2No
ZWNrX3VubG9ja2VkKHBvb2wpIF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKF9fRklMRV9fLCBf
X0xJTkVfXywgcG9vbCkKPiArc3RhdGljIGJvb2xfdCBfX3htZW1fcG9vbF9jaGVja191bmxvY2tl
ZChjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAr
ewo+ICsgICAgYm9vbF90IG9vcHM7Cj4gKwo+ICsgICAgc3Bpbl9sb2NrKCZwb29sLT5sb2NrKTsK
PiArICAgIG9vcHMgPSBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoZmlsZSwgbGluZSwgcG9vbCk7
Cj4gKyAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7Cj4gKyAgICByZXR1cm4gb29wczsKPiAr
fQo+ICsKPiArYm9vbF90IF9feG1lbV9wb29sX2NoZWNrKGNvbnN0IGNoYXIgKmZpbGUsIGludCBs
aW5lLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ICt7Cj4gKyAgICByZXR1cm4gX194bWVtX3Bv
b2xfY2hlY2tfdW5sb2NrZWQoZmlsZSwgbGluZSwgcG9vbCA/OiB4ZW5wb29sKTsKPiArfQo+ICsj
ZWxzZQo+ICsjZGVmaW5lIHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCkgKCh2b2lkKShwb29s
KSkKPiArI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQocG9vbCkgKCh2b2lkKShwb29s
KSkKPiArI2VuZGlmCj4gIAo+ICAvKioKPiAgICogUmV0dXJucyBpbmRleGVzIChmbCwgc2wpIG9m
IHRoZSBsaXN0IHVzZWQgdG8gc2VydmUgcmVxdWVzdCBvZiBzaXplIHIKPiBAQCAtMzgxLDYgKzQ5
MCw4IEBAIHZvaWQgKnhtZW1fcG9vbF9hbGxvYyh1bnNpZ25lZCBsb25nIHNpemUsIHN0cnVjdCB4
bWVtX3Bvb2wgKnBvb2wpCj4gICAgICBpbnQgZmwsIHNsOwo+ICAgICAgdW5zaWduZWQgbG9uZyB0
bXBfc2l6ZTsKPiAgCj4gKyAgICB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQocG9vbCk7Cj4gKwo+
ICAgICAgaWYgKCBwb29sLT5pbml0X3JlZ2lvbiA9PSBOVUxMICkKPiAgICAgIHsKPiAgICAgICAg
ICBpZiAoIChyZWdpb24gPSBwb29sLT5nZXRfbWVtKHBvb2wtPmluaXRfc2l6ZSkpID09IE5VTEwg
KQo+IEBAIC00NDIsMTEgKzU1MywxMyBAQCB2b2lkICp4bWVtX3Bvb2xfYWxsb2ModW5zaWduZWQg
bG9uZyBzaXplLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ICAKPiAgICAgIHBvb2wtPnVzZWRf
c2l6ZSArPSAoYi0+c2l6ZSAmIEJMT0NLX1NJWkVfTUFTSykgKyBCSERSX09WRVJIRUFEOwo+ICAK
PiArICAgIHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCk7Cj4gICAgICBzcGluX3VubG9jaygm
cG9vbC0+bG9jayk7Cj4gICAgICByZXR1cm4gKHZvaWQgKiliLT5wdHIuYnVmZmVyOwo+ICAKPiAg
ICAgIC8qIEZhaWxlZCBhbGxvYyAqLwo+ICAgb3V0X2xvY2tlZDoKPiArICAgIHhtZW1fcG9vbF9j
aGVja19sb2NrZWQocG9vbCk7Cj4gICAgICBzcGluX3VubG9jaygmcG9vbC0+bG9jayk7Cj4gIAo+
ICAgb3V0Ogo+IEBAIC00NjQsNiArNTc3LDcgQEAgdm9pZCB4bWVtX3Bvb2xfZnJlZSh2b2lkICpw
dHIsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gICAgICBiID0gKHN0cnVjdCBiaGRyICopKChj
aGFyICopIHB0ciAtIEJIRFJfT1ZFUkhFQUQpOwo+ICAKPiAgICAgIHNwaW5fbG9jaygmcG9vbC0+
bG9jayk7Cj4gKyAgICB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpOwo+ICAgICAgYi0+c2l6
ZSB8PSBGUkVFX0JMT0NLOwo+ICAgICAgcG9vbC0+dXNlZF9zaXplIC09IChiLT5zaXplICYgQkxP
Q0tfU0laRV9NQVNLKSArIEJIRFJfT1ZFUkhFQUQ7Cj4gICAgICBiLT5wdHIuZnJlZV9wdHIgPSAo
c3RydWN0IGZyZWVfcHRyKSB7IE5VTEwsIE5VTEx9Owo+IEBAIC01MDAsNiArNjE0LDcgQEAgdm9p
ZCB4bWVtX3Bvb2xfZnJlZSh2b2lkICpwdHIsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gICAg
ICB0bXBfYi0+c2l6ZSB8PSBQUkVWX0ZSRUU7Cj4gICAgICB0bXBfYi0+cHJldl9oZHIgPSBiOwo+
ICAgb3V0Ogo+ICsgICAgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKTsKPiAgICAgIHNwaW5f
dW5sb2NrKCZwb29sLT5sb2NrKTsKPiAgfQo+ICAKPiBAQCAtNTEyLDggKzYyNyw2IEBAIGludCB4
bWVtX3Bvb2xfbWF4YWxsb2Moc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAgICogR2x1ZSBmb3Ig
eG1hbGxvYygpLgo+ICAgKi8KPiAgCj4gLXN0YXRpYyBzdHJ1Y3QgeG1lbV9wb29sICp4ZW5wb29s
Owo+IC0KPiAgc3RhdGljIHZvaWQgKnhtYWxsb2NfcG9vbF9nZXQodW5zaWduZWQgbG9uZyBzaXpl
KQo+ICB7Cj4gICAgICBBU1NFUlQoc2l6ZSA9PSBQQUdFX1NJWkUpOwo+IGRpZmYgLS1naXQgYS94
ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oIGIveGVuL2luY2x1ZGUveGVuL3htYWxsb2MuaAo+IGlu
ZGV4IDI0YTk5YWMuLmFkNDg5MzAgMTAwNjQ0Cj4gLS0tIGEveGVuL2luY2x1ZGUveGVuL3htYWxs
b2MuaAo+ICsrKyBiL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKPiBAQCAtMTIzLDQgKzEyMywx
MSBAQCB1bnNpZ25lZCBsb25nIHhtZW1fcG9vbF9nZXRfdXNlZF9zaXplKHN0cnVjdCB4bWVtX3Bv
b2wgKnBvb2wpOwo+ICAgKi8KPiAgdW5zaWduZWQgbG9uZyB4bWVtX3Bvb2xfZ2V0X3RvdGFsX3Np
emUoc3RydWN0IHhtZW1fcG9vbCAqcG9vbCk7Cj4gIAo+ICsjaWZuZGVmIE5ERUJVRwo+ICsjZGVm
aW5lIHhtZW1fcG9vbF9jaGVjayhwb29sKSBfX3htZW1fcG9vbF9jaGVjayhfX0ZJTEVfXywgX19M
SU5FX18sIHBvb2wpCj4gK2Jvb2xfdCBfX3htZW1fcG9vbF9jaGVjayhjb25zdCBjaGFyICpmaWxl
LCBpbnQgbGluZSwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCk7Cj4gKyNlbHNlCj4gKyNkZWZpbmUg
eG1lbV9wb29sX2NoZWNrKHBvb2wpICgodm9pZCkwKQo+ICsjZW5kaWYKPiArCj4gICNlbmRpZiAv
KiBfX1hNQUxMT0NfSF9fICovCgooc2hvdWxkJ3ZlIGNyZWF0ZWQgYSBzZXJpZXMpCgpUaGlzIHBh
dGNoIGRlcGVuZHMgb246Cmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9hcmNoaXZlcy9odG1s
L3hlbi1kZXZlbC8yMDE0LTEyL21zZzAxMTM1Lmh0bWwKClRoYW4geW91LAoKLS0gCk1paGFpIERP
TsiaVQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Dec 10 12:45:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12: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 1XygdH-0004iI-Eb; Wed, 10 Dec 2014 12:44:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XygdF-0004iD-UE
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 12:44:42 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	D1/E7-02699-83048845; Wed, 10 Dec 2014 12:44:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418215478!14187013!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 12391 invoked from network); 10 Dec 2014 12:44:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 12:44:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202794770"
Message-ID: <1418215453.3505.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 12:44:13 +0000
In-Reply-To: <1413323416-21778-4-git-send-email-wei.liu2@citrix.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-4-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 03/11] ts-debian-install: rename
 cfg_xend to cfg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> ... as this config file is just a config file in general, not strictly a
> Xend format config file.
> 
> Signed-off-by: Wei Liu <wei.liu2@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 Dec 10 12:45:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12: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 1XygdH-0004iI-Eb; Wed, 10 Dec 2014 12:44:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XygdF-0004iD-UE
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 12:44:42 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	D1/E7-02699-83048845; Wed, 10 Dec 2014 12:44:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418215478!14187013!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 12391 invoked from network); 10 Dec 2014 12:44:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 12:44:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202794770"
Message-ID: <1418215453.3505.21.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 12:44:13 +0000
In-Reply-To: <1413323416-21778-4-git-send-email-wei.liu2@citrix.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-4-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 03/11] ts-debian-install: rename
 cfg_xend to cfg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> ... as this config file is just a config file in general, not strictly a
> Xend format config file.
> 
> Signed-off-by: Wei Liu <wei.liu2@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 Dec 10 12:54:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12:54:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XygmR-0004xb-Iy; Wed, 10 Dec 2014 12:54: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 1XygmP-0004xW-Lb
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 12:54:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8A/94-09842-07248845; Wed, 10 Dec 2014 12:54:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418216047!14651705!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 28905 invoked from network); 10 Dec 2014 12:54:08 -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;
	10 Dec 2014 12:54:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202394149"
Message-ID: <1418216045.3505.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 12:54:05 +0000
In-Reply-To: <1413323416-21778-5-git-send-email-wei.liu2@citrix.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-5-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/11] overlay: update
 overlay/etc/grub.d/20_linux_xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-14 at 22:50 +0100, Wei Liu wrote:
> This file was created to work around Debian bug #633127.
> 
> According to Debian bug tracker [0], this bug is fixed in Wheezy. As
> we're now using Wheezy in OSSTest we can safely remove this overlay
> file.
> 
> Also add a note to reference #633127 above grub2 setup function, in case
> someone trips over #633127.
> 
> As we're now using Wheezy in production, update this file to Wheezy's
> version and take care of Debian bug #690538 and GRUB bug #43420.

When reference bugs it would be useful to include the bug title here so
the reader doesn't have to go and look it up.

#690538 relates to providing an option to remove the submenus. Please
can the changelog explain why that is relevant to us.

Did you fix it by removing/reverting the submenu support altogether, as
opposed to e.g. importing the patch from Eric Fischer in the bug report?
I don't see stuff which I'd expect if you had applied the patch. I think
it would be worth spelling out in a bit more detail what the changes
you've made to the baseline for each bug were.

I suppose constructing overlay/etc/grub.d/20_linux_xen from a baseline
unmodified version (checked in, not retrieved from the host) and a
mini-patch-series (also checked in) on the fly is over complexifying
things?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 12:54:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12:54:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XygmR-0004xb-Iy; Wed, 10 Dec 2014 12:54: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 1XygmP-0004xW-Lb
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 12:54:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8A/94-09842-07248845; Wed, 10 Dec 2014 12:54:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418216047!14651705!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 28905 invoked from network); 10 Dec 2014 12:54:08 -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;
	10 Dec 2014 12:54:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202394149"
Message-ID: <1418216045.3505.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 12:54:05 +0000
In-Reply-To: <1413323416-21778-5-git-send-email-wei.liu2@citrix.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-5-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/11] overlay: update
 overlay/etc/grub.d/20_linux_xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-14 at 22:50 +0100, Wei Liu wrote:
> This file was created to work around Debian bug #633127.
> 
> According to Debian bug tracker [0], this bug is fixed in Wheezy. As
> we're now using Wheezy in OSSTest we can safely remove this overlay
> file.
> 
> Also add a note to reference #633127 above grub2 setup function, in case
> someone trips over #633127.
> 
> As we're now using Wheezy in production, update this file to Wheezy's
> version and take care of Debian bug #690538 and GRUB bug #43420.

When reference bugs it would be useful to include the bug title here so
the reader doesn't have to go and look it up.

#690538 relates to providing an option to remove the submenus. Please
can the changelog explain why that is relevant to us.

Did you fix it by removing/reverting the submenu support altogether, as
opposed to e.g. importing the patch from Eric Fischer in the bug report?
I don't see stuff which I'd expect if you had applied the patch. I think
it would be worth spelling out in a bit more detail what the changes
you've made to the baseline for each bug were.

I suppose constructing overlay/etc/grub.d/20_linux_xen from a baseline
unmodified version (checked in, not retrieved from the host) and a
mini-patch-series (also checked in) on the fly is over complexifying
things?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 12:56:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12: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 1Xygp2-00053n-4K; Wed, 10 Dec 2014 12:56:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xygp1-00053i-Kt
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 12:56:51 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	3B/A5-02954-31348845; Wed, 10 Dec 2014 12:56:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418216206!14195618!1
X-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 21800 invoked from network); 10 Dec 2014 12:56:47 -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; 10 Dec 2014 12:56:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 12:56:46 +0000
Message-Id: <5488511B020000780004E8CB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 12:56:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Mihai=20Don=C8=9Bu?=" <mdontu@bitdefender.com>
References: <1418213638-14896-1-git-send-email-mdontu@bitdefender.com>
In-Reply-To: <1418213638-14896-1-git-send-email-mdontu@bitdefender.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, tim@xen.org, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 13:13, <mdontu@bitdefender.com> wrote:
> +#define xmem_pool_check_locked(pool) __xmem_pool_check_locked(__FILE__, __LINE__, pool)
> +static bool_t __xmem_pool_check_locked(const char *file, int line, const struct xmem_pool *pool)

Long lines.

> +{
> +    int i;

unsigned int

> +    static bool_t once = 1;
> +
> +    if ( !once )
> +        goto out;
> +    for ( i = 0; i < REAL_FLI; i++ )
> +    {
> +        int fl = (pool->fl_bitmap & (1 << i)) ? i : -1;
> +
> +        if ( fl >= 0 )
> +        {
> +            int j;

unsigned int

> +
> +            if ( !pool->sl_bitmap[fl] )
> +            {
> +                printk(XENLOG_ERR
> +                       "xmem_pool: %s: the TLSF bitmap is corrupted (non-empty FL with empty SL)\n",

For the sake of brevity: "...: TLSF bitmap corrupt (...)\n" (please follow
advice given - as for an earlier message - throughout a patch).

> +                       pool->name);
> +                __warn(file, line);
> +                once = 0;
> +                break;
> +            }
> +            for ( j = 0; j < MAX_SLI; j++ )
> +            {
> +                int sl = (pool->sl_bitmap[fl] & (1 << j)) ? j : -1;
> +
> +                if ( sl < 0 )
> +                    continue;
> +                if ( !pool->matrix[fl][sl] )
> +                {
> +                    printk(XENLOG_ERR
> +                           "xmem_pool: %s: the TLSF bitmap is corrupted (matrix[%d][%d] is NULL)\n",
> +                           pool->name, fl, sl);
> +                    __warn(file, line);
> +                    once = 0;
> +                    break;
> +                }
> +                if ( !xmem_pool_check_size(pool, fl, sl) )
> +                {
> +                    printk(XENLOG_ERR "xmem_pool: %s: the TLSF chunk matrix is corrupted\n",
> +                           pool->name);
> +                    __warn(file, line);
> +                    once = 0;
> +                    break;
> +                }
> +            }
> +            if ( !once )
> +                break;
> +        }
> +    }
> +out:

Label should be indented by one space; whether a label is warranted
here is questionable though.

I thought I gave all these comments on v2 already, but it looks like
I accidentally lost them while reducing quoted text.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 12:56:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 12: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 1Xygp2-00053n-4K; Wed, 10 Dec 2014 12:56:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xygp1-00053i-Kt
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 12:56:51 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	3B/A5-02954-31348845; Wed, 10 Dec 2014 12:56:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418216206!14195618!1
X-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 21800 invoked from network); 10 Dec 2014 12:56:47 -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; 10 Dec 2014 12:56:47 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 10 Dec 2014 12:56:46 +0000
Message-Id: <5488511B020000780004E8CB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 10 Dec 2014 12:56:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Mihai=20Don=C8=9Bu?=" <mdontu@bitdefender.com>
References: <1418213638-14896-1-git-send-email-mdontu@bitdefender.com>
In-Reply-To: <1418213638-14896-1-git-send-email-mdontu@bitdefender.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, tim@xen.org, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 13:13, <mdontu@bitdefender.com> wrote:
> +#define xmem_pool_check_locked(pool) __xmem_pool_check_locked(__FILE__, __LINE__, pool)
> +static bool_t __xmem_pool_check_locked(const char *file, int line, const struct xmem_pool *pool)

Long lines.

> +{
> +    int i;

unsigned int

> +    static bool_t once = 1;
> +
> +    if ( !once )
> +        goto out;
> +    for ( i = 0; i < REAL_FLI; i++ )
> +    {
> +        int fl = (pool->fl_bitmap & (1 << i)) ? i : -1;
> +
> +        if ( fl >= 0 )
> +        {
> +            int j;

unsigned int

> +
> +            if ( !pool->sl_bitmap[fl] )
> +            {
> +                printk(XENLOG_ERR
> +                       "xmem_pool: %s: the TLSF bitmap is corrupted (non-empty FL with empty SL)\n",

For the sake of brevity: "...: TLSF bitmap corrupt (...)\n" (please follow
advice given - as for an earlier message - throughout a patch).

> +                       pool->name);
> +                __warn(file, line);
> +                once = 0;
> +                break;
> +            }
> +            for ( j = 0; j < MAX_SLI; j++ )
> +            {
> +                int sl = (pool->sl_bitmap[fl] & (1 << j)) ? j : -1;
> +
> +                if ( sl < 0 )
> +                    continue;
> +                if ( !pool->matrix[fl][sl] )
> +                {
> +                    printk(XENLOG_ERR
> +                           "xmem_pool: %s: the TLSF bitmap is corrupted (matrix[%d][%d] is NULL)\n",
> +                           pool->name, fl, sl);
> +                    __warn(file, line);
> +                    once = 0;
> +                    break;
> +                }
> +                if ( !xmem_pool_check_size(pool, fl, sl) )
> +                {
> +                    printk(XENLOG_ERR "xmem_pool: %s: the TLSF chunk matrix is corrupted\n",
> +                           pool->name);
> +                    __warn(file, line);
> +                    once = 0;
> +                    break;
> +                }
> +            }
> +            if ( !once )
> +                break;
> +        }
> +    }
> +out:

Label should be indented by one space; whether a label is warranted
here is questionable though.

I thought I gave all these comments on v2 already, but it looks like
I accidentally lost them while reducing quoted text.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:05:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XygxN-0005kH-44; Wed, 10 Dec 2014 13:05:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XygxL-0005kC-DL
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:05:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	CA/FB-09842-61548845; Wed, 10 Dec 2014 13:05:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418216724!14614631!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 13572 invoked from network); 10 Dec 2014 13:05:25 -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;
	10 Dec 2014 13:05:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202399033"
Message-ID: <1418216722.3505.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 13:05:22 +0000
In-Reply-To: <1413323416-21778-7-git-send-email-wei.liu2@citrix.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-7-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 06/11] ts-xen-build: build with
 XSM support if requested
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Looks like Ian J acked v2 in
<21559.64364.468553.506173@mariner.uk.xensource.com>.


> ---
>  ts-xen-build |   12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/ts-xen-build b/ts-xen-build
> index 661f186..390c114 100755
> --- a/ts-xen-build
> +++ b/ts-xen-build
> @@ -27,6 +27,8 @@ tsreadconfig();
>  selectbuildhost(\@ARGV);
>  # remaining arguments are passed as targets to "make"
>  builddirsprops();
> +
> +my $enable_xsm = $r{enable_xsm} =~ m/y/ ? 1 : 0;

Existing boolean runvars (enable_ovmf, enable_xend) appear to use
true/false (which still need laundering into Perl booleans). Using y/n
made sense when you were poking it straight into XSM_ENABLE, but if you
are going to have to translate it there anyway (into $build_xsm) you may
as well go for consistency.

>      
>  sub checkout () {
>      prepbuilddirs();
> @@ -34,6 +36,7 @@ sub checkout () {
>      build_clone($ho, 'xen', $builddir, 'xen');
>  
>      my $debug_build = $r{xen_build_debug} || 'y';
> +    my $build_xsm = $enable_xsm ? 'y' : 'n';
>  
>      # Do not set this unless you know what you are doing. This arm
>      # option makes the build specific to a particular type of
> @@ -47,6 +50,7 @@ sub checkout () {
>          cd $builddir/xen
>  	>.config
>  	echo >>.config debug=$debug_build
> +	echo >>.config XSM_ENABLE=$build_xsm
>  	echo >>.config GIT_HTTP=y
>  	echo >>.config LIBLEAFDIR_x86_64=lib
>  	echo >>.config QEMU_REMOTE='$r{tree_qemu}'
> @@ -114,6 +118,14 @@ END
>      buildcmd_stamped_logged(9000, 'build', '',<<END,'');
>              $make_prefix make $makeflags @ARGV
>  END
> +
> +    if ($enable_xsm) {
> +	my $xen_version = target_cmd_output_root($ho, <<END, 30);
> +	    cd $builddir/xen
> +	    $make_prefix make xenversion
> +END
> +        store_runvar("flaskpolicy", "xenpolicy-" . $xen_version);
> +    }
>  }
>  
>  sub collectversions () {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:05:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XygxN-0005kH-44; Wed, 10 Dec 2014 13:05:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XygxL-0005kC-DL
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:05:27 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	CA/FB-09842-61548845; Wed, 10 Dec 2014 13:05:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418216724!14614631!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 13572 invoked from network); 10 Dec 2014 13:05:25 -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;
	10 Dec 2014 13:05:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202399033"
Message-ID: <1418216722.3505.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 13:05:22 +0000
In-Reply-To: <1413323416-21778-7-git-send-email-wei.liu2@citrix.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-7-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 06/11] ts-xen-build: build with
 XSM support if requested
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Looks like Ian J acked v2 in
<21559.64364.468553.506173@mariner.uk.xensource.com>.


> ---
>  ts-xen-build |   12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/ts-xen-build b/ts-xen-build
> index 661f186..390c114 100755
> --- a/ts-xen-build
> +++ b/ts-xen-build
> @@ -27,6 +27,8 @@ tsreadconfig();
>  selectbuildhost(\@ARGV);
>  # remaining arguments are passed as targets to "make"
>  builddirsprops();
> +
> +my $enable_xsm = $r{enable_xsm} =~ m/y/ ? 1 : 0;

Existing boolean runvars (enable_ovmf, enable_xend) appear to use
true/false (which still need laundering into Perl booleans). Using y/n
made sense when you were poking it straight into XSM_ENABLE, but if you
are going to have to translate it there anyway (into $build_xsm) you may
as well go for consistency.

>      
>  sub checkout () {
>      prepbuilddirs();
> @@ -34,6 +36,7 @@ sub checkout () {
>      build_clone($ho, 'xen', $builddir, 'xen');
>  
>      my $debug_build = $r{xen_build_debug} || 'y';
> +    my $build_xsm = $enable_xsm ? 'y' : 'n';
>  
>      # Do not set this unless you know what you are doing. This arm
>      # option makes the build specific to a particular type of
> @@ -47,6 +50,7 @@ sub checkout () {
>          cd $builddir/xen
>  	>.config
>  	echo >>.config debug=$debug_build
> +	echo >>.config XSM_ENABLE=$build_xsm
>  	echo >>.config GIT_HTTP=y
>  	echo >>.config LIBLEAFDIR_x86_64=lib
>  	echo >>.config QEMU_REMOTE='$r{tree_qemu}'
> @@ -114,6 +118,14 @@ END
>      buildcmd_stamped_logged(9000, 'build', '',<<END,'');
>              $make_prefix make $makeflags @ARGV
>  END
> +
> +    if ($enable_xsm) {
> +	my $xen_version = target_cmd_output_root($ho, <<END, 30);
> +	    cd $builddir/xen
> +	    $make_prefix make xenversion
> +END
> +        store_runvar("flaskpolicy", "xenpolicy-" . $xen_version);
> +    }
>  }
>  
>  sub collectversions () {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:12:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13: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 1Xyh49-0005ur-Hi; Wed, 10 Dec 2014 13:12: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 1Xyh48-0005um-3y
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:12:28 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	DA/37-17735-BB648845; Wed, 10 Dec 2014 13:12:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418217145!9914821!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3313 invoked from network); 10 Dec 2014 13:12:26 -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 Dec 2014 13:12:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202806619"
Message-ID: <1418217143.3505.39.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 13:12:23 +0000
In-Reply-To: <1413323416-21778-8-git-send-email-wei.liu2@citrix.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-8-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 07/11] mfi-common: create
	build-$arch-xsm job
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-14 at 22:50 +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  mfi-common |   23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/mfi-common b/mfi-common
> index 5c4f5d5..e772086 100644
> --- a/mfi-common
> +++ b/mfi-common
> @@ -41,6 +41,19 @@ branch_wants_rumpkernel_tests () {
>    esac
>  }
>  
> +xenbranch_wants_xsm_tests () {
> +    # Test XSM from 4.5 onwards
> +    case "$xenbranch" in
> +    xen-3.*-testing) echo "n";;
> +    xen-4.0-testing) echo "n";;
> +    xen-4.1-testing) echo "n";;
> +    xen-4.2-testing) echo "n";;
> +    xen-4.3-testing) echo "n";;
> +    xen-4.4-testing) echo "n";;
> +    *) echo "n y";

Did you mean just "y" here, or is something very subtle going on?

Oh I see, you run over the result of this as a list with for. Sneaky!

I think you should name it something like xenbranch_xsm_variants or
something else which doesn't make the reader expect it to return a
boolean.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:12:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13: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 1Xyh49-0005ur-Hi; Wed, 10 Dec 2014 13:12: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 1Xyh48-0005um-3y
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:12:28 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	DA/37-17735-BB648845; Wed, 10 Dec 2014 13:12:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418217145!9914821!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3313 invoked from network); 10 Dec 2014 13:12:26 -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 Dec 2014 13:12:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202806619"
Message-ID: <1418217143.3505.39.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 13:12:23 +0000
In-Reply-To: <1413323416-21778-8-git-send-email-wei.liu2@citrix.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-8-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 07/11] mfi-common: create
	build-$arch-xsm job
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-14 at 22:50 +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  mfi-common |   23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/mfi-common b/mfi-common
> index 5c4f5d5..e772086 100644
> --- a/mfi-common
> +++ b/mfi-common
> @@ -41,6 +41,19 @@ branch_wants_rumpkernel_tests () {
>    esac
>  }
>  
> +xenbranch_wants_xsm_tests () {
> +    # Test XSM from 4.5 onwards
> +    case "$xenbranch" in
> +    xen-3.*-testing) echo "n";;
> +    xen-4.0-testing) echo "n";;
> +    xen-4.1-testing) echo "n";;
> +    xen-4.2-testing) echo "n";;
> +    xen-4.3-testing) echo "n";;
> +    xen-4.4-testing) echo "n";;
> +    *) echo "n y";

Did you mean just "y" here, or is something very subtle going on?

Oh I see, you run over the result of this as a list with for. Sneaky!

I think you should name it something like xenbranch_xsm_variants or
something else which doesn't make the reader expect it to return a
boolean.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:15:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13: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 1Xyh6u-00064c-3i; Wed, 10 Dec 2014 13:15: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 1Xyh6s-00064Q-0W
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:15:18 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	4C/8F-25547-56748845; Wed, 10 Dec 2014 13:15:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418217315!12369211!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 32381 invoked from network); 10 Dec 2014 13:15:16 -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 Dec 2014 13:15:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202808000"
Message-ID: <1418217313.3505.41.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 13:15:13 +0000
In-Reply-To: <1413323416-21778-11-git-send-email-wei.liu2@citrix.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-11-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 10/11] ts-xen-install: install
 Xen with XSM support if requested
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  ts-xen-install |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/ts-xen-install b/ts-xen-install
> index 4d34d1f..2e2fcbc 100755
> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -46,6 +46,8 @@ if (@ARGV and $ARGV[0] eq '--check') {
>  
>  our $ho;
>  
> +my $enable_xsm = $r{enable_xsm} =~ m/y/ ? 1 : 0;
> +
>  my %distpath;
>  
>  sub packages () {
> @@ -171,7 +173,7 @@ sub setupboot () {
>      }
>  
>      my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
> -    debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
> +    debian_boot_setup($ho, $want_kernver, $enable_xsm, $xenhopt, \%distpath, \@hooks);

Doesn't this have to be in the same patch as the one which adds the new
parameter in the function declaration? Or at least that patch needs to
hardcode a false until now.

(not sure we care much about bisectability in osstest, Ian?)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:15:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13: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 1Xyh6u-00064c-3i; Wed, 10 Dec 2014 13:15: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 1Xyh6s-00064Q-0W
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:15:18 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	4C/8F-25547-56748845; Wed, 10 Dec 2014 13:15:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418217315!12369211!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 32381 invoked from network); 10 Dec 2014 13:15:16 -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 Dec 2014 13:15:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202808000"
Message-ID: <1418217313.3505.41.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 13:15:13 +0000
In-Reply-To: <1413323416-21778-11-git-send-email-wei.liu2@citrix.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-11-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 10/11] ts-xen-install: install
 Xen with XSM support if requested
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  ts-xen-install |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/ts-xen-install b/ts-xen-install
> index 4d34d1f..2e2fcbc 100755
> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -46,6 +46,8 @@ if (@ARGV and $ARGV[0] eq '--check') {
>  
>  our $ho;
>  
> +my $enable_xsm = $r{enable_xsm} =~ m/y/ ? 1 : 0;
> +
>  my %distpath;
>  
>  sub packages () {
> @@ -171,7 +173,7 @@ sub setupboot () {
>      }
>  
>      my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
> -    debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
> +    debian_boot_setup($ho, $want_kernver, $enable_xsm, $xenhopt, \%distpath, \@hooks);

Doesn't this have to be in the same patch as the one which adds the new
parameter in the function declaration? Or at least that patch needs to
hardcode a false until now.

(not sure we care much about bisectability in osstest, Ian?)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:28:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhJF-0006mG-HI; Wed, 10 Dec 2014 13:28: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 1XyhJE-0006mB-7n
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:28:04 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	6F/EF-17694-36A48845; Wed, 10 Dec 2014 13:28:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418218081!12224193!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9298 invoked from network); 10 Dec 2014 13:28: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;
	10 Dec 2014 13:28:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202408855"
Message-ID: <1418218080.3505.50.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 13:28:00 +0000
In-Reply-To: <1413323416-21778-12-git-send-email-wei.liu2@citrix.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-12-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 11/11] mfi-common,
 make-flight: create XSM test jobs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-14 at 22:50 +0100, Wei Liu wrote:
> +test_matrix_do_one () {
> +
> +  test_xsm=$(xenbranch_wants_xsm_tests)
> +
> +  # Basic PV Linux test with xl
> +  for xsm in $test_xsm ; do
> +    do_pv_linux_xl_test_one $xsm
> +  done

Perhaps push this down into do_pv_debian_tests which contains this loop
and calls down to do_pv_debian_test_one (similar to the
do_hvm_debian_tests setup).

Should we run an xsm test for libvirt too -- I don't see why not, in
that case do_pv_debian_tests would call do_pv_debian_test_one twice and
pass the toolstack as a parameter.

>  @@ -342,13 +361,13 @@ test_matrix_do_one () {
>      do_hvm_win7_x64_tests
>      do_hvm_rhel6_tests
>  
> -    do_hvm_debian_tests
> +    do_hvm_debian_tests $test_xsm

The parameter here should be quoted (and do_hvm_debian_tests should use
$1), but IMHO it would be better to have do_hvm_debian_tests call
xenbranch_wants_xsm_tests itself and loop on the result.

> diff --git a/mfi-common b/mfi-common
> index e772086..a81dfba 100644
> --- a/mfi-common
> +++ b/mfi-common
> @@ -267,9 +267,16 @@ job_create_test () {
>    local toolstack=$1; shift
>    local xenarch=$1; shift
>    local dom0arch=$1; shift
> +  local xsm=$1; shift

Can you detect enable_xsm=y in the remaining runvars (in $@ at this
point) and enable xsm based on that, instead of requiring an additional
parameter to be added to every caller?

	for rv in $@ ; do
            case $rv in
                enable_xsm=y) xsm_prefix="-xsm";;
            esac
        done

Is one way I'd try.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:28:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhJF-0006mG-HI; Wed, 10 Dec 2014 13:28: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 1XyhJE-0006mB-7n
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:28:04 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	6F/EF-17694-36A48845; Wed, 10 Dec 2014 13:28:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418218081!12224193!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9298 invoked from network); 10 Dec 2014 13:28: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;
	10 Dec 2014 13:28:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202408855"
Message-ID: <1418218080.3505.50.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 13:28:00 +0000
In-Reply-To: <1413323416-21778-12-git-send-email-wei.liu2@citrix.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-12-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 11/11] mfi-common,
 make-flight: create XSM test jobs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-14 at 22:50 +0100, Wei Liu wrote:
> +test_matrix_do_one () {
> +
> +  test_xsm=$(xenbranch_wants_xsm_tests)
> +
> +  # Basic PV Linux test with xl
> +  for xsm in $test_xsm ; do
> +    do_pv_linux_xl_test_one $xsm
> +  done

Perhaps push this down into do_pv_debian_tests which contains this loop
and calls down to do_pv_debian_test_one (similar to the
do_hvm_debian_tests setup).

Should we run an xsm test for libvirt too -- I don't see why not, in
that case do_pv_debian_tests would call do_pv_debian_test_one twice and
pass the toolstack as a parameter.

>  @@ -342,13 +361,13 @@ test_matrix_do_one () {
>      do_hvm_win7_x64_tests
>      do_hvm_rhel6_tests
>  
> -    do_hvm_debian_tests
> +    do_hvm_debian_tests $test_xsm

The parameter here should be quoted (and do_hvm_debian_tests should use
$1), but IMHO it would be better to have do_hvm_debian_tests call
xenbranch_wants_xsm_tests itself and loop on the result.

> diff --git a/mfi-common b/mfi-common
> index e772086..a81dfba 100644
> --- a/mfi-common
> +++ b/mfi-common
> @@ -267,9 +267,16 @@ job_create_test () {
>    local toolstack=$1; shift
>    local xenarch=$1; shift
>    local dom0arch=$1; shift
> +  local xsm=$1; shift

Can you detect enable_xsm=y in the remaining runvars (in $@ at this
point) and enable xsm based on that, instead of requiring an additional
parameter to be added to every caller?

	for rv in $@ ; do
            case $rv in
                enable_xsm=y) xsm_prefix="-xsm";;
            esac
        done

Is one way I'd try.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:33:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:33:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhO7-00076l-As; Wed, 10 Dec 2014 13:33: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 1XyhO6-000756-9x
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:33:06 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	CF/2D-05632-19B48845; Wed, 10 Dec 2014 13:33:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418218382!12329501!1
X-Originating-IP: [66.165.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 24478 invoked from network); 10 Dec 2014 13:33:04 -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;
	10 Dec 2014 13:33:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202815954"
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.210.2;
	Wed, 10 Dec 2014 08:32: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 1XyhNw-0008IL-L1;
	Wed, 10 Dec 2014 13:32:56 +0000
Date: Wed, 10 Dec 2014 13:32:56 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210133256.GA19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-8-git-send-email-wei.liu2@citrix.com>
	<1418217143.3505.39.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418217143.3505.39.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>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 07/11] mfi-common: create
	build-$arch-xsm job
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 01:12:23PM +0000, Ian Campbell wrote:
> On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  mfi-common |   23 ++++++++++++++++++++++-
> >  1 file changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mfi-common b/mfi-common
> > index 5c4f5d5..e772086 100644
> > --- a/mfi-common
> > +++ b/mfi-common
> > @@ -41,6 +41,19 @@ branch_wants_rumpkernel_tests () {
> >    esac
> >  }
> >  
> > +xenbranch_wants_xsm_tests () {
> > +    # Test XSM from 4.5 onwards
> > +    case "$xenbranch" in
> > +    xen-3.*-testing) echo "n";;
> > +    xen-4.0-testing) echo "n";;
> > +    xen-4.1-testing) echo "n";;
> > +    xen-4.2-testing) echo "n";;
> > +    xen-4.3-testing) echo "n";;
> > +    xen-4.4-testing) echo "n";;
> > +    *) echo "n y";
> 
> Did you mean just "y" here, or is something very subtle going on?
> 
> Oh I see, you run over the result of this as a list with for. Sneaky!
> 

Ian J's suggestion.

> I think you should name it something like xenbranch_xsm_variants or
> something else which doesn't make the reader expect it to return a
> boolean.
> 

Ack.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:33:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:33:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhO7-00076l-As; Wed, 10 Dec 2014 13:33: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 1XyhO6-000756-9x
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:33:06 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	CF/2D-05632-19B48845; Wed, 10 Dec 2014 13:33:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418218382!12329501!1
X-Originating-IP: [66.165.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 24478 invoked from network); 10 Dec 2014 13:33:04 -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;
	10 Dec 2014 13:33:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202815954"
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.210.2;
	Wed, 10 Dec 2014 08:32: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 1XyhNw-0008IL-L1;
	Wed, 10 Dec 2014 13:32:56 +0000
Date: Wed, 10 Dec 2014 13:32:56 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210133256.GA19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-8-git-send-email-wei.liu2@citrix.com>
	<1418217143.3505.39.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418217143.3505.39.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>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 07/11] mfi-common: create
	build-$arch-xsm job
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 01:12:23PM +0000, Ian Campbell wrote:
> On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  mfi-common |   23 ++++++++++++++++++++++-
> >  1 file changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mfi-common b/mfi-common
> > index 5c4f5d5..e772086 100644
> > --- a/mfi-common
> > +++ b/mfi-common
> > @@ -41,6 +41,19 @@ branch_wants_rumpkernel_tests () {
> >    esac
> >  }
> >  
> > +xenbranch_wants_xsm_tests () {
> > +    # Test XSM from 4.5 onwards
> > +    case "$xenbranch" in
> > +    xen-3.*-testing) echo "n";;
> > +    xen-4.0-testing) echo "n";;
> > +    xen-4.1-testing) echo "n";;
> > +    xen-4.2-testing) echo "n";;
> > +    xen-4.3-testing) echo "n";;
> > +    xen-4.4-testing) echo "n";;
> > +    *) echo "n y";
> 
> Did you mean just "y" here, or is something very subtle going on?
> 
> Oh I see, you run over the result of this as a list with for. Sneaky!
> 

Ian J's suggestion.

> I think you should name it something like xenbranch_xsm_variants or
> something else which doesn't make the reader expect it to return a
> boolean.
> 

Ack.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:35:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:35:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhPw-0007Ji-R9; Wed, 10 Dec 2014 13:35: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 1XyhPv-0007JT-4a
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:34:59 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	89/F6-01660-20C48845; Wed, 10 Dec 2014 13:34:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418218496!12606823!1
X-Originating-IP: [66.165.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 7350 invoked from network); 10 Dec 2014 13:34:57 -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 Dec 2014 13:34:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202412028"
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.210.2;
	Wed, 10 Dec 2014 08:34: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 1XyhPK-0008Ka-FM;
	Wed, 10 Dec 2014 13:34:22 +0000
Date: Wed, 10 Dec 2014 13:34:22 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210133422.GB19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-11-git-send-email-wei.liu2@citrix.com>
	<1418217313.3505.41.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418217313.3505.41.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>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 10/11] ts-xen-install: install
 Xen with XSM support if requested
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 01:15:13PM +0000, Ian Campbell wrote:
> On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  ts-xen-install |    4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/ts-xen-install b/ts-xen-install
> > index 4d34d1f..2e2fcbc 100755
> > --- a/ts-xen-install
> > +++ b/ts-xen-install
> > @@ -46,6 +46,8 @@ if (@ARGV and $ARGV[0] eq '--check') {
> >  
> >  our $ho;
> >  
> > +my $enable_xsm = $r{enable_xsm} =~ m/y/ ? 1 : 0;
> > +
> >  my %distpath;
> >  
> >  sub packages () {
> > @@ -171,7 +173,7 @@ sub setupboot () {
> >      }
> >  
> >      my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
> > -    debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
> > +    debian_boot_setup($ho, $want_kernver, $enable_xsm, $xenhopt, \%distpath, \@hooks);
> 
> Doesn't this have to be in the same patch as the one which adds the new
> parameter in the function declaration? Or at least that patch needs to
> hardcode a false until now.
> 

Yes, I noticed this after I sent this series.  I will squash this one
into previous commit.

Wei.

> (not sure we care much about bisectability in osstest, Ian?)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:35:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:35:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhPw-0007Ji-R9; Wed, 10 Dec 2014 13:35: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 1XyhPv-0007JT-4a
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:34:59 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	89/F6-01660-20C48845; Wed, 10 Dec 2014 13:34:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418218496!12606823!1
X-Originating-IP: [66.165.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 7350 invoked from network); 10 Dec 2014 13:34:57 -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 Dec 2014 13:34:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202412028"
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.210.2;
	Wed, 10 Dec 2014 08:34: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 1XyhPK-0008Ka-FM;
	Wed, 10 Dec 2014 13:34:22 +0000
Date: Wed, 10 Dec 2014 13:34:22 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210133422.GB19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-11-git-send-email-wei.liu2@citrix.com>
	<1418217313.3505.41.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418217313.3505.41.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>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 10/11] ts-xen-install: install
 Xen with XSM support if requested
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 01:15:13PM +0000, Ian Campbell wrote:
> On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  ts-xen-install |    4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/ts-xen-install b/ts-xen-install
> > index 4d34d1f..2e2fcbc 100755
> > --- a/ts-xen-install
> > +++ b/ts-xen-install
> > @@ -46,6 +46,8 @@ if (@ARGV and $ARGV[0] eq '--check') {
> >  
> >  our $ho;
> >  
> > +my $enable_xsm = $r{enable_xsm} =~ m/y/ ? 1 : 0;
> > +
> >  my %distpath;
> >  
> >  sub packages () {
> > @@ -171,7 +173,7 @@ sub setupboot () {
> >      }
> >  
> >      my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
> > -    debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
> > +    debian_boot_setup($ho, $want_kernver, $enable_xsm, $xenhopt, \%distpath, \@hooks);
> 
> Doesn't this have to be in the same patch as the one which adds the new
> parameter in the function declaration? Or at least that patch needs to
> hardcode a false until now.
> 

Yes, I noticed this after I sent this series.  I will squash this one
into previous commit.

Wei.

> (not sure we care much about bisectability in osstest, Ian?)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:42:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:42:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhWc-0007W0-NR; Wed, 10 Dec 2014 13:41:54 +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 1XyhWc-0007Vv-13
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:41:54 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	AC/74-28296-1AD48845; Wed, 10 Dec 2014 13:41:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418218911!12228895!1
X-Originating-IP: [66.165.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 18215 invoked from network); 10 Dec 2014 13:41:52 -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;
	10 Dec 2014 13:41:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202820035"
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.210.2;
	Wed, 10 Dec 2014 08:41: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 1XyhWY-0008RL-5J;
	Wed, 10 Dec 2014 13:41:50 +0000
Date: Wed, 10 Dec 2014 13:41:50 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210134150.GC19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-5-git-send-email-wei.liu2@citrix.com>
	<1418216045.3505.28.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418216045.3505.28.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>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/11] overlay: update
 overlay/etc/grub.d/20_linux_xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 12:54:05PM +0000, Ian Campbell wrote:
> On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> > This file was created to work around Debian bug #633127.
> > 
> > According to Debian bug tracker [0], this bug is fixed in Wheezy. As
> > we're now using Wheezy in OSSTest we can safely remove this overlay
> > file.
> > 
> > Also add a note to reference #633127 above grub2 setup function, in case
> > someone trips over #633127.
> > 
> > As we're now using Wheezy in production, update this file to Wheezy's
> > version and take care of Debian bug #690538 and GRUB bug #43420.
> 
> When reference bugs it would be useful to include the bug title here so
> the reader doesn't have to go and look it up.
> 

OK.

> #690538 relates to providing an option to remove the submenus. Please
> can the changelog explain why that is relevant to us.
> 

Because somebody else thought not making submenu optional is a bug. So
do I.

> Did you fix it by removing/reverting the submenu support altogether, as
> opposed to e.g. importing the patch from Eric Fischer in the bug report?
> I don't see stuff which I'd expect if you had applied the patch. I think
> it would be worth spelling out in a bit more detail what the changes
> you've made to the baseline for each bug were.
> 

I fixed this by supplying a 20_linux_xen extracted from wheezy with
submenu generation removed (2 lines). This is how we dealt with other
grub bugs.

> I suppose constructing overlay/etc/grub.d/20_linux_xen from a baseline
> unmodified version (checked in, not retrieved from the host) and a
> mini-patch-series (also checked in) on the fly is over complexifying
> things?
> 

Certainly more complex than a single file solution. At the very least
new infrastructure to apply patches for overlay files is needed.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:42:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:42:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhWc-0007W0-NR; Wed, 10 Dec 2014 13:41:54 +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 1XyhWc-0007Vv-13
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:41:54 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	AC/74-28296-1AD48845; Wed, 10 Dec 2014 13:41:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418218911!12228895!1
X-Originating-IP: [66.165.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 18215 invoked from network); 10 Dec 2014 13:41:52 -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;
	10 Dec 2014 13:41:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202820035"
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.210.2;
	Wed, 10 Dec 2014 08:41: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 1XyhWY-0008RL-5J;
	Wed, 10 Dec 2014 13:41:50 +0000
Date: Wed, 10 Dec 2014 13:41:50 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210134150.GC19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-5-git-send-email-wei.liu2@citrix.com>
	<1418216045.3505.28.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418216045.3505.28.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>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/11] overlay: update
 overlay/etc/grub.d/20_linux_xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 12:54:05PM +0000, Ian Campbell wrote:
> On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> > This file was created to work around Debian bug #633127.
> > 
> > According to Debian bug tracker [0], this bug is fixed in Wheezy. As
> > we're now using Wheezy in OSSTest we can safely remove this overlay
> > file.
> > 
> > Also add a note to reference #633127 above grub2 setup function, in case
> > someone trips over #633127.
> > 
> > As we're now using Wheezy in production, update this file to Wheezy's
> > version and take care of Debian bug #690538 and GRUB bug #43420.
> 
> When reference bugs it would be useful to include the bug title here so
> the reader doesn't have to go and look it up.
> 

OK.

> #690538 relates to providing an option to remove the submenus. Please
> can the changelog explain why that is relevant to us.
> 

Because somebody else thought not making submenu optional is a bug. So
do I.

> Did you fix it by removing/reverting the submenu support altogether, as
> opposed to e.g. importing the patch from Eric Fischer in the bug report?
> I don't see stuff which I'd expect if you had applied the patch. I think
> it would be worth spelling out in a bit more detail what the changes
> you've made to the baseline for each bug were.
> 

I fixed this by supplying a 20_linux_xen extracted from wheezy with
submenu generation removed (2 lines). This is how we dealt with other
grub bugs.

> I suppose constructing overlay/etc/grub.d/20_linux_xen from a baseline
> unmodified version (checked in, not retrieved from the host) and a
> mini-patch-series (also checked in) on the fly is over complexifying
> things?
> 

Certainly more complex than a single file solution. At the very least
new infrastructure to apply patches for overlay files is needed.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:47:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13: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 1Xyhbk-0007qv-FL; Wed, 10 Dec 2014 13:47: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 1Xyhbj-0007qq-CW
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:47:11 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	6C/9B-24124-EDE48845; Wed, 10 Dec 2014 13:47:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418219228!5007047!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25707 invoked from network); 10 Dec 2014 13:47:09 -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 Dec 2014 13:47:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202822886"
Message-ID: <1418219226.3505.53.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 13:47:06 +0000
In-Reply-To: <20141210134150.GC19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-5-git-send-email-wei.liu2@citrix.com>
	<1418216045.3505.28.camel@citrix.com>
	<20141210134150.GC19059@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/11] overlay: update
 overlay/etc/grub.d/20_linux_xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 13:41 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 12:54:05PM +0000, Ian Campbell wrote:
> > #690538 relates to providing an option to remove the submenus. Please
> > can the changelog explain why that is relevant to us.
> > 
> 
> Because somebody else thought not making submenu optional is a bug. So
> do I.

I meant: why is this important to osstest? does using submenus break
something? if so then what? if not then there is no reason to be
diverging from the baseline.
 
> > Did you fix it by removing/reverting the submenu support altogether, as
> > opposed to e.g. importing the patch from Eric Fischer in the bug report?
> > I don't see stuff which I'd expect if you had applied the patch. I think
> > it would be worth spelling out in a bit more detail what the changes
> > you've made to the baseline for each bug were.
> > 
> 
> I fixed this by supplying a 20_linux_xen extracted from wheezy with
> submenu generation removed (2 lines). This is how we dealt with other
> grub bugs.

I think precisely what you've changed from the baseline should be
documented somewhere.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:47:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13: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 1Xyhbk-0007qv-FL; Wed, 10 Dec 2014 13:47: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 1Xyhbj-0007qq-CW
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:47:11 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	6C/9B-24124-EDE48845; Wed, 10 Dec 2014 13:47:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418219228!5007047!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25707 invoked from network); 10 Dec 2014 13:47:09 -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 Dec 2014 13:47:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202822886"
Message-ID: <1418219226.3505.53.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 13:47:06 +0000
In-Reply-To: <20141210134150.GC19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-5-git-send-email-wei.liu2@citrix.com>
	<1418216045.3505.28.camel@citrix.com>
	<20141210134150.GC19059@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/11] overlay: update
 overlay/etc/grub.d/20_linux_xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 13:41 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 12:54:05PM +0000, Ian Campbell wrote:
> > #690538 relates to providing an option to remove the submenus. Please
> > can the changelog explain why that is relevant to us.
> > 
> 
> Because somebody else thought not making submenu optional is a bug. So
> do I.

I meant: why is this important to osstest? does using submenus break
something? if so then what? if not then there is no reason to be
diverging from the baseline.
 
> > Did you fix it by removing/reverting the submenu support altogether, as
> > opposed to e.g. importing the patch from Eric Fischer in the bug report?
> > I don't see stuff which I'd expect if you had applied the patch. I think
> > it would be worth spelling out in a bit more detail what the changes
> > you've made to the baseline for each bug were.
> > 
> 
> I fixed this by supplying a 20_linux_xen extracted from wheezy with
> submenu generation removed (2 lines). This is how we dealt with other
> grub bugs.

I think precisely what you've changed from the baseline should be
documented somewhere.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:47:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:47:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhcI-0007tY-SU; Wed, 10 Dec 2014 13:47:46 +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 1XyhcH-0007tL-67
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:47:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EC/3E-09842-00F48845; Wed, 10 Dec 2014 13:47:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418219262!14692430!1
X-Originating-IP: [66.165.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 22016 invoked from network); 10 Dec 2014 13:47:43 -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 Dec 2014 13:47:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202823293"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 08:47: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 1XyhcC-000059-9q;
	Wed, 10 Dec 2014 13:47:40 +0000
Date: Wed, 10 Dec 2014 13:47:40 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210134740.GD19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-7-git-send-email-wei.liu2@citrix.com>
	<1418216722.3505.35.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418216722.3505.35.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>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 06/11] ts-xen-build: build with
 XSM support if requested
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 01:05:22PM +0000, Ian Campbell wrote:
> On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Looks like Ian J acked v2 in
> <21559.64364.468553.506173@mariner.uk.xensource.com>.
> 
> 
> > ---
> >  ts-xen-build |   12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/ts-xen-build b/ts-xen-build
> > index 661f186..390c114 100755
> > --- a/ts-xen-build
> > +++ b/ts-xen-build
> > @@ -27,6 +27,8 @@ tsreadconfig();
> >  selectbuildhost(\@ARGV);
> >  # remaining arguments are passed as targets to "make"
> >  builddirsprops();
> > +
> > +my $enable_xsm = $r{enable_xsm} =~ m/y/ ? 1 : 0;
> 
> Existing boolean runvars (enable_ovmf, enable_xend) appear to use
> true/false (which still need laundering into Perl booleans). Using y/n
> made sense when you were poking it straight into XSM_ENABLE, but if you
> are going to have to translate it there anyway (into $build_xsm) you may
> as well go for consistency.
> 

I tried to be consistent with next path (the "n y" one, eh). I'm OK with
changing them to true, false though.

> >      
> >  sub checkout () {
> >      prepbuilddirs();
> > @@ -34,6 +36,7 @@ sub checkout () {
> >      build_clone($ho, 'xen', $builddir, 'xen');
> >  
> >      my $debug_build = $r{xen_build_debug} || 'y';
> > +    my $build_xsm = $enable_xsm ? 'y' : 'n';
> >  
> >      # Do not set this unless you know what you are doing. This arm
> >      # option makes the build specific to a particular type of
> > @@ -47,6 +50,7 @@ sub checkout () {
> >          cd $builddir/xen
> >  	>.config
> >  	echo >>.config debug=$debug_build
> > +	echo >>.config XSM_ENABLE=$build_xsm
> >  	echo >>.config GIT_HTTP=y
> >  	echo >>.config LIBLEAFDIR_x86_64=lib
> >  	echo >>.config QEMU_REMOTE='$r{tree_qemu}'
> > @@ -114,6 +118,14 @@ END
> >      buildcmd_stamped_logged(9000, 'build', '',<<END,'');
> >              $make_prefix make $makeflags @ARGV
> >  END
> > +
> > +    if ($enable_xsm) {
> > +	my $xen_version = target_cmd_output_root($ho, <<END, 30);
> > +	    cd $builddir/xen
> > +	    $make_prefix make xenversion
> > +END
> > +        store_runvar("flaskpolicy", "xenpolicy-" . $xen_version);
> > +    }
> >  }
> >  
> >  sub collectversions () {
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:47:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:47:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhcI-0007tY-SU; Wed, 10 Dec 2014 13:47:46 +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 1XyhcH-0007tL-67
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:47:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EC/3E-09842-00F48845; Wed, 10 Dec 2014 13:47:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418219262!14692430!1
X-Originating-IP: [66.165.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 22016 invoked from network); 10 Dec 2014 13:47:43 -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 Dec 2014 13:47:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202823293"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 08:47: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 1XyhcC-000059-9q;
	Wed, 10 Dec 2014 13:47:40 +0000
Date: Wed, 10 Dec 2014 13:47:40 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210134740.GD19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-7-git-send-email-wei.liu2@citrix.com>
	<1418216722.3505.35.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418216722.3505.35.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>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 06/11] ts-xen-build: build with
 XSM support if requested
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 01:05:22PM +0000, Ian Campbell wrote:
> On Tue, 2014-10-14 at 22:50 +0100, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Looks like Ian J acked v2 in
> <21559.64364.468553.506173@mariner.uk.xensource.com>.
> 
> 
> > ---
> >  ts-xen-build |   12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/ts-xen-build b/ts-xen-build
> > index 661f186..390c114 100755
> > --- a/ts-xen-build
> > +++ b/ts-xen-build
> > @@ -27,6 +27,8 @@ tsreadconfig();
> >  selectbuildhost(\@ARGV);
> >  # remaining arguments are passed as targets to "make"
> >  builddirsprops();
> > +
> > +my $enable_xsm = $r{enable_xsm} =~ m/y/ ? 1 : 0;
> 
> Existing boolean runvars (enable_ovmf, enable_xend) appear to use
> true/false (which still need laundering into Perl booleans). Using y/n
> made sense when you were poking it straight into XSM_ENABLE, but if you
> are going to have to translate it there anyway (into $build_xsm) you may
> as well go for consistency.
> 

I tried to be consistent with next path (the "n y" one, eh). I'm OK with
changing them to true, false though.

> >      
> >  sub checkout () {
> >      prepbuilddirs();
> > @@ -34,6 +36,7 @@ sub checkout () {
> >      build_clone($ho, 'xen', $builddir, 'xen');
> >  
> >      my $debug_build = $r{xen_build_debug} || 'y';
> > +    my $build_xsm = $enable_xsm ? 'y' : 'n';
> >  
> >      # Do not set this unless you know what you are doing. This arm
> >      # option makes the build specific to a particular type of
> > @@ -47,6 +50,7 @@ sub checkout () {
> >          cd $builddir/xen
> >  	>.config
> >  	echo >>.config debug=$debug_build
> > +	echo >>.config XSM_ENABLE=$build_xsm
> >  	echo >>.config GIT_HTTP=y
> >  	echo >>.config LIBLEAFDIR_x86_64=lib
> >  	echo >>.config QEMU_REMOTE='$r{tree_qemu}'
> > @@ -114,6 +118,14 @@ END
> >      buildcmd_stamped_logged(9000, 'build', '',<<END,'');
> >              $make_prefix make $makeflags @ARGV
> >  END
> > +
> > +    if ($enable_xsm) {
> > +	my $xen_version = target_cmd_output_root($ho, <<END, 30);
> > +	    cd $builddir/xen
> > +	    $make_prefix make xenversion
> > +END
> > +        store_runvar("flaskpolicy", "xenpolicy-" . $xen_version);
> > +    }
> >  }
> >  
> >  sub collectversions () {
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:50:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhfG-000899-FC; Wed, 10 Dec 2014 13:50:50 +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 1XyhfF-000893-Sg
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:50:49 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DD/09-25276-9BF48845; Wed, 10 Dec 2014 13:50:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418219446!7382585!1
X-Originating-IP: [66.165.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 30936 invoked from network); 10 Dec 2014 13:50:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 13:50:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202825257"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 08:50: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 1Xyhf8-00008D-KG;
	Wed, 10 Dec 2014 13:50:42 +0000
Date: Wed, 10 Dec 2014 13:50:42 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210135042.GE19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-5-git-send-email-wei.liu2@citrix.com>
	<1418216045.3505.28.camel@citrix.com>
	<20141210134150.GC19059@zion.uk.xensource.com>
	<1418219226.3505.53.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418219226.3505.53.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>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/11] overlay: update
 overlay/etc/grub.d/20_linux_xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 01:47:06PM +0000, Ian Campbell wrote:
> On Wed, 2014-12-10 at 13:41 +0000, Wei Liu wrote:
> > On Wed, Dec 10, 2014 at 12:54:05PM +0000, Ian Campbell wrote:
> > > #690538 relates to providing an option to remove the submenus. Please
> > > can the changelog explain why that is relevant to us.
> > > 
> > 
> > Because somebody else thought not making submenu optional is a bug. So
> > do I.
> 
> I meant: why is this important to osstest? does using submenus break
> something? if so then what? if not then there is no reason to be
> diverging from the baseline.
>  

Submenu breaks OSSTest's grub menu parser, causing test step to fail.

> > > Did you fix it by removing/reverting the submenu support altogether, as
> > > opposed to e.g. importing the patch from Eric Fischer in the bug report?
> > > I don't see stuff which I'd expect if you had applied the patch. I think
> > > it would be worth spelling out in a bit more detail what the changes
> > > you've made to the baseline for each bug were.
> > > 
> > 
> > I fixed this by supplying a 20_linux_xen extracted from wheezy with
> > submenu generation removed (2 lines). This is how we dealt with other
> > grub bugs.
> 
> I think precisely what you've changed from the baseline should be
> documented somewhere.
> 

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 Wed Dec 10 13:50:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhfG-000899-FC; Wed, 10 Dec 2014 13:50:50 +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 1XyhfF-000893-Sg
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:50:49 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DD/09-25276-9BF48845; Wed, 10 Dec 2014 13:50:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418219446!7382585!1
X-Originating-IP: [66.165.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 30936 invoked from network); 10 Dec 2014 13:50:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 13:50:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202825257"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 08:50: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 1Xyhf8-00008D-KG;
	Wed, 10 Dec 2014 13:50:42 +0000
Date: Wed, 10 Dec 2014 13:50:42 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210135042.GE19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-5-git-send-email-wei.liu2@citrix.com>
	<1418216045.3505.28.camel@citrix.com>
	<20141210134150.GC19059@zion.uk.xensource.com>
	<1418219226.3505.53.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418219226.3505.53.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>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/11] overlay: update
 overlay/etc/grub.d/20_linux_xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 01:47:06PM +0000, Ian Campbell wrote:
> On Wed, 2014-12-10 at 13:41 +0000, Wei Liu wrote:
> > On Wed, Dec 10, 2014 at 12:54:05PM +0000, Ian Campbell wrote:
> > > #690538 relates to providing an option to remove the submenus. Please
> > > can the changelog explain why that is relevant to us.
> > > 
> > 
> > Because somebody else thought not making submenu optional is a bug. So
> > do I.
> 
> I meant: why is this important to osstest? does using submenus break
> something? if so then what? if not then there is no reason to be
> diverging from the baseline.
>  

Submenu breaks OSSTest's grub menu parser, causing test step to fail.

> > > Did you fix it by removing/reverting the submenu support altogether, as
> > > opposed to e.g. importing the patch from Eric Fischer in the bug report?
> > > I don't see stuff which I'd expect if you had applied the patch. I think
> > > it would be worth spelling out in a bit more detail what the changes
> > > you've made to the baseline for each bug were.
> > > 
> > 
> > I fixed this by supplying a 20_linux_xen extracted from wheezy with
> > submenu generation removed (2 lines). This is how we dealt with other
> > grub bugs.
> 
> I think precisely what you've changed from the baseline should be
> documented somewhere.
> 

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 Wed Dec 10 13:53:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:53:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhhE-00007M-0o; Wed, 10 Dec 2014 13:52: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 1XyhhD-00007E-5f
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:52:51 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	4C/0B-28296-23058845; Wed, 10 Dec 2014 13:52:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418219566!8641233!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 16981 invoked from network); 10 Dec 2014 13:52:49 -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 Dec 2014 13:52:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202826626"
Message-ID: <1418219567.3505.55.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 13:52:47 +0000
In-Reply-To: <20141210135042.GE19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-5-git-send-email-wei.liu2@citrix.com>
	<1418216045.3505.28.camel@citrix.com>
	<20141210134150.GC19059@zion.uk.xensource.com>
	<1418219226.3505.53.camel@citrix.com>
	<20141210135042.GE19059@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/11] overlay: update
 overlay/etc/grub.d/20_linux_xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 13:50 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 01:47:06PM +0000, Ian Campbell wrote:
> > On Wed, 2014-12-10 at 13:41 +0000, Wei Liu wrote:
> > > On Wed, Dec 10, 2014 at 12:54:05PM +0000, Ian Campbell wrote:
> > > > #690538 relates to providing an option to remove the submenus. Please
> > > > can the changelog explain why that is relevant to us.
> > > > 
> > > 
> > > Because somebody else thought not making submenu optional is a bug. So
> > > do I.
> > 
> > I meant: why is this important to osstest? does using submenus break
> > something? if so then what? if not then there is no reason to be
> > diverging from the baseline.
> >  
> 
> Submenu breaks OSSTest's grub menu parser, causing test step to fail.

Great, that's a good reason to diverge, but please say it somewhere like
in the commit log.

I think the parser should also gain a comment with a reference to either
the bug or this discussion saying that it relies on grub not using
submenus.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:53:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:53:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyhhE-00007M-0o; Wed, 10 Dec 2014 13:52: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 1XyhhD-00007E-5f
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:52:51 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	4C/0B-28296-23058845; Wed, 10 Dec 2014 13:52:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418219566!8641233!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 16981 invoked from network); 10 Dec 2014 13:52:49 -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 Dec 2014 13:52:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202826626"
Message-ID: <1418219567.3505.55.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 13:52:47 +0000
In-Reply-To: <20141210135042.GE19059@zion.uk.xensource.com>
References: <1413323416-21778-1-git-send-email-wei.liu2@citrix.com>
	<1413323416-21778-5-git-send-email-wei.liu2@citrix.com>
	<1418216045.3505.28.camel@citrix.com>
	<20141210134150.GC19059@zion.uk.xensource.com>
	<1418219226.3505.53.camel@citrix.com>
	<20141210135042.GE19059@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v3 04/11] overlay: update
 overlay/etc/grub.d/20_linux_xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 13:50 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 01:47:06PM +0000, Ian Campbell wrote:
> > On Wed, 2014-12-10 at 13:41 +0000, Wei Liu wrote:
> > > On Wed, Dec 10, 2014 at 12:54:05PM +0000, Ian Campbell wrote:
> > > > #690538 relates to providing an option to remove the submenus. Please
> > > > can the changelog explain why that is relevant to us.
> > > > 
> > > 
> > > Because somebody else thought not making submenu optional is a bug. So
> > > do I.
> > 
> > I meant: why is this important to osstest? does using submenus break
> > something? if so then what? if not then there is no reason to be
> > diverging from the baseline.
> >  
> 
> Submenu breaks OSSTest's grub menu parser, causing test step to fail.

Great, that's a good reason to diverge, but please say it somewhere like
in the commit log.

I think the parser should also gain a comment with a reference to either
the bug or this discussion saying that it relies on grub not using
submenus.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:54:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13: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 1Xyhic-0000GR-L1; Wed, 10 Dec 2014 13:54:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bsingharora@gmail.com>) id 1Xyhib-0000GH-7u
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 13:54:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	33/65-15461-88058845; Wed, 10 Dec 2014 13:54:16 +0000
X-Env-Sender: bsingharora@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418219655!14709752!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17011 invoked from network); 10 Dec 2014 13:54:15 -0000
Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com)
	(209.85.213.45)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 13:54:15 -0000
Received: by mail-yh0-f45.google.com with SMTP id f10so1271897yha.18
	for <xen-devel@lists.xensource.com>;
	Wed, 10 Dec 2014 05:54:14 -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=VT+BmK+o2OeClyhD06uioCNRcysD0yyI8qkxrbDgWdI=;
	b=FAhE10UY2ccktBM9UettqgYuo9aUlqI6hJGvPUzzTuUfJ1qX5GGCzLgBEM0rnLVTpr
	W8wt0IQJQ3JpyEQx0jAq+gMAC8CF40JK7fFD+6nUG5+2BBQGaBucs/s13bWc9vdU2nul
	JHRQPK9Ky95SQArbVWOuxMA7YlyasTf4ZirwW6fQsFpGjpeHF7mW1v4Q7iAhx7CUstd4
	2wWpqmnRyFfo0wsMzCy6qJiIgJg/q1pFxNRJC2ioC0fW+ggXUCZJVpWfs2Qb/WUMwgh7
	fHKELpq4hTHAcllvjiXUM8K8XM/OV/Qe7hlOqbLMk57MnXP/EJKkSD2p6AtNYpTVLgCy
	m3cQ==
MIME-Version: 1.0
X-Received: by 10.170.61.202 with SMTP id d193mr3344872ykd.32.1418219654650;
	Wed, 10 Dec 2014 05:54:14 -0800 (PST)
Received: by 10.170.211.212 with HTTP; Wed, 10 Dec 2014 05:54:14 -0800 (PST)
Date: Wed, 10 Dec 2014 19:24:14 +0530
Message-ID: <CAKTCnznScui38+ec50U0dkCvWK2jA4cHEmqgaf1USj23k6CE5g@mail.gmail.com>
From: Balbir Singh <bsingharora@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Frozen dom0 xl commands
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I've been facing an issue on my Ubuntu box (acting as dom0) with
xen-4.5 (HEAD). I am running dom0 3.13.0.19-generic (ubuntu). When I
try and xl command I see the command hangs, after a while I see the
guest kernel complain. I've tried a similar setup on another setup and
I see the same issue. Any clues on how to debug?

FYI: xl dmesg does not show much. I've tried using the console
debugger, but not had much luck with it

[  484.442137] xl              D 0000000000000000     0  4590   4122 0x00000004
[  484.442146]  ffff88038cf87dd8 0000000000000202 ffff8800c458afe0
ffff88038cf87fd8
[  484.442156]  0000000000014440 0000000000014440 ffff8800c458afe0
ffffffff81fc0260
[  484.442164]  ffff88038cf87e10 ffff8800c4130058 ffff8800c413004c
ffff8800c4130000
[  484.442172] Call Trace:
[  484.442188]  [<ffffffff817154b9>] schedule+0x29/0x70
[  484.442198]  [<ffffffff81429c25>] read_reply+0x95/0x140
[  484.442210]  [<ffffffff810a9a50>] ? prepare_to_wait_event+0x100/0x100
[  484.442218]  [<ffffffff8142aa1c>] xenbus_dev_request_and_reply+0x8c/0xb0
[  484.442226]  [<ffffffff8142d1ae>] xenbus_file_write+0x27e/0x540
[  484.442236]  [<ffffffff811baea9>] ? __sb_start_write+0x49/0xe0
[  484.442246]  [<ffffffff812cf1c3>] ? security_file_permission+0x23/0xa0
[  484.442253]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
[  484.442261]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
[  484.442269]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6
[  484.442276] INFO: task xl:4660 blocked for more than 120 seconds.
[  484.442280]       Tainted: PF          O 3.13.0-19-generic #40-Ubuntu
[  484.442283] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[  484.442286] xl              D 0000000000000000     0  4660   4646 0x00000004
[  484.442291]  ffff88038dc41dc0 0000000000000202 ffff88038e2797f0
ffff88038dc41fd8
[  484.442300]  0000000000014440 0000000000014440 ffff88038e2797f0
ffffffff81fc0290
[  484.442308]  ffffffff81fc0294 ffff88038e2797f0 00000000ffffffff
ffffffff81fc0298
[  484.442316] Call Trace:
[  484.442325]  [<ffffffff817159d9>] schedule_preempt_disabled+0x29/0x70
[  484.442333]  [<ffffffff81717845>] __mutex_lock_slowpath+0x135/0x1b0
[  484.442339]  [<ffffffff817178df>] mutex_lock+0x1f/0x2f
[  484.442347]  [<ffffffff8142a9b6>] xenbus_dev_request_and_reply+0x26/0xb0
[  484.442355]  [<ffffffff8142d1ae>] xenbus_file_write+0x27e/0x540
[  484.442364]  [<ffffffff811baea9>] ? __sb_start_write+0x49/0xe0
[  484.442371]  [<ffffffff812cf1c3>] ? security_file_permission+0x23/0xa0
[  484.442378]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
[  484.442386]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
[  484.442393]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:54:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13: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 1Xyhic-0000GR-L1; Wed, 10 Dec 2014 13:54:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bsingharora@gmail.com>) id 1Xyhib-0000GH-7u
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 13:54:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	33/65-15461-88058845; Wed, 10 Dec 2014 13:54:16 +0000
X-Env-Sender: bsingharora@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418219655!14709752!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17011 invoked from network); 10 Dec 2014 13:54:15 -0000
Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com)
	(209.85.213.45)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 13:54:15 -0000
Received: by mail-yh0-f45.google.com with SMTP id f10so1271897yha.18
	for <xen-devel@lists.xensource.com>;
	Wed, 10 Dec 2014 05:54:14 -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=VT+BmK+o2OeClyhD06uioCNRcysD0yyI8qkxrbDgWdI=;
	b=FAhE10UY2ccktBM9UettqgYuo9aUlqI6hJGvPUzzTuUfJ1qX5GGCzLgBEM0rnLVTpr
	W8wt0IQJQ3JpyEQx0jAq+gMAC8CF40JK7fFD+6nUG5+2BBQGaBucs/s13bWc9vdU2nul
	JHRQPK9Ky95SQArbVWOuxMA7YlyasTf4ZirwW6fQsFpGjpeHF7mW1v4Q7iAhx7CUstd4
	2wWpqmnRyFfo0wsMzCy6qJiIgJg/q1pFxNRJC2ioC0fW+ggXUCZJVpWfs2Qb/WUMwgh7
	fHKELpq4hTHAcllvjiXUM8K8XM/OV/Qe7hlOqbLMk57MnXP/EJKkSD2p6AtNYpTVLgCy
	m3cQ==
MIME-Version: 1.0
X-Received: by 10.170.61.202 with SMTP id d193mr3344872ykd.32.1418219654650;
	Wed, 10 Dec 2014 05:54:14 -0800 (PST)
Received: by 10.170.211.212 with HTTP; Wed, 10 Dec 2014 05:54:14 -0800 (PST)
Date: Wed, 10 Dec 2014 19:24:14 +0530
Message-ID: <CAKTCnznScui38+ec50U0dkCvWK2jA4cHEmqgaf1USj23k6CE5g@mail.gmail.com>
From: Balbir Singh <bsingharora@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Frozen dom0 xl commands
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I've been facing an issue on my Ubuntu box (acting as dom0) with
xen-4.5 (HEAD). I am running dom0 3.13.0.19-generic (ubuntu). When I
try and xl command I see the command hangs, after a while I see the
guest kernel complain. I've tried a similar setup on another setup and
I see the same issue. Any clues on how to debug?

FYI: xl dmesg does not show much. I've tried using the console
debugger, but not had much luck with it

[  484.442137] xl              D 0000000000000000     0  4590   4122 0x00000004
[  484.442146]  ffff88038cf87dd8 0000000000000202 ffff8800c458afe0
ffff88038cf87fd8
[  484.442156]  0000000000014440 0000000000014440 ffff8800c458afe0
ffffffff81fc0260
[  484.442164]  ffff88038cf87e10 ffff8800c4130058 ffff8800c413004c
ffff8800c4130000
[  484.442172] Call Trace:
[  484.442188]  [<ffffffff817154b9>] schedule+0x29/0x70
[  484.442198]  [<ffffffff81429c25>] read_reply+0x95/0x140
[  484.442210]  [<ffffffff810a9a50>] ? prepare_to_wait_event+0x100/0x100
[  484.442218]  [<ffffffff8142aa1c>] xenbus_dev_request_and_reply+0x8c/0xb0
[  484.442226]  [<ffffffff8142d1ae>] xenbus_file_write+0x27e/0x540
[  484.442236]  [<ffffffff811baea9>] ? __sb_start_write+0x49/0xe0
[  484.442246]  [<ffffffff812cf1c3>] ? security_file_permission+0x23/0xa0
[  484.442253]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
[  484.442261]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
[  484.442269]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6
[  484.442276] INFO: task xl:4660 blocked for more than 120 seconds.
[  484.442280]       Tainted: PF          O 3.13.0-19-generic #40-Ubuntu
[  484.442283] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[  484.442286] xl              D 0000000000000000     0  4660   4646 0x00000004
[  484.442291]  ffff88038dc41dc0 0000000000000202 ffff88038e2797f0
ffff88038dc41fd8
[  484.442300]  0000000000014440 0000000000014440 ffff88038e2797f0
ffffffff81fc0290
[  484.442308]  ffffffff81fc0294 ffff88038e2797f0 00000000ffffffff
ffffffff81fc0298
[  484.442316] Call Trace:
[  484.442325]  [<ffffffff817159d9>] schedule_preempt_disabled+0x29/0x70
[  484.442333]  [<ffffffff81717845>] __mutex_lock_slowpath+0x135/0x1b0
[  484.442339]  [<ffffffff817178df>] mutex_lock+0x1f/0x2f
[  484.442347]  [<ffffffff8142a9b6>] xenbus_dev_request_and_reply+0x26/0xb0
[  484.442355]  [<ffffffff8142d1ae>] xenbus_file_write+0x27e/0x540
[  484.442364]  [<ffffffff811baea9>] ? __sb_start_write+0x49/0xe0
[  484.442371]  [<ffffffff812cf1c3>] ? security_file_permission+0x23/0xa0
[  484.442378]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
[  484.442386]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
[  484.442393]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13: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 1XyhkN-0000RG-9n; Wed, 10 Dec 2014 13:56: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 1XyhkL-0000R0-WF
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 13:56:06 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	FA/64-02576-3F058845; Wed, 10 Dec 2014 13:56:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418219761!14176753!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 32331 invoked from network); 10 Dec 2014 13:56:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 13:56:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202421956"
Message-ID: <1418219759.3505.56.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Balbir Singh <bsingharora@gmail.com>
Date: Wed, 10 Dec 2014 13:55:59 +0000
In-Reply-To: <CAKTCnznScui38+ec50U0dkCvWK2jA4cHEmqgaf1USj23k6CE5g@mail.gmail.com>
References: <CAKTCnznScui38+ec50U0dkCvWK2jA4cHEmqgaf1USj23k6CE5g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Frozen dom0 xl commands
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-12-10 at 19:24 +0530, Balbir Singh wrote:
> I've been facing an issue on my Ubuntu box (acting as dom0) with
> xen-4.5 (HEAD). I am running dom0 3.13.0.19-generic (ubuntu). When I
> try and xl command I see the command hangs, after a while I see the
> guest kernel complain. I've tried a similar setup on another setup and
> I see the same issue. Any clues on how to debug?
> 
> FYI: xl dmesg does not show much. I've tried using the console
> debugger, but not had much luck with it

Is xenstored running?

> 
> [  484.442137] xl              D 0000000000000000     0  4590   4122 0x00000004
> [  484.442146]  ffff88038cf87dd8 0000000000000202 ffff8800c458afe0
> ffff88038cf87fd8
> [  484.442156]  0000000000014440 0000000000014440 ffff8800c458afe0
> ffffffff81fc0260
> [  484.442164]  ffff88038cf87e10 ffff8800c4130058 ffff8800c413004c
> ffff8800c4130000
> [  484.442172] Call Trace:
> [  484.442188]  [<ffffffff817154b9>] schedule+0x29/0x70
> [  484.442198]  [<ffffffff81429c25>] read_reply+0x95/0x140
> [  484.442210]  [<ffffffff810a9a50>] ? prepare_to_wait_event+0x100/0x100
> [  484.442218]  [<ffffffff8142aa1c>] xenbus_dev_request_and_reply+0x8c/0xb0
> [  484.442226]  [<ffffffff8142d1ae>] xenbus_file_write+0x27e/0x540
> [  484.442236]  [<ffffffff811baea9>] ? __sb_start_write+0x49/0xe0
> [  484.442246]  [<ffffffff812cf1c3>] ? security_file_permission+0x23/0xa0
> [  484.442253]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
> [  484.442261]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
> [  484.442269]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6
> [  484.442276] INFO: task xl:4660 blocked for more than 120 seconds.
> [  484.442280]       Tainted: PF          O 3.13.0-19-generic #40-Ubuntu
> [  484.442283] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [  484.442286] xl              D 0000000000000000     0  4660   4646 0x00000004
> [  484.442291]  ffff88038dc41dc0 0000000000000202 ffff88038e2797f0
> ffff88038dc41fd8
> [  484.442300]  0000000000014440 0000000000014440 ffff88038e2797f0
> ffffffff81fc0290
> [  484.442308]  ffffffff81fc0294 ffff88038e2797f0 00000000ffffffff
> ffffffff81fc0298
> [  484.442316] Call Trace:
> [  484.442325]  [<ffffffff817159d9>] schedule_preempt_disabled+0x29/0x70
> [  484.442333]  [<ffffffff81717845>] __mutex_lock_slowpath+0x135/0x1b0
> [  484.442339]  [<ffffffff817178df>] mutex_lock+0x1f/0x2f
> [  484.442347]  [<ffffffff8142a9b6>] xenbus_dev_request_and_reply+0x26/0xb0
> [  484.442355]  [<ffffffff8142d1ae>] xenbus_file_write+0x27e/0x540
> [  484.442364]  [<ffffffff811baea9>] ? __sb_start_write+0x49/0xe0
> [  484.442371]  [<ffffffff812cf1c3>] ? security_file_permission+0x23/0xa0
> [  484.442378]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
> [  484.442386]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
> [  484.442393]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 10 13:56:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13: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 1XyhkN-0000RG-9n; Wed, 10 Dec 2014 13:56: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 1XyhkL-0000R0-WF
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 13:56:06 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	FA/64-02576-3F058845; Wed, 10 Dec 2014 13:56:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418219761!14176753!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 32331 invoked from network); 10 Dec 2014 13:56:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 13:56:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202421956"
Message-ID: <1418219759.3505.56.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Balbir Singh <bsingharora@gmail.com>
Date: Wed, 10 Dec 2014 13:55:59 +0000
In-Reply-To: <CAKTCnznScui38+ec50U0dkCvWK2jA4cHEmqgaf1USj23k6CE5g@mail.gmail.com>
References: <CAKTCnznScui38+ec50U0dkCvWK2jA4cHEmqgaf1USj23k6CE5g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Frozen dom0 xl commands
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-12-10 at 19:24 +0530, Balbir Singh wrote:
> I've been facing an issue on my Ubuntu box (acting as dom0) with
> xen-4.5 (HEAD). I am running dom0 3.13.0.19-generic (ubuntu). When I
> try and xl command I see the command hangs, after a while I see the
> guest kernel complain. I've tried a similar setup on another setup and
> I see the same issue. Any clues on how to debug?
> 
> FYI: xl dmesg does not show much. I've tried using the console
> debugger, but not had much luck with it

Is xenstored running?

> 
> [  484.442137] xl              D 0000000000000000     0  4590   4122 0x00000004
> [  484.442146]  ffff88038cf87dd8 0000000000000202 ffff8800c458afe0
> ffff88038cf87fd8
> [  484.442156]  0000000000014440 0000000000014440 ffff8800c458afe0
> ffffffff81fc0260
> [  484.442164]  ffff88038cf87e10 ffff8800c4130058 ffff8800c413004c
> ffff8800c4130000
> [  484.442172] Call Trace:
> [  484.442188]  [<ffffffff817154b9>] schedule+0x29/0x70
> [  484.442198]  [<ffffffff81429c25>] read_reply+0x95/0x140
> [  484.442210]  [<ffffffff810a9a50>] ? prepare_to_wait_event+0x100/0x100
> [  484.442218]  [<ffffffff8142aa1c>] xenbus_dev_request_and_reply+0x8c/0xb0
> [  484.442226]  [<ffffffff8142d1ae>] xenbus_file_write+0x27e/0x540
> [  484.442236]  [<ffffffff811baea9>] ? __sb_start_write+0x49/0xe0
> [  484.442246]  [<ffffffff812cf1c3>] ? security_file_permission+0x23/0xa0
> [  484.442253]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
> [  484.442261]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
> [  484.442269]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6
> [  484.442276] INFO: task xl:4660 blocked for more than 120 seconds.
> [  484.442280]       Tainted: PF          O 3.13.0-19-generic #40-Ubuntu
> [  484.442283] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [  484.442286] xl              D 0000000000000000     0  4660   4646 0x00000004
> [  484.442291]  ffff88038dc41dc0 0000000000000202 ffff88038e2797f0
> ffff88038dc41fd8
> [  484.442300]  0000000000014440 0000000000014440 ffff88038e2797f0
> ffffffff81fc0290
> [  484.442308]  ffffffff81fc0294 ffff88038e2797f0 00000000ffffffff
> ffffffff81fc0298
> [  484.442316] Call Trace:
> [  484.442325]  [<ffffffff817159d9>] schedule_preempt_disabled+0x29/0x70
> [  484.442333]  [<ffffffff81717845>] __mutex_lock_slowpath+0x135/0x1b0
> [  484.442339]  [<ffffffff817178df>] mutex_lock+0x1f/0x2f
> [  484.442347]  [<ffffffff8142a9b6>] xenbus_dev_request_and_reply+0x26/0xb0
> [  484.442355]  [<ffffffff8142d1ae>] xenbus_file_write+0x27e/0x540
> [  484.442364]  [<ffffffff811baea9>] ? __sb_start_write+0x49/0xe0
> [  484.442371]  [<ffffffff812cf1c3>] ? security_file_permission+0x23/0xa0
> [  484.442378]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
> [  484.442386]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
> [  484.442393]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 10 13:56:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13: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 1Xyhkd-0000U7-Ml; Wed, 10 Dec 2014 13:56:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xyhkc-0000Ts-H3
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:56:22 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FB/69-15461-50158845; Wed, 10 Dec 2014 13:56:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418219780!14666209!1
X-Originating-IP: [66.165.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 21368 invoked from network); 10 Dec 2014 13:56:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 13:56:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202422073"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 08: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 1XyhkZ-0000Dq-A3;
	Wed, 10 Dec 2014 13:56:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyhkZ-0000Vi-2F;
	Wed, 10 Dec 2014 13:56:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21640.20738.890057.47682@mariner.uk.xensource.com>
Date: Wed, 10 Dec 2014 13:56:18 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1418032544-28645-1-git-send-email-ian.campbell@citrix.com>
References: <1418032544-28645-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] Add basic PVH flights.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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] Add basic PVH flights."):
> These are the usual PV debian flights with pvh=1 added to the
> configuration file.
> 
> A job is created for each of Intel and AMD, although obviously AMD is
> expected to fail at the moment.
...
> Beyond that I've not tested this at all I fully expect even Intel to
> fail in the first instance, due to issues such as lack of necessary
> kernel options etc. I suggest to take this now and iterate on any
> further changes.

That seems reasonable.

> For a xen-unstable flight this results in these runvars:
> diff --git a/ts-debian-fixup b/ts-debian-fixup
> index f001418..00477c5 100755
> --- a/ts-debian-fixup
> +++ b/ts-debian-fixup
> @@ -118,6 +118,12 @@ sub otherfixupcfg () {
...
> +    my $pvh = guest_var($gho,'pvh',undef);
> +    if ($pvh) {
> +	$cfg =~ s/^pvh.*//mg;

This should probably be

  +	$cfg =~ s/^pvh\b.*//mg;

unless you deliberately intend to strip out any other phv-related
settings which xen-create-image might put there ?

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 Dec 10 13:56:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13: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 1Xyhkd-0000U7-Ml; Wed, 10 Dec 2014 13:56:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xyhkc-0000Ts-H3
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:56:22 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	FB/69-15461-50158845; Wed, 10 Dec 2014 13:56:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418219780!14666209!1
X-Originating-IP: [66.165.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 21368 invoked from network); 10 Dec 2014 13:56:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 13:56:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202422073"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 08: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 1XyhkZ-0000Dq-A3;
	Wed, 10 Dec 2014 13:56:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyhkZ-0000Vi-2F;
	Wed, 10 Dec 2014 13:56:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21640.20738.890057.47682@mariner.uk.xensource.com>
Date: Wed, 10 Dec 2014 13:56:18 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1418032544-28645-1-git-send-email-ian.campbell@citrix.com>
References: <1418032544-28645-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] Add basic PVH flights.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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] Add basic PVH flights."):
> These are the usual PV debian flights with pvh=1 added to the
> configuration file.
> 
> A job is created for each of Intel and AMD, although obviously AMD is
> expected to fail at the moment.
...
> Beyond that I've not tested this at all I fully expect even Intel to
> fail in the first instance, due to issues such as lack of necessary
> kernel options etc. I suggest to take this now and iterate on any
> further changes.

That seems reasonable.

> For a xen-unstable flight this results in these runvars:
> diff --git a/ts-debian-fixup b/ts-debian-fixup
> index f001418..00477c5 100755
> --- a/ts-debian-fixup
> +++ b/ts-debian-fixup
> @@ -118,6 +118,12 @@ sub otherfixupcfg () {
...
> +    my $pvh = guest_var($gho,'pvh',undef);
> +    if ($pvh) {
> +	$cfg =~ s/^pvh.*//mg;

This should probably be

  +	$cfg =~ s/^pvh\b.*//mg;

unless you deliberately intend to strip out any other phv-related
settings which xen-create-image might put there ?

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 Dec 10 13:58:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyhmu-0000he-7z; Wed, 10 Dec 2014 13:58: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 1Xyhms-0000hU-5g
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:58:42 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	EE/46-26858-19158845; Wed, 10 Dec 2014 13:58:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418219918!12396004!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 4198 invoked from network); 10 Dec 2014 13:58:39 -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;
	10 Dec 2014 13:58:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202829215"
Message-ID: <1418219917.3505.57.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 10 Dec 2014 13:58:37 +0000
In-Reply-To: <21640.20738.890057.47682@mariner.uk.xensource.com>
References: <1418032544-28645-1-git-send-email-ian.campbell@citrix.com>
	<21640.20738.890057.47682@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST] Add basic PVH flights.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 13:56 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST] Add basic PVH flights."):
> > These are the usual PV debian flights with pvh=1 added to the
> > configuration file.
> > 
> > A job is created for each of Intel and AMD, although obviously AMD is
> > expected to fail at the moment.
> ...
> > Beyond that I've not tested this at all I fully expect even Intel to
> > fail in the first instance, due to issues such as lack of necessary
> > kernel options etc. I suggest to take this now and iterate on any
> > further changes.
> 
> That seems reasonable.
> 
> > For a xen-unstable flight this results in these runvars:
> > diff --git a/ts-debian-fixup b/ts-debian-fixup
> > index f001418..00477c5 100755
> > --- a/ts-debian-fixup
> > +++ b/ts-debian-fixup
> > @@ -118,6 +118,12 @@ sub otherfixupcfg () {
> ...
> > +    my $pvh = guest_var($gho,'pvh',undef);
> > +    if ($pvh) {
> > +	$cfg =~ s/^pvh.*//mg;
> 
> This should probably be
> 
>   +	$cfg =~ s/^pvh\b.*//mg;
> 
> unless you deliberately intend to strip out any other phv-related
> settings which xen-create-image might put there ?

Nope, your suggest is a good one.

Shall I resent or are you ok for me to do this change as I commit?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 13:58:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 13:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyhmu-0000he-7z; Wed, 10 Dec 2014 13:58: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 1Xyhms-0000hU-5g
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 13:58:42 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	EE/46-26858-19158845; Wed, 10 Dec 2014 13:58:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418219918!12396004!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 4198 invoked from network); 10 Dec 2014 13:58:39 -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;
	10 Dec 2014 13:58:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202829215"
Message-ID: <1418219917.3505.57.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 10 Dec 2014 13:58:37 +0000
In-Reply-To: <21640.20738.890057.47682@mariner.uk.xensource.com>
References: <1418032544-28645-1-git-send-email-ian.campbell@citrix.com>
	<21640.20738.890057.47682@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST] Add basic PVH flights.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 13:56 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST] Add basic PVH flights."):
> > These are the usual PV debian flights with pvh=1 added to the
> > configuration file.
> > 
> > A job is created for each of Intel and AMD, although obviously AMD is
> > expected to fail at the moment.
> ...
> > Beyond that I've not tested this at all I fully expect even Intel to
> > fail in the first instance, due to issues such as lack of necessary
> > kernel options etc. I suggest to take this now and iterate on any
> > further changes.
> 
> That seems reasonable.
> 
> > For a xen-unstable flight this results in these runvars:
> > diff --git a/ts-debian-fixup b/ts-debian-fixup
> > index f001418..00477c5 100755
> > --- a/ts-debian-fixup
> > +++ b/ts-debian-fixup
> > @@ -118,6 +118,12 @@ sub otherfixupcfg () {
> ...
> > +    my $pvh = guest_var($gho,'pvh',undef);
> > +    if ($pvh) {
> > +	$cfg =~ s/^pvh.*//mg;
> 
> This should probably be
> 
>   +	$cfg =~ s/^pvh\b.*//mg;
> 
> unless you deliberately intend to strip out any other phv-related
> settings which xen-create-image might put there ?

Nope, your suggest is a good one.

Shall I resent or are you ok for me to do this change as I commit?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 14:03:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 14: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 1Xyhrh-00012z-13; Wed, 10 Dec 2014 14:03:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xyhrf-00012u-SH
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 14:03:39 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	3A/82-14214-BB258845; Wed, 10 Dec 2014 14:03:39 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418220217!9243657!1
X-Originating-IP: [66.165.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 2624 invoked from network); 10 Dec 2014 14:03:38 -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 Dec 2014 14:03:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202831857"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 09:03: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 1XyhrD-0000KQ-KM;
	Wed, 10 Dec 2014 14:03:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyhrD-0000Wt-DE;
	Wed, 10 Dec 2014 14:03:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21640.21151.235518.931928@mariner.uk.xensource.com>
Date: Wed, 10 Dec 2014 14:03:11 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1418219917.3505.57.camel@citrix.com>
References: <1418032544-28645-1-git-send-email-ian.campbell@citrix.com>
	<21640.20738.890057.47682@mariner.uk.xensource.com>
	<1418219917.3505.57.camel@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] Add basic PVH flights.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 OSSTEST] Add basic PVH flights."):
> On Wed, 2014-12-10 at 13:56 +0000, Ian Jackson wrote:
> > This should probably be
> > 
> >   +	$cfg =~ s/^pvh\b.*//mg;
> > 
> > unless you deliberately intend to strip out any other phv-related
> > settings which xen-create-image might put there ?
> 
> Nope, your suggest is a good one.
> 
> Shall I resent or are you ok for me to do this change as I commit?

Please go ahead, but can you please first double check that it still
does actually still edit the config file as desired and cause the test
failure on your machine ?  It would be annoying if that line ceased to
take effect and the job spuriously passed.

That said,

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 Wed Dec 10 14:03:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 14: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 1Xyhrh-00012z-13; Wed, 10 Dec 2014 14:03:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xyhrf-00012u-SH
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 14:03:39 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	3A/82-14214-BB258845; Wed, 10 Dec 2014 14:03:39 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418220217!9243657!1
X-Originating-IP: [66.165.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 2624 invoked from network); 10 Dec 2014 14:03:38 -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 Dec 2014 14:03:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202831857"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 10 Dec 2014 09:03: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 1XyhrD-0000KQ-KM;
	Wed, 10 Dec 2014 14:03:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyhrD-0000Wt-DE;
	Wed, 10 Dec 2014 14:03:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21640.21151.235518.931928@mariner.uk.xensource.com>
Date: Wed, 10 Dec 2014 14:03:11 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1418219917.3505.57.camel@citrix.com>
References: <1418032544-28645-1-git-send-email-ian.campbell@citrix.com>
	<21640.20738.890057.47682@mariner.uk.xensource.com>
	<1418219917.3505.57.camel@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] Add basic PVH flights.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 OSSTEST] Add basic PVH flights."):
> On Wed, 2014-12-10 at 13:56 +0000, Ian Jackson wrote:
> > This should probably be
> > 
> >   +	$cfg =~ s/^pvh\b.*//mg;
> > 
> > unless you deliberately intend to strip out any other phv-related
> > settings which xen-create-image might put there ?
> 
> Nope, your suggest is a good one.
> 
> Shall I resent or are you ok for me to do this change as I commit?

Please go ahead, but can you please first double check that it still
does actually still edit the config file as desired and cause the test
failure on your machine ?  It would be annoying if that line ceased to
take effect and the job spuriously passed.

That said,

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 Wed Dec 10 14:12:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 14:12:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyi0A-0001if-2D; Wed, 10 Dec 2014 14:12:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xyi08-0001ia-ST
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 14:12:25 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	09/C5-26740-7C458845; Wed, 10 Dec 2014 14:12:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418220741!8648427!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 6519 invoked from network); 10 Dec 2014 14:12:23 -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 Dec 2014 14:12:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202431721"
Message-ID: <548854C3.7060008@citrix.com>
Date: Wed, 10 Dec 2014 14:12:19 +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: John <jw@nuclearfallout.net>
References: <54884DA8.7030003@nuclearfallout.net>
In-Reply-To: <54884DA8.7030003@nuclearfallout.net>
X-DLP: MIA2
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	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] xen-netback: make feature-rx-notify mandatory --
	Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 13:42, John wrote:
> David,
> 
> This patch you put into 3.18.0 appears to break the latest version of
> stubdomains. I found this out today when I tried to update a machine to
> 3.18.0 and all of the domUs crashed on start with the dmesg output like
> this:

Cc'ing the lists and relevant netback maintainers.

I guess the stubdoms are using minios's netfront?  This is something I
forgot about when deciding if it was ok to make this feature mandatory.

The patch cannot be reverted as it's a prerequisite for a critical
(security) bug fix.  I am also unconvinced that the no-feature-rx-notify
support worked correctly anyway.

This can be resolved by:

- Fixing minios's netfront to support feature-rx-notify. This should be
easy but wouldn't help existing Xen deployments.

Or:

- Reimplement feature-rx-notify support.  I think the easiest way is to
queue packets on the guest Rx internal queue with a short expiry time.

> [   83.045785] device vif2.0 entered promiscuous mode
> [   83.059220] vif vif-2-0: 22 feature-rx-notify is mandatory
> [   83.060763] vif vif-2-0: 1 mapping in shared page 2047 from domain 2
> [   83.060861] vif vif-2-0: 1 mapping shared-frames 2047/2046 port tx 4
> rx 4
> 
> This is on the very latest patched version of 4.4.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 14:12:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 14:12:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyi0A-0001if-2D; Wed, 10 Dec 2014 14:12:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xyi08-0001ia-ST
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 14:12:25 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	09/C5-26740-7C458845; Wed, 10 Dec 2014 14:12:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418220741!8648427!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 6519 invoked from network); 10 Dec 2014 14:12:23 -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 Dec 2014 14:12:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202431721"
Message-ID: <548854C3.7060008@citrix.com>
Date: Wed, 10 Dec 2014 14:12:19 +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: John <jw@nuclearfallout.net>
References: <54884DA8.7030003@nuclearfallout.net>
In-Reply-To: <54884DA8.7030003@nuclearfallout.net>
X-DLP: MIA2
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	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] xen-netback: make feature-rx-notify mandatory --
	Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 13:42, John wrote:
> David,
> 
> This patch you put into 3.18.0 appears to break the latest version of
> stubdomains. I found this out today when I tried to update a machine to
> 3.18.0 and all of the domUs crashed on start with the dmesg output like
> this:

Cc'ing the lists and relevant netback maintainers.

I guess the stubdoms are using minios's netfront?  This is something I
forgot about when deciding if it was ok to make this feature mandatory.

The patch cannot be reverted as it's a prerequisite for a critical
(security) bug fix.  I am also unconvinced that the no-feature-rx-notify
support worked correctly anyway.

This can be resolved by:

- Fixing minios's netfront to support feature-rx-notify. This should be
easy but wouldn't help existing Xen deployments.

Or:

- Reimplement feature-rx-notify support.  I think the easiest way is to
queue packets on the guest Rx internal queue with a short expiry time.

> [   83.045785] device vif2.0 entered promiscuous mode
> [   83.059220] vif vif-2-0: 22 feature-rx-notify is mandatory
> [   83.060763] vif vif-2-0: 1 mapping in shared page 2047 from domain 2
> [   83.060861] vif vif-2-0: 1 mapping shared-frames 2047/2046 port tx 4
> rx 4
> 
> This is on the very latest patched version of 4.4.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 14:30:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 14:30:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyiHQ-0002Bu-3F; Wed, 10 Dec 2014 14:30:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyiHO-0002Bm-Jd
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 14:30:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DD/16-25276-6F858845; Wed, 10 Dec 2014 14:30:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418221811!14705103!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 30335 invoked from network); 10 Dec 2014 14:30:13 -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;
	10 Dec 2014 14:30:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202846639"
Message-ID: <1418221807.3505.66.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 14:30:07 +0000
In-Reply-To: <21640.21151.235518.931928@mariner.uk.xensource.com>
References: <1418032544-28645-1-git-send-email-ian.campbell@citrix.com>
	<21640.20738.890057.47682@mariner.uk.xensource.com>
	<1418219917.3505.57.camel@citrix.com>
	<21640.21151.235518.931928@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST] Add basic PVH flights.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 14:03 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST] Add basic PVH flights."):
> > On Wed, 2014-12-10 at 13:56 +0000, Ian Jackson wrote:
> > > This should probably be
> > > 
> > >   +	$cfg =~ s/^pvh\b.*//mg;
> > > 
> > > unless you deliberately intend to strip out any other phv-related
> > > settings which xen-create-image might put there ?
> > 
> > Nope, your suggest is a good one.
> > 
> > Shall I resent or are you ok for me to do this change as I commit?
> 
> Please go ahead, but can you please first double check that it still
> does actually still edit the config file as desired and cause the test
> failure on your machine ?  It would be annoying if that line ceased to
> take effect and the job spuriously passed.

I checked both the pvh and non-pvh job and they did/didn't contain a
pvh=1 as expected.

> That said,
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks. As discussed on IRC I've added it to my to-push queue which is
pending the current pretest stuff propagating. I'll flush that once I
see a pass of osstest's own gate.

The queue contains:
$ git log --oneline origin/pretest..pretest 
082e565 Add basic PVH flights.
1f110e8 Osstest/Debian: support adding a rootdelay property to bootargs
f254b4d Osstest/Debian: Add support for "ExtraInitramfsModules" host property
7d8be54 Osstest/Debian: Refactor code to set bootargs in u-boot script
1b01799 ts-debian-install: rename cfg_xend to cfg
1f48acb gitignore: ignore images directory
1b95fe3 README: list chiark-utils-bin as requirement
abc19f4 TestSupport: allow overriding of on_* in prepareguest_part_xencfg

It's also in the pretest branch of my osstest tree on xenbits.

(Wei, just FYI since some patches of yours are in there)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 14:30:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 14:30:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyiHQ-0002Bu-3F; Wed, 10 Dec 2014 14:30:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyiHO-0002Bm-Jd
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 14:30:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DD/16-25276-6F858845; Wed, 10 Dec 2014 14:30:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418221811!14705103!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 30335 invoked from network); 10 Dec 2014 14:30:13 -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;
	10 Dec 2014 14:30:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="202846639"
Message-ID: <1418221807.3505.66.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>
Date: Wed, 10 Dec 2014 14:30:07 +0000
In-Reply-To: <21640.21151.235518.931928@mariner.uk.xensource.com>
References: <1418032544-28645-1-git-send-email-ian.campbell@citrix.com>
	<21640.20738.890057.47682@mariner.uk.xensource.com>
	<1418219917.3505.57.camel@citrix.com>
	<21640.21151.235518.931928@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST] Add basic PVH flights.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 14:03 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST] Add basic PVH flights."):
> > On Wed, 2014-12-10 at 13:56 +0000, Ian Jackson wrote:
> > > This should probably be
> > > 
> > >   +	$cfg =~ s/^pvh\b.*//mg;
> > > 
> > > unless you deliberately intend to strip out any other phv-related
> > > settings which xen-create-image might put there ?
> > 
> > Nope, your suggest is a good one.
> > 
> > Shall I resent or are you ok for me to do this change as I commit?
> 
> Please go ahead, but can you please first double check that it still
> does actually still edit the config file as desired and cause the test
> failure on your machine ?  It would be annoying if that line ceased to
> take effect and the job spuriously passed.

I checked both the pvh and non-pvh job and they did/didn't contain a
pvh=1 as expected.

> That said,
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks. As discussed on IRC I've added it to my to-push queue which is
pending the current pretest stuff propagating. I'll flush that once I
see a pass of osstest's own gate.

The queue contains:
$ git log --oneline origin/pretest..pretest 
082e565 Add basic PVH flights.
1f110e8 Osstest/Debian: support adding a rootdelay property to bootargs
f254b4d Osstest/Debian: Add support for "ExtraInitramfsModules" host property
7d8be54 Osstest/Debian: Refactor code to set bootargs in u-boot script
1b01799 ts-debian-install: rename cfg_xend to cfg
1f48acb gitignore: ignore images directory
1b95fe3 README: list chiark-utils-bin as requirement
abc19f4 TestSupport: allow overriding of on_* in prepareguest_part_xencfg

It's also in the pretest branch of my osstest tree on xenbits.

(Wei, just FYI since some patches of yours are in there)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 14:30:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 14:30:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyiGs-0002AN-MU; Wed, 10 Dec 2014 14:29: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 1XyiGr-0002AI-HA
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 14:29:41 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	46/0D-22737-4D858845; Wed, 10 Dec 2014 14:29:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418221778!7311342!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31890 invoked from network); 10 Dec 2014 14:29:39 -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; 10 Dec 2014 14:29: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 sBAETaN5018889
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 14:29:37 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
	sBAETZ2P013353
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 14:29:36 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
	sBAETZkS026489; Wed, 10 Dec 2014 14:29:35 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 06:29:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4CFE7122A6C; Wed, 10 Dec 2014 09:29:34 -0500 (EST)
Date: Wed, 10 Dec 2014 09:29:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141210142934.GA2640@laptop.dumpdata.com>
References: <20141208212739.GA7226@laptop.dumpdata.com>
	<5486C8C9020000780004DFDC@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5486C8C9020000780004DFDC@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen  4.5.0rc3 + Linux v3.18 + dom0pvh=1 = BOOM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 09:02:49AM +0000, Jan Beulich wrote:
> >>> On 08.12.14 at 22:27, <konrad.wilk@oracle.com> wrote:
> > [    8.761336] ------------[ cut here ]------------
> > [    8.761342] kernel BUG at arch/x86/xen/smp.c:438!
> 
> 	if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
> 		BUG();
> 
> > [    8.761348] invalid opcode: 0000 [#1] SMP 
> > [    8.761355] Modules linked in:
> > [    8.761362] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0 #1
> > [    8.761369] Hardware name: LENOVO 10A6S09R01/SHARKBAY, BIOS FBKTA1AUS 10/22/2014
> > [    8.761377] task: ffff8803ef058000 ti: ffff8803ef060000 task.ti: ffff8803ef060000
> > [    8.761386] RIP: 0010:[<ffffffff810114c5>]  [<ffffffff810114c5>] xen_cpu_up+0x4c5/0x4d0
> > [    8.761396] RSP: 0000:ffff8803ef063dd8  EFLAGS: 00010282
> > [    8.761402] RAX: fffffffffffffff4 RBX: 0000000000000001 RCX: 0000000000000001
> 
> -ENOMEM
> 
> Very strange. I suppose that Dom0 kernel doesn't exhaust all of the
> hypervisor's memory?

With 'dom0_mem=max:2GB' it boots. Thought it does hit another issue which
is related to TSC (will post a seperate email).


> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 14:30:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 14:30:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyiGs-0002AN-MU; Wed, 10 Dec 2014 14:29: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 1XyiGr-0002AI-HA
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 14:29:41 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	46/0D-22737-4D858845; Wed, 10 Dec 2014 14:29:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418221778!7311342!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31890 invoked from network); 10 Dec 2014 14:29:39 -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; 10 Dec 2014 14:29: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 sBAETaN5018889
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 14:29:37 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
	sBAETZ2P013353
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 14:29:36 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
	sBAETZkS026489; Wed, 10 Dec 2014 14:29:35 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 06:29:35 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 4CFE7122A6C; Wed, 10 Dec 2014 09:29:34 -0500 (EST)
Date: Wed, 10 Dec 2014 09:29:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141210142934.GA2640@laptop.dumpdata.com>
References: <20141208212739.GA7226@laptop.dumpdata.com>
	<5486C8C9020000780004DFDC@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5486C8C9020000780004DFDC@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen  4.5.0rc3 + Linux v3.18 + dom0pvh=1 = BOOM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 09:02:49AM +0000, Jan Beulich wrote:
> >>> On 08.12.14 at 22:27, <konrad.wilk@oracle.com> wrote:
> > [    8.761336] ------------[ cut here ]------------
> > [    8.761342] kernel BUG at arch/x86/xen/smp.c:438!
> 
> 	if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
> 		BUG();
> 
> > [    8.761348] invalid opcode: 0000 [#1] SMP 
> > [    8.761355] Modules linked in:
> > [    8.761362] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0 #1
> > [    8.761369] Hardware name: LENOVO 10A6S09R01/SHARKBAY, BIOS FBKTA1AUS 10/22/2014
> > [    8.761377] task: ffff8803ef058000 ti: ffff8803ef060000 task.ti: ffff8803ef060000
> > [    8.761386] RIP: 0010:[<ffffffff810114c5>]  [<ffffffff810114c5>] xen_cpu_up+0x4c5/0x4d0
> > [    8.761396] RSP: 0000:ffff8803ef063dd8  EFLAGS: 00010282
> > [    8.761402] RAX: fffffffffffffff4 RBX: 0000000000000001 RCX: 0000000000000001
> 
> -ENOMEM
> 
> Very strange. I suppose that Dom0 kernel doesn't exhaust all of the
> hypervisor's memory?

With 'dom0_mem=max:2GB' it boots. Thought it does hit another issue which
is related to TSC (will post a seperate email).


> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 15:11:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 15: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 1XyivG-0003nW-3S; Wed, 10 Dec 2014 15:11:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyivF-0003nO-3u
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 15:11:25 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D4/5D-15461-C9268845; Wed, 10 Dec 2014 15:11:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418224281!14733880!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 7594 invoked from network); 10 Dec 2014 15:11:23 -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 Dec 2014 15:11:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202866814"
Message-ID: <1418224039.3505.76.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 10 Dec 2014 15:07:19 +0000
In-Reply-To: <548854C3.7060008@citrix.com>
References: <54884DA8.7030003@nuclearfallout.net> <548854C3.7060008@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Wei Liu <wei.liu2@citrix.com>, John <jw@nuclearfallout.net>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen-netback: make feature-rx-notify mandatory --
	Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 14:12 +0000, David Vrabel wrote:
> On 10/12/14 13:42, John wrote:
> > David,
> > 
> > This patch you put into 3.18.0 appears to break the latest version of
> > stubdomains. I found this out today when I tried to update a machine to
> > 3.18.0 and all of the domUs crashed on start with the dmesg output like
> > this:
> 
> Cc'ing the lists and relevant netback maintainers.
> 
> I guess the stubdoms are using minios's netfront?  This is something I
> forgot about when deciding if it was ok to make this feature mandatory.

Oh bum, me too :/

> The patch cannot be reverted as it's a prerequisite for a critical
> (security) bug fix.  I am also unconvinced that the no-feature-rx-notify
> support worked correctly anyway.
> 
> This can be resolved by:
> 
> - Fixing minios's netfront to support feature-rx-notify. This should be
> easy but wouldn't help existing Xen deployments.

I think this is worth doing in its own right, but as you say it doesn't
help existing users.

> - Reimplement feature-rx-notify support.  I think the easiest way is to
> queue packets on the guest Rx internal queue with a short expiry time.

Right, I don't think we especially need to make this case good (so long
as it doesn't reintroduce a security hole!).

In principal we aren't really obliged to queue at all, but since all the
infrastructure for queuing and timing out all exists I suppose it would
be simple enough to implement and a bit less harsh.

Given we now have XENVIF_RX_QUEUE_BYTES and rx_drain_timeout_jiffies we
don't have the infinite queue any more. So does the expiry in this case
actually need to be shorter than the norm? Does it cause any extra
issues to keep them around for tx_drain_timeout_jiffies rather than some
shorter time?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 15:11:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 15: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 1XyivG-0003nW-3S; Wed, 10 Dec 2014 15:11:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XyivF-0003nO-3u
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 15:11:25 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D4/5D-15461-C9268845; Wed, 10 Dec 2014 15:11:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418224281!14733880!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 7594 invoked from network); 10 Dec 2014 15:11:23 -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 Dec 2014 15:11:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202866814"
Message-ID: <1418224039.3505.76.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 10 Dec 2014 15:07:19 +0000
In-Reply-To: <548854C3.7060008@citrix.com>
References: <54884DA8.7030003@nuclearfallout.net> <548854C3.7060008@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Wei Liu <wei.liu2@citrix.com>, John <jw@nuclearfallout.net>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen-netback: make feature-rx-notify mandatory --
	Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 14:12 +0000, David Vrabel wrote:
> On 10/12/14 13:42, John wrote:
> > David,
> > 
> > This patch you put into 3.18.0 appears to break the latest version of
> > stubdomains. I found this out today when I tried to update a machine to
> > 3.18.0 and all of the domUs crashed on start with the dmesg output like
> > this:
> 
> Cc'ing the lists and relevant netback maintainers.
> 
> I guess the stubdoms are using minios's netfront?  This is something I
> forgot about when deciding if it was ok to make this feature mandatory.

Oh bum, me too :/

> The patch cannot be reverted as it's a prerequisite for a critical
> (security) bug fix.  I am also unconvinced that the no-feature-rx-notify
> support worked correctly anyway.
> 
> This can be resolved by:
> 
> - Fixing minios's netfront to support feature-rx-notify. This should be
> easy but wouldn't help existing Xen deployments.

I think this is worth doing in its own right, but as you say it doesn't
help existing users.

> - Reimplement feature-rx-notify support.  I think the easiest way is to
> queue packets on the guest Rx internal queue with a short expiry time.

Right, I don't think we especially need to make this case good (so long
as it doesn't reintroduce a security hole!).

In principal we aren't really obliged to queue at all, but since all the
infrastructure for queuing and timing out all exists I suppose it would
be simple enough to implement and a bit less harsh.

Given we now have XENVIF_RX_QUEUE_BYTES and rx_drain_timeout_jiffies we
don't have the infinite queue any more. So does the expiry in this case
actually need to be shorter than the norm? Does it cause any extra
issues to keep them around for tx_drain_timeout_jiffies rather than some
shorter time?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 15:30:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 15:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyjDL-0004ea-Iz; Wed, 10 Dec 2014 15:30:07 +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 1XyjDK-0004eS-2e
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 15:30:06 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	6C/BC-27584-DF668845; Wed, 10 Dec 2014 15:30:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418225402!9267775!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 29658 invoked from network); 10 Dec 2014 15:30:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 15:30:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202879456"
Message-ID: <548866D9.5050900@citrix.com>
Date: Wed, 10 Dec 2014 15:29:29 +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: Ian Campbell <Ian.Campbell@citrix.com>
References: <54884DA8.7030003@nuclearfallout.net>	
	<548854C3.7060008@citrix.com> <1418224039.3505.76.camel@citrix.com>
In-Reply-To: <1418224039.3505.76.camel@citrix.com>
X-DLP: MIA1
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Wei Liu <wei.liu2@citrix.com>, John <jw@nuclearfallout.net>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen-netback: make feature-rx-notify mandatory --
	Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 15:07, Ian Campbell wrote:
> On Wed, 2014-12-10 at 14:12 +0000, David Vrabel wrote:
>> On 10/12/14 13:42, John wrote:
>>> David,
>>>
>>> This patch you put into 3.18.0 appears to break the latest version of
>>> stubdomains. I found this out today when I tried to update a machine to
>>> 3.18.0 and all of the domUs crashed on start with the dmesg output like
>>> this:
>>
>> Cc'ing the lists and relevant netback maintainers.
>>
>> I guess the stubdoms are using minios's netfront?  This is something I
>> forgot about when deciding if it was ok to make this feature mandatory.
> 
> Oh bum, me too :/
> 
>> The patch cannot be reverted as it's a prerequisite for a critical
>> (security) bug fix.  I am also unconvinced that the no-feature-rx-notify
>> support worked correctly anyway.
>>
>> This can be resolved by:
>>
>> - Fixing minios's netfront to support feature-rx-notify. This should be
>> easy but wouldn't help existing Xen deployments.
> 
> I think this is worth doing in its own right, but as you say it doesn't
> help existing users.
> 
>> - Reimplement feature-rx-notify support.  I think the easiest way is to
>> queue packets on the guest Rx internal queue with a short expiry time.
> 
> Right, I don't think we especially need to make this case good (so long
> as it doesn't reintroduce a security hole!).
> 
> In principal we aren't really obliged to queue at all, but since all the
> infrastructure for queuing and timing out all exists I suppose it would
> be simple enough to implement and a bit less harsh.
> 
> Given we now have XENVIF_RX_QUEUE_BYTES and rx_drain_timeout_jiffies we
> don't have the infinite queue any more. So does the expiry in this case
> actually need to be shorter than the norm? Does it cause any extra
> issues to keep them around for tx_drain_timeout_jiffies rather than some
> shorter time?

If the internal guest rx queue fills and the (host) tx queue is stopped,
it will take tx_drain_timeout for the thread to wake up and notice if
the frontend placed any rx requests on the ring.  This could potentially
end up where you shovel 512k through stall for 10 s, put another 512k
through, stall for 10 s again and so on.

The rx stall detection will also need to be disabled since there would
be no way for the frontend to signal rx ready.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 15:30:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 15:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyjDL-0004ea-Iz; Wed, 10 Dec 2014 15:30:07 +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 1XyjDK-0004eS-2e
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 15:30:06 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	6C/BC-27584-DF668845; Wed, 10 Dec 2014 15:30:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418225402!9267775!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 29658 invoked from network); 10 Dec 2014 15:30:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 15:30:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202879456"
Message-ID: <548866D9.5050900@citrix.com>
Date: Wed, 10 Dec 2014 15:29:29 +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: Ian Campbell <Ian.Campbell@citrix.com>
References: <54884DA8.7030003@nuclearfallout.net>	
	<548854C3.7060008@citrix.com> <1418224039.3505.76.camel@citrix.com>
In-Reply-To: <1418224039.3505.76.camel@citrix.com>
X-DLP: MIA1
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Wei Liu <wei.liu2@citrix.com>, John <jw@nuclearfallout.net>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen-netback: make feature-rx-notify mandatory --
	Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 15:07, Ian Campbell wrote:
> On Wed, 2014-12-10 at 14:12 +0000, David Vrabel wrote:
>> On 10/12/14 13:42, John wrote:
>>> David,
>>>
>>> This patch you put into 3.18.0 appears to break the latest version of
>>> stubdomains. I found this out today when I tried to update a machine to
>>> 3.18.0 and all of the domUs crashed on start with the dmesg output like
>>> this:
>>
>> Cc'ing the lists and relevant netback maintainers.
>>
>> I guess the stubdoms are using minios's netfront?  This is something I
>> forgot about when deciding if it was ok to make this feature mandatory.
> 
> Oh bum, me too :/
> 
>> The patch cannot be reverted as it's a prerequisite for a critical
>> (security) bug fix.  I am also unconvinced that the no-feature-rx-notify
>> support worked correctly anyway.
>>
>> This can be resolved by:
>>
>> - Fixing minios's netfront to support feature-rx-notify. This should be
>> easy but wouldn't help existing Xen deployments.
> 
> I think this is worth doing in its own right, but as you say it doesn't
> help existing users.
> 
>> - Reimplement feature-rx-notify support.  I think the easiest way is to
>> queue packets on the guest Rx internal queue with a short expiry time.
> 
> Right, I don't think we especially need to make this case good (so long
> as it doesn't reintroduce a security hole!).
> 
> In principal we aren't really obliged to queue at all, but since all the
> infrastructure for queuing and timing out all exists I suppose it would
> be simple enough to implement and a bit less harsh.
> 
> Given we now have XENVIF_RX_QUEUE_BYTES and rx_drain_timeout_jiffies we
> don't have the infinite queue any more. So does the expiry in this case
> actually need to be shorter than the norm? Does it cause any extra
> issues to keep them around for tx_drain_timeout_jiffies rather than some
> shorter time?

If the internal guest rx queue fills and the (host) tx queue is stopped,
it will take tx_drain_timeout for the thread to wake up and notice if
the frontend placed any rx requests on the ring.  This could potentially
end up where you shovel 512k through stall for 10 s, put another 512k
through, stall for 10 s again and so on.

The rx stall detection will also need to be disabled since there would
be no way for the frontend to signal rx ready.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 15:42:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 15: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 1XyjP5-0005cA-1L; Wed, 10 Dec 2014 15: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.Jackson@citrix.com>) id 1XyjP3-0005bi-Lj
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 15:42:13 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	AE/09-24859-4D968845; Wed, 10 Dec 2014 15:42:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418226130!12421753!1
X-Originating-IP: [66.165.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 18414 invoked from network); 10 Dec 2014 15:42:12 -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;
	10 Dec 2014 15:42:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202479833"
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.210.2; Wed, 10 Dec 2014 10:42: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 1XyjOz-0000UO-HR;
	Wed, 10 Dec 2014 15:42:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyjOz-00007Q-By;
	Wed, 10 Dec 2014 15:42:09 +0000
Date: Wed, 10 Dec 2014 15:42:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32192-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] 32192: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32192 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32192/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-libvirt       5 xen-boot                  fail REGR. vs. 32141
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot            fail REGR. vs. 32141
 test-amd64-amd64-libvirt      5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 32141
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 32141
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32141
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32141
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-freebsd10-amd64  5 xen-boot               fail REGR. vs. 32141
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32141
 test-amd64-i386-freebsd10-i386  5 xen-boot                fail REGR. vs. 32141
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot           fail REGR. vs. 32141
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot             fail REGR. vs. 32141
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32141
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 32141
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32141
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32141
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot           fail REGR. vs. 32141
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 32141
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 32141
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 32141
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32141
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32141
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot          fail REGR. vs. 32141
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32141
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32141
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 32141
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 32141
 test-amd64-i386-xl-winxpsp3   5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot             fail REGR. vs. 32141
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 32141
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 32141
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 32141
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32141
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 32141
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 32141
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot            fail REGR. vs. 32141

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 32141
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 32141
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 32141
 test-armhf-armhf-xl          12 guest-start.2            fail blocked in 32141

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

version targeted for testing:
 linux                cf12164be498180dc466ef97194ca7755ea39f3b
baseline version:
 linux                19b022572b9e0fa8ce5490db888714ecb2b1293e

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 Wed Dec 10 15:42:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 15: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 1XyjP5-0005cA-1L; Wed, 10 Dec 2014 15: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.Jackson@citrix.com>) id 1XyjP3-0005bi-Lj
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 15:42:13 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	AE/09-24859-4D968845; Wed, 10 Dec 2014 15:42:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418226130!12421753!1
X-Originating-IP: [66.165.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 18414 invoked from network); 10 Dec 2014 15:42:12 -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;
	10 Dec 2014 15:42:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202479833"
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.210.2; Wed, 10 Dec 2014 10:42: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 1XyjOz-0000UO-HR;
	Wed, 10 Dec 2014 15:42:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XyjOz-00007Q-By;
	Wed, 10 Dec 2014 15:42:09 +0000
Date: Wed, 10 Dec 2014 15:42:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32192-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] 32192: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32192 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32192/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-libvirt       5 xen-boot                  fail REGR. vs. 32141
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot            fail REGR. vs. 32141
 test-amd64-amd64-libvirt      5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 32141
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 32141
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32141
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32141
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-freebsd10-amd64  5 xen-boot               fail REGR. vs. 32141
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32141
 test-amd64-i386-freebsd10-i386  5 xen-boot                fail REGR. vs. 32141
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot           fail REGR. vs. 32141
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot             fail REGR. vs. 32141
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32141
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 32141
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32141
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32141
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot           fail REGR. vs. 32141
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 32141
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 32141
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 32141
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32141
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32141
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot          fail REGR. vs. 32141
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32141
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32141
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 32141
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 32141
 test-amd64-i386-xl-winxpsp3   5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot             fail REGR. vs. 32141
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 32141
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 32141
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 32141
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32141
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 32141
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 32141
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 32141
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot            fail REGR. vs. 32141

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 32141
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 32141
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 32141
 test-armhf-armhf-xl          12 guest-start.2            fail blocked in 32141

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

version targeted for testing:
 linux                cf12164be498180dc466ef97194ca7755ea39f3b
baseline version:
 linux                19b022572b9e0fa8ce5490db888714ecb2b1293e

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 Wed Dec 10 15:56:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 15:56:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyjcY-0006aa-Do; Wed, 10 Dec 2014 15:56: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 1XyjcX-0006aV-1l
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 15:56:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	71/4F-09842-81D68845; Wed, 10 Dec 2014 15:56:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418226967!6690507!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 22614 invoked from network); 10 Dec 2014 15:56:07 -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; 10 Dec 2014 15:56:07 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id C59EDABC6;
	Wed, 10 Dec 2014 15:56: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
Date: Wed, 10 Dec 2014 16:56:03 +0100
Message-Id: <1418226963-24873-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] xen: switch to post-init routines in xen mmu.c
	earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 virtual mapped linear p2m list the post-init mmu operations
must be used for setting up the p2m mappings, as in case of
CONFIG_FLATMEM the init routines may trigger BUGs.

Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6ab6150..a1a429a 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
 static void __init xen_pagetable_init(void)
 {
 	paging_init();
+	xen_post_allocator_init();
 
 	xen_pagetable_p2m_setup();
 
@@ -1236,7 +1237,6 @@ static void __init xen_pagetable_init(void)
 		xen_remap_memory();
 
 	xen_setup_shared_info();
-	xen_post_allocator_init();
 }
 static void xen_write_cr2(unsigned long cr2)
 {
-- 
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 Dec 10 15:56:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 15:56:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyjcY-0006aa-Do; Wed, 10 Dec 2014 15:56: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 1XyjcX-0006aV-1l
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 15:56:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	71/4F-09842-81D68845; Wed, 10 Dec 2014 15:56:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418226967!6690507!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 22614 invoked from network); 10 Dec 2014 15:56:07 -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; 10 Dec 2014 15:56:07 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id C59EDABC6;
	Wed, 10 Dec 2014 15:56: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
Date: Wed, 10 Dec 2014 16:56:03 +0100
Message-Id: <1418226963-24873-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] xen: switch to post-init routines in xen mmu.c
	earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 virtual mapped linear p2m list the post-init mmu operations
must be used for setting up the p2m mappings, as in case of
CONFIG_FLATMEM the init routines may trigger BUGs.

Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6ab6150..a1a429a 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
 static void __init xen_pagetable_init(void)
 {
 	paging_init();
+	xen_post_allocator_init();
 
 	xen_pagetable_p2m_setup();
 
@@ -1236,7 +1237,6 @@ static void __init xen_pagetable_init(void)
 		xen_remap_memory();
 
 	xen_setup_shared_info();
-	xen_post_allocator_init();
 }
 static void xen_write_cr2(unsigned long cr2)
 {
-- 
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 Dec 10 16:14:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 16:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyjtv-0007nI-NE; Wed, 10 Dec 2014 16:14:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xyjtu-0007nA-20
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 16:14:06 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	EB/A1-29352-D4178845; Wed, 10 Dec 2014 16:14:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418228043!9278241!1
X-Originating-IP: [156.151.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 3000 invoked from network); 10 Dec 2014 16:14:04 -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; 10 Dec 2014 16:14: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 sBAGDvUg028362
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 16:13: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
	sBAGDtVt000332
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 16:13:56 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
	sBAGDseI008391; Wed, 10 Dec 2014 16:13:54 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 08:13:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9C082122B64; Wed, 10 Dec 2014 11:13:53 -0500 (EST)
Date: Wed, 10 Dec 2014 11:13:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141210161353.GD4268@laptop.dumpdata.com>
References: <1418226963-24873-1-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418226963-24873-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: boris.ostrovsky@oracle.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen
	mmu.c earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 04:56:03PM +0100, Juergen Gross wrote:
> With the virtual mapped linear p2m list the post-init mmu operations
> must be used for setting up the p2m mappings, as in case of
> CONFIG_FLATMEM the init routines may trigger BUGs.

Um, could you explain a bit more of why the CONFIG_FLATMEM
is such unique? What about the other CONFIG_*MEM cases?

> 
> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  arch/x86/xen/mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 6ab6150..a1a429a 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
>  static void __init xen_pagetable_init(void)
>  {
>  	paging_init();
> +	xen_post_allocator_init();
>  
>  	xen_pagetable_p2m_setup();
>  
> @@ -1236,7 +1237,6 @@ static void __init xen_pagetable_init(void)
>  		xen_remap_memory();
>  
>  	xen_setup_shared_info();
> -	xen_post_allocator_init();
>  }
>  static void xen_write_cr2(unsigned long cr2)
>  {
> -- 
> 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 Dec 10 16:14:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 16:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyjtv-0007nI-NE; Wed, 10 Dec 2014 16:14:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xyjtu-0007nA-20
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 16:14:06 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	EB/A1-29352-D4178845; Wed, 10 Dec 2014 16:14:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418228043!9278241!1
X-Originating-IP: [156.151.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 3000 invoked from network); 10 Dec 2014 16:14:04 -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; 10 Dec 2014 16:14: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 sBAGDvUg028362
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 16:13: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
	sBAGDtVt000332
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 16:13:56 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
	sBAGDseI008391; Wed, 10 Dec 2014 16:13:54 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 08:13:54 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9C082122B64; Wed, 10 Dec 2014 11:13:53 -0500 (EST)
Date: Wed, 10 Dec 2014 11:13:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141210161353.GD4268@laptop.dumpdata.com>
References: <1418226963-24873-1-git-send-email-jgross@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418226963-24873-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: boris.ostrovsky@oracle.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen
	mmu.c earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 04:56:03PM +0100, Juergen Gross wrote:
> With the virtual mapped linear p2m list the post-init mmu operations
> must be used for setting up the p2m mappings, as in case of
> CONFIG_FLATMEM the init routines may trigger BUGs.

Um, could you explain a bit more of why the CONFIG_FLATMEM
is such unique? What about the other CONFIG_*MEM cases?

> 
> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  arch/x86/xen/mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 6ab6150..a1a429a 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
>  static void __init xen_pagetable_init(void)
>  {
>  	paging_init();
> +	xen_post_allocator_init();
>  
>  	xen_pagetable_p2m_setup();
>  
> @@ -1236,7 +1237,6 @@ static void __init xen_pagetable_init(void)
>  		xen_remap_memory();
>  
>  	xen_setup_shared_info();
> -	xen_post_allocator_init();
>  }
>  static void xen_write_cr2(unsigned long cr2)
>  {
> -- 
> 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 Dec 10 16:22:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 16:22:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyk1X-00089e-Lc; Wed, 10 Dec 2014 16:21: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 1Xyk1V-00089Z-J7
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 16:21:57 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	EC/2F-02698-42378845; Wed, 10 Dec 2014 16:21:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418228514!14245257!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 15580 invoked from network); 10 Dec 2014 16:21:55 -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 Dec 2014 16:21:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202907405"
Message-ID: <1418228446.3505.81.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 10 Dec 2014 16:20:46 +0000
In-Reply-To: <548866D9.5050900@citrix.com>
References: <54884DA8.7030003@nuclearfallout.net>
	<548854C3.7060008@citrix.com> <1418224039.3505.76.camel@citrix.com>
	<548866D9.5050900@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Wei Liu <wei.liu2@citrix.com>, John <jw@nuclearfallout.net>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen-netback: make feature-rx-notify mandatory --
	Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 15:29 +0000, David Vrabel wrote:
> On 10/12/14 15:07, Ian Campbell wrote:
> > On Wed, 2014-12-10 at 14:12 +0000, David Vrabel wrote:
> >> On 10/12/14 13:42, John wrote:
> >>> David,
> >>>
> >>> This patch you put into 3.18.0 appears to break the latest version of
> >>> stubdomains. I found this out today when I tried to update a machine to
> >>> 3.18.0 and all of the domUs crashed on start with the dmesg output like
> >>> this:
> >>
> >> Cc'ing the lists and relevant netback maintainers.
> >>
> >> I guess the stubdoms are using minios's netfront?  This is something I
> >> forgot about when deciding if it was ok to make this feature mandatory.
> > 
> > Oh bum, me too :/
> > 
> >> The patch cannot be reverted as it's a prerequisite for a critical
> >> (security) bug fix.  I am also unconvinced that the no-feature-rx-notify
> >> support worked correctly anyway.
> >>
> >> This can be resolved by:
> >>
> >> - Fixing minios's netfront to support feature-rx-notify. This should be
> >> easy but wouldn't help existing Xen deployments.
> > 
> > I think this is worth doing in its own right, but as you say it doesn't
> > help existing users.
> > 
> >> - Reimplement feature-rx-notify support.  I think the easiest way is to
> >> queue packets on the guest Rx internal queue with a short expiry time.
> > 
> > Right, I don't think we especially need to make this case good (so long
> > as it doesn't reintroduce a security hole!).
> > 
> > In principal we aren't really obliged to queue at all, but since all the
> > infrastructure for queuing and timing out all exists I suppose it would
> > be simple enough to implement and a bit less harsh.
> > 
> > Given we now have XENVIF_RX_QUEUE_BYTES and rx_drain_timeout_jiffies we
> > don't have the infinite queue any more. So does the expiry in this case
> > actually need to be shorter than the norm? Does it cause any extra
> > issues to keep them around for tx_drain_timeout_jiffies rather than some
> > shorter time?
> 
> If the internal guest rx queue fills and the (host) tx queue is stopped,
> it will take tx_drain_timeout for the thread to wake up and notice if
> the frontend placed any rx requests on the ring.  This could potentially
> end up where you shovel 512k through stall for 10 s, put another 512k
> through, stall for 10 s again and so on.

Ah, true, that's not so great.

What about if we don't queue at all(*) if rx-notify isn't supported, i.e
just drop the packet on the floor in start_xmit if the ring is full?
Would that be so bad? It would surely be simple...

(*) Not counting the "queue" which is the ring itself.

> The rx stall detection will also need to be disabled since there would
> be no way for the frontend to signal rx ready.

Agreed.

Could be trivially argued to be safe if we were just dropping packets on
ring overflow...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 16:22:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 16:22:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyk1X-00089e-Lc; Wed, 10 Dec 2014 16:21: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 1Xyk1V-00089Z-J7
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 16:21:57 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	EC/2F-02698-42378845; Wed, 10 Dec 2014 16:21:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418228514!14245257!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 15580 invoked from network); 10 Dec 2014 16:21:55 -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 Dec 2014 16:21:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202907405"
Message-ID: <1418228446.3505.81.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 10 Dec 2014 16:20:46 +0000
In-Reply-To: <548866D9.5050900@citrix.com>
References: <54884DA8.7030003@nuclearfallout.net>
	<548854C3.7060008@citrix.com> <1418224039.3505.76.camel@citrix.com>
	<548866D9.5050900@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Wei Liu <wei.liu2@citrix.com>, John <jw@nuclearfallout.net>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen-netback: make feature-rx-notify mandatory --
	Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 15:29 +0000, David Vrabel wrote:
> On 10/12/14 15:07, Ian Campbell wrote:
> > On Wed, 2014-12-10 at 14:12 +0000, David Vrabel wrote:
> >> On 10/12/14 13:42, John wrote:
> >>> David,
> >>>
> >>> This patch you put into 3.18.0 appears to break the latest version of
> >>> stubdomains. I found this out today when I tried to update a machine to
> >>> 3.18.0 and all of the domUs crashed on start with the dmesg output like
> >>> this:
> >>
> >> Cc'ing the lists and relevant netback maintainers.
> >>
> >> I guess the stubdoms are using minios's netfront?  This is something I
> >> forgot about when deciding if it was ok to make this feature mandatory.
> > 
> > Oh bum, me too :/
> > 
> >> The patch cannot be reverted as it's a prerequisite for a critical
> >> (security) bug fix.  I am also unconvinced that the no-feature-rx-notify
> >> support worked correctly anyway.
> >>
> >> This can be resolved by:
> >>
> >> - Fixing minios's netfront to support feature-rx-notify. This should be
> >> easy but wouldn't help existing Xen deployments.
> > 
> > I think this is worth doing in its own right, but as you say it doesn't
> > help existing users.
> > 
> >> - Reimplement feature-rx-notify support.  I think the easiest way is to
> >> queue packets on the guest Rx internal queue with a short expiry time.
> > 
> > Right, I don't think we especially need to make this case good (so long
> > as it doesn't reintroduce a security hole!).
> > 
> > In principal we aren't really obliged to queue at all, but since all the
> > infrastructure for queuing and timing out all exists I suppose it would
> > be simple enough to implement and a bit less harsh.
> > 
> > Given we now have XENVIF_RX_QUEUE_BYTES and rx_drain_timeout_jiffies we
> > don't have the infinite queue any more. So does the expiry in this case
> > actually need to be shorter than the norm? Does it cause any extra
> > issues to keep them around for tx_drain_timeout_jiffies rather than some
> > shorter time?
> 
> If the internal guest rx queue fills and the (host) tx queue is stopped,
> it will take tx_drain_timeout for the thread to wake up and notice if
> the frontend placed any rx requests on the ring.  This could potentially
> end up where you shovel 512k through stall for 10 s, put another 512k
> through, stall for 10 s again and so on.

Ah, true, that's not so great.

What about if we don't queue at all(*) if rx-notify isn't supported, i.e
just drop the packet on the floor in start_xmit if the ring is full?
Would that be so bad? It would surely be simple...

(*) Not counting the "queue" which is the ring itself.

> The rx stall detection will also need to be disabled since there would
> be no way for the frontend to signal rx ready.

Agreed.

Could be trivially argued to be safe if we were just dropping packets on
ring overflow...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 16:31:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 16:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XykAI-0000EL-RT; Wed, 10 Dec 2014 16:31: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 1XykAH-0000EG-T7
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 16:31:02 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	23/45-17958-54578845; Wed, 10 Dec 2014 16:31:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418229058!12421096!1
X-Originating-IP: [156.151.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 21538 invoked from network); 10 Dec 2014 16:31:00 -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; 10 Dec 2014 16:31: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 sBAGUo1W020970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 16:30: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
	sBAGUnaR016865
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Dec 2014 16:30:49 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
	sBAGUmfF018543; Wed, 10 Dec 2014 16:30:48 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 08:30:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id F19A8122B90; Wed, 10 Dec 2014 11:30:46 -0500 (EST)
Date: Wed, 10 Dec 2014 11:30:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210163046.GF4268@laptop.dumpdata.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
	<1418136501.14361.83.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418136501.14361.83.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>,
	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] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 02:48:21PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-09 at 14:04 +0000, George Dunlap wrote:
> > At the moment libxl unconditinally passes the underlying file format
> > to qemu in the device string.  However, when tapdisk is in use,
> > tapdisk handles the underlying format and presents qemu with
> > effectively a raw disk.  When qemu looks at the tapdisk block device
> > and doesn't find the image format it was looking for, it will fail.
> > 
> > This effectively means that tapdisk cannot be used with HVM domains at
> > the moment except for raw files.
> > 
> > Instead, if we're using a tapdisk backend, tell qemu to use a raw file
> > format.
> > 
> > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 exception justification:
> 
> I agree with your reasoning.
> 
> >  This fixes a bug in functionality, in
> > that at the moment HVM guests cannot boot with tapdisk and vhd format.
> > 
> > This is not a regression in xl functionality per se, since (AFAICT)
> > this has never worked.  However, given that 4.5 is the first release
> > without xend, this *does* represent a regression in functionality for
> > Xen as a whole (since before people using hvm guest with vhd on blktap
> > could use xend).
> > 
> > The fix is very simple and should only affect codepaths that already
> > don't work, so the risk of regressions should be very low.
> > 
> > While preparing this patch, I also noticed that cdroms will ignore the
> > backend parameter and treat everything as a file.  This is a bug but I
> > think it's a much less important one to address this late in the
> > release cycle.
> > ---
> >  tools/libxl/libxl_dm.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index b25b574..10f3090 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -797,11 +797,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> >                      continue;
> >                  }
> >  
> > -                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP)
> > +                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP) {
> > +                    format = qemu_disk_format_string(LIBXL_DISK_FORMAT_RAW);
> >                      pdev_path = libxl__blktap_devpath(gc, disks[i].pdev_path,
> >                                                        disks[i].format);
> > -                else
> > +                } else {
> >                      pdev_path = disks[i].pdev_path;
> > +                }
> > +
> >  
> >                  /*
> >                   * Explicit sd disks are passed through as is.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 16:31:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 16:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XykAI-0000EL-RT; Wed, 10 Dec 2014 16:31: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 1XykAH-0000EG-T7
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 16:31:02 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	23/45-17958-54578845; Wed, 10 Dec 2014 16:31:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418229058!12421096!1
X-Originating-IP: [156.151.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 21538 invoked from network); 10 Dec 2014 16:31:00 -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; 10 Dec 2014 16:31: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 sBAGUo1W020970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 16:30: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
	sBAGUnaR016865
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Dec 2014 16:30:49 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
	sBAGUmfF018543; Wed, 10 Dec 2014 16:30:48 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 08:30:47 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id F19A8122B90; Wed, 10 Dec 2014 11:30:46 -0500 (EST)
Date: Wed, 10 Dec 2014 11:30:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210163046.GF4268@laptop.dumpdata.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
	<1418136501.14361.83.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418136501.14361.83.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>,
	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] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 02:48:21PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-09 at 14:04 +0000, George Dunlap wrote:
> > At the moment libxl unconditinally passes the underlying file format
> > to qemu in the device string.  However, when tapdisk is in use,
> > tapdisk handles the underlying format and presents qemu with
> > effectively a raw disk.  When qemu looks at the tapdisk block device
> > and doesn't find the image format it was looking for, it will fail.
> > 
> > This effectively means that tapdisk cannot be used with HVM domains at
> > the moment except for raw files.
> > 
> > Instead, if we're using a tapdisk backend, tell qemu to use a raw file
> > format.
> > 
> > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 exception justification:
> 
> I agree with your reasoning.
> 
> >  This fixes a bug in functionality, in
> > that at the moment HVM guests cannot boot with tapdisk and vhd format.
> > 
> > This is not a regression in xl functionality per se, since (AFAICT)
> > this has never worked.  However, given that 4.5 is the first release
> > without xend, this *does* represent a regression in functionality for
> > Xen as a whole (since before people using hvm guest with vhd on blktap
> > could use xend).
> > 
> > The fix is very simple and should only affect codepaths that already
> > don't work, so the risk of regressions should be very low.
> > 
> > While preparing this patch, I also noticed that cdroms will ignore the
> > backend parameter and treat everything as a file.  This is a bug but I
> > think it's a much less important one to address this late in the
> > release cycle.
> > ---
> >  tools/libxl/libxl_dm.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index b25b574..10f3090 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -797,11 +797,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> >                      continue;
> >                  }
> >  
> > -                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP)
> > +                if (disks[i].backend == LIBXL_DISK_BACKEND_TAP) {
> > +                    format = qemu_disk_format_string(LIBXL_DISK_FORMAT_RAW);
> >                      pdev_path = libxl__blktap_devpath(gc, disks[i].pdev_path,
> >                                                        disks[i].format);
> > -                else
> > +                } else {
> >                      pdev_path = disks[i].pdev_path;
> > +                }
> > +
> >  
> >                  /*
> >                   * Explicit sd disks are passed through as is.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 16:42:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 16:42:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XykKi-0000gk-11; Wed, 10 Dec 2014 16:41:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XykKg-0000gf-K5
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 16:41:46 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	F1/B1-20609-9C778845; Wed, 10 Dec 2014 16:41:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418229703!14255866!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13841 invoked from network); 10 Dec 2014 16:41:45 -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; 10 Dec 2014 16:41: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 sBAGfaIo017944
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 16:41:36 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
	sBAGfYk6017569
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 16:41:35 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
	sBAGfYhV026826; Wed, 10 Dec 2014 16:41:34 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 08:41:34 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6C992122BA7; Wed, 10 Dec 2014 11:41:31 -0500 (EST)
Date: Wed, 10 Dec 2014 11:41:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141210164131.GG4268@laptop.dumpdata.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com>
	<547DC617.8020107@citrix.com>
	<CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
	<1417600430.11243.1.camel@citrix.com>
	<21639.5225.596115.600016@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21639.5225.596115.600016@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ed Swierk <eswierk@skyportsystems.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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, Dec 09, 2014 at 03:25:29PM +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with bison 3.0"):
> > There was a point in time where the prevailing version of bison (or
> > maybe flex) in stable distro releases had a bug which meant these files
> > could not be regenerated easily on common distros. I don't recall the
> > details well enough to know if that time has now passed. Perhaps Ian J
> > does.
> 
> We use (essential) features found only in non-ancient versions of
> bison and flex.  The last time it was proposed to remove these
> pregenerated files, there were complaints from people who were using
> six-year-old bison and flex.
> 
> I think we should prioritise compatibility with new versions of bison
> and flex, and retain the pregenerated versions of people with
> incompatibly old version.
> 
> I think for 4.5 we should:
> 
>  * Regenerate the flex files with current wheezy's flex.  (I have
>    reviewed the diff in the generated code.  It produces trivial
>    changes which add declarations of xlu__cfg_yyget_column and
>    xlu__cfg_yyset_column, but no code body changes - see below.)
> 
>  * Take the patch from Ed and regenerate the bison files too.
> 
> 
> Konrad: can we have two freeze exceptions please ?
> 
> Risk analysis for Ed's patch:
> 
> Not taking the patch hurts systems with bison 2.7.1 or later:
> 
>   - Affected systems include Debian jessie, which will be
>     released during the lifetime of 4.5.

My understanding is that Jessie won't be using Xen 4.5 but Xen 4.4 And the
next version of Debian that will be released will be most likely using Xen 4.6.

However, this issue (building) would even show up in Xen 4.4 - but
I hadn't seen any Debian bugs about this?

> 
>   - Bison 2.7.1 was released in April 2013, a year and
>     a half ago.  So any system which is less than 18 months out of
>     date suffers pain from not updating.

Aye. Any other distro that will use Xen 4.5 that is new (Fedora 21
ships with 3.0.2) can hit this when building the RPMs or out of
tree.

> 
> Taking the patch hurts systems with old bison:
> 
>   - Bison 2.4.1 is known to work and was released in December 2008.
>     So systems which suffer pain from updating are using at least
>     4-year-old bison.

I am not following that. Are you saying that taking this patch will
break building of the sources when using bison 2.4.1 (like Fedora
Core 13 - which is what I use for my small regression testing vehicles).

That would imply an regression?
> 
>   - I have not investigated whether there are even older bison
>     versions which are still OK with updating.

Anything older than Fedora Core 13 is so ancient I would be scared
to run on contemporary hardware.
> 
> On the affected systems:
> 
>   - Attempts to build actually-from-source, or with modified
>     bison input, will definitely fail.
> 
>   - Some proportion of other builds will fail anyway due to
>     timestamp skew.
> 
> 
> Risk analysis for regenerating with current wheezy's flex:
> 
> There doesn't seem to be any actual change in the generated code apart
> from a few new function declarations and changes to #line directives.
> So the risk of breakage is small.  Furthermore:
> 
> Not taking the patch now means that our flex file will be out of date
> and may be regenerated and updated accidentally (or need to be
> regenerated) at some point in the future.  That means that (a)
> whatever risk of breakage we are taking might be discovered at an
> inconvenient time (b) additional build system trouble might result
> from an out of date file.
> 
> 
> There isn't AFAICT a necessary connection between these two but we
> normally regenerate both the bison and flex files together, if
> necessary, before making any changes to the input files.
> 
> Thanks,
> Ian.
> 
> 
> 
> diff --git a/tools/libxl/libxlu_cfg_l.c b/tools/libxl/libxlu_cfg_l.c
> index df352aa..450863a 100644
> --- a/tools/libxl/libxlu_cfg_l.c
> +++ b/tools/libxl/libxlu_cfg_l.c
> @@ -610,6 +610,10 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner );
>  
>  void xlu__cfg_yyset_lineno (int line_number ,yyscan_t yyscanner );
>  
> +int xlu__cfg_yyget_column  (yyscan_t yyscanner );
> +
> +void xlu__cfg_yyset_column (int column_no ,yyscan_t yyscanner );
> +
>  YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner );
>  
>  void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
> @@ -762,7 +766,7 @@ YY_DECL
>  #line 53 "libxlu_cfg_l.l"
>  
>  
> -#line 766 "libxlu_cfg_l.c"
> +#line 770 "libxlu_cfg_l.c"
>  
>      yylval = yylval_param;
>  
> @@ -971,7 +975,7 @@ YY_RULE_SETUP
>  #line 104 "libxlu_cfg_l.l"
>  YY_FATAL_ERROR( "flex scanner jammed" );
>  	YY_BREAK
> -#line 975 "libxlu_cfg_l.c"
> +#line 979 "libxlu_cfg_l.c"
>  case YY_STATE_EOF(INITIAL):
>  case YY_STATE_EOF(lexerr):
>  	yyterminate();
> diff --git a/tools/libxl/libxlu_cfg_l.h b/tools/libxl/libxlu_cfg_l.h
> index 4078302..151064e 100644
> --- a/tools/libxl/libxlu_cfg_l.h
> +++ b/tools/libxl/libxlu_cfg_l.h
> @@ -276,6 +276,10 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner );
>  
>  void xlu__cfg_yyset_lineno (int line_number ,yyscan_t yyscanner );
>  
> +int xlu__cfg_yyget_column  (yyscan_t yyscanner );
> +
> +void xlu__cfg_yyset_column (int column_no ,yyscan_t yyscanner );
> +
>  YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner );
>  
>  void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
> @@ -352,6 +356,6 @@ extern int xlu__cfg_yylex \
>  
>  #line 104 "libxlu_cfg_l.l"
>  
> -#line 356 "libxlu_cfg_l.h"
> +#line 360 "libxlu_cfg_l.h"
>  #undef xlu__cfg_yyIN_HEADER
>  #endif /* xlu__cfg_yyHEADER_H */
> diff --git a/tools/libxl/libxlu_disk_l.c b/tools/libxl/libxlu_disk_l.c
> index 2c6e8e3..beea7f9 100644
> --- a/tools/libxl/libxlu_disk_l.c
> +++ b/tools/libxl/libxlu_disk_l.c
> @@ -1011,6 +1011,10 @@ int xlu__disk_yyget_lineno (yyscan_t yyscanner );
>  
>  void xlu__disk_yyset_lineno (int line_number ,yyscan_t yyscanner );
>  
> +int xlu__disk_yyget_column  (yyscan_t yyscanner );
> +
> +void xlu__disk_yyset_column (int column_no ,yyscan_t yyscanner );
> +
>  /* Macros after this point can all be overridden by user definitions in
>   * section 1.
>   */
> @@ -1155,7 +1159,7 @@ YY_DECL
>  
>   /*----- the scanner rules which do the parsing -----*/
>  
> -#line 1159 "libxlu_disk_l.c"
> +#line 1163 "libxlu_disk_l.c"
>  
>  	if ( !yyg->yy_init )
>  		{
> @@ -1498,7 +1502,7 @@ YY_RULE_SETUP
>  #line 259 "libxlu_disk_l.l"
>  YY_FATAL_ERROR( "flex scanner jammed" );
>  	YY_BREAK
> -#line 1502 "libxlu_disk_l.c"
> +#line 1506 "libxlu_disk_l.c"
>  			case YY_STATE_EOF(INITIAL):
>  			case YY_STATE_EOF(LEXERR):
>  				yyterminate();
> diff --git a/tools/libxl/libxlu_disk_l.h b/tools/libxl/libxlu_disk_l.h
> index 08f60e5..f615582 100644
> --- a/tools/libxl/libxlu_disk_l.h
> +++ b/tools/libxl/libxlu_disk_l.h
> @@ -280,6 +280,10 @@ int xlu__disk_yyget_lineno (yyscan_t yyscanner );
>  
>  void xlu__disk_yyset_lineno (int line_number ,yyscan_t yyscanner );
>  
> +int xlu__disk_yyget_column  (yyscan_t yyscanner );
> +
> +void xlu__disk_yyset_column (int column_no ,yyscan_t yyscanner );
> +
>  /* Macros after this point can all be overridden by user definitions in
>   * section 1.
>   */
> @@ -346,6 +350,6 @@ extern int xlu__disk_yylex (yyscan_t yyscanner);
>  
>  #line 259 "libxlu_disk_l.l"
>  
> -#line 350 "libxlu_disk_l.h"
> +#line 354 "libxlu_disk_l.h"
>  #undef xlu__disk_yyIN_HEADER
>  #endif /* xlu__disk_yyHEADER_H */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 16:42:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 16:42:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XykKi-0000gk-11; Wed, 10 Dec 2014 16:41:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XykKg-0000gf-K5
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 16:41:46 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	F1/B1-20609-9C778845; Wed, 10 Dec 2014 16:41:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418229703!14255866!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13841 invoked from network); 10 Dec 2014 16:41:45 -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; 10 Dec 2014 16:41: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 sBAGfaIo017944
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 16:41:36 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
	sBAGfYk6017569
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 16:41:35 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
	sBAGfYhV026826; Wed, 10 Dec 2014 16:41:34 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 08:41:34 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6C992122BA7; Wed, 10 Dec 2014 11:41:31 -0500 (EST)
Date: Wed, 10 Dec 2014 11:41:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141210164131.GG4268@laptop.dumpdata.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com>
	<547DC617.8020107@citrix.com>
	<CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
	<1417600430.11243.1.camel@citrix.com>
	<21639.5225.596115.600016@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <21639.5225.596115.600016@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ed Swierk <eswierk@skyportsystems.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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, Dec 09, 2014 at 03:25:29PM +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with bison 3.0"):
> > There was a point in time where the prevailing version of bison (or
> > maybe flex) in stable distro releases had a bug which meant these files
> > could not be regenerated easily on common distros. I don't recall the
> > details well enough to know if that time has now passed. Perhaps Ian J
> > does.
> 
> We use (essential) features found only in non-ancient versions of
> bison and flex.  The last time it was proposed to remove these
> pregenerated files, there were complaints from people who were using
> six-year-old bison and flex.
> 
> I think we should prioritise compatibility with new versions of bison
> and flex, and retain the pregenerated versions of people with
> incompatibly old version.
> 
> I think for 4.5 we should:
> 
>  * Regenerate the flex files with current wheezy's flex.  (I have
>    reviewed the diff in the generated code.  It produces trivial
>    changes which add declarations of xlu__cfg_yyget_column and
>    xlu__cfg_yyset_column, but no code body changes - see below.)
> 
>  * Take the patch from Ed and regenerate the bison files too.
> 
> 
> Konrad: can we have two freeze exceptions please ?
> 
> Risk analysis for Ed's patch:
> 
> Not taking the patch hurts systems with bison 2.7.1 or later:
> 
>   - Affected systems include Debian jessie, which will be
>     released during the lifetime of 4.5.

My understanding is that Jessie won't be using Xen 4.5 but Xen 4.4 And the
next version of Debian that will be released will be most likely using Xen 4.6.

However, this issue (building) would even show up in Xen 4.4 - but
I hadn't seen any Debian bugs about this?

> 
>   - Bison 2.7.1 was released in April 2013, a year and
>     a half ago.  So any system which is less than 18 months out of
>     date suffers pain from not updating.

Aye. Any other distro that will use Xen 4.5 that is new (Fedora 21
ships with 3.0.2) can hit this when building the RPMs or out of
tree.

> 
> Taking the patch hurts systems with old bison:
> 
>   - Bison 2.4.1 is known to work and was released in December 2008.
>     So systems which suffer pain from updating are using at least
>     4-year-old bison.

I am not following that. Are you saying that taking this patch will
break building of the sources when using bison 2.4.1 (like Fedora
Core 13 - which is what I use for my small regression testing vehicles).

That would imply an regression?
> 
>   - I have not investigated whether there are even older bison
>     versions which are still OK with updating.

Anything older than Fedora Core 13 is so ancient I would be scared
to run on contemporary hardware.
> 
> On the affected systems:
> 
>   - Attempts to build actually-from-source, or with modified
>     bison input, will definitely fail.
> 
>   - Some proportion of other builds will fail anyway due to
>     timestamp skew.
> 
> 
> Risk analysis for regenerating with current wheezy's flex:
> 
> There doesn't seem to be any actual change in the generated code apart
> from a few new function declarations and changes to #line directives.
> So the risk of breakage is small.  Furthermore:
> 
> Not taking the patch now means that our flex file will be out of date
> and may be regenerated and updated accidentally (or need to be
> regenerated) at some point in the future.  That means that (a)
> whatever risk of breakage we are taking might be discovered at an
> inconvenient time (b) additional build system trouble might result
> from an out of date file.
> 
> 
> There isn't AFAICT a necessary connection between these two but we
> normally regenerate both the bison and flex files together, if
> necessary, before making any changes to the input files.
> 
> Thanks,
> Ian.
> 
> 
> 
> diff --git a/tools/libxl/libxlu_cfg_l.c b/tools/libxl/libxlu_cfg_l.c
> index df352aa..450863a 100644
> --- a/tools/libxl/libxlu_cfg_l.c
> +++ b/tools/libxl/libxlu_cfg_l.c
> @@ -610,6 +610,10 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner );
>  
>  void xlu__cfg_yyset_lineno (int line_number ,yyscan_t yyscanner );
>  
> +int xlu__cfg_yyget_column  (yyscan_t yyscanner );
> +
> +void xlu__cfg_yyset_column (int column_no ,yyscan_t yyscanner );
> +
>  YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner );
>  
>  void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
> @@ -762,7 +766,7 @@ YY_DECL
>  #line 53 "libxlu_cfg_l.l"
>  
>  
> -#line 766 "libxlu_cfg_l.c"
> +#line 770 "libxlu_cfg_l.c"
>  
>      yylval = yylval_param;
>  
> @@ -971,7 +975,7 @@ YY_RULE_SETUP
>  #line 104 "libxlu_cfg_l.l"
>  YY_FATAL_ERROR( "flex scanner jammed" );
>  	YY_BREAK
> -#line 975 "libxlu_cfg_l.c"
> +#line 979 "libxlu_cfg_l.c"
>  case YY_STATE_EOF(INITIAL):
>  case YY_STATE_EOF(lexerr):
>  	yyterminate();
> diff --git a/tools/libxl/libxlu_cfg_l.h b/tools/libxl/libxlu_cfg_l.h
> index 4078302..151064e 100644
> --- a/tools/libxl/libxlu_cfg_l.h
> +++ b/tools/libxl/libxlu_cfg_l.h
> @@ -276,6 +276,10 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner );
>  
>  void xlu__cfg_yyset_lineno (int line_number ,yyscan_t yyscanner );
>  
> +int xlu__cfg_yyget_column  (yyscan_t yyscanner );
> +
> +void xlu__cfg_yyset_column (int column_no ,yyscan_t yyscanner );
> +
>  YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner );
>  
>  void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
> @@ -352,6 +356,6 @@ extern int xlu__cfg_yylex \
>  
>  #line 104 "libxlu_cfg_l.l"
>  
> -#line 356 "libxlu_cfg_l.h"
> +#line 360 "libxlu_cfg_l.h"
>  #undef xlu__cfg_yyIN_HEADER
>  #endif /* xlu__cfg_yyHEADER_H */
> diff --git a/tools/libxl/libxlu_disk_l.c b/tools/libxl/libxlu_disk_l.c
> index 2c6e8e3..beea7f9 100644
> --- a/tools/libxl/libxlu_disk_l.c
> +++ b/tools/libxl/libxlu_disk_l.c
> @@ -1011,6 +1011,10 @@ int xlu__disk_yyget_lineno (yyscan_t yyscanner );
>  
>  void xlu__disk_yyset_lineno (int line_number ,yyscan_t yyscanner );
>  
> +int xlu__disk_yyget_column  (yyscan_t yyscanner );
> +
> +void xlu__disk_yyset_column (int column_no ,yyscan_t yyscanner );
> +
>  /* Macros after this point can all be overridden by user definitions in
>   * section 1.
>   */
> @@ -1155,7 +1159,7 @@ YY_DECL
>  
>   /*----- the scanner rules which do the parsing -----*/
>  
> -#line 1159 "libxlu_disk_l.c"
> +#line 1163 "libxlu_disk_l.c"
>  
>  	if ( !yyg->yy_init )
>  		{
> @@ -1498,7 +1502,7 @@ YY_RULE_SETUP
>  #line 259 "libxlu_disk_l.l"
>  YY_FATAL_ERROR( "flex scanner jammed" );
>  	YY_BREAK
> -#line 1502 "libxlu_disk_l.c"
> +#line 1506 "libxlu_disk_l.c"
>  			case YY_STATE_EOF(INITIAL):
>  			case YY_STATE_EOF(LEXERR):
>  				yyterminate();
> diff --git a/tools/libxl/libxlu_disk_l.h b/tools/libxl/libxlu_disk_l.h
> index 08f60e5..f615582 100644
> --- a/tools/libxl/libxlu_disk_l.h
> +++ b/tools/libxl/libxlu_disk_l.h
> @@ -280,6 +280,10 @@ int xlu__disk_yyget_lineno (yyscan_t yyscanner );
>  
>  void xlu__disk_yyset_lineno (int line_number ,yyscan_t yyscanner );
>  
> +int xlu__disk_yyget_column  (yyscan_t yyscanner );
> +
> +void xlu__disk_yyset_column (int column_no ,yyscan_t yyscanner );
> +
>  /* Macros after this point can all be overridden by user definitions in
>   * section 1.
>   */
> @@ -346,6 +350,6 @@ extern int xlu__disk_yylex (yyscan_t yyscanner);
>  
>  #line 259 "libxlu_disk_l.l"
>  
> -#line 350 "libxlu_disk_l.h"
> +#line 354 "libxlu_disk_l.h"
>  #undef xlu__disk_yyIN_HEADER
>  #endif /* xlu__disk_yyHEADER_H */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 16:44:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 16: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 1XykMy-0000pU-Ia; Wed, 10 Dec 2014 16:44: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 1XykMx-0000pK-6t
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 16:44:07 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	8F/72-23865-65878845; Wed, 10 Dec 2014 16:44:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418229844!12414688!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 28003 invoked from network); 10 Dec 2014 16:44:05 -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 Dec 2014 16:44:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202514869"
Message-ID: <1418229840.3505.88.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 10 Dec 2014 16:44:00 +0000
In-Reply-To: <20141210164131.GG4268@laptop.dumpdata.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com> <547DC617.8020107@citrix.com>
	<CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
	<1417600430.11243.1.camel@citrix.com>
	<21639.5225.596115.600016@mariner.uk.xensource.com>
	<20141210164131.GG4268@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ed Swierk <eswierk@skyportsystems.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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-12-10 at 11:41 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 09, 2014 at 03:25:29PM +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with bison 3.0"):
> > > There was a point in time where the prevailing version of bison (or
> > > maybe flex) in stable distro releases had a bug which meant these files
> > > could not be regenerated easily on common distros. I don't recall the
> > > details well enough to know if that time has now passed. Perhaps Ian J
> > > does.
> > 
> > We use (essential) features found only in non-ancient versions of
> > bison and flex.  The last time it was proposed to remove these
> > pregenerated files, there were complaints from people who were using
> > six-year-old bison and flex.
> > 
> > I think we should prioritise compatibility with new versions of bison
> > and flex, and retain the pregenerated versions of people with
> > incompatibly old version.
> > 
> > I think for 4.5 we should:
> > 
> >  * Regenerate the flex files with current wheezy's flex.  (I have
> >    reviewed the diff in the generated code.  It produces trivial
> >    changes which add declarations of xlu__cfg_yyget_column and
> >    xlu__cfg_yyset_column, but no code body changes - see below.)
> > 
> >  * Take the patch from Ed and regenerate the bison files too.
> > 
> > 
> > Konrad: can we have two freeze exceptions please ?
> > 
> > Risk analysis for Ed's patch:
> > 
> > Not taking the patch hurts systems with bison 2.7.1 or later:
> > 
> >   - Affected systems include Debian jessie, which will be
> >     released during the lifetime of 4.5.
> 
> My understanding is that Jessie won't be using Xen 4.5 but Xen 4.4 And the
> next version of Debian that will be released will be most likely using Xen 4.6.

What Jessie (or Fedora etc) has available in packages has no real
bearing on whether people might run Xen 4.5 on them, plenty of people
will still build from source, including developers.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 16:44:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 16: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 1XykMy-0000pU-Ia; Wed, 10 Dec 2014 16:44: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 1XykMx-0000pK-6t
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 16:44:07 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	8F/72-23865-65878845; Wed, 10 Dec 2014 16:44:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418229844!12414688!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 28003 invoked from network); 10 Dec 2014 16:44:05 -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 Dec 2014 16:44:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202514869"
Message-ID: <1418229840.3505.88.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 10 Dec 2014 16:44:00 +0000
In-Reply-To: <20141210164131.GG4268@laptop.dumpdata.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com> <547DC617.8020107@citrix.com>
	<CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
	<1417600430.11243.1.camel@citrix.com>
	<21639.5225.596115.600016@mariner.uk.xensource.com>
	<20141210164131.GG4268@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ed Swierk <eswierk@skyportsystems.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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-12-10 at 11:41 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 09, 2014 at 03:25:29PM +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with bison 3.0"):
> > > There was a point in time where the prevailing version of bison (or
> > > maybe flex) in stable distro releases had a bug which meant these files
> > > could not be regenerated easily on common distros. I don't recall the
> > > details well enough to know if that time has now passed. Perhaps Ian J
> > > does.
> > 
> > We use (essential) features found only in non-ancient versions of
> > bison and flex.  The last time it was proposed to remove these
> > pregenerated files, there were complaints from people who were using
> > six-year-old bison and flex.
> > 
> > I think we should prioritise compatibility with new versions of bison
> > and flex, and retain the pregenerated versions of people with
> > incompatibly old version.
> > 
> > I think for 4.5 we should:
> > 
> >  * Regenerate the flex files with current wheezy's flex.  (I have
> >    reviewed the diff in the generated code.  It produces trivial
> >    changes which add declarations of xlu__cfg_yyget_column and
> >    xlu__cfg_yyset_column, but no code body changes - see below.)
> > 
> >  * Take the patch from Ed and regenerate the bison files too.
> > 
> > 
> > Konrad: can we have two freeze exceptions please ?
> > 
> > Risk analysis for Ed's patch:
> > 
> > Not taking the patch hurts systems with bison 2.7.1 or later:
> > 
> >   - Affected systems include Debian jessie, which will be
> >     released during the lifetime of 4.5.
> 
> My understanding is that Jessie won't be using Xen 4.5 but Xen 4.4 And the
> next version of Debian that will be released will be most likely using Xen 4.6.

What Jessie (or Fedora etc) has available in packages has no real
bearing on whether people might run Xen 4.5 on them, plenty of people
will still build from source, including developers.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 17:03:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17: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 1XykfE-0001iB-DB; Wed, 10 Dec 2014 17:03:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XykfD-0001gw-6r
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 17:02:59 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	2F/12-17694-2CC78845; Wed, 10 Dec 2014 17:02:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418230976!12418596!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25082 invoked from network); 10 Dec 2014 17:02:57 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 17:02:57 -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 sBAH2pjA017433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 17:02: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
	sBAH2neF015843
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Dec 2014 17:02:50 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
	sBAH2mFh015810; Wed, 10 Dec 2014 17:02:49 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 09:02:48 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9599D122BDD; Wed, 10 Dec 2014 12:02:47 -0500 (EST)
Date: Wed, 10 Dec 2014 12:02:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210170247.GI4268@laptop.dumpdata.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com>
	<547DC617.8020107@citrix.com>
	<CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
	<1417600430.11243.1.camel@citrix.com>
	<21639.5225.596115.600016@mariner.uk.xensource.com>
	<20141210164131.GG4268@laptop.dumpdata.com>
	<1418229840.3505.88.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418229840.3505.88.camel@citrix.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>,
	Ed Swierk <eswierk@skyportsystems.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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, Dec 10, 2014 at 04:44:00PM +0000, Ian Campbell wrote:
> On Wed, 2014-12-10 at 11:41 -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 09, 2014 at 03:25:29PM +0000, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with bison 3.0"):
> > > > There was a point in time where the prevailing version of bison (or
> > > > maybe flex) in stable distro releases had a bug which meant these files
> > > > could not be regenerated easily on common distros. I don't recall the
> > > > details well enough to know if that time has now passed. Perhaps Ian J
> > > > does.
> > > 
> > > We use (essential) features found only in non-ancient versions of
> > > bison and flex.  The last time it was proposed to remove these
> > > pregenerated files, there were complaints from people who were using
> > > six-year-old bison and flex.
> > > 
> > > I think we should prioritise compatibility with new versions of bison
> > > and flex, and retain the pregenerated versions of people with
> > > incompatibly old version.
> > > 
> > > I think for 4.5 we should:
> > > 
> > >  * Regenerate the flex files with current wheezy's flex.  (I have
> > >    reviewed the diff in the generated code.  It produces trivial
> > >    changes which add declarations of xlu__cfg_yyget_column and
> > >    xlu__cfg_yyset_column, but no code body changes - see below.)
> > > 
> > >  * Take the patch from Ed and regenerate the bison files too.
> > > 
> > > 
> > > Konrad: can we have two freeze exceptions please ?
> > > 
> > > Risk analysis for Ed's patch:
> > > 
> > > Not taking the patch hurts systems with bison 2.7.1 or later:
> > > 
> > >   - Affected systems include Debian jessie, which will be
> > >     released during the lifetime of 4.5.
> > 
> > My understanding is that Jessie won't be using Xen 4.5 but Xen 4.4 And the
> > next version of Debian that will be released will be most likely using Xen 4.6.
> 
> What Jessie (or Fedora etc) has available in packages has no real
> bearing on whether people might run Xen 4.5 on them, plenty of people
> will still build from source, including developers.

My initial reasoning for not giving the exception was that this bug did
not affect users.

But it does affect developers and distros - which in number comparison to
users make a miniscule amount.

However, from an perspective of bug-fixing, they (developers) are the most
important - not users. Hence making the environement for them to fix issues
and develop new features without much fuss is paramount. As in, I do not want
them to start looking at fixing an issue/developing, and this crops up and
they say "WTF? I just want to add this tiny libxl feature and I get this!
This is a quagmire".

Based on that reasoning (And thank you for pointing out the developers
factors), I retract my earlier reason and:

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

P.S.
And I just verified that this does not cause regressions with bison 2.4.1, so
that is OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 17:03:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17: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 1XykfE-0001iB-DB; Wed, 10 Dec 2014 17:03:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XykfD-0001gw-6r
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 17:02:59 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	2F/12-17694-2CC78845; Wed, 10 Dec 2014 17:02:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418230976!12418596!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25082 invoked from network); 10 Dec 2014 17:02:57 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 17:02:57 -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 sBAH2pjA017433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 17:02: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
	sBAH2neF015843
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Dec 2014 17:02:50 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
	sBAH2mFh015810; Wed, 10 Dec 2014 17:02:49 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 09:02:48 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 9599D122BDD; Wed, 10 Dec 2014 12:02:47 -0500 (EST)
Date: Wed, 10 Dec 2014 12:02:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210170247.GI4268@laptop.dumpdata.com>
References: <1417325015-22354-1-git-send-email-eswierk@skyportsystems.com>
	<1417426933.23604.77.camel@citrix.com>
	<20141201121955.GB19889@zion.uk.xensource.com>
	<1417528036.24320.32.camel@citrix.com>
	<547DC617.8020107@citrix.com>
	<CAO_EM_m72QsRdWcrYNg_VCcFKuexyZFZyF2waJyTvnn-OO8DxA@mail.gmail.com>
	<1417600430.11243.1.camel@citrix.com>
	<21639.5225.596115.600016@mariner.uk.xensource.com>
	<20141210164131.GG4268@laptop.dumpdata.com>
	<1418229840.3505.88.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418229840.3505.88.camel@citrix.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>,
	Ed Swierk <eswierk@skyportsystems.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with
 bison 3.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, Dec 10, 2014 at 04:44:00PM +0000, Ian Campbell wrote:
> On Wed, 2014-12-10 at 11:41 -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 09, 2014 at 03:25:29PM +0000, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with bison 3.0"):
> > > > There was a point in time where the prevailing version of bison (or
> > > > maybe flex) in stable distro releases had a bug which meant these files
> > > > could not be regenerated easily on common distros. I don't recall the
> > > > details well enough to know if that time has now passed. Perhaps Ian J
> > > > does.
> > > 
> > > We use (essential) features found only in non-ancient versions of
> > > bison and flex.  The last time it was proposed to remove these
> > > pregenerated files, there were complaints from people who were using
> > > six-year-old bison and flex.
> > > 
> > > I think we should prioritise compatibility with new versions of bison
> > > and flex, and retain the pregenerated versions of people with
> > > incompatibly old version.
> > > 
> > > I think for 4.5 we should:
> > > 
> > >  * Regenerate the flex files with current wheezy's flex.  (I have
> > >    reviewed the diff in the generated code.  It produces trivial
> > >    changes which add declarations of xlu__cfg_yyget_column and
> > >    xlu__cfg_yyset_column, but no code body changes - see below.)
> > > 
> > >  * Take the patch from Ed and regenerate the bison files too.
> > > 
> > > 
> > > Konrad: can we have two freeze exceptions please ?
> > > 
> > > Risk analysis for Ed's patch:
> > > 
> > > Not taking the patch hurts systems with bison 2.7.1 or later:
> > > 
> > >   - Affected systems include Debian jessie, which will be
> > >     released during the lifetime of 4.5.
> > 
> > My understanding is that Jessie won't be using Xen 4.5 but Xen 4.4 And the
> > next version of Debian that will be released will be most likely using Xen 4.6.
> 
> What Jessie (or Fedora etc) has available in packages has no real
> bearing on whether people might run Xen 4.5 on them, plenty of people
> will still build from source, including developers.

My initial reasoning for not giving the exception was that this bug did
not affect users.

But it does affect developers and distros - which in number comparison to
users make a miniscule amount.

However, from an perspective of bug-fixing, they (developers) are the most
important - not users. Hence making the environement for them to fix issues
and develop new features without much fuss is paramount. As in, I do not want
them to start looking at fixing an issue/developing, and this crops up and
they say "WTF? I just want to add this tiny libxl feature and I get this!
This is a quagmire".

Based on that reasoning (And thank you for pointing out the developers
factors), I retract my earlier reason and:

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

P.S.
And I just verified that this does not cause regressions with bison 2.4.1, so
that is OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 17:09:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17: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 1Xykkv-0001zK-7x; Wed, 10 Dec 2014 17:08: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 1Xykkt-0001zF-Jm
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 17:08:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FF/3B-09842-22E78845; Wed, 10 Dec 2014 17:08:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418231329!14707981!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30232 invoked from network); 10 Dec 2014 17:08:50 -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; 10 Dec 2014 17:08:50 -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 sBAH8ibH024945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 17:08:45 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
	sBAH8ifg028196
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 17:08:44 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
	sBAH8h2Q002941; Wed, 10 Dec 2014 17:08:44 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 09:08:43 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BE0BE122BEF; Wed, 10 Dec 2014 12:08:42 -0500 (EST)
Date: Wed, 10 Dec 2014 12:08:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20141210170842.GL4268@laptop.dumpdata.com>
References: <54857995020000780004DA2D@mail.emea.novell.com>
	<54872B02.50300@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54872B02.50300@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Kevin Tian <kevin.tian@intel.com>, Jan Beulich <JBeulich@suse.com>,
	Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
	handle_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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 06:01:54PM +0100, Roger Pau Monn=E9 wrote:
> El 08/12/14 a les 10.12, Jan Beulich ha escrit:
> > PVH guests accessing I/O ports via string ops is not supported yet.
> > =

> > Reported-by: Roger Pau Monn=E9<roger.pau@citrix.com>
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> =

> This looks fine to me (at least it doesn't break the existing IN/OUT
> users), and seems the best solution 4.5 wise:
> =

> Acked-by: Roger Pau Monn=E9 <roger.pau@citrix.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> =

> For 4.6 I think we need to start using a different hvm_io_bitmap for PVH
> Dom0 that allows direct access to the IO ports, bypassing the vmexit and
> simplifying the code in Xen (this would also fix INS/OUTS). Still not
> sure what should be done for PVH DomUs, specially when PVH gains support
> for pci-passthrough.
> =

> Roger.
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 17:09:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17: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 1Xykkv-0001zK-7x; Wed, 10 Dec 2014 17:08: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 1Xykkt-0001zF-Jm
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 17:08:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FF/3B-09842-22E78845; Wed, 10 Dec 2014 17:08:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418231329!14707981!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30232 invoked from network); 10 Dec 2014 17:08:50 -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; 10 Dec 2014 17:08:50 -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 sBAH8ibH024945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 17:08:45 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
	sBAH8ifg028196
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 17:08:44 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
	sBAH8h2Q002941; Wed, 10 Dec 2014 17:08:44 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 09:08:43 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BE0BE122BEF; Wed, 10 Dec 2014 12:08:42 -0500 (EST)
Date: Wed, 10 Dec 2014 12:08:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20141210170842.GL4268@laptop.dumpdata.com>
References: <54857995020000780004DA2D@mail.emea.novell.com>
	<54872B02.50300@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54872B02.50300@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Kevin Tian <kevin.tian@intel.com>, Jan Beulich <JBeulich@suse.com>,
	Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v2] VMX: don't allow PVH to reach
	handle_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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 06:01:54PM +0100, Roger Pau Monn=E9 wrote:
> El 08/12/14 a les 10.12, Jan Beulich ha escrit:
> > PVH guests accessing I/O ports via string ops is not supported yet.
> > =

> > Reported-by: Roger Pau Monn=E9<roger.pau@citrix.com>
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> =

> This looks fine to me (at least it doesn't break the existing IN/OUT
> users), and seems the best solution 4.5 wise:
> =

> Acked-by: Roger Pau Monn=E9 <roger.pau@citrix.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> =

> For 4.6 I think we need to start using a different hvm_io_bitmap for PVH
> Dom0 that allows direct access to the IO ports, bypassing the vmexit and
> simplifying the code in Xen (this would also fix INS/OUTS). Still not
> sure what should be done for PVH DomUs, specially when PVH gains support
> for pci-passthrough.
> =

> Roger.
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 17:14:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17: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 1Xykps-0002Wk-4a; Wed, 10 Dec 2014 17:14: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 1Xykpq-0002Wf-Ns
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 17:13:58 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	F7/F4-08051-65F78845; Wed, 10 Dec 2014 17:13:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418231635!10920217!1
X-Originating-IP: [156.151.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 9047 invoked from network); 10 Dec 2014 17:13:57 -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; 10 Dec 2014 17:13:57 -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 sBAHDmMS016529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 17:13:51 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
	sBAHDlTC015382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 17:13:48 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
	sBAHDkx9000935; Wed, 10 Dec 2014 17:13:47 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 09:13:46 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A1DC3122C05; Wed, 10 Dec 2014 12:13:45 -0500 (EST)
Date: Wed, 10 Dec 2014 12:13:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141210171345.GM4268@laptop.dumpdata.com>
References: <20141209162048.GB9585@laptop.dumpdata.com>
	<1418143402-29674-1-git-send-email-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418143402-29674-1-git-send-email-andrew.cooper3@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>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 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 Tue, Dec 09, 2014 at 04:43:22PM +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.
> 
> Coverity also complains about passing a non-NUL terminated string to
> xc_flask_context_to_sid().  xc_flask_context_to_sid() doesn't actually take a
> NUL terminated string, but it does take a char* which, in context, used to be
> a string, which is why Coverity complains.
> 
> One solution would be to use strdup(ctx) which is simpler than a
> strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated
> string being used with xc_flask_context_to_sid().
> 
> However, ctx is strictly an input to the hypercall and is not mutated along
> the way.  Both these issues can be fixed, and the error logic simplified, by
> not duplicating ctx in the first place.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Coverity-IDs: 1055305 1055721
> Acked-by: 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>
> 
> ---
> v2: Expand the commit message.  No code change

Thank you.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> ---
>  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 f83e33d..2aa0dc7 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -2125,8 +2125,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;
>  
> @@ -2136,28 +2134,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 Wed Dec 10 17:14:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17: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 1Xykps-0002Wk-4a; Wed, 10 Dec 2014 17:14: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 1Xykpq-0002Wf-Ns
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 17:13:58 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	F7/F4-08051-65F78845; Wed, 10 Dec 2014 17:13:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418231635!10920217!1
X-Originating-IP: [156.151.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 9047 invoked from network); 10 Dec 2014 17:13:57 -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; 10 Dec 2014 17:13:57 -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 sBAHDmMS016529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 17:13:51 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
	sBAHDlTC015382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 17:13:48 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
	sBAHDkx9000935; Wed, 10 Dec 2014 17:13:47 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 09:13:46 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A1DC3122C05; Wed, 10 Dec 2014 12:13:45 -0500 (EST)
Date: Wed, 10 Dec 2014 12:13:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141210171345.GM4268@laptop.dumpdata.com>
References: <20141209162048.GB9585@laptop.dumpdata.com>
	<1418143402-29674-1-git-send-email-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418143402-29674-1-git-send-email-andrew.cooper3@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>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 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 Tue, Dec 09, 2014 at 04:43:22PM +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.
> 
> Coverity also complains about passing a non-NUL terminated string to
> xc_flask_context_to_sid().  xc_flask_context_to_sid() doesn't actually take a
> NUL terminated string, but it does take a char* which, in context, used to be
> a string, which is why Coverity complains.
> 
> One solution would be to use strdup(ctx) which is simpler than a
> strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated
> string being used with xc_flask_context_to_sid().
> 
> However, ctx is strictly an input to the hypercall and is not mutated along
> the way.  Both these issues can be fixed, and the error logic simplified, by
> not duplicating ctx in the first place.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Coverity-IDs: 1055305 1055721
> Acked-by: 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>
> 
> ---
> v2: Expand the commit message.  No code change

Thank you.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> ---
>  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 f83e33d..2aa0dc7 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -2125,8 +2125,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;
>  
> @@ -2136,28 +2134,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 Wed Dec 10 17:22:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xykxd-0002hF-4b; Wed, 10 Dec 2014 17:22: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 1Xykxc-0002hA-CS
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 17:22:00 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	0F/B4-02696-73188845; Wed, 10 Dec 2014 17:21:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418232117!9605824!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18316 invoked from network); 10 Dec 2014 17:21:58 -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; 10 Dec 2014 17:21:58 -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 sBAHLttm010757
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 17:21:56 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
	sBAHLsMa023046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 17:21: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
	sBAHLscS014310; Wed, 10 Dec 2014 17:21:54 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 09:21:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E908D122C27; Wed, 10 Dec 2014 12:21:52 -0500 (EST)
Date: Wed, 10 Dec 2014 12:21:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141210172152.GR4268@laptop.dumpdata.com>
References: <54860EA4.7090705@oracle.com>
	<1418135110-7194-1-git-send-email-vkuznets@redhat.com>
	<5487620E.8060807@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5487620E.8060807@oracle.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, Vitaly Kuznetsov <vkuznets@redhat.com>,
	Andrew Jones <drjones@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v2] xen/blkfront: remove redundant flush_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, Dec 09, 2014 at 03:56:46PM -0500, Boris Ostrovsky wrote:
> On 12/09/2014 09:25 AM, Vitaly Kuznetsov wrote:
> >flush_op is unambiguously defined by feature_flush:
> >     REQ_FUA | REQ_FLUSH -> BLKIF_OP_WRITE_BARRIER
> >     REQ_FLUSH -> BLKIF_OP_FLUSH_DISKCACHE
> >     0 -> 0
> >and thus can be removed. This is just a cleanup.
> >
> >The patch was suggested by Boris Ostrovsky.
> >
> >Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> 
> 
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Thank you.

I am testing this and the     xen/blkfront: improve protection against issuing unsupported REQ_FUA
right now for 3.19

> 
> 
> >---
> >Changes from v1:
> >    Future-proof feature_flush against new flags [Boris Ostrovsky].
> >
> >The patch is supposed to be applied after "xen/blkfront: improve protection
> >against issuing unsupported REQ_FUA".
> >---
> >  drivers/block/xen-blkfront.c | 51 +++++++++++++++++++++++++++-----------------
> >  1 file changed, 31 insertions(+), 20 deletions(-)
> >
> >diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> >index 2e6c103..2236c6f 100644
> >--- a/drivers/block/xen-blkfront.c
> >+++ b/drivers/block/xen-blkfront.c
> >@@ -126,7 +126,6 @@ struct blkfront_info
> >  	unsigned int persistent_gnts_c;
> >  	unsigned long shadow_free;
> >  	unsigned int feature_flush;
> >-	unsigned int flush_op;
> >  	unsigned int feature_discard:1;
> >  	unsigned int feature_secdiscard:1;
> >  	unsigned int discard_granularity;
> >@@ -479,7 +478,19 @@ static int blkif_queue_request(struct request *req)
> >  				 * way.  (It's also a FLUSH+FUA, since it is
> >  				 * guaranteed ordered WRT previous writes.)
> >  				 */
> >-				ring_req->operation = info->flush_op;
> >+				switch (info->feature_flush &
> >+					((REQ_FLUSH|REQ_FUA))) {
> >+				case REQ_FLUSH|REQ_FUA:
> >+					ring_req->operation =
> >+						BLKIF_OP_WRITE_BARRIER;
> >+					break;
> >+				case REQ_FLUSH:
> >+					ring_req->operation =
> >+						BLKIF_OP_FLUSH_DISKCACHE;
> >+					break;
> >+				default:
> >+					ring_req->operation = 0;
> >+				}
> >  			}
> >  			ring_req->u.rw.nr_segments = nseg;
> >  		}
> >@@ -685,20 +696,26 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size,
> >  	return 0;
> >  }
> >+static const char *flush_info(unsigned int feature_flush)
> >+{
> >+	switch (feature_flush & ((REQ_FLUSH | REQ_FUA))) {
> >+	case REQ_FLUSH|REQ_FUA:
> >+		return "barrier: enabled;";
> >+	case REQ_FLUSH:
> >+		return "flush diskcache: enabled;";
> >+	default:
> >+		return "barrier or flush: disabled;";
> >+	}
> >+}
> >  static void xlvbd_flush(struct blkfront_info *info)
> >  {
> >  	blk_queue_flush(info->rq, info->feature_flush);
> >-	printk(KERN_INFO "blkfront: %s: %s: %s %s %s %s %s\n",
> >-	       info->gd->disk_name,
> >-	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> >-		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
> >-		"flush diskcache" : "barrier or flush"),
> >-	       info->feature_flush ? "enabled;" : "disabled;",
> >-	       "persistent grants:",
> >-	       info->feature_persistent ? "enabled;" : "disabled;",
> >-	       "indirect descriptors:",
> >-	       info->max_indirect_segments ? "enabled;" : "disabled;");
> >+	pr_info("blkfront: %s: %s %s %s %s %s\n",
> >+		info->gd->disk_name, flush_info(info->feature_flush),
> >+		"persistent grants:", info->feature_persistent ?
> >+		"enabled;" : "disabled;", "indirect descriptors:",
> >+		info->max_indirect_segments ? "enabled;" : "disabled;");
> >  }
> >  static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
> >@@ -1190,7 +1207,6 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> >  				if (error == -EOPNOTSUPP)
> >  					error = 0;
> >  				info->feature_flush = 0;
> >-				info->flush_op = 0;
> >  				xlvbd_flush(info);
> >  			}
> >  			/* fall through */
> >@@ -1810,7 +1826,6 @@ static void blkfront_connect(struct blkfront_info *info)
> >  		physical_sector_size = sector_size;
> >  	info->feature_flush = 0;
> >-	info->flush_op = 0;
> >  	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> >  			    "feature-barrier", "%d", &barrier,
> >@@ -1823,10 +1838,8 @@ static void blkfront_connect(struct blkfront_info *info)
> >  	 *
> >  	 * If there are barriers, then we use flush.
> >  	 */
> >-	if (!err && barrier) {
> >+	if (!err && barrier)
> >  		info->feature_flush = REQ_FLUSH | REQ_FUA;
> >-		info->flush_op = BLKIF_OP_WRITE_BARRIER;
> >-	}
> >  	/*
> >  	 * And if there is "feature-flush-cache" use that above
> >  	 * barriers.
> >@@ -1835,10 +1848,8 @@ static void blkfront_connect(struct blkfront_info *info)
> >  			    "feature-flush-cache", "%d", &flush,
> >  			    NULL);
> >-	if (!err && flush) {
> >+	if (!err && flush)
> >  		info->feature_flush = REQ_FLUSH;
> >-		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
> >-	}
> >  	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> >  			    "feature-discard", "%d", &discard,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 17:22:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xykxd-0002hF-4b; Wed, 10 Dec 2014 17:22: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 1Xykxc-0002hA-CS
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 17:22:00 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	0F/B4-02696-73188845; Wed, 10 Dec 2014 17:21:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418232117!9605824!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18316 invoked from network); 10 Dec 2014 17:21:58 -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; 10 Dec 2014 17:21:58 -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 sBAHLttm010757
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 17:21:56 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
	sBAHLsMa023046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 17:21: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
	sBAHLscS014310; Wed, 10 Dec 2014 17:21:54 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 09:21:53 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E908D122C27; Wed, 10 Dec 2014 12:21:52 -0500 (EST)
Date: Wed, 10 Dec 2014 12:21:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141210172152.GR4268@laptop.dumpdata.com>
References: <54860EA4.7090705@oracle.com>
	<1418135110-7194-1-git-send-email-vkuznets@redhat.com>
	<5487620E.8060807@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5487620E.8060807@oracle.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, Vitaly Kuznetsov <vkuznets@redhat.com>,
	Andrew Jones <drjones@redhat.com>, David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v2] xen/blkfront: remove redundant flush_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, Dec 09, 2014 at 03:56:46PM -0500, Boris Ostrovsky wrote:
> On 12/09/2014 09:25 AM, Vitaly Kuznetsov wrote:
> >flush_op is unambiguously defined by feature_flush:
> >     REQ_FUA | REQ_FLUSH -> BLKIF_OP_WRITE_BARRIER
> >     REQ_FLUSH -> BLKIF_OP_FLUSH_DISKCACHE
> >     0 -> 0
> >and thus can be removed. This is just a cleanup.
> >
> >The patch was suggested by Boris Ostrovsky.
> >
> >Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> 
> 
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Thank you.

I am testing this and the     xen/blkfront: improve protection against issuing unsupported REQ_FUA
right now for 3.19

> 
> 
> >---
> >Changes from v1:
> >    Future-proof feature_flush against new flags [Boris Ostrovsky].
> >
> >The patch is supposed to be applied after "xen/blkfront: improve protection
> >against issuing unsupported REQ_FUA".
> >---
> >  drivers/block/xen-blkfront.c | 51 +++++++++++++++++++++++++++-----------------
> >  1 file changed, 31 insertions(+), 20 deletions(-)
> >
> >diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> >index 2e6c103..2236c6f 100644
> >--- a/drivers/block/xen-blkfront.c
> >+++ b/drivers/block/xen-blkfront.c
> >@@ -126,7 +126,6 @@ struct blkfront_info
> >  	unsigned int persistent_gnts_c;
> >  	unsigned long shadow_free;
> >  	unsigned int feature_flush;
> >-	unsigned int flush_op;
> >  	unsigned int feature_discard:1;
> >  	unsigned int feature_secdiscard:1;
> >  	unsigned int discard_granularity;
> >@@ -479,7 +478,19 @@ static int blkif_queue_request(struct request *req)
> >  				 * way.  (It's also a FLUSH+FUA, since it is
> >  				 * guaranteed ordered WRT previous writes.)
> >  				 */
> >-				ring_req->operation = info->flush_op;
> >+				switch (info->feature_flush &
> >+					((REQ_FLUSH|REQ_FUA))) {
> >+				case REQ_FLUSH|REQ_FUA:
> >+					ring_req->operation =
> >+						BLKIF_OP_WRITE_BARRIER;
> >+					break;
> >+				case REQ_FLUSH:
> >+					ring_req->operation =
> >+						BLKIF_OP_FLUSH_DISKCACHE;
> >+					break;
> >+				default:
> >+					ring_req->operation = 0;
> >+				}
> >  			}
> >  			ring_req->u.rw.nr_segments = nseg;
> >  		}
> >@@ -685,20 +696,26 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size,
> >  	return 0;
> >  }
> >+static const char *flush_info(unsigned int feature_flush)
> >+{
> >+	switch (feature_flush & ((REQ_FLUSH | REQ_FUA))) {
> >+	case REQ_FLUSH|REQ_FUA:
> >+		return "barrier: enabled;";
> >+	case REQ_FLUSH:
> >+		return "flush diskcache: enabled;";
> >+	default:
> >+		return "barrier or flush: disabled;";
> >+	}
> >+}
> >  static void xlvbd_flush(struct blkfront_info *info)
> >  {
> >  	blk_queue_flush(info->rq, info->feature_flush);
> >-	printk(KERN_INFO "blkfront: %s: %s: %s %s %s %s %s\n",
> >-	       info->gd->disk_name,
> >-	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> >-		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
> >-		"flush diskcache" : "barrier or flush"),
> >-	       info->feature_flush ? "enabled;" : "disabled;",
> >-	       "persistent grants:",
> >-	       info->feature_persistent ? "enabled;" : "disabled;",
> >-	       "indirect descriptors:",
> >-	       info->max_indirect_segments ? "enabled;" : "disabled;");
> >+	pr_info("blkfront: %s: %s %s %s %s %s\n",
> >+		info->gd->disk_name, flush_info(info->feature_flush),
> >+		"persistent grants:", info->feature_persistent ?
> >+		"enabled;" : "disabled;", "indirect descriptors:",
> >+		info->max_indirect_segments ? "enabled;" : "disabled;");
> >  }
> >  static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
> >@@ -1190,7 +1207,6 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> >  				if (error == -EOPNOTSUPP)
> >  					error = 0;
> >  				info->feature_flush = 0;
> >-				info->flush_op = 0;
> >  				xlvbd_flush(info);
> >  			}
> >  			/* fall through */
> >@@ -1810,7 +1826,6 @@ static void blkfront_connect(struct blkfront_info *info)
> >  		physical_sector_size = sector_size;
> >  	info->feature_flush = 0;
> >-	info->flush_op = 0;
> >  	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> >  			    "feature-barrier", "%d", &barrier,
> >@@ -1823,10 +1838,8 @@ static void blkfront_connect(struct blkfront_info *info)
> >  	 *
> >  	 * If there are barriers, then we use flush.
> >  	 */
> >-	if (!err && barrier) {
> >+	if (!err && barrier)
> >  		info->feature_flush = REQ_FLUSH | REQ_FUA;
> >-		info->flush_op = BLKIF_OP_WRITE_BARRIER;
> >-	}
> >  	/*
> >  	 * And if there is "feature-flush-cache" use that above
> >  	 * barriers.
> >@@ -1835,10 +1848,8 @@ static void blkfront_connect(struct blkfront_info *info)
> >  			    "feature-flush-cache", "%d", &flush,
> >  			    NULL);
> >-	if (!err && flush) {
> >+	if (!err && flush)
> >  		info->feature_flush = REQ_FLUSH;
> >-		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
> >-	}
> >  	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> >  			    "feature-discard", "%d", &discard,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 17:26:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17: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 1Xyl25-0002sx-SE; Wed, 10 Dec 2014 17:26:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luis.henriques@canonical.com>) id 1Xyl24-0002sr-Ac
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 17:26:36 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C5/F1-25276-B4288845; Wed, 10 Dec 2014 17:26:35 +0000
X-Env-Sender: luis.henriques@canonical.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418232394!14752991!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5911 invoked from network); 10 Dec 2014 17:26:34 -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;
	10 Dec 2014 17:26:34 -0000
Received: from [10.172.192.212] (helo=localhost)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <luis.henriques@canonical.com>)
	id 1Xyl1x-0006dL-Qp; Wed, 10 Dec 2014 17:26:30 +0000
From: Luis Henriques <luis.henriques@canonical.com>
To: Zoltan Kiss <zoltan.kiss@citrix.com>
Date: Wed, 10 Dec 2014 17:26:28 +0000
Message-Id: <1418232388-16853-1-git-send-email-luis.henriques@canonical.com>
X-Mailer: git-send-email 2.1.0
X-Extended-Stable: 3.16
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Luis Henriques <luis.henriques@canonical.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Stefan Bader <stefan.bader@canonical.com>, kernel-team@lists.ubuntu.com,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org,
	"David S. Miller" <davem@davemloft.net>
Subject: [Xen-devel] [3.16.y-ckt stable] Patch "xen-netfront: Fix handling
	packets on compound pages with skb_linearize" has been added
	to staging queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a note to let you know that I have just added a patch titled

    xen-netfront: Fix handling packets on compound pages with skb_linearize

to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree 
which can be found at:

 http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y-queue

This patch is scheduled to be released in version 3.16.7-ckt3.

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.16.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

------

>From 079f869ca5082866d276b686721e89a649e622fe Mon Sep 17 00:00:00 2001
From: Zoltan Kiss <zoltan.kiss@citrix.com>
Date: Mon, 11 Aug 2014 18:32:23 +0100
Subject: xen-netfront: Fix handling packets on compound pages with
 skb_linearize

commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d upstream.

There is a long known problem with the netfront/netback interface: if the guest
tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
it gets dropped. The reason is that netback maps these slots to a frag in the
frags array, which is limited by size. Having so many slots can occur since
compound pages were introduced, as the ring protocol slice them up into
individual (non-compound) page aligned slots. The theoretical worst case
scenario looks like this (note, skbs are limited to 64 Kb here):
linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
using 2 slots
first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
end and the beginning of a page, therefore they use 3 * 15 = 45 slots
last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
Although I don't think this 51 slots skb can really happen, we need a solution
which can deal with every scenario. In real life there is only a few slots
overdue, but usually it causes the TCP stream to be blocked, as the retry will
most likely have the same buffer layout.
This patch solves this problem by linearizing the packet. This is not the
fastest way, and it can fail much easier as it tries to allocate a big linear
area for the whole packet, but probably easier by an order of magnitude than
anything else. Probably this code path is not touched very frequently anyway.

Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Paul Durrant <paul.durrant@citrix.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
---
 drivers/net/xen-netfront.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 055222bae6e4..23359aeb1ba0 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -628,9 +628,10 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	slots = DIV_ROUND_UP(offset + len, PAGE_SIZE) +
 		xennet_count_skb_frag_slots(skb);
 	if (unlikely(slots > MAX_SKB_FRAGS + 1)) {
-		net_alert_ratelimited(
-			"xennet: skb rides the rocket: %d slots\n", slots);
-		goto drop;
+		net_dbg_ratelimited("xennet: skb rides the rocket: %d slots, %d bytes\n",
+				    slots, skb->len);
+		if (skb_linearize(skb))
+			goto drop;
 	}

 	spin_lock_irqsave(&queue->tx_lock, flags);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 17:26:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17: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 1Xyl25-0002sx-SE; Wed, 10 Dec 2014 17:26:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luis.henriques@canonical.com>) id 1Xyl24-0002sr-Ac
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 17:26:36 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C5/F1-25276-B4288845; Wed, 10 Dec 2014 17:26:35 +0000
X-Env-Sender: luis.henriques@canonical.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418232394!14752991!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5911 invoked from network); 10 Dec 2014 17:26:34 -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;
	10 Dec 2014 17:26:34 -0000
Received: from [10.172.192.212] (helo=localhost)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <luis.henriques@canonical.com>)
	id 1Xyl1x-0006dL-Qp; Wed, 10 Dec 2014 17:26:30 +0000
From: Luis Henriques <luis.henriques@canonical.com>
To: Zoltan Kiss <zoltan.kiss@citrix.com>
Date: Wed, 10 Dec 2014 17:26:28 +0000
Message-Id: <1418232388-16853-1-git-send-email-luis.henriques@canonical.com>
X-Mailer: git-send-email 2.1.0
X-Extended-Stable: 3.16
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Luis Henriques <luis.henriques@canonical.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Stefan Bader <stefan.bader@canonical.com>, kernel-team@lists.ubuntu.com,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org,
	"David S. Miller" <davem@davemloft.net>
Subject: [Xen-devel] [3.16.y-ckt stable] Patch "xen-netfront: Fix handling
	packets on compound pages with skb_linearize" has been added
	to staging queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a note to let you know that I have just added a patch titled

    xen-netfront: Fix handling packets on compound pages with skb_linearize

to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree 
which can be found at:

 http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y-queue

This patch is scheduled to be released in version 3.16.7-ckt3.

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.16.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

------

>From 079f869ca5082866d276b686721e89a649e622fe Mon Sep 17 00:00:00 2001
From: Zoltan Kiss <zoltan.kiss@citrix.com>
Date: Mon, 11 Aug 2014 18:32:23 +0100
Subject: xen-netfront: Fix handling packets on compound pages with
 skb_linearize

commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d upstream.

There is a long known problem with the netfront/netback interface: if the guest
tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
it gets dropped. The reason is that netback maps these slots to a frag in the
frags array, which is limited by size. Having so many slots can occur since
compound pages were introduced, as the ring protocol slice them up into
individual (non-compound) page aligned slots. The theoretical worst case
scenario looks like this (note, skbs are limited to 64 Kb here):
linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
using 2 slots
first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
end and the beginning of a page, therefore they use 3 * 15 = 45 slots
last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
Although I don't think this 51 slots skb can really happen, we need a solution
which can deal with every scenario. In real life there is only a few slots
overdue, but usually it causes the TCP stream to be blocked, as the retry will
most likely have the same buffer layout.
This patch solves this problem by linearizing the packet. This is not the
fastest way, and it can fail much easier as it tries to allocate a big linear
area for the whole packet, but probably easier by an order of magnitude than
anything else. Probably this code path is not touched very frequently anyway.

Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Paul Durrant <paul.durrant@citrix.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
---
 drivers/net/xen-netfront.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 055222bae6e4..23359aeb1ba0 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -628,9 +628,10 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	slots = DIV_ROUND_UP(offset + len, PAGE_SIZE) +
 		xennet_count_skb_frag_slots(skb);
 	if (unlikely(slots > MAX_SKB_FRAGS + 1)) {
-		net_alert_ratelimited(
-			"xennet: skb rides the rocket: %d slots\n", slots);
-		goto drop;
+		net_dbg_ratelimited("xennet: skb rides the rocket: %d slots, %d bytes\n",
+				    slots, skb->len);
+		if (skb_linearize(skb))
+			goto drop;
 	}

 	spin_lock_irqsave(&queue->tx_lock, flags);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 17:53:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17: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 1XylRa-0003zq-AJ; Wed, 10 Dec 2014 17:52:58 +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 1XylRY-0003zl-Fe
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 17:52:56 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	0D/97-18267-77888845; Wed, 10 Dec 2014 17:52:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418233975!12449418!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31269 invoked from network); 10 Dec 2014 17:52:55 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 17:52:55 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418233975; l=2639;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=4kpWCZOgejWUTXx2zvWTGGQoIUE=;
	b=XTUYToIukiPkewE4sLcHXGiu/S47s8oDToIt46U4c18trZoziGH3T1IZD1HpGMK7dWt
	DRlCTDGIOYzW2yET2lJ97q7b4u9jyjTSlHF2PgV2MWgD9V2UN5ewf/LILbCStO8k+5VYe
	MzinLmXZxXjsrReOZFYY6/6Uqvc9qz+k3Jw=
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.3 AUTH) with ESMTPSA id m03ad5qBAHqqGBj
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 10 Dec 2014 18:52:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id D3A8D5015F; Wed, 10 Dec 2014 18:52:51 +0100 (CET)
Date: Wed, 10 Dec 2014 18:52:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210175251.GA4441@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418205728.19809.40.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, Ian Campbell wrote:

> That results in a wrapper which unconditionally execs, the systemd unit
> just calls that while the sysv script runs the wrapper and then does the
> xenstore-read -s loop. 

Since systemd handles the socket there is already a listener.
http://lists.freedesktop.org/archives/systemd-devel/2014-December/026157.html


I came up with this, works in my testing with SLE11 sysv and Factory
systemd. The beef looks like shown below.  Let me know if thats good
enough to handle XENSTORED_TRACE also in systemd. I will add some
comments to the wrapper why it is there.

Olaf

diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
index a1095c2..f57bfd3 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -66,11 +66,13 @@ do_start () {
 	then
 		test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
 		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
-		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
 
 		if [ -n "$XENSTORED" ] ; then
 		    echo -n Starting $XENSTORED...
-		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		    XENSTORED=$XENSTORED \
+		    XENSTORED_TRACE=$XENSTORED_TRACE \
+		    XENSTORED_ARGS=$XENSTORED_ARGS \
+		    ${LIBEXEC_BIN}/xenstored.sh --pid-file /var/run/xenstored.pid
 		else
 		    echo "No xenstored found"
 		    exit 1
diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 0f0ac58..d906ea2 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -8,13 +8,12 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=notify
-Environment=XENSTORED_ARGS=
 Environment=XENSTORED=@XENSTORED@
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/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@
-ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
+ExecStart=-@LIBEXEC_BIN@/xenstored.sh --no-fork
 
 [Install]
 WantedBy=multi-user.target
diff --git a/tools/hotplug/Linux/xenstored.sh.in b/tools/hotplug/Linux/xenstored.sh.in
new file mode 100644
index 0000000..dc806ee
--- /dev/null
+++ b/tools/hotplug/Linux/xenstored.sh.in
@@ -0,0 +1,6 @@
+#!/bin/sh
+if test -n "$XENSTORED_TRACE"
+then
+	XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
+fi
+exec $XENSTORED $@ $XENSTORED_ARGS

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 17:53:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17: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 1XylRa-0003zq-AJ; Wed, 10 Dec 2014 17:52:58 +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 1XylRY-0003zl-Fe
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 17:52:56 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	0D/97-18267-77888845; Wed, 10 Dec 2014 17:52:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418233975!12449418!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31269 invoked from network); 10 Dec 2014 17:52:55 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 17:52:55 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418233975; l=2639;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=4kpWCZOgejWUTXx2zvWTGGQoIUE=;
	b=XTUYToIukiPkewE4sLcHXGiu/S47s8oDToIt46U4c18trZoziGH3T1IZD1HpGMK7dWt
	DRlCTDGIOYzW2yET2lJ97q7b4u9jyjTSlHF2PgV2MWgD9V2UN5ewf/LILbCStO8k+5VYe
	MzinLmXZxXjsrReOZFYY6/6Uqvc9qz+k3Jw=
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.3 AUTH) with ESMTPSA id m03ad5qBAHqqGBj
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 10 Dec 2014 18:52:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id D3A8D5015F; Wed, 10 Dec 2014 18:52:51 +0100 (CET)
Date: Wed, 10 Dec 2014 18:52:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210175251.GA4441@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418205728.19809.40.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, Ian Campbell wrote:

> That results in a wrapper which unconditionally execs, the systemd unit
> just calls that while the sysv script runs the wrapper and then does the
> xenstore-read -s loop. 

Since systemd handles the socket there is already a listener.
http://lists.freedesktop.org/archives/systemd-devel/2014-December/026157.html


I came up with this, works in my testing with SLE11 sysv and Factory
systemd. The beef looks like shown below.  Let me know if thats good
enough to handle XENSTORED_TRACE also in systemd. I will add some
comments to the wrapper why it is there.

Olaf

diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
index a1095c2..f57bfd3 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -66,11 +66,13 @@ do_start () {
 	then
 		test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
 		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
-		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
 
 		if [ -n "$XENSTORED" ] ; then
 		    echo -n Starting $XENSTORED...
-		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		    XENSTORED=$XENSTORED \
+		    XENSTORED_TRACE=$XENSTORED_TRACE \
+		    XENSTORED_ARGS=$XENSTORED_ARGS \
+		    ${LIBEXEC_BIN}/xenstored.sh --pid-file /var/run/xenstored.pid
 		else
 		    echo "No xenstored found"
 		    exit 1
diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 0f0ac58..d906ea2 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -8,13 +8,12 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=notify
-Environment=XENSTORED_ARGS=
 Environment=XENSTORED=@XENSTORED@
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/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@
-ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
+ExecStart=-@LIBEXEC_BIN@/xenstored.sh --no-fork
 
 [Install]
 WantedBy=multi-user.target
diff --git a/tools/hotplug/Linux/xenstored.sh.in b/tools/hotplug/Linux/xenstored.sh.in
new file mode 100644
index 0000000..dc806ee
--- /dev/null
+++ b/tools/hotplug/Linux/xenstored.sh.in
@@ -0,0 +1,6 @@
+#!/bin/sh
+if test -n "$XENSTORED_TRACE"
+then
+	XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
+fi
+exec $XENSTORED $@ $XENSTORED_ARGS

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 17:55:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17:55:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XylTb-0004Dl-QW; Wed, 10 Dec 2014 17:55:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luis.henriques@canonical.com>) id 1XylTZ-0004DU-P1
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 17:55:01 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	BA/6A-02712-5F888845; Wed, 10 Dec 2014 17:55:01 +0000
X-Env-Sender: luis.henriques@canonical.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418234099!14270868!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21535 invoked from network); 10 Dec 2014 17:55:00 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Dec 2014 17:55:00 -0000
Received: from bl15-103-96.dsl.telepac.pt ([188.80.103.96] helo=localhost)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <luis.henriques@canonical.com>)
	id 1XylTS-0007ig-Jq; Wed, 10 Dec 2014 17:54:54 +0000
Date: Wed, 10 Dec 2014 17:54:52 +0000
From: Luis Henriques <luis.henriques@canonical.com>
To: Zoltan Kiss <zoltan.kiss@citrix.com>
Message-ID: <20141210175452.GE10463@hercules>
References: <1418232388-16853-1-git-send-email-luis.henriques@canonical.com>
MIME-Version: 1.0
Content-Length: 4097
Content-Disposition: inline
In-Reply-To: <1418232388-16853-1-git-send-email-luis.henriques@canonical.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Stefan Bader <stefan.bader@canonical.com>, kernel-team@lists.ubuntu.com,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] [3.16.y-ckt stable] Patch "xen-netfront: Fix
 handling packets on compound pages with skb_linearize" has been added to
 staging queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 10, 2014 at 05:26:28PM +0000, Luis Henriques wrote:
> This is a note to let you know that I have just added a patch titled
> =

>     xen-netfront: Fix handling packets on compound pages with skb_lineari=
ze
> =

> to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree =

> which can be found at:
> =

>  http://kernel.ubuntu.com/git?p=3Dubuntu/linux.git;a=3Dshortlog;h=3Drefs/=
heads/linux-3.16.y-queue
> =

> This patch is scheduled to be released in version 3.16.7-ckt3.
> =

> If you, or anyone else, feels it should not be added to this tree, please =

> reply to this email.
> =


Ups, sorry!  I thought I had this one dropped after David Vrabel
comment.  Now dropped for sure.

Cheers,
--
Lu=EDs


> For more information about the 3.16.y-ckt tree, see
> https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
> =

> Thanks.
> -Luis
> =

> ------
> =

> From 079f869ca5082866d276b686721e89a649e622fe Mon Sep 17 00:00:00 2001
> From: Zoltan Kiss <zoltan.kiss@citrix.com>
> Date: Mon, 11 Aug 2014 18:32:23 +0100
> Subject: xen-netfront: Fix handling packets on compound pages with
>  skb_linearize
> =

> commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d upstream.
> =

> There is a long known problem with the netfront/netback interface: if the=
 guest
> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring =
slots,
> it gets dropped. The reason is that netback maps these slots to a frag in=
 the
> frags array, which is limited by size. Having so many slots can occur sin=
ce
> compound pages were introduced, as the ring protocol slice them up into
> individual (non-compound) page aligned slots. The theoretical worst case
> scenario looks like this (note, skbs are limited to 64 Kb here):
> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundar=
y,
> using 2 slots
> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at=
 the
> end and the beginning of a page, therefore they use 3 * 15 =3D 45 slots
> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 slots
> Although I don't think this 51 slots skb can really happen, we need a sol=
ution
> which can deal with every scenario. In real life there is only a few slots
> overdue, but usually it causes the TCP stream to be blocked, as the retry=
 will
> most likely have the same buffer layout.
> This patch solves this problem by linearizing the packet. This is not the
> fastest way, and it can fail much easier as it tries to allocate a big li=
near
> area for the whole packet, but probably easier by an order of magnitude t=
han
> anything else. Probably this code path is not touched very frequently any=
way.
> =

> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Paul Durrant <paul.durrant@citrix.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: xen-devel@lists.xenproject.org
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Cc: Stefan Bader <stefan.bader@canonical.com>
> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
> ---
>  drivers/net/xen-netfront.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> =

> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 055222bae6e4..23359aeb1ba0 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -628,9 +628,10 @@ static int xennet_start_xmit(struct sk_buff *skb, st=
ruct net_device *dev)
>  	slots =3D DIV_ROUND_UP(offset + len, PAGE_SIZE) +
>  		xennet_count_skb_frag_slots(skb);
>  	if (unlikely(slots > MAX_SKB_FRAGS + 1)) {
> -		net_alert_ratelimited(
> -			"xennet: skb rides the rocket: %d slots\n", slots);
> -		goto drop;
> +		net_dbg_ratelimited("xennet: skb rides the rocket: %d slots, %d bytes\=
n",
> +				    slots, skb->len);
> +		if (skb_linearize(skb))
> +			goto drop;
>  	}
> =

>  	spin_lock_irqsave(&queue->tx_lock, flags);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 17:55:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 17:55:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XylTb-0004Dl-QW; Wed, 10 Dec 2014 17:55:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luis.henriques@canonical.com>) id 1XylTZ-0004DU-P1
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 17:55:01 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	BA/6A-02712-5F888845; Wed, 10 Dec 2014 17:55:01 +0000
X-Env-Sender: luis.henriques@canonical.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418234099!14270868!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21535 invoked from network); 10 Dec 2014 17:55:00 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Dec 2014 17:55:00 -0000
Received: from bl15-103-96.dsl.telepac.pt ([188.80.103.96] helo=localhost)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <luis.henriques@canonical.com>)
	id 1XylTS-0007ig-Jq; Wed, 10 Dec 2014 17:54:54 +0000
Date: Wed, 10 Dec 2014 17:54:52 +0000
From: Luis Henriques <luis.henriques@canonical.com>
To: Zoltan Kiss <zoltan.kiss@citrix.com>
Message-ID: <20141210175452.GE10463@hercules>
References: <1418232388-16853-1-git-send-email-luis.henriques@canonical.com>
MIME-Version: 1.0
Content-Length: 4097
Content-Disposition: inline
In-Reply-To: <1418232388-16853-1-git-send-email-luis.henriques@canonical.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Stefan Bader <stefan.bader@canonical.com>, kernel-team@lists.ubuntu.com,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] [3.16.y-ckt stable] Patch "xen-netfront: Fix
 handling packets on compound pages with skb_linearize" has been added to
 staging queue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 10, 2014 at 05:26:28PM +0000, Luis Henriques wrote:
> This is a note to let you know that I have just added a patch titled
> =

>     xen-netfront: Fix handling packets on compound pages with skb_lineari=
ze
> =

> to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree =

> which can be found at:
> =

>  http://kernel.ubuntu.com/git?p=3Dubuntu/linux.git;a=3Dshortlog;h=3Drefs/=
heads/linux-3.16.y-queue
> =

> This patch is scheduled to be released in version 3.16.7-ckt3.
> =

> If you, or anyone else, feels it should not be added to this tree, please =

> reply to this email.
> =


Ups, sorry!  I thought I had this one dropped after David Vrabel
comment.  Now dropped for sure.

Cheers,
--
Lu=EDs


> For more information about the 3.16.y-ckt tree, see
> https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
> =

> Thanks.
> -Luis
> =

> ------
> =

> From 079f869ca5082866d276b686721e89a649e622fe Mon Sep 17 00:00:00 2001
> From: Zoltan Kiss <zoltan.kiss@citrix.com>
> Date: Mon, 11 Aug 2014 18:32:23 +0100
> Subject: xen-netfront: Fix handling packets on compound pages with
>  skb_linearize
> =

> commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d upstream.
> =

> There is a long known problem with the netfront/netback interface: if the=
 guest
> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring =
slots,
> it gets dropped. The reason is that netback maps these slots to a frag in=
 the
> frags array, which is limited by size. Having so many slots can occur sin=
ce
> compound pages were introduced, as the ring protocol slice them up into
> individual (non-compound) page aligned slots. The theoretical worst case
> scenario looks like this (note, skbs are limited to 64 Kb here):
> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundar=
y,
> using 2 slots
> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at=
 the
> end and the beginning of a page, therefore they use 3 * 15 =3D 45 slots
> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 =3D 4 slots
> Although I don't think this 51 slots skb can really happen, we need a sol=
ution
> which can deal with every scenario. In real life there is only a few slots
> overdue, but usually it causes the TCP stream to be blocked, as the retry=
 will
> most likely have the same buffer layout.
> This patch solves this problem by linearizing the packet. This is not the
> fastest way, and it can fail much easier as it tries to allocate a big li=
near
> area for the whole packet, but probably easier by an order of magnitude t=
han
> anything else. Probably this code path is not touched very frequently any=
way.
> =

> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Paul Durrant <paul.durrant@citrix.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: xen-devel@lists.xenproject.org
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Cc: Stefan Bader <stefan.bader@canonical.com>
> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
> ---
>  drivers/net/xen-netfront.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> =

> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 055222bae6e4..23359aeb1ba0 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -628,9 +628,10 @@ static int xennet_start_xmit(struct sk_buff *skb, st=
ruct net_device *dev)
>  	slots =3D DIV_ROUND_UP(offset + len, PAGE_SIZE) +
>  		xennet_count_skb_frag_slots(skb);
>  	if (unlikely(slots > MAX_SKB_FRAGS + 1)) {
> -		net_alert_ratelimited(
> -			"xennet: skb rides the rocket: %d slots\n", slots);
> -		goto drop;
> +		net_dbg_ratelimited("xennet: skb rides the rocket: %d slots, %d bytes\=
n",
> +				    slots, skb->len);
> +		if (skb_linearize(skb))
> +			goto drop;
>  	}
> =

>  	spin_lock_irqsave(&queue->tx_lock, flags);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:02:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:02:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XylaC-0004dc-Rx; Wed, 10 Dec 2014 18:01:52 +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 1XylaB-0004dX-IM
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:01:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F8/16-25276-E8A88845; Wed, 10 Dec 2014 18:01:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418234510!14758238!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30948 invoked from network); 10 Dec 2014 18:01:50 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 18:01:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418234510; l=509;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=44Z/U9zw94yArjv5YEYBhE76dKM=;
	b=yCZhJt6wGq2C9EHwyZRZGsJn82SfRfA6XUjTV+mVvum2eD5XPwTMfXmmJvWD9qX5NwN
	wpjwB6vPp2eXgg0h92ULlrMPAV6huWdAByHWE5UbAHVSbMBuOdbcvS8IrxqhIjOcW7TMe
	8nrnLJ/Y0aRC6qRiDNMMGGtGhsyj1j1N0/U=
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.3 AUTH) with ESMTPSA id L050d5qBAI1jH14
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 10 Dec 2014 19:01:45 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 9735B5015F; Wed, 10 Dec 2014 19:01:44 +0100 (CET)
Date: Wed, 10 Dec 2014 19:01:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210180144.GB4441@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418205728.19809.40.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, Ian Campbell wrote:

> Separately from the above I wonder if it might be worth moving the
> xenstore readiness check into the xen-init-dom0 helper and having most
> things which currently depend on xenstore actually depend on the
> "dom0-is-ready" unit, which itself depends on xenstored, qemu-dom0 and
> whatever else is supposed to be ready in a dom0?

You mean something like this chain of depencencies?

 xenstored
 xen-init-dom0
 xenconsoled | qemu-dom0
 xendomains

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:02:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:02:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XylaC-0004dc-Rx; Wed, 10 Dec 2014 18:01:52 +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 1XylaB-0004dX-IM
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:01:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F8/16-25276-E8A88845; Wed, 10 Dec 2014 18:01:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418234510!14758238!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30948 invoked from network); 10 Dec 2014 18:01:50 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 18:01:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418234510; l=509;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=44Z/U9zw94yArjv5YEYBhE76dKM=;
	b=yCZhJt6wGq2C9EHwyZRZGsJn82SfRfA6XUjTV+mVvum2eD5XPwTMfXmmJvWD9qX5NwN
	wpjwB6vPp2eXgg0h92ULlrMPAV6huWdAByHWE5UbAHVSbMBuOdbcvS8IrxqhIjOcW7TMe
	8nrnLJ/Y0aRC6qRiDNMMGGtGhsyj1j1N0/U=
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.3 AUTH) with ESMTPSA id L050d5qBAI1jH14
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 10 Dec 2014 19:01:45 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 9735B5015F; Wed, 10 Dec 2014 19:01:44 +0100 (CET)
Date: Wed, 10 Dec 2014 19:01:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141210180144.GB4441@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418205728.19809.40.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
	in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, Ian Campbell wrote:

> Separately from the above I wonder if it might be worth moving the
> xenstore readiness check into the xen-init-dom0 helper and having most
> things which currently depend on xenstore actually depend on the
> "dom0-is-ready" unit, which itself depends on xenstored, qemu-dom0 and
> whatever else is supposed to be ready in a dom0?

You mean something like this chain of depencencies?

 xenstored
 xen-init-dom0
 xenconsoled | qemu-dom0
 xendomains

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:07:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XylfJ-00050s-J8; Wed, 10 Dec 2014 18:07:09 +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 1XylfI-00050m-2E
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 18:07:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6F/0D-09842-BCB88845; Wed, 10 Dec 2014 18:07:07 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418234825!11318964!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3570 invoked from network); 10 Dec 2014 18:07:06 -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;
	10 Dec 2014 18:07:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202958882"
Message-ID: <54888BC6.7030601@citrix.com>
Date: Wed, 10 Dec 2014 18:07:02 +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: 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>
References: <1418226963-24873-1-git-send-email-jgross@suse.com>
In-Reply-To: <1418226963-24873-1-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen
 mmu.c earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/12/14 15:56, Juergen Gross wrote:
> With the virtual mapped linear p2m list the post-init mmu operations
> must be used for setting up the p2m mappings, as in case of
> CONFIG_FLATMEM the init routines may trigger BUGs.
> 
> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  arch/x86/xen/mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 6ab6150..a1a429a 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
>  static void __init xen_pagetable_init(void)
>  {
>  	paging_init();
> +	xen_post_allocator_init();
>  
>  	xen_pagetable_p2m_setup();
>  

This feels very chicken-and-egg to me:  To setup the P2M we need to use
the MMU ops that use the P2M...

Please explain very clearly why this is all safe.

> @@ -1236,7 +1237,6 @@ static void __init xen_pagetable_init(void)
>  		xen_remap_memory();
>  
>  	xen_setup_shared_info();
> -	xen_post_allocator_init();
>  }
>  static void xen_write_cr2(unsigned long cr2)
>  {
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:07:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XylfJ-00050s-J8; Wed, 10 Dec 2014 18:07:09 +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 1XylfI-00050m-2E
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 18:07:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6F/0D-09842-BCB88845; Wed, 10 Dec 2014 18:07:07 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418234825!11318964!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3570 invoked from network); 10 Dec 2014 18:07:06 -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;
	10 Dec 2014 18:07:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202958882"
Message-ID: <54888BC6.7030601@citrix.com>
Date: Wed, 10 Dec 2014 18:07:02 +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: 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>
References: <1418226963-24873-1-git-send-email-jgross@suse.com>
In-Reply-To: <1418226963-24873-1-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen
 mmu.c earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/12/14 15:56, Juergen Gross wrote:
> With the virtual mapped linear p2m list the post-init mmu operations
> must be used for setting up the p2m mappings, as in case of
> CONFIG_FLATMEM the init routines may trigger BUGs.
> 
> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  arch/x86/xen/mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 6ab6150..a1a429a 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
>  static void __init xen_pagetable_init(void)
>  {
>  	paging_init();
> +	xen_post_allocator_init();
>  
>  	xen_pagetable_p2m_setup();
>  

This feels very chicken-and-egg to me:  To setup the P2M we need to use
the MMU ops that use the P2M...

Please explain very clearly why this is all safe.

> @@ -1236,7 +1237,6 @@ static void __init xen_pagetable_init(void)
>  		xen_remap_memory();
>  
>  	xen_setup_shared_info();
> -	xen_post_allocator_init();
>  }
>  static void xen_write_cr2(unsigned long cr2)
>  {
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylh7-00056w-2i; Wed, 10 Dec 2014 18:09:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylh5-00056p-Jm
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:08:59 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	D6/1A-02697-A3C88845; Wed, 10 Dec 2014 18:08:58 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418234937!12631804!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12861 invoked from network); 10 Dec 2014 18:08:57 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:08:57 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so12081388wid.15
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:08:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:user-agent:mime-version
	:content-type:content-transfer-encoding;
	bh=UfESKDRQez/J28ktqaxhLA1KjFPqhjlVD47haOS4lMk=;
	b=t6Cb8Vi59/gZJWS/bgWV+Lj1udhcaQYYnsUIYsvXzNAByTbypLzboBsktUb47QFYDw
	V4dFJQ5+kL+T7YqktfFlbdjXQ0WrwOfRzEUKRutjPCT+4xMc1AEqYYRiYvOAZ3amjHB4
	6jI9LGMb1uoadwvrVSNSZhSNep9ar8E2juu+0CLpXyIj0rN+bx8VnYxCgBKEeUZaTrB3
	EocQ9YFF3qMggnZ1fkCijTVTQLtw80UQPlZ6EcOzjJravh6ohOBAfoc0gYeLItblBOM2
	jhG7HZ1LsBoZ4RrVRCSt+d0hhA1jt6NYx4rMpyqsNcxlKknHJNTuY3JQ0rsIYVuKWBmO
	nO5A==
X-Received: by 10.194.85.83 with SMTP id f19mr9330737wjz.20.1418234937432;
	Wed, 10 Dec 2014 10:08:57 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id p14sm7298633wie.1.2014.12.10.10.08.55
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:08:56 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:08:54 +0100
Message-ID: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 00/27] Running benchmarks via OSSTest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello everyone,

This is a highly reworked and much more mature version of this old RFC series:

  http://lists.xen.org/archives/html/xen-devel/2014-06/msg03429.html

It is about integrating benchmarking capabilities into OSSTest. The series is a
lot bigger, because it is now capable of doing a lot more stuff. :-) All the
comments I got during review of the RFC have been addressed, of course... More
comments are of course welcome!

The series is available here:

  git://xenbits.xen.org/people/dariof/osstest.git benchmarking-with-osstest
  http://xenbits.xen.org/gitweb/?p=people/dariof/osstest.git;a=shortlog;h=refs/heads/benchmarking-with-osstest

So, about the patches. Patches 01 to 04, as well as patch 20, are preliminary
changes and fixes, necessary for the rest of the series to work properly, but
they are general enough to be considered separately from the series, if
interesting.

Patches 05 to 12 make it possible to run an instance of the Unixbench (XXX)
benchmark via OSSTest. Management scripts, test scripts, jobs and recipes are
provided to download the benchmark, prepare the guest (PV or HVM), build the
benchmark in the guest, run it, and retrieve and process (include some super
fancy plots! :-D) the results.

To do so, do as follows (in standalone mode):

  $ ./standalone-reset -t bench
  $ ./mg-unixbench-download
  $ ./standalone run-job -h ultralisk bench-unixbench-amd64-credit-pv-4vcpus-4096ram

One thing about patch 12. I tried, but I can't tell how I should invoke
./standalone in order to test the new parameter I'm adding... Can someone help
with this? IanC?

To have an idea of how the 'output' of one of this jobs looks like, have a look
here:

 http://xenbits.xen.org/people/dariof/osstest-bench/bench-kernbench-amd64-credit-hvm-4vcpus-4096ram.log
 http://xenbits.xen.org/people/dariof/osstest-bench/bench-kernbench-amd64-credit-hvm-4vcpus-4096ram/
 http://xenbits.xen.org/people/dariof/osstest-bench/bench-kernbench-amd64-credit-hvm-4vcpus-4096ram/debianhvm.guest.osstest--kernbench-n4-PLOT.png

Or here:

 http://xenbits.xen.org/people/dariof/osstest-bench/bench-unixbench-amd64-credit-pv-4vcpus-4096ram.log
 http://xenbits.xen.org/people/dariof/osstest-bench/bench-unixbench-amd64-credit-pv-4vcpus-4096ram/
 http://xenbits.xen.org/people/dariof/osstest-bench/bench-unixbench-amd64-credit-pv-4vcpus-4096ram/debian.guest.osstest--unixbench-i1-c4-PLOT.png

Patches 13 to 19 does the very same, but for Kernbench (XXX):

  $ ./mg-kernbench-download
  $ ./standalone run-job -h ultralisk bench-kernbench-amd64-credit-hvm-4vcpus-4096ram

Patches 21 to 27 aims at allowing running a benchmark both in a guest and on
baremetal, to investigate the performances loss due to the virtualization
overhead. To do that, for Unixbench and Kernbench, one just issue the following
commands (in standalone mode):

  $ ./standalone run-job -h ultralisk bench-hostcmp-unixbench-amd64-credit
  $ ./standalone run-job -h ultralisk bench-hostcmp-kernbench-amd64-credit2

To have an idea of how the 'output' of one of these jobs looks like, have a
look here:

 http://xenbits.xen.org/people/dariof/osstest-bench/bench-hostcmp-kernbench-amd64-credit.log
 http://xenbits.xen.org/people/dariof/osstest-bench/bench-hostcmp-kernbench-amd64-credit/
 http://xenbits.xen.org/people/dariof/osstest-bench/bench-hostcmp-kernbench-amd64-credit/bench-hostcmp-kernbench-amd64-credit-PLOT.png

TODOs:
 * in patch 02/27, I haven't actually checked whether also grub1 and/or uboot
   needs fixing
 * When comparing performance, I think it would be best to always use the same
   kernel, in host and guests. This happens by default for PV guest, while it
   does not for HVM guests. This of course can be solved pretty easily, and I
   plan to do it either in future posting of this series, or with a follow-up
   patch.

Regards,
Dario
---
Dario Faggioli (27):
      ts-devbian-hvm-install: prune "cdrom:" from install sources
      Osstest/Debian.pm: fix identifying a Linux baremetal grub2 entry
      Guest setup: allow the amount of RAM to be a runvar
      Osstest/TestSupport.pm: Introduce target_getfile_[root_]stash()
      mg-unixbench-download: new script for downloading the unixbench archive
      ts-unixbench-build: prep the environment for running unixbench
      ts-unixbench-run: kick off the benchmark on the target
      ts-unixbench-reslts: for retrieving the results
      ts-unixbench-reslts: process and plot bench results
      sg-run-job: recipes for the unixbench jobs
      make-bench-flight: to create a benchmarking flight
      standalone-reset: introduce a new -t option
      mg-kernbench-download: new script for downloading kernbench
      ts-kernbench-build: prep the environment for running kernbench
      ts-kernbench-run: kick off the benchmark on the target
      ts-unixbench-reslts: retrieve and stash kernbench results
      ts-kernbench-reslts: process and plot bench results
      sg-run-job: recipes for the kernbench jobs
      make-bench-flight: create kernbench jobs
      Osstest/TestSupport.pm: read hosts' hardware characteristics
      ts-bench-hostcmp-guest-prep: new script
      ts-bench-hostcmp-host-prep: new script
      ts-bench-hostcmp-host-reset: new script
      Recipes and jobs for running unixbench both on host and guest
      ts-bench-hostcmp-post: add plotting facilities
      Kernbench perf comparison between host and guest
      ts-bench-hostcmp-post: add plotting facilities


 Osstest/Benchmarking.pm     |  210 +++++++++++++++++++++++++++++++++++++++++++
 Osstest/Debian.pm           |   54 +++++++----
 Osstest/TestSupport.pm      |  166 +++++++++++++++++++++++++++++++++-
 README                      |   36 +++++++
 cr-daily-branch             |    3 -
 make-bench-flight           |  153 +++++++++++++++++++++++++++++++
 mg-host-hw-specs            |   35 +++++++
 mg-kernbench-download       |   49 ++++++++++
 mg-unixbench-download       |   40 ++++++++
 sg-run-job                  |  102 ++++++++++++++++++++-
 standalone                  |    7 +
 standalone-reset            |    9 +-
 ts-bench-hostcmp-guest-prep |   87 ++++++++++++++++++
 ts-bench-hostcmp-host-prep  |   74 +++++++++++++++
 ts-bench-hostcmp-post       |   81 +++++++++++++++++
 ts-debian-fixup             |    3 +
 ts-debian-hvm-install       |    3 -
 ts-kernbench-build          |   86 ++++++++++++++++++
 ts-kernbench-reslts         |   75 +++++++++++++++
 ts-kernbench-run            |   63 +++++++++++++
 ts-unixbench-build          |   77 ++++++++++++++++
 ts-unixbench-reslts         |   84 +++++++++++++++++
 ts-unixbench-run            |   67 ++++++++++++++
 ts-xen-install              |   38 --------
 24 files changed, 1534 insertions(+), 68 deletions(-)
 create mode 100644 Osstest/Benchmarking.pm
 create mode 100755 make-bench-flight
 create mode 100755 mg-host-hw-specs
 create mode 100755 mg-kernbench-download
 create mode 100755 mg-unixbench-download
 create mode 100755 ts-bench-hostcmp-guest-prep
 create mode 100755 ts-bench-hostcmp-host-prep
 create mode 100755 ts-bench-hostcmp-post
 create mode 100755 ts-kernbench-build
 create mode 100755 ts-kernbench-reslts
 create mode 100755 ts-kernbench-run
 create mode 100755 ts-unixbench-build
 create mode 100755 ts-unixbench-reslts
 create mode 100755 ts-unixbench-run

--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylh7-00056w-2i; Wed, 10 Dec 2014 18:09:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylh5-00056p-Jm
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:08:59 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	D6/1A-02697-A3C88845; Wed, 10 Dec 2014 18:08:58 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418234937!12631804!1
X-Originating-IP: [209.85.212.176]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12861 invoked from network); 10 Dec 2014 18:08:57 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:08:57 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so12081388wid.15
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:08:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:user-agent:mime-version
	:content-type:content-transfer-encoding;
	bh=UfESKDRQez/J28ktqaxhLA1KjFPqhjlVD47haOS4lMk=;
	b=t6Cb8Vi59/gZJWS/bgWV+Lj1udhcaQYYnsUIYsvXzNAByTbypLzboBsktUb47QFYDw
	V4dFJQ5+kL+T7YqktfFlbdjXQ0WrwOfRzEUKRutjPCT+4xMc1AEqYYRiYvOAZ3amjHB4
	6jI9LGMb1uoadwvrVSNSZhSNep9ar8E2juu+0CLpXyIj0rN+bx8VnYxCgBKEeUZaTrB3
	EocQ9YFF3qMggnZ1fkCijTVTQLtw80UQPlZ6EcOzjJravh6ohOBAfoc0gYeLItblBOM2
	jhG7HZ1LsBoZ4RrVRCSt+d0hhA1jt6NYx4rMpyqsNcxlKknHJNTuY3JQ0rsIYVuKWBmO
	nO5A==
X-Received: by 10.194.85.83 with SMTP id f19mr9330737wjz.20.1418234937432;
	Wed, 10 Dec 2014 10:08:57 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id p14sm7298633wie.1.2014.12.10.10.08.55
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:08:56 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:08:54 +0100
Message-ID: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 00/27] Running benchmarks via OSSTest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello everyone,

This is a highly reworked and much more mature version of this old RFC series:

  http://lists.xen.org/archives/html/xen-devel/2014-06/msg03429.html

It is about integrating benchmarking capabilities into OSSTest. The series is a
lot bigger, because it is now capable of doing a lot more stuff. :-) All the
comments I got during review of the RFC have been addressed, of course... More
comments are of course welcome!

The series is available here:

  git://xenbits.xen.org/people/dariof/osstest.git benchmarking-with-osstest
  http://xenbits.xen.org/gitweb/?p=people/dariof/osstest.git;a=shortlog;h=refs/heads/benchmarking-with-osstest

So, about the patches. Patches 01 to 04, as well as patch 20, are preliminary
changes and fixes, necessary for the rest of the series to work properly, but
they are general enough to be considered separately from the series, if
interesting.

Patches 05 to 12 make it possible to run an instance of the Unixbench (XXX)
benchmark via OSSTest. Management scripts, test scripts, jobs and recipes are
provided to download the benchmark, prepare the guest (PV or HVM), build the
benchmark in the guest, run it, and retrieve and process (include some super
fancy plots! :-D) the results.

To do so, do as follows (in standalone mode):

  $ ./standalone-reset -t bench
  $ ./mg-unixbench-download
  $ ./standalone run-job -h ultralisk bench-unixbench-amd64-credit-pv-4vcpus-4096ram

One thing about patch 12. I tried, but I can't tell how I should invoke
./standalone in order to test the new parameter I'm adding... Can someone help
with this? IanC?

To have an idea of how the 'output' of one of this jobs looks like, have a look
here:

 http://xenbits.xen.org/people/dariof/osstest-bench/bench-kernbench-amd64-credit-hvm-4vcpus-4096ram.log
 http://xenbits.xen.org/people/dariof/osstest-bench/bench-kernbench-amd64-credit-hvm-4vcpus-4096ram/
 http://xenbits.xen.org/people/dariof/osstest-bench/bench-kernbench-amd64-credit-hvm-4vcpus-4096ram/debianhvm.guest.osstest--kernbench-n4-PLOT.png

Or here:

 http://xenbits.xen.org/people/dariof/osstest-bench/bench-unixbench-amd64-credit-pv-4vcpus-4096ram.log
 http://xenbits.xen.org/people/dariof/osstest-bench/bench-unixbench-amd64-credit-pv-4vcpus-4096ram/
 http://xenbits.xen.org/people/dariof/osstest-bench/bench-unixbench-amd64-credit-pv-4vcpus-4096ram/debian.guest.osstest--unixbench-i1-c4-PLOT.png

Patches 13 to 19 does the very same, but for Kernbench (XXX):

  $ ./mg-kernbench-download
  $ ./standalone run-job -h ultralisk bench-kernbench-amd64-credit-hvm-4vcpus-4096ram

Patches 21 to 27 aims at allowing running a benchmark both in a guest and on
baremetal, to investigate the performances loss due to the virtualization
overhead. To do that, for Unixbench and Kernbench, one just issue the following
commands (in standalone mode):

  $ ./standalone run-job -h ultralisk bench-hostcmp-unixbench-amd64-credit
  $ ./standalone run-job -h ultralisk bench-hostcmp-kernbench-amd64-credit2

To have an idea of how the 'output' of one of these jobs looks like, have a
look here:

 http://xenbits.xen.org/people/dariof/osstest-bench/bench-hostcmp-kernbench-amd64-credit.log
 http://xenbits.xen.org/people/dariof/osstest-bench/bench-hostcmp-kernbench-amd64-credit/
 http://xenbits.xen.org/people/dariof/osstest-bench/bench-hostcmp-kernbench-amd64-credit/bench-hostcmp-kernbench-amd64-credit-PLOT.png

TODOs:
 * in patch 02/27, I haven't actually checked whether also grub1 and/or uboot
   needs fixing
 * When comparing performance, I think it would be best to always use the same
   kernel, in host and guests. This happens by default for PV guest, while it
   does not for HVM guests. This of course can be solved pretty easily, and I
   plan to do it either in future posting of this series, or with a follow-up
   patch.

Regards,
Dario
---
Dario Faggioli (27):
      ts-devbian-hvm-install: prune "cdrom:" from install sources
      Osstest/Debian.pm: fix identifying a Linux baremetal grub2 entry
      Guest setup: allow the amount of RAM to be a runvar
      Osstest/TestSupport.pm: Introduce target_getfile_[root_]stash()
      mg-unixbench-download: new script for downloading the unixbench archive
      ts-unixbench-build: prep the environment for running unixbench
      ts-unixbench-run: kick off the benchmark on the target
      ts-unixbench-reslts: for retrieving the results
      ts-unixbench-reslts: process and plot bench results
      sg-run-job: recipes for the unixbench jobs
      make-bench-flight: to create a benchmarking flight
      standalone-reset: introduce a new -t option
      mg-kernbench-download: new script for downloading kernbench
      ts-kernbench-build: prep the environment for running kernbench
      ts-kernbench-run: kick off the benchmark on the target
      ts-unixbench-reslts: retrieve and stash kernbench results
      ts-kernbench-reslts: process and plot bench results
      sg-run-job: recipes for the kernbench jobs
      make-bench-flight: create kernbench jobs
      Osstest/TestSupport.pm: read hosts' hardware characteristics
      ts-bench-hostcmp-guest-prep: new script
      ts-bench-hostcmp-host-prep: new script
      ts-bench-hostcmp-host-reset: new script
      Recipes and jobs for running unixbench both on host and guest
      ts-bench-hostcmp-post: add plotting facilities
      Kernbench perf comparison between host and guest
      ts-bench-hostcmp-post: add plotting facilities


 Osstest/Benchmarking.pm     |  210 +++++++++++++++++++++++++++++++++++++++++++
 Osstest/Debian.pm           |   54 +++++++----
 Osstest/TestSupport.pm      |  166 +++++++++++++++++++++++++++++++++-
 README                      |   36 +++++++
 cr-daily-branch             |    3 -
 make-bench-flight           |  153 +++++++++++++++++++++++++++++++
 mg-host-hw-specs            |   35 +++++++
 mg-kernbench-download       |   49 ++++++++++
 mg-unixbench-download       |   40 ++++++++
 sg-run-job                  |  102 ++++++++++++++++++++-
 standalone                  |    7 +
 standalone-reset            |    9 +-
 ts-bench-hostcmp-guest-prep |   87 ++++++++++++++++++
 ts-bench-hostcmp-host-prep  |   74 +++++++++++++++
 ts-bench-hostcmp-post       |   81 +++++++++++++++++
 ts-debian-fixup             |    3 +
 ts-debian-hvm-install       |    3 -
 ts-kernbench-build          |   86 ++++++++++++++++++
 ts-kernbench-reslts         |   75 +++++++++++++++
 ts-kernbench-run            |   63 +++++++++++++
 ts-unixbench-build          |   77 ++++++++++++++++
 ts-unixbench-reslts         |   84 +++++++++++++++++
 ts-unixbench-run            |   67 ++++++++++++++
 ts-xen-install              |   38 --------
 24 files changed, 1534 insertions(+), 68 deletions(-)
 create mode 100644 Osstest/Benchmarking.pm
 create mode 100755 make-bench-flight
 create mode 100755 mg-host-hw-specs
 create mode 100755 mg-kernbench-download
 create mode 100755 mg-unixbench-download
 create mode 100755 ts-bench-hostcmp-guest-prep
 create mode 100755 ts-bench-hostcmp-host-prep
 create mode 100755 ts-bench-hostcmp-post
 create mode 100755 ts-kernbench-build
 create mode 100755 ts-kernbench-reslts
 create mode 100755 ts-kernbench-run
 create mode 100755 ts-unixbench-build
 create mode 100755 ts-unixbench-reslts
 create mode 100755 ts-unixbench-run

--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XylhE-00057q-NU; Wed, 10 Dec 2014 18:09:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XylhD-00057V-37
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:07 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	9A/28-27785-24C88845; Wed, 10 Dec 2014 18:09:06 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418234945!8830302!1
X-Originating-IP: [74.125.82.48]
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 838 invoked from network); 10 Dec 2014 18:09:05 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:05 -0000
Received: by mail-wg0-f48.google.com with SMTP id y19so4326060wgg.21
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=poTwtDLEIFWjcJ7uiy/Nm11u5wdUIUeogzfhP/dEV0s=;
	b=JUxPObLZ7w2L91MmgIBIup8CAf24wfeKEcrIhO3AT1bvOdPdgEMFjMzXoGqYCJjjGv
	V4r+vb+lnAz4bwzvU3ueL7c5utwCzRvuw546y+S+t9jC7Z69+EzJkJP32NQKgYtHMKw5
	qxoHAeHy5j3hqbO8xmAJnqQxA70SNwT2IdR9+HJ+Jcoo5qLWKQhP6g9HTG+4+WPLxmMf
	YhfHCxtOaPWZbUiBJ2a42DAfUIwL5hvo6LDmHr98wFAusWFIPqdYpMq9mhZxBFDsTGiL
	IYGOqqebZw6pWFaTtim+8GgMV/mE42wZm3kJtTjIAykGbwv+aYHqaDnHcntW5Ukj0Rvk
	1ANw==
X-Received: by 10.194.179.166 with SMTP id dh6mr8811865wjc.87.1418234945313;
	Wed, 10 Dec 2014 10:09:05 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id gi5sm6806773wjd.26.2014.12.10.10.09.03
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:04 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:02 +0100
Message-ID: <20141210180902.26400.41693.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/27] ts-devbian-hvm-install: prune "cdrom:"
 from install sources
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 sources.list, so installing packages in the guest with
apt-get does not stall waiting for the install CD to be
inserted.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-debian-hvm-install |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 37eade2..e509064 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -78,7 +78,8 @@ 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";
+        in-target sh -c "echo -e '$authkeys'> /root/.ssh/authorized_keys";\\
+        in-target sed -i "/^deb cdrom:/s/^/#/" /etc/apt/sources.list
 END
     return $preseed_file;
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XylhE-00057q-NU; Wed, 10 Dec 2014 18:09:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XylhD-00057V-37
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:07 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	9A/28-27785-24C88845; Wed, 10 Dec 2014 18:09:06 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418234945!8830302!1
X-Originating-IP: [74.125.82.48]
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 838 invoked from network); 10 Dec 2014 18:09:05 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:05 -0000
Received: by mail-wg0-f48.google.com with SMTP id y19so4326060wgg.21
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=poTwtDLEIFWjcJ7uiy/Nm11u5wdUIUeogzfhP/dEV0s=;
	b=JUxPObLZ7w2L91MmgIBIup8CAf24wfeKEcrIhO3AT1bvOdPdgEMFjMzXoGqYCJjjGv
	V4r+vb+lnAz4bwzvU3ueL7c5utwCzRvuw546y+S+t9jC7Z69+EzJkJP32NQKgYtHMKw5
	qxoHAeHy5j3hqbO8xmAJnqQxA70SNwT2IdR9+HJ+Jcoo5qLWKQhP6g9HTG+4+WPLxmMf
	YhfHCxtOaPWZbUiBJ2a42DAfUIwL5hvo6LDmHr98wFAusWFIPqdYpMq9mhZxBFDsTGiL
	IYGOqqebZw6pWFaTtim+8GgMV/mE42wZm3kJtTjIAykGbwv+aYHqaDnHcntW5Ukj0Rvk
	1ANw==
X-Received: by 10.194.179.166 with SMTP id dh6mr8811865wjc.87.1418234945313;
	Wed, 10 Dec 2014 10:09:05 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id gi5sm6806773wjd.26.2014.12.10.10.09.03
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:04 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:02 +0100
Message-ID: <20141210180902.26400.41693.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/27] ts-devbian-hvm-install: prune "cdrom:"
 from install sources
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 sources.list, so installing packages in the guest with
apt-get does not stall waiting for the install CD to be
inserted.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-debian-hvm-install |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 37eade2..e509064 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -78,7 +78,8 @@ 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";
+        in-target sh -c "echo -e '$authkeys'> /root/.ssh/authorized_keys";\\
+        in-target sed -i "/^deb cdrom:/s/^/#/" /etc/apt/sources.list
 END
     return $preseed_file;
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XylhM-00059u-4O; Wed, 10 Dec 2014 18:09:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XylhK-00059Q-FN
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E1/A4-15461-94C88845; Wed, 10 Dec 2014 18:09:13 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418234953!14759491!1
X-Originating-IP: [74.125.82.45]
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 1952 invoked from network); 10 Dec 2014 18:09:13 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:13 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so4356413wgh.4
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=vi2PkYrmHo/O3IMlcEFVcgVn4JbjdSBYSkh1YI9dgfQ=;
	b=y6O3XfT7iTNyidHj/W2qArrO0Gssmai7Fz9Qy6vla0JOCuxN0I2VdXYIT8x9qxyMnm
	zg+TaGUeR26A2TJgcPCIxnrZU16EfppUIEtKmrUdmYGea8vv5Nbbf86YE8yXmu9tpdPJ
	Lu1p8vl8P1sGRPf/OIQQuX/AogL9Z/m+ozycAsAW7odVbuliSxoyB/RniWKhcfQD4XRz
	VU8zenQS1hOzO679Yisvb7xikYr/njrJkEcT9IVllTyS0oeu0tdFnJsgJpABtPQq7z23
	KCPXyoBn7uB/Ky3E0fOz0gJh4K616iHbHMH4n09nq7r4UKI1J+Zfjs4cRvGamJLRj247
	70gA==
X-Received: by 10.194.174.3 with SMTP id bo3mr8898209wjc.98.1418234953061;
	Wed, 10 Dec 2014 10:09:13 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103]) by mx.google.com with ESMTPSA id
	js5sm18880799wid.11.2014.12.10.10.09.11 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:12 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:10 +0100
Message-ID: <20141210180910.26400.81758.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/27] Osstest/Debian.pm: fix identifying a
 Linux baremetal grub2 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

In fact, in setupboot_grub2(), if we are interested
in a Linux baremetal entry, there is no point in
asking for the entry to contain an hypervisor line
("Hv").

Also, in such entry, Linux kernel and initrd are to be
found in "linux" and "initrd" lines, rather than in
"multiboot" and "module" ones.

I haven't actually checked whether also grub1 and/or
uboot needs fixing.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Debian.pm |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..70afaec 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -293,8 +293,8 @@ sub setupboot_grub2 ($$$) {
                 my (@missing) =
                     grep { !defined $entry->{$_} } 
 		        (defined $xenhopt
-			 ? qw(Title Hv KernDom0 KernVer)
-			 : qw(Title Hv KernOnly KernVer));
+                        ? qw(Title Hv KernDom0 KernVer)
+                        : qw(Title KernOnly KernVer));
 		if (@missing) {
 		    logm("(skipping entry at $entry->{StartLine};".
 			 " no @missing)");
@@ -321,11 +321,14 @@ sub setupboot_grub2 ($$$) {
                 die unless $entry;
                 $entry->{Hv}= $1;
             }
-            if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
+            if (m/^\s*linux\s*\/(vmlinu[xz]-(\S+))/) {
                 die unless $entry;
                 $entry->{KernOnly}= $1;
                 $entry->{KernVer}= $2;
             }
+            if (m/^\s*initrd\s*\/(initrd\S+)/) {
+                $entry->{Initrd}= $1;
+            }
             if (m/^\s*module\s*\/(vmlinu[xz]-(\S+))/) {
                 die unless $entry;
                 $entry->{KernDom0}= $1;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XylhM-00059u-4O; Wed, 10 Dec 2014 18:09:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XylhK-00059Q-FN
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:14 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E1/A4-15461-94C88845; Wed, 10 Dec 2014 18:09:13 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418234953!14759491!1
X-Originating-IP: [74.125.82.45]
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 1952 invoked from network); 10 Dec 2014 18:09:13 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:13 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so4356413wgh.4
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=vi2PkYrmHo/O3IMlcEFVcgVn4JbjdSBYSkh1YI9dgfQ=;
	b=y6O3XfT7iTNyidHj/W2qArrO0Gssmai7Fz9Qy6vla0JOCuxN0I2VdXYIT8x9qxyMnm
	zg+TaGUeR26A2TJgcPCIxnrZU16EfppUIEtKmrUdmYGea8vv5Nbbf86YE8yXmu9tpdPJ
	Lu1p8vl8P1sGRPf/OIQQuX/AogL9Z/m+ozycAsAW7odVbuliSxoyB/RniWKhcfQD4XRz
	VU8zenQS1hOzO679Yisvb7xikYr/njrJkEcT9IVllTyS0oeu0tdFnJsgJpABtPQq7z23
	KCPXyoBn7uB/Ky3E0fOz0gJh4K616iHbHMH4n09nq7r4UKI1J+Zfjs4cRvGamJLRj247
	70gA==
X-Received: by 10.194.174.3 with SMTP id bo3mr8898209wjc.98.1418234953061;
	Wed, 10 Dec 2014 10:09:13 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103]) by mx.google.com with ESMTPSA id
	js5sm18880799wid.11.2014.12.10.10.09.11 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:12 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:10 +0100
Message-ID: <20141210180910.26400.81758.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/27] Osstest/Debian.pm: fix identifying a
 Linux baremetal grub2 entry
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

In fact, in setupboot_grub2(), if we are interested
in a Linux baremetal entry, there is no point in
asking for the entry to contain an hypervisor line
("Hv").

Also, in such entry, Linux kernel and initrd are to be
found in "linux" and "initrd" lines, rather than in
"multiboot" and "module" ones.

I haven't actually checked whether also grub1 and/or
uboot needs fixing.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Debian.pm |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..70afaec 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -293,8 +293,8 @@ sub setupboot_grub2 ($$$) {
                 my (@missing) =
                     grep { !defined $entry->{$_} } 
 		        (defined $xenhopt
-			 ? qw(Title Hv KernDom0 KernVer)
-			 : qw(Title Hv KernOnly KernVer));
+                        ? qw(Title Hv KernDom0 KernVer)
+                        : qw(Title KernOnly KernVer));
 		if (@missing) {
 		    logm("(skipping entry at $entry->{StartLine};".
 			 " no @missing)");
@@ -321,11 +321,14 @@ sub setupboot_grub2 ($$$) {
                 die unless $entry;
                 $entry->{Hv}= $1;
             }
-            if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
+            if (m/^\s*linux\s*\/(vmlinu[xz]-(\S+))/) {
                 die unless $entry;
                 $entry->{KernOnly}= $1;
                 $entry->{KernVer}= $2;
             }
+            if (m/^\s*initrd\s*\/(initrd\S+)/) {
+                $entry->{Initrd}= $1;
+            }
             if (m/^\s*module\s*\/(vmlinu[xz]-(\S+))/) {
                 die unless $entry;
                 $entry->{KernDom0}= $1;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XylhU-0005CD-H7; Wed, 10 Dec 2014 18:09:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XylhT-0005Bq-7b
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:23 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	35/C7-28296-25C88845; Wed, 10 Dec 2014 18:09:22 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418234961!12452115!1
X-Originating-IP: [74.125.82.44]
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 19153 invoked from network); 10 Dec 2014 18:09:21 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:21 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so4330935wgh.17
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=DmMTeaxOq3RfXny1QCwSxmm3H1hdbhZl2bIp0TWOrZY=;
	b=sqqUH1HcHmVmVqxMwSejAvVxi46WLOM8VxHQlVBGYuHr4pxJZjNC7BePPHKTeGnALo
	PFV39lSwrlArYkVnLfEXvhmDyRZtJQBMh6yJQRNvntfAckO2sU4tzzeW0EUvtmz0n/rs
	dPoVjOU2DlVizyM0Iz1uK7iCUJzJ4E8RknEE6WR2XDTdl873I6hcIjoI73gab4ZuOWI5
	5PSQOEjmhDUqeO9k7+4RJM+2jeYBUQSPW2vZBjT1hBn9/qEH/XjraIJspMQ3E/lue9w/
	O+2956muuhJl5o374lOxA8Mpv/D9uDfSYXk87CxIAqixgV9yDdr6QgubZ3ZAA3B2Hrxt
	jLTA==
X-Received: by 10.180.211.84 with SMTP id na20mr15493703wic.41.1418234961204; 
	Wed, 10 Dec 2014 10:09:21 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id l3sm6818796wje.12.2014.12.10.10.09.19
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:20 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:18 +0100
Message-ID: <20141210180918.26400.69599.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03/27] Guest setup: allow the amount of RAM to
	be a runvar
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

the value of which can be retrieved via guest_var('memory');.

This works for both PV and HVM Debian guests.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm |    3 ++-
 ts-debian-fixup        |    3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index a3b6936..cdff8d5 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1460,11 +1460,12 @@ sub prepareguest_part_xencfg ($$$$$) {
     my ($ho, $gho, $ram_mb, $xopts, $cfgrest) = @_;
     my $onreboot= $xopts->{OnReboot} || 'restart';
     my $vcpus= guest_var($gho, 'vcpus', $xopts->{DefVcpus} || 2);
+    my $memory= guest_var($gho, 'memory', $xopts->{DefMem} || $ram_mb);
     my $xoptcfg= $xopts->{ExtraConfig};
     $xoptcfg='' unless defined $xoptcfg;
     my $xencfg= <<END;
 name        = '$gho->{Name}'
-memory = ${ram_mb}
+memory = ${memory}
 vif         = [ 'type=ioemu,mac=$gho->{Ether}' ]
 #
 on_poweroff = 'destroy'
diff --git a/ts-debian-fixup b/ts-debian-fixup
index f001418..f85b06d 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -113,10 +113,13 @@ sub setcfg ($$) {
 
 sub otherfixupcfg () {
     my $vcpus= guest_var($gho,'vcpus',1);
+    my $ram_mb= guest_var($gho,'memory',512);
     $cfg =~ s/^dhcp/#$&/mg;
     $cfg =~ s/^on_crash.*/on_crash='preserve'/mg;
     $cfg =~ s/^vcpus.*//mg;
     $cfg .= "\nvcpus = $vcpus\n";
+    $cfg =~ s/^memory.*//mg;
+    $cfg .= "\nmemory = $ram_mb\n";
 
     # PCI passthrough
     # Look for runvars   <gn>_pcipassthrough_<devtype>=<hostident>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XylhU-0005CD-H7; Wed, 10 Dec 2014 18:09:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XylhT-0005Bq-7b
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:23 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	35/C7-28296-25C88845; Wed, 10 Dec 2014 18:09:22 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418234961!12452115!1
X-Originating-IP: [74.125.82.44]
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 19153 invoked from network); 10 Dec 2014 18:09:21 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:21 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so4330935wgh.17
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=DmMTeaxOq3RfXny1QCwSxmm3H1hdbhZl2bIp0TWOrZY=;
	b=sqqUH1HcHmVmVqxMwSejAvVxi46WLOM8VxHQlVBGYuHr4pxJZjNC7BePPHKTeGnALo
	PFV39lSwrlArYkVnLfEXvhmDyRZtJQBMh6yJQRNvntfAckO2sU4tzzeW0EUvtmz0n/rs
	dPoVjOU2DlVizyM0Iz1uK7iCUJzJ4E8RknEE6WR2XDTdl873I6hcIjoI73gab4ZuOWI5
	5PSQOEjmhDUqeO9k7+4RJM+2jeYBUQSPW2vZBjT1hBn9/qEH/XjraIJspMQ3E/lue9w/
	O+2956muuhJl5o374lOxA8Mpv/D9uDfSYXk87CxIAqixgV9yDdr6QgubZ3ZAA3B2Hrxt
	jLTA==
X-Received: by 10.180.211.84 with SMTP id na20mr15493703wic.41.1418234961204; 
	Wed, 10 Dec 2014 10:09:21 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id l3sm6818796wje.12.2014.12.10.10.09.19
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:20 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:18 +0100
Message-ID: <20141210180918.26400.69599.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03/27] Guest setup: allow the amount of RAM to
	be a runvar
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

the value of which can be retrieved via guest_var('memory');.

This works for both PV and HVM Debian guests.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm |    3 ++-
 ts-debian-fixup        |    3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index a3b6936..cdff8d5 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1460,11 +1460,12 @@ sub prepareguest_part_xencfg ($$$$$) {
     my ($ho, $gho, $ram_mb, $xopts, $cfgrest) = @_;
     my $onreboot= $xopts->{OnReboot} || 'restart';
     my $vcpus= guest_var($gho, 'vcpus', $xopts->{DefVcpus} || 2);
+    my $memory= guest_var($gho, 'memory', $xopts->{DefMem} || $ram_mb);
     my $xoptcfg= $xopts->{ExtraConfig};
     $xoptcfg='' unless defined $xoptcfg;
     my $xencfg= <<END;
 name        = '$gho->{Name}'
-memory = ${ram_mb}
+memory = ${memory}
 vif         = [ 'type=ioemu,mac=$gho->{Ether}' ]
 #
 on_poweroff = 'destroy'
diff --git a/ts-debian-fixup b/ts-debian-fixup
index f001418..f85b06d 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -113,10 +113,13 @@ sub setcfg ($$) {
 
 sub otherfixupcfg () {
     my $vcpus= guest_var($gho,'vcpus',1);
+    my $ram_mb= guest_var($gho,'memory',512);
     $cfg =~ s/^dhcp/#$&/mg;
     $cfg =~ s/^on_crash.*/on_crash='preserve'/mg;
     $cfg =~ s/^vcpus.*//mg;
     $cfg .= "\nvcpus = $vcpus\n";
+    $cfg =~ s/^memory.*//mg;
+    $cfg .= "\nmemory = $ram_mb\n";
 
     # PCI passthrough
     # Look for runvars   <gn>_pcipassthrough_<devtype>=<hostident>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1Xylhk-0005IA-71; Wed, 10 Dec 2014 18:09:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylhi-0005HM-DW
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:38 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	4F/4A-28865-16C88845; Wed, 10 Dec 2014 18:09:37 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418234977!5067777!1
X-Originating-IP: [209.85.212.178]
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 881 invoked from network); 10 Dec 2014 18:09:37 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:37 -0000
Received: by mail-wi0-f178.google.com with SMTP id em10so6061078wid.11
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=yCyyad2q9KcGsxLXu2KMoxPh3NN7awfECxpjfD26F+Q=;
	b=dez7M1kUG8ZoPotlXyqrlE0gnNsY634veg9IEXe6uECK4DQSyP22sqduAi+fziMcHV
	Fp0SFnuDkAGR94IIMEjL+fRJO/uVSiFOs08NJyLJ5lw1FEgY5ArPFKdpvlkmK2X9VEbp
	n4n7htI4VMSbsd3lCdHqcDf4d96t+yTk0l62xdyDVn1LSYumNUE5AMCpcuv3+wGv83YQ
	uwq3gYUpsWlR0yUzxwTNVOHmFTbKgpeiy65NFWsgQN2lbZAXsWNAU4qsK+6wqVm0of/n
	QtzcYo8sqwsMHc1cpOAMCauVBusWe8uQQ3Pp4bm4x9t2/TAZDWtaQZK37hESISWYumE5
	LAYA==
X-Received: by 10.194.246.130 with SMTP id xw2mr8577449wjc.33.1418234976995;
	Wed, 10 Dec 2014 10:09:36 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id pf4sm6800507wjb.36.2014.12.10.10.09.35
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:36 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:34 +0100
Message-ID: <20141210180934.26400.45752.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/27] mg-unixbench-download: new script for
 downloading the unixbench archive
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The script fetches it, and saves it in c{Images}/benchs.

Default values for the repo URL and actual filename are embedded
in the script itself, and can be overridden as usual (e.g., via
standalone.config).

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
Changes from RFCv1:
 * stop using ap-common for default values (for URL and remote
   filename), as requested during review.
---
 mg-unixbench-download |   40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100755 mg-unixbench-download

diff --git a/mg-unixbench-download b/mg-unixbench-download
new file mode 100755
index 0000000..85184c9
--- /dev/null
+++ b/mg-unixbench-download
@@ -0,0 +1,40 @@
+#!/bin/bash
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+set -e
+
+if [ -f standalone.config ] ; then
+    . standalone.config
+fi
+
+. cri-getconfig
+
+fail () { echo >&2 "$0: $1"; exit 1; }
+
+# By default we try to grab Unixbench 5.1.3
+site=${UNIXBENCH_REPO:-http://byte-unixbench.googlecode.com/files}
+rfile=${UNIXBENCH_FILE:-unixbench-5.1.3.tgz}
+lfile=unixbench.tgz
+
+images=`getconfig Images`;
+dstdir="${images}/benchs"
+mkdir -p $dstdir
+
+wget ${site}/${rfile} -O ${dstdir}/${lfile} || \
+    fail "failed downloading the benchmark"
+
+echo >&2 "downloaded $dstdir/$lfile"


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1Xylhk-0005IA-71; Wed, 10 Dec 2014 18:09:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylhi-0005HM-DW
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:38 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	4F/4A-28865-16C88845; Wed, 10 Dec 2014 18:09:37 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418234977!5067777!1
X-Originating-IP: [209.85.212.178]
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 881 invoked from network); 10 Dec 2014 18:09:37 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:37 -0000
Received: by mail-wi0-f178.google.com with SMTP id em10so6061078wid.11
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=yCyyad2q9KcGsxLXu2KMoxPh3NN7awfECxpjfD26F+Q=;
	b=dez7M1kUG8ZoPotlXyqrlE0gnNsY634veg9IEXe6uECK4DQSyP22sqduAi+fziMcHV
	Fp0SFnuDkAGR94IIMEjL+fRJO/uVSiFOs08NJyLJ5lw1FEgY5ArPFKdpvlkmK2X9VEbp
	n4n7htI4VMSbsd3lCdHqcDf4d96t+yTk0l62xdyDVn1LSYumNUE5AMCpcuv3+wGv83YQ
	uwq3gYUpsWlR0yUzxwTNVOHmFTbKgpeiy65NFWsgQN2lbZAXsWNAU4qsK+6wqVm0of/n
	QtzcYo8sqwsMHc1cpOAMCauVBusWe8uQQ3Pp4bm4x9t2/TAZDWtaQZK37hESISWYumE5
	LAYA==
X-Received: by 10.194.246.130 with SMTP id xw2mr8577449wjc.33.1418234976995;
	Wed, 10 Dec 2014 10:09:36 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id pf4sm6800507wjb.36.2014.12.10.10.09.35
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:36 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:34 +0100
Message-ID: <20141210180934.26400.45752.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/27] mg-unixbench-download: new script for
 downloading the unixbench archive
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The script fetches it, and saves it in c{Images}/benchs.

Default values for the repo URL and actual filename are embedded
in the script itself, and can be overridden as usual (e.g., via
standalone.config).

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
Changes from RFCv1:
 * stop using ap-common for default values (for URL and remote
   filename), as requested during review.
---
 mg-unixbench-download |   40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100755 mg-unixbench-download

diff --git a/mg-unixbench-download b/mg-unixbench-download
new file mode 100755
index 0000000..85184c9
--- /dev/null
+++ b/mg-unixbench-download
@@ -0,0 +1,40 @@
+#!/bin/bash
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+set -e
+
+if [ -f standalone.config ] ; then
+    . standalone.config
+fi
+
+. cri-getconfig
+
+fail () { echo >&2 "$0: $1"; exit 1; }
+
+# By default we try to grab Unixbench 5.1.3
+site=${UNIXBENCH_REPO:-http://byte-unixbench.googlecode.com/files}
+rfile=${UNIXBENCH_FILE:-unixbench-5.1.3.tgz}
+lfile=unixbench.tgz
+
+images=`getconfig Images`;
+dstdir="${images}/benchs"
+mkdir -p $dstdir
+
+wget ${site}/${rfile} -O ${dstdir}/${lfile} || \
+    fail "failed downloading the benchmark"
+
+echo >&2 "downloaded $dstdir/$lfile"


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1Xylhp-0005KQ-JH; Wed, 10 Dec 2014 18:09:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylhn-0005JT-KC
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:43 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	37/26-02576-66C88845; Wed, 10 Dec 2014 18:09:42 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418234982!14265467!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26758 invoked from network); 10 Dec 2014 18:09:42 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:42 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so4388441wgg.29
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=dhfRl5QRlg/624xca04rB01pKm0w7baLZhCK3/ovkSw=;
	b=f5bR8iAQ0fJNL3m1uBRBEbNQR/0njRfaltD/hpydNXNlSu2sRYJxTwiPmYVZ72oFIL
	OfuXojXWxL/w0QmBH2CvOAyvlJgM3BYYy9EYjb4raYKh7Ccjg0GfEwFtR0u7dgPqum0o
	58oH4DnhqWR0scthOCkC5IYfnIhlaONtsZztTQiubZDhzPgxu6Jkqcu0z+wfDsqVDrMM
	/zU4biWKce89EkffaO76r9bz65KKCxmLixSSzXD00VlUeOI+BHOwyPhqAF+UgatknnGs
	7OzNa6gtFfggsRkWP/gbkPnyEW6cUj/pwiP9/JW6TIZAPbLMgIzCrfjSKif1+RZ9nHkN
	rj+g==
X-Received: by 10.194.85.197 with SMTP id j5mr8774794wjz.106.1418234969107;
	Wed, 10 Dec 2014 10:09:29 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id mw7sm7282497wib.14.2014.12.10.10.09.27
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:28 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:26 +0100
Message-ID: <20141210180926.26400.76982.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/27] Osstest/TestSupport.pm: Introduce
 target_getfile_[root_]stash()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

As an analogue to target_putfilecontents_[root_]stash().

(While at it, fix one whitespace damaged line.)

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
Changes from RFCv1:
 * adding this was requested during review.
---
 Osstest/TestSupport.pm |   17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index cdff8d5..67befd0 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -53,7 +53,8 @@ BEGIN {
                       target_getfile target_getfile_root
                       target_putfile target_putfile_root
                       target_putfilecontents_stash
-		      target_putfilecontents_root_stash
+                      target_putfilecontents_root_stash
+                      target_getfile_stash target_getfile_root_stash
                       target_put_guest_image target_editfile
                       target_editfile_root target_file_exists
                       target_run_apt
@@ -473,6 +474,20 @@ sub target_putfilecontents_root_stash ($$$$;$) {
     tpfcs_core(\&target_putfile_root, @_);
 }
 
+sub tgfs_core {
+    my ($tgetfilef,$ho,$timeout,$rsrc,$lleaf) = @_;
+    target_somefile_getleaf(\$lleaf,$rsrc,$ho);
+    $tgetfilef->($ho, $timeout, $rsrc, "$stash/$lleaf");
+}
+sub target_getfile_stash ($$$;$) {
+    my ($ho,$timeout,$rsrc,$lleaf) = @_;
+    tgfs_core(\&target_getfile, @_);
+}
+sub target_getfile_root_stash ($$$;$) {
+    my ($ho,$timeout,$rsrc,$lleaf) = @_;
+    tgfs_core(\&target_getfile_root, @_);
+}
+
 sub target_file_exists ($$) {
     my ($ho,$rfile) = @_;
     my $out= target_cmd_output($ho, "if test -e $rfile; then echo y; fi");


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1Xylhp-0005KQ-JH; Wed, 10 Dec 2014 18:09:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylhn-0005JT-KC
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:43 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	37/26-02576-66C88845; Wed, 10 Dec 2014 18:09:42 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418234982!14265467!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26758 invoked from network); 10 Dec 2014 18:09:42 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:42 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so4388441wgg.29
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=dhfRl5QRlg/624xca04rB01pKm0w7baLZhCK3/ovkSw=;
	b=f5bR8iAQ0fJNL3m1uBRBEbNQR/0njRfaltD/hpydNXNlSu2sRYJxTwiPmYVZ72oFIL
	OfuXojXWxL/w0QmBH2CvOAyvlJgM3BYYy9EYjb4raYKh7Ccjg0GfEwFtR0u7dgPqum0o
	58oH4DnhqWR0scthOCkC5IYfnIhlaONtsZztTQiubZDhzPgxu6Jkqcu0z+wfDsqVDrMM
	/zU4biWKce89EkffaO76r9bz65KKCxmLixSSzXD00VlUeOI+BHOwyPhqAF+UgatknnGs
	7OzNa6gtFfggsRkWP/gbkPnyEW6cUj/pwiP9/JW6TIZAPbLMgIzCrfjSKif1+RZ9nHkN
	rj+g==
X-Received: by 10.194.85.197 with SMTP id j5mr8774794wjz.106.1418234969107;
	Wed, 10 Dec 2014 10:09:29 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id mw7sm7282497wib.14.2014.12.10.10.09.27
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:28 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:26 +0100
Message-ID: <20141210180926.26400.76982.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/27] Osstest/TestSupport.pm: Introduce
 target_getfile_[root_]stash()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

As an analogue to target_putfilecontents_[root_]stash().

(While at it, fix one whitespace damaged line.)

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
Changes from RFCv1:
 * adding this was requested during review.
---
 Osstest/TestSupport.pm |   17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index cdff8d5..67befd0 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -53,7 +53,8 @@ BEGIN {
                       target_getfile target_getfile_root
                       target_putfile target_putfile_root
                       target_putfilecontents_stash
-		      target_putfilecontents_root_stash
+                      target_putfilecontents_root_stash
+                      target_getfile_stash target_getfile_root_stash
                       target_put_guest_image target_editfile
                       target_editfile_root target_file_exists
                       target_run_apt
@@ -473,6 +474,20 @@ sub target_putfilecontents_root_stash ($$$$;$) {
     tpfcs_core(\&target_putfile_root, @_);
 }
 
+sub tgfs_core {
+    my ($tgetfilef,$ho,$timeout,$rsrc,$lleaf) = @_;
+    target_somefile_getleaf(\$lleaf,$rsrc,$ho);
+    $tgetfilef->($ho, $timeout, $rsrc, "$stash/$lleaf");
+}
+sub target_getfile_stash ($$$;$) {
+    my ($ho,$timeout,$rsrc,$lleaf) = @_;
+    tgfs_core(\&target_getfile, @_);
+}
+sub target_getfile_root_stash ($$$;$) {
+    my ($ho,$timeout,$rsrc,$lleaf) = @_;
+    tgfs_core(\&target_getfile_root, @_);
+}
+
 sub target_file_exists ($$) {
     my ($ho,$rfile) = @_;
     my $out= target_cmd_output($ho, "if test -e $rfile; then echo y; fi");


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylhs-0005M5-1J; Wed, 10 Dec 2014 18:09:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylhq-0005Kp-Io
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8A/5F-09842-96C88845; Wed, 10 Dec 2014 18:09:45 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418234985!14759592!1
X-Originating-IP: [209.85.212.170]
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 4574 invoked from network); 10 Dec 2014 18:09:45 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:45 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so14168324wib.3
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=JeeCLNFF720rF07oO5EuZU1JMkEbDsNlNZnU2Vcklh8=;
	b=XH5TtSdXoWhoEIt7aHlOkCTWCTrElEfdgCHkA/k0V28Uw/uNhs4coLNNybHV+D/oCH
	YHnaG0Rv2sEKpqc2NSaKFzwqpMMwmqIjiMUIRUK920LR4IEWSz3BXFDMeCJEehKRBvgp
	p3xBhnvr4oEwPA4PC/KPPqeJIPsVcVcOLhKyu39gX+ai+9wMOeppkEC5w7N91vvhPWgN
	+kC8iQInP18VUAW/qXK1XZyZQubYnJwLCkYYEy4Ims/jton2gC4zcFETDWTgR3ZvirFm
	se8e8qWGyg9WgqZUex7osd5Xd9BF6SMmmVD09l1s5YuoTLiavGKSuTkCnTfhDubHvagk
	L8HQ==
X-Received: by 10.181.13.106 with SMTP id ex10mr8493662wid.36.1418234984958;
	Wed, 10 Dec 2014 10:09:44 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103]) by mx.google.com with ESMTPSA id
	bo18sm7287539wib.11.2014.12.10.10.09.43 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:44 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:42 +0100
Message-ID: <20141210180942.26400.95893.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06/27] ts-unixbench-build: prep the environment
 for running unixbench
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 installing some dependencies, shipping the archive, untaring
and building the sources.

This accepts two parametrs, in the form 'host=somehost someguest',
as most of the ts-guest-xxx scripts. If only the first one is
provided, it must be 'host=somehost', and the script will prep
the host.

As this installs some packages, troubles may arise if running
on a shered test host. This is not a too big deal, as hosts
used for benchmarking should not be shared anyway. In any case,
this patch from Ian Campbell will make the issue go away:

  http://lists.xen.org/archives/html/xen-devel/2014-04/msg02978.html

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
Changes from RFCv1:
 * make selecthost() interact directly with @ARGV, as
   requested during review;
 * renamed to -build (from -prep), as suggested during review;
 * use 'xaf' for automatic archive type detection, as suggested
   during review.
---
 ts-unixbench-build |   77 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100755 ts-unixbench-build

diff --git a/ts-unixbench-build b/ts-unixbench-build
new file mode 100755
index 0000000..4852609
--- /dev/null
+++ b/ts-unixbench-build
@@ -0,0 +1,77 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+use File::Basename;
+
+tsreadconfig();
+
+# what we expect as argument list is:
+#  host=<somehost> [<someguest>]
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+our $gho= $ho;
+if (defined $gn and $gn ne "") {
+  $gho= selectguest($gn, $ho);
+  my $err= guest_check_ip($gho);
+  die "$err $gho->{Name}" if defined $err;
+}
+
+# By default, we expect to find UnixBench 5.1.3, stored in
+# $c{Images}/benchs/unixbench.tgz. To use something different, define
+# r{'unixbench_file'}.
+our $unixbench_file= (defined($r{'unixbench_file'})) ?
+      $r{'unixbench_file'} : "$c{Images}/benchs/unixbench.tgz";
+
+# Prepare the target, by installing dependencies, and building the benchmark
+sub install_deps() {
+  target_install_packages_norec($gho, qw(build-essential libx11-dev
+                                         libgl1-mesa-dev libxext-dev
+                                         x11-apps));
+}
+
+# Ship the benchmark to the target machine
+sub ship() {
+  logm("Shipping and extracting $unixbench_file");
+  target_putfile_root($gho, 60, "$unixbench_file", "/root");
+
+  our $unixbench_filename= basename $unixbench_file;
+  target_cmd_root($gho, <<END, 200);
+      set -ex
+      rm -rf /root/unixbench/
+      mkdir /root/unixbench
+      tar xaf /root/$unixbench_filename -C /root/unixbench --strip-components=1
+END
+}
+
+sub build() {
+  target_cmd_root($gho, <<END, 200);
+      set -ex
+      cd /root/unixbench
+      sed -e "s/^# GRAPHIC_TESTS =/GRAPHIC_TESTS =/" -i Makefile
+      make
+END
+}
+
+install_deps();
+ship();
+build();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylhs-0005M5-1J; Wed, 10 Dec 2014 18:09:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylhq-0005Kp-Io
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8A/5F-09842-96C88845; Wed, 10 Dec 2014 18:09:45 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418234985!14759592!1
X-Originating-IP: [209.85.212.170]
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 4574 invoked from network); 10 Dec 2014 18:09:45 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:45 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so14168324wib.3
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=JeeCLNFF720rF07oO5EuZU1JMkEbDsNlNZnU2Vcklh8=;
	b=XH5TtSdXoWhoEIt7aHlOkCTWCTrElEfdgCHkA/k0V28Uw/uNhs4coLNNybHV+D/oCH
	YHnaG0Rv2sEKpqc2NSaKFzwqpMMwmqIjiMUIRUK920LR4IEWSz3BXFDMeCJEehKRBvgp
	p3xBhnvr4oEwPA4PC/KPPqeJIPsVcVcOLhKyu39gX+ai+9wMOeppkEC5w7N91vvhPWgN
	+kC8iQInP18VUAW/qXK1XZyZQubYnJwLCkYYEy4Ims/jton2gC4zcFETDWTgR3ZvirFm
	se8e8qWGyg9WgqZUex7osd5Xd9BF6SMmmVD09l1s5YuoTLiavGKSuTkCnTfhDubHvagk
	L8HQ==
X-Received: by 10.181.13.106 with SMTP id ex10mr8493662wid.36.1418234984958;
	Wed, 10 Dec 2014 10:09:44 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103]) by mx.google.com with ESMTPSA id
	bo18sm7287539wib.11.2014.12.10.10.09.43 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:44 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:42 +0100
Message-ID: <20141210180942.26400.95893.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06/27] ts-unixbench-build: prep the environment
 for running unixbench
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 installing some dependencies, shipping the archive, untaring
and building the sources.

This accepts two parametrs, in the form 'host=somehost someguest',
as most of the ts-guest-xxx scripts. If only the first one is
provided, it must be 'host=somehost', and the script will prep
the host.

As this installs some packages, troubles may arise if running
on a shered test host. This is not a too big deal, as hosts
used for benchmarking should not be shared anyway. In any case,
this patch from Ian Campbell will make the issue go away:

  http://lists.xen.org/archives/html/xen-devel/2014-04/msg02978.html

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
Changes from RFCv1:
 * make selecthost() interact directly with @ARGV, as
   requested during review;
 * renamed to -build (from -prep), as suggested during review;
 * use 'xaf' for automatic archive type detection, as suggested
   during review.
---
 ts-unixbench-build |   77 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100755 ts-unixbench-build

diff --git a/ts-unixbench-build b/ts-unixbench-build
new file mode 100755
index 0000000..4852609
--- /dev/null
+++ b/ts-unixbench-build
@@ -0,0 +1,77 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+use File::Basename;
+
+tsreadconfig();
+
+# what we expect as argument list is:
+#  host=<somehost> [<someguest>]
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+our $gho= $ho;
+if (defined $gn and $gn ne "") {
+  $gho= selectguest($gn, $ho);
+  my $err= guest_check_ip($gho);
+  die "$err $gho->{Name}" if defined $err;
+}
+
+# By default, we expect to find UnixBench 5.1.3, stored in
+# $c{Images}/benchs/unixbench.tgz. To use something different, define
+# r{'unixbench_file'}.
+our $unixbench_file= (defined($r{'unixbench_file'})) ?
+      $r{'unixbench_file'} : "$c{Images}/benchs/unixbench.tgz";
+
+# Prepare the target, by installing dependencies, and building the benchmark
+sub install_deps() {
+  target_install_packages_norec($gho, qw(build-essential libx11-dev
+                                         libgl1-mesa-dev libxext-dev
+                                         x11-apps));
+}
+
+# Ship the benchmark to the target machine
+sub ship() {
+  logm("Shipping and extracting $unixbench_file");
+  target_putfile_root($gho, 60, "$unixbench_file", "/root");
+
+  our $unixbench_filename= basename $unixbench_file;
+  target_cmd_root($gho, <<END, 200);
+      set -ex
+      rm -rf /root/unixbench/
+      mkdir /root/unixbench
+      tar xaf /root/$unixbench_filename -C /root/unixbench --strip-components=1
+END
+}
+
+sub build() {
+  target_cmd_root($gho, <<END, 200);
+      set -ex
+      cd /root/unixbench
+      sed -e "s/^# GRAPHIC_TESTS =/GRAPHIC_TESTS =/" -i Makefile
+      make
+END
+}
+
+install_deps();
+ship();
+build();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylhz-0005RG-Ff; Wed, 10 Dec 2014 18:09:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylhy-0005Q5-9R
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:54 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	AA/49-25714-17C88845; Wed, 10 Dec 2014 18:09:53 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418234992!5067812!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2030 invoked from network); 10 Dec 2014 18:09:52 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:52 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so12110185wiv.11
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=27TzyEq4e20HyBdEnyCA1vRBEGQXALZqAZsSO1CNrWA=;
	b=KkQ8lNcGTu2K+Roy/ioWKl2XdUPdvUG744VpOS79z12/mofctpjZ9L2QHNfWL0cgjz
	eE4Z7sZwqZgdoIOsh4gEsQJdCv1Rr3P0Dbtznhv+/d5da4/J33qYpMgIzQ/cF3AGG9Wf
	VZb0OU38V1rMrR6aghK15Gb8xLIl53TTyx36ewDtwcnxqT6Qs+CeoFQvcwSOllivg8yy
	pqy8axVIWUMkt229XPP4in19/d7gX9uafWp+L/GBmzGXc6QS52717FSkD24+ozB+usXb
	t0WFgFBvU7g5uZzJ6kAFNUvJHW3A5U/d/02ri13fabvXprdM2QfI0BXjLjq8p+z5b8yu
	B5AQ==
X-Received: by 10.180.228.37 with SMTP id sf5mr15561730wic.35.1418234992742;
	Wed, 10 Dec 2014 10:09:52 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id td6sm7282719wic.15.2014.12.10.10.09.51
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:52 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:50 +0100
Message-ID: <20141210180950.26400.14357.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07/27] ts-unixbench-run: kick off the benchmark
	on the 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

There is a runvar called 'unixbench_params', for specifying
the benchmark's runtime arguments.

The commit also adds a couple of generic functions in
TestSupport.pm, for `cat'-ing the content of a file on
the target into a corresponding file in the stash area.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
Changes from RFCv1:
 * add default value for runtime arguments.
---
 Osstest/TestSupport.pm |   23 ++++++++++++++++
 ts-unixbench-run       |   67 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+)
 create mode 100755 ts-unixbench-run

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 67befd0..7cc5be6 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -57,6 +57,7 @@ BEGIN {
                       target_getfile_stash target_getfile_root_stash
                       target_put_guest_image target_editfile
                       target_editfile_root target_file_exists
+                      target_catfile_stash target_catfile_root_stash
                       target_run_apt
                       target_install_packages target_install_packages_norec
                       target_jobdir target_extract_jobdistpath_subdir
@@ -488,6 +489,28 @@ sub target_getfile_root_stash ($$$;$) {
     tgfs_core(\&target_getfile_root, @_);
 }
 
+sub tcfs_core {
+  my ($tcmdoutf,$ho,$rfile)= @_;
+  my $lleaf;
+
+  target_somefile_getleaf(\$lleaf,$rfile,$ho);
+
+  my $h= new IO::File "$stash/$lleaf", 'w' or die $!;
+  my $fdata= $tcmdoutf->($ho, "cat $rfile");
+  print $h $fdata or die $!;
+  close $h or die $!;
+}
+
+sub target_catfile_stash ($$) {
+  my ($ho,$rfile)= @_;
+  tcfs_core(\&target_cmd_output,@_);
+}
+
+sub target_catfile_root_stash ($$) {
+  my ($ho,$rfile)= @_;
+  tcfs_core(\&target_cmd_output_root,@_);
+}
+
 sub target_file_exists ($$) {
     my ($ho,$rfile) = @_;
     my $out= target_cmd_output($ho, "if test -e $rfile; then echo y; fi");
diff --git a/ts-unixbench-run b/ts-unixbench-run
new file mode 100755
index 0000000..47e6964
--- /dev/null
+++ b/ts-unixbench-run
@@ -0,0 +1,67 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+# what we expect as argument list is:
+#  host=<somehost> [<someguest>]
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+our $gho= $ho;
+if (defined $gn and $gn ne "") {
+  $gho= selectguest($gn, $ho);
+  my $err= guest_check_ip($gho);
+  die "$err $gho->{Name}" if defined $err;
+}
+
+# Runtime parameters for the benchmark. We expect them to be
+# specified via a runvar. If not, let's provide a safe default.
+if (!defined($r{ 'unixbench_params' })) {
+  store_runvar('unixbench_params',"-i 3");
+}
+our $args= $r{'unixbench_params'};
+our $timeout= (defined($r{'unixbench_timeout'})) ?
+      $r{'unixbench_timeout'} : 6000;
+
+sub run() {
+  logm("Running: /root/unixbench/Run $args (timeout: $timeout)");
+  target_cmd_root($gho, <<END, $timeout);
+      set -ex
+      cd /root/unixbench/
+      rm -rf results/*
+      time ./Run $args
+END
+}
+
+sub hwinfo() {
+  # Collect some info about the target (virtual) hardware,
+  # in case we need them when looking and analyzing results.
+  #
+  # 'root' because there is no 'osstest' user in guests.
+  target_catfile_root_stash($gho, "/proc/cpuinfo");
+  target_catfile_root_stash($gho, "/proc/meminfo");
+}
+
+hwinfo();
+run();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylhz-0005RG-Ff; Wed, 10 Dec 2014 18:09:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylhy-0005Q5-9R
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:09:54 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	AA/49-25714-17C88845; Wed, 10 Dec 2014 18:09:53 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418234992!5067812!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2030 invoked from network); 10 Dec 2014 18:09:52 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:09:52 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so12110185wiv.11
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:09:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=27TzyEq4e20HyBdEnyCA1vRBEGQXALZqAZsSO1CNrWA=;
	b=KkQ8lNcGTu2K+Roy/ioWKl2XdUPdvUG744VpOS79z12/mofctpjZ9L2QHNfWL0cgjz
	eE4Z7sZwqZgdoIOsh4gEsQJdCv1Rr3P0Dbtznhv+/d5da4/J33qYpMgIzQ/cF3AGG9Wf
	VZb0OU38V1rMrR6aghK15Gb8xLIl53TTyx36ewDtwcnxqT6Qs+CeoFQvcwSOllivg8yy
	pqy8axVIWUMkt229XPP4in19/d7gX9uafWp+L/GBmzGXc6QS52717FSkD24+ozB+usXb
	t0WFgFBvU7g5uZzJ6kAFNUvJHW3A5U/d/02ri13fabvXprdM2QfI0BXjLjq8p+z5b8yu
	B5AQ==
X-Received: by 10.180.228.37 with SMTP id sf5mr15561730wic.35.1418234992742;
	Wed, 10 Dec 2014 10:09:52 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id td6sm7282719wic.15.2014.12.10.10.09.51
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:09:52 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:50 +0100
Message-ID: <20141210180950.26400.14357.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07/27] ts-unixbench-run: kick off the benchmark
	on the 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

There is a runvar called 'unixbench_params', for specifying
the benchmark's runtime arguments.

The commit also adds a couple of generic functions in
TestSupport.pm, for `cat'-ing the content of a file on
the target into a corresponding file in the stash area.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
Changes from RFCv1:
 * add default value for runtime arguments.
---
 Osstest/TestSupport.pm |   23 ++++++++++++++++
 ts-unixbench-run       |   67 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+)
 create mode 100755 ts-unixbench-run

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 67befd0..7cc5be6 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -57,6 +57,7 @@ BEGIN {
                       target_getfile_stash target_getfile_root_stash
                       target_put_guest_image target_editfile
                       target_editfile_root target_file_exists
+                      target_catfile_stash target_catfile_root_stash
                       target_run_apt
                       target_install_packages target_install_packages_norec
                       target_jobdir target_extract_jobdistpath_subdir
@@ -488,6 +489,28 @@ sub target_getfile_root_stash ($$$;$) {
     tgfs_core(\&target_getfile_root, @_);
 }
 
+sub tcfs_core {
+  my ($tcmdoutf,$ho,$rfile)= @_;
+  my $lleaf;
+
+  target_somefile_getleaf(\$lleaf,$rfile,$ho);
+
+  my $h= new IO::File "$stash/$lleaf", 'w' or die $!;
+  my $fdata= $tcmdoutf->($ho, "cat $rfile");
+  print $h $fdata or die $!;
+  close $h or die $!;
+}
+
+sub target_catfile_stash ($$) {
+  my ($ho,$rfile)= @_;
+  tcfs_core(\&target_cmd_output,@_);
+}
+
+sub target_catfile_root_stash ($$) {
+  my ($ho,$rfile)= @_;
+  tcfs_core(\&target_cmd_output_root,@_);
+}
+
 sub target_file_exists ($$) {
     my ($ho,$rfile) = @_;
     my $out= target_cmd_output($ho, "if test -e $rfile; then echo y; fi");
diff --git a/ts-unixbench-run b/ts-unixbench-run
new file mode 100755
index 0000000..47e6964
--- /dev/null
+++ b/ts-unixbench-run
@@ -0,0 +1,67 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+# what we expect as argument list is:
+#  host=<somehost> [<someguest>]
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+our $gho= $ho;
+if (defined $gn and $gn ne "") {
+  $gho= selectguest($gn, $ho);
+  my $err= guest_check_ip($gho);
+  die "$err $gho->{Name}" if defined $err;
+}
+
+# Runtime parameters for the benchmark. We expect them to be
+# specified via a runvar. If not, let's provide a safe default.
+if (!defined($r{ 'unixbench_params' })) {
+  store_runvar('unixbench_params',"-i 3");
+}
+our $args= $r{'unixbench_params'};
+our $timeout= (defined($r{'unixbench_timeout'})) ?
+      $r{'unixbench_timeout'} : 6000;
+
+sub run() {
+  logm("Running: /root/unixbench/Run $args (timeout: $timeout)");
+  target_cmd_root($gho, <<END, $timeout);
+      set -ex
+      cd /root/unixbench/
+      rm -rf results/*
+      time ./Run $args
+END
+}
+
+sub hwinfo() {
+  # Collect some info about the target (virtual) hardware,
+  # in case we need them when looking and analyzing results.
+  #
+  # 'root' because there is no 'osstest' user in guests.
+  target_catfile_root_stash($gho, "/proc/cpuinfo");
+  target_catfile_root_stash($gho, "/proc/meminfo");
+}
+
+hwinfo();
+run();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:10:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyli7-0005X3-V3; Wed, 10 Dec 2014 18:10:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xyli6-0005Vs-Be
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8A/BD-25276-97C88845; Wed, 10 Dec 2014 18:10:01 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418235001!14775375!1
X-Originating-IP: [74.125.82.42]
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 6546 invoked from network); 10 Dec 2014 18:10:01 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:01 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so4389214wgg.29
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=5YEHkPwCqeZZyuHj88OxABgvkCMBwgGylViZFqMtzBw=;
	b=vjB3L/KTgzmGyr85G3M0nSFLUWKi45+n16DxAY14gDPa3G19Ah8ZdRMtWgYGB7skYA
	L/v8ll6xS1DYVLrHUTVsCbB3TGdCzVpYuEz1rQHHgPEOYhbrsbcBfFfl7ancyDkLJ+/P
	gDbGrp0yGpCT6MwzUsl2ocXRkmaMqa9momZqKT995fzV6E27lRkvUrF/AtQ3oSX9t/Kq
	81Vwko/7V5xB9eNhcvObOUkH3lbr4m8DgbfrC51fMdQe2L7x16JKBcwdwAAj6qPj0OE3
	a31NUyem02rXeSIOQK0q0GRBt3KCdREsDOy3LFmJzC0LfZjvtp9SsCFpejdwLBjzwAz5
	hMqQ==
X-Received: by 10.181.8.98 with SMTP id dj2mr8259596wid.81.1418235001039;
	Wed, 10 Dec 2014 10:10:01 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id r10sm7278539wiy.19.2014.12.10.10.09.58
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:00 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:57 +0100
Message-ID: <20141210180957.26400.66565.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/27] ts-unixbench-reslts: for retrieving the
	results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 store them in $c{Stash}, in a file named according
to the following convention:

 $hostname--$benchname-$benchparams

i.e., something like this:

 debian--unixbench-i3-c2

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
Changes from RFCv1:
 * use target_getfile_root_stash, as suggested during review;
---
 ts-unixbench-reslts |   67 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)
 create mode 100755 ts-unixbench-reslts

diff --git a/ts-unixbench-reslts b/ts-unixbench-reslts
new file mode 100755
index 0000000..6e5a9a8
--- /dev/null
+++ b/ts-unixbench-reslts
@@ -0,0 +1,67 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use Osstest;
+use DBI;
+use IO::File;
+use POSIX;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+# what we expect as argument list is:
+#  host=<somehost> [<someguest>]
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+our $gho= $ho;
+if (defined $gn and $gn ne "") {
+  $gho= selectguest($gn, $ho);
+  my $err= guest_check_ip($gho);
+  die "$err $gho->{Name}" if defined $err;
+}
+
+our $run_id= (defined($r{'unixbench_run_id'})) ?
+      $r{'unixbench_run_id'} : '01';
+
+our $lresfile= $r{'unixbench_params'};
+$lresfile =~ tr/ //ds;
+$lresfile .= (defined($r{'unixbench_run_suffix'})) ?
+      $r{'unixbench_run_suffix'} : '';
+$lresfile = "unixbench$lresfile";
+
+# Unixbench stores results in a subdirectory called 'results'. The file name
+# is made up out of the box's hostname, today's date and a progressive id
+# (e.g., results/benny-2014-07-02-01).
+sub fetch() {
+  my $rresults_dir= "/root/unixbench/results";
+  my $gho_hostname= target_cmd_output_root($gho, 'hostname');
+  my $resultspat= "$rresults_dir/$gho_hostname*-$run_id";
+
+  my $rresfile= target_cmd_output_root($gho, <<END);
+    chmod a+r $resultspat 2>&1 ||:
+    echo $resultspat
+END
+
+  logm("Fetching $rresfile from $gho_hostname");
+  target_getfile_root_stash($gho, 60, "$rresfile",
+      "$lresfile");
+}
+
+fetch();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:10:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyli7-0005X3-V3; Wed, 10 Dec 2014 18:10:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xyli6-0005Vs-Be
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:02 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	8A/BD-25276-97C88845; Wed, 10 Dec 2014 18:10:01 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418235001!14775375!1
X-Originating-IP: [74.125.82.42]
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 6546 invoked from network); 10 Dec 2014 18:10:01 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:01 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so4389214wgg.29
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=5YEHkPwCqeZZyuHj88OxABgvkCMBwgGylViZFqMtzBw=;
	b=vjB3L/KTgzmGyr85G3M0nSFLUWKi45+n16DxAY14gDPa3G19Ah8ZdRMtWgYGB7skYA
	L/v8ll6xS1DYVLrHUTVsCbB3TGdCzVpYuEz1rQHHgPEOYhbrsbcBfFfl7ancyDkLJ+/P
	gDbGrp0yGpCT6MwzUsl2ocXRkmaMqa9momZqKT995fzV6E27lRkvUrF/AtQ3oSX9t/Kq
	81Vwko/7V5xB9eNhcvObOUkH3lbr4m8DgbfrC51fMdQe2L7x16JKBcwdwAAj6qPj0OE3
	a31NUyem02rXeSIOQK0q0GRBt3KCdREsDOy3LFmJzC0LfZjvtp9SsCFpejdwLBjzwAz5
	hMqQ==
X-Received: by 10.181.8.98 with SMTP id dj2mr8259596wid.81.1418235001039;
	Wed, 10 Dec 2014 10:10:01 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id r10sm7278539wiy.19.2014.12.10.10.09.58
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:00 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:09:57 +0100
Message-ID: <20141210180957.26400.66565.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/27] ts-unixbench-reslts: for retrieving the
	results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 store them in $c{Stash}, in a file named according
to the following convention:

 $hostname--$benchname-$benchparams

i.e., something like this:

 debian--unixbench-i3-c2

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
Changes from RFCv1:
 * use target_getfile_root_stash, as suggested during review;
---
 ts-unixbench-reslts |   67 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)
 create mode 100755 ts-unixbench-reslts

diff --git a/ts-unixbench-reslts b/ts-unixbench-reslts
new file mode 100755
index 0000000..6e5a9a8
--- /dev/null
+++ b/ts-unixbench-reslts
@@ -0,0 +1,67 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use Osstest;
+use DBI;
+use IO::File;
+use POSIX;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+# what we expect as argument list is:
+#  host=<somehost> [<someguest>]
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+our $gho= $ho;
+if (defined $gn and $gn ne "") {
+  $gho= selectguest($gn, $ho);
+  my $err= guest_check_ip($gho);
+  die "$err $gho->{Name}" if defined $err;
+}
+
+our $run_id= (defined($r{'unixbench_run_id'})) ?
+      $r{'unixbench_run_id'} : '01';
+
+our $lresfile= $r{'unixbench_params'};
+$lresfile =~ tr/ //ds;
+$lresfile .= (defined($r{'unixbench_run_suffix'})) ?
+      $r{'unixbench_run_suffix'} : '';
+$lresfile = "unixbench$lresfile";
+
+# Unixbench stores results in a subdirectory called 'results'. The file name
+# is made up out of the box's hostname, today's date and a progressive id
+# (e.g., results/benny-2014-07-02-01).
+sub fetch() {
+  my $rresults_dir= "/root/unixbench/results";
+  my $gho_hostname= target_cmd_output_root($gho, 'hostname');
+  my $resultspat= "$rresults_dir/$gho_hostname*-$run_id";
+
+  my $rresfile= target_cmd_output_root($gho, <<END);
+    chmod a+r $resultspat 2>&1 ||:
+    echo $resultspat
+END
+
+  logm("Fetching $rresfile from $gho_hostname");
+  target_getfile_root_stash($gho, 60, "$rresfile",
+      "$lresfile");
+}
+
+fetch();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:10:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XyliR-0005gV-N3; Wed, 10 Dec 2014 18:10:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyliN-0005eW-Lh
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5E/FD-25276-98C88845; Wed, 10 Dec 2014 18:10:17 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418235016!14759673!1
X-Originating-IP: [74.125.82.48]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7394 invoked from network); 10 Dec 2014 18:10:16 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:16 -0000
Received: by mail-wg0-f48.google.com with SMTP id y19so4355411wgg.7
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=rQ8sZO/YRUpfMxYsLfLvCEnH7NzAwFaJIy6gIiniy8Q=;
	b=FOOhsnar1m6hfcX6sX7M9nM/MFG8BXMWQYS0rrTLO+zIhb4+Udm5xJAwVB+HMXGYfU
	GjGyoUHMvx7EMGpA1G7462DZFrW6tGWZWwniIC7n09hnhhFoYZykIrMAvThOEpSUov45
	Dwn6HuGfx/uAC1Z1bZ4lnq8EAmcKAy/HJm3TZ4vrDlEi+k7KhGr0ODR5UUqePt6YIm8/
	J6ushW7+KjTTFZ17M2P3btNIHVQp8D/2sAsqoJJdmxzxApGv9JpuO6/At5HfB7omrhQ8
	czpDE+YNmAA2egpo+meOc+e/VgMj80qm4HDXncC+9RLW9rt4c60l60LpVQbyo5QmmIqY
	A1gA==
X-Received: by 10.180.20.43 with SMTP id k11mr8461052wie.56.1418235009394;
	Wed, 10 Dec 2014 10:10:09 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id 18sm6793181wjr.46.2014.12.10.10.10.07
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:08 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:06 +0100
Message-ID: <20141210181006.26400.25863.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09/27] ts-unixbench-reslts: process and plot
	bench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

Mangle the results of a run of unixbench a bit, so that
they can be plotted. This also produces a (gnu)plot script
and the plot itself. All is saved in $stash, for the
running flight and job.


This is done in a new Osstest/Benchmarking.pm module, as
the functions introduced may turn out useful somewhere else
too.

The results are read from the original unixbench results
file and a new file, with basically a table in it is
produced. Gnuplot uses such file as data for the plotting.

A gnuplot script is produced and invoked (and saved in $stash)
rather than using the gnuplot perl binding because, this way,
one can modify the plotting commands a bit, and regen the
plot(s).

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Benchmarking.pm |  115 +++++++++++++++++++++++++++++++++++++++++++++++
 ts-unixbench-reslts     |   17 +++++++
 2 files changed, 132 insertions(+)
 create mode 100644 Osstest/Benchmarking.pm

diff --git a/Osstest/Benchmarking.pm b/Osstest/Benchmarking.pm
new file mode 100644
index 0000000..0c5c538
--- /dev/null
+++ b/Osstest/Benchmarking.pm
@@ -0,0 +1,115 @@
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 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::Benchmarking;
+
+use strict;
+use warnings;
+
+use IO::File;
+use IPC::Cmd qw[can_run run];
+
+use Osstest;
+use Osstest::TestSupport;
+
+BEGIN {
+    use Exporter ();
+    our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
+    $VERSION     = 1.00;
+    @ISA         = qw(Exporter);
+    @EXPORT      = qw(unixbench_process_results
+                      unixbench_print_results
+                      unixbench_plot_results
+                      );
+    %EXPORT_TAGS = ( );
+
+    @EXPORT_OK   = qw();
+}
+
+#---------- manipulation of benchmarks results ----------
+
+sub unixbench_process_results ($$) {
+  my ($results_ref,$rfilen)= @_;
+  my $h= new IO::File "< $rfilen" or die "$!";
+
+  my $par;
+  while (<$h>) {
+    my ($bench,$val,$idx);
+    if (m/.*running ([0-9]*) parallel.*$/) {
+      $par= $1;
+    }
+    if (m/^(\S[a-zA-z0-9-\(\)\s]*)\s([0-9]+.[0-9]?)\s*([0-9]+.[0-9]?)\s*([0-9]+.[0-9]?)$/) {
+      $val= $3;
+      $idx= $4;
+      ($bench = $1) =~ s/\s+$//;
+      $$results_ref->{"$bench"}{Result}{"$par"}= $val;
+      $$results_ref->{"$bench"}{Index}{"$par"}= $idx;
+    }
+    next;
+  }
+  close($h);
+}
+
+sub unixbench_print_results ($$) {
+  my ($results,$rfilen)= @_;
+  open my $h, "|-", "tee $rfilen" or die "$!";
+
+  printf $h "%-50s","\"BENCHMARK NAME\"";
+  foreach my $i (sort keys $results->{'Double-Precision Whetstone'}{Index}) {
+    printf $h "%-15s","\"$i VCPUs\"";
+  }
+  print $h "\n";
+  foreach my $b (keys $results) {
+    printf $h "%-50s","\"$b\"";
+    foreach my $i (sort keys $results->{"$b"}{Index}) {
+      printf $h "%-15s",$results->{$b}{Index}{$i};
+    }
+    print $h "\n";
+  }
+  close($h);
+}
+
+sub unixbench_plot_results ($$$) {
+  my ($dataf,$num_cols,$pfile)= @_;
+  my $h= new IO::File "> $pfile.gp" or die "$!";
+
+  printf $h <<EOF;
+set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" 8 size 800,600
+set output '$pfile.png'
+set title 'Unixbench INDEXes for $flight.$job'
+set key outside center top horizontal noreverse noenhanced autotitles nobox
+set xtics mirror rotate by -45 out
+set style data histogram
+set style histogram cluster gap 1
+set style fill solid border lt -1
+set boxwidth 1 absolute
+set bmargin 13
+set rmargin 14
+SKIP_COL=1
+NCOL=$num_cols
+HWIDTH=1.0/(NCOL+1.0)
+plot for [c=SKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with histograms title columnhead, \\
+        for [c=SKIP_COL+1:SKIP_COL+NCOL]'' every ::1 using 0:c:c with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1))*HWIDTH, character 2 rotate by 90
+EOF
+  close($h);
+
+  my $gp= can_run('gnuplot') or return;
+  my ($ok,$err)= run( command => "$gp $pfile.gp", verbose => 1 );
+  logm("WARNING: plotting file with \"$err\"") unless $ok;
+}
+
+1;
diff --git a/ts-unixbench-reslts b/ts-unixbench-reslts
index 6e5a9a8..b480d15 100755
--- a/ts-unixbench-reslts
+++ b/ts-unixbench-reslts
@@ -21,6 +21,7 @@ use DBI;
 use IO::File;
 use POSIX;
 use Osstest::TestSupport;
+use Osstest::Benchmarking;
 
 tsreadconfig();
 
@@ -46,6 +47,8 @@ $lresfile .= (defined($r{'unixbench_run_suffix'})) ?
       $r{'unixbench_run_suffix'} : '';
 $lresfile = "unixbench$lresfile";
 
+our $results;
+
 # Unixbench stores results in a subdirectory called 'results'. The file name
 # is made up out of the box's hostname, today's date and a progressive id
 # (e.g., results/benny-2014-07-02-01).
@@ -64,4 +67,18 @@ END
       "$lresfile");
 }
 
+sub process () {
+  my $resf= "$stash/$gho->{Name}--$lresfile";
+  my $dataf= "$resf-DATA";
+  my $plotf= "$resf-PLOT";
+
+  unixbench_process_results(\$results,$resf);
+  unixbench_print_results($results,$dataf);
+
+  # For plotting we need to know the number of data columns
+  my $ncols= keys $results->{'Double-Precision Whetstone'}{Index};
+  unixbench_plot_results($dataf,$ncols,$plotf);
+}
+
 fetch();
+process();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:10:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XyliS-0005gw-6z; Wed, 10 Dec 2014 18:10:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyliR-0005fn-0t
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4D/CF-09842-A8C88845; Wed, 10 Dec 2014 18:10:18 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418235017!14759677!1
X-Originating-IP: [74.125.82.51]
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 7540 invoked from network); 10 Dec 2014 18:10:17 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:17 -0000
Received: by mail-wg0-f51.google.com with SMTP id x12so4367219wgg.10
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=WGkYqbIr6tDRr735NV/S3tdxcBZMR+iuFpHcfnY/x1Y=;
	b=bJ9BlOFu0VidM2wt6A8ksocrnLooYWy2b6+/9oRx8Sa2+g7FMscjMlA6O0pUHoBnUb
	PZEdin4pP9i22x9D60bbeL4BNK44145F+dHBXQlXg+2R816WH08VVmVbltOiGyqMlJY/
	icavRZK5z/rPSqUB8shCDDii02mnmDQptDIbnC7wVpiSgj4OZ+435BkZ37MtGg9M/Oh7
	Obs0y3kljYiVRnR5+RrSRfSBzR+Vsp72Gxez+jzmiieNbDGDfdZK7zWyMI5+R/eSxlI0
	qjlMseZOzc0lAVO5tOCF9nBP8TcSEKFwPEi4jdNyU+qjBv+Gyw11MCesuayuxc2OfGMP
	96YQ==
X-Received: by 10.194.109.6 with SMTP id ho6mr8889039wjb.93.1418235017651;
	Wed, 10 Dec 2014 10:10:17 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103]) by mx.google.com with ESMTPSA id
	ex9sm18879454wib.14.2014.12.10.10.10.16 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:16 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:14 +0100
Message-ID: <20141210181014.26400.89801.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10/27] sg-run-job: recipes for the unixbench jobs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Recipes are defined for prepping and running
the unixbench benchmark on the host and on
Debian PV and HVM guests.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 sg-run-job |   31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/sg-run-job b/sg-run-job
index 2cf810a..81c2040 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -321,6 +321,37 @@ proc run-job/test-rumpuserxen {} {
     run-ts . =   ts-guest-destroy-hard          + host + $g
 }
 
+#-------- benchmarks --------
+
+proc bench-unixbench-run {args} {
+    run-ts . = ts-unixbench-build  + host $args
+    run-ts . = ts-unixbench-run    + host $args
+    run-ts . = ts-unixbench-reslts + host $args
+}
+
+proc bench-unixbench-host {} {
+    bench-unixbench-run
+}
+
+proc bench-unixbench-guest {g} {
+    bench-unixbench-run $g
+    run-ts . = ts-guest-stop + host $g
+}
+
+proc need-hosts/bench-unixbench-pv {} { return host }
+proc run-job/bench-unixbench-pv {} {
+    run-ts . = ts-debian-install + host
+    run-ts . = ts-debian-fixup   + host debian
+    run-ts . = ts-guest-start    + host debian
+    bench-unixbench-guest debian
+}
+
+proc need-hosts/bench-unixbench-hvm {} { return host }
+proc run-job/bench-unixbench-hvm {} {
+    run-ts . = ts-debian-hvm-install
+    bench-unixbench-guest debianhvm
+}
+
 #---------- builds ----------
 
 proc need-hosts/build {} { return BUILD }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:10:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XyliR-0005gV-N3; Wed, 10 Dec 2014 18:10:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyliN-0005eW-Lh
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5E/FD-25276-98C88845; Wed, 10 Dec 2014 18:10:17 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418235016!14759673!1
X-Originating-IP: [74.125.82.48]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7394 invoked from network); 10 Dec 2014 18:10:16 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:16 -0000
Received: by mail-wg0-f48.google.com with SMTP id y19so4355411wgg.7
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=rQ8sZO/YRUpfMxYsLfLvCEnH7NzAwFaJIy6gIiniy8Q=;
	b=FOOhsnar1m6hfcX6sX7M9nM/MFG8BXMWQYS0rrTLO+zIhb4+Udm5xJAwVB+HMXGYfU
	GjGyoUHMvx7EMGpA1G7462DZFrW6tGWZWwniIC7n09hnhhFoYZykIrMAvThOEpSUov45
	Dwn6HuGfx/uAC1Z1bZ4lnq8EAmcKAy/HJm3TZ4vrDlEi+k7KhGr0ODR5UUqePt6YIm8/
	J6ushW7+KjTTFZ17M2P3btNIHVQp8D/2sAsqoJJdmxzxApGv9JpuO6/At5HfB7omrhQ8
	czpDE+YNmAA2egpo+meOc+e/VgMj80qm4HDXncC+9RLW9rt4c60l60LpVQbyo5QmmIqY
	A1gA==
X-Received: by 10.180.20.43 with SMTP id k11mr8461052wie.56.1418235009394;
	Wed, 10 Dec 2014 10:10:09 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id 18sm6793181wjr.46.2014.12.10.10.10.07
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:08 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:06 +0100
Message-ID: <20141210181006.26400.25863.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09/27] ts-unixbench-reslts: process and plot
	bench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

Mangle the results of a run of unixbench a bit, so that
they can be plotted. This also produces a (gnu)plot script
and the plot itself. All is saved in $stash, for the
running flight and job.


This is done in a new Osstest/Benchmarking.pm module, as
the functions introduced may turn out useful somewhere else
too.

The results are read from the original unixbench results
file and a new file, with basically a table in it is
produced. Gnuplot uses such file as data for the plotting.

A gnuplot script is produced and invoked (and saved in $stash)
rather than using the gnuplot perl binding because, this way,
one can modify the plotting commands a bit, and regen the
plot(s).

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Benchmarking.pm |  115 +++++++++++++++++++++++++++++++++++++++++++++++
 ts-unixbench-reslts     |   17 +++++++
 2 files changed, 132 insertions(+)
 create mode 100644 Osstest/Benchmarking.pm

diff --git a/Osstest/Benchmarking.pm b/Osstest/Benchmarking.pm
new file mode 100644
index 0000000..0c5c538
--- /dev/null
+++ b/Osstest/Benchmarking.pm
@@ -0,0 +1,115 @@
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 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::Benchmarking;
+
+use strict;
+use warnings;
+
+use IO::File;
+use IPC::Cmd qw[can_run run];
+
+use Osstest;
+use Osstest::TestSupport;
+
+BEGIN {
+    use Exporter ();
+    our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
+    $VERSION     = 1.00;
+    @ISA         = qw(Exporter);
+    @EXPORT      = qw(unixbench_process_results
+                      unixbench_print_results
+                      unixbench_plot_results
+                      );
+    %EXPORT_TAGS = ( );
+
+    @EXPORT_OK   = qw();
+}
+
+#---------- manipulation of benchmarks results ----------
+
+sub unixbench_process_results ($$) {
+  my ($results_ref,$rfilen)= @_;
+  my $h= new IO::File "< $rfilen" or die "$!";
+
+  my $par;
+  while (<$h>) {
+    my ($bench,$val,$idx);
+    if (m/.*running ([0-9]*) parallel.*$/) {
+      $par= $1;
+    }
+    if (m/^(\S[a-zA-z0-9-\(\)\s]*)\s([0-9]+.[0-9]?)\s*([0-9]+.[0-9]?)\s*([0-9]+.[0-9]?)$/) {
+      $val= $3;
+      $idx= $4;
+      ($bench = $1) =~ s/\s+$//;
+      $$results_ref->{"$bench"}{Result}{"$par"}= $val;
+      $$results_ref->{"$bench"}{Index}{"$par"}= $idx;
+    }
+    next;
+  }
+  close($h);
+}
+
+sub unixbench_print_results ($$) {
+  my ($results,$rfilen)= @_;
+  open my $h, "|-", "tee $rfilen" or die "$!";
+
+  printf $h "%-50s","\"BENCHMARK NAME\"";
+  foreach my $i (sort keys $results->{'Double-Precision Whetstone'}{Index}) {
+    printf $h "%-15s","\"$i VCPUs\"";
+  }
+  print $h "\n";
+  foreach my $b (keys $results) {
+    printf $h "%-50s","\"$b\"";
+    foreach my $i (sort keys $results->{"$b"}{Index}) {
+      printf $h "%-15s",$results->{$b}{Index}{$i};
+    }
+    print $h "\n";
+  }
+  close($h);
+}
+
+sub unixbench_plot_results ($$$) {
+  my ($dataf,$num_cols,$pfile)= @_;
+  my $h= new IO::File "> $pfile.gp" or die "$!";
+
+  printf $h <<EOF;
+set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" 8 size 800,600
+set output '$pfile.png'
+set title 'Unixbench INDEXes for $flight.$job'
+set key outside center top horizontal noreverse noenhanced autotitles nobox
+set xtics mirror rotate by -45 out
+set style data histogram
+set style histogram cluster gap 1
+set style fill solid border lt -1
+set boxwidth 1 absolute
+set bmargin 13
+set rmargin 14
+SKIP_COL=1
+NCOL=$num_cols
+HWIDTH=1.0/(NCOL+1.0)
+plot for [c=SKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with histograms title columnhead, \\
+        for [c=SKIP_COL+1:SKIP_COL+NCOL]'' every ::1 using 0:c:c with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1))*HWIDTH, character 2 rotate by 90
+EOF
+  close($h);
+
+  my $gp= can_run('gnuplot') or return;
+  my ($ok,$err)= run( command => "$gp $pfile.gp", verbose => 1 );
+  logm("WARNING: plotting file with \"$err\"") unless $ok;
+}
+
+1;
diff --git a/ts-unixbench-reslts b/ts-unixbench-reslts
index 6e5a9a8..b480d15 100755
--- a/ts-unixbench-reslts
+++ b/ts-unixbench-reslts
@@ -21,6 +21,7 @@ use DBI;
 use IO::File;
 use POSIX;
 use Osstest::TestSupport;
+use Osstest::Benchmarking;
 
 tsreadconfig();
 
@@ -46,6 +47,8 @@ $lresfile .= (defined($r{'unixbench_run_suffix'})) ?
       $r{'unixbench_run_suffix'} : '';
 $lresfile = "unixbench$lresfile";
 
+our $results;
+
 # Unixbench stores results in a subdirectory called 'results'. The file name
 # is made up out of the box's hostname, today's date and a progressive id
 # (e.g., results/benny-2014-07-02-01).
@@ -64,4 +67,18 @@ END
       "$lresfile");
 }
 
+sub process () {
+  my $resf= "$stash/$gho->{Name}--$lresfile";
+  my $dataf= "$resf-DATA";
+  my $plotf= "$resf-PLOT";
+
+  unixbench_process_results(\$results,$resf);
+  unixbench_print_results($results,$dataf);
+
+  # For plotting we need to know the number of data columns
+  my $ncols= keys $results->{'Double-Precision Whetstone'}{Index};
+  unixbench_plot_results($dataf,$ncols,$plotf);
+}
+
 fetch();
+process();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:10:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XyliS-0005gw-6z; Wed, 10 Dec 2014 18:10:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyliR-0005fn-0t
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4D/CF-09842-A8C88845; Wed, 10 Dec 2014 18:10:18 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418235017!14759677!1
X-Originating-IP: [74.125.82.51]
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 7540 invoked from network); 10 Dec 2014 18:10:17 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:17 -0000
Received: by mail-wg0-f51.google.com with SMTP id x12so4367219wgg.10
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=WGkYqbIr6tDRr735NV/S3tdxcBZMR+iuFpHcfnY/x1Y=;
	b=bJ9BlOFu0VidM2wt6A8ksocrnLooYWy2b6+/9oRx8Sa2+g7FMscjMlA6O0pUHoBnUb
	PZEdin4pP9i22x9D60bbeL4BNK44145F+dHBXQlXg+2R816WH08VVmVbltOiGyqMlJY/
	icavRZK5z/rPSqUB8shCDDii02mnmDQptDIbnC7wVpiSgj4OZ+435BkZ37MtGg9M/Oh7
	Obs0y3kljYiVRnR5+RrSRfSBzR+Vsp72Gxez+jzmiieNbDGDfdZK7zWyMI5+R/eSxlI0
	qjlMseZOzc0lAVO5tOCF9nBP8TcSEKFwPEi4jdNyU+qjBv+Gyw11MCesuayuxc2OfGMP
	96YQ==
X-Received: by 10.194.109.6 with SMTP id ho6mr8889039wjb.93.1418235017651;
	Wed, 10 Dec 2014 10:10:17 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103]) by mx.google.com with ESMTPSA id
	ex9sm18879454wib.14.2014.12.10.10.10.16 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:16 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:14 +0100
Message-ID: <20141210181014.26400.89801.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10/27] sg-run-job: recipes for the unixbench jobs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Recipes are defined for prepping and running
the unixbench benchmark on the host and on
Debian PV and HVM guests.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 sg-run-job |   31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/sg-run-job b/sg-run-job
index 2cf810a..81c2040 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -321,6 +321,37 @@ proc run-job/test-rumpuserxen {} {
     run-ts . =   ts-guest-destroy-hard          + host + $g
 }
 
+#-------- benchmarks --------
+
+proc bench-unixbench-run {args} {
+    run-ts . = ts-unixbench-build  + host $args
+    run-ts . = ts-unixbench-run    + host $args
+    run-ts . = ts-unixbench-reslts + host $args
+}
+
+proc bench-unixbench-host {} {
+    bench-unixbench-run
+}
+
+proc bench-unixbench-guest {g} {
+    bench-unixbench-run $g
+    run-ts . = ts-guest-stop + host $g
+}
+
+proc need-hosts/bench-unixbench-pv {} { return host }
+proc run-job/bench-unixbench-pv {} {
+    run-ts . = ts-debian-install + host
+    run-ts . = ts-debian-fixup   + host debian
+    run-ts . = ts-guest-start    + host debian
+    bench-unixbench-guest debian
+}
+
+proc need-hosts/bench-unixbench-hvm {} { return host }
+proc run-job/bench-unixbench-hvm {} {
+    run-ts . = ts-debian-hvm-install
+    bench-unixbench-guest debianhvm
+}
+
 #---------- builds ----------
 
 proc need-hosts/build {} { return BUILD }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:10:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XyliX-0005lE-O5; Wed, 10 Dec 2014 18:10:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyliV-0005jT-PW
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:27 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	2F/EB-02957-39C88845; Wed, 10 Dec 2014 18:10:27 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418235026!14265588!1
X-Originating-IP: [209.85.212.180]
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 29964 invoked from network); 10 Dec 2014 18:10:26 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:26 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so6100511wiv.1
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=fRDh5K9vvAlSLBrze60IJmUlh9Nb1x3HfDjurpCb8n0=;
	b=VcBwyE2ZFd3UZSX2qK8Xo4NJlnsaDuq15d//qToouP4ypiPWDelQd4YQQ/jXC0LW14
	V/7CLdIMcJM/gxqfVcUnzcAFoJUPlUUPYYZpF52wiPf99USyrOb0boiLZzJfn4DXl2/h
	BYKHCoehXQ/cbeDJaAqLGjV/fSBWMfA9d8+dCZJma7GyO+JaOVh8reJgexYSrugwwzI9
	F9OLLGI50YeAlOow2CTB5lVZzNOGQRURGACDesCQiIBdfNy776+O2wvP9+JEUKHgTkyH
	nRFtIlplAYeK6fW4G3jl7lGuG94IEEK9b0Wc882pncqyM3qwGwKKwjqO5DUa5Fyb2j2g
	/muA==
X-Received: by 10.180.8.70 with SMTP id p6mr8690828wia.72.1418235026049;
	Wed, 10 Dec 2014 10:10:26 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id kv6sm6825518wjb.9.2014.12.10.10.10.24
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:25 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:22 +0100
Message-ID: <20141210181022.26400.52391.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 11/27] make-bench-flight: to create a
	benchmarking flight
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 all done in a new script, to keep these jobs
separated from regular testing jobs defined by make-flight.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 README            |   10 +++++
 make-bench-flight |  100 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 110 insertions(+)
 create mode 100755 make-bench-flight

diff --git a/README b/README
index 3fe5ecc..45d1498 100644
--- a/README
+++ b/README
@@ -190,6 +190,16 @@ test-$XENARCH-$DOM0ARCH-<CASE>
         Some tests also have a -$DOMUARCH suffix indicating the
         obvious thing.
 
+bench-$BENCHNAME-$ARCH-<XEN_OPTS>-<GUEST_OPTS>
+
+        A benchmarking job, running benchmark $BENCHNAME on a $ARCH
+        hypervisor and dom0 (and guest).
+
+        In the remainder of the job's name, <XEN_OPTS> tells something
+        about Xen's configuration (e.g., what scheduler will be used);
+        <GUEST_OPTS> tells about the guest's configuration (e.g., whether
+        it's HVM or PV, number of vCPUs, RAM, etc.).
+
 NB: $ARCH (and $XENARCH etc) are Debian arch names, i386, amd64, armhf.
 
 Standalone Mode
diff --git a/make-bench-flight b/make-bench-flight
new file mode 100755
index 0000000..cdb22ff
--- /dev/null
+++ b/make-bench-flight
@@ -0,0 +1,100 @@
+#!/bin/bash
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+
+set -e
+
+branch=$1
+xenbranch=$2
+blessing=$3
+buildflight=$4
+
+flight=`./cs-flight-create $blessing $branch`
+
+. ap-common
+. cri-common
+. mfi-common
+
+defsuite=`getconfig DebianSuite`
+defguestsuite=`getconfig GuestDebianSuite`
+
+if [ x$buildflight = x ]; then
+
+  if [ "x$BUILD_LVEXTEND_MAX" != x ]; then
+     BUILD_RUNVARS+=" build_lvextend_max=$BUILD_LVEXTEND_MAX "
+  fi
+
+  create_build_jobs
+
+else
+
+  bfi=$buildflight.
+
+fi
+
+job_create_test_filter_callback () {
+    :
+}
+
+test_matrix_branch_filter_callback () {
+    :
+}
+
+do_unixbench_tests () {
+  gvcpus=$1
+  gmem=$2
+
+  # x86_64 only (for now)
+  if [ $xenarch != amd64 ]; then
+    return
+  fi
+  # "homogeneous" tests only (for now)
+  if [ $xenarch != $dom0arch ]; then
+    return
+  fi
+
+  gvcpus_runvars=guests_vcpus=$gvcpus; gvcpus_suffix=-${gvcpus}vcpus
+  gmem_runvars=guests_memory=$gmem; gmem_suffix=-${gmem}ram
+  if [ $gvcpus -ge 2 ];then params="-c $(($gvcpus/2))"; fi
+  params="$params -c $gvcpus -c $(($gvcpus*2)) -i 6"
+
+  for gt in pv hvm; do
+    for sched in credit credit2; do
+      job_create_test \
+              bench-unixbench-$xenarch-$sched-$gt$gvcpus_suffix$gmem_suffix \
+              bench-unixbench-$gt xl $xenarch $dom0arch $gvcpus_runvars $gmem_runvars \
+              xen_boot_append="sched=$sched" unixbench_params="$params" $debian_runvars \
+              bios=seabios debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
+              all_hostflags=$most_hostflags
+    done
+  done
+}
+
+test_matrix_do_one () {
+  do_unixbench_tests 4 4096 # 4 vcpus, 4GB RAM
+}
+
+test_matrix_iterate
+
+echo $flight
+
+# Local variables:
+# mode: sh
+# sh-basic-offset: 2
+# indent-tabs-mode: nil
+# End:


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:10:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XyliX-0005lE-O5; Wed, 10 Dec 2014 18:10:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyliV-0005jT-PW
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:27 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	2F/EB-02957-39C88845; Wed, 10 Dec 2014 18:10:27 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418235026!14265588!1
X-Originating-IP: [209.85.212.180]
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 29964 invoked from network); 10 Dec 2014 18:10:26 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:26 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so6100511wiv.1
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=fRDh5K9vvAlSLBrze60IJmUlh9Nb1x3HfDjurpCb8n0=;
	b=VcBwyE2ZFd3UZSX2qK8Xo4NJlnsaDuq15d//qToouP4ypiPWDelQd4YQQ/jXC0LW14
	V/7CLdIMcJM/gxqfVcUnzcAFoJUPlUUPYYZpF52wiPf99USyrOb0boiLZzJfn4DXl2/h
	BYKHCoehXQ/cbeDJaAqLGjV/fSBWMfA9d8+dCZJma7GyO+JaOVh8reJgexYSrugwwzI9
	F9OLLGI50YeAlOow2CTB5lVZzNOGQRURGACDesCQiIBdfNy776+O2wvP9+JEUKHgTkyH
	nRFtIlplAYeK6fW4G3jl7lGuG94IEEK9b0Wc882pncqyM3qwGwKKwjqO5DUa5Fyb2j2g
	/muA==
X-Received: by 10.180.8.70 with SMTP id p6mr8690828wia.72.1418235026049;
	Wed, 10 Dec 2014 10:10:26 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id kv6sm6825518wjb.9.2014.12.10.10.10.24
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:25 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:22 +0100
Message-ID: <20141210181022.26400.52391.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 11/27] make-bench-flight: to create a
	benchmarking flight
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 all done in a new script, to keep these jobs
separated from regular testing jobs defined by make-flight.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 README            |   10 +++++
 make-bench-flight |  100 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 110 insertions(+)
 create mode 100755 make-bench-flight

diff --git a/README b/README
index 3fe5ecc..45d1498 100644
--- a/README
+++ b/README
@@ -190,6 +190,16 @@ test-$XENARCH-$DOM0ARCH-<CASE>
         Some tests also have a -$DOMUARCH suffix indicating the
         obvious thing.
 
+bench-$BENCHNAME-$ARCH-<XEN_OPTS>-<GUEST_OPTS>
+
+        A benchmarking job, running benchmark $BENCHNAME on a $ARCH
+        hypervisor and dom0 (and guest).
+
+        In the remainder of the job's name, <XEN_OPTS> tells something
+        about Xen's configuration (e.g., what scheduler will be used);
+        <GUEST_OPTS> tells about the guest's configuration (e.g., whether
+        it's HVM or PV, number of vCPUs, RAM, etc.).
+
 NB: $ARCH (and $XENARCH etc) are Debian arch names, i386, amd64, armhf.
 
 Standalone Mode
diff --git a/make-bench-flight b/make-bench-flight
new file mode 100755
index 0000000..cdb22ff
--- /dev/null
+++ b/make-bench-flight
@@ -0,0 +1,100 @@
+#!/bin/bash
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+
+set -e
+
+branch=$1
+xenbranch=$2
+blessing=$3
+buildflight=$4
+
+flight=`./cs-flight-create $blessing $branch`
+
+. ap-common
+. cri-common
+. mfi-common
+
+defsuite=`getconfig DebianSuite`
+defguestsuite=`getconfig GuestDebianSuite`
+
+if [ x$buildflight = x ]; then
+
+  if [ "x$BUILD_LVEXTEND_MAX" != x ]; then
+     BUILD_RUNVARS+=" build_lvextend_max=$BUILD_LVEXTEND_MAX "
+  fi
+
+  create_build_jobs
+
+else
+
+  bfi=$buildflight.
+
+fi
+
+job_create_test_filter_callback () {
+    :
+}
+
+test_matrix_branch_filter_callback () {
+    :
+}
+
+do_unixbench_tests () {
+  gvcpus=$1
+  gmem=$2
+
+  # x86_64 only (for now)
+  if [ $xenarch != amd64 ]; then
+    return
+  fi
+  # "homogeneous" tests only (for now)
+  if [ $xenarch != $dom0arch ]; then
+    return
+  fi
+
+  gvcpus_runvars=guests_vcpus=$gvcpus; gvcpus_suffix=-${gvcpus}vcpus
+  gmem_runvars=guests_memory=$gmem; gmem_suffix=-${gmem}ram
+  if [ $gvcpus -ge 2 ];then params="-c $(($gvcpus/2))"; fi
+  params="$params -c $gvcpus -c $(($gvcpus*2)) -i 6"
+
+  for gt in pv hvm; do
+    for sched in credit credit2; do
+      job_create_test \
+              bench-unixbench-$xenarch-$sched-$gt$gvcpus_suffix$gmem_suffix \
+              bench-unixbench-$gt xl $xenarch $dom0arch $gvcpus_runvars $gmem_runvars \
+              xen_boot_append="sched=$sched" unixbench_params="$params" $debian_runvars \
+              bios=seabios debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
+              all_hostflags=$most_hostflags
+    done
+  done
+}
+
+test_matrix_do_one () {
+  do_unixbench_tests 4 4096 # 4 vcpus, 4GB RAM
+}
+
+test_matrix_iterate
+
+echo $flight
+
+# Local variables:
+# mode: sh
+# sh-basic-offset: 2
+# indent-tabs-mode: nil
+# End:


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:10:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1Xylif-0005qy-5J; Wed, 10 Dec 2014 18:10:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylie-0005pv-1T
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	35/10-09842-B9C88845; Wed, 10 Dec 2014 18:10:35 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418235034!14748393!1
X-Originating-IP: [74.125.82.50]
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 4573 invoked from network); 10 Dec 2014 18:10:34 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:34 -0000
Received: by mail-wg0-f50.google.com with SMTP id a1so4339066wgh.23
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=ib/Diy+q98FxVVxZqNQyb4pOhYHEBstgl+mmegsJDak=;
	b=0vT08mTKuCOGgmIWa2u0Zy8YnzQu+nuWpRf+ydl5GJHUFBRVx7m/RhLmpVdtbDHDgT
	91Y5hU7mPYcjF7sUFOBMsCoUOj8TlQHA4YLtRcttRbf23q/nKCdmTWxTeTbXFigjVK2u
	zLMkFMHNzSAe+lSEur/PzrcVAsid2ne9vgYP85Zv3zloV0CSfQFKPSms4gOOa+HPpw0y
	SkI7WItOA5iIGfQEJ+4XzRPvE8JvNoLbvLTfGwt/taOvyYZzgTmLYlpAIOeeK6UDKKG4
	uLpZegZOWvapXXzj1BNt9k5EUh0hf7fbLAFFB/1okZ4mXrny580OZP5nenoHzbAalovn
	NybQ==
X-Received: by 10.194.121.167 with SMTP id ll7mr8810259wjb.26.1418235034582;
	Wed, 10 Dec 2014 10:10:34 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id b10sm7292414wiw.9.2014.12.10.10.10.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:33 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:31 +0100
Message-ID: <20141210181031.26400.51275.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 12/27] standalone-reset: introduce a new -t
	option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

for making it possible to call the new make-bench-flight
script, and generating the benchmarking jobs. It can be
combined with the existing '-f' option, to create a
benchmarking flight containing all the benchmarking jobs.

This is generic, so, when passing '-t sometype', a script
called make-sometype-flight is what will be invoked.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
Changes from RFCv1:
 * this into "standalone make-flight" too, as requested
   during review.
---
 cr-daily-branch  |    3 ++-
 standalone       |    7 +++++--
 standalone-reset |    9 ++++++---
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/cr-daily-branch b/cr-daily-branch
index 17bb2c9..521682a 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -22,6 +22,7 @@ set -ex
 . cri-args-hostlists
 . ap-common
 branch=$1; shift
+ftype=$1; shift
 select_branch
 info_linux_tree $branch ||:
 
@@ -231,7 +232,7 @@ if [ "x$NEW_REVISION" = "x$OLD_REVISION" ]; then
 fi
 
 $DAILY_BRANCH_PREMAKE_HOOK
-flight=`./make-flight $branch $xenbranch $OSSTEST_BLESSING "$@"`
+flight=`./make-$ftype-flight $branch $xenbranch $OSSTEST_BLESSING "$@"`
 $DAILY_BRANCH_POSTMAKE_HOOK
 
 heading=tmp/$flight.heading-info
diff --git a/standalone b/standalone
index caf3fd5..22540c1 100755
--- a/standalone
+++ b/standalone
@@ -39,6 +39,7 @@ Options:
 
 -c FILE, --config=FILE        Use FILE as configuration file
 -f FLIGHT, --flight=FLIGHT    Operate on FLIGHT
+-t FL_TYPE, --type=FL_TYPE    Flight type (for invoking make-<FL_TYPE>-flight)
 -h HOST, --host=HOST          Test host
 -r, --reuse                   Do not wipe test host (default)
 -R, --noreuse, --noreinstall  Wipe the test host (if job or test does so)
@@ -63,12 +64,13 @@ if [ x$op = x--help ] ; then
     exit 0
 fi
 
-TEMP=$(getopt -o c:f:h:rR --long config:,flight:,host:,reuse,noreuse,reinstall,lvextendmax:,baseline,help -- "$@")
+TEMP=$(getopt -o c:f:t:h:rR --long config:,flight:,ftype:,host:,reuse,noreuse,reinstall,lvextendmax:,baseline,help -- "$@")
 
 eval set -- "$TEMP"
 
 config=${OSSTEST_CONFIG-$HOME/.xen-osstest/config}
 flight="standalone"
+ftype=
 host=
 reuse=1 # Don't blow away machines by default
 lvextendmax=50 # Leave some LVM space free for running tests
@@ -78,6 +80,7 @@ while true ; do
     case "$1" in
 	-c|--config) config=$2; shift 2;;
 	-f|--flight) flight=$2; shift 2;;
+	-t|--type)   ftype=$2;  shift 2;;
 	-h|--host)   host=$2;   shift 2;;
 	-r|--reuse)  reuse=1;   shift 1;;
 	-R|--noreuse|--reinstall)reuse=0;shift 1;;
@@ -184,7 +187,7 @@ case $op in
         OSSTEST_FLIGHT=$flight \
         OSSTEST_CONFIG=$config \
         OSSTEST_NO_BASELINE=$nobaseline \
-            with_logging logs/$flight/make-flight.log ./cr-daily-branch $@ $branch
+            with_logging logs/$flight/make-flight.log ./cr-daily-branch $@ $branch $ftype
         ;;
 
     set-paths)
diff --git a/standalone-reset b/standalone-reset
index 8555039..f041e6d 100755
--- a/standalone-reset
+++ b/standalone-reset
@@ -23,14 +23,17 @@ usage(){
 usage: ./standalone-reset [<options>] [<branch> [<xenbranch> [<buildflight>]]]
  branch and xenbranch default, separately, to xen-unstable
 options:
- -f<flight>     generate flight "flight", default is "standalone"
+ -f <flight>      generate flight "flight", default is "standalone"
+ -t <flight_type> generate a different type of flight (it calls
+                  make-<flight_type>-flight)
 END
 }
 
 flight="standalone"
-while getopts "f:" opt; do
+while getopts "f:t:" opt; do
     case "$opt" in
         f) flight=${OPTARG};;
+        t) flight_type="-${OPTARG}";;
         *) usage; exit 1;;
     esac
 done
@@ -140,7 +143,7 @@ fi
 export BUILD_LVEXTEND_MAX
 
 OSSTEST_FLIGHT=$flight \
-./make-flight "$branch" "$xenbranch" play $buildflight >/dev/null
+./make${flight_type}-flight "$branch" "$xenbranch" play $buildflight >/dev/null
 
 #---------- done ----------
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:10:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1Xylif-0005qy-5J; Wed, 10 Dec 2014 18:10:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylie-0005pv-1T
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	35/10-09842-B9C88845; Wed, 10 Dec 2014 18:10:35 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418235034!14748393!1
X-Originating-IP: [74.125.82.50]
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 4573 invoked from network); 10 Dec 2014 18:10:34 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:34 -0000
Received: by mail-wg0-f50.google.com with SMTP id a1so4339066wgh.23
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=ib/Diy+q98FxVVxZqNQyb4pOhYHEBstgl+mmegsJDak=;
	b=0vT08mTKuCOGgmIWa2u0Zy8YnzQu+nuWpRf+ydl5GJHUFBRVx7m/RhLmpVdtbDHDgT
	91Y5hU7mPYcjF7sUFOBMsCoUOj8TlQHA4YLtRcttRbf23q/nKCdmTWxTeTbXFigjVK2u
	zLMkFMHNzSAe+lSEur/PzrcVAsid2ne9vgYP85Zv3zloV0CSfQFKPSms4gOOa+HPpw0y
	SkI7WItOA5iIGfQEJ+4XzRPvE8JvNoLbvLTfGwt/taOvyYZzgTmLYlpAIOeeK6UDKKG4
	uLpZegZOWvapXXzj1BNt9k5EUh0hf7fbLAFFB/1okZ4mXrny580OZP5nenoHzbAalovn
	NybQ==
X-Received: by 10.194.121.167 with SMTP id ll7mr8810259wjb.26.1418235034582;
	Wed, 10 Dec 2014 10:10:34 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id b10sm7292414wiw.9.2014.12.10.10.10.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:33 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:31 +0100
Message-ID: <20141210181031.26400.51275.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 12/27] standalone-reset: introduce a new -t
	option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

for making it possible to call the new make-bench-flight
script, and generating the benchmarking jobs. It can be
combined with the existing '-f' option, to create a
benchmarking flight containing all the benchmarking jobs.

This is generic, so, when passing '-t sometype', a script
called make-sometype-flight is what will be invoked.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
Changes from RFCv1:
 * this into "standalone make-flight" too, as requested
   during review.
---
 cr-daily-branch  |    3 ++-
 standalone       |    7 +++++--
 standalone-reset |    9 ++++++---
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/cr-daily-branch b/cr-daily-branch
index 17bb2c9..521682a 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -22,6 +22,7 @@ set -ex
 . cri-args-hostlists
 . ap-common
 branch=$1; shift
+ftype=$1; shift
 select_branch
 info_linux_tree $branch ||:
 
@@ -231,7 +232,7 @@ if [ "x$NEW_REVISION" = "x$OLD_REVISION" ]; then
 fi
 
 $DAILY_BRANCH_PREMAKE_HOOK
-flight=`./make-flight $branch $xenbranch $OSSTEST_BLESSING "$@"`
+flight=`./make-$ftype-flight $branch $xenbranch $OSSTEST_BLESSING "$@"`
 $DAILY_BRANCH_POSTMAKE_HOOK
 
 heading=tmp/$flight.heading-info
diff --git a/standalone b/standalone
index caf3fd5..22540c1 100755
--- a/standalone
+++ b/standalone
@@ -39,6 +39,7 @@ Options:
 
 -c FILE, --config=FILE        Use FILE as configuration file
 -f FLIGHT, --flight=FLIGHT    Operate on FLIGHT
+-t FL_TYPE, --type=FL_TYPE    Flight type (for invoking make-<FL_TYPE>-flight)
 -h HOST, --host=HOST          Test host
 -r, --reuse                   Do not wipe test host (default)
 -R, --noreuse, --noreinstall  Wipe the test host (if job or test does so)
@@ -63,12 +64,13 @@ if [ x$op = x--help ] ; then
     exit 0
 fi
 
-TEMP=$(getopt -o c:f:h:rR --long config:,flight:,host:,reuse,noreuse,reinstall,lvextendmax:,baseline,help -- "$@")
+TEMP=$(getopt -o c:f:t:h:rR --long config:,flight:,ftype:,host:,reuse,noreuse,reinstall,lvextendmax:,baseline,help -- "$@")
 
 eval set -- "$TEMP"
 
 config=${OSSTEST_CONFIG-$HOME/.xen-osstest/config}
 flight="standalone"
+ftype=
 host=
 reuse=1 # Don't blow away machines by default
 lvextendmax=50 # Leave some LVM space free for running tests
@@ -78,6 +80,7 @@ while true ; do
     case "$1" in
 	-c|--config) config=$2; shift 2;;
 	-f|--flight) flight=$2; shift 2;;
+	-t|--type)   ftype=$2;  shift 2;;
 	-h|--host)   host=$2;   shift 2;;
 	-r|--reuse)  reuse=1;   shift 1;;
 	-R|--noreuse|--reinstall)reuse=0;shift 1;;
@@ -184,7 +187,7 @@ case $op in
         OSSTEST_FLIGHT=$flight \
         OSSTEST_CONFIG=$config \
         OSSTEST_NO_BASELINE=$nobaseline \
-            with_logging logs/$flight/make-flight.log ./cr-daily-branch $@ $branch
+            with_logging logs/$flight/make-flight.log ./cr-daily-branch $@ $branch $ftype
         ;;
 
     set-paths)
diff --git a/standalone-reset b/standalone-reset
index 8555039..f041e6d 100755
--- a/standalone-reset
+++ b/standalone-reset
@@ -23,14 +23,17 @@ usage(){
 usage: ./standalone-reset [<options>] [<branch> [<xenbranch> [<buildflight>]]]
  branch and xenbranch default, separately, to xen-unstable
 options:
- -f<flight>     generate flight "flight", default is "standalone"
+ -f <flight>      generate flight "flight", default is "standalone"
+ -t <flight_type> generate a different type of flight (it calls
+                  make-<flight_type>-flight)
 END
 }
 
 flight="standalone"
-while getopts "f:" opt; do
+while getopts "f:t:" opt; do
     case "$opt" in
         f) flight=${OPTARG};;
+        t) flight_type="-${OPTARG}";;
         *) usage; exit 1;;
     esac
 done
@@ -140,7 +143,7 @@ fi
 export BUILD_LVEXTEND_MAX
 
 OSSTEST_FLIGHT=$flight \
-./make-flight "$branch" "$xenbranch" play $buildflight >/dev/null
+./make${flight_type}-flight "$branch" "$xenbranch" play $buildflight >/dev/null
 
 #---------- done ----------
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:10:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylio-0005y0-IP; Wed, 10 Dec 2014 18:10:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylim-0005wZ-VD
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:45 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A4/96-17735-4AC88845; Wed, 10 Dec 2014 18:10:44 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418235043!12455424!1
X-Originating-IP: [74.125.82.44]
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 26072 invoked from network); 10 Dec 2014 18:10:43 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:43 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so4355840wgh.3
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=V7dga9fufv2dDSuKMp6zy8L7YMcHW01UgWqfNKN5MBA=;
	b=QzSTYrIi6qoJ6xxDp79qdTPAequohb5wD29xngvpD1JUth7nse8kWedSK/5K8pM2uw
	3faVJj6SDsklHjTDTcxxTZeaEA2vpCUYrKTkZ+cKzLHYTgnU/wnGK7w701hDyBEte96Q
	PEwR6dys2Jy/vgVg2lRmlL3zyWBxOCfFYLGvr1JRY80AuvqpBRPdhu6gPdHijMIEBm7F
	l8CixCCeXgJeERscnwL/441SC4c4ByjLZ3RZkDQWLY4lfq442Hy7votNZrnmw01r9GwO
	r5fzDDVSCAscUU1F+aoAmEd5rku1qJTtv4h+c0ND4yMYNyx/W6+doeMhqw2oyx0i/TyT
	aijg==
X-Received: by 10.180.90.165 with SMTP id bx5mr8618530wib.15.1418235042918;
	Wed, 10 Dec 2014 10:10:42 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id h8sm7281079wiy.17.2014.12.10.10.10.41
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:42 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:39 +0100
Message-ID: <20141210181039.26400.94094.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 13/27] mg-kernbench-download: new script for
 downloading kernbench
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 downloads the benchmark (it's just a script) and a linux
kernel archive, necessary for running the benchmark itself,
and store them in c{Images}/benchs.

Default values for the repo URL and actual filename are embedded
in the script itself, and can be overridden as usual (e.g., via
standalone.config).

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 mg-kernbench-download |   49 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100755 mg-kernbench-download

diff --git a/mg-kernbench-download b/mg-kernbench-download
new file mode 100755
index 0000000..7ed252b
--- /dev/null
+++ b/mg-kernbench-download
@@ -0,0 +1,49 @@
+#!/bin/bash
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+set -e
+
+if [ -f standalone.config ] ; then
+    . standalone.config
+fi
+
+. cri-getconfig
+
+fail () { echo >&2 "$0: $1"; exit 1; }
+
+# By default we try to grab version 0.50, and we build linux 3.15.3
+site=${KERNBENCH_REMOTE:-http://ck.kolivas.org/apps/kernbench/kernbench-0.50}
+rfile=${KERNBENCH_FILE:-kernbench}
+site_kern=${KERNBENCH_REMOTE_KERN:-https://www.kernel.org/pub/linux/kernel/v3.x}
+rfile_kern=${KERNBENCH_FILE_KERN:-linux-3.15.3.tar.xz}
+
+lfile=kernbench
+lfile_kern=linux.xz
+
+images=`getconfig Images`;
+dstdir="${images}/benchs"
+mkdir -p $dstdir
+
+wget ${site}/${rfile} -O ${dstdir}/${lfile} || \
+    fail "failed downloading the benchmark"
+
+echo >&2 "downloaded $dstdir/$lfile"
+
+wget ${site_kern}/${rfile_kern} -O ${dstdir}/${lfile_kern} || \
+    fail "failed downloading the kernel to be built"
+
+echo >&2 "downloaded $dstdir/$lfile"


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:10:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylio-0005y0-IP; Wed, 10 Dec 2014 18:10:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylim-0005wZ-VD
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:45 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A4/96-17735-4AC88845; Wed, 10 Dec 2014 18:10:44 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418235043!12455424!1
X-Originating-IP: [74.125.82.44]
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 26072 invoked from network); 10 Dec 2014 18:10:43 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:43 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so4355840wgh.3
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=V7dga9fufv2dDSuKMp6zy8L7YMcHW01UgWqfNKN5MBA=;
	b=QzSTYrIi6qoJ6xxDp79qdTPAequohb5wD29xngvpD1JUth7nse8kWedSK/5K8pM2uw
	3faVJj6SDsklHjTDTcxxTZeaEA2vpCUYrKTkZ+cKzLHYTgnU/wnGK7w701hDyBEte96Q
	PEwR6dys2Jy/vgVg2lRmlL3zyWBxOCfFYLGvr1JRY80AuvqpBRPdhu6gPdHijMIEBm7F
	l8CixCCeXgJeERscnwL/441SC4c4ByjLZ3RZkDQWLY4lfq442Hy7votNZrnmw01r9GwO
	r5fzDDVSCAscUU1F+aoAmEd5rku1qJTtv4h+c0ND4yMYNyx/W6+doeMhqw2oyx0i/TyT
	aijg==
X-Received: by 10.180.90.165 with SMTP id bx5mr8618530wib.15.1418235042918;
	Wed, 10 Dec 2014 10:10:42 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id h8sm7281079wiy.17.2014.12.10.10.10.41
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:42 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:39 +0100
Message-ID: <20141210181039.26400.94094.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 13/27] mg-kernbench-download: new script for
 downloading kernbench
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 downloads the benchmark (it's just a script) and a linux
kernel archive, necessary for running the benchmark itself,
and store them in c{Images}/benchs.

Default values for the repo URL and actual filename are embedded
in the script itself, and can be overridden as usual (e.g., via
standalone.config).

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 mg-kernbench-download |   49 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100755 mg-kernbench-download

diff --git a/mg-kernbench-download b/mg-kernbench-download
new file mode 100755
index 0000000..7ed252b
--- /dev/null
+++ b/mg-kernbench-download
@@ -0,0 +1,49 @@
+#!/bin/bash
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+set -e
+
+if [ -f standalone.config ] ; then
+    . standalone.config
+fi
+
+. cri-getconfig
+
+fail () { echo >&2 "$0: $1"; exit 1; }
+
+# By default we try to grab version 0.50, and we build linux 3.15.3
+site=${KERNBENCH_REMOTE:-http://ck.kolivas.org/apps/kernbench/kernbench-0.50}
+rfile=${KERNBENCH_FILE:-kernbench}
+site_kern=${KERNBENCH_REMOTE_KERN:-https://www.kernel.org/pub/linux/kernel/v3.x}
+rfile_kern=${KERNBENCH_FILE_KERN:-linux-3.15.3.tar.xz}
+
+lfile=kernbench
+lfile_kern=linux.xz
+
+images=`getconfig Images`;
+dstdir="${images}/benchs"
+mkdir -p $dstdir
+
+wget ${site}/${rfile} -O ${dstdir}/${lfile} || \
+    fail "failed downloading the benchmark"
+
+echo >&2 "downloaded $dstdir/$lfile"
+
+wget ${site_kern}/${rfile_kern} -O ${dstdir}/${lfile_kern} || \
+    fail "failed downloading the kernel to be built"
+
+echo >&2 "downloaded $dstdir/$lfile"


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:11:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyliw-00064R-5B; Wed, 10 Dec 2014 18:10:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xyliu-00063C-Lw
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	7B/06-15461-CAC88845; Wed, 10 Dec 2014 18:10:52 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418235051!11319547!1
X-Originating-IP: [209.85.212.169]
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 20371 invoked from network); 10 Dec 2014 18:10:51 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:51 -0000
Received: by mail-wi0-f169.google.com with SMTP id r20so14169700wiv.4
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=9LQyeu1q4HMOCW80m8I2fw2IMaLl65bEbtDA/t+E+Sg=;
	b=kfv6a2B9vw1OxZ2+LFjYRRI5AvOFu5WFpcwsObjtKyMlU7IeiIwM/CUXyikesEi3Hr
	7VrAEy6LqoxLCxYEpl5n7G6uEN+ccguBi7fye/NkpL6GEAxPiOJ0GThq44s4TUdKz08C
	jVcjoVh5ODN7A4mUePmoaqyt3A4uRp4dOuvT+jKXdL+BjgvC4KfeUC1tXChB4OknNRBR
	9XsMhkM8iRd81cVOe//XzHjf6/BUS4cRNU8ZLCI357E47dxb4dpHyyxhz3TbHN09KHUV
	y9QwdgIt81xxQpVfUEqwNtqCT28VFeBQhrHUq0VBiSh3vjZGRJ6S0q5t4+LuH08zJcmk
	Svog==
X-Received: by 10.180.73.206 with SMTP id n14mr15543863wiv.60.1418235050894;
	Wed, 10 Dec 2014 10:10:50 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103]) by mx.google.com with ESMTPSA id
	t10sm18880438wix.15.2014.12.10.10.10.49 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:50 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:48 +0100
Message-ID: <20141210181048.26400.68865.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 14/27] ts-kernbench-build: prep the environment
 for running kernbench
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 shipping the benchmark (it's just a script) and the linux
kernel sources to the target. The dependences installed are
the ones required to build a linux kernel, plus a few more
packages required by the kernbench script.

As for the unixbench equivalent, this accepts two parametrs,
in the form 'host=somehost someguest'. If only the first one is
provided, it must be 'host=somehost', and the script will prep
the host.

This also installs some packages so, if host sharing is to
be allowed (which, BTW, is highly *not* recommended), the
following patch from Ian Campbell is required:

  http://lists.xen.org/archives/html/xen-devel/2014-04/msg02978.html

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-kernbench-build |   86 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100755 ts-kernbench-build

diff --git a/ts-kernbench-build b/ts-kernbench-build
new file mode 100755
index 0000000..eea844c
--- /dev/null
+++ b/ts-kernbench-build
@@ -0,0 +1,86 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+use File::Basename;
+
+tsreadconfig();
+
+# what we expect as argument list is:
+#  host=<somehost> [<someguest>]
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+our $gho= $ho;
+if (defined $gn and $gn ne "") {
+  $gho= selectguest($gn, $ho);
+  my $err= guest_check_ip($gho);
+  die "$err $gho->{Name}" if defined $err;
+}
+
+# By default, we expect to find kernbench 0,50, stored in
+# $c{Images}/benchs/kernbench. To use something different, define
+# r{'kernbench_file'}.
+our $kernbench_file= (defined($r{'kernbench_file'})) ? $r{'kernbench_file'} :
+    "$c{Images}/benchs/kernbench";
+
+# We also assume to find the linux kernel archive to be used for the benchmark
+# in $c{Images}benchs/linux.xz. To use something different, define
+# $r{'kernbench_kern_file'}.
+our $kernbench_linux_file= (defined($r{'kernbench_kern_file'})) ?
+    $r{'kernbench_kern_file'} : "$c{Images}/benchs/linux.xz";
+
+# Some deps...
+sub install_deps() {
+  target_install_packages_norec($gho, qw(build-essential time bc));
+}
+
+# Ship the benchmark and the linux kernel archive to the target machine
+sub ship() {
+  logm("Shipping $kernbench_file and $kernbench_linux_file");
+  target_putfile_root($gho, 60, "$kernbench_file", "/root/kernbench");
+  target_putfile_root($gho, 200, "$kernbench_linux_file", "/root/");
+
+  our $kernbench_linux_filename= basename($kernbench_linux_file);
+  logm("Extracting $kernbench_linux_filename");
+  target_cmd_root($gho, <<END, 200);
+      set -ex
+      chmod +x /root/kernbench
+      rm -rf /root/linux-kernbench
+      mkdir /root/linux-kernbench
+      tar xaf /root/$kernbench_linux_filename -C /root/linux-kernbench --strip-components=1
+END
+}
+
+sub prep() {
+  # We use 'alldefconfig', to stress the system a bit more
+  # (default would be 'allnoconfig').
+  target_cmd_root($gho, <<END, 200);
+      set -ex
+      cd /root/linux-kernbench
+      make mrproper
+      make alldefconfig
+END
+}
+
+install_deps();
+ship();
+prep();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:11:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyliw-00064R-5B; Wed, 10 Dec 2014 18:10:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xyliu-00063C-Lw
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:10:52 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	7B/06-15461-CAC88845; Wed, 10 Dec 2014 18:10:52 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418235051!11319547!1
X-Originating-IP: [209.85.212.169]
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 20371 invoked from network); 10 Dec 2014 18:10:51 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:10:51 -0000
Received: by mail-wi0-f169.google.com with SMTP id r20so14169700wiv.4
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:10:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=9LQyeu1q4HMOCW80m8I2fw2IMaLl65bEbtDA/t+E+Sg=;
	b=kfv6a2B9vw1OxZ2+LFjYRRI5AvOFu5WFpcwsObjtKyMlU7IeiIwM/CUXyikesEi3Hr
	7VrAEy6LqoxLCxYEpl5n7G6uEN+ccguBi7fye/NkpL6GEAxPiOJ0GThq44s4TUdKz08C
	jVcjoVh5ODN7A4mUePmoaqyt3A4uRp4dOuvT+jKXdL+BjgvC4KfeUC1tXChB4OknNRBR
	9XsMhkM8iRd81cVOe//XzHjf6/BUS4cRNU8ZLCI357E47dxb4dpHyyxhz3TbHN09KHUV
	y9QwdgIt81xxQpVfUEqwNtqCT28VFeBQhrHUq0VBiSh3vjZGRJ6S0q5t4+LuH08zJcmk
	Svog==
X-Received: by 10.180.73.206 with SMTP id n14mr15543863wiv.60.1418235050894;
	Wed, 10 Dec 2014 10:10:50 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103]) by mx.google.com with ESMTPSA id
	t10sm18880438wix.15.2014.12.10.10.10.49 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:50 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:48 +0100
Message-ID: <20141210181048.26400.68865.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 14/27] ts-kernbench-build: prep the environment
 for running kernbench
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 shipping the benchmark (it's just a script) and the linux
kernel sources to the target. The dependences installed are
the ones required to build a linux kernel, plus a few more
packages required by the kernbench script.

As for the unixbench equivalent, this accepts two parametrs,
in the form 'host=somehost someguest'. If only the first one is
provided, it must be 'host=somehost', and the script will prep
the host.

This also installs some packages so, if host sharing is to
be allowed (which, BTW, is highly *not* recommended), the
following patch from Ian Campbell is required:

  http://lists.xen.org/archives/html/xen-devel/2014-04/msg02978.html

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-kernbench-build |   86 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100755 ts-kernbench-build

diff --git a/ts-kernbench-build b/ts-kernbench-build
new file mode 100755
index 0000000..eea844c
--- /dev/null
+++ b/ts-kernbench-build
@@ -0,0 +1,86 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+use File::Basename;
+
+tsreadconfig();
+
+# what we expect as argument list is:
+#  host=<somehost> [<someguest>]
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+our $gho= $ho;
+if (defined $gn and $gn ne "") {
+  $gho= selectguest($gn, $ho);
+  my $err= guest_check_ip($gho);
+  die "$err $gho->{Name}" if defined $err;
+}
+
+# By default, we expect to find kernbench 0,50, stored in
+# $c{Images}/benchs/kernbench. To use something different, define
+# r{'kernbench_file'}.
+our $kernbench_file= (defined($r{'kernbench_file'})) ? $r{'kernbench_file'} :
+    "$c{Images}/benchs/kernbench";
+
+# We also assume to find the linux kernel archive to be used for the benchmark
+# in $c{Images}benchs/linux.xz. To use something different, define
+# $r{'kernbench_kern_file'}.
+our $kernbench_linux_file= (defined($r{'kernbench_kern_file'})) ?
+    $r{'kernbench_kern_file'} : "$c{Images}/benchs/linux.xz";
+
+# Some deps...
+sub install_deps() {
+  target_install_packages_norec($gho, qw(build-essential time bc));
+}
+
+# Ship the benchmark and the linux kernel archive to the target machine
+sub ship() {
+  logm("Shipping $kernbench_file and $kernbench_linux_file");
+  target_putfile_root($gho, 60, "$kernbench_file", "/root/kernbench");
+  target_putfile_root($gho, 200, "$kernbench_linux_file", "/root/");
+
+  our $kernbench_linux_filename= basename($kernbench_linux_file);
+  logm("Extracting $kernbench_linux_filename");
+  target_cmd_root($gho, <<END, 200);
+      set -ex
+      chmod +x /root/kernbench
+      rm -rf /root/linux-kernbench
+      mkdir /root/linux-kernbench
+      tar xaf /root/$kernbench_linux_filename -C /root/linux-kernbench --strip-components=1
+END
+}
+
+sub prep() {
+  # We use 'alldefconfig', to stress the system a bit more
+  # (default would be 'allnoconfig').
+  target_cmd_root($gho, <<END, 200);
+      set -ex
+      cd /root/linux-kernbench
+      make mrproper
+      make alldefconfig
+END
+}
+
+install_deps();
+ship();
+prep();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:11:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyljE-0006Jn-3R; Wed, 10 Dec 2014 18:11:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyljC-0006IM-IY
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:10 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	E3/91-17958-DBC88845; Wed, 10 Dec 2014 18:11:09 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418235067!12455499!1
X-Originating-IP: [74.125.82.49]
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 27845 invoked from network); 10 Dec 2014 18:11:07 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:07 -0000
Received: by mail-wg0-f49.google.com with SMTP id n12so4335728wgh.8
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=ZuakWe5iNepiykydVD5vQGuUo5UP5gjIAKago224yJY=;
	b=tVvik6w9mlxjhhY1yTtgbqCPJ4hru5pOIH/LuDefi4NrGqBOTvPMB32i7rJpd7TjYt
	mZjAACYlijZmbZEQMsE+yQyFIOARIfor4JQlWPn0v2hiDi/q8fpAXdj7IfLPvI0oco90
	ze7MN5+S7wJsdCVJt7AptuYDHs+7dyhA+z/D2cA114I4fs+4OjHoBGcnA8KOoufB1+LY
	MCQfPhOH09l6pYKliiS8dyo2CrUWgqNEbBBYJREoR7uvz9cBCwhH7rdk+XqpAjNErbgt
	tdvpAWZv5lUux+b3hSZMKUEoFvE/vHLF9JkOnqorOQQq+/XhThOBSmr+918BgoCVOnuS
	T4AQ==
X-Received: by 10.194.81.38 with SMTP id w6mr8892925wjx.17.1418235067323;
	Wed, 10 Dec 2014 10:11:07 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id pl1sm7286437wic.16.2014.12.10.10.11.05
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:06 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:04 +0100
Message-ID: <20141210181104.26400.72266.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 16/27] ts-unixbench-reslts: retrieve and stash
 kernbench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 a file named according to the following convention:

 $hostname--$benchname-$benchparams

i.e., something like this:

 debian--kernbench-n2

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-kernbench-reslts |   60 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100755 ts-kernbench-reslts

diff --git a/ts-kernbench-reslts b/ts-kernbench-reslts
new file mode 100755
index 0000000..dcb279d
--- /dev/null
+++ b/ts-kernbench-reslts
@@ -0,0 +1,60 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 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/>.
+
+use strict qw(vars);
+use Osstest;
+use DBI;
+use IO::File;
+use POSIX;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+# what we expect as argument list is:
+#  host=<somehost> [<someguest>]
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+our $gho= $ho;
+if (defined $gn and $gn ne "") {
+  $gho= selectguest($gn, $ho);
+  my $err= guest_check_ip($gho);
+  die "$err $gho->{Name}" if defined $err;
+}
+
+our $lresfile= $r{'kernbench_params'};
+$lresfile =~ tr/ //ds;
+$lresfile .= (defined($r{'kernbench_run_suffix'})) ?
+      $r{'kernbench_run_suffix'} : '';
+$lresfile = "kernbench$lresfile";
+
+# Kernbench stores results in the linux kernel tree it
+# built, in a file called kernbench.log
+sub results() {
+  my $rresults_dir= "/root/linux-kernbench";
+  my $rresfile= "$rresults_dir/kernbench.log";
+
+  my $gho_hostname= target_cmd_output_root($gho, 'hostname');
+  target_cmd_root($gho, "chmod a+r $rresfile", 60);
+
+  logm("Fetching $rresfile from $gho_hostname");
+  target_getfile_root_stash($gho, 60, "$rresfile",
+      "$lresfile");
+}
+
+results();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:11:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylj5-0006C3-It; Wed, 10 Dec 2014 18:11:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylj3-0006A9-FA
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:02 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	4D/74-01660-4BC88845; Wed, 10 Dec 2014 18:11:00 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418235060!5067957!1
X-Originating-IP: [209.85.212.180]
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 8528 invoked from network); 10 Dec 2014 18:11:00 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:00 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so6083534wiv.13
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=N2zfiwxyz5XO9S9+iS5DEdyq8EkuT1uP57+DkjzQ60g=;
	b=IpwIfgt65In3zXegCweUiEoMT2He4EAjyxtUP2JP0gHX2KP3d0RWDX0pNtf7RjK8VX
	0zUmOKGrVYJoq0iqL4FA0OHKQn7uD1njiE/IiZt5+dTGIRWuDgopK0I0QGYbldhCjeH9
	PeZENtv2IULJXO9Y/FGILbXpZusr2jRzz8DKGW2gKqadgdJujaSod3Gzlvhys5GMpzLq
	KJUUAxkq7frw7vm7V64mW585sOkZo3uGvvOK7DazfnRNuIEkW7QaKO3vQSOWBW4v0FFH
	FZMWgfEUo9fgu50J3jgTVtLKljOw2p/+EtVYgxaSWih1W05DXimqVo9mwkhThcNZyf+2
	iQng==
X-Received: by 10.194.95.196 with SMTP id dm4mr9016988wjb.41.1418235059013;
	Wed, 10 Dec 2014 10:10:59 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103]) by mx.google.com with ESMTPSA id
	js5sm18886425wid.11.2014.12.10.10.10.57 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:58 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:56 +0100
Message-ID: <20141210181055.26400.31874.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 15/27] ts-kernbench-run: kick off the benchmark
	on the 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

There is a runvar called 'kernbench_params', for specifying
the benchmark's runtime arguments.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-kernbench-run |   63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)
 create mode 100755 ts-kernbench-run

diff --git a/ts-kernbench-run b/ts-kernbench-run
new file mode 100755
index 0000000..389f6b3
--- /dev/null
+++ b/ts-kernbench-run
@@ -0,0 +1,63 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+# what we expect as argument list is:
+#  host=<somehost> [<someguest>]
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+our $gho= $ho;
+if (defined $gn and $gn ne "") {
+  $gho= selectguest($gn, $ho);
+  my $err= guest_check_ip($gho);
+  die "$err $gho->{Name}" if defined $err;
+}
+
+# Runtime parameters for the benchmark. We expect them to be
+# specified via a runvar. If not, let's provide a safe default.
+if (!defined($r{ 'kernbench_params' })) {
+  store_runvar('kernbench_params',"-n 2");
+}
+our $args= $r{'kernbench_params'};
+our $timeout= (defined($r{'kernbench_timeout'})) ?
+      $r{'kernbench_timeout'} : 12000;
+
+sub run() {
+  logm("Running: /root/linux-kernbench/../kernbench $args (timeout: $timeout)");
+  target_cmd_root($gho, <<END, $timeout);
+      set -ex
+      cd /root/linux-kernbench/
+      rm -f kernbench.log timelog
+      time ../kernbench $args
+END
+}
+
+sub hwinfo() {
+  target_catfile_root_stash($gho, "/proc/cpuinfo");
+  target_catfile_root_stash($gho, "/proc/meminfo");
+}
+
+hwinfo();
+run();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:11:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylj5-0006C3-It; Wed, 10 Dec 2014 18:11:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylj3-0006A9-FA
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:02 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	4D/74-01660-4BC88845; Wed, 10 Dec 2014 18:11:00 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418235060!5067957!1
X-Originating-IP: [209.85.212.180]
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 8528 invoked from network); 10 Dec 2014 18:11:00 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:00 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so6083534wiv.13
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=N2zfiwxyz5XO9S9+iS5DEdyq8EkuT1uP57+DkjzQ60g=;
	b=IpwIfgt65In3zXegCweUiEoMT2He4EAjyxtUP2JP0gHX2KP3d0RWDX0pNtf7RjK8VX
	0zUmOKGrVYJoq0iqL4FA0OHKQn7uD1njiE/IiZt5+dTGIRWuDgopK0I0QGYbldhCjeH9
	PeZENtv2IULJXO9Y/FGILbXpZusr2jRzz8DKGW2gKqadgdJujaSod3Gzlvhys5GMpzLq
	KJUUAxkq7frw7vm7V64mW585sOkZo3uGvvOK7DazfnRNuIEkW7QaKO3vQSOWBW4v0FFH
	FZMWgfEUo9fgu50J3jgTVtLKljOw2p/+EtVYgxaSWih1W05DXimqVo9mwkhThcNZyf+2
	iQng==
X-Received: by 10.194.95.196 with SMTP id dm4mr9016988wjb.41.1418235059013;
	Wed, 10 Dec 2014 10:10:59 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103]) by mx.google.com with ESMTPSA id
	js5sm18886425wid.11.2014.12.10.10.10.57 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:10:58 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:10:56 +0100
Message-ID: <20141210181055.26400.31874.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 15/27] ts-kernbench-run: kick off the benchmark
	on the 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

There is a runvar called 'kernbench_params', for specifying
the benchmark's runtime arguments.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-kernbench-run |   63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)
 create mode 100755 ts-kernbench-run

diff --git a/ts-kernbench-run b/ts-kernbench-run
new file mode 100755
index 0000000..389f6b3
--- /dev/null
+++ b/ts-kernbench-run
@@ -0,0 +1,63 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+# what we expect as argument list is:
+#  host=<somehost> [<someguest>]
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+our $gho= $ho;
+if (defined $gn and $gn ne "") {
+  $gho= selectguest($gn, $ho);
+  my $err= guest_check_ip($gho);
+  die "$err $gho->{Name}" if defined $err;
+}
+
+# Runtime parameters for the benchmark. We expect them to be
+# specified via a runvar. If not, let's provide a safe default.
+if (!defined($r{ 'kernbench_params' })) {
+  store_runvar('kernbench_params',"-n 2");
+}
+our $args= $r{'kernbench_params'};
+our $timeout= (defined($r{'kernbench_timeout'})) ?
+      $r{'kernbench_timeout'} : 12000;
+
+sub run() {
+  logm("Running: /root/linux-kernbench/../kernbench $args (timeout: $timeout)");
+  target_cmd_root($gho, <<END, $timeout);
+      set -ex
+      cd /root/linux-kernbench/
+      rm -f kernbench.log timelog
+      time ../kernbench $args
+END
+}
+
+sub hwinfo() {
+  target_catfile_root_stash($gho, "/proc/cpuinfo");
+  target_catfile_root_stash($gho, "/proc/meminfo");
+}
+
+hwinfo();
+run();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:11:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyljE-0006Jn-3R; Wed, 10 Dec 2014 18:11:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyljC-0006IM-IY
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:10 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	E3/91-17958-DBC88845; Wed, 10 Dec 2014 18:11:09 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418235067!12455499!1
X-Originating-IP: [74.125.82.49]
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 27845 invoked from network); 10 Dec 2014 18:11:07 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:07 -0000
Received: by mail-wg0-f49.google.com with SMTP id n12so4335728wgh.8
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=ZuakWe5iNepiykydVD5vQGuUo5UP5gjIAKago224yJY=;
	b=tVvik6w9mlxjhhY1yTtgbqCPJ4hru5pOIH/LuDefi4NrGqBOTvPMB32i7rJpd7TjYt
	mZjAACYlijZmbZEQMsE+yQyFIOARIfor4JQlWPn0v2hiDi/q8fpAXdj7IfLPvI0oco90
	ze7MN5+S7wJsdCVJt7AptuYDHs+7dyhA+z/D2cA114I4fs+4OjHoBGcnA8KOoufB1+LY
	MCQfPhOH09l6pYKliiS8dyo2CrUWgqNEbBBYJREoR7uvz9cBCwhH7rdk+XqpAjNErbgt
	tdvpAWZv5lUux+b3hSZMKUEoFvE/vHLF9JkOnqorOQQq+/XhThOBSmr+918BgoCVOnuS
	T4AQ==
X-Received: by 10.194.81.38 with SMTP id w6mr8892925wjx.17.1418235067323;
	Wed, 10 Dec 2014 10:11:07 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id pl1sm7286437wic.16.2014.12.10.10.11.05
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:06 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:04 +0100
Message-ID: <20141210181104.26400.72266.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 16/27] ts-unixbench-reslts: retrieve and stash
 kernbench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 a file named according to the following convention:

 $hostname--$benchname-$benchparams

i.e., something like this:

 debian--kernbench-n2

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-kernbench-reslts |   60 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100755 ts-kernbench-reslts

diff --git a/ts-kernbench-reslts b/ts-kernbench-reslts
new file mode 100755
index 0000000..dcb279d
--- /dev/null
+++ b/ts-kernbench-reslts
@@ -0,0 +1,60 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 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/>.
+
+use strict qw(vars);
+use Osstest;
+use DBI;
+use IO::File;
+use POSIX;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+# what we expect as argument list is:
+#  host=<somehost> [<someguest>]
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+our $gho= $ho;
+if (defined $gn and $gn ne "") {
+  $gho= selectguest($gn, $ho);
+  my $err= guest_check_ip($gho);
+  die "$err $gho->{Name}" if defined $err;
+}
+
+our $lresfile= $r{'kernbench_params'};
+$lresfile =~ tr/ //ds;
+$lresfile .= (defined($r{'kernbench_run_suffix'})) ?
+      $r{'kernbench_run_suffix'} : '';
+$lresfile = "kernbench$lresfile";
+
+# Kernbench stores results in the linux kernel tree it
+# built, in a file called kernbench.log
+sub results() {
+  my $rresults_dir= "/root/linux-kernbench";
+  my $rresfile= "$rresults_dir/kernbench.log";
+
+  my $gho_hostname= target_cmd_output_root($gho, 'hostname');
+  target_cmd_root($gho, "chmod a+r $rresfile", 60);
+
+  logm("Fetching $rresfile from $gho_hostname");
+  target_getfile_root_stash($gho, 60, "$rresfile",
+      "$lresfile");
+}
+
+results();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:11:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyljM-0006RB-Hy; Wed, 10 Dec 2014 18:11:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyljK-0006P4-7P
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:18 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	36/41-17694-5CC88845; Wed, 10 Dec 2014 18:11:17 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418235076!12452345!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26610 invoked from network); 10 Dec 2014 18:11:16 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:16 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so12103161wiv.17
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=8ZTekhGPPgPtkA30GZ4KLcOgqMKxWXlfKvYUHNGgxck=;
	b=uclYZXwgaWVfCkyVJ3DUHrfe0Ql6O7ZwJPdDTWMqXmmSj1GgYcZFQHo5KBQsk5KkSI
	9nf1/JJluJgIVrl46U48BnEpyGxai2m8WPbWryuWiy4djcxz+E7yH4e/Lx29OCTDXORF
	t2ncnnAyNVjYE8a/kMQVGAv+lANV3deYNKR+R7oS4IHbDSaQW/8j94fuES8iQV2JAKHU
	v81qbfPh/q9U0zFBFjmYd4/XHqScYYSQDmLXOw7Hm394FOYmGWR0xQoqOHmKYUlU3OJu
	8u419D2Jj4h7ZWAazhiHz0klzzEhgc2Oa8VehyZF65RS30FIf+TXVHRbf83MQpAxXaeO
	55PQ==
X-Received: by 10.180.11.97 with SMTP id p1mr15630189wib.22.1418235075097;
	Wed, 10 Dec 2014 10:11:15 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id vy7sm6813485wjc.27.2014.12.10.10.11.13
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:14 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:12 +0100
Message-ID: <20141210181112.26400.8824.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 17/27] ts-kernbench-reslts: process and plot
	bench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

Extract the data from the output of kernbench and produce
the tables, the gnuplot script and the plots.

All is saved in $stash, for the running flight and job.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Benchmarking.pm |   88 ++++++++++++++++++++++++++++++++++++++++++++---
 ts-kernbench-reslts     |   19 +++++++++-
 2 files changed, 99 insertions(+), 8 deletions(-)

diff --git a/Osstest/Benchmarking.pm b/Osstest/Benchmarking.pm
index 0c5c538..ff45766 100644
--- a/Osstest/Benchmarking.pm
+++ b/Osstest/Benchmarking.pm
@@ -34,6 +34,9 @@ BEGIN {
     @EXPORT      = qw(unixbench_process_results
                       unixbench_print_results
                       unixbench_plot_results
+                      kernbench_process_results
+                      kernbench_print_results
+                      kernbench_plot_results
                       );
     %EXPORT_TAGS = ( );
 
@@ -83,6 +86,15 @@ sub unixbench_print_results ($$) {
   close($h);
 }
 
+our $common_plot_opts= <<EOF;
+set key outside center top horizontal noreverse noenhanced autotitles nobox
+set xtics mirror rotate by -45 out
+set style data histogram
+set style histogram cluster gap 1
+set style fill solid border lt -1
+set boxwidth 1 absolute
+EOF
+
 sub unixbench_plot_results ($$$) {
   my ($dataf,$num_cols,$pfile)= @_;
   my $h= new IO::File "> $pfile.gp" or die "$!";
@@ -91,12 +103,7 @@ sub unixbench_plot_results ($$$) {
 set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" 8 size 800,600
 set output '$pfile.png'
 set title 'Unixbench INDEXes for $flight.$job'
-set key outside center top horizontal noreverse noenhanced autotitles nobox
-set xtics mirror rotate by -45 out
-set style data histogram
-set style histogram cluster gap 1
-set style fill solid border lt -1
-set boxwidth 1 absolute
+$common_plot_opts
 set bmargin 13
 set rmargin 14
 SKIP_COL=1
@@ -112,4 +119,73 @@ EOF
   logm("WARNING: plotting file with \"$err\"") unless $ok;
 }
 
+sub kernbench_process_results ($$) {
+  my ($results_ref,$rfilen)= @_;
+  my $h= new IO::File "< $rfilen" or die "$!";
+
+  my $run;
+  while (<$h>) {
+    my ($bench,$val,$stdd);
+    if (m/.*load -j ([0-9]*)\s?Run.*$/) {
+      $run= $1 || 0;
+    }
+    if (m/^(\S[a-zA-z\s]*)\s([0-9]+.?[0-9]*)\s\(([0-9]+.?[0-9]*)\)$/) {
+      $bench=$1;
+      next if $bench =~ /Sleeps|Context|Percent/;
+      $val= $2;
+      $stdd= $3;
+      $$results_ref->{"$bench"}{Result}{"$run"}= $val;
+      $$results_ref->{"$bench"}{StdDev}{"$run"}= $stdd;
+    }
+    next;
+  }
+  close($h);
+}
+
+sub kernbench_print_results ($$) {
+  my ($results,$rfilen)= @_;
+  open my $h, "|-", "tee $rfilen" or die "$!";
+
+  printf $h "%-25s","\"What\"";
+  foreach my $i (sort keys $results->{'Elapsed Time'}{'Result'}) {
+    my $col= "kernbench -j";
+    $col .= ($i == 0) ? "" : " $i";
+    printf $h "%-20s","\"$col\""
+    # TODO: Include stddev too in the report
+  }
+  print $h "\n";
+  foreach my $b (keys $results) {
+    printf $h "%-25s","\"$b\"";
+    foreach my $i (sort keys $results->{"$b"}{'Result'}) {
+      printf $h "%-20s",$results->{$b}{'Result'}{$i};
+    }
+    print $h "\n";
+  }
+  close($h);
+}
+
+sub kernbench_plot_results ($$$) {
+  my ($dataf,$num_cols,$pfile)= @_;
+
+  my $h= new IO::File "> $pfile.gp" or die "$!";
+  print $h <<EOF;
+set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" 8 size 800,600
+set output '$pfile.png'
+set title 'Kernbench Results for $flight.$job'
+$common_plot_opts
+set bmargin 6
+SKIP_COL=1
+NCOL=$num_cols
+HWIDTH=1.0/(NCOL+1.0)
+cols=''
+plot for [c=SKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with histograms title columnhead, \\
+        for [c=SKIP_COL+1:SKIP_COL+NCOL] '' every ::1 using 0:c:c with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1))*HWIDTH, character 2 rotate by 90
+EOF
+  close($h);
+
+  my $gp= can_run('gnuplot') or return;
+  my ($ok,$err)= run( command => "$gp $pfile.gp", verbose => 1 );
+  logm("WARNING: plotting file with \"$err\"") unless $ok;
+}
+
 1;
diff --git a/ts-kernbench-reslts b/ts-kernbench-reslts
index dcb279d..113a4ce 100755
--- a/ts-kernbench-reslts
+++ b/ts-kernbench-reslts
@@ -21,6 +21,7 @@ use DBI;
 use IO::File;
 use POSIX;
 use Osstest::TestSupport;
+use Osstest::Benchmarking;
 
 tsreadconfig();
 
@@ -43,9 +44,11 @@ $lresfile .= (defined($r{'kernbench_run_suffix'})) ?
       $r{'kernbench_run_suffix'} : '';
 $lresfile = "kernbench$lresfile";
 
+our $results;
+
 # Kernbench stores results in the linux kernel tree it
 # built, in a file called kernbench.log
-sub results() {
+sub fetch() {
   my $rresults_dir= "/root/linux-kernbench";
   my $rresfile= "$rresults_dir/kernbench.log";
 
@@ -57,4 +60,16 @@ sub results() {
       "$lresfile");
 }
 
-results();
+sub process () {
+  my $resf= "$stash/$gho->{Name}--$lresfile";
+  my $dataf= "$resf-DATA";
+  my $plotf= "$resf-PLOT";
+
+  kernbench_process_results(\$results,$resf);
+  kernbench_print_results($results,$dataf);
+  my $ncols= keys $results->{'Elapsed Time'}{'Result'};
+  kernbench_plot_results($dataf,$ncols,$plotf);
+}
+
+fetch();
+process();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:11:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyljM-0006RB-Hy; Wed, 10 Dec 2014 18:11:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyljK-0006P4-7P
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:18 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	36/41-17694-5CC88845; Wed, 10 Dec 2014 18:11:17 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418235076!12452345!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26610 invoked from network); 10 Dec 2014 18:11:16 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:16 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so12103161wiv.17
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=8ZTekhGPPgPtkA30GZ4KLcOgqMKxWXlfKvYUHNGgxck=;
	b=uclYZXwgaWVfCkyVJ3DUHrfe0Ql6O7ZwJPdDTWMqXmmSj1GgYcZFQHo5KBQsk5KkSI
	9nf1/JJluJgIVrl46U48BnEpyGxai2m8WPbWryuWiy4djcxz+E7yH4e/Lx29OCTDXORF
	t2ncnnAyNVjYE8a/kMQVGAv+lANV3deYNKR+R7oS4IHbDSaQW/8j94fuES8iQV2JAKHU
	v81qbfPh/q9U0zFBFjmYd4/XHqScYYSQDmLXOw7Hm394FOYmGWR0xQoqOHmKYUlU3OJu
	8u419D2Jj4h7ZWAazhiHz0klzzEhgc2Oa8VehyZF65RS30FIf+TXVHRbf83MQpAxXaeO
	55PQ==
X-Received: by 10.180.11.97 with SMTP id p1mr15630189wib.22.1418235075097;
	Wed, 10 Dec 2014 10:11:15 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id vy7sm6813485wjc.27.2014.12.10.10.11.13
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:14 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:12 +0100
Message-ID: <20141210181112.26400.8824.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 17/27] ts-kernbench-reslts: process and plot
	bench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

Extract the data from the output of kernbench and produce
the tables, the gnuplot script and the plots.

All is saved in $stash, for the running flight and job.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Benchmarking.pm |   88 ++++++++++++++++++++++++++++++++++++++++++++---
 ts-kernbench-reslts     |   19 +++++++++-
 2 files changed, 99 insertions(+), 8 deletions(-)

diff --git a/Osstest/Benchmarking.pm b/Osstest/Benchmarking.pm
index 0c5c538..ff45766 100644
--- a/Osstest/Benchmarking.pm
+++ b/Osstest/Benchmarking.pm
@@ -34,6 +34,9 @@ BEGIN {
     @EXPORT      = qw(unixbench_process_results
                       unixbench_print_results
                       unixbench_plot_results
+                      kernbench_process_results
+                      kernbench_print_results
+                      kernbench_plot_results
                       );
     %EXPORT_TAGS = ( );
 
@@ -83,6 +86,15 @@ sub unixbench_print_results ($$) {
   close($h);
 }
 
+our $common_plot_opts= <<EOF;
+set key outside center top horizontal noreverse noenhanced autotitles nobox
+set xtics mirror rotate by -45 out
+set style data histogram
+set style histogram cluster gap 1
+set style fill solid border lt -1
+set boxwidth 1 absolute
+EOF
+
 sub unixbench_plot_results ($$$) {
   my ($dataf,$num_cols,$pfile)= @_;
   my $h= new IO::File "> $pfile.gp" or die "$!";
@@ -91,12 +103,7 @@ sub unixbench_plot_results ($$$) {
 set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" 8 size 800,600
 set output '$pfile.png'
 set title 'Unixbench INDEXes for $flight.$job'
-set key outside center top horizontal noreverse noenhanced autotitles nobox
-set xtics mirror rotate by -45 out
-set style data histogram
-set style histogram cluster gap 1
-set style fill solid border lt -1
-set boxwidth 1 absolute
+$common_plot_opts
 set bmargin 13
 set rmargin 14
 SKIP_COL=1
@@ -112,4 +119,73 @@ EOF
   logm("WARNING: plotting file with \"$err\"") unless $ok;
 }
 
+sub kernbench_process_results ($$) {
+  my ($results_ref,$rfilen)= @_;
+  my $h= new IO::File "< $rfilen" or die "$!";
+
+  my $run;
+  while (<$h>) {
+    my ($bench,$val,$stdd);
+    if (m/.*load -j ([0-9]*)\s?Run.*$/) {
+      $run= $1 || 0;
+    }
+    if (m/^(\S[a-zA-z\s]*)\s([0-9]+.?[0-9]*)\s\(([0-9]+.?[0-9]*)\)$/) {
+      $bench=$1;
+      next if $bench =~ /Sleeps|Context|Percent/;
+      $val= $2;
+      $stdd= $3;
+      $$results_ref->{"$bench"}{Result}{"$run"}= $val;
+      $$results_ref->{"$bench"}{StdDev}{"$run"}= $stdd;
+    }
+    next;
+  }
+  close($h);
+}
+
+sub kernbench_print_results ($$) {
+  my ($results,$rfilen)= @_;
+  open my $h, "|-", "tee $rfilen" or die "$!";
+
+  printf $h "%-25s","\"What\"";
+  foreach my $i (sort keys $results->{'Elapsed Time'}{'Result'}) {
+    my $col= "kernbench -j";
+    $col .= ($i == 0) ? "" : " $i";
+    printf $h "%-20s","\"$col\""
+    # TODO: Include stddev too in the report
+  }
+  print $h "\n";
+  foreach my $b (keys $results) {
+    printf $h "%-25s","\"$b\"";
+    foreach my $i (sort keys $results->{"$b"}{'Result'}) {
+      printf $h "%-20s",$results->{$b}{'Result'}{$i};
+    }
+    print $h "\n";
+  }
+  close($h);
+}
+
+sub kernbench_plot_results ($$$) {
+  my ($dataf,$num_cols,$pfile)= @_;
+
+  my $h= new IO::File "> $pfile.gp" or die "$!";
+  print $h <<EOF;
+set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" 8 size 800,600
+set output '$pfile.png'
+set title 'Kernbench Results for $flight.$job'
+$common_plot_opts
+set bmargin 6
+SKIP_COL=1
+NCOL=$num_cols
+HWIDTH=1.0/(NCOL+1.0)
+cols=''
+plot for [c=SKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with histograms title columnhead, \\
+        for [c=SKIP_COL+1:SKIP_COL+NCOL] '' every ::1 using 0:c:c with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1))*HWIDTH, character 2 rotate by 90
+EOF
+  close($h);
+
+  my $gp= can_run('gnuplot') or return;
+  my ($ok,$err)= run( command => "$gp $pfile.gp", verbose => 1 );
+  logm("WARNING: plotting file with \"$err\"") unless $ok;
+}
+
 1;
diff --git a/ts-kernbench-reslts b/ts-kernbench-reslts
index dcb279d..113a4ce 100755
--- a/ts-kernbench-reslts
+++ b/ts-kernbench-reslts
@@ -21,6 +21,7 @@ use DBI;
 use IO::File;
 use POSIX;
 use Osstest::TestSupport;
+use Osstest::Benchmarking;
 
 tsreadconfig();
 
@@ -43,9 +44,11 @@ $lresfile .= (defined($r{'kernbench_run_suffix'})) ?
       $r{'kernbench_run_suffix'} : '';
 $lresfile = "kernbench$lresfile";
 
+our $results;
+
 # Kernbench stores results in the linux kernel tree it
 # built, in a file called kernbench.log
-sub results() {
+sub fetch() {
   my $rresults_dir= "/root/linux-kernbench";
   my $rresfile= "$rresults_dir/kernbench.log";
 
@@ -57,4 +60,16 @@ sub results() {
       "$lresfile");
 }
 
-results();
+sub process () {
+  my $resf= "$stash/$gho->{Name}--$lresfile";
+  my $dataf= "$resf-DATA";
+  my $plotf= "$resf-PLOT";
+
+  kernbench_process_results(\$results,$resf);
+  kernbench_print_results($results,$dataf);
+  my $ncols= keys $results->{'Elapsed Time'}{'Result'};
+  kernbench_plot_results($dataf,$ncols,$plotf);
+}
+
+fetch();
+process();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XyljS-0006VL-1h; Wed, 10 Dec 2014 18:11:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyljR-0006US-6a
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:25 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	CF/61-02953-CCC88845; Wed, 10 Dec 2014 18:11:24 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418235083!14283419!1
X-Originating-IP: [209.85.212.181]
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 6080 invoked from network); 10 Dec 2014 18:11:23 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:23 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so6090839wiv.8
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=3pTstSETxDJ3slELCC+ePQf0PXo7BGXs7JPLzMPG0Ps=;
	b=MJiajtTB4o4KvR9BSJqDjabrEynOopoAOYf+Q5Ll6P1FiU4Z8lLvzqX2XJbqto6LXS
	sETmCjP9MjRLV7idGLTHDruivQ9acouOkBYosgofqqcaCfLkv+WFkc/k7NDCzEWhsQAx
	RMLIhyW5X1uUOI6QvY6yL3VLDpiKZl9gZnDD8KK5U17LAEfPsKxNPqLBZlWGcel/sOZl
	ahzxK5NLKeSQO3cyXnHlSl4pO82RkqQq+QUdVgaIPXX9nZ/0Lj39Br0ys5DAjhlgWHEa
	baS0gBQeyaVZmXli/MzEY91zIebi+8xgOAYTQAYsB16/RynNTVow1tavQE7WF0Af12ii
	rglw==
X-Received: by 10.194.63.229 with SMTP id j5mr8944218wjs.23.1418235083253;
	Wed, 10 Dec 2014 10:11:23 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id pl1sm7287299wic.16.2014.12.10.10.11.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:22 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:20 +0100
Message-ID: <20141210181120.26400.75416.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 18/27] sg-run-job: recipes for the kernbench jobs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Recipes are defined for prepping and running kernbench
on the host and on Debian PV and HVM guests.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 sg-run-job |   29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/sg-run-job b/sg-run-job
index 81c2040..32c94db 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -352,6 +352,35 @@ proc run-job/bench-unixbench-hvm {} {
     bench-unixbench-guest debianhvm
 }
 
+proc bench-kernbench-run {args} {
+    run-ts . = ts-kernbench-build  + host $args
+    run-ts . = ts-kernbench-run    + host $args
+    run-ts . = ts-kernbench-reslts + host $args
+}
+
+proc bench-kernbench-host {} {
+    bench-kernbench-run
+}
+
+proc bench-kernbench-guest {g} {
+    bench-kernbench-run $g
+    run-ts . = ts-guest-stop + host $g
+}
+
+proc need-hosts/bench-kernbench-pv {} { return host }
+proc run-job/bench-kernbench-pv {} {
+    run-ts . = ts-debian-install + host
+    run-ts . = ts-debian-fixup   + host debian
+    run-ts . = ts-guest-start    + host debian
+    bench-kernbench-guest debian
+}
+
+proc need-hosts/bench-kernbench-hvm {} { return host }
+proc run-job/bench-kernbench-hvm {} {
+    run-ts . = ts-debian-hvm-install
+    bench-kernbench-guest debianhvm
+}
+
 #---------- builds ----------
 
 proc need-hosts/build {} { return BUILD }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XyljS-0006VL-1h; Wed, 10 Dec 2014 18:11:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyljR-0006US-6a
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:25 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	CF/61-02953-CCC88845; Wed, 10 Dec 2014 18:11:24 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418235083!14283419!1
X-Originating-IP: [209.85.212.181]
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 6080 invoked from network); 10 Dec 2014 18:11:23 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:23 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so6090839wiv.8
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=3pTstSETxDJ3slELCC+ePQf0PXo7BGXs7JPLzMPG0Ps=;
	b=MJiajtTB4o4KvR9BSJqDjabrEynOopoAOYf+Q5Ll6P1FiU4Z8lLvzqX2XJbqto6LXS
	sETmCjP9MjRLV7idGLTHDruivQ9acouOkBYosgofqqcaCfLkv+WFkc/k7NDCzEWhsQAx
	RMLIhyW5X1uUOI6QvY6yL3VLDpiKZl9gZnDD8KK5U17LAEfPsKxNPqLBZlWGcel/sOZl
	ahzxK5NLKeSQO3cyXnHlSl4pO82RkqQq+QUdVgaIPXX9nZ/0Lj39Br0ys5DAjhlgWHEa
	baS0gBQeyaVZmXli/MzEY91zIebi+8xgOAYTQAYsB16/RynNTVow1tavQE7WF0Af12ii
	rglw==
X-Received: by 10.194.63.229 with SMTP id j5mr8944218wjs.23.1418235083253;
	Wed, 10 Dec 2014 10:11:23 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id pl1sm7287299wic.16.2014.12.10.10.11.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:22 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:20 +0100
Message-ID: <20141210181120.26400.75416.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 18/27] sg-run-job: recipes for the kernbench jobs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Recipes are defined for prepping and running kernbench
on the host and on Debian PV and HVM guests.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 sg-run-job |   29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/sg-run-job b/sg-run-job
index 81c2040..32c94db 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -352,6 +352,35 @@ proc run-job/bench-unixbench-hvm {} {
     bench-unixbench-guest debianhvm
 }
 
+proc bench-kernbench-run {args} {
+    run-ts . = ts-kernbench-build  + host $args
+    run-ts . = ts-kernbench-run    + host $args
+    run-ts . = ts-kernbench-reslts + host $args
+}
+
+proc bench-kernbench-host {} {
+    bench-kernbench-run
+}
+
+proc bench-kernbench-guest {g} {
+    bench-kernbench-run $g
+    run-ts . = ts-guest-stop + host $g
+}
+
+proc need-hosts/bench-kernbench-pv {} { return host }
+proc run-job/bench-kernbench-pv {} {
+    run-ts . = ts-debian-install + host
+    run-ts . = ts-debian-fixup   + host debian
+    run-ts . = ts-guest-start    + host debian
+    bench-kernbench-guest debian
+}
+
+proc need-hosts/bench-kernbench-hvm {} { return host }
+proc run-job/bench-kernbench-hvm {} {
+    run-ts . = ts-debian-hvm-install
+    bench-kernbench-guest debianhvm
+}
+
 #---------- builds ----------
 
 proc need-hosts/build {} { return BUILD }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylja-0006cV-N0; Wed, 10 Dec 2014 18:11:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyljY-0006aY-Od
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:32 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	39/4E-18267-4DC88845; Wed, 10 Dec 2014 18:11:32 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418235091!12442427!1
X-Originating-IP: [209.85.212.174]
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 22831 invoked from network); 10 Dec 2014 18:11:31 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:31 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so12128697wiw.1
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=P9OR8RAPgsptUGqw3X/vjmjEMWfhEh562NlkbDQ9ZHs=;
	b=kf3yybhJrmigHVsH9oyS30Db8AbFRM/L+CQXXiz9R6idqjBa7Xb1BG/nah28LvTArl
	oXZ8SthAVnpxED4VFkyRLlC6wHh2MLVtNjITy+BVu1RJzqDaR3Fy364JEH4SjSCE1Ya+
	pQ8fgyqyIGJBd0cmwNcDwnZcmJ4gKF//faNQY8gNNMKCxJwtPEOCGO2K6PU0CnF2hJ4q
	WB2HFt+XARSpSfxR9to2CvPC/iBPan/mBq+rnEqBS7Ym8vVN1nXh1VtX51RFObN28EJD
	pAacpVEJsM82HVISw1qtT9Ihxwmc8AZZ5Y6BduSDClAHRb1pQzpvDIRo2RgpZWlNe2Fa
	wq6Q==
X-Received: by 10.194.175.69 with SMTP id by5mr8961752wjc.32.1418235091251;
	Wed, 10 Dec 2014 10:11:31 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id d5sm6808544wjb.34.2014.12.10.10.11.29
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:30 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:28 +0100
Message-ID: <20141210181128.26400.92702.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 19/27] make-bench-flight: create kernbench jobs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 make-bench-flight |   55 ++++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 42 insertions(+), 13 deletions(-)

diff --git a/make-bench-flight b/make-bench-flight
index cdb22ff..125f244 100755
--- a/make-bench-flight
+++ b/make-bench-flight
@@ -56,8 +56,10 @@ test_matrix_branch_filter_callback () {
 }
 
 do_unixbench_tests () {
-  gvcpus=$1
-  gmem=$2
+  gt=$1
+  sched=$2
+  gvcpus=$3
+  gmem=$4
 
   # x86_64 only (for now)
   if [ $xenarch != amd64 ]; then
@@ -73,20 +75,47 @@ do_unixbench_tests () {
   if [ $gvcpus -ge 2 ];then params="-c $(($gvcpus/2))"; fi
   params="$params -c $gvcpus -c $(($gvcpus*2)) -i 6"
 
-  for gt in pv hvm; do
-    for sched in credit credit2; do
-      job_create_test \
-              bench-unixbench-$xenarch-$sched-$gt$gvcpus_suffix$gmem_suffix \
-              bench-unixbench-$gt xl $xenarch $dom0arch $gvcpus_runvars $gmem_runvars \
-              xen_boot_append="sched=$sched" unixbench_params="$params" $debian_runvars \
-              bios=seabios debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
-              all_hostflags=$most_hostflags
-    done
-  done
+  job_create_test \
+          bench-unixbench-$xenarch-$sched-$gt$gvcpus_suffix$gmem_suffix \
+          bench-unixbench-$gt xl $xenarch $dom0arch $gvcpus_runvars $gmem_runvars \
+          xen_boot_append="sched=$sched" unixbench_params="$params" $debian_runvars \
+          bios=seabios debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
+          all_hostflags=$most_hostflags
+}
+
+do_kernbench_tests () {
+  gt=$1
+  sched=$2
+  gvcpus=$3
+  gmem=$4
+
+  # x86_64 only (for now)
+  if [ $xenarch != amd64 ]; then
+    return
+  fi
+  # "homogeneous" tests only (for now)
+  if [ $xenarch != $dom0arch ]; then
+    return
+  fi
+
+  gvcpus_runvars=guests_vcpus=$gvcpus; gvcpus_suffix=-${gvcpus}vcpus
+  gmem_runvars=guests_memory=$gmem; gmem_suffix=-${gmem}ram
+
+  job_create_test \
+          bench-kernbench-$xenarch-$sched-$gt$gvcpus_suffix$gmem_suffix \
+          bench-kernbench-$gt xl $xenarch $dom0arch $gvcpus_runvars $gmem_runvars \
+          xen_boot_append="sched=$sched" kernbench_params="-n 4" $debian_runvars \
+          bios=seabios debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
+          all_hostflags=$most_hostflags
 }
 
 test_matrix_do_one () {
-  do_unixbench_tests 4 4096 # 4 vcpus, 4GB RAM
+  for s in credit credit2; do
+    for t in pv hvm; do
+      do_unixbench_tests $t $s 4 4096 # 4 vcpus, 4GB RAM
+      do_kernbench_tests $t $s 4 4096
+    done
+  done
 }
 
 test_matrix_iterate


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylja-0006cV-N0; Wed, 10 Dec 2014 18:11:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XyljY-0006aY-Od
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:32 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	39/4E-18267-4DC88845; Wed, 10 Dec 2014 18:11:32 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418235091!12442427!1
X-Originating-IP: [209.85.212.174]
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 22831 invoked from network); 10 Dec 2014 18:11:31 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:31 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so12128697wiw.1
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=P9OR8RAPgsptUGqw3X/vjmjEMWfhEh562NlkbDQ9ZHs=;
	b=kf3yybhJrmigHVsH9oyS30Db8AbFRM/L+CQXXiz9R6idqjBa7Xb1BG/nah28LvTArl
	oXZ8SthAVnpxED4VFkyRLlC6wHh2MLVtNjITy+BVu1RJzqDaR3Fy364JEH4SjSCE1Ya+
	pQ8fgyqyIGJBd0cmwNcDwnZcmJ4gKF//faNQY8gNNMKCxJwtPEOCGO2K6PU0CnF2hJ4q
	WB2HFt+XARSpSfxR9to2CvPC/iBPan/mBq+rnEqBS7Ym8vVN1nXh1VtX51RFObN28EJD
	pAacpVEJsM82HVISw1qtT9Ihxwmc8AZZ5Y6BduSDClAHRb1pQzpvDIRo2RgpZWlNe2Fa
	wq6Q==
X-Received: by 10.194.175.69 with SMTP id by5mr8961752wjc.32.1418235091251;
	Wed, 10 Dec 2014 10:11:31 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id d5sm6808544wjb.34.2014.12.10.10.11.29
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:30 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:28 +0100
Message-ID: <20141210181128.26400.92702.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 19/27] make-bench-flight: create kernbench jobs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 make-bench-flight |   55 ++++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 42 insertions(+), 13 deletions(-)

diff --git a/make-bench-flight b/make-bench-flight
index cdb22ff..125f244 100755
--- a/make-bench-flight
+++ b/make-bench-flight
@@ -56,8 +56,10 @@ test_matrix_branch_filter_callback () {
 }
 
 do_unixbench_tests () {
-  gvcpus=$1
-  gmem=$2
+  gt=$1
+  sched=$2
+  gvcpus=$3
+  gmem=$4
 
   # x86_64 only (for now)
   if [ $xenarch != amd64 ]; then
@@ -73,20 +75,47 @@ do_unixbench_tests () {
   if [ $gvcpus -ge 2 ];then params="-c $(($gvcpus/2))"; fi
   params="$params -c $gvcpus -c $(($gvcpus*2)) -i 6"
 
-  for gt in pv hvm; do
-    for sched in credit credit2; do
-      job_create_test \
-              bench-unixbench-$xenarch-$sched-$gt$gvcpus_suffix$gmem_suffix \
-              bench-unixbench-$gt xl $xenarch $dom0arch $gvcpus_runvars $gmem_runvars \
-              xen_boot_append="sched=$sched" unixbench_params="$params" $debian_runvars \
-              bios=seabios debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
-              all_hostflags=$most_hostflags
-    done
-  done
+  job_create_test \
+          bench-unixbench-$xenarch-$sched-$gt$gvcpus_suffix$gmem_suffix \
+          bench-unixbench-$gt xl $xenarch $dom0arch $gvcpus_runvars $gmem_runvars \
+          xen_boot_append="sched=$sched" unixbench_params="$params" $debian_runvars \
+          bios=seabios debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
+          all_hostflags=$most_hostflags
+}
+
+do_kernbench_tests () {
+  gt=$1
+  sched=$2
+  gvcpus=$3
+  gmem=$4
+
+  # x86_64 only (for now)
+  if [ $xenarch != amd64 ]; then
+    return
+  fi
+  # "homogeneous" tests only (for now)
+  if [ $xenarch != $dom0arch ]; then
+    return
+  fi
+
+  gvcpus_runvars=guests_vcpus=$gvcpus; gvcpus_suffix=-${gvcpus}vcpus
+  gmem_runvars=guests_memory=$gmem; gmem_suffix=-${gmem}ram
+
+  job_create_test \
+          bench-kernbench-$xenarch-$sched-$gt$gvcpus_suffix$gmem_suffix \
+          bench-kernbench-$gt xl $xenarch $dom0arch $gvcpus_runvars $gmem_runvars \
+          xen_boot_append="sched=$sched" kernbench_params="-n 4" $debian_runvars \
+          bios=seabios debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
+          all_hostflags=$most_hostflags
 }
 
 test_matrix_do_one () {
-  do_unixbench_tests 4 4096 # 4 vcpus, 4GB RAM
+  for s in credit credit2; do
+    for t in pv hvm; do
+      do_unixbench_tests $t $s 4 4096 # 4 vcpus, 4GB RAM
+      do_kernbench_tests $t $s 4 4096
+    done
+  done
 }
 
 test_matrix_iterate


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylji-0006jX-43; Wed, 10 Dec 2014 18:11:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xyljh-0006iQ-9D
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:41 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	19/E4-22777-CDC88845; Wed, 10 Dec 2014 18:11:40 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418235099!7248532!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27446 invoked from network); 10 Dec 2014 18:11:39 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:39 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so14168057wib.5
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=4U5GyVFMlSJ5MDaO6Nnv76JSGOBYTi3HECXiSq16Fps=;
	b=LGalG5FtDYzioE7szedsGPOyo0410iANrB73460OC/syZxnfszNddoeCn4yxTWC3yo
	fEE/A5MqSmGgZtGtdfqDqf7hPu5gttPxnK9jQbWX4G20ONUxOIdvBaFDbTXSjUktlP6z
	nzDEGH35hPCCr8zCNEU2CDorRuXHhOJFMt0GqN9hLdhkhxkaPCDBjcqEOU5y6PbXAdUt
	9Yndz/h34yZvOZJIXa1uUa2WEsOI0l0al1xdBjJ5RzOrsKDtNHvLJrl6EgtrxYP5WsJP
	4udUqHSBkqn8oamNjEEIQU5Z/5/g6L+x9DoNNHT3abhSddEplLu4NFcSf9IhOnRszde9
	itIg==
X-Received: by 10.194.250.105 with SMTP id zb9mr8825833wjc.123.1418235099418; 
	Wed, 10 Dec 2014 10:11:39 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id gi5sm6815080wjd.26.2014.12.10.10.11.37
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:38 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:36 +0100
Message-ID: <20141210181136.26400.49231.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 20/27] Osstest/TestSupport.pm: read hosts'
 hardware characteristics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

if defined, in the form of host properties. In standalone
mode, that should happen via the config file.

Methods are introduced to read those host properties or,
if they are not defined, to fetch the information by
querying the host directly.

The host properties always take precedence. This means
that, if they're defined, no command is run on the host,
and the values stored in the properties are used.

This commit also introduces a simple bash script that,
if run on the host, retrieves and prints such host
hardware properties, for convenience and/or testing.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm |   77 +++++++++++++++++++++++++++++++++++++++++++++++-
 README                 |   15 +++++++++
 mg-host-hw-specs       |   35 ++++++++++++++++++++++
 3 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100755 mg-host-hw-specs

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 7cc5be6..251668a 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -58,7 +58,7 @@ BEGIN {
                       target_put_guest_image target_editfile
                       target_editfile_root target_file_exists
                       target_catfile_stash target_catfile_root_stash
-                      target_run_apt
+                      target_file_contains target_run_apt
                       target_install_packages target_install_packages_norec
                       target_jobdir target_extract_jobdistpath_subdir
                       target_extract_jobdistpath target_guest_lv_name
@@ -67,6 +67,7 @@ BEGIN {
                       contents_make_cpio file_simple_write_contents
 
                       selecthost get_hostflags get_host_property
+                      get_host_cpus get_host_numanodes get_host_memory
                       get_host_native_linux_console
                       power_state power_cycle power_cycle_time
                       serial_fetch_logs
@@ -519,6 +520,15 @@ sub target_file_exists ($$) {
     die "$rfile $out ?";
 }
 
+sub target_file_contains ($$$) {
+  my ($ho,$rfile,$filecont) = @_;
+  return 0 unless target_file_exists($ho,$rfile);
+  my $out= target_cmd_output($ho, "grep $filecont $rfile");
+  return 1 if ($out ne "");
+  return 0 if ($out eq "");
+  die "$rfile $filecont $out ?";
+}
+
 sub teditfileex {
     my $user= shift @_;
     my $code= pop @_;
@@ -866,6 +876,11 @@ sub selecthost ($) {
     }
     $ho->{Ip}= $ho->{IpStatic};
 
+    #----- HW specs -----
+    $ho->{Cpus} = get_host_property($ho,'cpus');
+    $ho->{Memory} = get_host_property($ho,'memory');
+    $ho->{Nodes} = get_host_property($ho,'nodes');
+
     #----- tftp -----
 
     my $tftpscope = get_host_property($ho, 'TftpScope', $c{TftpDefaultScope});
@@ -937,6 +952,66 @@ sub get_host_method_object ($$$) {
     return $mo;
 }
 
+sub get_host_cpus ($) {
+    my ($ho) = @_;
+
+    # Let's first try if there's an host property defined;
+    # if no, we'll "ask" the host directly.
+    my $cpus= get_host_property($ho,'cpus',undef);
+    return $cpus if defined $cpus;
+
+    # Is the host running Dom0 or baremetal?
+    if (target_file_contains($ho,"/proc/xen/capabilities","control_d")) {
+        $cpus= target_cmd_output_root($ho,
+            "xl info | grep ^nr_cpus | awk '{print \$3}'");
+    } else {
+        $cpus= target_cmd_output_root($ho,
+            "cat /proc/cpuinfo | grep '^processor' | wc -l");
+    }
+
+    return $cpus;
+}
+
+sub get_host_numanodes ($) {
+    my ($ho) = @_;
+
+    # Let's first try if there's an host property defined;
+    # if no, we'll "ask" the host directly.
+    my $nodes= get_host_property($ho,'nodes',undef);
+    return $nodes if defined $nodes;
+
+    # Is the host running Dom0 or baremetal?
+    if (target_file_contains($ho,"/proc/xen/capabilities","control_d")) {
+        $nodes= target_cmd_output_root($ho,
+            "xl info | grep ^nr_nodes | awk '{print \$3}'");
+    } else {
+        $nodes= target_cmd_output_root($ho,
+            "which numactl && numactl --hardware | grep ^available: | awk '{print \$2}'");
+    }
+
+    return $nodes;
+}
+
+sub get_host_memory ($) {
+    my ($ho) = @_;
+
+    # Let's first try if there's an host property defined;
+    # if no, we'll "ask" the host directly.
+    my $mem= get_host_property($ho,'memory',undef);
+    return $mem if defined $mem;
+
+    # Is the host running Dom0 or baremetal?
+    if (target_file_contains($ho,"/proc/xen/capabilities","control_d")) {
+        $mem= target_cmd_output_root($ho,
+            "xl info | grep ^total_memory | awk '{print \$3}'");
+    } else {
+        $mem= target_cmd_output_root($ho,
+            "free -m | grep ^Mem: | awk '{print \$2}'");
+    }
+
+    return $mem;
+}
+
 #---------- stashed files ----------
 
 sub open_unique_stashfile ($) {
diff --git a/README b/README
index 45d1498..b3880b5 100644
--- a/README
+++ b/README
@@ -343,6 +343,21 @@ HostProp_<testbox>_TftpScope
    Defines the Tftp scope (i.e. subnet) where this host resides. See
    "TftpFoo_<scope> and TftpFoo" below.
 
+HostProp_<testbox>_Cpus
+   Tells how many physical CPUs the testbox has. If this is defined,
+   no further investigation is performed to figure out such information
+   and the value provided here is considered reliable and consumed.
+
+HostProp_<testbox>_Memory
+   Tells how much physical memory the testbox has. If this is defined,
+   no further investigation is performed to figure out such information
+   and the value provided here is considered reliable and consumed.
+
+HostProp_<testbox>_Nodes
+   Tells how many NUMA nodes the testbox has. If this is defined,
+   no further investigation is performed to figure out such information
+   and the value provided here is considered reliable and consumed.
+
 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
diff --git a/mg-host-hw-specs b/mg-host-hw-specs
new file mode 100755
index 0000000..a47d72d
--- /dev/null
+++ b/mg-host-hw-specs
@@ -0,0 +1,35 @@
+#!/bin/bash
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+set -e
+
+# Is the host running Dom0 or baremetal?
+if [[ -e /proc/xen/capabilities ]] && \
+   [[ `grep ^control_d$ /proc/xen/capabilities` == "control_d" ]]; then
+  cpus=`xl info | grep ^nr_cpus | awk '{print \$3}'`
+  memory=`xl info | grep ^total_memory | awk '{print \$3}'`
+  nodes=`xl info | grep ^nr_nodes | awk '{print \$3}'`
+else
+  cpus=`cat /proc/cpuinfo | grep "^processor" | wc -l`
+  memory=`free -m | grep ^Mem: | awk '{print $2}'`
+  nodes="?"
+  if [[ `which numactl` != "" ]] && [ -x `which numactl` ]; then
+    nodes=`numactl --hardware | grep ^available: | awk '{print $2}'`
+  fi
+fi
+
+echo >&2 "cpus=$cpus / memory=$memory / nodes=$nodes"


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:11:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylji-0006jX-43; Wed, 10 Dec 2014 18:11:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xyljh-0006iQ-9D
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:41 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	19/E4-22777-CDC88845; Wed, 10 Dec 2014 18:11:40 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418235099!7248532!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27446 invoked from network); 10 Dec 2014 18:11:39 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:39 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so14168057wib.5
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=4U5GyVFMlSJ5MDaO6Nnv76JSGOBYTi3HECXiSq16Fps=;
	b=LGalG5FtDYzioE7szedsGPOyo0410iANrB73460OC/syZxnfszNddoeCn4yxTWC3yo
	fEE/A5MqSmGgZtGtdfqDqf7hPu5gttPxnK9jQbWX4G20ONUxOIdvBaFDbTXSjUktlP6z
	nzDEGH35hPCCr8zCNEU2CDorRuXHhOJFMt0GqN9hLdhkhxkaPCDBjcqEOU5y6PbXAdUt
	9Yndz/h34yZvOZJIXa1uUa2WEsOI0l0al1xdBjJ5RzOrsKDtNHvLJrl6EgtrxYP5WsJP
	4udUqHSBkqn8oamNjEEIQU5Z/5/g6L+x9DoNNHT3abhSddEplLu4NFcSf9IhOnRszde9
	itIg==
X-Received: by 10.194.250.105 with SMTP id zb9mr8825833wjc.123.1418235099418; 
	Wed, 10 Dec 2014 10:11:39 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id gi5sm6815080wjd.26.2014.12.10.10.11.37
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:38 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:36 +0100
Message-ID: <20141210181136.26400.49231.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 20/27] Osstest/TestSupport.pm: read hosts'
 hardware characteristics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

if defined, in the form of host properties. In standalone
mode, that should happen via the config file.

Methods are introduced to read those host properties or,
if they are not defined, to fetch the information by
querying the host directly.

The host properties always take precedence. This means
that, if they're defined, no command is run on the host,
and the values stored in the properties are used.

This commit also introduces a simple bash script that,
if run on the host, retrieves and prints such host
hardware properties, for convenience and/or testing.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/TestSupport.pm |   77 +++++++++++++++++++++++++++++++++++++++++++++++-
 README                 |   15 +++++++++
 mg-host-hw-specs       |   35 ++++++++++++++++++++++
 3 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100755 mg-host-hw-specs

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 7cc5be6..251668a 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -58,7 +58,7 @@ BEGIN {
                       target_put_guest_image target_editfile
                       target_editfile_root target_file_exists
                       target_catfile_stash target_catfile_root_stash
-                      target_run_apt
+                      target_file_contains target_run_apt
                       target_install_packages target_install_packages_norec
                       target_jobdir target_extract_jobdistpath_subdir
                       target_extract_jobdistpath target_guest_lv_name
@@ -67,6 +67,7 @@ BEGIN {
                       contents_make_cpio file_simple_write_contents
 
                       selecthost get_hostflags get_host_property
+                      get_host_cpus get_host_numanodes get_host_memory
                       get_host_native_linux_console
                       power_state power_cycle power_cycle_time
                       serial_fetch_logs
@@ -519,6 +520,15 @@ sub target_file_exists ($$) {
     die "$rfile $out ?";
 }
 
+sub target_file_contains ($$$) {
+  my ($ho,$rfile,$filecont) = @_;
+  return 0 unless target_file_exists($ho,$rfile);
+  my $out= target_cmd_output($ho, "grep $filecont $rfile");
+  return 1 if ($out ne "");
+  return 0 if ($out eq "");
+  die "$rfile $filecont $out ?";
+}
+
 sub teditfileex {
     my $user= shift @_;
     my $code= pop @_;
@@ -866,6 +876,11 @@ sub selecthost ($) {
     }
     $ho->{Ip}= $ho->{IpStatic};
 
+    #----- HW specs -----
+    $ho->{Cpus} = get_host_property($ho,'cpus');
+    $ho->{Memory} = get_host_property($ho,'memory');
+    $ho->{Nodes} = get_host_property($ho,'nodes');
+
     #----- tftp -----
 
     my $tftpscope = get_host_property($ho, 'TftpScope', $c{TftpDefaultScope});
@@ -937,6 +952,66 @@ sub get_host_method_object ($$$) {
     return $mo;
 }
 
+sub get_host_cpus ($) {
+    my ($ho) = @_;
+
+    # Let's first try if there's an host property defined;
+    # if no, we'll "ask" the host directly.
+    my $cpus= get_host_property($ho,'cpus',undef);
+    return $cpus if defined $cpus;
+
+    # Is the host running Dom0 or baremetal?
+    if (target_file_contains($ho,"/proc/xen/capabilities","control_d")) {
+        $cpus= target_cmd_output_root($ho,
+            "xl info | grep ^nr_cpus | awk '{print \$3}'");
+    } else {
+        $cpus= target_cmd_output_root($ho,
+            "cat /proc/cpuinfo | grep '^processor' | wc -l");
+    }
+
+    return $cpus;
+}
+
+sub get_host_numanodes ($) {
+    my ($ho) = @_;
+
+    # Let's first try if there's an host property defined;
+    # if no, we'll "ask" the host directly.
+    my $nodes= get_host_property($ho,'nodes',undef);
+    return $nodes if defined $nodes;
+
+    # Is the host running Dom0 or baremetal?
+    if (target_file_contains($ho,"/proc/xen/capabilities","control_d")) {
+        $nodes= target_cmd_output_root($ho,
+            "xl info | grep ^nr_nodes | awk '{print \$3}'");
+    } else {
+        $nodes= target_cmd_output_root($ho,
+            "which numactl && numactl --hardware | grep ^available: | awk '{print \$2}'");
+    }
+
+    return $nodes;
+}
+
+sub get_host_memory ($) {
+    my ($ho) = @_;
+
+    # Let's first try if there's an host property defined;
+    # if no, we'll "ask" the host directly.
+    my $mem= get_host_property($ho,'memory',undef);
+    return $mem if defined $mem;
+
+    # Is the host running Dom0 or baremetal?
+    if (target_file_contains($ho,"/proc/xen/capabilities","control_d")) {
+        $mem= target_cmd_output_root($ho,
+            "xl info | grep ^total_memory | awk '{print \$3}'");
+    } else {
+        $mem= target_cmd_output_root($ho,
+            "free -m | grep ^Mem: | awk '{print \$2}'");
+    }
+
+    return $mem;
+}
+
 #---------- stashed files ----------
 
 sub open_unique_stashfile ($) {
diff --git a/README b/README
index 45d1498..b3880b5 100644
--- a/README
+++ b/README
@@ -343,6 +343,21 @@ HostProp_<testbox>_TftpScope
    Defines the Tftp scope (i.e. subnet) where this host resides. See
    "TftpFoo_<scope> and TftpFoo" below.
 
+HostProp_<testbox>_Cpus
+   Tells how many physical CPUs the testbox has. If this is defined,
+   no further investigation is performed to figure out such information
+   and the value provided here is considered reliable and consumed.
+
+HostProp_<testbox>_Memory
+   Tells how much physical memory the testbox has. If this is defined,
+   no further investigation is performed to figure out such information
+   and the value provided here is considered reliable and consumed.
+
+HostProp_<testbox>_Nodes
+   Tells how many NUMA nodes the testbox has. If this is defined,
+   no further investigation is performed to figure out such information
+   and the value provided here is considered reliable and consumed.
+
 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
diff --git a/mg-host-hw-specs b/mg-host-hw-specs
new file mode 100755
index 0000000..a47d72d
--- /dev/null
+++ b/mg-host-hw-specs
@@ -0,0 +1,35 @@
+#!/bin/bash
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+set -e
+
+# Is the host running Dom0 or baremetal?
+if [[ -e /proc/xen/capabilities ]] && \
+   [[ `grep ^control_d$ /proc/xen/capabilities` == "control_d" ]]; then
+  cpus=`xl info | grep ^nr_cpus | awk '{print \$3}'`
+  memory=`xl info | grep ^total_memory | awk '{print \$3}'`
+  nodes=`xl info | grep ^nr_nodes | awk '{print \$3}'`
+else
+  cpus=`cat /proc/cpuinfo | grep "^processor" | wc -l`
+  memory=`free -m | grep ^Mem: | awk '{print $2}'`
+  nodes="?"
+  if [[ `which numactl` != "" ]] && [ -x `which numactl` ]; then
+    nodes=`numactl --hardware | grep ^available: | awk '{print $2}'`
+  fi
+fi
+
+echo >&2 "cpus=$cpus / memory=$memory / nodes=$nodes"


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1Xyljq-0006tA-K8; Wed, 10 Dec 2014 18:11:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xyljp-0006pt-Fd
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:49 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	D6/0B-27623-4EC88845; Wed, 10 Dec 2014 18:11:48 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418235107!12442480!1
X-Originating-IP: [209.85.212.175]
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 24362 invoked from network); 10 Dec 2014 18:11:48 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:48 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so12143521wiw.2
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=a085/IkkX41Ra2gDREpTIoe1DsxYPF4Bx4KCKMoUePs=;
	b=TRRiDDZrjL4ig7el3rtY078nIviIEHKVG0cc0m3jt/CkTiHe+4WDOeioqa/CAvjAbY
	suJDcsY0Uk8fvjpr+i/ng26yiLAdoIYp6kYHU5/qoCM3P5p7mRUC3XB+L4vMhADajlq+
	qypSktHwyAg5BP0CwjqVqr7YEnyawWhsSzS3f8ZxfSZ+V52QdXEsBCwz+wB8gf4vjIBm
	nFAsP5AsUx/rU6gapUJ82S8MO8mKHZiSX77JfM/+hmElEGAMSmPCeEgNQENWmZMUPGGq
	W13ju+DuKIAKQLrInaGvEEDbOORITM5AfPPMMpfqLW6QE0YiimKMvUNE1VYCclUlS7hl
	p8hQ==
X-Received: by 10.180.80.34 with SMTP id o2mr15581863wix.53.1418235107714;
	Wed, 10 Dec 2014 10:11:47 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id m6sm18889254wix.10.2014.12.10.10.11.46
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:46 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:44 +0100
Message-ID: <20141210181144.26400.7042.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 21/27] ts-bench-hostcmp-guest-prep: new 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

From: Dario Faggioli <raistlin@linux.it>

the goal is to run a benchmark both in a guest and
on baremetal, to investigate the performances loss
due to the virtualization overhead.

In order to help accomplishing this, the new script
introduced by this commit modifies a guest's config
file in order for it to have the same number of
vcpus and (almost) the same amount of memory of the
underlying host. This is done under the assumption
that the benchmark will (or has been already) run
on the host too.

It is possible to make the guest have less vcpus
than the host has pcpus, and less memory than the
host, by defining two specific runvars. In fact, in
case of really "beefy" hosts, one may not want to
run the benchmark in an unrealistically large guest.
Of course, specific measures to also limit the host
resources, when running the benchmark on it, should
be taken, if comparing apples to apples is important.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-bench-hostcmp-guest-prep |   87 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 87 insertions(+)
 create mode 100755 ts-bench-hostcmp-guest-prep

diff --git a/ts-bench-hostcmp-guest-prep b/ts-bench-hostcmp-guest-prep
new file mode 100755
index 0000000..ffde981
--- /dev/null
+++ b/ts-bench-hostcmp-guest-prep
@@ -0,0 +1,87 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+$gn ||= 'debianhvm';
+
+our ($ho,$gho) = ts_get_host_guest($whhost,$gn);
+our $toolstack= toolstack()->{Command};
+
+# We want the guest to have:
+#  - the same number of vcpus than the host has pcpus
+#  - (almost) the same amount of memory the host has
+#
+# For both vcpus and memory, a maximum can be specified via
+# runvars.
+sub fixup () {
+  our ($hnodes,$hcpus,$hmem);
+  our ($cfgfile,$bcpus,$bmem,$hfreemem);
+
+  $hcpus= get_host_cpus($ho);
+  $hmem= get_host_memory($ho);
+  die unless (defined $hcpus and defined $hmem);
+
+  $hnodes= get_host_numanodes($ho);
+  if (defined $hnodes and $hnodes > 1) {
+    logm("WARNING: the host has $hnodes NUMA nodes. This may spoil results");
+  }
+
+  $bcpus= (!defined($r{'max_bench_cpus'})) ? $hcpus :
+      ($r{'max_bench_cpus'} > $hcpus) ? $hcpus : $r{'max_bench_cpus'};
+  $bmem= (!defined($r{'max_bench_mem'})) ? $hmem :
+      ($r{'max_bench_mem'} > $hmem) ? $hmem : $r{'max_bench_mem'};
+
+  $hfreemem = host_get_free_memory($ho,$toolstack);
+  if ($hfreemem < $bmem) {
+    $bmem= $hfreemem - 1024;
+    logm("WARNING: Not enough free memory. Using $bmem MB");
+  }
+
+  logm("Will run the benchmark with: $bcpus vcpus and $bmem MB RAM");
+
+  $cfgfile= $r{"$gho->{Guest}_cfgpath"};
+  target_editfile_root($ho, $cfgfile, sub {
+      while (<EI>) {
+        s/^vcpus.*/vcpus=$bcpus/;
+        s/^memory.*/memory=$bmem/;
+	print EO or die $!;
+      }
+  });
+}
+
+sub start () {
+  # Start the guest...
+  guest_umount_lv($ho, $gho);
+  my $cmd= toolstack()->{Command}." create ".
+      $r{ $gho->{Guest}.'_'. toolstack()->{CfgPathVar} };
+  target_cmd_root($ho, $cmd, 30);
+  # ...And verify it's up and running
+  guest_checkrunning($ho, $gho) or die "$gho->{Name} not running";
+  guest_await($gho, target_var($gho,'boot_timeout'));
+  guest_check_up($gho);
+}
+
+fixup();
+start();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1Xyljq-0006tA-K8; Wed, 10 Dec 2014 18:11:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xyljp-0006pt-Fd
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:49 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	D6/0B-27623-4EC88845; Wed, 10 Dec 2014 18:11:48 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418235107!12442480!1
X-Originating-IP: [209.85.212.175]
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 24362 invoked from network); 10 Dec 2014 18:11:48 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:48 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so12143521wiw.2
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=a085/IkkX41Ra2gDREpTIoe1DsxYPF4Bx4KCKMoUePs=;
	b=TRRiDDZrjL4ig7el3rtY078nIviIEHKVG0cc0m3jt/CkTiHe+4WDOeioqa/CAvjAbY
	suJDcsY0Uk8fvjpr+i/ng26yiLAdoIYp6kYHU5/qoCM3P5p7mRUC3XB+L4vMhADajlq+
	qypSktHwyAg5BP0CwjqVqr7YEnyawWhsSzS3f8ZxfSZ+V52QdXEsBCwz+wB8gf4vjIBm
	nFAsP5AsUx/rU6gapUJ82S8MO8mKHZiSX77JfM/+hmElEGAMSmPCeEgNQENWmZMUPGGq
	W13ju+DuKIAKQLrInaGvEEDbOORITM5AfPPMMpfqLW6QE0YiimKMvUNE1VYCclUlS7hl
	p8hQ==
X-Received: by 10.180.80.34 with SMTP id o2mr15581863wix.53.1418235107714;
	Wed, 10 Dec 2014 10:11:47 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id m6sm18889254wix.10.2014.12.10.10.11.46
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:46 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:44 +0100
Message-ID: <20141210181144.26400.7042.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 21/27] ts-bench-hostcmp-guest-prep: new 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

From: Dario Faggioli <raistlin@linux.it>

the goal is to run a benchmark both in a guest and
on baremetal, to investigate the performances loss
due to the virtualization overhead.

In order to help accomplishing this, the new script
introduced by this commit modifies a guest's config
file in order for it to have the same number of
vcpus and (almost) the same amount of memory of the
underlying host. This is done under the assumption
that the benchmark will (or has been already) run
on the host too.

It is possible to make the guest have less vcpus
than the host has pcpus, and less memory than the
host, by defining two specific runvars. In fact, in
case of really "beefy" hosts, one may not want to
run the benchmark in an unrealistically large guest.
Of course, specific measures to also limit the host
resources, when running the benchmark on it, should
be taken, if comparing apples to apples is important.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 ts-bench-hostcmp-guest-prep |   87 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 87 insertions(+)
 create mode 100755 ts-bench-hostcmp-guest-prep

diff --git a/ts-bench-hostcmp-guest-prep b/ts-bench-hostcmp-guest-prep
new file mode 100755
index 0000000..ffde981
--- /dev/null
+++ b/ts-bench-hostcmp-guest-prep
@@ -0,0 +1,87 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost,$gn) = @ARGV;
+$whhost ||= 'host';
+$gn ||= 'debianhvm';
+
+our ($ho,$gho) = ts_get_host_guest($whhost,$gn);
+our $toolstack= toolstack()->{Command};
+
+# We want the guest to have:
+#  - the same number of vcpus than the host has pcpus
+#  - (almost) the same amount of memory the host has
+#
+# For both vcpus and memory, a maximum can be specified via
+# runvars.
+sub fixup () {
+  our ($hnodes,$hcpus,$hmem);
+  our ($cfgfile,$bcpus,$bmem,$hfreemem);
+
+  $hcpus= get_host_cpus($ho);
+  $hmem= get_host_memory($ho);
+  die unless (defined $hcpus and defined $hmem);
+
+  $hnodes= get_host_numanodes($ho);
+  if (defined $hnodes and $hnodes > 1) {
+    logm("WARNING: the host has $hnodes NUMA nodes. This may spoil results");
+  }
+
+  $bcpus= (!defined($r{'max_bench_cpus'})) ? $hcpus :
+      ($r{'max_bench_cpus'} > $hcpus) ? $hcpus : $r{'max_bench_cpus'};
+  $bmem= (!defined($r{'max_bench_mem'})) ? $hmem :
+      ($r{'max_bench_mem'} > $hmem) ? $hmem : $r{'max_bench_mem'};
+
+  $hfreemem = host_get_free_memory($ho,$toolstack);
+  if ($hfreemem < $bmem) {
+    $bmem= $hfreemem - 1024;
+    logm("WARNING: Not enough free memory. Using $bmem MB");
+  }
+
+  logm("Will run the benchmark with: $bcpus vcpus and $bmem MB RAM");
+
+  $cfgfile= $r{"$gho->{Guest}_cfgpath"};
+  target_editfile_root($ho, $cfgfile, sub {
+      while (<EI>) {
+        s/^vcpus.*/vcpus=$bcpus/;
+        s/^memory.*/memory=$bmem/;
+	print EO or die $!;
+      }
+  });
+}
+
+sub start () {
+  # Start the guest...
+  guest_umount_lv($ho, $gho);
+  my $cmd= toolstack()->{Command}." create ".
+      $r{ $gho->{Guest}.'_'. toolstack()->{CfgPathVar} };
+  target_cmd_root($ho, $cmd, 30);
+  # ...And verify it's up and running
+  guest_checkrunning($ho, $gho) or die "$gho->{Name} not running";
+  guest_await($gho, target_var($gho,'boot_timeout'));
+  guest_check_up($gho);
+}
+
+fixup();
+start();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyljz-00070S-1Q; Wed, 10 Dec 2014 18:11:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xyljx-0006ye-Gx
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:57 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	7A/2B-31453-CEC88845; Wed, 10 Dec 2014 18:11:56 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418235115!12641578!1
X-Originating-IP: [74.125.82.45]
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 7354 invoked from network); 10 Dec 2014 18:11:56 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:56 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so4344217wgh.32
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=CZGzE3LTf+zZY+3kCzpjN6t50P+CvV+9cBeEGfPUWBk=;
	b=t8Y6NDUkFelMI4XQQSF43OgzMTsfaSLRXZb5s408CZjT/DquYfViQRVLs9y+yNmp/v
	gfapLaNDIUzLH/dVMpTuZqIjsNkVEOuhXFSVBsaMQe+I/ev5a2jQb1N6WIBSGiOyAYva
	kL5vIYIH8WDN1YXyVB6PCgKECnNB61ND5NgxLPGCWTBo7HyPaBgWioidugUzbbWBW8mX
	oFoRHqbwcixXWHiRpIsJ1c5DrOTKkphZM0b8Uk6kZ/pVEf43HRpnvG313d6h6ozcUDo3
	3Ni9hHR7heSnG3KVgw4C/6A2ez4wD9XRXPlWQRUj0vREnInzFUzcB74J1lQbGr+mMNIT
	FBEQ==
X-Received: by 10.194.86.165 with SMTP id q5mr9245361wjz.10.1418235115564;
	Wed, 10 Dec 2014 10:11:55 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id wv8sm6800960wjc.44.2014.12.10.10.11.53
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:54 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:52 +0100
Message-ID: <20141210181152.26400.21301.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 22/27] ts-bench-hostcmp-host-prep: new 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

From: Dario Faggioli <raistlin@linux.it>

the goal is to run a benchmark both in a guest and
on baremetal, to investigate the performances loss
due to the virtualization overhead.

In order to help accomplishing this, the new script
introduced by this commit modifies the host's boot
configuration as follows:
 - it makes it boot baremetal Linux, rather than Xen
   and a Dom0 kernel;
 - it limits the host's pcpus and amount of memory
   to the values contained in the specific runvars
   (if defined).

This is done under the assumption that the benchmark
will (or has been already) run on one (or more)
guest(s) too. If the runvars for limiting host's
resources are defined, it is assumed that they will
be (were) defined, and that they will have (had) the
same values, also when prepping the run of the
benchmark in the guest.

The test script only alter the host's boot config;
it is left to the caller to actually reboot the host,
and also to restore the old config, if wanted, after
the benchmark has been run.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Debian.pm          |   17 ++++++++--
 ts-bench-hostcmp-host-prep |   74 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 88 insertions(+), 3 deletions(-)
 create mode 100755 ts-bench-hostcmp-host-prep

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 70afaec..418d9f2 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -32,6 +32,9 @@ BEGIN {
     $VERSION     = 1.00;
     @ISA         = qw(Exporter);
     @EXPORT      = qw(debian_boot_setup
+                      setupboot_uboot
+                      setupboot_grub1
+                      setupboot_grub2
                       %preseed_cmds
                       preseed_base
                       preseed_create
@@ -112,7 +115,7 @@ sub bl_getmenu_open ($$$) {
     return $f;
 }
 
-sub setupboot_uboot ($$$) {
+sub setupboot_uboot ($$$$) {
     my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
     my $bl= { };
 
@@ -194,7 +197,7 @@ END
     return $bl;
 }
 
-sub setupboot_grub1 ($$$) {
+sub setupboot_grub1 ($$$$) {
     my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
     my $bl= { };
 
@@ -274,7 +277,7 @@ sub setupboot_grub1 ($$$) {
     return $bl;
 }
 
-sub setupboot_grub2 ($$$) {
+sub setupboot_grub2 ($$$$) {
     my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
     my $bl= { };
 
@@ -387,6 +390,14 @@ END
                 my $v= $k{$k};
                 $v =~ s/\bquiet\b//;
                 $v =~ s/\b(?:console|xencons)=[0-9A-Za-z,]+//;
+                # Get rid of any host/dom0 resource constraining. Idea is:
+                # (1) in the dom0 case, something like that should be achieved
+                # via Xen boot parameters; (2) in any case, if it is important
+                # to have something like these in Linux's boot cmd line by
+                # default, that should be put into the 'linux_boot_append'
+                # runvar, which won't be affected by this.
+                $v =~ s/\bmaxcpus=[0-9A-Za-z,]+//;
+                $v =~ s/\bmem=[0-9A-Za-z,]+//;
                 $v .= " $xenkopt" if $k eq 'GRUB_CMDLINE_LINUX';
                 print ::EO "$k=\"$v\"\n" or die $!;
             }
diff --git a/ts-bench-hostcmp-host-prep b/ts-bench-hostcmp-host-prep
new file mode 100755
index 0000000..493d948
--- /dev/null
+++ b/ts-bench-hostcmp-host-prep
@@ -0,0 +1,74 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::Debian;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+# We want to boot baremetal Linux on the host,
+# to compare against it.
+sub fixup () {
+  my ($bl,$bootkern);
+  my ($hcpus,$hmem,$hnodes);
+  my ($bcpus,$bmem);
+
+  target_install_packages_norec($ho, "numactl");
+
+  $hcpus= get_host_cpus($ho);
+  $hmem= get_host_memory($ho);
+  die unless (defined $hcpus and defined $hmem);
+
+  $hnodes= get_host_numanodes($ho);
+  if (defined $hnodes and $hnodes > 1) {
+    logm("WARNING: the host has $hnodes NUMA nodes. This may spoil results");
+  }
+
+  $bcpus= (!defined($r{'max_bench_cpus'})) ? $hcpus :
+      ($r{'max_bench_cpus'} > $hcpus) ? $hcpus : $r{'max_bench_cpus'};
+  $bmem= (!defined($r{'max_bench_mem'})) ? $hmem :
+      ($r{'max_bench_mem'} > $hmem) ? $hmem : $r{'max_bench_mem'};
+  die unless (defined $bcpus and defined $bmem);
+
+  logm("Will run the benchmark on host with: $bcpus vcpus and $bmem MB RAM");
+
+  my $kernver= get_runvar('kernel_ver',$r{'kernbuildjob'});
+  my $kopt= "maxcpus=$bcpus mem=$bmem" . "M";
+
+  if ($ho->{Flags}{'need-uboot-bootscr'}) {
+      $bl= setupboot_uboot($ho,$kernver,undef,$kopt);
+  } elsif ($ho->{Suite} =~ m/lenny/) {
+      $bl= setupboot_grub1($ho,$kernver,undef,$kopt);
+  } else {
+      $bl= setupboot_grub2($ho,$kernver,undef,$kopt);
+  }
+
+  $bootkern= $bl->{PreFinalUpdate}();
+  $bl->{UpdateConfig}($ho);
+
+  $bootkern= $bl->{GetBootKern}();
+  logm("$ho->{Name} will reboot on kernel $bootkern with '$kopt' as options");
+}
+
+fixup();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyljz-00070S-1Q; Wed, 10 Dec 2014 18:11:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xyljx-0006ye-Gx
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:11:57 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	7A/2B-31453-CEC88845; Wed, 10 Dec 2014 18:11:56 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418235115!12641578!1
X-Originating-IP: [74.125.82.45]
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 7354 invoked from network); 10 Dec 2014 18:11:56 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:11:56 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so4344217wgh.32
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:11:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=CZGzE3LTf+zZY+3kCzpjN6t50P+CvV+9cBeEGfPUWBk=;
	b=t8Y6NDUkFelMI4XQQSF43OgzMTsfaSLRXZb5s408CZjT/DquYfViQRVLs9y+yNmp/v
	gfapLaNDIUzLH/dVMpTuZqIjsNkVEOuhXFSVBsaMQe+I/ev5a2jQb1N6WIBSGiOyAYva
	kL5vIYIH8WDN1YXyVB6PCgKECnNB61ND5NgxLPGCWTBo7HyPaBgWioidugUzbbWBW8mX
	oFoRHqbwcixXWHiRpIsJ1c5DrOTKkphZM0b8Uk6kZ/pVEf43HRpnvG313d6h6ozcUDo3
	3Ni9hHR7heSnG3KVgw4C/6A2ez4wD9XRXPlWQRUj0vREnInzFUzcB74J1lQbGr+mMNIT
	FBEQ==
X-Received: by 10.194.86.165 with SMTP id q5mr9245361wjz.10.1418235115564;
	Wed, 10 Dec 2014 10:11:55 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id wv8sm6800960wjc.44.2014.12.10.10.11.53
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:11:54 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:11:52 +0100
Message-ID: <20141210181152.26400.21301.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 22/27] ts-bench-hostcmp-host-prep: new 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

From: Dario Faggioli <raistlin@linux.it>

the goal is to run a benchmark both in a guest and
on baremetal, to investigate the performances loss
due to the virtualization overhead.

In order to help accomplishing this, the new script
introduced by this commit modifies the host's boot
configuration as follows:
 - it makes it boot baremetal Linux, rather than Xen
   and a Dom0 kernel;
 - it limits the host's pcpus and amount of memory
   to the values contained in the specific runvars
   (if defined).

This is done under the assumption that the benchmark
will (or has been already) run on one (or more)
guest(s) too. If the runvars for limiting host's
resources are defined, it is assumed that they will
be (were) defined, and that they will have (had) the
same values, also when prepping the run of the
benchmark in the guest.

The test script only alter the host's boot config;
it is left to the caller to actually reboot the host,
and also to restore the old config, if wanted, after
the benchmark has been run.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Debian.pm          |   17 ++++++++--
 ts-bench-hostcmp-host-prep |   74 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 88 insertions(+), 3 deletions(-)
 create mode 100755 ts-bench-hostcmp-host-prep

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 70afaec..418d9f2 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -32,6 +32,9 @@ BEGIN {
     $VERSION     = 1.00;
     @ISA         = qw(Exporter);
     @EXPORT      = qw(debian_boot_setup
+                      setupboot_uboot
+                      setupboot_grub1
+                      setupboot_grub2
                       %preseed_cmds
                       preseed_base
                       preseed_create
@@ -112,7 +115,7 @@ sub bl_getmenu_open ($$$) {
     return $f;
 }
 
-sub setupboot_uboot ($$$) {
+sub setupboot_uboot ($$$$) {
     my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
     my $bl= { };
 
@@ -194,7 +197,7 @@ END
     return $bl;
 }
 
-sub setupboot_grub1 ($$$) {
+sub setupboot_grub1 ($$$$) {
     my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
     my $bl= { };
 
@@ -274,7 +277,7 @@ sub setupboot_grub1 ($$$) {
     return $bl;
 }
 
-sub setupboot_grub2 ($$$) {
+sub setupboot_grub2 ($$$$) {
     my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
     my $bl= { };
 
@@ -387,6 +390,14 @@ END
                 my $v= $k{$k};
                 $v =~ s/\bquiet\b//;
                 $v =~ s/\b(?:console|xencons)=[0-9A-Za-z,]+//;
+                # Get rid of any host/dom0 resource constraining. Idea is:
+                # (1) in the dom0 case, something like that should be achieved
+                # via Xen boot parameters; (2) in any case, if it is important
+                # to have something like these in Linux's boot cmd line by
+                # default, that should be put into the 'linux_boot_append'
+                # runvar, which won't be affected by this.
+                $v =~ s/\bmaxcpus=[0-9A-Za-z,]+//;
+                $v =~ s/\bmem=[0-9A-Za-z,]+//;
                 $v .= " $xenkopt" if $k eq 'GRUB_CMDLINE_LINUX';
                 print ::EO "$k=\"$v\"\n" or die $!;
             }
diff --git a/ts-bench-hostcmp-host-prep b/ts-bench-hostcmp-host-prep
new file mode 100755
index 0000000..493d948
--- /dev/null
+++ b/ts-bench-hostcmp-host-prep
@@ -0,0 +1,74 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::Debian;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+# We want to boot baremetal Linux on the host,
+# to compare against it.
+sub fixup () {
+  my ($bl,$bootkern);
+  my ($hcpus,$hmem,$hnodes);
+  my ($bcpus,$bmem);
+
+  target_install_packages_norec($ho, "numactl");
+
+  $hcpus= get_host_cpus($ho);
+  $hmem= get_host_memory($ho);
+  die unless (defined $hcpus and defined $hmem);
+
+  $hnodes= get_host_numanodes($ho);
+  if (defined $hnodes and $hnodes > 1) {
+    logm("WARNING: the host has $hnodes NUMA nodes. This may spoil results");
+  }
+
+  $bcpus= (!defined($r{'max_bench_cpus'})) ? $hcpus :
+      ($r{'max_bench_cpus'} > $hcpus) ? $hcpus : $r{'max_bench_cpus'};
+  $bmem= (!defined($r{'max_bench_mem'})) ? $hmem :
+      ($r{'max_bench_mem'} > $hmem) ? $hmem : $r{'max_bench_mem'};
+  die unless (defined $bcpus and defined $bmem);
+
+  logm("Will run the benchmark on host with: $bcpus vcpus and $bmem MB RAM");
+
+  my $kernver= get_runvar('kernel_ver',$r{'kernbuildjob'});
+  my $kopt= "maxcpus=$bcpus mem=$bmem" . "M";
+
+  if ($ho->{Flags}{'need-uboot-bootscr'}) {
+      $bl= setupboot_uboot($ho,$kernver,undef,$kopt);
+  } elsif ($ho->{Suite} =~ m/lenny/) {
+      $bl= setupboot_grub1($ho,$kernver,undef,$kopt);
+  } else {
+      $bl= setupboot_grub2($ho,$kernver,undef,$kopt);
+  }
+
+  $bootkern= $bl->{PreFinalUpdate}();
+  $bl->{UpdateConfig}($ho);
+
+  $bootkern= $bl->{GetBootKern}();
+  logm("$ho->{Name} will reboot on kernel $bootkern with '$kopt' as options");
+}
+
+fixup();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylk6-00077W-Lo; Wed, 10 Dec 2014 18:12:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylk5-00075w-8O
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:12:05 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	3D/B5-23865-4FC88845; Wed, 10 Dec 2014 18:12:04 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418235123!12418366!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18795 invoked from network); 10 Dec 2014 18:12:03 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:12:03 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so12107344wib.4
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:12:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=LgJfYwcXbAabXDbStgUS5yY6LfbQr9B9GdNQSoWdXpo=;
	b=r0gJPPj0UN6Ypfy/q8VctQXDSx5byPy92QVgBioArjmNhksuDbMJFcQja2Vj81VQfs
	EURTqehjE5Wo8wWS8w+43Uq3UrGfKSjjP5X6u8Ou8whynGzxzHhE0qMxg5u/bBxQZI6B
	zgVNO7mahJfdKQ1uuvqRUE23bo/I6u1boq6jdo/gTw8eH7kecoTxRpf4WiNkfTRnFT9u
	cFDi/Q9j04q2xqoGGoEI2HBH4T1wJYi8zRQdyPVtH508IHWF+eoZAeimbrPYcTF5ATsT
	YAajQHbZe2NkT5jQHYk0WSMBx66iHx6JLXU9d6hzYrjl48aij5IF1Im3irXuzhOhUW5q
	UWcw==
X-Received: by 10.194.85.83 with SMTP id f19mr9353324wjz.20.1418235123495;
	Wed, 10 Dec 2014 10:12:03 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id vm8sm6833496wjc.6.2014.12.10.10.12.01
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:12:02 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:12:00 +0100
Message-ID: <20141210181200.26400.71485.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 23/27] ts-bench-hostcmp-host-reset: new 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

From: Dario Faggioli <raistlin@linux.it>

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Debian.pm      |   32 +++++++++++++++++---------------
 Osstest/TestSupport.pm |   46 +++++++++++++++++++++++++++++++++++++++++++++-
 ts-bench-hostcmp-post  |   39 +++++++++++++++++++++++++++++++++++++++
 ts-xen-install         |   38 ++------------------------------------
 4 files changed, 103 insertions(+), 52 deletions(-)
 create mode 100755 ts-bench-hostcmp-post

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 418d9f2..447d2d2 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -87,25 +87,27 @@ sub debian_boot_setup ($$$$;$) {
     my $kern= $bootloader->{GetBootKern}();
     logm("dom0 kernel is $kern");
 
-    system "tar zvtf $distpath->{kern} boot/$kern";
-    $? and die "$distpath->{kern} boot/$kern $?";
-
-    my $kernver= $kern;
-    $kernver =~ s,^/?(?:boot/)?(?:vmlinu[xz]-)?,, or die "$kernver ?";
-    my $kernpath= $kern;
-    $kernpath =~ s,^(?:boot/)?,/boot/,;
-
-    target_cmd_root($ho,
-                    "update-initramfs -k $kernver -c ||".
-                    " update-initramfs -k $kernver -u",
-                    200);
+    if (defined $distpath) {
+        system "tar zvtf $distpath->{kern} boot/$kern";
+        $? and die "$distpath->{kern} boot/$kern $?";
+
+        my $kernver= $kern;
+        $kernver =~ s,^/?(?:boot/)?(?:vmlinu[xz]-)?,, or die "$kernver ?";
+        my $kernpath= $kern;
+        $kernpath =~ s,^(?:boot/)?,/boot/,;
+
+        target_cmd_root($ho,
+                        "update-initramfs -k $kernver -c ||".
+                        " update-initramfs -k $kernver -u",
+                        200);
+
+        store_runvar(target_var_prefix($ho).'xen_kernel_path',$kernpath);
+        store_runvar(target_var_prefix($ho).'xen_kernel_ver',$kernver);
+    }
 
     $bootloader->{PreFinalUpdate}();
 
     $bootloader->{UpdateConfig}($ho);
-
-    store_runvar(target_var_prefix($ho).'xen_kernel_path',$kernpath);
-    store_runvar(target_var_prefix($ho).'xen_kernel_ver',$kernver);
 }
 
 sub bl_getmenu_open ($$$) {
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 251668a..c967e4f 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -99,7 +99,7 @@ BEGIN {
                       guest_vncsnapshot_begin guest_vncsnapshot_stash
 		      guest_check_remus_ok guest_editconfig
                       host_involves_pcipassthrough host_get_pcipassthrough_devs
-                      toolstack guest_create
+                      toolstack guest_create host_bootxen_setup
 
                       await_webspace_fetch_byleaf create_webfile
                       file_link_contents get_timeout
@@ -1012,6 +1012,50 @@ sub get_host_memory ($) {
     return $mem;
 }
 
+#---------- bootloader and booting ----------
+#
+sub host_bootxen_setup ($) {
+    my ($ho)= @_;
+
+    my $xenhopt= "conswitch=x watchdog";
+
+    my $cons= get_host_property($ho, '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($ho, 'XenDTUARTPath', undef);
+        $xenhopt .= " dtuart=$dtuart" if $dtuart;
+    } else {
+        logm("No Xen console device defined for host");
+    }
+    if (toolstack()->{Dom0MemFixed}) {
+        $xenhopt .= " dom0_mem=512M,max:512M";
+    }
+    my $append= $r{xen_boot_append};
+    $xenhopt .= " $append" if defined $append;
+    $append = get_host_property($ho, 'xen-commandline-append', undef);
+    $xenhopt .= " $append" if defined $append;
+
+    my @hooks;
+
+    if (host_involves_pcipassthrough($ho)) {
+        push @hooks, {
+            EditBootOptions => sub {
+                my ($ho,$hopt,$kopt) = @_;
+                $$hopt .= ' iommu=on';
+                my $hide= ' xen-pciback.hide='. join '',map { "($_->{Bdf})" }
+                    host_get_pcipassthrough_devs($ho);
+                logm("pci passthrough: hiding in dom0: $hide");
+                $$kopt .= $hide;
+            }
+        };
+    }
+
+    return ($xenhopt,@hooks);
+}
+
 #---------- stashed files ----------
 
 sub open_unique_stashfile ($) {
diff --git a/ts-bench-hostcmp-post b/ts-bench-hostcmp-post
new file mode 100755
index 0000000..26a67f4
--- /dev/null
+++ b/ts-bench-hostcmp-post
@@ -0,0 +1,39 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::Debian;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+sub resetboot () {
+  my ($xenhopt,@hooks)= host_bootxen_setup($ho);
+  my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
+
+  debian_boot_setup($ho, $want_kernver, $xenhopt, undef, \@hooks);
+
+  logm("host reset to booting Xen");
+}
+
+resetboot();
diff --git a/ts-xen-install b/ts-xen-install
index 4d34d1f..d8d38fc 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -134,43 +134,9 @@ sub adjustconfig () {
 }
 
 sub setupboot () {
-    my $xenhopt= "conswitch=x watchdog";
-
-    my $cons= get_host_property($ho, '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($ho, 'XenDTUARTPath', undef);
-	$xenhopt .= " dtuart=$dtuart" if $dtuart;
-    } else {
-	logm("No Xen console device defined for host");
-    }
-    if (toolstack()->{Dom0MemFixed}) {
-        $xenhopt .= " dom0_mem=512M,max:512M";
-    }
-    my $append= $r{xen_boot_append};
-    $xenhopt .= " $append" if defined $append;
-    $append = get_host_property($ho, 'xen-commandline-append', undef);
-    $xenhopt .= " $append" if defined $append;
-
-    my @hooks;
-
-    if (host_involves_pcipassthrough($ho)) {
-        push @hooks, {
-            EditBootOptions => sub {
-                my ($ho,$hopt,$kopt) = @_;
-                $$hopt .= ' iommu=on';
-                my $hide= ' xen-pciback.hide='. join '',map { "($_->{Bdf})" }
-                    host_get_pcipassthrough_devs($ho);
-                logm("pci passthrough: hiding in dom0: $hide");
-                $$kopt .= $hide;
-            }
-        };
-    }
-
+    my ($xenhopt,@hooks)= host_bootxen_setup($ho);
     my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
+
     debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
 
     logm("ready to boot Xen");


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xylk6-00077W-Lo; Wed, 10 Dec 2014 18:12:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylk5-00075w-8O
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:12:05 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	3D/B5-23865-4FC88845; Wed, 10 Dec 2014 18:12:04 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418235123!12418366!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18795 invoked from network); 10 Dec 2014 18:12:03 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:12:03 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so12107344wib.4
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:12:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=LgJfYwcXbAabXDbStgUS5yY6LfbQr9B9GdNQSoWdXpo=;
	b=r0gJPPj0UN6Ypfy/q8VctQXDSx5byPy92QVgBioArjmNhksuDbMJFcQja2Vj81VQfs
	EURTqehjE5Wo8wWS8w+43Uq3UrGfKSjjP5X6u8Ou8whynGzxzHhE0qMxg5u/bBxQZI6B
	zgVNO7mahJfdKQ1uuvqRUE23bo/I6u1boq6jdo/gTw8eH7kecoTxRpf4WiNkfTRnFT9u
	cFDi/Q9j04q2xqoGGoEI2HBH4T1wJYi8zRQdyPVtH508IHWF+eoZAeimbrPYcTF5ATsT
	YAajQHbZe2NkT5jQHYk0WSMBx66iHx6JLXU9d6hzYrjl48aij5IF1Im3irXuzhOhUW5q
	UWcw==
X-Received: by 10.194.85.83 with SMTP id f19mr9353324wjz.20.1418235123495;
	Wed, 10 Dec 2014 10:12:03 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id vm8sm6833496wjc.6.2014.12.10.10.12.01
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:12:02 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:12:00 +0100
Message-ID: <20141210181200.26400.71485.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 23/27] ts-bench-hostcmp-host-reset: new 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

From: Dario Faggioli <raistlin@linux.it>

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Debian.pm      |   32 +++++++++++++++++---------------
 Osstest/TestSupport.pm |   46 +++++++++++++++++++++++++++++++++++++++++++++-
 ts-bench-hostcmp-post  |   39 +++++++++++++++++++++++++++++++++++++++
 ts-xen-install         |   38 ++------------------------------------
 4 files changed, 103 insertions(+), 52 deletions(-)
 create mode 100755 ts-bench-hostcmp-post

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 418d9f2..447d2d2 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -87,25 +87,27 @@ sub debian_boot_setup ($$$$;$) {
     my $kern= $bootloader->{GetBootKern}();
     logm("dom0 kernel is $kern");
 
-    system "tar zvtf $distpath->{kern} boot/$kern";
-    $? and die "$distpath->{kern} boot/$kern $?";
-
-    my $kernver= $kern;
-    $kernver =~ s,^/?(?:boot/)?(?:vmlinu[xz]-)?,, or die "$kernver ?";
-    my $kernpath= $kern;
-    $kernpath =~ s,^(?:boot/)?,/boot/,;
-
-    target_cmd_root($ho,
-                    "update-initramfs -k $kernver -c ||".
-                    " update-initramfs -k $kernver -u",
-                    200);
+    if (defined $distpath) {
+        system "tar zvtf $distpath->{kern} boot/$kern";
+        $? and die "$distpath->{kern} boot/$kern $?";
+
+        my $kernver= $kern;
+        $kernver =~ s,^/?(?:boot/)?(?:vmlinu[xz]-)?,, or die "$kernver ?";
+        my $kernpath= $kern;
+        $kernpath =~ s,^(?:boot/)?,/boot/,;
+
+        target_cmd_root($ho,
+                        "update-initramfs -k $kernver -c ||".
+                        " update-initramfs -k $kernver -u",
+                        200);
+
+        store_runvar(target_var_prefix($ho).'xen_kernel_path',$kernpath);
+        store_runvar(target_var_prefix($ho).'xen_kernel_ver',$kernver);
+    }
 
     $bootloader->{PreFinalUpdate}();
 
     $bootloader->{UpdateConfig}($ho);
-
-    store_runvar(target_var_prefix($ho).'xen_kernel_path',$kernpath);
-    store_runvar(target_var_prefix($ho).'xen_kernel_ver',$kernver);
 }
 
 sub bl_getmenu_open ($$$) {
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 251668a..c967e4f 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -99,7 +99,7 @@ BEGIN {
                       guest_vncsnapshot_begin guest_vncsnapshot_stash
 		      guest_check_remus_ok guest_editconfig
                       host_involves_pcipassthrough host_get_pcipassthrough_devs
-                      toolstack guest_create
+                      toolstack guest_create host_bootxen_setup
 
                       await_webspace_fetch_byleaf create_webfile
                       file_link_contents get_timeout
@@ -1012,6 +1012,50 @@ sub get_host_memory ($) {
     return $mem;
 }
 
+#---------- bootloader and booting ----------
+#
+sub host_bootxen_setup ($) {
+    my ($ho)= @_;
+
+    my $xenhopt= "conswitch=x watchdog";
+
+    my $cons= get_host_property($ho, '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($ho, 'XenDTUARTPath', undef);
+        $xenhopt .= " dtuart=$dtuart" if $dtuart;
+    } else {
+        logm("No Xen console device defined for host");
+    }
+    if (toolstack()->{Dom0MemFixed}) {
+        $xenhopt .= " dom0_mem=512M,max:512M";
+    }
+    my $append= $r{xen_boot_append};
+    $xenhopt .= " $append" if defined $append;
+    $append = get_host_property($ho, 'xen-commandline-append', undef);
+    $xenhopt .= " $append" if defined $append;
+
+    my @hooks;
+
+    if (host_involves_pcipassthrough($ho)) {
+        push @hooks, {
+            EditBootOptions => sub {
+                my ($ho,$hopt,$kopt) = @_;
+                $$hopt .= ' iommu=on';
+                my $hide= ' xen-pciback.hide='. join '',map { "($_->{Bdf})" }
+                    host_get_pcipassthrough_devs($ho);
+                logm("pci passthrough: hiding in dom0: $hide");
+                $$kopt .= $hide;
+            }
+        };
+    }
+
+    return ($xenhopt,@hooks);
+}
+
 #---------- stashed files ----------
 
 sub open_unique_stashfile ($) {
diff --git a/ts-bench-hostcmp-post b/ts-bench-hostcmp-post
new file mode 100755
index 0000000..26a67f4
--- /dev/null
+++ b/ts-bench-hostcmp-post
@@ -0,0 +1,39 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::Debian;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+
+sub resetboot () {
+  my ($xenhopt,@hooks)= host_bootxen_setup($ho);
+  my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
+
+  debian_boot_setup($ho, $want_kernver, $xenhopt, undef, \@hooks);
+
+  logm("host reset to booting Xen");
+}
+
+resetboot();
diff --git a/ts-xen-install b/ts-xen-install
index 4d34d1f..d8d38fc 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -134,43 +134,9 @@ sub adjustconfig () {
 }
 
 sub setupboot () {
-    my $xenhopt= "conswitch=x watchdog";
-
-    my $cons= get_host_property($ho, '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($ho, 'XenDTUARTPath', undef);
-	$xenhopt .= " dtuart=$dtuart" if $dtuart;
-    } else {
-	logm("No Xen console device defined for host");
-    }
-    if (toolstack()->{Dom0MemFixed}) {
-        $xenhopt .= " dom0_mem=512M,max:512M";
-    }
-    my $append= $r{xen_boot_append};
-    $xenhopt .= " $append" if defined $append;
-    $append = get_host_property($ho, 'xen-commandline-append', undef);
-    $xenhopt .= " $append" if defined $append;
-
-    my @hooks;
-
-    if (host_involves_pcipassthrough($ho)) {
-        push @hooks, {
-            EditBootOptions => sub {
-                my ($ho,$hopt,$kopt) = @_;
-                $$hopt .= ' iommu=on';
-                my $hide= ' xen-pciback.hide='. join '',map { "($_->{Bdf})" }
-                    host_get_pcipassthrough_devs($ho);
-                logm("pci passthrough: hiding in dom0: $hide");
-                $$kopt .= $hide;
-            }
-        };
-    }
-
+    my ($xenhopt,@hooks)= host_bootxen_setup($ho);
     my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
+
     debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
 
     logm("ready to boot Xen");


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XylkF-0007L6-3p; Wed, 10 Dec 2014 18:12:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XylkD-0007FY-6m
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:12:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B1/17-15461-CFC88845; Wed, 10 Dec 2014 18:12:12 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418235131!14736324!1
X-Originating-IP: [74.125.82.42]
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 18400 invoked from network); 10 Dec 2014 18:12:11 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:12:11 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so4373394wgg.1
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:12:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=u7LebMWqjnmU17wZxpSSDR29Plzvmzc55kqOWsXabqQ=;
	b=x9nzQlszdph9SoJDOZH2yGi3pLrC1FgdrczAfqhcw5LLveLobtrRpXUGOmX4FZCf1d
	NE1MHCme6uFxeVRuk42M6eodwLKUhGplvdX2NWMx76D8z4iX04RaXSdJtuiF5EDA5B9m
	Jnq0+RNok8CzbaRL8ofQSdrjsSQmcfGu07gVVjk6ZpN4YD+YXQflEq5sAsIZPKB2ZhgG
	WgT2nvEMYpBbvr4Ghc8Jr/rHCMLA1chrHxK1iNwRh9CkIEsVjBSfb1gD6ONz0gqgGZz+
	cehYbNaklGDL00QgIzN8jsOkg6exKJQ+qpyBiMTUUTE97SJO8rLiu3CIaKMRCVzsVP/3
	Q+8Q==
X-Received: by 10.180.96.227 with SMTP id dv3mr8696099wib.50.1418235131653;
	Wed, 10 Dec 2014 10:12:11 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id cp4sm6823394wjb.16.2014.12.10.10.12.09
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:12:10 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:12:08 +0100
Message-ID: <20141210181208.26400.90243.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 24/27] Recipes and jobs for running unixbench
 both on host and 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

From: Dario Faggioli <raistlin@linux.it>

Recipes are defined for running unixbench on baremetal,
PV and HVM guests, with similar HW resources. Jobs making
use of those recipes are instantiated too.

Aim is making  investigating performances loss due to
virtualization overhead easy and automatable.

In this case, rebooting the host is necessary (to
boot it baremetal, rather than on Dom0), and that makes
leak checks impossible. A mechanism is therefore introduced
for specifying, in sg-run-job, that for a particular job,
we don't want the leak checks.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 README            |   11 +++++++++++
 make-bench-flight |   20 ++++++++++++++++++++
 sg-run-job        |   33 +++++++++++++++++++++++++++++++--
 3 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/README b/README
index b3880b5..1e777df 100644
--- a/README
+++ b/README
@@ -200,6 +200,17 @@ bench-$BENCHNAME-$ARCH-<XEN_OPTS>-<GUEST_OPTS>
         <GUEST_OPTS> tells about the guest's configuration (e.g., whether
         it's HVM or PV, number of vCPUs, RAM, etc.).
 
+bench-hostcmp-$BENCHNAME-$ARCH-<XEN_OPTS>-<GUEST_OPTS>
+
+        A benchmarking job, for comparing baremetal and guest performances.
+        This runs benchmark $BENCHNAME on a $ARCH baremetal host, and on
+        PV and HVM guests running on a $ARCH hypervisor and dom0.
+
+        In the remainder of the job's name, <XEN_OPTS> tells something
+        about Xen's configuration (e.g., what scheduler will be used);
+        <GUEST_OPTS> tells about the guest's configuration (e.g., whether
+        it's HVM or PV, number of vCPUs, RAM, etc.).
+
 NB: $ARCH (and $XENARCH etc) are Debian arch names, i386, amd64, armhf.
 
 Standalone Mode
diff --git a/make-bench-flight b/make-bench-flight
index 125f244..d41cbbd 100755
--- a/make-bench-flight
+++ b/make-bench-flight
@@ -109,12 +109,32 @@ do_kernbench_tests () {
           all_hostflags=$most_hostflags
 }
 
+do_hostcmp_unixbench_tests () {
+  sched=$1
+
+  # x86_64 only (for now)
+  if [ $xenarch != amd64 ]; then
+    return
+  fi
+  # "homogeneous" tests only (for now)
+  if [ $xenarch != $dom0arch ]; then
+    return
+  fi
+
+  job_create_test \
+          bench-hostcmp-unixbench-$xenarch-$sched bench-hostcmp-unixbench \
+          xl $xenarch $dom0arch xen_boot_append="sched=$sched" max_bench_cpus=16 \
+          max_bench_mem=24576 $debian_runvars bios=seabios unixbench_params="-i 3" \
+          debbenchhvm_image=debian-7.2.0-amd64-CD-1.iso all_hostflags=$most_hostflags
+}
+
 test_matrix_do_one () {
   for s in credit credit2; do
     for t in pv hvm; do
       do_unixbench_tests $t $s 4 4096 # 4 vcpus, 4GB RAM
       do_kernbench_tests $t $s 4 4096
     done
+    do_hostcmp_unixbench_tests $s
   done
 }
 
diff --git a/sg-run-job b/sg-run-job
index 32c94db..5954032 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -30,10 +30,17 @@ proc run-job {job} {
     set anyfailed 0
     jobdb::prepare $job
 
+    set do_leak_check 1
     set nh [need-hosts/$jobinfo(recipe)]
     if {![string compare $nh BUILD]} {
         set need_xen_hosts {}
         set need_build_host 1
+    } elseif {[string match REBOOT* $nh]} {
+        # no leak checks for tests that reboot the host
+        set do_leak_check 0
+        set nh [lreplace $nh 0 0]
+        set need_xen_hosts $nh
+        set need_build_host 0
     } else {
         set need_xen_hosts $nh
         set need_build_host 0
@@ -54,10 +61,10 @@ proc run-job {job} {
     per-host-ts .       xen-install/@     ts-xen-install
     per-host-ts .       xen-boot/@        ts-host-reboot
 
-    per-host-ts .       =(*)             {ts-leak-check basis}
+    if {$do_leak_check} {per-host-ts . =(*) {ts-leak-check basis}         }
 
     if {$ok} { catching-otherwise fail      run-job/$jobinfo(recipe)      }
-    per-host-ts .       =                {ts-leak-check check}
+    if {$do_leak_check} {per-host-ts . = {ts-leak-check check}            }
 
     if {!$need_build_host} {
         per-host-ts !broken capture-logs/@(*) ts-logs-capture
@@ -381,6 +388,28 @@ proc run-job/bench-kernbench-hvm {} {
     bench-kernbench-guest debianhvm
 }
 
+proc need-hosts/bench-hostcmp-unixbench {} { return {REBOOT host} }
+proc run-job/bench-hostcmp-unixbench {} {
+    # Run benchmark in a PV guest
+    set g debbenchpv
+    run-ts . = ts-debian-install           + host $g
+    run-ts . = ts-debian-fixup             + host $g
+    run-ts . = ts-bench-hostcmp-guest-prep + host $g
+    bench-unixbench-guest $g
+    # Run benchmark in an HVM guest
+    set g debbenchhvm
+    run-ts . = ts-debian-hvm-install       + host $g
+    run-ts . = ts-guest-stop               + host $g
+    run-ts . = ts-bench-hostcmp-guest-prep + host $g
+    bench-unixbench-guest $g
+    # Run benchmark on the host
+    run-ts . = ts-bench-hostcmp-host-prep
+    run-ts . = ts-host-reboot
+    bench-unixbench-host
+    run-ts . = ts-bench-hostcmp-post
+    run-ts . = ts-host-reboot
+}
+
 #---------- builds ----------
 
 proc need-hosts/build {} { return BUILD }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1XylkF-0007L6-3p; Wed, 10 Dec 2014 18:12:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XylkD-0007FY-6m
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:12:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B1/17-15461-CFC88845; Wed, 10 Dec 2014 18:12:12 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418235131!14736324!1
X-Originating-IP: [74.125.82.42]
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 18400 invoked from network); 10 Dec 2014 18:12:11 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:12:11 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so4373394wgg.1
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:12:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=u7LebMWqjnmU17wZxpSSDR29Plzvmzc55kqOWsXabqQ=;
	b=x9nzQlszdph9SoJDOZH2yGi3pLrC1FgdrczAfqhcw5LLveLobtrRpXUGOmX4FZCf1d
	NE1MHCme6uFxeVRuk42M6eodwLKUhGplvdX2NWMx76D8z4iX04RaXSdJtuiF5EDA5B9m
	Jnq0+RNok8CzbaRL8ofQSdrjsSQmcfGu07gVVjk6ZpN4YD+YXQflEq5sAsIZPKB2ZhgG
	WgT2nvEMYpBbvr4Ghc8Jr/rHCMLA1chrHxK1iNwRh9CkIEsVjBSfb1gD6ONz0gqgGZz+
	cehYbNaklGDL00QgIzN8jsOkg6exKJQ+qpyBiMTUUTE97SJO8rLiu3CIaKMRCVzsVP/3
	Q+8Q==
X-Received: by 10.180.96.227 with SMTP id dv3mr8696099wib.50.1418235131653;
	Wed, 10 Dec 2014 10:12:11 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id cp4sm6823394wjb.16.2014.12.10.10.12.09
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:12:10 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:12:08 +0100
Message-ID: <20141210181208.26400.90243.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 24/27] Recipes and jobs for running unixbench
 both on host and 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

From: Dario Faggioli <raistlin@linux.it>

Recipes are defined for running unixbench on baremetal,
PV and HVM guests, with similar HW resources. Jobs making
use of those recipes are instantiated too.

Aim is making  investigating performances loss due to
virtualization overhead easy and automatable.

In this case, rebooting the host is necessary (to
boot it baremetal, rather than on Dom0), and that makes
leak checks impossible. A mechanism is therefore introduced
for specifying, in sg-run-job, that for a particular job,
we don't want the leak checks.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 README            |   11 +++++++++++
 make-bench-flight |   20 ++++++++++++++++++++
 sg-run-job        |   33 +++++++++++++++++++++++++++++++--
 3 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/README b/README
index b3880b5..1e777df 100644
--- a/README
+++ b/README
@@ -200,6 +200,17 @@ bench-$BENCHNAME-$ARCH-<XEN_OPTS>-<GUEST_OPTS>
         <GUEST_OPTS> tells about the guest's configuration (e.g., whether
         it's HVM or PV, number of vCPUs, RAM, etc.).
 
+bench-hostcmp-$BENCHNAME-$ARCH-<XEN_OPTS>-<GUEST_OPTS>
+
+        A benchmarking job, for comparing baremetal and guest performances.
+        This runs benchmark $BENCHNAME on a $ARCH baremetal host, and on
+        PV and HVM guests running on a $ARCH hypervisor and dom0.
+
+        In the remainder of the job's name, <XEN_OPTS> tells something
+        about Xen's configuration (e.g., what scheduler will be used);
+        <GUEST_OPTS> tells about the guest's configuration (e.g., whether
+        it's HVM or PV, number of vCPUs, RAM, etc.).
+
 NB: $ARCH (and $XENARCH etc) are Debian arch names, i386, amd64, armhf.
 
 Standalone Mode
diff --git a/make-bench-flight b/make-bench-flight
index 125f244..d41cbbd 100755
--- a/make-bench-flight
+++ b/make-bench-flight
@@ -109,12 +109,32 @@ do_kernbench_tests () {
           all_hostflags=$most_hostflags
 }
 
+do_hostcmp_unixbench_tests () {
+  sched=$1
+
+  # x86_64 only (for now)
+  if [ $xenarch != amd64 ]; then
+    return
+  fi
+  # "homogeneous" tests only (for now)
+  if [ $xenarch != $dom0arch ]; then
+    return
+  fi
+
+  job_create_test \
+          bench-hostcmp-unixbench-$xenarch-$sched bench-hostcmp-unixbench \
+          xl $xenarch $dom0arch xen_boot_append="sched=$sched" max_bench_cpus=16 \
+          max_bench_mem=24576 $debian_runvars bios=seabios unixbench_params="-i 3" \
+          debbenchhvm_image=debian-7.2.0-amd64-CD-1.iso all_hostflags=$most_hostflags
+}
+
 test_matrix_do_one () {
   for s in credit credit2; do
     for t in pv hvm; do
       do_unixbench_tests $t $s 4 4096 # 4 vcpus, 4GB RAM
       do_kernbench_tests $t $s 4 4096
     done
+    do_hostcmp_unixbench_tests $s
   done
 }
 
diff --git a/sg-run-job b/sg-run-job
index 32c94db..5954032 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -30,10 +30,17 @@ proc run-job {job} {
     set anyfailed 0
     jobdb::prepare $job
 
+    set do_leak_check 1
     set nh [need-hosts/$jobinfo(recipe)]
     if {![string compare $nh BUILD]} {
         set need_xen_hosts {}
         set need_build_host 1
+    } elseif {[string match REBOOT* $nh]} {
+        # no leak checks for tests that reboot the host
+        set do_leak_check 0
+        set nh [lreplace $nh 0 0]
+        set need_xen_hosts $nh
+        set need_build_host 0
     } else {
         set need_xen_hosts $nh
         set need_build_host 0
@@ -54,10 +61,10 @@ proc run-job {job} {
     per-host-ts .       xen-install/@     ts-xen-install
     per-host-ts .       xen-boot/@        ts-host-reboot
 
-    per-host-ts .       =(*)             {ts-leak-check basis}
+    if {$do_leak_check} {per-host-ts . =(*) {ts-leak-check basis}         }
 
     if {$ok} { catching-otherwise fail      run-job/$jobinfo(recipe)      }
-    per-host-ts .       =                {ts-leak-check check}
+    if {$do_leak_check} {per-host-ts . = {ts-leak-check check}            }
 
     if {!$need_build_host} {
         per-host-ts !broken capture-logs/@(*) ts-logs-capture
@@ -381,6 +388,28 @@ proc run-job/bench-kernbench-hvm {} {
     bench-kernbench-guest debianhvm
 }
 
+proc need-hosts/bench-hostcmp-unixbench {} { return {REBOOT host} }
+proc run-job/bench-hostcmp-unixbench {} {
+    # Run benchmark in a PV guest
+    set g debbenchpv
+    run-ts . = ts-debian-install           + host $g
+    run-ts . = ts-debian-fixup             + host $g
+    run-ts . = ts-bench-hostcmp-guest-prep + host $g
+    bench-unixbench-guest $g
+    # Run benchmark in an HVM guest
+    set g debbenchhvm
+    run-ts . = ts-debian-hvm-install       + host $g
+    run-ts . = ts-guest-stop               + host $g
+    run-ts . = ts-bench-hostcmp-guest-prep + host $g
+    bench-unixbench-guest $g
+    # Run benchmark on the host
+    run-ts . = ts-bench-hostcmp-host-prep
+    run-ts . = ts-host-reboot
+    bench-unixbench-host
+    run-ts . = ts-bench-hostcmp-post
+    run-ts . = ts-host-reboot
+}
+
 #---------- builds ----------
 
 proc need-hosts/build {} { return BUILD }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:12:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XylkU-0007ZQ-0C; Wed, 10 Dec 2014 18:12:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XylkT-0007YU-8t
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:12:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	02/A1-09842-C0D88845; Wed, 10 Dec 2014 18:12:28 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418235147!14775758!1
X-Originating-IP: [74.125.82.52]
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 14049 invoked from network); 10 Dec 2014 18:12:27 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:12:27 -0000
Received: by mail-wg0-f52.google.com with SMTP id x12so4349091wgg.39
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:12:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=bzAQbVa1YyZ/YMeJtHbsLyDxIR1L/nWpBms+O1eaJSY=;
	b=ugvemyjkM7+E/czIJCtNMCRamCeMGWSHPatP4C6wQsSx/xsVOOuGRGocj6+rLxBPOi
	BBAh3JoDuICL3tMV4BKN1IjEvQZpRupX1Vi5qF18zPEpGQ8sdl+Tw4qfMHQpwMY0/3Rw
	7H1ogCuGy3QG5A709vMYwVDNxtgzwopFknDRavxhPT28NJfALD8AD8EUBICzEUR68oc3
	QqC26KfsRT3q0ucqJjn9A+dE7q+yX7W6iq1nITR8NfPEQsdt+3W0jexzzI+u4SkGrQ81
	lcqtxdRQwBseShcE0erE/ISEEZhaWCTo/X6stvoeP1DNPgyVdpbDvgBCSCPmGeKCkj8L
	Cv1Q==
X-Received: by 10.180.85.34 with SMTP id e2mr8744870wiz.0.1418235147562;
	Wed, 10 Dec 2014 10:12:27 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id ep9sm7307105wid.3.2014.12.10.10.12.25
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:12:26 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:12:24 +0100
Message-ID: <20141210181224.26400.10642.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 26/27] Kernbench perf comparison between host
	and 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

From: Dario Faggioli <raistlin@linux.it>

Recipes are defined for running kernbench on baremetal,
and on PV and HVM guests. Jobs making use of those recipes
are instantiated too.

Aim is making  investigating performances loss due to
virtualization overhead easy and automatable.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 make-bench-flight |   14 +++++++++-----
 sg-run-job        |   21 +++++++++++++++------
 2 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/make-bench-flight b/make-bench-flight
index d41cbbd..12ac9f7 100755
--- a/make-bench-flight
+++ b/make-bench-flight
@@ -109,8 +109,9 @@ do_kernbench_tests () {
           all_hostflags=$most_hostflags
 }
 
-do_hostcmp_unixbench_tests () {
-  sched=$1
+do_bench_hostcmp_tests () {
+  bench=$1
+  sched=$2
 
   # x86_64 only (for now)
   if [ $xenarch != amd64 ]; then
@@ -122,10 +123,11 @@ do_hostcmp_unixbench_tests () {
   fi
 
   job_create_test \
-          bench-hostcmp-unixbench-$xenarch-$sched bench-hostcmp-unixbench \
+          bench-hostcmp-$bench-$xenarch-$sched bench-hostcmp-$bench \
           xl $xenarch $dom0arch xen_boot_append="sched=$sched" max_bench_cpus=16 \
           max_bench_mem=24576 $debian_runvars bios=seabios unixbench_params="-i 3" \
-          debbenchhvm_image=debian-7.2.0-amd64-CD-1.iso all_hostflags=$most_hostflags
+          kernbench_params="-n 3" debbenchhvm_image=debian-7.2.0-amd64-CD-1.iso \
+          all_hostflags=$most_hostflags
 }
 
 test_matrix_do_one () {
@@ -134,7 +136,9 @@ test_matrix_do_one () {
       do_unixbench_tests $t $s 4 4096 # 4 vcpus, 4GB RAM
       do_kernbench_tests $t $s 4 4096
     done
-    do_hostcmp_unixbench_tests $s
+    for b in unixbench kernbench; do
+      do_bench_hostcmp_tests $b $s
+    done
   done
 }
 
diff --git a/sg-run-job b/sg-run-job
index b16584a..1b3f4d6 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -388,28 +388,37 @@ proc run-job/bench-kernbench-hvm {} {
     bench-kernbench-guest debianhvm
 }
 
-proc need-hosts/bench-hostcmp-unixbench {} { return {REBOOT host} }
-proc run-job/bench-hostcmp-unixbench {} {
+proc bench-hostcmp {bench} {
     # Run benchmark in a PV guest
     set g debbenchpv
     run-ts . = ts-debian-install           + host $g
     run-ts . = ts-debian-fixup             + host $g
     run-ts . = ts-bench-hostcmp-guest-prep + host $g
-    bench-unixbench-guest $g
+    bench-$bench-guest $g
     # Run benchmark in an HVM guest
     set g debbenchhvm
     run-ts . = ts-debian-hvm-install       + host $g
     run-ts . = ts-guest-stop               + host $g
     run-ts . = ts-bench-hostcmp-guest-prep + host $g
-    bench-unixbench-guest $g
+    bench-$bench-guest $g
     # Run benchmark on the host
     run-ts . = ts-bench-hostcmp-host-prep
     run-ts . = ts-host-reboot
-    bench-unixbench-host
-    run-ts . = ts-bench-hostcmp-post       + host unixbench
+    bench-$bench-host
+    run-ts . = ts-bench-hostcmp-post       + host $bench
     run-ts . = ts-host-reboot
 }
 
+proc need-hosts/bench-hostcmp-unixbench {} { return {REBOOT host} }
+proc run-job/bench-hostcmp-unixbench {} {
+    bench-hostcmp unixbench
+}
+
+proc need-hosts/bench-hostcmp-kernbench {} { return {REBOOT host} }
+proc run-job/bench-hostcmp-kernbench {} {
+    bench-hostcmp kernbench
+}
+
 #---------- builds ----------
 
 proc need-hosts/build {} { return BUILD }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:12:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XylkO-0007US-He; Wed, 10 Dec 2014 18:12:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XylkL-0007Qy-7r
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:12:22 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	83/27-14214-40D88845; Wed, 10 Dec 2014 18:12:20 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418235139!12675104!1
X-Originating-IP: [74.125.82.53]
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 22139 invoked from network); 10 Dec 2014 18:12:19 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:12:19 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so4336824wgh.40
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:12:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=K98CUekkel1A+fqs9brdCYD6VW308mdow/vc1E7xL6A=;
	b=PU/StfdxwaqPrlzBQQ8jCmjBiBu87FFLz2eQxbQhfkIpNc69PzF8tOBkCDxEfbDunm
	IiEoKygj9j/Rg4g+gsJe8NQMybhBWopMNv40RijQdHAgpq6413xE9MysWbJOQ6oyrPmb
	ddeC1kaSuspI0An67RiR02XYVq4b9QVp4OX8IRPfrm4NdC+MEybkv2vu+677thpZNET9
	RyqeRbhR4HHGkBEgIcCfT9jHAu4Gmqb0+pVjF/aUef7AVbbNVLncheVjaGBGJZzdpc4H
	FcSN325wDW2SlmUShT0xbpGqQkBIKGSp6zcn2JX6kUMCkNhSVW+KViGvcHiu8b1Oq/Bm
	96fA==
X-Received: by 10.180.108.167 with SMTP id hl7mr15157843wib.68.1418235139545; 
	Wed, 10 Dec 2014 10:12:19 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id vm8sm6834351wjc.6.2014.12.10.10.12.17
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:12:18 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:12:16 +0100
Message-ID: <20141210181216.26400.96.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 25/27] ts-bench-hostcmp-post: add plotting
	facilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

in order to have an additional graph, comparing host and
guests performance when running unixbench.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Benchmarking.pm |   22 ++++++++++++++++------
 sg-run-job              |    2 +-
 ts-bench-hostcmp-post   |   43 ++++++++++++++++++++++++++++++++++++++++++-
 ts-unixbench-reslts     |    6 +++---
 4 files changed, 62 insertions(+), 11 deletions(-)

diff --git a/Osstest/Benchmarking.pm b/Osstest/Benchmarking.pm
index ff45766..301af08 100644
--- a/Osstest/Benchmarking.pm
+++ b/Osstest/Benchmarking.pm
@@ -96,21 +96,31 @@ set boxwidth 1 absolute
 EOF
 
 sub unixbench_plot_results ($$$) {
-  my ($dataf,$num_cols,$pfile)= @_;
-  my $h= new IO::File "> $pfile.gp" or die "$!";
+  my ($dfiles,$num_cols,$pfile)= @_;
+  my $f= keys @$dfiles;
+  my $s= join(' ',@$dfiles);
 
-  printf $h <<EOF;
+  my $h= new IO::File "> $pfile.gp" or die "$!";
+  print $h <<EOF;
 set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" 8 size 800,600
 set output '$pfile.png'
 set title 'Unixbench INDEXes for $flight.$job'
 $common_plot_opts
 set bmargin 13
 set rmargin 14
+NDATA=$num_cols
+NHOSTS=$f
 SKIP_COL=1
-NCOL=$num_cols
+NCOL=1*(NHOSTS*NDATA)
 HWIDTH=1.0/(NCOL+1.0)
-plot for [c=SKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with histograms title columnhead, \\
-        for [c=SKIP_COL+1:SKIP_COL+NCOL]'' every ::1 using 0:c:c with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1))*HWIDTH, character 2 rotate by 90
+cols=''
+do for [h=0:NHOSTS-1] {
+        do for [c=1+h*(NDATA+SKIP_COL)+SKIP_COL:1+h*(NDATA+SKIP_COL)+SKIP_COL+NDATA-1] {
+          cols = cols . sprintf("\%d ", c);
+        }
+}
+plot for [c in cols] '< paste $s' using int(c):xtic(1) with histograms title columnhead, \\
+        for [i=1:words(cols)] '' every ::1 using 0:int(word(cols,i)):int(word(cols,i)) with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(i-1)*HWIDTH, character 2 rotate by 90
 EOF
   close($h);
 
diff --git a/sg-run-job b/sg-run-job
index 5954032..b16584a 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -406,7 +406,7 @@ proc run-job/bench-hostcmp-unixbench {} {
     run-ts . = ts-bench-hostcmp-host-prep
     run-ts . = ts-host-reboot
     bench-unixbench-host
-    run-ts . = ts-bench-hostcmp-post
+    run-ts . = ts-bench-hostcmp-post       + host unixbench
     run-ts . = ts-host-reboot
 }
 
diff --git a/ts-bench-hostcmp-post b/ts-bench-hostcmp-post
index 26a67f4..383bac0 100755
--- a/ts-bench-hostcmp-post
+++ b/ts-bench-hostcmp-post
@@ -20,13 +20,53 @@ use DBI;
 use Osstest;
 use Osstest::Debian;
 use Osstest::TestSupport;
+use Osstest::Benchmarking;
+use IO::File;
 
 tsreadconfig();
 
-our ($whhost) = @ARGV;
+# what we expect as argument list is:
+#  host=<somehost> <somebench>
+our $whhost= $ARGV[0];
+our $bn= $ARGV[1];
+
+#our ($whhost,$gn,$bn) = @ARGV;
 $whhost ||= 'host';
 our $ho= selecthost($whhost);
 
+sub plot_hostcmp () {
+  opendir my $dir, "$stash" or die "$!";
+
+  my @dfiles = grep(/.*-DATA$/,readdir($dir));
+  closedir($dir);
+
+  # Mangle the data file a bit, so each data set is marked
+  # with the name of the box (either host or a VM) where
+  # the bench did run.
+  my ($fhi,$fho,$ncols);
+  foreach my $i (0 .. $#dfiles) {
+    $_= $dfiles[$i];
+    my $host= m/(\w*)(\.|--).*/;$host= $1;
+    $dfiles[$i]= "$stash/$dfiles[$i]";
+
+    open FH, "<", "$dfiles[$i]" or die "!";
+    my @lines= <FH>;
+    close FH;
+
+    open FH, ">", "$dfiles[$i]" or die "!";
+    foreach my $line (@lines) {
+      if ($line eq $lines[0]) {
+        $line =~ s/"([^"]*\w*[^"]*)"/"$host $1"/g if $line !~ "$host";
+      }
+      print FH $line;
+      # Figure out the number of data columns, for plotting
+      $ncols= () = $line =~ /(\d+\.\d+)/g;
+    }
+    close FH;
+  }
+  unixbench_plot_results(\@dfiles,$ncols,"$stash/$job-PLOT") if $bn eq "unixbench";
+}
+
 sub resetboot () {
   my ($xenhopt,@hooks)= host_bootxen_setup($ho);
   my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
@@ -36,4 +76,5 @@ sub resetboot () {
   logm("host reset to booting Xen");
 }
 
+plot_hostcmp();
 resetboot();
diff --git a/ts-unixbench-reslts b/ts-unixbench-reslts
index b480d15..6c3e0a3 100755
--- a/ts-unixbench-reslts
+++ b/ts-unixbench-reslts
@@ -69,15 +69,15 @@ END
 
 sub process () {
   my $resf= "$stash/$gho->{Name}--$lresfile";
-  my $dataf= "$resf-DATA";
+  my @dataf= "$resf-DATA";
   my $plotf= "$resf-PLOT";
 
   unixbench_process_results(\$results,$resf);
-  unixbench_print_results($results,$dataf);
+  unixbench_print_results($results,$dataf[0]);
 
   # For plotting we need to know the number of data columns
   my $ncols= keys $results->{'Double-Precision Whetstone'}{Index};
-  unixbench_plot_results($dataf,$ncols,$plotf);
+  unixbench_plot_results(\@dataf,$ncols,$plotf);
 }
 
 fetch();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:12:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XylkU-0007ZQ-0C; Wed, 10 Dec 2014 18:12:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XylkT-0007YU-8t
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:12:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	02/A1-09842-C0D88845; Wed, 10 Dec 2014 18:12:28 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418235147!14775758!1
X-Originating-IP: [74.125.82.52]
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 14049 invoked from network); 10 Dec 2014 18:12:27 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:12:27 -0000
Received: by mail-wg0-f52.google.com with SMTP id x12so4349091wgg.39
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:12:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=bzAQbVa1YyZ/YMeJtHbsLyDxIR1L/nWpBms+O1eaJSY=;
	b=ugvemyjkM7+E/czIJCtNMCRamCeMGWSHPatP4C6wQsSx/xsVOOuGRGocj6+rLxBPOi
	BBAh3JoDuICL3tMV4BKN1IjEvQZpRupX1Vi5qF18zPEpGQ8sdl+Tw4qfMHQpwMY0/3Rw
	7H1ogCuGy3QG5A709vMYwVDNxtgzwopFknDRavxhPT28NJfALD8AD8EUBICzEUR68oc3
	QqC26KfsRT3q0ucqJjn9A+dE7q+yX7W6iq1nITR8NfPEQsdt+3W0jexzzI+u4SkGrQ81
	lcqtxdRQwBseShcE0erE/ISEEZhaWCTo/X6stvoeP1DNPgyVdpbDvgBCSCPmGeKCkj8L
	Cv1Q==
X-Received: by 10.180.85.34 with SMTP id e2mr8744870wiz.0.1418235147562;
	Wed, 10 Dec 2014 10:12:27 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id ep9sm7307105wid.3.2014.12.10.10.12.25
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:12:26 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:12:24 +0100
Message-ID: <20141210181224.26400.10642.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 26/27] Kernbench perf comparison between host
	and 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

From: Dario Faggioli <raistlin@linux.it>

Recipes are defined for running kernbench on baremetal,
and on PV and HVM guests. Jobs making use of those recipes
are instantiated too.

Aim is making  investigating performances loss due to
virtualization overhead easy and automatable.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 make-bench-flight |   14 +++++++++-----
 sg-run-job        |   21 +++++++++++++++------
 2 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/make-bench-flight b/make-bench-flight
index d41cbbd..12ac9f7 100755
--- a/make-bench-flight
+++ b/make-bench-flight
@@ -109,8 +109,9 @@ do_kernbench_tests () {
           all_hostflags=$most_hostflags
 }
 
-do_hostcmp_unixbench_tests () {
-  sched=$1
+do_bench_hostcmp_tests () {
+  bench=$1
+  sched=$2
 
   # x86_64 only (for now)
   if [ $xenarch != amd64 ]; then
@@ -122,10 +123,11 @@ do_hostcmp_unixbench_tests () {
   fi
 
   job_create_test \
-          bench-hostcmp-unixbench-$xenarch-$sched bench-hostcmp-unixbench \
+          bench-hostcmp-$bench-$xenarch-$sched bench-hostcmp-$bench \
           xl $xenarch $dom0arch xen_boot_append="sched=$sched" max_bench_cpus=16 \
           max_bench_mem=24576 $debian_runvars bios=seabios unixbench_params="-i 3" \
-          debbenchhvm_image=debian-7.2.0-amd64-CD-1.iso all_hostflags=$most_hostflags
+          kernbench_params="-n 3" debbenchhvm_image=debian-7.2.0-amd64-CD-1.iso \
+          all_hostflags=$most_hostflags
 }
 
 test_matrix_do_one () {
@@ -134,7 +136,9 @@ test_matrix_do_one () {
       do_unixbench_tests $t $s 4 4096 # 4 vcpus, 4GB RAM
       do_kernbench_tests $t $s 4 4096
     done
-    do_hostcmp_unixbench_tests $s
+    for b in unixbench kernbench; do
+      do_bench_hostcmp_tests $b $s
+    done
   done
 }
 
diff --git a/sg-run-job b/sg-run-job
index b16584a..1b3f4d6 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -388,28 +388,37 @@ proc run-job/bench-kernbench-hvm {} {
     bench-kernbench-guest debianhvm
 }
 
-proc need-hosts/bench-hostcmp-unixbench {} { return {REBOOT host} }
-proc run-job/bench-hostcmp-unixbench {} {
+proc bench-hostcmp {bench} {
     # Run benchmark in a PV guest
     set g debbenchpv
     run-ts . = ts-debian-install           + host $g
     run-ts . = ts-debian-fixup             + host $g
     run-ts . = ts-bench-hostcmp-guest-prep + host $g
-    bench-unixbench-guest $g
+    bench-$bench-guest $g
     # Run benchmark in an HVM guest
     set g debbenchhvm
     run-ts . = ts-debian-hvm-install       + host $g
     run-ts . = ts-guest-stop               + host $g
     run-ts . = ts-bench-hostcmp-guest-prep + host $g
-    bench-unixbench-guest $g
+    bench-$bench-guest $g
     # Run benchmark on the host
     run-ts . = ts-bench-hostcmp-host-prep
     run-ts . = ts-host-reboot
-    bench-unixbench-host
-    run-ts . = ts-bench-hostcmp-post       + host unixbench
+    bench-$bench-host
+    run-ts . = ts-bench-hostcmp-post       + host $bench
     run-ts . = ts-host-reboot
 }
 
+proc need-hosts/bench-hostcmp-unixbench {} { return {REBOOT host} }
+proc run-job/bench-hostcmp-unixbench {} {
+    bench-hostcmp unixbench
+}
+
+proc need-hosts/bench-hostcmp-kernbench {} { return {REBOOT host} }
+proc run-job/bench-hostcmp-kernbench {} {
+    bench-hostcmp kernbench
+}
+
 #---------- builds ----------
 
 proc need-hosts/build {} { return BUILD }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:12:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XylkO-0007US-He; Wed, 10 Dec 2014 18:12:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1XylkL-0007Qy-7r
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:12:22 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	83/27-14214-40D88845; Wed, 10 Dec 2014 18:12:20 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418235139!12675104!1
X-Originating-IP: [74.125.82.53]
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 22139 invoked from network); 10 Dec 2014 18:12:19 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:12:19 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so4336824wgh.40
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:12:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=K98CUekkel1A+fqs9brdCYD6VW308mdow/vc1E7xL6A=;
	b=PU/StfdxwaqPrlzBQQ8jCmjBiBu87FFLz2eQxbQhfkIpNc69PzF8tOBkCDxEfbDunm
	IiEoKygj9j/Rg4g+gsJe8NQMybhBWopMNv40RijQdHAgpq6413xE9MysWbJOQ6oyrPmb
	ddeC1kaSuspI0An67RiR02XYVq4b9QVp4OX8IRPfrm4NdC+MEybkv2vu+677thpZNET9
	RyqeRbhR4HHGkBEgIcCfT9jHAu4Gmqb0+pVjF/aUef7AVbbNVLncheVjaGBGJZzdpc4H
	FcSN325wDW2SlmUShT0xbpGqQkBIKGSp6zcn2JX6kUMCkNhSVW+KViGvcHiu8b1Oq/Bm
	96fA==
X-Received: by 10.180.108.167 with SMTP id hl7mr15157843wib.68.1418235139545; 
	Wed, 10 Dec 2014 10:12:19 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id vm8sm6834351wjc.6.2014.12.10.10.12.17
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:12:18 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:12:16 +0100
Message-ID: <20141210181216.26400.96.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 25/27] ts-bench-hostcmp-post: add plotting
	facilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

in order to have an additional graph, comparing host and
guests performance when running unixbench.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Benchmarking.pm |   22 ++++++++++++++++------
 sg-run-job              |    2 +-
 ts-bench-hostcmp-post   |   43 ++++++++++++++++++++++++++++++++++++++++++-
 ts-unixbench-reslts     |    6 +++---
 4 files changed, 62 insertions(+), 11 deletions(-)

diff --git a/Osstest/Benchmarking.pm b/Osstest/Benchmarking.pm
index ff45766..301af08 100644
--- a/Osstest/Benchmarking.pm
+++ b/Osstest/Benchmarking.pm
@@ -96,21 +96,31 @@ set boxwidth 1 absolute
 EOF
 
 sub unixbench_plot_results ($$$) {
-  my ($dataf,$num_cols,$pfile)= @_;
-  my $h= new IO::File "> $pfile.gp" or die "$!";
+  my ($dfiles,$num_cols,$pfile)= @_;
+  my $f= keys @$dfiles;
+  my $s= join(' ',@$dfiles);
 
-  printf $h <<EOF;
+  my $h= new IO::File "> $pfile.gp" or die "$!";
+  print $h <<EOF;
 set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" 8 size 800,600
 set output '$pfile.png'
 set title 'Unixbench INDEXes for $flight.$job'
 $common_plot_opts
 set bmargin 13
 set rmargin 14
+NDATA=$num_cols
+NHOSTS=$f
 SKIP_COL=1
-NCOL=$num_cols
+NCOL=1*(NHOSTS*NDATA)
 HWIDTH=1.0/(NCOL+1.0)
-plot for [c=SKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with histograms title columnhead, \\
-        for [c=SKIP_COL+1:SKIP_COL+NCOL]'' every ::1 using 0:c:c with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1))*HWIDTH, character 2 rotate by 90
+cols=''
+do for [h=0:NHOSTS-1] {
+        do for [c=1+h*(NDATA+SKIP_COL)+SKIP_COL:1+h*(NDATA+SKIP_COL)+SKIP_COL+NDATA-1] {
+          cols = cols . sprintf("\%d ", c);
+        }
+}
+plot for [c in cols] '< paste $s' using int(c):xtic(1) with histograms title columnhead, \\
+        for [i=1:words(cols)] '' every ::1 using 0:int(word(cols,i)):int(word(cols,i)) with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(i-1)*HWIDTH, character 2 rotate by 90
 EOF
   close($h);
 
diff --git a/sg-run-job b/sg-run-job
index 5954032..b16584a 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -406,7 +406,7 @@ proc run-job/bench-hostcmp-unixbench {} {
     run-ts . = ts-bench-hostcmp-host-prep
     run-ts . = ts-host-reboot
     bench-unixbench-host
-    run-ts . = ts-bench-hostcmp-post
+    run-ts . = ts-bench-hostcmp-post       + host unixbench
     run-ts . = ts-host-reboot
 }
 
diff --git a/ts-bench-hostcmp-post b/ts-bench-hostcmp-post
index 26a67f4..383bac0 100755
--- a/ts-bench-hostcmp-post
+++ b/ts-bench-hostcmp-post
@@ -20,13 +20,53 @@ use DBI;
 use Osstest;
 use Osstest::Debian;
 use Osstest::TestSupport;
+use Osstest::Benchmarking;
+use IO::File;
 
 tsreadconfig();
 
-our ($whhost) = @ARGV;
+# what we expect as argument list is:
+#  host=<somehost> <somebench>
+our $whhost= $ARGV[0];
+our $bn= $ARGV[1];
+
+#our ($whhost,$gn,$bn) = @ARGV;
 $whhost ||= 'host';
 our $ho= selecthost($whhost);
 
+sub plot_hostcmp () {
+  opendir my $dir, "$stash" or die "$!";
+
+  my @dfiles = grep(/.*-DATA$/,readdir($dir));
+  closedir($dir);
+
+  # Mangle the data file a bit, so each data set is marked
+  # with the name of the box (either host or a VM) where
+  # the bench did run.
+  my ($fhi,$fho,$ncols);
+  foreach my $i (0 .. $#dfiles) {
+    $_= $dfiles[$i];
+    my $host= m/(\w*)(\.|--).*/;$host= $1;
+    $dfiles[$i]= "$stash/$dfiles[$i]";
+
+    open FH, "<", "$dfiles[$i]" or die "!";
+    my @lines= <FH>;
+    close FH;
+
+    open FH, ">", "$dfiles[$i]" or die "!";
+    foreach my $line (@lines) {
+      if ($line eq $lines[0]) {
+        $line =~ s/"([^"]*\w*[^"]*)"/"$host $1"/g if $line !~ "$host";
+      }
+      print FH $line;
+      # Figure out the number of data columns, for plotting
+      $ncols= () = $line =~ /(\d+\.\d+)/g;
+    }
+    close FH;
+  }
+  unixbench_plot_results(\@dfiles,$ncols,"$stash/$job-PLOT") if $bn eq "unixbench";
+}
+
 sub resetboot () {
   my ($xenhopt,@hooks)= host_bootxen_setup($ho);
   my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
@@ -36,4 +76,5 @@ sub resetboot () {
   logm("host reset to booting Xen");
 }
 
+plot_hostcmp();
 resetboot();
diff --git a/ts-unixbench-reslts b/ts-unixbench-reslts
index b480d15..6c3e0a3 100755
--- a/ts-unixbench-reslts
+++ b/ts-unixbench-reslts
@@ -69,15 +69,15 @@ END
 
 sub process () {
   my $resf= "$stash/$gho->{Name}--$lresfile";
-  my $dataf= "$resf-DATA";
+  my @dataf= "$resf-DATA";
   my $plotf= "$resf-PLOT";
 
   unixbench_process_results(\$results,$resf);
-  unixbench_print_results($results,$dataf);
+  unixbench_print_results($results,$dataf[0]);
 
   # For plotting we need to know the number of data columns
   my $ncols= keys $results->{'Double-Precision Whetstone'}{Index};
-  unixbench_plot_results($dataf,$ncols,$plotf);
+  unixbench_plot_results(\@dataf,$ncols,$plotf);
 }
 
 fetch();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1Xylkc-0007jw-QC; Wed, 10 Dec 2014 18:12:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylkb-0007hy-Cc
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:12:37 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	FD/89-02696-41D88845; Wed, 10 Dec 2014 18:12:36 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418235155!14265971!1
X-Originating-IP: [74.125.82.48]
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 8727 invoked from network); 10 Dec 2014 18:12:36 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:12:36 -0000
Received: by mail-wg0-f48.google.com with SMTP id y19so4353002wgg.35
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:12:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=UTUzjdcKwrWEo23f5Z568rC1cQs49fgPb826o/WBTuI=;
	b=v0/P1CJuZlh3xHrWzs3JGqNgnck3dgtTmDuQ52cikHLtp//rxMWFNx2Yi7OX24dQe7
	KWF+Tvu18sOJy6C09YCDkocRebpW8ARz4NtYk+qpCLRy49Fp0oSKnhb/8Ftp3/tpPrsV
	Eh9MSgLsaYlq+5Qh2u62y6JxmlNGNcTKYLQH/zRWzJ6FRjDUJhYeuxM3YK2EwGG78fuw
	aTuvbY6Op1CNTgzVV7RQxfVKrbR26kG9d+omE2CA9j3PnJITXD4+3Z2UbUWXdl4BnJM1
	b10B235hOe5r0+jrUw9bk2+BKMaTzOzlK4dhflh+nl1EtquOTZ6xHM7DxrJ+YUqQbi5g
	ek4g==
X-Received: by 10.180.80.163 with SMTP id s3mr8256141wix.59.1418235155745;
	Wed, 10 Dec 2014 10:12:35 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id f7sm7293563wiz.13.2014.12.10.10.12.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:12:34 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:12:32 +0100
Message-ID: <20141210181232.26400.79899.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 27/27] ts-bench-hostcmp-post: add plotting
	facilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

in order to have an additional graph, comparing host and
guests performance when running kernbench.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Benchmarking.pm |   17 +++++++++++++----
 ts-bench-hostcmp-post   |    1 +
 ts-kernbench-reslts     |    6 +++---
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/Osstest/Benchmarking.pm b/Osstest/Benchmarking.pm
index 301af08..1be9c97 100644
--- a/Osstest/Benchmarking.pm
+++ b/Osstest/Benchmarking.pm
@@ -175,7 +175,9 @@ sub kernbench_print_results ($$) {
 }
 
 sub kernbench_plot_results ($$$) {
-  my ($dataf,$num_cols,$pfile)= @_;
+  my ($dfiles,$num_cols,$pfile)= @_;
+  my $f= keys @$dfiles;
+  my $s= join(' ',@$dfiles);
 
   my $h= new IO::File "> $pfile.gp" or die "$!";
   print $h <<EOF;
@@ -184,12 +186,19 @@ set output '$pfile.png'
 set title 'Kernbench Results for $flight.$job'
 $common_plot_opts
 set bmargin 6
+NDATA=$num_cols
+NHOSTS=$f
 SKIP_COL=1
-NCOL=$num_cols
+NCOL=1*(NHOSTS*NDATA)
 HWIDTH=1.0/(NCOL+1.0)
 cols=''
-plot for [c=SKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with histograms title columnhead, \\
-        for [c=SKIP_COL+1:SKIP_COL+NCOL] '' every ::1 using 0:c:c with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1))*HWIDTH, character 2 rotate by 90
+do for [h=0:NHOSTS-1] {
+        do for [c=1+h*(NDATA+SKIP_COL)+SKIP_COL:1+h*(NDATA+SKIP_COL)+SKIP_COL+NDATA-1] {
+          cols = cols . sprintf("\%d ", c);
+        }
+}
+plot for [c in cols] '< paste $s' using int(c):xtic(1) with histograms title columnhead, \\
+        for [i=1:words(cols)] '' every ::1 using 0:int(word(cols,i)):int(word(cols,i)) with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(i-1)*HWIDTH, character 2 rotate by 90
 EOF
   close($h);
 
diff --git a/ts-bench-hostcmp-post b/ts-bench-hostcmp-post
index 383bac0..ee9cf0a 100755
--- a/ts-bench-hostcmp-post
+++ b/ts-bench-hostcmp-post
@@ -65,6 +65,7 @@ sub plot_hostcmp () {
     close FH;
   }
   unixbench_plot_results(\@dfiles,$ncols,"$stash/$job-PLOT") if $bn eq "unixbench";
+  kernbench_plot_results(\@dfiles,$ncols,"$stash/$job-PLOT") if $bn eq "kernbench";
 }
 
 sub resetboot () {
diff --git a/ts-kernbench-reslts b/ts-kernbench-reslts
index 113a4ce..b9ee393 100755
--- a/ts-kernbench-reslts
+++ b/ts-kernbench-reslts
@@ -62,13 +62,13 @@ sub fetch() {
 
 sub process () {
   my $resf= "$stash/$gho->{Name}--$lresfile";
-  my $dataf= "$resf-DATA";
+  my @dataf= "$resf-DATA";
   my $plotf= "$resf-PLOT";
 
   kernbench_process_results(\$results,$resf);
-  kernbench_print_results($results,$dataf);
+  kernbench_print_results($results,$dataf[0]);
   my $ncols= keys $results->{'Elapsed Time'}{'Result'};
-  kernbench_plot_results($dataf,$ncols,$plotf);
+  kernbench_plot_results(\@dataf,$ncols,$plotf);
 }
 
 fetch();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:12:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18: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 1Xylkc-0007jw-QC; Wed, 10 Dec 2014 18:12:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xylkb-0007hy-Cc
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:12:37 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	FD/89-02696-41D88845; Wed, 10 Dec 2014 18:12:36 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418235155!14265971!1
X-Originating-IP: [74.125.82.48]
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 8727 invoked from network); 10 Dec 2014 18:12:36 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 18:12:36 -0000
Received: by mail-wg0-f48.google.com with SMTP id y19so4353002wgg.35
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 10:12:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=UTUzjdcKwrWEo23f5Z568rC1cQs49fgPb826o/WBTuI=;
	b=v0/P1CJuZlh3xHrWzs3JGqNgnck3dgtTmDuQ52cikHLtp//rxMWFNx2Yi7OX24dQe7
	KWF+Tvu18sOJy6C09YCDkocRebpW8ARz4NtYk+qpCLRy49Fp0oSKnhb/8Ftp3/tpPrsV
	Eh9MSgLsaYlq+5Qh2u62y6JxmlNGNcTKYLQH/zRWzJ6FRjDUJhYeuxM3YK2EwGG78fuw
	aTuvbY6Op1CNTgzVV7RQxfVKrbR26kG9d+omE2CA9j3PnJITXD4+3Z2UbUWXdl4BnJM1
	b10B235hOe5r0+jrUw9bk2+BKMaTzOzlK4dhflh+nl1EtquOTZ6xHM7DxrJ+YUqQbi5g
	ek4g==
X-Received: by 10.180.80.163 with SMTP id s3mr8256141wix.59.1418235155745;
	Wed, 10 Dec 2014 10:12:35 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id f7sm7293563wiz.13.2014.12.10.10.12.33
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 10 Dec 2014 10:12:34 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 10 Dec 2014 19:12:32 +0100
Message-ID: <20141210181232.26400.79899.stgit@Abyss.station>
In-Reply-To: <20141210180651.26400.13356.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 27/27] ts-bench-hostcmp-post: add plotting
	facilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Dario Faggioli <raistlin@linux.it>

in order to have an additional graph, comparing host and
guests performance when running kernbench.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/Benchmarking.pm |   17 +++++++++++++----
 ts-bench-hostcmp-post   |    1 +
 ts-kernbench-reslts     |    6 +++---
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/Osstest/Benchmarking.pm b/Osstest/Benchmarking.pm
index 301af08..1be9c97 100644
--- a/Osstest/Benchmarking.pm
+++ b/Osstest/Benchmarking.pm
@@ -175,7 +175,9 @@ sub kernbench_print_results ($$) {
 }
 
 sub kernbench_plot_results ($$$) {
-  my ($dataf,$num_cols,$pfile)= @_;
+  my ($dfiles,$num_cols,$pfile)= @_;
+  my $f= keys @$dfiles;
+  my $s= join(' ',@$dfiles);
 
   my $h= new IO::File "> $pfile.gp" or die "$!";
   print $h <<EOF;
@@ -184,12 +186,19 @@ set output '$pfile.png'
 set title 'Kernbench Results for $flight.$job'
 $common_plot_opts
 set bmargin 6
+NDATA=$num_cols
+NHOSTS=$f
 SKIP_COL=1
-NCOL=$num_cols
+NCOL=1*(NHOSTS*NDATA)
 HWIDTH=1.0/(NCOL+1.0)
 cols=''
-plot for [c=SKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with histograms title columnhead, \\
-        for [c=SKIP_COL+1:SKIP_COL+NCOL] '' every ::1 using 0:c:c with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1))*HWIDTH, character 2 rotate by 90
+do for [h=0:NHOSTS-1] {
+        do for [c=1+h*(NDATA+SKIP_COL)+SKIP_COL:1+h*(NDATA+SKIP_COL)+SKIP_COL+NDATA-1] {
+          cols = cols . sprintf("\%d ", c);
+        }
+}
+plot for [c in cols] '< paste $s' using int(c):xtic(1) with histograms title columnhead, \\
+        for [i=1:words(cols)] '' every ::1 using 0:int(word(cols,i)):int(word(cols,i)) with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(i-1)*HWIDTH, character 2 rotate by 90
 EOF
   close($h);
 
diff --git a/ts-bench-hostcmp-post b/ts-bench-hostcmp-post
index 383bac0..ee9cf0a 100755
--- a/ts-bench-hostcmp-post
+++ b/ts-bench-hostcmp-post
@@ -65,6 +65,7 @@ sub plot_hostcmp () {
     close FH;
   }
   unixbench_plot_results(\@dfiles,$ncols,"$stash/$job-PLOT") if $bn eq "unixbench";
+  kernbench_plot_results(\@dfiles,$ncols,"$stash/$job-PLOT") if $bn eq "kernbench";
 }
 
 sub resetboot () {
diff --git a/ts-kernbench-reslts b/ts-kernbench-reslts
index 113a4ce..b9ee393 100755
--- a/ts-kernbench-reslts
+++ b/ts-kernbench-reslts
@@ -62,13 +62,13 @@ sub fetch() {
 
 sub process () {
   my $resf= "$stash/$gho->{Name}--$lresfile";
-  my $dataf= "$resf-DATA";
+  my @dataf= "$resf-DATA";
   my $plotf= "$resf-PLOT";
 
   kernbench_process_results(\$results,$resf);
-  kernbench_print_results($results,$dataf);
+  kernbench_print_results($results,$dataf[0]);
   my $ncols= keys $results->{'Elapsed Time'}{'Result'};
-  kernbench_plot_results($dataf,$ncols,$plotf);
+  kernbench_plot_results(\@dataf,$ncols,$plotf);
 }
 
 fetch();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:14:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:14:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyllz-0000HN-H9; Wed, 10 Dec 2014 18:14: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 1Xyllx-0000GG-Ie
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 18:14:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D3/E2-09842-86D88845; Wed, 10 Dec 2014 18:14:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418235238!14759824!1
X-Originating-IP: [66.165.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 19085 invoked from network); 10 Dec 2014 18:14:00 -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;
	10 Dec 2014 18:14:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202962444"
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.210.2; Wed, 10 Dec 2014 13:13: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 1Xyllq-0001Do-Vf;
	Wed, 10 Dec 2014 18:13:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xyllq-0002S5-Pr;
	Wed, 10 Dec 2014 18:13:54 +0000
Date: Wed, 10 Dec 2014 18:13:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32198-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] 32198: 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 32198 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32198/

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 32153

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-xl-pcipt-intel  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-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-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-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-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                  2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
baseline version:
 xen                  10e7747bca538205555e313574432f231070153b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@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                               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=2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
+ . 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 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
+ branch=xen-unstable
+ revision=2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
+ . 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 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   10e7747..2a549b9  2a549b9c8aa48dc39d7c97e5a93978b781b3a1db -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:14:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:14:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyllz-0000HN-H9; Wed, 10 Dec 2014 18:14: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 1Xyllx-0000GG-Ie
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 18:14:02 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D3/E2-09842-86D88845; Wed, 10 Dec 2014 18:14:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418235238!14759824!1
X-Originating-IP: [66.165.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 19085 invoked from network); 10 Dec 2014 18:14:00 -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;
	10 Dec 2014 18:14:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202962444"
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.210.2; Wed, 10 Dec 2014 13:13: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 1Xyllq-0001Do-Vf;
	Wed, 10 Dec 2014 18:13:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xyllq-0002S5-Pr;
	Wed, 10 Dec 2014 18:13:54 +0000
Date: Wed, 10 Dec 2014 18:13:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32198-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] 32198: 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 32198 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32198/

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 32153

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-xl-pcipt-intel  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-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-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-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-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                  2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
baseline version:
 xen                  10e7747bca538205555e313574432f231070153b

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@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                               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=2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
+ . 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 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
+ branch=xen-unstable
+ revision=2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
+ . 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 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   10e7747..2a549b9  2a549b9c8aa48dc39d7c97e5a93978b781b3a1db -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:40:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:40:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XymB2-0001iS-S5; Wed, 10 Dec 2014 18:39: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 1XymB1-0001iM-A0
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:39:55 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	C3/8D-17694-A7398845; Wed, 10 Dec 2014 18:39:54 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418236791!12457154!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 9400 invoked from network); 10 Dec 2014 18:39:53 -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 Dec 2014 18:39:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202976682"
Message-ID: <54889372.4070007@citrix.com>
Date: Wed, 10 Dec 2014 18:39:46 +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: Ian Campbell <Ian.Campbell@citrix.com>
References: <54884DA8.7030003@nuclearfallout.net>		
	<548854C3.7060008@citrix.com>
	<1418224039.3505.76.camel@citrix.com>	
	<548866D9.5050900@citrix.com> <1418228446.3505.81.camel@citrix.com>
In-Reply-To: <1418228446.3505.81.camel@citrix.com>
X-DLP: MIA1
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Wei Liu <wei.liu2@citrix.com>, John <jw@nuclearfallout.net>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen-netback: make feature-rx-notify mandatory --
	Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 16:20, Ian Campbell wrote:
> On Wed, 2014-12-10 at 15:29 +0000, David Vrabel wrote:
>> On 10/12/14 15:07, Ian Campbell wrote:
>>> On Wed, 2014-12-10 at 14:12 +0000, David Vrabel wrote:
>>>> On 10/12/14 13:42, John wrote:
>>>>> David,
>>>>>
>>>>> This patch you put into 3.18.0 appears to break the latest version of
>>>>> stubdomains. I found this out today when I tried to update a machine to
>>>>> 3.18.0 and all of the domUs crashed on start with the dmesg output like
>>>>> this:
>>>>
>>>> Cc'ing the lists and relevant netback maintainers.
>>>>
>>>> I guess the stubdoms are using minios's netfront?  This is something I
>>>> forgot about when deciding if it was ok to make this feature mandatory.
>>>
>>> Oh bum, me too :/
>>>
>>>> The patch cannot be reverted as it's a prerequisite for a critical
>>>> (security) bug fix.  I am also unconvinced that the no-feature-rx-notify
>>>> support worked correctly anyway.
>>>>
>>>> This can be resolved by:
>>>>
>>>> - Fixing minios's netfront to support feature-rx-notify. This should be
>>>> easy but wouldn't help existing Xen deployments.
>>>
>>> I think this is worth doing in its own right, but as you say it doesn't
>>> help existing users.
>>>
>>>> - Reimplement feature-rx-notify support.  I think the easiest way is to
>>>> queue packets on the guest Rx internal queue with a short expiry time.
>>>
>>> Right, I don't think we especially need to make this case good (so long
>>> as it doesn't reintroduce a security hole!).
>>>
>>> In principal we aren't really obliged to queue at all, but since all the
>>> infrastructure for queuing and timing out all exists I suppose it would
>>> be simple enough to implement and a bit less harsh.
>>>
>>> Given we now have XENVIF_RX_QUEUE_BYTES and rx_drain_timeout_jiffies we
>>> don't have the infinite queue any more. So does the expiry in this case
>>> actually need to be shorter than the norm? Does it cause any extra
>>> issues to keep them around for tx_drain_timeout_jiffies rather than some
>>> shorter time?
>>
>> If the internal guest rx queue fills and the (host) tx queue is stopped,
>> it will take tx_drain_timeout for the thread to wake up and notice if
>> the frontend placed any rx requests on the ring.  This could potentially
>> end up where you shovel 512k through stall for 10 s, put another 512k
>> through, stall for 10 s again and so on.
> 
> Ah, true, that's not so great.
> 
> What about if we don't queue at all(*) if rx-notify isn't supported, i.e
> just drop the packet on the floor in start_xmit if the ring is full?
> Would that be so bad? It would surely be simple...

There needs to be a queue between start_xmit and the rx thread so
checking for ring state in start_xmit doesn't help here since the
internal queue can fill before the thread wakes and begins to drain it.

netback could complete the request directly in start_xmit, avoiding the
internal queue but not allowing for any batching but I don't think it is
a good idea to add a different data path for this mode.

> (*) Not counting the "queue" which is the ring itself.
> 
>> The rx stall detection will also need to be disabled since there would
>> be no way for the frontend to signal rx ready.
> 
> Agreed.
> 
> Could be trivially argued to be safe if we were just dropping packets on
> ring overflow...

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 18:40:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 18:40:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XymB2-0001iS-S5; Wed, 10 Dec 2014 18:39: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 1XymB1-0001iM-A0
	for Xen-devel@lists.xen.org; Wed, 10 Dec 2014 18:39:55 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	C3/8D-17694-A7398845; Wed, 10 Dec 2014 18:39:54 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418236791!12457154!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 9400 invoked from network); 10 Dec 2014 18:39:53 -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 Dec 2014 18:39:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="202976682"
Message-ID: <54889372.4070007@citrix.com>
Date: Wed, 10 Dec 2014 18:39:46 +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: Ian Campbell <Ian.Campbell@citrix.com>
References: <54884DA8.7030003@nuclearfallout.net>		
	<548854C3.7060008@citrix.com>
	<1418224039.3505.76.camel@citrix.com>	
	<548866D9.5050900@citrix.com> <1418228446.3505.81.camel@citrix.com>
In-Reply-To: <1418228446.3505.81.camel@citrix.com>
X-DLP: MIA1
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Wei Liu <wei.liu2@citrix.com>, John <jw@nuclearfallout.net>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen-netback: make feature-rx-notify mandatory --
	Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 16:20, Ian Campbell wrote:
> On Wed, 2014-12-10 at 15:29 +0000, David Vrabel wrote:
>> On 10/12/14 15:07, Ian Campbell wrote:
>>> On Wed, 2014-12-10 at 14:12 +0000, David Vrabel wrote:
>>>> On 10/12/14 13:42, John wrote:
>>>>> David,
>>>>>
>>>>> This patch you put into 3.18.0 appears to break the latest version of
>>>>> stubdomains. I found this out today when I tried to update a machine to
>>>>> 3.18.0 and all of the domUs crashed on start with the dmesg output like
>>>>> this:
>>>>
>>>> Cc'ing the lists and relevant netback maintainers.
>>>>
>>>> I guess the stubdoms are using minios's netfront?  This is something I
>>>> forgot about when deciding if it was ok to make this feature mandatory.
>>>
>>> Oh bum, me too :/
>>>
>>>> The patch cannot be reverted as it's a prerequisite for a critical
>>>> (security) bug fix.  I am also unconvinced that the no-feature-rx-notify
>>>> support worked correctly anyway.
>>>>
>>>> This can be resolved by:
>>>>
>>>> - Fixing minios's netfront to support feature-rx-notify. This should be
>>>> easy but wouldn't help existing Xen deployments.
>>>
>>> I think this is worth doing in its own right, but as you say it doesn't
>>> help existing users.
>>>
>>>> - Reimplement feature-rx-notify support.  I think the easiest way is to
>>>> queue packets on the guest Rx internal queue with a short expiry time.
>>>
>>> Right, I don't think we especially need to make this case good (so long
>>> as it doesn't reintroduce a security hole!).
>>>
>>> In principal we aren't really obliged to queue at all, but since all the
>>> infrastructure for queuing and timing out all exists I suppose it would
>>> be simple enough to implement and a bit less harsh.
>>>
>>> Given we now have XENVIF_RX_QUEUE_BYTES and rx_drain_timeout_jiffies we
>>> don't have the infinite queue any more. So does the expiry in this case
>>> actually need to be shorter than the norm? Does it cause any extra
>>> issues to keep them around for tx_drain_timeout_jiffies rather than some
>>> shorter time?
>>
>> If the internal guest rx queue fills and the (host) tx queue is stopped,
>> it will take tx_drain_timeout for the thread to wake up and notice if
>> the frontend placed any rx requests on the ring.  This could potentially
>> end up where you shovel 512k through stall for 10 s, put another 512k
>> through, stall for 10 s again and so on.
> 
> Ah, true, that's not so great.
> 
> What about if we don't queue at all(*) if rx-notify isn't supported, i.e
> just drop the packet on the floor in start_xmit if the ring is full?
> Would that be so bad? It would surely be simple...

There needs to be a queue between start_xmit and the rx thread so
checking for ring state in start_xmit doesn't help here since the
internal queue can fill before the thread wakes and begins to drain it.

netback could complete the request directly in start_xmit, avoiding the
internal queue but not allowing for any batching but I don't think it is
a good idea to add a different data path for this mode.

> (*) Not counting the "queue" which is the ring itself.
> 
>> The rx stall detection will also need to be disabled since there would
>> be no way for the frontend to signal rx ready.
> 
> Agreed.
> 
> Could be trivially argued to be safe if we were just dropping packets on
> ring overflow...

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 20:21:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 20: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 1Xynl9-0005FM-0Y; Wed, 10 Dec 2014 20: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 1Xynl7-0005FH-Dg
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 20:21:17 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	10/1E-14214-C3BA8845; Wed, 10 Dec 2014 20:21:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418242874!5082569!1
X-Originating-IP: [156.151.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 20904 invoked from network); 10 Dec 2014 20:21:15 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 20:21: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 sBAKL6Bv029302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 20:21: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
	sBAKL54S011952
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 20:21: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
	sBAKL54r011946; Wed, 10 Dec 2014 20:21:05 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 12:21:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8DD26122E13; Wed, 10 Dec 2014 15:21:03 -0500 (EST)
Date: Wed, 10 Dec 2014 15:21:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141210202103.GA12367@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<5486DB5E020000780004E09A@mail.emea.novell.com>
	<5487A8F0.2010701@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5487A8F0.2010701@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 09:59:12AM +0800, Chen, Tiejun wrote:
> On 2014/12/9 18:22, Jan Beulich wrote:
> >>>>On 09.12.14 at 11:11, <tim@xen.org> wrote:
> >>At 08:19 +0000 on 09 Dec (1418109561), Jan Beulich wrote:
> >>>Why do you always pick other than the simplest possible solution?
> >>
> >>Jan, please don't make personal comments like this in code review.  It
> >>can only offend and demoralize contributors, and deter other people
> >>from joining in.
> >
> >I apologize - I shouldn't have permitted myself to do so.
> >
> >>I understand that it can be frustrating, and I'm sure I have lashed
> 
> Actually myself also have this same feeling but this really isn't helpful to
> step forward.
> 
> >>out at people on-list in the past.  But remember that people who are
> >>new to the project need time to learn, and keep the comments to the
> >>code itself.
> >>
> >>I can see that this series has been going for a long time, and is
> >>still getting hung up on coding style issues.  Might it be useful to
> 
> Something is my fault here. Although I learn more about Xen from this series
> constantly, looks its hard to cover this big thread with that reasonable
> code under Xen circumstance. This is also why I claimed I can't do this
> right from the start.
> 
> And additionally, even some initial designs are not very clear or argued
> between us, so when we discuss something during each revision, it bring a
> new thought again...

<nods>
> 
> >>have a round of internal review from some of the more xen-experienced
> >>engineers at Intel before Jan looks at it again?
> >
> >I've been suggesting something along those lines a number of times,
> >with (apparently) no success at all.
> >
> 
> Actually we had a little bit discussion internal and some guys really
> brought me some comments previously, but I think they're too busy to review
> each patch carefully one line by one line, especially if I bring something
> new to address yours comments just in the process of public review.
> 
> Anyway, now let me ask if this can deliver to other suitable guy. As I said
> previously I really would like to quit if this can step next properly.

Bummer. I was really looking forward to more patches from you. I understand
the frustration working throught this (my first patches in Linux took 9
months!) and I was hoping that you having to go through a pretty complex
code and getting the it done (with twist and turns at every corner) the
end result would be:
 - You would understand the Xen codebase at an expert level!
 - And would be able to contribute to Xen on other features knowing
   pitfalls, etc.
 - You would be able to help other engineers that start working on Xen
   how to do it.
 - Comfrotably review other folks patches.

Is there something that can be done for you to not step away?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 20:21:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 20: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 1Xynl9-0005FM-0Y; Wed, 10 Dec 2014 20: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 1Xynl7-0005FH-Dg
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 20:21:17 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	10/1E-14214-C3BA8845; Wed, 10 Dec 2014 20:21:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418242874!5082569!1
X-Originating-IP: [156.151.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 20904 invoked from network); 10 Dec 2014 20:21:15 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Dec 2014 20:21: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 sBAKL6Bv029302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 20:21: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
	sBAKL54S011952
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 20:21: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
	sBAKL54r011946; Wed, 10 Dec 2014 20:21:05 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 12:21:04 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8DD26122E13; Wed, 10 Dec 2014 15:21:03 -0500 (EST)
Date: Wed, 10 Dec 2014 15:21:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Message-ID: <20141210202103.GA12367@laptop.dumpdata.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<5486DB5E020000780004E09A@mail.emea.novell.com>
	<5487A8F0.2010701@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5487A8F0.2010701@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 09:59:12AM +0800, Chen, Tiejun wrote:
> On 2014/12/9 18:22, Jan Beulich wrote:
> >>>>On 09.12.14 at 11:11, <tim@xen.org> wrote:
> >>At 08:19 +0000 on 09 Dec (1418109561), Jan Beulich wrote:
> >>>Why do you always pick other than the simplest possible solution?
> >>
> >>Jan, please don't make personal comments like this in code review.  It
> >>can only offend and demoralize contributors, and deter other people
> >>from joining in.
> >
> >I apologize - I shouldn't have permitted myself to do so.
> >
> >>I understand that it can be frustrating, and I'm sure I have lashed
> 
> Actually myself also have this same feeling but this really isn't helpful to
> step forward.
> 
> >>out at people on-list in the past.  But remember that people who are
> >>new to the project need time to learn, and keep the comments to the
> >>code itself.
> >>
> >>I can see that this series has been going for a long time, and is
> >>still getting hung up on coding style issues.  Might it be useful to
> 
> Something is my fault here. Although I learn more about Xen from this series
> constantly, looks its hard to cover this big thread with that reasonable
> code under Xen circumstance. This is also why I claimed I can't do this
> right from the start.
> 
> And additionally, even some initial designs are not very clear or argued
> between us, so when we discuss something during each revision, it bring a
> new thought again...

<nods>
> 
> >>have a round of internal review from some of the more xen-experienced
> >>engineers at Intel before Jan looks at it again?
> >
> >I've been suggesting something along those lines a number of times,
> >with (apparently) no success at all.
> >
> 
> Actually we had a little bit discussion internal and some guys really
> brought me some comments previously, but I think they're too busy to review
> each patch carefully one line by one line, especially if I bring something
> new to address yours comments just in the process of public review.
> 
> Anyway, now let me ask if this can deliver to other suitable guy. As I said
> previously I really would like to quit if this can step next properly.

Bummer. I was really looking forward to more patches from you. I understand
the frustration working throught this (my first patches in Linux took 9
months!) and I was hoping that you having to go through a pretty complex
code and getting the it done (with twist and turns at every corner) the
end result would be:
 - You would understand the Xen codebase at an expert level!
 - And would be able to contribute to Xen on other features knowing
   pitfalls, etc.
 - You would be able to help other engineers that start working on Xen
   how to do it.
 - Comfrotably review other folks patches.

Is there something that can be done for you to not step away?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 20:43:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 20: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 1Xyo62-00064d-A5; Wed, 10 Dec 2014 20:42: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 1Xyo61-00062e-4f
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 20:42:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	ED/E9-09842-C40B8845; Wed, 10 Dec 2014 20:42:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418244170!7469412!1
X-Originating-IP: [156.151.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 15126 invoked from network); 10 Dec 2014 20:42:51 -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; 10 Dec 2014 20:42: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 sBAKgTnp021621
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 20:42:31 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
	sBAKgSYq014431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 20:42:28 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
	sBAKgRSY008397; Wed, 10 Dec 2014 20:42:27 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 12:42:27 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B1541122E63; Wed, 10 Dec 2014 15:42:26 -0500 (EST)
Date: Wed, 10 Dec 2014 15:42:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>, m.a.young@durham.ac.uk
Message-ID: <20141210204226.GA13076@laptop.dumpdata.com>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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, Dec 08, 2014 at 11:18:05AM +0100, Olaf Hering wrote:
> This is a resend of this series, with just the low hanging fruits:
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
> 

This looks like it would fix some of the issues I saw. I will test it
over today.

Please also CC Michael (Fedora Xen maintainer) on these changes (I've CC-ed
him here).

 The mentioned wrapper to run xenstored from systemd without duplicate
> functionality found in the sysv runlevel script will be send in another patch,
> once it is ready.
> 
> Olaf
> 
> Olaf Hering (4):
>   tools/hotplug: remove SELinux options from var-lib-xenstored.mount
>   tools/hotplug: remove XENSTORED_ROOTDIR from service file
>   tools/hotplug: remove EnvironmentFile from
>     xen-qemu-dom0-disk-backend.service
>   tools/hotplug: use xencommons as EnvironmentFile
> 
>  tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 4 +---
>  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
>  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 2 +-
>  tools/hotplug/Linux/systemd/xenstored.service.in                  | 1 -
>  4 files changed, 2 insertions(+), 6 deletions(-)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 20:43:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 20: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 1Xyo62-00064d-A5; Wed, 10 Dec 2014 20:42: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 1Xyo61-00062e-4f
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 20:42:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	ED/E9-09842-C40B8845; Wed, 10 Dec 2014 20:42:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418244170!7469412!1
X-Originating-IP: [156.151.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 15126 invoked from network); 10 Dec 2014 20:42:51 -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; 10 Dec 2014 20:42: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 sBAKgTnp021621
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 20:42:31 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
	sBAKgSYq014431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 10 Dec 2014 20:42:28 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
	sBAKgRSY008397; Wed, 10 Dec 2014 20:42:27 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 12:42:27 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id B1541122E63; Wed, 10 Dec 2014 15:42:26 -0500 (EST)
Date: Wed, 10 Dec 2014 15:42:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>, m.a.young@durham.ac.uk
Message-ID: <20141210204226.GA13076@laptop.dumpdata.com>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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, Dec 08, 2014 at 11:18:05AM +0100, Olaf Hering wrote:
> This is a resend of this series, with just the low hanging fruits:
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
> 

This looks like it would fix some of the issues I saw. I will test it
over today.

Please also CC Michael (Fedora Xen maintainer) on these changes (I've CC-ed
him here).

 The mentioned wrapper to run xenstored from systemd without duplicate
> functionality found in the sysv runlevel script will be send in another patch,
> once it is ready.
> 
> Olaf
> 
> Olaf Hering (4):
>   tools/hotplug: remove SELinux options from var-lib-xenstored.mount
>   tools/hotplug: remove XENSTORED_ROOTDIR from service file
>   tools/hotplug: remove EnvironmentFile from
>     xen-qemu-dom0-disk-backend.service
>   tools/hotplug: use xencommons as EnvironmentFile
> 
>  tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 4 +---
>  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
>  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 2 +-
>  tools/hotplug/Linux/systemd/xenstored.service.in                  | 1 -
>  4 files changed, 2 insertions(+), 6 deletions(-)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 20:46:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 20:46:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyo9g-0006QD-V0; Wed, 10 Dec 2014 20:46:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bjoern@clothesnetwork.com>) id 1XynvA-0005h7-NB
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 20:31:40 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	D8/E4-18267-CADA8845; Wed, 10 Dec 2014 20:31:40 +0000
X-Env-Sender: bjoern@clothesnetwork.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418243499!12475246!1
X-Originating-IP: [213.239.215.232]
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 23241 invoked from network); 10 Dec 2014 20:31:39 -0000
Received: from 213-239-215-232.clients.your-server.de (HELO ?213.239.215.232?)
	(213.239.215.232) by server-5.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 20:31:39 -0000
Received: from localhost (localhost [127.0.0.1])
	by thewebagency.org (Postfix) with ESMTP id 870BB80416
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 21:31:39 +0100 (CET)
Received: from [213.239.215.232] ([10.0.0.2])
	by localhost (mail.thewebagency.org [10.0.0.2]) (amavisd-new,
	port 10024) with ESMTP id 3fuNJg8mtri5 for <xen-devel@lists.xen.org>;
	Wed, 10 Dec 2014 21:31:39 +0100 (CET)
Received: from localhost (unknown [88.96.159.118])
	by thewebagency.org (Postfix) with ESMTPSA id 1CF7080311
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 21:31:39 +0100 (CET)
Date: Wed, 10 Dec 2014 20:25:25 +0000
From: Bjoern Rennhak <bjoern@clothesnetwork.com>
To: xen-devel@lists.xen.org
Message-ID: <20141210202525.GA20557@rennhak.de>
MIME-Version: 1.0
Content-Disposition: inline
X-URL: http://www.rennhak.com/
X-Operating-System: GNU/Linux Gentoo - Linux 3.13.0-rc3-linus-git-rennhak+ on
	a i686
X-Registered-Linux-User: 451519
X-Crypto: GnuPG/2.0.25 http://www.gnupg.org
X-GPG-Key-ID: 0x1122967D
X-GPG-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE9EE5EBA1122967D
X-GPG-Fingerprint: B2CC 3175 3A25 9616 F121 90FB E9EE 5EBA 1122 967D
X-Uptime: 11:30:15 up 18 days, 12:17, 13 users,  load average: 0.08, 0.05, 0.10
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Mailman-Approved-At: Wed, 10 Dec 2014 20:46:39 +0000
Subject: [Xen-devel] Question reg. named vif interface support in guest cfg; 
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dear Xen Developers,

I found handling of vifx.y interfaces slightly unintutive and was
wondering if it is possible to name the interface via the Xen guest
config file?

e.g. a vif_name parameter or otherwise maybe vif interface is automatically named
after set "name" entry in config instead of generic vifx.y.

So instead of a bunch of vifx.y's I would see <descriptivename>x.y ?

Is that already possible or a bad idea in general?
Should I open a wishlist entry on http://bugs.xenproject.org/xen/?

Thank you!

Cheers,
-Bjoern


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 20:46:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 20:46:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyo9g-0006QD-V0; Wed, 10 Dec 2014 20:46:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bjoern@clothesnetwork.com>) id 1XynvA-0005h7-NB
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 20:31:40 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	D8/E4-18267-CADA8845; Wed, 10 Dec 2014 20:31:40 +0000
X-Env-Sender: bjoern@clothesnetwork.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418243499!12475246!1
X-Originating-IP: [213.239.215.232]
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 23241 invoked from network); 10 Dec 2014 20:31:39 -0000
Received: from 213-239-215-232.clients.your-server.de (HELO ?213.239.215.232?)
	(213.239.215.232) by server-5.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 20:31:39 -0000
Received: from localhost (localhost [127.0.0.1])
	by thewebagency.org (Postfix) with ESMTP id 870BB80416
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 21:31:39 +0100 (CET)
Received: from [213.239.215.232] ([10.0.0.2])
	by localhost (mail.thewebagency.org [10.0.0.2]) (amavisd-new,
	port 10024) with ESMTP id 3fuNJg8mtri5 for <xen-devel@lists.xen.org>;
	Wed, 10 Dec 2014 21:31:39 +0100 (CET)
Received: from localhost (unknown [88.96.159.118])
	by thewebagency.org (Postfix) with ESMTPSA id 1CF7080311
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 21:31:39 +0100 (CET)
Date: Wed, 10 Dec 2014 20:25:25 +0000
From: Bjoern Rennhak <bjoern@clothesnetwork.com>
To: xen-devel@lists.xen.org
Message-ID: <20141210202525.GA20557@rennhak.de>
MIME-Version: 1.0
Content-Disposition: inline
X-URL: http://www.rennhak.com/
X-Operating-System: GNU/Linux Gentoo - Linux 3.13.0-rc3-linus-git-rennhak+ on
	a i686
X-Registered-Linux-User: 451519
X-Crypto: GnuPG/2.0.25 http://www.gnupg.org
X-GPG-Key-ID: 0x1122967D
X-GPG-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE9EE5EBA1122967D
X-GPG-Fingerprint: B2CC 3175 3A25 9616 F121 90FB E9EE 5EBA 1122 967D
X-Uptime: 11:30:15 up 18 days, 12:17, 13 users,  load average: 0.08, 0.05, 0.10
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Mailman-Approved-At: Wed, 10 Dec 2014 20:46:39 +0000
Subject: [Xen-devel] Question reg. named vif interface support in guest cfg; 
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dear Xen Developers,

I found handling of vifx.y interfaces slightly unintutive and was
wondering if it is possible to name the interface via the Xen guest
config file?

e.g. a vif_name parameter or otherwise maybe vif interface is automatically named
after set "name" entry in config instead of generic vifx.y.

So instead of a bunch of vifx.y's I would see <descriptivename>x.y ?

Is that already possible or a bad idea in general?
Should I open a wishlist entry on http://bugs.xenproject.org/xen/?

Thank you!

Cheers,
-Bjoern


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 20:57:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 20: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 1XyoKH-0006rP-4G; Wed, 10 Dec 2014 20:57: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 1XyoKF-0006rK-NI
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 20:57:35 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	6E/21-27584-FB3B8845; Wed, 10 Dec 2014 20:57:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418245052!8548763!1
X-Originating-IP: [156.151.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 28798 invoked from network); 10 Dec 2014 20:57:34 -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 Dec 2014 20:57:34 -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 sBAKvTXr006366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 20:57: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
	sBAKvSWg028112
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Dec 2014 20:57:29 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
	sBAKvSWr028076; Wed, 10 Dec 2014 20:57:28 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 12:57:27 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E3837122E9E; Wed, 10 Dec 2014 15:57:26 -0500 (EST)
Date: Wed, 10 Dec 2014 15:57:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: axboe@fb.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Message-ID: <20141210205726.GA13822@laptop.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [GIT PULL] (xen) for-jens-3.19 for v3.19 Xen blkfront
	driver 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="===============8651290769989723730=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8651290769989723730==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK"
Content-Disposition: inline


--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Jens,

These are two fixes for Xen blkfront. They harden how it deals with
broken backends.

Please git pull the following branch:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git for-jens-3.19

in your for-3.19-drivers branch. This branch is based on:
9af8785 NVMe: Fix command setup on IO retry

Thanks!

The changelog:

drivers/block/xen-blkfront.c | 65 ++++++++++++++++++++++++++------------------
 1 file changed, 39 insertions(+), 26 deletions(-)

Vitaly Kuznetsov (2):
      xen/blkfront: improve protection against issuing unsupported REQ_FUA
      xen/blkfront: remove redundant flush_op


--YZ5djTAD1cGYuMQK
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUiLOyAAoJEFjIrFwIi8fJmT8IAIKqaJmH8LJVwddN7wz1LtNS
75WqyXuTsx8yFptqpRlbF80W6oRmDJZ7UWiNhKC8var8/uv6jVY11HdcmU2TZJQh
W+Tl63GYDkgqP42+ahD6CGFD1beB+fVUSVDVf+D4qe9pF+0nBHum9L4F5NMoqE+s
sOhTIhmHaLQ7jYdjPKjW0sigNP3T0pRSCY5dQfboBxFnUgnOkmxPB4SFwB3LFcjj
TNVjCZIc8sjYaOjEY39W+gKyGiukKAUkwGgmy8Klgh+Sp5SbGEH3ErtmHmuYFh/X
CbupR/Mj5xMUSs6QH4jkch/NxUUsqGZrA2goDL23HD0ustqzF5sXEowbui9lNZ0=
=BJFW
-----END PGP SIGNATURE-----

--YZ5djTAD1cGYuMQK--


--===============8651290769989723730==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8651290769989723730==--


From xen-devel-bounces@lists.xen.org Wed Dec 10 20:57:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 20: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 1XyoKH-0006rP-4G; Wed, 10 Dec 2014 20:57: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 1XyoKF-0006rK-NI
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 20:57:35 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	6E/21-27584-FB3B8845; Wed, 10 Dec 2014 20:57:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418245052!8548763!1
X-Originating-IP: [156.151.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 28798 invoked from network); 10 Dec 2014 20:57:34 -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 Dec 2014 20:57:34 -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 sBAKvTXr006366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 20:57: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
	sBAKvSWg028112
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Dec 2014 20:57:29 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
	sBAKvSWr028076; Wed, 10 Dec 2014 20:57:28 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 12:57:27 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E3837122E9E; Wed, 10 Dec 2014 15:57:26 -0500 (EST)
Date: Wed, 10 Dec 2014 15:57:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: axboe@fb.com, linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Message-ID: <20141210205726.GA13822@laptop.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [GIT PULL] (xen) for-jens-3.19 for v3.19 Xen blkfront
	driver 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="===============8651290769989723730=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8651290769989723730==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK"
Content-Disposition: inline


--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Jens,

These are two fixes for Xen blkfront. They harden how it deals with
broken backends.

Please git pull the following branch:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git for-jens-3.19

in your for-3.19-drivers branch. This branch is based on:
9af8785 NVMe: Fix command setup on IO retry

Thanks!

The changelog:

drivers/block/xen-blkfront.c | 65 ++++++++++++++++++++++++++------------------
 1 file changed, 39 insertions(+), 26 deletions(-)

Vitaly Kuznetsov (2):
      xen/blkfront: improve protection against issuing unsupported REQ_FUA
      xen/blkfront: remove redundant flush_op


--YZ5djTAD1cGYuMQK
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUiLOyAAoJEFjIrFwIi8fJmT8IAIKqaJmH8LJVwddN7wz1LtNS
75WqyXuTsx8yFptqpRlbF80W6oRmDJZ7UWiNhKC8var8/uv6jVY11HdcmU2TZJQh
W+Tl63GYDkgqP42+ahD6CGFD1beB+fVUSVDVf+D4qe9pF+0nBHum9L4F5NMoqE+s
sOhTIhmHaLQ7jYdjPKjW0sigNP3T0pRSCY5dQfboBxFnUgnOkmxPB4SFwB3LFcjj
TNVjCZIc8sjYaOjEY39W+gKyGiukKAUkwGgmy8Klgh+Sp5SbGEH3ErtmHmuYFh/X
CbupR/Mj5xMUSs6QH4jkch/NxUUsqGZrA2goDL23HD0ustqzF5sXEowbui9lNZ0=
=BJFW
-----END PGP SIGNATURE-----

--YZ5djTAD1cGYuMQK--


--===============8651290769989723730==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8651290769989723730==--


From xen-devel-bounces@lists.xen.org Wed Dec 10 21:04:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 21: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 1XyoQ8-0007J0-TK; Wed, 10 Dec 2014 21:03:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=7421c5fa95=axboe@fb.com>) id 1XyoQ7-0007Iv-SN
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 21:03:40 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	D2/58-25727-B25B8845; Wed, 10 Dec 2014 21:03:39 +0000
X-Env-Sender: prvs=7421c5fa95=axboe@fb.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418245418!12410603!1
X-Originating-IP: [67.231.153.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjcuMjMxLjE1My4zMCA9PiAxNTc0MDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10105 invoked from network); 10 Dec 2014 21:03:38 -0000
Received: from mx0b-00082601.pphosted.com (HELO mx0b-00082601.pphosted.com)
	(67.231.153.30) by server-4.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 21:03:38 -0000
Received: from pps.filterd (m0004077 [127.0.0.1])
	by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id
	sBAL3Kwn013644; Wed, 10 Dec 2014 13:03:37 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com;
	h=message-id : date : from :
	mime-version : to : subject : references : in-reply-to : content-type :
	content-transfer-encoding; s=facebook;
	bh=g7kR3iDfq/+2zeq2Imhzi8m2XwHVSceYND0Zsa53WSc=;
	b=nLTYxegJhG92JEf62I0NK3lTDutHlIHz0EGlshGFEZJgLsz8d2XRkDYvlikTcuiR3NA2
	yDLlG8NimaWO0jK3iZtORDmOTZyt1wHEOBKqAuZ9KvQKPxPzLgJR98LC0jXhXxrmTi51
	9ftHAkZATFIDZixrPVbN1KdI2ojflf4+EvA= 
Received: from mail.thefacebook.com ([199.201.64.23])
	by mx0b-00082601.pphosted.com with ESMTP id 1r6tm60vg1-4
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK);
	Wed, 10 Dec 2014 13:03:37 -0800
Received: from [192.168.3.12] (192.168.57.29) by mail.thefacebook.com
	(192.168.16.14) with Microsoft SMTP Server (TLS) id 14.3.195.1;
	Wed, 10 Dec 2014 13:03:35 -0800
Message-ID: <5488B52C.1000202@fb.com>
Date: Wed, 10 Dec 2014 14:03:40 -0700
From: Jens Axboe <axboe@fb.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	<linux-kernel@vger.kernel.org>, <xen-devel@lists.xensource.com>
References: <20141210205726.GA13822@laptop.dumpdata.com>
In-Reply-To: <20141210205726.GA13822@laptop.dumpdata.com>
X-Originating-IP: [192.168.57.29]
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33,
	0.0.0000
	definitions=2014-12-10_08:2014-12-10, 2014-12-10,
	1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0
	kscore.is_bulkscore=0
	kscore.compositescore=0 circleOfTrustscore=0
	compositescore=0.925924926977281 urlsuspect_oldscore=0.925924926977281
	suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0
	bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0
	recipient_domain_to_sender_domain_totalscore=64355
	rbsscore=0.925924926977281 spamscore=0
	recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9
	adultscore=0
	classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000
	definitions=main-1412100198
X-FB-Internal: deliver
Subject: Re: [Xen-devel] [GIT PULL] (xen) for-jens-3.19 for v3.19 Xen
 blkfront driver 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 12/10/2014 01:57 PM, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
> 
> These are two fixes for Xen blkfront. They harden how it deals with
> broken backends.

Pulled, thanks.


-- 
Jens Axboe


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 21:04:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 21: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 1XyoQ8-0007J0-TK; Wed, 10 Dec 2014 21:03:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=7421c5fa95=axboe@fb.com>) id 1XyoQ7-0007Iv-SN
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 21:03:40 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	D2/58-25727-B25B8845; Wed, 10 Dec 2014 21:03:39 +0000
X-Env-Sender: prvs=7421c5fa95=axboe@fb.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418245418!12410603!1
X-Originating-IP: [67.231.153.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjcuMjMxLjE1My4zMCA9PiAxNTc0MDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10105 invoked from network); 10 Dec 2014 21:03:38 -0000
Received: from mx0b-00082601.pphosted.com (HELO mx0b-00082601.pphosted.com)
	(67.231.153.30) by server-4.tower-31.messagelabs.com with SMTP;
	10 Dec 2014 21:03:38 -0000
Received: from pps.filterd (m0004077 [127.0.0.1])
	by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id
	sBAL3Kwn013644; Wed, 10 Dec 2014 13:03:37 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com;
	h=message-id : date : from :
	mime-version : to : subject : references : in-reply-to : content-type :
	content-transfer-encoding; s=facebook;
	bh=g7kR3iDfq/+2zeq2Imhzi8m2XwHVSceYND0Zsa53WSc=;
	b=nLTYxegJhG92JEf62I0NK3lTDutHlIHz0EGlshGFEZJgLsz8d2XRkDYvlikTcuiR3NA2
	yDLlG8NimaWO0jK3iZtORDmOTZyt1wHEOBKqAuZ9KvQKPxPzLgJR98LC0jXhXxrmTi51
	9ftHAkZATFIDZixrPVbN1KdI2ojflf4+EvA= 
Received: from mail.thefacebook.com ([199.201.64.23])
	by mx0b-00082601.pphosted.com with ESMTP id 1r6tm60vg1-4
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK);
	Wed, 10 Dec 2014 13:03:37 -0800
Received: from [192.168.3.12] (192.168.57.29) by mail.thefacebook.com
	(192.168.16.14) with Microsoft SMTP Server (TLS) id 14.3.195.1;
	Wed, 10 Dec 2014 13:03:35 -0800
Message-ID: <5488B52C.1000202@fb.com>
Date: Wed, 10 Dec 2014 14:03:40 -0700
From: Jens Axboe <axboe@fb.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	<linux-kernel@vger.kernel.org>, <xen-devel@lists.xensource.com>
References: <20141210205726.GA13822@laptop.dumpdata.com>
In-Reply-To: <20141210205726.GA13822@laptop.dumpdata.com>
X-Originating-IP: [192.168.57.29]
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33,
	0.0.0000
	definitions=2014-12-10_08:2014-12-10, 2014-12-10,
	1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0
	kscore.is_bulkscore=0
	kscore.compositescore=0 circleOfTrustscore=0
	compositescore=0.925924926977281 urlsuspect_oldscore=0.925924926977281
	suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0
	bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0
	recipient_domain_to_sender_domain_totalscore=64355
	rbsscore=0.925924926977281 spamscore=0
	recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9
	adultscore=0
	classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000
	definitions=main-1412100198
X-FB-Internal: deliver
Subject: Re: [Xen-devel] [GIT PULL] (xen) for-jens-3.19 for v3.19 Xen
 blkfront driver 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 12/10/2014 01:57 PM, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
> 
> These are two fixes for Xen blkfront. They harden how it deals with
> broken backends.

Pulled, thanks.


-- 
Jens Axboe


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 21:04:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 21:04:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyoQc-0007L5-9z; Wed, 10 Dec 2014 21:04:10 +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 1XyoQb-0007Kx-4y
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 21:04:09 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	5D/6E-02702-845B8845; Wed, 10 Dec 2014 21:04:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418245446!14287119!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28925 invoked from network); 10 Dec 2014 21:04:07 -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; 10 Dec 2014 21:04: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 sBAL43GN003641
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 21:04:03 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
	sBAL42wg020691
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Dec 2014 21:04:02 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
	sBAL41pv019743; Wed, 10 Dec 2014 21:04:01 GMT
Received: from l.oracle.com (/10.137.179.11)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 13:04:00 -0800
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, dario.faggioli@citrix.com
Date: Wed, 10 Dec 2014 16:03:47 -0500
Message-Id: <1418245427-28132-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 2.1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] Update it work with Fedora Core 21.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 fedora-live-xen.ks | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fedora-live-xen.ks b/fedora-live-xen.ks
index 58f94b1..c99e46c 100644
--- a/fedora-live-xen.ks
+++ b/fedora-live-xen.ks
@@ -8,6 +8,7 @@
 repo --name=virt-preview --baseurl=http://fedorapeople.org/groups/virt/virt-preview/fedora-$releasever/$basearch
 # What about updates-testing reository? Well, why not!
 repo --name=updates-testing --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f$releasever&arch=$basearch
+repo --name=fedora --mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
 # And what about rawhide? Mmm... better not to go that far...
 #%include fedora-repo-rawhide.ks
 
@@ -45,7 +46,7 @@ xen*
 xen-devel
 libvirt-daemon-xen
 -gnome-boxes
-
+firewalld
 # Get rid of a few heavy stuff
 -@libreoffice
 -@printing
-- 
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 Wed Dec 10 21:04:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 21:04:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyoQc-0007L5-9z; Wed, 10 Dec 2014 21:04:10 +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 1XyoQb-0007Kx-4y
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 21:04:09 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	5D/6E-02702-845B8845; Wed, 10 Dec 2014 21:04:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418245446!14287119!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28925 invoked from network); 10 Dec 2014 21:04:07 -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; 10 Dec 2014 21:04: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 sBAL43GN003641
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Dec 2014 21:04:03 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
	sBAL42wg020691
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Dec 2014 21:04:02 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
	sBAL41pv019743; Wed, 10 Dec 2014 21:04:01 GMT
Received: from l.oracle.com (/10.137.179.11)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Dec 2014 13:04:00 -0800
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xenproject.org, dario.faggioli@citrix.com
Date: Wed, 10 Dec 2014 16:03:47 -0500
Message-Id: <1418245427-28132-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 2.1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] Update it work with Fedora Core 21.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 fedora-live-xen.ks | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fedora-live-xen.ks b/fedora-live-xen.ks
index 58f94b1..c99e46c 100644
--- a/fedora-live-xen.ks
+++ b/fedora-live-xen.ks
@@ -8,6 +8,7 @@
 repo --name=virt-preview --baseurl=http://fedorapeople.org/groups/virt/virt-preview/fedora-$releasever/$basearch
 # What about updates-testing reository? Well, why not!
 repo --name=updates-testing --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f$releasever&arch=$basearch
+repo --name=fedora --mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
 # And what about rawhide? Mmm... better not to go that far...
 #%include fedora-repo-rawhide.ks
 
@@ -45,7 +46,7 @@ xen*
 xen-devel
 libvirt-daemon-xen
 -gnome-boxes
-
+firewalld
 # Get rid of a few heavy stuff
 -@libreoffice
 -@printing
-- 
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 Wed Dec 10 21:31:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 21: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 1XyoqK-0008E6-P5; Wed, 10 Dec 2014 21:30:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyoqJ-0008E1-Ey
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 21:30:43 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	1B/D2-22819-28BB8845; Wed, 10 Dec 2014 21:30:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418247038!5089533!1
X-Originating-IP: [66.165.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 19884 invoked from network); 10 Dec 2014 21:30:41 -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 Dec 2014 21:30:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="203060641"
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.210.2; Wed, 10 Dec 2014 16:30: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 1Xyoq9-0002B8-SA;
	Wed, 10 Dec 2014 21: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 1Xyoq8-0006h9-Uq;
	Wed, 10 Dec 2014 21:30:33 +0000
Date: Wed, 10 Dec 2014 21:30:32 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32219-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] 32219: 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 32219 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32219/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          d40acc2019bd352e1de13842459b5fecf5bc565e
baseline version:
 rumpuserxen          b0b7b13cadc971e8c5745880dcbb92bc2185765b

------------------------------------------------------------
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=d40acc2019bd352e1de13842459b5fecf5bc565e
+ . 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 d40acc2019bd352e1de13842459b5fecf5bc565e
+ branch=rumpuserxen
+ revision=d40acc2019bd352e1de13842459b5fecf5bc565e
+ . 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 d40acc2019bd352e1de13842459b5fecf5bc565e:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   b0b7b13..d40acc2  d40acc2019bd352e1de13842459b5fecf5bc565e -> 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 Dec 10 21:31:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 21: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 1XyoqK-0008E6-P5; Wed, 10 Dec 2014 21:30:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XyoqJ-0008E1-Ey
	for xen-devel@lists.xensource.com; Wed, 10 Dec 2014 21:30:43 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	1B/D2-22819-28BB8845; Wed, 10 Dec 2014 21:30:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418247038!5089533!1
X-Originating-IP: [66.165.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 19884 invoked from network); 10 Dec 2014 21:30:41 -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 Dec 2014 21:30:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="203060641"
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.210.2; Wed, 10 Dec 2014 16:30: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 1Xyoq9-0002B8-SA;
	Wed, 10 Dec 2014 21: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 1Xyoq8-0006h9-Uq;
	Wed, 10 Dec 2014 21:30:33 +0000
Date: Wed, 10 Dec 2014 21:30:32 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32219-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] 32219: 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 32219 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32219/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          d40acc2019bd352e1de13842459b5fecf5bc565e
baseline version:
 rumpuserxen          b0b7b13cadc971e8c5745880dcbb92bc2185765b

------------------------------------------------------------
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=d40acc2019bd352e1de13842459b5fecf5bc565e
+ . 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 d40acc2019bd352e1de13842459b5fecf5bc565e
+ branch=rumpuserxen
+ revision=d40acc2019bd352e1de13842459b5fecf5bc565e
+ . 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 d40acc2019bd352e1de13842459b5fecf5bc565e:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   b0b7b13..d40acc2  d40acc2019bd352e1de13842459b5fecf5bc565e -> 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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeB-0001lO-4G; Wed, 10 Dec 2014 22:22:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xype8-0001kF-O6
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	98/4C-25276-397C8845; Wed, 10 Dec 2014 22:22:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418250129!11351812!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31523 invoked from network); 10 Dec 2014 22:22:11 -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 Dec 2014 22:22:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679396"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-D3;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:30 +0000
Message-ID: <1418250095-13287-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 4/9] mfi-common: create
	build-$arch-xsm job
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
---
Changes in v4:
1. Use "true" and "false" instead of "y" and "n".
2. Rename xenbranch_wants_xsm_tests to xenbranch_xsm_variants.
---
 mfi-common |   23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/mfi-common b/mfi-common
index 5c4f5d5..161847c 100644
--- a/mfi-common
+++ b/mfi-common
@@ -41,6 +41,19 @@ branch_wants_rumpkernel_tests () {
   esac
 }
 
+xenbranch_xsm_variants () {
+    # Test XSM from 4.5 onwards
+    case "$xenbranch" in
+    xen-3.*-testing) echo "false";;
+    xen-4.0-testing) echo "false";;
+    xen-4.1-testing) echo "false";;
+    xen-4.2-testing) echo "false";;
+    xen-4.3-testing) echo "false";;
+    xen-4.4-testing) echo "false";;
+    *) echo "false true";
+    esac
+}
+
 create_build_jobs () {
 
   local arch
@@ -139,8 +152,15 @@ create_build_jobs () {
 
     build_hostflags=share-build-$suite-$arch,arch-$arch,suite-$suite,purpose-build
 
-    ./cs-job-create $flight build-$arch build                                \
+    for enable_xsm in $(xenbranch_xsm_variants) ; do
+      if [ x$enable_xsm = xtrue ] ; then
+        xsm_suffix="-xsm"
+      else
+        xsm_suffix=""
+      fi
+      ./cs-job-create $flight build-$arch$xsm_suffix build                   \
                 arch=$arch enable_xend=$build_defxend enable_ovmf=$enable_ovmf\
+                enable_xsm=$enable_xsm                                       \
         tree_qemu=$TREE_QEMU                                                 \
         tree_qemuu=$TREE_QEMU_UPSTREAM                                       \
         tree_xen=$TREE_XEN                                                   \
@@ -152,6 +172,7 @@ create_build_jobs () {
                 revision_qemu=$REVISION_QEMU                                 \
                 revision_qemuu=$REVISION_QEMU_UPSTREAM                       \
                 revision_seabios=$REVISION_SEABIOS
+    done
 
     if [ $build_extraxend = "true" ] ; then
     ./cs-job-create $flight build-$arch-xend build                           \
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeC-0001lx-KB; Wed, 10 Dec 2014 22:22:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XypeA-0001ko-7t
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AA/4C-25276-597C8845; Wed, 10 Dec 2014 22:22:13 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418250128!14438752!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21025 invoked from network); 10 Dec 2014 22:22:12 -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 Dec 2014 22:22:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679394"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-8N;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:27 +0000
Message-ID: <1418250095-13287-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 1/9] overlay: update
	overlay/etc/grub.d/20_linux_xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This file was originally created to work around Debian bug #633127
("/etc/grub/20_linux does not recognise some old Xen kernels").

According to Debian bug tracker [0], #633127 bug is fixed in Wheezy. As
we're now using Wheezy in OSSTest we can safely remove the old overlay
file if there's no further bugs discovered.

However we have another bug #690538 ("grub-common: Please make submenu
creation optional or at least allow users to disable it easily") that
would break OSSTest.  We're now using Wheezy in production. There's no
way to disable submenu in Wheezy. And submenu breaks OSSTest's grub menu
parser.

So update this overlay file to Wheezy's version and take care of Debian
bug #690538 by removing the lines to generate submenu.

Also work around GRUB bug #43420 ("20_linux_xen doesn't support Xen XSM
policy file") by applying a small patch proposed in [2].

Add a note to reference #633127 and #690538 above grub2 setup function.

0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633127
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690538
2: https://savannah.gnu.org/bugs/?43420

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Debian.pm               |    5 ++
 overlay/etc/grub.d/20_linux_xen |  117 +++++++++++++++++++++++++++++++--------
 2 files changed, 98 insertions(+), 24 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..c446e8b 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -274,6 +274,11 @@ sub setupboot_grub1 ($$$) {
     return $bl;
 }
 
+# Note on running OSSTest on Squeeze with old Xen kernel: check out
+# Debian bug #633127 "/etc/grub/20_linux does not recognise some old
+# Xen kernels"
+# Currently setupboot_grub2 relies on Grub menu not having submenu.
+# Check Debian bug #690538.
 sub setupboot_grub2 ($$$) {
     my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
     my $bl= { };
diff --git a/overlay/etc/grub.d/20_linux_xen b/overlay/etc/grub.d/20_linux_xen
index 99854d2..001b76d 100755
--- a/overlay/etc/grub.d/20_linux_xen
+++ b/overlay/etc/grub.d/20_linux_xen
@@ -1,7 +1,7 @@
 #! /bin/sh
 
-# Copied from the identically named file in grub-common 1.98+20100804-14
-# i386.  This version fixes #633127 (and has the patch I proposed there).
+# Copied from the identical named file in grub-common 1.99-27+deb7u2.
+# This version fixed Debian bug #690538 and GRUB bug #43420.
 
 set -e
 
@@ -21,14 +21,14 @@ set -e
 # You should have received a copy of the GNU General Public License
 # along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
 
-prefix=/usr
-exec_prefix=${prefix}
-bindir=${exec_prefix}/bin
-libdir=${exec_prefix}/lib
-. ${libdir}/grub/grub-mkconfig_lib
+prefix="/usr"
+exec_prefix="${prefix}"
+datarootdir="${prefix}/share"
+
+. "${datarootdir}/grub/grub-mkconfig_lib"
 
 export TEXTDOMAIN=grub
-export TEXTDOMAINDIR=${prefix}/share/locale
+export TEXTDOMAINDIR="${datarootdir}/locale"
 
 CLASS="--class gnu-linux --class gnu --class os --class xen"
 
@@ -36,7 +36,7 @@ if [ "x${GRUB_DISTRIBUTOR}" = "x" ] ; then
   OS=GNU/Linux
 else
   OS="${GRUB_DISTRIBUTOR} GNU/Linux"
-  CLASS="--class $(echo ${GRUB_DISTRIBUTOR} | tr '[A-Z]' '[a-z]' | cut -d' ' -f1) ${CLASS}"
+  CLASS="--class $(echo ${GRUB_DISTRIBUTOR} | tr 'A-Z' 'a-z' | cut -d' ' -f1) ${CLASS}"
 fi
 
 # loop-AES arranges things so that /dev/loop/X can be our root device, but
@@ -44,6 +44,11 @@ fi
 case ${GRUB_DEVICE} in
   /dev/loop/*|/dev/loop[0-9])
     GRUB_DEVICE=`losetup ${GRUB_DEVICE} | sed -e "s/^[^(]*(\([^)]\+\)).*/\1/"`
+    # We can't cope with devices loop-mounted from files here.
+    case ${GRUB_DEVICE} in
+      /dev/*) ;;
+      *) exit 0 ;;
+    esac
   ;;
 esac
 
@@ -55,6 +60,23 @@ else
   LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
 fi
 
+# Allow overriding GRUB_CMDLINE_LINUX and GRUB_CMDLINE_LINUX_DEFAULT.
+if [ "${GRUB_CMDLINE_LINUX_XEN_REPLACE}" ]; then
+  GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX_XEN_REPLACE}"
+fi
+if [ "${GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT}" ]; then
+  GRUB_CMDLINE_LINUX_DEFAULT="${GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT}"
+fi
+
+if [ "x`${grub_probe} --device ${GRUB_DEVICE} --target=fs 2>/dev/null || true`" = xbtrfs ] \
+    || [ "x`stat -f --printf=%T /`" = xbtrfs ]; then
+  rootsubvol="`make_system_path_relative_to_its_root /`"
+  rootsubvol="${rootsubvol#/}"
+  if [ "x${rootsubvol}" != x ]; then
+    GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
+  fi
+fi
+
 linux_entry ()
 {
   os="$1"
@@ -63,22 +85,43 @@ linux_entry ()
   recovery="$4"
   args="$5"
   xen_args="$6"
-  if ${recovery} ; then
-    title="$(gettext_quoted "%s, with Linux %s and XEN %s (recovery mode)")"
+  xsm="$7"
+  # If user wants to enable XSM support, make sure there's
+  # corresponding policy file.
+  if ${xsm} ; then
+      xenpolicy=`echo xenpolicy-$xen_version`
+      if test ! -e "${xen_dirname}/${xenpolicy}" ; then
+	  return
+      fi
+      xen_args=`echo $xen_args flask_enabled=1 flask_enforcing=1`
+      if ${recovery} ; then
+	  title="$(gettext_quoted "%s, with Xen %s (XSM enabled) and Linux %s (recovery mode)")"
+      else
+	  title="$(gettext_quoted "%s, with Xen %s (XSM enabled) and Linux %s")"
+      fi
   else
-    title="$(gettext_quoted "%s, with Linux %s and XEN %s")"
+      xenpolicy=""
+      if ${recovery} ; then
+	  title="$(gettext_quoted "%s, with Xen %s and Linux %s (recovery mode)")"
+      else
+	  title="$(gettext_quoted "%s, with Xen %s and Linux %s")"
+      fi
+  fi
+  printf "menuentry '${title}' ${CLASS} {\n" "${os}" "${xen_version}" "${version}"
+  if ! ${recovery} ; then
+      save_default_entry | sed -e "s/^/\t/"
   fi
-  printf "menuentry '${title}' ${CLASS} {\n" "${os}" "${version}" "${xen_version}"
-  save_default_entry | sed -e "s/^/\t/"
 
   if [ -z "${prepare_boot_cache}" ]; then
     prepare_boot_cache="$(prepare_grub_to_access_device ${GRUB_DEVICE_BOOT} | sed -e "s/^/\t/")"
   fi
   printf '%s\n' "${prepare_boot_cache}"
-  message="$(gettext_printf "Loading Linux %s ..." ${version})"
+  xmessage="$(gettext_printf "Loading Xen %s ..." ${xen_version})"
+  lmessage="$(gettext_printf "Loading Linux %s ..." ${version})"
   cat << EOF
-	echo	'$message'
+	echo	'$xmessage'
 	multiboot	${rel_xen_dirname}/${xen_basename} placeholder ${xen_args}
+	echo	'$lmessage'
 	module	${rel_dirname}/${basename} placeholder root=${linux_root_device_thisversion} ro ${args}
 EOF
   if test -n "${initrd}" ; then
@@ -88,17 +131,37 @@ EOF
 	module	${rel_dirname}/${initrd}
 EOF
   fi
+  if test -n "${xenpolicy}" ; then
+    message="$(gettext_printf "Loading XSM policy ...")"
+    cat << EOF
+	echo	'$message'
+	module	${rel_dirname}/${xenpolicy}
+EOF
+  fi
   cat << EOF
 }
 EOF
 }
 
-linux_list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* ; do
+linux_list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* /boot/kernel-*; do
+    if grub_file_is_not_garbage "$i"; then
     	basename=$(basename $i)
 	version=$(echo $basename | sed -e "s,^[^0-9]*-,,g")
-        if grub_file_is_not_garbage "$i" && grep -qx 'CONFIG_XEN_\(DOM0\|PRIVILEGED_GUEST\)=y' /boot/config-${version} 2> /dev/null ; then echo -n "$i " ; fi
-      done`
-xen_list=`for i in /boot/xen*; do
+	dirname=$(dirname $i)
+	config=
+	for j in "${dirname}/config-${version}" "${dirname}/config-${alt_version}" "/etc/kernels/kernel-config-${version}" ; do
+	    if test -e "${j}" ; then
+		config="${j}"
+		break
+	    fi
+	done
+        if (grep -qx "CONFIG_XEN_DOM0=y" "${config}" 2> /dev/null || grep -qx "CONFIG_XEN_PRIVILEGED_GUEST=y" "${config}" 2> /dev/null); then echo -n "$i " ; fi
+    fi
+    done`
+if [ "x${linux_list}" = "x" ] ; then
+    exit 0
+fi
+xen_list=`for i in /boot/xen[-.]*; do
         if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
       done`
 prepare_boot_cache=
@@ -123,7 +186,9 @@ while [ "x${xen_list}" != "x" ] ; do
 	initrd=
 	for i in "initrd.img-${version}" "initrd-${version}.img" \
 	    "initrd-${version}" "initrd.img-${alt_version}" \
-	    "initrd-${alt_version}.img" "initrd-${alt_version}"; do
+	    "initrd-${alt_version}.img" "initrd-${alt_version}" \
+	    "initramfs-genkernel-${version}" \
+	    "initramfs-genkernel-${alt_version}" ; do
 	    if test -e "${dirname}/${i}" ; then
 		initrd="$i"
 		break
@@ -137,10 +202,14 @@ while [ "x${xen_list}" != "x" ] ; do
 	fi
 
 	linux_entry "${OS}" "${version}" "${xen_version}" false \
-	    "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}" "${GRUB_CMDLINE_XEN} ${GRUB_CMDLINE_XEN_DEFAULT}"
-	if [ "x${GRUB_DISABLE_LINUX_RECOVERY}" != "xtrue" ]; then
+	    "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}" "${GRUB_CMDLINE_XEN} ${GRUB_CMDLINE_XEN_DEFAULT}" false
+	linux_entry "${OS}" "${version}" "${xen_version}" false \
+	    "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}" "${GRUB_CMDLINE_XEN} ${GRUB_CMDLINE_XEN_DEFAULT}" true
+	if [ "x${GRUB_DISABLE_RECOVERY}" != "xtrue" ]; then
+	    linux_entry "${OS}" "${version}" "${xen_version}" true \
+		"single ${GRUB_CMDLINE_LINUX}" "${GRUB_CMDLINE_XEN}" false
 	    linux_entry "${OS}" "${version}" "${xen_version}" true \
-		"single ${GRUB_CMDLINE_LINUX}" "${GRUB_CMDLINE_XEN}"
+		"single ${GRUB_CMDLINE_LINUX}" "${GRUB_CMDLINE_XEN}" true
 	fi
 
 	list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\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 Wed Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeA-0001l3-Cm; Wed, 10 Dec 2014 22:22:14 +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 1Xype8-0001k6-3X
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	72/23-15461-397C8845; Wed, 10 Dec 2014 22:22:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418250128!14438752!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20970 invoked from network); 10 Dec 2014 22:22:10 -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 Dec 2014 22:22:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679397"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-Dc;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:31 +0000
Message-ID: <1418250095-13287-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 5/9] Debian.pm: pass in XSM
	configuration to bootloader setup routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change to Uboot will come in another patch. GRUB 1 is ignored, as
currently OSSTest only has Wheezy which has GRUB 2.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Changes in v4:
1. Modify callsite of debian_boot_setup to avoid regression.
---
 Osstest/Debian.pm |   32 +++++++++++++++++++++-----------
 ts-xen-install    |    2 +-
 2 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c446e8b..22b40ff 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -45,9 +45,9 @@ BEGIN {
 
 #---------- manipulation of Debian bootloader setup ----------
 
-sub debian_boot_setup ($$$$;$) {
+sub debian_boot_setup ($$$$$;$) {
     # $xenhopt==undef => is actually a guest, do not set up a hypervisor
-    my ($ho, $want_kernver, $xenhopt, $distpath, $hooks) = @_;
+    my ($ho, $want_kernver, $want_xsm, $xenhopt, $distpath, $hooks) = @_;
 
     target_kernkind_check($ho);
     target_kernkind_console_inittab($ho,$ho,"/");
@@ -72,11 +72,11 @@ sub debian_boot_setup ($$$$;$) {
 
     my $bootloader;
     if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
-	$bootloader= setupboot_uboot($ho, $want_kernver, $xenhopt, $kopt);
+	$bootloader= setupboot_uboot($ho, $want_kernver, $want_xsm, $xenhopt, $kopt);
     } elsif ($ho->{Suite} =~ m/lenny/) {
-        $bootloader= setupboot_grub1($ho, $want_kernver, $xenhopt, $kopt);
+        $bootloader= setupboot_grub1($ho, $want_kernver, $want_xsm, $xenhopt, $kopt);
     } else {
-        $bootloader= setupboot_grub2($ho, $want_kernver, $xenhopt, $kopt);
+        $bootloader= setupboot_grub2($ho, $want_kernver, $want_xsm, $xenhopt, $kopt);
     }
 
     $bootloader->{UpdateConfig}($ho);
@@ -112,8 +112,8 @@ sub bl_getmenu_open ($$$) {
     return $f;
 }
 
-sub setupboot_uboot ($$$) {
-    my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
+sub setupboot_uboot ($$$$) {
+    my ($ho,$want_kernver,$want_xsm,$xenhopt,$xenkopt) = @_;
     my $bl= { };
 
     $bl->{UpdateConfig}= sub {
@@ -194,13 +194,17 @@ END
     return $bl;
 }
 
-sub setupboot_grub1 ($$$) {
-    my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
+sub setupboot_grub1 ($$$$) {
+    my ($ho,$want_kernver,$want_xsm,$xenhopt,$xenkopt) = @_;
     my $bl= { };
 
     my $rmenu= "/boot/grub/menu.lst";
     my $lmenu= "$stash/$ho->{Name}--menu.lst.out";
 
+    if ($want_xsm) {
+	die "Enabling XSM with GRUB is not supported";
+    }
+
     target_editfile_root($ho, $rmenu, sub {
         while (<::EI>) {
             if (m/^## ## Start Default/ ..
@@ -279,8 +283,8 @@ sub setupboot_grub1 ($$$) {
 # Xen kernels"
 # Currently setupboot_grub2 relies on Grub menu not having submenu.
 # Check Debian bug #690538.
-sub setupboot_grub2 ($$$) {
-    my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
+sub setupboot_grub2 ($$$$) {
+    my ($ho,$want_kernver,$want_xsm,$xenhopt,$xenkopt) = @_;
     my $bl= { };
 
     my $rmenu= '/boot/grub/grub.cfg';
@@ -307,6 +311,9 @@ sub setupboot_grub2 ($$$) {
 			 $entry->{KernVer} ne $want_kernver) {
 		    logm("(skipping entry at $entry->{StartLine};".
 			 " kernel $entry->{KernVer}, not $want_kernver)");
+		} elsif ($want_xsm && !defined $entry->{Xenpolicy}) {
+		    logm("(skipping entry at $entry->{StartLine};".
+			 " XSM policy file not present)");
 		} else {
 		    # yes!
 		    last;
@@ -339,6 +346,9 @@ sub setupboot_grub2 ($$$) {
             if (m/^\s*module\s*\/(initrd\S+)/) {
                 $entry->{Initrd}= $1;
             }
+	    if (m/^\s*module\s*\/(xenpolicy\S+)/) {
+                $entry->{Xenpolicy}= $1;
+            }
         }
         die 'grub 2 bootloader entry not found' unless $entry;
 
diff --git a/ts-xen-install b/ts-xen-install
index 4d34d1f..910181e 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -171,7 +171,7 @@ sub setupboot () {
     }
 
     my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
-    debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
+    debian_boot_setup($ho, $want_kernver, 0, $xenhopt, \%distpath, \@hooks);
 
     logm("ready to boot Xen");
 }
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeD-0001mK-5e; Wed, 10 Dec 2014 22:22:17 +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 1XypeB-0001lE-2Z
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:15 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2B/4C-25276-597C8845; Wed, 10 Dec 2014 22:22:13 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418250129!11351812!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31581 invoked from network); 10 Dec 2014 22:22:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 22:22:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679398"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-Ga;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:34 +0000
Message-ID: <1418250095-13287-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 8/9] make-flight: factor out
	do_pv_debian_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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 make-flight |   21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/make-flight b/make-flight
index 9963a46..35904be 100755
--- a/make-flight
+++ b/make-flight
@@ -281,17 +281,24 @@ do_passthrough_tests () {
   done
 }
 
-test_matrix_do_one () {
-
-  # Basic PV Linux test with xl
+do_pv_debian_test_one () {
+  toolstack=$1
 
-  job_create_test test-$xenarch$kern-$dom0arch-xl test-debian xl \
+  job_create_test test-$xenarch$kern-$dom0arch-$toolstack test-debian $toolstack \
             $xenarch $dom0arch                                   \
             $debian_runvars all_hostflags=$most_hostflags
+}
 
-  job_create_test test-$xenarch$kern-$dom0arch-libvirt test-debian libvirt \
-            $xenarch $dom0arch                                       \
-            $debian_runvars all_hostflags=$most_hostflags
+do_pv_debian_tests () {
+  for toolstack in xl libvirt; do
+    do_pv_debian_test_one $toolstack
+  done
+}
+
+test_matrix_do_one () {
+
+  # Basic PV Linux test with xl
+  do_pv_debian_tests
 
   # No further arm tests at the moment
   if [ $dom0arch = armhf ]; then
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeC-0001lx-KB; Wed, 10 Dec 2014 22:22:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XypeA-0001ko-7t
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	AA/4C-25276-597C8845; Wed, 10 Dec 2014 22:22:13 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418250128!14438752!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21025 invoked from network); 10 Dec 2014 22:22:12 -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 Dec 2014 22:22:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679394"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-8N;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:27 +0000
Message-ID: <1418250095-13287-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 1/9] overlay: update
	overlay/etc/grub.d/20_linux_xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This file was originally created to work around Debian bug #633127
("/etc/grub/20_linux does not recognise some old Xen kernels").

According to Debian bug tracker [0], #633127 bug is fixed in Wheezy. As
we're now using Wheezy in OSSTest we can safely remove the old overlay
file if there's no further bugs discovered.

However we have another bug #690538 ("grub-common: Please make submenu
creation optional or at least allow users to disable it easily") that
would break OSSTest.  We're now using Wheezy in production. There's no
way to disable submenu in Wheezy. And submenu breaks OSSTest's grub menu
parser.

So update this overlay file to Wheezy's version and take care of Debian
bug #690538 by removing the lines to generate submenu.

Also work around GRUB bug #43420 ("20_linux_xen doesn't support Xen XSM
policy file") by applying a small patch proposed in [2].

Add a note to reference #633127 and #690538 above grub2 setup function.

0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633127
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690538
2: https://savannah.gnu.org/bugs/?43420

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Debian.pm               |    5 ++
 overlay/etc/grub.d/20_linux_xen |  117 +++++++++++++++++++++++++++++++--------
 2 files changed, 98 insertions(+), 24 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..c446e8b 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -274,6 +274,11 @@ sub setupboot_grub1 ($$$) {
     return $bl;
 }
 
+# Note on running OSSTest on Squeeze with old Xen kernel: check out
+# Debian bug #633127 "/etc/grub/20_linux does not recognise some old
+# Xen kernels"
+# Currently setupboot_grub2 relies on Grub menu not having submenu.
+# Check Debian bug #690538.
 sub setupboot_grub2 ($$$) {
     my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
     my $bl= { };
diff --git a/overlay/etc/grub.d/20_linux_xen b/overlay/etc/grub.d/20_linux_xen
index 99854d2..001b76d 100755
--- a/overlay/etc/grub.d/20_linux_xen
+++ b/overlay/etc/grub.d/20_linux_xen
@@ -1,7 +1,7 @@
 #! /bin/sh
 
-# Copied from the identically named file in grub-common 1.98+20100804-14
-# i386.  This version fixes #633127 (and has the patch I proposed there).
+# Copied from the identical named file in grub-common 1.99-27+deb7u2.
+# This version fixed Debian bug #690538 and GRUB bug #43420.
 
 set -e
 
@@ -21,14 +21,14 @@ set -e
 # You should have received a copy of the GNU General Public License
 # along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
 
-prefix=/usr
-exec_prefix=${prefix}
-bindir=${exec_prefix}/bin
-libdir=${exec_prefix}/lib
-. ${libdir}/grub/grub-mkconfig_lib
+prefix="/usr"
+exec_prefix="${prefix}"
+datarootdir="${prefix}/share"
+
+. "${datarootdir}/grub/grub-mkconfig_lib"
 
 export TEXTDOMAIN=grub
-export TEXTDOMAINDIR=${prefix}/share/locale
+export TEXTDOMAINDIR="${datarootdir}/locale"
 
 CLASS="--class gnu-linux --class gnu --class os --class xen"
 
@@ -36,7 +36,7 @@ if [ "x${GRUB_DISTRIBUTOR}" = "x" ] ; then
   OS=GNU/Linux
 else
   OS="${GRUB_DISTRIBUTOR} GNU/Linux"
-  CLASS="--class $(echo ${GRUB_DISTRIBUTOR} | tr '[A-Z]' '[a-z]' | cut -d' ' -f1) ${CLASS}"
+  CLASS="--class $(echo ${GRUB_DISTRIBUTOR} | tr 'A-Z' 'a-z' | cut -d' ' -f1) ${CLASS}"
 fi
 
 # loop-AES arranges things so that /dev/loop/X can be our root device, but
@@ -44,6 +44,11 @@ fi
 case ${GRUB_DEVICE} in
   /dev/loop/*|/dev/loop[0-9])
     GRUB_DEVICE=`losetup ${GRUB_DEVICE} | sed -e "s/^[^(]*(\([^)]\+\)).*/\1/"`
+    # We can't cope with devices loop-mounted from files here.
+    case ${GRUB_DEVICE} in
+      /dev/*) ;;
+      *) exit 0 ;;
+    esac
   ;;
 esac
 
@@ -55,6 +60,23 @@ else
   LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
 fi
 
+# Allow overriding GRUB_CMDLINE_LINUX and GRUB_CMDLINE_LINUX_DEFAULT.
+if [ "${GRUB_CMDLINE_LINUX_XEN_REPLACE}" ]; then
+  GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX_XEN_REPLACE}"
+fi
+if [ "${GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT}" ]; then
+  GRUB_CMDLINE_LINUX_DEFAULT="${GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT}"
+fi
+
+if [ "x`${grub_probe} --device ${GRUB_DEVICE} --target=fs 2>/dev/null || true`" = xbtrfs ] \
+    || [ "x`stat -f --printf=%T /`" = xbtrfs ]; then
+  rootsubvol="`make_system_path_relative_to_its_root /`"
+  rootsubvol="${rootsubvol#/}"
+  if [ "x${rootsubvol}" != x ]; then
+    GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
+  fi
+fi
+
 linux_entry ()
 {
   os="$1"
@@ -63,22 +85,43 @@ linux_entry ()
   recovery="$4"
   args="$5"
   xen_args="$6"
-  if ${recovery} ; then
-    title="$(gettext_quoted "%s, with Linux %s and XEN %s (recovery mode)")"
+  xsm="$7"
+  # If user wants to enable XSM support, make sure there's
+  # corresponding policy file.
+  if ${xsm} ; then
+      xenpolicy=`echo xenpolicy-$xen_version`
+      if test ! -e "${xen_dirname}/${xenpolicy}" ; then
+	  return
+      fi
+      xen_args=`echo $xen_args flask_enabled=1 flask_enforcing=1`
+      if ${recovery} ; then
+	  title="$(gettext_quoted "%s, with Xen %s (XSM enabled) and Linux %s (recovery mode)")"
+      else
+	  title="$(gettext_quoted "%s, with Xen %s (XSM enabled) and Linux %s")"
+      fi
   else
-    title="$(gettext_quoted "%s, with Linux %s and XEN %s")"
+      xenpolicy=""
+      if ${recovery} ; then
+	  title="$(gettext_quoted "%s, with Xen %s and Linux %s (recovery mode)")"
+      else
+	  title="$(gettext_quoted "%s, with Xen %s and Linux %s")"
+      fi
+  fi
+  printf "menuentry '${title}' ${CLASS} {\n" "${os}" "${xen_version}" "${version}"
+  if ! ${recovery} ; then
+      save_default_entry | sed -e "s/^/\t/"
   fi
-  printf "menuentry '${title}' ${CLASS} {\n" "${os}" "${version}" "${xen_version}"
-  save_default_entry | sed -e "s/^/\t/"
 
   if [ -z "${prepare_boot_cache}" ]; then
     prepare_boot_cache="$(prepare_grub_to_access_device ${GRUB_DEVICE_BOOT} | sed -e "s/^/\t/")"
   fi
   printf '%s\n' "${prepare_boot_cache}"
-  message="$(gettext_printf "Loading Linux %s ..." ${version})"
+  xmessage="$(gettext_printf "Loading Xen %s ..." ${xen_version})"
+  lmessage="$(gettext_printf "Loading Linux %s ..." ${version})"
   cat << EOF
-	echo	'$message'
+	echo	'$xmessage'
 	multiboot	${rel_xen_dirname}/${xen_basename} placeholder ${xen_args}
+	echo	'$lmessage'
 	module	${rel_dirname}/${basename} placeholder root=${linux_root_device_thisversion} ro ${args}
 EOF
   if test -n "${initrd}" ; then
@@ -88,17 +131,37 @@ EOF
 	module	${rel_dirname}/${initrd}
 EOF
   fi
+  if test -n "${xenpolicy}" ; then
+    message="$(gettext_printf "Loading XSM policy ...")"
+    cat << EOF
+	echo	'$message'
+	module	${rel_dirname}/${xenpolicy}
+EOF
+  fi
   cat << EOF
 }
 EOF
 }
 
-linux_list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* ; do
+linux_list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* /boot/kernel-*; do
+    if grub_file_is_not_garbage "$i"; then
     	basename=$(basename $i)
 	version=$(echo $basename | sed -e "s,^[^0-9]*-,,g")
-        if grub_file_is_not_garbage "$i" && grep -qx 'CONFIG_XEN_\(DOM0\|PRIVILEGED_GUEST\)=y' /boot/config-${version} 2> /dev/null ; then echo -n "$i " ; fi
-      done`
-xen_list=`for i in /boot/xen*; do
+	dirname=$(dirname $i)
+	config=
+	for j in "${dirname}/config-${version}" "${dirname}/config-${alt_version}" "/etc/kernels/kernel-config-${version}" ; do
+	    if test -e "${j}" ; then
+		config="${j}"
+		break
+	    fi
+	done
+        if (grep -qx "CONFIG_XEN_DOM0=y" "${config}" 2> /dev/null || grep -qx "CONFIG_XEN_PRIVILEGED_GUEST=y" "${config}" 2> /dev/null); then echo -n "$i " ; fi
+    fi
+    done`
+if [ "x${linux_list}" = "x" ] ; then
+    exit 0
+fi
+xen_list=`for i in /boot/xen[-.]*; do
         if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
       done`
 prepare_boot_cache=
@@ -123,7 +186,9 @@ while [ "x${xen_list}" != "x" ] ; do
 	initrd=
 	for i in "initrd.img-${version}" "initrd-${version}.img" \
 	    "initrd-${version}" "initrd.img-${alt_version}" \
-	    "initrd-${alt_version}.img" "initrd-${alt_version}"; do
+	    "initrd-${alt_version}.img" "initrd-${alt_version}" \
+	    "initramfs-genkernel-${version}" \
+	    "initramfs-genkernel-${alt_version}" ; do
 	    if test -e "${dirname}/${i}" ; then
 		initrd="$i"
 		break
@@ -137,10 +202,14 @@ while [ "x${xen_list}" != "x" ] ; do
 	fi
 
 	linux_entry "${OS}" "${version}" "${xen_version}" false \
-	    "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}" "${GRUB_CMDLINE_XEN} ${GRUB_CMDLINE_XEN_DEFAULT}"
-	if [ "x${GRUB_DISABLE_LINUX_RECOVERY}" != "xtrue" ]; then
+	    "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}" "${GRUB_CMDLINE_XEN} ${GRUB_CMDLINE_XEN_DEFAULT}" false
+	linux_entry "${OS}" "${version}" "${xen_version}" false \
+	    "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}" "${GRUB_CMDLINE_XEN} ${GRUB_CMDLINE_XEN_DEFAULT}" true
+	if [ "x${GRUB_DISABLE_RECOVERY}" != "xtrue" ]; then
+	    linux_entry "${OS}" "${version}" "${xen_version}" true \
+		"single ${GRUB_CMDLINE_LINUX}" "${GRUB_CMDLINE_XEN}" false
 	    linux_entry "${OS}" "${version}" "${xen_version}" true \
-		"single ${GRUB_CMDLINE_LINUX}" "${GRUB_CMDLINE_XEN}"
+		"single ${GRUB_CMDLINE_LINUX}" "${GRUB_CMDLINE_XEN}" true
 	fi
 
 	list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\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 Wed Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeB-0001li-SL; Wed, 10 Dec 2014 22:22:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xype9-0001kc-GH
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:13 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B9/4C-25276-497C8845; Wed, 10 Dec 2014 22:22:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418250129!11351812!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31549 invoked from network); 10 Dec 2014 22:22:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 22:22:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679403"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-HA;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:35 +0000
Message-ID: <1418250095-13287-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 9/9] mfi-common,
	make-flight: create XSM test jobs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Duplicate Debian PV and HVM test jobs for XSM testing.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Changes in v4:
1. Parse runvar to determine xsm suffix
---
 make-flight |   23 +++++++++++++++++++----
 mfi-common  |   12 ++++++++++--
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/make-flight b/make-flight
index 35904be..00bc0fc 100755
--- a/make-flight
+++ b/make-flight
@@ -200,27 +200,36 @@ do_hvm_win7_x64_tests () {
 do_hvm_debian_test_one () {
   testname=$1
   bios=$2
+  xsm=$3
+
   job_create_test test-$xenarch$kern-$dom0arch-xl$qemuu_suffix-$testname-amd64\
     test-debianhvm xl $xenarch $dom0arch $qemuu_runvar \
+    enable_xsm=$xsm                             \
     debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
     bios=$bios \
     all_hostflags=$most_hostflags,hvm
 }
 
 do_hvm_debian_tests() {
+  test_xsm=$(xenbranch_xsm_variants)
+
   if [ $xenarch != amd64 ]; then
     return
   fi
 
   # QEMU upstream supports ovmf and seabios
   if [ "x$qemuu_suffix" == "x-qemuu" ]; then
-    do_hvm_debian_test_one ovmf ovmf
-    do_hvm_debian_test_one debianhvm seabios
+    do_hvm_debian_test_one ovmf ovmf false
+    for xsm in $test_xsm ; do
+      do_hvm_debian_test_one debianhvm seabios $xsm
+    done
   fi
 
   # QEMU traditional supports rombios
   if [ "x$qemuu_suffix" == "x-qemut" ]; then
-    do_hvm_debian_test_one debianhvm rombios
+    for xsm in $test_xsm ; do
+      do_hvm_debian_test_one debianhvm rombios $xsm
+    done
   fi
 }
 
@@ -283,15 +292,21 @@ do_passthrough_tests () {
 
 do_pv_debian_test_one () {
   toolstack=$1
+  xsm=$2
 
   job_create_test test-$xenarch$kern-$dom0arch-$toolstack test-debian $toolstack \
             $xenarch $dom0arch                                   \
+            enable_xsm=$xsm                                      \
             $debian_runvars all_hostflags=$most_hostflags
 }
 
 do_pv_debian_tests () {
+  test_xsm=$(xenbranch_xsm_variants)
+
   for toolstack in xl libvirt; do
-    do_pv_debian_test_one $toolstack
+    for xsm in $test_xsm ; do
+      do_pv_debian_test_one $toolstack $xsm
+    done
   done
 }
 
diff --git a/mfi-common b/mfi-common
index 161847c..3a97a90 100644
--- a/mfi-common
+++ b/mfi-common
@@ -268,8 +268,16 @@ job_create_test () {
   local xenarch=$1; shift
   local dom0arch=$1; shift
 
-  xenbuildjob="${bfi}build-$xenarch"
-  buildjob="${bfi}build-$dom0arch"
+  xsm_suffix=""
+  for rv in $@ ; do
+      case $rv in
+          enable_xsm=true) xsm_suffix="-xsm";;
+      esac
+  done
+
+  job="$job$xsm_suffix"
+  xenbuildjob="${bfi}build-$xenarch$xsm_suffix"
+  buildjob="${bfi}build-$dom0arch$xsm_suffix"
   tsbuildjob=
 
   case "$xenbranch:$toolstack" in
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeA-0001lH-OZ; Wed, 10 Dec 2014 22:22:14 +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 1Xype8-0001kD-KS
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:12 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FD/BF-09842-497C8845; Wed, 10 Dec 2014 22:22:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418250128!14438752!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20997 invoked from network); 10 Dec 2014 22:22:11 -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 Dec 2014 22:22:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679401"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-Ek;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:33 +0000
Message-ID: <1418250095-13287-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 7/9] ts-xen-install: install Xen with
	XSM support if requested
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Changes in v4:
1. Use "true" instead of "y"
---
 ts-xen-install |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ts-xen-install b/ts-xen-install
index 910181e..08b5fe1 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -46,6 +46,8 @@ if (@ARGV and $ARGV[0] eq '--check') {
 
 our $ho;
 
+my $enable_xsm = $r{enable_xsm} =~ m/true/ ? 1 : 0;
+
 my %distpath;
 
 sub packages () {
@@ -171,7 +173,7 @@ sub setupboot () {
     }
 
     my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
-    debian_boot_setup($ho, $want_kernver, 0, $xenhopt, \%distpath, \@hooks);
+    debian_boot_setup($ho, $want_kernver, $enable_xsm, $xenhopt, \%distpath, \@hooks);
 
     logm("ready to boot Xen");
 }
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeA-0001l3-Cm; Wed, 10 Dec 2014 22:22:14 +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 1Xype8-0001k6-3X
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	72/23-15461-397C8845; Wed, 10 Dec 2014 22:22:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418250128!14438752!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20970 invoked from network); 10 Dec 2014 22:22:10 -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 Dec 2014 22:22:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679397"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-Dc;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:31 +0000
Message-ID: <1418250095-13287-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 5/9] Debian.pm: pass in XSM
	configuration to bootloader setup routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Change to Uboot will come in another patch. GRUB 1 is ignored, as
currently OSSTest only has Wheezy which has GRUB 2.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Changes in v4:
1. Modify callsite of debian_boot_setup to avoid regression.
---
 Osstest/Debian.pm |   32 +++++++++++++++++++++-----------
 ts-xen-install    |    2 +-
 2 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c446e8b..22b40ff 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -45,9 +45,9 @@ BEGIN {
 
 #---------- manipulation of Debian bootloader setup ----------
 
-sub debian_boot_setup ($$$$;$) {
+sub debian_boot_setup ($$$$$;$) {
     # $xenhopt==undef => is actually a guest, do not set up a hypervisor
-    my ($ho, $want_kernver, $xenhopt, $distpath, $hooks) = @_;
+    my ($ho, $want_kernver, $want_xsm, $xenhopt, $distpath, $hooks) = @_;
 
     target_kernkind_check($ho);
     target_kernkind_console_inittab($ho,$ho,"/");
@@ -72,11 +72,11 @@ sub debian_boot_setup ($$$$;$) {
 
     my $bootloader;
     if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
-	$bootloader= setupboot_uboot($ho, $want_kernver, $xenhopt, $kopt);
+	$bootloader= setupboot_uboot($ho, $want_kernver, $want_xsm, $xenhopt, $kopt);
     } elsif ($ho->{Suite} =~ m/lenny/) {
-        $bootloader= setupboot_grub1($ho, $want_kernver, $xenhopt, $kopt);
+        $bootloader= setupboot_grub1($ho, $want_kernver, $want_xsm, $xenhopt, $kopt);
     } else {
-        $bootloader= setupboot_grub2($ho, $want_kernver, $xenhopt, $kopt);
+        $bootloader= setupboot_grub2($ho, $want_kernver, $want_xsm, $xenhopt, $kopt);
     }
 
     $bootloader->{UpdateConfig}($ho);
@@ -112,8 +112,8 @@ sub bl_getmenu_open ($$$) {
     return $f;
 }
 
-sub setupboot_uboot ($$$) {
-    my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
+sub setupboot_uboot ($$$$) {
+    my ($ho,$want_kernver,$want_xsm,$xenhopt,$xenkopt) = @_;
     my $bl= { };
 
     $bl->{UpdateConfig}= sub {
@@ -194,13 +194,17 @@ END
     return $bl;
 }
 
-sub setupboot_grub1 ($$$) {
-    my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
+sub setupboot_grub1 ($$$$) {
+    my ($ho,$want_kernver,$want_xsm,$xenhopt,$xenkopt) = @_;
     my $bl= { };
 
     my $rmenu= "/boot/grub/menu.lst";
     my $lmenu= "$stash/$ho->{Name}--menu.lst.out";
 
+    if ($want_xsm) {
+	die "Enabling XSM with GRUB is not supported";
+    }
+
     target_editfile_root($ho, $rmenu, sub {
         while (<::EI>) {
             if (m/^## ## Start Default/ ..
@@ -279,8 +283,8 @@ sub setupboot_grub1 ($$$) {
 # Xen kernels"
 # Currently setupboot_grub2 relies on Grub menu not having submenu.
 # Check Debian bug #690538.
-sub setupboot_grub2 ($$$) {
-    my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
+sub setupboot_grub2 ($$$$) {
+    my ($ho,$want_kernver,$want_xsm,$xenhopt,$xenkopt) = @_;
     my $bl= { };
 
     my $rmenu= '/boot/grub/grub.cfg';
@@ -307,6 +311,9 @@ sub setupboot_grub2 ($$$) {
 			 $entry->{KernVer} ne $want_kernver) {
 		    logm("(skipping entry at $entry->{StartLine};".
 			 " kernel $entry->{KernVer}, not $want_kernver)");
+		} elsif ($want_xsm && !defined $entry->{Xenpolicy}) {
+		    logm("(skipping entry at $entry->{StartLine};".
+			 " XSM policy file not present)");
 		} else {
 		    # yes!
 		    last;
@@ -339,6 +346,9 @@ sub setupboot_grub2 ($$$) {
             if (m/^\s*module\s*\/(initrd\S+)/) {
                 $entry->{Initrd}= $1;
             }
+	    if (m/^\s*module\s*\/(xenpolicy\S+)/) {
+                $entry->{Xenpolicy}= $1;
+            }
         }
         die 'grub 2 bootloader entry not found' unless $entry;
 
diff --git a/ts-xen-install b/ts-xen-install
index 4d34d1f..910181e 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -171,7 +171,7 @@ sub setupboot () {
     }
 
     my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
-    debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
+    debian_boot_setup($ho, $want_kernver, 0, $xenhopt, \%distpath, \@hooks);
 
     logm("ready to boot Xen");
 }
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeC-0001lq-8d; Wed, 10 Dec 2014 22:22: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 1Xype9-0001kf-OP
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:14 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	61/45-27623-497C8845; Wed, 10 Dec 2014 22:22:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418250130!12451475!1
X-Originating-IP: [66.165.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 4800 invoked from network); 10 Dec 2014 22:22:11 -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;
	10 Dec 2014 22:22:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679402"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-7h;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:26 +0000
Message-ID: <1418250095-13287-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>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 0/9] XSM test case for OSSTest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 attempts to duplicate some Debian test cases for XSM. This
is version 4 of this series.

Tests duplicated for xen-unstable branch:
  build-{i386,amd64,armhf}-xsm
  test-amd64-{i386,amd64}-{xl,libvirt}-xsm
  test-armhf-armhf-{xl,libvirt}-xsm
  test-amd64-{i386,amd64}-xl-qemuu-debianhvm-amd64-xsm
  test-amd64-(i386,amd64}-xl-qemut-debianhvm-amd64-xsm

Changes in v4 can be found in individual patch.

See below for output of
  ./standalone-generate-dump-flight-runvars > origin # master
  ./standalone-generate-dump-flight-runvars > xsm # this series applied
  diff -ub ../origin xsm  | grep '-xen-unstable' | sed  's/[ \t]*$//' # nothing
  diff -ub ../origin xsm  | grep '+xen-unstable' | sed  's/[ \t]*$//'

+xen-unstable               test-amd64-amd64-libvirt-xsm                  all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,hvm
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,hvm
+xen-unstable               test-amd64-amd64-xl-xsm                       all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
+xen-unstable               test-amd64-i386-libvirt-xsm                   all_hostflags               arch-i386,arch-xen-amd64,suite-wheezy,purpose-test
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  all_hostflags               arch-i386,arch-xen-amd64,suite-wheezy,purpose-test,hvm
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  all_hostflags               arch-i386,arch-xen-amd64,suite-wheezy,purpose-test,hvm
+xen-unstable               test-amd64-i386-xl-xsm                        all_hostflags               arch-i386,arch-xen-amd64,suite-wheezy,purpose-test
+xen-unstable               test-armhf-armhf-libvirt-xsm                  all_hostflags               arch-armhf,arch-xen-armhf,suite-wheezy,purpose-test
+xen-unstable               test-armhf-armhf-xl-xsm                       all_hostflags               arch-armhf,arch-xen-armhf,suite-wheezy,purpose-test
+xen-unstable               build-amd64-xsm                               arch                        amd64
+xen-unstable               build-armhf-xsm                               arch                        armhf
+xen-unstable               build-i386-xsm                                arch                        i386
+xen-unstable               test-amd64-amd64-libvirt-xsm                  arch                        amd64
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm arch                        amd64
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm arch                        amd64
+xen-unstable               test-amd64-amd64-xl-xsm                       arch                        amd64
+xen-unstable               test-amd64-i386-libvirt-xsm                   arch                        i386
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  arch                        i386
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  arch                        i386
+xen-unstable               test-amd64-i386-xl-xsm                        arch                        i386
+xen-unstable               test-armhf-armhf-libvirt-xsm                  arch                        armhf
+xen-unstable               test-armhf-armhf-xl-xsm                       arch                        armhf
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm bios                        rombios
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm bios                        seabios
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  bios                        rombios
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  bios                        seabios
+xen-unstable               build-amd64-xsm                               build_lvextend_max          50
+xen-unstable               build-armhf-xsm                               build_lvextend_max          50
+xen-unstable               build-i386-xsm                                build_lvextend_max          50
+xen-unstable               test-amd64-amd64-libvirt-xsm                  buildjob                    build-amd64-xsm
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm buildjob                    build-amd64-xsm
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm buildjob                    build-amd64-xsm
+xen-unstable               test-amd64-amd64-xl-xsm                       buildjob                    build-amd64-xsm
+xen-unstable               test-amd64-i386-libvirt-xsm                   buildjob                    build-i386-xsm
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  buildjob                    build-i386-xsm
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  buildjob                    build-i386-xsm
+xen-unstable               test-amd64-i386-xl-xsm                        buildjob                    build-i386-xsm
+xen-unstable               test-armhf-armhf-libvirt-xsm                  buildjob                    build-armhf-xsm
+xen-unstable               test-armhf-armhf-xl-xsm                       buildjob                    build-armhf-xsm
+xen-unstable               test-amd64-amd64-libvirt-xsm                  debian_arch                 amd64
+xen-unstable               test-amd64-amd64-xl-xsm                       debian_arch                 amd64
+xen-unstable               test-amd64-i386-libvirt-xsm                   debian_arch                 i386
+xen-unstable               test-amd64-i386-xl-xsm                        debian_arch                 i386
+xen-unstable               test-armhf-armhf-libvirt-xsm                  debian_arch                 armhf
+xen-unstable               test-armhf-armhf-xl-xsm                       debian_arch                 armhf
+xen-unstable               test-amd64-amd64-libvirt-xsm                  debian_kernkind             pvops
+xen-unstable               test-amd64-amd64-xl-xsm                       debian_kernkind             pvops
+xen-unstable               test-amd64-i386-libvirt-xsm                   debian_kernkind             pvops
+xen-unstable               test-amd64-i386-xl-xsm                        debian_kernkind             pvops
+xen-unstable               test-armhf-armhf-libvirt-xsm                  debian_kernkind             pvops
+xen-unstable               test-armhf-armhf-xl-xsm                       debian_kernkind             pvops
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm debianhvm_image             debian-7.2.0-amd64-CD-1.iso
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm debianhvm_image             debian-7.2.0-amd64-CD-1.iso
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  debianhvm_image             debian-7.2.0-amd64-CD-1.iso
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  debianhvm_image             debian-7.2.0-amd64-CD-1.iso
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm device_model_version        qemu-xen-traditional
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm device_model_version        qemu-xen
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  device_model_version        qemu-xen-traditional
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  device_model_version        qemu-xen
+xen-unstable               build-amd64-xsm                               enable_ovmf                 true
+xen-unstable               build-armhf-xsm                               enable_ovmf                 true
+xen-unstable               build-i386-xsm                                enable_ovmf                 true
+xen-unstable               build-amd64-xsm                               enable_xend                 false
+xen-unstable               build-armhf-xsm                               enable_xend                 false
+xen-unstable               build-i386-xsm                                enable_xend                 false
+xen-unstable               build-amd64                                   enable_xsm                  false
+xen-unstable               build-amd64-xsm                               enable_xsm                  true
+xen-unstable               build-armhf                                   enable_xsm                  false
+xen-unstable               build-armhf-xsm                               enable_xsm                  true
+xen-unstable               build-i386                                    enable_xsm                  false
+xen-unstable               build-i386-xsm                                enable_xsm                  true
+xen-unstable               test-amd64-amd64-libvirt                      enable_xsm                  false
+xen-unstable               test-amd64-amd64-libvirt-xsm                  enable_xsm                  true
+xen-unstable               test-amd64-amd64-xl                           enable_xsm                  false
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64     enable_xsm                  false
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm enable_xsm                  true
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64     enable_xsm                  false
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm enable_xsm                  true
+xen-unstable               test-amd64-amd64-xl-qemuu-ovmf-amd64          enable_xsm                  false
+xen-unstable               test-amd64-amd64-xl-xsm                       enable_xsm                  true
+xen-unstable               test-amd64-i386-libvirt                       enable_xsm                  false
+xen-unstable               test-amd64-i386-libvirt-xsm                   enable_xsm                  true
+xen-unstable               test-amd64-i386-xl                            enable_xsm                  false
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64      enable_xsm                  false
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  enable_xsm                  true
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64      enable_xsm                  false
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  enable_xsm                  true
+xen-unstable               test-amd64-i386-xl-qemuu-ovmf-amd64           enable_xsm                  false
+xen-unstable               test-amd64-i386-xl-xsm                        enable_xsm                  true
+xen-unstable               test-armhf-armhf-libvirt                      enable_xsm                  false
+xen-unstable               test-armhf-armhf-libvirt-xsm                  enable_xsm                  true
+xen-unstable               test-armhf-armhf-xl                           enable_xsm                  false
+xen-unstable               test-armhf-armhf-xl-xsm                       enable_xsm                  true
+xen-unstable               build-amd64-xsm                               host_hostflags              share-build-wheezy-amd64,arch-amd64,suite-wheezy,purpose-build
+xen-unstable               build-armhf-xsm                               host_hostflags              share-build-wheezy-armhf,arch-armhf,suite-wheezy,purpose-build
+xen-unstable               build-i386-xsm                                host_hostflags              share-build-wheezy-i386,arch-i386,suite-wheezy,purpose-build
+xen-unstable               test-amd64-amd64-libvirt-xsm                  kernbuildjob                build-amd64-pvops
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm kernbuildjob                build-amd64-pvops
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm kernbuildjob                build-amd64-pvops
+xen-unstable               test-amd64-amd64-xl-xsm                       kernbuildjob                build-amd64-pvops
+xen-unstable               test-amd64-i386-libvirt-xsm                   kernbuildjob                build-i386-pvops
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  kernbuildjob                build-i386-pvops
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  kernbuildjob                build-i386-pvops
+xen-unstable               test-amd64-i386-xl-xsm                        kernbuildjob                build-i386-pvops
+xen-unstable               test-armhf-armhf-libvirt-xsm                  kernbuildjob                build-armhf-pvops
+xen-unstable               test-armhf-armhf-xl-xsm                       kernbuildjob                build-armhf-pvops
+xen-unstable               test-amd64-amd64-libvirt-xsm                  kernkind                    pvops
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm kernkind                    pvops
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm kernkind                    pvops
+xen-unstable               test-amd64-amd64-xl-xsm                       kernkind                    pvops
+xen-unstable               test-amd64-i386-libvirt-xsm                   kernkind                    pvops
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  kernkind                    pvops
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  kernkind                    pvops
+xen-unstable               test-amd64-i386-xl-xsm                        kernkind                    pvops
+xen-unstable               test-armhf-armhf-libvirt-xsm                  kernkind                    pvops
+xen-unstable               test-armhf-armhf-xl-xsm                       kernkind                    pvops
+xen-unstable               test-amd64-amd64-libvirt-xsm                  libvirtbuildjob             build-amd64-xsm-libvirt
+xen-unstable               test-amd64-i386-libvirt-xsm                   libvirtbuildjob             build-i386-xsm-libvirt
+xen-unstable               test-armhf-armhf-libvirt-xsm                  libvirtbuildjob             build-armhf-xsm-libvirt
+xen-unstable               build-amd64-xsm                               revision_qemu
+xen-unstable               build-armhf-xsm                               revision_qemu
+xen-unstable               build-i386-xsm                                revision_qemu
+xen-unstable               build-amd64-xsm                               revision_qemuu              1ebb75b1fee779621b63e84fefa7b07354c43a99
+xen-unstable               build-armhf-xsm                               revision_qemuu              1ebb75b1fee779621b63e84fefa7b07354c43a99
+xen-unstable               build-i386-xsm                                revision_qemuu              1ebb75b1fee779621b63e84fefa7b07354c43a99
+xen-unstable               build-amd64-xsm                               revision_seabios
+xen-unstable               build-armhf-xsm                               revision_seabios
+xen-unstable               build-i386-xsm                                revision_seabios
+xen-unstable               build-amd64-xsm                               revision_xen                60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
+xen-unstable               build-armhf-xsm                               revision_xen                60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
+xen-unstable               build-i386-xsm                                revision_xen                60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
+xen-unstable               test-amd64-amd64-libvirt-xsm                  toolstack                   libvirt
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm toolstack                   xl
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm toolstack                   xl
+xen-unstable               test-amd64-amd64-xl-xsm                       toolstack                   xl
+xen-unstable               test-amd64-i386-libvirt-xsm                   toolstack                   libvirt
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  toolstack                   xl
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  toolstack                   xl
+xen-unstable               test-amd64-i386-xl-xsm                        toolstack                   xl
+xen-unstable               test-armhf-armhf-libvirt-xsm                  toolstack                   libvirt
+xen-unstable               test-armhf-armhf-xl-xsm                       toolstack                   xl
+xen-unstable               build-amd64-xsm                               tree_qemu                   git://xenbits.xen.org/staging/qemu-xen-unstable.git
+xen-unstable               build-armhf-xsm                               tree_qemu                   git://xenbits.xen.org/staging/qemu-xen-unstable.git
+xen-unstable               build-i386-xsm                                tree_qemu                   git://xenbits.xen.org/staging/qemu-xen-unstable.git
+xen-unstable               build-amd64-xsm                               tree_qemuu                  git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+xen-unstable               build-armhf-xsm                               tree_qemuu                  git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+xen-unstable               build-i386-xsm                                tree_qemuu                  git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+xen-unstable               build-amd64-xsm                               tree_seabios
+xen-unstable               build-armhf-xsm                               tree_seabios
+xen-unstable               build-i386-xsm                                tree_seabios
+xen-unstable               build-amd64-xsm                               tree_xen                    git://xenbits.xen.org/xen.git
+xen-unstable               build-armhf-xsm                               tree_xen                    git://xenbits.xen.org/xen.git
+xen-unstable               build-i386-xsm                                tree_xen                    git://xenbits.xen.org/xen.git
+xen-unstable               test-amd64-amd64-libvirt-xsm                  xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-amd64-xl-xsm                       xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-i386-libvirt-xsm                   xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-i386-xl-xsm                        xenbuildjob                 build-amd64-xsm
+xen-unstable               test-armhf-armhf-libvirt-xsm                  xenbuildjob                 build-armhf-xsm
+xen-unstable               test-armhf-armhf-xl-xsm                       xenbuildjob                 build-armhf-xsm

Wei Liu (9):
  overlay: update overlay/etc/grub.d/20_linux_xen
  ts-xen-build-prep: install checkpolicy
  ts-xen-build: build with XSM support if requested
  mfi-common: create build-$arch-xsm job
  Debian.pm: pass in XSM configuration to bootloader setup routines
  Debian.pm: load flask policy in uboot
  ts-xen-install: install Xen with XSM support if requested
  make-flight: factor out do_pv_debian_tests
  mfi-common, make-flight: create XSM test jobs

 Osstest/Debian.pm               |   55 ++++++++++++++----
 make-flight                     |   42 ++++++++++----
 mfi-common                      |   35 +++++++++++-
 overlay/etc/grub.d/20_linux_xen |  117 +++++++++++++++++++++++++++++++--------
 ts-xen-build                    |   12 ++++
 ts-xen-build-prep               |    2 +-
 ts-xen-install                  |    4 +-
 7 files changed, 217 insertions(+), 50 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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeB-0001lb-HD; Wed, 10 Dec 2014 22:22:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xype9-0001kN-7I
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A4/23-15461-497C8845; Wed, 10 Dec 2014 22:22:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418250128!14438752!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20899 invoked from network); 10 Dec 2014 22:22:10 -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 Dec 2014 22:22:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679393"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-CO;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:29 +0000
Message-ID: <1418250095-13287-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 3/9] ts-xen-build: build with XSM
	support if requested
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Changes in v4:
1. Use "true" instead of "y"
---
 ts-xen-build |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/ts-xen-build b/ts-xen-build
index 661f186..9ee4522 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -27,6 +27,8 @@ tsreadconfig();
 selectbuildhost(\@ARGV);
 # remaining arguments are passed as targets to "make"
 builddirsprops();
+
+my $enable_xsm = $r{enable_xsm} =~ m/true/ ? 1 : 0;
     
 sub checkout () {
     prepbuilddirs();
@@ -34,6 +36,7 @@ sub checkout () {
     build_clone($ho, 'xen', $builddir, 'xen');
 
     my $debug_build = $r{xen_build_debug} || 'y';
+    my $build_xsm = $enable_xsm ? 'y' : 'n';
 
     # Do not set this unless you know what you are doing. This arm
     # option makes the build specific to a particular type of
@@ -47,6 +50,7 @@ sub checkout () {
         cd $builddir/xen
 	>.config
 	echo >>.config debug=$debug_build
+	echo >>.config XSM_ENABLE=$build_xsm
 	echo >>.config GIT_HTTP=y
 	echo >>.config LIBLEAFDIR_x86_64=lib
 	echo >>.config QEMU_REMOTE='$r{tree_qemu}'
@@ -114,6 +118,14 @@ END
     buildcmd_stamped_logged(9000, 'build', '',<<END,'');
             $make_prefix make $makeflags @ARGV
 END
+
+    if ($enable_xsm) {
+	my $xen_version = target_cmd_output_root($ho, <<END, 30);
+	    cd $builddir/xen
+	    $make_prefix make xenversion
+END
+        store_runvar("flaskpolicy", "xenpolicy-" . $xen_version);
+    }
 }
 
 sub collectversions () {
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1Xype7-0001k0-Gf; Wed, 10 Dec 2014 22:22:11 +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 1Xype6-0001jv-NZ
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D5/4C-25276-297C8845; Wed, 10 Dec 2014 22:22:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418250128!14438752!1
X-Originating-IP: [66.165.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 20861 invoked from network); 10 Dec 2014 22:22:09 -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 Dec 2014 22:22:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679392"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-AP;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:28 +0000
Message-ID: <1418250095-13287-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 2/9] ts-xen-build-prep: install
	checkpolicy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 used to complie Flask policy.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 ts-xen-build-prep |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index a7d0d03..4b016ae 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -178,7 +178,7 @@ sub prep () {
                                autoconf automake libtool xsltproc
                                libxml2-utils libxml2-dev libnl-dev
                                libdevmapper-dev w3c-dtd-xhtml libxml-xpath-perl
-			       ccache));
+			       ccache checkpolicy));
 
     target_cmd_root($ho, "chmod -R a+r /usr/share/git-core/templates");
     # workaround for Debian #595728
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeD-0001mK-5e; Wed, 10 Dec 2014 22:22:17 +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 1XypeB-0001lE-2Z
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:15 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2B/4C-25276-597C8845; Wed, 10 Dec 2014 22:22:13 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418250129!11351812!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31581 invoked from network); 10 Dec 2014 22:22:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 22:22:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679398"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-Ga;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:34 +0000
Message-ID: <1418250095-13287-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 8/9] make-flight: factor out
	do_pv_debian_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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 make-flight |   21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/make-flight b/make-flight
index 9963a46..35904be 100755
--- a/make-flight
+++ b/make-flight
@@ -281,17 +281,24 @@ do_passthrough_tests () {
   done
 }
 
-test_matrix_do_one () {
-
-  # Basic PV Linux test with xl
+do_pv_debian_test_one () {
+  toolstack=$1
 
-  job_create_test test-$xenarch$kern-$dom0arch-xl test-debian xl \
+  job_create_test test-$xenarch$kern-$dom0arch-$toolstack test-debian $toolstack \
             $xenarch $dom0arch                                   \
             $debian_runvars all_hostflags=$most_hostflags
+}
 
-  job_create_test test-$xenarch$kern-$dom0arch-libvirt test-debian libvirt \
-            $xenarch $dom0arch                                       \
-            $debian_runvars all_hostflags=$most_hostflags
+do_pv_debian_tests () {
+  for toolstack in xl libvirt; do
+    do_pv_debian_test_one $toolstack
+  done
+}
+
+test_matrix_do_one () {
+
+  # Basic PV Linux test with xl
+  do_pv_debian_tests
 
   # No further arm tests at the moment
   if [ $dom0arch = armhf ]; then
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeA-0001kp-1v; Wed, 10 Dec 2014 22:22:14 +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 1Xype8-0001k4-0a
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	77/4C-25276-397C8845; Wed, 10 Dec 2014 22:22:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418250129!11351812!1
X-Originating-IP: [66.165.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 31501 invoked from network); 10 Dec 2014 22:22:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 22:22:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679395"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-EB;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:32 +0000
Message-ID: <1418250095-13287-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 6/9] Debian.pm: load flask policy in
	uboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 Osstest/Debian.pm |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 22b40ff..08f0ad1 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -123,6 +123,22 @@ sub setupboot_uboot ($$$$) {
 	my $kern = "vmlinuz-$want_kernver";
 	my $initrd = "initrd.img-$want_kernver";
 
+	my $flask_commands = "";
+	if ($want_xsm) {
+	    my $flaskpolicy = $r{flaskpolicy};
+	    $flask_commands = <<END;
+
+setenv flask_policy_addr_r 0x1200000
+flaskpolicy=`readlink /boot/$flaskpolicy`
+ext2load scsi 0 \\\${flask_policy_addr_r} \$flaskpolicy
+fdt mknod /chosen module\@2
+fdt set /chosen/module\@2 compatible "xen,xsm-policy"
+fdt set /chosen/module\@2 reg <\\\${flask_policy_addr_r} \\\${filesize}>
+echo Loaded $flaskpolicy to \\\${flask_policy_addr_r} (\\\${filesize})
+
+END
+	}
+
 	my $root= target_guest_lv_name($ho,"root");
 
 	logm("Xen options: $xenhopt");
@@ -176,6 +192,8 @@ fdt set /chosen/module\@1 compatible "xen,linux-initrd" "xen,multiboot-module"
 fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} \\\${filesize}>
 echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize})
 
+${flask_commands}
+
 fdt print /chosen
 
 echo Booting \\\${xen_addr_r} - \\\${fdt_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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeB-0001lO-4G; Wed, 10 Dec 2014 22:22:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xype8-0001kF-O6
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	98/4C-25276-397C8845; Wed, 10 Dec 2014 22:22:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418250129!11351812!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31523 invoked from network); 10 Dec 2014 22:22:11 -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 Dec 2014 22:22:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679396"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-D3;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:30 +0000
Message-ID: <1418250095-13287-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 4/9] mfi-common: create
	build-$arch-xsm job
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
---
Changes in v4:
1. Use "true" and "false" instead of "y" and "n".
2. Rename xenbranch_wants_xsm_tests to xenbranch_xsm_variants.
---
 mfi-common |   23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/mfi-common b/mfi-common
index 5c4f5d5..161847c 100644
--- a/mfi-common
+++ b/mfi-common
@@ -41,6 +41,19 @@ branch_wants_rumpkernel_tests () {
   esac
 }
 
+xenbranch_xsm_variants () {
+    # Test XSM from 4.5 onwards
+    case "$xenbranch" in
+    xen-3.*-testing) echo "false";;
+    xen-4.0-testing) echo "false";;
+    xen-4.1-testing) echo "false";;
+    xen-4.2-testing) echo "false";;
+    xen-4.3-testing) echo "false";;
+    xen-4.4-testing) echo "false";;
+    *) echo "false true";
+    esac
+}
+
 create_build_jobs () {
 
   local arch
@@ -139,8 +152,15 @@ create_build_jobs () {
 
     build_hostflags=share-build-$suite-$arch,arch-$arch,suite-$suite,purpose-build
 
-    ./cs-job-create $flight build-$arch build                                \
+    for enable_xsm in $(xenbranch_xsm_variants) ; do
+      if [ x$enable_xsm = xtrue ] ; then
+        xsm_suffix="-xsm"
+      else
+        xsm_suffix=""
+      fi
+      ./cs-job-create $flight build-$arch$xsm_suffix build                   \
                 arch=$arch enable_xend=$build_defxend enable_ovmf=$enable_ovmf\
+                enable_xsm=$enable_xsm                                       \
         tree_qemu=$TREE_QEMU                                                 \
         tree_qemuu=$TREE_QEMU_UPSTREAM                                       \
         tree_xen=$TREE_XEN                                                   \
@@ -152,6 +172,7 @@ create_build_jobs () {
                 revision_qemu=$REVISION_QEMU                                 \
                 revision_qemuu=$REVISION_QEMU_UPSTREAM                       \
                 revision_seabios=$REVISION_SEABIOS
+    done
 
     if [ $build_extraxend = "true" ] ; then
     ./cs-job-create $flight build-$arch-xend build                           \
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeB-0001li-SL; Wed, 10 Dec 2014 22:22:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xype9-0001kc-GH
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:13 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B9/4C-25276-497C8845; Wed, 10 Dec 2014 22:22:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418250129!11351812!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31549 invoked from network); 10 Dec 2014 22:22:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 22:22:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679403"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-HA;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:35 +0000
Message-ID: <1418250095-13287-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 9/9] mfi-common,
	make-flight: create XSM test jobs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Duplicate Debian PV and HVM test jobs for XSM testing.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Changes in v4:
1. Parse runvar to determine xsm suffix
---
 make-flight |   23 +++++++++++++++++++----
 mfi-common  |   12 ++++++++++--
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/make-flight b/make-flight
index 35904be..00bc0fc 100755
--- a/make-flight
+++ b/make-flight
@@ -200,27 +200,36 @@ do_hvm_win7_x64_tests () {
 do_hvm_debian_test_one () {
   testname=$1
   bios=$2
+  xsm=$3
+
   job_create_test test-$xenarch$kern-$dom0arch-xl$qemuu_suffix-$testname-amd64\
     test-debianhvm xl $xenarch $dom0arch $qemuu_runvar \
+    enable_xsm=$xsm                             \
     debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
     bios=$bios \
     all_hostflags=$most_hostflags,hvm
 }
 
 do_hvm_debian_tests() {
+  test_xsm=$(xenbranch_xsm_variants)
+
   if [ $xenarch != amd64 ]; then
     return
   fi
 
   # QEMU upstream supports ovmf and seabios
   if [ "x$qemuu_suffix" == "x-qemuu" ]; then
-    do_hvm_debian_test_one ovmf ovmf
-    do_hvm_debian_test_one debianhvm seabios
+    do_hvm_debian_test_one ovmf ovmf false
+    for xsm in $test_xsm ; do
+      do_hvm_debian_test_one debianhvm seabios $xsm
+    done
   fi
 
   # QEMU traditional supports rombios
   if [ "x$qemuu_suffix" == "x-qemut" ]; then
-    do_hvm_debian_test_one debianhvm rombios
+    for xsm in $test_xsm ; do
+      do_hvm_debian_test_one debianhvm rombios $xsm
+    done
   fi
 }
 
@@ -283,15 +292,21 @@ do_passthrough_tests () {
 
 do_pv_debian_test_one () {
   toolstack=$1
+  xsm=$2
 
   job_create_test test-$xenarch$kern-$dom0arch-$toolstack test-debian $toolstack \
             $xenarch $dom0arch                                   \
+            enable_xsm=$xsm                                      \
             $debian_runvars all_hostflags=$most_hostflags
 }
 
 do_pv_debian_tests () {
+  test_xsm=$(xenbranch_xsm_variants)
+
   for toolstack in xl libvirt; do
-    do_pv_debian_test_one $toolstack
+    for xsm in $test_xsm ; do
+      do_pv_debian_test_one $toolstack $xsm
+    done
   done
 }
 
diff --git a/mfi-common b/mfi-common
index 161847c..3a97a90 100644
--- a/mfi-common
+++ b/mfi-common
@@ -268,8 +268,16 @@ job_create_test () {
   local xenarch=$1; shift
   local dom0arch=$1; shift
 
-  xenbuildjob="${bfi}build-$xenarch"
-  buildjob="${bfi}build-$dom0arch"
+  xsm_suffix=""
+  for rv in $@ ; do
+      case $rv in
+          enable_xsm=true) xsm_suffix="-xsm";;
+      esac
+  done
+
+  job="$job$xsm_suffix"
+  xenbuildjob="${bfi}build-$xenarch$xsm_suffix"
+  buildjob="${bfi}build-$dom0arch$xsm_suffix"
   tsbuildjob=
 
   case "$xenbranch:$toolstack" in
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeA-0001lH-OZ; Wed, 10 Dec 2014 22:22:14 +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 1Xype8-0001kD-KS
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:12 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FD/BF-09842-497C8845; Wed, 10 Dec 2014 22:22:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418250128!14438752!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20997 invoked from network); 10 Dec 2014 22:22:11 -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 Dec 2014 22:22:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679401"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-Ek;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:33 +0000
Message-ID: <1418250095-13287-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 7/9] ts-xen-install: install Xen with
	XSM support if requested
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Changes in v4:
1. Use "true" instead of "y"
---
 ts-xen-install |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ts-xen-install b/ts-xen-install
index 910181e..08b5fe1 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -46,6 +46,8 @@ if (@ARGV and $ARGV[0] eq '--check') {
 
 our $ho;
 
+my $enable_xsm = $r{enable_xsm} =~ m/true/ ? 1 : 0;
+
 my %distpath;
 
 sub packages () {
@@ -171,7 +173,7 @@ sub setupboot () {
     }
 
     my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
-    debian_boot_setup($ho, $want_kernver, 0, $xenhopt, \%distpath, \@hooks);
+    debian_boot_setup($ho, $want_kernver, $enable_xsm, $xenhopt, \%distpath, \@hooks);
 
     logm("ready to boot Xen");
 }
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeC-0001lq-8d; Wed, 10 Dec 2014 22:22: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 1Xype9-0001kf-OP
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:14 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	61/45-27623-497C8845; Wed, 10 Dec 2014 22:22:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418250130!12451475!1
X-Originating-IP: [66.165.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 4800 invoked from network); 10 Dec 2014 22:22:11 -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;
	10 Dec 2014 22:22:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679402"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-7h;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:26 +0000
Message-ID: <1418250095-13287-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>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 0/9] XSM test case for OSSTest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 attempts to duplicate some Debian test cases for XSM. This
is version 4 of this series.

Tests duplicated for xen-unstable branch:
  build-{i386,amd64,armhf}-xsm
  test-amd64-{i386,amd64}-{xl,libvirt}-xsm
  test-armhf-armhf-{xl,libvirt}-xsm
  test-amd64-{i386,amd64}-xl-qemuu-debianhvm-amd64-xsm
  test-amd64-(i386,amd64}-xl-qemut-debianhvm-amd64-xsm

Changes in v4 can be found in individual patch.

See below for output of
  ./standalone-generate-dump-flight-runvars > origin # master
  ./standalone-generate-dump-flight-runvars > xsm # this series applied
  diff -ub ../origin xsm  | grep '-xen-unstable' | sed  's/[ \t]*$//' # nothing
  diff -ub ../origin xsm  | grep '+xen-unstable' | sed  's/[ \t]*$//'

+xen-unstable               test-amd64-amd64-libvirt-xsm                  all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,hvm
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,hvm
+xen-unstable               test-amd64-amd64-xl-xsm                       all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
+xen-unstable               test-amd64-i386-libvirt-xsm                   all_hostflags               arch-i386,arch-xen-amd64,suite-wheezy,purpose-test
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  all_hostflags               arch-i386,arch-xen-amd64,suite-wheezy,purpose-test,hvm
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  all_hostflags               arch-i386,arch-xen-amd64,suite-wheezy,purpose-test,hvm
+xen-unstable               test-amd64-i386-xl-xsm                        all_hostflags               arch-i386,arch-xen-amd64,suite-wheezy,purpose-test
+xen-unstable               test-armhf-armhf-libvirt-xsm                  all_hostflags               arch-armhf,arch-xen-armhf,suite-wheezy,purpose-test
+xen-unstable               test-armhf-armhf-xl-xsm                       all_hostflags               arch-armhf,arch-xen-armhf,suite-wheezy,purpose-test
+xen-unstable               build-amd64-xsm                               arch                        amd64
+xen-unstable               build-armhf-xsm                               arch                        armhf
+xen-unstable               build-i386-xsm                                arch                        i386
+xen-unstable               test-amd64-amd64-libvirt-xsm                  arch                        amd64
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm arch                        amd64
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm arch                        amd64
+xen-unstable               test-amd64-amd64-xl-xsm                       arch                        amd64
+xen-unstable               test-amd64-i386-libvirt-xsm                   arch                        i386
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  arch                        i386
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  arch                        i386
+xen-unstable               test-amd64-i386-xl-xsm                        arch                        i386
+xen-unstable               test-armhf-armhf-libvirt-xsm                  arch                        armhf
+xen-unstable               test-armhf-armhf-xl-xsm                       arch                        armhf
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm bios                        rombios
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm bios                        seabios
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  bios                        rombios
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  bios                        seabios
+xen-unstable               build-amd64-xsm                               build_lvextend_max          50
+xen-unstable               build-armhf-xsm                               build_lvextend_max          50
+xen-unstable               build-i386-xsm                                build_lvextend_max          50
+xen-unstable               test-amd64-amd64-libvirt-xsm                  buildjob                    build-amd64-xsm
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm buildjob                    build-amd64-xsm
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm buildjob                    build-amd64-xsm
+xen-unstable               test-amd64-amd64-xl-xsm                       buildjob                    build-amd64-xsm
+xen-unstable               test-amd64-i386-libvirt-xsm                   buildjob                    build-i386-xsm
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  buildjob                    build-i386-xsm
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  buildjob                    build-i386-xsm
+xen-unstable               test-amd64-i386-xl-xsm                        buildjob                    build-i386-xsm
+xen-unstable               test-armhf-armhf-libvirt-xsm                  buildjob                    build-armhf-xsm
+xen-unstable               test-armhf-armhf-xl-xsm                       buildjob                    build-armhf-xsm
+xen-unstable               test-amd64-amd64-libvirt-xsm                  debian_arch                 amd64
+xen-unstable               test-amd64-amd64-xl-xsm                       debian_arch                 amd64
+xen-unstable               test-amd64-i386-libvirt-xsm                   debian_arch                 i386
+xen-unstable               test-amd64-i386-xl-xsm                        debian_arch                 i386
+xen-unstable               test-armhf-armhf-libvirt-xsm                  debian_arch                 armhf
+xen-unstable               test-armhf-armhf-xl-xsm                       debian_arch                 armhf
+xen-unstable               test-amd64-amd64-libvirt-xsm                  debian_kernkind             pvops
+xen-unstable               test-amd64-amd64-xl-xsm                       debian_kernkind             pvops
+xen-unstable               test-amd64-i386-libvirt-xsm                   debian_kernkind             pvops
+xen-unstable               test-amd64-i386-xl-xsm                        debian_kernkind             pvops
+xen-unstable               test-armhf-armhf-libvirt-xsm                  debian_kernkind             pvops
+xen-unstable               test-armhf-armhf-xl-xsm                       debian_kernkind             pvops
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm debianhvm_image             debian-7.2.0-amd64-CD-1.iso
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm debianhvm_image             debian-7.2.0-amd64-CD-1.iso
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  debianhvm_image             debian-7.2.0-amd64-CD-1.iso
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  debianhvm_image             debian-7.2.0-amd64-CD-1.iso
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm device_model_version        qemu-xen-traditional
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm device_model_version        qemu-xen
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  device_model_version        qemu-xen-traditional
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  device_model_version        qemu-xen
+xen-unstable               build-amd64-xsm                               enable_ovmf                 true
+xen-unstable               build-armhf-xsm                               enable_ovmf                 true
+xen-unstable               build-i386-xsm                                enable_ovmf                 true
+xen-unstable               build-amd64-xsm                               enable_xend                 false
+xen-unstable               build-armhf-xsm                               enable_xend                 false
+xen-unstable               build-i386-xsm                                enable_xend                 false
+xen-unstable               build-amd64                                   enable_xsm                  false
+xen-unstable               build-amd64-xsm                               enable_xsm                  true
+xen-unstable               build-armhf                                   enable_xsm                  false
+xen-unstable               build-armhf-xsm                               enable_xsm                  true
+xen-unstable               build-i386                                    enable_xsm                  false
+xen-unstable               build-i386-xsm                                enable_xsm                  true
+xen-unstable               test-amd64-amd64-libvirt                      enable_xsm                  false
+xen-unstable               test-amd64-amd64-libvirt-xsm                  enable_xsm                  true
+xen-unstable               test-amd64-amd64-xl                           enable_xsm                  false
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64     enable_xsm                  false
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm enable_xsm                  true
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64     enable_xsm                  false
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm enable_xsm                  true
+xen-unstable               test-amd64-amd64-xl-qemuu-ovmf-amd64          enable_xsm                  false
+xen-unstable               test-amd64-amd64-xl-xsm                       enable_xsm                  true
+xen-unstable               test-amd64-i386-libvirt                       enable_xsm                  false
+xen-unstable               test-amd64-i386-libvirt-xsm                   enable_xsm                  true
+xen-unstable               test-amd64-i386-xl                            enable_xsm                  false
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64      enable_xsm                  false
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  enable_xsm                  true
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64      enable_xsm                  false
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  enable_xsm                  true
+xen-unstable               test-amd64-i386-xl-qemuu-ovmf-amd64           enable_xsm                  false
+xen-unstable               test-amd64-i386-xl-xsm                        enable_xsm                  true
+xen-unstable               test-armhf-armhf-libvirt                      enable_xsm                  false
+xen-unstable               test-armhf-armhf-libvirt-xsm                  enable_xsm                  true
+xen-unstable               test-armhf-armhf-xl                           enable_xsm                  false
+xen-unstable               test-armhf-armhf-xl-xsm                       enable_xsm                  true
+xen-unstable               build-amd64-xsm                               host_hostflags              share-build-wheezy-amd64,arch-amd64,suite-wheezy,purpose-build
+xen-unstable               build-armhf-xsm                               host_hostflags              share-build-wheezy-armhf,arch-armhf,suite-wheezy,purpose-build
+xen-unstable               build-i386-xsm                                host_hostflags              share-build-wheezy-i386,arch-i386,suite-wheezy,purpose-build
+xen-unstable               test-amd64-amd64-libvirt-xsm                  kernbuildjob                build-amd64-pvops
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm kernbuildjob                build-amd64-pvops
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm kernbuildjob                build-amd64-pvops
+xen-unstable               test-amd64-amd64-xl-xsm                       kernbuildjob                build-amd64-pvops
+xen-unstable               test-amd64-i386-libvirt-xsm                   kernbuildjob                build-i386-pvops
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  kernbuildjob                build-i386-pvops
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  kernbuildjob                build-i386-pvops
+xen-unstable               test-amd64-i386-xl-xsm                        kernbuildjob                build-i386-pvops
+xen-unstable               test-armhf-armhf-libvirt-xsm                  kernbuildjob                build-armhf-pvops
+xen-unstable               test-armhf-armhf-xl-xsm                       kernbuildjob                build-armhf-pvops
+xen-unstable               test-amd64-amd64-libvirt-xsm                  kernkind                    pvops
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm kernkind                    pvops
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm kernkind                    pvops
+xen-unstable               test-amd64-amd64-xl-xsm                       kernkind                    pvops
+xen-unstable               test-amd64-i386-libvirt-xsm                   kernkind                    pvops
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  kernkind                    pvops
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  kernkind                    pvops
+xen-unstable               test-amd64-i386-xl-xsm                        kernkind                    pvops
+xen-unstable               test-armhf-armhf-libvirt-xsm                  kernkind                    pvops
+xen-unstable               test-armhf-armhf-xl-xsm                       kernkind                    pvops
+xen-unstable               test-amd64-amd64-libvirt-xsm                  libvirtbuildjob             build-amd64-xsm-libvirt
+xen-unstable               test-amd64-i386-libvirt-xsm                   libvirtbuildjob             build-i386-xsm-libvirt
+xen-unstable               test-armhf-armhf-libvirt-xsm                  libvirtbuildjob             build-armhf-xsm-libvirt
+xen-unstable               build-amd64-xsm                               revision_qemu
+xen-unstable               build-armhf-xsm                               revision_qemu
+xen-unstable               build-i386-xsm                                revision_qemu
+xen-unstable               build-amd64-xsm                               revision_qemuu              1ebb75b1fee779621b63e84fefa7b07354c43a99
+xen-unstable               build-armhf-xsm                               revision_qemuu              1ebb75b1fee779621b63e84fefa7b07354c43a99
+xen-unstable               build-i386-xsm                                revision_qemuu              1ebb75b1fee779621b63e84fefa7b07354c43a99
+xen-unstable               build-amd64-xsm                               revision_seabios
+xen-unstable               build-armhf-xsm                               revision_seabios
+xen-unstable               build-i386-xsm                                revision_seabios
+xen-unstable               build-amd64-xsm                               revision_xen                60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
+xen-unstable               build-armhf-xsm                               revision_xen                60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
+xen-unstable               build-i386-xsm                                revision_xen                60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
+xen-unstable               test-amd64-amd64-libvirt-xsm                  toolstack                   libvirt
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm toolstack                   xl
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm toolstack                   xl
+xen-unstable               test-amd64-amd64-xl-xsm                       toolstack                   xl
+xen-unstable               test-amd64-i386-libvirt-xsm                   toolstack                   libvirt
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  toolstack                   xl
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  toolstack                   xl
+xen-unstable               test-amd64-i386-xl-xsm                        toolstack                   xl
+xen-unstable               test-armhf-armhf-libvirt-xsm                  toolstack                   libvirt
+xen-unstable               test-armhf-armhf-xl-xsm                       toolstack                   xl
+xen-unstable               build-amd64-xsm                               tree_qemu                   git://xenbits.xen.org/staging/qemu-xen-unstable.git
+xen-unstable               build-armhf-xsm                               tree_qemu                   git://xenbits.xen.org/staging/qemu-xen-unstable.git
+xen-unstable               build-i386-xsm                                tree_qemu                   git://xenbits.xen.org/staging/qemu-xen-unstable.git
+xen-unstable               build-amd64-xsm                               tree_qemuu                  git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+xen-unstable               build-armhf-xsm                               tree_qemuu                  git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+xen-unstable               build-i386-xsm                                tree_qemuu                  git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+xen-unstable               build-amd64-xsm                               tree_seabios
+xen-unstable               build-armhf-xsm                               tree_seabios
+xen-unstable               build-i386-xsm                                tree_seabios
+xen-unstable               build-amd64-xsm                               tree_xen                    git://xenbits.xen.org/xen.git
+xen-unstable               build-armhf-xsm                               tree_xen                    git://xenbits.xen.org/xen.git
+xen-unstable               build-i386-xsm                                tree_xen                    git://xenbits.xen.org/xen.git
+xen-unstable               test-amd64-amd64-libvirt-xsm                  xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-amd64-xl-xsm                       xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-i386-libvirt-xsm                   xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  xenbuildjob                 build-amd64-xsm
+xen-unstable               test-amd64-i386-xl-xsm                        xenbuildjob                 build-amd64-xsm
+xen-unstable               test-armhf-armhf-libvirt-xsm                  xenbuildjob                 build-armhf-xsm
+xen-unstable               test-armhf-armhf-xl-xsm                       xenbuildjob                 build-armhf-xsm

Wei Liu (9):
  overlay: update overlay/etc/grub.d/20_linux_xen
  ts-xen-build-prep: install checkpolicy
  ts-xen-build: build with XSM support if requested
  mfi-common: create build-$arch-xsm job
  Debian.pm: pass in XSM configuration to bootloader setup routines
  Debian.pm: load flask policy in uboot
  ts-xen-install: install Xen with XSM support if requested
  make-flight: factor out do_pv_debian_tests
  mfi-common, make-flight: create XSM test jobs

 Osstest/Debian.pm               |   55 ++++++++++++++----
 make-flight                     |   42 ++++++++++----
 mfi-common                      |   35 +++++++++++-
 overlay/etc/grub.d/20_linux_xen |  117 +++++++++++++++++++++++++++++++--------
 ts-xen-build                    |   12 ++++
 ts-xen-build-prep               |    2 +-
 ts-xen-install                  |    4 +-
 7 files changed, 217 insertions(+), 50 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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeB-0001lb-HD; Wed, 10 Dec 2014 22:22:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xype9-0001kN-7I
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A4/23-15461-497C8845; Wed, 10 Dec 2014 22:22:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418250128!14438752!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20899 invoked from network); 10 Dec 2014 22:22:10 -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 Dec 2014 22:22:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679393"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-CO;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:29 +0000
Message-ID: <1418250095-13287-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 3/9] ts-xen-build: build with XSM
	support if requested
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Changes in v4:
1. Use "true" instead of "y"
---
 ts-xen-build |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/ts-xen-build b/ts-xen-build
index 661f186..9ee4522 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -27,6 +27,8 @@ tsreadconfig();
 selectbuildhost(\@ARGV);
 # remaining arguments are passed as targets to "make"
 builddirsprops();
+
+my $enable_xsm = $r{enable_xsm} =~ m/true/ ? 1 : 0;
     
 sub checkout () {
     prepbuilddirs();
@@ -34,6 +36,7 @@ sub checkout () {
     build_clone($ho, 'xen', $builddir, 'xen');
 
     my $debug_build = $r{xen_build_debug} || 'y';
+    my $build_xsm = $enable_xsm ? 'y' : 'n';
 
     # Do not set this unless you know what you are doing. This arm
     # option makes the build specific to a particular type of
@@ -47,6 +50,7 @@ sub checkout () {
         cd $builddir/xen
 	>.config
 	echo >>.config debug=$debug_build
+	echo >>.config XSM_ENABLE=$build_xsm
 	echo >>.config GIT_HTTP=y
 	echo >>.config LIBLEAFDIR_x86_64=lib
 	echo >>.config QEMU_REMOTE='$r{tree_qemu}'
@@ -114,6 +118,14 @@ END
     buildcmd_stamped_logged(9000, 'build', '',<<END,'');
             $make_prefix make $makeflags @ARGV
 END
+
+    if ($enable_xsm) {
+	my $xen_version = target_cmd_output_root($ho, <<END, 30);
+	    cd $builddir/xen
+	    $make_prefix make xenversion
+END
+        store_runvar("flaskpolicy", "xenpolicy-" . $xen_version);
+    }
 }
 
 sub collectversions () {
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1Xype7-0001k0-Gf; Wed, 10 Dec 2014 22:22:11 +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 1Xype6-0001jv-NZ
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D5/4C-25276-297C8845; Wed, 10 Dec 2014 22:22:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418250128!14438752!1
X-Originating-IP: [66.165.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 20861 invoked from network); 10 Dec 2014 22:22:09 -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 Dec 2014 22:22:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679392"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-AP;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:28 +0000
Message-ID: <1418250095-13287-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 2/9] ts-xen-build-prep: install
	checkpolicy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 used to complie Flask policy.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 ts-xen-build-prep |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index a7d0d03..4b016ae 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -178,7 +178,7 @@ sub prep () {
                                autoconf automake libtool xsltproc
                                libxml2-utils libxml2-dev libnl-dev
                                libdevmapper-dev w3c-dtd-xhtml libxml-xpath-perl
-			       ccache));
+			       ccache checkpolicy));
 
     target_cmd_root($ho, "chmod -R a+r /usr/share/git-core/templates");
     # workaround for Debian #595728
-- 
1.7.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 Dec 10 22:22:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 22: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 1XypeA-0001kp-1v; Wed, 10 Dec 2014 22:22:14 +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 1Xype8-0001k4-0a
	for xen-devel@lists.xen.org; Wed, 10 Dec 2014 22:22:12 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	77/4C-25276-397C8845; Wed, 10 Dec 2014 22:22:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418250129!11351812!1
X-Originating-IP: [66.165.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 31501 invoked from network); 10 Dec 2014 22:22:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 22:22:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="202679395"
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.210.2;
	Wed, 10 Dec 2014 17:21: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 1XypdX-0002QP-EB;
	Wed, 10 Dec 2014 22:21:35 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 10 Dec 2014 22:21:32 +0000
Message-ID: <1418250095-13287-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
References: <1418250095-13287-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
X-DLP: MIA1
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [OSSTEST PATCH v4 6/9] Debian.pm: load flask policy in
	uboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 Osstest/Debian.pm |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 22b40ff..08f0ad1 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -123,6 +123,22 @@ sub setupboot_uboot ($$$$) {
 	my $kern = "vmlinuz-$want_kernver";
 	my $initrd = "initrd.img-$want_kernver";
 
+	my $flask_commands = "";
+	if ($want_xsm) {
+	    my $flaskpolicy = $r{flaskpolicy};
+	    $flask_commands = <<END;
+
+setenv flask_policy_addr_r 0x1200000
+flaskpolicy=`readlink /boot/$flaskpolicy`
+ext2load scsi 0 \\\${flask_policy_addr_r} \$flaskpolicy
+fdt mknod /chosen module\@2
+fdt set /chosen/module\@2 compatible "xen,xsm-policy"
+fdt set /chosen/module\@2 reg <\\\${flask_policy_addr_r} \\\${filesize}>
+echo Loaded $flaskpolicy to \\\${flask_policy_addr_r} (\\\${filesize})
+
+END
+	}
+
 	my $root= target_guest_lv_name($ho,"root");
 
 	logm("Xen options: $xenhopt");
@@ -176,6 +192,8 @@ fdt set /chosen/module\@1 compatible "xen,linux-initrd" "xen,multiboot-module"
 fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} \\\${filesize}>
 echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize})
 
+${flask_commands}
+
 fdt print /chosen
 
 echo Booting \\\${xen_addr_r} - \\\${fdt_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 Dec 10 23:29:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 23: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 1Xyqgo-0005VS-1g; Wed, 10 Dec 2014 23:29:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe@perches.com>) id 1Xyqgm-0005VN-BU
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 23:29:00 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	5F/25-02699-B37D8845; Wed, 10 Dec 2014 23:28:59 +0000
X-Env-Sender: joe@perches.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418254137!14309018!1
X-Originating-IP: [216.40.44.98]
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 14799 invoked from network); 10 Dec 2014 23:28:57 -0000
Received: from smtprelay0098.hostedemail.com (HELO smtprelay.hostedemail.com)
	(216.40.44.98) by server-12.tower-27.messagelabs.com with SMTP;
	10 Dec 2014 23:28:57 -0000
Received: from filter.hostedemail.com (unknown [216.40.38.60])
	by smtprelay01.hostedemail.com (Postfix) with ESMTP id 10F5A23412;
	Wed, 10 Dec 2014 23:28:57 +0000 (UTC)
X-Session-Marker: 6A6F6540706572636865732E636F6D
X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, joe@perches.com, :::::::::::::::::,
	RULES_HIT:41:327:355:379:541:800:960:968:973:988:989:1260:1277:1311:1313:1314:1345:1373:1437:1515:1516:1518:1593:1594:1605:1730:1747:1777:1792:1801:2194:2198:2199:2200:2393:2559:2562:2828:2892:2895:2896:2901:2924:2926:3138:3139:3140:3141:3142:3165:3865:3866:3867:3868:3870:3871:3872:3874:4031:4250:4321:4605:5007:6119:6261:7875:7974:8660:9010:9038:10004:10848:11026:11232:11473:11658:11914:12043:12219:12294:12296:12438:12517:12519:12555:12679:13148:13161:13229:13230:13972:14096:14097:14394:21080,
	0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none,
	DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:none,
	Custom_rules:0:0:0
X-HE-Tag: trip24_139eac51b6c5d
X-Filterd-Recvd-Size: 23605
Received: from joe-X200MA.home (pool-71-103-235-196.lsanca.fios.verizon.net
	[71.103.235.196]) (Authenticated sender: joe@perches.com)
	by omf07.hostedemail.com (Postfix) with ESMTPA;
	Wed, 10 Dec 2014 23:28:54 +0000 (UTC)
Message-ID: <1418254133.18092.22.camel@perches.com>
From: Joe Perches <joe@perches.com>
To: Thomas Gleixner <tglx@linutronix.de>, Andrew Morton
	<akpm@linux-foundation.org>
Date: Wed, 10 Dec 2014 15:28:53 -0800
X-Mailer: Evolution 3.12.7-0ubuntu1 
Mime-Version: 1.0
Cc: linux-pm <linux-pm@vger.kernel.org>, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-tegra@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH] treewide: Convert clockevents_notify to use int
	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

As far as I can tell, there's no value indirecting
the cpu passed to this function via a void *.

Update all the callers and called functions from within
clockevents_notify.

Miscellanea:

Add pr_fmt and convert one printk(KERN_ERR to pr_err

Signed-off-by: Joe Perches <joe@perches.com>
---
 arch/arm/mach-omap2/cpuidle44xx.c      |  7 +++----
 arch/arm/mach-tegra/cpuidle-tegra114.c |  4 ++--
 arch/arm/mach-tegra/cpuidle-tegra20.c  |  8 ++++----
 arch/arm/mach-tegra/cpuidle-tegra30.c  |  8 ++++----
 arch/x86/kernel/process.c              |  6 +++---
 arch/x86/xen/suspend.c                 |  2 +-
 drivers/acpi/acpi_pad.c                |  9 +++++----
 drivers/acpi/processor_idle.c          |  4 ++--
 drivers/cpuidle/driver.c               |  3 +--
 drivers/idle/intel_idle.c              |  7 +++----
 include/linux/clockchips.h             |  6 +++---
 kernel/sched/idle.c                    |  4 ++--
 kernel/time/clockevents.c              | 15 +++++++--------
 kernel/time/hrtimer.c                  |  6 ++----
 kernel/time/tick-broadcast.c           | 16 ++++++++--------
 kernel/time/tick-common.c              | 16 ++++++++--------
 kernel/time/tick-internal.h            | 18 +++++++++---------
 kernel/time/timekeeping.c              |  4 ++--
 18 files changed, 69 insertions(+), 74 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 01e398a..5d50aa1 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -112,7 +112,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
 	mpuss_can_lose_context = (cx->mpu_state == PWRDM_POWER_RET) &&
 				 (cx->mpu_logic_state == PWRDM_POWER_OFF);
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
 
 	/*
 	 * Call idle CPU PM enter notifier chain so that
@@ -169,7 +169,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
 	if (dev->cpu == 0 && mpuss_can_lose_context)
 		cpu_cluster_pm_exit();
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
 
 fail:
 	cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
@@ -184,8 +184,7 @@ fail:
  */
 static void omap_setup_broadcast_timer(void *arg)
 {
-	int cpu = smp_processor_id();
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, smp_processor_id());
 }
 
 static struct cpuidle_driver omap4_idle_driver = {
diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index f2b586d..3b2fc3f 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -44,7 +44,7 @@ static int tegra114_idle_power_down(struct cpuidle_device *dev,
 	tegra_set_cpu_in_lp2();
 	cpu_pm_enter();
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
 
 	call_firmware_op(prepare_idle);
 
@@ -52,7 +52,7 @@ static int tegra114_idle_power_down(struct cpuidle_device *dev,
 	if (call_firmware_op(do_idle, 0) == -ENOSYS)
 		cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
 
 	cpu_pm_exit();
 	tegra_clear_cpu_in_lp2();
diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index 4f25a7c..ab30758 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -136,11 +136,11 @@ static bool tegra20_cpu_cluster_power_down(struct cpuidle_device *dev,
 	if (tegra20_reset_cpu_1() || !tegra_cpu_rail_off_ready())
 		return false;
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
 
 	tegra_idle_lp2_last();
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
 
 	if (cpu_online(1))
 		tegra20_wake_cpu1_from_reset();
@@ -153,13 +153,13 @@ static bool tegra20_idle_enter_lp2_cpu_1(struct cpuidle_device *dev,
 					 struct cpuidle_driver *drv,
 					 int index)
 {
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
 
 	cpu_suspend(0, tegra20_sleep_cpu_secondary_finish);
 
 	tegra20_cpu_clear_resettable();
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
 
 	return true;
 }
diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index f8815ed..67d0492 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -76,11 +76,11 @@ static bool tegra30_cpu_cluster_power_down(struct cpuidle_device *dev,
 		return false;
 	}
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
 
 	tegra_idle_lp2_last();
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
 
 	return true;
 }
@@ -90,13 +90,13 @@ static bool tegra30_cpu_core_power_down(struct cpuidle_device *dev,
 					struct cpuidle_driver *drv,
 					int index)
 {
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
 
 	smp_wmb();
 
 	cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
 
 	return true;
 }
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index e127dda..09290b0 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -380,10 +380,10 @@ static void amd_e400_idle(void)
 			 * Force broadcast so ACPI can not interfere.
 			 */
 			clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_FORCE,
-					   &cpu);
+					   cpu);
 			pr_info("Switch to broadcast mode on CPU%d\n", cpu);
 		}
-		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
 
 		default_idle();
 
@@ -392,7 +392,7 @@ static void amd_e400_idle(void)
 		 * called with interrupts disabled.
 		 */
 		local_irq_disable();
-		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
 		local_irq_enable();
 	} else
 		default_idle();
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index c4df9db..61bab6a 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -87,7 +87,7 @@ static void xen_vcpu_notify_restore(void *data)
 	if ( smp_processor_id() == 0)
 		return;
 
-	clockevents_notify(reason, NULL);
+	clockevents_notify(reason, -1);
 }
 
 void xen_arch_resume(void)
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index c7b105c..63138e4 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -180,17 +180,18 @@ static int power_saving_thread(void *data)
 			if (lapic_detected_unstable && !lapic_marked_unstable) {
 				int i;
 				/* LAPIC could halt in idle, so notify users */
-				for_each_online_cpu(i)
+				for_each_online_cpu(i) {
 					clockevents_notify(
 						CLOCK_EVT_NOTIFY_BROADCAST_ON,
-						&i);
+						i);
+				}
 				lapic_marked_unstable = 1;
 			}
 			local_irq_disable();
 			cpu = smp_processor_id();
 			if (lapic_marked_unstable)
 				clockevents_notify(
-					CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
+					CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
 			stop_critical_timings();
 
 			mwait_idle_with_hints(power_saving_mwait_eax, 1);
@@ -198,7 +199,7 @@ static int power_saving_thread(void *data)
 			start_critical_timings();
 			if (lapic_marked_unstable)
 				clockevents_notify(
-					CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
+					CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
 			local_irq_enable();
 
 			if (time_before(expire_time, jiffies)) {
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 4995365..2eaa450 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -162,7 +162,7 @@ static void __lapic_timer_propagate_broadcast(void *arg)
 	reason = pr->power.timer_broadcast_on_state < INT_MAX ?
 		CLOCK_EVT_NOTIFY_BROADCAST_ON : CLOCK_EVT_NOTIFY_BROADCAST_OFF;
 
-	clockevents_notify(reason, &pr->id);
+	clockevents_notify(reason, pr->id);
 }
 
 static void lapic_timer_propagate_broadcast(struct acpi_processor *pr)
@@ -183,7 +183,7 @@ static void lapic_timer_state_broadcast(struct acpi_processor *pr,
 
 		reason = broadcast ?  CLOCK_EVT_NOTIFY_BROADCAST_ENTER :
 			CLOCK_EVT_NOTIFY_BROADCAST_EXIT;
-		clockevents_notify(reason, &pr->id);
+		clockevents_notify(reason, pr->id);
 	}
 }
 
diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index 2697e87..2fcc20b 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -143,8 +143,7 @@ static inline void __cpuidle_unset_driver(struct cpuidle_driver *drv)
  */
 static void cpuidle_setup_broadcast_timer(void *arg)
 {
-	int cpu = smp_processor_id();
-	clockevents_notify((long)(arg), &cpu);
+	clockevents_notify((long)arg, smp_processor_id());
 }
 
 /**
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 9cceacb..945b1f3 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -582,12 +582,12 @@ static int intel_idle(struct cpuidle_device *dev,
 		leave_mm(cpu);
 
 	if (!(lapic_timer_reliable_states & (1 << (cstate))))
-		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
 
 	mwait_idle_with_hints(eax, ecx);
 
 	if (!(lapic_timer_reliable_states & (1 << (cstate))))
-		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
 
 	return index;
 }
@@ -595,12 +595,11 @@ static int intel_idle(struct cpuidle_device *dev,
 static void __setup_broadcast_timer(void *arg)
 {
 	unsigned long reason = (unsigned long)arg;
-	int cpu = smp_processor_id();
 
 	reason = reason ?
 		CLOCK_EVT_NOTIFY_BROADCAST_ON : CLOCK_EVT_NOTIFY_BROADCAST_OFF;
 
-	clockevents_notify(reason, &cpu);
+	clockevents_notify(reason, smp_processor_id());
 }
 
 static int cpu_hotplug_notify(struct notifier_block *n,
diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
index 2e4cb67..4e03069 100644
--- a/include/linux/clockchips.h
+++ b/include/linux/clockchips.h
@@ -195,9 +195,9 @@ static inline void tick_setup_hrtimer_broadcast(void) {};
 #endif
 
 #ifdef CONFIG_GENERIC_CLOCKEVENTS
-extern int clockevents_notify(unsigned long reason, void *arg);
+extern int clockevents_notify(unsigned long reason, int cpu);
 #else
-static inline int clockevents_notify(unsigned long reason, void *arg) { return 0; }
+static inline int clockevents_notify(unsigned long reason, int cpu) { return 0; }
 #endif
 
 #else /* CONFIG_GENERIC_CLOCKEVENTS_BUILD */
@@ -205,7 +205,7 @@ static inline int clockevents_notify(unsigned long reason, void *arg) { return 0
 static inline void clockevents_suspend(void) {}
 static inline void clockevents_resume(void) {}
 
-static inline int clockevents_notify(unsigned long reason, void *arg) { return 0; }
+static inline int clockevents_notify(unsigned long reason, int cpu) { return 0; }
 static inline int tick_check_broadcast_expired(void) { return 0; }
 static inline void tick_setup_hrtimer_broadcast(void) {};
 
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index c47fce7..e68faee 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -144,7 +144,7 @@ use_default:
 	 * fail if it is not available
 	 */
 	if (broadcast &&
-	    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu))
+	    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu))
 		goto use_default;
 
 	/* Take note of the planned idle state. */
@@ -161,7 +161,7 @@ use_default:
 	idle_set_state(this_rq(), NULL);
 
 	if (broadcast)
-		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
 
 	/*
 	 * Give the governor an opportunity to reflect on the outcome
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 5544990..69973be 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -546,11 +546,11 @@ void clockevents_resume(void)
  * clockevents_notify - notification about relevant events
  * Returns 0 on success, any other value on error
  */
-int clockevents_notify(unsigned long reason, void *arg)
+int clockevents_notify(unsigned long reason, int cpu)
 {
 	struct clock_event_device *dev, *tmp;
 	unsigned long flags;
-	int cpu, ret = 0;
+	int ret = 0;
 
 	raw_spin_lock_irqsave(&clockevents_lock, flags);
 
@@ -558,7 +558,7 @@ int clockevents_notify(unsigned long reason, void *arg)
 	case CLOCK_EVT_NOTIFY_BROADCAST_ON:
 	case CLOCK_EVT_NOTIFY_BROADCAST_OFF:
 	case CLOCK_EVT_NOTIFY_BROADCAST_FORCE:
-		tick_broadcast_on_off(reason, arg);
+		tick_broadcast_on_off(reason, cpu);
 		break;
 
 	case CLOCK_EVT_NOTIFY_BROADCAST_ENTER:
@@ -567,7 +567,7 @@ int clockevents_notify(unsigned long reason, void *arg)
 		break;
 
 	case CLOCK_EVT_NOTIFY_CPU_DYING:
-		tick_handover_do_timer(arg);
+		tick_handover_do_timer(cpu);
 		break;
 
 	case CLOCK_EVT_NOTIFY_SUSPEND:
@@ -580,9 +580,9 @@ int clockevents_notify(unsigned long reason, void *arg)
 		break;
 
 	case CLOCK_EVT_NOTIFY_CPU_DEAD:
-		tick_shutdown_broadcast_oneshot(arg);
-		tick_shutdown_broadcast(arg);
-		tick_shutdown(arg);
+		tick_shutdown_broadcast_oneshot(cpu);
+		tick_shutdown_broadcast(cpu);
+		tick_shutdown(cpu);
 		/*
 		 * Unregister the clock event devices which were
 		 * released from the users in the notify chain.
@@ -592,7 +592,6 @@ int clockevents_notify(unsigned long reason, void *arg)
 		/*
 		 * Now check whether the CPU has left unused per cpu devices
 		 */
-		cpu = *((int *)arg);
 		list_for_each_entry_safe(dev, tmp, &clockevent_devices, list) {
 			if (cpumask_test_cpu(cpu, dev->cpumask) &&
 			    cpumask_weight(dev->cpumask) == 1 &&
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 37e50aa..e8c903f 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1717,15 +1717,13 @@ static int hrtimer_cpu_notify(struct notifier_block *self,
 #ifdef CONFIG_HOTPLUG_CPU
 	case CPU_DYING:
 	case CPU_DYING_FROZEN:
-		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DYING, &scpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DYING, scpu);
 		break;
 	case CPU_DEAD:
 	case CPU_DEAD_FROZEN:
-	{
-		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, &scpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, scpu);
 		migrate_hrtimers(scpu);
 		break;
-	}
 #endif
 
 	default:
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 066f0ec..4ede817 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -11,6 +11,9 @@
  * This code is licenced under the GPL version 2. For details see
  * kernel-base/COPYING.
  */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include <linux/cpu.h>
 #include <linux/err.h>
 #include <linux/hrtimer.h>
@@ -396,11 +399,10 @@ out:
  * Powerstate information: The system enters/leaves a state, where
  * affected devices might stop.
  */
-void tick_broadcast_on_off(unsigned long reason, int *oncpu)
+void tick_broadcast_on_off(unsigned long reason, int oncpu)
 {
-	if (!cpumask_test_cpu(*oncpu, cpu_online_mask))
-		printk(KERN_ERR "tick-broadcast: ignoring broadcast for "
-		       "offline CPU #%d\n", *oncpu);
+	if (!cpumask_test_cpu(oncpu, cpu_online_mask))
+		pr_err("ignoring broadcast for offline CPU #%d\n", oncpu);
 	else
 		tick_do_broadcast_on_off(&reason);
 }
@@ -419,11 +421,10 @@ void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast)
 /*
  * Remove a CPU from broadcasting
  */
-void tick_shutdown_broadcast(unsigned int *cpup)
+void tick_shutdown_broadcast(int cpu)
 {
 	struct clock_event_device *bc;
 	unsigned long flags;
-	unsigned int cpu = *cpup;
 
 	raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
 
@@ -898,10 +899,9 @@ void tick_broadcast_switch_to_oneshot(void)
 /*
  * Remove a dead CPU from broadcasting
  */
-void tick_shutdown_broadcast_oneshot(unsigned int *cpup)
+void tick_shutdown_broadcast_oneshot(int cpu)
 {
 	unsigned long flags;
-	unsigned int cpu = *cpup;
 
 	raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
 
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 7efeedf..ae4b200 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -337,14 +337,14 @@ out_bc:
  *
  * Called with interrupts disabled.
  */
-void tick_handover_do_timer(int *cpup)
+void tick_handover_do_timer(int cpu)
 {
-	if (*cpup == tick_do_timer_cpu) {
-		int cpu = cpumask_first(cpu_online_mask);
+	if (cpu != tick_do_timer_cpu)
+		return;
 
-		tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu :
-			TICK_DO_TIMER_NONE;
-	}
+	cpu = cpumask_first(cpu_online_mask);
+
+	tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu : TICK_DO_TIMER_NONE;
 }
 
 /*
@@ -354,9 +354,9 @@ void tick_handover_do_timer(int *cpup)
  * access the hardware device itself.
  * We just set the mode and remove it from the lists.
  */
-void tick_shutdown(unsigned int *cpup)
+void tick_shutdown(int cpu)
 {
-	struct tick_device *td = &per_cpu(tick_cpu_device, *cpup);
+	struct tick_device *td = &per_cpu(tick_cpu_device, cpu);
 	struct clock_event_device *dev = td->evtdev;
 
 	td->mode = TICKDEV_MODE_PERIODIC;
diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
index 366aeb4..57ab722 100644
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@ -23,8 +23,8 @@ extern int tick_do_timer_cpu __read_mostly;
 extern void tick_setup_periodic(struct clock_event_device *dev, int broadcast);
 extern void tick_handle_periodic(struct clock_event_device *dev);
 extern void tick_check_new_device(struct clock_event_device *dev);
-extern void tick_handover_do_timer(int *cpup);
-extern void tick_shutdown(unsigned int *cpup);
+extern void tick_handover_do_timer(int cpu);
+extern void tick_shutdown(int cpu);
 extern void tick_suspend(void);
 extern void tick_resume(void);
 extern bool tick_check_replacement(struct clock_event_device *curdev,
@@ -50,7 +50,7 @@ extern void tick_resume_oneshot(void);
 extern void tick_broadcast_setup_oneshot(struct clock_event_device *bc);
 extern int tick_broadcast_oneshot_control(unsigned long reason);
 extern void tick_broadcast_switch_to_oneshot(void);
-extern void tick_shutdown_broadcast_oneshot(unsigned int *cpup);
+extern void tick_shutdown_broadcast_oneshot(int cpu);
 extern int tick_resume_broadcast_oneshot(struct clock_event_device *bc);
 extern int tick_broadcast_oneshot_active(void);
 extern void tick_check_oneshot_broadcast_this_cpu(void);
@@ -62,7 +62,7 @@ static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
 }
 static inline int tick_broadcast_oneshot_control(unsigned long reason) { return 0; }
 static inline void tick_broadcast_switch_to_oneshot(void) { }
-static inline void tick_shutdown_broadcast_oneshot(unsigned int *cpup) { }
+static inline void tick_shutdown_broadcast_oneshot(int cpu) { }
 static inline int tick_broadcast_oneshot_active(void) { return 0; }
 static inline void tick_check_oneshot_broadcast_this_cpu(void) { }
 static inline bool tick_broadcast_oneshot_available(void) { return true; }
@@ -90,7 +90,7 @@ static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
 	BUG();
 }
 static inline int tick_broadcast_oneshot_control(unsigned long reason) { return 0; }
-static inline void tick_shutdown_broadcast_oneshot(unsigned int *cpup) { }
+static inline void tick_shutdown_broadcast_oneshot(int cpu) { }
 static inline int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
 {
 	return 0;
@@ -113,8 +113,8 @@ static inline void tick_nohz_init(void) { }
 extern int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu);
 extern void tick_install_broadcast_device(struct clock_event_device *dev);
 extern int tick_is_broadcast_device(struct clock_event_device *dev);
-extern void tick_broadcast_on_off(unsigned long reason, int *oncpu);
-extern void tick_shutdown_broadcast(unsigned int *cpup);
+extern void tick_broadcast_on_off(unsigned long reason, int oncpu);
+extern void tick_shutdown_broadcast(int cpu);
 extern void tick_suspend_broadcast(void);
 extern int tick_resume_broadcast(void);
 extern void tick_broadcast_init(void);
@@ -138,8 +138,8 @@ static inline int tick_device_uses_broadcast(struct clock_event_device *dev,
 	return 0;
 }
 static inline void tick_do_periodic_broadcast(struct clock_event_device *d) { }
-static inline void tick_broadcast_on_off(unsigned long reason, int *oncpu) { }
-static inline void tick_shutdown_broadcast(unsigned int *cpup) { }
+static inline void tick_broadcast_on_off(unsigned long reason, int oncpu) { }
+static inline void tick_shutdown_broadcast(int cpu) { }
 static inline void tick_suspend_broadcast(void) { }
 static inline int tick_resume_broadcast(void) { return 0; }
 static inline void tick_broadcast_init(void) { }
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 6a93185..dc84f52 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1245,7 +1245,7 @@ static void timekeeping_resume(void)
 
 	touch_softlockup_watchdog();
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, NULL);
+	clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, -1);
 
 	/* Resume hrtimers */
 	hrtimers_resume();
@@ -1299,7 +1299,7 @@ static int timekeeping_suspend(void)
 	write_seqcount_end(&tk_core.seq);
 	raw_spin_unlock_irqrestore(&timekeeper_lock, flags);
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, NULL);
+	clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, -1);
 	clocksource_suspend();
 	clockevents_suspend();
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 23:29:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 23: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 1Xyqgo-0005VS-1g; Wed, 10 Dec 2014 23:29:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe@perches.com>) id 1Xyqgm-0005VN-BU
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 23:29:00 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	5F/25-02699-B37D8845; Wed, 10 Dec 2014 23:28:59 +0000
X-Env-Sender: joe@perches.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418254137!14309018!1
X-Originating-IP: [216.40.44.98]
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 14799 invoked from network); 10 Dec 2014 23:28:57 -0000
Received: from smtprelay0098.hostedemail.com (HELO smtprelay.hostedemail.com)
	(216.40.44.98) by server-12.tower-27.messagelabs.com with SMTP;
	10 Dec 2014 23:28:57 -0000
Received: from filter.hostedemail.com (unknown [216.40.38.60])
	by smtprelay01.hostedemail.com (Postfix) with ESMTP id 10F5A23412;
	Wed, 10 Dec 2014 23:28:57 +0000 (UTC)
X-Session-Marker: 6A6F6540706572636865732E636F6D
X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, joe@perches.com, :::::::::::::::::,
	RULES_HIT:41:327:355:379:541:800:960:968:973:988:989:1260:1277:1311:1313:1314:1345:1373:1437:1515:1516:1518:1593:1594:1605:1730:1747:1777:1792:1801:2194:2198:2199:2200:2393:2559:2562:2828:2892:2895:2896:2901:2924:2926:3138:3139:3140:3141:3142:3165:3865:3866:3867:3868:3870:3871:3872:3874:4031:4250:4321:4605:5007:6119:6261:7875:7974:8660:9010:9038:10004:10848:11026:11232:11473:11658:11914:12043:12219:12294:12296:12438:12517:12519:12555:12679:13148:13161:13229:13230:13972:14096:14097:14394:21080,
	0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none,
	DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:none,
	Custom_rules:0:0:0
X-HE-Tag: trip24_139eac51b6c5d
X-Filterd-Recvd-Size: 23605
Received: from joe-X200MA.home (pool-71-103-235-196.lsanca.fios.verizon.net
	[71.103.235.196]) (Authenticated sender: joe@perches.com)
	by omf07.hostedemail.com (Postfix) with ESMTPA;
	Wed, 10 Dec 2014 23:28:54 +0000 (UTC)
Message-ID: <1418254133.18092.22.camel@perches.com>
From: Joe Perches <joe@perches.com>
To: Thomas Gleixner <tglx@linutronix.de>, Andrew Morton
	<akpm@linux-foundation.org>
Date: Wed, 10 Dec 2014 15:28:53 -0800
X-Mailer: Evolution 3.12.7-0ubuntu1 
Mime-Version: 1.0
Cc: linux-pm <linux-pm@vger.kernel.org>, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-tegra@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH] treewide: Convert clockevents_notify to use int
	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

As far as I can tell, there's no value indirecting
the cpu passed to this function via a void *.

Update all the callers and called functions from within
clockevents_notify.

Miscellanea:

Add pr_fmt and convert one printk(KERN_ERR to pr_err

Signed-off-by: Joe Perches <joe@perches.com>
---
 arch/arm/mach-omap2/cpuidle44xx.c      |  7 +++----
 arch/arm/mach-tegra/cpuidle-tegra114.c |  4 ++--
 arch/arm/mach-tegra/cpuidle-tegra20.c  |  8 ++++----
 arch/arm/mach-tegra/cpuidle-tegra30.c  |  8 ++++----
 arch/x86/kernel/process.c              |  6 +++---
 arch/x86/xen/suspend.c                 |  2 +-
 drivers/acpi/acpi_pad.c                |  9 +++++----
 drivers/acpi/processor_idle.c          |  4 ++--
 drivers/cpuidle/driver.c               |  3 +--
 drivers/idle/intel_idle.c              |  7 +++----
 include/linux/clockchips.h             |  6 +++---
 kernel/sched/idle.c                    |  4 ++--
 kernel/time/clockevents.c              | 15 +++++++--------
 kernel/time/hrtimer.c                  |  6 ++----
 kernel/time/tick-broadcast.c           | 16 ++++++++--------
 kernel/time/tick-common.c              | 16 ++++++++--------
 kernel/time/tick-internal.h            | 18 +++++++++---------
 kernel/time/timekeeping.c              |  4 ++--
 18 files changed, 69 insertions(+), 74 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 01e398a..5d50aa1 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -112,7 +112,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
 	mpuss_can_lose_context = (cx->mpu_state == PWRDM_POWER_RET) &&
 				 (cx->mpu_logic_state == PWRDM_POWER_OFF);
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
 
 	/*
 	 * Call idle CPU PM enter notifier chain so that
@@ -169,7 +169,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
 	if (dev->cpu == 0 && mpuss_can_lose_context)
 		cpu_cluster_pm_exit();
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
 
 fail:
 	cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
@@ -184,8 +184,7 @@ fail:
  */
 static void omap_setup_broadcast_timer(void *arg)
 {
-	int cpu = smp_processor_id();
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, smp_processor_id());
 }
 
 static struct cpuidle_driver omap4_idle_driver = {
diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index f2b586d..3b2fc3f 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -44,7 +44,7 @@ static int tegra114_idle_power_down(struct cpuidle_device *dev,
 	tegra_set_cpu_in_lp2();
 	cpu_pm_enter();
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
 
 	call_firmware_op(prepare_idle);
 
@@ -52,7 +52,7 @@ static int tegra114_idle_power_down(struct cpuidle_device *dev,
 	if (call_firmware_op(do_idle, 0) == -ENOSYS)
 		cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
 
 	cpu_pm_exit();
 	tegra_clear_cpu_in_lp2();
diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
index 4f25a7c..ab30758 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -136,11 +136,11 @@ static bool tegra20_cpu_cluster_power_down(struct cpuidle_device *dev,
 	if (tegra20_reset_cpu_1() || !tegra_cpu_rail_off_ready())
 		return false;
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
 
 	tegra_idle_lp2_last();
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
 
 	if (cpu_online(1))
 		tegra20_wake_cpu1_from_reset();
@@ -153,13 +153,13 @@ static bool tegra20_idle_enter_lp2_cpu_1(struct cpuidle_device *dev,
 					 struct cpuidle_driver *drv,
 					 int index)
 {
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
 
 	cpu_suspend(0, tegra20_sleep_cpu_secondary_finish);
 
 	tegra20_cpu_clear_resettable();
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
 
 	return true;
 }
diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
index f8815ed..67d0492 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra30.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
@@ -76,11 +76,11 @@ static bool tegra30_cpu_cluster_power_down(struct cpuidle_device *dev,
 		return false;
 	}
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
 
 	tegra_idle_lp2_last();
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
 
 	return true;
 }
@@ -90,13 +90,13 @@ static bool tegra30_cpu_core_power_down(struct cpuidle_device *dev,
 					struct cpuidle_driver *drv,
 					int index)
 {
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
 
 	smp_wmb();
 
 	cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
 
 	return true;
 }
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index e127dda..09290b0 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -380,10 +380,10 @@ static void amd_e400_idle(void)
 			 * Force broadcast so ACPI can not interfere.
 			 */
 			clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_FORCE,
-					   &cpu);
+					   cpu);
 			pr_info("Switch to broadcast mode on CPU%d\n", cpu);
 		}
-		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
 
 		default_idle();
 
@@ -392,7 +392,7 @@ static void amd_e400_idle(void)
 		 * called with interrupts disabled.
 		 */
 		local_irq_disable();
-		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
 		local_irq_enable();
 	} else
 		default_idle();
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index c4df9db..61bab6a 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -87,7 +87,7 @@ static void xen_vcpu_notify_restore(void *data)
 	if ( smp_processor_id() == 0)
 		return;
 
-	clockevents_notify(reason, NULL);
+	clockevents_notify(reason, -1);
 }
 
 void xen_arch_resume(void)
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index c7b105c..63138e4 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -180,17 +180,18 @@ static int power_saving_thread(void *data)
 			if (lapic_detected_unstable && !lapic_marked_unstable) {
 				int i;
 				/* LAPIC could halt in idle, so notify users */
-				for_each_online_cpu(i)
+				for_each_online_cpu(i) {
 					clockevents_notify(
 						CLOCK_EVT_NOTIFY_BROADCAST_ON,
-						&i);
+						i);
+				}
 				lapic_marked_unstable = 1;
 			}
 			local_irq_disable();
 			cpu = smp_processor_id();
 			if (lapic_marked_unstable)
 				clockevents_notify(
-					CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
+					CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
 			stop_critical_timings();
 
 			mwait_idle_with_hints(power_saving_mwait_eax, 1);
@@ -198,7 +199,7 @@ static int power_saving_thread(void *data)
 			start_critical_timings();
 			if (lapic_marked_unstable)
 				clockevents_notify(
-					CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
+					CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
 			local_irq_enable();
 
 			if (time_before(expire_time, jiffies)) {
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 4995365..2eaa450 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -162,7 +162,7 @@ static void __lapic_timer_propagate_broadcast(void *arg)
 	reason = pr->power.timer_broadcast_on_state < INT_MAX ?
 		CLOCK_EVT_NOTIFY_BROADCAST_ON : CLOCK_EVT_NOTIFY_BROADCAST_OFF;
 
-	clockevents_notify(reason, &pr->id);
+	clockevents_notify(reason, pr->id);
 }
 
 static void lapic_timer_propagate_broadcast(struct acpi_processor *pr)
@@ -183,7 +183,7 @@ static void lapic_timer_state_broadcast(struct acpi_processor *pr,
 
 		reason = broadcast ?  CLOCK_EVT_NOTIFY_BROADCAST_ENTER :
 			CLOCK_EVT_NOTIFY_BROADCAST_EXIT;
-		clockevents_notify(reason, &pr->id);
+		clockevents_notify(reason, pr->id);
 	}
 }
 
diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index 2697e87..2fcc20b 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -143,8 +143,7 @@ static inline void __cpuidle_unset_driver(struct cpuidle_driver *drv)
  */
 static void cpuidle_setup_broadcast_timer(void *arg)
 {
-	int cpu = smp_processor_id();
-	clockevents_notify((long)(arg), &cpu);
+	clockevents_notify((long)arg, smp_processor_id());
 }
 
 /**
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 9cceacb..945b1f3 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -582,12 +582,12 @@ static int intel_idle(struct cpuidle_device *dev,
 		leave_mm(cpu);
 
 	if (!(lapic_timer_reliable_states & (1 << (cstate))))
-		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
 
 	mwait_idle_with_hints(eax, ecx);
 
 	if (!(lapic_timer_reliable_states & (1 << (cstate))))
-		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
 
 	return index;
 }
@@ -595,12 +595,11 @@ static int intel_idle(struct cpuidle_device *dev,
 static void __setup_broadcast_timer(void *arg)
 {
 	unsigned long reason = (unsigned long)arg;
-	int cpu = smp_processor_id();
 
 	reason = reason ?
 		CLOCK_EVT_NOTIFY_BROADCAST_ON : CLOCK_EVT_NOTIFY_BROADCAST_OFF;
 
-	clockevents_notify(reason, &cpu);
+	clockevents_notify(reason, smp_processor_id());
 }
 
 static int cpu_hotplug_notify(struct notifier_block *n,
diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
index 2e4cb67..4e03069 100644
--- a/include/linux/clockchips.h
+++ b/include/linux/clockchips.h
@@ -195,9 +195,9 @@ static inline void tick_setup_hrtimer_broadcast(void) {};
 #endif
 
 #ifdef CONFIG_GENERIC_CLOCKEVENTS
-extern int clockevents_notify(unsigned long reason, void *arg);
+extern int clockevents_notify(unsigned long reason, int cpu);
 #else
-static inline int clockevents_notify(unsigned long reason, void *arg) { return 0; }
+static inline int clockevents_notify(unsigned long reason, int cpu) { return 0; }
 #endif
 
 #else /* CONFIG_GENERIC_CLOCKEVENTS_BUILD */
@@ -205,7 +205,7 @@ static inline int clockevents_notify(unsigned long reason, void *arg) { return 0
 static inline void clockevents_suspend(void) {}
 static inline void clockevents_resume(void) {}
 
-static inline int clockevents_notify(unsigned long reason, void *arg) { return 0; }
+static inline int clockevents_notify(unsigned long reason, int cpu) { return 0; }
 static inline int tick_check_broadcast_expired(void) { return 0; }
 static inline void tick_setup_hrtimer_broadcast(void) {};
 
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index c47fce7..e68faee 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -144,7 +144,7 @@ use_default:
 	 * fail if it is not available
 	 */
 	if (broadcast &&
-	    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu))
+	    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu))
 		goto use_default;
 
 	/* Take note of the planned idle state. */
@@ -161,7 +161,7 @@ use_default:
 	idle_set_state(this_rq(), NULL);
 
 	if (broadcast)
-		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
 
 	/*
 	 * Give the governor an opportunity to reflect on the outcome
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 5544990..69973be 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -546,11 +546,11 @@ void clockevents_resume(void)
  * clockevents_notify - notification about relevant events
  * Returns 0 on success, any other value on error
  */
-int clockevents_notify(unsigned long reason, void *arg)
+int clockevents_notify(unsigned long reason, int cpu)
 {
 	struct clock_event_device *dev, *tmp;
 	unsigned long flags;
-	int cpu, ret = 0;
+	int ret = 0;
 
 	raw_spin_lock_irqsave(&clockevents_lock, flags);
 
@@ -558,7 +558,7 @@ int clockevents_notify(unsigned long reason, void *arg)
 	case CLOCK_EVT_NOTIFY_BROADCAST_ON:
 	case CLOCK_EVT_NOTIFY_BROADCAST_OFF:
 	case CLOCK_EVT_NOTIFY_BROADCAST_FORCE:
-		tick_broadcast_on_off(reason, arg);
+		tick_broadcast_on_off(reason, cpu);
 		break;
 
 	case CLOCK_EVT_NOTIFY_BROADCAST_ENTER:
@@ -567,7 +567,7 @@ int clockevents_notify(unsigned long reason, void *arg)
 		break;
 
 	case CLOCK_EVT_NOTIFY_CPU_DYING:
-		tick_handover_do_timer(arg);
+		tick_handover_do_timer(cpu);
 		break;
 
 	case CLOCK_EVT_NOTIFY_SUSPEND:
@@ -580,9 +580,9 @@ int clockevents_notify(unsigned long reason, void *arg)
 		break;
 
 	case CLOCK_EVT_NOTIFY_CPU_DEAD:
-		tick_shutdown_broadcast_oneshot(arg);
-		tick_shutdown_broadcast(arg);
-		tick_shutdown(arg);
+		tick_shutdown_broadcast_oneshot(cpu);
+		tick_shutdown_broadcast(cpu);
+		tick_shutdown(cpu);
 		/*
 		 * Unregister the clock event devices which were
 		 * released from the users in the notify chain.
@@ -592,7 +592,6 @@ int clockevents_notify(unsigned long reason, void *arg)
 		/*
 		 * Now check whether the CPU has left unused per cpu devices
 		 */
-		cpu = *((int *)arg);
 		list_for_each_entry_safe(dev, tmp, &clockevent_devices, list) {
 			if (cpumask_test_cpu(cpu, dev->cpumask) &&
 			    cpumask_weight(dev->cpumask) == 1 &&
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 37e50aa..e8c903f 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1717,15 +1717,13 @@ static int hrtimer_cpu_notify(struct notifier_block *self,
 #ifdef CONFIG_HOTPLUG_CPU
 	case CPU_DYING:
 	case CPU_DYING_FROZEN:
-		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DYING, &scpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DYING, scpu);
 		break;
 	case CPU_DEAD:
 	case CPU_DEAD_FROZEN:
-	{
-		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, &scpu);
+		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, scpu);
 		migrate_hrtimers(scpu);
 		break;
-	}
 #endif
 
 	default:
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 066f0ec..4ede817 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -11,6 +11,9 @@
  * This code is licenced under the GPL version 2. For details see
  * kernel-base/COPYING.
  */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include <linux/cpu.h>
 #include <linux/err.h>
 #include <linux/hrtimer.h>
@@ -396,11 +399,10 @@ out:
  * Powerstate information: The system enters/leaves a state, where
  * affected devices might stop.
  */
-void tick_broadcast_on_off(unsigned long reason, int *oncpu)
+void tick_broadcast_on_off(unsigned long reason, int oncpu)
 {
-	if (!cpumask_test_cpu(*oncpu, cpu_online_mask))
-		printk(KERN_ERR "tick-broadcast: ignoring broadcast for "
-		       "offline CPU #%d\n", *oncpu);
+	if (!cpumask_test_cpu(oncpu, cpu_online_mask))
+		pr_err("ignoring broadcast for offline CPU #%d\n", oncpu);
 	else
 		tick_do_broadcast_on_off(&reason);
 }
@@ -419,11 +421,10 @@ void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast)
 /*
  * Remove a CPU from broadcasting
  */
-void tick_shutdown_broadcast(unsigned int *cpup)
+void tick_shutdown_broadcast(int cpu)
 {
 	struct clock_event_device *bc;
 	unsigned long flags;
-	unsigned int cpu = *cpup;
 
 	raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
 
@@ -898,10 +899,9 @@ void tick_broadcast_switch_to_oneshot(void)
 /*
  * Remove a dead CPU from broadcasting
  */
-void tick_shutdown_broadcast_oneshot(unsigned int *cpup)
+void tick_shutdown_broadcast_oneshot(int cpu)
 {
 	unsigned long flags;
-	unsigned int cpu = *cpup;
 
 	raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
 
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 7efeedf..ae4b200 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -337,14 +337,14 @@ out_bc:
  *
  * Called with interrupts disabled.
  */
-void tick_handover_do_timer(int *cpup)
+void tick_handover_do_timer(int cpu)
 {
-	if (*cpup == tick_do_timer_cpu) {
-		int cpu = cpumask_first(cpu_online_mask);
+	if (cpu != tick_do_timer_cpu)
+		return;
 
-		tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu :
-			TICK_DO_TIMER_NONE;
-	}
+	cpu = cpumask_first(cpu_online_mask);
+
+	tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu : TICK_DO_TIMER_NONE;
 }
 
 /*
@@ -354,9 +354,9 @@ void tick_handover_do_timer(int *cpup)
  * access the hardware device itself.
  * We just set the mode and remove it from the lists.
  */
-void tick_shutdown(unsigned int *cpup)
+void tick_shutdown(int cpu)
 {
-	struct tick_device *td = &per_cpu(tick_cpu_device, *cpup);
+	struct tick_device *td = &per_cpu(tick_cpu_device, cpu);
 	struct clock_event_device *dev = td->evtdev;
 
 	td->mode = TICKDEV_MODE_PERIODIC;
diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
index 366aeb4..57ab722 100644
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@ -23,8 +23,8 @@ extern int tick_do_timer_cpu __read_mostly;
 extern void tick_setup_periodic(struct clock_event_device *dev, int broadcast);
 extern void tick_handle_periodic(struct clock_event_device *dev);
 extern void tick_check_new_device(struct clock_event_device *dev);
-extern void tick_handover_do_timer(int *cpup);
-extern void tick_shutdown(unsigned int *cpup);
+extern void tick_handover_do_timer(int cpu);
+extern void tick_shutdown(int cpu);
 extern void tick_suspend(void);
 extern void tick_resume(void);
 extern bool tick_check_replacement(struct clock_event_device *curdev,
@@ -50,7 +50,7 @@ extern void tick_resume_oneshot(void);
 extern void tick_broadcast_setup_oneshot(struct clock_event_device *bc);
 extern int tick_broadcast_oneshot_control(unsigned long reason);
 extern void tick_broadcast_switch_to_oneshot(void);
-extern void tick_shutdown_broadcast_oneshot(unsigned int *cpup);
+extern void tick_shutdown_broadcast_oneshot(int cpu);
 extern int tick_resume_broadcast_oneshot(struct clock_event_device *bc);
 extern int tick_broadcast_oneshot_active(void);
 extern void tick_check_oneshot_broadcast_this_cpu(void);
@@ -62,7 +62,7 @@ static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
 }
 static inline int tick_broadcast_oneshot_control(unsigned long reason) { return 0; }
 static inline void tick_broadcast_switch_to_oneshot(void) { }
-static inline void tick_shutdown_broadcast_oneshot(unsigned int *cpup) { }
+static inline void tick_shutdown_broadcast_oneshot(int cpu) { }
 static inline int tick_broadcast_oneshot_active(void) { return 0; }
 static inline void tick_check_oneshot_broadcast_this_cpu(void) { }
 static inline bool tick_broadcast_oneshot_available(void) { return true; }
@@ -90,7 +90,7 @@ static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
 	BUG();
 }
 static inline int tick_broadcast_oneshot_control(unsigned long reason) { return 0; }
-static inline void tick_shutdown_broadcast_oneshot(unsigned int *cpup) { }
+static inline void tick_shutdown_broadcast_oneshot(int cpu) { }
 static inline int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
 {
 	return 0;
@@ -113,8 +113,8 @@ static inline void tick_nohz_init(void) { }
 extern int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu);
 extern void tick_install_broadcast_device(struct clock_event_device *dev);
 extern int tick_is_broadcast_device(struct clock_event_device *dev);
-extern void tick_broadcast_on_off(unsigned long reason, int *oncpu);
-extern void tick_shutdown_broadcast(unsigned int *cpup);
+extern void tick_broadcast_on_off(unsigned long reason, int oncpu);
+extern void tick_shutdown_broadcast(int cpu);
 extern void tick_suspend_broadcast(void);
 extern int tick_resume_broadcast(void);
 extern void tick_broadcast_init(void);
@@ -138,8 +138,8 @@ static inline int tick_device_uses_broadcast(struct clock_event_device *dev,
 	return 0;
 }
 static inline void tick_do_periodic_broadcast(struct clock_event_device *d) { }
-static inline void tick_broadcast_on_off(unsigned long reason, int *oncpu) { }
-static inline void tick_shutdown_broadcast(unsigned int *cpup) { }
+static inline void tick_broadcast_on_off(unsigned long reason, int oncpu) { }
+static inline void tick_shutdown_broadcast(int cpu) { }
 static inline void tick_suspend_broadcast(void) { }
 static inline int tick_resume_broadcast(void) { return 0; }
 static inline void tick_broadcast_init(void) { }
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 6a93185..dc84f52 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1245,7 +1245,7 @@ static void timekeeping_resume(void)
 
 	touch_softlockup_watchdog();
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, NULL);
+	clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, -1);
 
 	/* Resume hrtimers */
 	hrtimers_resume();
@@ -1299,7 +1299,7 @@ static int timekeeping_suspend(void)
 	write_seqcount_end(&tk_core.seq);
 	raw_spin_unlock_irqrestore(&timekeeper_lock, flags);
 
-	clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, NULL);
+	clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, -1);
 	clocksource_suspend();
 	clockevents_suspend();
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 23:35:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 23:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyqmc-0005xk-1F; Wed, 10 Dec 2014 23:35:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1Xyqma-0005xf-Nf
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 23:35:00 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	1C/77-02699-4A8D8845; Wed, 10 Dec 2014 23:35:00 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418254497!8868589!1
X-Originating-IP: [209.85.192.171]
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 31822 invoked from network); 10 Dec 2014 23:34:59 -0000
Received: from mail-pd0-f171.google.com (HELO mail-pd0-f171.google.com)
	(209.85.192.171)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 23:34:59 -0000
Received: by mail-pd0-f171.google.com with SMTP id y13so3735719pdi.16
	for <xen-devel@lists.xenproject.org>;
	Wed, 10 Dec 2014 15:34:57 -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=cVv/kWS8Xfc7ZubKVI8uWX1hB6+DqQP56K0uBiR+Ldg=;
	b=d/BoPZqsfIn1IC6BZAuhfABC/0CtUUd/CVQjNDoZlFCUMkgiWoS+iUhJvLiBBLf8cf
	kGwDg9E6CA3Y96TrFL2hFWdsF8h3IMiCEPUCMZ6KgoB/UCHHzmB8a+NS25JXu3PmMLRC
	sjMrZTRC6TJWEqcYfAKB7P9J7Tz9ROutd8aBC8semgNxI32/g1DnYS3EhWQVtTGs4l7C
	9qjc6d9bz645hU0zlmEwEkKDnQyDUvUrYhNSycJre6GCkkgbvz2GGEezhvAsUQY5F9wv
	d+Zov5LTodDn0f9fMi1plKgiaaPNc3/fwUfKDCo8H9KHq3ZIU0+IpLDAIWNIEtf4UP2B
	Wb6Q==
X-Received: by 10.66.176.202 with SMTP id ck10mr11807292pac.18.1418254497575; 
	Wed, 10 Dec 2014 15:34:57 -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 fb7sm5263757pab.10.2014.12.10.15.34.53
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 10 Dec 2014 15:34:55 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Wed, 10 Dec 2014 15:34:52 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: mingo@redhat.com,
	peterz@infradead.org
Date: Wed, 10 Dec 2014 15:34:45 -0800
Message-Id: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
Cc: jgross@suse.com, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, david.vrabel@citrix.com, JBeulich@suse.com,
	hpa@zytor.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v2 0/2] x86: add xen hypercall preemption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

This is my second series which addresses hypercall preemption
on Xen. On the first iteration of this series [0] I tried as
much as possible to avoid cond_resched() type of behaviour
but after good feedback I've determined using something like
cond_resched() but on IRQ context is required for preempting
Xen hypercalls. This introduces and uses the new cond_resched_irq().

[0] https://lkml.org/lkml/2014/11/26/630

Luis R. Rodriguez (2):
  sched: add cond_resched_irq()
  x86/xen: allow privcmd hypercalls to be preempted

 arch/x86/kernel/entry_32.S | 21 +++++++++++++++++++++
 arch/x86/kernel/entry_64.S | 17 +++++++++++++++++
 drivers/xen/Makefile       |  2 +-
 drivers/xen/preempt.c      | 17 +++++++++++++++++
 drivers/xen/privcmd.c      |  2 ++
 include/linux/sched.h      |  7 +++++++
 include/xen/xen-ops.h      | 26 ++++++++++++++++++++++++++
 kernel/sched/core.c        | 10 ++++++++++
 8 files changed, 101 insertions(+), 1 deletion(-)
 create mode 100644 drivers/xen/preempt.c

-- 
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 Dec 10 23:35:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 23:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyqmh-0005yJ-DR; Wed, 10 Dec 2014 23:35:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1Xyqmg-0005y1-1L
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 23:35:06 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	51/A5-20609-9A8D8845; Wed, 10 Dec 2014 23:35:05 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418254503!14279453!1
X-Originating-IP: [209.85.220.49]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30251 invoked from network); 10 Dec 2014 23:35:04 -0000
Received: from mail-pa0-f49.google.com (HELO mail-pa0-f49.google.com)
	(209.85.220.49)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 23:35:04 -0000
Received: by mail-pa0-f49.google.com with SMTP id eu11so3727585pac.8
	for <xen-devel@lists.xenproject.org>;
	Wed, 10 Dec 2014 15:35:02 -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:in-reply-to:references;
	bh=OhKHQMkb9UWYFquAWik8VTG2+UL8g85xSWWtT+1mL4c=;
	b=qIg8s2u3dRSTRNxvtK6DtzEa4YYvSn9ZIuRyLSx1j67irOzBLjKMXep+tQLibjpyOb
	BnFrF181hQqfXCyD7cmLIovfBH0yB5tJuMMcftRF7iltk83nH9/gBs3d9C1hl6CrGwTd
	PNk9Y63djzRISxSuDUNDiPgdt0+jwmhuX7GtQS8tRLZSniGz8ygYrBSUZuYyCOSvOecE
	rdzMHzuuYFLvW5F97d35WWxdqtio0ErZVD9SyyXb9sovEfcqGeTagx/sQpQAShBnTvTd
	49O0pjmtQN3Qqkxbc4bryDkl+F2gUIzykuVRNSFON6GkHHmH0Oa7/wsfQZxsgR+axyAT
	ObSQ==
X-Received: by 10.66.155.225 with SMTP id vz1mr11102190pab.133.1418254502673; 
	Wed, 10 Dec 2014 15:35:02 -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 fa9sm5244413pab.36.2014.12.10.15.34.58
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 10 Dec 2014 15:35:01 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Wed, 10 Dec 2014 15:34:57 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: mingo@redhat.com,
	peterz@infradead.org
Date: Wed, 10 Dec 2014 15:34:46 -0800
Message-Id: <1418254487-9988-2-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
Cc: jgross@suse.com, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, david.vrabel@citrix.com, JBeulich@suse.com,
	hpa@zytor.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v2 1/2] sched: add cond_resched_irq()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

Under special circumstances we may want to force
voluntary preemption even for CONFIG_PREEMPT=n
with interrupts disabled. This adds helpers to
let us do that.

Cc: Borislav Petkov <bp@suse.de>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 include/linux/sched.h |  7 +++++++
 kernel/sched/core.c   | 10 ++++++++++
 2 files changed, 17 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5e344bb..92da927 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2759,6 +2759,13 @@ static inline int signal_pending_state(long state, struct task_struct *p)
  */
 extern int _cond_resched(void);
 
+/*
+ * Voluntarily preempting the kernel even for CONFIG_PREEMPT=n kernels
+ * on very special circumstances. This is to be used with interrupts
+ * disabled.
+ */
+extern int cond_resched_irq(void);
+
 #define cond_resched() ({			\
 	__might_sleep(__FILE__, __LINE__, 0);	\
 	_cond_resched();			\
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 89e7283..573edb1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4239,6 +4239,16 @@ int __sched _cond_resched(void)
 }
 EXPORT_SYMBOL(_cond_resched);
 
+int __sched cond_resched_irq(void)
+{
+	if (should_resched()) {
+		preempt_schedule_irq();
+		return 1;
+	}
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cond_resched_irq);
+
 /*
  * __cond_resched_lock() - if a reschedule is pending, drop the given lock,
  * call schedule, and on return reacquire the lock.
-- 
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 Dec 10 23:35:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 23:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyqmm-0005zX-QR; Wed, 10 Dec 2014 23:35:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1Xyqml-0005zC-DM
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 23:35:11 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	21/42-03148-EA8D8845; Wed, 10 Dec 2014 23:35:10 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418254507!14310509!1
X-Originating-IP: [209.85.192.175]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18191 invoked from network); 10 Dec 2014 23:35:09 -0000
Received: from mail-pd0-f175.google.com (HELO mail-pd0-f175.google.com)
	(209.85.192.175)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 23:35:09 -0000
Received: by mail-pd0-f175.google.com with SMTP id g10so1759757pdj.34
	for <xen-devel@lists.xenproject.org>;
	Wed, 10 Dec 2014 15:35:07 -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:in-reply-to:references;
	bh=hv8ZeuvMuDx3WzI8UZCDobz6g7YO2C87Lr6uLU9ZRUg=;
	b=C6etEkDXDhDNIEDeQBdtFkJste00ho5fL/EPK+Woz/iBLGMzL1vy/xN3JIZZKDmIg3
	hpVdUoNsrdVrd0y0CKQP+8DKcXiY1KYEGN+qW2PQWAZ9YGxNEgja3WsVYcV+2DIaPIC/
	mE5YOgs4DiFlvckqxTwqMsnexPCcCAfsgVTF6EmGN5wuEe0uc08BuFJUmc3RLFgWotzK
	OQ7aFJRioDkvDG+j2+LUU9dpIlY6bZmpbsOmaFqDKkvkK5CbcN2tx43CEiiU5o71wspo
	fe/W+tiJSIT8VmYGCybRiorGhvOmmT5mvF6aGYVG0Xw0Gth5UUBEYridmoyi7fBCksol
	ZD8Q==
X-Received: by 10.70.90.80 with SMTP id bu16mr11944185pdb.44.1418254507535;
	Wed, 10 Dec 2014 15:35:07 -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 hj2sm5142052pbc.69.2014.12.10.15.35.03
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 10 Dec 2014 15:35:06 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Wed, 10 Dec 2014 15:35:02 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: mingo@redhat.com,
	peterz@infradead.org
Date: Wed, 10 Dec 2014 15:34:47 -0800
Message-Id: <1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
Cc: jgross@suse.com, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, david.vrabel@citrix.com, JBeulich@suse.com,
	hpa@zytor.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to be
	preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

Xen has support for splitting heavy work work into a series
of hypercalls, called multicalls, and preempting them through
what Xen calls continuation [0]. Despite this though without
CONFIG_PREEMPT preemption won't happen and while enabling
CONFIG_RT_GROUP_SCHED can at times help its not enough to
make a system usable. Such is the case for example when
creating a > 50 GiB HVM guest, we can get softlockups [1] with:.

kernel: [  802.084335] BUG: soft lockup - CPU#1 stuck for 22s! [xend:31351]

The softlock up triggers on the TASK_UNINTERRUPTIBLE hanger check
(default 120 seconds), on the Xen side in this particular case
this happens when the following Xen hypervisor code is used:

xc_domain_set_pod_target() -->
  do_memory_op() -->
    arch_memory_op() -->
      p2m_pod_set_mem_target()
	-- long delay (real or emulated) --

This happens on arch_memory_op() on the XENMEM_set_pod_target memory
op even though arch_memory_op() can handle continuation via
hypercall_create_continuation() for example.

Machines over 50 GiB of memory are on high demand and hard to come
by so to help replicate this sort of issue long delays on select
hypercalls have been emulated in order to be able to test this on
smaller machines [2].

On one hand this issue can be considered as expected given that
CONFIG_PREEMPT=n is used however we have forced voluntary preemption
precedent practices in the kernel even for CONFIG_PREEMPT=n through
the usage of cond_resched() sprinkled in many places. To address
this issue with Xen hypercalls though we need to find a way to aid
to the schedular in the middle of hypercalls. We are motivated to
address this issue on CONFIG_PREEMPT=n as otherwise the system becomes
rather unresponsive for long periods of time; in the worst case, at least
only currently by emulating long delays on select io disk bound
hypercalls, this can lead to filesystem corruption if the delay happens
for example on SCHEDOP_remote_shutdown (when we call 'xl <domain> shutdown').

We can address this problem by trying to check if we should schedule
on the xen timer in the middle of a hypercall on the return from the
timer interrupt. We want to be careful to not always force voluntary
preemption though so to do this we only selectively enable preemption
on very specific xen hypercalls.

This enables hypercall preemption by selectively forcing checks for
voluntary preempting only on ioctl initiated private hypercalls
where we know some folks have run into reported issues [1].

[0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
[1] https://bugzilla.novell.com/show_bug.cgi?id=861093
[2] http://ftp.suse.com/pub/people/mcgrof/xen/emulate-long-xen-hypercalls.patch

Based on original work by: David Vrabel <david.vrabel@citrix.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 arch/x86/kernel/entry_32.S | 21 +++++++++++++++++++++
 arch/x86/kernel/entry_64.S | 17 +++++++++++++++++
 drivers/xen/Makefile       |  2 +-
 drivers/xen/preempt.c      | 17 +++++++++++++++++
 drivers/xen/privcmd.c      |  2 ++
 include/xen/xen-ops.h      | 26 ++++++++++++++++++++++++++
 6 files changed, 84 insertions(+), 1 deletion(-)
 create mode 100644 drivers/xen/preempt.c

diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 344b63f..40b5c0c 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
 ENTRY(xen_do_upcall)
 1:	mov %esp, %eax
 	call xen_evtchn_do_upcall
+#ifdef CONFIG_PREEMPT
 	jmp  ret_from_intr
+#else
+	GET_THREAD_INFO(%ebp)
+#ifdef CONFIG_VM86
+	movl PT_EFLAGS(%esp), %eax	# mix EFLAGS and CS
+	movb PT_CS(%esp), %al
+	andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
+#else
+	movl PT_CS(%esp), %eax
+	andl $SEGMENT_RPL_MASK, %eax
+#endif
+	cmpl $USER_RPL, %eax
+	jae resume_userspace		# returning to v8086 or userspace
+	DISABLE_INTERRUPTS(CLBR_ANY)
+	cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
+	jz resume_kernel
+	movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
+	call cond_resched_irq
+	movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
+	jmp resume_kernel
+#endif /* CONFIG_PREEMPT */
 	CFI_ENDPROC
 ENDPROC(xen_hypervisor_callback)
 
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index c0226ab..0ccdd06 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
 	popq %rsp
 	CFI_DEF_CFA_REGISTER rsp
 	decl PER_CPU_VAR(irq_count)
+#ifdef CONFIG_PREEMPT
 	jmp  error_exit
+#else
+	movl %ebx, %eax
+	RESTORE_REST
+	DISABLE_INTERRUPTS(CLBR_NONE)
+	TRACE_IRQS_OFF
+	GET_THREAD_INFO(%rcx)
+	testl %eax, %eax
+	je error_exit_user
+	cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
+	jz retint_kernel
+	movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
+	call cond_resched_irq
+	movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
+	jmp retint_kernel
+#endif /* CONFIG_PREEMPT */
 	CFI_ENDPROC
 END(xen_do_hypervisor_callback)
 
@@ -1398,6 +1414,7 @@ ENTRY(error_exit)
 	GET_THREAD_INFO(%rcx)
 	testl %eax,%eax
 	jne retint_kernel
+error_exit_user:
 	LOCKDEP_SYS_EXIT_IRQ
 	movl TI_flags(%rcx),%edx
 	movl $_TIF_WORK_MASK,%edi
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 2140398..2ccd359 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,7 +2,7 @@ ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
 obj-$(CONFIG_X86)			+= fallback.o
-obj-y	+= grant-table.o features.o balloon.o manage.o
+obj-y	+= grant-table.o features.o balloon.o manage.o preempt.o
 obj-y	+= events/
 obj-y	+= xenbus/
 
diff --git a/drivers/xen/preempt.c b/drivers/xen/preempt.c
new file mode 100644
index 0000000..b5a3e98
--- /dev/null
+++ b/drivers/xen/preempt.c
@@ -0,0 +1,17 @@
+/*
+ * Preemptible hypercalls
+ *
+ * Copyright (C) 2014 Citrix Systems R&D ltd.
+ *
+ * This source code is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ */
+
+#include <xen/xen-ops.h>
+
+#ifndef CONFIG_PREEMPT
+DEFINE_PER_CPU(bool, xen_in_preemptible_hcall);
+EXPORT_SYMBOL_GPL(xen_in_preemptible_hcall);
+#endif
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 569a13b..59ac71c 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -56,10 +56,12 @@ static long privcmd_ioctl_hypercall(void __user *udata)
 	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
 		return -EFAULT;
 
+	xen_preemptible_hcall_begin();
 	ret = privcmd_call(hypercall.op,
 			   hypercall.arg[0], hypercall.arg[1],
 			   hypercall.arg[2], hypercall.arg[3],
 			   hypercall.arg[4]);
+	xen_preemptible_hcall_end();
 
 	return ret;
 }
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 7491ee5..8333821 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -46,4 +46,30 @@ static inline efi_system_table_t __init *xen_efi_probe(void)
 }
 #endif
 
+#ifdef CONFIG_PREEMPT
+
+static inline void xen_preemptible_hcall_begin(void)
+{
+}
+
+static inline void xen_preemptible_hcall_end(void)
+{
+}
+
+#else
+
+DECLARE_PER_CPU(bool, xen_in_preemptible_hcall);
+
+static inline void xen_preemptible_hcall_begin(void)
+{
+	__this_cpu_write(xen_in_preemptible_hcall, true);
+}
+
+static inline void xen_preemptible_hcall_end(void)
+{
+	__this_cpu_write(xen_in_preemptible_hcall, false);
+}
+
+#endif /* CONFIG_PREEMPT */
+
 #endif /* INCLUDE_XEN_OPS_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 Dec 10 23:35:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 23:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyqmm-0005zX-QR; Wed, 10 Dec 2014 23:35:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1Xyqml-0005zC-DM
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 23:35:11 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	21/42-03148-EA8D8845; Wed, 10 Dec 2014 23:35:10 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418254507!14310509!1
X-Originating-IP: [209.85.192.175]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18191 invoked from network); 10 Dec 2014 23:35:09 -0000
Received: from mail-pd0-f175.google.com (HELO mail-pd0-f175.google.com)
	(209.85.192.175)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 23:35:09 -0000
Received: by mail-pd0-f175.google.com with SMTP id g10so1759757pdj.34
	for <xen-devel@lists.xenproject.org>;
	Wed, 10 Dec 2014 15:35:07 -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:in-reply-to:references;
	bh=hv8ZeuvMuDx3WzI8UZCDobz6g7YO2C87Lr6uLU9ZRUg=;
	b=C6etEkDXDhDNIEDeQBdtFkJste00ho5fL/EPK+Woz/iBLGMzL1vy/xN3JIZZKDmIg3
	hpVdUoNsrdVrd0y0CKQP+8DKcXiY1KYEGN+qW2PQWAZ9YGxNEgja3WsVYcV+2DIaPIC/
	mE5YOgs4DiFlvckqxTwqMsnexPCcCAfsgVTF6EmGN5wuEe0uc08BuFJUmc3RLFgWotzK
	OQ7aFJRioDkvDG+j2+LUU9dpIlY6bZmpbsOmaFqDKkvkK5CbcN2tx43CEiiU5o71wspo
	fe/W+tiJSIT8VmYGCybRiorGhvOmmT5mvF6aGYVG0Xw0Gth5UUBEYridmoyi7fBCksol
	ZD8Q==
X-Received: by 10.70.90.80 with SMTP id bu16mr11944185pdb.44.1418254507535;
	Wed, 10 Dec 2014 15:35:07 -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 hj2sm5142052pbc.69.2014.12.10.15.35.03
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 10 Dec 2014 15:35:06 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Wed, 10 Dec 2014 15:35:02 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: mingo@redhat.com,
	peterz@infradead.org
Date: Wed, 10 Dec 2014 15:34:47 -0800
Message-Id: <1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
Cc: jgross@suse.com, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, david.vrabel@citrix.com, JBeulich@suse.com,
	hpa@zytor.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to be
	preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

Xen has support for splitting heavy work work into a series
of hypercalls, called multicalls, and preempting them through
what Xen calls continuation [0]. Despite this though without
CONFIG_PREEMPT preemption won't happen and while enabling
CONFIG_RT_GROUP_SCHED can at times help its not enough to
make a system usable. Such is the case for example when
creating a > 50 GiB HVM guest, we can get softlockups [1] with:.

kernel: [  802.084335] BUG: soft lockup - CPU#1 stuck for 22s! [xend:31351]

The softlock up triggers on the TASK_UNINTERRUPTIBLE hanger check
(default 120 seconds), on the Xen side in this particular case
this happens when the following Xen hypervisor code is used:

xc_domain_set_pod_target() -->
  do_memory_op() -->
    arch_memory_op() -->
      p2m_pod_set_mem_target()
	-- long delay (real or emulated) --

This happens on arch_memory_op() on the XENMEM_set_pod_target memory
op even though arch_memory_op() can handle continuation via
hypercall_create_continuation() for example.

Machines over 50 GiB of memory are on high demand and hard to come
by so to help replicate this sort of issue long delays on select
hypercalls have been emulated in order to be able to test this on
smaller machines [2].

On one hand this issue can be considered as expected given that
CONFIG_PREEMPT=n is used however we have forced voluntary preemption
precedent practices in the kernel even for CONFIG_PREEMPT=n through
the usage of cond_resched() sprinkled in many places. To address
this issue with Xen hypercalls though we need to find a way to aid
to the schedular in the middle of hypercalls. We are motivated to
address this issue on CONFIG_PREEMPT=n as otherwise the system becomes
rather unresponsive for long periods of time; in the worst case, at least
only currently by emulating long delays on select io disk bound
hypercalls, this can lead to filesystem corruption if the delay happens
for example on SCHEDOP_remote_shutdown (when we call 'xl <domain> shutdown').

We can address this problem by trying to check if we should schedule
on the xen timer in the middle of a hypercall on the return from the
timer interrupt. We want to be careful to not always force voluntary
preemption though so to do this we only selectively enable preemption
on very specific xen hypercalls.

This enables hypercall preemption by selectively forcing checks for
voluntary preempting only on ioctl initiated private hypercalls
where we know some folks have run into reported issues [1].

[0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
[1] https://bugzilla.novell.com/show_bug.cgi?id=861093
[2] http://ftp.suse.com/pub/people/mcgrof/xen/emulate-long-xen-hypercalls.patch

Based on original work by: David Vrabel <david.vrabel@citrix.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 arch/x86/kernel/entry_32.S | 21 +++++++++++++++++++++
 arch/x86/kernel/entry_64.S | 17 +++++++++++++++++
 drivers/xen/Makefile       |  2 +-
 drivers/xen/preempt.c      | 17 +++++++++++++++++
 drivers/xen/privcmd.c      |  2 ++
 include/xen/xen-ops.h      | 26 ++++++++++++++++++++++++++
 6 files changed, 84 insertions(+), 1 deletion(-)
 create mode 100644 drivers/xen/preempt.c

diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 344b63f..40b5c0c 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
 ENTRY(xen_do_upcall)
 1:	mov %esp, %eax
 	call xen_evtchn_do_upcall
+#ifdef CONFIG_PREEMPT
 	jmp  ret_from_intr
+#else
+	GET_THREAD_INFO(%ebp)
+#ifdef CONFIG_VM86
+	movl PT_EFLAGS(%esp), %eax	# mix EFLAGS and CS
+	movb PT_CS(%esp), %al
+	andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
+#else
+	movl PT_CS(%esp), %eax
+	andl $SEGMENT_RPL_MASK, %eax
+#endif
+	cmpl $USER_RPL, %eax
+	jae resume_userspace		# returning to v8086 or userspace
+	DISABLE_INTERRUPTS(CLBR_ANY)
+	cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
+	jz resume_kernel
+	movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
+	call cond_resched_irq
+	movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
+	jmp resume_kernel
+#endif /* CONFIG_PREEMPT */
 	CFI_ENDPROC
 ENDPROC(xen_hypervisor_callback)
 
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index c0226ab..0ccdd06 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
 	popq %rsp
 	CFI_DEF_CFA_REGISTER rsp
 	decl PER_CPU_VAR(irq_count)
+#ifdef CONFIG_PREEMPT
 	jmp  error_exit
+#else
+	movl %ebx, %eax
+	RESTORE_REST
+	DISABLE_INTERRUPTS(CLBR_NONE)
+	TRACE_IRQS_OFF
+	GET_THREAD_INFO(%rcx)
+	testl %eax, %eax
+	je error_exit_user
+	cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
+	jz retint_kernel
+	movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
+	call cond_resched_irq
+	movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
+	jmp retint_kernel
+#endif /* CONFIG_PREEMPT */
 	CFI_ENDPROC
 END(xen_do_hypervisor_callback)
 
@@ -1398,6 +1414,7 @@ ENTRY(error_exit)
 	GET_THREAD_INFO(%rcx)
 	testl %eax,%eax
 	jne retint_kernel
+error_exit_user:
 	LOCKDEP_SYS_EXIT_IRQ
 	movl TI_flags(%rcx),%edx
 	movl $_TIF_WORK_MASK,%edi
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 2140398..2ccd359 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,7 +2,7 @@ ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
 obj-$(CONFIG_X86)			+= fallback.o
-obj-y	+= grant-table.o features.o balloon.o manage.o
+obj-y	+= grant-table.o features.o balloon.o manage.o preempt.o
 obj-y	+= events/
 obj-y	+= xenbus/
 
diff --git a/drivers/xen/preempt.c b/drivers/xen/preempt.c
new file mode 100644
index 0000000..b5a3e98
--- /dev/null
+++ b/drivers/xen/preempt.c
@@ -0,0 +1,17 @@
+/*
+ * Preemptible hypercalls
+ *
+ * Copyright (C) 2014 Citrix Systems R&D ltd.
+ *
+ * This source code is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ */
+
+#include <xen/xen-ops.h>
+
+#ifndef CONFIG_PREEMPT
+DEFINE_PER_CPU(bool, xen_in_preemptible_hcall);
+EXPORT_SYMBOL_GPL(xen_in_preemptible_hcall);
+#endif
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 569a13b..59ac71c 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -56,10 +56,12 @@ static long privcmd_ioctl_hypercall(void __user *udata)
 	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
 		return -EFAULT;
 
+	xen_preemptible_hcall_begin();
 	ret = privcmd_call(hypercall.op,
 			   hypercall.arg[0], hypercall.arg[1],
 			   hypercall.arg[2], hypercall.arg[3],
 			   hypercall.arg[4]);
+	xen_preemptible_hcall_end();
 
 	return ret;
 }
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 7491ee5..8333821 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -46,4 +46,30 @@ static inline efi_system_table_t __init *xen_efi_probe(void)
 }
 #endif
 
+#ifdef CONFIG_PREEMPT
+
+static inline void xen_preemptible_hcall_begin(void)
+{
+}
+
+static inline void xen_preemptible_hcall_end(void)
+{
+}
+
+#else
+
+DECLARE_PER_CPU(bool, xen_in_preemptible_hcall);
+
+static inline void xen_preemptible_hcall_begin(void)
+{
+	__this_cpu_write(xen_in_preemptible_hcall, true);
+}
+
+static inline void xen_preemptible_hcall_end(void)
+{
+	__this_cpu_write(xen_in_preemptible_hcall, false);
+}
+
+#endif /* CONFIG_PREEMPT */
+
 #endif /* INCLUDE_XEN_OPS_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 Dec 10 23:35:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 23:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyqmh-0005yJ-DR; Wed, 10 Dec 2014 23:35:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1Xyqmg-0005y1-1L
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 23:35:06 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	51/A5-20609-9A8D8845; Wed, 10 Dec 2014 23:35:05 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418254503!14279453!1
X-Originating-IP: [209.85.220.49]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30251 invoked from network); 10 Dec 2014 23:35:04 -0000
Received: from mail-pa0-f49.google.com (HELO mail-pa0-f49.google.com)
	(209.85.220.49)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 23:35:04 -0000
Received: by mail-pa0-f49.google.com with SMTP id eu11so3727585pac.8
	for <xen-devel@lists.xenproject.org>;
	Wed, 10 Dec 2014 15:35:02 -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:in-reply-to:references;
	bh=OhKHQMkb9UWYFquAWik8VTG2+UL8g85xSWWtT+1mL4c=;
	b=qIg8s2u3dRSTRNxvtK6DtzEa4YYvSn9ZIuRyLSx1j67irOzBLjKMXep+tQLibjpyOb
	BnFrF181hQqfXCyD7cmLIovfBH0yB5tJuMMcftRF7iltk83nH9/gBs3d9C1hl6CrGwTd
	PNk9Y63djzRISxSuDUNDiPgdt0+jwmhuX7GtQS8tRLZSniGz8ygYrBSUZuYyCOSvOecE
	rdzMHzuuYFLvW5F97d35WWxdqtio0ErZVD9SyyXb9sovEfcqGeTagx/sQpQAShBnTvTd
	49O0pjmtQN3Qqkxbc4bryDkl+F2gUIzykuVRNSFON6GkHHmH0Oa7/wsfQZxsgR+axyAT
	ObSQ==
X-Received: by 10.66.155.225 with SMTP id vz1mr11102190pab.133.1418254502673; 
	Wed, 10 Dec 2014 15:35:02 -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 fa9sm5244413pab.36.2014.12.10.15.34.58
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 10 Dec 2014 15:35:01 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Wed, 10 Dec 2014 15:34:57 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: mingo@redhat.com,
	peterz@infradead.org
Date: Wed, 10 Dec 2014 15:34:46 -0800
Message-Id: <1418254487-9988-2-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
Cc: jgross@suse.com, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, david.vrabel@citrix.com, JBeulich@suse.com,
	hpa@zytor.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v2 1/2] sched: add cond_resched_irq()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

Under special circumstances we may want to force
voluntary preemption even for CONFIG_PREEMPT=n
with interrupts disabled. This adds helpers to
let us do that.

Cc: Borislav Petkov <bp@suse.de>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 include/linux/sched.h |  7 +++++++
 kernel/sched/core.c   | 10 ++++++++++
 2 files changed, 17 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5e344bb..92da927 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2759,6 +2759,13 @@ static inline int signal_pending_state(long state, struct task_struct *p)
  */
 extern int _cond_resched(void);
 
+/*
+ * Voluntarily preempting the kernel even for CONFIG_PREEMPT=n kernels
+ * on very special circumstances. This is to be used with interrupts
+ * disabled.
+ */
+extern int cond_resched_irq(void);
+
 #define cond_resched() ({			\
 	__might_sleep(__FILE__, __LINE__, 0);	\
 	_cond_resched();			\
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 89e7283..573edb1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4239,6 +4239,16 @@ int __sched _cond_resched(void)
 }
 EXPORT_SYMBOL(_cond_resched);
 
+int __sched cond_resched_irq(void)
+{
+	if (should_resched()) {
+		preempt_schedule_irq();
+		return 1;
+	}
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cond_resched_irq);
+
 /*
  * __cond_resched_lock() - if a reschedule is pending, drop the given lock,
  * call schedule, and on return reacquire the lock.
-- 
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 Dec 10 23:35:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 23:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyqmc-0005xk-1F; Wed, 10 Dec 2014 23:35:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mcgrof@gmail.com>) id 1Xyqma-0005xf-Nf
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 23:35:00 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	1C/77-02699-4A8D8845; Wed, 10 Dec 2014 23:35:00 +0000
X-Env-Sender: mcgrof@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418254497!8868589!1
X-Originating-IP: [209.85.192.171]
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 31822 invoked from network); 10 Dec 2014 23:34:59 -0000
Received: from mail-pd0-f171.google.com (HELO mail-pd0-f171.google.com)
	(209.85.192.171)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 23:34:59 -0000
Received: by mail-pd0-f171.google.com with SMTP id y13so3735719pdi.16
	for <xen-devel@lists.xenproject.org>;
	Wed, 10 Dec 2014 15:34:57 -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=cVv/kWS8Xfc7ZubKVI8uWX1hB6+DqQP56K0uBiR+Ldg=;
	b=d/BoPZqsfIn1IC6BZAuhfABC/0CtUUd/CVQjNDoZlFCUMkgiWoS+iUhJvLiBBLf8cf
	kGwDg9E6CA3Y96TrFL2hFWdsF8h3IMiCEPUCMZ6KgoB/UCHHzmB8a+NS25JXu3PmMLRC
	sjMrZTRC6TJWEqcYfAKB7P9J7Tz9ROutd8aBC8semgNxI32/g1DnYS3EhWQVtTGs4l7C
	9qjc6d9bz645hU0zlmEwEkKDnQyDUvUrYhNSycJre6GCkkgbvz2GGEezhvAsUQY5F9wv
	d+Zov5LTodDn0f9fMi1plKgiaaPNc3/fwUfKDCo8H9KHq3ZIU0+IpLDAIWNIEtf4UP2B
	Wb6Q==
X-Received: by 10.66.176.202 with SMTP id ck10mr11807292pac.18.1418254497575; 
	Wed, 10 Dec 2014 15:34:57 -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 fb7sm5263757pab.10.2014.12.10.15.34.53
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 10 Dec 2014 15:34:55 -0800 (PST)
Received: by mcgrof@gmail.com (sSMTP sendmail emulation);
	Wed, 10 Dec 2014 15:34:52 -0800
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: mingo@redhat.com,
	peterz@infradead.org
Date: Wed, 10 Dec 2014 15:34:45 -0800
Message-Id: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
X-Mailer: git-send-email 2.1.0
Cc: jgross@suse.com, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, david.vrabel@citrix.com, JBeulich@suse.com,
	hpa@zytor.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de, bpoirier@suse.de
Subject: [Xen-devel] [PATCH v2 0/2] x86: add xen hypercall preemption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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>

This is my second series which addresses hypercall preemption
on Xen. On the first iteration of this series [0] I tried as
much as possible to avoid cond_resched() type of behaviour
but after good feedback I've determined using something like
cond_resched() but on IRQ context is required for preempting
Xen hypercalls. This introduces and uses the new cond_resched_irq().

[0] https://lkml.org/lkml/2014/11/26/630

Luis R. Rodriguez (2):
  sched: add cond_resched_irq()
  x86/xen: allow privcmd hypercalls to be preempted

 arch/x86/kernel/entry_32.S | 21 +++++++++++++++++++++
 arch/x86/kernel/entry_64.S | 17 +++++++++++++++++
 drivers/xen/Makefile       |  2 +-
 drivers/xen/preempt.c      | 17 +++++++++++++++++
 drivers/xen/privcmd.c      |  2 ++
 include/linux/sched.h      |  7 +++++++
 include/xen/xen-ops.h      | 26 ++++++++++++++++++++++++++
 kernel/sched/core.c        | 10 ++++++++++
 8 files changed, 101 insertions(+), 1 deletion(-)
 create mode 100644 drivers/xen/preempt.c

-- 
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 Dec 10 23:52:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 23:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyr3E-0006hu-Er; Wed, 10 Dec 2014 23:52:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1Xyr3C-0006hp-Uh
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 23:52:11 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	D4/E5-16982-AACD8845; Wed, 10 Dec 2014 23:52:10 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418255528!12483052!1
X-Originating-IP: [209.85.217.178]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17720 invoked from network); 10 Dec 2014 23:52:09 -0000
Received: from mail-lb0-f178.google.com (HELO mail-lb0-f178.google.com)
	(209.85.217.178)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 23:52:09 -0000
Received: by mail-lb0-f178.google.com with SMTP id f15so3508675lbj.23
	for <xen-devel@lists.xenproject.org>;
	Wed, 10 Dec 2014 15:52: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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=rqLlU+FuiC6mDlTKZ4b3m7ax/Uwpn0pJNwOofZkMEWM=;
	b=DwJZYDk6alaU4bR57eWLRNnb2mE0K8Fk/keIx23PSZKSl9XjiBRawh0Xis4Ooa+cTQ
	SYNEW80K3H24JZZmyqTNR0x3RxP3kZ6HFMQ3mWmuYMa48RxKqnQAE/1vlP7Lbz0OOO7n
	NiSd1iEUkIWQSYpIpWKb4VcYqvx6PldUzxNeQDHBUOuMzsKVyGZUduLde11ielu+dTRS
	D0CDf6PkMqp54JjLYezImThGHPLJl9deWurBninE3eyQi7UgYgX4lpRV+M9Nof98cEgo
	DUjwOWZ+lrNWkAF8+o8te4SwUpEpk8fiz3rbdJ2WgYAnALDJWJ8QSUSN07ceRXyu/TQZ
	GAow==
X-Gm-Message-State: ALoCoQnMSK6NTw24Xmvhkfk4qVl0FzVlvcawsKgXnN9CFDLBl8i9s8NzrYkLyEEscj9L1EkB3q9k
X-Received: by 10.112.147.199 with SMTP id tm7mr6797885lbb.92.1418255528587;
	Wed, 10 Dec 2014 15:52:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.7.132 with HTTP; Wed, 10 Dec 2014 15:51:48 -0800 (PST)
In-Reply-To: <1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Wed, 10 Dec 2014 15:51:48 -0800
Message-ID: <CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: Juergen Gross <jgross@suse.com>, Peter Zijlstra <peterz@infradead.org>,
	"Luis R. Rodriguez" <mcgrof@suse.com>, X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 3:34 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Xen has support for splitting heavy work work into a series
> of hypercalls, called multicalls, and preempting them through
> what Xen calls continuation [0]. Despite this though without
> CONFIG_PREEMPT preemption won't happen and while enabling
> CONFIG_RT_GROUP_SCHED can at times help its not enough to
> make a system usable. Such is the case for example when
> creating a > 50 GiB HVM guest, we can get softlockups [1] with:.
>
> kernel: [  802.084335] BUG: soft lockup - CPU#1 stuck for 22s! [xend:31351]
>
> The softlock up triggers on the TASK_UNINTERRUPTIBLE hanger check
> (default 120 seconds), on the Xen side in this particular case
> this happens when the following Xen hypervisor code is used:
>
> xc_domain_set_pod_target() -->
>   do_memory_op() -->
>     arch_memory_op() -->
>       p2m_pod_set_mem_target()
>         -- long delay (real or emulated) --
>
> This happens on arch_memory_op() on the XENMEM_set_pod_target memory
> op even though arch_memory_op() can handle continuation via
> hypercall_create_continuation() for example.
>
> Machines over 50 GiB of memory are on high demand and hard to come
> by so to help replicate this sort of issue long delays on select
> hypercalls have been emulated in order to be able to test this on
> smaller machines [2].
>
> On one hand this issue can be considered as expected given that
> CONFIG_PREEMPT=n is used however we have forced voluntary preemption
> precedent practices in the kernel even for CONFIG_PREEMPT=n through
> the usage of cond_resched() sprinkled in many places. To address
> this issue with Xen hypercalls though we need to find a way to aid
> to the schedular in the middle of hypercalls. We are motivated to
> address this issue on CONFIG_PREEMPT=n as otherwise the system becomes
> rather unresponsive for long periods of time; in the worst case, at least
> only currently by emulating long delays on select io disk bound
> hypercalls, this can lead to filesystem corruption if the delay happens
> for example on SCHEDOP_remote_shutdown (when we call 'xl <domain> shutdown').
>
> We can address this problem by trying to check if we should schedule
> on the xen timer in the middle of a hypercall on the return from the
> timer interrupt. We want to be careful to not always force voluntary
> preemption though so to do this we only selectively enable preemption
> on very specific xen hypercalls.
>
> This enables hypercall preemption by selectively forcing checks for
> voluntary preempting only on ioctl initiated private hypercalls
> where we know some folks have run into reported issues [1].
>
> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
> [1] https://bugzilla.novell.com/show_bug.cgi?id=861093
> [2] http://ftp.suse.com/pub/people/mcgrof/xen/emulate-long-xen-hypercalls.patch
>
> Based on original work by: David Vrabel <david.vrabel@citrix.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>  arch/x86/kernel/entry_32.S | 21 +++++++++++++++++++++
>  arch/x86/kernel/entry_64.S | 17 +++++++++++++++++
>  drivers/xen/Makefile       |  2 +-
>  drivers/xen/preempt.c      | 17 +++++++++++++++++
>  drivers/xen/privcmd.c      |  2 ++
>  include/xen/xen-ops.h      | 26 ++++++++++++++++++++++++++
>  6 files changed, 84 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/xen/preempt.c
>
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 344b63f..40b5c0c 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
>  ENTRY(xen_do_upcall)
>  1:     mov %esp, %eax
>         call xen_evtchn_do_upcall
> +#ifdef CONFIG_PREEMPT
>         jmp  ret_from_intr
> +#else
> +       GET_THREAD_INFO(%ebp)
> +#ifdef CONFIG_VM86
> +       movl PT_EFLAGS(%esp), %eax      # mix EFLAGS and CS
> +       movb PT_CS(%esp), %al
> +       andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
> +#else
> +       movl PT_CS(%esp), %eax
> +       andl $SEGMENT_RPL_MASK, %eax
> +#endif
> +       cmpl $USER_RPL, %eax
> +       jae resume_userspace            # returning to v8086 or userspace
> +       DISABLE_INTERRUPTS(CLBR_ANY)
> +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +       jz resume_kernel
> +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +       call cond_resched_irq
> +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> +       jmp resume_kernel
> +#endif /* CONFIG_PREEMPT */
>         CFI_ENDPROC
>  ENDPROC(xen_hypervisor_callback)
>
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index c0226ab..0ccdd06 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
>         popq %rsp
>         CFI_DEF_CFA_REGISTER rsp
>         decl PER_CPU_VAR(irq_count)
> +#ifdef CONFIG_PREEMPT
>         jmp  error_exit
> +#else
> +       movl %ebx, %eax
> +       RESTORE_REST
> +       DISABLE_INTERRUPTS(CLBR_NONE)
> +       TRACE_IRQS_OFF
> +       GET_THREAD_INFO(%rcx)
> +       testl %eax, %eax
> +       je error_exit_user
> +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +       jz retint_kernel

I think I understand this part.

> +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)

Why?  Is the issue that, if preemptible hypercalls nest, you don't
want to preempt again?

> +       call cond_resched_irq

On !CONFIG_PREEMPT, there's no preempt_disable, right?  So how do you
guarantee that you don't preempt something you shouldn't?  Is the idea
that these events will only fire nested *directly* inside a
preemptible hypercall?  Also, should you check that IRQs were on when
the event fired?  (Are they on in pt_regs?)

> +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> +       jmp retint_kernel
> +#endif /* CONFIG_PREEMPT */
>         CFI_ENDPROC

All that being said, this is IMO a bit gross.  You've added a bunch of
asm that's kind of like a parallel error_exit, and the error entry and
exit code is hairy enough that this scares me.  Can you do this mostly
in C instead?  This would look a nicer if it could be:

    call xen_evtchn_do_upcall
    popq %rsp
    CFI_DEF_CFA_REGISTER rsp
    decl PER_CPU_VAR(irq_count)
+  call xen_end_upcall
    jmp error_exit

Where xen_end_upcall would be witten in C, nokprobes and notrace (if
needed) and would check pt_regs and whatever else and just call
schedule if needed?

--Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 10 23:52:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Dec 2014 23:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyr3E-0006hu-Er; Wed, 10 Dec 2014 23:52:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1Xyr3C-0006hp-Uh
	for xen-devel@lists.xenproject.org; Wed, 10 Dec 2014 23:52:11 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	D4/E5-16982-AACD8845; Wed, 10 Dec 2014 23:52:10 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418255528!12483052!1
X-Originating-IP: [209.85.217.178]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17720 invoked from network); 10 Dec 2014 23:52:09 -0000
Received: from mail-lb0-f178.google.com (HELO mail-lb0-f178.google.com)
	(209.85.217.178)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Dec 2014 23:52:09 -0000
Received: by mail-lb0-f178.google.com with SMTP id f15so3508675lbj.23
	for <xen-devel@lists.xenproject.org>;
	Wed, 10 Dec 2014 15:52: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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=rqLlU+FuiC6mDlTKZ4b3m7ax/Uwpn0pJNwOofZkMEWM=;
	b=DwJZYDk6alaU4bR57eWLRNnb2mE0K8Fk/keIx23PSZKSl9XjiBRawh0Xis4Ooa+cTQ
	SYNEW80K3H24JZZmyqTNR0x3RxP3kZ6HFMQ3mWmuYMa48RxKqnQAE/1vlP7Lbz0OOO7n
	NiSd1iEUkIWQSYpIpWKb4VcYqvx6PldUzxNeQDHBUOuMzsKVyGZUduLde11ielu+dTRS
	D0CDf6PkMqp54JjLYezImThGHPLJl9deWurBninE3eyQi7UgYgX4lpRV+M9Nof98cEgo
	DUjwOWZ+lrNWkAF8+o8te4SwUpEpk8fiz3rbdJ2WgYAnALDJWJ8QSUSN07ceRXyu/TQZ
	GAow==
X-Gm-Message-State: ALoCoQnMSK6NTw24Xmvhkfk4qVl0FzVlvcawsKgXnN9CFDLBl8i9s8NzrYkLyEEscj9L1EkB3q9k
X-Received: by 10.112.147.199 with SMTP id tm7mr6797885lbb.92.1418255528587;
	Wed, 10 Dec 2014 15:52:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.7.132 with HTTP; Wed, 10 Dec 2014 15:51:48 -0800 (PST)
In-Reply-To: <1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Wed, 10 Dec 2014 15:51:48 -0800
Message-ID: <CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: Juergen Gross <jgross@suse.com>, Peter Zijlstra <peterz@infradead.org>,
	"Luis R. Rodriguez" <mcgrof@suse.com>, X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 3:34 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Xen has support for splitting heavy work work into a series
> of hypercalls, called multicalls, and preempting them through
> what Xen calls continuation [0]. Despite this though without
> CONFIG_PREEMPT preemption won't happen and while enabling
> CONFIG_RT_GROUP_SCHED can at times help its not enough to
> make a system usable. Such is the case for example when
> creating a > 50 GiB HVM guest, we can get softlockups [1] with:.
>
> kernel: [  802.084335] BUG: soft lockup - CPU#1 stuck for 22s! [xend:31351]
>
> The softlock up triggers on the TASK_UNINTERRUPTIBLE hanger check
> (default 120 seconds), on the Xen side in this particular case
> this happens when the following Xen hypervisor code is used:
>
> xc_domain_set_pod_target() -->
>   do_memory_op() -->
>     arch_memory_op() -->
>       p2m_pod_set_mem_target()
>         -- long delay (real or emulated) --
>
> This happens on arch_memory_op() on the XENMEM_set_pod_target memory
> op even though arch_memory_op() can handle continuation via
> hypercall_create_continuation() for example.
>
> Machines over 50 GiB of memory are on high demand and hard to come
> by so to help replicate this sort of issue long delays on select
> hypercalls have been emulated in order to be able to test this on
> smaller machines [2].
>
> On one hand this issue can be considered as expected given that
> CONFIG_PREEMPT=n is used however we have forced voluntary preemption
> precedent practices in the kernel even for CONFIG_PREEMPT=n through
> the usage of cond_resched() sprinkled in many places. To address
> this issue with Xen hypercalls though we need to find a way to aid
> to the schedular in the middle of hypercalls. We are motivated to
> address this issue on CONFIG_PREEMPT=n as otherwise the system becomes
> rather unresponsive for long periods of time; in the worst case, at least
> only currently by emulating long delays on select io disk bound
> hypercalls, this can lead to filesystem corruption if the delay happens
> for example on SCHEDOP_remote_shutdown (when we call 'xl <domain> shutdown').
>
> We can address this problem by trying to check if we should schedule
> on the xen timer in the middle of a hypercall on the return from the
> timer interrupt. We want to be careful to not always force voluntary
> preemption though so to do this we only selectively enable preemption
> on very specific xen hypercalls.
>
> This enables hypercall preemption by selectively forcing checks for
> voluntary preempting only on ioctl initiated private hypercalls
> where we know some folks have run into reported issues [1].
>
> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
> [1] https://bugzilla.novell.com/show_bug.cgi?id=861093
> [2] http://ftp.suse.com/pub/people/mcgrof/xen/emulate-long-xen-hypercalls.patch
>
> Based on original work by: David Vrabel <david.vrabel@citrix.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>  arch/x86/kernel/entry_32.S | 21 +++++++++++++++++++++
>  arch/x86/kernel/entry_64.S | 17 +++++++++++++++++
>  drivers/xen/Makefile       |  2 +-
>  drivers/xen/preempt.c      | 17 +++++++++++++++++
>  drivers/xen/privcmd.c      |  2 ++
>  include/xen/xen-ops.h      | 26 ++++++++++++++++++++++++++
>  6 files changed, 84 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/xen/preempt.c
>
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 344b63f..40b5c0c 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
>  ENTRY(xen_do_upcall)
>  1:     mov %esp, %eax
>         call xen_evtchn_do_upcall
> +#ifdef CONFIG_PREEMPT
>         jmp  ret_from_intr
> +#else
> +       GET_THREAD_INFO(%ebp)
> +#ifdef CONFIG_VM86
> +       movl PT_EFLAGS(%esp), %eax      # mix EFLAGS and CS
> +       movb PT_CS(%esp), %al
> +       andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
> +#else
> +       movl PT_CS(%esp), %eax
> +       andl $SEGMENT_RPL_MASK, %eax
> +#endif
> +       cmpl $USER_RPL, %eax
> +       jae resume_userspace            # returning to v8086 or userspace
> +       DISABLE_INTERRUPTS(CLBR_ANY)
> +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +       jz resume_kernel
> +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +       call cond_resched_irq
> +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> +       jmp resume_kernel
> +#endif /* CONFIG_PREEMPT */
>         CFI_ENDPROC
>  ENDPROC(xen_hypervisor_callback)
>
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index c0226ab..0ccdd06 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
>         popq %rsp
>         CFI_DEF_CFA_REGISTER rsp
>         decl PER_CPU_VAR(irq_count)
> +#ifdef CONFIG_PREEMPT
>         jmp  error_exit
> +#else
> +       movl %ebx, %eax
> +       RESTORE_REST
> +       DISABLE_INTERRUPTS(CLBR_NONE)
> +       TRACE_IRQS_OFF
> +       GET_THREAD_INFO(%rcx)
> +       testl %eax, %eax
> +       je error_exit_user
> +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +       jz retint_kernel

I think I understand this part.

> +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)

Why?  Is the issue that, if preemptible hypercalls nest, you don't
want to preempt again?

> +       call cond_resched_irq

On !CONFIG_PREEMPT, there's no preempt_disable, right?  So how do you
guarantee that you don't preempt something you shouldn't?  Is the idea
that these events will only fire nested *directly* inside a
preemptible hypercall?  Also, should you check that IRQs were on when
the event fired?  (Are they on in pt_regs?)

> +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> +       jmp retint_kernel
> +#endif /* CONFIG_PREEMPT */
>         CFI_ENDPROC

All that being said, this is IMO a bit gross.  You've added a bunch of
asm that's kind of like a parallel error_exit, and the error entry and
exit code is hairy enough that this scares me.  Can you do this mostly
in C instead?  This would look a nicer if it could be:

    call xen_evtchn_do_upcall
    popq %rsp
    CFI_DEF_CFA_REGISTER rsp
    decl PER_CPU_VAR(irq_count)
+  call xen_end_upcall
    jmp error_exit

Where xen_end_upcall would be witten in C, nokprobes and notrace (if
needed) and would check pt_regs and whatever else and just call
schedule if needed?

--Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 00:20:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 00:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyrTl-0008Bs-W1; Thu, 11 Dec 2014 00:19: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 1XyrTk-0008Bn-No
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 00:19:36 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	80/B8-26740-713E8845; Thu, 11 Dec 2014 00:19:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418257173!12475507!1
X-Originating-IP: [66.165.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 27170 invoked from network); 11 Dec 2014 00:19:34 -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 Dec 2014 00:19:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="203128507"
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.210.2;
	Wed, 10 Dec 2014 19:19: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 1XyrTg-0004ag-1H;
	Thu, 11 Dec 2014 00:19:32 +0000
Date: Thu, 11 Dec 2014 00:19:32 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Bjoern Rennhak <bjoern@clothesnetwork.com>
Message-ID: <20141211001931.GA25476@zion.uk.xensource.com>
References: <20141210202525.GA20557@rennhak.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141210202525.GA20557@rennhak.de>
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] Question reg. named vif interface support in guest
 cfg; 
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 08:25:25PM +0000, Bjoern Rennhak wrote:
> Dear Xen Developers,
> 
> I found handling of vifx.y interfaces slightly unintutive and was
> wondering if it is possible to name the interface via the Xen guest
> config file?
> 
> e.g. a vif_name parameter or otherwise maybe vif interface is automatically named
> after set "name" entry in config instead of generic vifx.y.
> 
> So instead of a bunch of vifx.y's I would see <descriptivename>x.y ?
> 
> Is that already possible or a bad idea in general?

Check out

http://xenbits.xen.org/docs/4.4-testing/misc/xl-network-configuration.html

vifname

Wei.

> Should I open a wishlist entry on http://bugs.xenproject.org/xen/?
> 
> Thank you!
> 
> Cheers,
> -Bjoern
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 11 00:20:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 00:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyrTl-0008Bs-W1; Thu, 11 Dec 2014 00:19: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 1XyrTk-0008Bn-No
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 00:19:36 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	80/B8-26740-713E8845; Thu, 11 Dec 2014 00:19:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418257173!12475507!1
X-Originating-IP: [66.165.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 27170 invoked from network); 11 Dec 2014 00:19:34 -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 Dec 2014 00:19:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,554,1413244800"; d="scan'208";a="203128507"
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.210.2;
	Wed, 10 Dec 2014 19:19: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 1XyrTg-0004ag-1H;
	Thu, 11 Dec 2014 00:19:32 +0000
Date: Thu, 11 Dec 2014 00:19:32 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Bjoern Rennhak <bjoern@clothesnetwork.com>
Message-ID: <20141211001931.GA25476@zion.uk.xensource.com>
References: <20141210202525.GA20557@rennhak.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141210202525.GA20557@rennhak.de>
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] Question reg. named vif interface support in guest
 cfg; 
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 08:25:25PM +0000, Bjoern Rennhak wrote:
> Dear Xen Developers,
> 
> I found handling of vifx.y interfaces slightly unintutive and was
> wondering if it is possible to name the interface via the Xen guest
> config file?
> 
> e.g. a vif_name parameter or otherwise maybe vif interface is automatically named
> after set "name" entry in config instead of generic vifx.y.
> 
> So instead of a bunch of vifx.y's I would see <descriptivename>x.y ?
> 
> Is that already possible or a bad idea in general?

Check out

http://xenbits.xen.org/docs/4.4-testing/misc/xl-network-configuration.html

vifname

Wei.

> Should I open a wishlist entry on http://bugs.xenproject.org/xen/?
> 
> Thank you!
> 
> Cheers,
> -Bjoern
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 11 00:30:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 00:30:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyrdu-0000Bt-5L; Thu, 11 Dec 2014 00:30:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1Xyrds-0000Bo-Hg
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 00:30:04 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	53/B2-14214-B85E8845; Thu, 11 Dec 2014 00:30:03 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418257801!9808283!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31640 invoked from network); 11 Dec 2014 00:30:03 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Dec 2014 00:30:03 -0000
Received: from anacreon.sc.intel.com (fmdmzpr01-ext.fm.intel.com
	[192.55.54.36]) (authenticated bits=0)
	by mail.zytor.com (8.14.8/8.14.5) with ESMTP id sBB0TBjb014739
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Wed, 10 Dec 2014 16:29:12 -0800
Message-ID: <5488E552.8050207@zytor.com>
Date: Wed, 10 Dec 2014 16:29:06 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>, mingo@redhat.com,
	peterz@infradead.org
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
In-Reply-To: <1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
Cc: jgross@suse.com, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, david.vrabel@citrix.com, JBeulich@suse.com,
	masami.hiramatsu.pt@hitachi.com, xen-devel@lists.xenproject.org,
	tglx@linutronix.de, Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/10/2014 03:34 PM, Luis R. Rodriguez wrote:
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 344b63f..40b5c0c 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
>  ENTRY(xen_do_upcall)
>  1:	mov %esp, %eax
>  	call xen_evtchn_do_upcall
> +#ifdef CONFIG_PREEMPT
>  	jmp  ret_from_intr
> +#else
> +	GET_THREAD_INFO(%ebp)
> +#ifdef CONFIG_VM86
> +	movl PT_EFLAGS(%esp), %eax	# mix EFLAGS and CS
> +	movb PT_CS(%esp), %al
> +	andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
> +#else
> +	movl PT_CS(%esp), %eax
> +	andl $SEGMENT_RPL_MASK, %eax
> +#endif
> +	cmpl $USER_RPL, %eax
> +	jae resume_userspace		# returning to v8086 or userspace
> +	DISABLE_INTERRUPTS(CLBR_ANY)
> +	cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +	jz resume_kernel
> +	movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +	call cond_resched_irq
> +	movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> +	jmp resume_kernel
> +#endif /* CONFIG_PREEMPT */
>  	CFI_ENDPROC
>  ENDPROC(xen_hypervisor_callback)
>  
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index c0226ab..0ccdd06 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
>  	popq %rsp
>  	CFI_DEF_CFA_REGISTER rsp
>  	decl PER_CPU_VAR(irq_count)
> +#ifdef CONFIG_PREEMPT
>  	jmp  error_exit
> +#else
> +	movl %ebx, %eax
> +	RESTORE_REST
> +	DISABLE_INTERRUPTS(CLBR_NONE)
> +	TRACE_IRQS_OFF
> +	GET_THREAD_INFO(%rcx)
> +	testl %eax, %eax
> +	je error_exit_user
> +	cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +	jz retint_kernel
> +	movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +	call cond_resched_irq
> +	movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> +	jmp retint_kernel
> +#endif /* CONFIG_PREEMPT */
>  	CFI_ENDPROC
>  END(xen_do_hypervisor_callback)
>  
> @@ -1398,6 +1414,7 @@ ENTRY(error_exit)
>  	GET_THREAD_INFO(%rcx)
>  	testl %eax,%eax
>  	jne retint_kernel
> +error_exit_user:
>  	LOCKDEP_SYS_EXIT_IRQ
>  	movl TI_flags(%rcx),%edx
>  	movl $_TIF_WORK_MASK,%edi

You're adding a bunch of code for the *non*-preemptive case here... why?

	-hpa



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 00:30:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 00:30:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyrdu-0000Bt-5L; Thu, 11 Dec 2014 00:30:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1Xyrds-0000Bo-Hg
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 00:30:04 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	53/B2-14214-B85E8845; Thu, 11 Dec 2014 00:30:03 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418257801!9808283!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31640 invoked from network); 11 Dec 2014 00:30:03 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Dec 2014 00:30:03 -0000
Received: from anacreon.sc.intel.com (fmdmzpr01-ext.fm.intel.com
	[192.55.54.36]) (authenticated bits=0)
	by mail.zytor.com (8.14.8/8.14.5) with ESMTP id sBB0TBjb014739
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Wed, 10 Dec 2014 16:29:12 -0800
Message-ID: <5488E552.8050207@zytor.com>
Date: Wed, 10 Dec 2014 16:29:06 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>, mingo@redhat.com,
	peterz@infradead.org
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
In-Reply-To: <1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
Cc: jgross@suse.com, "Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, david.vrabel@citrix.com, JBeulich@suse.com,
	masami.hiramatsu.pt@hitachi.com, xen-devel@lists.xenproject.org,
	tglx@linutronix.de, Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/10/2014 03:34 PM, Luis R. Rodriguez wrote:
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 344b63f..40b5c0c 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
>  ENTRY(xen_do_upcall)
>  1:	mov %esp, %eax
>  	call xen_evtchn_do_upcall
> +#ifdef CONFIG_PREEMPT
>  	jmp  ret_from_intr
> +#else
> +	GET_THREAD_INFO(%ebp)
> +#ifdef CONFIG_VM86
> +	movl PT_EFLAGS(%esp), %eax	# mix EFLAGS and CS
> +	movb PT_CS(%esp), %al
> +	andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
> +#else
> +	movl PT_CS(%esp), %eax
> +	andl $SEGMENT_RPL_MASK, %eax
> +#endif
> +	cmpl $USER_RPL, %eax
> +	jae resume_userspace		# returning to v8086 or userspace
> +	DISABLE_INTERRUPTS(CLBR_ANY)
> +	cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +	jz resume_kernel
> +	movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +	call cond_resched_irq
> +	movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> +	jmp resume_kernel
> +#endif /* CONFIG_PREEMPT */
>  	CFI_ENDPROC
>  ENDPROC(xen_hypervisor_callback)
>  
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index c0226ab..0ccdd06 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
>  	popq %rsp
>  	CFI_DEF_CFA_REGISTER rsp
>  	decl PER_CPU_VAR(irq_count)
> +#ifdef CONFIG_PREEMPT
>  	jmp  error_exit
> +#else
> +	movl %ebx, %eax
> +	RESTORE_REST
> +	DISABLE_INTERRUPTS(CLBR_NONE)
> +	TRACE_IRQS_OFF
> +	GET_THREAD_INFO(%rcx)
> +	testl %eax, %eax
> +	je error_exit_user
> +	cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +	jz retint_kernel
> +	movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> +	call cond_resched_irq
> +	movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> +	jmp retint_kernel
> +#endif /* CONFIG_PREEMPT */
>  	CFI_ENDPROC
>  END(xen_do_hypervisor_callback)
>  
> @@ -1398,6 +1414,7 @@ ENTRY(error_exit)
>  	GET_THREAD_INFO(%rcx)
>  	testl %eax,%eax
>  	jne retint_kernel
> +error_exit_user:
>  	LOCKDEP_SYS_EXIT_IRQ
>  	movl TI_flags(%rcx),%edx
>  	movl $_TIF_WORK_MASK,%edi

You're adding a bunch of code for the *non*-preemptive case here... why?

	-hpa



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 00:55:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 00: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 1Xys2G-0001Ed-BP; Thu, 11 Dec 2014 00:55:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1Xys2E-0001EW-Rb
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 00:55:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AE/17-15461-17BE8845; Thu, 11 Dec 2014 00:55:13 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418259312!7496971!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29093 invoked from network); 11 Dec 2014 00:55: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; 11 Dec 2014 00:55:12 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A07E8AB07;
	Thu, 11 Dec 2014 00:55:10 +0000 (UTC)
Date: Thu, 11 Dec 2014 01:55:09 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Andy Lutomirski <luto@amacapital.net>
Message-ID: <20141211005509.GN25677@wotan.suse.de>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Juergen Gross <jgross@suse.com>, X86 ML <x86@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be	preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 03:51:48PM -0800, Andy Lutomirski wrote:
> On Wed, Dec 10, 2014 at 3:34 PM, Luis R. Rodriguez
> <mcgrof@do-not-panic.com> wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > Xen has support for splitting heavy work work into a series
> > of hypercalls, called multicalls, and preempting them through
> > what Xen calls continuation [0]. Despite this though without
> > CONFIG_PREEMPT preemption won't happen and while enabling
> > CONFIG_RT_GROUP_SCHED can at times help its not enough to
> > make a system usable. Such is the case for example when
> > creating a > 50 GiB HVM guest, we can get softlockups [1] with:.
> >
> > kernel: [  802.084335] BUG: soft lockup - CPU#1 stuck for 22s! [xend:31351]
> >
> > The softlock up triggers on the TASK_UNINTERRUPTIBLE hanger check
> > (default 120 seconds), on the Xen side in this particular case
> > this happens when the following Xen hypervisor code is used:
> >
> > xc_domain_set_pod_target() -->
> >   do_memory_op() -->
> >     arch_memory_op() -->
> >       p2m_pod_set_mem_target()
> >         -- long delay (real or emulated) --
> >
> > This happens on arch_memory_op() on the XENMEM_set_pod_target memory
> > op even though arch_memory_op() can handle continuation via
> > hypercall_create_continuation() for example.
> >
> > Machines over 50 GiB of memory are on high demand and hard to come
> > by so to help replicate this sort of issue long delays on select
> > hypercalls have been emulated in order to be able to test this on
> > smaller machines [2].
> >
> > On one hand this issue can be considered as expected given that
> > CONFIG_PREEMPT=n is used however we have forced voluntary preemption
> > precedent practices in the kernel even for CONFIG_PREEMPT=n through
> > the usage of cond_resched() sprinkled in many places. To address
> > this issue with Xen hypercalls though we need to find a way to aid
> > to the schedular in the middle of hypercalls. We are motivated to
> > address this issue on CONFIG_PREEMPT=n as otherwise the system becomes
> > rather unresponsive for long periods of time; in the worst case, at least
> > only currently by emulating long delays on select io disk bound
> > hypercalls, this can lead to filesystem corruption if the delay happens
> > for example on SCHEDOP_remote_shutdown (when we call 'xl <domain> shutdown').
> >
> > We can address this problem by trying to check if we should schedule
> > on the xen timer in the middle of a hypercall on the return from the
> > timer interrupt. We want to be careful to not always force voluntary
> > preemption though so to do this we only selectively enable preemption
> > on very specific xen hypercalls.
> >
> > This enables hypercall preemption by selectively forcing checks for
> > voluntary preempting only on ioctl initiated private hypercalls
> > where we know some folks have run into reported issues [1].
> >
> > [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
> > [1] https://bugzilla.novell.com/show_bug.cgi?id=861093
> > [2] http://ftp.suse.com/pub/people/mcgrof/xen/emulate-long-xen-hypercalls.patch
> >
> > Based on original work by: David Vrabel <david.vrabel@citrix.com>
> > Cc: Borislav Petkov <bp@suse.de>
> > Cc: David Vrabel <david.vrabel@citrix.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: x86@kernel.org
> > Cc: Andy Lutomirski <luto@amacapital.net>
> > Cc: Steven Rostedt <rostedt@goodmis.org>
> > Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> > ---
> >  arch/x86/kernel/entry_32.S | 21 +++++++++++++++++++++
> >  arch/x86/kernel/entry_64.S | 17 +++++++++++++++++
> >  drivers/xen/Makefile       |  2 +-
> >  drivers/xen/preempt.c      | 17 +++++++++++++++++
> >  drivers/xen/privcmd.c      |  2 ++
> >  include/xen/xen-ops.h      | 26 ++++++++++++++++++++++++++
> >  6 files changed, 84 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/xen/preempt.c
> >
> > diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> > index 344b63f..40b5c0c 100644
> > --- a/arch/x86/kernel/entry_32.S
> > +++ b/arch/x86/kernel/entry_32.S
> > @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
> >  ENTRY(xen_do_upcall)
> >  1:     mov %esp, %eax
> >         call xen_evtchn_do_upcall
> > +#ifdef CONFIG_PREEMPT
> >         jmp  ret_from_intr
> > +#else
> > +       GET_THREAD_INFO(%ebp)
> > +#ifdef CONFIG_VM86
> > +       movl PT_EFLAGS(%esp), %eax      # mix EFLAGS and CS
> > +       movb PT_CS(%esp), %al
> > +       andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
> > +#else
> > +       movl PT_CS(%esp), %eax
> > +       andl $SEGMENT_RPL_MASK, %eax
> > +#endif
> > +       cmpl $USER_RPL, %eax
> > +       jae resume_userspace            # returning to v8086 or userspace
> > +       DISABLE_INTERRUPTS(CLBR_ANY)
> > +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +       jz resume_kernel
> > +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +       call cond_resched_irq
> > +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +       jmp resume_kernel
> > +#endif /* CONFIG_PREEMPT */
> >         CFI_ENDPROC
> >  ENDPROC(xen_hypervisor_callback)
> >
> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> > index c0226ab..0ccdd06 100644
> > --- a/arch/x86/kernel/entry_64.S
> > +++ b/arch/x86/kernel/entry_64.S
> > @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
> >         popq %rsp
> >         CFI_DEF_CFA_REGISTER rsp
> >         decl PER_CPU_VAR(irq_count)
> > +#ifdef CONFIG_PREEMPT
> >         jmp  error_exit
> > +#else
> > +       movl %ebx, %eax
> > +       RESTORE_REST
> > +       DISABLE_INTERRUPTS(CLBR_NONE)
> > +       TRACE_IRQS_OFF
> > +       GET_THREAD_INFO(%rcx)
> > +       testl %eax, %eax
> > +       je error_exit_user
> > +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +       jz retint_kernel
> 
> I think I understand this part.
> 
> > +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> 
> Why?  Is the issue that, if preemptible hypercalls nest, you don't
> want to preempt again?


So this callback on the xen timer, without the CPU variable
we would not be able to selectively preempt specific hypercalls
and we'd a no-preempt kernel fully preemptive.

I asked the same question, see:

https://lkml.org/lkml/2014/12/3/756

> 
> > +       call cond_resched_irq
> 
> On !CONFIG_PREEMPT, there's no preempt_disable, right?  So how do you
> guarantee that you don't preempt something you shouldn't?

Not sure I follow, but in essence this is no different then the use
of cond_resched() on !CONFIG_PREEMPT, the only thing here is we are
in interrupt context. If this is about abuse of making !CONFIG_PREEMPT
voluntarily preemptive at select points then I had similar concerns
and David pointed out to me the wide use of cond_resched() on the
kernel.

> Is the idea
> that these events will only fire nested *directly* inside a
> preemptible hypercall?

Yeah its the timer interrupt that would trigger the above.

> Also, should you check that IRQs were on when
> the event fired?  (Are they on in pt_regs?)

Right before this xen_evtchn_do_upcall() is issued, which
saves pt_regs and then restores them.

> > +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +       jmp retint_kernel
> > +#endif /* CONFIG_PREEMPT */
> >         CFI_ENDPROC
> 
> All that being said, this is IMO a bit gross.

That was my first reaction hence my original attempt to try to get away from
this. I've learned David also tried to not go down this route too before,
more on this below.

>  You've added a bunch of
> asm that's kind of like a parallel error_exit,

yeah.. I first tried to macro'tize this but it looked hairy, if we
wanted to do that... (although the name probably ain't best)

32-bit:
.macro test_from_kernel kernel_ret:req
	GET_THREAD_INFO(%ebp)
#ifdef CONFIG_VM86
	movl PT_EFLAGS(%esp), %eax	# mix EFLAGS and CS
	movb PT_CS(%esp), %al
	andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
#else
	/*
	 * We can be coming here from child spawned by kernel_thread().
	 */
	movl PT_CS(%esp), %eax
	andl $SEGMENT_RPL_MASK, %eax
#endif
	cmpl $USER_RPL, %eax
	jb \kernel_ret
.endm

64-bit:
	.macro test_from_kernel kernel_ret:req
	movl %ebx,%eax
	RESTORE_REST
	DISABLE_INTERRUPTS(CLBR_NONE)
	TRACE_IRQS_OFF
	GET_THREAD_INFO(%rcx)
	testl %eax,%eax
	jne \kernel_ret
	.endm

> and the error entry and
> exit code is hairy enough that this scares me.

yeah...

>  Can you do this mostly in C instead?  This would look a nicer if it could be:
> 
>     call xen_evtchn_do_upcall
>     popq %rsp
>     CFI_DEF_CFA_REGISTER rsp
>     decl PER_CPU_VAR(irq_count)
> +  call xen_end_upcall
>     jmp error_exit

It seems David tried this originally eons ago:

http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html

and the strategy was shifted based on Jan's feedback that we could
not sched as we're on the IRQ stack. David evolved the strategy
to asm and to use preempt_schedule_irq(), this new iteratin just
revisits the same old but tries to generalize scheduling on IRQ
context on very special circumstances.

> Where xen_end_upcall would be witten in C, nokprobes and notrace (if
> needed) and would check pt_regs and whatever else and just call
> schedule if needed?

If there's a way to do it it'd be great. I am not sure if we can though.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 00:55:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 00: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 1Xys2G-0001Ed-BP; Thu, 11 Dec 2014 00:55:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1Xys2E-0001EW-Rb
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 00:55:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AE/17-15461-17BE8845; Thu, 11 Dec 2014 00:55:13 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418259312!7496971!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29093 invoked from network); 11 Dec 2014 00:55: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; 11 Dec 2014 00:55:12 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A07E8AB07;
	Thu, 11 Dec 2014 00:55:10 +0000 (UTC)
Date: Thu, 11 Dec 2014 01:55:09 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Andy Lutomirski <luto@amacapital.net>
Message-ID: <20141211005509.GN25677@wotan.suse.de>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Juergen Gross <jgross@suse.com>, X86 ML <x86@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be	preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 03:51:48PM -0800, Andy Lutomirski wrote:
> On Wed, Dec 10, 2014 at 3:34 PM, Luis R. Rodriguez
> <mcgrof@do-not-panic.com> wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > Xen has support for splitting heavy work work into a series
> > of hypercalls, called multicalls, and preempting them through
> > what Xen calls continuation [0]. Despite this though without
> > CONFIG_PREEMPT preemption won't happen and while enabling
> > CONFIG_RT_GROUP_SCHED can at times help its not enough to
> > make a system usable. Such is the case for example when
> > creating a > 50 GiB HVM guest, we can get softlockups [1] with:.
> >
> > kernel: [  802.084335] BUG: soft lockup - CPU#1 stuck for 22s! [xend:31351]
> >
> > The softlock up triggers on the TASK_UNINTERRUPTIBLE hanger check
> > (default 120 seconds), on the Xen side in this particular case
> > this happens when the following Xen hypervisor code is used:
> >
> > xc_domain_set_pod_target() -->
> >   do_memory_op() -->
> >     arch_memory_op() -->
> >       p2m_pod_set_mem_target()
> >         -- long delay (real or emulated) --
> >
> > This happens on arch_memory_op() on the XENMEM_set_pod_target memory
> > op even though arch_memory_op() can handle continuation via
> > hypercall_create_continuation() for example.
> >
> > Machines over 50 GiB of memory are on high demand and hard to come
> > by so to help replicate this sort of issue long delays on select
> > hypercalls have been emulated in order to be able to test this on
> > smaller machines [2].
> >
> > On one hand this issue can be considered as expected given that
> > CONFIG_PREEMPT=n is used however we have forced voluntary preemption
> > precedent practices in the kernel even for CONFIG_PREEMPT=n through
> > the usage of cond_resched() sprinkled in many places. To address
> > this issue with Xen hypercalls though we need to find a way to aid
> > to the schedular in the middle of hypercalls. We are motivated to
> > address this issue on CONFIG_PREEMPT=n as otherwise the system becomes
> > rather unresponsive for long periods of time; in the worst case, at least
> > only currently by emulating long delays on select io disk bound
> > hypercalls, this can lead to filesystem corruption if the delay happens
> > for example on SCHEDOP_remote_shutdown (when we call 'xl <domain> shutdown').
> >
> > We can address this problem by trying to check if we should schedule
> > on the xen timer in the middle of a hypercall on the return from the
> > timer interrupt. We want to be careful to not always force voluntary
> > preemption though so to do this we only selectively enable preemption
> > on very specific xen hypercalls.
> >
> > This enables hypercall preemption by selectively forcing checks for
> > voluntary preempting only on ioctl initiated private hypercalls
> > where we know some folks have run into reported issues [1].
> >
> > [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
> > [1] https://bugzilla.novell.com/show_bug.cgi?id=861093
> > [2] http://ftp.suse.com/pub/people/mcgrof/xen/emulate-long-xen-hypercalls.patch
> >
> > Based on original work by: David Vrabel <david.vrabel@citrix.com>
> > Cc: Borislav Petkov <bp@suse.de>
> > Cc: David Vrabel <david.vrabel@citrix.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: x86@kernel.org
> > Cc: Andy Lutomirski <luto@amacapital.net>
> > Cc: Steven Rostedt <rostedt@goodmis.org>
> > Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> > ---
> >  arch/x86/kernel/entry_32.S | 21 +++++++++++++++++++++
> >  arch/x86/kernel/entry_64.S | 17 +++++++++++++++++
> >  drivers/xen/Makefile       |  2 +-
> >  drivers/xen/preempt.c      | 17 +++++++++++++++++
> >  drivers/xen/privcmd.c      |  2 ++
> >  include/xen/xen-ops.h      | 26 ++++++++++++++++++++++++++
> >  6 files changed, 84 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/xen/preempt.c
> >
> > diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> > index 344b63f..40b5c0c 100644
> > --- a/arch/x86/kernel/entry_32.S
> > +++ b/arch/x86/kernel/entry_32.S
> > @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
> >  ENTRY(xen_do_upcall)
> >  1:     mov %esp, %eax
> >         call xen_evtchn_do_upcall
> > +#ifdef CONFIG_PREEMPT
> >         jmp  ret_from_intr
> > +#else
> > +       GET_THREAD_INFO(%ebp)
> > +#ifdef CONFIG_VM86
> > +       movl PT_EFLAGS(%esp), %eax      # mix EFLAGS and CS
> > +       movb PT_CS(%esp), %al
> > +       andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
> > +#else
> > +       movl PT_CS(%esp), %eax
> > +       andl $SEGMENT_RPL_MASK, %eax
> > +#endif
> > +       cmpl $USER_RPL, %eax
> > +       jae resume_userspace            # returning to v8086 or userspace
> > +       DISABLE_INTERRUPTS(CLBR_ANY)
> > +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +       jz resume_kernel
> > +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +       call cond_resched_irq
> > +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +       jmp resume_kernel
> > +#endif /* CONFIG_PREEMPT */
> >         CFI_ENDPROC
> >  ENDPROC(xen_hypervisor_callback)
> >
> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> > index c0226ab..0ccdd06 100644
> > --- a/arch/x86/kernel/entry_64.S
> > +++ b/arch/x86/kernel/entry_64.S
> > @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
> >         popq %rsp
> >         CFI_DEF_CFA_REGISTER rsp
> >         decl PER_CPU_VAR(irq_count)
> > +#ifdef CONFIG_PREEMPT
> >         jmp  error_exit
> > +#else
> > +       movl %ebx, %eax
> > +       RESTORE_REST
> > +       DISABLE_INTERRUPTS(CLBR_NONE)
> > +       TRACE_IRQS_OFF
> > +       GET_THREAD_INFO(%rcx)
> > +       testl %eax, %eax
> > +       je error_exit_user
> > +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +       jz retint_kernel
> 
> I think I understand this part.
> 
> > +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> 
> Why?  Is the issue that, if preemptible hypercalls nest, you don't
> want to preempt again?


So this callback on the xen timer, without the CPU variable
we would not be able to selectively preempt specific hypercalls
and we'd a no-preempt kernel fully preemptive.

I asked the same question, see:

https://lkml.org/lkml/2014/12/3/756

> 
> > +       call cond_resched_irq
> 
> On !CONFIG_PREEMPT, there's no preempt_disable, right?  So how do you
> guarantee that you don't preempt something you shouldn't?

Not sure I follow, but in essence this is no different then the use
of cond_resched() on !CONFIG_PREEMPT, the only thing here is we are
in interrupt context. If this is about abuse of making !CONFIG_PREEMPT
voluntarily preemptive at select points then I had similar concerns
and David pointed out to me the wide use of cond_resched() on the
kernel.

> Is the idea
> that these events will only fire nested *directly* inside a
> preemptible hypercall?

Yeah its the timer interrupt that would trigger the above.

> Also, should you check that IRQs were on when
> the event fired?  (Are they on in pt_regs?)

Right before this xen_evtchn_do_upcall() is issued, which
saves pt_regs and then restores them.

> > +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +       jmp retint_kernel
> > +#endif /* CONFIG_PREEMPT */
> >         CFI_ENDPROC
> 
> All that being said, this is IMO a bit gross.

That was my first reaction hence my original attempt to try to get away from
this. I've learned David also tried to not go down this route too before,
more on this below.

>  You've added a bunch of
> asm that's kind of like a parallel error_exit,

yeah.. I first tried to macro'tize this but it looked hairy, if we
wanted to do that... (although the name probably ain't best)

32-bit:
.macro test_from_kernel kernel_ret:req
	GET_THREAD_INFO(%ebp)
#ifdef CONFIG_VM86
	movl PT_EFLAGS(%esp), %eax	# mix EFLAGS and CS
	movb PT_CS(%esp), %al
	andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
#else
	/*
	 * We can be coming here from child spawned by kernel_thread().
	 */
	movl PT_CS(%esp), %eax
	andl $SEGMENT_RPL_MASK, %eax
#endif
	cmpl $USER_RPL, %eax
	jb \kernel_ret
.endm

64-bit:
	.macro test_from_kernel kernel_ret:req
	movl %ebx,%eax
	RESTORE_REST
	DISABLE_INTERRUPTS(CLBR_NONE)
	TRACE_IRQS_OFF
	GET_THREAD_INFO(%rcx)
	testl %eax,%eax
	jne \kernel_ret
	.endm

> and the error entry and
> exit code is hairy enough that this scares me.

yeah...

>  Can you do this mostly in C instead?  This would look a nicer if it could be:
> 
>     call xen_evtchn_do_upcall
>     popq %rsp
>     CFI_DEF_CFA_REGISTER rsp
>     decl PER_CPU_VAR(irq_count)
> +  call xen_end_upcall
>     jmp error_exit

It seems David tried this originally eons ago:

http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html

and the strategy was shifted based on Jan's feedback that we could
not sched as we're on the IRQ stack. David evolved the strategy
to asm and to use preempt_schedule_irq(), this new iteratin just
revisits the same old but tries to generalize scheduling on IRQ
context on very special circumstances.

> Where xen_end_upcall would be witten in C, nokprobes and notrace (if
> needed) and would check pt_regs and whatever else and just call
> schedule if needed?

If there's a way to do it it'd be great. I am not sure if we can though.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 01:03:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 01: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 1XysAW-0005WG-B7; Thu, 11 Dec 2014 01:03:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XysAV-0005WB-0N
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 01:03:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C9/A4-25276-27DE8845; Thu, 11 Dec 2014 01:03:46 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418259825!14455422!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 7877 invoked from network); 11 Dec 2014 01:03:45 -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; 11 Dec 2014 01:03:45 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 47A84AB09;
	Thu, 11 Dec 2014 01:03:45 +0000 (UTC)
Date: Thu, 11 Dec 2014 02:03:44 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20141211010344.GO25677@wotan.suse.de>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<5488E552.8050207@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5488E552.8050207@zytor.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: jgross@suse.com, x86@kernel.org, peterz@infradead.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, mingo@redhat.com, david.vrabel@citrix.com,
	JBeulich@suse.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be	preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 04:29:06PM -0800, H. Peter Anvin wrote:
> On 12/10/2014 03:34 PM, Luis R. Rodriguez wrote:
> > diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> > index 344b63f..40b5c0c 100644
> > --- a/arch/x86/kernel/entry_32.S
> > +++ b/arch/x86/kernel/entry_32.S
> > @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
> >  ENTRY(xen_do_upcall)
> >  1:	mov %esp, %eax
> >  	call xen_evtchn_do_upcall
> > +#ifdef CONFIG_PREEMPT
> >  	jmp  ret_from_intr
> > +#else
> > +	GET_THREAD_INFO(%ebp)
> > +#ifdef CONFIG_VM86
> > +	movl PT_EFLAGS(%esp), %eax	# mix EFLAGS and CS
> > +	movb PT_CS(%esp), %al
> > +	andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
> > +#else
> > +	movl PT_CS(%esp), %eax
> > +	andl $SEGMENT_RPL_MASK, %eax
> > +#endif
> > +	cmpl $USER_RPL, %eax
> > +	jae resume_userspace		# returning to v8086 or userspace
> > +	DISABLE_INTERRUPTS(CLBR_ANY)
> > +	cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +	jz resume_kernel
> > +	movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +	call cond_resched_irq
> > +	movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +	jmp resume_kernel
> > +#endif /* CONFIG_PREEMPT */
> >  	CFI_ENDPROC
> >  ENDPROC(xen_hypervisor_callback)
> >  
> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> > index c0226ab..0ccdd06 100644
> > --- a/arch/x86/kernel/entry_64.S
> > +++ b/arch/x86/kernel/entry_64.S
> > @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
> >  	popq %rsp
> >  	CFI_DEF_CFA_REGISTER rsp
> >  	decl PER_CPU_VAR(irq_count)
> > +#ifdef CONFIG_PREEMPT
> >  	jmp  error_exit
> > +#else
> > +	movl %ebx, %eax
> > +	RESTORE_REST
> > +	DISABLE_INTERRUPTS(CLBR_NONE)
> > +	TRACE_IRQS_OFF
> > +	GET_THREAD_INFO(%rcx)
> > +	testl %eax, %eax
> > +	je error_exit_user
> > +	cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +	jz retint_kernel
> > +	movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +	call cond_resched_irq
> > +	movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +	jmp retint_kernel
> > +#endif /* CONFIG_PREEMPT */
> >  	CFI_ENDPROC
> >  END(xen_do_hypervisor_callback)
> >  
> > @@ -1398,6 +1414,7 @@ ENTRY(error_exit)
> >  	GET_THREAD_INFO(%rcx)
> >  	testl %eax,%eax
> >  	jne retint_kernel
> > +error_exit_user:
> >  	LOCKDEP_SYS_EXIT_IRQ
> >  	movl TI_flags(%rcx),%edx
> >  	movl $_TIF_WORK_MASK,%edi
> 
> You're adding a bunch of code for the *non*-preemptive case here... why?

This is an issue onloy for for non*-preemptive kernels.

Some of Xen's hypercalls can take a long time and unfortunately for
*non*-preemptive kernels this can be quite a bit of an issue.
We've handled situations like this with cond_resched() before which will
push even *non*-preemptive kernels to behave as voluntarily preemptive,
I was not aware to what extent this was done and precedents set but
its pretety widespread now... this then just addresses once particular
case where this is also an issuefor but now in IRQ context.

I agree its a hack but so are all the other cond_reshed() calls then.
I don't think its a good idea to be spreading use of something like
this everywhere but after careful review and trying toa void this
exact code for a while I have not been able to find any other reasonable
alternative.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 01:03:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 01: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 1XysAW-0005WG-B7; Thu, 11 Dec 2014 01:03:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XysAV-0005WB-0N
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 01:03:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C9/A4-25276-27DE8845; Thu, 11 Dec 2014 01:03:46 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418259825!14455422!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 7877 invoked from network); 11 Dec 2014 01:03:45 -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; 11 Dec 2014 01:03:45 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 47A84AB09;
	Thu, 11 Dec 2014 01:03:45 +0000 (UTC)
Date: Thu, 11 Dec 2014 02:03:44 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20141211010344.GO25677@wotan.suse.de>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<5488E552.8050207@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5488E552.8050207@zytor.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: jgross@suse.com, x86@kernel.org, peterz@infradead.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, mingo@redhat.com, david.vrabel@citrix.com,
	JBeulich@suse.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be	preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 04:29:06PM -0800, H. Peter Anvin wrote:
> On 12/10/2014 03:34 PM, Luis R. Rodriguez wrote:
> > diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> > index 344b63f..40b5c0c 100644
> > --- a/arch/x86/kernel/entry_32.S
> > +++ b/arch/x86/kernel/entry_32.S
> > @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
> >  ENTRY(xen_do_upcall)
> >  1:	mov %esp, %eax
> >  	call xen_evtchn_do_upcall
> > +#ifdef CONFIG_PREEMPT
> >  	jmp  ret_from_intr
> > +#else
> > +	GET_THREAD_INFO(%ebp)
> > +#ifdef CONFIG_VM86
> > +	movl PT_EFLAGS(%esp), %eax	# mix EFLAGS and CS
> > +	movb PT_CS(%esp), %al
> > +	andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
> > +#else
> > +	movl PT_CS(%esp), %eax
> > +	andl $SEGMENT_RPL_MASK, %eax
> > +#endif
> > +	cmpl $USER_RPL, %eax
> > +	jae resume_userspace		# returning to v8086 or userspace
> > +	DISABLE_INTERRUPTS(CLBR_ANY)
> > +	cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +	jz resume_kernel
> > +	movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +	call cond_resched_irq
> > +	movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +	jmp resume_kernel
> > +#endif /* CONFIG_PREEMPT */
> >  	CFI_ENDPROC
> >  ENDPROC(xen_hypervisor_callback)
> >  
> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> > index c0226ab..0ccdd06 100644
> > --- a/arch/x86/kernel/entry_64.S
> > +++ b/arch/x86/kernel/entry_64.S
> > @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
> >  	popq %rsp
> >  	CFI_DEF_CFA_REGISTER rsp
> >  	decl PER_CPU_VAR(irq_count)
> > +#ifdef CONFIG_PREEMPT
> >  	jmp  error_exit
> > +#else
> > +	movl %ebx, %eax
> > +	RESTORE_REST
> > +	DISABLE_INTERRUPTS(CLBR_NONE)
> > +	TRACE_IRQS_OFF
> > +	GET_THREAD_INFO(%rcx)
> > +	testl %eax, %eax
> > +	je error_exit_user
> > +	cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +	jz retint_kernel
> > +	movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +	call cond_resched_irq
> > +	movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
> > +	jmp retint_kernel
> > +#endif /* CONFIG_PREEMPT */
> >  	CFI_ENDPROC
> >  END(xen_do_hypervisor_callback)
> >  
> > @@ -1398,6 +1414,7 @@ ENTRY(error_exit)
> >  	GET_THREAD_INFO(%rcx)
> >  	testl %eax,%eax
> >  	jne retint_kernel
> > +error_exit_user:
> >  	LOCKDEP_SYS_EXIT_IRQ
> >  	movl TI_flags(%rcx),%edx
> >  	movl $_TIF_WORK_MASK,%edi
> 
> You're adding a bunch of code for the *non*-preemptive case here... why?

This is an issue onloy for for non*-preemptive kernels.

Some of Xen's hypercalls can take a long time and unfortunately for
*non*-preemptive kernels this can be quite a bit of an issue.
We've handled situations like this with cond_resched() before which will
push even *non*-preemptive kernels to behave as voluntarily preemptive,
I was not aware to what extent this was done and precedents set but
its pretety widespread now... this then just addresses once particular
case where this is also an issuefor but now in IRQ context.

I agree its a hack but so are all the other cond_reshed() calls then.
I don't think its a good idea to be spreading use of something like
this everywhere but after careful review and trying toa void this
exact code for a while I have not been able to find any other reasonable
alternative.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 01:04:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 01:04:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XysBa-0005kC-PR; Thu, 11 Dec 2014 01:04:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1XysBZ-0005k4-A9
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 01:04:53 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	01/87-28865-4BDE8845; Thu, 11 Dec 2014 01:04:52 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418259891!12709334!1
X-Originating-IP: [209.85.215.50]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16232 invoked from network); 11 Dec 2014 01:04:51 -0000
Received: from mail-la0-f50.google.com (HELO mail-la0-f50.google.com)
	(209.85.215.50)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 01:04:51 -0000
Received: by mail-la0-f50.google.com with SMTP id pn19so3425771lab.37
	for <xen-devel@lists.xenproject.org>;
	Wed, 10 Dec 2014 17:04: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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=bWBPI0Tvtn4+Jdbzcw0hUsHmzG3+HfmD48zvuZC/dSA=;
	b=kVKzU9vUg3hDDEhBdKmqdXkNKv2KT4ajFsC+uCG+LVmoIIqI06SGBH9WXvj/PKpwaH
	u4uY3h8Pl6A9x6teCj6jhMsq7ncbPDq9nFJimv82btPMM9gsYXwz6GTAtN+TPArJ48Ef
	MQ8BmUhJnomtdPHcNgXfUQXkuEXKKd4xn4wUc4BVnJy13E8FmgXHvxRULlN3C7g+iajp
	IRwDPifGOGi5PZkqb5K2H/OJzuSe8LEOJBj277YWkUuhfjf/Yju01QrLDpD63PY+aqM3
	NKbIDQutfXXPbpVbkU6kR+C+bIkrCb/Pf3opbZ0wePbZTq7FrKHtbKUi4NeeMmlEX3Oj
	RFUA==
X-Gm-Message-State: ALoCoQlk7OGLM3xemTRrIw1SYnqDng+JOfyCOp1sYp/v9836W/volGRXhferL+IV0BZ0vj4UMQWb
X-Received: by 10.152.1.131 with SMTP id 3mr6857417lam.89.1418259890788; Wed,
	10 Dec 2014 17:04:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.7.132 with HTTP; Wed, 10 Dec 2014 17:04:30 -0800 (PST)
In-Reply-To: <20141211005509.GN25677@wotan.suse.de>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
	<20141211005509.GN25677@wotan.suse.de>
From: Andy Lutomirski <luto@amacapital.net>
Date: Wed, 10 Dec 2014 17:04:30 -0800
Message-ID: <CALCETrVNhPvKENkcKu9dbfrBTfFxrknEq96Go8jCy6nOqURxjw@mail.gmail.com>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: Juergen Gross <jgross@suse.com>, X86 ML <x86@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 4:55 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Wed, Dec 10, 2014 at 03:51:48PM -0800, Andy Lutomirski wrote:
>> On Wed, Dec 10, 2014 at 3:34 PM, Luis R. Rodriguez
>> <mcgrof@do-not-panic.com> wrote:
>> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
>> >
>> > Xen has support for splitting heavy work work into a series
>> > of hypercalls, called multicalls, and preempting them through
>> > what Xen calls continuation [0]. Despite this though without
>> > CONFIG_PREEMPT preemption won't happen and while enabling
>> > CONFIG_RT_GROUP_SCHED can at times help its not enough to
>> > make a system usable. Such is the case for example when
>> > creating a > 50 GiB HVM guest, we can get softlockups [1] with:.
>> >
>> > kernel: [  802.084335] BUG: soft lockup - CPU#1 stuck for 22s! [xend:31351]
>> >
>> > The softlock up triggers on the TASK_UNINTERRUPTIBLE hanger check
>> > (default 120 seconds), on the Xen side in this particular case
>> > this happens when the following Xen hypervisor code is used:
>> >
>> > xc_domain_set_pod_target() -->
>> >   do_memory_op() -->
>> >     arch_memory_op() -->
>> >       p2m_pod_set_mem_target()
>> >         -- long delay (real or emulated) --
>> >
>> > This happens on arch_memory_op() on the XENMEM_set_pod_target memory
>> > op even though arch_memory_op() can handle continuation via
>> > hypercall_create_continuation() for example.
>> >
>> > Machines over 50 GiB of memory are on high demand and hard to come
>> > by so to help replicate this sort of issue long delays on select
>> > hypercalls have been emulated in order to be able to test this on
>> > smaller machines [2].
>> >
>> > On one hand this issue can be considered as expected given that
>> > CONFIG_PREEMPT=n is used however we have forced voluntary preemption
>> > precedent practices in the kernel even for CONFIG_PREEMPT=n through
>> > the usage of cond_resched() sprinkled in many places. To address
>> > this issue with Xen hypercalls though we need to find a way to aid
>> > to the schedular in the middle of hypercalls. We are motivated to
>> > address this issue on CONFIG_PREEMPT=n as otherwise the system becomes
>> > rather unresponsive for long periods of time; in the worst case, at least
>> > only currently by emulating long delays on select io disk bound
>> > hypercalls, this can lead to filesystem corruption if the delay happens
>> > for example on SCHEDOP_remote_shutdown (when we call 'xl <domain> shutdown').
>> >
>> > We can address this problem by trying to check if we should schedule
>> > on the xen timer in the middle of a hypercall on the return from the
>> > timer interrupt. We want to be careful to not always force voluntary
>> > preemption though so to do this we only selectively enable preemption
>> > on very specific xen hypercalls.
>> >
>> > This enables hypercall preemption by selectively forcing checks for
>> > voluntary preempting only on ioctl initiated private hypercalls
>> > where we know some folks have run into reported issues [1].
>> >
>> > [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
>> > [1] https://bugzilla.novell.com/show_bug.cgi?id=861093
>> > [2] http://ftp.suse.com/pub/people/mcgrof/xen/emulate-long-xen-hypercalls.patch
>> >
>> > Based on original work by: David Vrabel <david.vrabel@citrix.com>
>> > Cc: Borislav Petkov <bp@suse.de>
>> > Cc: David Vrabel <david.vrabel@citrix.com>
>> > Cc: Thomas Gleixner <tglx@linutronix.de>
>> > Cc: Ingo Molnar <mingo@redhat.com>
>> > Cc: "H. Peter Anvin" <hpa@zytor.com>
>> > Cc: x86@kernel.org
>> > Cc: Andy Lutomirski <luto@amacapital.net>
>> > Cc: Steven Rostedt <rostedt@goodmis.org>
>> > Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
>> > Cc: Jan Beulich <JBeulich@suse.com>
>> > Cc: linux-kernel@vger.kernel.org
>> > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
>> > ---
>> >  arch/x86/kernel/entry_32.S | 21 +++++++++++++++++++++
>> >  arch/x86/kernel/entry_64.S | 17 +++++++++++++++++
>> >  drivers/xen/Makefile       |  2 +-
>> >  drivers/xen/preempt.c      | 17 +++++++++++++++++
>> >  drivers/xen/privcmd.c      |  2 ++
>> >  include/xen/xen-ops.h      | 26 ++++++++++++++++++++++++++
>> >  6 files changed, 84 insertions(+), 1 deletion(-)
>> >  create mode 100644 drivers/xen/preempt.c
>> >
>> > diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
>> > index 344b63f..40b5c0c 100644
>> > --- a/arch/x86/kernel/entry_32.S
>> > +++ b/arch/x86/kernel/entry_32.S
>> > @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
>> >  ENTRY(xen_do_upcall)
>> >  1:     mov %esp, %eax
>> >         call xen_evtchn_do_upcall
>> > +#ifdef CONFIG_PREEMPT
>> >         jmp  ret_from_intr
>> > +#else
>> > +       GET_THREAD_INFO(%ebp)
>> > +#ifdef CONFIG_VM86
>> > +       movl PT_EFLAGS(%esp), %eax      # mix EFLAGS and CS
>> > +       movb PT_CS(%esp), %al
>> > +       andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
>> > +#else
>> > +       movl PT_CS(%esp), %eax
>> > +       andl $SEGMENT_RPL_MASK, %eax
>> > +#endif
>> > +       cmpl $USER_RPL, %eax
>> > +       jae resume_userspace            # returning to v8086 or userspace
>> > +       DISABLE_INTERRUPTS(CLBR_ANY)
>> > +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
>> > +       jz resume_kernel
>> > +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
>> > +       call cond_resched_irq
>> > +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
>> > +       jmp resume_kernel
>> > +#endif /* CONFIG_PREEMPT */
>> >         CFI_ENDPROC
>> >  ENDPROC(xen_hypervisor_callback)
>> >
>> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
>> > index c0226ab..0ccdd06 100644
>> > --- a/arch/x86/kernel/entry_64.S
>> > +++ b/arch/x86/kernel/entry_64.S
>> > @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
>> >         popq %rsp
>> >         CFI_DEF_CFA_REGISTER rsp
>> >         decl PER_CPU_VAR(irq_count)
>> > +#ifdef CONFIG_PREEMPT
>> >         jmp  error_exit
>> > +#else
>> > +       movl %ebx, %eax
>> > +       RESTORE_REST
>> > +       DISABLE_INTERRUPTS(CLBR_NONE)
>> > +       TRACE_IRQS_OFF
>> > +       GET_THREAD_INFO(%rcx)
>> > +       testl %eax, %eax
>> > +       je error_exit_user
>> > +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
>> > +       jz retint_kernel
>>
>> I think I understand this part.
>>
>> > +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
>>
>> Why?  Is the issue that, if preemptible hypercalls nest, you don't
>> want to preempt again?
>
>
> So this callback on the xen timer, without the CPU variable
> we would not be able to selectively preempt specific hypercalls
> and we'd a no-preempt kernel fully preemptive.
>
> I asked the same question, see:
>
> https://lkml.org/lkml/2014/12/3/756
>
>>
>> > +       call cond_resched_irq
>>
>> On !CONFIG_PREEMPT, there's no preempt_disable, right?  So how do you
>> guarantee that you don't preempt something you shouldn't?
>
> Not sure I follow, but in essence this is no different then the use
> of cond_resched() on !CONFIG_PREEMPT, the only thing here is we are
> in interrupt context. If this is about abuse of making !CONFIG_PREEMPT
> voluntarily preemptive at select points then I had similar concerns
> and David pointed out to me the wide use of cond_resched() on the
> kernel.
>
>> Is the idea
>> that these events will only fire nested *directly* inside a
>> preemptible hypercall?
>
> Yeah its the timer interrupt that would trigger the above.
>
>> Also, should you check that IRQs were on when
>> the event fired?  (Are they on in pt_regs?)
>
> Right before this xen_evtchn_do_upcall() is issued, which
> saves pt_regs and then restores them.
>
>> > +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
>> > +       jmp retint_kernel
>> > +#endif /* CONFIG_PREEMPT */
>> >         CFI_ENDPROC
>>
>> All that being said, this is IMO a bit gross.
>
> That was my first reaction hence my original attempt to try to get away from
> this. I've learned David also tried to not go down this route too before,
> more on this below.
>
>>  You've added a bunch of
>> asm that's kind of like a parallel error_exit,
>
> yeah.. I first tried to macro'tize this but it looked hairy, if we
> wanted to do that... (although the name probably ain't best)
>
> 32-bit:
> .macro test_from_kernel kernel_ret:req
>         GET_THREAD_INFO(%ebp)
> #ifdef CONFIG_VM86
>         movl PT_EFLAGS(%esp), %eax      # mix EFLAGS and CS
>         movb PT_CS(%esp), %al
>         andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
> #else
>         /*
>          * We can be coming here from child spawned by kernel_thread().
>          */
>         movl PT_CS(%esp), %eax
>         andl $SEGMENT_RPL_MASK, %eax
> #endif
>         cmpl $USER_RPL, %eax
>         jb \kernel_ret
> .endm
>
> 64-bit:
>         .macro test_from_kernel kernel_ret:req
>         movl %ebx,%eax
>         RESTORE_REST
>         DISABLE_INTERRUPTS(CLBR_NONE)
>         TRACE_IRQS_OFF
>         GET_THREAD_INFO(%rcx)
>         testl %eax,%eax
>         jne \kernel_ret
>         .endm
>
>> and the error entry and
>> exit code is hairy enough that this scares me.
>
> yeah...
>
>>  Can you do this mostly in C instead?  This would look a nicer if it could be:
>>
>>     call xen_evtchn_do_upcall
>>     popq %rsp
>>     CFI_DEF_CFA_REGISTER rsp
>>     decl PER_CPU_VAR(irq_count)
>> +  call xen_end_upcall
>>     jmp error_exit
>
> It seems David tried this originally eons ago:
>
> http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html
>
> and the strategy was shifted based on Jan's feedback that we could
> not sched as we're on the IRQ stack. David evolved the strategy
> to asm and to use preempt_schedule_irq(), this new iteratin just
> revisits the same old but tries to generalize scheduling on IRQ
> context on very special circumstances.

Indeed.  But look more closely at my proposed one-line asm patch:
we're not on the irq stack.

Also, to make this more obviously safe wrt preempting at the wrong
time, would it be possible to check regs->ip and make sure it's
pointing exactly where you expect before scheduling?  (You'd need one
more line of asm to get pt_regs in xen_end_upcall.)

--Andy, the stack switching maestro extraordinaire :)

>
>> Where xen_end_upcall would be witten in C, nokprobes and notrace (if
>> needed) and would check pt_regs and whatever else and just call
>> schedule if needed?
>
> If there's a way to do it it'd be great. I am not sure if we can though.
>
>   Luis



-- 
Andy Lutomirski
AMA Capital Management, LLC

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 01:04:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 01:04:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XysBa-0005kC-PR; Thu, 11 Dec 2014 01:04:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1XysBZ-0005k4-A9
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 01:04:53 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	01/87-28865-4BDE8845; Thu, 11 Dec 2014 01:04:52 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418259891!12709334!1
X-Originating-IP: [209.85.215.50]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16232 invoked from network); 11 Dec 2014 01:04:51 -0000
Received: from mail-la0-f50.google.com (HELO mail-la0-f50.google.com)
	(209.85.215.50)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 01:04:51 -0000
Received: by mail-la0-f50.google.com with SMTP id pn19so3425771lab.37
	for <xen-devel@lists.xenproject.org>;
	Wed, 10 Dec 2014 17:04: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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=bWBPI0Tvtn4+Jdbzcw0hUsHmzG3+HfmD48zvuZC/dSA=;
	b=kVKzU9vUg3hDDEhBdKmqdXkNKv2KT4ajFsC+uCG+LVmoIIqI06SGBH9WXvj/PKpwaH
	u4uY3h8Pl6A9x6teCj6jhMsq7ncbPDq9nFJimv82btPMM9gsYXwz6GTAtN+TPArJ48Ef
	MQ8BmUhJnomtdPHcNgXfUQXkuEXKKd4xn4wUc4BVnJy13E8FmgXHvxRULlN3C7g+iajp
	IRwDPifGOGi5PZkqb5K2H/OJzuSe8LEOJBj277YWkUuhfjf/Yju01QrLDpD63PY+aqM3
	NKbIDQutfXXPbpVbkU6kR+C+bIkrCb/Pf3opbZ0wePbZTq7FrKHtbKUi4NeeMmlEX3Oj
	RFUA==
X-Gm-Message-State: ALoCoQlk7OGLM3xemTRrIw1SYnqDng+JOfyCOp1sYp/v9836W/volGRXhferL+IV0BZ0vj4UMQWb
X-Received: by 10.152.1.131 with SMTP id 3mr6857417lam.89.1418259890788; Wed,
	10 Dec 2014 17:04:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.7.132 with HTTP; Wed, 10 Dec 2014 17:04:30 -0800 (PST)
In-Reply-To: <20141211005509.GN25677@wotan.suse.de>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
	<20141211005509.GN25677@wotan.suse.de>
From: Andy Lutomirski <luto@amacapital.net>
Date: Wed, 10 Dec 2014 17:04:30 -0800
Message-ID: <CALCETrVNhPvKENkcKu9dbfrBTfFxrknEq96Go8jCy6nOqURxjw@mail.gmail.com>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: Juergen Gross <jgross@suse.com>, X86 ML <x86@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 4:55 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Wed, Dec 10, 2014 at 03:51:48PM -0800, Andy Lutomirski wrote:
>> On Wed, Dec 10, 2014 at 3:34 PM, Luis R. Rodriguez
>> <mcgrof@do-not-panic.com> wrote:
>> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
>> >
>> > Xen has support for splitting heavy work work into a series
>> > of hypercalls, called multicalls, and preempting them through
>> > what Xen calls continuation [0]. Despite this though without
>> > CONFIG_PREEMPT preemption won't happen and while enabling
>> > CONFIG_RT_GROUP_SCHED can at times help its not enough to
>> > make a system usable. Such is the case for example when
>> > creating a > 50 GiB HVM guest, we can get softlockups [1] with:.
>> >
>> > kernel: [  802.084335] BUG: soft lockup - CPU#1 stuck for 22s! [xend:31351]
>> >
>> > The softlock up triggers on the TASK_UNINTERRUPTIBLE hanger check
>> > (default 120 seconds), on the Xen side in this particular case
>> > this happens when the following Xen hypervisor code is used:
>> >
>> > xc_domain_set_pod_target() -->
>> >   do_memory_op() -->
>> >     arch_memory_op() -->
>> >       p2m_pod_set_mem_target()
>> >         -- long delay (real or emulated) --
>> >
>> > This happens on arch_memory_op() on the XENMEM_set_pod_target memory
>> > op even though arch_memory_op() can handle continuation via
>> > hypercall_create_continuation() for example.
>> >
>> > Machines over 50 GiB of memory are on high demand and hard to come
>> > by so to help replicate this sort of issue long delays on select
>> > hypercalls have been emulated in order to be able to test this on
>> > smaller machines [2].
>> >
>> > On one hand this issue can be considered as expected given that
>> > CONFIG_PREEMPT=n is used however we have forced voluntary preemption
>> > precedent practices in the kernel even for CONFIG_PREEMPT=n through
>> > the usage of cond_resched() sprinkled in many places. To address
>> > this issue with Xen hypercalls though we need to find a way to aid
>> > to the schedular in the middle of hypercalls. We are motivated to
>> > address this issue on CONFIG_PREEMPT=n as otherwise the system becomes
>> > rather unresponsive for long periods of time; in the worst case, at least
>> > only currently by emulating long delays on select io disk bound
>> > hypercalls, this can lead to filesystem corruption if the delay happens
>> > for example on SCHEDOP_remote_shutdown (when we call 'xl <domain> shutdown').
>> >
>> > We can address this problem by trying to check if we should schedule
>> > on the xen timer in the middle of a hypercall on the return from the
>> > timer interrupt. We want to be careful to not always force voluntary
>> > preemption though so to do this we only selectively enable preemption
>> > on very specific xen hypercalls.
>> >
>> > This enables hypercall preemption by selectively forcing checks for
>> > voluntary preempting only on ioctl initiated private hypercalls
>> > where we know some folks have run into reported issues [1].
>> >
>> > [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
>> > [1] https://bugzilla.novell.com/show_bug.cgi?id=861093
>> > [2] http://ftp.suse.com/pub/people/mcgrof/xen/emulate-long-xen-hypercalls.patch
>> >
>> > Based on original work by: David Vrabel <david.vrabel@citrix.com>
>> > Cc: Borislav Petkov <bp@suse.de>
>> > Cc: David Vrabel <david.vrabel@citrix.com>
>> > Cc: Thomas Gleixner <tglx@linutronix.de>
>> > Cc: Ingo Molnar <mingo@redhat.com>
>> > Cc: "H. Peter Anvin" <hpa@zytor.com>
>> > Cc: x86@kernel.org
>> > Cc: Andy Lutomirski <luto@amacapital.net>
>> > Cc: Steven Rostedt <rostedt@goodmis.org>
>> > Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
>> > Cc: Jan Beulich <JBeulich@suse.com>
>> > Cc: linux-kernel@vger.kernel.org
>> > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
>> > ---
>> >  arch/x86/kernel/entry_32.S | 21 +++++++++++++++++++++
>> >  arch/x86/kernel/entry_64.S | 17 +++++++++++++++++
>> >  drivers/xen/Makefile       |  2 +-
>> >  drivers/xen/preempt.c      | 17 +++++++++++++++++
>> >  drivers/xen/privcmd.c      |  2 ++
>> >  include/xen/xen-ops.h      | 26 ++++++++++++++++++++++++++
>> >  6 files changed, 84 insertions(+), 1 deletion(-)
>> >  create mode 100644 drivers/xen/preempt.c
>> >
>> > diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
>> > index 344b63f..40b5c0c 100644
>> > --- a/arch/x86/kernel/entry_32.S
>> > +++ b/arch/x86/kernel/entry_32.S
>> > @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
>> >  ENTRY(xen_do_upcall)
>> >  1:     mov %esp, %eax
>> >         call xen_evtchn_do_upcall
>> > +#ifdef CONFIG_PREEMPT
>> >         jmp  ret_from_intr
>> > +#else
>> > +       GET_THREAD_INFO(%ebp)
>> > +#ifdef CONFIG_VM86
>> > +       movl PT_EFLAGS(%esp), %eax      # mix EFLAGS and CS
>> > +       movb PT_CS(%esp), %al
>> > +       andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
>> > +#else
>> > +       movl PT_CS(%esp), %eax
>> > +       andl $SEGMENT_RPL_MASK, %eax
>> > +#endif
>> > +       cmpl $USER_RPL, %eax
>> > +       jae resume_userspace            # returning to v8086 or userspace
>> > +       DISABLE_INTERRUPTS(CLBR_ANY)
>> > +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
>> > +       jz resume_kernel
>> > +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
>> > +       call cond_resched_irq
>> > +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
>> > +       jmp resume_kernel
>> > +#endif /* CONFIG_PREEMPT */
>> >         CFI_ENDPROC
>> >  ENDPROC(xen_hypervisor_callback)
>> >
>> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
>> > index c0226ab..0ccdd06 100644
>> > --- a/arch/x86/kernel/entry_64.S
>> > +++ b/arch/x86/kernel/entry_64.S
>> > @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
>> >         popq %rsp
>> >         CFI_DEF_CFA_REGISTER rsp
>> >         decl PER_CPU_VAR(irq_count)
>> > +#ifdef CONFIG_PREEMPT
>> >         jmp  error_exit
>> > +#else
>> > +       movl %ebx, %eax
>> > +       RESTORE_REST
>> > +       DISABLE_INTERRUPTS(CLBR_NONE)
>> > +       TRACE_IRQS_OFF
>> > +       GET_THREAD_INFO(%rcx)
>> > +       testl %eax, %eax
>> > +       je error_exit_user
>> > +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
>> > +       jz retint_kernel
>>
>> I think I understand this part.
>>
>> > +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
>>
>> Why?  Is the issue that, if preemptible hypercalls nest, you don't
>> want to preempt again?
>
>
> So this callback on the xen timer, without the CPU variable
> we would not be able to selectively preempt specific hypercalls
> and we'd a no-preempt kernel fully preemptive.
>
> I asked the same question, see:
>
> https://lkml.org/lkml/2014/12/3/756
>
>>
>> > +       call cond_resched_irq
>>
>> On !CONFIG_PREEMPT, there's no preempt_disable, right?  So how do you
>> guarantee that you don't preempt something you shouldn't?
>
> Not sure I follow, but in essence this is no different then the use
> of cond_resched() on !CONFIG_PREEMPT, the only thing here is we are
> in interrupt context. If this is about abuse of making !CONFIG_PREEMPT
> voluntarily preemptive at select points then I had similar concerns
> and David pointed out to me the wide use of cond_resched() on the
> kernel.
>
>> Is the idea
>> that these events will only fire nested *directly* inside a
>> preemptible hypercall?
>
> Yeah its the timer interrupt that would trigger the above.
>
>> Also, should you check that IRQs were on when
>> the event fired?  (Are they on in pt_regs?)
>
> Right before this xen_evtchn_do_upcall() is issued, which
> saves pt_regs and then restores them.
>
>> > +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
>> > +       jmp retint_kernel
>> > +#endif /* CONFIG_PREEMPT */
>> >         CFI_ENDPROC
>>
>> All that being said, this is IMO a bit gross.
>
> That was my first reaction hence my original attempt to try to get away from
> this. I've learned David also tried to not go down this route too before,
> more on this below.
>
>>  You've added a bunch of
>> asm that's kind of like a parallel error_exit,
>
> yeah.. I first tried to macro'tize this but it looked hairy, if we
> wanted to do that... (although the name probably ain't best)
>
> 32-bit:
> .macro test_from_kernel kernel_ret:req
>         GET_THREAD_INFO(%ebp)
> #ifdef CONFIG_VM86
>         movl PT_EFLAGS(%esp), %eax      # mix EFLAGS and CS
>         movb PT_CS(%esp), %al
>         andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
> #else
>         /*
>          * We can be coming here from child spawned by kernel_thread().
>          */
>         movl PT_CS(%esp), %eax
>         andl $SEGMENT_RPL_MASK, %eax
> #endif
>         cmpl $USER_RPL, %eax
>         jb \kernel_ret
> .endm
>
> 64-bit:
>         .macro test_from_kernel kernel_ret:req
>         movl %ebx,%eax
>         RESTORE_REST
>         DISABLE_INTERRUPTS(CLBR_NONE)
>         TRACE_IRQS_OFF
>         GET_THREAD_INFO(%rcx)
>         testl %eax,%eax
>         jne \kernel_ret
>         .endm
>
>> and the error entry and
>> exit code is hairy enough that this scares me.
>
> yeah...
>
>>  Can you do this mostly in C instead?  This would look a nicer if it could be:
>>
>>     call xen_evtchn_do_upcall
>>     popq %rsp
>>     CFI_DEF_CFA_REGISTER rsp
>>     decl PER_CPU_VAR(irq_count)
>> +  call xen_end_upcall
>>     jmp error_exit
>
> It seems David tried this originally eons ago:
>
> http://lists.xen.org/archives/html/xen-devel/2014-02/msg01101.html
>
> and the strategy was shifted based on Jan's feedback that we could
> not sched as we're on the IRQ stack. David evolved the strategy
> to asm and to use preempt_schedule_irq(), this new iteratin just
> revisits the same old but tries to generalize scheduling on IRQ
> context on very special circumstances.

Indeed.  But look more closely at my proposed one-line asm patch:
we're not on the irq stack.

Also, to make this more obviously safe wrt preempting at the wrong
time, would it be possible to check regs->ip and make sure it's
pointing exactly where you expect before scheduling?  (You'd need one
more line of asm to get pt_regs in xen_end_upcall.)

--Andy, the stack switching maestro extraordinaire :)

>
>> Where xen_end_upcall would be witten in C, nokprobes and notrace (if
>> needed) and would check pt_regs and whatever else and just call
>> schedule if needed?
>
> If there's a way to do it it'd be great. I am not sure if we can though.
>
>   Luis



-- 
Andy Lutomirski
AMA Capital Management, LLC

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 01:42:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 01: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 1Xysll-00074r-By; Thu, 11 Dec 2014 01:42: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 1Xyslk-000744-HA
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 01:42:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	77/46-09842-776F8845; Thu, 11 Dec 2014 01:42:15 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418262134!14772927!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1338 invoked from network); 11 Dec 2014 01:42:14 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-21.messagelabs.com with SMTP;
	11 Dec 2014 01:42:14 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 10 Dec 2014 17:42:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,554,1413270000"; d="scan'208";a="645797408"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga002.fm.intel.com with ESMTP; 10 Dec 2014 17:42:11 -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, 11 Dec 2014 09:41: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; Thu, 11 Dec 2014 09:41:45 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAF26eCAAB3OgIABbe5Q
Date: Thu, 11 Dec 2014 01:41:44 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
In-Reply-To: <20141210105505.GA64596@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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Wednesday, December 10, 2014 6:55 PM
> 
> At 01:14 +0000 on 10 Dec (1418170461), Tian, Kevin wrote:
> > > From: Tim Deegan [mailto:tim@xen.org]
> > > Sent: Tuesday, December 09, 2014 6:47 PM
> > >
> > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > > Hi all,
> > > >
> > > >    As you can see, we are pushing our XenGT patches to the upstream.
> One
> > > > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > > > device model.
> > > >
> > > >    Here we may have 2 similar solutions:
> > > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there
> was
> > > no
> > > > usage at that time.
> > >
> > > It's been suggested before that we should revive this hypercall, and I
> > > don't think it's a good idea.  Whenever a domain needs to know the
> > > actual MFN of another domain's memory it's usually because the
> > > security model is problematic.  In particular, finding the MFN is
> > > usually followed by a brute-force mapping from a dom0 process, or by
> > > passing the MFN to a device for unprotected DMA.
> >
> > In our case it's not because the security model is problematic. It's
> > because GPU virtualization is done in Dom0 while the memory virtualization
> > is done in hypervisor. We need a means to query GPFN->MFN so we can
> > setup shadow GPU page table in Dom0 correctly, for a VM.
> 
> I don't think we understand each other.  Let me try to explain what I
> mean.  My apologies if this sounds patronising; I'm just trying to be
> as clear as I can.

Thanks for your explanation. This is a very helpful discussion. :-)

> 
> It is Xen's job to isolate VMs from each other.  As part of that, Xen
> uses the MMU, nested paging, and IOMMUs to control access to RAM.  Any
> software component that can pass a raw MFN to hardware breaks that
> isolation, because Xen has no way of controlling what that component
> can do (including taking over the hypervisor).  This is why I am
> afraid when developers ask for GFN->MFN translation functions.

When I agree Xen's job absolutely, the isolation is also required in different
layers, regarding to who controls the resource and where the virtualization 
happens. For example talking about I/O virtualization, Dom0 or driver domain 
needs to isolate among backend drivers to avoid one backend interfering 
with another. Xen doesn't know such violation, since it only knows it's Dom0
wants to access a VM's page.

btw curious of how worse exposing GFN->MFN translation compared to
allowing mapping other VM's GFN? If exposing GFN->MFN is under the
same permission control as mapping, would it avoid your worry here?

> 
> So if the XenGT model allowed the backend component to (cause the GPU
> to) perform arbitrary DMA without IOMMU checks, then that component
> would have complete access to the system and (from a security pov)
> might as well be running in the hypervisor.  That would be very
> problematic, but AFAICT that's not what's going on.  From your reply
> on the other thread it seems like the GPU is behind the IOMMU, so
> that's OK. :)
> 
> When the backend component gets a GFN from the guest, it wants an
> address that it can give to the GPU for DMA that will map the right
> memory.  That address must be mapped in the IOMMU tables that the GPU
> will be using, which means the IOMMU tables of the backend domain,
> IIUC[1].  So the hypercall it needs is not "give me the MFN that matches
> this GFN" but "please map this GFN into my IOMMU tables".

Here "please map this GFN into my IOMMU tables" actually breaks the
IOMMU isolation. IOMMU is designed for serving DMA requests issued
by an exclusive VM, so IOMMU page table can restrict that VM's attempts
strictly.

To map multiple VM's GFNs into one IOMMU table, the 1st thing is to
avoid GFN conflictions to make it functional. We thought about this approach
previously, e.g. by reserving highest 3 bits of GFN as VMID, so one IOMMU
page table can be used to combine multi-VM's page table together. However
doing so have two limitations:

a) it still requires write-protect guest GPU page table, and maintain a shadow
GPU page table by translate from real GFN to pseudo GFN (plus VMID), which
doesn't save any engineering effort in the device model part

b) it breaks the designed isolation intrinsic of IOMMU. In such case, IOMMU
can't isolate multiple VMs by itself, since a DMA request can target any 
pseudo GFN if valid in the page table. We have to rely on the audit in the 
backend component in Dom0 to ensure the isolation. So even by using IOMMU,
it loses the isolation intention as you described earlier.

c) this introduces tricky logic in IOMMU driver to handle such non-standard
multiplexed page table style. 

w/o a SR-IOV implementation (so each VF has its own IOMMU page table),
I don't see using IOMMU can help isolation here.

> 
> Asking for the MFN will only work if the backend domain's IOMMU
> tables have an existing 1:1 r/w mapping of all guest RAM, which
> happens to be the case if the backend component is in dom0 _and_ dom0
> is PV _and_ we're not using strict IOMMU tables.  Restricting XenGT to
> work in only those circumstances would be short-sighted, not only
> because it would mean XenGT could never work as a driver domain, but
> also because it seems like PVH dom0 is going to be the default at some
> point.

yes, this is a good feedback we didn't think about before. So far the reason
why XenGT can work is because we use default IOMMU setting which set
up a 1:1 r/w mapping for all possible RAM, so when GPU hits a MFN thru
shadow GPU page table, IOMMU is essentially bypassed. However like
you said, if IOMMU page table is restricted to dom0's memory, or is not
1:1 identity mapping, XenGT will be broken.

However I don't see a good solution for this, except using multiplexed
IOMMU page table aforementioned, which however doesn't look like
a sane design to me.

> 
> If the existing hypercalls that make IOMMU mappings are not right for
> XenGT then we can absolutely consider adding some more.  But we need
> to talk about what policy Xen will enforce on the mapping requests.
> If the shared backend is allowed to map any page of any VM, then it
> can easily take control of any VM on the host (even though the IOMMU
> will prevent it from taking over the hypervisor itself).  The
> absolute minumum we should allow here is some toolstack-controlled
> list of which VMs the XenGT backend is serving, so that it can refuse
> to map other VMs' memory (like an extension of IS_PRIV_FOR, which does
> this job for Qemu).

for mapping and accessing other guest's memory, I don't think we 
need any new interface atop existing ones. Just similar to other backend
drivers, we can leverage the same permission control.

please note here the requirement of exposing p2m here, is really to
setup GPU page table so a guest GPU workload can be directly executed
by the GPU.

> 
> I would also strongly advise using privilege separation in the backend
> between the GPUPT shadow code (which needs mapping rights and is
> trusted to maintain isolation between the VMs that are sharing the
> GPU) and the rest of the XenGT backend (which doesn't/isn't).  But
> that's outside my remit as a hypervisor maintainer so it goes no
> further than an "I told you so". :)

We're open to suggestions making our code better, but could you 
elaborate a bit what exactly privilege separation you meant here? :-)

> 
> Cheers,
> 
> Tim.
> 
> [1] That is, AIUI this GPU doesn't context-switch which set of IOMMU
>     tables it's using for DMA, SR-IOV-style, and that's why you need a
>     software component in the first place.

yes, there's only one IOMMU dedicated for GPU, and it's impractical to
switch the IOMMU page table given concurrent access to graphics
memory from different VCPUs and different render engines within GPU.

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 Dec 11 01:42:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 01: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 1Xysll-00074r-By; Thu, 11 Dec 2014 01:42: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 1Xyslk-000744-HA
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 01:42:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	77/46-09842-776F8845; Thu, 11 Dec 2014 01:42:15 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418262134!14772927!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1338 invoked from network); 11 Dec 2014 01:42:14 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-21.messagelabs.com with SMTP;
	11 Dec 2014 01:42:14 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 10 Dec 2014 17:42:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,554,1413270000"; d="scan'208";a="645797408"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga002.fm.intel.com with ESMTP; 10 Dec 2014 17:42:11 -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, 11 Dec 2014 09:41: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; Thu, 11 Dec 2014 09:41:45 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAF26eCAAB3OgIABbe5Q
Date: Thu, 11 Dec 2014 01:41:44 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
In-Reply-To: <20141210105505.GA64596@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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Wednesday, December 10, 2014 6:55 PM
> 
> At 01:14 +0000 on 10 Dec (1418170461), Tian, Kevin wrote:
> > > From: Tim Deegan [mailto:tim@xen.org]
> > > Sent: Tuesday, December 09, 2014 6:47 PM
> > >
> > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > > Hi all,
> > > >
> > > >    As you can see, we are pushing our XenGT patches to the upstream.
> One
> > > > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> > > > device model.
> > > >
> > > >    Here we may have 2 similar solutions:
> > > >    1> Paul told me(and thank you, Paul :)) that there used to be a
> > > > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in
> > > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there
> was
> > > no
> > > > usage at that time.
> > >
> > > It's been suggested before that we should revive this hypercall, and I
> > > don't think it's a good idea.  Whenever a domain needs to know the
> > > actual MFN of another domain's memory it's usually because the
> > > security model is problematic.  In particular, finding the MFN is
> > > usually followed by a brute-force mapping from a dom0 process, or by
> > > passing the MFN to a device for unprotected DMA.
> >
> > In our case it's not because the security model is problematic. It's
> > because GPU virtualization is done in Dom0 while the memory virtualization
> > is done in hypervisor. We need a means to query GPFN->MFN so we can
> > setup shadow GPU page table in Dom0 correctly, for a VM.
> 
> I don't think we understand each other.  Let me try to explain what I
> mean.  My apologies if this sounds patronising; I'm just trying to be
> as clear as I can.

Thanks for your explanation. This is a very helpful discussion. :-)

> 
> It is Xen's job to isolate VMs from each other.  As part of that, Xen
> uses the MMU, nested paging, and IOMMUs to control access to RAM.  Any
> software component that can pass a raw MFN to hardware breaks that
> isolation, because Xen has no way of controlling what that component
> can do (including taking over the hypervisor).  This is why I am
> afraid when developers ask for GFN->MFN translation functions.

When I agree Xen's job absolutely, the isolation is also required in different
layers, regarding to who controls the resource and where the virtualization 
happens. For example talking about I/O virtualization, Dom0 or driver domain 
needs to isolate among backend drivers to avoid one backend interfering 
with another. Xen doesn't know such violation, since it only knows it's Dom0
wants to access a VM's page.

btw curious of how worse exposing GFN->MFN translation compared to
allowing mapping other VM's GFN? If exposing GFN->MFN is under the
same permission control as mapping, would it avoid your worry here?

> 
> So if the XenGT model allowed the backend component to (cause the GPU
> to) perform arbitrary DMA without IOMMU checks, then that component
> would have complete access to the system and (from a security pov)
> might as well be running in the hypervisor.  That would be very
> problematic, but AFAICT that's not what's going on.  From your reply
> on the other thread it seems like the GPU is behind the IOMMU, so
> that's OK. :)
> 
> When the backend component gets a GFN from the guest, it wants an
> address that it can give to the GPU for DMA that will map the right
> memory.  That address must be mapped in the IOMMU tables that the GPU
> will be using, which means the IOMMU tables of the backend domain,
> IIUC[1].  So the hypercall it needs is not "give me the MFN that matches
> this GFN" but "please map this GFN into my IOMMU tables".

Here "please map this GFN into my IOMMU tables" actually breaks the
IOMMU isolation. IOMMU is designed for serving DMA requests issued
by an exclusive VM, so IOMMU page table can restrict that VM's attempts
strictly.

To map multiple VM's GFNs into one IOMMU table, the 1st thing is to
avoid GFN conflictions to make it functional. We thought about this approach
previously, e.g. by reserving highest 3 bits of GFN as VMID, so one IOMMU
page table can be used to combine multi-VM's page table together. However
doing so have two limitations:

a) it still requires write-protect guest GPU page table, and maintain a shadow
GPU page table by translate from real GFN to pseudo GFN (plus VMID), which
doesn't save any engineering effort in the device model part

b) it breaks the designed isolation intrinsic of IOMMU. In such case, IOMMU
can't isolate multiple VMs by itself, since a DMA request can target any 
pseudo GFN if valid in the page table. We have to rely on the audit in the 
backend component in Dom0 to ensure the isolation. So even by using IOMMU,
it loses the isolation intention as you described earlier.

c) this introduces tricky logic in IOMMU driver to handle such non-standard
multiplexed page table style. 

w/o a SR-IOV implementation (so each VF has its own IOMMU page table),
I don't see using IOMMU can help isolation here.

> 
> Asking for the MFN will only work if the backend domain's IOMMU
> tables have an existing 1:1 r/w mapping of all guest RAM, which
> happens to be the case if the backend component is in dom0 _and_ dom0
> is PV _and_ we're not using strict IOMMU tables.  Restricting XenGT to
> work in only those circumstances would be short-sighted, not only
> because it would mean XenGT could never work as a driver domain, but
> also because it seems like PVH dom0 is going to be the default at some
> point.

yes, this is a good feedback we didn't think about before. So far the reason
why XenGT can work is because we use default IOMMU setting which set
up a 1:1 r/w mapping for all possible RAM, so when GPU hits a MFN thru
shadow GPU page table, IOMMU is essentially bypassed. However like
you said, if IOMMU page table is restricted to dom0's memory, or is not
1:1 identity mapping, XenGT will be broken.

However I don't see a good solution for this, except using multiplexed
IOMMU page table aforementioned, which however doesn't look like
a sane design to me.

> 
> If the existing hypercalls that make IOMMU mappings are not right for
> XenGT then we can absolutely consider adding some more.  But we need
> to talk about what policy Xen will enforce on the mapping requests.
> If the shared backend is allowed to map any page of any VM, then it
> can easily take control of any VM on the host (even though the IOMMU
> will prevent it from taking over the hypervisor itself).  The
> absolute minumum we should allow here is some toolstack-controlled
> list of which VMs the XenGT backend is serving, so that it can refuse
> to map other VMs' memory (like an extension of IS_PRIV_FOR, which does
> this job for Qemu).

for mapping and accessing other guest's memory, I don't think we 
need any new interface atop existing ones. Just similar to other backend
drivers, we can leverage the same permission control.

please note here the requirement of exposing p2m here, is really to
setup GPU page table so a guest GPU workload can be directly executed
by the GPU.

> 
> I would also strongly advise using privilege separation in the backend
> between the GPUPT shadow code (which needs mapping rights and is
> trusted to maintain isolation between the VMs that are sharing the
> GPU) and the rest of the XenGT backend (which doesn't/isn't).  But
> that's outside my remit as a hypervisor maintainer so it goes no
> further than an "I told you so". :)

We're open to suggestions making our code better, but could you 
elaborate a bit what exactly privilege separation you meant here? :-)

> 
> Cheers,
> 
> Tim.
> 
> [1] That is, AIUI this GPU doesn't context-switch which set of IOMMU
>     tables it's using for DMA, SR-IOV-style, and that's why you need a
>     software component in the first place.

yes, there's only one IOMMU dedicated for GPU, and it's impractical to
switch the IOMMU page table given concurrent access to graphics
memory from different VCPUs and different render engines within GPU.

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 Dec 11 01:45:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 01:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xysom-0007K5-Vd; Thu, 11 Dec 2014 01:45:24 +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 1Xysol-0007Jz-Az
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 01:45:23 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	ED/4B-05632-237F8845; Thu, 11 Dec 2014 01:45:22 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418262321!12518443!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2267 invoked from network); 11 Dec 2014 01:45:21 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-31.messagelabs.com with SMTP;
	11 Dec 2014 01:45:21 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 10 Dec 2014 17:45:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="427589509"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by FMSMGA003.fm.intel.com with ESMTP; 10 Dec 2014 17:34:31 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 11 Dec 2014 09:45:10 +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; Thu, 11 Dec 2014 09:45:08 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAF26eCAABiOgIABg7RA
Date: Thu, 11 Dec 2014 01:45:09 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126116756@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<54883031020000780004E7EC@mail.emea.novell.com>
In-Reply-To: <54883031020000780004E7EC@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: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, December 10, 2014 6:36 PM
> 
> >>> On 10.12.14 at 02:14, <kevin.tian@intel.com> wrote:
> >>  From: Tim Deegan [mailto:tim@xen.org]
> >> It's been suggested before that we should revive this hypercall, and I
> >> don't think it's a good idea.  Whenever a domain needs to know the
> >> actual MFN of another domain's memory it's usually because the
> >> security model is problematic.  In particular, finding the MFN is
> >> usually followed by a brute-force mapping from a dom0 process, or by
> >> passing the MFN to a device for unprotected DMA.
> >
> > In our case it's not because the security model is problematic. It's
> > because GPU virtualization is done in Dom0 while the memory virtualization
> > is done in hypervisor.
> 
> Which by itself is a questionable design decision.
> 

I don't think we want to put a ~20K LOC device model in hypervisor.

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 Dec 11 01:45:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 01:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xysom-0007K5-Vd; Thu, 11 Dec 2014 01:45:24 +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 1Xysol-0007Jz-Az
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 01:45:23 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	ED/4B-05632-237F8845; Thu, 11 Dec 2014 01:45:22 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418262321!12518443!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2267 invoked from network); 11 Dec 2014 01:45:21 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-31.messagelabs.com with SMTP;
	11 Dec 2014 01:45:21 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 10 Dec 2014 17:45:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="427589509"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by FMSMGA003.fm.intel.com with ESMTP; 10 Dec 2014 17:34:31 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 11 Dec 2014 09:45:10 +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; Thu, 11 Dec 2014 09:45:08 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAF26eCAABiOgIABg7RA
Date: Thu, 11 Dec 2014 01:45:09 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126116756@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<54883031020000780004E7EC@mail.emea.novell.com>
In-Reply-To: <54883031020000780004E7EC@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: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, December 10, 2014 6:36 PM
> 
> >>> On 10.12.14 at 02:14, <kevin.tian@intel.com> wrote:
> >>  From: Tim Deegan [mailto:tim@xen.org]
> >> It's been suggested before that we should revive this hypercall, and I
> >> don't think it's a good idea.  Whenever a domain needs to know the
> >> actual MFN of another domain's memory it's usually because the
> >> security model is problematic.  In particular, finding the MFN is
> >> usually followed by a brute-force mapping from a dom0 process, or by
> >> passing the MFN to a device for unprotected DMA.
> >
> > In our case it's not because the security model is problematic. It's
> > because GPU virtualization is done in Dom0 while the memory virtualization
> > is done in hypervisor.
> 
> Which by itself is a questionable design decision.
> 

I don't think we want to put a ~20K LOC device model in hypervisor.

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 Dec 11 01:52:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 01: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 1Xysve-0007dW-RX; Thu, 11 Dec 2014 01:52:30 +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 1Xysvd-0007dR-1g
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 01:52:29 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	AD/DC-24859-CD8F8845; Thu, 11 Dec 2014 01:52:28 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418262746!12403407!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 15311 invoked from network); 11 Dec 2014 01:52:26 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-31.messagelabs.com with SMTP;
	11 Dec 2014 01:52:26 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 10 Dec 2014 17:52:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,555,1413270000"; d="scan'208";a="645800865"
Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103])
	by fmsmga002.fm.intel.com with ESMTP; 10 Dec 2014 17:52:22 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 11 Dec 2014 09:51:00 +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, 11 Dec 2014 09:50:59 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAAFMICAAAGqAIAAAayAgAADWoCAAAQmAIABb3PAgAAJAoCAAYuHQA==
Date: Thu, 11 Dec 2014 01:50:58 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126116787@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
	<1418124543.14361.27.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD0257859BB@AMSPEX01CL01.citrite.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114D11@SHSMSX101.ccr.corp.intel.com>
	<1418206277.19809.48.camel@citrix.com>
In-Reply-To: <1418206277.19809.48.camel@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: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Wednesday, December 10, 2014 6:11 PM
> 
> On Wed, 2014-12-10 at 01:48 +0000, Tian, Kevin wrote:
> > I'm not familiar with Arm architecture, but based on a brief reading it's
> > for the assigned case where the MMU is exclusive owned by a VM, so
> > some type of MMU virtualization is required and it's straightforward.
> 
> > However XenGT is a shared GPU usage:
> >
> > - a global GPU page table is partitioned among VMs. a shared shadow
> > global page table is maintained, containing translations for multiple
> > VMs simultaneously based on partitioning information
> > - multiple per-process GPU page tables are created by each VM, and
> > multiple shadow per-process GPU page tables are created correspondingly.
> > shadow page table is switched when doing GPU context switch, same as
> > what we did for CPU shadow page table.
> 
> None of that sounds to me to be impossible to do in the remoteproc
> model, perhaps it needs some extensions from its initial core feature
> set but I see no reason why it couldn't maintain multiple sets of page
> tables, each tagged with an owning domain (for validation purposes) and
> a mechanism to switch between them, or to be able to manage partitioning
> of the GPU address space.

here we're talking about multiple GPU page tables on top of a 
IOMMU page table. Instead of one MMU unit concerned here in 
remoteproc.

> 
> > So you can see above shared MMU virtualization usage is very GPU
> > specific,
> 
> AIUI remoteproc is specific to a particular h/w device too, i.e. there
> is a device specific stub in the hypervisor which essentially knows how
> to implement set_pte for that bit of h/w, with appropriate safety and
> validation, as well as a write_cr3 type operation.
> 
> >  that's why we didn't put in Xen hypervisor, and thus additional
> > interface is required to get p2m mapping to assist our shadow GPU
> > page table usage.
> 
> There is a great reluctance among several maintainers to expose real
> hardware MFNs to VMs (including dom0 and backend driver domains).
> 
> I think you need to think very carefully about possible ways of avoiding
> the need for this. Yes, this might require some changes to your current
> mode/design.
> 

We're open to changes if necessary.

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 Dec 11 01:52:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 01: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 1Xysvi-0007dk-6v; Thu, 11 Dec 2014 01:52:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maomingya928@gmail.com>) id 1Xysvg-0007dd-LD
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 01:52:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	78/57-25276-0E8F8845; Thu, 11 Dec 2014 01:52:32 +0000
X-Env-Sender: maomingya928@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418262750!14812754!1
X-Originating-IP: [209.85.220.47]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18775 invoked from network); 11 Dec 2014 01:52:31 -0000
Received: from mail-pa0-f47.google.com (HELO mail-pa0-f47.google.com)
	(209.85.220.47)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 01:52:31 -0000
Received: by mail-pa0-f47.google.com with SMTP id kq14so3985020pab.34
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 17:52:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent
	:mime-version:content-type:content-transfer-encoding;
	bh=QJSX/iQRU5or/QVMJ3YHL1B4BiJqLq5Q7nNLvVwVgYo=;
	b=DhD3f0dGsaHFtqV1zOYO9ckP1SWJApyFdwuyjTKh4Q8eXHeLPm5j6+2YY9X5hVyiax
	BZVd0G1csQpu8OadCD/6EBP70msZG8x5zryZsc/PJsXIqe4YLi+ZdQNDrStELLJ3F3E8
	MAVVJwzNQJ1dUvE10lsy+7Bfx7062ptswpcBabe8F3yVpk6vNNPBWIjhm0MGyexrJ0xs
	Jv9uLm8zSYRPDObgZNJHGZdfbwmf9KyH5StJJpBytaij9gpPMI5cqS/AluK5gv3C6gvO
	efKkV1ZzQG91fLNngC/d8pYM7ApDp/Am6ipgZzGYRAsHJEc1ilb+B0ggo1E3xkklQiab
	dPmw==
X-Received: by 10.68.236.163 with SMTP id uv3mr1585708pbc.5.1418262749759;
	Wed, 10 Dec 2014 17:52:29 -0800 (PST)
Received: from [10.0.1.100] ([202.55.93.170])
	by mx.google.com with ESMTPSA id c5sm948411pdb.83.2014.12.10.17.52.28
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 10 Dec 2014 17:52:29 -0800 (PST)
From: "Mao Mingya" <maomingya928@gmail.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
Date: Thu, 11 Dec 2014 01:52:24 +0000
Message-Id: <em10f4478b-5649-4f26-a846-8d4f8298c95f@sgp1030c>
In-Reply-To: <1418204839.19809.30.camel@citrix.com>
User-Agent: eM_Client/6.0.21040.0
Mime-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] arch arm qemu compile erro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mao Mingya <maomingya928@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



------ Original Message ------
From: "Ian Campbell" <Ian.Campbell@citrix.com>
To: "Mao Mingya" <maomingya928@gmail.com>
Cc: xen-devel@lists.xen.org
Sent: 10/12/2014 5:47:19 PM
Subject: Re: Re[2]: [Xen-devel] arch arm qemu compile erro

>Please don't top post.
>
>On Wed, 2014-12-10 at 07:09 +0000, Mao Mingya wrote:
>>  From the the arch arm, since the stubdom is not supported now. Does 
>>the
>>  device to be shared between doms have to be pv front/backend 
>>structure.
>
>Yes.
>
>There is no equivalent to the x86 "hvm" type guest, i.e. one which 
>looks
>to the guest like a real system, in the ARM version of Xen. On x86
>stub-qemu is primarily about providing these emulated system devices in
>a sandboxed environment. There are no emulated devices on ARM hence no
>need for qemu for this purpose, hence no stubdomains.
>
>qemu has a "second hat" when in a Xen system, which is that it can
>provide certain PV backends, we do use it for this purpose on ARM.
>
>>  To run the Linux on Dom0 and DomU. Could the qemu and pv backend run 
>>in
>>  the Dom0 at the same time?
>
>Yes.
>
>>       For example: for network, block device, serial console, the pv
>>  backend provides the device drive for DomU linux
>>       while qemu provides all other devices driver for DomU linux.
>
>Yes, qemu can be used to provide PV backends for: disk (using qdisk),
>framebuffer, kbd and mouse.
Thank you for the detail explanation.
What is the best pv backend on arch arm? qemu-upstream, 
qemu-xen-traditional, or anything else?
Is there any guild doc to get it work on arch arm?
>
>Ian.
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 01:52:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 01: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 1Xysve-0007dW-RX; Thu, 11 Dec 2014 01:52:30 +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 1Xysvd-0007dR-1g
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 01:52:29 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	AD/DC-24859-CD8F8845; Thu, 11 Dec 2014 01:52:28 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418262746!12403407!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 15311 invoked from network); 11 Dec 2014 01:52:26 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-31.messagelabs.com with SMTP;
	11 Dec 2014 01:52:26 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 10 Dec 2014 17:52:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,555,1413270000"; d="scan'208";a="645800865"
Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103])
	by fmsmga002.fm.intel.com with ESMTP; 10 Dec 2014 17:52:22 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 11 Dec 2014 09:51:00 +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, 11 Dec 2014 09:50:59 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAAFMICAAAGqAIAAAayAgAADWoCAAAQmAIABb3PAgAAJAoCAAYuHQA==
Date: Thu, 11 Dec 2014 01:50:58 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126116787@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net>
	<1418123464.14361.19.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net>
	<1418124543.14361.27.camel@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD0257859BB@AMSPEX01CL01.citrite.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114D11@SHSMSX101.ccr.corp.intel.com>
	<1418206277.19809.48.camel@citrix.com>
In-Reply-To: <1418206277.19809.48.camel@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: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Wednesday, December 10, 2014 6:11 PM
> 
> On Wed, 2014-12-10 at 01:48 +0000, Tian, Kevin wrote:
> > I'm not familiar with Arm architecture, but based on a brief reading it's
> > for the assigned case where the MMU is exclusive owned by a VM, so
> > some type of MMU virtualization is required and it's straightforward.
> 
> > However XenGT is a shared GPU usage:
> >
> > - a global GPU page table is partitioned among VMs. a shared shadow
> > global page table is maintained, containing translations for multiple
> > VMs simultaneously based on partitioning information
> > - multiple per-process GPU page tables are created by each VM, and
> > multiple shadow per-process GPU page tables are created correspondingly.
> > shadow page table is switched when doing GPU context switch, same as
> > what we did for CPU shadow page table.
> 
> None of that sounds to me to be impossible to do in the remoteproc
> model, perhaps it needs some extensions from its initial core feature
> set but I see no reason why it couldn't maintain multiple sets of page
> tables, each tagged with an owning domain (for validation purposes) and
> a mechanism to switch between them, or to be able to manage partitioning
> of the GPU address space.

here we're talking about multiple GPU page tables on top of a 
IOMMU page table. Instead of one MMU unit concerned here in 
remoteproc.

> 
> > So you can see above shared MMU virtualization usage is very GPU
> > specific,
> 
> AIUI remoteproc is specific to a particular h/w device too, i.e. there
> is a device specific stub in the hypervisor which essentially knows how
> to implement set_pte for that bit of h/w, with appropriate safety and
> validation, as well as a write_cr3 type operation.
> 
> >  that's why we didn't put in Xen hypervisor, and thus additional
> > interface is required to get p2m mapping to assist our shadow GPU
> > page table usage.
> 
> There is a great reluctance among several maintainers to expose real
> hardware MFNs to VMs (including dom0 and backend driver domains).
> 
> I think you need to think very carefully about possible ways of avoiding
> the need for this. Yes, this might require some changes to your current
> mode/design.
> 

We're open to changes if necessary.

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 Dec 11 01:52:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 01: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 1Xysvi-0007dk-6v; Thu, 11 Dec 2014 01:52:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maomingya928@gmail.com>) id 1Xysvg-0007dd-LD
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 01:52:32 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	78/57-25276-0E8F8845; Thu, 11 Dec 2014 01:52:32 +0000
X-Env-Sender: maomingya928@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418262750!14812754!1
X-Originating-IP: [209.85.220.47]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18775 invoked from network); 11 Dec 2014 01:52:31 -0000
Received: from mail-pa0-f47.google.com (HELO mail-pa0-f47.google.com)
	(209.85.220.47)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 01:52:31 -0000
Received: by mail-pa0-f47.google.com with SMTP id kq14so3985020pab.34
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 17:52:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent
	:mime-version:content-type:content-transfer-encoding;
	bh=QJSX/iQRU5or/QVMJ3YHL1B4BiJqLq5Q7nNLvVwVgYo=;
	b=DhD3f0dGsaHFtqV1zOYO9ckP1SWJApyFdwuyjTKh4Q8eXHeLPm5j6+2YY9X5hVyiax
	BZVd0G1csQpu8OadCD/6EBP70msZG8x5zryZsc/PJsXIqe4YLi+ZdQNDrStELLJ3F3E8
	MAVVJwzNQJ1dUvE10lsy+7Bfx7062ptswpcBabe8F3yVpk6vNNPBWIjhm0MGyexrJ0xs
	Jv9uLm8zSYRPDObgZNJHGZdfbwmf9KyH5StJJpBytaij9gpPMI5cqS/AluK5gv3C6gvO
	efKkV1ZzQG91fLNngC/d8pYM7ApDp/Am6ipgZzGYRAsHJEc1ilb+B0ggo1E3xkklQiab
	dPmw==
X-Received: by 10.68.236.163 with SMTP id uv3mr1585708pbc.5.1418262749759;
	Wed, 10 Dec 2014 17:52:29 -0800 (PST)
Received: from [10.0.1.100] ([202.55.93.170])
	by mx.google.com with ESMTPSA id c5sm948411pdb.83.2014.12.10.17.52.28
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 10 Dec 2014 17:52:29 -0800 (PST)
From: "Mao Mingya" <maomingya928@gmail.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
Date: Thu, 11 Dec 2014 01:52:24 +0000
Message-Id: <em10f4478b-5649-4f26-a846-8d4f8298c95f@sgp1030c>
In-Reply-To: <1418204839.19809.30.camel@citrix.com>
User-Agent: eM_Client/6.0.21040.0
Mime-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] arch arm qemu compile erro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mao Mingya <maomingya928@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



------ Original Message ------
From: "Ian Campbell" <Ian.Campbell@citrix.com>
To: "Mao Mingya" <maomingya928@gmail.com>
Cc: xen-devel@lists.xen.org
Sent: 10/12/2014 5:47:19 PM
Subject: Re: Re[2]: [Xen-devel] arch arm qemu compile erro

>Please don't top post.
>
>On Wed, 2014-12-10 at 07:09 +0000, Mao Mingya wrote:
>>  From the the arch arm, since the stubdom is not supported now. Does 
>>the
>>  device to be shared between doms have to be pv front/backend 
>>structure.
>
>Yes.
>
>There is no equivalent to the x86 "hvm" type guest, i.e. one which 
>looks
>to the guest like a real system, in the ARM version of Xen. On x86
>stub-qemu is primarily about providing these emulated system devices in
>a sandboxed environment. There are no emulated devices on ARM hence no
>need for qemu for this purpose, hence no stubdomains.
>
>qemu has a "second hat" when in a Xen system, which is that it can
>provide certain PV backends, we do use it for this purpose on ARM.
>
>>  To run the Linux on Dom0 and DomU. Could the qemu and pv backend run 
>>in
>>  the Dom0 at the same time?
>
>Yes.
>
>>       For example: for network, block device, serial console, the pv
>>  backend provides the device drive for DomU linux
>>       while qemu provides all other devices driver for DomU linux.
>
>Yes, qemu can be used to provide PV backends for: disk (using qdisk),
>framebuffer, kbd and mouse.
Thank you for the detail explanation.
What is the best pv backend on arch arm? qemu-upstream, 
qemu-xen-traditional, or anything else?
Is there any guild doc to get it work on arch arm?
>
>Ian.
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 02:04:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 02:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyt73-0000Fl-LR; Thu, 11 Dec 2014 02:04: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 1Xyt72-0000Fg-Ak
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 02:04:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	54/6F-09842-F9BF8845; Thu, 11 Dec 2014 02:04:15 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418263453!14461120!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 28475 invoked from network); 11 Dec 2014 02:04:14 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-3.tower-21.messagelabs.com with SMTP;
	11 Dec 2014 02:04:14 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 10 Dec 2014 18:02:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,555,1413270000"; d="scan'208";a="651961320"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
	by orsmga002.jf.intel.com with ESMTP; 10 Dec 2014 18:03:46 -0800
Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by
	PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 11 Dec 2014 10:03:19 +0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by
	KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 11 Dec 2014 10:03:19 +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, 11 Dec 2014 10:03:18 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
	support XEN_DOMCTL_set_rdm
Thread-Index: AQHQE5h0ZLDY7ZdMpU2g0ypuvrX7qZyIH8AggAAHPoCAAXy5kA==
Date: Thu, 11 Dec 2014 02:03:17 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1261167AC@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
	<20141210111213.GB64596@deinos.phlegethon.org>
In-Reply-To: <20141210111213.GB64596@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@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Wednesday, December 10, 2014 7:12 PM
> 
> Hi Kevin,
> 
> Thanks for taking the time to work through this.
> 
> At 03:39 +0000 on 10 Dec (1418179184), Tian, Kevin wrote:
> > 1. It's more efficient for new people to start from a small, well-defined task
> > in one area, and then spanning to adjacent areas gradually. Patience must
> > be given by the community to help them grow;
> >
> > 2. Unfortunately this RMRR effort grows from original two patches (very
> VT-d
> > focused) to now v8 17 patches spanning many areas (including hypercall,
> mmu,
> > domain builder, hvmloader, etc.), and thus imposing both long learning curve
> > and lots of frustrations being no achievement returned. Though having a
> complete
> > solution is desired, we need to help split the big task into step-by-step
> approach
> > as long as:
> > 	- the overall design is agreed
> > 	- each step is self-contained
> > 	- each step won't be wasted moving forward.
> > That way new people can see incremental achievements, instead of being hit
> > down before final success.
> >
> > Take this RMRR for example. Maybe we can split into steps like:
> >
> > 	step-1: setup RMRR identify mapping in hypervisor. fail if confliction. no
> > user space changes
> > 	step-2: expose RMRR knowledge to userspace and detect confliction in
> > domain builder and hvmloader
> > 	step-3: reconcile e820/mmio to avoid confliction in a best effort
> > 	step-4: miscellaneous enhancements, each can be ACK-ed individually:
> > 		- handle guest CPU access to RMRR regions
> > 		- handle conflicting RMRR regions
> > 		- handle group RMRRs
> > 		- re-enable USB device assignment
> >
> > That way Tiejun can focus on a self-contained task at one time, and then
> observe
> > continuous acknowledgements for his work. We don't need to claim RMRR
> fully
> > ready in Xen until last patch is accepted, but that at least provides a way to
> ack
> > new people when working on complex features and also allow for partial
> usage
> > on his work.
> 
> We had this discussion before and I think it was clear that the
> maintainers in general are unhappy with a partial solution.  OTOH, if
> we can agree on the roadmap, and Intel will commit to seeing the work
> through, it might be possible.  I think Jan is the man to convince
> here. :)

I think w/ last 8 series Tiejun has sent out, there's no doubt Intel commits
to make a complete work. :-)

> 
> Now since the code's not going to be in 4.5 anyway, it should be
> possible to _develop_ it in this manner, possibly in a private branch,
> even if the early stages aren't getting applied immediately.  We
> should be able to set up an rmrr branch on the public servers if that
> helps.  But again, that relies on having a design worked out in
> advance that both developers and maintainers are (within reason)
> committed to.

that's a good suggestion. We'll send out a design review today, and then
based on discussion we can see whether making sense to do such 
incremental way.

> 
> > 3. Maintainers sometimes didn't give definitive guidance to the new people,
> > and the high-level design is not closed in the 1st place. e.g. when I thought
> this v8
> > version has everyone agreed on the design, there's another comment from
> Jan
> > about using XENMEM_set_memory_map might be better, while back to Aug.
> > when Tiejun raised that option the answer is "I'm not sure". Note I
> understand
> > as a maintainer he might not have definite answers for all opens. But w/o a
> > definitive guide new people may waste lots of effort on chasing a wrong
> option,
> > which is definitely frustrating.
> 
> This is definitely a problem, and indeed frustrating for the
> developers.  We had similar difficulties with PVH development, where
> even though we planned the architecture up-front, once the code was
> written it became clear that a different approach would have been
> better.  I'm not sure what we can do here to make it more likely that
> we get the design right first time.

understand and reasonable.

> 
> I do think that figuring out the design in advance makes these
> projects much smoother, and it's something we're seeing more of.  For
> example David Vrabel's designs for the new event channel interface, or
> indeed the design doc he wrote about grant table locking, where review
> at the design stage may have avoided a bunch of implementation effort
> altogether.

yes. a formal review in advance would be lot better than mixing design 
comments in scattered in deep coding review comments. For this RMRR
example, Tiejun did send out some summary for his patch set, but not
abstracted enough to catch people's eye on key design opens. And having
a goal for 4.5 window really brought him hard time to balance code 
refactoring and learn new areas when each series was questioned with 
new design inputs.

> 
> > So I'd suggest for such non-trivial task for a new people, all maintainers in
> > involved areas (xen, mmu, tools, vtd, etc) should first spend time to agree
> > on the high level design. At that stage, let's skip the coding problems to save
> > both time.
> 
> That sounds like a very good idea to me.
> 

Thanks a lot,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 02:04:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 02:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyt73-0000Fl-LR; Thu, 11 Dec 2014 02:04: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 1Xyt72-0000Fg-Ak
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 02:04:16 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	54/6F-09842-F9BF8845; Thu, 11 Dec 2014 02:04:15 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418263453!14461120!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 28475 invoked from network); 11 Dec 2014 02:04:14 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-3.tower-21.messagelabs.com with SMTP;
	11 Dec 2014 02:04:14 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 10 Dec 2014 18:02:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,555,1413270000"; d="scan'208";a="651961320"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
	by orsmga002.jf.intel.com with ESMTP; 10 Dec 2014 18:03:46 -0800
Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by
	PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 11 Dec 2014 10:03:19 +0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by
	KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 11 Dec 2014 10:03:19 +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, 11 Dec 2014 10:03:18 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
	support XEN_DOMCTL_set_rdm
Thread-Index: AQHQE5h0ZLDY7ZdMpU2g0ypuvrX7qZyIH8AggAAHPoCAAXy5kA==
Date: Thu, 11 Dec 2014 02:03:17 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1261167AC@SHSMSX101.ccr.corp.intel.com>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
	<20141210111213.GB64596@deinos.phlegethon.org>
In-Reply-To: <20141210111213.GB64596@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@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Wednesday, December 10, 2014 7:12 PM
> 
> Hi Kevin,
> 
> Thanks for taking the time to work through this.
> 
> At 03:39 +0000 on 10 Dec (1418179184), Tian, Kevin wrote:
> > 1. It's more efficient for new people to start from a small, well-defined task
> > in one area, and then spanning to adjacent areas gradually. Patience must
> > be given by the community to help them grow;
> >
> > 2. Unfortunately this RMRR effort grows from original two patches (very
> VT-d
> > focused) to now v8 17 patches spanning many areas (including hypercall,
> mmu,
> > domain builder, hvmloader, etc.), and thus imposing both long learning curve
> > and lots of frustrations being no achievement returned. Though having a
> complete
> > solution is desired, we need to help split the big task into step-by-step
> approach
> > as long as:
> > 	- the overall design is agreed
> > 	- each step is self-contained
> > 	- each step won't be wasted moving forward.
> > That way new people can see incremental achievements, instead of being hit
> > down before final success.
> >
> > Take this RMRR for example. Maybe we can split into steps like:
> >
> > 	step-1: setup RMRR identify mapping in hypervisor. fail if confliction. no
> > user space changes
> > 	step-2: expose RMRR knowledge to userspace and detect confliction in
> > domain builder and hvmloader
> > 	step-3: reconcile e820/mmio to avoid confliction in a best effort
> > 	step-4: miscellaneous enhancements, each can be ACK-ed individually:
> > 		- handle guest CPU access to RMRR regions
> > 		- handle conflicting RMRR regions
> > 		- handle group RMRRs
> > 		- re-enable USB device assignment
> >
> > That way Tiejun can focus on a self-contained task at one time, and then
> observe
> > continuous acknowledgements for his work. We don't need to claim RMRR
> fully
> > ready in Xen until last patch is accepted, but that at least provides a way to
> ack
> > new people when working on complex features and also allow for partial
> usage
> > on his work.
> 
> We had this discussion before and I think it was clear that the
> maintainers in general are unhappy with a partial solution.  OTOH, if
> we can agree on the roadmap, and Intel will commit to seeing the work
> through, it might be possible.  I think Jan is the man to convince
> here. :)

I think w/ last 8 series Tiejun has sent out, there's no doubt Intel commits
to make a complete work. :-)

> 
> Now since the code's not going to be in 4.5 anyway, it should be
> possible to _develop_ it in this manner, possibly in a private branch,
> even if the early stages aren't getting applied immediately.  We
> should be able to set up an rmrr branch on the public servers if that
> helps.  But again, that relies on having a design worked out in
> advance that both developers and maintainers are (within reason)
> committed to.

that's a good suggestion. We'll send out a design review today, and then
based on discussion we can see whether making sense to do such 
incremental way.

> 
> > 3. Maintainers sometimes didn't give definitive guidance to the new people,
> > and the high-level design is not closed in the 1st place. e.g. when I thought
> this v8
> > version has everyone agreed on the design, there's another comment from
> Jan
> > about using XENMEM_set_memory_map might be better, while back to Aug.
> > when Tiejun raised that option the answer is "I'm not sure". Note I
> understand
> > as a maintainer he might not have definite answers for all opens. But w/o a
> > definitive guide new people may waste lots of effort on chasing a wrong
> option,
> > which is definitely frustrating.
> 
> This is definitely a problem, and indeed frustrating for the
> developers.  We had similar difficulties with PVH development, where
> even though we planned the architecture up-front, once the code was
> written it became clear that a different approach would have been
> better.  I'm not sure what we can do here to make it more likely that
> we get the design right first time.

understand and reasonable.

> 
> I do think that figuring out the design in advance makes these
> projects much smoother, and it's something we're seeing more of.  For
> example David Vrabel's designs for the new event channel interface, or
> indeed the design doc he wrote about grant table locking, where review
> at the design stage may have avoided a bunch of implementation effort
> altogether.

yes. a formal review in advance would be lot better than mixing design 
comments in scattered in deep coding review comments. For this RMRR
example, Tiejun did send out some summary for his patch set, but not
abstracted enough to catch people's eye on key design opens. And having
a goal for 4.5 window really brought him hard time to balance code 
refactoring and learn new areas when each series was questioned with 
new design inputs.

> 
> > So I'd suggest for such non-trivial task for a new people, all maintainers in
> > involved areas (xen, mmu, tools, vtd, etc) should first spend time to agree
> > on the high level design. At that stage, let's skip the coding problems to save
> > both time.
> 
> That sounds like a very good idea to me.
> 

Thanks a lot,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 02:09:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 02: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 1XytBn-0000Tt-P6; Thu, 11 Dec 2014 02:09: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 1XytBm-0000To-3S
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 02:09:10 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	BF/87-17694-5CCF8845; Thu, 11 Dec 2014 02:09:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418263747!12521054!1
X-Originating-IP: [66.165.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 20024 invoked from network); 11 Dec 2014 02:09:08 -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;
	11 Dec 2014 02:09:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,555,1413244800"; d="scan'208";a="203158817"
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.210.2; Wed, 10 Dec 2014 21:09: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 1XytBh-0003XD-Ln;
	Thu, 11 Dec 2014 02:09:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XytBh-0000jy-DZ;
	Thu, 11 Dec 2014 02:09:05 +0000
Date: Thu, 11 Dec 2014 02:09:05 +0000
Message-ID: <E1XytBh-0000jy-DZ@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] [libvirt bisection] complete build-i386-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-i386-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: 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:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  19a5474d04a497dd12928b694c4c3ab9621c9552
  Bug not present: 100b7a72a4cf209f2146610f1860b87331f1d9ad


  commit 19a5474d04a497dd12928b694c4c3ab9621c9552
  Author: Laine Stump <laine@laine.org>
  Date:   Thu Nov 20 11:55:50 2014 -0500
  
      util: functions to manage bridge fdb (forwarding database)
      
      These two functions use netlink RTM_NEWNEIGH and RTM_DELNEIGH messages
      to add and delete entries from a bridge's fdb. The bridge itself is
      not referenced in the arguments to the functions, only the name of the
      device that is attached to the bridge (since a device can only be
      attached to one bridge at a time, and must be attached for this
      function to make sense, the kernel easily infers which bridge's fdb is
      being modified by looking at the device name/index).


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.libvirt.build-i386-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32180 fail [host=itch-mite] / 32137 [host=moss-bug] 32005 [host=gall-mite] 31928 [host=grain-weevil] 31860 [host=bush-cricket] 31852 [host=grain-weevil] 31839 [host=grain-weevil] 31827 ok.
Failure / basis pass flights: 32180 / 31827
(tree with no url: seabios)
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: 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 3c4e08331004fb2c43d42f521e1b546222ef8d6e 8a408b869ce343f953a7ca564598985504b9aa7f b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
Basis pass 624ea2886cc570788cb01c4fd59315de301b0cd6 42874fa45f9fab99212d0ba3f66cf4671ddb0a30 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
Generating revisions with ./adhoc-revtuple-generator  git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]#624ea2886cc570788cb01c4fd59315de301b0cd6-3c4e08331004fb2c43d42f521e1b546222ef8d6e git://libvirt.org/libvirt.git#42874fa45f9fab99212d0ba3f66cf4671ddb0a30-8a408b869ce343f953a7ca564598985504b9aa7f git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51-1ebb75b1fee779621b63e84fefa7b07354c43a99 git://xenbits.xen.org/xen.git#0540b854f6733759593e829bc3f13c9b45974e32-3a80985b894f54eb3b2e143e4dea737cf139a517
+ 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/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/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/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 4007 nodes in revision graph
Searching for test results:
 31827 pass 624ea2886cc570788cb01c4fd59315de301b0cd6 42874fa45f9fab99212d0ba3f66cf4671ddb0a30 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31787 [host=bush-cricket]
 31860 [host=bush-cricket]
 31839 [host=grain-weevil]
 31928 [host=grain-weevil]
 31852 [host=grain-weevil]
 32005 [host=gall-mite]
 32077 [host=moss-bug]
 32138 [host=moss-bug]
 32101 [host=moss-bug]
 32064 [host=moss-bug]
 32083 [host=moss-bug]
 32115 [host=moss-bug]
 32122 [host=moss-bug]
 32098 [host=moss-bug]
 32116 [host=moss-bug]
 32133 [host=moss-bug]
 32118 [host=moss-bug]
 32120 [host=moss-bug]
 32102 [host=moss-bug]
 32121 [host=moss-bug]
 32123 [host=moss-bug]
 32137 [host=moss-bug]
 32266 pass 3c411c43e5bd964fa6ac98f9cca639d18523ff06 100b7a72a4cf209f2146610f1860b87331f1d9ad b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32241 pass 4b4ef862eb7f4cf5ea6f375b527271883924f392 04c383ea7a991325ab6d2894b4f5bbdbbeb8fdd9 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a ac16e70b2648ee782fb084c73ee63804209498fd
 32180 fail 3c4e08331004fb2c43d42f521e1b546222ef8d6e 8a408b869ce343f953a7ca564598985504b9aa7f b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32246 pass e5a15adc6db466ae9d7ea5d892f78e0390d032d0 421406808abaf7eb66abd27d71c21ae5b783a380 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 188336bb86d0992a2a034ece5f39eccc5d10f337
 32260 fail 3c411c43e5bd964fa6ac98f9cca639d18523ff06 19a5474d04a497dd12928b694c4c3ab9621c9552 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32248 pass 79002fdd9f556694728f5ebc2ea0c43c14ef476d 253319ced6e9e92992f59000e3810b7d3ab59750 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32205 pass 624ea2886cc570788cb01c4fd59315de301b0cd6 42874fa45f9fab99212d0ba3f66cf4671ddb0a30 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 32240 fail 3c4e08331004fb2c43d42f521e1b546222ef8d6e 8a408b869ce343f953a7ca564598985504b9aa7f b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32267 fail 3c411c43e5bd964fa6ac98f9cca639d18523ff06 19a5474d04a497dd12928b694c4c3ab9621c9552 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32253 pass 3c411c43e5bd964fa6ac98f9cca639d18523ff06 7b499262cb6d2bc2361bc4cd3742c0cea331666f b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32249 fail 3c411c43e5bd964fa6ac98f9cca639d18523ff06 a3609121799d44898a3e0d0bf92b755e55e7b418 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32263 pass 3c411c43e5bd964fa6ac98f9cca639d18523ff06 100b7a72a4cf209f2146610f1860b87331f1d9ad b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32258 fail 3c411c43e5bd964fa6ac98f9cca639d18523ff06 19a5474d04a497dd12928b694c4c3ab9621c9552 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32251 pass 3c411c43e5bd964fa6ac98f9cca639d18523ff06 9f019d0cfdb2025e951ea4f8e81fc8a8b530518a b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32259 pass 3c411c43e5bd964fa6ac98f9cca639d18523ff06 100b7a72a4cf209f2146610f1860b87331f1d9ad b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32264 fail 3c411c43e5bd964fa6ac98f9cca639d18523ff06 19a5474d04a497dd12928b694c4c3ab9621c9552 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
Searching for interesting versions
 Result found: flight 31827 (pass), for basis pass
 Result found: flight 32180 (fail), for basis failure
 Repro found: flight 32205 (pass), for basis pass
 Repro found: flight 32240 (fail), for basis failure
 0 revisions at 3c411c43e5bd964fa6ac98f9cca639d18523ff06 100b7a72a4cf209f2146610f1860b87331f1d9ad b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
No revisions left to test, checking graph state.
 Result found: flight 32259 (pass), for last pass
 Result found: flight 32260 (fail), for first failure
 Repro found: flight 32263 (pass), for last pass
 Repro found: flight 32264 (fail), for first failure
 Repro found: flight 32266 (pass), for last pass
 Repro found: flight 32267 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  19a5474d04a497dd12928b694c4c3ab9621c9552
  Bug not present: 100b7a72a4cf209f2146610f1860b87331f1d9ad

+ 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 19a5474d04a497dd12928b694c4c3ab9621c9552
  Author: Laine Stump <laine@laine.org>
  Date:   Thu Nov 20 11:55:50 2014 -0500
  
      util: functions to manage bridge fdb (forwarding database)
      
      These two functions use netlink RTM_NEWNEIGH and RTM_DELNEIGH messages
      to add and delete entries from a bridge's fdb. The bridge itself is
      not referenced in the arguments to the functions, only the name of the
      device that is attached to the bridge (since a device can only be
      attached to one bridge at a time, and must be attached for this
      function to make sense, the kernel easily infers which bridge's fdb is
      being modified by looking at the device name/index).

Revision graph left in /home/xc_osstest/results/bisect.libvirt.build-i386-libvirt.libvirt-build.{dot,ps,png,html}.
----------------------------------------
32267: tolerable ALL FAIL

flight 32267 libvirt real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32267/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build           fail baseline untested


jobs:
 build-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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 02:09:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 02: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 1XytBn-0000Tt-P6; Thu, 11 Dec 2014 02:09: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 1XytBm-0000To-3S
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 02:09:10 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	BF/87-17694-5CCF8845; Thu, 11 Dec 2014 02:09:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418263747!12521054!1
X-Originating-IP: [66.165.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 20024 invoked from network); 11 Dec 2014 02:09:08 -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;
	11 Dec 2014 02:09:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,555,1413244800"; d="scan'208";a="203158817"
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.210.2; Wed, 10 Dec 2014 21:09: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 1XytBh-0003XD-Ln;
	Thu, 11 Dec 2014 02:09:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XytBh-0000jy-DZ;
	Thu, 11 Dec 2014 02:09:05 +0000
Date: Thu, 11 Dec 2014 02:09:05 +0000
Message-ID: <E1XytBh-0000jy-DZ@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] [libvirt bisection] complete build-i386-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-i386-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: 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:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  19a5474d04a497dd12928b694c4c3ab9621c9552
  Bug not present: 100b7a72a4cf209f2146610f1860b87331f1d9ad


  commit 19a5474d04a497dd12928b694c4c3ab9621c9552
  Author: Laine Stump <laine@laine.org>
  Date:   Thu Nov 20 11:55:50 2014 -0500
  
      util: functions to manage bridge fdb (forwarding database)
      
      These two functions use netlink RTM_NEWNEIGH and RTM_DELNEIGH messages
      to add and delete entries from a bridge's fdb. The bridge itself is
      not referenced in the arguments to the functions, only the name of the
      device that is attached to the bridge (since a device can only be
      attached to one bridge at a time, and must be attached for this
      function to make sense, the kernel easily infers which bridge's fdb is
      being modified by looking at the device name/index).


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.libvirt.build-i386-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32180 fail [host=itch-mite] / 32137 [host=moss-bug] 32005 [host=gall-mite] 31928 [host=grain-weevil] 31860 [host=bush-cricket] 31852 [host=grain-weevil] 31839 [host=grain-weevil] 31827 ok.
Failure / basis pass flights: 32180 / 31827
(tree with no url: seabios)
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: 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 3c4e08331004fb2c43d42f521e1b546222ef8d6e 8a408b869ce343f953a7ca564598985504b9aa7f b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
Basis pass 624ea2886cc570788cb01c4fd59315de301b0cd6 42874fa45f9fab99212d0ba3f66cf4671ddb0a30 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
Generating revisions with ./adhoc-revtuple-generator  git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]#624ea2886cc570788cb01c4fd59315de301b0cd6-3c4e08331004fb2c43d42f521e1b546222ef8d6e git://libvirt.org/libvirt.git#42874fa45f9fab99212d0ba3f66cf4671ddb0a30-8a408b869ce343f953a7ca564598985504b9aa7f git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51-1ebb75b1fee779621b63e84fefa7b07354c43a99 git://xenbits.xen.org/xen.git#0540b854f6733759593e829bc3f13c9b45974e32-3a80985b894f54eb3b2e143e4dea737cf139a517
+ 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/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/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/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 4007 nodes in revision graph
Searching for test results:
 31827 pass 624ea2886cc570788cb01c4fd59315de301b0cd6 42874fa45f9fab99212d0ba3f66cf4671ddb0a30 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 31787 [host=bush-cricket]
 31860 [host=bush-cricket]
 31839 [host=grain-weevil]
 31928 [host=grain-weevil]
 31852 [host=grain-weevil]
 32005 [host=gall-mite]
 32077 [host=moss-bug]
 32138 [host=moss-bug]
 32101 [host=moss-bug]
 32064 [host=moss-bug]
 32083 [host=moss-bug]
 32115 [host=moss-bug]
 32122 [host=moss-bug]
 32098 [host=moss-bug]
 32116 [host=moss-bug]
 32133 [host=moss-bug]
 32118 [host=moss-bug]
 32120 [host=moss-bug]
 32102 [host=moss-bug]
 32121 [host=moss-bug]
 32123 [host=moss-bug]
 32137 [host=moss-bug]
 32266 pass 3c411c43e5bd964fa6ac98f9cca639d18523ff06 100b7a72a4cf209f2146610f1860b87331f1d9ad b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32241 pass 4b4ef862eb7f4cf5ea6f375b527271883924f392 04c383ea7a991325ab6d2894b4f5bbdbbeb8fdd9 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 a230ec3101ddda868252c036ea960af2b2d6cd5a ac16e70b2648ee782fb084c73ee63804209498fd
 32180 fail 3c4e08331004fb2c43d42f521e1b546222ef8d6e 8a408b869ce343f953a7ca564598985504b9aa7f b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32246 pass e5a15adc6db466ae9d7ea5d892f78e0390d032d0 421406808abaf7eb66abd27d71c21ae5b783a380 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 188336bb86d0992a2a034ece5f39eccc5d10f337
 32260 fail 3c411c43e5bd964fa6ac98f9cca639d18523ff06 19a5474d04a497dd12928b694c4c3ab9621c9552 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32248 pass 79002fdd9f556694728f5ebc2ea0c43c14ef476d 253319ced6e9e92992f59000e3810b7d3ab59750 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32205 pass 624ea2886cc570788cb01c4fd59315de301b0cd6 42874fa45f9fab99212d0ba3f66cf4671ddb0a30 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 0540b854f6733759593e829bc3f13c9b45974e32
 32240 fail 3c4e08331004fb2c43d42f521e1b546222ef8d6e 8a408b869ce343f953a7ca564598985504b9aa7f b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32267 fail 3c411c43e5bd964fa6ac98f9cca639d18523ff06 19a5474d04a497dd12928b694c4c3ab9621c9552 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32253 pass 3c411c43e5bd964fa6ac98f9cca639d18523ff06 7b499262cb6d2bc2361bc4cd3742c0cea331666f b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32249 fail 3c411c43e5bd964fa6ac98f9cca639d18523ff06 a3609121799d44898a3e0d0bf92b755e55e7b418 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32263 pass 3c411c43e5bd964fa6ac98f9cca639d18523ff06 100b7a72a4cf209f2146610f1860b87331f1d9ad b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32258 fail 3c411c43e5bd964fa6ac98f9cca639d18523ff06 19a5474d04a497dd12928b694c4c3ab9621c9552 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32251 pass 3c411c43e5bd964fa6ac98f9cca639d18523ff06 9f019d0cfdb2025e951ea4f8e81fc8a8b530518a b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32259 pass 3c411c43e5bd964fa6ac98f9cca639d18523ff06 100b7a72a4cf209f2146610f1860b87331f1d9ad b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
 32264 fail 3c411c43e5bd964fa6ac98f9cca639d18523ff06 19a5474d04a497dd12928b694c4c3ab9621c9552 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
Searching for interesting versions
 Result found: flight 31827 (pass), for basis pass
 Result found: flight 32180 (fail), for basis failure
 Repro found: flight 32205 (pass), for basis pass
 Repro found: flight 32240 (fail), for basis failure
 0 revisions at 3c411c43e5bd964fa6ac98f9cca639d18523ff06 100b7a72a4cf209f2146610f1860b87331f1d9ad b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 3a80985b894f54eb3b2e143e4dea737cf139a517
No revisions left to test, checking graph state.
 Result found: flight 32259 (pass), for last pass
 Result found: flight 32260 (fail), for first failure
 Repro found: flight 32263 (pass), for last pass
 Repro found: flight 32264 (fail), for first failure
 Repro found: flight 32266 (pass), for last pass
 Repro found: flight 32267 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  19a5474d04a497dd12928b694c4c3ab9621c9552
  Bug not present: 100b7a72a4cf209f2146610f1860b87331f1d9ad

+ 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 19a5474d04a497dd12928b694c4c3ab9621c9552
  Author: Laine Stump <laine@laine.org>
  Date:   Thu Nov 20 11:55:50 2014 -0500
  
      util: functions to manage bridge fdb (forwarding database)
      
      These two functions use netlink RTM_NEWNEIGH and RTM_DELNEIGH messages
      to add and delete entries from a bridge's fdb. The bridge itself is
      not referenced in the arguments to the functions, only the name of the
      device that is attached to the bridge (since a device can only be
      attached to one bridge at a time, and must be attached for this
      function to make sense, the kernel easily infers which bridge's fdb is
      being modified by looking at the device name/index).

Revision graph left in /home/xc_osstest/results/bisect.libvirt.build-i386-libvirt.libvirt-build.{dot,ps,png,html}.
----------------------------------------
32267: tolerable ALL FAIL

flight 32267 libvirt real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32267/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-i386-libvirt            5 libvirt-build           fail baseline untested


jobs:
 build-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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 02:28:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 02: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 1XytTk-0001G1-Ip; Thu, 11 Dec 2014 02:27:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1XytTj-0001Fu-Ha
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 02:27:43 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	2F/9B-25727-E1109845; Thu, 11 Dec 2014 02:27:42 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418264859!8768182!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14611 invoked from network); 11 Dec 2014 02:27:40 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 02:27:40 -0000
Received: by mail-qa0-f50.google.com with SMTP id w8so2919566qac.23
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 18:27: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=hQoYuBnY19DD0/F40rslVRLNXhdZwS/FWrwjq5zD7G8=;
	b=Yqw0MaUIBQMN6vTXZ9EWk6qtjPHQegbxFy409tavJ7awiVhESY/BNt7ulDMygqa+0e
	Rv2e2WSvoP4VFtb4KNzoNSVDaQrLoW93q1INrYzSyvBP02E3flfGGgloWtHvAMuhzuyO
	Yq5vfwFCXqSqObaUJ2KlrIQMJzRtIEWOo0Fa5Okc81dC7tlwKES4Ho40Nlc9PrT5iXZt
	rfa+yLaLtq46l/BnBSUsxfZGmqgnYC4/v6++A4vpn+vnrREyOmpFqXwff29EFcFy4s/0
	WQjWu4nx7eTO75CwOVCgv2mGztzEHGaUZbo8CaoumydH5j03ctosBqeRYNlc1jeDjrVn
	SqKw==
MIME-Version: 1.0
X-Received: by 10.224.80.6 with SMTP id r6mr15078196qak.5.1418264859383; Wed,
	10 Dec 2014 18:27:39 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Wed, 10 Dec 2014 18:27:39 -0800 (PST)
Date: Wed, 10 Dec 2014 18:27:39 -0800
Message-ID: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Julien Grall <julien.grall@linaro.org>, 
	Ian Campbell <Ian.Campbell@citrix.com>, manish.jaggi@caviumnetworks.com
Subject: [Xen-devel] Timed out waiting for device dev-hvc0.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

I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)

...

[  OK  ] Reached target Host and Network Name Lookups.
[  OK  ] Started OpenSSH Daemon.
[ TIME ] Timed out waiting for device dev-hvc0.device.
[DEPEND] Dependency failed for Serial Getty on hvc0.
[  OK  ] Reached target Login Prompts.


Any Idea? what could be wrong here


-Manish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 02:28:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 02: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 1XytTk-0001G1-Ip; Thu, 11 Dec 2014 02:27:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1XytTj-0001Fu-Ha
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 02:27:43 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	2F/9B-25727-E1109845; Thu, 11 Dec 2014 02:27:42 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418264859!8768182!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14611 invoked from network); 11 Dec 2014 02:27:40 -0000
Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com)
	(209.85.216.50)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 02:27:40 -0000
Received: by mail-qa0-f50.google.com with SMTP id w8so2919566qac.23
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 18:27: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=hQoYuBnY19DD0/F40rslVRLNXhdZwS/FWrwjq5zD7G8=;
	b=Yqw0MaUIBQMN6vTXZ9EWk6qtjPHQegbxFy409tavJ7awiVhESY/BNt7ulDMygqa+0e
	Rv2e2WSvoP4VFtb4KNzoNSVDaQrLoW93q1INrYzSyvBP02E3flfGGgloWtHvAMuhzuyO
	Yq5vfwFCXqSqObaUJ2KlrIQMJzRtIEWOo0Fa5Okc81dC7tlwKES4Ho40Nlc9PrT5iXZt
	rfa+yLaLtq46l/BnBSUsxfZGmqgnYC4/v6++A4vpn+vnrREyOmpFqXwff29EFcFy4s/0
	WQjWu4nx7eTO75CwOVCgv2mGztzEHGaUZbo8CaoumydH5j03ctosBqeRYNlc1jeDjrVn
	SqKw==
MIME-Version: 1.0
X-Received: by 10.224.80.6 with SMTP id r6mr15078196qak.5.1418264859383; Wed,
	10 Dec 2014 18:27:39 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Wed, 10 Dec 2014 18:27:39 -0800 (PST)
Date: Wed, 10 Dec 2014 18:27:39 -0800
Message-ID: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Julien Grall <julien.grall@linaro.org>, 
	Ian Campbell <Ian.Campbell@citrix.com>, manish.jaggi@caviumnetworks.com
Subject: [Xen-devel] Timed out waiting for device dev-hvc0.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

I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)

...

[  OK  ] Reached target Host and Network Name Lookups.
[  OK  ] Started OpenSSH Daemon.
[ TIME ] Timed out waiting for device dev-hvc0.device.
[DEPEND] Dependency failed for Serial Getty on hvc0.
[  OK  ] Reached target Login Prompts.


Any Idea? what could be wrong here


-Manish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 02:40:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 02: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 1XytfV-0001hW-QJ; Thu, 11 Dec 2014 02:39:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1XytfU-0001hR-IJ
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 02:39:52 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	4A/50-01660-7F309845; Thu, 11 Dec 2014 02:39:51 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418265590!12677178!1
X-Originating-IP: [209.85.216.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 10872 invoked from network); 11 Dec 2014 02:39:51 -0000
Received: from mail-qc0-f174.google.com (HELO mail-qc0-f174.google.com)
	(209.85.216.174)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 02:39:51 -0000
Received: by mail-qc0-f174.google.com with SMTP id c9so3218455qcz.33
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 18:39:50 -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=G3YBw+rzoSGF46qbZnRzgx3SYRzYx71+2TdL7ORXSV8=;
	b=OxopVA+lFs9cffyPA2V9j04olQQJ4DFc8qwHuk8+LRLwJVEzBOaRkMEGRSOkCTMuOQ
	ke/GyRdLzdJWqBw7KgUcyU8zupydOYsPx3pxafK4xIeZEpPHu2CkWAPJpElaHpsyJ+ye
	dSrAr+Z0SAkpYa2cDQh6G9LulszAU8+OzGc6Mbo2yhE/NaC/Oo/dFVWPISUwAPhPdBF7
	fad1v4OPuBFIKFrfFT1v7SaPn2PsitAn1/tcTPZRUDzrH4OOTZgqlL2HjMHGCwg71sCj
	z6Pr4GrScmEVSBL3YGf2T5uZm34ApIbawuNIpNr5pWb8TUIfGB0peQUlJGFQXcO9jCLn
	nggA==
MIME-Version: 1.0
X-Received: by 10.224.131.135 with SMTP id x7mr15671054qas.38.1418265590357;
	Wed, 10 Dec 2014 18:39:50 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Wed, 10 Dec 2014 18:39:50 -0800 (PST)
Date: Wed, 10 Dec 2014 18:39:50 -0800
Message-ID: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Julien Grall <julien.grall@linaro.org>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	manish.jaggi@caviumnetworks.com
Subject: [Xen-devel] Few Comments on the Xen SMMU ARM code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Based on my experience with PCI passthrough code merging, below are
some comments:
Both require a change in code

a) The current code which is non-pci passthrough requires a devices'
device tree node to be associated with smmu node, if that device has
to be assigned to domU.

In our system there is no platform device which can be passthough. All
devices (including uart) are enumerated using PCI enumeration.
So the device tree looks like

pcie0 {
}

smmu {
mmu-masters = <&pcie0 0x100>;
}

When dom0 boots pcie is assigned to dom0 and a stream ID 0x100 is
created which later conflicts with a valid device enumerated later

b) Current xen code and linux code used rb_tree with key as dt_node to
locate a device and its smmu. With an enumerated device there is no
such thing. So this would not work.


I need your views how PCI passthrough / Non PCI passthrough code can
coexist with the two points mentioned above ?


-Regards
Manish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 02:40:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 02: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 1XytfV-0001hW-QJ; Thu, 11 Dec 2014 02:39:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <manishjaggi.oss@gmail.com>) id 1XytfU-0001hR-IJ
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 02:39:52 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	4A/50-01660-7F309845; Thu, 11 Dec 2014 02:39:51 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418265590!12677178!1
X-Originating-IP: [209.85.216.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 10872 invoked from network); 11 Dec 2014 02:39:51 -0000
Received: from mail-qc0-f174.google.com (HELO mail-qc0-f174.google.com)
	(209.85.216.174)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 02:39:51 -0000
Received: by mail-qc0-f174.google.com with SMTP id c9so3218455qcz.33
	for <xen-devel@lists.xen.org>; Wed, 10 Dec 2014 18:39:50 -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=G3YBw+rzoSGF46qbZnRzgx3SYRzYx71+2TdL7ORXSV8=;
	b=OxopVA+lFs9cffyPA2V9j04olQQJ4DFc8qwHuk8+LRLwJVEzBOaRkMEGRSOkCTMuOQ
	ke/GyRdLzdJWqBw7KgUcyU8zupydOYsPx3pxafK4xIeZEpPHu2CkWAPJpElaHpsyJ+ye
	dSrAr+Z0SAkpYa2cDQh6G9LulszAU8+OzGc6Mbo2yhE/NaC/Oo/dFVWPISUwAPhPdBF7
	fad1v4OPuBFIKFrfFT1v7SaPn2PsitAn1/tcTPZRUDzrH4OOTZgqlL2HjMHGCwg71sCj
	z6Pr4GrScmEVSBL3YGf2T5uZm34ApIbawuNIpNr5pWb8TUIfGB0peQUlJGFQXcO9jCLn
	nggA==
MIME-Version: 1.0
X-Received: by 10.224.131.135 with SMTP id x7mr15671054qas.38.1418265590357;
	Wed, 10 Dec 2014 18:39:50 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Wed, 10 Dec 2014 18:39:50 -0800 (PST)
Date: Wed, 10 Dec 2014 18:39:50 -0800
Message-ID: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Julien Grall <julien.grall@linaro.org>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	manish.jaggi@caviumnetworks.com
Subject: [Xen-devel] Few Comments on the Xen SMMU ARM code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Based on my experience with PCI passthrough code merging, below are
some comments:
Both require a change in code

a) The current code which is non-pci passthrough requires a devices'
device tree node to be associated with smmu node, if that device has
to be assigned to domU.

In our system there is no platform device which can be passthough. All
devices (including uart) are enumerated using PCI enumeration.
So the device tree looks like

pcie0 {
}

smmu {
mmu-masters = <&pcie0 0x100>;
}

When dom0 boots pcie is assigned to dom0 and a stream ID 0x100 is
created which later conflicts with a valid device enumerated later

b) Current xen code and linux code used rb_tree with key as dt_node to
locate a device and its smmu. With an enumerated device there is no
such thing. So this would not work.


I need your views how PCI passthrough / Non PCI passthrough code can
coexist with the two points mentioned above ?


-Regards
Manish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 03:57:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 03: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 1XyusO-0004Mi-0G; Thu, 11 Dec 2014 03:57:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bsingharora@gmail.com>) id 1XyusM-0004Md-QA
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 03:57:14 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	39/23-28296-91619845; Thu, 11 Dec 2014 03:57:13 +0000
X-Env-Sender: bsingharora@gmail.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418270231!8776210!1
X-Originating-IP: [209.85.213.54]
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 20851 invoked from network); 11 Dec 2014 03:57:12 -0000
Received: from mail-yh0-f54.google.com (HELO mail-yh0-f54.google.com)
	(209.85.213.54)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 03:57:12 -0000
Received: by mail-yh0-f54.google.com with SMTP id 29so2077601yhl.27
	for <xen-devel@lists.xensource.com>;
	Wed, 10 Dec 2014 19:57:11 -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=cztFHj3WQoRrhSqpdyfjednBMWQ0vAgcwaU2+rVL8H4=;
	b=iNCI1oDLlkjP1QZo1/HiDc/rOWVxoOwx+KWR8mv2NGQt/SJ/mjeLWNR3YgaNEs1RRl
	QmlszCbj182JkApRJtP0quzy9vdUuGhkziahtIPtdh7qLeHx/wjo4XHfZnpMOUdmQsoa
	3hIp1dVyhwyprzvEJnNr5fgDUWZIQozbKC734vCRPzcE3uZ+5l7O9gGZuc905/P0+mKM
	a8bkGVKsQjhb3Q9Ji/C0IiYdi9TRzgjRP09UlLxRuDuDFgwBEdqoUqnru3qrMVocFbpM
	ciBwv1qT6+z5CW1bUPGd16E38bpIovtcU6OOiOD2fbh00qmP/yHq9mjh8VlY5V+xfdQv
	NjBw==
MIME-Version: 1.0
X-Received: by 10.170.61.202 with SMTP id d193mr6493345ykd.32.1418270231612;
	Wed, 10 Dec 2014 19:57:11 -0800 (PST)
Received: by 10.170.211.212 with HTTP; Wed, 10 Dec 2014 19:57:11 -0800 (PST)
In-Reply-To: <1418219759.3505.56.camel@citrix.com>
References: <CAKTCnznScui38+ec50U0dkCvWK2jA4cHEmqgaf1USj23k6CE5g@mail.gmail.com>
	<1418219759.3505.56.camel@citrix.com>
Date: Thu, 11 Dec 2014 09:27:11 +0530
Message-ID: <CAKTCnz=EecqWfrWkH1+pCfCLCF1F6Bt63sJBfT_oWayXr3F7cg@mail.gmail.com>
From: Balbir Singh <bsingharora@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Frozen dom0 xl commands
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Good catch Ian!

You are absolutely right! I built everything and it put the tools/etc
in /usr/local. I did not see a link to xencommons, I missed it
completely! Is there any thing else I should care about - any other
daemons/bridge to be setup?

Balbir Singh.

On Wed, Dec 10, 2014 at 7:25 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2014-12-10 at 19:24 +0530, Balbir Singh wrote:
>> I've been facing an issue on my Ubuntu box (acting as dom0) with
>> xen-4.5 (HEAD). I am running dom0 3.13.0.19-generic (ubuntu). When I
>> try and xl command I see the command hangs, after a while I see the
>> guest kernel complain. I've tried a similar setup on another setup and
>> I see the same issue. Any clues on how to debug?
>>
>> FYI: xl dmesg does not show much. I've tried using the console
>> debugger, but not had much luck with it
>
> Is xenstored running?
>
>>
>> [  484.442137] xl              D 0000000000000000     0  4590   4122 0x00000004
>> [  484.442146]  ffff88038cf87dd8 0000000000000202 ffff8800c458afe0
>> ffff88038cf87fd8
>> [  484.442156]  0000000000014440 0000000000014440 ffff8800c458afe0
>> ffffffff81fc0260
>> [  484.442164]  ffff88038cf87e10 ffff8800c4130058 ffff8800c413004c
>> ffff8800c4130000
>> [  484.442172] Call Trace:
>> [  484.442188]  [<ffffffff817154b9>] schedule+0x29/0x70
>> [  484.442198]  [<ffffffff81429c25>] read_reply+0x95/0x140
>> [  484.442210]  [<ffffffff810a9a50>] ? prepare_to_wait_event+0x100/0x100
>> [  484.442218]  [<ffffffff8142aa1c>] xenbus_dev_request_and_reply+0x8c/0xb0
>> [  484.442226]  [<ffffffff8142d1ae>] xenbus_file_write+0x27e/0x540
>> [  484.442236]  [<ffffffff811baea9>] ? __sb_start_write+0x49/0xe0
>> [  484.442246]  [<ffffffff812cf1c3>] ? security_file_permission+0x23/0xa0
>> [  484.442253]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
>> [  484.442261]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
>> [  484.442269]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6
>> [  484.442276] INFO: task xl:4660 blocked for more than 120 seconds.
>> [  484.442280]       Tainted: PF          O 3.13.0-19-generic #40-Ubuntu
>> [  484.442283] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>> disables this message.
>> [  484.442286] xl              D 0000000000000000     0  4660   4646 0x00000004
>> [  484.442291]  ffff88038dc41dc0 0000000000000202 ffff88038e2797f0
>> ffff88038dc41fd8
>> [  484.442300]  0000000000014440 0000000000014440 ffff88038e2797f0
>> ffffffff81fc0290
>> [  484.442308]  ffffffff81fc0294 ffff88038e2797f0 00000000ffffffff
>> ffffffff81fc0298
>> [  484.442316] Call Trace:
>> [  484.442325]  [<ffffffff817159d9>] schedule_preempt_disabled+0x29/0x70
>> [  484.442333]  [<ffffffff81717845>] __mutex_lock_slowpath+0x135/0x1b0
>> [  484.442339]  [<ffffffff817178df>] mutex_lock+0x1f/0x2f
>> [  484.442347]  [<ffffffff8142a9b6>] xenbus_dev_request_and_reply+0x26/0xb0
>> [  484.442355]  [<ffffffff8142d1ae>] xenbus_file_write+0x27e/0x540
>> [  484.442364]  [<ffffffff811baea9>] ? __sb_start_write+0x49/0xe0
>> [  484.442371]  [<ffffffff812cf1c3>] ? security_file_permission+0x23/0xa0
>> [  484.442378]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
>> [  484.442386]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
>> [  484.442393]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Dec 11 03:57:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 03: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 1XyusO-0004Mi-0G; Thu, 11 Dec 2014 03:57:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bsingharora@gmail.com>) id 1XyusM-0004Md-QA
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 03:57:14 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	39/23-28296-91619845; Thu, 11 Dec 2014 03:57:13 +0000
X-Env-Sender: bsingharora@gmail.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418270231!8776210!1
X-Originating-IP: [209.85.213.54]
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 20851 invoked from network); 11 Dec 2014 03:57:12 -0000
Received: from mail-yh0-f54.google.com (HELO mail-yh0-f54.google.com)
	(209.85.213.54)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 03:57:12 -0000
Received: by mail-yh0-f54.google.com with SMTP id 29so2077601yhl.27
	for <xen-devel@lists.xensource.com>;
	Wed, 10 Dec 2014 19:57:11 -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=cztFHj3WQoRrhSqpdyfjednBMWQ0vAgcwaU2+rVL8H4=;
	b=iNCI1oDLlkjP1QZo1/HiDc/rOWVxoOwx+KWR8mv2NGQt/SJ/mjeLWNR3YgaNEs1RRl
	QmlszCbj182JkApRJtP0quzy9vdUuGhkziahtIPtdh7qLeHx/wjo4XHfZnpMOUdmQsoa
	3hIp1dVyhwyprzvEJnNr5fgDUWZIQozbKC734vCRPzcE3uZ+5l7O9gGZuc905/P0+mKM
	a8bkGVKsQjhb3Q9Ji/C0IiYdi9TRzgjRP09UlLxRuDuDFgwBEdqoUqnru3qrMVocFbpM
	ciBwv1qT6+z5CW1bUPGd16E38bpIovtcU6OOiOD2fbh00qmP/yHq9mjh8VlY5V+xfdQv
	NjBw==
MIME-Version: 1.0
X-Received: by 10.170.61.202 with SMTP id d193mr6493345ykd.32.1418270231612;
	Wed, 10 Dec 2014 19:57:11 -0800 (PST)
Received: by 10.170.211.212 with HTTP; Wed, 10 Dec 2014 19:57:11 -0800 (PST)
In-Reply-To: <1418219759.3505.56.camel@citrix.com>
References: <CAKTCnznScui38+ec50U0dkCvWK2jA4cHEmqgaf1USj23k6CE5g@mail.gmail.com>
	<1418219759.3505.56.camel@citrix.com>
Date: Thu, 11 Dec 2014 09:27:11 +0530
Message-ID: <CAKTCnz=EecqWfrWkH1+pCfCLCF1F6Bt63sJBfT_oWayXr3F7cg@mail.gmail.com>
From: Balbir Singh <bsingharora@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Frozen dom0 xl commands
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Good catch Ian!

You are absolutely right! I built everything and it put the tools/etc
in /usr/local. I did not see a link to xencommons, I missed it
completely! Is there any thing else I should care about - any other
daemons/bridge to be setup?

Balbir Singh.

On Wed, Dec 10, 2014 at 7:25 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2014-12-10 at 19:24 +0530, Balbir Singh wrote:
>> I've been facing an issue on my Ubuntu box (acting as dom0) with
>> xen-4.5 (HEAD). I am running dom0 3.13.0.19-generic (ubuntu). When I
>> try and xl command I see the command hangs, after a while I see the
>> guest kernel complain. I've tried a similar setup on another setup and
>> I see the same issue. Any clues on how to debug?
>>
>> FYI: xl dmesg does not show much. I've tried using the console
>> debugger, but not had much luck with it
>
> Is xenstored running?
>
>>
>> [  484.442137] xl              D 0000000000000000     0  4590   4122 0x00000004
>> [  484.442146]  ffff88038cf87dd8 0000000000000202 ffff8800c458afe0
>> ffff88038cf87fd8
>> [  484.442156]  0000000000014440 0000000000014440 ffff8800c458afe0
>> ffffffff81fc0260
>> [  484.442164]  ffff88038cf87e10 ffff8800c4130058 ffff8800c413004c
>> ffff8800c4130000
>> [  484.442172] Call Trace:
>> [  484.442188]  [<ffffffff817154b9>] schedule+0x29/0x70
>> [  484.442198]  [<ffffffff81429c25>] read_reply+0x95/0x140
>> [  484.442210]  [<ffffffff810a9a50>] ? prepare_to_wait_event+0x100/0x100
>> [  484.442218]  [<ffffffff8142aa1c>] xenbus_dev_request_and_reply+0x8c/0xb0
>> [  484.442226]  [<ffffffff8142d1ae>] xenbus_file_write+0x27e/0x540
>> [  484.442236]  [<ffffffff811baea9>] ? __sb_start_write+0x49/0xe0
>> [  484.442246]  [<ffffffff812cf1c3>] ? security_file_permission+0x23/0xa0
>> [  484.442253]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
>> [  484.442261]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
>> [  484.442269]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6
>> [  484.442276] INFO: task xl:4660 blocked for more than 120 seconds.
>> [  484.442280]       Tainted: PF          O 3.13.0-19-generic #40-Ubuntu
>> [  484.442283] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>> disables this message.
>> [  484.442286] xl              D 0000000000000000     0  4660   4646 0x00000004
>> [  484.442291]  ffff88038dc41dc0 0000000000000202 ffff88038e2797f0
>> ffff88038dc41fd8
>> [  484.442300]  0000000000014440 0000000000014440 ffff88038e2797f0
>> ffffffff81fc0290
>> [  484.442308]  ffffffff81fc0294 ffff88038e2797f0 00000000ffffffff
>> ffffffff81fc0298
>> [  484.442316] Call Trace:
>> [  484.442325]  [<ffffffff817159d9>] schedule_preempt_disabled+0x29/0x70
>> [  484.442333]  [<ffffffff81717845>] __mutex_lock_slowpath+0x135/0x1b0
>> [  484.442339]  [<ffffffff817178df>] mutex_lock+0x1f/0x2f
>> [  484.442347]  [<ffffffff8142a9b6>] xenbus_dev_request_and_reply+0x26/0xb0
>> [  484.442355]  [<ffffffff8142d1ae>] xenbus_file_write+0x27e/0x540
>> [  484.442364]  [<ffffffff811baea9>] ? __sb_start_write+0x49/0xe0
>> [  484.442371]  [<ffffffff812cf1c3>] ? security_file_permission+0x23/0xa0
>> [  484.442378]  [<ffffffff811b88c4>] vfs_write+0xb4/0x1f0
>> [  484.442386]  [<ffffffff811b92f9>] SyS_write+0x49/0xa0
>> [  484.442393]  [<ffffffff81721c7f>] tracesys+0xe1/0xe6
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Dec 11 05:18:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 05:18:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyw89-0007S8-9F; Thu, 11 Dec 2014 05:17:37 +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 1Xyw88-0007S3-9h
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 05:17:36 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	18/05-17694-FE829845; Thu, 11 Dec 2014 05:17:35 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418275054!12461890!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 30096 invoked from network); 11 Dec 2014 05:17:34 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 05:17:34 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0CFBDAB07;
	Thu, 11 Dec 2014 05:17:33 +0000 (UTC)
Message-ID: <548928ED.9060800@suse.com>
Date: Thu, 11 Dec 2014 06:17: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: <1418226963-24873-1-git-send-email-jgross@suse.com>
	<20141210161353.GD4268@laptop.dumpdata.com>
In-Reply-To: <20141210161353.GD4268@laptop.dumpdata.com>
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen
	mmu.c earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/2014 05:13 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 10, 2014 at 04:56:03PM +0100, Juergen Gross wrote:
>> With the virtual mapped linear p2m list the post-init mmu operations
>> must be used for setting up the p2m mappings, as in case of
>> CONFIG_FLATMEM the init routines may trigger BUGs.
>
> Um, could you explain a bit more of why the CONFIG_FLATMEM
> is such unique? What about the other CONFIG_*MEM cases?

CONFIG_FLATMEM is just the configuration hitting a BUG() in
xen_alloc_pte_init() being used after finishing paging_init().

Juergen

>
>>
>> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   arch/x86/xen/mmu.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>> index 6ab6150..a1a429a 100644
>> --- a/arch/x86/xen/mmu.c
>> +++ b/arch/x86/xen/mmu.c
>> @@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
>>   static void __init xen_pagetable_init(void)
>>   {
>>   	paging_init();
>> +	xen_post_allocator_init();
>>
>>   	xen_pagetable_p2m_setup();
>>
>> @@ -1236,7 +1237,6 @@ static void __init xen_pagetable_init(void)
>>   		xen_remap_memory();
>>
>>   	xen_setup_shared_info();
>> -	xen_post_allocator_init();
>>   }
>>   static void xen_write_cr2(unsigned long cr2)
>>   {
>> --
>> 2.1.2
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 05:18:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 05:18:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyw89-0007S8-9F; Thu, 11 Dec 2014 05:17:37 +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 1Xyw88-0007S3-9h
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 05:17:36 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	18/05-17694-FE829845; Thu, 11 Dec 2014 05:17:35 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418275054!12461890!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 30096 invoked from network); 11 Dec 2014 05:17:34 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 05:17:34 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 0CFBDAB07;
	Thu, 11 Dec 2014 05:17:33 +0000 (UTC)
Message-ID: <548928ED.9060800@suse.com>
Date: Thu, 11 Dec 2014 06:17: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: <1418226963-24873-1-git-send-email-jgross@suse.com>
	<20141210161353.GD4268@laptop.dumpdata.com>
In-Reply-To: <20141210161353.GD4268@laptop.dumpdata.com>
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen
	mmu.c earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/2014 05:13 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 10, 2014 at 04:56:03PM +0100, Juergen Gross wrote:
>> With the virtual mapped linear p2m list the post-init mmu operations
>> must be used for setting up the p2m mappings, as in case of
>> CONFIG_FLATMEM the init routines may trigger BUGs.
>
> Um, could you explain a bit more of why the CONFIG_FLATMEM
> is such unique? What about the other CONFIG_*MEM cases?

CONFIG_FLATMEM is just the configuration hitting a BUG() in
xen_alloc_pte_init() being used after finishing paging_init().

Juergen

>
>>
>> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   arch/x86/xen/mmu.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>> index 6ab6150..a1a429a 100644
>> --- a/arch/x86/xen/mmu.c
>> +++ b/arch/x86/xen/mmu.c
>> @@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
>>   static void __init xen_pagetable_init(void)
>>   {
>>   	paging_init();
>> +	xen_post_allocator_init();
>>
>>   	xen_pagetable_p2m_setup();
>>
>> @@ -1236,7 +1237,6 @@ static void __init xen_pagetable_init(void)
>>   		xen_remap_memory();
>>
>>   	xen_setup_shared_info();
>> -	xen_post_allocator_init();
>>   }
>>   static void xen_write_cr2(unsigned long cr2)
>>   {
>> --
>> 2.1.2
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 05:32:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 05: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 1XywMG-0007yG-Vj; Thu, 11 Dec 2014 05:32:13 +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 1XywME-0007yB-Vm
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 05:32:11 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	3B/A3-02699-A5C29845; Thu, 11 Dec 2014 05:32:10 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418275929!14349201!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 26646 invoked from network); 11 Dec 2014 05:32:09 -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; 11 Dec 2014 05:32:09 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 93435AB07;
	Thu, 11 Dec 2014 05:32:08 +0000 (UTC)
Message-ID: <54892C58.5070707@suse.com>
Date: Thu, 11 Dec 2014 06:32: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
References: <1418226963-24873-1-git-send-email-jgross@suse.com>
	<54888BC6.7030601@citrix.com>
In-Reply-To: <54888BC6.7030601@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen
 mmu.c earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/2014 07:07 PM, David Vrabel wrote:
> On 10/12/14 15:56, Juergen Gross wrote:
>> With the virtual mapped linear p2m list the post-init mmu operations
>> must be used for setting up the p2m mappings, as in case of
>> CONFIG_FLATMEM the init routines may trigger BUGs.
>>
>> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   arch/x86/xen/mmu.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>> index 6ab6150..a1a429a 100644
>> --- a/arch/x86/xen/mmu.c
>> +++ b/arch/x86/xen/mmu.c
>> @@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
>>   static void __init xen_pagetable_init(void)
>>   {
>>   	paging_init();
>> +	xen_post_allocator_init();
>>
>>   	xen_pagetable_p2m_setup();
>>
>
> This feels very chicken-and-egg to me:  To setup the P2M we need to use
> the MMU ops that use the P2M...
>
> Please explain very clearly why this is all safe.

Okay. paging_init() sets up all infrastructure needed to switch to the
post-init mmu ops done by xen_post_allocator_init(). With the virtual
mapped linear p2m list we need some mmu ops during setup of this list,
so we have to switch to the correct mmu ops as soon as possible.

The p2m list is usable from the beginning, just expansion requires to
have established the new linear mapping. So the call of
xen_remap_memory() had to be introduced, but this is not due to the
mmu ops requiring this.

Summing it up: calling xen_post_allocator_init() not directly after
paging_init() was conceptually wrong in the beginning, it just didn't
matter up to now as no functions used between the two calls needed
some critical mmu ops (e.g. alloc_pte). This has changed now, so I
corrected it.

Juergen

>
>> @@ -1236,7 +1237,6 @@ static void __init xen_pagetable_init(void)
>>   		xen_remap_memory();
>>
>>   	xen_setup_shared_info();
>> -	xen_post_allocator_init();
>>   }
>>   static void xen_write_cr2(unsigned long cr2)
>>   {
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 05:32:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 05: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 1XywMG-0007yG-Vj; Thu, 11 Dec 2014 05:32:13 +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 1XywME-0007yB-Vm
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 05:32:11 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	3B/A3-02699-A5C29845; Thu, 11 Dec 2014 05:32:10 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418275929!14349201!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 26646 invoked from network); 11 Dec 2014 05:32:09 -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; 11 Dec 2014 05:32:09 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 93435AB07;
	Thu, 11 Dec 2014 05:32:08 +0000 (UTC)
Message-ID: <54892C58.5070707@suse.com>
Date: Thu, 11 Dec 2014 06:32: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
References: <1418226963-24873-1-git-send-email-jgross@suse.com>
	<54888BC6.7030601@citrix.com>
In-Reply-To: <54888BC6.7030601@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen
 mmu.c earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/2014 07:07 PM, David Vrabel wrote:
> On 10/12/14 15:56, Juergen Gross wrote:
>> With the virtual mapped linear p2m list the post-init mmu operations
>> must be used for setting up the p2m mappings, as in case of
>> CONFIG_FLATMEM the init routines may trigger BUGs.
>>
>> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   arch/x86/xen/mmu.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>> index 6ab6150..a1a429a 100644
>> --- a/arch/x86/xen/mmu.c
>> +++ b/arch/x86/xen/mmu.c
>> @@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
>>   static void __init xen_pagetable_init(void)
>>   {
>>   	paging_init();
>> +	xen_post_allocator_init();
>>
>>   	xen_pagetable_p2m_setup();
>>
>
> This feels very chicken-and-egg to me:  To setup the P2M we need to use
> the MMU ops that use the P2M...
>
> Please explain very clearly why this is all safe.

Okay. paging_init() sets up all infrastructure needed to switch to the
post-init mmu ops done by xen_post_allocator_init(). With the virtual
mapped linear p2m list we need some mmu ops during setup of this list,
so we have to switch to the correct mmu ops as soon as possible.

The p2m list is usable from the beginning, just expansion requires to
have established the new linear mapping. So the call of
xen_remap_memory() had to be introduced, but this is not due to the
mmu ops requiring this.

Summing it up: calling xen_post_allocator_init() not directly after
paging_init() was conceptually wrong in the beginning, it just didn't
matter up to now as no functions used between the two calls needed
some critical mmu ops (e.g. alloc_pte). This has changed now, so I
corrected it.

Juergen

>
>> @@ -1236,7 +1237,6 @@ static void __init xen_pagetable_init(void)
>>   		xen_remap_memory();
>>
>>   	xen_setup_shared_info();
>> -	xen_post_allocator_init();
>>   }
>>   static void xen_write_cr2(unsigned long cr2)
>>   {
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 08:21:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 08: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 1Xyyz5-0006Vm-9y; Thu, 11 Dec 2014 08:20: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 1Xyyz4-0006Vh-A1
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 08:20:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9B/FB-15461-9C359845; Thu, 11 Dec 2014 08:20:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418286023!14822473!1
X-Originating-IP: [66.165.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 3464 invoked from network); 11 Dec 2014 08:20:24 -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;
	11 Dec 2014 08:20:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,556,1413244800"; d="scan'208";a="203249064"
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.210.2; Thu, 11 Dec 2014 03:20: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 1Xyyz0-0005N9-Ey;
	Thu, 11 Dec 2014 08:20:22 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xyyz0-0007aJ-9N;
	Thu, 11 Dec 2014 08:20:22 +0000
Date: Thu, 11 Dec 2014 08:20:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32218-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] 32218: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32218 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32218/

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-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-i386-xl-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-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-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 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-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                     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 34178 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 Dec 11 08:21:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 08: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 1Xyyz5-0006Vm-9y; Thu, 11 Dec 2014 08:20: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 1Xyyz4-0006Vh-A1
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 08:20:26 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9B/FB-15461-9C359845; Thu, 11 Dec 2014 08:20:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418286023!14822473!1
X-Originating-IP: [66.165.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 3464 invoked from network); 11 Dec 2014 08:20:24 -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;
	11 Dec 2014 08:20:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,556,1413244800"; d="scan'208";a="203249064"
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.210.2; Thu, 11 Dec 2014 03:20: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 1Xyyz0-0005N9-Ey;
	Thu, 11 Dec 2014 08:20:22 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xyyz0-0007aJ-9N;
	Thu, 11 Dec 2014 08:20:22 +0000
Date: Thu, 11 Dec 2014 08:20:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32218-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] 32218: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32218 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32218/

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-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-i386-xl-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-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-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 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-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                     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 34178 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 Dec 11 08:43:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 08:43:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyzL4-0007ZW-8l; Thu, 11 Dec 2014 08:43:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XyzL2-0007ZR-Ba
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 08:43:08 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	7A/F9-25714-B1959845; Thu, 11 Dec 2014 08:43:07 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418287387!12782923!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13991 invoked from network); 11 Dec 2014 08:43:07 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 08:43:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418287386; l=755;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=L1hUP4ub+tF9Pa5QiBmSOcyJjtk=;
	b=ac5OD60dTdYqz4DFIWoLs/Va7X1aGgJTAv4sHUFqQmD6GlY+LKn1pdgrJoMXY6dZhAB
	6/Urw67giDS+h1Vfwqwn+xxD5M95MxhBWgKTzS5b6L1MLZ4RsxA7LdyK0THcY2IgOPJP1
	7XX1JX4ORiJgjLNorZM7G83FnzP0jMPbRIQ=
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.3 AUTH) with ESMTPSA id Q05251qBB8h3KHu
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 11 Dec 2014 09:43:03 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A3DE15015F; Thu, 11 Dec 2014 09:43:02 +0100 (CET)
Date: Thu, 11 Dec 2014 09:43:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141211084302.GA16507@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141210204226.GA13076@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org, m.a.young@durham.ac.uk
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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 Wed, Dec 10, Konrad Rzeszutek Wilk wrote:

> On Mon, Dec 08, 2014 at 11:18:05AM +0100, Olaf Hering wrote:
> > This is a resend of this series, with just the low hanging fruits:
> > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
> This looks like it would fix some of the issues I saw. I will test it
> over today.
> Please also CC Michael (Fedora Xen maintainer) on these changes (I've CC-ed
> him here).

It would be nice to know if the entire chain of dependencies fails, or
just that unit. Furthermore it would be nice to know if there needs to
be anyhing related to SELinux in the xen sources. In other words, would
xenstored behave correctly if that tmpfs mount would be done without any
options?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 08:43:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 08:43:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XyzL4-0007ZW-8l; Thu, 11 Dec 2014 08:43:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1XyzL2-0007ZR-Ba
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 08:43:08 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	7A/F9-25714-B1959845; Thu, 11 Dec 2014 08:43:07 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418287387!12782923!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13991 invoked from network); 11 Dec 2014 08:43:07 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 08:43:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418287386; l=755;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=L1hUP4ub+tF9Pa5QiBmSOcyJjtk=;
	b=ac5OD60dTdYqz4DFIWoLs/Va7X1aGgJTAv4sHUFqQmD6GlY+LKn1pdgrJoMXY6dZhAB
	6/Urw67giDS+h1Vfwqwn+xxD5M95MxhBWgKTzS5b6L1MLZ4RsxA7LdyK0THcY2IgOPJP1
	7XX1JX4ORiJgjLNorZM7G83FnzP0jMPbRIQ=
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.3 AUTH) with ESMTPSA id Q05251qBB8h3KHu
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 11 Dec 2014 09:43:03 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id A3DE15015F; Thu, 11 Dec 2014 09:43:02 +0100 (CET)
Date: Thu, 11 Dec 2014 09:43:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141211084302.GA16507@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141210204226.GA13076@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org, m.a.young@durham.ac.uk
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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 Wed, Dec 10, Konrad Rzeszutek Wilk wrote:

> On Mon, Dec 08, 2014 at 11:18:05AM +0100, Olaf Hering wrote:
> > This is a resend of this series, with just the low hanging fruits:
> > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
> This looks like it would fix some of the issues I saw. I will test it
> over today.
> Please also CC Michael (Fedora Xen maintainer) on these changes (I've CC-ed
> him here).

It would be nice to know if the entire chain of dependencies fails, or
just that unit. Furthermore it would be nice to know if there needs to
be anyhing related to SELinux in the xen sources. In other words, would
xenstored behave correctly if that tmpfs mount would be done without any
options?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 09:19:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 09:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyzu5-0000Ou-7m; Thu, 11 Dec 2014 09:19: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 1Xyzu3-0000Op-Fi
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 09:19:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	0A/32-15461-69169845; Thu, 11 Dec 2014 09:19:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418289556!11437529!1
X-Originating-IP: [66.165.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 9720 invoked from network); 11 Dec 2014 09:19:17 -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;
	11 Dec 2014 09:19:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,556,1413244800"; d="scan'208";a="202860281"
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.210.2; Thu, 11 Dec 2014 04:19: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 1Xyztq-0005eb-V3;
	Thu, 11 Dec 2014 09:19:07 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xyztq-0000m3-Pm;
	Thu, 11 Dec 2014 09:19:06 +0000
Date: Thu, 11 Dec 2014 09:19:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32222-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] 32222: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32222 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32222/

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-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-xl-pcipt-intel  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-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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                a0e4467726cd26bacb16f13d207ffcfa82ffc07d
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
982 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 61846 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 Dec 11 09:19:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 09:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xyzu5-0000Ou-7m; Thu, 11 Dec 2014 09:19: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 1Xyzu3-0000Op-Fi
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 09:19:19 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	0A/32-15461-69169845; Thu, 11 Dec 2014 09:19:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418289556!11437529!1
X-Originating-IP: [66.165.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 9720 invoked from network); 11 Dec 2014 09:19:17 -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;
	11 Dec 2014 09:19:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,556,1413244800"; d="scan'208";a="202860281"
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.210.2; Thu, 11 Dec 2014 04:19: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 1Xyztq-0005eb-V3;
	Thu, 11 Dec 2014 09:19:07 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xyztq-0000m3-Pm;
	Thu, 11 Dec 2014 09:19:06 +0000
Date: Thu, 11 Dec 2014 09:19:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32222-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] 32222: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32222 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32222/

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-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-xl-pcipt-intel  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-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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                a0e4467726cd26bacb16f13d207ffcfa82ffc07d
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
982 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 61846 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 Dec 11 09:39:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 09: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 1Xz0DS-00019x-2c; Thu, 11 Dec 2014 09:39:22 +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 1Xz0DQ-00019s-MH
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 09:39:20 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	E1/A0-24859-74669845; Thu, 11 Dec 2014 09:39:19 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418290759!8127316!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4299 invoked from network); 11 Dec 2014 09:39:19 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 09:39:19 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so5897618wgh.31
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 01:39: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=C+G45rD6/eYtI5lxUNHED4LLug3bHFbjY7rgn/U19eo=;
	b=KrU0kgPs5nOccNTMyaej9HOgl9Okzmu7K/PB53Quup13y+e6MRCTCf5jUC2iE7Abk/
	gdUxSZw0u3cpCln82AikBPjEesuKVmWkUkx6HOfc96/MQaJk7n2oMeyi/pgLToa9yRZT
	sKtq7pO7LpjyeJbISI9BwNnSDEkCNWr+ME4TFtPBtqHPmTD2ijqPguFLtEhvkgyUUiaG
	D8C7+qoE2JYaYrw+4oUfJs5gNyMS/ZCxN2eVWp88xQ2nbZFwlO7SJFQbCzMtyXdwVYK4
	zOentqpcOrqF2mj5BGiVigBa9a1OfX7obAqRGjN6K2/xh/ANt3plmA8df0fB3FBb9Zxc
	3jvQ==
X-Gm-Message-State: ALoCoQmEDB9nehkD4COoluHpEoOXV7UbC3dfmMgTVCVQ5U6Zxp3ATkx87stetciW7JaxnC55B1pX
X-Received: by 10.180.101.200 with SMTP id fi8mr14063090wib.77.1418290757878; 
	Thu, 11 Dec 2014 01:39:17 -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 wa5sm972194wjc.8.2014.12.11.01.39.16
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 01:39:17 -0800 (PST)
Message-ID: <5489668C.6030506@m2r.biz>
Date: Thu, 11 Dec 2014 10:40: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.3.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, 
	xen-devel <xen-devel@lists.xensource.com>
References: <542529E3.9080104@m2r.biz> <54253E5C.5090002@citrix.com>
	<54255208.1080904@m2r.biz> <542555C3.1030606@citrix.com>
In-Reply-To: <542555C3.1030606@citrix.com>
Cc: ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] xen ballon errors in kernel logs even if I disabled
 it after kernel upgrade from 3.2 to 3.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 26/09/2014 14:02, David Vrabel ha scritto:
> On 26/09/14 12:46, Fabio Fantoni wrote:
>> Il 26/09/2014 12:22, David Vrabel ha scritto:
>>> On 26/09/14 09:54, Fabio Fantoni wrote:
>>>> Yesterday I updated wheezy kernel (3.2) to 3.14 from wheezy-backports to
>>>> solves one critical network problem with new windows pv driver.
>>>> Today I saw the kernel logs full of this error:
>>>> xen:balloon: reserve_additional_memory: add_memory() failed: -17
>>> Fixed by:
>>>
>>> 3dcf63677d4eb7fdfc13290c8558c301d2588fe8 (xen/balloon: cancel ballooning
>>> if adding new memory failed)
>>>
>>> Ballooned memory is required by backends which is why you're seeing it
>>> even with auto-ballooning disabled.
>>>
>>> David
>>>
>> Thanks for your reply.
>> Is correct that show it also if dom0 have fixed memory size and xl.conf
>> have balloning disabled?
> Yes.
>
>> Can this problem cause a crash or other important aftermath?
> No. It's harmless.
>
>> Can you apply or request the backport of this fix to stable branchs?
> No. A fix for a harmless log message is not critical enough for stable.
>
> David

Thanks for your reply.
New debian kernel is freezed to 3.16 version without this fix 
(3.16.7-ckt2-1), I not found a workaround for it, even with dom0 mem 
fixed and autoballoning  disabled I still have big syslog and kern.log 
full of these messages when I start 1 or more domUs that make difficult 
see other parts of logs.
And another strange thing that I not understand is why older kernel 
(3.2) not have this problem.
Someone has advices about it please?

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 Dec 11 09:39:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 09: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 1Xz0DS-00019x-2c; Thu, 11 Dec 2014 09:39:22 +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 1Xz0DQ-00019s-MH
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 09:39:20 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	E1/A0-24859-74669845; Thu, 11 Dec 2014 09:39:19 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418290759!8127316!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4299 invoked from network); 11 Dec 2014 09:39:19 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 09:39:19 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so5897618wgh.31
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 01:39: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=C+G45rD6/eYtI5lxUNHED4LLug3bHFbjY7rgn/U19eo=;
	b=KrU0kgPs5nOccNTMyaej9HOgl9Okzmu7K/PB53Quup13y+e6MRCTCf5jUC2iE7Abk/
	gdUxSZw0u3cpCln82AikBPjEesuKVmWkUkx6HOfc96/MQaJk7n2oMeyi/pgLToa9yRZT
	sKtq7pO7LpjyeJbISI9BwNnSDEkCNWr+ME4TFtPBtqHPmTD2ijqPguFLtEhvkgyUUiaG
	D8C7+qoE2JYaYrw+4oUfJs5gNyMS/ZCxN2eVWp88xQ2nbZFwlO7SJFQbCzMtyXdwVYK4
	zOentqpcOrqF2mj5BGiVigBa9a1OfX7obAqRGjN6K2/xh/ANt3plmA8df0fB3FBb9Zxc
	3jvQ==
X-Gm-Message-State: ALoCoQmEDB9nehkD4COoluHpEoOXV7UbC3dfmMgTVCVQ5U6Zxp3ATkx87stetciW7JaxnC55B1pX
X-Received: by 10.180.101.200 with SMTP id fi8mr14063090wib.77.1418290757878; 
	Thu, 11 Dec 2014 01:39:17 -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 wa5sm972194wjc.8.2014.12.11.01.39.16
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 01:39:17 -0800 (PST)
Message-ID: <5489668C.6030506@m2r.biz>
Date: Thu, 11 Dec 2014 10:40: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.3.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>, 
	xen-devel <xen-devel@lists.xensource.com>
References: <542529E3.9080104@m2r.biz> <54253E5C.5090002@citrix.com>
	<54255208.1080904@m2r.biz> <542555C3.1030606@citrix.com>
In-Reply-To: <542555C3.1030606@citrix.com>
Cc: ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] xen ballon errors in kernel logs even if I disabled
 it after kernel upgrade from 3.2 to 3.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 26/09/2014 14:02, David Vrabel ha scritto:
> On 26/09/14 12:46, Fabio Fantoni wrote:
>> Il 26/09/2014 12:22, David Vrabel ha scritto:
>>> On 26/09/14 09:54, Fabio Fantoni wrote:
>>>> Yesterday I updated wheezy kernel (3.2) to 3.14 from wheezy-backports to
>>>> solves one critical network problem with new windows pv driver.
>>>> Today I saw the kernel logs full of this error:
>>>> xen:balloon: reserve_additional_memory: add_memory() failed: -17
>>> Fixed by:
>>>
>>> 3dcf63677d4eb7fdfc13290c8558c301d2588fe8 (xen/balloon: cancel ballooning
>>> if adding new memory failed)
>>>
>>> Ballooned memory is required by backends which is why you're seeing it
>>> even with auto-ballooning disabled.
>>>
>>> David
>>>
>> Thanks for your reply.
>> Is correct that show it also if dom0 have fixed memory size and xl.conf
>> have balloning disabled?
> Yes.
>
>> Can this problem cause a crash or other important aftermath?
> No. It's harmless.
>
>> Can you apply or request the backport of this fix to stable branchs?
> No. A fix for a harmless log message is not critical enough for stable.
>
> David

Thanks for your reply.
New debian kernel is freezed to 3.16 version without this fix 
(3.16.7-ckt2-1), I not found a workaround for it, even with dom0 mem 
fixed and autoballoning  disabled I still have big syslog and kern.log 
full of these messages when I start 1 or more domUs that make difficult 
see other parts of logs.
And another strange thing that I not understand is why older kernel 
(3.2) not have this problem.
Someone has advices about it please?

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 Dec 11 10:21:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 10:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz0rH-0002vj-3M; Thu, 11 Dec 2014 10:20:31 +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 1Xz0rF-0002ve-Om
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 10:20:29 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	FF/98-19763-DEF69845; Thu, 11 Dec 2014 10:20:29 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418293228!7360967!1
X-Originating-IP: [209.85.215.43]
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 2498 invoked from network); 11 Dec 2014 10:20:28 -0000
Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com)
	(209.85.215.43)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 10:20:28 -0000
Received: by mail-la0-f43.google.com with SMTP id s18so4038898lam.16
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 02:20: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
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=67XCogu82n0jU1XRS8hXUrWIdUIZSGIPq50OHawjbi8=;
	b=gF+nlIByLvu5h7tbzsK22WCHXQ1ABa506DSNxQLIaF2Vgo8gcPAyhwvEySXwnaXM11
	Bl/u1tT/cjMm0SAGX1n206+Xgni3IbgfYOyQnA8uHptFHbs+EFzU86yYjv5L1MQe2Rpa
	6w1YmsvZpm2ZYSHHU5yhrfDVxb9eXvDH2VqwsKGlGiqTV3ebo6sfwmwCsX7l2fLvi2AC
	2f7NAL2xgij2nlOuHKt6R2wkNSnVGY04nXHoKs+n2ZYkM/aiBSSt2vOCXSl0gqzSdYjA
	sclYp+KEKAJPTYrsis2Pni8qlvJADPCqPqJwz41XNTJYQcPChSF6dvhcxAElN5P3o6IR
	lGPA==
X-Gm-Message-State: ALoCoQlRYZ4kmNNzrHif1I5QzOhusc5YDOvF65A91lAzWX7QjavkfkE6GXlz2H3Pzx+SgL7xTmQW
X-Received: by 10.112.101.100 with SMTP id ff4mr8863401lbb.94.1418293227915;
	Thu, 11 Dec 2014 02:20: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 ku11sm239936lac.32.2014.12.11.02.20.25
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 02:20:26 -0800 (PST)
Message-ID: <54896FE8.2050905@linaro.org>
Date: Thu, 11 Dec 2014 10:20:24 +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.3.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>, 
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	manish.jaggi@caviumnetworks.com
References: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
In-Reply-To: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
Subject: Re: [Xen-devel] Few Comments on the Xen SMMU ARM code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

On 11/12/2014 02:39, manish jaggi wrote:
> I need your views how PCI passthrough / Non PCI passthrough code can
> coexist with the two points mentioned above ?

It' s hard to answer to your question if you don't specify on which 
version of the platform device passthrough you are based....

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 Dec 11 10:21:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 10:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz0rH-0002vj-3M; Thu, 11 Dec 2014 10:20:31 +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 1Xz0rF-0002ve-Om
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 10:20:29 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	FF/98-19763-DEF69845; Thu, 11 Dec 2014 10:20:29 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418293228!7360967!1
X-Originating-IP: [209.85.215.43]
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 2498 invoked from network); 11 Dec 2014 10:20:28 -0000
Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com)
	(209.85.215.43)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 10:20:28 -0000
Received: by mail-la0-f43.google.com with SMTP id s18so4038898lam.16
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 02:20: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
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=67XCogu82n0jU1XRS8hXUrWIdUIZSGIPq50OHawjbi8=;
	b=gF+nlIByLvu5h7tbzsK22WCHXQ1ABa506DSNxQLIaF2Vgo8gcPAyhwvEySXwnaXM11
	Bl/u1tT/cjMm0SAGX1n206+Xgni3IbgfYOyQnA8uHptFHbs+EFzU86yYjv5L1MQe2Rpa
	6w1YmsvZpm2ZYSHHU5yhrfDVxb9eXvDH2VqwsKGlGiqTV3ebo6sfwmwCsX7l2fLvi2AC
	2f7NAL2xgij2nlOuHKt6R2wkNSnVGY04nXHoKs+n2ZYkM/aiBSSt2vOCXSl0gqzSdYjA
	sclYp+KEKAJPTYrsis2Pni8qlvJADPCqPqJwz41XNTJYQcPChSF6dvhcxAElN5P3o6IR
	lGPA==
X-Gm-Message-State: ALoCoQlRYZ4kmNNzrHif1I5QzOhusc5YDOvF65A91lAzWX7QjavkfkE6GXlz2H3Pzx+SgL7xTmQW
X-Received: by 10.112.101.100 with SMTP id ff4mr8863401lbb.94.1418293227915;
	Thu, 11 Dec 2014 02:20: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 ku11sm239936lac.32.2014.12.11.02.20.25
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 02:20:26 -0800 (PST)
Message-ID: <54896FE8.2050905@linaro.org>
Date: Thu, 11 Dec 2014 10:20:24 +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.3.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>, 
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	manish.jaggi@caviumnetworks.com
References: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
In-Reply-To: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
Subject: Re: [Xen-devel] Few Comments on the Xen SMMU ARM code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

On 11/12/2014 02:39, manish jaggi wrote:
> I need your views how PCI passthrough / Non PCI passthrough code can
> coexist with the two points mentioned above ?

It' s hard to answer to your question if you don't specify on which 
version of the platform device passthrough you are based....

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 Dec 11 10:23:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 10: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 1Xz0u5-0003In-La; Thu, 11 Dec 2014 10:23:25 +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 1Xz0u4-0003Ih-CS
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 10:23:24 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	50/8C-29352-B9079845; Thu, 11 Dec 2014 10:23:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418293403!12756086!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29683 invoked from network); 11 Dec 2014 10:23:23 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 10:23:23 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so14034454wib.16
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 02:23: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
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=2EMks/u8eah6QeC0BjfI+gbQGelJbJYpzeeAe/2RRc8=;
	b=ChiJpLvYyeYVPlZRlPpajzKx8cjdUao+M6Ejj3kihZZW7uNx+erJ2tDv6Coztos4J1
	LkiD9ye/E+gx5qjv+vjLYxA1r3zEVsoBSl98yq8/9EHPzu/CQ7+2v/jp/8JzjFt0h+MP
	gYDjS5oKjA2azcAOjpsoSWXfZqAbj/g/83BNHSadeLAAC6HWuC2MzT6bBqaMeTq8FpS1
	JMJ7TBI7eRCyrxCpp2Ur47X1BDlFqFrFzAyqSSobpmTnV3kZuQ4VnluTAfL9FzUIZPHJ
	ZFZDke/klu2R132031Zq3UGoOAHIXeJ6lU7HyWv2IbTXNmWtBYZ5OPnZuIsHmgi2KN7m
	VzRA==
X-Gm-Message-State: ALoCoQmxDTiWGr2dLmi0CifJ7J5Cf6QznVpQYgc7AEF4VZBFdQHl0hvv1i4GEE1Gbc64GM4BhvE+
X-Received: by 10.194.216.170 with SMTP id or10mr15374205wjc.96.1418293402994; 
	Thu, 11 Dec 2014 02:23: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 j2sm1083278wjs.28.2014.12.11.02.23.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 02:23:22 -0800 (PST)
Message-ID: <54897098.3070009@linaro.org>
Date: Thu, 11 Dec 2014 10:23: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.3.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>, 
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>, manish.jaggi@caviumnetworks.com
References: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>
In-Reply-To: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>
Subject: Re: [Xen-devel] Timed out waiting for device dev-hvc0.device.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

On 11/12/2014 02:27, manish jaggi wrote:
> I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)
>
> ...
>
> [  OK  ] Reached target Host and Network Name Lookups.
> [  OK  ] Started OpenSSH Daemon.
> [ TIME ] Timed out waiting for device dev-hvc0.device.
> [DEPEND] Dependency failed for Serial Getty on hvc0.
> [  OK  ] Reached target Login Prompts.
>
>
> Any Idea? what could be wrong here

Please provide the full boot log. With only those 5 lines we can only 
guess what could be the issue.

Maybe the DOM0 kernel didn't detect that it's running on Xen or you 
forgot to enable CONFIG_XEN_HVC in your config.

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 Dec 11 10:23:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 10: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 1Xz0u5-0003In-La; Thu, 11 Dec 2014 10:23:25 +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 1Xz0u4-0003Ih-CS
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 10:23:24 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	50/8C-29352-B9079845; Thu, 11 Dec 2014 10:23:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418293403!12756086!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29683 invoked from network); 11 Dec 2014 10:23:23 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 10:23:23 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so14034454wib.16
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 02:23: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
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=2EMks/u8eah6QeC0BjfI+gbQGelJbJYpzeeAe/2RRc8=;
	b=ChiJpLvYyeYVPlZRlPpajzKx8cjdUao+M6Ejj3kihZZW7uNx+erJ2tDv6Coztos4J1
	LkiD9ye/E+gx5qjv+vjLYxA1r3zEVsoBSl98yq8/9EHPzu/CQ7+2v/jp/8JzjFt0h+MP
	gYDjS5oKjA2azcAOjpsoSWXfZqAbj/g/83BNHSadeLAAC6HWuC2MzT6bBqaMeTq8FpS1
	JMJ7TBI7eRCyrxCpp2Ur47X1BDlFqFrFzAyqSSobpmTnV3kZuQ4VnluTAfL9FzUIZPHJ
	ZFZDke/klu2R132031Zq3UGoOAHIXeJ6lU7HyWv2IbTXNmWtBYZ5OPnZuIsHmgi2KN7m
	VzRA==
X-Gm-Message-State: ALoCoQmxDTiWGr2dLmi0CifJ7J5Cf6QznVpQYgc7AEF4VZBFdQHl0hvv1i4GEE1Gbc64GM4BhvE+
X-Received: by 10.194.216.170 with SMTP id or10mr15374205wjc.96.1418293402994; 
	Thu, 11 Dec 2014 02:23: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 j2sm1083278wjs.28.2014.12.11.02.23.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 02:23:22 -0800 (PST)
Message-ID: <54897098.3070009@linaro.org>
Date: Thu, 11 Dec 2014 10:23: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.3.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>, 
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>, manish.jaggi@caviumnetworks.com
References: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>
In-Reply-To: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>
Subject: Re: [Xen-devel] Timed out waiting for device dev-hvc0.device.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

On 11/12/2014 02:27, manish jaggi wrote:
> I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)
>
> ...
>
> [  OK  ] Reached target Host and Network Name Lookups.
> [  OK  ] Started OpenSSH Daemon.
> [ TIME ] Timed out waiting for device dev-hvc0.device.
> [DEPEND] Dependency failed for Serial Getty on hvc0.
> [  OK  ] Reached target Login Prompts.
>
>
> Any Idea? what could be wrong here

Please provide the full boot log. With only those 5 lines we can only 
guess what could be the issue.

Maybe the DOM0 kernel didn't detect that it's running on Xen or you 
forgot to enable CONFIG_XEN_HVC in your config.

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 Dec 11 10:30:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 10: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 1Xz10x-0003Vf-Hq; Thu, 11 Dec 2014 10:30: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 1Xz10w-0003Va-DG
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 10:30:30 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	EC/8A-02957-54279845; Thu, 11 Dec 2014 10:30:29 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418293827!14367765!1
X-Originating-IP: [66.165.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 27718 invoked from network); 11 Dec 2014 10:30:28 -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;
	11 Dec 2014 10:30:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202881585"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 05:30: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 1Xz10r-0007NJ-NA;
	Thu, 11 Dec 2014 10:30:25 +0000
Date: Thu, 11 Dec 2014 10:30:05 +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: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1412111027550.30971@kaball.uk.xensource.com>
References: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Few Comments on the Xen SMMU ARM code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 10 Dec 2014, manish jaggi wrote:
> Based on my experience with PCI passthrough code merging, below are
> some comments:
> Both require a change in code
> 
> a) The current code which is non-pci passthrough requires a devices'
> device tree node to be associated with smmu node, if that device has
> to be assigned to domU.
> 
> In our system there is no platform device which can be passthough. All
> devices (including uart) are enumerated using PCI enumeration.
> So the device tree looks like
> 
> pcie0 {
> }
> 
> smmu {
> mmu-masters = <&pcie0 0x100>;
> }
> 
> When dom0 boots pcie is assigned to dom0 and a stream ID 0x100 is
> created which later conflicts with a valid device enumerated later
> 
> b) Current xen code and linux code used rb_tree with key as dt_node to
> locate a device and its smmu. With an enumerated device there is no
> such thing. So this would not work.
> 
> 
> I need your views how PCI passthrough / Non PCI passthrough code can
> coexist with the two points mentioned above ?

Hello Manish,
it is increasingly difficult to reply to your questions without reading
any patches or well written design documents.  I suggest you send out
your series, then we can move forward from there.

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 10:30:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 10: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 1Xz10x-0003Vf-Hq; Thu, 11 Dec 2014 10:30: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 1Xz10w-0003Va-DG
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 10:30:30 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	EC/8A-02957-54279845; Thu, 11 Dec 2014 10:30:29 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418293827!14367765!1
X-Originating-IP: [66.165.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 27718 invoked from network); 11 Dec 2014 10:30:28 -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;
	11 Dec 2014 10:30:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202881585"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 05:30: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 1Xz10r-0007NJ-NA;
	Thu, 11 Dec 2014 10:30:25 +0000
Date: Thu, 11 Dec 2014 10:30:05 +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: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1412111027550.30971@kaball.uk.xensource.com>
References: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Few Comments on the Xen SMMU ARM code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 10 Dec 2014, manish jaggi wrote:
> Based on my experience with PCI passthrough code merging, below are
> some comments:
> Both require a change in code
> 
> a) The current code which is non-pci passthrough requires a devices'
> device tree node to be associated with smmu node, if that device has
> to be assigned to domU.
> 
> In our system there is no platform device which can be passthough. All
> devices (including uart) are enumerated using PCI enumeration.
> So the device tree looks like
> 
> pcie0 {
> }
> 
> smmu {
> mmu-masters = <&pcie0 0x100>;
> }
> 
> When dom0 boots pcie is assigned to dom0 and a stream ID 0x100 is
> created which later conflicts with a valid device enumerated later
> 
> b) Current xen code and linux code used rb_tree with key as dt_node to
> locate a device and its smmu. With an enumerated device there is no
> such thing. So this would not work.
> 
> 
> I need your views how PCI passthrough / Non PCI passthrough code can
> coexist with the two points mentioned above ?

Hello Manish,
it is increasingly difficult to reply to your questions without reading
any patches or well written design documents.  I suggest you send out
your series, then we can move forward from there.

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 10:39:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 10:39:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz19B-0003xU-U6; Thu, 11 Dec 2014 10:39: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 1Xz199-0003xP-Vr
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 10:39:00 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	00/BE-02702-24479845; Thu, 11 Dec 2014 10:38:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418294337!11065485!1
X-Originating-IP: [66.165.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 13952 invoked from network); 11 Dec 2014 10:38:58 -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;
	11 Dec 2014 10:38:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203287524"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 05:38: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 1Xz195-0007Wj-LI;
	Thu, 11 Dec 2014 10:38:55 +0000
Date: Thu, 11 Dec 2014 10:38:55 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: longtao.pang <longtaox.pang@intel.com>
Message-ID: <20141211103855.GB21659@zion.uk.xensource.com>
References: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, robert.hu@intel.com, di.zheng@intel.com
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

Please use clear subject line in the future. Currently it's not very
descriptive. Something like "Introduction of netsted HVM test case" is
better.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 10:39:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 10:39:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz19B-0003xU-U6; Thu, 11 Dec 2014 10:39: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 1Xz199-0003xP-Vr
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 10:39:00 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	00/BE-02702-24479845; Thu, 11 Dec 2014 10:38:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418294337!11065485!1
X-Originating-IP: [66.165.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 13952 invoked from network); 11 Dec 2014 10:38:58 -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;
	11 Dec 2014 10:38:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203287524"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 05:38: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 1Xz195-0007Wj-LI;
	Thu, 11 Dec 2014 10:38:55 +0000
Date: Thu, 11 Dec 2014 10:38:55 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: longtao.pang <longtaox.pang@intel.com>
Message-ID: <20141211103855.GB21659@zion.uk.xensource.com>
References: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, robert.hu@intel.com, di.zheng@intel.com
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

Please use clear subject line in the future. Currently it's not very
descriptive. Something like "Introduction of netsted HVM test case" is
better.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 10:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 10: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 1Xz1HM-0004Pq-Vc; Thu, 11 Dec 2014 10:47: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 1Xz1HL-0004Pl-OF
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 10:47:27 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	D3/A3-29352-F3679845; Thu, 11 Dec 2014 10:47:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418294842!12752755!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7637 invoked from network); 11 Dec 2014 10:47:22 -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; 11 Dec 2014 10:47:22 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 10:47:22 +0000
Message-Id: <54898449020000780004EDDD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 10:47:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEADF3A29.0__="
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH] x86: don't deliver NMI to PVH Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartEADF3A29.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... for the time being: The mechanism used depends on the domain's use
of the IRET hypercall.

Also drop two bogus code lines spotted while going through the involved
code paths: Addresses of per-CPU variables can't possibly be NULL, and
the setting of st->vcpu in send_guest_trap()'s MCE case is redundant
with an earlier cmpxchgptr().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3168,7 +3168,6 @@ static void nmi_mce_softirq(void)
     int cpu =3D smp_processor_id();
     struct softirq_trap *st =3D &per_cpu(softirq_trap, cpu);
=20
-    BUG_ON(st =3D=3D NULL);
     BUG_ON(st->vcpu =3D=3D NULL);
=20
     /* Set the tmp value unconditionally, so that
@@ -3233,7 +3232,7 @@ static void nmi_hwdom_report(unsigned in
 {
     struct domain *d =3D hardware_domain;
=20
-    if ( (d =3D=3D NULL) || (d->vcpu =3D=3D NULL) || (d->vcpu[0] =3D=3D =
NULL) )
+    if ( !d || !d->vcpu || !d->vcpu[0] || !is_pv_domain(d) /* PVH fixme =
*/ )
         return;
=20
     set_bit(reason_idx, nmi_reason(d));
@@ -3674,7 +3673,6 @@ int send_guest_trap(struct domain *d, ui
=20
         if ( !test_and_set_bool(v->mce_pending) ) {
                 st->domain =3D d;
-                st->vcpu =3D v;
                 st->processor =3D v->processor;
=20
                 /* not safe to wake up a vcpu here */




--=__PartEADF3A29.0__=
Content-Type: text/plain; name="x86-PVH-suppress-NMI.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-PVH-suppress-NMI.patch"

x86: don't deliver NMI to PVH Dom0=0A=0A... for the time being: The =
mechanism used depends on the domain's use=0Aof the IRET hypercall.=0A=0AAl=
so drop two bogus code lines spotted while going through the involved=0Acod=
e paths: Addresses of per-CPU variables can't possibly be NULL, and=0Athe =
setting of st->vcpu in send_guest_trap()'s MCE case is redundant=0Awith an =
earlier cmpxchgptr().=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -3168,7 =
+3168,6 @@ static void nmi_mce_softirq(void)=0A     int cpu =3D smp_process=
or_id();=0A     struct softirq_trap *st =3D &per_cpu(softirq_trap, =
cpu);=0A =0A-    BUG_ON(st =3D=3D NULL);=0A     BUG_ON(st->vcpu =3D=3D =
NULL);=0A =0A     /* Set the tmp value unconditionally, so that=0A@@ =
-3233,7 +3232,7 @@ static void nmi_hwdom_report(unsigned in=0A {=0A     =
struct domain *d =3D hardware_domain;=0A =0A-    if ( (d =3D=3D NULL) || =
(d->vcpu =3D=3D NULL) || (d->vcpu[0] =3D=3D NULL) )=0A+    if ( !d || =
!d->vcpu || !d->vcpu[0] || !is_pv_domain(d) /* PVH fixme */ )=0A         =
return;=0A =0A     set_bit(reason_idx, nmi_reason(d));=0A@@ -3674,7 =
+3673,6 @@ int send_guest_trap(struct domain *d, ui=0A =0A         if ( =
!test_and_set_bool(v->mce_pending) ) {=0A                 st->domain =3D =
d;=0A-                st->vcpu =3D v;=0A                 st->processor =3D =
v->processor;=0A =0A                 /* not safe to wake up a vcpu here =
*/=0A
--=__PartEADF3A29.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

--=__PartEADF3A29.0__=--


From xen-devel-bounces@lists.xen.org Thu Dec 11 10:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 10: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 1Xz1HM-0004Pq-Vc; Thu, 11 Dec 2014 10:47: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 1Xz1HL-0004Pl-OF
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 10:47:27 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	D3/A3-29352-F3679845; Thu, 11 Dec 2014 10:47:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418294842!12752755!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7637 invoked from network); 11 Dec 2014 10:47:22 -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; 11 Dec 2014 10:47:22 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 10:47:22 +0000
Message-Id: <54898449020000780004EDDD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 10:47:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEADF3A29.0__="
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH] x86: don't deliver NMI to PVH Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartEADF3A29.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... for the time being: The mechanism used depends on the domain's use
of the IRET hypercall.

Also drop two bogus code lines spotted while going through the involved
code paths: Addresses of per-CPU variables can't possibly be NULL, and
the setting of st->vcpu in send_guest_trap()'s MCE case is redundant
with an earlier cmpxchgptr().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3168,7 +3168,6 @@ static void nmi_mce_softirq(void)
     int cpu =3D smp_processor_id();
     struct softirq_trap *st =3D &per_cpu(softirq_trap, cpu);
=20
-    BUG_ON(st =3D=3D NULL);
     BUG_ON(st->vcpu =3D=3D NULL);
=20
     /* Set the tmp value unconditionally, so that
@@ -3233,7 +3232,7 @@ static void nmi_hwdom_report(unsigned in
 {
     struct domain *d =3D hardware_domain;
=20
-    if ( (d =3D=3D NULL) || (d->vcpu =3D=3D NULL) || (d->vcpu[0] =3D=3D =
NULL) )
+    if ( !d || !d->vcpu || !d->vcpu[0] || !is_pv_domain(d) /* PVH fixme =
*/ )
         return;
=20
     set_bit(reason_idx, nmi_reason(d));
@@ -3674,7 +3673,6 @@ int send_guest_trap(struct domain *d, ui
=20
         if ( !test_and_set_bool(v->mce_pending) ) {
                 st->domain =3D d;
-                st->vcpu =3D v;
                 st->processor =3D v->processor;
=20
                 /* not safe to wake up a vcpu here */




--=__PartEADF3A29.0__=
Content-Type: text/plain; name="x86-PVH-suppress-NMI.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-PVH-suppress-NMI.patch"

x86: don't deliver NMI to PVH Dom0=0A=0A... for the time being: The =
mechanism used depends on the domain's use=0Aof the IRET hypercall.=0A=0AAl=
so drop two bogus code lines spotted while going through the involved=0Acod=
e paths: Addresses of per-CPU variables can't possibly be NULL, and=0Athe =
setting of st->vcpu in send_guest_trap()'s MCE case is redundant=0Awith an =
earlier cmpxchgptr().=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -3168,7 =
+3168,6 @@ static void nmi_mce_softirq(void)=0A     int cpu =3D smp_process=
or_id();=0A     struct softirq_trap *st =3D &per_cpu(softirq_trap, =
cpu);=0A =0A-    BUG_ON(st =3D=3D NULL);=0A     BUG_ON(st->vcpu =3D=3D =
NULL);=0A =0A     /* Set the tmp value unconditionally, so that=0A@@ =
-3233,7 +3232,7 @@ static void nmi_hwdom_report(unsigned in=0A {=0A     =
struct domain *d =3D hardware_domain;=0A =0A-    if ( (d =3D=3D NULL) || =
(d->vcpu =3D=3D NULL) || (d->vcpu[0] =3D=3D NULL) )=0A+    if ( !d || =
!d->vcpu || !d->vcpu[0] || !is_pv_domain(d) /* PVH fixme */ )=0A         =
return;=0A =0A     set_bit(reason_idx, nmi_reason(d));=0A@@ -3674,7 =
+3673,6 @@ int send_guest_trap(struct domain *d, ui=0A =0A         if ( =
!test_and_set_bool(v->mce_pending) ) {=0A                 st->domain =3D =
d;=0A-                st->vcpu =3D v;=0A                 st->processor =3D =
v->processor;=0A =0A                 /* not safe to wake up a vcpu here =
*/=0A
--=__PartEADF3A29.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

--=__PartEADF3A29.0__=--


From xen-devel-bounces@lists.xen.org Thu Dec 11 10:48:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 10:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz1IN-0004Tr-Fz; Thu, 11 Dec 2014 10:48: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 1Xz1IM-0004Tl-OA
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 10:48:30 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	AC/69-19763-E7679845; Thu, 11 Dec 2014 10:48:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418294908!7369186!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22580 invoked from network); 11 Dec 2014 10:48:29 -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;
	11 Dec 2014 10:48:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203289912"
Message-ID: <54897677.6000406@citrix.com>
Date: Thu, 11 Dec 2014 10:48:23 +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: Fabio Fantoni <fabio.fantoni@m2r.biz>, David Vrabel
	<david.vrabel@citrix.com>, xen-devel <xen-devel@lists.xensource.com>
References: <542529E3.9080104@m2r.biz>
	<54253E5C.5090002@citrix.com>	<54255208.1080904@m2r.biz>
	<542555C3.1030606@citrix.com> <5489668C.6030506@m2r.biz>
In-Reply-To: <5489668C.6030506@m2r.biz>
X-DLP: MIA2
Cc: ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] xen ballon errors in kernel logs even if I disabled
 it after kernel upgrade from 3.2 to 3.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 11/12/14 09:40, Fabio Fantoni wrote:
> Il 26/09/2014 14:02, David Vrabel ha scritto:
>> On 26/09/14 12:46, Fabio Fantoni wrote:
>>> Il 26/09/2014 12:22, David Vrabel ha scritto:
>>>> On 26/09/14 09:54, Fabio Fantoni wrote:
>>>>> Yesterday I updated wheezy kernel (3.2) to 3.14 from
>>>>> wheezy-backports to
>>>>> solves one critical network problem with new windows pv driver.
>>>>> Today I saw the kernel logs full of this error:
>>>>> xen:balloon: reserve_additional_memory: add_memory() failed: -17
>>>> Fixed by:
>>>>
>>>> 3dcf63677d4eb7fdfc13290c8558c301d2588fe8 (xen/balloon: cancel
>>>> ballooning
>>>> if adding new memory failed)
>>>>
>>>> Ballooned memory is required by backends which is why you're seeing it
>>>> even with auto-ballooning disabled.
>>>>
>>>> David
>>>>
>>> Thanks for your reply.
>>> Is correct that show it also if dom0 have fixed memory size and xl.conf
>>> have balloning disabled?
>> Yes.
>>
>>> Can this problem cause a crash or other important aftermath?
>> No. It's harmless.
>>
>>> Can you apply or request the backport of this fix to stable branchs?
>> No. A fix for a harmless log message is not critical enough for stable.
>>
>> David
> 
> Thanks for your reply.
> New debian kernel is freezed to 3.16 version without this fix
> (3.16.7-ckt2-1), I not found a workaround for it, even with dom0 mem
> fixed and autoballoning  disabled I still have big syslog and kern.log
> full of these messages when I start 1 or more domUs that make difficult
> see other parts of logs.
> And another strange thing that I not understand is why older kernel
> (3.2) not have this problem.
> Someone has advices about it please?

You can workaround it by pre-ballooning dom0 with a Xen command line
option such as dom0_mem=4G,max:5G

Don't have too much ballooned memory or dom0 may run out of memory and
not boot or run very slowly.

You can also disable XEN_BALLOON_MEMORY_HOTPLUG.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 10:48:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 10:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz1IN-0004Tr-Fz; Thu, 11 Dec 2014 10:48: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 1Xz1IM-0004Tl-OA
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 10:48:30 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	AC/69-19763-E7679845; Thu, 11 Dec 2014 10:48:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418294908!7369186!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22580 invoked from network); 11 Dec 2014 10:48:29 -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;
	11 Dec 2014 10:48:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203289912"
Message-ID: <54897677.6000406@citrix.com>
Date: Thu, 11 Dec 2014 10:48:23 +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: Fabio Fantoni <fabio.fantoni@m2r.biz>, David Vrabel
	<david.vrabel@citrix.com>, xen-devel <xen-devel@lists.xensource.com>
References: <542529E3.9080104@m2r.biz>
	<54253E5C.5090002@citrix.com>	<54255208.1080904@m2r.biz>
	<542555C3.1030606@citrix.com> <5489668C.6030506@m2r.biz>
In-Reply-To: <5489668C.6030506@m2r.biz>
X-DLP: MIA2
Cc: ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] xen ballon errors in kernel logs even if I disabled
 it after kernel upgrade from 3.2 to 3.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 11/12/14 09:40, Fabio Fantoni wrote:
> Il 26/09/2014 14:02, David Vrabel ha scritto:
>> On 26/09/14 12:46, Fabio Fantoni wrote:
>>> Il 26/09/2014 12:22, David Vrabel ha scritto:
>>>> On 26/09/14 09:54, Fabio Fantoni wrote:
>>>>> Yesterday I updated wheezy kernel (3.2) to 3.14 from
>>>>> wheezy-backports to
>>>>> solves one critical network problem with new windows pv driver.
>>>>> Today I saw the kernel logs full of this error:
>>>>> xen:balloon: reserve_additional_memory: add_memory() failed: -17
>>>> Fixed by:
>>>>
>>>> 3dcf63677d4eb7fdfc13290c8558c301d2588fe8 (xen/balloon: cancel
>>>> ballooning
>>>> if adding new memory failed)
>>>>
>>>> Ballooned memory is required by backends which is why you're seeing it
>>>> even with auto-ballooning disabled.
>>>>
>>>> David
>>>>
>>> Thanks for your reply.
>>> Is correct that show it also if dom0 have fixed memory size and xl.conf
>>> have balloning disabled?
>> Yes.
>>
>>> Can this problem cause a crash or other important aftermath?
>> No. It's harmless.
>>
>>> Can you apply or request the backport of this fix to stable branchs?
>> No. A fix for a harmless log message is not critical enough for stable.
>>
>> David
> 
> Thanks for your reply.
> New debian kernel is freezed to 3.16 version without this fix
> (3.16.7-ckt2-1), I not found a workaround for it, even with dom0 mem
> fixed and autoballoning  disabled I still have big syslog and kern.log
> full of these messages when I start 1 or more domUs that make difficult
> see other parts of logs.
> And another strange thing that I not understand is why older kernel
> (3.2) not have this problem.
> Someone has advices about it please?

You can workaround it by pre-ballooning dom0 with a Xen command line
option such as dom0_mem=4G,max:5G

Don't have too much ballooned memory or dom0 may run out of memory and
not boot or run very slowly.

You can also disable XEN_BALLOON_MEMORY_HOTPLUG.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 11:07:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11:07:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz1aN-0005NG-Ah; Thu, 11 Dec 2014 11:07:07 +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 1Xz1aM-0005NB-4s
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 11:07:06 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	24/20-02954-9DA79845; Thu, 11 Dec 2014 11:07:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418296022!14322047!1
X-Originating-IP: [66.165.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 26775 invoked from network); 11 Dec 2014 11:07:04 -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;
	11 Dec 2014 11:07:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203294500"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 06:06: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 1Xz1Zo-00082k-UU;
	Thu, 11 Dec 2014 11:06:32 +0000
Date: Thu, 11 Dec 2014 11:06:32 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: longtao.pang <longtaox.pang@intel.com>
Message-ID: <20141211110632.GC21659@zion.uk.xensource.com>
References: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
	<1418198860-29802-2-git-send-email-longtaox.pang@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418198860-29802-2-git-send-email-longtaox.pang@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, robert.hu@intel.com, di.zheng@intel.com
Subject: Re: [Xen-devel] [OSSTEST PATCH 1/4] Add nested testcase of
 preparing and installing 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 04:07:37PM +0800, longtao.pang wrote:
> 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      |   27 ++++++++++++++++++---------
>  Osstest/TestSupport.pm |   31 ++++++++++++++++++++++++++-----
>  sg-run-job             |    5 +++++
>  ts-debian-hvm-install  |   34 ++++++++++++++++++++++++----------
>  4 files changed, 73 insertions(+), 24 deletions(-)
> 
> diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> index c8db601..a671d20 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
> @@ -34,6 +35,7 @@ BEGIN {
>      @EXPORT      = qw(debian_boot_setup
>                        %preseed_cmds
>                        preseed_base
> +                      setupboot_grub2

Why do you want to export this helper? I think debian_setup_boot will
just choose the right one amongst uboot, grub1 and grub2.

>                        preseed_create
>                        preseed_hook_command preseed_hook_installscript
>                        di_installcmdline_core
> @@ -286,15 +288,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));

Please don't make non-functional change like this.

>  		if (@missing) {
>  		    logm("(skipping entry at $entry->{StartLine};".
>  			 " no @missing)");
> @@ -317,21 +322,25 @@ 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\S+)/) {
> +#	    if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {

And if this line is redundant, remove it. What's the reason of changing
this regex? Are you using non-debian based distro?

>                  die unless $entry;
>                  $entry->{Hv}= $1;
>              }
> -            if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
> +	    if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {

And this?

>                  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;
>              }
>          }

As I said before, this hunk should be in its own patch.

Just FYI, there are multiple people (Dario, you and I) touching this
piece of code. You might want to keep an eye on main OSSTest git tree
and rebase before reposting (and so do Dario and I).

> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index a3b6936..1e47039 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

Please don't just change white spaces. This makes patches hard to
review.

>                        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

Indentation. I think we mostly use space instead of hard tab. Ian?

>                        );
>      %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 @_;
> @@ -717,6 +727,7 @@ sub power_cycle_time ($) {
>  sub power_cycle ($) {
>      my ($ho) = @_;
>      $mjobdb->host_check_allocated($ho);
> +    $mjobdb->xen_check_installed($ho);

And this is? I don't see implementation in this patch set.

Also this routine is called by ts-host-install, which doesn't necessary
require Xen to be installed.

>      die "refusing to set power state for host $ho->{Name}".
>  	" possibly shared with other jobs\n"
>  	if $ho->{SharedMaybeOthers};
> @@ -937,7 +948,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 {

This should go into its own patch as well. I think it's probably nested
virt is slower than real hardware so you need some more time?

>          my $output;
>          if (!eval {
>              $output= target_cmd_output($ho, <<END, 40);
> @@ -1465,7 +1476,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}' ]

What is this needed? If it's necessary, please use a single commit and
state the reason in commit log.

>  #
>  on_poweroff = 'destroy'
>  on_reboot   = '$onreboot'
> @@ -2063,4 +2074,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/;

This pattern is different than the one used to match. This should also
go into its own commit -- "Introduce guest_editconfig_cd".

> +        }
> +        s/^on_reboot.*/on_reboot='restart'/;
> +    });
> +}
> +
>  1;
> diff --git a/sg-run-job b/sg-run-job
> index 2cf810a..8dcf7af 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-debian-hvm-install + host + nested + nested_L1
> +}
> +
>  proc test-guest-migr {g} {
>      if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
>  

This hunk should go into its own commit.

> diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
> index 37eade2..6dcec3c 100755
> --- a/ts-debian-hvm-install
> +++ b/ts-debian-hvm-install

The modification of debian-hvm-install should also go into a single
commit.

> @@ -28,22 +28,24 @@ 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;
> +our ($whhost,$gn,$nested_L1,$guesthost) = @ARGV;
>  $whhost ||= 'host';
> -$gn ||= 'debianhvm';
> -
> +$nested_L1 ||= '';
> +if ($nested_L1 eq 'nested_L1') {
> +    $gn ||= 'nested';
> +    $guesthost ||= "$gn.l1.osstest";
> +} else {
> +    $gn ||= 'debianhvm';
> +    $guesthost= "$gn.guest.osstest";
> +}
>  our $ho= selecthost($whhost);
> -
> +our $disk_mb= 50000;
>  # guest memory size will be set based on host free memory, see below
>  our $ram_mb;
> -our $disk_mb= 10000;
> -
> -our $guesthost= "$gn.guest.osstest";
>  our $gho;
>  
>  our $toolstack= toolstack()->{Command};
>  
> -

Stray blank line change. Please avoid this kind of changes.

>  sub preseed () {
>  
>      my $preseed_file = preseed_base('wheezy','',());
> @@ -63,7 +65,7 @@ d-i partman-auto/expert_recipe string \\
>                          use_filesystem{ } filesystem{ vfat } \\
>                          mountpoint{ /boot/efi } \\
>                  . \\
> -                5000 50 5000 ext4 \\
> +                25000 50 25000 ext4 \\
>                          method{ format } format{ } \\
>                          use_filesystem{ } filesystem{ ext4 } \\
>                          mountpoint{ / } \\
> @@ -155,6 +157,8 @@ sub prep () {
>      more_prepareguest_hvm($ho,$gho, $ram_mb, $disk_mb,
>                            OnReboot => 'preserve',
>                            Bios => $r{bios},
> +                          DefVcpus => 4,

And where is this handled?

Wei.

> +                          ExtraConfig => '#nestedhvm=1',
>                            PostImageHook => sub {
>          my $cmds = iso_copy_content_from_image($gho, $newiso);
>          $cmds .= prepare_initrd($initrddir,$newiso,$preseed_file_path);
> @@ -176,6 +180,8 @@ my $ram_minslop = 100;
>  my $ram_lots = 5000;
>  if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
>      $ram_mb = $ram_lots;
> +} elsif ($nested_L1 eq 'nested_L1') {
> +    $ram_mb = 2048;
>  } else {
>      $ram_mb = 768;
>  }
> @@ -192,7 +198,15 @@ if ($stage<2) {
>      guest_destroy($ho,$gho);
>  }
>  
> -guest_editconfig_nocd($gho,$emptyiso);
> +if ($nested_L1 eq 'nested_L1') {
> +    guest_editconfig_cd($gho);
> +} else {
> +    guest_editconfig_nocd($gho,$emptyiso);
> +}
>  guest_create($gho,$toolstack);
>  guest_await_dhcp_tcp($gho,300);
>  guest_check_up($gho);
> +if ($nested_L1 eq 'nested_L1') {
> +    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 Thu Dec 11 11:07:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11:07:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz1aN-0005NG-Ah; Thu, 11 Dec 2014 11:07:07 +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 1Xz1aM-0005NB-4s
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 11:07:06 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	24/20-02954-9DA79845; Thu, 11 Dec 2014 11:07:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418296022!14322047!1
X-Originating-IP: [66.165.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 26775 invoked from network); 11 Dec 2014 11:07:04 -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;
	11 Dec 2014 11:07:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203294500"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 06:06: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 1Xz1Zo-00082k-UU;
	Thu, 11 Dec 2014 11:06:32 +0000
Date: Thu, 11 Dec 2014 11:06:32 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: longtao.pang <longtaox.pang@intel.com>
Message-ID: <20141211110632.GC21659@zion.uk.xensource.com>
References: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
	<1418198860-29802-2-git-send-email-longtaox.pang@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418198860-29802-2-git-send-email-longtaox.pang@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, robert.hu@intel.com, di.zheng@intel.com
Subject: Re: [Xen-devel] [OSSTEST PATCH 1/4] Add nested testcase of
 preparing and installing 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 04:07:37PM +0800, longtao.pang wrote:
> 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      |   27 ++++++++++++++++++---------
>  Osstest/TestSupport.pm |   31 ++++++++++++++++++++++++++-----
>  sg-run-job             |    5 +++++
>  ts-debian-hvm-install  |   34 ++++++++++++++++++++++++----------
>  4 files changed, 73 insertions(+), 24 deletions(-)
> 
> diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> index c8db601..a671d20 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
> @@ -34,6 +35,7 @@ BEGIN {
>      @EXPORT      = qw(debian_boot_setup
>                        %preseed_cmds
>                        preseed_base
> +                      setupboot_grub2

Why do you want to export this helper? I think debian_setup_boot will
just choose the right one amongst uboot, grub1 and grub2.

>                        preseed_create
>                        preseed_hook_command preseed_hook_installscript
>                        di_installcmdline_core
> @@ -286,15 +288,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));

Please don't make non-functional change like this.

>  		if (@missing) {
>  		    logm("(skipping entry at $entry->{StartLine};".
>  			 " no @missing)");
> @@ -317,21 +322,25 @@ 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\S+)/) {
> +#	    if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {

And if this line is redundant, remove it. What's the reason of changing
this regex? Are you using non-debian based distro?

>                  die unless $entry;
>                  $entry->{Hv}= $1;
>              }
> -            if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
> +	    if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {

And this?

>                  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;
>              }
>          }

As I said before, this hunk should be in its own patch.

Just FYI, there are multiple people (Dario, you and I) touching this
piece of code. You might want to keep an eye on main OSSTest git tree
and rebase before reposting (and so do Dario and I).

> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index a3b6936..1e47039 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

Please don't just change white spaces. This makes patches hard to
review.

>                        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

Indentation. I think we mostly use space instead of hard tab. Ian?

>                        );
>      %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 @_;
> @@ -717,6 +727,7 @@ sub power_cycle_time ($) {
>  sub power_cycle ($) {
>      my ($ho) = @_;
>      $mjobdb->host_check_allocated($ho);
> +    $mjobdb->xen_check_installed($ho);

And this is? I don't see implementation in this patch set.

Also this routine is called by ts-host-install, which doesn't necessary
require Xen to be installed.

>      die "refusing to set power state for host $ho->{Name}".
>  	" possibly shared with other jobs\n"
>  	if $ho->{SharedMaybeOthers};
> @@ -937,7 +948,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 {

This should go into its own patch as well. I think it's probably nested
virt is slower than real hardware so you need some more time?

>          my $output;
>          if (!eval {
>              $output= target_cmd_output($ho, <<END, 40);
> @@ -1465,7 +1476,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}' ]

What is this needed? If it's necessary, please use a single commit and
state the reason in commit log.

>  #
>  on_poweroff = 'destroy'
>  on_reboot   = '$onreboot'
> @@ -2063,4 +2074,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/;

This pattern is different than the one used to match. This should also
go into its own commit -- "Introduce guest_editconfig_cd".

> +        }
> +        s/^on_reboot.*/on_reboot='restart'/;
> +    });
> +}
> +
>  1;
> diff --git a/sg-run-job b/sg-run-job
> index 2cf810a..8dcf7af 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-debian-hvm-install + host + nested + nested_L1
> +}
> +
>  proc test-guest-migr {g} {
>      if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
>  

This hunk should go into its own commit.

> diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
> index 37eade2..6dcec3c 100755
> --- a/ts-debian-hvm-install
> +++ b/ts-debian-hvm-install

The modification of debian-hvm-install should also go into a single
commit.

> @@ -28,22 +28,24 @@ 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;
> +our ($whhost,$gn,$nested_L1,$guesthost) = @ARGV;
>  $whhost ||= 'host';
> -$gn ||= 'debianhvm';
> -
> +$nested_L1 ||= '';
> +if ($nested_L1 eq 'nested_L1') {
> +    $gn ||= 'nested';
> +    $guesthost ||= "$gn.l1.osstest";
> +} else {
> +    $gn ||= 'debianhvm';
> +    $guesthost= "$gn.guest.osstest";
> +}
>  our $ho= selecthost($whhost);
> -
> +our $disk_mb= 50000;
>  # guest memory size will be set based on host free memory, see below
>  our $ram_mb;
> -our $disk_mb= 10000;
> -
> -our $guesthost= "$gn.guest.osstest";
>  our $gho;
>  
>  our $toolstack= toolstack()->{Command};
>  
> -

Stray blank line change. Please avoid this kind of changes.

>  sub preseed () {
>  
>      my $preseed_file = preseed_base('wheezy','',());
> @@ -63,7 +65,7 @@ d-i partman-auto/expert_recipe string \\
>                          use_filesystem{ } filesystem{ vfat } \\
>                          mountpoint{ /boot/efi } \\
>                  . \\
> -                5000 50 5000 ext4 \\
> +                25000 50 25000 ext4 \\
>                          method{ format } format{ } \\
>                          use_filesystem{ } filesystem{ ext4 } \\
>                          mountpoint{ / } \\
> @@ -155,6 +157,8 @@ sub prep () {
>      more_prepareguest_hvm($ho,$gho, $ram_mb, $disk_mb,
>                            OnReboot => 'preserve',
>                            Bios => $r{bios},
> +                          DefVcpus => 4,

And where is this handled?

Wei.

> +                          ExtraConfig => '#nestedhvm=1',
>                            PostImageHook => sub {
>          my $cmds = iso_copy_content_from_image($gho, $newiso);
>          $cmds .= prepare_initrd($initrddir,$newiso,$preseed_file_path);
> @@ -176,6 +180,8 @@ my $ram_minslop = 100;
>  my $ram_lots = 5000;
>  if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
>      $ram_mb = $ram_lots;
> +} elsif ($nested_L1 eq 'nested_L1') {
> +    $ram_mb = 2048;
>  } else {
>      $ram_mb = 768;
>  }
> @@ -192,7 +198,15 @@ if ($stage<2) {
>      guest_destroy($ho,$gho);
>  }
>  
> -guest_editconfig_nocd($gho,$emptyiso);
> +if ($nested_L1 eq 'nested_L1') {
> +    guest_editconfig_cd($gho);
> +} else {
> +    guest_editconfig_nocd($gho,$emptyiso);
> +}
>  guest_create($gho,$toolstack);
>  guest_await_dhcp_tcp($gho,300);
>  guest_check_up($gho);
> +if ($nested_L1 eq 'nested_L1') {
> +    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 Thu Dec 11 11:10:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11: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 1Xz1d0-0005US-2K; Thu, 11 Dec 2014 11:09: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 1Xz1cy-0005UL-Cw
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 11:09:48 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	A3/8F-22777-B7B79845; Thu, 11 Dec 2014 11:09:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418296185!12759682!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8294 invoked from network); 11 Dec 2014 11:09:46 -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;
	11 Dec 2014 11:09:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203295639"
Message-ID: <54897B76.6070500@citrix.com>
Date: Thu, 11 Dec 2014 11:09:42 +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: Andy Lutomirski <luto@amacapital.net>, "Luis R. Rodriguez"
	<mcgrof@do-not-panic.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
In-Reply-To: <CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>, Peter Zijlstra <peterz@infradead.org>,
	"Luis R. Rodriguez" <mcgrof@suse.com>, X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
 be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 23:51, Andy Lutomirski wrote:
> On Wed, Dec 10, 2014 at 3:34 PM, Luis R. Rodriguez
>> --- a/arch/x86/kernel/entry_64.S
>> +++ b/arch/x86/kernel/entry_64.S
>> @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
>>         popq %rsp
>>         CFI_DEF_CFA_REGISTER rsp
>>         decl PER_CPU_VAR(irq_count)
>> +#ifdef CONFIG_PREEMPT
>>         jmp  error_exit
>> +#else
>> +       movl %ebx, %eax
>> +       RESTORE_REST
>> +       DISABLE_INTERRUPTS(CLBR_NONE)
>> +       TRACE_IRQS_OFF
>> +       GET_THREAD_INFO(%rcx)
>> +       testl %eax, %eax
>> +       je error_exit_user
>> +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
>> +       jz retint_kernel
> 
> I think I understand this part.
> 
>> +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> 
> Why?  Is the issue that, if preemptible hypercalls nest, you don't
> want to preempt again?

We need to clear and reset this per-cpu variable around the schedule
point since the current task may be rescheduled on a different CPU, or
we may switch to a task that was previously preempted at this point.

That this prevents nested preemption is fine because we only want
hypercalls issued by the privcmd driver on behalf of userspace to be
preemptible.

>> +       call cond_resched_irq
> 
> On !CONFIG_PREEMPT, there's no preempt_disable, right?  So how do you
> guarantee that you don't preempt something you shouldn't?  Is the idea
> that these events will only fire nested *directly* inside a
> preemptible hypercall?  Also, should you check that IRQs were on when
> the event fired?  (Are they on in pt_regs?)

Testing xen_in_preemptible_hcall is sufficient.  We bracket the
hypercalls we want to be preemptible like so:

	xen_preemptible_hcall_begin();
 	ret = privcmd_call(hypercall.op,
 			   hypercall.arg[0], hypercall.arg[1],
 			   hypercall.arg[2], hypercall.arg[3],
 			   hypercall.arg[4]);
	xen_preemptible_hcall_end();

begin() and end() are somewhat like a Xen-specific prempt_enable() and
preempt_disable(), overriding the default no-preempt state.

>> +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
>> +       jmp retint_kernel
>> +#endif /* CONFIG_PREEMPT */
>>         CFI_ENDPROC
> 
> All that being said, this is IMO a bit gross.  You've added a bunch of
> asm that's kind of like a parallel error_exit, and the error entry and
> exit code is hairy enough that this scares me.  Can you do this mostly
> in C instead?  This would look a nicer if it could be:

I abandoned my initial attempt that looked like this because I thought
it was gross too.

>     call xen_evtchn_do_upcall
>     popq %rsp
>     CFI_DEF_CFA_REGISTER rsp
>     decl PER_CPU_VAR(irq_count)
> +  call xen_end_upcall
>     jmp error_exit
> 
> Where xen_end_upcall would be witten in C, nokprobes and notrace (if
> needed) and would check pt_regs and whatever else and just call
> schedule if needed?

Oh that's a good idea, thanks!

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 11:10:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11: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 1Xz1d0-0005US-2K; Thu, 11 Dec 2014 11:09: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 1Xz1cy-0005UL-Cw
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 11:09:48 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	A3/8F-22777-B7B79845; Thu, 11 Dec 2014 11:09:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418296185!12759682!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8294 invoked from network); 11 Dec 2014 11:09:46 -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;
	11 Dec 2014 11:09:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203295639"
Message-ID: <54897B76.6070500@citrix.com>
Date: Thu, 11 Dec 2014 11:09:42 +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: Andy Lutomirski <luto@amacapital.net>, "Luis R. Rodriguez"
	<mcgrof@do-not-panic.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
In-Reply-To: <CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>, Peter Zijlstra <peterz@infradead.org>,
	"Luis R. Rodriguez" <mcgrof@suse.com>, X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
 be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 23:51, Andy Lutomirski wrote:
> On Wed, Dec 10, 2014 at 3:34 PM, Luis R. Rodriguez
>> --- a/arch/x86/kernel/entry_64.S
>> +++ b/arch/x86/kernel/entry_64.S
>> @@ -1170,7 +1170,23 @@ ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
>>         popq %rsp
>>         CFI_DEF_CFA_REGISTER rsp
>>         decl PER_CPU_VAR(irq_count)
>> +#ifdef CONFIG_PREEMPT
>>         jmp  error_exit
>> +#else
>> +       movl %ebx, %eax
>> +       RESTORE_REST
>> +       DISABLE_INTERRUPTS(CLBR_NONE)
>> +       TRACE_IRQS_OFF
>> +       GET_THREAD_INFO(%rcx)
>> +       testl %eax, %eax
>> +       je error_exit_user
>> +       cmpb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
>> +       jz retint_kernel
> 
> I think I understand this part.
> 
>> +       movb $0,PER_CPU_VAR(xen_in_preemptible_hcall)
> 
> Why?  Is the issue that, if preemptible hypercalls nest, you don't
> want to preempt again?

We need to clear and reset this per-cpu variable around the schedule
point since the current task may be rescheduled on a different CPU, or
we may switch to a task that was previously preempted at this point.

That this prevents nested preemption is fine because we only want
hypercalls issued by the privcmd driver on behalf of userspace to be
preemptible.

>> +       call cond_resched_irq
> 
> On !CONFIG_PREEMPT, there's no preempt_disable, right?  So how do you
> guarantee that you don't preempt something you shouldn't?  Is the idea
> that these events will only fire nested *directly* inside a
> preemptible hypercall?  Also, should you check that IRQs were on when
> the event fired?  (Are they on in pt_regs?)

Testing xen_in_preemptible_hcall is sufficient.  We bracket the
hypercalls we want to be preemptible like so:

	xen_preemptible_hcall_begin();
 	ret = privcmd_call(hypercall.op,
 			   hypercall.arg[0], hypercall.arg[1],
 			   hypercall.arg[2], hypercall.arg[3],
 			   hypercall.arg[4]);
	xen_preemptible_hcall_end();

begin() and end() are somewhat like a Xen-specific prempt_enable() and
preempt_disable(), overriding the default no-preempt state.

>> +       movb $1,PER_CPU_VAR(xen_in_preemptible_hcall)
>> +       jmp retint_kernel
>> +#endif /* CONFIG_PREEMPT */
>>         CFI_ENDPROC
> 
> All that being said, this is IMO a bit gross.  You've added a bunch of
> asm that's kind of like a parallel error_exit, and the error entry and
> exit code is hairy enough that this scares me.  Can you do this mostly
> in C instead?  This would look a nicer if it could be:

I abandoned my initial attempt that looked like this because I thought
it was gross too.

>     call xen_evtchn_do_upcall
>     popq %rsp
>     CFI_DEF_CFA_REGISTER rsp
>     decl PER_CPU_VAR(irq_count)
> +  call xen_end_upcall
>     jmp error_exit
> 
> Where xen_end_upcall would be witten in C, nokprobes and notrace (if
> needed) and would check pt_regs and whatever else and just call
> schedule if needed?

Oh that's a good idea, thanks!

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 11:28:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11: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 1Xz1ue-0006KW-On; Thu, 11 Dec 2014 11: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.Campbell@citrix.com>) id 1Xz1ud-0006KR-Fx
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 11:28:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D0/E9-09842-2CF79845; Thu, 11 Dec 2014 11:28:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418297280!14877388!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 26156 invoked from network); 11 Dec 2014 11:28:01 -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;
	11 Dec 2014 11:28:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203299976"
Message-ID: <1418297279.10394.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mao Mingya <maomingya928@gmail.com>
Date: Thu, 11 Dec 2014 11:27:59 +0000
In-Reply-To: <em10f4478b-5649-4f26-a846-8d4f8298c95f@sgp1030c>
References: <em10f4478b-5649-4f26-a846-8d4f8298c95f@sgp1030c>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] arch arm qemu compile erro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-11 at 01:52 +0000, Mao Mingya wrote:
> >Yes, qemu can be used to provide PV backends for: disk (using qdisk),
> >framebuffer, kbd and mouse.
> Thank you for the detail explanation.
> What is the best pv backend on arch arm? qemu-upstream, 
> qemu-xen-traditional, or anything else?

There is no one pv backend, it is a per device type thing.

For disk, blkback (in backend kernel driver) is best if your guest disks
are backed by raw disks (e.g. lvm volumes in the backend), qdisk (from
qemu-upstream) is best if your guest disks are backed by something more
complex, like a qcow2 file.

For network netback (in kernel backend driver) is best.

For PVFB, PVKBD and PVMOUSE qemu-upstream is the best (only?) backend.

There is no qemu-xen-trad on ARM, I don't expect anyone to port it and I
wouldn't expect those patches to be accepted anyway.

> Is there any guild doc to get it work on arch arm?

I'm not sure what "it" refers to here. PV backends generally are part of
all the docs on the wiki explaining how to get Xen to work, there is not
generally a separate guide for them since they are part of the core
concept.

qemu-upstream is built along with Xen on ARM for a while (not 4.4,
4.5-rcN should be fine), the in kernel backends have been available for
longer than Xen on ARM has been.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 11:28:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11: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 1Xz1ue-0006KW-On; Thu, 11 Dec 2014 11: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.Campbell@citrix.com>) id 1Xz1ud-0006KR-Fx
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 11:28:03 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D0/E9-09842-2CF79845; Thu, 11 Dec 2014 11:28:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418297280!14877388!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 26156 invoked from network); 11 Dec 2014 11:28:01 -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;
	11 Dec 2014 11:28:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203299976"
Message-ID: <1418297279.10394.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mao Mingya <maomingya928@gmail.com>
Date: Thu, 11 Dec 2014 11:27:59 +0000
In-Reply-To: <em10f4478b-5649-4f26-a846-8d4f8298c95f@sgp1030c>
References: <em10f4478b-5649-4f26-a846-8d4f8298c95f@sgp1030c>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] arch arm qemu compile erro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-11 at 01:52 +0000, Mao Mingya wrote:
> >Yes, qemu can be used to provide PV backends for: disk (using qdisk),
> >framebuffer, kbd and mouse.
> Thank you for the detail explanation.
> What is the best pv backend on arch arm? qemu-upstream, 
> qemu-xen-traditional, or anything else?

There is no one pv backend, it is a per device type thing.

For disk, blkback (in backend kernel driver) is best if your guest disks
are backed by raw disks (e.g. lvm volumes in the backend), qdisk (from
qemu-upstream) is best if your guest disks are backed by something more
complex, like a qcow2 file.

For network netback (in kernel backend driver) is best.

For PVFB, PVKBD and PVMOUSE qemu-upstream is the best (only?) backend.

There is no qemu-xen-trad on ARM, I don't expect anyone to port it and I
wouldn't expect those patches to be accepted anyway.

> Is there any guild doc to get it work on arch arm?

I'm not sure what "it" refers to here. PV backends generally are part of
all the docs on the wiki explaining how to get Xen to work, there is not
generally a separate guide for them since they are part of the core
concept.

qemu-upstream is built along with Xen on ARM for a while (not 4.4,
4.5-rcN should be fine), the in kernel backends have been available for
longer than Xen on ARM has been.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 11:32:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11: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 1Xz1yc-0006jR-DV; Thu, 11 Dec 2014 11:32: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 1Xz1yb-0006jM-4t
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 11:32:09 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	A6/AC-19763-8B089845; Thu, 11 Dec 2014 11:32:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418297526!7493797!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 11597 invoked from network); 11 Dec 2014 11:32:07 -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;
	11 Dec 2014 11:32:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202897043"
Message-ID: <1418297524.10394.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Balbir Singh <bsingharora@gmail.com>
Date: Thu, 11 Dec 2014 11:32:04 +0000
In-Reply-To: <CAKTCnz=EecqWfrWkH1+pCfCLCF1F6Bt63sJBfT_oWayXr3F7cg@mail.gmail.com>
References: <CAKTCnznScui38+ec50U0dkCvWK2jA4cHEmqgaf1USj23k6CE5g@mail.gmail.com>
	<1418219759.3505.56.camel@citrix.com>
	<CAKTCnz=EecqWfrWkH1+pCfCLCF1F6Bt63sJBfT_oWayXr3F7cg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Frozen dom0 xl commands
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-12-11 at 09:27 +0530, Balbir Singh wrote:

Please don't top post.

> Good catch Ian!
> 
> You are absolutely right!

Oh good.

>  I built everything and it put the tools/etc
> in /usr/local. I did not see a link to xencommons, I missed it
> completely! Is there any thing else I should care about - any other
> daemons/bridge to be setup?

http://wiki.xen.org/wiki/Compiling_Xen_From_Source covers a bunch of it
and links to 
http://wiki.xen.org/wiki/Category:Host_Configuration which has links to
various other things you might want to consider.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 11:32:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11: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 1Xz1yc-0006jR-DV; Thu, 11 Dec 2014 11:32: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 1Xz1yb-0006jM-4t
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 11:32:09 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	A6/AC-19763-8B089845; Thu, 11 Dec 2014 11:32:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418297526!7493797!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 11597 invoked from network); 11 Dec 2014 11:32:07 -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;
	11 Dec 2014 11:32:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202897043"
Message-ID: <1418297524.10394.9.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Balbir Singh <bsingharora@gmail.com>
Date: Thu, 11 Dec 2014 11:32:04 +0000
In-Reply-To: <CAKTCnz=EecqWfrWkH1+pCfCLCF1F6Bt63sJBfT_oWayXr3F7cg@mail.gmail.com>
References: <CAKTCnznScui38+ec50U0dkCvWK2jA4cHEmqgaf1USj23k6CE5g@mail.gmail.com>
	<1418219759.3505.56.camel@citrix.com>
	<CAKTCnz=EecqWfrWkH1+pCfCLCF1F6Bt63sJBfT_oWayXr3F7cg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Frozen dom0 xl commands
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-12-11 at 09:27 +0530, Balbir Singh wrote:

Please don't top post.

> Good catch Ian!
> 
> You are absolutely right!

Oh good.

>  I built everything and it put the tools/etc
> in /usr/local. I did not see a link to xencommons, I missed it
> completely! Is there any thing else I should care about - any other
> daemons/bridge to be setup?

http://wiki.xen.org/wiki/Compiling_Xen_From_Source covers a bunch of it
and links to 
http://wiki.xen.org/wiki/Category:Host_Configuration which has links to
various other things you might want to consider.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 11:34:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11: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 1Xz20H-0006q4-U0; Thu, 11 Dec 2014 11:33: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 1Xz20F-0006pw-TU
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 11:33:52 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	A1/EE-23865-F1189845; Thu, 11 Dec 2014 11:33:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418297628!12595078!1
X-Originating-IP: [66.165.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 4632 invoked from network); 11 Dec 2014 11:33: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;
	11 Dec 2014 11:33:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203301403"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 06:33: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 1Xz1rh-0000MS-Qj;
	Thu, 11 Dec 2014 11:25:01 +0000
Date: Thu, 11 Dec 2014 11:25:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: longtao.pang <longtaox.pang@intel.com>
Message-ID: <20141211112501.GD21659@zion.uk.xensource.com>
References: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
	<1418198860-29802-3-git-send-email-longtaox.pang@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418198860-29802-3-git-send-email-longtaox.pang@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, robert.hu@intel.com, di.zheng@intel.com
Subject: Re: [Xen-devel] [OSSTEST PATCH 2/4] Build 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 04:07:38PM +0800, longtao.pang wrote:
> 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.
> 

I think you can just use the L0 Xen and Dom0 kernel, that would save you
lots of time running this test case. It can also help simplifies this
patch, maybe?

> ---
>  sg-run-job     |    1 +
>  ts-xen-install |  149 +++++++++++++++++++++++++++++++++++++++++---------------
>  2 files changed, 111 insertions(+), 39 deletions(-)
> 
> diff --git a/sg-run-job b/sg-run-job
> index 8dcf7af..e513bd1 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-debian-hvm-install + host + nested + nested_L1
> +    run-ts . = ts-xen-install + host + nested + nested_build
>  }
>  
>  proc test-guest-migr {g} {
> diff --git a/ts-xen-install b/ts-xen-install
> index 4d34d1f..c175d6d 100755
> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -28,19 +28,25 @@ use Osstest::CXFabric;
>  my $checkmode= 0;
>  
>  tsreadconfig();
> -
> +our $w_ho;
>  our @hos;
> -
> -if (@ARGV and $ARGV[0] eq '--check') {
> -    $checkmode= 1;
> -    shift @ARGV;
> -    logm("checking builds are done...");
> +our ($whhost,$gn,$nested_build) = @ARGV;
> +$nested_build ||= '';
> +if ($nested_build eq 'nested_build') {
> +    $whhost ||= 'host';
> +    $gn ||= 'nested';
>  } else {
> -    if (!@ARGV) {
> -	push @ARGV, 'host';
> -    }
> -    foreach my $k (@ARGV) {
> -        push @hos, selecthost($k);
> +    if (@ARGV and $ARGV[0] eq '--check') {
> +        $checkmode= 1;
> +        shift @ARGV;
> +        logm("checking builds are done...");
> +    } else {
> +        if (!@ARGV) {
> +            push @ARGV, 'host';
> +        }
> +        foreach my $k (@ARGV) {
> +            push @hos, selecthost($k);
> +        }
>      }
>  }
>  
> @@ -49,18 +55,18 @@ our $ho;
>  my %distpath;
>  
>  sub packages () {
> -    target_install_packages($ho,
> +    target_install_packages($w_ho,
>                              qw(bridge-utils vncsnapshot libaio1 libpixman-1-0
>                                 libsdl1.2debian libglib2.0-0 liblzma5));
> -    target_install_packages($ho,
> +    target_install_packages($w_ho,
>  			    $ho->{Suite} =~ /squeeze/ ? "libyajl1" : "libyajl2");
>      if ($ho->{Suite} !~ m/lenny|squeeze/) {
> -        target_install_packages($ho, 'libfdt1');
> +        target_install_packages($w_ho, 'libfdt1');
>      }
>      if ($r{arch} eq 'i386') {
> -	target_install_packages($ho, 'libc6-xen');
> +	target_install_packages($w_ho, 'libc6-xen');
>      }
> -    target_install_packages($ho, @{toolstack()->{ExtraPackages}})
> +    target_install_packages($w_ho, @{toolstack()->{ExtraPackages}})
>          if toolstack()->{ExtraPackages};
>  }
>  
> @@ -69,14 +75,14 @@ sub extract () {
>      push @parts, 'libvirt' if $r{toolstack} eq "libvirt";
>  
>      foreach my $part (@parts) {
> -        target_extract_jobdistpath($ho, $part, "path_${part}dist",
> +        target_extract_jobdistpath($w_ho, $part, "path_${part}dist",
>  				   $r{"${part}buildjob"}, \%distpath);
>      }
> -    target_cmd_root($ho, '/sbin/ldconfig');
> +    target_cmd_root($w_ho, '/sbin/ldconfig');
>  }
>  
>  sub adjustconfig () {
> -    target_editfile_root($ho, "/etc/xen/xend-config.sxp",
> +    target_editfile_root($w_ho, "/etc/xen/xend-config.sxp",
>  			 "xend-config.sxp", sub {
>  	my (@domains) = (qw(localhost localhost.localdomain),
>  			 ".".$c{DnsDomain}, ".".$c{TestHostDomain});
> @@ -108,13 +114,13 @@ sub adjustconfig () {
>                          /etc/sysconfig/xencommons
>                          /etc/default/xend
>                          /etc/sysconfig/xend)) {
> -        next unless target_file_exists($ho, $try);
> +        next unless target_file_exists($w_ho, $try);
>          $trace_config_file= $try;
>          last;
>      }
>      die unless defined $trace_config_file;
>  
> -    target_editfile_root($ho, $trace_config_file, sub {
> +    target_editfile_root($w_ho, $trace_config_file, sub {
>          my $prnow;
>          $prnow= sub {
>              print EO "XENCONSOLED_TRACE=guest\n" or die $!;
> @@ -128,7 +134,7 @@ sub adjustconfig () {
>          $prnow->();
>      });
>  
> -    target_cmd_root($ho, 'mkdir -p /var/log/xen/console');
> +    target_cmd_root($w_ho, 'mkdir -p /var/log/xen/console');
>  
>      setup_cxfabric($ho);
>  }
> @@ -156,19 +162,19 @@ sub setupboot () {
>      $xenhopt .= " $append" if defined $append;
>  
>      my @hooks;
> -
> +    
>      if (host_involves_pcipassthrough($ho)) {
>          push @hooks, {
>              EditBootOptions => sub {
>                  my ($ho,$hopt,$kopt) = @_;
>                  $$hopt .= ' iommu=on';
>                  my $hide= ' xen-pciback.hide='. join '',map { "($_->{Bdf})" }
> -                    host_get_pcipassthrough_devs($ho);
> +                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($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
> @@ -182,7 +188,7 @@ sub setupinitd () {
>      my $ts= toolstack();
>      my $xencommons= '/etc/init.d/xencommons';
>      my $have_xencommons=
> -        !!target_cmd_output_root($ho, <<END);
> +        !!target_cmd_output_root($w_ho, <<END);
>   if test -f $xencommons && ! grep 'FOR USE WITH LIBXL' $xencommons >/dev/null
>   then
>     echo y
> @@ -211,7 +217,33 @@ END
>          $updatercd->($initd,93) if defined $initd;
>          $updatercd->('xenbridge',38) if $ts->{OldSeparateBridgeInitd};
>      }
> -    target_cmd_root($ho, $cmd);
> +    target_cmd_root($w_ho, $cmd);
> +}
> +
> +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");
>  }

FWIW, OSSTest has a bunch of overlay files (look at overlay directory),
which includes an init script called xenbridge. In theory if you're
reusing this script (ts-xen-install) then you don't need to worry about
setting up bridge?

>  
>  sub nodhcp () {
> @@ -322,17 +354,56 @@ sub forbidden () {
>  END
>  }
>  
> -if ($checkmode) {
> -    extract();
> -} else {
> -    die if @hos > 1;
> -    $ho= $hos[0];
> -    
> +if ($nested_build eq 'nested_build') {
> +    our $gho;
> +    $ho= selecthost($whhost);
> +    $gho= selectguest($gn,$ho);
> +    $w_ho = $gho;
> +    store_runvar("$gho->{Guest}_kernkind",$r{'kernkind'});
> +    $gho->{Suite}=$ho->{Suite};
> +
> +    guest_check_ip($gho);
>      packages();
>      extract();
> -    forbidden();
>      adjustconfig();
> -    setupboot();
> -    setupinitd();
> -    nodhcp();
> +    my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
> +    my $bootloader;
> +    $bootloader=setupboot_grub2($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
> +
> +    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);
> +

This hunk is copied from Debian.pm. If debian_setup_boot cannot meet
your requirement, please refactor it.

Wei.

> +    
> +} else {
> +
> +    if ($checkmode) {
> +        extract();
> +    } else {
> +        die if @hos > 1;
> +        $ho= $hos[0];
> +        $w_ho = $ho;
> +        packages();
> +        extract();
> +        forbidden();
> +        adjustconfig();
> +        setupboot();
> +        setupinitd();
> +        nodhcp();
> +    }
>  }
> -- 
> 1.7.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 Dec 11 11:34:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11: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 1Xz20H-0006q4-U0; Thu, 11 Dec 2014 11:33: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 1Xz20F-0006pw-TU
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 11:33:52 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	A1/EE-23865-F1189845; Thu, 11 Dec 2014 11:33:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-31.messagelabs.com!1418297628!12595078!1
X-Originating-IP: [66.165.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 4632 invoked from network); 11 Dec 2014 11:33: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;
	11 Dec 2014 11:33:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203301403"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 06:33: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 1Xz1rh-0000MS-Qj;
	Thu, 11 Dec 2014 11:25:01 +0000
Date: Thu, 11 Dec 2014 11:25:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: longtao.pang <longtaox.pang@intel.com>
Message-ID: <20141211112501.GD21659@zion.uk.xensource.com>
References: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
	<1418198860-29802-3-git-send-email-longtaox.pang@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418198860-29802-3-git-send-email-longtaox.pang@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, robert.hu@intel.com, di.zheng@intel.com
Subject: Re: [Xen-devel] [OSSTEST PATCH 2/4] Build 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 04:07:38PM +0800, longtao.pang wrote:
> 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.
> 

I think you can just use the L0 Xen and Dom0 kernel, that would save you
lots of time running this test case. It can also help simplifies this
patch, maybe?

> ---
>  sg-run-job     |    1 +
>  ts-xen-install |  149 +++++++++++++++++++++++++++++++++++++++++---------------
>  2 files changed, 111 insertions(+), 39 deletions(-)
> 
> diff --git a/sg-run-job b/sg-run-job
> index 8dcf7af..e513bd1 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-debian-hvm-install + host + nested + nested_L1
> +    run-ts . = ts-xen-install + host + nested + nested_build
>  }
>  
>  proc test-guest-migr {g} {
> diff --git a/ts-xen-install b/ts-xen-install
> index 4d34d1f..c175d6d 100755
> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -28,19 +28,25 @@ use Osstest::CXFabric;
>  my $checkmode= 0;
>  
>  tsreadconfig();
> -
> +our $w_ho;
>  our @hos;
> -
> -if (@ARGV and $ARGV[0] eq '--check') {
> -    $checkmode= 1;
> -    shift @ARGV;
> -    logm("checking builds are done...");
> +our ($whhost,$gn,$nested_build) = @ARGV;
> +$nested_build ||= '';
> +if ($nested_build eq 'nested_build') {
> +    $whhost ||= 'host';
> +    $gn ||= 'nested';
>  } else {
> -    if (!@ARGV) {
> -	push @ARGV, 'host';
> -    }
> -    foreach my $k (@ARGV) {
> -        push @hos, selecthost($k);
> +    if (@ARGV and $ARGV[0] eq '--check') {
> +        $checkmode= 1;
> +        shift @ARGV;
> +        logm("checking builds are done...");
> +    } else {
> +        if (!@ARGV) {
> +            push @ARGV, 'host';
> +        }
> +        foreach my $k (@ARGV) {
> +            push @hos, selecthost($k);
> +        }
>      }
>  }
>  
> @@ -49,18 +55,18 @@ our $ho;
>  my %distpath;
>  
>  sub packages () {
> -    target_install_packages($ho,
> +    target_install_packages($w_ho,
>                              qw(bridge-utils vncsnapshot libaio1 libpixman-1-0
>                                 libsdl1.2debian libglib2.0-0 liblzma5));
> -    target_install_packages($ho,
> +    target_install_packages($w_ho,
>  			    $ho->{Suite} =~ /squeeze/ ? "libyajl1" : "libyajl2");
>      if ($ho->{Suite} !~ m/lenny|squeeze/) {
> -        target_install_packages($ho, 'libfdt1');
> +        target_install_packages($w_ho, 'libfdt1');
>      }
>      if ($r{arch} eq 'i386') {
> -	target_install_packages($ho, 'libc6-xen');
> +	target_install_packages($w_ho, 'libc6-xen');
>      }
> -    target_install_packages($ho, @{toolstack()->{ExtraPackages}})
> +    target_install_packages($w_ho, @{toolstack()->{ExtraPackages}})
>          if toolstack()->{ExtraPackages};
>  }
>  
> @@ -69,14 +75,14 @@ sub extract () {
>      push @parts, 'libvirt' if $r{toolstack} eq "libvirt";
>  
>      foreach my $part (@parts) {
> -        target_extract_jobdistpath($ho, $part, "path_${part}dist",
> +        target_extract_jobdistpath($w_ho, $part, "path_${part}dist",
>  				   $r{"${part}buildjob"}, \%distpath);
>      }
> -    target_cmd_root($ho, '/sbin/ldconfig');
> +    target_cmd_root($w_ho, '/sbin/ldconfig');
>  }
>  
>  sub adjustconfig () {
> -    target_editfile_root($ho, "/etc/xen/xend-config.sxp",
> +    target_editfile_root($w_ho, "/etc/xen/xend-config.sxp",
>  			 "xend-config.sxp", sub {
>  	my (@domains) = (qw(localhost localhost.localdomain),
>  			 ".".$c{DnsDomain}, ".".$c{TestHostDomain});
> @@ -108,13 +114,13 @@ sub adjustconfig () {
>                          /etc/sysconfig/xencommons
>                          /etc/default/xend
>                          /etc/sysconfig/xend)) {
> -        next unless target_file_exists($ho, $try);
> +        next unless target_file_exists($w_ho, $try);
>          $trace_config_file= $try;
>          last;
>      }
>      die unless defined $trace_config_file;
>  
> -    target_editfile_root($ho, $trace_config_file, sub {
> +    target_editfile_root($w_ho, $trace_config_file, sub {
>          my $prnow;
>          $prnow= sub {
>              print EO "XENCONSOLED_TRACE=guest\n" or die $!;
> @@ -128,7 +134,7 @@ sub adjustconfig () {
>          $prnow->();
>      });
>  
> -    target_cmd_root($ho, 'mkdir -p /var/log/xen/console');
> +    target_cmd_root($w_ho, 'mkdir -p /var/log/xen/console');
>  
>      setup_cxfabric($ho);
>  }
> @@ -156,19 +162,19 @@ sub setupboot () {
>      $xenhopt .= " $append" if defined $append;
>  
>      my @hooks;
> -
> +    
>      if (host_involves_pcipassthrough($ho)) {
>          push @hooks, {
>              EditBootOptions => sub {
>                  my ($ho,$hopt,$kopt) = @_;
>                  $$hopt .= ' iommu=on';
>                  my $hide= ' xen-pciback.hide='. join '',map { "($_->{Bdf})" }
> -                    host_get_pcipassthrough_devs($ho);
> +                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($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
> @@ -182,7 +188,7 @@ sub setupinitd () {
>      my $ts= toolstack();
>      my $xencommons= '/etc/init.d/xencommons';
>      my $have_xencommons=
> -        !!target_cmd_output_root($ho, <<END);
> +        !!target_cmd_output_root($w_ho, <<END);
>   if test -f $xencommons && ! grep 'FOR USE WITH LIBXL' $xencommons >/dev/null
>   then
>     echo y
> @@ -211,7 +217,33 @@ END
>          $updatercd->($initd,93) if defined $initd;
>          $updatercd->('xenbridge',38) if $ts->{OldSeparateBridgeInitd};
>      }
> -    target_cmd_root($ho, $cmd);
> +    target_cmd_root($w_ho, $cmd);
> +}
> +
> +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");
>  }

FWIW, OSSTest has a bunch of overlay files (look at overlay directory),
which includes an init script called xenbridge. In theory if you're
reusing this script (ts-xen-install) then you don't need to worry about
setting up bridge?

>  
>  sub nodhcp () {
> @@ -322,17 +354,56 @@ sub forbidden () {
>  END
>  }
>  
> -if ($checkmode) {
> -    extract();
> -} else {
> -    die if @hos > 1;
> -    $ho= $hos[0];
> -    
> +if ($nested_build eq 'nested_build') {
> +    our $gho;
> +    $ho= selecthost($whhost);
> +    $gho= selectguest($gn,$ho);
> +    $w_ho = $gho;
> +    store_runvar("$gho->{Guest}_kernkind",$r{'kernkind'});
> +    $gho->{Suite}=$ho->{Suite};
> +
> +    guest_check_ip($gho);
>      packages();
>      extract();
> -    forbidden();
>      adjustconfig();
> -    setupboot();
> -    setupinitd();
> -    nodhcp();
> +    my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
> +    my $bootloader;
> +    $bootloader=setupboot_grub2($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
> +
> +    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);
> +

This hunk is copied from Debian.pm. If debian_setup_boot cannot meet
your requirement, please refactor it.

Wei.

> +    
> +} else {
> +
> +    if ($checkmode) {
> +        extract();
> +    } else {
> +        die if @hos > 1;
> +        $ho= $hos[0];
> +        $w_ho = $ho;
> +        packages();
> +        extract();
> +        forbidden();
> +        adjustconfig();
> +        setupboot();
> +        setupinitd();
> +        nodhcp();
> +    }
>  }
> -- 
> 1.7.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 Dec 11 11:39:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz25O-00070v-Lk; Thu, 11 Dec 2014 11:39:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xz25N-00070q-58
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 11:39:09 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	BA/40-05632-C5289845; Thu, 11 Dec 2014 11:39:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418297947!12622075!1
X-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 32293 invoked from network); 11 Dec 2014 11:39:07 -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; 11 Dec 2014 11:39:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 11:39:07 +0000
Message-Id: <5489906B020000780004EE34@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 11:39:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"Keir Fraser" <keir@xen.org>,"Tim Deegan" <tim@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: [Xen-devel] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Co-REST-maintainers,

there are a couple of patches I'd like to ask for feedback on, and I'm
assuming (based on previous replies by him) Konrad is waiting for such
too before considering giving release-acks:

http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00667.html
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00692.html 
Either
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00260.html
or (my preference)
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01054.html

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 Dec 11 11:39:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz25O-00070v-Lk; Thu, 11 Dec 2014 11:39:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xz25N-00070q-58
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 11:39:09 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	BA/40-05632-C5289845; Thu, 11 Dec 2014 11:39:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418297947!12622075!1
X-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 32293 invoked from network); 11 Dec 2014 11:39:07 -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; 11 Dec 2014 11:39:07 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 11:39:07 +0000
Message-Id: <5489906B020000780004EE34@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 11:39:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"Keir Fraser" <keir@xen.org>,"Tim Deegan" <tim@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: [Xen-devel] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Co-REST-maintainers,

there are a couple of patches I'd like to ask for feedback on, and I'm
assuming (based on previous replies by him) Konrad is waiting for such
too before considering giving release-acks:

http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00667.html
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00692.html 
Either
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00260.html
or (my preference)
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01054.html

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 Dec 11 11:39:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11: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 1Xz25k-00072T-1x; Thu, 11 Dec 2014 11:39:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xz25i-00072K-Vj
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 11:39:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	61/21-15461-27289845; Thu, 11 Dec 2014 11:39:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418297968!14922737!1
X-Originating-IP: [66.165.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 23967 invoked from network); 11 Dec 2014 11:39:29 -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;
	11 Dec 2014 11:39:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203303031"
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.210.2; Thu, 11 Dec 2014 06:39: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 1Xz25f-0006KW-4N;
	Thu, 11 Dec 2014 11:39:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xz25e-0000sz-Ur;
	Thu, 11 Dec 2014 11:39:26 +0000
Date: Thu, 11 Dec 2014 11:39:26 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32214-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] 32214: 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 32214 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32214/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 32110

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)    broken pass in 32163
 test-armhf-armhf-xl           4 xen-install                 fail pass in 32163
 test-amd64-i386-freebsd10-amd64  3 host-install(3)        broken pass in 32163
 test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 32163 pass in 32214
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 32163 pass in 32214
 test-amd64-amd64-xl-sedf      7 debian-install     fail in 32163 pass in 32214
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 guest-localmigrate fail in 32163 pass in 32214
 test-amd64-i386-xl-win7-amd64  3 host-install(3) broken in 32163 pass in 32214
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot   fail in 32163 pass in 32214

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  3 host-install(3)  broken like 31883
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32110
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 31934

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-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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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
 test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail in 32163 never pass
 test-armhf-armhf-xl           5 xen-boot              fail in 32163 never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail in 32163 never pass

version targeted for testing:
 xen                  145c8ced0de02d0ad37743eb42b116e40f13e97e
baseline version:
 xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@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                              broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 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                               broken  
 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-ovmf-amd64 host-install(3)
broken-step test-amd64-i386-freebsd10-amd64 host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)
broken-step test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 host-install(3)

Not pushing.

------------------------------------------------------------
commit 145c8ced0de02d0ad37743eb42b116e40f13e97e
Author: Keir Fraser <keir@xen.org>
Date:   Mon Dec 8 15:30:17 2014 +0100

    switch to write-biased r/w locks
    
    This is to improve fairness: A permanent flow of read acquires can
    otherwise lock out eventual writers indefinitely.
    
    This is CVE-2014-9065 / XSA-114.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
    master date: 2014-12-08 14:45:46 +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 Thu Dec 11 11:39:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11: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 1Xz25k-00072T-1x; Thu, 11 Dec 2014 11:39:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xz25i-00072K-Vj
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 11:39:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	61/21-15461-27289845; Thu, 11 Dec 2014 11:39:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418297968!14922737!1
X-Originating-IP: [66.165.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 23967 invoked from network); 11 Dec 2014 11:39:29 -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;
	11 Dec 2014 11:39:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203303031"
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.210.2; Thu, 11 Dec 2014 06:39: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 1Xz25f-0006KW-4N;
	Thu, 11 Dec 2014 11:39:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xz25e-0000sz-Ur;
	Thu, 11 Dec 2014 11:39:26 +0000
Date: Thu, 11 Dec 2014 11:39:26 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32214-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] 32214: 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 32214 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32214/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 32110

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)    broken pass in 32163
 test-armhf-armhf-xl           4 xen-install                 fail pass in 32163
 test-amd64-i386-freebsd10-amd64  3 host-install(3)        broken pass in 32163
 test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 32163 pass in 32214
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 32163 pass in 32214
 test-amd64-amd64-xl-sedf      7 debian-install     fail in 32163 pass in 32214
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 guest-localmigrate fail in 32163 pass in 32214
 test-amd64-i386-xl-win7-amd64  3 host-install(3) broken in 32163 pass in 32214
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot   fail in 32163 pass in 32214

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  3 host-install(3)  broken like 31883
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32110
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 31934

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-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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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
 test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail in 32163 never pass
 test-armhf-armhf-xl           5 xen-boot              fail in 32163 never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail in 32163 never pass

version targeted for testing:
 xen                  145c8ced0de02d0ad37743eb42b116e40f13e97e
baseline version:
 xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@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                              broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         fail    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 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                               broken  
 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-ovmf-amd64 host-install(3)
broken-step test-amd64-i386-freebsd10-amd64 host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)
broken-step test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 host-install(3)

Not pushing.

------------------------------------------------------------
commit 145c8ced0de02d0ad37743eb42b116e40f13e97e
Author: Keir Fraser <keir@xen.org>
Date:   Mon Dec 8 15:30:17 2014 +0100

    switch to write-biased r/w locks
    
    This is to improve fairness: A permanent flow of read acquires can
    otherwise lock out eventual writers indefinitely.
    
    This is CVE-2014-9065 / XSA-114.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
    master date: 2014-12-08 14:45:46 +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 Thu Dec 11 11:41:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11: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 1Xz281-0007Gz-Pa; Thu, 11 Dec 2014 11:41: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 1Xz280-0007Gp-JS
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 11:41:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F1/20-25276-FF289845; Thu, 11 Dec 2014 11:41:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418298110!14884468!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 27771 invoked from network); 11 Dec 2014 11:41:51 -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;
	11 Dec 2014 11:41:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202899850"
Message-ID: <548982FC.5040107@citrix.com>
Date: Thu, 11 Dec 2014 11:41: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: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <54898449020000780004EDDD@mail.emea.novell.com>
In-Reply-To: <54898449020000780004EDDD@mail.emea.novell.com>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: don't deliver NMI to PVH 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 11/12/14 10:47, Jan Beulich wrote:
> ... for the time being: The mechanism used depends on the domain's use
> of the IRET hypercall.
>
> Also drop two bogus code lines spotted while going through the involved
> code paths: Addresses of per-CPU variables can't possibly be NULL, and
> the setting of st->vcpu in send_guest_trap()'s MCE case is redundant
> with an earlier cmpxchgptr().
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

>
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -3168,7 +3168,6 @@ static void nmi_mce_softirq(void)
>      int cpu = smp_processor_id();
>      struct softirq_trap *st = &per_cpu(softirq_trap, cpu);
>  
> -    BUG_ON(st == NULL);
>      BUG_ON(st->vcpu == NULL);
>  
>      /* Set the tmp value unconditionally, so that
> @@ -3233,7 +3232,7 @@ static void nmi_hwdom_report(unsigned in
>  {
>      struct domain *d = hardware_domain;
>  
> -    if ( (d == NULL) || (d->vcpu == NULL) || (d->vcpu[0] == NULL) )
> +    if ( !d || !d->vcpu || !d->vcpu[0] || !is_pv_domain(d) /* PVH fixme */ )
>          return;
>  
>      set_bit(reason_idx, nmi_reason(d));
> @@ -3674,7 +3673,6 @@ int send_guest_trap(struct domain *d, ui
>  
>          if ( !test_and_set_bool(v->mce_pending) ) {
>                  st->domain = d;
> -                st->vcpu = v;
>                  st->processor = v->processor;
>  
>                  /* not safe to wake up a vcpu here */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 11:41:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11: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 1Xz281-0007Gz-Pa; Thu, 11 Dec 2014 11:41: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 1Xz280-0007Gp-JS
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 11:41:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F1/20-25276-FF289845; Thu, 11 Dec 2014 11:41:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418298110!14884468!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 27771 invoked from network); 11 Dec 2014 11:41:51 -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;
	11 Dec 2014 11:41:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202899850"
Message-ID: <548982FC.5040107@citrix.com>
Date: Thu, 11 Dec 2014 11:41: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: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <54898449020000780004EDDD@mail.emea.novell.com>
In-Reply-To: <54898449020000780004EDDD@mail.emea.novell.com>
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: don't deliver NMI to PVH 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 11/12/14 10:47, Jan Beulich wrote:
> ... for the time being: The mechanism used depends on the domain's use
> of the IRET hypercall.
>
> Also drop two bogus code lines spotted while going through the involved
> code paths: Addresses of per-CPU variables can't possibly be NULL, and
> the setting of st->vcpu in send_guest_trap()'s MCE case is redundant
> with an earlier cmpxchgptr().
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

>
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -3168,7 +3168,6 @@ static void nmi_mce_softirq(void)
>      int cpu = smp_processor_id();
>      struct softirq_trap *st = &per_cpu(softirq_trap, cpu);
>  
> -    BUG_ON(st == NULL);
>      BUG_ON(st->vcpu == NULL);
>  
>      /* Set the tmp value unconditionally, so that
> @@ -3233,7 +3232,7 @@ static void nmi_hwdom_report(unsigned in
>  {
>      struct domain *d = hardware_domain;
>  
> -    if ( (d == NULL) || (d->vcpu == NULL) || (d->vcpu[0] == NULL) )
> +    if ( !d || !d->vcpu || !d->vcpu[0] || !is_pv_domain(d) /* PVH fixme */ )
>          return;
>  
>      set_bit(reason_idx, nmi_reason(d));
> @@ -3674,7 +3673,6 @@ int send_guest_trap(struct domain *d, ui
>  
>          if ( !test_and_set_bool(v->mce_pending) ) {
>                  st->domain = d;
> -                st->vcpu = v;
>                  st->processor = v->processor;
>  
>                  /* not safe to wake up a vcpu here */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 11:44:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2AU-0007h7-Ay; Thu, 11 Dec 2014 11:44:26 +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 1Xz2AS-0007gz-T4
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 11:44:25 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	5D/B3-08051-89389845; Thu, 11 Dec 2014 11:44:24 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418298262!14435898!1
X-Originating-IP: [66.165.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 3659 invoked from network); 11 Dec 2014 11:44:23 -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;
	11 Dec 2014 11:44:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202900332"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 06:43: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 1Xz2A1-0000qD-0F;
	Thu, 11 Dec 2014 11:43:57 +0000
Date: Thu, 11 Dec 2014 11:43:56 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: longtao.pang <longtaox.pang@intel.com>
Message-ID: <20141211114356.GE21659@zion.uk.xensource.com>
References: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
	<1418198860-29802-4-git-send-email-longtaox.pang@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418198860-29802-4-git-send-email-longtaox.pang@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, robert.hu@intel.com, di.zheng@intel.com
Subject: Re: [Xen-devel] [OSSTEST PATCH 3/4] Add nested testcase 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 04:07:39PM +0800, longtao.pang wrote:
> 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 e513bd1..85f7b22 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-debian-hvm-install + host + nested + nested_L1
>      run-ts . = ts-xen-install + host + nested + nested_build
> +    run-ts . = ts-debian-install + host + nested + amd64 + nested_L2
> +    run-ts . = ts-guest-destroy + host nested

It would also be possible to run ts-debian-hvm-install as L2. That would
suite this test case better -- it's testing nested HVM.

There's no need to remove the PV test case though.

>  }
>  
>  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;
> -

Stray blank line.

>  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";
> +        } 
> +    } 

To be honest, this looks convoluted. Special casing needs better
explanation.

>      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

As far as I can tell, the only difference is a few variables.

You can set up variables in

  if ($nested_L2) {
    var = foo;
  } else {
    var = bar;
  }
  target_cmd_root($ho,  var ... );

Just like you did in previous hunk. Please add in some comments where
necessary.

>  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");
> +}

I think we already have a guest start script?

This hunk is going to break easily if we're more flexible about the
toolstack (we already have a partially working libvirt test case).

> +
> +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");
> +    }
> +}
> +

target_ping_check_{up,down} may be suitable?


Wei.


> +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 Thu Dec 11 11:44:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2Ag-0007iM-Nh; Thu, 11 Dec 2014 11:44: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 1Xz2Ag-0007iD-62
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 11:44:38 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	B7/65-29352-5A389845; Thu, 11 Dec 2014 11:44:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418298276!12769391!1
X-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 12065 invoked from network); 11 Dec 2014 11:44:36 -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; 11 Dec 2014 11:44:36 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 11:44:35 +0000
Message-Id: <548991B2020000780004EE44@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 11:44:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
 <dgdegra@tycho.nsa.gov>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
	<1418205196.19809.34.camel@eu.citrix.com>
In-Reply-To: <1418205196.19809.34.camel@eu.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>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 10:53, <Ian.Campbell@eu.citrix.com> wrote:
> On Wed, 2014-12-10 at 08:07 +0000, Jan Beulich wrote:
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>>  
>>      case XEN_DOMCTL_irq_permission:
>>      {
>> -        unsigned int pirq = op->u.irq_permission.pirq;
>> +        unsigned int pirq = op->u.irq_permission.pirq, irq;
>>          int allow = op->u.irq_permission.allow_access;
>>  
>>          if ( pirq >= d->nr_pirqs )
>>              ret = -EINVAL;
>> -        else if ( !pirq_access_permitted(current->domain, pirq) ||
>> +        else if ( !(irq = pirq_access_permitted(current->domain, pirq)) ||
> 
> I find hiding an assignment inside the second condition in a chain of
> if's to be rather obfuscated. Doing an assignment in a standalone if
> statement is one thing, this is going to far IMHO.

Changed. My main intention was to avoid having to add another
"break;".

> Also, you range check pirq against d->nr_pirqs but then translate it
> against current->domain, is that correct?

No, it's not. As much as xsm_irq_permission(XSM_HOOK, d, pirq, allow)
is bogus, yet it's not clear to me whether switching that to use the Xen
IRQ number is okay without any other changes. Daniel?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 11:44:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2AU-0007h7-Ay; Thu, 11 Dec 2014 11:44:26 +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 1Xz2AS-0007gz-T4
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 11:44:25 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	5D/B3-08051-89389845; Thu, 11 Dec 2014 11:44:24 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418298262!14435898!1
X-Originating-IP: [66.165.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 3659 invoked from network); 11 Dec 2014 11:44:23 -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;
	11 Dec 2014 11:44:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202900332"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 06:43: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 1Xz2A1-0000qD-0F;
	Thu, 11 Dec 2014 11:43:57 +0000
Date: Thu, 11 Dec 2014 11:43:56 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: longtao.pang <longtaox.pang@intel.com>
Message-ID: <20141211114356.GE21659@zion.uk.xensource.com>
References: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
	<1418198860-29802-4-git-send-email-longtaox.pang@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418198860-29802-4-git-send-email-longtaox.pang@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, robert.hu@intel.com, di.zheng@intel.com
Subject: Re: [Xen-devel] [OSSTEST PATCH 3/4] Add nested testcase 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 04:07:39PM +0800, longtao.pang wrote:
> 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 e513bd1..85f7b22 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-debian-hvm-install + host + nested + nested_L1
>      run-ts . = ts-xen-install + host + nested + nested_build
> +    run-ts . = ts-debian-install + host + nested + amd64 + nested_L2
> +    run-ts . = ts-guest-destroy + host nested

It would also be possible to run ts-debian-hvm-install as L2. That would
suite this test case better -- it's testing nested HVM.

There's no need to remove the PV test case though.

>  }
>  
>  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;
> -

Stray blank line.

>  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";
> +        } 
> +    } 

To be honest, this looks convoluted. Special casing needs better
explanation.

>      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

As far as I can tell, the only difference is a few variables.

You can set up variables in

  if ($nested_L2) {
    var = foo;
  } else {
    var = bar;
  }
  target_cmd_root($ho,  var ... );

Just like you did in previous hunk. Please add in some comments where
necessary.

>  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");
> +}

I think we already have a guest start script?

This hunk is going to break easily if we're more flexible about the
toolstack (we already have a partially working libvirt test case).

> +
> +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");
> +    }
> +}
> +

target_ping_check_{up,down} may be suitable?


Wei.


> +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 Thu Dec 11 11:44:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2Ag-0007iM-Nh; Thu, 11 Dec 2014 11:44: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 1Xz2Ag-0007iD-62
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 11:44:38 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	B7/65-29352-5A389845; Thu, 11 Dec 2014 11:44:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418298276!12769391!1
X-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 12065 invoked from network); 11 Dec 2014 11:44:36 -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; 11 Dec 2014 11:44:36 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 11:44:35 +0000
Message-Id: <548991B2020000780004EE44@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 11:44:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
 <dgdegra@tycho.nsa.gov>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
	<1418205196.19809.34.camel@eu.citrix.com>
In-Reply-To: <1418205196.19809.34.camel@eu.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>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 10:53, <Ian.Campbell@eu.citrix.com> wrote:
> On Wed, 2014-12-10 at 08:07 +0000, Jan Beulich wrote:
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>>  
>>      case XEN_DOMCTL_irq_permission:
>>      {
>> -        unsigned int pirq = op->u.irq_permission.pirq;
>> +        unsigned int pirq = op->u.irq_permission.pirq, irq;
>>          int allow = op->u.irq_permission.allow_access;
>>  
>>          if ( pirq >= d->nr_pirqs )
>>              ret = -EINVAL;
>> -        else if ( !pirq_access_permitted(current->domain, pirq) ||
>> +        else if ( !(irq = pirq_access_permitted(current->domain, pirq)) ||
> 
> I find hiding an assignment inside the second condition in a chain of
> if's to be rather obfuscated. Doing an assignment in a standalone if
> statement is one thing, this is going to far IMHO.

Changed. My main intention was to avoid having to add another
"break;".

> Also, you range check pirq against d->nr_pirqs but then translate it
> against current->domain, is that correct?

No, it's not. As much as xsm_irq_permission(XSM_HOOK, d, pirq, allow)
is bogus, yet it's not clear to me whether switching that to use the Xen
IRQ number is okay without any other changes. Daniel?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 11:46:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11:46:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2CU-0007to-7Z; Thu, 11 Dec 2014 11:46: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 1Xz2CT-0007te-14
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 11:46:29 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	68/67-22819-41489845; Thu, 11 Dec 2014 11:46:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418298382!9437188!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 27315 invoked from network); 11 Dec 2014 11:46:27 -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;
	11 Dec 2014 11:46:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203304976"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 06:46:26 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xz2CP-0000t6-Os;
	Thu, 11 Dec 2014 11:46:25 +0000
Date: Thu, 11 Dec 2014 11:46:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: longtao.pang <longtaox.pang@intel.com>
Message-ID: <20141211114625.GF21659@zion.uk.xensource.com>
References: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
	<1418198860-29802-5-git-send-email-longtaox.pang@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418198860-29802-5-git-send-email-longtaox.pang@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, robert.hu@intel.com, di.zheng@intel.com
Subject: Re: [Xen-devel] [OSSTEST PATCH 4/4] Insert nested test job name and
	runvars into
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 04:07:40PM +0800, longtao.pang wrote:
> 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..b65f0b5 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=v3.16                                         \
> +                tree_linux=git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git                                                             \

Please don't hard code tree and revision.

You can specify tree and revision in you test configuration.

Wei.

> +                ${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 Thu Dec 11 11:46:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 11:46:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2CU-0007to-7Z; Thu, 11 Dec 2014 11:46: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 1Xz2CT-0007te-14
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 11:46:29 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	68/67-22819-41489845; Thu, 11 Dec 2014 11:46:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418298382!9437188!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 27315 invoked from network); 11 Dec 2014 11:46:27 -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;
	11 Dec 2014 11:46:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203304976"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 06:46:26 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Xz2CP-0000t6-Os;
	Thu, 11 Dec 2014 11:46:25 +0000
Date: Thu, 11 Dec 2014 11:46:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: longtao.pang <longtaox.pang@intel.com>
Message-ID: <20141211114625.GF21659@zion.uk.xensource.com>
References: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
	<1418198860-29802-5-git-send-email-longtaox.pang@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418198860-29802-5-git-send-email-longtaox.pang@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, robert.hu@intel.com, di.zheng@intel.com
Subject: Re: [Xen-devel] [OSSTEST PATCH 4/4] Insert nested test job name and
	runvars into
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 04:07:40PM +0800, longtao.pang wrote:
> 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..b65f0b5 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=v3.16                                         \
> +                tree_linux=git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git                                                             \

Please don't hard code tree and revision.

You can specify tree and revision in you test configuration.

Wei.

> +                ${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 Thu Dec 11 11:57:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 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 1Xz2N8-0008P8-DC; Thu, 11 Dec 2014 11:57: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 1Xz2N6-0008P1-HE
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 11:57:28 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	BF/EF-02712-7A689845; Thu, 11 Dec 2014 11:57:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418299043!9774184!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 29512 invoked from network); 11 Dec 2014 11:57:24 -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;
	11 Dec 2014 11:57:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203307908"
Message-ID: <1418299040.10394.21.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 11 Dec 2014 11:57:20 +0000
In-Reply-To: <5481A589020000780004D1E3@mail.emea.novell.com>
References: <5481A589020000780004D1E3@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-05 at 11:31 +0000, Jan Beulich wrote:
> Andrew validly points out that even if these masks aren't a formal part
> of the hypercall interface, we aren't free to change them: A guest
> suspended for migration in the middle of a continuation would fail to
> work if resumed on a hypervisor using a different value. Hence add
> respective comments to their definitions.
> 
> Additionally, to help future extensibility as well as in the spirit of
> reducing undefined behavior as much as possible, refuse hypercalls made
> with the respective bits non-zero when the respective sub-ops don't
> make use of those bits.
> 
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 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 Thu Dec 11 11:57:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 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 1Xz2N8-0008P8-DC; Thu, 11 Dec 2014 11:57: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 1Xz2N6-0008P1-HE
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 11:57:28 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	BF/EF-02712-7A689845; Thu, 11 Dec 2014 11:57:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418299043!9774184!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 29512 invoked from network); 11 Dec 2014 11:57:24 -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;
	11 Dec 2014 11:57:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203307908"
Message-ID: <1418299040.10394.21.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 11 Dec 2014 11:57:20 +0000
In-Reply-To: <5481A589020000780004D1E3@mail.emea.novell.com>
References: <5481A589020000780004D1E3@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-05 at 11:31 +0000, Jan Beulich wrote:
> Andrew validly points out that even if these masks aren't a formal part
> of the hypercall interface, we aren't free to change them: A guest
> suspended for migration in the middle of a continuation would fail to
> work if resumed on a hypervisor using a different value. Hence add
> respective comments to their definitions.
> 
> Additionally, to help future extensibility as well as in the spirit of
> reducing undefined behavior as much as possible, refuse hypercalls made
> with the respective bits non-zero when the respective sub-ops don't
> make use of those bits.
> 
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 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 Thu Dec 11 12:00:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2Q4-00008i-LP; Thu, 11 Dec 2014 12:00:32 +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 1Xz2Q3-000085-5U
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:00:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	31/E8-15461-E5789845; Thu, 11 Dec 2014 12:00:30 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418299229!14864259!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 26982 invoked from network); 11 Dec 2014 12:00:30 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 12:00:30 -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 sBBC09fQ011253;
	Thu, 11 Dec 2014 12:00:13 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 sBBC04Jr019824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Dec 2014 12:00:04 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 sBBC04xh027957;
	Thu, 11 Dec 2014 12:00:04 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sBBC03XP027952; Thu, 11 Dec 2014 12:00:03 GMT
Date: Thu, 11 Dec 2014 12:00:03 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141211084302.GA16507@aepfle.de>
Message-ID: <alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sBBC09fQ011253
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 11 Dec 2014, Olaf Hering wrote:

> On Wed, Dec 10, Konrad Rzeszutek Wilk wrote:
>
>> On Mon, Dec 08, 2014 at 11:18:05AM +0100, Olaf Hering wrote:
>>> This is a resend of this series, with just the low hanging fruits:
>>> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
>> This looks like it would fix some of the issues I saw. I will test it
>> over today.
>> Please also CC Michael (Fedora Xen maintainer) on these changes (I've CC-ed
>> him here).
>
> It would be nice to know if the entire chain of dependencies fails, or
> just that unit. Furthermore it would be nice to know if there needs to
> be anyhing related to SELinux in the xen sources. In other words, would
> xenstored behave correctly if that tmpfs mount would be done without any
> options?

Yes, you do need to set explicit selinux permissions when mounting 
/var/lib/xenstored as otherwise it gets a tmpfs selinux context which 
xenstored can't use in enforcing mode.

The other selinux issue is that it seems you can't run xenstored through a 
shell script wrapper, because it still has startup shell script selinux 
permissions when it is trying to connect to the sockets, so it doesn't 
work. It does work if you run xenstored directly from the systemd file.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:00:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2Q4-00008i-LP; Thu, 11 Dec 2014 12:00:32 +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 1Xz2Q3-000085-5U
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:00:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	31/E8-15461-E5789845; Thu, 11 Dec 2014 12:00:30 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418299229!14864259!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 26982 invoked from network); 11 Dec 2014 12:00:30 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 12:00:30 -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 sBBC09fQ011253;
	Thu, 11 Dec 2014 12:00:13 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 sBBC04Jr019824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Dec 2014 12:00:04 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 sBBC04xh027957;
	Thu, 11 Dec 2014 12:00:04 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sBBC03XP027952; Thu, 11 Dec 2014 12:00:03 GMT
Date: Thu, 11 Dec 2014 12:00:03 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141211084302.GA16507@aepfle.de>
Message-ID: <alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sBBC09fQ011253
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 11 Dec 2014, Olaf Hering wrote:

> On Wed, Dec 10, Konrad Rzeszutek Wilk wrote:
>
>> On Mon, Dec 08, 2014 at 11:18:05AM +0100, Olaf Hering wrote:
>>> This is a resend of this series, with just the low hanging fruits:
>>> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
>> This looks like it would fix some of the issues I saw. I will test it
>> over today.
>> Please also CC Michael (Fedora Xen maintainer) on these changes (I've CC-ed
>> him here).
>
> It would be nice to know if the entire chain of dependencies fails, or
> just that unit. Furthermore it would be nice to know if there needs to
> be anyhing related to SELinux in the xen sources. In other words, would
> xenstored behave correctly if that tmpfs mount would be done without any
> options?

Yes, you do need to set explicit selinux permissions when mounting 
/var/lib/xenstored as otherwise it gets a tmpfs selinux context which 
xenstored can't use in enforcing mode.

The other selinux issue is that it seems you can't run xenstored through a 
shell script wrapper, because it still has startup shell script selinux 
permissions when it is trying to connect to the sockets, so it doesn't 
work. It does work if you run xenstored directly from the systemd file.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:04:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2Tv-0000ep-N6; Thu, 11 Dec 2014 12:04:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xz2Tu-0000ed-Ck
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:04:30 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	2B/96-26652-D4889845; Thu, 11 Dec 2014 12:04:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418299468!12793415!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6586 invoked from network); 11 Dec 2014 12:04:29 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 12:04:29 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418299468; l=820;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=kJfoHlzMV1WNJc7RFPKY5h4lJNA=;
	b=gyaLtI4eqEoJK7deorFqbgpLn1unz9IYpSS+P2fZEKHasI+H/j0zFd9XUryprrP9nZA
	2RuQLPkNDdaeCFqiaQaKRLQxQgDb3wHREYJBs08fljVbgbDCBbE9/8NRcRiUkBGTXZn3D
	rdzN3ny4wfB3NNmvRKhGMF7GVvpwsYsOD9A=
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.3 AUTH) with ESMTPSA id z03d29qBBC4O1xX
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 11 Dec 2014 13:04:24 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 42A885015F; Thu, 11 Dec 2014 13:04:24 +0100 (CET)
Date: Thu, 11 Dec 2014 13:04:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141211120424.GA25950@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
	<alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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 Thu, Dec 11, M A Young wrote:

> Yes, you do need to set explicit selinux permissions when mounting
> /var/lib/xenstored as otherwise it gets a tmpfs selinux context which
> xenstored can't use in enforcing mode.

Is that "enforcing mode" the default? And would it be too cumbersome to
have these context settings in fstab?

> The other selinux issue is that it seems you can't run xenstored through a
> shell script wrapper, because it still has startup shell script selinux
> permissions when it is trying to connect to the sockets, so it doesn't work.
> It does work if you run xenstored directly from the systemd file.

This sounds like xenstored has to parse the possible environment
variables found in sysconfig.xencommons all by itself? Is there perhaps
a way out of the SELinux jail?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:04:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2Tt-0000eV-Aq; Thu, 11 Dec 2014 12:04:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1Xz2Tr-0000eO-SV
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 12:04:28 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B8/F9-27584-B4889845; Thu, 11 Dec 2014 12:04:27 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418299466!12839750!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7408 invoked from network); 11 Dec 2014 12:04:26 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 12:04:26 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so6250004wgh.16
	for <xen-devel@lists.xenproject.org>;
	Thu, 11 Dec 2014 04:04:26 -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:to:cc:subject
	:content-type:content-transfer-encoding;
	bh=xcjjMA/zW7lFYaNxHHUNE2SnIAp8haGDA8y/ho+FO3I=;
	b=B+Jr4IEqREm0RS6NR/RkqyUsDbDvR/CfFWdCd3lfsSoSAa9TtF/wFwYKPvy1sQcCVo
	I+1mQPC9nk9nUVrRDdQclstznAd3lq2XnWOkS7iqfh6LIYsf5duuDsy3YD6+/xF2KnBI
	9kFBwaWXgt64oJIxv1LDWpvRc0OY4M9HFtKA3Cn5QgsSLeguj4NH4LLSgXv+kyiBgL49
	2KUmEp0AwJllq1EXtYmPgDbcAqWLCrdVM8dSHfFU7HvjayDApNbNLA1mF/U8EmV1QQLO
	s5sRfvdbQiUGgnI61Mg1mOs0xvKQaY/zIDodSQOTsf6F1z5K/NSMt9MMW9xvHeXZ9t6u
	SYwA==
X-Received: by 10.180.74.108 with SMTP id s12mr22713318wiv.28.1418299466097;
	Thu, 11 Dec 2014 04:04:26 -0800 (PST)
Received: from [10.80.2.76] ([185.25.64.249])
	by mx.google.com with ESMTPSA id e7sm1410961wjx.31.2014.12.11.04.04.22
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 04:04:25 -0800 (PST)
Message-ID: <54898841.3060108@cantab.net>
Date: Thu, 11 Dec 2014 12:04:17 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <Boris.Ostrovsky@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [GIT PULL] xen: features and fixes for 3.19-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git stable/for-linus-3.19-rc0-tag

xen: features and fixes for 3.19-rc0

- - Fully support non-coherent devices on ARM by introducing the
  mechanisms to request the hypervisor to perform the required cache
  maintainance operations.

- - A number of pciback bug fixes and cleanups.  Notably a deadlock fix
  if a PCI device was manually uunbound and a fix for incorrectly
  restoring state after a function reset.

- - In x86 PVHVM guests, use the APIC for interrupts if this has been
  virtualized by the hardware.  This reduces the number of interrupt-
  related VM exits on such hardware.

Thanks.

David

 arch/arm/include/asm/device.h              |    1 +
 arch/arm/include/asm/dma-mapping.h         |    7 +
 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       |    7 +
 arch/arm64/include/asm/xen/page-coherent.h |   44 +-----
 arch/x86/include/asm/xen/cpuid.h           |   91 +++++++++++++
 arch/x86/include/asm/xen/page-coherent.h   |    4 +-
 arch/x86/include/asm/xen/page.h            |    7 +
 arch/x86/pci/xen.c                         |   31 ++++-
 drivers/pci/pci.c                          |    5 +-
 drivers/xen/swiotlb-xen.c                  |   19 +--
 drivers/xen/xen-pciback/passthrough.c      |   14 +-
 drivers/xen/xen-pciback/pci_stub.c         |  112 ++++++++++++---
 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 +
 include/xen/interface/features.h           |    3 -
 include/xen/interface/grant_table.h        |   19 +++
 26 files changed, 488 insertions(+), 309 deletions(-)

Boris Ostrovsky (2):
      xen/pci: Defer initialization of MSI ops on HVM guests
      xen/pci: Use APIC directly when APIC virtualization hardware is available

David Vrabel (1):
      Revert "swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single"

Jan Beulich (1):
      xen-pciback: drop SR-IOV VFs when PF driver unloads

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.

Stefano Stabellini (15):
      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
      swiotlb-xen: call xen_dma_sync_single_for_device when appropriate
      swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUiYhAAAoJEFxbo/MsZsTRJTkIAIi9zrj7029PkxggyEAZHvVO
0XGwMGwXei6n8ofQFkFYEc5/3Df9JW7v05uqy2Y4bu+ifMvDa1C6R4tk5ol4bM4E
sgs96yMiOSRwrVD9SgE73bW84i/Xa87LCpBoCi7417j1h+6e9oQ2l4+XiWTySSne
N8/m/1QuD+6argsf2LN/a1XG1V9OInm8k9oGMM1prDwWN7JsZeaLyY3LSFXb6s2S
o6KQmUiAa66WALCFkeatocq5+PZ5PXMndweo064Zyjfuj2pYdxeGkqmWQrA1IeY4
wp2YP+XFrU36MPXD88VR9do9ovlxFCJG6tO0IWYcW8tiY+y4Rw2b+4C/oe4lm9U=
=zcCQ
-----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 Dec 11 12:04:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2Tv-0000ep-N6; Thu, 11 Dec 2014 12:04:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xz2Tu-0000ed-Ck
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:04:30 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	2B/96-26652-D4889845; Thu, 11 Dec 2014 12:04:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418299468!12793415!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6586 invoked from network); 11 Dec 2014 12:04:29 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 12:04:29 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418299468; l=820;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=kJfoHlzMV1WNJc7RFPKY5h4lJNA=;
	b=gyaLtI4eqEoJK7deorFqbgpLn1unz9IYpSS+P2fZEKHasI+H/j0zFd9XUryprrP9nZA
	2RuQLPkNDdaeCFqiaQaKRLQxQgDb3wHREYJBs08fljVbgbDCBbE9/8NRcRiUkBGTXZn3D
	rdzN3ny4wfB3NNmvRKhGMF7GVvpwsYsOD9A=
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.3 AUTH) with ESMTPSA id z03d29qBBC4O1xX
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 11 Dec 2014 13:04:24 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 42A885015F; Thu, 11 Dec 2014 13:04:24 +0100 (CET)
Date: Thu, 11 Dec 2014 13:04:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141211120424.GA25950@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
	<alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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 Thu, Dec 11, M A Young wrote:

> Yes, you do need to set explicit selinux permissions when mounting
> /var/lib/xenstored as otherwise it gets a tmpfs selinux context which
> xenstored can't use in enforcing mode.

Is that "enforcing mode" the default? And would it be too cumbersome to
have these context settings in fstab?

> The other selinux issue is that it seems you can't run xenstored through a
> shell script wrapper, because it still has startup shell script selinux
> permissions when it is trying to connect to the sockets, so it doesn't work.
> It does work if you run xenstored directly from the systemd file.

This sounds like xenstored has to parse the possible environment
variables found in sysconfig.xencommons all by itself? Is there perhaps
a way out of the SELinux jail?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:04:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2Tt-0000eV-Aq; Thu, 11 Dec 2014 12:04:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1Xz2Tr-0000eO-SV
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 12:04:28 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B8/F9-27584-B4889845; Thu, 11 Dec 2014 12:04:27 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418299466!12839750!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7408 invoked from network); 11 Dec 2014 12:04:26 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 12:04:26 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so6250004wgh.16
	for <xen-devel@lists.xenproject.org>;
	Thu, 11 Dec 2014 04:04:26 -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:to:cc:subject
	:content-type:content-transfer-encoding;
	bh=xcjjMA/zW7lFYaNxHHUNE2SnIAp8haGDA8y/ho+FO3I=;
	b=B+Jr4IEqREm0RS6NR/RkqyUsDbDvR/CfFWdCd3lfsSoSAa9TtF/wFwYKPvy1sQcCVo
	I+1mQPC9nk9nUVrRDdQclstznAd3lq2XnWOkS7iqfh6LIYsf5duuDsy3YD6+/xF2KnBI
	9kFBwaWXgt64oJIxv1LDWpvRc0OY4M9HFtKA3Cn5QgsSLeguj4NH4LLSgXv+kyiBgL49
	2KUmEp0AwJllq1EXtYmPgDbcAqWLCrdVM8dSHfFU7HvjayDApNbNLA1mF/U8EmV1QQLO
	s5sRfvdbQiUGgnI61Mg1mOs0xvKQaY/zIDodSQOTsf6F1z5K/NSMt9MMW9xvHeXZ9t6u
	SYwA==
X-Received: by 10.180.74.108 with SMTP id s12mr22713318wiv.28.1418299466097;
	Thu, 11 Dec 2014 04:04:26 -0800 (PST)
Received: from [10.80.2.76] ([185.25.64.249])
	by mx.google.com with ESMTPSA id e7sm1410961wjx.31.2014.12.11.04.04.22
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 04:04:25 -0800 (PST)
Message-ID: <54898841.3060108@cantab.net>
Date: Thu, 11 Dec 2014 12:04:17 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <Boris.Ostrovsky@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [GIT PULL] xen: features and fixes for 3.19-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git stable/for-linus-3.19-rc0-tag

xen: features and fixes for 3.19-rc0

- - Fully support non-coherent devices on ARM by introducing the
  mechanisms to request the hypervisor to perform the required cache
  maintainance operations.

- - A number of pciback bug fixes and cleanups.  Notably a deadlock fix
  if a PCI device was manually uunbound and a fix for incorrectly
  restoring state after a function reset.

- - In x86 PVHVM guests, use the APIC for interrupts if this has been
  virtualized by the hardware.  This reduces the number of interrupt-
  related VM exits on such hardware.

Thanks.

David

 arch/arm/include/asm/device.h              |    1 +
 arch/arm/include/asm/dma-mapping.h         |    7 +
 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       |    7 +
 arch/arm64/include/asm/xen/page-coherent.h |   44 +-----
 arch/x86/include/asm/xen/cpuid.h           |   91 +++++++++++++
 arch/x86/include/asm/xen/page-coherent.h   |    4 +-
 arch/x86/include/asm/xen/page.h            |    7 +
 arch/x86/pci/xen.c                         |   31 ++++-
 drivers/pci/pci.c                          |    5 +-
 drivers/xen/swiotlb-xen.c                  |   19 +--
 drivers/xen/xen-pciback/passthrough.c      |   14 +-
 drivers/xen/xen-pciback/pci_stub.c         |  112 ++++++++++++---
 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 +
 include/xen/interface/features.h           |    3 -
 include/xen/interface/grant_table.h        |   19 +++
 26 files changed, 488 insertions(+), 309 deletions(-)

Boris Ostrovsky (2):
      xen/pci: Defer initialization of MSI ops on HVM guests
      xen/pci: Use APIC directly when APIC virtualization hardware is available

David Vrabel (1):
      Revert "swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single"

Jan Beulich (1):
      xen-pciback: drop SR-IOV VFs when PF driver unloads

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.

Stefano Stabellini (15):
      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
      swiotlb-xen: call xen_dma_sync_single_for_device when appropriate
      swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUiYhAAAoJEFxbo/MsZsTRJTkIAIi9zrj7029PkxggyEAZHvVO
0XGwMGwXei6n8ofQFkFYEc5/3Df9JW7v05uqy2Y4bu+ifMvDa1C6R4tk5ol4bM4E
sgs96yMiOSRwrVD9SgE73bW84i/Xa87LCpBoCi7417j1h+6e9oQ2l4+XiWTySSne
N8/m/1QuD+6argsf2LN/a1XG1V9OInm8k9oGMM1prDwWN7JsZeaLyY3LSFXb6s2S
o6KQmUiAa66WALCFkeatocq5+PZ5PXMndweo064Zyjfuj2pYdxeGkqmWQrA1IeY4
wp2YP+XFrU36MPXD88VR9do9ovlxFCJG6tO0IWYcW8tiY+y4Rw2b+4C/oe4lm9U=
=zcCQ
-----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 Dec 11 12:05:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:05:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2UY-0000kW-51; Thu, 11 Dec 2014 12:05: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 1Xz2UW-0000kB-Ej
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:05:08 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	6B/B0-11581-37889845; Thu, 11 Dec 2014 12:05:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418299506!12785771!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 31016 invoked from network); 11 Dec 2014 12:05:07 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 12:05:07 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz2UE-000GRT-LB; Thu, 11 Dec 2014 12:04:50 +0000
Date: Thu, 11 Dec 2014 13:04:50 +0100
From: Tim Deegan <tim@xen.org>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Message-ID: <20141211120450.GA53811@deinos.phlegethon.org>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417838137-12473-3-git-send-email-yu.c.zhang@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417838137-12473-3-git-send-email-yu.c.zhang@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, JBeulich@suse.com,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v6 2/2] add a new p2m type -
	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

At 11:55 +0800 on 06 Dec (1417863337), Yu Zhang wrote:
> From: Yu Zhang <yu.c.zhang@intel.com>
> 
> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
> the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
> model, and will be discarded later in __hvm_copy(); while for the
> p2m_mmio_write_dm type pages, writes will go to the device model
> via ioreq-server.
> 
> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
> Signed-off-by: Wei Ye <wei.ye@intel.com>

Sorry not to have seen this before, but it looks like the new type isn't
handled in the shadow-pagetable code.  I think you need this as well:

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 225290e..58c0cca 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3181,7 +3181,8 @@ static int sh_page_fault(struct vcpu *v,
     }
 
     /* Need to hand off device-model MMIO to the device model */
-    if ( p2mt == p2m_mmio_dm ) 
+    if ( p2mt == p2m_mmio_dm
+         || p2mt == p2m_mmio_readonly && ft == ft_demand_write )
     {
         gpa = guest_walk_to_gpa(&gw);
         goto mmio;

With that hunk added, you can add

Reviewed-by: Tim Deegan <tim@xen.org>

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:05:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:05:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2UY-0000kW-51; Thu, 11 Dec 2014 12:05: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 1Xz2UW-0000kB-Ej
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:05:08 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	6B/B0-11581-37889845; Thu, 11 Dec 2014 12:05:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418299506!12785771!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 31016 invoked from network); 11 Dec 2014 12:05:07 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 12:05:07 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz2UE-000GRT-LB; Thu, 11 Dec 2014 12:04:50 +0000
Date: Thu, 11 Dec 2014 13:04:50 +0100
From: Tim Deegan <tim@xen.org>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Message-ID: <20141211120450.GA53811@deinos.phlegethon.org>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417838137-12473-3-git-send-email-yu.c.zhang@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417838137-12473-3-git-send-email-yu.c.zhang@linux.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: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	donald.d.dugger@intel.com, Xen-devel@lists.xen.org,
	Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, JBeulich@suse.com,
	yang.z.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v6 2/2] add a new p2m type -
	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

At 11:55 +0800 on 06 Dec (1417863337), Yu Zhang wrote:
> From: Yu Zhang <yu.c.zhang@intel.com>
> 
> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
> the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
> model, and will be discarded later in __hvm_copy(); while for the
> p2m_mmio_write_dm type pages, writes will go to the device model
> via ioreq-server.
> 
> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
> Signed-off-by: Wei Ye <wei.ye@intel.com>

Sorry not to have seen this before, but it looks like the new type isn't
handled in the shadow-pagetable code.  I think you need this as well:

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 225290e..58c0cca 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3181,7 +3181,8 @@ static int sh_page_fault(struct vcpu *v,
     }
 
     /* Need to hand off device-model MMIO to the device model */
-    if ( p2mt == p2m_mmio_dm ) 
+    if ( p2mt == p2m_mmio_dm
+         || p2mt == p2m_mmio_readonly && ft == ft_demand_write )
     {
         gpa = guest_walk_to_gpa(&gw);
         goto mmio;

With that hunk added, you can add

Reviewed-by: Tim Deegan <tim@xen.org>

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:05:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2VC-0000rh-Il; Thu, 11 Dec 2014 12:05:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xz2VB-0000rX-D3
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:05:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EB/29-09842-C9889845; Thu, 11 Dec 2014 12:05:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418299548!14950392!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3785 invoked from network); 11 Dec 2014 12:05:48 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 12:05:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418299548; l=277;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=M0S6iaHhA1B3PNtvhfc9kMf2OEM=;
	b=n2p7k/o+s0xJhxeFMF+s2fLqw8ohnRQkmamlUDlVDpaGpUammPoEe7mBhOIrrtDA5Tv
	B48R4ZoyEIdf+KGX7VdlGvzzMQHZ470+tbYs5bsrfHN8KoKzy8jE0Ai41vHQHlSvearPW
	DMW/bUFM7ARcottt73bycvtTN1K6DUjhupY=
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.3 AUTH) with ESMTPSA id 50241cqBBC5j2aY
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 11 Dec 2014 13:05:45 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id D60205015F; Thu, 11 Dec 2014 13:05:44 +0100 (CET)
Date: Thu, 11 Dec 2014 13:05:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141211120544.GB25950@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
	<alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
	<20141211120424.GA25950@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141211120424.GA25950@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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 Thu, Dec 11, Olaf Hering wrote:

> This sounds like xenstored has to parse the possible environment
> variables found in sysconfig.xencommons all by itself? Is there perhaps
> a way out of the SELinux jail?

Does all that work with the sysv runlevel scripts?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:05:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2VC-0000rh-Il; Thu, 11 Dec 2014 12:05:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xz2VB-0000rX-D3
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:05:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	EB/29-09842-C9889845; Thu, 11 Dec 2014 12:05:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418299548!14950392!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3785 invoked from network); 11 Dec 2014 12:05:48 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 12:05:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418299548; l=277;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=M0S6iaHhA1B3PNtvhfc9kMf2OEM=;
	b=n2p7k/o+s0xJhxeFMF+s2fLqw8ohnRQkmamlUDlVDpaGpUammPoEe7mBhOIrrtDA5Tv
	B48R4ZoyEIdf+KGX7VdlGvzzMQHZ470+tbYs5bsrfHN8KoKzy8jE0Ai41vHQHlSvearPW
	DMW/bUFM7ARcottt73bycvtTN1K6DUjhupY=
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.3 AUTH) with ESMTPSA id 50241cqBBC5j2aY
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 11 Dec 2014 13:05:45 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id D60205015F; Thu, 11 Dec 2014 13:05:44 +0100 (CET)
Date: Thu, 11 Dec 2014 13:05:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141211120544.GB25950@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
	<alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
	<20141211120424.GA25950@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141211120424.GA25950@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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 Thu, Dec 11, Olaf Hering wrote:

> This sounds like xenstored has to parse the possible environment
> variables found in sysconfig.xencommons all by itself? Is there perhaps
> a way out of the SELinux jail?

Does all that work with the sysv runlevel scripts?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:07:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:07:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2Wb-00014j-2e; Thu, 11 Dec 2014 12:07: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 1Xz2WZ-00014R-Q2
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 12:07:15 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	60/AA-31453-3F889845; Thu, 11 Dec 2014 12:07:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418299632!12786394!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16898 invoked from network); 11 Dec 2014 12:07:14 -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;
	11 Dec 2014 12:07:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202907134"
Message-ID: <1418299630.10394.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 11 Dec 2014 12:07:10 +0000
In-Reply-To: <1417791061.22808.68.camel@eu.citrix.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
	<5481D3D1020000780004D35F@mail.emea.novell.com>
	<1417791061.22808.68.camel@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Tim
	Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	IanJackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 14:51 +0000, Ian Campbell wrote:
> On Fri, 2014-12-05 at 14:48 +0000, Jan Beulich wrote:
> > >>> On 05.12.14 at 15:27, <Ian.Campbell@eu.citrix.com> wrote:
> > > On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
> > >>  #define nr_static_irqs NR_IRQS
> > >> +#define arch_hwdom_irqs(domid) NR_IRQS
> > > 
> > > FWIW gic_number_lines() is the ARM equivalent of getting the number of
> > > GSIs.
> > > 
> > > *BUT* we don't actually use pirqs on ARM (everything goes via the
> > > virtualised interrupt controller). So maybe we should be setting
> > > nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> > > from an ARM person, so I'm fine with you making this NR_IRQS in the
> > > meantime.
> > 
> > Considering Julien also asking for this, I don't mind changing this to
> > zero for ARM. Just let me know which way I can get this ack-ed.
> 
> If you are happy to provide a version using zero and Julien wants to
> provide a tested-by then I'm fine with going that way.

Seems like things were more complex than Julien expected here, so I
think changing to zero would be a mistake at this point.

AIUI this patch results in no functional change for ARM, in that dom0
previously saw:
        d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
where nr_static_irqs == NR_IRQS on ARM where now it sees:

When extra_dom0_irqs > 0
        nr_static_irqs + extra_dom0_irqs
which is the same as before. Or when extra_dom0_irqs:
        arch_hwdom_irqs(domid);
==   NR_IRQS
==   nr_static_irqs + 0
i.e. no change.

Oh, actually extra_dom0_irqs has changed from a default of 256 to 0, I
don't think NR_IRQS(1024) + 256 made much sense on ARM (which is limited
to 1020 IRQs in h/w anyway), so I don't consider that a problem.

If that's all correct then: 
        Acked-by: Ian Campbell <ian.campbell@citrix.com>

Also Ack with my REST maintainer hat on for the general principal/common
code.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:07:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:07:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2Wb-00014j-2e; Thu, 11 Dec 2014 12:07: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 1Xz2WZ-00014R-Q2
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 12:07:15 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	60/AA-31453-3F889845; Thu, 11 Dec 2014 12:07:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418299632!12786394!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16898 invoked from network); 11 Dec 2014 12:07:14 -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;
	11 Dec 2014 12:07:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202907134"
Message-ID: <1418299630.10394.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 11 Dec 2014 12:07:10 +0000
In-Reply-To: <1417791061.22808.68.camel@eu.citrix.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
	<5481D3D1020000780004D35F@mail.emea.novell.com>
	<1417791061.22808.68.camel@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Tim
	Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	IanJackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-05 at 14:51 +0000, Ian Campbell wrote:
> On Fri, 2014-12-05 at 14:48 +0000, Jan Beulich wrote:
> > >>> On 05.12.14 at 15:27, <Ian.Campbell@eu.citrix.com> wrote:
> > > On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
> > >>  #define nr_static_irqs NR_IRQS
> > >> +#define arch_hwdom_irqs(domid) NR_IRQS
> > > 
> > > FWIW gic_number_lines() is the ARM equivalent of getting the number of
> > > GSIs.
> > > 
> > > *BUT* we don't actually use pirqs on ARM (everything goes via the
> > > virtualised interrupt controller). So maybe we should be setting
> > > nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
> > > from an ARM person, so I'm fine with you making this NR_IRQS in the
> > > meantime.
> > 
> > Considering Julien also asking for this, I don't mind changing this to
> > zero for ARM. Just let me know which way I can get this ack-ed.
> 
> If you are happy to provide a version using zero and Julien wants to
> provide a tested-by then I'm fine with going that way.

Seems like things were more complex than Julien expected here, so I
think changing to zero would be a mistake at this point.

AIUI this patch results in no functional change for ARM, in that dom0
previously saw:
        d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
where nr_static_irqs == NR_IRQS on ARM where now it sees:

When extra_dom0_irqs > 0
        nr_static_irqs + extra_dom0_irqs
which is the same as before. Or when extra_dom0_irqs:
        arch_hwdom_irqs(domid);
==   NR_IRQS
==   nr_static_irqs + 0
i.e. no change.

Oh, actually extra_dom0_irqs has changed from a default of 256 to 0, I
don't think NR_IRQS(1024) + 256 made much sense on ARM (which is limited
to 1020 IRQs in h/w anyway), so I don't consider that a problem.

If that's all correct then: 
        Acked-by: Ian Campbell <ian.campbell@citrix.com>

Also Ack with my REST maintainer hat on for the general principal/common
code.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:09:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 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 1Xz2YD-0001FM-IG; Thu, 11 Dec 2014 12:08: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 1Xz2YB-0001EZ-9t
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 12:08:56 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	32/D3-24859-F4989845; Thu, 11 Dec 2014 12:08:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418299725!12623617!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 31119 invoked from network); 11 Dec 2014 12:08:46 -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;
	11 Dec 2014 12:08:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203311364"
Message-ID: <1418299722.10394.29.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 11 Dec 2014 12:08:42 +0000
In-Reply-To: <548740C4020000780004E471@mail.emea.novell.com>
References: <548740C4020000780004E471@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v2] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-09 at 17:34 +0000, Jan Beulich wrote:
> ... when "conring_size=" was specified on the command line. We can't
> really do this as early as we would want to when the option was not
> specified, as the default depends on knowing the system CPU count. Yet
> the parsing of the ACPI tables is one of the things that generates a
> lot of output especially on large systems.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com> (ARM  and generic bits)

> ---
> v2: Also adjust ARM (as requested by Julien). Rename new function to
>     console_init_ring().
> 
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -745,6 +745,7 @@ void __init start_xen(unsigned long boot
>  
>      dt_uart_init();
>      console_init_preirq();
> +    console_init_ring();
>  
>      system_state = SYS_STATE_boot;
>  
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1187,6 +1187,7 @@ void __init noreturn __start_xen(unsigne
>      }
>  
>      vm_init();
> +    console_init_ring();
>      vesa_init();
>  
>      softirq_init();
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -744,15 +744,14 @@ void __init console_init_preirq(void)
>      }
>  }
>  
> -void __init console_init_postirq(void)
> +void __init console_init_ring(void)
>  {
>      char *ring;
>      unsigned int i, order, memflags;
> -
> -    serial_init_postirq();
> +    unsigned long flags;
>  
>      if ( !opt_conring_size )
> -        opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
> +        return;
>  
>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
>      memflags = MEMF_bits(crashinfo_maxaddr_bits);
> @@ -763,17 +762,30 @@ void __init console_init_postirq(void)
>      }
>      opt_conring_size = PAGE_SIZE << order;
>  
> -    spin_lock_irq(&console_lock);
> +    spin_lock_irqsave(&console_lock, flags);
>      for ( i = conringc ; i != conringp; i++ )
>          ring[i & (opt_conring_size - 1)] = conring[i & (conring_size - 1)];
>      conring = ring;
>      smp_wmb(); /* Allow users of console_force_unlock() to see larger buffer. */
>      conring_size = opt_conring_size;
> -    spin_unlock_irq(&console_lock);
> +    spin_unlock_irqrestore(&console_lock, flags);
>  
>      printk("Allocated console ring of %u KiB.\n", opt_conring_size >> 10);
>  }
>  
> +void __init console_init_postirq(void)
> +{
> +    serial_init_postirq();
> +
> +    if ( conring != _conring )
> +        return;
> +
> +    if ( !opt_conring_size )
> +        opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
> +
> +    console_init_ring();
> +}
> +
>  void __init console_endboot(void)
>  {
>      int i, j;
> --- a/xen/include/xen/console.h
> +++ b/xen/include/xen/console.h
> @@ -14,6 +14,7 @@ struct xen_sysctl_readconsole;
>  long read_console_ring(struct xen_sysctl_readconsole *op);
>  
>  void console_init_preirq(void);
> +void console_init_ring(void);
>  void console_init_postirq(void);
>  void console_endboot(void);
>  int console_has(const char *device);
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:09:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 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 1Xz2YD-0001FM-IG; Thu, 11 Dec 2014 12:08: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 1Xz2YB-0001EZ-9t
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 12:08:56 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	32/D3-24859-F4989845; Thu, 11 Dec 2014 12:08:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418299725!12623617!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 31119 invoked from network); 11 Dec 2014 12:08:46 -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;
	11 Dec 2014 12:08:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203311364"
Message-ID: <1418299722.10394.29.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 11 Dec 2014 12:08:42 +0000
In-Reply-To: <548740C4020000780004E471@mail.emea.novell.com>
References: <548740C4020000780004E471@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v2] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-09 at 17:34 +0000, Jan Beulich wrote:
> ... when "conring_size=" was specified on the command line. We can't
> really do this as early as we would want to when the option was not
> specified, as the default depends on knowing the system CPU count. Yet
> the parsing of the ACPI tables is one of the things that generates a
> lot of output especially on large systems.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com> (ARM  and generic bits)

> ---
> v2: Also adjust ARM (as requested by Julien). Rename new function to
>     console_init_ring().
> 
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -745,6 +745,7 @@ void __init start_xen(unsigned long boot
>  
>      dt_uart_init();
>      console_init_preirq();
> +    console_init_ring();
>  
>      system_state = SYS_STATE_boot;
>  
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1187,6 +1187,7 @@ void __init noreturn __start_xen(unsigne
>      }
>  
>      vm_init();
> +    console_init_ring();
>      vesa_init();
>  
>      softirq_init();
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -744,15 +744,14 @@ void __init console_init_preirq(void)
>      }
>  }
>  
> -void __init console_init_postirq(void)
> +void __init console_init_ring(void)
>  {
>      char *ring;
>      unsigned int i, order, memflags;
> -
> -    serial_init_postirq();
> +    unsigned long flags;
>  
>      if ( !opt_conring_size )
> -        opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
> +        return;
>  
>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
>      memflags = MEMF_bits(crashinfo_maxaddr_bits);
> @@ -763,17 +762,30 @@ void __init console_init_postirq(void)
>      }
>      opt_conring_size = PAGE_SIZE << order;
>  
> -    spin_lock_irq(&console_lock);
> +    spin_lock_irqsave(&console_lock, flags);
>      for ( i = conringc ; i != conringp; i++ )
>          ring[i & (opt_conring_size - 1)] = conring[i & (conring_size - 1)];
>      conring = ring;
>      smp_wmb(); /* Allow users of console_force_unlock() to see larger buffer. */
>      conring_size = opt_conring_size;
> -    spin_unlock_irq(&console_lock);
> +    spin_unlock_irqrestore(&console_lock, flags);
>  
>      printk("Allocated console ring of %u KiB.\n", opt_conring_size >> 10);
>  }
>  
> +void __init console_init_postirq(void)
> +{
> +    serial_init_postirq();
> +
> +    if ( conring != _conring )
> +        return;
> +
> +    if ( !opt_conring_size )
> +        opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
> +
> +    console_init_ring();
> +}
> +
>  void __init console_endboot(void)
>  {
>      int i, j;
> --- a/xen/include/xen/console.h
> +++ b/xen/include/xen/console.h
> @@ -14,6 +14,7 @@ struct xen_sysctl_readconsole;
>  long read_console_ring(struct xen_sysctl_readconsole *op);
>  
>  void console_init_preirq(void);
> +void console_init_ring(void);
>  void console_init_postirq(void);
>  void console_endboot(void);
>  int console_has(const char *device);
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:10:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2ZJ-0001OJ-5z; Thu, 11 Dec 2014 12:10:05 +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 1Xz2ZG-0001Nz-V9
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:10:03 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	C9/0A-25547-A9989845; Thu, 11 Dec 2014 12:10:02 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418299801!12567148!1
X-Originating-IP: [62.176.169.44]
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 15102 invoked from network); 11 Dec 2014 12:10:01 -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; 11 Dec 2014 12:10:01 -0000
Received: from dezo.moloch.sk (unknown [92.240.231.146])
	by mail.moloch.sk (Postfix) with ESMTPSA id D87561800D85;
	Thu, 11 Dec 2014 13:10:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1418299800;
	bh=1tGosqGAq3MlwQUYlitpWKrI8cC5aJr0/qGQC48pNdU=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=GDDauoxb4BAmRdW0v1JbahN49Of2ZM+SlwZSLiemCbVKFK7dwnqHFOybHtbc7HJE8
	wY73hN/S83G0tnFSCOxhfI93i83trB5kjnoHAf2oMRGtm856oxSZc19su5qnxYno8V
	9iDoiEyoPyoMDYzS4ZdPJFLcVkyiHEVedYGnMaD9V1jXD7BW5ldpmtPaXpu23fhns3
	ZATDqAIAzZ75Hy1wY3IXP7bRS29fxB2cCrnfUxmvTGSFbTC3xFNsusC/cms+IDVg0a
	ELjKuBamjYWPhFCDmB9ewmUMJNM2klYe/ckVt9ksx4ef4wbg2uFBCuO2i0+elag/gr
	2ve2TZmXRP2zA==
Received: by dezo.moloch.sk (Postfix, from userid 1000)
	id 2EF6ED059546; Thu, 11 Dec 2014 13:10:00 +0100 (CET)
Date: Thu, 11 Dec 2014 13:10:00 +0100
From: Martin Lucina <martin@lucina.net>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, xen-devel@lists.xen.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
Message-ID: <20141211120959.GA3218@dezo.moloch.sk>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
References: <20141204135550.GC11192@dezo.moloch.sk>
	<20141207195343.GC3141@type.youpi.perso.aquilenet.fr>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141207195343.GC3141@type.youpi.perso.aquilenet.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] [PATCH] Mini-OS: netfront: Fix rx ring starvation
 in network_rx
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Samuel,

Comments and updated patch below.

samuel.thibault@ens-lyon.org said:
> > -        if (rx->flags & NETRXF_extra_info)
> > -        {
> > -            printk("+++++++++++++++++++++ we have extras!\n");
> > -            continue;
> > -        }
> > -
> > -
> > -        if (rx->status == NETIF_RSP_NULL) continue;
> 
> I believe we want to keep them.  Or turn them into
> if (rx->status != NETIF_RSP_OKAY)
>   continue;

If we keep them then the following code calling gnttab_end_access() will
not get called and the second loops calls to gnttab_grant_access() will
not match up.

Rather, shouldn't the final if() in the loop (where data is sent up) be:

  if(rx->status > NETIF_RSP_NULL) { ... }

*we can't use NETIF_RSP_OKAY as NETIF_RSP_NULL is defined to be 1 (yuck).

I don't see any value in keeping the printk(), the netfront driver already
disclaims supporting extras in comments.

> Yes, and I introduced the "some" variable especially for this. The
> idea was to implement a basic support for opening the device with a
> tap behavior.  But we didn't want to introduce dynamic buffers to
> store incoming packets.  In that case we don't run network_rx from the
> interrupt, but netfront_select_handler instead, which will wake the
> select() call, the application then calls netfront_receive(), which eats
> exactly one packet only from the ring.  Thus the "some" variable in
> order to break the loop when exactly one packet was eaten (and no, we
> can't use break or set cons to rp, since that'd would eat 0 or more than
> 1 packets).

Ah, now I understand. The presence of the "some" variable was making it
really hard to reason about the logic in that loop :-/

Assuming you don't want to duplicate some code and write a separate
receive() function for the HAVE_LIBC codepath entirely then a minimal
change which clears things up for future readers is to:

- make "some" explicit using #ifdef HAVE_LIBC 
- take it out of the for() loop initialisation and condition
- set some = 1 and use break to exit the loop

I've done this in the updated patch, take a look and let me know what you
think.

Martin

----
>From 3880f59159bf0a05b47b6e723091b1e7e4fb6814 Mon Sep 17 00:00:00 2001
From: Martin Lucina <martin@lucina.net>
Date: Thu, 4 Dec 2014 14:33:53 +0100
Subject: [PATCH] Mini-OS: netfront: Fix rx ring starvation in network_rx

In network_rx() we must push the same amount of requests back onto the
ring in the second loop that we consumed in the first loop. Otherwise
the ring will eventually starve itself of free request slots and no
packets will be delivered.

Further, we make the HAVE_LIBC codepath clearer to follow by removing
the "some" variable from the for loop initialisation and conditions.

Signed-off-by: Martin Lucina <martin@lucina.net>
---
 extras/mini-os/netfront.c |   36 +++++++++++++++++-------------------
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/extras/mini-os/netfront.c b/extras/mini-os/netfront.c
index 44c3995..42bb103 100644
--- a/extras/mini-os/netfront.c
+++ b/extras/mini-os/netfront.c
@@ -96,42 +96,35 @@ static inline int xennet_rxidx(RING_IDX idx)
 void network_rx(struct netfront_dev *dev)
 {
     RING_IDX rp,cons,req_prod;
-    struct netif_rx_response *rx;
-    int nr_consumed, some, more, i, notify;
-
+    int nr_consumed, more, i, notify;
+#ifdef HAVE_LIBC
+    int some;
+#endif
 
+    nr_consumed = 0;
 moretodo:
     rp = dev->rx.sring->rsp_prod;
     rmb(); /* Ensure we see queued responses up to 'rp'. */
-    cons = dev->rx.rsp_cons;
 
-    for (nr_consumed = 0, some = 0;
-         (cons != rp) && !some;
-         nr_consumed++, cons++)
+#ifdef HAVE_LIBC
+    some = 0;
+#endif
+    for (cons = dev->rx.rsp_cons; cons != rp; nr_consumed++, cons++)
     {
         struct net_buffer* buf;
         unsigned char* page;
         int id;
 
-        rx = RING_GET_RESPONSE(&dev->rx, cons);
-
-        if (rx->flags & NETRXF_extra_info)
-        {
-            printk("+++++++++++++++++++++ we have extras!\n");
-            continue;
-        }
-
-
-        if (rx->status == NETIF_RSP_NULL) continue;
+        struct netif_rx_response *rx = RING_GET_RESPONSE(&dev->rx, cons);
 
         id = rx->id;
-        BUG_ON(id >= NET_TX_RING_SIZE);
+        BUG_ON(id >= NET_RX_RING_SIZE);
 
         buf = &dev->rx_buffers[id];
         page = (unsigned char*)buf->page;
         gnttab_end_access(buf->gref);
 
-        if(rx->status>0)
+        if (rx->status > NETIF_RSP_NULL)
         {
 #ifdef HAVE_LIBC
 	    if (dev->netif_rx == NETIF_SELECT_RX) {
@@ -142,6 +135,7 @@ moretodo:
 		memcpy(dev->data, page+rx->offset, len);
 		dev->rlen = len;
 		some = 1;
+                break;
 	    } else
 #endif
 		dev->netif_rx(page+rx->offset,rx->status);
@@ -150,7 +144,11 @@ moretodo:
     dev->rx.rsp_cons=cons;
 
     RING_FINAL_CHECK_FOR_RESPONSES(&dev->rx,more);
+#ifdef HAVE_LIBC
     if(more && !some) goto moretodo;
+#else
+    if(more) goto moretodo;
+#endif
 
     req_prod = dev->rx.req_prod_pvt;
 
-- 
1.7.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 Dec 11 12:10:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2ZJ-0001OJ-5z; Thu, 11 Dec 2014 12:10:05 +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 1Xz2ZG-0001Nz-V9
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:10:03 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	C9/0A-25547-A9989845; Thu, 11 Dec 2014 12:10:02 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418299801!12567148!1
X-Originating-IP: [62.176.169.44]
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 15102 invoked from network); 11 Dec 2014 12:10:01 -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; 11 Dec 2014 12:10:01 -0000
Received: from dezo.moloch.sk (unknown [92.240.231.146])
	by mail.moloch.sk (Postfix) with ESMTPSA id D87561800D85;
	Thu, 11 Dec 2014 13:10:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1418299800;
	bh=1tGosqGAq3MlwQUYlitpWKrI8cC5aJr0/qGQC48pNdU=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=GDDauoxb4BAmRdW0v1JbahN49Of2ZM+SlwZSLiemCbVKFK7dwnqHFOybHtbc7HJE8
	wY73hN/S83G0tnFSCOxhfI93i83trB5kjnoHAf2oMRGtm856oxSZc19su5qnxYno8V
	9iDoiEyoPyoMDYzS4ZdPJFLcVkyiHEVedYGnMaD9V1jXD7BW5ldpmtPaXpu23fhns3
	ZATDqAIAzZ75Hy1wY3IXP7bRS29fxB2cCrnfUxmvTGSFbTC3xFNsusC/cms+IDVg0a
	ELjKuBamjYWPhFCDmB9ewmUMJNM2klYe/ckVt9ksx4ef4wbg2uFBCuO2i0+elag/gr
	2ve2TZmXRP2zA==
Received: by dezo.moloch.sk (Postfix, from userid 1000)
	id 2EF6ED059546; Thu, 11 Dec 2014 13:10:00 +0100 (CET)
Date: Thu, 11 Dec 2014 13:10:00 +0100
From: Martin Lucina <martin@lucina.net>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, xen-devel@lists.xen.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
Message-ID: <20141211120959.GA3218@dezo.moloch.sk>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
References: <20141204135550.GC11192@dezo.moloch.sk>
	<20141207195343.GC3141@type.youpi.perso.aquilenet.fr>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141207195343.GC3141@type.youpi.perso.aquilenet.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] [PATCH] Mini-OS: netfront: Fix rx ring starvation
 in network_rx
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Samuel,

Comments and updated patch below.

samuel.thibault@ens-lyon.org said:
> > -        if (rx->flags & NETRXF_extra_info)
> > -        {
> > -            printk("+++++++++++++++++++++ we have extras!\n");
> > -            continue;
> > -        }
> > -
> > -
> > -        if (rx->status == NETIF_RSP_NULL) continue;
> 
> I believe we want to keep them.  Or turn them into
> if (rx->status != NETIF_RSP_OKAY)
>   continue;

If we keep them then the following code calling gnttab_end_access() will
not get called and the second loops calls to gnttab_grant_access() will
not match up.

Rather, shouldn't the final if() in the loop (where data is sent up) be:

  if(rx->status > NETIF_RSP_NULL) { ... }

*we can't use NETIF_RSP_OKAY as NETIF_RSP_NULL is defined to be 1 (yuck).

I don't see any value in keeping the printk(), the netfront driver already
disclaims supporting extras in comments.

> Yes, and I introduced the "some" variable especially for this. The
> idea was to implement a basic support for opening the device with a
> tap behavior.  But we didn't want to introduce dynamic buffers to
> store incoming packets.  In that case we don't run network_rx from the
> interrupt, but netfront_select_handler instead, which will wake the
> select() call, the application then calls netfront_receive(), which eats
> exactly one packet only from the ring.  Thus the "some" variable in
> order to break the loop when exactly one packet was eaten (and no, we
> can't use break or set cons to rp, since that'd would eat 0 or more than
> 1 packets).

Ah, now I understand. The presence of the "some" variable was making it
really hard to reason about the logic in that loop :-/

Assuming you don't want to duplicate some code and write a separate
receive() function for the HAVE_LIBC codepath entirely then a minimal
change which clears things up for future readers is to:

- make "some" explicit using #ifdef HAVE_LIBC 
- take it out of the for() loop initialisation and condition
- set some = 1 and use break to exit the loop

I've done this in the updated patch, take a look and let me know what you
think.

Martin

----
>From 3880f59159bf0a05b47b6e723091b1e7e4fb6814 Mon Sep 17 00:00:00 2001
From: Martin Lucina <martin@lucina.net>
Date: Thu, 4 Dec 2014 14:33:53 +0100
Subject: [PATCH] Mini-OS: netfront: Fix rx ring starvation in network_rx

In network_rx() we must push the same amount of requests back onto the
ring in the second loop that we consumed in the first loop. Otherwise
the ring will eventually starve itself of free request slots and no
packets will be delivered.

Further, we make the HAVE_LIBC codepath clearer to follow by removing
the "some" variable from the for loop initialisation and conditions.

Signed-off-by: Martin Lucina <martin@lucina.net>
---
 extras/mini-os/netfront.c |   36 +++++++++++++++++-------------------
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/extras/mini-os/netfront.c b/extras/mini-os/netfront.c
index 44c3995..42bb103 100644
--- a/extras/mini-os/netfront.c
+++ b/extras/mini-os/netfront.c
@@ -96,42 +96,35 @@ static inline int xennet_rxidx(RING_IDX idx)
 void network_rx(struct netfront_dev *dev)
 {
     RING_IDX rp,cons,req_prod;
-    struct netif_rx_response *rx;
-    int nr_consumed, some, more, i, notify;
-
+    int nr_consumed, more, i, notify;
+#ifdef HAVE_LIBC
+    int some;
+#endif
 
+    nr_consumed = 0;
 moretodo:
     rp = dev->rx.sring->rsp_prod;
     rmb(); /* Ensure we see queued responses up to 'rp'. */
-    cons = dev->rx.rsp_cons;
 
-    for (nr_consumed = 0, some = 0;
-         (cons != rp) && !some;
-         nr_consumed++, cons++)
+#ifdef HAVE_LIBC
+    some = 0;
+#endif
+    for (cons = dev->rx.rsp_cons; cons != rp; nr_consumed++, cons++)
     {
         struct net_buffer* buf;
         unsigned char* page;
         int id;
 
-        rx = RING_GET_RESPONSE(&dev->rx, cons);
-
-        if (rx->flags & NETRXF_extra_info)
-        {
-            printk("+++++++++++++++++++++ we have extras!\n");
-            continue;
-        }
-
-
-        if (rx->status == NETIF_RSP_NULL) continue;
+        struct netif_rx_response *rx = RING_GET_RESPONSE(&dev->rx, cons);
 
         id = rx->id;
-        BUG_ON(id >= NET_TX_RING_SIZE);
+        BUG_ON(id >= NET_RX_RING_SIZE);
 
         buf = &dev->rx_buffers[id];
         page = (unsigned char*)buf->page;
         gnttab_end_access(buf->gref);
 
-        if(rx->status>0)
+        if (rx->status > NETIF_RSP_NULL)
         {
 #ifdef HAVE_LIBC
 	    if (dev->netif_rx == NETIF_SELECT_RX) {
@@ -142,6 +135,7 @@ moretodo:
 		memcpy(dev->data, page+rx->offset, len);
 		dev->rlen = len;
 		some = 1;
+                break;
 	    } else
 #endif
 		dev->netif_rx(page+rx->offset,rx->status);
@@ -150,7 +144,11 @@ moretodo:
     dev->rx.rsp_cons=cons;
 
     RING_FINAL_CHECK_FOR_RESPONSES(&dev->rx,more);
+#ifdef HAVE_LIBC
     if(more && !some) goto moretodo;
+#else
+    if(more) goto moretodo;
+#endif
 
     req_prod = dev->rx.req_prod_pvt;
 
-- 
1.7.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 Dec 11 12:13:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:13:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2cA-0001su-4b; Thu, 11 Dec 2014 12:13:02 +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 1Xz2c8-0001sK-MK
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:13:00 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	64/B4-29352-C4A89845; Thu, 11 Dec 2014 12:13:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418299978!5213043!1
X-Originating-IP: [66.165.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 32398 invoked from network); 11 Dec 2014 12:12:59 -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;
	11 Dec 2014 12:12:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202909138"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 07:12: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 1Xz2Yo-0001S0-Ew;
	Thu, 11 Dec 2014 12:09:34 +0000
Date: Thu, 11 Dec 2014 12:09:34 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141211120934.GH21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210180957.26400.66565.stgit@Abyss.station>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141210180957.26400.66565.stgit@Abyss.station>
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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 08/27] ts-unixbench-reslts: for retrieving
	the results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 07:09:57PM +0100, Dario Faggioli wrote:
> and store them in $c{Stash}, in a file named according
> to the following convention:
> 
>  $hostname--$benchname-$benchparams
> 
> i.e., something like this:
> 
>  debian--unixbench-i3-c2
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
> Changes from RFCv1:
>  * use target_getfile_root_stash, as suggested during review;
> ---
>  ts-unixbench-reslts |   67 +++++++++++++++++++++++++++++++++++++++++++++++++++

Typo "reslts" (also in subject line).

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:13:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:13:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2cA-0001su-4b; Thu, 11 Dec 2014 12:13:02 +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 1Xz2c8-0001sK-MK
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:13:00 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	64/B4-29352-C4A89845; Thu, 11 Dec 2014 12:13:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418299978!5213043!1
X-Originating-IP: [66.165.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 32398 invoked from network); 11 Dec 2014 12:12:59 -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;
	11 Dec 2014 12:12:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202909138"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 07:12: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 1Xz2Yo-0001S0-Ew;
	Thu, 11 Dec 2014 12:09:34 +0000
Date: Thu, 11 Dec 2014 12:09:34 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141211120934.GH21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210180957.26400.66565.stgit@Abyss.station>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141210180957.26400.66565.stgit@Abyss.station>
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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 08/27] ts-unixbench-reslts: for retrieving
	the results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 07:09:57PM +0100, Dario Faggioli wrote:
> and store them in $c{Stash}, in a file named according
> to the following convention:
> 
>  $hostname--$benchname-$benchparams
> 
> i.e., something like this:
> 
>  debian--unixbench-i3-c2
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
> Changes from RFCv1:
>  * use target_getfile_root_stash, as suggested during review;
> ---
>  ts-unixbench-reslts |   67 +++++++++++++++++++++++++++++++++++++++++++++++++++

Typo "reslts" (also in subject line).

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:13:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:13:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2cK-0001v8-I6; Thu, 11 Dec 2014 12:13:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xz2cJ-0001uo-1R
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:13:11 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	F0/A9-31453-65A89845; Thu, 11 Dec 2014 12:13:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418299988!12842201!1
X-Originating-IP: [66.165.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 3027 invoked from network); 11 Dec 2014 12:13:09 -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;
	11 Dec 2014 12:13:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202909184"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 07:13: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 1Xz2VG-0001NK-74;
	Thu, 11 Dec 2014 12:05:54 +0000
Date: Thu, 11 Dec 2014 12:05:53 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141211120553.GG21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210180918.26400.69599.stgit@Abyss.station>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141210180918.26400.69599.stgit@Abyss.station>
User-Agent: Mutt/1.5.23 (2014-03-12)
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
Subject: Re: [Xen-devel] [PATCH 03/27] Guest setup: allow the amount of RAM
 to be a runvar
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 07:09:18PM +0100, Dario Faggioli wrote:
> From: Dario Faggioli <raistlin@linux.it>
> 
> the value of which can be retrieved via guest_var('memory');.
> 
> This works for both PV and HVM Debian guests.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  Osstest/TestSupport.pm |    3 ++-
>  ts-debian-fixup        |    3 +++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index a3b6936..cdff8d5 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -1460,11 +1460,12 @@ sub prepareguest_part_xencfg ($$$$$) {
>      my ($ho, $gho, $ram_mb, $xopts, $cfgrest) = @_;
>      my $onreboot= $xopts->{OnReboot} || 'restart';
>      my $vcpus= guest_var($gho, 'vcpus', $xopts->{DefVcpus} || 2);
> +    my $memory= guest_var($gho, 'memory', $xopts->{DefMem} || $ram_mb);
>      my $xoptcfg= $xopts->{ExtraConfig};
>      $xoptcfg='' unless defined $xoptcfg;
>      my $xencfg= <<END;
>  name        = '$gho->{Name}'
> -memory = ${ram_mb}
> +memory = ${memory}

You made ram_mb redundant. And this seems to be deep in the call chain
which has subtle knock on effect.

Wei.

>  vif         = [ 'type=ioemu,mac=$gho->{Ether}' ]
>  #
>  on_poweroff = 'destroy'
> diff --git a/ts-debian-fixup b/ts-debian-fixup
> index f001418..f85b06d 100755
> --- a/ts-debian-fixup
> +++ b/ts-debian-fixup
> @@ -113,10 +113,13 @@ sub setcfg ($$) {
>  
>  sub otherfixupcfg () {
>      my $vcpus= guest_var($gho,'vcpus',1);
> +    my $ram_mb= guest_var($gho,'memory',512);
>      $cfg =~ s/^dhcp/#$&/mg;
>      $cfg =~ s/^on_crash.*/on_crash='preserve'/mg;
>      $cfg =~ s/^vcpus.*//mg;
>      $cfg .= "\nvcpus = $vcpus\n";
> +    $cfg =~ s/^memory.*//mg;
> +    $cfg .= "\nmemory = $ram_mb\n";
>  
>      # PCI passthrough
>      # Look for runvars   <gn>_pcipassthrough_<devtype>=<hostident>
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 11 12:13:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:13:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2cK-0001v8-I6; Thu, 11 Dec 2014 12:13:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xz2cJ-0001uo-1R
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:13:11 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	F0/A9-31453-65A89845; Thu, 11 Dec 2014 12:13:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418299988!12842201!1
X-Originating-IP: [66.165.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 3027 invoked from network); 11 Dec 2014 12:13:09 -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;
	11 Dec 2014 12:13:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202909184"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 07:13: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 1Xz2VG-0001NK-74;
	Thu, 11 Dec 2014 12:05:54 +0000
Date: Thu, 11 Dec 2014 12:05:53 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141211120553.GG21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210180918.26400.69599.stgit@Abyss.station>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141210180918.26400.69599.stgit@Abyss.station>
User-Agent: Mutt/1.5.23 (2014-03-12)
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
Subject: Re: [Xen-devel] [PATCH 03/27] Guest setup: allow the amount of RAM
 to be a runvar
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 07:09:18PM +0100, Dario Faggioli wrote:
> From: Dario Faggioli <raistlin@linux.it>
> 
> the value of which can be retrieved via guest_var('memory');.
> 
> This works for both PV and HVM Debian guests.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  Osstest/TestSupport.pm |    3 ++-
>  ts-debian-fixup        |    3 +++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index a3b6936..cdff8d5 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -1460,11 +1460,12 @@ sub prepareguest_part_xencfg ($$$$$) {
>      my ($ho, $gho, $ram_mb, $xopts, $cfgrest) = @_;
>      my $onreboot= $xopts->{OnReboot} || 'restart';
>      my $vcpus= guest_var($gho, 'vcpus', $xopts->{DefVcpus} || 2);
> +    my $memory= guest_var($gho, 'memory', $xopts->{DefMem} || $ram_mb);
>      my $xoptcfg= $xopts->{ExtraConfig};
>      $xoptcfg='' unless defined $xoptcfg;
>      my $xencfg= <<END;
>  name        = '$gho->{Name}'
> -memory = ${ram_mb}
> +memory = ${memory}

You made ram_mb redundant. And this seems to be deep in the call chain
which has subtle knock on effect.

Wei.

>  vif         = [ 'type=ioemu,mac=$gho->{Ether}' ]
>  #
>  on_poweroff = 'destroy'
> diff --git a/ts-debian-fixup b/ts-debian-fixup
> index f001418..f85b06d 100755
> --- a/ts-debian-fixup
> +++ b/ts-debian-fixup
> @@ -113,10 +113,13 @@ sub setcfg ($$) {
>  
>  sub otherfixupcfg () {
>      my $vcpus= guest_var($gho,'vcpus',1);
> +    my $ram_mb= guest_var($gho,'memory',512);
>      $cfg =~ s/^dhcp/#$&/mg;
>      $cfg =~ s/^on_crash.*/on_crash='preserve'/mg;
>      $cfg =~ s/^vcpus.*//mg;
>      $cfg .= "\nvcpus = $vcpus\n";
> +    $cfg =~ s/^memory.*//mg;
> +    $cfg .= "\nmemory = $ram_mb\n";
>  
>      # PCI passthrough
>      # Look for runvars   <gn>_pcipassthrough_<devtype>=<hostident>
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 11 12:15:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2eV-00029b-GM; Thu, 11 Dec 2014 12:15:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xz2eU-00029E-0c
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 12:15:26 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	0A/15-24124-DDA89845; Thu, 11 Dec 2014 12:15:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418300123!12796405!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 556 invoked from network); 11 Dec 2014 12:15:24 -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 Dec 2014 12:15:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203313732"
Message-ID: <54898AD9.2030009@citrix.com>
Date: Thu, 11 Dec 2014 12:15:21 +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: 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>
References: <1418226963-24873-1-git-send-email-jgross@suse.com>	<54888BC6.7030601@citrix.com>
	<54892C58.5070707@suse.com>
In-Reply-To: <54892C58.5070707@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen
 mmu.c earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/14 05:32, Juergen Gross wrote:
> On 12/10/2014 07:07 PM, David Vrabel wrote:
>> On 10/12/14 15:56, Juergen Gross wrote:
>>> With the virtual mapped linear p2m list the post-init mmu operations
>>> must be used for setting up the p2m mappings, as in case of
>>> CONFIG_FLATMEM the init routines may trigger BUGs.
>>>
>>> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>>   arch/x86/xen/mmu.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>>> index 6ab6150..a1a429a 100644
>>> --- a/arch/x86/xen/mmu.c
>>> +++ b/arch/x86/xen/mmu.c
>>> @@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
>>>   static void __init xen_pagetable_init(void)
>>>   {
>>>       paging_init();
>>> +    xen_post_allocator_init();
>>>
>>>       xen_pagetable_p2m_setup();
>>>
>>
>> This feels very chicken-and-egg to me:  To setup the P2M we need to use
>> the MMU ops that use the P2M...
>>
>> Please explain very clearly why this is all safe.
> 
> Okay. paging_init() sets up all infrastructure needed to switch to the
> post-init mmu ops done by xen_post_allocator_init(). With the virtual
> mapped linear p2m list we need some mmu ops during setup of this list,
> so we have to switch to the correct mmu ops as soon as possible.
> 
> The p2m list is usable from the beginning, just expansion requires to
> have established the new linear mapping. So the call of
> xen_remap_memory() had to be introduced, but this is not due to the
> mmu ops requiring this.
> 
> Summing it up: calling xen_post_allocator_init() not directly after
> paging_init() was conceptually wrong in the beginning, it just didn't
> matter up to now as no functions used between the two calls needed
> some critical mmu ops (e.g. alloc_pte). This has changed now, so I
> corrected it.

I've added this to the commit message and applied to
devel/for-linus-3.19.  If the tests pass I will consider sending a
further pull request for 3.19 including the linear p2m changes early
next week.

Thanks.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:15:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2eN-00028L-40; Thu, 11 Dec 2014 12:15:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1Xz2eM-00028A-2O
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 12:15:18 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	26/B9-03148-5DA89845; Thu, 11 Dec 2014 12:15:17 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418300116!14344260!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17091 invoked from network); 11 Dec 2014 12:15:16 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 12:15:16 -0000
Received: by mail-wg0-f47.google.com with SMTP id n12so6184080wgh.6
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 04:15:16 -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:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=iUlyhHaPiUaEKiOEnGsd+IO1ec/2nDeS2M3dWKRLA2Y=;
	b=wtcLuCkak+/vThh0CE+5fwdoHSRAF1Mwb55Uek1FpFdLD8+uy6Vkh32IP+/ko9Ikc1
	jL8mdY97V2NxifIhI7X+jV9iGeoHeyapA1ZWXsljp6HTCn0PhaZJfobbyRSAOEzsy1sR
	rEQhbo1a3ndN9mVTCLWWA1Otxrjmw9Gy1dFZhT4g/xOxaeNZFHBokfCZ3Nca1fUQkQ3s
	1WGFlFm+aoAxPK9/qN5Nv2W1CuRdb0zEus/788iWYZwKSJtGWwZ5dXKH+cj8rLUT4egL
	koTS8qqGvMBfXXXIcSX0UEcIYuEGxlrmdDbSDs7EWDDwfqrhlQA+s3juwF6yWEmzxcRS
	sMLw==
X-Received: by 10.194.174.72 with SMTP id bq8mr15760113wjc.120.1418300115982; 
	Thu, 11 Dec 2014 04:15:15 -0800 (PST)
Received: from [10.80.2.76] ([185.25.64.249])
	by mx.google.com with ESMTPSA id t10sm2720389wix.15.2014.12.11.04.15.14
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 04:15:15 -0800 (PST)
Message-ID: <54898AD1.5060006@cantab.net>
Date: Thu, 11 Dec 2014 12:15:13 +0000
From: David Vrabel <dvrabel@cantab.net>
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>, David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, 
	konrad.wilk@oracle.com, boris.ostrovsky@oracle.com
References: <1418226963-24873-1-git-send-email-jgross@suse.com>	<54888BC6.7030601@citrix.com>
	<54892C58.5070707@suse.com>
In-Reply-To: <54892C58.5070707@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen
 mmu.c earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/14 05:32, Juergen Gross wrote:
> On 12/10/2014 07:07 PM, David Vrabel wrote:
>> On 10/12/14 15:56, Juergen Gross wrote:
>>> With the virtual mapped linear p2m list the post-init mmu operations
>>> must be used for setting up the p2m mappings, as in case of
>>> CONFIG_FLATMEM the init routines may trigger BUGs.
>>>
>>> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>>   arch/x86/xen/mmu.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>>> index 6ab6150..a1a429a 100644
>>> --- a/arch/x86/xen/mmu.c
>>> +++ b/arch/x86/xen/mmu.c
>>> @@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
>>>   static void __init xen_pagetable_init(void)
>>>   {
>>>       paging_init();
>>> +    xen_post_allocator_init();
>>>
>>>       xen_pagetable_p2m_setup();
>>>
>>
>> This feels very chicken-and-egg to me:  To setup the P2M we need to use
>> the MMU ops that use the P2M...
>>
>> Please explain very clearly why this is all safe.
> 
> Okay. paging_init() sets up all infrastructure needed to switch to the
> post-init mmu ops done by xen_post_allocator_init(). With the virtual
> mapped linear p2m list we need some mmu ops during setup of this list,
> so we have to switch to the correct mmu ops as soon as possible.
> 
> The p2m list is usable from the beginning, just expansion requires to
> have established the new linear mapping. So the call of
> xen_remap_memory() had to be introduced, but this is not due to the
> mmu ops requiring this.
> 
> Summing it up: calling xen_post_allocator_init() not directly after
> paging_init() was conceptually wrong in the beginning, it just didn't
> matter up to now as no functions used between the two calls needed
> some critical mmu ops (e.g. alloc_pte). This has changed now, so I
> corrected it.

I've added this to the commit message and applied to
devel/for-linus-3.19.  If the tests pass I will consider sending a
further pull request for 3.19 including the linear p2m changes early
next week.

Thanks.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:15:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2eN-00028L-40; Thu, 11 Dec 2014 12:15:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1Xz2eM-00028A-2O
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 12:15:18 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	26/B9-03148-5DA89845; Thu, 11 Dec 2014 12:15:17 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418300116!14344260!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17091 invoked from network); 11 Dec 2014 12:15:16 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 12:15:16 -0000
Received: by mail-wg0-f47.google.com with SMTP id n12so6184080wgh.6
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 04:15:16 -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:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=iUlyhHaPiUaEKiOEnGsd+IO1ec/2nDeS2M3dWKRLA2Y=;
	b=wtcLuCkak+/vThh0CE+5fwdoHSRAF1Mwb55Uek1FpFdLD8+uy6Vkh32IP+/ko9Ikc1
	jL8mdY97V2NxifIhI7X+jV9iGeoHeyapA1ZWXsljp6HTCn0PhaZJfobbyRSAOEzsy1sR
	rEQhbo1a3ndN9mVTCLWWA1Otxrjmw9Gy1dFZhT4g/xOxaeNZFHBokfCZ3Nca1fUQkQ3s
	1WGFlFm+aoAxPK9/qN5Nv2W1CuRdb0zEus/788iWYZwKSJtGWwZ5dXKH+cj8rLUT4egL
	koTS8qqGvMBfXXXIcSX0UEcIYuEGxlrmdDbSDs7EWDDwfqrhlQA+s3juwF6yWEmzxcRS
	sMLw==
X-Received: by 10.194.174.72 with SMTP id bq8mr15760113wjc.120.1418300115982; 
	Thu, 11 Dec 2014 04:15:15 -0800 (PST)
Received: from [10.80.2.76] ([185.25.64.249])
	by mx.google.com with ESMTPSA id t10sm2720389wix.15.2014.12.11.04.15.14
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 04:15:15 -0800 (PST)
Message-ID: <54898AD1.5060006@cantab.net>
Date: Thu, 11 Dec 2014 12:15:13 +0000
From: David Vrabel <dvrabel@cantab.net>
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>, David Vrabel <david.vrabel@citrix.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, 
	konrad.wilk@oracle.com, boris.ostrovsky@oracle.com
References: <1418226963-24873-1-git-send-email-jgross@suse.com>	<54888BC6.7030601@citrix.com>
	<54892C58.5070707@suse.com>
In-Reply-To: <54892C58.5070707@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen
 mmu.c earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/14 05:32, Juergen Gross wrote:
> On 12/10/2014 07:07 PM, David Vrabel wrote:
>> On 10/12/14 15:56, Juergen Gross wrote:
>>> With the virtual mapped linear p2m list the post-init mmu operations
>>> must be used for setting up the p2m mappings, as in case of
>>> CONFIG_FLATMEM the init routines may trigger BUGs.
>>>
>>> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>>   arch/x86/xen/mmu.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>>> index 6ab6150..a1a429a 100644
>>> --- a/arch/x86/xen/mmu.c
>>> +++ b/arch/x86/xen/mmu.c
>>> @@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
>>>   static void __init xen_pagetable_init(void)
>>>   {
>>>       paging_init();
>>> +    xen_post_allocator_init();
>>>
>>>       xen_pagetable_p2m_setup();
>>>
>>
>> This feels very chicken-and-egg to me:  To setup the P2M we need to use
>> the MMU ops that use the P2M...
>>
>> Please explain very clearly why this is all safe.
> 
> Okay. paging_init() sets up all infrastructure needed to switch to the
> post-init mmu ops done by xen_post_allocator_init(). With the virtual
> mapped linear p2m list we need some mmu ops during setup of this list,
> so we have to switch to the correct mmu ops as soon as possible.
> 
> The p2m list is usable from the beginning, just expansion requires to
> have established the new linear mapping. So the call of
> xen_remap_memory() had to be introduced, but this is not due to the
> mmu ops requiring this.
> 
> Summing it up: calling xen_post_allocator_init() not directly after
> paging_init() was conceptually wrong in the beginning, it just didn't
> matter up to now as no functions used between the two calls needed
> some critical mmu ops (e.g. alloc_pte). This has changed now, so I
> corrected it.

I've added this to the commit message and applied to
devel/for-linus-3.19.  If the tests pass I will consider sending a
further pull request for 3.19 including the linear p2m changes early
next week.

Thanks.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:15:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2eV-00029b-GM; Thu, 11 Dec 2014 12:15:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xz2eU-00029E-0c
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 12:15:26 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	0A/15-24124-DDA89845; Thu, 11 Dec 2014 12:15:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418300123!12796405!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 556 invoked from network); 11 Dec 2014 12:15:24 -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 Dec 2014 12:15:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203313732"
Message-ID: <54898AD9.2030009@citrix.com>
Date: Thu, 11 Dec 2014 12:15:21 +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: 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>
References: <1418226963-24873-1-git-send-email-jgross@suse.com>	<54888BC6.7030601@citrix.com>
	<54892C58.5070707@suse.com>
In-Reply-To: <54892C58.5070707@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen
 mmu.c earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/14 05:32, Juergen Gross wrote:
> On 12/10/2014 07:07 PM, David Vrabel wrote:
>> On 10/12/14 15:56, Juergen Gross wrote:
>>> With the virtual mapped linear p2m list the post-init mmu operations
>>> must be used for setting up the p2m mappings, as in case of
>>> CONFIG_FLATMEM the init routines may trigger BUGs.
>>>
>>> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>>   arch/x86/xen/mmu.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>>> index 6ab6150..a1a429a 100644
>>> --- a/arch/x86/xen/mmu.c
>>> +++ b/arch/x86/xen/mmu.c
>>> @@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
>>>   static void __init xen_pagetable_init(void)
>>>   {
>>>       paging_init();
>>> +    xen_post_allocator_init();
>>>
>>>       xen_pagetable_p2m_setup();
>>>
>>
>> This feels very chicken-and-egg to me:  To setup the P2M we need to use
>> the MMU ops that use the P2M...
>>
>> Please explain very clearly why this is all safe.
> 
> Okay. paging_init() sets up all infrastructure needed to switch to the
> post-init mmu ops done by xen_post_allocator_init(). With the virtual
> mapped linear p2m list we need some mmu ops during setup of this list,
> so we have to switch to the correct mmu ops as soon as possible.
> 
> The p2m list is usable from the beginning, just expansion requires to
> have established the new linear mapping. So the call of
> xen_remap_memory() had to be introduced, but this is not due to the
> mmu ops requiring this.
> 
> Summing it up: calling xen_post_allocator_init() not directly after
> paging_init() was conceptually wrong in the beginning, it just didn't
> matter up to now as no functions used between the two calls needed
> some critical mmu ops (e.g. alloc_pte). This has changed now, so I
> corrected it.

I've added this to the commit message and applied to
devel/for-linus-3.19.  If the tests pass I will consider sending a
further pull request for 3.19 including the linear p2m changes early
next week.

Thanks.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:16:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:16:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2f2-0002Gf-U4; Thu, 11 Dec 2014 12:16: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 1Xz2f0-0002G5-RB
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:15:59 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	06/CD-09842-EFA89845; Thu, 11 Dec 2014 12:15:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418300156!14935501!1
X-Originating-IP: [66.165.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 22487 invoked from network); 11 Dec 2014 12:15:57 -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;
	11 Dec 2014 12:15:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202910137"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 07:15: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 1Xz2ew-0001ge-Eh;
	Thu, 11 Dec 2014 12:15:54 +0000
Date: Thu, 11 Dec 2014 12:15:54 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141211121554.GI21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181006.26400.25863.stgit@Abyss.station>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141210181006.26400.25863.stgit@Abyss.station>
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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/27] ts-unixbench-reslts: process and plot
	bench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 07:10:06PM +0100, Dario Faggioli wrote:
> From: Dario Faggioli <raistlin@linux.it>
> 
> Mangle the results of a run of unixbench a bit, so that
> they can be plotted. This also produces a (gnu)plot script
> and the plot itself. All is saved in $stash, for the
> running flight and job.
> 
> 
> This is done in a new Osstest/Benchmarking.pm module, as
> the functions introduced may turn out useful somewhere else
> too.
> 

I would suggest using a dedicated commit for the introduction of
Benchmarking.pm.

> The results are read from the original unixbench results
> file and a new file, with basically a table in it is
> produced. Gnuplot uses such file as data for the plotting.
> 
> A gnuplot script is produced and invoked (and saved in $stash)
> rather than using the gnuplot perl binding because, this way,
> one can modify the plotting commands a bit, and regen the
> plot(s).
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  Osstest/Benchmarking.pm |  115 +++++++++++++++++++++++++++++++++++++++++++++++
>  ts-unixbench-reslts     |   17 +++++++
>  2 files changed, 132 insertions(+)
>  create mode 100644 Osstest/Benchmarking.pm
> 
> diff --git a/Osstest/Benchmarking.pm b/Osstest/Benchmarking.pm
> new file mode 100644
> index 0000000..0c5c538
> --- /dev/null
> +++ b/Osstest/Benchmarking.pm
> @@ -0,0 +1,115 @@
> +# This is part of "osstest", an automated testing framework for Xen.
> +# Copyright (C) 2009-2013 Citrix Inc.

2009-2014

> +#
> +# 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::Benchmarking;
> +
> +use strict;
> +use warnings;
> +
> +use IO::File;
> +use IPC::Cmd qw[can_run run];
> +
> +use Osstest;
> +use Osstest::TestSupport;
> +
> +BEGIN {
> +    use Exporter ();
> +    our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
> +    $VERSION     = 1.00;
> +    @ISA         = qw(Exporter);
> +    @EXPORT      = qw(unixbench_process_results
> +                      unixbench_print_results
> +                      unixbench_plot_results
> +                      );
> +    %EXPORT_TAGS = ( );
> +
> +    @EXPORT_OK   = qw();
> +}
> +
> +#---------- manipulation of benchmarks results ----------
> +
> +sub unixbench_process_results ($$) {
> +  my ($results_ref,$rfilen)= @_;
> +  my $h= new IO::File "< $rfilen" or die "$!";
> +
> +  my $par;
> +  while (<$h>) {
> +    my ($bench,$val,$idx);
> +    if (m/.*running ([0-9]*) parallel.*$/) {
> +      $par= $1;
> +    }
> +    if (m/^(\S[a-zA-z0-9-\(\)\s]*)\s([0-9]+.[0-9]?)\s*([0-9]+.[0-9]?)\s*([0-9]+.[0-9]?)$/) {
> +      $val= $3;
> +      $idx= $4;
> +      ($bench = $1) =~ s/\s+$//;
> +      $$results_ref->{"$bench"}{Result}{"$par"}= $val;
> +      $$results_ref->{"$bench"}{Index}{"$par"}= $idx;
> +    }
> +    next;
> +  }
> +  close($h);
> +}
> +
> +sub unixbench_print_results ($$) {
> +  my ($results,$rfilen)= @_;
> +  open my $h, "|-", "tee $rfilen" or die "$!";
> +
> +  printf $h "%-50s","\"BENCHMARK NAME\"";
> +  foreach my $i (sort keys $results->{'Double-Precision Whetstone'}{Index}) {
> +    printf $h "%-15s","\"$i VCPUs\"";
> +  }
> +  print $h "\n";
> +  foreach my $b (keys $results) {
> +    printf $h "%-50s","\"$b\"";
> +    foreach my $i (sort keys $results->{"$b"}{Index}) {
> +      printf $h "%-15s",$results->{$b}{Index}{$i};
> +    }
> +    print $h "\n";
> +  }
> +  close($h);
> +}
> +
> +sub unixbench_plot_results ($$$) {
> +  my ($dataf,$num_cols,$pfile)= @_;
> +  my $h= new IO::File "> $pfile.gp" or die "$!";
> +
> +  printf $h <<EOF;
> +set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" 8 size 800,600
> +set output '$pfile.png'
> +set title 'Unixbench INDEXes for $flight.$job'
> +set key outside center top horizontal noreverse noenhanced autotitles nobox
> +set xtics mirror rotate by -45 out
> +set style data histogram
> +set style histogram cluster gap 1
> +set style fill solid border lt -1
> +set boxwidth 1 absolute
> +set bmargin 13
> +set rmargin 14
> +SKIP_COL=1
> +NCOL=$num_cols
> +HWIDTH=1.0/(NCOL+1.0)
> +plot for [c=SKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with histograms title columnhead, \\
> +        for [c=SKIP_COL+1:SKIP_COL+NCOL]'' every ::1 using 0:c:c with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1))*HWIDTH, character 2 rotate by 90
> +EOF
> +  close($h);
> +
> +  my $gp= can_run('gnuplot') or return;

Need to install gnuplot before hand?

> +  my ($ok,$err)= run( command => "$gp $pfile.gp", verbose => 1 );
> +  logm("WARNING: plotting file with \"$err\"") unless $ok;

Fail the test case instead of issuing a warning?

Wei.

> +}
> +
> +1;
> diff --git a/ts-unixbench-reslts b/ts-unixbench-reslts
> index 6e5a9a8..b480d15 100755
> --- a/ts-unixbench-reslts
> +++ b/ts-unixbench-reslts
> @@ -21,6 +21,7 @@ use DBI;
>  use IO::File;
>  use POSIX;
>  use Osstest::TestSupport;
> +use Osstest::Benchmarking;
>  
>  tsreadconfig();
>  
> @@ -46,6 +47,8 @@ $lresfile .= (defined($r{'unixbench_run_suffix'})) ?
>        $r{'unixbench_run_suffix'} : '';
>  $lresfile = "unixbench$lresfile";
>  
> +our $results;
> +
>  # Unixbench stores results in a subdirectory called 'results'. The file name
>  # is made up out of the box's hostname, today's date and a progressive id
>  # (e.g., results/benny-2014-07-02-01).
> @@ -64,4 +67,18 @@ END
>        "$lresfile");
>  }
>  
> +sub process () {
> +  my $resf= "$stash/$gho->{Name}--$lresfile";
> +  my $dataf= "$resf-DATA";
> +  my $plotf= "$resf-PLOT";
> +
> +  unixbench_process_results(\$results,$resf);
> +  unixbench_print_results($results,$dataf);
> +
> +  # For plotting we need to know the number of data columns
> +  my $ncols= keys $results->{'Double-Precision Whetstone'}{Index};
> +  unixbench_plot_results($dataf,$ncols,$plotf);
> +}
> +
>  fetch();
> +process();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:16:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:16:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2f2-0002Gf-U4; Thu, 11 Dec 2014 12:16: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 1Xz2f0-0002G5-RB
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:15:59 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	06/CD-09842-EFA89845; Thu, 11 Dec 2014 12:15:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418300156!14935501!1
X-Originating-IP: [66.165.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 22487 invoked from network); 11 Dec 2014 12:15:57 -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;
	11 Dec 2014 12:15:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202910137"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 07:15: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 1Xz2ew-0001ge-Eh;
	Thu, 11 Dec 2014 12:15:54 +0000
Date: Thu, 11 Dec 2014 12:15:54 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141211121554.GI21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181006.26400.25863.stgit@Abyss.station>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141210181006.26400.25863.stgit@Abyss.station>
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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/27] ts-unixbench-reslts: process and plot
	bench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 07:10:06PM +0100, Dario Faggioli wrote:
> From: Dario Faggioli <raistlin@linux.it>
> 
> Mangle the results of a run of unixbench a bit, so that
> they can be plotted. This also produces a (gnu)plot script
> and the plot itself. All is saved in $stash, for the
> running flight and job.
> 
> 
> This is done in a new Osstest/Benchmarking.pm module, as
> the functions introduced may turn out useful somewhere else
> too.
> 

I would suggest using a dedicated commit for the introduction of
Benchmarking.pm.

> The results are read from the original unixbench results
> file and a new file, with basically a table in it is
> produced. Gnuplot uses such file as data for the plotting.
> 
> A gnuplot script is produced and invoked (and saved in $stash)
> rather than using the gnuplot perl binding because, this way,
> one can modify the plotting commands a bit, and regen the
> plot(s).
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  Osstest/Benchmarking.pm |  115 +++++++++++++++++++++++++++++++++++++++++++++++
>  ts-unixbench-reslts     |   17 +++++++
>  2 files changed, 132 insertions(+)
>  create mode 100644 Osstest/Benchmarking.pm
> 
> diff --git a/Osstest/Benchmarking.pm b/Osstest/Benchmarking.pm
> new file mode 100644
> index 0000000..0c5c538
> --- /dev/null
> +++ b/Osstest/Benchmarking.pm
> @@ -0,0 +1,115 @@
> +# This is part of "osstest", an automated testing framework for Xen.
> +# Copyright (C) 2009-2013 Citrix Inc.

2009-2014

> +#
> +# 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::Benchmarking;
> +
> +use strict;
> +use warnings;
> +
> +use IO::File;
> +use IPC::Cmd qw[can_run run];
> +
> +use Osstest;
> +use Osstest::TestSupport;
> +
> +BEGIN {
> +    use Exporter ();
> +    our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
> +    $VERSION     = 1.00;
> +    @ISA         = qw(Exporter);
> +    @EXPORT      = qw(unixbench_process_results
> +                      unixbench_print_results
> +                      unixbench_plot_results
> +                      );
> +    %EXPORT_TAGS = ( );
> +
> +    @EXPORT_OK   = qw();
> +}
> +
> +#---------- manipulation of benchmarks results ----------
> +
> +sub unixbench_process_results ($$) {
> +  my ($results_ref,$rfilen)= @_;
> +  my $h= new IO::File "< $rfilen" or die "$!";
> +
> +  my $par;
> +  while (<$h>) {
> +    my ($bench,$val,$idx);
> +    if (m/.*running ([0-9]*) parallel.*$/) {
> +      $par= $1;
> +    }
> +    if (m/^(\S[a-zA-z0-9-\(\)\s]*)\s([0-9]+.[0-9]?)\s*([0-9]+.[0-9]?)\s*([0-9]+.[0-9]?)$/) {
> +      $val= $3;
> +      $idx= $4;
> +      ($bench = $1) =~ s/\s+$//;
> +      $$results_ref->{"$bench"}{Result}{"$par"}= $val;
> +      $$results_ref->{"$bench"}{Index}{"$par"}= $idx;
> +    }
> +    next;
> +  }
> +  close($h);
> +}
> +
> +sub unixbench_print_results ($$) {
> +  my ($results,$rfilen)= @_;
> +  open my $h, "|-", "tee $rfilen" or die "$!";
> +
> +  printf $h "%-50s","\"BENCHMARK NAME\"";
> +  foreach my $i (sort keys $results->{'Double-Precision Whetstone'}{Index}) {
> +    printf $h "%-15s","\"$i VCPUs\"";
> +  }
> +  print $h "\n";
> +  foreach my $b (keys $results) {
> +    printf $h "%-50s","\"$b\"";
> +    foreach my $i (sort keys $results->{"$b"}{Index}) {
> +      printf $h "%-15s",$results->{$b}{Index}{$i};
> +    }
> +    print $h "\n";
> +  }
> +  close($h);
> +}
> +
> +sub unixbench_plot_results ($$$) {
> +  my ($dataf,$num_cols,$pfile)= @_;
> +  my $h= new IO::File "> $pfile.gp" or die "$!";
> +
> +  printf $h <<EOF;
> +set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" 8 size 800,600
> +set output '$pfile.png'
> +set title 'Unixbench INDEXes for $flight.$job'
> +set key outside center top horizontal noreverse noenhanced autotitles nobox
> +set xtics mirror rotate by -45 out
> +set style data histogram
> +set style histogram cluster gap 1
> +set style fill solid border lt -1
> +set boxwidth 1 absolute
> +set bmargin 13
> +set rmargin 14
> +SKIP_COL=1
> +NCOL=$num_cols
> +HWIDTH=1.0/(NCOL+1.0)
> +plot for [c=SKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with histograms title columnhead, \\
> +        for [c=SKIP_COL+1:SKIP_COL+NCOL]'' every ::1 using 0:c:c with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1))*HWIDTH, character 2 rotate by 90
> +EOF
> +  close($h);
> +
> +  my $gp= can_run('gnuplot') or return;

Need to install gnuplot before hand?

> +  my ($ok,$err)= run( command => "$gp $pfile.gp", verbose => 1 );
> +  logm("WARNING: plotting file with \"$err\"") unless $ok;

Fail the test case instead of issuing a warning?

Wei.

> +}
> +
> +1;
> diff --git a/ts-unixbench-reslts b/ts-unixbench-reslts
> index 6e5a9a8..b480d15 100755
> --- a/ts-unixbench-reslts
> +++ b/ts-unixbench-reslts
> @@ -21,6 +21,7 @@ use DBI;
>  use IO::File;
>  use POSIX;
>  use Osstest::TestSupport;
> +use Osstest::Benchmarking;
>  
>  tsreadconfig();
>  
> @@ -46,6 +47,8 @@ $lresfile .= (defined($r{'unixbench_run_suffix'})) ?
>        $r{'unixbench_run_suffix'} : '';
>  $lresfile = "unixbench$lresfile";
>  
> +our $results;
> +
>  # Unixbench stores results in a subdirectory called 'results'. The file name
>  # is made up out of the box's hostname, today's date and a progressive id
>  # (e.g., results/benny-2014-07-02-01).
> @@ -64,4 +67,18 @@ END
>        "$lresfile");
>  }
>  
> +sub process () {
> +  my $resf= "$stash/$gho->{Name}--$lresfile";
> +  my $dataf= "$resf-DATA";
> +  my $plotf= "$resf-PLOT";
> +
> +  unixbench_process_results(\$results,$resf);
> +  unixbench_print_results($results,$dataf);
> +
> +  # For plotting we need to know the number of data columns
> +  my $ncols= keys $results->{'Double-Precision Whetstone'}{Index};
> +  unixbench_plot_results($dataf,$ncols,$plotf);
> +}
> +
>  fetch();
> +process();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:16:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2fI-0002LE-Hm; Thu, 11 Dec 2014 12:16:16 +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 1Xz2fI-0002Kp-17
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:16:16 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	03/47-24124-F0B89845; Thu, 11 Dec 2014 12:16:15 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418300174!12801246!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 22212 invoked from network); 11 Dec 2014 12:16:14 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Dec 2014 12:16:14 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz2ev-000Gdm-V3; Thu, 11 Dec 2014 12:15:53 +0000
Date: Thu, 11 Dec 2014 13:15:53 +0100
From: Tim Deegan <tim@xen.org>
To: vijay.kilari@gmail.com
Message-ID: <20141211121553.GB53811@deinos.phlegethon.org>
References: <1418099995-22777-1-git-send-email-vijay.kilari@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418099995-22777-1-git-send-email-vijay.kilari@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: Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Prasun.Kapoor@caviumnetworks.com,
	manish.jaggi@caviumnetworks.com, julien.grall@linaro.org,
	xen-devel@lists.xen.org, stefano.stabellini@citrix.com,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Subject: Re: [Xen-devel] [PATCH v1] xen/arm: Manage pl011 uart TX interrupt
	correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:09 +0530 on 09 Dec (1418116195), vijay.kilari@gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> 
> In pl011.c, when TX interrupt is received
> serial_tx_interrupt() is called to push next
> characters. If TX buffer is empty, serial_tx_interrupt()
> does not disable TX interrupt and hence pl011 UART
> irq handler pl011_interrupt() always sees TX interrupt
> status set in MIS register and cpu does not come out of
> UART irq handler.
> 
> With this patch, mask TX interrupt by writing 0 to
> IMSC register when TX buffer is empty and unmask by
> writing 1 to IMSC register before sending characters.
> 
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.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 Dec 11 12:16:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12: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 1Xz2fI-0002LE-Hm; Thu, 11 Dec 2014 12:16:16 +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 1Xz2fI-0002Kp-17
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:16:16 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	03/47-24124-F0B89845; Thu, 11 Dec 2014 12:16:15 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418300174!12801246!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 22212 invoked from network); 11 Dec 2014 12:16:14 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Dec 2014 12:16:14 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz2ev-000Gdm-V3; Thu, 11 Dec 2014 12:15:53 +0000
Date: Thu, 11 Dec 2014 13:15:53 +0100
From: Tim Deegan <tim@xen.org>
To: vijay.kilari@gmail.com
Message-ID: <20141211121553.GB53811@deinos.phlegethon.org>
References: <1418099995-22777-1-git-send-email-vijay.kilari@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418099995-22777-1-git-send-email-vijay.kilari@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: Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Prasun.Kapoor@caviumnetworks.com,
	manish.jaggi@caviumnetworks.com, julien.grall@linaro.org,
	xen-devel@lists.xen.org, stefano.stabellini@citrix.com,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Subject: Re: [Xen-devel] [PATCH v1] xen/arm: Manage pl011 uart TX interrupt
	correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:09 +0530 on 09 Dec (1418116195), vijay.kilari@gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> 
> In pl011.c, when TX interrupt is received
> serial_tx_interrupt() is called to push next
> characters. If TX buffer is empty, serial_tx_interrupt()
> does not disable TX interrupt and hence pl011 UART
> irq handler pl011_interrupt() always sees TX interrupt
> status set in MIS register and cpu does not come out of
> UART irq handler.
> 
> With this patch, mask TX interrupt by writing 0 to
> IMSC register when TX buffer is empty and unmask by
> writing 1 to IMSC register before sending characters.
> 
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.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 Dec 11 12:25:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:25:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2nO-00030k-Hu; Thu, 11 Dec 2014 12:24: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 1Xz2nN-00030f-K8
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:24:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	EA/A7-15461-50D89845; Thu, 11 Dec 2014 12:24:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418300675!14913166!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 24166 invoked from network); 11 Dec 2014 12:24:36 -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;
	11 Dec 2014 12:24:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203316241"
Message-ID: <1418300672.10394.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <vijay.kilari@gmail.com>
Date: Thu, 11 Dec 2014 12:24:32 +0000
In-Reply-To: <1418099995-22777-1-git-send-email-vijay.kilari@gmail.com>
References: <1418099995-22777-1-git-send-email-vijay.kilari@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, stefano.stabellini@eu.citrix.com,
	Prasun.Kapoor@caviumnetworks.com,
	manish.jaggi@caviumnetworks.com, julien.grall@linaro.org,
	tim@xen.org, xen-devel@lists.xen.org, stefano.stabellini@citrix.com,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Subject: Re: [Xen-devel] [PATCH v1] xen/arm: Manage pl011 uart TX interrupt
	correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-09 at 10:09 +0530, vijay.kilari@gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> 
> In pl011.c, when TX interrupt is received
> serial_tx_interrupt() is called to push next
> characters. If TX buffer is empty, serial_tx_interrupt()
> does not disable TX interrupt and hence pl011 UART
> irq handler pl011_interrupt() always sees TX interrupt
> status set in MIS register and cpu does not come out of
> UART irq handler.
> 
> With this patch, mask TX interrupt by writing 0 to
> IMSC register when TX buffer is empty and unmask by
> writing 1 to IMSC register before sending characters.
> 
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> ---
>  xen/drivers/char/pl011.c  |   16 ++++++++++++++++
>  xen/drivers/char/serial.c |   34 ++++++++++++++++++++++++++++++++++
>  xen/include/xen/serial.h  |    4 ++++

These last two changes require that you cc the common serial maintainer,
not just the ARM maintainers. In this case that means Keir, who I have
CCd.

./scripts/get_maintainers.pl can help automate this.

>  3 files changed, 54 insertions(+)
> 
> diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
> index dd19ce8..57274d9 100644
> --- a/xen/drivers/char/pl011.c
> +++ b/xen/drivers/char/pl011.c
> @@ -197,6 +197,20 @@ static const struct vuart_info *pl011_vuart(struct serial_port *port)
>      return &uart->vuart;
>  }
>  
> +static void pl011_tx_stop(struct serial_port *port)
> +{
> +    struct pl011 *uart = port->uart;
> +
> +    pl011_write(uart, IMSC, pl011_read(uart, IMSC) & ~(TXI));
> +}
> +
> +static void pl011_tx_start(struct serial_port *port)
> +{
> +    struct pl011 *uart = port->uart;
> +
> +    pl011_write(uart, IMSC, pl011_read(uart, IMSC) | (TXI));
> +}
> +
>  static struct uart_driver __read_mostly pl011_driver = {
>      .init_preirq  = pl011_init_preirq,
>      .init_postirq = pl011_init_postirq,
> @@ -207,6 +221,8 @@ static struct uart_driver __read_mostly pl011_driver = {
>      .putc         = pl011_putc,
>      .getc         = pl011_getc,
>      .irq          = pl011_irq,
> +    .start_tx     = pl011_tx_start,
> +    .stop_tx      = pl011_tx_stop,
>      .vuart_info   = pl011_vuart,
>  };
>  
> diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
> index 44026b1..c583a48 100644
> --- a/xen/drivers/char/serial.c
> +++ b/xen/drivers/char/serial.c
> @@ -31,6 +31,18 @@ static struct serial_port com[SERHND_IDX + 1] = {
>  
>  static bool_t __read_mostly post_irq;
>  
> +static inline void serial_start_tx(struct serial_port *port)
> +{
> +    if ( port->driver->start_tx != NULL )
> +        port->driver->start_tx(port);
> +}
> +
> +static inline void serial_stop_tx(struct serial_port *port)
> +{
> +    if ( port->driver->stop_tx != NULL )
> +        port->driver->stop_tx(port);
> +}
> +
>  void serial_rx_interrupt(struct serial_port *port, struct cpu_user_regs *regs)
>  {
>      char c;
> @@ -76,6 +88,18 @@ void serial_tx_interrupt(struct serial_port *port, struct cpu_user_regs *regs)
>          cpu_relax();
>      }
>  
> +    if ( port->txbufc == port->txbufp )
> +    {
> +        /* Disable TX. nothing to send */
> +        serial_stop_tx(port);
> +        spin_unlock(&port->tx_lock);
> +        goto out;
> +    }
> +    else
> +    {
> +        if ( port->driver->tx_ready(port) )
> +            serial_start_tx(port);
> +    }
>      for ( i = 0, n = port->driver->tx_ready(port); i < n; i++ )
>      {
>          if ( port->txbufc == port->txbufp )
> @@ -117,6 +141,8 @@ static void __serial_putc(struct serial_port *port, char c)
>                      cpu_relax();
>                  if ( n > 0 )
>                  {
> +                    /* Enable TX before sending chars */
> +                    serial_start_tx(port);
>                      while ( n-- )
>                          port->driver->putc(
>                              port,
> @@ -135,6 +161,8 @@ static void __serial_putc(struct serial_port *port, char c)
>          if ( ((port->txbufp - port->txbufc) == 0) &&
>               port->driver->tx_ready(port) > 0 )
>          {
> +            /* Enable TX before sending chars */
> +            serial_start_tx(port);
>              /* Buffer and UART FIFO are both empty, and port is available. */
>              port->driver->putc(port, c);
>          }
> @@ -152,11 +180,16 @@ static void __serial_putc(struct serial_port *port, char c)
>          while ( !(n = port->driver->tx_ready(port)) )
>              cpu_relax();
>          if ( n > 0 )
> +        {
> +            /* Enable TX before sending chars */
> +            serial_start_tx(port);
>              port->driver->putc(port, c);
> +        }
>      }
>      else
>      {
>          /* Simple synchronous transmitter. */
> +        serial_start_tx(port);
>          port->driver->putc(port, c);
>      }
>  }
> @@ -404,6 +437,7 @@ void serial_start_sync(int handle)
>                  /* port is unavailable and might not come up until reenabled by
>                     dom0, we can't really do proper sync */
>                  break;
> +            serial_start_tx(port);
>              port->driver->putc(
>                  port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);
>          }
> diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
> index 9f4451b..71e6ade 100644
> --- a/xen/include/xen/serial.h
> +++ b/xen/include/xen/serial.h
> @@ -81,6 +81,10 @@ struct uart_driver {
>      int  (*getc)(struct serial_port *, char *);
>      /* Get IRQ number for this port's serial line: returns -1 if none. */
>      int  (*irq)(struct serial_port *);
> +    /* Unmask TX interrupt */
> +    void  (*start_tx)(struct serial_port *);
> +    /* Mask TX interrupt */
> +    void  (*stop_tx)(struct serial_port *);
>      /* Get serial information */
>      const struct vuart_info *(*vuart_info)(struct serial_port *);
>  };



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:25:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:25:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2nO-00030k-Hu; Thu, 11 Dec 2014 12:24: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 1Xz2nN-00030f-K8
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:24:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	EA/A7-15461-50D89845; Thu, 11 Dec 2014 12:24:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418300675!14913166!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 24166 invoked from network); 11 Dec 2014 12:24:36 -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;
	11 Dec 2014 12:24:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203316241"
Message-ID: <1418300672.10394.35.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <vijay.kilari@gmail.com>
Date: Thu, 11 Dec 2014 12:24:32 +0000
In-Reply-To: <1418099995-22777-1-git-send-email-vijay.kilari@gmail.com>
References: <1418099995-22777-1-git-send-email-vijay.kilari@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Keir Fraser <keir@xen.org>, stefano.stabellini@eu.citrix.com,
	Prasun.Kapoor@caviumnetworks.com,
	manish.jaggi@caviumnetworks.com, julien.grall@linaro.org,
	tim@xen.org, xen-devel@lists.xen.org, stefano.stabellini@citrix.com,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Subject: Re: [Xen-devel] [PATCH v1] xen/arm: Manage pl011 uart TX interrupt
	correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-09 at 10:09 +0530, vijay.kilari@gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> 
> In pl011.c, when TX interrupt is received
> serial_tx_interrupt() is called to push next
> characters. If TX buffer is empty, serial_tx_interrupt()
> does not disable TX interrupt and hence pl011 UART
> irq handler pl011_interrupt() always sees TX interrupt
> status set in MIS register and cpu does not come out of
> UART irq handler.
> 
> With this patch, mask TX interrupt by writing 0 to
> IMSC register when TX buffer is empty and unmask by
> writing 1 to IMSC register before sending characters.
> 
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> ---
>  xen/drivers/char/pl011.c  |   16 ++++++++++++++++
>  xen/drivers/char/serial.c |   34 ++++++++++++++++++++++++++++++++++
>  xen/include/xen/serial.h  |    4 ++++

These last two changes require that you cc the common serial maintainer,
not just the ARM maintainers. In this case that means Keir, who I have
CCd.

./scripts/get_maintainers.pl can help automate this.

>  3 files changed, 54 insertions(+)
> 
> diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
> index dd19ce8..57274d9 100644
> --- a/xen/drivers/char/pl011.c
> +++ b/xen/drivers/char/pl011.c
> @@ -197,6 +197,20 @@ static const struct vuart_info *pl011_vuart(struct serial_port *port)
>      return &uart->vuart;
>  }
>  
> +static void pl011_tx_stop(struct serial_port *port)
> +{
> +    struct pl011 *uart = port->uart;
> +
> +    pl011_write(uart, IMSC, pl011_read(uart, IMSC) & ~(TXI));
> +}
> +
> +static void pl011_tx_start(struct serial_port *port)
> +{
> +    struct pl011 *uart = port->uart;
> +
> +    pl011_write(uart, IMSC, pl011_read(uart, IMSC) | (TXI));
> +}
> +
>  static struct uart_driver __read_mostly pl011_driver = {
>      .init_preirq  = pl011_init_preirq,
>      .init_postirq = pl011_init_postirq,
> @@ -207,6 +221,8 @@ static struct uart_driver __read_mostly pl011_driver = {
>      .putc         = pl011_putc,
>      .getc         = pl011_getc,
>      .irq          = pl011_irq,
> +    .start_tx     = pl011_tx_start,
> +    .stop_tx      = pl011_tx_stop,
>      .vuart_info   = pl011_vuart,
>  };
>  
> diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
> index 44026b1..c583a48 100644
> --- a/xen/drivers/char/serial.c
> +++ b/xen/drivers/char/serial.c
> @@ -31,6 +31,18 @@ static struct serial_port com[SERHND_IDX + 1] = {
>  
>  static bool_t __read_mostly post_irq;
>  
> +static inline void serial_start_tx(struct serial_port *port)
> +{
> +    if ( port->driver->start_tx != NULL )
> +        port->driver->start_tx(port);
> +}
> +
> +static inline void serial_stop_tx(struct serial_port *port)
> +{
> +    if ( port->driver->stop_tx != NULL )
> +        port->driver->stop_tx(port);
> +}
> +
>  void serial_rx_interrupt(struct serial_port *port, struct cpu_user_regs *regs)
>  {
>      char c;
> @@ -76,6 +88,18 @@ void serial_tx_interrupt(struct serial_port *port, struct cpu_user_regs *regs)
>          cpu_relax();
>      }
>  
> +    if ( port->txbufc == port->txbufp )
> +    {
> +        /* Disable TX. nothing to send */
> +        serial_stop_tx(port);
> +        spin_unlock(&port->tx_lock);
> +        goto out;
> +    }
> +    else
> +    {
> +        if ( port->driver->tx_ready(port) )
> +            serial_start_tx(port);
> +    }
>      for ( i = 0, n = port->driver->tx_ready(port); i < n; i++ )
>      {
>          if ( port->txbufc == port->txbufp )
> @@ -117,6 +141,8 @@ static void __serial_putc(struct serial_port *port, char c)
>                      cpu_relax();
>                  if ( n > 0 )
>                  {
> +                    /* Enable TX before sending chars */
> +                    serial_start_tx(port);
>                      while ( n-- )
>                          port->driver->putc(
>                              port,
> @@ -135,6 +161,8 @@ static void __serial_putc(struct serial_port *port, char c)
>          if ( ((port->txbufp - port->txbufc) == 0) &&
>               port->driver->tx_ready(port) > 0 )
>          {
> +            /* Enable TX before sending chars */
> +            serial_start_tx(port);
>              /* Buffer and UART FIFO are both empty, and port is available. */
>              port->driver->putc(port, c);
>          }
> @@ -152,11 +180,16 @@ static void __serial_putc(struct serial_port *port, char c)
>          while ( !(n = port->driver->tx_ready(port)) )
>              cpu_relax();
>          if ( n > 0 )
> +        {
> +            /* Enable TX before sending chars */
> +            serial_start_tx(port);
>              port->driver->putc(port, c);
> +        }
>      }
>      else
>      {
>          /* Simple synchronous transmitter. */
> +        serial_start_tx(port);
>          port->driver->putc(port, c);
>      }
>  }
> @@ -404,6 +437,7 @@ void serial_start_sync(int handle)
>                  /* port is unavailable and might not come up until reenabled by
>                     dom0, we can't really do proper sync */
>                  break;
> +            serial_start_tx(port);
>              port->driver->putc(
>                  port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);
>          }
> diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
> index 9f4451b..71e6ade 100644
> --- a/xen/include/xen/serial.h
> +++ b/xen/include/xen/serial.h
> @@ -81,6 +81,10 @@ struct uart_driver {
>      int  (*getc)(struct serial_port *, char *);
>      /* Get IRQ number for this port's serial line: returns -1 if none. */
>      int  (*irq)(struct serial_port *);
> +    /* Unmask TX interrupt */
> +    void  (*start_tx)(struct serial_port *);
> +    /* Mask TX interrupt */
> +    void  (*stop_tx)(struct serial_port *);
>      /* Get serial information */
>      const struct vuart_info *(*vuart_info)(struct serial_port *);
>  };



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:30:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:30:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2sp-0003C5-AJ; Thu, 11 Dec 2014 12:30:15 +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 1Xz2so-0003C0-8i
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:30:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	08/3D-25276-55E89845; Thu, 11 Dec 2014 12:30:13 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418301012!14953990!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25183 invoked from network); 11 Dec 2014 12:30:13 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 12:30:13 -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 sBBCU2Ru007205;
	Thu, 11 Dec 2014 12:30:06 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 sBBCTubZ010508
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Dec 2014 12:29:56 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 sBBCTubp027753;
	Thu, 11 Dec 2014 12:29:56 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sBBCTuMj027749; Thu, 11 Dec 2014 12:29:56 GMT
Date: Thu, 11 Dec 2014 12:29:56 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141211120544.GB25950@aepfle.de>
Message-ID: <alpine.DEB.2.00.1412111226040.28709@procyon.dur.ac.uk>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
	<alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
	<20141211120424.GA25950@aepfle.de>
	<20141211120544.GB25950@aepfle.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sBBCU2Ru007205
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Thu, 11 Dec 2014, Olaf Hering wrote:

> On Thu, Dec 11, Olaf Hering wrote:
>
>> This sounds like xenstored has to parse the possible environment
>> variables found in sysconfig.xencommons all by itself? Is there perhaps
>> a way out of the SELinux jail?
>
> Does all that work with the sysv runlevel scripts?

I assume so, but Fedora hasn't used the upstream sysv scripts for a long 
time (from before I started maintaining it) so I don't know for sure.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:30:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:30:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2sp-0003C5-AJ; Thu, 11 Dec 2014 12:30:15 +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 1Xz2so-0003C0-8i
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:30:14 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	08/3D-25276-55E89845; Thu, 11 Dec 2014 12:30:13 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418301012!14953990!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25183 invoked from network); 11 Dec 2014 12:30:13 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 12:30:13 -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 sBBCU2Ru007205;
	Thu, 11 Dec 2014 12:30:06 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 sBBCTubZ010508
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Dec 2014 12:29:56 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 sBBCTubp027753;
	Thu, 11 Dec 2014 12:29:56 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sBBCTuMj027749; Thu, 11 Dec 2014 12:29:56 GMT
Date: Thu, 11 Dec 2014 12:29:56 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20141211120544.GB25950@aepfle.de>
Message-ID: <alpine.DEB.2.00.1412111226040.28709@procyon.dur.ac.uk>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
	<alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
	<20141211120424.GA25950@aepfle.de>
	<20141211120544.GB25950@aepfle.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: sBBCU2Ru007205
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Thu, 11 Dec 2014, Olaf Hering wrote:

> On Thu, Dec 11, Olaf Hering wrote:
>
>> This sounds like xenstored has to parse the possible environment
>> variables found in sysconfig.xencommons all by itself? Is there perhaps
>> a way out of the SELinux jail?
>
> Does all that work with the sysv runlevel scripts?

I assume so, but Fedora hasn't used the upstream sysv scripts for a long 
time (from before I started maintaining it) so I don't know for sure.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:33:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2vY-0003bh-7o; Thu, 11 Dec 2014 12:33:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xz2vX-0003bb-BD
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:33:03 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	BA/F2-26858-EFE89845; Thu, 11 Dec 2014 12:33:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418301180!12484001!1
X-Originating-IP: [66.165.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 7848 invoked from network); 11 Dec 2014 12:33:02 -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 Dec 2014 12:33:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203318793"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 07:32: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 1Xz2vS-00023i-IB;
	Thu, 11 Dec 2014 12:32:58 +0000
Date: Thu, 11 Dec 2014 12:32:58 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141211123258.GJ21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181152.26400.21301.stgit@Abyss.station>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141210181152.26400.21301.stgit@Abyss.station>
User-Agent: Mutt/1.5.23 (2014-03-12)
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
Subject: Re: [Xen-devel] [PATCH 22/27] ts-bench-hostcmp-host-prep: new script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 07:11:52PM +0100, Dario Faggioli wrote:
[...]
> +
> +  logm("Will run the benchmark on host with: $bcpus vcpus and $bmem MB RAM");
> +
> +  my $kernver= get_runvar('kernel_ver',$r{'kernbuildjob'});
> +  my $kopt= "maxcpus=$bcpus mem=$bmem" . "M";
> +
> +  if ($ho->{Flags}{'need-uboot-bootscr'}) {
> +      $bl= setupboot_uboot($ho,$kernver,undef,$kopt);
> +  } elsif ($ho->{Suite} =~ m/lenny/) {
> +      $bl= setupboot_grub1($ho,$kernver,undef,$kopt);
> +  } else {
> +      $bl= setupboot_grub2($ho,$kernver,undef,$kopt);
> +  }
> +
> +  $bootkern= $bl->{PreFinalUpdate}();
> +  $bl->{UpdateConfig}($ho);
> +
> +  $bootkern= $bl->{GetBootKern}();
> +  logm("$ho->{Name} will reboot on kernel $bootkern with '$kopt' as options");

Can you refactor debian_setup_boot to achieve your goal?

> +}
> +
> +fixup();
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 11 12:33:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz2vY-0003bh-7o; Thu, 11 Dec 2014 12:33:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xz2vX-0003bb-BD
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:33:03 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	BA/F2-26858-EFE89845; Thu, 11 Dec 2014 12:33:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418301180!12484001!1
X-Originating-IP: [66.165.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 7848 invoked from network); 11 Dec 2014 12:33:02 -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 Dec 2014 12:33:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203318793"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 07:32: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 1Xz2vS-00023i-IB;
	Thu, 11 Dec 2014 12:32:58 +0000
Date: Thu, 11 Dec 2014 12:32:58 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141211123258.GJ21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181152.26400.21301.stgit@Abyss.station>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141210181152.26400.21301.stgit@Abyss.station>
User-Agent: Mutt/1.5.23 (2014-03-12)
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
Subject: Re: [Xen-devel] [PATCH 22/27] ts-bench-hostcmp-host-prep: new script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 07:11:52PM +0100, Dario Faggioli wrote:
[...]
> +
> +  logm("Will run the benchmark on host with: $bcpus vcpus and $bmem MB RAM");
> +
> +  my $kernver= get_runvar('kernel_ver',$r{'kernbuildjob'});
> +  my $kopt= "maxcpus=$bcpus mem=$bmem" . "M";
> +
> +  if ($ho->{Flags}{'need-uboot-bootscr'}) {
> +      $bl= setupboot_uboot($ho,$kernver,undef,$kopt);
> +  } elsif ($ho->{Suite} =~ m/lenny/) {
> +      $bl= setupboot_grub1($ho,$kernver,undef,$kopt);
> +  } else {
> +      $bl= setupboot_grub2($ho,$kernver,undef,$kopt);
> +  }
> +
> +  $bootkern= $bl->{PreFinalUpdate}();
> +  $bl->{UpdateConfig}($ho);
> +
> +  $bootkern= $bl->{GetBootKern}();
> +  logm("$ho->{Name} will reboot on kernel $bootkern with '$kopt' as options");

Can you refactor debian_setup_boot to achieve your goal?

> +}
> +
> +fixup();
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 11 12:45:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:45:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz370-00045Y-G9; Thu, 11 Dec 2014 12:44:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xz36z-00045T-ER
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 12:44:53 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	C3/25-22819-4C199845; Thu, 11 Dec 2014 12:44:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418301891!12850287!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 17712 invoked from network); 11 Dec 2014 12:44:52 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 12:44:52 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz36i-000H62-3e; Thu, 11 Dec 2014 12:44:36 +0000
Date: Thu, 11 Dec 2014 13:44:36 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141211124436.GC53811@deinos.phlegethon.org>
References: <5481A589020000780004D1E3@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481A589020000780004D1E3@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: Keir Fraser <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:31 +0000 on 05 Dec (1417775465), Jan Beulich wrote:
> Andrew validly points out that even if these masks aren't a formal part
> of the hypercall interface, we aren't free to change them: A guest
> suspended for migration in the middle of a continuation would fail to
> work if resumed on a hypervisor using a different value. Hence add
> respective comments to their definitions.
> 
> Additionally, to help future extensibility as well as in the spirit of
> reducing undefined behavior as much as possible, refuse hypercalls made
> with the respective bits non-zero when the respective sub-ops don't
> make use of those bits.
> 
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:45:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:45:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz370-00045Y-G9; Thu, 11 Dec 2014 12:44:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xz36z-00045T-ER
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 12:44:53 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	C3/25-22819-4C199845; Thu, 11 Dec 2014 12:44:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418301891!12850287!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 17712 invoked from network); 11 Dec 2014 12:44:52 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 12:44:52 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz36i-000H62-3e; Thu, 11 Dec 2014 12:44:36 +0000
Date: Thu, 11 Dec 2014 13:44:36 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141211124436.GC53811@deinos.phlegethon.org>
References: <5481A589020000780004D1E3@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5481A589020000780004D1E3@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: Keir Fraser <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] lock down hypercall continuation encoding
	masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:31 +0000 on 05 Dec (1417775465), Jan Beulich wrote:
> Andrew validly points out that even if these masks aren't a formal part
> of the hypercall interface, we aren't free to change them: A guest
> suspended for migration in the middle of a continuation would fail to
> work if resumed on a hypervisor using a different value. Hence add
> respective comments to their definitions.
> 
> Additionally, to help future extensibility as well as in the spirit of
> reducing undefined behavior as much as possible, refuse hypercalls made
> with the respective bits non-zero when the respective sub-ops don't
> make use of those bits.
> 
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 12:58:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:58:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3Jo-0004XW-Q7; Thu, 11 Dec 2014 12:58:08 +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 1Xz3Jm-0004XO-WF
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:58:07 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	46/8B-09842-ED499845; Thu, 11 Dec 2014 12:58:06 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418302682!14946907!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) c3VyYmxfcmVjaGVja19kZWxheTogMjAyMDAzMiAo
	YWJhbmRvbmVkOiBhYm91dC5tZS9kYXJpby5m\nYWdnaW9saSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31957 invoked from network); 11 Dec 2014 12:58:03 -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;
	11 Dec 2014 12:58:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; 
	d="asc'?scan'208";a="203326885"
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.210.2;
	Thu, 11 Dec 2014 07:58:01 -0500
Message-ID: <1418302679.31647.85.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 11 Dec 2014 13:57:59 +0100
In-Reply-To: <20141211120553.GG21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210180918.26400.69599.stgit@Abyss.station>
	<20141211120553.GG21659@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 Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 03/27] Guest setup: allow the amount of RAM
 to be a runvar
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4866485337314963961=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4866485337314963961==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-iYrXjAvKc+zTbz1TQIBU"

--=-iYrXjAvKc+zTbz1TQIBU
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-12-11 at 12:05 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 07:09:18PM +0100, Dario Faggioli wrote:
> > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > index a3b6936..cdff8d5 100644
> > --- a/Osstest/TestSupport.pm
> > +++ b/Osstest/TestSupport.pm
> > @@ -1460,11 +1460,12 @@ sub prepareguest_part_xencfg ($$$$$) {
> >      my ($ho, $gho, $ram_mb, $xopts, $cfgrest) =3D @_;
> >      my $onreboot=3D $xopts->{OnReboot} || 'restart';
> >      my $vcpus=3D guest_var($gho, 'vcpus', $xopts->{DefVcpus} || 2);
> > +    my $memory=3D guest_var($gho, 'memory', $xopts->{DefMem} || $ram_m=
b);
> >      my $xoptcfg=3D $xopts->{ExtraConfig};
> >      $xoptcfg=3D'' unless defined $xoptcfg;
> >      my $xencfg=3D <<END;
> >  name        =3D '$gho->{Name}'
> > -memory =3D ${ram_mb}
> > +memory =3D ${memory}
>=20
> You made ram_mb redundant.
>
Did I? My idea was to use it as default, if the runvar is not defined...
That is what I though this line does (and I'm quite sure I tested it
actually does that):

my $memory=3D guest_var($gho, 'memory', $xopts->{DefMem} || $ram_mb);

But, perhaps, I'm not getting what you mean by "redundant"...

>  And this seems to be deep in the call chain
> which has subtle knock on effect.
>=20
Sorry, I don't get what you mean here.

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)


--=-iYrXjAvKc+zTbz1TQIBU
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

iEYEABECAAYFAlSJlNcACgkQk4XaBE3IOsRHYwCfeHe/fvhpaXWALlFD/LHvfcgD
xvgAn2zNe/19EM13aW0fYGXhsKcxT83G
=wAnm
-----END PGP SIGNATURE-----

--=-iYrXjAvKc+zTbz1TQIBU--


--===============4866485337314963961==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4866485337314963961==--


From xen-devel-bounces@lists.xen.org Thu Dec 11 12:58:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 12:58:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3Jo-0004XW-Q7; Thu, 11 Dec 2014 12:58:08 +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 1Xz3Jm-0004XO-WF
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 12:58:07 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	46/8B-09842-ED499845; Thu, 11 Dec 2014 12:58:06 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418302682!14946907!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) c3VyYmxfcmVjaGVja19kZWxheTogMjAyMDAzMiAo
	YWJhbmRvbmVkOiBhYm91dC5tZS9kYXJpby5m\nYWdnaW9saSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31957 invoked from network); 11 Dec 2014 12:58:03 -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;
	11 Dec 2014 12:58:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; 
	d="asc'?scan'208";a="203326885"
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.210.2;
	Thu, 11 Dec 2014 07:58:01 -0500
Message-ID: <1418302679.31647.85.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 11 Dec 2014 13:57:59 +0100
In-Reply-To: <20141211120553.GG21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210180918.26400.69599.stgit@Abyss.station>
	<20141211120553.GG21659@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 Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 03/27] Guest setup: allow the amount of RAM
 to be a runvar
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4866485337314963961=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4866485337314963961==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-iYrXjAvKc+zTbz1TQIBU"

--=-iYrXjAvKc+zTbz1TQIBU
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-12-11 at 12:05 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 07:09:18PM +0100, Dario Faggioli wrote:
> > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > index a3b6936..cdff8d5 100644
> > --- a/Osstest/TestSupport.pm
> > +++ b/Osstest/TestSupport.pm
> > @@ -1460,11 +1460,12 @@ sub prepareguest_part_xencfg ($$$$$) {
> >      my ($ho, $gho, $ram_mb, $xopts, $cfgrest) =3D @_;
> >      my $onreboot=3D $xopts->{OnReboot} || 'restart';
> >      my $vcpus=3D guest_var($gho, 'vcpus', $xopts->{DefVcpus} || 2);
> > +    my $memory=3D guest_var($gho, 'memory', $xopts->{DefMem} || $ram_m=
b);
> >      my $xoptcfg=3D $xopts->{ExtraConfig};
> >      $xoptcfg=3D'' unless defined $xoptcfg;
> >      my $xencfg=3D <<END;
> >  name        =3D '$gho->{Name}'
> > -memory =3D ${ram_mb}
> > +memory =3D ${memory}
>=20
> You made ram_mb redundant.
>
Did I? My idea was to use it as default, if the runvar is not defined...
That is what I though this line does (and I'm quite sure I tested it
actually does that):

my $memory=3D guest_var($gho, 'memory', $xopts->{DefMem} || $ram_mb);

But, perhaps, I'm not getting what you mean by "redundant"...

>  And this seems to be deep in the call chain
> which has subtle knock on effect.
>=20
Sorry, I don't get what you mean here.

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)


--=-iYrXjAvKc+zTbz1TQIBU
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

iEYEABECAAYFAlSJlNcACgkQk4XaBE3IOsRHYwCfeHe/fvhpaXWALlFD/LHvfcgD
xvgAn2zNe/19EM13aW0fYGXhsKcxT83G
=wAnm
-----END PGP SIGNATURE-----

--=-iYrXjAvKc+zTbz1TQIBU--


--===============4866485337314963961==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4866485337314963961==--


From xen-devel-bounces@lists.xen.org Thu Dec 11 13:00:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:00:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3Le-0004eN-9x; Thu, 11 Dec 2014 13:00:02 +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 1Xz3Ld-0004cQ-EY
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:00:01 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	A1/5D-27785-05599845; Thu, 11 Dec 2014 13:00:00 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418302794!14415234!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8146 invoked from network); 11 Dec 2014 12:59:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 12:59:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; 
	d="asc'?scan'208";a="202924985"
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.210.2;
	Thu, 11 Dec 2014 07:59:54 -0500
Message-ID: <1418302792.31647.87.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 11 Dec 2014 13:59:52 +0100
In-Reply-To: <20141211120934.GH21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210180957.26400.66565.stgit@Abyss.station>
	<20141211120934.GH21659@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: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 08/27] ts-unixbench-reslts: for retrieving
 the results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3214854860582128501=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3214854860582128501==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-/f371QqpQOdh4prJrDq2"

--=-/f371QqpQOdh4prJrDq2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-12-11 at 12:09 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 07:09:57PM +0100, Dario Faggioli wrote:
> > ---
> >  ts-unixbench-reslts |   67 +++++++++++++++++++++++++++++++++++++++++++=
++++++++
>=20
> Typo "reslts" (also in subject line).
>=20
Yes, it's like that everywhere. In fact, it was kind of intentional, but
I guess I can spell 'results' properly and call these files
'ts-foobench-results'.

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)


--=-/f371QqpQOdh4prJrDq2
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

iEYEABECAAYFAlSJlUgACgkQk4XaBE3IOsT1RwCffyBrgWlxmd1zY9mZ5uPIp55T
39IAnA8K9Y7KXVjSz/z7u+Zx0BxwTmCc
=DGG1
-----END PGP SIGNATURE-----

--=-/f371QqpQOdh4prJrDq2--


--===============3214854860582128501==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3214854860582128501==--


From xen-devel-bounces@lists.xen.org Thu Dec 11 13:00:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:00:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3Le-0004eN-9x; Thu, 11 Dec 2014 13:00:02 +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 1Xz3Ld-0004cQ-EY
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:00:01 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	A1/5D-27785-05599845; Thu, 11 Dec 2014 13:00:00 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418302794!14415234!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8146 invoked from network); 11 Dec 2014 12:59:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 12:59:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; 
	d="asc'?scan'208";a="202924985"
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.210.2;
	Thu, 11 Dec 2014 07:59:54 -0500
Message-ID: <1418302792.31647.87.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 11 Dec 2014 13:59:52 +0100
In-Reply-To: <20141211120934.GH21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210180957.26400.66565.stgit@Abyss.station>
	<20141211120934.GH21659@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: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 08/27] ts-unixbench-reslts: for retrieving
 the results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3214854860582128501=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3214854860582128501==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-/f371QqpQOdh4prJrDq2"

--=-/f371QqpQOdh4prJrDq2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-12-11 at 12:09 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 07:09:57PM +0100, Dario Faggioli wrote:
> > ---
> >  ts-unixbench-reslts |   67 +++++++++++++++++++++++++++++++++++++++++++=
++++++++
>=20
> Typo "reslts" (also in subject line).
>=20
Yes, it's like that everywhere. In fact, it was kind of intentional, but
I guess I can spell 'results' properly and call these files
'ts-foobench-results'.

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)


--=-/f371QqpQOdh4prJrDq2
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

iEYEABECAAYFAlSJlUgACgkQk4XaBE3IOsT1RwCffyBrgWlxmd1zY9mZ5uPIp55T
39IAnA8K9Y7KXVjSz/z7u+Zx0BxwTmCc
=DGG1
-----END PGP SIGNATURE-----

--=-/f371QqpQOdh4prJrDq2--


--===============3214854860582128501==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3214854860582128501==--


From xen-devel-bounces@lists.xen.org Thu Dec 11 13:00:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13: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 1Xz3MK-0004jh-Tf; Thu, 11 Dec 2014 13:00:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xz3MJ-0004jR-0i
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:00:43 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	A9/A5-03145-A7599845; Thu, 11 Dec 2014 13:00:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418302841!9011373!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 8875 invoked from network); 11 Dec 2014 13:00:41 -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; 11 Dec 2014 13:00:41 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz3M2-000HM1-Vv; Thu, 11 Dec 2014 13:00:26 +0000
Date: Thu, 11 Dec 2014 14:00:26 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141211130026.GA53825@deinos.phlegethon.org>
References: <54898449020000780004EDDD@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54898449020000780004EDDD@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: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: don't deliver NMI to PVH Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:47 +0000 on 11 Dec (1418291241), Jan Beulich wrote:
> ... for the time being: The mechanism used depends on the domain's use
> of the IRET hypercall.

Can you elaborate?  Looking at the existing code it seems like what it
does is set v->nmi_pending and make sure the vcpu gets scheduled
appropriately.

The HVM code will deliver an NMI if it sees v->nmi_pending (which is
what vlapic_accept_irq does, for example).  Is there some other piece
I'm missing?

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 Dec 11 13:00:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13: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 1Xz3MK-0004jh-Tf; Thu, 11 Dec 2014 13:00:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xz3MJ-0004jR-0i
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:00:43 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	A9/A5-03145-A7599845; Thu, 11 Dec 2014 13:00:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418302841!9011373!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 8875 invoked from network); 11 Dec 2014 13:00:41 -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; 11 Dec 2014 13:00:41 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz3M2-000HM1-Vv; Thu, 11 Dec 2014 13:00:26 +0000
Date: Thu, 11 Dec 2014 14:00:26 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141211130026.GA53825@deinos.phlegethon.org>
References: <54898449020000780004EDDD@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54898449020000780004EDDD@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: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: don't deliver NMI to PVH Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:47 +0000 on 11 Dec (1418291241), Jan Beulich wrote:
> ... for the time being: The mechanism used depends on the domain's use
> of the IRET hypercall.

Can you elaborate?  Looking at the existing code it seems like what it
does is set v->nmi_pending and make sure the vcpu gets scheduled
appropriately.

The HVM code will deliver an NMI if it sees v->nmi_pending (which is
what vlapic_accept_irq does, for example).  Is there some other piece
I'm missing?

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 Dec 11 13:07:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13: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 1Xz3SB-0005If-NV; Thu, 11 Dec 2014 13:06:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xz3S9-0005Ia-Qv
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:06:45 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	A7/D9-02953-5E699845; Thu, 11 Dec 2014 13:06:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418303203!14417442!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13202 invoked from network); 11 Dec 2014 13:06: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;
	11 Dec 2014 13:06:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202927993"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 08:06: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 1Xz3S3-0002ow-Nc;
	Thu, 11 Dec 2014 13:06:39 +0000
Date: Thu, 11 Dec 2014 13:06:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141211130639.GK21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210180918.26400.69599.stgit@Abyss.station>
	<20141211120553.GG21659@zion.uk.xensource.com>
	<1418302679.31647.85.camel@Abyss.station>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418302679.31647.85.camel@Abyss.station>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
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
Subject: Re: [Xen-devel] [PATCH 03/27] Guest setup: allow the amount of RAM
 to be a runvar
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 01:57:59PM +0100, Dario Faggioli wrote:
> On Thu, 2014-12-11 at 12:05 +0000, Wei Liu wrote:
> > On Wed, Dec 10, 2014 at 07:09:18PM +0100, Dario Faggioli wrote:
> > > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > > index a3b6936..cdff8d5 100644
> > > --- a/Osstest/TestSupport.pm
> > > +++ b/Osstest/TestSupport.pm
> > > @@ -1460,11 +1460,12 @@ sub prepareguest_part_xencfg ($$$$$) {
> > >      my ($ho, $gho, $ram_mb, $xopts, $cfgrest) = @_;
> > >      my $onreboot= $xopts->{OnReboot} || 'restart';
> > >      my $vcpus= guest_var($gho, 'vcpus', $xopts->{DefVcpus} || 2);
> > > +    my $memory= guest_var($gho, 'memory', $xopts->{DefMem} || $ram_mb);
> > >      my $xoptcfg= $xopts->{ExtraConfig};
> > >      $xoptcfg='' unless defined $xoptcfg;
> > >      my $xencfg= <<END;
> > >  name        = '$gho->{Name}'
> > > -memory = ${ram_mb}
> > > +memory = ${memory}
> > 
> > You made ram_mb redundant.
> >
> Did I? My idea was to use it as default, if the runvar is not defined...
> That is what I though this line does (and I'm quite sure I tested it
> actually does that):
> 
> my $memory= guest_var($gho, 'memory', $xopts->{DefMem} || $ram_mb);
> 
> But, perhaps, I'm not getting what you mean by "redundant"...

Sorry, I missed the "|| $ram_mb".

In any case, having two way of specifying guest memory and one might
shadow the other is a bit subtle to me. One might be affected by a
guest runvar stored in other places and confusingly find out $ram_mb
doesn't work in his / her own script...

> 
> >  And this seems to be deep in the call chain
> > which has subtle knock on effect.
> > 
> Sorry, I don't get what you mean here.
> 

prepareguest_part_xencfg is not exported to guest and user might not
have a good idea why $ram_mb he / she specifies doesn't work.

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 Thu Dec 11 13:07:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13: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 1Xz3SB-0005If-NV; Thu, 11 Dec 2014 13:06:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xz3S9-0005Ia-Qv
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:06:45 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	A7/D9-02953-5E699845; Thu, 11 Dec 2014 13:06:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418303203!14417442!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13202 invoked from network); 11 Dec 2014 13:06: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;
	11 Dec 2014 13:06:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="202927993"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 08:06: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 1Xz3S3-0002ow-Nc;
	Thu, 11 Dec 2014 13:06:39 +0000
Date: Thu, 11 Dec 2014 13:06:39 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141211130639.GK21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210180918.26400.69599.stgit@Abyss.station>
	<20141211120553.GG21659@zion.uk.xensource.com>
	<1418302679.31647.85.camel@Abyss.station>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418302679.31647.85.camel@Abyss.station>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
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
Subject: Re: [Xen-devel] [PATCH 03/27] Guest setup: allow the amount of RAM
 to be a runvar
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 01:57:59PM +0100, Dario Faggioli wrote:
> On Thu, 2014-12-11 at 12:05 +0000, Wei Liu wrote:
> > On Wed, Dec 10, 2014 at 07:09:18PM +0100, Dario Faggioli wrote:
> > > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > > index a3b6936..cdff8d5 100644
> > > --- a/Osstest/TestSupport.pm
> > > +++ b/Osstest/TestSupport.pm
> > > @@ -1460,11 +1460,12 @@ sub prepareguest_part_xencfg ($$$$$) {
> > >      my ($ho, $gho, $ram_mb, $xopts, $cfgrest) = @_;
> > >      my $onreboot= $xopts->{OnReboot} || 'restart';
> > >      my $vcpus= guest_var($gho, 'vcpus', $xopts->{DefVcpus} || 2);
> > > +    my $memory= guest_var($gho, 'memory', $xopts->{DefMem} || $ram_mb);
> > >      my $xoptcfg= $xopts->{ExtraConfig};
> > >      $xoptcfg='' unless defined $xoptcfg;
> > >      my $xencfg= <<END;
> > >  name        = '$gho->{Name}'
> > > -memory = ${ram_mb}
> > > +memory = ${memory}
> > 
> > You made ram_mb redundant.
> >
> Did I? My idea was to use it as default, if the runvar is not defined...
> That is what I though this line does (and I'm quite sure I tested it
> actually does that):
> 
> my $memory= guest_var($gho, 'memory', $xopts->{DefMem} || $ram_mb);
> 
> But, perhaps, I'm not getting what you mean by "redundant"...

Sorry, I missed the "|| $ram_mb".

In any case, having two way of specifying guest memory and one might
shadow the other is a bit subtle to me. One might be affected by a
guest runvar stored in other places and confusingly find out $ram_mb
doesn't work in his / her own script...

> 
> >  And this seems to be deep in the call chain
> > which has subtle knock on effect.
> > 
> Sorry, I don't get what you mean here.
> 

prepareguest_part_xencfg is not exported to guest and user might not
have a good idea why $ram_mb he / she specifies doesn't work.

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 Thu Dec 11 13:09:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 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 1Xz3UW-0005Op-8d; Thu, 11 Dec 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 <JBeulich@suse.com>) id 1Xz3UU-0005Ok-Rl
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:09:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4E/03-09842-57799845; Thu, 11 Dec 2014 13:09:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418303349!14950931!1
X-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 21374 invoked from network); 11 Dec 2014 13:09:09 -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; 11 Dec 2014 13:09:09 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 13:09:08 +0000
Message-Id: <5489A584020000780004EF49@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 13:09:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <54898449020000780004EDDD@mail.emea.novell.com>
	<20141211130026.GA53825@deinos.phlegethon.org>
In-Reply-To: <20141211130026.GA53825@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] x86: don't deliver NMI to PVH 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 11.12.14 at 14:00, <tim@xen.org> wrote:
> At 10:47 +0000 on 11 Dec (1418291241), Jan Beulich wrote:
>> ... for the time being: The mechanism used depends on the domain's use
>> of the IRET hypercall.
> 
> Can you elaborate?  Looking at the existing code it seems like what it
> does is set v->nmi_pending and make sure the vcpu gets scheduled
> appropriately.
> 
> The HVM code will deliver an NMI if it sees v->nmi_pending (which is
> what vlapic_accept_irq does, for example).  Is there some other piece
> I'm missing?

Just so that others see the answer too: The problem is that the
temporary affinity adjustment gets undone in the HYPERVISOR_iret
handler, yet PVH can't call that hypercall.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 13:09:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 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 1Xz3UW-0005Op-8d; Thu, 11 Dec 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 <JBeulich@suse.com>) id 1Xz3UU-0005Ok-Rl
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:09:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4E/03-09842-57799845; Thu, 11 Dec 2014 13:09:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418303349!14950931!1
X-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 21374 invoked from network); 11 Dec 2014 13:09:09 -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; 11 Dec 2014 13:09:09 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 13:09:08 +0000
Message-Id: <5489A584020000780004EF49@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 13:09:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <54898449020000780004EDDD@mail.emea.novell.com>
	<20141211130026.GA53825@deinos.phlegethon.org>
In-Reply-To: <20141211130026.GA53825@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] x86: don't deliver NMI to PVH 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 11.12.14 at 14:00, <tim@xen.org> wrote:
> At 10:47 +0000 on 11 Dec (1418291241), Jan Beulich wrote:
>> ... for the time being: The mechanism used depends on the domain's use
>> of the IRET hypercall.
> 
> Can you elaborate?  Looking at the existing code it seems like what it
> does is set v->nmi_pending and make sure the vcpu gets scheduled
> appropriately.
> 
> The HVM code will deliver an NMI if it sees v->nmi_pending (which is
> what vlapic_accept_irq does, for example).  Is there some other piece
> I'm missing?

Just so that others see the answer too: The problem is that the
temporary affinity adjustment gets undone in the HYPERVISOR_iret
handler, yet PVH can't call that hypercall.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 13:10:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13: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 1Xz3VT-0005U5-Ml; Thu, 11 Dec 2014 13:10:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xz3VS-0005Ts-HL
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:10:10 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	3F/C7-02699-1B799845; Thu, 11 Dec 2014 13:10:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418303408!14465790!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 21626 invoked from network); 11 Dec 2014 13:10:09 -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; 11 Dec 2014 13:10:09 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz3V4-000HXP-Vx; Thu, 11 Dec 2014 13:09:46 +0000
Date: Thu, 11 Dec 2014 14:09:46 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141211130946.GD53811@deinos.phlegethon.org>
References: <1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
	<20141210111213.GB64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261167AC@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1261167AC@SHSMSX101.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@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 02:03 +0000 on 11 Dec (1418259797), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:tim@xen.org]
> > Now since the code's not going to be in 4.5 anyway, it should be
> > possible to _develop_ it in this manner, possibly in a private branch,
> > even if the early stages aren't getting applied immediately.  We
> > should be able to set up an rmrr branch on the public servers if that
> > helps.  But again, that relies on having a design worked out in
> > advance that both developers and maintainers are (within reason)
> > committed to.
> 
> that's a good suggestion. We'll send out a design review today, and then
> based on discussion we can see whether making sense to do such 
> incremental way.

Sounds good!

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 Dec 11 13:10:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13: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 1Xz3VT-0005U5-Ml; Thu, 11 Dec 2014 13:10:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xz3VS-0005Ts-HL
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:10:10 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	3F/C7-02699-1B799845; Thu, 11 Dec 2014 13:10:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418303408!14465790!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 21626 invoked from network); 11 Dec 2014 13:10:09 -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; 11 Dec 2014 13:10:09 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz3V4-000HXP-Vx; Thu, 11 Dec 2014 13:09:46 +0000
Date: Thu, 11 Dec 2014 14:09:46 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141211130946.GD53811@deinos.phlegethon.org>
References: <1417425875-9634-5-git-send-email-tiejun.chen@intel.com>
	<548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
	<20141210111213.GB64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261167AC@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1261167AC@SHSMSX101.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@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 02:03 +0000 on 11 Dec (1418259797), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:tim@xen.org]
> > Now since the code's not going to be in 4.5 anyway, it should be
> > possible to _develop_ it in this manner, possibly in a private branch,
> > even if the early stages aren't getting applied immediately.  We
> > should be able to set up an rmrr branch on the public servers if that
> > helps.  But again, that relies on having a design worked out in
> > advance that both developers and maintainers are (within reason)
> > committed to.
> 
> that's a good suggestion. We'll send out a design review today, and then
> based on discussion we can see whether making sense to do such 
> incremental way.

Sounds good!

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 Dec 11 13:11:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3X6-0005fN-8H; Thu, 11 Dec 2014 13:11:52 +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 1Xz3X4-0005eZ-5w
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:11:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	37/F8-09842-51899845; Thu, 11 Dec 2014 13:11:49 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418303506!14970938!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5659 invoked from network); 11 Dec 2014 13:11:47 -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;
	11 Dec 2014 13:11:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; 
	d="asc'?scan'208";a="202930224"
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.210.2;
	Thu, 11 Dec 2014 08:11:45 -0500
Message-ID: <1418303504.31647.98.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 11 Dec 2014 14:11:44 +0100
In-Reply-To: <20141211121554.GI21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181006.26400.25863.stgit@Abyss.station>
	<20141211121554.GI21659@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: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/27] ts-unixbench-reslts: process and plot
 bench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7963812080128913436=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7963812080128913436==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-3aJ4Q1Khld+MiGoxl9KG"

--=-3aJ4Q1Khld+MiGoxl9KG
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-12-11 at 12:15 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 07:10:06PM +0100, Dario Faggioli wrote:

> > This is done in a new Osstest/Benchmarking.pm module, as
> > the functions introduced may turn out useful somewhere else
> > too.
> >=20
>=20
> I would suggest using a dedicated commit for the introduction of
> Benchmarking.pm.
>=20
I'm not sure. I like it being introduced here where it's useful, since
that does not, IMO, make the patch too long or to difficult to
understand/review/etc.

However, this is not a too big deal... let's see what others think, and
I'll copy. :-)

> > --- /dev/null
> > +++ b/Osstest/Benchmarking.pm
> > @@ -0,0 +1,115 @@
> > +# This is part of "osstest", an automated testing framework for Xen.
> > +# Copyright (C) 2009-2013 Citrix Inc.
>=20
> 2009-2014
>=20
Right! :-)

> > +sub unixbench_plot_results ($$$) {
> > +  my ($dataf,$num_cols,$pfile)=3D @_;
> > +  my $h=3D new IO::File "> $pfile.gp" or die "$!";
> > +
> > +  printf $h <<EOF;
> > +set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/D=
ejaVuSans.ttf" 8 size 800,600
> > +set output '$pfile.png'
> > +set title 'Unixbench INDEXes for $flight.$job'
> > +set key outside center top horizontal noreverse noenhanced autotitles =
nobox
> > +set xtics mirror rotate by -45 out
> > +set style data histogram
> > +set style histogram cluster gap 1
> > +set style fill solid border lt -1
> > +set boxwidth 1 absolute
> > +set bmargin 13
> > +set rmargin 14
> > +SKIP_COL=3D1
> > +NCOL=3D$num_cols
> > +HWIDTH=3D1.0/(NCOL+1.0)
> > +plot for [c=3DSKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with =
histograms title columnhead, \\
> > +        for [c=3DSKIP_COL+1:SKIP_COL+NCOL]'' every ::1 using 0:c:c wit=
h labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1)=
)*HWIDTH, character 2 rotate by 90
> > +EOF
> > +  close($h);
> > +
> > +  my $gp=3D can_run('gnuplot') or return;
>=20
> Need to install gnuplot before hand?
>=20
Well, this is the OSSTest controller, not the target host, guest or
anything, so I'd need to install it by some perl equivalent of
'system("apt-get install gnuplot") (or whatever Perl offers to run
system commands).

I haven't found many examples of executing commands on the controller in
current OSSTest codebase, and I'm not sure whether that is a good idea
and/or a strong requirement here... Again, let's see what others think.

> > +  my ($ok,$err)=3D run( command =3D> "$gp $pfile.gp", verbose =3D> 1 )=
;
> > +  logm("WARNING: plotting file with \"$err\"") unless $ok;
>=20
> Fail the test case instead of issuing a warning?
>=20
You think? Well, the benchmark(s) did run, and produced results that we
can analyze in many way other than plotting, either inside OSSTest
(adding the logic for that, of course) or outside of it, so I wouldn't
call this a 'failure'.

Perhaps I should distinguish between the cases where gnuplot is just not
there, in which case I really would continue just issuing warnings, from
the case where the plotting command ran and failed, in which cased I
agree, we should fail the test... What do you think?

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)


--=-3aJ4Q1Khld+MiGoxl9KG
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

iEYEABECAAYFAlSJmBAACgkQk4XaBE3IOsTvdACghU+akBam0CvGla/YoKJhYWMy
tWcAn3JI3KCyyKdveMYmb+FKTVyR//rr
=hVxp
-----END PGP SIGNATURE-----

--=-3aJ4Q1Khld+MiGoxl9KG--


--===============7963812080128913436==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7963812080128913436==--


From xen-devel-bounces@lists.xen.org Thu Dec 11 13:11:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3X6-0005fN-8H; Thu, 11 Dec 2014 13:11:52 +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 1Xz3X4-0005eZ-5w
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:11:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	37/F8-09842-51899845; Thu, 11 Dec 2014 13:11:49 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418303506!14970938!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5659 invoked from network); 11 Dec 2014 13:11:47 -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;
	11 Dec 2014 13:11:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; 
	d="asc'?scan'208";a="202930224"
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.210.2;
	Thu, 11 Dec 2014 08:11:45 -0500
Message-ID: <1418303504.31647.98.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 11 Dec 2014 14:11:44 +0100
In-Reply-To: <20141211121554.GI21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181006.26400.25863.stgit@Abyss.station>
	<20141211121554.GI21659@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: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/27] ts-unixbench-reslts: process and plot
 bench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7963812080128913436=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7963812080128913436==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-3aJ4Q1Khld+MiGoxl9KG"

--=-3aJ4Q1Khld+MiGoxl9KG
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-12-11 at 12:15 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 07:10:06PM +0100, Dario Faggioli wrote:

> > This is done in a new Osstest/Benchmarking.pm module, as
> > the functions introduced may turn out useful somewhere else
> > too.
> >=20
>=20
> I would suggest using a dedicated commit for the introduction of
> Benchmarking.pm.
>=20
I'm not sure. I like it being introduced here where it's useful, since
that does not, IMO, make the patch too long or to difficult to
understand/review/etc.

However, this is not a too big deal... let's see what others think, and
I'll copy. :-)

> > --- /dev/null
> > +++ b/Osstest/Benchmarking.pm
> > @@ -0,0 +1,115 @@
> > +# This is part of "osstest", an automated testing framework for Xen.
> > +# Copyright (C) 2009-2013 Citrix Inc.
>=20
> 2009-2014
>=20
Right! :-)

> > +sub unixbench_plot_results ($$$) {
> > +  my ($dataf,$num_cols,$pfile)=3D @_;
> > +  my $h=3D new IO::File "> $pfile.gp" or die "$!";
> > +
> > +  printf $h <<EOF;
> > +set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/D=
ejaVuSans.ttf" 8 size 800,600
> > +set output '$pfile.png'
> > +set title 'Unixbench INDEXes for $flight.$job'
> > +set key outside center top horizontal noreverse noenhanced autotitles =
nobox
> > +set xtics mirror rotate by -45 out
> > +set style data histogram
> > +set style histogram cluster gap 1
> > +set style fill solid border lt -1
> > +set boxwidth 1 absolute
> > +set bmargin 13
> > +set rmargin 14
> > +SKIP_COL=3D1
> > +NCOL=3D$num_cols
> > +HWIDTH=3D1.0/(NCOL+1.0)
> > +plot for [c=3DSKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with =
histograms title columnhead, \\
> > +        for [c=3DSKIP_COL+1:SKIP_COL+NCOL]'' every ::1 using 0:c:c wit=
h labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1)=
)*HWIDTH, character 2 rotate by 90
> > +EOF
> > +  close($h);
> > +
> > +  my $gp=3D can_run('gnuplot') or return;
>=20
> Need to install gnuplot before hand?
>=20
Well, this is the OSSTest controller, not the target host, guest or
anything, so I'd need to install it by some perl equivalent of
'system("apt-get install gnuplot") (or whatever Perl offers to run
system commands).

I haven't found many examples of executing commands on the controller in
current OSSTest codebase, and I'm not sure whether that is a good idea
and/or a strong requirement here... Again, let's see what others think.

> > +  my ($ok,$err)=3D run( command =3D> "$gp $pfile.gp", verbose =3D> 1 )=
;
> > +  logm("WARNING: plotting file with \"$err\"") unless $ok;
>=20
> Fail the test case instead of issuing a warning?
>=20
You think? Well, the benchmark(s) did run, and produced results that we
can analyze in many way other than plotting, either inside OSSTest
(adding the logic for that, of course) or outside of it, so I wouldn't
call this a 'failure'.

Perhaps I should distinguish between the cases where gnuplot is just not
there, in which case I really would continue just issuing warnings, from
the case where the plotting command ran and failed, in which cased I
agree, we should fail the test... What do you think?

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)


--=-3aJ4Q1Khld+MiGoxl9KG
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

iEYEABECAAYFAlSJmBAACgkQk4XaBE3IOsTvdACghU+akBam0CvGla/YoKJhYWMy
tWcAn3JI3KCyyKdveMYmb+FKTVyR//rr
=hVxp
-----END PGP SIGNATURE-----

--=-3aJ4Q1Khld+MiGoxl9KG--


--===============7963812080128913436==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7963812080128913436==--


From xen-devel-bounces@lists.xen.org Thu Dec 11 13:16:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3bH-00068T-Uh; Thu, 11 Dec 2014 13:16: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 1Xz3bH-00068O-56
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:16:11 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	9E/8A-02697-A1999845; Thu, 11 Dec 2014 13:16:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418303768!12859427!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29424 invoked from network); 11 Dec 2014 13:16: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;
	11 Dec 2014 13:16:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203334549"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 08:16: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 1Xz3bC-00031p-Ic;
	Thu, 11 Dec 2014 13:16:06 +0000
Date: Thu, 11 Dec 2014 13:16:06 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141211131606.GL21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181006.26400.25863.stgit@Abyss.station>
	<20141211121554.GI21659@zion.uk.xensource.com>
	<1418303504.31647.98.camel@Abyss.station>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418303504.31647.98.camel@Abyss.station>
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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/27] ts-unixbench-reslts: process and plot
 bench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 02:11:44PM +0100, Dario Faggioli wrote:
[...]
> > > +sub unixbench_plot_results ($$$) {
> > > +  my ($dataf,$num_cols,$pfile)= @_;
> > > +  my $h= new IO::File "> $pfile.gp" or die "$!";
> > > +
> > > +  printf $h <<EOF;
> > > +set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" 8 size 800,600
> > > +set output '$pfile.png'
> > > +set title 'Unixbench INDEXes for $flight.$job'
> > > +set key outside center top horizontal noreverse noenhanced autotitles nobox
> > > +set xtics mirror rotate by -45 out
> > > +set style data histogram
> > > +set style histogram cluster gap 1
> > > +set style fill solid border lt -1
> > > +set boxwidth 1 absolute
> > > +set bmargin 13
> > > +set rmargin 14
> > > +SKIP_COL=1
> > > +NCOL=$num_cols
> > > +HWIDTH=1.0/(NCOL+1.0)
> > > +plot for [c=SKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with histograms title columnhead, \\
> > > +        for [c=SKIP_COL+1:SKIP_COL+NCOL]'' every ::1 using 0:c:c with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1))*HWIDTH, character 2 rotate by 90
> > > +EOF
> > > +  close($h);
> > > +
> > > +  my $gp= can_run('gnuplot') or return;
> > 
> > Need to install gnuplot before hand?
> > 
> Well, this is the OSSTest controller, not the target host, guest or
> anything, so I'd need to install it by some perl equivalent of
> 'system("apt-get install gnuplot") (or whatever Perl offers to run
> system commands).
> 

Ah, the controller, OK...

> I haven't found many examples of executing commands on the controller in
> current OSSTest codebase, and I'm not sure whether that is a good idea
> and/or a strong requirement here... Again, let's see what others think.
> 
> > > +  my ($ok,$err)= run( command => "$gp $pfile.gp", verbose => 1 );
> > > +  logm("WARNING: plotting file with \"$err\"") unless $ok;
> > 
> > Fail the test case instead of issuing a warning?
> > 
> You think? Well, the benchmark(s) did run, and produced results that we
> can analyze in many way other than plotting, either inside OSSTest
> (adding the logic for that, of course) or outside of it, so I wouldn't
> call this a 'failure'.
> 

Since gnuplot runs on controller this point becomes moot.

> Perhaps I should distinguish between the cases where gnuplot is just not
> there, in which case I really would continue just issuing warnings, from
> the case where the plotting command ran and failed, in which cased I
> agree, we should fail the test... What do you think?
> 

Make sense.

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 Thu Dec 11 13:16:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3bH-00068T-Uh; Thu, 11 Dec 2014 13:16: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 1Xz3bH-00068O-56
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:16:11 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	9E/8A-02697-A1999845; Thu, 11 Dec 2014 13:16:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418303768!12859427!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29424 invoked from network); 11 Dec 2014 13:16: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;
	11 Dec 2014 13:16:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203334549"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 08:16: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 1Xz3bC-00031p-Ic;
	Thu, 11 Dec 2014 13:16:06 +0000
Date: Thu, 11 Dec 2014 13:16:06 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Message-ID: <20141211131606.GL21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181006.26400.25863.stgit@Abyss.station>
	<20141211121554.GI21659@zion.uk.xensource.com>
	<1418303504.31647.98.camel@Abyss.station>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418303504.31647.98.camel@Abyss.station>
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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/27] ts-unixbench-reslts: process and plot
 bench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 02:11:44PM +0100, Dario Faggioli wrote:
[...]
> > > +sub unixbench_plot_results ($$$) {
> > > +  my ($dataf,$num_cols,$pfile)= @_;
> > > +  my $h= new IO::File "> $pfile.gp" or die "$!";
> > > +
> > > +  printf $h <<EOF;
> > > +set terminal png enhanced font "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" 8 size 800,600
> > > +set output '$pfile.png'
> > > +set title 'Unixbench INDEXes for $flight.$job'
> > > +set key outside center top horizontal noreverse noenhanced autotitles nobox
> > > +set xtics mirror rotate by -45 out
> > > +set style data histogram
> > > +set style histogram cluster gap 1
> > > +set style fill solid border lt -1
> > > +set boxwidth 1 absolute
> > > +set bmargin 13
> > > +set rmargin 14
> > > +SKIP_COL=1
> > > +NCOL=$num_cols
> > > +HWIDTH=1.0/(NCOL+1.0)
> > > +plot for [c=SKIP_COL+1:SKIP_COL+NCOL] '$dataf' using c:xtic(1) with histograms title columnhead, \\
> > > +        for [c=SKIP_COL+1:SKIP_COL+NCOL]'' every ::1 using 0:c:c with labels notitle offset first -HWIDTH*(NCOL/2.0)+HWIDTH/2.0+(c-(SKIP_COL+1))*HWIDTH, character 2 rotate by 90
> > > +EOF
> > > +  close($h);
> > > +
> > > +  my $gp= can_run('gnuplot') or return;
> > 
> > Need to install gnuplot before hand?
> > 
> Well, this is the OSSTest controller, not the target host, guest or
> anything, so I'd need to install it by some perl equivalent of
> 'system("apt-get install gnuplot") (or whatever Perl offers to run
> system commands).
> 

Ah, the controller, OK...

> I haven't found many examples of executing commands on the controller in
> current OSSTest codebase, and I'm not sure whether that is a good idea
> and/or a strong requirement here... Again, let's see what others think.
> 
> > > +  my ($ok,$err)= run( command => "$gp $pfile.gp", verbose => 1 );
> > > +  logm("WARNING: plotting file with \"$err\"") unless $ok;
> > 
> > Fail the test case instead of issuing a warning?
> > 
> You think? Well, the benchmark(s) did run, and produced results that we
> can analyze in many way other than plotting, either inside OSSTest
> (adding the logic for that, of course) or outside of it, so I wouldn't
> call this a 'failure'.
> 

Since gnuplot runs on controller this point becomes moot.

> Perhaps I should distinguish between the cases where gnuplot is just not
> there, in which case I really would continue just issuing warnings, from
> the case where the plotting command ran and failed, in which cased I
> agree, we should fail the test... What do you think?
> 

Make sense.

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 Thu Dec 11 13:16:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3bf-0006Ac-Aw; Thu, 11 Dec 2014 13:16:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xz3bd-0006AP-Mb
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:16:33 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	10/A9-15461-03999845; Thu, 11 Dec 2014 13:16:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418303792!14953583!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 30258 invoked from network); 11 Dec 2014 13:16:32 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:16:32 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz3bN-000HeM-AS; Thu, 11 Dec 2014 13:16:17 +0000
Date: Thu, 11 Dec 2014 14:16:17 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141211131617.GE53811@deinos.phlegethon.org>
References: <54898449020000780004EDDD@mail.emea.novell.com>
	<20141211130026.GA53825@deinos.phlegethon.org>
	<5489A584020000780004EF49@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5489A584020000780004EF49@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: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: don't deliver NMI to PVH Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:09 +0000 on 11 Dec (1418299748), Jan Beulich wrote:
> >>> On 11.12.14 at 14:00, <tim@xen.org> wrote:
> > At 10:47 +0000 on 11 Dec (1418291241), Jan Beulich wrote:
> >> ... for the time being: The mechanism used depends on the domain's use
> >> of the IRET hypercall.
> > 
> > Can you elaborate?  Looking at the existing code it seems like what it
> > does is set v->nmi_pending and make sure the vcpu gets scheduled
> > appropriately.
> > 
> > The HVM code will deliver an NMI if it sees v->nmi_pending (which is
> > what vlapic_accept_irq does, for example).  Is there some other piece
> > I'm missing?
> 
> Just so that others see the answer too: The problem is that the
> temporary affinity adjustment gets undone in the HYPERVISOR_iret
> handler, yet PVH can't call that hypercall.

Thanks.  So to make this work for PVH we'd want to do something like
calling async_exception_cleanup() from vlapic_EOI_set()?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 13:16:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3bf-0006Ac-Aw; Thu, 11 Dec 2014 13:16:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xz3bd-0006AP-Mb
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:16:33 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	10/A9-15461-03999845; Thu, 11 Dec 2014 13:16:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418303792!14953583!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 30258 invoked from network); 11 Dec 2014 13:16:32 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:16:32 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz3bN-000HeM-AS; Thu, 11 Dec 2014 13:16:17 +0000
Date: Thu, 11 Dec 2014 14:16:17 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141211131617.GE53811@deinos.phlegethon.org>
References: <54898449020000780004EDDD@mail.emea.novell.com>
	<20141211130026.GA53825@deinos.phlegethon.org>
	<5489A584020000780004EF49@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5489A584020000780004EF49@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: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: don't deliver NMI to PVH Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:09 +0000 on 11 Dec (1418299748), Jan Beulich wrote:
> >>> On 11.12.14 at 14:00, <tim@xen.org> wrote:
> > At 10:47 +0000 on 11 Dec (1418291241), Jan Beulich wrote:
> >> ... for the time being: The mechanism used depends on the domain's use
> >> of the IRET hypercall.
> > 
> > Can you elaborate?  Looking at the existing code it seems like what it
> > does is set v->nmi_pending and make sure the vcpu gets scheduled
> > appropriately.
> > 
> > The HVM code will deliver an NMI if it sees v->nmi_pending (which is
> > what vlapic_accept_irq does, for example).  Is there some other piece
> > I'm missing?
> 
> Just so that others see the answer too: The problem is that the
> temporary affinity adjustment gets undone in the HYPERVISOR_iret
> handler, yet PVH can't call that hypercall.

Thanks.  So to make this work for PVH we'd want to do something like
calling async_exception_cleanup() from vlapic_EOI_set()?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 13:16:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:16:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3bg-0006BI-O6; Thu, 11 Dec 2014 13:16:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xz3bf-0006Aa-KC
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:16:35 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	1E/8C-14727-23999845; Thu, 11 Dec 2014 13:16:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418303794!7522483!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19854 invoked from network); 11 Dec 2014 13:16:34 -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; 11 Dec 2014 13:16:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 13:16:33 +0000
Message-Id: <5489A741020000780004EF68@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 13:16:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
	<5481D3D1020000780004D35F@mail.emea.novell.com>
	<1417791061.22808.68.camel@eu.citrix.com>
	<1418299630.10394.28.camel@citrix.com>
In-Reply-To: <1418299630.10394.28.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	IanJackson <Ian.Jackson@eu.citrix.com>, TimDeegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.14 at 13:07, <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-12-05 at 14:51 +0000, Ian Campbell wrote:
>> On Fri, 2014-12-05 at 14:48 +0000, Jan Beulich wrote:
>> > >>> On 05.12.14 at 15:27, <Ian.Campbell@eu.citrix.com> wrote:
>> > > On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>> > >>  #define nr_static_irqs NR_IRQS
>> > >> +#define arch_hwdom_irqs(domid) NR_IRQS
>> > > 
>> > > FWIW gic_number_lines() is the ARM equivalent of getting the number of
>> > > GSIs.
>> > > 
>> > > *BUT* we don't actually use pirqs on ARM (everything goes via the
>> > > virtualised interrupt controller). So maybe we should be setting
>> > > nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
>> > > from an ARM person, so I'm fine with you making this NR_IRQS in the
>> > > meantime.
>> > 
>> > Considering Julien also asking for this, I don't mind changing this to
>> > zero for ARM. Just let me know which way I can get this ack-ed.
>> 
>> If you are happy to provide a version using zero and Julien wants to
>> provide a tested-by then I'm fine with going that way.
> 
> Seems like things were more complex than Julien expected here, so I
> think changing to zero would be a mistake at this point.
> 
> AIUI this patch results in no functional change for ARM, in that dom0
> previously saw:
>         d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
> where nr_static_irqs == NR_IRQS on ARM where now it sees:
> 
> When extra_dom0_irqs > 0
>         nr_static_irqs + extra_dom0_irqs
> which is the same as before. Or when extra_dom0_irqs:
>         arch_hwdom_irqs(domid);
> ==   NR_IRQS
> ==   nr_static_irqs + 0
> i.e. no change.
> 
> Oh, actually extra_dom0_irqs has changed from a default of 256 to 0, I
> don't think NR_IRQS(1024) + 256 made much sense on ARM (which is limited
> to 1020 IRQs in h/w anyway), so I don't consider that a problem.
> 
> If that's all correct then: 

It is.

>         Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Also Ack with my REST maintainer hat on for the general principal/common
> code.

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 Dec 11 13:16:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:16:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3bg-0006BI-O6; Thu, 11 Dec 2014 13:16:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xz3bf-0006Aa-KC
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:16:35 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	1E/8C-14727-23999845; Thu, 11 Dec 2014 13:16:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418303794!7522483!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19854 invoked from network); 11 Dec 2014 13:16:34 -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; 11 Dec 2014 13:16:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 13:16:33 +0000
Message-Id: <5489A741020000780004EF68@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 13:16:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <5481C67D020000780004D2D1@mail.emea.novell.com>
	<1417789634.22808.66.camel@eu.citrix.com>
	<5481D3D1020000780004D35F@mail.emea.novell.com>
	<1417791061.22808.68.camel@eu.citrix.com>
	<1418299630.10394.28.camel@citrix.com>
In-Reply-To: <1418299630.10394.28.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	IanJackson <Ian.Jackson@eu.citrix.com>, TimDeegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] have architectures specify the number of
 PIRQs a hardware domain gets
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.14 at 13:07, <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-12-05 at 14:51 +0000, Ian Campbell wrote:
>> On Fri, 2014-12-05 at 14:48 +0000, Jan Beulich wrote:
>> > >>> On 05.12.14 at 15:27, <Ian.Campbell@eu.citrix.com> wrote:
>> > > On Fri, 2014-12-05 at 13:51 +0000, Jan Beulich wrote:
>> > >>  #define nr_static_irqs NR_IRQS
>> > >> +#define arch_hwdom_irqs(domid) NR_IRQS
>> > > 
>> > > FWIW gic_number_lines() is the ARM equivalent of getting the number of
>> > > GSIs.
>> > > 
>> > > *BUT* we don't actually use pirqs on ARM (everything goes via the
>> > > virtualised interrupt controller). So maybe we should be setting
>> > > nr_pirqs to 0 on ARM. I appreciate you likely want such a patch to come
>> > > from an ARM person, so I'm fine with you making this NR_IRQS in the
>> > > meantime.
>> > 
>> > Considering Julien also asking for this, I don't mind changing this to
>> > zero for ARM. Just let me know which way I can get this ack-ed.
>> 
>> If you are happy to provide a version using zero and Julien wants to
>> provide a tested-by then I'm fine with going that way.
> 
> Seems like things were more complex than Julien expected here, so I
> think changing to zero would be a mistake at this point.
> 
> AIUI this patch results in no functional change for ARM, in that dom0
> previously saw:
>         d->nr_pirqs = nr_static_irqs + extra_dom0_irqs;
> where nr_static_irqs == NR_IRQS on ARM where now it sees:
> 
> When extra_dom0_irqs > 0
>         nr_static_irqs + extra_dom0_irqs
> which is the same as before. Or when extra_dom0_irqs:
>         arch_hwdom_irqs(domid);
> ==   NR_IRQS
> ==   nr_static_irqs + 0
> i.e. no change.
> 
> Oh, actually extra_dom0_irqs has changed from a default of 256 to 0, I
> don't think NR_IRQS(1024) + 256 made much sense on ARM (which is limited
> to 1020 IRQs in h/w anyway), so I don't consider that a problem.
> 
> If that's all correct then: 

It is.

>         Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Also Ack with my REST maintainer hat on for the general principal/common
> code.

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 Dec 11 13:19:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3ep-0006YT-8L; Thu, 11 Dec 2014 13:19: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 1Xz3en-0006YJ-SW
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:19:49 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	4F/C3-28296-5F999845; Thu, 11 Dec 2014 13:19:49 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418303986!12641643!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2048 invoked from network); 11 Dec 2014 13:19:48 -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;
	11 Dec 2014 13:19:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; 
	d="asc'?scan'208";a="202933218"
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.210.2;
	Thu, 11 Dec 2014 08:19:17 -0500
Message-ID: <1418303956.31647.100.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 11 Dec 2014 14:19:16 +0100
In-Reply-To: <20141210181112.26400.8824.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181112.26400.8824.stgit@Abyss.station>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
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: Re: [Xen-devel] [PATCH 17/27] ts-kernbench-reslts: process and plot
 bench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1552539795854573929=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1552539795854573929==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-v21GJt7VRNz6hU5dx2bA"

--=-v21GJt7VRNz6hU5dx2bA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2014-12-10 at 19:11 +0100, Dario Faggioli wrote:
> From: Dario Faggioli <raistlin@linux.it>
>=20
Mmm... It's quite weird that some of the patches came out with this
'From:' tag with my pvt address. I guess I've messed up something with
the git/stgit configuration on the box from where I sent this.

Will fix, please ignore that. :-P

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)


--=-v21GJt7VRNz6hU5dx2bA
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

iEYEABECAAYFAlSJmdQACgkQk4XaBE3IOsTVUgCgrSyWQHS/r5E9NU1qETbH6GmF
zB0AoK17ta2ZOG8vd8eUbNkrkRUCQ5Pm
=JzUa
-----END PGP SIGNATURE-----

--=-v21GJt7VRNz6hU5dx2bA--


--===============1552539795854573929==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1552539795854573929==--


From xen-devel-bounces@lists.xen.org Thu Dec 11 13:19:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3ep-0006YT-8L; Thu, 11 Dec 2014 13:19: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 1Xz3en-0006YJ-SW
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:19:49 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	4F/C3-28296-5F999845; Thu, 11 Dec 2014 13:19:49 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418303986!12641643!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2048 invoked from network); 11 Dec 2014 13:19:48 -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;
	11 Dec 2014 13:19:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; 
	d="asc'?scan'208";a="202933218"
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.210.2;
	Thu, 11 Dec 2014 08:19:17 -0500
Message-ID: <1418303956.31647.100.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 11 Dec 2014 14:19:16 +0100
In-Reply-To: <20141210181112.26400.8824.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181112.26400.8824.stgit@Abyss.station>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
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: Re: [Xen-devel] [PATCH 17/27] ts-kernbench-reslts: process and plot
 bench results
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1552539795854573929=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1552539795854573929==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-v21GJt7VRNz6hU5dx2bA"

--=-v21GJt7VRNz6hU5dx2bA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2014-12-10 at 19:11 +0100, Dario Faggioli wrote:
> From: Dario Faggioli <raistlin@linux.it>
>=20
Mmm... It's quite weird that some of the patches came out with this
'From:' tag with my pvt address. I guess I've messed up something with
the git/stgit configuration on the box from where I sent this.

Will fix, please ignore that. :-P

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)


--=-v21GJt7VRNz6hU5dx2bA
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

iEYEABECAAYFAlSJmdQACgkQk4XaBE3IOsTVUgCgrSyWQHS/r5E9NU1qETbH6GmF
zB0AoK17ta2ZOG8vd8eUbNkrkRUCQ5Pm
=JzUa
-----END PGP SIGNATURE-----

--=-v21GJt7VRNz6hU5dx2bA--


--===============1552539795854573929==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1552539795854573929==--


From xen-devel-bounces@lists.xen.org Thu Dec 11 13:20:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3fG-0006bq-LU; Thu, 11 Dec 2014 13:20:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xz3fF-0006bf-Uu
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:20:18 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	A1/E1-02696-11A99845; Thu, 11 Dec 2014 13:20:17 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418304015!14428831!1
X-Originating-IP: [209.85.212.172]
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 21119 invoked from network); 11 Dec 2014 13:20:16 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 13:20:16 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so14538434wiv.17
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 05:20:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references
	:content-type:mime-version;
	bh=61P9LUisdPJPlLXNU6ev6utIYG8dNi5RKPL/AxBlX+c=;
	b=NTCJUYy+YgNzEBz5WmXil1KcEEPFpIXkHdGm1SG1Guk2rGB2VIW2iEQfOopSSorMXI
	YP5Tbn4H1bIoSJpA03xTBrJdmhGPbXvb+MtOI7ezgVE1gJX1rz+eb8nVATbjDBxtVHQp
	ae7QR6D/n5H2I8XKIiORVo8JVv+QNmEFFxshBrrh70PT6i2pKXecmGZO/ZB3QxyXp4VF
	6Gk0eUfYbvhF7QvUHN6OSjiUtnRtJcqSqB82gVRCU15LEl8uzqxLf/JwhFsGcGWFqp45
	wxuWQoqKsSKjtn7F/HBKhkPI6ZTcwLcsDQf2HHqu+TrQ2nP5VcMyvsvwYt0xAC661Jlr
	RdtA==
X-Received: by 10.180.109.46 with SMTP id hp14mr16213266wib.54.1418304014912; 
	Thu, 11 Dec 2014 05:20:14 -0800 (PST)
Received: from [192.168.1.40] (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id gi5sm1662765wjd.26.2014.12.11.05.20.12
	for <multiple recipients>
	(version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 05:20:13 -0800 (PST)
Message-ID: <1418304011.31647.101.camel@Abyss.station>
From: Dario Faggioli <raistlin.df@gmail.com>
To: xen-devel@lists.xen.org
Date: Thu, 11 Dec 2014 14:20:11 +0100
In-Reply-To: <20141210181200.26400.71485.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181200.26400.71485.stgit@Abyss.station>
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
Mime-Version: 1.0
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 23/27] ts-bench-hostcmp-host-reset: new
	script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: raistlin@linux.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="===============6979308872276089674=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6979308872276089674==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-mj5Bzatkn3G6DdFouvO5"


--=-mj5Bzatkn3G6DdFouvO5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2014-12-10 at 19:12 +0100, Dario Faggioli wrote:
> From: Dario Faggioli <raistlin@linux.it>
>=20
Somehow, this patch lacks a changelog! :-O

Sorry about this too, I'll write one for next version.

Regards,
Dario

> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  Osstest/Debian.pm      |   32 +++++++++++++++++---------------
>  Osstest/TestSupport.pm |   46 ++++++++++++++++++++++++++++++++++++++++++=
+++-
>  ts-bench-hostcmp-post  |   39 +++++++++++++++++++++++++++++++++++++++
>  ts-xen-install         |   38 ++------------------------------------
>  4 files changed, 103 insertions(+), 52 deletions(-)
>  create mode 100755 ts-bench-hostcmp-post
>=20
> diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> index 418d9f2..447d2d2 100644
> --- a/Osstest/Debian.pm
> +++ b/Osstest/Debian.pm
> @@ -87,25 +87,27 @@ sub debian_boot_setup ($$$$;$) {
>      my $kern=3D $bootloader->{GetBootKern}();
>      logm("dom0 kernel is $kern");
> =20
> -    system "tar zvtf $distpath->{kern} boot/$kern";
> -    $? and die "$distpath->{kern} boot/$kern $?";
> -
> -    my $kernver=3D $kern;
> -    $kernver =3D~ s,^/?(?:boot/)?(?:vmlinu[xz]-)?,, or die "$kernver ?";
> -    my $kernpath=3D $kern;
> -    $kernpath =3D~ s,^(?:boot/)?,/boot/,;
> -
> -    target_cmd_root($ho,
> -                    "update-initramfs -k $kernver -c ||".
> -                    " update-initramfs -k $kernver -u",
> -                    200);
> +    if (defined $distpath) {
> +        system "tar zvtf $distpath->{kern} boot/$kern";
> +        $? and die "$distpath->{kern} boot/$kern $?";
> +
> +        my $kernver=3D $kern;
> +        $kernver =3D~ s,^/?(?:boot/)?(?:vmlinu[xz]-)?,, or die "$kernver=
 ?";
> +        my $kernpath=3D $kern;
> +        $kernpath =3D~ s,^(?:boot/)?,/boot/,;
> +
> +        target_cmd_root($ho,
> +                        "update-initramfs -k $kernver -c ||".
> +                        " update-initramfs -k $kernver -u",
> +                        200);
> +
> +        store_runvar(target_var_prefix($ho).'xen_kernel_path',$kernpath)=
;
> +        store_runvar(target_var_prefix($ho).'xen_kernel_ver',$kernver);
> +    }
> =20
>      $bootloader->{PreFinalUpdate}();
> =20
>      $bootloader->{UpdateConfig}($ho);
> -
> -    store_runvar(target_var_prefix($ho).'xen_kernel_path',$kernpath);
> -    store_runvar(target_var_prefix($ho).'xen_kernel_ver',$kernver);
>  }
> =20
>  sub bl_getmenu_open ($$$) {
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index 251668a..c967e4f 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -99,7 +99,7 @@ BEGIN {
>                        guest_vncsnapshot_begin guest_vncsnapshot_stash
>  		      guest_check_remus_ok guest_editconfig
>                        host_involves_pcipassthrough host_get_pcipassthrou=
gh_devs
> -                      toolstack guest_create
> +                      toolstack guest_create host_bootxen_setup
> =20
>                        await_webspace_fetch_byleaf create_webfile
>                        file_link_contents get_timeout
> @@ -1012,6 +1012,50 @@ sub get_host_memory ($) {
>      return $mem;
>  }
> =20
> +#---------- bootloader and booting ----------
> +#
> +sub host_bootxen_setup ($) {
> +    my ($ho)=3D @_;
> +
> +    my $xenhopt=3D "conswitch=3Dx watchdog";
> +
> +    my $cons=3D get_host_property($ho, 'XenSerialConsole', 'com1');
> +
> +    if ( $cons eq "com1" ) {
> +        $xenhopt .=3D " com1=3D$c{Baud},8n1 console=3Dcom1,vga gdb=3Dcom=
1";
> +    } elsif ( $cons eq "dtuart" ) {
> +        $xenhopt .=3D " console=3Ddtuart";
> +        my $dtuart=3D get_host_property($ho, 'XenDTUARTPath', undef);
> +        $xenhopt .=3D " dtuart=3D$dtuart" if $dtuart;
> +    } else {
> +        logm("No Xen console device defined for host");
> +    }
> +    if (toolstack()->{Dom0MemFixed}) {
> +        $xenhopt .=3D " dom0_mem=3D512M,max:512M";
> +    }
> +    my $append=3D $r{xen_boot_append};
> +    $xenhopt .=3D " $append" if defined $append;
> +    $append =3D get_host_property($ho, 'xen-commandline-append', undef);
> +    $xenhopt .=3D " $append" if defined $append;
> +
> +    my @hooks;
> +
> +    if (host_involves_pcipassthrough($ho)) {
> +        push @hooks, {
> +            EditBootOptions =3D> sub {
> +                my ($ho,$hopt,$kopt) =3D @_;
> +                $$hopt .=3D ' iommu=3Don';
> +                my $hide=3D ' xen-pciback.hide=3D'. join '',map { "($_->=
{Bdf})" }
> +                    host_get_pcipassthrough_devs($ho);
> +                logm("pci passthrough: hiding in dom0: $hide");
> +                $$kopt .=3D $hide;
> +            }
> +        };
> +    }
> +
> +    return ($xenhopt,@hooks);
> +}
> +
>  #---------- stashed files ----------
> =20
>  sub open_unique_stashfile ($) {
> diff --git a/ts-bench-hostcmp-post b/ts-bench-hostcmp-post
> new file mode 100755
> index 0000000..26a67f4
> --- /dev/null
> +++ b/ts-bench-hostcmp-post
> @@ -0,0 +1,39 @@
> +#!/usr/bin/perl -w
> +# This is part of "osstest", an automated testing framework for Xen.
> +# Copyright (C) 2009-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 publish=
ed 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 Licen=
se
> +# 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) =3D @ARGV;
> +$whhost ||=3D 'host';
> +our $ho=3D selecthost($whhost);
> +
> +sub resetboot () {
> +  my ($xenhopt,@hooks)=3D host_bootxen_setup($ho);
> +  my $want_kernver =3D get_runvar('kernel_ver',$r{'kernbuildjob'});
> +
> +  debian_boot_setup($ho, $want_kernver, $xenhopt, undef, \@hooks);
> +
> +  logm("host reset to booting Xen");
> +}
> +
> +resetboot();
> diff --git a/ts-xen-install b/ts-xen-install
> index 4d34d1f..d8d38fc 100755
> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -134,43 +134,9 @@ sub adjustconfig () {
>  }
> =20
>  sub setupboot () {
> -    my $xenhopt=3D "conswitch=3Dx watchdog";
> -
> -    my $cons=3D get_host_property($ho, 'XenSerialConsole', 'com1');
> -
> -    if ( $cons eq "com1" ) {
> -	$xenhopt .=3D " com1=3D$c{Baud},8n1 console=3Dcom1,vga gdb=3Dcom1";
> -    } elsif ( $cons eq "dtuart" ) {
> -	$xenhopt .=3D " console=3Ddtuart";
> -	my $dtuart=3D get_host_property($ho, 'XenDTUARTPath', undef);
> -	$xenhopt .=3D " dtuart=3D$dtuart" if $dtuart;
> -    } else {
> -	logm("No Xen console device defined for host");
> -    }
> -    if (toolstack()->{Dom0MemFixed}) {
> -        $xenhopt .=3D " dom0_mem=3D512M,max:512M";
> -    }
> -    my $append=3D $r{xen_boot_append};
> -    $xenhopt .=3D " $append" if defined $append;
> -    $append =3D get_host_property($ho, 'xen-commandline-append', undef);
> -    $xenhopt .=3D " $append" if defined $append;
> -
> -    my @hooks;
> -
> -    if (host_involves_pcipassthrough($ho)) {
> -        push @hooks, {
> -            EditBootOptions =3D> sub {
> -                my ($ho,$hopt,$kopt) =3D @_;
> -                $$hopt .=3D ' iommu=3Don';
> -                my $hide=3D ' xen-pciback.hide=3D'. join '',map { "($_->=
{Bdf})" }
> -                    host_get_pcipassthrough_devs($ho);
> -                logm("pci passthrough: hiding in dom0: $hide");
> -                $$kopt .=3D $hide;
> -            }
> -        };
> -    }
> -
> +    my ($xenhopt,@hooks)=3D host_bootxen_setup($ho);
>      my $want_kernver =3D get_runvar('kernel_ver',$r{'kernbuildjob'});
> +
>      debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks)=
;
> =20
>      logm("ready to boot Xen");
>=20


--=-mj5Bzatkn3G6DdFouvO5
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

iEYEABECAAYFAlSJmgsACgkQk4XaBE3IOsTjFwCfYJnXscQVqSigC8mzi4wbud6k
53UAn0xilM5xjx843HfZHGdLY+tDfr6t
=HUkk
-----END PGP SIGNATURE-----

--=-mj5Bzatkn3G6DdFouvO5--



--===============6979308872276089674==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6979308872276089674==--



From xen-devel-bounces@lists.xen.org Thu Dec 11 13:20:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3fG-0006bq-LU; Thu, 11 Dec 2014 13:20:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Xz3fF-0006bf-Uu
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:20:18 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	A1/E1-02696-11A99845; Thu, 11 Dec 2014 13:20:17 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418304015!14428831!1
X-Originating-IP: [209.85.212.172]
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 21119 invoked from network); 11 Dec 2014 13:20:16 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 13:20:16 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so14538434wiv.17
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 05:20:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references
	:content-type:mime-version;
	bh=61P9LUisdPJPlLXNU6ev6utIYG8dNi5RKPL/AxBlX+c=;
	b=NTCJUYy+YgNzEBz5WmXil1KcEEPFpIXkHdGm1SG1Guk2rGB2VIW2iEQfOopSSorMXI
	YP5Tbn4H1bIoSJpA03xTBrJdmhGPbXvb+MtOI7ezgVE1gJX1rz+eb8nVATbjDBxtVHQp
	ae7QR6D/n5H2I8XKIiORVo8JVv+QNmEFFxshBrrh70PT6i2pKXecmGZO/ZB3QxyXp4VF
	6Gk0eUfYbvhF7QvUHN6OSjiUtnRtJcqSqB82gVRCU15LEl8uzqxLf/JwhFsGcGWFqp45
	wxuWQoqKsSKjtn7F/HBKhkPI6ZTcwLcsDQf2HHqu+TrQ2nP5VcMyvsvwYt0xAC661Jlr
	RdtA==
X-Received: by 10.180.109.46 with SMTP id hp14mr16213266wib.54.1418304014912; 
	Thu, 11 Dec 2014 05:20:14 -0800 (PST)
Received: from [192.168.1.40] (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id gi5sm1662765wjd.26.2014.12.11.05.20.12
	for <multiple recipients>
	(version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 05:20:13 -0800 (PST)
Message-ID: <1418304011.31647.101.camel@Abyss.station>
From: Dario Faggioli <raistlin.df@gmail.com>
To: xen-devel@lists.xen.org
Date: Thu, 11 Dec 2014 14:20:11 +0100
In-Reply-To: <20141210181200.26400.71485.stgit@Abyss.station>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181200.26400.71485.stgit@Abyss.station>
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
Mime-Version: 1.0
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 23/27] ts-bench-hostcmp-host-reset: new
	script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: raistlin@linux.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="===============6979308872276089674=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6979308872276089674==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-mj5Bzatkn3G6DdFouvO5"


--=-mj5Bzatkn3G6DdFouvO5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2014-12-10 at 19:12 +0100, Dario Faggioli wrote:
> From: Dario Faggioli <raistlin@linux.it>
>=20
Somehow, this patch lacks a changelog! :-O

Sorry about this too, I'll write one for next version.

Regards,
Dario

> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  Osstest/Debian.pm      |   32 +++++++++++++++++---------------
>  Osstest/TestSupport.pm |   46 ++++++++++++++++++++++++++++++++++++++++++=
+++-
>  ts-bench-hostcmp-post  |   39 +++++++++++++++++++++++++++++++++++++++
>  ts-xen-install         |   38 ++------------------------------------
>  4 files changed, 103 insertions(+), 52 deletions(-)
>  create mode 100755 ts-bench-hostcmp-post
>=20
> diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> index 418d9f2..447d2d2 100644
> --- a/Osstest/Debian.pm
> +++ b/Osstest/Debian.pm
> @@ -87,25 +87,27 @@ sub debian_boot_setup ($$$$;$) {
>      my $kern=3D $bootloader->{GetBootKern}();
>      logm("dom0 kernel is $kern");
> =20
> -    system "tar zvtf $distpath->{kern} boot/$kern";
> -    $? and die "$distpath->{kern} boot/$kern $?";
> -
> -    my $kernver=3D $kern;
> -    $kernver =3D~ s,^/?(?:boot/)?(?:vmlinu[xz]-)?,, or die "$kernver ?";
> -    my $kernpath=3D $kern;
> -    $kernpath =3D~ s,^(?:boot/)?,/boot/,;
> -
> -    target_cmd_root($ho,
> -                    "update-initramfs -k $kernver -c ||".
> -                    " update-initramfs -k $kernver -u",
> -                    200);
> +    if (defined $distpath) {
> +        system "tar zvtf $distpath->{kern} boot/$kern";
> +        $? and die "$distpath->{kern} boot/$kern $?";
> +
> +        my $kernver=3D $kern;
> +        $kernver =3D~ s,^/?(?:boot/)?(?:vmlinu[xz]-)?,, or die "$kernver=
 ?";
> +        my $kernpath=3D $kern;
> +        $kernpath =3D~ s,^(?:boot/)?,/boot/,;
> +
> +        target_cmd_root($ho,
> +                        "update-initramfs -k $kernver -c ||".
> +                        " update-initramfs -k $kernver -u",
> +                        200);
> +
> +        store_runvar(target_var_prefix($ho).'xen_kernel_path',$kernpath)=
;
> +        store_runvar(target_var_prefix($ho).'xen_kernel_ver',$kernver);
> +    }
> =20
>      $bootloader->{PreFinalUpdate}();
> =20
>      $bootloader->{UpdateConfig}($ho);
> -
> -    store_runvar(target_var_prefix($ho).'xen_kernel_path',$kernpath);
> -    store_runvar(target_var_prefix($ho).'xen_kernel_ver',$kernver);
>  }
> =20
>  sub bl_getmenu_open ($$$) {
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index 251668a..c967e4f 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -99,7 +99,7 @@ BEGIN {
>                        guest_vncsnapshot_begin guest_vncsnapshot_stash
>  		      guest_check_remus_ok guest_editconfig
>                        host_involves_pcipassthrough host_get_pcipassthrou=
gh_devs
> -                      toolstack guest_create
> +                      toolstack guest_create host_bootxen_setup
> =20
>                        await_webspace_fetch_byleaf create_webfile
>                        file_link_contents get_timeout
> @@ -1012,6 +1012,50 @@ sub get_host_memory ($) {
>      return $mem;
>  }
> =20
> +#---------- bootloader and booting ----------
> +#
> +sub host_bootxen_setup ($) {
> +    my ($ho)=3D @_;
> +
> +    my $xenhopt=3D "conswitch=3Dx watchdog";
> +
> +    my $cons=3D get_host_property($ho, 'XenSerialConsole', 'com1');
> +
> +    if ( $cons eq "com1" ) {
> +        $xenhopt .=3D " com1=3D$c{Baud},8n1 console=3Dcom1,vga gdb=3Dcom=
1";
> +    } elsif ( $cons eq "dtuart" ) {
> +        $xenhopt .=3D " console=3Ddtuart";
> +        my $dtuart=3D get_host_property($ho, 'XenDTUARTPath', undef);
> +        $xenhopt .=3D " dtuart=3D$dtuart" if $dtuart;
> +    } else {
> +        logm("No Xen console device defined for host");
> +    }
> +    if (toolstack()->{Dom0MemFixed}) {
> +        $xenhopt .=3D " dom0_mem=3D512M,max:512M";
> +    }
> +    my $append=3D $r{xen_boot_append};
> +    $xenhopt .=3D " $append" if defined $append;
> +    $append =3D get_host_property($ho, 'xen-commandline-append', undef);
> +    $xenhopt .=3D " $append" if defined $append;
> +
> +    my @hooks;
> +
> +    if (host_involves_pcipassthrough($ho)) {
> +        push @hooks, {
> +            EditBootOptions =3D> sub {
> +                my ($ho,$hopt,$kopt) =3D @_;
> +                $$hopt .=3D ' iommu=3Don';
> +                my $hide=3D ' xen-pciback.hide=3D'. join '',map { "($_->=
{Bdf})" }
> +                    host_get_pcipassthrough_devs($ho);
> +                logm("pci passthrough: hiding in dom0: $hide");
> +                $$kopt .=3D $hide;
> +            }
> +        };
> +    }
> +
> +    return ($xenhopt,@hooks);
> +}
> +
>  #---------- stashed files ----------
> =20
>  sub open_unique_stashfile ($) {
> diff --git a/ts-bench-hostcmp-post b/ts-bench-hostcmp-post
> new file mode 100755
> index 0000000..26a67f4
> --- /dev/null
> +++ b/ts-bench-hostcmp-post
> @@ -0,0 +1,39 @@
> +#!/usr/bin/perl -w
> +# This is part of "osstest", an automated testing framework for Xen.
> +# Copyright (C) 2009-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 publish=
ed 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 Licen=
se
> +# 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) =3D @ARGV;
> +$whhost ||=3D 'host';
> +our $ho=3D selecthost($whhost);
> +
> +sub resetboot () {
> +  my ($xenhopt,@hooks)=3D host_bootxen_setup($ho);
> +  my $want_kernver =3D get_runvar('kernel_ver',$r{'kernbuildjob'});
> +
> +  debian_boot_setup($ho, $want_kernver, $xenhopt, undef, \@hooks);
> +
> +  logm("host reset to booting Xen");
> +}
> +
> +resetboot();
> diff --git a/ts-xen-install b/ts-xen-install
> index 4d34d1f..d8d38fc 100755
> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -134,43 +134,9 @@ sub adjustconfig () {
>  }
> =20
>  sub setupboot () {
> -    my $xenhopt=3D "conswitch=3Dx watchdog";
> -
> -    my $cons=3D get_host_property($ho, 'XenSerialConsole', 'com1');
> -
> -    if ( $cons eq "com1" ) {
> -	$xenhopt .=3D " com1=3D$c{Baud},8n1 console=3Dcom1,vga gdb=3Dcom1";
> -    } elsif ( $cons eq "dtuart" ) {
> -	$xenhopt .=3D " console=3Ddtuart";
> -	my $dtuart=3D get_host_property($ho, 'XenDTUARTPath', undef);
> -	$xenhopt .=3D " dtuart=3D$dtuart" if $dtuart;
> -    } else {
> -	logm("No Xen console device defined for host");
> -    }
> -    if (toolstack()->{Dom0MemFixed}) {
> -        $xenhopt .=3D " dom0_mem=3D512M,max:512M";
> -    }
> -    my $append=3D $r{xen_boot_append};
> -    $xenhopt .=3D " $append" if defined $append;
> -    $append =3D get_host_property($ho, 'xen-commandline-append', undef);
> -    $xenhopt .=3D " $append" if defined $append;
> -
> -    my @hooks;
> -
> -    if (host_involves_pcipassthrough($ho)) {
> -        push @hooks, {
> -            EditBootOptions =3D> sub {
> -                my ($ho,$hopt,$kopt) =3D @_;
> -                $$hopt .=3D ' iommu=3Don';
> -                my $hide=3D ' xen-pciback.hide=3D'. join '',map { "($_->=
{Bdf})" }
> -                    host_get_pcipassthrough_devs($ho);
> -                logm("pci passthrough: hiding in dom0: $hide");
> -                $$kopt .=3D $hide;
> -            }
> -        };
> -    }
> -
> +    my ($xenhopt,@hooks)=3D host_bootxen_setup($ho);
>      my $want_kernver =3D get_runvar('kernel_ver',$r{'kernbuildjob'});
> +
>      debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks)=
;
> =20
>      logm("ready to boot Xen");
>=20


--=-mj5Bzatkn3G6DdFouvO5
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

iEYEABECAAYFAlSJmgsACgkQk4XaBE3IOsTjFwCfYJnXscQVqSigC8mzi4wbud6k
53UAn0xilM5xjx843HfZHGdLY+tDfr6t
=HUkk
-----END PGP SIGNATURE-----

--=-mj5Bzatkn3G6DdFouvO5--



--===============6979308872276089674==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6979308872276089674==--



From xen-devel-bounces@lists.xen.org Thu Dec 11 13:20:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 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 1Xz3fU-0006f8-2s; Thu, 11 Dec 2014 13:20: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 1Xz3fS-0006eb-M8
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:20:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0C/FB-25276-E1A99845; Thu, 11 Dec 2014 13:20:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418304029!14955648!1
X-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 18206 invoked from network); 11 Dec 2014 13:20:29 -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 Dec 2014 13:20:29 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 13:20:29 +0000
Message-Id: <5489A82D020000780004EF86@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 13:20:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <54898449020000780004EDDD@mail.emea.novell.com>
	<20141211130026.GA53825@deinos.phlegethon.org>
	<5489A584020000780004EF49@mail.emea.novell.com>
	<20141211131617.GE53811@deinos.phlegethon.org>
In-Reply-To: <20141211131617.GE53811@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] x86: don't deliver NMI to PVH 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 11.12.14 at 14:16, <tim@xen.org> wrote:
> At 13:09 +0000 on 11 Dec (1418299748), Jan Beulich wrote:
>> >>> On 11.12.14 at 14:00, <tim@xen.org> wrote:
>> > At 10:47 +0000 on 11 Dec (1418291241), Jan Beulich wrote:
>> >> ... for the time being: The mechanism used depends on the domain's use
>> >> of the IRET hypercall.
>> > 
>> > Can you elaborate?  Looking at the existing code it seems like what it
>> > does is set v->nmi_pending and make sure the vcpu gets scheduled
>> > appropriately.
>> > 
>> > The HVM code will deliver an NMI if it sees v->nmi_pending (which is
>> > what vlapic_accept_irq does, for example).  Is there some other piece
>> > I'm missing?
>> 
>> Just so that others see the answer too: The problem is that the
>> temporary affinity adjustment gets undone in the HYPERVISOR_iret
>> handler, yet PVH can't call that hypercall.
> 
> Thanks.  So to make this work for PVH we'd want to do something like
> calling async_exception_cleanup() from vlapic_EOI_set()?

No, that's the wrong place - there's no EOI involved in ACK-ing an NMI.
Instead there ought to be (optional?) VM exits upon clearing of the
NMI masked state, and their handling code should presumably call that
function.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 13:20:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 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 1Xz3fU-0006f8-2s; Thu, 11 Dec 2014 13:20: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 1Xz3fS-0006eb-M8
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:20:30 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0C/FB-25276-E1A99845; Thu, 11 Dec 2014 13:20:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418304029!14955648!1
X-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 18206 invoked from network); 11 Dec 2014 13:20:29 -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 Dec 2014 13:20:29 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 13:20:29 +0000
Message-Id: <5489A82D020000780004EF86@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 13:20:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <54898449020000780004EDDD@mail.emea.novell.com>
	<20141211130026.GA53825@deinos.phlegethon.org>
	<5489A584020000780004EF49@mail.emea.novell.com>
	<20141211131617.GE53811@deinos.phlegethon.org>
In-Reply-To: <20141211131617.GE53811@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] x86: don't deliver NMI to PVH 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 11.12.14 at 14:16, <tim@xen.org> wrote:
> At 13:09 +0000 on 11 Dec (1418299748), Jan Beulich wrote:
>> >>> On 11.12.14 at 14:00, <tim@xen.org> wrote:
>> > At 10:47 +0000 on 11 Dec (1418291241), Jan Beulich wrote:
>> >> ... for the time being: The mechanism used depends on the domain's use
>> >> of the IRET hypercall.
>> > 
>> > Can you elaborate?  Looking at the existing code it seems like what it
>> > does is set v->nmi_pending and make sure the vcpu gets scheduled
>> > appropriately.
>> > 
>> > The HVM code will deliver an NMI if it sees v->nmi_pending (which is
>> > what vlapic_accept_irq does, for example).  Is there some other piece
>> > I'm missing?
>> 
>> Just so that others see the answer too: The problem is that the
>> temporary affinity adjustment gets undone in the HYPERVISOR_iret
>> handler, yet PVH can't call that hypercall.
> 
> Thanks.  So to make this work for PVH we'd want to do something like
> calling async_exception_cleanup() from vlapic_EOI_set()?

No, that's the wrong place - there's no EOI involved in ACK-ing an NMI.
Instead there ought to be (optional?) VM exits upon clearing of the
NMI masked state, and their handling code should presumably call that
function.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 13:23:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:23:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3ib-0007Go-Mh; Thu, 11 Dec 2014 13:23:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1Xz3iZ-0007GZ-NB
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:23:43 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	35/D3-18267-EDA99845; Thu, 11 Dec 2014 13:23:42 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418304221!12658542!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17332 invoked from network); 11 Dec 2014 13:23:42 -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;
	11 Dec 2014 13:23:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; 
	d="asc'?scan'208";a="202935330"
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.210.2;
	Thu, 11 Dec 2014 08:23:40 -0500
Message-ID: <1418304218.31647.104.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 11 Dec 2014 14:23:38 +0100
In-Reply-To: <20141211123258.GJ21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181152.26400.21301.stgit@Abyss.station>
	<20141211123258.GJ21659@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: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 22/27] ts-bench-hostcmp-host-prep: new script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5060965656687854609=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5060965656687854609==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-cNXjO09P35v7y3TW/jBT"

--=-cNXjO09P35v7y3TW/jBT
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-12-11 at 12:32 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 07:11:52PM +0100, Dario Faggioli wrote:

> > +  logm("Will run the benchmark on host with: $bcpus vcpus and $bmem MB=
 RAM");
> > +
> > +  my $kernver=3D get_runvar('kernel_ver',$r{'kernbuildjob'});
> > +  my $kopt=3D "maxcpus=3D$bcpus mem=3D$bmem" . "M";
> > +
> > +  if ($ho->{Flags}{'need-uboot-bootscr'}) {
> > +      $bl=3D setupboot_uboot($ho,$kernver,undef,$kopt);
> > +  } elsif ($ho->{Suite} =3D~ m/lenny/) {
> > +      $bl=3D setupboot_grub1($ho,$kernver,undef,$kopt);
> > +  } else {
> > +      $bl=3D setupboot_grub2($ho,$kernver,undef,$kopt);
> > +  }
> > +
> > +  $bootkern=3D $bl->{PreFinalUpdate}();
> > +  $bl->{UpdateConfig}($ho);
> > +
> > +  $bootkern=3D $bl->{GetBootKern}();
> > +  logm("$ho->{Name} will reboot on kernel $bootkern with '$kopt' as op=
tions");
>=20
> Can you refactor debian_setup_boot to achieve your goal?
>=20
This happens in patch 23, at least to some extent. :-)

BTW, that patch came out without a changelog, so sorry again for that.

I can see if I can merge the parts of these patches that play with
debian_setup_boot into something that makes sense for both this and the
other patch's purposes.

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)


--=-cNXjO09P35v7y3TW/jBT
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

iEYEABECAAYFAlSJmtoACgkQk4XaBE3IOsQ5EgCgqCqwsdSSu0U1B5wX6T+jZjkf
0FoAoK9fYuS7kKqZvhfXzPnVO+rG/uhU
=+AiI
-----END PGP SIGNATURE-----

--=-cNXjO09P35v7y3TW/jBT--


--===============5060965656687854609==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5060965656687854609==--


From xen-devel-bounces@lists.xen.org Thu Dec 11 13:23:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:23:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz3ib-0007Go-Mh; Thu, 11 Dec 2014 13:23:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1Xz3iZ-0007GZ-NB
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:23:43 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	35/D3-18267-EDA99845; Thu, 11 Dec 2014 13:23:42 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418304221!12658542!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17332 invoked from network); 11 Dec 2014 13:23:42 -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;
	11 Dec 2014 13:23:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; 
	d="asc'?scan'208";a="202935330"
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.210.2;
	Thu, 11 Dec 2014 08:23:40 -0500
Message-ID: <1418304218.31647.104.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 11 Dec 2014 14:23:38 +0100
In-Reply-To: <20141211123258.GJ21659@zion.uk.xensource.com>
References: <20141210180651.26400.13356.stgit@Abyss.station>
	<20141210181152.26400.21301.stgit@Abyss.station>
	<20141211123258.GJ21659@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: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 22/27] ts-bench-hostcmp-host-prep: new script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5060965656687854609=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5060965656687854609==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-cNXjO09P35v7y3TW/jBT"

--=-cNXjO09P35v7y3TW/jBT
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-12-11 at 12:32 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 07:11:52PM +0100, Dario Faggioli wrote:

> > +  logm("Will run the benchmark on host with: $bcpus vcpus and $bmem MB=
 RAM");
> > +
> > +  my $kernver=3D get_runvar('kernel_ver',$r{'kernbuildjob'});
> > +  my $kopt=3D "maxcpus=3D$bcpus mem=3D$bmem" . "M";
> > +
> > +  if ($ho->{Flags}{'need-uboot-bootscr'}) {
> > +      $bl=3D setupboot_uboot($ho,$kernver,undef,$kopt);
> > +  } elsif ($ho->{Suite} =3D~ m/lenny/) {
> > +      $bl=3D setupboot_grub1($ho,$kernver,undef,$kopt);
> > +  } else {
> > +      $bl=3D setupboot_grub2($ho,$kernver,undef,$kopt);
> > +  }
> > +
> > +  $bootkern=3D $bl->{PreFinalUpdate}();
> > +  $bl->{UpdateConfig}($ho);
> > +
> > +  $bootkern=3D $bl->{GetBootKern}();
> > +  logm("$ho->{Name} will reboot on kernel $bootkern with '$kopt' as op=
tions");
>=20
> Can you refactor debian_setup_boot to achieve your goal?
>=20
This happens in patch 23, at least to some extent. :-)

BTW, that patch came out without a changelog, so sorry again for that.

I can see if I can merge the parts of these patches that play with
debian_setup_boot into something that makes sense for both this and the
other patch's purposes.

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)


--=-cNXjO09P35v7y3TW/jBT
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

iEYEABECAAYFAlSJmtoACgkQk4XaBE3IOsQ5EgCgqCqwsdSSu0U1B5wX6T+jZjkf
0FoAoK9fYuS7kKqZvhfXzPnVO+rG/uhU
=+AiI
-----END PGP SIGNATURE-----

--=-cNXjO09P35v7y3TW/jBT--


--===============5060965656687854609==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5060965656687854609==--


From xen-devel-bounces@lists.xen.org Thu Dec 11 13:24:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13: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 1Xz3is-0007J8-5c; Thu, 11 Dec 2014 13:24:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xz3iq-0007Iz-Km
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:24:00 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	27/77-17958-FEA99845; Thu, 11 Dec 2014 13:23:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418304239!12643078!1
X-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 7929 invoked from network); 11 Dec 2014 13:23:59 -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; 11 Dec 2014 13:23:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 13:23:58 +0000
Message-Id: <5489A8FF020000780004EFA1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 13:23:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yu Zhang" <yu.c.zhang@linux.intel.com>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417838137-12473-3-git-send-email-yu.c.zhang@linux.intel.com>
	<20141211120450.GA53811@deinos.phlegethon.org>
In-Reply-To: <20141211120450.GA53811@deinos.phlegethon.org>
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 Deegan <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 v6 2/2] add a new p2m type -
	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 11.12.14 at 13:04, <tim@xen.org> wrote:
> At 11:55 +0800 on 06 Dec (1417863337), Yu Zhang wrote:
>> From: Yu Zhang <yu.c.zhang@intel.com>
>> 
>> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
>> the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
>> model, and will be discarded later in __hvm_copy(); while for the
>> p2m_mmio_write_dm type pages, writes will go to the device model
>> via ioreq-server.
>> 
>> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
>> Signed-off-by: Wei Ye <wei.ye@intel.com>
> 
> Sorry not to have seen this before, but it looks like the new type isn't
> handled in the shadow-pagetable code.  I think you need this as well:
> 
> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> index 225290e..58c0cca 100644
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -3181,7 +3181,8 @@ static int sh_page_fault(struct vcpu *v,
>      }
>  
>      /* Need to hand off device-model MMIO to the device model */
> -    if ( p2mt == p2m_mmio_dm ) 
> +    if ( p2mt == p2m_mmio_dm
> +         || p2mt == p2m_mmio_readonly && ft == ft_demand_write )
>      {
>          gpa = guest_walk_to_gpa(&gw);
>          goto mmio;
> 
> With that hunk added, you can add
> 
> Reviewed-by: Tim Deegan <tim@xen.org>

But please add parentheses around the && operands, even if not
strictly needed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 13:24:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13: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 1Xz3is-0007J8-5c; Thu, 11 Dec 2014 13:24:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xz3iq-0007Iz-Km
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 13:24:00 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	27/77-17958-FEA99845; Thu, 11 Dec 2014 13:23:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418304239!12643078!1
X-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 7929 invoked from network); 11 Dec 2014 13:23:59 -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; 11 Dec 2014 13:23:59 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 13:23:58 +0000
Message-Id: <5489A8FF020000780004EFA1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 13:23:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yu Zhang" <yu.c.zhang@linux.intel.com>
References: <1417838137-12473-1-git-send-email-yu.c.zhang@linux.intel.com>
	<1417838137-12473-3-git-send-email-yu.c.zhang@linux.intel.com>
	<20141211120450.GA53811@deinos.phlegethon.org>
In-Reply-To: <20141211120450.GA53811@deinos.phlegethon.org>
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 Deegan <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 v6 2/2] add a new p2m type -
	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 11.12.14 at 13:04, <tim@xen.org> wrote:
> At 11:55 +0800 on 06 Dec (1417863337), Yu Zhang wrote:
>> From: Yu Zhang <yu.c.zhang@intel.com>
>> 
>> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
>> the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
>> model, and will be discarded later in __hvm_copy(); while for the
>> p2m_mmio_write_dm type pages, writes will go to the device model
>> via ioreq-server.
>> 
>> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
>> Signed-off-by: Wei Ye <wei.ye@intel.com>
> 
> Sorry not to have seen this before, but it looks like the new type isn't
> handled in the shadow-pagetable code.  I think you need this as well:
> 
> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> index 225290e..58c0cca 100644
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -3181,7 +3181,8 @@ static int sh_page_fault(struct vcpu *v,
>      }
>  
>      /* Need to hand off device-model MMIO to the device model */
> -    if ( p2mt == p2m_mmio_dm ) 
> +    if ( p2mt == p2m_mmio_dm
> +         || p2mt == p2m_mmio_readonly && ft == ft_demand_write )
>      {
>          gpa = guest_walk_to_gpa(&gw);
>          goto mmio;
> 
> With that hunk added, you can add
> 
> Reviewed-by: Tim Deegan <tim@xen.org>

But please add parentheses around the && operands, even if not
strictly needed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 13:24:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13: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 1Xz3j6-0007MB-IP; Thu, 11 Dec 2014 13: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 1Xz3j5-0007Lr-Ds
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 13:24:15 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	B2/E1-02954-EFA99845; Thu, 11 Dec 2014 13:24:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418304252!14430148!1
X-Originating-IP: [66.165.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 22767 invoked from network); 11 Dec 2014 13:24:13 -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 Dec 2014 13:24:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203338223"
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.210.2; Thu, 11 Dec 2014 08:23: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 1Xz3ib-0006q1-Nf;
	Thu, 11 Dec 2014 13:23:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xz3ib-00036g-E2;
	Thu, 11 Dec 2014 13:23:45 +0000
Date: Thu, 11 Dec 2014 13:23:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32215-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] 32215: 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 32215 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32215/

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. 32126
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)  broken REGR. vs. 32126

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32126

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-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-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-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-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              ed675ad4193bc7f929e5b39074d50672970aefa3
baseline version:
 seabios              56b252ea737c1514916d6df4493f89ff71322f60

------------------------------------------------------------
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                          broken  
 test-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                           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)
broken-step test-amd64-i386-xl-qemuu-win7-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit ed675ad4193bc7f929e5b39074d50672970aefa3
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Wed Dec 3 12:53:01 2014 -0500

    Eliminate FUNCFSEG - only force portions of inline asm to f-segment
    
    The FUNCFSEG macro was introduced to force a C function into the
    f-segment.  This was needed for some C functions that used inline
    assembler that contained some 16bit code.  Instead of forcing the
    entire C function into the f-segment, just force the small subset of
    inline assembler into the f-segment.
    
    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

commit ff6d5519f2767b160d6f8e12f79d920dbf9872c6
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Wed Dec 3 12:39:28 2014 -0500

    Use macros for .code16/32 mode switches in inline asm in stacks.c
    
    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 Thu Dec 11 13:24:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13: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 1Xz3j6-0007MB-IP; Thu, 11 Dec 2014 13: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 1Xz3j5-0007Lr-Ds
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 13:24:15 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	B2/E1-02954-EFA99845; Thu, 11 Dec 2014 13:24:14 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418304252!14430148!1
X-Originating-IP: [66.165.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 22767 invoked from network); 11 Dec 2014 13:24:13 -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 Dec 2014 13:24:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,557,1413244800"; d="scan'208";a="203338223"
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.210.2; Thu, 11 Dec 2014 08:23: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 1Xz3ib-0006q1-Nf;
	Thu, 11 Dec 2014 13:23:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xz3ib-00036g-E2;
	Thu, 11 Dec 2014 13:23:45 +0000
Date: Thu, 11 Dec 2014 13:23:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32215-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] 32215: 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 32215 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32215/

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. 32126
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)  broken REGR. vs. 32126

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32126

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-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-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-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-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              ed675ad4193bc7f929e5b39074d50672970aefa3
baseline version:
 seabios              56b252ea737c1514916d6df4493f89ff71322f60

------------------------------------------------------------
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                          broken  
 test-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                           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)
broken-step test-amd64-i386-xl-qemuu-win7-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit ed675ad4193bc7f929e5b39074d50672970aefa3
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Wed Dec 3 12:53:01 2014 -0500

    Eliminate FUNCFSEG - only force portions of inline asm to f-segment
    
    The FUNCFSEG macro was introduced to force a C function into the
    f-segment.  This was needed for some C functions that used inline
    assembler that contained some 16bit code.  Instead of forcing the
    entire C function into the f-segment, just force the small subset of
    inline assembler into the f-segment.
    
    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

commit ff6d5519f2767b160d6f8e12f79d920dbf9872c6
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Wed Dec 3 12:39:28 2014 -0500

    Use macros for .code16/32 mode switches in inline asm in stacks.c
    
    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 Thu Dec 11 13:32:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13: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 1Xz3qZ-0007nZ-Ms; Thu, 11 Dec 2014 13:31:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xz3qY-0007n4-0f
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:31:58 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	E5/AD-03148-DCC99845; Thu, 11 Dec 2014 13:31:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418304716!14464460!1
X-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 27336 invoked from network); 11 Dec 2014 13:31:56 -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; 11 Dec 2014 13:31:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 13:31:55 +0000
Message-Id: <5489AADA020000780004EFB9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 13:31:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-2-git-send-email-mcgrof@do-not-panic.com>
In-Reply-To: <1418254487-9988-2-git-send-email-mcgrof@do-not-panic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Juergen Gross <JGross@suse.com>, peterz@infradead.org,
	Luis Rodriguez <Mcgrof@Suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, mingo@redhat.com, david.vrabel@citrix.com,
	hpa@zytor.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 1/2] sched: add cond_resched_irq()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.12.14 at 00:34, <mcgrof@do-not-panic.com> wrote:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4239,6 +4239,16 @@ int __sched _cond_resched(void)
>  }
>  EXPORT_SYMBOL(_cond_resched);
>  
> +int __sched cond_resched_irq(void)
> +{
> +	if (should_resched()) {
> +		preempt_schedule_irq();
> +		return 1;
> +	}
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(cond_resched_irq);

Do you really want to export to modules a symbol like this?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 13:32:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13: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 1Xz3qZ-0007nZ-Ms; Thu, 11 Dec 2014 13:31:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Xz3qY-0007n4-0f
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:31:58 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	E5/AD-03148-DCC99845; Thu, 11 Dec 2014 13:31:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418304716!14464460!1
X-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 27336 invoked from network); 11 Dec 2014 13:31:56 -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; 11 Dec 2014 13:31:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 13:31:55 +0000
Message-Id: <5489AADA020000780004EFB9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 13:31:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-2-git-send-email-mcgrof@do-not-panic.com>
In-Reply-To: <1418254487-9988-2-git-send-email-mcgrof@do-not-panic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Juergen Gross <JGross@suse.com>, peterz@infradead.org,
	Luis Rodriguez <Mcgrof@Suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, mingo@redhat.com, david.vrabel@citrix.com,
	hpa@zytor.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 1/2] sched: add cond_resched_irq()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.12.14 at 00:34, <mcgrof@do-not-panic.com> wrote:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4239,6 +4239,16 @@ int __sched _cond_resched(void)
>  }
>  EXPORT_SYMBOL(_cond_resched);
>  
> +int __sched cond_resched_irq(void)
> +{
> +	if (should_resched()) {
> +		preempt_schedule_irq();
> +		return 1;
> +	}
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(cond_resched_irq);

Do you really want to export to modules a symbol like this?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44Q-00005i-JQ; Thu, 11 Dec 2014 13:46:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1Xz44P-00005O-VN
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BD/9A-09842-920A9845; Thu, 11 Dec 2014 13:46:17 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418305572!14933026!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24617 invoked from network); 11 Dec 2014 13:46:14 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:46:14 -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 sBBDk2bo022179
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:46:03 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW8013088; Thu, 11 Dec 2014 08:46:00 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:37 +0100
Message-Id: <1418305541-5135-6-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 5/9] libxc: support XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 new xc_domain_devour() function to support XEN_DOMCTL_devour.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxc/include/xenctrl.h | 14 ++++++++++++++
 tools/libxc/xc_domain.c       | 13 +++++++++++++
 2 files changed, 27 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..a789de3 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -558,6 +558,20 @@ int xc_domain_unpause(xc_interface *xch,
 int xc_domain_destroy(xc_interface *xch,
                       uint32_t domid);
 
+/**
+ * This function sets a 'recipient' domain for a domain (when the source domain
+ * releases memory it is being reassigned to the recipient domain instead of
+ * being freed) and kills the original domain. The destination domain is supposed
+ * to have enough max_mem and no pages assigned.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the source domain id
+ * @parm recipient the destrination domain id
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_devour(xc_interface *xch,
+                     uint32_t domid, uint32_t recipient);
+
 
 /**
  * This function resumes a suspended domain. The domain should have
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index b864872..5949725 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -122,6 +122,19 @@ int xc_domain_destroy(xc_interface *xch,
     return ret;
 }
 
+int xc_domain_devour(xc_interface *xch, uint32_t domid, uint32_t recipient)
+{
+    int ret;
+    DECLARE_DOMCTL;
+    domctl.cmd = XEN_DOMCTL_devour;
+    domctl.domain = (domid_t)domid;
+    domctl.u.devour.recipient = (domid_t)recipient;
+    do {
+        ret = do_domctl(xch, &domctl);
+    } while ( ret && (errno == EAGAIN) );
+    return ret;
+}
+
 int xc_domain_shutdown(xc_interface *xch,
                        uint32_t domid,
                        int reason)
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44L-0008W0-6s; Thu, 11 Dec 2014 13:46: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 1Xz44J-0008VT-QB
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:12 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	12/53-11581-320A9845; Thu, 11 Dec 2014 13:46:11 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418305568!5238559!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8557 invoked from network); 11 Dec 2014 13:46:10 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:46:10 -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 sBBDjxin022155
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:45:59 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW7013088; Thu, 11 Dec 2014 08:45:56 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:36 +0100
Message-Id: <1418305541-5135-5-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

New operation sets the 'recipient' domain which will receive all
memory pages from a particular domain and kills the original domain.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/domain.c         |  3 +++
 xen/common/domctl.c         | 33 +++++++++++++++++++++++++++++++++
 xen/common/page_alloc.c     | 28 ++++++++++++++++++++++++----
 xen/include/public/domctl.h | 15 +++++++++++++++
 xen/include/xen/sched.h     |  2 ++
 5 files changed, 77 insertions(+), 4 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index c13a7cf..f26267a 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -825,6 +825,9 @@ static void complete_domain_destroy(struct rcu_head *head)
     if ( d->target != NULL )
         put_domain(d->target);
 
+    if ( d->recipient != NULL )
+        put_domain(d->recipient);
+
     evtchn_destroy_final(d);
 
     radix_tree_destroy(&d->pirq_tree, free_pirq_struct);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index f15dcfe..7e7fb47 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1177,6 +1177,39 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_devour:
+    {
+        struct domain *recipient_dom;
+
+        if ( !d->recipient )
+        {
+            recipient_dom = get_domain_by_id(op->u.devour.recipient);
+            if ( recipient_dom == NULL )
+            {
+                ret = -ESRCH;
+                break;
+            }
+
+            if ( recipient_dom->tot_pages != 0 )
+            {
+                put_domain(recipient_dom);
+                ret = -EINVAL;
+                break;
+            }
+            /*
+             * Make sure no allocation/remapping is ongoing and set is_dying
+             * flag to prevent such actions in future.
+             */
+            spin_lock(&d->page_alloc_lock);
+            d->is_dying = DOMDYING_locked;
+            d->recipient = recipient_dom;
+            smp_wmb(); /* make sure recipient was set before domain_kill() */
+            spin_unlock(&d->page_alloc_lock);
+        }
+        ret = domain_kill(d);
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 7b4092d..7eb4404 100644
--- 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,13 +1765,32 @@ 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);
+            if ( assign_pages(d->recipient, pg, order, 0) )
+                /* assign_pages reports the error by itself */
+                goto out;
+
+            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
+                printk(XENLOG_G_INFO
+                       "Failed to add MFN %lx (GFN %lx) to Dom%d's physmap\n",
+                       mfn, gmfn, d->recipient->domain_id);
+        }
     }
 
+out:
     if ( drop_dom_ref )
         put_domain(d);
 }
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 57e2ed7..871fa5e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -995,6 +995,19 @@ struct xen_domctl_psr_cmt_op {
 typedef struct xen_domctl_psr_cmt_op xen_domctl_psr_cmt_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cmt_op_t);
 
+/*
+ * XEN_DOMCTL_devour - kills the domain reassigning all of its domheap pages
+ * to the 'recipient' domain. Pages from xen heap belonging to the domain
+ * are not copied. Reassigned pages are mapped to the same GMFNs in the
+ * recipient domain as they were mapped in the original. The recipient domain
+ * is supposed to not have any domheap pages to avoid MFN-GMFN collisions.
+ */
+struct xen_domctl_devour {
+    domid_t recipient;
+};
+typedef struct xen_domctl_devour xen_domctl_devour_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_devour_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -1070,6 +1083,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_setvnumainfo                  74
 #define XEN_DOMCTL_psr_cmt_op                    75
 #define XEN_DOMCTL_arm_configure_domain          76
+#define XEN_DOMCTL_devour                        77
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1135,6 +1149,7 @@ struct xen_domctl {
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         struct xen_domctl_vnuma             vnuma;
         struct xen_domctl_psr_cmt_op        psr_cmt_op;
+        struct xen_domctl_devour            devour;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index a42d0b8..bbb0505 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -366,6 +366,8 @@ struct domain
     bool_t           is_privileged;
     /* Which guest this guest has privileges on */
     struct domain   *target;
+    /* Newly created guest which receives freed memory pages (soft reset) */
+    struct domain   *recipient;
     /* Is this guest being debugged by dom0? */
     bool_t           debugger_attached;
     /* Is this guest dying (i.e., a zombie)? */
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44I-0008VK-5X; Thu, 11 Dec 2014 13:46:10 +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 1Xz44H-0008VF-PX
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:09 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	AF/1C-02696-020A9845; Thu, 11 Dec 2014 13:46:08 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418305563!14454809!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20176 invoked from network); 11 Dec 2014 13:46:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:46:06 -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 sBBDjrl6008413
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:45:53 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW5013088; Thu, 11 Dec 2014 08:45:50 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:34 +0100
Message-Id: <1418305541-5135-3-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 2/9] xen: introduce SHUTDOWN_soft_reset
	shutdown reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/shutdown.c      | 7 +++++++
 xen/include/public/sched.h | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index 94d4c53..5c3a158 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -71,6 +71,13 @@ void hwdom_shutdown(u8 reason)
         break; /* not reached */
     }
 
+    case SHUTDOWN_soft_reset:
+    {
+        printk("Domain 0 did soft reset but it is unsupported, rebooting.\n");
+        machine_restart(0);
+        break; /* not reached */
+    }
+
     default:
     {
         printk("Domain 0 shutdown (unknown reason %u): ", reason);
diff --git a/xen/include/public/sched.h b/xen/include/public/sched.h
index 4000ac9..800c808 100644
--- a/xen/include/public/sched.h
+++ b/xen/include/public/sched.h
@@ -159,7 +159,8 @@ DEFINE_XEN_GUEST_HANDLE(sched_watchdog_t);
 #define SHUTDOWN_suspend    2  /* Clean up, save suspend info, kill.         */
 #define SHUTDOWN_crash      3  /* Tell controller we've crashed.             */
 #define SHUTDOWN_watchdog   4  /* Restart because watchdog time expired.     */
-#define SHUTDOWN_MAX        4  /* Maximum valid shutdown reason.             */
+#define SHUTDOWN_soft_reset 5  /* Soft reset, rebuild keeping memory content */
+#define SHUTDOWN_MAX        5  /* Maximum valid shutdown reason.             */
 /* ` } */
 
 #endif /* __XEN_PUBLIC_SCHED_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 Thu Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44K-0008Vn-Ru; Thu, 11 Dec 2014 13:46:12 +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 1Xz44J-0008VS-Bq
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D4/6A-09842-220A9845; Thu, 11 Dec 2014 13:46:10 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418305567!14607782!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17754 invoked from network); 11 Dec 2014 13:46:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:46:09 -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 sBBDjuOh023479
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:45:57 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW6013088; Thu, 11 Dec 2014 08:45:53 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:35 +0100
Message-Id: <1418305541-5135-4-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 3/9] libxl: support SHUTDOWN_soft_reset
	shutdown reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 letter 't' to indicate a domain in such state.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxl/libxl_types.idl       | 1 +
 tools/libxl/xl_cmdimpl.c          | 2 +-
 tools/python/xen/lowlevel/xl/xl.c | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..4a0e2be 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -175,6 +175,7 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
     (2, "suspend"),
     (3, "crash"),
     (4, "watchdog"),
+    (5, "soft_reset"),
     ], init_val = "LIBXL_SHUTDOWN_REASON_UNKNOWN")
 
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3737c7e..b193c3c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3506,7 +3506,7 @@ static void list_domains(int verbose, int context, int claim, int numa,
                          const libxl_dominfo *info, int nb_domain)
 {
     int i;
-    static const char shutdown_reason_letters[]= "-rscw";
+    static const char shutdown_reason_letters[]= "-rscwt";
     libxl_bitmap nodemap;
     libxl_physinfo physinfo;
 
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index 32f982a..7c61160 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -784,6 +784,7 @@ PyMODINIT_FUNC initxl(void)
     _INT_CONST_LIBXL(m, SHUTDOWN_REASON_SUSPEND);
     _INT_CONST_LIBXL(m, SHUTDOWN_REASON_CRASH);
     _INT_CONST_LIBXL(m, SHUTDOWN_REASON_WATCHDOG);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_SOFT_RESET);
 
     genwrap__init(m);
 }
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44K-0008Vg-HF; Thu, 11 Dec 2014 13:46:12 +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 1Xz44J-0008VP-6H
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:11 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	98/DE-20609-020A9845; Thu, 11 Dec 2014 13:46:08 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418305563!14454808!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20166 invoked from network); 11 Dec 2014 13:46:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:46:06 -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 sBBDjowq026650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:45:51 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW4013088; Thu, 11 Dec 2014 08:45:47 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:33 +0100
Message-Id: <1418305541-5135-2-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 1/9] xen: introduce DOMDYING_locked state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

New dying state is requred to indicate that a particular domain
is dying but cleanup procedure wasn't started. This state can be
set from outside of domain_kill().

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/domain.c     | 1 +
 xen/include/xen/sched.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 4a62c1d..c13a7cf 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -603,6 +603,7 @@ int domain_kill(struct domain *d)
     switch ( d->is_dying )
     {
     case DOMDYING_alive:
+    case DOMDYING_locked:
         domain_pause(d);
         d->is_dying = DOMDYING_dying;
         spin_barrier(&d->domain_lock);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 46fc6e3..a42d0b8 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -369,7 +369,8 @@ struct domain
     /* Is this guest being debugged by dom0? */
     bool_t           debugger_attached;
     /* Is this guest dying (i.e., a zombie)? */
-    enum { DOMDYING_alive, DOMDYING_dying, DOMDYING_dead } is_dying;
+    enum { DOMDYING_alive, DOMDYING_locked, DOMDYING_dying, DOMDYING_dead }
+        is_dying;
     /* Domain is paused by controller software? */
     int              controller_pause_count;
     /* Domain's VCPUs are pinned 1:1 to physical CPUs? */
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44Z-0000Bi-Ve; Thu, 11 Dec 2014 13:46:27 +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 1Xz44Y-0000AI-8Y
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:26 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	51/98-02697-130A9845; Thu, 11 Dec 2014 13:46:25 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418305583!9469474!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2628 invoked from network); 11 Dec 2014 13:46:24 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Dec 2014 13:46:24 -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 sBBDkFB6026782
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:46:15 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgWC013088; Thu, 11 Dec 2014 08:46:12 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:41 +0100
Message-Id: <1418305541-5135-10-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 9/9] xsm: add XEN_DOMCTL_devour support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/domctl.c                 |  6 ++++++
 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 ++++++++++
 6 files changed, 46 insertions(+)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 7e7fb47..7c22e35 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1190,6 +1190,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                 break;
             }
 
+            ret = xsm_devour(XSM_HOOK, d, recipient_dom);
+            if ( ret ) {
+                put_domain(recipient_dom);
+                break;
+            }
+
             if ( recipient_dom->tot_pages != 0 )
             {
                 put_domain(recipient_dom);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f20e89c..6e9e38b 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -113,6 +113,12 @@ static XSM_INLINE int xsm_set_target(XSM_DEFAULT_ARG struct domain *d, struct do
     return xsm_default_action(action, current->domain, NULL);
 }
 
+static XSM_INLINE int xsm_devour(XSM_DEFAULT_ARG struct domain *d, struct domain *e)
+{
+    XSM_ASSERT_ACTION(XSM_HOOK);
+    return xsm_default_action(action, current->domain, NULL);
+}
+
 static XSM_INLINE int xsm_domctl(XSM_DEFAULT_ARG struct domain *d, int cmd)
 {
     XSM_ASSERT_ACTION(XSM_OTHER);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4ce089f..7db7433 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -58,6 +58,7 @@ struct xsm_operations {
     int (*domctl_scheduler_op) (struct domain *d, int op);
     int (*sysctl_scheduler_op) (int op);
     int (*set_target) (struct domain *d, struct domain *e);
+    int (*devour) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
     int (*sysctl) (int cmd);
     int (*readconsole) (uint32_t clear);
@@ -213,6 +214,11 @@ static inline int xsm_set_target (xsm_default_t def, struct domain *d, struct do
     return xsm_ops->set_target(d, e);
 }
 
+static inline int xsm_devour (xsm_default_t def, struct domain *d, struct domain *r)
+{
+    return xsm_ops->devour(d, r);
+}
+
 static inline int xsm_domctl (xsm_default_t def, struct domain *d, int cmd)
 {
     return xsm_ops->domctl(d, cmd);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 8eb3050..f3c2f9e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -35,6 +35,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domctl_scheduler_op);
     set_to_dummy_if_null(ops, sysctl_scheduler_op);
     set_to_dummy_if_null(ops, set_target);
+    set_to_dummy_if_null(ops, devour);
     set_to_dummy_if_null(ops, domctl);
     set_to_dummy_if_null(ops, sysctl);
     set_to_dummy_if_null(ops, readconsole);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d48463f..097c8c2 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -565,6 +565,21 @@ static int flask_set_target(struct domain *d, struct domain *t)
     return rc;
 }
 
+static int flask_devour(struct domain *d, struct domain *r)
+{
+    int rc;
+    struct domain_security_struct *dsec, *rsec;
+    dsec = d->ssid;
+    rsec = r->ssid;
+
+    rc = current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_SOURCE);
+    if ( rc )
+        return rc;
+    if ( r )
+        rc = current_has_perm(r, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_RECIPIENT);
+    return rc;
+}
+
 static int flask_domctl(struct domain *d, int cmd)
 {
     switch ( cmd )
@@ -580,6 +595,7 @@ static int flask_domctl(struct domain *d, int cmd)
 #ifdef HAS_MEM_ACCESS
     case XEN_DOMCTL_mem_event_op:
 #endif
+    case XEN_DOMCTL_devour:
 #ifdef CONFIG_X86
     /* These have individual XSM hooks (arch/x86/domctl.c) */
     case XEN_DOMCTL_shadow_op:
@@ -1512,6 +1528,7 @@ static struct xsm_operations flask_ops = {
     .domctl_scheduler_op = flask_domctl_scheduler_op,
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
     .set_target = flask_set_target,
+    .devour = flask_devour,
     .domctl = flask_domctl,
     .sysctl = flask_sysctl,
     .readconsole = flask_readconsole,
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 1da9f63..64c3424 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -142,6 +142,8 @@ class domain
 #  target = the new target domain
 # see also the domain2 make_priv_for and set_as_target checks
     set_target
+# XEN_DOMCTL_devour
+    devour
 # SCHEDOP_remote_shutdown
     shutdown
 # XEN_DOMCTL_set{,_machine}_address_size
@@ -196,6 +198,14 @@ class domain2
 #  source = the domain making the hypercall
 #  target = the new target domain
     set_as_target
+# checked in XEN_DOMCTL_devour:
+#  source = the domain making the hypercall
+#  target = the new source domain
+    set_as_source
+# checked in XEN_DOMCTL_devour:
+#  source = the domain making the hypercall
+#  target = the new recipient domain
+    set_as_recipient
 # XEN_DOMCTL_set_cpuid
     set_cpuid
 # XEN_DOMCTL_gettscinfo
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44K-0008Vn-Ru; Thu, 11 Dec 2014 13:46:12 +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 1Xz44J-0008VS-Bq
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:11 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	D4/6A-09842-220A9845; Thu, 11 Dec 2014 13:46:10 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418305567!14607782!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17754 invoked from network); 11 Dec 2014 13:46:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:46:09 -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 sBBDjuOh023479
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:45:57 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW6013088; Thu, 11 Dec 2014 08:45:53 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:35 +0100
Message-Id: <1418305541-5135-4-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 3/9] libxl: support SHUTDOWN_soft_reset
	shutdown reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 letter 't' to indicate a domain in such state.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxl/libxl_types.idl       | 1 +
 tools/libxl/xl_cmdimpl.c          | 2 +-
 tools/python/xen/lowlevel/xl/xl.c | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..4a0e2be 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -175,6 +175,7 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
     (2, "suspend"),
     (3, "crash"),
     (4, "watchdog"),
+    (5, "soft_reset"),
     ], init_val = "LIBXL_SHUTDOWN_REASON_UNKNOWN")
 
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3737c7e..b193c3c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3506,7 +3506,7 @@ static void list_domains(int verbose, int context, int claim, int numa,
                          const libxl_dominfo *info, int nb_domain)
 {
     int i;
-    static const char shutdown_reason_letters[]= "-rscw";
+    static const char shutdown_reason_letters[]= "-rscwt";
     libxl_bitmap nodemap;
     libxl_physinfo physinfo;
 
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index 32f982a..7c61160 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -784,6 +784,7 @@ PyMODINIT_FUNC initxl(void)
     _INT_CONST_LIBXL(m, SHUTDOWN_REASON_SUSPEND);
     _INT_CONST_LIBXL(m, SHUTDOWN_REASON_CRASH);
     _INT_CONST_LIBXL(m, SHUTDOWN_REASON_WATCHDOG);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_SOFT_RESET);
 
     genwrap__init(m);
 }
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44I-0008VK-5X; Thu, 11 Dec 2014 13:46:10 +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 1Xz44H-0008VF-PX
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:09 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	AF/1C-02696-020A9845; Thu, 11 Dec 2014 13:46:08 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418305563!14454809!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20176 invoked from network); 11 Dec 2014 13:46:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:46:06 -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 sBBDjrl6008413
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:45:53 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW5013088; Thu, 11 Dec 2014 08:45:50 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:34 +0100
Message-Id: <1418305541-5135-3-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 2/9] xen: introduce SHUTDOWN_soft_reset
	shutdown reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/shutdown.c      | 7 +++++++
 xen/include/public/sched.h | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index 94d4c53..5c3a158 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -71,6 +71,13 @@ void hwdom_shutdown(u8 reason)
         break; /* not reached */
     }
 
+    case SHUTDOWN_soft_reset:
+    {
+        printk("Domain 0 did soft reset but it is unsupported, rebooting.\n");
+        machine_restart(0);
+        break; /* not reached */
+    }
+
     default:
     {
         printk("Domain 0 shutdown (unknown reason %u): ", reason);
diff --git a/xen/include/public/sched.h b/xen/include/public/sched.h
index 4000ac9..800c808 100644
--- a/xen/include/public/sched.h
+++ b/xen/include/public/sched.h
@@ -159,7 +159,8 @@ DEFINE_XEN_GUEST_HANDLE(sched_watchdog_t);
 #define SHUTDOWN_suspend    2  /* Clean up, save suspend info, kill.         */
 #define SHUTDOWN_crash      3  /* Tell controller we've crashed.             */
 #define SHUTDOWN_watchdog   4  /* Restart because watchdog time expired.     */
-#define SHUTDOWN_MAX        4  /* Maximum valid shutdown reason.             */
+#define SHUTDOWN_soft_reset 5  /* Soft reset, rebuild keeping memory content */
+#define SHUTDOWN_MAX        5  /* Maximum valid shutdown reason.             */
 /* ` } */
 
 #endif /* __XEN_PUBLIC_SCHED_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 Thu Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44V-00008t-Hp; Thu, 11 Dec 2014 13:46:23 +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 1Xz44T-00006t-EO
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:21 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	12/47-16982-C20A9845; Thu, 11 Dec 2014 13:46:20 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418305577!10203619!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7155 invoked from network); 11 Dec 2014 13:46:19 -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; 11 Dec 2014 13:46:19 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBBDk9T2026745
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:46:09 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgWA013088; Thu, 11 Dec 2014 08:46:06 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:39 +0100
Message-Id: <1418305541-5135-8-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 7/9] libxc: introduce soft reset for 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>
MIME-Version: 1.0
Content-Type: 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 new xc_domain_soft_reset() function which performs so-called 'soft reset'
for an HVM domain. It is being performed in the following way:
- Save HVM context and all HVM params;
- Devour original domain with XEN_DOMCTL_devour;
- Wait till original domain dies or has no pages left;
- Restore HVM context, HVM params, seed grant table.

After that the domain resumes execution from where SHUTDOWN_soft_reset was
called.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxc/Makefile               |   1 +
 tools/libxc/include/xenguest.h     |  20 +++
 tools/libxc/xc_domain_soft_reset.c | 282 +++++++++++++++++++++++++++++++++++++
 3 files changed, 303 insertions(+)
 create mode 100644 tools/libxc/xc_domain_soft_reset.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index bd2ca6c..8f8abd6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -52,6 +52,7 @@ GUEST_SRCS-y += xc_offline_page.c xc_compression.c
 else
 GUEST_SRCS-y += xc_nomigrate.c
 endif
+GUEST_SRCS-y += xc_domain_soft_reset.c
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 40bbac8..770cd10 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -131,6 +131,26 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
  * of the new domain is automatically appended to the filename,
  * separated by a ".".
  */
+
+/**
+ * This function does soft reset for a domain. During soft reset all
+ * source domain's memory is being reassigned to the destination domain,
+ * HVM context and HVM params are being copied.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm source_dom the id of the source domain
+ * @parm dest_dom the id of the destination domain
+ * @parm console_domid the id of the domain handling console
+ * @parm console_mfn returned with the mfn of the console page
+ * @parm store_domid the id of the domain handling store
+ * @parm store_mfn returned with the mfn of the store page
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_soft_reset(xc_interface *xch, uint32_t source_dom,
+                         uint32_t dest_dom, domid_t console_domid,
+                         unsigned long *console_mfn, domid_t store_domid,
+                         unsigned long *store_mfn);
+
 #define XC_DEVICE_MODEL_RESTORE_FILE "/var/lib/xen/qemu-resume"
 
 /**
diff --git a/tools/libxc/xc_domain_soft_reset.c b/tools/libxc/xc_domain_soft_reset.c
new file mode 100644
index 0000000..24d0b48
--- /dev/null
+++ b/tools/libxc/xc_domain_soft_reset.c
@@ -0,0 +1,282 @@
+/******************************************************************************
+ * xc_domain_soft_reset.c
+ *
+ * Do soft reset.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <inttypes.h>
+#include <time.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <sys/time.h>
+
+#include "xc_private.h"
+#include "xc_core.h"
+#include "xc_bitops.h"
+#include "xc_dom.h"
+#include "xg_private.h"
+#include "xg_save_restore.h"
+
+#include <xen/hvm/params.h>
+
+#define SLEEP_INT 1
+
+int xc_domain_soft_reset(xc_interface *xch, uint32_t source_dom,
+                         uint32_t dest_dom, domid_t console_domid,
+                         unsigned long *console_mfn, domid_t store_domid,
+                         unsigned long *store_mfn)
+{
+    xc_dominfo_t old_info, new_info;
+    int rc = 1;
+
+    uint32_t hvm_buf_size = 0;
+    uint8_t *hvm_buf = NULL;
+    unsigned long console_pfn, store_pfn, io_pfn, buffio_pfn;
+    unsigned long max_gpfn;
+    uint64_t hvm_params[HVM_NR_PARAMS];
+    xen_pfn_t sharedinfo_pfn;
+
+    DPRINTF("%s: soft reset domid %u -> %u", __func__, source_dom, dest_dom);
+
+    if ( xc_domain_getinfo(xch, source_dom, 1, &old_info) != 1 )
+    {
+        PERROR("Could not get old domain info");
+        return 1;
+    }
+
+    if ( xc_domain_getinfo(xch, dest_dom, 1, &new_info) != 1 )
+    {
+        PERROR("Could not get new domain info");
+        return 1;
+    }
+
+    if ( !old_info.hvm || !new_info.hvm )
+    {
+        PERROR("Soft reset is supported for HVM only");
+        return 1;
+    }
+
+    max_gpfn = xc_domain_maximum_gpfn(xch, source_dom);
+
+    sharedinfo_pfn = old_info.shared_info_frame;
+    if ( xc_get_pfn_type_batch(xch, source_dom, 1, &sharedinfo_pfn) )
+    {
+        PERROR("xc_get_pfn_type_batch failed");
+        goto out;
+    }
+
+    hvm_buf_size = xc_domain_hvm_getcontext(xch, source_dom, 0, 0);
+    if ( hvm_buf_size == -1 )
+    {
+        PERROR("Couldn't get HVM context size from Xen");
+        goto out;
+    }
+
+    hvm_buf = malloc(hvm_buf_size);
+    if ( !hvm_buf )
+    {
+        ERROR("Couldn't allocate memory");
+        goto out;
+    }
+
+    if ( xc_domain_hvm_getcontext(xch, source_dom, hvm_buf,
+                                  hvm_buf_size) == -1 )
+    {
+        PERROR("HVM:Could not get hvm buffer");
+        goto out;
+    }
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_STORE_PFN,
+                     &hvm_params[HVM_PARAM_STORE_PFN]);
+    store_pfn = hvm_params[HVM_PARAM_STORE_PFN];
+    *store_mfn = store_pfn;
+
+    xc_hvm_param_get(xch, source_dom,
+                     HVM_PARAM_CONSOLE_PFN,
+                     &hvm_params[HVM_PARAM_CONSOLE_PFN]);
+    console_pfn = hvm_params[HVM_PARAM_CONSOLE_PFN];
+    *console_mfn = console_pfn;
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_BUFIOREQ_PFN,
+                     &hvm_params[HVM_PARAM_BUFIOREQ_PFN]);
+    buffio_pfn = hvm_params[HVM_PARAM_BUFIOREQ_PFN];
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_IOREQ_PFN,
+                     &hvm_params[HVM_PARAM_IOREQ_PFN]);
+    io_pfn = hvm_params[HVM_PARAM_IOREQ_PFN];
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_IDENT_PT,
+                     &hvm_params[HVM_PARAM_IDENT_PT]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_PAGING_RING_PFN,
+                     &hvm_params[HVM_PARAM_PAGING_RING_PFN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_ACCESS_RING_PFN,
+                     &hvm_params[HVM_PARAM_ACCESS_RING_PFN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_VM86_TSS,
+                     &hvm_params[HVM_PARAM_VM86_TSS]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_ACPI_IOPORTS_LOCATION,
+                     &hvm_params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_VIRIDIAN,
+                     &hvm_params[HVM_PARAM_VIRIDIAN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_PAE_ENABLED,
+                     &hvm_params[HVM_PARAM_PAE_ENABLED]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_STORE_EVTCHN,
+                     &hvm_params[HVM_PARAM_STORE_EVTCHN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_IOREQ_SERVER_PFN,
+                     &hvm_params[HVM_PARAM_IOREQ_SERVER_PFN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
+                     &hvm_params[HVM_PARAM_NR_IOREQ_SERVER_PAGES]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
+                     &hvm_params[HVM_PARAM_VM_GENERATION_ID_ADDR]);
+
+    rc = xc_domain_devour(xch, source_dom, dest_dom);
+    if ( rc != 0 )
+    {
+        PERROR("failed to devour original domain, rc=%d\n", rc);
+        goto out;
+    }
+
+    while ( 1 )
+    {
+        sleep(SLEEP_INT);
+        if ( xc_get_tot_pages(xch, source_dom) <= 0 )
+        {
+            DPRINTF("All pages were transferred");
+            break;
+        }
+    }
+
+
+    if ( sharedinfo_pfn == XEN_DOMCTL_PFINFO_XTAB)
+    {
+        /*
+         * Shared info frame is being removed when guest maps shared info so
+         * this page is likely XEN_DOMCTL_PFINFO_XTAB but we need to replace
+         * it with an empty page in that case.
+         */
+
+        if ( xc_domain_populate_physmap_exact(xch, dest_dom, 1, 0, 0,
+                                              &old_info.shared_info_frame) )
+        {
+            PERROR("failed to populate pfn %lx (shared info)", old_info.shared_info_frame);
+            goto out;
+        }
+    }
+
+    if ( xc_domain_hvm_setcontext(xch, dest_dom, hvm_buf,
+                                  hvm_buf_size) == -1 )
+    {
+        PERROR("HVM:Could not set hvm buffer");
+        goto out;
+    }
+
+    if ( store_pfn )
+        xc_clear_domain_page(xch, dest_dom, store_pfn);
+
+    if ( console_pfn )
+        xc_clear_domain_page(xch, dest_dom, console_pfn);
+
+    if ( buffio_pfn )
+        xc_clear_domain_page(xch, dest_dom, buffio_pfn);
+
+    if ( io_pfn )
+        xc_clear_domain_page(xch, dest_dom, io_pfn);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_STORE_PFN,
+                     hvm_params[HVM_PARAM_STORE_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom,
+                     HVM_PARAM_CONSOLE_PFN,
+                     hvm_params[HVM_PARAM_CONSOLE_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_BUFIOREQ_PFN,
+                     hvm_params[HVM_PARAM_BUFIOREQ_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_IOREQ_PFN,
+                     hvm_params[HVM_PARAM_IOREQ_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_IDENT_PT,
+                     hvm_params[HVM_PARAM_IDENT_PT]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_PAGING_RING_PFN,
+                     hvm_params[HVM_PARAM_PAGING_RING_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_ACCESS_RING_PFN,
+                     hvm_params[HVM_PARAM_ACCESS_RING_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_VM86_TSS,
+                     hvm_params[HVM_PARAM_VM86_TSS]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_ACPI_IOPORTS_LOCATION,
+                     hvm_params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_VIRIDIAN,
+                     hvm_params[HVM_PARAM_VIRIDIAN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_PAE_ENABLED,
+                     hvm_params[HVM_PARAM_PAE_ENABLED]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_STORE_EVTCHN,
+                     hvm_params[HVM_PARAM_STORE_EVTCHN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_IOREQ_SERVER_PFN,
+                     hvm_params[HVM_PARAM_IOREQ_SERVER_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
+                     hvm_params[HVM_PARAM_NR_IOREQ_SERVER_PAGES]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
+                     hvm_params[HVM_PARAM_VM_GENERATION_ID_ADDR]);
+
+    if (xc_dom_gnttab_hvm_seed(xch, dest_dom, console_pfn, store_pfn,
+                               console_domid, store_domid))
+    {
+        PERROR("error seeding hvm grant table");
+        goto out;
+    }
+
+    rc = 0;
+out:
+    if (hvm_buf) free(hvm_buf);
+
+    if ( (rc != 0) && (dest_dom != 0) ) {
+            PERROR("Faled to perform soft reset, destroying domain %d",
+                   dest_dom);
+	    xc_domain_destroy(xch, dest_dom);
+    }
+
+    return !!rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44U-00007O-0W; Thu, 11 Dec 2014 13:46:22 +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 1Xz44S-00006C-86
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:20 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	3B/63-02957-B20A9845; Thu, 11 Dec 2014 13:46:19 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418305575!14429413!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3522 invoked from network); 11 Dec 2014 13:46:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:46:18 -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 sBBDk64L023536
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:46:06 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW9013088; Thu, 11 Dec 2014 08:46:03 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:38 +0100
Message-Id: <1418305541-5135-7-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 6/9] libxl: add
	libxl__domain_soft_reset_destroy()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

New libxl__domain_soft_reset_destroy() is an internal-only
version of libxl_domain_destroy() which follows the same domain
destroy path with the only difference: xc_domain_destroy() is
being avoided so the domain is not actually being destroyed.

Add soft_reset flag to libxl__domain_destroy_state structure
to support the change.

The original libxl_domain_destroy() function could be easily
modified to support new flag but I'm trying to avoid that as
it is part of public API.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxl/libxl.c          | 33 ++++++++++++++++++++++++++++-----
 tools/libxl/libxl_internal.h |  4 ++++
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 74c00dc..a232db1 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1444,6 +1444,24 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
     return AO_INPROGRESS;
 }
 
+int libxl__domain_soft_reset_destroy(libxl__gc *gc_in, uint32_t domid,
+                                     const libxl_asyncop_how *ao_how)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc_in);
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__domain_destroy_state *dds;
+
+    GCNEW(dds);
+    dds->ao = ao;
+    dds->domid = domid;
+    dds->callback = domain_destroy_cb;
+    dds->soft_reset = 1;
+    libxl__domain_destroy(egc, dds);
+
+    return AO_INPROGRESS;
+}
+
+
 static void domain_destroy_cb(libxl__egc *egc, libxl__domain_destroy_state *dds,
                               int rc)
 {
@@ -1619,6 +1637,7 @@ static void devices_destroy_cb(libxl__egc *egc,
 {
     STATE_AO_GC(drs->ao);
     libxl__destroy_domid_state *dis = CONTAINER_OF(drs, *dis, drs);
+    libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, domain);
     libxl_ctx *ctx = CTX;
     uint32_t domid = dis->domid;
     char *dom_path;
@@ -1657,11 +1676,15 @@ static void devices_destroy_cb(libxl__egc *egc,
     }
     libxl__userdata_destroyall(gc, domid);
 
-    rc = xc_domain_destroy(ctx->xch, domid);
-    if (rc < 0) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_destroy failed for %d", domid);
-        rc = ERROR_FAIL;
-        goto out;
+    if (!dds->soft_reset)
+    {
+        rc = xc_domain_destroy(ctx->xch, domid);
+        if (rc < 0) {
+            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
+                                "xc_domain_destroy failed for %d", domid);
+            rc = ERROR_FAIL;
+            goto out;
+        }
     }
     rc = 0;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a38f695..d58f08a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2969,6 +2969,7 @@ struct libxl__domain_destroy_state {
     int stubdom_finished;
     libxl__destroy_domid_state domain;
     int domain_finished;
+    int soft_reset;
 };
 
 /*
@@ -3132,6 +3133,9 @@ _hidden void libxl__domain_save_device_model(libxl__egc *egc,
 
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 
+_hidden int libxl__domain_soft_reset_destroy(libxl__gc *gc, uint32_t domid,
+                                             const libxl_asyncop_how *ao_how);
+
 
 /*
  * Convenience macros.
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44U-00007O-0W; Thu, 11 Dec 2014 13:46:22 +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 1Xz44S-00006C-86
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:20 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	3B/63-02957-B20A9845; Thu, 11 Dec 2014 13:46:19 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418305575!14429413!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3522 invoked from network); 11 Dec 2014 13:46:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:46:18 -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 sBBDk64L023536
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:46:06 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW9013088; Thu, 11 Dec 2014 08:46:03 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:38 +0100
Message-Id: <1418305541-5135-7-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 6/9] libxl: add
	libxl__domain_soft_reset_destroy()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

New libxl__domain_soft_reset_destroy() is an internal-only
version of libxl_domain_destroy() which follows the same domain
destroy path with the only difference: xc_domain_destroy() is
being avoided so the domain is not actually being destroyed.

Add soft_reset flag to libxl__domain_destroy_state structure
to support the change.

The original libxl_domain_destroy() function could be easily
modified to support new flag but I'm trying to avoid that as
it is part of public API.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxl/libxl.c          | 33 ++++++++++++++++++++++++++++-----
 tools/libxl/libxl_internal.h |  4 ++++
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 74c00dc..a232db1 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1444,6 +1444,24 @@ int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
     return AO_INPROGRESS;
 }
 
+int libxl__domain_soft_reset_destroy(libxl__gc *gc_in, uint32_t domid,
+                                     const libxl_asyncop_how *ao_how)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc_in);
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__domain_destroy_state *dds;
+
+    GCNEW(dds);
+    dds->ao = ao;
+    dds->domid = domid;
+    dds->callback = domain_destroy_cb;
+    dds->soft_reset = 1;
+    libxl__domain_destroy(egc, dds);
+
+    return AO_INPROGRESS;
+}
+
+
 static void domain_destroy_cb(libxl__egc *egc, libxl__domain_destroy_state *dds,
                               int rc)
 {
@@ -1619,6 +1637,7 @@ static void devices_destroy_cb(libxl__egc *egc,
 {
     STATE_AO_GC(drs->ao);
     libxl__destroy_domid_state *dis = CONTAINER_OF(drs, *dis, drs);
+    libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, domain);
     libxl_ctx *ctx = CTX;
     uint32_t domid = dis->domid;
     char *dom_path;
@@ -1657,11 +1676,15 @@ static void devices_destroy_cb(libxl__egc *egc,
     }
     libxl__userdata_destroyall(gc, domid);
 
-    rc = xc_domain_destroy(ctx->xch, domid);
-    if (rc < 0) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_destroy failed for %d", domid);
-        rc = ERROR_FAIL;
-        goto out;
+    if (!dds->soft_reset)
+    {
+        rc = xc_domain_destroy(ctx->xch, domid);
+        if (rc < 0) {
+            LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
+                                "xc_domain_destroy failed for %d", domid);
+            rc = ERROR_FAIL;
+            goto out;
+        }
     }
     rc = 0;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a38f695..d58f08a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2969,6 +2969,7 @@ struct libxl__domain_destroy_state {
     int stubdom_finished;
     libxl__destroy_domid_state domain;
     int domain_finished;
+    int soft_reset;
 };
 
 /*
@@ -3132,6 +3133,9 @@ _hidden void libxl__domain_save_device_model(libxl__egc *egc,
 
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 
+_hidden int libxl__domain_soft_reset_destroy(libxl__gc *gc, uint32_t domid,
+                                             const libxl_asyncop_how *ao_how);
+
 
 /*
  * Convenience macros.
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44K-0008Vg-HF; Thu, 11 Dec 2014 13:46:12 +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 1Xz44J-0008VP-6H
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:11 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	98/DE-20609-020A9845; Thu, 11 Dec 2014 13:46:08 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418305563!14454808!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20166 invoked from network); 11 Dec 2014 13:46:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:46:06 -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 sBBDjowq026650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:45:51 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW4013088; Thu, 11 Dec 2014 08:45:47 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:33 +0100
Message-Id: <1418305541-5135-2-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 1/9] xen: introduce DOMDYING_locked state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

New dying state is requred to indicate that a particular domain
is dying but cleanup procedure wasn't started. This state can be
set from outside of domain_kill().

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/domain.c     | 1 +
 xen/include/xen/sched.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 4a62c1d..c13a7cf 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -603,6 +603,7 @@ int domain_kill(struct domain *d)
     switch ( d->is_dying )
     {
     case DOMDYING_alive:
+    case DOMDYING_locked:
         domain_pause(d);
         d->is_dying = DOMDYING_dying;
         spin_barrier(&d->domain_lock);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 46fc6e3..a42d0b8 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -369,7 +369,8 @@ struct domain
     /* Is this guest being debugged by dom0? */
     bool_t           debugger_attached;
     /* Is this guest dying (i.e., a zombie)? */
-    enum { DOMDYING_alive, DOMDYING_dying, DOMDYING_dead } is_dying;
+    enum { DOMDYING_alive, DOMDYING_locked, DOMDYING_dying, DOMDYING_dead }
+        is_dying;
     /* Domain is paused by controller software? */
     int              controller_pause_count;
     /* Domain's VCPUs are pinned 1:1 to physical CPUs? */
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44V-00008t-Hp; Thu, 11 Dec 2014 13:46:23 +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 1Xz44T-00006t-EO
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:21 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	12/47-16982-C20A9845; Thu, 11 Dec 2014 13:46:20 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418305577!10203619!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7155 invoked from network); 11 Dec 2014 13:46:19 -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; 11 Dec 2014 13:46:19 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBBDk9T2026745
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:46:09 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgWA013088; Thu, 11 Dec 2014 08:46:06 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:39 +0100
Message-Id: <1418305541-5135-8-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 7/9] libxc: introduce soft reset for 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>
MIME-Version: 1.0
Content-Type: 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 new xc_domain_soft_reset() function which performs so-called 'soft reset'
for an HVM domain. It is being performed in the following way:
- Save HVM context and all HVM params;
- Devour original domain with XEN_DOMCTL_devour;
- Wait till original domain dies or has no pages left;
- Restore HVM context, HVM params, seed grant table.

After that the domain resumes execution from where SHUTDOWN_soft_reset was
called.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxc/Makefile               |   1 +
 tools/libxc/include/xenguest.h     |  20 +++
 tools/libxc/xc_domain_soft_reset.c | 282 +++++++++++++++++++++++++++++++++++++
 3 files changed, 303 insertions(+)
 create mode 100644 tools/libxc/xc_domain_soft_reset.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index bd2ca6c..8f8abd6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -52,6 +52,7 @@ GUEST_SRCS-y += xc_offline_page.c xc_compression.c
 else
 GUEST_SRCS-y += xc_nomigrate.c
 endif
+GUEST_SRCS-y += xc_domain_soft_reset.c
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 40bbac8..770cd10 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -131,6 +131,26 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
  * of the new domain is automatically appended to the filename,
  * separated by a ".".
  */
+
+/**
+ * This function does soft reset for a domain. During soft reset all
+ * source domain's memory is being reassigned to the destination domain,
+ * HVM context and HVM params are being copied.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm source_dom the id of the source domain
+ * @parm dest_dom the id of the destination domain
+ * @parm console_domid the id of the domain handling console
+ * @parm console_mfn returned with the mfn of the console page
+ * @parm store_domid the id of the domain handling store
+ * @parm store_mfn returned with the mfn of the store page
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_soft_reset(xc_interface *xch, uint32_t source_dom,
+                         uint32_t dest_dom, domid_t console_domid,
+                         unsigned long *console_mfn, domid_t store_domid,
+                         unsigned long *store_mfn);
+
 #define XC_DEVICE_MODEL_RESTORE_FILE "/var/lib/xen/qemu-resume"
 
 /**
diff --git a/tools/libxc/xc_domain_soft_reset.c b/tools/libxc/xc_domain_soft_reset.c
new file mode 100644
index 0000000..24d0b48
--- /dev/null
+++ b/tools/libxc/xc_domain_soft_reset.c
@@ -0,0 +1,282 @@
+/******************************************************************************
+ * xc_domain_soft_reset.c
+ *
+ * Do soft reset.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <inttypes.h>
+#include <time.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <sys/time.h>
+
+#include "xc_private.h"
+#include "xc_core.h"
+#include "xc_bitops.h"
+#include "xc_dom.h"
+#include "xg_private.h"
+#include "xg_save_restore.h"
+
+#include <xen/hvm/params.h>
+
+#define SLEEP_INT 1
+
+int xc_domain_soft_reset(xc_interface *xch, uint32_t source_dom,
+                         uint32_t dest_dom, domid_t console_domid,
+                         unsigned long *console_mfn, domid_t store_domid,
+                         unsigned long *store_mfn)
+{
+    xc_dominfo_t old_info, new_info;
+    int rc = 1;
+
+    uint32_t hvm_buf_size = 0;
+    uint8_t *hvm_buf = NULL;
+    unsigned long console_pfn, store_pfn, io_pfn, buffio_pfn;
+    unsigned long max_gpfn;
+    uint64_t hvm_params[HVM_NR_PARAMS];
+    xen_pfn_t sharedinfo_pfn;
+
+    DPRINTF("%s: soft reset domid %u -> %u", __func__, source_dom, dest_dom);
+
+    if ( xc_domain_getinfo(xch, source_dom, 1, &old_info) != 1 )
+    {
+        PERROR("Could not get old domain info");
+        return 1;
+    }
+
+    if ( xc_domain_getinfo(xch, dest_dom, 1, &new_info) != 1 )
+    {
+        PERROR("Could not get new domain info");
+        return 1;
+    }
+
+    if ( !old_info.hvm || !new_info.hvm )
+    {
+        PERROR("Soft reset is supported for HVM only");
+        return 1;
+    }
+
+    max_gpfn = xc_domain_maximum_gpfn(xch, source_dom);
+
+    sharedinfo_pfn = old_info.shared_info_frame;
+    if ( xc_get_pfn_type_batch(xch, source_dom, 1, &sharedinfo_pfn) )
+    {
+        PERROR("xc_get_pfn_type_batch failed");
+        goto out;
+    }
+
+    hvm_buf_size = xc_domain_hvm_getcontext(xch, source_dom, 0, 0);
+    if ( hvm_buf_size == -1 )
+    {
+        PERROR("Couldn't get HVM context size from Xen");
+        goto out;
+    }
+
+    hvm_buf = malloc(hvm_buf_size);
+    if ( !hvm_buf )
+    {
+        ERROR("Couldn't allocate memory");
+        goto out;
+    }
+
+    if ( xc_domain_hvm_getcontext(xch, source_dom, hvm_buf,
+                                  hvm_buf_size) == -1 )
+    {
+        PERROR("HVM:Could not get hvm buffer");
+        goto out;
+    }
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_STORE_PFN,
+                     &hvm_params[HVM_PARAM_STORE_PFN]);
+    store_pfn = hvm_params[HVM_PARAM_STORE_PFN];
+    *store_mfn = store_pfn;
+
+    xc_hvm_param_get(xch, source_dom,
+                     HVM_PARAM_CONSOLE_PFN,
+                     &hvm_params[HVM_PARAM_CONSOLE_PFN]);
+    console_pfn = hvm_params[HVM_PARAM_CONSOLE_PFN];
+    *console_mfn = console_pfn;
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_BUFIOREQ_PFN,
+                     &hvm_params[HVM_PARAM_BUFIOREQ_PFN]);
+    buffio_pfn = hvm_params[HVM_PARAM_BUFIOREQ_PFN];
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_IOREQ_PFN,
+                     &hvm_params[HVM_PARAM_IOREQ_PFN]);
+    io_pfn = hvm_params[HVM_PARAM_IOREQ_PFN];
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_IDENT_PT,
+                     &hvm_params[HVM_PARAM_IDENT_PT]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_PAGING_RING_PFN,
+                     &hvm_params[HVM_PARAM_PAGING_RING_PFN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_ACCESS_RING_PFN,
+                     &hvm_params[HVM_PARAM_ACCESS_RING_PFN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_VM86_TSS,
+                     &hvm_params[HVM_PARAM_VM86_TSS]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_ACPI_IOPORTS_LOCATION,
+                     &hvm_params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_VIRIDIAN,
+                     &hvm_params[HVM_PARAM_VIRIDIAN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_PAE_ENABLED,
+                     &hvm_params[HVM_PARAM_PAE_ENABLED]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_STORE_EVTCHN,
+                     &hvm_params[HVM_PARAM_STORE_EVTCHN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_IOREQ_SERVER_PFN,
+                     &hvm_params[HVM_PARAM_IOREQ_SERVER_PFN]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
+                     &hvm_params[HVM_PARAM_NR_IOREQ_SERVER_PAGES]);
+
+    xc_hvm_param_get(xch, source_dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
+                     &hvm_params[HVM_PARAM_VM_GENERATION_ID_ADDR]);
+
+    rc = xc_domain_devour(xch, source_dom, dest_dom);
+    if ( rc != 0 )
+    {
+        PERROR("failed to devour original domain, rc=%d\n", rc);
+        goto out;
+    }
+
+    while ( 1 )
+    {
+        sleep(SLEEP_INT);
+        if ( xc_get_tot_pages(xch, source_dom) <= 0 )
+        {
+            DPRINTF("All pages were transferred");
+            break;
+        }
+    }
+
+
+    if ( sharedinfo_pfn == XEN_DOMCTL_PFINFO_XTAB)
+    {
+        /*
+         * Shared info frame is being removed when guest maps shared info so
+         * this page is likely XEN_DOMCTL_PFINFO_XTAB but we need to replace
+         * it with an empty page in that case.
+         */
+
+        if ( xc_domain_populate_physmap_exact(xch, dest_dom, 1, 0, 0,
+                                              &old_info.shared_info_frame) )
+        {
+            PERROR("failed to populate pfn %lx (shared info)", old_info.shared_info_frame);
+            goto out;
+        }
+    }
+
+    if ( xc_domain_hvm_setcontext(xch, dest_dom, hvm_buf,
+                                  hvm_buf_size) == -1 )
+    {
+        PERROR("HVM:Could not set hvm buffer");
+        goto out;
+    }
+
+    if ( store_pfn )
+        xc_clear_domain_page(xch, dest_dom, store_pfn);
+
+    if ( console_pfn )
+        xc_clear_domain_page(xch, dest_dom, console_pfn);
+
+    if ( buffio_pfn )
+        xc_clear_domain_page(xch, dest_dom, buffio_pfn);
+
+    if ( io_pfn )
+        xc_clear_domain_page(xch, dest_dom, io_pfn);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_STORE_PFN,
+                     hvm_params[HVM_PARAM_STORE_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom,
+                     HVM_PARAM_CONSOLE_PFN,
+                     hvm_params[HVM_PARAM_CONSOLE_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_BUFIOREQ_PFN,
+                     hvm_params[HVM_PARAM_BUFIOREQ_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_IOREQ_PFN,
+                     hvm_params[HVM_PARAM_IOREQ_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_IDENT_PT,
+                     hvm_params[HVM_PARAM_IDENT_PT]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_PAGING_RING_PFN,
+                     hvm_params[HVM_PARAM_PAGING_RING_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_ACCESS_RING_PFN,
+                     hvm_params[HVM_PARAM_ACCESS_RING_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_VM86_TSS,
+                     hvm_params[HVM_PARAM_VM86_TSS]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_ACPI_IOPORTS_LOCATION,
+                     hvm_params[HVM_PARAM_ACPI_IOPORTS_LOCATION]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_VIRIDIAN,
+                     hvm_params[HVM_PARAM_VIRIDIAN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_PAE_ENABLED,
+                     hvm_params[HVM_PARAM_PAE_ENABLED]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_STORE_EVTCHN,
+                     hvm_params[HVM_PARAM_STORE_EVTCHN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_IOREQ_SERVER_PFN,
+                     hvm_params[HVM_PARAM_IOREQ_SERVER_PFN]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_NR_IOREQ_SERVER_PAGES,
+                     hvm_params[HVM_PARAM_NR_IOREQ_SERVER_PAGES]);
+
+    xc_hvm_param_set(xch, dest_dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
+                     hvm_params[HVM_PARAM_VM_GENERATION_ID_ADDR]);
+
+    if (xc_dom_gnttab_hvm_seed(xch, dest_dom, console_pfn, store_pfn,
+                               console_domid, store_domid))
+    {
+        PERROR("error seeding hvm grant table");
+        goto out;
+    }
+
+    rc = 0;
+out:
+    if (hvm_buf) free(hvm_buf);
+
+    if ( (rc != 0) && (dest_dom != 0) ) {
+            PERROR("Faled to perform soft reset, destroying domain %d",
+                   dest_dom);
+	    xc_domain_destroy(xch, dest_dom);
+    }
+
+    return !!rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44Q-00005i-JQ; Thu, 11 Dec 2014 13:46:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1Xz44P-00005O-VN
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BD/9A-09842-920A9845; Thu, 11 Dec 2014 13:46:17 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418305572!14933026!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24617 invoked from network); 11 Dec 2014 13:46:14 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:46:14 -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 sBBDk2bo022179
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:46:03 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW8013088; Thu, 11 Dec 2014 08:46:00 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:37 +0100
Message-Id: <1418305541-5135-6-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 5/9] libxc: support XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 new xc_domain_devour() function to support XEN_DOMCTL_devour.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 tools/libxc/include/xenctrl.h | 14 ++++++++++++++
 tools/libxc/xc_domain.c       | 13 +++++++++++++
 2 files changed, 27 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..a789de3 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -558,6 +558,20 @@ int xc_domain_unpause(xc_interface *xch,
 int xc_domain_destroy(xc_interface *xch,
                       uint32_t domid);
 
+/**
+ * This function sets a 'recipient' domain for a domain (when the source domain
+ * releases memory it is being reassigned to the recipient domain instead of
+ * being freed) and kills the original domain. The destination domain is supposed
+ * to have enough max_mem and no pages assigned.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the source domain id
+ * @parm recipient the destrination domain id
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_devour(xc_interface *xch,
+                     uint32_t domid, uint32_t recipient);
+
 
 /**
  * This function resumes a suspended domain. The domain should have
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index b864872..5949725 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -122,6 +122,19 @@ int xc_domain_destroy(xc_interface *xch,
     return ret;
 }
 
+int xc_domain_devour(xc_interface *xch, uint32_t domid, uint32_t recipient)
+{
+    int ret;
+    DECLARE_DOMCTL;
+    domctl.cmd = XEN_DOMCTL_devour;
+    domctl.domain = (domid_t)domid;
+    domctl.u.devour.recipient = (domid_t)recipient;
+    do {
+        ret = do_domctl(xch, &domctl);
+    } while ( ret && (errno == EAGAIN) );
+    return ret;
+}
+
 int xc_domain_shutdown(xc_interface *xch,
                        uint32_t domid,
                        int reason)
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44L-0008W0-6s; Thu, 11 Dec 2014 13:46: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 1Xz44J-0008VT-QB
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:12 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	12/53-11581-320A9845; Thu, 11 Dec 2014 13:46:11 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418305568!5238559!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8557 invoked from network); 11 Dec 2014 13:46:10 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 13:46:10 -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 sBBDjxin022155
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:45:59 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW7013088; Thu, 11 Dec 2014 08:45:56 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:36 +0100
Message-Id: <1418305541-5135-5-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

New operation sets the 'recipient' domain which will receive all
memory pages from a particular domain and kills the original domain.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/domain.c         |  3 +++
 xen/common/domctl.c         | 33 +++++++++++++++++++++++++++++++++
 xen/common/page_alloc.c     | 28 ++++++++++++++++++++++++----
 xen/include/public/domctl.h | 15 +++++++++++++++
 xen/include/xen/sched.h     |  2 ++
 5 files changed, 77 insertions(+), 4 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index c13a7cf..f26267a 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -825,6 +825,9 @@ static void complete_domain_destroy(struct rcu_head *head)
     if ( d->target != NULL )
         put_domain(d->target);
 
+    if ( d->recipient != NULL )
+        put_domain(d->recipient);
+
     evtchn_destroy_final(d);
 
     radix_tree_destroy(&d->pirq_tree, free_pirq_struct);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index f15dcfe..7e7fb47 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1177,6 +1177,39 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_devour:
+    {
+        struct domain *recipient_dom;
+
+        if ( !d->recipient )
+        {
+            recipient_dom = get_domain_by_id(op->u.devour.recipient);
+            if ( recipient_dom == NULL )
+            {
+                ret = -ESRCH;
+                break;
+            }
+
+            if ( recipient_dom->tot_pages != 0 )
+            {
+                put_domain(recipient_dom);
+                ret = -EINVAL;
+                break;
+            }
+            /*
+             * Make sure no allocation/remapping is ongoing and set is_dying
+             * flag to prevent such actions in future.
+             */
+            spin_lock(&d->page_alloc_lock);
+            d->is_dying = DOMDYING_locked;
+            d->recipient = recipient_dom;
+            smp_wmb(); /* make sure recipient was set before domain_kill() */
+            spin_unlock(&d->page_alloc_lock);
+        }
+        ret = domain_kill(d);
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 7b4092d..7eb4404 100644
--- 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,13 +1765,32 @@ 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);
+            if ( assign_pages(d->recipient, pg, order, 0) )
+                /* assign_pages reports the error by itself */
+                goto out;
+
+            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
+                printk(XENLOG_G_INFO
+                       "Failed to add MFN %lx (GFN %lx) to Dom%d's physmap\n",
+                       mfn, gmfn, d->recipient->domain_id);
+        }
     }
 
+out:
     if ( drop_dom_ref )
         put_domain(d);
 }
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 57e2ed7..871fa5e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -995,6 +995,19 @@ struct xen_domctl_psr_cmt_op {
 typedef struct xen_domctl_psr_cmt_op xen_domctl_psr_cmt_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cmt_op_t);
 
+/*
+ * XEN_DOMCTL_devour - kills the domain reassigning all of its domheap pages
+ * to the 'recipient' domain. Pages from xen heap belonging to the domain
+ * are not copied. Reassigned pages are mapped to the same GMFNs in the
+ * recipient domain as they were mapped in the original. The recipient domain
+ * is supposed to not have any domheap pages to avoid MFN-GMFN collisions.
+ */
+struct xen_domctl_devour {
+    domid_t recipient;
+};
+typedef struct xen_domctl_devour xen_domctl_devour_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_devour_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -1070,6 +1083,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_setvnumainfo                  74
 #define XEN_DOMCTL_psr_cmt_op                    75
 #define XEN_DOMCTL_arm_configure_domain          76
+#define XEN_DOMCTL_devour                        77
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1135,6 +1149,7 @@ struct xen_domctl {
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         struct xen_domctl_vnuma             vnuma;
         struct xen_domctl_psr_cmt_op        psr_cmt_op;
+        struct xen_domctl_devour            devour;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index a42d0b8..bbb0505 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -366,6 +366,8 @@ struct domain
     bool_t           is_privileged;
     /* Which guest this guest has privileges on */
     struct domain   *target;
+    /* Newly created guest which receives freed memory pages (soft reset) */
+    struct domain   *recipient;
     /* Is this guest being debugged by dom0? */
     bool_t           debugger_attached;
     /* Is this guest dying (i.e., a zombie)? */
-- 
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 Dec 11 13:46:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 13:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz44Z-0000Bi-Ve; Thu, 11 Dec 2014 13:46:27 +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 1Xz44Y-0000AI-8Y
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:46:26 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	51/98-02697-130A9845; Thu, 11 Dec 2014 13:46:25 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418305583!9469474!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2628 invoked from network); 11 Dec 2014 13:46:24 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Dec 2014 13:46:24 -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 sBBDkFB6026782
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 08:46:15 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgWC013088; Thu, 11 Dec 2014 08:46:12 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:41 +0100
Message-Id: <1418305541-5135-10-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 9/9] xsm: add XEN_DOMCTL_devour support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 xen/common/domctl.c                 |  6 ++++++
 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 ++++++++++
 6 files changed, 46 insertions(+)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 7e7fb47..7c22e35 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1190,6 +1190,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                 break;
             }
 
+            ret = xsm_devour(XSM_HOOK, d, recipient_dom);
+            if ( ret ) {
+                put_domain(recipient_dom);
+                break;
+            }
+
             if ( recipient_dom->tot_pages != 0 )
             {
                 put_domain(recipient_dom);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f20e89c..6e9e38b 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -113,6 +113,12 @@ static XSM_INLINE int xsm_set_target(XSM_DEFAULT_ARG struct domain *d, struct do
     return xsm_default_action(action, current->domain, NULL);
 }
 
+static XSM_INLINE int xsm_devour(XSM_DEFAULT_ARG struct domain *d, struct domain *e)
+{
+    XSM_ASSERT_ACTION(XSM_HOOK);
+    return xsm_default_action(action, current->domain, NULL);
+}
+
 static XSM_INLINE int xsm_domctl(XSM_DEFAULT_ARG struct domain *d, int cmd)
 {
     XSM_ASSERT_ACTION(XSM_OTHER);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4ce089f..7db7433 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -58,6 +58,7 @@ struct xsm_operations {
     int (*domctl_scheduler_op) (struct domain *d, int op);
     int (*sysctl_scheduler_op) (int op);
     int (*set_target) (struct domain *d, struct domain *e);
+    int (*devour) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
     int (*sysctl) (int cmd);
     int (*readconsole) (uint32_t clear);
@@ -213,6 +214,11 @@ static inline int xsm_set_target (xsm_default_t def, struct domain *d, struct do
     return xsm_ops->set_target(d, e);
 }
 
+static inline int xsm_devour (xsm_default_t def, struct domain *d, struct domain *r)
+{
+    return xsm_ops->devour(d, r);
+}
+
 static inline int xsm_domctl (xsm_default_t def, struct domain *d, int cmd)
 {
     return xsm_ops->domctl(d, cmd);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 8eb3050..f3c2f9e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -35,6 +35,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domctl_scheduler_op);
     set_to_dummy_if_null(ops, sysctl_scheduler_op);
     set_to_dummy_if_null(ops, set_target);
+    set_to_dummy_if_null(ops, devour);
     set_to_dummy_if_null(ops, domctl);
     set_to_dummy_if_null(ops, sysctl);
     set_to_dummy_if_null(ops, readconsole);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d48463f..097c8c2 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -565,6 +565,21 @@ static int flask_set_target(struct domain *d, struct domain *t)
     return rc;
 }
 
+static int flask_devour(struct domain *d, struct domain *r)
+{
+    int rc;
+    struct domain_security_struct *dsec, *rsec;
+    dsec = d->ssid;
+    rsec = r->ssid;
+
+    rc = current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_SOURCE);
+    if ( rc )
+        return rc;
+    if ( r )
+        rc = current_has_perm(r, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_RECIPIENT);
+    return rc;
+}
+
 static int flask_domctl(struct domain *d, int cmd)
 {
     switch ( cmd )
@@ -580,6 +595,7 @@ static int flask_domctl(struct domain *d, int cmd)
 #ifdef HAS_MEM_ACCESS
     case XEN_DOMCTL_mem_event_op:
 #endif
+    case XEN_DOMCTL_devour:
 #ifdef CONFIG_X86
     /* These have individual XSM hooks (arch/x86/domctl.c) */
     case XEN_DOMCTL_shadow_op:
@@ -1512,6 +1528,7 @@ static struct xsm_operations flask_ops = {
     .domctl_scheduler_op = flask_domctl_scheduler_op,
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
     .set_target = flask_set_target,
+    .devour = flask_devour,
     .domctl = flask_domctl,
     .sysctl = flask_sysctl,
     .readconsole = flask_readconsole,
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 1da9f63..64c3424 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -142,6 +142,8 @@ class domain
 #  target = the new target domain
 # see also the domain2 make_priv_for and set_as_target checks
     set_target
+# XEN_DOMCTL_devour
+    devour
 # SCHEDOP_remote_shutdown
     shutdown
 # XEN_DOMCTL_set{,_machine}_address_size
@@ -196,6 +198,14 @@ class domain2
 #  source = the domain making the hypercall
 #  target = the new target domain
     set_as_target
+# checked in XEN_DOMCTL_devour:
+#  source = the domain making the hypercall
+#  target = the new source domain
+    set_as_source
+# checked in XEN_DOMCTL_devour:
+#  source = the domain making the hypercall
+#  target = the new recipient domain
+    set_as_recipient
 # XEN_DOMCTL_set_cpuid
     set_cpuid
 # XEN_DOMCTL_gettscinfo
-- 
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 Dec 11 14:15:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 14: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 1Xz4WI-0002Qg-G6; Thu, 11 Dec 2014 14:15:06 +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 1Xz4WH-0002Qb-He
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 14:15:05 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	F1/80-28296-8E6A9845; Thu, 11 Dec 2014 14:15:04 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418307304!12571149!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9192 invoked from network); 11 Dec 2014 14:15:04 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 14:15:04 -0000
Received: from dezo.moloch.sk (unknown [92.240.231.146])
	by mail.moloch.sk (Postfix) with ESMTPSA id B80D61800D85;
	Thu, 11 Dec 2014 15:15:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1418307303;
	bh=m1L7I1bw8nBXXW21x9wWUCneH8k9udgFWbwmtpgeJpI=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=j0mA1FH/S8J/228cRuxzce+fIpu3d/RxIER8d06AiWRmja/xtutkuh3J+qR6NORXK
	4o3kTS3qSJDR85efROcpuZ0ySbKXwCgr7OsbtIS5MqVcvZb38RiHl+fUIweM/q1D0R
	q7bdKY7U7VOHGTGkKZyrRAlaK5BiNnIjyQXBylm4LQGzw9JRmY+221UJx7I437MQW7
	qZhMPRunZqvjW3qJmH/DmTVO9w+PhBsj5iqnmmu9/bExgVLC6Ckr0wluKs2cfB7gut
	3jYqnjIvH3/XAtc6z8FQ6uwqfpUPo2VdQDm7EF1FlEo/CHOI5IsaWE8bZXmK2Wh1+k
	nHMTApbHtbnuw==
Received: by dezo.moloch.sk (Postfix, from userid 1000)
	id 57ED5D059546; Thu, 11 Dec 2014 15:15:03 +0100 (CET)
Date: Thu, 11 Dec 2014 15:15:03 +0100
From: Martin Lucina <martin@lucina.net>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, xen-devel@lists.xen.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
Message-ID: <20141211141503.GB3218@dezo.moloch.sk>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
References: <20141204135550.GC11192@dezo.moloch.sk>
	<20141207195343.GC3141@type.youpi.perso.aquilenet.fr>
	<20141211120959.GA3218@dezo.moloch.sk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141211120959.GA3218@dezo.moloch.sk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] [PATCH] Mini-OS: netfront: Fix rx ring starvation
 in network_rx
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.net said:
> Rather, shouldn't the final if() in the loop (where data is sent up) be:
> 
>   if(rx->status > NETIF_RSP_NULL) { ... }
> 
> *we can't use NETIF_RSP_OKAY as NETIF_RSP_NULL is defined to be 1 (yuck).
> 
> I don't see any value in keeping the printk(), the netfront driver already
> disclaims supporting extras in comments.

I just cross-checked with include/xen/io/netif.h and the Linux kernel
xen-netfront.c. We will never see NETRXF_extra_info as we (correctly) don't
advertise any of the relevant feature-* toggles in Xenstore.

AFAICT we should also never see NETIF_RSP_NULL as according to the
documentation that is only used for responses to TX requests. If this is
indeed the case then the if can be 

  if (rx->status > NETIF_RSP_OKAY)

it can't be tested with == as rx->status is overloaded to contain the
rx packet size.

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 14:15:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 14: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 1Xz4WI-0002Qg-G6; Thu, 11 Dec 2014 14:15:06 +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 1Xz4WH-0002Qb-He
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 14:15:05 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	F1/80-28296-8E6A9845; Thu, 11 Dec 2014 14:15:04 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418307304!12571149!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9192 invoked from network); 11 Dec 2014 14:15:04 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 14:15:04 -0000
Received: from dezo.moloch.sk (unknown [92.240.231.146])
	by mail.moloch.sk (Postfix) with ESMTPSA id B80D61800D85;
	Thu, 11 Dec 2014 15:15:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1418307303;
	bh=m1L7I1bw8nBXXW21x9wWUCneH8k9udgFWbwmtpgeJpI=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=j0mA1FH/S8J/228cRuxzce+fIpu3d/RxIER8d06AiWRmja/xtutkuh3J+qR6NORXK
	4o3kTS3qSJDR85efROcpuZ0ySbKXwCgr7OsbtIS5MqVcvZb38RiHl+fUIweM/q1D0R
	q7bdKY7U7VOHGTGkKZyrRAlaK5BiNnIjyQXBylm4LQGzw9JRmY+221UJx7I437MQW7
	qZhMPRunZqvjW3qJmH/DmTVO9w+PhBsj5iqnmmu9/bExgVLC6Ckr0wluKs2cfB7gut
	3jYqnjIvH3/XAtc6z8FQ6uwqfpUPo2VdQDm7EF1FlEo/CHOI5IsaWE8bZXmK2Wh1+k
	nHMTApbHtbnuw==
Received: by dezo.moloch.sk (Postfix, from userid 1000)
	id 57ED5D059546; Thu, 11 Dec 2014 15:15:03 +0100 (CET)
Date: Thu, 11 Dec 2014 15:15:03 +0100
From: Martin Lucina <martin@lucina.net>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, xen-devel@lists.xen.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
Message-ID: <20141211141503.GB3218@dezo.moloch.sk>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
References: <20141204135550.GC11192@dezo.moloch.sk>
	<20141207195343.GC3141@type.youpi.perso.aquilenet.fr>
	<20141211120959.GA3218@dezo.moloch.sk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141211120959.GA3218@dezo.moloch.sk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] [PATCH] Mini-OS: netfront: Fix rx ring starvation
 in network_rx
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.net said:
> Rather, shouldn't the final if() in the loop (where data is sent up) be:
> 
>   if(rx->status > NETIF_RSP_NULL) { ... }
> 
> *we can't use NETIF_RSP_OKAY as NETIF_RSP_NULL is defined to be 1 (yuck).
> 
> I don't see any value in keeping the printk(), the netfront driver already
> disclaims supporting extras in comments.

I just cross-checked with include/xen/io/netif.h and the Linux kernel
xen-netfront.c. We will never see NETRXF_extra_info as we (correctly) don't
advertise any of the relevant feature-* toggles in Xenstore.

AFAICT we should also never see NETIF_RSP_NULL as according to the
documentation that is only used for responses to TX requests. If this is
indeed the case then the if can be 

  if (rx->status > NETIF_RSP_OKAY)

it can't be tested with == as rx->status is overloaded to contain the
rx packet size.

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 14:24:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 14: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 1Xz4fa-00033R-Hj; Thu, 11 Dec 2014 14:24:42 +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 1Xz4fY-00033M-OR
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 14:24:41 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	7D/05-15461-829A9845; Thu, 11 Dec 2014 14:24:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418307879!14973118!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
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32067 invoked from network); 11 Dec 2014 14:24:39 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 14:24:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418307879; l=688;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=AW/ygWA9/is9xaWdzU3QAddDhCo=;
	b=Pr/khasAlC5AvciHhyWMfgdnUw9JMWFxPWKjVmtOuOIS7eDMOYcFtkqJjA3WA4oC+Cy
	ThFwyNzJfVEGNE/iUsqC4nfkZ25GV9O++ZlkPgMtHcT4txPsBvyaAvIp7FSJ6SUGH7w9x
	yvoTvktKlpjrvgL+yybwag4CZoHk4brwmkQ=
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.3 AUTH) with ESMTPSA id V07fefqBBEOT3pa
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 11 Dec 2014 15:24:29 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0EA7B5015F; Thu, 11 Dec 2014 15:24:28 +0100 (CET)
Date: Thu, 11 Dec 2014 15:24:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141211142428.GA19820@aepfle.de>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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 Wed, Dec 03, Vitaly Kuznetsov wrote:

> 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.

How does this approach handle ballooned pages?
>From the guests point of view they are always there, just claimed by the
balloon driver. The new kernel does not have that driver nor does its
driver have the knowledge which pages the old kernel gave back to Xen.

After a brief look none of the patches seem to deal with that.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 14:24:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 14: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 1Xz4fa-00033R-Hj; Thu, 11 Dec 2014 14:24:42 +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 1Xz4fY-00033M-OR
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 14:24:41 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	7D/05-15461-829A9845; Thu, 11 Dec 2014 14:24:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418307879!14973118!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
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32067 invoked from network); 11 Dec 2014 14:24:39 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 14:24:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418307879; l=688;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=AW/ygWA9/is9xaWdzU3QAddDhCo=;
	b=Pr/khasAlC5AvciHhyWMfgdnUw9JMWFxPWKjVmtOuOIS7eDMOYcFtkqJjA3WA4oC+Cy
	ThFwyNzJfVEGNE/iUsqC4nfkZ25GV9O++ZlkPgMtHcT4txPsBvyaAvIp7FSJ6SUGH7w9x
	yvoTvktKlpjrvgL+yybwag4CZoHk4brwmkQ=
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.3 AUTH) with ESMTPSA id V07fefqBBEOT3pa
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 11 Dec 2014 15:24:29 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0EA7B5015F; Thu, 11 Dec 2014 15:24:28 +0100 (CET)
Date: Thu, 11 Dec 2014 15:24:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20141211142428.GA19820@aepfle.de>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Jones <drjones@redhat.com>,
	Keir Fraser <keir@xen.org>, 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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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 Wed, Dec 03, Vitaly Kuznetsov wrote:

> 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.

How does this approach handle ballooned pages?
>From the guests point of view they are always there, just claimed by the
balloon driver. The new kernel does not have that driver nor does its
driver have the knowledge which pages the old kernel gave back to Xen.

After a brief look none of the patches seem to deal with that.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 14:29:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 14: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 1Xz4kY-0003Dp-Gg; Thu, 11 Dec 2014 14:29:50 +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 1Xz4kW-0003Df-Ey
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 14:29:48 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	DF/E1-02953-B5AA9845; Thu, 11 Dec 2014 14:29:47 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418308184!14441189!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27823 invoked from network); 11 Dec 2014 14:29:46 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 14:29:46 -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 sBBETRJi012032
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 09:29:32 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgWB013088; Thu, 11 Dec 2014 08:46:09 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:40 +0100
Message-Id: <1418305541-5135-9-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 8/9] libxl: soft reset support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Perform soft reset when a domain did SHUTDOWN_soft_reset. Migrate the
content with xc_domain_soft_reset(), reload dm and toolstack.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 docs/man/xl.cfg.pod.5        |  12 +++++
 tools/libxl/libxl.h          |   6 +++
 tools/libxl/libxl_create.c   | 103 +++++++++++++++++++++++++++++++++++++++----
 tools/libxl/libxl_internal.h |  26 +++++++++++
 tools/libxl/libxl_types.idl  |   3 ++
 tools/libxl/xl_cmdimpl.c     |  35 ++++++++++++++-
 6 files changed, 174 insertions(+), 11 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 622ea53..8b57643 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -306,6 +306,13 @@ destroy the domain.
 write a "coredump" of the domain to F</var/xen/dump/NAME> and then
 restart the domain.
 
+=item B<soft-reset>
+
+create a new domain with the same configuration, reassign all the domain's
+memory to this new domain, kill the original domain, and continue execution
+of the new domain from where the action was triggered. Supported for HVM
+guests only.
+
 =back
 
 The default for C<on_poweroff> is C<destroy>.
@@ -324,6 +331,11 @@ Default is C<destroy>.
 
 Action to take if the domain crashes.  Default is C<destroy>.
 
+=item B<on_soft_reset="ACTION">
+
+Action to take if the domain performs 'soft reset' (e.g. does kexec).
+Default is C<soft-reset>.
+
 =back
 
 =head3 Direct Kernel Boot
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0a123f1..710dc0e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -929,6 +929,12 @@ int static inline libxl_domain_create_restore_0x040200(
 
 #endif
 
+int libxl_domain_soft_reset(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            uint32_t *domid, uint32_t domid_old,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+
   /* A progress report will be made via ao_console_how, of type
    * domain_create_console_available, when the domain's primary
    * console is available and can be connected to.
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1198225..0a840c9 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -25,6 +25,8 @@
 #include <xen/hvm/hvm_info_table.h>
 #include <xen/hvm/e820.h>
 
+#define INVALID_DOMID ~0
+
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                          libxl_domain_create_info *c_info)
 {
@@ -903,6 +905,9 @@ static void initiate_domain_create(libxl__egc *egc,
     if (restore_fd >= 0) {
         LOG(DEBUG, "restoring, not running bootloader");
         domcreate_bootloader_done(egc, &dcs->bl, 0);
+    } else if (dcs->domid_soft_reset != INVALID_DOMID) {
+        LOG(DEBUG, "soft reset, not running bootloader\n");
+        domcreate_bootloader_done(egc, &dcs->bl, 0);
     } else  {
         LOG(DEBUG, "running bootloader");
         dcs->bl.callback = domcreate_bootloader_done;
@@ -951,6 +956,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl_domain_config *const d_config = dcs->guest_config;
     libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
+    const uint32_t domid_soft_reset = dcs->domid_soft_reset;
     libxl__domain_build_state *const state = &dcs->build_state;
     libxl__srm_restore_autogen_callbacks *const callbacks =
         &dcs->shs.callbacks.restore.a;
@@ -974,7 +980,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->dmss.dm.callback = domcreate_devmodel_started;
     dcs->dmss.callback = domcreate_devmodel_started;
 
-    if ( restore_fd < 0 ) {
+    if ( (restore_fd < 0) && (domid_soft_reset == INVALID_DOMID) ) {
         rc = libxl__domain_build(gc, d_config, domid, state);
         domcreate_rebuild_done(egc, dcs, rc);
         return;
@@ -1004,14 +1010,74 @@ static void domcreate_bootloader_done(libxl__egc *egc,
         rc = ERROR_INVAL;
         goto out;
     }
-    libxl__xc_domain_restore(egc, dcs,
-                             hvm, pae, superpages);
+    if ( restore_fd >= 0 ) {
+        libxl__xc_domain_restore(egc, dcs,
+                                 hvm, pae, superpages);
+    } else {
+        libxl__xc_domain_soft_reset(egc, dcs);
+    }
+
     return;
 
  out:
     libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
 }
 
+void libxl__xc_domain_soft_reset(libxl__egc *egc,
+                                 libxl__domain_create_state *dcs)
+{
+    STATE_AO_GC(dcs->ao);
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    const uint32_t domid_soft_reset = dcs->domid_soft_reset;
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
+    uint8_t *buf;
+    uint32_t len;
+    uint32_t console_domid, store_domid;
+    unsigned long store_mfn, console_mfn;
+    int rc;
+    struct libxl__domain_suspend_state *dss;
+
+    GCNEW(dss);
+
+    dss->ao = ao;
+    dss->domid = domid_soft_reset;
+    dss->dm_savefile = GCSPRINTF("/var/lib/xen/qemu-save.%d",
+                                 domid_soft_reset);
+
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        rc = libxl__domain_suspend_device_model(gc, dss);
+        if (rc) goto out;
+    }
+
+    console_domid = dcs->build_state.console_domid;
+    store_domid = dcs->build_state.store_domid;
+
+    libxl__domain_soft_reset_destroy(gc, domid_soft_reset, 0);
+
+    rc = xc_domain_soft_reset(ctx->xch, domid_soft_reset, domid, console_domid,
+                              &console_mfn, store_domid, &store_mfn);
+    if (rc) goto out;
+
+    libxl__qmp_cleanup(gc, domid_soft_reset);
+
+    dcs->build_state.store_mfn = store_mfn;
+    dcs->build_state.console_mfn = console_mfn;
+
+    rc = libxl__toolstack_save(domid_soft_reset, &buf, &len, dss);
+    if (rc) goto out;
+
+    rc = libxl__toolstack_restore(domid, buf, len, &dcs->shs);
+    if (rc) goto out;
+out:
+    /*
+     * Now pretend we did normal restore and simply call
+     * libxl__xc_domain_restore_done().
+     */
+    libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
+}
+
 void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
           unsigned long console_mfn, void *user)
 {
@@ -1037,6 +1103,7 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
 
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
+    const uint32_t domid_soft_reset = dcs->domid_soft_reset;
     libxl_domain_config *const d_config = dcs->guest_config;
     libxl_domain_build_info *const info = &d_config->b_info;
     libxl__domain_build_state *const state = &dcs->build_state;
@@ -1089,9 +1156,12 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
     if (ret)
         goto out;
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM && fd != -1) {
         state->saved_state = GCSPRINTF(
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
+    } else if (domid_soft_reset != INVALID_DOMID) {
+        state->saved_state = GCSPRINTF(
+                       "/var/lib/xen/qemu-save.%d", domid_soft_reset);
     }
 
 out:
@@ -1100,9 +1170,12 @@ out:
         libxl__file_reference_unmap(&state->pv_ramdisk);
     }
 
-    esave = errno;
-    libxl_fd_set_nonblock(ctx, fd, 0);
-    errno = esave;
+    if ( fd != -1 ) {
+        esave = errno;
+        libxl_fd_set_nonblock(ctx, fd, 0);
+        errno = esave;
+    }
+
     domcreate_rebuild_done(egc, dcs, ret);
 }
 
@@ -1495,6 +1568,7 @@ static void domain_create_cb(libxl__egc *egc,
 static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid,
                             int restore_fd, int checkpointed_stream,
+                            uint32_t domid_old,
                             const libxl_asyncop_how *ao_how,
                             const libxl_asyncprogress_how *aop_console_how)
 {
@@ -1507,6 +1581,7 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     libxl_domain_config_init(&cdcs->dcs.guest_config_saved);
     libxl_domain_config_copy(ctx, &cdcs->dcs.guest_config_saved, d_config);
     cdcs->dcs.restore_fd = restore_fd;
+    cdcs->dcs.domid_soft_reset = domid_old;
     cdcs->dcs.callback = domain_create_cb;
     cdcs->dcs.checkpointed_stream = checkpointed_stream;
     libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
@@ -1535,7 +1610,7 @@ int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             const libxl_asyncop_how *ao_how,
                             const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, domid, -1, 0,
+    return do_domain_create(ctx, d_config, domid, -1, 0, INVALID_DOMID,
                             ao_how, aop_console_how);
 }
 
@@ -1546,7 +1621,17 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 const libxl_asyncprogress_how *aop_console_how)
 {
     return do_domain_create(ctx, d_config, domid, restore_fd,
-                            params->checkpointed_stream, ao_how, aop_console_how);
+                            params->checkpointed_stream, INVALID_DOMID,
+                            ao_how, aop_console_how);
+}
+
+int libxl_domain_soft_reset(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            uint32_t *domid, uint32_t domid_old,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
+{
+    return do_domain_create(ctx, d_config, domid, -1, 0, domid_old,
+                            ao_how, aop_console_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d58f08a..b149c51 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3069,6 +3069,7 @@ struct libxl__domain_create_state {
     libxl_domain_config *guest_config;
     libxl_domain_config guest_config_saved; /* vanilla config */
     int restore_fd;
+    uint32_t domid_soft_reset;
     libxl__domain_create_cb *callback;
     libxl_asyncprogress_how aop_console_how;
     /* private to domain_create */
@@ -3133,6 +3134,31 @@ _hidden void libxl__domain_save_device_model(libxl__egc *egc,
 
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 
+/*
+ * Soft reset is a special type of reset when the new domain is being built with
+ * the memory contents and vCPU contexts of the original domain thus allowing
+ * to continue execution from where the hypercall was done. This is supported
+ * for HVM domains only and is done as a modification for the domain create /
+ * restore path within xl:
+ * domcreate_bootloader_done()
+ *     libxl__xc_domain_soft_reset()
+ *         for the original domain:
+ *           libxl__domain_suspend_device_model()
+ *           libxl__domain_soft_reset_destroy()
+ *         xc_domain_soft_reset() which saves HVM context and HVM params, calls
+ *             XEN_DOMCTL_devour destroying the original domain and waiting till
+ *             all memory migrates to the new domain, restoring HVM context and
+ *             HVM params for the new domain
+ *         for the new domain:
+ *           libxl__toolstack_save()
+ *           libxl__toolstack_restore()
+ *         libxl__xc_domain_restore_done() and following the standard 'restore'
+ *             path.
+ */
+
+_hidden void libxl__xc_domain_soft_reset(libxl__egc *egc,
+                                         libxl__domain_create_state *dcs);
+
 _hidden int libxl__domain_soft_reset_destroy(libxl__gc *gc, uint32_t domid,
                                              const libxl_asyncop_how *ao_how);
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 4a0e2be..10ef652 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -121,6 +121,8 @@ libxl_action_on_shutdown = Enumeration("action_on_shutdown", [
 
     (5, "COREDUMP_DESTROY"),
     (6, "COREDUMP_RESTART"),
+
+    (7, "SOFT_RESET"),
     ], init_val = "LIBXL_ACTION_ON_SHUTDOWN_DESTROY")
 
 libxl_trigger = Enumeration("trigger", [
@@ -558,6 +560,7 @@ libxl_domain_config = Struct("domain_config", [
     ("on_reboot", libxl_action_on_shutdown),
     ("on_watchdog", libxl_action_on_shutdown),
     ("on_crash", libxl_action_on_shutdown),
+    ("on_soft_reset", libxl_action_on_shutdown),
     ], dir=DIR_IN)
 
 libxl_diskinfo = Struct("diskinfo", [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index b193c3c..d3ce409 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -130,6 +130,8 @@ static const char *action_on_shutdown_names[] = {
 
     [LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY] = "coredump-destroy",
     [LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART] = "coredump-restart",
+
+    [LIBXL_ACTION_ON_SHUTDOWN_SOFT_RESET] = "soft-reset",
 };
 
 /* Optional data, in order:
@@ -1067,6 +1069,13 @@ static void parse_config_data(const char *config_source,
         exit(1);
     }
 
+    if (xlu_cfg_get_string (config, "on_soft_reset", &buf, 0))
+        buf = "soft-reset";
+    if (!parse_action_on_shutdown(buf, &d_config->on_soft_reset)) {
+        fprintf(stderr, "Unknown on_soft_reset action \"%s\" specified\n", buf);
+        exit(1);
+    }
+
     /* libxl_get_required_shadow_memory() must be called after final values
      * (default or specified) for vcpus and memory are set, because the
      * calculation depends on those values. */
@@ -2052,7 +2061,8 @@ static void reload_domain_config(uint32_t domid,
 }
 
 /* Returns 1 if domain should be restarted,
- * 2 if domain should be renamed then restarted, or 0
+ * 2 if domain should be renamed then restarted,
+ * 3 if domain performed soft reset, or 0
  * Can update r_domid if domain is destroyed etc */
 static int handle_domain_death(uint32_t *r_domid,
                                libxl_event *event,
@@ -2078,6 +2088,9 @@ static int handle_domain_death(uint32_t *r_domid,
     case LIBXL_SHUTDOWN_REASON_WATCHDOG:
         action = d_config->on_watchdog;
         break;
+    case LIBXL_SHUTDOWN_REASON_SOFT_RESET:
+        action = d_config->on_soft_reset;
+        break;
     default:
         LOG("Unknown shutdown reason code %d. Destroying domain.",
             event->u.domain_shutdown.shutdown_reason);
@@ -2128,6 +2141,11 @@ static int handle_domain_death(uint32_t *r_domid,
         *r_domid = INVALID_DOMID;
         break;
 
+    case LIBXL_ACTION_ON_SHUTDOWN_SOFT_RESET:
+        reload_domain_config(*r_domid, d_config);
+        restart = 3;
+        break;
+
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART:
         /* Already handled these above. */
@@ -2294,6 +2312,7 @@ static void evdisable_disk_ejects(libxl_evgen_disk_eject **diskws,
 static uint32_t create_domain(struct domain_create *dom_info)
 {
     uint32_t domid = INVALID_DOMID;
+    uint32_t domid_old = INVALID_DOMID;
 
     libxl_domain_config d_config;
 
@@ -2519,7 +2538,17 @@ start:
          * restore/migrate-receive it again.
          */
         restoring = 0;
-    }else{
+    } else if (domid_old != INVALID_DOMID) {
+        /* Do soft reset */
+        ret = libxl_domain_soft_reset(ctx, &d_config,
+                                      &domid, domid_old,
+                                      0, 0);
+
+        if ( ret ) {
+            goto error_out;
+        }
+        domid_old = INVALID_DOMID;
+    } else {
         ret = libxl_domain_create_new(ctx, &d_config, &domid,
                                       0, autoconnect_console_how);
     }
@@ -2583,6 +2612,8 @@ start:
                 event->u.domain_shutdown.shutdown_reason,
                 event->u.domain_shutdown.shutdown_reason);
             switch (handle_domain_death(&domid, event, &d_config)) {
+            case 3:
+                domid_old = domid;
             case 2:
                 if (!preserve_domain(&domid, event, &d_config)) {
                     /* If we fail then exit leaving the old domain in place. */
-- 
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 Dec 11 14:29:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 14: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 1Xz4kY-0003Dw-Sj; Thu, 11 Dec 2014 14:29:50 +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 1Xz4kX-0003Dk-Kj
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 14:29:49 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D3/AB-02696-C5AA9845; Thu, 11 Dec 2014 14:29:48 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418308183!14488796!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32625 invoked from network); 11 Dec 2014 14:29:45 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 14:29:45 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBBETRJg012032
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 09:29:32 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW3013088; Thu, 11 Dec 2014 08:45:43 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:32 +0100
Message-Id: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 0/9] 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>
MIME-Version: 1.0
Content-Type: text/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 provides x86 PVHVM domains with an ability to perform
kexec/kdump.

Changes from v4:
- "on_soft_reset" option was introduced, now it's possible to specify the behavior
  [Wei Liu]
- renamed libxl__domain_soft_reset_destroy_old to libxl__domain_soft_reset_destroy
- libxl__domain_soft_reset_destroy now takes gc instead of ctx, coding style fix
  [Wei Liu]
- remove forgotten 'd_config.b_info.nodemap.size = 0' hackaround, add
  reload_domain_config() on soft reset path [Wei Liu]
- add whole procedure description to libxl_internal.h [Wei Liu]
- reword 'recipient' description in struct domain [Julien Grall]

Nothing was done with regards to ARM. It seems that correct implementation of
mfn_to_gmfn() returning propper gmfn for DomUs is the desirable solution in the
long run, however, any additional thoughts here are more than wellcome! 

Changes from RFCv3:
This is the first non-RFC series as no major concerns were expressed. I'm trying
to address Jan's comments. Changes are:
- Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really like
  the name but nothing more appropriate came to my mind) which incorporates
  former XEN_DOMCTL_set_recipient and XEN_DOMCTL_destroydomain to prevent
  original domain from changing its allocations during transfer procedure.
- Check in free_domheap_pages() that assign_pages() succeeded.
- Change printk() in free_domheap_pages().
- DOMDYING_locked state was introduced to support XEN_DOMCTL_devour.
- xc_domain_soft_reset() got simplified a bit. Now we just wait for the original
  domain to die or loose all its pages.
- rebased on top of current master branch.

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.

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.

Previous discussions:
This patch series:
http://lists.xen.org/archives/html/xen-devel/2014-12/msg00432.html
http://lists.xen.org/archives/html/xen-devel/2014-10/msg00764.html
http://lists.xen.org/archives/html/xen-devel/2014-09/msg03623.html
http://lists.xen.org/archives/html/xen-devel/2014-08/msg02309.html

on resetting VCPU_info (and that's where 'rebuild everything with the
toolstack solution' was suggested):
http://lists.xen.org/archives/html/xen-devel/2014-08/msg01869.html
Previous versions:
http://lists.xen.org/archives/html/xen-devel/2014-08/msg01630.html
http://lists.xen.org/archives/html/xen-devel/2014-08/msg00603.html

EVTCHNOP_reset (got merged):
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03979.html
Previous:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03925.html
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03322.html
http://lists.xen.org/archives/html/xen-devel/2014-07/msg02500.html

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 (9):
  xen: introduce DOMDYING_locked state
  xen: introduce SHUTDOWN_soft_reset shutdown reason
  libxl: support SHUTDOWN_soft_reset shutdown reason
  xen: introduce XEN_DOMCTL_devour
  libxc: support XEN_DOMCTL_devour
  libxl: add libxl__domain_soft_reset_destroy()
  libxc: introduce soft reset for HVM domains
  libxl: soft reset support
  xsm: add XEN_DOMCTL_devour support

 docs/man/xl.cfg.pod.5               |  12 ++
 tools/libxc/Makefile                |   1 +
 tools/libxc/include/xenctrl.h       |  14 ++
 tools/libxc/include/xenguest.h      |  20 +++
 tools/libxc/xc_domain.c             |  13 ++
 tools/libxc/xc_domain_soft_reset.c  | 282 ++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl.c                 |  33 ++++-
 tools/libxl/libxl.h                 |   6 +
 tools/libxl/libxl_create.c          | 103 +++++++++++--
 tools/libxl/libxl_internal.h        |  30 ++++
 tools/libxl/libxl_types.idl         |   4 +
 tools/libxl/xl_cmdimpl.c            |  37 ++++-
 tools/python/xen/lowlevel/xl/xl.c   |   1 +
 xen/common/domain.c                 |   4 +
 xen/common/domctl.c                 |  39 +++++
 xen/common/page_alloc.c             |  28 +++-
 xen/common/shutdown.c               |   7 +
 xen/include/public/domctl.h         |  15 ++
 xen/include/public/sched.h          |   3 +-
 xen/include/xen/sched.h             |   5 +-
 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 ++
 25 files changed, 674 insertions(+), 23 deletions(-)
 create mode 100644 tools/libxc/xc_domain_soft_reset.c

-- 
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 Dec 11 14:29:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 14: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 1Xz4kY-0003Dp-Gg; Thu, 11 Dec 2014 14:29:50 +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 1Xz4kW-0003Df-Ey
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 14:29:48 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	DF/E1-02953-B5AA9845; Thu, 11 Dec 2014 14:29:47 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418308184!14441189!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27823 invoked from network); 11 Dec 2014 14:29:46 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 14:29:46 -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 sBBETRJi012032
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 09:29:32 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgWB013088; Thu, 11 Dec 2014 08:46:09 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:40 +0100
Message-Id: <1418305541-5135-9-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 8/9] libxl: soft reset support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Perform soft reset when a domain did SHUTDOWN_soft_reset. Migrate the
content with xc_domain_soft_reset(), reload dm and toolstack.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 docs/man/xl.cfg.pod.5        |  12 +++++
 tools/libxl/libxl.h          |   6 +++
 tools/libxl/libxl_create.c   | 103 +++++++++++++++++++++++++++++++++++++++----
 tools/libxl/libxl_internal.h |  26 +++++++++++
 tools/libxl/libxl_types.idl  |   3 ++
 tools/libxl/xl_cmdimpl.c     |  35 ++++++++++++++-
 6 files changed, 174 insertions(+), 11 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 622ea53..8b57643 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -306,6 +306,13 @@ destroy the domain.
 write a "coredump" of the domain to F</var/xen/dump/NAME> and then
 restart the domain.
 
+=item B<soft-reset>
+
+create a new domain with the same configuration, reassign all the domain's
+memory to this new domain, kill the original domain, and continue execution
+of the new domain from where the action was triggered. Supported for HVM
+guests only.
+
 =back
 
 The default for C<on_poweroff> is C<destroy>.
@@ -324,6 +331,11 @@ Default is C<destroy>.
 
 Action to take if the domain crashes.  Default is C<destroy>.
 
+=item B<on_soft_reset="ACTION">
+
+Action to take if the domain performs 'soft reset' (e.g. does kexec).
+Default is C<soft-reset>.
+
 =back
 
 =head3 Direct Kernel Boot
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0a123f1..710dc0e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -929,6 +929,12 @@ int static inline libxl_domain_create_restore_0x040200(
 
 #endif
 
+int libxl_domain_soft_reset(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            uint32_t *domid, uint32_t domid_old,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+
   /* A progress report will be made via ao_console_how, of type
    * domain_create_console_available, when the domain's primary
    * console is available and can be connected to.
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1198225..0a840c9 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -25,6 +25,8 @@
 #include <xen/hvm/hvm_info_table.h>
 #include <xen/hvm/e820.h>
 
+#define INVALID_DOMID ~0
+
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                          libxl_domain_create_info *c_info)
 {
@@ -903,6 +905,9 @@ static void initiate_domain_create(libxl__egc *egc,
     if (restore_fd >= 0) {
         LOG(DEBUG, "restoring, not running bootloader");
         domcreate_bootloader_done(egc, &dcs->bl, 0);
+    } else if (dcs->domid_soft_reset != INVALID_DOMID) {
+        LOG(DEBUG, "soft reset, not running bootloader\n");
+        domcreate_bootloader_done(egc, &dcs->bl, 0);
     } else  {
         LOG(DEBUG, "running bootloader");
         dcs->bl.callback = domcreate_bootloader_done;
@@ -951,6 +956,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     libxl_domain_config *const d_config = dcs->guest_config;
     libxl_domain_build_info *const info = &d_config->b_info;
     const int restore_fd = dcs->restore_fd;
+    const uint32_t domid_soft_reset = dcs->domid_soft_reset;
     libxl__domain_build_state *const state = &dcs->build_state;
     libxl__srm_restore_autogen_callbacks *const callbacks =
         &dcs->shs.callbacks.restore.a;
@@ -974,7 +980,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
     dcs->dmss.dm.callback = domcreate_devmodel_started;
     dcs->dmss.callback = domcreate_devmodel_started;
 
-    if ( restore_fd < 0 ) {
+    if ( (restore_fd < 0) && (domid_soft_reset == INVALID_DOMID) ) {
         rc = libxl__domain_build(gc, d_config, domid, state);
         domcreate_rebuild_done(egc, dcs, rc);
         return;
@@ -1004,14 +1010,74 @@ static void domcreate_bootloader_done(libxl__egc *egc,
         rc = ERROR_INVAL;
         goto out;
     }
-    libxl__xc_domain_restore(egc, dcs,
-                             hvm, pae, superpages);
+    if ( restore_fd >= 0 ) {
+        libxl__xc_domain_restore(egc, dcs,
+                                 hvm, pae, superpages);
+    } else {
+        libxl__xc_domain_soft_reset(egc, dcs);
+    }
+
     return;
 
  out:
     libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
 }
 
+void libxl__xc_domain_soft_reset(libxl__egc *egc,
+                                 libxl__domain_create_state *dcs)
+{
+    STATE_AO_GC(dcs->ao);
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    const uint32_t domid_soft_reset = dcs->domid_soft_reset;
+    const uint32_t domid = dcs->guest_domid;
+    libxl_domain_config *const d_config = dcs->guest_config;
+    libxl_domain_build_info *const info = &d_config->b_info;
+    uint8_t *buf;
+    uint32_t len;
+    uint32_t console_domid, store_domid;
+    unsigned long store_mfn, console_mfn;
+    int rc;
+    struct libxl__domain_suspend_state *dss;
+
+    GCNEW(dss);
+
+    dss->ao = ao;
+    dss->domid = domid_soft_reset;
+    dss->dm_savefile = GCSPRINTF("/var/lib/xen/qemu-save.%d",
+                                 domid_soft_reset);
+
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        rc = libxl__domain_suspend_device_model(gc, dss);
+        if (rc) goto out;
+    }
+
+    console_domid = dcs->build_state.console_domid;
+    store_domid = dcs->build_state.store_domid;
+
+    libxl__domain_soft_reset_destroy(gc, domid_soft_reset, 0);
+
+    rc = xc_domain_soft_reset(ctx->xch, domid_soft_reset, domid, console_domid,
+                              &console_mfn, store_domid, &store_mfn);
+    if (rc) goto out;
+
+    libxl__qmp_cleanup(gc, domid_soft_reset);
+
+    dcs->build_state.store_mfn = store_mfn;
+    dcs->build_state.console_mfn = console_mfn;
+
+    rc = libxl__toolstack_save(domid_soft_reset, &buf, &len, dss);
+    if (rc) goto out;
+
+    rc = libxl__toolstack_restore(domid, buf, len, &dcs->shs);
+    if (rc) goto out;
+out:
+    /*
+     * Now pretend we did normal restore and simply call
+     * libxl__xc_domain_restore_done().
+     */
+    libxl__xc_domain_restore_done(egc, dcs, rc, 0, 0);
+}
+
 void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
           unsigned long console_mfn, void *user)
 {
@@ -1037,6 +1103,7 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
 
     /* convenience aliases */
     const uint32_t domid = dcs->guest_domid;
+    const uint32_t domid_soft_reset = dcs->domid_soft_reset;
     libxl_domain_config *const d_config = dcs->guest_config;
     libxl_domain_build_info *const info = &d_config->b_info;
     libxl__domain_build_state *const state = &dcs->build_state;
@@ -1089,9 +1156,12 @@ void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
     if (ret)
         goto out;
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM && fd != -1) {
         state->saved_state = GCSPRINTF(
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
+    } else if (domid_soft_reset != INVALID_DOMID) {
+        state->saved_state = GCSPRINTF(
+                       "/var/lib/xen/qemu-save.%d", domid_soft_reset);
     }
 
 out:
@@ -1100,9 +1170,12 @@ out:
         libxl__file_reference_unmap(&state->pv_ramdisk);
     }
 
-    esave = errno;
-    libxl_fd_set_nonblock(ctx, fd, 0);
-    errno = esave;
+    if ( fd != -1 ) {
+        esave = errno;
+        libxl_fd_set_nonblock(ctx, fd, 0);
+        errno = esave;
+    }
+
     domcreate_rebuild_done(egc, dcs, ret);
 }
 
@@ -1495,6 +1568,7 @@ static void domain_create_cb(libxl__egc *egc,
 static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
                             uint32_t *domid,
                             int restore_fd, int checkpointed_stream,
+                            uint32_t domid_old,
                             const libxl_asyncop_how *ao_how,
                             const libxl_asyncprogress_how *aop_console_how)
 {
@@ -1507,6 +1581,7 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
     libxl_domain_config_init(&cdcs->dcs.guest_config_saved);
     libxl_domain_config_copy(ctx, &cdcs->dcs.guest_config_saved, d_config);
     cdcs->dcs.restore_fd = restore_fd;
+    cdcs->dcs.domid_soft_reset = domid_old;
     cdcs->dcs.callback = domain_create_cb;
     cdcs->dcs.checkpointed_stream = checkpointed_stream;
     libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
@@ -1535,7 +1610,7 @@ int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
                             const libxl_asyncop_how *ao_how,
                             const libxl_asyncprogress_how *aop_console_how)
 {
-    return do_domain_create(ctx, d_config, domid, -1, 0,
+    return do_domain_create(ctx, d_config, domid, -1, 0, INVALID_DOMID,
                             ao_how, aop_console_how);
 }
 
@@ -1546,7 +1621,17 @@ int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
                                 const libxl_asyncprogress_how *aop_console_how)
 {
     return do_domain_create(ctx, d_config, domid, restore_fd,
-                            params->checkpointed_stream, ao_how, aop_console_how);
+                            params->checkpointed_stream, INVALID_DOMID,
+                            ao_how, aop_console_how);
+}
+
+int libxl_domain_soft_reset(libxl_ctx *ctx, libxl_domain_config *d_config,
+                            uint32_t *domid, uint32_t domid_old,
+                            const libxl_asyncop_how *ao_how,
+                            const libxl_asyncprogress_how *aop_console_how)
+{
+    return do_domain_create(ctx, d_config, domid, -1, 0, domid_old,
+                            ao_how, aop_console_how);
 }
 
 /*
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d58f08a..b149c51 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3069,6 +3069,7 @@ struct libxl__domain_create_state {
     libxl_domain_config *guest_config;
     libxl_domain_config guest_config_saved; /* vanilla config */
     int restore_fd;
+    uint32_t domid_soft_reset;
     libxl__domain_create_cb *callback;
     libxl_asyncprogress_how aop_console_how;
     /* private to domain_create */
@@ -3133,6 +3134,31 @@ _hidden void libxl__domain_save_device_model(libxl__egc *egc,
 
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 
+/*
+ * Soft reset is a special type of reset when the new domain is being built with
+ * the memory contents and vCPU contexts of the original domain thus allowing
+ * to continue execution from where the hypercall was done. This is supported
+ * for HVM domains only and is done as a modification for the domain create /
+ * restore path within xl:
+ * domcreate_bootloader_done()
+ *     libxl__xc_domain_soft_reset()
+ *         for the original domain:
+ *           libxl__domain_suspend_device_model()
+ *           libxl__domain_soft_reset_destroy()
+ *         xc_domain_soft_reset() which saves HVM context and HVM params, calls
+ *             XEN_DOMCTL_devour destroying the original domain and waiting till
+ *             all memory migrates to the new domain, restoring HVM context and
+ *             HVM params for the new domain
+ *         for the new domain:
+ *           libxl__toolstack_save()
+ *           libxl__toolstack_restore()
+ *         libxl__xc_domain_restore_done() and following the standard 'restore'
+ *             path.
+ */
+
+_hidden void libxl__xc_domain_soft_reset(libxl__egc *egc,
+                                         libxl__domain_create_state *dcs);
+
 _hidden int libxl__domain_soft_reset_destroy(libxl__gc *gc, uint32_t domid,
                                              const libxl_asyncop_how *ao_how);
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 4a0e2be..10ef652 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -121,6 +121,8 @@ libxl_action_on_shutdown = Enumeration("action_on_shutdown", [
 
     (5, "COREDUMP_DESTROY"),
     (6, "COREDUMP_RESTART"),
+
+    (7, "SOFT_RESET"),
     ], init_val = "LIBXL_ACTION_ON_SHUTDOWN_DESTROY")
 
 libxl_trigger = Enumeration("trigger", [
@@ -558,6 +560,7 @@ libxl_domain_config = Struct("domain_config", [
     ("on_reboot", libxl_action_on_shutdown),
     ("on_watchdog", libxl_action_on_shutdown),
     ("on_crash", libxl_action_on_shutdown),
+    ("on_soft_reset", libxl_action_on_shutdown),
     ], dir=DIR_IN)
 
 libxl_diskinfo = Struct("diskinfo", [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index b193c3c..d3ce409 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -130,6 +130,8 @@ static const char *action_on_shutdown_names[] = {
 
     [LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY] = "coredump-destroy",
     [LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART] = "coredump-restart",
+
+    [LIBXL_ACTION_ON_SHUTDOWN_SOFT_RESET] = "soft-reset",
 };
 
 /* Optional data, in order:
@@ -1067,6 +1069,13 @@ static void parse_config_data(const char *config_source,
         exit(1);
     }
 
+    if (xlu_cfg_get_string (config, "on_soft_reset", &buf, 0))
+        buf = "soft-reset";
+    if (!parse_action_on_shutdown(buf, &d_config->on_soft_reset)) {
+        fprintf(stderr, "Unknown on_soft_reset action \"%s\" specified\n", buf);
+        exit(1);
+    }
+
     /* libxl_get_required_shadow_memory() must be called after final values
      * (default or specified) for vcpus and memory are set, because the
      * calculation depends on those values. */
@@ -2052,7 +2061,8 @@ static void reload_domain_config(uint32_t domid,
 }
 
 /* Returns 1 if domain should be restarted,
- * 2 if domain should be renamed then restarted, or 0
+ * 2 if domain should be renamed then restarted,
+ * 3 if domain performed soft reset, or 0
  * Can update r_domid if domain is destroyed etc */
 static int handle_domain_death(uint32_t *r_domid,
                                libxl_event *event,
@@ -2078,6 +2088,9 @@ static int handle_domain_death(uint32_t *r_domid,
     case LIBXL_SHUTDOWN_REASON_WATCHDOG:
         action = d_config->on_watchdog;
         break;
+    case LIBXL_SHUTDOWN_REASON_SOFT_RESET:
+        action = d_config->on_soft_reset;
+        break;
     default:
         LOG("Unknown shutdown reason code %d. Destroying domain.",
             event->u.domain_shutdown.shutdown_reason);
@@ -2128,6 +2141,11 @@ static int handle_domain_death(uint32_t *r_domid,
         *r_domid = INVALID_DOMID;
         break;
 
+    case LIBXL_ACTION_ON_SHUTDOWN_SOFT_RESET:
+        reload_domain_config(*r_domid, d_config);
+        restart = 3;
+        break;
+
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY:
     case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART:
         /* Already handled these above. */
@@ -2294,6 +2312,7 @@ static void evdisable_disk_ejects(libxl_evgen_disk_eject **diskws,
 static uint32_t create_domain(struct domain_create *dom_info)
 {
     uint32_t domid = INVALID_DOMID;
+    uint32_t domid_old = INVALID_DOMID;
 
     libxl_domain_config d_config;
 
@@ -2519,7 +2538,17 @@ start:
          * restore/migrate-receive it again.
          */
         restoring = 0;
-    }else{
+    } else if (domid_old != INVALID_DOMID) {
+        /* Do soft reset */
+        ret = libxl_domain_soft_reset(ctx, &d_config,
+                                      &domid, domid_old,
+                                      0, 0);
+
+        if ( ret ) {
+            goto error_out;
+        }
+        domid_old = INVALID_DOMID;
+    } else {
         ret = libxl_domain_create_new(ctx, &d_config, &domid,
                                       0, autoconnect_console_how);
     }
@@ -2583,6 +2612,8 @@ start:
                 event->u.domain_shutdown.shutdown_reason,
                 event->u.domain_shutdown.shutdown_reason);
             switch (handle_domain_death(&domid, event, &d_config)) {
+            case 3:
+                domid_old = domid;
             case 2:
                 if (!preserve_domain(&domid, event, &d_config)) {
                     /* If we fail then exit leaving the old domain in place. */
-- 
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 Dec 11 14:29:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 14: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 1Xz4kY-0003Dw-Sj; Thu, 11 Dec 2014 14:29:50 +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 1Xz4kX-0003Dk-Kj
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 14:29:49 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	D3/AB-02696-C5AA9845; Thu, 11 Dec 2014 14:29:48 +0000
X-Env-Sender: vkuznets@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418308183!14488796!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32625 invoked from network); 11 Dec 2014 14:29:45 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 14:29:45 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBBETRJg012032
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Thu, 11 Dec 2014 09:29:32 -0500
Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBBDjgW3013088; Thu, 11 Dec 2014 08:45:43 -0500
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: xen-devel@lists.xenproject.org
Date: Thu, 11 Dec 2014 14:45:32 +0100
Message-Id: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>,
	Keir Fraser <keir@xen.org>, 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>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH v5 0/9] 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>
MIME-Version: 1.0
Content-Type: text/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 provides x86 PVHVM domains with an ability to perform
kexec/kdump.

Changes from v4:
- "on_soft_reset" option was introduced, now it's possible to specify the behavior
  [Wei Liu]
- renamed libxl__domain_soft_reset_destroy_old to libxl__domain_soft_reset_destroy
- libxl__domain_soft_reset_destroy now takes gc instead of ctx, coding style fix
  [Wei Liu]
- remove forgotten 'd_config.b_info.nodemap.size = 0' hackaround, add
  reload_domain_config() on soft reset path [Wei Liu]
- add whole procedure description to libxl_internal.h [Wei Liu]
- reword 'recipient' description in struct domain [Julien Grall]

Nothing was done with regards to ARM. It seems that correct implementation of
mfn_to_gmfn() returning propper gmfn for DomUs is the desirable solution in the
long run, however, any additional thoughts here are more than wellcome! 

Changes from RFCv3:
This is the first non-RFC series as no major concerns were expressed. I'm trying
to address Jan's comments. Changes are:
- Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really like
  the name but nothing more appropriate came to my mind) which incorporates
  former XEN_DOMCTL_set_recipient and XEN_DOMCTL_destroydomain to prevent
  original domain from changing its allocations during transfer procedure.
- Check in free_domheap_pages() that assign_pages() succeeded.
- Change printk() in free_domheap_pages().
- DOMDYING_locked state was introduced to support XEN_DOMCTL_devour.
- xc_domain_soft_reset() got simplified a bit. Now we just wait for the original
  domain to die or loose all its pages.
- rebased on top of current master branch.

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.

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.

Previous discussions:
This patch series:
http://lists.xen.org/archives/html/xen-devel/2014-12/msg00432.html
http://lists.xen.org/archives/html/xen-devel/2014-10/msg00764.html
http://lists.xen.org/archives/html/xen-devel/2014-09/msg03623.html
http://lists.xen.org/archives/html/xen-devel/2014-08/msg02309.html

on resetting VCPU_info (and that's where 'rebuild everything with the
toolstack solution' was suggested):
http://lists.xen.org/archives/html/xen-devel/2014-08/msg01869.html
Previous versions:
http://lists.xen.org/archives/html/xen-devel/2014-08/msg01630.html
http://lists.xen.org/archives/html/xen-devel/2014-08/msg00603.html

EVTCHNOP_reset (got merged):
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03979.html
Previous:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03925.html
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03322.html
http://lists.xen.org/archives/html/xen-devel/2014-07/msg02500.html

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 (9):
  xen: introduce DOMDYING_locked state
  xen: introduce SHUTDOWN_soft_reset shutdown reason
  libxl: support SHUTDOWN_soft_reset shutdown reason
  xen: introduce XEN_DOMCTL_devour
  libxc: support XEN_DOMCTL_devour
  libxl: add libxl__domain_soft_reset_destroy()
  libxc: introduce soft reset for HVM domains
  libxl: soft reset support
  xsm: add XEN_DOMCTL_devour support

 docs/man/xl.cfg.pod.5               |  12 ++
 tools/libxc/Makefile                |   1 +
 tools/libxc/include/xenctrl.h       |  14 ++
 tools/libxc/include/xenguest.h      |  20 +++
 tools/libxc/xc_domain.c             |  13 ++
 tools/libxc/xc_domain_soft_reset.c  | 282 ++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl.c                 |  33 ++++-
 tools/libxl/libxl.h                 |   6 +
 tools/libxl/libxl_create.c          | 103 +++++++++++--
 tools/libxl/libxl_internal.h        |  30 ++++
 tools/libxl/libxl_types.idl         |   4 +
 tools/libxl/xl_cmdimpl.c            |  37 ++++-
 tools/python/xen/lowlevel/xl/xl.c   |   1 +
 xen/common/domain.c                 |   4 +
 xen/common/domctl.c                 |  39 +++++
 xen/common/page_alloc.c             |  28 +++-
 xen/common/shutdown.c               |   7 +
 xen/include/public/domctl.h         |  15 ++
 xen/include/public/sched.h          |   3 +-
 xen/include/xen/sched.h             |   5 +-
 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 ++
 25 files changed, 674 insertions(+), 23 deletions(-)
 create mode 100644 tools/libxc/xc_domain_soft_reset.c

-- 
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 Dec 11 14:42:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 14:42:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz4wc-00049N-4y; Thu, 11 Dec 2014 14:42:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1Xz4wa-00049I-NP
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 14:42:16 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	A9/48-26652-74DA9845; Thu, 11 Dec 2014 14:42:15 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418308934!12819745!1
X-Originating-IP: [96.126.108.55]
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 18500 invoked from network); 11 Dec 2014 14:42:15 -0000
Received: from mail1.linode.com (HELO mail1.linode.com) (96.126.108.55)
	by server-5.tower-206.messagelabs.com with SMTP;
	11 Dec 2014 14:42:15 -0000
Received: from imap-newark.linode.com (unknown
	[IPv6:2600:3c03::f03c:91ff:fedf:57d1])
	by mail1.linode.com (Postfix) with ESMTP id 64506265F7
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 09:42:14 -0500 (EST)
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by imap-newark.linode.com (Postfix) with ESMTPSA id 570C3AA4F
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 09:42:14 -0500 (EST)
From: "Christopher S. Aker" <caker@theshore.net>
Message-Id: <B5D21A64-6E2E-4FB4-B970-DB90B815A93E@theshore.net>
Date: Thu, 11 Dec 2014 09:42:13 -0500
To: xen devel <xen-devel@lists.xensource.com>
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
X-Mailer: Apple Mail (2.1990.1)
Subject: [Xen-devel] netback: Carrier off / Carrier on again, rinse, repeat
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
Dom0: 3.17.4

We recently moved our dom0 from 3.10.x to 3.17.4, in order to avoid a netback host crash that has been plaguing us.  After doing so, the new multi-queue netback stuff constantly on/offs carrier on the vif, spamming the console, and making the bridge device leave forwarding state and then immediately reenter forwarding state.

vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
br0: port 44(vif43.0) entered disabled state
vif vif-43-0 vif43.0: Carrier on again
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
br0: port 44(vif43.0) entered disabled state
vif vif-43-0 vif43.0: Carrier on again
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
vif vif-113-0 vif113.0: Carrier off due to lack of guest response on queue 0
br0: port 108(vif113.0) entered disabled state
vif vif-113-0 vif113.0: Carrier on again
br0: port 108(vif113.0) entered forwarding state
br0: port 108(vif113.0) entered forwarding state
br0: port 108(vif113.0) entered forwarding state
vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
br0: port 44(vif43.0) entered disabled state
vif vif-43-0 vif43.0: Carrier on again
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
br0: port 44(vif43.0) entered disabled state
vif vif-43-0 vif43.0: Carrier on again
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state

(This is in the span of a few minutes, however it is non-stop)

If this is normal expected operation then obviously we can live with the console messages, but - I just wanted to report this in the case it is not expected behavior.

Thanks,
-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 14:42:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 14:42:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz4wc-00049N-4y; Thu, 11 Dec 2014 14:42:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1Xz4wa-00049I-NP
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 14:42:16 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	A9/48-26652-74DA9845; Thu, 11 Dec 2014 14:42:15 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418308934!12819745!1
X-Originating-IP: [96.126.108.55]
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 18500 invoked from network); 11 Dec 2014 14:42:15 -0000
Received: from mail1.linode.com (HELO mail1.linode.com) (96.126.108.55)
	by server-5.tower-206.messagelabs.com with SMTP;
	11 Dec 2014 14:42:15 -0000
Received: from imap-newark.linode.com (unknown
	[IPv6:2600:3c03::f03c:91ff:fedf:57d1])
	by mail1.linode.com (Postfix) with ESMTP id 64506265F7
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 09:42:14 -0500 (EST)
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by imap-newark.linode.com (Postfix) with ESMTPSA id 570C3AA4F
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 09:42:14 -0500 (EST)
From: "Christopher S. Aker" <caker@theshore.net>
Message-Id: <B5D21A64-6E2E-4FB4-B970-DB90B815A93E@theshore.net>
Date: Thu, 11 Dec 2014 09:42:13 -0500
To: xen devel <xen-devel@lists.xensource.com>
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
X-Mailer: Apple Mail (2.1990.1)
Subject: [Xen-devel] netback: Carrier off / Carrier on again, rinse, repeat
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
Dom0: 3.17.4

We recently moved our dom0 from 3.10.x to 3.17.4, in order to avoid a netback host crash that has been plaguing us.  After doing so, the new multi-queue netback stuff constantly on/offs carrier on the vif, spamming the console, and making the bridge device leave forwarding state and then immediately reenter forwarding state.

vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
br0: port 44(vif43.0) entered disabled state
vif vif-43-0 vif43.0: Carrier on again
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
br0: port 44(vif43.0) entered disabled state
vif vif-43-0 vif43.0: Carrier on again
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
vif vif-113-0 vif113.0: Carrier off due to lack of guest response on queue 0
br0: port 108(vif113.0) entered disabled state
vif vif-113-0 vif113.0: Carrier on again
br0: port 108(vif113.0) entered forwarding state
br0: port 108(vif113.0) entered forwarding state
br0: port 108(vif113.0) entered forwarding state
vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
br0: port 44(vif43.0) entered disabled state
vif vif-43-0 vif43.0: Carrier on again
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
br0: port 44(vif43.0) entered disabled state
vif vif-43-0 vif43.0: Carrier on again
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state
br0: port 44(vif43.0) entered forwarding state

(This is in the span of a few minutes, however it is non-stop)

If this is normal expected operation then obviously we can live with the console messages, but - I just wanted to report this in the case it is not expected behavior.

Thanks,
-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 15:00:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 15: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 1Xz5DT-0004fk-W5; Thu, 11 Dec 2014 14:59:43 +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 1Xz5DR-0004ff-NG
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 14:59:41 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	FD/5B-02702-C51B9845; Thu, 11 Dec 2014 14:59:40 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418309980!14477535!1
X-Originating-IP: [74.125.82.44]
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 11029 invoked from network); 11 Dec 2014 14:59:40 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 14:59:40 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so6640537wgh.3
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 06:59: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
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=MESHo13zmQMuBUJ1/s6aekXwLOOLwCggIFLMG6/pQJ0=;
	b=W0wABj/zBk0BlVABn8BKfOz7SiMbRdwWR0EFAxWIv/vsBg5pgV6VdTRE9iZw3WV9HX
	E3Z4rvH0xV8DGL7Bu9Ausuy3l0ZVUTF+EqXHend67byWHM4SADd+ynOfuXtYATftvvAP
	SL5aKy4beaVhmwmCd6H2OVI45ackWTOpmbMmegHpg936DbxtE4uC3R09AJ+u3BqFnGBL
	UTyPyvrXFqvSWMKDMnuA4iyz2A8rYxJUBvwswWQOrqLXSPv1h/MYlsLll4c6JfP3qn8P
	V6qQm54IRMoHzAL8yaBi2bQIIcgjRPVke3CNhxQngzMurKCz/Nbed5Qp3iaMnHlugWgB
	8slw==
X-Gm-Message-State: ALoCoQlFlUzbBRUABkY2/g0d1ZXw4kx/za2RoLJyfZZ87gs7uxuwArhmRrsRJUG33KGsffU+orqf
X-Received: by 10.194.63.229 with SMTP id j5mr17749884wjs.23.1418309979965;
	Thu, 11 Dec 2014 06:59:39 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id nj9sm2639110wic.10.2014.12.11.06.59.38
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 06:59:39 -0800 (PST)
Message-ID: <5489B15B.9040506@linaro.org>
Date: Thu, 11 Dec 2014 14:59: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.3.0
MIME-Version: 1.0
To: "Christopher S. Aker" <caker@theshore.net>, 
	xen devel <xen-devel@lists.xensource.com>
References: <B5D21A64-6E2E-4FB4-B970-DB90B815A93E@theshore.net>
In-Reply-To: <B5D21A64-6E2E-4FB4-B970-DB90B815A93E@theshore.net>
Subject: Re: [Xen-devel] netback: Carrier off / Carrier on again, rinse,
	repeat
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

This has been fixed by "f48da8: xen-netback: fix unlimited guest Rx 
internal queue and carrier flapping", it's already in 3.18, I don't know 
if it is going to be backported to 3.17

Zoli

On 11/12/14 14:42, Christopher S. Aker wrote:
> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
> Dom0: 3.17.4
>
> We recently moved our dom0 from 3.10.x to 3.17.4, in order to avoid a netback host crash that has been plaguing us.  After doing so, the new multi-queue netback stuff constantly on/offs carrier on the vif, spamming the console, and making the bridge device leave forwarding state and then immediately reenter forwarding state.
>
> vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
> br0: port 44(vif43.0) entered disabled state
> vif vif-43-0 vif43.0: Carrier on again
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
> br0: port 44(vif43.0) entered disabled state
> vif vif-43-0 vif43.0: Carrier on again
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> vif vif-113-0 vif113.0: Carrier off due to lack of guest response on queue 0
> br0: port 108(vif113.0) entered disabled state
> vif vif-113-0 vif113.0: Carrier on again
> br0: port 108(vif113.0) entered forwarding state
> br0: port 108(vif113.0) entered forwarding state
> br0: port 108(vif113.0) entered forwarding state
> vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
> br0: port 44(vif43.0) entered disabled state
> vif vif-43-0 vif43.0: Carrier on again
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
> br0: port 44(vif43.0) entered disabled state
> vif vif-43-0 vif43.0: Carrier on again
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
>
> (This is in the span of a few minutes, however it is non-stop)
>
> If this is normal expected operation then obviously we can live with the console messages, but - I just wanted to report this in the case it is not expected behavior.
>
> Thanks,
> -Chris
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 15:00:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 15: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 1Xz5DT-0004fk-W5; Thu, 11 Dec 2014 14:59:43 +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 1Xz5DR-0004ff-NG
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 14:59:41 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	FD/5B-02702-C51B9845; Thu, 11 Dec 2014 14:59:40 +0000
X-Env-Sender: zoltan.kiss@linaro.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418309980!14477535!1
X-Originating-IP: [74.125.82.44]
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 11029 invoked from network); 11 Dec 2014 14:59:40 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 14:59:40 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so6640537wgh.3
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 06:59: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
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=MESHo13zmQMuBUJ1/s6aekXwLOOLwCggIFLMG6/pQJ0=;
	b=W0wABj/zBk0BlVABn8BKfOz7SiMbRdwWR0EFAxWIv/vsBg5pgV6VdTRE9iZw3WV9HX
	E3Z4rvH0xV8DGL7Bu9Ausuy3l0ZVUTF+EqXHend67byWHM4SADd+ynOfuXtYATftvvAP
	SL5aKy4beaVhmwmCd6H2OVI45ackWTOpmbMmegHpg936DbxtE4uC3R09AJ+u3BqFnGBL
	UTyPyvrXFqvSWMKDMnuA4iyz2A8rYxJUBvwswWQOrqLXSPv1h/MYlsLll4c6JfP3qn8P
	V6qQm54IRMoHzAL8yaBi2bQIIcgjRPVke3CNhxQngzMurKCz/Nbed5Qp3iaMnHlugWgB
	8slw==
X-Gm-Message-State: ALoCoQlFlUzbBRUABkY2/g0d1ZXw4kx/za2RoLJyfZZ87gs7uxuwArhmRrsRJUG33KGsffU+orqf
X-Received: by 10.194.63.229 with SMTP id j5mr17749884wjs.23.1418309979965;
	Thu, 11 Dec 2014 06:59:39 -0800 (PST)
Received: from [192.168.0.101] ([90.152.119.35])
	by mx.google.com with ESMTPSA id nj9sm2639110wic.10.2014.12.11.06.59.38
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 06:59:39 -0800 (PST)
Message-ID: <5489B15B.9040506@linaro.org>
Date: Thu, 11 Dec 2014 14:59: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.3.0
MIME-Version: 1.0
To: "Christopher S. Aker" <caker@theshore.net>, 
	xen devel <xen-devel@lists.xensource.com>
References: <B5D21A64-6E2E-4FB4-B970-DB90B815A93E@theshore.net>
In-Reply-To: <B5D21A64-6E2E-4FB4-B970-DB90B815A93E@theshore.net>
Subject: Re: [Xen-devel] netback: Carrier off / Carrier on again, rinse,
	repeat
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

This has been fixed by "f48da8: xen-netback: fix unlimited guest Rx 
internal queue and carrier flapping", it's already in 3.18, I don't know 
if it is going to be backported to 3.17

Zoli

On 11/12/14 14:42, Christopher S. Aker wrote:
> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
> Dom0: 3.17.4
>
> We recently moved our dom0 from 3.10.x to 3.17.4, in order to avoid a netback host crash that has been plaguing us.  After doing so, the new multi-queue netback stuff constantly on/offs carrier on the vif, spamming the console, and making the bridge device leave forwarding state and then immediately reenter forwarding state.
>
> vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
> br0: port 44(vif43.0) entered disabled state
> vif vif-43-0 vif43.0: Carrier on again
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
> br0: port 44(vif43.0) entered disabled state
> vif vif-43-0 vif43.0: Carrier on again
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> vif vif-113-0 vif113.0: Carrier off due to lack of guest response on queue 0
> br0: port 108(vif113.0) entered disabled state
> vif vif-113-0 vif113.0: Carrier on again
> br0: port 108(vif113.0) entered forwarding state
> br0: port 108(vif113.0) entered forwarding state
> br0: port 108(vif113.0) entered forwarding state
> vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
> br0: port 44(vif43.0) entered disabled state
> vif vif-43-0 vif43.0: Carrier on again
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> vif vif-43-0 vif43.0: Carrier off due to lack of guest response on queue 0
> br0: port 44(vif43.0) entered disabled state
> vif vif-43-0 vif43.0: Carrier on again
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
> br0: port 44(vif43.0) entered forwarding state
>
> (This is in the span of a few minutes, however it is non-stop)
>
> If this is normal expected operation then obviously we can live with the console messages, but - I just wanted to report this in the case it is not expected behavior.
>
> Thanks,
> -Chris
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 15:13:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 15:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz5QJ-0005Sz-Gn; Thu, 11 Dec 2014 15:12:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1Xz5QH-0005Qf-VW
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 15:12:58 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	1F/99-09284-974B9845; Thu, 11 Dec 2014 15:12:57 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418310775!12538476!1
X-Originating-IP: [96.126.108.55]
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 5440 invoked from network); 11 Dec 2014 15:12:55 -0000
Received: from mail1.linode.com (HELO mail1.linode.com) (96.126.108.55)
	by server-15.tower-31.messagelabs.com with SMTP;
	11 Dec 2014 15:12:55 -0000
Received: from imap-newark.linode.com (imap-newark.linode.com [69.164.208.11])
	by mail1.linode.com (Postfix) with ESMTP id 3F9EA26643
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 10:12:55 -0500 (EST)
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by imap-newark.linode.com (Postfix) with ESMTPSA id 2A57BAA4F
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 10:12:55 -0500 (EST)
From: "Christopher S. Aker" <caker@theshore.net>
Message-Id: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>
Date: Thu, 11 Dec 2014 10:12:54 -0500
To: xen devel <xen-devel@lists.xensource.com>
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
X-Mailer: Apple Mail (2.1990.1)
Subject: [Xen-devel] WARNING: at drivers/xen/gntdev.c:426
	unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
Dom0: 3.17.4

Things go badly after a day or four.  We've hit this on a number of previously healthy hosts, since moving from 3.10.x dom0 to 3.17.4:

printk: 5441 messages suppressed.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
(XEN) printk: 4857 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 4846 callbacks suppressed
(XEN) printk: 4699 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1569 callbacks suppressed
(XEN) printk: 1809 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 2327 callbacks suppressed
(XEN) printk: 2779 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 2509 callbacks suppressed
(XEN) printk: 2022 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 2282 callbacks suppressed
(XEN) printk: 2778 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 2385 callbacks suppressed
(XEN) printk: 1560 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1714 callbacks suppressed
(XEN) printk: 1713 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1619 callbacks suppressed
(XEN) printk: 1852 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1895 callbacks suppressed
(XEN) printk: 2058 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1797 callbacks suppressed
(XEN) printk: 1530 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1440 callbacks suppressed
(XEN) printk: 1306 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.

(...this repeats a few hundred times over the course of 30 minutes...)

net_ratelimit: 1221 callbacks suppressed
(XEN) printk: 1719 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1747 callbacks suppressed
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1496 callbacks suppressed
br0: port 80(vif242.0) entered disabled state
device vif242.0 left promiscuous mode
br0: port 80(vif242.0) entered disabled state
device vif249.0 entered promiscuous mode
xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi) persistent grants
xen-blkback:ring-ref 9, event-channel 10, protocol 1 (x86_64-abi) persistent grants
(XEN) printk: 1107 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 648 callbacks suppressed
m2p_remove_override: pfn 10828f2 mfn 8000000005b4284e, failed to modify kernel mappings
------------[ cut here ]------------
WARNING: CPU: 6 PID: 23911 at drivers/xen/gntdev.c:426 unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
Modules linked in: xt_u32 xt_physdev ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ip6table_mangle ip6_tables ebtable_nat xen_acpi_processor xen_pciback xen_gntalloc xen_gntdev bonding ebtable_filter 8021q mrp ixgbe mdio ptp pps_core
CPU: 6 PID: 23911 Comm: qemu-dm Not tainted 3.17.4-1 #1
Hardware name: Supermicro X9DRE-TF+/X9DR7-TF+/X9DRE-TF+/X9DR7-TF+, BIOS 3.0a 12/04/2013
 0000000000000009 ffff880043dafcc8 ffffffff81876bcb 0000000000000001
 0000000000000000 ffff880043dafd08 ffffffff81069777 ffff880043dafd18
 ffff880020154690 00007f8add804000 00007f8add80f000 ffff880020154660
Call Trace:
 [<ffffffff81876bcb>] dump_stack+0x46/0x58
 [<ffffffff81069777>] warn_slowpath_common+0x87/0xb0
 [<ffffffff810697b5>] warn_slowpath_null+0x15/0x20
 [<ffffffffa012d29d>] unmap_if_in_range+0x5d/0x60 [xen_gntdev]
 [<ffffffffa012d46e>] mn_invl_range_start+0x4e/0xa0 [xen_gntdev]
 [<ffffffff811615cb>] __mmu_notifier_invalidate_range_start+0x5b/0x90
 [<ffffffff811469a9>] unmap_vmas+0x79/0x90
 [<ffffffff8114bb13>] unmap_region+0xa3/0x120
 [<ffffffff8116b339>] ? new_sync_read+0x79/0xb0
 [<ffffffff8114bfb1>] ? vma_rb_erase+0x121/0x210
 [<ffffffff8114dba0>] do_munmap+0x2a0/0x3b0
 [<ffffffff8114dcf9>] vm_munmap+0x49/0x70
 [<ffffffff8114ecd6>] SyS_munmap+0x26/0x40
 [<ffffffff81880169>] system_call_fastpath+0x16/0x1b
---[ end trace 25ca87f9adc0ad78 ]---
INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 32, t=60002 jiffies, g=26177592, c=26177591, q=1229)
Task dump for CPU 0:
swapper/0       R  running task    14072     0      0 0x00000008
 00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
 ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
 000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
Call Trace:
 [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
 [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
 [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
 [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
 [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
 [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
 [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
 [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
 [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
 [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 34, t=240007 jiffies, g=26177592, c=26177591, q=4592)
Task dump for CPU 0:
swapper/0       R  running task    14072     0      0 0x00000008
 00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
 ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
 000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
Call Trace:
 [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
 [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
 [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
 [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
 [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
 [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
 [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
 [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
 [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
 [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 34, t=420012 jiffies, g=26177592, c=26177591, q=8255)
Task dump for CPU 0:
swapper/0       R  running task    14072     0      0 0x00000008
 00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
 ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
 000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
Call Trace:
 [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
 [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
 [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
 [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
 [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
 [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
 [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
 [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
 [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
 [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542

Then the dom0 is unresponsive, and requires a reboot.

Any ideas?

-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 15:13:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 15:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz5QJ-0005Sz-Gn; Thu, 11 Dec 2014 15:12:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1Xz5QH-0005Qf-VW
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 15:12:58 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	1F/99-09284-974B9845; Thu, 11 Dec 2014 15:12:57 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418310775!12538476!1
X-Originating-IP: [96.126.108.55]
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 5440 invoked from network); 11 Dec 2014 15:12:55 -0000
Received: from mail1.linode.com (HELO mail1.linode.com) (96.126.108.55)
	by server-15.tower-31.messagelabs.com with SMTP;
	11 Dec 2014 15:12:55 -0000
Received: from imap-newark.linode.com (imap-newark.linode.com [69.164.208.11])
	by mail1.linode.com (Postfix) with ESMTP id 3F9EA26643
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 10:12:55 -0500 (EST)
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by imap-newark.linode.com (Postfix) with ESMTPSA id 2A57BAA4F
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Dec 2014 10:12:55 -0500 (EST)
From: "Christopher S. Aker" <caker@theshore.net>
Message-Id: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>
Date: Thu, 11 Dec 2014 10:12:54 -0500
To: xen devel <xen-devel@lists.xensource.com>
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
X-Mailer: Apple Mail (2.1990.1)
Subject: [Xen-devel] WARNING: at drivers/xen/gntdev.c:426
	unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
Dom0: 3.17.4

Things go badly after a day or four.  We've hit this on a number of previously healthy hosts, since moving from 3.10.x dom0 to 3.17.4:

printk: 5441 messages suppressed.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
grant_table.c:567:d0 Failed to obtain maptrack handle.
(XEN) printk: 4857 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 4846 callbacks suppressed
(XEN) printk: 4699 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1569 callbacks suppressed
(XEN) printk: 1809 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 2327 callbacks suppressed
(XEN) printk: 2779 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 2509 callbacks suppressed
(XEN) printk: 2022 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 2282 callbacks suppressed
(XEN) printk: 2778 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 2385 callbacks suppressed
(XEN) printk: 1560 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1714 callbacks suppressed
(XEN) printk: 1713 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1619 callbacks suppressed
(XEN) printk: 1852 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1895 callbacks suppressed
(XEN) printk: 2058 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1797 callbacks suppressed
(XEN) printk: 1530 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1440 callbacks suppressed
(XEN) printk: 1306 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.

(...this repeats a few hundred times over the course of 30 minutes...)

net_ratelimit: 1221 callbacks suppressed
(XEN) printk: 1719 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1747 callbacks suppressed
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 1496 callbacks suppressed
br0: port 80(vif242.0) entered disabled state
device vif242.0 left promiscuous mode
br0: port 80(vif242.0) entered disabled state
device vif249.0 entered promiscuous mode
xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi) persistent grants
xen-blkback:ring-ref 9, event-channel 10, protocol 1 (x86_64-abi) persistent grants
(XEN) printk: 1107 messages suppressed.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
(XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
net_ratelimit: 648 callbacks suppressed
m2p_remove_override: pfn 10828f2 mfn 8000000005b4284e, failed to modify kernel mappings
------------[ cut here ]------------
WARNING: CPU: 6 PID: 23911 at drivers/xen/gntdev.c:426 unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
Modules linked in: xt_u32 xt_physdev ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ip6table_mangle ip6_tables ebtable_nat xen_acpi_processor xen_pciback xen_gntalloc xen_gntdev bonding ebtable_filter 8021q mrp ixgbe mdio ptp pps_core
CPU: 6 PID: 23911 Comm: qemu-dm Not tainted 3.17.4-1 #1
Hardware name: Supermicro X9DRE-TF+/X9DR7-TF+/X9DRE-TF+/X9DR7-TF+, BIOS 3.0a 12/04/2013
 0000000000000009 ffff880043dafcc8 ffffffff81876bcb 0000000000000001
 0000000000000000 ffff880043dafd08 ffffffff81069777 ffff880043dafd18
 ffff880020154690 00007f8add804000 00007f8add80f000 ffff880020154660
Call Trace:
 [<ffffffff81876bcb>] dump_stack+0x46/0x58
 [<ffffffff81069777>] warn_slowpath_common+0x87/0xb0
 [<ffffffff810697b5>] warn_slowpath_null+0x15/0x20
 [<ffffffffa012d29d>] unmap_if_in_range+0x5d/0x60 [xen_gntdev]
 [<ffffffffa012d46e>] mn_invl_range_start+0x4e/0xa0 [xen_gntdev]
 [<ffffffff811615cb>] __mmu_notifier_invalidate_range_start+0x5b/0x90
 [<ffffffff811469a9>] unmap_vmas+0x79/0x90
 [<ffffffff8114bb13>] unmap_region+0xa3/0x120
 [<ffffffff8116b339>] ? new_sync_read+0x79/0xb0
 [<ffffffff8114bfb1>] ? vma_rb_erase+0x121/0x210
 [<ffffffff8114dba0>] do_munmap+0x2a0/0x3b0
 [<ffffffff8114dcf9>] vm_munmap+0x49/0x70
 [<ffffffff8114ecd6>] SyS_munmap+0x26/0x40
 [<ffffffff81880169>] system_call_fastpath+0x16/0x1b
---[ end trace 25ca87f9adc0ad78 ]---
INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 32, t=60002 jiffies, g=26177592, c=26177591, q=1229)
Task dump for CPU 0:
swapper/0       R  running task    14072     0      0 0x00000008
 00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
 ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
 000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
Call Trace:
 [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
 [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
 [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
 [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
 [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
 [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
 [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
 [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
 [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
 [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 34, t=240007 jiffies, g=26177592, c=26177591, q=4592)
Task dump for CPU 0:
swapper/0       R  running task    14072     0      0 0x00000008
 00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
 ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
 000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
Call Trace:
 [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
 [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
 [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
 [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
 [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
 [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
 [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
 [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
 [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
 [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 34, t=420012 jiffies, g=26177592, c=26177591, q=8255)
Task dump for CPU 0:
swapper/0       R  running task    14072     0      0 0x00000008
 00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
 ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
 000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
Call Trace:
 [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
 [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
 [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
 [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
 [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
 [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
 [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
 [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
 [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
 [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542

Then the dom0 is unresponsive, and requires a reboot.

Any ideas?

-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 15:14:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 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 1Xz5SD-0005bk-0X; Thu, 11 Dec 2014 15:14:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bjoern@clothesnetwork.com>) id 1Xz1I1-0004SW-2n
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 10:48:09 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	FC/D5-01660-86679845; Thu, 11 Dec 2014 10:48:08 +0000
X-Env-Sender: bjoern@clothesnetwork.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418294887!7480414!1
X-Originating-IP: [213.239.215.232]
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 26382 invoked from network); 11 Dec 2014 10:48:08 -0000
Received: from 213-239-215-232.clients.your-server.de (HELO ?213.239.215.232?)
	(213.239.215.232) by server-10.tower-206.messagelabs.com with SMTP;
	11 Dec 2014 10:48:08 -0000
Received: from localhost (localhost [127.0.0.1])
	by thewebagency.org (Postfix) with ESMTP id ED08F80463;
	Thu, 11 Dec 2014 11:48:07 +0100 (CET)
Received: from [213.239.215.232] ([10.0.0.2])
	by localhost (mail.thewebagency.org [10.0.0.2]) (amavisd-new,
	port 10024)
	with ESMTP id qOWbD1t35EoD; Thu, 11 Dec 2014 11:48:07 +0100 (CET)
Received: from localhost (unknown [88.96.159.118])
	by thewebagency.org (Postfix) with ESMTPSA id F413B80525;
	Thu, 11 Dec 2014 11:48:06 +0100 (CET)
Date: Thu, 11 Dec 2014 10:41:54 +0000
From: Bjoern Rennhak <bjoern@clothesnetwork.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141211104154.GB20557@rennhak.de>
References: <20141210202525.GA20557@rennhak.de>
	<20141211001931.GA25476@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141211001931.GA25476@zion.uk.xensource.com>
X-URL: http://www.rennhak.com/
X-Operating-System: GNU/Linux Gentoo - Linux 3.13.0-rc3-linus-git-rennhak+ on
	a i686
X-Registered-Linux-User: 451519
X-Crypto: GnuPG/2.0.25 http://www.gnupg.org
X-GPG-Key-ID: 0x1122967D
X-GPG-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE9EE5EBA1122967D
X-GPG-Fingerprint: B2CC 3175 3A25 9616 F121 90FB E9EE 5EBA 1122 967D
X-Uptime: 11:30:15 up 18 days, 12:17, 13 users,  load average: 0.08, 0.05, 0.10
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Mailman-Approved-At: Thu, 11 Dec 2014 15:14:55 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Question reg. named vif interface support in guest
 cfg; 
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wei,

> > So instead of a bunch of vifx.y's I would see <descriptivename>x.y ?
> Check out
> http://xenbits.xen.org/docs/4.4-testing/misc/xl-network-configuration.html
> vifname

Sorry must have overlooked that, thank you!

-Bjoern

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 15:14:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 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 1Xz5SD-0005bk-0X; Thu, 11 Dec 2014 15:14:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bjoern@clothesnetwork.com>) id 1Xz1I1-0004SW-2n
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 10:48:09 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	FC/D5-01660-86679845; Thu, 11 Dec 2014 10:48:08 +0000
X-Env-Sender: bjoern@clothesnetwork.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418294887!7480414!1
X-Originating-IP: [213.239.215.232]
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 26382 invoked from network); 11 Dec 2014 10:48:08 -0000
Received: from 213-239-215-232.clients.your-server.de (HELO ?213.239.215.232?)
	(213.239.215.232) by server-10.tower-206.messagelabs.com with SMTP;
	11 Dec 2014 10:48:08 -0000
Received: from localhost (localhost [127.0.0.1])
	by thewebagency.org (Postfix) with ESMTP id ED08F80463;
	Thu, 11 Dec 2014 11:48:07 +0100 (CET)
Received: from [213.239.215.232] ([10.0.0.2])
	by localhost (mail.thewebagency.org [10.0.0.2]) (amavisd-new,
	port 10024)
	with ESMTP id qOWbD1t35EoD; Thu, 11 Dec 2014 11:48:07 +0100 (CET)
Received: from localhost (unknown [88.96.159.118])
	by thewebagency.org (Postfix) with ESMTPSA id F413B80525;
	Thu, 11 Dec 2014 11:48:06 +0100 (CET)
Date: Thu, 11 Dec 2014 10:41:54 +0000
From: Bjoern Rennhak <bjoern@clothesnetwork.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141211104154.GB20557@rennhak.de>
References: <20141210202525.GA20557@rennhak.de>
	<20141211001931.GA25476@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141211001931.GA25476@zion.uk.xensource.com>
X-URL: http://www.rennhak.com/
X-Operating-System: GNU/Linux Gentoo - Linux 3.13.0-rc3-linus-git-rennhak+ on
	a i686
X-Registered-Linux-User: 451519
X-Crypto: GnuPG/2.0.25 http://www.gnupg.org
X-GPG-Key-ID: 0x1122967D
X-GPG-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE9EE5EBA1122967D
X-GPG-Fingerprint: B2CC 3175 3A25 9616 F121 90FB E9EE 5EBA 1122 967D
X-Uptime: 11:30:15 up 18 days, 12:17, 13 users,  load average: 0.08, 0.05, 0.10
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Mailman-Approved-At: Thu, 11 Dec 2014 15:14:55 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Question reg. named vif interface support in guest
 cfg; 
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wei,

> > So instead of a bunch of vifx.y's I would see <descriptivename>x.y ?
> Check out
> http://xenbits.xen.org/docs/4.4-testing/misc/xl-network-configuration.html
> vifname

Sorry must have overlooked that, thank you!

-Bjoern

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 15:18:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 15:18:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz5VW-0005mh-K5; Thu, 11 Dec 2014 15:18: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 1Xz5VU-0005mc-UL
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 15:18:21 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	2F/71-01660-CB5B9845; Thu, 11 Dec 2014 15:18:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418311098!5263217!1
X-Originating-IP: [156.151.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 13149 invoked from network); 11 Dec 2014 15:18:19 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 15:18:19 -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 sBBFIDrJ026186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Dec 2014 15:18:13 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
	sBBFIBcf017749
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 11 Dec 2014 15:18:12 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
	sBBFIBfJ001571; Thu, 11 Dec 2014 15:18:11 GMT
Received: from [IPv6:2607:fb90:e16:86fe:18fb:52f1:3922:ccdf] (/172.56.23.227)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Dec 2014 07:18:10 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <5489906B020000780004EE34@mail.emea.novell.com>
References: <5489906B020000780004EE34@mail.emea.novell.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 11 Dec 2014 10:18:02 -0500
To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>
Message-ID: <69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On December 11, 2014 6:39:07 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>Co-REST-maintainers,
>
>there are a couple of patches I'd like to ask for feedback on, and I'm
>assuming (based on previous replies by him) Konrad is waiting for such
>too before considering giving release-acks:
>

I believe these two already have Acks - it is just that they did not say 'for-xen-4.5'  in the title.

>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00667.html

That
>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00692.html
>

Release-Acked-by: Konrad Rzeszutek Wilk (Konrad.wilk@oracle.com)

For both above. The second is an obvious fix for large scale machines.

>Either
>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00260.html
>or (my preference)
>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01054.html
>

Daniel's patch fixes the case for EFI map or large CPU count (to a certain extent). Jan's patch only fixes it for large CPU count. The memmap can be huge on small CPU count machines.

A proper fix would be to automatically adjust based on memmap and CPU but that could be too complex.

Perhaps putting both patches in is the right way?

>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 Dec 11 15:18:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 15:18:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz5VW-0005mh-K5; Thu, 11 Dec 2014 15:18: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 1Xz5VU-0005mc-UL
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 15:18:21 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	2F/71-01660-CB5B9845; Thu, 11 Dec 2014 15:18:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418311098!5263217!1
X-Originating-IP: [156.151.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 13149 invoked from network); 11 Dec 2014 15:18:19 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 15:18:19 -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 sBBFIDrJ026186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Dec 2014 15:18:13 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
	sBBFIBcf017749
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 11 Dec 2014 15:18:12 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
	sBBFIBfJ001571; Thu, 11 Dec 2014 15:18:11 GMT
Received: from [IPv6:2607:fb90:e16:86fe:18fb:52f1:3922:ccdf] (/172.56.23.227)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Dec 2014 07:18:10 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <5489906B020000780004EE34@mail.emea.novell.com>
References: <5489906B020000780004EE34@mail.emea.novell.com>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 11 Dec 2014 10:18:02 -0500
To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>
Message-ID: <69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On December 11, 2014 6:39:07 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>Co-REST-maintainers,
>
>there are a couple of patches I'd like to ask for feedback on, and I'm
>assuming (based on previous replies by him) Konrad is waiting for such
>too before considering giving release-acks:
>

I believe these two already have Acks - it is just that they did not say 'for-xen-4.5'  in the title.

>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00667.html

That
>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00692.html
>

Release-Acked-by: Konrad Rzeszutek Wilk (Konrad.wilk@oracle.com)

For both above. The second is an obvious fix for large scale machines.

>Either
>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00260.html
>or (my preference)
>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01054.html
>

Daniel's patch fixes the case for EFI map or large CPU count (to a certain extent). Jan's patch only fixes it for large CPU count. The memmap can be huge on small CPU count machines.

A proper fix would be to automatically adjust based on memmap and CPU but that could be too complex.

Perhaps putting both patches in is the right way?

>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 Dec 11 15:25:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 15:25:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz5br-0006Hb-G9; Thu, 11 Dec 2014 15:24:55 +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 1Xz5bp-0006HW-Ic
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 15:24:53 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	15/A7-02953-447B9845; Thu, 11 Dec 2014 15:24:52 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418311490!14458797!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28355 invoked from network); 11 Dec 2014 15:24:51 -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;
	11 Dec 2014 15:24:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="203402650"
Message-ID: <5489B721.6010504@citrix.com>
Date: Thu, 11 Dec 2014 15:24:17 +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: Olaf Hering <olaf@aepfle.de>, Vitaly Kuznetsov <vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<20141211142428.GA19820@aepfle.de>
In-Reply-To: <20141211142428.GA19820@aepfle.de>
X-DLP: MIA2
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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 11/12/14 14:24, Olaf Hering wrote:
> On Wed, Dec 03, Vitaly Kuznetsov wrote:
> 
>> 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.
> 
> How does this approach handle ballooned pages?
>>From the guests point of view they are always there, just claimed by the
> balloon driver. The new kernel does not have that driver nor does its
> driver have the knowledge which pages the old kernel gave back to Xen.
> 
> After a brief look none of the patches seem to deal with that.

Nothing special needs to be done with ballooned pages.  If frames are
not populated in the original domain, they will be unpopulated in the
new domain.

It's the responsibility of the guest to ensure it either doesn't kexec
when it is ballooned or that the kexec kernel can handle this (e.g., by
using a crash region that is never ballooned out).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 15:25:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 15:25:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz5br-0006Hb-G9; Thu, 11 Dec 2014 15:24:55 +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 1Xz5bp-0006HW-Ic
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 15:24:53 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	15/A7-02953-447B9845; Thu, 11 Dec 2014 15:24:52 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418311490!14458797!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28355 invoked from network); 11 Dec 2014 15:24:51 -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;
	11 Dec 2014 15:24:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="203402650"
Message-ID: <5489B721.6010504@citrix.com>
Date: Thu, 11 Dec 2014 15:24:17 +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: Olaf Hering <olaf@aepfle.de>, Vitaly Kuznetsov <vkuznets@redhat.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<20141211142428.GA19820@aepfle.de>
In-Reply-To: <20141211142428.GA19820@aepfle.de>
X-DLP: MIA2
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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 11/12/14 14:24, Olaf Hering wrote:
> On Wed, Dec 03, Vitaly Kuznetsov wrote:
> 
>> 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.
> 
> How does this approach handle ballooned pages?
>>From the guests point of view they are always there, just claimed by the
> balloon driver. The new kernel does not have that driver nor does its
> driver have the knowledge which pages the old kernel gave back to Xen.
> 
> After a brief look none of the patches seem to deal with that.

Nothing special needs to be done with ballooned pages.  If frames are
not populated in the original domain, they will be unpopulated in the
new domain.

It's the responsibility of the guest to ensure it either doesn't kexec
when it is ballooned or that the kexec kernel can handle this (e.g., by
using a crash region that is never ballooned out).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 15:30:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 15:30:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz5hW-0006QB-9n; Thu, 11 Dec 2014 15:30:46 +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 1Xz5hU-0006Q4-Kf
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 15:30:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	26/99-09842-3A8B9845; Thu, 11 Dec 2014 15:30:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418311843!14638436!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11281 invoked from network); 11 Dec 2014 15:30:43 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 15:30:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418311843; l=916;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=1Kzo5fjLXmorknjcXQ6L5KFW9qI=;
	b=AuFsUiVdmyycN0hA1qAu/a7QX8AgVkxe307ByynxOLDi8w3YUIC9HWMisGzE0YuJwhJ
	npZNqMYZXVkLyErjo+56GuuzVbvp5KUk6z+JvQYnlHL1QMMLpPhqVP/BQcD3S+yS55272
	ziEa7VLrSo/GBFfXAiK4F7gflEddQFtKjj8=
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.3 AUTH) with ESMTPSA id t04b03qBBFUT53h
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 11 Dec 2014 16:30:29 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 7DD1E5015F; Thu, 11 Dec 2014 16:30:29 +0100 (CET)
Date: Thu, 11 Dec 2014 16:30:29 +0100
From: Olaf Hering <olaf@aepfle.de>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141211153029.GA1772@aepfle.de>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<20141211142428.GA19820@aepfle.de> <5489B721.6010504@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5489B721.6010504@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Wei Liu <wei.liu2@citrix.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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 Thu, Dec 11, David Vrabel wrote:

> Nothing special needs to be done with ballooned pages.  If frames are
> not populated in the original domain, they will be unpopulated in the
> new domain.
> 
> It's the responsibility of the guest to ensure it either doesn't kexec
> when it is ballooned or that the kexec kernel can handle this (e.g., by
> using a crash region that is never ballooned out).

There is a difference between kexec and kdump. The kdump kernel does not
care because there is code in /proc/vmcore to handle ballooned pages in
the crashed kernel gracefully.
But a kexec boot will likely access pages which are not backed by RAM.
Unfortunately there is no flag left to mark a page as ballooned.

So what you are saying means that kexec-tools needs to continue to
balloon up before doing the actual kexec. I had hoped this suggested
approach would get rid of that limitation.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 15:30:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 15:30:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz5hW-0006QB-9n; Thu, 11 Dec 2014 15:30:46 +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 1Xz5hU-0006Q4-Kf
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 15:30:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	26/99-09842-3A8B9845; Thu, 11 Dec 2014 15:30:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418311843!14638436!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11281 invoked from network); 11 Dec 2014 15:30:43 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 15:30:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418311843; l=916;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=1Kzo5fjLXmorknjcXQ6L5KFW9qI=;
	b=AuFsUiVdmyycN0hA1qAu/a7QX8AgVkxe307ByynxOLDi8w3YUIC9HWMisGzE0YuJwhJ
	npZNqMYZXVkLyErjo+56GuuzVbvp5KUk6z+JvQYnlHL1QMMLpPhqVP/BQcD3S+yS55272
	ziEa7VLrSo/GBFfXAiK4F7gflEddQFtKjj8=
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.3 AUTH) with ESMTPSA id t04b03qBBFUT53h
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 11 Dec 2014 16:30:29 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 7DD1E5015F; Thu, 11 Dec 2014 16:30:29 +0100 (CET)
Date: Thu, 11 Dec 2014 16:30:29 +0100
From: Olaf Hering <olaf@aepfle.de>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141211153029.GA1772@aepfle.de>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<20141211142428.GA19820@aepfle.de> <5489B721.6010504@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5489B721.6010504@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>,
	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>,
	Tim Deegan <tim@xen.org>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org, Wei Liu <wei.liu2@citrix.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/9] 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 Thu, Dec 11, David Vrabel wrote:

> Nothing special needs to be done with ballooned pages.  If frames are
> not populated in the original domain, they will be unpopulated in the
> new domain.
> 
> It's the responsibility of the guest to ensure it either doesn't kexec
> when it is ballooned or that the kexec kernel can handle this (e.g., by
> using a crash region that is never ballooned out).

There is a difference between kexec and kdump. The kdump kernel does not
care because there is code in /proc/vmcore to handle ballooned pages in
the crashed kernel gracefully.
But a kexec boot will likely access pages which are not backed by RAM.
Unfortunately there is no flag left to mark a page as ballooned.

So what you are saying means that kexec-tools needs to continue to
balloon up before doing the actual kexec. I had hoped this suggested
approach would get rid of that limitation.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 15:39:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 15:39:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz5pD-0006vY-Fq; Thu, 11 Dec 2014 15:38: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 1Xz5pC-0006vT-1D
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 15:38:42 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	97/64-02696-18AB9845; Thu, 11 Dec 2014 15:38:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418312320!14493192!1
X-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 21285 invoked from network); 11 Dec 2014 15:38:40 -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; 11 Dec 2014 15:38:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 15:38:40 +0000
Message-Id: <5489C88F020000780004F0C2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 15:38:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5489906B020000780004EE34@mail.emea.novell.com>
	<69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.com>
In-Reply-To: <69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.14 at 16:18, <konrad.wilk@oracle.com> wrote:
> On December 11, 2014 6:39:07 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>>Either
>>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00260.html 
>>or (my preference)
>>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01054.html 
>>
> 
> Daniel's patch fixes the case for EFI map or large CPU count (to a certain 
> extent). Jan's patch only fixes it for large CPU count. The memmap can be 
> huge on small CPU count machines.

The EFI memory map gets printed much later than when the ring
buffer gets set up with "conring_size=" present.

> A proper fix would be to automatically adjust based on memmap and CPU but 
> that could be too complex.

The problem isn't the complexity, but the chicken-and-egg problem
as far as CPU count is concerned. The memory map size would be
known early enough.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 15:39:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 15:39:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz5pD-0006vY-Fq; Thu, 11 Dec 2014 15:38: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 1Xz5pC-0006vT-1D
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 15:38:42 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	97/64-02696-18AB9845; Thu, 11 Dec 2014 15:38:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418312320!14493192!1
X-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 21285 invoked from network); 11 Dec 2014 15:38:40 -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; 11 Dec 2014 15:38:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 11 Dec 2014 15:38:40 +0000
Message-Id: <5489C88F020000780004F0C2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 11 Dec 2014 15:38:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5489906B020000780004EE34@mail.emea.novell.com>
	<69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.com>
In-Reply-To: <69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.14 at 16:18, <konrad.wilk@oracle.com> wrote:
> On December 11, 2014 6:39:07 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>>Either
>>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00260.html 
>>or (my preference)
>>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01054.html 
>>
> 
> Daniel's patch fixes the case for EFI map or large CPU count (to a certain 
> extent). Jan's patch only fixes it for large CPU count. The memmap can be 
> huge on small CPU count machines.

The EFI memory map gets printed much later than when the ring
buffer gets set up with "conring_size=" present.

> A proper fix would be to automatically adjust based on memmap and CPU but 
> that could be too complex.

The problem isn't the complexity, but the chicken-and-egg problem
as far as CPU count is concerned. The memory map size would be
known early enough.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 16:20:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 16: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 1Xz6Se-0000QV-S0; Thu, 11 Dec 2014 16:19:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Xz6Sd-0000QQ-NT
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 16:19:27 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	14/B0-02576-E04C9845; Thu, 11 Dec 2014 16:19:26 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418314764!14520040!1
X-Originating-IP: [66.165.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 20835 invoked from network); 11 Dec 2014 16:19:26 -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;
	11 Dec 2014 16:19:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="203023976"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 11:16:37 -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 1Xz6Ps-0006ls-ES;
	Thu, 11 Dec 2014 16:16:36 +0000
Date: Thu, 11 Dec 2014 16:16:36 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141211161636.GE1900@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418140562.19809.14.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Jim
	Fehlig <jfehlig@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 03:56:02PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-09 at 15:39 +0000, Anthony PERARD wrote:
> > The path to the pty of a Xen PV console is set only in
> > virDomainOpenConsole. But this is done too late. A call to
> > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > the pty, but a call after OpenConsole will.
> > 
> > e.g. of the current issue.
> > Starting a domain with '<console type="pty"/>'
> > Then:
> > virDomainGetXMLDesc():
> >   <devices>
> >     <console type='pty'>
> >       <target type='xen' port='0'/>
> >     </console>
> >   </devices>
> > virDomainOpenConsole()
> > virDomainGetXMLDesc():
> >   <devices>
> >     <console type='pty' tty='/dev/pts/30'>
> >       <source path='/dev/pts/30'/>
> >       <target type='xen' port='0'/>
> >     </console>
> >   </devices>
> > 
> > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > This is done by setting up the path at domain start up instead of in
> > OpenConsole.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > 
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > 
> > ---
> > Change in V2:
> >   Adding bug report link.
> >   Reword the last part of the patch description.
> >   Cleanup the code.
> >   Use VIR_FREE before VIR_STRDUP.
> >   Remove the code from OpenConsole as it is now a duplicate.
> > ---
> >  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
> >  src/libxl/libxl_driver.c | 15 ---------------
> >  2 files changed, 20 insertions(+), 15 deletions(-)
> > 
> > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > index 9c62291..325de79 100644
> > --- a/src/libxl/libxl_domain.c
> > +++ b/src/libxl/libxl_domain.c
> > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> >          goto cleanup_dom;
> >  
> > +    if (vm->def->nconsoles) {
> > +        virDomainChrDefPtr chr = vm->def->consoles[0];
> 
> Given vm->def->nconsoles should we loop and do them all?

Maybe. libvirt it self will not be able to access any console that is
not the first one (virDomainOpenConsole only provide access to console
0), but a consumer of libvirt could.

> Also, and I really should know the answer to this (and sorry for not
> thinking of it earlier), but:
> 
> > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > +                                        chr->target.port, console_type,
> > +                                        &console);
> 
> Might this race against xenconsoled writing the node to xenstore and
> therefore be prone to failing when starting multiple guests all at once?

I've look through out libxl, xenconsoled and libvirt, and I could not
find any synchronisation point. So I guest it's possible.

> Is there a hook which is called on virsh dumpxml which could update
> things on the fly (i.e. lookup the console iff it isn't already set)?

I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
to do the check, or having a xenstore watch on the path (if that is
possible).

-- 
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 Dec 11 16:20:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 16: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 1Xz6Se-0000QV-S0; Thu, 11 Dec 2014 16:19:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Xz6Sd-0000QQ-NT
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 16:19:27 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	14/B0-02576-E04C9845; Thu, 11 Dec 2014 16:19:26 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418314764!14520040!1
X-Originating-IP: [66.165.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 20835 invoked from network); 11 Dec 2014 16:19:26 -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;
	11 Dec 2014 16:19:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="203023976"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 11:16:37 -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 1Xz6Ps-0006ls-ES;
	Thu, 11 Dec 2014 16:16:36 +0000
Date: Thu, 11 Dec 2014 16:16:36 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141211161636.GE1900@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418140562.19809.14.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Jim
	Fehlig <jfehlig@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 03:56:02PM +0000, Ian Campbell wrote:
> On Tue, 2014-12-09 at 15:39 +0000, Anthony PERARD wrote:
> > The path to the pty of a Xen PV console is set only in
> > virDomainOpenConsole. But this is done too late. A call to
> > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > the pty, but a call after OpenConsole will.
> > 
> > e.g. of the current issue.
> > Starting a domain with '<console type="pty"/>'
> > Then:
> > virDomainGetXMLDesc():
> >   <devices>
> >     <console type='pty'>
> >       <target type='xen' port='0'/>
> >     </console>
> >   </devices>
> > virDomainOpenConsole()
> > virDomainGetXMLDesc():
> >   <devices>
> >     <console type='pty' tty='/dev/pts/30'>
> >       <source path='/dev/pts/30'/>
> >       <target type='xen' port='0'/>
> >     </console>
> >   </devices>
> > 
> > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > This is done by setting up the path at domain start up instead of in
> > OpenConsole.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > 
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > 
> > ---
> > Change in V2:
> >   Adding bug report link.
> >   Reword the last part of the patch description.
> >   Cleanup the code.
> >   Use VIR_FREE before VIR_STRDUP.
> >   Remove the code from OpenConsole as it is now a duplicate.
> > ---
> >  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
> >  src/libxl/libxl_driver.c | 15 ---------------
> >  2 files changed, 20 insertions(+), 15 deletions(-)
> > 
> > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > index 9c62291..325de79 100644
> > --- a/src/libxl/libxl_domain.c
> > +++ b/src/libxl/libxl_domain.c
> > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> >          goto cleanup_dom;
> >  
> > +    if (vm->def->nconsoles) {
> > +        virDomainChrDefPtr chr = vm->def->consoles[0];
> 
> Given vm->def->nconsoles should we loop and do them all?

Maybe. libvirt it self will not be able to access any console that is
not the first one (virDomainOpenConsole only provide access to console
0), but a consumer of libvirt could.

> Also, and I really should know the answer to this (and sorry for not
> thinking of it earlier), but:
> 
> > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > +                                        chr->target.port, console_type,
> > +                                        &console);
> 
> Might this race against xenconsoled writing the node to xenstore and
> therefore be prone to failing when starting multiple guests all at once?

I've look through out libxl, xenconsoled and libvirt, and I could not
find any synchronisation point. So I guest it's possible.

> Is there a hook which is called on virsh dumpxml which could update
> things on the fly (i.e. lookup the console iff it isn't already set)?

I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
to do the check, or having a xenstore watch on the path (if that is
possible).

-- 
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 Dec 11 16:26:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 16:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz6ZH-0000uG-PS; Thu, 11 Dec 2014 16:26: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 1Xz6ZH-0000uB-0y
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 16:26:19 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	D4/57-03145-AA5C9845; Thu, 11 Dec 2014 16:26:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418315176!14505011!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 12285 invoked from network); 11 Dec 2014 16:26:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 16:26:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="203027970"
Message-ID: <1418314995.23309.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 11 Dec 2014 16:23:15 +0000
In-Reply-To: <20141211161636.GE1900@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: libvir-list@redhat.com, Jim
	Fehlig <jfehlig@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-11 at 16:16 +0000, Anthony PERARD wrote:
> On Tue, Dec 09, 2014 at 03:56:02PM +0000, Ian Campbell wrote:
> > On Tue, 2014-12-09 at 15:39 +0000, Anthony PERARD wrote:
> > > The path to the pty of a Xen PV console is set only in
> > > virDomainOpenConsole. But this is done too late. A call to
> > > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > > the pty, but a call after OpenConsole will.
> > > 
> > > e.g. of the current issue.
> > > Starting a domain with '<console type="pty"/>'
> > > Then:
> > > virDomainGetXMLDesc():
> > >   <devices>
> > >     <console type='pty'>
> > >       <target type='xen' port='0'/>
> > >     </console>
> > >   </devices>
> > > virDomainOpenConsole()
> > > virDomainGetXMLDesc():
> > >   <devices>
> > >     <console type='pty' tty='/dev/pts/30'>
> > >       <source path='/dev/pts/30'/>
> > >       <target type='xen' port='0'/>
> > >     </console>
> > >   </devices>
> > > 
> > > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > > This is done by setting up the path at domain start up instead of in
> > > OpenConsole.
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > > 
> > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > > 
> > > ---
> > > Change in V2:
> > >   Adding bug report link.
> > >   Reword the last part of the patch description.
> > >   Cleanup the code.
> > >   Use VIR_FREE before VIR_STRDUP.
> > >   Remove the code from OpenConsole as it is now a duplicate.
> > > ---
> > >  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
> > >  src/libxl/libxl_driver.c | 15 ---------------
> > >  2 files changed, 20 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > index 9c62291..325de79 100644
> > > --- a/src/libxl/libxl_domain.c
> > > +++ b/src/libxl/libxl_domain.c
> > > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> > >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > >          goto cleanup_dom;
> > >  
> > > +    if (vm->def->nconsoles) {
> > > +        virDomainChrDefPtr chr = vm->def->consoles[0];
> > 
> > Given vm->def->nconsoles should we loop and do them all?
> 
> Maybe. libvirt it self will not be able to access any console that is
> not the first one (virDomainOpenConsole only provide access to console
> 0), but a consumer of libvirt could.
> 
> > Also, and I really should know the answer to this (and sorry for not
> > thinking of it earlier), but:
> > 
> > > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > > +                                        chr->target.port, console_type,
> > > +                                        &console);
> > 
> > Might this race against xenconsoled writing the node to xenstore and
> > therefore be prone to failing when starting multiple guests all at once?
> 
> I've look through out libxl, xenconsoled and libvirt, and I could not
> find any synchronisation point. So I guest it's possible.
> 
> > Is there a hook which is called on virsh dumpxml which could update
> > things on the fly (i.e. lookup the console iff it isn't already set)?
> 
> I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
> to do the check, or having a xenstore watch on the path (if that is
> possible).

The aop_console_how option to libxl_domain_create_new and
libxl_domain_create_restore is documented as:

  /* A progress report will be made via ao_console_how, of type
   * domain_create_console_available, when the domain's primary
   * console is available and can be connected to.
   */

Which sounds like exactly what is needed?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 16:26:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 16:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz6ZH-0000uG-PS; Thu, 11 Dec 2014 16:26: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 1Xz6ZH-0000uB-0y
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 16:26:19 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	D4/57-03145-AA5C9845; Thu, 11 Dec 2014 16:26:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418315176!14505011!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 12285 invoked from network); 11 Dec 2014 16:26:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 16:26:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="203027970"
Message-ID: <1418314995.23309.7.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 11 Dec 2014 16:23:15 +0000
In-Reply-To: <20141211161636.GE1900@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: libvir-list@redhat.com, Jim
	Fehlig <jfehlig@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-11 at 16:16 +0000, Anthony PERARD wrote:
> On Tue, Dec 09, 2014 at 03:56:02PM +0000, Ian Campbell wrote:
> > On Tue, 2014-12-09 at 15:39 +0000, Anthony PERARD wrote:
> > > The path to the pty of a Xen PV console is set only in
> > > virDomainOpenConsole. But this is done too late. A call to
> > > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > > the pty, but a call after OpenConsole will.
> > > 
> > > e.g. of the current issue.
> > > Starting a domain with '<console type="pty"/>'
> > > Then:
> > > virDomainGetXMLDesc():
> > >   <devices>
> > >     <console type='pty'>
> > >       <target type='xen' port='0'/>
> > >     </console>
> > >   </devices>
> > > virDomainOpenConsole()
> > > virDomainGetXMLDesc():
> > >   <devices>
> > >     <console type='pty' tty='/dev/pts/30'>
> > >       <source path='/dev/pts/30'/>
> > >       <target type='xen' port='0'/>
> > >     </console>
> > >   </devices>
> > > 
> > > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > > This is done by setting up the path at domain start up instead of in
> > > OpenConsole.
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > > 
> > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > > 
> > > ---
> > > Change in V2:
> > >   Adding bug report link.
> > >   Reword the last part of the patch description.
> > >   Cleanup the code.
> > >   Use VIR_FREE before VIR_STRDUP.
> > >   Remove the code from OpenConsole as it is now a duplicate.
> > > ---
> > >  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
> > >  src/libxl/libxl_driver.c | 15 ---------------
> > >  2 files changed, 20 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > index 9c62291..325de79 100644
> > > --- a/src/libxl/libxl_domain.c
> > > +++ b/src/libxl/libxl_domain.c
> > > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> > >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > >          goto cleanup_dom;
> > >  
> > > +    if (vm->def->nconsoles) {
> > > +        virDomainChrDefPtr chr = vm->def->consoles[0];
> > 
> > Given vm->def->nconsoles should we loop and do them all?
> 
> Maybe. libvirt it self will not be able to access any console that is
> not the first one (virDomainOpenConsole only provide access to console
> 0), but a consumer of libvirt could.
> 
> > Also, and I really should know the answer to this (and sorry for not
> > thinking of it earlier), but:
> > 
> > > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > > +                                        chr->target.port, console_type,
> > > +                                        &console);
> > 
> > Might this race against xenconsoled writing the node to xenstore and
> > therefore be prone to failing when starting multiple guests all at once?
> 
> I've look through out libxl, xenconsoled and libvirt, and I could not
> find any synchronisation point. So I guest it's possible.
> 
> > Is there a hook which is called on virsh dumpxml which could update
> > things on the fly (i.e. lookup the console iff it isn't already set)?
> 
> I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
> to do the check, or having a xenstore watch on the path (if that is
> possible).

The aop_console_how option to libxl_domain_create_new and
libxl_domain_create_restore is documented as:

  /* A progress report will be made via ao_console_how, of type
   * domain_create_console_available, when the domain's primary
   * console is available and can be connected to.
   */

Which sounds like exactly what is needed?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 16:45:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 16: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 1Xz6rZ-0001ji-Ih; Thu, 11 Dec 2014 16:45:13 +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 1Xz6rY-0001jd-8V
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 16:45:12 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	F3/13-27785-71AC9845; Thu, 11 Dec 2014 16:45:11 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418316309!9859624!1
X-Originating-IP: [74.125.82.50]
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 2493 invoked from network); 11 Dec 2014 16:45:10 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 16:45:10 -0000
Received: by mail-wg0-f50.google.com with SMTP id a1so6995161wgh.9
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 08:45:09 -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=O7XcSHBZ/NaSXW95NhVDsY9FQJ+NOWWRAnnq0X2IIXA=;
	b=Owx5okAmc0Ckb4UI2gPUcW1PfP2eoHePNXGrPx03waE2e8XT6avAwI9rLcV7+b0jSq
	m1kltodKLizIRaeYFj4hb6GzFVMms+n4BXMnVYcILqJWz4WMETBMqrHlb577yOtqjmE7
	0cun1XgBPPF+yUn70hoGlcICBlQ1qrwq/3wTCvZ99aa0DOqqljRWuhEchdx5jyYMCIdl
	vNLpHDsUTN3yQ34Xz9f3ypQ+KBYZJphQDUswnVNuAGOcSbMyoSUG/CN7pLuJ9ar6trdK
	5ZohuVO2/6s9hU9R2XBzcQW2Gr2BltyK9VogCj2Hud7qz8Rm4cV1j+3Dzmpr3xDHOgR7
	ZU2w==
MIME-Version: 1.0
X-Received: by 10.180.8.7 with SMTP id n7mr23982187wia.11.1418316309783; Thu,
	11 Dec 2014 08:45:09 -0800 (PST)
Received: by 10.194.163.70 with HTTP; Thu, 11 Dec 2014 08:45:09 -0800 (PST)
In-Reply-To: <1411365561-29242-4-git-send-email-wency@cn.fujitsu.com>
References: <1411365561-29242-1-git-send-email-wency@cn.fujitsu.com>
	<1411365561-29242-4-git-send-email-wency@cn.fujitsu.com>
Date: Thu, 11 Dec 2014 16:45:09 +0000
X-Google-Sender-Auth: Qivh8WVX-KOs91KGO7eZDYt_d2M
Message-ID: <CAFLBxZbzSAFSZZrW9p+Gz-VTbts+q4Z1xT_+d9jrYJ8jjXVy8g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC Patch v4 3/9] pass correct file to qemu if we
 use blktap2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 22, 2014 at 6:59 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
> If we use blktap2, the correct file should be blktap device
> not the pdev_path.
>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

If I'm reading this correctly, this is actually a fairly serious bug
in libxl -- it means that when using backend=tap with HVM domains,
qemu will actually *bypass entirely* the tapdisk process and access
the underlying file directly.

This should probably be backported, potentially as far back as 4.2.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 16:45:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 16: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 1Xz6rZ-0001ji-Ih; Thu, 11 Dec 2014 16:45:13 +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 1Xz6rY-0001jd-8V
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 16:45:12 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	F3/13-27785-71AC9845; Thu, 11 Dec 2014 16:45:11 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418316309!9859624!1
X-Originating-IP: [74.125.82.50]
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 2493 invoked from network); 11 Dec 2014 16:45:10 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 16:45:10 -0000
Received: by mail-wg0-f50.google.com with SMTP id a1so6995161wgh.9
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 08:45:09 -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=O7XcSHBZ/NaSXW95NhVDsY9FQJ+NOWWRAnnq0X2IIXA=;
	b=Owx5okAmc0Ckb4UI2gPUcW1PfP2eoHePNXGrPx03waE2e8XT6avAwI9rLcV7+b0jSq
	m1kltodKLizIRaeYFj4hb6GzFVMms+n4BXMnVYcILqJWz4WMETBMqrHlb577yOtqjmE7
	0cun1XgBPPF+yUn70hoGlcICBlQ1qrwq/3wTCvZ99aa0DOqqljRWuhEchdx5jyYMCIdl
	vNLpHDsUTN3yQ34Xz9f3ypQ+KBYZJphQDUswnVNuAGOcSbMyoSUG/CN7pLuJ9ar6trdK
	5ZohuVO2/6s9hU9R2XBzcQW2Gr2BltyK9VogCj2Hud7qz8Rm4cV1j+3Dzmpr3xDHOgR7
	ZU2w==
MIME-Version: 1.0
X-Received: by 10.180.8.7 with SMTP id n7mr23982187wia.11.1418316309783; Thu,
	11 Dec 2014 08:45:09 -0800 (PST)
Received: by 10.194.163.70 with HTTP; Thu, 11 Dec 2014 08:45:09 -0800 (PST)
In-Reply-To: <1411365561-29242-4-git-send-email-wency@cn.fujitsu.com>
References: <1411365561-29242-1-git-send-email-wency@cn.fujitsu.com>
	<1411365561-29242-4-git-send-email-wency@cn.fujitsu.com>
Date: Thu, 11 Dec 2014 16:45:09 +0000
X-Google-Sender-Auth: Qivh8WVX-KOs91KGO7eZDYt_d2M
Message-ID: <CAFLBxZbzSAFSZZrW9p+Gz-VTbts+q4Z1xT_+d9jrYJ8jjXVy8g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC Patch v4 3/9] pass correct file to qemu if we
 use blktap2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 22, 2014 at 6:59 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
> If we use blktap2, the correct file should be blktap device
> not the pdev_path.
>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

If I'm reading this correctly, this is actually a fairly serious bug
in libxl -- it means that when using backend=tap with HVM domains,
qemu will actually *bypass entirely* the tapdisk process and access
the underlying file directly.

This should probably be backported, potentially as far back as 4.2.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 16:46:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 16:46:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz6tD-0001oi-21; Thu, 11 Dec 2014 16:46:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xz6tB-0001oc-FV
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 16:46:53 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	56/D1-15461-C7AC9845; Thu, 11 Dec 2014 16:46:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418316411!14987791!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 12926 invoked from network); 11 Dec 2014 16:46:52 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 16:46:52 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz6sq-000L2I-E3; Thu, 11 Dec 2014 16:46:32 +0000
Date: Thu, 11 Dec 2014 17:46:32 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141211164632.GF53811@deinos.phlegethon.org>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 01:41 +0000 on 11 Dec (1418258504), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:tim@xen.org]
> > It is Xen's job to isolate VMs from each other.  As part of that, Xen
> > uses the MMU, nested paging, and IOMMUs to control access to RAM.  Any
> > software component that can pass a raw MFN to hardware breaks that
> > isolation, because Xen has no way of controlling what that component
> > can do (including taking over the hypervisor).  This is why I am
> > afraid when developers ask for GFN->MFN translation functions.
> 
> When I agree Xen's job absolutely, the isolation is also required in different
> layers, regarding to who controls the resource and where the virtualization 
> happens. For example talking about I/O virtualization, Dom0 or driver domain 
> needs to isolate among backend drivers to avoid one backend interfering 
> with another. Xen doesn't know such violation, since it only knows it's Dom0
> wants to access a VM's page.

I'm going to write second reply to this mail in a bit, to talk about
this kind of system-level design.  In this email I'll just talk about
the practical aspects of interfaces and address spaces and IOMMUs.

> btw curious of how worse exposing GFN->MFN translation compared to
> allowing mapping other VM's GFN? If exposing GFN->MFN is under the
> same permission control as mapping, would it avoid your worry here?

I'm afraid not.  There's nothing worrying per se in a backend knowing
the MFNs of the pages -- the worry is that the backend can pass the
MFNs to hardware.  If the check happens only at lookup time, then XenGT
can (either through a bug or a security breach) just pass _any_ MFN to
the GPU for DMA.

But even without considering the security aspects, this model has bugs
that may be impossible for XenGT itself to even detect.  E.g.:
 1. Guest asks its virtual GPU to DMA to a frame of memory;
 2. XenGT looks up the GFN->MFN mapping;
 3. Guest balloons out the page;
 4. Xen allocates the page to a different guest;
 5. XenGT passes the MFN to the GPU, which DMAs to it.

Whereas if stage 2 is a _mapping_ operation, Xen can refcount the
underlying memory and make sure it doesn't get reallocated until XenGT
is finished with it.

> > When the backend component gets a GFN from the guest, it wants an
> > address that it can give to the GPU for DMA that will map the right
> > memory.  That address must be mapped in the IOMMU tables that the GPU
> > will be using, which means the IOMMU tables of the backend domain,
> > IIUC[1].  So the hypercall it needs is not "give me the MFN that matches
> > this GFN" but "please map this GFN into my IOMMU tables".
> 
> Here "please map this GFN into my IOMMU tables" actually breaks the
> IOMMU isolation. IOMMU is designed for serving DMA requests issued
> by an exclusive VM, so IOMMU page table can restrict that VM's attempts
> strictly.
> 
> To map multiple VM's GFNs into one IOMMU table, the 1st thing is to
> avoid GFN conflictions to make it functional. We thought about this approach
> previously, e.g. by reserving highest 3 bits of GFN as VMID, so one IOMMU
> page table can be used to combine multi-VM's page table together. However
> doing so have two limitations:
> 
> a) it still requires write-protect guest GPU page table, and maintain a shadow
> GPU page table by translate from real GFN to pseudo GFN (plus VMID), which
> doesn't save any engineering effort in the device model part

Yes -- since there's only one IOMMU context for the whole GPU, the
XenGT backend still has to audit all GPU commands to maintain
isolation between clients.

> b) it breaks the designed isolation intrinsic of IOMMU. In such case, IOMMU
> can't isolate multiple VMs by itself, since a DMA request can target any 
> pseudo GFN if valid in the page table. We have to rely on the audit in the 
> backend component in Dom0 to ensure the isolation.

Yep.

> c) this introduces tricky logic in IOMMU driver to handle such non-standard
> multiplexed page table style. 
> 
> w/o a SR-IOV implementation (so each VF has its own IOMMU page table),
> I don't see using IOMMU can help isolation here.

If I've understood your argument correctly, it basically comes down
to "It would be extra work for no benefit, because XenGT still has to
do all the work of isolating GPU clients from each other".  It's true
that XenGT still has to isolate its clients, but there are other
benefits.

The main one, from my point of view as a Xen maintainer, is that it
allows Xen to constrain XenGT itself, in the case where bugs or
security breaches mean that XenGT tries to access memory it shouldn't.
More about that in my other reply.  I'll talk about the rest below.

> yes, this is a good feedback we didn't think about before. So far the reason
> why XenGT can work is because we use default IOMMU setting which set
> up a 1:1 r/w mapping for all possible RAM, so when GPU hits a MFN thru
> shadow GPU page table, IOMMU is essentially bypassed. However like
> you said, if IOMMU page table is restricted to dom0's memory, or is not
> 1:1 identity mapping, XenGT will be broken.
> 
> However I don't see a good solution for this, except using multiplexed
> IOMMU page table aforementioned, which however doesn't look like
> a sane design to me.

Right.  AIUI you're talking about having a component, maybe in Xen,
that automatically makes a merged IOMMU table that contains multiple
VMs' p2m tables all at once.  I think that we can do something simpler
than that which will have the same effect and also avoid race
conditions like the one I mentioned at the top of the email.

[First some hopefully-helpful diagrams to explain my thinking.  I'll
 borrow 'BFN' from Malcolm's discussion of IOMMUs to describe the
 addresses that devices issue their DMAs in:

 Here's how the translations work for a HVM guest using HAP:

   CPU    <- Code supplied by the guest
    |
  (VA)
    | 
   MMU    <- Pagetables supplied by the guest
    | 
  (GFN)
    | 
   HAP    <- Guest's P2M, supplied by Xen
    |
  (MFN)
    | 
   RAM

 Here's how it looks for a GPU operation using XenGT:

   GPU       <- Code supplied by Guest, audited by XenGT
    | 
  (GPU VA)
    | 
  GPU-MMU    <- GTTs supplied by XenGT (by shadowing guest ones)
    | 
  (GPU BFN)
    | 
  IOMMU      <- XenGT backend dom's P2M (for PVH/HVM) or IOMMU tables (for PV)
    |
  (MFN)
    | 
   RAM

 OK, on we go...]

Somewhere in the existing XenGT code, XenGT has a guest GFN in its
hand and makes a lookup hypercall to find the MFN.  It puts that MFN
into the GTTs that it passes to the GPU.  But an MFN is not actually
what it needs here -- it needs a GPU BFN, which the IOMMU will then
turn into an MFN for it.

If we replace that lookup with a _map_ hypercall, either with Xen
choosing the BFN (as happens in the PV grant map operation) or with
the guest choosing an unused address (as happens in the HVM/PVH
grant map operation), then:
 - the only extra code in XenGT itself is that you need to unmap
   when you change the GTT;
 - Xen can track and control exactly which MFNs XenGT/the GPU can access;
 - running XenGT in a driver domain or PVH dom0 ought to work; and
 - we fix the race condition I described above.

The default policy I'm suggesting is that the XenGT backend domain
should be marked IS_PRIV_FOR (or similar) over the XenGT client VMs,
which will need a small extension in Xen since at the moment struct
domain has only one "target" field.

BTW, this is the exact analogue of how all other backend and toolstack
operations work -- they request access from Xen to specific pages and
they relinquish it when they are done.  In particular:

> for mapping and accessing other guest's memory, I don't think we 
> need any new interface atop existing ones. Just similar to other backend
> drivers, we can leverage the same permission control.

I don't think that's right -- other backend drivers use the grant
table mechanism, wher the guest explicitly grants access to only the
memory it needs.  AIUI you're not suggesting that you'll use that for
XenGT! :)

Right - I hope that made some sense.  I'll go get another cup of
coffee and start on that other reply...

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 Dec 11 16:46:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 16:46:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz6tD-0001oi-21; Thu, 11 Dec 2014 16:46:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Xz6tB-0001oc-FV
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 16:46:53 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	56/D1-15461-C7AC9845; Thu, 11 Dec 2014 16:46:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418316411!14987791!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 12926 invoked from network); 11 Dec 2014 16:46:52 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 16:46:52 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Xz6sq-000L2I-E3; Thu, 11 Dec 2014 16:46:32 +0000
Date: Thu, 11 Dec 2014 17:46:32 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141211164632.GF53811@deinos.phlegethon.org>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 01:41 +0000 on 11 Dec (1418258504), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:tim@xen.org]
> > It is Xen's job to isolate VMs from each other.  As part of that, Xen
> > uses the MMU, nested paging, and IOMMUs to control access to RAM.  Any
> > software component that can pass a raw MFN to hardware breaks that
> > isolation, because Xen has no way of controlling what that component
> > can do (including taking over the hypervisor).  This is why I am
> > afraid when developers ask for GFN->MFN translation functions.
> 
> When I agree Xen's job absolutely, the isolation is also required in different
> layers, regarding to who controls the resource and where the virtualization 
> happens. For example talking about I/O virtualization, Dom0 or driver domain 
> needs to isolate among backend drivers to avoid one backend interfering 
> with another. Xen doesn't know such violation, since it only knows it's Dom0
> wants to access a VM's page.

I'm going to write second reply to this mail in a bit, to talk about
this kind of system-level design.  In this email I'll just talk about
the practical aspects of interfaces and address spaces and IOMMUs.

> btw curious of how worse exposing GFN->MFN translation compared to
> allowing mapping other VM's GFN? If exposing GFN->MFN is under the
> same permission control as mapping, would it avoid your worry here?

I'm afraid not.  There's nothing worrying per se in a backend knowing
the MFNs of the pages -- the worry is that the backend can pass the
MFNs to hardware.  If the check happens only at lookup time, then XenGT
can (either through a bug or a security breach) just pass _any_ MFN to
the GPU for DMA.

But even without considering the security aspects, this model has bugs
that may be impossible for XenGT itself to even detect.  E.g.:
 1. Guest asks its virtual GPU to DMA to a frame of memory;
 2. XenGT looks up the GFN->MFN mapping;
 3. Guest balloons out the page;
 4. Xen allocates the page to a different guest;
 5. XenGT passes the MFN to the GPU, which DMAs to it.

Whereas if stage 2 is a _mapping_ operation, Xen can refcount the
underlying memory and make sure it doesn't get reallocated until XenGT
is finished with it.

> > When the backend component gets a GFN from the guest, it wants an
> > address that it can give to the GPU for DMA that will map the right
> > memory.  That address must be mapped in the IOMMU tables that the GPU
> > will be using, which means the IOMMU tables of the backend domain,
> > IIUC[1].  So the hypercall it needs is not "give me the MFN that matches
> > this GFN" but "please map this GFN into my IOMMU tables".
> 
> Here "please map this GFN into my IOMMU tables" actually breaks the
> IOMMU isolation. IOMMU is designed for serving DMA requests issued
> by an exclusive VM, so IOMMU page table can restrict that VM's attempts
> strictly.
> 
> To map multiple VM's GFNs into one IOMMU table, the 1st thing is to
> avoid GFN conflictions to make it functional. We thought about this approach
> previously, e.g. by reserving highest 3 bits of GFN as VMID, so one IOMMU
> page table can be used to combine multi-VM's page table together. However
> doing so have two limitations:
> 
> a) it still requires write-protect guest GPU page table, and maintain a shadow
> GPU page table by translate from real GFN to pseudo GFN (plus VMID), which
> doesn't save any engineering effort in the device model part

Yes -- since there's only one IOMMU context for the whole GPU, the
XenGT backend still has to audit all GPU commands to maintain
isolation between clients.

> b) it breaks the designed isolation intrinsic of IOMMU. In such case, IOMMU
> can't isolate multiple VMs by itself, since a DMA request can target any 
> pseudo GFN if valid in the page table. We have to rely on the audit in the 
> backend component in Dom0 to ensure the isolation.

Yep.

> c) this introduces tricky logic in IOMMU driver to handle such non-standard
> multiplexed page table style. 
> 
> w/o a SR-IOV implementation (so each VF has its own IOMMU page table),
> I don't see using IOMMU can help isolation here.

If I've understood your argument correctly, it basically comes down
to "It would be extra work for no benefit, because XenGT still has to
do all the work of isolating GPU clients from each other".  It's true
that XenGT still has to isolate its clients, but there are other
benefits.

The main one, from my point of view as a Xen maintainer, is that it
allows Xen to constrain XenGT itself, in the case where bugs or
security breaches mean that XenGT tries to access memory it shouldn't.
More about that in my other reply.  I'll talk about the rest below.

> yes, this is a good feedback we didn't think about before. So far the reason
> why XenGT can work is because we use default IOMMU setting which set
> up a 1:1 r/w mapping for all possible RAM, so when GPU hits a MFN thru
> shadow GPU page table, IOMMU is essentially bypassed. However like
> you said, if IOMMU page table is restricted to dom0's memory, or is not
> 1:1 identity mapping, XenGT will be broken.
> 
> However I don't see a good solution for this, except using multiplexed
> IOMMU page table aforementioned, which however doesn't look like
> a sane design to me.

Right.  AIUI you're talking about having a component, maybe in Xen,
that automatically makes a merged IOMMU table that contains multiple
VMs' p2m tables all at once.  I think that we can do something simpler
than that which will have the same effect and also avoid race
conditions like the one I mentioned at the top of the email.

[First some hopefully-helpful diagrams to explain my thinking.  I'll
 borrow 'BFN' from Malcolm's discussion of IOMMUs to describe the
 addresses that devices issue their DMAs in:

 Here's how the translations work for a HVM guest using HAP:

   CPU    <- Code supplied by the guest
    |
  (VA)
    | 
   MMU    <- Pagetables supplied by the guest
    | 
  (GFN)
    | 
   HAP    <- Guest's P2M, supplied by Xen
    |
  (MFN)
    | 
   RAM

 Here's how it looks for a GPU operation using XenGT:

   GPU       <- Code supplied by Guest, audited by XenGT
    | 
  (GPU VA)
    | 
  GPU-MMU    <- GTTs supplied by XenGT (by shadowing guest ones)
    | 
  (GPU BFN)
    | 
  IOMMU      <- XenGT backend dom's P2M (for PVH/HVM) or IOMMU tables (for PV)
    |
  (MFN)
    | 
   RAM

 OK, on we go...]

Somewhere in the existing XenGT code, XenGT has a guest GFN in its
hand and makes a lookup hypercall to find the MFN.  It puts that MFN
into the GTTs that it passes to the GPU.  But an MFN is not actually
what it needs here -- it needs a GPU BFN, which the IOMMU will then
turn into an MFN for it.

If we replace that lookup with a _map_ hypercall, either with Xen
choosing the BFN (as happens in the PV grant map operation) or with
the guest choosing an unused address (as happens in the HVM/PVH
grant map operation), then:
 - the only extra code in XenGT itself is that you need to unmap
   when you change the GTT;
 - Xen can track and control exactly which MFNs XenGT/the GPU can access;
 - running XenGT in a driver domain or PVH dom0 ought to work; and
 - we fix the race condition I described above.

The default policy I'm suggesting is that the XenGT backend domain
should be marked IS_PRIV_FOR (or similar) over the XenGT client VMs,
which will need a small extension in Xen since at the moment struct
domain has only one "target" field.

BTW, this is the exact analogue of how all other backend and toolstack
operations work -- they request access from Xen to specific pages and
they relinquish it when they are done.  In particular:

> for mapping and accessing other guest's memory, I don't think we 
> need any new interface atop existing ones. Just similar to other backend
> drivers, we can leverage the same permission control.

I don't think that's right -- other backend drivers use the grant
table mechanism, wher the guest explicitly grants access to only the
memory it needs.  AIUI you're not suggesting that you'll use that for
XenGT! :)

Right - I hope that made some sense.  I'll go get another cup of
coffee and start on that other reply...

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 Dec 11 17:13:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 17:13:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz7IM-000350-BC; Thu, 11 Dec 2014 17:12:54 +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 1Xz7IL-00034v-F3
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 17:12:53 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	3E/BA-28296-490D9845; Thu, 11 Dec 2014 17:12:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418317970!12730221!1
X-Originating-IP: [66.165.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 2615 invoked from network); 11 Dec 2014 17:12:51 -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;
	11 Dec 2014 17:12:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="203055235"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 12:07:38 -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 1Xz7DF-0007qN-S3;
	Thu, 11 Dec 2014 17:07:37 +0000
Date: Thu, 11 Dec 2014 17:07:37 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141211170737.GF1900@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418314995.23309.7.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 04:23:15PM +0000, Ian Campbell wrote:
> On Thu, 2014-12-11 at 16:16 +0000, Anthony PERARD wrote:
> > On Tue, Dec 09, 2014 at 03:56:02PM +0000, Ian Campbell wrote:
> > > On Tue, 2014-12-09 at 15:39 +0000, Anthony PERARD wrote:
> > > > The path to the pty of a Xen PV console is set only in
> > > > virDomainOpenConsole. But this is done too late. A call to
> > > > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > > > the pty, but a call after OpenConsole will.
> > > > 
> > > > e.g. of the current issue.
> > > > Starting a domain with '<console type="pty"/>'
> > > > Then:
> > > > virDomainGetXMLDesc():
> > > >   <devices>
> > > >     <console type='pty'>
> > > >       <target type='xen' port='0'/>
> > > >     </console>
> > > >   </devices>
> > > > virDomainOpenConsole()
> > > > virDomainGetXMLDesc():
> > > >   <devices>
> > > >     <console type='pty' tty='/dev/pts/30'>
> > > >       <source path='/dev/pts/30'/>
> > > >       <target type='xen' port='0'/>
> > > >     </console>
> > > >   </devices>
> > > > 
> > > > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > > > This is done by setting up the path at domain start up instead of in
> > > > OpenConsole.
> > > > 
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > > > 
> > > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > > > 
> > > > ---
> > > > Change in V2:
> > > >   Adding bug report link.
> > > >   Reword the last part of the patch description.
> > > >   Cleanup the code.
> > > >   Use VIR_FREE before VIR_STRDUP.
> > > >   Remove the code from OpenConsole as it is now a duplicate.
> > > > ---
> > > >  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
> > > >  src/libxl/libxl_driver.c | 15 ---------------
> > > >  2 files changed, 20 insertions(+), 15 deletions(-)
> > > > 
> > > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > > index 9c62291..325de79 100644
> > > > --- a/src/libxl/libxl_domain.c
> > > > +++ b/src/libxl/libxl_domain.c
> > > > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> > > >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > > >          goto cleanup_dom;
> > > >  
> > > > +    if (vm->def->nconsoles) {
> > > > +        virDomainChrDefPtr chr = vm->def->consoles[0];
> > > 
> > > Given vm->def->nconsoles should we loop and do them all?
> > 
> > Maybe. libvirt it self will not be able to access any console that is
> > not the first one (virDomainOpenConsole only provide access to console
> > 0), but a consumer of libvirt could.
> > 
> > > Also, and I really should know the answer to this (and sorry for not
> > > thinking of it earlier), but:
> > > 
> > > > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > > > +                                        chr->target.port, console_type,
> > > > +                                        &console);
> > > 
> > > Might this race against xenconsoled writing the node to xenstore and
> > > therefore be prone to failing when starting multiple guests all at once?
> > 
> > I've look through out libxl, xenconsoled and libvirt, and I could not
> > find any synchronisation point. So I guest it's possible.
> > 
> > > Is there a hook which is called on virsh dumpxml which could update
> > > things on the fly (i.e. lookup the console iff it isn't already set)?
> > 
> > I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
> > to do the check, or having a xenstore watch on the path (if that is
> > possible).
> 
> The aop_console_how option to libxl_domain_create_new and
> libxl_domain_create_restore is documented as:
> 
>   /* A progress report will be made via ao_console_how, of type
>    * domain_create_console_available, when the domain's primary
>    * console is available and can be connected to.
>    */
> 
> Which sounds like exactly what is needed?

It look like it. If I find how to use that.

-- 
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 Dec 11 17:13:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 17:13:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz7IM-000350-BC; Thu, 11 Dec 2014 17:12:54 +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 1Xz7IL-00034v-F3
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 17:12:53 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	3E/BA-28296-490D9845; Thu, 11 Dec 2014 17:12:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418317970!12730221!1
X-Originating-IP: [66.165.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 2615 invoked from network); 11 Dec 2014 17:12:51 -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;
	11 Dec 2014 17:12:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="203055235"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 11 Dec 2014 12:07:38 -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 1Xz7DF-0007qN-S3;
	Thu, 11 Dec 2014 17:07:37 +0000
Date: Thu, 11 Dec 2014 17:07:37 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141211170737.GF1900@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418314995.23309.7.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 04:23:15PM +0000, Ian Campbell wrote:
> On Thu, 2014-12-11 at 16:16 +0000, Anthony PERARD wrote:
> > On Tue, Dec 09, 2014 at 03:56:02PM +0000, Ian Campbell wrote:
> > > On Tue, 2014-12-09 at 15:39 +0000, Anthony PERARD wrote:
> > > > The path to the pty of a Xen PV console is set only in
> > > > virDomainOpenConsole. But this is done too late. A call to
> > > > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > > > the pty, but a call after OpenConsole will.
> > > > 
> > > > e.g. of the current issue.
> > > > Starting a domain with '<console type="pty"/>'
> > > > Then:
> > > > virDomainGetXMLDesc():
> > > >   <devices>
> > > >     <console type='pty'>
> > > >       <target type='xen' port='0'/>
> > > >     </console>
> > > >   </devices>
> > > > virDomainOpenConsole()
> > > > virDomainGetXMLDesc():
> > > >   <devices>
> > > >     <console type='pty' tty='/dev/pts/30'>
> > > >       <source path='/dev/pts/30'/>
> > > >       <target type='xen' port='0'/>
> > > >     </console>
> > > >   </devices>
> > > > 
> > > > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > > > This is done by setting up the path at domain start up instead of in
> > > > OpenConsole.
> > > > 
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > > > 
> > > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > > > 
> > > > ---
> > > > Change in V2:
> > > >   Adding bug report link.
> > > >   Reword the last part of the patch description.
> > > >   Cleanup the code.
> > > >   Use VIR_FREE before VIR_STRDUP.
> > > >   Remove the code from OpenConsole as it is now a duplicate.
> > > > ---
> > > >  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
> > > >  src/libxl/libxl_driver.c | 15 ---------------
> > > >  2 files changed, 20 insertions(+), 15 deletions(-)
> > > > 
> > > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > > index 9c62291..325de79 100644
> > > > --- a/src/libxl/libxl_domain.c
> > > > +++ b/src/libxl/libxl_domain.c
> > > > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> > > >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > > >          goto cleanup_dom;
> > > >  
> > > > +    if (vm->def->nconsoles) {
> > > > +        virDomainChrDefPtr chr = vm->def->consoles[0];
> > > 
> > > Given vm->def->nconsoles should we loop and do them all?
> > 
> > Maybe. libvirt it self will not be able to access any console that is
> > not the first one (virDomainOpenConsole only provide access to console
> > 0), but a consumer of libvirt could.
> > 
> > > Also, and I really should know the answer to this (and sorry for not
> > > thinking of it earlier), but:
> > > 
> > > > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > > > +                                        chr->target.port, console_type,
> > > > +                                        &console);
> > > 
> > > Might this race against xenconsoled writing the node to xenstore and
> > > therefore be prone to failing when starting multiple guests all at once?
> > 
> > I've look through out libxl, xenconsoled and libvirt, and I could not
> > find any synchronisation point. So I guest it's possible.
> > 
> > > Is there a hook which is called on virsh dumpxml which could update
> > > things on the fly (i.e. lookup the console iff it isn't already set)?
> > 
> > I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
> > to do the check, or having a xenstore watch on the path (if that is
> > possible).
> 
> The aop_console_how option to libxl_domain_create_new and
> libxl_domain_create_restore is documented as:
> 
>   /* A progress report will be made via ao_console_how, of type
>    * domain_create_console_available, when the domain's primary
>    * console is available and can be connected to.
>    */
> 
> Which sounds like exactly what is needed?

It look like it. If I find how to use that.

-- 
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 Dec 11 17:41:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 17:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz7jK-0004Jl-5f; Thu, 11 Dec 2014 17:40:46 +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 1Xz7jI-0004Jf-PD
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 17:40:44 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	D4/00-18267-C17D9845; Thu, 11 Dec 2014 17:40:44 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418319642!12743167!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23053 invoked from network); 11 Dec 2014 17:40:42 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-3.tower-31.messagelabs.com with SMTP;
	11 Dec 2014 17:40:42 -0000
X-TM-IMSS-Message-ID: <a959cc0f000bd56e@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 a959cc0f000bd56e ;
	Thu, 11 Dec 2014 12:41: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 sBBHe05v022720; 
	Thu, 11 Dec 2014 12:40:13 -0500
Message-ID: <5489D6F0.4040403@tycho.nsa.gov>
Date: Thu, 11 Dec 2014 12:40:00 -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: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
	<1418205196.19809.34.camel@eu.citrix.com>
	<548991B2020000780004EE44@mail.emea.novell.com>
In-Reply-To: <548991B2020000780004EE44@mail.emea.novell.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/2014 06:44 AM, Jan Beulich wrote:
>>>> On 10.12.14 at 10:53, <Ian.Campbell@eu.citrix.com> wrote:
>> On Wed, 2014-12-10 at 08:07 +0000, Jan Beulich wrote:
>>> --- a/xen/common/domctl.c
>>> +++ b/xen/common/domctl.c
>>> @@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>>>
>>>       case XEN_DOMCTL_irq_permission:
>>>       {
>>> -        unsigned int pirq = op->u.irq_permission.pirq;
>>> +        unsigned int pirq = op->u.irq_permission.pirq, irq;
>>>           int allow = op->u.irq_permission.allow_access;
>>>
>>>           if ( pirq >= d->nr_pirqs )
>>>               ret = -EINVAL;
>>> -        else if ( !pirq_access_permitted(current->domain, pirq) ||
>>> +        else if ( !(irq = pirq_access_permitted(current->domain, pirq)) ||
>>
>> I find hiding an assignment inside the second condition in a chain of
>> if's to be rather obfuscated. Doing an assignment in a standalone if
>> statement is one thing, this is going to far IMHO.
>
> Changed. My main intention was to avoid having to add another
> "break;".
>
>> Also, you range check pirq against d->nr_pirqs but then translate it
>> against current->domain, is that correct?
>
> No, it's not. As much as xsm_irq_permission(XSM_HOOK, d, pirq, allow)
> is bogus, yet it's not clear to me whether switching that to use the Xen
> IRQ number is okay without any other changes. Daniel?
>
> Jan

At the moment, this XSM hook does not inspect the PIRQ argument, so it
is safe to change it to use the Xen IRQ number.  The XSM hooks currently
only inspect the IRQ at mapping time; with this change (and the prior
changes that fixed up the IRQ permissions rangesets), it may make sense
to either add a check here or move the check in order to catch the error
earlier.

-- 
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 Dec 11 17:41:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 17:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz7jK-0004Jl-5f; Thu, 11 Dec 2014 17:40:46 +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 1Xz7jI-0004Jf-PD
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 17:40:44 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	D4/00-18267-C17D9845; Thu, 11 Dec 2014 17:40:44 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418319642!12743167!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23053 invoked from network); 11 Dec 2014 17:40:42 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-3.tower-31.messagelabs.com with SMTP;
	11 Dec 2014 17:40:42 -0000
X-TM-IMSS-Message-ID: <a959cc0f000bd56e@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 a959cc0f000bd56e ;
	Thu, 11 Dec 2014 12:41: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 sBBHe05v022720; 
	Thu, 11 Dec 2014 12:40:13 -0500
Message-ID: <5489D6F0.4040403@tycho.nsa.gov>
Date: Thu, 11 Dec 2014 12:40:00 -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: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>
References: <54880D6B020000780004E6AA@mail.emea.novell.com>
	<1418205196.19809.34.camel@eu.citrix.com>
	<548991B2020000780004EE44@mail.emea.novell.com>
In-Reply-To: <548991B2020000780004EE44@mail.emea.novell.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Tim Deegan <tim@xen.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/2014 06:44 AM, Jan Beulich wrote:
>>>> On 10.12.14 at 10:53, <Ian.Campbell@eu.citrix.com> wrote:
>> On Wed, 2014-12-10 at 08:07 +0000, Jan Beulich wrote:
>>> --- a/xen/common/domctl.c
>>> +++ b/xen/common/domctl.c
>>> @@ -981,18 +981,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>>>
>>>       case XEN_DOMCTL_irq_permission:
>>>       {
>>> -        unsigned int pirq = op->u.irq_permission.pirq;
>>> +        unsigned int pirq = op->u.irq_permission.pirq, irq;
>>>           int allow = op->u.irq_permission.allow_access;
>>>
>>>           if ( pirq >= d->nr_pirqs )
>>>               ret = -EINVAL;
>>> -        else if ( !pirq_access_permitted(current->domain, pirq) ||
>>> +        else if ( !(irq = pirq_access_permitted(current->domain, pirq)) ||
>>
>> I find hiding an assignment inside the second condition in a chain of
>> if's to be rather obfuscated. Doing an assignment in a standalone if
>> statement is one thing, this is going to far IMHO.
>
> Changed. My main intention was to avoid having to add another
> "break;".
>
>> Also, you range check pirq against d->nr_pirqs but then translate it
>> against current->domain, is that correct?
>
> No, it's not. As much as xsm_irq_permission(XSM_HOOK, d, pirq, allow)
> is bogus, yet it's not clear to me whether switching that to use the Xen
> IRQ number is okay without any other changes. Daniel?
>
> Jan

At the moment, this XSM hook does not inspect the PIRQ argument, so it
is safe to change it to use the Xen IRQ number.  The XSM hooks currently
only inspect the IRQ at mapping time; with this change (and the prior
changes that fixed up the IRQ permissions rangesets), it may make sense
to either add a check here or move the check in order to catch the error
earlier.

-- 
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 Dec 11 17:56:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 17: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 1Xz7xz-0005LK-M6; Thu, 11 Dec 2014 17:55:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xz7xx-0005LF-Kc
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 17:55:53 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	E1/2E-14727-8AAD9845; Thu, 11 Dec 2014 17:55:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418320550!8757630!1
X-Originating-IP: [66.165.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 19002 invoked from network); 11 Dec 2014 17:55:51 -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;
	11 Dec 2014 17:55:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="203488198"
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.210.2; Thu, 11 Dec 2014 12:55: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 1Xz7xs-00088z-IA;
	Thu, 11 Dec 2014 17:55:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xz7xs-0002aO-8a;
	Thu, 11 Dec 2014 17:55:48 +0000
Date: Thu, 11 Dec 2014 17:55:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32227-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] 32227: FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32227 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32227/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen      3 host-install(3) broken in 32162 REGR. vs. 31897

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-freebsd10-i386 14 guest-localmigrate/x10 fail pass in 32162
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install      fail pass in 32162
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 32162 pass in 32227
 test-amd64-amd64-pair         8 xen-boot/dst_host  fail in 32162 pass in 32227
 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken in 32162 pass in 32227

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair         17 guest-migrate/src_host/dst_host fail like 31897
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31897

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-amd64-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
 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-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-i386-xl-win7-amd64 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-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-i386-i386-xl-qemuu-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-qemut-win7-amd64 14 guest-stop     fail in 32162 never pass

version targeted for testing:
 xen                  353de6b221c2d0fb59edfceb1f535357e4d84825
baseline version:
 xen                  3e5c06aeea1ff91c3f2247baae372936b67cf411

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-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                         fail    
 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 353de6b221c2d0fb59edfceb1f535357e4d84825
Author: Keir Fraser <keir@xen.org>
Date:   Mon Dec 8 15:32:04 2014 +0100

    switch to write-biased r/w locks
    
    This is to improve fairness: A permanent flow of read acquires can
    otherwise lock out eventual writers indefinitely.
    
    This is CVE-2014-9065 / XSA-114.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
    master date: 2014-12-08 14:45:46 +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 Thu Dec 11 17:56:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 17: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 1Xz7xz-0005LK-M6; Thu, 11 Dec 2014 17:55:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xz7xx-0005LF-Kc
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 17:55:53 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	E1/2E-14727-8AAD9845; Thu, 11 Dec 2014 17:55:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418320550!8757630!1
X-Originating-IP: [66.165.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 19002 invoked from network); 11 Dec 2014 17:55:51 -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;
	11 Dec 2014 17:55:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="203488198"
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.210.2; Thu, 11 Dec 2014 12:55: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 1Xz7xs-00088z-IA;
	Thu, 11 Dec 2014 17:55:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xz7xs-0002aO-8a;
	Thu, 11 Dec 2014 17:55:48 +0000
Date: Thu, 11 Dec 2014 17:55:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32227-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] 32227: FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32227 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32227/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen      3 host-install(3) broken in 32162 REGR. vs. 31897

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-freebsd10-i386 14 guest-localmigrate/x10 fail pass in 32162
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install      fail pass in 32162
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 32162 pass in 32227
 test-amd64-amd64-pair         8 xen-boot/dst_host  fail in 32162 pass in 32227
 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken in 32162 pass in 32227

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair         17 guest-migrate/src_host/dst_host fail like 31897
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31897

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-amd64-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
 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-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-i386-xl-win7-amd64 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-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-i386-i386-xl-qemuu-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-qemut-win7-amd64 14 guest-stop     fail in 32162 never pass

version targeted for testing:
 xen                  353de6b221c2d0fb59edfceb1f535357e4d84825
baseline version:
 xen                  3e5c06aeea1ff91c3f2247baae372936b67cf411

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-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                         fail    
 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 353de6b221c2d0fb59edfceb1f535357e4d84825
Author: Keir Fraser <keir@xen.org>
Date:   Mon Dec 8 15:32:04 2014 +0100

    switch to write-biased r/w locks
    
    This is to improve fairness: A permanent flow of read acquires can
    otherwise lock out eventual writers indefinitely.
    
    This is CVE-2014-9065 / XSA-114.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    master commit: 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db
    master date: 2014-12-08 14:45:46 +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 Thu Dec 11 18:03:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz84d-0005eb-PB; Thu, 11 Dec 2014 18:02:47 +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 1Xz84c-0005eN-3h
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 18:02:46 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	01/E3-25276-54CD9845; Thu, 11 Dec 2014 18:02:45 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418320963!14998408!1
X-Originating-IP: [209.85.192.46]
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 16890 invoked from network); 11 Dec 2014 18:02:44 -0000
Received: from mail-qg0-f46.google.com (HELO mail-qg0-f46.google.com)
	(209.85.192.46)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 18:02:44 -0000
Received: by mail-qg0-f46.google.com with SMTP id q107so2102341qgd.5
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 10:02:43 -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=0Lee/jlgu5mA0DWNtosn92eAaSnUe5ScWQo66mXqwng=;
	b=rW1cprc2LdN8oT7qvHc93hWL5oqLJPkEQw9XS4jq3RNGHat2ItNjuUithzW6JxMq4r
	KzlehaDjHHyxi8zWHnKIeRdL0h9jWmCTZY1kcdZjgzIICGCnkdS8R64iKsvtO5zf5dJh
	1UV0Hzs/WT0b3jABH2E1VKVz/xIuRpjlk0TH/pu05hYWnjB8yJKMWDpB7vWnHo4MQvgc
	lLzajWw+8HywKk/KnBylSHMvac92HsQTvN4E0mMGhGda8dSJW1sxWBQML0SNUaHXW65p
	E6OUfUdKB++leMRSjqPSowIPbVJeRsSN64Gn2toRi1RoEv5KIFQ/Jh6RFTtzK2ChOo1r
	+IRA==
MIME-Version: 1.0
X-Received: by 10.224.88.8 with SMTP id y8mr21515497qal.47.1418320963443; Thu,
	11 Dec 2014 10:02:43 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Thu, 11 Dec 2014 10:02:43 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1412111027550.30971@kaball.uk.xensource.com>
References: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
	<alpine.DEB.2.02.1412111027550.30971@kaball.uk.xensource.com>
Date: Thu, 11 Dec 2014 10:02:43 -0800
Message-ID: <CAAiw7J=VLb5tJn18uYZh-SHO9Kb6PsUTiM694BdzRfjKxpv_-Q@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Few Comments on the Xen SMMU ARM code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11 December 2014 at 02:30, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 10 Dec 2014, manish jaggi wrote:
>> Based on my experience with PCI passthrough code merging, below are
>> some comments:
>> Both require a change in code
>>
>> a) The current code which is non-pci passthrough requires a devices'
>> device tree node to be associated with smmu node, if that device has
>> to be assigned to domU.
>>
>> In our system there is no platform device which can be passthough. All
>> devices (including uart) are enumerated using PCI enumeration.
>> So the device tree looks like
>>
>> pcie0 {
>> }
>>
>> smmu {
>> mmu-masters = <&pcie0 0x100>;
>> }
>>
>> When dom0 boots pcie is assigned to dom0 and a stream ID 0x100 is
>> created which later conflicts with a valid device enumerated later
>>
>> b) Current xen code and linux code used rb_tree with key as dt_node to
>> locate a device and its smmu. With an enumerated device there is no
>> such thing. So this would not work.
>>
>>
>> I need your views how PCI passthrough / Non PCI passthrough code can
>> coexist with the two points mentioned above ?
>
> Hello Manish,
> it is increasingly difficult to reply to your questions without reading
> any patches or well written design documents.

Hi Stefano,
I am sorry about this. I though this mail was discussing on the
approach already being taken in the current code and I was just
pointing out issues. I request you to please read the mail one more
time.

I suggest you send out
> your series, then we can move forward from there.
>

This is the complete smmu.c file which you can refer for PCI
passthrough (http://pastebin.com/QDX8fpDu)
Just FYI this is not a patch, we are still testing on our board and
can post a patch only after our testing is complete.

> Cheers,
>
> Stefano

Best Regards
Manish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 18:03:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz84d-0005eb-PB; Thu, 11 Dec 2014 18:02:47 +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 1Xz84c-0005eN-3h
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 18:02:46 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	01/E3-25276-54CD9845; Thu, 11 Dec 2014 18:02:45 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418320963!14998408!1
X-Originating-IP: [209.85.192.46]
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 16890 invoked from network); 11 Dec 2014 18:02:44 -0000
Received: from mail-qg0-f46.google.com (HELO mail-qg0-f46.google.com)
	(209.85.192.46)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 18:02:44 -0000
Received: by mail-qg0-f46.google.com with SMTP id q107so2102341qgd.5
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 10:02:43 -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=0Lee/jlgu5mA0DWNtosn92eAaSnUe5ScWQo66mXqwng=;
	b=rW1cprc2LdN8oT7qvHc93hWL5oqLJPkEQw9XS4jq3RNGHat2ItNjuUithzW6JxMq4r
	KzlehaDjHHyxi8zWHnKIeRdL0h9jWmCTZY1kcdZjgzIICGCnkdS8R64iKsvtO5zf5dJh
	1UV0Hzs/WT0b3jABH2E1VKVz/xIuRpjlk0TH/pu05hYWnjB8yJKMWDpB7vWnHo4MQvgc
	lLzajWw+8HywKk/KnBylSHMvac92HsQTvN4E0mMGhGda8dSJW1sxWBQML0SNUaHXW65p
	E6OUfUdKB++leMRSjqPSowIPbVJeRsSN64Gn2toRi1RoEv5KIFQ/Jh6RFTtzK2ChOo1r
	+IRA==
MIME-Version: 1.0
X-Received: by 10.224.88.8 with SMTP id y8mr21515497qal.47.1418320963443; Thu,
	11 Dec 2014 10:02:43 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Thu, 11 Dec 2014 10:02:43 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1412111027550.30971@kaball.uk.xensource.com>
References: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
	<alpine.DEB.2.02.1412111027550.30971@kaball.uk.xensource.com>
Date: Thu, 11 Dec 2014 10:02:43 -0800
Message-ID: <CAAiw7J=VLb5tJn18uYZh-SHO9Kb6PsUTiM694BdzRfjKxpv_-Q@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Few Comments on the Xen SMMU ARM code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11 December 2014 at 02:30, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 10 Dec 2014, manish jaggi wrote:
>> Based on my experience with PCI passthrough code merging, below are
>> some comments:
>> Both require a change in code
>>
>> a) The current code which is non-pci passthrough requires a devices'
>> device tree node to be associated with smmu node, if that device has
>> to be assigned to domU.
>>
>> In our system there is no platform device which can be passthough. All
>> devices (including uart) are enumerated using PCI enumeration.
>> So the device tree looks like
>>
>> pcie0 {
>> }
>>
>> smmu {
>> mmu-masters = <&pcie0 0x100>;
>> }
>>
>> When dom0 boots pcie is assigned to dom0 and a stream ID 0x100 is
>> created which later conflicts with a valid device enumerated later
>>
>> b) Current xen code and linux code used rb_tree with key as dt_node to
>> locate a device and its smmu. With an enumerated device there is no
>> such thing. So this would not work.
>>
>>
>> I need your views how PCI passthrough / Non PCI passthrough code can
>> coexist with the two points mentioned above ?
>
> Hello Manish,
> it is increasingly difficult to reply to your questions without reading
> any patches or well written design documents.

Hi Stefano,
I am sorry about this. I though this mail was discussing on the
approach already being taken in the current code and I was just
pointing out issues. I request you to please read the mail one more
time.

I suggest you send out
> your series, then we can move forward from there.
>

This is the complete smmu.c file which you can refer for PCI
passthrough (http://pastebin.com/QDX8fpDu)
Just FYI this is not a patch, we are still testing on our board and
can post a patch only after our testing is complete.

> Cheers,
>
> Stefano

Best Regards
Manish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 18:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18: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 1Xz88c-0005po-3X; Thu, 11 Dec 2014 18:06:54 +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 1Xz88a-0005ok-4y
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 18:06:52 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	7E/C1-02954-B3DD9845; Thu, 11 Dec 2014 18:06:51 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418321209!9875836!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 4516 invoked from network); 11 Dec 2014 18:06:50 -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 Dec 2014 18:06:50 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 52795ABC6;
	Thu, 11 Dec 2014 18:06:49 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Thu, 11 Dec 2014 19:04:21 +0100
Message-Id: <1418321065-10212-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] xen: auto-generate symbols for xen
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Xen hypercalls are defined in include/xen/interface/xen.h. There
are some places where for each hypercall a table element is created.
Instead of manually add each hypercall element to these tables use
an auto generated header built during the make process of the kernel.

Juergen Gross (4):
  xen: build infrastructure for generating hypercall depending symbols
  xen: synchronize include/xen/interface/xen.h with xen
  xen: use generated hypervisor symbols in arch/x86/xen/trace.c
  xen: use generated hypercall symbols in arch/x86/xen/xen-head.S

 arch/x86/syscalls/Makefile  |  9 +++++++
 arch/x86/xen/trace.c        | 50 +++---------------------------------
 arch/x86/xen/xen-head.S     | 62 ++++++++-------------------------------------
 include/xen/interface/xen.h |  6 ++++-
 scripts/xen-hypercalls.sh   | 11 ++++++++
 5 files changed, 39 insertions(+), 99 deletions(-)
 create mode 100644 scripts/xen-hypercalls.sh

-- 
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 Dec 11 18:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18: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 1Xz88a-0005ox-E9; Thu, 11 Dec 2014 18:06:52 +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 1Xz88Z-0005oX-AM
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 18:06:51 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	92/9F-29352-A3DD9845; Thu, 11 Dec 2014 18:06:50 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418321209!9528136!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 21868 invoked from network); 11 Dec 2014 18:06:50 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Dec 2014 18:06:50 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A3661ACBD;
	Thu, 11 Dec 2014 18:06:49 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Thu, 11 Dec 2014 19:04:22 +0100
Message-Id: <1418321065-10212-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418321065-10212-1-git-send-email-jgross@suse.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 1/4] xen: build infrastructure for generating
	hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 there are several places in the kernel which build tables
containing one entry for each possible Xen hypercall. Create an
infrastructure to be able to generate these tables at build time.

Based-on-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/syscalls/Makefile |  9 +++++++++
 scripts/xen-hypercalls.sh  | 11 +++++++++++
 2 files changed, 20 insertions(+)
 create mode 100644 scripts/xen-hypercalls.sh

diff --git a/arch/x86/syscalls/Makefile b/arch/x86/syscalls/Makefile
index 3323c27..a55abb9 100644
--- a/arch/x86/syscalls/Makefile
+++ b/arch/x86/syscalls/Makefile
@@ -19,6 +19,9 @@ quiet_cmd_syshdr = SYSHDR  $@
 quiet_cmd_systbl = SYSTBL  $@
       cmd_systbl = $(CONFIG_SHELL) '$(systbl)' $< $@
 
+quiet_cmd_hypercalls = HYPERCALLS $@
+      cmd_hypercalls = $(CONFIG_SHELL) '$<' $@ $(filter-out $<,$^)
+
 syshdr_abi_unistd_32 := i386
 $(uapi)/unistd_32.h: $(syscall32) $(syshdr)
 	$(call if_changed,syshdr)
@@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
 $(out)/syscalls_64.h: $(syscall64) $(systbl)
 	$(call if_changed,systbl)
 
+$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
+	$(call if_changed,hypercalls)
+
+$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
+
 uapisyshdr-y			+= unistd_32.h unistd_64.h unistd_x32.h
 syshdr-y			+= syscalls_32.h
 syshdr-$(CONFIG_X86_64)		+= unistd_32_ia32.h unistd_64_x32.h
 syshdr-$(CONFIG_X86_64)		+= syscalls_64.h
+syshdr-$(CONFIG_XEN)		+= xen-hypercalls.h
 
 targets	+= $(uapisyshdr-y) $(syshdr-y)
 
diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
new file mode 100644
index 0000000..e6447b7
--- /dev/null
+++ b/scripts/xen-hypercalls.sh
@@ -0,0 +1,11 @@
+#!/bin/sh
+out="$1"
+shift
+in="$@"
+
+for i in $in; do
+	eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
+done | \
+awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
+	END {for (i in v) if (!(v[i] in v))
+		print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
-- 
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 Dec 11 18:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18: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 1Xz88b-0005pP-Gv; Thu, 11 Dec 2014 18:06:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xz88Z-0005oa-TK
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 18:06:52 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	9E/E9-26858-B3DD9845; Thu, 11 Dec 2014 18:06:51 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418321210!12692108!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21944 invoked from network); 11 Dec 2014 18:06:50 -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; 11 Dec 2014 18:06:50 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 8C227AD0C;
	Thu, 11 Dec 2014 18:06:50 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Thu, 11 Dec 2014 19:04:25 +0100
Message-Id: <1418321065-10212-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418321065-10212-1-git-send-email-jgross@suse.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 4/4] xen: use generated hypercall symbols in
	arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 manually list each hypercall in arch/x86/xen/xen-head.S
use the auto generated symbol list.

This also corrects the wrong address of xen_hypercall_mca which was
located 32 bytes higher than it should.

Symbol addresses have been verified to match the correct ones via
objdump output.

Based-on-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/xen-head.S | 62 ++++++++-----------------------------------------
 1 file changed, 10 insertions(+), 52 deletions(-)

diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 674b2225..b2ba341 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -12,6 +12,8 @@
 
 #include <xen/interface/elfnote.h>
 #include <xen/interface/features.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/xen-mca.h>
 #include <asm/xen/interface.h>
 
 #ifdef CONFIG_XEN_PVH
@@ -85,58 +87,14 @@ ENTRY(xen_pvh_early_cpu_init)
 .pushsection .text
 	.balign PAGE_SIZE
 ENTRY(hypercall_page)
-#define NEXT_HYPERCALL(x) \
-	ENTRY(xen_hypercall_##x) \
-	.skip 32
-
-NEXT_HYPERCALL(set_trap_table)
-NEXT_HYPERCALL(mmu_update)
-NEXT_HYPERCALL(set_gdt)
-NEXT_HYPERCALL(stack_switch)
-NEXT_HYPERCALL(set_callbacks)
-NEXT_HYPERCALL(fpu_taskswitch)
-NEXT_HYPERCALL(sched_op_compat)
-NEXT_HYPERCALL(platform_op)
-NEXT_HYPERCALL(set_debugreg)
-NEXT_HYPERCALL(get_debugreg)
-NEXT_HYPERCALL(update_descriptor)
-NEXT_HYPERCALL(ni)
-NEXT_HYPERCALL(memory_op)
-NEXT_HYPERCALL(multicall)
-NEXT_HYPERCALL(update_va_mapping)
-NEXT_HYPERCALL(set_timer_op)
-NEXT_HYPERCALL(event_channel_op_compat)
-NEXT_HYPERCALL(xen_version)
-NEXT_HYPERCALL(console_io)
-NEXT_HYPERCALL(physdev_op_compat)
-NEXT_HYPERCALL(grant_table_op)
-NEXT_HYPERCALL(vm_assist)
-NEXT_HYPERCALL(update_va_mapping_otherdomain)
-NEXT_HYPERCALL(iret)
-NEXT_HYPERCALL(vcpu_op)
-NEXT_HYPERCALL(set_segment_base)
-NEXT_HYPERCALL(mmuext_op)
-NEXT_HYPERCALL(xsm_op)
-NEXT_HYPERCALL(nmi_op)
-NEXT_HYPERCALL(sched_op)
-NEXT_HYPERCALL(callback_op)
-NEXT_HYPERCALL(xenoprof_op)
-NEXT_HYPERCALL(event_channel_op)
-NEXT_HYPERCALL(physdev_op)
-NEXT_HYPERCALL(hvm_op)
-NEXT_HYPERCALL(sysctl)
-NEXT_HYPERCALL(domctl)
-NEXT_HYPERCALL(kexec_op)
-NEXT_HYPERCALL(tmem_op) /* 38 */
-ENTRY(xen_hypercall_rsvr)
-	.skip 320
-NEXT_HYPERCALL(mca) /* 48 */
-NEXT_HYPERCALL(arch_1)
-NEXT_HYPERCALL(arch_2)
-NEXT_HYPERCALL(arch_3)
-NEXT_HYPERCALL(arch_4)
-NEXT_HYPERCALL(arch_5)
-NEXT_HYPERCALL(arch_6)
+	.skip PAGE_SIZE
+
+#define HYPERCALL(n) \
+	.equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \
+	.type xen_hypercall_##n, function; .size xen_hypercall_##n, 32
+#include <asm/xen-hypercalls.h>
+#undef HYPERCALL
+
 	.balign PAGE_SIZE
 .popsection
 
-- 
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 Dec 11 18:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18: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 1Xz88a-0005ox-E9; Thu, 11 Dec 2014 18:06:52 +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 1Xz88Z-0005oX-AM
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 18:06:51 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	92/9F-29352-A3DD9845; Thu, 11 Dec 2014 18:06:50 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418321209!9528136!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 21868 invoked from network); 11 Dec 2014 18:06:50 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Dec 2014 18:06:50 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id A3661ACBD;
	Thu, 11 Dec 2014 18:06:49 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Thu, 11 Dec 2014 19:04:22 +0100
Message-Id: <1418321065-10212-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418321065-10212-1-git-send-email-jgross@suse.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 1/4] xen: build infrastructure for generating
	hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 there are several places in the kernel which build tables
containing one entry for each possible Xen hypercall. Create an
infrastructure to be able to generate these tables at build time.

Based-on-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/syscalls/Makefile |  9 +++++++++
 scripts/xen-hypercalls.sh  | 11 +++++++++++
 2 files changed, 20 insertions(+)
 create mode 100644 scripts/xen-hypercalls.sh

diff --git a/arch/x86/syscalls/Makefile b/arch/x86/syscalls/Makefile
index 3323c27..a55abb9 100644
--- a/arch/x86/syscalls/Makefile
+++ b/arch/x86/syscalls/Makefile
@@ -19,6 +19,9 @@ quiet_cmd_syshdr = SYSHDR  $@
 quiet_cmd_systbl = SYSTBL  $@
       cmd_systbl = $(CONFIG_SHELL) '$(systbl)' $< $@
 
+quiet_cmd_hypercalls = HYPERCALLS $@
+      cmd_hypercalls = $(CONFIG_SHELL) '$<' $@ $(filter-out $<,$^)
+
 syshdr_abi_unistd_32 := i386
 $(uapi)/unistd_32.h: $(syscall32) $(syshdr)
 	$(call if_changed,syshdr)
@@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
 $(out)/syscalls_64.h: $(syscall64) $(systbl)
 	$(call if_changed,systbl)
 
+$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
+	$(call if_changed,hypercalls)
+
+$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
+
 uapisyshdr-y			+= unistd_32.h unistd_64.h unistd_x32.h
 syshdr-y			+= syscalls_32.h
 syshdr-$(CONFIG_X86_64)		+= unistd_32_ia32.h unistd_64_x32.h
 syshdr-$(CONFIG_X86_64)		+= syscalls_64.h
+syshdr-$(CONFIG_XEN)		+= xen-hypercalls.h
 
 targets	+= $(uapisyshdr-y) $(syshdr-y)
 
diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
new file mode 100644
index 0000000..e6447b7
--- /dev/null
+++ b/scripts/xen-hypercalls.sh
@@ -0,0 +1,11 @@
+#!/bin/sh
+out="$1"
+shift
+in="$@"
+
+for i in $in; do
+	eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
+done | \
+awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
+	END {for (i in v) if (!(v[i] in v))
+		print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
-- 
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 Dec 11 18:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18: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 1Xz88a-0005p4-PC; Thu, 11 Dec 2014 18:06:52 +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 1Xz88Z-0005oY-Ed
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 18:06:51 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	5C/C5-09284-A3DD9845; Thu, 11 Dec 2014 18:06:50 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418321210!12674612!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 6898 invoked from network); 11 Dec 2014 18:06:50 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 18:06:50 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id EAC3EAD06;
	Thu, 11 Dec 2014 18:06:49 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Thu, 11 Dec 2014 19:04:23 +0100
Message-Id: <1418321065-10212-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418321065-10212-1-git-send-email-jgross@suse.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 2/4] xen: synchronize
	include/xen/interface/xen.h with xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The header include/xen/interface/xen.h doesn't contain all definitions
from Xen's version of that header. Update it accordingly.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/trace.c        | 2 +-
 include/xen/interface/xen.h | 6 +++++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/trace.c b/arch/x86/xen/trace.c
index 520022d..8296cdf 100644
--- a/arch/x86/xen/trace.c
+++ b/arch/x86/xen/trace.c
@@ -29,7 +29,7 @@ static const char *xen_hypercall_names[] = {
 	N(vcpu_op),
 	N(set_segment_base),
 	N(mmuext_op),
-	N(acm_op),
+	N(xsm_op),
 	N(nmi_op),
 	N(sched_op),
 	N(callback_op),
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index f68719f..a483789 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -67,7 +67,7 @@
 #define __HYPERVISOR_vcpu_op              24
 #define __HYPERVISOR_set_segment_base     25 /* x86/64 only */
 #define __HYPERVISOR_mmuext_op            26
-#define __HYPERVISOR_acm_op               27
+#define __HYPERVISOR_xsm_op               27
 #define __HYPERVISOR_nmi_op               28
 #define __HYPERVISOR_sched_op             29
 #define __HYPERVISOR_callback_op          30
@@ -75,7 +75,11 @@
 #define __HYPERVISOR_event_channel_op     32
 #define __HYPERVISOR_physdev_op           33
 #define __HYPERVISOR_hvm_op               34
+#define __HYPERVISOR_sysctl               35
+#define __HYPERVISOR_domctl               36
+#define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
+#define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient */
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
-- 
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 Dec 11 18:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18: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 1Xz88c-0005po-3X; Thu, 11 Dec 2014 18:06:54 +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 1Xz88a-0005ok-4y
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 18:06:52 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	7E/C1-02954-B3DD9845; Thu, 11 Dec 2014 18:06:51 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418321209!9875836!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 4516 invoked from network); 11 Dec 2014 18:06:50 -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 Dec 2014 18:06:50 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 52795ABC6;
	Thu, 11 Dec 2014 18:06:49 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Thu, 11 Dec 2014 19:04:21 +0100
Message-Id: <1418321065-10212-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] xen: auto-generate symbols for xen
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Xen hypercalls are defined in include/xen/interface/xen.h. There
are some places where for each hypercall a table element is created.
Instead of manually add each hypercall element to these tables use
an auto generated header built during the make process of the kernel.

Juergen Gross (4):
  xen: build infrastructure for generating hypercall depending symbols
  xen: synchronize include/xen/interface/xen.h with xen
  xen: use generated hypervisor symbols in arch/x86/xen/trace.c
  xen: use generated hypercall symbols in arch/x86/xen/xen-head.S

 arch/x86/syscalls/Makefile  |  9 +++++++
 arch/x86/xen/trace.c        | 50 +++---------------------------------
 arch/x86/xen/xen-head.S     | 62 ++++++++-------------------------------------
 include/xen/interface/xen.h |  6 ++++-
 scripts/xen-hypercalls.sh   | 11 ++++++++
 5 files changed, 39 insertions(+), 99 deletions(-)
 create mode 100644 scripts/xen-hypercalls.sh

-- 
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 Dec 11 18:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18: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 1Xz88b-0005pB-44; Thu, 11 Dec 2014 18:06:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xz88Z-0005oZ-Pt
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 18:06:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0A/4D-09842-B3DD9845; Thu, 11 Dec 2014 18:06:51 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418321210!14999135!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 5404 invoked from network); 11 Dec 2014 18:06:50 -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; 11 Dec 2014 18:06:50 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 40595AD0B;
	Thu, 11 Dec 2014 18:06:50 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Thu, 11 Dec 2014 19:04:24 +0100
Message-Id: <1418321065-10212-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418321065-10212-1-git-send-email-jgross@suse.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 3/4] xen: use generated hypervisor symbols in
	arch/x86/xen/trace.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 manually list all hypervisor calls in arch/x86/xen/trace.c
use the auto generated list.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/trace.c | 50 ++++----------------------------------------------
 1 file changed, 4 insertions(+), 46 deletions(-)

diff --git a/arch/x86/xen/trace.c b/arch/x86/xen/trace.c
index 8296cdf..a702ec2 100644
--- a/arch/x86/xen/trace.c
+++ b/arch/x86/xen/trace.c
@@ -1,54 +1,12 @@
 #include <linux/ftrace.h>
 #include <xen/interface/xen.h>
+#include <xen/interface/xen-mca.h>
 
-#define N(x)	[__HYPERVISOR_##x] = "("#x")"
+#define HYPERCALL(x)	[__HYPERVISOR_##x] = "("#x")",
 static const char *xen_hypercall_names[] = {
-	N(set_trap_table),
-	N(mmu_update),
-	N(set_gdt),
-	N(stack_switch),
-	N(set_callbacks),
-	N(fpu_taskswitch),
-	N(sched_op_compat),
-	N(dom0_op),
-	N(set_debugreg),
-	N(get_debugreg),
-	N(update_descriptor),
-	N(memory_op),
-	N(multicall),
-	N(update_va_mapping),
-	N(set_timer_op),
-	N(event_channel_op_compat),
-	N(xen_version),
-	N(console_io),
-	N(physdev_op_compat),
-	N(grant_table_op),
-	N(vm_assist),
-	N(update_va_mapping_otherdomain),
-	N(iret),
-	N(vcpu_op),
-	N(set_segment_base),
-	N(mmuext_op),
-	N(xsm_op),
-	N(nmi_op),
-	N(sched_op),
-	N(callback_op),
-	N(xenoprof_op),
-	N(event_channel_op),
-	N(physdev_op),
-	N(hvm_op),
-
-/* Architecture-specific hypercall definitions. */
-	N(arch_0),
-	N(arch_1),
-	N(arch_2),
-	N(arch_3),
-	N(arch_4),
-	N(arch_5),
-	N(arch_6),
-	N(arch_7),
+#include <asm/xen-hypercalls.h>
 };
-#undef N
+#undef HYPERCALL
 
 static const char *xen_hypercall_name(unsigned op)
 {
-- 
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 Dec 11 18:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18: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 1Xz88a-0005p4-PC; Thu, 11 Dec 2014 18:06:52 +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 1Xz88Z-0005oY-Ed
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 18:06:51 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	5C/C5-09284-A3DD9845; Thu, 11 Dec 2014 18:06:50 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418321210!12674612!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 6898 invoked from network); 11 Dec 2014 18:06:50 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 18:06:50 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id EAC3EAD06;
	Thu, 11 Dec 2014 18:06:49 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Thu, 11 Dec 2014 19:04:23 +0100
Message-Id: <1418321065-10212-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418321065-10212-1-git-send-email-jgross@suse.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 2/4] xen: synchronize
	include/xen/interface/xen.h with xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The header include/xen/interface/xen.h doesn't contain all definitions
from Xen's version of that header. Update it accordingly.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/trace.c        | 2 +-
 include/xen/interface/xen.h | 6 +++++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/trace.c b/arch/x86/xen/trace.c
index 520022d..8296cdf 100644
--- a/arch/x86/xen/trace.c
+++ b/arch/x86/xen/trace.c
@@ -29,7 +29,7 @@ static const char *xen_hypercall_names[] = {
 	N(vcpu_op),
 	N(set_segment_base),
 	N(mmuext_op),
-	N(acm_op),
+	N(xsm_op),
 	N(nmi_op),
 	N(sched_op),
 	N(callback_op),
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index f68719f..a483789 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -67,7 +67,7 @@
 #define __HYPERVISOR_vcpu_op              24
 #define __HYPERVISOR_set_segment_base     25 /* x86/64 only */
 #define __HYPERVISOR_mmuext_op            26
-#define __HYPERVISOR_acm_op               27
+#define __HYPERVISOR_xsm_op               27
 #define __HYPERVISOR_nmi_op               28
 #define __HYPERVISOR_sched_op             29
 #define __HYPERVISOR_callback_op          30
@@ -75,7 +75,11 @@
 #define __HYPERVISOR_event_channel_op     32
 #define __HYPERVISOR_physdev_op           33
 #define __HYPERVISOR_hvm_op               34
+#define __HYPERVISOR_sysctl               35
+#define __HYPERVISOR_domctl               36
+#define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
+#define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient */
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
-- 
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 Dec 11 18:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18: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 1Xz88b-0005pP-Gv; Thu, 11 Dec 2014 18:06:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xz88Z-0005oa-TK
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 18:06:52 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	9E/E9-26858-B3DD9845; Thu, 11 Dec 2014 18:06:51 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418321210!12692108!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21944 invoked from network); 11 Dec 2014 18:06:50 -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; 11 Dec 2014 18:06:50 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 8C227AD0C;
	Thu, 11 Dec 2014 18:06:50 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Thu, 11 Dec 2014 19:04:25 +0100
Message-Id: <1418321065-10212-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418321065-10212-1-git-send-email-jgross@suse.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 4/4] xen: use generated hypercall symbols in
	arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 manually list each hypercall in arch/x86/xen/xen-head.S
use the auto generated symbol list.

This also corrects the wrong address of xen_hypercall_mca which was
located 32 bytes higher than it should.

Symbol addresses have been verified to match the correct ones via
objdump output.

Based-on-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/xen-head.S | 62 ++++++++-----------------------------------------
 1 file changed, 10 insertions(+), 52 deletions(-)

diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 674b2225..b2ba341 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -12,6 +12,8 @@
 
 #include <xen/interface/elfnote.h>
 #include <xen/interface/features.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/xen-mca.h>
 #include <asm/xen/interface.h>
 
 #ifdef CONFIG_XEN_PVH
@@ -85,58 +87,14 @@ ENTRY(xen_pvh_early_cpu_init)
 .pushsection .text
 	.balign PAGE_SIZE
 ENTRY(hypercall_page)
-#define NEXT_HYPERCALL(x) \
-	ENTRY(xen_hypercall_##x) \
-	.skip 32
-
-NEXT_HYPERCALL(set_trap_table)
-NEXT_HYPERCALL(mmu_update)
-NEXT_HYPERCALL(set_gdt)
-NEXT_HYPERCALL(stack_switch)
-NEXT_HYPERCALL(set_callbacks)
-NEXT_HYPERCALL(fpu_taskswitch)
-NEXT_HYPERCALL(sched_op_compat)
-NEXT_HYPERCALL(platform_op)
-NEXT_HYPERCALL(set_debugreg)
-NEXT_HYPERCALL(get_debugreg)
-NEXT_HYPERCALL(update_descriptor)
-NEXT_HYPERCALL(ni)
-NEXT_HYPERCALL(memory_op)
-NEXT_HYPERCALL(multicall)
-NEXT_HYPERCALL(update_va_mapping)
-NEXT_HYPERCALL(set_timer_op)
-NEXT_HYPERCALL(event_channel_op_compat)
-NEXT_HYPERCALL(xen_version)
-NEXT_HYPERCALL(console_io)
-NEXT_HYPERCALL(physdev_op_compat)
-NEXT_HYPERCALL(grant_table_op)
-NEXT_HYPERCALL(vm_assist)
-NEXT_HYPERCALL(update_va_mapping_otherdomain)
-NEXT_HYPERCALL(iret)
-NEXT_HYPERCALL(vcpu_op)
-NEXT_HYPERCALL(set_segment_base)
-NEXT_HYPERCALL(mmuext_op)
-NEXT_HYPERCALL(xsm_op)
-NEXT_HYPERCALL(nmi_op)
-NEXT_HYPERCALL(sched_op)
-NEXT_HYPERCALL(callback_op)
-NEXT_HYPERCALL(xenoprof_op)
-NEXT_HYPERCALL(event_channel_op)
-NEXT_HYPERCALL(physdev_op)
-NEXT_HYPERCALL(hvm_op)
-NEXT_HYPERCALL(sysctl)
-NEXT_HYPERCALL(domctl)
-NEXT_HYPERCALL(kexec_op)
-NEXT_HYPERCALL(tmem_op) /* 38 */
-ENTRY(xen_hypercall_rsvr)
-	.skip 320
-NEXT_HYPERCALL(mca) /* 48 */
-NEXT_HYPERCALL(arch_1)
-NEXT_HYPERCALL(arch_2)
-NEXT_HYPERCALL(arch_3)
-NEXT_HYPERCALL(arch_4)
-NEXT_HYPERCALL(arch_5)
-NEXT_HYPERCALL(arch_6)
+	.skip PAGE_SIZE
+
+#define HYPERCALL(n) \
+	.equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \
+	.type xen_hypercall_##n, function; .size xen_hypercall_##n, 32
+#include <asm/xen-hypercalls.h>
+#undef HYPERCALL
+
 	.balign PAGE_SIZE
 .popsection
 
-- 
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 Dec 11 18:06:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18: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 1Xz88b-0005pB-44; Thu, 11 Dec 2014 18:06:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1Xz88Z-0005oZ-Pt
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 18:06:51 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0A/4D-09842-B3DD9845; Thu, 11 Dec 2014 18:06:51 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418321210!14999135!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 5404 invoked from network); 11 Dec 2014 18:06:50 -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; 11 Dec 2014 18:06:50 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 40595AD0B;
	Thu, 11 Dec 2014 18:06:50 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Thu, 11 Dec 2014 19:04:24 +0100
Message-Id: <1418321065-10212-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418321065-10212-1-git-send-email-jgross@suse.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [PATCH 3/4] xen: use generated hypervisor symbols in
	arch/x86/xen/trace.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 manually list all hypervisor calls in arch/x86/xen/trace.c
use the auto generated list.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/trace.c | 50 ++++----------------------------------------------
 1 file changed, 4 insertions(+), 46 deletions(-)

diff --git a/arch/x86/xen/trace.c b/arch/x86/xen/trace.c
index 8296cdf..a702ec2 100644
--- a/arch/x86/xen/trace.c
+++ b/arch/x86/xen/trace.c
@@ -1,54 +1,12 @@
 #include <linux/ftrace.h>
 #include <xen/interface/xen.h>
+#include <xen/interface/xen-mca.h>
 
-#define N(x)	[__HYPERVISOR_##x] = "("#x")"
+#define HYPERCALL(x)	[__HYPERVISOR_##x] = "("#x")",
 static const char *xen_hypercall_names[] = {
-	N(set_trap_table),
-	N(mmu_update),
-	N(set_gdt),
-	N(stack_switch),
-	N(set_callbacks),
-	N(fpu_taskswitch),
-	N(sched_op_compat),
-	N(dom0_op),
-	N(set_debugreg),
-	N(get_debugreg),
-	N(update_descriptor),
-	N(memory_op),
-	N(multicall),
-	N(update_va_mapping),
-	N(set_timer_op),
-	N(event_channel_op_compat),
-	N(xen_version),
-	N(console_io),
-	N(physdev_op_compat),
-	N(grant_table_op),
-	N(vm_assist),
-	N(update_va_mapping_otherdomain),
-	N(iret),
-	N(vcpu_op),
-	N(set_segment_base),
-	N(mmuext_op),
-	N(xsm_op),
-	N(nmi_op),
-	N(sched_op),
-	N(callback_op),
-	N(xenoprof_op),
-	N(event_channel_op),
-	N(physdev_op),
-	N(hvm_op),
-
-/* Architecture-specific hypercall definitions. */
-	N(arch_0),
-	N(arch_1),
-	N(arch_2),
-	N(arch_3),
-	N(arch_4),
-	N(arch_5),
-	N(arch_6),
-	N(arch_7),
+#include <asm/xen-hypercalls.h>
 };
-#undef N
+#undef HYPERCALL
 
 static const char *xen_hypercall_name(unsigned op)
 {
-- 
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 Dec 11 18:07:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18: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 1Xz89Z-00068u-KZ; Thu, 11 Dec 2014 18:07:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mswilson@gmail.com>) id 1Xz89Y-00068U-AJ
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 18:07:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C4/C8-25276-77DD9845; Thu, 11 Dec 2014 18:07:51 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418321269!15003607!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18472 invoked from network); 11 Dec 2014 18:07:51 -0000
Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com)
	(209.85.220.44)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 18:07:51 -0000
Received: by mail-pa0-f44.google.com with SMTP id et14so5562626pad.3
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 10:07:49 -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=gq8Sfk8bT6QXduWZB7xIEs6TIw3TKb8vHTF9A7SAQog=;
	b=uGiq0ayqO0tfgNQq/mx00+HOHU35cEV7bKDnk0ELlxLIWvH+W0XzzzutouGWj7NOp+
	bbkJReS2R9A6PyqMlj2UfhJjAM+C8e08T1zY6VcxFpKrntn7i/YmX6q3iBPBZloHym4c
	i0iLpGToq72RZHPWm4eYpkb/JBw+x4/WJifeWj0PBMSQGXAnbwe5QxCigy027KIZZT4R
	+OKghLcgMgM3VBfTrZ0L7ZiqAEw2wK03C+nhz9PVrKz0S3pAChIFi0rkh7kr/abA04O5
	4V9vAfxUuMPOE1OCzOQRvx2a1sooik1L3dwYCxHmo+ewZQZ9kpCajAsF3DDLl8+XNhsB
	0l6g==
X-Received: by 10.66.220.34 with SMTP id pt2mr19099063pac.142.1418321269362;
	Thu, 11 Dec 2014 10:07:49 -0800 (PST)
Received: from mswilson@gmail.com (54-240-196-185.amazon.com. [54.240.196.185])
	by mx.google.com with ESMTPSA id f1sm1904029pds.93.2014.12.11.10.07.46
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 11 Dec 2014 10:07:48 -0800 (PST)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
	Thu, 11 Dec 2014 10:07:44 -0800
Date: Thu, 11 Dec 2014 10:07:44 -0800
From: Matt Wilson <msw@linux.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141211180737.GA29692@u109add4315675089e695.ant.amazon.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
	<20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
	<54882EAA020000780004E7DE@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54882EAA020000780004E7DE@mail.emea.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Keir Fraser <keir@xen.org>, 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 Wed, Dec 10, 2014 at 10:29:46AM +0000, Jan Beulich wrote:
> >>> On 10.12.14 at 07:00, <msw@linux.com> wrote:
> > On Thu, Nov 06, 2014 at 09:27:59PM +0000, Andrew Cooper wrote:
> >> 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.
> > 
> > Sorry for chiming in late...
> > 
> > That's not strictly true. You can use the processor index in ACPI.
> 
> Not really, no. The ACPI tables get created by hvmloader, without
> regard to Xen vCPU numbering afaict.

The ACPI tables created by hvmloader must take Xen vCPU numbering into
regard, at last as a consideration as both hvmloader and the
hypervisor share this "vcpu_id * 2" math for assigning APIC IDs.

> >> >> 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.
> > 
> > No, don't assume anything about APIC IDs mapping to Xen virtual
> > processor index. This will break things on EC2 instances that expose
> > proper CPU topology through CPUID, and this does *not* follow the
> > "index * 2" formula.
> 
> Hmm, you say "no" first, but the rest of your statement seems to
> agree with what Andrew was saying...

I say "no" because the guest has more to work on than APIC IDs. It has
ACPI processor object 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.
> > 
> > And the Xen vCPU index can be determined by the processor object IDs
> > in DSDT.
> 
> I hope you don't have code doing so, as such an association isn't
> pinned down anywhere in the ABI afaik.

I think that both Linux and FreeBSD are using the enumeration of CPUs
in ACPI tables to derive the vCPU ID needed for HYPERVISOR_vcpu_op
hypercalls. For Linux, we use smp_processor_id() to get the vCPU
ID. This, as far as I know, will enumerate as CPUs are presented in
ACPI tables (where CPU 0, the boot CPU, will return 0 for
smp_processor_id() and so on.).

--msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 18:07:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18: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 1Xz89Z-00068u-KZ; Thu, 11 Dec 2014 18:07:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mswilson@gmail.com>) id 1Xz89Y-00068U-AJ
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 18:07:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C4/C8-25276-77DD9845; Thu, 11 Dec 2014 18:07:51 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418321269!15003607!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18472 invoked from network); 11 Dec 2014 18:07:51 -0000
Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com)
	(209.85.220.44)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 18:07:51 -0000
Received: by mail-pa0-f44.google.com with SMTP id et14so5562626pad.3
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 10:07:49 -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=gq8Sfk8bT6QXduWZB7xIEs6TIw3TKb8vHTF9A7SAQog=;
	b=uGiq0ayqO0tfgNQq/mx00+HOHU35cEV7bKDnk0ELlxLIWvH+W0XzzzutouGWj7NOp+
	bbkJReS2R9A6PyqMlj2UfhJjAM+C8e08T1zY6VcxFpKrntn7i/YmX6q3iBPBZloHym4c
	i0iLpGToq72RZHPWm4eYpkb/JBw+x4/WJifeWj0PBMSQGXAnbwe5QxCigy027KIZZT4R
	+OKghLcgMgM3VBfTrZ0L7ZiqAEw2wK03C+nhz9PVrKz0S3pAChIFi0rkh7kr/abA04O5
	4V9vAfxUuMPOE1OCzOQRvx2a1sooik1L3dwYCxHmo+ewZQZ9kpCajAsF3DDLl8+XNhsB
	0l6g==
X-Received: by 10.66.220.34 with SMTP id pt2mr19099063pac.142.1418321269362;
	Thu, 11 Dec 2014 10:07:49 -0800 (PST)
Received: from mswilson@gmail.com (54-240-196-185.amazon.com. [54.240.196.185])
	by mx.google.com with ESMTPSA id f1sm1904029pds.93.2014.12.11.10.07.46
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 11 Dec 2014 10:07:48 -0800 (PST)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
	Thu, 11 Dec 2014 10:07:44 -0800
Date: Thu, 11 Dec 2014 10:07:44 -0800
From: Matt Wilson <msw@linux.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141211180737.GA29692@u109add4315675089e695.ant.amazon.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
	<20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
	<54882EAA020000780004E7DE@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54882EAA020000780004E7DE@mail.emea.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Keir Fraser <keir@xen.org>, 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 Wed, Dec 10, 2014 at 10:29:46AM +0000, Jan Beulich wrote:
> >>> On 10.12.14 at 07:00, <msw@linux.com> wrote:
> > On Thu, Nov 06, 2014 at 09:27:59PM +0000, Andrew Cooper wrote:
> >> 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.
> > 
> > Sorry for chiming in late...
> > 
> > That's not strictly true. You can use the processor index in ACPI.
> 
> Not really, no. The ACPI tables get created by hvmloader, without
> regard to Xen vCPU numbering afaict.

The ACPI tables created by hvmloader must take Xen vCPU numbering into
regard, at last as a consideration as both hvmloader and the
hypervisor share this "vcpu_id * 2" math for assigning APIC IDs.

> >> >> 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.
> > 
> > No, don't assume anything about APIC IDs mapping to Xen virtual
> > processor index. This will break things on EC2 instances that expose
> > proper CPU topology through CPUID, and this does *not* follow the
> > "index * 2" formula.
> 
> Hmm, you say "no" first, but the rest of your statement seems to
> agree with what Andrew was saying...

I say "no" because the guest has more to work on than APIC IDs. It has
ACPI processor object 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.
> > 
> > And the Xen vCPU index can be determined by the processor object IDs
> > in DSDT.
> 
> I hope you don't have code doing so, as such an association isn't
> pinned down anywhere in the ABI afaik.

I think that both Linux and FreeBSD are using the enumeration of CPUs
in ACPI tables to derive the vCPU ID needed for HYPERVISOR_vcpu_op
hypercalls. For Linux, we use smp_processor_id() to get the vCPU
ID. This, as far as I know, will enumerate as CPUs are presented in
ACPI tables (where CPU 0, the boot CPU, will return 0 for
smp_processor_id() and so on.).

--msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 18:19:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz8Kk-0007Dx-Su; Thu, 11 Dec 2014 18:19:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mswilson@gmail.com>) id 1Xz8Kj-0007Ds-T8
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 18:19:26 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	73/16-31453-D20E9845; Thu, 11 Dec 2014 18:19:25 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418321963!12863020!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 28472 invoked from network); 11 Dec 2014 18:19:24 -0000
Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com)
	(209.85.220.50)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 18:19:24 -0000
Received: by mail-pa0-f50.google.com with SMTP id bj1so5573325pad.9
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 10:19:23 -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=TBlaTSEG4Gz6byi8YbWgdKljLIuIsbDeClDLTf+XCmA=;
	b=UvtUcM9HRclvYlpvleQJeIfboelDbcSlqO8IAkN1oFdnonvKfB4j5kwFaMeDqubvD+
	CJ/9+CSGWXSV6b/nU2Dfh1G+ZWxCWOOhMcFzTVJvG9/wwdIaMbnTDKCNcFqePBkjWqL3
	tidDZbHY+9RQg3YwA5RMxI1+VBjzuobFpTwoEeUW6AFI59d0vZkGh01J8vBF0uGd/tPB
	f0nyI0JSQC6/EEuic8GbqNOMfm/A0YWbv1/4Xqt+DBP+IVSMdjC2SGRUUj8EGs+mJB0F
	r7g3tsNbO1/MqwoVvPrBCBskYTZK9g58EE3k84IHniQMGtLJXOvqtCD7nHZIdZCJnwGc
	9XWw==
X-Received: by 10.68.68.227 with SMTP id z3mr8580907pbt.3.1418321962986;
	Thu, 11 Dec 2014 10:19:22 -0800 (PST)
Received: from mswilson@gmail.com (54-240-196-186.amazon.com. [54.240.196.186])
	by mx.google.com with ESMTPSA id x9sm1975715pdm.51.2014.12.11.10.19.20
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 11 Dec 2014 10:19:21 -0800 (PST)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
	Thu, 11 Dec 2014 10:19:14 -0800
Date: Thu, 11 Dec 2014 10:19:14 -0800
From: Matt Wilson <msw@linux.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141211181913.GB29692@u109add4315675089e695.ant.amazon.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
	<20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
	<54882222.7090005@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54882222.7090005@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	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 Wed, Dec 10, 2014 at 10:36:18AM +0000, Andrew Cooper wrote:
> On 10/12/14 06:00, Matt Wilson wrote:
> >
> > That's not strictly true. You can use the processor index in ACPI.
> 
> The LAPIC objects in the MADT/APIC table?  That is still constructed
> with the broken LAPIC_ID = 2 * processor_id logic.

Have you checked on an EC2 instance (for example: C3, I2, R3)?

> > And the Xen vCPU index can be determined by the processor object IDs
> > in DSDT.
> 
> The processor object IDs have no requirement in the spec to be in order,
> or contiguous.

True - this is a weak heuristic today, so having a CPUID based
approach would be more robust. (To be clear, I'm not arguing against
the proposed patch - I just want to make sure that the justification
doesn't give people the wrong impression about the functional way to
derive Xen vCPU ID without it.)

> A DSDT processor object refers back to the MADT, which in turn still
> has the broken logic.

See above. :-)

> Also, any solution using ACPI tables is going to be an issue for PVH guests.

PVH guests have the same facilities available to them for vCPU
enumeration as PV guests, no?

--msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 18:19:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz8Kk-0007Dx-Su; Thu, 11 Dec 2014 18:19:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mswilson@gmail.com>) id 1Xz8Kj-0007Ds-T8
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 18:19:26 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	73/16-31453-D20E9845; Thu, 11 Dec 2014 18:19:25 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418321963!12863020!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 28472 invoked from network); 11 Dec 2014 18:19:24 -0000
Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com)
	(209.85.220.50)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 18:19:24 -0000
Received: by mail-pa0-f50.google.com with SMTP id bj1so5573325pad.9
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 10:19:23 -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=TBlaTSEG4Gz6byi8YbWgdKljLIuIsbDeClDLTf+XCmA=;
	b=UvtUcM9HRclvYlpvleQJeIfboelDbcSlqO8IAkN1oFdnonvKfB4j5kwFaMeDqubvD+
	CJ/9+CSGWXSV6b/nU2Dfh1G+ZWxCWOOhMcFzTVJvG9/wwdIaMbnTDKCNcFqePBkjWqL3
	tidDZbHY+9RQg3YwA5RMxI1+VBjzuobFpTwoEeUW6AFI59d0vZkGh01J8vBF0uGd/tPB
	f0nyI0JSQC6/EEuic8GbqNOMfm/A0YWbv1/4Xqt+DBP+IVSMdjC2SGRUUj8EGs+mJB0F
	r7g3tsNbO1/MqwoVvPrBCBskYTZK9g58EE3k84IHniQMGtLJXOvqtCD7nHZIdZCJnwGc
	9XWw==
X-Received: by 10.68.68.227 with SMTP id z3mr8580907pbt.3.1418321962986;
	Thu, 11 Dec 2014 10:19:22 -0800 (PST)
Received: from mswilson@gmail.com (54-240-196-186.amazon.com. [54.240.196.186])
	by mx.google.com with ESMTPSA id x9sm1975715pdm.51.2014.12.11.10.19.20
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 11 Dec 2014 10:19:21 -0800 (PST)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
	Thu, 11 Dec 2014 10:19:14 -0800
Date: Thu, 11 Dec 2014 10:19:14 -0800
From: Matt Wilson <msw@linux.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141211181913.GB29692@u109add4315675089e695.ant.amazon.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
	<20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
	<54882222.7090005@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54882222.7090005@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	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 Wed, Dec 10, 2014 at 10:36:18AM +0000, Andrew Cooper wrote:
> On 10/12/14 06:00, Matt Wilson wrote:
> >
> > That's not strictly true. You can use the processor index in ACPI.
> 
> The LAPIC objects in the MADT/APIC table?  That is still constructed
> with the broken LAPIC_ID = 2 * processor_id logic.

Have you checked on an EC2 instance (for example: C3, I2, R3)?

> > And the Xen vCPU index can be determined by the processor object IDs
> > in DSDT.
> 
> The processor object IDs have no requirement in the spec to be in order,
> or contiguous.

True - this is a weak heuristic today, so having a CPUID based
approach would be more robust. (To be clear, I'm not arguing against
the proposed patch - I just want to make sure that the justification
doesn't give people the wrong impression about the functional way to
derive Xen vCPU ID without it.)

> A DSDT processor object refers back to the MADT, which in turn still
> has the broken logic.

See above. :-)

> Also, any solution using ACPI tables is going to be an issue for PVH guests.

PVH guests have the same facilities available to them for vCPU
enumeration as PV guests, no?

--msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 18:49:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18:49:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz8n0-0008Po-IJ; Thu, 11 Dec 2014 18:48:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1Xz8my-0008Pj-Pl
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 18:48:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	75/3F-09842-407E9845; Thu, 11 Dec 2014 18:48:36 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418323714!15053498!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15641 invoked from network); 11 Dec 2014 18:48:35 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 18:48:35 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:7280:900:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.8/8.14.5) with ESMTP id sBBIliPi002288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Thu, 11 Dec 2014 10:47:44 -0800
Message-ID: <5489E6D0.8020002@zytor.com>
Date: Thu, 11 Dec 2014 10:47:44 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Luis R. Rodriguez" <mcgrof@suse.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<5488E552.8050207@zytor.com> <20141211010344.GO25677@wotan.suse.de>
In-Reply-To: <20141211010344.GO25677@wotan.suse.de>
Cc: jgross@suse.com, x86@kernel.org, peterz@infradead.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, mingo@redhat.com, david.vrabel@citrix.com,
	JBeulich@suse.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/10/2014 05:03 PM, Luis R. Rodriguez wrote:
> 
> This is an issue onloy for for non*-preemptive kernels.
> 
> Some of Xen's hypercalls can take a long time and unfortunately for
> *non*-preemptive kernels this can be quite a bit of an issue.
> We've handled situations like this with cond_resched() before which will
> push even *non*-preemptive kernels to behave as voluntarily preemptive,
> I was not aware to what extent this was done and precedents set but
> its pretety widespread now... this then just addresses once particular
> case where this is also an issuefor but now in IRQ context.
> 
> I agree its a hack but so are all the other cond_reshed() calls then.
> I don't think its a good idea to be spreading use of something like
> this everywhere but after careful review and trying toa void this
> exact code for a while I have not been able to find any other reasonable
> alternative.
> 

This sounds like a patch that is completely unrelated to the rest of the
patch.

	-hpa



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 18:49:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 18:49:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz8n0-0008Po-IJ; Thu, 11 Dec 2014 18:48:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1Xz8my-0008Pj-Pl
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 18:48:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	75/3F-09842-407E9845; Thu, 11 Dec 2014 18:48:36 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418323714!15053498!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15641 invoked from network); 11 Dec 2014 18:48:35 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 18:48:35 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:7280:900:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.8/8.14.5) with ESMTP id sBBIliPi002288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Thu, 11 Dec 2014 10:47:44 -0800
Message-ID: <5489E6D0.8020002@zytor.com>
Date: Thu, 11 Dec 2014 10:47:44 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Luis R. Rodriguez" <mcgrof@suse.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<5488E552.8050207@zytor.com> <20141211010344.GO25677@wotan.suse.de>
In-Reply-To: <20141211010344.GO25677@wotan.suse.de>
Cc: jgross@suse.com, x86@kernel.org, peterz@infradead.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, mingo@redhat.com, david.vrabel@citrix.com,
	JBeulich@suse.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/10/2014 05:03 PM, Luis R. Rodriguez wrote:
> 
> This is an issue onloy for for non*-preemptive kernels.
> 
> Some of Xen's hypercalls can take a long time and unfortunately for
> *non*-preemptive kernels this can be quite a bit of an issue.
> We've handled situations like this with cond_resched() before which will
> push even *non*-preemptive kernels to behave as voluntarily preemptive,
> I was not aware to what extent this was done and precedents set but
> its pretety widespread now... this then just addresses once particular
> case where this is also an issuefor but now in IRQ context.
> 
> I agree its a hack but so are all the other cond_reshed() calls then.
> I don't think its a good idea to be spreading use of something like
> this everywhere but after careful review and trying toa void this
> exact code for a while I have not been able to find any other reasonable
> alternative.
> 

This sounds like a patch that is completely unrelated to the rest of the
patch.

	-hpa



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 19:01:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz8zW-0000VN-3o; Thu, 11 Dec 2014 19:01:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xz8zU-0000VI-2j
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 19:01:32 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	FA/EF-24124-B0AE9845; Thu, 11 Dec 2014 19:01:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418324487!12932539!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 11046 invoked from network); 11 Dec 2014 19:01:30 -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;
	11 Dec 2014 19:01:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,559,1413244800"; d="scan'208";a="203115717"
Message-ID: <5489E9E7.8020608@citrix.com>
Date: Thu, 11 Dec 2014 19:00: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: Matt Wilson <msw@linux.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
	<20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
	<54882222.7090005@citrix.com>
	<20141211181913.GB29692@u109add4315675089e695.ant.amazon.com>
In-Reply-To: <20141211181913.GB29692@u109add4315675089e695.ant.amazon.com>
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	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 11/12/14 18:19, Matt Wilson wrote:
> On Wed, Dec 10, 2014 at 10:36:18AM +0000, Andrew Cooper wrote:
>> On 10/12/14 06:00, Matt Wilson wrote:
>>> That's not strictly true. You can use the processor index in ACPI.
>> The LAPIC objects in the MADT/APIC table?  That is still constructed
>> with the broken LAPIC_ID = 2 * processor_id logic.
> Have you checked on an EC2 instance (for example: C3, I2, R3)?

I meant in terms of upstream code.  I will believe you when you say that
those instances do it differently.

My point was that the processor index is only as accurate as hvmloader
makes it, and upstream, this relies on the broken logic.

Even if hvmloader is altered and does things differently, it is still
bogus to draw any inference of vcpu_id from processor id.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 19:01:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz8zW-0000VN-3o; Thu, 11 Dec 2014 19:01:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Xz8zU-0000VI-2j
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 19:01:32 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	FA/EF-24124-B0AE9845; Thu, 11 Dec 2014 19:01:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418324487!12932539!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 11046 invoked from network); 11 Dec 2014 19:01:30 -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;
	11 Dec 2014 19:01:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,559,1413244800"; d="scan'208";a="203115717"
Message-ID: <5489E9E7.8020608@citrix.com>
Date: Thu, 11 Dec 2014 19:00: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: Matt Wilson <msw@linux.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
	<20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
	<54882222.7090005@citrix.com>
	<20141211181913.GB29692@u109add4315675089e695.ant.amazon.com>
In-Reply-To: <20141211181913.GB29692@u109add4315675089e695.ant.amazon.com>
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	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 11/12/14 18:19, Matt Wilson wrote:
> On Wed, Dec 10, 2014 at 10:36:18AM +0000, Andrew Cooper wrote:
>> On 10/12/14 06:00, Matt Wilson wrote:
>>> That's not strictly true. You can use the processor index in ACPI.
>> The LAPIC objects in the MADT/APIC table?  That is still constructed
>> with the broken LAPIC_ID = 2 * processor_id logic.
> Have you checked on an EC2 instance (for example: C3, I2, R3)?

I meant in terms of upstream code.  I will believe you when you say that
those instances do it differently.

My point was that the processor index is only as accurate as hvmloader
makes it, and upstream, this relies on the broken logic.

Even if hvmloader is altered and does things differently, it is still
bogus to draw any inference of vcpu_id from processor id.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 19:11:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19:11:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz98e-0000yo-5W; Thu, 11 Dec 2014 19:11:00 +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 1Xz98d-0000yj-4O
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 19:10:59 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B9/F9-25276-24CE9845; Thu, 11 Dec 2014 19:10:58 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418325057!15053143!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7776 invoked from network); 11 Dec 2014 19:10:57 -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;
	11 Dec 2014 19:10:57 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so7335970wgh.2
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 11:10: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:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=K8n9Snzd4ZumE5evyA+qjz4TNFA7Re/HB6bvoT6fXPQ=;
	b=h1XI463qHYI2U5C7+VTxqqR0FqQe+QSpR+G/TPlB4K6bGNU04cxFTub25AO7J7r0FE
	AzoggZOS2W6cGm6AndMwfFP3mMMTMJSL9KslzwpsqbJI0VZ/TXbWArU15uKY3QXvvjvL
	T3LgXJQ/7MQzAQcTBwBTtbIy3M5LVxfKc3ivzMOl9grm3sHmtzNO3OLTWDSyXY3zq2vy
	FXFXZ0pqQsU+l4SpGD8fAIZlf41X0BVY/DdJ13iFKszvHwRYHvw4i28M9Mxo6rE19t6h
	6AXIFS6Qz7ili++YH79czmGHTkcCcahVVYYyMb5jGmIs7iBd/awjYGCJrkGbuQlrJll/
	ybtQ==
X-Gm-Message-State: ALoCoQnPXU/yoU/+XwCGlThffi+Hx2HGUz4OyAGtLnh0V73gXGE3GvBCnfKejMtk35Mt7Kap3A6t
X-Received: by 10.194.109.6 with SMTP id ho6mr19900365wjb.93.1418325057655;
	Thu, 11 Dec 2014 11:10:57 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id js5sm331545wid.11.2014.12.11.11.10.56
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 11:10:56 -0800 (PST)
Message-ID: <5489EC3C.6040008@linaro.org>
Date: Thu, 11 Dec 2014 19:10:52 +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: manish jaggi <manishjaggi.oss@gmail.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>	<alpine.DEB.2.02.1412111027550.30971@kaball.uk.xensource.com>
	<CAAiw7J=VLb5tJn18uYZh-SHO9Kb6PsUTiM694BdzRfjKxpv_-Q@mail.gmail.com>
In-Reply-To: <CAAiw7J=VLb5tJn18uYZh-SHO9Kb6PsUTiM694BdzRfjKxpv_-Q@mail.gmail.com>
Cc: manish.jaggi@caviumnetworks.com, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Few Comments on the Xen SMMU ARM code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Manish,

On 11/12/14 18:02, manish jaggi wrote:
> On 11 December 2014 at 02:30, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Wed, 10 Dec 2014, manish jaggi wrote:
>>> Based on my experience with PCI passthrough code merging, below are
>>> some comments:
>>> Both require a change in code
>>>
>>> a) The current code which is non-pci passthrough requires a devices'
>>> device tree node to be associated with smmu node, if that device has
>>> to be assigned to domU.
>>>
>>> In our system there is no platform device which can be passthough. All
>>> devices (including uart) are enumerated using PCI enumeration.
>>> So the device tree looks like
>>>
>>> pcie0 {
>>> }
>>>
>>> smmu {
>>> mmu-masters = <&pcie0 0x100>;
>>> }
>>>
>>> When dom0 boots pcie is assigned to dom0 and a stream ID 0x100 is
>>> created which later conflicts with a valid device enumerated later
>>>
>>> b) Current xen code and linux code used rb_tree with key as dt_node to
>>> locate a device and its smmu. With an enumerated device there is no
>>> such thing. So this would not work.
>>>
>>>
>>> I need your views how PCI passthrough / Non PCI passthrough code can
>>> coexist with the two points mentioned above ?
>>
>> Hello Manish,
>> it is increasingly difficult to reply to your questions without reading
>> any patches or well written design documents.
> 
> Hi Stefano,
> I am sorry about this. I though this mail was discussing on the
> approach already being taken in the current code and I was just
> pointing out issues. I request you to please read the mail one more
> time.

This is not the first time you asked question about the SMMU driver (see
[1]). As I said, I resynced the SMMU driver to use the same as Linux. So
the PCI support should come nicely.

I haven't send anything yet because I'm still clean up the platform
device passthrough code and not happy with some part of the code.
Anyway, I have pushed a branch passthrough-v2.3 on my personal repo:
http://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git

The SMMU drivers should not change too much (assuming the Maintainers
will be happy my change in the IOMMU interface).

Please take a look and let me know if you need to modified on this new
driver or have any question.

> I suggest you send out
>> your series, then we can move forward from there.
>>
> 
> This is the complete smmu.c file which you can refer for PCI
> passthrough (http://pastebin.com/QDX8fpDu)

It's rather difficult to find your changes in a 2000 lines file where
you have lots of debug and commented code. Furthermore you have some
external definition ( such as extern struct pci_dev pci) which is set
somewhere else.

Can you send the whole series as an RFC which all its dependencies (i.e
Linux, GICv3 ITS...)?

> Just FYI this is not a patch, we are still testing on our board and
> can post a patch only after our testing is complete.

I'm lost... I though PCI passthrough was working for you? So what's the
status of the support?

Regards,

[1] http://lists.xen.org/archives/html/xen-devel/2014-11/msg00018.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 Thu Dec 11 19:11:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19:11:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz98e-0000yo-5W; Thu, 11 Dec 2014 19:11:00 +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 1Xz98d-0000yj-4O
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 19:10:59 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B9/F9-25276-24CE9845; Thu, 11 Dec 2014 19:10:58 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418325057!15053143!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7776 invoked from network); 11 Dec 2014 19:10:57 -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;
	11 Dec 2014 19:10:57 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so7335970wgh.2
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 11:10: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:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=K8n9Snzd4ZumE5evyA+qjz4TNFA7Re/HB6bvoT6fXPQ=;
	b=h1XI463qHYI2U5C7+VTxqqR0FqQe+QSpR+G/TPlB4K6bGNU04cxFTub25AO7J7r0FE
	AzoggZOS2W6cGm6AndMwfFP3mMMTMJSL9KslzwpsqbJI0VZ/TXbWArU15uKY3QXvvjvL
	T3LgXJQ/7MQzAQcTBwBTtbIy3M5LVxfKc3ivzMOl9grm3sHmtzNO3OLTWDSyXY3zq2vy
	FXFXZ0pqQsU+l4SpGD8fAIZlf41X0BVY/DdJ13iFKszvHwRYHvw4i28M9Mxo6rE19t6h
	6AXIFS6Qz7ili++YH79czmGHTkcCcahVVYYyMb5jGmIs7iBd/awjYGCJrkGbuQlrJll/
	ybtQ==
X-Gm-Message-State: ALoCoQnPXU/yoU/+XwCGlThffi+Hx2HGUz4OyAGtLnh0V73gXGE3GvBCnfKejMtk35Mt7Kap3A6t
X-Received: by 10.194.109.6 with SMTP id ho6mr19900365wjb.93.1418325057655;
	Thu, 11 Dec 2014 11:10:57 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id js5sm331545wid.11.2014.12.11.11.10.56
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 Dec 2014 11:10:56 -0800 (PST)
Message-ID: <5489EC3C.6040008@linaro.org>
Date: Thu, 11 Dec 2014 19:10:52 +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: manish jaggi <manishjaggi.oss@gmail.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>	<alpine.DEB.2.02.1412111027550.30971@kaball.uk.xensource.com>
	<CAAiw7J=VLb5tJn18uYZh-SHO9Kb6PsUTiM694BdzRfjKxpv_-Q@mail.gmail.com>
In-Reply-To: <CAAiw7J=VLb5tJn18uYZh-SHO9Kb6PsUTiM694BdzRfjKxpv_-Q@mail.gmail.com>
Cc: manish.jaggi@caviumnetworks.com, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Few Comments on the Xen SMMU ARM code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Manish,

On 11/12/14 18:02, manish jaggi wrote:
> On 11 December 2014 at 02:30, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Wed, 10 Dec 2014, manish jaggi wrote:
>>> Based on my experience with PCI passthrough code merging, below are
>>> some comments:
>>> Both require a change in code
>>>
>>> a) The current code which is non-pci passthrough requires a devices'
>>> device tree node to be associated with smmu node, if that device has
>>> to be assigned to domU.
>>>
>>> In our system there is no platform device which can be passthough. All
>>> devices (including uart) are enumerated using PCI enumeration.
>>> So the device tree looks like
>>>
>>> pcie0 {
>>> }
>>>
>>> smmu {
>>> mmu-masters = <&pcie0 0x100>;
>>> }
>>>
>>> When dom0 boots pcie is assigned to dom0 and a stream ID 0x100 is
>>> created which later conflicts with a valid device enumerated later
>>>
>>> b) Current xen code and linux code used rb_tree with key as dt_node to
>>> locate a device and its smmu. With an enumerated device there is no
>>> such thing. So this would not work.
>>>
>>>
>>> I need your views how PCI passthrough / Non PCI passthrough code can
>>> coexist with the two points mentioned above ?
>>
>> Hello Manish,
>> it is increasingly difficult to reply to your questions without reading
>> any patches or well written design documents.
> 
> Hi Stefano,
> I am sorry about this. I though this mail was discussing on the
> approach already being taken in the current code and I was just
> pointing out issues. I request you to please read the mail one more
> time.

This is not the first time you asked question about the SMMU driver (see
[1]). As I said, I resynced the SMMU driver to use the same as Linux. So
the PCI support should come nicely.

I haven't send anything yet because I'm still clean up the platform
device passthrough code and not happy with some part of the code.
Anyway, I have pushed a branch passthrough-v2.3 on my personal repo:
http://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git

The SMMU drivers should not change too much (assuming the Maintainers
will be happy my change in the IOMMU interface).

Please take a look and let me know if you need to modified on this new
driver or have any question.

> I suggest you send out
>> your series, then we can move forward from there.
>>
> 
> This is the complete smmu.c file which you can refer for PCI
> passthrough (http://pastebin.com/QDX8fpDu)

It's rather difficult to find your changes in a 2000 lines file where
you have lots of debug and commented code. Furthermore you have some
external definition ( such as extern struct pci_dev pci) which is set
somewhere else.

Can you send the whole series as an RFC which all its dependencies (i.e
Linux, GICv3 ITS...)?

> Just FYI this is not a patch, we are still testing on our board and
> can post a patch only after our testing is complete.

I'm lost... I though PCI passthrough was working for you? So what's the
status of the support?

Regards,

[1] http://lists.xen.org/archives/html/xen-devel/2014-11/msg00018.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 Thu Dec 11 19:16:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz9DO-0001TZ-6P; Thu, 11 Dec 2014 19:15: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 1Xz9DM-0001TU-IP
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 19:15:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0F/AD-25276-76DE9845; Thu, 11 Dec 2014 19:15:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418325350!15013818!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10475 invoked from network); 11 Dec 2014 19:15:51 -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; 11 Dec 2014 19:15:51 -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 sBBJFVLI013496
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Dec 2014 19:15:32 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
	sBBJFSal023341
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 11 Dec 2014 19:15:30 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
	sBBJFS4w009336; Thu, 11 Dec 2014 19:15:28 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Dec 2014 11:15:28 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 85791123267; Thu, 11 Dec 2014 14:15:27 -0500 (EST)
Date: Thu, 11 Dec 2014 14:15:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141211191527.GB18992@laptop.dumpdata.com>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
	<alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
	<20141211120424.GA25950@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141211120424.GA25950@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xen.org, M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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 Thu, Dec 11, 2014 at 01:04:24PM +0100, Olaf Hering wrote:
> On Thu, Dec 11, M A Young wrote:
> 
> > Yes, you do need to set explicit selinux permissions when mounting
> > /var/lib/xenstored as otherwise it gets a tmpfs selinux context which
> > xenstored can't use in enforcing mode.
> 
> Is that "enforcing mode" the default? And would it be too cumbersome to

Yes.
> have these context settings in fstab?

That would be a question for the SELinux maintainer..
> 
> > The other selinux issue is that it seems you can't run xenstored through a
> > shell script wrapper, because it still has startup shell script selinux
> > permissions when it is trying to connect to the sockets, so it doesn't work.
> > It does work if you run xenstored directly from the systemd file.
> 
> This sounds like xenstored has to parse the possible environment
> variables found in sysconfig.xencommons all by itself? Is there perhaps
> a way out of the SELinux jail?

We do want to be in the SELinux jail as you call it.

This is what it looks to be doing:

[konrad@laptop SOURCES]$ more var-lib-xenstored.mount 
[Unit]
Description=mount xenstore file system
ConditionPathExists=/proc/xen
RefuseManualStop=true

[Mount]
What=xenstore
Where=/var/lib/xenstored
Type=tmpfs
Options=mode=755,context="system_u:object_r:xenstored_var_lib_t:s0"
[konrad@laptop SOURCES]$ 

I wonder if we can detect the context during build-time (an autoconf function
that checks whether the build is done for Fedora?)

But what if the version of Fedora is different and the object is called
something else?
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 19:16:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz9DO-0001TZ-6P; Thu, 11 Dec 2014 19:15: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 1Xz9DM-0001TU-IP
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 19:15:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	0F/AD-25276-76DE9845; Thu, 11 Dec 2014 19:15:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418325350!15013818!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10475 invoked from network); 11 Dec 2014 19:15:51 -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; 11 Dec 2014 19:15:51 -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 sBBJFVLI013496
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Dec 2014 19:15:32 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
	sBBJFSal023341
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 11 Dec 2014 19:15:30 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
	sBBJFS4w009336; Thu, 11 Dec 2014 19:15:28 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Dec 2014 11:15:28 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 85791123267; Thu, 11 Dec 2014 14:15:27 -0500 (EST)
Date: Thu, 11 Dec 2014 14:15:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141211191527.GB18992@laptop.dumpdata.com>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
	<alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
	<20141211120424.GA25950@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141211120424.GA25950@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xen.org, M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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 Thu, Dec 11, 2014 at 01:04:24PM +0100, Olaf Hering wrote:
> On Thu, Dec 11, M A Young wrote:
> 
> > Yes, you do need to set explicit selinux permissions when mounting
> > /var/lib/xenstored as otherwise it gets a tmpfs selinux context which
> > xenstored can't use in enforcing mode.
> 
> Is that "enforcing mode" the default? And would it be too cumbersome to

Yes.
> have these context settings in fstab?

That would be a question for the SELinux maintainer..
> 
> > The other selinux issue is that it seems you can't run xenstored through a
> > shell script wrapper, because it still has startup shell script selinux
> > permissions when it is trying to connect to the sockets, so it doesn't work.
> > It does work if you run xenstored directly from the systemd file.
> 
> This sounds like xenstored has to parse the possible environment
> variables found in sysconfig.xencommons all by itself? Is there perhaps
> a way out of the SELinux jail?

We do want to be in the SELinux jail as you call it.

This is what it looks to be doing:

[konrad@laptop SOURCES]$ more var-lib-xenstored.mount 
[Unit]
Description=mount xenstore file system
ConditionPathExists=/proc/xen
RefuseManualStop=true

[Mount]
What=xenstore
Where=/var/lib/xenstored
Type=tmpfs
Options=mode=755,context="system_u:object_r:xenstored_var_lib_t:s0"
[konrad@laptop SOURCES]$ 

I wonder if we can detect the context during build-time (an autoconf function
that checks whether the build is done for Fedora?)

But what if the version of Fedora is different and the object is called
something else?
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 19:16:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19: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 1Xz9E9-0001Wy-LE; Thu, 11 Dec 2014 19:16:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xz9E7-0001Wn-Cf
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 19:16:39 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	8E/82-26740-69DE9845; Thu, 11 Dec 2014 19:16:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418325395!12751187!1
X-Originating-IP: [66.165.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 5564 invoked from network); 11 Dec 2014 19:16:37 -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;
	11 Dec 2014 19:16:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,559,1413244800"; d="scan'208";a="203123516"
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.210.2; Thu, 11 Dec 2014 14:16: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 1Xz9DZ-000056-Sz;
	Thu, 11 Dec 2014 19:16:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xz9DZ-0006SC-N5;
	Thu, 11 Dec 2014 19:16:05 +0000
Date: Thu, 11 Dec 2014 19:16:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32232-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] 32232: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32232 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32232/

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. 32194

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32194

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      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  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-xl-qemut-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-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-winxpsp3  1 build-check(1)               blocked  n/a
 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-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-pair         1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-debianhvm-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-winxpsp3  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-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                7fb8da2b8861795e0013e6ee97acd0363d868a35
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  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                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 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                    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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     fail    
 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.

------------------------------------------------------------
commit 7fb8da2b8861795e0013e6ee97acd0363d868a35
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Dec 9 21:48:34 2014 +0000

    Open 2.3 development tree
    
    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 Dec 11 19:16:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19: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 1Xz9E9-0001Wy-LE; Thu, 11 Dec 2014 19:16:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xz9E7-0001Wn-Cf
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 19:16:39 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	8E/82-26740-69DE9845; Thu, 11 Dec 2014 19:16:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418325395!12751187!1
X-Originating-IP: [66.165.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 5564 invoked from network); 11 Dec 2014 19:16:37 -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;
	11 Dec 2014 19:16:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,559,1413244800"; d="scan'208";a="203123516"
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.210.2; Thu, 11 Dec 2014 14:16: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 1Xz9DZ-000056-Sz;
	Thu, 11 Dec 2014 19:16:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xz9DZ-0006SC-N5;
	Thu, 11 Dec 2014 19:16:05 +0000
Date: Thu, 11 Dec 2014 19:16:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32232-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] 32232: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32232 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32232/

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. 32194

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32194

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      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  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-xl-qemut-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-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-winxpsp3  1 build-check(1)               blocked  n/a
 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-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-pair         1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-debianhvm-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-winxpsp3  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-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                7fb8da2b8861795e0013e6ee97acd0363d868a35
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  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                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 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                    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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     fail    
 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.

------------------------------------------------------------
commit 7fb8da2b8861795e0013e6ee97acd0363d868a35
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Tue Dec 9 21:48:34 2014 +0000

    Open 2.3 development tree
    
    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 Dec 11 19:21:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz9IU-0001kh-En; Thu, 11 Dec 2014 19:21:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xz9IS-0001kc-Rk
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 19:21:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	65/19-09842-4AEE9845; Thu, 11 Dec 2014 19:21:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418325667!15040299!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2908 invoked from network); 11 Dec 2014 19:21:07 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 19:21:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418325667; l=528;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=KPcGxIL5tKRN/Wj5uKT3mgoLTyM=;
	b=llKFItZm24XCdKCGe+bIMibJHwfBR2yKsSyF7iftJkpvbn9mrKOob0mvtXmkFKmCtge
	lpbkYQCIqz1jdEtw7s0z3uLVv+t8i8kNJOdAxQxu/JkAoQqOu+ZvDLB4X9/v43pcqclxT
	+0TbaeSNrd/GmNApRvZIRECitSnZte8uzSg=
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.3 AUTH) with ESMTPSA id e050c9qBBJL46of
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 11 Dec 2014 20:21:04 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id CD1055015F; Thu, 11 Dec 2014 20:21:00 +0100 (CET)
Date: Thu, 11 Dec 2014 20:20:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141211192058.GA5709@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
	<alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
	<20141211120424.GA25950@aepfle.de>
	<20141211191527.GB18992@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141211191527.GB18992@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org, M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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 Thu, Dec 11, Konrad Rzeszutek Wilk wrote:

> I wonder if we can detect the context during build-time (an autoconf function
> that checks whether the build is done for Fedora?)
> But what if the version of Fedora is different and the object is called
> something else?

Exactly. The build host is not the host where the code runs. It just
happens to be the same in your case.

This and the fact that xenstored cant (appearently) be launched via a
wrapper script makes we wonder how to deal with SELinux...

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 19:21:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19:21:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz9IU-0001kh-En; Thu, 11 Dec 2014 19:21:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Xz9IS-0001kc-Rk
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 19:21:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	65/19-09842-4AEE9845; Thu, 11 Dec 2014 19:21:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418325667!15040299!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2908 invoked from network); 11 Dec 2014 19:21:07 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 19:21:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418325667; l=528;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=KPcGxIL5tKRN/Wj5uKT3mgoLTyM=;
	b=llKFItZm24XCdKCGe+bIMibJHwfBR2yKsSyF7iftJkpvbn9mrKOob0mvtXmkFKmCtge
	lpbkYQCIqz1jdEtw7s0z3uLVv+t8i8kNJOdAxQxu/JkAoQqOu+ZvDLB4X9/v43pcqclxT
	+0TbaeSNrd/GmNApRvZIRECitSnZte8uzSg=
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.3 AUTH) with ESMTPSA id e050c9qBBJL46of
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 11 Dec 2014 20:21:04 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id CD1055015F; Thu, 11 Dec 2014 20:21:00 +0100 (CET)
Date: Thu, 11 Dec 2014 20:20:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141211192058.GA5709@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
	<alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
	<20141211120424.GA25950@aepfle.de>
	<20141211191527.GB18992@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141211191527.GB18992@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org, M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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 Thu, Dec 11, Konrad Rzeszutek Wilk wrote:

> I wonder if we can detect the context during build-time (an autoconf function
> that checks whether the build is done for Fedora?)
> But what if the version of Fedora is different and the object is called
> something else?

Exactly. The build host is not the host where the code runs. It just
happens to be the same in your case.

This and the fact that xenstored cant (appearently) be launched via a
wrapper script makes we wonder how to deal with SELinux...

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 19:42:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19: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 1Xz9ce-0002aT-Bx; Thu, 11 Dec 2014 19:42:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xz9cc-0002aO-Uz
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 19:41:59 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	C2/06-24124-683F9845; Thu, 11 Dec 2014 19:41:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418326916!12937162!1
X-Originating-IP: [156.151.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 28421 invoked from network); 11 Dec 2014 19:41:57 -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; 11 Dec 2014 19:41: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 sBBJfpBC021219
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Dec 2014 19:41: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
	sBBJfpiL018469
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Dec 2014 19:41:51 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
	sBBJfnsG018390; Thu, 11 Dec 2014 19:41:50 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Dec 2014 11:41:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A39A2123294; Thu, 11 Dec 2014 14:41:48 -0500 (EST)
Date: Thu, 11 Dec 2014 14:41:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141211194148.GG18992@laptop.dumpdata.com>
References: <5489906B020000780004EE34@mail.emea.novell.com>
	<69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.com>
	<5489C88F020000780004F0C2@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5489C88F020000780004F0C2@mail.emea.novell.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@eu.citrix.com>,
	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] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 03:38:39PM +0000, Jan Beulich wrote:
> >>> On 11.12.14 at 16:18, <konrad.wilk@oracle.com> wrote:
> > On December 11, 2014 6:39:07 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
> >>Either
> >>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00260.html 
> >>or (my preference)
> >>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01054.html 
> >>
> > 
> > Daniel's patch fixes the case for EFI map or large CPU count (to a certain 
> > extent). Jan's patch only fixes it for large CPU count. The memmap can be 
> > huge on small CPU count machines.
> 
> The EFI memory map gets printed much later than when the ring
> buffer gets set up with "conring_size=" present.

Right..
> 
> > A proper fix would be to automatically adjust based on memmap and CPU but 
> > that could be too complex.
> 
> The problem isn't the complexity, but the chicken-and-egg problem
> as far as CPU count is concerned. The memory map size would be
> known early enough.

Let me explain my thought process:
 - There are existing knobs that can be used to change this (conring_size=X)
 - But we would like an awesome release where those knobs don't have to
   be used.
 - The patch you posted could be reworked to fully address memmap and CPU.
 - I don't know what your time constraints are for said patch and you
   might not have the energy to rework it.
 - I don't want to put pressure on you or Daniel on having to write new
   patches - especially as folks are going on vacation soon.

Hence as a fallback I believe that Daniel's patch should go in and
Jan's patch can go in too. However if Jan (or somebody else) wants to
rework the v2 (or a new one) to address the memmap issue then that
patch would go in - instead of Daniel's or v2 of Jan patch.

> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 19:42:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19: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 1Xz9ce-0002aT-Bx; Thu, 11 Dec 2014 19:42:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xz9cc-0002aO-Uz
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 19:41:59 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	C2/06-24124-683F9845; Thu, 11 Dec 2014 19:41:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418326916!12937162!1
X-Originating-IP: [156.151.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 28421 invoked from network); 11 Dec 2014 19:41:57 -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; 11 Dec 2014 19:41: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 sBBJfpBC021219
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Dec 2014 19:41: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
	sBBJfpiL018469
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Dec 2014 19:41:51 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
	sBBJfnsG018390; Thu, 11 Dec 2014 19:41:50 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Dec 2014 11:41:49 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A39A2123294; Thu, 11 Dec 2014 14:41:48 -0500 (EST)
Date: Thu, 11 Dec 2014 14:41:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141211194148.GG18992@laptop.dumpdata.com>
References: <5489906B020000780004EE34@mail.emea.novell.com>
	<69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.com>
	<5489C88F020000780004F0C2@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5489C88F020000780004F0C2@mail.emea.novell.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@eu.citrix.com>,
	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] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 03:38:39PM +0000, Jan Beulich wrote:
> >>> On 11.12.14 at 16:18, <konrad.wilk@oracle.com> wrote:
> > On December 11, 2014 6:39:07 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
> >>Either
> >>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00260.html 
> >>or (my preference)
> >>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01054.html 
> >>
> > 
> > Daniel's patch fixes the case for EFI map or large CPU count (to a certain 
> > extent). Jan's patch only fixes it for large CPU count. The memmap can be 
> > huge on small CPU count machines.
> 
> The EFI memory map gets printed much later than when the ring
> buffer gets set up with "conring_size=" present.

Right..
> 
> > A proper fix would be to automatically adjust based on memmap and CPU but 
> > that could be too complex.
> 
> The problem isn't the complexity, but the chicken-and-egg problem
> as far as CPU count is concerned. The memory map size would be
> known early enough.

Let me explain my thought process:
 - There are existing knobs that can be used to change this (conring_size=X)
 - But we would like an awesome release where those knobs don't have to
   be used.
 - The patch you posted could be reworked to fully address memmap and CPU.
 - I don't know what your time constraints are for said patch and you
   might not have the energy to rework it.
 - I don't want to put pressure on you or Daniel on having to write new
   patches - especially as folks are going on vacation soon.

Hence as a fallback I believe that Daniel's patch should go in and
Jan's patch can go in too. However if Jan (or somebody else) wants to
rework the v2 (or a new one) to address the memmap issue then that
patch would go in - instead of Daniel's or v2 of Jan patch.

> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 19:46:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19:46:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz9hP-000334-C0; Thu, 11 Dec 2014 19:46:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek.xen@gmail.com>)
	id 1Xz9hN-00032c-DK; Thu, 11 Dec 2014 19:46:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	60/73-25276-CA4F9845; Thu, 11 Dec 2014 19:46:52 +0000
X-Env-Sender: russell.pavlicek.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418327211!15058148!1
X-Originating-IP: [209.85.217.178]
X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP,
  SUSPICIOUS_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20381 invoked from network); 11 Dec 2014 19:46:51 -0000
Received: from mail-lb0-f178.google.com (HELO mail-lb0-f178.google.com)
	(209.85.217.178)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 19:46:51 -0000
Received: by mail-lb0-f178.google.com with SMTP id f15so5197951lbj.37
	for <multiple recipients>; Thu, 11 Dec 2014 11:46:51 -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=jTY3SSCjJXKEkf0lLNCG3D4OEA4TBYcqNWbuxLuBsqE=;
	b=ZVOOerKuoKO8uvY4FQJVhQzyS2DypGUJrpGJFgfsvPz9B0xb8/woIGWAPL86hOCpsD
	G5g86oG/+DstykIeQBc603LzkXPJsuRb7f8s4PAunf+9XnuPu06Xrs+E4qOPDpKCtPLp
	n132wkgWUuEccvqtdzpJKjVu4gaZ6P/kSUqeLFkQ/JeqdawK9tWjDInzzZmmiOkrjmQS
	1iiSi3v1xd8GevAV6qg9DhPsgoB57SJ3orLVNDSqKWtJx/Qo3+kQhnmq++1M8hA50pgw
	WWMYHVKf9RcymasoWn8OPIhad8cFP7JUufNrvTC8xu6pP2zpngT1OBmPcr3cHA7lmpM7
	4VrA==
MIME-Version: 1.0
X-Received: by 10.153.7.170 with SMTP id dd10mr11602423lad.44.1418327211131;
	Thu, 11 Dec 2014 11:46:51 -0800 (PST)
Received: by 10.112.0.104 with HTTP; Thu, 11 Dec 2014 11:46:51 -0800 (PST)
Date: Thu, 11 Dec 2014 14:46:51 -0500
X-Google-Sender-Auth: pHn9gd75f98-3gyK4Perd-dUCNY
Message-ID: <CAHehzX00Hg7CRLQt1Edmf2E6AW-ndZ54Tcofqcr2ovsyw1MYZQ@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] Monday is the Last Xen Project Document Day of 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Monday, December 15, will be our last Document Day of the year.

Given the 4.5 RC4 Testing scheduled for Wednesday of next week and the holidays
which occur later in the month, we have scheduled Document Day for Monday.

This is a great time to get our documentation ready for the new
release.  Have you
added a new feature in this release?  Make sure it is in the Wiki.
Have you noticed
pages which might be confusing for a new installation?  Now is a great
time to clean
it up.  Have you information on better integrating Xen Project with
other projects?
Share that information with others.

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 Monday, 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

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 Monday in #xendocs!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 19:46:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 19:46:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xz9hP-000334-C0; Thu, 11 Dec 2014 19:46:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek.xen@gmail.com>)
	id 1Xz9hN-00032c-DK; Thu, 11 Dec 2014 19:46:53 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	60/73-25276-CA4F9845; Thu, 11 Dec 2014 19:46:52 +0000
X-Env-Sender: russell.pavlicek.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418327211!15058148!1
X-Originating-IP: [209.85.217.178]
X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP,
  SUSPICIOUS_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20381 invoked from network); 11 Dec 2014 19:46:51 -0000
Received: from mail-lb0-f178.google.com (HELO mail-lb0-f178.google.com)
	(209.85.217.178)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 19:46:51 -0000
Received: by mail-lb0-f178.google.com with SMTP id f15so5197951lbj.37
	for <multiple recipients>; Thu, 11 Dec 2014 11:46:51 -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=jTY3SSCjJXKEkf0lLNCG3D4OEA4TBYcqNWbuxLuBsqE=;
	b=ZVOOerKuoKO8uvY4FQJVhQzyS2DypGUJrpGJFgfsvPz9B0xb8/woIGWAPL86hOCpsD
	G5g86oG/+DstykIeQBc603LzkXPJsuRb7f8s4PAunf+9XnuPu06Xrs+E4qOPDpKCtPLp
	n132wkgWUuEccvqtdzpJKjVu4gaZ6P/kSUqeLFkQ/JeqdawK9tWjDInzzZmmiOkrjmQS
	1iiSi3v1xd8GevAV6qg9DhPsgoB57SJ3orLVNDSqKWtJx/Qo3+kQhnmq++1M8hA50pgw
	WWMYHVKf9RcymasoWn8OPIhad8cFP7JUufNrvTC8xu6pP2zpngT1OBmPcr3cHA7lmpM7
	4VrA==
MIME-Version: 1.0
X-Received: by 10.153.7.170 with SMTP id dd10mr11602423lad.44.1418327211131;
	Thu, 11 Dec 2014 11:46:51 -0800 (PST)
Received: by 10.112.0.104 with HTTP; Thu, 11 Dec 2014 11:46:51 -0800 (PST)
Date: Thu, 11 Dec 2014 14:46:51 -0500
X-Google-Sender-Auth: pHn9gd75f98-3gyK4Perd-dUCNY
Message-ID: <CAHehzX00Hg7CRLQt1Edmf2E6AW-ndZ54Tcofqcr2ovsyw1MYZQ@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] Monday is the Last Xen Project Document Day of 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Monday, December 15, will be our last Document Day of the year.

Given the 4.5 RC4 Testing scheduled for Wednesday of next week and the holidays
which occur later in the month, we have scheduled Document Day for Monday.

This is a great time to get our documentation ready for the new
release.  Have you
added a new feature in this release?  Make sure it is in the Wiki.
Have you noticed
pages which might be confusing for a new installation?  Now is a great
time to clean
it up.  Have you information on better integrating Xen Project with
other projects?
Share that information with others.

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 Monday, 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

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 Monday in #xendocs!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 20:28:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 20:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzALC-00051H-Mf; Thu, 11 Dec 2014 20:28:02 +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 1XzALB-00051C-BQ
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 20:28:01 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	38/15-02954-05EF9845; Thu, 11 Dec 2014 20:28:00 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418329678!14513973!1
X-Originating-IP: [209.85.192.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 16726 invoked from network); 11 Dec 2014 20:27:59 -0000
Received: from mail-pd0-f179.google.com (HELO mail-pd0-f179.google.com)
	(209.85.192.179)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 20:27:59 -0000
Received: by mail-pd0-f179.google.com with SMTP id fp1so5679497pdb.38
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 12:27:58 -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=/90BKntw5C87/JA8TyaT+B+jXlAs8nw+WybYz8g/w4o=;
	b=sG+HgrbJlz1W87kW2t8viBozGq/+Y3BH8/K7QKFrYzc2p6wdCheBoIQAUjlCmVNjMm
	h3wVRpt/2CV9P0ItEunJNVLkGoXknmzkeGsKI41kVA0IRuj8jmZrA5m76U2vBwrtqde6
	cQSnUHhYmuDCOBEmRvLeTuUxB6Y53YWv0+u+WiVdDguzNAfEwdz4iw3VQakjWNfrJoNB
	BVEq1xBMG1DBmviYblJDtM/c8OHgjM9urRrTDhr2Qs6e6cOi+vemZrUdCRKhHQsILKhU
	ftMRam/CrW+SVlwaiZilkblf1fwvKsOPlAtPupJzUuBeICRYPq2J2SreXRkjbuSejqhl
	VSCA==
X-Received: by 10.66.66.40 with SMTP id c8mr20778516pat.66.1418329678119;
	Thu, 11 Dec 2014 12:27:58 -0800 (PST)
Received: from mswilson@gmail.com (54-240-196-186.amazon.com. [54.240.196.186])
	by mx.google.com with ESMTPSA id lg8sm2144254pab.41.2014.12.11.12.27.54
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 11 Dec 2014 12:27:56 -0800 (PST)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
	Thu, 11 Dec 2014 12:27:52 -0800
Date: Thu, 11 Dec 2014 12:27:52 -0800
From: Matt Wilson <msw@linux.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141211202747.GA6811@u109add4315675089e695.ant.amazon.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
	<20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
	<54882222.7090005@citrix.com>
	<20141211181913.GB29692@u109add4315675089e695.ant.amazon.com>
	<5489E9E7.8020608@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5489E9E7.8020608@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	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 Thu, Dec 11, 2014 at 07:00:55PM +0000, Andrew Cooper wrote:
> On 11/12/14 18:19, Matt Wilson wrote:
> > On Wed, Dec 10, 2014 at 10:36:18AM +0000, Andrew Cooper wrote:
> >> On 10/12/14 06:00, Matt Wilson wrote:
> >>> That's not strictly true. You can use the processor index in ACPI.
> >> The LAPIC objects in the MADT/APIC table?  That is still constructed
> >> with the broken LAPIC_ID = 2 * processor_id logic.
> > Have you checked on an EC2 instance (for example: C3, I2, R3)?
> 
> I meant in terms of upstream code.  I will believe you when you say that
> those instances do it differently.
> 
> My point was that the processor index is only as accurate as hvmloader
> makes it, and upstream, this relies on the broken logic.
> 
> Even if hvmloader is altered and does things differently, it is still
> bogus to draw any inference of vcpu_id from processor id.

hvmloader accurately sets the processor_id in the MADT LAPIC tables to
the correct vcpu_id value (by chance, though things would not work if
this was not so).

hvmloader/acpi/build.c:
>    for ( i = 0; i < nr_processor_objects; i++ )
>    {
>        memset(lapic, 0, sizeof(*lapic));
>        lapic->type    = ACPI_PROCESSOR_LOCAL_APIC;
>        lapic->length  = sizeof(*lapic);
>        /* Processor ID must match processor-object IDs in the DSDT. */
>-->     lapic->acpi_processor_id = i;
>        lapic->apic_id = LAPIC_ID(i);
>        lapic->flags = ((i < hvm_info->nr_vcpus) &&
>                        test_bit(i, hvm_info->vcpu_online)
>                        ? ACPI_LOCAL_APIC_ENABLED : 0);
>        lapic++;
>    }

See also hvmloader/config.h:
> #define LAPIC_ID(vcpu_id)   ((vcpu_id) * 2)

See how Keir called this "vcpu_id"?

--msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 20:28:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 20:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzALC-00051H-Mf; Thu, 11 Dec 2014 20:28:02 +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 1XzALB-00051C-BQ
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 20:28:01 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	38/15-02954-05EF9845; Thu, 11 Dec 2014 20:28:00 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418329678!14513973!1
X-Originating-IP: [209.85.192.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 16726 invoked from network); 11 Dec 2014 20:27:59 -0000
Received: from mail-pd0-f179.google.com (HELO mail-pd0-f179.google.com)
	(209.85.192.179)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 20:27:59 -0000
Received: by mail-pd0-f179.google.com with SMTP id fp1so5679497pdb.38
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 12:27:58 -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=/90BKntw5C87/JA8TyaT+B+jXlAs8nw+WybYz8g/w4o=;
	b=sG+HgrbJlz1W87kW2t8viBozGq/+Y3BH8/K7QKFrYzc2p6wdCheBoIQAUjlCmVNjMm
	h3wVRpt/2CV9P0ItEunJNVLkGoXknmzkeGsKI41kVA0IRuj8jmZrA5m76U2vBwrtqde6
	cQSnUHhYmuDCOBEmRvLeTuUxB6Y53YWv0+u+WiVdDguzNAfEwdz4iw3VQakjWNfrJoNB
	BVEq1xBMG1DBmviYblJDtM/c8OHgjM9urRrTDhr2Qs6e6cOi+vemZrUdCRKhHQsILKhU
	ftMRam/CrW+SVlwaiZilkblf1fwvKsOPlAtPupJzUuBeICRYPq2J2SreXRkjbuSejqhl
	VSCA==
X-Received: by 10.66.66.40 with SMTP id c8mr20778516pat.66.1418329678119;
	Thu, 11 Dec 2014 12:27:58 -0800 (PST)
Received: from mswilson@gmail.com (54-240-196-186.amazon.com. [54.240.196.186])
	by mx.google.com with ESMTPSA id lg8sm2144254pab.41.2014.12.11.12.27.54
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 11 Dec 2014 12:27:56 -0800 (PST)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
	Thu, 11 Dec 2014 12:27:52 -0800
Date: Thu, 11 Dec 2014 12:27:52 -0800
From: Matt Wilson <msw@linux.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141211202747.GA6811@u109add4315675089e695.ant.amazon.com>
References: <1415286430-11155-1-git-send-email-paul.durrant@citrix.com>
	<20141106193249.GB5906@laptop.dumpdata.com>
	<545BE7DF.2090803@citrix.com>
	<20141210055958.GA28631@u109add4315675089e695.ant.amazon.com>
	<54882222.7090005@citrix.com>
	<20141211181913.GB29692@u109add4315675089e695.ant.amazon.com>
	<5489E9E7.8020608@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5489E9E7.8020608@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	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 Thu, Dec 11, 2014 at 07:00:55PM +0000, Andrew Cooper wrote:
> On 11/12/14 18:19, Matt Wilson wrote:
> > On Wed, Dec 10, 2014 at 10:36:18AM +0000, Andrew Cooper wrote:
> >> On 10/12/14 06:00, Matt Wilson wrote:
> >>> That's not strictly true. You can use the processor index in ACPI.
> >> The LAPIC objects in the MADT/APIC table?  That is still constructed
> >> with the broken LAPIC_ID = 2 * processor_id logic.
> > Have you checked on an EC2 instance (for example: C3, I2, R3)?
> 
> I meant in terms of upstream code.  I will believe you when you say that
> those instances do it differently.
> 
> My point was that the processor index is only as accurate as hvmloader
> makes it, and upstream, this relies on the broken logic.
> 
> Even if hvmloader is altered and does things differently, it is still
> bogus to draw any inference of vcpu_id from processor id.

hvmloader accurately sets the processor_id in the MADT LAPIC tables to
the correct vcpu_id value (by chance, though things would not work if
this was not so).

hvmloader/acpi/build.c:
>    for ( i = 0; i < nr_processor_objects; i++ )
>    {
>        memset(lapic, 0, sizeof(*lapic));
>        lapic->type    = ACPI_PROCESSOR_LOCAL_APIC;
>        lapic->length  = sizeof(*lapic);
>        /* Processor ID must match processor-object IDs in the DSDT. */
>-->     lapic->acpi_processor_id = i;
>        lapic->apic_id = LAPIC_ID(i);
>        lapic->flags = ((i < hvm_info->nr_vcpus) &&
>                        test_bit(i, hvm_info->vcpu_online)
>                        ? ACPI_LOCAL_APIC_ENABLED : 0);
>        lapic++;
>    }

See also hvmloader/config.h:
> #define LAPIC_ID(vcpu_id)   ((vcpu_id) * 2)

See how Keir called this "vcpu_id"?

--msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 20:39:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 20:39:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzAWF-0005XM-1s; Thu, 11 Dec 2014 20:39:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XzAWC-0005XH-Rv
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 20:39:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CB/E7-15461-CF00A845; Thu, 11 Dec 2014 20:39:24 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418330363!14695162!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 30667 invoked from network); 11 Dec 2014 20:39:23 -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; 11 Dec 2014 20:39:23 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3F1D4AC28;
	Thu, 11 Dec 2014 20:39:22 +0000 (UTC)
Date: Thu, 11 Dec 2014 21:39:21 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20141211203921.GP25677@wotan.suse.de>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<5488E552.8050207@zytor.com> <20141211010344.GO25677@wotan.suse.de>
	<5489E6D0.8020002@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5489E6D0.8020002@zytor.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: jgross@suse.com, x86@kernel.org, peterz@infradead.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, mingo@redhat.com, david.vrabel@citrix.com,
	JBeulich@suse.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be	preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 10:47:44AM -0800, H. Peter Anvin wrote:
> On 12/10/2014 05:03 PM, Luis R. Rodriguez wrote:
> > 
> > This is an issue onloy for for non*-preemptive kernels.
> > 
> > Some of Xen's hypercalls can take a long time and unfortunately for
> > *non*-preemptive kernels this can be quite a bit of an issue.
> > We've handled situations like this with cond_resched() before which will
> > push even *non*-preemptive kernels to behave as voluntarily preemptive,
> > I was not aware to what extent this was done and precedents set but
> > its pretety widespread now... this then just addresses once particular
> > case where this is also an issuefor but now in IRQ context.
> > 
> > I agree its a hack but so are all the other cond_reshed() calls then.
> > I don't think its a good idea to be spreading use of something like
> > this everywhere but after careful review and trying toa void this
> > exact code for a while I have not been able to find any other reasonable
> > alternative.
> > 
> 
> This sounds like a patch that is completely unrelated to the rest of the
> patch.

If you mean architecture and design then yes however this patch tries
to look for a resolution with the existing architecture.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 20:39:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 20:39:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzAWF-0005XM-1s; Thu, 11 Dec 2014 20:39:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XzAWC-0005XH-Rv
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 20:39:24 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	CB/E7-15461-CF00A845; Thu, 11 Dec 2014 20:39:24 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418330363!14695162!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 30667 invoked from network); 11 Dec 2014 20:39:23 -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; 11 Dec 2014 20:39:23 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3F1D4AC28;
	Thu, 11 Dec 2014 20:39:22 +0000 (UTC)
Date: Thu, 11 Dec 2014 21:39:21 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20141211203921.GP25677@wotan.suse.de>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<5488E552.8050207@zytor.com> <20141211010344.GO25677@wotan.suse.de>
	<5489E6D0.8020002@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5489E6D0.8020002@zytor.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: jgross@suse.com, x86@kernel.org, peterz@infradead.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, mingo@redhat.com, david.vrabel@citrix.com,
	JBeulich@suse.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
	be	preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 10:47:44AM -0800, H. Peter Anvin wrote:
> On 12/10/2014 05:03 PM, Luis R. Rodriguez wrote:
> > 
> > This is an issue onloy for for non*-preemptive kernels.
> > 
> > Some of Xen's hypercalls can take a long time and unfortunately for
> > *non*-preemptive kernels this can be quite a bit of an issue.
> > We've handled situations like this with cond_resched() before which will
> > push even *non*-preemptive kernels to behave as voluntarily preemptive,
> > I was not aware to what extent this was done and precedents set but
> > its pretety widespread now... this then just addresses once particular
> > case where this is also an issuefor but now in IRQ context.
> > 
> > I agree its a hack but so are all the other cond_reshed() calls then.
> > I don't think its a good idea to be spreading use of something like
> > this everywhere but after careful review and trying toa void this
> > exact code for a while I have not been able to find any other reasonable
> > alternative.
> > 
> 
> This sounds like a patch that is completely unrelated to the rest of the
> patch.

If you mean architecture and design then yes however this patch tries
to look for a resolution with the existing architecture.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 21:06:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 21:06:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzAvj-0006lv-CF; Thu, 11 Dec 2014 21:05:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XzAvi-0006lq-DR
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 21:05:46 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D7/70-25276-9270A845; Thu, 11 Dec 2014 21:05:45 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418331945!15053224!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 31119 invoked from network); 11 Dec 2014 21:05:45 -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 Dec 2014 21:05:45 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 59309AB43;
	Thu, 11 Dec 2014 21:05:44 +0000 (UTC)
Date: Thu, 11 Dec 2014 22:05:43 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141211210543.GQ25677@wotan.suse.de>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
	<54897B76.6070500@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54897B76.6070500@citrix.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Juergen Gross <jgross@suse.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Peter Zijlstra <peterz@infradead.org>, X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Ingo Molnar <mingo@redhat.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls	to
	be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 11:09:42AM +0000, David Vrabel wrote:
> On 10/12/14 23:51, Andy Lutomirski wrote:
> > On Wed, Dec 10, 2014 at 3:34 PM, Luis R. Rodriguez
> > All that being said, this is IMO a bit gross.  You've added a bunch of
> > asm that's kind of like a parallel error_exit, and the error entry and
> > exit code is hairy enough that this scares me.  Can you do this mostly
> > in C instead?  This would look a nicer if it could be:
> 
> I abandoned my initial attempt that looked like this because I thought
> it was gross too.
> 
> >     call xen_evtchn_do_upcall
> >     popq %rsp
> >     CFI_DEF_CFA_REGISTER rsp
> >     decl PER_CPU_VAR(irq_count)
> > +  call xen_end_upcall
> >     jmp error_exit
> > 
> > Where xen_end_upcall would be witten in C, nokprobes and notrace (if
> > needed) and would check pt_regs and whatever else and just call
> > schedule if needed?
> 
> Oh that's a good idea, thanks!

David, are you going to respin yourself with the goal to get this upstream?
If so I can move on with life on other matters.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 21:06:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 21:06:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzAvj-0006lv-CF; Thu, 11 Dec 2014 21:05:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1XzAvi-0006lq-DR
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 21:05:46 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D7/70-25276-9270A845; Thu, 11 Dec 2014 21:05:45 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418331945!15053224!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 31119 invoked from network); 11 Dec 2014 21:05:45 -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 Dec 2014 21:05:45 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 59309AB43;
	Thu, 11 Dec 2014 21:05:44 +0000 (UTC)
Date: Thu, 11 Dec 2014 22:05:43 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141211210543.GQ25677@wotan.suse.de>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
	<CALCETrVAQ5JRoyL=V=fj+KxwUXfOTibKQkEDcvSqJzEi2sgshA@mail.gmail.com>
	<54897B76.6070500@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54897B76.6070500@citrix.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Juergen Gross <jgross@suse.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Peter Zijlstra <peterz@infradead.org>, X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Ingo Molnar <mingo@redhat.com>, Jan Beulich <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls	to
	be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 11:09:42AM +0000, David Vrabel wrote:
> On 10/12/14 23:51, Andy Lutomirski wrote:
> > On Wed, Dec 10, 2014 at 3:34 PM, Luis R. Rodriguez
> > All that being said, this is IMO a bit gross.  You've added a bunch of
> > asm that's kind of like a parallel error_exit, and the error entry and
> > exit code is hairy enough that this scares me.  Can you do this mostly
> > in C instead?  This would look a nicer if it could be:
> 
> I abandoned my initial attempt that looked like this because I thought
> it was gross too.
> 
> >     call xen_evtchn_do_upcall
> >     popq %rsp
> >     CFI_DEF_CFA_REGISTER rsp
> >     decl PER_CPU_VAR(irq_count)
> > +  call xen_end_upcall
> >     jmp error_exit
> > 
> > Where xen_end_upcall would be witten in C, nokprobes and notrace (if
> > needed) and would check pt_regs and whatever else and just call
> > schedule if needed?
> 
> Oh that's a good idea, thanks!

David, are you going to respin yourself with the goal to get this upstream?
If so I can move on with life on other matters.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 21:06:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 21: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 1XzAwm-0006pT-Q5; Thu, 11 Dec 2014 21:06:52 +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 1XzAwl-0006p9-7q
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 21:06:51 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	AF/C5-07724-A670A845; Thu, 11 Dec 2014 21:06:50 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418332009!12757992!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 7606 invoked from network); 11 Dec 2014 21:06:49 -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; 11 Dec 2014 21:06:49 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id C5AADAC28;
	Thu, 11 Dec 2014 21:06:49 +0000 (UTC)
Date: Thu, 11 Dec 2014 22:06:49 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141211210649.GR25677@wotan.suse.de>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-2-git-send-email-mcgrof@do-not-panic.com>
	<5489AADA020000780004EFB9@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5489AADA020000780004EFB9@suse.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Juergen Gross <JGross@suse.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	peterz@infradead.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, mingo@redhat.com, david.vrabel@citrix.com,
	hpa@zytor.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 1/2] sched: add cond_resched_irq()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 06:31:54AM -0700, Jan Beulich wrote:
> >>> On 11.12.14 at 00:34, <mcgrof@do-not-panic.com> wrote:
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -4239,6 +4239,16 @@ int __sched _cond_resched(void)
> >  }
> >  EXPORT_SYMBOL(_cond_resched);
> >  
> > +int __sched cond_resched_irq(void)
> > +{
> > +	if (should_resched()) {
> > +		preempt_schedule_irq();
> > +		return 1;
> > +	}
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(cond_resched_irq);
> 
> Do you really want to export to modules a symbol like this?

You mean lets not, true and good point. Let's see if seems
if we go with Andy's suggestion we may not need this anyway.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 21:06:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 21: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 1XzAwm-0006pT-Q5; Thu, 11 Dec 2014 21:06:52 +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 1XzAwl-0006p9-7q
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 21:06:51 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	AF/C5-07724-A670A845; Thu, 11 Dec 2014 21:06:50 +0000
X-Env-Sender: lurodriguez@suse.de
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418332009!12757992!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 7606 invoked from network); 11 Dec 2014 21:06:49 -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; 11 Dec 2014 21:06:49 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id C5AADAC28;
	Thu, 11 Dec 2014 21:06:49 +0000 (UTC)
Date: Thu, 11 Dec 2014 22:06:49 +0100
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141211210649.GR25677@wotan.suse.de>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-2-git-send-email-mcgrof@do-not-panic.com>
	<5489AADA020000780004EFB9@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5489AADA020000780004EFB9@suse.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: Juergen Gross <JGross@suse.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	peterz@infradead.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, mingo@redhat.com, david.vrabel@citrix.com,
	hpa@zytor.com, masami.hiramatsu.pt@hitachi.com,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 1/2] sched: add cond_resched_irq()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 06:31:54AM -0700, Jan Beulich wrote:
> >>> On 11.12.14 at 00:34, <mcgrof@do-not-panic.com> wrote:
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -4239,6 +4239,16 @@ int __sched _cond_resched(void)
> >  }
> >  EXPORT_SYMBOL(_cond_resched);
> >  
> > +int __sched cond_resched_irq(void)
> > +{
> > +	if (should_resched()) {
> > +		preempt_schedule_irq();
> > +		return 1;
> > +	}
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(cond_resched_irq);
> 
> Do you really want to export to modules a symbol like this?

You mean lets not, true and good point. Let's see if seems
if we go with Andy's suggestion we may not need this anyway.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 21:30:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 21: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 1XzBIh-0007ke-2C; Thu, 11 Dec 2014 21:29:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XzBIf-0007kZ-Dy
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 21:29:29 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	38/43-02699-8BC0A845; Thu, 11 Dec 2014 21:29:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418333367!14465123!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31711 invoked from network); 11 Dec 2014 21:29:27 -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; 11 Dec 2014 21:29:27 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XzBIG-000PcM-VD; Thu, 11 Dec 2014 21:29:04 +0000
Date: Thu, 11 Dec 2014 22:29:04 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141211212904.GA91831@deinos.phlegethon.org>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, again. :)

As promised, I'm going to talk about more abstract design
considerations.  Thi will be a lot less concrete than in the other
email, and about a larger range of things.  Some of of them may not be
really desirable - or even possible.

[ TL;DR: read the other reply with the practical suggestions in it :) ]

I'm talking from the point of view of a hypervisor maintainer, looking
at introducing this new XenGT component and thinking about what
security properties we would like the _system_ to have once XenGT is
introduced.  I'm going to lay out a series of broadly increasing
levels of security goodness and talk about what we'd need to do to get
there.

For the purposes of this discussion, Xen does not _trust_ XenGT.  By
that I mean that Xen can't rely on the correctness/integrity of XenGT
itself to maintain system security.  Now, we can decide that for some
properties we _will_ choose to trust XenGT, but the default is to
assume that XenGT could be compromised or buggy.  (This is not
intended as a slur on XenGT, btw -- this is how we reason about device
driver domains, qemu-dm and other components.  There will be bugs in
any component, and we're designing the system to minimise the effect
of those bugs.)

OK.  Properties we would like to have:

LEVEL 0: Protect Xen itself from XenGT
--------------------------------------

Bugs in XenGT should not be able to crash he host, and a compromised
XenGT should not be able to take over the hypervisor

We're not there in the current design, purely because XenGT has to be
in dom0 (so it can trivially DoS Xen by rebooting the host).

But it doesn't seem too hard: as soon as we can run XenGT in a driver
domain, and with IOMMU tables that restrict the GPU from writing to Xen's
datastructures, we'll have this property.

[BTW, this whole discussion assumes that the GPU has no 'back door'
 access to issue DMA that is not translated by the IOMMU.  I have heard
 rumours in the past that such things exist. :) If the GPU can issue
 untranslated DMA, then whetever controls it can take over the entire
 system, and so we can't make _any_ security guarantees about it.]


LEVEL 1: Isolate XenGT's clients from other VMs
-----------------------------------------------

In other words we partition the machine into VMs XenGT can touch
(i.e. its clients) and those it can't.  Then a malicious client that
compromises XenGT only gains access to other VMs that share a GPU with
it.  That means we can deploy XenGT for some VMs without increasing
the risk to other tenants.

Again we're not there yet, but I think the design I was talking about
in my other email would do it: if XenGT must map all the memory it
wants to let the GPU DMA to, and Xen's policy is to deny mappings for
non-client-vm memory, then VMs that aren't using XenGT are protected.


LEVEL 2: Isolate XenGT's clients from each other
------------------------------------------------

This is trickier, as you pointed out.  We could:

a) Decide that we will trust XenGT to provide this property.  After
   all, that's its main purpose!  This is how we treat other shared
   backends: if a NIC device driver domain is compromised, the
   attacker controls the network traffic for all its frontends.
   OTOH, we don't trust qemu in that way -- instead we use stub domains 
   and IS_PRIV_FOR to enforce isolation.

b) Move all of XenGT into Xen.  This is just defining the problem away
   and would probably do more harm than good - after all, keeping it
   separate has other advantages.

c) Use privilege separation: break XenGT into parts, isolated from each
   other, with the principle of least privilege applied to them.  E.g.
   - GPU emulation could be in a per-client component that doesn't
     share state with the other clients' emulators;
   - Shadowing GTTs and auditing GPU commands could move into Xen,
     with a clean interface to the emulation parts.
   That way, even if a client VM can exploit a bug in the emulator,
   it can't affect other clients because it can't see their emulator
   state, and it can't bypass the safety rules because they're
   enforced by Xen.

   When I talked about privilege separation before I was suggesting
   something like this, but without moving anything into Xen -- e.g.
   the device-emulation code for each client could be in a per-client,
   non-root process.  The code that audits and issues commands to the
   GPU would be in a separate process, which is allowed to make
   hypercalls, and which does not trust the emulator processes.
   My apologies if you're already doing this -- I know XenGT has some
   components in a kernel driver and some elsewhere but I haven't
   looked at the details.


LEVEL 3: Isolate XenGT's clients from XenGT itself
--------------------------------------------------

XenGT should not be able to access parts of its client VMs that they
have not given it permission to.  E.g. XenGT should not be able to
read a client VM's crypto keys unless it displays them on the
framebuffer or uses the GPU to accelerate crypto.

Unlike level 2, device driver domains _do_ have this property: this is
what the grant tables are used for.  A compromised NIC driver domain
can MITM the frontend guest but it can't read any memory in the guest
other than network buffers.

Again there are a few approaches, like:

a) Declare that we don't care (i.e. that we will trust XenGT for this
   property too).  In a way it's no worse than trusting the firmware
   on a dedicated pass-though GPU.  But on the other hand the client
   VM is sharing that firmware with some other VMs... :(

b) Make the GPU driver in the client use grant tables for all RAM that
   it gives to the GPU.  Probably not practical!

c) Move just the code that builds the GTTs into Xen.  That way
   Xen would guarantee that the GPU never accessed memory it wasn't
   allowed to.

I'm sure there are other ideas too.


Conclusion
----------

That's enough rambling from me -- time to come back down to earth.
While I think it's useful to think about all these things, we don't
want to get carried away. :)  And as I said, for some things we can
decide to trust XenGT to provide them, as long as we're clear about
what that means.

I think that a reasonable minimum standard to expect is to enforce
levels 0 and 1 in Xen, and trust XenGT for levels 2 and 3.  And I
think we can do that without needing any huge engineering effort;
as I said, I think that's covered in my earlier reply.

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 Dec 11 21:30:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 21: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 1XzBIh-0007ke-2C; Thu, 11 Dec 2014 21:29:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1XzBIf-0007kZ-Dy
	for Xen-devel@lists.xen.org; Thu, 11 Dec 2014 21:29:29 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	38/43-02699-8BC0A845; Thu, 11 Dec 2014 21:29:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418333367!14465123!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31711 invoked from network); 11 Dec 2014 21:29:27 -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; 11 Dec 2014 21:29:27 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1XzBIG-000PcM-VD; Thu, 11 Dec 2014 21:29:04 +0000
Date: Thu, 11 Dec 2014 22:29:04 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141211212904.GA91831@deinos.phlegethon.org>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, again. :)

As promised, I'm going to talk about more abstract design
considerations.  Thi will be a lot less concrete than in the other
email, and about a larger range of things.  Some of of them may not be
really desirable - or even possible.

[ TL;DR: read the other reply with the practical suggestions in it :) ]

I'm talking from the point of view of a hypervisor maintainer, looking
at introducing this new XenGT component and thinking about what
security properties we would like the _system_ to have once XenGT is
introduced.  I'm going to lay out a series of broadly increasing
levels of security goodness and talk about what we'd need to do to get
there.

For the purposes of this discussion, Xen does not _trust_ XenGT.  By
that I mean that Xen can't rely on the correctness/integrity of XenGT
itself to maintain system security.  Now, we can decide that for some
properties we _will_ choose to trust XenGT, but the default is to
assume that XenGT could be compromised or buggy.  (This is not
intended as a slur on XenGT, btw -- this is how we reason about device
driver domains, qemu-dm and other components.  There will be bugs in
any component, and we're designing the system to minimise the effect
of those bugs.)

OK.  Properties we would like to have:

LEVEL 0: Protect Xen itself from XenGT
--------------------------------------

Bugs in XenGT should not be able to crash he host, and a compromised
XenGT should not be able to take over the hypervisor

We're not there in the current design, purely because XenGT has to be
in dom0 (so it can trivially DoS Xen by rebooting the host).

But it doesn't seem too hard: as soon as we can run XenGT in a driver
domain, and with IOMMU tables that restrict the GPU from writing to Xen's
datastructures, we'll have this property.

[BTW, this whole discussion assumes that the GPU has no 'back door'
 access to issue DMA that is not translated by the IOMMU.  I have heard
 rumours in the past that such things exist. :) If the GPU can issue
 untranslated DMA, then whetever controls it can take over the entire
 system, and so we can't make _any_ security guarantees about it.]


LEVEL 1: Isolate XenGT's clients from other VMs
-----------------------------------------------

In other words we partition the machine into VMs XenGT can touch
(i.e. its clients) and those it can't.  Then a malicious client that
compromises XenGT only gains access to other VMs that share a GPU with
it.  That means we can deploy XenGT for some VMs without increasing
the risk to other tenants.

Again we're not there yet, but I think the design I was talking about
in my other email would do it: if XenGT must map all the memory it
wants to let the GPU DMA to, and Xen's policy is to deny mappings for
non-client-vm memory, then VMs that aren't using XenGT are protected.


LEVEL 2: Isolate XenGT's clients from each other
------------------------------------------------

This is trickier, as you pointed out.  We could:

a) Decide that we will trust XenGT to provide this property.  After
   all, that's its main purpose!  This is how we treat other shared
   backends: if a NIC device driver domain is compromised, the
   attacker controls the network traffic for all its frontends.
   OTOH, we don't trust qemu in that way -- instead we use stub domains 
   and IS_PRIV_FOR to enforce isolation.

b) Move all of XenGT into Xen.  This is just defining the problem away
   and would probably do more harm than good - after all, keeping it
   separate has other advantages.

c) Use privilege separation: break XenGT into parts, isolated from each
   other, with the principle of least privilege applied to them.  E.g.
   - GPU emulation could be in a per-client component that doesn't
     share state with the other clients' emulators;
   - Shadowing GTTs and auditing GPU commands could move into Xen,
     with a clean interface to the emulation parts.
   That way, even if a client VM can exploit a bug in the emulator,
   it can't affect other clients because it can't see their emulator
   state, and it can't bypass the safety rules because they're
   enforced by Xen.

   When I talked about privilege separation before I was suggesting
   something like this, but without moving anything into Xen -- e.g.
   the device-emulation code for each client could be in a per-client,
   non-root process.  The code that audits and issues commands to the
   GPU would be in a separate process, which is allowed to make
   hypercalls, and which does not trust the emulator processes.
   My apologies if you're already doing this -- I know XenGT has some
   components in a kernel driver and some elsewhere but I haven't
   looked at the details.


LEVEL 3: Isolate XenGT's clients from XenGT itself
--------------------------------------------------

XenGT should not be able to access parts of its client VMs that they
have not given it permission to.  E.g. XenGT should not be able to
read a client VM's crypto keys unless it displays them on the
framebuffer or uses the GPU to accelerate crypto.

Unlike level 2, device driver domains _do_ have this property: this is
what the grant tables are used for.  A compromised NIC driver domain
can MITM the frontend guest but it can't read any memory in the guest
other than network buffers.

Again there are a few approaches, like:

a) Declare that we don't care (i.e. that we will trust XenGT for this
   property too).  In a way it's no worse than trusting the firmware
   on a dedicated pass-though GPU.  But on the other hand the client
   VM is sharing that firmware with some other VMs... :(

b) Make the GPU driver in the client use grant tables for all RAM that
   it gives to the GPU.  Probably not practical!

c) Move just the code that builds the GTTs into Xen.  That way
   Xen would guarantee that the GPU never accessed memory it wasn't
   allowed to.

I'm sure there are other ideas too.


Conclusion
----------

That's enough rambling from me -- time to come back down to earth.
While I think it's useful to think about all these things, we don't
want to get carried away. :)  And as I said, for some things we can
decide to trust XenGT to provide them, as long as we're clear about
what that means.

I think that a reasonable minimum standard to expect is to enforce
levels 0 and 1 in Xen, and trust XenGT for levels 2 and 3.  And I
think we can do that without needing any huge engineering effort;
as I said, I think that's covered in my earlier reply.

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 Dec 11 22:15:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 22:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzC0z-0001GX-5i; Thu, 11 Dec 2014 22:15:17 +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 1XzC0x-0001GS-62
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 22:15:15 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	CB/C9-22737-2771A845; Thu, 11 Dec 2014 22:15:14 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418336113!8784827!1
X-Originating-IP: [209.85.213.171]
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 8009 invoked from network); 11 Dec 2014 22:15:13 -0000
Received: from mail-ig0-f171.google.com (HELO mail-ig0-f171.google.com)
	(209.85.213.171)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 22:15:13 -0000
Received: by mail-ig0-f171.google.com with SMTP id z20so447647igj.16
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 14:15:12 -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=vJ7mr0EGacI6nxHDnodA6+5ToQVx6QIcndS99qpf0e8=;
	b=qxd5+bOn+zjyboEy9IQ1Rm1gBouktQ13xtFWhNa9BbRuha9dRLGaSSGXpjeyVcGYP4
	9XprKGO7rxZH41aWOfy23CT7YTs0OAFKP+DbSBD+HRcjj3+aeekQzjCnypCidrd4WTmq
	qxTq009xXRAC52B0fLKw27EZ0M9YzGkmnnK1du2C/qgA+7lwejt0tG+Aw9kN3U5Kvo3+
	LTPDjDc4GjvWn39tE/bb1RZW26TgO0ihPqexQxlH7pAErrk79poLNU0lX2Cj230AMG12
	AXtVDomffVDtpKwuaxBFM1dU3oGK+8qa6X7EV4VmY7JQD27ABfzV4W2a0spdSqd1M/BA
	zOzA==
MIME-Version: 1.0
X-Received: by 10.43.44.201 with SMTP id uh9mr13337719icb.51.1418336112691;
	Thu, 11 Dec 2014 14:15:12 -0800 (PST)
Received: by 10.64.121.194 with HTTP; Thu, 11 Dec 2014 14:15:12 -0800 (PST)
Date: Fri, 12 Dec 2014 03:45:12 +0530
Message-ID: <CALicx6uzreJuQfKTw4O7VKp-E9Orhmf8u7=NoO6J75xARRYKAg@mail.gmail.com>
From: Vijay Kilari <vijay.kilari@gmail.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Julien Grall <julien.grall@linaro.org>
Subject: [Xen-devel] Installing xen tools on Distros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

    Apart from OpenSUSE, I am looking for booting Dom0 with other distros like
Redhat & Ubuntu. If so what is the procedure for installing xen tools on these
distros?

Regards
Vijay

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 22:15:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 22:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzC0z-0001GX-5i; Thu, 11 Dec 2014 22:15:17 +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 1XzC0x-0001GS-62
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 22:15:15 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	CB/C9-22737-2771A845; Thu, 11 Dec 2014 22:15:14 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418336113!8784827!1
X-Originating-IP: [209.85.213.171]
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 8009 invoked from network); 11 Dec 2014 22:15:13 -0000
Received: from mail-ig0-f171.google.com (HELO mail-ig0-f171.google.com)
	(209.85.213.171)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 22:15:13 -0000
Received: by mail-ig0-f171.google.com with SMTP id z20so447647igj.16
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 14:15:12 -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=vJ7mr0EGacI6nxHDnodA6+5ToQVx6QIcndS99qpf0e8=;
	b=qxd5+bOn+zjyboEy9IQ1Rm1gBouktQ13xtFWhNa9BbRuha9dRLGaSSGXpjeyVcGYP4
	9XprKGO7rxZH41aWOfy23CT7YTs0OAFKP+DbSBD+HRcjj3+aeekQzjCnypCidrd4WTmq
	qxTq009xXRAC52B0fLKw27EZ0M9YzGkmnnK1du2C/qgA+7lwejt0tG+Aw9kN3U5Kvo3+
	LTPDjDc4GjvWn39tE/bb1RZW26TgO0ihPqexQxlH7pAErrk79poLNU0lX2Cj230AMG12
	AXtVDomffVDtpKwuaxBFM1dU3oGK+8qa6X7EV4VmY7JQD27ABfzV4W2a0spdSqd1M/BA
	zOzA==
MIME-Version: 1.0
X-Received: by 10.43.44.201 with SMTP id uh9mr13337719icb.51.1418336112691;
	Thu, 11 Dec 2014 14:15:12 -0800 (PST)
Received: by 10.64.121.194 with HTTP; Thu, 11 Dec 2014 14:15:12 -0800 (PST)
Date: Fri, 12 Dec 2014 03:45:12 +0530
Message-ID: <CALicx6uzreJuQfKTw4O7VKp-E9Orhmf8u7=NoO6J75xARRYKAg@mail.gmail.com>
From: Vijay Kilari <vijay.kilari@gmail.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Julien Grall <julien.grall@linaro.org>
Subject: [Xen-devel] Installing xen tools on Distros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

    Apart from OpenSUSE, I am looking for booting Dom0 with other distros like
Redhat & Ubuntu. If so what is the procedure for installing xen tools on these
distros?

Regards
Vijay

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 22:59:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 22:59:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzChO-0002w8-UW; Thu, 11 Dec 2014 22:59: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 1XzChM-0002w3-SS
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 22:59:05 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	45/EF-01660-8B12A845; Thu, 11 Dec 2014 22:59:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418338740!10030338!1
X-Originating-IP: [66.165.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 13539 invoked from network); 11 Dec 2014 22:59:03 -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 Dec 2014 22:59:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,560,1413244800"; d="scan'208";a="203223207"
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.210.2; Thu, 11 Dec 2014 17:58: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 1XzChG-00019X-AJ;
	Thu, 11 Dec 2014 22:58:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzChF-0001Fv-7n;
	Thu, 11 Dec 2014 22:58:57 +0000
Date: Thu, 11 Dec 2014 22:58:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32231-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] 32231: 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 32231 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32231/

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 32164

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-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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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                  de6313ab40a2858693609338db935cb689380361
baseline version:
 xen                  8029dc43f4b232968168ca5bbd0ef47589243140

------------------------------------------------------------
People who touched revisions under test:
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@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                                         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


Pushing revision :

+ branch=xen-4.4-testing
+ revision=de6313ab40a2858693609338db935cb689380361
+ . 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 de6313ab40a2858693609338db935cb689380361
+ branch=xen-4.4-testing
+ revision=de6313ab40a2858693609338db935cb689380361
+ . 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 de6313ab40a2858693609338db935cb689380361:stable-4.4
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   8029dc4..de6313a  de6313ab40a2858693609338db935cb689380361 -> 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 Thu Dec 11 22:59:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 22:59:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzChO-0002w8-UW; Thu, 11 Dec 2014 22:59: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 1XzChM-0002w3-SS
	for xen-devel@lists.xensource.com; Thu, 11 Dec 2014 22:59:05 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	45/EF-01660-8B12A845; Thu, 11 Dec 2014 22:59:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418338740!10030338!1
X-Originating-IP: [66.165.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 13539 invoked from network); 11 Dec 2014 22:59:03 -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 Dec 2014 22:59:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,560,1413244800"; d="scan'208";a="203223207"
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.210.2; Thu, 11 Dec 2014 17:58: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 1XzChG-00019X-AJ;
	Thu, 11 Dec 2014 22:58:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzChF-0001Fv-7n;
	Thu, 11 Dec 2014 22:58:57 +0000
Date: Thu, 11 Dec 2014 22:58:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32231-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] 32231: 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 32231 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32231/

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 32164

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-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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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                  de6313ab40a2858693609338db935cb689380361
baseline version:
 xen                  8029dc43f4b232968168ca5bbd0ef47589243140

------------------------------------------------------------
People who touched revisions under test:
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@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                                         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


Pushing revision :

+ branch=xen-4.4-testing
+ revision=de6313ab40a2858693609338db935cb689380361
+ . 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 de6313ab40a2858693609338db935cb689380361
+ branch=xen-4.4-testing
+ revision=de6313ab40a2858693609338db935cb689380361
+ . 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 de6313ab40a2858693609338db935cb689380361:stable-4.4
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   8029dc4..de6313a  de6313ab40a2858693609338db935cb689380361 -> 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 Thu Dec 11 23:17:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 23: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 1XzCz7-0003oz-Qg; Thu, 11 Dec 2014 23:17:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mswilson@gmail.com>) id 1XzCz7-0003ou-42
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 23:17:25 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	FE/49-22777-4062A845; Thu, 11 Dec 2014 23:17:24 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418339842!5327903!1
X-Originating-IP: [209.85.220.41]
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 29087 invoked from network); 11 Dec 2014 23:17:23 -0000
Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com)
	(209.85.220.41)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 23:17:23 -0000
Received: by mail-pa0-f41.google.com with SMTP id rd3so6029014pab.0
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 15:17:22 -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=94Aav/XwtbaDZPUUIy8DfxeDJ4YZnuLoFlXtOfhu08M=;
	b=X0IjeUeaiiErc71QdmVXKy58Z0hTADhfhpA1p9gZ7xDoEF+tR2W9IhpwitBh18eXVE
	39SFrXR4iB1rkD3AGXD1UQd0iEJPUJ00q/Ucyh9cY8jvENWATXV/+LMk+rqYqBPSCJNp
	7Ezy38OeaJ0ay77cYTQhvUwa35Nr1c7COkxQI8UOC8T67JC2LAjcx4ThuQvtUPb9hAoj
	suKsnzWpLRwdZY76GG7B9Ds0dctOQ8TOmbyKJcWY5Bwof/slkmOlM+r9kjygyA4Knn4U
	njNzDIYZkOZsQ/o3dI1cZfJAboClt7vbWvTgEBgL1dQ0OekoOh6gIND9FLkesiGHQLbD
	WLcw==
X-Received: by 10.68.196.231 with SMTP id ip7mr21686022pbc.94.1418339842128;
	Thu, 11 Dec 2014 15:17:22 -0800 (PST)
Received: from mswilson@gmail.com (54-240-196-186.amazon.com. [54.240.196.186])
	by mx.google.com with ESMTPSA id fr1sm2314432pbb.32.2014.12.11.15.17.18
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 11 Dec 2014 15:17:20 -0800 (PST)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
	Thu, 11 Dec 2014 15:17:18 -0800
Date: Thu, 11 Dec 2014 15:17:18 -0800
From: Matt Wilson <msw@linux.com>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20141211213609.GA11251@u109add4315675089e695.ant.amazon.com>
References: <1415287584-11322-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415287584-11322-1-git-send-email-paul.durrant@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [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

On Thu, Nov 06, 2014 at 03:26:24PM +0000, 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.

One more tangent on this, since this is partially considered in a
Windows context. Why not use the existing Viridian virtual processor
index MSR for this, since that would work on Xen today.

xen/arch/x86/hvm/viridian.c:
> #define VIRIDIAN_MSR_VP_INDEX                   0x40000002
> ...
>     case VIRIDIAN_MSR_VP_INDEX:
>        perfc_incr(mshv_rdmsr_vp_index);
>        *val = v->vcpu_id;
>        break;

--msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 23:17:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 23: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 1XzCz7-0003oz-Qg; Thu, 11 Dec 2014 23:17:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mswilson@gmail.com>) id 1XzCz7-0003ou-42
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 23:17:25 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	FE/49-22777-4062A845; Thu, 11 Dec 2014 23:17:24 +0000
X-Env-Sender: mswilson@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418339842!5327903!1
X-Originating-IP: [209.85.220.41]
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 29087 invoked from network); 11 Dec 2014 23:17:23 -0000
Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com)
	(209.85.220.41)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Dec 2014 23:17:23 -0000
Received: by mail-pa0-f41.google.com with SMTP id rd3so6029014pab.0
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 15:17:22 -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=94Aav/XwtbaDZPUUIy8DfxeDJ4YZnuLoFlXtOfhu08M=;
	b=X0IjeUeaiiErc71QdmVXKy58Z0hTADhfhpA1p9gZ7xDoEF+tR2W9IhpwitBh18eXVE
	39SFrXR4iB1rkD3AGXD1UQd0iEJPUJ00q/Ucyh9cY8jvENWATXV/+LMk+rqYqBPSCJNp
	7Ezy38OeaJ0ay77cYTQhvUwa35Nr1c7COkxQI8UOC8T67JC2LAjcx4ThuQvtUPb9hAoj
	suKsnzWpLRwdZY76GG7B9Ds0dctOQ8TOmbyKJcWY5Bwof/slkmOlM+r9kjygyA4Knn4U
	njNzDIYZkOZsQ/o3dI1cZfJAboClt7vbWvTgEBgL1dQ0OekoOh6gIND9FLkesiGHQLbD
	WLcw==
X-Received: by 10.68.196.231 with SMTP id ip7mr21686022pbc.94.1418339842128;
	Thu, 11 Dec 2014 15:17:22 -0800 (PST)
Received: from mswilson@gmail.com (54-240-196-186.amazon.com. [54.240.196.186])
	by mx.google.com with ESMTPSA id fr1sm2314432pbb.32.2014.12.11.15.17.18
	for <multiple recipients>
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 11 Dec 2014 15:17:20 -0800 (PST)
Received: by mswilson@gmail.com (sSMTP sendmail emulation);
	Thu, 11 Dec 2014 15:17:18 -0800
Date: Thu, 11 Dec 2014 15:17:18 -0800
From: Matt Wilson <msw@linux.com>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20141211213609.GA11251@u109add4315675089e695.ant.amazon.com>
References: <1415287584-11322-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1415287584-11322-1-git-send-email-paul.durrant@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [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

On Thu, Nov 06, 2014 at 03:26:24PM +0000, 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.

One more tangent on this, since this is partially considered in a
Windows context. Why not use the existing Viridian virtual processor
index MSR for this, since that would work on Xen today.

xen/arch/x86/hvm/viridian.c:
> #define VIRIDIAN_MSR_VP_INDEX                   0x40000002
> ...
>     case VIRIDIAN_MSR_VP_INDEX:
>        perfc_incr(mshv_rdmsr_vp_index);
>        *val = v->vcpu_id;
>        break;

--msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 23:20:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 23:20:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzD2M-0003vb-E0; Thu, 11 Dec 2014 23:20:46 +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 1XzD2K-0003vT-NS
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 23:20:44 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	6B/42-25547-BC62A845; Thu, 11 Dec 2014 23:20:43 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418340043!12742773!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 16537 invoked from network); 11 Dec 2014 23:20:43 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 23:20:43 -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 sBBNKPvx020407;
	Thu, 11 Dec 2014 23:20:29 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 sBBNKKSg030225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Dec 2014 23:20:20 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 sBBNKKfg022064;
	Thu, 11 Dec 2014 23:20:20 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sBBNKJVD022060; Thu, 11 Dec 2014 23:20:19 GMT
Date: Thu, 11 Dec 2014 23:20:19 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Vijay Kilari <vijay.kilari@gmail.com>
In-Reply-To: <CALicx6uzreJuQfKTw4O7VKp-E9Orhmf8u7=NoO6J75xARRYKAg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1412112318270.23332@procyon.dur.ac.uk>
References: <CALicx6uzreJuQfKTw4O7VKp-E9Orhmf8u7=NoO6J75xARRYKAg@mail.gmail.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: sBBNKPvx020407
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, 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] Installing xen tools on Distros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 11 Dec 2014, Vijay Kilari wrote:

>    Apart from OpenSUSE, I am looking for booting Dom0 with other distros like
> Redhat & Ubuntu. If so what is the procedure for installing xen tools on these
> distros?

Check out the wiki. A good place to start is 
http://wiki.xenproject.org/wiki/Getting_Started

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 11 23:20:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Dec 2014 23:20:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzD2M-0003vb-E0; Thu, 11 Dec 2014 23:20:46 +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 1XzD2K-0003vT-NS
	for xen-devel@lists.xen.org; Thu, 11 Dec 2014 23:20:44 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	6B/42-25547-BC62A845; Thu, 11 Dec 2014 23:20:43 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418340043!12742773!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 16537 invoked from network); 11 Dec 2014 23:20:43 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Dec 2014 23:20:43 -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 sBBNKPvx020407;
	Thu, 11 Dec 2014 23:20:29 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 sBBNKKSg030225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Dec 2014 23:20:20 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 sBBNKKfg022064;
	Thu, 11 Dec 2014 23:20:20 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sBBNKJVD022060; Thu, 11 Dec 2014 23:20:19 GMT
Date: Thu, 11 Dec 2014 23:20:19 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Vijay Kilari <vijay.kilari@gmail.com>
In-Reply-To: <CALicx6uzreJuQfKTw4O7VKp-E9Orhmf8u7=NoO6J75xARRYKAg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1412112318270.23332@procyon.dur.ac.uk>
References: <CALicx6uzreJuQfKTw4O7VKp-E9Orhmf8u7=NoO6J75xARRYKAg@mail.gmail.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: sBBNKPvx020407
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, 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] Installing xen tools on Distros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 11 Dec 2014, Vijay Kilari wrote:

>    Apart from OpenSUSE, I am looking for booting Dom0 with other distros like
> Redhat & Ubuntu. If so what is the procedure for installing xen tools on these
> distros?

Check out the wiki. A good place to start is 
http://wiki.xenproject.org/wiki/Getting_Started

 	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 Dec 12 00:22:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 00:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzDzv-0006pw-8Z; Fri, 12 Dec 2014 00:22: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 1XzDzt-0006mJ-At
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 00:22:17 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	75/2E-02712-8353A845; Fri, 12 Dec 2014 00:22:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418343734!14566705!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4384 invoked from network); 12 Dec 2014 00:22:15 -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; 12 Dec 2014 00:22:15 -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 sBC0LsaB026225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Dec 2014 00:21: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
	sBC0LruX018933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 12 Dec 2014 00:21:54 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
	sBC0LrFW003601; Fri, 12 Dec 2014 00:21:53 GMT
Received: from android-f2c4df591cc093fb.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Dec 2014 16:21:51 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <20141211192058.GA5709@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
	<alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
	<20141211120424.GA25950@aepfle.de>
	<20141211191527.GB18992@laptop.dumpdata.com>
	<20141211192058.GA5709@aepfle.de>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 11 Dec 2014 19:21:42 -0500
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <36640B41-DD56-4C78-B096-30634FA51140@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xen.org, M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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 December 11, 2014 2:20:59 PM EST, Olaf Hering <olaf@aepfle.de> wrote:
>On Thu, Dec 11, Konrad Rzeszutek Wilk wrote:
>
>> I wonder if we can detect the context during build-time (an autoconf
>function
>> that checks whether the build is done for Fedora?)
>> But what if the version of Fedora is different and the object is
>called
>> something else?
>
>Exactly. The build host is not the host where the code runs. It just
>happens to be the same in your case.

The file I pasted was the one from the SOURCES directory. Since the end result is an RPM and it works without issues I would surmise the context is OK - for this version  of Fedora. But maybe older ones had this?
>
>This and the fact that xenstored cant (appearently) be launched via a
>wrapper script makes we wonder how to deal with SELinux...
>
>Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 00:22:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 00:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzDzv-0006pw-8Z; Fri, 12 Dec 2014 00:22: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 1XzDzt-0006mJ-At
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 00:22:17 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	75/2E-02712-8353A845; Fri, 12 Dec 2014 00:22:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418343734!14566705!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4384 invoked from network); 12 Dec 2014 00:22:15 -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; 12 Dec 2014 00:22:15 -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 sBC0LsaB026225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Dec 2014 00:21: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
	sBC0LruX018933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 12 Dec 2014 00:21:54 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
	sBC0LrFW003601; Fri, 12 Dec 2014 00:21:53 GMT
Received: from android-f2c4df591cc093fb.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Dec 2014 16:21:51 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <20141211192058.GA5709@aepfle.de>
References: <1418033889-11616-1-git-send-email-olaf@aepfle.de>
	<20141210204226.GA13076@laptop.dumpdata.com>
	<20141211084302.GA16507@aepfle.de>
	<alpine.DEB.2.00.1412111149080.30133@procyon.dur.ac.uk>
	<20141211120424.GA25950@aepfle.de>
	<20141211191527.GB18992@laptop.dumpdata.com>
	<20141211192058.GA5709@aepfle.de>
MIME-Version: 1.0
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 11 Dec 2014 19:21:42 -0500
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <36640B41-DD56-4C78-B096-30634FA51140@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xen.org, M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] [PATCH 0/4 v2] tools/hotplug: systemd changes 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 December 11, 2014 2:20:59 PM EST, Olaf Hering <olaf@aepfle.de> wrote:
>On Thu, Dec 11, Konrad Rzeszutek Wilk wrote:
>
>> I wonder if we can detect the context during build-time (an autoconf
>function
>> that checks whether the build is done for Fedora?)
>> But what if the version of Fedora is different and the object is
>called
>> something else?
>
>Exactly. The build host is not the host where the code runs. It just
>happens to be the same in your case.

The file I pasted was the one from the SOURCES directory. Since the end result is an RPM and it works without issues I would surmise the context is OK - for this version  of Fedora. But maybe older ones had this?
>
>This and the fact that xenstored cant (appearently) be launched via a
>wrapper script makes we wonder how to deal with SELinux...
>
>Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 00:25:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 00: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 1XzE32-00077F-Ru; Fri, 12 Dec 2014 00:25:32 +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 1XzE31-00077A-GF
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 00:25:31 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	28/56-02954-AF53A845; Fri, 12 Dec 2014 00:25:30 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418343928!14580940!1
X-Originating-IP: [209.85.216.181]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17740 invoked from network); 12 Dec 2014 00:25:29 -0000
Received: from mail-qc0-f181.google.com (HELO mail-qc0-f181.google.com)
	(209.85.216.181)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 00:25:29 -0000
Received: by mail-qc0-f181.google.com with SMTP id m20so4752852qcx.40
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 16:25: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=uHMTodTeouV2xUBXdXsHYfLA/SdBxStBMpOd/P04OeM=;
	b=qBkzgOsL8rLXy0zxFNNZC1qPH8SecOWqxloyQWJWdMNL2SR2tOtBw+oqUTOLWU0zZe
	MgsWXsRBhZMsmENxdtf/4jqYr07qCpIVvmjNYN2rMJJv6rFCmHK78jieKDhYFU+aC59/
	7Po8mi+/6ODecDazaIaOGpSl2VwWBFP4wi6RpKqdHFIPkOWAyy+MFU4xuRUItYMJiuSe
	Rx5tT9Ld1Lne5sOYpObgExhMW0yGk1+XevfbeB1ftJxpZYp7Ci+IBCtsIOGCYgToPEv6
	WPkZakTtPN82QBv08p4M+YdHzzTo+GIBf5WyA0RKoaC4Xhp3w0NPK3H8JKSa0ZNxW5Oo
	Vseg==
MIME-Version: 1.0
X-Received: by 10.224.80.6 with SMTP id r6mr25174625qak.5.1418343928147; Thu,
	11 Dec 2014 16:25:28 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Thu, 11 Dec 2014 16:25:28 -0800 (PST)
In-Reply-To: <54897098.3070009@linaro.org>
References: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>
	<54897098.3070009@linaro.org>
Date: Thu, 11 Dec 2014 16:25:28 -0800
Message-ID: <CAAiw7Jk2xmpWo-Dv8KLb4sSoU4PhCuj-iDeVPJU7xHoR+Wsxag@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Julien Grall <julien.grall@linaro.org>, agraf@suse.de
Cc: manish.jaggi@caviumnetworks.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Timed out waiting for device dev-hvc0.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 11 December 2014 at 02:23, Julien Grall <julien.grall@linaro.org> wrote:
> Hello,
>
>
> On 11/12/2014 02:27, manish jaggi wrote:
>>
>> I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)
>>
>> ...
>>
>> [  OK  ] Reached target Host and Network Name Lookups.
>> [  OK  ] Started OpenSSH Daemon.
>> [ TIME ] Timed out waiting for device dev-hvc0.device.
>> [DEPEND] Dependency failed for Serial Getty on hvc0.
>> [  OK  ] Reached target Login Prompts.
>>
>>
>> Any Idea? what could be wrong here
>
>
> Please provide the full boot log. With only those 5 lines we can only guess
> what could be the issue.
>
Added
> Maybe the DOM0 kernel didn't detect that it's running on Xen or you forgot
> to enable CONFIG_XEN_HVC in your config.
That is already enabled.
FYI with other rootfs I dont see any problem.
>
> Regards,
>
> --
> Julien Grall

[... Std linux boot log .. ]
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sda2): using internal journal
EXT3-fs (sda2): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) on device 8:2.
devtmpfs: mounted
Freeing unused kernel memory: 236K (ffffffc000789000 - ffffffc0007c4000)
random: systemd urandom read with 4 bits of entropy available
systemd[1]: systemd 210 running in system mode. (+PAM -LIBWRAP +AUDIT
+SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP
+APPARMOR)
systemd[1]: Detected virtualization 'xen'.
systemd[1]: Detected architecture 'arm64'.

Welcome to openSUSE 13.2 (Harlequin) (aarch64)!

systemd[1]: Failed to insert module 'autofs4'
systemd[1]: Failed to insert module 'ipv6'
systemd[1]: Set hostname to <linux>.
systemd[1]: Cannot add dependency job for unit
display-manager.service, ignoring: Unit display-manager.service failed
to load: No such file or directory.
systemd[1]: Expecting device dev-hvc0.device...
         Expecting device dev-hvc0.device...
systemd[1]: Starting Remote File Systems (Pre).
[  OK  ] Reached target Remote File Systems (Pre).
systemd[1]: Reached target Remote File Systems (Pre).
systemd[1]: Starting Remote File Systems.
[  OK  ] Reached target Remote File Systems.
systemd[1]: Reached target Remote File Systems.
systemd[1]: Set up automount Arbitrary Executable File Formats File
System Automount Point.
systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
systemd[1]: Starting Paths.
[  OK  ] Reached target Paths.
systemd[1]: Reached target Paths.
systemd[1]: Starting Swap.
[  OK  ] Reached target Swap.
systemd[1]: Reached target Swap.
systemd[1]: Starting Root Slice.
[  OK  ] Created slice Root Slice.
systemd[1]: Created slice Root Slice.
systemd[1]: Starting udev Kernel Socket.
[  OK  ] Listening on udev Kernel Socket.
systemd[1]: Listening on udev Kernel Socket.
systemd[1]: Starting Journal Socket.
[  OK  ] Listening on Journal Socket.
systemd[1]: Listening on Journal Socket.
systemd[1]: Starting LVM2 metadata daemon socket.
[  OK  ] Listening on LVM2 metadata daemon socket.
systemd[1]: Listening on LVM2 metadata daemon socket.
systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
[  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
systemd[1]: Starting Delayed Shutdown Socket.
[  OK  ] Listening on Delayed Shutdown Socket.
systemd[1]: Listening on Delayed Shutdown Socket.
systemd[1]: Starting Syslog Socket.
[  OK  ] Listening on Syslog Socket.
systemd[1]: Listening on Syslog Socket.
systemd[1]: Starting User and Session Slice.
[  OK  ] Created slice User and Session Slice.
systemd[1]: Created slice User and Session Slice.
systemd[1]: Starting System Slice.
[  OK  ] Created slice System Slice.
systemd[1]: Created slice System Slice.
systemd[1]: Started Create list of required static device nodes for
the current kernel.
systemd[1]: Starting Create static device nodes in /dev...
         Starting Create static device nodes in /dev...
systemd[1]: Mounting POSIX Message Queue File System...
         Mounting POSIX Message Queue File System...
systemd[1]: Mounting Debug File System...
         Mounting Debug File System...
systemd[1]: Mounting Huge Pages File System...
         Mounting Huge Pages File System...
systemd[1]: Starting Journal Service...
         Starting Journal Service...
[  OK  ] Started Journal Service.
systemd[1]: Started Journal Service.
[  OK  ] Created slice system-serial\x2dgetty.slice.
[  OK  ] Created slice system-getty.slice.
         Starting LVM2 metadata daemon...
         Starting Load Kernel Modules...
         Starting Setup Virtual Console...
         Starting Remount Root and Kernel File Systems...
         Starting Create dynamic rule for /dev/root link...
[  OK  ] Reached target Slices.
[  OK  ] Listening on udev Control Socket.
[  OK  ] Mounted Huge Pages File System.
[  OK  ] Mounted Debug File System.
[  OK  ] Mounted POSIX Message Queue File System.
[  OK  ] Started Create static device nodes in /dev.
[  OK  ] Started LVM2 metadata daemon.
[FAILED] Failed to start Load Kernel Modules.
See "systemctl status systemd-modules-load.service" for details.
[  OK  ] Started Setup Virtual Console.
[  OK  ] Started Remount Root and Kernel File Systems.
[  OK  ] Started Create dynamic rule for /dev/root link.
         Starting Load/Save Random Seed...
         Starting udev Coldplug all Devices...
         Starting Apply Kernel Variables...
         Mounting FUSE Control File System...
         Starting udev Kernel Device Manager...
[  OK  ] Reached target Local File Systems (Pre).
         Mounting Runtime Directory...
[  OK  ] Mounted FUSE Control File System.
[  OK  ] Mounted Runtime Directory.
[  OK  ] Started udev Kernel Device Manager.
[  OK  ] Started Load/Save Random Seed.
[  OK  ] Started Apply Kernel Variables.
[  OK  ] Started udev Coldplug all Devices.
thunder-nicvf 0002:01:00.3 enP2p1s0f3: renamed from eth2
         Starting udev Wait for Complete Device Initialization...
thunder-nicvf 0002:01:00.1 enP2p1s0f1: renamed from eth0
thunder-nicvf 0002:01:00.2 enP2p1s0f2: renamed from eth1
thunder-nicvf 0002:01:00.4 enP2p1s0f4: renamed from eth3
[  OK  ] Started udev Wait for Complete Device Initialization.
         Starting Activation of LVM2 logical volumes...
[  OK  ] Started Activation of LVM2 logical volumes.
[  OK  ] Reached target Encrypted Volumes.
         Starting Activation of LVM2 logical volumes...
[  OK  ] Started Activation of LVM2 logical volumes.
[  OK  ] Reached target Local File Systems.
         Starting Trigger Flushing of Journal to Persistent Storage...
         Starting Create Volatile Files and Directories...
systemd-journald[884]: Received request to flush runtime journal from PID 1
[  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
[  OK  ] Started Create Volatile Files and Directories.
         Starting Update UTMP about System Reboot/Shutdown...
[  OK  ] Started Update UTMP about System Reboot/Shutdown.
[  OK  ] Reached target System Initialization.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Reached target Sockets.
[  OK  ] Reached target Timers.
         Starting Restore Sound Card State...
[  OK  ] Reached target Basic System.
         Starting Permit User Sessions...
         Starting /etc/init.d/boot.local Compatibility...
         Starting System Logging Service...
         Starting Purge old kernels...
         Starting Login Service...
         Starting D-Bus System Message Bus...
[  OK  ] Started D-Bus System Message Bus.
         Starting wicked DHCPv4 supplicant service...
         Starting wicked AutoIPv4 supplicant service...
         Starting wicked DHCPv6 supplicant service...
[  OK  ] Started Restore Sound Card State.
[  OK  ] Started Permit User Sessions.
[  OK  ] Started /etc/init.d/boot.local Compatibility.
[  OK  ] Started wicked AutoIPv4 supplicant service.
[  OK  ] Started wicked DHCPv6 supplicant service.
[  OK  ] Started wicked DHCPv4 supplicant service.
[  OK  ] Started Login Service.
         Starting wicked network management service daemon...
         Starting Getty on tty1...
[  OK  ] Started Getty on tty1.
[  OK  ] Started System Logging Service.
[  OK  ] Started wicked network management service daemon.
         Starting wicked network nanny service...
[  OK  ] Started wicked network nanny service.
         Starting wicked managed network interfaces...
[  OK  ] Started Purge old kernels.
[  OK  ] Started wicked managed network interfaces.
[  OK  ] Reached target Network.
         Starting OpenSSH Daemon...
         Starting NTP Server Daemon...
[  OK  ] Started NTP Server Daemon.
[  OK  ] Started OpenSSH Daemon.
[ TIME ] Timed out waiting for device dev-hvc0.device.
[DEPEND] Dependency failed for Serial Getty on hvc0.
[  OK  ] Reached target Login Prompts.
         Starting /etc/init.d/after.local Compatibility...
[  OK  ] Started /etc/init.d/after.local Compatibility.
[  OK  ] Reached target Multi-User System.
[  OK  ] Reached target Graphical Interface.


Alex,any idea how to look for what is causing timeout ?
Grep -rn hcv0 in suse file system resulted nil.
I am using https://wiki.linaro.org/LEG/Engineering/Xen_booting_on_Foundationv8

-regards
manish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 00:25:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 00: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 1XzE32-00077F-Ru; Fri, 12 Dec 2014 00:25:32 +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 1XzE31-00077A-GF
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 00:25:31 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	28/56-02954-AF53A845; Fri, 12 Dec 2014 00:25:30 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418343928!14580940!1
X-Originating-IP: [209.85.216.181]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17740 invoked from network); 12 Dec 2014 00:25:29 -0000
Received: from mail-qc0-f181.google.com (HELO mail-qc0-f181.google.com)
	(209.85.216.181)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 00:25:29 -0000
Received: by mail-qc0-f181.google.com with SMTP id m20so4752852qcx.40
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 16:25: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=uHMTodTeouV2xUBXdXsHYfLA/SdBxStBMpOd/P04OeM=;
	b=qBkzgOsL8rLXy0zxFNNZC1qPH8SecOWqxloyQWJWdMNL2SR2tOtBw+oqUTOLWU0zZe
	MgsWXsRBhZMsmENxdtf/4jqYr07qCpIVvmjNYN2rMJJv6rFCmHK78jieKDhYFU+aC59/
	7Po8mi+/6ODecDazaIaOGpSl2VwWBFP4wi6RpKqdHFIPkOWAyy+MFU4xuRUItYMJiuSe
	Rx5tT9Ld1Lne5sOYpObgExhMW0yGk1+XevfbeB1ftJxpZYp7Ci+IBCtsIOGCYgToPEv6
	WPkZakTtPN82QBv08p4M+YdHzzTo+GIBf5WyA0RKoaC4Xhp3w0NPK3H8JKSa0ZNxW5Oo
	Vseg==
MIME-Version: 1.0
X-Received: by 10.224.80.6 with SMTP id r6mr25174625qak.5.1418343928147; Thu,
	11 Dec 2014 16:25:28 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Thu, 11 Dec 2014 16:25:28 -0800 (PST)
In-Reply-To: <54897098.3070009@linaro.org>
References: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>
	<54897098.3070009@linaro.org>
Date: Thu, 11 Dec 2014 16:25:28 -0800
Message-ID: <CAAiw7Jk2xmpWo-Dv8KLb4sSoU4PhCuj-iDeVPJU7xHoR+Wsxag@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Julien Grall <julien.grall@linaro.org>, agraf@suse.de
Cc: manish.jaggi@caviumnetworks.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Timed out waiting for device dev-hvc0.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 11 December 2014 at 02:23, Julien Grall <julien.grall@linaro.org> wrote:
> Hello,
>
>
> On 11/12/2014 02:27, manish jaggi wrote:
>>
>> I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)
>>
>> ...
>>
>> [  OK  ] Reached target Host and Network Name Lookups.
>> [  OK  ] Started OpenSSH Daemon.
>> [ TIME ] Timed out waiting for device dev-hvc0.device.
>> [DEPEND] Dependency failed for Serial Getty on hvc0.
>> [  OK  ] Reached target Login Prompts.
>>
>>
>> Any Idea? what could be wrong here
>
>
> Please provide the full boot log. With only those 5 lines we can only guess
> what could be the issue.
>
Added
> Maybe the DOM0 kernel didn't detect that it's running on Xen or you forgot
> to enable CONFIG_XEN_HVC in your config.
That is already enabled.
FYI with other rootfs I dont see any problem.
>
> Regards,
>
> --
> Julien Grall

[... Std linux boot log .. ]
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sda2): using internal journal
EXT3-fs (sda2): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) on device 8:2.
devtmpfs: mounted
Freeing unused kernel memory: 236K (ffffffc000789000 - ffffffc0007c4000)
random: systemd urandom read with 4 bits of entropy available
systemd[1]: systemd 210 running in system mode. (+PAM -LIBWRAP +AUDIT
+SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP
+APPARMOR)
systemd[1]: Detected virtualization 'xen'.
systemd[1]: Detected architecture 'arm64'.

Welcome to openSUSE 13.2 (Harlequin) (aarch64)!

systemd[1]: Failed to insert module 'autofs4'
systemd[1]: Failed to insert module 'ipv6'
systemd[1]: Set hostname to <linux>.
systemd[1]: Cannot add dependency job for unit
display-manager.service, ignoring: Unit display-manager.service failed
to load: No such file or directory.
systemd[1]: Expecting device dev-hvc0.device...
         Expecting device dev-hvc0.device...
systemd[1]: Starting Remote File Systems (Pre).
[  OK  ] Reached target Remote File Systems (Pre).
systemd[1]: Reached target Remote File Systems (Pre).
systemd[1]: Starting Remote File Systems.
[  OK  ] Reached target Remote File Systems.
systemd[1]: Reached target Remote File Systems.
systemd[1]: Set up automount Arbitrary Executable File Formats File
System Automount Point.
systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
systemd[1]: Starting Paths.
[  OK  ] Reached target Paths.
systemd[1]: Reached target Paths.
systemd[1]: Starting Swap.
[  OK  ] Reached target Swap.
systemd[1]: Reached target Swap.
systemd[1]: Starting Root Slice.
[  OK  ] Created slice Root Slice.
systemd[1]: Created slice Root Slice.
systemd[1]: Starting udev Kernel Socket.
[  OK  ] Listening on udev Kernel Socket.
systemd[1]: Listening on udev Kernel Socket.
systemd[1]: Starting Journal Socket.
[  OK  ] Listening on Journal Socket.
systemd[1]: Listening on Journal Socket.
systemd[1]: Starting LVM2 metadata daemon socket.
[  OK  ] Listening on LVM2 metadata daemon socket.
systemd[1]: Listening on LVM2 metadata daemon socket.
systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
[  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
systemd[1]: Starting Delayed Shutdown Socket.
[  OK  ] Listening on Delayed Shutdown Socket.
systemd[1]: Listening on Delayed Shutdown Socket.
systemd[1]: Starting Syslog Socket.
[  OK  ] Listening on Syslog Socket.
systemd[1]: Listening on Syslog Socket.
systemd[1]: Starting User and Session Slice.
[  OK  ] Created slice User and Session Slice.
systemd[1]: Created slice User and Session Slice.
systemd[1]: Starting System Slice.
[  OK  ] Created slice System Slice.
systemd[1]: Created slice System Slice.
systemd[1]: Started Create list of required static device nodes for
the current kernel.
systemd[1]: Starting Create static device nodes in /dev...
         Starting Create static device nodes in /dev...
systemd[1]: Mounting POSIX Message Queue File System...
         Mounting POSIX Message Queue File System...
systemd[1]: Mounting Debug File System...
         Mounting Debug File System...
systemd[1]: Mounting Huge Pages File System...
         Mounting Huge Pages File System...
systemd[1]: Starting Journal Service...
         Starting Journal Service...
[  OK  ] Started Journal Service.
systemd[1]: Started Journal Service.
[  OK  ] Created slice system-serial\x2dgetty.slice.
[  OK  ] Created slice system-getty.slice.
         Starting LVM2 metadata daemon...
         Starting Load Kernel Modules...
         Starting Setup Virtual Console...
         Starting Remount Root and Kernel File Systems...
         Starting Create dynamic rule for /dev/root link...
[  OK  ] Reached target Slices.
[  OK  ] Listening on udev Control Socket.
[  OK  ] Mounted Huge Pages File System.
[  OK  ] Mounted Debug File System.
[  OK  ] Mounted POSIX Message Queue File System.
[  OK  ] Started Create static device nodes in /dev.
[  OK  ] Started LVM2 metadata daemon.
[FAILED] Failed to start Load Kernel Modules.
See "systemctl status systemd-modules-load.service" for details.
[  OK  ] Started Setup Virtual Console.
[  OK  ] Started Remount Root and Kernel File Systems.
[  OK  ] Started Create dynamic rule for /dev/root link.
         Starting Load/Save Random Seed...
         Starting udev Coldplug all Devices...
         Starting Apply Kernel Variables...
         Mounting FUSE Control File System...
         Starting udev Kernel Device Manager...
[  OK  ] Reached target Local File Systems (Pre).
         Mounting Runtime Directory...
[  OK  ] Mounted FUSE Control File System.
[  OK  ] Mounted Runtime Directory.
[  OK  ] Started udev Kernel Device Manager.
[  OK  ] Started Load/Save Random Seed.
[  OK  ] Started Apply Kernel Variables.
[  OK  ] Started udev Coldplug all Devices.
thunder-nicvf 0002:01:00.3 enP2p1s0f3: renamed from eth2
         Starting udev Wait for Complete Device Initialization...
thunder-nicvf 0002:01:00.1 enP2p1s0f1: renamed from eth0
thunder-nicvf 0002:01:00.2 enP2p1s0f2: renamed from eth1
thunder-nicvf 0002:01:00.4 enP2p1s0f4: renamed from eth3
[  OK  ] Started udev Wait for Complete Device Initialization.
         Starting Activation of LVM2 logical volumes...
[  OK  ] Started Activation of LVM2 logical volumes.
[  OK  ] Reached target Encrypted Volumes.
         Starting Activation of LVM2 logical volumes...
[  OK  ] Started Activation of LVM2 logical volumes.
[  OK  ] Reached target Local File Systems.
         Starting Trigger Flushing of Journal to Persistent Storage...
         Starting Create Volatile Files and Directories...
systemd-journald[884]: Received request to flush runtime journal from PID 1
[  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
[  OK  ] Started Create Volatile Files and Directories.
         Starting Update UTMP about System Reboot/Shutdown...
[  OK  ] Started Update UTMP about System Reboot/Shutdown.
[  OK  ] Reached target System Initialization.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Reached target Sockets.
[  OK  ] Reached target Timers.
         Starting Restore Sound Card State...
[  OK  ] Reached target Basic System.
         Starting Permit User Sessions...
         Starting /etc/init.d/boot.local Compatibility...
         Starting System Logging Service...
         Starting Purge old kernels...
         Starting Login Service...
         Starting D-Bus System Message Bus...
[  OK  ] Started D-Bus System Message Bus.
         Starting wicked DHCPv4 supplicant service...
         Starting wicked AutoIPv4 supplicant service...
         Starting wicked DHCPv6 supplicant service...
[  OK  ] Started Restore Sound Card State.
[  OK  ] Started Permit User Sessions.
[  OK  ] Started /etc/init.d/boot.local Compatibility.
[  OK  ] Started wicked AutoIPv4 supplicant service.
[  OK  ] Started wicked DHCPv6 supplicant service.
[  OK  ] Started wicked DHCPv4 supplicant service.
[  OK  ] Started Login Service.
         Starting wicked network management service daemon...
         Starting Getty on tty1...
[  OK  ] Started Getty on tty1.
[  OK  ] Started System Logging Service.
[  OK  ] Started wicked network management service daemon.
         Starting wicked network nanny service...
[  OK  ] Started wicked network nanny service.
         Starting wicked managed network interfaces...
[  OK  ] Started Purge old kernels.
[  OK  ] Started wicked managed network interfaces.
[  OK  ] Reached target Network.
         Starting OpenSSH Daemon...
         Starting NTP Server Daemon...
[  OK  ] Started NTP Server Daemon.
[  OK  ] Started OpenSSH Daemon.
[ TIME ] Timed out waiting for device dev-hvc0.device.
[DEPEND] Dependency failed for Serial Getty on hvc0.
[  OK  ] Reached target Login Prompts.
         Starting /etc/init.d/after.local Compatibility...
[  OK  ] Started /etc/init.d/after.local Compatibility.
[  OK  ] Reached target Multi-User System.
[  OK  ] Reached target Graphical Interface.


Alex,any idea how to look for what is causing timeout ?
Grep -rn hcv0 in suse file system resulted nil.
I am using https://wiki.linaro.org/LEG/Engineering/Xen_booting_on_Foundationv8

-regards
manish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 00:33:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 00: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 1XzEA3-0007db-OR; Fri, 12 Dec 2014 00:32:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1XzEA3-0007dW-3J
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 00:32:47 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	7C/D4-08051-EA73A845; Fri, 12 Dec 2014 00:32:46 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418344364!14581778!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 16289 invoked from network); 12 Dec 2014 00:32:45 -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; 12 Dec 2014 00:32:45 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 81BCCAD08;
	Fri, 12 Dec 2014 00:32:44 +0000 (UTC)
Message-ID: <548A37A9.1010006@suse.de>
Date: Fri, 12 Dec 2014 01:32:41 +0100
From: Alexander Graf <agraf@suse.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>, 
	Julien Grall <julien.grall@linaro.org>
References: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>	<54897098.3070009@linaro.org>
	<CAAiw7Jk2xmpWo-Dv8KLb4sSoU4PhCuj-iDeVPJU7xHoR+Wsxag@mail.gmail.com>
In-Reply-To: <CAAiw7Jk2xmpWo-Dv8KLb4sSoU4PhCuj-iDeVPJU7xHoR+Wsxag@mail.gmail.com>
Cc: manish.jaggi@caviumnetworks.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Timed out waiting for device dev-hvc0.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 12.12.14 01:25, manish jaggi wrote:
> On 11 December 2014 at 02:23, Julien Grall <julien.grall@linaro.org> wrote:
>> Hello,
>>
>>
>> On 11/12/2014 02:27, manish jaggi wrote:
>>>
>>> I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)
>>>
>>> ...
>>>
>>> [  OK  ] Reached target Host and Network Name Lookups.
>>> [  OK  ] Started OpenSSH Daemon.
>>> [ TIME ] Timed out waiting for device dev-hvc0.device.
>>> [DEPEND] Dependency failed for Serial Getty on hvc0.
>>> [  OK  ] Reached target Login Prompts.
>>>
>>>
>>> Any Idea? what could be wrong here
>>
>>
>> Please provide the full boot log. With only those 5 lines we can only guess
>> what could be the issue.
>>
> Added
>> Maybe the DOM0 kernel didn't detect that it's running on Xen or you forgot
>> to enable CONFIG_XEN_HVC in your config.
> That is already enabled.
> FYI with other rootfs I dont see any problem.
>>
>> Regards,
>>
>> --
>> Julien Grall
> 
> [... Std linux boot log .. ]
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs (sda2): using internal journal
> EXT3-fs (sda2): mounted filesystem with writeback data mode
> VFS: Mounted root (ext3 filesystem) on device 8:2.
> devtmpfs: mounted
> Freeing unused kernel memory: 236K (ffffffc000789000 - ffffffc0007c4000)
> random: systemd urandom read with 4 bits of entropy available
> systemd[1]: systemd 210 running in system mode. (+PAM -LIBWRAP +AUDIT
> +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP
> +APPARMOR)
> systemd[1]: Detected virtualization 'xen'.
> systemd[1]: Detected architecture 'arm64'.
> 
> Welcome to openSUSE 13.2 (Harlequin) (aarch64)!
> 
> systemd[1]: Failed to insert module 'autofs4'
> systemd[1]: Failed to insert module 'ipv6'
> systemd[1]: Set hostname to <linux>.
> systemd[1]: Cannot add dependency job for unit
> display-manager.service, ignoring: Unit display-manager.service failed
> to load: No such file or directory.
> systemd[1]: Expecting device dev-hvc0.device...
>          Expecting device dev-hvc0.device...
> systemd[1]: Starting Remote File Systems (Pre).
> [  OK  ] Reached target Remote File Systems (Pre).
> systemd[1]: Reached target Remote File Systems (Pre).
> systemd[1]: Starting Remote File Systems.
> [  OK  ] Reached target Remote File Systems.
> systemd[1]: Reached target Remote File Systems.
> systemd[1]: Set up automount Arbitrary Executable File Formats File
> System Automount Point.
> systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
> systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
> systemd[1]: Starting Paths.
> [  OK  ] Reached target Paths.
> systemd[1]: Reached target Paths.
> systemd[1]: Starting Swap.
> [  OK  ] Reached target Swap.
> systemd[1]: Reached target Swap.
> systemd[1]: Starting Root Slice.
> [  OK  ] Created slice Root Slice.
> systemd[1]: Created slice Root Slice.
> systemd[1]: Starting udev Kernel Socket.
> [  OK  ] Listening on udev Kernel Socket.
> systemd[1]: Listening on udev Kernel Socket.
> systemd[1]: Starting Journal Socket.
> [  OK  ] Listening on Journal Socket.
> systemd[1]: Listening on Journal Socket.
> systemd[1]: Starting LVM2 metadata daemon socket.
> [  OK  ] Listening on LVM2 metadata daemon socket.
> systemd[1]: Listening on LVM2 metadata daemon socket.
> systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
> [  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
> systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
> systemd[1]: Starting Delayed Shutdown Socket.
> [  OK  ] Listening on Delayed Shutdown Socket.
> systemd[1]: Listening on Delayed Shutdown Socket.
> systemd[1]: Starting Syslog Socket.
> [  OK  ] Listening on Syslog Socket.
> systemd[1]: Listening on Syslog Socket.
> systemd[1]: Starting User and Session Slice.
> [  OK  ] Created slice User and Session Slice.
> systemd[1]: Created slice User and Session Slice.
> systemd[1]: Starting System Slice.
> [  OK  ] Created slice System Slice.
> systemd[1]: Created slice System Slice.
> systemd[1]: Started Create list of required static device nodes for
> the current kernel.
> systemd[1]: Starting Create static device nodes in /dev...
>          Starting Create static device nodes in /dev...
> systemd[1]: Mounting POSIX Message Queue File System...
>          Mounting POSIX Message Queue File System...
> systemd[1]: Mounting Debug File System...
>          Mounting Debug File System...
> systemd[1]: Mounting Huge Pages File System...
>          Mounting Huge Pages File System...
> systemd[1]: Starting Journal Service...
>          Starting Journal Service...
> [  OK  ] Started Journal Service.
> systemd[1]: Started Journal Service.
> [  OK  ] Created slice system-serial\x2dgetty.slice.
> [  OK  ] Created slice system-getty.slice.
>          Starting LVM2 metadata daemon...
>          Starting Load Kernel Modules...
>          Starting Setup Virtual Console...
>          Starting Remount Root and Kernel File Systems...
>          Starting Create dynamic rule for /dev/root link...
> [  OK  ] Reached target Slices.
> [  OK  ] Listening on udev Control Socket.
> [  OK  ] Mounted Huge Pages File System.
> [  OK  ] Mounted Debug File System.
> [  OK  ] Mounted POSIX Message Queue File System.
> [  OK  ] Started Create static device nodes in /dev.
> [  OK  ] Started LVM2 metadata daemon.
> [FAILED] Failed to start Load Kernel Modules.
> See "systemctl status systemd-modules-load.service" for details.
> [  OK  ] Started Setup Virtual Console.
> [  OK  ] Started Remount Root and Kernel File Systems.
> [  OK  ] Started Create dynamic rule for /dev/root link.
>          Starting Load/Save Random Seed...
>          Starting udev Coldplug all Devices...
>          Starting Apply Kernel Variables...
>          Mounting FUSE Control File System...
>          Starting udev Kernel Device Manager...
> [  OK  ] Reached target Local File Systems (Pre).
>          Mounting Runtime Directory...
> [  OK  ] Mounted FUSE Control File System.
> [  OK  ] Mounted Runtime Directory.
> [  OK  ] Started udev Kernel Device Manager.
> [  OK  ] Started Load/Save Random Seed.
> [  OK  ] Started Apply Kernel Variables.
> [  OK  ] Started udev Coldplug all Devices.
> thunder-nicvf 0002:01:00.3 enP2p1s0f3: renamed from eth2
>          Starting udev Wait for Complete Device Initialization...
> thunder-nicvf 0002:01:00.1 enP2p1s0f1: renamed from eth0
> thunder-nicvf 0002:01:00.2 enP2p1s0f2: renamed from eth1
> thunder-nicvf 0002:01:00.4 enP2p1s0f4: renamed from eth3
> [  OK  ] Started udev Wait for Complete Device Initialization.
>          Starting Activation of LVM2 logical volumes...
> [  OK  ] Started Activation of LVM2 logical volumes.
> [  OK  ] Reached target Encrypted Volumes.
>          Starting Activation of LVM2 logical volumes...
> [  OK  ] Started Activation of LVM2 logical volumes.
> [  OK  ] Reached target Local File Systems.
>          Starting Trigger Flushing of Journal to Persistent Storage...
>          Starting Create Volatile Files and Directories...
> systemd-journald[884]: Received request to flush runtime journal from PID 1
> [  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
> [  OK  ] Started Create Volatile Files and Directories.
>          Starting Update UTMP about System Reboot/Shutdown...
> [  OK  ] Started Update UTMP about System Reboot/Shutdown.
> [  OK  ] Reached target System Initialization.
> [  OK  ] Listening on D-Bus System Message Bus Socket.
> [  OK  ] Reached target Sockets.
> [  OK  ] Reached target Timers.
>          Starting Restore Sound Card State...
> [  OK  ] Reached target Basic System.
>          Starting Permit User Sessions...
>          Starting /etc/init.d/boot.local Compatibility...
>          Starting System Logging Service...
>          Starting Purge old kernels...
>          Starting Login Service...
>          Starting D-Bus System Message Bus...
> [  OK  ] Started D-Bus System Message Bus.
>          Starting wicked DHCPv4 supplicant service...
>          Starting wicked AutoIPv4 supplicant service...
>          Starting wicked DHCPv6 supplicant service...
> [  OK  ] Started Restore Sound Card State.
> [  OK  ] Started Permit User Sessions.
> [  OK  ] Started /etc/init.d/boot.local Compatibility.
> [  OK  ] Started wicked AutoIPv4 supplicant service.
> [  OK  ] Started wicked DHCPv6 supplicant service.
> [  OK  ] Started wicked DHCPv4 supplicant service.
> [  OK  ] Started Login Service.
>          Starting wicked network management service daemon...
>          Starting Getty on tty1...
> [  OK  ] Started Getty on tty1.
> [  OK  ] Started System Logging Service.
> [  OK  ] Started wicked network management service daemon.
>          Starting wicked network nanny service...
> [  OK  ] Started wicked network nanny service.
>          Starting wicked managed network interfaces...
> [  OK  ] Started Purge old kernels.
> [  OK  ] Started wicked managed network interfaces.
> [  OK  ] Reached target Network.
>          Starting OpenSSH Daemon...
>          Starting NTP Server Daemon...
> [  OK  ] Started NTP Server Daemon.
> [  OK  ] Started OpenSSH Daemon.
> [ TIME ] Timed out waiting for device dev-hvc0.device.
> [DEPEND] Dependency failed for Serial Getty on hvc0.
> [  OK  ] Reached target Login Prompts.
>          Starting /etc/init.d/after.local Compatibility...
> [  OK  ] Started /etc/init.d/after.local Compatibility.
> [  OK  ] Reached target Multi-User System.
> [  OK  ] Reached target Graphical Interface.
> 
> 
> Alex,any idea how to look for what is causing timeout ?
> Grep -rn hcv0 in suse file system resulted nil.
> I am using https://wiki.linaro.org/LEG/Engineering/Xen_booting_on_Foundationv8

Hrm, does your kernel have devtmpfs support enabled? Apparently SSH did
come up, can you try to log in via ssh and see whether you can see an
hvc0 device node in /dev?


Alex

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 00:33:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 00: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 1XzEA3-0007db-OR; Fri, 12 Dec 2014 00:32:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1XzEA3-0007dW-3J
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 00:32:47 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	7C/D4-08051-EA73A845; Fri, 12 Dec 2014 00:32:46 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418344364!14581778!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 16289 invoked from network); 12 Dec 2014 00:32:45 -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; 12 Dec 2014 00:32:45 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 81BCCAD08;
	Fri, 12 Dec 2014 00:32:44 +0000 (UTC)
Message-ID: <548A37A9.1010006@suse.de>
Date: Fri, 12 Dec 2014 01:32:41 +0100
From: Alexander Graf <agraf@suse.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>, 
	Julien Grall <julien.grall@linaro.org>
References: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>	<54897098.3070009@linaro.org>
	<CAAiw7Jk2xmpWo-Dv8KLb4sSoU4PhCuj-iDeVPJU7xHoR+Wsxag@mail.gmail.com>
In-Reply-To: <CAAiw7Jk2xmpWo-Dv8KLb4sSoU4PhCuj-iDeVPJU7xHoR+Wsxag@mail.gmail.com>
Cc: manish.jaggi@caviumnetworks.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Timed out waiting for device dev-hvc0.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 12.12.14 01:25, manish jaggi wrote:
> On 11 December 2014 at 02:23, Julien Grall <julien.grall@linaro.org> wrote:
>> Hello,
>>
>>
>> On 11/12/2014 02:27, manish jaggi wrote:
>>>
>>> I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)
>>>
>>> ...
>>>
>>> [  OK  ] Reached target Host and Network Name Lookups.
>>> [  OK  ] Started OpenSSH Daemon.
>>> [ TIME ] Timed out waiting for device dev-hvc0.device.
>>> [DEPEND] Dependency failed for Serial Getty on hvc0.
>>> [  OK  ] Reached target Login Prompts.
>>>
>>>
>>> Any Idea? what could be wrong here
>>
>>
>> Please provide the full boot log. With only those 5 lines we can only guess
>> what could be the issue.
>>
> Added
>> Maybe the DOM0 kernel didn't detect that it's running on Xen or you forgot
>> to enable CONFIG_XEN_HVC in your config.
> That is already enabled.
> FYI with other rootfs I dont see any problem.
>>
>> Regards,
>>
>> --
>> Julien Grall
> 
> [... Std linux boot log .. ]
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs (sda2): using internal journal
> EXT3-fs (sda2): mounted filesystem with writeback data mode
> VFS: Mounted root (ext3 filesystem) on device 8:2.
> devtmpfs: mounted
> Freeing unused kernel memory: 236K (ffffffc000789000 - ffffffc0007c4000)
> random: systemd urandom read with 4 bits of entropy available
> systemd[1]: systemd 210 running in system mode. (+PAM -LIBWRAP +AUDIT
> +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP
> +APPARMOR)
> systemd[1]: Detected virtualization 'xen'.
> systemd[1]: Detected architecture 'arm64'.
> 
> Welcome to openSUSE 13.2 (Harlequin) (aarch64)!
> 
> systemd[1]: Failed to insert module 'autofs4'
> systemd[1]: Failed to insert module 'ipv6'
> systemd[1]: Set hostname to <linux>.
> systemd[1]: Cannot add dependency job for unit
> display-manager.service, ignoring: Unit display-manager.service failed
> to load: No such file or directory.
> systemd[1]: Expecting device dev-hvc0.device...
>          Expecting device dev-hvc0.device...
> systemd[1]: Starting Remote File Systems (Pre).
> [  OK  ] Reached target Remote File Systems (Pre).
> systemd[1]: Reached target Remote File Systems (Pre).
> systemd[1]: Starting Remote File Systems.
> [  OK  ] Reached target Remote File Systems.
> systemd[1]: Reached target Remote File Systems.
> systemd[1]: Set up automount Arbitrary Executable File Formats File
> System Automount Point.
> systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
> systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
> systemd[1]: Starting Paths.
> [  OK  ] Reached target Paths.
> systemd[1]: Reached target Paths.
> systemd[1]: Starting Swap.
> [  OK  ] Reached target Swap.
> systemd[1]: Reached target Swap.
> systemd[1]: Starting Root Slice.
> [  OK  ] Created slice Root Slice.
> systemd[1]: Created slice Root Slice.
> systemd[1]: Starting udev Kernel Socket.
> [  OK  ] Listening on udev Kernel Socket.
> systemd[1]: Listening on udev Kernel Socket.
> systemd[1]: Starting Journal Socket.
> [  OK  ] Listening on Journal Socket.
> systemd[1]: Listening on Journal Socket.
> systemd[1]: Starting LVM2 metadata daemon socket.
> [  OK  ] Listening on LVM2 metadata daemon socket.
> systemd[1]: Listening on LVM2 metadata daemon socket.
> systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
> [  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
> systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
> systemd[1]: Starting Delayed Shutdown Socket.
> [  OK  ] Listening on Delayed Shutdown Socket.
> systemd[1]: Listening on Delayed Shutdown Socket.
> systemd[1]: Starting Syslog Socket.
> [  OK  ] Listening on Syslog Socket.
> systemd[1]: Listening on Syslog Socket.
> systemd[1]: Starting User and Session Slice.
> [  OK  ] Created slice User and Session Slice.
> systemd[1]: Created slice User and Session Slice.
> systemd[1]: Starting System Slice.
> [  OK  ] Created slice System Slice.
> systemd[1]: Created slice System Slice.
> systemd[1]: Started Create list of required static device nodes for
> the current kernel.
> systemd[1]: Starting Create static device nodes in /dev...
>          Starting Create static device nodes in /dev...
> systemd[1]: Mounting POSIX Message Queue File System...
>          Mounting POSIX Message Queue File System...
> systemd[1]: Mounting Debug File System...
>          Mounting Debug File System...
> systemd[1]: Mounting Huge Pages File System...
>          Mounting Huge Pages File System...
> systemd[1]: Starting Journal Service...
>          Starting Journal Service...
> [  OK  ] Started Journal Service.
> systemd[1]: Started Journal Service.
> [  OK  ] Created slice system-serial\x2dgetty.slice.
> [  OK  ] Created slice system-getty.slice.
>          Starting LVM2 metadata daemon...
>          Starting Load Kernel Modules...
>          Starting Setup Virtual Console...
>          Starting Remount Root and Kernel File Systems...
>          Starting Create dynamic rule for /dev/root link...
> [  OK  ] Reached target Slices.
> [  OK  ] Listening on udev Control Socket.
> [  OK  ] Mounted Huge Pages File System.
> [  OK  ] Mounted Debug File System.
> [  OK  ] Mounted POSIX Message Queue File System.
> [  OK  ] Started Create static device nodes in /dev.
> [  OK  ] Started LVM2 metadata daemon.
> [FAILED] Failed to start Load Kernel Modules.
> See "systemctl status systemd-modules-load.service" for details.
> [  OK  ] Started Setup Virtual Console.
> [  OK  ] Started Remount Root and Kernel File Systems.
> [  OK  ] Started Create dynamic rule for /dev/root link.
>          Starting Load/Save Random Seed...
>          Starting udev Coldplug all Devices...
>          Starting Apply Kernel Variables...
>          Mounting FUSE Control File System...
>          Starting udev Kernel Device Manager...
> [  OK  ] Reached target Local File Systems (Pre).
>          Mounting Runtime Directory...
> [  OK  ] Mounted FUSE Control File System.
> [  OK  ] Mounted Runtime Directory.
> [  OK  ] Started udev Kernel Device Manager.
> [  OK  ] Started Load/Save Random Seed.
> [  OK  ] Started Apply Kernel Variables.
> [  OK  ] Started udev Coldplug all Devices.
> thunder-nicvf 0002:01:00.3 enP2p1s0f3: renamed from eth2
>          Starting udev Wait for Complete Device Initialization...
> thunder-nicvf 0002:01:00.1 enP2p1s0f1: renamed from eth0
> thunder-nicvf 0002:01:00.2 enP2p1s0f2: renamed from eth1
> thunder-nicvf 0002:01:00.4 enP2p1s0f4: renamed from eth3
> [  OK  ] Started udev Wait for Complete Device Initialization.
>          Starting Activation of LVM2 logical volumes...
> [  OK  ] Started Activation of LVM2 logical volumes.
> [  OK  ] Reached target Encrypted Volumes.
>          Starting Activation of LVM2 logical volumes...
> [  OK  ] Started Activation of LVM2 logical volumes.
> [  OK  ] Reached target Local File Systems.
>          Starting Trigger Flushing of Journal to Persistent Storage...
>          Starting Create Volatile Files and Directories...
> systemd-journald[884]: Received request to flush runtime journal from PID 1
> [  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
> [  OK  ] Started Create Volatile Files and Directories.
>          Starting Update UTMP about System Reboot/Shutdown...
> [  OK  ] Started Update UTMP about System Reboot/Shutdown.
> [  OK  ] Reached target System Initialization.
> [  OK  ] Listening on D-Bus System Message Bus Socket.
> [  OK  ] Reached target Sockets.
> [  OK  ] Reached target Timers.
>          Starting Restore Sound Card State...
> [  OK  ] Reached target Basic System.
>          Starting Permit User Sessions...
>          Starting /etc/init.d/boot.local Compatibility...
>          Starting System Logging Service...
>          Starting Purge old kernels...
>          Starting Login Service...
>          Starting D-Bus System Message Bus...
> [  OK  ] Started D-Bus System Message Bus.
>          Starting wicked DHCPv4 supplicant service...
>          Starting wicked AutoIPv4 supplicant service...
>          Starting wicked DHCPv6 supplicant service...
> [  OK  ] Started Restore Sound Card State.
> [  OK  ] Started Permit User Sessions.
> [  OK  ] Started /etc/init.d/boot.local Compatibility.
> [  OK  ] Started wicked AutoIPv4 supplicant service.
> [  OK  ] Started wicked DHCPv6 supplicant service.
> [  OK  ] Started wicked DHCPv4 supplicant service.
> [  OK  ] Started Login Service.
>          Starting wicked network management service daemon...
>          Starting Getty on tty1...
> [  OK  ] Started Getty on tty1.
> [  OK  ] Started System Logging Service.
> [  OK  ] Started wicked network management service daemon.
>          Starting wicked network nanny service...
> [  OK  ] Started wicked network nanny service.
>          Starting wicked managed network interfaces...
> [  OK  ] Started Purge old kernels.
> [  OK  ] Started wicked managed network interfaces.
> [  OK  ] Reached target Network.
>          Starting OpenSSH Daemon...
>          Starting NTP Server Daemon...
> [  OK  ] Started NTP Server Daemon.
> [  OK  ] Started OpenSSH Daemon.
> [ TIME ] Timed out waiting for device dev-hvc0.device.
> [DEPEND] Dependency failed for Serial Getty on hvc0.
> [  OK  ] Reached target Login Prompts.
>          Starting /etc/init.d/after.local Compatibility...
> [  OK  ] Started /etc/init.d/after.local Compatibility.
> [  OK  ] Reached target Multi-User System.
> [  OK  ] Reached target Graphical Interface.
> 
> 
> Alex,any idea how to look for what is causing timeout ?
> Grep -rn hcv0 in suse file system resulted nil.
> I am using https://wiki.linaro.org/LEG/Engineering/Xen_booting_on_Foundationv8

Hrm, does your kernel have devtmpfs support enabled? Apparently SSH did
come up, can you try to log in via ssh and see whether you can see an
hvc0 device node in /dev?


Alex

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 01:21:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 01: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 1XzEuW-0004nz-4t; Fri, 12 Dec 2014 01:20:48 +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 1XzEuU-0004nu-Ij
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 01:20:46 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	D4/C6-02712-DE24A845; Fri, 12 Dec 2014 01:20:45 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418347243!14549853!1
X-Originating-IP: [209.85.192.42]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10588 invoked from network); 12 Dec 2014 01:20:44 -0000
Received: from mail-qg0-f42.google.com (HELO mail-qg0-f42.google.com)
	(209.85.192.42)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 01:20:44 -0000
Received: by mail-qg0-f42.google.com with SMTP id q108so2745731qgd.29
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 17:20:43 -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=sPZZPc3o3Y6cTokPK8lzV6EfpdyauV47ex6UPAcf04k=;
	b=v+PRqFuXWS/N1QsODJsaTCSVYKmLj8AZ+9rLDMPmRv6mkVt6SODenKV42TI20ZxYID
	EO6WOFM95cYjQQRN0f9ZbWFrK0Heey60kRj1TtWMDQ4l0FS4Kz5XpSTqdg1LPqsBJLKt
	/uCUsM61C6a05iqrEuI5XA8xIuB6QhSrfRi7mYH2cYvk8fztaGLGZT/DTKzbzHXSo20k
	DwBUdO6lS0bsGRbJKuTexs4Am8CFUAGg5nm0YaLb/rCldBjbFMZ3hHJDG3/h7mej9rp8
	ECbTv0BhWtA6Q6vmZhD5Muf4vuGksbnBcZ/vvphJKmAmkpBzibTG2Jvjg6t7TsX9rKrt
	gQSg==
MIME-Version: 1.0
X-Received: by 10.140.31.166 with SMTP id f35mr24941640qgf.66.1418347243254;
	Thu, 11 Dec 2014 17:20:43 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Thu, 11 Dec 2014 17:20:43 -0800 (PST)
In-Reply-To: <548A37A9.1010006@suse.de>
References: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>
	<54897098.3070009@linaro.org>
	<CAAiw7Jk2xmpWo-Dv8KLb4sSoU4PhCuj-iDeVPJU7xHoR+Wsxag@mail.gmail.com>
	<548A37A9.1010006@suse.de>
Date: Thu, 11 Dec 2014 17:20:43 -0800
Message-ID: <CAAiw7JkV-T+WP4kspGAgBhGr8UKcVT=ySO63VLv3RFGJs7RQSg@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Alexander Graf <agraf@suse.de>
Cc: manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Timed out waiting for device dev-hvc0.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 11 December 2014 at 16:32, Alexander Graf <agraf@suse.de> wrote:
>
>
> On 12.12.14 01:25, manish jaggi wrote:
>> On 11 December 2014 at 02:23, Julien Grall <julien.grall@linaro.org> wrote:
>>> Hello,
>>>
>>>
>>> On 11/12/2014 02:27, manish jaggi wrote:
>>>>
>>>> I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)
>>>>
>>>> ...
>>>>
>>>> [  OK  ] Reached target Host and Network Name Lookups.
>>>> [  OK  ] Started OpenSSH Daemon.
>>>> [ TIME ] Timed out waiting for device dev-hvc0.device.
>>>> [DEPEND] Dependency failed for Serial Getty on hvc0.
>>>> [  OK  ] Reached target Login Prompts.
>>>>
>>>>
>>>> Any Idea? what could be wrong here
>>>
>>>
>>> Please provide the full boot log. With only those 5 lines we can only guess
>>> what could be the issue.
>>>
>> Added
>>> Maybe the DOM0 kernel didn't detect that it's running on Xen or you forgot
>>> to enable CONFIG_XEN_HVC in your config.
>> That is already enabled.
>> FYI with other rootfs I dont see any problem.
>>>
>>> Regards,
>>>
>>> --
>>> Julien Grall
>>
>> [... Std linux boot log .. ]
>> kjournald starting.  Commit interval 5 seconds
>> EXT3-fs (sda2): using internal journal
>> EXT3-fs (sda2): mounted filesystem with writeback data mode
>> VFS: Mounted root (ext3 filesystem) on device 8:2.
>> devtmpfs: mounted
>> Freeing unused kernel memory: 236K (ffffffc000789000 - ffffffc0007c4000)
>> random: systemd urandom read with 4 bits of entropy available
>> systemd[1]: systemd 210 running in system mode. (+PAM -LIBWRAP +AUDIT
>> +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP
>> +APPARMOR)
>> systemd[1]: Detected virtualization 'xen'.
>> systemd[1]: Detected architecture 'arm64'.
>>
>> Welcome to openSUSE 13.2 (Harlequin) (aarch64)!
>>
>> systemd[1]: Failed to insert module 'autofs4'
>> systemd[1]: Failed to insert module 'ipv6'
>> systemd[1]: Set hostname to <linux>.
>> systemd[1]: Cannot add dependency job for unit
>> display-manager.service, ignoring: Unit display-manager.service failed
>> to load: No such file or directory.
>> systemd[1]: Expecting device dev-hvc0.device...
>>          Expecting device dev-hvc0.device...
>> systemd[1]: Starting Remote File Systems (Pre).
>> [  OK  ] Reached target Remote File Systems (Pre).
>> systemd[1]: Reached target Remote File Systems (Pre).
>> systemd[1]: Starting Remote File Systems.
>> [  OK  ] Reached target Remote File Systems.
>> systemd[1]: Reached target Remote File Systems.
>> systemd[1]: Set up automount Arbitrary Executable File Formats File
>> System Automount Point.
>> systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
>> systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
>> systemd[1]: Starting Paths.
>> [  OK  ] Reached target Paths.
>> systemd[1]: Reached target Paths.
>> systemd[1]: Starting Swap.
>> [  OK  ] Reached target Swap.
>> systemd[1]: Reached target Swap.
>> systemd[1]: Starting Root Slice.
>> [  OK  ] Created slice Root Slice.
>> systemd[1]: Created slice Root Slice.
>> systemd[1]: Starting udev Kernel Socket.
>> [  OK  ] Listening on udev Kernel Socket.
>> systemd[1]: Listening on udev Kernel Socket.
>> systemd[1]: Starting Journal Socket.
>> [  OK  ] Listening on Journal Socket.
>> systemd[1]: Listening on Journal Socket.
>> systemd[1]: Starting LVM2 metadata daemon socket.
>> [  OK  ] Listening on LVM2 metadata daemon socket.
>> systemd[1]: Listening on LVM2 metadata daemon socket.
>> systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
>> [  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
>> systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
>> systemd[1]: Starting Delayed Shutdown Socket.
>> [  OK  ] Listening on Delayed Shutdown Socket.
>> systemd[1]: Listening on Delayed Shutdown Socket.
>> systemd[1]: Starting Syslog Socket.
>> [  OK  ] Listening on Syslog Socket.
>> systemd[1]: Listening on Syslog Socket.
>> systemd[1]: Starting User and Session Slice.
>> [  OK  ] Created slice User and Session Slice.
>> systemd[1]: Created slice User and Session Slice.
>> systemd[1]: Starting System Slice.
>> [  OK  ] Created slice System Slice.
>> systemd[1]: Created slice System Slice.
>> systemd[1]: Started Create list of required static device nodes for
>> the current kernel.
>> systemd[1]: Starting Create static device nodes in /dev...
>>          Starting Create static device nodes in /dev...
>> systemd[1]: Mounting POSIX Message Queue File System...
>>          Mounting POSIX Message Queue File System...
>> systemd[1]: Mounting Debug File System...
>>          Mounting Debug File System...
>> systemd[1]: Mounting Huge Pages File System...
>>          Mounting Huge Pages File System...
>> systemd[1]: Starting Journal Service...
>>          Starting Journal Service...
>> [  OK  ] Started Journal Service.
>> systemd[1]: Started Journal Service.
>> [  OK  ] Created slice system-serial\x2dgetty.slice.
>> [  OK  ] Created slice system-getty.slice.
>>          Starting LVM2 metadata daemon...
>>          Starting Load Kernel Modules...
>>          Starting Setup Virtual Console...
>>          Starting Remount Root and Kernel File Systems...
>>          Starting Create dynamic rule for /dev/root link...
>> [  OK  ] Reached target Slices.
>> [  OK  ] Listening on udev Control Socket.
>> [  OK  ] Mounted Huge Pages File System.
>> [  OK  ] Mounted Debug File System.
>> [  OK  ] Mounted POSIX Message Queue File System.
>> [  OK  ] Started Create static device nodes in /dev.
>> [  OK  ] Started LVM2 metadata daemon.
>> [FAILED] Failed to start Load Kernel Modules.
>> See "systemctl status systemd-modules-load.service" for details.
>> [  OK  ] Started Setup Virtual Console.
>> [  OK  ] Started Remount Root and Kernel File Systems.
>> [  OK  ] Started Create dynamic rule for /dev/root link.
>>          Starting Load/Save Random Seed...
>>          Starting udev Coldplug all Devices...
>>          Starting Apply Kernel Variables...
>>          Mounting FUSE Control File System...
>>          Starting udev Kernel Device Manager...
>> [  OK  ] Reached target Local File Systems (Pre).
>>          Mounting Runtime Directory...
>> [  OK  ] Mounted FUSE Control File System.
>> [  OK  ] Mounted Runtime Directory.
>> [  OK  ] Started udev Kernel Device Manager.
>> [  OK  ] Started Load/Save Random Seed.
>> [  OK  ] Started Apply Kernel Variables.
>> [  OK  ] Started udev Coldplug all Devices.
>> thunder-nicvf 0002:01:00.3 enP2p1s0f3: renamed from eth2
>>          Starting udev Wait for Complete Device Initialization...
>> thunder-nicvf 0002:01:00.1 enP2p1s0f1: renamed from eth0
>> thunder-nicvf 0002:01:00.2 enP2p1s0f2: renamed from eth1
>> thunder-nicvf 0002:01:00.4 enP2p1s0f4: renamed from eth3
>> [  OK  ] Started udev Wait for Complete Device Initialization.
>>          Starting Activation of LVM2 logical volumes...
>> [  OK  ] Started Activation of LVM2 logical volumes.
>> [  OK  ] Reached target Encrypted Volumes.
>>          Starting Activation of LVM2 logical volumes...
>> [  OK  ] Started Activation of LVM2 logical volumes.
>> [  OK  ] Reached target Local File Systems.
>>          Starting Trigger Flushing of Journal to Persistent Storage...
>>          Starting Create Volatile Files and Directories...
>> systemd-journald[884]: Received request to flush runtime journal from PID 1
>> [  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
>> [  OK  ] Started Create Volatile Files and Directories.
>>          Starting Update UTMP about System Reboot/Shutdown...
>> [  OK  ] Started Update UTMP about System Reboot/Shutdown.
>> [  OK  ] Reached target System Initialization.
>> [  OK  ] Listening on D-Bus System Message Bus Socket.
>> [  OK  ] Reached target Sockets.
>> [  OK  ] Reached target Timers.
>>          Starting Restore Sound Card State...
>> [  OK  ] Reached target Basic System.
>>          Starting Permit User Sessions...
>>          Starting /etc/init.d/boot.local Compatibility...
>>          Starting System Logging Service...
>>          Starting Purge old kernels...
>>          Starting Login Service...
>>          Starting D-Bus System Message Bus...
>> [  OK  ] Started D-Bus System Message Bus.
>>          Starting wicked DHCPv4 supplicant service...
>>          Starting wicked AutoIPv4 supplicant service...
>>          Starting wicked DHCPv6 supplicant service...
>> [  OK  ] Started Restore Sound Card State.
>> [  OK  ] Started Permit User Sessions.
>> [  OK  ] Started /etc/init.d/boot.local Compatibility.
>> [  OK  ] Started wicked AutoIPv4 supplicant service.
>> [  OK  ] Started wicked DHCPv6 supplicant service.
>> [  OK  ] Started wicked DHCPv4 supplicant service.
>> [  OK  ] Started Login Service.
>>          Starting wicked network management service daemon...
>>          Starting Getty on tty1...
>> [  OK  ] Started Getty on tty1.
>> [  OK  ] Started System Logging Service.
>> [  OK  ] Started wicked network management service daemon.
>>          Starting wicked network nanny service...
>> [  OK  ] Started wicked network nanny service.
>>          Starting wicked managed network interfaces...
>> [  OK  ] Started Purge old kernels.
>> [  OK  ] Started wicked managed network interfaces.
>> [  OK  ] Reached target Network.
>>          Starting OpenSSH Daemon...
>>          Starting NTP Server Daemon...
>> [  OK  ] Started NTP Server Daemon.
>> [  OK  ] Started OpenSSH Daemon.
>> [ TIME ] Timed out waiting for device dev-hvc0.device.
>> [DEPEND] Dependency failed for Serial Getty on hvc0.
>> [  OK  ] Reached target Login Prompts.
>>          Starting /etc/init.d/after.local Compatibility...
>> [  OK  ] Started /etc/init.d/after.local Compatibility.
>> [  OK  ] Reached target Multi-User System.
>> [  OK  ] Reached target Graphical Interface.
>>
>>
>> Alex,any idea how to look for what is causing timeout ?
>> Grep -rn hcv0 in suse file system resulted nil.
>> I am using https://wiki.linaro.org/LEG/Engineering/Xen_booting_on_Foundationv8
>
> Hrm, does your kernel have devtmpfs support enabled? Apparently SSH did
> come up, can you try to log in via ssh and see whether you can see an
> hvc0 device node in /dev?
>
>
> Alex
I cant, as I have to do dhcpcd post login. I dont see dev-hvc0 in
other rootfs. Is it required for xen or can be it be disabled ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 01:21:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 01: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 1XzEuW-0004nz-4t; Fri, 12 Dec 2014 01:20:48 +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 1XzEuU-0004nu-Ij
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 01:20:46 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	D4/C6-02712-DE24A845; Fri, 12 Dec 2014 01:20:45 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418347243!14549853!1
X-Originating-IP: [209.85.192.42]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10588 invoked from network); 12 Dec 2014 01:20:44 -0000
Received: from mail-qg0-f42.google.com (HELO mail-qg0-f42.google.com)
	(209.85.192.42)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 01:20:44 -0000
Received: by mail-qg0-f42.google.com with SMTP id q108so2745731qgd.29
	for <xen-devel@lists.xen.org>; Thu, 11 Dec 2014 17:20:43 -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=sPZZPc3o3Y6cTokPK8lzV6EfpdyauV47ex6UPAcf04k=;
	b=v+PRqFuXWS/N1QsODJsaTCSVYKmLj8AZ+9rLDMPmRv6mkVt6SODenKV42TI20ZxYID
	EO6WOFM95cYjQQRN0f9ZbWFrK0Heey60kRj1TtWMDQ4l0FS4Kz5XpSTqdg1LPqsBJLKt
	/uCUsM61C6a05iqrEuI5XA8xIuB6QhSrfRi7mYH2cYvk8fztaGLGZT/DTKzbzHXSo20k
	DwBUdO6lS0bsGRbJKuTexs4Am8CFUAGg5nm0YaLb/rCldBjbFMZ3hHJDG3/h7mej9rp8
	ECbTv0BhWtA6Q6vmZhD5Muf4vuGksbnBcZ/vvphJKmAmkpBzibTG2Jvjg6t7TsX9rKrt
	gQSg==
MIME-Version: 1.0
X-Received: by 10.140.31.166 with SMTP id f35mr24941640qgf.66.1418347243254;
	Thu, 11 Dec 2014 17:20:43 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Thu, 11 Dec 2014 17:20:43 -0800 (PST)
In-Reply-To: <548A37A9.1010006@suse.de>
References: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>
	<54897098.3070009@linaro.org>
	<CAAiw7Jk2xmpWo-Dv8KLb4sSoU4PhCuj-iDeVPJU7xHoR+Wsxag@mail.gmail.com>
	<548A37A9.1010006@suse.de>
Date: Thu, 11 Dec 2014 17:20:43 -0800
Message-ID: <CAAiw7JkV-T+WP4kspGAgBhGr8UKcVT=ySO63VLv3RFGJs7RQSg@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: Alexander Graf <agraf@suse.de>
Cc: manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Timed out waiting for device dev-hvc0.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 11 December 2014 at 16:32, Alexander Graf <agraf@suse.de> wrote:
>
>
> On 12.12.14 01:25, manish jaggi wrote:
>> On 11 December 2014 at 02:23, Julien Grall <julien.grall@linaro.org> wrote:
>>> Hello,
>>>
>>>
>>> On 11/12/2014 02:27, manish jaggi wrote:
>>>>
>>>> I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)
>>>>
>>>> ...
>>>>
>>>> [  OK  ] Reached target Host and Network Name Lookups.
>>>> [  OK  ] Started OpenSSH Daemon.
>>>> [ TIME ] Timed out waiting for device dev-hvc0.device.
>>>> [DEPEND] Dependency failed for Serial Getty on hvc0.
>>>> [  OK  ] Reached target Login Prompts.
>>>>
>>>>
>>>> Any Idea? what could be wrong here
>>>
>>>
>>> Please provide the full boot log. With only those 5 lines we can only guess
>>> what could be the issue.
>>>
>> Added
>>> Maybe the DOM0 kernel didn't detect that it's running on Xen or you forgot
>>> to enable CONFIG_XEN_HVC in your config.
>> That is already enabled.
>> FYI with other rootfs I dont see any problem.
>>>
>>> Regards,
>>>
>>> --
>>> Julien Grall
>>
>> [... Std linux boot log .. ]
>> kjournald starting.  Commit interval 5 seconds
>> EXT3-fs (sda2): using internal journal
>> EXT3-fs (sda2): mounted filesystem with writeback data mode
>> VFS: Mounted root (ext3 filesystem) on device 8:2.
>> devtmpfs: mounted
>> Freeing unused kernel memory: 236K (ffffffc000789000 - ffffffc0007c4000)
>> random: systemd urandom read with 4 bits of entropy available
>> systemd[1]: systemd 210 running in system mode. (+PAM -LIBWRAP +AUDIT
>> +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP
>> +APPARMOR)
>> systemd[1]: Detected virtualization 'xen'.
>> systemd[1]: Detected architecture 'arm64'.
>>
>> Welcome to openSUSE 13.2 (Harlequin) (aarch64)!
>>
>> systemd[1]: Failed to insert module 'autofs4'
>> systemd[1]: Failed to insert module 'ipv6'
>> systemd[1]: Set hostname to <linux>.
>> systemd[1]: Cannot add dependency job for unit
>> display-manager.service, ignoring: Unit display-manager.service failed
>> to load: No such file or directory.
>> systemd[1]: Expecting device dev-hvc0.device...
>>          Expecting device dev-hvc0.device...
>> systemd[1]: Starting Remote File Systems (Pre).
>> [  OK  ] Reached target Remote File Systems (Pre).
>> systemd[1]: Reached target Remote File Systems (Pre).
>> systemd[1]: Starting Remote File Systems.
>> [  OK  ] Reached target Remote File Systems.
>> systemd[1]: Reached target Remote File Systems.
>> systemd[1]: Set up automount Arbitrary Executable File Formats File
>> System Automount Point.
>> systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
>> systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
>> systemd[1]: Starting Paths.
>> [  OK  ] Reached target Paths.
>> systemd[1]: Reached target Paths.
>> systemd[1]: Starting Swap.
>> [  OK  ] Reached target Swap.
>> systemd[1]: Reached target Swap.
>> systemd[1]: Starting Root Slice.
>> [  OK  ] Created slice Root Slice.
>> systemd[1]: Created slice Root Slice.
>> systemd[1]: Starting udev Kernel Socket.
>> [  OK  ] Listening on udev Kernel Socket.
>> systemd[1]: Listening on udev Kernel Socket.
>> systemd[1]: Starting Journal Socket.
>> [  OK  ] Listening on Journal Socket.
>> systemd[1]: Listening on Journal Socket.
>> systemd[1]: Starting LVM2 metadata daemon socket.
>> [  OK  ] Listening on LVM2 metadata daemon socket.
>> systemd[1]: Listening on LVM2 metadata daemon socket.
>> systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
>> [  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
>> systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
>> systemd[1]: Starting Delayed Shutdown Socket.
>> [  OK  ] Listening on Delayed Shutdown Socket.
>> systemd[1]: Listening on Delayed Shutdown Socket.
>> systemd[1]: Starting Syslog Socket.
>> [  OK  ] Listening on Syslog Socket.
>> systemd[1]: Listening on Syslog Socket.
>> systemd[1]: Starting User and Session Slice.
>> [  OK  ] Created slice User and Session Slice.
>> systemd[1]: Created slice User and Session Slice.
>> systemd[1]: Starting System Slice.
>> [  OK  ] Created slice System Slice.
>> systemd[1]: Created slice System Slice.
>> systemd[1]: Started Create list of required static device nodes for
>> the current kernel.
>> systemd[1]: Starting Create static device nodes in /dev...
>>          Starting Create static device nodes in /dev...
>> systemd[1]: Mounting POSIX Message Queue File System...
>>          Mounting POSIX Message Queue File System...
>> systemd[1]: Mounting Debug File System...
>>          Mounting Debug File System...
>> systemd[1]: Mounting Huge Pages File System...
>>          Mounting Huge Pages File System...
>> systemd[1]: Starting Journal Service...
>>          Starting Journal Service...
>> [  OK  ] Started Journal Service.
>> systemd[1]: Started Journal Service.
>> [  OK  ] Created slice system-serial\x2dgetty.slice.
>> [  OK  ] Created slice system-getty.slice.
>>          Starting LVM2 metadata daemon...
>>          Starting Load Kernel Modules...
>>          Starting Setup Virtual Console...
>>          Starting Remount Root and Kernel File Systems...
>>          Starting Create dynamic rule for /dev/root link...
>> [  OK  ] Reached target Slices.
>> [  OK  ] Listening on udev Control Socket.
>> [  OK  ] Mounted Huge Pages File System.
>> [  OK  ] Mounted Debug File System.
>> [  OK  ] Mounted POSIX Message Queue File System.
>> [  OK  ] Started Create static device nodes in /dev.
>> [  OK  ] Started LVM2 metadata daemon.
>> [FAILED] Failed to start Load Kernel Modules.
>> See "systemctl status systemd-modules-load.service" for details.
>> [  OK  ] Started Setup Virtual Console.
>> [  OK  ] Started Remount Root and Kernel File Systems.
>> [  OK  ] Started Create dynamic rule for /dev/root link.
>>          Starting Load/Save Random Seed...
>>          Starting udev Coldplug all Devices...
>>          Starting Apply Kernel Variables...
>>          Mounting FUSE Control File System...
>>          Starting udev Kernel Device Manager...
>> [  OK  ] Reached target Local File Systems (Pre).
>>          Mounting Runtime Directory...
>> [  OK  ] Mounted FUSE Control File System.
>> [  OK  ] Mounted Runtime Directory.
>> [  OK  ] Started udev Kernel Device Manager.
>> [  OK  ] Started Load/Save Random Seed.
>> [  OK  ] Started Apply Kernel Variables.
>> [  OK  ] Started udev Coldplug all Devices.
>> thunder-nicvf 0002:01:00.3 enP2p1s0f3: renamed from eth2
>>          Starting udev Wait for Complete Device Initialization...
>> thunder-nicvf 0002:01:00.1 enP2p1s0f1: renamed from eth0
>> thunder-nicvf 0002:01:00.2 enP2p1s0f2: renamed from eth1
>> thunder-nicvf 0002:01:00.4 enP2p1s0f4: renamed from eth3
>> [  OK  ] Started udev Wait for Complete Device Initialization.
>>          Starting Activation of LVM2 logical volumes...
>> [  OK  ] Started Activation of LVM2 logical volumes.
>> [  OK  ] Reached target Encrypted Volumes.
>>          Starting Activation of LVM2 logical volumes...
>> [  OK  ] Started Activation of LVM2 logical volumes.
>> [  OK  ] Reached target Local File Systems.
>>          Starting Trigger Flushing of Journal to Persistent Storage...
>>          Starting Create Volatile Files and Directories...
>> systemd-journald[884]: Received request to flush runtime journal from PID 1
>> [  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
>> [  OK  ] Started Create Volatile Files and Directories.
>>          Starting Update UTMP about System Reboot/Shutdown...
>> [  OK  ] Started Update UTMP about System Reboot/Shutdown.
>> [  OK  ] Reached target System Initialization.
>> [  OK  ] Listening on D-Bus System Message Bus Socket.
>> [  OK  ] Reached target Sockets.
>> [  OK  ] Reached target Timers.
>>          Starting Restore Sound Card State...
>> [  OK  ] Reached target Basic System.
>>          Starting Permit User Sessions...
>>          Starting /etc/init.d/boot.local Compatibility...
>>          Starting System Logging Service...
>>          Starting Purge old kernels...
>>          Starting Login Service...
>>          Starting D-Bus System Message Bus...
>> [  OK  ] Started D-Bus System Message Bus.
>>          Starting wicked DHCPv4 supplicant service...
>>          Starting wicked AutoIPv4 supplicant service...
>>          Starting wicked DHCPv6 supplicant service...
>> [  OK  ] Started Restore Sound Card State.
>> [  OK  ] Started Permit User Sessions.
>> [  OK  ] Started /etc/init.d/boot.local Compatibility.
>> [  OK  ] Started wicked AutoIPv4 supplicant service.
>> [  OK  ] Started wicked DHCPv6 supplicant service.
>> [  OK  ] Started wicked DHCPv4 supplicant service.
>> [  OK  ] Started Login Service.
>>          Starting wicked network management service daemon...
>>          Starting Getty on tty1...
>> [  OK  ] Started Getty on tty1.
>> [  OK  ] Started System Logging Service.
>> [  OK  ] Started wicked network management service daemon.
>>          Starting wicked network nanny service...
>> [  OK  ] Started wicked network nanny service.
>>          Starting wicked managed network interfaces...
>> [  OK  ] Started Purge old kernels.
>> [  OK  ] Started wicked managed network interfaces.
>> [  OK  ] Reached target Network.
>>          Starting OpenSSH Daemon...
>>          Starting NTP Server Daemon...
>> [  OK  ] Started NTP Server Daemon.
>> [  OK  ] Started OpenSSH Daemon.
>> [ TIME ] Timed out waiting for device dev-hvc0.device.
>> [DEPEND] Dependency failed for Serial Getty on hvc0.
>> [  OK  ] Reached target Login Prompts.
>>          Starting /etc/init.d/after.local Compatibility...
>> [  OK  ] Started /etc/init.d/after.local Compatibility.
>> [  OK  ] Reached target Multi-User System.
>> [  OK  ] Reached target Graphical Interface.
>>
>>
>> Alex,any idea how to look for what is causing timeout ?
>> Grep -rn hcv0 in suse file system resulted nil.
>> I am using https://wiki.linaro.org/LEG/Engineering/Xen_booting_on_Foundationv8
>
> Hrm, does your kernel have devtmpfs support enabled? Apparently SSH did
> come up, can you try to log in via ssh and see whether you can see an
> hvc0 device node in /dev?
>
>
> Alex
I cant, as I have to do dhcpcd post login. I dont see dev-hvc0 in
other rootfs. Is it required for xen or can be it be disabled ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 01:27:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 01:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzF0G-0005HT-UX; Fri, 12 Dec 2014 01:26:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1XzF0F-0005HM-J6
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 01:26:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	65/1A-15461-2544A845; Fri, 12 Dec 2014 01:26:42 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418347601!15080230!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 24639 invoked from network); 12 Dec 2014 01:26:41 -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; 12 Dec 2014 01:26:41 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id E794CABC6;
	Fri, 12 Dec 2014 01:26:40 +0000 (UTC)
Message-ID: <548A444F.3080707@suse.de>
Date: Fri, 12 Dec 2014 02:26:39 +0100
From: Alexander Graf <agraf@suse.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>
References: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>	<54897098.3070009@linaro.org>	<CAAiw7Jk2xmpWo-Dv8KLb4sSoU4PhCuj-iDeVPJU7xHoR+Wsxag@mail.gmail.com>	<548A37A9.1010006@suse.de>
	<CAAiw7JkV-T+WP4kspGAgBhGr8UKcVT=ySO63VLv3RFGJs7RQSg@mail.gmail.com>
In-Reply-To: <CAAiw7JkV-T+WP4kspGAgBhGr8UKcVT=ySO63VLv3RFGJs7RQSg@mail.gmail.com>
Cc: manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Timed out waiting for device dev-hvc0.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 12.12.14 02:20, manish jaggi wrote:
> On 11 December 2014 at 16:32, Alexander Graf <agraf@suse.de> wrote:
>>
>>
>> On 12.12.14 01:25, manish jaggi wrote:
>>> On 11 December 2014 at 02:23, Julien Grall <julien.grall@linaro.org> wrote:
>>>> Hello,
>>>>
>>>>
>>>> On 11/12/2014 02:27, manish jaggi wrote:
>>>>>
>>>>> I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)
>>>>>
>>>>> ...
>>>>>
>>>>> [  OK  ] Reached target Host and Network Name Lookups.
>>>>> [  OK  ] Started OpenSSH Daemon.
>>>>> [ TIME ] Timed out waiting for device dev-hvc0.device.
>>>>> [DEPEND] Dependency failed for Serial Getty on hvc0.
>>>>> [  OK  ] Reached target Login Prompts.
>>>>>
>>>>>
>>>>> Any Idea? what could be wrong here
>>>>
>>>>
>>>> Please provide the full boot log. With only those 5 lines we can only guess
>>>> what could be the issue.
>>>>
>>> Added
>>>> Maybe the DOM0 kernel didn't detect that it's running on Xen or you forgot
>>>> to enable CONFIG_XEN_HVC in your config.
>>> That is already enabled.
>>> FYI with other rootfs I dont see any problem.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Julien Grall
>>>
>>> [... Std linux boot log .. ]
>>> kjournald starting.  Commit interval 5 seconds
>>> EXT3-fs (sda2): using internal journal
>>> EXT3-fs (sda2): mounted filesystem with writeback data mode
>>> VFS: Mounted root (ext3 filesystem) on device 8:2.
>>> devtmpfs: mounted
>>> Freeing unused kernel memory: 236K (ffffffc000789000 - ffffffc0007c4000)
>>> random: systemd urandom read with 4 bits of entropy available
>>> systemd[1]: systemd 210 running in system mode. (+PAM -LIBWRAP +AUDIT
>>> +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP
>>> +APPARMOR)
>>> systemd[1]: Detected virtualization 'xen'.
>>> systemd[1]: Detected architecture 'arm64'.
>>>
>>> Welcome to openSUSE 13.2 (Harlequin) (aarch64)!
>>>
>>> systemd[1]: Failed to insert module 'autofs4'
>>> systemd[1]: Failed to insert module 'ipv6'
>>> systemd[1]: Set hostname to <linux>.
>>> systemd[1]: Cannot add dependency job for unit
>>> display-manager.service, ignoring: Unit display-manager.service failed
>>> to load: No such file or directory.
>>> systemd[1]: Expecting device dev-hvc0.device...
>>>          Expecting device dev-hvc0.device...
>>> systemd[1]: Starting Remote File Systems (Pre).
>>> [  OK  ] Reached target Remote File Systems (Pre).
>>> systemd[1]: Reached target Remote File Systems (Pre).
>>> systemd[1]: Starting Remote File Systems.
>>> [  OK  ] Reached target Remote File Systems.
>>> systemd[1]: Reached target Remote File Systems.
>>> systemd[1]: Set up automount Arbitrary Executable File Formats File
>>> System Automount Point.
>>> systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
>>> systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
>>> systemd[1]: Starting Paths.
>>> [  OK  ] Reached target Paths.
>>> systemd[1]: Reached target Paths.
>>> systemd[1]: Starting Swap.
>>> [  OK  ] Reached target Swap.
>>> systemd[1]: Reached target Swap.
>>> systemd[1]: Starting Root Slice.
>>> [  OK  ] Created slice Root Slice.
>>> systemd[1]: Created slice Root Slice.
>>> systemd[1]: Starting udev Kernel Socket.
>>> [  OK  ] Listening on udev Kernel Socket.
>>> systemd[1]: Listening on udev Kernel Socket.
>>> systemd[1]: Starting Journal Socket.
>>> [  OK  ] Listening on Journal Socket.
>>> systemd[1]: Listening on Journal Socket.
>>> systemd[1]: Starting LVM2 metadata daemon socket.
>>> [  OK  ] Listening on LVM2 metadata daemon socket.
>>> systemd[1]: Listening on LVM2 metadata daemon socket.
>>> systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
>>> [  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
>>> systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
>>> systemd[1]: Starting Delayed Shutdown Socket.
>>> [  OK  ] Listening on Delayed Shutdown Socket.
>>> systemd[1]: Listening on Delayed Shutdown Socket.
>>> systemd[1]: Starting Syslog Socket.
>>> [  OK  ] Listening on Syslog Socket.
>>> systemd[1]: Listening on Syslog Socket.
>>> systemd[1]: Starting User and Session Slice.
>>> [  OK  ] Created slice User and Session Slice.
>>> systemd[1]: Created slice User and Session Slice.
>>> systemd[1]: Starting System Slice.
>>> [  OK  ] Created slice System Slice.
>>> systemd[1]: Created slice System Slice.
>>> systemd[1]: Started Create list of required static device nodes for
>>> the current kernel.
>>> systemd[1]: Starting Create static device nodes in /dev...
>>>          Starting Create static device nodes in /dev...
>>> systemd[1]: Mounting POSIX Message Queue File System...
>>>          Mounting POSIX Message Queue File System...
>>> systemd[1]: Mounting Debug File System...
>>>          Mounting Debug File System...
>>> systemd[1]: Mounting Huge Pages File System...
>>>          Mounting Huge Pages File System...
>>> systemd[1]: Starting Journal Service...
>>>          Starting Journal Service...
>>> [  OK  ] Started Journal Service.
>>> systemd[1]: Started Journal Service.
>>> [  OK  ] Created slice system-serial\x2dgetty.slice.
>>> [  OK  ] Created slice system-getty.slice.
>>>          Starting LVM2 metadata daemon...
>>>          Starting Load Kernel Modules...
>>>          Starting Setup Virtual Console...
>>>          Starting Remount Root and Kernel File Systems...
>>>          Starting Create dynamic rule for /dev/root link...
>>> [  OK  ] Reached target Slices.
>>> [  OK  ] Listening on udev Control Socket.
>>> [  OK  ] Mounted Huge Pages File System.
>>> [  OK  ] Mounted Debug File System.
>>> [  OK  ] Mounted POSIX Message Queue File System.
>>> [  OK  ] Started Create static device nodes in /dev.
>>> [  OK  ] Started LVM2 metadata daemon.
>>> [FAILED] Failed to start Load Kernel Modules.
>>> See "systemctl status systemd-modules-load.service" for details.
>>> [  OK  ] Started Setup Virtual Console.
>>> [  OK  ] Started Remount Root and Kernel File Systems.
>>> [  OK  ] Started Create dynamic rule for /dev/root link.
>>>          Starting Load/Save Random Seed...
>>>          Starting udev Coldplug all Devices...
>>>          Starting Apply Kernel Variables...
>>>          Mounting FUSE Control File System...
>>>          Starting udev Kernel Device Manager...
>>> [  OK  ] Reached target Local File Systems (Pre).
>>>          Mounting Runtime Directory...
>>> [  OK  ] Mounted FUSE Control File System.
>>> [  OK  ] Mounted Runtime Directory.
>>> [  OK  ] Started udev Kernel Device Manager.
>>> [  OK  ] Started Load/Save Random Seed.
>>> [  OK  ] Started Apply Kernel Variables.
>>> [  OK  ] Started udev Coldplug all Devices.
>>> thunder-nicvf 0002:01:00.3 enP2p1s0f3: renamed from eth2
>>>          Starting udev Wait for Complete Device Initialization...
>>> thunder-nicvf 0002:01:00.1 enP2p1s0f1: renamed from eth0
>>> thunder-nicvf 0002:01:00.2 enP2p1s0f2: renamed from eth1
>>> thunder-nicvf 0002:01:00.4 enP2p1s0f4: renamed from eth3
>>> [  OK  ] Started udev Wait for Complete Device Initialization.
>>>          Starting Activation of LVM2 logical volumes...
>>> [  OK  ] Started Activation of LVM2 logical volumes.
>>> [  OK  ] Reached target Encrypted Volumes.
>>>          Starting Activation of LVM2 logical volumes...
>>> [  OK  ] Started Activation of LVM2 logical volumes.
>>> [  OK  ] Reached target Local File Systems.
>>>          Starting Trigger Flushing of Journal to Persistent Storage...
>>>          Starting Create Volatile Files and Directories...
>>> systemd-journald[884]: Received request to flush runtime journal from PID 1
>>> [  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
>>> [  OK  ] Started Create Volatile Files and Directories.
>>>          Starting Update UTMP about System Reboot/Shutdown...
>>> [  OK  ] Started Update UTMP about System Reboot/Shutdown.
>>> [  OK  ] Reached target System Initialization.
>>> [  OK  ] Listening on D-Bus System Message Bus Socket.
>>> [  OK  ] Reached target Sockets.
>>> [  OK  ] Reached target Timers.
>>>          Starting Restore Sound Card State...
>>> [  OK  ] Reached target Basic System.
>>>          Starting Permit User Sessions...
>>>          Starting /etc/init.d/boot.local Compatibility...
>>>          Starting System Logging Service...
>>>          Starting Purge old kernels...
>>>          Starting Login Service...
>>>          Starting D-Bus System Message Bus...
>>> [  OK  ] Started D-Bus System Message Bus.
>>>          Starting wicked DHCPv4 supplicant service...
>>>          Starting wicked AutoIPv4 supplicant service...
>>>          Starting wicked DHCPv6 supplicant service...
>>> [  OK  ] Started Restore Sound Card State.
>>> [  OK  ] Started Permit User Sessions.
>>> [  OK  ] Started /etc/init.d/boot.local Compatibility.
>>> [  OK  ] Started wicked AutoIPv4 supplicant service.
>>> [  OK  ] Started wicked DHCPv6 supplicant service.
>>> [  OK  ] Started wicked DHCPv4 supplicant service.
>>> [  OK  ] Started Login Service.
>>>          Starting wicked network management service daemon...
>>>          Starting Getty on tty1...
>>> [  OK  ] Started Getty on tty1.
>>> [  OK  ] Started System Logging Service.
>>> [  OK  ] Started wicked network management service daemon.
>>>          Starting wicked network nanny service...
>>> [  OK  ] Started wicked network nanny service.
>>>          Starting wicked managed network interfaces...
>>> [  OK  ] Started Purge old kernels.
>>> [  OK  ] Started wicked managed network interfaces.
>>> [  OK  ] Reached target Network.
>>>          Starting OpenSSH Daemon...
>>>          Starting NTP Server Daemon...
>>> [  OK  ] Started NTP Server Daemon.
>>> [  OK  ] Started OpenSSH Daemon.
>>> [ TIME ] Timed out waiting for device dev-hvc0.device.
>>> [DEPEND] Dependency failed for Serial Getty on hvc0.
>>> [  OK  ] Reached target Login Prompts.
>>>          Starting /etc/init.d/after.local Compatibility...
>>> [  OK  ] Started /etc/init.d/after.local Compatibility.
>>> [  OK  ] Reached target Multi-User System.
>>> [  OK  ] Reached target Graphical Interface.
>>>
>>>
>>> Alex,any idea how to look for what is causing timeout ?
>>> Grep -rn hcv0 in suse file system resulted nil.
>>> I am using https://wiki.linaro.org/LEG/Engineering/Xen_booting_on_Foundationv8
>>
>> Hrm, does your kernel have devtmpfs support enabled? Apparently SSH did
>> come up, can you try to log in via ssh and see whether you can see an
>> hvc0 device node in /dev?
>>
>>
>> Alex
> I cant, as I have to do dhcpcd post login. I dont see dev-hvc0 in
> other rootfs. Is it required for xen or can be it be disabled ?

It gets generated automatically based on the console=hvc0 command line
option you're passing into your kernel.

Something also believes that you do have a working graphical console (tty1).


Alex

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 01:27:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 01:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzF0G-0005HT-UX; Fri, 12 Dec 2014 01:26:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1XzF0F-0005HM-J6
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 01:26:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	65/1A-15461-2544A845; Fri, 12 Dec 2014 01:26:42 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418347601!15080230!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 24639 invoked from network); 12 Dec 2014 01:26:41 -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; 12 Dec 2014 01:26:41 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id E794CABC6;
	Fri, 12 Dec 2014 01:26:40 +0000 (UTC)
Message-ID: <548A444F.3080707@suse.de>
Date: Fri, 12 Dec 2014 02:26:39 +0100
From: Alexander Graf <agraf@suse.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>
References: <CAAiw7J=8+2H4817f2e4_LZ+29Enr0SB9m8EmzF-izkeU4_UdvQ@mail.gmail.com>	<54897098.3070009@linaro.org>	<CAAiw7Jk2xmpWo-Dv8KLb4sSoU4PhCuj-iDeVPJU7xHoR+Wsxag@mail.gmail.com>	<548A37A9.1010006@suse.de>
	<CAAiw7JkV-T+WP4kspGAgBhGr8UKcVT=ySO63VLv3RFGJs7RQSg@mail.gmail.com>
In-Reply-To: <CAAiw7JkV-T+WP4kspGAgBhGr8UKcVT=ySO63VLv3RFGJs7RQSg@mail.gmail.com>
Cc: manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Timed out waiting for device dev-hvc0.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 12.12.14 02:20, manish jaggi wrote:
> On 11 December 2014 at 16:32, Alexander Graf <agraf@suse.de> wrote:
>>
>>
>> On 12.12.14 01:25, manish jaggi wrote:
>>> On 11 December 2014 at 02:23, Julien Grall <julien.grall@linaro.org> wrote:
>>>> Hello,
>>>>
>>>>
>>>> On 11/12/2014 02:27, manish jaggi wrote:
>>>>>
>>>>> I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs)
>>>>>
>>>>> ...
>>>>>
>>>>> [  OK  ] Reached target Host and Network Name Lookups.
>>>>> [  OK  ] Started OpenSSH Daemon.
>>>>> [ TIME ] Timed out waiting for device dev-hvc0.device.
>>>>> [DEPEND] Dependency failed for Serial Getty on hvc0.
>>>>> [  OK  ] Reached target Login Prompts.
>>>>>
>>>>>
>>>>> Any Idea? what could be wrong here
>>>>
>>>>
>>>> Please provide the full boot log. With only those 5 lines we can only guess
>>>> what could be the issue.
>>>>
>>> Added
>>>> Maybe the DOM0 kernel didn't detect that it's running on Xen or you forgot
>>>> to enable CONFIG_XEN_HVC in your config.
>>> That is already enabled.
>>> FYI with other rootfs I dont see any problem.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Julien Grall
>>>
>>> [... Std linux boot log .. ]
>>> kjournald starting.  Commit interval 5 seconds
>>> EXT3-fs (sda2): using internal journal
>>> EXT3-fs (sda2): mounted filesystem with writeback data mode
>>> VFS: Mounted root (ext3 filesystem) on device 8:2.
>>> devtmpfs: mounted
>>> Freeing unused kernel memory: 236K (ffffffc000789000 - ffffffc0007c4000)
>>> random: systemd urandom read with 4 bits of entropy available
>>> systemd[1]: systemd 210 running in system mode. (+PAM -LIBWRAP +AUDIT
>>> +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP
>>> +APPARMOR)
>>> systemd[1]: Detected virtualization 'xen'.
>>> systemd[1]: Detected architecture 'arm64'.
>>>
>>> Welcome to openSUSE 13.2 (Harlequin) (aarch64)!
>>>
>>> systemd[1]: Failed to insert module 'autofs4'
>>> systemd[1]: Failed to insert module 'ipv6'
>>> systemd[1]: Set hostname to <linux>.
>>> systemd[1]: Cannot add dependency job for unit
>>> display-manager.service, ignoring: Unit display-manager.service failed
>>> to load: No such file or directory.
>>> systemd[1]: Expecting device dev-hvc0.device...
>>>          Expecting device dev-hvc0.device...
>>> systemd[1]: Starting Remote File Systems (Pre).
>>> [  OK  ] Reached target Remote File Systems (Pre).
>>> systemd[1]: Reached target Remote File Systems (Pre).
>>> systemd[1]: Starting Remote File Systems.
>>> [  OK  ] Reached target Remote File Systems.
>>> systemd[1]: Reached target Remote File Systems.
>>> systemd[1]: Set up automount Arbitrary Executable File Formats File
>>> System Automount Point.
>>> systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
>>> systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
>>> systemd[1]: Starting Paths.
>>> [  OK  ] Reached target Paths.
>>> systemd[1]: Reached target Paths.
>>> systemd[1]: Starting Swap.
>>> [  OK  ] Reached target Swap.
>>> systemd[1]: Reached target Swap.
>>> systemd[1]: Starting Root Slice.
>>> [  OK  ] Created slice Root Slice.
>>> systemd[1]: Created slice Root Slice.
>>> systemd[1]: Starting udev Kernel Socket.
>>> [  OK  ] Listening on udev Kernel Socket.
>>> systemd[1]: Listening on udev Kernel Socket.
>>> systemd[1]: Starting Journal Socket.
>>> [  OK  ] Listening on Journal Socket.
>>> systemd[1]: Listening on Journal Socket.
>>> systemd[1]: Starting LVM2 metadata daemon socket.
>>> [  OK  ] Listening on LVM2 metadata daemon socket.
>>> systemd[1]: Listening on LVM2 metadata daemon socket.
>>> systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
>>> [  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
>>> systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
>>> systemd[1]: Starting Delayed Shutdown Socket.
>>> [  OK  ] Listening on Delayed Shutdown Socket.
>>> systemd[1]: Listening on Delayed Shutdown Socket.
>>> systemd[1]: Starting Syslog Socket.
>>> [  OK  ] Listening on Syslog Socket.
>>> systemd[1]: Listening on Syslog Socket.
>>> systemd[1]: Starting User and Session Slice.
>>> [  OK  ] Created slice User and Session Slice.
>>> systemd[1]: Created slice User and Session Slice.
>>> systemd[1]: Starting System Slice.
>>> [  OK  ] Created slice System Slice.
>>> systemd[1]: Created slice System Slice.
>>> systemd[1]: Started Create list of required static device nodes for
>>> the current kernel.
>>> systemd[1]: Starting Create static device nodes in /dev...
>>>          Starting Create static device nodes in /dev...
>>> systemd[1]: Mounting POSIX Message Queue File System...
>>>          Mounting POSIX Message Queue File System...
>>> systemd[1]: Mounting Debug File System...
>>>          Mounting Debug File System...
>>> systemd[1]: Mounting Huge Pages File System...
>>>          Mounting Huge Pages File System...
>>> systemd[1]: Starting Journal Service...
>>>          Starting Journal Service...
>>> [  OK  ] Started Journal Service.
>>> systemd[1]: Started Journal Service.
>>> [  OK  ] Created slice system-serial\x2dgetty.slice.
>>> [  OK  ] Created slice system-getty.slice.
>>>          Starting LVM2 metadata daemon...
>>>          Starting Load Kernel Modules...
>>>          Starting Setup Virtual Console...
>>>          Starting Remount Root and Kernel File Systems...
>>>          Starting Create dynamic rule for /dev/root link...
>>> [  OK  ] Reached target Slices.
>>> [  OK  ] Listening on udev Control Socket.
>>> [  OK  ] Mounted Huge Pages File System.
>>> [  OK  ] Mounted Debug File System.
>>> [  OK  ] Mounted POSIX Message Queue File System.
>>> [  OK  ] Started Create static device nodes in /dev.
>>> [  OK  ] Started LVM2 metadata daemon.
>>> [FAILED] Failed to start Load Kernel Modules.
>>> See "systemctl status systemd-modules-load.service" for details.
>>> [  OK  ] Started Setup Virtual Console.
>>> [  OK  ] Started Remount Root and Kernel File Systems.
>>> [  OK  ] Started Create dynamic rule for /dev/root link.
>>>          Starting Load/Save Random Seed...
>>>          Starting udev Coldplug all Devices...
>>>          Starting Apply Kernel Variables...
>>>          Mounting FUSE Control File System...
>>>          Starting udev Kernel Device Manager...
>>> [  OK  ] Reached target Local File Systems (Pre).
>>>          Mounting Runtime Directory...
>>> [  OK  ] Mounted FUSE Control File System.
>>> [  OK  ] Mounted Runtime Directory.
>>> [  OK  ] Started udev Kernel Device Manager.
>>> [  OK  ] Started Load/Save Random Seed.
>>> [  OK  ] Started Apply Kernel Variables.
>>> [  OK  ] Started udev Coldplug all Devices.
>>> thunder-nicvf 0002:01:00.3 enP2p1s0f3: renamed from eth2
>>>          Starting udev Wait for Complete Device Initialization...
>>> thunder-nicvf 0002:01:00.1 enP2p1s0f1: renamed from eth0
>>> thunder-nicvf 0002:01:00.2 enP2p1s0f2: renamed from eth1
>>> thunder-nicvf 0002:01:00.4 enP2p1s0f4: renamed from eth3
>>> [  OK  ] Started udev Wait for Complete Device Initialization.
>>>          Starting Activation of LVM2 logical volumes...
>>> [  OK  ] Started Activation of LVM2 logical volumes.
>>> [  OK  ] Reached target Encrypted Volumes.
>>>          Starting Activation of LVM2 logical volumes...
>>> [  OK  ] Started Activation of LVM2 logical volumes.
>>> [  OK  ] Reached target Local File Systems.
>>>          Starting Trigger Flushing of Journal to Persistent Storage...
>>>          Starting Create Volatile Files and Directories...
>>> systemd-journald[884]: Received request to flush runtime journal from PID 1
>>> [  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
>>> [  OK  ] Started Create Volatile Files and Directories.
>>>          Starting Update UTMP about System Reboot/Shutdown...
>>> [  OK  ] Started Update UTMP about System Reboot/Shutdown.
>>> [  OK  ] Reached target System Initialization.
>>> [  OK  ] Listening on D-Bus System Message Bus Socket.
>>> [  OK  ] Reached target Sockets.
>>> [  OK  ] Reached target Timers.
>>>          Starting Restore Sound Card State...
>>> [  OK  ] Reached target Basic System.
>>>          Starting Permit User Sessions...
>>>          Starting /etc/init.d/boot.local Compatibility...
>>>          Starting System Logging Service...
>>>          Starting Purge old kernels...
>>>          Starting Login Service...
>>>          Starting D-Bus System Message Bus...
>>> [  OK  ] Started D-Bus System Message Bus.
>>>          Starting wicked DHCPv4 supplicant service...
>>>          Starting wicked AutoIPv4 supplicant service...
>>>          Starting wicked DHCPv6 supplicant service...
>>> [  OK  ] Started Restore Sound Card State.
>>> [  OK  ] Started Permit User Sessions.
>>> [  OK  ] Started /etc/init.d/boot.local Compatibility.
>>> [  OK  ] Started wicked AutoIPv4 supplicant service.
>>> [  OK  ] Started wicked DHCPv6 supplicant service.
>>> [  OK  ] Started wicked DHCPv4 supplicant service.
>>> [  OK  ] Started Login Service.
>>>          Starting wicked network management service daemon...
>>>          Starting Getty on tty1...
>>> [  OK  ] Started Getty on tty1.
>>> [  OK  ] Started System Logging Service.
>>> [  OK  ] Started wicked network management service daemon.
>>>          Starting wicked network nanny service...
>>> [  OK  ] Started wicked network nanny service.
>>>          Starting wicked managed network interfaces...
>>> [  OK  ] Started Purge old kernels.
>>> [  OK  ] Started wicked managed network interfaces.
>>> [  OK  ] Reached target Network.
>>>          Starting OpenSSH Daemon...
>>>          Starting NTP Server Daemon...
>>> [  OK  ] Started NTP Server Daemon.
>>> [  OK  ] Started OpenSSH Daemon.
>>> [ TIME ] Timed out waiting for device dev-hvc0.device.
>>> [DEPEND] Dependency failed for Serial Getty on hvc0.
>>> [  OK  ] Reached target Login Prompts.
>>>          Starting /etc/init.d/after.local Compatibility...
>>> [  OK  ] Started /etc/init.d/after.local Compatibility.
>>> [  OK  ] Reached target Multi-User System.
>>> [  OK  ] Reached target Graphical Interface.
>>>
>>>
>>> Alex,any idea how to look for what is causing timeout ?
>>> Grep -rn hcv0 in suse file system resulted nil.
>>> I am using https://wiki.linaro.org/LEG/Engineering/Xen_booting_on_Foundationv8
>>
>> Hrm, does your kernel have devtmpfs support enabled? Apparently SSH did
>> come up, can you try to log in via ssh and see whether you can see an
>> hvc0 device node in /dev?
>>
>>
>> Alex
> I cant, as I have to do dhcpcd post login. I dont see dev-hvc0 in
> other rootfs. Is it required for xen or can be it be disabled ?

It gets generated automatically based on the console=hvc0 command line
option you're passing into your kernel.

Something also believes that you do have a working graphical console (tty1).


Alex

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 06:08:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 06: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 1XzJO7-0006Pm-RF; Fri, 12 Dec 2014 06:07:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XzJO6-0006Ph-0B
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 06:07:38 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	61/31-27584-9268A845; Fri, 12 Dec 2014 06:07:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418364454!8817723!1
X-Originating-IP: [66.165.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 1927 invoked from network); 12 Dec 2014 06:07:35 -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 Dec 2014 06:07:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,561,1413244800"; d="scan'208";a="203334871"
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.210.2; Fri, 12 Dec 2014 01:07: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 1XzJO0-0003DY-Hq;
	Fri, 12 Dec 2014 06:07:32 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzJO0-0002MZ-B6;
	Fri, 12 Dec 2014 06:07:32 +0000
Date: Fri, 12 Dec 2014 06:07:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32272-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8341
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32272: 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="===============3454242083316215004=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3454242083316215004==
Content-Type: text/plain
Content-Length: 8070
Content-Transfer-Encoding: quoted-printable

flight 32272 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32272/

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              82977058f5b1d143a355079900029e9cbfee2fe4
baseline version:
 libvirt              ab8715506facc6a6d1e08b16b32f58a4c7bcfdcb

------------------------------------------------------------
People who touched revisions under test:
  C=C3=A9dric Bosdonnat <cbosdonnat@suse.com>
  Hao Liu <hliu@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Laine Stump <laine@laine.org>
  Martin Kletzander <mkletzan@redhat.com>
  Matthew Rosato <mjrosato@linux.vnet.ibm.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=3D82977058f5b1d143a355079900029e9cbfee2fe4
+ . 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 82977058f5b1d143a355079900029e9cbfee2fe4
+ branch=3Dlibvirt
+ revision=3D82977058f5b1d143a355079900029e9cbfee2fe4
+ . 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 82977058f5b1d143a355079900029e9cbfee2fe4:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   ab87155..8297705  82977058f5b1d143a355079900029e9cbfee2fe4 -> xen-tested-master


--===============3454242083316215004==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3454242083316215004==--

From xen-devel-bounces@lists.xen.org Fri Dec 12 06:08:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 06: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 1XzJO7-0006Pm-RF; Fri, 12 Dec 2014 06:07:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XzJO6-0006Ph-0B
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 06:07:38 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	61/31-27584-9268A845; Fri, 12 Dec 2014 06:07:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418364454!8817723!1
X-Originating-IP: [66.165.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 1927 invoked from network); 12 Dec 2014 06:07:35 -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 Dec 2014 06:07:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,561,1413244800"; d="scan'208";a="203334871"
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.210.2; Fri, 12 Dec 2014 01:07: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 1XzJO0-0003DY-Hq;
	Fri, 12 Dec 2014 06:07:32 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzJO0-0002MZ-B6;
	Fri, 12 Dec 2014 06:07:32 +0000
Date: Fri, 12 Dec 2014 06:07:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32272-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8341
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32272: 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="===============3454242083316215004=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3454242083316215004==
Content-Type: text/plain
Content-Length: 8070
Content-Transfer-Encoding: quoted-printable

flight 32272 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32272/

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              82977058f5b1d143a355079900029e9cbfee2fe4
baseline version:
 libvirt              ab8715506facc6a6d1e08b16b32f58a4c7bcfdcb

------------------------------------------------------------
People who touched revisions under test:
  C=C3=A9dric Bosdonnat <cbosdonnat@suse.com>
  Hao Liu <hliu@redhat.com>
  John Ferlan <jferlan@redhat.com>
  Laine Stump <laine@laine.org>
  Martin Kletzander <mkletzan@redhat.com>
  Matthew Rosato <mjrosato@linux.vnet.ibm.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=3D82977058f5b1d143a355079900029e9cbfee2fe4
+ . 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 82977058f5b1d143a355079900029e9cbfee2fe4
+ branch=3Dlibvirt
+ revision=3D82977058f5b1d143a355079900029e9cbfee2fe4
+ . 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 82977058f5b1d143a355079900029e9cbfee2fe4:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   ab87155..8297705  82977058f5b1d143a355079900029e9cbfee2fe4 -> xen-tested-master


--===============3454242083316215004==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3454242083316215004==--

From xen-devel-bounces@lists.xen.org Fri Dec 12 06:30:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 06:30:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzJjb-0007JG-TU; Fri, 12 Dec 2014 06:29:51 +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 1XzJja-0007JB-Gx
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 06:29:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8A/EC-15461-D5B8A845; Fri, 12 Dec 2014 06:29:49 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418365787!7068403!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21146 invoked from network); 12 Dec 2014 06:29:48 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-2.tower-21.messagelabs.com with SMTP;
	12 Dec 2014 06:29:48 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 11 Dec 2014 22:29:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,561,1413270000"; d="scan'208";a="636528747"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga001.fm.intel.com with ESMTP; 11 Dec 2014 22:29:45 -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; Fri, 12 Dec 2014 14:29:44 +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, 12 Dec 2014 14:29:43 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAF26eCAAB3OgIABbe5QgADViQCAAQdz8A==
Date: Fri, 12 Dec 2014 06:29:42 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611829E@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211212904.GA91831@deinos.phlegethon.org>
In-Reply-To: <20141211212904.GA91831@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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Friday, December 12, 2014 5:29 AM
> 
> Hi, again. :)
> 
> As promised, I'm going to talk about more abstract design
> considerations.  Thi will be a lot less concrete than in the other
> email, and about a larger range of things.  Some of of them may not be
> really desirable - or even possible.

Thanks for your time on sharing thoughts on this! I'll give my comments
in same level and leave detail technical discussion in another thread. :-)

> 
> [ TL;DR: read the other reply with the practical suggestions in it :) ]
> 
> I'm talking from the point of view of a hypervisor maintainer, looking
> at introducing this new XenGT component and thinking about what
> security properties we would like the _system_ to have once XenGT is
> introduced.  I'm going to lay out a series of broadly increasing
> levels of security goodness and talk about what we'd need to do to get
> there.

that's a good clarification of the levels.

> 
> For the purposes of this discussion, Xen does not _trust_ XenGT.  By
> that I mean that Xen can't rely on the correctness/integrity of XenGT
> itself to maintain system security.  Now, we can decide that for some
> properties we _will_ choose to trust XenGT, but the default is to
> assume that XenGT could be compromised or buggy.  (This is not
> intended as a slur on XenGT, btw -- this is how we reason about device
> driver domains, qemu-dm and other components.  There will be bugs in
> any component, and we're designing the system to minimise the effect
> of those bugs.)

Yes, it's a fair concern.

> 
> OK.  Properties we would like to have:
> 
> LEVEL 0: Protect Xen itself from XenGT
> --------------------------------------
> 
> Bugs in XenGT should not be able to crash he host, and a compromised
> XenGT should not be able to take over the hypervisor
> 
> We're not there in the current design, purely because XenGT has to be
> in dom0 (so it can trivially DoS Xen by rebooting the host).

Can we really decouple dom0 from DoS Xen? I know there's on-going effort
like PVH Dom0, however there are lots of trickiness in Dom0 which can 
put the platform into a bad state. One example is ACPI. All the platform
details are encapsulated in AML language, and only dom0 knows how to
handle ACPI events. Unless Xen has another parser to guard all possible
resources which might be touched thru ACPI, a tampered dom0 has many
way to break out. But that'd be very challenging and complex.

If we can't containerize Dom0's behavior completely, I would think dom0
and Xen actually in the same trust zone, so putting XenGT in Dom0 shouldn't
make things worse.

> 
> But it doesn't seem too hard: as soon as we can run XenGT in a driver
> domain, and with IOMMU tables that restrict the GPU from writing to Xen's
> datastructures, we'll have this property.
> 
> [BTW, this whole discussion assumes that the GPU has no 'back door'
>  access to issue DMA that is not translated by the IOMMU.  I have heard
>  rumours in the past that such things exist. :) If the GPU can issue
>  untranslated DMA, then whetever controls it can take over the entire
>  system, and so we can't make _any_ security guarantees about it.]

I definitely agree with this LEVEL 0 requirement in general, e.g. dom0 
can't DMA into Xen's data structure (this is ensured even for default 1:1 
identity mapping). However I'm not on whether XenGT must be put
in a driver domain as a hard requirement. It's nice to have (and some
implementation opens let's discuss in another thread)

> 
> 
> LEVEL 1: Isolate XenGT's clients from other VMs
> -----------------------------------------------
> 
> In other words we partition the machine into VMs XenGT can touch
> (i.e. its clients) and those it can't.  Then a malicious client that
> compromises XenGT only gains access to other VMs that share a GPU with
> it.  That means we can deploy XenGT for some VMs without increasing
> the risk to other tenants.
> 
> Again we're not there yet, but I think the design I was talking about
> in my other email would do it: if XenGT must map all the memory it
> wants to let the GPU DMA to, and Xen's policy is to deny mappings for
> non-client-vm memory, then VMs that aren't using XenGT are protected.

fully agree. We have a 'vgt' control option in each VM's config file. that
can be the hint for Xen to decide allow or deny mapping from XenGT.

> 
> 
> LEVEL 2: Isolate XenGT's clients from each other
> ------------------------------------------------
> 
> This is trickier, as you pointed out.  We could:
> 
> a) Decide that we will trust XenGT to provide this property.  After
>    all, that's its main purpose!  This is how we treat other shared
>    backends: if a NIC device driver domain is compromised, the
>    attacker controls the network traffic for all its frontends.
>    OTOH, we don't trust qemu in that way -- instead we use stub domains
>    and IS_PRIV_FOR to enforce isolation.

yep. Just curious, I thought stubdomain is not popularly used. typical
case is to have qemu in dom0. is this still true? :-)

> 
> b) Move all of XenGT into Xen.  This is just defining the problem away
>    and would probably do more harm than good - after all, keeping it
>    separate has other advantages.

I'll explain below why we don't keep XenGT in Xen.

> 
> c) Use privilege separation: break XenGT into parts, isolated from each
>    other, with the principle of least privilege applied to them.  E.g.
>    - GPU emulation could be in a per-client component that doesn't
>      share state with the other clients' emulators;

yes, we're doing it that way now. the emulation is a per-vm kernel thread.
a separate main thread manages physical GPU to do context switch.

>    - Shadowing GTTs and auditing GPU commands could move into Xen,
>      with a clean interface to the emulation parts.

I'm afraid there's no such a clean interface given the complexity of
GPU.

Here let me give some other background which impacts XenGT design
(some are existing, and some are following plan). Putting them here 
is not to say "we don't want to change due to other reasons", but to
show the list of factors we need to balance:

1. the core device model will be merged as part of Intel graphics kernel
driver. This can avoid duplicated physical GPU management in XenGT
(that's today's implementation) with benefits on simplicity, quality and 
maintainability. 

2. the same device model will then be shared by both XenGT and KVMGT,
only requiring Xen/KVM to provide a minimal set of emulation services,
like event forwarding, map guest memory, etc.

3. GPU emulation is complex, and generation-to-generation there are
lots of differences. Our customers need a flexible release model so 
we can release new features and bug fixes quickly thru kernel module.

Those are major reasons we come to current XenGT architecture. Then
back to your idea on moving shadow GTT and auditing GPU commands
into Xen. It will cause more complexity on:

- somehow it means we have two drivers on one device, each responsible
for some role. Then likely we need hack Intel graphics driver's GTT 
management code and scheduling code to cooperate with this movement. 
That's unlikely to be acceptable by driver people

- auditing GPU commands need to understand vGPU context, which
means share and synchronization of a large buffer required between 
Xen and XenGT

- GTT/command format are not compatible generation-to-generation,
which means unnecessary maintenance effort in Xen

- and last but not the least, GPU HW itself is not designed so cleanly
to separate GTT from remaining parts, which means even we move
GTT mgmt. into hypervisor, there are many means to bypass the control,
e.g. changing the root pointer of GTT (which may be in a register,
or maybe in a memory structure). while once we wants to move those
parts into Xen which will dig out more bits and finally we have to pull
the whole driver in Xen (though less complex than a real graphics driver)

sorry write a long detail in this high level discussion. Just write-down
when thinking whether this is practical, and hope it answers our concern
here. :-)

>    That way, even if a client VM can exploit a bug in the emulator,
>    it can't affect other clients because it can't see their emulator
>    state, and it can't bypass the safety rules because they're
>    enforced by Xen.
> 
>    When I talked about privilege separation before I was suggesting
>    something like this, but without moving anything into Xen -- e.g.
>    the device-emulation code for each client could be in a per-client,
>    non-root process.  The code that audits and issues commands to the
>    GPU would be in a separate process, which is allowed to make
>    hypercalls, and which does not trust the emulator processes.
>    My apologies if you're already doing this -- I know XenGT has some
>    components in a kernel driver and some elsewhere but I haven't
>    looked at the details.

that's a good comment. we're implementing that way, but might not
be so strictly separated. I'll bring this comment back to our engineering
team to have it well considered.

> 
> 
> LEVEL 3: Isolate XenGT's clients from XenGT itself
> --------------------------------------------------
> 
> XenGT should not be able to access parts of its client VMs that they
> have not given it permission to.  E.g. XenGT should not be able to
> read a client VM's crypto keys unless it displays them on the
> framebuffer or uses the GPU to accelerate crypto.
> 
> Unlike level 2, device driver domains _do_ have this property: this is
> what the grant tables are used for.  A compromised NIC driver domain
> can MITM the frontend guest but it can't read any memory in the guest
> other than network buffers.
> 
> Again there are a few approaches, like:
> 
> a) Declare that we don't care (i.e. that we will trust XenGT for this
>    property too).  In a way it's no worse than trusting the firmware
>    on a dedicated pass-though GPU.  But on the other hand the client
>    VM is sharing that firmware with some other VMs... :(
> 
> b) Make the GPU driver in the client use grant tables for all RAM that
>    it gives to the GPU.  Probably not practical!

yes, and that can be a good research topic. :-)

> 
> c) Move just the code that builds the GTTs into Xen.  That way
>    Xen would guarantee that the GPU never accessed memory it wasn't
>    allowed to.

as explained above, it's impractical to separate a self-contained GTT logic
into Xen. In GPU, GTT is somehow an attribute belonging to a render context,
not like CPU CR3 which is very simple.

> 
> I'm sure there are other ideas too.
> 
> 
> Conclusion
> ----------
> 
> That's enough rambling from me -- time to come back down to earth.
> While I think it's useful to think about all these things, we don't
> want to get carried away. :)  And as I said, for some things we can
> decide to trust XenGT to provide them, as long as we're clear about
> what that means.
> 
> I think that a reasonable minimum standard to expect is to enforce
> levels 0 and 1 in Xen, and trust XenGT for levels 2 and 3.  And I
> think we can do that without needing any huge engineering effort;
> as I said, I think that's covered in my earlier reply.
> 

I agree the conclusion that "minimum standard to expect is to enforce
levels 0 and 1 in Xen, and trust XenGT for levels 2 and 3", except the
concern whether PVH Dom0 is a hard requirement or not. Having
said that, I'm happy to discuss technical detail in another thread on
how to support PVH Dom0.

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 Dec 12 06:30:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 06:30:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzJjb-0007JG-TU; Fri, 12 Dec 2014 06:29:51 +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 1XzJja-0007JB-Gx
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 06:29:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8A/EC-15461-D5B8A845; Fri, 12 Dec 2014 06:29:49 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418365787!7068403!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21146 invoked from network); 12 Dec 2014 06:29:48 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-2.tower-21.messagelabs.com with SMTP;
	12 Dec 2014 06:29:48 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 11 Dec 2014 22:29:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,561,1413270000"; d="scan'208";a="636528747"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga001.fm.intel.com with ESMTP; 11 Dec 2014 22:29:45 -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; Fri, 12 Dec 2014 14:29:44 +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, 12 Dec 2014 14:29:43 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAF26eCAAB3OgIABbe5QgADViQCAAQdz8A==
Date: Fri, 12 Dec 2014 06:29:42 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611829E@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211212904.GA91831@deinos.phlegethon.org>
In-Reply-To: <20141211212904.GA91831@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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Friday, December 12, 2014 5:29 AM
> 
> Hi, again. :)
> 
> As promised, I'm going to talk about more abstract design
> considerations.  Thi will be a lot less concrete than in the other
> email, and about a larger range of things.  Some of of them may not be
> really desirable - or even possible.

Thanks for your time on sharing thoughts on this! I'll give my comments
in same level and leave detail technical discussion in another thread. :-)

> 
> [ TL;DR: read the other reply with the practical suggestions in it :) ]
> 
> I'm talking from the point of view of a hypervisor maintainer, looking
> at introducing this new XenGT component and thinking about what
> security properties we would like the _system_ to have once XenGT is
> introduced.  I'm going to lay out a series of broadly increasing
> levels of security goodness and talk about what we'd need to do to get
> there.

that's a good clarification of the levels.

> 
> For the purposes of this discussion, Xen does not _trust_ XenGT.  By
> that I mean that Xen can't rely on the correctness/integrity of XenGT
> itself to maintain system security.  Now, we can decide that for some
> properties we _will_ choose to trust XenGT, but the default is to
> assume that XenGT could be compromised or buggy.  (This is not
> intended as a slur on XenGT, btw -- this is how we reason about device
> driver domains, qemu-dm and other components.  There will be bugs in
> any component, and we're designing the system to minimise the effect
> of those bugs.)

Yes, it's a fair concern.

> 
> OK.  Properties we would like to have:
> 
> LEVEL 0: Protect Xen itself from XenGT
> --------------------------------------
> 
> Bugs in XenGT should not be able to crash he host, and a compromised
> XenGT should not be able to take over the hypervisor
> 
> We're not there in the current design, purely because XenGT has to be
> in dom0 (so it can trivially DoS Xen by rebooting the host).

Can we really decouple dom0 from DoS Xen? I know there's on-going effort
like PVH Dom0, however there are lots of trickiness in Dom0 which can 
put the platform into a bad state. One example is ACPI. All the platform
details are encapsulated in AML language, and only dom0 knows how to
handle ACPI events. Unless Xen has another parser to guard all possible
resources which might be touched thru ACPI, a tampered dom0 has many
way to break out. But that'd be very challenging and complex.

If we can't containerize Dom0's behavior completely, I would think dom0
and Xen actually in the same trust zone, so putting XenGT in Dom0 shouldn't
make things worse.

> 
> But it doesn't seem too hard: as soon as we can run XenGT in a driver
> domain, and with IOMMU tables that restrict the GPU from writing to Xen's
> datastructures, we'll have this property.
> 
> [BTW, this whole discussion assumes that the GPU has no 'back door'
>  access to issue DMA that is not translated by the IOMMU.  I have heard
>  rumours in the past that such things exist. :) If the GPU can issue
>  untranslated DMA, then whetever controls it can take over the entire
>  system, and so we can't make _any_ security guarantees about it.]

I definitely agree with this LEVEL 0 requirement in general, e.g. dom0 
can't DMA into Xen's data structure (this is ensured even for default 1:1 
identity mapping). However I'm not on whether XenGT must be put
in a driver domain as a hard requirement. It's nice to have (and some
implementation opens let's discuss in another thread)

> 
> 
> LEVEL 1: Isolate XenGT's clients from other VMs
> -----------------------------------------------
> 
> In other words we partition the machine into VMs XenGT can touch
> (i.e. its clients) and those it can't.  Then a malicious client that
> compromises XenGT only gains access to other VMs that share a GPU with
> it.  That means we can deploy XenGT for some VMs without increasing
> the risk to other tenants.
> 
> Again we're not there yet, but I think the design I was talking about
> in my other email would do it: if XenGT must map all the memory it
> wants to let the GPU DMA to, and Xen's policy is to deny mappings for
> non-client-vm memory, then VMs that aren't using XenGT are protected.

fully agree. We have a 'vgt' control option in each VM's config file. that
can be the hint for Xen to decide allow or deny mapping from XenGT.

> 
> 
> LEVEL 2: Isolate XenGT's clients from each other
> ------------------------------------------------
> 
> This is trickier, as you pointed out.  We could:
> 
> a) Decide that we will trust XenGT to provide this property.  After
>    all, that's its main purpose!  This is how we treat other shared
>    backends: if a NIC device driver domain is compromised, the
>    attacker controls the network traffic for all its frontends.
>    OTOH, we don't trust qemu in that way -- instead we use stub domains
>    and IS_PRIV_FOR to enforce isolation.

yep. Just curious, I thought stubdomain is not popularly used. typical
case is to have qemu in dom0. is this still true? :-)

> 
> b) Move all of XenGT into Xen.  This is just defining the problem away
>    and would probably do more harm than good - after all, keeping it
>    separate has other advantages.

I'll explain below why we don't keep XenGT in Xen.

> 
> c) Use privilege separation: break XenGT into parts, isolated from each
>    other, with the principle of least privilege applied to them.  E.g.
>    - GPU emulation could be in a per-client component that doesn't
>      share state with the other clients' emulators;

yes, we're doing it that way now. the emulation is a per-vm kernel thread.
a separate main thread manages physical GPU to do context switch.

>    - Shadowing GTTs and auditing GPU commands could move into Xen,
>      with a clean interface to the emulation parts.

I'm afraid there's no such a clean interface given the complexity of
GPU.

Here let me give some other background which impacts XenGT design
(some are existing, and some are following plan). Putting them here 
is not to say "we don't want to change due to other reasons", but to
show the list of factors we need to balance:

1. the core device model will be merged as part of Intel graphics kernel
driver. This can avoid duplicated physical GPU management in XenGT
(that's today's implementation) with benefits on simplicity, quality and 
maintainability. 

2. the same device model will then be shared by both XenGT and KVMGT,
only requiring Xen/KVM to provide a minimal set of emulation services,
like event forwarding, map guest memory, etc.

3. GPU emulation is complex, and generation-to-generation there are
lots of differences. Our customers need a flexible release model so 
we can release new features and bug fixes quickly thru kernel module.

Those are major reasons we come to current XenGT architecture. Then
back to your idea on moving shadow GTT and auditing GPU commands
into Xen. It will cause more complexity on:

- somehow it means we have two drivers on one device, each responsible
for some role. Then likely we need hack Intel graphics driver's GTT 
management code and scheduling code to cooperate with this movement. 
That's unlikely to be acceptable by driver people

- auditing GPU commands need to understand vGPU context, which
means share and synchronization of a large buffer required between 
Xen and XenGT

- GTT/command format are not compatible generation-to-generation,
which means unnecessary maintenance effort in Xen

- and last but not the least, GPU HW itself is not designed so cleanly
to separate GTT from remaining parts, which means even we move
GTT mgmt. into hypervisor, there are many means to bypass the control,
e.g. changing the root pointer of GTT (which may be in a register,
or maybe in a memory structure). while once we wants to move those
parts into Xen which will dig out more bits and finally we have to pull
the whole driver in Xen (though less complex than a real graphics driver)

sorry write a long detail in this high level discussion. Just write-down
when thinking whether this is practical, and hope it answers our concern
here. :-)

>    That way, even if a client VM can exploit a bug in the emulator,
>    it can't affect other clients because it can't see their emulator
>    state, and it can't bypass the safety rules because they're
>    enforced by Xen.
> 
>    When I talked about privilege separation before I was suggesting
>    something like this, but without moving anything into Xen -- e.g.
>    the device-emulation code for each client could be in a per-client,
>    non-root process.  The code that audits and issues commands to the
>    GPU would be in a separate process, which is allowed to make
>    hypercalls, and which does not trust the emulator processes.
>    My apologies if you're already doing this -- I know XenGT has some
>    components in a kernel driver and some elsewhere but I haven't
>    looked at the details.

that's a good comment. we're implementing that way, but might not
be so strictly separated. I'll bring this comment back to our engineering
team to have it well considered.

> 
> 
> LEVEL 3: Isolate XenGT's clients from XenGT itself
> --------------------------------------------------
> 
> XenGT should not be able to access parts of its client VMs that they
> have not given it permission to.  E.g. XenGT should not be able to
> read a client VM's crypto keys unless it displays them on the
> framebuffer or uses the GPU to accelerate crypto.
> 
> Unlike level 2, device driver domains _do_ have this property: this is
> what the grant tables are used for.  A compromised NIC driver domain
> can MITM the frontend guest but it can't read any memory in the guest
> other than network buffers.
> 
> Again there are a few approaches, like:
> 
> a) Declare that we don't care (i.e. that we will trust XenGT for this
>    property too).  In a way it's no worse than trusting the firmware
>    on a dedicated pass-though GPU.  But on the other hand the client
>    VM is sharing that firmware with some other VMs... :(
> 
> b) Make the GPU driver in the client use grant tables for all RAM that
>    it gives to the GPU.  Probably not practical!

yes, and that can be a good research topic. :-)

> 
> c) Move just the code that builds the GTTs into Xen.  That way
>    Xen would guarantee that the GPU never accessed memory it wasn't
>    allowed to.

as explained above, it's impractical to separate a self-contained GTT logic
into Xen. In GPU, GTT is somehow an attribute belonging to a render context,
not like CPU CR3 which is very simple.

> 
> I'm sure there are other ideas too.
> 
> 
> Conclusion
> ----------
> 
> That's enough rambling from me -- time to come back down to earth.
> While I think it's useful to think about all these things, we don't
> want to get carried away. :)  And as I said, for some things we can
> decide to trust XenGT to provide them, as long as we're clear about
> what that means.
> 
> I think that a reasonable minimum standard to expect is to enforce
> levels 0 and 1 in Xen, and trust XenGT for levels 2 and 3.  And I
> think we can do that without needing any huge engineering effort;
> as I said, I think that's covered in my earlier reply.
> 

I agree the conclusion that "minimum standard to expect is to enforce
levels 0 and 1 in Xen, and trust XenGT for levels 2 and 3", except the
concern whether PVH Dom0 is a hard requirement or not. Having
said that, I'm happy to discuss technical detail in another thread on
how to support PVH Dom0.

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 Dec 12 07:28:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 07:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzKe2-0000zJ-JF; Fri, 12 Dec 2014 07:28:10 +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 1XzKe0-0000zE-Fw
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 07:28:08 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	EF/3C-18267-7099A845; Fri, 12 Dec 2014 07:28:07 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418369284!12821893!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 18551 invoked from network); 12 Dec 2014 07:28:05 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-31.messagelabs.com with SMTP;
	12 Dec 2014 07:28:05 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 11 Dec 2014 23:26:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,561,1413270000"; d="scan'208";a="622640645"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga001.jf.intel.com with ESMTP; 11 Dec 2014 23:28:01 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 12 Dec 2014 15:25:12 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.67]) with mapi id
	14.03.0195.001; Fri, 12 Dec 2014 15:24:52 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQFWLPVrKgt/iprUGeDtFvUCgErJyLgXPw
Date: Fri, 12 Dec 2014 07:24:51 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
In-Reply-To: <20141211164632.GF53811@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: "Yu, Zhang" <yu.c.zhang@linux.intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	"keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate
	gfn	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan
> Sent: Friday, December 12, 2014 12:47 AM
> 
> Hi,
> 
> At 01:41 +0000 on 11 Dec (1418258504), Tian, Kevin wrote:
> > > From: Tim Deegan [mailto:tim@xen.org]
> > > It is Xen's job to isolate VMs from each other.  As part of that, Xen
> > > uses the MMU, nested paging, and IOMMUs to control access to RAM.
> Any
> > > software component that can pass a raw MFN to hardware breaks that
> > > isolation, because Xen has no way of controlling what that component
> > > can do (including taking over the hypervisor).  This is why I am
> > > afraid when developers ask for GFN->MFN translation functions.
> >
> > When I agree Xen's job absolutely, the isolation is also required in different
> > layers, regarding to who controls the resource and where the virtualization
> > happens. For example talking about I/O virtualization, Dom0 or driver
> domain
> > needs to isolate among backend drivers to avoid one backend interfering
> > with another. Xen doesn't know such violation, since it only knows it's Dom0
> > wants to access a VM's page.
> 
> I'm going to write second reply to this mail in a bit, to talk about
> this kind of system-level design.  In this email I'll just talk about
> the practical aspects of interfaces and address spaces and IOMMUs.

sure. I've replied to another design mail before seeing this. my bad outlook 
rule didn't push this mail to my eye, and fortunately I dig it out when 
wondering "Hi, again" in your another mail. :-)


> 
> > btw curious of how worse exposing GFN->MFN translation compared to
> > allowing mapping other VM's GFN? If exposing GFN->MFN is under the
> > same permission control as mapping, would it avoid your worry here?
> 
> I'm afraid not.  There's nothing worrying per se in a backend knowing
> the MFNs of the pages -- the worry is that the backend can pass the
> MFNs to hardware.  If the check happens only at lookup time, then XenGT
> can (either through a bug or a security breach) just pass _any_ MFN to
> the GPU for DMA.
> 
> But even without considering the security aspects, this model has bugs
> that may be impossible for XenGT itself to even detect.  E.g.:
>  1. Guest asks its virtual GPU to DMA to a frame of memory;
>  2. XenGT looks up the GFN->MFN mapping;
>  3. Guest balloons out the page;
>  4. Xen allocates the page to a different guest;
>  5. XenGT passes the MFN to the GPU, which DMAs to it.
> 
> Whereas if stage 2 is a _mapping_ operation, Xen can refcount the
> underlying memory and make sure it doesn't get reallocated until XenGT
> is finished with it.

yes, I see your point. Now we can't support ballooning in VM given above
reason, and refcnt is required to close that gap.

but just to confirm one point. from my understanding whether it's a 
mapping operation doesn't really matter. We can invent an interface
to get p2m mapping and then increase refcnt. the key is refcnt here.
when XenGT constructs a shadow GPU page table, it creates a reference
to guest memory page so the refcnt must be increased. :-)

> 
> > > When the backend component gets a GFN from the guest, it wants an
> > > address that it can give to the GPU for DMA that will map the right
> > > memory.  That address must be mapped in the IOMMU tables that the
> GPU
> > > will be using, which means the IOMMU tables of the backend domain,
> > > IIUC[1].  So the hypercall it needs is not "give me the MFN that matches
> > > this GFN" but "please map this GFN into my IOMMU tables".
> >
> > Here "please map this GFN into my IOMMU tables" actually breaks the
> > IOMMU isolation. IOMMU is designed for serving DMA requests issued
> > by an exclusive VM, so IOMMU page table can restrict that VM's attempts
> > strictly.
> >
> > To map multiple VM's GFNs into one IOMMU table, the 1st thing is to
> > avoid GFN conflictions to make it functional. We thought about this approach
> > previously, e.g. by reserving highest 3 bits of GFN as VMID, so one IOMMU
> > page table can be used to combine multi-VM's page table together. However
> > doing so have two limitations:
> >
> > a) it still requires write-protect guest GPU page table, and maintain a
> shadow
> > GPU page table by translate from real GFN to pseudo GFN (plus VMID),
> which
> > doesn't save any engineering effort in the device model part
> 
> Yes -- since there's only one IOMMU context for the whole GPU, the
> XenGT backend still has to audit all GPU commands to maintain
> isolation between clients.
> 
> > b) it breaks the designed isolation intrinsic of IOMMU. In such case, IOMMU
> > can't isolate multiple VMs by itself, since a DMA request can target any
> > pseudo GFN if valid in the page table. We have to rely on the audit in the
> > backend component in Dom0 to ensure the isolation.
> 
> Yep.
> 
> > c) this introduces tricky logic in IOMMU driver to handle such non-standard
> > multiplexed page table style.
> >
> > w/o a SR-IOV implementation (so each VF has its own IOMMU page table),
> > I don't see using IOMMU can help isolation here.
> 
> If I've understood your argument correctly, it basically comes down
> to "It would be extra work for no benefit, because XenGT still has to
> do all the work of isolating GPU clients from each other".  It's true
> that XenGT still has to isolate its clients, but there are other
> benefits.
> 
> The main one, from my point of view as a Xen maintainer, is that it
> allows Xen to constrain XenGT itself, in the case where bugs or
> security breaches mean that XenGT tries to access memory it shouldn't.
> More about that in my other reply.  I'll talk about the rest below.
> 
> > yes, this is a good feedback we didn't think about before. So far the reason
> > why XenGT can work is because we use default IOMMU setting which set
> > up a 1:1 r/w mapping for all possible RAM, so when GPU hits a MFN thru
> > shadow GPU page table, IOMMU is essentially bypassed. However like
> > you said, if IOMMU page table is restricted to dom0's memory, or is not
> > 1:1 identity mapping, XenGT will be broken.
> >
> > However I don't see a good solution for this, except using multiplexed
> > IOMMU page table aforementioned, which however doesn't look like
> > a sane design to me.
> 
> Right.  AIUI you're talking about having a component, maybe in Xen,
> that automatically makes a merged IOMMU table that contains multiple
> VMs' p2m tables all at once.  I think that we can do something simpler
> than that which will have the same effect and also avoid race
> conditions like the one I mentioned at the top of the email.
> 
> [First some hopefully-helpful diagrams to explain my thinking.  I'll
>  borrow 'BFN' from Malcolm's discussion of IOMMUs to describe the
>  addresses that devices issue their DMAs in:

what's 'BFN' short for? Bus Frame Number?

> 
>  Here's how the translations work for a HVM guest using HAP:
> 
>    CPU    <- Code supplied by the guest
>     |
>   (VA)
>     |
>    MMU    <- Pagetables supplied by the guest
>     |
>   (GFN)
>     |
>    HAP    <- Guest's P2M, supplied by Xen
>     |
>   (MFN)
>     |
>    RAM
> 
>  Here's how it looks for a GPU operation using XenGT:
> 
>    GPU       <- Code supplied by Guest, audited by XenGT
>     |
>   (GPU VA)
>     |
>   GPU-MMU    <- GTTs supplied by XenGT (by shadowing guest ones)
>     |
>   (GPU BFN)
>     |
>   IOMMU      <- XenGT backend dom's P2M (for PVH/HVM) or IOMMU
> tables (for PV)
>     |
>   (MFN)
>     |
>    RAM
> 
>  OK, on we go...]
> 
> Somewhere in the existing XenGT code, XenGT has a guest GFN in its
> hand and makes a lookup hypercall to find the MFN.  It puts that MFN
> into the GTTs that it passes to the GPU.  But an MFN is not actually
> what it needs here -- it needs a GPU BFN, which the IOMMU will then
> turn into an MFN for it.
> 
> If we replace that lookup with a _map_ hypercall, either with Xen
> choosing the BFN (as happens in the PV grant map operation) or with
> the guest choosing an unused address (as happens in the HVM/PVH
> grant map operation), then:
>  - the only extra code in XenGT itself is that you need to unmap
>    when you change the GTT;
>  - Xen can track and control exactly which MFNs XenGT/the GPU can access;
>  - running XenGT in a driver domain or PVH dom0 ought to work; and
>  - we fix the race condition I described above.

ok, I see your point here. It does sound like a better design to meet
Xen hypervisor's security requirement and can also work with PVH
Dom0 or driver domain. Previously even when we said a MFN is
required, it's actually a BFN due to IOMMU existence, and it works
just because we have a 1:1 identity mapping in-place. And by finding
a BFN

some follow-up think here:

- one extra unmap call will have some performance impact, especially
for media processing workloads where GPU page table modifications
are hot. but suppose this can be optimized with batch request

- is there existing _map_ call for this purpose per your knowledge, or
a new one is required? If the latter, what's the additional logic to be
implemented there?

- when you say _map_, do you expect this mapped into dom0's virtual
address space, or just guest physical space?

- how is BFN or unused address (what do you mean by address here?)
allocated? does it need present in guest physical memory at boot time,
or just finding some holes?

- graphics memory size could be large. starting from BDW, there'll
be 64bit page table format. Do you see any limitation here on finding
BFN or address?

> 
> The default policy I'm suggesting is that the XenGT backend domain
> should be marked IS_PRIV_FOR (or similar) over the XenGT client VMs,
> which will need a small extension in Xen since at the moment struct
> domain has only one "target" field.

Is that connection setup by toolstack or by hypervisor today?

> 
> BTW, this is the exact analogue of how all other backend and toolstack
> operations work -- they request access from Xen to specific pages and
> they relinquish it when they are done.  In particular:

agree.

> 
> > for mapping and accessing other guest's memory, I don't think we
> > need any new interface atop existing ones. Just similar to other backend
> > drivers, we can leverage the same permission control.
> 
> I don't think that's right -- other backend drivers use the grant
> table mechanism, wher the guest explicitly grants access to only the
> memory it needs.  AIUI you're not suggesting that you'll use that for
> XenGT! :)

yes, we're running native graphics driver in VM, not PV driver

> 
> Right - I hope that made some sense.  I'll go get another cup of
> coffee and start on that other reply...
> 
> Cheers,
> 

Really appreciate your explanation here. It makes lots of sense to me.

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 Dec 12 07:28:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 07:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzKe2-0000zJ-JF; Fri, 12 Dec 2014 07:28:10 +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 1XzKe0-0000zE-Fw
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 07:28:08 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	EF/3C-18267-7099A845; Fri, 12 Dec 2014 07:28:07 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418369284!12821893!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 18551 invoked from network); 12 Dec 2014 07:28:05 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-31.messagelabs.com with SMTP;
	12 Dec 2014 07:28:05 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 11 Dec 2014 23:26:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,561,1413270000"; d="scan'208";a="622640645"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga001.jf.intel.com with ESMTP; 11 Dec 2014 23:28:01 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 12 Dec 2014 15:25:12 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.67]) with mapi id
	14.03.0195.001; Fri, 12 Dec 2014 15:24:52 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQFWLPVrKgt/iprUGeDtFvUCgErJyLgXPw
Date: Fri, 12 Dec 2014 07:24:51 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
In-Reply-To: <20141211164632.GF53811@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: "Yu, Zhang" <yu.c.zhang@linux.intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	"keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate
	gfn	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan
> Sent: Friday, December 12, 2014 12:47 AM
> 
> Hi,
> 
> At 01:41 +0000 on 11 Dec (1418258504), Tian, Kevin wrote:
> > > From: Tim Deegan [mailto:tim@xen.org]
> > > It is Xen's job to isolate VMs from each other.  As part of that, Xen
> > > uses the MMU, nested paging, and IOMMUs to control access to RAM.
> Any
> > > software component that can pass a raw MFN to hardware breaks that
> > > isolation, because Xen has no way of controlling what that component
> > > can do (including taking over the hypervisor).  This is why I am
> > > afraid when developers ask for GFN->MFN translation functions.
> >
> > When I agree Xen's job absolutely, the isolation is also required in different
> > layers, regarding to who controls the resource and where the virtualization
> > happens. For example talking about I/O virtualization, Dom0 or driver
> domain
> > needs to isolate among backend drivers to avoid one backend interfering
> > with another. Xen doesn't know such violation, since it only knows it's Dom0
> > wants to access a VM's page.
> 
> I'm going to write second reply to this mail in a bit, to talk about
> this kind of system-level design.  In this email I'll just talk about
> the practical aspects of interfaces and address spaces and IOMMUs.

sure. I've replied to another design mail before seeing this. my bad outlook 
rule didn't push this mail to my eye, and fortunately I dig it out when 
wondering "Hi, again" in your another mail. :-)


> 
> > btw curious of how worse exposing GFN->MFN translation compared to
> > allowing mapping other VM's GFN? If exposing GFN->MFN is under the
> > same permission control as mapping, would it avoid your worry here?
> 
> I'm afraid not.  There's nothing worrying per se in a backend knowing
> the MFNs of the pages -- the worry is that the backend can pass the
> MFNs to hardware.  If the check happens only at lookup time, then XenGT
> can (either through a bug or a security breach) just pass _any_ MFN to
> the GPU for DMA.
> 
> But even without considering the security aspects, this model has bugs
> that may be impossible for XenGT itself to even detect.  E.g.:
>  1. Guest asks its virtual GPU to DMA to a frame of memory;
>  2. XenGT looks up the GFN->MFN mapping;
>  3. Guest balloons out the page;
>  4. Xen allocates the page to a different guest;
>  5. XenGT passes the MFN to the GPU, which DMAs to it.
> 
> Whereas if stage 2 is a _mapping_ operation, Xen can refcount the
> underlying memory and make sure it doesn't get reallocated until XenGT
> is finished with it.

yes, I see your point. Now we can't support ballooning in VM given above
reason, and refcnt is required to close that gap.

but just to confirm one point. from my understanding whether it's a 
mapping operation doesn't really matter. We can invent an interface
to get p2m mapping and then increase refcnt. the key is refcnt here.
when XenGT constructs a shadow GPU page table, it creates a reference
to guest memory page so the refcnt must be increased. :-)

> 
> > > When the backend component gets a GFN from the guest, it wants an
> > > address that it can give to the GPU for DMA that will map the right
> > > memory.  That address must be mapped in the IOMMU tables that the
> GPU
> > > will be using, which means the IOMMU tables of the backend domain,
> > > IIUC[1].  So the hypercall it needs is not "give me the MFN that matches
> > > this GFN" but "please map this GFN into my IOMMU tables".
> >
> > Here "please map this GFN into my IOMMU tables" actually breaks the
> > IOMMU isolation. IOMMU is designed for serving DMA requests issued
> > by an exclusive VM, so IOMMU page table can restrict that VM's attempts
> > strictly.
> >
> > To map multiple VM's GFNs into one IOMMU table, the 1st thing is to
> > avoid GFN conflictions to make it functional. We thought about this approach
> > previously, e.g. by reserving highest 3 bits of GFN as VMID, so one IOMMU
> > page table can be used to combine multi-VM's page table together. However
> > doing so have two limitations:
> >
> > a) it still requires write-protect guest GPU page table, and maintain a
> shadow
> > GPU page table by translate from real GFN to pseudo GFN (plus VMID),
> which
> > doesn't save any engineering effort in the device model part
> 
> Yes -- since there's only one IOMMU context for the whole GPU, the
> XenGT backend still has to audit all GPU commands to maintain
> isolation between clients.
> 
> > b) it breaks the designed isolation intrinsic of IOMMU. In such case, IOMMU
> > can't isolate multiple VMs by itself, since a DMA request can target any
> > pseudo GFN if valid in the page table. We have to rely on the audit in the
> > backend component in Dom0 to ensure the isolation.
> 
> Yep.
> 
> > c) this introduces tricky logic in IOMMU driver to handle such non-standard
> > multiplexed page table style.
> >
> > w/o a SR-IOV implementation (so each VF has its own IOMMU page table),
> > I don't see using IOMMU can help isolation here.
> 
> If I've understood your argument correctly, it basically comes down
> to "It would be extra work for no benefit, because XenGT still has to
> do all the work of isolating GPU clients from each other".  It's true
> that XenGT still has to isolate its clients, but there are other
> benefits.
> 
> The main one, from my point of view as a Xen maintainer, is that it
> allows Xen to constrain XenGT itself, in the case where bugs or
> security breaches mean that XenGT tries to access memory it shouldn't.
> More about that in my other reply.  I'll talk about the rest below.
> 
> > yes, this is a good feedback we didn't think about before. So far the reason
> > why XenGT can work is because we use default IOMMU setting which set
> > up a 1:1 r/w mapping for all possible RAM, so when GPU hits a MFN thru
> > shadow GPU page table, IOMMU is essentially bypassed. However like
> > you said, if IOMMU page table is restricted to dom0's memory, or is not
> > 1:1 identity mapping, XenGT will be broken.
> >
> > However I don't see a good solution for this, except using multiplexed
> > IOMMU page table aforementioned, which however doesn't look like
> > a sane design to me.
> 
> Right.  AIUI you're talking about having a component, maybe in Xen,
> that automatically makes a merged IOMMU table that contains multiple
> VMs' p2m tables all at once.  I think that we can do something simpler
> than that which will have the same effect and also avoid race
> conditions like the one I mentioned at the top of the email.
> 
> [First some hopefully-helpful diagrams to explain my thinking.  I'll
>  borrow 'BFN' from Malcolm's discussion of IOMMUs to describe the
>  addresses that devices issue their DMAs in:

what's 'BFN' short for? Bus Frame Number?

> 
>  Here's how the translations work for a HVM guest using HAP:
> 
>    CPU    <- Code supplied by the guest
>     |
>   (VA)
>     |
>    MMU    <- Pagetables supplied by the guest
>     |
>   (GFN)
>     |
>    HAP    <- Guest's P2M, supplied by Xen
>     |
>   (MFN)
>     |
>    RAM
> 
>  Here's how it looks for a GPU operation using XenGT:
> 
>    GPU       <- Code supplied by Guest, audited by XenGT
>     |
>   (GPU VA)
>     |
>   GPU-MMU    <- GTTs supplied by XenGT (by shadowing guest ones)
>     |
>   (GPU BFN)
>     |
>   IOMMU      <- XenGT backend dom's P2M (for PVH/HVM) or IOMMU
> tables (for PV)
>     |
>   (MFN)
>     |
>    RAM
> 
>  OK, on we go...]
> 
> Somewhere in the existing XenGT code, XenGT has a guest GFN in its
> hand and makes a lookup hypercall to find the MFN.  It puts that MFN
> into the GTTs that it passes to the GPU.  But an MFN is not actually
> what it needs here -- it needs a GPU BFN, which the IOMMU will then
> turn into an MFN for it.
> 
> If we replace that lookup with a _map_ hypercall, either with Xen
> choosing the BFN (as happens in the PV grant map operation) or with
> the guest choosing an unused address (as happens in the HVM/PVH
> grant map operation), then:
>  - the only extra code in XenGT itself is that you need to unmap
>    when you change the GTT;
>  - Xen can track and control exactly which MFNs XenGT/the GPU can access;
>  - running XenGT in a driver domain or PVH dom0 ought to work; and
>  - we fix the race condition I described above.

ok, I see your point here. It does sound like a better design to meet
Xen hypervisor's security requirement and can also work with PVH
Dom0 or driver domain. Previously even when we said a MFN is
required, it's actually a BFN due to IOMMU existence, and it works
just because we have a 1:1 identity mapping in-place. And by finding
a BFN

some follow-up think here:

- one extra unmap call will have some performance impact, especially
for media processing workloads where GPU page table modifications
are hot. but suppose this can be optimized with batch request

- is there existing _map_ call for this purpose per your knowledge, or
a new one is required? If the latter, what's the additional logic to be
implemented there?

- when you say _map_, do you expect this mapped into dom0's virtual
address space, or just guest physical space?

- how is BFN or unused address (what do you mean by address here?)
allocated? does it need present in guest physical memory at boot time,
or just finding some holes?

- graphics memory size could be large. starting from BDW, there'll
be 64bit page table format. Do you see any limitation here on finding
BFN or address?

> 
> The default policy I'm suggesting is that the XenGT backend domain
> should be marked IS_PRIV_FOR (or similar) over the XenGT client VMs,
> which will need a small extension in Xen since at the moment struct
> domain has only one "target" field.

Is that connection setup by toolstack or by hypervisor today?

> 
> BTW, this is the exact analogue of how all other backend and toolstack
> operations work -- they request access from Xen to specific pages and
> they relinquish it when they are done.  In particular:

agree.

> 
> > for mapping and accessing other guest's memory, I don't think we
> > need any new interface atop existing ones. Just similar to other backend
> > drivers, we can leverage the same permission control.
> 
> I don't think that's right -- other backend drivers use the grant
> table mechanism, wher the guest explicitly grants access to only the
> memory it needs.  AIUI you're not suggesting that you'll use that for
> XenGT! :)

yes, we're running native graphics driver in VM, not PV driver

> 
> Right - I hope that made some sense.  I'll go get another cup of
> coffee and start on that other reply...
> 
> Cheers,
> 

Really appreciate your explanation here. It makes lots of sense to me.

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 Dec 12 07:30:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 07:30:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzKgQ-00015G-4d; Fri, 12 Dec 2014 07:30:38 +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 1XzKgO-00015A-Ei
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 07:30:36 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	6F/50-11581-B999A845; Fri, 12 Dec 2014 07:30:35 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418369434!12947514!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13742 invoked from network); 12 Dec 2014 07:30:35 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-206.messagelabs.com with SMTP;
	12 Dec 2014 07:30:35 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 11 Dec 2014 23:28:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,561,1413270000"; d="scan'208";a="622641308"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga001.jf.intel.com with ESMTP; 11 Dec 2014 23:30:32 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 12 Dec 2014 15:30:23 +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; Fri, 12 Dec 2014 15:30:21 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAF26eCAAB3OgIABbe5QgADViQCAAQdz8IAAJnTw
Date: Fri, 12 Dec 2014 07:30:21 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611830C@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211212904.GA91831@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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tian, Kevin
> Sent: Friday, December 12, 2014 2:30 PM
> >
> > Conclusion
> > ----------
> >
> > That's enough rambling from me -- time to come back down to earth.
> > While I think it's useful to think about all these things, we don't
> > want to get carried away. :)  And as I said, for some things we can
> > decide to trust XenGT to provide them, as long as we're clear about
> > what that means.
> >
> > I think that a reasonable minimum standard to expect is to enforce
> > levels 0 and 1 in Xen, and trust XenGT for levels 2 and 3.  And I
> > think we can do that without needing any huge engineering effort;
> > as I said, I think that's covered in my earlier reply.
> >
> 
> I agree the conclusion that "minimum standard to expect is to enforce
> levels 0 and 1 in Xen, and trust XenGT for levels 2 and 3", except the
> concern whether PVH Dom0 is a hard requirement or not. Having
> said that, I'm happy to discuss technical detail in another thread on
> how to support PVH Dom0.
> 

So after going through another mail, now I agree both level 0/1 can't
be enforced. :-)

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 Dec 12 07:30:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 07:30:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzKgQ-00015G-4d; Fri, 12 Dec 2014 07:30:38 +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 1XzKgO-00015A-Ei
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 07:30:36 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	6F/50-11581-B999A845; Fri, 12 Dec 2014 07:30:35 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418369434!12947514!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13742 invoked from network); 12 Dec 2014 07:30:35 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-206.messagelabs.com with SMTP;
	12 Dec 2014 07:30:35 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 11 Dec 2014 23:28:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,561,1413270000"; d="scan'208";a="622641308"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga001.jf.intel.com with ESMTP; 11 Dec 2014 23:30:32 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Fri, 12 Dec 2014 15:30:23 +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; Fri, 12 Dec 2014 15:30:21 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Tim Deegan <tim@xen.org>
Thread-Topic: One question about the hypercall to translate gfn to mfn.
Thread-Index: AQHQE5ijx8eE5zCfX0WmGWg5Lg8fgJyGjX2AgAF26eCAAB3OgIABbe5QgADViQCAAQdz8IAAJnTw
Date: Fri, 12 Dec 2014 07:30:21 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611830C@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211212904.GA91831@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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tian, Kevin
> Sent: Friday, December 12, 2014 2:30 PM
> >
> > Conclusion
> > ----------
> >
> > That's enough rambling from me -- time to come back down to earth.
> > While I think it's useful to think about all these things, we don't
> > want to get carried away. :)  And as I said, for some things we can
> > decide to trust XenGT to provide them, as long as we're clear about
> > what that means.
> >
> > I think that a reasonable minimum standard to expect is to enforce
> > levels 0 and 1 in Xen, and trust XenGT for levels 2 and 3.  And I
> > think we can do that without needing any huge engineering effort;
> > as I said, I think that's covered in my earlier reply.
> >
> 
> I agree the conclusion that "minimum standard to expect is to enforce
> levels 0 and 1 in Xen, and trust XenGT for levels 2 and 3", except the
> concern whether PVH Dom0 is a hard requirement or not. Having
> said that, I'm happy to discuss technical detail in another thread on
> how to support PVH Dom0.
> 

So after going through another mail, now I agree both level 0/1 can't
be enforced. :-)

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 Dec 12 08:43:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 08: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 1XzLoH-00043s-FS; Fri, 12 Dec 2014 08:42:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XzLoG-00043n-DC
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 08:42:48 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	A0/56-02702-78AAA845; Fri, 12 Dec 2014 08:42:47 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418373766!11289899!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16770 invoked from network); 12 Dec 2014 08:42:47 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-27.messagelabs.com with SMTP;
	12 Dec 2014 08:42:47 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 12 Dec 2014 00:42:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="428128285"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by FMSMGA003.fm.intel.com with ESMTP; 12 Dec 2014 00:31:54 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Fri, 12 Dec 2014 16:12:05 +0800
Message-Id: <1418371927-32007-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 v7 0/2] add new p2m type class and new p2m 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

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 added
a new p2m type, p2m_mmio_write_dm, to trap and emulate the write
operations 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_ram_ro types, write operations will not
trigger the device model, and will be discarded later in __hvm_copy();
while for the 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 v6:
 - Handle the new p2m type in the shadow-pagetable code.

Changes from v5:
 - Stricter type checks for p2m type transitions;
 - One code style change.

Changes from v4:
 - A new p2m type class, P2M_DISCARD_WRITE_TYPES, is added;
 - A new predicate, p2m_is_discard_write, is used in __hvm_copy()/
   __hvm_clear()/emulate_gva_to_mfn()/hvm_hap_nested_page_fault(),
   to discard the write operations;
 - The new p2m type, p2m_mmio_write_dm, is added to P2M_RO_TYPES;
 - Coding style changes;

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.

Yu Zhang (2):
  Add a new p2m type class - P2M_DISCARD_WRITE_TYPES
  add a new p2m type - p2m_mmio_write_dm

 xen/arch/x86/hvm/hvm.c          | 25 ++++++++++---------------
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/include/asm-x86/p2m.h       |  9 ++++++++-
 xen/include/public/hvm/hvm_op.h |  1 +
 6 files changed, 22 insertions(+), 17 deletions(-)

-- 
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 Dec 12 08:43:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 08: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 1XzLoJ-000444-RA; Fri, 12 Dec 2014 08:42:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XzLoI-00043z-7k
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 08:42:50 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A2/02-08051-98AAA845; Fri, 12 Dec 2014 08:42:49 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418373766!11289899!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16967 invoked from network); 12 Dec 2014 08:42:48 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-27.messagelabs.com with SMTP;
	12 Dec 2014 08:42:48 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 12 Dec 2014 00:42:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="428128294"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by FMSMGA003.fm.intel.com with ESMTP; 12 Dec 2014 00:31:57 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Fri, 12 Dec 2014 16:12:06 +0800
Message-Id: <1418371927-32007-2-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1418371927-32007-1-git-send-email-yu.c.zhang@linux.intel.com>
References: <1418371927-32007-1-git-send-email-yu.c.zhang@linux.intel.com>
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 v7 1/2] add a new p2m type class -
	P2M_DISCARD_WRITE_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Yu Zhang <yu.c.zhang@intel.com>

Currently, the P2M_RO_TYPES bears 2 meanings: one is
"_PAGE_RW bit is clear in their PTEs", and another is
to discard the write operations on these pages. This
patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
to bear the second meaning, so we can use this type
class instead of the P2M_RO_TYPES, to decide if a write
operation is to be ignored.

Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
Reviewed-by: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/hvm/hvm.c         | 16 +++-------------
 xen/arch/x86/mm/shadow/multi.c |  2 +-
 xen/include/asm-x86/p2m.h      |  5 +++++
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index bc414ff..2eb0795 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2837,7 +2837,7 @@ 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 && (p2m_is_discard_write(p2mt))) )
     {
         put_gfn(p2m->domain, gfn);
 
@@ -2882,16 +2882,6 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
         goto out_put_gfn;
     }
 
-    /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
-    if ( npfec.write_access && (p2mt == p2m_grant_map_ro) )
-    {
-        gdprintk(XENLOG_WARNING,
-                 "trying to write to read-only grant mapping\n");
-        hvm_inject_hw_exception(TRAP_gp_fault, 0);
-        rc = 1;
-        goto out_put_gfn;
-    }
-
     /* If we fell through, the vcpu will retry now that access restrictions have
      * been removed. It may fault again if the p2m entry type still requires so.
      * Otherwise, this is an error condition. */
@@ -3941,7 +3931,7 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( flags & HVMCOPY_to_guest )
         {
-            if ( p2mt == p2m_ram_ro )
+            if ( p2m_is_discard_write(p2mt) )
             {
                 static unsigned long lastpage;
                 if ( xchg(&lastpage, gfn) != gfn )
@@ -4035,7 +4025,7 @@ static enum hvm_copy_result __hvm_clear(paddr_t addr, int size)
 
         p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
-        if ( p2mt == p2m_ram_ro )
+        if ( p2m_is_discard_write(p2mt) )
         {
             static unsigned long lastpage;
             if ( xchg(&lastpage, gfn) != gfn )
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 225290e..94cf06d 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4575,7 +4575,7 @@ static mfn_t emulate_gva_to_mfn(struct vcpu *v,
     {
         return _mfn(BAD_GFN_TO_MFN);
     }
-    if ( p2m_is_readonly(p2mt) )
+    if ( p2m_is_discard_write(p2mt) )
     {
         put_page(page);
         return _mfn(READONLY_GFN);
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 5f7fe71..42de75d 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -113,6 +113,10 @@ typedef unsigned int p2m_query_t;
                       | p2m_to_mask(p2m_grant_map_ro)   \
                       | p2m_to_mask(p2m_ram_shared) )
 
+/* Write-discard types, which should discard the write operations */
+#define P2M_DISCARD_WRITE_TYPES (p2m_to_mask(p2m_ram_ro)     \
+                      | p2m_to_mask(p2m_grant_map_ro))
+
 /* Types that can be subject to bulk transitions. */
 #define P2M_CHANGEABLE_TYPES (p2m_to_mask(p2m_ram_rw) \
                               | p2m_to_mask(p2m_ram_logdirty) )
@@ -145,6 +149,7 @@ typedef unsigned int p2m_query_t;
 #define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
 #define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
 #define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
+#define p2m_is_discard_write(_t) (p2m_to_mask(_t) & P2M_DISCARD_WRITE_TYPES)
 #define p2m_is_changeable(_t) (p2m_to_mask(_t) & P2M_CHANGEABLE_TYPES)
 #define p2m_is_pod(_t) (p2m_to_mask(_t) & P2M_POD_TYPES)
 #define p2m_is_grant(_t) (p2m_to_mask(_t) & P2M_GRANT_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 Fri Dec 12 08:43:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 08: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 1XzLoH-00043s-FS; Fri, 12 Dec 2014 08:42:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XzLoG-00043n-DC
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 08:42:48 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	A0/56-02702-78AAA845; Fri, 12 Dec 2014 08:42:47 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418373766!11289899!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16770 invoked from network); 12 Dec 2014 08:42:47 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-27.messagelabs.com with SMTP;
	12 Dec 2014 08:42:47 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 12 Dec 2014 00:42:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="428128285"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by FMSMGA003.fm.intel.com with ESMTP; 12 Dec 2014 00:31:54 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Fri, 12 Dec 2014 16:12:05 +0800
Message-Id: <1418371927-32007-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 v7 0/2] add new p2m type class and new p2m 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

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 added
a new p2m type, p2m_mmio_write_dm, to trap and emulate the write
operations 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_ram_ro types, write operations will not
trigger the device model, and will be discarded later in __hvm_copy();
while for the 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 v6:
 - Handle the new p2m type in the shadow-pagetable code.

Changes from v5:
 - Stricter type checks for p2m type transitions;
 - One code style change.

Changes from v4:
 - A new p2m type class, P2M_DISCARD_WRITE_TYPES, is added;
 - A new predicate, p2m_is_discard_write, is used in __hvm_copy()/
   __hvm_clear()/emulate_gva_to_mfn()/hvm_hap_nested_page_fault(),
   to discard the write operations;
 - The new p2m type, p2m_mmio_write_dm, is added to P2M_RO_TYPES;
 - Coding style changes;

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.

Yu Zhang (2):
  Add a new p2m type class - P2M_DISCARD_WRITE_TYPES
  add a new p2m type - p2m_mmio_write_dm

 xen/arch/x86/hvm/hvm.c          | 25 ++++++++++---------------
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/include/asm-x86/p2m.h       |  9 ++++++++-
 xen/include/public/hvm/hvm_op.h |  1 +
 6 files changed, 22 insertions(+), 17 deletions(-)

-- 
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 Dec 12 08:43:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 08: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 1XzLoM-00044I-6l; Fri, 12 Dec 2014 08:42:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XzLoL-00044B-3W
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 08:42:53 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	BF/4B-02696-C8AAA845; Fri, 12 Dec 2014 08:42:52 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418373766!11289899!3
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17362 invoked from network); 12 Dec 2014 08:42:51 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-27.messagelabs.com with SMTP;
	12 Dec 2014 08:42:51 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 12 Dec 2014 00:42:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="428128303"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by FMSMGA003.fm.intel.com with ESMTP; 12 Dec 2014 00:31:59 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Fri, 12 Dec 2014 16:12:07 +0800
Message-Id: <1418371927-32007-3-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1418371927-32007-1-git-send-email-yu.c.zhang@linux.intel.com>
References: <1418371927-32007-1-git-send-email-yu.c.zhang@linux.intel.com>
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 v7 2/2] add a new p2m type - 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

From: Yu Zhang <yu.c.zhang@intel.com>

A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
model, and will be discarded later in __hvm_copy(); while for the
p2m_mmio_write_dm type pages, writes will go to the device model
via ioreq-server.

Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: Wei Ye <wei.ye@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/hvm/hvm.c          | 11 ++++++++---
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/arch/x86/mm/shadow/multi.c  |  3 ++-
 xen/include/asm-x86/p2m.h       |  4 +++-
 xen/include/public/hvm/hvm_op.h |  1 +
 6 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 2eb0795..f66f2c6 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2837,7 +2837,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 && (p2m_is_discard_write(p2mt))) )
+         (npfec.write_access &&
+          (p2m_is_discard_write(p2mt) || (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)
             get_gfn_query_unlocked(d, a.pfn, &t);
             if ( p2m_is_mmio(t) )
                 a.mem_type =  HVMMEM_mmio_dm;
+            else if ( t == p2m_mmio_write_dm )
+                a.mem_type = HVMMEM_mmio_write_dm;
             else if ( p2m_is_readonly(t) )
                 a.mem_type =  HVMMEM_ram_ro;
             else if ( p2m_is_ram(t) )
@@ -5949,7 +5952,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) )
@@ -5996,7 +6000,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
                 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 || a.hvmmem_type != HVMMEM_ram_rw) )
             {
                 put_gfn(d, pfn);
                 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/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 94cf06d..65815bb 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3181,7 +3181,8 @@ static int sh_page_fault(struct vcpu *v,
     }
 
     /* Need to hand off device-model MMIO to the device model */
-    if ( p2mt == p2m_mmio_dm ) 
+    if ( p2mt == p2m_mmio_dm
+         || (p2mt == p2m_mmio_write_dm && ft == ft_demand_write) )
     {
         gpa = guest_walk_to_gpa(&gw);
         goto mmio;
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 42de75d..2cf73ca 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 */
@@ -111,7 +112,8 @@ typedef unsigned int p2m_query_t;
 #define P2M_RO_TYPES (p2m_to_mask(p2m_ram_logdirty)     \
                       | p2m_to_mask(p2m_ram_ro)         \
                       | p2m_to_mask(p2m_grant_map_ro)   \
-                      | p2m_to_mask(p2m_ram_shared) )
+                      | p2m_to_mask(p2m_ram_shared)     \
+                      | p2m_to_mask(p2m_mmio_write_dm))
 
 /* Write-discard types, which should discard the write operations */
 #define P2M_DISCARD_WRITE_TYPES (p2m_to_mask(p2m_ram_ro)     \
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 Dec 12 08:43:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 08: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 1XzLoM-00044I-6l; Fri, 12 Dec 2014 08:42:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XzLoL-00044B-3W
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 08:42:53 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	BF/4B-02696-C8AAA845; Fri, 12 Dec 2014 08:42:52 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418373766!11289899!3
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17362 invoked from network); 12 Dec 2014 08:42:51 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-27.messagelabs.com with SMTP;
	12 Dec 2014 08:42:51 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 12 Dec 2014 00:42:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="428128303"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by FMSMGA003.fm.intel.com with ESMTP; 12 Dec 2014 00:31:59 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Fri, 12 Dec 2014 16:12:07 +0800
Message-Id: <1418371927-32007-3-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1418371927-32007-1-git-send-email-yu.c.zhang@linux.intel.com>
References: <1418371927-32007-1-git-send-email-yu.c.zhang@linux.intel.com>
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 v7 2/2] add a new p2m type - 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

From: Yu Zhang <yu.c.zhang@intel.com>

A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's 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_ram_ro types, write operations will not trigger the device
model, and will be discarded later in __hvm_copy(); while for the
p2m_mmio_write_dm type pages, writes will go to the device model
via ioreq-server.

Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: Wei Ye <wei.ye@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/hvm/hvm.c          | 11 ++++++++---
 xen/arch/x86/mm/p2m-ept.c       |  1 +
 xen/arch/x86/mm/p2m-pt.c        |  1 +
 xen/arch/x86/mm/shadow/multi.c  |  3 ++-
 xen/include/asm-x86/p2m.h       |  4 +++-
 xen/include/public/hvm/hvm_op.h |  1 +
 6 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 2eb0795..f66f2c6 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2837,7 +2837,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 && (p2m_is_discard_write(p2mt))) )
+         (npfec.write_access &&
+          (p2m_is_discard_write(p2mt) || (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)
             get_gfn_query_unlocked(d, a.pfn, &t);
             if ( p2m_is_mmio(t) )
                 a.mem_type =  HVMMEM_mmio_dm;
+            else if ( t == p2m_mmio_write_dm )
+                a.mem_type = HVMMEM_mmio_write_dm;
             else if ( p2m_is_readonly(t) )
                 a.mem_type =  HVMMEM_ram_ro;
             else if ( p2m_is_ram(t) )
@@ -5949,7 +5952,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) )
@@ -5996,7 +6000,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
                 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 || a.hvmmem_type != HVMMEM_ram_rw) )
             {
                 put_gfn(d, pfn);
                 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/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 94cf06d..65815bb 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3181,7 +3181,8 @@ static int sh_page_fault(struct vcpu *v,
     }
 
     /* Need to hand off device-model MMIO to the device model */
-    if ( p2mt == p2m_mmio_dm ) 
+    if ( p2mt == p2m_mmio_dm
+         || (p2mt == p2m_mmio_write_dm && ft == ft_demand_write) )
     {
         gpa = guest_walk_to_gpa(&gw);
         goto mmio;
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 42de75d..2cf73ca 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 */
@@ -111,7 +112,8 @@ typedef unsigned int p2m_query_t;
 #define P2M_RO_TYPES (p2m_to_mask(p2m_ram_logdirty)     \
                       | p2m_to_mask(p2m_ram_ro)         \
                       | p2m_to_mask(p2m_grant_map_ro)   \
-                      | p2m_to_mask(p2m_ram_shared) )
+                      | p2m_to_mask(p2m_ram_shared)     \
+                      | p2m_to_mask(p2m_mmio_write_dm))
 
 /* Write-discard types, which should discard the write operations */
 #define P2M_DISCARD_WRITE_TYPES (p2m_to_mask(p2m_ram_ro)     \
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 Dec 12 08:43:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 08: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 1XzLoJ-000444-RA; Fri, 12 Dec 2014 08:42:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yu.c.zhang@linux.intel.com>) id 1XzLoI-00043z-7k
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 08:42:50 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A2/02-08051-98AAA845; Fri, 12 Dec 2014 08:42:49 +0000
X-Env-Sender: yu.c.zhang@linux.intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418373766!11289899!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16967 invoked from network); 12 Dec 2014 08:42:48 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-27.messagelabs.com with SMTP;
	12 Dec 2014 08:42:48 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 12 Dec 2014 00:42:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="428128294"
Received: from zhangyu-xengt.bj.intel.com ([10.238.157.61])
	by FMSMGA003.fm.intel.com with ESMTP; 12 Dec 2014 00:31:57 -0800
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Xen-devel@lists.xen.org
Date: Fri, 12 Dec 2014 16:12:06 +0800
Message-Id: <1418371927-32007-2-git-send-email-yu.c.zhang@linux.intel.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <1418371927-32007-1-git-send-email-yu.c.zhang@linux.intel.com>
References: <1418371927-32007-1-git-send-email-yu.c.zhang@linux.intel.com>
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 v7 1/2] add a new p2m type class -
	P2M_DISCARD_WRITE_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Yu Zhang <yu.c.zhang@intel.com>

Currently, the P2M_RO_TYPES bears 2 meanings: one is
"_PAGE_RW bit is clear in their PTEs", and another is
to discard the write operations on these pages. This
patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
to bear the second meaning, so we can use this type
class instead of the P2M_RO_TYPES, to decide if a write
operation is to be ignored.

Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
Reviewed-by: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/hvm/hvm.c         | 16 +++-------------
 xen/arch/x86/mm/shadow/multi.c |  2 +-
 xen/include/asm-x86/p2m.h      |  5 +++++
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index bc414ff..2eb0795 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2837,7 +2837,7 @@ 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 && (p2m_is_discard_write(p2mt))) )
     {
         put_gfn(p2m->domain, gfn);
 
@@ -2882,16 +2882,6 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
         goto out_put_gfn;
     }
 
-    /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
-    if ( npfec.write_access && (p2mt == p2m_grant_map_ro) )
-    {
-        gdprintk(XENLOG_WARNING,
-                 "trying to write to read-only grant mapping\n");
-        hvm_inject_hw_exception(TRAP_gp_fault, 0);
-        rc = 1;
-        goto out_put_gfn;
-    }
-
     /* If we fell through, the vcpu will retry now that access restrictions have
      * been removed. It may fault again if the p2m entry type still requires so.
      * Otherwise, this is an error condition. */
@@ -3941,7 +3931,7 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( flags & HVMCOPY_to_guest )
         {
-            if ( p2mt == p2m_ram_ro )
+            if ( p2m_is_discard_write(p2mt) )
             {
                 static unsigned long lastpage;
                 if ( xchg(&lastpage, gfn) != gfn )
@@ -4035,7 +4025,7 @@ static enum hvm_copy_result __hvm_clear(paddr_t addr, int size)
 
         p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
 
-        if ( p2mt == p2m_ram_ro )
+        if ( p2m_is_discard_write(p2mt) )
         {
             static unsigned long lastpage;
             if ( xchg(&lastpage, gfn) != gfn )
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 225290e..94cf06d 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4575,7 +4575,7 @@ static mfn_t emulate_gva_to_mfn(struct vcpu *v,
     {
         return _mfn(BAD_GFN_TO_MFN);
     }
-    if ( p2m_is_readonly(p2mt) )
+    if ( p2m_is_discard_write(p2mt) )
     {
         put_page(page);
         return _mfn(READONLY_GFN);
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 5f7fe71..42de75d 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -113,6 +113,10 @@ typedef unsigned int p2m_query_t;
                       | p2m_to_mask(p2m_grant_map_ro)   \
                       | p2m_to_mask(p2m_ram_shared) )
 
+/* Write-discard types, which should discard the write operations */
+#define P2M_DISCARD_WRITE_TYPES (p2m_to_mask(p2m_ram_ro)     \
+                      | p2m_to_mask(p2m_grant_map_ro))
+
 /* Types that can be subject to bulk transitions. */
 #define P2M_CHANGEABLE_TYPES (p2m_to_mask(p2m_ram_rw) \
                               | p2m_to_mask(p2m_ram_logdirty) )
@@ -145,6 +149,7 @@ typedef unsigned int p2m_query_t;
 #define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
 #define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
 #define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
+#define p2m_is_discard_write(_t) (p2m_to_mask(_t) & P2M_DISCARD_WRITE_TYPES)
 #define p2m_is_changeable(_t) (p2m_to_mask(_t) & P2M_CHANGEABLE_TYPES)
 #define p2m_is_pod(_t) (p2m_to_mask(_t) & P2M_POD_TYPES)
 #define p2m_is_grant(_t) (p2m_to_mask(_t) & P2M_GRANT_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 Fri Dec 12 09:31:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 09: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 1XzMYa-0005hs-2l; Fri, 12 Dec 2014 09:30:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XzMYY-0005hn-Oa
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 09:30:38 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	D6/B0-02954-DB5BA845; Fri, 12 Dec 2014 09:30:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418376634!14607706!1
X-Originating-IP: [66.165.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 17511 invoked from network); 12 Dec 2014 09:30:36 -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 Dec 2014 09:30:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,561,1413244800"; d="scan'208";a="203386347"
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.210.2; Fri, 12 Dec 2014 04: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 1XzMYT-0004Dx-M3;
	Fri, 12 Dec 2014 09: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 1XzMYT-0006SO-ER;
	Fri, 12 Dec 2014 09:30:33 +0000
Date: Fri, 12 Dec 2014 09:30:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32239-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] 32239: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32239 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32239/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 32171
 test-amd64-i386-libvirt       5 xen-boot                  fail REGR. vs. 32171
 test-amd64-amd64-libvirt      5 xen-boot                  fail REGR. vs. 32171
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 32171
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot            fail REGR. vs. 32171
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 32171
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 32171
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 32171
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32171
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 32171
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32171
 test-amd64-i386-freebsd10-amd64  5 xen-boot               fail REGR. vs. 32171
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32171
 test-amd64-i386-freebsd10-i386  5 xen-boot                fail REGR. vs. 32171
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 32171
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot           fail REGR. vs. 32171
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot             fail REGR. vs. 32171
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32171
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32171
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32171
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot           fail REGR. vs. 32171
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 32171
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 32171
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 32171
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32171
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32171
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot          fail REGR. vs. 32171
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32171
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32171
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 32171
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 32171
 test-amd64-i386-xl-winxpsp3   5 xen-boot                  fail REGR. vs. 32171
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot             fail REGR. vs. 32171
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 32171
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 32171
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot            fail REGR. vs. 32171
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 32171
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32171
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 32171
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 32171
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 32171

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 32171
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 32171
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 32171

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

version targeted for testing:
 linux                12fd07251e19050ca979d9ce5d4b6bcb41dc00e9
baseline version:
 linux                b2776bf7149bddd1f4161f14f79520f17fc1d71d

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                                 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 Fri Dec 12 09:31:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 09: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 1XzMYa-0005hs-2l; Fri, 12 Dec 2014 09:30:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XzMYY-0005hn-Oa
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 09:30:38 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	D6/B0-02954-DB5BA845; Fri, 12 Dec 2014 09:30:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418376634!14607706!1
X-Originating-IP: [66.165.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 17511 invoked from network); 12 Dec 2014 09:30:36 -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 Dec 2014 09:30:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,561,1413244800"; d="scan'208";a="203386347"
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.210.2; Fri, 12 Dec 2014 04: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 1XzMYT-0004Dx-M3;
	Fri, 12 Dec 2014 09: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 1XzMYT-0006SO-ER;
	Fri, 12 Dec 2014 09:30:33 +0000
Date: Fri, 12 Dec 2014 09:30:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32239-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] 32239: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32239 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32239/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 32171
 test-amd64-i386-libvirt       5 xen-boot                  fail REGR. vs. 32171
 test-amd64-amd64-libvirt      5 xen-boot                  fail REGR. vs. 32171
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 32171
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot            fail REGR. vs. 32171
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 32171
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 32171
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 32171
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32171
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 32171
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32171
 test-amd64-i386-freebsd10-amd64  5 xen-boot               fail REGR. vs. 32171
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32171
 test-amd64-i386-freebsd10-i386  5 xen-boot                fail REGR. vs. 32171
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 32171
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot           fail REGR. vs. 32171
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot             fail REGR. vs. 32171
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32171
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32171
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32171
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot           fail REGR. vs. 32171
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 32171
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 32171
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 32171
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32171
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32171
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot          fail REGR. vs. 32171
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32171
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32171
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 32171
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 32171
 test-amd64-i386-xl-winxpsp3   5 xen-boot                  fail REGR. vs. 32171
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot             fail REGR. vs. 32171
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 32171
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 32171
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot            fail REGR. vs. 32171
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 32171
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32171
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 32171
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 32171
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 32171

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 32171
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 32171
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 32171

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

version targeted for testing:
 linux                12fd07251e19050ca979d9ce5d4b6bcb41dc00e9
baseline version:
 linux                b2776bf7149bddd1f4161f14f79520f17fc1d71d

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                                 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 Fri Dec 12 09:45:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 09: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 1XzMmn-0006T8-6i; Fri, 12 Dec 2014 09:45:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XzMml-0006T3-BU
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 09:45:19 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	48/31-18267-E29BA845; Fri, 12 Dec 2014 09:45:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418377518!12862371!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5544 invoked from network); 12 Dec 2014 09:45:18 -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 Dec 2014 09:45:18 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 12 Dec 2014 09:45:17 +0000
Message-Id: <548AC73D020000780004F2F6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 12 Dec 2014 09:45:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5489906B020000780004EE34@mail.emea.novell.com>
	<69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.com>
	<5489C88F020000780004F0C2@mail.emea.novell.com>
	<20141211194148.GG18992@laptop.dumpdata.com>
In-Reply-To: <20141211194148.GG18992@laptop.dumpdata.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.14 at 20:41, <konrad.wilk@oracle.com> wrote:
> On Thu, Dec 11, 2014 at 03:38:39PM +0000, Jan Beulich wrote:
>> >>> On 11.12.14 at 16:18, <konrad.wilk@oracle.com> wrote:
>> > A proper fix would be to automatically adjust based on memmap and CPU but 
>> > that could be too complex.
>> 
>> The problem isn't the complexity, but the chicken-and-egg problem
>> as far as CPU count is concerned. The memory map size would be
>> known early enough.
> 
> Let me explain my thought process:
>  - There are existing knobs that can be used to change this (conring_size=X)
>  - But we would like an awesome release where those knobs don't have to
>    be used.
>  - The patch you posted could be reworked to fully address memmap and CPU.

Not really, unless we separate parsing and printing of the ACPI
tables. Again, the CPU count is known only after that parsing.

>  - I don't know what your time constraints are for said patch and you
>    might not have the energy to rework it.
>  - I don't want to put pressure on you or Daniel on having to write new
>    patches - especially as folks are going on vacation soon.
> 
> Hence as a fallback I believe that Daniel's patch should go in and
> Jan's patch can go in too. However if Jan (or somebody else) wants to
> rework the v2 (or a new one) to address the memmap issue then that
> patch would go in - instead of Daniel's or v2 of Jan patch.

Which memmap issue? You confirmed in your reply that you understand
that the memmap gets printed late enough for the change in v2 to
take effect. Plus those are info-level messages, and hence don't get
printed at all by default. And if somebody alters the log levels, (s)he
can surely be expected to also adjust the ring size. (The log level
aspect is actually another argument against Daniel's 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 Dec 12 09:45:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 09: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 1XzMmn-0006T8-6i; Fri, 12 Dec 2014 09:45:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XzMml-0006T3-BU
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 09:45:19 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	48/31-18267-E29BA845; Fri, 12 Dec 2014 09:45:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418377518!12862371!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5544 invoked from network); 12 Dec 2014 09:45:18 -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 Dec 2014 09:45:18 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 12 Dec 2014 09:45:17 +0000
Message-Id: <548AC73D020000780004F2F6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 12 Dec 2014 09:45:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5489906B020000780004EE34@mail.emea.novell.com>
	<69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.com>
	<5489C88F020000780004F0C2@mail.emea.novell.com>
	<20141211194148.GG18992@laptop.dumpdata.com>
In-Reply-To: <20141211194148.GG18992@laptop.dumpdata.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.14 at 20:41, <konrad.wilk@oracle.com> wrote:
> On Thu, Dec 11, 2014 at 03:38:39PM +0000, Jan Beulich wrote:
>> >>> On 11.12.14 at 16:18, <konrad.wilk@oracle.com> wrote:
>> > A proper fix would be to automatically adjust based on memmap and CPU but 
>> > that could be too complex.
>> 
>> The problem isn't the complexity, but the chicken-and-egg problem
>> as far as CPU count is concerned. The memory map size would be
>> known early enough.
> 
> Let me explain my thought process:
>  - There are existing knobs that can be used to change this (conring_size=X)
>  - But we would like an awesome release where those knobs don't have to
>    be used.
>  - The patch you posted could be reworked to fully address memmap and CPU.

Not really, unless we separate parsing and printing of the ACPI
tables. Again, the CPU count is known only after that parsing.

>  - I don't know what your time constraints are for said patch and you
>    might not have the energy to rework it.
>  - I don't want to put pressure on you or Daniel on having to write new
>    patches - especially as folks are going on vacation soon.
> 
> Hence as a fallback I believe that Daniel's patch should go in and
> Jan's patch can go in too. However if Jan (or somebody else) wants to
> rework the v2 (or a new one) to address the memmap issue then that
> patch would go in - instead of Daniel's or v2 of Jan patch.

Which memmap issue? You confirmed in your reply that you understand
that the memmap gets printed late enough for the change in v2 to
take effect. Plus those are info-level messages, and hence don't get
printed at all by default. And if somebody alters the log levels, (s)he
can surely be expected to also adjust the ring size. (The log level
aspect is actually another argument against Daniel's 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 Dec 12 10:07:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 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 1XzN8D-0007FY-6V; Fri, 12 Dec 2014 10:07:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XzN8B-0007FT-Hc
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 10:07:27 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1C/5C-15461-E5EBA845; Fri, 12 Dec 2014 10:07:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418378845!15175651!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 12022 invoked from network); 12 Dec 2014 10:07:26 -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;
	12 Dec 2014 10:07:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,561,1413244800"; d="scan'208";a="203396073"
Message-ID: <1418378843.23309.43.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 12 Dec 2014 10:07:23 +0000
In-Reply-To: <20141210180144.GB4441@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210180144.GB4441@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
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>
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 19:01 +0100, Olaf Hering wrote:
> On Wed, Dec 10, Ian Campbell wrote:
> 
> > Separately from the above I wonder if it might be worth moving the
> > xenstore readiness check into the xen-init-dom0 helper and having most
> > things which currently depend on xenstore actually depend on the
> > "dom0-is-ready" unit, which itself depends on xenstored, qemu-dom0 and
> > whatever else is supposed to be ready in a dom0?
> 
> You mean something like this chain of depencencies?
> 
>  xenstored
>  xen-init-dom0
>  xenconsoled | qemu-dom0
>  xendomains

If you mean | to be "in parallel" rather than "or" then yes, I think
that's what I meant, or something like 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 Dec 12 10:07:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 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 1XzN8D-0007FY-6V; Fri, 12 Dec 2014 10:07:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XzN8B-0007FT-Hc
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 10:07:27 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1C/5C-15461-E5EBA845; Fri, 12 Dec 2014 10:07:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418378845!15175651!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 12022 invoked from network); 12 Dec 2014 10:07:26 -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;
	12 Dec 2014 10:07:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,561,1413244800"; d="scan'208";a="203396073"
Message-ID: <1418378843.23309.43.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 12 Dec 2014 10:07:23 +0000
In-Reply-To: <20141210180144.GB4441@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210180144.GB4441@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
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>
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 19:01 +0100, Olaf Hering wrote:
> On Wed, Dec 10, Ian Campbell wrote:
> 
> > Separately from the above I wonder if it might be worth moving the
> > xenstore readiness check into the xen-init-dom0 helper and having most
> > things which currently depend on xenstore actually depend on the
> > "dom0-is-ready" unit, which itself depends on xenstored, qemu-dom0 and
> > whatever else is supposed to be ready in a dom0?
> 
> You mean something like this chain of depencencies?
> 
>  xenstored
>  xen-init-dom0
>  xenconsoled | qemu-dom0
>  xendomains

If you mean | to be "in parallel" rather than "or" then yes, I think
that's what I meant, or something like 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 Dec 12 10:11:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 10:11:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzNBe-0007NN-Q4; Fri, 12 Dec 2014 10:11: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 1XzNBd-0007NG-L0
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 10:11:01 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	8F/2F-05632-43FBA845; Fri, 12 Dec 2014 10:11:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418379059!10421896!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 1688 invoked from network); 12 Dec 2014 10:11:00 -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;
	12 Dec 2014 10:11:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,561,1413244800"; d="scan'208";a="203396908"
Message-ID: <1418379056.23309.45.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 12 Dec 2014 10:10:56 +0000
In-Reply-To: <20141210175251.GA4441@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210175251.GA4441@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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>
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 18:52 +0100, Olaf Hering wrote:
> On Wed, Dec 10, Ian Campbell wrote:
> 
> > That results in a wrapper which unconditionally execs, the systemd unit
> > just calls that while the sysv script runs the wrapper and then does the
> > xenstore-read -s loop. 
> 
> Since systemd handles the socket there is already a listener.
> http://lists.freedesktop.org/archives/systemd-devel/2014-December/026157.html

Not sure I understand what any of that means, but I'll assume it's
good ;-)

> I came up with this, works in my testing with SLE11 sysv and Factory
> systemd. The beef looks like shown below.  Let me know if thats good
> enough to handle XENSTORED_TRACE also in systemd. I will add some
> comments to the wrapper why it is there.

Seems ok. I wonder if the wrapper ought to source
@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
rather than relying on the initscript and unit file to do so. Especially
in the initscript case it looks a bit ugly to have to manually propagate
things.

> 
> Olaf
> 
> diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
> index a1095c2..f57bfd3 100644
> --- a/tools/hotplug/Linux/init.d/xencommons.in
> +++ b/tools/hotplug/Linux/init.d/xencommons.in
> @@ -66,11 +66,13 @@ do_start () {
>  	then
>  		test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
>  		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
> -		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
>  
>  		if [ -n "$XENSTORED" ] ; then
>  		    echo -n Starting $XENSTORED...
> -		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
> +		    XENSTORED=$XENSTORED \
> +		    XENSTORED_TRACE=$XENSTORED_TRACE \
> +		    XENSTORED_ARGS=$XENSTORED_ARGS \
> +		    ${LIBEXEC_BIN}/xenstored.sh --pid-file /var/run/xenstored.pid
>  		else
>  		    echo "No xenstored found"
>  		    exit 1
> diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
> index 0f0ac58..d906ea2 100644
> --- a/tools/hotplug/Linux/systemd/xenstored.service.in
> +++ b/tools/hotplug/Linux/systemd/xenstored.service.in
> @@ -8,13 +8,12 @@ ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
>  Type=notify
> -Environment=XENSTORED_ARGS=
>  Environment=XENSTORED=@XENSTORED@
> -EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/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@
> -ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
> +ExecStart=-@LIBEXEC_BIN@/xenstored.sh --no-fork
>  
>  [Install]
>  WantedBy=multi-user.target
> diff --git a/tools/hotplug/Linux/xenstored.sh.in b/tools/hotplug/Linux/xenstored.sh.in
> new file mode 100644
> index 0000000..dc806ee
> --- /dev/null
> +++ b/tools/hotplug/Linux/xenstored.sh.in
> @@ -0,0 +1,6 @@
> +#!/bin/sh
> +if test -n "$XENSTORED_TRACE"
> +then
> +	XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
> +fi
> +exec $XENSTORED $@ $XENSTORED_ARGS
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 12 10:11:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 10:11:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzNBe-0007NN-Q4; Fri, 12 Dec 2014 10:11: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 1XzNBd-0007NG-L0
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 10:11:01 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	8F/2F-05632-43FBA845; Fri, 12 Dec 2014 10:11:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418379059!10421896!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 1688 invoked from network); 12 Dec 2014 10:11:00 -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;
	12 Dec 2014 10:11:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,561,1413244800"; d="scan'208";a="203396908"
Message-ID: <1418379056.23309.45.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 12 Dec 2014 10:10:56 +0000
In-Reply-To: <20141210175251.GA4441@aepfle.de>
References: <1417781152-9926-1-git-send-email-olaf@aepfle.de>
	<1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210175251.GA4441@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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>
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-10 at 18:52 +0100, Olaf Hering wrote:
> On Wed, Dec 10, Ian Campbell wrote:
> 
> > That results in a wrapper which unconditionally execs, the systemd unit
> > just calls that while the sysv script runs the wrapper and then does the
> > xenstore-read -s loop. 
> 
> Since systemd handles the socket there is already a listener.
> http://lists.freedesktop.org/archives/systemd-devel/2014-December/026157.html

Not sure I understand what any of that means, but I'll assume it's
good ;-)

> I came up with this, works in my testing with SLE11 sysv and Factory
> systemd. The beef looks like shown below.  Let me know if thats good
> enough to handle XENSTORED_TRACE also in systemd. I will add some
> comments to the wrapper why it is there.

Seems ok. I wonder if the wrapper ought to source
@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
rather than relying on the initscript and unit file to do so. Especially
in the initscript case it looks a bit ugly to have to manually propagate
things.

> 
> Olaf
> 
> diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
> index a1095c2..f57bfd3 100644
> --- a/tools/hotplug/Linux/init.d/xencommons.in
> +++ b/tools/hotplug/Linux/init.d/xencommons.in
> @@ -66,11 +66,13 @@ do_start () {
>  	then
>  		test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
>  		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
> -		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
>  
>  		if [ -n "$XENSTORED" ] ; then
>  		    echo -n Starting $XENSTORED...
> -		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
> +		    XENSTORED=$XENSTORED \
> +		    XENSTORED_TRACE=$XENSTORED_TRACE \
> +		    XENSTORED_ARGS=$XENSTORED_ARGS \
> +		    ${LIBEXEC_BIN}/xenstored.sh --pid-file /var/run/xenstored.pid
>  		else
>  		    echo "No xenstored found"
>  		    exit 1
> diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
> index 0f0ac58..d906ea2 100644
> --- a/tools/hotplug/Linux/systemd/xenstored.service.in
> +++ b/tools/hotplug/Linux/systemd/xenstored.service.in
> @@ -8,13 +8,12 @@ ConditionPathExists=/proc/xen/capabilities
>  
>  [Service]
>  Type=notify
> -Environment=XENSTORED_ARGS=
>  Environment=XENSTORED=@XENSTORED@
> -EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/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@
> -ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
> +ExecStart=-@LIBEXEC_BIN@/xenstored.sh --no-fork
>  
>  [Install]
>  WantedBy=multi-user.target
> diff --git a/tools/hotplug/Linux/xenstored.sh.in b/tools/hotplug/Linux/xenstored.sh.in
> new file mode 100644
> index 0000000..dc806ee
> --- /dev/null
> +++ b/tools/hotplug/Linux/xenstored.sh.in
> @@ -0,0 +1,6 @@
> +#!/bin/sh
> +if test -n "$XENSTORED_TRACE"
> +then
> +	XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
> +fi
> +exec $XENSTORED $@ $XENSTORED_ARGS
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 12 10:24:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 10:24:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzNOW-00085o-4A; Fri, 12 Dec 2014 10:24:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XzNOU-00085j-Oj
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 10:24:18 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	28/3C-09284-152CA845; Fri, 12 Dec 2014 10:24:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418379857!12847698!1
X-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 25242 invoked from network); 12 Dec 2014 10:24:17 -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; 12 Dec 2014 10:24:17 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 12 Dec 2014 10:24:16 +0000
Message-Id: <548AD05D020000780004F329@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 12 Dec 2014 10:24:13 +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>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 545607eb3c ("x86: fix various issues with handling guest IRQs")
wasn't really consistent in one respect: The granting of access to an
IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
domains. In fact it is wrong to assume that a translation is already/
still in place at the time access is being granted/revoked.

What is wanted is to translate the incoming pIRQ to an IRQ for
the invoking domain (as the pIRQ is the only notion the invoking
domain has of the IRQ), and grant the subject domain access to
the resulting IRQ.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Also fix initial range check to use current->domain, adjust code
    structure, and extend description (all requested by Ian). Along
    the lines of the first mentioned change, also pass the Xen IRQ
    number to the XSM hook (confirmed okay by Daniel).
Note that I would hope for this to make unnecessary Stefano's proposed
tools side change
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00160.html.

--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -982,18 +982,21 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
 
     case XEN_DOMCTL_irq_permission:
     {
-        unsigned int pirq = op->u.irq_permission.pirq;
+        unsigned int pirq = op->u.irq_permission.pirq, irq;
         int allow = op->u.irq_permission.allow_access;
 
-        if ( pirq >= d->nr_pirqs )
+        if ( pirq >= current->domain->nr_pirqs )
+        {
             ret = -EINVAL;
-        else if ( !pirq_access_permitted(current->domain, pirq) ||
-                  xsm_irq_permission(XSM_HOOK, d, pirq, allow) )
+            break;
+        }
+        irq = pirq_access_permitted(current->domain, pirq);
+        if ( !irq || xsm_irq_permission(XSM_HOOK, d, irq, allow) )
             ret = -EPERM;
         else if ( allow )
-            ret = pirq_permit_access(d, pirq);
+            ret = irq_permit_access(d, irq);
         else
-            ret = pirq_deny_access(d, pirq);
+            ret = irq_deny_access(d, irq);
     }
     break;
 
--- a/xen/include/xen/iocap.h
+++ b/xen/include/xen/iocap.h
@@ -28,22 +28,11 @@
 #define irq_access_permitted(d, i)                      \
     rangeset_contains_singleton((d)->irq_caps, i)
 
-#define pirq_permit_access(d, i) ({                     \
-    struct domain *d__ = (d);                           \
-    int i__ = domain_pirq_to_irq(d__, i);               \
-    i__ > 0 ? rangeset_add_singleton(d__->irq_caps, i__)\
-            : -EINVAL;                                  \
-})
-#define pirq_deny_access(d, i) ({                       \
-    struct domain *d__ = (d);                           \
-    int i__ = domain_pirq_to_irq(d__, i);               \
-    i__ > 0 ? rangeset_remove_singleton(d__->irq_caps, i__)\
-            : -EINVAL;                                  \
-})
 #define pirq_access_permitted(d, i) ({                  \
     struct domain *d__ = (d);                           \
-    rangeset_contains_singleton(d__->irq_caps,          \
-                                domain_pirq_to_irq(d__, i));\
+    int irq__ = domain_pirq_to_irq(d__, i);             \
+    irq__ > 0 && irq_access_permitted(d__, irq__)       \
+    ? irq__ : 0;                                        \
 })
 
 #endif /* __XEN_IOCAP_H__ */




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 10:24:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 10:24:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzNOW-00085o-4A; Fri, 12 Dec 2014 10:24:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XzNOU-00085j-Oj
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 10:24:18 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	28/3C-09284-152CA845; Fri, 12 Dec 2014 10:24:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418379857!12847698!1
X-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 25242 invoked from network); 12 Dec 2014 10:24:17 -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; 12 Dec 2014 10:24:17 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 12 Dec 2014 10:24:16 +0000
Message-Id: <548AD05D020000780004F329@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 12 Dec 2014 10:24:13 +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>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 545607eb3c ("x86: fix various issues with handling guest IRQs")
wasn't really consistent in one respect: The granting of access to an
IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
domains. In fact it is wrong to assume that a translation is already/
still in place at the time access is being granted/revoked.

What is wanted is to translate the incoming pIRQ to an IRQ for
the invoking domain (as the pIRQ is the only notion the invoking
domain has of the IRQ), and grant the subject domain access to
the resulting IRQ.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Also fix initial range check to use current->domain, adjust code
    structure, and extend description (all requested by Ian). Along
    the lines of the first mentioned change, also pass the Xen IRQ
    number to the XSM hook (confirmed okay by Daniel).
Note that I would hope for this to make unnecessary Stefano's proposed
tools side change
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00160.html.

--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -982,18 +982,21 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
 
     case XEN_DOMCTL_irq_permission:
     {
-        unsigned int pirq = op->u.irq_permission.pirq;
+        unsigned int pirq = op->u.irq_permission.pirq, irq;
         int allow = op->u.irq_permission.allow_access;
 
-        if ( pirq >= d->nr_pirqs )
+        if ( pirq >= current->domain->nr_pirqs )
+        {
             ret = -EINVAL;
-        else if ( !pirq_access_permitted(current->domain, pirq) ||
-                  xsm_irq_permission(XSM_HOOK, d, pirq, allow) )
+            break;
+        }
+        irq = pirq_access_permitted(current->domain, pirq);
+        if ( !irq || xsm_irq_permission(XSM_HOOK, d, irq, allow) )
             ret = -EPERM;
         else if ( allow )
-            ret = pirq_permit_access(d, pirq);
+            ret = irq_permit_access(d, irq);
         else
-            ret = pirq_deny_access(d, pirq);
+            ret = irq_deny_access(d, irq);
     }
     break;
 
--- a/xen/include/xen/iocap.h
+++ b/xen/include/xen/iocap.h
@@ -28,22 +28,11 @@
 #define irq_access_permitted(d, i)                      \
     rangeset_contains_singleton((d)->irq_caps, i)
 
-#define pirq_permit_access(d, i) ({                     \
-    struct domain *d__ = (d);                           \
-    int i__ = domain_pirq_to_irq(d__, i);               \
-    i__ > 0 ? rangeset_add_singleton(d__->irq_caps, i__)\
-            : -EINVAL;                                  \
-})
-#define pirq_deny_access(d, i) ({                       \
-    struct domain *d__ = (d);                           \
-    int i__ = domain_pirq_to_irq(d__, i);               \
-    i__ > 0 ? rangeset_remove_singleton(d__->irq_caps, i__)\
-            : -EINVAL;                                  \
-})
 #define pirq_access_permitted(d, i) ({                  \
     struct domain *d__ = (d);                           \
-    rangeset_contains_singleton(d__->irq_caps,          \
-                                domain_pirq_to_irq(d__, i));\
+    int irq__ = domain_pirq_to_irq(d__, i);             \
+    irq__ > 0 && irq_access_permitted(d__, irq__)       \
+    ? irq__ : 0;                                        \
 })
 
 #endif /* __XEN_IOCAP_H__ */




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 10:50:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 10: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 1XzNmz-0000Pb-Es; Fri, 12 Dec 2014 10:49:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XzNmy-0000PW-At
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 10:49:36 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	98/0C-17694-F38CA845; Fri, 12 Dec 2014 10:49:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418381373!10434426!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 17244 invoked from network); 12 Dec 2014 10:49:34 -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 Dec 2014 10:49:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="203814385"
Message-ID: <548AC83A.6020802@citrix.com>
Date: Fri, 12 Dec 2014 10:49: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: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <548AD05D020000780004F329@mail.emea.novell.com>
In-Reply-To: <548AD05D020000780004F329@mail.emea.novell.com>
X-DLP: MIA1
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 10:24, Jan Beulich wrote:
> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> wasn't really consistent in one respect: The granting of access to an
> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> domains. In fact it is wrong to assume that a translation is already/
> still in place at the time access is being granted/revoked.
>
> What is wanted is to translate the incoming pIRQ to an IRQ for
> the invoking domain (as the pIRQ is the only notion the invoking
> domain has of the IRQ), and grant the subject domain access to
> the resulting IRQ.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Should domain_pirq_to_irq() be using 0 as its default invalid value,
rather than -1?  irq 0 is a real irq and could plausibly be wanted to be
passed through to a guest.

~Andrew

> ---
> v2: Also fix initial range check to use current->domain, adjust code
>     structure, and extend description (all requested by Ian). Along
>     the lines of the first mentioned change, also pass the Xen IRQ
>     number to the XSM hook (confirmed okay by Daniel).
> Note that I would hope for this to make unnecessary Stefano's proposed
> tools side change
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00160.html.
>
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -982,18 +982,21 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  
>      case XEN_DOMCTL_irq_permission:
>      {
> -        unsigned int pirq = op->u.irq_permission.pirq;
> +        unsigned int pirq = op->u.irq_permission.pirq, irq;
>          int allow = op->u.irq_permission.allow_access;
>  
> -        if ( pirq >= d->nr_pirqs )
> +        if ( pirq >= current->domain->nr_pirqs )
> +        {
>              ret = -EINVAL;
> -        else if ( !pirq_access_permitted(current->domain, pirq) ||
> -                  xsm_irq_permission(XSM_HOOK, d, pirq, allow) )
> +            break;
> +        }
> +        irq = pirq_access_permitted(current->domain, pirq);
> +        if ( !irq || xsm_irq_permission(XSM_HOOK, d, irq, allow) )
>              ret = -EPERM;
>          else if ( allow )
> -            ret = pirq_permit_access(d, pirq);
> +            ret = irq_permit_access(d, irq);
>          else
> -            ret = pirq_deny_access(d, pirq);
> +            ret = irq_deny_access(d, irq);
>      }
>      break;
>  
> --- a/xen/include/xen/iocap.h
> +++ b/xen/include/xen/iocap.h
> @@ -28,22 +28,11 @@
>  #define irq_access_permitted(d, i)                      \
>      rangeset_contains_singleton((d)->irq_caps, i)
>  
> -#define pirq_permit_access(d, i) ({                     \
> -    struct domain *d__ = (d);                           \
> -    int i__ = domain_pirq_to_irq(d__, i);               \
> -    i__ > 0 ? rangeset_add_singleton(d__->irq_caps, i__)\
> -            : -EINVAL;                                  \
> -})
> -#define pirq_deny_access(d, i) ({                       \
> -    struct domain *d__ = (d);                           \
> -    int i__ = domain_pirq_to_irq(d__, i);               \
> -    i__ > 0 ? rangeset_remove_singleton(d__->irq_caps, i__)\
> -            : -EINVAL;                                  \
> -})
>  #define pirq_access_permitted(d, i) ({                  \
>      struct domain *d__ = (d);                           \
> -    rangeset_contains_singleton(d__->irq_caps,          \
> -                                domain_pirq_to_irq(d__, i));\
> +    int irq__ = domain_pirq_to_irq(d__, i);             \
> +    irq__ > 0 && irq_access_permitted(d__, irq__)       \
> +    ? irq__ : 0;                                        \
>  })
>  
>  #endif /* __XEN_IOCAP_H__ */
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 10:50:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 10: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 1XzNmz-0000Pb-Es; Fri, 12 Dec 2014 10:49:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1XzNmy-0000PW-At
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 10:49:36 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	98/0C-17694-F38CA845; Fri, 12 Dec 2014 10:49:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418381373!10434426!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 17244 invoked from network); 12 Dec 2014 10:49:34 -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 Dec 2014 10:49:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="203814385"
Message-ID: <548AC83A.6020802@citrix.com>
Date: Fri, 12 Dec 2014 10:49: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: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <548AD05D020000780004F329@mail.emea.novell.com>
In-Reply-To: <548AD05D020000780004F329@mail.emea.novell.com>
X-DLP: MIA1
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 10:24, Jan Beulich wrote:
> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> wasn't really consistent in one respect: The granting of access to an
> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> domains. In fact it is wrong to assume that a translation is already/
> still in place at the time access is being granted/revoked.
>
> What is wanted is to translate the incoming pIRQ to an IRQ for
> the invoking domain (as the pIRQ is the only notion the invoking
> domain has of the IRQ), and grant the subject domain access to
> the resulting IRQ.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Should domain_pirq_to_irq() be using 0 as its default invalid value,
rather than -1?  irq 0 is a real irq and could plausibly be wanted to be
passed through to a guest.

~Andrew

> ---
> v2: Also fix initial range check to use current->domain, adjust code
>     structure, and extend description (all requested by Ian). Along
>     the lines of the first mentioned change, also pass the Xen IRQ
>     number to the XSM hook (confirmed okay by Daniel).
> Note that I would hope for this to make unnecessary Stefano's proposed
> tools side change
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00160.html.
>
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -982,18 +982,21 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  
>      case XEN_DOMCTL_irq_permission:
>      {
> -        unsigned int pirq = op->u.irq_permission.pirq;
> +        unsigned int pirq = op->u.irq_permission.pirq, irq;
>          int allow = op->u.irq_permission.allow_access;
>  
> -        if ( pirq >= d->nr_pirqs )
> +        if ( pirq >= current->domain->nr_pirqs )
> +        {
>              ret = -EINVAL;
> -        else if ( !pirq_access_permitted(current->domain, pirq) ||
> -                  xsm_irq_permission(XSM_HOOK, d, pirq, allow) )
> +            break;
> +        }
> +        irq = pirq_access_permitted(current->domain, pirq);
> +        if ( !irq || xsm_irq_permission(XSM_HOOK, d, irq, allow) )
>              ret = -EPERM;
>          else if ( allow )
> -            ret = pirq_permit_access(d, pirq);
> +            ret = irq_permit_access(d, irq);
>          else
> -            ret = pirq_deny_access(d, pirq);
> +            ret = irq_deny_access(d, irq);
>      }
>      break;
>  
> --- a/xen/include/xen/iocap.h
> +++ b/xen/include/xen/iocap.h
> @@ -28,22 +28,11 @@
>  #define irq_access_permitted(d, i)                      \
>      rangeset_contains_singleton((d)->irq_caps, i)
>  
> -#define pirq_permit_access(d, i) ({                     \
> -    struct domain *d__ = (d);                           \
> -    int i__ = domain_pirq_to_irq(d__, i);               \
> -    i__ > 0 ? rangeset_add_singleton(d__->irq_caps, i__)\
> -            : -EINVAL;                                  \
> -})
> -#define pirq_deny_access(d, i) ({                       \
> -    struct domain *d__ = (d);                           \
> -    int i__ = domain_pirq_to_irq(d__, i);               \
> -    i__ > 0 ? rangeset_remove_singleton(d__->irq_caps, i__)\
> -            : -EINVAL;                                  \
> -})
>  #define pirq_access_permitted(d, i) ({                  \
>      struct domain *d__ = (d);                           \
> -    rangeset_contains_singleton(d__->irq_caps,          \
> -                                domain_pirq_to_irq(d__, i));\
> +    int irq__ = domain_pirq_to_irq(d__, i);             \
> +    irq__ > 0 && irq_access_permitted(d__, irq__)       \
> +    ? irq__ : 0;                                        \
>  })
>  
>  #endif /* __XEN_IOCAP_H__ */
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 10:54:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 10:54:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzNrM-0000ou-4Q; Fri, 12 Dec 2014 10:54: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 1XzNrK-0000oj-6i
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 10:54:06 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	CF/DD-23865-D49CA845; Fri, 12 Dec 2014 10:54:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418381644!12906427!1
X-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 5774 invoked from network); 12 Dec 2014 10:54:04 -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; 12 Dec 2014 10:54:04 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 12 Dec 2014 10:54:04 +0000
Message-Id: <548AD75B020000780004F342@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 12 Dec 2014 10:54:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.12.14 at 08:24, <kevin.tian@intel.com> wrote:
> - is there existing _map_ call for this purpose per your knowledge, or
> a new one is required? If the latter, what's the additional logic to be
> implemented there?

I think the answer to this depends on whether you want to use
grants. The goal of using the native driver in the guest (mentioned
further down) speaks against this, in which case I don't think we
have an existing interface.

> - when you say _map_, do you expect this mapped into dom0's virtual
> address space, or just guest physical space?

Iiuc you don't care about the memory to be visible to the CPU, all
you need is it being translated by the IOMMU. In which case the
input address space for the IOMMU (which is different between PV
and PVH) is where this needs to be mapped into.

> - how is BFN or unused address (what do you mean by address here?)
> allocated? does it need present in guest physical memory at boot time,
> or just finding some holes?

Fitting this into holes should be fine.

> - graphics memory size could be large. starting from BDW, there'll
> be 64bit page table format. Do you see any limitation here on finding
> BFN or address?

I don't think this concern differs much for the different models: As long
as you don't want the same underlying memory to be accessible by
more than one guest, the address space requirements ought to be the
same.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 10:54:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 10:54:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzNrM-0000ou-4Q; Fri, 12 Dec 2014 10:54: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 1XzNrK-0000oj-6i
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 10:54:06 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	CF/DD-23865-D49CA845; Fri, 12 Dec 2014 10:54:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418381644!12906427!1
X-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 5774 invoked from network); 12 Dec 2014 10:54:04 -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; 12 Dec 2014 10:54:04 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 12 Dec 2014 10:54:04 +0000
Message-Id: <548AD75B020000780004F342@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 12 Dec 2014 10:54:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.12.14 at 08:24, <kevin.tian@intel.com> wrote:
> - is there existing _map_ call for this purpose per your knowledge, or
> a new one is required? If the latter, what's the additional logic to be
> implemented there?

I think the answer to this depends on whether you want to use
grants. The goal of using the native driver in the guest (mentioned
further down) speaks against this, in which case I don't think we
have an existing interface.

> - when you say _map_, do you expect this mapped into dom0's virtual
> address space, or just guest physical space?

Iiuc you don't care about the memory to be visible to the CPU, all
you need is it being translated by the IOMMU. In which case the
input address space for the IOMMU (which is different between PV
and PVH) is where this needs to be mapped into.

> - how is BFN or unused address (what do you mean by address here?)
> allocated? does it need present in guest physical memory at boot time,
> or just finding some holes?

Fitting this into holes should be fine.

> - graphics memory size could be large. starting from BDW, there'll
> be 64bit page table format. Do you see any limitation here on finding
> BFN or address?

I don't think this concern differs much for the different models: As long
as you don't want the same underlying memory to be accessible by
more than one guest, the address space requirements ought to be the
same.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 11:04:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 11:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzO0p-0001Ig-BF; Fri, 12 Dec 2014 11:03:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XzO0o-0001Ib-6t
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 11:03:54 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	14/57-22737-99BCA845; Fri, 12 Dec 2014 11:03:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418382232!8877689!1
X-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 11221 invoked from network); 12 Dec 2014 11:03:52 -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; 12 Dec 2014 11:03:52 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 12 Dec 2014 11:03:52 +0000
Message-Id: <548AD9A6020000780004F354@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 12 Dec 2014 11:03:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <548AD05D020000780004F329@mail.emea.novell.com>
	<548AC83A.6020802@citrix.com>
In-Reply-To: <548AC83A.6020802@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	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>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v2] domctl: fix IRQ permission
 granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 11:49, <andrew.cooper3@citrix.com> wrote:
> On 12/12/14 10:24, Jan Beulich wrote:
>> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
>> wasn't really consistent in one respect: The granting of access to an
>> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
>> domains. In fact it is wrong to assume that a translation is already/
>> still in place at the time access is being granted/revoked.
>>
>> What is wanted is to translate the incoming pIRQ to an IRQ for
>> the invoking domain (as the pIRQ is the only notion the invoking
>> domain has of the IRQ), and grant the subject domain access to
>> the resulting IRQ.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Should domain_pirq_to_irq() be using 0 as its default invalid value,
> rather than -1?  irq 0 is a real irq and could plausibly be wanted to be
> passed through to a guest.

Not on x86. If another architecture would ever need this, I think
we'd need to audit all current users of domain_pirq_to_irq() before
doing such a change.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 11:04:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 11:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzO0p-0001Ig-BF; Fri, 12 Dec 2014 11:03:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XzO0o-0001Ib-6t
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 11:03:54 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	14/57-22737-99BCA845; Fri, 12 Dec 2014 11:03:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418382232!8877689!1
X-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 11221 invoked from network); 12 Dec 2014 11:03:52 -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; 12 Dec 2014 11:03:52 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 12 Dec 2014 11:03:52 +0000
Message-Id: <548AD9A6020000780004F354@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 12 Dec 2014 11:03:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <548AD05D020000780004F329@mail.emea.novell.com>
	<548AC83A.6020802@citrix.com>
In-Reply-To: <548AC83A.6020802@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	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>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v2] domctl: fix IRQ permission
 granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 11:49, <andrew.cooper3@citrix.com> wrote:
> On 12/12/14 10:24, Jan Beulich wrote:
>> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
>> wasn't really consistent in one respect: The granting of access to an
>> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
>> domains. In fact it is wrong to assume that a translation is already/
>> still in place at the time access is being granted/revoked.
>>
>> What is wanted is to translate the incoming pIRQ to an IRQ for
>> the invoking domain (as the pIRQ is the only notion the invoking
>> domain has of the IRQ), and grant the subject domain access to
>> the resulting IRQ.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Should domain_pirq_to_irq() be using 0 as its default invalid value,
> rather than -1?  irq 0 is a real irq and could plausibly be wanted to be
> passed through to a guest.

Not on x86. If another architecture would ever need this, I think
we'd need to audit all current users of domain_pirq_to_irq() before
doing such a change.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 11:14:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 11:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzOB8-0001l2-KQ; Fri, 12 Dec 2014 11:14: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 1XzOB6-0001kx-TJ
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 11:14:33 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	1D/0F-25727-81ECA845; Fri, 12 Dec 2014 11:14:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418382870!12893334!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 23833 invoked from network); 12 Dec 2014 11:14:31 -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;
	12 Dec 2014 11:14:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="203822182"
Message-ID: <1418382867.23309.54.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: manish jaggi <manishjaggi.oss@gmail.com>
Date: Fri, 12 Dec 2014 11:14:27 +0000
In-Reply-To: <CAAiw7J=VLb5tJn18uYZh-SHO9Kb6PsUTiM694BdzRfjKxpv_-Q@mail.gmail.com>
References: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
	<alpine.DEB.2.02.1412111027550.30971@kaball.uk.xensource.com>
	<CAAiw7J=VLb5tJn18uYZh-SHO9Kb6PsUTiM694BdzRfjKxpv_-Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Few Comments on the Xen SMMU ARM code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-12-11 at 10:02 -0800, manish jaggi wrote:
> This is the complete smmu.c file which you can refer for PCI
> passthrough (http://pastebin.com/QDX8fpDu)

I'm afraid that as Julien says this is basically no help.

> Just FYI this is not a patch, we are still testing on our board and
> can post a patch only after our testing is complete.

Please post whatever patch(es) you have now with a WIP (Work In
Progress) tag in the subject. It does not need to be complete, working,
tested or clean. You can put a big fat warning on the commit log if you
like. See for example
http://article.gmane.org/gmane.comp.emulators.xen.devel/220265 where I
did exactly this with some very dirty patches I was halfway through
writing[0] (I used "incomplete" rather than "WIP", the exact words don't
really matter).

If you have any design documentation then please include that as well,
e.g. in the 0/N mail.

IMHO seeing what you have actually done which is leading to the
questions you are asking is a prerequisite to having any sort of
constructive discussion about the design decisions going forward. I'd
certainly want to see the code before any call takes place.

Cheers,
Ian.

[0] in this case because I wasn't going to be able to finish them soon
and it was better to get them onto the list than rotting in my dev tree.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 11:14:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 11:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzOB8-0001l2-KQ; Fri, 12 Dec 2014 11:14: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 1XzOB6-0001kx-TJ
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 11:14:33 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	1D/0F-25727-81ECA845; Fri, 12 Dec 2014 11:14:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418382870!12893334!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 23833 invoked from network); 12 Dec 2014 11:14:31 -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;
	12 Dec 2014 11:14:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="203822182"
Message-ID: <1418382867.23309.54.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: manish jaggi <manishjaggi.oss@gmail.com>
Date: Fri, 12 Dec 2014 11:14:27 +0000
In-Reply-To: <CAAiw7J=VLb5tJn18uYZh-SHO9Kb6PsUTiM694BdzRfjKxpv_-Q@mail.gmail.com>
References: <CAAiw7Jm16Beo69pcnqi3-8QhoKokxc0fVGbE8W+KHGCEWofV0g@mail.gmail.com>
	<alpine.DEB.2.02.1412111027550.30971@kaball.uk.xensource.com>
	<CAAiw7J=VLb5tJn18uYZh-SHO9Kb6PsUTiM694BdzRfjKxpv_-Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Few Comments on the Xen SMMU ARM code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-12-11 at 10:02 -0800, manish jaggi wrote:
> This is the complete smmu.c file which you can refer for PCI
> passthrough (http://pastebin.com/QDX8fpDu)

I'm afraid that as Julien says this is basically no help.

> Just FYI this is not a patch, we are still testing on our board and
> can post a patch only after our testing is complete.

Please post whatever patch(es) you have now with a WIP (Work In
Progress) tag in the subject. It does not need to be complete, working,
tested or clean. You can put a big fat warning on the commit log if you
like. See for example
http://article.gmane.org/gmane.comp.emulators.xen.devel/220265 where I
did exactly this with some very dirty patches I was halfway through
writing[0] (I used "incomplete" rather than "WIP", the exact words don't
really matter).

If you have any design documentation then please include that as well,
e.g. in the 0/N mail.

IMHO seeing what you have actually done which is leading to the
questions you are asking is a prerequisite to having any sort of
constructive discussion about the design decisions going forward. I'd
certainly want to see the code before any call takes place.

Cheers,
Ian.

[0] in this case because I wasn't going to be able to finish them soon
and it was better to get them onto the list than rotting in my dev tree.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 11:25:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 11: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 1XzOLi-0002C6-VF; Fri, 12 Dec 2014 11:25: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 1XzOLh-0002C1-Fa
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 11:25:29 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	AA/FC-31453-8A0DA845; Fri, 12 Dec 2014 11:25:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418383526!10126115!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 24862 invoked from network); 12 Dec 2014 11:25:27 -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 Dec 2014 11:25:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="203825596"
Message-ID: <1418383524.23309.57.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 12 Dec 2014 11:25:24 +0000
In-Reply-To: <548AD9A6020000780004F354@mail.emea.novell.com>
References: <548AD05D020000780004F329@mail.emea.novell.com>
	<548AC83A.6020802@citrix.com>
	<548AD9A6020000780004F354@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] domctl: fix IRQ permission
 granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-12 at 11:03 +0000, Jan Beulich wrote:
> >>> On 12.12.14 at 11:49, <andrew.cooper3@citrix.com> wrote:
> > On 12/12/14 10:24, Jan Beulich wrote:
> >> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> >> wasn't really consistent in one respect: The granting of access to an
> >> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> >> domains. In fact it is wrong to assume that a translation is already/
> >> still in place at the time access is being granted/revoked.
> >>
> >> What is wanted is to translate the incoming pIRQ to an IRQ for
> >> the invoking domain (as the pIRQ is the only notion the invoking
> >> domain has of the IRQ), and grant the subject domain access to
> >> the resulting IRQ.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > Should domain_pirq_to_irq() be using 0 as its default invalid value,
> > rather than -1?  irq 0 is a real irq and could plausibly be wanted to be
> > passed through to a guest.
> 
> Not on x86. If another architecture would ever need this, I think
> we'd need to audit all current users of domain_pirq_to_irq() before
> doing such a change.

FWIW on ARM (at least the versions we support, i.e. with the generic IRQ
controller) IRQ0 is an SGI (what x86 would call an IPI). It seems
unlikely we'd want to pass one of those through...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 11:25:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 11: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 1XzOLi-0002C6-VF; Fri, 12 Dec 2014 11:25: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 1XzOLh-0002C1-Fa
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 11:25:29 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	AA/FC-31453-8A0DA845; Fri, 12 Dec 2014 11:25:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418383526!10126115!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 24862 invoked from network); 12 Dec 2014 11:25:27 -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 Dec 2014 11:25:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="203825596"
Message-ID: <1418383524.23309.57.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 12 Dec 2014 11:25:24 +0000
In-Reply-To: <548AD9A6020000780004F354@mail.emea.novell.com>
References: <548AD05D020000780004F329@mail.emea.novell.com>
	<548AC83A.6020802@citrix.com>
	<548AD9A6020000780004F354@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] domctl: fix IRQ permission
 granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-12 at 11:03 +0000, Jan Beulich wrote:
> >>> On 12.12.14 at 11:49, <andrew.cooper3@citrix.com> wrote:
> > On 12/12/14 10:24, Jan Beulich wrote:
> >> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> >> wasn't really consistent in one respect: The granting of access to an
> >> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> >> domains. In fact it is wrong to assume that a translation is already/
> >> still in place at the time access is being granted/revoked.
> >>
> >> What is wanted is to translate the incoming pIRQ to an IRQ for
> >> the invoking domain (as the pIRQ is the only notion the invoking
> >> domain has of the IRQ), and grant the subject domain access to
> >> the resulting IRQ.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > Should domain_pirq_to_irq() be using 0 as its default invalid value,
> > rather than -1?  irq 0 is a real irq and could plausibly be wanted to be
> > passed through to a guest.
> 
> Not on x86. If another architecture would ever need this, I think
> we'd need to audit all current users of domain_pirq_to_irq() before
> doing such a change.

FWIW on ARM (at least the versions we support, i.e. with the generic IRQ
controller) IRQ0 is an SGI (what x86 would call an IPI). It seems
unlikely we'd want to pass one of those through...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 11:38:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 11:38:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzOXj-0002dF-7I; Fri, 12 Dec 2014 11:37:55 +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 1XzOXi-0002dA-DZ
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 11:37:54 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	8A/F3-02953-193DA845; Fri, 12 Dec 2014 11:37:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418384272!14685677!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30907 invoked from network); 12 Dec 2014 11:37:53 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 11:37:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418384272; l=608;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=E38FzkC2RL9koeFc02PLEqLY0bo=;
	b=XbtLGtiuFmRQ+FmEn0KDr7F5qy2nLxr3X4WcE2tNCyWQUxQCbXfIdgtT56jT7EqIE6u
	bagFxaBN0PSp1eTVKKlpIDrqfpTpSwKE/SigNfnV6R8Fj0LzDySkghSZbeTXovLPVGUH6
	1W+HHk8g7K+0pIPIul9umCzc5ChkdyiMeKo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id j00ac6qBCBbqEIX
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 12 Dec 2014 12:37:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 14F3250160; Fri, 12 Dec 2014 12:37:51 +0100 (CET)
Date: Fri, 12 Dec 2014 12:37:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141212113751.GA5367@aepfle.de>
References: <1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210175251.GA4441@aepfle.de>
	<1418379056.23309.45.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418379056.23309.45.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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>
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, Ian Campbell wrote:

> Seems ok. I wonder if the wrapper ought to source
> @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
> rather than relying on the initscript and unit file to do so. Especially
> in the initscript case it looks a bit ugly to have to manually propagate
> things.

It seems all that wrapping is of no use because SELinux can not deal
with it. I will see if "ExecStart=/bin/ary --no-fork $ENVVAR" can be
used to pass additional arguments. If so, the current XENSTORED_TRACE
handling has to be removed in favour of XENSTORED_ARGS=.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 11:38:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 11:38:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzOXj-0002dF-7I; Fri, 12 Dec 2014 11:37:55 +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 1XzOXi-0002dA-DZ
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 11:37:54 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	8A/F3-02953-193DA845; Fri, 12 Dec 2014 11:37:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418384272!14685677!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30907 invoked from network); 12 Dec 2014 11:37:53 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 11:37:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418384272; l=608;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=E38FzkC2RL9koeFc02PLEqLY0bo=;
	b=XbtLGtiuFmRQ+FmEn0KDr7F5qy2nLxr3X4WcE2tNCyWQUxQCbXfIdgtT56jT7EqIE6u
	bagFxaBN0PSp1eTVKKlpIDrqfpTpSwKE/SigNfnV6R8Fj0LzDySkghSZbeTXovLPVGUH6
	1W+HHk8g7K+0pIPIul9umCzc5ChkdyiMeKo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id j00ac6qBCBbqEIX
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 12 Dec 2014 12:37:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 14F3250160; Fri, 12 Dec 2014 12:37:51 +0100 (CET)
Date: Fri, 12 Dec 2014 12:37:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141212113751.GA5367@aepfle.de>
References: <1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210175251.GA4441@aepfle.de>
	<1418379056.23309.45.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418379056.23309.45.camel@citrix.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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>
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, Ian Campbell wrote:

> Seems ok. I wonder if the wrapper ought to source
> @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
> rather than relying on the initscript and unit file to do so. Especially
> in the initscript case it looks a bit ugly to have to manually propagate
> things.

It seems all that wrapping is of no use because SELinux can not deal
with it. I will see if "ExecStart=/bin/ary --no-fork $ENVVAR" can be
used to pass additional arguments. If so, the current XENSTORED_TRACE
handling has to be removed in favour of XENSTORED_ARGS=.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 11:43:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 11: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 1XzOdG-00033t-1Q; Fri, 12 Dec 2014 11:43: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 1XzOdF-00033o-44
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 11:43:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	13/47-25276-8E4DA845; Fri, 12 Dec 2014 11:43:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418384614!7144249!1
X-Originating-IP: [66.165.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 9708 invoked from network); 12 Dec 2014 11:43: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;
	12 Dec 2014 11:43:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="203830244"
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.210.2; Fri, 12 Dec 2014 06:43: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 1XzOd6-0004r1-5e;
	Fri, 12 Dec 2014 11:43:28 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzOd5-0002RD-UT;
	Fri, 12 Dec 2014 11:43:27 +0000
Date: Fri, 12 Dec 2014 11:43:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32277-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] 32277: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32277 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32277/

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-freebsd10-amd64 16 guest-start.2            fail pass in 32218
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install      fail pass in 32218

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 32218 like 28935-bisect

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-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-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-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-vcpus1 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-win7-amd64 14 guest-stop     fail in 32218 never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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 34178 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 Dec 12 11:43:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 11: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 1XzOdG-00033t-1Q; Fri, 12 Dec 2014 11:43: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 1XzOdF-00033o-44
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 11:43:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	13/47-25276-8E4DA845; Fri, 12 Dec 2014 11:43:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418384614!7144249!1
X-Originating-IP: [66.165.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 9708 invoked from network); 12 Dec 2014 11:43: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;
	12 Dec 2014 11:43:35 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="203830244"
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.210.2; Fri, 12 Dec 2014 06:43: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 1XzOd6-0004r1-5e;
	Fri, 12 Dec 2014 11:43:28 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzOd5-0002RD-UT;
	Fri, 12 Dec 2014 11:43:27 +0000
Date: Fri, 12 Dec 2014 11:43:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32277-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] 32277: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32277 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32277/

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-freebsd10-amd64 16 guest-start.2            fail pass in 32218
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install      fail pass in 32218

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 32218 like 28935-bisect

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-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-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-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-vcpus1 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-win7-amd64 14 guest-stop     fail in 32218 never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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 34178 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 Dec 12 11:47:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 11:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzOgc-0003Ba-Kf; Fri, 12 Dec 2014 11:47: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 1XzOgb-0003BT-IY
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 11:47:05 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	C2/0D-17694-8B5DA845; Fri, 12 Dec 2014 11:47:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418384822!12846032!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 29708 invoked from network); 12 Dec 2014 11:47:04 -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;
	12 Dec 2014 11:47:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="203831292"
Message-ID: <1418384820.23309.58.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 12 Dec 2014 11:47:00 +0000
In-Reply-To: <20141212113751.GA5367@aepfle.de>
References: <1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210175251.GA4441@aepfle.de>
	<1418379056.23309.45.camel@citrix.com>
	<20141212113751.GA5367@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
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>
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-12 at 12:37 +0100, Olaf Hering wrote:
> On Fri, Dec 12, Ian Campbell wrote:
> 
> > Seems ok. I wonder if the wrapper ought to source
> > @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
> > rather than relying on the initscript and unit file to do so. Especially
> > in the initscript case it looks a bit ugly to have to manually propagate
> > things.
> 
> It seems all that wrapping is of no use because SELinux can not deal
> with it.

I suppose you mean "the current SELinux policies". Surely SELinux in
general can cope with execing things...

>  I will see if "ExecStart=/bin/ary --no-fork $ENVVAR" can be
> used to pass additional arguments. If so, the current XENSTORED_TRACE
> handling has to be removed in favour of XENSTORED_ARGS=.
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 11:47:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 11:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzOgc-0003Ba-Kf; Fri, 12 Dec 2014 11:47: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 1XzOgb-0003BT-IY
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 11:47:05 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	C2/0D-17694-8B5DA845; Fri, 12 Dec 2014 11:47:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418384822!12846032!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 29708 invoked from network); 12 Dec 2014 11:47:04 -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;
	12 Dec 2014 11:47:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="203831292"
Message-ID: <1418384820.23309.58.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 12 Dec 2014 11:47:00 +0000
In-Reply-To: <20141212113751.GA5367@aepfle.de>
References: <1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210175251.GA4441@aepfle.de>
	<1418379056.23309.45.camel@citrix.com>
	<20141212113751.GA5367@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
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>
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-12 at 12:37 +0100, Olaf Hering wrote:
> On Fri, Dec 12, Ian Campbell wrote:
> 
> > Seems ok. I wonder if the wrapper ought to source
> > @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
> > rather than relying on the initscript and unit file to do so. Especially
> > in the initscript case it looks a bit ugly to have to manually propagate
> > things.
> 
> It seems all that wrapping is of no use because SELinux can not deal
> with it.

I suppose you mean "the current SELinux policies". Surely SELinux in
general can cope with execing things...

>  I will see if "ExecStart=/bin/ary --no-fork $ENVVAR" can be
> used to pass additional arguments. If so, the current XENSTORED_TRACE
> handling has to be removed in favour of XENSTORED_ARGS=.
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 12:00:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 12:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzOss-00044O-CW; Fri, 12 Dec 2014 11:59:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XzOsq-00044E-W3
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 11:59:45 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	59/EB-25547-0B8DA845; Fri, 12 Dec 2014 11:59:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418385581!12866832!1
X-Originating-IP: [66.165.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 27877 invoked from network); 12 Dec 2014 11:59: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;
	12 Dec 2014 11:59:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="203428219"
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.210.2; Fri, 12 Dec 2014 06:59: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 1XzOsD-0004ve-Gm;
	Fri, 12 Dec 2014 11:59:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzOsB-0006iy-Ax;
	Fri, 12 Dec 2014 11:59:03 +0000
Date: Fri, 12 Dec 2014 11:59:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32245-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] 32245: 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 32245 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32245/

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 32198

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-xl-pcipt-intel  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-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-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-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-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                  60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
baseline version:
 xen                  2a549b9c8aa48dc39d7c97e5a93978b781b3a1db

------------------------------------------------------------
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>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

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=60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
+ . 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 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
+ branch=xen-unstable
+ revision=60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
+ . 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 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   2a549b9..60ce518  60ce518a1b1caf2c1e4c1b203e87fb0b179ba687 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 12:00:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 12:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzOss-00044O-CW; Fri, 12 Dec 2014 11:59:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XzOsq-00044E-W3
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 11:59:45 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	59/EB-25547-0B8DA845; Fri, 12 Dec 2014 11:59:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418385581!12866832!1
X-Originating-IP: [66.165.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 27877 invoked from network); 12 Dec 2014 11:59: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;
	12 Dec 2014 11:59:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="203428219"
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.210.2; Fri, 12 Dec 2014 06:59: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 1XzOsD-0004ve-Gm;
	Fri, 12 Dec 2014 11:59:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzOsB-0006iy-Ax;
	Fri, 12 Dec 2014 11:59:03 +0000
Date: Fri, 12 Dec 2014 11:59:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32245-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] 32245: 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 32245 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32245/

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 32198

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-xl-pcipt-intel  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-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-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-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-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                  60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
baseline version:
 xen                  2a549b9c8aa48dc39d7c97e5a93978b781b3a1db

------------------------------------------------------------
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>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

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=60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
+ . 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 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
+ branch=xen-unstable
+ revision=60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
+ . 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 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   2a549b9..60ce518  60ce518a1b1caf2c1e4c1b203e87fb0b179ba687 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 12:09:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 12: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 1XzP1y-0004il-T0; Fri, 12 Dec 2014 12:09:10 +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 1XzP1w-0004ig-Np
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 12:09:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	14/C9-25276-4EADA845; Fri, 12 Dec 2014 12:09:08 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418386147!15151799!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 21921 invoked from network); 12 Dec 2014 12:09:07 -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; 12 Dec 2014 12:09:07 -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 sBCC8BWA032458;
	Fri, 12 Dec 2014 12:08:15 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 sBCC85m8009515
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Dec 2014 12:08:05 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 sBCC85w0014990;
	Fri, 12 Dec 2014 12:08:05 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sBCC84R4014986; Fri, 12 Dec 2014 12:08:04 GMT
Date: Fri, 12 Dec 2014 12:08:04 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1418384820.23309.58.camel@citrix.com>
Message-ID: <alpine.DEB.2.00.1412121204070.13925@procyon.dur.ac.uk>
References: <1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210175251.GA4441@aepfle.de>
	<1418379056.23309.45.camel@citrix.com>
	<20141212113751.GA5367@aepfle.de>
	<1418384820.23309.58.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: sBCC8BWA032458
Cc: Wei Liu <wei.liu2@citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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, 12 Dec 2014, Ian Campbell wrote:

> On Fri, 2014-12-12 at 12:37 +0100, Olaf Hering wrote:
>> On Fri, Dec 12, Ian Campbell wrote:
>>
>>> Seems ok. I wonder if the wrapper ought to source
>>> @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
>>> rather than relying on the initscript and unit file to do so. Especially
>>> in the initscript case it looks a bit ugly to have to manually propagate
>>> things.
>>
>> It seems all that wrapping is of no use because SELinux can not deal
>> with it.
>
> I suppose you mean "the current SELinux policies". Surely SELinux in
> general can cope with execing things...

I suspect it is more how systemd implements selinux. xenstored does get 
the right permissions eventually, but too late to connect to the sockets.

 	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 Dec 12 12:09:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 12: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 1XzP1y-0004il-T0; Fri, 12 Dec 2014 12:09:10 +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 1XzP1w-0004ig-Np
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 12:09:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	14/C9-25276-4EADA845; Fri, 12 Dec 2014 12:09:08 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418386147!15151799!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 21921 invoked from network); 12 Dec 2014 12:09:07 -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; 12 Dec 2014 12:09:07 -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 sBCC8BWA032458;
	Fri, 12 Dec 2014 12:08:15 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 sBCC85m8009515
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Dec 2014 12:08:05 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 sBCC85w0014990;
	Fri, 12 Dec 2014 12:08:05 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sBCC84R4014986; Fri, 12 Dec 2014 12:08:04 GMT
Date: Fri, 12 Dec 2014 12:08:04 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1418384820.23309.58.camel@citrix.com>
Message-ID: <alpine.DEB.2.00.1412121204070.13925@procyon.dur.ac.uk>
References: <1417781152-9926-6-git-send-email-olaf@aepfle.de>
	<21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210175251.GA4441@aepfle.de>
	<1418379056.23309.45.camel@citrix.com>
	<20141212113751.GA5367@aepfle.de>
	<1418384820.23309.58.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: sBCC8BWA032458
Cc: Wei Liu <wei.liu2@citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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, 12 Dec 2014, Ian Campbell wrote:

> On Fri, 2014-12-12 at 12:37 +0100, Olaf Hering wrote:
>> On Fri, Dec 12, Ian Campbell wrote:
>>
>>> Seems ok. I wonder if the wrapper ought to source
>>> @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
>>> rather than relying on the initscript and unit file to do so. Especially
>>> in the initscript case it looks a bit ugly to have to manually propagate
>>> things.
>>
>> It seems all that wrapping is of no use because SELinux can not deal
>> with it.
>
> I suppose you mean "the current SELinux policies". Surely SELinux in
> general can cope with execing things...

I suspect it is more how systemd implements selinux. xenstored does get 
the right permissions eventually, but too late to connect to the sockets.

 	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 Dec 12 12:12:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 12:12:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzP5Q-00054P-H0; Fri, 12 Dec 2014 12:12: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 1XzP5P-00053Y-3u
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 12:12:43 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	9B/61-02698-ABBDA845; Fri, 12 Dec 2014 12:12:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418386361!14595629!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11695 invoked from network); 12 Dec 2014 12:12:41 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 12:12:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418386361; l=1172;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=tZ4a3tv/tkr5bZemhB0kDG3aZZY=;
	b=I9ttiG/d8KeAg47UECKL9cupCbPLqvQVi9bnlaD7UVeLkb4bSN6X0+pkbxSbjqJwdDP
	nWsXqmwf6z+z7XQY19wdQqzRsaakeD/+GWkN5ZcJhQfPMHF31m2rU8LFdgMC+DKuSzcEt
	d6aILISTeMoMF4TiWXZ8CyO16LhFgKGfZBQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id e02e0eqBCCCbERZ
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 12 Dec 2014 13:12:37 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 2959A50160; Fri, 12 Dec 2014 13:12:36 +0100 (CET)
Date: Fri, 12 Dec 2014 13:12:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>, konrad.wilk@oracle.com
Message-ID: <20141212121236.GA8380@aepfle.de>
References: <21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210175251.GA4441@aepfle.de>
	<1418379056.23309.45.camel@citrix.com>
	<20141212113751.GA5367@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141212113751.GA5367@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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>
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, Olaf Hering wrote:

> On Fri, Dec 12, Ian Campbell wrote:
> 
> > Seems ok. I wonder if the wrapper ought to source
> > @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
> > rather than relying on the initscript and unit file to do so. Especially
> > in the initscript case it looks a bit ugly to have to manually propagate
> > things.
> 
> It seems all that wrapping is of no use because SELinux can not deal
> with it. I will see if "ExecStart=/bin/ary --no-fork $ENVVAR" can be
> used to pass additional arguments. If so, the current XENSTORED_TRACE
> handling has to be removed in favour of XENSTORED_ARGS=.

This works:
ExecStart=@XENSTORED@ --no-fork $XENSTORED_ARGS

This fails:
ExecStart=$XENSTORED --no-fork $XENSTORED_ARGS
Dez 12 13:06:21 optiplex systemd[1]: [/usr/lib/systemd/system/xenstored.service:16] Executable path is not absolute, ignoring: $XENSTORED --no-fork $XENSTORED_ARGS

Looks like variables are not expanded for the executable itself. If that
really has to be supported a wrapper is required.

Maybe that new wrapper script just needs some special SELinux handling?
No idea.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 12:12:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 12:12:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzP5Q-00054P-H0; Fri, 12 Dec 2014 12:12: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 1XzP5P-00053Y-3u
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 12:12:43 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	9B/61-02698-ABBDA845; Fri, 12 Dec 2014 12:12:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418386361!14595629!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11695 invoked from network); 12 Dec 2014 12:12:41 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 12:12:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418386361; l=1172;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=tZ4a3tv/tkr5bZemhB0kDG3aZZY=;
	b=I9ttiG/d8KeAg47UECKL9cupCbPLqvQVi9bnlaD7UVeLkb4bSN6X0+pkbxSbjqJwdDP
	nWsXqmwf6z+z7XQY19wdQqzRsaakeD/+GWkN5ZcJhQfPMHF31m2rU8LFdgMC+DKuSzcEt
	d6aILISTeMoMF4TiWXZ8CyO16LhFgKGfZBQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id e02e0eqBCCCbERZ
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 12 Dec 2014 13:12:37 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 2959A50160; Fri, 12 Dec 2014 13:12:36 +0100 (CET)
Date: Fri, 12 Dec 2014 13:12:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>, konrad.wilk@oracle.com
Message-ID: <20141212121236.GA8380@aepfle.de>
References: <21633.41977.399042.691409@mariner.uk.xensource.com>
	<20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210175251.GA4441@aepfle.de>
	<1418379056.23309.45.camel@citrix.com>
	<20141212113751.GA5367@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141212113751.GA5367@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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>
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, Olaf Hering wrote:

> On Fri, Dec 12, Ian Campbell wrote:
> 
> > Seems ok. I wonder if the wrapper ought to source
> > @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
> > rather than relying on the initscript and unit file to do so. Especially
> > in the initscript case it looks a bit ugly to have to manually propagate
> > things.
> 
> It seems all that wrapping is of no use because SELinux can not deal
> with it. I will see if "ExecStart=/bin/ary --no-fork $ENVVAR" can be
> used to pass additional arguments. If so, the current XENSTORED_TRACE
> handling has to be removed in favour of XENSTORED_ARGS=.

This works:
ExecStart=@XENSTORED@ --no-fork $XENSTORED_ARGS

This fails:
ExecStart=$XENSTORED --no-fork $XENSTORED_ARGS
Dez 12 13:06:21 optiplex systemd[1]: [/usr/lib/systemd/system/xenstored.service:16] Executable path is not absolute, ignoring: $XENSTORED --no-fork $XENSTORED_ARGS

Looks like variables are not expanded for the executable itself. If that
really has to be supported a wrapper is required.

Maybe that new wrapper script just needs some special SELinux handling?
No idea.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 12:28:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 12:28:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzPKI-0005fF-JI; Fri, 12 Dec 2014 12:28:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1XzPKG-0005f3-Gl
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 12:28:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4E/EB-25276-35FDA845; Fri, 12 Dec 2014 12:28:03 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418387282!7157482!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 17702 invoked from network); 12 Dec 2014 12:28:02 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-21.messagelabs.com with SMTP;
	12 Dec 2014 12:28:02 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 12 Dec 2014 04:28:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,563,1413270000"; d="scan'208";a="636643595"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by fmsmga001.fm.intel.com with ESMTP; 12 Dec 2014 04:27:58 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 12 Dec 2014 20:27:57 +0800
Message-Id: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	Ian.Jackson@eu.citrix.com, will.auld@intel.com,
	JBeulich@suse.com, wei.liu2@citrix.com, dgdegra@tycho.nsa.gov
Subject: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all, we plan to bring Intel CAT into XEN. This is the initial
design for that. Comments/suggestions are welcome.

Background
==========
Traditionally, all Virtual Machines ("VMs") share the same set of system
cache resources. There is no hardware support to control allocation or
availability of cache resources to individual VMs. The lack of such
partition mechanism for cache resource makes the cache utilization for
different types of VMs inefficient. While on the other side, more and
more cache resources become available on modern server platforms.

With the introduction of Intel Cache Allocation Technology ("CAT"), now
Virtualization Machine Monitor ("VMM") has the ability to partition the
cache allocation per VM, based on the priority of VM.


CAT Introduction
================
Generally speaking, CAT introduces a mechanism for software to enable
cache allocation based on application priority or Class of Service
("COS"). Cache allocation for the respective applications is then
restricted based on the COS with which they are associated. Each COS can
be configured using capacity bitmasks ("CBM") which represent cache
capacity and indicate the degree of overlap and isolation between
classes. For each logical processor there is a register
exposed(IA32_PQR_ASSOC MSR) to allow the OS/VMM to specify a COS when an
application, thread or VM is scheduled. Cache allocation for the
indicated application/thread/VM is then controlled automatically by the
hardware based on the COS and the CBM associated with that class.
Hardware initializes COS of each logical processor to 0 and the
corresponding CBM is set to all-ones, means all the system cache
resource can be used for each application.

For more information please refer to Section 17.15 in the Intel SDM [1].


Design Overview
===============
- Domain COS/CBM association
When enforcing cache allocation for VMs, the minimum granularity is
defined as the domain. All Virtual CPUs ("VCPUs") of a domain have the
same COS, and therefore, correspond to the same CBM. COS is used only in
hypervisor and is transparent to tool stack/user. System administrator
can specify the initial CBM for each domain or change it at runtime using 
tool stack. Hypervisor then choses a free COS to associate it with that
CBM or find a existed COS which has the same CBM.

- VCPU Schedule
When VCPU is scheduled on the physical CPU ("PCPU"), its COS value is
then written to MSR (IA32_PQR_ASSOC) of PCPU to notify hardware to use 
the new COS. The cache allocation is then enforced by hardware.

- Multi-Socket
In multi-socket environment, each VCPU may be scheduled on different
sockets. The hardware CAT ability(such as maximum supported COS and length
of CBM) maybe different among sockets. For such system, per-socket COS/CBM
configuration of a domain is specified. Hypervisor then use this per-socket
CBM information for VCPU schedule.


Implementation Description
==========================
In this design, one principal is that only implementing the cache
enforcement mechanism in hypervisor but leaving the cache allocation
policy to user space tool stack. In this way some complex governors then
can be implemented in tool stack. 

In summary, hypervisor changes include:
1) A new field "cat_info" in domain structure to indicate the CAT
   information for each socket. It points to array of structure:
   struct domain_socket_cat_info {
       unsigned int cbm; /* CBM specified by toolstack  */
       unsigned int cos; /* COS allocated by Hypervisor */
   }
2) A new SYSCTL to expose the CAT information to tool stack:
     * Whether CAT is enabled;
     * Max COS supported;
     * Length of CBM;
     * Other needed information from host cpuid;
3) A new DOMCTL to allow tool stack to set/get CBM for a specified domain
   for each socket.
4) Context switch: write COS of domain to MSR (IA32_PQR_ASSOC) of PCPU.
5) XSM policy to restrict the functions visibility to control domain only.

Hypervisor interfaces:
1) Boot line param: "psr=cat" to enable the feature.
2) SYSCTL: XEN_SYSCTL_psr_cat_op
     - XEN_SYSCTL_PSR_CAT_INFO_GET: Get system CAT information;
3) DOMCTL: XEN_DOMCTL_psr_cat_op
     - XEN_DOMCTL_PSR_CAT_OP_CBM_SET: Set CBM value for a domain.
     - XEN_DOMCTL_PSR_CAT_OP_CBM_GET: Get CBM value for a domain.

xl interfaces:
1) psr-cat-show: Show system/runtime CAT information.
     => XEN_SYSCTL_PSR_CAT_INFO_GET/XEN_DOMCTL_PSR_CAT_OP_CBM_GET
2) psr-cat-cbm-set [dom] [cbm] [socket]: Set CBM for a domain.
     => XEN_DOMCTL_PSR_CAT_OP_CBM_SET


Hardware Limitation & Performance Improvement
=============================================
As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
switch. If the change is frequent then hardware may fail to strictly
enforce the cache allocation basing on the specified COS. Due to this
the strict placement characteristic would soften if VCPU is migrated on
different PCPU frequently.

For this reason, lazy updating for IA32_PQR_ASSOC will be done. Also this
design allows CAT to run in two modes:

1) Non Affinitized mode: Each VM can be freely scheduled on any PCPU
assigning its COS as it does.

2) Affinitized mode: Each PCPU is assigned a fixed COS and a VM can be
scheduled on the PCPU only when it has a same COS. It's less flexible
but can be an option for those who must have strict COS placement or in
cases where problems have arisen because of the less strict nature of the
non-affinitized mode.

However, no additional code is designed to support these two modes. CAT is
already running in non affinitized mode by default. If affinitized mode
is desirable, then existed "xl vcpu-pin" command can be used to pin all
the VCPUs which has the same COS to certain fixed PCPUs so that these 
PCPUs always have the same COS set.

[1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf

Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 12:28:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 12:28:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzPKI-0005fF-JI; Fri, 12 Dec 2014 12:28:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1XzPKG-0005f3-Gl
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 12:28:04 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4E/EB-25276-35FDA845; Fri, 12 Dec 2014 12:28:03 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418387282!7157482!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 17702 invoked from network); 12 Dec 2014 12:28:02 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-21.messagelabs.com with SMTP;
	12 Dec 2014 12:28:02 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 12 Dec 2014 04:28:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,563,1413270000"; d="scan'208";a="636643595"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by fmsmga001.fm.intel.com with ESMTP; 12 Dec 2014 04:27:58 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Fri, 12 Dec 2014 20:27:57 +0800
Message-Id: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	Ian.Jackson@eu.citrix.com, will.auld@intel.com,
	JBeulich@suse.com, wei.liu2@citrix.com, dgdegra@tycho.nsa.gov
Subject: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all, we plan to bring Intel CAT into XEN. This is the initial
design for that. Comments/suggestions are welcome.

Background
==========
Traditionally, all Virtual Machines ("VMs") share the same set of system
cache resources. There is no hardware support to control allocation or
availability of cache resources to individual VMs. The lack of such
partition mechanism for cache resource makes the cache utilization for
different types of VMs inefficient. While on the other side, more and
more cache resources become available on modern server platforms.

With the introduction of Intel Cache Allocation Technology ("CAT"), now
Virtualization Machine Monitor ("VMM") has the ability to partition the
cache allocation per VM, based on the priority of VM.


CAT Introduction
================
Generally speaking, CAT introduces a mechanism for software to enable
cache allocation based on application priority or Class of Service
("COS"). Cache allocation for the respective applications is then
restricted based on the COS with which they are associated. Each COS can
be configured using capacity bitmasks ("CBM") which represent cache
capacity and indicate the degree of overlap and isolation between
classes. For each logical processor there is a register
exposed(IA32_PQR_ASSOC MSR) to allow the OS/VMM to specify a COS when an
application, thread or VM is scheduled. Cache allocation for the
indicated application/thread/VM is then controlled automatically by the
hardware based on the COS and the CBM associated with that class.
Hardware initializes COS of each logical processor to 0 and the
corresponding CBM is set to all-ones, means all the system cache
resource can be used for each application.

For more information please refer to Section 17.15 in the Intel SDM [1].


Design Overview
===============
- Domain COS/CBM association
When enforcing cache allocation for VMs, the minimum granularity is
defined as the domain. All Virtual CPUs ("VCPUs") of a domain have the
same COS, and therefore, correspond to the same CBM. COS is used only in
hypervisor and is transparent to tool stack/user. System administrator
can specify the initial CBM for each domain or change it at runtime using 
tool stack. Hypervisor then choses a free COS to associate it with that
CBM or find a existed COS which has the same CBM.

- VCPU Schedule
When VCPU is scheduled on the physical CPU ("PCPU"), its COS value is
then written to MSR (IA32_PQR_ASSOC) of PCPU to notify hardware to use 
the new COS. The cache allocation is then enforced by hardware.

- Multi-Socket
In multi-socket environment, each VCPU may be scheduled on different
sockets. The hardware CAT ability(such as maximum supported COS and length
of CBM) maybe different among sockets. For such system, per-socket COS/CBM
configuration of a domain is specified. Hypervisor then use this per-socket
CBM information for VCPU schedule.


Implementation Description
==========================
In this design, one principal is that only implementing the cache
enforcement mechanism in hypervisor but leaving the cache allocation
policy to user space tool stack. In this way some complex governors then
can be implemented in tool stack. 

In summary, hypervisor changes include:
1) A new field "cat_info" in domain structure to indicate the CAT
   information for each socket. It points to array of structure:
   struct domain_socket_cat_info {
       unsigned int cbm; /* CBM specified by toolstack  */
       unsigned int cos; /* COS allocated by Hypervisor */
   }
2) A new SYSCTL to expose the CAT information to tool stack:
     * Whether CAT is enabled;
     * Max COS supported;
     * Length of CBM;
     * Other needed information from host cpuid;
3) A new DOMCTL to allow tool stack to set/get CBM for a specified domain
   for each socket.
4) Context switch: write COS of domain to MSR (IA32_PQR_ASSOC) of PCPU.
5) XSM policy to restrict the functions visibility to control domain only.

Hypervisor interfaces:
1) Boot line param: "psr=cat" to enable the feature.
2) SYSCTL: XEN_SYSCTL_psr_cat_op
     - XEN_SYSCTL_PSR_CAT_INFO_GET: Get system CAT information;
3) DOMCTL: XEN_DOMCTL_psr_cat_op
     - XEN_DOMCTL_PSR_CAT_OP_CBM_SET: Set CBM value for a domain.
     - XEN_DOMCTL_PSR_CAT_OP_CBM_GET: Get CBM value for a domain.

xl interfaces:
1) psr-cat-show: Show system/runtime CAT information.
     => XEN_SYSCTL_PSR_CAT_INFO_GET/XEN_DOMCTL_PSR_CAT_OP_CBM_GET
2) psr-cat-cbm-set [dom] [cbm] [socket]: Set CBM for a domain.
     => XEN_DOMCTL_PSR_CAT_OP_CBM_SET


Hardware Limitation & Performance Improvement
=============================================
As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
switch. If the change is frequent then hardware may fail to strictly
enforce the cache allocation basing on the specified COS. Due to this
the strict placement characteristic would soften if VCPU is migrated on
different PCPU frequently.

For this reason, lazy updating for IA32_PQR_ASSOC will be done. Also this
design allows CAT to run in two modes:

1) Non Affinitized mode: Each VM can be freely scheduled on any PCPU
assigning its COS as it does.

2) Affinitized mode: Each PCPU is assigned a fixed COS and a VM can be
scheduled on the PCPU only when it has a same COS. It's less flexible
but can be an option for those who must have strict COS placement or in
cases where problems have arisen because of the less strict nature of the
non-affinitized mode.

However, no additional code is designed to support these two modes. CAT is
already running in non affinitized mode by default. If affinitized mode
is desirable, then existed "xl vcpu-pin" command can be used to pin all
the VCPUs which has the same COS to certain fixed PCPUs so that these 
PCPUs always have the same COS set.

[1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf

Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 13:18:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 13: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 1XzQ67-0007hS-MH; Fri, 12 Dec 2014 13:17:31 +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 1XzQ66-0007hN-Nj
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 13:17:30 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	BB/12-28296-9EAEA845; Fri, 12 Dec 2014 13:17:29 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418390249!12941808!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_50_75
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30447 invoked from network); 12 Dec 2014 13:17:29 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 13:17:29 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DCA57AC40;
	Fri, 12 Dec 2014 13:17:28 +0000 (UTC)
Message-ID: <548AEAE7.8020604@suse.com>
Date: Fri, 12 Dec 2014 14:17: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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	David Vrabel <david.vrabel@citrix.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, 
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] Xen's Linux kernel config 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-Transfer-Encoding: 7bit
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,

This is a design proposal for a rework of the config options on the
Linux kernel which are related to Xen.

The need to do so arose from the fact that it is currently not
possible to build the Xen frontend drivers for a non-pvops kernel,
e.g. to run them in a HVM-domain. There are more drawbacks in the
current config options to which I'll come later.

Current Xen related config options are as follows:

Option                          Selects                 Depends
---------------------------------------------------------------------
XEN                             PARAVIRT_CLOCK(x86)     PARAVIRT(x86)
                                 XEN_HAVE_PVMMU(x86)
                                 SWIOTLB_XEN(arm,arm64)
   PCI_XEN(x86)                  SWIOTLB_XEN
   XEN_DOM0                                              PCI_XEN(x86)
     XEN_BACKEND
       XEN_BLKDEV_BACKEND
       XEN_PCIDEV_BACKEND(x86)
       XEN_SCSI_BACKEND
       XEN_NETDEV_BACKEND
     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
     XEN_MCE_LOG(x86)
   XEN_PVHVM(x86)
     XEN_PVH(x86)
   XEN_MAX_DOMAIN_MEMORY(x86)
   XEN_SAVE_RESTORE(x86)
   XEN_DEBUG_FS(x86)
   XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
                                 INPUT_XEN_KBDDEV_FRONTEND
   XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
   HVC_XEN
     HVC_XEN_FRONTEND            XEN_XENBUS_FRONTEND
   TCG_XEN                       XEN_XENBUS_FRONTEND
   XEN_PCIDEV_FRONTEND           PCI_XEN
                                 XEN_XENBUS_FRONTEND
   XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
   INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
   XEN_WDT
   XEN_BALLOON
     XEN_SELFBALLOONING                                  XEN_TMEM
     XEN_BALLOON_MEMORY_HOTPLUG
     XEN_SCRUB_PAGES
   XEN_DEV_EVTCHN
   XENFS                         XEN_PRIVCMD
     XEN_COMPAT_XENFS
   XEN_SYS_HYPERVISOR
   XEN_XENBUS_FRONTEND
   XEN_GNTDEV
   XEN_GRANT_DEV_ALLOC
   SWIOTLB_XEN
   XEN_TMEM(x86)
   XEN_PRIVCMD
   XEN_STUB(x86_64)                                      BROKEN
   XEN_ACPI_PROCESSOR(x86)
   XEN_HAVE_PVMMU
   XEN_EFI(x64)
   XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND

Legend:
- The first column are the Xen config options. Indentation in this
   column reflects the dependency between those options (e.g.
   XEN_SCSI_BACKEND depends on XEN_BACKEND, which in turn depends on
   XEN_DOM0, which depends on XEN).
- The second column shows the options which are selected automatically
   if the corresponding option in the first column is configured.
- The last column shows additional dependencies which can't be shown via
   the indentation level of the first column.
- Some options or dependencies are architecture specific, they are
   listed in brackets (e.g. XEN_TMEM which is available for x86 only).
- Non-Xen options are mentioned only if they seem to be really relevant,
   like e.g. PARAVIRT or BROKEN.

There are several reasons to change the config options:
- Be able to build Xen frontend drivers for HVM domains without the need
   for choosing a pvops kernel: currently the frontend drivers need XEN
   configured which depends on PARAVIRT.
- Be able to build a Dom0 using XEN_PVH without having to configure
   XEN_HAVE_PVMMU.
- Be able to build HVM driver domains.
- Some features are available for x86 only, in spite of being not
   architecture specific, e.g. XEN_DEBUG_FS or XEN_TMEM.

As a first draft I'd suggest the following:

Option                          Selects                 Depends
----------------------------------------------------------------------
XEN                             SWIOTLB_XEN(arm,arm64)
   XEN_PV(x86)                   XEN_HAVE_PVMMU
                                 PARAVIRT
                                 PARAVIRT_CLOCK
   XEN_PVH(x86)                  XEN_PVHVM
                                 PARAVIRT
                                 PARAVIRT_CLOCK
   XEN_BACKEND                                           XEN_PV(x86) ||
                                                         XEN_PVH(x86) ||
                                                         XEN_PVHVM
     XEN_BLKDEV_BACKEND
     XEN_PCIDEV_BACKEND(x86)
     XEN_SCSI_BACKEND
     XEN_NETDEV_BACKEND
   PCI_XEN(x86)                  SWIOTLB_XEN
   XEN_DOM0                      XEN_BACKEND             XEN_PV(x86) ||
                                 PCI_XEN(x86)            XEN_PVH(x86)
     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
     XEN_MCE_LOG(x86)
   XEN_MAX_DOMAIN_MEMORY(x86)
   XEN_SAVE_RESTORE(x86)
   XEN_DEBUG_FS
   XEN_WDT
   XEN_BALLOON
     XEN_SELFBALLOONING                                  XEN_TMEM
     XEN_BALLOON_MEMORY_HOTPLUG
     XEN_SCRUB_PAGES
   XENFS                         XEN_PRIVCMD
     XEN_COMPAT_XENFS
   XEN_SYS_HYPERVISOR
   XEN_DEV_EVTCHN
   XEN_GNTDEV
   XEN_GRANT_DEV_ALLOC
   SWIOTLB_XEN
   XEN_TMEM
   XEN_PRIVCMD
   XEN_STUB(x86_64)                                      BROKEN
   XEN_ACPI_PROCESSOR(x86)
   XEN_HAVE_PVMMU
   XEN_EFI(x64)
XEN_PVHVM
XEN_FRONTEND                                            XEN_PV ||
                                                         XEN_PVH ||
                                                         XEN_PVHVM
   XEN_XENBUS_FRONTEND
   XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
                                 INPUT_XEN_KBDDEV_FRONTEND
   XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
   HVC_XEN_FRONTEND              XEN_XENBUS_FRONTEND
                                 HVC_XEN
   TCG_XEN                       XEN_XENBUS_FRONTEND
   XEN_PCIDEV_FRONTEND           PCI_XEN
                                 XEN_XENBUS_FRONTEND
   XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
   INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
   XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND

There might be some further adjustments needed (should XEN_DEV_EVTCHN
and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The
main difference to the current status is the XEN setting no longer
controlling all other options.

Changing the config options in this way surely will need some
adjustments in the drivers, but this can be discussed when we agree
on the future config dependencies.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 13:18:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 13: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 1XzQ67-0007hS-MH; Fri, 12 Dec 2014 13:17:31 +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 1XzQ66-0007hN-Nj
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 13:17:30 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	BB/12-28296-9EAEA845; Fri, 12 Dec 2014 13:17:29 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418390249!12941808!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_50_75
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30447 invoked from network); 12 Dec 2014 13:17:29 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 13:17:29 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DCA57AC40;
	Fri, 12 Dec 2014 13:17:28 +0000 (UTC)
Message-ID: <548AEAE7.8020604@suse.com>
Date: Fri, 12 Dec 2014 14:17: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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	David Vrabel <david.vrabel@citrix.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, 
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] Xen's Linux kernel config 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-Transfer-Encoding: 7bit
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,

This is a design proposal for a rework of the config options on the
Linux kernel which are related to Xen.

The need to do so arose from the fact that it is currently not
possible to build the Xen frontend drivers for a non-pvops kernel,
e.g. to run them in a HVM-domain. There are more drawbacks in the
current config options to which I'll come later.

Current Xen related config options are as follows:

Option                          Selects                 Depends
---------------------------------------------------------------------
XEN                             PARAVIRT_CLOCK(x86)     PARAVIRT(x86)
                                 XEN_HAVE_PVMMU(x86)
                                 SWIOTLB_XEN(arm,arm64)
   PCI_XEN(x86)                  SWIOTLB_XEN
   XEN_DOM0                                              PCI_XEN(x86)
     XEN_BACKEND
       XEN_BLKDEV_BACKEND
       XEN_PCIDEV_BACKEND(x86)
       XEN_SCSI_BACKEND
       XEN_NETDEV_BACKEND
     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
     XEN_MCE_LOG(x86)
   XEN_PVHVM(x86)
     XEN_PVH(x86)
   XEN_MAX_DOMAIN_MEMORY(x86)
   XEN_SAVE_RESTORE(x86)
   XEN_DEBUG_FS(x86)
   XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
                                 INPUT_XEN_KBDDEV_FRONTEND
   XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
   HVC_XEN
     HVC_XEN_FRONTEND            XEN_XENBUS_FRONTEND
   TCG_XEN                       XEN_XENBUS_FRONTEND
   XEN_PCIDEV_FRONTEND           PCI_XEN
                                 XEN_XENBUS_FRONTEND
   XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
   INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
   XEN_WDT
   XEN_BALLOON
     XEN_SELFBALLOONING                                  XEN_TMEM
     XEN_BALLOON_MEMORY_HOTPLUG
     XEN_SCRUB_PAGES
   XEN_DEV_EVTCHN
   XENFS                         XEN_PRIVCMD
     XEN_COMPAT_XENFS
   XEN_SYS_HYPERVISOR
   XEN_XENBUS_FRONTEND
   XEN_GNTDEV
   XEN_GRANT_DEV_ALLOC
   SWIOTLB_XEN
   XEN_TMEM(x86)
   XEN_PRIVCMD
   XEN_STUB(x86_64)                                      BROKEN
   XEN_ACPI_PROCESSOR(x86)
   XEN_HAVE_PVMMU
   XEN_EFI(x64)
   XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND

Legend:
- The first column are the Xen config options. Indentation in this
   column reflects the dependency between those options (e.g.
   XEN_SCSI_BACKEND depends on XEN_BACKEND, which in turn depends on
   XEN_DOM0, which depends on XEN).
- The second column shows the options which are selected automatically
   if the corresponding option in the first column is configured.
- The last column shows additional dependencies which can't be shown via
   the indentation level of the first column.
- Some options or dependencies are architecture specific, they are
   listed in brackets (e.g. XEN_TMEM which is available for x86 only).
- Non-Xen options are mentioned only if they seem to be really relevant,
   like e.g. PARAVIRT or BROKEN.

There are several reasons to change the config options:
- Be able to build Xen frontend drivers for HVM domains without the need
   for choosing a pvops kernel: currently the frontend drivers need XEN
   configured which depends on PARAVIRT.
- Be able to build a Dom0 using XEN_PVH without having to configure
   XEN_HAVE_PVMMU.
- Be able to build HVM driver domains.
- Some features are available for x86 only, in spite of being not
   architecture specific, e.g. XEN_DEBUG_FS or XEN_TMEM.

As a first draft I'd suggest the following:

Option                          Selects                 Depends
----------------------------------------------------------------------
XEN                             SWIOTLB_XEN(arm,arm64)
   XEN_PV(x86)                   XEN_HAVE_PVMMU
                                 PARAVIRT
                                 PARAVIRT_CLOCK
   XEN_PVH(x86)                  XEN_PVHVM
                                 PARAVIRT
                                 PARAVIRT_CLOCK
   XEN_BACKEND                                           XEN_PV(x86) ||
                                                         XEN_PVH(x86) ||
                                                         XEN_PVHVM
     XEN_BLKDEV_BACKEND
     XEN_PCIDEV_BACKEND(x86)
     XEN_SCSI_BACKEND
     XEN_NETDEV_BACKEND
   PCI_XEN(x86)                  SWIOTLB_XEN
   XEN_DOM0                      XEN_BACKEND             XEN_PV(x86) ||
                                 PCI_XEN(x86)            XEN_PVH(x86)
     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
     XEN_MCE_LOG(x86)
   XEN_MAX_DOMAIN_MEMORY(x86)
   XEN_SAVE_RESTORE(x86)
   XEN_DEBUG_FS
   XEN_WDT
   XEN_BALLOON
     XEN_SELFBALLOONING                                  XEN_TMEM
     XEN_BALLOON_MEMORY_HOTPLUG
     XEN_SCRUB_PAGES
   XENFS                         XEN_PRIVCMD
     XEN_COMPAT_XENFS
   XEN_SYS_HYPERVISOR
   XEN_DEV_EVTCHN
   XEN_GNTDEV
   XEN_GRANT_DEV_ALLOC
   SWIOTLB_XEN
   XEN_TMEM
   XEN_PRIVCMD
   XEN_STUB(x86_64)                                      BROKEN
   XEN_ACPI_PROCESSOR(x86)
   XEN_HAVE_PVMMU
   XEN_EFI(x64)
XEN_PVHVM
XEN_FRONTEND                                            XEN_PV ||
                                                         XEN_PVH ||
                                                         XEN_PVHVM
   XEN_XENBUS_FRONTEND
   XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
                                 INPUT_XEN_KBDDEV_FRONTEND
   XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
   HVC_XEN_FRONTEND              XEN_XENBUS_FRONTEND
                                 HVC_XEN
   TCG_XEN                       XEN_XENBUS_FRONTEND
   XEN_PCIDEV_FRONTEND           PCI_XEN
                                 XEN_XENBUS_FRONTEND
   XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
   INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
   XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND

There might be some further adjustments needed (should XEN_DEV_EVTCHN
and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The
main difference to the current status is the XEN setting no longer
controlling all other options.

Changing the config options in this way surely will need some
adjustments in the drivers, but this can be discussed when we agree
on the future config dependencies.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 13:20:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 13:20:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzQ8g-0007mz-7v; Fri, 12 Dec 2014 13:20: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 1XzQ8f-0007ms-3Y
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 13:20:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	87/60-09842-88BEA845; Fri, 12 Dec 2014 13:20:08 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418390407!7899243!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30098 invoked from network); 12 Dec 2014 13:20:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 13:20:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="27831025"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Matt Wilson <msw@linux.com>
Thread-Topic: [Xen-devel] [PATCH v2] x86/hvm: Extend HVM cpuid leaf with
	vcpu id
Thread-Index: AQHP+dYX9KDDbq4yNE+XWM7EigcuAZyLLMcAgAD6vgA=
Date: Fri, 12 Dec 2014 13:20:05 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD025789A35@AMSPEX01CL01.citrite.net>
References: <1415287584-11322-1-git-send-email-paul.durrant@citrix.com>
	<20141211213609.GA11251@u109add4315675089e695.ant.amazon.com>
In-Reply-To: <20141211213609.GA11251@u109add4315675089e695.ant.amazon.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>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [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

> -----Original Message-----
> From: Matt Wilson [mailto:mswilson@gmail.com] On Behalf Of Matt Wilson
> Sent: 11 December 2014 23:17
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: Extend HVM cpuid leaf with
> vcpu id
> 
> On Thu, Nov 06, 2014 at 03:26:24PM +0000, 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.
> 
> One more tangent on this, since this is partially considered in a
> Windows context. Why not use the existing Viridian virtual processor
> index MSR for this, since that would work on Xen today.
> 
> xen/arch/x86/hvm/viridian.c:
> > #define VIRIDIAN_MSR_VP_INDEX                   0x40000002
> > ...
> >     case VIRIDIAN_MSR_VP_INDEX:
> >        perfc_incr(mshv_rdmsr_vp_index);
> >        *val = v->vcpu_id;
> >        break;
> 

Yes, that would work for VMs where viridian is enabled, but there's no requirement that viridian is enabled to install PV drivers even in Windows. I guess ACPI is the only robust way to get vcpu id in an HVM guest in the absence of the new cpuid leaf.

  Paul

> --msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 13:20:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 13:20:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzQ8g-0007mz-7v; Fri, 12 Dec 2014 13:20: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 1XzQ8f-0007ms-3Y
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 13:20:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	87/60-09842-88BEA845; Fri, 12 Dec 2014 13:20:08 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418390407!7899243!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30098 invoked from network); 12 Dec 2014 13:20:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 13:20:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="27831025"
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Matt Wilson <msw@linux.com>
Thread-Topic: [Xen-devel] [PATCH v2] x86/hvm: Extend HVM cpuid leaf with
	vcpu id
Thread-Index: AQHP+dYX9KDDbq4yNE+XWM7EigcuAZyLLMcAgAD6vgA=
Date: Fri, 12 Dec 2014 13:20:05 +0000
Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD025789A35@AMSPEX01CL01.citrite.net>
References: <1415287584-11322-1-git-send-email-paul.durrant@citrix.com>
	<20141211213609.GA11251@u109add4315675089e695.ant.amazon.com>
In-Reply-To: <20141211213609.GA11251@u109add4315675089e695.ant.amazon.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>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [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

> -----Original Message-----
> From: Matt Wilson [mailto:mswilson@gmail.com] On Behalf Of Matt Wilson
> Sent: 11 December 2014 23:17
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: Extend HVM cpuid leaf with
> vcpu id
> 
> On Thu, Nov 06, 2014 at 03:26:24PM +0000, 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.
> 
> One more tangent on this, since this is partially considered in a
> Windows context. Why not use the existing Viridian virtual processor
> index MSR for this, since that would work on Xen today.
> 
> xen/arch/x86/hvm/viridian.c:
> > #define VIRIDIAN_MSR_VP_INDEX                   0x40000002
> > ...
> >     case VIRIDIAN_MSR_VP_INDEX:
> >        perfc_incr(mshv_rdmsr_vp_index);
> >        *val = v->vcpu_id;
> >        break;
> 

Yes, that would work for VMs where viridian is enabled, but there's no requirement that viridian is enabled to install PV drivers even in Windows. I guess ACPI is the only robust way to get vcpu id in an HVM guest in the absence of the new cpuid leaf.

  Paul

> --msw

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 14:44:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 14:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzRRE-0002vz-4B; Fri, 12 Dec 2014 14:43:24 +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 1XzRRC-0002v8-T5
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 14:43:22 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	9F/96-02699-A0FFA845; Fri, 12 Dec 2014 14:43:22 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418395401!14726252!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13997 invoked from network); 12 Dec 2014 14:43:21 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 14:43:21 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so2701132wiw.13
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 06:43: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:from:to:cc:subject:date:message-id;
	bh=z8UNxp/BP7Uj8WrkySvqT4h5Zo7bLWrmvY8Atd/5wXM=;
	b=IMDMT3JuTvL1m0q1RfRH2kUEirc8pPxF1zooz/C7IqdlapoItkt2VaDI3pNeUpc6ve
	YrDsS428AwjFUmlyq0zW/d4uS8d4ctcS4oJXQNMwSI2gFxbwmGm6DEQe+SsAB+zZc8C/
	uWKgEhX3rZ30d2EpAKjy+yGva5SIDh4Bx++OnMf3CzxXutQqE99ARB9Fs+6ncEK4iQDD
	+vKNiibGJzFg6iaR0sIt/wrAhbpH60viv8E7MkIZbRIH4HPLvABtq28WWbJuIRvlwR63
	ZHsPPckahADTBcU265rEEoJHWnJFbY9cuXPKncKbdQQAaORSqjPg0IwYizLBapnn1m+Y
	qeaQ==
X-Gm-Message-State: ALoCoQmTl3LwTIHAy4vfJFu7HOogQwGXzd4mJNrJjQNYiP0DCRO6bTMRslKz8wGsG9OqGO7xlgc3
X-Received: by 10.194.79.199 with SMTP id l7mr28169445wjx.136.1418395400988;
	Fri, 12 Dec 2014 06:43:20 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id cq4sm2066234wjc.35.2014.12.12.06.43.19
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 12 Dec 2014 06:43:19 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 12 Dec 2014 14:43:08 +0000
Message-Id: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
Cc: ian.campbell@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com,
	parth.dixit@linaro.org, christoffer.dall@linaro.org
Subject: [Xen-devel] [PATCH for-4.6 0/4] Find automatically a PPI for the
	DOM0 even channel IRQ
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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,

This patch series replaces the per-platform hardcoded event channel interrupt
to a generic solution. It will make the port to a new platform more easier and
may avoid to introduce per-platform code with the new upcoming ACPI support.

This could be done by keeping track of vIRQ (emulated and assigned) used by
a domain.

Parth: I provided a branch on my personal repo [1]. It's based on the latest
upstream branch. You can use vgic_allocate_virq(d, 0) to allocate the event
channel PPI.

Sincerely yours,

[1] git://xenbits.xen.org/people/julieng/xen-unstable.git branch find-evtchn

Julien Grall (4):
  xen/arm: vgic: Rename nr_lines into nr_spis
  xen/arm: vgic: Keep track of vIRQ used by a domain
  xen/arm: vgic: notice if the vIRQ is not allocated when the guest
    enable it
  xen/arm: Find automatically a PPI for the DOM0 event channel interrupt

 xen/arch/arm/domain.c                | 13 +++--
 xen/arch/arm/domain_build.c          | 16 ++++++
 xen/arch/arm/gic-v2.c                |  2 -
 xen/arch/arm/gic-v3.c                |  2 +-
 xen/arch/arm/platform.c              |  7 ---
 xen/arch/arm/platforms/xgene-storm.c |  5 +-
 xen/arch/arm/vgic-v2.c               |  2 +-
 xen/arch/arm/vgic-v3.c               |  2 +-
 xen/arch/arm/vgic.c                  | 95 ++++++++++++++++++++++++++++++++----
 xen/arch/arm/vtimer.c                | 15 ++++++
 xen/include/asm-arm/domain.h         |  3 +-
 xen/include/asm-arm/platform.h       |  4 --
 xen/include/asm-arm/vgic.h           | 17 ++++++-
 13 files changed, 152 insertions(+), 31 deletions(-)

-- 
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 Dec 12 14:44:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 14:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzRRH-0002wc-L1; Fri, 12 Dec 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 <julien.grall@linaro.org>) id 1XzRRG-0002wK-9H
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 14:43:26 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	F2/35-17958-D0FFA845; Fri, 12 Dec 2014 14:43:25 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418395404!12900431!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16195 invoked from network); 12 Dec 2014 14:43:24 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 14:43:24 -0000
Received: by mail-wg0-f51.google.com with SMTP id x12so9152450wgg.24
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 06:43: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=wHPVoJQgp0YGfRTqZj7/pDEy0gbhADWCpccgBgsIbaQ=;
	b=dPiQ70zfIF9abClwy2ZzPf0ttvXu873jroZpEsBZKdnnFVVqF8zamxaz0pkAHIYa5h
	6GXuY/O/D5UxrEOtnfC7sizuFUgcyAj17VYGvg9GGDZDYTo38u6dC8rPOcS6IuIyfveN
	4IJOolxbkpwaFvAdDp/kyWgBhe1Au3ZtPRBe/QaVkdBZQeMEJnfttUZck8I+fpi/gUXR
	4gI5uyNaS53Nn221XOG2ekbQOySjhTxnRp0UviewchEoFriUGIr0CN1ku2pmxegxME+f
	fQv8eUej3tUniN7Xn0YFie6IiMwh2JeT/Fx2C8BtPBDR8kZalinWzQskNi+N56RWX7K2
	SxWg==
X-Gm-Message-State: ALoCoQkH5e73habpz/Etyfo5s9I8IFq8Di7ybyT/vXEmX1gmBfv5R9smbTxqNnWPIJRHyFcEleIm
X-Received: by 10.194.174.40 with SMTP id bp8mr27403693wjc.104.1418395404370; 
	Fri, 12 Dec 2014 06:43:24 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id cq4sm2066234wjc.35.2014.12.12.06.43.22
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 12 Dec 2014 06:43:23 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 12 Dec 2014 14:43:10 +0000
Message-Id: <1418395392-30460-3-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
Cc: ian.campbell@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com,
	parth.dixit@linaro.org, christoffer.dall@linaro.org
Subject: [Xen-devel] [PATCH for-4.6 2/4] xen/arm: vgic: Keep track of vIRQ
	used by a domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 it's easy to know which hardware IRQ is assigned to a domain, there
is no way to know which IRQ is emulated by Xen for a specific domain.

Introduce a bitmap to keep track of every vIRQ used by a domain. This
will be used later to find free vIRQ for interrupt device assignment and
emulated interrupt.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/domain_build.c          |  6 +++
 xen/arch/arm/platforms/xgene-storm.c |  4 ++
 xen/arch/arm/vgic.c                  | 76 ++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vtimer.c                | 15 +++++++
 xen/include/asm-arm/domain.h         |  1 +
 xen/include/asm-arm/vgic.h           | 13 ++++++
 6 files changed, 115 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index de180d8..c238c8f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -968,6 +968,12 @@ static int map_device(struct domain *d, struct dt_device_node *dev)
         irq = res;
 
         DPRINT("irq %u = %u\n", i, irq);
+        /*
+         * Checking the return of vgic_reserve_virq is not
+         * necessary. It should not fail except when we try to map
+         * twice the IRQ. This can happen if the IRQ is shared
+         */
+        vgic_reserve_virq(d, irq);
         res = route_irq_to_guest(d, irq, dt_node_name(dev));
         if ( res )
         {
diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 0b3492d..416d42c 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -71,6 +71,10 @@ static int map_one_spi(struct domain *d, const char *what,
 
     printk("Additional IRQ %u (%s)\n", irq, what);
 
+    if ( !vgic_reserve_virq(d, irq) )
+        printk("Failed to reserve the vIRQ %u on dom%d\n",
+               irq, d->domain_id);
+
     ret = route_irq_to_guest(d, irq, what);
     if ( ret )
         printk("Failed to route %s to dom%d\n", what, d->domain_id);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 75cb7ff..dbfc259 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -87,6 +87,8 @@ int domain_vgic_init(struct domain *d)
         return -ENODEV;
     }
 
+    spin_lock_init(&d->arch.vgic.lock);
+
     d->arch.vgic.shared_irqs =
         xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
     if ( d->arch.vgic.shared_irqs == NULL )
@@ -107,6 +109,15 @@ int domain_vgic_init(struct domain *d)
 
     d->arch.vgic.handler->domain_init(d);
 
+    d->arch.vgic.allocated_irqs =
+        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irqs(d)));
+    if ( !d->arch.vgic.allocated_irqs )
+        return -ENOMEM;
+
+    /* vIRQ0-15 (SGIs) are reserved */
+    for (i = 0; i <= 15; i++)
+        set_bit(i, d->arch.vgic.allocated_irqs);
+
     return 0;
 }
 
@@ -119,6 +130,7 @@ void domain_vgic_free(struct domain *d)
 {
     xfree(d->arch.vgic.shared_irqs);
     xfree(d->arch.vgic.pending_irqs);
+    xfree(d->arch.vgic.allocated_irqs);
 }
 
 int vcpu_vgic_init(struct vcpu *v)
@@ -441,6 +453,70 @@ int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
     return v->domain->arch.vgic.handler->emulate_sysreg(regs, hsr);
 }
 
+bool_t vgic_reserve_virq(struct domain *d, unsigned int virq)
+{
+    bool_t reserved;
+
+    if ( virq >= vgic_num_irqs(d) )
+        return 0;
+
+    spin_lock(&d->arch.vgic.lock);
+    reserved = !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
+    spin_unlock(&d->arch.vgic.lock);
+
+    return reserved;
+}
+
+int vgic_allocate_virq(struct domain *d, bool_t spi)
+{
+    int ret = -1;
+    unsigned int virq;
+
+    spin_lock(&d->arch.vgic.lock);
+    if ( !spi )
+    {
+        virq = find_first_zero_bit(d->arch.vgic.allocated_irqs, 32);
+        if ( virq >= 32 )
+            goto unlock;
+    }
+    else
+    {
+        virq = find_next_zero_bit(d->arch.vgic.allocated_irqs,
+                                  32, vgic_num_irqs(d));
+        if ( virq >= vgic_num_irqs(d) )
+            goto unlock;
+    }
+
+    set_bit(virq, d->arch.vgic.allocated_irqs);
+    ret = virq;
+
+unlock:
+    spin_unlock(&d->arch.vgic.lock);
+
+    return ret;
+}
+
+void vgic_free_virq(struct domain *d, unsigned int virq)
+{
+    unsigned int spi;
+
+    if ( is_hardware_domain(d) )
+        return;
+
+    if ( virq < 32 && virq >= vgic_num_irqs(d) )
+        return;
+
+    spi = virq - 32;
+
+    /* Taking the vGIC domain lock is not necessary. We don't care if
+     * the bit is cleared a bit later. What only matters is bit to 1.
+     *
+     * With this solution vgic_allocate may fail to find an vIRQ if the
+     * allocated_irqs is fully. But we don't care.
+     */
+    clear_bit(spi, d->arch.vgic.allocated_irqs);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 2e95ceb..de660bb 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -49,6 +49,21 @@ int domain_vtimer_init(struct domain *d)
 {
     d->arch.phys_timer_base.offset = NOW();
     d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0);
+
+    /* At this stage vgic_reserve_virq can't fail */
+    if ( is_hardware_domain(d) )
+    {
+        BUG_ON(!vgic_reserve_virq(d, timer_get_irq(TIMER_PHYS_SECURE_PPI)));
+        BUG_ON(!vgic_reserve_virq(d, timer_get_irq(TIMER_PHYS_NONSECURE_PPI)));
+        BUG_ON(!vgic_reserve_virq(d, timer_get_irq(TIMER_VIRT_PPI)));
+    }
+    else
+    {
+        BUG_ON(!vgic_reserve_virq(d, GUEST_TIMER_PHYS_S_PPI));
+        BUG_ON(!vgic_reserve_virq(d, GUEST_TIMER_PHYS_NS_PPI));
+        BUG_ON(!vgic_reserve_virq(d, GUEST_TIMER_VIRT_PPI));
+    }
+
     return 0;
 }
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 8b7dd85..d302fc9 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -90,6 +90,7 @@ struct arch_domain
         spinlock_t lock;
         int ctlr;
         int nr_spis; /* Number of SPIs */
+        unsigned long *allocated_irqs; /* bitmap of IRQs allocated */
         struct vgic_irq_rank *shared_irqs;
         /*
          * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 74d5a4e..9e167fa 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -199,6 +199,19 @@ extern int vgic_to_sgi(struct vcpu *v, register_t sgir,
                        enum gic_sgi_mode irqmode, int virq,
                        unsigned long vcpu_mask);
 extern void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq);
+
+/* Reserve a specific guest vIRQ */
+extern bool_t vgic_reserve_virq(struct domain *d, unsigned int virq);
+
+/*
+ * Allocate a guest VIRQ
+ *  - spi == 0 => allocate a PPI. It will be the same on every vCPU
+ *  - spi == 0 => allocate an SGI
+ */
+extern int vgic_allocate_virq(struct domain *d, bool_t spi);
+
+extern void vgic_free_virq(struct domain *d, unsigned int irq);
+
 #endif /* __ASM_ARM_VGIC_H__ */
 
 /*
-- 
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 Dec 12 14:44:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 14:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzRRJ-0002x4-Bu; Fri, 12 Dec 2014 14:43:29 +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 1XzRRH-0002wY-Pc
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 14:43:28 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	8D/FF-05632-F0FFA845; Fri, 12 Dec 2014 14:43:27 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418395403!12978580!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28850 invoked from network); 12 Dec 2014 14:43:23 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 14:43:23 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so2699781wid.9
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 06:43: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:in-reply-to
	:references;
	bh=2ztTRX34455TnEdsLeo2kkaZQr2R358MbzJ7UpDsfPs=;
	b=DMLJAB7S0dK4mauSNgJsF8eBb6m4+Wh38CabhsQSAX+xbSzgIzqjGPylmVxFMnAW89
	nL6XvbRk4N08giBYGFgiPMQo2++yLUiZsVZfgcW+uvv/kmHTQEj9WDPl2SK+HT9GmlZA
	Wd3rleOFTXvkhD3/77dkvRHZuGeBszEXF0FD+3q1uMYbYYwwrbNNK+kDdM9mwuMkkBjY
	vaZ5m0pD0mDFgIhkd5fTgsHsZtp9uP4p/lSMNev+ARpofh+mG4yM+fGIacBs5elJUb9E
	0RWGVKQXFfZW356xo3Ns6K2Sy5MhWOZbgOFNqEaFotr9jw2QIcgE5hzLbjOY1vPjl0VH
	fq8w==
X-Gm-Message-State: ALoCoQlsNxhyr32FWJpWljJtzdIDQ2jkwUuHEPMkZUI+gVv/5uaL6aQdHBGf0J/KJ0p875zBMyhm
X-Received: by 10.180.160.144 with SMTP id xk16mr8594928wib.12.1418395402718; 
	Fri, 12 Dec 2014 06:43:22 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id cq4sm2066234wjc.35.2014.12.12.06.43.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 12 Dec 2014 06:43:21 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 12 Dec 2014 14:43:09 +0000
Message-Id: <1418395392-30460-2-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
Cc: ian.campbell@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com,
	parth.dixit@linaro.org, christoffer.dall@linaro.org
Subject: [Xen-devel] [PATCH for-4.6 1/4] xen/arm: vgic: Rename nr_lines into
	nr_spis
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The field nr_lines in the arch_domain vgic structure contains the number of
SPIs for the emulated GIC. Using the nr_lines make confusion with the GIC
code, where it means the number of IRQs. This can lead to coding error.

Also introduce vgic_nr_lines to get the number of IRQ handled by the emulated
GIC.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

---
    It was part of the platform device passthrough series: https://patches.linaro.org/34661/

    Stefano: I've kept your ack from the previous version. Let me know
    if there is any issue.

    Changes in v3:
        - Add acked-by from Stefano.
        - Update the patch to also modify GICv3 code which has been
        pushed recently

    Changes in v2:
        - Patch added.
---
 xen/arch/arm/gic-v2.c        |  2 --
 xen/arch/arm/gic-v3.c        |  2 +-
 xen/arch/arm/vgic-v2.c       |  2 +-
 xen/arch/arm/vgic-v3.c       |  2 +-
 xen/arch/arm/vgic.c          | 15 ++++++---------
 xen/include/asm-arm/domain.h |  2 +-
 xen/include/asm-arm/vgic.h   |  4 +++-
 7 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..31fb81a 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -432,8 +432,6 @@ static int gicv2v_setup(struct domain *d)
         d->arch.vgic.cbase = GUEST_GICC_BASE;
     }
 
-    d->arch.vgic.nr_lines = 0;
-
     /*
      * Map the gic virtual cpu interface in the gic cpu interface
      * region of the guest.
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 076aa62..ec48fc1 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -922,7 +922,7 @@ static int gicv_v3_init(struct domain *d)
         d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
     }
 
-    d->arch.vgic.nr_lines = 0;
+    d->arch.vgic.nr_spis = 0;
 
     return 0;
 }
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 1369f78..039e19a 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -54,7 +54,7 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
         /* No secure world support for guests. */
         vgic_lock(v);
         *r = ( (v->domain->max_vcpus << 5) & GICD_TYPE_CPUS )
-            |( ((v->domain->arch.vgic.nr_lines / 32)) & GICD_TYPE_LINES );
+            |( ((v->domain->arch.vgic.nr_spis / 32)) & GICD_TYPE_LINES );
         vgic_unlock(v);
         return 1;
     case GICD_IIDR:
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index ff99e50..2785c10 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -668,7 +668,7 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
         if ( dabt.size != DABT_WORD ) goto bad_width;
         /* No secure world support for guests. */
         *r = (((v->domain->max_vcpus << 5) & GICD_TYPE_CPUS ) |
-              ((v->domain->arch.vgic.nr_lines / 32) & GICD_TYPE_LINES));
+              ((v->domain->arch.vgic.nr_spis / 32) & GICD_TYPE_LINES));
         return 1;
     case GICD_STATUSR:
         /*
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 97061ce..75cb7ff 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -66,13 +66,10 @@ int domain_vgic_init(struct domain *d)
 
     d->arch.vgic.ctlr = 0;
 
-    /* Currently nr_lines in vgic and gic doesn't have the same meanings
-     * Here nr_lines = number of SPIs
-     */
     if ( is_hardware_domain(d) )
-        d->arch.vgic.nr_lines = gic_number_lines() - 32;
+        d->arch.vgic.nr_spis = gic_number_lines() - 32;
     else
-        d->arch.vgic.nr_lines = 0; /* We don't need SPIs for the guest */
+        d->arch.vgic.nr_spis = 0; /* We don't need SPIs for the guest */
 
     switch ( gic_hw_version() )
     {
@@ -96,11 +93,11 @@ int domain_vgic_init(struct domain *d)
         return -ENOMEM;
 
     d->arch.vgic.pending_irqs =
-        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
+        xzalloc_array(struct pending_irq, d->arch.vgic.nr_spis);
     if ( d->arch.vgic.pending_irqs == NULL )
         return -ENOMEM;
 
-    for (i=0; i<d->arch.vgic.nr_lines; i++)
+    for (i=0; i<d->arch.vgic.nr_spis; i++)
     {
         INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
         INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].lr_queue);
@@ -218,7 +215,7 @@ void arch_move_irqs(struct vcpu *v)
     struct vcpu *v_target;
     int i;
 
-    for ( i = 32; i < (d->arch.vgic.nr_lines + 32); i++ )
+    for ( i = 32; i < vgic_num_irqs(d); i++ )
     {
         v_target = vgic_get_target_vcpu(v, i);
         p = irq_to_pending(v_target, i);
@@ -344,7 +341,7 @@ int vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode, int
 struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
 {
     struct pending_irq *n;
-    /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
+    /* Pending irqs allocation strategy: the first vgic.nr_spis irqs
      * are used for SPIs; the rests are used for per cpu irqs */
     if ( irq < 32 )
         n = &v->arch.vgic.pending_irqs[irq];
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 787e93c..8b7dd85 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -89,7 +89,7 @@ struct arch_domain
          */
         spinlock_t lock;
         int ctlr;
-        int nr_lines; /* Number of SPIs */
+        int nr_spis; /* Number of SPIs */
         struct vgic_irq_rank *shared_irqs;
         /*
          * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 5160f17..74d5a4e 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -113,7 +113,7 @@ struct vgic_ops {
 };
 
 /* Number of ranks of interrupt registers for a domain */
-#define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_lines+31)/32)
+#define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_spis+31)/32)
 
 #define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
 #define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)
@@ -175,6 +175,8 @@ enum gic_sgi_mode;
  */
 #define REG_RANK_INDEX(b, n, s) ((((n) >> s) & ((b)-1)) % 32)
 
+#define vgic_num_irqs(d)        ((d)->arch.vgic.nr_spis + 32)
+
 extern int domain_vgic_init(struct domain *d);
 extern void domain_vgic_free(struct domain *d);
 extern int vcpu_vgic_init(struct vcpu *v);
-- 
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 Dec 12 14:44:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 14:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzRRE-0002vz-4B; Fri, 12 Dec 2014 14:43:24 +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 1XzRRC-0002v8-T5
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 14:43:22 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	9F/96-02699-A0FFA845; Fri, 12 Dec 2014 14:43:22 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418395401!14726252!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13997 invoked from network); 12 Dec 2014 14:43:21 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 14:43:21 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so2701132wiw.13
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 06:43: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:from:to:cc:subject:date:message-id;
	bh=z8UNxp/BP7Uj8WrkySvqT4h5Zo7bLWrmvY8Atd/5wXM=;
	b=IMDMT3JuTvL1m0q1RfRH2kUEirc8pPxF1zooz/C7IqdlapoItkt2VaDI3pNeUpc6ve
	YrDsS428AwjFUmlyq0zW/d4uS8d4ctcS4oJXQNMwSI2gFxbwmGm6DEQe+SsAB+zZc8C/
	uWKgEhX3rZ30d2EpAKjy+yGva5SIDh4Bx++OnMf3CzxXutQqE99ARB9Fs+6ncEK4iQDD
	+vKNiibGJzFg6iaR0sIt/wrAhbpH60viv8E7MkIZbRIH4HPLvABtq28WWbJuIRvlwR63
	ZHsPPckahADTBcU265rEEoJHWnJFbY9cuXPKncKbdQQAaORSqjPg0IwYizLBapnn1m+Y
	qeaQ==
X-Gm-Message-State: ALoCoQmTl3LwTIHAy4vfJFu7HOogQwGXzd4mJNrJjQNYiP0DCRO6bTMRslKz8wGsG9OqGO7xlgc3
X-Received: by 10.194.79.199 with SMTP id l7mr28169445wjx.136.1418395400988;
	Fri, 12 Dec 2014 06:43:20 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id cq4sm2066234wjc.35.2014.12.12.06.43.19
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 12 Dec 2014 06:43:19 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 12 Dec 2014 14:43:08 +0000
Message-Id: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
Cc: ian.campbell@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com,
	parth.dixit@linaro.org, christoffer.dall@linaro.org
Subject: [Xen-devel] [PATCH for-4.6 0/4] Find automatically a PPI for the
	DOM0 even channel IRQ
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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,

This patch series replaces the per-platform hardcoded event channel interrupt
to a generic solution. It will make the port to a new platform more easier and
may avoid to introduce per-platform code with the new upcoming ACPI support.

This could be done by keeping track of vIRQ (emulated and assigned) used by
a domain.

Parth: I provided a branch on my personal repo [1]. It's based on the latest
upstream branch. You can use vgic_allocate_virq(d, 0) to allocate the event
channel PPI.

Sincerely yours,

[1] git://xenbits.xen.org/people/julieng/xen-unstable.git branch find-evtchn

Julien Grall (4):
  xen/arm: vgic: Rename nr_lines into nr_spis
  xen/arm: vgic: Keep track of vIRQ used by a domain
  xen/arm: vgic: notice if the vIRQ is not allocated when the guest
    enable it
  xen/arm: Find automatically a PPI for the DOM0 event channel interrupt

 xen/arch/arm/domain.c                | 13 +++--
 xen/arch/arm/domain_build.c          | 16 ++++++
 xen/arch/arm/gic-v2.c                |  2 -
 xen/arch/arm/gic-v3.c                |  2 +-
 xen/arch/arm/platform.c              |  7 ---
 xen/arch/arm/platforms/xgene-storm.c |  5 +-
 xen/arch/arm/vgic-v2.c               |  2 +-
 xen/arch/arm/vgic-v3.c               |  2 +-
 xen/arch/arm/vgic.c                  | 95 ++++++++++++++++++++++++++++++++----
 xen/arch/arm/vtimer.c                | 15 ++++++
 xen/include/asm-arm/domain.h         |  3 +-
 xen/include/asm-arm/platform.h       |  4 --
 xen/include/asm-arm/vgic.h           | 17 ++++++-
 13 files changed, 152 insertions(+), 31 deletions(-)

-- 
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 Dec 12 14:44:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 14:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzRRH-0002wc-L1; Fri, 12 Dec 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 <julien.grall@linaro.org>) id 1XzRRG-0002wK-9H
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 14:43:26 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	F2/35-17958-D0FFA845; Fri, 12 Dec 2014 14:43:25 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418395404!12900431!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16195 invoked from network); 12 Dec 2014 14:43:24 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 14:43:24 -0000
Received: by mail-wg0-f51.google.com with SMTP id x12so9152450wgg.24
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 06:43: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=wHPVoJQgp0YGfRTqZj7/pDEy0gbhADWCpccgBgsIbaQ=;
	b=dPiQ70zfIF9abClwy2ZzPf0ttvXu873jroZpEsBZKdnnFVVqF8zamxaz0pkAHIYa5h
	6GXuY/O/D5UxrEOtnfC7sizuFUgcyAj17VYGvg9GGDZDYTo38u6dC8rPOcS6IuIyfveN
	4IJOolxbkpwaFvAdDp/kyWgBhe1Au3ZtPRBe/QaVkdBZQeMEJnfttUZck8I+fpi/gUXR
	4gI5uyNaS53Nn221XOG2ekbQOySjhTxnRp0UviewchEoFriUGIr0CN1ku2pmxegxME+f
	fQv8eUej3tUniN7Xn0YFie6IiMwh2JeT/Fx2C8BtPBDR8kZalinWzQskNi+N56RWX7K2
	SxWg==
X-Gm-Message-State: ALoCoQkH5e73habpz/Etyfo5s9I8IFq8Di7ybyT/vXEmX1gmBfv5R9smbTxqNnWPIJRHyFcEleIm
X-Received: by 10.194.174.40 with SMTP id bp8mr27403693wjc.104.1418395404370; 
	Fri, 12 Dec 2014 06:43:24 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id cq4sm2066234wjc.35.2014.12.12.06.43.22
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 12 Dec 2014 06:43:23 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 12 Dec 2014 14:43:10 +0000
Message-Id: <1418395392-30460-3-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
Cc: ian.campbell@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com,
	parth.dixit@linaro.org, christoffer.dall@linaro.org
Subject: [Xen-devel] [PATCH for-4.6 2/4] xen/arm: vgic: Keep track of vIRQ
	used by a domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 it's easy to know which hardware IRQ is assigned to a domain, there
is no way to know which IRQ is emulated by Xen for a specific domain.

Introduce a bitmap to keep track of every vIRQ used by a domain. This
will be used later to find free vIRQ for interrupt device assignment and
emulated interrupt.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/domain_build.c          |  6 +++
 xen/arch/arm/platforms/xgene-storm.c |  4 ++
 xen/arch/arm/vgic.c                  | 76 ++++++++++++++++++++++++++++++++++++
 xen/arch/arm/vtimer.c                | 15 +++++++
 xen/include/asm-arm/domain.h         |  1 +
 xen/include/asm-arm/vgic.h           | 13 ++++++
 6 files changed, 115 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index de180d8..c238c8f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -968,6 +968,12 @@ static int map_device(struct domain *d, struct dt_device_node *dev)
         irq = res;
 
         DPRINT("irq %u = %u\n", i, irq);
+        /*
+         * Checking the return of vgic_reserve_virq is not
+         * necessary. It should not fail except when we try to map
+         * twice the IRQ. This can happen if the IRQ is shared
+         */
+        vgic_reserve_virq(d, irq);
         res = route_irq_to_guest(d, irq, dt_node_name(dev));
         if ( res )
         {
diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 0b3492d..416d42c 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -71,6 +71,10 @@ static int map_one_spi(struct domain *d, const char *what,
 
     printk("Additional IRQ %u (%s)\n", irq, what);
 
+    if ( !vgic_reserve_virq(d, irq) )
+        printk("Failed to reserve the vIRQ %u on dom%d\n",
+               irq, d->domain_id);
+
     ret = route_irq_to_guest(d, irq, what);
     if ( ret )
         printk("Failed to route %s to dom%d\n", what, d->domain_id);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 75cb7ff..dbfc259 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -87,6 +87,8 @@ int domain_vgic_init(struct domain *d)
         return -ENODEV;
     }
 
+    spin_lock_init(&d->arch.vgic.lock);
+
     d->arch.vgic.shared_irqs =
         xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
     if ( d->arch.vgic.shared_irqs == NULL )
@@ -107,6 +109,15 @@ int domain_vgic_init(struct domain *d)
 
     d->arch.vgic.handler->domain_init(d);
 
+    d->arch.vgic.allocated_irqs =
+        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irqs(d)));
+    if ( !d->arch.vgic.allocated_irqs )
+        return -ENOMEM;
+
+    /* vIRQ0-15 (SGIs) are reserved */
+    for (i = 0; i <= 15; i++)
+        set_bit(i, d->arch.vgic.allocated_irqs);
+
     return 0;
 }
 
@@ -119,6 +130,7 @@ void domain_vgic_free(struct domain *d)
 {
     xfree(d->arch.vgic.shared_irqs);
     xfree(d->arch.vgic.pending_irqs);
+    xfree(d->arch.vgic.allocated_irqs);
 }
 
 int vcpu_vgic_init(struct vcpu *v)
@@ -441,6 +453,70 @@ int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
     return v->domain->arch.vgic.handler->emulate_sysreg(regs, hsr);
 }
 
+bool_t vgic_reserve_virq(struct domain *d, unsigned int virq)
+{
+    bool_t reserved;
+
+    if ( virq >= vgic_num_irqs(d) )
+        return 0;
+
+    spin_lock(&d->arch.vgic.lock);
+    reserved = !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
+    spin_unlock(&d->arch.vgic.lock);
+
+    return reserved;
+}
+
+int vgic_allocate_virq(struct domain *d, bool_t spi)
+{
+    int ret = -1;
+    unsigned int virq;
+
+    spin_lock(&d->arch.vgic.lock);
+    if ( !spi )
+    {
+        virq = find_first_zero_bit(d->arch.vgic.allocated_irqs, 32);
+        if ( virq >= 32 )
+            goto unlock;
+    }
+    else
+    {
+        virq = find_next_zero_bit(d->arch.vgic.allocated_irqs,
+                                  32, vgic_num_irqs(d));
+        if ( virq >= vgic_num_irqs(d) )
+            goto unlock;
+    }
+
+    set_bit(virq, d->arch.vgic.allocated_irqs);
+    ret = virq;
+
+unlock:
+    spin_unlock(&d->arch.vgic.lock);
+
+    return ret;
+}
+
+void vgic_free_virq(struct domain *d, unsigned int virq)
+{
+    unsigned int spi;
+
+    if ( is_hardware_domain(d) )
+        return;
+
+    if ( virq < 32 && virq >= vgic_num_irqs(d) )
+        return;
+
+    spi = virq - 32;
+
+    /* Taking the vGIC domain lock is not necessary. We don't care if
+     * the bit is cleared a bit later. What only matters is bit to 1.
+     *
+     * With this solution vgic_allocate may fail to find an vIRQ if the
+     * allocated_irqs is fully. But we don't care.
+     */
+    clear_bit(spi, d->arch.vgic.allocated_irqs);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 2e95ceb..de660bb 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -49,6 +49,21 @@ int domain_vtimer_init(struct domain *d)
 {
     d->arch.phys_timer_base.offset = NOW();
     d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0);
+
+    /* At this stage vgic_reserve_virq can't fail */
+    if ( is_hardware_domain(d) )
+    {
+        BUG_ON(!vgic_reserve_virq(d, timer_get_irq(TIMER_PHYS_SECURE_PPI)));
+        BUG_ON(!vgic_reserve_virq(d, timer_get_irq(TIMER_PHYS_NONSECURE_PPI)));
+        BUG_ON(!vgic_reserve_virq(d, timer_get_irq(TIMER_VIRT_PPI)));
+    }
+    else
+    {
+        BUG_ON(!vgic_reserve_virq(d, GUEST_TIMER_PHYS_S_PPI));
+        BUG_ON(!vgic_reserve_virq(d, GUEST_TIMER_PHYS_NS_PPI));
+        BUG_ON(!vgic_reserve_virq(d, GUEST_TIMER_VIRT_PPI));
+    }
+
     return 0;
 }
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 8b7dd85..d302fc9 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -90,6 +90,7 @@ struct arch_domain
         spinlock_t lock;
         int ctlr;
         int nr_spis; /* Number of SPIs */
+        unsigned long *allocated_irqs; /* bitmap of IRQs allocated */
         struct vgic_irq_rank *shared_irqs;
         /*
          * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 74d5a4e..9e167fa 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -199,6 +199,19 @@ extern int vgic_to_sgi(struct vcpu *v, register_t sgir,
                        enum gic_sgi_mode irqmode, int virq,
                        unsigned long vcpu_mask);
 extern void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq);
+
+/* Reserve a specific guest vIRQ */
+extern bool_t vgic_reserve_virq(struct domain *d, unsigned int virq);
+
+/*
+ * Allocate a guest VIRQ
+ *  - spi == 0 => allocate a PPI. It will be the same on every vCPU
+ *  - spi == 0 => allocate an SGI
+ */
+extern int vgic_allocate_virq(struct domain *d, bool_t spi);
+
+extern void vgic_free_virq(struct domain *d, unsigned int irq);
+
 #endif /* __ASM_ARM_VGIC_H__ */
 
 /*
-- 
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 Dec 12 14:44:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 14:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzRRJ-0002x4-Bu; Fri, 12 Dec 2014 14:43:29 +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 1XzRRH-0002wY-Pc
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 14:43:28 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	8D/FF-05632-F0FFA845; Fri, 12 Dec 2014 14:43:27 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418395403!12978580!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28850 invoked from network); 12 Dec 2014 14:43:23 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com)
	(209.85.212.176)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 14:43:23 -0000
Received: by mail-wi0-f176.google.com with SMTP id ex7so2699781wid.9
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 06:43: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:in-reply-to
	:references;
	bh=2ztTRX34455TnEdsLeo2kkaZQr2R358MbzJ7UpDsfPs=;
	b=DMLJAB7S0dK4mauSNgJsF8eBb6m4+Wh38CabhsQSAX+xbSzgIzqjGPylmVxFMnAW89
	nL6XvbRk4N08giBYGFgiPMQo2++yLUiZsVZfgcW+uvv/kmHTQEj9WDPl2SK+HT9GmlZA
	Wd3rleOFTXvkhD3/77dkvRHZuGeBszEXF0FD+3q1uMYbYYwwrbNNK+kDdM9mwuMkkBjY
	vaZ5m0pD0mDFgIhkd5fTgsHsZtp9uP4p/lSMNev+ARpofh+mG4yM+fGIacBs5elJUb9E
	0RWGVKQXFfZW356xo3Ns6K2Sy5MhWOZbgOFNqEaFotr9jw2QIcgE5hzLbjOY1vPjl0VH
	fq8w==
X-Gm-Message-State: ALoCoQlsNxhyr32FWJpWljJtzdIDQ2jkwUuHEPMkZUI+gVv/5uaL6aQdHBGf0J/KJ0p875zBMyhm
X-Received: by 10.180.160.144 with SMTP id xk16mr8594928wib.12.1418395402718; 
	Fri, 12 Dec 2014 06:43:22 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id cq4sm2066234wjc.35.2014.12.12.06.43.21
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 12 Dec 2014 06:43:21 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 12 Dec 2014 14:43:09 +0000
Message-Id: <1418395392-30460-2-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
Cc: ian.campbell@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com,
	parth.dixit@linaro.org, christoffer.dall@linaro.org
Subject: [Xen-devel] [PATCH for-4.6 1/4] xen/arm: vgic: Rename nr_lines into
	nr_spis
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The field nr_lines in the arch_domain vgic structure contains the number of
SPIs for the emulated GIC. Using the nr_lines make confusion with the GIC
code, where it means the number of IRQs. This can lead to coding error.

Also introduce vgic_nr_lines to get the number of IRQ handled by the emulated
GIC.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

---
    It was part of the platform device passthrough series: https://patches.linaro.org/34661/

    Stefano: I've kept your ack from the previous version. Let me know
    if there is any issue.

    Changes in v3:
        - Add acked-by from Stefano.
        - Update the patch to also modify GICv3 code which has been
        pushed recently

    Changes in v2:
        - Patch added.
---
 xen/arch/arm/gic-v2.c        |  2 --
 xen/arch/arm/gic-v3.c        |  2 +-
 xen/arch/arm/vgic-v2.c       |  2 +-
 xen/arch/arm/vgic-v3.c       |  2 +-
 xen/arch/arm/vgic.c          | 15 ++++++---------
 xen/include/asm-arm/domain.h |  2 +-
 xen/include/asm-arm/vgic.h   |  4 +++-
 7 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..31fb81a 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -432,8 +432,6 @@ static int gicv2v_setup(struct domain *d)
         d->arch.vgic.cbase = GUEST_GICC_BASE;
     }
 
-    d->arch.vgic.nr_lines = 0;
-
     /*
      * Map the gic virtual cpu interface in the gic cpu interface
      * region of the guest.
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 076aa62..ec48fc1 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -922,7 +922,7 @@ static int gicv_v3_init(struct domain *d)
         d->arch.vgic.rbase_size[0] = GUEST_GICV3_GICR0_SIZE;
     }
 
-    d->arch.vgic.nr_lines = 0;
+    d->arch.vgic.nr_spis = 0;
 
     return 0;
 }
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 1369f78..039e19a 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -54,7 +54,7 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
         /* No secure world support for guests. */
         vgic_lock(v);
         *r = ( (v->domain->max_vcpus << 5) & GICD_TYPE_CPUS )
-            |( ((v->domain->arch.vgic.nr_lines / 32)) & GICD_TYPE_LINES );
+            |( ((v->domain->arch.vgic.nr_spis / 32)) & GICD_TYPE_LINES );
         vgic_unlock(v);
         return 1;
     case GICD_IIDR:
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index ff99e50..2785c10 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -668,7 +668,7 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
         if ( dabt.size != DABT_WORD ) goto bad_width;
         /* No secure world support for guests. */
         *r = (((v->domain->max_vcpus << 5) & GICD_TYPE_CPUS ) |
-              ((v->domain->arch.vgic.nr_lines / 32) & GICD_TYPE_LINES));
+              ((v->domain->arch.vgic.nr_spis / 32) & GICD_TYPE_LINES));
         return 1;
     case GICD_STATUSR:
         /*
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 97061ce..75cb7ff 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -66,13 +66,10 @@ int domain_vgic_init(struct domain *d)
 
     d->arch.vgic.ctlr = 0;
 
-    /* Currently nr_lines in vgic and gic doesn't have the same meanings
-     * Here nr_lines = number of SPIs
-     */
     if ( is_hardware_domain(d) )
-        d->arch.vgic.nr_lines = gic_number_lines() - 32;
+        d->arch.vgic.nr_spis = gic_number_lines() - 32;
     else
-        d->arch.vgic.nr_lines = 0; /* We don't need SPIs for the guest */
+        d->arch.vgic.nr_spis = 0; /* We don't need SPIs for the guest */
 
     switch ( gic_hw_version() )
     {
@@ -96,11 +93,11 @@ int domain_vgic_init(struct domain *d)
         return -ENOMEM;
 
     d->arch.vgic.pending_irqs =
-        xzalloc_array(struct pending_irq, d->arch.vgic.nr_lines);
+        xzalloc_array(struct pending_irq, d->arch.vgic.nr_spis);
     if ( d->arch.vgic.pending_irqs == NULL )
         return -ENOMEM;
 
-    for (i=0; i<d->arch.vgic.nr_lines; i++)
+    for (i=0; i<d->arch.vgic.nr_spis; i++)
     {
         INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].inflight);
         INIT_LIST_HEAD(&d->arch.vgic.pending_irqs[i].lr_queue);
@@ -218,7 +215,7 @@ void arch_move_irqs(struct vcpu *v)
     struct vcpu *v_target;
     int i;
 
-    for ( i = 32; i < (d->arch.vgic.nr_lines + 32); i++ )
+    for ( i = 32; i < vgic_num_irqs(d); i++ )
     {
         v_target = vgic_get_target_vcpu(v, i);
         p = irq_to_pending(v_target, i);
@@ -344,7 +341,7 @@ int vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode, int
 struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
 {
     struct pending_irq *n;
-    /* Pending irqs allocation strategy: the first vgic.nr_lines irqs
+    /* Pending irqs allocation strategy: the first vgic.nr_spis irqs
      * are used for SPIs; the rests are used for per cpu irqs */
     if ( irq < 32 )
         n = &v->arch.vgic.pending_irqs[irq];
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 787e93c..8b7dd85 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -89,7 +89,7 @@ struct arch_domain
          */
         spinlock_t lock;
         int ctlr;
-        int nr_lines; /* Number of SPIs */
+        int nr_spis; /* Number of SPIs */
         struct vgic_irq_rank *shared_irqs;
         /*
          * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 5160f17..74d5a4e 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -113,7 +113,7 @@ struct vgic_ops {
 };
 
 /* Number of ranks of interrupt registers for a domain */
-#define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_lines+31)/32)
+#define DOMAIN_NR_RANKS(d) (((d)->arch.vgic.nr_spis+31)/32)
 
 #define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
 #define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)
@@ -175,6 +175,8 @@ enum gic_sgi_mode;
  */
 #define REG_RANK_INDEX(b, n, s) ((((n) >> s) & ((b)-1)) % 32)
 
+#define vgic_num_irqs(d)        ((d)->arch.vgic.nr_spis + 32)
+
 extern int domain_vgic_init(struct domain *d);
 extern void domain_vgic_free(struct domain *d);
 extern int vcpu_vgic_init(struct vcpu *v);
-- 
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 Dec 12 14:44:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 14:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzRRJ-0002wv-0g; Fri, 12 Dec 2014 14:43:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XzRRH-0002wX-Mn
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 14:43:27 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	43/CC-29352-F0FFA845; Fri, 12 Dec 2014 14:43:27 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418395406!13073476!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30111 invoked from network); 12 Dec 2014 14:43:26 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 14:43:26 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so9325932wgh.31
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 06:43: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=2WNtq8sOexP4igg8xY4b28OLysZywOmxXLyMY7QGPZQ=;
	b=bpSKmyIjzrEVKG2RrnLdLcwg2biSwURpOAjTcbz82rV+ng5LWHB2VWM6B4+ZPeUNZg
	pH9KlV4O4S6gtVwNzUa1aahGpSQ9qpk2C6Wm8DGPko+b4zlLTUpw2k2jiosC5EdwmsY6
	at7E7ckqEIydAitcFD8KDwWzdiYFFpDkeP+FoCOgJqH7Wh59EopSJs88UaBh6Vd05XsK
	y7RRJWoYdf7+dGdVa9td3+OPQt6RiU87F2OlC50pkAGK9M+fy8/cmeOFHzX6XHYNhJWP
	0pVN2EnQY7n8waw+Qc85oCRrAYod2y4B7K22i9dmsNWI5qo9ZCKKYAayBWp6wmtkfAc2
	HVcA==
X-Gm-Message-State: ALoCoQna22aF8xJYB63DY/zmJ4PAjvieo4NBmncCWKX8xARzR25/L1EwKB1ilA7dwlSqyrckZQnY
X-Received: by 10.195.12.76 with SMTP id eo12mr28002630wjd.22.1418395406474;
	Fri, 12 Dec 2014 06:43:26 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id cq4sm2066234wjc.35.2014.12.12.06.43.24
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 12 Dec 2014 06:43:25 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 12 Dec 2014 14:43:11 +0000
Message-Id: <1418395392-30460-4-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
Cc: ian.campbell@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com,
	parth.dixit@linaro.org, christoffer.dall@linaro.org
Subject: [Xen-devel] [PATCH for-4.6 3/4] xen/arm: vgic: notice if the vIRQ
	is not allocated when the guest enable it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This help for guest interrupts debugging. If the vIRQ is not allocate,
this means that nothing is wired to it.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/vgic.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index dbfc259..719cb9f 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -282,6 +282,10 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
         if ( !list_empty(&p->inflight) && !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) )
             gic_raise_guest_irq(v_target, irq, p->priority);
         spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
+
+        if ( !test_bit(irq, d->arch.vgic.allocated_irqs) )
+            gdprintk(XENLOG_DEBUG, "vIRQ %u is not allocated\n", irq);
+
         if ( p->desc != NULL )
         {
             irq_set_affinity(p->desc, cpumask_of(v_target->processor));
-- 
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 Dec 12 14:44:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 14:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzRRJ-0002wv-0g; Fri, 12 Dec 2014 14:43:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1XzRRH-0002wX-Mn
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 14:43:27 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	43/CC-29352-F0FFA845; Fri, 12 Dec 2014 14:43:27 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418395406!13073476!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30111 invoked from network); 12 Dec 2014 14:43:26 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 14:43:26 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so9325932wgh.31
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 06:43: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=2WNtq8sOexP4igg8xY4b28OLysZywOmxXLyMY7QGPZQ=;
	b=bpSKmyIjzrEVKG2RrnLdLcwg2biSwURpOAjTcbz82rV+ng5LWHB2VWM6B4+ZPeUNZg
	pH9KlV4O4S6gtVwNzUa1aahGpSQ9qpk2C6Wm8DGPko+b4zlLTUpw2k2jiosC5EdwmsY6
	at7E7ckqEIydAitcFD8KDwWzdiYFFpDkeP+FoCOgJqH7Wh59EopSJs88UaBh6Vd05XsK
	y7RRJWoYdf7+dGdVa9td3+OPQt6RiU87F2OlC50pkAGK9M+fy8/cmeOFHzX6XHYNhJWP
	0pVN2EnQY7n8waw+Qc85oCRrAYod2y4B7K22i9dmsNWI5qo9ZCKKYAayBWp6wmtkfAc2
	HVcA==
X-Gm-Message-State: ALoCoQna22aF8xJYB63DY/zmJ4PAjvieo4NBmncCWKX8xARzR25/L1EwKB1ilA7dwlSqyrckZQnY
X-Received: by 10.195.12.76 with SMTP id eo12mr28002630wjd.22.1418395406474;
	Fri, 12 Dec 2014 06:43:26 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id cq4sm2066234wjc.35.2014.12.12.06.43.24
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 12 Dec 2014 06:43:25 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 12 Dec 2014 14:43:11 +0000
Message-Id: <1418395392-30460-4-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
Cc: ian.campbell@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com,
	parth.dixit@linaro.org, christoffer.dall@linaro.org
Subject: [Xen-devel] [PATCH for-4.6 3/4] xen/arm: vgic: notice if the vIRQ
	is not allocated when the guest enable it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This help for guest interrupts debugging. If the vIRQ is not allocate,
this means that nothing is wired to it.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/vgic.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index dbfc259..719cb9f 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -282,6 +282,10 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
         if ( !list_empty(&p->inflight) && !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) )
             gic_raise_guest_irq(v_target, irq, p->priority);
         spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
+
+        if ( !test_bit(irq, d->arch.vgic.allocated_irqs) )
+            gdprintk(XENLOG_DEBUG, "vIRQ %u is not allocated\n", irq);
+
         if ( p->desc != NULL )
         {
             irq_set_affinity(p->desc, cpumask_of(v_target->processor));
-- 
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 Dec 12 14:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 14: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 1XzRRL-0002xn-Ny; Fri, 12 Dec 2014 14:43:31 +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 1XzRRJ-0002x5-Qq
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 14:43:30 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	DA/C9-27584-11FFA845; Fri, 12 Dec 2014 14:43:29 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418395408!13073481!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32671 invoked from network); 12 Dec 2014 14:43:28 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 14:43:28 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so9362831wgg.15
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 06:43: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=tjAZqaVwmhHpGzaNIIwESXUS53370sHpU6E/6kBSAMo=;
	b=j40DLRLBkxxbNRUNXbDIdgRqdOQiKPH8Fq+LwUOBxNs+eLqFAKssZNaCqSrzrksn7A
	24VvixZFgx/6RaxljshkamhJtjSQQZIY8kWIFEkrlmtgixc8m247L5cvn3re43V452Lm
	5d3kJY2Fb4bC34xsKM28+vNmDEBnFk3If+Mf1FqmfN43LQZVgyC7FdGAAVx1yamJ4dsU
	UgxbOfPbFaioElBudYKJSV/JIGthOHagttu9h8fXEtBzwJUKkd685VX+RgXXOilH9+CL
	D8X02ccudM7XNJPWKV0OT3C+wStuRhtRIxsNWXm2vf+BSUbpoLp9H3EZUjCWUUuy2orl
	D6Pg==
X-Gm-Message-State: ALoCoQmLiANnuwdmsQjMcV9m3IPqpJ91KL8SjVe0NDbw0Crw/V2OXP1GlZizG/exeGjlrkgCF+Xm
X-Received: by 10.194.92.148 with SMTP id cm20mr28379873wjb.88.1418395408394; 
	Fri, 12 Dec 2014 06:43:28 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id cq4sm2066234wjc.35.2014.12.12.06.43.26
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 12 Dec 2014 06:43:27 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 12 Dec 2014 14:43:12 +0000
Message-Id: <1418395392-30460-5-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
Cc: ian.campbell@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com,
	parth.dixit@linaro.org, christoffer.dall@linaro.org
Subject: [Xen-devel] [PATCH for-4.6 4/4] xen/arm: Find automatically a PPI
	for the DOM0 event channel interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 the new vgic interface to know which virtual PPI is free and use it
for the event channel code.

At the DOM0 creation time, Xen still don't know which vIRQ will be free.
All the vIRQ will be reserved when we parse the device tree. So allocate
when the hypervisor node is created.

It's safe to defer the allocation because no vIRQ can be injected as
long as the vCPU is not online.

Also correct the check in arch_domain_create to use is_hardware_domain.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/domain.c                | 13 ++++++++++---
 xen/arch/arm/domain_build.c          | 10 ++++++++++
 xen/arch/arm/platform.c              |  7 -------
 xen/arch/arm/platforms/xgene-storm.c |  1 -
 xen/include/asm-arm/platform.h       |  4 ----
 5 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7221bc8..7d14377 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -543,10 +543,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = domain_vtimer_init(d)) != 0 )
         goto fail;
 
-    if ( d->domain_id )
+    /*
+     * The hardware domain will get a PPI later in
+     * arch/arm/domain_build.c  depending on the
+     * interrupt map of the hardware.
+     */
+    if ( !is_hardware_domain(d) )
+    {
         d->arch.evtchn_irq = GUEST_EVTCHN_PPI;
-    else
-        d->arch.evtchn_irq = platform_dom0_evtchn_ppi();
+        /* At this stage vgic_reserve_virq should never fail */
+        BUG_ON(vgic_reserve_virq(d, GUEST_EVTCHN_PPI));
+    }
 
     /*
      * Virtual UART is only used by linux early printk and decompress code.
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c238c8f..8dedc60 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -625,6 +625,16 @@ static int make_hypervisor_node(struct domain *d,
         return res;
 
     /*
+     * The allocation of the event channel IRQ has been deferred until
+     * now. At this time, all PPIs use by DOM0 has been registered
+     */
+    res = vgic_allocate_virq(d, 0);
+    if ( res < 0 )
+        return -FDT_ERR_XEN(ENOSPC);
+
+    d->arch.evtchn_irq = res;
+
+    /*
      * interrupts is evtchn upcall:
      *  - Active-low level-sensitive
      *  - All cpus
diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index cb4cda8..d016797 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -160,13 +160,6 @@ bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
     return dt_match_node(blacklist, node);
 }
 
-unsigned int platform_dom0_evtchn_ppi(void)
-{
-    if ( platform && platform->dom0_evtchn_ppi )
-        return platform->dom0_evtchn_ppi;
-    return GUEST_EVTCHN_PPI;
-}
-
 void platform_dom0_gnttab(paddr_t *start, paddr_t *size)
 {
     if ( platform && platform->dom0_gnttab_size )
diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 416d42c..b0808b8 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -232,7 +232,6 @@ PLATFORM_START(xgene_storm, "APM X-GENE STORM")
     .quirks = xgene_storm_quirks,
     .specific_mapping = xgene_storm_specific_mapping,
 
-    .dom0_evtchn_ppi = 24,
     .dom0_gnttab_start = 0x1f800000,
     .dom0_gnttab_size = 0x20000,
 PLATFORM_END
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index eefaca6..4eba37b 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -38,10 +38,6 @@ struct platform_desc {
      */
     const struct dt_device_match *blacklist_dev;
     /*
-     * The IRQ (PPI) to use to inject event channels to dom0.
-     */
-    unsigned int dom0_evtchn_ppi;
-    /*
      * The location of a region of physical address space which dom0
      * can use for grant table mappings. If size is zero defaults to
      * 0xb0000000-0xb0020000.
-- 
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 Dec 12 14:44:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 14: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 1XzRRL-0002xn-Ny; Fri, 12 Dec 2014 14:43:31 +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 1XzRRJ-0002x5-Qq
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 14:43:30 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	DA/C9-27584-11FFA845; Fri, 12 Dec 2014 14:43:29 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418395408!13073481!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32671 invoked from network); 12 Dec 2014 14:43:28 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 14:43:28 -0000
Received: by mail-wg0-f42.google.com with SMTP id z12so9362831wgg.15
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 06:43: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=tjAZqaVwmhHpGzaNIIwESXUS53370sHpU6E/6kBSAMo=;
	b=j40DLRLBkxxbNRUNXbDIdgRqdOQiKPH8Fq+LwUOBxNs+eLqFAKssZNaCqSrzrksn7A
	24VvixZFgx/6RaxljshkamhJtjSQQZIY8kWIFEkrlmtgixc8m247L5cvn3re43V452Lm
	5d3kJY2Fb4bC34xsKM28+vNmDEBnFk3If+Mf1FqmfN43LQZVgyC7FdGAAVx1yamJ4dsU
	UgxbOfPbFaioElBudYKJSV/JIGthOHagttu9h8fXEtBzwJUKkd685VX+RgXXOilH9+CL
	D8X02ccudM7XNJPWKV0OT3C+wStuRhtRIxsNWXm2vf+BSUbpoLp9H3EZUjCWUUuy2orl
	D6Pg==
X-Gm-Message-State: ALoCoQmLiANnuwdmsQjMcV9m3IPqpJ91KL8SjVe0NDbw0Crw/V2OXP1GlZizG/exeGjlrkgCF+Xm
X-Received: by 10.194.92.148 with SMTP id cm20mr28379873wjb.88.1418395408394; 
	Fri, 12 Dec 2014 06:43:28 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id cq4sm2066234wjc.35.2014.12.12.06.43.26
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 12 Dec 2014 06:43:27 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Fri, 12 Dec 2014 14:43:12 +0000
Message-Id: <1418395392-30460-5-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
Cc: ian.campbell@citrix.com, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com,
	parth.dixit@linaro.org, christoffer.dall@linaro.org
Subject: [Xen-devel] [PATCH for-4.6 4/4] xen/arm: Find automatically a PPI
	for the DOM0 event channel interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 the new vgic interface to know which virtual PPI is free and use it
for the event channel code.

At the DOM0 creation time, Xen still don't know which vIRQ will be free.
All the vIRQ will be reserved when we parse the device tree. So allocate
when the hypervisor node is created.

It's safe to defer the allocation because no vIRQ can be injected as
long as the vCPU is not online.

Also correct the check in arch_domain_create to use is_hardware_domain.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/domain.c                | 13 ++++++++++---
 xen/arch/arm/domain_build.c          | 10 ++++++++++
 xen/arch/arm/platform.c              |  7 -------
 xen/arch/arm/platforms/xgene-storm.c |  1 -
 xen/include/asm-arm/platform.h       |  4 ----
 5 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7221bc8..7d14377 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -543,10 +543,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = domain_vtimer_init(d)) != 0 )
         goto fail;
 
-    if ( d->domain_id )
+    /*
+     * The hardware domain will get a PPI later in
+     * arch/arm/domain_build.c  depending on the
+     * interrupt map of the hardware.
+     */
+    if ( !is_hardware_domain(d) )
+    {
         d->arch.evtchn_irq = GUEST_EVTCHN_PPI;
-    else
-        d->arch.evtchn_irq = platform_dom0_evtchn_ppi();
+        /* At this stage vgic_reserve_virq should never fail */
+        BUG_ON(vgic_reserve_virq(d, GUEST_EVTCHN_PPI));
+    }
 
     /*
      * Virtual UART is only used by linux early printk and decompress code.
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c238c8f..8dedc60 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -625,6 +625,16 @@ static int make_hypervisor_node(struct domain *d,
         return res;
 
     /*
+     * The allocation of the event channel IRQ has been deferred until
+     * now. At this time, all PPIs use by DOM0 has been registered
+     */
+    res = vgic_allocate_virq(d, 0);
+    if ( res < 0 )
+        return -FDT_ERR_XEN(ENOSPC);
+
+    d->arch.evtchn_irq = res;
+
+    /*
      * interrupts is evtchn upcall:
      *  - Active-low level-sensitive
      *  - All cpus
diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index cb4cda8..d016797 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -160,13 +160,6 @@ bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
     return dt_match_node(blacklist, node);
 }
 
-unsigned int platform_dom0_evtchn_ppi(void)
-{
-    if ( platform && platform->dom0_evtchn_ppi )
-        return platform->dom0_evtchn_ppi;
-    return GUEST_EVTCHN_PPI;
-}
-
 void platform_dom0_gnttab(paddr_t *start, paddr_t *size)
 {
     if ( platform && platform->dom0_gnttab_size )
diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 416d42c..b0808b8 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -232,7 +232,6 @@ PLATFORM_START(xgene_storm, "APM X-GENE STORM")
     .quirks = xgene_storm_quirks,
     .specific_mapping = xgene_storm_specific_mapping,
 
-    .dom0_evtchn_ppi = 24,
     .dom0_gnttab_start = 0x1f800000,
     .dom0_gnttab_size = 0x20000,
 PLATFORM_END
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index eefaca6..4eba37b 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -38,10 +38,6 @@ struct platform_desc {
      */
     const struct dt_device_match *blacklist_dev;
     /*
-     * The IRQ (PPI) to use to inject event channels to dom0.
-     */
-    unsigned int dom0_evtchn_ppi;
-    /*
      * The location of a region of physical address space which dom0
      * can use for grant table mappings. If size is zero defaults to
      * 0xb0000000-0xb0020000.
-- 
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 Dec 12 15:03:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 15: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 1XzRjs-0004NA-QZ; Fri, 12 Dec 2014 15:02: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 1XzRjr-0004N5-Io
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 15:02:39 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7A/CB-09842-E830B845; Fri, 12 Dec 2014 15:02:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418396556!14884614!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25636 invoked from network); 12 Dec 2014 15:02: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;
	12 Dec 2014 15:02:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203900314"
Message-ID: <548B0389.5040107@citrix.com>
Date: Fri, 12 Dec 2014 15:02: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: Chao Peng <chao.p.peng@linux.intel.com>, <xen-devel@lists.xen.org>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
In-Reply-To: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
X-DLP: MIA1
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	will.auld@intel.com, JBeulich@suse.com, wei.liu2@citrix.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/12/14 12:27, Chao Peng wrote:
> Hi all, we plan to bring Intel CAT into XEN. This is the initial
> design for that. Comments/suggestions are welcome.
>
> Background
> ==========
> Traditionally, all Virtual Machines ("VMs") share the same set of system
> cache resources. There is no hardware support to control allocation or
> availability of cache resources to individual VMs. The lack of such
> partition mechanism for cache resource makes the cache utilization for
> different types of VMs inefficient. While on the other side, more and
> more cache resources become available on modern server platforms.
>
> With the introduction of Intel Cache Allocation Technology ("CAT"), now
> Virtualization Machine Monitor ("VMM") has the ability to partition the
> cache allocation per VM, based on the priority of VM.
>
>
> CAT Introduction
> ================
> Generally speaking, CAT introduces a mechanism for software to enable
> cache allocation based on application priority or Class of Service
> ("COS"). Cache allocation for the respective applications is then
> restricted based on the COS with which they are associated. Each COS can
> be configured using capacity bitmasks ("CBM") which represent cache
> capacity and indicate the degree of overlap and isolation between
> classes. For each logical processor there is a register
> exposed(IA32_PQR_ASSOC MSR) to allow the OS/VMM to specify a COS when an
> application, thread or VM is scheduled. Cache allocation for the
> indicated application/thread/VM is then controlled automatically by the
> hardware based on the COS and the CBM associated with that class.
> Hardware initializes COS of each logical processor to 0 and the
> corresponding CBM is set to all-ones, means all the system cache
> resource can be used for each application.
>
> For more information please refer to Section 17.15 in the Intel SDM [1].
>
>
> Design Overview
> ===============
> - Domain COS/CBM association
> When enforcing cache allocation for VMs, the minimum granularity is
> defined as the domain. All Virtual CPUs ("VCPUs") of a domain have the
> same COS, and therefore, correspond to the same CBM. COS is used only in
> hypervisor and is transparent to tool stack/user. System administrator
> can specify the initial CBM for each domain or change it at runtime using 
> tool stack. Hypervisor then choses a free COS to associate it with that
> CBM or find a existed COS which has the same CBM.
>
> - VCPU Schedule
> When VCPU is scheduled on the physical CPU ("PCPU"), its COS value is
> then written to MSR (IA32_PQR_ASSOC) of PCPU to notify hardware to use 
> the new COS. The cache allocation is then enforced by hardware.
>
> - Multi-Socket
> In multi-socket environment, each VCPU may be scheduled on different
> sockets. The hardware CAT ability(such as maximum supported COS and length
> of CBM) maybe different among sockets. For such system, per-socket COS/CBM
> configuration of a domain is specified. Hypervisor then use this per-socket
> CBM information for VCPU schedule.
>
>
> Implementation Description
> ==========================
> In this design, one principal is that only implementing the cache
> enforcement mechanism in hypervisor but leaving the cache allocation
> policy to user space tool stack. In this way some complex governors then
> can be implemented in tool stack. 
>
> In summary, hypervisor changes include:
> 1) A new field "cat_info" in domain structure to indicate the CAT
>    information for each socket. It points to array of structure:
>    struct domain_socket_cat_info {
>        unsigned int cbm; /* CBM specified by toolstack  */
>        unsigned int cos; /* COS allocated by Hypervisor */
>    }
> 2) A new SYSCTL to expose the CAT information to tool stack:
>      * Whether CAT is enabled;
>      * Max COS supported;
>      * Length of CBM;
>      * Other needed information from host cpuid;
> 3) A new DOMCTL to allow tool stack to set/get CBM for a specified domain
>    for each socket.
> 4) Context switch: write COS of domain to MSR (IA32_PQR_ASSOC) of PCPU.
> 5) XSM policy to restrict the functions visibility to control domain only.
>
> Hypervisor interfaces:
> 1) Boot line param: "psr=cat" to enable the feature.
> 2) SYSCTL: XEN_SYSCTL_psr_cat_op
>      - XEN_SYSCTL_PSR_CAT_INFO_GET: Get system CAT information;
> 3) DOMCTL: XEN_DOMCTL_psr_cat_op
>      - XEN_DOMCTL_PSR_CAT_OP_CBM_SET: Set CBM value for a domain.
>      - XEN_DOMCTL_PSR_CAT_OP_CBM_GET: Get CBM value for a domain.
>
> xl interfaces:
> 1) psr-cat-show: Show system/runtime CAT information.
>      => XEN_SYSCTL_PSR_CAT_INFO_GET/XEN_DOMCTL_PSR_CAT_OP_CBM_GET
> 2) psr-cat-cbm-set [dom] [cbm] [socket]: Set CBM for a domain.
>      => XEN_DOMCTL_PSR_CAT_OP_CBM_SET
>
>
> Hardware Limitation & Performance Improvement
> =============================================
> As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
> switch. If the change is frequent then hardware may fail to strictly
> enforce the cache allocation basing on the specified COS. Due to this
> the strict placement characteristic would soften if VCPU is migrated on
> different PCPU frequently.
>
> For this reason, lazy updating for IA32_PQR_ASSOC will be done. Also this
> design allows CAT to run in two modes:
>
> 1) Non Affinitized mode: Each VM can be freely scheduled on any PCPU
> assigning its COS as it does.
>
> 2) Affinitized mode: Each PCPU is assigned a fixed COS and a VM can be
> scheduled on the PCPU only when it has a same COS. It's less flexible
> but can be an option for those who must have strict COS placement or in
> cases where problems have arisen because of the less strict nature of the
> non-affinitized mode.
>
> However, no additional code is designed to support these two modes. CAT is
> already running in non affinitized mode by default. If affinitized mode
> is desirable, then existed "xl vcpu-pin" command can be used to pin all
> the VCPUs which has the same COS to certain fixed PCPUs so that these 
> PCPUs always have the same COS set.
>
> [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>
> Chao

Fantastic - this is a very clear and well presented document.  In terms
of a plan of action, it looks fine.

>From my understanding, CAT is a largely orthogonal to CMT, but will
share some of the base PSR infrastructure in Xen?

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 15:03:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 15: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 1XzRjs-0004NA-QZ; Fri, 12 Dec 2014 15:02: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 1XzRjr-0004N5-Io
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 15:02:39 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7A/CB-09842-E830B845; Fri, 12 Dec 2014 15:02:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418396556!14884614!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25636 invoked from network); 12 Dec 2014 15:02: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;
	12 Dec 2014 15:02:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203900314"
Message-ID: <548B0389.5040107@citrix.com>
Date: Fri, 12 Dec 2014 15:02: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: Chao Peng <chao.p.peng@linux.intel.com>, <xen-devel@lists.xen.org>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
In-Reply-To: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
X-DLP: MIA1
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	will.auld@intel.com, JBeulich@suse.com, wei.liu2@citrix.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/12/14 12:27, Chao Peng wrote:
> Hi all, we plan to bring Intel CAT into XEN. This is the initial
> design for that. Comments/suggestions are welcome.
>
> Background
> ==========
> Traditionally, all Virtual Machines ("VMs") share the same set of system
> cache resources. There is no hardware support to control allocation or
> availability of cache resources to individual VMs. The lack of such
> partition mechanism for cache resource makes the cache utilization for
> different types of VMs inefficient. While on the other side, more and
> more cache resources become available on modern server platforms.
>
> With the introduction of Intel Cache Allocation Technology ("CAT"), now
> Virtualization Machine Monitor ("VMM") has the ability to partition the
> cache allocation per VM, based on the priority of VM.
>
>
> CAT Introduction
> ================
> Generally speaking, CAT introduces a mechanism for software to enable
> cache allocation based on application priority or Class of Service
> ("COS"). Cache allocation for the respective applications is then
> restricted based on the COS with which they are associated. Each COS can
> be configured using capacity bitmasks ("CBM") which represent cache
> capacity and indicate the degree of overlap and isolation between
> classes. For each logical processor there is a register
> exposed(IA32_PQR_ASSOC MSR) to allow the OS/VMM to specify a COS when an
> application, thread or VM is scheduled. Cache allocation for the
> indicated application/thread/VM is then controlled automatically by the
> hardware based on the COS and the CBM associated with that class.
> Hardware initializes COS of each logical processor to 0 and the
> corresponding CBM is set to all-ones, means all the system cache
> resource can be used for each application.
>
> For more information please refer to Section 17.15 in the Intel SDM [1].
>
>
> Design Overview
> ===============
> - Domain COS/CBM association
> When enforcing cache allocation for VMs, the minimum granularity is
> defined as the domain. All Virtual CPUs ("VCPUs") of a domain have the
> same COS, and therefore, correspond to the same CBM. COS is used only in
> hypervisor and is transparent to tool stack/user. System administrator
> can specify the initial CBM for each domain or change it at runtime using 
> tool stack. Hypervisor then choses a free COS to associate it with that
> CBM or find a existed COS which has the same CBM.
>
> - VCPU Schedule
> When VCPU is scheduled on the physical CPU ("PCPU"), its COS value is
> then written to MSR (IA32_PQR_ASSOC) of PCPU to notify hardware to use 
> the new COS. The cache allocation is then enforced by hardware.
>
> - Multi-Socket
> In multi-socket environment, each VCPU may be scheduled on different
> sockets. The hardware CAT ability(such as maximum supported COS and length
> of CBM) maybe different among sockets. For such system, per-socket COS/CBM
> configuration of a domain is specified. Hypervisor then use this per-socket
> CBM information for VCPU schedule.
>
>
> Implementation Description
> ==========================
> In this design, one principal is that only implementing the cache
> enforcement mechanism in hypervisor but leaving the cache allocation
> policy to user space tool stack. In this way some complex governors then
> can be implemented in tool stack. 
>
> In summary, hypervisor changes include:
> 1) A new field "cat_info" in domain structure to indicate the CAT
>    information for each socket. It points to array of structure:
>    struct domain_socket_cat_info {
>        unsigned int cbm; /* CBM specified by toolstack  */
>        unsigned int cos; /* COS allocated by Hypervisor */
>    }
> 2) A new SYSCTL to expose the CAT information to tool stack:
>      * Whether CAT is enabled;
>      * Max COS supported;
>      * Length of CBM;
>      * Other needed information from host cpuid;
> 3) A new DOMCTL to allow tool stack to set/get CBM for a specified domain
>    for each socket.
> 4) Context switch: write COS of domain to MSR (IA32_PQR_ASSOC) of PCPU.
> 5) XSM policy to restrict the functions visibility to control domain only.
>
> Hypervisor interfaces:
> 1) Boot line param: "psr=cat" to enable the feature.
> 2) SYSCTL: XEN_SYSCTL_psr_cat_op
>      - XEN_SYSCTL_PSR_CAT_INFO_GET: Get system CAT information;
> 3) DOMCTL: XEN_DOMCTL_psr_cat_op
>      - XEN_DOMCTL_PSR_CAT_OP_CBM_SET: Set CBM value for a domain.
>      - XEN_DOMCTL_PSR_CAT_OP_CBM_GET: Get CBM value for a domain.
>
> xl interfaces:
> 1) psr-cat-show: Show system/runtime CAT information.
>      => XEN_SYSCTL_PSR_CAT_INFO_GET/XEN_DOMCTL_PSR_CAT_OP_CBM_GET
> 2) psr-cat-cbm-set [dom] [cbm] [socket]: Set CBM for a domain.
>      => XEN_DOMCTL_PSR_CAT_OP_CBM_SET
>
>
> Hardware Limitation & Performance Improvement
> =============================================
> As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
> switch. If the change is frequent then hardware may fail to strictly
> enforce the cache allocation basing on the specified COS. Due to this
> the strict placement characteristic would soften if VCPU is migrated on
> different PCPU frequently.
>
> For this reason, lazy updating for IA32_PQR_ASSOC will be done. Also this
> design allows CAT to run in two modes:
>
> 1) Non Affinitized mode: Each VM can be freely scheduled on any PCPU
> assigning its COS as it does.
>
> 2) Affinitized mode: Each PCPU is assigned a fixed COS and a VM can be
> scheduled on the PCPU only when it has a same COS. It's less flexible
> but can be an option for those who must have strict COS placement or in
> cases where problems have arisen because of the less strict nature of the
> non-affinitized mode.
>
> However, no additional code is designed to support these two modes. CAT is
> already running in non affinitized mode by default. If affinitized mode
> is desirable, then existed "xl vcpu-pin" command can be used to pin all
> the VCPUs which has the same COS to certain fixed PCPUs so that these 
> PCPUs always have the same COS set.
>
> [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
>
> Chao

Fantastic - this is a very clear and well presented document.  In terms
of a plan of action, it looks fine.

>From my understanding, CAT is a largely orthogonal to CMT, but will
share some of the base PSR infrastructure in Xen?

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 15:06:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 15:06:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzRnK-0004UG-EQ; Fri, 12 Dec 2014 15:06:14 +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 1XzRnI-0004U8-PD
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 15:06:13 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	CA/0D-05632-3640B845; Fri, 12 Dec 2014 15:06:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418396771!10515410!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22622 invoked from network); 12 Dec 2014 15:06:11 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 15:06:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418396771; l=306;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=v3fG7Sfe8dnXqUQJ94/E/IxS7DI=;
	b=mYreB1jojfyzO89H+B//cKPxxOw0eWqhfxCcPJCGpdNRXr5pPJ/gaiV+XrXFP5R3Jku
	xoWNEWXlGgVLn1canVTFIAxgx14p4TI1/Z0Qmr2xcpkMQGfp80ZNaOEAXN4p42aDiihUy
	6ifM7SFdSct5MDgHW9DzlT5EB7jbK94T1R4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id i03626qBCF68HG0
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 12 Dec 2014 16:06:08 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 2D34450160; Fri, 12 Dec 2014 16:06:07 +0100 (CET)
Date: Fri, 12 Dec 2014 16:06:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>, konrad.wilk@oracle.com
Message-ID: <20141212150607.GA6115@aepfle.de>
References: <20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210175251.GA4441@aepfle.de>
	<1418379056.23309.45.camel@citrix.com>
	<20141212113751.GA5367@aepfle.de> <20141212121236.GA8380@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141212121236.GA8380@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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>
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, Olaf Hering wrote:

> This works:
> ExecStart=@XENSTORED@ --no-fork $XENSTORED_ARGS
> 
> This fails:
> ExecStart=$XENSTORED --no-fork $XENSTORED_ARGS

But this will likely work:
ExecStart=/usr/bin/env $XENSTORED --no-fork $XENSTORED_ARGS


Let me know how to proceed...

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 15:06:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 15:06:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzRnK-0004UG-EQ; Fri, 12 Dec 2014 15:06:14 +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 1XzRnI-0004U8-PD
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 15:06:13 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	CA/0D-05632-3640B845; Fri, 12 Dec 2014 15:06:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418396771!10515410!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22622 invoked from network); 12 Dec 2014 15:06:11 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 15:06:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418396771; l=306;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=v3fG7Sfe8dnXqUQJ94/E/IxS7DI=;
	b=mYreB1jojfyzO89H+B//cKPxxOw0eWqhfxCcPJCGpdNRXr5pPJ/gaiV+XrXFP5R3Jku
	xoWNEWXlGgVLn1canVTFIAxgx14p4TI1/Z0Qmr2xcpkMQGfp80ZNaOEAXN4p42aDiihUy
	6ifM7SFdSct5MDgHW9DzlT5EB7jbK94T1R4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id i03626qBCF68HG0
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 12 Dec 2014 16:06:08 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 2D34450160; Fri, 12 Dec 2014 16:06:07 +0100 (CET)
Date: Fri, 12 Dec 2014 16:06:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	M A Young <m.a.young@durham.ac.uk>, konrad.wilk@oracle.com
Message-ID: <20141212150607.GA6115@aepfle.de>
References: <20141208123736.GA3691@aepfle.de>
	<21639.7875.160312.349247@mariner.uk.xensource.com>
	<20141209162740.GA14288@aepfle.de>
	<21639.10108.666942.407514@mariner.uk.xensource.com>
	<20141210091534.GA24974@aepfle.de>
	<1418205728.19809.40.camel@citrix.com>
	<20141210175251.GA4441@aepfle.de>
	<1418379056.23309.45.camel@citrix.com>
	<20141212113751.GA5367@aepfle.de> <20141212121236.GA8380@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141212121236.GA8380@aepfle.de>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
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>
Subject: Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
 in systemd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, Olaf Hering wrote:

> This works:
> ExecStart=@XENSTORED@ --no-fork $XENSTORED_ARGS
> 
> This fails:
> ExecStart=$XENSTORED --no-fork $XENSTORED_ARGS

But this will likely work:
ExecStart=/usr/bin/env $XENSTORED --no-fork $XENSTORED_ARGS


Let me know how to proceed...

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 15:14:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 15:14:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzRur-0004yo-L8; Fri, 12 Dec 2014 15:14:01 +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 1XzRup-0004yj-OP
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 15:13:59 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	2B/BA-02696-7360B845; Fri, 12 Dec 2014 15:13:59 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418397238!9290589!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19299 invoked from network); 12 Dec 2014 15:13:58 -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; 12 Dec 2014 15:13:58 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:53865 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 1XzRuP-0000nU-FF; Fri, 12 Dec 2014 16:13:33 +0100
Date: Fri, 12 Dec 2014 16:13:52 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1999787702.20141212161352@eikelenboom.it>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [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

Hi Konrad,

This doesn't seem to be applied yet, nor does it seem to have a release-(N)ACK 
from you ?

--
Sander



Friday, November 28, 2014, 5:53:09 PM, you wrote:

> 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 Dec 12 15:14:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 15:14:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzRur-0004yo-L8; Fri, 12 Dec 2014 15:14:01 +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 1XzRup-0004yj-OP
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 15:13:59 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	2B/BA-02696-7360B845; Fri, 12 Dec 2014 15:13:59 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418397238!9290589!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19299 invoked from network); 12 Dec 2014 15:13:58 -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; 12 Dec 2014 15:13:58 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:53865 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 1XzRuP-0000nU-FF; Fri, 12 Dec 2014 16:13:33 +0100
Date: Fri, 12 Dec 2014 16:13:52 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1999787702.20141212161352@eikelenboom.it>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [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

Hi Konrad,

This doesn't seem to be applied yet, nor does it seem to have a release-(N)ACK 
from you ?

--
Sander



Friday, November 28, 2014, 5:53:09 PM, you wrote:

> 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 Dec 12 16:00:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzScw-0006UP-Kb; Fri, 12 Dec 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 1XzScv-0006UK-DC
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 15:59:33 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	C9/C0-05632-4E01B845; Fri, 12 Dec 2014 15:59:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418399970!12977292!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 24548 invoked from network); 12 Dec 2014 15:59:32 -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 Dec 2014 15:59:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203927013"
Message-ID: <1418399945.16425.13.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <freddy77@gmail.com>
Date: Fri, 12 Dec 2014 15:59:05 +0000
In-Reply-To: <CAHt6W4da7s=UcxucNnfYvWD8cMvVHSuQUiYWPTNu_V7X1ejq9w@mail.gmail.com>
References: <CAHt6W4da7s=UcxucNnfYvWD8cMvVHSuQUiYWPTNu_V7X1ejq9w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Porting 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>
Content-Type: text/plain; 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-12-08 at 15:47 +0000, Frediano Ziglio wrote:
> Hi,
>   while I was porting D01 platform
> (https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
> trying to describe the step I made and problems I encountered hoping
> it could useful to other people. The idea is to put such documentation
> in a wiki page or in the docs directory.
> 
> Let me know what do you think.

I've only skimmed the headings etc but I see no harm in posting it
somewhere publicly. I don't know if wiki or in tree docs would be
better. Maybe just post it on the list? At least then it will be in the
archives.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:00:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzScw-0006UP-Kb; Fri, 12 Dec 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 1XzScv-0006UK-DC
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 15:59:33 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	C9/C0-05632-4E01B845; Fri, 12 Dec 2014 15:59:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418399970!12977292!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 24548 invoked from network); 12 Dec 2014 15:59:32 -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 Dec 2014 15:59:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203927013"
Message-ID: <1418399945.16425.13.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <freddy77@gmail.com>
Date: Fri, 12 Dec 2014 15:59:05 +0000
In-Reply-To: <CAHt6W4da7s=UcxucNnfYvWD8cMvVHSuQUiYWPTNu_V7X1ejq9w@mail.gmail.com>
References: <CAHt6W4da7s=UcxucNnfYvWD8cMvVHSuQUiYWPTNu_V7X1ejq9w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Porting 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>
Content-Type: text/plain; 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-12-08 at 15:47 +0000, Frediano Ziglio wrote:
> Hi,
>   while I was porting D01 platform
> (https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
> trying to describe the step I made and problems I encountered hoping
> it could useful to other people. The idea is to put such documentation
> in a wiki page or in the docs directory.
> 
> Let me know what do you think.

I've only skimmed the headings etc but I see no harm in posting it
somewhere publicly. I don't know if wiki or in tree docs would be
better. Maybe just post it on the list? At least then it will be in the
archives.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:01:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzSeo-0006yY-8X; Fri, 12 Dec 2014 16:01: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 1XzSem-0006yQ-J4
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 16:01:28 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	6E/02-02953-7511B845; Fri, 12 Dec 2014 16:01:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418400084!14747112!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 3412 invoked from network); 12 Dec 2014 16:01: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;
	12 Dec 2014 16:01:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203521307"
Message-ID: <1418400081.16425.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <freddy77@gmail.com>
Date: Fri, 12 Dec 2014 16:01:21 +0000
In-Reply-To: <1418399945.16425.13.camel@citrix.com>
References: <CAHt6W4da7s=UcxucNnfYvWD8cMvVHSuQUiYWPTNu_V7X1ejq9w@mail.gmail.com>
	<1418399945.16425.13.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Porting 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>
Content-Type: text/plain; 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-12-12 at 15:59 +0000, Ian Campbell wrote:
> On Mon, 2014-12-08 at 15:47 +0000, Frediano Ziglio wrote:
> > Hi,
> >   while I was porting D01 platform
> > (https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
> > trying to describe the step I made and problems I encountered hoping
> > it could useful to other people. The idea is to put such documentation
> > in a wiki page or in the docs directory.
> > 
> > Let me know what do you think.
> 
> I've only skimmed the headings etc but I see no harm in posting it
> somewhere publicly. I don't know if wiki or in tree docs would be
> better. Maybe just post it on the list? At least then it will be in the
> archives.

Silly me, I missed the CC to the list!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:01:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzSeo-0006yY-8X; Fri, 12 Dec 2014 16:01: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 1XzSem-0006yQ-J4
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 16:01:28 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	6E/02-02953-7511B845; Fri, 12 Dec 2014 16:01:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418400084!14747112!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 3412 invoked from network); 12 Dec 2014 16:01: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;
	12 Dec 2014 16:01:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203521307"
Message-ID: <1418400081.16425.14.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <freddy77@gmail.com>
Date: Fri, 12 Dec 2014 16:01:21 +0000
In-Reply-To: <1418399945.16425.13.camel@citrix.com>
References: <CAHt6W4da7s=UcxucNnfYvWD8cMvVHSuQUiYWPTNu_V7X1ejq9w@mail.gmail.com>
	<1418399945.16425.13.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Porting 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>
Content-Type: text/plain; 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-12-12 at 15:59 +0000, Ian Campbell wrote:
> On Mon, 2014-12-08 at 15:47 +0000, Frediano Ziglio wrote:
> > Hi,
> >   while I was porting D01 platform
> > (https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
> > trying to describe the step I made and problems I encountered hoping
> > it could useful to other people. The idea is to put such documentation
> > in a wiki page or in the docs directory.
> > 
> > Let me know what do you think.
> 
> I've only skimmed the headings etc but I see no harm in posting it
> somewhere publicly. I don't know if wiki or in tree docs would be
> better. Maybe just post it on the list? At least then it will be in the
> archives.

Silly me, I missed the CC to the list!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:15:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzSre-0007oY-J0; Fri, 12 Dec 2014 16:14:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1XzSrc-0007oR-Ns
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 16:14:44 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	04/79-16982-3741B845; Fri, 12 Dec 2014 16:14:43 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418400883!12990506!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13375 invoked from network); 12 Dec 2014 16:14:43 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 16:14:43 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id DC70710FF065;
	Fri, 12 Dec 2014 17:14:42 +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 6ZZLKyomDI3q; Fri, 12 Dec 2014 17:14:42 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id 5DB9A10FF109;
	Fri, 12 Dec 2014 17:14:42 +0100 (CET)
Message-ID: <548B1472.5080302@univention.de>
Date: Fri, 12 Dec 2014 17:14:42 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com>
In-Reply-To: <1415869951.31613.26.camel@citrix.com>
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

Hello,

On 13.11.2014 10:12, Ian Campbell wrote:
> 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.

We did enable tracing and now have the xenstored-trace.log of one crash:
It contains 1.6 billion lines and is 83 GiB.
It just shows xenstored to crash on TRANSACTION_START.

Is there some tool to feed that trace back into a newly launched xenstored?

My hope would be that xenstored crashes again, because then we could use
all those other tools like valgrind more easily.

>> 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.

Now we also observed a crash on a host running Windows VMs.

> 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?

Multiple host in two different data centers.

> 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.

We're using a tmpfs for /var/lib/xenstored/, as we had some sever
performance problem with something updating
/local/domain/0/backend/console/*/0/uuid too often, which put xenstored
in permanent D state.

> 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.

Thank you for the hint, I'll have another look at the Ocaml version.

Thank you again.
Philipp Hahn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:15:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzSre-0007oY-J0; Fri, 12 Dec 2014 16:14:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1XzSrc-0007oR-Ns
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 16:14:44 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	04/79-16982-3741B845; Fri, 12 Dec 2014 16:14:43 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418400883!12990506!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13375 invoked from network); 12 Dec 2014 16:14:43 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 16:14:43 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id DC70710FF065;
	Fri, 12 Dec 2014 17:14:42 +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 6ZZLKyomDI3q; Fri, 12 Dec 2014 17:14:42 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id 5DB9A10FF109;
	Fri, 12 Dec 2014 17:14:42 +0100 (CET)
Message-ID: <548B1472.5080302@univention.de>
Date: Fri, 12 Dec 2014 17:14:42 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com>
In-Reply-To: <1415869951.31613.26.camel@citrix.com>
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

Hello,

On 13.11.2014 10:12, Ian Campbell wrote:
> 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.

We did enable tracing and now have the xenstored-trace.log of one crash:
It contains 1.6 billion lines and is 83 GiB.
It just shows xenstored to crash on TRANSACTION_START.

Is there some tool to feed that trace back into a newly launched xenstored?

My hope would be that xenstored crashes again, because then we could use
all those other tools like valgrind more easily.

>> 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.

Now we also observed a crash on a host running Windows VMs.

> 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?

Multiple host in two different data centers.

> 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.

We're using a tmpfs for /var/lib/xenstored/, as we had some sever
performance problem with something updating
/local/domain/0/backend/console/*/0/uuid too often, which put xenstored
in permanent D state.

> 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.

Thank you for the hint, I'll have another look at the Ocaml version.

Thank you again.
Philipp Hahn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:22:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzSyn-00089A-Ez; Fri, 12 Dec 2014 16:22: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 1XzSym-000895-5i
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 16:22:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2D/5D-25276-F261B845; Fri, 12 Dec 2014 16:22:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418401325!7944274!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25014 invoked from network); 12 Dec 2014 16:22:06 -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;
	12 Dec 2014 16:22:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203938421"
Message-ID: <1418401323.16425.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Fri, 12 Dec 2014 16:22:03 +0000
In-Reply-To: <548832AD0200006600082E25@soto.provo.novell.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
	<20141208111214.GC17128@zion.uk.xensource.com>
	<5486F36502000066000825D5@soto.provo.novell.com>
	<1418123518.14361.20.camel@citrix.com>
	<548832AD0200006600082E25@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, 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-12-09 at 20:46 -0700, Chun Yan Liu wrote:
> 
> >>> On 12/9/2014 at 07:11 PM, in message <1418123518.14361.20.camel@citrix.com>,
> Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> > On Mon, 2014-12-08 at 22:04 -0700, Chun Yan Liu wrote: 
> > > Partly. At least for domain disk snapshot create/delete, I prefer using 
> > > qmp commands instead of calling qemu-img one by one. Using qmp 
> > > commands, libvirt will need libxl's help. Of course, if libxl doesn't 
> > > supply that, libvirt can call qemu-img to each disk one by one, 
> > > not preferred but can do. 
> >  
> > You can't use qmp unless the domain is active, for an inactive domain 
> > there is no qemu to talk to, so you have to use qemu-img anyway in that 
> > case. Does libvirt not have existing code to do all this sort of thing? 
> > (I thought so, but it turns out I may be wrong, see below). 
> 
> No. Even inlibvirt/qemu_driver (for kvm), it does the work itself through
> qemu monitor commands.

Is this just the code for the actual act of taking a snapshot or is it a
complete snapshotting infrastructure in the driver itself?

I would hope/assume that there was a split between the common code which
drives everything and tracks all the state etc and the specific driver
backend which is used to make state changes to active domains. Is that
the case or is everything snapshot related in the libvirt qemu_driver?

> > And for an active domain I expect that *must* use qmp, since it seems 
> > unlikely that you can go around changing things under the feet of an 
> > active process (maybe I'm wrong?).
> 
> For active domain, I tried 'qemu-img snapshot' after pausing a domain,
> the commands succeeded. But I also think using qmp commands is better
> since qemu supplies transaction qmp, it avoids the trouble to roll back
> status when using qemu-img to do disk snapshot one by one but only part of
> disks succeed.

Yes, using qmp for an active domain seems sensible.

But you can't use qmp on an inactive domain. Does libvirt deal with this
in common code or does it require two code paths in the backend driver,
one for active and one for inactive domains?

> So, if disk snapshot functions can be provided to both libvirt and xl usage,
> it's very helpful to libvirt side. In this way, I may prefer to put disk snapshot
> functions to libxlu.

The actual command to snapshot a disk of an active+paused domain is fine
to go into libxl. In fact due to the proposed use of qmp it would have
to be.

Anything to do with the subsequent management of snapshots most likely
doesn't belong in libxl. Whether that stuff belongs in libxlu, xl or
libvirt depends on what scope there is for multiple toolstacks to use a
given helper function.

> > My understanding was that your primary aim here was to enable snapshots 
> > via libvirt and that xl support was just a nice to have. Is that right? 
> 
> We hope both :-)

OK, thanks for clarifying.

> Libvirt side already has some codes as I know and hopes to integrate with
> libxl to enable snapshots. Of course the two toolstacks can have some
> differences in commands, that's OK.
> 
> Libvirt side, to use unified virsh commands, it will supply
> snapshot-create/delete/revert/list.

This is what I expected you were aiming for.

> Xl side, if it's better to supply snapshot-create/revert, we can implement
> like that. Then it IS much easier since no need to manage snapshots in xl,
> then no save/retrieve json file things and no snapshot chain things. Do
> we want/decide to follow this?

The xl snapshot functionality should be kept as simple as possible and
following the existing xl idioms of managing storage and saved VM images
via existing CLI command (qemu-img, lvcreate, ls, mv, cp 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 Dec 12 16:22:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzSyn-00089A-Ez; Fri, 12 Dec 2014 16:22: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 1XzSym-000895-5i
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 16:22:08 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	2D/5D-25276-F261B845; Fri, 12 Dec 2014 16:22:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418401325!7944274!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25014 invoked from network); 12 Dec 2014 16:22:06 -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;
	12 Dec 2014 16:22:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203938421"
Message-ID: <1418401323.16425.28.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Fri, 12 Dec 2014 16:22:03 +0000
In-Reply-To: <548832AD0200006600082E25@soto.provo.novell.com>
References: <1415607424-15920-1-git-send-email-cyliu@suse.com>
	<1415607424-15920-3-git-send-email-cyliu@suse.com>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
	<20141208111214.GC17128@zion.uk.xensource.com>
	<5486F36502000066000825D5@soto.provo.novell.com>
	<1418123518.14361.20.camel@citrix.com>
	<548832AD0200006600082E25@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, 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-12-09 at 20:46 -0700, Chun Yan Liu wrote:
> 
> >>> On 12/9/2014 at 07:11 PM, in message <1418123518.14361.20.camel@citrix.com>,
> Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> > On Mon, 2014-12-08 at 22:04 -0700, Chun Yan Liu wrote: 
> > > Partly. At least for domain disk snapshot create/delete, I prefer using 
> > > qmp commands instead of calling qemu-img one by one. Using qmp 
> > > commands, libvirt will need libxl's help. Of course, if libxl doesn't 
> > > supply that, libvirt can call qemu-img to each disk one by one, 
> > > not preferred but can do. 
> >  
> > You can't use qmp unless the domain is active, for an inactive domain 
> > there is no qemu to talk to, so you have to use qemu-img anyway in that 
> > case. Does libvirt not have existing code to do all this sort of thing? 
> > (I thought so, but it turns out I may be wrong, see below). 
> 
> No. Even inlibvirt/qemu_driver (for kvm), it does the work itself through
> qemu monitor commands.

Is this just the code for the actual act of taking a snapshot or is it a
complete snapshotting infrastructure in the driver itself?

I would hope/assume that there was a split between the common code which
drives everything and tracks all the state etc and the specific driver
backend which is used to make state changes to active domains. Is that
the case or is everything snapshot related in the libvirt qemu_driver?

> > And for an active domain I expect that *must* use qmp, since it seems 
> > unlikely that you can go around changing things under the feet of an 
> > active process (maybe I'm wrong?).
> 
> For active domain, I tried 'qemu-img snapshot' after pausing a domain,
> the commands succeeded. But I also think using qmp commands is better
> since qemu supplies transaction qmp, it avoids the trouble to roll back
> status when using qemu-img to do disk snapshot one by one but only part of
> disks succeed.

Yes, using qmp for an active domain seems sensible.

But you can't use qmp on an inactive domain. Does libvirt deal with this
in common code or does it require two code paths in the backend driver,
one for active and one for inactive domains?

> So, if disk snapshot functions can be provided to both libvirt and xl usage,
> it's very helpful to libvirt side. In this way, I may prefer to put disk snapshot
> functions to libxlu.

The actual command to snapshot a disk of an active+paused domain is fine
to go into libxl. In fact due to the proposed use of qmp it would have
to be.

Anything to do with the subsequent management of snapshots most likely
doesn't belong in libxl. Whether that stuff belongs in libxlu, xl or
libvirt depends on what scope there is for multiple toolstacks to use a
given helper function.

> > My understanding was that your primary aim here was to enable snapshots 
> > via libvirt and that xl support was just a nice to have. Is that right? 
> 
> We hope both :-)

OK, thanks for clarifying.

> Libvirt side already has some codes as I know and hopes to integrate with
> libxl to enable snapshots. Of course the two toolstacks can have some
> differences in commands, that's OK.
> 
> Libvirt side, to use unified virsh commands, it will supply
> snapshot-create/delete/revert/list.

This is what I expected you were aiming for.

> Xl side, if it's better to supply snapshot-create/revert, we can implement
> like that. Then it IS much easier since no need to manage snapshots in xl,
> then no save/retrieve json file things and no snapshot chain things. Do
> we want/decide to follow this?

The xl snapshot functionality should be kept as simple as possible and
following the existing xl idioms of managing storage and saved VM images
via existing CLI command (qemu-img, lvcreate, ls, mv, cp 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 Dec 12 16:27:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzT3w-0008Qx-Dr; Fri, 12 Dec 2014 16:27: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 1XzT3v-0008Qs-D5
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 16:27:27 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	E5/E8-17958-E671B845; Fri, 12 Dec 2014 16:27:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418401644!10535365!1
X-Originating-IP: [66.165.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 13828 invoked from network); 12 Dec 2014 16:27:25 -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;
	12 Dec 2014 16:27:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203534533"
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.210.2; Fri, 12 Dec 2014 11:27: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 1XzT3r-0006Ea-FX;
	Fri, 12 Dec 2014 16:27:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzT3r-0006RO-9c;
	Fri, 12 Dec 2014 16:27:23 +0000
Date: Fri, 12 Dec 2014 16:27:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32278-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] 32278: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32278 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32278/

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

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-xl-pcipt-intel  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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                92a578b064d0227a3a7fbbdb9e29dbab7f8d400e
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1111 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 85196 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 Dec 12 16:27:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzT3w-0008Qx-Dr; Fri, 12 Dec 2014 16:27: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 1XzT3v-0008Qs-D5
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 16:27:27 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	E5/E8-17958-E671B845; Fri, 12 Dec 2014 16:27:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418401644!10535365!1
X-Originating-IP: [66.165.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 13828 invoked from network); 12 Dec 2014 16:27:25 -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;
	12 Dec 2014 16:27:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203534533"
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.210.2; Fri, 12 Dec 2014 11:27: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 1XzT3r-0006Ea-FX;
	Fri, 12 Dec 2014 16:27:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzT3r-0006RO-9c;
	Fri, 12 Dec 2014 16:27:23 +0000
Date: Fri, 12 Dec 2014 16:27:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32278-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] 32278: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32278 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32278/

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

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-xl-pcipt-intel  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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                92a578b064d0227a3a7fbbdb9e29dbab7f8d400e
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1111 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 85196 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 Dec 12 16:32:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzT8f-0000Jp-4S; Fri, 12 Dec 2014 16:32: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 1XzT8d-0000Iz-4L
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 16:32:19 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	51/2C-26652-2981B845; Fri, 12 Dec 2014 16:32:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418401935!13098797!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 31582 invoked from network); 12 Dec 2014 16:32: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;
	12 Dec 2014 16:32:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203536746"
Message-ID: <1418401932.16425.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Fri, 12 Dec 2014 16:32:12 +0000
In-Reply-To: <548B1472.5080302@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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 Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
> Hello,
> 
> On 13.11.2014 10:12, Ian Campbell wrote:
> > 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.
> 
> We did enable tracing and now have the xenstored-trace.log of one crash:
> It contains 1.6 billion lines and is 83 GiB.
> It just shows xenstored to crash on TRANSACTION_START.
> 
> Is there some tool to feed that trace back into a newly launched xenstored?

Not that I know of I'm afraid.

Do you get a core dump when this happens? You might need to fiddle with
ulimits (some distros disable by default). IIRC there is also some /proc
nob which controls where core dumps go on the filesystem.

> My hope would be that xenstored crashes again, because then we could use
> all those other tools like valgrind more easily.

That would be handy. My fear would be that this bug is likely to be a
race condition of some sort, and the granularity/accuracy of the
playback would possibly need to be quite high to trigger the issue.
 
> > 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.
> 
> We're using a tmpfs for /var/lib/xenstored/, as we had some sever
> performance problem with something updating
> /local/domain/0/backend/console/*/0/uuid too often, which put xenstored
> in permanent D state.

But this is just a process crashing and not the whole host so you still
have the db file at the point of the crash?

It might be interesting to see what happens if you preserve the db and
reboot arranging for the new xenstored to start with the old file. If
the corruption is part of the file then maybe it can be induced to crash
again more quickly.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:32:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzT8f-0000Jp-4S; Fri, 12 Dec 2014 16:32: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 1XzT8d-0000Iz-4L
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 16:32:19 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	51/2C-26652-2981B845; Fri, 12 Dec 2014 16:32:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418401935!13098797!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 31582 invoked from network); 12 Dec 2014 16:32: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;
	12 Dec 2014 16:32:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203536746"
Message-ID: <1418401932.16425.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Fri, 12 Dec 2014 16:32:12 +0000
In-Reply-To: <548B1472.5080302@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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 Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
> Hello,
> 
> On 13.11.2014 10:12, Ian Campbell wrote:
> > 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.
> 
> We did enable tracing and now have the xenstored-trace.log of one crash:
> It contains 1.6 billion lines and is 83 GiB.
> It just shows xenstored to crash on TRANSACTION_START.
> 
> Is there some tool to feed that trace back into a newly launched xenstored?

Not that I know of I'm afraid.

Do you get a core dump when this happens? You might need to fiddle with
ulimits (some distros disable by default). IIRC there is also some /proc
nob which controls where core dumps go on the filesystem.

> My hope would be that xenstored crashes again, because then we could use
> all those other tools like valgrind more easily.

That would be handy. My fear would be that this bug is likely to be a
race condition of some sort, and the granularity/accuracy of the
playback would possibly need to be quite high to trigger the issue.
 
> > 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.
> 
> We're using a tmpfs for /var/lib/xenstored/, as we had some sever
> performance problem with something updating
> /local/domain/0/backend/console/*/0/uuid too often, which put xenstored
> in permanent D state.

But this is just a process crashing and not the whole host so you still
have the db file at the point of the crash?

It might be interesting to see what happens if you preserve the db and
reboot arranging for the new xenstored to start with the old file. If
the corruption is part of the file then maybe it can be induced to crash
again more quickly.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:35:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzTBF-0000Z6-Lt; Fri, 12 Dec 2014 16: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.Campbell@citrix.com>) id 1XzTBE-0000Z1-Qa
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 16:35:00 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	03/65-02957-4391B845; Fri, 12 Dec 2014 16:35:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418402097!14753384!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 15772 invoked from network); 12 Dec 2014 16:34:59 -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 Dec 2014 16:34:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203944003"
Message-ID: <1418402085.16425.35.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 12 Dec 2014 16:34:45 +0000
In-Reply-To: <548AD05D020000780004F329@mail.emea.novell.com>
References: <548AD05D020000780004F329@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v2] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-12 at 10:24 +0000, Jan Beulich wrote:
> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> wasn't really consistent in one respect: The granting of access to an
> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> domains. In fact it is wrong to assume that a translation is already/
> still in place at the time access is being granted/revoked.
> 
> What is wanted is to translate the incoming pIRQ to an IRQ for
> the invoking domain (as the pIRQ is the only notion the invoking
> domain has of the IRQ), and grant the subject domain access to
> the resulting IRQ.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
> v2: Also fix initial range check to use current->domain, adjust code
>     structure, and extend description (all requested by Ian). Along
>     the lines of the first mentioned change, also pass the Xen IRQ
>     number to the XSM hook (confirmed okay by Daniel).
> Note that I would hope for this to make unnecessary Stefano's proposed
> tools side change
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00160.html.
> 
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -982,18 +982,21 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  
>      case XEN_DOMCTL_irq_permission:
>      {
> -        unsigned int pirq = op->u.irq_permission.pirq;
> +        unsigned int pirq = op->u.irq_permission.pirq, irq;
>          int allow = op->u.irq_permission.allow_access;
>  
> -        if ( pirq >= d->nr_pirqs )
> +        if ( pirq >= current->domain->nr_pirqs )
> +        {
>              ret = -EINVAL;
> -        else if ( !pirq_access_permitted(current->domain, pirq) ||
> -                  xsm_irq_permission(XSM_HOOK, d, pirq, allow) )
> +            break;
> +        }
> +        irq = pirq_access_permitted(current->domain, pirq);
> +        if ( !irq || xsm_irq_permission(XSM_HOOK, d, irq, allow) )
>              ret = -EPERM;
>          else if ( allow )
> -            ret = pirq_permit_access(d, pirq);
> +            ret = irq_permit_access(d, irq);
>          else
> -            ret = pirq_deny_access(d, pirq);
> +            ret = irq_deny_access(d, irq);
>      }
>      break;
>  
> --- a/xen/include/xen/iocap.h
> +++ b/xen/include/xen/iocap.h
> @@ -28,22 +28,11 @@
>  #define irq_access_permitted(d, i)                      \
>      rangeset_contains_singleton((d)->irq_caps, i)
>  
> -#define pirq_permit_access(d, i) ({                     \
> -    struct domain *d__ = (d);                           \
> -    int i__ = domain_pirq_to_irq(d__, i);               \
> -    i__ > 0 ? rangeset_add_singleton(d__->irq_caps, i__)\
> -            : -EINVAL;                                  \
> -})
> -#define pirq_deny_access(d, i) ({                       \
> -    struct domain *d__ = (d);                           \
> -    int i__ = domain_pirq_to_irq(d__, i);               \
> -    i__ > 0 ? rangeset_remove_singleton(d__->irq_caps, i__)\
> -            : -EINVAL;                                  \
> -})
>  #define pirq_access_permitted(d, i) ({                  \
>      struct domain *d__ = (d);                           \
> -    rangeset_contains_singleton(d__->irq_caps,          \
> -                                domain_pirq_to_irq(d__, i));\
> +    int irq__ = domain_pirq_to_irq(d__, i);             \
> +    irq__ > 0 && irq_access_permitted(d__, irq__)       \
> +    ? irq__ : 0;                                        \
>  })
>  
>  #endif /* __XEN_IOCAP_H__ */
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:35:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzTBF-0000Z6-Lt; Fri, 12 Dec 2014 16: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.Campbell@citrix.com>) id 1XzTBE-0000Z1-Qa
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 16:35:00 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	03/65-02957-4391B845; Fri, 12 Dec 2014 16:35:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418402097!14753384!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 15772 invoked from network); 12 Dec 2014 16:34:59 -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 Dec 2014 16:34:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="203944003"
Message-ID: <1418402085.16425.35.camel@eu.citrix.com>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 12 Dec 2014 16:34:45 +0000
In-Reply-To: <548AD05D020000780004F329@mail.emea.novell.com>
References: <548AD05D020000780004F329@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v2] domctl: fix IRQ permission
	granting/revocation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-12 at 10:24 +0000, Jan Beulich wrote:
> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> wasn't really consistent in one respect: The granting of access to an
> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> domains. In fact it is wrong to assume that a translation is already/
> still in place at the time access is being granted/revoked.
> 
> What is wanted is to translate the incoming pIRQ to an IRQ for
> the invoking domain (as the pIRQ is the only notion the invoking
> domain has of the IRQ), and grant the subject domain access to
> the resulting IRQ.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
> v2: Also fix initial range check to use current->domain, adjust code
>     structure, and extend description (all requested by Ian). Along
>     the lines of the first mentioned change, also pass the Xen IRQ
>     number to the XSM hook (confirmed okay by Daniel).
> Note that I would hope for this to make unnecessary Stefano's proposed
> tools side change
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00160.html.
> 
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -982,18 +982,21 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  
>      case XEN_DOMCTL_irq_permission:
>      {
> -        unsigned int pirq = op->u.irq_permission.pirq;
> +        unsigned int pirq = op->u.irq_permission.pirq, irq;
>          int allow = op->u.irq_permission.allow_access;
>  
> -        if ( pirq >= d->nr_pirqs )
> +        if ( pirq >= current->domain->nr_pirqs )
> +        {
>              ret = -EINVAL;
> -        else if ( !pirq_access_permitted(current->domain, pirq) ||
> -                  xsm_irq_permission(XSM_HOOK, d, pirq, allow) )
> +            break;
> +        }
> +        irq = pirq_access_permitted(current->domain, pirq);
> +        if ( !irq || xsm_irq_permission(XSM_HOOK, d, irq, allow) )
>              ret = -EPERM;
>          else if ( allow )
> -            ret = pirq_permit_access(d, pirq);
> +            ret = irq_permit_access(d, irq);
>          else
> -            ret = pirq_deny_access(d, pirq);
> +            ret = irq_deny_access(d, irq);
>      }
>      break;
>  
> --- a/xen/include/xen/iocap.h
> +++ b/xen/include/xen/iocap.h
> @@ -28,22 +28,11 @@
>  #define irq_access_permitted(d, i)                      \
>      rangeset_contains_singleton((d)->irq_caps, i)
>  
> -#define pirq_permit_access(d, i) ({                     \
> -    struct domain *d__ = (d);                           \
> -    int i__ = domain_pirq_to_irq(d__, i);               \
> -    i__ > 0 ? rangeset_add_singleton(d__->irq_caps, i__)\
> -            : -EINVAL;                                  \
> -})
> -#define pirq_deny_access(d, i) ({                       \
> -    struct domain *d__ = (d);                           \
> -    int i__ = domain_pirq_to_irq(d__, i);               \
> -    i__ > 0 ? rangeset_remove_singleton(d__->irq_caps, i__)\
> -            : -EINVAL;                                  \
> -})
>  #define pirq_access_permitted(d, i) ({                  \
>      struct domain *d__ = (d);                           \
> -    rangeset_contains_singleton(d__->irq_caps,          \
> -                                domain_pirq_to_irq(d__, i));\
> +    int irq__ = domain_pirq_to_irq(d__, i);             \
> +    irq__ > 0 && irq_access_permitted(d__, irq__)       \
> +    ? irq__ : 0;                                        \
>  })
>  
>  #endif /* __XEN_IOCAP_H__ */
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:41:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzTHZ-0000jL-Td; Fri, 12 Dec 2014 16:41:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XzTHY-0000jG-6S
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 16:41:32 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	83/74-14214-BBA1B845; Fri, 12 Dec 2014 16:41:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418402489!7786641!1
X-Originating-IP: [156.151.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 16907 invoked from network); 12 Dec 2014 16:41:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2014 16:41:30 -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 sBCGfOEd023147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Dec 2014 16:41:25 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
	sBCGfMhU015455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Dec 2014 16:41:23 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
	sBCGfLow021912; Fri, 12 Dec 2014 16:41:22 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 08:41:21 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EF4D3123653; Fri, 12 Dec 2014 11:41:19 -0500 (EST)
Date: Fri, 12 Dec 2014 11:41:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141212164119.GA28140@laptop.dumpdata.com>
References: <5489906B020000780004EE34@mail.emea.novell.com>
	<69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.com>
	<5489C88F020000780004F0C2@mail.emea.novell.com>
	<20141211194148.GG18992@laptop.dumpdata.com>
	<548AC73D020000780004F2F6@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548AC73D020000780004F2F6@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	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] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, 2014 at 09:45:17AM +0000, Jan Beulich wrote:
> >>> On 11.12.14 at 20:41, <konrad.wilk@oracle.com> wrote:
> > On Thu, Dec 11, 2014 at 03:38:39PM +0000, Jan Beulich wrote:
> >> >>> On 11.12.14 at 16:18, <konrad.wilk@oracle.com> wrote:
> >> > A proper fix would be to automatically adjust based on memmap and CPU but 
> >> > that could be too complex.
> >> 
> >> The problem isn't the complexity, but the chicken-and-egg problem
> >> as far as CPU count is concerned. The memory map size would be
> >> known early enough.
> > 
> > Let me explain my thought process:
> >  - There are existing knobs that can be used to change this (conring_size=X)
> >  - But we would like an awesome release where those knobs don't have to
> >    be used.
> >  - The patch you posted could be reworked to fully address memmap and CPU.
> 
> Not really, unless we separate parsing and printing of the ACPI
> tables. Again, the CPU count is known only after that parsing.

Right, the logic of increasing the buffer based on CPU count is an
excellent addition.
> 
> >  - I don't know what your time constraints are for said patch and you
> >    might not have the energy to rework it.
> >  - I don't want to put pressure on you or Daniel on having to write new
> >    patches - especially as folks are going on vacation soon.
> > 
> > Hence as a fallback I believe that Daniel's patch should go in and
> > Jan's patch can go in too. However if Jan (or somebody else) wants to
> > rework the v2 (or a new one) to address the memmap issue then that
> > patch would go in - instead of Daniel's or v2 of Jan patch.
> 
> Which memmap issue? You confirmed in your reply that you understand
> that the memmap gets printed late enough for the change in v2 to
> take effect. Plus those are info-level messages, and hence don't get

Correct. The count of memmap entries can be high even with an
small amount of CPUs. Meaning your patch would not modify the
size of the circular buffer in such case (and we would lose some
of the memmap entries being printed). Daniel's patch would
provide a cushion by expanding the default size, however ..

> printed at all by default. And if somebody alters the log levels, (s)he
> can surely be expected to also adjust the ring size. (The log level
> aspect is actually another argument against Daniel's patch.)

... your point about the need to use 'loglvl' points out that
Daniel's patch does not fix the all-generic case.

/me puts on the Xen 4.6 todo 'adjust log buffer based on memmap size'

And your patch is:
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 Fri Dec 12 16:41:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzTHZ-0000jL-Td; Fri, 12 Dec 2014 16:41:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XzTHY-0000jG-6S
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 16:41:32 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	83/74-14214-BBA1B845; Fri, 12 Dec 2014 16:41:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418402489!7786641!1
X-Originating-IP: [156.151.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 16907 invoked from network); 12 Dec 2014 16:41:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Dec 2014 16:41:30 -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 sBCGfOEd023147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Dec 2014 16:41:25 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
	sBCGfMhU015455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Dec 2014 16:41:23 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
	sBCGfLow021912; Fri, 12 Dec 2014 16:41:22 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 08:41:21 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id EF4D3123653; Fri, 12 Dec 2014 11:41:19 -0500 (EST)
Date: Fri, 12 Dec 2014 11:41:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141212164119.GA28140@laptop.dumpdata.com>
References: <5489906B020000780004EE34@mail.emea.novell.com>
	<69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.com>
	<5489C88F020000780004F0C2@mail.emea.novell.com>
	<20141211194148.GG18992@laptop.dumpdata.com>
	<548AC73D020000780004F2F6@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548AC73D020000780004F2F6@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	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] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, 2014 at 09:45:17AM +0000, Jan Beulich wrote:
> >>> On 11.12.14 at 20:41, <konrad.wilk@oracle.com> wrote:
> > On Thu, Dec 11, 2014 at 03:38:39PM +0000, Jan Beulich wrote:
> >> >>> On 11.12.14 at 16:18, <konrad.wilk@oracle.com> wrote:
> >> > A proper fix would be to automatically adjust based on memmap and CPU but 
> >> > that could be too complex.
> >> 
> >> The problem isn't the complexity, but the chicken-and-egg problem
> >> as far as CPU count is concerned. The memory map size would be
> >> known early enough.
> > 
> > Let me explain my thought process:
> >  - There are existing knobs that can be used to change this (conring_size=X)
> >  - But we would like an awesome release where those knobs don't have to
> >    be used.
> >  - The patch you posted could be reworked to fully address memmap and CPU.
> 
> Not really, unless we separate parsing and printing of the ACPI
> tables. Again, the CPU count is known only after that parsing.

Right, the logic of increasing the buffer based on CPU count is an
excellent addition.
> 
> >  - I don't know what your time constraints are for said patch and you
> >    might not have the energy to rework it.
> >  - I don't want to put pressure on you or Daniel on having to write new
> >    patches - especially as folks are going on vacation soon.
> > 
> > Hence as a fallback I believe that Daniel's patch should go in and
> > Jan's patch can go in too. However if Jan (or somebody else) wants to
> > rework the v2 (or a new one) to address the memmap issue then that
> > patch would go in - instead of Daniel's or v2 of Jan patch.
> 
> Which memmap issue? You confirmed in your reply that you understand
> that the memmap gets printed late enough for the change in v2 to
> take effect. Plus those are info-level messages, and hence don't get

Correct. The count of memmap entries can be high even with an
small amount of CPUs. Meaning your patch would not modify the
size of the circular buffer in such case (and we would lose some
of the memmap entries being printed). Daniel's patch would
provide a cushion by expanding the default size, however ..

> printed at all by default. And if somebody alters the log levels, (s)he
> can surely be expected to also adjust the ring size. (The log level
> aspect is actually another argument against Daniel's patch.)

... your point about the need to use 'loglvl' points out that
Daniel's patch does not fix the all-generic case.

/me puts on the Xen 4.6 todo 'adjust log buffer based on memmap size'

And your patch is:
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 Fri Dec 12 16:44:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzTKC-00019x-FR; Fri, 12 Dec 2014 16:44:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XzTKB-00019r-RB
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 16:44:16 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	51/89-20609-F5B1B845; Fri, 12 Dec 2014 16:44:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418402653!14755124!1
X-Originating-IP: [156.151.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 31265 invoked from network); 12 Dec 2014 16:44:14 -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; 12 Dec 2014 16:44: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 sBCGiAYJ027123
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Dec 2014 16:44:11 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
	sBCGi9Rt002995
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 12 Dec 2014 16:44:10 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
	sBCGi9jb002983; Fri, 12 Dec 2014 16:44:09 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 08:44:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BE0ED123659; Fri, 12 Dec 2014 11:44:07 -0500 (EST)
Date: Fri, 12 Dec 2014 11:44:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141212164407.GB28140@laptop.dumpdata.com>
References: <548AEAE7.8020604@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548AEAE7.8020604@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Xen's Linux kernel config options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, 2014 at 02:17:27PM +0100, Juergen Gross wrote:
> Hi,
> 
> This is a design proposal for a rework of the config options on the
> Linux kernel which are related to Xen.
> 
> The need to do so arose from the fact that it is currently not
> possible to build the Xen frontend drivers for a non-pvops kernel,
> e.g. to run them in a HVM-domain. There are more drawbacks in the
> current config options to which I'll come later.
> 
> Current Xen related config options are as follows:
> 
> Option                          Selects                 Depends
> ---------------------------------------------------------------------
> XEN                             PARAVIRT_CLOCK(x86)     PARAVIRT(x86)
>                                 XEN_HAVE_PVMMU(x86)
>                                 SWIOTLB_XEN(arm,arm64)
>   PCI_XEN(x86)                  SWIOTLB_XEN
>   XEN_DOM0                                              PCI_XEN(x86)
>     XEN_BACKEND
>       XEN_BLKDEV_BACKEND
>       XEN_PCIDEV_BACKEND(x86)
>       XEN_SCSI_BACKEND
>       XEN_NETDEV_BACKEND
>     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
>     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
>     XEN_MCE_LOG(x86)
>   XEN_PVHVM(x86)
>     XEN_PVH(x86)
>   XEN_MAX_DOMAIN_MEMORY(x86)
>   XEN_SAVE_RESTORE(x86)
>   XEN_DEBUG_FS(x86)
>   XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
>                                 INPUT_XEN_KBDDEV_FRONTEND
>   XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
>   HVC_XEN
>     HVC_XEN_FRONTEND            XEN_XENBUS_FRONTEND
>   TCG_XEN                       XEN_XENBUS_FRONTEND
>   XEN_PCIDEV_FRONTEND           PCI_XEN
>                                 XEN_XENBUS_FRONTEND
>   XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
>   INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
>   XEN_WDT
>   XEN_BALLOON
>     XEN_SELFBALLOONING                                  XEN_TMEM
>     XEN_BALLOON_MEMORY_HOTPLUG
>     XEN_SCRUB_PAGES
>   XEN_DEV_EVTCHN
>   XENFS                         XEN_PRIVCMD
>     XEN_COMPAT_XENFS
>   XEN_SYS_HYPERVISOR
>   XEN_XENBUS_FRONTEND
>   XEN_GNTDEV
>   XEN_GRANT_DEV_ALLOC
>   SWIOTLB_XEN
>   XEN_TMEM(x86)
>   XEN_PRIVCMD
>   XEN_STUB(x86_64)                                      BROKEN
>   XEN_ACPI_PROCESSOR(x86)
>   XEN_HAVE_PVMMU
>   XEN_EFI(x64)
>   XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND
> 
> Legend:
> - The first column are the Xen config options. Indentation in this
>   column reflects the dependency between those options (e.g.
>   XEN_SCSI_BACKEND depends on XEN_BACKEND, which in turn depends on
>   XEN_DOM0, which depends on XEN).
> - The second column shows the options which are selected automatically
>   if the corresponding option in the first column is configured.
> - The last column shows additional dependencies which can't be shown via
>   the indentation level of the first column.
> - Some options or dependencies are architecture specific, they are
>   listed in brackets (e.g. XEN_TMEM which is available for x86 only).
> - Non-Xen options are mentioned only if they seem to be really relevant,
>   like e.g. PARAVIRT or BROKEN.
> 
> There are several reasons to change the config options:
> - Be able to build Xen frontend drivers for HVM domains without the need
>   for choosing a pvops kernel: currently the frontend drivers need XEN
>   configured which depends on PARAVIRT.
> - Be able to build a Dom0 using XEN_PVH without having to configure
>   XEN_HAVE_PVMMU.
> - Be able to build HVM driver domains.
> - Some features are available for x86 only, in spite of being not
>   architecture specific, e.g. XEN_DEBUG_FS or XEN_TMEM.
> 
> As a first draft I'd suggest the following:
> 
> Option                          Selects                 Depends
> ----------------------------------------------------------------------
> XEN                             SWIOTLB_XEN(arm,arm64)
>   XEN_PV(x86)                   XEN_HAVE_PVMMU
>                                 PARAVIRT
>                                 PARAVIRT_CLOCK
>   XEN_PVH(x86)                  XEN_PVHVM
>                                 PARAVIRT
>                                 PARAVIRT_CLOCK
>   XEN_BACKEND                                           XEN_PV(x86) ||
>                                                         XEN_PVH(x86) ||
>                                                         XEN_PVHVM
>     XEN_BLKDEV_BACKEND
>     XEN_PCIDEV_BACKEND(x86)
>     XEN_SCSI_BACKEND
>     XEN_NETDEV_BACKEND
>   PCI_XEN(x86)                  SWIOTLB_XEN
>   XEN_DOM0                      XEN_BACKEND             XEN_PV(x86) ||
>                                 PCI_XEN(x86)            XEN_PVH(x86)

Could XEN_DOM0 be removed completly? And instead we just have
an 'backend' and 'frontend' type options?


>     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
>     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
>     XEN_MCE_LOG(x86)
>   XEN_MAX_DOMAIN_MEMORY(x86)
>   XEN_SAVE_RESTORE(x86)
>   XEN_DEBUG_FS
>   XEN_WDT
>   XEN_BALLOON
>     XEN_SELFBALLOONING                                  XEN_TMEM
>     XEN_BALLOON_MEMORY_HOTPLUG
>     XEN_SCRUB_PAGES
>   XENFS                         XEN_PRIVCMD
>     XEN_COMPAT_XENFS
>   XEN_SYS_HYPERVISOR
>   XEN_DEV_EVTCHN
>   XEN_GNTDEV
>   XEN_GRANT_DEV_ALLOC
>   SWIOTLB_XEN
>   XEN_TMEM
>   XEN_PRIVCMD
>   XEN_STUB(x86_64)                                      BROKEN
>   XEN_ACPI_PROCESSOR(x86)
>   XEN_HAVE_PVMMU
>   XEN_EFI(x64)
> XEN_PVHVM
> XEN_FRONTEND                                            XEN_PV ||
>                                                         XEN_PVH ||
>                                                         XEN_PVHVM
>   XEN_XENBUS_FRONTEND
>   XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
>                                 INPUT_XEN_KBDDEV_FRONTEND
>   XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
>   HVC_XEN_FRONTEND              XEN_XENBUS_FRONTEND
>                                 HVC_XEN
>   TCG_XEN                       XEN_XENBUS_FRONTEND
>   XEN_PCIDEV_FRONTEND           PCI_XEN
>                                 XEN_XENBUS_FRONTEND
>   XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
>   INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
>   XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND
> 
> There might be some further adjustments needed (should XEN_DEV_EVTCHN
> and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The
> main difference to the current status is the XEN setting no longer
> controlling all other options.
> 
> Changing the config options in this way surely will need some
> adjustments in the drivers, but this can be discussed when we agree
> on the future config dependencies.
> 
> 
> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:44:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16: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 1XzTKC-00019x-FR; Fri, 12 Dec 2014 16:44:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XzTKB-00019r-RB
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 16:44:16 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	51/89-20609-F5B1B845; Fri, 12 Dec 2014 16:44:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418402653!14755124!1
X-Originating-IP: [156.151.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 31265 invoked from network); 12 Dec 2014 16:44:14 -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; 12 Dec 2014 16:44: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 sBCGiAYJ027123
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Dec 2014 16:44:11 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
	sBCGi9Rt002995
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 12 Dec 2014 16:44:10 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
	sBCGi9jb002983; Fri, 12 Dec 2014 16:44:09 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 08:44:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BE0ED123659; Fri, 12 Dec 2014 11:44:07 -0500 (EST)
Date: Fri, 12 Dec 2014 11:44:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141212164407.GB28140@laptop.dumpdata.com>
References: <548AEAE7.8020604@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548AEAE7.8020604@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Xen's Linux kernel config options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, 2014 at 02:17:27PM +0100, Juergen Gross wrote:
> Hi,
> 
> This is a design proposal for a rework of the config options on the
> Linux kernel which are related to Xen.
> 
> The need to do so arose from the fact that it is currently not
> possible to build the Xen frontend drivers for a non-pvops kernel,
> e.g. to run them in a HVM-domain. There are more drawbacks in the
> current config options to which I'll come later.
> 
> Current Xen related config options are as follows:
> 
> Option                          Selects                 Depends
> ---------------------------------------------------------------------
> XEN                             PARAVIRT_CLOCK(x86)     PARAVIRT(x86)
>                                 XEN_HAVE_PVMMU(x86)
>                                 SWIOTLB_XEN(arm,arm64)
>   PCI_XEN(x86)                  SWIOTLB_XEN
>   XEN_DOM0                                              PCI_XEN(x86)
>     XEN_BACKEND
>       XEN_BLKDEV_BACKEND
>       XEN_PCIDEV_BACKEND(x86)
>       XEN_SCSI_BACKEND
>       XEN_NETDEV_BACKEND
>     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
>     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
>     XEN_MCE_LOG(x86)
>   XEN_PVHVM(x86)
>     XEN_PVH(x86)
>   XEN_MAX_DOMAIN_MEMORY(x86)
>   XEN_SAVE_RESTORE(x86)
>   XEN_DEBUG_FS(x86)
>   XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
>                                 INPUT_XEN_KBDDEV_FRONTEND
>   XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
>   HVC_XEN
>     HVC_XEN_FRONTEND            XEN_XENBUS_FRONTEND
>   TCG_XEN                       XEN_XENBUS_FRONTEND
>   XEN_PCIDEV_FRONTEND           PCI_XEN
>                                 XEN_XENBUS_FRONTEND
>   XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
>   INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
>   XEN_WDT
>   XEN_BALLOON
>     XEN_SELFBALLOONING                                  XEN_TMEM
>     XEN_BALLOON_MEMORY_HOTPLUG
>     XEN_SCRUB_PAGES
>   XEN_DEV_EVTCHN
>   XENFS                         XEN_PRIVCMD
>     XEN_COMPAT_XENFS
>   XEN_SYS_HYPERVISOR
>   XEN_XENBUS_FRONTEND
>   XEN_GNTDEV
>   XEN_GRANT_DEV_ALLOC
>   SWIOTLB_XEN
>   XEN_TMEM(x86)
>   XEN_PRIVCMD
>   XEN_STUB(x86_64)                                      BROKEN
>   XEN_ACPI_PROCESSOR(x86)
>   XEN_HAVE_PVMMU
>   XEN_EFI(x64)
>   XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND
> 
> Legend:
> - The first column are the Xen config options. Indentation in this
>   column reflects the dependency between those options (e.g.
>   XEN_SCSI_BACKEND depends on XEN_BACKEND, which in turn depends on
>   XEN_DOM0, which depends on XEN).
> - The second column shows the options which are selected automatically
>   if the corresponding option in the first column is configured.
> - The last column shows additional dependencies which can't be shown via
>   the indentation level of the first column.
> - Some options or dependencies are architecture specific, they are
>   listed in brackets (e.g. XEN_TMEM which is available for x86 only).
> - Non-Xen options are mentioned only if they seem to be really relevant,
>   like e.g. PARAVIRT or BROKEN.
> 
> There are several reasons to change the config options:
> - Be able to build Xen frontend drivers for HVM domains without the need
>   for choosing a pvops kernel: currently the frontend drivers need XEN
>   configured which depends on PARAVIRT.
> - Be able to build a Dom0 using XEN_PVH without having to configure
>   XEN_HAVE_PVMMU.
> - Be able to build HVM driver domains.
> - Some features are available for x86 only, in spite of being not
>   architecture specific, e.g. XEN_DEBUG_FS or XEN_TMEM.
> 
> As a first draft I'd suggest the following:
> 
> Option                          Selects                 Depends
> ----------------------------------------------------------------------
> XEN                             SWIOTLB_XEN(arm,arm64)
>   XEN_PV(x86)                   XEN_HAVE_PVMMU
>                                 PARAVIRT
>                                 PARAVIRT_CLOCK
>   XEN_PVH(x86)                  XEN_PVHVM
>                                 PARAVIRT
>                                 PARAVIRT_CLOCK
>   XEN_BACKEND                                           XEN_PV(x86) ||
>                                                         XEN_PVH(x86) ||
>                                                         XEN_PVHVM
>     XEN_BLKDEV_BACKEND
>     XEN_PCIDEV_BACKEND(x86)
>     XEN_SCSI_BACKEND
>     XEN_NETDEV_BACKEND
>   PCI_XEN(x86)                  SWIOTLB_XEN
>   XEN_DOM0                      XEN_BACKEND             XEN_PV(x86) ||
>                                 PCI_XEN(x86)            XEN_PVH(x86)

Could XEN_DOM0 be removed completly? And instead we just have
an 'backend' and 'frontend' type options?


>     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
>     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
>     XEN_MCE_LOG(x86)
>   XEN_MAX_DOMAIN_MEMORY(x86)
>   XEN_SAVE_RESTORE(x86)
>   XEN_DEBUG_FS
>   XEN_WDT
>   XEN_BALLOON
>     XEN_SELFBALLOONING                                  XEN_TMEM
>     XEN_BALLOON_MEMORY_HOTPLUG
>     XEN_SCRUB_PAGES
>   XENFS                         XEN_PRIVCMD
>     XEN_COMPAT_XENFS
>   XEN_SYS_HYPERVISOR
>   XEN_DEV_EVTCHN
>   XEN_GNTDEV
>   XEN_GRANT_DEV_ALLOC
>   SWIOTLB_XEN
>   XEN_TMEM
>   XEN_PRIVCMD
>   XEN_STUB(x86_64)                                      BROKEN
>   XEN_ACPI_PROCESSOR(x86)
>   XEN_HAVE_PVMMU
>   XEN_EFI(x64)
> XEN_PVHVM
> XEN_FRONTEND                                            XEN_PV ||
>                                                         XEN_PVH ||
>                                                         XEN_PVHVM
>   XEN_XENBUS_FRONTEND
>   XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
>                                 INPUT_XEN_KBDDEV_FRONTEND
>   XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
>   HVC_XEN_FRONTEND              XEN_XENBUS_FRONTEND
>                                 HVC_XEN
>   TCG_XEN                       XEN_XENBUS_FRONTEND
>   XEN_PCIDEV_FRONTEND           PCI_XEN
>                                 XEN_XENBUS_FRONTEND
>   XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
>   INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
>   XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND
> 
> There might be some further adjustments needed (should XEN_DEV_EVTCHN
> and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The
> main difference to the current status is the XEN setting no longer
> controlling all other options.
> 
> Changing the config options in this way surely will need some
> adjustments in the drivers, but this can be discussed when we agree
> on the future config dependencies.
> 
> 
> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:45:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16:45:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzTLQ-0001HW-42; Fri, 12 Dec 2014 16:45:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1XzTLP-0001HO-0z
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 16:45:31 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	98/17-17958-AAB1B845; Fri, 12 Dec 2014 16:45:30 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418402729!12989521!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2667 invoked from network); 12 Dec 2014 16:45:29 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 16:45:29 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id 808E510FF181;
	Fri, 12 Dec 2014 17:45:29 +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 sBmOXDExjKto; Fri, 12 Dec 2014 17:45:29 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id DB93110FF178;
	Fri, 12 Dec 2014 17:45:28 +0100 (CET)
Message-ID: <548B1BA8.3090504@univention.de>
Date: Fri, 12 Dec 2014 17:45:28 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>	
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com>
In-Reply-To: <1418401932.16425.34.camel@citrix.com>
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

Hello Ian,

On 12.12.2014 17:32, Ian Campbell wrote:
> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
>> We did enable tracing and now have the xenstored-trace.log of one crash:
>> It contains 1.6 billion lines and is 83 GiB.
>> It just shows xenstored to crash on TRANSACTION_START.
>>
>> Is there some tool to feed that trace back into a newly launched xenstored?
> 
> Not that I know of I'm afraid.

Okay, then I have to continue with my own tool.

> Do you get a core dump when this happens? You might need to fiddle with
> ulimits (some distros disable by default). IIRC there is also some /proc
> nob which controls where core dumps go on the filesystem.

Not for that specific trace: We first enabled generating core files, but
only then discovered that this is not enough. Then we enabled
--trace-file, but on that host something reseted generating the core file.
We hopefully fixed all hosts so on the next crash we hopefully will get
both a core file and the trace.

>> My hope would be that xenstored crashes again, because then we could use
>> all those other tools like valgrind more easily.
> 
> That would be handy. My fear would be that this bug is likely to be a
> race condition of some sort, and the granularity/accuracy of the
> playback would possibly need to be quite high to trigger the issue.

cxenstored looks single threaded to me, or am I wrong?

>>> 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.
>>
>> We're using a tmpfs for /var/lib/xenstored/, as we had some sever
>> performance problem with something updating
>> /local/domain/0/backend/console/*/0/uuid too often, which put xenstored
>> in permanent D state.
> 
> But this is just a process crashing and not the whole host so you still
> have the db file at the point of the crash?

Yes: Running xs_tdb_dump or tdb_dump on it didn't show anything
obviously wrong.

> It might be interesting to see what happens if you preserve the db and
> reboot arranging for the new xenstored to start with the old file. If
> the corruption is part of the file then maybe it can be induced to crash
> again more quickly.

Thanks for the pointer, will try.

Thank you again for your fast reply.
Philipp Hahn


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:45:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16:45:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzTLQ-0001HW-42; Fri, 12 Dec 2014 16:45:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1XzTLP-0001HO-0z
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 16:45:31 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	98/17-17958-AAB1B845; Fri, 12 Dec 2014 16:45:30 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418402729!12989521!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2667 invoked from network); 12 Dec 2014 16:45:29 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 16:45:29 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id 808E510FF181;
	Fri, 12 Dec 2014 17:45:29 +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 sBmOXDExjKto; Fri, 12 Dec 2014 17:45:29 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id DB93110FF178;
	Fri, 12 Dec 2014 17:45:28 +0100 (CET)
Message-ID: <548B1BA8.3090504@univention.de>
Date: Fri, 12 Dec 2014 17:45:28 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>	
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com>
In-Reply-To: <1418401932.16425.34.camel@citrix.com>
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

Hello Ian,

On 12.12.2014 17:32, Ian Campbell wrote:
> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
>> We did enable tracing and now have the xenstored-trace.log of one crash:
>> It contains 1.6 billion lines and is 83 GiB.
>> It just shows xenstored to crash on TRANSACTION_START.
>>
>> Is there some tool to feed that trace back into a newly launched xenstored?
> 
> Not that I know of I'm afraid.

Okay, then I have to continue with my own tool.

> Do you get a core dump when this happens? You might need to fiddle with
> ulimits (some distros disable by default). IIRC there is also some /proc
> nob which controls where core dumps go on the filesystem.

Not for that specific trace: We first enabled generating core files, but
only then discovered that this is not enough. Then we enabled
--trace-file, but on that host something reseted generating the core file.
We hopefully fixed all hosts so on the next crash we hopefully will get
both a core file and the trace.

>> My hope would be that xenstored crashes again, because then we could use
>> all those other tools like valgrind more easily.
> 
> That would be handy. My fear would be that this bug is likely to be a
> race condition of some sort, and the granularity/accuracy of the
> playback would possibly need to be quite high to trigger the issue.

cxenstored looks single threaded to me, or am I wrong?

>>> 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.
>>
>> We're using a tmpfs for /var/lib/xenstored/, as we had some sever
>> performance problem with something updating
>> /local/domain/0/backend/console/*/0/uuid too often, which put xenstored
>> in permanent D state.
> 
> But this is just a process crashing and not the whole host so you still
> have the db file at the point of the crash?

Yes: Running xs_tdb_dump or tdb_dump on it didn't show anything
obviously wrong.

> It might be interesting to see what happens if you preserve the db and
> reboot arranging for the new xenstored to start with the old file. If
> the corruption is part of the file then maybe it can be induced to crash
> again more quickly.

Thanks for the pointer, will try.

Thank you again for your fast reply.
Philipp Hahn


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:51:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzTQc-0001U5-T4; Fri, 12 Dec 2014 16:50:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XzTQb-0001U0-AU
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 16:50:53 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	65/DC-27785-CEC1B845; Fri, 12 Dec 2014 16:50:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418403050!14729816!1
X-Originating-IP: [156.151.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 30579 invoked from network); 12 Dec 2014 16:50:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 16:50: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 sBCGofVf002539
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Dec 2014 16:50: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
	sBCGobSB013259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Dec 2014 16:50:38 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
	sBCGoapO021052; Fri, 12 Dec 2014 16:50:36 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 08:50:36 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 152BA1236E3; Fri, 12 Dec 2014 11:50:35 -0500 (EST)
Date: Fri, 12 Dec 2014 11:50:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141212165035.GA28592@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
	<1999787702.20141212161352@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1999787702.20141212161352@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 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 Fri, Dec 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> This doesn't seem to be applied yet, nor does it seem to have a release-(N)ACK 
> from you ?

Hm, Stefano:

- Is this a regression?

- What are the risks of this not going in? I presume that it just means
  we haven't reset it in sysfs. But the xc_deassign_device operation
  if not done will not affect the hypervisor - which will move the
  device to dom0 upon guest teardown.

> 
> --
> Sander
> 
> 
> 
> Friday, November 28, 2014, 5:53:09 PM, you wrote:
> 
> > 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 Dec 12 16:51:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 16:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzTQc-0001U5-T4; Fri, 12 Dec 2014 16:50:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1XzTQb-0001U0-AU
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 16:50:53 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	65/DC-27785-CEC1B845; Fri, 12 Dec 2014 16:50:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418403050!14729816!1
X-Originating-IP: [156.151.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 30579 invoked from network); 12 Dec 2014 16:50:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 16:50: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 sBCGofVf002539
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Dec 2014 16:50: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
	sBCGobSB013259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Dec 2014 16:50:38 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
	sBCGoapO021052; Fri, 12 Dec 2014 16:50:36 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 08:50:36 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 152BA1236E3; Fri, 12 Dec 2014 11:50:35 -0500 (EST)
Date: Fri, 12 Dec 2014 11:50:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141212165035.GA28592@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
	<1999787702.20141212161352@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1999787702.20141212161352@eikelenboom.it>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 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 Fri, Dec 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> This doesn't seem to be applied yet, nor does it seem to have a release-(N)ACK 
> from you ?

Hm, Stefano:

- Is this a regression?

- What are the risks of this not going in? I presume that it just means
  we haven't reset it in sysfs. But the xc_deassign_device operation
  if not done will not affect the hypervisor - which will move the
  device to dom0 upon guest teardown.

> 
> --
> Sander
> 
> 
> 
> Friday, November 28, 2014, 5:53:09 PM, you wrote:
> 
> > 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 Dec 12 16:59:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 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 1XzTYC-0001x0-Qd; Fri, 12 Dec 2014 16:58:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XzTYC-0001wt-1p
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 16:58:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A4/55-15461-3CE1B845; Fri, 12 Dec 2014 16:58:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418403518!15221565!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16475 invoked from network); 12 Dec 2014 16:58:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 16:58:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,565,1413244800"; d="scan'208";a="203547298"
Message-ID: <1418403387.16425.38.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Fri, 12 Dec 2014 16:56:27 +0000
In-Reply-To: <548B1BA8.3090504@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
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 Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
> Hello Ian,
> 
> On 12.12.2014 17:32, Ian Campbell wrote:
> > On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
> >> We did enable tracing and now have the xenstored-trace.log of one crash:
> >> It contains 1.6 billion lines and is 83 GiB.
> >> It just shows xenstored to crash on TRANSACTION_START.
> >>
> >> Is there some tool to feed that trace back into a newly launched xenstored?
> > 
> > Not that I know of I'm afraid.
> 
> Okay, then I have to continue with my own tool.

If you do end up developing a tool to replay a xenstore trace then I
think that'd be something great to have in tree!

> > Do you get a core dump when this happens? You might need to fiddle with
> > ulimits (some distros disable by default). IIRC there is also some /proc
> > nob which controls where core dumps go on the filesystem.
> 
> Not for that specific trace: We first enabled generating core files, but
> only then discovered that this is not enough.

How wasn't it enough? You mean you couldn't use gdb to extract a
backtrace from the core file? Or was something else wrong?

>  Then we enabled
> --trace-file, but on that host something reseted generating the core file.
> We hopefully fixed all hosts so on the next crash we hopefully will get
> both a core file and the trace.

Great.

> >> My hope would be that xenstored crashes again, because then we could use
> >> all those other tools like valgrind more easily.
> > 
> > That would be handy. My fear would be that this bug is likely to be a
> > race condition of some sort, and the granularity/accuracy of the
> > playback would possibly need to be quite high to trigger the issue.
> 
> cxenstored looks single threaded to me, or am I wrong?

Nope, you are right, my mistake.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 16:59:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 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 1XzTYC-0001x0-Qd; Fri, 12 Dec 2014 16:58:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XzTYC-0001wt-1p
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 16:58:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	A4/55-15461-3CE1B845; Fri, 12 Dec 2014 16:58:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418403518!15221565!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16475 invoked from network); 12 Dec 2014 16:58:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 16:58:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,565,1413244800"; d="scan'208";a="203547298"
Message-ID: <1418403387.16425.38.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Fri, 12 Dec 2014 16:56:27 +0000
In-Reply-To: <548B1BA8.3090504@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
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 Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
> Hello Ian,
> 
> On 12.12.2014 17:32, Ian Campbell wrote:
> > On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
> >> We did enable tracing and now have the xenstored-trace.log of one crash:
> >> It contains 1.6 billion lines and is 83 GiB.
> >> It just shows xenstored to crash on TRANSACTION_START.
> >>
> >> Is there some tool to feed that trace back into a newly launched xenstored?
> > 
> > Not that I know of I'm afraid.
> 
> Okay, then I have to continue with my own tool.

If you do end up developing a tool to replay a xenstore trace then I
think that'd be something great to have in tree!

> > Do you get a core dump when this happens? You might need to fiddle with
> > ulimits (some distros disable by default). IIRC there is also some /proc
> > nob which controls where core dumps go on the filesystem.
> 
> Not for that specific trace: We first enabled generating core files, but
> only then discovered that this is not enough.

How wasn't it enough? You mean you couldn't use gdb to extract a
backtrace from the core file? Or was something else wrong?

>  Then we enabled
> --trace-file, but on that host something reseted generating the core file.
> We hopefully fixed all hosts so on the next crash we hopefully will get
> both a core file and the trace.

Great.

> >> My hope would be that xenstored crashes again, because then we could use
> >> all those other tools like valgrind more easily.
> > 
> > That would be handy. My fear would be that this bug is likely to be a
> > race condition of some sort, and the granularity/accuracy of the
> > playback would possibly need to be quite high to trigger the issue.
> 
> cxenstored looks single threaded to me, or am I wrong?

Nope, you are right, my mistake.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 17:00:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 17:00:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzTa1-00024M-CS; Fri, 12 Dec 2014 17:00:37 +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 1XzTa0-00024F-64
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 17:00:36 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	E3/ED-11581-33F1B845; Fri, 12 Dec 2014 17:00:35 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418403635!13079800!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25485 invoked from network); 12 Dec 2014 17:00:35 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 17:00:35 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so5101574wib.1
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 09:00: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=k8AdtlCzaNruY3bA7uk1EKcu4caa7pqPQ1/zrBIV/KY=;
	b=UAqmzNoNfZ9LvA4yE/rpbjGseaWlP2D8bS++a1RekoSsgAf9zFivDGyQoxlw2CsmVv
	6uf4nwUEqopiIWFI4S9WjgAmpr3Zh0MBPXJovufOwE3sBhtqM2bG3HugjcWI6y/hubhb
	lv8HYXjry6lp9m+Tl17VpQYVMTf7oJg38BKuetgqeiWh2xVQdma9yWfPYUSkMKzn+a51
	h4Q0vXdUboYr3W2q7QqaoioMDoSkvIcG8H6xLg9+709ZgKU/L/frPiDfvTkrHl3uZ7yv
	Racs4UVRJHLFeeDmwKjz1Dixh0RgJKd2NBK2prCp/lPj6mcuhK98qi6aYCCkw8K/TkES
	vvYA==
X-Gm-Message-State: ALoCoQkVN6CkqhsWFHz+AiMi917mS3bLEIbEbpE6Y8pTSkbkMgJe91hOl0ZVGTShM12+PZN5jgb9
X-Received: by 10.194.178.231 with SMTP id db7mr28450131wjc.112.1418403634570; 
	Fri, 12 Dec 2014 09:00:34 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ef1sm2654506wic.0.2014.12.12.09.00.32
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 12 Dec 2014 09:00:33 -0800 (PST)
Message-ID: <548B1F2D.9000209@linaro.org>
Date: Fri, 12 Dec 2014 17:00:29 +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: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
	<1418395392-30460-5-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1418395392-30460-5-git-send-email-julien.grall@linaro.org>
Cc: christoffer.dall@linaro.org, stefano.stabellini@citrix.com, tim@xen.org,
	ian.campbell@citrix.com, parth.dixit@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.6 4/4] xen/arm: Find automatically a
 PPI for the DOM0 event channel interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/12/14 14:43, Julien Grall wrote:
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 7221bc8..7d14377 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -543,10 +543,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = domain_vtimer_init(d)) != 0 )
>          goto fail;
>  
> -    if ( d->domain_id )
> +    /*
> +     * The hardware domain will get a PPI later in
> +     * arch/arm/domain_build.c  depending on the
> +     * interrupt map of the hardware.
> +     */
> +    if ( !is_hardware_domain(d) )
> +    {
>          d->arch.evtchn_irq = GUEST_EVTCHN_PPI;
> -    else
> -        d->arch.evtchn_irq = platform_dom0_evtchn_ppi();
> +        /* At this stage vgic_reserve_virq should never fail */
> +        BUG_ON(vgic_reserve_virq(d, GUEST_EVTCHN_PPI));

I forgot the "!" in the BUG_ON. This line should be:

BUG_ON(!..)


-- 
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 Dec 12 17:00:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 17:00:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzTa1-00024M-CS; Fri, 12 Dec 2014 17:00:37 +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 1XzTa0-00024F-64
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 17:00:36 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	E3/ED-11581-33F1B845; Fri, 12 Dec 2014 17:00:35 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418403635!13079800!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25485 invoked from network); 12 Dec 2014 17:00:35 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 17:00:35 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so5101574wib.1
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 09:00: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=k8AdtlCzaNruY3bA7uk1EKcu4caa7pqPQ1/zrBIV/KY=;
	b=UAqmzNoNfZ9LvA4yE/rpbjGseaWlP2D8bS++a1RekoSsgAf9zFivDGyQoxlw2CsmVv
	6uf4nwUEqopiIWFI4S9WjgAmpr3Zh0MBPXJovufOwE3sBhtqM2bG3HugjcWI6y/hubhb
	lv8HYXjry6lp9m+Tl17VpQYVMTf7oJg38BKuetgqeiWh2xVQdma9yWfPYUSkMKzn+a51
	h4Q0vXdUboYr3W2q7QqaoioMDoSkvIcG8H6xLg9+709ZgKU/L/frPiDfvTkrHl3uZ7yv
	Racs4UVRJHLFeeDmwKjz1Dixh0RgJKd2NBK2prCp/lPj6mcuhK98qi6aYCCkw8K/TkES
	vvYA==
X-Gm-Message-State: ALoCoQkVN6CkqhsWFHz+AiMi917mS3bLEIbEbpE6Y8pTSkbkMgJe91hOl0ZVGTShM12+PZN5jgb9
X-Received: by 10.194.178.231 with SMTP id db7mr28450131wjc.112.1418403634570; 
	Fri, 12 Dec 2014 09:00:34 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ef1sm2654506wic.0.2014.12.12.09.00.32
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 12 Dec 2014 09:00:33 -0800 (PST)
Message-ID: <548B1F2D.9000209@linaro.org>
Date: Fri, 12 Dec 2014 17:00:29 +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: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
	<1418395392-30460-5-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1418395392-30460-5-git-send-email-julien.grall@linaro.org>
Cc: christoffer.dall@linaro.org, stefano.stabellini@citrix.com, tim@xen.org,
	ian.campbell@citrix.com, parth.dixit@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.6 4/4] xen/arm: Find automatically a
 PPI for the DOM0 event channel interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/12/14 14:43, Julien Grall wrote:
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 7221bc8..7d14377 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -543,10 +543,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = domain_vtimer_init(d)) != 0 )
>          goto fail;
>  
> -    if ( d->domain_id )
> +    /*
> +     * The hardware domain will get a PPI later in
> +     * arch/arm/domain_build.c  depending on the
> +     * interrupt map of the hardware.
> +     */
> +    if ( !is_hardware_domain(d) )
> +    {
>          d->arch.evtchn_irq = GUEST_EVTCHN_PPI;
> -    else
> -        d->arch.evtchn_irq = platform_dom0_evtchn_ppi();
> +        /* At this stage vgic_reserve_virq should never fail */
> +        BUG_ON(vgic_reserve_virq(d, GUEST_EVTCHN_PPI));

I forgot the "!" in the BUG_ON. This line should be:

BUG_ON(!..)


-- 
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 Dec 12 17:21:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 17: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 1XzTtm-0002vZ-8R; Fri, 12 Dec 2014 17:21:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1XzTtl-0002vU-15
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 17:21:01 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	FF/97-22819-CF32B845; Fri, 12 Dec 2014 17:21:00 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418404859!13065078!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18823 invoked from network); 12 Dec 2014 17:20:59 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 17:20:59 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id 62ABD10FF1D6;
	Fri, 12 Dec 2014 18:20:59 +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 3GwxGI1SwieU; Fri, 12 Dec 2014 18:20:58 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id C3C3B10FF1C5;
	Fri, 12 Dec 2014 18:20:58 +0100 (CET)
Message-ID: <548B23FA.6070108@univention.de>
Date: Fri, 12 Dec 2014 18:20:58 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>		
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>	
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com>
In-Reply-To: <1418403387.16425.38.camel@citrix.com>
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

Hello Ian,

On 12.12.2014 17:56, Ian Campbell wrote:
> On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
>> On 12.12.2014 17:32, Ian Campbell wrote:
>>> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
>>>> We did enable tracing and now have the xenstored-trace.log of one crash:
>>>> It contains 1.6 billion lines and is 83 GiB.
>>>> It just shows xenstored to crash on TRANSACTION_START.
>>>>
>>>> Is there some tool to feed that trace back into a newly launched xenstored?
>>>
>>> Not that I know of I'm afraid.
>>
>> Okay, then I have to continue with my own tool.
> 
> If you do end up developing a tool to replay a xenstore trace then I
> think that'd be something great to have in tree!

I just need to figure out how to talk to xenstored on the wire: for some
strange reason xenstored is closing the connection to the UNIX socket on
the first write inside a transaction.
Or switch to /usr/share/pyshared/xen/xend/xenstore/xstransact.py...

>>> Do you get a core dump when this happens? You might need to fiddle with
>>> ulimits (some distros disable by default). IIRC there is also some /proc
>>> nob which controls where core dumps go on the filesystem.
>>
>> Not for that specific trace: We first enabled generating core files, but
>> only then discovered that this is not enough.
> 
> How wasn't it enough? You mean you couldn't use gdb to extract a
> backtrace from the core file? Or was something else wrong?

The 1st and 2nd trace look like this: ptr in frame #2 looks very bogus.

(gdb) bt full
#0  talloc_chunk_from_ptr (ptr=0xff00000000) at talloc.c:116
        tc = <value optimized out>
#1  0x0000000000407edf in talloc_free (ptr=0xff00000000) at talloc.c:551
        tc = <value optimized out>
#2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0
"/var/lib/xenstored/tdb.0x1935bb0",
    hash_size=<value optimized out>, tdb_flags=0, open_flags=<value
optimized out>, mode=<value optimized out>,
    log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at
tdb.c:1958
        tdb = 0x1921270
        st = {st_dev = 17, st_ino = 816913342, st_nlink = 1, st_mode =
33184, st_uid = 0, st_gid = 0, __pad0 = 0,
          st_rdev = 0, st_size = 303104, st_blksize = 4096, st_blocks =
592, st_atim = {tv_sec = 1415748063,
            tv_nsec = 87562634}, st_mtim = {tv_sec = 1415748063, tv_nsec
= 87562634}, st_ctim = {
            tv_sec = 1415748063, tv_nsec = 87562634}, __unused = {0, 0, 0}}
        rev = <value optimized out>
        locked = 4232112
        vp = <value optimized out>
#3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
0xff00000000 out of bounds>, hash_size=0,
    tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
No locals.
#4  0x000000000040a70b in tdb_copy (tdb=0x192e540, outfile=0x1941fb0
"/var/lib/xenstored/tdb.0x1935bb0")
    at tdb.c:2124
        fd = <value optimized out>
        saved_errno = <value optimized out>
        copy = 0x0
#5  0x0000000000406c2d in do_transaction_start (conn=0x1939550,
in=<value optimized out>)
    at xenstored_transaction.c:164
        trans = 0x1935bb0
        exists = <value optimized out>
        id_str =
"\300L\222\001\000\000\000\000\330!@\000\000\000\000\000P\225\223\001"
#6  0x00000000004045ca in process_message (conn=0x1939550) at
xenstored_core.c:1214
        trans = <value optimized out>
#7  consider_message (conn=0x1939550) at xenstored_core.c:1261
No locals.
#8  handle_input (conn=0x1939550) at xenstored_core.c:1308
        bytes = <value optimized out>
        in = <value optimized out>
#9  0x0000000000405170 in main (argc=<value optimized out>, argv=<value
optimized out>) at xenstored_core.c:1964

A 3rd trace is somewhere completely different:
(gdb) bt
#0  0x00007fcbf066088d in _IO_vfprintf_internal (s=0x7fff46ac3010,
format=<value optimized out>, ap=0x7fff46ac3170)
    at vfprintf.c:1617
#1  0x00007fcbf0682732 in _IO_vsnprintf (string=0x7fff46ac318f "",
maxlen=<value optimized out>,
    format=0x40d4a4 "%.*s", args=0x7fff46ac3170) at vsnprintf.c:120
#2  0x000000000040855b in talloc_vasprintf (t=0x17aaf20, fmt=0x40d4a4
"%.*s", ap=0x7fff46ac31d0) at talloc.c:1104
#3  0x0000000000408666 in talloc_asprintf (t=0x1f, fmt=0xffffe938
<Address 0xffffe938 out of bounds>)
    at talloc.c:1129
#4  0x0000000000403a38 in ask_parents (conn=0x177a1f0, name=0x17aaf20
"/local/domain/0/backend/vif/1/0/accel",
    perm=XS_PERM_READ) at xenstored_core.c:492
#5  errno_from_parents (conn=0x177a1f0, name=0x17aaf20
"/local/domain/0/backend/vif/1/0/accel", perm=XS_PERM_READ)
    at xenstored_core.c:516
#6  get_node (conn=0x177a1f0, name=0x17aaf20
"/local/domain/0/backend/vif/1/0/accel", perm=XS_PERM_READ)
    at xenstored_core.c:543
#7  0x000000000040481d in do_read (conn=0x177a1f0) at xenstored_core.c:744
#8  process_message (conn=0x177a1f0) at xenstored_core.c:1178
#9  consider_message (conn=0x177a1f0) at xenstored_core.c:1261
#10 handle_input (conn=0x177a1f0) at xenstored_core.c:1308
#11 0x0000000000405170 in main (argc=<value optimized out>, argv=<value
optimized out>) at xenstored_core.c:1964


>> It might be interesting to see what happens if you preserve the db and
>> reboot arranging for the new xenstored to start with the old file. If
>> the corruption is part of the file then maybe it can be induced to crash
>> again more quickly.
> 
> Thanks for the pointer, will try.

Didn't crash immediately.
Now running /usr/share/pyshared/xen/xend/xenstore/tests/stress_xs.py for
the weekend.

Thanks again.
Philipp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 17:21:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 17: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 1XzTtm-0002vZ-8R; Fri, 12 Dec 2014 17:21:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1XzTtl-0002vU-15
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 17:21:01 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	FF/97-22819-CF32B845; Fri, 12 Dec 2014 17:21:00 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418404859!13065078!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18823 invoked from network); 12 Dec 2014 17:20:59 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Dec 2014 17:20:59 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id 62ABD10FF1D6;
	Fri, 12 Dec 2014 18:20:59 +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 3GwxGI1SwieU; Fri, 12 Dec 2014 18:20:58 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id C3C3B10FF1C5;
	Fri, 12 Dec 2014 18:20:58 +0100 (CET)
Message-ID: <548B23FA.6070108@univention.de>
Date: Fri, 12 Dec 2014 18:20:58 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>		
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>	
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com>
In-Reply-To: <1418403387.16425.38.camel@citrix.com>
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

Hello Ian,

On 12.12.2014 17:56, Ian Campbell wrote:
> On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
>> On 12.12.2014 17:32, Ian Campbell wrote:
>>> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
>>>> We did enable tracing and now have the xenstored-trace.log of one crash:
>>>> It contains 1.6 billion lines and is 83 GiB.
>>>> It just shows xenstored to crash on TRANSACTION_START.
>>>>
>>>> Is there some tool to feed that trace back into a newly launched xenstored?
>>>
>>> Not that I know of I'm afraid.
>>
>> Okay, then I have to continue with my own tool.
> 
> If you do end up developing a tool to replay a xenstore trace then I
> think that'd be something great to have in tree!

I just need to figure out how to talk to xenstored on the wire: for some
strange reason xenstored is closing the connection to the UNIX socket on
the first write inside a transaction.
Or switch to /usr/share/pyshared/xen/xend/xenstore/xstransact.py...

>>> Do you get a core dump when this happens? You might need to fiddle with
>>> ulimits (some distros disable by default). IIRC there is also some /proc
>>> nob which controls where core dumps go on the filesystem.
>>
>> Not for that specific trace: We first enabled generating core files, but
>> only then discovered that this is not enough.
> 
> How wasn't it enough? You mean you couldn't use gdb to extract a
> backtrace from the core file? Or was something else wrong?

The 1st and 2nd trace look like this: ptr in frame #2 looks very bogus.

(gdb) bt full
#0  talloc_chunk_from_ptr (ptr=0xff00000000) at talloc.c:116
        tc = <value optimized out>
#1  0x0000000000407edf in talloc_free (ptr=0xff00000000) at talloc.c:551
        tc = <value optimized out>
#2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0
"/var/lib/xenstored/tdb.0x1935bb0",
    hash_size=<value optimized out>, tdb_flags=0, open_flags=<value
optimized out>, mode=<value optimized out>,
    log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at
tdb.c:1958
        tdb = 0x1921270
        st = {st_dev = 17, st_ino = 816913342, st_nlink = 1, st_mode =
33184, st_uid = 0, st_gid = 0, __pad0 = 0,
          st_rdev = 0, st_size = 303104, st_blksize = 4096, st_blocks =
592, st_atim = {tv_sec = 1415748063,
            tv_nsec = 87562634}, st_mtim = {tv_sec = 1415748063, tv_nsec
= 87562634}, st_ctim = {
            tv_sec = 1415748063, tv_nsec = 87562634}, __unused = {0, 0, 0}}
        rev = <value optimized out>
        locked = 4232112
        vp = <value optimized out>
#3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
0xff00000000 out of bounds>, hash_size=0,
    tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
No locals.
#4  0x000000000040a70b in tdb_copy (tdb=0x192e540, outfile=0x1941fb0
"/var/lib/xenstored/tdb.0x1935bb0")
    at tdb.c:2124
        fd = <value optimized out>
        saved_errno = <value optimized out>
        copy = 0x0
#5  0x0000000000406c2d in do_transaction_start (conn=0x1939550,
in=<value optimized out>)
    at xenstored_transaction.c:164
        trans = 0x1935bb0
        exists = <value optimized out>
        id_str =
"\300L\222\001\000\000\000\000\330!@\000\000\000\000\000P\225\223\001"
#6  0x00000000004045ca in process_message (conn=0x1939550) at
xenstored_core.c:1214
        trans = <value optimized out>
#7  consider_message (conn=0x1939550) at xenstored_core.c:1261
No locals.
#8  handle_input (conn=0x1939550) at xenstored_core.c:1308
        bytes = <value optimized out>
        in = <value optimized out>
#9  0x0000000000405170 in main (argc=<value optimized out>, argv=<value
optimized out>) at xenstored_core.c:1964

A 3rd trace is somewhere completely different:
(gdb) bt
#0  0x00007fcbf066088d in _IO_vfprintf_internal (s=0x7fff46ac3010,
format=<value optimized out>, ap=0x7fff46ac3170)
    at vfprintf.c:1617
#1  0x00007fcbf0682732 in _IO_vsnprintf (string=0x7fff46ac318f "",
maxlen=<value optimized out>,
    format=0x40d4a4 "%.*s", args=0x7fff46ac3170) at vsnprintf.c:120
#2  0x000000000040855b in talloc_vasprintf (t=0x17aaf20, fmt=0x40d4a4
"%.*s", ap=0x7fff46ac31d0) at talloc.c:1104
#3  0x0000000000408666 in talloc_asprintf (t=0x1f, fmt=0xffffe938
<Address 0xffffe938 out of bounds>)
    at talloc.c:1129
#4  0x0000000000403a38 in ask_parents (conn=0x177a1f0, name=0x17aaf20
"/local/domain/0/backend/vif/1/0/accel",
    perm=XS_PERM_READ) at xenstored_core.c:492
#5  errno_from_parents (conn=0x177a1f0, name=0x17aaf20
"/local/domain/0/backend/vif/1/0/accel", perm=XS_PERM_READ)
    at xenstored_core.c:516
#6  get_node (conn=0x177a1f0, name=0x17aaf20
"/local/domain/0/backend/vif/1/0/accel", perm=XS_PERM_READ)
    at xenstored_core.c:543
#7  0x000000000040481d in do_read (conn=0x177a1f0) at xenstored_core.c:744
#8  process_message (conn=0x177a1f0) at xenstored_core.c:1178
#9  consider_message (conn=0x177a1f0) at xenstored_core.c:1261
#10 handle_input (conn=0x177a1f0) at xenstored_core.c:1308
#11 0x0000000000405170 in main (argc=<value optimized out>, argv=<value
optimized out>) at xenstored_core.c:1964


>> It might be interesting to see what happens if you preserve the db and
>> reboot arranging for the new xenstored to start with the old file. If
>> the corruption is part of the file then maybe it can be induced to crash
>> again more quickly.
> 
> Thanks for the pointer, will try.

Didn't crash immediately.
Now running /usr/share/pyshared/xen/xend/xenstore/tests/stress_xs.py for
the weekend.

Thanks again.
Philipp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 17:30:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 17:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzU2Q-0003Wq-8a; Fri, 12 Dec 2014 17:29: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 1XzU2O-0003Wl-F6
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 17:29:56 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	FB/29-29352-3162B845; Fri, 12 Dec 2014 17:29:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418405393!5503037!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5204 invoked from network); 12 Dec 2014 17:29:55 -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;
	12 Dec 2014 17:29:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,565,1413244800"; d="scan'208";a="203966535"
Message-ID: <548B25FC.6020601@citrix.com>
Date: Fri, 12 Dec 2014 17:29: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: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, David Vrabel <david.vrabel@citrix.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Boris
	Ostrovsky <boris.ostrovsky@oracle.com>
References: <548AEAE7.8020604@suse.com>
In-Reply-To: <548AEAE7.8020604@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] Xen's Linux kernel config options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/12/14 13:17, Juergen Gross wrote:
> 
> 
> As a first draft I'd suggest the following:

Some rough thoughts below.

> Option                          Selects                 Depends
> ----------------------------------------------------------------------
> XEN                             SWIOTLB_XEN(arm,arm64)

XEN should get you basic support for making hypercalls and allowing
guest to identify themselves as running on Xen.  I don't think it should
select SWIOTLB_XEN even on ARM as it is only needed for guests with
access to real hardware.

>   XEN_PV(x86)                   XEN_HAVE_PVMMU
>                                 PARAVIRT
>                                 PARAVIRT_CLOCK
>   XEN_PVH(x86)                  XEN_PVHVM
>                                 PARAVIRT
>                                 PARAVIRT_CLOCK
>   XEN_BACKEND                                           XEN_PV(x86) ||
>                                                         XEN_PVH(x86) ||
>                                                         XEN_PVHVM
>     XEN_BLKDEV_BACKEND
>     XEN_PCIDEV_BACKEND(x86)
>     XEN_SCSI_BACKEND
>     XEN_NETDEV_BACKEND
[...]
> XEN_PVHVM

Move XEN_PVHVM under XEN and have it select PARAVIRT and PARAVIRT_CLOCK.

> XEN_FRONTEND                                            XEN_PV ||
>                                                         XEN_PVH ||
>                                                         XEN_PVHVM

This enables all the basic infrastructure for frontends: event channels,
grant tables and Xenbus.

Don't make XEN_FRONTEND depend on any XEN_* variant.  It should be
possible to have frontend drivers without support for any of the
PV/PVHVM/PVH guest types.  Frontends only need event channels, grant
table and xenbus.

Perhaps have XEN_FRONTEND select XEN instead?

You need an additional option to enable the Xen platform PCI device.
This should depend on XEN_FRONTEND.

>   XEN_XENBUS_FRONTEND

Fold this into XEN_FRONTEND?

>   XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
>                                 INPUT_XEN_KBDDEV_FRONTEND
>   XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
>   HVC_XEN_FRONTEND              XEN_XENBUS_FRONTEND
>                                 HVC_XEN
>   TCG_XEN                       XEN_XENBUS_FRONTEND
>   XEN_PCIDEV_FRONTEND           PCI_XEN
>                                 XEN_XENBUS_FRONTEND
>   XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
>   INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
>   XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND
> 
> There might be some further adjustments needed (should XEN_DEV_EVTCHN
> and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The
> main difference to the current status is the XEN setting no longer
> controlling all other options.

XEN_DEV_EVTCH and XEN_GNTDEV are useful to non-backends (e.g., for
interdomain comms).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 17:30:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 17:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzU2Q-0003Wq-8a; Fri, 12 Dec 2014 17:29: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 1XzU2O-0003Wl-F6
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 17:29:56 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	FB/29-29352-3162B845; Fri, 12 Dec 2014 17:29:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418405393!5503037!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5204 invoked from network); 12 Dec 2014 17:29:55 -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;
	12 Dec 2014 17:29:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,565,1413244800"; d="scan'208";a="203966535"
Message-ID: <548B25FC.6020601@citrix.com>
Date: Fri, 12 Dec 2014 17:29: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: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, David Vrabel <david.vrabel@citrix.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Boris
	Ostrovsky <boris.ostrovsky@oracle.com>
References: <548AEAE7.8020604@suse.com>
In-Reply-To: <548AEAE7.8020604@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] Xen's Linux kernel config options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/12/14 13:17, Juergen Gross wrote:
> 
> 
> As a first draft I'd suggest the following:

Some rough thoughts below.

> Option                          Selects                 Depends
> ----------------------------------------------------------------------
> XEN                             SWIOTLB_XEN(arm,arm64)

XEN should get you basic support for making hypercalls and allowing
guest to identify themselves as running on Xen.  I don't think it should
select SWIOTLB_XEN even on ARM as it is only needed for guests with
access to real hardware.

>   XEN_PV(x86)                   XEN_HAVE_PVMMU
>                                 PARAVIRT
>                                 PARAVIRT_CLOCK
>   XEN_PVH(x86)                  XEN_PVHVM
>                                 PARAVIRT
>                                 PARAVIRT_CLOCK
>   XEN_BACKEND                                           XEN_PV(x86) ||
>                                                         XEN_PVH(x86) ||
>                                                         XEN_PVHVM
>     XEN_BLKDEV_BACKEND
>     XEN_PCIDEV_BACKEND(x86)
>     XEN_SCSI_BACKEND
>     XEN_NETDEV_BACKEND
[...]
> XEN_PVHVM

Move XEN_PVHVM under XEN and have it select PARAVIRT and PARAVIRT_CLOCK.

> XEN_FRONTEND                                            XEN_PV ||
>                                                         XEN_PVH ||
>                                                         XEN_PVHVM

This enables all the basic infrastructure for frontends: event channels,
grant tables and Xenbus.

Don't make XEN_FRONTEND depend on any XEN_* variant.  It should be
possible to have frontend drivers without support for any of the
PV/PVHVM/PVH guest types.  Frontends only need event channels, grant
table and xenbus.

Perhaps have XEN_FRONTEND select XEN instead?

You need an additional option to enable the Xen platform PCI device.
This should depend on XEN_FRONTEND.

>   XEN_XENBUS_FRONTEND

Fold this into XEN_FRONTEND?

>   XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
>                                 INPUT_XEN_KBDDEV_FRONTEND
>   XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
>   HVC_XEN_FRONTEND              XEN_XENBUS_FRONTEND
>                                 HVC_XEN
>   TCG_XEN                       XEN_XENBUS_FRONTEND
>   XEN_PCIDEV_FRONTEND           PCI_XEN
>                                 XEN_XENBUS_FRONTEND
>   XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
>   INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
>   XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND
> 
> There might be some further adjustments needed (should XEN_DEV_EVTCHN
> and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The
> main difference to the current status is the XEN setting no longer
> controlling all other options.

XEN_DEV_EVTCH and XEN_GNTDEV are useful to non-backends (e.g., for
interdomain comms).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 17:59:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 17:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzUUD-0004OX-QO; Fri, 12 Dec 2014 17:58: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 1XzUUC-0004OS-SJ
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 17:58:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6D/CD-09842-0DC2B845; Fri, 12 Dec 2014 17:58:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418407118!15234428!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 26715 invoked from network); 12 Dec 2014 17:58:39 -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;
	12 Dec 2014 17:58:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,565,1413244800"; d="scan'208";a="203976335"
Message-ID: <1418407116.16425.53.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 12 Dec 2014 17:58:36 +0000
In-Reply-To: <548B23FA.6070108@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
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

(adding Ian J who knows a bit more about C xenstored than me...)

 On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
> Hello Ian,
> 
> On 12.12.2014 17:56, Ian Campbell wrote:
> > On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
> >> On 12.12.2014 17:32, Ian Campbell wrote:
> >>> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
> >>>> We did enable tracing and now have the xenstored-trace.log of one crash:
> >>>> It contains 1.6 billion lines and is 83 GiB.
> >>>> It just shows xenstored to crash on TRANSACTION_START.
> >>>>
> >>>> Is there some tool to feed that trace back into a newly launched xenstored?
> >>>
> >>> Not that I know of I'm afraid.
> >>
> >> Okay, then I have to continue with my own tool.
> > 
> > If you do end up developing a tool to replay a xenstore trace then I
> > think that'd be something great to have in tree!
> 
> I just need to figure out how to talk to xenstored on the wire: for some
> strange reason xenstored is closing the connection to the UNIX socket on
> the first write inside a transaction.
> Or switch to /usr/share/pyshared/xen/xend/xenstore/xstransact.py...
> 
> >>> Do you get a core dump when this happens? You might need to fiddle with
> >>> ulimits (some distros disable by default). IIRC there is also some /proc
> >>> nob which controls where core dumps go on the filesystem.
> >>
> >> Not for that specific trace: We first enabled generating core files, but
> >> only then discovered that this is not enough.
> > 
> > How wasn't it enough? You mean you couldn't use gdb to extract a
> > backtrace from the core file? Or was something else wrong?
> 
> The 1st and 2nd trace look like this: ptr in frame #2 looks very bogus.
> 
> (gdb) bt full
> #0  talloc_chunk_from_ptr (ptr=0xff00000000) at talloc.c:116
>         tc = <value optimized out>
> #1  0x0000000000407edf in talloc_free (ptr=0xff00000000) at talloc.c:551
>         tc = <value optimized out>
> #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0
> "/var/lib/xenstored/tdb.0x1935bb0",

This is interesting actually. There are only a small number of calls to
talloc_free in tdb_open_ex (all wrapped in "SAFE_FREE") and they are all
in after the fail: error exit path. So I think the reason the crash is
rare is that you have to hit some other failure first.

About half of the "goto fail" statements are preceded by a TDB_LOG
statement. But given the presence of logfn=<null_log_fn> in the trace
that doesn't seem likely to be helpful right now.

It might be worth splurging some debug of your own before each of those
failure points and/or wiring up the tdb log function to xenstores
logging.

The calls to SAFE_FREE are
        SAFE_FREE(tdb->map_ptr);
        SAFE_FREE(tdb->name);
        SAFE_FREE(tdb->locked);
        SAFE_FREE(tdb);

I think those should all have been allocated by the time we get to fail
though, so not sure where 0xff000000 in the trace comes from.

I've timed out for tonight will try and have another look next week.

Ian.

>     hash_size=<value optimized out>, tdb_flags=0, open_flags=<value
> optimized out>, mode=<value optimized out>,
>     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at
> tdb.c:1958
>         tdb = 0x1921270
>         st = {st_dev = 17, st_ino = 816913342, st_nlink = 1, st_mode =
> 33184, st_uid = 0, st_gid = 0, __pad0 = 0,
>           st_rdev = 0, st_size = 303104, st_blksize = 4096, st_blocks =
> 592, st_atim = {tv_sec = 1415748063,
>             tv_nsec = 87562634}, st_mtim = {tv_sec = 1415748063, tv_nsec
> = 87562634}, st_ctim = {
>             tv_sec = 1415748063, tv_nsec = 87562634}, __unused = {0, 0, 0}}
>         rev = <value optimized out>
>         locked = 4232112
>         vp = <value optimized out>
> #3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
> 0xff00000000 out of bounds>, hash_size=0,
>     tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
> No locals.
> #4  0x000000000040a70b in tdb_copy (tdb=0x192e540, outfile=0x1941fb0
> "/var/lib/xenstored/tdb.0x1935bb0")
>     at tdb.c:2124
>         fd = <value optimized out>
>         saved_errno = <value optimized out>
>         copy = 0x0
> #5  0x0000000000406c2d in do_transaction_start (conn=0x1939550,
> in=<value optimized out>)
>     at xenstored_transaction.c:164
>         trans = 0x1935bb0
>         exists = <value optimized out>
>         id_str =
> "\300L\222\001\000\000\000\000\330!@\000\000\000\000\000P\225\223\001"
> #6  0x00000000004045ca in process_message (conn=0x1939550) at
> xenstored_core.c:1214
>         trans = <value optimized out>
> #7  consider_message (conn=0x1939550) at xenstored_core.c:1261
> No locals.
> #8  handle_input (conn=0x1939550) at xenstored_core.c:1308
>         bytes = <value optimized out>
>         in = <value optimized out>
> #9  0x0000000000405170 in main (argc=<value optimized out>, argv=<value
> optimized out>) at xenstored_core.c:1964
> 
> A 3rd trace is somewhere completely different:
> (gdb) bt
> #0  0x00007fcbf066088d in _IO_vfprintf_internal (s=0x7fff46ac3010,
> format=<value optimized out>, ap=0x7fff46ac3170)
>     at vfprintf.c:1617
> #1  0x00007fcbf0682732 in _IO_vsnprintf (string=0x7fff46ac318f "",
> maxlen=<value optimized out>,
>     format=0x40d4a4 "%.*s", args=0x7fff46ac3170) at vsnprintf.c:120
> #2  0x000000000040855b in talloc_vasprintf (t=0x17aaf20, fmt=0x40d4a4
> "%.*s", ap=0x7fff46ac31d0) at talloc.c:1104
> #3  0x0000000000408666 in talloc_asprintf (t=0x1f, fmt=0xffffe938
> <Address 0xffffe938 out of bounds>)
>     at talloc.c:1129
> #4  0x0000000000403a38 in ask_parents (conn=0x177a1f0, name=0x17aaf20
> "/local/domain/0/backend/vif/1/0/accel",
>     perm=XS_PERM_READ) at xenstored_core.c:492
> #5  errno_from_parents (conn=0x177a1f0, name=0x17aaf20
> "/local/domain/0/backend/vif/1/0/accel", perm=XS_PERM_READ)
>     at xenstored_core.c:516
> #6  get_node (conn=0x177a1f0, name=0x17aaf20
> "/local/domain/0/backend/vif/1/0/accel", perm=XS_PERM_READ)
>     at xenstored_core.c:543
> #7  0x000000000040481d in do_read (conn=0x177a1f0) at xenstored_core.c:744
> #8  process_message (conn=0x177a1f0) at xenstored_core.c:1178
> #9  consider_message (conn=0x177a1f0) at xenstored_core.c:1261
> #10 handle_input (conn=0x177a1f0) at xenstored_core.c:1308
> #11 0x0000000000405170 in main (argc=<value optimized out>, argv=<value
> optimized out>) at xenstored_core.c:1964
> 
> 
> >> It might be interesting to see what happens if you preserve the db and
> >> reboot arranging for the new xenstored to start with the old file. If
> >> the corruption is part of the file then maybe it can be induced to crash
> >> again more quickly.
> > 
> > Thanks for the pointer, will try.
> 
> Didn't crash immediately.
> Now running /usr/share/pyshared/xen/xend/xenstore/tests/stress_xs.py for
> the weekend.
> 
> Thanks again.
> Philipp
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 12 17:59:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 17:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzUUD-0004OX-QO; Fri, 12 Dec 2014 17:58: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 1XzUUC-0004OS-SJ
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 17:58:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6D/CD-09842-0DC2B845; Fri, 12 Dec 2014 17:58:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418407118!15234428!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 26715 invoked from network); 12 Dec 2014 17:58:39 -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;
	12 Dec 2014 17:58:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,565,1413244800"; d="scan'208";a="203976335"
Message-ID: <1418407116.16425.53.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 12 Dec 2014 17:58:36 +0000
In-Reply-To: <548B23FA.6070108@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
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

(adding Ian J who knows a bit more about C xenstored than me...)

 On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
> Hello Ian,
> 
> On 12.12.2014 17:56, Ian Campbell wrote:
> > On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
> >> On 12.12.2014 17:32, Ian Campbell wrote:
> >>> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
> >>>> We did enable tracing and now have the xenstored-trace.log of one crash:
> >>>> It contains 1.6 billion lines and is 83 GiB.
> >>>> It just shows xenstored to crash on TRANSACTION_START.
> >>>>
> >>>> Is there some tool to feed that trace back into a newly launched xenstored?
> >>>
> >>> Not that I know of I'm afraid.
> >>
> >> Okay, then I have to continue with my own tool.
> > 
> > If you do end up developing a tool to replay a xenstore trace then I
> > think that'd be something great to have in tree!
> 
> I just need to figure out how to talk to xenstored on the wire: for some
> strange reason xenstored is closing the connection to the UNIX socket on
> the first write inside a transaction.
> Or switch to /usr/share/pyshared/xen/xend/xenstore/xstransact.py...
> 
> >>> Do you get a core dump when this happens? You might need to fiddle with
> >>> ulimits (some distros disable by default). IIRC there is also some /proc
> >>> nob which controls where core dumps go on the filesystem.
> >>
> >> Not for that specific trace: We first enabled generating core files, but
> >> only then discovered that this is not enough.
> > 
> > How wasn't it enough? You mean you couldn't use gdb to extract a
> > backtrace from the core file? Or was something else wrong?
> 
> The 1st and 2nd trace look like this: ptr in frame #2 looks very bogus.
> 
> (gdb) bt full
> #0  talloc_chunk_from_ptr (ptr=0xff00000000) at talloc.c:116
>         tc = <value optimized out>
> #1  0x0000000000407edf in talloc_free (ptr=0xff00000000) at talloc.c:551
>         tc = <value optimized out>
> #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0
> "/var/lib/xenstored/tdb.0x1935bb0",

This is interesting actually. There are only a small number of calls to
talloc_free in tdb_open_ex (all wrapped in "SAFE_FREE") and they are all
in after the fail: error exit path. So I think the reason the crash is
rare is that you have to hit some other failure first.

About half of the "goto fail" statements are preceded by a TDB_LOG
statement. But given the presence of logfn=<null_log_fn> in the trace
that doesn't seem likely to be helpful right now.

It might be worth splurging some debug of your own before each of those
failure points and/or wiring up the tdb log function to xenstores
logging.

The calls to SAFE_FREE are
        SAFE_FREE(tdb->map_ptr);
        SAFE_FREE(tdb->name);
        SAFE_FREE(tdb->locked);
        SAFE_FREE(tdb);

I think those should all have been allocated by the time we get to fail
though, so not sure where 0xff000000 in the trace comes from.

I've timed out for tonight will try and have another look next week.

Ian.

>     hash_size=<value optimized out>, tdb_flags=0, open_flags=<value
> optimized out>, mode=<value optimized out>,
>     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at
> tdb.c:1958
>         tdb = 0x1921270
>         st = {st_dev = 17, st_ino = 816913342, st_nlink = 1, st_mode =
> 33184, st_uid = 0, st_gid = 0, __pad0 = 0,
>           st_rdev = 0, st_size = 303104, st_blksize = 4096, st_blocks =
> 592, st_atim = {tv_sec = 1415748063,
>             tv_nsec = 87562634}, st_mtim = {tv_sec = 1415748063, tv_nsec
> = 87562634}, st_ctim = {
>             tv_sec = 1415748063, tv_nsec = 87562634}, __unused = {0, 0, 0}}
>         rev = <value optimized out>
>         locked = 4232112
>         vp = <value optimized out>
> #3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
> 0xff00000000 out of bounds>, hash_size=0,
>     tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
> No locals.
> #4  0x000000000040a70b in tdb_copy (tdb=0x192e540, outfile=0x1941fb0
> "/var/lib/xenstored/tdb.0x1935bb0")
>     at tdb.c:2124
>         fd = <value optimized out>
>         saved_errno = <value optimized out>
>         copy = 0x0
> #5  0x0000000000406c2d in do_transaction_start (conn=0x1939550,
> in=<value optimized out>)
>     at xenstored_transaction.c:164
>         trans = 0x1935bb0
>         exists = <value optimized out>
>         id_str =
> "\300L\222\001\000\000\000\000\330!@\000\000\000\000\000P\225\223\001"
> #6  0x00000000004045ca in process_message (conn=0x1939550) at
> xenstored_core.c:1214
>         trans = <value optimized out>
> #7  consider_message (conn=0x1939550) at xenstored_core.c:1261
> No locals.
> #8  handle_input (conn=0x1939550) at xenstored_core.c:1308
>         bytes = <value optimized out>
>         in = <value optimized out>
> #9  0x0000000000405170 in main (argc=<value optimized out>, argv=<value
> optimized out>) at xenstored_core.c:1964
> 
> A 3rd trace is somewhere completely different:
> (gdb) bt
> #0  0x00007fcbf066088d in _IO_vfprintf_internal (s=0x7fff46ac3010,
> format=<value optimized out>, ap=0x7fff46ac3170)
>     at vfprintf.c:1617
> #1  0x00007fcbf0682732 in _IO_vsnprintf (string=0x7fff46ac318f "",
> maxlen=<value optimized out>,
>     format=0x40d4a4 "%.*s", args=0x7fff46ac3170) at vsnprintf.c:120
> #2  0x000000000040855b in talloc_vasprintf (t=0x17aaf20, fmt=0x40d4a4
> "%.*s", ap=0x7fff46ac31d0) at talloc.c:1104
> #3  0x0000000000408666 in talloc_asprintf (t=0x1f, fmt=0xffffe938
> <Address 0xffffe938 out of bounds>)
>     at talloc.c:1129
> #4  0x0000000000403a38 in ask_parents (conn=0x177a1f0, name=0x17aaf20
> "/local/domain/0/backend/vif/1/0/accel",
>     perm=XS_PERM_READ) at xenstored_core.c:492
> #5  errno_from_parents (conn=0x177a1f0, name=0x17aaf20
> "/local/domain/0/backend/vif/1/0/accel", perm=XS_PERM_READ)
>     at xenstored_core.c:516
> #6  get_node (conn=0x177a1f0, name=0x17aaf20
> "/local/domain/0/backend/vif/1/0/accel", perm=XS_PERM_READ)
>     at xenstored_core.c:543
> #7  0x000000000040481d in do_read (conn=0x177a1f0) at xenstored_core.c:744
> #8  process_message (conn=0x177a1f0) at xenstored_core.c:1178
> #9  consider_message (conn=0x177a1f0) at xenstored_core.c:1261
> #10 handle_input (conn=0x177a1f0) at xenstored_core.c:1308
> #11 0x0000000000405170 in main (argc=<value optimized out>, argv=<value
> optimized out>) at xenstored_core.c:1964
> 
> 
> >> It might be interesting to see what happens if you preserve the db and
> >> reboot arranging for the new xenstored to start with the old file. If
> >> the corruption is part of the file then maybe it can be induced to crash
> >> again more quickly.
> > 
> > Thanks for the pointer, will try.
> 
> Didn't crash immediately.
> Now running /usr/share/pyshared/xen/xend/xenstore/tests/stress_xs.py for
> the weekend.
> 
> Thanks again.
> Philipp
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 12 18:26:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 18:26:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzUvC-0005H5-82; Fri, 12 Dec 2014 18:26: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 1XzUvA-0005H0-G9
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 18:26:32 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	55/EE-02696-7533B845; Fri, 12 Dec 2014 18:26:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418408789!14780459!1
X-Originating-IP: [66.165.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 5297 invoked from network); 12 Dec 2014 18:26:31 -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;
	12 Dec 2014 18:26:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,565,1413244800"; d="scan'208";a="203585816"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Fri, 12 Dec 2014 13:26: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
	1XzUuh-0000TG-65; Fri, 12 Dec 2014 18:26:03 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Fri, 12 Dec 2014 18:26:02 +0000
Message-ID: <1418408762-9691-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>,
	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: Minor formatting
	fixes and 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

`font` had a trailing single quote which was out of place.

`gnttab_max_frames` was missing escapes for the underscores which caused the
underscores to take their markdown meaning, causing 'max' in the middle to be
italicised.  Escape the underscores, and make all command line parameters
bold, to be consistent with the existing style.

Clarify how the default for `nmi` changes between debug and non debug builds
of Xen.

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>

---
Requesting for 4.5, under the "strictly a documentation change" allowance
---
 docs/misc/xen-command-line.markdown |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 1e8c024..152ae03 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -614,7 +614,7 @@ to use the default.
 > `= <integer>`
 
 ### font
-> `= <height>` where height is `8x8 | 8x14 | 8x16 '`
+> `= <height>` where height is `8x8 | 8x14 | 8x16`
 
 Specify the font size when using the VESA console driver.
 
@@ -648,13 +648,13 @@ Specify the maximum number of frames per grant table operation.
 > `= <integer>`
 
 Specify the maximum number of maptrack frames domain.
-The default value is 8 times gnttab_max_frames.
+The default value is 8 times **gnttab\_max\_frames**.
 
 ### gnttab\_max\_nr\_frames
 > `= <integer>`
 
 *Deprecated*
-Use gnttab\_max\_frames and gnttab\_max\_maptrack\_frames instead.
+Use **gnttab\_max\_frames** and **gnttab\_max\_maptrack\_frames** instead.
 
 Specify the maximum number of frames per grant table operation and the
 maximum number of maptrack frames domain.
@@ -986,7 +986,7 @@ of the ACPI based one.
 ### nmi
 > `= ignore | dom0 | fatal`
 
-> Default: `nmi=fatal`
+> Default: `fatal` for a debug build, or `dom0` for a non-debug build
 
 Specify what Xen should do in the event of an NMI parity or I/O error.
 `ignore` discards the error; `dom0` causes Xen to report the error 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 Dec 12 18:26:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 18:26:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzUvC-0005H5-82; Fri, 12 Dec 2014 18:26: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 1XzUvA-0005H0-G9
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 18:26:32 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	55/EE-02696-7533B845; Fri, 12 Dec 2014 18:26:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418408789!14780459!1
X-Originating-IP: [66.165.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 5297 invoked from network); 12 Dec 2014 18:26:31 -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;
	12 Dec 2014 18:26:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,565,1413244800"; d="scan'208";a="203585816"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Fri, 12 Dec 2014 13:26: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
	1XzUuh-0000TG-65; Fri, 12 Dec 2014 18:26:03 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Date: Fri, 12 Dec 2014 18:26:02 +0000
Message-ID: <1418408762-9691-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>,
	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: Minor formatting
	fixes and 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

`font` had a trailing single quote which was out of place.

`gnttab_max_frames` was missing escapes for the underscores which caused the
underscores to take their markdown meaning, causing 'max' in the middle to be
italicised.  Escape the underscores, and make all command line parameters
bold, to be consistent with the existing style.

Clarify how the default for `nmi` changes between debug and non debug builds
of Xen.

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>

---
Requesting for 4.5, under the "strictly a documentation change" allowance
---
 docs/misc/xen-command-line.markdown |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 1e8c024..152ae03 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -614,7 +614,7 @@ to use the default.
 > `= <integer>`
 
 ### font
-> `= <height>` where height is `8x8 | 8x14 | 8x16 '`
+> `= <height>` where height is `8x8 | 8x14 | 8x16`
 
 Specify the font size when using the VESA console driver.
 
@@ -648,13 +648,13 @@ Specify the maximum number of frames per grant table operation.
 > `= <integer>`
 
 Specify the maximum number of maptrack frames domain.
-The default value is 8 times gnttab_max_frames.
+The default value is 8 times **gnttab\_max\_frames**.
 
 ### gnttab\_max\_nr\_frames
 > `= <integer>`
 
 *Deprecated*
-Use gnttab\_max\_frames and gnttab\_max\_maptrack\_frames instead.
+Use **gnttab\_max\_frames** and **gnttab\_max\_maptrack\_frames** instead.
 
 Specify the maximum number of frames per grant table operation and the
 maximum number of maptrack frames domain.
@@ -986,7 +986,7 @@ of the ACPI based one.
 ### nmi
 > `= ignore | dom0 | fatal`
 
-> Default: `nmi=fatal`
+> Default: `fatal` for a debug build, or `dom0` for a non-debug build
 
 Specify what Xen should do in the event of an NMI parity or I/O error.
 `ignore` discards the error; `dom0` causes Xen to report the error 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 Dec 12 19:14:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 19: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 1XzVei-0006YP-49; Fri, 12 Dec 2014 19:13:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tlviewer@yahoo.com>) id 1XzVeh-0006YK-Ij
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 19:13:35 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	D5/B8-16982-E5E3B845; Fri, 12 Dec 2014 19:13:34 +0000
X-Env-Sender: tlviewer@yahoo.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418411612!12956402!1
X-Originating-IP: [216.109.114.223]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_YAHOO_RCVD,
	HTML_50_60,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11988 invoked from network); 12 Dec 2014 19:13:33 -0000
Received: from nm43-vm4.bullet.mail.bf1.yahoo.com (HELO
	nm43-vm4.bullet.mail.bf1.yahoo.com) (216.109.114.223)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 19:13:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
	t=1418411612; bh=OmdD6bovp9h3w48KF6NkUPQsqCCct8hfRcRPci5aTLc=;
	h=Date:From:Reply-To:To:Subject:From:Subject;
	b=nS5QkhAhnYjKHRXFfB5Tat4tHBNcm/XdjUkE3aQzZaQbp/YQ6KQIQ7VdoB0eaUFagRFfxPtGWsWFCble2ZObF2UJqvovs/q79SNHhAHKpAFYiztFvVlLQjjKaP4SqpCPMLd0VPvtwmB8WTr//pCyAYBnjcYY0mxwhVIRub0ktzVxn94Hl9vNo0Mn8xkh0bZg8N3qv0UMDLuZfIB5oHPMrzdOnJgA9RWZuaq8d/HBqnXobCjCFW6WijOwm/qMSQF64FFNuPGwchcMVD/NS3PmGBvGaxQNVvbF4XZvJCTTmcIGKXZU01VQr5Vge7WTpdYLWT1yfgv6/AjPyuZVi4Z1fg==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com;
	b=NtKh5t+MqhCKQp79UXmfooMdp0Fm2ZoIcE6lOuw+e524Ity9t5VbDQCML/8UI+BEfiZShsTf1Spi4bVLWMmGqcsbagjBa1TpsenD1kZAW7JwYJmvQbmI+bmkyz2O00r23/LFUkw94WKVQt0v/B02RThMzVeVXTa6GFstNiLQxIw+LIIHj6qdnYOkNBdBatIboEOSuGEM5HcRYJ/gZlLcd8WCvzxB0ZrsCS7G/uyGDt1GWsubDaRR1SKWMfqz3ubYyEvb/6P9l2ldY5pbuuXXVea801yB5xHURMmop0AbSCZo9wNEO0zca5o6aOxto6xXNsutd3ICUJwWC20giUHF2Q==;
Received: from [98.139.215.143] by nm43.bullet.mail.bf1.yahoo.com with NNFMP;
	12 Dec 2014 19:13:32 -0000
Received: from [98.139.212.192] by tm14.bullet.mail.bf1.yahoo.com with NNFMP;
	12 Dec 2014 19:13:32 -0000
Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP;
	12 Dec 2014 19:13:32 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 17055.5266.bm@omp1001.mail.bf1.yahoo.com
X-YMail-OSG: mOlrifcVM1mr5tPj0Q1ZyPJ0ApW5Ox3XHcIcnMzp9Mf9gdfOtB2n8zrARDJjQhs
	mw2f6oZe9hqJX9OKPOzVmEUUEVp3d0hu6HpwWCbGIz8URfdiN3K4MxiOyX8Al8cLnjlSScOBsaG9
	SVuZqcDK_pwqyWnzFUjmUOfKTIHsIDER7qe8FI09FnCXaS8VXLn_Aahp_DaPYtnQUdrJEuqOGtTF
	PHQ1edXO1Db5x5_sG3l8HoR.NnOe4r7PhMO9Kn3hy3xEQ84JQkwdIvBS2kEDj9FI6WFijdBn1U9E
	mbBPM.QWs_9COtluFiQxFOAh8Q1XnNXaMOBEGGThOPkJjafnSp.O_YGdvhQwghvFPUtvCsLJC2s1
	uQFEnn0Kozh2N.MGAXwK_7ocVicIj7MgcOAJ8Jk2HzpbozMXcFERn3EAVO8G1PSCpC.xYTe9J8y1
	cFQwMy4Dx_wjZIFbaZCJK3FyJtepaNHSAcCO1urEVTaixU9wKO0yzq6oB_u1MOzXR5YNXhSg-
Received: by 66.196.80.150; Fri, 12 Dec 2014 19:13:31 +0000 
Date: Fri, 12 Dec 2014 19:13:31 +0000 (UTC)
From: Mark Pryor <tlviewer@yahoo.com>
To: Xen-devel <xen-devel@lists.xen.org>
Message-ID: <1701008001.9091123.1418411611015.JavaMail.yahoo@jws10667.mail.bf1.yahoo.com>
MIME-Version: 1.0
Content-Length: 2109
Subject: [Xen-devel] does rdname() in xendomains follow symlink?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mark Pryor <tlviewer@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3516514716031756160=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3516514716031756160==
Content-Type: multipart/alternative; 
	boundary="----=_Part_9091122_1883400938.1418411611008"
Content-Length: 1620

------=_Part_9091122_1883400938.1418411611008
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I am testing 4.5 (HEAD) in deb8 and noticed some problems with xendomains(g=
it path):=C2=A0 ./tools/hotplug/Linux/xendomains

when trying to get the name from the JSON config it ends up with the symlin=
k name instead. Thismay not show up as a bug unless you use symlinks in /et=
c/xen/auto, like me.
I think I can fix this, but I have no business submitting a patch for a blu=
e-chip project.
thanks for developer attention on this,Mark

------=_Part_9091122_1883400938.1418411611008
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1418411373370_2378">I am testing 4.5 (HEAD) in deb8 and noticed some problems with xendomains</div><div>(git path):&nbsp; ./tools/hotplug/Linux/xendomains<br></div><div id="yui_3_16_0_1_1418411373370_2365"><br></div><div dir="ltr">when trying to get the name from the JSON config it ends up with the symlink name instead. This</div><div dir="ltr">may not show up as a bug unless you use symlinks in /etc/xen/auto, like me.</div><div dir="ltr"><br></div><div dir="ltr">I think I can fix this, but I have no business submitting a patch for a blue-chip project.</div><div dir="ltr"><br></div><div dir="ltr">thanks for developer attention on this,</div><div dir="ltr">Mark<br></div></div></body></html>
------=_Part_9091122_1883400938.1418411611008--


--===============3516514716031756160==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3516514716031756160==--


From xen-devel-bounces@lists.xen.org Fri Dec 12 19:14:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 19: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 1XzVei-0006YP-49; Fri, 12 Dec 2014 19:13:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tlviewer@yahoo.com>) id 1XzVeh-0006YK-Ij
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 19:13:35 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	D5/B8-16982-E5E3B845; Fri, 12 Dec 2014 19:13:34 +0000
X-Env-Sender: tlviewer@yahoo.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418411612!12956402!1
X-Originating-IP: [216.109.114.223]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_YAHOO_RCVD,
	HTML_50_60,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11988 invoked from network); 12 Dec 2014 19:13:33 -0000
Received: from nm43-vm4.bullet.mail.bf1.yahoo.com (HELO
	nm43-vm4.bullet.mail.bf1.yahoo.com) (216.109.114.223)
	by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 19:13:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
	t=1418411612; bh=OmdD6bovp9h3w48KF6NkUPQsqCCct8hfRcRPci5aTLc=;
	h=Date:From:Reply-To:To:Subject:From:Subject;
	b=nS5QkhAhnYjKHRXFfB5Tat4tHBNcm/XdjUkE3aQzZaQbp/YQ6KQIQ7VdoB0eaUFagRFfxPtGWsWFCble2ZObF2UJqvovs/q79SNHhAHKpAFYiztFvVlLQjjKaP4SqpCPMLd0VPvtwmB8WTr//pCyAYBnjcYY0mxwhVIRub0ktzVxn94Hl9vNo0Mn8xkh0bZg8N3qv0UMDLuZfIB5oHPMrzdOnJgA9RWZuaq8d/HBqnXobCjCFW6WijOwm/qMSQF64FFNuPGwchcMVD/NS3PmGBvGaxQNVvbF4XZvJCTTmcIGKXZU01VQr5Vge7WTpdYLWT1yfgv6/AjPyuZVi4Z1fg==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com;
	b=NtKh5t+MqhCKQp79UXmfooMdp0Fm2ZoIcE6lOuw+e524Ity9t5VbDQCML/8UI+BEfiZShsTf1Spi4bVLWMmGqcsbagjBa1TpsenD1kZAW7JwYJmvQbmI+bmkyz2O00r23/LFUkw94WKVQt0v/B02RThMzVeVXTa6GFstNiLQxIw+LIIHj6qdnYOkNBdBatIboEOSuGEM5HcRYJ/gZlLcd8WCvzxB0ZrsCS7G/uyGDt1GWsubDaRR1SKWMfqz3ubYyEvb/6P9l2ldY5pbuuXXVea801yB5xHURMmop0AbSCZo9wNEO0zca5o6aOxto6xXNsutd3ICUJwWC20giUHF2Q==;
Received: from [98.139.215.143] by nm43.bullet.mail.bf1.yahoo.com with NNFMP;
	12 Dec 2014 19:13:32 -0000
Received: from [98.139.212.192] by tm14.bullet.mail.bf1.yahoo.com with NNFMP;
	12 Dec 2014 19:13:32 -0000
Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP;
	12 Dec 2014 19:13:32 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 17055.5266.bm@omp1001.mail.bf1.yahoo.com
X-YMail-OSG: mOlrifcVM1mr5tPj0Q1ZyPJ0ApW5Ox3XHcIcnMzp9Mf9gdfOtB2n8zrARDJjQhs
	mw2f6oZe9hqJX9OKPOzVmEUUEVp3d0hu6HpwWCbGIz8URfdiN3K4MxiOyX8Al8cLnjlSScOBsaG9
	SVuZqcDK_pwqyWnzFUjmUOfKTIHsIDER7qe8FI09FnCXaS8VXLn_Aahp_DaPYtnQUdrJEuqOGtTF
	PHQ1edXO1Db5x5_sG3l8HoR.NnOe4r7PhMO9Kn3hy3xEQ84JQkwdIvBS2kEDj9FI6WFijdBn1U9E
	mbBPM.QWs_9COtluFiQxFOAh8Q1XnNXaMOBEGGThOPkJjafnSp.O_YGdvhQwghvFPUtvCsLJC2s1
	uQFEnn0Kozh2N.MGAXwK_7ocVicIj7MgcOAJ8Jk2HzpbozMXcFERn3EAVO8G1PSCpC.xYTe9J8y1
	cFQwMy4Dx_wjZIFbaZCJK3FyJtepaNHSAcCO1urEVTaixU9wKO0yzq6oB_u1MOzXR5YNXhSg-
Received: by 66.196.80.150; Fri, 12 Dec 2014 19:13:31 +0000 
Date: Fri, 12 Dec 2014 19:13:31 +0000 (UTC)
From: Mark Pryor <tlviewer@yahoo.com>
To: Xen-devel <xen-devel@lists.xen.org>
Message-ID: <1701008001.9091123.1418411611015.JavaMail.yahoo@jws10667.mail.bf1.yahoo.com>
MIME-Version: 1.0
Content-Length: 2109
Subject: [Xen-devel] does rdname() in xendomains follow symlink?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mark Pryor <tlviewer@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3516514716031756160=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3516514716031756160==
Content-Type: multipart/alternative; 
	boundary="----=_Part_9091122_1883400938.1418411611008"
Content-Length: 1620

------=_Part_9091122_1883400938.1418411611008
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I am testing 4.5 (HEAD) in deb8 and noticed some problems with xendomains(g=
it path):=C2=A0 ./tools/hotplug/Linux/xendomains

when trying to get the name from the JSON config it ends up with the symlin=
k name instead. Thismay not show up as a bug unless you use symlinks in /et=
c/xen/auto, like me.
I think I can fix this, but I have no business submitting a patch for a blu=
e-chip project.
thanks for developer attention on this,Mark

------=_Part_9091122_1883400938.1418411611008
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1418411373370_2378">I am testing 4.5 (HEAD) in deb8 and noticed some problems with xendomains</div><div>(git path):&nbsp; ./tools/hotplug/Linux/xendomains<br></div><div id="yui_3_16_0_1_1418411373370_2365"><br></div><div dir="ltr">when trying to get the name from the JSON config it ends up with the symlink name instead. This</div><div dir="ltr">may not show up as a bug unless you use symlinks in /etc/xen/auto, like me.</div><div dir="ltr"><br></div><div dir="ltr">I think I can fix this, but I have no business submitting a patch for a blue-chip project.</div><div dir="ltr"><br></div><div dir="ltr">thanks for developer attention on this,</div><div dir="ltr">Mark<br></div></div></body></html>
------=_Part_9091122_1883400938.1418411611008--


--===============3516514716031756160==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3516514716031756160==--


From xen-devel-bounces@lists.xen.org Fri Dec 12 20:47:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 20:47:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzX6x-0000BY-HJ; Fri, 12 Dec 2014 20:46:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rientjes@google.com>) id 1XzX6v-0000BS-R7
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 20:46:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4B/8B-09842-8345B845; Fri, 12 Dec 2014 20:46:48 +0000
X-Env-Sender: rientjes@google.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418417206!15291967!1
X-Originating-IP: [209.85.223.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17582 invoked from network); 12 Dec 2014 20:46:47 -0000
Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com)
	(209.85.223.169)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 20:46:47 -0000
Received: by mail-ie0-f169.google.com with SMTP id y20so7748539ier.28
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 12:46:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:to:cc:subject:in-reply-to:message-id:references
	:user-agent:mime-version:content-type;
	bh=vTYlEGoeASs622lcFWhWhnQc4A1GfggD9GVeiJKuyu0=;
	b=Effpc1YPuUCR89xd8uB0hCU61FUGIL70qTKRBZzcKJ//t7F+Ltpifhs65o9W1Jf5cH
	HxAk4Htdziuofn6mCdAi0lqmEizCl5G5hWfwfV2dCBiPeF6YPwALvVPUL4IM4j8aQ7qR
	nxGFls7ioLZH6aPAthyjrqGwfVoHMiCnPnWPhiGnprJC//lrAl3564os+PKnCqh4M7OR
	uFH12A1jTU6MD65Rzc6yDXkcyCo1AEFdI0tdXS3VeA2O92fH0y6oayd7m5at+hcK4KY9
	fyor8SD5i8VysXKTQ1fZU8pB0u1E+U/SdatMPF4ezvwff8meOTp6XJHwnk9d2MVJOblV
	d7Sg==
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:in-reply-to:message-id
	:references:user-agent:mime-version:content-type;
	bh=vTYlEGoeASs622lcFWhWhnQc4A1GfggD9GVeiJKuyu0=;
	b=HjAhvrPodglMNSfhzduud3hhTUv/8tKxhKjDZqp0MCPvXMSplBOshNqtVT8kTTvzli
	TrFJmBcOOKciUUXyrV+GcvRhzNmVxpQ8Acptu5U6AbaMzF2SJeUy0lN8VG2jskbZW96Z
	SebLkB34amKP2uo2hxalvepbceKMaRPRFbjyy8UqbuOB488P9N1zZt+nrd0ImOqfqk9F
	3dY+m2ijMx75wzjngIJGawgyFf2kzaKc5RTvEjhtRUxvuf8USELH8uDpTiwQcYBA414/
	7GcpRIOfmXc5E4COM4xNAqVSU/1grNsxjpB/FibAnI3nL9OPbQLm/74M4QtX4yW54S1B
	P4JQ==
X-Gm-Message-State: ALoCoQl2TJU8JMkuXJwNWMjh0X7u65qBVhbWETi2pyvkeuO0FPVHS7fuX3EQZXiYkm/cMiublWgQ
X-Received: by 10.42.129.140 with SMTP id q12mr17693570ics.68.1418417206122;
	Fri, 12 Dec 2014 12:46:46 -0800 (PST)
Received: from [2620:0:1008:1101:f51b:f61e:9c94:f441]
	([2620:0:1008:1101:f51b:f61e:9c94:f441])
	by mx.google.com with ESMTPSA id b2sm1144045ioe.2.2014.12.12.12.46.42
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 12 Dec 2014 12:46:43 -0800 (PST)
Date: Fri, 12 Dec 2014 12:46:42 -0800 (PST)
From: David Rientjes <rientjes@google.com>
X-X-Sender: rientjes@chino.kir.corp.google.com
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
In-Reply-To: <1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
Message-ID: <alpine.DEB.2.10.1412121246250.2273@chino.kir.corp.google.com>
References: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
	<1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	josh@joshtriplett.org, linux-kernel@vger.kernel.org,
	Pekka Enberg <penberg@kernel.org>, mtosatti@redhat.com,
	fengguang.wu@intel.com, levinsasha928@gmail.com, hpa@zytor.com,
	xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>,
	sam@ravnborg.org, David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86, arm, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 9 Dec 2014, Luis R. Rodriguez wrote:

> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> This lets you build a kernel which can support xen dom0
> or xen guests by just using:
> 
>    make xenconfig
> 
> on both x86 and arm64 kernels. This also splits out the
> options which are available currently to be built with x86
> and 'make ARCH=arm64' under a shared config.
> 
> Technically xen supports a dom0 kernel and also a guest
> kernel configuration but upon review with the xen team
> since we don't have many dom0 options its best to just
> combine these two into one.
> 
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Pekka Enberg <penberg@kernel.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Michal Marek <mmarek@suse.cz>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: penberg@kernel.org
> Cc: levinsasha928@gmail.com
> Cc: mtosatti@redhat.com
> Cc: fengguang.wu@intel.com
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xenproject.org
> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>

Acked-by: David Rientjes <rientjes@google.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 20:47:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 20:47:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzX6x-0000BY-HJ; Fri, 12 Dec 2014 20:46:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rientjes@google.com>) id 1XzX6v-0000BS-R7
	for xen-devel@lists.xenproject.org; Fri, 12 Dec 2014 20:46:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4B/8B-09842-8345B845; Fri, 12 Dec 2014 20:46:48 +0000
X-Env-Sender: rientjes@google.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418417206!15291967!1
X-Originating-IP: [209.85.223.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17582 invoked from network); 12 Dec 2014 20:46:47 -0000
Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com)
	(209.85.223.169)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 20:46:47 -0000
Received: by mail-ie0-f169.google.com with SMTP id y20so7748539ier.28
	for <xen-devel@lists.xenproject.org>;
	Fri, 12 Dec 2014 12:46:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=date:from:to:cc:subject:in-reply-to:message-id:references
	:user-agent:mime-version:content-type;
	bh=vTYlEGoeASs622lcFWhWhnQc4A1GfggD9GVeiJKuyu0=;
	b=Effpc1YPuUCR89xd8uB0hCU61FUGIL70qTKRBZzcKJ//t7F+Ltpifhs65o9W1Jf5cH
	HxAk4Htdziuofn6mCdAi0lqmEizCl5G5hWfwfV2dCBiPeF6YPwALvVPUL4IM4j8aQ7qR
	nxGFls7ioLZH6aPAthyjrqGwfVoHMiCnPnWPhiGnprJC//lrAl3564os+PKnCqh4M7OR
	uFH12A1jTU6MD65Rzc6yDXkcyCo1AEFdI0tdXS3VeA2O92fH0y6oayd7m5at+hcK4KY9
	fyor8SD5i8VysXKTQ1fZU8pB0u1E+U/SdatMPF4ezvwff8meOTp6XJHwnk9d2MVJOblV
	d7Sg==
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:in-reply-to:message-id
	:references:user-agent:mime-version:content-type;
	bh=vTYlEGoeASs622lcFWhWhnQc4A1GfggD9GVeiJKuyu0=;
	b=HjAhvrPodglMNSfhzduud3hhTUv/8tKxhKjDZqp0MCPvXMSplBOshNqtVT8kTTvzli
	TrFJmBcOOKciUUXyrV+GcvRhzNmVxpQ8Acptu5U6AbaMzF2SJeUy0lN8VG2jskbZW96Z
	SebLkB34amKP2uo2hxalvepbceKMaRPRFbjyy8UqbuOB488P9N1zZt+nrd0ImOqfqk9F
	3dY+m2ijMx75wzjngIJGawgyFf2kzaKc5RTvEjhtRUxvuf8USELH8uDpTiwQcYBA414/
	7GcpRIOfmXc5E4COM4xNAqVSU/1grNsxjpB/FibAnI3nL9OPbQLm/74M4QtX4yW54S1B
	P4JQ==
X-Gm-Message-State: ALoCoQl2TJU8JMkuXJwNWMjh0X7u65qBVhbWETi2pyvkeuO0FPVHS7fuX3EQZXiYkm/cMiublWgQ
X-Received: by 10.42.129.140 with SMTP id q12mr17693570ics.68.1418417206122;
	Fri, 12 Dec 2014 12:46:46 -0800 (PST)
Received: from [2620:0:1008:1101:f51b:f61e:9c94:f441]
	([2620:0:1008:1101:f51b:f61e:9c94:f441])
	by mx.google.com with ESMTPSA id b2sm1144045ioe.2.2014.12.12.12.46.42
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 12 Dec 2014 12:46:43 -0800 (PST)
Date: Fri, 12 Dec 2014 12:46:42 -0800 (PST)
From: David Rientjes <rientjes@google.com>
X-X-Sender: rientjes@chino.kir.corp.google.com
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
In-Reply-To: <1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
Message-ID: <alpine.DEB.2.10.1412121246250.2273@chino.kir.corp.google.com>
References: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
	<1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	josh@joshtriplett.org, linux-kernel@vger.kernel.org,
	Pekka Enberg <penberg@kernel.org>, mtosatti@redhat.com,
	fengguang.wu@intel.com, levinsasha928@gmail.com, hpa@zytor.com,
	xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>,
	sam@ravnborg.org, David Vrabel <david.vrabel@citrix.com>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86, arm, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 9 Dec 2014, Luis R. Rodriguez wrote:

> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> This lets you build a kernel which can support xen dom0
> or xen guests by just using:
> 
>    make xenconfig
> 
> on both x86 and arm64 kernels. This also splits out the
> options which are available currently to be built with x86
> and 'make ARCH=arm64' under a shared config.
> 
> Technically xen supports a dom0 kernel and also a guest
> kernel configuration but upon review with the xen team
> since we don't have many dom0 options its best to just
> combine these two into one.
> 
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Pekka Enberg <penberg@kernel.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Michal Marek <mmarek@suse.cz>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: penberg@kernel.org
> Cc: levinsasha928@gmail.com
> Cc: mtosatti@redhat.com
> Cc: fengguang.wu@intel.com
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xenproject.org
> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>

Acked-by: David Rientjes <rientjes@google.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 20:53:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 20:53:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzXDH-0000W5-C9; Fri, 12 Dec 2014 20:53:23 +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 1XzXDF-0000W0-QG
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 20:53:21 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	EA/6D-25547-1C55B845; Fri, 12 Dec 2014 20:53:21 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418417599!12879223!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12573 invoked from network); 12 Dec 2014 20:53:20 -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; 12 Dec 2014 20:53:20 -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 sBCKrHdY027915
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Dec 2014 20:53: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
	sBCKrG47002335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 12 Dec 2014 20:53:16 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
	sBCKrGn5016205; Fri, 12 Dec 2014 20:53:16 GMT
Received: from ovs101.us.oracle.com (/10.149.76.201)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 12:53:14 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, konrad.wilk@oracle.com
Date: Fri, 12 Dec 2014 16:20:48 -0500
Message-Id: <1418419248-2863-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] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try dereference it in
the future, when VCPU is gone.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/vpmu.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

This needs to be backported to 4.3 and 4.4 as well

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1df74c2..6d39680 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
     }
 }
 
+static void vpmu_clear_last(void *arg)
+{
+    struct vcpu *v = (struct vcpu *)arg;
+
+    if ( this_cpu(last_vcpu) == v )
+        this_cpu(last_vcpu) = NULL;
+}
+
 void vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
+    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
+    {
+        /* Need to clear last_vcpu in case it points to v */
+        if ( vpmu->last_pcpu != smp_processor_id() )
+            on_selected_cpus(cpumask_of(vpmu->last_pcpu),
+                             vpmu_clear_last, (void *)v, 1);
+        else
+        {
+            local_irq_disable();
+            vpmu_clear_last((void *)v);
+            local_irq_enable();
+        }
+    }
+
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
         vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
 }
-- 
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 Dec 12 20:53:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 20:53:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzXDH-0000W5-C9; Fri, 12 Dec 2014 20:53:23 +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 1XzXDF-0000W0-QG
	for xen-devel@lists.xen.org; Fri, 12 Dec 2014 20:53:21 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	EA/6D-25547-1C55B845; Fri, 12 Dec 2014 20:53:21 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418417599!12879223!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12573 invoked from network); 12 Dec 2014 20:53:20 -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; 12 Dec 2014 20:53:20 -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 sBCKrHdY027915
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Dec 2014 20:53: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
	sBCKrG47002335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 12 Dec 2014 20:53:16 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
	sBCKrGn5016205; Fri, 12 Dec 2014 20:53:16 GMT
Received: from ovs101.us.oracle.com (/10.149.76.201)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 12:53:14 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, konrad.wilk@oracle.com
Date: Fri, 12 Dec 2014 16:20:48 -0500
Message-Id: <1418419248-2863-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] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try dereference it in
the future, when VCPU is gone.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/vpmu.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

This needs to be backported to 4.3 and 4.4 as well

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1df74c2..6d39680 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
     }
 }
 
+static void vpmu_clear_last(void *arg)
+{
+    struct vcpu *v = (struct vcpu *)arg;
+
+    if ( this_cpu(last_vcpu) == v )
+        this_cpu(last_vcpu) = NULL;
+}
+
 void vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
+    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
+    {
+        /* Need to clear last_vcpu in case it points to v */
+        if ( vpmu->last_pcpu != smp_processor_id() )
+            on_selected_cpus(cpumask_of(vpmu->last_pcpu),
+                             vpmu_clear_last, (void *)v, 1);
+        else
+        {
+            local_irq_disable();
+            vpmu_clear_last((void *)v);
+            local_irq_enable();
+        }
+    }
+
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
         vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
 }
-- 
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 Dec 12 21:36:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 21:36:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzXsz-0001dL-Dn; Fri, 12 Dec 2014 21:36: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 1XzXsy-0001dG-Dd
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 21:36:28 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	1B/F9-20609-BDF5B845; Fri, 12 Dec 2014 21:36:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418420185!14796531!1
X-Originating-IP: [66.165.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 31697 invoked from network); 12 Dec 2014 21:36:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 21:36:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,566,1413244800"; d="scan'208";a="204063906"
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.210.2; Fri, 12 Dec 2014 16:36: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 1XzXsq-0007hr-Lf;
	Fri, 12 Dec 2014 21:36:20 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzXsq-0006IV-E7;
	Fri, 12 Dec 2014 21:36:20 +0000
Date: Fri, 12 Dec 2014 21:36:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32282-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] 32282: 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 32282 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32282/

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 32110
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 31934

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
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-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-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-qemut-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-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-qemuu-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

version targeted for testing:
 xen                  5cd7ed02530eb86ffee6f5b9c7f04743c726754f
baseline version:
 xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Keir Fraser <keir@xen.org>
  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                                         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


Pushing revision :

+ branch=xen-4.3-testing
+ revision=5cd7ed02530eb86ffee6f5b9c7f04743c726754f
+ . 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 5cd7ed02530eb86ffee6f5b9c7f04743c726754f
+ branch=xen-4.3-testing
+ revision=5cd7ed02530eb86ffee6f5b9c7f04743c726754f
+ . 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 5cd7ed02530eb86ffee6f5b9c7f04743c726754f:stable-4.3
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   e0921ec..5cd7ed0  5cd7ed02530eb86ffee6f5b9c7f04743c726754f -> 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 Dec 12 21:36:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 21:36:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzXsz-0001dL-Dn; Fri, 12 Dec 2014 21:36: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 1XzXsy-0001dG-Dd
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 21:36:28 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	1B/F9-20609-BDF5B845; Fri, 12 Dec 2014 21:36:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418420185!14796531!1
X-Originating-IP: [66.165.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 31697 invoked from network); 12 Dec 2014 21:36:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 21:36:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,566,1413244800"; d="scan'208";a="204063906"
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.210.2; Fri, 12 Dec 2014 16:36: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 1XzXsq-0007hr-Lf;
	Fri, 12 Dec 2014 21:36:20 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzXsq-0006IV-E7;
	Fri, 12 Dec 2014 21:36:20 +0000
Date: Fri, 12 Dec 2014 21:36:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32282-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] 32282: 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 32282 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32282/

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 32110
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 31934

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
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    fail   never pass
 build-i386-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-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-qemut-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-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-qemuu-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

version targeted for testing:
 xen                  5cd7ed02530eb86ffee6f5b9c7f04743c726754f
baseline version:
 xen                  e0921ec746410f0a07eb3767e95e5eda25d4934a

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <jgross@suse.com>
  Keir Fraser <keir@xen.org>
  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                                         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


Pushing revision :

+ branch=xen-4.3-testing
+ revision=5cd7ed02530eb86ffee6f5b9c7f04743c726754f
+ . 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 5cd7ed02530eb86ffee6f5b9c7f04743c726754f
+ branch=xen-4.3-testing
+ revision=5cd7ed02530eb86ffee6f5b9c7f04743c726754f
+ . 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 5cd7ed02530eb86ffee6f5b9c7f04743c726754f:stable-4.3
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   e0921ec..5cd7ed0  5cd7ed02530eb86ffee6f5b9c7f04743c726754f -> 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 Dec 12 22:47:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 22: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 1XzYyz-0003Ds-5V; Fri, 12 Dec 2014 22:46: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 1XzYyy-0003Dl-4a
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 22:46:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A5/68-09842-3507B845; Fri, 12 Dec 2014 22:46:43 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418424401!15278612!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9493 invoked from network); 12 Dec 2014 22:46:42 -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; 12 Dec 2014 22:46:42 -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 sBCMkStK020840
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Dec 2014 22:46:28 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
	sBCMkPgr003549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 12 Dec 2014 22:46:26 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
	sBCMkP8d026229; Fri, 12 Dec 2014 22:46: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 ; Fri, 12 Dec 2014 14:46:25 -0800
Message-ID: <548B70B3.7030807@oracle.com>
Date: Fri, 12 Dec 2014 17: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: Juergen Gross <jgross@suse.com>, linux-kernel@vger.kernel.org,
	x86@kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	david.vrabel@citrix.com, tglx@linutronix.de, mingo@redhat.com,
	hpa@zytor.com, mmarek@suse.cz, linux-kbuild@vger.kernel.org
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-2-git-send-email-jgross@suse.com>
In-Reply-To: <1418321065-10212-2-git-send-email-jgross@suse.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/2014 01:04 PM, Juergen Gross wrote:
> diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
> new file mode 100644
> index 0000000..e6447b7
> --- /dev/null
> +++ b/scripts/xen-hypercalls.sh
> @@ -0,0 +1,11 @@
> +#!/bin/sh
> +out="$1"
> +shift
> +in="$@"
> +
> +for i in $in; do
> +	eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
> +done | \
> +awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
> +	END {for (i in v) if (!(v[i] in v))
> +		print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out

Why do you 'sort -u'? Do you expect multiple definitions of the same 
hypercall?

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 12 22:47:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Dec 2014 22: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 1XzYyz-0003Ds-5V; Fri, 12 Dec 2014 22:46: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 1XzYyy-0003Dl-4a
	for xen-devel@lists.xensource.com; Fri, 12 Dec 2014 22:46:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A5/68-09842-3507B845; Fri, 12 Dec 2014 22:46:43 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418424401!15278612!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9493 invoked from network); 12 Dec 2014 22:46:42 -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; 12 Dec 2014 22:46:42 -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 sBCMkStK020840
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Dec 2014 22:46:28 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
	sBCMkPgr003549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 12 Dec 2014 22:46:26 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
	sBCMkP8d026229; Fri, 12 Dec 2014 22:46: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 ; Fri, 12 Dec 2014 14:46:25 -0800
Message-ID: <548B70B3.7030807@oracle.com>
Date: Fri, 12 Dec 2014 17: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: Juergen Gross <jgross@suse.com>, linux-kernel@vger.kernel.org,
	x86@kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	david.vrabel@citrix.com, tglx@linutronix.de, mingo@redhat.com,
	hpa@zytor.com, mmarek@suse.cz, linux-kbuild@vger.kernel.org
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-2-git-send-email-jgross@suse.com>
In-Reply-To: <1418321065-10212-2-git-send-email-jgross@suse.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/2014 01:04 PM, Juergen Gross wrote:
> diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
> new file mode 100644
> index 0000000..e6447b7
> --- /dev/null
> +++ b/scripts/xen-hypercalls.sh
> @@ -0,0 +1,11 @@
> +#!/bin/sh
> +out="$1"
> +shift
> +in="$@"
> +
> +for i in $in; do
> +	eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
> +done | \
> +awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
> +	END {for (i in v) if (!(v[i] in v))
> +		print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out

Why do you 'sort -u'? Do you expect multiple definitions of the same 
hypercall?

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 13 00:10:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 00:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzaH2-0005QG-PK; Sat, 13 Dec 2014 00:09: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 1XzaH1-0005QB-Jc
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 00:09:27 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	7A/3D-15461-6B38B845; Sat, 13 Dec 2014 00:09:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418429364!15331343!1
X-Originating-IP: [66.165.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 31403 invoked from network); 13 Dec 2014 00:09:25 -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 Dec 2014 00:09:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,567,1413244800"; d="scan'208";a="203705802"
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.210.2; Fri, 12 Dec 2014 19:09: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 1XzaGw-0008Qk-9V;
	Sat, 13 Dec 2014 00:09:22 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzaGw-0008Pj-1h;
	Sat, 13 Dec 2014 00:09:22 +0000
Date: Sat, 13 Dec 2014 00:09:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32285-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] 32285: 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 32285 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32285/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 32215
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 32215 pass in 32285
 test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3) broken in 32215 pass in 32285

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32126

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-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-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-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-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-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              ed675ad4193bc7f929e5b39074d50672970aefa3
baseline version:
 seabios              56b252ea737c1514916d6df4493f89ff71322f60

------------------------------------------------------------
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                                     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


Pushing revision :

+ branch=seabios
+ revision=ed675ad4193bc7f929e5b39074d50672970aefa3
+ . 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 ed675ad4193bc7f929e5b39074d50672970aefa3
+ branch=seabios
+ revision=ed675ad4193bc7f929e5b39074d50672970aefa3
+ . 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 ed675ad4193bc7f929e5b39074d50672970aefa3:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   56b252e..ed675ad  ed675ad4193bc7f929e5b39074d50672970aefa3 -> 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 Dec 13 00:10:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 00:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzaH2-0005QG-PK; Sat, 13 Dec 2014 00:09: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 1XzaH1-0005QB-Jc
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 00:09:27 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	7A/3D-15461-6B38B845; Sat, 13 Dec 2014 00:09:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418429364!15331343!1
X-Originating-IP: [66.165.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 31403 invoked from network); 13 Dec 2014 00:09:25 -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 Dec 2014 00:09:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,567,1413244800"; d="scan'208";a="203705802"
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.210.2; Fri, 12 Dec 2014 19:09: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 1XzaGw-0008Qk-9V;
	Sat, 13 Dec 2014 00:09:22 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzaGw-0008Pj-1h;
	Sat, 13 Dec 2014 00:09:22 +0000
Date: Sat, 13 Dec 2014 00:09:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32285-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] 32285: 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 32285 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32285/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 32215
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 32215 pass in 32285
 test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3) broken in 32215 pass in 32285

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32126

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-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-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-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-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-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              ed675ad4193bc7f929e5b39074d50672970aefa3
baseline version:
 seabios              56b252ea737c1514916d6df4493f89ff71322f60

------------------------------------------------------------
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                                     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


Pushing revision :

+ branch=seabios
+ revision=ed675ad4193bc7f929e5b39074d50672970aefa3
+ . 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 ed675ad4193bc7f929e5b39074d50672970aefa3
+ branch=seabios
+ revision=ed675ad4193bc7f929e5b39074d50672970aefa3
+ . 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 ed675ad4193bc7f929e5b39074d50672970aefa3:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   56b252e..ed675ad  ed675ad4193bc7f929e5b39074d50672970aefa3 -> 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 Dec 13 01:34:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 01:34:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzbbA-0002xF-QQ; Sat, 13 Dec 2014 01:34:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tlviewer@yahoo.com>) id 1Xzbb8-0002xA-Lo
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 01:34:18 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	86/18-31453-9979B845; Sat, 13 Dec 2014 01:34:17 +0000
X-Env-Sender: tlviewer@yahoo.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418434455!13112579!1
X-Originating-IP: [216.109.114.170]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_YAHOO_RCVD,
	HTML_50_60,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22438 invoked from network); 13 Dec 2014 01:34:16 -0000
Received: from nm43-vm9.bullet.mail.bf1.yahoo.com (HELO
	nm43-vm9.bullet.mail.bf1.yahoo.com) (216.109.114.170)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 01:34:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
	t=1418434455; bh=BfS6prr/EuDoks4972X8MCbcFRDOXDDO235AmbUKr8E=;
	h=Date:From:Reply-To:To:Subject:From:Subject;
	b=dYVddL+qLtq7ebo8HGxE1xqZSZlo8EzKH5UznjnZdipY9yvDupUNGJnuarr2uhgZjgnAMFOV/0cu2ohE79MimVrF/nU4MC5eTAkPs5vHMDsPYNet+PzdZfvGAMRKkPLSi2NhjKKgf+Vi38kNT29MhpDyye+pzuPvVDc7OEvOdMp0uthAPNasZjV41bwhIYUkRoXB4FFdiv53gZjmON+UOVGTHrPSycnihmqnnwo/KE/gYICigM0kh/HBaLKiE5mWtiBE6b7p4ROVYSM6T8+OtK+q57OAK/U300DWOr1Y7ceOskt3MmgVnJ82MlkQsqJTQqWRCZIMX6JArgPAN3wvuw==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com;
	b=D0Wwoqg+I5n6ecJmhWfZH52HG54vHgspbOMWPJuAZjHJd7ouK8yPetR6pk6xLqZoQRWKsJ58MsZWf7/+6xwzfFK3oqYWuITBiA/vxa0QBibrGwQ5Xr9aSBCXnJeNOj6T0PAfrnR3rJDbms2Z7CCOH9hdIdkHBJ5QNbKDeexOCyc5PlezJwe6OhPDNCAFqfyXNojboE03NG0+RrqFdFREYYQosLeEl32O9iufxlvn43nF3eTGwSdWjupoh2ceYF+dQ/qdxM01Q8RzhCtskqls2/WUmZnVvkDDPp0Mzz2MUAwej9hBZmBUrQOMiq8ZcjkX45z49iio5G3Ftk39o1QPWQ==;
Received: from [66.196.81.170] by nm43.bullet.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2014 01:34:15 -0000
Received: from [98.139.212.213] by tm16.bullet.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2014 01:34:15 -0000
Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2014 01:34:15 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 566333.12938.bm@omp1022.mail.bf1.yahoo.com
X-YMail-OSG: PRO3vCAVM1mUHLqerEFscn8uAhOEXLqCXSGxCHOvtwGinqLZOEV4_1JK46pSxdF
	aaUqMW4nIg_WeXT4fuHUZzOTTWqByLf9yTNpb2iDvKNbN9IxWzDbdmvMvWEmMo50YP8a1QV8IZ77
	E.WGH18GqfrNt6.j_0vt2yOGfzAyRw9qNhUAXdKCnVuAuwRr4PFEZF2kzhZhI913if9EVIfziGNy
	aomYTnzkbGKySWVEd_Z2rd7NBT0Qt59LGRzqJvN3ZvUURqm1e5VXACdnh7p4QBm5y6Ap2qwoxoxN
	aAYJOWMLuiiwpJaItZQasFP1HNZh6.coefuqOlQcLvIxFlDkzpCK4VINAe8NPuvpAvy.rNaMwr5w
	U8TVT4UziZcNFe8JbxYVB7AqcJiQdFiGOXju5SRAxEtPV7kv.r8qU9MavY7HYF0guCe09Paoo2nr
	QkhQgKm.5bBEp8XG2F1rF0rHbfH.Knr.zkTOT.bPJGF.CLPj28FeLLmhE6H_seiZBGO6_1_JelZe
	XdVuEKl1YjkyAkoqFZyX2jCQaR94zZZlhc1.kjhIOaSu1MCVuBeoE_yg-
Received: by 76.13.26.198; Sat, 13 Dec 2014 01:34:15 +0000 
Date: Sat, 13 Dec 2014 01:34:14 +0000 (UTC)
From: Mark Pryor <tlviewer@yahoo.com>
To: Xen-devel <xen-devel@lists.xen.org>
Message-ID: <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
MIME-Version: 1.0
Content-Length: 2976
Subject: [Xen-devel] 4.5 patch: xendomains noise to stderr in rdname()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mark Pryor <tlviewer@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5886123611713459533=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5886123611713459533==
Content-Type: multipart/alternative; 
	boundary="----=_Part_78912_2053105263.1418434454760"
Content-Length: 2489

------=_Part_78912_2053105263.1418434454760
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Instead of tracking down which commit involving libxl* which prints all kin=
d of noiseto stderr, I will post a workaround.=20

If you build, install, and use 4.5 this bug will drive you mad, so here it =
is:
-------------------- snip -----------------
--- a/tools/hotplug/Linux/xendomains.in+++ b/tools/hotplug/Linux/xendomains=
.in
@@ -175,7 +175,7 @@ contains_something()
=C2=A0# read name from xen config file
=C2=A0rdname()
=C2=A0{
-=C2=A0=C2=A0=C2=A0 NM=3D$($CMD create --quiet --dryrun --defconfig "$1" |
+=C2=A0=C2=A0=C2=A0 NM=3D$($CMD create --quiet --dryrun --defconfig "$1" 2>=
&1 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sed -n 's/^.*(name \=
(.*\))$/\1/p;s/^.*"name": "\(.*\)",$/\1/p')
=C2=A0}



------=_Part_78912_2053105263.1418434454760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo=
nt-size:16px"><div dir=3D"ltr">Instead of tracking down which commit involv=
ing libxl* which prints all kind of noise</div><div dir=3D"ltr">to stderr, =
I will post a workaround. <br></div><div dir=3D"ltr"><br></div><div dir=3D"=
ltr">If you build, install, and use 4.5 this bug will drive you mad, so her=
e it is:<br></div><div id=3D"yui_3_16_0_1_1418434213662_2416" dir=3D"ltr">-=
------------------- snip -----------------<br></div><div id=3D"yui_3_16_0_1=
_1418434213662_2415">--- a/tools/hotplug/Linux/xendomains.in</div>+++ b/too=
ls/hotplug/Linux/xendomains.in<br style=3D"" class=3D"">@@ -175,7 +175,7 @@=
 contains_something()<br style=3D"" class=3D"">&nbsp;# read name from xen c=
onfig file<br style=3D"" class=3D"">&nbsp;rdname()<br style=3D"" class=3D""=
>&nbsp;{<br style=3D"" class=3D"">-&nbsp;&nbsp;&nbsp; NM=3D$($CMD create --=
quiet --dryrun --defconfig "$1" |<br style=3D"" class=3D"">+&nbsp;&nbsp;&nb=
sp; NM=3D$($CMD create --quiet --dryrun --defconfig "$1" 2&gt;&amp;1 |<br s=
tyle=3D"" class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 sed -n 's/^.*(name \(.*\))$/\1/p;s/^.*"name": "\(.*\)",$/\1/p')<br style=
=3D"" class=3D"">&nbsp;}<br style=3D"" class=3D""><br style=3D"" class=3D""=
><div id=3D"yui_3_16_0_1_1418434213662_2376"><br></div></div></body></html>
------=_Part_78912_2053105263.1418434454760--


--===============5886123611713459533==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5886123611713459533==--


From xen-devel-bounces@lists.xen.org Sat Dec 13 01:34:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 01:34:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzbbA-0002xF-QQ; Sat, 13 Dec 2014 01:34:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tlviewer@yahoo.com>) id 1Xzbb8-0002xA-Lo
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 01:34:18 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	86/18-31453-9979B845; Sat, 13 Dec 2014 01:34:17 +0000
X-Env-Sender: tlviewer@yahoo.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418434455!13112579!1
X-Originating-IP: [216.109.114.170]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_YAHOO_RCVD,
	HTML_50_60,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22438 invoked from network); 13 Dec 2014 01:34:16 -0000
Received: from nm43-vm9.bullet.mail.bf1.yahoo.com (HELO
	nm43-vm9.bullet.mail.bf1.yahoo.com) (216.109.114.170)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 01:34:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
	t=1418434455; bh=BfS6prr/EuDoks4972X8MCbcFRDOXDDO235AmbUKr8E=;
	h=Date:From:Reply-To:To:Subject:From:Subject;
	b=dYVddL+qLtq7ebo8HGxE1xqZSZlo8EzKH5UznjnZdipY9yvDupUNGJnuarr2uhgZjgnAMFOV/0cu2ohE79MimVrF/nU4MC5eTAkPs5vHMDsPYNet+PzdZfvGAMRKkPLSi2NhjKKgf+Vi38kNT29MhpDyye+pzuPvVDc7OEvOdMp0uthAPNasZjV41bwhIYUkRoXB4FFdiv53gZjmON+UOVGTHrPSycnihmqnnwo/KE/gYICigM0kh/HBaLKiE5mWtiBE6b7p4ROVYSM6T8+OtK+q57OAK/U300DWOr1Y7ceOskt3MmgVnJ82MlkQsqJTQqWRCZIMX6JArgPAN3wvuw==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com;
	b=D0Wwoqg+I5n6ecJmhWfZH52HG54vHgspbOMWPJuAZjHJd7ouK8yPetR6pk6xLqZoQRWKsJ58MsZWf7/+6xwzfFK3oqYWuITBiA/vxa0QBibrGwQ5Xr9aSBCXnJeNOj6T0PAfrnR3rJDbms2Z7CCOH9hdIdkHBJ5QNbKDeexOCyc5PlezJwe6OhPDNCAFqfyXNojboE03NG0+RrqFdFREYYQosLeEl32O9iufxlvn43nF3eTGwSdWjupoh2ceYF+dQ/qdxM01Q8RzhCtskqls2/WUmZnVvkDDPp0Mzz2MUAwej9hBZmBUrQOMiq8ZcjkX45z49iio5G3Ftk39o1QPWQ==;
Received: from [66.196.81.170] by nm43.bullet.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2014 01:34:15 -0000
Received: from [98.139.212.213] by tm16.bullet.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2014 01:34:15 -0000
Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2014 01:34:15 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 566333.12938.bm@omp1022.mail.bf1.yahoo.com
X-YMail-OSG: PRO3vCAVM1mUHLqerEFscn8uAhOEXLqCXSGxCHOvtwGinqLZOEV4_1JK46pSxdF
	aaUqMW4nIg_WeXT4fuHUZzOTTWqByLf9yTNpb2iDvKNbN9IxWzDbdmvMvWEmMo50YP8a1QV8IZ77
	E.WGH18GqfrNt6.j_0vt2yOGfzAyRw9qNhUAXdKCnVuAuwRr4PFEZF2kzhZhI913if9EVIfziGNy
	aomYTnzkbGKySWVEd_Z2rd7NBT0Qt59LGRzqJvN3ZvUURqm1e5VXACdnh7p4QBm5y6Ap2qwoxoxN
	aAYJOWMLuiiwpJaItZQasFP1HNZh6.coefuqOlQcLvIxFlDkzpCK4VINAe8NPuvpAvy.rNaMwr5w
	U8TVT4UziZcNFe8JbxYVB7AqcJiQdFiGOXju5SRAxEtPV7kv.r8qU9MavY7HYF0guCe09Paoo2nr
	QkhQgKm.5bBEp8XG2F1rF0rHbfH.Knr.zkTOT.bPJGF.CLPj28FeLLmhE6H_seiZBGO6_1_JelZe
	XdVuEKl1YjkyAkoqFZyX2jCQaR94zZZlhc1.kjhIOaSu1MCVuBeoE_yg-
Received: by 76.13.26.198; Sat, 13 Dec 2014 01:34:15 +0000 
Date: Sat, 13 Dec 2014 01:34:14 +0000 (UTC)
From: Mark Pryor <tlviewer@yahoo.com>
To: Xen-devel <xen-devel@lists.xen.org>
Message-ID: <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
MIME-Version: 1.0
Content-Length: 2976
Subject: [Xen-devel] 4.5 patch: xendomains noise to stderr in rdname()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mark Pryor <tlviewer@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5886123611713459533=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5886123611713459533==
Content-Type: multipart/alternative; 
	boundary="----=_Part_78912_2053105263.1418434454760"
Content-Length: 2489

------=_Part_78912_2053105263.1418434454760
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Instead of tracking down which commit involving libxl* which prints all kin=
d of noiseto stderr, I will post a workaround.=20

If you build, install, and use 4.5 this bug will drive you mad, so here it =
is:
-------------------- snip -----------------
--- a/tools/hotplug/Linux/xendomains.in+++ b/tools/hotplug/Linux/xendomains=
.in
@@ -175,7 +175,7 @@ contains_something()
=C2=A0# read name from xen config file
=C2=A0rdname()
=C2=A0{
-=C2=A0=C2=A0=C2=A0 NM=3D$($CMD create --quiet --dryrun --defconfig "$1" |
+=C2=A0=C2=A0=C2=A0 NM=3D$($CMD create --quiet --dryrun --defconfig "$1" 2>=
&1 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sed -n 's/^.*(name \=
(.*\))$/\1/p;s/^.*"name": "\(.*\)",$/\1/p')
=C2=A0}



------=_Part_78912_2053105263.1418434454760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo=
nt-size:16px"><div dir=3D"ltr">Instead of tracking down which commit involv=
ing libxl* which prints all kind of noise</div><div dir=3D"ltr">to stderr, =
I will post a workaround. <br></div><div dir=3D"ltr"><br></div><div dir=3D"=
ltr">If you build, install, and use 4.5 this bug will drive you mad, so her=
e it is:<br></div><div id=3D"yui_3_16_0_1_1418434213662_2416" dir=3D"ltr">-=
------------------- snip -----------------<br></div><div id=3D"yui_3_16_0_1=
_1418434213662_2415">--- a/tools/hotplug/Linux/xendomains.in</div>+++ b/too=
ls/hotplug/Linux/xendomains.in<br style=3D"" class=3D"">@@ -175,7 +175,7 @@=
 contains_something()<br style=3D"" class=3D"">&nbsp;# read name from xen c=
onfig file<br style=3D"" class=3D"">&nbsp;rdname()<br style=3D"" class=3D""=
>&nbsp;{<br style=3D"" class=3D"">-&nbsp;&nbsp;&nbsp; NM=3D$($CMD create --=
quiet --dryrun --defconfig "$1" |<br style=3D"" class=3D"">+&nbsp;&nbsp;&nb=
sp; NM=3D$($CMD create --quiet --dryrun --defconfig "$1" 2&gt;&amp;1 |<br s=
tyle=3D"" class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 sed -n 's/^.*(name \(.*\))$/\1/p;s/^.*"name": "\(.*\)",$/\1/p')<br style=
=3D"" class=3D"">&nbsp;}<br style=3D"" class=3D""><br style=3D"" class=3D""=
><div id=3D"yui_3_16_0_1_1418434213662_2376"><br></div></div></body></html>
------=_Part_78912_2053105263.1418434454760--


--===============5886123611713459533==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5886123611713459533==--


From xen-devel-bounces@lists.xen.org Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcuy-00052b-AT; Sat, 13 Dec 2014 02:58:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcuw-00051w-7d
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:50 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	89/80-11608-96BAB845; Sat, 13 Dec 2014 02:58:49 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418439525!12910788!1
X-Originating-IP: [156.151.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 8425 invoked from network); 13 Dec 2014 02:58: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; 13 Dec 2014 02:58: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 sBD2wihl010987
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58: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
	sBD2whhF021474
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 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
	sBD2whco007049
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:43 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:43 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:25 -0800
Message-Id: <1418439507-16027-5-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
References: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [V0 PATCH 4/6] AMD-PVH: Do not get/set vlapic TPR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH doesn't use apic emulation hence vlapic->regs ptr is not set for it.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 xen/arch/x86/hvm/svm/svm.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index dac16f4..4bb4ff2 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1052,7 +1052,7 @@ static void noreturn svm_do_resume(struct vcpu *v)
         hvm_asid_flush_vcpu(v);
     }
 
-    if ( !vcpu_guestmode )
+    if ( !vcpu_guestmode && vcpu_vlapic(v)->regs )
     {
         vintr_t intr;
 
@@ -2247,7 +2247,7 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
      * NB. We need to preserve the low bits of the TPR to make checked builds
      * of Windows work, even though they don't actually do anything.
      */
-    if ( !vcpu_guestmode ) {
+    if ( !vcpu_guestmode && vcpu_vlapic(v)->regs ) {
         intr = vmcb_get_vintr(vmcb);
         vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI,
                    ((intr.fields.tpr & 0x0F) << 4) |
@@ -2628,15 +2628,18 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
     }
 
   out:
-    if ( vcpu_guestmode )
-        /* Don't clobber TPR of the nested guest. */
-        return;
-
-    /* The exit may have updated the TPR: reflect this in the hardware vtpr */
-    intr = vmcb_get_vintr(vmcb);
-    intr.fields.tpr =
-        (vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) & 0xFF) >> 4;
-    vmcb_set_vintr(vmcb, intr);
+    /* Don't clobber TPR of the nested guest. */
+    if ( vcpu_guestmode && vcpu_vlapic(v)->regs )
+    {
+        /*
+         * The exit may have updated the TPR: reflect this in the hardware
+         * vtpr.
+         */
+        intr = vmcb_get_vintr(vmcb);
+        intr.fields.tpr =
+            (vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) & 0xFF) >> 4;
+        vmcb_set_vintr(vmcb, intr);
+    }
 }
 
 void svm_trace_vmentry(void)
-- 
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 Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcuw-00052N-RR; Sat, 13 Dec 2014 02:58:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcuu-00051i-Qi
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	22/A9-25276-86BAB845; Sat, 13 Dec 2014 02:58:48 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418439526!14970476!1
X-Originating-IP: [156.151.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 14068 invoked from network); 13 Dec 2014 02:58:47 -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; 13 Dec 2014 02:58: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 sBD2wjXC010994
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:45 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
	sBD2wirb000057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 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
	sBD2wiPH000054
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:44 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:27 -0800
Message-Id: <1418439507-16027-7-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
References: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [V0 PATCH 6/6] AMD-PVH: enable pvh if requirements met
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Finally, enable pvh if the cpu supports NPT and svm decode.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 xen/arch/x86/hvm/svm/svm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 4bb4ff2..8b27a76 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1390,6 +1390,9 @@ const struct hvm_function_table * __init start_svm(void)
     svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB |
         ((cpuid_edx(0x80000001) & 0x04000000) ? HVM_HAP_SUPERPAGE_1GB : 0);
 
+    if ( cpu_has_svm_npt  && cpu_has_svm_decode )
+        svm_function_table.pvh_supported = 1;
+
     return &svm_function_table;
 }
 
-- 
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 Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcuv-00051n-5t; Sat, 13 Dec 2014 02:58:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcut-00051M-Ao
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	18/09-09842-66BAB845; Sat, 13 Dec 2014 02:58:46 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418439524!15281599!1
X-Originating-IP: [156.151.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 20430 invoked from network); 13 Dec 2014 02:58:45 -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; 13 Dec 2014 02:58: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 sBD2whRx010948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 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
	sBD2wg5w021457
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:43 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
	sBD2wg1u007038
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:42 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:42 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:23 -0800
Message-Id: <1418439507-16027-3-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
References: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [V0 PATCH 2/6] AMD-PVH: cpuid intercept
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Call pv_cpuid for pvh cpuid intercept. Note, we modify
svm_vmexit_do_cpuid instead of the intercept switch because the guest
eip needs to be adjusted for pvh also.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 xen/arch/x86/hvm/svm/svm.c | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 71b8a6a..4ff4a96 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1517,18 +1517,22 @@ static void svm_vmexit_do_cpuid(struct cpu_user_regs *regs)
     if ( (inst_len = __get_instruction_length(current, INSTR_CPUID)) == 0 )
         return;
 
-    eax = regs->eax;
-    ebx = regs->ebx;
-    ecx = regs->ecx;
-    edx = regs->edx;
-
-    svm_cpuid_intercept(&eax, &ebx, &ecx, &edx);
+    if ( is_pvh_vcpu(current) )
+        pv_cpuid(regs);
+    else
+    {
+        eax = regs->eax;
+        ebx = regs->ebx;
+        ecx = regs->ecx;
+        edx = regs->edx;
 
-    regs->eax = eax;
-    regs->ebx = ebx;
-    regs->ecx = ecx;
-    regs->edx = edx;
+        svm_cpuid_intercept(&eax, &ebx, &ecx, &edx);
 
+        regs->eax = eax;
+        regs->ebx = ebx;
+        regs->ecx = ecx;
+        regs->edx = edx;
+    }
     __update_guest_eip(regs, inst_len);
 }
 
-- 
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 Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcuy-00052n-PT; Sat, 13 Dec 2014 02:58:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcuw-000528-QP
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:50 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	6A/70-02696-A6BAB845; Sat, 13 Dec 2014 02:58:50 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418439526!14807214!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4276 invoked from network); 13 Dec 2014 02:58:47 -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; 13 Dec 2014 02:58: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 sBD2wj32020565
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58: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
	sBD2wjPN021506
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:45 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
	sBD2wiMa021481
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:43 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:26 -0800
Message-Id: <1418439507-16027-6-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
References: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [V0 PATCH 5/6] AMD-PVH: Support TSC_MODE_NEVER_EMULATE
	for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On AMD, MSR_AMD64_TSC_RATIO must be set for rdtsc instruction in guest
to properly read the cpu tsc. To that end, set tsc_khz in struct domain.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 xen/arch/x86/time.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index bd89219..7512aa4 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1908,6 +1908,7 @@ void tsc_set_info(struct domain *d,
          * but "always_emulate" does not for some reason.  Figure out
          * why.
          */
+        d->arch.tsc_khz = cpu_khz;
         switch ( tsc_mode )
         {
         case TSC_MODE_NEVER_EMULATE:
-- 
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 Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcuv-00051u-KX; Sat, 13 Dec 2014 02:58:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcut-00051N-M0
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:47 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	85/E2-02576-66BAB845; Sat, 13 Dec 2014 02:58:46 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418439524!14778999!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10280 invoked from network); 13 Dec 2014 02:58:46 -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; 13 Dec 2014 02:58:46 -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 sBD2whnH020514
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 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
	sBD2whtD007048
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:43 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
	sBD2wgCP021449
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:42 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:41 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:22 -0800
Message-Id: <1418439507-16027-2-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
References: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [V0 PATCH 1/6] AMD-PVH: construct vmcb changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH guest starts in Long 64bit paging mode. This patch modifies
construct_vmcb for that.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 xen/arch/x86/hvm/svm/vmcb.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 21292bb..5df5f36 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -138,6 +138,8 @@ static int construct_vmcb(struct vcpu *v)
 
     /* Guest EFER. */
     v->arch.hvm_vcpu.guest_efer = 0;
+    if ( is_pvh_vcpu(v) )
+        v->arch.hvm_vcpu.guest_efer |= EFER_LMA;   /* PVH 32bitfixme */
     hvm_update_guest_efer(v);
 
     /* Guest segment limits. */
@@ -162,7 +164,12 @@ static int construct_vmcb(struct vcpu *v)
     vmcb->ds.attr.bytes = 0xc93;
     vmcb->fs.attr.bytes = 0xc93;
     vmcb->gs.attr.bytes = 0xc93;
-    vmcb->cs.attr.bytes = 0xc9b; /* exec/read, accessed */
+
+    if ( is_pvh_vcpu(v) )
+        /* CS.L == 1, exec, read/write, accessed. PVH 32bitfixme. */
+        vmcb->cs.attr.bytes = 0xa9b;
+    else
+        vmcb->cs.attr.bytes = 0xc9b; /* exec/read, accessed */
 
     /* Guest IDT. */
     vmcb->idtr.base = 0;
@@ -184,12 +191,17 @@ static int construct_vmcb(struct vcpu *v)
     vmcb->tr.limit = 0xff;
 
     v->arch.hvm_vcpu.guest_cr[0] = X86_CR0_PE | X86_CR0_ET;
+    /* PVH domains start in paging mode */
+    if ( is_pvh_vcpu(v) )
+        v->arch.hvm_vcpu.guest_cr[0] |= X86_CR0_PG;
     hvm_update_guest_cr(v, 0);
 
-    v->arch.hvm_vcpu.guest_cr[4] = 0;
+    v->arch.hvm_vcpu.guest_cr[4] = is_pvh_vcpu(v) ? X86_CR4_PAE : 0;
     hvm_update_guest_cr(v, 4);
 
-    paging_update_paging_modes(v);
+    /* For pvh, paging mode is updated by arch_set_info_guest(). */
+    if ( is_hvm_vcpu(v) )
+        paging_update_paging_modes(v);
 
     vmcb->_exception_intercepts =
         HVM_TRAP_MASK
-- 
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 Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcut-00051T-Kl; Sat, 13 Dec 2014 02:58:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcus-00051H-AN
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:46 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	3E/C0-27584-56BAB845; Sat, 13 Dec 2014 02:58:45 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418439523!7834995!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17267 invoked from network); 13 Dec 2014 02:58:44 -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; 13 Dec 2014 02:58: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 sBD2wgYN020493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:43 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
	sBD2wflG029992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:42 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
	sBD2wfU7029984
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:41 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:41 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:21 -0800
Message-Id: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [AMD PVH]: Partial/domU xen 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

Hi Elena/Boris:

Actually, I forgot I had already made and tested AMD SVM and other changes 
for domU support, please find the patches.

So the only thing remaining for AMD would be iommu support and SVM vmexit 
for CR reads and writes which currently calls handle_mmio (which patch #3
attempted, but improperly).  I believe Jan or Roger is already looking 
into that path, so you could start down the iommu path... the last I 
remember was :

(XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x99, fault address = 0xffffffc0, flags = 0
(XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x91, fault address = 0xffffffc0, flags = 0
(XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x90, fault address = 0xffffffc0, flags = 0

(XEN) Xen call trace:
(XEN)    [<ffff82d08014d600>] parse_event_log_entry+0/0x140
(XEN)    [<ffff82d08014dfdf>] iommu_read_log.constprop.6+0x8f/0x100
(XEN)    [<ffff82d08014e165>] do_amd_iommu_irq+0x115/0x1f0
(XEN)    [<ffff82d0801296d0>] do_tasklet_work+0x60/0xa0
(XEN)    [<ffff82d080129750>] tasklet_softirq_action+0x40/0x70
(XEN)    [<ffff82d080126ee5>] __do_softirq+0x65/0xa0
(XEN)    [<ffff82d0802abe68>] _setup_hwdom_pci_devices+0xa8/0x190
(XEN)    [<ffff82d0802abdc0>] _setup_hwdom_pci_devices+0/0x190
(XEN)    [<ffff82d0801435cb>] pci_segments_iterate+0x2b/0x70
(XEN)    [<ffff82d0802ac2e8>] setup_hwdom_pci_devices+0x28/0x40
(XEN)    [<ffff82d0802aee00>] amd_iommu_setup_hwdom_device+0/0xc0
(XEN)    [<ffff82d0802cbfab>] construct_dom0+0x247b/0x3390
(XEN)    [<ffff82d0802bb810>] bootstrap_map+0/0x10c
(XEN)    [<ffff82d0802bf136>] __start_xen+0x35a6/0x3aa0
(XEN)    [<ffff82d080100067>] __high_start+0x53/0x5c


Thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcuw-000522-3N; Sat, 13 Dec 2014 02:58:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcut-00051O-NY
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:47 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	39/45-02707-66BAB845; Sat, 13 Dec 2014 02:58:46 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418439525!10247694!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18616 invoked from network); 13 Dec 2014 02:58:46 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2014 02:58:46 -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 sBD2widI020515
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 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
	sBD2whii021475
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:43 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
	sBD2whdN021462
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:43 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:42 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:24 -0800
Message-Id: <1418439507-16027-4-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
References: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [V0 PATCH 3/6] AMD-PVH: call hvm_emulate_one instead of
	handle_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Certain IOIO instructions and CR access instructions like
lmsw/clts etc need to be emulated. handle_mmio is incorrectly called to
accomplish this. Create svm_emulate() to call hvm_emulate_one which is more
appropriate, and works for pvh as well. handle_mmio call is
forbidden for pvh.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 xen/arch/x86/hvm/svm/svm.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 4ff4a96..dac16f4 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2209,6 +2209,18 @@ static struct hvm_function_table __initdata svm_function_table = {
     .nhvm_hap_walk_L1_p2m = nsvm_hap_walk_L1_p2m,
 };
 
+static void svm_emulate(struct cpu_user_regs *regs)
+{
+    int rc;
+    struct hvm_emulate_ctxt ctxt;
+
+    hvm_emulate_prepare(&ctxt, regs);
+    rc = hvm_emulate_one(&ctxt);
+
+    if ( rc != X86EMUL_OKAY )
+        hvm_inject_hw_exception(TRAP_gp_fault, 0);
+}
+
 void svm_vmexit_handler(struct cpu_user_regs *regs)
 {
     uint64_t exit_reason;
@@ -2470,16 +2482,16 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
             if ( handle_pio(port, bytes, dir) )
                 __update_guest_eip(regs, vmcb->exitinfo2 - vmcb->rip);
         }
-        else if ( !handle_mmio() )
-            hvm_inject_hw_exception(TRAP_gp_fault, 0);
+        else
+            svm_emulate(regs);
         break;
 
     case VMEXIT_CR0_READ ... VMEXIT_CR15_READ:
     case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE:
         if ( cpu_has_svm_decode && (vmcb->exitinfo1 & (1ULL << 63)) )
             svm_vmexit_do_cr_access(vmcb, regs);
-        else if ( !handle_mmio() ) 
-            hvm_inject_hw_exception(TRAP_gp_fault, 0);
+        else
+            svm_emulate(regs);
         break;
 
     case VMEXIT_INVLPG:
-- 
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 Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcuy-00052b-AT; Sat, 13 Dec 2014 02:58:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcuw-00051w-7d
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:50 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	89/80-11608-96BAB845; Sat, 13 Dec 2014 02:58:49 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418439525!12910788!1
X-Originating-IP: [156.151.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 8425 invoked from network); 13 Dec 2014 02:58: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; 13 Dec 2014 02:58: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 sBD2wihl010987
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58: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
	sBD2whhF021474
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 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
	sBD2whco007049
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:43 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:43 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:25 -0800
Message-Id: <1418439507-16027-5-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
References: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [V0 PATCH 4/6] AMD-PVH: Do not get/set vlapic TPR
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH doesn't use apic emulation hence vlapic->regs ptr is not set for it.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 xen/arch/x86/hvm/svm/svm.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index dac16f4..4bb4ff2 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1052,7 +1052,7 @@ static void noreturn svm_do_resume(struct vcpu *v)
         hvm_asid_flush_vcpu(v);
     }
 
-    if ( !vcpu_guestmode )
+    if ( !vcpu_guestmode && vcpu_vlapic(v)->regs )
     {
         vintr_t intr;
 
@@ -2247,7 +2247,7 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
      * NB. We need to preserve the low bits of the TPR to make checked builds
      * of Windows work, even though they don't actually do anything.
      */
-    if ( !vcpu_guestmode ) {
+    if ( !vcpu_guestmode && vcpu_vlapic(v)->regs ) {
         intr = vmcb_get_vintr(vmcb);
         vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI,
                    ((intr.fields.tpr & 0x0F) << 4) |
@@ -2628,15 +2628,18 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
     }
 
   out:
-    if ( vcpu_guestmode )
-        /* Don't clobber TPR of the nested guest. */
-        return;
-
-    /* The exit may have updated the TPR: reflect this in the hardware vtpr */
-    intr = vmcb_get_vintr(vmcb);
-    intr.fields.tpr =
-        (vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) & 0xFF) >> 4;
-    vmcb_set_vintr(vmcb, intr);
+    /* Don't clobber TPR of the nested guest. */
+    if ( vcpu_guestmode && vcpu_vlapic(v)->regs )
+    {
+        /*
+         * The exit may have updated the TPR: reflect this in the hardware
+         * vtpr.
+         */
+        intr = vmcb_get_vintr(vmcb);
+        intr.fields.tpr =
+            (vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) & 0xFF) >> 4;
+        vmcb_set_vintr(vmcb, intr);
+    }
 }
 
 void svm_trace_vmentry(void)
-- 
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 Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcuy-00052n-PT; Sat, 13 Dec 2014 02:58:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcuw-000528-QP
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:50 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	6A/70-02696-A6BAB845; Sat, 13 Dec 2014 02:58:50 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418439526!14807214!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4276 invoked from network); 13 Dec 2014 02:58:47 -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; 13 Dec 2014 02:58: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 sBD2wj32020565
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58: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
	sBD2wjPN021506
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:45 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
	sBD2wiMa021481
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:43 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:26 -0800
Message-Id: <1418439507-16027-6-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
References: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [V0 PATCH 5/6] AMD-PVH: Support TSC_MODE_NEVER_EMULATE
	for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On AMD, MSR_AMD64_TSC_RATIO must be set for rdtsc instruction in guest
to properly read the cpu tsc. To that end, set tsc_khz in struct domain.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 xen/arch/x86/time.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index bd89219..7512aa4 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1908,6 +1908,7 @@ void tsc_set_info(struct domain *d,
          * but "always_emulate" does not for some reason.  Figure out
          * why.
          */
+        d->arch.tsc_khz = cpu_khz;
         switch ( tsc_mode )
         {
         case TSC_MODE_NEVER_EMULATE:
-- 
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 Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcut-00051T-Kl; Sat, 13 Dec 2014 02:58:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcus-00051H-AN
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:46 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	3E/C0-27584-56BAB845; Sat, 13 Dec 2014 02:58:45 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418439523!7834995!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17267 invoked from network); 13 Dec 2014 02:58:44 -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; 13 Dec 2014 02:58: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 sBD2wgYN020493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:43 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
	sBD2wflG029992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:42 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
	sBD2wfU7029984
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:41 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:41 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:21 -0800
Message-Id: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [AMD PVH]: Partial/domU xen 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

Hi Elena/Boris:

Actually, I forgot I had already made and tested AMD SVM and other changes 
for domU support, please find the patches.

So the only thing remaining for AMD would be iommu support and SVM vmexit 
for CR reads and writes which currently calls handle_mmio (which patch #3
attempted, but improperly).  I believe Jan or Roger is already looking 
into that path, so you could start down the iommu path... the last I 
remember was :

(XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x99, fault address = 0xffffffc0, flags = 0
(XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x91, fault address = 0xffffffc0, flags = 0
(XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x90, fault address = 0xffffffc0, flags = 0

(XEN) Xen call trace:
(XEN)    [<ffff82d08014d600>] parse_event_log_entry+0/0x140
(XEN)    [<ffff82d08014dfdf>] iommu_read_log.constprop.6+0x8f/0x100
(XEN)    [<ffff82d08014e165>] do_amd_iommu_irq+0x115/0x1f0
(XEN)    [<ffff82d0801296d0>] do_tasklet_work+0x60/0xa0
(XEN)    [<ffff82d080129750>] tasklet_softirq_action+0x40/0x70
(XEN)    [<ffff82d080126ee5>] __do_softirq+0x65/0xa0
(XEN)    [<ffff82d0802abe68>] _setup_hwdom_pci_devices+0xa8/0x190
(XEN)    [<ffff82d0802abdc0>] _setup_hwdom_pci_devices+0/0x190
(XEN)    [<ffff82d0801435cb>] pci_segments_iterate+0x2b/0x70
(XEN)    [<ffff82d0802ac2e8>] setup_hwdom_pci_devices+0x28/0x40
(XEN)    [<ffff82d0802aee00>] amd_iommu_setup_hwdom_device+0/0xc0
(XEN)    [<ffff82d0802cbfab>] construct_dom0+0x247b/0x3390
(XEN)    [<ffff82d0802bb810>] bootstrap_map+0/0x10c
(XEN)    [<ffff82d0802bf136>] __start_xen+0x35a6/0x3aa0
(XEN)    [<ffff82d080100067>] __high_start+0x53/0x5c


Thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcuw-000522-3N; Sat, 13 Dec 2014 02:58:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcut-00051O-NY
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:47 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	39/45-02707-66BAB845; Sat, 13 Dec 2014 02:58:46 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418439525!10247694!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18616 invoked from network); 13 Dec 2014 02:58:46 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2014 02:58:46 -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 sBD2widI020515
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 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
	sBD2whii021475
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:43 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
	sBD2whdN021462
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:43 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:42 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:24 -0800
Message-Id: <1418439507-16027-4-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
References: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [V0 PATCH 3/6] AMD-PVH: call hvm_emulate_one instead of
	handle_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Certain IOIO instructions and CR access instructions like
lmsw/clts etc need to be emulated. handle_mmio is incorrectly called to
accomplish this. Create svm_emulate() to call hvm_emulate_one which is more
appropriate, and works for pvh as well. handle_mmio call is
forbidden for pvh.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 xen/arch/x86/hvm/svm/svm.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 4ff4a96..dac16f4 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2209,6 +2209,18 @@ static struct hvm_function_table __initdata svm_function_table = {
     .nhvm_hap_walk_L1_p2m = nsvm_hap_walk_L1_p2m,
 };
 
+static void svm_emulate(struct cpu_user_regs *regs)
+{
+    int rc;
+    struct hvm_emulate_ctxt ctxt;
+
+    hvm_emulate_prepare(&ctxt, regs);
+    rc = hvm_emulate_one(&ctxt);
+
+    if ( rc != X86EMUL_OKAY )
+        hvm_inject_hw_exception(TRAP_gp_fault, 0);
+}
+
 void svm_vmexit_handler(struct cpu_user_regs *regs)
 {
     uint64_t exit_reason;
@@ -2470,16 +2482,16 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
             if ( handle_pio(port, bytes, dir) )
                 __update_guest_eip(regs, vmcb->exitinfo2 - vmcb->rip);
         }
-        else if ( !handle_mmio() )
-            hvm_inject_hw_exception(TRAP_gp_fault, 0);
+        else
+            svm_emulate(regs);
         break;
 
     case VMEXIT_CR0_READ ... VMEXIT_CR15_READ:
     case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE:
         if ( cpu_has_svm_decode && (vmcb->exitinfo1 & (1ULL << 63)) )
             svm_vmexit_do_cr_access(vmcb, regs);
-        else if ( !handle_mmio() ) 
-            hvm_inject_hw_exception(TRAP_gp_fault, 0);
+        else
+            svm_emulate(regs);
         break;
 
     case VMEXIT_INVLPG:
-- 
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 Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcuv-00051u-KX; Sat, 13 Dec 2014 02:58:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcut-00051N-M0
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:47 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	85/E2-02576-66BAB845; Sat, 13 Dec 2014 02:58:46 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418439524!14778999!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10280 invoked from network); 13 Dec 2014 02:58:46 -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; 13 Dec 2014 02:58:46 -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 sBD2whnH020514
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 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
	sBD2whtD007048
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:43 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
	sBD2wgCP021449
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:42 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:41 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:22 -0800
Message-Id: <1418439507-16027-2-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
References: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [V0 PATCH 1/6] AMD-PVH: construct vmcb changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH guest starts in Long 64bit paging mode. This patch modifies
construct_vmcb for that.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 xen/arch/x86/hvm/svm/vmcb.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 21292bb..5df5f36 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -138,6 +138,8 @@ static int construct_vmcb(struct vcpu *v)
 
     /* Guest EFER. */
     v->arch.hvm_vcpu.guest_efer = 0;
+    if ( is_pvh_vcpu(v) )
+        v->arch.hvm_vcpu.guest_efer |= EFER_LMA;   /* PVH 32bitfixme */
     hvm_update_guest_efer(v);
 
     /* Guest segment limits. */
@@ -162,7 +164,12 @@ static int construct_vmcb(struct vcpu *v)
     vmcb->ds.attr.bytes = 0xc93;
     vmcb->fs.attr.bytes = 0xc93;
     vmcb->gs.attr.bytes = 0xc93;
-    vmcb->cs.attr.bytes = 0xc9b; /* exec/read, accessed */
+
+    if ( is_pvh_vcpu(v) )
+        /* CS.L == 1, exec, read/write, accessed. PVH 32bitfixme. */
+        vmcb->cs.attr.bytes = 0xa9b;
+    else
+        vmcb->cs.attr.bytes = 0xc9b; /* exec/read, accessed */
 
     /* Guest IDT. */
     vmcb->idtr.base = 0;
@@ -184,12 +191,17 @@ static int construct_vmcb(struct vcpu *v)
     vmcb->tr.limit = 0xff;
 
     v->arch.hvm_vcpu.guest_cr[0] = X86_CR0_PE | X86_CR0_ET;
+    /* PVH domains start in paging mode */
+    if ( is_pvh_vcpu(v) )
+        v->arch.hvm_vcpu.guest_cr[0] |= X86_CR0_PG;
     hvm_update_guest_cr(v, 0);
 
-    v->arch.hvm_vcpu.guest_cr[4] = 0;
+    v->arch.hvm_vcpu.guest_cr[4] = is_pvh_vcpu(v) ? X86_CR4_PAE : 0;
     hvm_update_guest_cr(v, 4);
 
-    paging_update_paging_modes(v);
+    /* For pvh, paging mode is updated by arch_set_info_guest(). */
+    if ( is_hvm_vcpu(v) )
+        paging_update_paging_modes(v);
 
     vmcb->_exception_intercepts =
         HVM_TRAP_MASK
-- 
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 Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcuv-00051n-5t; Sat, 13 Dec 2014 02:58:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcut-00051M-Ao
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	18/09-09842-66BAB845; Sat, 13 Dec 2014 02:58:46 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418439524!15281599!1
X-Originating-IP: [156.151.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 20430 invoked from network); 13 Dec 2014 02:58:45 -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; 13 Dec 2014 02:58: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 sBD2whRx010948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 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
	sBD2wg5w021457
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:43 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
	sBD2wg1u007038
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:42 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:42 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:23 -0800
Message-Id: <1418439507-16027-3-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
References: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [V0 PATCH 2/6] AMD-PVH: cpuid intercept
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Call pv_cpuid for pvh cpuid intercept. Note, we modify
svm_vmexit_do_cpuid instead of the intercept switch because the guest
eip needs to be adjusted for pvh also.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 xen/arch/x86/hvm/svm/svm.c | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 71b8a6a..4ff4a96 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1517,18 +1517,22 @@ static void svm_vmexit_do_cpuid(struct cpu_user_regs *regs)
     if ( (inst_len = __get_instruction_length(current, INSTR_CPUID)) == 0 )
         return;
 
-    eax = regs->eax;
-    ebx = regs->ebx;
-    ecx = regs->ecx;
-    edx = regs->edx;
-
-    svm_cpuid_intercept(&eax, &ebx, &ecx, &edx);
+    if ( is_pvh_vcpu(current) )
+        pv_cpuid(regs);
+    else
+    {
+        eax = regs->eax;
+        ebx = regs->ebx;
+        ecx = regs->ecx;
+        edx = regs->edx;
 
-    regs->eax = eax;
-    regs->ebx = ebx;
-    regs->ecx = ecx;
-    regs->edx = edx;
+        svm_cpuid_intercept(&eax, &ebx, &ecx, &edx);
 
+        regs->eax = eax;
+        regs->ebx = ebx;
+        regs->ecx = ecx;
+        regs->edx = edx;
+    }
     __update_guest_eip(regs, inst_len);
 }
 
-- 
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 Sat Dec 13 02:59:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 02:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzcuw-00052N-RR; Sat, 13 Dec 2014 02:58:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Xzcuu-00051i-Qi
	for xen-devel@lists.xenproject.org; Sat, 13 Dec 2014 02:58:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	22/A9-25276-86BAB845; Sat, 13 Dec 2014 02:58:48 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418439526!14970476!1
X-Originating-IP: [156.151.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 14068 invoked from network); 13 Dec 2014 02:58:47 -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; 13 Dec 2014 02:58: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 sBD2wjXC010994
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:45 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
	sBD2wirb000057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 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
	sBD2wiPH000054
	for <xen-devel@lists.xenproject.org>; Sat, 13 Dec 2014 02:58:44 GMT
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Dec 2014 18:58:44 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: boris.ostrovsky@oracle.com, elena.ufimtseva@oracle.com
Date: Fri, 12 Dec 2014 18:58:27 -0800
Message-Id: <1418439507-16027-7-git-send-email-mukesh.rathor@oracle.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
References: <1418439507-16027-1-git-send-email-mukesh.rathor@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xenproject.org
Subject: [Xen-devel] [V0 PATCH 6/6] AMD-PVH: enable pvh if requirements met
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Finally, enable pvh if the cpu supports NPT and svm decode.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 xen/arch/x86/hvm/svm/svm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 4bb4ff2..8b27a76 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1390,6 +1390,9 @@ const struct hvm_function_table * __init start_svm(void)
     svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB |
         ((cpuid_edx(0x80000001) & 0x04000000) ? HVM_HAP_SUPERPAGE_1GB : 0);
 
+    if ( cpu_has_svm_npt  && cpu_has_svm_decode )
+        svm_function_table.pvh_supported = 1;
+
     return &svm_function_table;
 }
 
-- 
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 Sat Dec 13 03:48:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 03: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 1XzdgJ-00072Y-02; Sat, 13 Dec 2014 03:47: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 1XzdgH-00072T-BP
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 03:47:45 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	49/E6-19763-0E6BB845; Sat, 13 Dec 2014 03:47:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418442462!7837044!1
X-Originating-IP: [66.165.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 3628 invoked from network); 13 Dec 2014 03:47:43 -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;
	13 Dec 2014 03:47:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,569,1413244800"; d="scan'208";a="203742956"
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.210.2; Fri, 12 Dec 2014 22:47: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 1Xzdfz-000136-Uu;
	Sat, 13 Dec 2014 03:47:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xzdfz-0006PR-H5;
	Sat, 13 Dec 2014 03:47:27 +0000
Date: Sat, 13 Dec 2014 03:47:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32294-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 7613
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32294: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8911251445670064011=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8911251445670064011==
Content-Type: text/plain
Content-Length: 7283
Content-Transfer-Encoding: quoted-printable

flight 32294 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32294/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32194

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-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-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-armhf-armhf-xl          10 migrate-support-check        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                b141290478f847ecaa25561f3b31fbf1ddde95e6
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Anton Blanchard <anton@samba.org>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Christoffer Dall <christoffer.dall@linaro.org>
  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>
  Jeff Cody <jcody@redhat.com>
  Kevin Wolf <kwolf@redhat.com>
  Liviu Ionescu <ilg@livius.net>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael Mueller <mimu@linux.vnet.ibm.com>
  Nikita Belov <zodiac@ispras.ru>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Sergey Fedorov <s.fedorov@samsung.com>
  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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 2121 lines long.)


--===============8911251445670064011==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8911251445670064011==--

From xen-devel-bounces@lists.xen.org Sat Dec 13 03:48:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 03: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 1XzdgJ-00072Y-02; Sat, 13 Dec 2014 03:47: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 1XzdgH-00072T-BP
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 03:47:45 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	49/E6-19763-0E6BB845; Sat, 13 Dec 2014 03:47:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418442462!7837044!1
X-Originating-IP: [66.165.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 3628 invoked from network); 13 Dec 2014 03:47:43 -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;
	13 Dec 2014 03:47:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,569,1413244800"; d="scan'208";a="203742956"
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.210.2; Fri, 12 Dec 2014 22:47: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 1Xzdfz-000136-Uu;
	Sat, 13 Dec 2014 03:47:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xzdfz-0006PR-H5;
	Sat, 13 Dec 2014 03:47:27 +0000
Date: Sat, 13 Dec 2014 03:47:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32294-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 7613
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32294: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8911251445670064011=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8911251445670064011==
Content-Type: text/plain
Content-Length: 7283
Content-Transfer-Encoding: quoted-printable

flight 32294 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32294/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32194

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-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-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-armhf-armhf-xl          10 migrate-support-check        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                b141290478f847ecaa25561f3b31fbf1ddde95e6
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Anton Blanchard <anton@samba.org>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Christoffer Dall <christoffer.dall@linaro.org>
  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>
  Jeff Cody <jcody@redhat.com>
  Kevin Wolf <kwolf@redhat.com>
  Liviu Ionescu <ilg@livius.net>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael Mueller <mimu@linux.vnet.ibm.com>
  Nikita Belov <zodiac@ispras.ru>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Sergey Fedorov <s.fedorov@samsung.com>
  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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 2121 lines long.)


--===============8911251445670064011==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8911251445670064011==--

From xen-devel-bounces@lists.xen.org Sat Dec 13 04:59:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 04: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 1Xzemz-0000V5-Uo; Sat, 13 Dec 2014 04:58:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xzemz-0000V0-8z
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 04:58:45 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	58/A2-24124-487CB845; Sat, 13 Dec 2014 04:58:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418446722!9009845!1
X-Originating-IP: [66.165.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 20821 invoked from network); 13 Dec 2014 04:58:43 -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 Dec 2014 04:58:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,569,1413244800"; d="scan'208";a="203758357"
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.210.2; Fri, 12 Dec 2014 23:58: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 1Xzemu-0001O7-BW;
	Sat, 13 Dec 2014 04:58:40 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xzemt-0001Xo-Ox;
	Sat, 13 Dec 2014 04:58:40 +0000
Date: Sat, 13 Dec 2014 04:58:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32291-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] 32291: 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 32291 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32291/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair         17 guest-migrate/src_host/dst_host fail like 31897
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31897

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
 build-amd64-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-amd64-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
 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-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-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-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-i386-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-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  353de6b221c2d0fb59edfceb1f535357e4d84825
baseline version:
 xen                  3e5c06aeea1ff91c3f2247baae372936b67cf411

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-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=353de6b221c2d0fb59edfceb1f535357e4d84825
+ . 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 353de6b221c2d0fb59edfceb1f535357e4d84825
+ branch=xen-4.2-testing
+ revision=353de6b221c2d0fb59edfceb1f535357e4d84825
+ . 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 353de6b221c2d0fb59edfceb1f535357e4d84825:stable-4.2
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   3e5c06a..353de6b  353de6b221c2d0fb59edfceb1f535357e4d84825 -> 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 Dec 13 04:59:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 04: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 1Xzemz-0000V5-Uo; Sat, 13 Dec 2014 04:58:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Xzemz-0000V0-8z
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 04:58:45 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	58/A2-24124-487CB845; Sat, 13 Dec 2014 04:58:44 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418446722!9009845!1
X-Originating-IP: [66.165.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 20821 invoked from network); 13 Dec 2014 04:58:43 -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 Dec 2014 04:58:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,569,1413244800"; d="scan'208";a="203758357"
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.210.2; Fri, 12 Dec 2014 23:58: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 1Xzemu-0001O7-BW;
	Sat, 13 Dec 2014 04:58:40 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xzemt-0001Xo-Ox;
	Sat, 13 Dec 2014 04:58:40 +0000
Date: Sat, 13 Dec 2014 04:58:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32291-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] 32291: 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 32291 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32291/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pair         17 guest-migrate/src_host/dst_host fail like 31897
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 31897

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
 build-amd64-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-amd64-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
 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-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-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-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-i386-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-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  353de6b221c2d0fb59edfceb1f535357e4d84825
baseline version:
 xen                  3e5c06aeea1ff91c3f2247baae372936b67cf411

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-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=353de6b221c2d0fb59edfceb1f535357e4d84825
+ . 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 353de6b221c2d0fb59edfceb1f535357e4d84825
+ branch=xen-4.2-testing
+ revision=353de6b221c2d0fb59edfceb1f535357e4d84825
+ . 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 353de6b221c2d0fb59edfceb1f535357e4d84825:stable-4.2
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   3e5c06a..353de6b  353de6b221c2d0fb59edfceb1f535357e4d84825 -> 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 Dec 13 07:38:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 07:38:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzhHQ-00044u-Sj; Sat, 13 Dec 2014 07:38: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 1XzhHP-00044p-5V
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 07:38:19 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	C7/F9-25714-AECEB845; Sat, 13 Dec 2014 07:38:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418456295!5557497!1
X-Originating-IP: [66.165.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 13755 invoked from network); 13 Dec 2014 07:38:17 -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;
	13 Dec 2014 07:38:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,570,1413244800"; d="scan'208";a="203790960"
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.210.2; Sat, 13 Dec 2014 02:37: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 1XzhH4-0002BD-Ch;
	Sat, 13 Dec 2014 07:37:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzhGA-0000Bt-Mm;
	Sat, 13 Dec 2014 07:37:57 +0000
Date: Sat, 13 Dec 2014 07:37:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32298-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] 32298: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32298 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32298/

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. 32231

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32231

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-amd64-libvirt      9 guest-start                  fail   never pass
 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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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                  7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
baseline version:
 xen                  de6313ab40a2858693609338db935cb689380361

------------------------------------------------------------
People who touched revisions under test:
  Frediano Ziglio <frediano.ziglio@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Julien Grall <julien.grall@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.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                                         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 7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
Author: Frediano Ziglio <frediano.ziglio@huawei.com>
Date:   Thu Oct 23 17:18:52 2014 +0100

    xen/arm: dump guest stack even if not the current VCPU
    
    If show_guest_stack was called from Xen context (for instance hitting
    '0' key on Xen console) get_page_from_gva was not able to get the
    page returning NULL.
    Detecting different domain and changing VTTBR register make
    get_page_from_gva works for different domains.
    
    Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    (cherry picked from commit 281c892e3bdb0a56cfd8ab6516cd1a33c095c857)

commit af73321f101962c69d48daf21bfe09b87a49b459
Author: Julien Grall <julien.grall@linaro.org>
Date:   Fri Nov 28 15:17:06 2014 +0000

    xen/arm: Handle platforms with edge-triggered virtual timer
    
    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>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    [ ijc -- tweaked some wording in the comment ]
    (cherry picked from commit f688aec47c452d6aef382739d0781735672ef995)

commit dcb95321d24d3659d5bfa61fe9b0e0e5a5bfe32c
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Jun 24 19:30:00 2014 +0100

    call vgic_en/disable_irqs holding the rank_lock
    
    Modifying ienable and calling vgic_enable_irqs or vgic_disable_irqs need
    to be atomic. Move the calls to vgic_enable_irqs and vgic_disable_irqs
    before releasing the rank lock.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    [ ijc -- partial backport of just the locking part of 5b3a817ea33b
             "xen/arm: observe itargets setting in vgic_enable_irqs and
             vgic_disable_irqs"
    ]

commit c3ed5de85e7916d70ac8f1e741d5fe31c719004c
Author: Julien Grall <julien.grall@linaro.org>
Date:   Fri Jul 25 15:17:26 2014 +0100

    xen/arm: domain_vgic_init: Avoid double free on shared_irqs
    
    When the function domain_vgic_init is failing to initialize pending_irqs,
    it will free shared_irqs. Few call later, domain_vgic_free will be called
    an try to free a second time the same variable. This will result to a double
    free.
    
    Remove the free in domain_vgic_init and rely on domain_vgic_free to correctly
    release the memory.
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    (cherry picked from commit 7b41618f5a08145b0198af4a8a2ce361d7e677e6)
(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 Dec 13 07:38:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 07:38:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzhHQ-00044u-Sj; Sat, 13 Dec 2014 07:38: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 1XzhHP-00044p-5V
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 07:38:19 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	C7/F9-25714-AECEB845; Sat, 13 Dec 2014 07:38:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418456295!5557497!1
X-Originating-IP: [66.165.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 13755 invoked from network); 13 Dec 2014 07:38:17 -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;
	13 Dec 2014 07:38:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,570,1413244800"; d="scan'208";a="203790960"
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.210.2; Sat, 13 Dec 2014 02:37: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 1XzhH4-0002BD-Ch;
	Sat, 13 Dec 2014 07:37:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XzhGA-0000Bt-Mm;
	Sat, 13 Dec 2014 07:37:57 +0000
Date: Sat, 13 Dec 2014 07:37:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32298-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] 32298: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32298 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32298/

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. 32231

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32231

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-amd64-libvirt      9 guest-start                  fail   never pass
 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
 build-i386-rumpuserxen        6 xen-build                    fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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                  7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
baseline version:
 xen                  de6313ab40a2858693609338db935cb689380361

------------------------------------------------------------
People who touched revisions under test:
  Frediano Ziglio <frediano.ziglio@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Julien Grall <julien.grall@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.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                                         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 7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
Author: Frediano Ziglio <frediano.ziglio@huawei.com>
Date:   Thu Oct 23 17:18:52 2014 +0100

    xen/arm: dump guest stack even if not the current VCPU
    
    If show_guest_stack was called from Xen context (for instance hitting
    '0' key on Xen console) get_page_from_gva was not able to get the
    page returning NULL.
    Detecting different domain and changing VTTBR register make
    get_page_from_gva works for different domains.
    
    Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    (cherry picked from commit 281c892e3bdb0a56cfd8ab6516cd1a33c095c857)

commit af73321f101962c69d48daf21bfe09b87a49b459
Author: Julien Grall <julien.grall@linaro.org>
Date:   Fri Nov 28 15:17:06 2014 +0000

    xen/arm: Handle platforms with edge-triggered virtual timer
    
    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>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    [ ijc -- tweaked some wording in the comment ]
    (cherry picked from commit f688aec47c452d6aef382739d0781735672ef995)

commit dcb95321d24d3659d5bfa61fe9b0e0e5a5bfe32c
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Jun 24 19:30:00 2014 +0100

    call vgic_en/disable_irqs holding the rank_lock
    
    Modifying ienable and calling vgic_enable_irqs or vgic_disable_irqs need
    to be atomic. Move the calls to vgic_enable_irqs and vgic_disable_irqs
    before releasing the rank lock.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    [ ijc -- partial backport of just the locking part of 5b3a817ea33b
             "xen/arm: observe itargets setting in vgic_enable_irqs and
             vgic_disable_irqs"
    ]

commit c3ed5de85e7916d70ac8f1e741d5fe31c719004c
Author: Julien Grall <julien.grall@linaro.org>
Date:   Fri Jul 25 15:17:26 2014 +0100

    xen/arm: domain_vgic_init: Avoid double free on shared_irqs
    
    When the function domain_vgic_init is failing to initialize pending_irqs,
    it will free shared_irqs. Few call later, domain_vgic_free will be called
    an try to free a second time the same variable. This will result to a double
    free.
    
    Remove the free in domain_vgic_init and rely on domain_vgic_free to correctly
    release the memory.
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    (cherry picked from commit 7b41618f5a08145b0198af4a8a2ce361d7e677e6)
(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 Dec 13 09:34:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 09:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzj50-0006um-MO; Sat, 13 Dec 2014 09:33: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 1Xzj4z-0006uh-4Z
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 09:33:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5F/E7-25276-0F70C845; Sat, 13 Dec 2014 09:33:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418463213!7317160!1
X-Originating-IP: [66.165.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 8991 invoked from network); 13 Dec 2014 09:33:34 -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 Dec 2014 09:33:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,570,1413244800"; d="scan'208";a="204217161"
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.210.2; Sat, 13 Dec 2014 04:33: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 1Xzj4s-00030B-Fy;
	Sat, 13 Dec 2014 09:33:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xzj4r-0002hd-RU;
	Sat, 13 Dec 2014 09:33:30 +0000
Date: Sat, 13 Dec 2014 09:33:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32308-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8185
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32308: 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="===============0889937277735910001=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0889937277735910001==
Content-Type: text/plain
Content-Length: 7910
Content-Transfer-Encoding: quoted-printable

flight 32308 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32308/

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              15abebdecb35308ddd4d2967efa6dffa4842fac9
baseline version:
 libvirt              82977058f5b1d143a355079900029e9cbfee2fe4

------------------------------------------------------------
People who touched revisions under test:
  Francesco Romani <fromani@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Luyao Huang <lhuang@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=3D15abebdecb35308ddd4d2967efa6dffa4842fac9
+ . 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 15abebdecb35308ddd4d2967efa6dffa4842fac9
+ branch=3Dlibvirt
+ revision=3D15abebdecb35308ddd4d2967efa6dffa4842fac9
+ . 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 15abebdecb35308ddd4d2967efa6dffa4842fac9:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   8297705..15abebd  15abebdecb35308ddd4d2967efa6dffa4842fac9 -> xen-tested-master


--===============0889937277735910001==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0889937277735910001==--

From xen-devel-bounces@lists.xen.org Sat Dec 13 09:34:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 09:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzj50-0006um-MO; Sat, 13 Dec 2014 09:33: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 1Xzj4z-0006uh-4Z
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 09:33:37 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	5F/E7-25276-0F70C845; Sat, 13 Dec 2014 09:33:36 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418463213!7317160!1
X-Originating-IP: [66.165.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 8991 invoked from network); 13 Dec 2014 09:33:34 -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 Dec 2014 09:33:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,570,1413244800"; d="scan'208";a="204217161"
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.210.2; Sat, 13 Dec 2014 04:33: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 1Xzj4s-00030B-Fy;
	Sat, 13 Dec 2014 09:33:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xzj4r-0002hd-RU;
	Sat, 13 Dec 2014 09:33:30 +0000
Date: Sat, 13 Dec 2014 09:33:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32308-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8185
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32308: 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="===============0889937277735910001=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0889937277735910001==
Content-Type: text/plain
Content-Length: 7910
Content-Transfer-Encoding: quoted-printable

flight 32308 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32308/

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              15abebdecb35308ddd4d2967efa6dffa4842fac9
baseline version:
 libvirt              82977058f5b1d143a355079900029e9cbfee2fe4

------------------------------------------------------------
People who touched revisions under test:
  Francesco Romani <fromani@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Luyao Huang <lhuang@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=3D15abebdecb35308ddd4d2967efa6dffa4842fac9
+ . 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 15abebdecb35308ddd4d2967efa6dffa4842fac9
+ branch=3Dlibvirt
+ revision=3D15abebdecb35308ddd4d2967efa6dffa4842fac9
+ . 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 15abebdecb35308ddd4d2967efa6dffa4842fac9:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   8297705..15abebd  15abebdecb35308ddd4d2967efa6dffa4842fac9 -> xen-tested-master


--===============0889937277735910001==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0889937277735910001==--

From xen-devel-bounces@lists.xen.org Sat Dec 13 14:04:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 14:04:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XznIA-00041P-BW; Sat, 13 Dec 2014 14:03:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XznI9-00041K-7K
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 14:03:29 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	E8/34-19763-0374C845; Sat, 13 Dec 2014 14:03:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418479406!13157271!1
X-Originating-IP: [66.165.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 13864 invoked from network); 13 Dec 2014 14:03:27 -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;
	13 Dec 2014 14:03:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="204265693"
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.210.2; Sat, 13 Dec 2014 09:03: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 1XznI3-0004HN-2L;
	Sat, 13 Dec 2014 14:03:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XznI2-0008Qm-75;
	Sat, 13 Dec 2014 14:03:22 +0000
Date: Sat, 13 Dec 2014 14:03:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32312-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] 32312: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32312 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32312/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 32222
 test-amd64-i386-libvirt       5 xen-boot                  fail REGR. vs. 32222
 test-amd64-amd64-libvirt      5 xen-boot                  fail REGR. vs. 32222
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 32222
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot            fail REGR. vs. 32222
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 32222
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 32222
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 32222
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32222
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 32222
 test-amd64-i386-freebsd10-amd64  5 xen-boot               fail REGR. vs. 32222
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32222
 test-amd64-i386-freebsd10-i386  5 xen-boot                fail REGR. vs. 32222
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 32222
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot           fail REGR. vs. 32222
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32222
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot             fail REGR. vs. 32222
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32222
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32222
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32222
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot           fail REGR. vs. 32222
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 32222
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 32222
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 32222
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32222
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32222
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot          fail REGR. vs. 32222
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32222
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32222
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 32222
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 32222
 test-amd64-i386-xl-winxpsp3   5 xen-boot                  fail REGR. vs. 32222
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot             fail REGR. vs. 32222
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 32222
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 32222
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot            fail REGR. vs. 32222
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 32222
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32222
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 32222
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32222
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 32222

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 32222
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 32222
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 32222

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

version targeted for testing:
 linux                f4aec88d2134e8ace530be28db614e383961b9c8
baseline version:
 linux                a0e4467726cd26bacb16f13d207ffcfa82ffc07d

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                                 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 Dec 13 14:04:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 14:04:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XznIA-00041P-BW; Sat, 13 Dec 2014 14:03:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1XznI9-00041K-7K
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 14:03:29 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	E8/34-19763-0374C845; Sat, 13 Dec 2014 14:03:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418479406!13157271!1
X-Originating-IP: [66.165.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 13864 invoked from network); 13 Dec 2014 14:03:27 -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;
	13 Dec 2014 14:03:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="204265693"
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.210.2; Sat, 13 Dec 2014 09:03: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 1XznI3-0004HN-2L;
	Sat, 13 Dec 2014 14:03:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XznI2-0008Qm-75;
	Sat, 13 Dec 2014 14:03:22 +0000
Date: Sat, 13 Dec 2014 14:03:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32312-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] 32312: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32312 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32312/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 32222
 test-amd64-i386-libvirt       5 xen-boot                  fail REGR. vs. 32222
 test-amd64-amd64-libvirt      5 xen-boot                  fail REGR. vs. 32222
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 32222
 test-amd64-amd64-rumpuserxen-amd64  5 xen-boot            fail REGR. vs. 32222
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 32222
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 32222
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 32222
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32222
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 32222
 test-amd64-i386-freebsd10-amd64  5 xen-boot               fail REGR. vs. 32222
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32222
 test-amd64-i386-freebsd10-i386  5 xen-boot                fail REGR. vs. 32222
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 32222
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot           fail REGR. vs. 32222
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32222
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot             fail REGR. vs. 32222
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32222
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32222
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32222
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot           fail REGR. vs. 32222
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 32222
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 32222
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot          fail REGR. vs. 32222
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32222
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  5 xen-boot     fail REGR. vs. 32222
 test-amd64-amd64-xl-qemuu-ovmf-amd64  5 xen-boot          fail REGR. vs. 32222
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32222
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32222
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 32222
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 32222
 test-amd64-i386-xl-winxpsp3   5 xen-boot                  fail REGR. vs. 32222
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot             fail REGR. vs. 32222
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 32222
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 32222
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot            fail REGR. vs. 32222
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 32222
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32222
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 32222
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32222
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 32222

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 32222
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 32222
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 32222

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

version targeted for testing:
 linux                f4aec88d2134e8ace530be28db614e383961b9c8
baseline version:
 linux                a0e4467726cd26bacb16f13d207ffcfa82ffc07d

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                                 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 Dec 13 16:06:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 16: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 1XzpCu-0006nP-Pi; Sat, 13 Dec 2014 16:06:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XzpCt-0006nK-5d
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 16:06:11 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	14/D4-22737-2F36C845; Sat, 13 Dec 2014 16:06:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418486768!13171268!1
X-Originating-IP: [66.165.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 23654 invoked from network); 13 Dec 2014 16:06:09 -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;
	13 Dec 2014 16:06:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="204289314"
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.210.2;
	Sat, 13 Dec 2014 11:06: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 1XzpCo-000553-RC;
	Sat, 13 Dec 2014 16:06:06 +0000
Date: Sat, 13 Dec 2014 16:06:06 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141213160606.GA2285@zion.uk.xensource.com>
References: <1417536141.29004.6.camel@citrix.com>
	<1417536299-1810-18-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417536299-1810-18-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Jim Fehlig <jfehlig@suse.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v2 18/18] WIP: libvirt: migration +
 save/restore support.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 04:04:59PM +0000, Ian Campbell wrote:
> Note that this remains stubbed out, since making it actually work
> requires more work (i.e. I need to figure out what is involved, seem
> to need TLS and a CA etc...)
> 
> Appears to need gnutls enabling for migration, even to localhost.
> 
> NB haven't managed to get this actually working. With GNUtls enabled
> it wants a CA certificate installed:
>     error: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory
> 
> Other attempts give:
>     # virsh migrate --live debian.guest.osstest xen://
>     error: Requested operation is not valid: domain 'debian.guest.osstest' is already active
> 
> Also need to try tcp:// based, by bodging libvirtd.conf to turn on
> tcp.
> 

Tried this. It didn't make any difference with regard to the error
message you saw, i.e. it's the same as above.

I've also played with changing domain name and UUID (since they are what
libvirt is checking), but  it didn't work either. Error messages were
different but libvirt still refuses to migrate to localhost.

On the other hand, save and restore worked just fine. I have a patch to
implement save and restore, which is literally calling "virsh save" and
"virsh restore".

One way to move forward is to separate the concept of migration support
and save / restore support, so that we can test save / restore for
libvirt, even if we can test local migration at the moment.

Of course if we can get local migration to work that would be best.

> TODO: Ask Jim for advice...
> 

Jim, any suggestion?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 13 16:06:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 16: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 1XzpCu-0006nP-Pi; Sat, 13 Dec 2014 16:06:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1XzpCt-0006nK-5d
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 16:06:11 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	14/D4-22737-2F36C845; Sat, 13 Dec 2014 16:06:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418486768!13171268!1
X-Originating-IP: [66.165.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 23654 invoked from network); 13 Dec 2014 16:06:09 -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;
	13 Dec 2014 16:06:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="204289314"
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.210.2;
	Sat, 13 Dec 2014 11:06: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 1XzpCo-000553-RC;
	Sat, 13 Dec 2014 16:06:06 +0000
Date: Sat, 13 Dec 2014 16:06:06 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20141213160606.GA2285@zion.uk.xensource.com>
References: <1417536141.29004.6.camel@citrix.com>
	<1417536299-1810-18-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1417536299-1810-18-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Jim Fehlig <jfehlig@suse.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH OSSTEST v2 18/18] WIP: libvirt: migration +
 save/restore support.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 02, 2014 at 04:04:59PM +0000, Ian Campbell wrote:
> Note that this remains stubbed out, since making it actually work
> requires more work (i.e. I need to figure out what is involved, seem
> to need TLS and a CA etc...)
> 
> Appears to need gnutls enabling for migration, even to localhost.
> 
> NB haven't managed to get this actually working. With GNUtls enabled
> it wants a CA certificate installed:
>     error: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory
> 
> Other attempts give:
>     # virsh migrate --live debian.guest.osstest xen://
>     error: Requested operation is not valid: domain 'debian.guest.osstest' is already active
> 
> Also need to try tcp:// based, by bodging libvirtd.conf to turn on
> tcp.
> 

Tried this. It didn't make any difference with regard to the error
message you saw, i.e. it's the same as above.

I've also played with changing domain name and UUID (since they are what
libvirt is checking), but  it didn't work either. Error messages were
different but libvirt still refuses to migrate to localhost.

On the other hand, save and restore worked just fine. I have a patch to
implement save and restore, which is literally calling "virsh save" and
"virsh restore".

One way to move forward is to separate the concept of migration support
and save / restore support, so that we can test save / restore for
libvirt, even if we can test local migration at the moment.

Of course if we can get local migration to work that would be best.

> TODO: Ask Jim for advice...
> 

Jim, any suggestion?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 13 16:45:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 16:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzpp3-0007eP-2I; Sat, 13 Dec 2014 16: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 1Xzpp1-0007eK-3B
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 16:45:35 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	2A/EE-26652-E2D6C845; Sat, 13 Dec 2014 16:45:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418489132!13194713!1
X-Originating-IP: [66.165.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 11845 invoked from network); 13 Dec 2014 16:45:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 16:45:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="203887141"
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.210.2;
	Sat, 13 Dec 2014 11:45: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 1Xzpos-0005ho-Pk;
	Sat, 13 Dec 2014 16:45:26 +0000
Date: Sat, 13 Dec 2014 16:45:26 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Mark Pryor <tlviewer@yahoo.com>
Message-ID: <20141213164526.GB2285@zion.uk.xensource.com>
References: <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
MIME-Version: 1.0
Content-Length: 1200
Content-Disposition: inline
In-Reply-To: <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.5 patch: xendomains noise to stderr in rdname()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Dec 13, 2014 at 01:34:14AM +0000, Mark Pryor wrote:
> Instead of tracking down which commit involving libxl* which prints all k=
ind of noiseto stderr, I will post a workaround. =


Though I think I am able to guess what log you were seeing, it would be
better in the future if you attach actual log for a bug report.

I will post a patch for this.

Wei.

> =

> If you build, install, and use 4.5 this bug will drive you mad, so here i=
t is:
> -------------------- snip -----------------
> --- a/tools/hotplug/Linux/xendomains.in+++ b/tools/hotplug/Linux/xendomai=
ns.in
> @@ -175,7 +175,7 @@ contains_something()
> =A0# read name from xen config file
> =A0rdname()
> =A0{
> -=A0=A0=A0 NM=3D$($CMD create --quiet --dryrun --defconfig "$1" |
> +=A0=A0=A0 NM=3D$($CMD create --quiet --dryrun --defconfig "$1" 2>&1 |
> =A0=A0=A0=A0=A0=A0=A0=A0=A0 sed -n 's/^.*(name \(.*\))$/\1/p;s/^.*"name":=
 "\(.*\)",$/\1/p')
> =A0}
> =

> =


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 13 16:45:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 16:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzpp3-0007eP-2I; Sat, 13 Dec 2014 16: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 1Xzpp1-0007eK-3B
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 16:45:35 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	2A/EE-26652-E2D6C845; Sat, 13 Dec 2014 16:45:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418489132!13194713!1
X-Originating-IP: [66.165.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 11845 invoked from network); 13 Dec 2014 16:45:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 16:45:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="203887141"
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.210.2;
	Sat, 13 Dec 2014 11:45: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 1Xzpos-0005ho-Pk;
	Sat, 13 Dec 2014 16:45:26 +0000
Date: Sat, 13 Dec 2014 16:45:26 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Mark Pryor <tlviewer@yahoo.com>
Message-ID: <20141213164526.GB2285@zion.uk.xensource.com>
References: <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
MIME-Version: 1.0
Content-Length: 1200
Content-Disposition: inline
In-Reply-To: <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.5 patch: xendomains noise to stderr in rdname()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Dec 13, 2014 at 01:34:14AM +0000, Mark Pryor wrote:
> Instead of tracking down which commit involving libxl* which prints all k=
ind of noiseto stderr, I will post a workaround. =


Though I think I am able to guess what log you were seeing, it would be
better in the future if you attach actual log for a bug report.

I will post a patch for this.

Wei.

> =

> If you build, install, and use 4.5 this bug will drive you mad, so here i=
t is:
> -------------------- snip -----------------
> --- a/tools/hotplug/Linux/xendomains.in+++ b/tools/hotplug/Linux/xendomai=
ns.in
> @@ -175,7 +175,7 @@ contains_something()
> =A0# read name from xen config file
> =A0rdname()
> =A0{
> -=A0=A0=A0 NM=3D$($CMD create --quiet --dryrun --defconfig "$1" |
> +=A0=A0=A0 NM=3D$($CMD create --quiet --dryrun --defconfig "$1" 2>&1 |
> =A0=A0=A0=A0=A0=A0=A0=A0=A0 sed -n 's/^.*(name \(.*\))$/\1/p;s/^.*"name":=
 "\(.*\)",$/\1/p')
> =A0}
> =

> =


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 13 16:54:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 16:54:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzpxM-0007yu-5z; Sat, 13 Dec 2014 16:54:12 +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 1XzpxK-0007yk-Nn
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 16:54:10 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	20/72-27785-23F6C845; Sat, 13 Dec 2014 16:54:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418489648!14875729!1
X-Originating-IP: [66.165.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 17661 invoked from network); 13 Dec 2014 16:54:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 16:54:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="204297808"
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.210.2;
	Sat, 13 Dec 2014 11:54:07 -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 1XzpxG-0005uS-8f;
	Sat, 13 Dec 2014 16:54:06 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Sat, 13 Dec 2014 16:54:05 +0000
Message-ID: <1418489645-7689-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: tlviewer@yahoo.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, M A Young <m.a.young@durham.ac.uk>
Subject: [Xen-devel] [PATCH for-4.5] xl: print message to stdout when
	(!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 commit d36a3734a ("xl: fix migration failure with xl migrate
--debug"), message is printed to stderr for both debug mode
and dryrun mode. That caused rdname() in xendomains fails to parse
domain name since it's expecting input from xl's stdout.

So this patch separates those two cases. If xl is running in debug mode,
then message is printed to stderr; if xl is running in dryrun mode and
debug is not enabled, message is printed to stdout. This will fix
xendomains and other scripts that use "xl create --dryrun", as well as
not re-introducing the old bug fixed in d36a3734a.

Reported-by: Mark Pryor <tlviewer@yahoo.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
---
This is a regression, and this bug is so subtle that's a bit hard to
debug from user's point of view. So I think this should go into 4.5.

Mark posted a workaround in
<104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
but to be honest I don't think it's nice to have everyone patch their
scripts in order to work around this.
---
 tools/libxl/xl_cmdimpl.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3737c7e..0a5f7c8 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2472,8 +2472,10 @@ static uint32_t create_domain(struct domain_create *dom_info)
         }
     }
 
-    if (debug || dom_info->dryrun)
+    if (debug)
         printf_info(default_output_format, -1, &d_config, stderr);
+    if (!debug && dom_info->dryrun)
+        printf_info(default_output_format, -1, &d_config, stdout);
 
     ret = 0;
     if (dom_info->dryrun)
-- 
1.7.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 Dec 13 16:54:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 16:54:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzpxM-0007yu-5z; Sat, 13 Dec 2014 16:54:12 +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 1XzpxK-0007yk-Nn
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 16:54:10 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	20/72-27785-23F6C845; Sat, 13 Dec 2014 16:54:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418489648!14875729!1
X-Originating-IP: [66.165.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 17661 invoked from network); 13 Dec 2014 16:54:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 16:54:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="204297808"
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.210.2;
	Sat, 13 Dec 2014 11:54:07 -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 1XzpxG-0005uS-8f;
	Sat, 13 Dec 2014 16:54:06 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Sat, 13 Dec 2014 16:54:05 +0000
Message-ID: <1418489645-7689-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: tlviewer@yahoo.com, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, M A Young <m.a.young@durham.ac.uk>
Subject: [Xen-devel] [PATCH for-4.5] xl: print message to stdout when
	(!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 commit d36a3734a ("xl: fix migration failure with xl migrate
--debug"), message is printed to stderr for both debug mode
and dryrun mode. That caused rdname() in xendomains fails to parse
domain name since it's expecting input from xl's stdout.

So this patch separates those two cases. If xl is running in debug mode,
then message is printed to stderr; if xl is running in dryrun mode and
debug is not enabled, message is printed to stdout. This will fix
xendomains and other scripts that use "xl create --dryrun", as well as
not re-introducing the old bug fixed in d36a3734a.

Reported-by: Mark Pryor <tlviewer@yahoo.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
---
This is a regression, and this bug is so subtle that's a bit hard to
debug from user's point of view. So I think this should go into 4.5.

Mark posted a workaround in
<104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
but to be honest I don't think it's nice to have everyone patch their
scripts in order to work around this.
---
 tools/libxl/xl_cmdimpl.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3737c7e..0a5f7c8 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2472,8 +2472,10 @@ static uint32_t create_domain(struct domain_create *dom_info)
         }
     }
 
-    if (debug || dom_info->dryrun)
+    if (debug)
         printf_info(default_output_format, -1, &d_config, stderr);
+    if (!debug && dom_info->dryrun)
+        printf_info(default_output_format, -1, &d_config, stdout);
 
     ret = 0;
     if (dom_info->dryrun)
-- 
1.7.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 Dec 13 17:00:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 17: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 1Xzq2s-00087Q-V4; Sat, 13 Dec 2014 16:59: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 1Xzq2r-00087L-Tu
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 16:59:54 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	50/94-01660-9807C845; Sat, 13 Dec 2014 16:59:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418489991!13165422!1
X-Originating-IP: [66.165.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 14178 invoked from network); 13 Dec 2014 16:59:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 16:59:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="203889253"
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.210.2;
	Sat, 13 Dec 2014 11: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 1Xzq2o-00060S-00;
	Sat, 13 Dec 2014 16:59:50 +0000
Date: Sat, 13 Dec 2014 16:59:49 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Mark Pryor <tlviewer@yahoo.com>
Message-ID: <20141213165949.GC2285@zion.uk.xensource.com>
References: <1701008001.9091123.1418411611015.JavaMail.yahoo@jws10667.mail.bf1.yahoo.com>
MIME-Version: 1.0
Content-Length: 891
Content-Disposition: inline
In-Reply-To: <1701008001.9091123.1418411611015.JavaMail.yahoo@jws10667.mail.bf1.yahoo.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] does rdname() in xendomains follow symlink?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, 2014 at 07:13:31PM +0000, Mark Pryor wrote:
> I am testing 4.5 (HEAD) in deb8 and noticed some problems with xendomains=
(git path):=A0 ./tools/hotplug/Linux/xendomains
> =

> when trying to get the name from the JSON config it ends up with the syml=
ink name instead. Thismay not show up as a bug unless you use symlinks in /=
etc/xen/auto, like me.
> I think I can fix this, but I have no business submitting a patch for a b=
lue-chip project.
> thanks for developer attention on this,Mark

Just saw this.

Is this the reason you posted a workaround for rdname? I.e., do I need
to pay attention to this?

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 Sat Dec 13 17:00:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 17: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 1Xzq2s-00087Q-V4; Sat, 13 Dec 2014 16:59: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 1Xzq2r-00087L-Tu
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 16:59:54 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	50/94-01660-9807C845; Sat, 13 Dec 2014 16:59:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418489991!13165422!1
X-Originating-IP: [66.165.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 14178 invoked from network); 13 Dec 2014 16:59:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 16:59:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="203889253"
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.210.2;
	Sat, 13 Dec 2014 11: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 1Xzq2o-00060S-00;
	Sat, 13 Dec 2014 16:59:50 +0000
Date: Sat, 13 Dec 2014 16:59:49 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Mark Pryor <tlviewer@yahoo.com>
Message-ID: <20141213165949.GC2285@zion.uk.xensource.com>
References: <1701008001.9091123.1418411611015.JavaMail.yahoo@jws10667.mail.bf1.yahoo.com>
MIME-Version: 1.0
Content-Length: 891
Content-Disposition: inline
In-Reply-To: <1701008001.9091123.1418411611015.JavaMail.yahoo@jws10667.mail.bf1.yahoo.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] does rdname() in xendomains follow symlink?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, 2014 at 07:13:31PM +0000, Mark Pryor wrote:
> I am testing 4.5 (HEAD) in deb8 and noticed some problems with xendomains=
(git path):=A0 ./tools/hotplug/Linux/xendomains
> =

> when trying to get the name from the JSON config it ends up with the syml=
ink name instead. Thismay not show up as a bug unless you use symlinks in /=
etc/xen/auto, like me.
> I think I can fix this, but I have no business submitting a patch for a b=
lue-chip project.
> thanks for developer attention on this,Mark

Just saw this.

Is this the reason you posted a workaround for rdname? I.e., do I need
to pay attention to this?

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 Sat Dec 13 17:05:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 17:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzq8E-0008SL-NL; Sat, 13 Dec 2014 17:05: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 1Xzq8D-0008SG-2H
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 17:05:25 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	2E/FD-17694-4D17C845; Sat, 13 Dec 2014 17:05:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418490322!13091619!1
X-Originating-IP: [66.165.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 8669 invoked from network); 13 Dec 2014 17:05:23 -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;
	13 Dec 2014 17:05:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="203890486"
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.210.2; Sat, 13 Dec 2014 12:05:20 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xzq88-00058n-3n;
	Sat, 13 Dec 2014 17:05:20 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xzq86-0005tk-L0;
	Sat, 13 Dec 2014 17:05:19 +0000
Date: Sat, 13 Dec 2014 17:05:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32315-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] 32315: 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 32315 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32315/

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-credit2    3 host-install(3)           broken pass in 32277
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)         broken pass in 32277
 test-amd64-amd64-xl-win7-amd64 13 guest-localmigrate/x10    fail pass in 32277
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 32277
 test-amd64-i386-freebsd10-amd64 16 guest-start.2   fail in 32277 pass in 32315
 test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail in 32277 pass in 32315

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-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

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-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-winxpsp3  14 guest-stop                   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-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-vcpus1 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-winxpsp3 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 in 32277 never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                     broken  
 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                                   broken  
 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                                        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?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-i386-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)

Not pushing.

(No revision log; it would be 34178 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 Dec 13 17:05:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 17:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzq8E-0008SL-NL; Sat, 13 Dec 2014 17:05: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 1Xzq8D-0008SG-2H
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 17:05:25 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	2E/FD-17694-4D17C845; Sat, 13 Dec 2014 17:05:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418490322!13091619!1
X-Originating-IP: [66.165.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 8669 invoked from network); 13 Dec 2014 17:05:23 -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;
	13 Dec 2014 17:05:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="203890486"
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.210.2; Sat, 13 Dec 2014 12:05:20 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Xzq88-00058n-3n;
	Sat, 13 Dec 2014 17:05:20 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Xzq86-0005tk-L0;
	Sat, 13 Dec 2014 17:05:19 +0000
Date: Sat, 13 Dec 2014 17:05:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32315-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] 32315: 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 32315 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32315/

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-credit2    3 host-install(3)           broken pass in 32277
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)         broken pass in 32277
 test-amd64-amd64-xl-win7-amd64 13 guest-localmigrate/x10    fail pass in 32277
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 32277
 test-amd64-i386-freebsd10-amd64 16 guest-start.2   fail in 32277 pass in 32315
 test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail in 32277 pass in 32315

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-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

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-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-winxpsp3  14 guest-stop                   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-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-vcpus1 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-winxpsp3 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 in 32277 never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                     broken  
 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                                   broken  
 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                                        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?p=osstest.git;a=summary

broken-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-i386-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)

Not pushing.

(No revision log; it would be 34178 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 Dec 13 17:06:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 17:06:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzq8w-0008WH-9s; Sat, 13 Dec 2014 17:06:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xzq8v-0008W3-E9
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 17:06:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0E/B8-09842-0027C845; Sat, 13 Dec 2014 17:06:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418490367!8082838!1
X-Originating-IP: [66.165.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 5845 invoked from network); 13 Dec 2014 17:06: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;
	13 Dec 2014 17:06:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="204300198"
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.210.2;
	Sat, 13 Dec 2014 12:06: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 1Xzq8r-00066D-Nn;
	Sat, 13 Dec 2014 17:06:05 +0000
Date: Sat, 13 Dec 2014 17:06:05 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20141213170605.GD2285@zion.uk.xensource.com>
References: <1411365561-29242-1-git-send-email-wency@cn.fujitsu.com>
	<1411365561-29242-4-git-send-email-wency@cn.fujitsu.com>
	<CAFLBxZbzSAFSZZrW9p+Gz-VTbts+q4Z1xT_+d9jrYJ8jjXVy8g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZbzSAFSZZrW9p+Gz-VTbts+q4Z1xT_+d9jrYJ8jjXVy8g@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Wen Congyang <wency@cn.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [RFC Patch v4 3/9] pass correct file to qemu if we
 use blktap2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 04:45:09PM +0000, George Dunlap wrote:
> On Mon, Sep 22, 2014 at 6:59 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
> > If we use blktap2, the correct file should be blktap device
> > not the pdev_path.
> >
> > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> > Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> If I'm reading this correctly, this is actually a fairly serious bug
> in libxl -- it means that when using backend=tap with HVM domains,
> qemu will actually *bypass entirely* the tapdisk process and access
> the underlying file directly.
> 

Is it because qemu will corrupt the underlying file so it's very
serious? 

Wei.

> This should probably be backported, potentially as far back as 4.2.
> 
>  -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 Sat Dec 13 17:06:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 17:06:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzq8w-0008WH-9s; Sat, 13 Dec 2014 17:06:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Xzq8v-0008W3-E9
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 17:06:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0E/B8-09842-0027C845; Sat, 13 Dec 2014 17:06:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418490367!8082838!1
X-Originating-IP: [66.165.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 5845 invoked from network); 13 Dec 2014 17:06: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;
	13 Dec 2014 17:06:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,571,1413244800"; d="scan'208";a="204300198"
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.210.2;
	Sat, 13 Dec 2014 12:06: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 1Xzq8r-00066D-Nn;
	Sat, 13 Dec 2014 17:06:05 +0000
Date: Sat, 13 Dec 2014 17:06:05 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20141213170605.GD2285@zion.uk.xensource.com>
References: <1411365561-29242-1-git-send-email-wency@cn.fujitsu.com>
	<1411365561-29242-4-git-send-email-wency@cn.fujitsu.com>
	<CAFLBxZbzSAFSZZrW9p+Gz-VTbts+q4Z1xT_+d9jrYJ8jjXVy8g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZbzSAFSZZrW9p+Gz-VTbts+q4Z1xT_+d9jrYJ8jjXVy8g@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Wen Congyang <wency@cn.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [RFC Patch v4 3/9] pass correct file to qemu if we
 use blktap2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 04:45:09PM +0000, George Dunlap wrote:
> On Mon, Sep 22, 2014 at 6:59 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
> > If we use blktap2, the correct file should be blktap device
> > not the pdev_path.
> >
> > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> > Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> If I'm reading this correctly, this is actually a fairly serious bug
> in libxl -- it means that when using backend=tap with HVM domains,
> qemu will actually *bypass entirely* the tapdisk process and access
> the underlying file directly.
> 

Is it because qemu will corrupt the underlying file so it's very
serious? 

Wei.

> This should probably be backported, potentially as far back as 4.2.
> 
>  -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 Sat Dec 13 18:23:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 18: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 1XzrLT-0001rI-Hx; Sat, 13 Dec 2014 18:23: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 1XzrLR-0001rD-HG
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 18:23:09 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	43/68-19763-C048C845; Sat, 13 Dec 2014 18:23:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418494986!13169673!1
X-Originating-IP: [156.151.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 28925 invoked from network); 13 Dec 2014 18:23:08 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Dec 2014 18:23:08 -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 sBDIMiRJ002852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 13 Dec 2014 18:22: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
	sBDIMge4006912
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 13 Dec 2014 18:22:43 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
	sBDIMfuV011406; Sat, 13 Dec 2014 18:22:42 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 13 Dec 2014 10:22:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 915F212384A; Sat, 13 Dec 2014 13:22:39 -0500 (EST)
Date: Sat, 13 Dec 2014 13:22:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, m.a.young@durham.ac.uk
Message-ID: <20141213182239.GA31121@laptop.dumpdata.com>
References: <1416579506.17932.10.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416579506.17932.10.camel@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>, xen-devel <xen-devel@lists.xen.org>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, M A Young <m.a.young@durham.ac.uk>
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-Type: text/plain; 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:18:26PM +0000, 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?

ping?
> 
> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 13 18:23:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 18: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 1XzrLT-0001rI-Hx; Sat, 13 Dec 2014 18:23: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 1XzrLR-0001rD-HG
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 18:23:09 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	43/68-19763-C048C845; Sat, 13 Dec 2014 18:23:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418494986!13169673!1
X-Originating-IP: [156.151.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 28925 invoked from network); 13 Dec 2014 18:23:08 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Dec 2014 18:23:08 -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 sBDIMiRJ002852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 13 Dec 2014 18:22: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
	sBDIMge4006912
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 13 Dec 2014 18:22:43 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
	sBDIMfuV011406; Sat, 13 Dec 2014 18:22:42 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 13 Dec 2014 10:22:41 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 915F212384A; Sat, 13 Dec 2014 13:22:39 -0500 (EST)
Date: Sat, 13 Dec 2014 13:22:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, m.a.young@durham.ac.uk
Message-ID: <20141213182239.GA31121@laptop.dumpdata.com>
References: <1416579506.17932.10.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1416579506.17932.10.camel@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>, xen-devel <xen-devel@lists.xen.org>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, M A Young <m.a.young@durham.ac.uk>
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-Type: text/plain; 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:18:26PM +0000, 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?

ping?
> 
> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 13 18:29:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 18:29:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzrQt-000201-Bp; Sat, 13 Dec 2014 18:28:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tlviewer@yahoo.com>) id 1XzrQs-0001zv-PY
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 18:28:47 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	3F/19-25714-E558C845; Sat, 13 Dec 2014 18:28:46 +0000
X-Env-Sender: tlviewer@yahoo.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418495323!10301631!1
X-Originating-IP: [216.109.115.109]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_YAHOO_RCVD,
	HTML_50_60,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1081 invoked from network); 13 Dec 2014 18:28:44 -0000
Received: from nm46-vm6.bullet.mail.bf1.yahoo.com (HELO
	nm46-vm6.bullet.mail.bf1.yahoo.com) (216.109.115.109)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 18:28:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
	t=1418495323; bh=/Py6fjx7wrDxWqj7p49RlPaob2O7wHCjnUk5Ky1xKvk=;
	h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;
	b=S4u69SL3D/oMQr1F+dnY9irLYYMWWcqgxcdhcqMxEaTbLnqVUCLogcIPRl3yXoJh7djnclk+u2wcGcK83R9zexNlSAK5gDVsCj25urIwiOabSNSV9EUzs6l4nYhyL2ZIz4X65zmsX8IHN4EbK2R8PzkVCW/TQ0N9Pev6iPl+3iiS84Hi7LQqcMf65nrCdePVKEZbaBHviA67wCha91fs+aD0CH+9aisvtTW+lB5qkJ4j9WhiygBPmp1oUHqSmRPK441dWHhthOd0JzqqeGZOwzLmqJX3hWhmvuCxifY47xukGU90svj6ADwdvorl4N5tJQWrltotWkwLyRDzedGhDg==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com;
	b=S8UflczFj2H041EuhFbRMvX8vDzZmMSvZZMV91gDi7pQC7xea1gJL7+RjUlOAil3cVeI52Uaw/iLFpOduvWhBe2rTFdi3MtAI5clJowTKesYZIcNHrQK2hWuhb/k1VPiKqKKGYwJxhf+Ml+P3ElR5rOMf1GUEeP0+5JLy1iiNz7B5nn+wyPXRZELfmbEYC1VlF5P+Fxyt4DEjYPGFolVjDZvN5MAFAPZD/05WRRqJ5BK9PF63O5/nNJWWS9pdbENPQEXp0Y7rTsBdZNPhxQYPg/JexgAeTANpSRq10XmcwkBX3tvgYmvAtWH1nwsEGUbTM+Oye6Dm3WxEShiwVhPRg==;
Received: from [98.139.212.151] by nm46.bullet.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2014 18:28:43 -0000
Received: from [98.139.215.250] by tm8.bullet.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2014 18:28:43 -0000
Received: from [127.0.0.1] by omp1063.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2014 18:28:43 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 411509.16585.bm@omp1063.mail.bf1.yahoo.com
X-YMail-OSG: dzHkjWIVM1ngFir9nHn1cNbieluQ50FaEutQ0volt2E6zyx8ROozwKQPFb9xQxG
	z8CX2wys_RhNTCvEtLINYQhDVSK0.1S.WI2S9EH96TRWQGS0Fd_fq.ilTzMAI7_PsSSgASt22xe6
	0dqkI4Yf9AB038roh96jKapgZeZBTtWn18cB0mxcatfuz3dQPFILCMngXYz.dbH4ICTz_ZgW0tta
	IvuIJkTTwRuGtqP8EkvZgDLKttEPL3uZwEnAfUHG3RBAMUMnz5uiT7sbn4tkq.xz.RI4nHEBgyt_
	4BnAV99pAoQv0MViuCzMkU76OuI31AYf.DkG2aQzxS_srW4VWr1Cy32JFjEpkqR6RtJqu_5K.19a
	e7COX37OdFh36dpXB9h52AD4U_SlUirXtIJgyVhGHcDhyD9pU9Bxz_CUySok9ucDevlGCk7RLfpi
	s.z_oRrsxluIRmLQ06gE0LPGDvvYv0nfj2lHr9qpPn9TsiBpf_9Y392Pp_zBenYUbzEQAjYfltss
	CWSl.jZXLz0XKG0MMpSvEyuJK1sSeQdD7lOEt1puT9SkOIhTfSu4RTXmO
Received: by 66.196.80.151; Sat, 13 Dec 2014 18:28:42 +0000 
Date: Sat, 13 Dec 2014 18:28:42 +0000 (UTC)
From: Mark Pryor <tlviewer@yahoo.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <1061947120.278921.1418495322630.JavaMail.yahoo@jws106124.mail.bf1.yahoo.com>
In-Reply-To: <20141213164526.GB2285@zion.uk.xensource.com>
References: <20141213164526.GB2285@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Length: 6492
Cc: Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.5 patch: xendomains noise to stderr in rdname()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mark Pryor <tlviewer@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9159801177517248700=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9159801177517248700==
Content-Type: multipart/alternative; 
	boundary="----=_Part_278920_352254077.1418495322625"
Content-Length: 6005

------=_Part_278920_352254077.1418495322625
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think I tracked it down this morning:
this commit `d36a373 fix xl: migration` causes `$(which xendomains) start` =
to flood logs with JSON configs
IOW, when the xendomains services starts, the JSON config for every domU in=
 autostart folder is logged. Its written to stdout if you do manually:`$(wh=
ich xendomains) start`=20

I am using the above patch to rdname() in all my dom0 builds with 4.5 (HEAD=
) to avoid this trouble.
=20

     On Saturday, December 13, 2014 8:45 AM, Wei Liu <wei.liu2@citrix.com> =
wrote:
  =20

 On Sat, Dec 13, 2014 at 01:34:14AM +0000, Mark Pryor wrote:
> Instead of tracking down which commit involving libxl* which prints all k=
ind of noiseto stderr, I will post a workaround.=20

Though I think I am able to guess what log you were seeing, it would be
better in the future if you attach actual log for a bug report.

I will post a patch for this.

Wei.

>=20
> If you build, install, and use 4.5 this bug will drive you mad, so here i=
t is:
> -------------------- snip -----------------
> --- a/tools/hotplug/Linux/xendomains.in+++ b/tools/hotplug/Linux/xendomai=
ns.in
> @@ -175,7 +175,7 @@ contains_something()
> =C2=A0# read name from xen config file
> =C2=A0rdname()
> =C2=A0{
> -=C2=A0=C2=A0=C2=A0 NM=3D$($CMD create --quiet --dryrun --defconfig "$1" =
|
> +=C2=A0=C2=A0=C2=A0 NM=3D$($CMD create --quiet --dryrun --defconfig "$1" =
2>&1 |
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sed -n 's/^.*(name=
 \(.*\))$/\1/p;s/^.*"name": "\(.*\)",$/\1/p')
> =C2=A0}
>=20
>=20

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



   
------=_Part_278920_352254077.1418495322625
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo=
nt-size:16px"><div dir=3D"ltr" id=3D"yui_3_16_0_1_1418495001427_2824"><span=
 id=3D"yui_3_16_0_1_1418495001427_3037">I think I tracked it down this morn=
ing:<br></span></div><div><span id=3D"yui_3_16_0_1_1418495001427_3037">this=
 commit `d36a373 fix xl: migration` causes `$(which xendomains) start` to f=
lood logs with JSON configs</span></div><div id=3D"yui_3_16_0_1_14184950014=
27_3036"><br><span></span></div><div id=3D"yui_3_16_0_1_1418495001427_3039"=
 dir=3D"ltr"><span id=3D"yui_3_16_0_1_1418495001427_3038">IOW, when the xen=
domains services starts, the JSON config for every domU in autostart folder=
 is logged. Its written to stdout if you do manually:</span></div><div id=
=3D"yui_3_16_0_1_1418495001427_3040" dir=3D"ltr"><span style=3D"" class=3D"=
" id=3D"yui_3_16_0_1_1418495001427_3037">`$(which xendomains) start` <br></=
span></div><div dir=3D"ltr"><br><span style=3D"" class=3D"" id=3D"yui_3_16_=
0_1_1418495001427_3037"></span></div><div id=3D"yui_3_16_0_1_1418495001427_=
3445" dir=3D"ltr"><span style=3D"" class=3D"" id=3D"yui_3_16_0_1_1418495001=
427_3037">I am using the above patch to rdname() in all my dom0 builds with=
 4.5 (HEAD) to avoid this trouble.<br></span></div> <div class=3D"qtdSepara=
teBR"><br><br></div><div style=3D"display: block;" class=3D"yahoo_quoted"> =
<div style=3D"font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial,=
 Lucida Grande, sans-serif; font-size: 16px;"> <div style=3D"font-family: H=
elveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; =
font-size: 16px;"> <div dir=3D"ltr"> <font face=3D"Arial" size=3D"2"> On Sa=
turday, December 13, 2014 8:45 AM, Wei Liu &lt;wei.liu2@citrix.com&gt; wrot=
e:<br> </font> </div>  <br><br> <div class=3D"y_msg_container">On Sat, Dec =
13, 2014 at 01:34:14AM +0000, Mark Pryor wrote:<br clear=3D"none">&gt; Inst=
ead of tracking down which commit involving libxl* which prints all kind of=
 noiseto stderr, I will post a workaround. <br clear=3D"none"><br clear=3D"=
none">Though I think I am able to guess what log you were seeing, it would =
be<br clear=3D"none">better in the future if you attach actual log for a bu=
g report.<br clear=3D"none"><br clear=3D"none">I will post a patch for this=
.<br clear=3D"none"><br clear=3D"none">Wei.<div class=3D"yqt1935014146" id=
=3D"yqtfd71925"><br clear=3D"none"><br clear=3D"none">&gt; <br clear=3D"non=
e">&gt; If you build, install, and use 4.5 this bug will drive you mad, so =
here it is:<br clear=3D"none">&gt; -------------------- snip --------------=
---<br clear=3D"none">&gt; --- a/tools/hotplug/Linux/xendomains.in+++ b/too=
ls/hotplug/Linux/xendomains.in<br clear=3D"none">&gt; @@ -175,7 +175,7 @@ c=
ontains_something()<br clear=3D"none">&gt; &nbsp;# read name from xen confi=
g file<br clear=3D"none">&gt; &nbsp;rdname()<br clear=3D"none">&gt; &nbsp;{=
<br clear=3D"none">&gt; -&nbsp;&nbsp;&nbsp; NM=3D$($CMD create --quiet --dr=
yrun --defconfig "$1" |<br clear=3D"none">&gt; +&nbsp;&nbsp;&nbsp; NM=3D$($=
CMD create --quiet --dryrun --defconfig "$1" 2&gt;&amp;1 |<br clear=3D"none=
">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sed -n 's/^.*=
(name \(.*\))$/\1/p;s/^.*"name": "\(.*\)",$/\1/p')</div><br clear=3D"none">=
&gt; &nbsp;}<br clear=3D"none">&gt; <br clear=3D"none">&gt; <br clear=3D"no=
ne"><br clear=3D"none">&gt; _______________________________________________=
<br clear=3D"none">&gt; Xen-devel mailing list<br clear=3D"none">&gt; <a sh=
ape=3D"rect" ymailto=3D"mailto:Xen-devel@lists.xen.org" href=3D"mailto:Xen-=
devel@lists.xen.org">Xen-devel@lists.xen.org</a><br clear=3D"none">&gt; <a =
shape=3D"rect" href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">ht=
tp://lists.xen.org/xen-devel</a><div class=3D"yqt1935014146" id=3D"yqtfd366=
41"><br clear=3D"none"><br clear=3D"none"></div><br><br></div>  </div> </di=
v>  </div> </div></body></html>
------=_Part_278920_352254077.1418495322625--


--===============9159801177517248700==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9159801177517248700==--


From xen-devel-bounces@lists.xen.org Sat Dec 13 18:29:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 18:29:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzrQt-000201-Bp; Sat, 13 Dec 2014 18:28:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tlviewer@yahoo.com>) id 1XzrQs-0001zv-PY
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 18:28:47 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	3F/19-25714-E558C845; Sat, 13 Dec 2014 18:28:46 +0000
X-Env-Sender: tlviewer@yahoo.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418495323!10301631!1
X-Originating-IP: [216.109.115.109]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_YAHOO_RCVD,
	HTML_50_60,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1081 invoked from network); 13 Dec 2014 18:28:44 -0000
Received: from nm46-vm6.bullet.mail.bf1.yahoo.com (HELO
	nm46-vm6.bullet.mail.bf1.yahoo.com) (216.109.115.109)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 18:28:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
	t=1418495323; bh=/Py6fjx7wrDxWqj7p49RlPaob2O7wHCjnUk5Ky1xKvk=;
	h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;
	b=S4u69SL3D/oMQr1F+dnY9irLYYMWWcqgxcdhcqMxEaTbLnqVUCLogcIPRl3yXoJh7djnclk+u2wcGcK83R9zexNlSAK5gDVsCj25urIwiOabSNSV9EUzs6l4nYhyL2ZIz4X65zmsX8IHN4EbK2R8PzkVCW/TQ0N9Pev6iPl+3iiS84Hi7LQqcMf65nrCdePVKEZbaBHviA67wCha91fs+aD0CH+9aisvtTW+lB5qkJ4j9WhiygBPmp1oUHqSmRPK441dWHhthOd0JzqqeGZOwzLmqJX3hWhmvuCxifY47xukGU90svj6ADwdvorl4N5tJQWrltotWkwLyRDzedGhDg==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com;
	b=S8UflczFj2H041EuhFbRMvX8vDzZmMSvZZMV91gDi7pQC7xea1gJL7+RjUlOAil3cVeI52Uaw/iLFpOduvWhBe2rTFdi3MtAI5clJowTKesYZIcNHrQK2hWuhb/k1VPiKqKKGYwJxhf+Ml+P3ElR5rOMf1GUEeP0+5JLy1iiNz7B5nn+wyPXRZELfmbEYC1VlF5P+Fxyt4DEjYPGFolVjDZvN5MAFAPZD/05WRRqJ5BK9PF63O5/nNJWWS9pdbENPQEXp0Y7rTsBdZNPhxQYPg/JexgAeTANpSRq10XmcwkBX3tvgYmvAtWH1nwsEGUbTM+Oye6Dm3WxEShiwVhPRg==;
Received: from [98.139.212.151] by nm46.bullet.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2014 18:28:43 -0000
Received: from [98.139.215.250] by tm8.bullet.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2014 18:28:43 -0000
Received: from [127.0.0.1] by omp1063.mail.bf1.yahoo.com with NNFMP;
	13 Dec 2014 18:28:43 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 411509.16585.bm@omp1063.mail.bf1.yahoo.com
X-YMail-OSG: dzHkjWIVM1ngFir9nHn1cNbieluQ50FaEutQ0volt2E6zyx8ROozwKQPFb9xQxG
	z8CX2wys_RhNTCvEtLINYQhDVSK0.1S.WI2S9EH96TRWQGS0Fd_fq.ilTzMAI7_PsSSgASt22xe6
	0dqkI4Yf9AB038roh96jKapgZeZBTtWn18cB0mxcatfuz3dQPFILCMngXYz.dbH4ICTz_ZgW0tta
	IvuIJkTTwRuGtqP8EkvZgDLKttEPL3uZwEnAfUHG3RBAMUMnz5uiT7sbn4tkq.xz.RI4nHEBgyt_
	4BnAV99pAoQv0MViuCzMkU76OuI31AYf.DkG2aQzxS_srW4VWr1Cy32JFjEpkqR6RtJqu_5K.19a
	e7COX37OdFh36dpXB9h52AD4U_SlUirXtIJgyVhGHcDhyD9pU9Bxz_CUySok9ucDevlGCk7RLfpi
	s.z_oRrsxluIRmLQ06gE0LPGDvvYv0nfj2lHr9qpPn9TsiBpf_9Y392Pp_zBenYUbzEQAjYfltss
	CWSl.jZXLz0XKG0MMpSvEyuJK1sSeQdD7lOEt1puT9SkOIhTfSu4RTXmO
Received: by 66.196.80.151; Sat, 13 Dec 2014 18:28:42 +0000 
Date: Sat, 13 Dec 2014 18:28:42 +0000 (UTC)
From: Mark Pryor <tlviewer@yahoo.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <1061947120.278921.1418495322630.JavaMail.yahoo@jws106124.mail.bf1.yahoo.com>
In-Reply-To: <20141213164526.GB2285@zion.uk.xensource.com>
References: <20141213164526.GB2285@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Length: 6492
Cc: Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.5 patch: xendomains noise to stderr in rdname()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Mark Pryor <tlviewer@yahoo.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9159801177517248700=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9159801177517248700==
Content-Type: multipart/alternative; 
	boundary="----=_Part_278920_352254077.1418495322625"
Content-Length: 6005

------=_Part_278920_352254077.1418495322625
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think I tracked it down this morning:
this commit `d36a373 fix xl: migration` causes `$(which xendomains) start` =
to flood logs with JSON configs
IOW, when the xendomains services starts, the JSON config for every domU in=
 autostart folder is logged. Its written to stdout if you do manually:`$(wh=
ich xendomains) start`=20

I am using the above patch to rdname() in all my dom0 builds with 4.5 (HEAD=
) to avoid this trouble.
=20

     On Saturday, December 13, 2014 8:45 AM, Wei Liu <wei.liu2@citrix.com> =
wrote:
  =20

 On Sat, Dec 13, 2014 at 01:34:14AM +0000, Mark Pryor wrote:
> Instead of tracking down which commit involving libxl* which prints all k=
ind of noiseto stderr, I will post a workaround.=20

Though I think I am able to guess what log you were seeing, it would be
better in the future if you attach actual log for a bug report.

I will post a patch for this.

Wei.

>=20
> If you build, install, and use 4.5 this bug will drive you mad, so here i=
t is:
> -------------------- snip -----------------
> --- a/tools/hotplug/Linux/xendomains.in+++ b/tools/hotplug/Linux/xendomai=
ns.in
> @@ -175,7 +175,7 @@ contains_something()
> =C2=A0# read name from xen config file
> =C2=A0rdname()
> =C2=A0{
> -=C2=A0=C2=A0=C2=A0 NM=3D$($CMD create --quiet --dryrun --defconfig "$1" =
|
> +=C2=A0=C2=A0=C2=A0 NM=3D$($CMD create --quiet --dryrun --defconfig "$1" =
2>&1 |
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sed -n 's/^.*(name=
 \(.*\))$/\1/p;s/^.*"name": "\(.*\)",$/\1/p')
> =C2=A0}
>=20
>=20

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



   
------=_Part_278920_352254077.1418495322625
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo=
nt-size:16px"><div dir=3D"ltr" id=3D"yui_3_16_0_1_1418495001427_2824"><span=
 id=3D"yui_3_16_0_1_1418495001427_3037">I think I tracked it down this morn=
ing:<br></span></div><div><span id=3D"yui_3_16_0_1_1418495001427_3037">this=
 commit `d36a373 fix xl: migration` causes `$(which xendomains) start` to f=
lood logs with JSON configs</span></div><div id=3D"yui_3_16_0_1_14184950014=
27_3036"><br><span></span></div><div id=3D"yui_3_16_0_1_1418495001427_3039"=
 dir=3D"ltr"><span id=3D"yui_3_16_0_1_1418495001427_3038">IOW, when the xen=
domains services starts, the JSON config for every domU in autostart folder=
 is logged. Its written to stdout if you do manually:</span></div><div id=
=3D"yui_3_16_0_1_1418495001427_3040" dir=3D"ltr"><span style=3D"" class=3D"=
" id=3D"yui_3_16_0_1_1418495001427_3037">`$(which xendomains) start` <br></=
span></div><div dir=3D"ltr"><br><span style=3D"" class=3D"" id=3D"yui_3_16_=
0_1_1418495001427_3037"></span></div><div id=3D"yui_3_16_0_1_1418495001427_=
3445" dir=3D"ltr"><span style=3D"" class=3D"" id=3D"yui_3_16_0_1_1418495001=
427_3037">I am using the above patch to rdname() in all my dom0 builds with=
 4.5 (HEAD) to avoid this trouble.<br></span></div> <div class=3D"qtdSepara=
teBR"><br><br></div><div style=3D"display: block;" class=3D"yahoo_quoted"> =
<div style=3D"font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial,=
 Lucida Grande, sans-serif; font-size: 16px;"> <div style=3D"font-family: H=
elveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; =
font-size: 16px;"> <div dir=3D"ltr"> <font face=3D"Arial" size=3D"2"> On Sa=
turday, December 13, 2014 8:45 AM, Wei Liu &lt;wei.liu2@citrix.com&gt; wrot=
e:<br> </font> </div>  <br><br> <div class=3D"y_msg_container">On Sat, Dec =
13, 2014 at 01:34:14AM +0000, Mark Pryor wrote:<br clear=3D"none">&gt; Inst=
ead of tracking down which commit involving libxl* which prints all kind of=
 noiseto stderr, I will post a workaround. <br clear=3D"none"><br clear=3D"=
none">Though I think I am able to guess what log you were seeing, it would =
be<br clear=3D"none">better in the future if you attach actual log for a bu=
g report.<br clear=3D"none"><br clear=3D"none">I will post a patch for this=
.<br clear=3D"none"><br clear=3D"none">Wei.<div class=3D"yqt1935014146" id=
=3D"yqtfd71925"><br clear=3D"none"><br clear=3D"none">&gt; <br clear=3D"non=
e">&gt; If you build, install, and use 4.5 this bug will drive you mad, so =
here it is:<br clear=3D"none">&gt; -------------------- snip --------------=
---<br clear=3D"none">&gt; --- a/tools/hotplug/Linux/xendomains.in+++ b/too=
ls/hotplug/Linux/xendomains.in<br clear=3D"none">&gt; @@ -175,7 +175,7 @@ c=
ontains_something()<br clear=3D"none">&gt; &nbsp;# read name from xen confi=
g file<br clear=3D"none">&gt; &nbsp;rdname()<br clear=3D"none">&gt; &nbsp;{=
<br clear=3D"none">&gt; -&nbsp;&nbsp;&nbsp; NM=3D$($CMD create --quiet --dr=
yrun --defconfig "$1" |<br clear=3D"none">&gt; +&nbsp;&nbsp;&nbsp; NM=3D$($=
CMD create --quiet --dryrun --defconfig "$1" 2&gt;&amp;1 |<br clear=3D"none=
">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sed -n 's/^.*=
(name \(.*\))$/\1/p;s/^.*"name": "\(.*\)",$/\1/p')</div><br clear=3D"none">=
&gt; &nbsp;}<br clear=3D"none">&gt; <br clear=3D"none">&gt; <br clear=3D"no=
ne"><br clear=3D"none">&gt; _______________________________________________=
<br clear=3D"none">&gt; Xen-devel mailing list<br clear=3D"none">&gt; <a sh=
ape=3D"rect" ymailto=3D"mailto:Xen-devel@lists.xen.org" href=3D"mailto:Xen-=
devel@lists.xen.org">Xen-devel@lists.xen.org</a><br clear=3D"none">&gt; <a =
shape=3D"rect" href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">ht=
tp://lists.xen.org/xen-devel</a><div class=3D"yqt1935014146" id=3D"yqtfd366=
41"><br clear=3D"none"><br clear=3D"none"></div><br><br></div>  </div> </di=
v>  </div> </div></body></html>
------=_Part_278920_352254077.1418495322625--


--===============9159801177517248700==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9159801177517248700==--


From xen-devel-bounces@lists.xen.org Sat Dec 13 18:37:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 18:37:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzrZW-0002Jf-D5; Sat, 13 Dec 2014 18:37:42 +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 1XzrZV-0002Ja-2u
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 18:37:41 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	25/0F-26740-4778C845; Sat, 13 Dec 2014 18:37:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418495857!13139453!1
X-Originating-IP: [156.151.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 16302 invoked from network); 13 Dec 2014 18:37:39 -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; 13 Dec 2014 18:37: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 sBDIbJhO011809
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 13 Dec 2014 18:37:20 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
	sBDIbIQM013593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 13 Dec 2014 18:37:19 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
	sBDIbHRM029434; Sat, 13 Dec 2014 18:37:18 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 13 Dec 2014 10:37:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A7CB912385C; Sat, 13 Dec 2014 13:37:16 -0500 (EST)
Date: Sat, 13 Dec 2014 13:37:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141213183716.GD31121@laptop.dumpdata.com>
References: <1418489645-7689-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418489645-7689-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: tlviewer@yahoo.com, M A Young <m.a.young@durham.ac.uk>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Dec 13, 2014 at 04:54:05PM +0000, Wei Liu wrote:
> In commit d36a3734a ("xl: fix migration failure with xl migrate
> --debug"), message is printed to stderr for both debug mode
> and dryrun mode. That caused rdname() in xendomains fails to parse
> domain name since it's expecting input from xl's stdout.
> 
> So this patch separates those two cases. If xl is running in debug mode,
> then message is printed to stderr; if xl is running in dryrun mode and
> debug is not enabled, message is printed to stdout. This will fix
> xendomains and other scripts that use "xl create --dryrun", as well as
> not re-introducing the old bug fixed in d36a3734a.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: M A Young <m.a.young@durham.ac.uk>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Konrad Wilk <konrad.wilk@oracle.com>
> ---
> This is a regression, and this bug is so subtle that's a bit hard to
> debug from user's point of view. So I think this should go into 4.5.
> 
> Mark posted a workaround in
> <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
> but to be honest I don't think it's nice to have everyone patch their
> scripts in order to work around this.
> ---
>  tools/libxl/xl_cmdimpl.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3737c7e..0a5f7c8 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2472,8 +2472,10 @@ static uint32_t create_domain(struct domain_create *dom_info)
>          }
>      }
>  
> -    if (debug || dom_info->dryrun)
> +    if (debug)
>          printf_info(default_output_format, -1, &d_config, stderr);
> +    if (!debug && dom_info->dryrun)

Could this 'else if (dom_info->dry_run)' ?

I know that semantically it is exactly the same as the 'if (!debug ..)' but
it just "feels" more proper? Thought since you are the maintainer in that
area - your opinion on how you want to do that is of course authoritive.

Regardless,

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> +        printf_info(default_output_format, -1, &d_config, stdout);
>  
>      ret = 0;
>      if (dom_info->dryrun)
> -- 
> 1.7.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 Dec 13 18:37:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 18:37:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1XzrZW-0002Jf-D5; Sat, 13 Dec 2014 18:37:42 +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 1XzrZV-0002Ja-2u
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 18:37:41 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	25/0F-26740-4778C845; Sat, 13 Dec 2014 18:37:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418495857!13139453!1
X-Originating-IP: [156.151.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 16302 invoked from network); 13 Dec 2014 18:37:39 -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; 13 Dec 2014 18:37: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 sBDIbJhO011809
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 13 Dec 2014 18:37:20 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
	sBDIbIQM013593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 13 Dec 2014 18:37:19 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
	sBDIbHRM029434; Sat, 13 Dec 2014 18:37:18 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 13 Dec 2014 10:37:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id A7CB912385C; Sat, 13 Dec 2014 13:37:16 -0500 (EST)
Date: Sat, 13 Dec 2014 13:37:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141213183716.GD31121@laptop.dumpdata.com>
References: <1418489645-7689-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418489645-7689-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: tlviewer@yahoo.com, M A Young <m.a.young@durham.ac.uk>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Dec 13, 2014 at 04:54:05PM +0000, Wei Liu wrote:
> In commit d36a3734a ("xl: fix migration failure with xl migrate
> --debug"), message is printed to stderr for both debug mode
> and dryrun mode. That caused rdname() in xendomains fails to parse
> domain name since it's expecting input from xl's stdout.
> 
> So this patch separates those two cases. If xl is running in debug mode,
> then message is printed to stderr; if xl is running in dryrun mode and
> debug is not enabled, message is printed to stdout. This will fix
> xendomains and other scripts that use "xl create --dryrun", as well as
> not re-introducing the old bug fixed in d36a3734a.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: M A Young <m.a.young@durham.ac.uk>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Konrad Wilk <konrad.wilk@oracle.com>
> ---
> This is a regression, and this bug is so subtle that's a bit hard to
> debug from user's point of view. So I think this should go into 4.5.
> 
> Mark posted a workaround in
> <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
> but to be honest I don't think it's nice to have everyone patch their
> scripts in order to work around this.
> ---
>  tools/libxl/xl_cmdimpl.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3737c7e..0a5f7c8 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2472,8 +2472,10 @@ static uint32_t create_domain(struct domain_create *dom_info)
>          }
>      }
>  
> -    if (debug || dom_info->dryrun)
> +    if (debug)
>          printf_info(default_output_format, -1, &d_config, stderr);
> +    if (!debug && dom_info->dryrun)

Could this 'else if (dom_info->dry_run)' ?

I know that semantically it is exactly the same as the 'if (!debug ..)' but
it just "feels" more proper? Thought since you are the maintainer in that
area - your opinion on how you want to do that is of course authoritive.

Regardless,

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> +        printf_info(default_output_format, -1, &d_config, stdout);
>  
>      ret = 0;
>      if (dom_info->dryrun)
> -- 
> 1.7.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 Dec 13 18:42:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 18: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 1Xzrdv-0002cL-3C; Sat, 13 Dec 2014 18:42:15 +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 1Xzrdt-0002cG-6D
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 18:42:13 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	E8/76-02957-4888C845; Sat, 13 Dec 2014 18:42:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418496130!11546226!1
X-Originating-IP: [66.165.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 9363 invoked from network); 13 Dec 2014 18:42: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;
	13 Dec 2014 18:42:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,572,1413244800"; d="scan'208";a="203907478"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Sat, 13 Dec 2014 13:42: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 1Xzrdp-0007cr-CL;
	Sat, 13 Dec 2014 18:42:09 +0000
Date: Sat, 13 Dec 2014 18:42:09 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141213184209.GE2285@zion.uk.xensource.com>
References: <1418489645-7689-1-git-send-email-wei.liu2@citrix.com>
	<20141213183716.GD31121@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141213183716.GD31121@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: tlviewer@yahoo.com, M A Young <m.a.young@durham.ac.uk>,
	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: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Dec 13, 2014 at 01:37:16PM -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Dec 13, 2014 at 04:54:05PM +0000, Wei Liu wrote:
> > In commit d36a3734a ("xl: fix migration failure with xl migrate
> > --debug"), message is printed to stderr for both debug mode
> > and dryrun mode. That caused rdname() in xendomains fails to parse
> > domain name since it's expecting input from xl's stdout.
> > 
> > So this patch separates those two cases. If xl is running in debug mode,
> > then message is printed to stderr; if xl is running in dryrun mode and
> > debug is not enabled, message is printed to stdout. This will fix
> > xendomains and other scripts that use "xl create --dryrun", as well as
> > not re-introducing the old bug fixed in d36a3734a.
> > 
> > Reported-by: Mark Pryor <tlviewer@yahoo.com>
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: M A Young <m.a.young@durham.ac.uk>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > ---
> > This is a regression, and this bug is so subtle that's a bit hard to
> > debug from user's point of view. So I think this should go into 4.5.
> > 
> > Mark posted a workaround in
> > <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
> > but to be honest I don't think it's nice to have everyone patch their
> > scripts in order to work around this.
> > ---
> >  tools/libxl/xl_cmdimpl.c |    4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 3737c7e..0a5f7c8 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -2472,8 +2472,10 @@ static uint32_t create_domain(struct domain_create *dom_info)
> >          }
> >      }
> >  
> > -    if (debug || dom_info->dryrun)
> > +    if (debug)
> >          printf_info(default_output_format, -1, &d_config, stderr);
> > +    if (!debug && dom_info->dryrun)
> 
> Could this 'else if (dom_info->dry_run)' ?
> 
> I know that semantically it is exactly the same as the 'if (!debug ..)' but
> it just "feels" more proper? Thought since you are the maintainer in that
> area - your opinion on how you want to do that is of course authoritive.
> 

I don't have strong preference on this. I just happened to type in
whatever style that flowed though my mind at that particular point. If
Ian and you both feel strongly about this I can certainly resend. :-)

Wei.

> Regardless,
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > +        printf_info(default_output_format, -1, &d_config, stdout);
> >  
> >      ret = 0;
> >      if (dom_info->dryrun)
> > -- 
> > 1.7.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 Dec 13 18:42:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 18: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 1Xzrdv-0002cL-3C; Sat, 13 Dec 2014 18:42:15 +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 1Xzrdt-0002cG-6D
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 18:42:13 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	E8/76-02957-4888C845; Sat, 13 Dec 2014 18:42:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418496130!11546226!1
X-Originating-IP: [66.165.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 9363 invoked from network); 13 Dec 2014 18:42: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;
	13 Dec 2014 18:42:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,572,1413244800"; d="scan'208";a="203907478"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Sat, 13 Dec 2014 13:42: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 1Xzrdp-0007cr-CL;
	Sat, 13 Dec 2014 18:42:09 +0000
Date: Sat, 13 Dec 2014 18:42:09 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141213184209.GE2285@zion.uk.xensource.com>
References: <1418489645-7689-1-git-send-email-wei.liu2@citrix.com>
	<20141213183716.GD31121@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141213183716.GD31121@laptop.dumpdata.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: tlviewer@yahoo.com, M A Young <m.a.young@durham.ac.uk>,
	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: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Dec 13, 2014 at 01:37:16PM -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Dec 13, 2014 at 04:54:05PM +0000, Wei Liu wrote:
> > In commit d36a3734a ("xl: fix migration failure with xl migrate
> > --debug"), message is printed to stderr for both debug mode
> > and dryrun mode. That caused rdname() in xendomains fails to parse
> > domain name since it's expecting input from xl's stdout.
> > 
> > So this patch separates those two cases. If xl is running in debug mode,
> > then message is printed to stderr; if xl is running in dryrun mode and
> > debug is not enabled, message is printed to stdout. This will fix
> > xendomains and other scripts that use "xl create --dryrun", as well as
> > not re-introducing the old bug fixed in d36a3734a.
> > 
> > Reported-by: Mark Pryor <tlviewer@yahoo.com>
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > Cc: M A Young <m.a.young@durham.ac.uk>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > ---
> > This is a regression, and this bug is so subtle that's a bit hard to
> > debug from user's point of view. So I think this should go into 4.5.
> > 
> > Mark posted a workaround in
> > <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
> > but to be honest I don't think it's nice to have everyone patch their
> > scripts in order to work around this.
> > ---
> >  tools/libxl/xl_cmdimpl.c |    4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 3737c7e..0a5f7c8 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -2472,8 +2472,10 @@ static uint32_t create_domain(struct domain_create *dom_info)
> >          }
> >      }
> >  
> > -    if (debug || dom_info->dryrun)
> > +    if (debug)
> >          printf_info(default_output_format, -1, &d_config, stderr);
> > +    if (!debug && dom_info->dryrun)
> 
> Could this 'else if (dom_info->dry_run)' ?
> 
> I know that semantically it is exactly the same as the 'if (!debug ..)' but
> it just "feels" more proper? Thought since you are the maintainer in that
> area - your opinion on how you want to do that is of course authoritive.
> 

I don't have strong preference on this. I just happened to type in
whatever style that flowed though my mind at that particular point. If
Ian and you both feel strongly about this I can certainly resend. :-)

Wei.

> Regardless,
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > +        printf_info(default_output_format, -1, &d_config, stdout);
> >  
> >      ret = 0;
> >      if (dom_info->dryrun)
> > -- 
> > 1.7.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 Dec 13 18:47:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 18:47:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzriq-0002mx-RC; Sat, 13 Dec 2014 18:47:20 +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 1Xzrip-0002mr-DB
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 18:47:19 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	93/4D-17694-6B98C845; Sat, 13 Dec 2014 18:47:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418496436!13150552!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1938 invoked from network); 13 Dec 2014 18:47:17 -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 Dec 2014 18:47:17 -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 sBDIkvNv021803
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 13 Dec 2014 18:46: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
	sBDIkuWI005366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 13 Dec 2014 18:46:57 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
	sBDIku6S012254; Sat, 13 Dec 2014 18:46:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 13 Dec 2014 10:46:56 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0FA16123889; Sat, 13 Dec 2014 13:46:51 -0500 (EST)
Date: Sat, 13 Dec 2014 13:46:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141213184650.GA32014@laptop.dumpdata.com>
References: <1418489645-7689-1-git-send-email-wei.liu2@citrix.com>
	<20141213183716.GD31121@laptop.dumpdata.com>
	<20141213184209.GE2285@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141213184209.GE2285@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: tlviewer@yahoo.com, M A Young <m.a.young@durham.ac.uk>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Dec 13, 2014 at 06:42:09PM +0000, Wei Liu wrote:
> On Sat, Dec 13, 2014 at 01:37:16PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Sat, Dec 13, 2014 at 04:54:05PM +0000, Wei Liu wrote:
> > > In commit d36a3734a ("xl: fix migration failure with xl migrate
> > > --debug"), message is printed to stderr for both debug mode
> > > and dryrun mode. That caused rdname() in xendomains fails to parse
> > > domain name since it's expecting input from xl's stdout.
> > > 
> > > So this patch separates those two cases. If xl is running in debug mode,
> > > then message is printed to stderr; if xl is running in dryrun mode and
> > > debug is not enabled, message is printed to stdout. This will fix
> > > xendomains and other scripts that use "xl create --dryrun", as well as
> > > not re-introducing the old bug fixed in d36a3734a.
> > > 
> > > Reported-by: Mark Pryor <tlviewer@yahoo.com>
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > Cc: M A Young <m.a.young@durham.ac.uk>
> > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > > ---
> > > This is a regression, and this bug is so subtle that's a bit hard to
> > > debug from user's point of view. So I think this should go into 4.5.
> > > 
> > > Mark posted a workaround in
> > > <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
> > > but to be honest I don't think it's nice to have everyone patch their
> > > scripts in order to work around this.
> > > ---
> > >  tools/libxl/xl_cmdimpl.c |    4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > > index 3737c7e..0a5f7c8 100644
> > > --- a/tools/libxl/xl_cmdimpl.c
> > > +++ b/tools/libxl/xl_cmdimpl.c
> > > @@ -2472,8 +2472,10 @@ static uint32_t create_domain(struct domain_create *dom_info)
> > >          }
> > >      }
> > >  
> > > -    if (debug || dom_info->dryrun)
> > > +    if (debug)
> > >          printf_info(default_output_format, -1, &d_config, stderr);
> > > +    if (!debug && dom_info->dryrun)
> > 
> > Could this 'else if (dom_info->dry_run)' ?
> > 
> > I know that semantically it is exactly the same as the 'if (!debug ..)' but
> > it just "feels" more proper? Thought since you are the maintainer in that
> > area - your opinion on how you want to do that is of course authoritive.
> > 
> 
> I don't have strong preference on this. I just happened to type in
> whatever style that flowed though my mind at that particular point. If
> Ian and you both feel strongly about this I can certainly resend. :-)

Lets wait to see what Ian says (or what he ends up checking in).
> 
> Wei.
> 
> > Regardless,
> > 
> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > +        printf_info(default_output_format, -1, &d_config, stdout);
> > >  
> > >      ret = 0;
> > >      if (dom_info->dryrun)
> > > -- 
> > > 1.7.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 Dec 13 18:47:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 18:47:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzriq-0002mx-RC; Sat, 13 Dec 2014 18:47:20 +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 1Xzrip-0002mr-DB
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 18:47:19 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	93/4D-17694-6B98C845; Sat, 13 Dec 2014 18:47:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418496436!13150552!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1938 invoked from network); 13 Dec 2014 18:47:17 -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 Dec 2014 18:47:17 -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 sBDIkvNv021803
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 13 Dec 2014 18:46: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
	sBDIkuWI005366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 13 Dec 2014 18:46:57 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
	sBDIku6S012254; Sat, 13 Dec 2014 18:46:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 13 Dec 2014 10:46:56 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 0FA16123889; Sat, 13 Dec 2014 13:46:51 -0500 (EST)
Date: Sat, 13 Dec 2014 13:46:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20141213184650.GA32014@laptop.dumpdata.com>
References: <1418489645-7689-1-git-send-email-wei.liu2@citrix.com>
	<20141213183716.GD31121@laptop.dumpdata.com>
	<20141213184209.GE2285@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141213184209.GE2285@zion.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: tlviewer@yahoo.com, M A Young <m.a.young@durham.ac.uk>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Dec 13, 2014 at 06:42:09PM +0000, Wei Liu wrote:
> On Sat, Dec 13, 2014 at 01:37:16PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Sat, Dec 13, 2014 at 04:54:05PM +0000, Wei Liu wrote:
> > > In commit d36a3734a ("xl: fix migration failure with xl migrate
> > > --debug"), message is printed to stderr for both debug mode
> > > and dryrun mode. That caused rdname() in xendomains fails to parse
> > > domain name since it's expecting input from xl's stdout.
> > > 
> > > So this patch separates those two cases. If xl is running in debug mode,
> > > then message is printed to stderr; if xl is running in dryrun mode and
> > > debug is not enabled, message is printed to stdout. This will fix
> > > xendomains and other scripts that use "xl create --dryrun", as well as
> > > not re-introducing the old bug fixed in d36a3734a.
> > > 
> > > Reported-by: Mark Pryor <tlviewer@yahoo.com>
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > Cc: M A Young <m.a.young@durham.ac.uk>
> > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > > ---
> > > This is a regression, and this bug is so subtle that's a bit hard to
> > > debug from user's point of view. So I think this should go into 4.5.
> > > 
> > > Mark posted a workaround in
> > > <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
> > > but to be honest I don't think it's nice to have everyone patch their
> > > scripts in order to work around this.
> > > ---
> > >  tools/libxl/xl_cmdimpl.c |    4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > > index 3737c7e..0a5f7c8 100644
> > > --- a/tools/libxl/xl_cmdimpl.c
> > > +++ b/tools/libxl/xl_cmdimpl.c
> > > @@ -2472,8 +2472,10 @@ static uint32_t create_domain(struct domain_create *dom_info)
> > >          }
> > >      }
> > >  
> > > -    if (debug || dom_info->dryrun)
> > > +    if (debug)
> > >          printf_info(default_output_format, -1, &d_config, stderr);
> > > +    if (!debug && dom_info->dryrun)
> > 
> > Could this 'else if (dom_info->dry_run)' ?
> > 
> > I know that semantically it is exactly the same as the 'if (!debug ..)' but
> > it just "feels" more proper? Thought since you are the maintainer in that
> > area - your opinion on how you want to do that is of course authoritive.
> > 
> 
> I don't have strong preference on this. I just happened to type in
> whatever style that flowed though my mind at that particular point. If
> Ian and you both feel strongly about this I can certainly resend. :-)

Lets wait to see what Ian says (or what he ends up checking in).
> 
> Wei.
> 
> > Regardless,
> > 
> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > +        printf_info(default_output_format, -1, &d_config, stdout);
> > >  
> > >      ret = 0;
> > >      if (dom_info->dryrun)
> > > -- 
> > > 1.7.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 Dec 13 19:08:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 19:08:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzs3A-0003Nl-W4; Sat, 13 Dec 2014 19:08:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xzs39-0003Ng-Uf
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 19:08:20 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B1/B5-27584-3AE8C845; Sat, 13 Dec 2014 19:08:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418497697!10303389!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6744 invoked from network); 13 Dec 2014 19:08:18 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2014 19:08:18 -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 sBDJ8DVL002055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 13 Dec 2014 19:08:14 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
	sBDJ8AkY010766
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 13 Dec 2014 19:08:11 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
	sBDJ8AaM015456; Sat, 13 Dec 2014 19:08:10 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 13 Dec 2014 11:08:09 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 027D21238FB; Sat, 13 Dec 2014 14:08:08 -0500 (EST)
Date: Sat, 13 Dec 2014 14:08:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141213190808.GA2842@laptop.dumpdata.com>
References: <1418419248-2863-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418419248-2863-1-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, 2014 at 04:20:48PM -0500, Boris Ostrovsky wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try dereference it in
> the future, when VCPU is gone.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  xen/arch/x86/hvm/vpmu.c |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)
> 
> This needs to be backported to 4.3 and 4.4 as well
> 
> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
> index 1df74c2..6d39680 100644
> --- a/xen/arch/x86/hvm/vpmu.c
> +++ b/xen/arch/x86/hvm/vpmu.c
> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
>      }
>  }
>  
> +static void vpmu_clear_last(void *arg)
> +{
> +    struct vcpu *v = (struct vcpu *)arg;
> +
> +    if ( this_cpu(last_vcpu) == v )
> +        this_cpu(last_vcpu) = NULL;
> +}
> +
>  void vpmu_destroy(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> +    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> +    {
> +        /* Need to clear last_vcpu in case it points to v */
> +        if ( vpmu->last_pcpu != smp_processor_id() )
> +            on_selected_cpus(cpumask_of(vpmu->last_pcpu),
> +                             vpmu_clear_last, (void *)v, 1);
> +        else
> +        {
> +            local_irq_disable();
> +            vpmu_clear_last((void *)v);
> +            local_irq_enable();
> +        }
> +    }
> +
>      if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>  }
> -- 
> 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 Sat Dec 13 19:08:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 19:08:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzs3A-0003Nl-W4; Sat, 13 Dec 2014 19:08:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Xzs39-0003Ng-Uf
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 19:08:20 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B1/B5-27584-3AE8C845; Sat, 13 Dec 2014 19:08:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418497697!10303389!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6744 invoked from network); 13 Dec 2014 19:08:18 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Dec 2014 19:08:18 -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 sBDJ8DVL002055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 13 Dec 2014 19:08:14 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
	sBDJ8AkY010766
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 13 Dec 2014 19:08:11 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
	sBDJ8AaM015456; Sat, 13 Dec 2014 19:08:10 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 13 Dec 2014 11:08:09 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 027D21238FB; Sat, 13 Dec 2014 14:08:08 -0500 (EST)
Date: Sat, 13 Dec 2014 14:08:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141213190808.GA2842@laptop.dumpdata.com>
References: <1418419248-2863-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418419248-2863-1-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 12, 2014 at 04:20:48PM -0500, Boris Ostrovsky wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try dereference it in
> the future, when VCPU is gone.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  xen/arch/x86/hvm/vpmu.c |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)
> 
> This needs to be backported to 4.3 and 4.4 as well
> 
> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
> index 1df74c2..6d39680 100644
> --- a/xen/arch/x86/hvm/vpmu.c
> +++ b/xen/arch/x86/hvm/vpmu.c
> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
>      }
>  }
>  
> +static void vpmu_clear_last(void *arg)
> +{
> +    struct vcpu *v = (struct vcpu *)arg;
> +
> +    if ( this_cpu(last_vcpu) == v )
> +        this_cpu(last_vcpu) = NULL;
> +}
> +
>  void vpmu_destroy(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> +    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> +    {
> +        /* Need to clear last_vcpu in case it points to v */
> +        if ( vpmu->last_pcpu != smp_processor_id() )
> +            on_selected_cpus(cpumask_of(vpmu->last_pcpu),
> +                             vpmu_clear_last, (void *)v, 1);
> +        else
> +        {
> +            local_irq_disable();
> +            vpmu_clear_last((void *)v);
> +            local_irq_enable();
> +        }
> +    }
> +
>      if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>  }
> -- 
> 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 Sat Dec 13 20:44:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 20: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 1XztXR-0005Pl-HA; Sat, 13 Dec 2014 20:43: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 1XztXP-0005Pg-7G
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 20:43:39 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	E2/2E-02696-AF4AC845; Sat, 13 Dec 2014 20:43:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418503415!14866531!1
X-Originating-IP: [66.165.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 24395 invoked from network); 13 Dec 2014 20:43:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 20:43:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,572,1413244800"; d="scan'208";a="203925728"
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.210.2; Sat, 13 Dec 2014 15:43: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 1XztXI-0006BT-TB;
	Sat, 13 Dec 2014 20:43:32 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XztXI-000722-Mi;
	Sat, 13 Dec 2014 20:43:32 +0000
Date: Sat, 13 Dec 2014 20:43:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32316-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 10955
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 32316: 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="===============1279727408808480324=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1279727408808480324==
Content-Type: text/plain
Content-Length: 10685
Content-Transfer-Encoding: quoted-printable

flight 32316 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32316/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  3 host-install(3)     broken REGR. vs. 32245
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 32245
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 32245
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 32245
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 32245
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)  broken REGR. vs. 32245
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 32245
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 32245

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-xl          10 migrate-support-check        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-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-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-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                  7e73a6e7f12ae080222c5d339799905de3443a6e
baseline version:
 xen                  60ce518a1b1caf2c1e4c1b203e87fb0b179ba687

------------------------------------------------------------
People who touched revisions under test:
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
  Mukesh Rathor <mukesh.rathor@oracle.com>
  Roger Pau Monn=C3=A9 <roger.pau@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                                          broken  
 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                     broken  
 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                               broken  
 test-amd64-i386-rumpuserxen-i386                             broken  
 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                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 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-rumpuserxen-i386 host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)
broken-step test-amd64-amd64-xl host-install(3)
broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)
broken-step test-amd64-i386-pair host-install/dst_host(4)

Not pushing.

------------------------------------------------------------
commit 7e73a6e7f12ae080222c5d339799905de3443a6e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Dec 11 17:14:07 2014 +0100

    have architectures specify the number of PIRQs a hardware domain gets
    
    The current value of nr_static_irqs + 256 is often too small for larger
    systems. Make it dependent on CPU count and number of IO-APIC pins on
    x86, and (until it obtains PCI support) simply NR_IRQS on ARM.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>

commit 4ef6b5f16c8a91cf6592f8817720a9de95b7052c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Dec 11 17:13:04 2014 +0100

    lock down hypercall continuation encoding masks
    
    Andrew validly points out that even if these masks aren't a formal part
    of the hypercall interface, we aren't free to change them: A guest
    suspended for migration in the middle of a continuation would fail to
    work if resumed on a hypervisor using a different value. Hence add
    respective comments to their definitions.
    
    Additionally, to help future extensibility as well as in the spirit of
    reducing undefined behavior as much as possible, refuse hypercalls made
    with the respective bits non-zero when the respective sub-ops don't
    make use of those bits.
    
    Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Release-Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>

commit 4d1308afaafa43ff68d6ecc493e36ee8f3ac9942
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Dec 11 12:24:05 2014 +0100

    VMX: don't allow PVH to reach handle_mmio()
    
    PVH guests accessing I/O ports via string ops is not supported yet.
    
    Reported-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Mukesh Rathor <mukesh.rathor@oracle.com>
    Acked-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
    Acked-by: Kevin Tian <kevin.tian@intel.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(qemu changes not included)


--===============1279727408808480324==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1279727408808480324==--

From xen-devel-bounces@lists.xen.org Sat Dec 13 20:44:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 20: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 1XztXR-0005Pl-HA; Sat, 13 Dec 2014 20:43: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 1XztXP-0005Pg-7G
	for xen-devel@lists.xensource.com; Sat, 13 Dec 2014 20:43:39 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	E2/2E-02696-AF4AC845; Sat, 13 Dec 2014 20:43:38 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418503415!14866531!1
X-Originating-IP: [66.165.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 24395 invoked from network); 13 Dec 2014 20:43:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 20:43:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,572,1413244800"; d="scan'208";a="203925728"
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.210.2; Sat, 13 Dec 2014 15:43: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 1XztXI-0006BT-TB;
	Sat, 13 Dec 2014 20:43:32 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1XztXI-000722-Mi;
	Sat, 13 Dec 2014 20:43:32 +0000
Date: Sat, 13 Dec 2014 20:43:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32316-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 10955
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 32316: 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="===============1279727408808480324=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1279727408808480324==
Content-Type: text/plain
Content-Length: 10685
Content-Transfer-Encoding: quoted-printable

flight 32316 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32316/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  3 host-install(3)     broken REGR. vs. 32245
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 32245
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 32245
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 32245
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 32245
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)  broken REGR. vs. 32245
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 32245
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 32245

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-xl          10 migrate-support-check        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-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-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-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                  7e73a6e7f12ae080222c5d339799905de3443a6e
baseline version:
 xen                  60ce518a1b1caf2c1e4c1b203e87fb0b179ba687

------------------------------------------------------------
People who touched revisions under test:
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
  Mukesh Rathor <mukesh.rathor@oracle.com>
  Roger Pau Monn=C3=A9 <roger.pau@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                                          broken  
 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                     broken  
 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                               broken  
 test-amd64-i386-rumpuserxen-i386                             broken  
 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                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 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-rumpuserxen-i386 host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)
broken-step test-amd64-amd64-xl host-install(3)
broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)
broken-step test-amd64-i386-pair host-install/dst_host(4)

Not pushing.

------------------------------------------------------------
commit 7e73a6e7f12ae080222c5d339799905de3443a6e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Dec 11 17:14:07 2014 +0100

    have architectures specify the number of PIRQs a hardware domain gets
    
    The current value of nr_static_irqs + 256 is often too small for larger
    systems. Make it dependent on CPU count and number of IO-APIC pins on
    x86, and (until it obtains PCI support) simply NR_IRQS on ARM.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>

commit 4ef6b5f16c8a91cf6592f8817720a9de95b7052c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Dec 11 17:13:04 2014 +0100

    lock down hypercall continuation encoding masks
    
    Andrew validly points out that even if these masks aren't a formal part
    of the hypercall interface, we aren't free to change them: A guest
    suspended for migration in the middle of a continuation would fail to
    work if resumed on a hypervisor using a different value. Hence add
    respective comments to their definitions.
    
    Additionally, to help future extensibility as well as in the spirit of
    reducing undefined behavior as much as possible, refuse hypercalls made
    with the respective bits non-zero when the respective sub-ops don't
    make use of those bits.
    
    Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Release-Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>

commit 4d1308afaafa43ff68d6ecc493e36ee8f3ac9942
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Dec 11 12:24:05 2014 +0100

    VMX: don't allow PVH to reach handle_mmio()
    
    PVH guests accessing I/O ports via string ops is not supported yet.
    
    Reported-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Mukesh Rathor <mukesh.rathor@oracle.com>
    Acked-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
    Acked-by: Kevin Tian <kevin.tian@intel.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(qemu changes not included)


--===============1279727408808480324==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1279727408808480324==--

From xen-devel-bounces@lists.xen.org Sat Dec 13 20:50:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 20: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 1Xztda-0005YF-BS; Sat, 13 Dec 2014 20:50:02 +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 1XztdZ-0005YA-MV
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 20:50:01 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	C8/8A-16982-876AC845; Sat, 13 Dec 2014 20:50:00 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418503798!8708127!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31650 invoked from network); 13 Dec 2014 20:50:00 -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; 13 Dec 2014 20:50: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 sBDKnuoX031353
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 13 Dec 2014 20:49:57 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
	sBDKntHH006146
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 13 Dec 2014 20:49:56 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
	sBDKntaO027892; Sat, 13 Dec 2014 20:49:55 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 ; Sat, 13 Dec 2014 12:49:54 -0800
Message-ID: <548CA6E6.9050604@oracle.com>
Date: Sat, 13 Dec 2014 15:51:50 -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>
References: <1418419248-2863-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141213190808.GA2842@laptop.dumpdata.com>
In-Reply-To: <20141213190808.GA2842@laptop.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/13/2014 02:08 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 12, 2014 at 04:20:48PM -0500, Boris Ostrovsky wrote:
>> We need to make sure that last_vcpu is not pointing to VCPU whose
>> VPMU is being destroyed. Otherwise we may try dereference it in
>> the future, when VCPU is gone.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

I would like to send a slightly better patch on Monday (along the same 
lines but trying to avoid unnecessary IPIs if not needed).

-boris


>> ---
>>   xen/arch/x86/hvm/vpmu.c |   22 ++++++++++++++++++++++
>>   1 files changed, 22 insertions(+), 0 deletions(-)
>>
>> This needs to be backported to 4.3 and 4.4 as well
>>
>> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
>> index 1df74c2..6d39680 100644
>> --- a/xen/arch/x86/hvm/vpmu.c
>> +++ b/xen/arch/x86/hvm/vpmu.c
>> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
>>       }
>>   }
>>   
>> +static void vpmu_clear_last(void *arg)
>> +{
>> +    struct vcpu *v = (struct vcpu *)arg;
>> +
>> +    if ( this_cpu(last_vcpu) == v )
>> +        this_cpu(last_vcpu) = NULL;
>> +}
>> +
>>   void vpmu_destroy(struct vcpu *v)
>>   {
>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>   
>> +    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
>> +    {
>> +        /* Need to clear last_vcpu in case it points to v */
>> +        if ( vpmu->last_pcpu != smp_processor_id() )
>> +            on_selected_cpus(cpumask_of(vpmu->last_pcpu),
>> +                             vpmu_clear_last, (void *)v, 1);
>> +        else
>> +        {
>> +            local_irq_disable();
>> +            vpmu_clear_last((void *)v);
>> +            local_irq_enable();
>> +        }
>> +    }
>> +
>>       if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>>           vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>>   }
>> -- 
>> 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 Sat Dec 13 20:50:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Dec 2014 20: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 1Xztda-0005YF-BS; Sat, 13 Dec 2014 20:50:02 +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 1XztdZ-0005YA-MV
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 20:50:01 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	C8/8A-16982-876AC845; Sat, 13 Dec 2014 20:50:00 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418503798!8708127!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31650 invoked from network); 13 Dec 2014 20:50:00 -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; 13 Dec 2014 20:50: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 sBDKnuoX031353
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 13 Dec 2014 20:49:57 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
	sBDKntHH006146
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 13 Dec 2014 20:49:56 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
	sBDKntaO027892; Sat, 13 Dec 2014 20:49:55 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 ; Sat, 13 Dec 2014 12:49:54 -0800
Message-ID: <548CA6E6.9050604@oracle.com>
Date: Sat, 13 Dec 2014 15:51:50 -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>
References: <1418419248-2863-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141213190808.GA2842@laptop.dumpdata.com>
In-Reply-To: <20141213190808.GA2842@laptop.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/13/2014 02:08 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 12, 2014 at 04:20:48PM -0500, Boris Ostrovsky wrote:
>> We need to make sure that last_vcpu is not pointing to VCPU whose
>> VPMU is being destroyed. Otherwise we may try dereference it in
>> the future, when VCPU is gone.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

I would like to send a slightly better patch on Monday (along the same 
lines but trying to avoid unnecessary IPIs if not needed).

-boris


>> ---
>>   xen/arch/x86/hvm/vpmu.c |   22 ++++++++++++++++++++++
>>   1 files changed, 22 insertions(+), 0 deletions(-)
>>
>> This needs to be backported to 4.3 and 4.4 as well
>>
>> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
>> index 1df74c2..6d39680 100644
>> --- a/xen/arch/x86/hvm/vpmu.c
>> +++ b/xen/arch/x86/hvm/vpmu.c
>> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
>>       }
>>   }
>>   
>> +static void vpmu_clear_last(void *arg)
>> +{
>> +    struct vcpu *v = (struct vcpu *)arg;
>> +
>> +    if ( this_cpu(last_vcpu) == v )
>> +        this_cpu(last_vcpu) = NULL;
>> +}
>> +
>>   void vpmu_destroy(struct vcpu *v)
>>   {
>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>   
>> +    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
>> +    {
>> +        /* Need to clear last_vcpu in case it points to v */
>> +        if ( vpmu->last_pcpu != smp_processor_id() )
>> +            on_selected_cpus(cpumask_of(vpmu->last_pcpu),
>> +                             vpmu_clear_last, (void *)v, 1);
>> +        else
>> +        {
>> +            local_irq_disable();
>> +            vpmu_clear_last((void *)v);
>> +            local_irq_enable();
>> +        }
>> +    }
>> +
>>       if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>>           vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>>   }
>> -- 
>> 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 Sun Dec 14 03:21:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 03:21:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzzk2-00012b-FX; Sun, 14 Dec 2014 03:21:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlatimer@suse.com>) id 1Xzzk1-00012W-A3
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 03:21:05 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	11/02-31453-0220D845; Sun, 14 Dec 2014 03:21:04 +0000
X-Env-Sender: mlatimer@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418527262!13186283!1
X-Originating-IP: [137.65.248.124]
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 30770 invoked from network); 14 Dec 2014 03:21:03 -0000
Received: from inet-orm.provo.novell.com (HELO mail.novell.com)
	(137.65.248.124)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2014 03:21:03 -0000
Received: from linux-4w67.dnsdhcp.provo.novell.com ([137.65.220.21])
	by mail.novell.com with ESMTP (NOT encrypted);
	Sat, 13 Dec 2014 20:20:50 -0700
From: Mike Latimer <mlatimer@suse.com>
To: xen-devel@lists.xen.org
Date: Sat, 13 Dec 2014 20:20:49 -0700
Message-ID: <3154807.Gz8aOatYUo@linux-4w67.dnsdhcp.provo.novell.com>
User-Agent: KMail/4.11.5 (Linux/3.11.10-7-desktop; KDE/4.11.5; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] Ballooning dom0: insufficient memory (libxl) or CPU
	soft lockups (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've recently been testing large memory (64GB - 1TB) domains, and encountering 
CPU soft lockups while dom0 is ballooning down to free memory for the domain. 
The root of the issue also exposes a difference between libxl and libvirt.

When creating a domain using xl, if ballooning is enabled (and required) there 
is a 33 second window for the memory request to be satisfied. If not, an 
ERROR_NOMEM is returned and the domain create fails. (See 
tools/libxl/xl_cmdimpl.c:freemem)

The libvirt code for the same operation 
(src/libxl/libxl_domain.c:libxlDomainFreeMem) is nearly identical, except the 
function returns the value of 'ret'. The intent seems to be the same as libxl, 
but ret is set to 0 by libxl_wait_for_memory_target if memory ballooning is 
still ongoing at the end of the 33 second loop. The end result is that when 
using libvirt, the process believes the free memory call succeeded and 
continues to create the domain despite the fact that dom0 has not finished 
ballooning.

In either case, dom0 continues to balloon in the background. In the case of 
libxl, a second attempt to create the domain will succeed after waiting until 
this ballooning finishes. With libvirt, the original create request encounters 
contention between dom0 ballooning down and that same memory being allocated 
to the starting domain. This contention can cause CPU soft lockups, and a 
major performance degradation. This issue is more easily seen when using large 
domains (64-128GB+) and slower memory models (such as large NUMA 
configurations).

It is trivial to correct the bug in libvirt and cause it to return ERROR_NOMEM 
if ballooning is not finished by the end of the libxlDomainFreeMem loop. (I've 
tested this, and it does cause libvirt to behave like libxl.) However, it 
seems that a more correct fix would be to continue to wait for free memory if 
the ballooning process is progressing.

In some tests I've performed, ballooning down 100GB has taken as long as 2.5 
minutes. If users are attempting to create very large domains, the 33 second 
delay to balloon the memory seems rather low. I realize that best practices 
include using a set dom0 size with ballooning disabled, but I'd rather not see 
insufficient memory errors or produce CPU soft lockups if users choose not to 
follow this advice.

To summarize:

- If using xl, dom0 ballooning has to complete in 33 seconds, or ERROR_NOMEM 
will be encountered.
- If using virsh, the domain can be created while dom0 is still ballooning 
down. This results in CPU soft lockups/performance degradation across the 
entire host. (When creating a very large domain, the soft lockups can be 
severe enough to kill the machine.)

Any thoughts on handling this?

Thanks,
Mike


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 14 03:21:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 03:21:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Xzzk2-00012b-FX; Sun, 14 Dec 2014 03:21:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mlatimer@suse.com>) id 1Xzzk1-00012W-A3
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 03:21:05 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	11/02-31453-0220D845; Sun, 14 Dec 2014 03:21:04 +0000
X-Env-Sender: mlatimer@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418527262!13186283!1
X-Originating-IP: [137.65.248.124]
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 30770 invoked from network); 14 Dec 2014 03:21:03 -0000
Received: from inet-orm.provo.novell.com (HELO mail.novell.com)
	(137.65.248.124)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2014 03:21:03 -0000
Received: from linux-4w67.dnsdhcp.provo.novell.com ([137.65.220.21])
	by mail.novell.com with ESMTP (NOT encrypted);
	Sat, 13 Dec 2014 20:20:50 -0700
From: Mike Latimer <mlatimer@suse.com>
To: xen-devel@lists.xen.org
Date: Sat, 13 Dec 2014 20:20:49 -0700
Message-ID: <3154807.Gz8aOatYUo@linux-4w67.dnsdhcp.provo.novell.com>
User-Agent: KMail/4.11.5 (Linux/3.11.10-7-desktop; KDE/4.11.5; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] Ballooning dom0: insufficient memory (libxl) or CPU
	soft lockups (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've recently been testing large memory (64GB - 1TB) domains, and encountering 
CPU soft lockups while dom0 is ballooning down to free memory for the domain. 
The root of the issue also exposes a difference between libxl and libvirt.

When creating a domain using xl, if ballooning is enabled (and required) there 
is a 33 second window for the memory request to be satisfied. If not, an 
ERROR_NOMEM is returned and the domain create fails. (See 
tools/libxl/xl_cmdimpl.c:freemem)

The libvirt code for the same operation 
(src/libxl/libxl_domain.c:libxlDomainFreeMem) is nearly identical, except the 
function returns the value of 'ret'. The intent seems to be the same as libxl, 
but ret is set to 0 by libxl_wait_for_memory_target if memory ballooning is 
still ongoing at the end of the 33 second loop. The end result is that when 
using libvirt, the process believes the free memory call succeeded and 
continues to create the domain despite the fact that dom0 has not finished 
ballooning.

In either case, dom0 continues to balloon in the background. In the case of 
libxl, a second attempt to create the domain will succeed after waiting until 
this ballooning finishes. With libvirt, the original create request encounters 
contention between dom0 ballooning down and that same memory being allocated 
to the starting domain. This contention can cause CPU soft lockups, and a 
major performance degradation. This issue is more easily seen when using large 
domains (64-128GB+) and slower memory models (such as large NUMA 
configurations).

It is trivial to correct the bug in libvirt and cause it to return ERROR_NOMEM 
if ballooning is not finished by the end of the libxlDomainFreeMem loop. (I've 
tested this, and it does cause libvirt to behave like libxl.) However, it 
seems that a more correct fix would be to continue to wait for free memory if 
the ballooning process is progressing.

In some tests I've performed, ballooning down 100GB has taken as long as 2.5 
minutes. If users are attempting to create very large domains, the 33 second 
delay to balloon the memory seems rather low. I realize that best practices 
include using a set dom0 size with ballooning disabled, but I'd rather not see 
insufficient memory errors or produce CPU soft lockups if users choose not to 
follow this advice.

To summarize:

- If using xl, dom0 ballooning has to complete in 33 seconds, or ERROR_NOMEM 
will be encountered.
- If using virsh, the domain can be created while dom0 is still ballooning 
down. This results in CPU soft lockups/performance degradation across the 
entire host. (When creating a very large domain, the soft lockups can be 
severe enough to kill the machine.)

Any thoughts on handling this?

Thanks,
Mike


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 14 04:12:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 04: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 1Y00X9-000202-Oh; Sun, 14 Dec 2014 04:11:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y00X7-0001yK-Rv
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 04:11:50 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	B3/8A-02957-50E0D845; Sun, 14 Dec 2014 04:11:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418530307!14928548!1
X-Originating-IP: [66.165.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 9618 invoked from network); 14 Dec 2014 04:11:48 -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 Dec 2014 04:11:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,573,1413244800"; d="scan'208";a="203995910"
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.210.2; Sat, 13 Dec 2014 23:11: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 1Y00X3-0008KM-Ic;
	Sun, 14 Dec 2014 04:11:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y00X3-0007Jt-DY;
	Sun, 14 Dec 2014 04:11:45 +0000
Date: Sun, 14 Dec 2014 04:11:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32323-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] 32323: 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 32323 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32323/

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-multivcpu 11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-xl           9 guest-start               fail REGR. vs. 31241
 test-amd64-i386-xl           12 guest-localmigrate        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 3 host-install(3) broken REGR. vs. 31241
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)  broken REGR. vs. 31241
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 31241
 test-amd64-amd64-pair  17 guest-migrate/src_host/dst_host fail REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 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-amd64-xl-sedf     15 guest-localmigrate/x10    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       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          10 migrate-support-check        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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                2756d373a3f45a3a9ebf4ac389f9e0e02bd35a93
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1456 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                                          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                     broken  
 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                         broken  
 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                          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                             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                         broken  
 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                                 broken  
 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-amd64-xl-sedf-pin host-install(3)
broken-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-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)

Not pushing.

(No revision log; it would be 146129 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 Dec 14 04:12:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 04: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 1Y00X9-000202-Oh; Sun, 14 Dec 2014 04:11:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y00X7-0001yK-Rv
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 04:11:50 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	B3/8A-02957-50E0D845; Sun, 14 Dec 2014 04:11:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418530307!14928548!1
X-Originating-IP: [66.165.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 9618 invoked from network); 14 Dec 2014 04:11:48 -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 Dec 2014 04:11:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,573,1413244800"; d="scan'208";a="203995910"
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.210.2; Sat, 13 Dec 2014 23:11: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 1Y00X3-0008KM-Ic;
	Sun, 14 Dec 2014 04:11:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y00X3-0007Jt-DY;
	Sun, 14 Dec 2014 04:11:45 +0000
Date: Sun, 14 Dec 2014 04:11:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32323-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] 32323: 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 32323 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32323/

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-multivcpu 11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 31241
 test-amd64-amd64-xl           9 guest-start               fail REGR. vs. 31241
 test-amd64-i386-xl           12 guest-localmigrate        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 3 host-install(3) broken REGR. vs. 31241
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)  broken REGR. vs. 31241
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 31241
 test-amd64-amd64-pair  17 guest-migrate/src_host/dst_host fail REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 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-amd64-xl-sedf     15 guest-localmigrate/x10    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       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          10 migrate-support-check        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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                2756d373a3f45a3a9ebf4ac389f9e0e02bd35a93
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1456 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                                          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                     broken  
 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                         broken  
 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                          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                             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                         broken  
 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                                 broken  
 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-amd64-xl-sedf-pin host-install(3)
broken-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-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)

Not pushing.

(No revision log; it would be 146129 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 Dec 14 07:10:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 07: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 1Y03Iv-0005Ho-RW; Sun, 14 Dec 2014 07:09: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 1Y03It-0005Hj-Pe
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 07:09:20 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	C4/A5-17694-E973D845; Sun, 14 Dec 2014 07:09:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418540956!13165582!1
X-Originating-IP: [66.165.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 18949 invoked from network); 14 Dec 2014 07:09:17 -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 Dec 2014 07:09:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,574,1413244800"; d="scan'208";a="204023418"
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.210.2; Sun, 14 Dec 2014 02:09: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 1Y03Ip-0000mw-1y;
	Sun, 14 Dec 2014 07:09:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y03Io-0004CN-R4;
	Sun, 14 Dec 2014 07:09:14 +0000
Date: Sun, 14 Dec 2014 07:09:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32330-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8236
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32330: 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="===============1032148669457218347=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1032148669457218347==
Content-Type: text/plain
Content-Length: 7962
Content-Transfer-Encoding: quoted-printable

flight 32330 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32330/

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              c7d1c139ca3402e875002753952e80ce8054374e
baseline version:
 libvirt              15abebdecb35308ddd4d2967efa6dffa4842fac9

------------------------------------------------------------
People who touched revisions under test:
  C=C3=A9dric Bosdonnat <cbosdonnat@suse.com>
  Daniel Veillard <veillard@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=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3Dc7d1c139ca3402e875002753952e80ce8054374e
+ . 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 c7d1c139ca3402e875002753952e80ce8054374e
+ branch=3Dlibvirt
+ revision=3Dc7d1c139ca3402e875002753952e80ce8054374e
+ . 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 c7d1c139ca3402e875002753952e80ce8054374e:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   15abebd..c7d1c13  c7d1c139ca3402e875002753952e80ce8054374e -> xen-tested-master


--===============1032148669457218347==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1032148669457218347==--

From xen-devel-bounces@lists.xen.org Sun Dec 14 07:10:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 07: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 1Y03Iv-0005Ho-RW; Sun, 14 Dec 2014 07:09: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 1Y03It-0005Hj-Pe
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 07:09:20 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	C4/A5-17694-E973D845; Sun, 14 Dec 2014 07:09:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418540956!13165582!1
X-Originating-IP: [66.165.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 18949 invoked from network); 14 Dec 2014 07:09:17 -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 Dec 2014 07:09:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,574,1413244800"; d="scan'208";a="204023418"
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.210.2; Sun, 14 Dec 2014 02:09: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 1Y03Ip-0000mw-1y;
	Sun, 14 Dec 2014 07:09:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y03Io-0004CN-R4;
	Sun, 14 Dec 2014 07:09:14 +0000
Date: Sun, 14 Dec 2014 07:09:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32330-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8236
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32330: 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="===============1032148669457218347=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1032148669457218347==
Content-Type: text/plain
Content-Length: 7962
Content-Transfer-Encoding: quoted-printable

flight 32330 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32330/

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              c7d1c139ca3402e875002753952e80ce8054374e
baseline version:
 libvirt              15abebdecb35308ddd4d2967efa6dffa4842fac9

------------------------------------------------------------
People who touched revisions under test:
  C=C3=A9dric Bosdonnat <cbosdonnat@suse.com>
  Daniel Veillard <veillard@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=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3Dc7d1c139ca3402e875002753952e80ce8054374e
+ . 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 c7d1c139ca3402e875002753952e80ce8054374e
+ branch=3Dlibvirt
+ revision=3Dc7d1c139ca3402e875002753952e80ce8054374e
+ . 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 c7d1c139ca3402e875002753952e80ce8054374e:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   15abebd..c7d1c13  c7d1c139ca3402e875002753952e80ce8054374e -> xen-tested-master


--===============1032148669457218347==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1032148669457218347==--

From xen-devel-bounces@lists.xen.org Sun Dec 14 07:43:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 07: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 1Y03pw-000602-P0; Sun, 14 Dec 2014 07:43: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 1Y03pv-0005zx-PS
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 07:43:27 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	DA/B1-03145-E9F3D845; Sun, 14 Dec 2014 07:43:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418543004!14925972!1
X-Originating-IP: [66.165.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 28204 invoked from network); 14 Dec 2014 07:43:25 -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 Dec 2014 07:43:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,574,1413244800"; d="scan'208";a="204028700"
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.210.2; Sun, 14 Dec 2014 02:43: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 1Y03pr-0000wy-0Y;
	Sun, 14 Dec 2014 07:43:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y03pq-0005ub-Rg;
	Sun, 14 Dec 2014 07:43:22 +0000
Date: Sun, 14 Dec 2014 07:43:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32326-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 9288
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32326: 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="===============7536262512080584099=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7536262512080584099==
Content-Type: text/plain
Content-Length: 8986
Content-Transfer-Encoding: quoted-printable

flight 32326 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32326/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 32194
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 32194
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 32194
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32194
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 32194
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 32194
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 32194
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 guest-localmigrate.2 fail REGR. vs. 32194
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 32194
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 32194

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 32194
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32194

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-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-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-armhf-armhf-xl          10 migrate-support-check        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-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                99c9c3cb24e566258a0a141178934f9cb5198842
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Amos Kong <akong@redhat.com>
  Anton Blanchard <anton@samba.org>
  Antony Pavlov <antonynpavlov@gmail.com>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Christoffer Dall <christoffer.dall@linaro.org>
  Dr. David Alan Gilbert <dgilbert@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>
  Jeff Cody <jcody@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  lijun <junmuzi@gmail.com>
  Liviu Ionescu <ilg@livius.net>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael Mueller <mimu@linux.vnet.ibm.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Nikita Belov <zodiac@ispras.ru>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@linux.vnet.ibm.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                                           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                    broken  
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     broken  
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         broken  
 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                         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                                   broken  
 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                         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                                        broken  
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 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-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, 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-xl-credit2 host-install(3)
broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-amd64-xl-sedf-pin host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-win7-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)

Not pushing.

(No revision log; it would be 2395 lines long.)


--===============7536262512080584099==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7536262512080584099==--

From xen-devel-bounces@lists.xen.org Sun Dec 14 07:43:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 07: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 1Y03pw-000602-P0; Sun, 14 Dec 2014 07:43: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 1Y03pv-0005zx-PS
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 07:43:27 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	DA/B1-03145-E9F3D845; Sun, 14 Dec 2014 07:43:26 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418543004!14925972!1
X-Originating-IP: [66.165.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 28204 invoked from network); 14 Dec 2014 07:43:25 -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 Dec 2014 07:43:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,574,1413244800"; d="scan'208";a="204028700"
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.210.2; Sun, 14 Dec 2014 02:43: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 1Y03pr-0000wy-0Y;
	Sun, 14 Dec 2014 07:43:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y03pq-0005ub-Rg;
	Sun, 14 Dec 2014 07:43:22 +0000
Date: Sun, 14 Dec 2014 07:43:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32326-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 9288
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32326: 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="===============7536262512080584099=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7536262512080584099==
Content-Type: text/plain
Content-Length: 8986
Content-Transfer-Encoding: quoted-printable

flight 32326 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32326/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 32194
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 32194
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 32194
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32194
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 32194
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 32194
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 32194
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 guest-localmigrate.2 fail REGR. vs. 32194
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 32194
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 32194

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 32194
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32194

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-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-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-armhf-armhf-xl          10 migrate-support-check        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-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                99c9c3cb24e566258a0a141178934f9cb5198842
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Amos Kong <akong@redhat.com>
  Anton Blanchard <anton@samba.org>
  Antony Pavlov <antonynpavlov@gmail.com>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Christoffer Dall <christoffer.dall@linaro.org>
  Dr. David Alan Gilbert <dgilbert@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>
  Jeff Cody <jcody@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  lijun <junmuzi@gmail.com>
  Liviu Ionescu <ilg@livius.net>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael Mueller <mimu@linux.vnet.ibm.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Nikita Belov <zodiac@ispras.ru>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@linux.vnet.ibm.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                                           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                    broken  
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    fail    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     broken  
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         broken  
 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                         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                                   broken  
 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                         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                                        broken  
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 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-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, 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-xl-credit2 host-install(3)
broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-amd64-xl-sedf-pin host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-win7-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)

Not pushing.

(No revision log; it would be 2395 lines long.)


--===============7536262512080584099==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7536262512080584099==--

From xen-devel-bounces@lists.xen.org Sun Dec 14 11:50:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 11: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 1Y07gJ-0001rE-LB; Sun, 14 Dec 2014 11:49: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 1Y07gI-0001r9-15
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 11:49:46 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	2C/4F-02712-9597D845; Sun, 14 Dec 2014 11:49:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418557783!14947239!1
X-Originating-IP: [66.165.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 23881 invoked from network); 14 Dec 2014 11:49:44 -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 Dec 2014 11:49:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,575,1413244800"; d="scan'208";a="204070831"
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.210.2; Sun, 14 Dec 2014 06:49: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 1Y07gD-00027l-3g;
	Sun, 14 Dec 2014 11:49:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y07gC-0007dt-T3;
	Sun, 14 Dec 2014 11:49:40 +0000
Date: Sun, 14 Dec 2014 11:49:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32329-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] 32329: 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 32329 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32329/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl           3 host-install(3)           broken pass in 32298
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 32298
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 32298
 test-amd64-i386-xl-credit2    3 host-install(3)           broken pass in 32298
 test-amd64-i386-xl            3 host-install(3)           broken pass in 32298
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3)   broken pass in 32298
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 32298
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 32298
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)    broken pass in 32298
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken pass in 32298
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 32298
 test-amd64-i386-pair          4 host-install/dst_host(4)  broken pass in 32298
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 32298 pass in 32329

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 32298 like 32231

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-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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-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-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
 test-armhf-armhf-xl          10 migrate-support-check fail in 32298 never pass

version targeted for testing:
 xen                  7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
baseline version:
 xen                  de6313ab40a2858693609338db935cb689380361

------------------------------------------------------------
People who touched revisions under test:
  Frediano Ziglio <frediano.ziglio@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Julien Grall <julien.grall@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.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                                          broken  
 test-armhf-armhf-xl                                          broken  
 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                    broken  
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    broken  
 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                           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                                   broken  
 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                         broken  
 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                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          broken  
 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-armhf-armhf-xl host-install(3)
broken-step test-amd64-amd64-pv host-install(3)
broken-step test-amd64-i386-xl-multivcpu host-install(3)
broken-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-intel 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-amd64-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-pair host-install/dst_host(4)

Pushing revision :

+ branch=xen-4.4-testing
+ revision=7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
+ . 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 7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
+ branch=xen-4.4-testing
+ revision=7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
+ . 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 7bb6b2722be1e27f99948e5c68f7f42eb23f8e53:stable-4.4
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   de6313a..7bb6b27  7bb6b2722be1e27f99948e5c68f7f42eb23f8e53 -> 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 Dec 14 11:50:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 11: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 1Y07gJ-0001rE-LB; Sun, 14 Dec 2014 11:49: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 1Y07gI-0001r9-15
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 11:49:46 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	2C/4F-02712-9597D845; Sun, 14 Dec 2014 11:49:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418557783!14947239!1
X-Originating-IP: [66.165.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 23881 invoked from network); 14 Dec 2014 11:49:44 -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 Dec 2014 11:49:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,575,1413244800"; d="scan'208";a="204070831"
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.210.2; Sun, 14 Dec 2014 06:49: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 1Y07gD-00027l-3g;
	Sun, 14 Dec 2014 11:49:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y07gC-0007dt-T3;
	Sun, 14 Dec 2014 11:49:40 +0000
Date: Sun, 14 Dec 2014 11:49:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32329-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] 32329: 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 32329 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32329/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl           3 host-install(3)           broken pass in 32298
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 32298
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 32298
 test-amd64-i386-xl-credit2    3 host-install(3)           broken pass in 32298
 test-amd64-i386-xl            3 host-install(3)           broken pass in 32298
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3)   broken pass in 32298
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 32298
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 32298
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)    broken pass in 32298
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken pass in 32298
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 32298
 test-amd64-i386-pair          4 host-install/dst_host(4)  broken pass in 32298
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 32298 pass in 32329

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 32298 like 32231

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-i386-rumpuserxen        6 xen-build                    fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 build-amd64-rumpuserxen       6 xen-build                    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-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-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-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-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
 test-armhf-armhf-xl          10 migrate-support-check fail in 32298 never pass

version targeted for testing:
 xen                  7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
baseline version:
 xen                  de6313ab40a2858693609338db935cb689380361

------------------------------------------------------------
People who touched revisions under test:
  Frediano Ziglio <frediano.ziglio@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Julien Grall <julien.grall@linaro.org>
  Stefano Stabellini <stefano.stabellini@eu.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                                          broken  
 test-armhf-armhf-xl                                          broken  
 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                    broken  
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    broken  
 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                           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                                   broken  
 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                         broken  
 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                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          broken  
 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-armhf-armhf-xl host-install(3)
broken-step test-amd64-amd64-pv host-install(3)
broken-step test-amd64-i386-xl-multivcpu host-install(3)
broken-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-intel 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-amd64-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-pair host-install/dst_host(4)

Pushing revision :

+ branch=xen-4.4-testing
+ revision=7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
+ . 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 7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
+ branch=xen-4.4-testing
+ revision=7bb6b2722be1e27f99948e5c68f7f42eb23f8e53
+ . 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 7bb6b2722be1e27f99948e5c68f7f42eb23f8e53:stable-4.4
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   de6313a..7bb6b27  7bb6b2722be1e27f99948e5c68f7f42eb23f8e53 -> 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 Dec 14 13:35:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 13:35:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y09KU-0003tR-7m; Sun, 14 Dec 2014 13:35:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gallagnv.rao@gmail.com>) id 1Y09KT-0003tM-9Q
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 13:35:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A2/9F-25276-8129D845; Sun, 14 Dec 2014 13:35:20 +0000
X-Env-Sender: gallagnv.rao@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418564118!15490968!1
X-Originating-IP: [209.85.213.176]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7621 invoked from network); 14 Dec 2014 13:35:19 -0000
Received: from mail-ig0-f176.google.com (HELO mail-ig0-f176.google.com)
	(209.85.213.176)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2014 13:35:19 -0000
Received: by mail-ig0-f176.google.com with SMTP id l13so3993876iga.15
	for <xen-devel@lists.xen.org>; Sun, 14 Dec 2014 05:35:18 -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=S5pUgfL1iuLDaMI6/4ZWjtKhMm9aNv9eeu5IJMZPSgk=;
	b=qLYjxQ1nDHBgf2oEJ4QaHu68f1LJyuXOISk6XrxJLqfHA1UcskFZFA9FunyQ8Y17Gq
	kVSagJCpzQ/5cZuDk5nDJw8xBqlt5MDFjUgoQGgMgIM3PSxESw2a94jmnK9xO++KnwOk
	Y2uUDjYqvWiuBHUFb1vsN9g1ywGbRt3cM6SRUzboCOFSD856DvgEgtFarW7nXpG0rbTm
	f9S7O8dXs+tcaZVuVrVIqnZ3FgScAT9yE9YZq96F5l5uKwJWvgDKgtXbgoiyssoPJv75
	T6IY1MZApJzYZ+qJA3rMsX1cyx3qBk9X49dmd2m3zalm/+5BJVTwU8jhiuMp1EwURcJz
	AOmg==
MIME-Version: 1.0
X-Received: by 10.42.255.72 with SMTP id nh8mr23107573icb.1.1418564118493;
	Sun, 14 Dec 2014 05:35:18 -0800 (PST)
Received: by 10.107.43.87 with HTTP; Sun, 14 Dec 2014 05:35:18 -0800 (PST)
Date: Sun, 14 Dec 2014 19:05:18 +0530
Message-ID: <CANtx2outtiqeGzvbnCX0kY9jocp_+qCUjpxr8ypfWUMjx5A1gA@mail.gmail.com>
From: Galla Rao <gallagnv.rao@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] SRIOV on a NIC card
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6876564287992588032=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6876564287992588032==
Content-Type: multipart/alternative; boundary=bcaec511e5fa5fbe6e050a2d32da

--bcaec511e5fa5fbe6e050a2d32da
Content-Type: text/plain; charset=UTF-8

Am trying to boot a guest OS on a Virtual Function, It hangs in preboot
The server is not a x86, it is on SUN SPARC

What BIOS/pre-boot has to enable to make Guest OS boot on VF
The PF& VF driver in OS are working well

VF Enable is set
VF MSE is set

What could be the possible failure?

Any thoughts welcome, Thanks for your time!

Regards
Ranga

--bcaec511e5fa5fbe6e050a2d32da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style=3D"font-size:13px">Am trying to boot=C2=A0a gue=
st OS on a Virtual Function, It hangs in preboot</div><div style=3D"font-si=
ze:13px">The server is not a x86, it is on SUN SPARC</div><div style=3D"fon=
t-size:13px"><br></div><div style=3D"font-size:13px">What BIOS/pre-boot has=
 to enable to make Guest OS boot on VF</div><div style=3D"font-size:13px">T=
he PF&amp; VF driver in OS are working well</div><div style=3D"font-size:13=
px"><br></div><div style=3D"font-size:13px">VF Enable is set<br></div><div =
style=3D"font-size:13px">VF MSE is set</div><div style=3D"font-size:13px"><=
br></div><div style=3D"font-size:13px">What could be the possible failure?<=
/div><div style=3D"font-size:13px"><br></div><div style=3D"font-size:13px">=
Any thoughts welcome, Thanks for your time!</div><div style=3D"font-size:13=
px"><br></div><div style=3D"font-size:13px">Regards</div><div style=3D"font=
-size:13px">Ranga</div></div>

--bcaec511e5fa5fbe6e050a2d32da--


--===============6876564287992588032==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6876564287992588032==--


From xen-devel-bounces@lists.xen.org Sun Dec 14 13:35:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 13:35:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y09KU-0003tR-7m; Sun, 14 Dec 2014 13:35:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gallagnv.rao@gmail.com>) id 1Y09KT-0003tM-9Q
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 13:35:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A2/9F-25276-8129D845; Sun, 14 Dec 2014 13:35:20 +0000
X-Env-Sender: gallagnv.rao@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418564118!15490968!1
X-Originating-IP: [209.85.213.176]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7621 invoked from network); 14 Dec 2014 13:35:19 -0000
Received: from mail-ig0-f176.google.com (HELO mail-ig0-f176.google.com)
	(209.85.213.176)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2014 13:35:19 -0000
Received: by mail-ig0-f176.google.com with SMTP id l13so3993876iga.15
	for <xen-devel@lists.xen.org>; Sun, 14 Dec 2014 05:35:18 -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=S5pUgfL1iuLDaMI6/4ZWjtKhMm9aNv9eeu5IJMZPSgk=;
	b=qLYjxQ1nDHBgf2oEJ4QaHu68f1LJyuXOISk6XrxJLqfHA1UcskFZFA9FunyQ8Y17Gq
	kVSagJCpzQ/5cZuDk5nDJw8xBqlt5MDFjUgoQGgMgIM3PSxESw2a94jmnK9xO++KnwOk
	Y2uUDjYqvWiuBHUFb1vsN9g1ywGbRt3cM6SRUzboCOFSD856DvgEgtFarW7nXpG0rbTm
	f9S7O8dXs+tcaZVuVrVIqnZ3FgScAT9yE9YZq96F5l5uKwJWvgDKgtXbgoiyssoPJv75
	T6IY1MZApJzYZ+qJA3rMsX1cyx3qBk9X49dmd2m3zalm/+5BJVTwU8jhiuMp1EwURcJz
	AOmg==
MIME-Version: 1.0
X-Received: by 10.42.255.72 with SMTP id nh8mr23107573icb.1.1418564118493;
	Sun, 14 Dec 2014 05:35:18 -0800 (PST)
Received: by 10.107.43.87 with HTTP; Sun, 14 Dec 2014 05:35:18 -0800 (PST)
Date: Sun, 14 Dec 2014 19:05:18 +0530
Message-ID: <CANtx2outtiqeGzvbnCX0kY9jocp_+qCUjpxr8ypfWUMjx5A1gA@mail.gmail.com>
From: Galla Rao <gallagnv.rao@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] SRIOV on a NIC card
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6876564287992588032=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6876564287992588032==
Content-Type: multipart/alternative; boundary=bcaec511e5fa5fbe6e050a2d32da

--bcaec511e5fa5fbe6e050a2d32da
Content-Type: text/plain; charset=UTF-8

Am trying to boot a guest OS on a Virtual Function, It hangs in preboot
The server is not a x86, it is on SUN SPARC

What BIOS/pre-boot has to enable to make Guest OS boot on VF
The PF& VF driver in OS are working well

VF Enable is set
VF MSE is set

What could be the possible failure?

Any thoughts welcome, Thanks for your time!

Regards
Ranga

--bcaec511e5fa5fbe6e050a2d32da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style=3D"font-size:13px">Am trying to boot=C2=A0a gue=
st OS on a Virtual Function, It hangs in preboot</div><div style=3D"font-si=
ze:13px">The server is not a x86, it is on SUN SPARC</div><div style=3D"fon=
t-size:13px"><br></div><div style=3D"font-size:13px">What BIOS/pre-boot has=
 to enable to make Guest OS boot on VF</div><div style=3D"font-size:13px">T=
he PF&amp; VF driver in OS are working well</div><div style=3D"font-size:13=
px"><br></div><div style=3D"font-size:13px">VF Enable is set<br></div><div =
style=3D"font-size:13px">VF MSE is set</div><div style=3D"font-size:13px"><=
br></div><div style=3D"font-size:13px">What could be the possible failure?<=
/div><div style=3D"font-size:13px"><br></div><div style=3D"font-size:13px">=
Any thoughts welcome, Thanks for your time!</div><div style=3D"font-size:13=
px"><br></div><div style=3D"font-size:13px">Regards</div><div style=3D"font=
-size:13px">Ranga</div></div>

--bcaec511e5fa5fbe6e050a2d32da--


--===============6876564287992588032==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6876564287992588032==--


From xen-devel-bounces@lists.xen.org Sun Dec 14 14:16:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 14:16:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y09xZ-0004hI-Ia; Sun, 14 Dec 2014 14:15:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y09xX-0004hB-HL
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 14:15:43 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	9A/9C-14214-E8B9D845; Sun, 14 Dec 2014 14:15:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418566539!13285761!1
X-Originating-IP: [66.165.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 29217 invoked from network); 14 Dec 2014 14:15: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;
	14 Dec 2014 14:15:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,575,1413244800"; d="scan'208";a="204097436"
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.210.2; Sun, 14 Dec 2014 09:15: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 1Y09xR-0002or-Ez;
	Sun, 14 Dec 2014 14:15:37 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y09xR-000826-7X;
	Sun, 14 Dec 2014 14:15:37 +0000
Date: Sun, 14 Dec 2014 14:15:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32332-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] 32332: 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 32332 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32332/

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-sedf-pin  3 host-install(3)           broken pass in 32315
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)         broken pass in 32277
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 32315
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 32315
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3)   broken pass in 32315
 test-amd64-i386-freebsd10-i386  3 host-install(3)         broken pass in 32315
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 32315
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)    broken pass in 32315
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 32277
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 32315 pass in 32332
 test-amd64-amd64-xl-win7-amd64 13 guest-localmigrate/x10 fail in 32315 pass in 32332
 test-amd64-i386-freebsd10-amd64 16 guest-start.2   fail in 32277 pass in 32332
 test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail in 32277 pass in 32332

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-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

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-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-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-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-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-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 14 guest-stop                fail never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                     broken  
 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                               broken  
 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                         broken  
 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                                 broken  
 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                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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)
broken-step test-amd64-i386-rhel6hvm-intel host-install(3)
broken-step test-amd64-amd64-xl-sedf host-install(3)
broken-step test-amd64-i386-xl-multivcpu host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)

Not pushing.

(No revision log; it would be 34178 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 Dec 14 14:16:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 14:16:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y09xZ-0004hI-Ia; Sun, 14 Dec 2014 14:15:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y09xX-0004hB-HL
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 14:15:43 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	9A/9C-14214-E8B9D845; Sun, 14 Dec 2014 14:15:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418566539!13285761!1
X-Originating-IP: [66.165.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 29217 invoked from network); 14 Dec 2014 14:15: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;
	14 Dec 2014 14:15:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,575,1413244800"; d="scan'208";a="204097436"
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.210.2; Sun, 14 Dec 2014 09:15: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 1Y09xR-0002or-Ez;
	Sun, 14 Dec 2014 14:15:37 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y09xR-000826-7X;
	Sun, 14 Dec 2014 14:15:37 +0000
Date: Sun, 14 Dec 2014 14:15:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32332-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] 32332: 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 32332 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32332/

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-sedf-pin  3 host-install(3)           broken pass in 32315
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)         broken pass in 32277
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 32315
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 32315
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3)   broken pass in 32315
 test-amd64-i386-freebsd10-i386  3 host-install(3)         broken pass in 32315
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 32315
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)    broken pass in 32315
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 32277
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 32315 pass in 32332
 test-amd64-amd64-xl-win7-amd64 13 guest-localmigrate/x10 fail in 32315 pass in 32332
 test-amd64-i386-freebsd10-amd64 16 guest-start.2   fail in 32277 pass in 32332
 test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail in 32277 pass in 32332

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-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

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-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-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-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-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-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 14 guest-stop                fail never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                     broken  
 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                               broken  
 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                         broken  
 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                                 broken  
 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                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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)
broken-step test-amd64-i386-rhel6hvm-intel host-install(3)
broken-step test-amd64-amd64-xl-sedf host-install(3)
broken-step test-amd64-i386-xl-multivcpu host-install(3)
broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)

Not pushing.

(No revision log; it would be 34178 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 Dec 14 14:34:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 14: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 1Y0AFP-00058G-9L; Sun, 14 Dec 2014 14:34:11 +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 1Y0AFO-00058B-PT
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 14:34:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C0/40-25276-2EF9D845; Sun, 14 Dec 2014 14:34:10 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418567649!7455153!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9877 invoked from network); 14 Dec 2014 14:34:09 -0000
Received: from emh07.mail.saunalahti.fi (HELO emh07.mail.saunalahti.fi)
	(62.142.5.117)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2014 14:34:09 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 9D5BD3FDF;
	Sun, 14 Dec 2014 16:34:08 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 92C9936C05C; Sun, 14 Dec 2014 16:34:08 +0200 (EET)
Date: Sun, 14 Dec 2014 16:34:08 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Galla Rao <gallagnv.rao@gmail.com>
Message-ID: <20141214143408.GB19091@reaktio.net>
References: <CANtx2outtiqeGzvbnCX0kY9jocp_+qCUjpxr8ypfWUMjx5A1gA@mail.gmail.com>
MIME-Version: 1.0
Content-Length: 690
Content-Disposition: inline
In-Reply-To: <CANtx2outtiqeGzvbnCX0kY9jocp_+qCUjpxr8ypfWUMjx5A1gA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] SRIOV on a NIC card
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 14, 2014 at 07:05:18PM +0530, Galla Rao wrote:
>    Am trying to boot=C2 a guest OS on a Virtual Function, It hangs in pre=
boot
>    The server is not a x86, it is on SUN SPARC
>

Afaik Xen has never been ported to SPARC.. Are you sure you're using Xen hy=
pervisor? =



-- Pasi

>    What BIOS/pre-boot has to enable to make Guest OS boot on VF
>    The PF& VF driver in OS are working well
>    VF Enable is set
>    VF MSE is set
>    What could be the possible failure?
>    Any thoughts welcome, Thanks for your time!
>    Regards
>    Ranga



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 14 14:34:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 14: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 1Y0AFP-00058G-9L; Sun, 14 Dec 2014 14:34:11 +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 1Y0AFO-00058B-PT
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 14:34:10 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C0/40-25276-2EF9D845; Sun, 14 Dec 2014 14:34:10 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418567649!7455153!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9877 invoked from network); 14 Dec 2014 14:34:09 -0000
Received: from emh07.mail.saunalahti.fi (HELO emh07.mail.saunalahti.fi)
	(62.142.5.117)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Dec 2014 14:34:09 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 9D5BD3FDF;
	Sun, 14 Dec 2014 16:34:08 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 92C9936C05C; Sun, 14 Dec 2014 16:34:08 +0200 (EET)
Date: Sun, 14 Dec 2014 16:34:08 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Galla Rao <gallagnv.rao@gmail.com>
Message-ID: <20141214143408.GB19091@reaktio.net>
References: <CANtx2outtiqeGzvbnCX0kY9jocp_+qCUjpxr8ypfWUMjx5A1gA@mail.gmail.com>
MIME-Version: 1.0
Content-Length: 690
Content-Disposition: inline
In-Reply-To: <CANtx2outtiqeGzvbnCX0kY9jocp_+qCUjpxr8ypfWUMjx5A1gA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] SRIOV on a NIC card
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 14, 2014 at 07:05:18PM +0530, Galla Rao wrote:
>    Am trying to boot=C2 a guest OS on a Virtual Function, It hangs in pre=
boot
>    The server is not a x86, it is on SUN SPARC
>

Afaik Xen has never been ported to SPARC.. Are you sure you're using Xen hy=
pervisor? =



-- Pasi

>    What BIOS/pre-boot has to enable to make Guest OS boot on VF
>    The PF& VF driver in OS are working well
>    VF Enable is set
>    VF MSE is set
>    What could be the possible failure?
>    Any thoughts welcome, Thanks for your time!
>    Regards
>    Ranga



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 14 14:58:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 14:58:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Acp-0005b3-DY; Sun, 14 Dec 2014 14:58: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 1Y0Aco-0005ay-0v
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 14:58:22 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	E1/CF-02953-D85AD845; Sun, 14 Dec 2014 14:58:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418569099!14877359!1
X-Originating-IP: [66.165.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 23628 invoked from network); 14 Dec 2014 14:58:20 -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;
	14 Dec 2014 14:58:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,575,1413244800"; d="scan'208";a="204529629"
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.210.2;
	Sun, 14 Dec 2014 09:58:18 -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 1Y0Acj-0000Kb-LB;
	Sun, 14 Dec 2014 14:58:17 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <libvir-list@redhat.com>
Date: Sun, 14 Dec 2014 14:58:17 +0000
Message-ID: <1418569097-19322-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: jfehlig@suse.com, Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xenconfig: fix boot device parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 code always checked *boot which was in effect boot[0]. It
should use boot[i].

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 src/xenconfig/xen_common.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c
index 7f4ec89..48431a7 100644
--- a/src/xenconfig/xen_common.c
+++ b/src/xenconfig/xen_common.c
@@ -1071,7 +1071,7 @@ xenParseOS(virConfPtr conf, virDomainDefPtr def)
             return -1;
 
         for (i = 0; i < VIR_DOMAIN_BOOT_LAST && boot[i]; i++) {
-            switch (*boot) {
+            switch (boot[i]) {
             case 'a':
                 def->os.bootDevs[i] = VIR_DOMAIN_BOOT_FLOPPY;
                 break;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 14 14:58:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 14:58:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Acp-0005b3-DY; Sun, 14 Dec 2014 14:58: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 1Y0Aco-0005ay-0v
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 14:58:22 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	E1/CF-02953-D85AD845; Sun, 14 Dec 2014 14:58:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418569099!14877359!1
X-Originating-IP: [66.165.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 23628 invoked from network); 14 Dec 2014 14:58:20 -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;
	14 Dec 2014 14:58:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,575,1413244800"; d="scan'208";a="204529629"
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.210.2;
	Sun, 14 Dec 2014 09:58:18 -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 1Y0Acj-0000Kb-LB;
	Sun, 14 Dec 2014 14:58:17 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <libvir-list@redhat.com>
Date: Sun, 14 Dec 2014 14:58:17 +0000
Message-ID: <1418569097-19322-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: jfehlig@suse.com, Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xenconfig: fix boot device parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 code always checked *boot which was in effect boot[0]. It
should use boot[i].

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 src/xenconfig/xen_common.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c
index 7f4ec89..48431a7 100644
--- a/src/xenconfig/xen_common.c
+++ b/src/xenconfig/xen_common.c
@@ -1071,7 +1071,7 @@ xenParseOS(virConfPtr conf, virDomainDefPtr def)
             return -1;
 
         for (i = 0; i < VIR_DOMAIN_BOOT_LAST && boot[i]; i++) {
-            switch (*boot) {
+            switch (boot[i]) {
             case 'a':
                 def->os.bootDevs[i] = VIR_DOMAIN_BOOT_FLOPPY;
                 break;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 14 15:39:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 15:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BGP-0006NZ-Op; Sun, 14 Dec 2014 15:39:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gallagnv.rao@gmail.com>) id 1Y0BGO-0006NU-7x
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 15:39:16 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	4D/0E-17735-32FAD845; Sun, 14 Dec 2014 15:39:15 +0000
X-Env-Sender: gallagnv.rao@gmail.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418571553!13202248!1
X-Originating-IP: [209.85.223.179]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8670 invoked from network); 14 Dec 2014 15:39:14 -0000
Received: from mail-ie0-f179.google.com (HELO mail-ie0-f179.google.com)
	(209.85.223.179)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2014 15:39:14 -0000
Received: by mail-ie0-f179.google.com with SMTP id rp18so9520255iec.10
	for <xen-devel@lists.xen.org>; Sun, 14 Dec 2014 07:39: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=vAvhB++ZIPQZErpidPwn8HCPEWebXjrYQyBSVAcEQDg=;
	b=J76JsIgqSsE2AeJoQqww8iofpLhLh6M9XiyZSv3h+RCs9BLAr2Be7/eBiys+qfeliY
	3iRI6iWwuH7f2Vv0GPBjDNYKe9d/DY3BW/hQy4kCqXeoJPQQ9I3/nJtLat/dFMdZX9vi
	cy5ZUO785yrUrrDUQsgGHZOs94PdGuyLxbNP9BfHWDDIMSI4xFZhUK10TPaiEHR0W7tD
	6WC614g4wHpEYtz/6218U4vGBkWtFyUi9uCbbheTQ2HNz57M3qR/mOJBQLAhQmrA0CyR
	IvgUlta2PeOwz+KlBaw6PeKCKeDzGDtEl95c+0CejV18maT4zqwmPR6o2InwKTEOEiTg
	9YHQ==
MIME-Version: 1.0
X-Received: by 10.43.104.3 with SMTP id dk3mr24148544icc.47.1418571553147;
	Sun, 14 Dec 2014 07:39:13 -0800 (PST)
Received: by 10.107.43.87 with HTTP; Sun, 14 Dec 2014 07:39:13 -0800 (PST)
In-Reply-To: <20141214143408.GB19091@reaktio.net>
References: <CANtx2outtiqeGzvbnCX0kY9jocp_+qCUjpxr8ypfWUMjx5A1gA@mail.gmail.com>
	<20141214143408.GB19091@reaktio.net>
Date: Sun, 14 Dec 2014 21:09:13 +0530
Message-ID: <CANtx2ovOxN_R0BQskE_OyA_1YjU22x4f4DWhmgzrjbe3iRO6xg@mail.gmail.com>
From: Galla Rao <gallagnv.rao@gmail.com>
To: =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] SRIOV on a NIC card
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2480086527411642301=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2480086527411642301==
Content-Type: multipart/alternative; boundary=bcaec5171a49838dea050a2eed27

--bcaec5171a49838dea050a2eed27
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

True it is not on Xen, it is on solaris platform

As SRIOV (PCIe) spec is same on all platforms, the feature implementation
should not change

May be not an appropriate group for posting this query.





On Sun, Dec 14, 2014 at 8:04 PM, Pasi K=C3=A4rkk=C3=A4inen <pasik@iki.fi> w=
rote:
>
> On Sun, Dec 14, 2014 at 07:05:18PM +0530, Galla Rao wrote:
> >    Am trying to boot=C4=80 a guest OS on a Virtual Function, It hangs i=
n
> preboot
> >    The server is not a x86, it is on SUN SPARC
> >
>
> Afaik Xen has never been ported to SPARC.. Are you sure you're using Xen
> hypervisor?
>
>
> -- Pasi
>
> >    What BIOS/pre-boot has to enable to make Guest OS boot on VF
> >    The PF& VF driver in OS are working well
> >    VF Enable is set
> >    VF MSE is set
> >    What could be the possible failure?
> >    Any thoughts welcome, Thanks for your time!
> >    Regards
> >    Ranga
>
>
>

--bcaec5171a49838dea050a2eed27
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>True it is not on Xen, it is on solaris platform</div=
><div><br></div><div>As SRIOV (PCIe) spec is same on all platforms, the fea=
ture implementation</div><div>should not change</div><div><br></div><div>Ma=
y be not an appropriate group=C2=A0for posting this query.</div><div><br></=
div><div><br></div><div><br></div><div><br></div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Sun, Dec 14, 2014 at 8:04 PM, Pasi=
 K=C3=A4rkk=C3=A4inen <span dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi"=
 target=3D"_blank">pasik@iki.fi</a>&gt;</span> wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">On Sun, Dec 14, 2014 at 07:05:18PM +0530, Galla Rao wrote:<br>
&gt;=C2=A0 =C2=A0 Am trying to boot=C4=80 a guest OS on a Virtual Function,=
 It hangs in preboot<br>
<span>&gt;=C2=A0 =C2=A0 The server is not a x86, it is on SUN SPARC<br>
&gt;<br>
<br>
</span>Afaik Xen has never been ported to SPARC.. Are you sure you&#39;re u=
sing Xen hypervisor?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- Pasi<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;=C2=A0 =C2=A0 What BIOS/pre-boot has to enable to make Guest OS boot on=
 VF<br>
&gt;=C2=A0 =C2=A0 The PF&amp; VF driver in OS are working well<br>
&gt;=C2=A0 =C2=A0 VF Enable is set<br>
&gt;=C2=A0 =C2=A0 VF MSE is set<br>
&gt;=C2=A0 =C2=A0 What could be the possible failure?<br>
&gt;=C2=A0 =C2=A0 Any thoughts welcome, Thanks for your time!<br>
&gt;=C2=A0 =C2=A0 Regards<br>
&gt;=C2=A0 =C2=A0 Ranga<br>
<br>
<br>
</div></div></blockquote></div></div>

--bcaec5171a49838dea050a2eed27--


--===============2480086527411642301==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2480086527411642301==--


From xen-devel-bounces@lists.xen.org Sun Dec 14 15:39:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 15:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BGP-0006NZ-Op; Sun, 14 Dec 2014 15:39:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gallagnv.rao@gmail.com>) id 1Y0BGO-0006NU-7x
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 15:39:16 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	4D/0E-17735-32FAD845; Sun, 14 Dec 2014 15:39:15 +0000
X-Env-Sender: gallagnv.rao@gmail.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418571553!13202248!1
X-Originating-IP: [209.85.223.179]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8670 invoked from network); 14 Dec 2014 15:39:14 -0000
Received: from mail-ie0-f179.google.com (HELO mail-ie0-f179.google.com)
	(209.85.223.179)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2014 15:39:14 -0000
Received: by mail-ie0-f179.google.com with SMTP id rp18so9520255iec.10
	for <xen-devel@lists.xen.org>; Sun, 14 Dec 2014 07:39: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=vAvhB++ZIPQZErpidPwn8HCPEWebXjrYQyBSVAcEQDg=;
	b=J76JsIgqSsE2AeJoQqww8iofpLhLh6M9XiyZSv3h+RCs9BLAr2Be7/eBiys+qfeliY
	3iRI6iWwuH7f2Vv0GPBjDNYKe9d/DY3BW/hQy4kCqXeoJPQQ9I3/nJtLat/dFMdZX9vi
	cy5ZUO785yrUrrDUQsgGHZOs94PdGuyLxbNP9BfHWDDIMSI4xFZhUK10TPaiEHR0W7tD
	6WC614g4wHpEYtz/6218U4vGBkWtFyUi9uCbbheTQ2HNz57M3qR/mOJBQLAhQmrA0CyR
	IvgUlta2PeOwz+KlBaw6PeKCKeDzGDtEl95c+0CejV18maT4zqwmPR6o2InwKTEOEiTg
	9YHQ==
MIME-Version: 1.0
X-Received: by 10.43.104.3 with SMTP id dk3mr24148544icc.47.1418571553147;
	Sun, 14 Dec 2014 07:39:13 -0800 (PST)
Received: by 10.107.43.87 with HTTP; Sun, 14 Dec 2014 07:39:13 -0800 (PST)
In-Reply-To: <20141214143408.GB19091@reaktio.net>
References: <CANtx2outtiqeGzvbnCX0kY9jocp_+qCUjpxr8ypfWUMjx5A1gA@mail.gmail.com>
	<20141214143408.GB19091@reaktio.net>
Date: Sun, 14 Dec 2014 21:09:13 +0530
Message-ID: <CANtx2ovOxN_R0BQskE_OyA_1YjU22x4f4DWhmgzrjbe3iRO6xg@mail.gmail.com>
From: Galla Rao <gallagnv.rao@gmail.com>
To: =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] SRIOV on a NIC card
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2480086527411642301=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2480086527411642301==
Content-Type: multipart/alternative; boundary=bcaec5171a49838dea050a2eed27

--bcaec5171a49838dea050a2eed27
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

True it is not on Xen, it is on solaris platform

As SRIOV (PCIe) spec is same on all platforms, the feature implementation
should not change

May be not an appropriate group for posting this query.





On Sun, Dec 14, 2014 at 8:04 PM, Pasi K=C3=A4rkk=C3=A4inen <pasik@iki.fi> w=
rote:
>
> On Sun, Dec 14, 2014 at 07:05:18PM +0530, Galla Rao wrote:
> >    Am trying to boot=C4=80 a guest OS on a Virtual Function, It hangs i=
n
> preboot
> >    The server is not a x86, it is on SUN SPARC
> >
>
> Afaik Xen has never been ported to SPARC.. Are you sure you're using Xen
> hypervisor?
>
>
> -- Pasi
>
> >    What BIOS/pre-boot has to enable to make Guest OS boot on VF
> >    The PF& VF driver in OS are working well
> >    VF Enable is set
> >    VF MSE is set
> >    What could be the possible failure?
> >    Any thoughts welcome, Thanks for your time!
> >    Regards
> >    Ranga
>
>
>

--bcaec5171a49838dea050a2eed27
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>True it is not on Xen, it is on solaris platform</div=
><div><br></div><div>As SRIOV (PCIe) spec is same on all platforms, the fea=
ture implementation</div><div>should not change</div><div><br></div><div>Ma=
y be not an appropriate group=C2=A0for posting this query.</div><div><br></=
div><div><br></div><div><br></div><div><br></div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Sun, Dec 14, 2014 at 8:04 PM, Pasi=
 K=C3=A4rkk=C3=A4inen <span dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi"=
 target=3D"_blank">pasik@iki.fi</a>&gt;</span> wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">On Sun, Dec 14, 2014 at 07:05:18PM +0530, Galla Rao wrote:<br>
&gt;=C2=A0 =C2=A0 Am trying to boot=C4=80 a guest OS on a Virtual Function,=
 It hangs in preboot<br>
<span>&gt;=C2=A0 =C2=A0 The server is not a x86, it is on SUN SPARC<br>
&gt;<br>
<br>
</span>Afaik Xen has never been ported to SPARC.. Are you sure you&#39;re u=
sing Xen hypervisor?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- Pasi<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;=C2=A0 =C2=A0 What BIOS/pre-boot has to enable to make Guest OS boot on=
 VF<br>
&gt;=C2=A0 =C2=A0 The PF&amp; VF driver in OS are working well<br>
&gt;=C2=A0 =C2=A0 VF Enable is set<br>
&gt;=C2=A0 =C2=A0 VF MSE is set<br>
&gt;=C2=A0 =C2=A0 What could be the possible failure?<br>
&gt;=C2=A0 =C2=A0 Any thoughts welcome, Thanks for your time!<br>
&gt;=C2=A0 =C2=A0 Regards<br>
&gt;=C2=A0 =C2=A0 Ranga<br>
<br>
<br>
</div></div></blockquote></div></div>

--bcaec5171a49838dea050a2eed27--


--===============2480086527411642301==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2480086527411642301==--


From xen-devel-bounces@lists.xen.org Sun Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Bni-0007kb-KR; Sun, 14 Dec 2014 16:13:42 +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 1Y0Bnh-0007jn-S2
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:41 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	B8/8C-02702-537BD845; Sun, 14 Dec 2014 16:13:41 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418573620!14971544!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26763 invoked from network); 14 Dec 2014 16:13:40 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-14.tower-27.messagelabs.com with SMTP;
	14 Dec 2014 16:13:40 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 14 Dec 2014 08:13:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="647434702"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 14 Dec 2014 08:13:38 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:56 -0500
Message-Id: <1418558996-13718-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 10/12] vTPM/TPM2: Support TPM 2.0 bind and
	unbind 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bind data with TPM2_RSA_Encrypt, which performs RSA encryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1). If the
scheme of keyHandle is TPM_ALG_NULL, then the caller may use inScheme
to specify the padding scheme.
Unbind data with TPM2_RSA_Decrypt, which performs RSA decryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1).

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/disk_tpm.c | 42 ++++++++++++++++++++++++++++++++++++++++--
 stubdom/vtpmmgr/disk_tpm.h |  4 ++++
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_tpm.c b/stubdom/vtpmmgr/disk_tpm.c
index d650fbc..2e33eac 100644
--- a/stubdom/vtpmmgr/disk_tpm.c
+++ b/stubdom/vtpmmgr/disk_tpm.c
@@ -12,17 +12,20 @@
 #include <polarssl/sha1.h>
 
 #include "tpm.h"
+#include "tpm2.h"
 #include "tcg.h"
 
 #include "vtpmmgr.h"
 #include "vtpm_disk.h"
 #include "disk_tpm.h"
 
+#include "log.h"
 // Print out input/output of seal/unseal operations (includes keys)
 #undef DEBUG_SEAL_OPS
 
 #ifdef DEBUG_SEAL_OPS
 #include "marshal.h"
+#include "tpm2_marshal.h"
 #endif
 
 struct pcr_list {
@@ -31,11 +34,16 @@ struct pcr_list {
 
 static struct pcr_list hwtpm;
 
+/*Ignore PCR on TPM 2.0, read PCR values for TPM 1.x seal | unseal*/
 void TPM_read_pcrs(void)
 {
 	int i;
-	for(i=0; i < 24; i++)
-		TPM_PCR_Read(i, &hwtpm.pcrs[i]);
+	for (i=0; i < 24; i++) {
+        if (hw_is_tpm2())
+            memset(&hwtpm.pcrs[i], 0, TPM_DIGEST_SIZE);
+        else
+		    TPM_PCR_Read(i, &hwtpm.pcrs[i]);
+    }
 }
 
 struct pcr_composite_3 {
@@ -138,6 +146,36 @@ int TPM_disk_seal(struct disk_seal_entry *dst, const void* src, size_t size)
 	return rc;
 }
 
+TPM_RC TPM2_disk_bind(struct disk_seal_entry *dst, void* src, unsigned int size)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+
+    TPMTRYRETURN(TPM2_Bind(vtpm_globals.sk_handle,
+                           src,
+                           size,
+                           dst->sealed_data));
+
+abort_egress:
+egress:
+   return status;
+}
+
+TPM_RC TPM2_disk_unbind(void *dst, unsigned int *size, const struct disk_seal_entry *src)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+    unsigned char buf[RSA_CIPHER_SIZE];
+
+    memcpy(buf, src->sealed_data, RSA_CIPHER_SIZE);
+    TPMTRYRETURN(TPM2_UnBind(vtpm_globals.sk_handle,
+                             RSA_CIPHER_SIZE,
+                             buf,
+                             size,
+                             dst));
+abort_egress:
+egress:
+   return status;
+}
+
 int TPM_disk_unseal(void *dst, size_t size, const struct disk_seal_entry *src)
 {
 	uint32_t rc;
diff --git a/stubdom/vtpmmgr/disk_tpm.h b/stubdom/vtpmmgr/disk_tpm.h
index b235895..57ae2a6 100644
--- a/stubdom/vtpmmgr/disk_tpm.h
+++ b/stubdom/vtpmmgr/disk_tpm.h
@@ -10,6 +10,10 @@ void TPM_pcr_digest(struct hash160 *buf, le32_t selection);
 int TPM_disk_seal(struct disk_seal_entry *dst, const void* src, size_t size);
 int TPM_disk_unseal(void *dst, size_t size, const struct disk_seal_entry *src);
 
+/*TPM 2.0 Bind and Unbind */
+TPM_RC TPM2_disk_bind(struct disk_seal_entry *dst, void* src, unsigned int size);
+TPM_RC TPM2_disk_unbind(void *dst, unsigned int *size, const struct disk_seal_entry *src);
+
 /* NVRAM to allow revocation of TM-KEY */
 int TPM_disk_nvalloc(be32_t *nvram_slot, struct tpm_authdata auth);
 int TPM_disk_nvread(void *buf, size_t bufsiz, be32_t nvram_slot, struct tpm_authdata auth);
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Bnm-0007nF-1U; Sun, 14 Dec 2014 16:13:46 +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 1Y0Bnk-0007ls-He
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:44 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	B3/24-02698-737BD845; Sun, 14 Dec 2014 16:13:43 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418573611!14939834!3
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 31074 invoked from network); 14 Dec 2014 16:13:42 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-27.messagelabs.com with SMTP;
	14 Dec 2014 16:13:42 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2014 08:13:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="637398655"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 14 Dec 2014 08:13:40 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:58 -0500
Message-Id: <1418558998-13755-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 11/12] vTPM/TPM2: Bind group keys and sectors
	data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/disk_write.c | 29 ++++++++++++++++++++---------
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_write.c b/stubdom/vtpmmgr/disk_write.c
index 4c825c5..73018ef 100644
--- a/stubdom/vtpmmgr/disk_write.c
+++ b/stubdom/vtpmmgr/disk_write.c
@@ -83,12 +83,18 @@ static void generate_group_seals(struct mem_group *src, const struct mem_tpm_mgr
 	if (src->nr_seals > NR_SEALS_PER_GROUP)
 		abort();
 
-	for(i=0; i < src->nr_seals; i++) {
+	for (i=0; i < src->nr_seals; i++) {
 		struct disk_seal_entry *dst = &src->seal_bits.entry[i];
-		dst->pcr_selection = src->seals[i].pcr_selection;
-		memcpy(&dst->digest_release, &src->seals[i].digest_release, 20);
-		TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
-		TPM_disk_seal(dst, &sblob, sizeof(sblob));
+
+        /*TPM 2.0 bind | TPM 1.x seal*/
+        if (hw_is_tpm2()) {
+            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+        } else {
+            dst->pcr_selection = src->seals[i].pcr_selection;
+            memcpy(&dst->digest_release, &src->seals[i].digest_release, 20);
+            TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
+            TPM_disk_seal(dst, &sblob, sizeof(sblob));
+        }
 	}
 	src->seal_bits.nr_cfgs = native_be32(src->nr_seals);
 
@@ -246,11 +252,16 @@ static void disk_write_seal_list(struct mem_tpm_mgr *mgr, struct mem_group *grou
 	for(i=0; i < group->nr_seals; i++) {
 		struct mem_seal *src = &group->seals[i];
 		struct disk_seal_entry *dst = &seal->entry[i];
-		dst->pcr_selection = src->pcr_selection;
-		memcpy(&dst->digest_release, &src->digest_release, 20);
-		TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
 
-		TPM_disk_seal(dst, &sblob, sizeof(sblob));
+        /*TPM 2.0 bind / TPM 1.x seal*/
+        if (hw_is_tpm2()) {
+            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+        } else {
+            dst->pcr_selection = src->pcr_selection;
+            memcpy(&dst->digest_release, &src->digest_release, 20);
+            TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
+            TPM_disk_seal(dst, &sblob, sizeof(sblob));
+        }
 	}
 
 	memcpy(seal->hdr.magic, TPM_MGR_MAGIC, 12);
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnV-0007av-4t; Sun, 14 Dec 2014 16:13:29 +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 1Y0BnU-0007ad-K3
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:28 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	86/85-02696-827BD845; Sun, 14 Dec 2014 16:13:28 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418573606!14980121!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22117 invoked from network); 14 Dec 2014 16:13:27 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-27.messagelabs.com with SMTP;
	14 Dec 2014 16:13:27 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 14 Dec 2014 08:11:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="498545877"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 14 Dec 2014 08:09:21 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:41 -0500
Message-Id: <1418558981-13531-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 05/12] vTPM/TPM2: TPM 2.0 takes ownership and
	create SRK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TPM2_CreatePrimary is used to create a Primary Object under one of
the Primary Seeds or a Temporary Object under TPM_RH_NULL. The command
uses a TPM2B_PUBLIC as a template for the object to be created. The
command will create and load a Primary Object. The sensitive area is
not returned. Any type of object and attributes combination that is
allowed by TPM2_Create() may be created by this command. The constraints
on templates and parameters are the same as TPM2_Create() except that a
Primary Storage Key and a Temporary Storage Key are not constrained to
use the algorithms of their parents.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/init.c    | 71 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.h |  3 ++
 2 files changed, 74 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index f3aa02f..c654071 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -51,6 +51,7 @@
 #include "vtpm_disk.h"
 #include "tpm.h"
 #include "marshal.h"
+#include "tpm2.h"
 
 struct Opts {
    enum {
@@ -509,3 +510,73 @@ void vtpmmgr_shutdown(void)
 
    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager stopped.\n");
 }
+
+/* TPM 2.0 */
+
+static void tpm2_AuthArea_ctor(const char *authValue, UINT32 authLen,
+                               TPM_AuthArea *auth)
+{
+    auth->sessionHandle = TPM_RS_PW;
+    auth->nonce.size = 0;
+    auth->sessionAttributes = 1;
+    auth->auth.size = authLen;
+    memcpy(auth->auth.buffer, authValue, authLen);
+    auth->size = 9 + authLen;
+}
+
+TPM_RC tpm2_take_ownership(void)
+{
+    TPM_RC status = TPM_SUCCESS;
+
+    tpm2_AuthArea_ctor(NULL, 0, &vtpm_globals.pw_auth);
+
+    /* create SRK */
+    TPM2_CreatePrimary_Params_in in = {
+        .inSensitive = {
+            .size = 4,
+            .sensitive = {
+                .userAuth.size = 0,
+                .userAuth.buffer = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\
+                                     0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+                .data.size = 0,
+            },
+        },
+        .inPublic = {
+            .size = 60,
+            .publicArea = {
+                .type = TPM2_ALG_RSA,
+                .nameAlg = TPM2_ALG_SHA256,
+#define SRK_OBJ_ATTR (fixedTPM | fixedParent  | userWithAuth | \
+                      sensitiveDataOrigin | restricted | decrypt)
+                .objectAttributes = SRK_OBJ_ATTR,
+                .authPolicy.size = 0,
+                .parameters.rsaDetail = {
+                    .symmetric = {
+                    .algorithm = TPM2_ALG_AES,
+                    .keyBits.aes = AES_KEY_SIZES_BITS,
+                    .mode.aes = TPM2_ALG_CFB,
+                    },
+                .scheme = { TPM2_ALG_NULL },
+                .keyBits = RSA_KEY_SIZES_BITS,
+                .exponent = 0,
+                },
+                .unique.rsa.size = 0,
+            },
+        },
+            .outsideInfo.size = 0,
+            .creationPCR.count = 0,
+    };
+
+    TPMTRYRETURN(TPM2_CreatePrimary(TPM_RH_OWNER,&in,
+                                    &vtpm_globals.srk_handle, NULL));
+    vtpmloginfo(VTPM_LOG_VTPM, "SRK handle: 0x%X\n", vtpm_globals.srk_handle);
+    {
+        const char data[20] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\
+                                0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+        tpm2_AuthArea_ctor(data, 20, &vtpm_globals.srk_auth_area);
+    }
+    /*end create SRK*/
+
+abort_egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 0d0c604..95519ba 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -93,4 +93,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
    return ctr_drbg_random(&vtpm_globals.ctr_drbg, bytes, num_bytes) == 0 ? 0 : TPM_FAIL;
 }
 
+/* TPM 2.0 */
+TPM_RC tpm2_take_ownership(void);
+
 #endif
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnH-0007XY-Fo; Sun, 14 Dec 2014 16:13:15 +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 1Y0BnF-0007XT-TP
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:14 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	53/EB-16982-917BD845; Sun, 14 Dec 2014 16:13:13 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418573591!13267064!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 11264 invoked from network); 14 Dec 2014 16:13:11 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-3.tower-31.messagelabs.com with SMTP;
	14 Dec 2014 16:13:11 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga102.jf.intel.com with ESMTP; 14 Dec 2014 08:11:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="498545825"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 14 Dec 2014 08:09:05 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:25 -0500
Message-Id: <1418558965-13342-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
MIME-Version: 1.0
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 00/12] Enable vTPM subsystem on TPM 2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series of patch enable the virtual Trusted Platform Module (vTPM)
subsystem for Xen on TPM 2.0.

Noted, functionality for a virtual guest operating system (a DomU) is still
TPM 1.2. The main modifcation is on vtpmmgr-stubdom. The challenge is that
TPM 2.0 is not backward compatibility with TPM 1.2.

------------------------------
DESIGN OVERVIEW
------------------------------
The architecture of vTPM subsystem on TPM 2.0 is described below:

+------------------+
|    Linux DomU    | ...
|       |  ^       |
|       v  |       |
|   xen-tpmfront   |
+------------------+
        |  ^
        v  |
+------------------+
| mini-os/tpmback  |
|       |  ^       |
|       v  |       |
|  vtpm-stubdom    | ...
|       |  ^       |
|       v  |       |
| mini-os/tpmfront |
+------------------+
        |  ^
        v  |
+------------------+
| mini-os/tpmback  |
|       |  ^       |
|       v  |       |
| vtpmmgr-stubdom  |
|       |  ^       |
|       v  |       |
| mini-os/tpm2_tis |
+------------------+
        |  ^
        v  |
+------------------+
| Hardware TPM 2.0 |
+------------------+
 * Linux DomU: The Linux based guest that wants to use a vTPM. There many be
               more than one of these.

 * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver
                    provides vTPM access to a para-virtualized Linux based DomU.

 * 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.  This domain regulates
               access to the physical TPM on the system and secures the
               persistent state of each vTPM.

 * mini-os/tpm2_tis: Mini-os TPM version 2.0 TPM Interface Specification (TIS)
                    driver. This driver used by vtpmmgr-stubdom to talk directly
                    to the hardware TPM 2.0. Communication is facilitated by mapping
                    hardware memory pages into vtpmmgr-stubdom.

 * Hardware TPM 2.0: The physical TPM 2.0 that is soldered onto the motherboard.

------------------------------
Key Hierarchy
------------------------------

    +------------------+
    |  vTPM's secrets  | ...
    +------------------+
            |  ^
            |  |(Bind / Unbind)
- - - - -  -v  |- - - - - - - - TPM 2.0
    +------------------+
    |        SK        +
    +------------------+
            |  ^
            v  |
    +------------------+
    |       SRK        |
    +------------------+
            |  ^
            v  |
    +------------------+
    | TPM 2.0 Storage  |
    |   Primary Seed   |
    +------------------+

------------------------------
INSTALLATION
------------------------------

Prerequisites:
--------------
You must have an x86 machine with a TPM on the motherboard.  The only extra
software requirement for compiling vTPM is cmake.  You must use libxl to manage
domains with vTPMs; 'xm' is deprecated and does not support vTPMs.

Compiling the Xen tree:
-----------------------

Compile and install the Xen tree as usual; be sure that the vTPM domains are
enabled when you run configure.

Compiling the LINUX dom0 kernel:
--------------------------------

Because the TPM manager uses direct access to the physical TPM, it may interfere
with access to the TPM by dom0.  The simplest solution for this is to prevent
dom0 from accessing the physical TPM by compiling the kernel without a driver or
blacklisting the module.

Compiling the LINUX domU kernel:
--------------------------------

The domU kernel used by domains with vtpms must include the xen-tpmfront.ko
driver. It can be built directly into the kernel or as a module; however, some
features such as IMA require the TPM to be built in to the kernel.

CONFIG_TCG_TPM=y
CONFIG_TCG_XEN=y

------------------------------
VTPM MANAGER SETUP
------------------------------

Manager disk image setup:
-------------------------

The vTPM Manager requires a disk image to store its encrypted data. The image
does not require a filesystem and can live anywhere on the host disk. The image
is not large; the Xen 4.5 vtpmmgr is limited to using the first 2MB of the image
but can support more than 20,000 vTPMs.

 dd if=/dev/zero of=/home/vtpm2/vmgr bs=16M count=1

Manager config file:
--------------------

The vTPM Manager domain (vtpmmgr-stubdom) must be started like any other Xen
virtual machine and requires a config file.  The manager requires a disk image
for storage and permission to access the hardware memory pages for the TPM. The
disk must be presented as "hda", and the TPM memory pages are passed using the
iomem configuration parameter. The TPM TIS uses 5 pages of IO memory (one per
locality) that start at physical address 0xfed40000. By default, the TPM manager
uses locality 0 (so only the page at 0xfed40 is needed).

Add:
..
     extra="--tpm2"
..
extra option to launch vtpm-stubdom domain on TPM 2.0, and ignore it on TPM 1.x.

for example:

    kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
    memory=128
    disk=["file:/home/vtpm2/vmgr,hda,w"]
    name="vtpmmgr"
    iomem=["fed40,5"]
    extra="--tpm2"

------------------------------
VTPM AND LINUX PVM SETUP
------------------------------
vTPM disk image setup:
----------------------

The vTPM requires a disk image to store its persistent data (RSA keys, NVRAM,
etc). The image does not require a filesystem. The image does not need to be
large; 2 Mb should be sufficient.

    dd if=/dev/zero of=/home/vtpm2/vtpm0 bs=2M count=1

vTPM config file:
-----------------

The vTPM domain requires a configuration file like any other domain. The vTPM
requires a disk image for storage and a TPM frontend driver to communicate with
the manager.  You are required to generate a uuid for this vtpm, which is
specified on the "vtpm=" line that describes its connection to the vTPM Manager.
for example:

    kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
    memory=8
    disk=["file:/home/vtpm2/vtpm0,hda,w"]
    name="vtpm0"
    vtpm=["backend=vtpmmgr,uuid=914fe389-e2c5-44e6-993f-2189637cf1de"]

If you wish to clear the vTPM data you can either recreate the disk image or
change the uuid.

Linux Guest config file:
------------------------
The Linux guest config file needs to be modified to include the Linux tpmfront
driver. Add the following line:

vtpm=["backend=vtpm0"]

Currently only Linux guests are supported (PV or HVM with PV drivers). My series
of patch for HVM virtual mahcine are still being reviewed and modifcated.

Using the vTPM in the guest:
----------------------------

If xen-tpmfront was compiled as a module, it must be loaded it in the guest.

# modprobe xen-tpmfront

After the Linux domain boots and the xen-tpmfront driver is loaded, you should
see the following on the vtpm console:

Info: VTPM attached to Frontend X/Y

You can quickly test the vTPM by using the sysfs interface:

# cat /sys/devices/vtpm-0/pubek
# cat /sys/devices/vtpm-0/pcrs
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

You should also see the command being sent to the vtpm console as well as the
vtpm saving its state. You should see the vtpm key being encrypted and stored on
the vtpmmgr console.

You may wish to write a script to start your vtpm and guest together and to
destroy the vtpm when the guest shuts down.

------------------------------
INTEGRATION WITH PV-GRUB
------------------------------

The vTPM currently starts up with all PCRs set to their default values (all
zeros for the lower 16).  This means that any decisions about the
trustworthiness of the created domain must be made based on the environment that
created the vTPM and the domU; for example, a system that only constructs images
using a trusted configuration and guest kernel be able to provide guarantees
about the guests and any measurements done that kernel (such as the IMA TCB
log).  Guests wishing to use a custom kernel in such a secure environment are
often started using the pv-grub bootloader as the kernel, which then can load
the untrusted kernel without needing to parse an untrusted filesystem and kernel
in dom0.  If the pv-grub stub domain succeeds in connecting to a vTPM, it will
extend the hash of the kernel that it boots into PCR #4, and will extend the
command line and initrd into PCR #5 before booting so that a domU booted in this
way can attest to its early boot state.

------------------------------
REFERENCES
------------------------------

Berlios TPM Emulator:
http://tpm-emulator.berlios.de/
Xen docs/misc/vtpm.txt
Xen docs/misc/vtpm-platforms.txt
Xen docs/misc/vtpmmgr.txt


Quan Xu (12):
  vTPM/TPM2: Add TPM 2.0 data structures and commands definition
  vTPM/TPM2: TPM 2.0 data structures marshal
  vTPM/TPM2: Add global data in vtpm_globals{}
  vTPM/TPM2: Add TPM 2.0 Exposed APIs
  vTPM/TPM2: TPM 2.0 takes ownership and create SRK
  vTPM/TPM2: Create and load SK on TPM 2.0
  vTPM/TPM2: TPM2.0 TIS initialization and self test.
  vTPM/TPM2: Add main entrance vtpmmgr2_init()
  vTPM/TPM2: Support '--tpm2' extra command line.
  vTPM/TPM2: Support TPM 2.0 bind and unbind data
  vTPM/TPM2: Bind group keys and sectors data on disk
  vTPM/TPM2: Unind group keys and sectors data on disk

 extras/mini-os/include/tpm_tis.h |   1 +
 extras/mini-os/tpm_tis.c         | 156 +++++++
 stubdom/vtpmmgr/Makefile         |   2 +-
 stubdom/vtpmmgr/disk_read.c      |  28 +-
 stubdom/vtpmmgr/disk_tpm.c       |  42 +-
 stubdom/vtpmmgr/disk_tpm.h       |   4 +
 stubdom/vtpmmgr/disk_write.c     |  29 +-
 stubdom/vtpmmgr/init.c           | 282 +++++++++++
 stubdom/vtpmmgr/tpm2.c           | 455 ++++++++++++++++++
 stubdom/vtpmmgr/tpm2.h           | 104 +++++
 stubdom/vtpmmgr/tpm2_marshal.h   | 673 +++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2_types.h     | 978 +++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.c        |  46 +-
 stubdom/vtpmmgr/vtpmmgr.h        |  28 ++
 14 files changed, 2802 insertions(+), 26 deletions(-)
 create mode 100644 stubdom/vtpmmgr/tpm2.c
 create mode 100644 stubdom/vtpmmgr/tpm2.h
 create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h
 create mode 100644 stubdom/vtpmmgr/tpm2_types.h

-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnT-0007a5-Ix; Sun, 14 Dec 2014 16:13:27 +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 1Y0BnR-0007Zi-Mb
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:25 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	BE/B1-22819-427BD845; Sun, 14 Dec 2014 16:13:24 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418573602!13228416!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19280 invoked from network); 14 Dec 2014 16:13:23 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-206.messagelabs.com with SMTP;
	14 Dec 2014 16:13:23 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 14 Dec 2014 08:13:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="428810486"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 14 Dec 2014 08:02:23 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:38 -0500
Message-Id: <1418558978-13492-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 04/12] vTPM/TPM2: Add TPM 2.0 Exposed APIs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 TPM 2.0 Exposed APIs for the Mini-os to access TPM 2.0
hardware.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/Makefile |   2 +-
 stubdom/vtpmmgr/tpm2.c   | 455 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2.h   | 104 +++++++++++
 3 files changed, 560 insertions(+), 1 deletion(-)
 create mode 100644 stubdom/vtpmmgr/tpm2.c
 create mode 100644 stubdom/vtpmmgr/tpm2.h

diff --git a/stubdom/vtpmmgr/Makefile b/stubdom/vtpmmgr/Makefile
index c5e17c5..6dae034 100644
--- a/stubdom/vtpmmgr/Makefile
+++ b/stubdom/vtpmmgr/Makefile
@@ -12,7 +12,7 @@
 XEN_ROOT=../..
 
 TARGET=vtpmmgr.a
-OBJS=vtpmmgr.o vtpm_cmd_handler.o init.o tpmrsa.o tpm.o log.o
+OBJS=vtpmmgr.o vtpm_cmd_handler.o init.o tpmrsa.o tpm.o tpm2.o log.o
 OBJS += vtpm_disk.o disk_tpm.o disk_io.o disk_crypto.o disk_read.o disk_write.o
 OBJS += mgmt_authority.o
 
diff --git a/stubdom/vtpmmgr/tpm2.c b/stubdom/vtpmmgr/tpm2.c
new file mode 100644
index 0000000..1903e27
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2.c
@@ -0,0 +1,455 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005/2006, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#include <stdio.h>
+#include <string.h>
+#include <malloc.h>
+#include <unistd.h>
+#include <errno.h>
+#include <polarssl/sha1.h>
+
+#include "tcg.h"
+#include "tpm.h"
+#include "tpm2.h"
+#include "log.h"
+#include "marshal.h"
+#include "tpm2_marshal.h"
+#include "tpmrsa.h"
+#include "vtpmmgr.h"
+
+#define TCPA_MAX_BUFFER_LENGTH 0x2000
+#define TPM_BEGIN(TAG, ORD) \
+    const TPM_TAG intag = TAG;\
+    TPM_TAG tag = intag;\
+    UINT32 paramSize;\
+    const TPM_COMMAND_CODE ordinal = ORD;\
+    TPM_RESULT status = TPM_SUCCESS;\
+    BYTE in_buf[TCPA_MAX_BUFFER_LENGTH];\
+    BYTE out_buf[TCPA_MAX_BUFFER_LENGTH];\
+    UINT32 out_len = sizeof(out_buf);\
+    BYTE* ptr = in_buf;\
+    /*Print a log message */\
+    vtpmloginfo(VTPM_LOG_TPM, "%s\n", __func__);\
+    /* Pack the header*/\
+    ptr = pack_TPM_TAG(ptr, tag);\
+    ptr += sizeof(UINT32);\
+    ptr = pack_TPM_COMMAND_CODE(ptr, ordinal)\
+
+#define TPM_AUTH_BEGIN() \
+    sha1_context sha1_ctx;\
+    BYTE* authbase = ptr - sizeof(TPM_COMMAND_CODE);\
+    TPM_DIGEST paramDigest;\
+    sha1_starts(&sha1_ctx)
+
+#define TPM_AUTH1_GEN(HMACkey, auth) do {\
+    sha1_finish(&sha1_ctx, paramDigest.digest);\
+    generateAuth(&paramDigest, HMACkey, auth);\
+    ptr = pack_TPM_AUTH_SESSION(ptr, auth);\
+} while(0)
+
+#define TPM_AUTH2_GEN(HMACkey, auth) do {\
+    generateAuth(&paramDigest, HMACkey, auth);\
+    ptr = pack_TPM_AUTH_SESSION(ptr, auth);\
+} while(0)
+
+#define TPM_TRANSMIT() do {\
+    /* Pack the command size */\
+    paramSize = ptr - in_buf;\
+    pack_UINT32(in_buf + sizeof(TPM_TAG), paramSize);\
+    if ((status = TPM_TransmitData(in_buf, paramSize, out_buf, &out_len)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH_VERIFY_BEGIN() do {\
+    UINT32 buf[2] = { cpu_to_be32(status), cpu_to_be32(ordinal) };\
+    sha1_starts(&sha1_ctx);\
+    sha1_update(&sha1_ctx, (unsigned char*)buf, sizeof(buf));\
+    authbase = ptr;\
+} while(0)
+
+#define TPM_AUTH1_VERIFY(HMACkey, auth) do {\
+    sha1_finish(&sha1_ctx, paramDigest.digest);\
+    ptr = unpack_TPM_AUTH_SESSION(ptr, auth);\
+    if ((status = verifyAuth(&paramDigest, HMACkey, auth)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH2_VERIFY(HMACkey, auth) do {\
+    ptr = unpack_TPM_AUTH_SESSION(ptr, auth);\
+    if ((status = verifyAuth(&paramDigest, HMACkey, auth)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_UNPACK_VERIFY() do { \
+    ptr = out_buf;\
+    ptr = unpack_TPM_RSP_HEADER(ptr, \
+          &(tag), &(paramSize), &(status));\
+    if ((status) != TPM_SUCCESS){ \
+        vtpmlogerror(VTPM_LOG_TPM, "Failed with return code %s\n", tpm_get_error_name(status));\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH_HASH() do {\
+    sha1_update(&sha1_ctx, authbase, ptr - authbase);\
+    authbase = ptr;\
+} while(0)
+
+#define TPM_AUTH_SKIP() do {\
+    authbase = ptr;\
+} while(0)
+
+TPM_RC TPM2_PCR_Read(TPML_PCR_SELECTION pcrSelectionIn,
+                     UINT32 *pcrUpdateCounter,
+                     TPML_PCR_SELECTION *pcrSelectionOut,
+                     TPML_DIGEST *pcrValues)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS,TPM_CC_PCR_Read);
+
+    /*pack in*/
+    ptr =  pack_TPML_PCR_SELECTION(ptr, &pcrSelectionIn);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    /*unpack out*/
+    ptr = unpack_UINT32(ptr, pcrUpdateCounter);
+    ptr = unpack_TPML_PCR_SELECTION(ptr, pcrSelectionOut);
+    ptr = unpack_TPML_DIGEST(ptr, pcrValues);
+
+    goto egress;
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_Load(TPMI_DH_OBJECT parentHandle,
+                 TPM2B_PRIVATE *inPrivate, /* in */
+                 TPM2B_PUBLIC *inPublic, /* in */
+                 TPM_HANDLE *objectHandle, /* out */
+                 TPM2B_NAME *name /* out */)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Load);
+
+    /* pack handle of parent for new object */
+    ptr =  pack_UINT32(ptr, parentHandle);
+
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+    ptr = pack_TPM2B_PRIVATE(ptr, inPrivate);
+    ptr = pack_TPM2B_PUBLIC(ptr, inPublic);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    if (objectHandle != NULL) {
+        ptr = unpack_TPM_HANDLE(ptr, objectHandle);
+    } else {
+        TPM_HANDLE tmp;
+        ptr = unpack_TPM_HANDLE(ptr, &tmp);
+    }
+
+    if (name != NULL)
+        ptr = unpack_TPM2B_NAME(ptr, name);
+    goto egress;
+
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_Create(TPMI_DH_OBJECT parentHandle,
+                   TPM2_Create_Params_in *in,
+                   TPM2_Create_Params_out *out)
+{
+    UINT32 param_size;
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Create);
+
+    /* pack handle of parent for new object */
+    ptr =  pack_UINT32(ptr, parentHandle);
+
+    /* pack Auth Area */
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+
+    /* pack inSensitive */
+    ptr = pack_TPM2B_SENSITIVE_CREATE(ptr, &in->inSensitive);
+
+    /* pack inPublic */
+    ptr = pack_TPM2B_PUBLIC(ptr, &in->inPublic);
+
+    /* pack outside Info */
+    ptr = pack_TPM2B_DATA(ptr, &in->outsideInfo);
+
+    /* pack createPCR */
+    ptr = pack_TPML_PCR_SELECTION(ptr, &in->creationPCR);
+
+    /* Send the command to the tpm */
+    TPM_TRANSMIT();
+
+    /* Unpack and validate the header */
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT32(ptr, &param_size);
+    if (out != NULL) {
+        ptr = unpack_TPM2B_PRIVATE(ptr, &vtpm_globals.tpm2_storage_key.Private);
+        ptr = unpack_TPM2B_PUBLIC(ptr, &vtpm_globals.tpm2_storage_key.Public);
+        ptr = unpack_TPM2B_CREATION_DATA(ptr, &out->creationData);
+        ptr = unpack_TPM2B_DIGEST(ptr, &out->creationHash);
+        ptr = unpack_TPMT_TK_CREATION(ptr, &out->creationTicket);
+    } else {
+           ptr += param_size;
+    }
+    goto egress;
+
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_CreatePrimary(TPMI_RH_HIERARCHY primaryHandle,
+                          TPM2_Create_Params_in *in,
+                          TPM_HANDLE *objHandle,
+                          TPM2_Create_Params_out *out)
+{
+    UINT32 param_size;
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_CreatePrimary);
+
+    /* pack primary handle */
+    ptr = pack_UINT32(ptr, primaryHandle);
+
+    /* pack Auth Area */
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+
+    /* pack inSenstive */
+    ptr = pack_TPM2B_SENSITIVE_CREATE(ptr, &in->inSensitive);
+
+    /* pack inPublic */
+    ptr = pack_TPM2B_PUBLIC(ptr, &in->inPublic);
+
+    /* pack outsideInfo */
+    ptr = pack_TPM2B_DATA(ptr, &in->outsideInfo);
+
+    /* pack creationPCR */
+    ptr = pack_TPML_PCR_SELECTION(ptr, &in->creationPCR);
+
+    /* Send the command to the tpm */
+    TPM_TRANSMIT();
+
+    /* Unpack and validate the header */
+    TPM_UNPACK_VERIFY();
+
+    if (objHandle != NULL)
+        ptr = unpack_TPM_HANDLE(ptr, objHandle);
+    else {
+        TPM_HANDLE handle;
+        ptr = unpack_TPM_HANDLE(ptr, &handle);
+    }
+    ptr = unpack_UINT32(ptr, &param_size);
+
+    if (out != NULL) {
+        ptr = unpack_TPM2B_PUBLIC(ptr, &out->outPublic);
+        ptr = unpack_TPM2B_CREATION_DATA(ptr, &out->creationData);
+        ptr = unpack_TPM2B_DIGEST(ptr, &out->creationHash);
+        ptr = unpack_TPMT_TK_CREATION(ptr, &out->creationTicket);
+    } else {
+        ptr += param_size;
+    }
+
+goto egress;
+
+abort_egress:
+egress:
+   return status;
+}
+
+TPM_RC TPM2_HierachyChangeAuth(TPMI_RH_HIERARCHY_AUTH authHandle, TPM2B_AUTH *newAuth)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_HierarchyChangeAuth);
+    ptr = pack_UINT32(ptr, authHandle);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+    ptr = pack_TPM2B_AUTH(ptr, newAuth);
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_RSA_ENCRYPT(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *message,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *outData)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_RSA_Encrypt);
+
+    ptr = pack_UINT32(ptr, keyHandle);
+    ptr = pack_TPM2B_PUBLIC_KEY_RSA(ptr, message);
+    ptr = pack_TPMT_RSA_DECRYPT(ptr, inScheme);
+    ptr = pack_TPM2B_DATA(ptr, label);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    if (outData != NULL)
+        unpack_TPM2B_PUBLIC_KEY_RSA(ptr, outData);
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_Bind(TPMI_DH_OBJECT keyHandle,
+                 void *buf,
+                 UINT32 len,
+                 void *out)
+{
+    TPM_RC status = TPM_SUCCESS;
+    TPM2B_PUBLIC_KEY_RSA message;
+    TPMT_RSA_DECRYPT inScheme;
+    TPM2B_DATA label;
+    TPM2B_PUBLIC_KEY_RSA outData;
+
+    message.size = len;
+    memcpy(message.buffer, buf, len);
+    inScheme.scheme = TPM2_ALG_NULL;
+    label.size = 0;
+    TPMTRYRETURN(TPM2_RSA_ENCRYPT(keyHandle, &message, &inScheme, &label, &outData));
+    memcpy(out, outData.buffer, outData.size);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_RSA_Decrypt(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *cipherText,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *message)
+{
+    UINT32 param_size;
+
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_RSA_Decrypt);
+    ptr = pack_UINT32(ptr, keyHandle);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+    ptr = pack_TPM2B_PUBLIC_KEY_RSA(ptr, cipherText);
+    ptr = pack_TPMT_RSA_DECRYPT(ptr, inScheme);
+    ptr = pack_TPM2B_DATA(ptr, label);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT32(ptr, &param_size);
+
+    if (message)
+        ptr = unpack_TPM2B_PUBLIC_KEY_RSA(ptr, message);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_UnBind(TPMI_DH_OBJECT keyHandle,
+                   UINT32 ilen,
+                   void *in,
+                   UINT32 *olen,
+                   void *out)
+{
+    UINT32 status;
+    TPM2B_PUBLIC_KEY_RSA cipher, message;
+    TPMT_RSA_DECRYPT inScheme;
+    TPM2B_DATA label;
+
+    cipher.size = ilen;
+    memcpy(cipher.buffer, in, ilen);
+    inScheme.scheme = TPM2_ALG_NULL;
+    label.size = 0;
+
+    TPMTRYRETURN(TPM2_RSA_Decrypt(keyHandle, &cipher, &inScheme, &label, &message));
+
+    *olen = message.size;
+    memcpy(out, message.buffer, *olen);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_CLEAR(void)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Clear);
+
+    ptr = pack_UINT32(ptr, TPM_RH_PLATFORM);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_GetRandom(UINT32 * bytesRequested, BYTE * randomBytes)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_GetRandom);
+
+    ptr = pack_UINT16(ptr, (UINT16)*bytesRequested);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT16(ptr, (UINT16 *)bytesRequested);
+    ptr = unpack_TPM_BUFFER(ptr, randomBytes, *bytesRequested);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_FlushContext(TPMI_DH_CONTEXT flushHandle)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_FlushContext);
+
+    ptr = pack_UINT32(ptr, flushHandle);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/tpm2.h b/stubdom/vtpmmgr/tpm2.h
new file mode 100644
index 0000000..9f597ee
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2.h
@@ -0,0 +1,104 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005/2006, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef __TPM2_H__
+#define __TPM2_H__
+
+#include "tcg.h"
+#include "tpm2_types.h"
+
+// ------------------------------------------------------------------
+// TPM 2.0 Exposed API
+// ------------------------------------------------------------------
+
+TPM_RC TPM2_PCR_Read(TPML_PCR_SELECTION pcrSelectionIn,
+                     UINT32 *pcrUpdateCounter,
+                     TPML_PCR_SELECTION *pcrSelectionOut,
+                     TPML_DIGEST *pcrValues);
+
+TPM_RC TPM2_Load(TPMI_DH_OBJECT parentHandle,
+                 TPM2B_PRIVATE *inPrivate,
+                 TPM2B_PUBLIC *inPublic,
+                 TPM_HANDLE *objectHandle,
+                 TPM2B_NAME *name);
+
+TPM_RC TPM2_Create(TPMI_DH_OBJECT parentHandle,
+                   TPM2_Create_Params_in *in,
+                   TPM2_Create_Params_out *out);
+
+TPM_RC TPM2_CreatePrimary(TPMI_RH_HIERARCHY primaryHandle,
+                          TPM2_Create_Params_in *objHandle,
+                          TPM_HANDLE *in,
+                          TPM2_Create_Params_out *out);
+
+TPM_RC TPM2_HierachyChangeAuth(TPMI_RH_HIERARCHY_AUTH authHandle,
+                               TPM2B_AUTH *newAuth);
+
+TPM_RC TPM2_RSA_ENCRYPT(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *message,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *outData);
+
+TPM_RC TPM2_Bind(TPMI_DH_OBJECT keyHandle,
+                 void *buf,
+                 UINT32 len,
+                 void *out);
+
+TPM_RC TPM2_RSA_Decrypt(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *cipherText,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *message);
+
+TPM_RC TPM2_UnBind(TPMI_DH_OBJECT keyHandle,
+                   UINT32 ilen,
+                   void *in,
+                   UINT32 *olen,
+                   void *out);
+
+TPM_RESULT TPM2_GetRandom(UINT32* bytesRequested,
+                          BYTE* randomBytes);
+
+TPM_RC TPM2_CLEAR(void);
+
+TPM_RC TPM2_FlushContext(TPMI_DH_CONTEXT);
+#endif //TPM2_H
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Bnd-0007fl-Vf; Sun, 14 Dec 2014 16:13:37 +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 1Y0Bnc-0007ed-7L
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:36 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	9C/A5-02953-F27BD845; Sun, 14 Dec 2014 16:13:35 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418573611!14939834!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 30878 invoked from network); 14 Dec 2014 16:13:32 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-27.messagelabs.com with SMTP;
	14 Dec 2014 16:13:32 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2014 08:13:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="637398621"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 14 Dec 2014 08:13:30 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:47 -0500
Message-Id: <1418558987-13605-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 07/12] vTPM/TPM2: TPM2.0 TIS initialization and
	self test.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

call the TPM 2.0 various registers that allow communication between
the TPM 2.0 and platform hardware and software. TPM2_SelfTest causes
the TPM 2.0 to perform a test of its capabilities.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 extras/mini-os/include/tpm_tis.h |   1 +
 extras/mini-os/tpm_tis.c         | 156 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 157 insertions(+)

diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h
index 1faca0d..86e83f1 100644
--- a/extras/mini-os/include/tpm_tis.h
+++ b/extras/mini-os/include/tpm_tis.h
@@ -36,6 +36,7 @@
 struct tpm_chip;
 
 struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq);
+struct tpm_chip* init_tpm2_tis(unsigned long baseaddr, int localities, unsigned int irq);
 void shutdown_tpm_tis(struct tpm_chip* tpm);
 
 int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
index d78c465..debcc43 100644
--- a/extras/mini-os/tpm_tis.c
+++ b/extras/mini-os/tpm_tis.c
@@ -1363,5 +1363,161 @@ int tpm_tis_posix_fstat(int fd, struct stat* buf)
    return 0;
 }
 
+/* TPM 2.0 */
 
+/*TPM2.0 Selftest*/
+static void tpm2_selftest(struct tpm_chip* chip)
+{
+    uint8_t data[] = {
+        0x80, 0x1,
+        0x0, 0x0, 0x0, 0xb,
+        0x0, 0x0, 0x1, 0x43,
+        0x1,
+    };
+
+    tpm_transmit(chip, data, sizeof(data));
+}
+
+struct tpm_chip* init_tpm2_tis(unsigned long baseaddr, int localities, unsigned int irq)
+{
+    int i;
+    unsigned long addr;
+    struct tpm_chip* tpm = NULL;
+    uint32_t didvid;
+    uint32_t intfcaps;
+    uint32_t intmask;
+
+    printk("============= Init TPM2 TIS Driver ==============\n");
+
+    /*Sanity check the localities input */
+    if (localities & ~TPM_TIS_EN_LOCLALL) {
+        printk("init_tpm2_tis Invalid locality specification! %X\n", localities);
+        goto abort_egress;
+    }
+
+    printk("IOMEM Machine Base Address: %lX\n", baseaddr);
+
+    /* Create the tpm data structure */
+    tpm = malloc(sizeof(struct tpm_chip));
+    __init_tpm_chip(tpm);
+
+    /* Set the enabled localities - if 0 we leave default as all enabled */
+    if (localities != 0) {
+        tpm->enabled_localities = localities;
+    }
+    printk("Enabled Localities: ");
+    for (i = 0; i < 5; ++i) {
+        if (locality_enabled(tpm, i)) {
+            printk("%d ", i);
+        }
+    }
+    printk("\n");
+
+    /* Set the base machine address */
+    tpm->baseaddr = baseaddr;
+
+    /* Set default timeouts */
+    tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT);
+    tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT);
+    tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT);
+    tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT);
+
+    /*Map the mmio pages */
+    addr = tpm->baseaddr;
+    for (i = 0; i < 5; ++i) {
+        if (locality_enabled(tpm, i)) {
+
+            /* Map the page in now */
+            if ((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) {
+                printk("Unable to map iomem page a address %p\n", addr);
+                goto abort_egress;
+            }
+
+            /* Set default locality to the first enabled one */
+            if (tpm->locality < 0) {
+                if (tpm_tis_request_locality(tpm, i) < 0) {
+                    printk("Unable to request locality %d??\n", i);
+                    goto abort_egress;
+                }
+            }
+        }
+        addr += PAGE_SIZE;
+    }
+
+    /* Get the vendor and device ids */
+    didvid = ioread32(TPM_DID_VID(tpm, tpm->locality));
+    tpm->did = didvid >> 16;
+    tpm->vid = didvid & 0xFFFF;
+
+    /* Get the revision id */
+    tpm->rid = ioread8(TPM_RID(tpm, tpm->locality));
+    printk("2.0 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n",
+           tpm->did, tpm->vid, tpm->rid);
+
+    intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
+    printk("TPM interface capabilities (0x%x):\n", intfcaps);
+    if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
+        printk("\tBurst Count Static\n");
+    if (intfcaps & TPM_INTF_CMD_READY_INT)
+        printk("\tCommand Ready Int Support\n");
+    if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
+        printk("\tInterrupt Edge Falling\n");
+    if (intfcaps & TPM_INTF_INT_EDGE_RISING)
+        printk("\tInterrupt Edge Rising\n");
+    if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
+        printk("\tInterrupt Level Low\n");
+    if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
+        printk("\tInterrupt Level High\n");
+    if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
+        printk("\tLocality Change Int Support\n");
+    if (intfcaps & TPM_INTF_STS_VALID_INT)
+        printk("\tSts Valid Int Support\n");
+    if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
+        printk("\tData Avail Int Support\n");
+
+    /*Interupt setup */
+    intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
+
+    intmask |= TPM_INTF_CMD_READY_INT | TPM_INTF_LOCALITY_CHANGE_INT |
+               TPM_INTF_DATA_AVAIL_INT | TPM_INTF_STS_VALID_INT;
+
+    iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
+
+    /*If interupts are enabled, handle it */
+    if (irq) {
+        if (irq != TPM_PROBE_IRQ) {
+            tpm->irq = irq;
+        } else {
+        /*FIXME add irq probing feature later */
+        printk("IRQ probing not implemented\n");
+        }
+    }
+
+    if (tpm->irq) {
+        iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
+        if (bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) {
+            printk("Unabled to request irq: %u for use\n", tpm->irq);
+            printk("Will use polling mode\n");
+            tpm->irq = 0;
+        } else {
+
+            /* Clear all existing */
+            iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
+                                     ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
+
+            /* Turn on interrupts */
+            iowrite32(TPM_INT_ENABLE(tpm, tpm->locality),
+                                     intmask | TPM_GLOBAL_INT_ENABLE);
+        }
+    }
+
+    tpm2_selftest(tpm);
+    return tpm;
+
+abort_egress:
+    if (tpm != NULL) {
+        shutdown_tpm_tis(tpm);
+    }
+    return NULL;
+}
 #endif
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnY-0007ch-Hw; Sun, 14 Dec 2014 16:13:32 +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 1Y0BnX-0007bx-3n
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:31 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	B0/2B-19763-A27BD845; Sun, 14 Dec 2014 16:13:30 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418573602!13228416!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19427 invoked from network); 14 Dec 2014 16:13:29 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-206.messagelabs.com with SMTP;
	14 Dec 2014 16:13:29 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 14 Dec 2014 08:13:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="647434646"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 14 Dec 2014 08:13:27 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:45 -0500
Message-Id: <1418558985-13568-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
MIME-Version: 1.0
Content-Length: 6274
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 06/12] vTPM/TPM2: Create and load SK on TPM 2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VFBNMl9DcmVhdGUgaXMgdXNlZCB0byBjcmVhdGUgYW4gb2JqZWN0IHRoYXQgY2FuIGJlIGxvYWRl
ZCBpbnRvIGEKVFBNIHVzaW5nIFRQTTJfTG9hZCgpLiBJZiB0aGUgY29tbWFuZCBjb21wbGV0ZXMg
c3VjY2Vzc2Z1bGx5LCB0aGUKVFBNIHdpbGwgY3JlYXRlIHRoZSBuZXcgb2JqZWN0IGFuZCByZXR1
cm4gdGhlIG9iamVjdOKAmXMgY3JlYXRpb24uCmRhdGEgKGNyZWF0aW9uRGF0YSksIGl0cyBwdWJs
aWMgYXJlYSAob3V0UHVibGljKSwgYW5kIGl0cyBlbmNyeXB0ZWQKc2Vuc2l0aXZlIGFyZWEgKG91
dFByaXZhdGUpLiBQcmVzZXJ2YXRpb24gb2YgdGhlIHJldHVybmVkIGRhdGEgaXMKdGhlIHJlc3Bv
bnNpYmlsaXR5IG9mIHRoZSBjYWxsZXIuIFRoZSBvYmplY3Qgd2lsbCBuZWVkIHRvIGJlIGxvYWRl
ZAooVFBNMl9Mb2FkKCkpLgpUUE0yX0xvYWQgaXMgdXNlZCB0byBsb2FkIG9iamVjdHMgaW50byB0
aGUgVFBNLiBUaGlzIGNvbW1hbmQgaXMgdXNlZAp3aGVuIGJvdGggYSBUUE0yQl9QVUJMSUMgYW5k
IFRQTTJCX1BSSVZBVEUgYXJlIHRvIGJlIGxvYWRlZC4gSWYgb25seQphIFRQTTJCX1BVQkxJQyBp
cyB0byBiZSBsb2FkZWQsIHRoZSBUUE0yX0xvYWRFeHRlcm5hbCBjb21tYW5kIGlzIHVzZWQuCgpT
aWduZWQtb2ZmLWJ5OiBRdWFuIFh1IDxxdWFuLnh1QGludGVsLmNvbT4KLS0tCiBzdHViZG9tL3Z0
cG1tZ3IvaW5pdC5jICAgIHwgMTAxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysKIHN0dWJkb20vdnRwbW1nci92dHBtbWdyLmggfCAgIDEgKwogMiBmaWxlcyBj
aGFuZ2VkLCAxMDIgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3N0dWJkb20vdnRwbW1nci9p
bml0LmMgYi9zdHViZG9tL3Z0cG1tZ3IvaW5pdC5jCmluZGV4IGM2NTQwNzEuLjgyNDRiYjAgMTAw
NjQ0Ci0tLSBhL3N0dWJkb20vdnRwbW1nci9pbml0LmMKKysrIGIvc3R1YmRvbS92dHBtbWdyL2lu
aXQuYwpAQCAtNTgwLDMgKzU4MCwxMDQgQEAgVFBNX1JDIHRwbTJfdGFrZV9vd25lcnNoaXAodm9p
ZCkKIGFib3J0X2VncmVzczoKICAgICByZXR1cm4gc3RhdHVzOwogfQorCitUUE1fUkVTVUxUIHZ0
cG1tZ3IyX2NyZWF0ZSh2b2lkKQoreworICAgIFRQTV9SRVNVTFQgc3RhdHVzID0gVFBNX1NVQ0NF
U1M7CisKKyAgICBUUE1UUllSRVRVUk4odHBtMl90YWtlX293bmVyc2hpcCgpKTsKKworICAgLyog
Y3JlYXRlIFNLICovCisgICAgVFBNMl9DcmVhdGVfUGFyYW1zX291dCBvdXQ7CisgICAgVFBNMl9D
cmVhdGVfUGFyYW1zX2luIGluID0geworICAgICAgICAuaW5TZW5zaXRpdmUgPSB7CisgICAgICAg
ICAgICAuc2l6ZSA9IDQgKyAyMCwKKyAgICAgICAgICAgIC5zZW5zaXRpdmUgPSB7CisgICAgICAg
ICAgICAgICAgLnVzZXJBdXRoLnNpemUgPSAyMCwKKyAgICAgICAgICAgICAgICAudXNlckF1dGgu
YnVmZmVyID0geyAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLFwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwIH0sCisg
ICAgICAgICAgICAgICAgLmRhdGEuc2l6ZSA9IDAsCisgICAgICAgICAgICB9LAorICAgICAgICB9
LAorICAgICAgICAuaW5QdWJsaWMgPSB7CisgICAgICAgICAgICAuc2l6ZSA9ICg2MCksCisgICAg
ICAgICAgICAucHVibGljQXJlYSA9IHsKKyAgICAgICAgICAgICAgICAgLnR5cGUgPSBUUE0yX0FM
R19SU0EsCisgICAgICAgICAgICAgICAgIC5uYW1lQWxnID0gVFBNMl9BTEdfU0hBMjU2LAorI2Rl
ZmluZSBTS19PQkpfQVRUUiAoZml4ZWRUUE0gfCBmaXhlZFBhcmVudCB8IHVzZXJXaXRoQXV0aCB8
XAorICAgICAgICAgICAgICAgICAgICAgc2Vuc2l0aXZlRGF0YU9yaWdpbiB8ZGVjcnlwdCkKKyAg
ICAgICAgICAgICAgICAgLm9iamVjdEF0dHJpYnV0ZXMgPSBTS19PQkpfQVRUUiwKKyAgICAgICAg
ICAgICAgICAgLmF1dGhQb2xpY3kuc2l6ZSA9IDAsCisgICAgICAgICAgICAgICAgIC5wYXJhbWV0
ZXJzLnJzYURldGFpbCA9IHsKKyAgICAgICAgICAgICAgICAgICAgIC5zeW1tZXRyaWMgPSB7Cisg
ICAgICAgICAgICAgICAgICAgICAgICAgLmFsZ29yaXRobSA9IFRQTTJfQUxHX05VTEwsCisgICAg
ICAgICAgICAgICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgICAgLnNjaGVtZSA9IHsKKyAg
ICAgICAgICAgICAgICAgICAgICAgICBUUE0yX0FMR19PQUVQLAorICAgICAgICAgICAgICAgICAg
ICAgICAgIC5kZXRhaWxzLm9hZXAuaGFzaEFsZyA9IFRQTTJfQUxHX1NIQTI1NiwKKyAgICAgICAg
ICAgICAgICAgICAgIH0sCisgICAgICAgICAgICAgICAgICAgICAua2V5Qml0cyA9IFJTQV9LRVlf
U0laRVNfQklUUywKKyAgICAgICAgICAgICAgICAgICAgIC5leHBvbmVudCA9IDAsCisgICAgICAg
ICAgICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgLnVuaXF1ZS5yc2Euc2l6ZSA9IDAsCisg
ICAgICAgICAgICB9LAorICAgICAgICB9LAorICAgICAgICAub3V0c2lkZUluZm8uc2l6ZSA9IDAs
CisgICAgICAgIC5jcmVhdGlvblBDUi5jb3VudCA9IDAsCisgICAgfTsvKmVuZCBpbiAqLworCisg
ICAgVFBNVFJZUkVUVVJOKFRQTTJfQ3JlYXRlKHZ0cG1fZ2xvYmFscy5zcmtfaGFuZGxlLCAmaW4s
ICZvdXQpKTsKKyAgICBUUE1UUllSRVRVUk4oVFBNMl9Mb2FkKHZ0cG1fZ2xvYmFscy5zcmtfaGFu
ZGxlLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZ0cG1fZ2xvYmFscy50cG0yX3N0b3Jh
Z2Vfa2V5LlByaXZhdGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAmdnRwbV9nbG9iYWxz
LnRwbTJfc3RvcmFnZV9rZXkuUHVibGljLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZ0
cG1fZ2xvYmFscy5za19oYW5kbGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAmdnRwbV9n
bG9iYWxzLnNrX25hbWUpKTsKKworICAgIHZ0cG1sb2dpbmZvKFZUUE1fTE9HX1ZUUE0sICJTSyBI
QU5ETEU6IDB4JVhcbiIsIHZ0cG1fZ2xvYmFscy5za19oYW5kbGUpOworICAgIC8qZW5kIGNyZWF0
ZSBTSyovCisKKyNpZiAwIC8qQmluZCAmIHVuQmluZCovCit7CisgICAgdW5zaWduZWQgY2hhciBy
YW5kWzIwXTsKKyAgICB1bnNpZ25lZCBjaGFyIGNpcGhlclsyNTZdLCBvdXRbMjU2XTsKKyAgICB2
dHBtbWdyX3JhbmQocmFuZCwgMjApOworICAgIGludCBpOworICAgIFVJTlQzMiBvbGVuOworCisg
ICAgcHJpbnRrKCJyYW5kOiAiKTsKKyAgICBmb3IgKGkgPSAwOyBpIDwgMjA7IGkrKykgeworICAg
ICAgICAgcHJpbnRrKCIgJXUgIiwgcmFuZFtpXSk7CisgICAgfQorICAgIHByaW50aygiXG4iKTsK
KyAgICBUUE1UUllSRVRVUk4oVFBNMl9CaW5kKHZ0cG1fZ2xvYmFscy5za19oYW5kbGUsCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICByYW5kLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg
MjAsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBjaXBoZXIpKTsKKyAgICBwcmludGsoImNp
cGhlciA6ICIpOworICAgIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykgeworICAgICAgICAgcHJp
bnRrKCIlMDJ4IiwgY2lwaGVyW2ldKTsKKyAgICB9CisgICAgcHJpbnRrKCJcbiIpOworICAgIFRQ
TVRSWVJFVFVSTihUUE0yX1VuQmluZCh2dHBtX2dsb2JhbHMuc2tfaGFuZGxlLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAyNTYsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNp
cGhlciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJm9sZW4sCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG91dCkpOworICAgIHByaW50aygib2xlbiA6ICVkIFxuIiwgb2xlbik7
CisgICAgcHJpbnRrKCJvdXQgOiAiKTsKKyAgICBmb3IgKGkgPSAwOyBpIDwgb2xlbjsgaSsrKQor
ICAgICAgICAgcHJpbnRrKCIgJXUgIiwgb3V0W2ldKTsKKyAgICBwcmludGsoIlxuIik7Cit9Cisj
ZW5kaWYKKworICAgIC8qQ3JlYXRlIG5ldyBkaXNrIGltYWdlKi8KKyAgICBUUE1UUllSRVRVUk4o
dnRwbV9uZXdfZGlzaygpKTsKKworICAgIGdvdG8gZWdyZXNzOworCithYm9ydF9lZ3Jlc3M6Citl
Z3Jlc3M6CisgICAgdnRwbWxvZ2luZm8oVlRQTV9MT0dfVlRQTSwgIkZpbmlzaGVkIGluaXRpYWxp
emVkIG5ldyBWVFBNIG1hbmFnZXJcbiIpOworICAgIHJldHVybiBzdGF0dXM7Cit9CmRpZmYgLS1n
aXQgYS9zdHViZG9tL3Z0cG1tZ3IvdnRwbW1nci5oIGIvc3R1YmRvbS92dHBtbWdyL3Z0cG1tZ3Iu
aAppbmRleCA5NTUxOWJhLi45ODg5ZmViIDEwMDY0NAotLS0gYS9zdHViZG9tL3Z0cG1tZ3IvdnRw
bW1nci5oCisrKyBiL3N0dWJkb20vdnRwbW1nci92dHBtbWdyLmgKQEAgLTk1LDUgKzk1LDYgQEAg
aW5saW5lIFRQTV9SRVNVTFQgdnRwbW1ncl9yYW5kKHVuc2lnbmVkIGNoYXIqIGJ5dGVzLCBzaXpl
X3QgbnVtX2J5dGVzKSB7CiAKIC8qIFRQTSAyLjAgKi8KIFRQTV9SQyB0cG0yX3Rha2Vfb3duZXJz
aGlwKHZvaWQpOworVFBNX1JFU1VMVCB2dHBtbWdyMl9jcmVhdGUodm9pZCk7CiAKICNlbmRpZgot
LSAKMS44LjMuMgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sun Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnP-0007Z1-Pv; Sun, 14 Dec 2014 16:13:23 +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 1Y0BnM-0007Y3-8x
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	55/BB-25276-F17BD845; Sun, 14 Dec 2014 16:13:19 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418573596!15463841!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 18062 invoked from network); 14 Dec 2014 16:13:17 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-21.messagelabs.com with SMTP;
	14 Dec 2014 16:13:17 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2014 08:13:15 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="637398582"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 14 Dec 2014 08:13:14 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:32 -0500
Message-Id: <1418558972-13418-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 02/12] vTPM/TPM2: TPM 2.0 data structures marshal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 TPM 2.0 data structure marshal for packing and unpacking TPM
2.0 data structures.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/tpm2_marshal.h | 673 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 673 insertions(+)
 create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h

diff --git a/stubdom/vtpmmgr/tpm2_marshal.h b/stubdom/vtpmmgr/tpm2_marshal.h
new file mode 100644
index 0000000..aaa4464
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2_marshal.h
@@ -0,0 +1,673 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef TPM2_MARSHAL_H
+#define TPM2_MARSHAL_H
+
+#include <stdlib.h>
+#include <mini-os/byteorder.h>
+#include <mini-os/endian.h>
+#include "tcg.h"
+#include "tpm2_types.h"
+#include <assert.h>
+
+#define pack_TPM_BUFFER(ptr, buf, size) pack_BUFFER(ptr, buf, size)
+#define unpack_TPM_BUFFER(ptr, buf, size) unpack_BUFFER(ptr, buf, size)
+
+inline BYTE* pack_BYTE_ARRAY(BYTE* ptr, const BYTE* array, UINT32 size)
+{
+    int i;
+    for (i = 0; i < size; i++)
+         ptr = pack_BYTE(ptr, array[i]);
+    return ptr;
+}
+
+inline BYTE* pack_TPMA_SESSION(BYTE* ptr, const TPMA_SESSION *attr)
+{
+    return pack_BYTE(ptr, (BYTE)(*attr));
+}
+
+inline BYTE* unpack_TPMA_SESSION(BYTE* ptr, TPMA_SESSION *attr)
+{
+    return unpack_BYTE(ptr, (BYTE *)attr);
+}
+
+inline BYTE* pack_TPMI_ALG_HASH(BYTE* ptr, const TPMI_ALG_HASH *hash)
+{
+    return pack_UINT16(ptr, *hash);
+}
+
+inline BYTE* unpack_TPMI_ALG_HASH(BYTE *ptr, TPMI_ALG_HASH *hash)
+{
+    return unpack_UINT16(ptr, hash);
+}
+
+#define pack_TPMA_OBJECT(ptr, t)                pack_UINT32(ptr, (UINT32)(*t))
+#define unpack_TPMA_OBJECT(ptr, t)              unpack_UINT32(ptr, (UINT32 *)(t))
+#define pack_TPM_RH(ptr, t)                     pack_UINT32(ptr, (UINT32)(*t))
+#define unpack_TPM_RH(ptr, t)                   unpack_UINT32(ptr, (UINT32 *)(t))
+#define pack_TPMA_LOCALITY(ptr, locality)       pack_BYTE(ptr, (BYTE)*locality)
+#define unpack_TPMA_LOCALITY(ptr, locality)     unpack_BYTE(ptr, (BYTE *)locality)
+#define pack_TPM_ST(ptr, tag)                   pack_UINT16(ptr, *tag)
+#define unpack_TPM_ST(ptr, tag)                 unpack_UINT16(ptr, tag)
+#define pack_TPM_KEY_BITS(ptr, t)               pack_UINT16(ptr, *t)
+#define unpack_TPM_KEY_BITS(ptr, t)             unpack_UINT16(ptr, t)
+#define pack_TPMI_AES_KEY_BITS(ptr, t)          pack_TPM_KEY_BITS(ptr, t)
+#define unpack_TPMI_AES_KEY_BITS(ptr, t)        unpack_TPM_KEY_BITS(ptr, t)
+#define pack_TPMI_RSA_KEY_BITS(ptr, t)          pack_TPM_KEY_BITS(ptr, t)
+#define unpack_TPMI_RSA_KEY_BITS(ptr, t)        unpack_TPM_KEY_BITS(ptr, t)
+#define pack_TPM_ALG_ID(ptr, id)                pack_UINT16(ptr, *id)
+#define unpack_TPM_ALG_ID(ptr, id)              unpack_UINT16(ptr, id)
+#define pack_TPM_ALG_SYM(ptr, t)                pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPM_ALG_SYM(ptr, t)              unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_ASYM(ptr, asym)           pack_TPM_ALG_ID(ptr, asym)
+#define unpack_TPMI_ALG_ASYM(ptr, asym)         unpack_TPM_ALG_ID(ptr, asym)
+#define pack_TPMI_ALG_SYM_OBJECT(ptr, t)        pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_SYM_OBJECT(ptr, t)      unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_SYM_MODE(ptr, t)          pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_SYM_MODE(ptr, t)        unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_KDF(ptr, t)               pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_KDF(ptr, t)             unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_PUBLIC(ptr, t)            pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_PUBLIC(ptr, t)          unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPM2_HANDLE(ptr, h)                pack_UINT32(ptr, *h)
+#define unpack_TPM2_HANDLE(ptr, h)              unpack_UINT32(ptr, h)
+#define pack_TPMI_ALG_RSA_SCHEME(ptr, t)        pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_RSA_SCHEME(ptr, t)      unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_DH_OBJECT(ptr, o)             pack_TPM2_HANDLE(ptr, o)
+#define unpack_TPMI_DH_OBJECT(PTR, O)           unpack_TPM2_HANDLE(ptr, o)
+#define pack_TPMI_RH_HIERACHY(ptr, h)           pack_TPM2_HANDLE(ptr, h)
+#define unpack_TPMI_RH_HIERACHY(ptr, h)         unpack_TPM2_HANDLE(ptr, h)
+#define pack_TPMI_RH_PLATFORM(ptr, p)           pack_TPM2_HANDLE(ptr, p)
+#define unpack_TPMI_RH_PLATFORM(ptr, p)         unpack_TPM2_HANDLE(ptr, p)
+#define pack_TPMI_RH_OWNER(ptr, o)              pack_TPM2_HANDLE(ptr, o)
+#define unpack_TPMI_RH_OWNER(ptr, o)            unpack_TPM2_HANDLE(ptr, o)
+#define pack_TPMI_RH_ENDORSEMENT(ptr, e)        pack_TPM2_HANDLE(ptr, e)
+#define unpack_TPMI_RH_ENDORSEMENT(ptr, e)      unpack_TPM2_HANDLE(ptr, e)
+#define pack_TPMI_RH_LOCKOUT(ptr, l)            pack_TPM2_HANDLE(ptr, l)
+#define unpack_TPMI_RH_LOCKOUT(ptr, l)          unpack_TPM2_HANDLE(ptr, l)
+
+inline BYTE* pack_TPM2B_DIGEST(BYTE* ptr, const TPM2B_DIGEST *digest)
+{
+    ptr = pack_UINT16(ptr, digest->size);
+    ptr = pack_BUFFER(ptr, digest->buffer, digest->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_DIGEST(BYTE* ptr, TPM2B_DIGEST *digest)
+{
+    ptr = unpack_UINT16(ptr, &digest->size);
+    ptr = unpack_BUFFER(ptr, digest->buffer, digest->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_TK_CREATION(BYTE* ptr,const TPMT_TK_CREATION *ticket )
+{
+    ptr = pack_TPM_ST(ptr , &ticket->tag);
+    ptr = pack_TPMI_RH_HIERACHY(ptr , &ticket->hierarchy);
+    ptr = pack_TPM2B_DIGEST(ptr, &ticket->digest);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_TK_CREATION(BYTE* ptr, TPMT_TK_CREATION *ticket )
+{
+    ptr = unpack_TPM_ST(ptr, &ticket->tag);
+    ptr = unpack_TPMI_RH_HIERACHY(ptr, &ticket->hierarchy);
+    ptr = unpack_TPM2B_DIGEST(ptr, &ticket->digest);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_NAME(BYTE* ptr,const TPM2B_NAME *name )
+{
+    ptr = pack_UINT16(ptr, name->size);
+    ptr = pack_TPM_BUFFER(ptr, name->name, name->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_NAME(BYTE* ptr, TPM2B_NAME *name)
+{
+    ptr = unpack_UINT16(ptr, &name->size);
+    ptr = unpack_TPM_BUFFER(ptr, name->name, name->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_NONCE(BYTE* ptr, const TPM2B_NONCE *nonce)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)nonce);
+}
+
+#define unpack_TPM2B_NONCE(ptr, nonce)  unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)nonce)
+
+inline BYTE* pack_TPM2B_AUTH(BYTE* ptr, const TPM2B_AUTH *auth)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)auth);
+}
+
+#define unpack_TPM2B_AUTH(ptr, auth)    unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)auth)
+
+inline BYTE* pack_TPM2B_DATA(BYTE* ptr, const TPM2B_DATA *data)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)data);
+}
+
+#define unpack_TPM2B_DATA(ptr, data)    unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)data)
+
+inline BYTE* pack_TPM2B_SENSITIVE_DATA(BYTE* ptr, const TPM2B_SENSITIVE_DATA *data)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)data);
+}
+
+#define unpack_TPM2B_SENSITIVE_DATA(ptr, data)  unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)data)
+
+inline BYTE* pack_TPM2B_PUBLIC_KEY_RSA(BYTE* ptr, const TPM2B_PUBLIC_KEY_RSA *rsa)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)rsa);
+}
+
+#define unpack_TPM2B_PUBLIC_KEY_RSA(ptr, rsa)   unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)rsa)
+
+inline BYTE* pack_TPM2B_PRIVATE(BYTE* ptr, const TPM2B_PRIVATE *Private)
+{
+    ptr = pack_UINT16(ptr, Private->size);
+    ptr = pack_TPM_BUFFER(ptr, Private->buffer, Private->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_PRIVATE(BYTE* ptr, TPM2B_PRIVATE *Private)
+{
+    ptr = unpack_UINT16(ptr, &Private->size);
+    ptr = unpack_BUFFER(ptr, Private->buffer, Private->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION_ARRAY(BYTE* ptr, const TPMS_PCR_SELECTION *sel, UINT32 count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+        ptr = pack_TPMI_ALG_HASH(ptr, &sel[i].hash);
+        ptr = pack_BYTE(ptr, sel[i].sizeofSelect);
+        ptr = pack_BUFFER(ptr, sel[i].pcrSelect, sel[i].sizeofSelect);
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_PCR_SELECTION_ARRAY(BYTE* ptr, TPMS_PCR_SELECTION *sel, UINT32 count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+        ptr = unpack_TPMI_ALG_HASH(ptr, &sel[i].hash);
+        ptr = unpack_BYTE(ptr, &sel[i].sizeofSelect);
+        ptr = unpack_BUFFER(ptr, sel[i].pcrSelect, sel[i].sizeofSelect);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPML_PCR_SELECTION(BYTE* ptr, const TPML_PCR_SELECTION *sel)
+{
+    ptr = pack_UINT32(ptr, sel->count);
+    ptr = pack_TPMS_PCR_SELECTION_ARRAY(ptr, sel->pcrSelections, sel->count);
+    return ptr;
+}
+
+inline BYTE* unpack_TPML_PCR_SELECTION(BYTE* ptr, TPML_PCR_SELECTION *sel)
+{
+    ptr = unpack_UINT32(ptr, &sel->count);
+    ptr = unpack_TPMS_PCR_SELECTION_ARRAY(ptr, sel->pcrSelections, sel->count);
+    return ptr;
+}
+
+inline BYTE* unpack_TPML_DIGEST(BYTE* ptr,TPML_DIGEST *digest)
+{
+    int i;
+    ptr = unpack_UINT32(ptr, &digest->count);
+    for (i=0;i<digest->count;i++)
+    {
+        ptr = unpack_TPM2B_DIGEST(ptr, &digest->digests[i]);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_CREATION_DATA(BYTE* ptr,const TPMS_CREATION_DATA *data)
+{
+    ptr = pack_TPML_PCR_SELECTION(ptr, &data->pcrSelect);
+    ptr = pack_TPM2B_DIGEST(ptr, &data->pcrDigest);
+    ptr = pack_TPMA_LOCALITY(ptr, &data->locality);
+    ptr = pack_TPM_ALG_ID(ptr, &data->parentNameAlg);
+    ptr = pack_TPM2B_NAME(ptr, &data->parentQualifiedName);
+    ptr = pack_TPM2B_DATA(ptr, &data->outsideInfo);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_CREATION_DATA(BYTE* ptr, TPMS_CREATION_DATA *data)
+{
+    ptr = unpack_TPML_PCR_SELECTION(ptr, &data->pcrSelect);
+    ptr = unpack_TPM2B_DIGEST(ptr, &data->pcrDigest);
+    ptr = unpack_TPMA_LOCALITY(ptr, &data->locality);
+    ptr = unpack_TPM_ALG_ID(ptr, &data->parentNameAlg);
+    ptr = unpack_TPM2B_NAME(ptr, &data->parentName);
+    ptr = unpack_TPM2B_NAME(ptr, &data->parentQualifiedName);
+    ptr = unpack_TPM2B_DATA(ptr, &data->outsideInfo);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_CREATION_DATA(BYTE* ptr, const TPM2B_CREATION_DATA *data )
+{
+    ptr = pack_UINT16(ptr, data->size);
+    ptr = pack_TPMS_CREATION_DATA(ptr, &data->creationData);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_CREATION_DATA(BYTE* ptr, TPM2B_CREATION_DATA * data)
+{
+    ptr = unpack_UINT16(ptr, &data->size);
+    ptr = unpack_TPMS_CREATION_DATA(ptr, &data->creationData);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_SENSITIVE_CREATE(BYTE* ptr, const TPMS_SENSITIVE_CREATE *create)
+{
+    ptr = pack_TPM2B_AUTH(ptr, &create->userAuth);
+    ptr = pack_TPM2B_SENSITIVE_DATA(ptr, &create->data);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_SENSITIVE_CREATE(BYTE* ptr, const TPM2B_SENSITIVE_CREATE *create)
+{
+    BYTE* sizePtr = ptr;
+    ptr += 2;
+    ptr = pack_TPMS_SENSITIVE_CREATE(ptr, &create->sensitive);
+    pack_UINT16(sizePtr, (UINT16)(ptr - sizePtr - 2));
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_SYM_MODE(BYTE* ptr, const TPMU_SYM_MODE *p,
+                                const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = pack_TPMI_ALG_SYM_MODE(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        case TPM2_ALG_XOR:
+        break;
+    default:
+        ptr = pack_TPMI_ALG_SYM_MODE(ptr, &p->sym);
+    }
+    return ptr;
+}
+inline BYTE* unpack_TPMU_SYM_MODE(BYTE* ptr, TPMU_SYM_MODE *p,
+                                  const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = unpack_TPMI_ALG_SYM_MODE(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+    case TPM2_ALG_XOR:
+        break;
+    default:
+        ptr = unpack_TPMI_ALG_SYM_MODE(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_SYM_KEY_BITS(BYTE* ptr, const TPMU_SYM_KEY_BITS *p,
+                                    const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = pack_TPMI_AES_KEY_BITS(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_XOR:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        ptr = pack_TPM_KEY_BITS(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMU_SYM_KEY_BITS(BYTE* ptr, TPMU_SYM_KEY_BITS *p,
+                                      const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = unpack_TPMI_AES_KEY_BITS(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_XOR:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        ptr = unpack_TPM_KEY_BITS(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_SYM_DEF_OBJECT(BYTE* ptr, const TPMT_SYM_DEF_OBJECT *p)
+{
+    ptr = pack_TPMI_ALG_SYM_OBJECT(ptr, &p->algorithm);
+    ptr = pack_TPMU_SYM_KEY_BITS(ptr, &p->keyBits, &p->algorithm);
+    ptr = pack_TPMU_SYM_MODE(ptr, &p->mode, &p->algorithm);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_SYM_DEF_OBJECT(BYTE *ptr, TPMT_SYM_DEF_OBJECT *p)
+{
+    ptr = unpack_TPMI_ALG_SYM_OBJECT(ptr, &p->algorithm);
+    ptr = unpack_TPMU_SYM_KEY_BITS(ptr, &p->keyBits, &p->algorithm);
+    ptr = unpack_TPMU_SYM_MODE(ptr, &p->mode, &p->algorithm);
+    return ptr;
+}
+
+#define pack_TPMS_SCHEME_OAEP(p, t)     pack_TPMI_ALG_HASH(p, &((t)->hashAlg))
+#define unpack_TPMS_SCHEME_OAEP(p, t)   unpack_TPMI_ALG_HASH(p, &((t)->hashAlg))
+
+inline BYTE* pack_TPMU_ASYM_SCHEME(BYTE *ptr, const TPMU_ASYM_SCHEME *p,
+                                   const TPMI_ALG_RSA_SCHEME *s)
+{
+    switch(*s) {
+#ifdef TPM2_ALG_RSASSA
+    case TPM2_ALG_RSASSA:
+        assert(false || "TPM2_ALG_RSASSA");
+        break;
+#endif
+#ifdef TPM2_ALG_OAEP
+    case TPM2_ALG_OAEP:
+        ptr = pack_TPMS_SCHEME_OAEP(ptr, &p->oaep);
+        break;
+#endif
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        assert(false || "DEFAULT");
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMU_ASYM_SCHEME(BYTE *ptr, TPMU_ASYM_SCHEME *p,
+                                     const TPMI_ALG_RSA_SCHEME *s)
+{
+    switch(*s) {
+    #ifdef TPM2_ALG_RSASSA
+    case TPM2_ALG_RSASSA:
+        printf("not support TPM_ALG_RSASSA\n");
+        assert(false);
+        break;
+    #endif
+    #ifdef TPM2_ALG_OAEP
+    case TPM2_ALG_OAEP:
+        ptr = unpack_TPMS_SCHEME_OAEP(ptr, &p->oaep);
+        break;
+    #endif
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        printf("default TPMI_ALG_RSA_SCHEME 0x%X\n", (UINT32)*s);
+        ptr = unpack_TPMI_ALG_HASH(ptr, &p->anySig.hashAlg);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_RSA_SCHEME(BYTE* ptr, const TPMT_RSA_SCHEME *p)
+{
+    ptr = pack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_RSA_SCHEME(BYTE* ptr, TPMT_RSA_SCHEME *p)
+{
+    ptr = unpack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = unpack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_RSA_DECRYPT(BYTE* ptr, const TPMT_RSA_DECRYPT *p)
+{
+    ptr = pack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_RSA_PARMS(BYTE* ptr, const TPMS_RSA_PARMS *p)
+{
+    ptr = pack_TPMT_SYM_DEF_OBJECT(ptr, &p->symmetric);
+    ptr = pack_TPMT_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMI_RSA_KEY_BITS(ptr, &p->keyBits);
+    ptr = pack_UINT32(ptr, p->exponent);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_RSA_PARMS(BYTE *ptr, TPMS_RSA_PARMS *p)
+{
+    ptr = unpack_TPMT_SYM_DEF_OBJECT(ptr, &p->symmetric);
+    ptr = unpack_TPMT_RSA_SCHEME(ptr, &p->scheme);
+    ptr = unpack_TPMI_RSA_KEY_BITS(ptr, &p->keyBits);
+    ptr = unpack_UINT32(ptr, &p->exponent);
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_PUBLIC_PARMS(BYTE* ptr, const TPMU_PUBLIC_PARMS *param,
+                                    const TPMI_ALG_PUBLIC *selector)
+{
+    switch(*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        assert(false);
+    case TPM2_ALG_SYMCIPHER:
+        assert(false);
+    case TPM2_ALG_RSA:
+        return pack_TPMS_RSA_PARMS(ptr, &param->rsaDetail);
+    case TPM2_ALG_ECC:
+        assert(false);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* unpack_TPMU_PUBLIC_PARMS(BYTE* ptr, TPMU_PUBLIC_PARMS *param,
+                                      const TPMI_ALG_PUBLIC *selector)
+{
+    switch(*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        assert(false);
+    case TPM2_ALG_SYMCIPHER:
+        assert(false);
+    case TPM2_ALG_RSA:
+        return unpack_TPMS_RSA_PARMS(ptr, &param->rsaDetail);
+    case TPM2_ALG_ECC:
+        assert(false);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* pack_TPMS_ECC_POINT(BYTE* ptr, const TPMS_ECC_POINT *point)
+{
+    assert(false);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_ECC_POINT(BYTE* ptr, TPMS_ECC_POINT *point)
+{
+    assert(false);
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_PUBLIC_ID(BYTE* ptr, const TPMU_PUBLIC_ID *id,
+                                 const TPMI_ALG_PUBLIC *selector)
+{
+    switch (*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        return pack_TPM2B_DIGEST(ptr, &id->keyedHash);
+    case TPM2_ALG_SYMCIPHER:
+        return pack_TPM2B_DIGEST(ptr, &id->sym);
+    case TPM2_ALG_RSA:
+        return pack_TPM2B_PUBLIC_KEY_RSA(ptr, &id->rsa);
+    case TPM2_ALG_ECC:
+        return pack_TPMS_ECC_POINT(ptr, &id->ecc);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* unpack_TPMU_PUBLIC_ID(BYTE* ptr, TPMU_PUBLIC_ID *id, TPMI_ALG_PUBLIC *selector)
+{
+    switch (*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        return unpack_TPM2B_DIGEST(ptr, &id->keyedHash);
+    case TPM2_ALG_SYMCIPHER:
+        return unpack_TPM2B_DIGEST(ptr, &id->sym);
+    case TPM2_ALG_RSA:
+        return unpack_TPM2B_PUBLIC_KEY_RSA(ptr, &id->rsa);
+    case TPM2_ALG_ECC:
+        return unpack_TPMS_ECC_POINT(ptr, &id->ecc);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* pack_TPMT_PUBLIC(BYTE* ptr, const TPMT_PUBLIC *public)
+{
+    ptr = pack_TPMI_ALG_PUBLIC(ptr, &public->type);
+    ptr = pack_TPMI_ALG_HASH(ptr, &public->nameAlg);
+    ptr = pack_TPMA_OBJECT(ptr, &public->objectAttributes);
+    ptr = pack_TPM2B_DIGEST(ptr, &public->authPolicy);
+    ptr = pack_TPMU_PUBLIC_PARMS(ptr, &public->parameters, &public->type);
+    ptr = pack_TPMU_PUBLIC_ID(ptr, &public->unique, &public->type);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_PUBLIC(BYTE* ptr, TPMT_PUBLIC *public)
+{
+    ptr = unpack_TPMI_ALG_PUBLIC(ptr, &public->type);
+    ptr = unpack_TPMI_ALG_HASH(ptr, &public->nameAlg);
+    ptr = unpack_TPMA_OBJECT(ptr, &public->objectAttributes);
+    ptr = unpack_TPM2B_DIGEST(ptr, &public->authPolicy);
+    ptr = unpack_TPMU_PUBLIC_PARMS(ptr, &public->parameters, &public->type);
+    ptr = unpack_TPMU_PUBLIC_ID(ptr, &public->unique, &public->type);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_PUBLIC(BYTE* ptr, const TPM2B_PUBLIC *public)
+{
+    BYTE *sizePtr = ptr;
+    ptr += 2;
+    ptr = pack_TPMT_PUBLIC(ptr, &public->publicArea);
+    pack_UINT16(sizePtr, (UINT16)(ptr - sizePtr - 2));
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_PUBLIC(BYTE* ptr, TPM2B_PUBLIC *public)
+{
+    ptr = unpack_UINT16(ptr, &public->size);
+    ptr = unpack_TPMT_PUBLIC(ptr, &public->publicArea);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION(BYTE* ptr, const TPMS_PCR_SELECTION *selection)
+{
+    ptr = pack_TPMI_ALG_HASH(ptr, &selection->hash);
+    ptr = pack_BYTE(ptr, selection->sizeofSelect);
+    ptr = pack_BYTE_ARRAY(ptr, selection->pcrSelect, selection->sizeofSelect);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION_Array(BYTE* ptr, const TPMS_PCR_SELECTION *selections,
+                                           const UINT32 cnt)
+{
+    int i;
+    for (i = 0; i < cnt; i++)
+        ptr = pack_TPMS_PCR_SELECTION(ptr, selections + i);
+    return ptr;
+}
+
+inline BYTE* pack_TPM_AuthArea(BYTE* ptr, const TPM_AuthArea *auth)
+{
+    BYTE* sizePtr = ptr;
+    ptr += sizeof(UINT32);
+    ptr = pack_TPM_RH(ptr, &auth->sessionHandle);
+    ptr = pack_TPM2B_NONCE(ptr, &auth->nonce);
+    ptr = pack_TPMA_SESSION(ptr, &auth->sessionAttributes);
+    ptr = pack_TPM2B_AUTH(ptr, &auth->auth);
+    pack_UINT32(sizePtr, ptr - sizePtr - sizeof(UINT32));
+    return ptr;
+}
+
+inline BYTE* unpack_TPM_AuthArea(BYTE* ptr, TPM_AuthArea *auth)
+{
+    ptr = unpack_UINT32(ptr, &auth->size);
+    ptr = unpack_TPM_RH(ptr, &auth->sessionHandle);
+    ptr = unpack_TPM2B_NONCE(ptr, &auth->nonce);
+    ptr = unpack_TPMA_SESSION(ptr, &auth->sessionAttributes);
+    ptr = unpack_TPM2B_AUTH(ptr, &auth->auth);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2_RSA_KEY(BYTE* ptr, const TPM2_RSA_KEY *key)
+{
+    ptr = pack_TPM2B_PRIVATE(ptr, &key->Private);
+    ptr = pack_TPM2B_PUBLIC(ptr, &key->Public);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2_RSA_KEY(BYTE* ptr, TPM2_RSA_KEY *key)
+{
+    ptr = unpack_TPM2B_PRIVATE(ptr, &key->Private);
+    ptr = unpack_TPM2B_PUBLIC(ptr, &key->Public);
+    return ptr;
+}
+#endif
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Bnf-0007hx-T2; Sun, 14 Dec 2014 16:13:39 +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 1Y0Bne-0007gC-NI
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:38 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	7B/70-02954-237BD845; Sun, 14 Dec 2014 16:13:38 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418573611!14939834!2
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 30968 invoked from network); 14 Dec 2014 16:13:37 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-27.messagelabs.com with SMTP;
	14 Dec 2014 16:13:37 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2014 08:13:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="428810536"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 14 Dec 2014 08:02:38 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:53 -0500
Message-Id: <1418558993-13681-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 09/12] vTPM/TPM2: Support '--tpm2' extra 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>
MIME-Version: 1.0
Content-Type: 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 vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
Add:
..
     extra="--tpm2"
..
to launch vtpm-stubdom domain on TPM 2.0, ignore it on TPM 1.x. for
example,
vtpm-stubdom domain configuration on TPM 2.0:

kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
memory=16
disk=["file:/var/scale/vdisk/vmgr,hda,w"]
name="vtpmmgr"
iomem=["fed40,5"]
extra="--tpm2"

vtpm-stubdom domain configuration on TPM 1.x:

kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
memory=16
disk=["file:/var/scale/vdisk/vmgr,hda,w"]
name="vtpmmgr"
iomem=["fed40,5"]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/vtpmmgr.c | 46 ++++++++++++++++++++++++++++++++++++++++------
 stubdom/vtpmmgr/vtpmmgr.h | 14 ++++++++++++++
 2 files changed, 54 insertions(+), 6 deletions(-)

diff --git a/stubdom/vtpmmgr/vtpmmgr.c b/stubdom/vtpmmgr/vtpmmgr.c
index 270ca8a..9cf0197 100644
--- a/stubdom/vtpmmgr/vtpmmgr.c
+++ b/stubdom/vtpmmgr/vtpmmgr.c
@@ -45,6 +45,27 @@
 #include "vtpmmgr.h"
 #include "tcg.h"
 
+struct tpm_hardware_version hardware_version = {
+    .hw_version = TPM1_HARDWARE,
+};
+
+int parse_cmdline_hw(int argc, char** argv)
+{
+    int i;
+
+    for (i = 1; i < argc; ++i) {
+        if (!strncmp(argv[i], TPM2_EXTRA_OPT, 6)) {
+            hardware_version.hw_version = TPM2_HARDWARE;
+            break;
+        }
+    }
+    return 0;
+}
+
+int hw_is_tpm2(void)
+{
+    return (hardware_version.hw_version == TPM2_HARDWARE) ? 1 : 0;
+}
 
 void main_loop(void) {
    tpmcmd_t* tpmcmd;
@@ -74,12 +95,25 @@ int main(int argc, char** argv)
    sleep(2);
    vtpmloginfo(VTPM_LOG_VTPM, "Starting vTPM manager domain\n");
 
-   /* Initialize the vtpm manager */
-   if(vtpmmgr_init(argc, argv) != TPM_SUCCESS) {
-      vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
-      rc = -1;
-      goto exit;
-   }
+    /*Parse TPM hardware in extra command line*/
+    parse_cmdline_hw(argc, argv);
+
+    /* Initialize the vtpm manager */
+    if (hw_is_tpm2()) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Hardware : --- TPM 2.0 ---\n");
+        if (vtpmmgr2_init(argc, argv) != TPM_SUCCESS) {
+            vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
+            rc = -1;
+            goto exit;
+        }
+    }else{
+        vtpmloginfo(VTPM_LOG_VTPM, "Hardware : --- TPM 1.x ---\n");
+        if (vtpmmgr_init(argc, argv) != TPM_SUCCESS) {
+            vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
+            rc = -1;
+            goto exit;
+        }
+    }
 
    main_loop();
 
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index c479443..37da1f2 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -46,9 +46,21 @@
 #include "vtpm_manager.h"
 #include "tpm2_types.h"
 
+#define TPM2_EXTRA_OPT "--tpm2"
 #define RSA_KEY_SIZE 0x0800
 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8)
 
+enum {
+    TPM1_HARDWARE = 1,
+    TPM2_HARDWARE,
+} tpm_version;
+
+struct tpm_hardware_version {
+    int hw_version;
+};
+
+extern struct tpm_hardware_version hardware_version;
+
 struct vtpm_globals {
    int tpm_fd;
    TPM_AUTH_SESSION    oiap;                // OIAP session for storageKey
@@ -97,5 +109,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 TPM_RC tpm2_take_ownership(void);
 TPM_RESULT vtpmmgr2_create(void);
 TPM_RESULT vtpmmgr2_init(int argc, char** argv);
+int parse_cmdline_hw(int argc, char** argv);
+int hw_is_tpm2(void);
 
 #endif
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Bne-0007gM-F3; Sun, 14 Dec 2014 16:13:38 +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 1Y0Bnd-0007fP-Sx
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:38 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	9F/1A-22777-137BD845; Sun, 14 Dec 2014 16:13:37 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418573615!13270779!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2680 invoked from network); 14 Dec 2014 16:13:36 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-206.messagelabs.com with SMTP;
	14 Dec 2014 16:13:36 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 14 Dec 2014 08:13:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="653716933"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 14 Dec 2014 08:13:33 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:50 -0500
Message-Id: <1418558990-13644-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 08/12] vTPM/TPM2: Add main entrance
	vtpmmgr2_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

Accept commands from the vtpm-stubdom domains via the mini-os TPM
backend driver. The vTPM manager communicates directly with hardware
TPM 2.0 using the mini-os tpm2_tis driver.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/init.c    | 110 ++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.h |   1 +
 2 files changed, 111 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 8244bb0..c901454 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -681,3 +681,113 @@ egress:
     vtpmloginfo(VTPM_LOG_VTPM, "Finished initialized new VTPM manager\n");
     return status;
 }
+
+static int tpm2_entropy_source(void* dummy, unsigned char* data,
+                               size_t len, size_t* olen)
+{
+    UINT32 sz = len;
+    TPM_RESULT rc = TPM2_GetRandom(&sz, data);
+    *olen = sz;
+    return rc == TPM_SUCCESS ? 0 : POLARSSL_ERR_ENTROPY_SOURCE_FAILED;
+}
+
+/*TPM 2.0 Objects flush */
+static TPM_RC flush_tpm2(void)
+{
+    int i;
+
+    for (i = TRANSIENT_FIRST; i < TRANSIENT_LAST; i++)
+         TPM2_FlushContext(i);
+
+    return TPM_SUCCESS;
+}
+
+TPM_RESULT vtpmmgr2_init(int argc, char** argv)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+
+    /* Default commandline options */
+    struct Opts opts = {
+        .tpmdriver = TPMDRV_TPM_TIS,
+        .tpmiomem = TPM_BASEADDR,
+        .tpmirq = 0,
+        .tpmlocality = 0,
+        .gen_owner_auth = 0,
+    };
+
+    if (parse_cmdline_opts(argc, argv, &opts) != 0) {
+        vtpmlogerror(VTPM_LOG_VTPM, "Command line parsing failed! exiting..\n");
+        status = TPM_BAD_PARAMETER;
+        goto abort_egress;
+    }
+
+    /*Setup storage system*/
+    if (vtpm_storage_init() != 0) {
+        vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize storage subsystem!\n");
+        status = TPM_IOERROR;
+        goto abort_egress;
+    }
+
+    /*Setup tpmback device*/
+    init_tpmback(set_opaque, free_opaque);
+
+    /*Setup tpm access*/
+    switch(opts.tpmdriver) {
+        case TPMDRV_TPM_TIS:
+        {
+            struct tpm_chip* tpm;
+            if ((tpm = init_tpm2_tis(opts.tpmiomem, TPM_TIS_LOCL_INT_TO_FLAG(opts.tpmlocality),
+                                     opts.tpmirq)) == NULL) {
+                vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize tpmfront device\n");
+                status = TPM_IOERROR;
+                goto abort_egress;
+            }
+            printk("init_tpm2_tis()       ...ok\n");
+            vtpm_globals.tpm_fd = tpm_tis_open(tpm);
+            tpm_tis_request_locality(tpm, opts.tpmlocality);
+        }
+        break;
+        case TPMDRV_TPMFRONT:
+        {
+            struct tpmfront_dev* tpmfront_dev;
+            if ((tpmfront_dev = init_tpmfront(NULL)) == NULL) {
+                vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize tpmfront device\n");
+                status = TPM_IOERROR;
+                goto abort_egress;
+            }
+            vtpm_globals.tpm_fd = tpmfront_open(tpmfront_dev);
+        }
+        break;
+    }
+    printk("TPM 2.0 access ...ok\n");
+    /* Blow away all stale handles left in the tpm*/
+    if (flush_tpm2() != TPM_SUCCESS) {
+        vtpmlogerror(VTPM_LOG_VTPM, "VTPM_FlushResources failed, continuing anyway..\n");
+    }
+
+    /* Initialize the rng */
+    entropy_init(&vtpm_globals.entropy);
+    entropy_add_source(&vtpm_globals.entropy, tpm2_entropy_source, NULL, 0);
+    entropy_gather(&vtpm_globals.entropy);
+    ctr_drbg_init(&vtpm_globals.ctr_drbg, entropy_func, &vtpm_globals.entropy, NULL, 0);
+    ctr_drbg_set_prediction_resistance( &vtpm_globals.ctr_drbg, CTR_DRBG_PR_OFF );
+
+    /* Generate Auth for Owner*/
+    if (opts.gen_owner_auth) {
+        vtpmmgr_rand(vtpm_globals.owner_auth, sizeof(TPM_AUTHDATA));
+    }
+
+    /* Load the Manager data, if it fails create a new manager */
+    if (vtpm_load_disk()) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Assuming first time initialization.\n");
+        TPMTRYRETURN(vtpmmgr2_create());
+    }
+
+    goto egress;
+
+abort_egress:
+    vtpmmgr_shutdown();
+egress:
+    return status;
+}
+
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 9889feb..c479443 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -96,5 +96,6 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 /* TPM 2.0 */
 TPM_RC tpm2_take_ownership(void);
 TPM_RESULT vtpmmgr2_create(void);
+TPM_RESULT vtpmmgr2_init(int argc, char** argv);
 
 #endif
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Bne-0007gM-F3; Sun, 14 Dec 2014 16:13:38 +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 1Y0Bnd-0007fP-Sx
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:38 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	9F/1A-22777-137BD845; Sun, 14 Dec 2014 16:13:37 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418573615!13270779!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2680 invoked from network); 14 Dec 2014 16:13:36 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-206.messagelabs.com with SMTP;
	14 Dec 2014 16:13:36 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 14 Dec 2014 08:13:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="653716933"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 14 Dec 2014 08:13:33 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:50 -0500
Message-Id: <1418558990-13644-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 08/12] vTPM/TPM2: Add main entrance
	vtpmmgr2_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

Accept commands from the vtpm-stubdom domains via the mini-os TPM
backend driver. The vTPM manager communicates directly with hardware
TPM 2.0 using the mini-os tpm2_tis driver.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/init.c    | 110 ++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.h |   1 +
 2 files changed, 111 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 8244bb0..c901454 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -681,3 +681,113 @@ egress:
     vtpmloginfo(VTPM_LOG_VTPM, "Finished initialized new VTPM manager\n");
     return status;
 }
+
+static int tpm2_entropy_source(void* dummy, unsigned char* data,
+                               size_t len, size_t* olen)
+{
+    UINT32 sz = len;
+    TPM_RESULT rc = TPM2_GetRandom(&sz, data);
+    *olen = sz;
+    return rc == TPM_SUCCESS ? 0 : POLARSSL_ERR_ENTROPY_SOURCE_FAILED;
+}
+
+/*TPM 2.0 Objects flush */
+static TPM_RC flush_tpm2(void)
+{
+    int i;
+
+    for (i = TRANSIENT_FIRST; i < TRANSIENT_LAST; i++)
+         TPM2_FlushContext(i);
+
+    return TPM_SUCCESS;
+}
+
+TPM_RESULT vtpmmgr2_init(int argc, char** argv)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+
+    /* Default commandline options */
+    struct Opts opts = {
+        .tpmdriver = TPMDRV_TPM_TIS,
+        .tpmiomem = TPM_BASEADDR,
+        .tpmirq = 0,
+        .tpmlocality = 0,
+        .gen_owner_auth = 0,
+    };
+
+    if (parse_cmdline_opts(argc, argv, &opts) != 0) {
+        vtpmlogerror(VTPM_LOG_VTPM, "Command line parsing failed! exiting..\n");
+        status = TPM_BAD_PARAMETER;
+        goto abort_egress;
+    }
+
+    /*Setup storage system*/
+    if (vtpm_storage_init() != 0) {
+        vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize storage subsystem!\n");
+        status = TPM_IOERROR;
+        goto abort_egress;
+    }
+
+    /*Setup tpmback device*/
+    init_tpmback(set_opaque, free_opaque);
+
+    /*Setup tpm access*/
+    switch(opts.tpmdriver) {
+        case TPMDRV_TPM_TIS:
+        {
+            struct tpm_chip* tpm;
+            if ((tpm = init_tpm2_tis(opts.tpmiomem, TPM_TIS_LOCL_INT_TO_FLAG(opts.tpmlocality),
+                                     opts.tpmirq)) == NULL) {
+                vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize tpmfront device\n");
+                status = TPM_IOERROR;
+                goto abort_egress;
+            }
+            printk("init_tpm2_tis()       ...ok\n");
+            vtpm_globals.tpm_fd = tpm_tis_open(tpm);
+            tpm_tis_request_locality(tpm, opts.tpmlocality);
+        }
+        break;
+        case TPMDRV_TPMFRONT:
+        {
+            struct tpmfront_dev* tpmfront_dev;
+            if ((tpmfront_dev = init_tpmfront(NULL)) == NULL) {
+                vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize tpmfront device\n");
+                status = TPM_IOERROR;
+                goto abort_egress;
+            }
+            vtpm_globals.tpm_fd = tpmfront_open(tpmfront_dev);
+        }
+        break;
+    }
+    printk("TPM 2.0 access ...ok\n");
+    /* Blow away all stale handles left in the tpm*/
+    if (flush_tpm2() != TPM_SUCCESS) {
+        vtpmlogerror(VTPM_LOG_VTPM, "VTPM_FlushResources failed, continuing anyway..\n");
+    }
+
+    /* Initialize the rng */
+    entropy_init(&vtpm_globals.entropy);
+    entropy_add_source(&vtpm_globals.entropy, tpm2_entropy_source, NULL, 0);
+    entropy_gather(&vtpm_globals.entropy);
+    ctr_drbg_init(&vtpm_globals.ctr_drbg, entropy_func, &vtpm_globals.entropy, NULL, 0);
+    ctr_drbg_set_prediction_resistance( &vtpm_globals.ctr_drbg, CTR_DRBG_PR_OFF );
+
+    /* Generate Auth for Owner*/
+    if (opts.gen_owner_auth) {
+        vtpmmgr_rand(vtpm_globals.owner_auth, sizeof(TPM_AUTHDATA));
+    }
+
+    /* Load the Manager data, if it fails create a new manager */
+    if (vtpm_load_disk()) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Assuming first time initialization.\n");
+        TPMTRYRETURN(vtpmmgr2_create());
+    }
+
+    goto egress;
+
+abort_egress:
+    vtpmmgr_shutdown();
+egress:
+    return status;
+}
+
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 9889feb..c479443 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -96,5 +96,6 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 /* TPM 2.0 */
 TPM_RC tpm2_take_ownership(void);
 TPM_RESULT vtpmmgr2_create(void);
+TPM_RESULT vtpmmgr2_init(int argc, char** argv);
 
 #endif
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnQ-0007ZJ-6P; Sun, 14 Dec 2014 16:13:24 +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 1Y0BnO-0007YQ-5c
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:22 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	B2/B0-03148-127BD845; Sun, 14 Dec 2014 16:13:21 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418573600!10323191!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31789 invoked from network); 14 Dec 2014 16:13:20 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-27.messagelabs.com with SMTP;
	14 Dec 2014 16:13:20 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 14 Dec 2014 08:13:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="623611030"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 14 Dec 2014 08:13:17 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:35 -0500
Message-Id: <1418558975-13455-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 03/12] vTPM/TPM2: Add global data in
	vtpm_globals{}
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 data is for the Mini-os to access TPM 2.0 hardware.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/vtpmmgr.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 2d9d153..0d0c604 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -44,6 +44,7 @@
 #include "uuid.h"
 #include "tcg.h"
 #include "vtpm_manager.h"
+#include "tpm2_types.h"
 
 #define RSA_KEY_SIZE 0x0800
 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8)
@@ -59,6 +60,14 @@ struct vtpm_globals {
    ctr_drbg_context    ctr_drbg;
 
    int hw_locality;
+
+    /* TPM 2.0 */
+    TPM_AuthArea       pw_auth;
+    TPM_AuthArea       srk_auth_area;
+    TPM_HANDLE         srk_handle;
+    TPM_HANDLE         sk_handle;
+    TPM2B_NAME         sk_name;
+    TPM2_RSA_KEY       tpm2_storage_key;
 };
 
 struct tpm_opaque {
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnN-0007YG-3V; Sun, 14 Dec 2014 16:13:21 +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 1Y0BnL-0007Xy-Gw
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:19 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	17/24-23865-E17BD845; Sun, 14 Dec 2014 16:13:18 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418573594!8804052!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 22143 invoked from network); 14 Dec 2014 16:13:15 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-31.messagelabs.com with SMTP;
	14 Dec 2014 16:13:15 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2014 08:13:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="647434585"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 14 Dec 2014 08:13:11 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:29 -0500
Message-Id: <1418558969-13381-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 01/12] vTPM/TPM2: Add TPM 2.0 data structures
	and commands 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

Add TPM 2.0 data structures on Trusted Platform Module Library Part 2:
Structures and Trust Platform Module Library Part 3: Commands.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/tpm2_types.h | 978 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 978 insertions(+)
 create mode 100644 stubdom/vtpmmgr/tpm2_types.h

diff --git a/stubdom/vtpmmgr/tpm2_types.h b/stubdom/vtpmmgr/tpm2_types.h
new file mode 100644
index 0000000..214335c
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2_types.h
@@ -0,0 +1,978 @@
+#ifndef __TPM2_TYPES_H__
+#define __TPM2_TYPES_H__
+
+#include <stdlib.h>
+#include <stdint.h>
+
+// "implementation.h"
+// Table 212 -- Logic Values
+#define    YES      1
+#define    NO       0
+#ifndef    TRUE
+#define    TRUE     1
+#endif
+#ifndef    FALSE
+#define    FALSE    0
+#endif
+#ifndef    true
+#define    true     1
+#endif
+#ifndef    false
+#define    false    0
+#endif
+#define    SET      1
+#define    CLEAR    0
+
+
+// Table 214 -- Implemented Algorithms
+#define    ALG_RSA               YES    // 1
+#define    ALG_DES               NO     // 0
+#define    ALG__3DES             NO     // 0
+#define    ALG_SHA1              YES    // 1
+#define    ALG_HMAC              YES    // 1
+#define    ALG_AES               YES    // 1
+#define    ALG_MGF1              YES    // 1
+#define    ALG_XOR               YES    // 1
+#define    ALG_KEYEDHASH         YES    // 1
+#define    ALG_SHA256            YES    // 1
+#define    ALG_SHA384            YES    // 0
+#define    ALG_SHA512            YES    // 0
+#define    ALG_WHIRLPOOL512      YES    // 0
+#define    ALG_SM3_256           YES    // 1
+#define    ALG_SM4               YES    // 1
+#define    ALG_RSASSA            YES    // 1
+#define    ALG_RSAES             YES    // 1
+#define    ALG_RSAPSS            YES    // 1
+#define    ALG_OAEP              YES    // 1
+#define    ALG_ECC               YES    // 1
+#define    ALG_CFB               YES    // 1
+#define    ALG_ECDH              YES    // 1
+#define    ALG_ECDSA             YES    // 1
+#define    ALG_ECDAA             YES    // 1
+#define    ALG_SM2               YES    // 1
+#define    ALG_ECSCHNORR         YES    // 1
+#define    ALG_SYMCIPHER         YES    // 1
+#define    ALG_KDF1_SP800_56a    YES    // 1
+#define    ALG_KDF2              NO     // 0
+#define    ALG_KDF1_SP800_108    YES    // 1
+#define    ALG_CTR               YES    // 1
+#define    ALG_OFB               YES    // 1
+#define    ALG_CBC               YES    // 1
+
+#define HASH_COUNT (ALG_SHA1+ALG_SHA256+ALG_SHA384+ALG_SHA512+ALG_WHIRLPOOL512+ALG_SM3_256)
+
+// Table 216 -- RSA Algorithm Constants
+#define    RSA_KEY_SIZES_BITS    2048    // {1024,2048}
+#define    MAX_RSA_KEY_BITS      2048
+#define    MAX_RSA_KEY_BYTES     ((MAX_RSA_KEY_BITS + 7) / 8)    // 256
+
+// Table 218 -- AES Algorithm Constants
+#define    AES_KEY_SIZES_BITS          128
+#define    MAX_AES_KEY_BITS            128
+#define    MAX_AES_BLOCK_SIZE_BYTES    16
+#define    MAX_AES_KEY_BYTES           ((MAX_AES_KEY_BITS + 7) / 8)    // 16
+
+
+// Table 220 -- Symmetric Algorithm Constants
+#define    MAX_SYM_KEY_BITS      MAX_AES_KEY_BITS    // 128
+#define    MAX_SYM_KEY_BYTES     MAX_AES_KEY_BYTES    // 16
+#define    MAX_SYM_BLOCK_SIZE    MAX_AES_BLOCK_SIZE_BYTES    // 16
+
+#define    MAX_SYM_DATA         128
+#define    MAX_ECC_KEY_BITS     256
+#define    MAX_ECC_KEY_BYTES    ((MAX_ECC_KEY_BITS + 7) / 8)
+
+
+typedef unsigned char BYTE;
+typedef unsigned char BOOL;
+typedef uint8_t       UINT8;
+typedef uint16_t      UINT16;
+typedef uint32_t      UINT32;
+typedef uint64_t      UINT64;
+
+// TPM2 command code
+
+typedef UINT32 TPM_CC;
+#define    TPM_CC_FIRST                         (TPM_CC)(0x0000011F)
+#define    TPM_CC_PP_FIRST                      (TPM_CC)(0x0000011F)
+#define    TPM_CC_NV_UndefineSpaceSpecial       (TPM_CC)(0x0000011F)
+#define    TPM_CC_EvictControl                  (TPM_CC)(0x00000120)
+#define    TPM_CC_HierarchyControl              (TPM_CC)(0x00000121)
+#define    TPM_CC_NV_UndefineSpace              (TPM_CC)(0x00000122)
+#define    TPM_CC_ChangeEPS                     (TPM_CC)(0x00000124)
+#define    TPM_CC_ChangePPS                     (TPM_CC)(0x00000125)
+#define    TPM_CC_Clear                         (TPM_CC)(0x00000126)
+#define    TPM_CC_ClearControl                  (TPM_CC)(0x00000127)
+#define    TPM_CC_ClockSet                      (TPM_CC)(0x00000128)
+#define    TPM_CC_HierarchyChangeAuth           (TPM_CC)(0x00000129)
+#define    TPM_CC_NV_DefineSpace                (TPM_CC)(0x0000012A)
+#define    TPM_CC_PCR_Allocate                  (TPM_CC)(0x0000012B)
+#define    TPM_CC_PCR_SetAuthPolicy             (TPM_CC)(0x0000012C)
+#define    TPM_CC_PP_Commands                   (TPM_CC)(0x0000012D)
+#define    TPM_CC_SetPrimaryPolicy              (TPM_CC)(0x0000012E)
+#define    TPM_CC_FieldUpgradeStart             (TPM_CC)(0x0000012F)
+#define    TPM_CC_ClockRateAdjust               (TPM_CC)(0x00000130)
+#define    TPM_CC_CreatePrimary                 (TPM_CC)(0x00000131)
+#define    TPM_CC_NV_GlobalWriteLock            (TPM_CC)(0x00000132)
+#define    TPM_CC_PP_LAST                       (TPM_CC)(0x00000132)
+#define    TPM_CC_GetCommandAuditDigest         (TPM_CC)(0x00000133)
+#define    TPM_CC_NV_Increment                  (TPM_CC)(0x00000134)
+#define    TPM_CC_NV_SetBits                    (TPM_CC)(0x00000135)
+#define    TPM_CC_NV_Extend                     (TPM_CC)(0x00000136)
+#define    TPM_CC_NV_Write                      (TPM_CC)(0x00000137)
+#define    TPM_CC_NV_WriteLock                  (TPM_CC)(0x00000138)
+#define    TPM_CC_DictionaryAttackLockReset     (TPM_CC)(0x00000139)
+#define    TPM_CC_DictionaryAttackParameters    (TPM_CC)(0x0000013A)
+#define    TPM_CC_NV_ChangeAuth                 (TPM_CC)(0x0000013B)
+#define    TPM_CC_PCR_Event                     (TPM_CC)(0x0000013C)
+#define    TPM_CC_PCR_Reset                     (TPM_CC)(0x0000013D)
+#define    TPM_CC_SequenceComplete              (TPM_CC)(0x0000013E)
+#define    TPM_CC_SetAlgorithmSet               (TPM_CC)(0x0000013F)
+#define    TPM_CC_SetCommandCodeAuditStatus     (TPM_CC)(0x00000140)
+#define    TPM_CC_FieldUpgradeData              (TPM_CC)(0x00000141)
+#define    TPM_CC_IncrementalSelfTest           (TPM_CC)(0x00000142)
+#define    TPM_CC_SelfTest                      (TPM_CC)(0x00000143)
+#define    TPM_CC_Startup                       (TPM_CC)(0x00000144)
+#define    TPM_CC_Shutdown                      (TPM_CC)(0x00000145)
+#define    TPM_CC_StirRandom                    (TPM_CC)(0x00000146)
+#define    TPM_CC_ActivateCredential            (TPM_CC)(0x00000147)
+#define    TPM_CC_Certify                       (TPM_CC)(0x00000148)
+#define    TPM_CC_PolicyNV                      (TPM_CC)(0x00000149)
+#define    TPM_CC_CertifyCreation               (TPM_CC)(0x0000014A)
+#define    TPM_CC_Duplicate                     (TPM_CC)(0x0000014B)
+#define    TPM_CC_GetTime                       (TPM_CC)(0x0000014C)
+#define    TPM_CC_GetSessionAuditDigest         (TPM_CC)(0x0000014D)
+#define    TPM_CC_NV_Read                       (TPM_CC)(0x0000014E)
+#define    TPM_CC_NV_ReadLock                   (TPM_CC)(0x0000014F)
+#define    TPM_CC_ObjectChangeAuth              (TPM_CC)(0x00000150)
+#define    TPM_CC_PolicySecret                  (TPM_CC)(0x00000151)
+#define    TPM_CC_Rewrap                        (TPM_CC)(0x00000152)
+#define    TPM_CC_Create                        (TPM_CC)(0x00000153)
+#define    TPM_CC_ECDH_ZGen                     (TPM_CC)(0x00000154)
+#define    TPM_CC_HMAC                          (TPM_CC)(0x00000155)
+#define    TPM_CC_Import                        (TPM_CC)(0x00000156)
+#define    TPM_CC_Load                          (TPM_CC)(0x00000157)
+#define    TPM_CC_Quote                         (TPM_CC)(0x00000158)
+#define    TPM_CC_RSA_Decrypt                   (TPM_CC)(0x00000159)
+#define    TPM_CC_HMAC_Start                    (TPM_CC)(0x0000015B)
+#define    TPM_CC_SequenceUpdate                (TPM_CC)(0x0000015C)
+#define    TPM_CC_Sign                          (TPM_CC)(0x0000015D)
+#define    TPM_CC_Unseal                        (TPM_CC)(0x0000015E)
+#define    TPM_CC_PolicySigned                  (TPM_CC)(0x00000160)
+#define    TPM_CC_ContextLoad                   (TPM_CC)(0x00000161)
+#define    TPM_CC_ContextSave                   (TPM_CC)(0x00000162)
+#define    TPM_CC_ECDH_KeyGen                   (TPM_CC)(0x00000163)
+#define    TPM_CC_EncryptDecrypt                (TPM_CC)(0x00000164)
+#define    TPM_CC_FlushContext                  (TPM_CC)(0x00000165)
+#define    TPM_CC_LoadExternal                  (TPM_CC)(0x00000167)
+#define    TPM_CC_MakeCredential                (TPM_CC)(0x00000168)
+#define    TPM_CC_NV_ReadPublic                 (TPM_CC)(0x00000169)
+#define    TPM_CC_PolicyAuthorize               (TPM_CC)(0x0000016A)
+#define    TPM_CC_PolicyAuthValue               (TPM_CC)(0x0000016B)
+#define    TPM_CC_PolicyCommandCode             (TPM_CC)(0x0000016C)
+#define    TPM_CC_PolicyCounterTimer            (TPM_CC)(0x0000016D)
+#define    TPM_CC_PolicyCpHash                  (TPM_CC)(0x0000016E)
+#define    TPM_CC_PolicyLocality                (TPM_CC)(0x0000016F)
+#define    TPM_CC_PolicyNameHash                (TPM_CC)(0x00000170)
+#define    TPM_CC_PolicyOR                      (TPM_CC)(0x00000171)
+#define    TPM_CC_PolicyTicket                  (TPM_CC)(0x00000172)
+#define    TPM_CC_ReadPublic                    (TPM_CC)(0x00000173)
+#define    TPM_CC_RSA_Encrypt                   (TPM_CC)(0x00000174)
+#define    TPM_CC_StartAuthSession              (TPM_CC)(0x00000176)
+#define    TPM_CC_VerifySignature               (TPM_CC)(0x00000177)
+#define    TPM_CC_ECC_Parameters                (TPM_CC)(0x00000178)
+#define    TPM_CC_FirmwareRead                  (TPM_CC)(0x00000179)
+#define    TPM_CC_GetCapability                 (TPM_CC)(0x0000017A)
+#define    TPM_CC_GetRandom                     (TPM_CC)(0x0000017B)
+#define    TPM_CC_GetTestResult                 (TPM_CC)(0x0000017C)
+#define    TPM_CC_Hash                          (TPM_CC)(0x0000017D)
+#define    TPM_CC_PCR_Read                      (TPM_CC)(0x0000017E)
+#define    TPM_CC_PolicyPCR                     (TPM_CC)(0x0000017F)
+#define    TPM_CC_PolicyRestart                 (TPM_CC)(0x00000180)
+#define    TPM_CC_ReadClock                     (TPM_CC)(0x00000181)
+#define    TPM_CC_PCR_Extend                    (TPM_CC)(0x00000182)
+#define    TPM_CC_PCR_SetAuthValue              (TPM_CC)(0x00000183)
+#define    TPM_CC_NV_Certify                    (TPM_CC)(0x00000184)
+#define    TPM_CC_EventSequenceComplete         (TPM_CC)(0x00000185)
+#define    TPM_CC_HashSequenceStart             (TPM_CC)(0x00000186)
+#define    TPM_CC_PolicyPhysicalPresence        (TPM_CC)(0x00000187)
+#define    TPM_CC_PolicyDuplicationSelect       (TPM_CC)(0x00000188)
+#define    TPM_CC_PolicyGetDigest               (TPM_CC)(0x00000189)
+#define    TPM_CC_TestParms                     (TPM_CC)(0x0000018A)
+#define    TPM_CC_Commit                        (TPM_CC)(0x0000018B)
+#define    TPM_CC_PolicyPassword                (TPM_CC)(0x0000018C)
+#define    TPM_CC_SM2_ZGen                      (TPM_CC)(0x0000018D)
+#define    TPM_CC_LAST                          (TPM_CC)(0x0000018D)
+
+
+//TPM_RC
+typedef UINT32 TPM_RC;
+
+// TPM_ST Constants
+typedef UINT16 TPM_ST;
+#define    TPM_ST_NULL                    (TPM_ST)(0X8000)
+#define    TPM_ST_NO_SESSIONS             (TPM_ST)(0x8001)
+#define    TPM_ST_SESSIONS                (TPM_ST)(0x8002)
+
+
+// TPM Handle types
+typedef UINT32 TPM_HANDLE;
+typedef UINT8 TPM_HT;
+
+
+// TPM_RH Constants
+typedef UINT32 TPM_RH;
+
+#define    TPM_RH_FIRST          (TPM_RH)(0x40000000)
+#define    TPM_RH_SRK            (TPM_RH)(0x40000000)
+#define    TPM_RH_OWNER          (TPM_RH)(0x40000001)
+#define    TPM_RS_PW             (TPM_RH)(0x40000009)
+#define    TPM_RH_LOCKOUT        (TPM_RH)(0x4000000A)
+#define    TPM_RH_ENDORSEMENT    (TPM_RH)(0x4000000B)
+#define    TPM_RH_PLATFORM       (TPM_RH)(0x4000000C)
+#define    TPM_RH_LAST           (TPM_RH)(0x4000000C)
+
+// Table 4 -- DocumentationClarity Types <I/O>
+typedef UINT32    TPM_ALGORITHM_ID;
+typedef UINT32    TPM_MODIFIER_INDICATOR;
+typedef UINT32    TPM_SESSION_OFFSET;
+typedef UINT16    TPM_KEY_SIZE;
+typedef UINT16    TPM_KEY_BITS;
+typedef UINT64    TPM_SYSTEM_ADDRESS;
+typedef UINT32    TPM_SPEC;
+
+// Table 29 -- TPMA_ALGORITHM Bits <I/O>
+typedef struct {
+    unsigned int asymmetric:1;
+    unsigned int symmetric:1;
+    unsigned int hash:1;
+    unsigned int object:1;
+    unsigned int reserved5:4;
+    unsigned int signing:1;
+    unsigned int encrypting:1;
+    unsigned int method:1;
+    unsigned int reserved9:21;
+} TPMA_ALGORITHM;
+
+typedef UINT32 TPMA_OBJECT;
+typedef BYTE TPMA_SESSION;
+typedef BYTE TPMA_LOCALITY;
+
+// Table 37 -- TPMI_YES_NO Type <I/O>
+typedef BYTE TPMI_YES_NO;
+
+typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
+
+// Table 38 -- TPMI_DH_OBJECT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_OBJECT;
+
+// Table 39 -- TPMI_DH_PERSISTENT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_PERSISTENT;
+
+// Table 42 -- TPMI_SH_AUTH_SESSION Type <I/O>
+typedef TPM_HANDLE TPMI_SH_AUTH_SESSION;
+
+// Table 40 -- TPMI_DH_ENTITY Type <I>
+typedef TPM_HANDLE TPMI_DH_ENTITY;
+
+// Table 45 -- TPMI_DH_CONTEXT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_CONTEXT;
+
+// Table 46 -- TPMI_RH_HIERARCHY Type <I/O>
+typedef TPM_HANDLE TPMI_RH_HIERARCHY;
+
+// Table 47 -- TPMI_RH_HIERARCHY_AUTH Type <I>
+typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
+
+// Table 48 -- TPMI_RH_PLATFORM Type <I>
+typedef TPM_HANDLE TPMI_RH_PLATFORM;
+
+// Table 49 -- TPMI_RH_OWNER Type <I>
+typedef TPM_HANDLE TPMI_RH_OWNER;
+
+// Table 50 -- TPMI_RH_ENDORSEMENT Type <I>
+typedef TPM_HANDLE TPMI_RH_ENDORSEMENT;
+
+// Table 51 -- TPMI_RH_PROVISION Type <I>
+typedef TPM_HANDLE TPMI_RH_PROVISION;
+
+// Table 52 -- TPMI_RH_CLEAR Type <I>
+typedef TPM_HANDLE TPMI_RH_CLEAR;
+
+// Table 54 -- TPMI_RH_LOCKOUT Type <I>
+typedef TPM_HANDLE TPMI_RH_LOCKOUT;
+
+// Table 7 -- TPM_ALG_ID
+typedef UINT16 TPM_ALG_ID;
+typedef UINT16 TPM_ALG_ID;
+
+#define    TPM2_ALG_ERROR             (TPM_ALG_ID)(0x0000) // a: ; D:
+#define    TPM2_ALG_FIRST             (TPM_ALG_ID)(0x0001) // a: ; D:
+#if ALG_RSA == YES || ALG_ALL == YES
+#define    TPM2_ALG_RSA               (TPM_ALG_ID)(0x0001) // a: A O; D:
+#endif
+#if ALG_DES == YES || ALG_ALL == YES
+#define    TPM2_ALG_DES               (TPM_ALG_ID)(0x0002) // a: S; D:
+#endif
+#define    TPM2_ALG_SHA1              (TPM_ALG_ID)(0x0004) // a: H; D:
+#if ALG_HMAC == YES || ALG_ALL == YES
+#define    TPM2_ALG_HMAC              (TPM_ALG_ID)(0x0005) // a: H X; D:
+#endif
+#if ALG_AES == YES || ALG_ALL == YES
+#define    TPM2_ALG_AES               (TPM_ALG_ID)(0x0006) // a: S; D:
+#endif
+#if ALG_XOR == YES || ALG_ALL == YES
+#define    TPM2_ALG_XOR               (TPM_ALG_ID)(0x000A) // a: H S; D:
+#endif
+#if ALG_MGF1 == YES || ALG_ALL == YES
+#define    TPM2_ALG_MGF1              (TPM_ALG_ID)(0x0007) // a: H M; D:
+#endif
+#if ALG_KEYEDHASH == YES || ALG_ALL == YES
+#define    TPM2_ALG_KEYEDHASH         (TPM_ALG_ID)(0x0008) // a: H E X O; D:
+#endif
+#if ALG_SHA256 == YES || ALG_ALL == YES
+#define    TPM2_ALG_SHA256            (TPM_ALG_ID)(0x000B) // a: H; D:
+#endif
+#define    TPM2_ALG_NULL              (TPM_ALG_ID)(0x0010) // a: ; D:
+#if ALG_OAEP == YES || ALG_ALL == YES
+#define    TPM2_ALG_OAEP              (TPM_ALG_ID)(0x0017) // a: A E; D: RSA
+#endif
+#if ALG_ECC == YES || ALG_ALL == YES
+#define    TPM2_ALG_ECC               (TPM_ALG_ID)(0x0023) // a: A O; D:
+#endif
+#if ALG_SM4 == YES || ALG_ALL == YES
+#define    TPM2_ALG_SM4               (TPM_ALG_ID)(0x0013) // a: S; D:
+#endif
+#if ALG_SYMCIPHER == YES || ALG_ALL == YES
+#define    TPM2_ALG_SYMCIPHER         (TPM_ALG_ID)(0x0025) // a: O; D:
+#endif
+#if ALG_CFB == YES || ALG_ALL == YES
+#define    TPM2_ALG_CFB               (TPM_ALG_ID)(0x0043) // a: S E; D:
+#endif
+#define    TPM2_ALG_LAST              (TPM_ALG_ID)(0x0044)
+
+#define    SHA1_DIGEST_SIZE      20
+#define    SHA1_BLOCK_SIZE       64
+#define    SHA256_DIGEST_SIZE    32
+#define    SHA256_BLOCK_SIZE     64
+
+// Table 57 -- TPMI_ALG_ASYM Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_ASYM;
+
+// Table 56 -- TPMI_ALG_HASH Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_HASH;
+
+// Table 58 -- TPMI_ALG_SYM Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM;
+
+// Table 59 -- TPMI_ALG_SYM_OBJECT Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM_OBJECT;
+
+// Table 60 -- TPMI_ALG_SYM_MODE Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM_MODE;
+
+// Table 61 -- TPMI_ALG_KDF Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_KDF;
+
+// Table 62 -- TPMI_ALG_SIG_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SIG_SCHEME;
+
+// Table 65 -- TPMU_HA Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_SHA1
+    BYTE  sha1[SHA1_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA256
+    BYTE  sha256[SHA256_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SM3_256
+    BYTE  sm3_256[SM3_256_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA384
+    BYTE  sha384[SHA384_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA512
+    BYTE  sha512[SHA512_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_WHIRLPOOL512
+    BYTE  whirlpool[WHIRLPOOL512_DIGEST_SIZE];
+#endif
+
+} TPMU_HA;
+
+// Table 67 -- TPM2B_DIGEST Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[sizeof(TPMU_HA)];
+} TPM2B_DIGEST;
+
+// Table 69 -- TPM2B_NONCE Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_NONCE;
+
+typedef TPM2B_DIGEST    TPM2B_DATA;
+
+// Table 70 -- TPM2B_AUTH Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_AUTH;
+
+// Table 71 -- TPM2B_OPERAND Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_OPERAND;
+
+// Table 66 -- TPMT_HA Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    TPMU_HA          digest;
+} TPMT_HA;
+
+//Table 80 -- TPM2B_NAME Structure
+typedef struct {
+    UINT16 size;
+    BYTE name[sizeof(TPMT_HA)];
+} TPM2B_NAME;
+
+#define    IMPLEMENTATION_PCR   24
+#define    PLATFORM_PCR         24
+#define    PCR_SELECT_MAX       ((IMPLEMENTATION_PCR+7)/8)
+
+//Table 79 -- TPMS_PCR_SELECT Structure <I/O>
+typedef struct {
+    UINT8    sizeofSelect;
+    BYTE     pcrSelect[PCR_SELECT_MAX];
+} TPMS_PCR_SELECT;
+
+// Table 80 -- TPMS_PCR_SELECTION Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hash;
+    UINT8            sizeofSelect;
+    BYTE             pcrSelect[PCR_SELECT_MAX];
+} TPMS_PCR_SELECTION;
+
+// Table 83 -- TPMT_TK_CREATION Structure <I/O>
+typedef struct {
+    TPM_ST               tag;
+    TPMI_RH_HIERARCHY    hierarchy;
+    TPM2B_DIGEST         digest;
+} TPMT_TK_CREATION;
+
+// Table 96 -- Definition of TPML_DIGEST Structure <I/O>
+typedef struct {
+    UINT32               count;
+    TPM2B_DIGEST         digests[8];
+}TPML_DIGEST;
+
+// Table 97 -- TPML_PCR_SELECTION Structure <I/O>
+typedef struct {
+    UINT32                count;
+    TPMS_PCR_SELECTION    pcrSelections[HASH_COUNT];
+} TPML_PCR_SELECTION;
+
+// Table 119 -- TPMI_AES_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_AES_KEY_BITS;
+
+// Table 120 -- TPMI_SM4_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_SM4_KEY_BITS;
+
+// Table 121 -- TPMU_SYM_KEY_BITS Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_AES
+    TPMI_AES_KEY_BITS  aes;
+#endif
+#ifdef TPM2_ALG_SM4
+    TPMI_SM4_KEY_BITS  SM4;
+#endif
+    TPM_KEY_BITS  sym;
+#ifdef TPM2_ALG_XOR
+    TPMI_ALG_HASH  xor;
+#endif
+
+} TPMU_SYM_KEY_BITS;
+
+// Table 122 -- TPMU_SYM_MODE Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_AES
+    TPMI_ALG_SYM_MODE  aes;
+#endif
+#ifdef TPM2_ALG_SM4
+    TPMI_ALG_SYM_MODE  SM4;
+#endif
+    TPMI_ALG_SYM_MODE  sym;
+} TPMU_SYM_MODE ;
+
+// Table 124 -- TPMT_SYM_DEF Structure <I/O>
+typedef struct {
+    TPMI_ALG_SYM         algorithm;
+    TPMU_SYM_KEY_BITS    keyBits;
+    TPMU_SYM_MODE        mode;
+} TPMT_SYM_DEF;
+
+// Table 125 -- TPMT_SYM_DEF_OBJECT Structure <I/O>
+typedef struct {
+    TPMI_ALG_SYM_OBJECT    algorithm;
+    TPMU_SYM_KEY_BITS      keyBits;
+    TPMU_SYM_MODE          mode;
+} TPMT_SYM_DEF_OBJECT;
+
+// Table 126 -- TPM2B_SYM_KEY Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_SYM_KEY_BYTES];
+} TPM2B_SYM_KEY;
+
+// Table 127 -- TPMS_SYMCIPHER_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    sym;
+} TPMS_SYMCIPHER_PARMS;
+
+// Table 128 -- TPM2B_SENSITIVE_DATA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_SYM_DATA];
+} TPM2B_SENSITIVE_DATA;
+
+// Table 129 -- TPMS_SENSITIVE_CREATE Structure <I>
+typedef struct {
+    TPM2B_AUTH              userAuth;
+    TPM2B_SENSITIVE_DATA    data;
+} TPMS_SENSITIVE_CREATE;
+
+// Table 130 -- TPM2B_SENSITIVE_CREATE Structure <I,S>
+typedef struct {
+    UINT16                   size;
+    TPMS_SENSITIVE_CREATE    sensitive;
+} TPM2B_SENSITIVE_CREATE;
+
+// Table 131 -- TPMS_SCHEME_SIGHASH Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_SIGHASH;
+
+// Table 132 -- TPMI_ALG_KEYEDHASH_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_KEYEDHASH_SCHEME;
+
+// Table 133 -- HMAC_SIG_SCHEME Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_HMAC;
+
+// Table 134 -- TPMS_SCHEME_XOR Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    TPMI_ALG_KDF     kdf;
+} TPMS_SCHEME_XOR;
+
+// Table 135 -- TPMU_SCHEME_KEYEDHASH Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_HMAC
+    TPMS_SCHEME_HMAC  hmac;
+#endif
+#ifdef TPM2_ALG_XOR
+    TPMS_SCHEME_XOR  xor;
+#endif
+
+} TPMU_SCHEME_KEYEDHASH ;
+
+// Table 136 -- TPMT_KEYEDHASH_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_KEYEDHASH_SCHEME    scheme;
+    TPMU_SCHEME_KEYEDHASH        details;
+} TPMT_KEYEDHASH_SCHEME;
+
+// Table 137 -- RSA_SIG_SCHEMES Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_RSASSA;
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_RSAPSS;
+
+// Table 138 -- ECC_SIG_SCHEMES Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_ECDSA;
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_SM2;
+
+// Table 139 -- TPMS_SCHEME_ECDAA Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    UINT16           count;
+} TPMS_SCHEME_ECDAA;
+
+// Table 140 -- TPMS_SCHEME_ECSCHNORR Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    UINT16           count;
+} TPMS_SCHEME_ECSCHNORR;
+
+// Table 141 -- TPMU_SIG_SCHEME Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_RSASSA
+    TPMS_SCHEME_RSASSA  rsassa;
+#endif
+#ifdef TPM2_ALG_RSAPSS
+    TPMS_SCHEME_RSAPSS  rsapss;
+#endif
+#ifdef TPM2_ALG_ECDSA
+    TPMS_SCHEME_ECDSA  ecdsa;
+#endif
+#ifdef TPM2_ALG_SM2
+    TPMS_SCHEME_SM2  sm2;
+#endif
+#ifdef TPM2_ALG_ECDAA
+    TPMS_SCHEME_ECDAA  ecdaa;
+#endif
+#ifdef TPM2_ALG_ECSCHNORR
+    TPMS_SCHEME_ECSCHNORR  ecSchnorr;
+#endif
+#ifdef TPM2_ALG_HMAC
+    TPMS_SCHEME_HMAC  hmac;
+#endif
+    TPMS_SCHEME_SIGHASH  any;
+} TPMU_SIG_SCHEME;
+
+// Table 142 -- TPMT_SIG_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_SIG_SCHEME    scheme;
+    TPMU_SIG_SCHEME        details;
+} TPMT_SIG_SCHEME;
+
+// Table 143 -- TPMS_SCHEME_OAEP Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_OAEP;
+
+// Table 144 -- TPMS_SCHEME_ECDH Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_ECDH;
+
+// Table 145 -- TPMS_SCHEME_MGF1 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_MGF1;
+
+// Table 146 -- TPMS_SCHEME_KDF1_SP800_56a Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF1_SP800_56a;
+
+// Table 147 -- TPMS_SCHEME_KDF2 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF2;
+
+// Table 148 -- TPMS_SCHEME_KDF1_SP800_108 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF1_SP800_108;
+
+// Table 149 -- TPMU_KDF_SCHEME Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_MGF1
+    TPMS_SCHEME_MGF1  mgf1;
+#endif
+#ifdef TPM2_ALG_KDF1_SP800_56a
+    TPMS_SCHEME_KDF1_SP800_56a  kdf1_SP800_56a;
+#endif
+#ifdef TPM2_ALG_KDF2
+    TPMS_SCHEME_KDF2  kdf2;
+#endif
+#ifdef TPM2_ALG_KDF1_SP800_108
+    TPMS_SCHEME_KDF1_SP800_108  kdf1_sp800_108;
+#endif
+
+} TPMU_KDF_SCHEME;
+
+// Table 150 -- TPMT_KDF_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_KDF       scheme;
+    TPMU_KDF_SCHEME    details;
+} TPMT_KDF_SCHEME;
+typedef TPM_ALG_ID TPMI_ALG_ASYM_SCHEME;
+
+// Table 152 -- TPMU_ASYM_SCHEME Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_RSASSA
+    TPMS_SCHEME_RSASSA  rsassa;
+#endif
+#ifdef TPM2_ALG_RSAPSS
+    TPMS_SCHEME_RSAPSS  rsapss;
+#endif
+#ifdef TPM2_ALG_OAEP
+    TPMS_SCHEME_OAEP  oaep;
+#endif
+#ifdef TPM2_ALG_ECDSA
+    TPMS_SCHEME_ECDSA  ecdsa;
+#endif
+#ifdef TPM2_ALG_SM2
+    TPMS_SCHEME_SM2  sm2;
+#endif
+#ifdef TPM2_ALG_ECDAA
+    TPMS_SCHEME_ECDAA  ecdaa;
+#endif
+#ifdef TPM2_ALG_ECSCHNORR
+    TPMS_SCHEME_ECSCHNORR  ecSchnorr;
+#endif
+    TPMS_SCHEME_SIGHASH  anySig;
+} TPMU_ASYM_SCHEME;
+
+typedef struct {
+    TPMI_ALG_ASYM_SCHEME    scheme;
+    TPMU_ASYM_SCHEME        details;
+} TPMT_ASYM_SCHEME;
+
+// Table 154 -- TPMI_ALG_RSA_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_RSA_SCHEME;
+
+// Table 155 -- TPMT_RSA_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_RSA_SCHEME    scheme;
+    TPMU_ASYM_SCHEME       details;
+} TPMT_RSA_SCHEME;
+
+// Table 156 -- TPMI_ALG_RSA_DECRYPT Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_RSA_DECRYPT;
+
+// Table 157 -- TPMT_RSA_DECRYPT Structure <I/O>
+typedef struct {
+    TPMI_ALG_RSA_DECRYPT    scheme;
+    TPMU_ASYM_SCHEME        details;
+} TPMT_RSA_DECRYPT;
+
+// Table 158 -- TPM2B_PUBLIC_KEY_RSA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_RSA_KEY_BYTES];
+} TPM2B_PUBLIC_KEY_RSA;
+
+// Table 159 -- TPMI_RSA_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_RSA_KEY_BITS;
+
+// Table 160 -- TPM2B_PRIVATE_KEY_RSA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_RSA_KEY_BYTES/2];
+} TPM2B_PRIVATE_KEY_RSA;
+
+// Table 162 -- TPM2B_ECC_PARAMETER
+typedef struct {
+    UINT16 size;
+    BYTE buffer[MAX_ECC_KEY_BYTES];
+} TPM2B_ECC_PARAMETER;
+
+// Table 163 -- TPMS_ECC_POINT Structure <I/O>
+typedef struct {
+    TPM2B_ECC_PARAMETER    x;
+    TPM2B_ECC_PARAMETER    y;
+} TPMS_ECC_POINT;
+
+// Table 164 -- TPMI_ALG_ECC_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_ECC_SCHEME;
+
+typedef UINT16 TPM_ECC_CURVE;
+
+// Table 165 -- TPMI_ECC_CURVE Type <I/O>
+typedef TPM_ECC_CURVE TPMI_ECC_CURVE;
+
+// Table 166 -- TPMT_ECC_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_ECC_SCHEME    scheme;
+    TPMU_SIG_SCHEME        details;
+} TPMT_ECC_SCHEME;
+
+// Table 175 -- TPMI_ALG_PUBLIC Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_PUBLIC;
+
+// Table 176 -- TPMU_PUBLIC_ID Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_KEYEDHASH
+    TPM2B_DIGEST  keyedHash;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPM2B_DIGEST  sym;
+#endif
+#ifdef TPM2_ALG_RSA
+    TPM2B_PUBLIC_KEY_RSA  rsa;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPMS_ECC_POINT  ecc;
+#endif
+} TPMU_PUBLIC_ID;
+
+// Table 177 -- TPMS_KEYEDHASH_PARMS Structure <I/O>
+typedef struct {
+    TPMT_KEYEDHASH_SCHEME    scheme;
+} TPMS_KEYEDHASH_PARMS;
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_ASYM_SCHEME       scheme;
+} TPMS_ASYM_PARMS;
+
+// Table 179 -- TPMS_RSA_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_RSA_SCHEME        scheme;
+    TPMI_RSA_KEY_BITS      keyBits;
+    UINT32                 exponent;
+} TPMS_RSA_PARMS;
+
+// Table 180 -- TPMS_ECC_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_ECC_SCHEME        scheme;
+    TPMI_ECC_CURVE         curveID;
+    TPMT_KDF_SCHEME        kdf;
+} TPMS_ECC_PARMS;
+
+// Table 181 -- TPMU_PUBLIC_PARMS Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_KEYEDHASH
+    TPMS_KEYEDHASH_PARMS  keyedHashDetail;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPMT_SYM_DEF_OBJECT  symDetail;
+#endif
+#ifdef TPM2_ALG_RSA
+    TPMS_RSA_PARMS  rsaDetail;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPMS_ECC_PARMS  eccDetail;
+#endif
+    TPMS_ASYM_PARMS  asymDetail;
+} TPMU_PUBLIC_PARMS;
+
+// Table 182 -- TPMT_PUBLIC_PARMS Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC      type;
+    TPMU_PUBLIC_PARMS    parameters;
+} TPMT_PUBLIC_PARMS;
+
+// Table 183 -- TPMT_PUBLIC Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC      type;
+    TPMI_ALG_HASH        nameAlg;
+    TPMA_OBJECT          objectAttributes;
+    TPM2B_DIGEST         authPolicy;
+    TPMU_PUBLIC_PARMS    parameters;
+    TPMU_PUBLIC_ID       unique;
+} TPMT_PUBLIC;
+
+// Table 184 -- TPM2B_PUBLIC
+typedef struct {
+    UINT16         size;
+    TPMT_PUBLIC    publicArea;
+} TPM2B_PUBLIC;
+
+// Table 185 -- TPMU_SENSITIVE_COMPOSITE Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_RSA
+    TPM2B_PRIVATE_KEY_RSA  rsa;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPM2B_ECC_PARAMETER  ecc;
+#endif
+#ifdef TPM2_ALG_KEYEDHASH
+    TPM2B_SENSITIVE_DATA  bits;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPM2B_SYM_KEY  sym;
+#endif
+    TPM2B_SENSITIVE_DATA  any;
+} TPMU_SENSITIVE_COMPOSITE;
+
+// Table 186 -- TPMT_SENSITIVE Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC             sensitiveType;
+    TPM2B_AUTH                  authValue;
+    TPM2B_DIGEST                seedValue;
+    TPMU_SENSITIVE_COMPOSITE    sensitive;
+} TPMT_SENSITIVE;
+
+// Table 187 -- TPM2B_SENSITIVE Structure <I/O>
+typedef struct {
+    UINT16            size;
+    TPMT_SENSITIVE    sensitiveArea;
+} TPM2B_SENSITIVE;
+
+typedef struct {
+    TPM2B_DIGEST      integrityOuter;
+    TPM2B_DIGEST      integrityInner;
+    TPMT_SENSITIVE    sensitive;
+} _PRIVATE;
+
+// Table 189 -- TPM2B_PRIVATE Structure <I/O,S>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[sizeof(_PRIVATE)];
+} TPM2B_PRIVATE;
+
+// Table 204 -- TPMS_CREATION_DATA <OUT>
+typedef struct {
+    TPML_PCR_SELECTION    pcrSelect;
+    TPM2B_DIGEST          pcrDigest;
+    TPMA_LOCALITY         locality;
+    TPM_ALG_ID            parentNameAlg;
+    TPM2B_NAME            parentName;
+    TPM2B_NAME            parentQualifiedName;
+    TPM2B_DATA            outsideInfo;
+} TPMS_CREATION_DATA;
+
+// Table 205 -- TPM2B_CREATION_DATA <OUT>
+typedef struct {
+    UINT16 size;
+    TPMS_CREATION_DATA creationData;
+} TPM2B_CREATION_DATA;
+
+/* the following structs is not part of standard struct defined in TPM2 spec */
+typedef struct {
+    UINT32            size;
+    TPM_RH            sessionHandle;
+    TPM2B_NONCE       nonce;
+    TPMA_SESSION      sessionAttributes;
+    TPM2B_AUTH        auth;
+} TPM_AuthArea;
+
+typedef struct {
+    TPM2B_SENSITIVE_CREATE  inSensitive;
+    TPM2B_PUBLIC            inPublic;
+    TPM2B_DATA              outsideInfo;
+    TPML_PCR_SELECTION      creationPCR;
+} TPM2_Create_Params_in;
+
+typedef TPM2_Create_Params_in    TPM2_CreatePrimary_Params_in;
+
+typedef struct {
+    TPM2B_PUBLIC        outPublic;
+    TPM2B_CREATION_DATA creationData;
+    TPM2B_DIGEST        creationHash;
+    TPMT_TK_CREATION    creationTicket;
+    TPM2B_NAME          name;
+} TPM2_CreatePrimary_Params_out;
+
+typedef struct {
+    TPM2B_PRIVATE       outPrivate;
+    TPM2B_PUBLIC        outPublic;
+    TPM2B_CREATION_DATA creationData;
+    TPM2B_DIGEST        creationHash;
+    TPMT_TK_CREATION    creationTicket;
+} TPM2_Create_Params_out;
+typedef struct {
+    TPM2B_PRIVATE    Private;
+    TPM2B_PUBLIC     Public;
+} TPM2_RSA_KEY;
+
+/*
+ * TPM 2.0 Objects
+ */
+
+#define TPM_HT_TRANSIENT        0x80
+#define HR_SHIFT                24
+#define HR_PERMANENT            (TPM_HT_TRANSIENT << HR_SHIFT)
+#define TRANSIENT_FIRST         (HR_PERMANENT)
+#define MAX_LOADED_OBJECTS      3
+#define TRANSIENT_LAST          (TRANSIENT_FIRST+MAX_LOADED_OBJECTS-1)
+/*
+ * TPMA_OBJECT Bits
+ */
+#define fixedTPM                ((1 << 1))
+#define stClear                 ((1 << 2))
+#define fixedParent             ((1 << 4))
+#define sensitiveDataOrigin     ((1 << 5))
+#define userWithAuth            ((1 << 6))
+#define adminWithPolicy         ((1 << 7))
+#define noDA                    ((1 << 10))
+#define encryptedDuplication    ((1 << 11))
+#define restricted              ((1 << 16))
+#define decrypt                 ((1 << 17))
+#define sign                    ((1 << 18))
+#endif
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnT-0007a5-Ix; Sun, 14 Dec 2014 16:13:27 +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 1Y0BnR-0007Zi-Mb
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:25 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	BE/B1-22819-427BD845; Sun, 14 Dec 2014 16:13:24 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418573602!13228416!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19280 invoked from network); 14 Dec 2014 16:13:23 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-206.messagelabs.com with SMTP;
	14 Dec 2014 16:13:23 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 14 Dec 2014 08:13:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="428810486"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 14 Dec 2014 08:02:23 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:38 -0500
Message-Id: <1418558978-13492-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 04/12] vTPM/TPM2: Add TPM 2.0 Exposed APIs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 TPM 2.0 Exposed APIs for the Mini-os to access TPM 2.0
hardware.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/Makefile |   2 +-
 stubdom/vtpmmgr/tpm2.c   | 455 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2.h   | 104 +++++++++++
 3 files changed, 560 insertions(+), 1 deletion(-)
 create mode 100644 stubdom/vtpmmgr/tpm2.c
 create mode 100644 stubdom/vtpmmgr/tpm2.h

diff --git a/stubdom/vtpmmgr/Makefile b/stubdom/vtpmmgr/Makefile
index c5e17c5..6dae034 100644
--- a/stubdom/vtpmmgr/Makefile
+++ b/stubdom/vtpmmgr/Makefile
@@ -12,7 +12,7 @@
 XEN_ROOT=../..
 
 TARGET=vtpmmgr.a
-OBJS=vtpmmgr.o vtpm_cmd_handler.o init.o tpmrsa.o tpm.o log.o
+OBJS=vtpmmgr.o vtpm_cmd_handler.o init.o tpmrsa.o tpm.o tpm2.o log.o
 OBJS += vtpm_disk.o disk_tpm.o disk_io.o disk_crypto.o disk_read.o disk_write.o
 OBJS += mgmt_authority.o
 
diff --git a/stubdom/vtpmmgr/tpm2.c b/stubdom/vtpmmgr/tpm2.c
new file mode 100644
index 0000000..1903e27
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2.c
@@ -0,0 +1,455 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005/2006, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#include <stdio.h>
+#include <string.h>
+#include <malloc.h>
+#include <unistd.h>
+#include <errno.h>
+#include <polarssl/sha1.h>
+
+#include "tcg.h"
+#include "tpm.h"
+#include "tpm2.h"
+#include "log.h"
+#include "marshal.h"
+#include "tpm2_marshal.h"
+#include "tpmrsa.h"
+#include "vtpmmgr.h"
+
+#define TCPA_MAX_BUFFER_LENGTH 0x2000
+#define TPM_BEGIN(TAG, ORD) \
+    const TPM_TAG intag = TAG;\
+    TPM_TAG tag = intag;\
+    UINT32 paramSize;\
+    const TPM_COMMAND_CODE ordinal = ORD;\
+    TPM_RESULT status = TPM_SUCCESS;\
+    BYTE in_buf[TCPA_MAX_BUFFER_LENGTH];\
+    BYTE out_buf[TCPA_MAX_BUFFER_LENGTH];\
+    UINT32 out_len = sizeof(out_buf);\
+    BYTE* ptr = in_buf;\
+    /*Print a log message */\
+    vtpmloginfo(VTPM_LOG_TPM, "%s\n", __func__);\
+    /* Pack the header*/\
+    ptr = pack_TPM_TAG(ptr, tag);\
+    ptr += sizeof(UINT32);\
+    ptr = pack_TPM_COMMAND_CODE(ptr, ordinal)\
+
+#define TPM_AUTH_BEGIN() \
+    sha1_context sha1_ctx;\
+    BYTE* authbase = ptr - sizeof(TPM_COMMAND_CODE);\
+    TPM_DIGEST paramDigest;\
+    sha1_starts(&sha1_ctx)
+
+#define TPM_AUTH1_GEN(HMACkey, auth) do {\
+    sha1_finish(&sha1_ctx, paramDigest.digest);\
+    generateAuth(&paramDigest, HMACkey, auth);\
+    ptr = pack_TPM_AUTH_SESSION(ptr, auth);\
+} while(0)
+
+#define TPM_AUTH2_GEN(HMACkey, auth) do {\
+    generateAuth(&paramDigest, HMACkey, auth);\
+    ptr = pack_TPM_AUTH_SESSION(ptr, auth);\
+} while(0)
+
+#define TPM_TRANSMIT() do {\
+    /* Pack the command size */\
+    paramSize = ptr - in_buf;\
+    pack_UINT32(in_buf + sizeof(TPM_TAG), paramSize);\
+    if ((status = TPM_TransmitData(in_buf, paramSize, out_buf, &out_len)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH_VERIFY_BEGIN() do {\
+    UINT32 buf[2] = { cpu_to_be32(status), cpu_to_be32(ordinal) };\
+    sha1_starts(&sha1_ctx);\
+    sha1_update(&sha1_ctx, (unsigned char*)buf, sizeof(buf));\
+    authbase = ptr;\
+} while(0)
+
+#define TPM_AUTH1_VERIFY(HMACkey, auth) do {\
+    sha1_finish(&sha1_ctx, paramDigest.digest);\
+    ptr = unpack_TPM_AUTH_SESSION(ptr, auth);\
+    if ((status = verifyAuth(&paramDigest, HMACkey, auth)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH2_VERIFY(HMACkey, auth) do {\
+    ptr = unpack_TPM_AUTH_SESSION(ptr, auth);\
+    if ((status = verifyAuth(&paramDigest, HMACkey, auth)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_UNPACK_VERIFY() do { \
+    ptr = out_buf;\
+    ptr = unpack_TPM_RSP_HEADER(ptr, \
+          &(tag), &(paramSize), &(status));\
+    if ((status) != TPM_SUCCESS){ \
+        vtpmlogerror(VTPM_LOG_TPM, "Failed with return code %s\n", tpm_get_error_name(status));\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH_HASH() do {\
+    sha1_update(&sha1_ctx, authbase, ptr - authbase);\
+    authbase = ptr;\
+} while(0)
+
+#define TPM_AUTH_SKIP() do {\
+    authbase = ptr;\
+} while(0)
+
+TPM_RC TPM2_PCR_Read(TPML_PCR_SELECTION pcrSelectionIn,
+                     UINT32 *pcrUpdateCounter,
+                     TPML_PCR_SELECTION *pcrSelectionOut,
+                     TPML_DIGEST *pcrValues)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS,TPM_CC_PCR_Read);
+
+    /*pack in*/
+    ptr =  pack_TPML_PCR_SELECTION(ptr, &pcrSelectionIn);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    /*unpack out*/
+    ptr = unpack_UINT32(ptr, pcrUpdateCounter);
+    ptr = unpack_TPML_PCR_SELECTION(ptr, pcrSelectionOut);
+    ptr = unpack_TPML_DIGEST(ptr, pcrValues);
+
+    goto egress;
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_Load(TPMI_DH_OBJECT parentHandle,
+                 TPM2B_PRIVATE *inPrivate, /* in */
+                 TPM2B_PUBLIC *inPublic, /* in */
+                 TPM_HANDLE *objectHandle, /* out */
+                 TPM2B_NAME *name /* out */)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Load);
+
+    /* pack handle of parent for new object */
+    ptr =  pack_UINT32(ptr, parentHandle);
+
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+    ptr = pack_TPM2B_PRIVATE(ptr, inPrivate);
+    ptr = pack_TPM2B_PUBLIC(ptr, inPublic);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    if (objectHandle != NULL) {
+        ptr = unpack_TPM_HANDLE(ptr, objectHandle);
+    } else {
+        TPM_HANDLE tmp;
+        ptr = unpack_TPM_HANDLE(ptr, &tmp);
+    }
+
+    if (name != NULL)
+        ptr = unpack_TPM2B_NAME(ptr, name);
+    goto egress;
+
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_Create(TPMI_DH_OBJECT parentHandle,
+                   TPM2_Create_Params_in *in,
+                   TPM2_Create_Params_out *out)
+{
+    UINT32 param_size;
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Create);
+
+    /* pack handle of parent for new object */
+    ptr =  pack_UINT32(ptr, parentHandle);
+
+    /* pack Auth Area */
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+
+    /* pack inSensitive */
+    ptr = pack_TPM2B_SENSITIVE_CREATE(ptr, &in->inSensitive);
+
+    /* pack inPublic */
+    ptr = pack_TPM2B_PUBLIC(ptr, &in->inPublic);
+
+    /* pack outside Info */
+    ptr = pack_TPM2B_DATA(ptr, &in->outsideInfo);
+
+    /* pack createPCR */
+    ptr = pack_TPML_PCR_SELECTION(ptr, &in->creationPCR);
+
+    /* Send the command to the tpm */
+    TPM_TRANSMIT();
+
+    /* Unpack and validate the header */
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT32(ptr, &param_size);
+    if (out != NULL) {
+        ptr = unpack_TPM2B_PRIVATE(ptr, &vtpm_globals.tpm2_storage_key.Private);
+        ptr = unpack_TPM2B_PUBLIC(ptr, &vtpm_globals.tpm2_storage_key.Public);
+        ptr = unpack_TPM2B_CREATION_DATA(ptr, &out->creationData);
+        ptr = unpack_TPM2B_DIGEST(ptr, &out->creationHash);
+        ptr = unpack_TPMT_TK_CREATION(ptr, &out->creationTicket);
+    } else {
+           ptr += param_size;
+    }
+    goto egress;
+
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_CreatePrimary(TPMI_RH_HIERARCHY primaryHandle,
+                          TPM2_Create_Params_in *in,
+                          TPM_HANDLE *objHandle,
+                          TPM2_Create_Params_out *out)
+{
+    UINT32 param_size;
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_CreatePrimary);
+
+    /* pack primary handle */
+    ptr = pack_UINT32(ptr, primaryHandle);
+
+    /* pack Auth Area */
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+
+    /* pack inSenstive */
+    ptr = pack_TPM2B_SENSITIVE_CREATE(ptr, &in->inSensitive);
+
+    /* pack inPublic */
+    ptr = pack_TPM2B_PUBLIC(ptr, &in->inPublic);
+
+    /* pack outsideInfo */
+    ptr = pack_TPM2B_DATA(ptr, &in->outsideInfo);
+
+    /* pack creationPCR */
+    ptr = pack_TPML_PCR_SELECTION(ptr, &in->creationPCR);
+
+    /* Send the command to the tpm */
+    TPM_TRANSMIT();
+
+    /* Unpack and validate the header */
+    TPM_UNPACK_VERIFY();
+
+    if (objHandle != NULL)
+        ptr = unpack_TPM_HANDLE(ptr, objHandle);
+    else {
+        TPM_HANDLE handle;
+        ptr = unpack_TPM_HANDLE(ptr, &handle);
+    }
+    ptr = unpack_UINT32(ptr, &param_size);
+
+    if (out != NULL) {
+        ptr = unpack_TPM2B_PUBLIC(ptr, &out->outPublic);
+        ptr = unpack_TPM2B_CREATION_DATA(ptr, &out->creationData);
+        ptr = unpack_TPM2B_DIGEST(ptr, &out->creationHash);
+        ptr = unpack_TPMT_TK_CREATION(ptr, &out->creationTicket);
+    } else {
+        ptr += param_size;
+    }
+
+goto egress;
+
+abort_egress:
+egress:
+   return status;
+}
+
+TPM_RC TPM2_HierachyChangeAuth(TPMI_RH_HIERARCHY_AUTH authHandle, TPM2B_AUTH *newAuth)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_HierarchyChangeAuth);
+    ptr = pack_UINT32(ptr, authHandle);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+    ptr = pack_TPM2B_AUTH(ptr, newAuth);
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_RSA_ENCRYPT(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *message,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *outData)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_RSA_Encrypt);
+
+    ptr = pack_UINT32(ptr, keyHandle);
+    ptr = pack_TPM2B_PUBLIC_KEY_RSA(ptr, message);
+    ptr = pack_TPMT_RSA_DECRYPT(ptr, inScheme);
+    ptr = pack_TPM2B_DATA(ptr, label);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    if (outData != NULL)
+        unpack_TPM2B_PUBLIC_KEY_RSA(ptr, outData);
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_Bind(TPMI_DH_OBJECT keyHandle,
+                 void *buf,
+                 UINT32 len,
+                 void *out)
+{
+    TPM_RC status = TPM_SUCCESS;
+    TPM2B_PUBLIC_KEY_RSA message;
+    TPMT_RSA_DECRYPT inScheme;
+    TPM2B_DATA label;
+    TPM2B_PUBLIC_KEY_RSA outData;
+
+    message.size = len;
+    memcpy(message.buffer, buf, len);
+    inScheme.scheme = TPM2_ALG_NULL;
+    label.size = 0;
+    TPMTRYRETURN(TPM2_RSA_ENCRYPT(keyHandle, &message, &inScheme, &label, &outData));
+    memcpy(out, outData.buffer, outData.size);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_RSA_Decrypt(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *cipherText,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *message)
+{
+    UINT32 param_size;
+
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_RSA_Decrypt);
+    ptr = pack_UINT32(ptr, keyHandle);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+    ptr = pack_TPM2B_PUBLIC_KEY_RSA(ptr, cipherText);
+    ptr = pack_TPMT_RSA_DECRYPT(ptr, inScheme);
+    ptr = pack_TPM2B_DATA(ptr, label);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT32(ptr, &param_size);
+
+    if (message)
+        ptr = unpack_TPM2B_PUBLIC_KEY_RSA(ptr, message);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_UnBind(TPMI_DH_OBJECT keyHandle,
+                   UINT32 ilen,
+                   void *in,
+                   UINT32 *olen,
+                   void *out)
+{
+    UINT32 status;
+    TPM2B_PUBLIC_KEY_RSA cipher, message;
+    TPMT_RSA_DECRYPT inScheme;
+    TPM2B_DATA label;
+
+    cipher.size = ilen;
+    memcpy(cipher.buffer, in, ilen);
+    inScheme.scheme = TPM2_ALG_NULL;
+    label.size = 0;
+
+    TPMTRYRETURN(TPM2_RSA_Decrypt(keyHandle, &cipher, &inScheme, &label, &message));
+
+    *olen = message.size;
+    memcpy(out, message.buffer, *olen);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_CLEAR(void)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Clear);
+
+    ptr = pack_UINT32(ptr, TPM_RH_PLATFORM);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_GetRandom(UINT32 * bytesRequested, BYTE * randomBytes)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_GetRandom);
+
+    ptr = pack_UINT16(ptr, (UINT16)*bytesRequested);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT16(ptr, (UINT16 *)bytesRequested);
+    ptr = unpack_TPM_BUFFER(ptr, randomBytes, *bytesRequested);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_FlushContext(TPMI_DH_CONTEXT flushHandle)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_FlushContext);
+
+    ptr = pack_UINT32(ptr, flushHandle);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/tpm2.h b/stubdom/vtpmmgr/tpm2.h
new file mode 100644
index 0000000..9f597ee
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2.h
@@ -0,0 +1,104 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005/2006, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef __TPM2_H__
+#define __TPM2_H__
+
+#include "tcg.h"
+#include "tpm2_types.h"
+
+// ------------------------------------------------------------------
+// TPM 2.0 Exposed API
+// ------------------------------------------------------------------
+
+TPM_RC TPM2_PCR_Read(TPML_PCR_SELECTION pcrSelectionIn,
+                     UINT32 *pcrUpdateCounter,
+                     TPML_PCR_SELECTION *pcrSelectionOut,
+                     TPML_DIGEST *pcrValues);
+
+TPM_RC TPM2_Load(TPMI_DH_OBJECT parentHandle,
+                 TPM2B_PRIVATE *inPrivate,
+                 TPM2B_PUBLIC *inPublic,
+                 TPM_HANDLE *objectHandle,
+                 TPM2B_NAME *name);
+
+TPM_RC TPM2_Create(TPMI_DH_OBJECT parentHandle,
+                   TPM2_Create_Params_in *in,
+                   TPM2_Create_Params_out *out);
+
+TPM_RC TPM2_CreatePrimary(TPMI_RH_HIERARCHY primaryHandle,
+                          TPM2_Create_Params_in *objHandle,
+                          TPM_HANDLE *in,
+                          TPM2_Create_Params_out *out);
+
+TPM_RC TPM2_HierachyChangeAuth(TPMI_RH_HIERARCHY_AUTH authHandle,
+                               TPM2B_AUTH *newAuth);
+
+TPM_RC TPM2_RSA_ENCRYPT(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *message,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *outData);
+
+TPM_RC TPM2_Bind(TPMI_DH_OBJECT keyHandle,
+                 void *buf,
+                 UINT32 len,
+                 void *out);
+
+TPM_RC TPM2_RSA_Decrypt(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *cipherText,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *message);
+
+TPM_RC TPM2_UnBind(TPMI_DH_OBJECT keyHandle,
+                   UINT32 ilen,
+                   void *in,
+                   UINT32 *olen,
+                   void *out);
+
+TPM_RESULT TPM2_GetRandom(UINT32* bytesRequested,
+                          BYTE* randomBytes);
+
+TPM_RC TPM2_CLEAR(void);
+
+TPM_RC TPM2_FlushContext(TPMI_DH_CONTEXT);
+#endif //TPM2_H
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnQ-0007ZJ-6P; Sun, 14 Dec 2014 16:13:24 +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 1Y0BnO-0007YQ-5c
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:22 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	B2/B0-03148-127BD845; Sun, 14 Dec 2014 16:13:21 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418573600!10323191!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31789 invoked from network); 14 Dec 2014 16:13:20 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-27.messagelabs.com with SMTP;
	14 Dec 2014 16:13:20 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 14 Dec 2014 08:13:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="623611030"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 14 Dec 2014 08:13:17 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:35 -0500
Message-Id: <1418558975-13455-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 03/12] vTPM/TPM2: Add global data in
	vtpm_globals{}
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 data is for the Mini-os to access TPM 2.0 hardware.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/vtpmmgr.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 2d9d153..0d0c604 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -44,6 +44,7 @@
 #include "uuid.h"
 #include "tcg.h"
 #include "vtpm_manager.h"
+#include "tpm2_types.h"
 
 #define RSA_KEY_SIZE 0x0800
 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8)
@@ -59,6 +60,14 @@ struct vtpm_globals {
    ctr_drbg_context    ctr_drbg;
 
    int hw_locality;
+
+    /* TPM 2.0 */
+    TPM_AuthArea       pw_auth;
+    TPM_AuthArea       srk_auth_area;
+    TPM_HANDLE         srk_handle;
+    TPM_HANDLE         sk_handle;
+    TPM2B_NAME         sk_name;
+    TPM2_RSA_KEY       tpm2_storage_key;
 };
 
 struct tpm_opaque {
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnP-0007Z1-Pv; Sun, 14 Dec 2014 16:13:23 +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 1Y0BnM-0007Y3-8x
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:20 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	55/BB-25276-F17BD845; Sun, 14 Dec 2014 16:13:19 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418573596!15463841!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 18062 invoked from network); 14 Dec 2014 16:13:17 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-21.messagelabs.com with SMTP;
	14 Dec 2014 16:13:17 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2014 08:13:15 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="637398582"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 14 Dec 2014 08:13:14 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:32 -0500
Message-Id: <1418558972-13418-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 02/12] vTPM/TPM2: TPM 2.0 data structures marshal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 TPM 2.0 data structure marshal for packing and unpacking TPM
2.0 data structures.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/tpm2_marshal.h | 673 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 673 insertions(+)
 create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h

diff --git a/stubdom/vtpmmgr/tpm2_marshal.h b/stubdom/vtpmmgr/tpm2_marshal.h
new file mode 100644
index 0000000..aaa4464
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2_marshal.h
@@ -0,0 +1,673 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef TPM2_MARSHAL_H
+#define TPM2_MARSHAL_H
+
+#include <stdlib.h>
+#include <mini-os/byteorder.h>
+#include <mini-os/endian.h>
+#include "tcg.h"
+#include "tpm2_types.h"
+#include <assert.h>
+
+#define pack_TPM_BUFFER(ptr, buf, size) pack_BUFFER(ptr, buf, size)
+#define unpack_TPM_BUFFER(ptr, buf, size) unpack_BUFFER(ptr, buf, size)
+
+inline BYTE* pack_BYTE_ARRAY(BYTE* ptr, const BYTE* array, UINT32 size)
+{
+    int i;
+    for (i = 0; i < size; i++)
+         ptr = pack_BYTE(ptr, array[i]);
+    return ptr;
+}
+
+inline BYTE* pack_TPMA_SESSION(BYTE* ptr, const TPMA_SESSION *attr)
+{
+    return pack_BYTE(ptr, (BYTE)(*attr));
+}
+
+inline BYTE* unpack_TPMA_SESSION(BYTE* ptr, TPMA_SESSION *attr)
+{
+    return unpack_BYTE(ptr, (BYTE *)attr);
+}
+
+inline BYTE* pack_TPMI_ALG_HASH(BYTE* ptr, const TPMI_ALG_HASH *hash)
+{
+    return pack_UINT16(ptr, *hash);
+}
+
+inline BYTE* unpack_TPMI_ALG_HASH(BYTE *ptr, TPMI_ALG_HASH *hash)
+{
+    return unpack_UINT16(ptr, hash);
+}
+
+#define pack_TPMA_OBJECT(ptr, t)                pack_UINT32(ptr, (UINT32)(*t))
+#define unpack_TPMA_OBJECT(ptr, t)              unpack_UINT32(ptr, (UINT32 *)(t))
+#define pack_TPM_RH(ptr, t)                     pack_UINT32(ptr, (UINT32)(*t))
+#define unpack_TPM_RH(ptr, t)                   unpack_UINT32(ptr, (UINT32 *)(t))
+#define pack_TPMA_LOCALITY(ptr, locality)       pack_BYTE(ptr, (BYTE)*locality)
+#define unpack_TPMA_LOCALITY(ptr, locality)     unpack_BYTE(ptr, (BYTE *)locality)
+#define pack_TPM_ST(ptr, tag)                   pack_UINT16(ptr, *tag)
+#define unpack_TPM_ST(ptr, tag)                 unpack_UINT16(ptr, tag)
+#define pack_TPM_KEY_BITS(ptr, t)               pack_UINT16(ptr, *t)
+#define unpack_TPM_KEY_BITS(ptr, t)             unpack_UINT16(ptr, t)
+#define pack_TPMI_AES_KEY_BITS(ptr, t)          pack_TPM_KEY_BITS(ptr, t)
+#define unpack_TPMI_AES_KEY_BITS(ptr, t)        unpack_TPM_KEY_BITS(ptr, t)
+#define pack_TPMI_RSA_KEY_BITS(ptr, t)          pack_TPM_KEY_BITS(ptr, t)
+#define unpack_TPMI_RSA_KEY_BITS(ptr, t)        unpack_TPM_KEY_BITS(ptr, t)
+#define pack_TPM_ALG_ID(ptr, id)                pack_UINT16(ptr, *id)
+#define unpack_TPM_ALG_ID(ptr, id)              unpack_UINT16(ptr, id)
+#define pack_TPM_ALG_SYM(ptr, t)                pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPM_ALG_SYM(ptr, t)              unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_ASYM(ptr, asym)           pack_TPM_ALG_ID(ptr, asym)
+#define unpack_TPMI_ALG_ASYM(ptr, asym)         unpack_TPM_ALG_ID(ptr, asym)
+#define pack_TPMI_ALG_SYM_OBJECT(ptr, t)        pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_SYM_OBJECT(ptr, t)      unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_SYM_MODE(ptr, t)          pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_SYM_MODE(ptr, t)        unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_KDF(ptr, t)               pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_KDF(ptr, t)             unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_PUBLIC(ptr, t)            pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_PUBLIC(ptr, t)          unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPM2_HANDLE(ptr, h)                pack_UINT32(ptr, *h)
+#define unpack_TPM2_HANDLE(ptr, h)              unpack_UINT32(ptr, h)
+#define pack_TPMI_ALG_RSA_SCHEME(ptr, t)        pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_RSA_SCHEME(ptr, t)      unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_DH_OBJECT(ptr, o)             pack_TPM2_HANDLE(ptr, o)
+#define unpack_TPMI_DH_OBJECT(PTR, O)           unpack_TPM2_HANDLE(ptr, o)
+#define pack_TPMI_RH_HIERACHY(ptr, h)           pack_TPM2_HANDLE(ptr, h)
+#define unpack_TPMI_RH_HIERACHY(ptr, h)         unpack_TPM2_HANDLE(ptr, h)
+#define pack_TPMI_RH_PLATFORM(ptr, p)           pack_TPM2_HANDLE(ptr, p)
+#define unpack_TPMI_RH_PLATFORM(ptr, p)         unpack_TPM2_HANDLE(ptr, p)
+#define pack_TPMI_RH_OWNER(ptr, o)              pack_TPM2_HANDLE(ptr, o)
+#define unpack_TPMI_RH_OWNER(ptr, o)            unpack_TPM2_HANDLE(ptr, o)
+#define pack_TPMI_RH_ENDORSEMENT(ptr, e)        pack_TPM2_HANDLE(ptr, e)
+#define unpack_TPMI_RH_ENDORSEMENT(ptr, e)      unpack_TPM2_HANDLE(ptr, e)
+#define pack_TPMI_RH_LOCKOUT(ptr, l)            pack_TPM2_HANDLE(ptr, l)
+#define unpack_TPMI_RH_LOCKOUT(ptr, l)          unpack_TPM2_HANDLE(ptr, l)
+
+inline BYTE* pack_TPM2B_DIGEST(BYTE* ptr, const TPM2B_DIGEST *digest)
+{
+    ptr = pack_UINT16(ptr, digest->size);
+    ptr = pack_BUFFER(ptr, digest->buffer, digest->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_DIGEST(BYTE* ptr, TPM2B_DIGEST *digest)
+{
+    ptr = unpack_UINT16(ptr, &digest->size);
+    ptr = unpack_BUFFER(ptr, digest->buffer, digest->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_TK_CREATION(BYTE* ptr,const TPMT_TK_CREATION *ticket )
+{
+    ptr = pack_TPM_ST(ptr , &ticket->tag);
+    ptr = pack_TPMI_RH_HIERACHY(ptr , &ticket->hierarchy);
+    ptr = pack_TPM2B_DIGEST(ptr, &ticket->digest);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_TK_CREATION(BYTE* ptr, TPMT_TK_CREATION *ticket )
+{
+    ptr = unpack_TPM_ST(ptr, &ticket->tag);
+    ptr = unpack_TPMI_RH_HIERACHY(ptr, &ticket->hierarchy);
+    ptr = unpack_TPM2B_DIGEST(ptr, &ticket->digest);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_NAME(BYTE* ptr,const TPM2B_NAME *name )
+{
+    ptr = pack_UINT16(ptr, name->size);
+    ptr = pack_TPM_BUFFER(ptr, name->name, name->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_NAME(BYTE* ptr, TPM2B_NAME *name)
+{
+    ptr = unpack_UINT16(ptr, &name->size);
+    ptr = unpack_TPM_BUFFER(ptr, name->name, name->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_NONCE(BYTE* ptr, const TPM2B_NONCE *nonce)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)nonce);
+}
+
+#define unpack_TPM2B_NONCE(ptr, nonce)  unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)nonce)
+
+inline BYTE* pack_TPM2B_AUTH(BYTE* ptr, const TPM2B_AUTH *auth)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)auth);
+}
+
+#define unpack_TPM2B_AUTH(ptr, auth)    unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)auth)
+
+inline BYTE* pack_TPM2B_DATA(BYTE* ptr, const TPM2B_DATA *data)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)data);
+}
+
+#define unpack_TPM2B_DATA(ptr, data)    unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)data)
+
+inline BYTE* pack_TPM2B_SENSITIVE_DATA(BYTE* ptr, const TPM2B_SENSITIVE_DATA *data)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)data);
+}
+
+#define unpack_TPM2B_SENSITIVE_DATA(ptr, data)  unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)data)
+
+inline BYTE* pack_TPM2B_PUBLIC_KEY_RSA(BYTE* ptr, const TPM2B_PUBLIC_KEY_RSA *rsa)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)rsa);
+}
+
+#define unpack_TPM2B_PUBLIC_KEY_RSA(ptr, rsa)   unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)rsa)
+
+inline BYTE* pack_TPM2B_PRIVATE(BYTE* ptr, const TPM2B_PRIVATE *Private)
+{
+    ptr = pack_UINT16(ptr, Private->size);
+    ptr = pack_TPM_BUFFER(ptr, Private->buffer, Private->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_PRIVATE(BYTE* ptr, TPM2B_PRIVATE *Private)
+{
+    ptr = unpack_UINT16(ptr, &Private->size);
+    ptr = unpack_BUFFER(ptr, Private->buffer, Private->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION_ARRAY(BYTE* ptr, const TPMS_PCR_SELECTION *sel, UINT32 count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+        ptr = pack_TPMI_ALG_HASH(ptr, &sel[i].hash);
+        ptr = pack_BYTE(ptr, sel[i].sizeofSelect);
+        ptr = pack_BUFFER(ptr, sel[i].pcrSelect, sel[i].sizeofSelect);
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_PCR_SELECTION_ARRAY(BYTE* ptr, TPMS_PCR_SELECTION *sel, UINT32 count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+        ptr = unpack_TPMI_ALG_HASH(ptr, &sel[i].hash);
+        ptr = unpack_BYTE(ptr, &sel[i].sizeofSelect);
+        ptr = unpack_BUFFER(ptr, sel[i].pcrSelect, sel[i].sizeofSelect);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPML_PCR_SELECTION(BYTE* ptr, const TPML_PCR_SELECTION *sel)
+{
+    ptr = pack_UINT32(ptr, sel->count);
+    ptr = pack_TPMS_PCR_SELECTION_ARRAY(ptr, sel->pcrSelections, sel->count);
+    return ptr;
+}
+
+inline BYTE* unpack_TPML_PCR_SELECTION(BYTE* ptr, TPML_PCR_SELECTION *sel)
+{
+    ptr = unpack_UINT32(ptr, &sel->count);
+    ptr = unpack_TPMS_PCR_SELECTION_ARRAY(ptr, sel->pcrSelections, sel->count);
+    return ptr;
+}
+
+inline BYTE* unpack_TPML_DIGEST(BYTE* ptr,TPML_DIGEST *digest)
+{
+    int i;
+    ptr = unpack_UINT32(ptr, &digest->count);
+    for (i=0;i<digest->count;i++)
+    {
+        ptr = unpack_TPM2B_DIGEST(ptr, &digest->digests[i]);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_CREATION_DATA(BYTE* ptr,const TPMS_CREATION_DATA *data)
+{
+    ptr = pack_TPML_PCR_SELECTION(ptr, &data->pcrSelect);
+    ptr = pack_TPM2B_DIGEST(ptr, &data->pcrDigest);
+    ptr = pack_TPMA_LOCALITY(ptr, &data->locality);
+    ptr = pack_TPM_ALG_ID(ptr, &data->parentNameAlg);
+    ptr = pack_TPM2B_NAME(ptr, &data->parentQualifiedName);
+    ptr = pack_TPM2B_DATA(ptr, &data->outsideInfo);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_CREATION_DATA(BYTE* ptr, TPMS_CREATION_DATA *data)
+{
+    ptr = unpack_TPML_PCR_SELECTION(ptr, &data->pcrSelect);
+    ptr = unpack_TPM2B_DIGEST(ptr, &data->pcrDigest);
+    ptr = unpack_TPMA_LOCALITY(ptr, &data->locality);
+    ptr = unpack_TPM_ALG_ID(ptr, &data->parentNameAlg);
+    ptr = unpack_TPM2B_NAME(ptr, &data->parentName);
+    ptr = unpack_TPM2B_NAME(ptr, &data->parentQualifiedName);
+    ptr = unpack_TPM2B_DATA(ptr, &data->outsideInfo);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_CREATION_DATA(BYTE* ptr, const TPM2B_CREATION_DATA *data )
+{
+    ptr = pack_UINT16(ptr, data->size);
+    ptr = pack_TPMS_CREATION_DATA(ptr, &data->creationData);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_CREATION_DATA(BYTE* ptr, TPM2B_CREATION_DATA * data)
+{
+    ptr = unpack_UINT16(ptr, &data->size);
+    ptr = unpack_TPMS_CREATION_DATA(ptr, &data->creationData);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_SENSITIVE_CREATE(BYTE* ptr, const TPMS_SENSITIVE_CREATE *create)
+{
+    ptr = pack_TPM2B_AUTH(ptr, &create->userAuth);
+    ptr = pack_TPM2B_SENSITIVE_DATA(ptr, &create->data);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_SENSITIVE_CREATE(BYTE* ptr, const TPM2B_SENSITIVE_CREATE *create)
+{
+    BYTE* sizePtr = ptr;
+    ptr += 2;
+    ptr = pack_TPMS_SENSITIVE_CREATE(ptr, &create->sensitive);
+    pack_UINT16(sizePtr, (UINT16)(ptr - sizePtr - 2));
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_SYM_MODE(BYTE* ptr, const TPMU_SYM_MODE *p,
+                                const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = pack_TPMI_ALG_SYM_MODE(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        case TPM2_ALG_XOR:
+        break;
+    default:
+        ptr = pack_TPMI_ALG_SYM_MODE(ptr, &p->sym);
+    }
+    return ptr;
+}
+inline BYTE* unpack_TPMU_SYM_MODE(BYTE* ptr, TPMU_SYM_MODE *p,
+                                  const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = unpack_TPMI_ALG_SYM_MODE(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+    case TPM2_ALG_XOR:
+        break;
+    default:
+        ptr = unpack_TPMI_ALG_SYM_MODE(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_SYM_KEY_BITS(BYTE* ptr, const TPMU_SYM_KEY_BITS *p,
+                                    const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = pack_TPMI_AES_KEY_BITS(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_XOR:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        ptr = pack_TPM_KEY_BITS(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMU_SYM_KEY_BITS(BYTE* ptr, TPMU_SYM_KEY_BITS *p,
+                                      const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = unpack_TPMI_AES_KEY_BITS(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_XOR:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        ptr = unpack_TPM_KEY_BITS(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_SYM_DEF_OBJECT(BYTE* ptr, const TPMT_SYM_DEF_OBJECT *p)
+{
+    ptr = pack_TPMI_ALG_SYM_OBJECT(ptr, &p->algorithm);
+    ptr = pack_TPMU_SYM_KEY_BITS(ptr, &p->keyBits, &p->algorithm);
+    ptr = pack_TPMU_SYM_MODE(ptr, &p->mode, &p->algorithm);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_SYM_DEF_OBJECT(BYTE *ptr, TPMT_SYM_DEF_OBJECT *p)
+{
+    ptr = unpack_TPMI_ALG_SYM_OBJECT(ptr, &p->algorithm);
+    ptr = unpack_TPMU_SYM_KEY_BITS(ptr, &p->keyBits, &p->algorithm);
+    ptr = unpack_TPMU_SYM_MODE(ptr, &p->mode, &p->algorithm);
+    return ptr;
+}
+
+#define pack_TPMS_SCHEME_OAEP(p, t)     pack_TPMI_ALG_HASH(p, &((t)->hashAlg))
+#define unpack_TPMS_SCHEME_OAEP(p, t)   unpack_TPMI_ALG_HASH(p, &((t)->hashAlg))
+
+inline BYTE* pack_TPMU_ASYM_SCHEME(BYTE *ptr, const TPMU_ASYM_SCHEME *p,
+                                   const TPMI_ALG_RSA_SCHEME *s)
+{
+    switch(*s) {
+#ifdef TPM2_ALG_RSASSA
+    case TPM2_ALG_RSASSA:
+        assert(false || "TPM2_ALG_RSASSA");
+        break;
+#endif
+#ifdef TPM2_ALG_OAEP
+    case TPM2_ALG_OAEP:
+        ptr = pack_TPMS_SCHEME_OAEP(ptr, &p->oaep);
+        break;
+#endif
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        assert(false || "DEFAULT");
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMU_ASYM_SCHEME(BYTE *ptr, TPMU_ASYM_SCHEME *p,
+                                     const TPMI_ALG_RSA_SCHEME *s)
+{
+    switch(*s) {
+    #ifdef TPM2_ALG_RSASSA
+    case TPM2_ALG_RSASSA:
+        printf("not support TPM_ALG_RSASSA\n");
+        assert(false);
+        break;
+    #endif
+    #ifdef TPM2_ALG_OAEP
+    case TPM2_ALG_OAEP:
+        ptr = unpack_TPMS_SCHEME_OAEP(ptr, &p->oaep);
+        break;
+    #endif
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        printf("default TPMI_ALG_RSA_SCHEME 0x%X\n", (UINT32)*s);
+        ptr = unpack_TPMI_ALG_HASH(ptr, &p->anySig.hashAlg);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_RSA_SCHEME(BYTE* ptr, const TPMT_RSA_SCHEME *p)
+{
+    ptr = pack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_RSA_SCHEME(BYTE* ptr, TPMT_RSA_SCHEME *p)
+{
+    ptr = unpack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = unpack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_RSA_DECRYPT(BYTE* ptr, const TPMT_RSA_DECRYPT *p)
+{
+    ptr = pack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_RSA_PARMS(BYTE* ptr, const TPMS_RSA_PARMS *p)
+{
+    ptr = pack_TPMT_SYM_DEF_OBJECT(ptr, &p->symmetric);
+    ptr = pack_TPMT_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMI_RSA_KEY_BITS(ptr, &p->keyBits);
+    ptr = pack_UINT32(ptr, p->exponent);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_RSA_PARMS(BYTE *ptr, TPMS_RSA_PARMS *p)
+{
+    ptr = unpack_TPMT_SYM_DEF_OBJECT(ptr, &p->symmetric);
+    ptr = unpack_TPMT_RSA_SCHEME(ptr, &p->scheme);
+    ptr = unpack_TPMI_RSA_KEY_BITS(ptr, &p->keyBits);
+    ptr = unpack_UINT32(ptr, &p->exponent);
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_PUBLIC_PARMS(BYTE* ptr, const TPMU_PUBLIC_PARMS *param,
+                                    const TPMI_ALG_PUBLIC *selector)
+{
+    switch(*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        assert(false);
+    case TPM2_ALG_SYMCIPHER:
+        assert(false);
+    case TPM2_ALG_RSA:
+        return pack_TPMS_RSA_PARMS(ptr, &param->rsaDetail);
+    case TPM2_ALG_ECC:
+        assert(false);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* unpack_TPMU_PUBLIC_PARMS(BYTE* ptr, TPMU_PUBLIC_PARMS *param,
+                                      const TPMI_ALG_PUBLIC *selector)
+{
+    switch(*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        assert(false);
+    case TPM2_ALG_SYMCIPHER:
+        assert(false);
+    case TPM2_ALG_RSA:
+        return unpack_TPMS_RSA_PARMS(ptr, &param->rsaDetail);
+    case TPM2_ALG_ECC:
+        assert(false);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* pack_TPMS_ECC_POINT(BYTE* ptr, const TPMS_ECC_POINT *point)
+{
+    assert(false);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_ECC_POINT(BYTE* ptr, TPMS_ECC_POINT *point)
+{
+    assert(false);
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_PUBLIC_ID(BYTE* ptr, const TPMU_PUBLIC_ID *id,
+                                 const TPMI_ALG_PUBLIC *selector)
+{
+    switch (*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        return pack_TPM2B_DIGEST(ptr, &id->keyedHash);
+    case TPM2_ALG_SYMCIPHER:
+        return pack_TPM2B_DIGEST(ptr, &id->sym);
+    case TPM2_ALG_RSA:
+        return pack_TPM2B_PUBLIC_KEY_RSA(ptr, &id->rsa);
+    case TPM2_ALG_ECC:
+        return pack_TPMS_ECC_POINT(ptr, &id->ecc);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* unpack_TPMU_PUBLIC_ID(BYTE* ptr, TPMU_PUBLIC_ID *id, TPMI_ALG_PUBLIC *selector)
+{
+    switch (*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        return unpack_TPM2B_DIGEST(ptr, &id->keyedHash);
+    case TPM2_ALG_SYMCIPHER:
+        return unpack_TPM2B_DIGEST(ptr, &id->sym);
+    case TPM2_ALG_RSA:
+        return unpack_TPM2B_PUBLIC_KEY_RSA(ptr, &id->rsa);
+    case TPM2_ALG_ECC:
+        return unpack_TPMS_ECC_POINT(ptr, &id->ecc);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* pack_TPMT_PUBLIC(BYTE* ptr, const TPMT_PUBLIC *public)
+{
+    ptr = pack_TPMI_ALG_PUBLIC(ptr, &public->type);
+    ptr = pack_TPMI_ALG_HASH(ptr, &public->nameAlg);
+    ptr = pack_TPMA_OBJECT(ptr, &public->objectAttributes);
+    ptr = pack_TPM2B_DIGEST(ptr, &public->authPolicy);
+    ptr = pack_TPMU_PUBLIC_PARMS(ptr, &public->parameters, &public->type);
+    ptr = pack_TPMU_PUBLIC_ID(ptr, &public->unique, &public->type);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_PUBLIC(BYTE* ptr, TPMT_PUBLIC *public)
+{
+    ptr = unpack_TPMI_ALG_PUBLIC(ptr, &public->type);
+    ptr = unpack_TPMI_ALG_HASH(ptr, &public->nameAlg);
+    ptr = unpack_TPMA_OBJECT(ptr, &public->objectAttributes);
+    ptr = unpack_TPM2B_DIGEST(ptr, &public->authPolicy);
+    ptr = unpack_TPMU_PUBLIC_PARMS(ptr, &public->parameters, &public->type);
+    ptr = unpack_TPMU_PUBLIC_ID(ptr, &public->unique, &public->type);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_PUBLIC(BYTE* ptr, const TPM2B_PUBLIC *public)
+{
+    BYTE *sizePtr = ptr;
+    ptr += 2;
+    ptr = pack_TPMT_PUBLIC(ptr, &public->publicArea);
+    pack_UINT16(sizePtr, (UINT16)(ptr - sizePtr - 2));
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_PUBLIC(BYTE* ptr, TPM2B_PUBLIC *public)
+{
+    ptr = unpack_UINT16(ptr, &public->size);
+    ptr = unpack_TPMT_PUBLIC(ptr, &public->publicArea);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION(BYTE* ptr, const TPMS_PCR_SELECTION *selection)
+{
+    ptr = pack_TPMI_ALG_HASH(ptr, &selection->hash);
+    ptr = pack_BYTE(ptr, selection->sizeofSelect);
+    ptr = pack_BYTE_ARRAY(ptr, selection->pcrSelect, selection->sizeofSelect);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION_Array(BYTE* ptr, const TPMS_PCR_SELECTION *selections,
+                                           const UINT32 cnt)
+{
+    int i;
+    for (i = 0; i < cnt; i++)
+        ptr = pack_TPMS_PCR_SELECTION(ptr, selections + i);
+    return ptr;
+}
+
+inline BYTE* pack_TPM_AuthArea(BYTE* ptr, const TPM_AuthArea *auth)
+{
+    BYTE* sizePtr = ptr;
+    ptr += sizeof(UINT32);
+    ptr = pack_TPM_RH(ptr, &auth->sessionHandle);
+    ptr = pack_TPM2B_NONCE(ptr, &auth->nonce);
+    ptr = pack_TPMA_SESSION(ptr, &auth->sessionAttributes);
+    ptr = pack_TPM2B_AUTH(ptr, &auth->auth);
+    pack_UINT32(sizePtr, ptr - sizePtr - sizeof(UINT32));
+    return ptr;
+}
+
+inline BYTE* unpack_TPM_AuthArea(BYTE* ptr, TPM_AuthArea *auth)
+{
+    ptr = unpack_UINT32(ptr, &auth->size);
+    ptr = unpack_TPM_RH(ptr, &auth->sessionHandle);
+    ptr = unpack_TPM2B_NONCE(ptr, &auth->nonce);
+    ptr = unpack_TPMA_SESSION(ptr, &auth->sessionAttributes);
+    ptr = unpack_TPM2B_AUTH(ptr, &auth->auth);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2_RSA_KEY(BYTE* ptr, const TPM2_RSA_KEY *key)
+{
+    ptr = pack_TPM2B_PRIVATE(ptr, &key->Private);
+    ptr = pack_TPM2B_PUBLIC(ptr, &key->Public);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2_RSA_KEY(BYTE* ptr, TPM2_RSA_KEY *key)
+{
+    ptr = unpack_TPM2B_PRIVATE(ptr, &key->Private);
+    ptr = unpack_TPM2B_PUBLIC(ptr, &key->Public);
+    return ptr;
+}
+#endif
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Bnf-0007hx-T2; Sun, 14 Dec 2014 16:13:39 +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 1Y0Bne-0007gC-NI
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:38 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	7B/70-02954-237BD845; Sun, 14 Dec 2014 16:13:38 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418573611!14939834!2
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 30968 invoked from network); 14 Dec 2014 16:13:37 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-27.messagelabs.com with SMTP;
	14 Dec 2014 16:13:37 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2014 08:13:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="428810536"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 14 Dec 2014 08:02:38 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:53 -0500
Message-Id: <1418558993-13681-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 09/12] vTPM/TPM2: Support '--tpm2' extra 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>
MIME-Version: 1.0
Content-Type: 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 vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
Add:
..
     extra="--tpm2"
..
to launch vtpm-stubdom domain on TPM 2.0, ignore it on TPM 1.x. for
example,
vtpm-stubdom domain configuration on TPM 2.0:

kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
memory=16
disk=["file:/var/scale/vdisk/vmgr,hda,w"]
name="vtpmmgr"
iomem=["fed40,5"]
extra="--tpm2"

vtpm-stubdom domain configuration on TPM 1.x:

kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
memory=16
disk=["file:/var/scale/vdisk/vmgr,hda,w"]
name="vtpmmgr"
iomem=["fed40,5"]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/vtpmmgr.c | 46 ++++++++++++++++++++++++++++++++++++++++------
 stubdom/vtpmmgr/vtpmmgr.h | 14 ++++++++++++++
 2 files changed, 54 insertions(+), 6 deletions(-)

diff --git a/stubdom/vtpmmgr/vtpmmgr.c b/stubdom/vtpmmgr/vtpmmgr.c
index 270ca8a..9cf0197 100644
--- a/stubdom/vtpmmgr/vtpmmgr.c
+++ b/stubdom/vtpmmgr/vtpmmgr.c
@@ -45,6 +45,27 @@
 #include "vtpmmgr.h"
 #include "tcg.h"
 
+struct tpm_hardware_version hardware_version = {
+    .hw_version = TPM1_HARDWARE,
+};
+
+int parse_cmdline_hw(int argc, char** argv)
+{
+    int i;
+
+    for (i = 1; i < argc; ++i) {
+        if (!strncmp(argv[i], TPM2_EXTRA_OPT, 6)) {
+            hardware_version.hw_version = TPM2_HARDWARE;
+            break;
+        }
+    }
+    return 0;
+}
+
+int hw_is_tpm2(void)
+{
+    return (hardware_version.hw_version == TPM2_HARDWARE) ? 1 : 0;
+}
 
 void main_loop(void) {
    tpmcmd_t* tpmcmd;
@@ -74,12 +95,25 @@ int main(int argc, char** argv)
    sleep(2);
    vtpmloginfo(VTPM_LOG_VTPM, "Starting vTPM manager domain\n");
 
-   /* Initialize the vtpm manager */
-   if(vtpmmgr_init(argc, argv) != TPM_SUCCESS) {
-      vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
-      rc = -1;
-      goto exit;
-   }
+    /*Parse TPM hardware in extra command line*/
+    parse_cmdline_hw(argc, argv);
+
+    /* Initialize the vtpm manager */
+    if (hw_is_tpm2()) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Hardware : --- TPM 2.0 ---\n");
+        if (vtpmmgr2_init(argc, argv) != TPM_SUCCESS) {
+            vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
+            rc = -1;
+            goto exit;
+        }
+    }else{
+        vtpmloginfo(VTPM_LOG_VTPM, "Hardware : --- TPM 1.x ---\n");
+        if (vtpmmgr_init(argc, argv) != TPM_SUCCESS) {
+            vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
+            rc = -1;
+            goto exit;
+        }
+    }
 
    main_loop();
 
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index c479443..37da1f2 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -46,9 +46,21 @@
 #include "vtpm_manager.h"
 #include "tpm2_types.h"
 
+#define TPM2_EXTRA_OPT "--tpm2"
 #define RSA_KEY_SIZE 0x0800
 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8)
 
+enum {
+    TPM1_HARDWARE = 1,
+    TPM2_HARDWARE,
+} tpm_version;
+
+struct tpm_hardware_version {
+    int hw_version;
+};
+
+extern struct tpm_hardware_version hardware_version;
+
 struct vtpm_globals {
    int tpm_fd;
    TPM_AUTH_SESSION    oiap;                // OIAP session for storageKey
@@ -97,5 +109,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 TPM_RC tpm2_take_ownership(void);
 TPM_RESULT vtpmmgr2_create(void);
 TPM_RESULT vtpmmgr2_init(int argc, char** argv);
+int parse_cmdline_hw(int argc, char** argv);
+int hw_is_tpm2(void);
 
 #endif
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Bnd-0007fl-Vf; Sun, 14 Dec 2014 16:13:37 +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 1Y0Bnc-0007ed-7L
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:36 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	9C/A5-02953-F27BD845; Sun, 14 Dec 2014 16:13:35 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418573611!14939834!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 30878 invoked from network); 14 Dec 2014 16:13:32 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-27.messagelabs.com with SMTP;
	14 Dec 2014 16:13:32 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2014 08:13:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="637398621"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 14 Dec 2014 08:13:30 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:47 -0500
Message-Id: <1418558987-13605-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 07/12] vTPM/TPM2: TPM2.0 TIS initialization and
	self test.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

call the TPM 2.0 various registers that allow communication between
the TPM 2.0 and platform hardware and software. TPM2_SelfTest causes
the TPM 2.0 to perform a test of its capabilities.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 extras/mini-os/include/tpm_tis.h |   1 +
 extras/mini-os/tpm_tis.c         | 156 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 157 insertions(+)

diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h
index 1faca0d..86e83f1 100644
--- a/extras/mini-os/include/tpm_tis.h
+++ b/extras/mini-os/include/tpm_tis.h
@@ -36,6 +36,7 @@
 struct tpm_chip;
 
 struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq);
+struct tpm_chip* init_tpm2_tis(unsigned long baseaddr, int localities, unsigned int irq);
 void shutdown_tpm_tis(struct tpm_chip* tpm);
 
 int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
index d78c465..debcc43 100644
--- a/extras/mini-os/tpm_tis.c
+++ b/extras/mini-os/tpm_tis.c
@@ -1363,5 +1363,161 @@ int tpm_tis_posix_fstat(int fd, struct stat* buf)
    return 0;
 }
 
+/* TPM 2.0 */
 
+/*TPM2.0 Selftest*/
+static void tpm2_selftest(struct tpm_chip* chip)
+{
+    uint8_t data[] = {
+        0x80, 0x1,
+        0x0, 0x0, 0x0, 0xb,
+        0x0, 0x0, 0x1, 0x43,
+        0x1,
+    };
+
+    tpm_transmit(chip, data, sizeof(data));
+}
+
+struct tpm_chip* init_tpm2_tis(unsigned long baseaddr, int localities, unsigned int irq)
+{
+    int i;
+    unsigned long addr;
+    struct tpm_chip* tpm = NULL;
+    uint32_t didvid;
+    uint32_t intfcaps;
+    uint32_t intmask;
+
+    printk("============= Init TPM2 TIS Driver ==============\n");
+
+    /*Sanity check the localities input */
+    if (localities & ~TPM_TIS_EN_LOCLALL) {
+        printk("init_tpm2_tis Invalid locality specification! %X\n", localities);
+        goto abort_egress;
+    }
+
+    printk("IOMEM Machine Base Address: %lX\n", baseaddr);
+
+    /* Create the tpm data structure */
+    tpm = malloc(sizeof(struct tpm_chip));
+    __init_tpm_chip(tpm);
+
+    /* Set the enabled localities - if 0 we leave default as all enabled */
+    if (localities != 0) {
+        tpm->enabled_localities = localities;
+    }
+    printk("Enabled Localities: ");
+    for (i = 0; i < 5; ++i) {
+        if (locality_enabled(tpm, i)) {
+            printk("%d ", i);
+        }
+    }
+    printk("\n");
+
+    /* Set the base machine address */
+    tpm->baseaddr = baseaddr;
+
+    /* Set default timeouts */
+    tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT);
+    tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT);
+    tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT);
+    tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT);
+
+    /*Map the mmio pages */
+    addr = tpm->baseaddr;
+    for (i = 0; i < 5; ++i) {
+        if (locality_enabled(tpm, i)) {
+
+            /* Map the page in now */
+            if ((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) {
+                printk("Unable to map iomem page a address %p\n", addr);
+                goto abort_egress;
+            }
+
+            /* Set default locality to the first enabled one */
+            if (tpm->locality < 0) {
+                if (tpm_tis_request_locality(tpm, i) < 0) {
+                    printk("Unable to request locality %d??\n", i);
+                    goto abort_egress;
+                }
+            }
+        }
+        addr += PAGE_SIZE;
+    }
+
+    /* Get the vendor and device ids */
+    didvid = ioread32(TPM_DID_VID(tpm, tpm->locality));
+    tpm->did = didvid >> 16;
+    tpm->vid = didvid & 0xFFFF;
+
+    /* Get the revision id */
+    tpm->rid = ioread8(TPM_RID(tpm, tpm->locality));
+    printk("2.0 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n",
+           tpm->did, tpm->vid, tpm->rid);
+
+    intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
+    printk("TPM interface capabilities (0x%x):\n", intfcaps);
+    if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
+        printk("\tBurst Count Static\n");
+    if (intfcaps & TPM_INTF_CMD_READY_INT)
+        printk("\tCommand Ready Int Support\n");
+    if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
+        printk("\tInterrupt Edge Falling\n");
+    if (intfcaps & TPM_INTF_INT_EDGE_RISING)
+        printk("\tInterrupt Edge Rising\n");
+    if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
+        printk("\tInterrupt Level Low\n");
+    if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
+        printk("\tInterrupt Level High\n");
+    if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
+        printk("\tLocality Change Int Support\n");
+    if (intfcaps & TPM_INTF_STS_VALID_INT)
+        printk("\tSts Valid Int Support\n");
+    if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
+        printk("\tData Avail Int Support\n");
+
+    /*Interupt setup */
+    intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
+
+    intmask |= TPM_INTF_CMD_READY_INT | TPM_INTF_LOCALITY_CHANGE_INT |
+               TPM_INTF_DATA_AVAIL_INT | TPM_INTF_STS_VALID_INT;
+
+    iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
+
+    /*If interupts are enabled, handle it */
+    if (irq) {
+        if (irq != TPM_PROBE_IRQ) {
+            tpm->irq = irq;
+        } else {
+        /*FIXME add irq probing feature later */
+        printk("IRQ probing not implemented\n");
+        }
+    }
+
+    if (tpm->irq) {
+        iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
+        if (bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) {
+            printk("Unabled to request irq: %u for use\n", tpm->irq);
+            printk("Will use polling mode\n");
+            tpm->irq = 0;
+        } else {
+
+            /* Clear all existing */
+            iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
+                                     ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
+
+            /* Turn on interrupts */
+            iowrite32(TPM_INT_ENABLE(tpm, tpm->locality),
+                                     intmask | TPM_GLOBAL_INT_ENABLE);
+        }
+    }
+
+    tpm2_selftest(tpm);
+    return tpm;
+
+abort_egress:
+    if (tpm != NULL) {
+        shutdown_tpm_tis(tpm);
+    }
+    return NULL;
+}
 #endif
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnN-0007YG-3V; Sun, 14 Dec 2014 16:13:21 +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 1Y0BnL-0007Xy-Gw
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:19 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	17/24-23865-E17BD845; Sun, 14 Dec 2014 16:13:18 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418573594!8804052!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 22143 invoked from network); 14 Dec 2014 16:13:15 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-31.messagelabs.com with SMTP;
	14 Dec 2014 16:13:15 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2014 08:13:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="647434585"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 14 Dec 2014 08:13:11 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:29 -0500
Message-Id: <1418558969-13381-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 01/12] vTPM/TPM2: Add TPM 2.0 data structures
	and commands 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

Add TPM 2.0 data structures on Trusted Platform Module Library Part 2:
Structures and Trust Platform Module Library Part 3: Commands.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/tpm2_types.h | 978 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 978 insertions(+)
 create mode 100644 stubdom/vtpmmgr/tpm2_types.h

diff --git a/stubdom/vtpmmgr/tpm2_types.h b/stubdom/vtpmmgr/tpm2_types.h
new file mode 100644
index 0000000..214335c
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2_types.h
@@ -0,0 +1,978 @@
+#ifndef __TPM2_TYPES_H__
+#define __TPM2_TYPES_H__
+
+#include <stdlib.h>
+#include <stdint.h>
+
+// "implementation.h"
+// Table 212 -- Logic Values
+#define    YES      1
+#define    NO       0
+#ifndef    TRUE
+#define    TRUE     1
+#endif
+#ifndef    FALSE
+#define    FALSE    0
+#endif
+#ifndef    true
+#define    true     1
+#endif
+#ifndef    false
+#define    false    0
+#endif
+#define    SET      1
+#define    CLEAR    0
+
+
+// Table 214 -- Implemented Algorithms
+#define    ALG_RSA               YES    // 1
+#define    ALG_DES               NO     // 0
+#define    ALG__3DES             NO     // 0
+#define    ALG_SHA1              YES    // 1
+#define    ALG_HMAC              YES    // 1
+#define    ALG_AES               YES    // 1
+#define    ALG_MGF1              YES    // 1
+#define    ALG_XOR               YES    // 1
+#define    ALG_KEYEDHASH         YES    // 1
+#define    ALG_SHA256            YES    // 1
+#define    ALG_SHA384            YES    // 0
+#define    ALG_SHA512            YES    // 0
+#define    ALG_WHIRLPOOL512      YES    // 0
+#define    ALG_SM3_256           YES    // 1
+#define    ALG_SM4               YES    // 1
+#define    ALG_RSASSA            YES    // 1
+#define    ALG_RSAES             YES    // 1
+#define    ALG_RSAPSS            YES    // 1
+#define    ALG_OAEP              YES    // 1
+#define    ALG_ECC               YES    // 1
+#define    ALG_CFB               YES    // 1
+#define    ALG_ECDH              YES    // 1
+#define    ALG_ECDSA             YES    // 1
+#define    ALG_ECDAA             YES    // 1
+#define    ALG_SM2               YES    // 1
+#define    ALG_ECSCHNORR         YES    // 1
+#define    ALG_SYMCIPHER         YES    // 1
+#define    ALG_KDF1_SP800_56a    YES    // 1
+#define    ALG_KDF2              NO     // 0
+#define    ALG_KDF1_SP800_108    YES    // 1
+#define    ALG_CTR               YES    // 1
+#define    ALG_OFB               YES    // 1
+#define    ALG_CBC               YES    // 1
+
+#define HASH_COUNT (ALG_SHA1+ALG_SHA256+ALG_SHA384+ALG_SHA512+ALG_WHIRLPOOL512+ALG_SM3_256)
+
+// Table 216 -- RSA Algorithm Constants
+#define    RSA_KEY_SIZES_BITS    2048    // {1024,2048}
+#define    MAX_RSA_KEY_BITS      2048
+#define    MAX_RSA_KEY_BYTES     ((MAX_RSA_KEY_BITS + 7) / 8)    // 256
+
+// Table 218 -- AES Algorithm Constants
+#define    AES_KEY_SIZES_BITS          128
+#define    MAX_AES_KEY_BITS            128
+#define    MAX_AES_BLOCK_SIZE_BYTES    16
+#define    MAX_AES_KEY_BYTES           ((MAX_AES_KEY_BITS + 7) / 8)    // 16
+
+
+// Table 220 -- Symmetric Algorithm Constants
+#define    MAX_SYM_KEY_BITS      MAX_AES_KEY_BITS    // 128
+#define    MAX_SYM_KEY_BYTES     MAX_AES_KEY_BYTES    // 16
+#define    MAX_SYM_BLOCK_SIZE    MAX_AES_BLOCK_SIZE_BYTES    // 16
+
+#define    MAX_SYM_DATA         128
+#define    MAX_ECC_KEY_BITS     256
+#define    MAX_ECC_KEY_BYTES    ((MAX_ECC_KEY_BITS + 7) / 8)
+
+
+typedef unsigned char BYTE;
+typedef unsigned char BOOL;
+typedef uint8_t       UINT8;
+typedef uint16_t      UINT16;
+typedef uint32_t      UINT32;
+typedef uint64_t      UINT64;
+
+// TPM2 command code
+
+typedef UINT32 TPM_CC;
+#define    TPM_CC_FIRST                         (TPM_CC)(0x0000011F)
+#define    TPM_CC_PP_FIRST                      (TPM_CC)(0x0000011F)
+#define    TPM_CC_NV_UndefineSpaceSpecial       (TPM_CC)(0x0000011F)
+#define    TPM_CC_EvictControl                  (TPM_CC)(0x00000120)
+#define    TPM_CC_HierarchyControl              (TPM_CC)(0x00000121)
+#define    TPM_CC_NV_UndefineSpace              (TPM_CC)(0x00000122)
+#define    TPM_CC_ChangeEPS                     (TPM_CC)(0x00000124)
+#define    TPM_CC_ChangePPS                     (TPM_CC)(0x00000125)
+#define    TPM_CC_Clear                         (TPM_CC)(0x00000126)
+#define    TPM_CC_ClearControl                  (TPM_CC)(0x00000127)
+#define    TPM_CC_ClockSet                      (TPM_CC)(0x00000128)
+#define    TPM_CC_HierarchyChangeAuth           (TPM_CC)(0x00000129)
+#define    TPM_CC_NV_DefineSpace                (TPM_CC)(0x0000012A)
+#define    TPM_CC_PCR_Allocate                  (TPM_CC)(0x0000012B)
+#define    TPM_CC_PCR_SetAuthPolicy             (TPM_CC)(0x0000012C)
+#define    TPM_CC_PP_Commands                   (TPM_CC)(0x0000012D)
+#define    TPM_CC_SetPrimaryPolicy              (TPM_CC)(0x0000012E)
+#define    TPM_CC_FieldUpgradeStart             (TPM_CC)(0x0000012F)
+#define    TPM_CC_ClockRateAdjust               (TPM_CC)(0x00000130)
+#define    TPM_CC_CreatePrimary                 (TPM_CC)(0x00000131)
+#define    TPM_CC_NV_GlobalWriteLock            (TPM_CC)(0x00000132)
+#define    TPM_CC_PP_LAST                       (TPM_CC)(0x00000132)
+#define    TPM_CC_GetCommandAuditDigest         (TPM_CC)(0x00000133)
+#define    TPM_CC_NV_Increment                  (TPM_CC)(0x00000134)
+#define    TPM_CC_NV_SetBits                    (TPM_CC)(0x00000135)
+#define    TPM_CC_NV_Extend                     (TPM_CC)(0x00000136)
+#define    TPM_CC_NV_Write                      (TPM_CC)(0x00000137)
+#define    TPM_CC_NV_WriteLock                  (TPM_CC)(0x00000138)
+#define    TPM_CC_DictionaryAttackLockReset     (TPM_CC)(0x00000139)
+#define    TPM_CC_DictionaryAttackParameters    (TPM_CC)(0x0000013A)
+#define    TPM_CC_NV_ChangeAuth                 (TPM_CC)(0x0000013B)
+#define    TPM_CC_PCR_Event                     (TPM_CC)(0x0000013C)
+#define    TPM_CC_PCR_Reset                     (TPM_CC)(0x0000013D)
+#define    TPM_CC_SequenceComplete              (TPM_CC)(0x0000013E)
+#define    TPM_CC_SetAlgorithmSet               (TPM_CC)(0x0000013F)
+#define    TPM_CC_SetCommandCodeAuditStatus     (TPM_CC)(0x00000140)
+#define    TPM_CC_FieldUpgradeData              (TPM_CC)(0x00000141)
+#define    TPM_CC_IncrementalSelfTest           (TPM_CC)(0x00000142)
+#define    TPM_CC_SelfTest                      (TPM_CC)(0x00000143)
+#define    TPM_CC_Startup                       (TPM_CC)(0x00000144)
+#define    TPM_CC_Shutdown                      (TPM_CC)(0x00000145)
+#define    TPM_CC_StirRandom                    (TPM_CC)(0x00000146)
+#define    TPM_CC_ActivateCredential            (TPM_CC)(0x00000147)
+#define    TPM_CC_Certify                       (TPM_CC)(0x00000148)
+#define    TPM_CC_PolicyNV                      (TPM_CC)(0x00000149)
+#define    TPM_CC_CertifyCreation               (TPM_CC)(0x0000014A)
+#define    TPM_CC_Duplicate                     (TPM_CC)(0x0000014B)
+#define    TPM_CC_GetTime                       (TPM_CC)(0x0000014C)
+#define    TPM_CC_GetSessionAuditDigest         (TPM_CC)(0x0000014D)
+#define    TPM_CC_NV_Read                       (TPM_CC)(0x0000014E)
+#define    TPM_CC_NV_ReadLock                   (TPM_CC)(0x0000014F)
+#define    TPM_CC_ObjectChangeAuth              (TPM_CC)(0x00000150)
+#define    TPM_CC_PolicySecret                  (TPM_CC)(0x00000151)
+#define    TPM_CC_Rewrap                        (TPM_CC)(0x00000152)
+#define    TPM_CC_Create                        (TPM_CC)(0x00000153)
+#define    TPM_CC_ECDH_ZGen                     (TPM_CC)(0x00000154)
+#define    TPM_CC_HMAC                          (TPM_CC)(0x00000155)
+#define    TPM_CC_Import                        (TPM_CC)(0x00000156)
+#define    TPM_CC_Load                          (TPM_CC)(0x00000157)
+#define    TPM_CC_Quote                         (TPM_CC)(0x00000158)
+#define    TPM_CC_RSA_Decrypt                   (TPM_CC)(0x00000159)
+#define    TPM_CC_HMAC_Start                    (TPM_CC)(0x0000015B)
+#define    TPM_CC_SequenceUpdate                (TPM_CC)(0x0000015C)
+#define    TPM_CC_Sign                          (TPM_CC)(0x0000015D)
+#define    TPM_CC_Unseal                        (TPM_CC)(0x0000015E)
+#define    TPM_CC_PolicySigned                  (TPM_CC)(0x00000160)
+#define    TPM_CC_ContextLoad                   (TPM_CC)(0x00000161)
+#define    TPM_CC_ContextSave                   (TPM_CC)(0x00000162)
+#define    TPM_CC_ECDH_KeyGen                   (TPM_CC)(0x00000163)
+#define    TPM_CC_EncryptDecrypt                (TPM_CC)(0x00000164)
+#define    TPM_CC_FlushContext                  (TPM_CC)(0x00000165)
+#define    TPM_CC_LoadExternal                  (TPM_CC)(0x00000167)
+#define    TPM_CC_MakeCredential                (TPM_CC)(0x00000168)
+#define    TPM_CC_NV_ReadPublic                 (TPM_CC)(0x00000169)
+#define    TPM_CC_PolicyAuthorize               (TPM_CC)(0x0000016A)
+#define    TPM_CC_PolicyAuthValue               (TPM_CC)(0x0000016B)
+#define    TPM_CC_PolicyCommandCode             (TPM_CC)(0x0000016C)
+#define    TPM_CC_PolicyCounterTimer            (TPM_CC)(0x0000016D)
+#define    TPM_CC_PolicyCpHash                  (TPM_CC)(0x0000016E)
+#define    TPM_CC_PolicyLocality                (TPM_CC)(0x0000016F)
+#define    TPM_CC_PolicyNameHash                (TPM_CC)(0x00000170)
+#define    TPM_CC_PolicyOR                      (TPM_CC)(0x00000171)
+#define    TPM_CC_PolicyTicket                  (TPM_CC)(0x00000172)
+#define    TPM_CC_ReadPublic                    (TPM_CC)(0x00000173)
+#define    TPM_CC_RSA_Encrypt                   (TPM_CC)(0x00000174)
+#define    TPM_CC_StartAuthSession              (TPM_CC)(0x00000176)
+#define    TPM_CC_VerifySignature               (TPM_CC)(0x00000177)
+#define    TPM_CC_ECC_Parameters                (TPM_CC)(0x00000178)
+#define    TPM_CC_FirmwareRead                  (TPM_CC)(0x00000179)
+#define    TPM_CC_GetCapability                 (TPM_CC)(0x0000017A)
+#define    TPM_CC_GetRandom                     (TPM_CC)(0x0000017B)
+#define    TPM_CC_GetTestResult                 (TPM_CC)(0x0000017C)
+#define    TPM_CC_Hash                          (TPM_CC)(0x0000017D)
+#define    TPM_CC_PCR_Read                      (TPM_CC)(0x0000017E)
+#define    TPM_CC_PolicyPCR                     (TPM_CC)(0x0000017F)
+#define    TPM_CC_PolicyRestart                 (TPM_CC)(0x00000180)
+#define    TPM_CC_ReadClock                     (TPM_CC)(0x00000181)
+#define    TPM_CC_PCR_Extend                    (TPM_CC)(0x00000182)
+#define    TPM_CC_PCR_SetAuthValue              (TPM_CC)(0x00000183)
+#define    TPM_CC_NV_Certify                    (TPM_CC)(0x00000184)
+#define    TPM_CC_EventSequenceComplete         (TPM_CC)(0x00000185)
+#define    TPM_CC_HashSequenceStart             (TPM_CC)(0x00000186)
+#define    TPM_CC_PolicyPhysicalPresence        (TPM_CC)(0x00000187)
+#define    TPM_CC_PolicyDuplicationSelect       (TPM_CC)(0x00000188)
+#define    TPM_CC_PolicyGetDigest               (TPM_CC)(0x00000189)
+#define    TPM_CC_TestParms                     (TPM_CC)(0x0000018A)
+#define    TPM_CC_Commit                        (TPM_CC)(0x0000018B)
+#define    TPM_CC_PolicyPassword                (TPM_CC)(0x0000018C)
+#define    TPM_CC_SM2_ZGen                      (TPM_CC)(0x0000018D)
+#define    TPM_CC_LAST                          (TPM_CC)(0x0000018D)
+
+
+//TPM_RC
+typedef UINT32 TPM_RC;
+
+// TPM_ST Constants
+typedef UINT16 TPM_ST;
+#define    TPM_ST_NULL                    (TPM_ST)(0X8000)
+#define    TPM_ST_NO_SESSIONS             (TPM_ST)(0x8001)
+#define    TPM_ST_SESSIONS                (TPM_ST)(0x8002)
+
+
+// TPM Handle types
+typedef UINT32 TPM_HANDLE;
+typedef UINT8 TPM_HT;
+
+
+// TPM_RH Constants
+typedef UINT32 TPM_RH;
+
+#define    TPM_RH_FIRST          (TPM_RH)(0x40000000)
+#define    TPM_RH_SRK            (TPM_RH)(0x40000000)
+#define    TPM_RH_OWNER          (TPM_RH)(0x40000001)
+#define    TPM_RS_PW             (TPM_RH)(0x40000009)
+#define    TPM_RH_LOCKOUT        (TPM_RH)(0x4000000A)
+#define    TPM_RH_ENDORSEMENT    (TPM_RH)(0x4000000B)
+#define    TPM_RH_PLATFORM       (TPM_RH)(0x4000000C)
+#define    TPM_RH_LAST           (TPM_RH)(0x4000000C)
+
+// Table 4 -- DocumentationClarity Types <I/O>
+typedef UINT32    TPM_ALGORITHM_ID;
+typedef UINT32    TPM_MODIFIER_INDICATOR;
+typedef UINT32    TPM_SESSION_OFFSET;
+typedef UINT16    TPM_KEY_SIZE;
+typedef UINT16    TPM_KEY_BITS;
+typedef UINT64    TPM_SYSTEM_ADDRESS;
+typedef UINT32    TPM_SPEC;
+
+// Table 29 -- TPMA_ALGORITHM Bits <I/O>
+typedef struct {
+    unsigned int asymmetric:1;
+    unsigned int symmetric:1;
+    unsigned int hash:1;
+    unsigned int object:1;
+    unsigned int reserved5:4;
+    unsigned int signing:1;
+    unsigned int encrypting:1;
+    unsigned int method:1;
+    unsigned int reserved9:21;
+} TPMA_ALGORITHM;
+
+typedef UINT32 TPMA_OBJECT;
+typedef BYTE TPMA_SESSION;
+typedef BYTE TPMA_LOCALITY;
+
+// Table 37 -- TPMI_YES_NO Type <I/O>
+typedef BYTE TPMI_YES_NO;
+
+typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
+
+// Table 38 -- TPMI_DH_OBJECT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_OBJECT;
+
+// Table 39 -- TPMI_DH_PERSISTENT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_PERSISTENT;
+
+// Table 42 -- TPMI_SH_AUTH_SESSION Type <I/O>
+typedef TPM_HANDLE TPMI_SH_AUTH_SESSION;
+
+// Table 40 -- TPMI_DH_ENTITY Type <I>
+typedef TPM_HANDLE TPMI_DH_ENTITY;
+
+// Table 45 -- TPMI_DH_CONTEXT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_CONTEXT;
+
+// Table 46 -- TPMI_RH_HIERARCHY Type <I/O>
+typedef TPM_HANDLE TPMI_RH_HIERARCHY;
+
+// Table 47 -- TPMI_RH_HIERARCHY_AUTH Type <I>
+typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
+
+// Table 48 -- TPMI_RH_PLATFORM Type <I>
+typedef TPM_HANDLE TPMI_RH_PLATFORM;
+
+// Table 49 -- TPMI_RH_OWNER Type <I>
+typedef TPM_HANDLE TPMI_RH_OWNER;
+
+// Table 50 -- TPMI_RH_ENDORSEMENT Type <I>
+typedef TPM_HANDLE TPMI_RH_ENDORSEMENT;
+
+// Table 51 -- TPMI_RH_PROVISION Type <I>
+typedef TPM_HANDLE TPMI_RH_PROVISION;
+
+// Table 52 -- TPMI_RH_CLEAR Type <I>
+typedef TPM_HANDLE TPMI_RH_CLEAR;
+
+// Table 54 -- TPMI_RH_LOCKOUT Type <I>
+typedef TPM_HANDLE TPMI_RH_LOCKOUT;
+
+// Table 7 -- TPM_ALG_ID
+typedef UINT16 TPM_ALG_ID;
+typedef UINT16 TPM_ALG_ID;
+
+#define    TPM2_ALG_ERROR             (TPM_ALG_ID)(0x0000) // a: ; D:
+#define    TPM2_ALG_FIRST             (TPM_ALG_ID)(0x0001) // a: ; D:
+#if ALG_RSA == YES || ALG_ALL == YES
+#define    TPM2_ALG_RSA               (TPM_ALG_ID)(0x0001) // a: A O; D:
+#endif
+#if ALG_DES == YES || ALG_ALL == YES
+#define    TPM2_ALG_DES               (TPM_ALG_ID)(0x0002) // a: S; D:
+#endif
+#define    TPM2_ALG_SHA1              (TPM_ALG_ID)(0x0004) // a: H; D:
+#if ALG_HMAC == YES || ALG_ALL == YES
+#define    TPM2_ALG_HMAC              (TPM_ALG_ID)(0x0005) // a: H X; D:
+#endif
+#if ALG_AES == YES || ALG_ALL == YES
+#define    TPM2_ALG_AES               (TPM_ALG_ID)(0x0006) // a: S; D:
+#endif
+#if ALG_XOR == YES || ALG_ALL == YES
+#define    TPM2_ALG_XOR               (TPM_ALG_ID)(0x000A) // a: H S; D:
+#endif
+#if ALG_MGF1 == YES || ALG_ALL == YES
+#define    TPM2_ALG_MGF1              (TPM_ALG_ID)(0x0007) // a: H M; D:
+#endif
+#if ALG_KEYEDHASH == YES || ALG_ALL == YES
+#define    TPM2_ALG_KEYEDHASH         (TPM_ALG_ID)(0x0008) // a: H E X O; D:
+#endif
+#if ALG_SHA256 == YES || ALG_ALL == YES
+#define    TPM2_ALG_SHA256            (TPM_ALG_ID)(0x000B) // a: H; D:
+#endif
+#define    TPM2_ALG_NULL              (TPM_ALG_ID)(0x0010) // a: ; D:
+#if ALG_OAEP == YES || ALG_ALL == YES
+#define    TPM2_ALG_OAEP              (TPM_ALG_ID)(0x0017) // a: A E; D: RSA
+#endif
+#if ALG_ECC == YES || ALG_ALL == YES
+#define    TPM2_ALG_ECC               (TPM_ALG_ID)(0x0023) // a: A O; D:
+#endif
+#if ALG_SM4 == YES || ALG_ALL == YES
+#define    TPM2_ALG_SM4               (TPM_ALG_ID)(0x0013) // a: S; D:
+#endif
+#if ALG_SYMCIPHER == YES || ALG_ALL == YES
+#define    TPM2_ALG_SYMCIPHER         (TPM_ALG_ID)(0x0025) // a: O; D:
+#endif
+#if ALG_CFB == YES || ALG_ALL == YES
+#define    TPM2_ALG_CFB               (TPM_ALG_ID)(0x0043) // a: S E; D:
+#endif
+#define    TPM2_ALG_LAST              (TPM_ALG_ID)(0x0044)
+
+#define    SHA1_DIGEST_SIZE      20
+#define    SHA1_BLOCK_SIZE       64
+#define    SHA256_DIGEST_SIZE    32
+#define    SHA256_BLOCK_SIZE     64
+
+// Table 57 -- TPMI_ALG_ASYM Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_ASYM;
+
+// Table 56 -- TPMI_ALG_HASH Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_HASH;
+
+// Table 58 -- TPMI_ALG_SYM Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM;
+
+// Table 59 -- TPMI_ALG_SYM_OBJECT Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM_OBJECT;
+
+// Table 60 -- TPMI_ALG_SYM_MODE Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM_MODE;
+
+// Table 61 -- TPMI_ALG_KDF Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_KDF;
+
+// Table 62 -- TPMI_ALG_SIG_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SIG_SCHEME;
+
+// Table 65 -- TPMU_HA Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_SHA1
+    BYTE  sha1[SHA1_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA256
+    BYTE  sha256[SHA256_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SM3_256
+    BYTE  sm3_256[SM3_256_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA384
+    BYTE  sha384[SHA384_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA512
+    BYTE  sha512[SHA512_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_WHIRLPOOL512
+    BYTE  whirlpool[WHIRLPOOL512_DIGEST_SIZE];
+#endif
+
+} TPMU_HA;
+
+// Table 67 -- TPM2B_DIGEST Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[sizeof(TPMU_HA)];
+} TPM2B_DIGEST;
+
+// Table 69 -- TPM2B_NONCE Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_NONCE;
+
+typedef TPM2B_DIGEST    TPM2B_DATA;
+
+// Table 70 -- TPM2B_AUTH Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_AUTH;
+
+// Table 71 -- TPM2B_OPERAND Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_OPERAND;
+
+// Table 66 -- TPMT_HA Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    TPMU_HA          digest;
+} TPMT_HA;
+
+//Table 80 -- TPM2B_NAME Structure
+typedef struct {
+    UINT16 size;
+    BYTE name[sizeof(TPMT_HA)];
+} TPM2B_NAME;
+
+#define    IMPLEMENTATION_PCR   24
+#define    PLATFORM_PCR         24
+#define    PCR_SELECT_MAX       ((IMPLEMENTATION_PCR+7)/8)
+
+//Table 79 -- TPMS_PCR_SELECT Structure <I/O>
+typedef struct {
+    UINT8    sizeofSelect;
+    BYTE     pcrSelect[PCR_SELECT_MAX];
+} TPMS_PCR_SELECT;
+
+// Table 80 -- TPMS_PCR_SELECTION Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hash;
+    UINT8            sizeofSelect;
+    BYTE             pcrSelect[PCR_SELECT_MAX];
+} TPMS_PCR_SELECTION;
+
+// Table 83 -- TPMT_TK_CREATION Structure <I/O>
+typedef struct {
+    TPM_ST               tag;
+    TPMI_RH_HIERARCHY    hierarchy;
+    TPM2B_DIGEST         digest;
+} TPMT_TK_CREATION;
+
+// Table 96 -- Definition of TPML_DIGEST Structure <I/O>
+typedef struct {
+    UINT32               count;
+    TPM2B_DIGEST         digests[8];
+}TPML_DIGEST;
+
+// Table 97 -- TPML_PCR_SELECTION Structure <I/O>
+typedef struct {
+    UINT32                count;
+    TPMS_PCR_SELECTION    pcrSelections[HASH_COUNT];
+} TPML_PCR_SELECTION;
+
+// Table 119 -- TPMI_AES_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_AES_KEY_BITS;
+
+// Table 120 -- TPMI_SM4_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_SM4_KEY_BITS;
+
+// Table 121 -- TPMU_SYM_KEY_BITS Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_AES
+    TPMI_AES_KEY_BITS  aes;
+#endif
+#ifdef TPM2_ALG_SM4
+    TPMI_SM4_KEY_BITS  SM4;
+#endif
+    TPM_KEY_BITS  sym;
+#ifdef TPM2_ALG_XOR
+    TPMI_ALG_HASH  xor;
+#endif
+
+} TPMU_SYM_KEY_BITS;
+
+// Table 122 -- TPMU_SYM_MODE Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_AES
+    TPMI_ALG_SYM_MODE  aes;
+#endif
+#ifdef TPM2_ALG_SM4
+    TPMI_ALG_SYM_MODE  SM4;
+#endif
+    TPMI_ALG_SYM_MODE  sym;
+} TPMU_SYM_MODE ;
+
+// Table 124 -- TPMT_SYM_DEF Structure <I/O>
+typedef struct {
+    TPMI_ALG_SYM         algorithm;
+    TPMU_SYM_KEY_BITS    keyBits;
+    TPMU_SYM_MODE        mode;
+} TPMT_SYM_DEF;
+
+// Table 125 -- TPMT_SYM_DEF_OBJECT Structure <I/O>
+typedef struct {
+    TPMI_ALG_SYM_OBJECT    algorithm;
+    TPMU_SYM_KEY_BITS      keyBits;
+    TPMU_SYM_MODE          mode;
+} TPMT_SYM_DEF_OBJECT;
+
+// Table 126 -- TPM2B_SYM_KEY Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_SYM_KEY_BYTES];
+} TPM2B_SYM_KEY;
+
+// Table 127 -- TPMS_SYMCIPHER_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    sym;
+} TPMS_SYMCIPHER_PARMS;
+
+// Table 128 -- TPM2B_SENSITIVE_DATA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_SYM_DATA];
+} TPM2B_SENSITIVE_DATA;
+
+// Table 129 -- TPMS_SENSITIVE_CREATE Structure <I>
+typedef struct {
+    TPM2B_AUTH              userAuth;
+    TPM2B_SENSITIVE_DATA    data;
+} TPMS_SENSITIVE_CREATE;
+
+// Table 130 -- TPM2B_SENSITIVE_CREATE Structure <I,S>
+typedef struct {
+    UINT16                   size;
+    TPMS_SENSITIVE_CREATE    sensitive;
+} TPM2B_SENSITIVE_CREATE;
+
+// Table 131 -- TPMS_SCHEME_SIGHASH Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_SIGHASH;
+
+// Table 132 -- TPMI_ALG_KEYEDHASH_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_KEYEDHASH_SCHEME;
+
+// Table 133 -- HMAC_SIG_SCHEME Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_HMAC;
+
+// Table 134 -- TPMS_SCHEME_XOR Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    TPMI_ALG_KDF     kdf;
+} TPMS_SCHEME_XOR;
+
+// Table 135 -- TPMU_SCHEME_KEYEDHASH Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_HMAC
+    TPMS_SCHEME_HMAC  hmac;
+#endif
+#ifdef TPM2_ALG_XOR
+    TPMS_SCHEME_XOR  xor;
+#endif
+
+} TPMU_SCHEME_KEYEDHASH ;
+
+// Table 136 -- TPMT_KEYEDHASH_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_KEYEDHASH_SCHEME    scheme;
+    TPMU_SCHEME_KEYEDHASH        details;
+} TPMT_KEYEDHASH_SCHEME;
+
+// Table 137 -- RSA_SIG_SCHEMES Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_RSASSA;
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_RSAPSS;
+
+// Table 138 -- ECC_SIG_SCHEMES Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_ECDSA;
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_SM2;
+
+// Table 139 -- TPMS_SCHEME_ECDAA Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    UINT16           count;
+} TPMS_SCHEME_ECDAA;
+
+// Table 140 -- TPMS_SCHEME_ECSCHNORR Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    UINT16           count;
+} TPMS_SCHEME_ECSCHNORR;
+
+// Table 141 -- TPMU_SIG_SCHEME Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_RSASSA
+    TPMS_SCHEME_RSASSA  rsassa;
+#endif
+#ifdef TPM2_ALG_RSAPSS
+    TPMS_SCHEME_RSAPSS  rsapss;
+#endif
+#ifdef TPM2_ALG_ECDSA
+    TPMS_SCHEME_ECDSA  ecdsa;
+#endif
+#ifdef TPM2_ALG_SM2
+    TPMS_SCHEME_SM2  sm2;
+#endif
+#ifdef TPM2_ALG_ECDAA
+    TPMS_SCHEME_ECDAA  ecdaa;
+#endif
+#ifdef TPM2_ALG_ECSCHNORR
+    TPMS_SCHEME_ECSCHNORR  ecSchnorr;
+#endif
+#ifdef TPM2_ALG_HMAC
+    TPMS_SCHEME_HMAC  hmac;
+#endif
+    TPMS_SCHEME_SIGHASH  any;
+} TPMU_SIG_SCHEME;
+
+// Table 142 -- TPMT_SIG_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_SIG_SCHEME    scheme;
+    TPMU_SIG_SCHEME        details;
+} TPMT_SIG_SCHEME;
+
+// Table 143 -- TPMS_SCHEME_OAEP Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_OAEP;
+
+// Table 144 -- TPMS_SCHEME_ECDH Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_ECDH;
+
+// Table 145 -- TPMS_SCHEME_MGF1 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_MGF1;
+
+// Table 146 -- TPMS_SCHEME_KDF1_SP800_56a Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF1_SP800_56a;
+
+// Table 147 -- TPMS_SCHEME_KDF2 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF2;
+
+// Table 148 -- TPMS_SCHEME_KDF1_SP800_108 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF1_SP800_108;
+
+// Table 149 -- TPMU_KDF_SCHEME Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_MGF1
+    TPMS_SCHEME_MGF1  mgf1;
+#endif
+#ifdef TPM2_ALG_KDF1_SP800_56a
+    TPMS_SCHEME_KDF1_SP800_56a  kdf1_SP800_56a;
+#endif
+#ifdef TPM2_ALG_KDF2
+    TPMS_SCHEME_KDF2  kdf2;
+#endif
+#ifdef TPM2_ALG_KDF1_SP800_108
+    TPMS_SCHEME_KDF1_SP800_108  kdf1_sp800_108;
+#endif
+
+} TPMU_KDF_SCHEME;
+
+// Table 150 -- TPMT_KDF_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_KDF       scheme;
+    TPMU_KDF_SCHEME    details;
+} TPMT_KDF_SCHEME;
+typedef TPM_ALG_ID TPMI_ALG_ASYM_SCHEME;
+
+// Table 152 -- TPMU_ASYM_SCHEME Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_RSASSA
+    TPMS_SCHEME_RSASSA  rsassa;
+#endif
+#ifdef TPM2_ALG_RSAPSS
+    TPMS_SCHEME_RSAPSS  rsapss;
+#endif
+#ifdef TPM2_ALG_OAEP
+    TPMS_SCHEME_OAEP  oaep;
+#endif
+#ifdef TPM2_ALG_ECDSA
+    TPMS_SCHEME_ECDSA  ecdsa;
+#endif
+#ifdef TPM2_ALG_SM2
+    TPMS_SCHEME_SM2  sm2;
+#endif
+#ifdef TPM2_ALG_ECDAA
+    TPMS_SCHEME_ECDAA  ecdaa;
+#endif
+#ifdef TPM2_ALG_ECSCHNORR
+    TPMS_SCHEME_ECSCHNORR  ecSchnorr;
+#endif
+    TPMS_SCHEME_SIGHASH  anySig;
+} TPMU_ASYM_SCHEME;
+
+typedef struct {
+    TPMI_ALG_ASYM_SCHEME    scheme;
+    TPMU_ASYM_SCHEME        details;
+} TPMT_ASYM_SCHEME;
+
+// Table 154 -- TPMI_ALG_RSA_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_RSA_SCHEME;
+
+// Table 155 -- TPMT_RSA_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_RSA_SCHEME    scheme;
+    TPMU_ASYM_SCHEME       details;
+} TPMT_RSA_SCHEME;
+
+// Table 156 -- TPMI_ALG_RSA_DECRYPT Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_RSA_DECRYPT;
+
+// Table 157 -- TPMT_RSA_DECRYPT Structure <I/O>
+typedef struct {
+    TPMI_ALG_RSA_DECRYPT    scheme;
+    TPMU_ASYM_SCHEME        details;
+} TPMT_RSA_DECRYPT;
+
+// Table 158 -- TPM2B_PUBLIC_KEY_RSA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_RSA_KEY_BYTES];
+} TPM2B_PUBLIC_KEY_RSA;
+
+// Table 159 -- TPMI_RSA_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_RSA_KEY_BITS;
+
+// Table 160 -- TPM2B_PRIVATE_KEY_RSA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_RSA_KEY_BYTES/2];
+} TPM2B_PRIVATE_KEY_RSA;
+
+// Table 162 -- TPM2B_ECC_PARAMETER
+typedef struct {
+    UINT16 size;
+    BYTE buffer[MAX_ECC_KEY_BYTES];
+} TPM2B_ECC_PARAMETER;
+
+// Table 163 -- TPMS_ECC_POINT Structure <I/O>
+typedef struct {
+    TPM2B_ECC_PARAMETER    x;
+    TPM2B_ECC_PARAMETER    y;
+} TPMS_ECC_POINT;
+
+// Table 164 -- TPMI_ALG_ECC_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_ECC_SCHEME;
+
+typedef UINT16 TPM_ECC_CURVE;
+
+// Table 165 -- TPMI_ECC_CURVE Type <I/O>
+typedef TPM_ECC_CURVE TPMI_ECC_CURVE;
+
+// Table 166 -- TPMT_ECC_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_ECC_SCHEME    scheme;
+    TPMU_SIG_SCHEME        details;
+} TPMT_ECC_SCHEME;
+
+// Table 175 -- TPMI_ALG_PUBLIC Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_PUBLIC;
+
+// Table 176 -- TPMU_PUBLIC_ID Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_KEYEDHASH
+    TPM2B_DIGEST  keyedHash;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPM2B_DIGEST  sym;
+#endif
+#ifdef TPM2_ALG_RSA
+    TPM2B_PUBLIC_KEY_RSA  rsa;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPMS_ECC_POINT  ecc;
+#endif
+} TPMU_PUBLIC_ID;
+
+// Table 177 -- TPMS_KEYEDHASH_PARMS Structure <I/O>
+typedef struct {
+    TPMT_KEYEDHASH_SCHEME    scheme;
+} TPMS_KEYEDHASH_PARMS;
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_ASYM_SCHEME       scheme;
+} TPMS_ASYM_PARMS;
+
+// Table 179 -- TPMS_RSA_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_RSA_SCHEME        scheme;
+    TPMI_RSA_KEY_BITS      keyBits;
+    UINT32                 exponent;
+} TPMS_RSA_PARMS;
+
+// Table 180 -- TPMS_ECC_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_ECC_SCHEME        scheme;
+    TPMI_ECC_CURVE         curveID;
+    TPMT_KDF_SCHEME        kdf;
+} TPMS_ECC_PARMS;
+
+// Table 181 -- TPMU_PUBLIC_PARMS Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_KEYEDHASH
+    TPMS_KEYEDHASH_PARMS  keyedHashDetail;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPMT_SYM_DEF_OBJECT  symDetail;
+#endif
+#ifdef TPM2_ALG_RSA
+    TPMS_RSA_PARMS  rsaDetail;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPMS_ECC_PARMS  eccDetail;
+#endif
+    TPMS_ASYM_PARMS  asymDetail;
+} TPMU_PUBLIC_PARMS;
+
+// Table 182 -- TPMT_PUBLIC_PARMS Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC      type;
+    TPMU_PUBLIC_PARMS    parameters;
+} TPMT_PUBLIC_PARMS;
+
+// Table 183 -- TPMT_PUBLIC Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC      type;
+    TPMI_ALG_HASH        nameAlg;
+    TPMA_OBJECT          objectAttributes;
+    TPM2B_DIGEST         authPolicy;
+    TPMU_PUBLIC_PARMS    parameters;
+    TPMU_PUBLIC_ID       unique;
+} TPMT_PUBLIC;
+
+// Table 184 -- TPM2B_PUBLIC
+typedef struct {
+    UINT16         size;
+    TPMT_PUBLIC    publicArea;
+} TPM2B_PUBLIC;
+
+// Table 185 -- TPMU_SENSITIVE_COMPOSITE Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_RSA
+    TPM2B_PRIVATE_KEY_RSA  rsa;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPM2B_ECC_PARAMETER  ecc;
+#endif
+#ifdef TPM2_ALG_KEYEDHASH
+    TPM2B_SENSITIVE_DATA  bits;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPM2B_SYM_KEY  sym;
+#endif
+    TPM2B_SENSITIVE_DATA  any;
+} TPMU_SENSITIVE_COMPOSITE;
+
+// Table 186 -- TPMT_SENSITIVE Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC             sensitiveType;
+    TPM2B_AUTH                  authValue;
+    TPM2B_DIGEST                seedValue;
+    TPMU_SENSITIVE_COMPOSITE    sensitive;
+} TPMT_SENSITIVE;
+
+// Table 187 -- TPM2B_SENSITIVE Structure <I/O>
+typedef struct {
+    UINT16            size;
+    TPMT_SENSITIVE    sensitiveArea;
+} TPM2B_SENSITIVE;
+
+typedef struct {
+    TPM2B_DIGEST      integrityOuter;
+    TPM2B_DIGEST      integrityInner;
+    TPMT_SENSITIVE    sensitive;
+} _PRIVATE;
+
+// Table 189 -- TPM2B_PRIVATE Structure <I/O,S>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[sizeof(_PRIVATE)];
+} TPM2B_PRIVATE;
+
+// Table 204 -- TPMS_CREATION_DATA <OUT>
+typedef struct {
+    TPML_PCR_SELECTION    pcrSelect;
+    TPM2B_DIGEST          pcrDigest;
+    TPMA_LOCALITY         locality;
+    TPM_ALG_ID            parentNameAlg;
+    TPM2B_NAME            parentName;
+    TPM2B_NAME            parentQualifiedName;
+    TPM2B_DATA            outsideInfo;
+} TPMS_CREATION_DATA;
+
+// Table 205 -- TPM2B_CREATION_DATA <OUT>
+typedef struct {
+    UINT16 size;
+    TPMS_CREATION_DATA creationData;
+} TPM2B_CREATION_DATA;
+
+/* the following structs is not part of standard struct defined in TPM2 spec */
+typedef struct {
+    UINT32            size;
+    TPM_RH            sessionHandle;
+    TPM2B_NONCE       nonce;
+    TPMA_SESSION      sessionAttributes;
+    TPM2B_AUTH        auth;
+} TPM_AuthArea;
+
+typedef struct {
+    TPM2B_SENSITIVE_CREATE  inSensitive;
+    TPM2B_PUBLIC            inPublic;
+    TPM2B_DATA              outsideInfo;
+    TPML_PCR_SELECTION      creationPCR;
+} TPM2_Create_Params_in;
+
+typedef TPM2_Create_Params_in    TPM2_CreatePrimary_Params_in;
+
+typedef struct {
+    TPM2B_PUBLIC        outPublic;
+    TPM2B_CREATION_DATA creationData;
+    TPM2B_DIGEST        creationHash;
+    TPMT_TK_CREATION    creationTicket;
+    TPM2B_NAME          name;
+} TPM2_CreatePrimary_Params_out;
+
+typedef struct {
+    TPM2B_PRIVATE       outPrivate;
+    TPM2B_PUBLIC        outPublic;
+    TPM2B_CREATION_DATA creationData;
+    TPM2B_DIGEST        creationHash;
+    TPMT_TK_CREATION    creationTicket;
+} TPM2_Create_Params_out;
+typedef struct {
+    TPM2B_PRIVATE    Private;
+    TPM2B_PUBLIC     Public;
+} TPM2_RSA_KEY;
+
+/*
+ * TPM 2.0 Objects
+ */
+
+#define TPM_HT_TRANSIENT        0x80
+#define HR_SHIFT                24
+#define HR_PERMANENT            (TPM_HT_TRANSIENT << HR_SHIFT)
+#define TRANSIENT_FIRST         (HR_PERMANENT)
+#define MAX_LOADED_OBJECTS      3
+#define TRANSIENT_LAST          (TRANSIENT_FIRST+MAX_LOADED_OBJECTS-1)
+/*
+ * TPMA_OBJECT Bits
+ */
+#define fixedTPM                ((1 << 1))
+#define stClear                 ((1 << 2))
+#define fixedParent             ((1 << 4))
+#define sensitiveDataOrigin     ((1 << 5))
+#define userWithAuth            ((1 << 6))
+#define adminWithPolicy         ((1 << 7))
+#define noDA                    ((1 << 10))
+#define encryptedDuplication    ((1 << 11))
+#define restricted              ((1 << 16))
+#define decrypt                 ((1 << 17))
+#define sign                    ((1 << 18))
+#endif
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnV-0007av-4t; Sun, 14 Dec 2014 16:13:29 +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 1Y0BnU-0007ad-K3
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:28 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	86/85-02696-827BD845; Sun, 14 Dec 2014 16:13:28 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418573606!14980121!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22117 invoked from network); 14 Dec 2014 16:13:27 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-13.tower-27.messagelabs.com with SMTP;
	14 Dec 2014 16:13:27 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 14 Dec 2014 08:11:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="498545877"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 14 Dec 2014 08:09:21 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:41 -0500
Message-Id: <1418558981-13531-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 05/12] vTPM/TPM2: TPM 2.0 takes ownership and
	create SRK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TPM2_CreatePrimary is used to create a Primary Object under one of
the Primary Seeds or a Temporary Object under TPM_RH_NULL. The command
uses a TPM2B_PUBLIC as a template for the object to be created. The
command will create and load a Primary Object. The sensitive area is
not returned. Any type of object and attributes combination that is
allowed by TPM2_Create() may be created by this command. The constraints
on templates and parameters are the same as TPM2_Create() except that a
Primary Storage Key and a Temporary Storage Key are not constrained to
use the algorithms of their parents.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/init.c    | 71 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.h |  3 ++
 2 files changed, 74 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index f3aa02f..c654071 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -51,6 +51,7 @@
 #include "vtpm_disk.h"
 #include "tpm.h"
 #include "marshal.h"
+#include "tpm2.h"
 
 struct Opts {
    enum {
@@ -509,3 +510,73 @@ void vtpmmgr_shutdown(void)
 
    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager stopped.\n");
 }
+
+/* TPM 2.0 */
+
+static void tpm2_AuthArea_ctor(const char *authValue, UINT32 authLen,
+                               TPM_AuthArea *auth)
+{
+    auth->sessionHandle = TPM_RS_PW;
+    auth->nonce.size = 0;
+    auth->sessionAttributes = 1;
+    auth->auth.size = authLen;
+    memcpy(auth->auth.buffer, authValue, authLen);
+    auth->size = 9 + authLen;
+}
+
+TPM_RC tpm2_take_ownership(void)
+{
+    TPM_RC status = TPM_SUCCESS;
+
+    tpm2_AuthArea_ctor(NULL, 0, &vtpm_globals.pw_auth);
+
+    /* create SRK */
+    TPM2_CreatePrimary_Params_in in = {
+        .inSensitive = {
+            .size = 4,
+            .sensitive = {
+                .userAuth.size = 0,
+                .userAuth.buffer = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\
+                                     0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+                .data.size = 0,
+            },
+        },
+        .inPublic = {
+            .size = 60,
+            .publicArea = {
+                .type = TPM2_ALG_RSA,
+                .nameAlg = TPM2_ALG_SHA256,
+#define SRK_OBJ_ATTR (fixedTPM | fixedParent  | userWithAuth | \
+                      sensitiveDataOrigin | restricted | decrypt)
+                .objectAttributes = SRK_OBJ_ATTR,
+                .authPolicy.size = 0,
+                .parameters.rsaDetail = {
+                    .symmetric = {
+                    .algorithm = TPM2_ALG_AES,
+                    .keyBits.aes = AES_KEY_SIZES_BITS,
+                    .mode.aes = TPM2_ALG_CFB,
+                    },
+                .scheme = { TPM2_ALG_NULL },
+                .keyBits = RSA_KEY_SIZES_BITS,
+                .exponent = 0,
+                },
+                .unique.rsa.size = 0,
+            },
+        },
+            .outsideInfo.size = 0,
+            .creationPCR.count = 0,
+    };
+
+    TPMTRYRETURN(TPM2_CreatePrimary(TPM_RH_OWNER,&in,
+                                    &vtpm_globals.srk_handle, NULL));
+    vtpmloginfo(VTPM_LOG_VTPM, "SRK handle: 0x%X\n", vtpm_globals.srk_handle);
+    {
+        const char data[20] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\
+                                0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+        tpm2_AuthArea_ctor(data, 20, &vtpm_globals.srk_auth_area);
+    }
+    /*end create SRK*/
+
+abort_egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 0d0c604..95519ba 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -93,4 +93,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
    return ctr_drbg_random(&vtpm_globals.ctr_drbg, bytes, num_bytes) == 0 ? 0 : TPM_FAIL;
 }
 
+/* TPM 2.0 */
+TPM_RC tpm2_take_ownership(void);
+
 #endif
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Bnm-0007nF-1U; Sun, 14 Dec 2014 16:13:46 +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 1Y0Bnk-0007ls-He
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:44 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	B3/24-02698-737BD845; Sun, 14 Dec 2014 16:13:43 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418573611!14939834!3
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 31074 invoked from network); 14 Dec 2014 16:13:42 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-27.messagelabs.com with SMTP;
	14 Dec 2014 16:13:42 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2014 08:13:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="637398655"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 14 Dec 2014 08:13:40 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:58 -0500
Message-Id: <1418558998-13755-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 11/12] vTPM/TPM2: Bind group keys and sectors
	data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/disk_write.c | 29 ++++++++++++++++++++---------
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_write.c b/stubdom/vtpmmgr/disk_write.c
index 4c825c5..73018ef 100644
--- a/stubdom/vtpmmgr/disk_write.c
+++ b/stubdom/vtpmmgr/disk_write.c
@@ -83,12 +83,18 @@ static void generate_group_seals(struct mem_group *src, const struct mem_tpm_mgr
 	if (src->nr_seals > NR_SEALS_PER_GROUP)
 		abort();
 
-	for(i=0; i < src->nr_seals; i++) {
+	for (i=0; i < src->nr_seals; i++) {
 		struct disk_seal_entry *dst = &src->seal_bits.entry[i];
-		dst->pcr_selection = src->seals[i].pcr_selection;
-		memcpy(&dst->digest_release, &src->seals[i].digest_release, 20);
-		TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
-		TPM_disk_seal(dst, &sblob, sizeof(sblob));
+
+        /*TPM 2.0 bind | TPM 1.x seal*/
+        if (hw_is_tpm2()) {
+            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+        } else {
+            dst->pcr_selection = src->seals[i].pcr_selection;
+            memcpy(&dst->digest_release, &src->seals[i].digest_release, 20);
+            TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
+            TPM_disk_seal(dst, &sblob, sizeof(sblob));
+        }
 	}
 	src->seal_bits.nr_cfgs = native_be32(src->nr_seals);
 
@@ -246,11 +252,16 @@ static void disk_write_seal_list(struct mem_tpm_mgr *mgr, struct mem_group *grou
 	for(i=0; i < group->nr_seals; i++) {
 		struct mem_seal *src = &group->seals[i];
 		struct disk_seal_entry *dst = &seal->entry[i];
-		dst->pcr_selection = src->pcr_selection;
-		memcpy(&dst->digest_release, &src->digest_release, 20);
-		TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
 
-		TPM_disk_seal(dst, &sblob, sizeof(sblob));
+        /*TPM 2.0 bind / TPM 1.x seal*/
+        if (hw_is_tpm2()) {
+            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+        } else {
+            dst->pcr_selection = src->pcr_selection;
+            memcpy(&dst->digest_release, &src->digest_release, 20);
+            TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
+            TPM_disk_seal(dst, &sblob, sizeof(sblob));
+        }
 	}
 
 	memcpy(seal->hdr.magic, TPM_MGR_MAGIC, 12);
-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnY-0007ch-Hw; Sun, 14 Dec 2014 16:13:32 +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 1Y0BnX-0007bx-3n
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:31 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	B0/2B-19763-A27BD845; Sun, 14 Dec 2014 16:13:30 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418573602!13228416!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19427 invoked from network); 14 Dec 2014 16:13:29 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-206.messagelabs.com with SMTP;
	14 Dec 2014 16:13:29 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 14 Dec 2014 08:13:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="647434646"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 14 Dec 2014 08:13:27 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:45 -0500
Message-Id: <1418558985-13568-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
MIME-Version: 1.0
Content-Length: 6274
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 06/12] vTPM/TPM2: Create and load SK on TPM 2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VFBNMl9DcmVhdGUgaXMgdXNlZCB0byBjcmVhdGUgYW4gb2JqZWN0IHRoYXQgY2FuIGJlIGxvYWRl
ZCBpbnRvIGEKVFBNIHVzaW5nIFRQTTJfTG9hZCgpLiBJZiB0aGUgY29tbWFuZCBjb21wbGV0ZXMg
c3VjY2Vzc2Z1bGx5LCB0aGUKVFBNIHdpbGwgY3JlYXRlIHRoZSBuZXcgb2JqZWN0IGFuZCByZXR1
cm4gdGhlIG9iamVjdOKAmXMgY3JlYXRpb24uCmRhdGEgKGNyZWF0aW9uRGF0YSksIGl0cyBwdWJs
aWMgYXJlYSAob3V0UHVibGljKSwgYW5kIGl0cyBlbmNyeXB0ZWQKc2Vuc2l0aXZlIGFyZWEgKG91
dFByaXZhdGUpLiBQcmVzZXJ2YXRpb24gb2YgdGhlIHJldHVybmVkIGRhdGEgaXMKdGhlIHJlc3Bv
bnNpYmlsaXR5IG9mIHRoZSBjYWxsZXIuIFRoZSBvYmplY3Qgd2lsbCBuZWVkIHRvIGJlIGxvYWRl
ZAooVFBNMl9Mb2FkKCkpLgpUUE0yX0xvYWQgaXMgdXNlZCB0byBsb2FkIG9iamVjdHMgaW50byB0
aGUgVFBNLiBUaGlzIGNvbW1hbmQgaXMgdXNlZAp3aGVuIGJvdGggYSBUUE0yQl9QVUJMSUMgYW5k
IFRQTTJCX1BSSVZBVEUgYXJlIHRvIGJlIGxvYWRlZC4gSWYgb25seQphIFRQTTJCX1BVQkxJQyBp
cyB0byBiZSBsb2FkZWQsIHRoZSBUUE0yX0xvYWRFeHRlcm5hbCBjb21tYW5kIGlzIHVzZWQuCgpT
aWduZWQtb2ZmLWJ5OiBRdWFuIFh1IDxxdWFuLnh1QGludGVsLmNvbT4KLS0tCiBzdHViZG9tL3Z0
cG1tZ3IvaW5pdC5jICAgIHwgMTAxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysKIHN0dWJkb20vdnRwbW1nci92dHBtbWdyLmggfCAgIDEgKwogMiBmaWxlcyBj
aGFuZ2VkLCAxMDIgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3N0dWJkb20vdnRwbW1nci9p
bml0LmMgYi9zdHViZG9tL3Z0cG1tZ3IvaW5pdC5jCmluZGV4IGM2NTQwNzEuLjgyNDRiYjAgMTAw
NjQ0Ci0tLSBhL3N0dWJkb20vdnRwbW1nci9pbml0LmMKKysrIGIvc3R1YmRvbS92dHBtbWdyL2lu
aXQuYwpAQCAtNTgwLDMgKzU4MCwxMDQgQEAgVFBNX1JDIHRwbTJfdGFrZV9vd25lcnNoaXAodm9p
ZCkKIGFib3J0X2VncmVzczoKICAgICByZXR1cm4gc3RhdHVzOwogfQorCitUUE1fUkVTVUxUIHZ0
cG1tZ3IyX2NyZWF0ZSh2b2lkKQoreworICAgIFRQTV9SRVNVTFQgc3RhdHVzID0gVFBNX1NVQ0NF
U1M7CisKKyAgICBUUE1UUllSRVRVUk4odHBtMl90YWtlX293bmVyc2hpcCgpKTsKKworICAgLyog
Y3JlYXRlIFNLICovCisgICAgVFBNMl9DcmVhdGVfUGFyYW1zX291dCBvdXQ7CisgICAgVFBNMl9D
cmVhdGVfUGFyYW1zX2luIGluID0geworICAgICAgICAuaW5TZW5zaXRpdmUgPSB7CisgICAgICAg
ICAgICAuc2l6ZSA9IDQgKyAyMCwKKyAgICAgICAgICAgIC5zZW5zaXRpdmUgPSB7CisgICAgICAg
ICAgICAgICAgLnVzZXJBdXRoLnNpemUgPSAyMCwKKyAgICAgICAgICAgICAgICAudXNlckF1dGgu
YnVmZmVyID0geyAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLFwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwIH0sCisg
ICAgICAgICAgICAgICAgLmRhdGEuc2l6ZSA9IDAsCisgICAgICAgICAgICB9LAorICAgICAgICB9
LAorICAgICAgICAuaW5QdWJsaWMgPSB7CisgICAgICAgICAgICAuc2l6ZSA9ICg2MCksCisgICAg
ICAgICAgICAucHVibGljQXJlYSA9IHsKKyAgICAgICAgICAgICAgICAgLnR5cGUgPSBUUE0yX0FM
R19SU0EsCisgICAgICAgICAgICAgICAgIC5uYW1lQWxnID0gVFBNMl9BTEdfU0hBMjU2LAorI2Rl
ZmluZSBTS19PQkpfQVRUUiAoZml4ZWRUUE0gfCBmaXhlZFBhcmVudCB8IHVzZXJXaXRoQXV0aCB8
XAorICAgICAgICAgICAgICAgICAgICAgc2Vuc2l0aXZlRGF0YU9yaWdpbiB8ZGVjcnlwdCkKKyAg
ICAgICAgICAgICAgICAgLm9iamVjdEF0dHJpYnV0ZXMgPSBTS19PQkpfQVRUUiwKKyAgICAgICAg
ICAgICAgICAgLmF1dGhQb2xpY3kuc2l6ZSA9IDAsCisgICAgICAgICAgICAgICAgIC5wYXJhbWV0
ZXJzLnJzYURldGFpbCA9IHsKKyAgICAgICAgICAgICAgICAgICAgIC5zeW1tZXRyaWMgPSB7Cisg
ICAgICAgICAgICAgICAgICAgICAgICAgLmFsZ29yaXRobSA9IFRQTTJfQUxHX05VTEwsCisgICAg
ICAgICAgICAgICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgICAgLnNjaGVtZSA9IHsKKyAg
ICAgICAgICAgICAgICAgICAgICAgICBUUE0yX0FMR19PQUVQLAorICAgICAgICAgICAgICAgICAg
ICAgICAgIC5kZXRhaWxzLm9hZXAuaGFzaEFsZyA9IFRQTTJfQUxHX1NIQTI1NiwKKyAgICAgICAg
ICAgICAgICAgICAgIH0sCisgICAgICAgICAgICAgICAgICAgICAua2V5Qml0cyA9IFJTQV9LRVlf
U0laRVNfQklUUywKKyAgICAgICAgICAgICAgICAgICAgIC5leHBvbmVudCA9IDAsCisgICAgICAg
ICAgICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgLnVuaXF1ZS5yc2Euc2l6ZSA9IDAsCisg
ICAgICAgICAgICB9LAorICAgICAgICB9LAorICAgICAgICAub3V0c2lkZUluZm8uc2l6ZSA9IDAs
CisgICAgICAgIC5jcmVhdGlvblBDUi5jb3VudCA9IDAsCisgICAgfTsvKmVuZCBpbiAqLworCisg
ICAgVFBNVFJZUkVUVVJOKFRQTTJfQ3JlYXRlKHZ0cG1fZ2xvYmFscy5zcmtfaGFuZGxlLCAmaW4s
ICZvdXQpKTsKKyAgICBUUE1UUllSRVRVUk4oVFBNMl9Mb2FkKHZ0cG1fZ2xvYmFscy5zcmtfaGFu
ZGxlLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZ0cG1fZ2xvYmFscy50cG0yX3N0b3Jh
Z2Vfa2V5LlByaXZhdGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAmdnRwbV9nbG9iYWxz
LnRwbTJfc3RvcmFnZV9rZXkuUHVibGljLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZ0
cG1fZ2xvYmFscy5za19oYW5kbGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAmdnRwbV9n
bG9iYWxzLnNrX25hbWUpKTsKKworICAgIHZ0cG1sb2dpbmZvKFZUUE1fTE9HX1ZUUE0sICJTSyBI
QU5ETEU6IDB4JVhcbiIsIHZ0cG1fZ2xvYmFscy5za19oYW5kbGUpOworICAgIC8qZW5kIGNyZWF0
ZSBTSyovCisKKyNpZiAwIC8qQmluZCAmIHVuQmluZCovCit7CisgICAgdW5zaWduZWQgY2hhciBy
YW5kWzIwXTsKKyAgICB1bnNpZ25lZCBjaGFyIGNpcGhlclsyNTZdLCBvdXRbMjU2XTsKKyAgICB2
dHBtbWdyX3JhbmQocmFuZCwgMjApOworICAgIGludCBpOworICAgIFVJTlQzMiBvbGVuOworCisg
ICAgcHJpbnRrKCJyYW5kOiAiKTsKKyAgICBmb3IgKGkgPSAwOyBpIDwgMjA7IGkrKykgeworICAg
ICAgICAgcHJpbnRrKCIgJXUgIiwgcmFuZFtpXSk7CisgICAgfQorICAgIHByaW50aygiXG4iKTsK
KyAgICBUUE1UUllSRVRVUk4oVFBNMl9CaW5kKHZ0cG1fZ2xvYmFscy5za19oYW5kbGUsCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICByYW5kLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg
MjAsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBjaXBoZXIpKTsKKyAgICBwcmludGsoImNp
cGhlciA6ICIpOworICAgIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykgeworICAgICAgICAgcHJp
bnRrKCIlMDJ4IiwgY2lwaGVyW2ldKTsKKyAgICB9CisgICAgcHJpbnRrKCJcbiIpOworICAgIFRQ
TVRSWVJFVFVSTihUUE0yX1VuQmluZCh2dHBtX2dsb2JhbHMuc2tfaGFuZGxlLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAyNTYsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNp
cGhlciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJm9sZW4sCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG91dCkpOworICAgIHByaW50aygib2xlbiA6ICVkIFxuIiwgb2xlbik7
CisgICAgcHJpbnRrKCJvdXQgOiAiKTsKKyAgICBmb3IgKGkgPSAwOyBpIDwgb2xlbjsgaSsrKQor
ICAgICAgICAgcHJpbnRrKCIgJXUgIiwgb3V0W2ldKTsKKyAgICBwcmludGsoIlxuIik7Cit9Cisj
ZW5kaWYKKworICAgIC8qQ3JlYXRlIG5ldyBkaXNrIGltYWdlKi8KKyAgICBUUE1UUllSRVRVUk4o
dnRwbV9uZXdfZGlzaygpKTsKKworICAgIGdvdG8gZWdyZXNzOworCithYm9ydF9lZ3Jlc3M6Citl
Z3Jlc3M6CisgICAgdnRwbWxvZ2luZm8oVlRQTV9MT0dfVlRQTSwgIkZpbmlzaGVkIGluaXRpYWxp
emVkIG5ldyBWVFBNIG1hbmFnZXJcbiIpOworICAgIHJldHVybiBzdGF0dXM7Cit9CmRpZmYgLS1n
aXQgYS9zdHViZG9tL3Z0cG1tZ3IvdnRwbW1nci5oIGIvc3R1YmRvbS92dHBtbWdyL3Z0cG1tZ3Iu
aAppbmRleCA5NTUxOWJhLi45ODg5ZmViIDEwMDY0NAotLS0gYS9zdHViZG9tL3Z0cG1tZ3IvdnRw
bW1nci5oCisrKyBiL3N0dWJkb20vdnRwbW1nci92dHBtbWdyLmgKQEAgLTk1LDUgKzk1LDYgQEAg
aW5saW5lIFRQTV9SRVNVTFQgdnRwbW1ncl9yYW5kKHVuc2lnbmVkIGNoYXIqIGJ5dGVzLCBzaXpl
X3QgbnVtX2J5dGVzKSB7CiAKIC8qIFRQTSAyLjAgKi8KIFRQTV9SQyB0cG0yX3Rha2Vfb3duZXJz
aGlwKHZvaWQpOworVFBNX1JFU1VMVCB2dHBtbWdyMl9jcmVhdGUodm9pZCk7CiAKICNlbmRpZgot
LSAKMS44LjMuMgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sun Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0BnH-0007XY-Fo; Sun, 14 Dec 2014 16:13:15 +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 1Y0BnF-0007XT-TP
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:14 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	53/EB-16982-917BD845; Sun, 14 Dec 2014 16:13:13 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418573591!13267064!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 11264 invoked from network); 14 Dec 2014 16:13:11 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-3.tower-31.messagelabs.com with SMTP;
	14 Dec 2014 16:13:11 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga102.jf.intel.com with ESMTP; 14 Dec 2014 08:11:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="498545825"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 14 Dec 2014 08:09:05 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:25 -0500
Message-Id: <1418558965-13342-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
MIME-Version: 1.0
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 00/12] Enable vTPM subsystem on TPM 2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series of patch enable the virtual Trusted Platform Module (vTPM)
subsystem for Xen on TPM 2.0.

Noted, functionality for a virtual guest operating system (a DomU) is still
TPM 1.2. The main modifcation is on vtpmmgr-stubdom. The challenge is that
TPM 2.0 is not backward compatibility with TPM 1.2.

------------------------------
DESIGN OVERVIEW
------------------------------
The architecture of vTPM subsystem on TPM 2.0 is described below:

+------------------+
|    Linux DomU    | ...
|       |  ^       |
|       v  |       |
|   xen-tpmfront   |
+------------------+
        |  ^
        v  |
+------------------+
| mini-os/tpmback  |
|       |  ^       |
|       v  |       |
|  vtpm-stubdom    | ...
|       |  ^       |
|       v  |       |
| mini-os/tpmfront |
+------------------+
        |  ^
        v  |
+------------------+
| mini-os/tpmback  |
|       |  ^       |
|       v  |       |
| vtpmmgr-stubdom  |
|       |  ^       |
|       v  |       |
| mini-os/tpm2_tis |
+------------------+
        |  ^
        v  |
+------------------+
| Hardware TPM 2.0 |
+------------------+
 * Linux DomU: The Linux based guest that wants to use a vTPM. There many be
               more than one of these.

 * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver
                    provides vTPM access to a para-virtualized Linux based DomU.

 * 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.  This domain regulates
               access to the physical TPM on the system and secures the
               persistent state of each vTPM.

 * mini-os/tpm2_tis: Mini-os TPM version 2.0 TPM Interface Specification (TIS)
                    driver. This driver used by vtpmmgr-stubdom to talk directly
                    to the hardware TPM 2.0. Communication is facilitated by mapping
                    hardware memory pages into vtpmmgr-stubdom.

 * Hardware TPM 2.0: The physical TPM 2.0 that is soldered onto the motherboard.

------------------------------
Key Hierarchy
------------------------------

    +------------------+
    |  vTPM's secrets  | ...
    +------------------+
            |  ^
            |  |(Bind / Unbind)
- - - - -  -v  |- - - - - - - - TPM 2.0
    +------------------+
    |        SK        +
    +------------------+
            |  ^
            v  |
    +------------------+
    |       SRK        |
    +------------------+
            |  ^
            v  |
    +------------------+
    | TPM 2.0 Storage  |
    |   Primary Seed   |
    +------------------+

------------------------------
INSTALLATION
------------------------------

Prerequisites:
--------------
You must have an x86 machine with a TPM on the motherboard.  The only extra
software requirement for compiling vTPM is cmake.  You must use libxl to manage
domains with vTPMs; 'xm' is deprecated and does not support vTPMs.

Compiling the Xen tree:
-----------------------

Compile and install the Xen tree as usual; be sure that the vTPM domains are
enabled when you run configure.

Compiling the LINUX dom0 kernel:
--------------------------------

Because the TPM manager uses direct access to the physical TPM, it may interfere
with access to the TPM by dom0.  The simplest solution for this is to prevent
dom0 from accessing the physical TPM by compiling the kernel without a driver or
blacklisting the module.

Compiling the LINUX domU kernel:
--------------------------------

The domU kernel used by domains with vtpms must include the xen-tpmfront.ko
driver. It can be built directly into the kernel or as a module; however, some
features such as IMA require the TPM to be built in to the kernel.

CONFIG_TCG_TPM=y
CONFIG_TCG_XEN=y

------------------------------
VTPM MANAGER SETUP
------------------------------

Manager disk image setup:
-------------------------

The vTPM Manager requires a disk image to store its encrypted data. The image
does not require a filesystem and can live anywhere on the host disk. The image
is not large; the Xen 4.5 vtpmmgr is limited to using the first 2MB of the image
but can support more than 20,000 vTPMs.

 dd if=/dev/zero of=/home/vtpm2/vmgr bs=16M count=1

Manager config file:
--------------------

The vTPM Manager domain (vtpmmgr-stubdom) must be started like any other Xen
virtual machine and requires a config file.  The manager requires a disk image
for storage and permission to access the hardware memory pages for the TPM. The
disk must be presented as "hda", and the TPM memory pages are passed using the
iomem configuration parameter. The TPM TIS uses 5 pages of IO memory (one per
locality) that start at physical address 0xfed40000. By default, the TPM manager
uses locality 0 (so only the page at 0xfed40 is needed).

Add:
..
     extra="--tpm2"
..
extra option to launch vtpm-stubdom domain on TPM 2.0, and ignore it on TPM 1.x.

for example:

    kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
    memory=128
    disk=["file:/home/vtpm2/vmgr,hda,w"]
    name="vtpmmgr"
    iomem=["fed40,5"]
    extra="--tpm2"

------------------------------
VTPM AND LINUX PVM SETUP
------------------------------
vTPM disk image setup:
----------------------

The vTPM requires a disk image to store its persistent data (RSA keys, NVRAM,
etc). The image does not require a filesystem. The image does not need to be
large; 2 Mb should be sufficient.

    dd if=/dev/zero of=/home/vtpm2/vtpm0 bs=2M count=1

vTPM config file:
-----------------

The vTPM domain requires a configuration file like any other domain. The vTPM
requires a disk image for storage and a TPM frontend driver to communicate with
the manager.  You are required to generate a uuid for this vtpm, which is
specified on the "vtpm=" line that describes its connection to the vTPM Manager.
for example:

    kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
    memory=8
    disk=["file:/home/vtpm2/vtpm0,hda,w"]
    name="vtpm0"
    vtpm=["backend=vtpmmgr,uuid=914fe389-e2c5-44e6-993f-2189637cf1de"]

If you wish to clear the vTPM data you can either recreate the disk image or
change the uuid.

Linux Guest config file:
------------------------
The Linux guest config file needs to be modified to include the Linux tpmfront
driver. Add the following line:

vtpm=["backend=vtpm0"]

Currently only Linux guests are supported (PV or HVM with PV drivers). My series
of patch for HVM virtual mahcine are still being reviewed and modifcated.

Using the vTPM in the guest:
----------------------------

If xen-tpmfront was compiled as a module, it must be loaded it in the guest.

# modprobe xen-tpmfront

After the Linux domain boots and the xen-tpmfront driver is loaded, you should
see the following on the vtpm console:

Info: VTPM attached to Frontend X/Y

You can quickly test the vTPM by using the sysfs interface:

# cat /sys/devices/vtpm-0/pubek
# cat /sys/devices/vtpm-0/pcrs
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

You should also see the command being sent to the vtpm console as well as the
vtpm saving its state. You should see the vtpm key being encrypted and stored on
the vtpmmgr console.

You may wish to write a script to start your vtpm and guest together and to
destroy the vtpm when the guest shuts down.

------------------------------
INTEGRATION WITH PV-GRUB
------------------------------

The vTPM currently starts up with all PCRs set to their default values (all
zeros for the lower 16).  This means that any decisions about the
trustworthiness of the created domain must be made based on the environment that
created the vTPM and the domU; for example, a system that only constructs images
using a trusted configuration and guest kernel be able to provide guarantees
about the guests and any measurements done that kernel (such as the IMA TCB
log).  Guests wishing to use a custom kernel in such a secure environment are
often started using the pv-grub bootloader as the kernel, which then can load
the untrusted kernel without needing to parse an untrusted filesystem and kernel
in dom0.  If the pv-grub stub domain succeeds in connecting to a vTPM, it will
extend the hash of the kernel that it boots into PCR #4, and will extend the
command line and initrd into PCR #5 before booting so that a domU booted in this
way can attest to its early boot state.

------------------------------
REFERENCES
------------------------------

Berlios TPM Emulator:
http://tpm-emulator.berlios.de/
Xen docs/misc/vtpm.txt
Xen docs/misc/vtpm-platforms.txt
Xen docs/misc/vtpmmgr.txt


Quan Xu (12):
  vTPM/TPM2: Add TPM 2.0 data structures and commands definition
  vTPM/TPM2: TPM 2.0 data structures marshal
  vTPM/TPM2: Add global data in vtpm_globals{}
  vTPM/TPM2: Add TPM 2.0 Exposed APIs
  vTPM/TPM2: TPM 2.0 takes ownership and create SRK
  vTPM/TPM2: Create and load SK on TPM 2.0
  vTPM/TPM2: TPM2.0 TIS initialization and self test.
  vTPM/TPM2: Add main entrance vtpmmgr2_init()
  vTPM/TPM2: Support '--tpm2' extra command line.
  vTPM/TPM2: Support TPM 2.0 bind and unbind data
  vTPM/TPM2: Bind group keys and sectors data on disk
  vTPM/TPM2: Unind group keys and sectors data on disk

 extras/mini-os/include/tpm_tis.h |   1 +
 extras/mini-os/tpm_tis.c         | 156 +++++++
 stubdom/vtpmmgr/Makefile         |   2 +-
 stubdom/vtpmmgr/disk_read.c      |  28 +-
 stubdom/vtpmmgr/disk_tpm.c       |  42 +-
 stubdom/vtpmmgr/disk_tpm.h       |   4 +
 stubdom/vtpmmgr/disk_write.c     |  29 +-
 stubdom/vtpmmgr/init.c           | 282 +++++++++++
 stubdom/vtpmmgr/tpm2.c           | 455 ++++++++++++++++++
 stubdom/vtpmmgr/tpm2.h           | 104 +++++
 stubdom/vtpmmgr/tpm2_marshal.h   | 673 +++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2_types.h     | 978 +++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.c        |  46 +-
 stubdom/vtpmmgr/vtpmmgr.h        |  28 ++
 14 files changed, 2802 insertions(+), 26 deletions(-)
 create mode 100644 stubdom/vtpmmgr/tpm2.c
 create mode 100644 stubdom/vtpmmgr/tpm2.h
 create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h
 create mode 100644 stubdom/vtpmmgr/tpm2_types.h

-- 
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 Dec 14 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Bni-0007kb-KR; Sun, 14 Dec 2014 16:13:42 +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 1Y0Bnh-0007jn-S2
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:41 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	B8/8C-02702-537BD845; Sun, 14 Dec 2014 16:13:41 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418573620!14971544!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26763 invoked from network); 14 Dec 2014 16:13:40 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-14.tower-27.messagelabs.com with SMTP;
	14 Dec 2014 16:13:40 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 14 Dec 2014 08:13:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="647434702"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 14 Dec 2014 08:13:38 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:09:56 -0500
Message-Id: <1418558996-13718-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 10/12] vTPM/TPM2: Support TPM 2.0 bind and
	unbind 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bind data with TPM2_RSA_Encrypt, which performs RSA encryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1). If the
scheme of keyHandle is TPM_ALG_NULL, then the caller may use inScheme
to specify the padding scheme.
Unbind data with TPM2_RSA_Decrypt, which performs RSA decryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1).

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/disk_tpm.c | 42 ++++++++++++++++++++++++++++++++++++++++--
 stubdom/vtpmmgr/disk_tpm.h |  4 ++++
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_tpm.c b/stubdom/vtpmmgr/disk_tpm.c
index d650fbc..2e33eac 100644
--- a/stubdom/vtpmmgr/disk_tpm.c
+++ b/stubdom/vtpmmgr/disk_tpm.c
@@ -12,17 +12,20 @@
 #include <polarssl/sha1.h>
 
 #include "tpm.h"
+#include "tpm2.h"
 #include "tcg.h"
 
 #include "vtpmmgr.h"
 #include "vtpm_disk.h"
 #include "disk_tpm.h"
 
+#include "log.h"
 // Print out input/output of seal/unseal operations (includes keys)
 #undef DEBUG_SEAL_OPS
 
 #ifdef DEBUG_SEAL_OPS
 #include "marshal.h"
+#include "tpm2_marshal.h"
 #endif
 
 struct pcr_list {
@@ -31,11 +34,16 @@ struct pcr_list {
 
 static struct pcr_list hwtpm;
 
+/*Ignore PCR on TPM 2.0, read PCR values for TPM 1.x seal | unseal*/
 void TPM_read_pcrs(void)
 {
 	int i;
-	for(i=0; i < 24; i++)
-		TPM_PCR_Read(i, &hwtpm.pcrs[i]);
+	for (i=0; i < 24; i++) {
+        if (hw_is_tpm2())
+            memset(&hwtpm.pcrs[i], 0, TPM_DIGEST_SIZE);
+        else
+		    TPM_PCR_Read(i, &hwtpm.pcrs[i]);
+    }
 }
 
 struct pcr_composite_3 {
@@ -138,6 +146,36 @@ int TPM_disk_seal(struct disk_seal_entry *dst, const void* src, size_t size)
 	return rc;
 }
 
+TPM_RC TPM2_disk_bind(struct disk_seal_entry *dst, void* src, unsigned int size)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+
+    TPMTRYRETURN(TPM2_Bind(vtpm_globals.sk_handle,
+                           src,
+                           size,
+                           dst->sealed_data));
+
+abort_egress:
+egress:
+   return status;
+}
+
+TPM_RC TPM2_disk_unbind(void *dst, unsigned int *size, const struct disk_seal_entry *src)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+    unsigned char buf[RSA_CIPHER_SIZE];
+
+    memcpy(buf, src->sealed_data, RSA_CIPHER_SIZE);
+    TPMTRYRETURN(TPM2_UnBind(vtpm_globals.sk_handle,
+                             RSA_CIPHER_SIZE,
+                             buf,
+                             size,
+                             dst));
+abort_egress:
+egress:
+   return status;
+}
+
 int TPM_disk_unseal(void *dst, size_t size, const struct disk_seal_entry *src)
 {
 	uint32_t rc;
diff --git a/stubdom/vtpmmgr/disk_tpm.h b/stubdom/vtpmmgr/disk_tpm.h
index b235895..57ae2a6 100644
--- a/stubdom/vtpmmgr/disk_tpm.h
+++ b/stubdom/vtpmmgr/disk_tpm.h
@@ -10,6 +10,10 @@ void TPM_pcr_digest(struct hash160 *buf, le32_t selection);
 int TPM_disk_seal(struct disk_seal_entry *dst, const void* src, size_t size);
 int TPM_disk_unseal(void *dst, size_t size, const struct disk_seal_entry *src);
 
+/*TPM 2.0 Bind and Unbind */
+TPM_RC TPM2_disk_bind(struct disk_seal_entry *dst, void* src, unsigned int size);
+TPM_RC TPM2_disk_unbind(void *dst, unsigned int *size, const struct disk_seal_entry *src);
+
 /* NVRAM to allow revocation of TM-KEY */
 int TPM_disk_nvalloc(be32_t *nvram_slot, struct tpm_authdata auth);
 int TPM_disk_nvread(void *buf, size_t bufsiz, be32_t nvram_slot, struct tpm_authdata auth);
-- 
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 Dec 14 16:13:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Bnq-0007t5-WB; Sun, 14 Dec 2014 16:13:51 +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 1Y0Bno-0007p4-Id
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C9/DB-25276-B37BD845; Sun, 14 Dec 2014 16:13:47 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418573625!15148734!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 7267 invoked from network); 14 Dec 2014 16:13:46 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-3.tower-21.messagelabs.com with SMTP;
	14 Dec 2014 16:13:46 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 14 Dec 2014 08:12:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="623611168"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 14 Dec 2014 08:13:44 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:10:01 -0500
Message-Id: <1418559001-13794-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 12/12] vTPM/TPM2: Unind group keys and sectors
	data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/disk_read.c | 28 ++++++++++++++++++++--------
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_read.c b/stubdom/vtpmmgr/disk_read.c
index 33aacdd..57573e4 100644
--- a/stubdom/vtpmmgr/disk_read.c
+++ b/stubdom/vtpmmgr/disk_read.c
@@ -10,7 +10,6 @@
 #include "vtpm_manager.h"
 #include "log.h"
 #include "uuid.h"
-
 #include "vtpmmgr.h"
 #include "vtpm_disk.h"
 #include "disk_tpm.h"
@@ -67,6 +66,7 @@ static int find_group_key(struct mem_group *dst,
 		const struct mem_tpm_mgr *parent)
 {
 	int i, rc, rv = 1;
+    unsigned int olen;
 	struct hash160 buf;
 	struct disk_group_sealed_data sealed;
 
@@ -82,13 +82,19 @@ static int find_group_key(struct mem_group *dst,
 
 	for(i=0; i < dst->nr_seals; i++) {
 		const struct disk_seal_entry *cfg = &group->v.boot_configs.entry[i];
-		dst->seals[i].pcr_selection = cfg->pcr_selection;
-		memcpy(&dst->seals[i].digest_release, &cfg->digest_release, 20);
 
-		TPM_pcr_digest(&buf, cfg->pcr_selection);
-		if (memcmp(&buf, &cfg->digest_release, 20))
-			continue;
-		rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
+        /*TPM 2.0 unbind | TPM 1.x unseal*/
+        if (hw_is_tpm2()) {
+            rc = TPM2_disk_unbind(&sealed, &olen, cfg);
+        } else {
+		    dst->seals[i].pcr_selection = cfg->pcr_selection;
+		    memcpy(&dst->seals[i].digest_release, &cfg->digest_release, 20);
+
+		    TPM_pcr_digest(&buf, cfg->pcr_selection);
+		    if (memcmp(&buf, &cfg->digest_release, 20))
+                continue;
+            rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
+        }
 		if (rc)
 			continue;
 		if (memcmp(&sealed.magic, DISK_GROUP_BOUND_MAGIC, 4))
@@ -112,9 +118,15 @@ static int find_group_key(struct mem_group *dst,
 static int parse_root_key(struct mem_tpm_mgr *dst, struct disk_seal_entry *src)
 {
 	int rc;
+    unsigned int olen;
 	struct disk_root_sealed_data sealed;
 
-	rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
+    /*TPM 2.0 unbind | TPM 1.x unseal*/
+    if (hw_is_tpm2())
+        rc = TPM2_disk_unbind(&sealed, &olen, src);
+    else
+        rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
+
 	if (rc)
 		return rc;
 
-- 
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 Dec 14 16:13:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:13:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Bnq-0007t5-WB; Sun, 14 Dec 2014 16:13:51 +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 1Y0Bno-0007p4-Id
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 16:13:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C9/DB-25276-B37BD845; Sun, 14 Dec 2014 16:13:47 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418573625!15148734!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 7267 invoked from network); 14 Dec 2014 16:13:46 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-3.tower-21.messagelabs.com with SMTP;
	14 Dec 2014 16:13:46 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 14 Dec 2014 08:12:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,575,1413270000"; d="scan'208";a="623611168"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 14 Dec 2014 08:13:44 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Sun, 14 Dec 2014 07:10:01 -0500
Message-Id: <1418559001-13794-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 12/12] vTPM/TPM2: Unind group keys and sectors
	data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/disk_read.c | 28 ++++++++++++++++++++--------
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_read.c b/stubdom/vtpmmgr/disk_read.c
index 33aacdd..57573e4 100644
--- a/stubdom/vtpmmgr/disk_read.c
+++ b/stubdom/vtpmmgr/disk_read.c
@@ -10,7 +10,6 @@
 #include "vtpm_manager.h"
 #include "log.h"
 #include "uuid.h"
-
 #include "vtpmmgr.h"
 #include "vtpm_disk.h"
 #include "disk_tpm.h"
@@ -67,6 +66,7 @@ static int find_group_key(struct mem_group *dst,
 		const struct mem_tpm_mgr *parent)
 {
 	int i, rc, rv = 1;
+    unsigned int olen;
 	struct hash160 buf;
 	struct disk_group_sealed_data sealed;
 
@@ -82,13 +82,19 @@ static int find_group_key(struct mem_group *dst,
 
 	for(i=0; i < dst->nr_seals; i++) {
 		const struct disk_seal_entry *cfg = &group->v.boot_configs.entry[i];
-		dst->seals[i].pcr_selection = cfg->pcr_selection;
-		memcpy(&dst->seals[i].digest_release, &cfg->digest_release, 20);
 
-		TPM_pcr_digest(&buf, cfg->pcr_selection);
-		if (memcmp(&buf, &cfg->digest_release, 20))
-			continue;
-		rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
+        /*TPM 2.0 unbind | TPM 1.x unseal*/
+        if (hw_is_tpm2()) {
+            rc = TPM2_disk_unbind(&sealed, &olen, cfg);
+        } else {
+		    dst->seals[i].pcr_selection = cfg->pcr_selection;
+		    memcpy(&dst->seals[i].digest_release, &cfg->digest_release, 20);
+
+		    TPM_pcr_digest(&buf, cfg->pcr_selection);
+		    if (memcmp(&buf, &cfg->digest_release, 20))
+                continue;
+            rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
+        }
 		if (rc)
 			continue;
 		if (memcmp(&sealed.magic, DISK_GROUP_BOUND_MAGIC, 4))
@@ -112,9 +118,15 @@ static int find_group_key(struct mem_group *dst,
 static int parse_root_key(struct mem_tpm_mgr *dst, struct disk_seal_entry *src)
 {
 	int rc;
+    unsigned int olen;
 	struct disk_root_sealed_data sealed;
 
-	rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
+    /*TPM 2.0 unbind | TPM 1.x unseal*/
+    if (hw_is_tpm2())
+        rc = TPM2_disk_unbind(&sealed, &olen, src);
+    else
+        rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
+
 	if (rc)
 		return rc;
 
-- 
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 Dec 14 16:40:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:40:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0CDF-0001GL-Ea; Sun, 14 Dec 2014 16:40:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0CDD-0001GG-Ev
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 16:40:03 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	7A/BF-25547-26DBD845; Sun, 14 Dec 2014 16:40:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418575200!13260816!1
X-Originating-IP: [66.165.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 31524 invoked from network); 14 Dec 2014 16:40:01 -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 Dec 2014 16:40:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,575,1413244800"; d="scan'208";a="204550388"
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.210.2; Sun, 14 Dec 2014 11:39: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 1Y0CD9-0003VP-1A;
	Sun, 14 Dec 2014 16:39:59 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0CD8-0007DA-P6;
	Sun, 14 Dec 2014 16:39:58 +0000
Date: Sun, 14 Dec 2014 16:39:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32337-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 13294
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 32337: 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="===============4833423317459809986=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4833423317459809986==
Content-Type: text/plain
Content-Length: 13054
Content-Transfer-Encoding: quoted-printable

flight 32337 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32337/

Failures and problems with tests :-(

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. 32245
 test-amd64-i386-rumpuserxen-i386 3 host-install(3) broken in 32316 REGR. vs. 32245
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 32316 REGR. vs. 32245
 test-amd64-i386-xl           3 host-install(3) broken in 32316 REGR. vs. 32245
 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 32316 REGR. vs. 32245
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 32316 REGR. vs. 32245
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 32316 REGR. vs. 32245
 test-amd64-i386-pair 4 host-install/dst_host(4) broken in 32316 REGR. vs. 32245

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  3 host-install(3)     broken pass in 32316
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)           broken pass in 32316
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 32316
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3)   broken pass in 32316
 test-amd64-amd64-xl           3 host-install(3)  broken in 32316 pass in 32337

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 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-xl-pcipt-intel  9 guest-start                 fail never pass
 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-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-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  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-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-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-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-qemut-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-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-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-win7-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 14 guest-stop                   fail   never pass
 test-amd64-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-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-libvirt       9 guest-start           fail in 32316 never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop       fail in 32316 never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail in 32316 never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop       fail in 32316 never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail in 32316 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 32316 never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 32316 never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop     fail in 32316 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 32316 never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop            fail in 32316 never pass

version targeted for testing:
 xen                  7e73a6e7f12ae080222c5d339799905de3443a6e
baseline version:
 xen                  60ce518a1b1caf2c1e4c1b203e87fb0b179ba687

------------------------------------------------------------
People who touched revisions under test:
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
  Mukesh Rathor <mukesh.rathor@oracle.com>
  Roger Pau Monn=C3=A9 <roger.pau@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                                             broken  
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 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                    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                         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                              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                                        broken  
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 broken  
 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=3Fp=3Dosstest.git;a=3Dsummary

broken-step test-amd64-amd64-rumpuserxen-amd64 host-install(3)
broken-step test-amd64-amd64-xl-sedf-pin host-install(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)
broken-step build-i386-pvops host-install(3)
broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit 7e73a6e7f12ae080222c5d339799905de3443a6e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Dec 11 17:14:07 2014 +0100

    have architectures specify the number of PIRQs a hardware domain gets
    
    The current value of nr_static_irqs + 256 is often too small for larger
    systems. Make it dependent on CPU count and number of IO-APIC pins on
    x86, and (until it obtains PCI support) simply NR_IRQS on ARM.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>

commit 4ef6b5f16c8a91cf6592f8817720a9de95b7052c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Dec 11 17:13:04 2014 +0100

    lock down hypercall continuation encoding masks
    
    Andrew validly points out that even if these masks aren't a formal part
    of the hypercall interface, we aren't free to change them: A guest
    suspended for migration in the middle of a continuation would fail to
    work if resumed on a hypervisor using a different value. Hence add
    respective comments to their definitions.
    
    Additionally, to help future extensibility as well as in the spirit of
    reducing undefined behavior as much as possible, refuse hypercalls made
    with the respective bits non-zero when the respective sub-ops don't
    make use of those bits.
    
    Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Release-Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>

commit 4d1308afaafa43ff68d6ecc493e36ee8f3ac9942
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Dec 11 12:24:05 2014 +0100

    VMX: don't allow PVH to reach handle_mmio()
    
    PVH guests accessing I/O ports via string ops is not supported yet.
    
    Reported-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Mukesh Rathor <mukesh.rathor@oracle.com>
    Acked-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
    Acked-by: Kevin Tian <kevin.tian@intel.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(qemu changes not included)


--===============4833423317459809986==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4833423317459809986==--

From xen-devel-bounces@lists.xen.org Sun Dec 14 16:40:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 16:40:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0CDF-0001GL-Ea; Sun, 14 Dec 2014 16:40:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0CDD-0001GG-Ev
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 16:40:03 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	7A/BF-25547-26DBD845; Sun, 14 Dec 2014 16:40:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418575200!13260816!1
X-Originating-IP: [66.165.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 31524 invoked from network); 14 Dec 2014 16:40:01 -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 Dec 2014 16:40:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,575,1413244800"; d="scan'208";a="204550388"
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.210.2; Sun, 14 Dec 2014 11:39: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 1Y0CD9-0003VP-1A;
	Sun, 14 Dec 2014 16:39:59 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0CD8-0007DA-P6;
	Sun, 14 Dec 2014 16:39:58 +0000
Date: Sun, 14 Dec 2014 16:39:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32337-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 13294
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 32337: 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="===============4833423317459809986=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4833423317459809986==
Content-Type: text/plain
Content-Length: 13054
Content-Transfer-Encoding: quoted-printable

flight 32337 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32337/

Failures and problems with tests :-(

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. 32245
 test-amd64-i386-rumpuserxen-i386 3 host-install(3) broken in 32316 REGR. vs. 32245
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 32316 REGR. vs. 32245
 test-amd64-i386-xl           3 host-install(3) broken in 32316 REGR. vs. 32245
 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 32316 REGR. vs. 32245
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 32316 REGR. vs. 32245
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 32316 REGR. vs. 32245
 test-amd64-i386-pair 4 host-install/dst_host(4) broken in 32316 REGR. vs. 32245

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  3 host-install(3)     broken pass in 32316
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)           broken pass in 32316
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 32316
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3)   broken pass in 32316
 test-amd64-amd64-xl           3 host-install(3)  broken in 32316 pass in 32337

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 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-xl-pcipt-intel  9 guest-start                 fail never pass
 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-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-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  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-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-qemut-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-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-qemut-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-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-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-win7-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 14 guest-stop                   fail   never pass
 test-amd64-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-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-libvirt       9 guest-start           fail in 32316 never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop       fail in 32316 never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail in 32316 never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop       fail in 32316 never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail in 32316 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop     fail in 32316 never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 32316 never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop     fail in 32316 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop      fail in 32316 never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop            fail in 32316 never pass

version targeted for testing:
 xen                  7e73a6e7f12ae080222c5d339799905de3443a6e
baseline version:
 xen                  60ce518a1b1caf2c1e4c1b203e87fb0b179ba687

------------------------------------------------------------
People who touched revisions under test:
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
  Mukesh Rathor <mukesh.rathor@oracle.com>
  Roger Pau Monn=C3=A9 <roger.pau@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                                             broken  
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 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                    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                         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                              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                                        broken  
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 broken  
 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=3Fp=3Dosstest.git;a=3Dsummary

broken-step test-amd64-amd64-rumpuserxen-amd64 host-install(3)
broken-step test-amd64-amd64-xl-sedf-pin host-install(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)
broken-step build-i386-pvops host-install(3)
broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)

Not pushing.

------------------------------------------------------------
commit 7e73a6e7f12ae080222c5d339799905de3443a6e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Dec 11 17:14:07 2014 +0100

    have architectures specify the number of PIRQs a hardware domain gets
    
    The current value of nr_static_irqs + 256 is often too small for larger
    systems. Make it dependent on CPU count and number of IO-APIC pins on
    x86, and (until it obtains PCI support) simply NR_IRQS on ARM.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>

commit 4ef6b5f16c8a91cf6592f8817720a9de95b7052c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Dec 11 17:13:04 2014 +0100

    lock down hypercall continuation encoding masks
    
    Andrew validly points out that even if these masks aren't a formal part
    of the hypercall interface, we aren't free to change them: A guest
    suspended for migration in the middle of a continuation would fail to
    work if resumed on a hypervisor using a different value. Hence add
    respective comments to their definitions.
    
    Additionally, to help future extensibility as well as in the spirit of
    reducing undefined behavior as much as possible, refuse hypercalls made
    with the respective bits non-zero when the respective sub-ops don't
    make use of those bits.
    
    Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Release-Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>

commit 4d1308afaafa43ff68d6ecc493e36ee8f3ac9942
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Dec 11 12:24:05 2014 +0100

    VMX: don't allow PVH to reach handle_mmio()
    
    PVH guests accessing I/O ports via string ops is not supported yet.
    
    Reported-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Mukesh Rathor <mukesh.rathor@oracle.com>
    Acked-by: Roger Pau Monn=C3=A9 <roger.pau@citrix.com>
    Acked-by: Kevin Tian <kevin.tian@intel.com>
    Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(qemu changes not included)


--===============4833423317459809986==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4833423317459809986==--

From xen-devel-bounces@lists.xen.org Sun Dec 14 17:48:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 17: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 1Y0DHL-0002iG-5S; Sun, 14 Dec 2014 17:48:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1Y0DHJ-0002iB-UZ
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 17:48:22 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	9A/3F-19763-56DCD845; Sun, 14 Dec 2014 17:48:21 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418579299!7849647!1
X-Originating-IP: [96.126.108.55]
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 3578 invoked from network); 14 Dec 2014 17:48:20 -0000
Received: from mail1.linode.com (HELO mail1.linode.com) (96.126.108.55)
	by server-14.tower-206.messagelabs.com with SMTP;
	14 Dec 2014 17:48:20 -0000
Received: from imap-newark.linode.com (unknown
	[IPv6:2600:3c03::f03c:91ff:fedf:57d1])
	by mail1.linode.com (Postfix) with ESMTP id 30DA126644
	for <xen-devel@lists.xensource.com>;
	Sun, 14 Dec 2014 12:48:19 -0500 (EST)
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by imap-newark.linode.com (Postfix) with ESMTPSA id 1FA7EAA4F
	for <xen-devel@lists.xensource.com>;
	Sun, 14 Dec 2014 12:48:19 -0500 (EST)
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: "Christopher S. Aker" <caker@theshore.net>
In-Reply-To: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>
Date: Sun, 14 Dec 2014 12:48:18 -0500
Message-Id: <56D159A7-FAAD-4CD7-9E86-B45C6E5C429C@theshore.net>
References: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>
To: xen devel <xen-devel@lists.xensource.com>
X-Mailer: Apple Mail (2.1990.1)
Subject: Re: [Xen-devel] WARNING: at drivers/xen/gntdev.c:426
	unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> On Dec 11, 2014, at 10:12 AM, Christopher S. Aker <caker@theshore.net> wrote:
> 
> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
> Dom0: 3.17.4
> 
> Things go badly after a day or four.  We've hit this on a number of previously healthy hosts, since moving from 3.10.x dom0 to 3.17.4:
> 
> printk: 5441 messages suppressed.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) printk: 4857 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 4846 callbacks suppressed
> (XEN) printk: 4699 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1569 callbacks suppressed
> (XEN) printk: 1809 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2327 callbacks suppressed
> (XEN) printk: 2779 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2509 callbacks suppressed
> (XEN) printk: 2022 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2282 callbacks suppressed
> (XEN) printk: 2778 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2385 callbacks suppressed
> (XEN) printk: 1560 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1714 callbacks suppressed
> (XEN) printk: 1713 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1619 callbacks suppressed
> (XEN) printk: 1852 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1895 callbacks suppressed
> (XEN) printk: 2058 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1797 callbacks suppressed
> (XEN) printk: 1530 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1440 callbacks suppressed
> (XEN) printk: 1306 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> 
> (...this repeats a few hundred times over the course of 30 minutes...)

We've also had reports that this adversely affects guests (filesystem errors), during the time the dom0 is cranking out these messages but before it crashes.

> net_ratelimit: 1221 callbacks suppressed
> (XEN) printk: 1719 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1747 callbacks suppressed
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1496 callbacks suppressed
> br0: port 80(vif242.0) entered disabled state
> device vif242.0 left promiscuous mode
> br0: port 80(vif242.0) entered disabled state
> device vif249.0 entered promiscuous mode
> xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi) persistent grants
> xen-blkback:ring-ref 9, event-channel 10, protocol 1 (x86_64-abi) persistent grants
> (XEN) printk: 1107 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 648 callbacks suppressed
> m2p_remove_override: pfn 10828f2 mfn 8000000005b4284e, failed to modify kernel mappings
> ------------[ cut here ]------------
> WARNING: CPU: 6 PID: 23911 at drivers/xen/gntdev.c:426 unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
> Modules linked in: xt_u32 xt_physdev ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ip6table_mangle ip6_tables ebtable_nat xen_acpi_processor xen_pciback xen_gntalloc xen_gntdev bonding ebtable_filter 8021q mrp ixgbe mdio ptp pps_core
> CPU: 6 PID: 23911 Comm: qemu-dm Not tainted 3.17.4-1 #1
> Hardware name: Supermicro X9DRE-TF+/X9DR7-TF+/X9DRE-TF+/X9DR7-TF+, BIOS 3.0a 12/04/2013
> 0000000000000009 ffff880043dafcc8 ffffffff81876bcb 0000000000000001
> 0000000000000000 ffff880043dafd08 ffffffff81069777 ffff880043dafd18
> ffff880020154690 00007f8add804000 00007f8add80f000 ffff880020154660
> Call Trace:
> [<ffffffff81876bcb>] dump_stack+0x46/0x58
> [<ffffffff81069777>] warn_slowpath_common+0x87/0xb0
> [<ffffffff810697b5>] warn_slowpath_null+0x15/0x20
> [<ffffffffa012d29d>] unmap_if_in_range+0x5d/0x60 [xen_gntdev]
> [<ffffffffa012d46e>] mn_invl_range_start+0x4e/0xa0 [xen_gntdev]
> [<ffffffff811615cb>] __mmu_notifier_invalidate_range_start+0x5b/0x90
> [<ffffffff811469a9>] unmap_vmas+0x79/0x90
> [<ffffffff8114bb13>] unmap_region+0xa3/0x120
> [<ffffffff8116b339>] ? new_sync_read+0x79/0xb0
> [<ffffffff8114bfb1>] ? vma_rb_erase+0x121/0x210
> [<ffffffff8114dba0>] do_munmap+0x2a0/0x3b0
> [<ffffffff8114dcf9>] vm_munmap+0x49/0x70
> [<ffffffff8114ecd6>] SyS_munmap+0x26/0x40
> [<ffffffff81880169>] system_call_fastpath+0x16/0x1b
> ---[ end trace 25ca87f9adc0ad78 ]---
> INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 32, t=60002 jiffies, g=26177592, c=26177591, q=1229)
> Task dump for CPU 0:
> swapper/0       R  running task    14072     0      0 0x00000008
> 00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
> ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
> 000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
> Call Trace:
> [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
> [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
> [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
> [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
> [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
> [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
> [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
> [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
> [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
> [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
> INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 34, t=240007 jiffies, g=26177592, c=26177591, q=4592)
> Task dump for CPU 0:
> swapper/0       R  running task    14072     0      0 0x00000008
> 00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
> ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
> 000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
> Call Trace:
> [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
> [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
> [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
> [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
> [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
> [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
> [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
> [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
> [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
> [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
> INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 34, t=420012 jiffies, g=26177592, c=26177591, q=8255)
> Task dump for CPU 0:
> swapper/0       R  running task    14072     0      0 0x00000008
> 00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
> ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
> 000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
> Call Trace:
> [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
> [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
> [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
> [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
> [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
> [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
> [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
> [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
> [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
> [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
> 
> Then the dom0 is unresponsive, and requires a reboot.

We've hit this on a number of hosts, so it's not an isolated incident.  Any suggestions would be appreciated.  We're stuck without a stable dom0, at the moment.  3.10.x has the netback issue, and then kernels beyond 3.10 each have their own problems.  I suppose we should forge ahead and try 3.18...

Thanks!
-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 14 17:48:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 17: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 1Y0DHL-0002iG-5S; Sun, 14 Dec 2014 17:48:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1Y0DHJ-0002iB-UZ
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 17:48:22 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	9A/3F-19763-56DCD845; Sun, 14 Dec 2014 17:48:21 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418579299!7849647!1
X-Originating-IP: [96.126.108.55]
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 3578 invoked from network); 14 Dec 2014 17:48:20 -0000
Received: from mail1.linode.com (HELO mail1.linode.com) (96.126.108.55)
	by server-14.tower-206.messagelabs.com with SMTP;
	14 Dec 2014 17:48:20 -0000
Received: from imap-newark.linode.com (unknown
	[IPv6:2600:3c03::f03c:91ff:fedf:57d1])
	by mail1.linode.com (Postfix) with ESMTP id 30DA126644
	for <xen-devel@lists.xensource.com>;
	Sun, 14 Dec 2014 12:48:19 -0500 (EST)
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by imap-newark.linode.com (Postfix) with ESMTPSA id 1FA7EAA4F
	for <xen-devel@lists.xensource.com>;
	Sun, 14 Dec 2014 12:48:19 -0500 (EST)
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: "Christopher S. Aker" <caker@theshore.net>
In-Reply-To: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>
Date: Sun, 14 Dec 2014 12:48:18 -0500
Message-Id: <56D159A7-FAAD-4CD7-9E86-B45C6E5C429C@theshore.net>
References: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>
To: xen devel <xen-devel@lists.xensource.com>
X-Mailer: Apple Mail (2.1990.1)
Subject: Re: [Xen-devel] WARNING: at drivers/xen/gntdev.c:426
	unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> On Dec 11, 2014, at 10:12 AM, Christopher S. Aker <caker@theshore.net> wrote:
> 
> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
> Dom0: 3.17.4
> 
> Things go badly after a day or four.  We've hit this on a number of previously healthy hosts, since moving from 3.10.x dom0 to 3.17.4:
> 
> printk: 5441 messages suppressed.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) printk: 4857 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 4846 callbacks suppressed
> (XEN) printk: 4699 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1569 callbacks suppressed
> (XEN) printk: 1809 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2327 callbacks suppressed
> (XEN) printk: 2779 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2509 callbacks suppressed
> (XEN) printk: 2022 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2282 callbacks suppressed
> (XEN) printk: 2778 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2385 callbacks suppressed
> (XEN) printk: 1560 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1714 callbacks suppressed
> (XEN) printk: 1713 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1619 callbacks suppressed
> (XEN) printk: 1852 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1895 callbacks suppressed
> (XEN) printk: 2058 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1797 callbacks suppressed
> (XEN) printk: 1530 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1440 callbacks suppressed
> (XEN) printk: 1306 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> 
> (...this repeats a few hundred times over the course of 30 minutes...)

We've also had reports that this adversely affects guests (filesystem errors), during the time the dom0 is cranking out these messages but before it crashes.

> net_ratelimit: 1221 callbacks suppressed
> (XEN) printk: 1719 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1747 callbacks suppressed
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1496 callbacks suppressed
> br0: port 80(vif242.0) entered disabled state
> device vif242.0 left promiscuous mode
> br0: port 80(vif242.0) entered disabled state
> device vif249.0 entered promiscuous mode
> xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi) persistent grants
> xen-blkback:ring-ref 9, event-channel 10, protocol 1 (x86_64-abi) persistent grants
> (XEN) printk: 1107 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 648 callbacks suppressed
> m2p_remove_override: pfn 10828f2 mfn 8000000005b4284e, failed to modify kernel mappings
> ------------[ cut here ]------------
> WARNING: CPU: 6 PID: 23911 at drivers/xen/gntdev.c:426 unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
> Modules linked in: xt_u32 xt_physdev ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ip6table_mangle ip6_tables ebtable_nat xen_acpi_processor xen_pciback xen_gntalloc xen_gntdev bonding ebtable_filter 8021q mrp ixgbe mdio ptp pps_core
> CPU: 6 PID: 23911 Comm: qemu-dm Not tainted 3.17.4-1 #1
> Hardware name: Supermicro X9DRE-TF+/X9DR7-TF+/X9DRE-TF+/X9DR7-TF+, BIOS 3.0a 12/04/2013
> 0000000000000009 ffff880043dafcc8 ffffffff81876bcb 0000000000000001
> 0000000000000000 ffff880043dafd08 ffffffff81069777 ffff880043dafd18
> ffff880020154690 00007f8add804000 00007f8add80f000 ffff880020154660
> Call Trace:
> [<ffffffff81876bcb>] dump_stack+0x46/0x58
> [<ffffffff81069777>] warn_slowpath_common+0x87/0xb0
> [<ffffffff810697b5>] warn_slowpath_null+0x15/0x20
> [<ffffffffa012d29d>] unmap_if_in_range+0x5d/0x60 [xen_gntdev]
> [<ffffffffa012d46e>] mn_invl_range_start+0x4e/0xa0 [xen_gntdev]
> [<ffffffff811615cb>] __mmu_notifier_invalidate_range_start+0x5b/0x90
> [<ffffffff811469a9>] unmap_vmas+0x79/0x90
> [<ffffffff8114bb13>] unmap_region+0xa3/0x120
> [<ffffffff8116b339>] ? new_sync_read+0x79/0xb0
> [<ffffffff8114bfb1>] ? vma_rb_erase+0x121/0x210
> [<ffffffff8114dba0>] do_munmap+0x2a0/0x3b0
> [<ffffffff8114dcf9>] vm_munmap+0x49/0x70
> [<ffffffff8114ecd6>] SyS_munmap+0x26/0x40
> [<ffffffff81880169>] system_call_fastpath+0x16/0x1b
> ---[ end trace 25ca87f9adc0ad78 ]---
> INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 32, t=60002 jiffies, g=26177592, c=26177591, q=1229)
> Task dump for CPU 0:
> swapper/0       R  running task    14072     0      0 0x00000008
> 00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
> ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
> 000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
> Call Trace:
> [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
> [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
> [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
> [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
> [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
> [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
> [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
> [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
> [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
> [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
> INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 34, t=240007 jiffies, g=26177592, c=26177591, q=4592)
> Task dump for CPU 0:
> swapper/0       R  running task    14072     0      0 0x00000008
> 00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
> ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
> 000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
> Call Trace:
> [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
> [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
> [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
> [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
> [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
> [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
> [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
> [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
> [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
> [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
> INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 34, t=420012 jiffies, g=26177592, c=26177591, q=8255)
> Task dump for CPU 0:
> swapper/0       R  running task    14072     0      0 0x00000008
> 00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
> ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
> 000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
> Call Trace:
> [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
> [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
> [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
> [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
> [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
> [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
> [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
> [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
> [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
> [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
> 
> Then the dom0 is unresponsive, and requires a reboot.

We've hit this on a number of hosts, so it's not an isolated incident.  Any suggestions would be appreciated.  We're stuck without a stable dom0, at the moment.  3.10.x has the netback issue, and then kernels beyond 3.10 each have their own problems.  I suppose we should forge ahead and try 3.18...

Thanks!
-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 14 22:32:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 22:32:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Hi7-0008Ec-0S; Sun, 14 Dec 2014 22:32:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0Hi4-0008EU-W9
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 22:32:17 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	37/42-16982-0FF0E845; Sun, 14 Dec 2014 22:32:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418596334!13277196!1
X-Originating-IP: [66.165.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 23907 invoked from network); 14 Dec 2014 22:32:15 -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;
	14 Dec 2014 22:32:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,576,1413244800"; d="scan'208";a="204632999"
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.210.2; Sun, 14 Dec 2014 17:32: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 1Y0Hhx-0005CM-DA;
	Sun, 14 Dec 2014 22:32:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0Hhx-0001zp-4J;
	Sun, 14 Dec 2014 22:32:09 +0000
Date: Sun, 14 Dec 2014 22:32:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32351-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] 32351: 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 32351 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32351/

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              c5a54917d5ae97653d29dbfe4995f2efcf5717d6
baseline version:
 libvirt              c7d1c139ca3402e875002753952e80ce8054374e

------------------------------------------------------------
People who touched revisions under test:
  Laine Stump <laine@laine.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-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=c5a54917d5ae97653d29dbfe4995f2efcf5717d6
+ . 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 c5a54917d5ae97653d29dbfe4995f2efcf5717d6
+ branch=libvirt
+ revision=c5a54917d5ae97653d29dbfe4995f2efcf5717d6
+ . 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 c5a54917d5ae97653d29dbfe4995f2efcf5717d6:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   c7d1c13..c5a5491  c5a54917d5ae97653d29dbfe4995f2efcf5717d6 -> 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 Dec 14 22:32:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 22:32:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Hi7-0008Ec-0S; Sun, 14 Dec 2014 22:32:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0Hi4-0008EU-W9
	for xen-devel@lists.xensource.com; Sun, 14 Dec 2014 22:32:17 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	37/42-16982-0FF0E845; Sun, 14 Dec 2014 22:32:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418596334!13277196!1
X-Originating-IP: [66.165.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 23907 invoked from network); 14 Dec 2014 22:32:15 -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;
	14 Dec 2014 22:32:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,576,1413244800"; d="scan'208";a="204632999"
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.210.2; Sun, 14 Dec 2014 17:32: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 1Y0Hhx-0005CM-DA;
	Sun, 14 Dec 2014 22:32:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0Hhx-0001zp-4J;
	Sun, 14 Dec 2014 22:32:09 +0000
Date: Sun, 14 Dec 2014 22:32:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32351-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] 32351: 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 32351 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32351/

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              c5a54917d5ae97653d29dbfe4995f2efcf5717d6
baseline version:
 libvirt              c7d1c139ca3402e875002753952e80ce8054374e

------------------------------------------------------------
People who touched revisions under test:
  Laine Stump <laine@laine.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-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=c5a54917d5ae97653d29dbfe4995f2efcf5717d6
+ . 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 c5a54917d5ae97653d29dbfe4995f2efcf5717d6
+ branch=libvirt
+ revision=c5a54917d5ae97653d29dbfe4995f2efcf5717d6
+ . 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 c5a54917d5ae97653d29dbfe4995f2efcf5717d6:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   c7d1c13..c5a5491  c5a54917d5ae97653d29dbfe4995f2efcf5717d6 -> 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 Dec 14 23:16:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 23:16:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0IOh-0000jc-NM; Sun, 14 Dec 2014 23:16:19 +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 1Y0IOg-0000jW-LC
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 23:16:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F0/CB-09842-24A1E845; Sun, 14 Dec 2014 23:16:18 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418598972!15471248!1
X-Originating-IP: [209.85.214.176]
X-SpamReason: No, hits=2.6 required=7.0 tests=HTML_20_30,
	HTML_LINK_OPT_OUT,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28045 invoked from network); 14 Dec 2014 23:16:13 -0000
Received: from mail-ob0-f176.google.com (HELO mail-ob0-f176.google.com)
	(209.85.214.176)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2014 23:16:13 -0000
Received: by mail-ob0-f176.google.com with SMTP id vb8so15285857obc.7
	for <xen-devel@lists.xen.org>; Sun, 14 Dec 2014 15:16:12 -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=CKESsslAfpo/l1RJYRpBqpYj1/7F+6XOXtRgmiunuLQ=;
	b=tD5DlSjwiw5i+vE4OgOpIANPmvG5/eAy6kV6W+7uNk0AmiKL4QEG+RErRkdOSprWyM
	+fTeIeGlg++3wVzdFFl+x0fVbQ4p+3OC35HWz7N+ikjCYcGp5HKntT6JpA5K5DZ/+Mnp
	BI+ULliJ0d0fHFBM7gpyue+AQbRhshsG/MiZJ+t9tXXYHIRs80+wheAH3qfgkBhuLXus
	lpzLPh96YKdfBeI5ysxgauTvV2i/KBcyIq9Sx6l/XlvFjPZkebtrT/OXsMLoVx38W86p
	QLR05TaoDvXY/SFNGhAZ7Cr9KjSEywlQ6d0TecOC4vr6N40NsFC0k5HHtfOtDbMLBThz
	KY4g==
MIME-Version: 1.0
X-Received: by 10.202.85.80 with SMTP id j77mr16310790oib.97.1418598972009;
	Sun, 14 Dec 2014 15:16:12 -0800 (PST)
Received: by 10.76.128.18 with HTTP; Sun, 14 Dec 2014 15:16:11 -0800 (PST)
In-Reply-To: <CADUQMei4ssFXs-fq83QrcpSu5pw8Xq_dtmY0=NwLywy4MNd8ng@mail.gmail.com>
References: <CADUQMei4ssFXs-fq83QrcpSu5pw8Xq_dtmY0=NwLywy4MNd8ng@mail.gmail.com>
Date: Sun, 14 Dec 2014 15:16:11 -0800
Message-ID: <CAENZ-+=TbKkBY3j+qKuLXo3tHHLiGWb5W3YS6bB1Z7qYsvGOww@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: Jie Shen <jshen25@hawk.iit.edu>
Cc: Xiayu Hua <xiayuhuahxy@gmail.com>,
	"rtxen-devel@googlegroups.com" <rtxen-devel@googlegroups.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [rtxen-devel] XEN::SCHEDULER::libxl.c::make install
 error ::libxenlight.so: undefined reference to `xc_sched_rm_domain_set'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8817972448961495193=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8817972448961495193==
Content-Type: multipart/alternative; boundary=001a113defd8ce3772050a354f57

--001a113defd8ce3772050a354f57
Content-Type: text/plain; charset=UTF-8

Not sure if you have solved it or not. if you look througth the code patch
I sent to you last week, you should find it in the xc_rtpatition.c file
under the tools folder.

2014-12-13 0:26 GMT-08:00 Jie Shen <jshen25@hawk.iit.edu>:
>
>
> Hello Gurus,
> I am adding a new rm scheduler to the rt-xen,
> unfortunately I met "undefined reference to " error ,the output is below:
>
> ================error output begin==============
>
>
> ln -sf libxenlight.so.4.3.0 libxenlight.so.4.3
> ln -sf libxenlight.so.4.3 libxenlight.so
> gcc    -pthread -o xl xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
> libxlutil.so
> /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so
> -Wl,-rpath-link=/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxc
> -Wl,-rpath-link=/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/xenstore
> -Wl,-rpath-link=/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/blktap2/control
> /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxc/libxenctrl.so
> -lyajl
> /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so:
> undefined reference to `xc_sched_rm_domain_get'
> /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so:
> undefined reference to `xc_sched_rm_domain_set'
> collect2: error: ld returned 1 exit status
> make[3]: *** [xl] Error 1
> make[3]: Leaving directory
> `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl'
> make[2]: *** [subdir-install-libxl] Error 2
> make[2]: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools'
> make: *** [install-tools] Error 2
>
> =============== error output end ===================
>
>
> I searched all the folder ,it should be defined in the file :(reference
> rtpartion)
>
>
> ==================== grep for rm===============
> jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ grep -r
>  xc_sched_rm_domain_set
> dist/install/usr/local/include/xenctrl.h~:int
> xc_sched_rm_domain_set(xc_interface *xch,
> dist/install/usr/local/include/xenctrl.h:int
> xc_sched_rm_domain_set(xc_interface *xch,
> tools/libxc/xc_rm.c:xc_sched_rm_domain_set(
> tools/libxc/xenctrl.h:int xc_sched_rm_domain_set(xc_interface *xch,
> tools/libxl/libxl.c:    rc = xc_sched_rm_domain_set(CTX->xch, domid,
> &sdom);
> Binary file tools/libxl/libxenlight.so.4.3.0 matches
> Binary file tools/libxl/libxl.o matches
> tools/python/xen/lowlevel/xc/xc.c:static PyObject
> *pyxc_sched_rm_domain_set(XcObject *self,
> tools/python/xen/lowlevel/xc/xc.c:    if (
> xc_sched_rm_domain_set(self->xc_handle, domid, &sdom) != 0 )
> tools/python/xen/lowlevel/xc/xc.c:
>  (PyCFunction)pyxc_sched_rm_domain_set,
>
> ====================grep for rtpartion ============
> jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ grep -r
>  xc_sched_rtpartition_domain_set
> dist/install/usr/local/include/xenctrl.h~:int
> xc_sched_rtpartition_domain_set(xc_interface *xch,
> dist/install/usr/local/include/xenctl.hbak:int
> xc_sched_rtpartition_domain_set(xc_interface *xch,     ===>bakfile can be
> ignored
> dist/install/usr/local/include/xenctrl.h:int
> xc_sched_rtpartition_domain_set(xc_interface *xch,
> Binary file dist/install/usr/local/lib/libxenlight.so.4.3.0 matches
> Binary file dist/install/usr/local/lib/libxenlight.a matches
> Binary file dist/install/usr/local/lib/libxenctrl.so.4.3.0 matches
> Binary file dist/install/usr/local/lib/libxenctrl.a matches
> Binary file
> dist/install/usr/local/lib/python2.7/dist-packages/xen/lowlevel/xc.so
> matches
> Binary file tools/libxc/libxenctrl.so.4.3.0 matches
> Binary file tools/libxc/libxenctrl.a matches
> Binary file tools/libxc/xc_rtpartition.o matches
> tools/libxc/xc_rtpartition.c:xc_sched_rtpartition_domain_set(
> Binary file tools/libxc/xc_rtpartition.opic matches
> tools/libxc/xenctrl.h:int xc_sched_rtpartition_domain_set(xc_interface
> *xch,
> tools/libxl/libxl.c:    rc = xc_sched_rtpartition_domain_set(CTX->xch,
> domid, &sdom);
> Binary file tools/libxl/libxenlight.so.4.3.0 matches
> tools/libxl/libxl.cbak:    rc = xc_sched_rtpartition_domain_set(CTX->xch,
> domid, &sdom);
> Binary file tools/libxl/libxl.o matches
> tools/libxl/libxl.cbak.20141211:    rc =
> xc_sched_rtpartition_domain_set(CTX->xch, domid, &sdom);
> tools/python/xen/lowlevel/xc/xc.c:static PyObject
> *pyxc_sched_rtpartition_domain_set(XcObject *self,
> tools/python/xen/lowlevel/xc/xc.c:    if (
> xc_sched_rtpartition_domain_set(self->xc_handle, domid, &sdom) != 0 )
> tools/python/xen/lowlevel/xc/xc.c:
>  (PyCFunction)pyxc_sched_rtpartition_domain_set,
> tools/python/xen/lowlevel/xc/xc.cbak:static PyObject
> *pyxc_sched_rtpartition_domain_set(XcObject *self,
> ===>bakfile
> tools/python/xen/lowlevel/xc/xc.cbak:    if (
> xc_sched_rtpartition_domain_set(self->xc_handle, domid, &sdom) != 0 )
> tools/python/xen/lowlevel/xc/xc.cbak:
>  (PyCFunction)pyxc_sched_rtpartition_domain_set,
> jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$
>
>
>
> Could you please advice me where I need to define it?
> Thank you very much!
>
>
>  Best regards
> Jie Shen
>
>
> Graduate Student in Computer Science
> Illinois Institute of Technology
> Stuart Building  Chicago, IL 60616
> +1  312 404 0122
>
>  --
> You received this message because you are subscribed to the Google Groups
> "rtxen-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rtxen-devel+unsubscribe@googlegroups.com.
> To post to this group, send email to rtxen-devel@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--001a113defd8ce3772050a354f57
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">Not=
 sure if you have solved it or not. if you look througth the code patch I s=
ent to you last week, you should find it in the xc_rtpatition.c file under =
the tools folder.<br></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">2014-12-13 0:26 GMT-08:00 Jie Shen <span dir=3D"ltr">&lt;<=
a href=3D"mailto:jshen25@hawk.iit.edu" target=3D"_blank">jshen25@hawk.iit.e=
du</a>&gt;</span>:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>=
</div><div>Hello Gurus,</div><div>I am adding a new rm scheduler to the rt-=
xen,</div><div>unfortunately I met &quot;undefined reference to &quot; erro=
r ,the output is below:</div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3Derror output begin=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D</div><div><br></div><div><br></div><div>ln -sf libxenlight.so.4.3=
.0 libxenlight.so.4.3</div><div>ln -sf libxenlight.so.4.3 libxenlight.so</d=
iv><div>gcc =C2=A0 =C2=A0-pthread -o xl xl.o xl_cmdimpl.o xl_cmdtable.o xl_=
sxp.o libxlutil.so /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../=
../tools/libxl/libxenlight.so -Wl,-rpath-link=3D/home/jackyshen/RT-XEN/RT-X=
en-rt-xen_2.0/tools/libxl/../../tools/libxc -Wl,-rpath-link=3D/home/jackysh=
en/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/xenstore -Wl,-rpath-lin=
k=3D/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/blktap=
2/control /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/=
libxc/libxenctrl.so -lyajl=C2=A0</div><div>/home/jackyshen/RT-XEN/RT-Xen-rt=
-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so: undefined reference =
to `xc_sched_rm_domain_get&#39;</div><div>/home/jackyshen/RT-XEN/RT-Xen-rt-=
xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so: undefined reference t=
o `xc_sched_rm_domain_set&#39;</div><div>collect2: error: ld returned 1 exi=
t status</div><div>make[3]: *** [xl] Error 1</div><div>make[3]: Leaving dir=
ectory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl&#39;</div><div=
>make[2]: *** [subdir-install-libxl] Error 2</div><div>make[2]: Leaving dir=
ectory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools&#39;</div><div>make[=
1]: *** [subdirs-install] Error 2</div><div>make[1]: Leaving directory `/ho=
me/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools&#39;</div><div>make: *** [insta=
ll-tools] Error 2</div><div><br></div><div><div><div dir=3D"ltr"><div><div>=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D error output end =3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br><br>I searched all the=
 folder ,it should be defined in the file :(reference rtpartion)</div><div>=
<br></div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D grep for rm=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</d=
iv><div><div>jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ =
grep -r =C2=A0xc_sched_rm_domain_set</div><div>dist/install/usr/local/inclu=
de/xenctrl.h~:int xc_sched_rm_domain_set(xc_interface *xch,</div><div>dist/=
install/usr/local/include/xenctrl.h:int xc_sched_rm_domain_set(xc_interface=
 *xch,</div><div>tools/libxc/xc_rm.c:xc_sched_rm_domain_set(</div><div>tool=
s/libxc/xenctrl.h:int xc_sched_rm_domain_set(xc_interface *xch,</div><div>t=
ools/libxl/libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_domain_set(CTX-&gt;xch,=
 domid, &amp;sdom);</div><div>Binary file tools/libxl/libxenlight.so.4.3.0 =
matches</div><div>Binary file tools/libxl/libxl.o matches</div><div>tools/p=
ython/xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_set(XcObje=
ct *self,</div><div>tools/python/xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc=
_sched_rm_domain_set(self-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</div><d=
iv>tools/python/xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc=
_sched_rm_domain_set,</div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dgrep for rtpartion =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D</div><div>jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen=
-rt-xen_2.0$ grep -r =C2=A0xc_sched_rtpartition_domain_set</div><div>dist/i=
nstall/usr/local/include/xenctrl.h~:int xc_sched_rtpartition_domain_set(xc_=
interface *xch,</div><div>dist/install/usr/local/include/xenctl.hbak:int xc=
_sched_rtpartition_domain_set(xc_interface *xch, =C2=A0 =C2=A0 =3D=3D=3D&gt=
;bakfile can be ignored</div><div>dist/install/usr/local/include/xenctrl.h:=
int xc_sched_rtpartition_domain_set(xc_interface *xch,</div><div>Binary fil=
e dist/install/usr/local/lib/libxenlight.so.4.3.0 matches</div><div>Binary =
file dist/install/usr/local/lib/libxenlight.a matches</div><div>Binary file=
 dist/install/usr/local/lib/libxenctrl.so.4.3.0 matches</div><div>Binary fi=
le dist/install/usr/local/lib/libxenctrl.a matches</div><div>Binary file di=
st/install/usr/local/lib/python2.7/dist-packages/xen/lowlevel/xc.so matches=
</div><div>Binary file tools/libxc/libxenctrl.so.4.3.0 matches</div><div>Bi=
nary file tools/libxc/libxenctrl.a matches</div><div>Binary file tools/libx=
c/xc_rtpartition.o matches</div><div>tools/libxc/xc_rtpartition.c:xc_sched_=
rtpartition_domain_set(</div><div>Binary file tools/libxc/xc_rtpartition.op=
ic matches</div><div>tools/libxc/xenctrl.h:int xc_sched_rtpartition_domain_=
set(xc_interface *xch,</div><div>tools/libxl/libxl.c: =C2=A0 =C2=A0rc =3D x=
c_sched_rtpartition_domain_set(CTX-&gt;xch, domid, &amp;sdom);</div><div>Bi=
nary file tools/libxl/libxenlight.so.4.3.0 matches</div><div>tools/libxl/li=
bxl.cbak: =C2=A0 =C2=A0rc =3D xc_sched_rtpartition_domain_set(CTX-&gt;xch, =
domid, &amp;sdom);</div><div>Binary file tools/libxl/libxl.o matches</div><=
div>tools/libxl/libxl.cbak.20141211: =C2=A0 =C2=A0rc =3D xc_sched_rtpartiti=
on_domain_set(CTX-&gt;xch, domid, &amp;sdom);</div><div>tools/python/xen/lo=
wlevel/xc/xc.c:static PyObject *pyxc_sched_rtpartition_domain_set(XcObject =
*self,</div><div>tools/python/xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sc=
hed_rtpartition_domain_set(self-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</=
div><div>tools/python/xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunctio=
n)pyxc_sched_rtpartition_domain_set,</div><div>tools/python/xen/lowlevel/xc=
/xc.cbak:static PyObject *pyxc_sched_rtpartition_domain_set(XcObject *self,=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =3D=3D=3D&gt;bakfile</div><div>tools/python/xen/lowlevel/xc/xc.cbak: =
=C2=A0 =C2=A0if ( xc_sched_rtpartition_domain_set(self-&gt;xc_handle, domid=
, &amp;sdom) !=3D 0 )</div><div>tools/python/xen/lowlevel/xc/xc.cbak: =C2=
=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rtpartition_domain_set,</div><div>=
jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$=C2=A0</div><d=
iv><br></div><div><br></div><div><br></div>Could you please advice me where=
 I need to define it?</div><div>Thank you very much!<br><br><br>=C2=A0Best =
regards<br>Jie Shen <br><br><br></div>Graduate Student in Computer Science<=
br></div>Illinois Institute of Technology=C2=A0=C2=A0=C2=A0 <br>Stuart Buil=
ding=C2=A0 Chicago, IL 60616<br><a href=3D"tel:%2B1%C2%A0%20312%20404%20012=
2" value=3D"+13124040122" target=3D"_blank">+1=C2=A0 312 404 0122</a><span =
class=3D"HOEnZb"><font color=3D"#888888"><br><div><br></div></font></span><=
/div></div></div><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;rtxen-devel&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:rtxen-devel+unsubscribe@googlegroups.com" target=
=3D"_blank">rtxen-devel+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to <a href=3D"mailto:rtxen-devel@googlegr=
oups.com" target=3D"_blank">rtxen-devel@googlegroups.com</a>.<br>
For more options, visit <a href=3D"https://groups.google.com/d/optout" targ=
et=3D"_blank">https://groups.google.com/d/optout</a>.<br>
</font></span></blockquote></div><br clear=3D"all"><br>-- <br><div class=3D=
"gmail_signature"><div dir=3D"ltr"><br><br>-----------<br>Meng Xu<br>PhD St=
udent in Computer and Information Science<br>University of Pennsylvania</di=
v></div>
</div>

--001a113defd8ce3772050a354f57--


--===============8817972448961495193==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8817972448961495193==--


From xen-devel-bounces@lists.xen.org Sun Dec 14 23:16:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 23:16:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0IOh-0000jc-NM; Sun, 14 Dec 2014 23:16:19 +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 1Y0IOg-0000jW-LC
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 23:16:18 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F0/CB-09842-24A1E845; Sun, 14 Dec 2014 23:16:18 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418598972!15471248!1
X-Originating-IP: [209.85.214.176]
X-SpamReason: No, hits=2.6 required=7.0 tests=HTML_20_30,
	HTML_LINK_OPT_OUT,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28045 invoked from network); 14 Dec 2014 23:16:13 -0000
Received: from mail-ob0-f176.google.com (HELO mail-ob0-f176.google.com)
	(209.85.214.176)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Dec 2014 23:16:13 -0000
Received: by mail-ob0-f176.google.com with SMTP id vb8so15285857obc.7
	for <xen-devel@lists.xen.org>; Sun, 14 Dec 2014 15:16:12 -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=CKESsslAfpo/l1RJYRpBqpYj1/7F+6XOXtRgmiunuLQ=;
	b=tD5DlSjwiw5i+vE4OgOpIANPmvG5/eAy6kV6W+7uNk0AmiKL4QEG+RErRkdOSprWyM
	+fTeIeGlg++3wVzdFFl+x0fVbQ4p+3OC35HWz7N+ikjCYcGp5HKntT6JpA5K5DZ/+Mnp
	BI+ULliJ0d0fHFBM7gpyue+AQbRhshsG/MiZJ+t9tXXYHIRs80+wheAH3qfgkBhuLXus
	lpzLPh96YKdfBeI5ysxgauTvV2i/KBcyIq9Sx6l/XlvFjPZkebtrT/OXsMLoVx38W86p
	QLR05TaoDvXY/SFNGhAZ7Cr9KjSEywlQ6d0TecOC4vr6N40NsFC0k5HHtfOtDbMLBThz
	KY4g==
MIME-Version: 1.0
X-Received: by 10.202.85.80 with SMTP id j77mr16310790oib.97.1418598972009;
	Sun, 14 Dec 2014 15:16:12 -0800 (PST)
Received: by 10.76.128.18 with HTTP; Sun, 14 Dec 2014 15:16:11 -0800 (PST)
In-Reply-To: <CADUQMei4ssFXs-fq83QrcpSu5pw8Xq_dtmY0=NwLywy4MNd8ng@mail.gmail.com>
References: <CADUQMei4ssFXs-fq83QrcpSu5pw8Xq_dtmY0=NwLywy4MNd8ng@mail.gmail.com>
Date: Sun, 14 Dec 2014 15:16:11 -0800
Message-ID: <CAENZ-+=TbKkBY3j+qKuLXo3tHHLiGWb5W3YS6bB1Z7qYsvGOww@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: Jie Shen <jshen25@hawk.iit.edu>
Cc: Xiayu Hua <xiayuhuahxy@gmail.com>,
	"rtxen-devel@googlegroups.com" <rtxen-devel@googlegroups.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [rtxen-devel] XEN::SCHEDULER::libxl.c::make install
 error ::libxenlight.so: undefined reference to `xc_sched_rm_domain_set'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8817972448961495193=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8817972448961495193==
Content-Type: multipart/alternative; boundary=001a113defd8ce3772050a354f57

--001a113defd8ce3772050a354f57
Content-Type: text/plain; charset=UTF-8

Not sure if you have solved it or not. if you look througth the code patch
I sent to you last week, you should find it in the xc_rtpatition.c file
under the tools folder.

2014-12-13 0:26 GMT-08:00 Jie Shen <jshen25@hawk.iit.edu>:
>
>
> Hello Gurus,
> I am adding a new rm scheduler to the rt-xen,
> unfortunately I met "undefined reference to " error ,the output is below:
>
> ================error output begin==============
>
>
> ln -sf libxenlight.so.4.3.0 libxenlight.so.4.3
> ln -sf libxenlight.so.4.3 libxenlight.so
> gcc    -pthread -o xl xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
> libxlutil.so
> /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so
> -Wl,-rpath-link=/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxc
> -Wl,-rpath-link=/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/xenstore
> -Wl,-rpath-link=/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/blktap2/control
> /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxc/libxenctrl.so
> -lyajl
> /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so:
> undefined reference to `xc_sched_rm_domain_get'
> /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so:
> undefined reference to `xc_sched_rm_domain_set'
> collect2: error: ld returned 1 exit status
> make[3]: *** [xl] Error 1
> make[3]: Leaving directory
> `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl'
> make[2]: *** [subdir-install-libxl] Error 2
> make[2]: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools'
> make: *** [install-tools] Error 2
>
> =============== error output end ===================
>
>
> I searched all the folder ,it should be defined in the file :(reference
> rtpartion)
>
>
> ==================== grep for rm===============
> jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ grep -r
>  xc_sched_rm_domain_set
> dist/install/usr/local/include/xenctrl.h~:int
> xc_sched_rm_domain_set(xc_interface *xch,
> dist/install/usr/local/include/xenctrl.h:int
> xc_sched_rm_domain_set(xc_interface *xch,
> tools/libxc/xc_rm.c:xc_sched_rm_domain_set(
> tools/libxc/xenctrl.h:int xc_sched_rm_domain_set(xc_interface *xch,
> tools/libxl/libxl.c:    rc = xc_sched_rm_domain_set(CTX->xch, domid,
> &sdom);
> Binary file tools/libxl/libxenlight.so.4.3.0 matches
> Binary file tools/libxl/libxl.o matches
> tools/python/xen/lowlevel/xc/xc.c:static PyObject
> *pyxc_sched_rm_domain_set(XcObject *self,
> tools/python/xen/lowlevel/xc/xc.c:    if (
> xc_sched_rm_domain_set(self->xc_handle, domid, &sdom) != 0 )
> tools/python/xen/lowlevel/xc/xc.c:
>  (PyCFunction)pyxc_sched_rm_domain_set,
>
> ====================grep for rtpartion ============
> jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ grep -r
>  xc_sched_rtpartition_domain_set
> dist/install/usr/local/include/xenctrl.h~:int
> xc_sched_rtpartition_domain_set(xc_interface *xch,
> dist/install/usr/local/include/xenctl.hbak:int
> xc_sched_rtpartition_domain_set(xc_interface *xch,     ===>bakfile can be
> ignored
> dist/install/usr/local/include/xenctrl.h:int
> xc_sched_rtpartition_domain_set(xc_interface *xch,
> Binary file dist/install/usr/local/lib/libxenlight.so.4.3.0 matches
> Binary file dist/install/usr/local/lib/libxenlight.a matches
> Binary file dist/install/usr/local/lib/libxenctrl.so.4.3.0 matches
> Binary file dist/install/usr/local/lib/libxenctrl.a matches
> Binary file
> dist/install/usr/local/lib/python2.7/dist-packages/xen/lowlevel/xc.so
> matches
> Binary file tools/libxc/libxenctrl.so.4.3.0 matches
> Binary file tools/libxc/libxenctrl.a matches
> Binary file tools/libxc/xc_rtpartition.o matches
> tools/libxc/xc_rtpartition.c:xc_sched_rtpartition_domain_set(
> Binary file tools/libxc/xc_rtpartition.opic matches
> tools/libxc/xenctrl.h:int xc_sched_rtpartition_domain_set(xc_interface
> *xch,
> tools/libxl/libxl.c:    rc = xc_sched_rtpartition_domain_set(CTX->xch,
> domid, &sdom);
> Binary file tools/libxl/libxenlight.so.4.3.0 matches
> tools/libxl/libxl.cbak:    rc = xc_sched_rtpartition_domain_set(CTX->xch,
> domid, &sdom);
> Binary file tools/libxl/libxl.o matches
> tools/libxl/libxl.cbak.20141211:    rc =
> xc_sched_rtpartition_domain_set(CTX->xch, domid, &sdom);
> tools/python/xen/lowlevel/xc/xc.c:static PyObject
> *pyxc_sched_rtpartition_domain_set(XcObject *self,
> tools/python/xen/lowlevel/xc/xc.c:    if (
> xc_sched_rtpartition_domain_set(self->xc_handle, domid, &sdom) != 0 )
> tools/python/xen/lowlevel/xc/xc.c:
>  (PyCFunction)pyxc_sched_rtpartition_domain_set,
> tools/python/xen/lowlevel/xc/xc.cbak:static PyObject
> *pyxc_sched_rtpartition_domain_set(XcObject *self,
> ===>bakfile
> tools/python/xen/lowlevel/xc/xc.cbak:    if (
> xc_sched_rtpartition_domain_set(self->xc_handle, domid, &sdom) != 0 )
> tools/python/xen/lowlevel/xc/xc.cbak:
>  (PyCFunction)pyxc_sched_rtpartition_domain_set,
> jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$
>
>
>
> Could you please advice me where I need to define it?
> Thank you very much!
>
>
>  Best regards
> Jie Shen
>
>
> Graduate Student in Computer Science
> Illinois Institute of Technology
> Stuart Building  Chicago, IL 60616
> +1  312 404 0122
>
>  --
> You received this message because you are subscribed to the Google Groups
> "rtxen-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rtxen-devel+unsubscribe@googlegroups.com.
> To post to this group, send email to rtxen-devel@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--001a113defd8ce3772050a354f57
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">Not=
 sure if you have solved it or not. if you look througth the code patch I s=
ent to you last week, you should find it in the xc_rtpatition.c file under =
the tools folder.<br></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">2014-12-13 0:26 GMT-08:00 Jie Shen <span dir=3D"ltr">&lt;<=
a href=3D"mailto:jshen25@hawk.iit.edu" target=3D"_blank">jshen25@hawk.iit.e=
du</a>&gt;</span>:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>=
</div><div>Hello Gurus,</div><div>I am adding a new rm scheduler to the rt-=
xen,</div><div>unfortunately I met &quot;undefined reference to &quot; erro=
r ,the output is below:</div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3Derror output begin=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D</div><div><br></div><div><br></div><div>ln -sf libxenlight.so.4.3=
.0 libxenlight.so.4.3</div><div>ln -sf libxenlight.so.4.3 libxenlight.so</d=
iv><div>gcc =C2=A0 =C2=A0-pthread -o xl xl.o xl_cmdimpl.o xl_cmdtable.o xl_=
sxp.o libxlutil.so /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../=
../tools/libxl/libxenlight.so -Wl,-rpath-link=3D/home/jackyshen/RT-XEN/RT-X=
en-rt-xen_2.0/tools/libxl/../../tools/libxc -Wl,-rpath-link=3D/home/jackysh=
en/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/xenstore -Wl,-rpath-lin=
k=3D/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/blktap=
2/control /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/=
libxc/libxenctrl.so -lyajl=C2=A0</div><div>/home/jackyshen/RT-XEN/RT-Xen-rt=
-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so: undefined reference =
to `xc_sched_rm_domain_get&#39;</div><div>/home/jackyshen/RT-XEN/RT-Xen-rt-=
xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so: undefined reference t=
o `xc_sched_rm_domain_set&#39;</div><div>collect2: error: ld returned 1 exi=
t status</div><div>make[3]: *** [xl] Error 1</div><div>make[3]: Leaving dir=
ectory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl&#39;</div><div=
>make[2]: *** [subdir-install-libxl] Error 2</div><div>make[2]: Leaving dir=
ectory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools&#39;</div><div>make[=
1]: *** [subdirs-install] Error 2</div><div>make[1]: Leaving directory `/ho=
me/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools&#39;</div><div>make: *** [insta=
ll-tools] Error 2</div><div><br></div><div><div><div dir=3D"ltr"><div><div>=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D error output end =3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br><br>I searched all the=
 folder ,it should be defined in the file :(reference rtpartion)</div><div>=
<br></div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D grep for rm=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</d=
iv><div><div>jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ =
grep -r =C2=A0xc_sched_rm_domain_set</div><div>dist/install/usr/local/inclu=
de/xenctrl.h~:int xc_sched_rm_domain_set(xc_interface *xch,</div><div>dist/=
install/usr/local/include/xenctrl.h:int xc_sched_rm_domain_set(xc_interface=
 *xch,</div><div>tools/libxc/xc_rm.c:xc_sched_rm_domain_set(</div><div>tool=
s/libxc/xenctrl.h:int xc_sched_rm_domain_set(xc_interface *xch,</div><div>t=
ools/libxl/libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_domain_set(CTX-&gt;xch,=
 domid, &amp;sdom);</div><div>Binary file tools/libxl/libxenlight.so.4.3.0 =
matches</div><div>Binary file tools/libxl/libxl.o matches</div><div>tools/p=
ython/xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_set(XcObje=
ct *self,</div><div>tools/python/xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc=
_sched_rm_domain_set(self-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</div><d=
iv>tools/python/xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc=
_sched_rm_domain_set,</div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dgrep for rtpartion =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D</div><div>jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen=
-rt-xen_2.0$ grep -r =C2=A0xc_sched_rtpartition_domain_set</div><div>dist/i=
nstall/usr/local/include/xenctrl.h~:int xc_sched_rtpartition_domain_set(xc_=
interface *xch,</div><div>dist/install/usr/local/include/xenctl.hbak:int xc=
_sched_rtpartition_domain_set(xc_interface *xch, =C2=A0 =C2=A0 =3D=3D=3D&gt=
;bakfile can be ignored</div><div>dist/install/usr/local/include/xenctrl.h:=
int xc_sched_rtpartition_domain_set(xc_interface *xch,</div><div>Binary fil=
e dist/install/usr/local/lib/libxenlight.so.4.3.0 matches</div><div>Binary =
file dist/install/usr/local/lib/libxenlight.a matches</div><div>Binary file=
 dist/install/usr/local/lib/libxenctrl.so.4.3.0 matches</div><div>Binary fi=
le dist/install/usr/local/lib/libxenctrl.a matches</div><div>Binary file di=
st/install/usr/local/lib/python2.7/dist-packages/xen/lowlevel/xc.so matches=
</div><div>Binary file tools/libxc/libxenctrl.so.4.3.0 matches</div><div>Bi=
nary file tools/libxc/libxenctrl.a matches</div><div>Binary file tools/libx=
c/xc_rtpartition.o matches</div><div>tools/libxc/xc_rtpartition.c:xc_sched_=
rtpartition_domain_set(</div><div>Binary file tools/libxc/xc_rtpartition.op=
ic matches</div><div>tools/libxc/xenctrl.h:int xc_sched_rtpartition_domain_=
set(xc_interface *xch,</div><div>tools/libxl/libxl.c: =C2=A0 =C2=A0rc =3D x=
c_sched_rtpartition_domain_set(CTX-&gt;xch, domid, &amp;sdom);</div><div>Bi=
nary file tools/libxl/libxenlight.so.4.3.0 matches</div><div>tools/libxl/li=
bxl.cbak: =C2=A0 =C2=A0rc =3D xc_sched_rtpartition_domain_set(CTX-&gt;xch, =
domid, &amp;sdom);</div><div>Binary file tools/libxl/libxl.o matches</div><=
div>tools/libxl/libxl.cbak.20141211: =C2=A0 =C2=A0rc =3D xc_sched_rtpartiti=
on_domain_set(CTX-&gt;xch, domid, &amp;sdom);</div><div>tools/python/xen/lo=
wlevel/xc/xc.c:static PyObject *pyxc_sched_rtpartition_domain_set(XcObject =
*self,</div><div>tools/python/xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sc=
hed_rtpartition_domain_set(self-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</=
div><div>tools/python/xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunctio=
n)pyxc_sched_rtpartition_domain_set,</div><div>tools/python/xen/lowlevel/xc=
/xc.cbak:static PyObject *pyxc_sched_rtpartition_domain_set(XcObject *self,=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =3D=3D=3D&gt;bakfile</div><div>tools/python/xen/lowlevel/xc/xc.cbak: =
=C2=A0 =C2=A0if ( xc_sched_rtpartition_domain_set(self-&gt;xc_handle, domid=
, &amp;sdom) !=3D 0 )</div><div>tools/python/xen/lowlevel/xc/xc.cbak: =C2=
=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rtpartition_domain_set,</div><div>=
jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$=C2=A0</div><d=
iv><br></div><div><br></div><div><br></div>Could you please advice me where=
 I need to define it?</div><div>Thank you very much!<br><br><br>=C2=A0Best =
regards<br>Jie Shen <br><br><br></div>Graduate Student in Computer Science<=
br></div>Illinois Institute of Technology=C2=A0=C2=A0=C2=A0 <br>Stuart Buil=
ding=C2=A0 Chicago, IL 60616<br><a href=3D"tel:%2B1%C2%A0%20312%20404%20012=
2" value=3D"+13124040122" target=3D"_blank">+1=C2=A0 312 404 0122</a><span =
class=3D"HOEnZb"><font color=3D"#888888"><br><div><br></div></font></span><=
/div></div></div><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;rtxen-devel&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:rtxen-devel+unsubscribe@googlegroups.com" target=
=3D"_blank">rtxen-devel+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to <a href=3D"mailto:rtxen-devel@googlegr=
oups.com" target=3D"_blank">rtxen-devel@googlegroups.com</a>.<br>
For more options, visit <a href=3D"https://groups.google.com/d/optout" targ=
et=3D"_blank">https://groups.google.com/d/optout</a>.<br>
</font></span></blockquote></div><br clear=3D"all"><br>-- <br><div class=3D=
"gmail_signature"><div dir=3D"ltr"><br><br>-----------<br>Meng Xu<br>PhD St=
udent in Computer and Information Science<br>University of Pennsylvania</di=
v></div>
</div>

--001a113defd8ce3772050a354f57--


--===============8817972448961495193==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8817972448961495193==--


From xen-devel-bounces@lists.xen.org Sun Dec 14 23:59:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 23: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 1Y0J49-0001Vm-C8; Sun, 14 Dec 2014 23:59:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=1Rc1=BC=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1Y0J48-0001Ve-4o
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 23:59:08 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	97/32-03148-B442E845; Sun, 14 Dec 2014 23:59:07 +0000
X-Env-Sender: SRS0=1Rc1=BC=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418601546!11668442!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24880 invoked from network); 14 Dec 2014 23:59:06 -0000
Received: from sonata.ens-lyon.org (HELO sonata.ens-lyon.org) (140.77.166.138)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2014 23:59:06 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id CCE0C20095;
	Mon, 15 Dec 2014 00:59:05 +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 74hxKJyJgYXC; Mon, 15 Dec 2014 00:59:05 +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 7DA4220094;
	Mon, 15 Dec 2014 00:59:05 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1Y0J43-0001YK-Si; Mon, 15 Dec 2014 00:59:03 +0100
Date: Mon, 15 Dec 2014 00:59:03 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
Message-ID: <20141214235903.GB2983@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
References: <20141204135550.GC11192@dezo.moloch.sk>
	<20141207195343.GC3141@type.youpi.perso.aquilenet.fr>
	<20141211120959.GA3218@dezo.moloch.sk>
MIME-Version: 1.0
Content-Length: 3637
Content-Disposition: inline
In-Reply-To: <20141211120959.GA3218@dezo.moloch.sk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Subject: Re: [Xen-devel] [PATCH] Mini-OS: netfront: Fix rx ring starvation
 in network_rx
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Martin Lucina, le Thu 11 Dec 2014 13:10:00 +0100, a =E9crit :
> I've done this in the updated patch, take a look and let me know what you
> think.

I like that :)

> From 3880f59159bf0a05b47b6e723091b1e7e4fb6814 Mon Sep 17 00:00:00 2001
> From: Martin Lucina <martin@lucina.net>
> Date: Thu, 4 Dec 2014 14:33:53 +0100
> Subject: [PATCH] Mini-OS: netfront: Fix rx ring starvation in network_rx
> =

> In network_rx() we must push the same amount of requests back onto the
> ring in the second loop that we consumed in the first loop. Otherwise
> the ring will eventually starve itself of free request slots and no
> packets will be delivered.
> =

> Further, we make the HAVE_LIBC codepath clearer to follow by removing
> the "some" variable from the for loop initialisation and conditions.
> =

> Signed-off-by: Martin Lucina <martin@lucina.net>

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> ---
>  extras/mini-os/netfront.c |   36 +++++++++++++++++-------------------
>  1 file changed, 17 insertions(+), 19 deletions(-)
> =

> diff --git a/extras/mini-os/netfront.c b/extras/mini-os/netfront.c
> index 44c3995..42bb103 100644
> --- a/extras/mini-os/netfront.c
> +++ b/extras/mini-os/netfront.c
> @@ -96,42 +96,35 @@ static inline int xennet_rxidx(RING_IDX idx)
>  void network_rx(struct netfront_dev *dev)
>  {
>      RING_IDX rp,cons,req_prod;
> -    struct netif_rx_response *rx;
> -    int nr_consumed, some, more, i, notify;
> -
> +    int nr_consumed, more, i, notify;
> +#ifdef HAVE_LIBC
> +    int some;
> +#endif
>  =

> +    nr_consumed =3D 0;
>  moretodo:
>      rp =3D dev->rx.sring->rsp_prod;
>      rmb(); /* Ensure we see queued responses up to 'rp'. */
> -    cons =3D dev->rx.rsp_cons;
>  =

> -    for (nr_consumed =3D 0, some =3D 0;
> -         (cons !=3D rp) && !some;
> -         nr_consumed++, cons++)
> +#ifdef HAVE_LIBC
> +    some =3D 0;
> +#endif
> +    for (cons =3D dev->rx.rsp_cons; cons !=3D rp; nr_consumed++, cons++)
>      {
>          struct net_buffer* buf;
>          unsigned char* page;
>          int id;
>  =

> -        rx =3D RING_GET_RESPONSE(&dev->rx, cons);
> -
> -        if (rx->flags & NETRXF_extra_info)
> -        {
> -            printk("+++++++++++++++++++++ we have extras!\n");
> -            continue;
> -        }
> -
> -
> -        if (rx->status =3D=3D NETIF_RSP_NULL) continue;
> +        struct netif_rx_response *rx =3D RING_GET_RESPONSE(&dev->rx, con=
s);
>  =

>          id =3D rx->id;
> -        BUG_ON(id >=3D NET_TX_RING_SIZE);
> +        BUG_ON(id >=3D NET_RX_RING_SIZE);
>  =

>          buf =3D &dev->rx_buffers[id];
>          page =3D (unsigned char*)buf->page;
>          gnttab_end_access(buf->gref);
>  =

> -        if(rx->status>0)
> +        if (rx->status > NETIF_RSP_NULL)
>          {
>  #ifdef HAVE_LIBC
>  	    if (dev->netif_rx =3D=3D NETIF_SELECT_RX) {
> @@ -142,6 +135,7 @@ moretodo:
>  		memcpy(dev->data, page+rx->offset, len);
>  		dev->rlen =3D len;
>  		some =3D 1;
> +                break;
>  	    } else
>  #endif
>  		dev->netif_rx(page+rx->offset,rx->status);
> @@ -150,7 +144,11 @@ moretodo:
>      dev->rx.rsp_cons=3Dcons;
>  =

>      RING_FINAL_CHECK_FOR_RESPONSES(&dev->rx,more);
> +#ifdef HAVE_LIBC
>      if(more && !some) goto moretodo;
> +#else
> +    if(more) goto moretodo;
> +#endif
>  =

>      req_prod =3D dev->rx.req_prod_pvt;
>  =

> -- =

> 1.7.10.4
> =


-- =

Samuel
<T> csp.tar.gz:     ascii text
 -+- #ens-mim - vive les browsers qui prennent des initiatives =E0 la con -=
+-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 14 23:59:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Dec 2014 23: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 1Y0J49-0001Vm-C8; Sun, 14 Dec 2014 23:59:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<SRS0=1Rc1=BC=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
	id 1Y0J48-0001Ve-4o
	for xen-devel@lists.xen.org; Sun, 14 Dec 2014 23:59:08 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	97/32-03148-B442E845; Sun, 14 Dec 2014 23:59:07 +0000
X-Env-Sender: SRS0=1Rc1=BC=ens-lyon.org=samuel.thibault@bounce.ens-lyon.o rg
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418601546!11668442!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24880 invoked from network); 14 Dec 2014 23:59:06 -0000
Received: from sonata.ens-lyon.org (HELO sonata.ens-lyon.org) (140.77.166.138)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Dec 2014 23:59:06 -0000
Received: from localhost (localhost [127.0.0.1])
	by sonata.ens-lyon.org (Postfix) with ESMTP id CCE0C20095;
	Mon, 15 Dec 2014 00:59:05 +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 74hxKJyJgYXC; Mon, 15 Dec 2014 00:59:05 +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 7DA4220094;
	Mon, 15 Dec 2014 00:59:05 +0100 (CET)
Received: from samy by type.youpi.perso.aquilenet.fr with local (Exim 4.84)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1Y0J43-0001YK-Si; Mon, 15 Dec 2014 00:59:03 +0100
Date: Mon, 15 Dec 2014 00:59:03 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
Message-ID: <20141214235903.GB2983@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
References: <20141204135550.GC11192@dezo.moloch.sk>
	<20141207195343.GC3141@type.youpi.perso.aquilenet.fr>
	<20141211120959.GA3218@dezo.moloch.sk>
MIME-Version: 1.0
Content-Length: 3637
Content-Disposition: inline
In-Reply-To: <20141211120959.GA3218@dezo.moloch.sk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Subject: Re: [Xen-devel] [PATCH] Mini-OS: netfront: Fix rx ring starvation
 in network_rx
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Martin Lucina, le Thu 11 Dec 2014 13:10:00 +0100, a =E9crit :
> I've done this in the updated patch, take a look and let me know what you
> think.

I like that :)

> From 3880f59159bf0a05b47b6e723091b1e7e4fb6814 Mon Sep 17 00:00:00 2001
> From: Martin Lucina <martin@lucina.net>
> Date: Thu, 4 Dec 2014 14:33:53 +0100
> Subject: [PATCH] Mini-OS: netfront: Fix rx ring starvation in network_rx
> =

> In network_rx() we must push the same amount of requests back onto the
> ring in the second loop that we consumed in the first loop. Otherwise
> the ring will eventually starve itself of free request slots and no
> packets will be delivered.
> =

> Further, we make the HAVE_LIBC codepath clearer to follow by removing
> the "some" variable from the for loop initialisation and conditions.
> =

> Signed-off-by: Martin Lucina <martin@lucina.net>

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> ---
>  extras/mini-os/netfront.c |   36 +++++++++++++++++-------------------
>  1 file changed, 17 insertions(+), 19 deletions(-)
> =

> diff --git a/extras/mini-os/netfront.c b/extras/mini-os/netfront.c
> index 44c3995..42bb103 100644
> --- a/extras/mini-os/netfront.c
> +++ b/extras/mini-os/netfront.c
> @@ -96,42 +96,35 @@ static inline int xennet_rxidx(RING_IDX idx)
>  void network_rx(struct netfront_dev *dev)
>  {
>      RING_IDX rp,cons,req_prod;
> -    struct netif_rx_response *rx;
> -    int nr_consumed, some, more, i, notify;
> -
> +    int nr_consumed, more, i, notify;
> +#ifdef HAVE_LIBC
> +    int some;
> +#endif
>  =

> +    nr_consumed =3D 0;
>  moretodo:
>      rp =3D dev->rx.sring->rsp_prod;
>      rmb(); /* Ensure we see queued responses up to 'rp'. */
> -    cons =3D dev->rx.rsp_cons;
>  =

> -    for (nr_consumed =3D 0, some =3D 0;
> -         (cons !=3D rp) && !some;
> -         nr_consumed++, cons++)
> +#ifdef HAVE_LIBC
> +    some =3D 0;
> +#endif
> +    for (cons =3D dev->rx.rsp_cons; cons !=3D rp; nr_consumed++, cons++)
>      {
>          struct net_buffer* buf;
>          unsigned char* page;
>          int id;
>  =

> -        rx =3D RING_GET_RESPONSE(&dev->rx, cons);
> -
> -        if (rx->flags & NETRXF_extra_info)
> -        {
> -            printk("+++++++++++++++++++++ we have extras!\n");
> -            continue;
> -        }
> -
> -
> -        if (rx->status =3D=3D NETIF_RSP_NULL) continue;
> +        struct netif_rx_response *rx =3D RING_GET_RESPONSE(&dev->rx, con=
s);
>  =

>          id =3D rx->id;
> -        BUG_ON(id >=3D NET_TX_RING_SIZE);
> +        BUG_ON(id >=3D NET_RX_RING_SIZE);
>  =

>          buf =3D &dev->rx_buffers[id];
>          page =3D (unsigned char*)buf->page;
>          gnttab_end_access(buf->gref);
>  =

> -        if(rx->status>0)
> +        if (rx->status > NETIF_RSP_NULL)
>          {
>  #ifdef HAVE_LIBC
>  	    if (dev->netif_rx =3D=3D NETIF_SELECT_RX) {
> @@ -142,6 +135,7 @@ moretodo:
>  		memcpy(dev->data, page+rx->offset, len);
>  		dev->rlen =3D len;
>  		some =3D 1;
> +                break;
>  	    } else
>  #endif
>  		dev->netif_rx(page+rx->offset,rx->status);
> @@ -150,7 +144,11 @@ moretodo:
>      dev->rx.rsp_cons=3Dcons;
>  =

>      RING_FINAL_CHECK_FOR_RESPONSES(&dev->rx,more);
> +#ifdef HAVE_LIBC
>      if(more && !some) goto moretodo;
> +#else
> +    if(more) goto moretodo;
> +#endif
>  =

>      req_prod =3D dev->rx.req_prod_pvt;
>  =

> -- =

> 1.7.10.4
> =


-- =

Samuel
<T> csp.tar.gz:     ascii text
 -+- #ens-mim - vive les browsers qui prennent des initiatives =E0 la con -=
+-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 00:44:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 00:44:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0JlP-0002tq-7h; Mon, 15 Dec 2014 00:43: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 1Y0JlN-0002tl-4F
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 00:43:49 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	9E/0A-14727-4CE2E845; Mon, 15 Dec 2014 00:43:48 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418604226!13265838!1
X-Originating-IP: [66.165.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 10149 invoked from network); 15 Dec 2014 00:43:47 -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;
	15 Dec 2014 00:43:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,577,1413244800"; d="scan'208";a="204225049"
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.210.2; Sun, 14 Dec 2014 19:43: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 1Y0JlG-0005pG-M4;
	Mon, 15 Dec 2014 00:43:42 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0JlG-0002lf-Ep;
	Mon, 15 Dec 2014 00:43:42 +0000
Date: Mon, 15 Dec 2014 00:43:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32348-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] 32348: 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 32348 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32348/

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
 build-i386-libvirt            3 host-install(3)         broken REGR. vs. 31241
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 31241
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 31241
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 31241
 test-amd64-i386-xl           12 guest-localmigrate        fail REGR. vs. 31241
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 31241
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)  broken REGR. vs. 31241
 build-amd64-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-armhf-armhf-xl          11 guest-stop               fail blocked in 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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  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-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 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-pair         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-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  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-qemut-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-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-amd64-xl-qemut-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)               blocked n/a

version targeted for testing:
 linux                9ea18f8cab5f1c36cdd0f09717e35ceb48c36a87
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1588 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                                           broken  
 build-amd64-pvops                                            broken  
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          blocked 
 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                    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                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 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                                   broken  
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-amd64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 fail    
 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

broken-step build-i386-libvirt host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-xl-credit2 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-i386-xl-qemuu-ovmf-amd64 host-install(3)
broken-step build-amd64-pvops host-install(3)

Not pushing.

(No revision log; it would be 160803 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 Dec 15 00:44:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 00:44:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0JlP-0002tq-7h; Mon, 15 Dec 2014 00:43: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 1Y0JlN-0002tl-4F
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 00:43:49 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	9E/0A-14727-4CE2E845; Mon, 15 Dec 2014 00:43:48 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418604226!13265838!1
X-Originating-IP: [66.165.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 10149 invoked from network); 15 Dec 2014 00:43:47 -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;
	15 Dec 2014 00:43:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,577,1413244800"; d="scan'208";a="204225049"
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.210.2; Sun, 14 Dec 2014 19:43: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 1Y0JlG-0005pG-M4;
	Mon, 15 Dec 2014 00:43:42 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0JlG-0002lf-Ep;
	Mon, 15 Dec 2014 00:43:42 +0000
Date: Mon, 15 Dec 2014 00:43:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32348-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] 32348: 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 32348 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32348/

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
 build-i386-libvirt            3 host-install(3)         broken REGR. vs. 31241
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 31241
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 31241
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 31241
 test-amd64-i386-xl           12 guest-localmigrate        fail REGR. vs. 31241
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 31241
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)  broken REGR. vs. 31241
 build-amd64-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-armhf-armhf-xl          11 guest-stop               fail blocked in 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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  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-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 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-pair         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-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  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-qemut-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-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-amd64-xl-qemut-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)               blocked n/a

version targeted for testing:
 linux                9ea18f8cab5f1c36cdd0f09717e35ceb48c36a87
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1588 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                                           broken  
 build-amd64-pvops                                            broken  
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          blocked 
 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                    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                              fail    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64                          broken  
 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                                   broken  
 test-amd64-i386-freebsd10-i386                               fail    
 test-amd64-i386-rumpuserxen-i386                             fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-amd64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      blocked 
 test-amd64-i386-xl-multivcpu                                 fail    
 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

broken-step build-i386-libvirt host-install(3)
broken-step test-amd64-i386-qemuu-rhel6hvm-intel host-install(3)
broken-step test-amd64-i386-xl-credit2 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-i386-xl-qemuu-ovmf-amd64 host-install(3)
broken-step build-amd64-pvops host-install(3)

Not pushing.

(No revision log; it would be 160803 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 Dec 15 03:14:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 03: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 1Y0M6N-0001jX-OH; Mon, 15 Dec 2014 03:13:39 +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 1Y0M6M-0001jS-7E
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 03:13:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1D/3D-25276-1E15E845; Mon, 15 Dec 2014 03:13:37 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418613215!15575567!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31134 invoked from network); 15 Dec 2014 03:13:36 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 03:13:36 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Sun, 14 Dec 2014 20:13:34 -0700
Message-Id: <548EC2530200006600084AE4@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Sun, 14 Dec 2014 20:13:23 -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>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
	<20141208111214.GC17128@zion.uk.xensource.com>
	<5486F36502000066000825D5@soto.provo.novell.com>
	<1418123518.14361.20.camel@citrix.com>
	<548832AD0200006600082E25@soto.provo.novell.com>
	<1418401323.16425.28.camel@citrix.com>
In-Reply-To: <1418401323.16425.28.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, 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 12/13/2014 at 12:22 AM, in message <1418401323.16425.28.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-12-09 at 20:46 -0700, Chun Yan Liu wrote: 
> >  
> > >>> On 12/9/2014 at 07:11 PM, in message <1418123518.14361.20.camel@citrix.com>, 
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:  
> > > On Mon, 2014-12-08 at 22:04 -0700, Chun Yan Liu wrote:  
> > > > Partly. At least for domain disk snapshot create/delete, I prefer using  
> > > > qmp commands instead of calling qemu-img one by one. Using qmp  
> > > > commands, libvirt will need libxl's help. Of course, if libxl doesn't  
> > > > supply that, libvirt can call qemu-img to each disk one by one,  
> > > > not preferred but can do.  
> > >   
> > > You can't use qmp unless the domain is active, for an inactive domain  
> > > there is no qemu to talk to, so you have to use qemu-img anyway in that  
> > > case. Does libvirt not have existing code to do all this sort of thing?  
> > > (I thought so, but it turns out I may be wrong, see below).  
> >  
> > No. Even inlibvirt/qemu_driver (for kvm), it does the work itself through 
> > qemu monitor commands. 
>  
> Is this just the code for the actual act of taking a snapshot or is it a 
> complete snapshotting infrastructure in the driver itself? 
>  
> I would hope/assume that there was a split between the common code which 
> drives everything and tracks all the state etc and the specific driver 
> backend which is used to make state changes to active domains. Is that 
> the case or is everything snapshot related in the libvirt qemu_driver? 

Everything snapshot related is done in libvirt qemu driver. But data structures
about managing domain snapshots are common, so each hypervisor driver can
share.

>  
> > > And for an active domain I expect that *must* use qmp, since it seems  
> > > unlikely that you can go around changing things under the feet of an  
> > > active process (maybe I'm wrong?). 
> >  
> > For active domain, I tried 'qemu-img snapshot' after pausing a domain, 
> > the commands succeeded. But I also think using qmp commands is better 
> > since qemu supplies transaction qmp, it avoids the trouble to roll back 
> > status when using qemu-img to do disk snapshot one by one but only part of 
> > disks succeed. 
>  
> Yes, using qmp for an active domain seems sensible. 
>  
> But you can't use qmp on an inactive domain. Does libvirt deal with this 
> in common code or does it require two code paths in the backend driver, 
> one for active and one for inactive domains? 

Taking libvirt qemu driver for example, it goes two codes paths for active
domain and inactive domain. For inactive domain, it calls qemu-img
command to do the job. For active domain, calls qmp commands through
qemu monitor.

>  
> > So, if disk snapshot functions can be provided to both libvirt and xl  
> usage, 
> > it's very helpful to libvirt side. In this way, I may prefer to put disk  
> snapshot 
> > functions to libxlu. 
>  
> The actual command to snapshot a disk of an active+paused domain is fine 
> to go into libxl. In fact due to the proposed use of qmp it would have 
> to be. 
>  
> Anything to do with the subsequent management of snapshots most likely 
> doesn't belong in libxl. Whether that stuff belongs in libxlu, xl or 
> libvirt depends on what scope there is for multiple toolstacks to use a 
> given helper function. 

OK. Thanks.

>  
> > > My understanding was that your primary aim here was to enable snapshots  
> > > via libvirt and that xl support was just a nice to have. Is that right?  
> >  
> > We hope both :-) 
>  
> OK, thanks for clarifying. 
>  
> > Libvirt side already has some codes as I know and hopes to integrate with 
> > libxl to enable snapshots. Of course the two toolstacks can have some 
> > differences in commands, that's OK. 
> >  
> > Libvirt side, to use unified virsh commands, it will supply 
> > snapshot-create/delete/revert/list. 
>  
> This is what I expected you were aiming for. 
>  
> > Xl side, if it's better to supply snapshot-create/revert, we can implement 
> > like that. Then it IS much easier since no need to manage snapshots in xl, 
> > then no save/retrieve json file things and no snapshot chain things. Do 
> > we want/decide to follow this? 
>  
> The xl snapshot functionality should be kept as simple as possible and 
> following the existing xl idioms of managing storage and saved VM images 
> via existing CLI command (qemu-img, lvcreate, ls, mv, cp etc).

Got it. Thanks. So I'll update document.

Chunyan
 
>  
> Ian. 
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 03:14:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 03: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 1Y0M6N-0001jX-OH; Mon, 15 Dec 2014 03:13:39 +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 1Y0M6M-0001jS-7E
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 03:13:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1D/3D-25276-1E15E845; Mon, 15 Dec 2014 03:13:37 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418613215!15575567!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31134 invoked from network); 15 Dec 2014 03:13:36 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 03:13:36 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Sun, 14 Dec 2014 20:13:34 -0700
Message-Id: <548EC2530200006600084AE4@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Sun, 14 Dec 2014 20:13:23 -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>
	<20141205160615.GA24938@zion.uk.xensource.com>
	<5485C5170200006600081D20@soto.provo.novell.com>
	<20141208111214.GC17128@zion.uk.xensource.com>
	<5486F36502000066000825D5@soto.provo.novell.com>
	<1418123518.14361.20.camel@citrix.com>
	<548832AD0200006600082E25@soto.provo.novell.com>
	<1418401323.16425.28.camel@citrix.com>
In-Reply-To: <1418401323.16425.28.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian.Jackson@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, 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 12/13/2014 at 12:22 AM, in message <1418401323.16425.28.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-12-09 at 20:46 -0700, Chun Yan Liu wrote: 
> >  
> > >>> On 12/9/2014 at 07:11 PM, in message <1418123518.14361.20.camel@citrix.com>, 
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:  
> > > On Mon, 2014-12-08 at 22:04 -0700, Chun Yan Liu wrote:  
> > > > Partly. At least for domain disk snapshot create/delete, I prefer using  
> > > > qmp commands instead of calling qemu-img one by one. Using qmp  
> > > > commands, libvirt will need libxl's help. Of course, if libxl doesn't  
> > > > supply that, libvirt can call qemu-img to each disk one by one,  
> > > > not preferred but can do.  
> > >   
> > > You can't use qmp unless the domain is active, for an inactive domain  
> > > there is no qemu to talk to, so you have to use qemu-img anyway in that  
> > > case. Does libvirt not have existing code to do all this sort of thing?  
> > > (I thought so, but it turns out I may be wrong, see below).  
> >  
> > No. Even inlibvirt/qemu_driver (for kvm), it does the work itself through 
> > qemu monitor commands. 
>  
> Is this just the code for the actual act of taking a snapshot or is it a 
> complete snapshotting infrastructure in the driver itself? 
>  
> I would hope/assume that there was a split between the common code which 
> drives everything and tracks all the state etc and the specific driver 
> backend which is used to make state changes to active domains. Is that 
> the case or is everything snapshot related in the libvirt qemu_driver? 

Everything snapshot related is done in libvirt qemu driver. But data structures
about managing domain snapshots are common, so each hypervisor driver can
share.

>  
> > > And for an active domain I expect that *must* use qmp, since it seems  
> > > unlikely that you can go around changing things under the feet of an  
> > > active process (maybe I'm wrong?). 
> >  
> > For active domain, I tried 'qemu-img snapshot' after pausing a domain, 
> > the commands succeeded. But I also think using qmp commands is better 
> > since qemu supplies transaction qmp, it avoids the trouble to roll back 
> > status when using qemu-img to do disk snapshot one by one but only part of 
> > disks succeed. 
>  
> Yes, using qmp for an active domain seems sensible. 
>  
> But you can't use qmp on an inactive domain. Does libvirt deal with this 
> in common code or does it require two code paths in the backend driver, 
> one for active and one for inactive domains? 

Taking libvirt qemu driver for example, it goes two codes paths for active
domain and inactive domain. For inactive domain, it calls qemu-img
command to do the job. For active domain, calls qmp commands through
qemu monitor.

>  
> > So, if disk snapshot functions can be provided to both libvirt and xl  
> usage, 
> > it's very helpful to libvirt side. In this way, I may prefer to put disk  
> snapshot 
> > functions to libxlu. 
>  
> The actual command to snapshot a disk of an active+paused domain is fine 
> to go into libxl. In fact due to the proposed use of qmp it would have 
> to be. 
>  
> Anything to do with the subsequent management of snapshots most likely 
> doesn't belong in libxl. Whether that stuff belongs in libxlu, xl or 
> libvirt depends on what scope there is for multiple toolstacks to use a 
> given helper function. 

OK. Thanks.

>  
> > > My understanding was that your primary aim here was to enable snapshots  
> > > via libvirt and that xl support was just a nice to have. Is that right?  
> >  
> > We hope both :-) 
>  
> OK, thanks for clarifying. 
>  
> > Libvirt side already has some codes as I know and hopes to integrate with 
> > libxl to enable snapshots. Of course the two toolstacks can have some 
> > differences in commands, that's OK. 
> >  
> > Libvirt side, to use unified virsh commands, it will supply 
> > snapshot-create/delete/revert/list. 
>  
> This is what I expected you were aiming for. 
>  
> > Xl side, if it's better to supply snapshot-create/revert, we can implement 
> > like that. Then it IS much easier since no need to manage snapshots in xl, 
> > then no save/retrieve json file things and no snapshot chain things. Do 
> > we want/decide to follow this? 
>  
> The xl snapshot functionality should be kept as simple as possible and 
> following the existing xl idioms of managing storage and saved VM images 
> via existing CLI command (qemu-img, lvcreate, ls, mv, cp etc).

Got it. Thanks. So I'll update document.

Chunyan
 
>  
> Ian. 
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 03:27:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 03: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 1Y0MJN-00021X-78; Mon, 15 Dec 2014 03:27:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0MJL-00021S-FF
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 03:27:03 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	57/A3-27623-6055E845; Mon, 15 Dec 2014 03:27:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418614020!13156313!1
X-Originating-IP: [66.165.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 20203 invoked from network); 15 Dec 2014 03:27: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;
	15 Dec 2014 03:27:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,577,1413244800"; d="scan'208";a="204705082"
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.210.2; Sun, 14 Dec 2014 22:26: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 1Y0MJH-0006bb-EK;
	Mon, 15 Dec 2014 03:26:59 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0MJH-0006Gz-98;
	Mon, 15 Dec 2014 03:26:59 +0000
Date: Mon, 15 Dec 2014 03:26:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32352-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 9495
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32352: 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="===============4376500363363639758=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4376500363363639758==
Content-Type: text/plain
Content-Length: 9196
Content-Transfer-Encoding: quoted-printable

flight 32352 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32352/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 32194
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 32194
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 32194
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 32194
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 32194

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-amd64  3 host-install(3)        broken pass in 32326
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)    broken pass in 32326
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 32326 pass in 32352
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot   fail in 32326 pass in 32352
 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 32326 pass in 32352
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 32326 pass in 32352
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 guest-localmigrate.2 fail in 32326 pass in 32352
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken in 32326 pass in 32352

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32194

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-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-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-armhf-armhf-xl          10 migrate-support-check        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                99c9c3cb24e566258a0a141178934f9cb5198842
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Amos Kong <akong@redhat.com>
  Anton Blanchard <anton@samba.org>
  Antony Pavlov <antonynpavlov@gmail.com>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Christoffer Dall <christoffer.dall@linaro.org>
  Dr. David Alan Gilbert <dgilbert@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>
  Jeff Cody <jcody@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  lijun <junmuzi@gmail.com>
  Liviu Ionescu <ilg@livius.net>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael Mueller <mimu@linux.vnet.ibm.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Nikita Belov <zodiac@ispras.ru>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@linux.vnet.ibm.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                                           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                         broken  
 test-amd64-i386-xl-qemuu-ovmf-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                               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                                        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-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-i386-freebsd10-amd64 host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)
broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)

Not pushing.

(No revision log; it would be 2395 lines long.)


--===============4376500363363639758==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4376500363363639758==--

From xen-devel-bounces@lists.xen.org Mon Dec 15 03:27:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 03: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 1Y0MJN-00021X-78; Mon, 15 Dec 2014 03:27:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0MJL-00021S-FF
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 03:27:03 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	57/A3-27623-6055E845; Mon, 15 Dec 2014 03:27:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418614020!13156313!1
X-Originating-IP: [66.165.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 20203 invoked from network); 15 Dec 2014 03:27: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;
	15 Dec 2014 03:27:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,577,1413244800"; d="scan'208";a="204705082"
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.210.2; Sun, 14 Dec 2014 22:26: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 1Y0MJH-0006bb-EK;
	Mon, 15 Dec 2014 03:26:59 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0MJH-0006Gz-98;
	Mon, 15 Dec 2014 03:26:59 +0000
Date: Mon, 15 Dec 2014 03:26:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32352-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 9495
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32352: 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="===============4376500363363639758=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4376500363363639758==
Content-Type: text/plain
Content-Length: 9196
Content-Transfer-Encoding: quoted-printable

flight 32352 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32352/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 32194
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 32194
 test-amd64-i386-freebsd10-i386  3 host-install(3)       broken REGR. vs. 32194
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 32194
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 32194

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-amd64  3 host-install(3)        broken pass in 32326
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)    broken pass in 32326
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 32326 pass in 32352
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot   fail in 32326 pass in 32352
 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 32326 pass in 32352
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 32326 pass in 32352
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 guest-localmigrate.2 fail in 32326 pass in 32352
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken in 32326 pass in 32352

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32194

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-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-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-armhf-armhf-xl          10 migrate-support-check        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                99c9c3cb24e566258a0a141178934f9cb5198842
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Amos Kong <akong@redhat.com>
  Anton Blanchard <anton@samba.org>
  Antony Pavlov <antonynpavlov@gmail.com>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Christoffer Dall <christoffer.dall@linaro.org>
  Dr. David Alan Gilbert <dgilbert@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>
  Jeff Cody <jcody@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  lijun <junmuzi@gmail.com>
  Liviu Ionescu <ilg@livius.net>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael Mueller <mimu@linux.vnet.ibm.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Nikita Belov <zodiac@ispras.ru>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@linux.vnet.ibm.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                                           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                         broken  
 test-amd64-i386-xl-qemuu-ovmf-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                               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                                        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-step test-amd64-i386-xl-credit2 host-install(3)
broken-step test-amd64-i386-xl host-install(3)
broken-step test-amd64-i386-freebsd10-amd64 host-install(3)
broken-step test-amd64-i386-freebsd10-i386 host-install(3)
broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 host-install(3)
broken-step test-amd64-amd64-pair host-install/dst_host(4)
broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 host-install(3)

Not pushing.

(No revision log; it would be 2395 lines long.)


--===============4376500363363639758==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4376500363363639758==--

From xen-devel-bounces@lists.xen.org Mon Dec 15 03:56:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 03: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 1Y0MlT-0002dX-6P; Mon, 15 Dec 2014 03:56:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek.xen@gmail.com>)
	id 1Y0MlR-0002d7-IS; Mon, 15 Dec 2014 03:56:05 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	DF/76-15461-4DB5E845; Mon, 15 Dec 2014 03:56:04 +0000
X-Env-Sender: russell.pavlicek.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418615763!15204616!1
X-Originating-IP: [209.85.215.41]
X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP,
  SUSPICIOUS_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32592 invoked from network); 15 Dec 2014 03:56:03 -0000
Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com)
	(209.85.215.41)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 03:56:03 -0000
Received: by mail-la0-f41.google.com with SMTP id hv19so8818982lab.28
	for <multiple recipients>; Sun, 14 Dec 2014 19:56:03 -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=zU5ONomH9f2+bGyxrvK3wQvBVh5+CTNuxsoFrg6cTFw=;
	b=byn2sSnXSXTnIM0BhwuN/LQFqmtZoZqxtq18b6sXSsy6OgUgPH6ntwR39I36RGa9ON
	oyTXEyJ7k+kJqLICDAPSj9/HdsQ5raVgRRWUN7I+crR6x5ZbcJ+Ngl6xwC9gDEM2u9kg
	RqfzuFngUbEapupi+0x7zEAHhxlEIwRAsJgRTY5hYcJFlj8WJAwP1y0T7NJzy5thiX81
	/gkGb+Wyzy/LOAvNP7aCK575Q9lUT1WUFYajxWfWDXGHNjDbFNiZAQe/ij0yx1RJcVq2
	W5URJoCC3P47lguo3RBbeQ78B+NPrAslqQ7GrPZNHmlXisbTZPhKx31qGHtRUMQM3PBH
	TJUw==
MIME-Version: 1.0
X-Received: by 10.152.22.199 with SMTP id g7mr28280771laf.23.1418615763113;
	Sun, 14 Dec 2014 19:56:03 -0800 (PST)
Received: by 10.112.0.104 with HTTP; Sun, 14 Dec 2014 19:56:03 -0800 (PST)
In-Reply-To: <CAHehzX00Hg7CRLQt1Edmf2E6AW-ndZ54Tcofqcr2ovsyw1MYZQ@mail.gmail.com>
References: <CAHehzX00Hg7CRLQt1Edmf2E6AW-ndZ54Tcofqcr2ovsyw1MYZQ@mail.gmail.com>
Date: Sun, 14 Dec 2014 22:56:03 -0500
X-Google-Sender-Auth: MKNeBMXQW11hrsybPbY5vDfwTEo
Message-ID: <CAHehzX2E33iRk44xUuqZaSqhVHdpDZd4BQ4pD5eMobrFJGCrKw@mail.gmail.com>
From: Russ Pavlicek <russell.pavlicek@xenproject.org>
To: Russ Pavlicek <russell.pavlicek@xenproject.org>
Cc: "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, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Monday is the Last Xen Project Document Day of 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Reminder: Today is Document Day!

Give someone a present and document a new capability, or improve an
older page so it is up to date.

More information is below.  See you in #xendocs on IRC.

On Thu, Dec 11, 2014 at 2:46 PM, Russ Pavlicek
<russell.pavlicek@xenproject.org> wrote:
> Monday, December 15, will be our last Document Day of the year.
>
> Given the 4.5 RC4 Testing scheduled for Wednesday of next week and the holidays
> which occur later in the month, we have scheduled Document Day for Monday.
>
> This is a great time to get our documentation ready for the new
> release.  Have you
> added a new feature in this release?  Make sure it is in the Wiki.
> Have you noticed
> pages which might be confusing for a new installation?  Now is a great
> time to clean
> it up.  Have you information on better integrating Xen Project with
> other projects?
> Share that information with others.
>
> 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 Monday, 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
>
> 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 Monday in #xendocs!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 03:56:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 03: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 1Y0MlT-0002dX-6P; Mon, 15 Dec 2014 03:56:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek.xen@gmail.com>)
	id 1Y0MlR-0002d7-IS; Mon, 15 Dec 2014 03:56:05 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	DF/76-15461-4DB5E845; Mon, 15 Dec 2014 03:56:04 +0000
X-Env-Sender: russell.pavlicek.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418615763!15204616!1
X-Originating-IP: [209.85.215.41]
X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP,
  SUSPICIOUS_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32592 invoked from network); 15 Dec 2014 03:56:03 -0000
Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com)
	(209.85.215.41)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 03:56:03 -0000
Received: by mail-la0-f41.google.com with SMTP id hv19so8818982lab.28
	for <multiple recipients>; Sun, 14 Dec 2014 19:56:03 -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=zU5ONomH9f2+bGyxrvK3wQvBVh5+CTNuxsoFrg6cTFw=;
	b=byn2sSnXSXTnIM0BhwuN/LQFqmtZoZqxtq18b6sXSsy6OgUgPH6ntwR39I36RGa9ON
	oyTXEyJ7k+kJqLICDAPSj9/HdsQ5raVgRRWUN7I+crR6x5ZbcJ+Ngl6xwC9gDEM2u9kg
	RqfzuFngUbEapupi+0x7zEAHhxlEIwRAsJgRTY5hYcJFlj8WJAwP1y0T7NJzy5thiX81
	/gkGb+Wyzy/LOAvNP7aCK575Q9lUT1WUFYajxWfWDXGHNjDbFNiZAQe/ij0yx1RJcVq2
	W5URJoCC3P47lguo3RBbeQ78B+NPrAslqQ7GrPZNHmlXisbTZPhKx31qGHtRUMQM3PBH
	TJUw==
MIME-Version: 1.0
X-Received: by 10.152.22.199 with SMTP id g7mr28280771laf.23.1418615763113;
	Sun, 14 Dec 2014 19:56:03 -0800 (PST)
Received: by 10.112.0.104 with HTTP; Sun, 14 Dec 2014 19:56:03 -0800 (PST)
In-Reply-To: <CAHehzX00Hg7CRLQt1Edmf2E6AW-ndZ54Tcofqcr2ovsyw1MYZQ@mail.gmail.com>
References: <CAHehzX00Hg7CRLQt1Edmf2E6AW-ndZ54Tcofqcr2ovsyw1MYZQ@mail.gmail.com>
Date: Sun, 14 Dec 2014 22:56:03 -0500
X-Google-Sender-Auth: MKNeBMXQW11hrsybPbY5vDfwTEo
Message-ID: <CAHehzX2E33iRk44xUuqZaSqhVHdpDZd4BQ4pD5eMobrFJGCrKw@mail.gmail.com>
From: Russ Pavlicek <russell.pavlicek@xenproject.org>
To: Russ Pavlicek <russell.pavlicek@xenproject.org>
Cc: "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, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Monday is the Last Xen Project Document Day of 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Reminder: Today is Document Day!

Give someone a present and document a new capability, or improve an
older page so it is up to date.

More information is below.  See you in #xendocs on IRC.

On Thu, Dec 11, 2014 at 2:46 PM, Russ Pavlicek
<russell.pavlicek@xenproject.org> wrote:
> Monday, December 15, will be our last Document Day of the year.
>
> Given the 4.5 RC4 Testing scheduled for Wednesday of next week and the holidays
> which occur later in the month, we have scheduled Document Day for Monday.
>
> This is a great time to get our documentation ready for the new
> release.  Have you
> added a new feature in this release?  Make sure it is in the Wiki.
> Have you noticed
> pages which might be confusing for a new installation?  Now is a great
> time to clean
> it up.  Have you information on better integrating Xen Project with
> other projects?
> Share that information with others.
>
> 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 Monday, 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
>
> 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 Monday in #xendocs!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 05:21:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 05: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 1Y0O5Q-0004g6-Vu; Mon, 15 Dec 2014 05:20:48 +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 1Y0O5P-0004g1-2I
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 05:20:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AE/78-15461-EAF6E845; Mon, 15 Dec 2014 05:20:46 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418620845!7526818!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 11957 invoked from network); 15 Dec 2014 05:20:45 -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; 15 Dec 2014 05:20:45 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 462E7AC54;
	Mon, 15 Dec 2014 05:20:43 +0000 (UTC)
Message-ID: <548E6FAA.4070204@suse.com>
Date: Mon, 15 Dec 2014 06:20: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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	linux-kernel@vger.kernel.org, x86@kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	david.vrabel@citrix.com, tglx@linutronix.de, mingo@redhat.com, 
	hpa@zytor.com, mmarek@suse.cz, linux-kbuild@vger.kernel.org
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-2-git-send-email-jgross@suse.com>
	<548B70B3.7030807@oracle.com>
In-Reply-To: <548B70B3.7030807@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/12/2014 11:48 PM, Boris Ostrovsky wrote:
> On 12/11/2014 01:04 PM, Juergen Gross wrote:
>> diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
>> new file mode 100644
>> index 0000000..e6447b7
>> --- /dev/null
>> +++ b/scripts/xen-hypercalls.sh
>> @@ -0,0 +1,11 @@
>> +#!/bin/sh
>> +out="$1"
>> +shift
>> +in="$@"
>> +
>> +for i in $in; do
>> +    eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
>> +done | \
>> +awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] =
>> $2 }
>> +    END {for (i in v) if (!(v[i] in v))
>> +        print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
>
> Why do you 'sort -u'? Do you expect multiple definitions of the same
> hypercall?

Paranoia related to the use of wildcards for files scanned:

$(srctree)/include/xen/interface/xen*.h


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 05:21:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 05: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 1Y0O5Q-0004g6-Vu; Mon, 15 Dec 2014 05:20:48 +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 1Y0O5P-0004g1-2I
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 05:20:47 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AE/78-15461-EAF6E845; Mon, 15 Dec 2014 05:20:46 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418620845!7526818!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 11957 invoked from network); 15 Dec 2014 05:20:45 -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; 15 Dec 2014 05:20:45 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 462E7AC54;
	Mon, 15 Dec 2014 05:20:43 +0000 (UTC)
Message-ID: <548E6FAA.4070204@suse.com>
Date: Mon, 15 Dec 2014 06:20: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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	linux-kernel@vger.kernel.org, x86@kernel.org, 
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	david.vrabel@citrix.com, tglx@linutronix.de, mingo@redhat.com, 
	hpa@zytor.com, mmarek@suse.cz, linux-kbuild@vger.kernel.org
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-2-git-send-email-jgross@suse.com>
	<548B70B3.7030807@oracle.com>
In-Reply-To: <548B70B3.7030807@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/12/2014 11:48 PM, Boris Ostrovsky wrote:
> On 12/11/2014 01:04 PM, Juergen Gross wrote:
>> diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
>> new file mode 100644
>> index 0000000..e6447b7
>> --- /dev/null
>> +++ b/scripts/xen-hypercalls.sh
>> @@ -0,0 +1,11 @@
>> +#!/bin/sh
>> +out="$1"
>> +shift
>> +in="$@"
>> +
>> +for i in $in; do
>> +    eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
>> +done | \
>> +awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] =
>> $2 }
>> +    END {for (i in v) if (!(v[i] in v))
>> +        print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
>
> Why do you 'sort -u'? Do you expect multiple definitions of the same
> hypercall?

Paranoia related to the use of wildcards for files scanned:

$(srctree)/include/xen/interface/xen*.h


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 06:26:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 06: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 1Y0P6E-0005vu-Gg; Mon, 15 Dec 2014 06:25:42 +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 1Y0P6C-0005vp-Kr
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 06:25:40 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	61/DC-15461-4EE7E845; Mon, 15 Dec 2014 06:25:40 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418624738!15534816!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 21218 invoked from network); 15 Dec 2014 06:25:39 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-21.messagelabs.com with SMTP;
	15 Dec 2014 06:25:39 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2014 22:25:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="428970456"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by FMSMGA003.fm.intel.com with ESMTP; 14 Dec 2014 22:14:36 -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; Mon, 15 Dec 2014 14:25:12 +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; Mon, 15 Dec 2014 14:25:11 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQGC/gTnKCuINaSEuNrOPaD/DIeA==
Date: Mon, 15 Dec 2014 06:25:10 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
In-Reply-To: <548AD75B020000780004F342@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: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, December 12, 2014 6:54 PM
> 
> >>> On 12.12.14 at 08:24, <kevin.tian@intel.com> wrote:
> > - is there existing _map_ call for this purpose per your knowledge, or
> > a new one is required? If the latter, what's the additional logic to be
> > implemented there?
> 
> I think the answer to this depends on whether you want to use
> grants. The goal of using the native driver in the guest (mentioned
> further down) speaks against this, in which case I don't think we
> have an existing interface.

yes, grants don't apply here. 

> 
> > - when you say _map_, do you expect this mapped into dom0's virtual
> > address space, or just guest physical space?
> 
> Iiuc you don't care about the memory to be visible to the CPU, all
> you need is it being translated by the IOMMU. In which case the
> input address space for the IOMMU (which is different between PV
> and PVH) is where this needs to be mapped into.

it should be in p2m level, not just in IOMMU. otherwise I'm wondering 
there'll be tricky issues ahead due to inconsistent mapping between EPT 
and IOMMU page table (though a specific attributes like r/w may be 
different from previous split table discussion). 

another reason here. If we just talk about shadow GPU page table, yes
it's used by device only so IOMMU mapping is enough. However we do 
have several other places where we need to map and access guest memory,
e.g. scanning command in a buffer mapped through GPU page table (
currently through remap_domain_mfn_range_in_kernel). 

> 
> > - how is BFN or unused address (what do you mean by address here?)
> > allocated? does it need present in guest physical memory at boot time,
> > or just finding some holes?
> 
> Fitting this into holes should be fine.

this is an interesting open to be further discussed. Here we need consider 
the extreme case, i.e. a 64bit GPU page table can legitimately use up all 
the system memory allocates to that VM, and considering dozens of VMs, 
it means we need reserve a very large hole. 

I once remember some similar cases requiring grabbing some unmapped
pfns (in grant table?). So wonder whether there's already a clean interface
for such purpose, or we need tweak a new one to allocate unmapped pfns
(but won't conflict with usages like memory hotplug)...

appreciate any suggestion here.

> 
> > - graphics memory size could be large. starting from BDW, there'll
> > be 64bit page table format. Do you see any limitation here on finding
> > BFN or address?
> 
> I don't think this concern differs much for the different models: As long
> as you don't want the same underlying memory to be accessible by
> more than one guest, the address space requirements ought to be the
> same.

See above.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 06:26:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 06: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 1Y0P6E-0005vu-Gg; Mon, 15 Dec 2014 06:25:42 +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 1Y0P6C-0005vp-Kr
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 06:25:40 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	61/DC-15461-4EE7E845; Mon, 15 Dec 2014 06:25:40 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418624738!15534816!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 21218 invoked from network); 15 Dec 2014 06:25:39 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-21.messagelabs.com with SMTP;
	15 Dec 2014 06:25:39 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2014 22:25:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="428970456"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by FMSMGA003.fm.intel.com with ESMTP; 14 Dec 2014 22:14:36 -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; Mon, 15 Dec 2014 14:25:12 +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; Mon, 15 Dec 2014 14:25:11 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQGC/gTnKCuINaSEuNrOPaD/DIeA==
Date: Mon, 15 Dec 2014 06:25:10 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
In-Reply-To: <548AD75B020000780004F342@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: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, December 12, 2014 6:54 PM
> 
> >>> On 12.12.14 at 08:24, <kevin.tian@intel.com> wrote:
> > - is there existing _map_ call for this purpose per your knowledge, or
> > a new one is required? If the latter, what's the additional logic to be
> > implemented there?
> 
> I think the answer to this depends on whether you want to use
> grants. The goal of using the native driver in the guest (mentioned
> further down) speaks against this, in which case I don't think we
> have an existing interface.

yes, grants don't apply here. 

> 
> > - when you say _map_, do you expect this mapped into dom0's virtual
> > address space, or just guest physical space?
> 
> Iiuc you don't care about the memory to be visible to the CPU, all
> you need is it being translated by the IOMMU. In which case the
> input address space for the IOMMU (which is different between PV
> and PVH) is where this needs to be mapped into.

it should be in p2m level, not just in IOMMU. otherwise I'm wondering 
there'll be tricky issues ahead due to inconsistent mapping between EPT 
and IOMMU page table (though a specific attributes like r/w may be 
different from previous split table discussion). 

another reason here. If we just talk about shadow GPU page table, yes
it's used by device only so IOMMU mapping is enough. However we do 
have several other places where we need to map and access guest memory,
e.g. scanning command in a buffer mapped through GPU page table (
currently through remap_domain_mfn_range_in_kernel). 

> 
> > - how is BFN or unused address (what do you mean by address here?)
> > allocated? does it need present in guest physical memory at boot time,
> > or just finding some holes?
> 
> Fitting this into holes should be fine.

this is an interesting open to be further discussed. Here we need consider 
the extreme case, i.e. a 64bit GPU page table can legitimately use up all 
the system memory allocates to that VM, and considering dozens of VMs, 
it means we need reserve a very large hole. 

I once remember some similar cases requiring grabbing some unmapped
pfns (in grant table?). So wonder whether there's already a clean interface
for such purpose, or we need tweak a new one to allocate unmapped pfns
(but won't conflict with usages like memory hotplug)...

appreciate any suggestion here.

> 
> > - graphics memory size could be large. starting from BDW, there'll
> > be 64bit page table format. Do you see any limitation here on finding
> > BFN or address?
> 
> I don't think this concern differs much for the different models: As long
> as you don't want the same underlying memory to be accessible by
> more than one guest, the address space requirements ought to be the
> same.

See above.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 06:40:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 06: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 1Y0PJw-0006Dr-Tu; Mon, 15 Dec 2014 06:39: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 1Y0PJv-0006Dm-Kv
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 06:39:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	10/1B-25276-7328E845; Mon, 15 Dec 2014 06:39:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418625588!15590876!1
X-Originating-IP: [66.165.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 25547 invoked from network); 15 Dec 2014 06:39: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;
	15 Dec 2014 06:39:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="scan'208";a="204306971"
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.210.2; Mon, 15 Dec 2014 01:39: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 1Y0PJr-0007Yn-9b;
	Mon, 15 Dec 2014 06:39:47 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0PJr-0001hi-2E;
	Mon, 15 Dec 2014 06:39:47 +0000
Date: Mon, 15 Dec 2014 06:39:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32359-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] 32359: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32359 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32359/

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-sedf      9 guest-start                 fail pass in 32315
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot               fail pass in 32332
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 32315 pass in 32359
 test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken in 32315 pass in 32359
 test-amd64-amd64-xl-win7-amd64 13 guest-localmigrate/x10 fail in 32315 pass in 32359
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 32315 pass in 32359
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 32332 pass in 32359
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 32332 pass in 32359
 test-amd64-i386-xl-multivcpu  3 host-install(3)  broken in 32332 pass in 32359
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 32332 pass in 32359
 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 32332 pass in 32359
 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 32332 pass in 32359
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 32332 pass in 32359

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-xl-qemut-debianhvm-amd64 3 host-install(3) broken in 32315 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-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-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-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-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-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 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop       fail in 32315 never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                                     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 34178 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 Dec 15 06:40:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 06: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 1Y0PJw-0006Dr-Tu; Mon, 15 Dec 2014 06:39: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 1Y0PJv-0006Dm-Kv
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 06:39:51 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	10/1B-25276-7328E845; Mon, 15 Dec 2014 06:39:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418625588!15590876!1
X-Originating-IP: [66.165.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 25547 invoked from network); 15 Dec 2014 06:39: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;
	15 Dec 2014 06:39:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="scan'208";a="204306971"
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.210.2; Mon, 15 Dec 2014 01:39: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 1Y0PJr-0007Yn-9b;
	Mon, 15 Dec 2014 06:39:47 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0PJr-0001hi-2E;
	Mon, 15 Dec 2014 06:39:47 +0000
Date: Mon, 15 Dec 2014 06:39:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32359-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] 32359: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32359 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32359/

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-sedf      9 guest-start                 fail pass in 32315
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot               fail pass in 32332
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 32315 pass in 32359
 test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken in 32315 pass in 32359
 test-amd64-amd64-xl-win7-amd64 13 guest-localmigrate/x10 fail in 32315 pass in 32359
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 32315 pass in 32359
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 32332 pass in 32359
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 32332 pass in 32359
 test-amd64-i386-xl-multivcpu  3 host-install(3)  broken in 32332 pass in 32359
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 32332 pass in 32359
 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 32332 pass in 32359
 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 32332 pass in 32359
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 32332 pass in 32359

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-xl-qemut-debianhvm-amd64 3 host-install(3) broken in 32315 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-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-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-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-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-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 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop       fail in 32315 never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                                     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 34178 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 Dec 15 07:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 07: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 1Y0QXQ-0007kZ-W5; Mon, 15 Dec 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 <ba1020@homie.homelinux.net>) id 1XzivX-0006j8-Rj
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 09:23:51 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	1E/BF-31453-7A50C845; Sat, 13 Dec 2014 09:23:51 +0000
X-Env-Sender: ba1020@homie.homelinux.net
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418462630!13128346!1
X-Originating-IP: [87.81.139.118]
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 20076 invoked from network); 13 Dec 2014 09:23:50 -0000
Received: from 57518b76.skybroadband.com (HELO zimbra.homelinux.net)
	(87.81.139.118)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Dec 2014 09:23:50 -0000
Received: from localhost (ip6-localhost [IPv6:::1])
	by zimbra.homelinux.net (Postfix) with ESMTP id DE81320006D
	for <xen-devel@lists.xen.org>; Sat, 13 Dec 2014 09:23:49 +0000 (GMT)
Received: from zimbra.homelinux.net ([IPv6:::1])
	by localhost (zimbra.homelinux.net [IPv6:::1]) (amavisd-new, port 10032)
	with ESMTP id nxhPY4ykT8Jz for <xen-devel@lists.xen.org>;
	Sat, 13 Dec 2014 09:23:49 +0000 (GMT)
Received: from localhost (ip6-localhost [IPv6:::1])
	by zimbra.homelinux.net (Postfix) with ESMTP id 64CB5201130
	for <xen-devel@lists.xen.org>; Sat, 13 Dec 2014 09:23:49 +0000 (GMT)
X-Virus-Scanned: amavisd-new at zimbra.homelinux.net
Received: from zimbra.homelinux.net ([IPv6:::1])
	by localhost (zimbra.homelinux.net [IPv6:::1]) (amavisd-new, port 10026)
	with ESMTP id RLkuvUjoG3LJ for <xen-devel@lists.xen.org>;
	Sat, 13 Dec 2014 09:23:49 +0000 (GMT)
Received: from zimbra.homelinux.net (localhost [127.0.0.1])
	by zimbra.homelinux.net (Postfix) with ESMTP id 0F92B20006D
	for <xen-devel@lists.xen.org>; Sat, 13 Dec 2014 09:23:49 +0000 (GMT)
Date: Sat, 13 Dec 2014 09:23:48 +0000 (GMT)
From: Juergen Schinker <ba1020@homie.homelinux.net>
To: xen-devel@lists.xen.org
Message-ID: <1022891597.144.1418462628949.JavaMail.zimbra@homie.homelinux.net>
MIME-Version: 1.0
X-Originating-IP: [2001:470:6984:1:216:3eff:fe68:9940]
X-Mailer: Zimbra 8.5.1_GA_3056 (ZimbraWebClient - FF31 (Linux)/8.5.1_GA_3056)
Thread-Topic: Test report Xen 4.5.0-RC3
Thread-Index: Ybm14016h//wK7R75ZLRCGLOD5II8g==
X-Mailman-Approved-At: Mon, 15 Dec 2014 07:57:51 +0000
Subject: [Xen-devel] [TESTDAY] Test report  Xen 4.5.0-RC3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Subject: [TESTDAY] Test report Xen 4.5.0-RC3
 
* Hardware:
 Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz (4cores -1 socket)
 32G Ram

* Software:
  Debian Jessie

* Guest operating systems:
  Debian Jessie
* Functionality tested:
  xl
  pygrub

* Comments:

had to compile with
configure --enable-githttp --enable-systemd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 07:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 07: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 1Y0QXQ-0007kS-KZ; Mon, 15 Dec 2014 07:57:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jshen25@hawk.iit.edu>) id 1Xzi2J-0005a5-Vw
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 08:26:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	98/1B-15461-748FB845; Sat, 13 Dec 2014 08:26:47 +0000
X-Env-Sender: jshen25@hawk.iit.edu
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418459204!15349397!1
X-Originating-IP: [209.85.220.41]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25840 invoked from network); 13 Dec 2014 08:26:45 -0000
Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com)
	(209.85.220.41)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 08:26:45 -0000
Received: by mail-pa0-f41.google.com with SMTP id rd3so8744299pab.0
	for <xen-devel@lists.xen.org>; Sat, 13 Dec 2014 00:26: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:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=cmbQyokAqviUpvHV701/iAkdS1QOXl0efco77itKWFc=;
	b=kp0DTce3faHqU9ru8nfJ5azSePQLcJJF7fV4kACn+MnE0TP3odCtTzzTwGajp2BHib
	nqdgyTU7NNni/9Fh4DBWW0SU8GJmqv7E5QqoD2NvOPX7/yiwXZFBAVvzJ83ZePEXCVkv
	/NmMMm/z4+LWTx5vephhu9lWW+r6MlMUvNE7y4MECxPRhVQpdQI/B0z9dsS3hb+2oscj
	H1ji91H6ZWTTHTwUdRfJUXRuTNLIT7WEH+CXWPaGpVdepzztrKMNiR4tH5C6bRlosa6P
	C3rBsN/cHdksorMAjBlmInbNdgXqxXo7/dnCo9PPOGIjQHC6V1MvxCJF5v8gmJOOLviC
	sv4w==
X-Gm-Message-State: ALoCoQkrW6V4m3Ge0ymDiBrPzmFnAmj2YGL0Ha8Ytf+HoQCbHV0F78pQN1WqR+Vi+iX9xaohSqEs
MIME-Version: 1.0
X-Received: by 10.70.88.164 with SMTP id bh4mr33495789pdb.96.1418459204268;
	Sat, 13 Dec 2014 00:26:44 -0800 (PST)
Received: by 10.70.43.74 with HTTP; Sat, 13 Dec 2014 00:26:44 -0800 (PST)
Date: Sat, 13 Dec 2014 02:26:44 -0600
Message-ID: <CADUQMei4ssFXs-fq83QrcpSu5pw8Xq_dtmY0=NwLywy4MNd8ng@mail.gmail.com>
From: Jie Shen <jshen25@hawk.iit.edu>
To: "rtxen-devel@googlegroups.com" <rtxen-devel@googlegroups.com>,
	xen-devel@lists.xen.org, 
	mengxu@seas.upenn.edu, Xiayu Hua <xiayuhuahxy@gmail.com>
X-Mailman-Approved-At: Mon, 15 Dec 2014 07:57:51 +0000
Subject: [Xen-devel] XEN::SCHEDULER::libxl.c::make install error
 ::libxenlight.so: undefined reference to `xc_sched_rm_domain_set'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3474216860565391377=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3474216860565391377==
Content-Type: multipart/alternative; boundary=001a11c321ceffd2f8050a14c483

--001a11c321ceffd2f8050a14c483
Content-Type: text/plain; charset=UTF-8

Hello Gurus,
I am adding a new rm scheduler to the rt-xen,
unfortunately I met "undefined reference to " error ,the output is below:

================error output begin==============


ln -sf libxenlight.so.4.3.0 libxenlight.so.4.3
ln -sf libxenlight.so.4.3 libxenlight.so
gcc    -pthread -o xl xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o libxlutil.so
/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so
-Wl,-rpath-link=/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxc
-Wl,-rpath-link=/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/xenstore
-Wl,-rpath-link=/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/blktap2/control
/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxc/libxenctrl.so
-lyajl
/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so:
undefined reference to `xc_sched_rm_domain_get'
/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so:
undefined reference to `xc_sched_rm_domain_set'
collect2: error: ld returned 1 exit status
make[3]: *** [xl] Error 1
make[3]: Leaving directory
`/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl'
make[2]: *** [subdir-install-libxl] Error 2
make[2]: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools'
make: *** [install-tools] Error 2

=============== error output end ===================


I searched all the folder ,it should be defined in the file :(reference
rtpartion)


==================== grep for rm===============
jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ grep -r
 xc_sched_rm_domain_set
dist/install/usr/local/include/xenctrl.h~:int
xc_sched_rm_domain_set(xc_interface *xch,
dist/install/usr/local/include/xenctrl.h:int
xc_sched_rm_domain_set(xc_interface *xch,
tools/libxc/xc_rm.c:xc_sched_rm_domain_set(
tools/libxc/xenctrl.h:int xc_sched_rm_domain_set(xc_interface *xch,
tools/libxl/libxl.c:    rc = xc_sched_rm_domain_set(CTX->xch, domid, &sdom);
Binary file tools/libxl/libxenlight.so.4.3.0 matches
Binary file tools/libxl/libxl.o matches
tools/python/xen/lowlevel/xc/xc.c:static PyObject
*pyxc_sched_rm_domain_set(XcObject *self,
tools/python/xen/lowlevel/xc/xc.c:    if (
xc_sched_rm_domain_set(self->xc_handle, domid, &sdom) != 0 )
tools/python/xen/lowlevel/xc/xc.c:
 (PyCFunction)pyxc_sched_rm_domain_set,

====================grep for rtpartion ============
jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ grep -r
 xc_sched_rtpartition_domain_set
dist/install/usr/local/include/xenctrl.h~:int
xc_sched_rtpartition_domain_set(xc_interface *xch,
dist/install/usr/local/include/xenctl.hbak:int
xc_sched_rtpartition_domain_set(xc_interface *xch,     ===>bakfile can be
ignored
dist/install/usr/local/include/xenctrl.h:int
xc_sched_rtpartition_domain_set(xc_interface *xch,
Binary file dist/install/usr/local/lib/libxenlight.so.4.3.0 matches
Binary file dist/install/usr/local/lib/libxenlight.a matches
Binary file dist/install/usr/local/lib/libxenctrl.so.4.3.0 matches
Binary file dist/install/usr/local/lib/libxenctrl.a matches
Binary file
dist/install/usr/local/lib/python2.7/dist-packages/xen/lowlevel/xc.so
matches
Binary file tools/libxc/libxenctrl.so.4.3.0 matches
Binary file tools/libxc/libxenctrl.a matches
Binary file tools/libxc/xc_rtpartition.o matches
tools/libxc/xc_rtpartition.c:xc_sched_rtpartition_domain_set(
Binary file tools/libxc/xc_rtpartition.opic matches
tools/libxc/xenctrl.h:int xc_sched_rtpartition_domain_set(xc_interface *xch,
tools/libxl/libxl.c:    rc = xc_sched_rtpartition_domain_set(CTX->xch,
domid, &sdom);
Binary file tools/libxl/libxenlight.so.4.3.0 matches
tools/libxl/libxl.cbak:    rc = xc_sched_rtpartition_domain_set(CTX->xch,
domid, &sdom);
Binary file tools/libxl/libxl.o matches
tools/libxl/libxl.cbak.20141211:    rc =
xc_sched_rtpartition_domain_set(CTX->xch, domid, &sdom);
tools/python/xen/lowlevel/xc/xc.c:static PyObject
*pyxc_sched_rtpartition_domain_set(XcObject *self,
tools/python/xen/lowlevel/xc/xc.c:    if (
xc_sched_rtpartition_domain_set(self->xc_handle, domid, &sdom) != 0 )
tools/python/xen/lowlevel/xc/xc.c:
 (PyCFunction)pyxc_sched_rtpartition_domain_set,
tools/python/xen/lowlevel/xc/xc.cbak:static PyObject
*pyxc_sched_rtpartition_domain_set(XcObject *self,
===>bakfile
tools/python/xen/lowlevel/xc/xc.cbak:    if (
xc_sched_rtpartition_domain_set(self->xc_handle, domid, &sdom) != 0 )
tools/python/xen/lowlevel/xc/xc.cbak:
 (PyCFunction)pyxc_sched_rtpartition_domain_set,
jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$



Could you please advice me where I need to define it?
Thank you very much!


 Best regards
Jie Shen


Graduate Student in Computer Science
Illinois Institute of Technology
Stuart Building  Chicago, IL 60616
+1  312 404 0122

--001a11c321ceffd2f8050a14c483
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>Hello Gurus,</div><div>I am adding a n=
ew rm scheduler to the rt-xen,</div><div>unfortunately I met &quot;undefine=
d reference to &quot; error ,the output is below:</div><div><br></div><div>=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Derror output begin=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><br></div><div><br></div><div>l=
n -sf libxenlight.so.4.3.0 libxenlight.so.4.3</div><div>ln -sf libxenlight.=
so.4.3 libxenlight.so</div><div>gcc =C2=A0 =C2=A0-pthread -o xl xl.o xl_cmd=
impl.o xl_cmdtable.o xl_sxp.o libxlutil.so /home/jackyshen/RT-XEN/RT-Xen-rt=
-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so -Wl,-rpath-link=3D/ho=
me/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxc -Wl,-rp=
ath-link=3D/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools=
/xenstore -Wl,-rpath-link=3D/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/=
libxl/../../tools/blktap2/control /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/=
tools/libxl/../../tools/libxc/libxenctrl.so -lyajl=C2=A0</div><div>/home/ja=
ckyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.=
so: undefined reference to `xc_sched_rm_domain_get&#39;</div><div>/home/jac=
kyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.s=
o: undefined reference to `xc_sched_rm_domain_set&#39;</div><div>collect2: =
error: ld returned 1 exit status</div><div>make[3]: *** [xl] Error 1</div><=
div>make[3]: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/to=
ols/libxl&#39;</div><div>make[2]: *** [subdir-install-libxl] Error 2</div><=
div>make[2]: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/to=
ols&#39;</div><div>make[1]: *** [subdirs-install] Error 2</div><div>make[1]=
: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools&#39;</d=
iv><div>make: *** [install-tools] Error 2</div><div><br></div><div><div cla=
ss=3D"gmail_signature"><div dir=3D"ltr"><div><div>=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D error output end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D<br><br><br>I searched all the folder ,it should be de=
fined in the file :(reference rtpartion)</div><div><br></div><div><br></div=
><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D grep for=
 rm=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><div>jackyshen@j=
ackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ grep -r =C2=A0xc_sched_r=
m_domain_set</div><div>dist/install/usr/local/include/xenctrl.h~:int xc_sch=
ed_rm_domain_set(xc_interface *xch,</div><div>dist/install/usr/local/includ=
e/xenctrl.h:int xc_sched_rm_domain_set(xc_interface *xch,</div><div>tools/l=
ibxc/xc_rm.c:xc_sched_rm_domain_set(</div><div>tools/libxc/xenctrl.h:int xc=
_sched_rm_domain_set(xc_interface *xch,</div><div>tools/libxl/libxl.c: =C2=
=A0 =C2=A0rc =3D xc_sched_rm_domain_set(CTX-&gt;xch, domid, &amp;sdom);</di=
v><div>Binary file tools/libxl/libxenlight.so.4.3.0 matches</div><div>Binar=
y file tools/libxl/libxl.o matches</div><div>tools/python/xen/lowlevel/xc/x=
c.c:static PyObject *pyxc_sched_rm_domain_set(XcObject *self,</div><div>too=
ls/python/xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_set(se=
lf-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</div><div>tools/python/xen/low=
level/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_set,</=
div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3Dgrep for rtpartion =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div>=
jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ grep -r =C2=
=A0xc_sched_rtpartition_domain_set</div><div>dist/install/usr/local/include=
/xenctrl.h~:int xc_sched_rtpartition_domain_set(xc_interface *xch,</div><di=
v>dist/install/usr/local/include/xenctl.hbak:int xc_sched_rtpartition_domai=
n_set(xc_interface *xch, =C2=A0 =C2=A0 =3D=3D=3D&gt;bakfile can be ignored<=
/div><div>dist/install/usr/local/include/xenctrl.h:int xc_sched_rtpartition=
_domain_set(xc_interface *xch,</div><div>Binary file dist/install/usr/local=
/lib/libxenlight.so.4.3.0 matches</div><div>Binary file dist/install/usr/lo=
cal/lib/libxenlight.a matches</div><div>Binary file dist/install/usr/local/=
lib/libxenctrl.so.4.3.0 matches</div><div>Binary file dist/install/usr/loca=
l/lib/libxenctrl.a matches</div><div>Binary file dist/install/usr/local/lib=
/python2.7/dist-packages/xen/lowlevel/xc.so matches</div><div>Binary file t=
ools/libxc/libxenctrl.so.4.3.0 matches</div><div>Binary file tools/libxc/li=
bxenctrl.a matches</div><div>Binary file tools/libxc/xc_rtpartition.o match=
es</div><div>tools/libxc/xc_rtpartition.c:xc_sched_rtpartition_domain_set(<=
/div><div>Binary file tools/libxc/xc_rtpartition.opic matches</div><div>too=
ls/libxc/xenctrl.h:int xc_sched_rtpartition_domain_set(xc_interface *xch,</=
div><div>tools/libxl/libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rtpartition_doma=
in_set(CTX-&gt;xch, domid, &amp;sdom);</div><div>Binary file tools/libxl/li=
bxenlight.so.4.3.0 matches</div><div>tools/libxl/libxl.cbak: =C2=A0 =C2=A0r=
c =3D xc_sched_rtpartition_domain_set(CTX-&gt;xch, domid, &amp;sdom);</div>=
<div>Binary file tools/libxl/libxl.o matches</div><div>tools/libxl/libxl.cb=
ak.20141211: =C2=A0 =C2=A0rc =3D xc_sched_rtpartition_domain_set(CTX-&gt;xc=
h, domid, &amp;sdom);</div><div>tools/python/xen/lowlevel/xc/xc.c:static Py=
Object *pyxc_sched_rtpartition_domain_set(XcObject *self,</div><div>tools/p=
ython/xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rtpartition_domain_s=
et(self-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</div><div>tools/python/xe=
n/lowlevel/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rtpartition=
_domain_set,</div><div>tools/python/xen/lowlevel/xc/xc.cbak:static PyObject=
 *pyxc_sched_rtpartition_domain_set(XcObject *self, =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=3D=3D&gt;bakfil=
e</div><div>tools/python/xen/lowlevel/xc/xc.cbak: =C2=A0 =C2=A0if ( xc_sche=
d_rtpartition_domain_set(self-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</di=
v><div>tools/python/xen/lowlevel/xc/xc.cbak: =C2=A0 =C2=A0 =C2=A0(PyCFuncti=
on)pyxc_sched_rtpartition_domain_set,</div><div>jackyshen@jackyshen-ThinkPa=
d-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$=C2=A0</div><div><br></div><div><br></div=
><div><br></div>Could you please advice me where I need to define it?</div>=
<div>Thank you very much!<br><br><br>=C2=A0Best regards<br>Jie Shen <br><br=
><br></div>Graduate Student in Computer Science<br></div>Illinois Institute=
 of Technology=C2=A0=C2=A0=C2=A0 <br>Stuart Building=C2=A0 Chicago, IL 6061=
6<br>+1=C2=A0 312 404 0122<br><div><br></div></div></div></div>
</div>

--001a11c321ceffd2f8050a14c483--


--===============3474216860565391377==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3474216860565391377==--


From xen-devel-bounces@lists.xen.org Mon Dec 15 07:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 07: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 1Y0QXR-0007kn-Ml; Mon, 15 Dec 2014 07:57:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jshen25@hawk.iit.edu>) id 1Y0QGC-0007RL-P0
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 07:40:05 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	FC/67-28296-3509E845; Mon, 15 Dec 2014 07:40:03 +0000
X-Env-Sender: jshen25@hawk.iit.edu
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418629200!13356777!1
X-Originating-IP: [209.85.192.169]
X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24518 invoked from network); 15 Dec 2014 07:40:02 -0000
Received: from mail-pd0-f169.google.com (HELO mail-pd0-f169.google.com)
	(209.85.192.169)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 07:40:02 -0000
Received: by mail-pd0-f169.google.com with SMTP id z10so11179797pdj.14
	for <xen-devel@lists.xen.org>; Sun, 14 Dec 2014 23:40: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=IQKoESmzXtB9lyAqW/45WhagYcc7nkeWuOrHCQKD8uU=;
	b=VqvBu5R2TUXNUOykIPTnvcR8PbozsxTT2F48p/8UnGBz9ohppCMTb+rR2dqLPH7TtN
	S8ccVfahd6H6Zp6yiiwdjc9iJ2O4nSlyFCY6NCRZUOY/JVF8pi6m2m+nazxVe3d0nQsC
	qU8rrC7p2yxNMxtbIjH0i4jEC+khER5wNtg4bzeFOm1jIH8idU6f9HvcgvEQ/WX896PT
	KJx5mS3AJZhQfK9lDzlu76vchxe9qMiaXacWoNX13QUVMVS0TwjKoS37xFh4ykjqLC2W
	7BmqMfyRMpI8WeMqAHJqPiXs4kPRHrj3R/JDwOyslRSjbOX2Pu9BsfopfLL1OlVnHztH
	VIpg==
X-Gm-Message-State: ALoCoQnxN7H0jBI51M77F68Sdk4fIC+T1XX1xy8ygJBdoGZjArYDadTUMJ7gYVdQj9X4fzr93a1j
MIME-Version: 1.0
X-Received: by 10.68.232.104 with SMTP id tn8mr48724243pbc.31.1418629200249;
	Sun, 14 Dec 2014 23:40:00 -0800 (PST)
Received: by 10.70.43.74 with HTTP; Sun, 14 Dec 2014 23:40:00 -0800 (PST)
In-Reply-To: <CADUQMehGUdNXjsvLAKXXwRDDfJMLdbQw6xHk2rMYAFzyUTtaGQ@mail.gmail.com>
References: <CADUQMegeBg2dVXptjo7w+dU5CkTs5gUrM=6HbCuj3NftD05oDA@mail.gmail.com>
	<CADUQMehGUdNXjsvLAKXXwRDDfJMLdbQw6xHk2rMYAFzyUTtaGQ@mail.gmail.com>
Date: Mon, 15 Dec 2014 01:40:00 -0600
Message-ID: <CADUQMejvxaQkBr=FzoyN8yG12CTmpDKzuF4bX+0pYr9hK9_RUg@mail.gmail.com>
From: Jie Shen <jshen25@hawk.iit.edu>
To: xen-devel@lists.xen.org, 
	"rtxen-devel@googlegroups.com" <rtxen-devel@googlegroups.com>,
	Xiayu Hua <xiayuhuahxy@gmail.com>
X-Mailman-Approved-At: Mon, 15 Dec 2014 07:57:51 +0000
Subject: Re: [Xen-devel] rt-xen::make Done::xl :: sched-rm not shown:: how
 to add a command line in xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2109020785592066319=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2109020785592066319==
Content-Type: multipart/alternative; boundary=047d7b33d6088ca744050a3c59bc

--047d7b33d6088ca744050a3c59bc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Gurus,
should be the two files :

xl_cmdimpl.c
xl_cmdtable.c?









 Best regards
Jie Shen


Graduate Student in Computer Science
Illinois Institute of Technology
Stuart Building  Chicago, IL 60616
+1  312 404 0122


On Mon, Dec 15, 2014 at 12:56 AM, Jie Shen <jshen25@hawk.iit.edu> wrote:
>
>
> Hello Gurus ,
> Sorry to bother your again.
>
> Now Make is Done.
>
> Many errors are resolved ( such as some programming errors on xenbus.c
> ,fbfront.c)
>
>
> now I can use xl ,unfortunately, xl no option sched-rm.
>
> I changed the source of :
>
> libxl.c   =3D=3D>  output from grep:
>
> libxl.c:static int sched_rm_domain_get(libxl__gc *gc, uint32_t domid,
> libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
> libxl.c:static int sched_rm_domain_set(libxl__gc *gc, uint32_t domid,
> libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
> libxl.c:    rc =3D xc_sched_rm_domain_set(CTX->xch, domid, &sdom);
> libxl.c:        ret=3Dsched_rm_domain_set(gc, domid, scinfo);
> libxl.c: ret=3Dsched_rm_domain_get(gc,domid,scinfo);
>
>
> and :
> xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_set(XcObject
> *self,
> xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
> xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_set(self->xc_handle,
> domid, &sdom) !=3D 0 )
> xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_get(XcObject
> *self, PyObject *args)
> xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
> xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_get(self->xc_handle,
> domid, &sdom) !=3D 0 )
> xen/lowlevel/xc/xc.c:   { "sched_rm_domain_set",
> xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_set,
> xen/lowlevel/xc/xc.c:     { "sched_rm_domain_get",
> xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_get,
>
>
> also created :
> libxc/xc_rm.c  =3D=3D=3D> just like libxc/xc_rtpartition.c
>
>
>
> not changing main.py:
>
> since I see it is commtented::
>
>
> main.py:    'sched-rtpartition': ('[-d <Domain>
> [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=3DEXTRA]]',
> main.py:                     'Get/set rtpartition scheduler parameters.')=
,
> main.py:    'sched-rtpartition': (
> main.py:    "sched-rtpartition",
> main.py:# # rtpartition
> main.py:# def xm_sched_rtpartition(args):
> main.py:#     """Get/Set options for rtpartition Scheduler."""
> main.py:#     check_sched_type('rtpartition')
> main.py:#         usage('sched-rtpartition')
> main.py:#             usage('sched-rtpartition')
> main.py:#                     info =3D
> server.xend.domain.sched_rtpartition_get(d['name'])
> main.py:#                 # domain does not support sched-rtpartition?
> main.py:#             usage('sched-rtpartition')
> main.py:#             result =3D
> server.xend.domain.sched_rtpartition_set(domid, period, budget, vcpu, ext=
ra)
> main.py:    # "sched-rtpartition": xm_sched_rtpartition,
> grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=95
>
>
>
>
>
> my question is how to make xl can changed "sched-rm"  parameters?
>
>
>
>
> jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl
> Usage xl [-vfN] <subcommand> [args]
>
> xl full list of subcommands:
>
>  create              Create a domain from config file <filename>
>  config-update       Update a running domain's saved configuration, used
> when rebuilding the domain after reboot
>  list                List information about all/some domains
>  destroy             Terminate a domain immediately
>  shutdown            Issue a shutdown signal to a domain
>  reboot              Issue a reboot signal to a domain
>  pci-attach          Insert a new pass-through pci device
>  pci-detach          Remove a domain's pass-through pci device
>  pci-list            List pass-through pci devices for a domain
>  pci-assignable-add  Make a device assignable for pci-passthru
>  pci-assignable-remove
>                      Remove a device from being assignable
>  pci-assignable-list List all the assignable pci devices
>  pause               Pause execution of a domain
>  unpause             Unpause a paused domain
>  console             Attach to domain's console
>  vncviewer           Attach to domain's VNC server.
>  save                Save a domain state to restore later
>  migrate             Migrate a domain to another host
>  dump-core           Core dump a domain
>  restore             Restore a domain from a saved state
>  migrate-receive     Restore a domain from a saved state
>  cd-insert           Insert a cdrom into a guest's cd drive
>  cd-eject            Eject a cdrom from a guest's cd drive
>  mem-max             Set the maximum amount reservation for a domain
>  mem-set             Set the current memory usage for a domain
>  button-press        Indicate an ACPI button press to the domain
>  vcpu-list           List the VCPUs for all/some domains
>  vcpu-pin            Set which CPUs a VCPU can use
>  vcpu-set            Set the number of active VCPUs allowed for the domai=
n
>  vm-list             List guest domains, excluding dom0, stubdoms, etc.
>  info                Get information about Xen host
>  sharing             Get information about page sharing
>  sched-credit        Get/set credit scheduler parameters
>  sched-credit2       Get/set credit2 scheduler parameters
>  sched-rtglobal      Get/set rtglobal scheduler parameters
>  sched-rtpartition   Get/set rtpartition scheduler parameters
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<><><>  >>> here should be "sched-rm"=
  but not show.  >>>> it
> the my question.
>
>
>
>
>
>
>
>
>  Best regards
> Jie Shen
>
>
> Graduate Student in Computer Science
> Illinois Institute of Technology
> Stuart Building  Chicago, IL 60616
> +1  312 404 0122
>
>

--047d7b33d6088ca744050a3c59bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello Gurus,<div>should be the two files :</div><div><br><=
/div><div>xl_cmdimpl.c</div><div>xl_cmdtable.c?</div><div><br></div><div><b=
r></div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div><div><br><br><br><br><br><br>=C2=
=A0Best regards<br>Jie Shen <br><br><br></div>Graduate Student in Computer =
Science<br></div>Illinois Institute of Technology=C2=A0=C2=A0=C2=A0 <br>Stu=
art Building=C2=A0 Chicago, IL 60616<br>+1=C2=A0 312 404 0122<br><div><br><=
/div></div></div></div>
<br><div class=3D"gmail_quote">On Mon, Dec 15, 2014 at 12:56 AM, Jie Shen <=
span dir=3D"ltr">&lt;<a href=3D"mailto:jshen25@hawk.iit.edu" target=3D"_bla=
nk">jshen25@hawk.iit.edu</a>&gt;</span> wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_quote"><br><div dir=3D"ltr"><div>Hel=
lo Gurus ,</div><div><div class=3D"h5"><div>Sorry to bother your again.<br>=
</div><div><br></div><div>Now Make is Done.</div><div><br></div><div>Many e=
rrors are resolved ( such as some programming errors on xenbus.c ,fbfront.c=
)</div><div><br></div><div><br></div><div>now I can use xl ,unfortunately, =
xl no option sched-rm.</div><div><br></div><div>I changed the source of :</=
div><div><br></div><div>libxl.c =C2=A0 =3D=3D&gt; =C2=A0output from grep:</=
div><div><br></div><div><div>libxl.c:static int sched_rm_domain_get(libxl__=
gc *gc, uint32_t domid,</div><div>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_=
domain_get(CTX-&gt;xch, domid, &amp;sdom);</div><div>libxl.c:static int sch=
ed_rm_domain_set(libxl__gc *gc, uint32_t domid,</div><div>libxl.c: =C2=A0 =
=C2=A0rc =3D xc_sched_rm_domain_get(CTX-&gt;xch, domid, &amp;sdom);</div><d=
iv>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_domain_set(CTX-&gt;xch, domid, =
&amp;sdom);</div><div>libxl.c: =C2=A0 =C2=A0 =C2=A0 =C2=A0ret=3Dsched_rm_do=
main_set(gc, domid, scinfo);</div><div>libxl.c:<span style=3D"white-space:p=
re-wrap">		</span>ret=3Dsched_rm_domain_get(gc,domid,scinfo);</div></div><d=
iv><br></div><div><br></div><div>and :</div><div><div>xen/lowlevel/xc/xc.c:=
static PyObject *pyxc_sched_rm_domain_set(XcObject *self,</div><div>xen/low=
level/xc/xc.c: =C2=A0 =C2=A0struct xen_domctl_sched_rm sdom;</div><div>xen/=
lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_set(self-&gt;xc_hand=
le, domid, &amp;sdom) !=3D 0 )</div><div>xen/lowlevel/xc/xc.c:static PyObje=
ct *pyxc_sched_rm_domain_get(XcObject *self, PyObject *args)</div><div>xen/=
lowlevel/xc/xc.c: =C2=A0 =C2=A0struct xen_domctl_sched_rm sdom;</div><div>x=
en/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_get(self-&gt;xc_h=
andle, domid, &amp;sdom) !=3D 0 )</div><div>xen/lowlevel/xc/xc.c: =C2=A0 { =
&quot;sched_rm_domain_set&quot;,</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=
=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_set,</div><div>xen/lowlevel/xc/=
xc.c: =C2=A0 =C2=A0 { &quot;sched_rm_domain_get&quot;,</div><div>xen/lowlev=
el/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_get,</div=
></div><div><br></div><div><br></div><div>also created :</div><div>libxc/xc=
_rm.c =C2=A0=3D=3D=3D&gt; just like=C2=A0libxc/xc_rtpartition.c<br></div><d=
iv><br></div><div><br></div><div><br></div><div>not changing main.py:</div>=
<div><br></div><div>since I see it is commtented::</div><div><br></div><div=
><br></div><div><div>main.py: =C2=A0 =C2=A0&#39;sched-rtpartition&#39;: (&#=
39;[-d &lt;Domain&gt; [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=3DEXTRA]=
]&#39;,</div><div>main.py: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 &#39;Get/set rtpartition scheduler parameters.&#39;),=
</div><div>main.py: =C2=A0 =C2=A0&#39;sched-rtpartition&#39;: (</div><div>m=
ain.py: =C2=A0 =C2=A0&quot;sched-rtpartition&quot;,</div><div>main.py:# # r=
tpartition</div><div>main.py:# def xm_sched_rtpartition(args):</div><div>ma=
in.py:# =C2=A0 =C2=A0 &quot;&quot;&quot;Get/Set options for rtpartition Sch=
eduler.&quot;&quot;&quot;</div><div>main.py:# =C2=A0 =C2=A0 check_sched_typ=
e(&#39;rtpartition&#39;)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 us=
age(&#39;sched-rtpartition&#39;)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div><div>main.py:#=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 info=
 =3D server.xend.domain.sched_rtpartition_get(d[&#39;name&#39;])</div><div>=
main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # domain =
does not support sched-rtpartition?</div><div>main.py:# =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div><div>main.=
py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 result =3D server.xend.domai=
n.sched_rtpartition_set(domid, period, budget, vcpu, extra)</div><div>main.=
py: =C2=A0 =C2=A0# &quot;sched-rtpartition&quot;: xm_sched_rtpartition,</di=
v><div>grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=95</div></di=
v><div><br></div><div><br></div><div><br></div><div><br></div><div><br></di=
v><div>my question is how to make xl can changed &quot;sched-rm&quot; =C2=
=A0parameters?</div><div><br><br></div><div><br></div><div><br></div><div>j=
ackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl</div><div>U=
sage xl [-vfN] &lt;subcommand&gt; [args]</div><div><br></div><div>xl full l=
ist of subcommands:</div><div><br></div><div>=C2=A0create =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Create a domain from config file &lt;filenam=
e&gt;</div><div>=C2=A0config-update =C2=A0 =C2=A0 =C2=A0 Update a running d=
omain&#39;s saved configuration, used when rebuilding the domain after rebo=
ot</div><div>=C2=A0list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0List information about all/some domains</div><div>=C2=A0destroy =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Terminate a domain immediately</div>=
<div>=C2=A0shutdown =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Issue a shutdo=
wn signal to a domain</div><div>=C2=A0reboot =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Issue a reboot signal to a domain</div><div>=C2=A0pci-a=
ttach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Insert a new pass-through pci devic=
e</div><div>=C2=A0pci-detach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Remove a dom=
ain&#39;s pass-through pci device</div><div>=C2=A0pci-list =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0List pass-through pci devices for a domain</div>=
<div>=C2=A0pci-assignable-add =C2=A0Make a device assignable for pci-passth=
ru</div><div>=C2=A0pci-assignable-remove=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=A0Remove a device =
from being assignable</div><div>=C2=A0pci-assignable-list List all the assi=
gnable pci devices</div><div>=C2=A0pause =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 Pause execution of a domain</div><div>=C2=A0unpause =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unpause a paused domain</div><div>=C2=A0=
console =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Attach to domain&#39;s co=
nsole</div><div>=C2=A0vncviewer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Attach t=
o domain&#39;s VNC server.</div><div>=C2=A0save =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0Save a domain state to restore later</div><div>=
=C2=A0migrate =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Migrate a domain to=
 another host</div><div>=C2=A0dump-core =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
Core dump a domain</div><div>=C2=A0restore =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Restore a domain from a saved state</div><div>=C2=A0migrate-rece=
ive =C2=A0 =C2=A0 Restore a domain from a saved state</div><div>=C2=A0cd-in=
sert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Insert a cdrom into a guest&#39;s c=
d drive</div><div>=C2=A0cd-eject =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E=
ject a cdrom from a guest&#39;s cd drive</div><div>=C2=A0mem-max =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Set the maximum amount reservation for a do=
main</div><div>=C2=A0mem-set =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Set =
the current memory usage for a domain</div><div>=C2=A0button-press =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Indicate an ACPI button press to the domain</div><div>=
=C2=A0vcpu-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 List the VCPUs for all/s=
ome domains</div><div>=C2=A0vcpu-pin =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Set which CPUs a VCPU can use</div><div>=C2=A0vcpu-set =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Set the number of active VCPUs allowed for the doma=
in</div><div>=C2=A0vm-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 List g=
uest domains, excluding dom0, stubdoms, etc.</div><div>=C2=A0info =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get information about Xen h=
ost</div><div>=C2=A0sharing =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Get i=
nformation about page sharing</div><div>=C2=A0sched-credit =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Get/set credit scheduler parameters</div><div>=C2=A0sched-cred=
it2 =C2=A0 =C2=A0 =C2=A0 Get/set credit2 scheduler parameters</div><div>=C2=
=A0sched-rtglobal =C2=A0 =C2=A0 =C2=A0Get/set rtglobal scheduler parameters=
</div><div>=C2=A0sched-rtpartition =C2=A0 Get/set rtpartition scheduler par=
ameters</div></div></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&lt;&gt;&=
lt;&gt;&lt;&gt; =C2=A0&gt;&gt;&gt; here should be &quot;sched-rm&quot; =C2=
=A0but not show. =C2=A0&gt;&gt;&gt;&gt; it the my question.</div><span clas=
s=3D""><div><br></div><div><br></div><div><div><div dir=3D"ltr"><div><div><=
br><br><br><br><br><br>=C2=A0Best regards<br>Jie Shen <br><br><br></div>Gra=
duate Student in Computer Science<br></div>Illinois Institute of Technology=
=C2=A0=C2=A0=C2=A0 <br>Stuart Building=C2=A0 Chicago, IL 60616<br><a href=
=3D"tel:%2B1%C2%A0%20312%20404%200122" value=3D"+13124040122" target=3D"_bl=
ank">+1=C2=A0 312 404 0122</a><br><div><br></div></div></div></div>
</span></div>
</div></div>
</blockquote></div></div>

--047d7b33d6088ca744050a3c59bc--


--===============2109020785592066319==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2109020785592066319==--


From xen-devel-bounces@lists.xen.org Mon Dec 15 07:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 07: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 1Y0QXR-0007kg-B1; Mon, 15 Dec 2014 07:57:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jshen25@hawk.iit.edu>) id 1Y0PaG-0006e1-7N
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 06:56:44 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	91/46-25276-B268E845; Mon, 15 Dec 2014 06:56:43 +0000
X-Env-Sender: jshen25@hawk.iit.edu
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418626600!8265037!1
X-Originating-IP: [209.85.192.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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19537 invoked from network); 15 Dec 2014 06:56:41 -0000
Received: from mail-pd0-f173.google.com (HELO mail-pd0-f173.google.com)
	(209.85.192.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 06:56:41 -0000
Received: by mail-pd0-f173.google.com with SMTP id ft15so11119544pdb.32
	for <xen-devel@lists.xen.org>; Sun, 14 Dec 2014 22:56: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=QlmZEKWcoMjU9imRoiK8iQntsMtShW2IHMNnd8S3FI4=;
	b=Abbi+08OMqL2JOhFszgoRwKbgAeT1sRyVGHMbS76kweJ8bWcWFY2RPzJqadJLgUitA
	fCtDZGfceFpdZCDB+K3VG+nptH4bhIc0fFH/kRM+wJTfEsJniCF43m/LBdc3TAPBRpN+
	P+qSntzBEUjG7C2WPiU25vpJ1esm3KJfn06zWrOXGv+5RzYhyZ7atXe5hafd9dVsbh1l
	bw6SLMGFhOC9c0BqmU3hO4pQlbrbRkuAYO0PPw7bJDi8HihKq1FiXXWuWJmRIGdkhtg8
	TImKW2Jd/KPpPvgmVIzMg/A+Y7GgoN7nRzacyoQFddWl8ow69TJxAp70j9XV/HY4i7kr
	jx+Q==
X-Gm-Message-State: ALoCoQm0r+Kuql2PhMvoV1kfobAmvE98PmH5yJmxAAVdp9BZkb7Uz98R5gThvACqoTfxVtcsnqfj
MIME-Version: 1.0
X-Received: by 10.68.217.231 with SMTP id pb7mr49073239pbc.124.1418626600397; 
	Sun, 14 Dec 2014 22:56:40 -0800 (PST)
Received: by 10.70.43.74 with HTTP; Sun, 14 Dec 2014 22:56:40 -0800 (PST)
In-Reply-To: <CADUQMegeBg2dVXptjo7w+dU5CkTs5gUrM=6HbCuj3NftD05oDA@mail.gmail.com>
References: <CADUQMegeBg2dVXptjo7w+dU5CkTs5gUrM=6HbCuj3NftD05oDA@mail.gmail.com>
Date: Mon, 15 Dec 2014 00:56:40 -0600
Message-ID: <CADUQMehGUdNXjsvLAKXXwRDDfJMLdbQw6xHk2rMYAFzyUTtaGQ@mail.gmail.com>
From: Jie Shen <jshen25@hawk.iit.edu>
To: xen-devel@lists.xen.org, 
	"rtxen-devel@googlegroups.com" <rtxen-devel@googlegroups.com>,
	Xiayu Hua <xiayuhuahxy@gmail.com>
X-Mailman-Approved-At: Mon, 15 Dec 2014 07:57:51 +0000
Subject: [Xen-devel] Fwd: rt-xen::make Done::xl :: sched-rm not shown:: how
 to add a command line in xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4353886259780485642=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4353886259780485642==
Content-Type: multipart/alternative; boundary=047d7b2ede2f95f1c9050a3bbefe

--047d7b2ede2f95f1c9050a3bbefe
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Gurus ,
Sorry to bother your again.

Now Make is Done.

Many errors are resolved ( such as some programming errors on xenbus.c
,fbfront.c)


now I can use xl ,unfortunately, xl no option sched-rm.

I changed the source of :

libxl.c   =3D=3D>  output from grep:

libxl.c:static int sched_rm_domain_get(libxl__gc *gc, uint32_t domid,
libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
libxl.c:static int sched_rm_domain_set(libxl__gc *gc, uint32_t domid,
libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
libxl.c:    rc =3D xc_sched_rm_domain_set(CTX->xch, domid, &sdom);
libxl.c:        ret=3Dsched_rm_domain_set(gc, domid, scinfo);
libxl.c: ret=3Dsched_rm_domain_get(gc,domid,scinfo);


and :
xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_set(XcObject
*self,
xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_set(self->xc_handle,
domid, &sdom) !=3D 0 )
xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_get(XcObject
*self, PyObject *args)
xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_get(self->xc_handle,
domid, &sdom) !=3D 0 )
xen/lowlevel/xc/xc.c:   { "sched_rm_domain_set",
xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_set,
xen/lowlevel/xc/xc.c:     { "sched_rm_domain_get",
xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_get,


also created :
libxc/xc_rm.c  =3D=3D=3D> just like libxc/xc_rtpartition.c



not changing main.py:

since I see it is commtented::


main.py:    'sched-rtpartition': ('[-d <Domain>
[-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=3DEXTRA]]',
main.py:                     'Get/set rtpartition scheduler parameters.'),
main.py:    'sched-rtpartition': (
main.py:    "sched-rtpartition",
main.py:# # rtpartition
main.py:# def xm_sched_rtpartition(args):
main.py:#     """Get/Set options for rtpartition Scheduler."""
main.py:#     check_sched_type('rtpartition')
main.py:#         usage('sched-rtpartition')
main.py:#             usage('sched-rtpartition')
main.py:#                     info =3D
server.xend.domain.sched_rtpartition_get(d['name'])
main.py:#                 # domain does not support sched-rtpartition?
main.py:#             usage('sched-rtpartition')
main.py:#             result =3D
server.xend.domain.sched_rtpartition_set(domid, period, budget, vcpu, extra=
)
main.py:    # "sched-rtpartition": xm_sched_rtpartition,
grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=95





my question is how to make xl can changed "sched-rm"  parameters?




jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl
Usage xl [-vfN] <subcommand> [args]

xl full list of subcommands:

 create              Create a domain from config file <filename>
 config-update       Update a running domain's saved configuration, used
when rebuilding the domain after reboot
 list                List information about all/some domains
 destroy             Terminate a domain immediately
 shutdown            Issue a shutdown signal to a domain
 reboot              Issue a reboot signal to a domain
 pci-attach          Insert a new pass-through pci device
 pci-detach          Remove a domain's pass-through pci device
 pci-list            List pass-through pci devices for a domain
 pci-assignable-add  Make a device assignable for pci-passthru
 pci-assignable-remove
                     Remove a device from being assignable
 pci-assignable-list List all the assignable pci devices
 pause               Pause execution of a domain
 unpause             Unpause a paused domain
 console             Attach to domain's console
 vncviewer           Attach to domain's VNC server.
 save                Save a domain state to restore later
 migrate             Migrate a domain to another host
 dump-core           Core dump a domain
 restore             Restore a domain from a saved state
 migrate-receive     Restore a domain from a saved state
 cd-insert           Insert a cdrom into a guest's cd drive
 cd-eject            Eject a cdrom from a guest's cd drive
 mem-max             Set the maximum amount reservation for a domain
 mem-set             Set the current memory usage for a domain
 button-press        Indicate an ACPI button press to the domain
 vcpu-list           List the VCPUs for all/some domains
 vcpu-pin            Set which CPUs a VCPU can use
 vcpu-set            Set the number of active VCPUs allowed for the domain
 vm-list             List guest domains, excluding dom0, stubdoms, etc.
 info                Get information about Xen host
 sharing             Get information about page sharing
 sched-credit        Get/set credit scheduler parameters
 sched-credit2       Get/set credit2 scheduler parameters
 sched-rtglobal      Get/set rtglobal scheduler parameters
 sched-rtpartition   Get/set rtpartition scheduler parameters
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<><><>  >>> here should be "sched-rm"  =
but not show.  >>>> it
the my question.








 Best regards
Jie Shen


Graduate Student in Computer Science
Illinois Institute of Technology
Stuart Building  Chicago, IL 60616
+1  312 404 0122

--047d7b2ede2f95f1c9050a3bbefe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><br><div dir=3D"ltr"><div>Hello=
 Gurus ,</div><div>Sorry to bother your again.<br></div><div><br></div><div=
>Now Make is Done.</div><div><br></div><div>Many errors are resolved ( such=
 as some programming errors on xenbus.c ,fbfront.c)</div><div><br></div><di=
v><br></div><div>now I can use xl ,unfortunately, xl no option sched-rm.</d=
iv><div><br></div><div>I changed the source of :</div><div><br></div><div>l=
ibxl.c =C2=A0 =3D=3D&gt; =C2=A0output from grep:</div><div><br></div><div><=
div>libxl.c:static int sched_rm_domain_get(libxl__gc *gc, uint32_t domid,</=
div><div>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_domain_get(CTX-&gt;xch, d=
omid, &amp;sdom);</div><div>libxl.c:static int sched_rm_domain_set(libxl__g=
c *gc, uint32_t domid,</div><div>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_d=
omain_get(CTX-&gt;xch, domid, &amp;sdom);</div><div>libxl.c: =C2=A0 =C2=A0r=
c =3D xc_sched_rm_domain_set(CTX-&gt;xch, domid, &amp;sdom);</div><div>libx=
l.c: =C2=A0 =C2=A0 =C2=A0 =C2=A0ret=3Dsched_rm_domain_set(gc, domid, scinfo=
);</div><div>libxl.c:<span style=3D"white-space:pre-wrap">		</span>ret=3Dsc=
hed_rm_domain_get(gc,domid,scinfo);</div></div><div><br></div><div><br></di=
v><div>and :</div><div><div>xen/lowlevel/xc/xc.c:static PyObject *pyxc_sche=
d_rm_domain_set(XcObject *self,</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=
=A0struct xen_domctl_sched_rm sdom;</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =
=C2=A0if ( xc_sched_rm_domain_set(self-&gt;xc_handle, domid, &amp;sdom) !=
=3D 0 )</div><div>xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domai=
n_get(XcObject *self, PyObject *args)</div><div>xen/lowlevel/xc/xc.c: =C2=
=A0 =C2=A0struct xen_domctl_sched_rm sdom;</div><div>xen/lowlevel/xc/xc.c: =
=C2=A0 =C2=A0if ( xc_sched_rm_domain_get(self-&gt;xc_handle, domid, &amp;sd=
om) !=3D 0 )</div><div>xen/lowlevel/xc/xc.c: =C2=A0 { &quot;sched_rm_domain=
_set&quot;,</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunctio=
n)pyxc_sched_rm_domain_set,</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0 {=
 &quot;sched_rm_domain_get&quot;,</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =
=C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_get,</div></div><div><br></d=
iv><div><br></div><div>also created :</div><div>libxc/xc_rm.c =C2=A0=3D=3D=
=3D&gt; just like=C2=A0libxc/xc_rtpartition.c<br></div><div><br></div><div>=
<br></div><div><br></div><div>not changing main.py:</div><div><br></div><di=
v>since I see it is commtented::</div><div><br></div><div><br></div><div><d=
iv>main.py: =C2=A0 =C2=A0&#39;sched-rtpartition&#39;: (&#39;[-d &lt;Domain&=
gt; [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=3DEXTRA]]&#39;,</div><div>=
main.py: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 &#39;Get/set rtpartition scheduler parameters.&#39;),</div><div>main.py=
: =C2=A0 =C2=A0&#39;sched-rtpartition&#39;: (</div><div>main.py: =C2=A0 =C2=
=A0&quot;sched-rtpartition&quot;,</div><div>main.py:# # rtpartition</div><d=
iv>main.py:# def xm_sched_rtpartition(args):</div><div>main.py:# =C2=A0 =C2=
=A0 &quot;&quot;&quot;Get/Set options for rtpartition Scheduler.&quot;&quot=
;&quot;</div><div>main.py:# =C2=A0 =C2=A0 check_sched_type(&#39;rtpartition=
&#39;)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtp=
artition&#39;)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 usage(&#39;sched-rtpartition&#39;)</div><div>main.py:# =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 info =3D server.xen=
d.domain.sched_rtpartition_get(d[&#39;name&#39;])</div><div>main.py:# =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # domain does not supp=
ort sched-rtpartition?</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div><div>main.py:# =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 result =3D server.xend.domain.sched_rtpa=
rtition_set(domid, period, budget, vcpu, extra)</div><div>main.py: =C2=A0 =
=C2=A0# &quot;sched-rtpartition&quot;: xm_sched_rtpartition,</div><div>grep=
: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=95</div></div><div><br>=
</div><div><br></div><div><br></div><div><br></div><div><br></div><div>my q=
uestion is how to make xl can changed &quot;sched-rm&quot; =C2=A0parameters=
?</div><div><br><br></div><div><br></div><div><br></div><div>jackyshen@jack=
yshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl</div><div>Usage xl [-vfN=
] &lt;subcommand&gt; [args]</div><div><br></div><div>xl full list of subcom=
mands:</div><div><br></div><div>=C2=A0create =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Create a domain from config file &lt;filename&gt;</div>=
<div>=C2=A0config-update =C2=A0 =C2=A0 =C2=A0 Update a running domain&#39;s=
 saved configuration, used when rebuilding the domain after reboot</div><di=
v>=C2=A0list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0List in=
formation about all/some domains</div><div>=C2=A0destroy =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 Terminate a domain immediately</div><div>=C2=A0shu=
tdown =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Issue a shutdown signal to a=
 domain</div><div>=C2=A0reboot =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Issue a reboot signal to a domain</div><div>=C2=A0pci-attach =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Insert a new pass-through pci device</div><div>=
=C2=A0pci-detach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Remove a domain&#39;s pa=
ss-through pci device</div><div>=C2=A0pci-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0List pass-through pci devices for a domain</div><div>=C2=A0pci=
-assignable-add =C2=A0Make a device assignable for pci-passthru</div><div>=
=C2=A0pci-assignable-remove=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=A0Remove a device from being ass=
ignable</div><div>=C2=A0pci-assignable-list List all the assignable pci dev=
ices</div><div>=C2=A0pause =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 Pause execution of a domain</div><div>=C2=A0unpause =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Unpause a paused domain</div><div>=C2=A0console =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Attach to domain&#39;s console</div><di=
v>=C2=A0vncviewer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Attach to domain&#39;s=
 VNC server.</div><div>=C2=A0save =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0Save a domain state to restore later</div><div>=C2=A0migrate =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Migrate a domain to another host<=
/div><div>=C2=A0dump-core =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Core dump a do=
main</div><div>=C2=A0restore =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Rest=
ore a domain from a saved state</div><div>=C2=A0migrate-receive =C2=A0 =C2=
=A0 Restore a domain from a saved state</div><div>=C2=A0cd-insert =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Insert a cdrom into a guest&#39;s cd drive</div=
><div>=C2=A0cd-eject =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Eject a cdrom=
 from a guest&#39;s cd drive</div><div>=C2=A0mem-max =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Set the maximum amount reservation for a domain</div><=
div>=C2=A0mem-set =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Set the current=
 memory usage for a domain</div><div>=C2=A0button-press =C2=A0 =C2=A0 =C2=
=A0 =C2=A0Indicate an ACPI button press to the domain</div><div>=C2=A0vcpu-=
list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 List the VCPUs for all/some domains=
</div><div>=C2=A0vcpu-pin =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Set whic=
h CPUs a VCPU can use</div><div>=C2=A0vcpu-set =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Set the number of active VCPUs allowed for the domain</div><di=
v>=C2=A0vm-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 List guest domain=
s, excluding dom0, stubdoms, etc.</div><div>=C2=A0info =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get information about Xen host</div><div=
>=C2=A0sharing =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Get information ab=
out page sharing</div><div>=C2=A0sched-credit =C2=A0 =C2=A0 =C2=A0 =C2=A0Ge=
t/set credit scheduler parameters</div><div>=C2=A0sched-credit2 =C2=A0 =C2=
=A0 =C2=A0 Get/set credit2 scheduler parameters</div><div>=C2=A0sched-rtglo=
bal =C2=A0 =C2=A0 =C2=A0Get/set rtglobal scheduler parameters</div><div>=C2=
=A0sched-rtpartition =C2=A0 Get/set rtpartition scheduler parameters</div><=
div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&lt;&gt;&lt;&gt;&lt;&gt; =C2=A0&gt;=
&gt;&gt; here should be &quot;sched-rm&quot; =C2=A0but not show. =C2=A0&gt;=
&gt;&gt;&gt; it the my question.</div><div><br></div><div><br></div><div><d=
iv><div dir=3D"ltr"><div><div><br><br><br><br><br><br>=C2=A0Best regards<br=
>Jie Shen <br><br><br></div>Graduate Student in Computer Science<br></div>I=
llinois Institute of Technology=C2=A0=C2=A0=C2=A0 <br>Stuart Building=C2=A0=
 Chicago, IL 60616<br><a href=3D"tel:%2B1%C2%A0%20312%20404%200122" value=
=3D"+13124040122" target=3D"_blank">+1=C2=A0 312 404 0122</a><br><div><br><=
/div></div></div></div>
</div>
</div></div>

--047d7b2ede2f95f1c9050a3bbefe--


--===============4353886259780485642==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4353886259780485642==--


From xen-devel-bounces@lists.xen.org Mon Dec 15 07:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 07: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 1Y0QXR-0007kg-B1; Mon, 15 Dec 2014 07:57:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jshen25@hawk.iit.edu>) id 1Y0PaG-0006e1-7N
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 06:56:44 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	91/46-25276-B268E845; Mon, 15 Dec 2014 06:56:43 +0000
X-Env-Sender: jshen25@hawk.iit.edu
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418626600!8265037!1
X-Originating-IP: [209.85.192.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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19537 invoked from network); 15 Dec 2014 06:56:41 -0000
Received: from mail-pd0-f173.google.com (HELO mail-pd0-f173.google.com)
	(209.85.192.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 06:56:41 -0000
Received: by mail-pd0-f173.google.com with SMTP id ft15so11119544pdb.32
	for <xen-devel@lists.xen.org>; Sun, 14 Dec 2014 22:56: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=QlmZEKWcoMjU9imRoiK8iQntsMtShW2IHMNnd8S3FI4=;
	b=Abbi+08OMqL2JOhFszgoRwKbgAeT1sRyVGHMbS76kweJ8bWcWFY2RPzJqadJLgUitA
	fCtDZGfceFpdZCDB+K3VG+nptH4bhIc0fFH/kRM+wJTfEsJniCF43m/LBdc3TAPBRpN+
	P+qSntzBEUjG7C2WPiU25vpJ1esm3KJfn06zWrOXGv+5RzYhyZ7atXe5hafd9dVsbh1l
	bw6SLMGFhOC9c0BqmU3hO4pQlbrbRkuAYO0PPw7bJDi8HihKq1FiXXWuWJmRIGdkhtg8
	TImKW2Jd/KPpPvgmVIzMg/A+Y7GgoN7nRzacyoQFddWl8ow69TJxAp70j9XV/HY4i7kr
	jx+Q==
X-Gm-Message-State: ALoCoQm0r+Kuql2PhMvoV1kfobAmvE98PmH5yJmxAAVdp9BZkb7Uz98R5gThvACqoTfxVtcsnqfj
MIME-Version: 1.0
X-Received: by 10.68.217.231 with SMTP id pb7mr49073239pbc.124.1418626600397; 
	Sun, 14 Dec 2014 22:56:40 -0800 (PST)
Received: by 10.70.43.74 with HTTP; Sun, 14 Dec 2014 22:56:40 -0800 (PST)
In-Reply-To: <CADUQMegeBg2dVXptjo7w+dU5CkTs5gUrM=6HbCuj3NftD05oDA@mail.gmail.com>
References: <CADUQMegeBg2dVXptjo7w+dU5CkTs5gUrM=6HbCuj3NftD05oDA@mail.gmail.com>
Date: Mon, 15 Dec 2014 00:56:40 -0600
Message-ID: <CADUQMehGUdNXjsvLAKXXwRDDfJMLdbQw6xHk2rMYAFzyUTtaGQ@mail.gmail.com>
From: Jie Shen <jshen25@hawk.iit.edu>
To: xen-devel@lists.xen.org, 
	"rtxen-devel@googlegroups.com" <rtxen-devel@googlegroups.com>,
	Xiayu Hua <xiayuhuahxy@gmail.com>
X-Mailman-Approved-At: Mon, 15 Dec 2014 07:57:51 +0000
Subject: [Xen-devel] Fwd: rt-xen::make Done::xl :: sched-rm not shown:: how
 to add a command line in xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4353886259780485642=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4353886259780485642==
Content-Type: multipart/alternative; boundary=047d7b2ede2f95f1c9050a3bbefe

--047d7b2ede2f95f1c9050a3bbefe
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Gurus ,
Sorry to bother your again.

Now Make is Done.

Many errors are resolved ( such as some programming errors on xenbus.c
,fbfront.c)


now I can use xl ,unfortunately, xl no option sched-rm.

I changed the source of :

libxl.c   =3D=3D>  output from grep:

libxl.c:static int sched_rm_domain_get(libxl__gc *gc, uint32_t domid,
libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
libxl.c:static int sched_rm_domain_set(libxl__gc *gc, uint32_t domid,
libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
libxl.c:    rc =3D xc_sched_rm_domain_set(CTX->xch, domid, &sdom);
libxl.c:        ret=3Dsched_rm_domain_set(gc, domid, scinfo);
libxl.c: ret=3Dsched_rm_domain_get(gc,domid,scinfo);


and :
xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_set(XcObject
*self,
xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_set(self->xc_handle,
domid, &sdom) !=3D 0 )
xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_get(XcObject
*self, PyObject *args)
xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_get(self->xc_handle,
domid, &sdom) !=3D 0 )
xen/lowlevel/xc/xc.c:   { "sched_rm_domain_set",
xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_set,
xen/lowlevel/xc/xc.c:     { "sched_rm_domain_get",
xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_get,


also created :
libxc/xc_rm.c  =3D=3D=3D> just like libxc/xc_rtpartition.c



not changing main.py:

since I see it is commtented::


main.py:    'sched-rtpartition': ('[-d <Domain>
[-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=3DEXTRA]]',
main.py:                     'Get/set rtpartition scheduler parameters.'),
main.py:    'sched-rtpartition': (
main.py:    "sched-rtpartition",
main.py:# # rtpartition
main.py:# def xm_sched_rtpartition(args):
main.py:#     """Get/Set options for rtpartition Scheduler."""
main.py:#     check_sched_type('rtpartition')
main.py:#         usage('sched-rtpartition')
main.py:#             usage('sched-rtpartition')
main.py:#                     info =3D
server.xend.domain.sched_rtpartition_get(d['name'])
main.py:#                 # domain does not support sched-rtpartition?
main.py:#             usage('sched-rtpartition')
main.py:#             result =3D
server.xend.domain.sched_rtpartition_set(domid, period, budget, vcpu, extra=
)
main.py:    # "sched-rtpartition": xm_sched_rtpartition,
grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=95





my question is how to make xl can changed "sched-rm"  parameters?




jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl
Usage xl [-vfN] <subcommand> [args]

xl full list of subcommands:

 create              Create a domain from config file <filename>
 config-update       Update a running domain's saved configuration, used
when rebuilding the domain after reboot
 list                List information about all/some domains
 destroy             Terminate a domain immediately
 shutdown            Issue a shutdown signal to a domain
 reboot              Issue a reboot signal to a domain
 pci-attach          Insert a new pass-through pci device
 pci-detach          Remove a domain's pass-through pci device
 pci-list            List pass-through pci devices for a domain
 pci-assignable-add  Make a device assignable for pci-passthru
 pci-assignable-remove
                     Remove a device from being assignable
 pci-assignable-list List all the assignable pci devices
 pause               Pause execution of a domain
 unpause             Unpause a paused domain
 console             Attach to domain's console
 vncviewer           Attach to domain's VNC server.
 save                Save a domain state to restore later
 migrate             Migrate a domain to another host
 dump-core           Core dump a domain
 restore             Restore a domain from a saved state
 migrate-receive     Restore a domain from a saved state
 cd-insert           Insert a cdrom into a guest's cd drive
 cd-eject            Eject a cdrom from a guest's cd drive
 mem-max             Set the maximum amount reservation for a domain
 mem-set             Set the current memory usage for a domain
 button-press        Indicate an ACPI button press to the domain
 vcpu-list           List the VCPUs for all/some domains
 vcpu-pin            Set which CPUs a VCPU can use
 vcpu-set            Set the number of active VCPUs allowed for the domain
 vm-list             List guest domains, excluding dom0, stubdoms, etc.
 info                Get information about Xen host
 sharing             Get information about page sharing
 sched-credit        Get/set credit scheduler parameters
 sched-credit2       Get/set credit2 scheduler parameters
 sched-rtglobal      Get/set rtglobal scheduler parameters
 sched-rtpartition   Get/set rtpartition scheduler parameters
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<><><>  >>> here should be "sched-rm"  =
but not show.  >>>> it
the my question.








 Best regards
Jie Shen


Graduate Student in Computer Science
Illinois Institute of Technology
Stuart Building  Chicago, IL 60616
+1  312 404 0122

--047d7b2ede2f95f1c9050a3bbefe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><br><div dir=3D"ltr"><div>Hello=
 Gurus ,</div><div>Sorry to bother your again.<br></div><div><br></div><div=
>Now Make is Done.</div><div><br></div><div>Many errors are resolved ( such=
 as some programming errors on xenbus.c ,fbfront.c)</div><div><br></div><di=
v><br></div><div>now I can use xl ,unfortunately, xl no option sched-rm.</d=
iv><div><br></div><div>I changed the source of :</div><div><br></div><div>l=
ibxl.c =C2=A0 =3D=3D&gt; =C2=A0output from grep:</div><div><br></div><div><=
div>libxl.c:static int sched_rm_domain_get(libxl__gc *gc, uint32_t domid,</=
div><div>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_domain_get(CTX-&gt;xch, d=
omid, &amp;sdom);</div><div>libxl.c:static int sched_rm_domain_set(libxl__g=
c *gc, uint32_t domid,</div><div>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_d=
omain_get(CTX-&gt;xch, domid, &amp;sdom);</div><div>libxl.c: =C2=A0 =C2=A0r=
c =3D xc_sched_rm_domain_set(CTX-&gt;xch, domid, &amp;sdom);</div><div>libx=
l.c: =C2=A0 =C2=A0 =C2=A0 =C2=A0ret=3Dsched_rm_domain_set(gc, domid, scinfo=
);</div><div>libxl.c:<span style=3D"white-space:pre-wrap">		</span>ret=3Dsc=
hed_rm_domain_get(gc,domid,scinfo);</div></div><div><br></div><div><br></di=
v><div>and :</div><div><div>xen/lowlevel/xc/xc.c:static PyObject *pyxc_sche=
d_rm_domain_set(XcObject *self,</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=
=A0struct xen_domctl_sched_rm sdom;</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =
=C2=A0if ( xc_sched_rm_domain_set(self-&gt;xc_handle, domid, &amp;sdom) !=
=3D 0 )</div><div>xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domai=
n_get(XcObject *self, PyObject *args)</div><div>xen/lowlevel/xc/xc.c: =C2=
=A0 =C2=A0struct xen_domctl_sched_rm sdom;</div><div>xen/lowlevel/xc/xc.c: =
=C2=A0 =C2=A0if ( xc_sched_rm_domain_get(self-&gt;xc_handle, domid, &amp;sd=
om) !=3D 0 )</div><div>xen/lowlevel/xc/xc.c: =C2=A0 { &quot;sched_rm_domain=
_set&quot;,</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunctio=
n)pyxc_sched_rm_domain_set,</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0 {=
 &quot;sched_rm_domain_get&quot;,</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =
=C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_get,</div></div><div><br></d=
iv><div><br></div><div>also created :</div><div>libxc/xc_rm.c =C2=A0=3D=3D=
=3D&gt; just like=C2=A0libxc/xc_rtpartition.c<br></div><div><br></div><div>=
<br></div><div><br></div><div>not changing main.py:</div><div><br></div><di=
v>since I see it is commtented::</div><div><br></div><div><br></div><div><d=
iv>main.py: =C2=A0 =C2=A0&#39;sched-rtpartition&#39;: (&#39;[-d &lt;Domain&=
gt; [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=3DEXTRA]]&#39;,</div><div>=
main.py: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 &#39;Get/set rtpartition scheduler parameters.&#39;),</div><div>main.py=
: =C2=A0 =C2=A0&#39;sched-rtpartition&#39;: (</div><div>main.py: =C2=A0 =C2=
=A0&quot;sched-rtpartition&quot;,</div><div>main.py:# # rtpartition</div><d=
iv>main.py:# def xm_sched_rtpartition(args):</div><div>main.py:# =C2=A0 =C2=
=A0 &quot;&quot;&quot;Get/Set options for rtpartition Scheduler.&quot;&quot=
;&quot;</div><div>main.py:# =C2=A0 =C2=A0 check_sched_type(&#39;rtpartition=
&#39;)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtp=
artition&#39;)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 usage(&#39;sched-rtpartition&#39;)</div><div>main.py:# =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 info =3D server.xen=
d.domain.sched_rtpartition_get(d[&#39;name&#39;])</div><div>main.py:# =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # domain does not supp=
ort sched-rtpartition?</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div><div>main.py:# =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 result =3D server.xend.domain.sched_rtpa=
rtition_set(domid, period, budget, vcpu, extra)</div><div>main.py: =C2=A0 =
=C2=A0# &quot;sched-rtpartition&quot;: xm_sched_rtpartition,</div><div>grep=
: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=95</div></div><div><br>=
</div><div><br></div><div><br></div><div><br></div><div><br></div><div>my q=
uestion is how to make xl can changed &quot;sched-rm&quot; =C2=A0parameters=
?</div><div><br><br></div><div><br></div><div><br></div><div>jackyshen@jack=
yshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl</div><div>Usage xl [-vfN=
] &lt;subcommand&gt; [args]</div><div><br></div><div>xl full list of subcom=
mands:</div><div><br></div><div>=C2=A0create =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Create a domain from config file &lt;filename&gt;</div>=
<div>=C2=A0config-update =C2=A0 =C2=A0 =C2=A0 Update a running domain&#39;s=
 saved configuration, used when rebuilding the domain after reboot</div><di=
v>=C2=A0list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0List in=
formation about all/some domains</div><div>=C2=A0destroy =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 Terminate a domain immediately</div><div>=C2=A0shu=
tdown =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Issue a shutdown signal to a=
 domain</div><div>=C2=A0reboot =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Issue a reboot signal to a domain</div><div>=C2=A0pci-attach =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Insert a new pass-through pci device</div><div>=
=C2=A0pci-detach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Remove a domain&#39;s pa=
ss-through pci device</div><div>=C2=A0pci-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0List pass-through pci devices for a domain</div><div>=C2=A0pci=
-assignable-add =C2=A0Make a device assignable for pci-passthru</div><div>=
=C2=A0pci-assignable-remove=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=A0Remove a device from being ass=
ignable</div><div>=C2=A0pci-assignable-list List all the assignable pci dev=
ices</div><div>=C2=A0pause =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 Pause execution of a domain</div><div>=C2=A0unpause =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Unpause a paused domain</div><div>=C2=A0console =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Attach to domain&#39;s console</div><di=
v>=C2=A0vncviewer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Attach to domain&#39;s=
 VNC server.</div><div>=C2=A0save =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0Save a domain state to restore later</div><div>=C2=A0migrate =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Migrate a domain to another host<=
/div><div>=C2=A0dump-core =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Core dump a do=
main</div><div>=C2=A0restore =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Rest=
ore a domain from a saved state</div><div>=C2=A0migrate-receive =C2=A0 =C2=
=A0 Restore a domain from a saved state</div><div>=C2=A0cd-insert =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Insert a cdrom into a guest&#39;s cd drive</div=
><div>=C2=A0cd-eject =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Eject a cdrom=
 from a guest&#39;s cd drive</div><div>=C2=A0mem-max =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Set the maximum amount reservation for a domain</div><=
div>=C2=A0mem-set =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Set the current=
 memory usage for a domain</div><div>=C2=A0button-press =C2=A0 =C2=A0 =C2=
=A0 =C2=A0Indicate an ACPI button press to the domain</div><div>=C2=A0vcpu-=
list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 List the VCPUs for all/some domains=
</div><div>=C2=A0vcpu-pin =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Set whic=
h CPUs a VCPU can use</div><div>=C2=A0vcpu-set =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Set the number of active VCPUs allowed for the domain</div><di=
v>=C2=A0vm-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 List guest domain=
s, excluding dom0, stubdoms, etc.</div><div>=C2=A0info =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get information about Xen host</div><div=
>=C2=A0sharing =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Get information ab=
out page sharing</div><div>=C2=A0sched-credit =C2=A0 =C2=A0 =C2=A0 =C2=A0Ge=
t/set credit scheduler parameters</div><div>=C2=A0sched-credit2 =C2=A0 =C2=
=A0 =C2=A0 Get/set credit2 scheduler parameters</div><div>=C2=A0sched-rtglo=
bal =C2=A0 =C2=A0 =C2=A0Get/set rtglobal scheduler parameters</div><div>=C2=
=A0sched-rtpartition =C2=A0 Get/set rtpartition scheduler parameters</div><=
div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&lt;&gt;&lt;&gt;&lt;&gt; =C2=A0&gt;=
&gt;&gt; here should be &quot;sched-rm&quot; =C2=A0but not show. =C2=A0&gt;=
&gt;&gt;&gt; it the my question.</div><div><br></div><div><br></div><div><d=
iv><div dir=3D"ltr"><div><div><br><br><br><br><br><br>=C2=A0Best regards<br=
>Jie Shen <br><br><br></div>Graduate Student in Computer Science<br></div>I=
llinois Institute of Technology=C2=A0=C2=A0=C2=A0 <br>Stuart Building=C2=A0=
 Chicago, IL 60616<br><a href=3D"tel:%2B1%C2%A0%20312%20404%200122" value=
=3D"+13124040122" target=3D"_blank">+1=C2=A0 312 404 0122</a><br><div><br><=
/div></div></div></div>
</div>
</div></div>

--047d7b2ede2f95f1c9050a3bbefe--


--===============4353886259780485642==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4353886259780485642==--


From xen-devel-bounces@lists.xen.org Mon Dec 15 07:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 07: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 1Y0QXQ-0007kL-8P; Mon, 15 Dec 2014 07:57:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shenjie7810@gmail.com>) id 1XzZ1U-0003JK-AG
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 22:49:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B1/85-15461-FE07B845; Fri, 12 Dec 2014 22:49:19 +0000
X-Env-Sender: shenjie7810@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418424557!7991581!1
X-Originating-IP: [209.85.218.49]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17145 invoked from network); 12 Dec 2014 22:49:18 -0000
Received: from mail-oi0-f49.google.com (HELO mail-oi0-f49.google.com)
	(209.85.218.49)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 22:49:18 -0000
Received: by mail-oi0-f49.google.com with SMTP id i138so5819882oig.36
	for <Xen-devel@lists.xen.org>; Fri, 12 Dec 2014 14:49:16 -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=G4XY09WJ9Fd7SWKtIygfXnWsLTiuUeIlRmMa85H3q7w=;
	b=w0ZHBLBD8BiAH2rJCohLmZtk1wk40rQZ0QpCSKLFF0abM2PX9N2uetQNbP02cpJQk+
	3P6GOtAP0/sm+0QtAM41XnCAG2EQwyS6b9w85hyYo71n4b31zoo+VKs7ne96nMPfepll
	jFDh8mXsMRX1B+RJ+ObrQgJD9AfGr2JQo+7r30JeTqLYa6QJewYQldC/KiQpxFjAiQ3r
	Bk0/Gv//51oYoBe0B4DN+CwrH7QW3Js/w1pXacetV98V3eBCmegwVYri1WlPUDuqvA6t
	o3TBmQ50L9cwn8QxFoeAzdYIFb3h1vtoq/cJjCJeUM9EDb4g/Bao+/rCS9dm2gJdzguU
	LahQ==
MIME-Version: 1.0
X-Received: by 10.182.28.99 with SMTP id a3mr11704794obh.79.1418424556868;
	Fri, 12 Dec 2014 14:49:16 -0800 (PST)
Received: by 10.76.7.206 with HTTP; Fri, 12 Dec 2014 14:49:16 -0800 (PST)
Date: Fri, 12 Dec 2014 16:49:16 -0600
Message-ID: <CAB2Q45H0D0ZvGWth1hV+aYnV+MZ1EaEqHk4sk9whUCeuDh-7QA@mail.gmail.com>
From: Jie Shen <shenjie7810@gmail.com>
To: Xen-devel@lists.xen.org
X-Mailman-Approved-At: Mon, 15 Dec 2014 07:57:51 +0000
Subject: [Xen-devel] libxl.c::macro definition::LIBXL_SCHEDULER_SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2327421872146702705=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2327421872146702705==
Content-Type: multipart/alternative; boundary=089e0158ae02da5d08050a0cb361

--089e0158ae02da5d08050a0cb361
Content-Type: text/plain; charset=UTF-8

Hello Gurus,

I am working on a project to change code of xen,
Unfortunately I can not find the macro def of : LIBXL_SCHEDULER_****

if C compiler not finds it ,it will trigger  an error " XXX not defined"

But where is it ? I search all c and h files.
Could you please help me to check it ?


Jie Shen

===========================================


int libxl_domain_sched_params_set(libxl_ctx *ctx, uint32_t domid,
                                  const libxl_domain_sched_params *scinfo)
{
    GC_INIT(ctx);
    libxl_scheduler sched = scinfo->sched;
    int ret;

    if (sched == LIBXL_SCHEDULER_UNKNOWN)
        sched = libxl__domain_scheduler(gc, domid);

    switch (sched) {
    case LIBXL_SCHEDULER_SEDF:
        ret=sched_sedf_domain_set(gc, domid, scinfo);
        break;
    case LIBXL_SCHEDULER_CREDIT:
        ret=sched_credit_domain_set(gc, domid, scinfo);
        break;
    case LIBXL_SCHEDULER_CREDIT2:
        ret=sched_credit2_domain_set(gc, domid, scinfo);
        break;
    case LIBXL_SCHEDULER_RTGLOBAL:
        ret=sched_rtglobal_domain_set(gc, domid, scinfo);
        break;
    case LIBXL_SCHEDULER_RTPARTITION:
        ret=sched_rtpartition_domain_set(gc, domid, scinfo);
        break;
    case LIBXL_SCHEDULER_ARINC653:
        ret=sched_arinc653_domain_set(gc, domid, scinfo);
        break;
    default:
        LOG(ERROR, "Unknown scheduler");
        ret=ERROR_INVAL;
        break;
    }

    GC_FREE;
    return ret;

--089e0158ae02da5d08050a0cb361
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello Gurus,</div><div><br></div><div>I am working on=
 a project to change code of xen,</div><div>Unfortunately I can not find th=
e macro def of :=C2=A0LIBXL_SCHEDULER_****</div><div><br></div><div>if C co=
mpiler not finds it ,it will trigger =C2=A0an error &quot; XXX not defined&=
quot;</div><div><br></div><div>But where is it ? I search all c and h files=
.</div><div>Could you please help me to check it ?</div><div><br></div><div=
><br></div><div>Jie Shen=C2=A0</div><div><br></div><div>=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><br></div><div><br></div><di=
v>int libxl_domain_sched_params_set(libxl_ctx *ctx, uint32_t domid,</div><d=
iv>=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 const libxl_domain_sched_p=
arams *scinfo)</div><div>{</div><div>=C2=A0 =C2=A0 GC_INIT(ctx);</div><div>=
=C2=A0 =C2=A0 libxl_scheduler sched =3D scinfo-&gt;sched;</div><div>=C2=A0 =
=C2=A0 int ret;</div><div><br></div><div>=C2=A0 =C2=A0 if (sched =3D=3D LIB=
XL_SCHEDULER_UNKNOWN)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sched =3D libxl=
__domain_scheduler(gc, domid);</div><div><br></div><div>=C2=A0 =C2=A0 switc=
h (sched) {</div><div>=C2=A0 =C2=A0 case LIBXL_SCHEDULER_SEDF:</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_sedf_domain_set(gc, domid, scinfo);=
</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;</div><div>=C2=A0 =C2=A0 case =
LIBXL_SCHEDULER_CREDIT:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_c=
redit_domain_set(gc, domid, scinfo);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
break;</div><div>=C2=A0 =C2=A0 case LIBXL_SCHEDULER_CREDIT2:</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_credit2_domain_set(gc, domid, scinfo);=
</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;</div><div>=C2=A0 =C2=A0 case =
LIBXL_SCHEDULER_RTGLOBAL:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched=
_rtglobal_domain_set(gc, domid, scinfo);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 break;</div><div>=C2=A0 =C2=A0 case LIBXL_SCHEDULER_RTPARTITION:</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_rtpartition_domain_set(gc, domi=
d, scinfo);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 break; =C2=A0 =C2=A0=C2=
=A0</div><div>=C2=A0 =C2=A0 case LIBXL_SCHEDULER_ARINC653:</div><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_arinc653_domain_set(gc, domid, scinfo);</=
div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;</div><div>=C2=A0 =C2=A0 default=
:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 LOG(ERROR, &quot;Unknown scheduler&=
quot;);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3DERROR_INVAL;</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;</div><div>=C2=A0 =C2=A0 }</div><div><br>=
</div><div>=C2=A0 =C2=A0 GC_FREE;</div><div>=C2=A0 =C2=A0 return ret;</div>=
</div>

--089e0158ae02da5d08050a0cb361--


--===============2327421872146702705==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2327421872146702705==--


From xen-devel-bounces@lists.xen.org Mon Dec 15 07:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 07: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 1Y0QXQ-0007kL-8P; Mon, 15 Dec 2014 07:57:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shenjie7810@gmail.com>) id 1XzZ1U-0003JK-AG
	for Xen-devel@lists.xen.org; Fri, 12 Dec 2014 22:49:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B1/85-15461-FE07B845; Fri, 12 Dec 2014 22:49:19 +0000
X-Env-Sender: shenjie7810@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418424557!7991581!1
X-Originating-IP: [209.85.218.49]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17145 invoked from network); 12 Dec 2014 22:49:18 -0000
Received: from mail-oi0-f49.google.com (HELO mail-oi0-f49.google.com)
	(209.85.218.49)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Dec 2014 22:49:18 -0000
Received: by mail-oi0-f49.google.com with SMTP id i138so5819882oig.36
	for <Xen-devel@lists.xen.org>; Fri, 12 Dec 2014 14:49:16 -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=G4XY09WJ9Fd7SWKtIygfXnWsLTiuUeIlRmMa85H3q7w=;
	b=w0ZHBLBD8BiAH2rJCohLmZtk1wk40rQZ0QpCSKLFF0abM2PX9N2uetQNbP02cpJQk+
	3P6GOtAP0/sm+0QtAM41XnCAG2EQwyS6b9w85hyYo71n4b31zoo+VKs7ne96nMPfepll
	jFDh8mXsMRX1B+RJ+ObrQgJD9AfGr2JQo+7r30JeTqLYa6QJewYQldC/KiQpxFjAiQ3r
	Bk0/Gv//51oYoBe0B4DN+CwrH7QW3Js/w1pXacetV98V3eBCmegwVYri1WlPUDuqvA6t
	o3TBmQ50L9cwn8QxFoeAzdYIFb3h1vtoq/cJjCJeUM9EDb4g/Bao+/rCS9dm2gJdzguU
	LahQ==
MIME-Version: 1.0
X-Received: by 10.182.28.99 with SMTP id a3mr11704794obh.79.1418424556868;
	Fri, 12 Dec 2014 14:49:16 -0800 (PST)
Received: by 10.76.7.206 with HTTP; Fri, 12 Dec 2014 14:49:16 -0800 (PST)
Date: Fri, 12 Dec 2014 16:49:16 -0600
Message-ID: <CAB2Q45H0D0ZvGWth1hV+aYnV+MZ1EaEqHk4sk9whUCeuDh-7QA@mail.gmail.com>
From: Jie Shen <shenjie7810@gmail.com>
To: Xen-devel@lists.xen.org
X-Mailman-Approved-At: Mon, 15 Dec 2014 07:57:51 +0000
Subject: [Xen-devel] libxl.c::macro definition::LIBXL_SCHEDULER_SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2327421872146702705=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2327421872146702705==
Content-Type: multipart/alternative; boundary=089e0158ae02da5d08050a0cb361

--089e0158ae02da5d08050a0cb361
Content-Type: text/plain; charset=UTF-8

Hello Gurus,

I am working on a project to change code of xen,
Unfortunately I can not find the macro def of : LIBXL_SCHEDULER_****

if C compiler not finds it ,it will trigger  an error " XXX not defined"

But where is it ? I search all c and h files.
Could you please help me to check it ?


Jie Shen

===========================================


int libxl_domain_sched_params_set(libxl_ctx *ctx, uint32_t domid,
                                  const libxl_domain_sched_params *scinfo)
{
    GC_INIT(ctx);
    libxl_scheduler sched = scinfo->sched;
    int ret;

    if (sched == LIBXL_SCHEDULER_UNKNOWN)
        sched = libxl__domain_scheduler(gc, domid);

    switch (sched) {
    case LIBXL_SCHEDULER_SEDF:
        ret=sched_sedf_domain_set(gc, domid, scinfo);
        break;
    case LIBXL_SCHEDULER_CREDIT:
        ret=sched_credit_domain_set(gc, domid, scinfo);
        break;
    case LIBXL_SCHEDULER_CREDIT2:
        ret=sched_credit2_domain_set(gc, domid, scinfo);
        break;
    case LIBXL_SCHEDULER_RTGLOBAL:
        ret=sched_rtglobal_domain_set(gc, domid, scinfo);
        break;
    case LIBXL_SCHEDULER_RTPARTITION:
        ret=sched_rtpartition_domain_set(gc, domid, scinfo);
        break;
    case LIBXL_SCHEDULER_ARINC653:
        ret=sched_arinc653_domain_set(gc, domid, scinfo);
        break;
    default:
        LOG(ERROR, "Unknown scheduler");
        ret=ERROR_INVAL;
        break;
    }

    GC_FREE;
    return ret;

--089e0158ae02da5d08050a0cb361
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello Gurus,</div><div><br></div><div>I am working on=
 a project to change code of xen,</div><div>Unfortunately I can not find th=
e macro def of :=C2=A0LIBXL_SCHEDULER_****</div><div><br></div><div>if C co=
mpiler not finds it ,it will trigger =C2=A0an error &quot; XXX not defined&=
quot;</div><div><br></div><div>But where is it ? I search all c and h files=
.</div><div>Could you please help me to check it ?</div><div><br></div><div=
><br></div><div>Jie Shen=C2=A0</div><div><br></div><div>=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><br></div><div><br></div><di=
v>int libxl_domain_sched_params_set(libxl_ctx *ctx, uint32_t domid,</div><d=
iv>=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 const libxl_domain_sched_p=
arams *scinfo)</div><div>{</div><div>=C2=A0 =C2=A0 GC_INIT(ctx);</div><div>=
=C2=A0 =C2=A0 libxl_scheduler sched =3D scinfo-&gt;sched;</div><div>=C2=A0 =
=C2=A0 int ret;</div><div><br></div><div>=C2=A0 =C2=A0 if (sched =3D=3D LIB=
XL_SCHEDULER_UNKNOWN)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sched =3D libxl=
__domain_scheduler(gc, domid);</div><div><br></div><div>=C2=A0 =C2=A0 switc=
h (sched) {</div><div>=C2=A0 =C2=A0 case LIBXL_SCHEDULER_SEDF:</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_sedf_domain_set(gc, domid, scinfo);=
</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;</div><div>=C2=A0 =C2=A0 case =
LIBXL_SCHEDULER_CREDIT:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_c=
redit_domain_set(gc, domid, scinfo);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
break;</div><div>=C2=A0 =C2=A0 case LIBXL_SCHEDULER_CREDIT2:</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_credit2_domain_set(gc, domid, scinfo);=
</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;</div><div>=C2=A0 =C2=A0 case =
LIBXL_SCHEDULER_RTGLOBAL:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched=
_rtglobal_domain_set(gc, domid, scinfo);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 break;</div><div>=C2=A0 =C2=A0 case LIBXL_SCHEDULER_RTPARTITION:</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_rtpartition_domain_set(gc, domi=
d, scinfo);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 break; =C2=A0 =C2=A0=C2=
=A0</div><div>=C2=A0 =C2=A0 case LIBXL_SCHEDULER_ARINC653:</div><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_arinc653_domain_set(gc, domid, scinfo);</=
div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;</div><div>=C2=A0 =C2=A0 default=
:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 LOG(ERROR, &quot;Unknown scheduler&=
quot;);</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3DERROR_INVAL;</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;</div><div>=C2=A0 =C2=A0 }</div><div><br>=
</div><div>=C2=A0 =C2=A0 GC_FREE;</div><div>=C2=A0 =C2=A0 return ret;</div>=
</div>

--089e0158ae02da5d08050a0cb361--


--===============2327421872146702705==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2327421872146702705==--


From xen-devel-bounces@lists.xen.org Mon Dec 15 07:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 07: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 1Y0QXS-0007ku-2K; Mon, 15 Dec 2014 07:57:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jshen25@hawk.iit.edu>) id 1Y0QLq-0007ab-Fi
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 07:45:54 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	24/63-15461-1B19E845; Mon, 15 Dec 2014 07:45:53 +0000
X-Env-Sender: jshen25@hawk.iit.edu
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418629550!15548742!1
X-Originating-IP: [209.85.192.179]
X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26920 invoked from network); 15 Dec 2014 07:45:52 -0000
Received: from mail-pd0-f179.google.com (HELO mail-pd0-f179.google.com)
	(209.85.192.179)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 07:45:52 -0000
Received: by mail-pd0-f179.google.com with SMTP id fp1so11230392pdb.10
	for <xen-devel@lists.xen.org>; Sun, 14 Dec 2014 23:45: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=FxhERLRfILluinB3/RQ7QLKTOOp2rzMfr5UfCvkhXtQ=;
	b=JodLXPWTAxIcNPL+8TUBioLZozIVN/DA9+WMBJRr/uh6rrelE3A2VhBTrIHBrgC4wq
	K0gfNUZJXpKQLHWzuMt0tXTq+0sZGyx5F7SXSvJpjgQoOAQSeFWeQlTOR/WfwXY94MXN
	xa/WvDSShI/EcXp6mMRz8cIElw2RcyY/b8z+o45TgvErWFP4ShOyrggytgwTlXIf2QLE
	hZEfpSrJMNvhJTRvBqdL5XlHmh7JRiyzMJX+cWgEcLd4C481+fcKB185CthoZR6xIn17
	AxS71W3I0Bnf9DFy5cB7LPPqaXeod6DdT6zXELj2tSiyfdSmCgUVI/4NLWYKMc3Gp/uK
	lmcA==
X-Gm-Message-State: ALoCoQkSADBHcctJnQd5/e/4X8M2ctngBGnlo6fpswdNDjNjTox1pl20jZsORuYq39F38A4ciUay
MIME-Version: 1.0
X-Received: by 10.67.13.12 with SMTP id eu12mr49193349pad.157.1418629550537;
	Sun, 14 Dec 2014 23:45:50 -0800 (PST)
Received: by 10.70.43.74 with HTTP; Sun, 14 Dec 2014 23:45:50 -0800 (PST)
In-Reply-To: <CADUQMejvxaQkBr=FzoyN8yG12CTmpDKzuF4bX+0pYr9hK9_RUg@mail.gmail.com>
References: <CADUQMegeBg2dVXptjo7w+dU5CkTs5gUrM=6HbCuj3NftD05oDA@mail.gmail.com>
	<CADUQMehGUdNXjsvLAKXXwRDDfJMLdbQw6xHk2rMYAFzyUTtaGQ@mail.gmail.com>
	<CADUQMejvxaQkBr=FzoyN8yG12CTmpDKzuF4bX+0pYr9hK9_RUg@mail.gmail.com>
Date: Mon, 15 Dec 2014 01:45:50 -0600
Message-ID: <CADUQMejBN9Uz+=gMNVeGGdGYHSMfs6vwV5zjQLnhxmVvsrqvtg@mail.gmail.com>
From: Jie Shen <jshen25@hawk.iit.edu>
To: xen-devel@lists.xen.org, 
	"rtxen-devel@googlegroups.com" <rtxen-devel@googlegroups.com>,
	Xiayu Hua <xiayuhuahxy@gmail.com>
X-Mailman-Approved-At: Mon, 15 Dec 2014 07:57:51 +0000
Subject: Re: [Xen-devel] rt-xen::make Done::xl :: sched-rm not shown:: how
 to add a command line in xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1718337007820827120=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1718337007820827120==
Content-Type: multipart/alternative; boundary=047d7b2e0d496d9572050a3c6e7b

--047d7b2e0d496d9572050a3c6e7b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

resolved !!!!
thanks any way!

info                Get information about Xen host
 sharing             Get information about page sharing
 sched-credit        Get/set credit scheduler parameters
 sched-credit2       Get/set credit2 scheduler parameters
 sched-rtglobal      Get/set rtglobal scheduler parameters
 sched-rtpartition   Get/set rtpartition scheduler parameters
 sched-rm            Get/set rm scheduler parameters
   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> showing.....
 sched-sedf          Get/set sedf scheduler parameters
 domid               Convert a domain name to domain id
 domname             Convert a domain id to domain name
 rename              Rename a domain








 Best regards
Jie Shen


Graduate Student in Computer Science
Illinois Institute of Technology
Stuart Building  Chicago, IL 60616
+1  312 404 0122


On Mon, Dec 15, 2014 at 1:40 AM, Jie Shen <jshen25@hawk.iit.edu> wrote:
>
> Hello Gurus,
> should be the two files :
>
> xl_cmdimpl.c
> xl_cmdtable.c?
>
>
>
>
>
>
>
>
>
>  Best regards
> Jie Shen
>
>
> Graduate Student in Computer Science
> Illinois Institute of Technology
> Stuart Building  Chicago, IL 60616
> +1  312 404 0122
>
>
> On Mon, Dec 15, 2014 at 12:56 AM, Jie Shen <jshen25@hawk.iit.edu> wrote:
>>
>>
>> Hello Gurus ,
>> Sorry to bother your again.
>>
>> Now Make is Done.
>>
>> Many errors are resolved ( such as some programming errors on xenbus.c
>> ,fbfront.c)
>>
>>
>> now I can use xl ,unfortunately, xl no option sched-rm.
>>
>> I changed the source of :
>>
>> libxl.c   =3D=3D>  output from grep:
>>
>> libxl.c:static int sched_rm_domain_get(libxl__gc *gc, uint32_t domid,
>> libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
>> libxl.c:static int sched_rm_domain_set(libxl__gc *gc, uint32_t domid,
>> libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
>> libxl.c:    rc =3D xc_sched_rm_domain_set(CTX->xch, domid, &sdom);
>> libxl.c:        ret=3Dsched_rm_domain_set(gc, domid, scinfo);
>> libxl.c: ret=3Dsched_rm_domain_get(gc,domid,scinfo);
>>
>>
>> and :
>> xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_set(XcObject
>> *self,
>> xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
>> xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_set(self->xc_handle,
>> domid, &sdom) !=3D 0 )
>> xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_get(XcObject
>> *self, PyObject *args)
>> xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
>> xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_get(self->xc_handle,
>> domid, &sdom) !=3D 0 )
>> xen/lowlevel/xc/xc.c:   { "sched_rm_domain_set",
>> xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_set,
>> xen/lowlevel/xc/xc.c:     { "sched_rm_domain_get",
>> xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_get,
>>
>>
>> also created :
>> libxc/xc_rm.c  =3D=3D=3D> just like libxc/xc_rtpartition.c
>>
>>
>>
>> not changing main.py:
>>
>> since I see it is commtented::
>>
>>
>> main.py:    'sched-rtpartition': ('[-d <Domain>
>> [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=3DEXTRA]]',
>> main.py:                     'Get/set rtpartition scheduler parameters.'=
),
>> main.py:    'sched-rtpartition': (
>> main.py:    "sched-rtpartition",
>> main.py:# # rtpartition
>> main.py:# def xm_sched_rtpartition(args):
>> main.py:#     """Get/Set options for rtpartition Scheduler."""
>> main.py:#     check_sched_type('rtpartition')
>> main.py:#         usage('sched-rtpartition')
>> main.py:#             usage('sched-rtpartition')
>> main.py:#                     info =3D
>> server.xend.domain.sched_rtpartition_get(d['name'])
>> main.py:#                 # domain does not support sched-rtpartition?
>> main.py:#             usage('sched-rtpartition')
>> main.py:#             result =3D
>> server.xend.domain.sched_rtpartition_set(domid, period, budget, vcpu, ex=
tra)
>> main.py:    # "sched-rtpartition": xm_sched_rtpartition,
>> grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=95
>>
>>
>>
>>
>>
>> my question is how to make xl can changed "sched-rm"  parameters?
>>
>>
>>
>>
>> jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl
>> Usage xl [-vfN] <subcommand> [args]
>>
>> xl full list of subcommands:
>>
>>  create              Create a domain from config file <filename>
>>  config-update       Update a running domain's saved configuration, used
>> when rebuilding the domain after reboot
>>  list                List information about all/some domains
>>  destroy             Terminate a domain immediately
>>  shutdown            Issue a shutdown signal to a domain
>>  reboot              Issue a reboot signal to a domain
>>  pci-attach          Insert a new pass-through pci device
>>  pci-detach          Remove a domain's pass-through pci device
>>  pci-list            List pass-through pci devices for a domain
>>  pci-assignable-add  Make a device assignable for pci-passthru
>>  pci-assignable-remove
>>                      Remove a device from being assignable
>>  pci-assignable-list List all the assignable pci devices
>>  pause               Pause execution of a domain
>>  unpause             Unpause a paused domain
>>  console             Attach to domain's console
>>  vncviewer           Attach to domain's VNC server.
>>  save                Save a domain state to restore later
>>  migrate             Migrate a domain to another host
>>  dump-core           Core dump a domain
>>  restore             Restore a domain from a saved state
>>  migrate-receive     Restore a domain from a saved state
>>  cd-insert           Insert a cdrom into a guest's cd drive
>>  cd-eject            Eject a cdrom from a guest's cd drive
>>  mem-max             Set the maximum amount reservation for a domain
>>  mem-set             Set the current memory usage for a domain
>>  button-press        Indicate an ACPI button press to the domain
>>  vcpu-list           List the VCPUs for all/some domains
>>  vcpu-pin            Set which CPUs a VCPU can use
>>  vcpu-set            Set the number of active VCPUs allowed for the doma=
in
>>  vm-list             List guest domains, excluding dom0, stubdoms, etc.
>>  info                Get information about Xen host
>>  sharing             Get information about page sharing
>>  sched-credit        Get/set credit scheduler parameters
>>  sched-credit2       Get/set credit2 scheduler parameters
>>  sched-rtglobal      Get/set rtglobal scheduler parameters
>>  sched-rtpartition   Get/set rtpartition scheduler parameters
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<><><>  >>> here should be "sched-rm=
"  but not show.  >>>> it
>> the my question.
>>
>>
>>
>>
>>
>>
>>
>>
>>  Best regards
>> Jie Shen
>>
>>
>> Graduate Student in Computer Science
>> Illinois Institute of Technology
>> Stuart Building  Chicago, IL 60616
>> +1  312 404 0122
>>
>>

--047d7b2e0d496d9572050a3c6e7b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div>resolved !!!!<div>thanks any way!<br><div><=
br></div><div><div>info =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Get information about Xen host</div><div>=C2=A0sharing =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Get information about page sharing</div><div>=
=C2=A0sched-credit =C2=A0 =C2=A0 =C2=A0 =C2=A0Get/set credit scheduler para=
meters</div><div>=C2=A0sched-credit2 =C2=A0 =C2=A0 =C2=A0 Get/set credit2 s=
cheduler parameters</div><div>=C2=A0sched-rtglobal =C2=A0 =C2=A0 =C2=A0Get/=
set rtglobal scheduler parameters</div><div>=C2=A0sched-rtpartition =C2=A0 =
Get/set rtpartition scheduler parameters</div><div>=C2=A0sched-rm =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get/set rm scheduler parameters =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&gt; showing.....</div><div>=C2=A0s=
ched-sedf =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get/set sedf scheduler paramete=
rs</div><div>=C2=A0domid =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 C=
onvert a domain name to domain id</div><div>=C2=A0domname =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 Convert a domain id to domain name</div><div>=C2=
=A0rename =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rename a domain</=
div></div><div><br></div></div></div><div class=3D"gmail_extra"><br clear=
=3D"all"><div><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div><br=
><br><br><br><br><br>=C2=A0Best regards<br>Jie Shen <br><br><br></div>Gradu=
ate Student in Computer Science<br></div>Illinois Institute of Technology=
=C2=A0=C2=A0=C2=A0 <br>Stuart Building=C2=A0 Chicago, IL 60616<br>+1=C2=A0 =
312 404 0122<br><div><br></div></div></div></div>
<br><div class=3D"gmail_quote">On Mon, Dec 15, 2014 at 1:40 AM, Jie Shen <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:jshen25@hawk.iit.edu" target=3D"_blan=
k">jshen25@hawk.iit.edu</a>&gt;</span> wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Hello Gurus,<div>should be the two files :</div><div><br>=
</div><div>xl_cmdimpl.c</div><div>xl_cmdtable.c?</div><div><br></div><div><=
br></div></div><div class=3D"gmail_extra"><span class=3D""><br clear=3D"all=
"><div><div><div dir=3D"ltr"><div><div><br><br><br><br><br><br>=C2=A0Best r=
egards<br>Jie Shen <br><br><br></div>Graduate Student in Computer Science<b=
r></div>Illinois Institute of Technology=C2=A0=C2=A0=C2=A0 <br>Stuart Build=
ing=C2=A0 Chicago, IL 60616<br><a href=3D"tel:%2B1%C2%A0%20312%20404%200122=
" value=3D"+13124040122" target=3D"_blank">+1=C2=A0 312 404 0122</a><br><di=
v><br></div></div></div></div>
<br></span><div><div class=3D"h5"><div class=3D"gmail_quote">On Mon, Dec 15=
, 2014 at 12:56 AM, Jie Shen <span dir=3D"ltr">&lt;<a href=3D"mailto:jshen2=
5@hawk.iit.edu" target=3D"_blank">jshen25@hawk.iit.edu</a>&gt;</span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"=
><br><div dir=3D"ltr"><div>Hello Gurus ,</div><div><div><div>Sorry to bothe=
r your again.<br></div><div><br></div><div>Now Make is Done.</div><div><br>=
</div><div>Many errors are resolved ( such as some programming errors on xe=
nbus.c ,fbfront.c)</div><div><br></div><div><br></div><div>now I can use xl=
 ,unfortunately, xl no option sched-rm.</div><div><br></div><div>I changed =
the source of :</div><div><br></div><div>libxl.c =C2=A0 =3D=3D&gt; =C2=A0ou=
tput from grep:</div><div><br></div><div><div>libxl.c:static int sched_rm_d=
omain_get(libxl__gc *gc, uint32_t domid,</div><div>libxl.c: =C2=A0 =C2=A0rc=
 =3D xc_sched_rm_domain_get(CTX-&gt;xch, domid, &amp;sdom);</div><div>libxl=
.c:static int sched_rm_domain_set(libxl__gc *gc, uint32_t domid,</div><div>=
libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_domain_get(CTX-&gt;xch, domid, &am=
p;sdom);</div><div>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_domain_set(CTX-=
&gt;xch, domid, &amp;sdom);</div><div>libxl.c: =C2=A0 =C2=A0 =C2=A0 =C2=A0r=
et=3Dsched_rm_domain_set(gc, domid, scinfo);</div><div>libxl.c:<span style=
=3D"white-space:pre-wrap">		</span>ret=3Dsched_rm_domain_get(gc,domid,scinf=
o);</div></div><div><br></div><div><br></div><div>and :</div><div><div>xen/=
lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_set(XcObject *self,<=
/div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0struct xen_domctl_sched_rm sdo=
m;</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_set=
(self-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</div><div>xen/lowlevel/xc/x=
c.c:static PyObject *pyxc_sched_rm_domain_get(XcObject *self, PyObject *arg=
s)</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0struct xen_domctl_sched_rm =
sdom;</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_=
get(self-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</div><div>xen/lowlevel/x=
c/xc.c: =C2=A0 { &quot;sched_rm_domain_set&quot;,</div><div>xen/lowlevel/xc=
/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_set,</div><div=
>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0 { &quot;sched_rm_domain_get&quot;,</di=
v><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm=
_domain_get,</div></div><div><br></div><div><br></div><div>also created :</=
div><div>libxc/xc_rm.c =C2=A0=3D=3D=3D&gt; just like=C2=A0libxc/xc_rtpartit=
ion.c<br></div><div><br></div><div><br></div><div><br></div><div>not changi=
ng main.py:</div><div><br></div><div>since I see it is commtented::</div><d=
iv><br></div><div><br></div><div><div>main.py: =C2=A0 =C2=A0&#39;sched-rtpa=
rtition&#39;: (&#39;[-d &lt;Domain&gt; [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DV=
CPU]|-e[=3DEXTRA]]&#39;,</div><div>main.py: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &#39;Get/set rtpartition scheduler p=
arameters.&#39;),</div><div>main.py: =C2=A0 =C2=A0&#39;sched-rtpartition&#3=
9;: (</div><div>main.py: =C2=A0 =C2=A0&quot;sched-rtpartition&quot;,</div><=
div>main.py:# # rtpartition</div><div>main.py:# def xm_sched_rtpartition(ar=
gs):</div><div>main.py:# =C2=A0 =C2=A0 &quot;&quot;&quot;Get/Set options fo=
r rtpartition Scheduler.&quot;&quot;&quot;</div><div>main.py:# =C2=A0 =C2=
=A0 check_sched_type(&#39;rtpartition&#39;)</div><div>main.py:# =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div><div>main.py:# =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;=
)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 info =3D server.xend.domain.sched_rtpartition_get(d[&#39;=
name&#39;])</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 # domain does not support sched-rtpartition?</div><div>main.p=
y:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&=
#39;)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 result =
=3D server.xend.domain.sched_rtpartition_set(domid, period, budget, vcpu, e=
xtra)</div><div>main.py: =C2=A0 =C2=A0# &quot;sched-rtpartition&quot;: xm_s=
ched_rtpartition,</div><div>grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=
=AE=E5=BD=95</div></div><div><br></div><div><br></div><div><br></div><div><=
br></div><div><br></div><div>my question is how to make xl can changed &quo=
t;sched-rm&quot; =C2=A0parameters?</div><div><br><br></div><div><br></div><=
div><br></div><div>jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen=
_2.0$ xl</div><div>Usage xl [-vfN] &lt;subcommand&gt; [args]</div><div><br>=
</div><div>xl full list of subcommands:</div><div><br></div><div>=C2=A0crea=
te =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Create a domain from con=
fig file &lt;filename&gt;</div><div>=C2=A0config-update =C2=A0 =C2=A0 =C2=
=A0 Update a running domain&#39;s saved configuration, used when rebuilding=
 the domain after reboot</div><div>=C2=A0list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0List information about all/some domains</div><di=
v>=C2=A0destroy =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Terminate a domai=
n immediately</div><div>=C2=A0shutdown =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Issue a shutdown signal to a domain</div><div>=C2=A0reboot =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Issue a reboot signal to a domain</di=
v><div>=C2=A0pci-attach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Insert a new pass=
-through pci device</div><div>=C2=A0pci-detach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Remove a domain&#39;s pass-through pci device</div><div>=C2=A0pci-lis=
t =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0List pass-through pci devices fo=
r a domain</div><div>=C2=A0pci-assignable-add =C2=A0Make a device assignabl=
e for pci-passthru</div><div>=C2=A0pci-assignable-remove=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=
=A0Remove a device from being assignable</div><div>=C2=A0pci-assignable-lis=
t List all the assignable pci devices</div><div>=C2=A0pause =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pause execution of a domain</div><div>=
=C2=A0unpause =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unpause a paused do=
main</div><div>=C2=A0console =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Atta=
ch to domain&#39;s console</div><div>=C2=A0vncviewer =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 Attach to domain&#39;s VNC server.</div><div>=C2=A0save =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Save a domain state to =
restore later</div><div>=C2=A0migrate =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 Migrate a domain to another host</div><div>=C2=A0dump-core =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Core dump a domain</div><div>=C2=A0restore =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Restore a domain from a saved state<=
/div><div>=C2=A0migrate-receive =C2=A0 =C2=A0 Restore a domain from a saved=
 state</div><div>=C2=A0cd-insert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Insert =
a cdrom into a guest&#39;s cd drive</div><div>=C2=A0cd-eject =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Eject a cdrom from a guest&#39;s cd drive</div><=
div>=C2=A0mem-max =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Set the maximum=
 amount reservation for a domain</div><div>=C2=A0mem-set =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 Set the current memory usage for a domain</div><di=
v>=C2=A0button-press =C2=A0 =C2=A0 =C2=A0 =C2=A0Indicate an ACPI button pre=
ss to the domain</div><div>=C2=A0vcpu-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 List the VCPUs for all/some domains</div><div>=C2=A0vcpu-pin =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Set which CPUs a VCPU can use</div><div>=C2=
=A0vcpu-set =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Set the number of acti=
ve VCPUs allowed for the domain</div><div>=C2=A0vm-list =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 List guest domains, excluding dom0, stubdoms, etc.=
</div><div>=C2=A0info =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Get information about Xen host</div><div>=C2=A0sharing =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 Get information about page sharing</div><div>=C2=
=A0sched-credit =C2=A0 =C2=A0 =C2=A0 =C2=A0Get/set credit scheduler paramet=
ers</div><div>=C2=A0sched-credit2 =C2=A0 =C2=A0 =C2=A0 Get/set credit2 sche=
duler parameters</div><div>=C2=A0sched-rtglobal =C2=A0 =C2=A0 =C2=A0Get/set=
 rtglobal scheduler parameters</div><div>=C2=A0sched-rtpartition =C2=A0 Get=
/set rtpartition scheduler parameters</div></div></div><div>=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D&lt;&gt;&lt;&gt;&lt;&gt; =C2=A0&gt;&gt;&gt; here shoul=
d be &quot;sched-rm&quot; =C2=A0but not show. =C2=A0&gt;&gt;&gt;&gt; it the=
 my question.</div><span><div><br></div><div><br></div><div><div><div dir=
=3D"ltr"><div><div><br><br><br><br><br><br>=C2=A0Best regards<br>Jie Shen <=
br><br><br></div>Graduate Student in Computer Science<br></div>Illinois Ins=
titute of Technology=C2=A0=C2=A0=C2=A0 <br>Stuart Building=C2=A0 Chicago, I=
L 60616<br><a href=3D"tel:%2B1%C2%A0%20312%20404%200122" value=3D"+13124040=
122" target=3D"_blank">+1=C2=A0 312 404 0122</a><br><div><br></div></div></=
div></div>
</span></div>
</div></div>
</blockquote></div></div></div></div>
</blockquote></div></div>

--047d7b2e0d496d9572050a3c6e7b--


--===============1718337007820827120==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1718337007820827120==--


From xen-devel-bounces@lists.xen.org Mon Dec 15 07:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 07: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 1Y0QXS-0007ku-2K; Mon, 15 Dec 2014 07:57:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jshen25@hawk.iit.edu>) id 1Y0QLq-0007ab-Fi
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 07:45:54 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	24/63-15461-1B19E845; Mon, 15 Dec 2014 07:45:53 +0000
X-Env-Sender: jshen25@hawk.iit.edu
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418629550!15548742!1
X-Originating-IP: [209.85.192.179]
X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26920 invoked from network); 15 Dec 2014 07:45:52 -0000
Received: from mail-pd0-f179.google.com (HELO mail-pd0-f179.google.com)
	(209.85.192.179)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 07:45:52 -0000
Received: by mail-pd0-f179.google.com with SMTP id fp1so11230392pdb.10
	for <xen-devel@lists.xen.org>; Sun, 14 Dec 2014 23:45: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=FxhERLRfILluinB3/RQ7QLKTOOp2rzMfr5UfCvkhXtQ=;
	b=JodLXPWTAxIcNPL+8TUBioLZozIVN/DA9+WMBJRr/uh6rrelE3A2VhBTrIHBrgC4wq
	K0gfNUZJXpKQLHWzuMt0tXTq+0sZGyx5F7SXSvJpjgQoOAQSeFWeQlTOR/WfwXY94MXN
	xa/WvDSShI/EcXp6mMRz8cIElw2RcyY/b8z+o45TgvErWFP4ShOyrggytgwTlXIf2QLE
	hZEfpSrJMNvhJTRvBqdL5XlHmh7JRiyzMJX+cWgEcLd4C481+fcKB185CthoZR6xIn17
	AxS71W3I0Bnf9DFy5cB7LPPqaXeod6DdT6zXELj2tSiyfdSmCgUVI/4NLWYKMc3Gp/uK
	lmcA==
X-Gm-Message-State: ALoCoQkSADBHcctJnQd5/e/4X8M2ctngBGnlo6fpswdNDjNjTox1pl20jZsORuYq39F38A4ciUay
MIME-Version: 1.0
X-Received: by 10.67.13.12 with SMTP id eu12mr49193349pad.157.1418629550537;
	Sun, 14 Dec 2014 23:45:50 -0800 (PST)
Received: by 10.70.43.74 with HTTP; Sun, 14 Dec 2014 23:45:50 -0800 (PST)
In-Reply-To: <CADUQMejvxaQkBr=FzoyN8yG12CTmpDKzuF4bX+0pYr9hK9_RUg@mail.gmail.com>
References: <CADUQMegeBg2dVXptjo7w+dU5CkTs5gUrM=6HbCuj3NftD05oDA@mail.gmail.com>
	<CADUQMehGUdNXjsvLAKXXwRDDfJMLdbQw6xHk2rMYAFzyUTtaGQ@mail.gmail.com>
	<CADUQMejvxaQkBr=FzoyN8yG12CTmpDKzuF4bX+0pYr9hK9_RUg@mail.gmail.com>
Date: Mon, 15 Dec 2014 01:45:50 -0600
Message-ID: <CADUQMejBN9Uz+=gMNVeGGdGYHSMfs6vwV5zjQLnhxmVvsrqvtg@mail.gmail.com>
From: Jie Shen <jshen25@hawk.iit.edu>
To: xen-devel@lists.xen.org, 
	"rtxen-devel@googlegroups.com" <rtxen-devel@googlegroups.com>,
	Xiayu Hua <xiayuhuahxy@gmail.com>
X-Mailman-Approved-At: Mon, 15 Dec 2014 07:57:51 +0000
Subject: Re: [Xen-devel] rt-xen::make Done::xl :: sched-rm not shown:: how
 to add a command line in xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1718337007820827120=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1718337007820827120==
Content-Type: multipart/alternative; boundary=047d7b2e0d496d9572050a3c6e7b

--047d7b2e0d496d9572050a3c6e7b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

resolved !!!!
thanks any way!

info                Get information about Xen host
 sharing             Get information about page sharing
 sched-credit        Get/set credit scheduler parameters
 sched-credit2       Get/set credit2 scheduler parameters
 sched-rtglobal      Get/set rtglobal scheduler parameters
 sched-rtpartition   Get/set rtpartition scheduler parameters
 sched-rm            Get/set rm scheduler parameters
   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> showing.....
 sched-sedf          Get/set sedf scheduler parameters
 domid               Convert a domain name to domain id
 domname             Convert a domain id to domain name
 rename              Rename a domain








 Best regards
Jie Shen


Graduate Student in Computer Science
Illinois Institute of Technology
Stuart Building  Chicago, IL 60616
+1  312 404 0122


On Mon, Dec 15, 2014 at 1:40 AM, Jie Shen <jshen25@hawk.iit.edu> wrote:
>
> Hello Gurus,
> should be the two files :
>
> xl_cmdimpl.c
> xl_cmdtable.c?
>
>
>
>
>
>
>
>
>
>  Best regards
> Jie Shen
>
>
> Graduate Student in Computer Science
> Illinois Institute of Technology
> Stuart Building  Chicago, IL 60616
> +1  312 404 0122
>
>
> On Mon, Dec 15, 2014 at 12:56 AM, Jie Shen <jshen25@hawk.iit.edu> wrote:
>>
>>
>> Hello Gurus ,
>> Sorry to bother your again.
>>
>> Now Make is Done.
>>
>> Many errors are resolved ( such as some programming errors on xenbus.c
>> ,fbfront.c)
>>
>>
>> now I can use xl ,unfortunately, xl no option sched-rm.
>>
>> I changed the source of :
>>
>> libxl.c   =3D=3D>  output from grep:
>>
>> libxl.c:static int sched_rm_domain_get(libxl__gc *gc, uint32_t domid,
>> libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
>> libxl.c:static int sched_rm_domain_set(libxl__gc *gc, uint32_t domid,
>> libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
>> libxl.c:    rc =3D xc_sched_rm_domain_set(CTX->xch, domid, &sdom);
>> libxl.c:        ret=3Dsched_rm_domain_set(gc, domid, scinfo);
>> libxl.c: ret=3Dsched_rm_domain_get(gc,domid,scinfo);
>>
>>
>> and :
>> xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_set(XcObject
>> *self,
>> xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
>> xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_set(self->xc_handle,
>> domid, &sdom) !=3D 0 )
>> xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_get(XcObject
>> *self, PyObject *args)
>> xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
>> xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_get(self->xc_handle,
>> domid, &sdom) !=3D 0 )
>> xen/lowlevel/xc/xc.c:   { "sched_rm_domain_set",
>> xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_set,
>> xen/lowlevel/xc/xc.c:     { "sched_rm_domain_get",
>> xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_get,
>>
>>
>> also created :
>> libxc/xc_rm.c  =3D=3D=3D> just like libxc/xc_rtpartition.c
>>
>>
>>
>> not changing main.py:
>>
>> since I see it is commtented::
>>
>>
>> main.py:    'sched-rtpartition': ('[-d <Domain>
>> [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=3DEXTRA]]',
>> main.py:                     'Get/set rtpartition scheduler parameters.'=
),
>> main.py:    'sched-rtpartition': (
>> main.py:    "sched-rtpartition",
>> main.py:# # rtpartition
>> main.py:# def xm_sched_rtpartition(args):
>> main.py:#     """Get/Set options for rtpartition Scheduler."""
>> main.py:#     check_sched_type('rtpartition')
>> main.py:#         usage('sched-rtpartition')
>> main.py:#             usage('sched-rtpartition')
>> main.py:#                     info =3D
>> server.xend.domain.sched_rtpartition_get(d['name'])
>> main.py:#                 # domain does not support sched-rtpartition?
>> main.py:#             usage('sched-rtpartition')
>> main.py:#             result =3D
>> server.xend.domain.sched_rtpartition_set(domid, period, budget, vcpu, ex=
tra)
>> main.py:    # "sched-rtpartition": xm_sched_rtpartition,
>> grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=95
>>
>>
>>
>>
>>
>> my question is how to make xl can changed "sched-rm"  parameters?
>>
>>
>>
>>
>> jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl
>> Usage xl [-vfN] <subcommand> [args]
>>
>> xl full list of subcommands:
>>
>>  create              Create a domain from config file <filename>
>>  config-update       Update a running domain's saved configuration, used
>> when rebuilding the domain after reboot
>>  list                List information about all/some domains
>>  destroy             Terminate a domain immediately
>>  shutdown            Issue a shutdown signal to a domain
>>  reboot              Issue a reboot signal to a domain
>>  pci-attach          Insert a new pass-through pci device
>>  pci-detach          Remove a domain's pass-through pci device
>>  pci-list            List pass-through pci devices for a domain
>>  pci-assignable-add  Make a device assignable for pci-passthru
>>  pci-assignable-remove
>>                      Remove a device from being assignable
>>  pci-assignable-list List all the assignable pci devices
>>  pause               Pause execution of a domain
>>  unpause             Unpause a paused domain
>>  console             Attach to domain's console
>>  vncviewer           Attach to domain's VNC server.
>>  save                Save a domain state to restore later
>>  migrate             Migrate a domain to another host
>>  dump-core           Core dump a domain
>>  restore             Restore a domain from a saved state
>>  migrate-receive     Restore a domain from a saved state
>>  cd-insert           Insert a cdrom into a guest's cd drive
>>  cd-eject            Eject a cdrom from a guest's cd drive
>>  mem-max             Set the maximum amount reservation for a domain
>>  mem-set             Set the current memory usage for a domain
>>  button-press        Indicate an ACPI button press to the domain
>>  vcpu-list           List the VCPUs for all/some domains
>>  vcpu-pin            Set which CPUs a VCPU can use
>>  vcpu-set            Set the number of active VCPUs allowed for the doma=
in
>>  vm-list             List guest domains, excluding dom0, stubdoms, etc.
>>  info                Get information about Xen host
>>  sharing             Get information about page sharing
>>  sched-credit        Get/set credit scheduler parameters
>>  sched-credit2       Get/set credit2 scheduler parameters
>>  sched-rtglobal      Get/set rtglobal scheduler parameters
>>  sched-rtpartition   Get/set rtpartition scheduler parameters
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<><><>  >>> here should be "sched-rm=
"  but not show.  >>>> it
>> the my question.
>>
>>
>>
>>
>>
>>
>>
>>
>>  Best regards
>> Jie Shen
>>
>>
>> Graduate Student in Computer Science
>> Illinois Institute of Technology
>> Stuart Building  Chicago, IL 60616
>> +1  312 404 0122
>>
>>

--047d7b2e0d496d9572050a3c6e7b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div>resolved !!!!<div>thanks any way!<br><div><=
br></div><div><div>info =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Get information about Xen host</div><div>=C2=A0sharing =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Get information about page sharing</div><div>=
=C2=A0sched-credit =C2=A0 =C2=A0 =C2=A0 =C2=A0Get/set credit scheduler para=
meters</div><div>=C2=A0sched-credit2 =C2=A0 =C2=A0 =C2=A0 Get/set credit2 s=
cheduler parameters</div><div>=C2=A0sched-rtglobal =C2=A0 =C2=A0 =C2=A0Get/=
set rtglobal scheduler parameters</div><div>=C2=A0sched-rtpartition =C2=A0 =
Get/set rtpartition scheduler parameters</div><div>=C2=A0sched-rm =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get/set rm scheduler parameters =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&gt; showing.....</div><div>=C2=A0s=
ched-sedf =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get/set sedf scheduler paramete=
rs</div><div>=C2=A0domid =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 C=
onvert a domain name to domain id</div><div>=C2=A0domname =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 Convert a domain id to domain name</div><div>=C2=
=A0rename =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rename a domain</=
div></div><div><br></div></div></div><div class=3D"gmail_extra"><br clear=
=3D"all"><div><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div><br=
><br><br><br><br><br>=C2=A0Best regards<br>Jie Shen <br><br><br></div>Gradu=
ate Student in Computer Science<br></div>Illinois Institute of Technology=
=C2=A0=C2=A0=C2=A0 <br>Stuart Building=C2=A0 Chicago, IL 60616<br>+1=C2=A0 =
312 404 0122<br><div><br></div></div></div></div>
<br><div class=3D"gmail_quote">On Mon, Dec 15, 2014 at 1:40 AM, Jie Shen <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:jshen25@hawk.iit.edu" target=3D"_blan=
k">jshen25@hawk.iit.edu</a>&gt;</span> wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Hello Gurus,<div>should be the two files :</div><div><br>=
</div><div>xl_cmdimpl.c</div><div>xl_cmdtable.c?</div><div><br></div><div><=
br></div></div><div class=3D"gmail_extra"><span class=3D""><br clear=3D"all=
"><div><div><div dir=3D"ltr"><div><div><br><br><br><br><br><br>=C2=A0Best r=
egards<br>Jie Shen <br><br><br></div>Graduate Student in Computer Science<b=
r></div>Illinois Institute of Technology=C2=A0=C2=A0=C2=A0 <br>Stuart Build=
ing=C2=A0 Chicago, IL 60616<br><a href=3D"tel:%2B1%C2%A0%20312%20404%200122=
" value=3D"+13124040122" target=3D"_blank">+1=C2=A0 312 404 0122</a><br><di=
v><br></div></div></div></div>
<br></span><div><div class=3D"h5"><div class=3D"gmail_quote">On Mon, Dec 15=
, 2014 at 12:56 AM, Jie Shen <span dir=3D"ltr">&lt;<a href=3D"mailto:jshen2=
5@hawk.iit.edu" target=3D"_blank">jshen25@hawk.iit.edu</a>&gt;</span> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"=
><br><div dir=3D"ltr"><div>Hello Gurus ,</div><div><div><div>Sorry to bothe=
r your again.<br></div><div><br></div><div>Now Make is Done.</div><div><br>=
</div><div>Many errors are resolved ( such as some programming errors on xe=
nbus.c ,fbfront.c)</div><div><br></div><div><br></div><div>now I can use xl=
 ,unfortunately, xl no option sched-rm.</div><div><br></div><div>I changed =
the source of :</div><div><br></div><div>libxl.c =C2=A0 =3D=3D&gt; =C2=A0ou=
tput from grep:</div><div><br></div><div><div>libxl.c:static int sched_rm_d=
omain_get(libxl__gc *gc, uint32_t domid,</div><div>libxl.c: =C2=A0 =C2=A0rc=
 =3D xc_sched_rm_domain_get(CTX-&gt;xch, domid, &amp;sdom);</div><div>libxl=
.c:static int sched_rm_domain_set(libxl__gc *gc, uint32_t domid,</div><div>=
libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_domain_get(CTX-&gt;xch, domid, &am=
p;sdom);</div><div>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_domain_set(CTX-=
&gt;xch, domid, &amp;sdom);</div><div>libxl.c: =C2=A0 =C2=A0 =C2=A0 =C2=A0r=
et=3Dsched_rm_domain_set(gc, domid, scinfo);</div><div>libxl.c:<span style=
=3D"white-space:pre-wrap">		</span>ret=3Dsched_rm_domain_get(gc,domid,scinf=
o);</div></div><div><br></div><div><br></div><div>and :</div><div><div>xen/=
lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_set(XcObject *self,<=
/div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0struct xen_domctl_sched_rm sdo=
m;</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_set=
(self-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</div><div>xen/lowlevel/xc/x=
c.c:static PyObject *pyxc_sched_rm_domain_get(XcObject *self, PyObject *arg=
s)</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0struct xen_domctl_sched_rm =
sdom;</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_=
get(self-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</div><div>xen/lowlevel/x=
c/xc.c: =C2=A0 { &quot;sched_rm_domain_set&quot;,</div><div>xen/lowlevel/xc=
/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_set,</div><div=
>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0 { &quot;sched_rm_domain_get&quot;,</di=
v><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm=
_domain_get,</div></div><div><br></div><div><br></div><div>also created :</=
div><div>libxc/xc_rm.c =C2=A0=3D=3D=3D&gt; just like=C2=A0libxc/xc_rtpartit=
ion.c<br></div><div><br></div><div><br></div><div><br></div><div>not changi=
ng main.py:</div><div><br></div><div>since I see it is commtented::</div><d=
iv><br></div><div><br></div><div><div>main.py: =C2=A0 =C2=A0&#39;sched-rtpa=
rtition&#39;: (&#39;[-d &lt;Domain&gt; [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DV=
CPU]|-e[=3DEXTRA]]&#39;,</div><div>main.py: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &#39;Get/set rtpartition scheduler p=
arameters.&#39;),</div><div>main.py: =C2=A0 =C2=A0&#39;sched-rtpartition&#3=
9;: (</div><div>main.py: =C2=A0 =C2=A0&quot;sched-rtpartition&quot;,</div><=
div>main.py:# # rtpartition</div><div>main.py:# def xm_sched_rtpartition(ar=
gs):</div><div>main.py:# =C2=A0 =C2=A0 &quot;&quot;&quot;Get/Set options fo=
r rtpartition Scheduler.&quot;&quot;&quot;</div><div>main.py:# =C2=A0 =C2=
=A0 check_sched_type(&#39;rtpartition&#39;)</div><div>main.py:# =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div><div>main.py:# =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;=
)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 info =3D server.xend.domain.sched_rtpartition_get(d[&#39;=
name&#39;])</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 # domain does not support sched-rtpartition?</div><div>main.p=
y:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&=
#39;)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 result =
=3D server.xend.domain.sched_rtpartition_set(domid, period, budget, vcpu, e=
xtra)</div><div>main.py: =C2=A0 =C2=A0# &quot;sched-rtpartition&quot;: xm_s=
ched_rtpartition,</div><div>grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=
=AE=E5=BD=95</div></div><div><br></div><div><br></div><div><br></div><div><=
br></div><div><br></div><div>my question is how to make xl can changed &quo=
t;sched-rm&quot; =C2=A0parameters?</div><div><br><br></div><div><br></div><=
div><br></div><div>jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen=
_2.0$ xl</div><div>Usage xl [-vfN] &lt;subcommand&gt; [args]</div><div><br>=
</div><div>xl full list of subcommands:</div><div><br></div><div>=C2=A0crea=
te =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Create a domain from con=
fig file &lt;filename&gt;</div><div>=C2=A0config-update =C2=A0 =C2=A0 =C2=
=A0 Update a running domain&#39;s saved configuration, used when rebuilding=
 the domain after reboot</div><div>=C2=A0list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0List information about all/some domains</div><di=
v>=C2=A0destroy =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Terminate a domai=
n immediately</div><div>=C2=A0shutdown =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Issue a shutdown signal to a domain</div><div>=C2=A0reboot =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Issue a reboot signal to a domain</di=
v><div>=C2=A0pci-attach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Insert a new pass=
-through pci device</div><div>=C2=A0pci-detach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Remove a domain&#39;s pass-through pci device</div><div>=C2=A0pci-lis=
t =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0List pass-through pci devices fo=
r a domain</div><div>=C2=A0pci-assignable-add =C2=A0Make a device assignabl=
e for pci-passthru</div><div>=C2=A0pci-assignable-remove=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=
=A0Remove a device from being assignable</div><div>=C2=A0pci-assignable-lis=
t List all the assignable pci devices</div><div>=C2=A0pause =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pause execution of a domain</div><div>=
=C2=A0unpause =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unpause a paused do=
main</div><div>=C2=A0console =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Atta=
ch to domain&#39;s console</div><div>=C2=A0vncviewer =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 Attach to domain&#39;s VNC server.</div><div>=C2=A0save =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Save a domain state to =
restore later</div><div>=C2=A0migrate =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 Migrate a domain to another host</div><div>=C2=A0dump-core =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Core dump a domain</div><div>=C2=A0restore =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Restore a domain from a saved state<=
/div><div>=C2=A0migrate-receive =C2=A0 =C2=A0 Restore a domain from a saved=
 state</div><div>=C2=A0cd-insert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Insert =
a cdrom into a guest&#39;s cd drive</div><div>=C2=A0cd-eject =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Eject a cdrom from a guest&#39;s cd drive</div><=
div>=C2=A0mem-max =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Set the maximum=
 amount reservation for a domain</div><div>=C2=A0mem-set =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 Set the current memory usage for a domain</div><di=
v>=C2=A0button-press =C2=A0 =C2=A0 =C2=A0 =C2=A0Indicate an ACPI button pre=
ss to the domain</div><div>=C2=A0vcpu-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 List the VCPUs for all/some domains</div><div>=C2=A0vcpu-pin =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Set which CPUs a VCPU can use</div><div>=C2=
=A0vcpu-set =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Set the number of acti=
ve VCPUs allowed for the domain</div><div>=C2=A0vm-list =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 List guest domains, excluding dom0, stubdoms, etc.=
</div><div>=C2=A0info =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Get information about Xen host</div><div>=C2=A0sharing =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 Get information about page sharing</div><div>=C2=
=A0sched-credit =C2=A0 =C2=A0 =C2=A0 =C2=A0Get/set credit scheduler paramet=
ers</div><div>=C2=A0sched-credit2 =C2=A0 =C2=A0 =C2=A0 Get/set credit2 sche=
duler parameters</div><div>=C2=A0sched-rtglobal =C2=A0 =C2=A0 =C2=A0Get/set=
 rtglobal scheduler parameters</div><div>=C2=A0sched-rtpartition =C2=A0 Get=
/set rtpartition scheduler parameters</div></div></div><div>=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D&lt;&gt;&lt;&gt;&lt;&gt; =C2=A0&gt;&gt;&gt; here shoul=
d be &quot;sched-rm&quot; =C2=A0but not show. =C2=A0&gt;&gt;&gt;&gt; it the=
 my question.</div><span><div><br></div><div><br></div><div><div><div dir=
=3D"ltr"><div><div><br><br><br><br><br><br>=C2=A0Best regards<br>Jie Shen <=
br><br><br></div>Graduate Student in Computer Science<br></div>Illinois Ins=
titute of Technology=C2=A0=C2=A0=C2=A0 <br>Stuart Building=C2=A0 Chicago, I=
L 60616<br><a href=3D"tel:%2B1%C2%A0%20312%20404%200122" value=3D"+13124040=
122" target=3D"_blank">+1=C2=A0 312 404 0122</a><br><div><br></div></div></=
div></div>
</span></div>
</div></div>
</blockquote></div></div></div></div>
</blockquote></div></div>

--047d7b2e0d496d9572050a3c6e7b--


--===============1718337007820827120==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1718337007820827120==--


From xen-devel-bounces@lists.xen.org Mon Dec 15 07:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 07: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 1Y0QXQ-0007kZ-W5; Mon, 15 Dec 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 <ba1020@homie.homelinux.net>) id 1XzivX-0006j8-Rj
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 09:23:51 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	1E/BF-31453-7A50C845; Sat, 13 Dec 2014 09:23:51 +0000
X-Env-Sender: ba1020@homie.homelinux.net
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418462630!13128346!1
X-Originating-IP: [87.81.139.118]
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 20076 invoked from network); 13 Dec 2014 09:23:50 -0000
Received: from 57518b76.skybroadband.com (HELO zimbra.homelinux.net)
	(87.81.139.118)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Dec 2014 09:23:50 -0000
Received: from localhost (ip6-localhost [IPv6:::1])
	by zimbra.homelinux.net (Postfix) with ESMTP id DE81320006D
	for <xen-devel@lists.xen.org>; Sat, 13 Dec 2014 09:23:49 +0000 (GMT)
Received: from zimbra.homelinux.net ([IPv6:::1])
	by localhost (zimbra.homelinux.net [IPv6:::1]) (amavisd-new, port 10032)
	with ESMTP id nxhPY4ykT8Jz for <xen-devel@lists.xen.org>;
	Sat, 13 Dec 2014 09:23:49 +0000 (GMT)
Received: from localhost (ip6-localhost [IPv6:::1])
	by zimbra.homelinux.net (Postfix) with ESMTP id 64CB5201130
	for <xen-devel@lists.xen.org>; Sat, 13 Dec 2014 09:23:49 +0000 (GMT)
X-Virus-Scanned: amavisd-new at zimbra.homelinux.net
Received: from zimbra.homelinux.net ([IPv6:::1])
	by localhost (zimbra.homelinux.net [IPv6:::1]) (amavisd-new, port 10026)
	with ESMTP id RLkuvUjoG3LJ for <xen-devel@lists.xen.org>;
	Sat, 13 Dec 2014 09:23:49 +0000 (GMT)
Received: from zimbra.homelinux.net (localhost [127.0.0.1])
	by zimbra.homelinux.net (Postfix) with ESMTP id 0F92B20006D
	for <xen-devel@lists.xen.org>; Sat, 13 Dec 2014 09:23:49 +0000 (GMT)
Date: Sat, 13 Dec 2014 09:23:48 +0000 (GMT)
From: Juergen Schinker <ba1020@homie.homelinux.net>
To: xen-devel@lists.xen.org
Message-ID: <1022891597.144.1418462628949.JavaMail.zimbra@homie.homelinux.net>
MIME-Version: 1.0
X-Originating-IP: [2001:470:6984:1:216:3eff:fe68:9940]
X-Mailer: Zimbra 8.5.1_GA_3056 (ZimbraWebClient - FF31 (Linux)/8.5.1_GA_3056)
Thread-Topic: Test report Xen 4.5.0-RC3
Thread-Index: Ybm14016h//wK7R75ZLRCGLOD5II8g==
X-Mailman-Approved-At: Mon, 15 Dec 2014 07:57:51 +0000
Subject: [Xen-devel] [TESTDAY] Test report  Xen 4.5.0-RC3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Subject: [TESTDAY] Test report Xen 4.5.0-RC3
 
* Hardware:
 Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz (4cores -1 socket)
 32G Ram

* Software:
  Debian Jessie

* Guest operating systems:
  Debian Jessie
* Functionality tested:
  xl
  pygrub

* Comments:

had to compile with
configure --enable-githttp --enable-systemd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 07:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 07: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 1Y0QXR-0007kn-Ml; Mon, 15 Dec 2014 07:57:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jshen25@hawk.iit.edu>) id 1Y0QGC-0007RL-P0
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 07:40:05 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	FC/67-28296-3509E845; Mon, 15 Dec 2014 07:40:03 +0000
X-Env-Sender: jshen25@hawk.iit.edu
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418629200!13356777!1
X-Originating-IP: [209.85.192.169]
X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24518 invoked from network); 15 Dec 2014 07:40:02 -0000
Received: from mail-pd0-f169.google.com (HELO mail-pd0-f169.google.com)
	(209.85.192.169)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 07:40:02 -0000
Received: by mail-pd0-f169.google.com with SMTP id z10so11179797pdj.14
	for <xen-devel@lists.xen.org>; Sun, 14 Dec 2014 23:40: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=IQKoESmzXtB9lyAqW/45WhagYcc7nkeWuOrHCQKD8uU=;
	b=VqvBu5R2TUXNUOykIPTnvcR8PbozsxTT2F48p/8UnGBz9ohppCMTb+rR2dqLPH7TtN
	S8ccVfahd6H6Zp6yiiwdjc9iJ2O4nSlyFCY6NCRZUOY/JVF8pi6m2m+nazxVe3d0nQsC
	qU8rrC7p2yxNMxtbIjH0i4jEC+khER5wNtg4bzeFOm1jIH8idU6f9HvcgvEQ/WX896PT
	KJx5mS3AJZhQfK9lDzlu76vchxe9qMiaXacWoNX13QUVMVS0TwjKoS37xFh4ykjqLC2W
	7BmqMfyRMpI8WeMqAHJqPiXs4kPRHrj3R/JDwOyslRSjbOX2Pu9BsfopfLL1OlVnHztH
	VIpg==
X-Gm-Message-State: ALoCoQnxN7H0jBI51M77F68Sdk4fIC+T1XX1xy8ygJBdoGZjArYDadTUMJ7gYVdQj9X4fzr93a1j
MIME-Version: 1.0
X-Received: by 10.68.232.104 with SMTP id tn8mr48724243pbc.31.1418629200249;
	Sun, 14 Dec 2014 23:40:00 -0800 (PST)
Received: by 10.70.43.74 with HTTP; Sun, 14 Dec 2014 23:40:00 -0800 (PST)
In-Reply-To: <CADUQMehGUdNXjsvLAKXXwRDDfJMLdbQw6xHk2rMYAFzyUTtaGQ@mail.gmail.com>
References: <CADUQMegeBg2dVXptjo7w+dU5CkTs5gUrM=6HbCuj3NftD05oDA@mail.gmail.com>
	<CADUQMehGUdNXjsvLAKXXwRDDfJMLdbQw6xHk2rMYAFzyUTtaGQ@mail.gmail.com>
Date: Mon, 15 Dec 2014 01:40:00 -0600
Message-ID: <CADUQMejvxaQkBr=FzoyN8yG12CTmpDKzuF4bX+0pYr9hK9_RUg@mail.gmail.com>
From: Jie Shen <jshen25@hawk.iit.edu>
To: xen-devel@lists.xen.org, 
	"rtxen-devel@googlegroups.com" <rtxen-devel@googlegroups.com>,
	Xiayu Hua <xiayuhuahxy@gmail.com>
X-Mailman-Approved-At: Mon, 15 Dec 2014 07:57:51 +0000
Subject: Re: [Xen-devel] rt-xen::make Done::xl :: sched-rm not shown:: how
 to add a command line in xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2109020785592066319=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2109020785592066319==
Content-Type: multipart/alternative; boundary=047d7b33d6088ca744050a3c59bc

--047d7b33d6088ca744050a3c59bc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Gurus,
should be the two files :

xl_cmdimpl.c
xl_cmdtable.c?









 Best regards
Jie Shen


Graduate Student in Computer Science
Illinois Institute of Technology
Stuart Building  Chicago, IL 60616
+1  312 404 0122


On Mon, Dec 15, 2014 at 12:56 AM, Jie Shen <jshen25@hawk.iit.edu> wrote:
>
>
> Hello Gurus ,
> Sorry to bother your again.
>
> Now Make is Done.
>
> Many errors are resolved ( such as some programming errors on xenbus.c
> ,fbfront.c)
>
>
> now I can use xl ,unfortunately, xl no option sched-rm.
>
> I changed the source of :
>
> libxl.c   =3D=3D>  output from grep:
>
> libxl.c:static int sched_rm_domain_get(libxl__gc *gc, uint32_t domid,
> libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
> libxl.c:static int sched_rm_domain_set(libxl__gc *gc, uint32_t domid,
> libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
> libxl.c:    rc =3D xc_sched_rm_domain_set(CTX->xch, domid, &sdom);
> libxl.c:        ret=3Dsched_rm_domain_set(gc, domid, scinfo);
> libxl.c: ret=3Dsched_rm_domain_get(gc,domid,scinfo);
>
>
> and :
> xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_set(XcObject
> *self,
> xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
> xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_set(self->xc_handle,
> domid, &sdom) !=3D 0 )
> xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_get(XcObject
> *self, PyObject *args)
> xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
> xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_get(self->xc_handle,
> domid, &sdom) !=3D 0 )
> xen/lowlevel/xc/xc.c:   { "sched_rm_domain_set",
> xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_set,
> xen/lowlevel/xc/xc.c:     { "sched_rm_domain_get",
> xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_get,
>
>
> also created :
> libxc/xc_rm.c  =3D=3D=3D> just like libxc/xc_rtpartition.c
>
>
>
> not changing main.py:
>
> since I see it is commtented::
>
>
> main.py:    'sched-rtpartition': ('[-d <Domain>
> [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=3DEXTRA]]',
> main.py:                     'Get/set rtpartition scheduler parameters.')=
,
> main.py:    'sched-rtpartition': (
> main.py:    "sched-rtpartition",
> main.py:# # rtpartition
> main.py:# def xm_sched_rtpartition(args):
> main.py:#     """Get/Set options for rtpartition Scheduler."""
> main.py:#     check_sched_type('rtpartition')
> main.py:#         usage('sched-rtpartition')
> main.py:#             usage('sched-rtpartition')
> main.py:#                     info =3D
> server.xend.domain.sched_rtpartition_get(d['name'])
> main.py:#                 # domain does not support sched-rtpartition?
> main.py:#             usage('sched-rtpartition')
> main.py:#             result =3D
> server.xend.domain.sched_rtpartition_set(domid, period, budget, vcpu, ext=
ra)
> main.py:    # "sched-rtpartition": xm_sched_rtpartition,
> grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=95
>
>
>
>
>
> my question is how to make xl can changed "sched-rm"  parameters?
>
>
>
>
> jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl
> Usage xl [-vfN] <subcommand> [args]
>
> xl full list of subcommands:
>
>  create              Create a domain from config file <filename>
>  config-update       Update a running domain's saved configuration, used
> when rebuilding the domain after reboot
>  list                List information about all/some domains
>  destroy             Terminate a domain immediately
>  shutdown            Issue a shutdown signal to a domain
>  reboot              Issue a reboot signal to a domain
>  pci-attach          Insert a new pass-through pci device
>  pci-detach          Remove a domain's pass-through pci device
>  pci-list            List pass-through pci devices for a domain
>  pci-assignable-add  Make a device assignable for pci-passthru
>  pci-assignable-remove
>                      Remove a device from being assignable
>  pci-assignable-list List all the assignable pci devices
>  pause               Pause execution of a domain
>  unpause             Unpause a paused domain
>  console             Attach to domain's console
>  vncviewer           Attach to domain's VNC server.
>  save                Save a domain state to restore later
>  migrate             Migrate a domain to another host
>  dump-core           Core dump a domain
>  restore             Restore a domain from a saved state
>  migrate-receive     Restore a domain from a saved state
>  cd-insert           Insert a cdrom into a guest's cd drive
>  cd-eject            Eject a cdrom from a guest's cd drive
>  mem-max             Set the maximum amount reservation for a domain
>  mem-set             Set the current memory usage for a domain
>  button-press        Indicate an ACPI button press to the domain
>  vcpu-list           List the VCPUs for all/some domains
>  vcpu-pin            Set which CPUs a VCPU can use
>  vcpu-set            Set the number of active VCPUs allowed for the domai=
n
>  vm-list             List guest domains, excluding dom0, stubdoms, etc.
>  info                Get information about Xen host
>  sharing             Get information about page sharing
>  sched-credit        Get/set credit scheduler parameters
>  sched-credit2       Get/set credit2 scheduler parameters
>  sched-rtglobal      Get/set rtglobal scheduler parameters
>  sched-rtpartition   Get/set rtpartition scheduler parameters
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<><><>  >>> here should be "sched-rm"=
  but not show.  >>>> it
> the my question.
>
>
>
>
>
>
>
>
>  Best regards
> Jie Shen
>
>
> Graduate Student in Computer Science
> Illinois Institute of Technology
> Stuart Building  Chicago, IL 60616
> +1  312 404 0122
>
>

--047d7b33d6088ca744050a3c59bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello Gurus,<div>should be the two files :</div><div><br><=
/div><div>xl_cmdimpl.c</div><div>xl_cmdtable.c?</div><div><br></div><div><b=
r></div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div><div><br><br><br><br><br><br>=C2=
=A0Best regards<br>Jie Shen <br><br><br></div>Graduate Student in Computer =
Science<br></div>Illinois Institute of Technology=C2=A0=C2=A0=C2=A0 <br>Stu=
art Building=C2=A0 Chicago, IL 60616<br>+1=C2=A0 312 404 0122<br><div><br><=
/div></div></div></div>
<br><div class=3D"gmail_quote">On Mon, Dec 15, 2014 at 12:56 AM, Jie Shen <=
span dir=3D"ltr">&lt;<a href=3D"mailto:jshen25@hawk.iit.edu" target=3D"_bla=
nk">jshen25@hawk.iit.edu</a>&gt;</span> wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_quote"><br><div dir=3D"ltr"><div>Hel=
lo Gurus ,</div><div><div class=3D"h5"><div>Sorry to bother your again.<br>=
</div><div><br></div><div>Now Make is Done.</div><div><br></div><div>Many e=
rrors are resolved ( such as some programming errors on xenbus.c ,fbfront.c=
)</div><div><br></div><div><br></div><div>now I can use xl ,unfortunately, =
xl no option sched-rm.</div><div><br></div><div>I changed the source of :</=
div><div><br></div><div>libxl.c =C2=A0 =3D=3D&gt; =C2=A0output from grep:</=
div><div><br></div><div><div>libxl.c:static int sched_rm_domain_get(libxl__=
gc *gc, uint32_t domid,</div><div>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_=
domain_get(CTX-&gt;xch, domid, &amp;sdom);</div><div>libxl.c:static int sch=
ed_rm_domain_set(libxl__gc *gc, uint32_t domid,</div><div>libxl.c: =C2=A0 =
=C2=A0rc =3D xc_sched_rm_domain_get(CTX-&gt;xch, domid, &amp;sdom);</div><d=
iv>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_domain_set(CTX-&gt;xch, domid, =
&amp;sdom);</div><div>libxl.c: =C2=A0 =C2=A0 =C2=A0 =C2=A0ret=3Dsched_rm_do=
main_set(gc, domid, scinfo);</div><div>libxl.c:<span style=3D"white-space:p=
re-wrap">		</span>ret=3Dsched_rm_domain_get(gc,domid,scinfo);</div></div><d=
iv><br></div><div><br></div><div>and :</div><div><div>xen/lowlevel/xc/xc.c:=
static PyObject *pyxc_sched_rm_domain_set(XcObject *self,</div><div>xen/low=
level/xc/xc.c: =C2=A0 =C2=A0struct xen_domctl_sched_rm sdom;</div><div>xen/=
lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_set(self-&gt;xc_hand=
le, domid, &amp;sdom) !=3D 0 )</div><div>xen/lowlevel/xc/xc.c:static PyObje=
ct *pyxc_sched_rm_domain_get(XcObject *self, PyObject *args)</div><div>xen/=
lowlevel/xc/xc.c: =C2=A0 =C2=A0struct xen_domctl_sched_rm sdom;</div><div>x=
en/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_get(self-&gt;xc_h=
andle, domid, &amp;sdom) !=3D 0 )</div><div>xen/lowlevel/xc/xc.c: =C2=A0 { =
&quot;sched_rm_domain_set&quot;,</div><div>xen/lowlevel/xc/xc.c: =C2=A0 =C2=
=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_set,</div><div>xen/lowlevel/xc/=
xc.c: =C2=A0 =C2=A0 { &quot;sched_rm_domain_get&quot;,</div><div>xen/lowlev=
el/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_get,</div=
></div><div><br></div><div><br></div><div>also created :</div><div>libxc/xc=
_rm.c =C2=A0=3D=3D=3D&gt; just like=C2=A0libxc/xc_rtpartition.c<br></div><d=
iv><br></div><div><br></div><div><br></div><div>not changing main.py:</div>=
<div><br></div><div>since I see it is commtented::</div><div><br></div><div=
><br></div><div><div>main.py: =C2=A0 =C2=A0&#39;sched-rtpartition&#39;: (&#=
39;[-d &lt;Domain&gt; [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=3DEXTRA]=
]&#39;,</div><div>main.py: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 &#39;Get/set rtpartition scheduler parameters.&#39;),=
</div><div>main.py: =C2=A0 =C2=A0&#39;sched-rtpartition&#39;: (</div><div>m=
ain.py: =C2=A0 =C2=A0&quot;sched-rtpartition&quot;,</div><div>main.py:# # r=
tpartition</div><div>main.py:# def xm_sched_rtpartition(args):</div><div>ma=
in.py:# =C2=A0 =C2=A0 &quot;&quot;&quot;Get/Set options for rtpartition Sch=
eduler.&quot;&quot;&quot;</div><div>main.py:# =C2=A0 =C2=A0 check_sched_typ=
e(&#39;rtpartition&#39;)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 us=
age(&#39;sched-rtpartition&#39;)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div><div>main.py:#=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 info=
 =3D server.xend.domain.sched_rtpartition_get(d[&#39;name&#39;])</div><div>=
main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # domain =
does not support sched-rtpartition?</div><div>main.py:# =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div><div>main.=
py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 result =3D server.xend.domai=
n.sched_rtpartition_set(domid, period, budget, vcpu, extra)</div><div>main.=
py: =C2=A0 =C2=A0# &quot;sched-rtpartition&quot;: xm_sched_rtpartition,</di=
v><div>grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=95</div></di=
v><div><br></div><div><br></div><div><br></div><div><br></div><div><br></di=
v><div>my question is how to make xl can changed &quot;sched-rm&quot; =C2=
=A0parameters?</div><div><br><br></div><div><br></div><div><br></div><div>j=
ackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl</div><div>U=
sage xl [-vfN] &lt;subcommand&gt; [args]</div><div><br></div><div>xl full l=
ist of subcommands:</div><div><br></div><div>=C2=A0create =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Create a domain from config file &lt;filenam=
e&gt;</div><div>=C2=A0config-update =C2=A0 =C2=A0 =C2=A0 Update a running d=
omain&#39;s saved configuration, used when rebuilding the domain after rebo=
ot</div><div>=C2=A0list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0List information about all/some domains</div><div>=C2=A0destroy =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Terminate a domain immediately</div>=
<div>=C2=A0shutdown =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Issue a shutdo=
wn signal to a domain</div><div>=C2=A0reboot =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Issue a reboot signal to a domain</div><div>=C2=A0pci-a=
ttach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Insert a new pass-through pci devic=
e</div><div>=C2=A0pci-detach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Remove a dom=
ain&#39;s pass-through pci device</div><div>=C2=A0pci-list =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0List pass-through pci devices for a domain</div>=
<div>=C2=A0pci-assignable-add =C2=A0Make a device assignable for pci-passth=
ru</div><div>=C2=A0pci-assignable-remove=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=A0Remove a device =
from being assignable</div><div>=C2=A0pci-assignable-list List all the assi=
gnable pci devices</div><div>=C2=A0pause =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 Pause execution of a domain</div><div>=C2=A0unpause =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unpause a paused domain</div><div>=C2=A0=
console =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Attach to domain&#39;s co=
nsole</div><div>=C2=A0vncviewer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Attach t=
o domain&#39;s VNC server.</div><div>=C2=A0save =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0Save a domain state to restore later</div><div>=
=C2=A0migrate =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Migrate a domain to=
 another host</div><div>=C2=A0dump-core =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
Core dump a domain</div><div>=C2=A0restore =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Restore a domain from a saved state</div><div>=C2=A0migrate-rece=
ive =C2=A0 =C2=A0 Restore a domain from a saved state</div><div>=C2=A0cd-in=
sert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Insert a cdrom into a guest&#39;s c=
d drive</div><div>=C2=A0cd-eject =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E=
ject a cdrom from a guest&#39;s cd drive</div><div>=C2=A0mem-max =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Set the maximum amount reservation for a do=
main</div><div>=C2=A0mem-set =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Set =
the current memory usage for a domain</div><div>=C2=A0button-press =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Indicate an ACPI button press to the domain</div><div>=
=C2=A0vcpu-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 List the VCPUs for all/s=
ome domains</div><div>=C2=A0vcpu-pin =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Set which CPUs a VCPU can use</div><div>=C2=A0vcpu-set =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Set the number of active VCPUs allowed for the doma=
in</div><div>=C2=A0vm-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 List g=
uest domains, excluding dom0, stubdoms, etc.</div><div>=C2=A0info =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get information about Xen h=
ost</div><div>=C2=A0sharing =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Get i=
nformation about page sharing</div><div>=C2=A0sched-credit =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Get/set credit scheduler parameters</div><div>=C2=A0sched-cred=
it2 =C2=A0 =C2=A0 =C2=A0 Get/set credit2 scheduler parameters</div><div>=C2=
=A0sched-rtglobal =C2=A0 =C2=A0 =C2=A0Get/set rtglobal scheduler parameters=
</div><div>=C2=A0sched-rtpartition =C2=A0 Get/set rtpartition scheduler par=
ameters</div></div></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&lt;&gt;&=
lt;&gt;&lt;&gt; =C2=A0&gt;&gt;&gt; here should be &quot;sched-rm&quot; =C2=
=A0but not show. =C2=A0&gt;&gt;&gt;&gt; it the my question.</div><span clas=
s=3D""><div><br></div><div><br></div><div><div><div dir=3D"ltr"><div><div><=
br><br><br><br><br><br>=C2=A0Best regards<br>Jie Shen <br><br><br></div>Gra=
duate Student in Computer Science<br></div>Illinois Institute of Technology=
=C2=A0=C2=A0=C2=A0 <br>Stuart Building=C2=A0 Chicago, IL 60616<br><a href=
=3D"tel:%2B1%C2%A0%20312%20404%200122" value=3D"+13124040122" target=3D"_bl=
ank">+1=C2=A0 312 404 0122</a><br><div><br></div></div></div></div>
</span></div>
</div></div>
</blockquote></div></div>

--047d7b33d6088ca744050a3c59bc--


--===============2109020785592066319==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2109020785592066319==--


From xen-devel-bounces@lists.xen.org Mon Dec 15 07:58:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 07: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 1Y0QXQ-0007kS-KZ; Mon, 15 Dec 2014 07:57:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jshen25@hawk.iit.edu>) id 1Xzi2J-0005a5-Vw
	for xen-devel@lists.xen.org; Sat, 13 Dec 2014 08:26:48 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	98/1B-15461-748FB845; Sat, 13 Dec 2014 08:26:47 +0000
X-Env-Sender: jshen25@hawk.iit.edu
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418459204!15349397!1
X-Originating-IP: [209.85.220.41]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25840 invoked from network); 13 Dec 2014 08:26:45 -0000
Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com)
	(209.85.220.41)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Dec 2014 08:26:45 -0000
Received: by mail-pa0-f41.google.com with SMTP id rd3so8744299pab.0
	for <xen-devel@lists.xen.org>; Sat, 13 Dec 2014 00:26: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:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=cmbQyokAqviUpvHV701/iAkdS1QOXl0efco77itKWFc=;
	b=kp0DTce3faHqU9ru8nfJ5azSePQLcJJF7fV4kACn+MnE0TP3odCtTzzTwGajp2BHib
	nqdgyTU7NNni/9Fh4DBWW0SU8GJmqv7E5QqoD2NvOPX7/yiwXZFBAVvzJ83ZePEXCVkv
	/NmMMm/z4+LWTx5vephhu9lWW+r6MlMUvNE7y4MECxPRhVQpdQI/B0z9dsS3hb+2oscj
	H1ji91H6ZWTTHTwUdRfJUXRuTNLIT7WEH+CXWPaGpVdepzztrKMNiR4tH5C6bRlosa6P
	C3rBsN/cHdksorMAjBlmInbNdgXqxXo7/dnCo9PPOGIjQHC6V1MvxCJF5v8gmJOOLviC
	sv4w==
X-Gm-Message-State: ALoCoQkrW6V4m3Ge0ymDiBrPzmFnAmj2YGL0Ha8Ytf+HoQCbHV0F78pQN1WqR+Vi+iX9xaohSqEs
MIME-Version: 1.0
X-Received: by 10.70.88.164 with SMTP id bh4mr33495789pdb.96.1418459204268;
	Sat, 13 Dec 2014 00:26:44 -0800 (PST)
Received: by 10.70.43.74 with HTTP; Sat, 13 Dec 2014 00:26:44 -0800 (PST)
Date: Sat, 13 Dec 2014 02:26:44 -0600
Message-ID: <CADUQMei4ssFXs-fq83QrcpSu5pw8Xq_dtmY0=NwLywy4MNd8ng@mail.gmail.com>
From: Jie Shen <jshen25@hawk.iit.edu>
To: "rtxen-devel@googlegroups.com" <rtxen-devel@googlegroups.com>,
	xen-devel@lists.xen.org, 
	mengxu@seas.upenn.edu, Xiayu Hua <xiayuhuahxy@gmail.com>
X-Mailman-Approved-At: Mon, 15 Dec 2014 07:57:51 +0000
Subject: [Xen-devel] XEN::SCHEDULER::libxl.c::make install error
 ::libxenlight.so: undefined reference to `xc_sched_rm_domain_set'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3474216860565391377=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3474216860565391377==
Content-Type: multipart/alternative; boundary=001a11c321ceffd2f8050a14c483

--001a11c321ceffd2f8050a14c483
Content-Type: text/plain; charset=UTF-8

Hello Gurus,
I am adding a new rm scheduler to the rt-xen,
unfortunately I met "undefined reference to " error ,the output is below:

================error output begin==============


ln -sf libxenlight.so.4.3.0 libxenlight.so.4.3
ln -sf libxenlight.so.4.3 libxenlight.so
gcc    -pthread -o xl xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o libxlutil.so
/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so
-Wl,-rpath-link=/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxc
-Wl,-rpath-link=/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/xenstore
-Wl,-rpath-link=/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/blktap2/control
/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxc/libxenctrl.so
-lyajl
/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so:
undefined reference to `xc_sched_rm_domain_get'
/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so:
undefined reference to `xc_sched_rm_domain_set'
collect2: error: ld returned 1 exit status
make[3]: *** [xl] Error 1
make[3]: Leaving directory
`/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl'
make[2]: *** [subdir-install-libxl] Error 2
make[2]: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools'
make: *** [install-tools] Error 2

=============== error output end ===================


I searched all the folder ,it should be defined in the file :(reference
rtpartion)


==================== grep for rm===============
jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ grep -r
 xc_sched_rm_domain_set
dist/install/usr/local/include/xenctrl.h~:int
xc_sched_rm_domain_set(xc_interface *xch,
dist/install/usr/local/include/xenctrl.h:int
xc_sched_rm_domain_set(xc_interface *xch,
tools/libxc/xc_rm.c:xc_sched_rm_domain_set(
tools/libxc/xenctrl.h:int xc_sched_rm_domain_set(xc_interface *xch,
tools/libxl/libxl.c:    rc = xc_sched_rm_domain_set(CTX->xch, domid, &sdom);
Binary file tools/libxl/libxenlight.so.4.3.0 matches
Binary file tools/libxl/libxl.o matches
tools/python/xen/lowlevel/xc/xc.c:static PyObject
*pyxc_sched_rm_domain_set(XcObject *self,
tools/python/xen/lowlevel/xc/xc.c:    if (
xc_sched_rm_domain_set(self->xc_handle, domid, &sdom) != 0 )
tools/python/xen/lowlevel/xc/xc.c:
 (PyCFunction)pyxc_sched_rm_domain_set,

====================grep for rtpartion ============
jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ grep -r
 xc_sched_rtpartition_domain_set
dist/install/usr/local/include/xenctrl.h~:int
xc_sched_rtpartition_domain_set(xc_interface *xch,
dist/install/usr/local/include/xenctl.hbak:int
xc_sched_rtpartition_domain_set(xc_interface *xch,     ===>bakfile can be
ignored
dist/install/usr/local/include/xenctrl.h:int
xc_sched_rtpartition_domain_set(xc_interface *xch,
Binary file dist/install/usr/local/lib/libxenlight.so.4.3.0 matches
Binary file dist/install/usr/local/lib/libxenlight.a matches
Binary file dist/install/usr/local/lib/libxenctrl.so.4.3.0 matches
Binary file dist/install/usr/local/lib/libxenctrl.a matches
Binary file
dist/install/usr/local/lib/python2.7/dist-packages/xen/lowlevel/xc.so
matches
Binary file tools/libxc/libxenctrl.so.4.3.0 matches
Binary file tools/libxc/libxenctrl.a matches
Binary file tools/libxc/xc_rtpartition.o matches
tools/libxc/xc_rtpartition.c:xc_sched_rtpartition_domain_set(
Binary file tools/libxc/xc_rtpartition.opic matches
tools/libxc/xenctrl.h:int xc_sched_rtpartition_domain_set(xc_interface *xch,
tools/libxl/libxl.c:    rc = xc_sched_rtpartition_domain_set(CTX->xch,
domid, &sdom);
Binary file tools/libxl/libxenlight.so.4.3.0 matches
tools/libxl/libxl.cbak:    rc = xc_sched_rtpartition_domain_set(CTX->xch,
domid, &sdom);
Binary file tools/libxl/libxl.o matches
tools/libxl/libxl.cbak.20141211:    rc =
xc_sched_rtpartition_domain_set(CTX->xch, domid, &sdom);
tools/python/xen/lowlevel/xc/xc.c:static PyObject
*pyxc_sched_rtpartition_domain_set(XcObject *self,
tools/python/xen/lowlevel/xc/xc.c:    if (
xc_sched_rtpartition_domain_set(self->xc_handle, domid, &sdom) != 0 )
tools/python/xen/lowlevel/xc/xc.c:
 (PyCFunction)pyxc_sched_rtpartition_domain_set,
tools/python/xen/lowlevel/xc/xc.cbak:static PyObject
*pyxc_sched_rtpartition_domain_set(XcObject *self,
===>bakfile
tools/python/xen/lowlevel/xc/xc.cbak:    if (
xc_sched_rtpartition_domain_set(self->xc_handle, domid, &sdom) != 0 )
tools/python/xen/lowlevel/xc/xc.cbak:
 (PyCFunction)pyxc_sched_rtpartition_domain_set,
jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$



Could you please advice me where I need to define it?
Thank you very much!


 Best regards
Jie Shen


Graduate Student in Computer Science
Illinois Institute of Technology
Stuart Building  Chicago, IL 60616
+1  312 404 0122

--001a11c321ceffd2f8050a14c483
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>Hello Gurus,</div><div>I am adding a n=
ew rm scheduler to the rt-xen,</div><div>unfortunately I met &quot;undefine=
d reference to &quot; error ,the output is below:</div><div><br></div><div>=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Derror output begin=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><br></div><div><br></div><div>l=
n -sf libxenlight.so.4.3.0 libxenlight.so.4.3</div><div>ln -sf libxenlight.=
so.4.3 libxenlight.so</div><div>gcc =C2=A0 =C2=A0-pthread -o xl xl.o xl_cmd=
impl.o xl_cmdtable.o xl_sxp.o libxlutil.so /home/jackyshen/RT-XEN/RT-Xen-rt=
-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.so -Wl,-rpath-link=3D/ho=
me/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxc -Wl,-rp=
ath-link=3D/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools=
/xenstore -Wl,-rpath-link=3D/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/=
libxl/../../tools/blktap2/control /home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/=
tools/libxl/../../tools/libxc/libxenctrl.so -lyajl=C2=A0</div><div>/home/ja=
ckyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.=
so: undefined reference to `xc_sched_rm_domain_get&#39;</div><div>/home/jac=
kyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools/libxl/../../tools/libxl/libxenlight.s=
o: undefined reference to `xc_sched_rm_domain_set&#39;</div><div>collect2: =
error: ld returned 1 exit status</div><div>make[3]: *** [xl] Error 1</div><=
div>make[3]: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/to=
ols/libxl&#39;</div><div>make[2]: *** [subdir-install-libxl] Error 2</div><=
div>make[2]: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/to=
ols&#39;</div><div>make[1]: *** [subdirs-install] Error 2</div><div>make[1]=
: Leaving directory `/home/jackyshen/RT-XEN/RT-Xen-rt-xen_2.0/tools&#39;</d=
iv><div>make: *** [install-tools] Error 2</div><div><br></div><div><div cla=
ss=3D"gmail_signature"><div dir=3D"ltr"><div><div>=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D error output end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D<br><br><br>I searched all the folder ,it should be de=
fined in the file :(reference rtpartion)</div><div><br></div><div><br></div=
><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D grep for=
 rm=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><div>jackyshen@j=
ackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ grep -r =C2=A0xc_sched_r=
m_domain_set</div><div>dist/install/usr/local/include/xenctrl.h~:int xc_sch=
ed_rm_domain_set(xc_interface *xch,</div><div>dist/install/usr/local/includ=
e/xenctrl.h:int xc_sched_rm_domain_set(xc_interface *xch,</div><div>tools/l=
ibxc/xc_rm.c:xc_sched_rm_domain_set(</div><div>tools/libxc/xenctrl.h:int xc=
_sched_rm_domain_set(xc_interface *xch,</div><div>tools/libxl/libxl.c: =C2=
=A0 =C2=A0rc =3D xc_sched_rm_domain_set(CTX-&gt;xch, domid, &amp;sdom);</di=
v><div>Binary file tools/libxl/libxenlight.so.4.3.0 matches</div><div>Binar=
y file tools/libxl/libxl.o matches</div><div>tools/python/xen/lowlevel/xc/x=
c.c:static PyObject *pyxc_sched_rm_domain_set(XcObject *self,</div><div>too=
ls/python/xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_set(se=
lf-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</div><div>tools/python/xen/low=
level/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_set,</=
div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3Dgrep for rtpartion =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div>=
jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ grep -r =C2=
=A0xc_sched_rtpartition_domain_set</div><div>dist/install/usr/local/include=
/xenctrl.h~:int xc_sched_rtpartition_domain_set(xc_interface *xch,</div><di=
v>dist/install/usr/local/include/xenctl.hbak:int xc_sched_rtpartition_domai=
n_set(xc_interface *xch, =C2=A0 =C2=A0 =3D=3D=3D&gt;bakfile can be ignored<=
/div><div>dist/install/usr/local/include/xenctrl.h:int xc_sched_rtpartition=
_domain_set(xc_interface *xch,</div><div>Binary file dist/install/usr/local=
/lib/libxenlight.so.4.3.0 matches</div><div>Binary file dist/install/usr/lo=
cal/lib/libxenlight.a matches</div><div>Binary file dist/install/usr/local/=
lib/libxenctrl.so.4.3.0 matches</div><div>Binary file dist/install/usr/loca=
l/lib/libxenctrl.a matches</div><div>Binary file dist/install/usr/local/lib=
/python2.7/dist-packages/xen/lowlevel/xc.so matches</div><div>Binary file t=
ools/libxc/libxenctrl.so.4.3.0 matches</div><div>Binary file tools/libxc/li=
bxenctrl.a matches</div><div>Binary file tools/libxc/xc_rtpartition.o match=
es</div><div>tools/libxc/xc_rtpartition.c:xc_sched_rtpartition_domain_set(<=
/div><div>Binary file tools/libxc/xc_rtpartition.opic matches</div><div>too=
ls/libxc/xenctrl.h:int xc_sched_rtpartition_domain_set(xc_interface *xch,</=
div><div>tools/libxl/libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rtpartition_doma=
in_set(CTX-&gt;xch, domid, &amp;sdom);</div><div>Binary file tools/libxl/li=
bxenlight.so.4.3.0 matches</div><div>tools/libxl/libxl.cbak: =C2=A0 =C2=A0r=
c =3D xc_sched_rtpartition_domain_set(CTX-&gt;xch, domid, &amp;sdom);</div>=
<div>Binary file tools/libxl/libxl.o matches</div><div>tools/libxl/libxl.cb=
ak.20141211: =C2=A0 =C2=A0rc =3D xc_sched_rtpartition_domain_set(CTX-&gt;xc=
h, domid, &amp;sdom);</div><div>tools/python/xen/lowlevel/xc/xc.c:static Py=
Object *pyxc_sched_rtpartition_domain_set(XcObject *self,</div><div>tools/p=
ython/xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rtpartition_domain_s=
et(self-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</div><div>tools/python/xe=
n/lowlevel/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rtpartition=
_domain_set,</div><div>tools/python/xen/lowlevel/xc/xc.cbak:static PyObject=
 *pyxc_sched_rtpartition_domain_set(XcObject *self, =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=3D=3D&gt;bakfil=
e</div><div>tools/python/xen/lowlevel/xc/xc.cbak: =C2=A0 =C2=A0if ( xc_sche=
d_rtpartition_domain_set(self-&gt;xc_handle, domid, &amp;sdom) !=3D 0 )</di=
v><div>tools/python/xen/lowlevel/xc/xc.cbak: =C2=A0 =C2=A0 =C2=A0(PyCFuncti=
on)pyxc_sched_rtpartition_domain_set,</div><div>jackyshen@jackyshen-ThinkPa=
d-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$=C2=A0</div><div><br></div><div><br></div=
><div><br></div>Could you please advice me where I need to define it?</div>=
<div>Thank you very much!<br><br><br>=C2=A0Best regards<br>Jie Shen <br><br=
><br></div>Graduate Student in Computer Science<br></div>Illinois Institute=
 of Technology=C2=A0=C2=A0=C2=A0 <br>Stuart Building=C2=A0 Chicago, IL 6061=
6<br>+1=C2=A0 312 404 0122<br><div><br></div></div></div></div>
</div>

--001a11c321ceffd2f8050a14c483--


--===============3474216860565391377==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3474216860565391377==--


From xen-devel-bounces@lists.xen.org Mon Dec 15 08:36:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 08:36:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0R82-0001Eu-C7; Mon, 15 Dec 2014 08:35:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y0R80-0001Ep-W3
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 08:35:41 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	DE/0C-24124-B5D9E845; Mon, 15 Dec 2014 08:35:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418632538!13301116!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6516 invoked from network); 15 Dec 2014 08:35:38 -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; 15 Dec 2014 08:35:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 08:35:37 +0000
Message-Id: <548EAB66020000780004F757@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 08:35:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5489906B020000780004EE34@mail.emea.novell.com>
	<69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.com>
	<5489C88F020000780004F0C2@mail.emea.novell.com>
	<20141211194148.GG18992@laptop.dumpdata.com>
	<548AC73D020000780004F2F6@mail.emea.novell.com>
	<20141212164119.GA28140@laptop.dumpdata.com>
In-Reply-To: <20141212164119.GA28140@laptop.dumpdata.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 17:41, <konrad.wilk@oracle.com> wrote:
> On Fri, Dec 12, 2014 at 09:45:17AM +0000, Jan Beulich wrote:
>> >>> On 11.12.14 at 20:41, <konrad.wilk@oracle.com> wrote:
>> > On Thu, Dec 11, 2014 at 03:38:39PM +0000, Jan Beulich wrote:
>> >> >>> On 11.12.14 at 16:18, <konrad.wilk@oracle.com> wrote:
>> >> > A proper fix would be to automatically adjust based on memmap and CPU but 
>> >> > that could be too complex.
>> >> 
>> >> The problem isn't the complexity, but the chicken-and-egg problem
>> >> as far as CPU count is concerned. The memory map size would be
>> >> known early enough.
>> > 
>> > Let me explain my thought process:
>> >  - There are existing knobs that can be used to change this (conring_size=X)
>> >  - But we would like an awesome release where those knobs don't have to
>> >    be used.
>> >  - The patch you posted could be reworked to fully address memmap and CPU.
>> 
>> Not really, unless we separate parsing and printing of the ACPI
>> tables. Again, the CPU count is known only after that parsing.
> 
> Right, the logic of increasing the buffer based on CPU count is an
> excellent addition.
>> 
>> >  - I don't know what your time constraints are for said patch and you
>> >    might not have the energy to rework it.
>> >  - I don't want to put pressure on you or Daniel on having to write new
>> >    patches - especially as folks are going on vacation soon.
>> > 
>> > Hence as a fallback I believe that Daniel's patch should go in and
>> > Jan's patch can go in too. However if Jan (or somebody else) wants to
>> > rework the v2 (or a new one) to address the memmap issue then that
>> > patch would go in - instead of Daniel's or v2 of Jan patch.
>> 
>> Which memmap issue? You confirmed in your reply that you understand
>> that the memmap gets printed late enough for the change in v2 to
>> take effect. Plus those are info-level messages, and hence don't get
> 
> Correct. The count of memmap entries can be high even with an
> small amount of CPUs. Meaning your patch would not modify the
> size of the circular buffer in such case (and we would lose some
> of the memmap entries being printed).

I'm not following - the patch doesn't make the ring size dependent
on CPU count, that was the case already before. It only allows the
permanent ring buffer to be allocated quite a bit earlier thus
avoiding messages from getting overwritten.

> Daniel's patch would
> provide a cushion by expanding the default size, however ..
> 
>> printed at all by default. And if somebody alters the log levels, (s)he
>> can surely be expected to also adjust the ring size. (The log level
>> aspect is actually another argument against Daniel's patch.)
> 
> ... your point about the need to use 'loglvl' points out that
> Daniel's patch does not fix the all-generic case.
> 
> /me puts on the Xen 4.6 todo 'adjust log buffer based on memmap size'

I'm not convinced this is a good idea, or else we should account for
possible other high volume sources too. Plus you'd still not be in the
position to auto-size the ring buffer in a way accounting for both
CPU count and memmap size.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 08:36:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 08:36:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0R82-0001Eu-C7; Mon, 15 Dec 2014 08:35:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y0R80-0001Ep-W3
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 08:35:41 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	DE/0C-24124-B5D9E845; Mon, 15 Dec 2014 08:35:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418632538!13301116!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6516 invoked from network); 15 Dec 2014 08:35:38 -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; 15 Dec 2014 08:35:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 08:35:37 +0000
Message-Id: <548EAB66020000780004F757@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 08:35:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <5489906B020000780004EE34@mail.emea.novell.com>
	<69DD4F40-ADC1-48A4-9BD0-0A2A00624F66@oracle.com>
	<5489C88F020000780004F0C2@mail.emea.novell.com>
	<20141211194148.GG18992@laptop.dumpdata.com>
	<548AC73D020000780004F2F6@mail.emea.novell.com>
	<20141212164119.GA28140@laptop.dumpdata.com>
In-Reply-To: <20141212164119.GA28140@laptop.dumpdata.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] patches pending acks (or naks)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 17:41, <konrad.wilk@oracle.com> wrote:
> On Fri, Dec 12, 2014 at 09:45:17AM +0000, Jan Beulich wrote:
>> >>> On 11.12.14 at 20:41, <konrad.wilk@oracle.com> wrote:
>> > On Thu, Dec 11, 2014 at 03:38:39PM +0000, Jan Beulich wrote:
>> >> >>> On 11.12.14 at 16:18, <konrad.wilk@oracle.com> wrote:
>> >> > A proper fix would be to automatically adjust based on memmap and CPU but 
>> >> > that could be too complex.
>> >> 
>> >> The problem isn't the complexity, but the chicken-and-egg problem
>> >> as far as CPU count is concerned. The memory map size would be
>> >> known early enough.
>> > 
>> > Let me explain my thought process:
>> >  - There are existing knobs that can be used to change this (conring_size=X)
>> >  - But we would like an awesome release where those knobs don't have to
>> >    be used.
>> >  - The patch you posted could be reworked to fully address memmap and CPU.
>> 
>> Not really, unless we separate parsing and printing of the ACPI
>> tables. Again, the CPU count is known only after that parsing.
> 
> Right, the logic of increasing the buffer based on CPU count is an
> excellent addition.
>> 
>> >  - I don't know what your time constraints are for said patch and you
>> >    might not have the energy to rework it.
>> >  - I don't want to put pressure on you or Daniel on having to write new
>> >    patches - especially as folks are going on vacation soon.
>> > 
>> > Hence as a fallback I believe that Daniel's patch should go in and
>> > Jan's patch can go in too. However if Jan (or somebody else) wants to
>> > rework the v2 (or a new one) to address the memmap issue then that
>> > patch would go in - instead of Daniel's or v2 of Jan patch.
>> 
>> Which memmap issue? You confirmed in your reply that you understand
>> that the memmap gets printed late enough for the change in v2 to
>> take effect. Plus those are info-level messages, and hence don't get
> 
> Correct. The count of memmap entries can be high even with an
> small amount of CPUs. Meaning your patch would not modify the
> size of the circular buffer in such case (and we would lose some
> of the memmap entries being printed).

I'm not following - the patch doesn't make the ring size dependent
on CPU count, that was the case already before. It only allows the
permanent ring buffer to be allocated quite a bit earlier thus
avoiding messages from getting overwritten.

> Daniel's patch would
> provide a cushion by expanding the default size, however ..
> 
>> printed at all by default. And if somebody alters the log levels, (s)he
>> can surely be expected to also adjust the ring size. (The log level
>> aspect is actually another argument against Daniel's patch.)
> 
> ... your point about the need to use 'loglvl' points out that
> Daniel's patch does not fix the all-generic case.
> 
> /me puts on the Xen 4.6 todo 'adjust log buffer based on memmap size'

I'm not convinced this is a good idea, or else we should account for
possible other high volume sources too. Plus you'd still not be in the
position to auto-size the ring buffer in a way accounting for both
CPU count and memmap size.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 08:45:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 08: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 1Y0RH1-0001Xb-Jh; Mon, 15 Dec 2014 08:44:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y0RGz-0001XW-K6
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 08:44:57 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	52/26-07724-88F9E845; Mon, 15 Dec 2014 08:44:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418633096!9616774!1
X-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 26235 invoked from network); 15 Dec 2014 08:44:56 -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; 15 Dec 2014 08:44:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 08:44:55 +0000
Message-Id: <548EAD94020000780004F76D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 08:44:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 07:25, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>> On 12.12.14 at 08:24, <kevin.tian@intel.com> wrote:
>> > - how is BFN or unused address (what do you mean by address here?)
>> > allocated? does it need present in guest physical memory at boot time,
>> > or just finding some holes?
>> 
>> Fitting this into holes should be fine.
> 
> this is an interesting open to be further discussed. Here we need consider 
> the extreme case, i.e. a 64bit GPU page table can legitimately use up all 
> the system memory allocates to that VM, and considering dozens of VMs, 
> it means we need reserve a very large hole. 

Oh, it's guest RAM you want mapped, not frame buffer space. But still
you're never going to have to map more than the total amount of host
RAM, and (with Linux) we already assume everything can be mapped
through the 1:1 mapping. I.e. the only collision would be with excessive
PFN reservations for ballooning purposes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 08:45:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 08: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 1Y0RH1-0001Xb-Jh; Mon, 15 Dec 2014 08:44:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y0RGz-0001XW-K6
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 08:44:57 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	52/26-07724-88F9E845; Mon, 15 Dec 2014 08:44:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418633096!9616774!1
X-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 26235 invoked from network); 15 Dec 2014 08:44:56 -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; 15 Dec 2014 08:44:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 08:44:55 +0000
Message-Id: <548EAD94020000780004F76D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 08:44:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 07:25, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>> On 12.12.14 at 08:24, <kevin.tian@intel.com> wrote:
>> > - how is BFN or unused address (what do you mean by address here?)
>> > allocated? does it need present in guest physical memory at boot time,
>> > or just finding some holes?
>> 
>> Fitting this into holes should be fine.
> 
> this is an interesting open to be further discussed. Here we need consider 
> the extreme case, i.e. a 64bit GPU page table can legitimately use up all 
> the system memory allocates to that VM, and considering dozens of VMs, 
> it means we need reserve a very large hole. 

Oh, it's guest RAM you want mapped, not frame buffer space. But still
you're never going to have to map more than the total amount of host
RAM, and (with Linux) we already assume everything can be mapped
through the 1:1 mapping. I.e. the only collision would be with excessive
PFN reservations for ballooning purposes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 08:48:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 08: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 1Y0RK6-0001gy-Bc; Mon, 15 Dec 2014 08:48:10 +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 1Y0RK5-0001gq-AR
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 08:48:09 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	38/6B-01660-840AE845; Mon, 15 Dec 2014 08:48:08 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418633286!5740148!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18921 invoked from network); 15 Dec 2014 08:48:07 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-206.messagelabs.com with SMTP;
	15 Dec 2014 08:48:07 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 15 Dec 2014 00:47:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,578,1413270000"; d="scan'208";a="637638406"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by fmsmga001.fm.intel.com with ESMTP; 15 Dec 2014 00:47:52 -0800
Date: Mon, 15 Dec 2014 16:47:51 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141215084751.GA3105@pengc-linux.bj.intel.com>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
	<548B0389.5040107@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548B0389.5040107@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, will.auld@intel.com, JBeulich@suse.com,
	wei.liu2@citrix.com, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
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 Fri, Dec 12, 2014 at 03:02:33PM +0000, Andrew Cooper wrote:
> On 12/12/14 12:27, Chao Peng wrote:
> > Hi all, we plan to bring Intel CAT into XEN. This is the initial
> > design for that. Comments/suggestions are welcome.
> >
> 
> Fantastic - this is a very clear and well presented document.  In terms
> of a plan of action, it looks fine.
Thank you for review.
> 
> >From my understanding, CAT is a largely orthogonal to CMT, but will
> share some of the base PSR infrastructure in Xen?
> 
Yes, from functional perspective, they are independent features. But
they do share some common codes and also have similar designs in XEN.

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 Mon Dec 15 08:48:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 08: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 1Y0RK6-0001gy-Bc; Mon, 15 Dec 2014 08:48:10 +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 1Y0RK5-0001gq-AR
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 08:48:09 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	38/6B-01660-840AE845; Mon, 15 Dec 2014 08:48:08 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418633286!5740148!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18921 invoked from network); 15 Dec 2014 08:48:07 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-206.messagelabs.com with SMTP;
	15 Dec 2014 08:48:07 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 15 Dec 2014 00:47:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,578,1413270000"; d="scan'208";a="637638406"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by fmsmga001.fm.intel.com with ESMTP; 15 Dec 2014 00:47:52 -0800
Date: Mon, 15 Dec 2014 16:47:51 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141215084751.GA3105@pengc-linux.bj.intel.com>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
	<548B0389.5040107@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548B0389.5040107@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, will.auld@intel.com, JBeulich@suse.com,
	wei.liu2@citrix.com, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
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 Fri, Dec 12, 2014 at 03:02:33PM +0000, Andrew Cooper wrote:
> On 12/12/14 12:27, Chao Peng wrote:
> > Hi all, we plan to bring Intel CAT into XEN. This is the initial
> > design for that. Comments/suggestions are welcome.
> >
> 
> Fantastic - this is a very clear and well presented document.  In terms
> of a plan of action, it looks fine.
Thank you for review.
> 
> >From my understanding, CAT is a largely orthogonal to CMT, but will
> share some of the base PSR infrastructure in Xen?
> 
Yes, from functional perspective, they are independent features. But
they do share some common codes and also have similar designs in XEN.

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 Mon Dec 15 09:05:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 09:05:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Ran-0002C6-2d; Mon, 15 Dec 2014 09:05:25 +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 1Y0Ral-0002C1-Sz
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 09:05:24 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	85/01-22777-354AE845; Mon, 15 Dec 2014 09:05:23 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418634322!9974811!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 10671 invoked from network); 15 Dec 2014 09:05:22 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-206.messagelabs.com with SMTP;
	15 Dec 2014 09:05:22 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga102.jf.intel.com with ESMTP; 15 Dec 2014 01:03:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="498801109"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by orsmga003.jf.intel.com with ESMTP; 15 Dec 2014 01:01:12 -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; Mon, 15 Dec 2014 17:05:18 +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; Mon, 15 Dec 2014 17:05:17 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQGC/gTnKCuINaSEuNrOPaD/DIeJyP0EwAgACJvQA=
Date: Mon, 15 Dec 2014 09:05:15 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
In-Reply-To: <548EAD94020000780004F76D@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: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, December 15, 2014 4:45 PM
> 
> >>> On 15.12.14 at 07:25, <kevin.tian@intel.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >>> On 12.12.14 at 08:24, <kevin.tian@intel.com> wrote:
> >> > - how is BFN or unused address (what do you mean by address here?)
> >> > allocated? does it need present in guest physical memory at boot time,
> >> > or just finding some holes?
> >>
> >> Fitting this into holes should be fine.
> >
> > this is an interesting open to be further discussed. Here we need consider
> > the extreme case, i.e. a 64bit GPU page table can legitimately use up all
> > the system memory allocates to that VM, and considering dozens of VMs,
> > it means we need reserve a very large hole.
> 
> Oh, it's guest RAM you want mapped, not frame buffer space. But still
> you're never going to have to map more than the total amount of host
> RAM, and (with Linux) we already assume everything can be mapped
> through the 1:1 mapping. I.e. the only collision would be with excessive
> PFN reservations for ballooning purposes.
> 

Intel GPU has graphics memory (or framebuffer) backed through system
memory, and we need to walk GPU page table and then map corresponding
guest RAM for handling.

yes, definitely host RAM is the upper limit, and what I'm concerning here
is how to reserve (at boot time) or allocate (on-demand) such large PFN
resource, w/o collision with other PFN reservation usage (ballooning
should be fine since it's operating existing RAM ranges in dom0 e820
table). Maybe we can reserve a big-enough reserved region in dom0's 
e820 table at boot time, for all PFN reservation usages, and then allocate
them on-demand for specific usages?

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 09:05:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 09:05:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Ran-0002C6-2d; Mon, 15 Dec 2014 09:05:25 +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 1Y0Ral-0002C1-Sz
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 09:05:24 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	85/01-22777-354AE845; Mon, 15 Dec 2014 09:05:23 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418634322!9974811!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 10671 invoked from network); 15 Dec 2014 09:05:22 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-206.messagelabs.com with SMTP;
	15 Dec 2014 09:05:22 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga102.jf.intel.com with ESMTP; 15 Dec 2014 01:03:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="498801109"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
	by orsmga003.jf.intel.com with ESMTP; 15 Dec 2014 01:01:12 -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; Mon, 15 Dec 2014 17:05:18 +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; Mon, 15 Dec 2014 17:05:17 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQGC/gTnKCuINaSEuNrOPaD/DIeJyP0EwAgACJvQA=
Date: Mon, 15 Dec 2014 09:05:15 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
In-Reply-To: <548EAD94020000780004F76D@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: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, December 15, 2014 4:45 PM
> 
> >>> On 15.12.14 at 07:25, <kevin.tian@intel.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >>> On 12.12.14 at 08:24, <kevin.tian@intel.com> wrote:
> >> > - how is BFN or unused address (what do you mean by address here?)
> >> > allocated? does it need present in guest physical memory at boot time,
> >> > or just finding some holes?
> >>
> >> Fitting this into holes should be fine.
> >
> > this is an interesting open to be further discussed. Here we need consider
> > the extreme case, i.e. a 64bit GPU page table can legitimately use up all
> > the system memory allocates to that VM, and considering dozens of VMs,
> > it means we need reserve a very large hole.
> 
> Oh, it's guest RAM you want mapped, not frame buffer space. But still
> you're never going to have to map more than the total amount of host
> RAM, and (with Linux) we already assume everything can be mapped
> through the 1:1 mapping. I.e. the only collision would be with excessive
> PFN reservations for ballooning purposes.
> 

Intel GPU has graphics memory (or framebuffer) backed through system
memory, and we need to walk GPU page table and then map corresponding
guest RAM for handling.

yes, definitely host RAM is the upper limit, and what I'm concerning here
is how to reserve (at boot time) or allocate (on-demand) such large PFN
resource, w/o collision with other PFN reservation usage (ballooning
should be fine since it's operating existing RAM ranges in dom0 e820
table). Maybe we can reserve a big-enough reserved region in dom0's 
e820 table at boot time, for all PFN reservation usages, and then allocate
them on-demand for specific usages?

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 09:16:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 09: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 1Y0RlI-0002UJ-AC; Mon, 15 Dec 2014 09:16: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 1Y0RlG-0002UE-CE
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 09:16:14 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	45/AA-02696-DD6AE845; Mon, 15 Dec 2014 09:16:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418634972!15077011!1
X-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 2479 invoked from network); 15 Dec 2014 09:16:12 -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; 15 Dec 2014 09:16:12 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 09:16:12 +0000
Message-Id: <548EB4E9020000780004F7BE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 09:16:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDDE80AC9.1__="
Cc: Keir Fraser <keir@xen.org>,
	Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Subject: [Xen-devel] [PATCH] x86/AMD-ucode: correct multiple container
	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.

--=__PartDDE80AC9.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Avoid emitting an error message referring to an incorrect or corrupt
container file just because no entry was found for the running CPU.

Additionally switch the order of data validation and consumption in
cpu_request_microcode()'s first loop, and also check the types of
skipped blocks in container_fast_forward().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -331,12 +331,17 @@ static int container_fast_forward(const=20
              header[1] =3D=3D UCODE_EQUIV_CPU_TABLE_TYPE )
             break;
=20
+        if ( header[0] !=3D UCODE_UCODE_TYPE )
+            return -EINVAL;
         size =3D header[1] + SECTION_HDR_SIZE;
         if ( size < PATCH_HDR_SIZE || size_left < size )
             return -EINVAL;
=20
         size_left -=3D size;
         *offset +=3D size;
+
+        if ( !size_left )
+            return -ENODATA;
     }
=20
     return 0;
@@ -386,10 +391,6 @@ static int cpu_request_microcode(int cpu
             break;
         }
=20
-        if ( find_equiv_cpu_id(mc_amd->equiv_cpu_table, current_cpu_id,
-                               &equiv_cpu_id) )
-                break;
-
         /*
          * Could happen as we advance 'offset' early
          * in install_equiv_cpu_table
@@ -401,7 +402,16 @@ static int cpu_request_microcode(int cpu
             break;
         }
=20
+        if ( find_equiv_cpu_id(mc_amd->equiv_cpu_table, current_cpu_id,
+                               &equiv_cpu_id) )
+            break;
+
         error =3D container_fast_forward(buf, bufsize - offset, &offset);
+        if ( error =3D=3D -ENODATA )
+        {
+            ASSERT(offset =3D=3D bufsize);
+            break;
+        }
         if ( error )
         {
             printk(KERN_ERR "microcode: CPU%d incorrect or corrupt =
container file\n"




--=__PartDDE80AC9.1__=
Content-Type: text/plain; name="x86-AMD-ucode-flow.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-AMD-ucode-flow.patch"

x86/AMD-ucode: correct multiple container handling=0A=0AAvoid emitting an =
error message referring to an incorrect or corrupt=0Acontainer file just =
because no entry was found for the running CPU.=0A=0AAdditionally switch =
the order of data validation and consumption in=0Acpu_request_microcode()'s=
 first loop, and also check the types of=0Askipped blocks in container_fast=
_forward().=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/microcode_amd.c=0A+++ b/xen/arch/x86/microcode_amd.c=0A@@ =
-331,12 +331,17 @@ static int container_fast_forward(const =0A             =
 header[1] =3D=3D UCODE_EQUIV_CPU_TABLE_TYPE )=0A             break;=0A =
=0A+        if ( header[0] !=3D UCODE_UCODE_TYPE )=0A+            return =
-EINVAL;=0A         size =3D header[1] + SECTION_HDR_SIZE;=0A         if ( =
size < PATCH_HDR_SIZE || size_left < size )=0A             return =
-EINVAL;=0A =0A         size_left -=3D size;=0A         *offset +=3D =
size;=0A+=0A+        if ( !size_left )=0A+            return -ENODATA;=0A  =
   }=0A =0A     return 0;=0A@@ -386,10 +391,6 @@ static int cpu_request_mic=
rocode(int cpu=0A             break;=0A         }=0A =0A-        if ( =
find_equiv_cpu_id(mc_amd->equiv_cpu_table, current_cpu_id,=0A-             =
                  &equiv_cpu_id) )=0A-                break;=0A-=0A        =
 /*=0A          * Could happen as we advance 'offset' early=0A          * =
in install_equiv_cpu_table=0A@@ -401,7 +402,16 @@ static int cpu_request_mi=
crocode(int cpu=0A             break;=0A         }=0A =0A+        if ( =
find_equiv_cpu_id(mc_amd->equiv_cpu_table, current_cpu_id,=0A+             =
                  &equiv_cpu_id) )=0A+            break;=0A+=0A         =
error =3D container_fast_forward(buf, bufsize - offset, &offset);=0A+      =
  if ( error =3D=3D -ENODATA )=0A+        {=0A+            ASSERT(offset =
=3D=3D bufsize);=0A+            break;=0A+        }=0A         if ( error =
)=0A         {=0A             printk(KERN_ERR "microcode: CPU%d incorrect =
or corrupt container file\n"=0A
--=__PartDDE80AC9.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

--=__PartDDE80AC9.1__=--


From xen-devel-bounces@lists.xen.org Mon Dec 15 09:16:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 09: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 1Y0RlI-0002UJ-AC; Mon, 15 Dec 2014 09:16: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 1Y0RlG-0002UE-CE
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 09:16:14 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	45/AA-02696-DD6AE845; Mon, 15 Dec 2014 09:16:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418634972!15077011!1
X-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 2479 invoked from network); 15 Dec 2014 09:16:12 -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; 15 Dec 2014 09:16:12 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 09:16:12 +0000
Message-Id: <548EB4E9020000780004F7BE@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 09:16:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDDE80AC9.1__="
Cc: Keir Fraser <keir@xen.org>,
	Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Subject: [Xen-devel] [PATCH] x86/AMD-ucode: correct multiple container
	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.

--=__PartDDE80AC9.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Avoid emitting an error message referring to an incorrect or corrupt
container file just because no entry was found for the running CPU.

Additionally switch the order of data validation and consumption in
cpu_request_microcode()'s first loop, and also check the types of
skipped blocks in container_fast_forward().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -331,12 +331,17 @@ static int container_fast_forward(const=20
              header[1] =3D=3D UCODE_EQUIV_CPU_TABLE_TYPE )
             break;
=20
+        if ( header[0] !=3D UCODE_UCODE_TYPE )
+            return -EINVAL;
         size =3D header[1] + SECTION_HDR_SIZE;
         if ( size < PATCH_HDR_SIZE || size_left < size )
             return -EINVAL;
=20
         size_left -=3D size;
         *offset +=3D size;
+
+        if ( !size_left )
+            return -ENODATA;
     }
=20
     return 0;
@@ -386,10 +391,6 @@ static int cpu_request_microcode(int cpu
             break;
         }
=20
-        if ( find_equiv_cpu_id(mc_amd->equiv_cpu_table, current_cpu_id,
-                               &equiv_cpu_id) )
-                break;
-
         /*
          * Could happen as we advance 'offset' early
          * in install_equiv_cpu_table
@@ -401,7 +402,16 @@ static int cpu_request_microcode(int cpu
             break;
         }
=20
+        if ( find_equiv_cpu_id(mc_amd->equiv_cpu_table, current_cpu_id,
+                               &equiv_cpu_id) )
+            break;
+
         error =3D container_fast_forward(buf, bufsize - offset, &offset);
+        if ( error =3D=3D -ENODATA )
+        {
+            ASSERT(offset =3D=3D bufsize);
+            break;
+        }
         if ( error )
         {
             printk(KERN_ERR "microcode: CPU%d incorrect or corrupt =
container file\n"




--=__PartDDE80AC9.1__=
Content-Type: text/plain; name="x86-AMD-ucode-flow.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-AMD-ucode-flow.patch"

x86/AMD-ucode: correct multiple container handling=0A=0AAvoid emitting an =
error message referring to an incorrect or corrupt=0Acontainer file just =
because no entry was found for the running CPU.=0A=0AAdditionally switch =
the order of data validation and consumption in=0Acpu_request_microcode()'s=
 first loop, and also check the types of=0Askipped blocks in container_fast=
_forward().=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/microcode_amd.c=0A+++ b/xen/arch/x86/microcode_amd.c=0A@@ =
-331,12 +331,17 @@ static int container_fast_forward(const =0A             =
 header[1] =3D=3D UCODE_EQUIV_CPU_TABLE_TYPE )=0A             break;=0A =
=0A+        if ( header[0] !=3D UCODE_UCODE_TYPE )=0A+            return =
-EINVAL;=0A         size =3D header[1] + SECTION_HDR_SIZE;=0A         if ( =
size < PATCH_HDR_SIZE || size_left < size )=0A             return =
-EINVAL;=0A =0A         size_left -=3D size;=0A         *offset +=3D =
size;=0A+=0A+        if ( !size_left )=0A+            return -ENODATA;=0A  =
   }=0A =0A     return 0;=0A@@ -386,10 +391,6 @@ static int cpu_request_mic=
rocode(int cpu=0A             break;=0A         }=0A =0A-        if ( =
find_equiv_cpu_id(mc_amd->equiv_cpu_table, current_cpu_id,=0A-             =
                  &equiv_cpu_id) )=0A-                break;=0A-=0A        =
 /*=0A          * Could happen as we advance 'offset' early=0A          * =
in install_equiv_cpu_table=0A@@ -401,7 +402,16 @@ static int cpu_request_mi=
crocode(int cpu=0A             break;=0A         }=0A =0A+        if ( =
find_equiv_cpu_id(mc_amd->equiv_cpu_table, current_cpu_id,=0A+             =
                  &equiv_cpu_id) )=0A+            break;=0A+=0A         =
error =3D container_fast_forward(buf, bufsize - offset, &offset);=0A+      =
  if ( error =3D=3D -ENODATA )=0A+        {=0A+            ASSERT(offset =
=3D=3D bufsize);=0A+            break;=0A+        }=0A         if ( error =
)=0A         {=0A             printk(KERN_ERR "microcode: CPU%d incorrect =
or corrupt container file\n"=0A
--=__PartDDE80AC9.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

--=__PartDDE80AC9.1__=--


From xen-devel-bounces@lists.xen.org Mon Dec 15 09:23:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 09: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 1Y0Rrg-0002ir-9N; Mon, 15 Dec 2014 09:22: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 1Y0Rre-0002hB-2d
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 09:22:50 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	B6/04-09284-968AE845; Mon, 15 Dec 2014 09:22:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418635366!13270572!1
X-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 2774 invoked from network); 15 Dec 2014 09:22:46 -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; 15 Dec 2014 09:22:46 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 09:22:46 +0000
Message-Id: <548EB672020000780004F7D2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 09:22:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
> yes, definitely host RAM is the upper limit, and what I'm concerning here
> is how to reserve (at boot time) or allocate (on-demand) such large PFN
> resource, w/o collision with other PFN reservation usage (ballooning
> should be fine since it's operating existing RAM ranges in dom0 e820
> table).

I don't think ballooning is restricted to the regions named RAM in
Dom0's E820 table (at least it shouldn't be, and wasn't in the
classic Xen kernels).

> Maybe we can reserve a big-enough reserved region in dom0's 
> e820 table at boot time, for all PFN reservation usages, and then allocate
> them on-demand for specific usages?

What would "big enough" here mean (i.e. how would one determine
the needed size up front)? Plus any form of allocation would need a
reasonable approach to avoid fragmentation. And anyway I'm not
getting what position you're on: Do you expect to be able to fit
everything that needs mapping into the available mapping space (as
your reply above seems to imply) or do you think there won't be
enough mapping space (as earlier replies of yours appeared to
indicate)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 09:23:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 09: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 1Y0Rrg-0002ir-9N; Mon, 15 Dec 2014 09:22: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 1Y0Rre-0002hB-2d
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 09:22:50 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	B6/04-09284-968AE845; Mon, 15 Dec 2014 09:22:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418635366!13270572!1
X-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 2774 invoked from network); 15 Dec 2014 09:22:46 -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; 15 Dec 2014 09:22:46 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 09:22:46 +0000
Message-Id: <548EB672020000780004F7D2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 09:22:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
> yes, definitely host RAM is the upper limit, and what I'm concerning here
> is how to reserve (at boot time) or allocate (on-demand) such large PFN
> resource, w/o collision with other PFN reservation usage (ballooning
> should be fine since it's operating existing RAM ranges in dom0 e820
> table).

I don't think ballooning is restricted to the regions named RAM in
Dom0's E820 table (at least it shouldn't be, and wasn't in the
classic Xen kernels).

> Maybe we can reserve a big-enough reserved region in dom0's 
> e820 table at boot time, for all PFN reservation usages, and then allocate
> them on-demand for specific usages?

What would "big enough" here mean (i.e. how would one determine
the needed size up front)? Plus any form of allocation would need a
reasonable approach to avoid fragmentation. And anyway I'm not
getting what position you're on: Do you expect to be able to fit
everything that needs mapping into the available mapping space (as
your reply above seems to imply) or do you think there won't be
enough mapping space (as earlier replies of yours appeared to
indicate)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 09:57:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 09:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0SOS-0003Pp-6H; Mon, 15 Dec 2014 09:56: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 1Y0SOR-0003Pk-1Y
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 09:56:43 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	AD/8C-05632-A50BE845; Mon, 15 Dec 2014 09:56:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418637399!10927963!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22823 invoked from network); 15 Dec 2014 09:56:40 -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;
	15 Dec 2014 09:56:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="scan'208";a="204816872"
Message-ID: <1418637397.16425.61.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jie Shen <shenjie7810@gmail.com>
Date: Mon, 15 Dec 2014 09:56:37 +0000
In-Reply-To: <CAB2Q45H0D0ZvGWth1hV+aYnV+MZ1EaEqHk4sk9whUCeuDh-7QA@mail.gmail.com>
References: <CAB2Q45H0D0ZvGWth1hV+aYnV+MZ1EaEqHk4sk9whUCeuDh-7QA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl.c::macro definition::LIBXL_SCHEDULER_SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-12 at 16:49 -0600, Jie Shen wrote:
> Hello Gurus,
> 
> 
> I am working on a project to change code of xen,
> Unfortunately I can not find the macro def of : LIBXL_SCHEDULER_****

Check tools/libxl/{libxl_types.idl,idl.py,gentypes.py,idl.txt}

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 09:57:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 09:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0SOS-0003Pp-6H; Mon, 15 Dec 2014 09:56: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 1Y0SOR-0003Pk-1Y
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 09:56:43 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	AD/8C-05632-A50BE845; Mon, 15 Dec 2014 09:56:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418637399!10927963!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22823 invoked from network); 15 Dec 2014 09:56:40 -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;
	15 Dec 2014 09:56:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="scan'208";a="204816872"
Message-ID: <1418637397.16425.61.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jie Shen <shenjie7810@gmail.com>
Date: Mon, 15 Dec 2014 09:56:37 +0000
In-Reply-To: <CAB2Q45H0D0ZvGWth1hV+aYnV+MZ1EaEqHk4sk9whUCeuDh-7QA@mail.gmail.com>
References: <CAB2Q45H0D0ZvGWth1hV+aYnV+MZ1EaEqHk4sk9whUCeuDh-7QA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl.c::macro definition::LIBXL_SCHEDULER_SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-12 at 16:49 -0600, Jie Shen wrote:
> Hello Gurus,
> 
> 
> I am working on a project to change code of xen,
> Unfortunately I can not find the macro def of : LIBXL_SCHEDULER_****

Check tools/libxl/{libxl_types.idl,idl.py,gentypes.py,idl.txt}

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:00:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 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 1Y0SSD-0003bo-SW; Mon, 15 Dec 2014 10:00: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 1Y0SSC-0003bj-2t
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:00:36 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	73/97-02954-341BE845; Mon, 15 Dec 2014 10:00:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418637633!15050765!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 21675 invoked from network); 15 Dec 2014 10:00:34 -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;
	15 Dec 2014 10:00:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="scan'208";a="204363868"
Message-ID: <1418637630.16425.63.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Quan Xu <quan.xu@intel.com>
Date: Mon, 15 Dec 2014 10:00:30 +0000
In-Reply-To: <1418558965-13342-1-git-send-email-quan.xu@intel.com>
References: <1418558965-13342-1-git-send-email-quan.xu@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/12] Enable vTPM subsystem on TPM 2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2014-12-14 at 07:09 -0500, Quan Xu wrote:
> This series of patch enable the virtual Trusted Platform Module (vTPM)
> subsystem for Xen on TPM 2.0.

Please can you investigate the --thread option to "git send-email"
and/or "git format-patch", such that all of the mails appear as replies
to this one or at least to the previous patch.

This will ensure that all the patches stay together in any decent MUA,
which is much easier for maintainers to cope with.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:00:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 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 1Y0SSD-0003bo-SW; Mon, 15 Dec 2014 10:00: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 1Y0SSC-0003bj-2t
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:00:36 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	73/97-02954-341BE845; Mon, 15 Dec 2014 10:00:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418637633!15050765!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 21675 invoked from network); 15 Dec 2014 10:00:34 -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;
	15 Dec 2014 10:00:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="scan'208";a="204363868"
Message-ID: <1418637630.16425.63.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Quan Xu <quan.xu@intel.com>
Date: Mon, 15 Dec 2014 10:00:30 +0000
In-Reply-To: <1418558965-13342-1-git-send-email-quan.xu@intel.com>
References: <1418558965-13342-1-git-send-email-quan.xu@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 00/12] Enable vTPM subsystem on TPM 2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2014-12-14 at 07:09 -0500, Quan Xu wrote:
> This series of patch enable the virtual Trusted Platform Module (vTPM)
> subsystem for Xen on TPM 2.0.

Please can you investigate the --thread option to "git send-email"
and/or "git format-patch", such that all of the mails appear as replies
to this one or at least to the previous patch.

This will ensure that all the patches stay together in any decent MUA,
which is much easier for maintainers to cope with.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:00:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10: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 1Y0SSP-0003dU-8W; Mon, 15 Dec 2014 10:00:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y0SSN-0003dA-5o
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 10:00:47 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	C1/7A-25547-E41BE845; Mon, 15 Dec 2014 10:00:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418637644!13232624!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7830 invoked from network); 15 Dec 2014 10:00:44 -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; 15 Dec 2014 10:00:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 10:00:43 +0000
Message-Id: <548EBF58020000780004F7E7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 10:00:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-2-git-send-email-jgross@suse.com>
	<548B70B3.7030807@oracle.com>
In-Reply-To: <548B70B3.7030807@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Juergen Gross <JGross@suse.com>, mmarek@suse.cz, x86@kernel.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	david.vrabel@citrix.com, hpa@zytor.com,
	xen-devel <xen-devel@lists.xenproject.org>, tglx@linutronix.de,
	linux-kbuild@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 23:48, <boris.ostrovsky@oracle.com> wrote:
> On 12/11/2014 01:04 PM, Juergen Gross wrote:
>> diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
>> new file mode 100644
>> index 0000000..e6447b7
>> --- /dev/null
>> +++ b/scripts/xen-hypercalls.sh
>> @@ -0,0 +1,11 @@
>> +#!/bin/sh
>> +out="$1"
>> +shift
>> +in="$@"
>> +
>> +for i in $in; do
>> +	eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
>> +done | \
>> +awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
>> +	END {for (i in v) if (!(v[i] in v))
>> +		print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
> 
> Why do you 'sort -u'? Do you expect multiple definitions of the same 
> hypercall?

For upstream I think this could be dropped; the original version needs
this as the classic tree sticks more closely to the original xen.h (which
has a couple of backward compatibility defines which would get in the
way). Otoh it does no harm afaict...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:00:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10: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 1Y0SSP-0003dU-8W; Mon, 15 Dec 2014 10:00:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y0SSN-0003dA-5o
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 10:00:47 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	C1/7A-25547-E41BE845; Mon, 15 Dec 2014 10:00:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418637644!13232624!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7830 invoked from network); 15 Dec 2014 10:00:44 -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; 15 Dec 2014 10:00:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 10:00:43 +0000
Message-Id: <548EBF58020000780004F7E7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 10:00:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-2-git-send-email-jgross@suse.com>
	<548B70B3.7030807@oracle.com>
In-Reply-To: <548B70B3.7030807@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Juergen Gross <JGross@suse.com>, mmarek@suse.cz, x86@kernel.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	david.vrabel@citrix.com, hpa@zytor.com,
	xen-devel <xen-devel@lists.xenproject.org>, tglx@linutronix.de,
	linux-kbuild@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 23:48, <boris.ostrovsky@oracle.com> wrote:
> On 12/11/2014 01:04 PM, Juergen Gross wrote:
>> diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
>> new file mode 100644
>> index 0000000..e6447b7
>> --- /dev/null
>> +++ b/scripts/xen-hypercalls.sh
>> @@ -0,0 +1,11 @@
>> +#!/bin/sh
>> +out="$1"
>> +shift
>> +in="$@"
>> +
>> +for i in $in; do
>> +	eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
>> +done | \
>> +awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
>> +	END {for (i in v) if (!(v[i] in v))
>> +		print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
> 
> Why do you 'sort -u'? Do you expect multiple definitions of the same 
> hypercall?

For upstream I think this could be dropped; the original version needs
this as the classic tree sticks more closely to the original xen.h (which
has a couple of backward compatibility defines which would get in the
way). Otoh it does no harm afaict...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:02:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10: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 1Y0SU8-0003pM-Qu; Mon, 15 Dec 2014 10:02: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 1Y0SU7-0003pE-Sj
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:02:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	95/19-09842-BB1BE845; Mon, 15 Dec 2014 10:02:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418637753!15586994!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 6614 invoked from network); 15 Dec 2014 10:02: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;
	15 Dec 2014 10:02:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="scan'208";a="204364583"
Message-ID: <1418637751.16425.64.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Date: Mon, 15 Dec 2014 10:02:31 +0000
In-Reply-To: <321a64dc64db335460b51becfc040f4cb0e84a9e.1407146305.git.ian.campbell@citrix.com>
References: <321a64dc64db335460b51becfc040f4cb0e84a9e.1407146305.git.ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Bastian Blank <waldi@debian.org>
Subject: Re: [Xen-devel] [PATCH] tools: libxl: link libxlu against 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-08-04 at 10:58 +0100, Ian Campbell wrote:

Ping again. This issue has resurfaced in the Debian packaging of the 4.5
rcs. I think we should fix this for 4.5, the risks are minimal.

> It uses libxl_defbool_set and must therefore be linked against the
> right library.
> 
> Spotted by dpkg-shlibdeps and pointed out by Bastian Blank:
> 
> dpkg-shlibdeps: warning: symbol libxl_defbool_set used by debian/libxen-4.4/usr/lib/libxlutil-4.4.so found in none of the libraries
> 
> This required switching the make rule from $^ to an explicit
> LIBXLU_OBJS since the former now includes libxenlight.so.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Bastian Blank <waldi@debian.org>
> ---
>  tools/libxl/Makefile |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index bd0db3b..e61048d 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -35,7 +35,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
>  LIBXL_LIBS += $(PTHREAD_LIBS)
>  LIBXL_LIBS += $(LIBXL_LIBS-y)
>  
> -LIBXLU_LIBS =
> +LIBXLU_LIBS = libxenlight.so
>  
>  LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
>  ifeq ($(LIBXL_BLKTAP),y)
> @@ -213,8 +213,8 @@ libxlutil.so: libxlutil.so.$(XLUMAJOR)
>  libxlutil.so.$(XLUMAJOR): libxlutil.so.$(XLUMAJOR).$(XLUMINOR)
>  	$(SYMLINK_SHLIB) $< $@
>  
> -libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS)
> -	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxlutil.so.$(XLUMAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXLU_LIBS) $(APPEND_LDFLAGS)
> +libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS) libxenlight.so
> +	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxlutil.so.$(XLUMAJOR) $(SHLIB_LDFLAGS) -o $@ $(LIBXLU_OBJS) $(LIBXLU_LIBS) $(APPEND_LDFLAGS)
>  
>  libxlutil.a: $(LIBXLU_OBJS)
>  	$(AR) rcs libxlutil.a $^



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:02:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10: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 1Y0SU8-0003pM-Qu; Mon, 15 Dec 2014 10:02: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 1Y0SU7-0003pE-Sj
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:02:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	95/19-09842-BB1BE845; Mon, 15 Dec 2014 10:02:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418637753!15586994!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 6614 invoked from network); 15 Dec 2014 10:02: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;
	15 Dec 2014 10:02:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="scan'208";a="204364583"
Message-ID: <1418637751.16425.64.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Date: Mon, 15 Dec 2014 10:02:31 +0000
In-Reply-To: <321a64dc64db335460b51becfc040f4cb0e84a9e.1407146305.git.ian.campbell@citrix.com>
References: <321a64dc64db335460b51becfc040f4cb0e84a9e.1407146305.git.ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Bastian Blank <waldi@debian.org>
Subject: Re: [Xen-devel] [PATCH] tools: libxl: link libxlu against 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-08-04 at 10:58 +0100, Ian Campbell wrote:

Ping again. This issue has resurfaced in the Debian packaging of the 4.5
rcs. I think we should fix this for 4.5, the risks are minimal.

> It uses libxl_defbool_set and must therefore be linked against the
> right library.
> 
> Spotted by dpkg-shlibdeps and pointed out by Bastian Blank:
> 
> dpkg-shlibdeps: warning: symbol libxl_defbool_set used by debian/libxen-4.4/usr/lib/libxlutil-4.4.so found in none of the libraries
> 
> This required switching the make rule from $^ to an explicit
> LIBXLU_OBJS since the former now includes libxenlight.so.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Bastian Blank <waldi@debian.org>
> ---
>  tools/libxl/Makefile |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index bd0db3b..e61048d 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -35,7 +35,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
>  LIBXL_LIBS += $(PTHREAD_LIBS)
>  LIBXL_LIBS += $(LIBXL_LIBS-y)
>  
> -LIBXLU_LIBS =
> +LIBXLU_LIBS = libxenlight.so
>  
>  LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
>  ifeq ($(LIBXL_BLKTAP),y)
> @@ -213,8 +213,8 @@ libxlutil.so: libxlutil.so.$(XLUMAJOR)
>  libxlutil.so.$(XLUMAJOR): libxlutil.so.$(XLUMAJOR).$(XLUMINOR)
>  	$(SYMLINK_SHLIB) $< $@
>  
> -libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS)
> -	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxlutil.so.$(XLUMAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXLU_LIBS) $(APPEND_LDFLAGS)
> +libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS) libxenlight.so
> +	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxlutil.so.$(XLUMAJOR) $(SHLIB_LDFLAGS) -o $@ $(LIBXLU_OBJS) $(LIBXLU_LIBS) $(APPEND_LDFLAGS)
>  
>  libxlutil.a: $(LIBXLU_OBJS)
>  	$(AR) rcs libxlutil.a $^



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:08:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 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 1Y0SZE-0004Bw-OG; Mon, 15 Dec 2014 10:07: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 1Y0SZD-0004Br-JS
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:07:51 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	05/2B-02697-6F2BE845; Mon, 15 Dec 2014 10:07:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418638070!5762235!1
X-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 4927 invoked from network); 15 Dec 2014 10:07:50 -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; 15 Dec 2014 10:07:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 10:07:49 +0000
Message-Id: <548EC102020000780004F810@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 10:07:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418419248-2863-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418419248-2863-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 4.5] x86/VPMU: Clear last_vcpu when
 destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 22:20, <boris.ostrovsky@oracle.com> wrote:
> --- a/xen/arch/x86/hvm/vpmu.c
> +++ b/xen/arch/x86/hvm/vpmu.c
> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
>      }
>  }
>  
> +static void vpmu_clear_last(void *arg)
> +{
> +    struct vcpu *v = (struct vcpu *)arg;

Please drop this pointless cast, or perhaps the entire variable, as ...

> +
> +    if ( this_cpu(last_vcpu) == v )

... you don't really need it to be of "struct vcpu *" type - "void *"
is quite fine for a comparison.

> +        this_cpu(last_vcpu) = NULL;
> +}
> +
>  void vpmu_destroy(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> +    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> +    {
> +        /* Need to clear last_vcpu in case it points to v */
> +        if ( vpmu->last_pcpu != smp_processor_id() )
> +            on_selected_cpus(cpumask_of(vpmu->last_pcpu),
> +                             vpmu_clear_last, (void *)v, 1);

The cast here is pointless too. But considering your subsequent
reply this code may go away altogether anyway; if it doesn't,
explaining (in the commit message) why you need to use an IPI
here would seem necessary.

> +        else
> +        {
> +            local_irq_disable();
> +            vpmu_clear_last((void *)v);

And another pointless cast.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:08:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 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 1Y0SZE-0004Bw-OG; Mon, 15 Dec 2014 10:07: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 1Y0SZD-0004Br-JS
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:07:51 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	05/2B-02697-6F2BE845; Mon, 15 Dec 2014 10:07:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418638070!5762235!1
X-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 4927 invoked from network); 15 Dec 2014 10:07:50 -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; 15 Dec 2014 10:07:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 10:07:49 +0000
Message-Id: <548EC102020000780004F810@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 10:07:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418419248-2863-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418419248-2863-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 4.5] x86/VPMU: Clear last_vcpu when
 destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 22:20, <boris.ostrovsky@oracle.com> wrote:
> --- a/xen/arch/x86/hvm/vpmu.c
> +++ b/xen/arch/x86/hvm/vpmu.c
> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
>      }
>  }
>  
> +static void vpmu_clear_last(void *arg)
> +{
> +    struct vcpu *v = (struct vcpu *)arg;

Please drop this pointless cast, or perhaps the entire variable, as ...

> +
> +    if ( this_cpu(last_vcpu) == v )

... you don't really need it to be of "struct vcpu *" type - "void *"
is quite fine for a comparison.

> +        this_cpu(last_vcpu) = NULL;
> +}
> +
>  void vpmu_destroy(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> +    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> +    {
> +        /* Need to clear last_vcpu in case it points to v */
> +        if ( vpmu->last_pcpu != smp_processor_id() )
> +            on_selected_cpus(cpumask_of(vpmu->last_pcpu),
> +                             vpmu_clear_last, (void *)v, 1);

The cast here is pointless too. But considering your subsequent
reply this code may go away altogether anyway; if it doesn't,
explaining (in the commit message) why you need to use an IPI
here would seem necessary.

> +        else
> +        {
> +            local_irq_disable();
> +            vpmu_clear_last((void *)v);

And another pointless cast.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:11:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Scq-0004Jh-Bl; Mon, 15 Dec 2014 10:11: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 1Y0Sco-0004Jc-VB
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:11:35 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	C7/50-02696-6D3BE845; Mon, 15 Dec 2014 10:11:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418638292!15095038!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 19976 invoked from network); 15 Dec 2014 10:11:33 -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 Dec 2014 10:11:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="scan'208";a="204822483"
Message-ID: <1418638290.16425.66.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 15 Dec 2014 10:11:30 +0000
In-Reply-To: <1418569097-19322-1-git-send-email-wei.liu2@citrix.com>
References: <1418569097-19322-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: libvir-list@redhat.com, jfehlig@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xenconfig: fix boot device parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-14 at 14:58 +0000, Wei Liu wrote:
> The original code always checked *boot which was in effect boot[0]. It
> should use boot[i].
> 
> Signed-off-by: Wei Liu <wei.liu2@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 Mon Dec 15 10:11:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Scq-0004Jh-Bl; Mon, 15 Dec 2014 10:11: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 1Y0Sco-0004Jc-VB
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:11:35 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	C7/50-02696-6D3BE845; Mon, 15 Dec 2014 10:11:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418638292!15095038!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 19976 invoked from network); 15 Dec 2014 10:11:33 -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 Dec 2014 10:11:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="scan'208";a="204822483"
Message-ID: <1418638290.16425.66.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 15 Dec 2014 10:11:30 +0000
In-Reply-To: <1418569097-19322-1-git-send-email-wei.liu2@citrix.com>
References: <1418569097-19322-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: libvir-list@redhat.com, jfehlig@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xenconfig: fix boot device parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-14 at 14:58 +0000, Wei Liu wrote:
> The original code always checked *boot which was in effect boot[0]. It
> should use boot[i].
> 
> Signed-off-by: Wei Liu <wei.liu2@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 Mon Dec 15 10:14:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10: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 1Y0SfL-0004b9-TP; Mon, 15 Dec 2014 10:14: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 1Y0SfL-0004b3-C9
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:14:11 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	93/83-02712-274BE845; Mon, 15 Dec 2014 10:14:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418638449!15099645!1
X-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 10121 invoked from network); 15 Dec 2014 10:14:10 -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; 15 Dec 2014 10:14:10 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 10:14:09 +0000
Message-Id: <548EC27F020000780004F81B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 10:14:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mike Latimer" <mlatimer@suse.com>
References: <3154807.Gz8aOatYUo@linux-4w67.dnsdhcp.provo.novell.com>
In-Reply-To: <3154807.Gz8aOatYUo@linux-4w67.dnsdhcp.provo.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Ballooning dom0: insufficient memory (libxl) or CPU
 soft lockups (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 14.12.14 at 04:20, <mlatimer@suse.com> wrote:
> - If using virsh, the domain can be created while dom0 is still ballooning 
> down. This results in CPU soft lockups/performance degradation across the 
> entire host. (When creating a very large domain, the soft lockups can be 
> severe enough to kill the machine.)

This is an issue that needs handling independent of the tool stack
issues pointed out. Whether we should discuss this here depends
on whether we suspect the problem to be only with our kernels, or
also with upstream's. It's in any event quite odd for there to be
softlockups in the first place, as in the hypervisor the involved
hypercalls are all preemptible afaict. I'll have to go did through the
data you had provided earlier to see whether there's a complete
enough (and readable) log to be able to tell where there's a lack
of re-scheduling in the kernel.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:14:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10: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 1Y0SfL-0004b9-TP; Mon, 15 Dec 2014 10:14: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 1Y0SfL-0004b3-C9
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:14:11 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	93/83-02712-274BE845; Mon, 15 Dec 2014 10:14:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418638449!15099645!1
X-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 10121 invoked from network); 15 Dec 2014 10:14:10 -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; 15 Dec 2014 10:14:10 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 10:14:09 +0000
Message-Id: <548EC27F020000780004F81B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 10:14:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mike Latimer" <mlatimer@suse.com>
References: <3154807.Gz8aOatYUo@linux-4w67.dnsdhcp.provo.novell.com>
In-Reply-To: <3154807.Gz8aOatYUo@linux-4w67.dnsdhcp.provo.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Ballooning dom0: insufficient memory (libxl) or CPU
 soft lockups (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 14.12.14 at 04:20, <mlatimer@suse.com> wrote:
> - If using virsh, the domain can be created while dom0 is still ballooning 
> down. This results in CPU soft lockups/performance degradation across the 
> entire host. (When creating a very large domain, the soft lockups can be 
> severe enough to kill the machine.)

This is an issue that needs handling independent of the tool stack
issues pointed out. Whether we should discuss this here depends
on whether we suspect the problem to be only with our kernels, or
also with upstream's. It's in any event quite odd for there to be
softlockups in the first place, as in the hypervisor the involved
hypercalls are all preemptible afaict. I'll have to go did through the
data you had provided earlier to see whether there's a complete
enough (and readable) log to be able to tell where there's a lack
of re-scheduling in the kernel.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:19:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Sjz-0004kc-Kl; Mon, 15 Dec 2014 10:18:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0Sjy-0004kX-19
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:18:58 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	6E/11-02696-195BE845; Mon, 15 Dec 2014 10:18:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418638734!15069706!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 27534 invoked from network); 15 Dec 2014 10:18:55 -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;
	15 Dec 2014 10:18:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204825603"
Message-ID: <1418638732.16425.70.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 15 Dec 2014 10:18:52 +0000
In-Reply-To: <20141213170605.GD2285@zion.uk.xensource.com>
References: <1411365561-29242-1-git-send-email-wency@cn.fujitsu.com>
	<1411365561-29242-4-git-send-email-wency@cn.fujitsu.com>
	<CAFLBxZbzSAFSZZrW9p+Gz-VTbts+q4Z1xT_+d9jrYJ8jjXVy8g@mail.gmail.com>
	<20141213170605.GD2285@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan
	Beulich <JBeulich@suse.com>, Wen Congyang <wency@cn.fujitsu.com>,
	xen devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC Patch v4 3/9] pass correct file to qemu if we
 use blktap2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-13 at 17:06 +0000, Wei Liu wrote:
> On Thu, Dec 11, 2014 at 04:45:09PM +0000, George Dunlap wrote:
> > On Mon, Sep 22, 2014 at 6:59 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
> > > If we use blktap2, the correct file should be blktap device
> > > not the pdev_path.
> > >
> > > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> > > Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > If I'm reading this correctly, this is actually a fairly serious bug
> > in libxl -- it means that when using backend=tap with HVM domains,
> > qemu will actually *bypass entirely* the tapdisk process and access
> > the underlying file directly.
> > 
> 
> Is it because qemu will corrupt the underlying file so it's very
> serious? 

I think it ends up being reasonably safe due to the unplug stuff, in
general only one of the two paths should be active at any given time and
there is appropriate flushing/syncing on the unplug etc.

In fact, I'm not 100% sure this wasn't a deliberate design decision at
one point to avoid the overhead of doing both qdisk and tapdisk. (I'm
not going to argue that this still makes sense though).

If qemu is corrupting files then that's a different matter, which would
indeed be serious, and which this change might paper over/avoid.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:19:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Sjz-0004kc-Kl; Mon, 15 Dec 2014 10:18:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0Sjy-0004kX-19
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:18:58 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	6E/11-02696-195BE845; Mon, 15 Dec 2014 10:18:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418638734!15069706!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 27534 invoked from network); 15 Dec 2014 10:18:55 -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;
	15 Dec 2014 10:18:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204825603"
Message-ID: <1418638732.16425.70.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 15 Dec 2014 10:18:52 +0000
In-Reply-To: <20141213170605.GD2285@zion.uk.xensource.com>
References: <1411365561-29242-1-git-send-email-wency@cn.fujitsu.com>
	<1411365561-29242-4-git-send-email-wency@cn.fujitsu.com>
	<CAFLBxZbzSAFSZZrW9p+Gz-VTbts+q4Z1xT_+d9jrYJ8jjXVy8g@mail.gmail.com>
	<20141213170605.GD2285@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan
	Beulich <JBeulich@suse.com>, Wen Congyang <wency@cn.fujitsu.com>,
	xen devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC Patch v4 3/9] pass correct file to qemu if we
 use blktap2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-13 at 17:06 +0000, Wei Liu wrote:
> On Thu, Dec 11, 2014 at 04:45:09PM +0000, George Dunlap wrote:
> > On Mon, Sep 22, 2014 at 6:59 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
> > > If we use blktap2, the correct file should be blktap device
> > > not the pdev_path.
> > >
> > > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> > > Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > If I'm reading this correctly, this is actually a fairly serious bug
> > in libxl -- it means that when using backend=tap with HVM domains,
> > qemu will actually *bypass entirely* the tapdisk process and access
> > the underlying file directly.
> > 
> 
> Is it because qemu will corrupt the underlying file so it's very
> serious? 

I think it ends up being reasonably safe due to the unplug stuff, in
general only one of the two paths should be active at any given time and
there is appropriate flushing/syncing on the unplug etc.

In fact, I'm not 100% sure this wasn't a deliberate design decision at
one point to avoid the overhead of doing both qdisk and tapdisk. (I'm
not going to argue that this still makes sense though).

If qemu is corrupting files then that's a different matter, which would
indeed be serious, and which this change might paper over/avoid.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:31:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10:31:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Svj-000545-Sr; Mon, 15 Dec 2014 10:31: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 1Y0Svi-00053x-0i
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 10:31:06 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	53/AB-24124-968BE845; Mon, 15 Dec 2014 10:31:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418639462!13396890!1
X-Originating-IP: [66.165.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 3451 invoked from network); 15 Dec 2014 10:31:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 10:31:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204375061"
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.210.2; Mon, 15 Dec 2014 05:31: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 1Y0Svd-0000Dc-CT;
	Mon, 15 Dec 2014 10:31:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0Svd-0000CQ-7b;
	Mon, 15 Dec 2014 10:31:01 +0000
Date: Mon, 15 Dec 2014 10:31:01 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32374-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] 32374: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32374 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32374/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   5 xen-build                 fail REGR. vs. 31241
 build-i386-pvops              5 kernel-build              fail REGR. vs. 31241
 build-i386                    5 xen-build                 fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  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-amd64-rumpuserxen-amd64  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
 build-amd64-rumpuserxen       1 build-check(1)               blocked  n/a
 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-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      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-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  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
 build-i386-rumpuserxen        1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf      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
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 build-amd64-libvirt           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-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-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-pair         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-win7-amd64  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-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-amd64-xl-qemut-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-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-amd64-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-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)               blocked n/a

version targeted for testing:
 linux                e6b5be2be4e30037eb551e0ed09dd97bd00d85d3
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1658 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-libvirt                                          blocked 
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 build-amd64-rumpuserxen                                      blocked 
 build-i386-rumpuserxen                                       blocked 
 test-amd64-amd64-xl                                          blocked 
 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                    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-rumpuserxen-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-i386-rumpuserxen-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.

(No revision log; it would be 176250 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 Dec 15 10:31:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10:31:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Svj-000545-Sr; Mon, 15 Dec 2014 10:31: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 1Y0Svi-00053x-0i
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 10:31:06 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	53/AB-24124-968BE845; Mon, 15 Dec 2014 10:31:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418639462!13396890!1
X-Originating-IP: [66.165.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 3451 invoked from network); 15 Dec 2014 10:31:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 10:31:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204375061"
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.210.2; Mon, 15 Dec 2014 05:31: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 1Y0Svd-0000Dc-CT;
	Mon, 15 Dec 2014 10:31:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0Svd-0000CQ-7b;
	Mon, 15 Dec 2014 10:31:01 +0000
Date: Mon, 15 Dec 2014 10:31:01 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32374-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] 32374: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32374 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32374/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   5 xen-build                 fail REGR. vs. 31241
 build-i386-pvops              5 kernel-build              fail REGR. vs. 31241
 build-i386                    5 xen-build                 fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           9 guest-start                  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-amd64-rumpuserxen-amd64  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
 build-amd64-rumpuserxen       1 build-check(1)               blocked  n/a
 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-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      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-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  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
 build-i386-rumpuserxen        1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf      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
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 build-amd64-libvirt           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-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-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-pair         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-win7-amd64  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-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-amd64-xl-qemut-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-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-amd64-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-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)               blocked n/a

version targeted for testing:
 linux                e6b5be2be4e30037eb551e0ed09dd97bd00d85d3
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1658 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-libvirt                                          blocked 
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 build-amd64-rumpuserxen                                      blocked 
 build-i386-rumpuserxen                                       blocked 
 test-amd64-amd64-xl                                          blocked 
 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                    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-rumpuserxen-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-i386-rumpuserxen-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.

(No revision log; it would be 176250 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 Dec 15 10:44:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10: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 1Y0T8l-0005Zj-8s; Mon, 15 Dec 2014 10:44: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 1Y0T8j-0005Ze-Tc
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:44:34 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	4C/14-14727-19BBE845; Mon, 15 Dec 2014 10:44:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418640270!13376495!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 781 invoked from network); 15 Dec 2014 10:44:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 10:44:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204378995"
Message-ID: <1418640268.16425.79.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <jbeulich@suse.com>, Keir Fraser <keir@xen.org>
Date: Mon, 15 Dec 2014 10:44:28 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Lots of ACPI warnings from newer iasl (20140926).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

isal 20140926-1 in Debian Jessie is rather vocal about
tools/firmware/hvmloader/acpi. See below. Essentially, a few of these:
        Control Method should be made Serialized (due to creation of
        named objects within)
a slew of:
        Object is not referenced ^  (Name is within method [_CRS])
and a load of:
        ^ Reserved method should not return a value (_L02)

4.4 seems to produce a similar looking set of warnings, so I think this
is a case of newer iasl having more warnings rather than a regression in
our code.

I also tried iasl from 20141107-1 Sid and it is similarly vocal.

Ian.

make: Entering directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader'
make[1]: Entering directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader'
make -C acpi all
make[2]: Entering directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi'
iasl -vs -p ssdt_s3 -tc ssdt_s3.asl
ASL Input:     ssdt_s3.asl - 33 lines, 172 bytes, 1 keywords
AML Output:    ssdt_s3.aml - 49 bytes, 1 named objects, 0 executable opcodes
Hex Dump:      ssdt_s3.hex - 844 bytes

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 4 Optimizations
sed -e 's/AmlCode/ssdt_s3/g' ssdt_s3.hex >ssdt_s3.h
rm -f ssdt_s3.hex ssdt_s3.aml
iasl -vs -p ssdt_s4 -tc ssdt_s4.asl
ASL Input:     ssdt_s4.asl - 33 lines, 172 bytes, 1 keywords
AML Output:    ssdt_s4.aml - 49 bytes, 1 named objects, 0 executable opcodes
Hex Dump:      ssdt_s4.hex - 844 bytes

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 4 Optimizations
sed -e 's/AmlCode/ssdt_s4/g' ssdt_s4.hex >ssdt_s4.h
rm -f ssdt_s4.hex ssdt_s4.aml
iasl -vs -p ssdt_pm -tc ssdt_pm.asl
ssdt_pm.asl    281:         Method (HLPA, 0, NotSerialized)
Remark   2120 -                       ^ Control Method should be made Serialized (due to creation of named objects within)

ssdt_pm.asl    368:             Method (_BST, 0, NotSerialized)
Remark   2120 -                           ^ Control Method should be made Serialized (due to creation of named objects within)

ssdt_pm.asl    406:             Method (_BST, 0, NotSerialized)
Remark   2120 -                           ^ Control Method should be made Serialized (due to creation of named objects within)

ASL Input:     ssdt_pm.asl - 424 lines, 8311 bytes, 192 keywords
AML Output:    ssdt_pm.aml - 1494 bytes, 64 named objects, 128 executable opcodes
Hex Dump:      ssdt_pm.hex - 14345 bytes

Compilation complete. 0 Errors, 0 Warnings, 3 Remarks, 31 Optimizations
sed -e 's/AmlCode/ssdt_pm/g' ssdt_pm.hex >ssdt_pm.h
rm -f ssdt_pm.hex ssdt_pm.aml
iasl -vs -p ssdt_tpm -tc ssdt_tpm.asl
ASL Input:     ssdt_tpm.asl - 33 lines, 250 bytes, 3 keywords
AML Output:    ssdt_tpm.aml - 76 bytes, 3 named objects, 0 executable opcodes
Hex Dump:      ssdt_tpm.hex - 1070 bytes

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
sed -e 's/AmlCode/ssdt_tpm/g' ssdt_tpm.hex >ssdt_tpm.h
rm -f ssdt_tpm.hex ssdt_tpm.aml
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .build.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi/../../../../tools/include  -c -o build.o build.c 
gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -Wdeclaration-after-statement -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi/../../../../tools/include -o mk_dsdt mk_dsdt.c
awk 'NR > 1 {print s} {s=$0}' dsdt.asl > dsdt_anycpu.asl
./mk_dsdt --maxcpu any  >> dsdt_anycpu.asl
iasl -vs -p dsdt_anycpu -tc dsdt_anycpu.asl
dsdt_anycpu.asl    110:            Method (_CRS, 0, NotSerialized)
Remark   2120 -                              ^ Control Method should be made Serialized (due to creation of named objects within)

dsdt_anycpu.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                           Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                     Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    152:                         NonCacheable, ReadWrite,
Remark   2089 -                  Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    152:                         NonCacheable, ReadWrite,
Remark   2089 -                             Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    153:                         0x00000000,
Remark   2089 -                Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    156:                         0x00000000,
Remark   2089 -                Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    158:                         ,, _Y01)
Remark   2089 -              Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    158:                         ,, _Y01)
Remark   2089 -              Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                           Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                     Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    162:                         NonCacheable, ReadWrite,
Remark   2089 -                  Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    162:                         NonCacheable, ReadWrite,
Remark   2089 -                             Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    163:                         0x0000000000000000,
Remark   2089 -                        Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    165:                         0x0000000FFFFFFFFF,
Remark   2089 -                        Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    166:                         0x0000000000000000,
Remark   2089 -                        Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    167:                         0x0000000000000010,
Remark   2089 -                        Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    168:                         ,, _Y02)
Remark   2089 -              Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    168:                         ,, _Y02)
Remark   2089 -              Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl   5360:             Return ( \_SB.PRSC() )
Warning  3104 -                                     ^ Reserved method should not return a value (_L02)

ASL Input:     dsdt_anycpu.asl - 11013 lines, 387593 bytes, 8007 keywords
AML Output:    dsdt_anycpu.aml - 70833 bytes, 2470 named objects, 5537 executable opcodes
Hex Dump:      dsdt_anycpu.hex - 664451 bytes

Compilation complete. 0 Errors, 1 Warnings, 21 Remarks, 2630 Optimizations
sed -e 's/AmlCode/dsdt_anycpu/g' dsdt_anycpu.hex >dsdt_anycpu.c
echo "int dsdt_anycpu_len=sizeof(dsdt_anycpu);" >>dsdt_anycpu.c
rm -f dsdt_anycpu.aml dsdt_anycpu.hex
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .dsdt_anycpu.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi/../../../../tools/include  -c -o dsdt_anycpu.o dsdt_anycpu.c 
awk 'NR > 1 {print s} {s=$0}' dsdt.asl > dsdt_15cpu.asl
./mk_dsdt --maxcpu 15  >> dsdt_15cpu.asl
iasl -vs -p dsdt_15cpu -tc dsdt_15cpu.asl
dsdt_15cpu.asl    110:            Method (_CRS, 0, NotSerialized)
Remark   2120 -                             ^ Control Method should be made Serialized (due to creation of named objects within)

dsdt_15cpu.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                          Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                    Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    152:                         NonCacheable, ReadWrite,
Remark   2089 -                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    152:                         NonCacheable, ReadWrite,
Remark   2089 -                            Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    153:                         0x00000000,
Remark   2089 -               Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    156:                         0x00000000,
Remark   2089 -               Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    158:                         ,, _Y01)
Remark   2089 -             Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    158:                         ,, _Y01)
Remark   2089 -             Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                          Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                    Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    162:                         NonCacheable, ReadWrite,
Remark   2089 -                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    162:                         NonCacheable, ReadWrite,
Remark   2089 -                            Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    163:                         0x0000000000000000,
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    165:                         0x0000000FFFFFFFFF,
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    166:                         0x0000000000000000,
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    167:                         0x0000000000000010,
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    168:                         ,, _Y02)
Remark   2089 -             Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    168:                         ,, _Y02)
Remark   2089 -             Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl   1066:             Return ( \_SB.PRSC() )
Warning  3104 -                                    ^ Reserved method should not return a value (_L02)

ASL Input:     dsdt_15cpu.asl - 6719 lines, 245586 bytes, 4815 keywords
AML Output:    dsdt_15cpu.aml - 48530 bytes, 1566 named objects, 3249 executable opcodes
Hex Dump:      dsdt_15cpu.hex - 455349 bytes

Compilation complete. 0 Errors, 1 Warnings, 21 Remarks, 1062 Optimizations
sed -e 's/AmlCode/dsdt_15cpu/g' dsdt_15cpu.hex >dsdt_15cpu.c
echo "int dsdt_15cpu_len=sizeof(dsdt_15cpu);" >>dsdt_15cpu.c
rm -f dsdt_15cpu.aml dsdt_15cpu.hex
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .dsdt_15cpu.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi/../../../../tools/include  -c -o dsdt_15cpu.o dsdt_15cpu.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .static_tables.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi/../../../../tools/include  -c -o static_tables.o static_tables.c 
awk 'NR > 1 {print s} {s=$0}' dsdt.asl > dsdt_anycpu_qemu_xen.asl
./mk_dsdt --dm-version qemu-xen >> dsdt_anycpu_qemu_xen.asl
iasl -vs -p dsdt_anycpu_qemu_xen -tc dsdt_anycpu_qemu_xen.asl
dsdt_anycpu_qemu_xen.asl    110:            Method (_CRS, 0, NotSerialized)
Remark   2120 -                                       ^ Control Method should be made Serialized (due to creation of named objects within)

dsdt_anycpu_qemu_xen.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                          Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                    Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                              Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    152:                         NonCacheable, ReadWrite,
Remark   2089 -                           Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    152:                         NonCacheable, ReadWrite,
Remark   2089 -                                      Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    153:                         0x00000000,
Remark   2089 -                         Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    156:                         0x00000000,
Remark   2089 -                         Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    158:                         ,, _Y01)
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    158:                         ,, _Y01)
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                          Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                    Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                              Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    162:                         NonCacheable, ReadWrite,
Remark   2089 -                           Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    162:                         NonCacheable, ReadWrite,
Remark   2089 -                                      Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    163:                         0x0000000000000000,
Remark   2089 -                                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    165:                         0x0000000FFFFFFFFF,
Remark   2089 -                                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    166:                         0x0000000000000000,
Remark   2089 -                                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    167:                         0x0000000000000010,
Remark   2089 -                                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    168:                         ,, _Y02)
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    168:                         ,, _Y02)
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl   5360:             Return ( \_SB.PRSC() )
Warning  3104 -    Reserved method should not return a value ^  (_E02)

dsdt_anycpu_qemu_xen.asl   5753:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5761:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5769:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5777:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5785:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5793:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5801:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5809:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5817:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5825:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5833:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5841:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5849:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5857:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5865:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5873:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5881:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5889:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5897:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5905:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5913:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5921:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5929:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5937:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5945:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5953:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5961:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5969:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5977:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5985:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5993:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

ASL Input:     dsdt_anycpu_qemu_xen.asl - 6199 lines, 204324 bytes, 4373 keywords
AML Output:    dsdt_anycpu_qemu_xen.aml - 34545 bytes, 1314 named objects, 3059 executable opcodes
Hex Dump:      dsdt_anycpu_qemu_xen.hex - 324259 bytes

Compilation complete. 0 Errors, 32 Warnings, 21 Remarks, 2602 Optimizations
sed -e 's/AmlCode/dsdt_anycpu_qemu_xen/g' dsdt_anycpu_qemu_xen.hex >dsdt_anycpu_qemu_xen.c
echo "int dsdt_anycpu_qemu_xen_len=sizeof(dsdt_anycpu_qemu_xen);" >>dsdt_anycpu_qemu_xen.c
rm -f dsdt_anycpu_qemu_xen.aml dsdt_anycpu_qemu_xen.hex
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .dsdt_anycpu_qemu_xen.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi/../../../../tools/include  -c -o dsdt_anycpu_qemu_xen.o dsdt_anycpu_qemu_xen.c 
ar rc acpi.a build.o dsdt_anycpu.o dsdt_15cpu.o static_tables.o dsdt_anycpu_qemu_xen.o
make[2]: Leaving directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi'
make[1]: Leaving directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader'
make hvmloader
make[1]: Entering directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader'
echo "/* Autogenerated file. DO NOT EDIT */" > roms.inc.new
echo "#ifdef ROM_INCLUDE_ROMBIOS" >> roms.inc.new
sh ./mkhex rombios ../rombios/BIOS-bochs-latest >> roms.inc.new
echo "#endif" >> roms.inc.new
echo "#ifdef ROM_INCLUDE_SEABIOS" >> roms.inc.new
sh ./mkhex seabios ../seabios-dir/out/bios.bin >> roms.inc.new
echo "#endif" >> roms.inc.new
echo "#ifdef ROM_INCLUDE_VGABIOS" >> roms.inc.new
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.inc.new
echo "#endif" >> roms.inc.new
echo "#ifdef ROM_INCLUDE_VGABIOS" >> roms.inc.new
sh ./mkhex vgabios_cirrusvga ../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.inc.new
echo "#endif" >> roms.inc.new
echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> roms.inc.new
sh ./mkhex etherboot ../etherboot/ipxe/src/bin/rtl8139.rom ../etherboot/ipxe/src/bin/8086100e.rom >> roms.inc.new
echo "#endif" >> roms.inc.new
mv roms.inc.new roms.inc
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .hvmloader.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o hvmloader.o hvmloader.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .mp_tables.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o mp_tables.o mp_tables.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .util.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o util.o util.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .smbios.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS -D__SMBIOS_DATE__="\"12/15/2014\""  -c -o smbios.o smbios.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .smp.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o smp.o smp.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .cacheattr.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o cacheattr.o cacheattr.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .xenbus.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o xenbus.o xenbus.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .e820.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o e820.o e820.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .pci.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o pci.o pci.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .pir.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o pir.o pir.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .ctype.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o ctype.o ctype.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .hvm_param.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o hvm_param.o hvm_param.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .tests.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o tests.o tests.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .optionroms.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o optionroms.o optionroms.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .32bitbios_support.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o 32bitbios_support.o 32bitbios_support.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .rombios.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o rombios.o rombios.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .seabios.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o seabios.o seabios.c 
ld -melf_i386 -N -Ttext 0x100000 -o hvmloader.tmp hvmloader.o mp_tables.o util.o smbios.o smp.o cacheattr.o xenbus.o e820.o pci.o pir.o ctype.o hvm_param.o tests.o optionroms.o 32bitbios_support.o rombios.o seabios.o acpi/acpi.a
objcopy hvmloader.tmp hvmloader
rm -f hvmloader.tmp
make[1]: Leaving directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader'
make: Leaving directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader'



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:44:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10: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 1Y0T8l-0005Zj-8s; Mon, 15 Dec 2014 10:44: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 1Y0T8j-0005Ze-Tc
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:44:34 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	4C/14-14727-19BBE845; Mon, 15 Dec 2014 10:44:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418640270!13376495!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 781 invoked from network); 15 Dec 2014 10:44:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 10:44:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204378995"
Message-ID: <1418640268.16425.79.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <jbeulich@suse.com>, Keir Fraser <keir@xen.org>
Date: Mon, 15 Dec 2014 10:44:28 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Lots of ACPI warnings from newer iasl (20140926).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

isal 20140926-1 in Debian Jessie is rather vocal about
tools/firmware/hvmloader/acpi. See below. Essentially, a few of these:
        Control Method should be made Serialized (due to creation of
        named objects within)
a slew of:
        Object is not referenced ^  (Name is within method [_CRS])
and a load of:
        ^ Reserved method should not return a value (_L02)

4.4 seems to produce a similar looking set of warnings, so I think this
is a case of newer iasl having more warnings rather than a regression in
our code.

I also tried iasl from 20141107-1 Sid and it is similarly vocal.

Ian.

make: Entering directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader'
make[1]: Entering directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader'
make -C acpi all
make[2]: Entering directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi'
iasl -vs -p ssdt_s3 -tc ssdt_s3.asl
ASL Input:     ssdt_s3.asl - 33 lines, 172 bytes, 1 keywords
AML Output:    ssdt_s3.aml - 49 bytes, 1 named objects, 0 executable opcodes
Hex Dump:      ssdt_s3.hex - 844 bytes

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 4 Optimizations
sed -e 's/AmlCode/ssdt_s3/g' ssdt_s3.hex >ssdt_s3.h
rm -f ssdt_s3.hex ssdt_s3.aml
iasl -vs -p ssdt_s4 -tc ssdt_s4.asl
ASL Input:     ssdt_s4.asl - 33 lines, 172 bytes, 1 keywords
AML Output:    ssdt_s4.aml - 49 bytes, 1 named objects, 0 executable opcodes
Hex Dump:      ssdt_s4.hex - 844 bytes

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 4 Optimizations
sed -e 's/AmlCode/ssdt_s4/g' ssdt_s4.hex >ssdt_s4.h
rm -f ssdt_s4.hex ssdt_s4.aml
iasl -vs -p ssdt_pm -tc ssdt_pm.asl
ssdt_pm.asl    281:         Method (HLPA, 0, NotSerialized)
Remark   2120 -                       ^ Control Method should be made Serialized (due to creation of named objects within)

ssdt_pm.asl    368:             Method (_BST, 0, NotSerialized)
Remark   2120 -                           ^ Control Method should be made Serialized (due to creation of named objects within)

ssdt_pm.asl    406:             Method (_BST, 0, NotSerialized)
Remark   2120 -                           ^ Control Method should be made Serialized (due to creation of named objects within)

ASL Input:     ssdt_pm.asl - 424 lines, 8311 bytes, 192 keywords
AML Output:    ssdt_pm.aml - 1494 bytes, 64 named objects, 128 executable opcodes
Hex Dump:      ssdt_pm.hex - 14345 bytes

Compilation complete. 0 Errors, 0 Warnings, 3 Remarks, 31 Optimizations
sed -e 's/AmlCode/ssdt_pm/g' ssdt_pm.hex >ssdt_pm.h
rm -f ssdt_pm.hex ssdt_pm.aml
iasl -vs -p ssdt_tpm -tc ssdt_tpm.asl
ASL Input:     ssdt_tpm.asl - 33 lines, 250 bytes, 3 keywords
AML Output:    ssdt_tpm.aml - 76 bytes, 3 named objects, 0 executable opcodes
Hex Dump:      ssdt_tpm.hex - 1070 bytes

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
sed -e 's/AmlCode/ssdt_tpm/g' ssdt_tpm.hex >ssdt_tpm.h
rm -f ssdt_tpm.hex ssdt_tpm.aml
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .build.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi/../../../../tools/include  -c -o build.o build.c 
gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -Wdeclaration-after-statement -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi/../../../../tools/include -o mk_dsdt mk_dsdt.c
awk 'NR > 1 {print s} {s=$0}' dsdt.asl > dsdt_anycpu.asl
./mk_dsdt --maxcpu any  >> dsdt_anycpu.asl
iasl -vs -p dsdt_anycpu -tc dsdt_anycpu.asl
dsdt_anycpu.asl    110:            Method (_CRS, 0, NotSerialized)
Remark   2120 -                              ^ Control Method should be made Serialized (due to creation of named objects within)

dsdt_anycpu.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                           Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                     Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    152:                         NonCacheable, ReadWrite,
Remark   2089 -                  Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    152:                         NonCacheable, ReadWrite,
Remark   2089 -                             Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    153:                         0x00000000,
Remark   2089 -                Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    156:                         0x00000000,
Remark   2089 -                Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    158:                         ,, _Y01)
Remark   2089 -              Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    158:                         ,, _Y01)
Remark   2089 -              Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                           Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                     Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    162:                         NonCacheable, ReadWrite,
Remark   2089 -                  Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    162:                         NonCacheable, ReadWrite,
Remark   2089 -                             Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    163:                         0x0000000000000000,
Remark   2089 -                        Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    165:                         0x0000000FFFFFFFFF,
Remark   2089 -                        Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    166:                         0x0000000000000000,
Remark   2089 -                        Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    167:                         0x0000000000000010,
Remark   2089 -                        Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    168:                         ,, _Y02)
Remark   2089 -              Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl    168:                         ,, _Y02)
Remark   2089 -              Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu.asl   5360:             Return ( \_SB.PRSC() )
Warning  3104 -                                     ^ Reserved method should not return a value (_L02)

ASL Input:     dsdt_anycpu.asl - 11013 lines, 387593 bytes, 8007 keywords
AML Output:    dsdt_anycpu.aml - 70833 bytes, 2470 named objects, 5537 executable opcodes
Hex Dump:      dsdt_anycpu.hex - 664451 bytes

Compilation complete. 0 Errors, 1 Warnings, 21 Remarks, 2630 Optimizations
sed -e 's/AmlCode/dsdt_anycpu/g' dsdt_anycpu.hex >dsdt_anycpu.c
echo "int dsdt_anycpu_len=sizeof(dsdt_anycpu);" >>dsdt_anycpu.c
rm -f dsdt_anycpu.aml dsdt_anycpu.hex
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .dsdt_anycpu.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi/../../../../tools/include  -c -o dsdt_anycpu.o dsdt_anycpu.c 
awk 'NR > 1 {print s} {s=$0}' dsdt.asl > dsdt_15cpu.asl
./mk_dsdt --maxcpu 15  >> dsdt_15cpu.asl
iasl -vs -p dsdt_15cpu -tc dsdt_15cpu.asl
dsdt_15cpu.asl    110:            Method (_CRS, 0, NotSerialized)
Remark   2120 -                             ^ Control Method should be made Serialized (due to creation of named objects within)

dsdt_15cpu.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                          Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                    Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    152:                         NonCacheable, ReadWrite,
Remark   2089 -                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    152:                         NonCacheable, ReadWrite,
Remark   2089 -                            Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    153:                         0x00000000,
Remark   2089 -               Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    156:                         0x00000000,
Remark   2089 -               Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    158:                         ,, _Y01)
Remark   2089 -             Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    158:                         ,, _Y01)
Remark   2089 -             Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                          Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                    Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    162:                         NonCacheable, ReadWrite,
Remark   2089 -                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    162:                         NonCacheable, ReadWrite,
Remark   2089 -                            Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    163:                         0x0000000000000000,
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    165:                         0x0000000FFFFFFFFF,
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    166:                         0x0000000000000000,
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    167:                         0x0000000000000010,
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    168:                         ,, _Y02)
Remark   2089 -             Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl    168:                         ,, _Y02)
Remark   2089 -             Object is not referenced ^  (Name is within method [_CRS])

dsdt_15cpu.asl   1066:             Return ( \_SB.PRSC() )
Warning  3104 -                                    ^ Reserved method should not return a value (_L02)

ASL Input:     dsdt_15cpu.asl - 6719 lines, 245586 bytes, 4815 keywords
AML Output:    dsdt_15cpu.aml - 48530 bytes, 1566 named objects, 3249 executable opcodes
Hex Dump:      dsdt_15cpu.hex - 455349 bytes

Compilation complete. 0 Errors, 1 Warnings, 21 Remarks, 1062 Optimizations
sed -e 's/AmlCode/dsdt_15cpu/g' dsdt_15cpu.hex >dsdt_15cpu.c
echo "int dsdt_15cpu_len=sizeof(dsdt_15cpu);" >>dsdt_15cpu.c
rm -f dsdt_15cpu.aml dsdt_15cpu.hex
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .dsdt_15cpu.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi/../../../../tools/include  -c -o dsdt_15cpu.o dsdt_15cpu.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .static_tables.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi/../../../../tools/include  -c -o static_tables.o static_tables.c 
awk 'NR > 1 {print s} {s=$0}' dsdt.asl > dsdt_anycpu_qemu_xen.asl
./mk_dsdt --dm-version qemu-xen >> dsdt_anycpu_qemu_xen.asl
iasl -vs -p dsdt_anycpu_qemu_xen -tc dsdt_anycpu_qemu_xen.asl
dsdt_anycpu_qemu_xen.asl    110:            Method (_CRS, 0, NotSerialized)
Remark   2120 -                                       ^ Control Method should be made Serialized (due to creation of named objects within)

dsdt_anycpu_qemu_xen.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                          Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                    Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    151:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                              Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    152:                         NonCacheable, ReadWrite,
Remark   2089 -                           Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    152:                         NonCacheable, ReadWrite,
Remark   2089 -                                      Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    153:                         0x00000000,
Remark   2089 -                         Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    156:                         0x00000000,
Remark   2089 -                         Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    158:                         ,, _Y01)
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    158:                         ,, _Y01)
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                          Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                    Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    161:                         ResourceProducer, PosDecode, MinFixed, MaxFixed,
Remark   2089 -                                                              Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    162:                         NonCacheable, ReadWrite,
Remark   2089 -                           Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    162:                         NonCacheable, ReadWrite,
Remark   2089 -                                      Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    163:                         0x0000000000000000,
Remark   2089 -                                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    165:                         0x0000000FFFFFFFFF,
Remark   2089 -                                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    166:                         0x0000000000000000,
Remark   2089 -                                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    167:                         0x0000000000000010,
Remark   2089 -                                 Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    168:                         ,, _Y02)
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl    168:                         ,, _Y02)
Remark   2089 -                       Object is not referenced ^  (Name is within method [_CRS])

dsdt_anycpu_qemu_xen.asl   5360:             Return ( \_SB.PRSC() )
Warning  3104 -    Reserved method should not return a value ^  (_E02)

dsdt_anycpu_qemu_xen.asl   5753:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5761:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5769:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5777:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5785:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5793:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5801:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5809:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5817:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5825:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5833:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5841:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5849:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5857:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5865:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5873:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5881:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5889:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5897:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5905:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5913:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5921:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5929:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5937:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5945:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5953:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5961:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5969:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5977:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5985:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

dsdt_anycpu_qemu_xen.asl   5993:                 Return ( 0x0 )
Warning  3104 -  Reserved method should not return a value ^  (_EJ0)

ASL Input:     dsdt_anycpu_qemu_xen.asl - 6199 lines, 204324 bytes, 4373 keywords
AML Output:    dsdt_anycpu_qemu_xen.aml - 34545 bytes, 1314 named objects, 3059 executable opcodes
Hex Dump:      dsdt_anycpu_qemu_xen.hex - 324259 bytes

Compilation complete. 0 Errors, 32 Warnings, 21 Remarks, 2602 Optimizations
sed -e 's/AmlCode/dsdt_anycpu_qemu_xen/g' dsdt_anycpu_qemu_xen.hex >dsdt_anycpu_qemu_xen.c
echo "int dsdt_anycpu_qemu_xen_len=sizeof(dsdt_anycpu_qemu_xen);" >>dsdt_anycpu_qemu_xen.c
rm -f dsdt_anycpu_qemu_xen.aml dsdt_anycpu_qemu_xen.hex
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .dsdt_anycpu_qemu_xen.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi/../../../../tools/include  -c -o dsdt_anycpu_qemu_xen.o dsdt_anycpu_qemu_xen.c 
ar rc acpi.a build.o dsdt_anycpu.o dsdt_15cpu.o static_tables.o dsdt_anycpu_qemu_xen.o
make[2]: Leaving directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/acpi'
make[1]: Leaving directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader'
make hvmloader
make[1]: Entering directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader'
echo "/* Autogenerated file. DO NOT EDIT */" > roms.inc.new
echo "#ifdef ROM_INCLUDE_ROMBIOS" >> roms.inc.new
sh ./mkhex rombios ../rombios/BIOS-bochs-latest >> roms.inc.new
echo "#endif" >> roms.inc.new
echo "#ifdef ROM_INCLUDE_SEABIOS" >> roms.inc.new
sh ./mkhex seabios ../seabios-dir/out/bios.bin >> roms.inc.new
echo "#endif" >> roms.inc.new
echo "#ifdef ROM_INCLUDE_VGABIOS" >> roms.inc.new
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.inc.new
echo "#endif" >> roms.inc.new
echo "#ifdef ROM_INCLUDE_VGABIOS" >> roms.inc.new
sh ./mkhex vgabios_cirrusvga ../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.inc.new
echo "#endif" >> roms.inc.new
echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> roms.inc.new
sh ./mkhex etherboot ../etherboot/ipxe/src/bin/rtl8139.rom ../etherboot/ipxe/src/bin/8086100e.rom >> roms.inc.new
echo "#endif" >> roms.inc.new
mv roms.inc.new roms.inc
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .hvmloader.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o hvmloader.o hvmloader.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .mp_tables.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o mp_tables.o mp_tables.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .util.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o util.o util.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .smbios.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS -D__SMBIOS_DATE__="\"12/15/2014\""  -c -o smbios.o smbios.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .smp.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o smp.o smp.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .cacheattr.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o cacheattr.o cacheattr.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .xenbus.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o xenbus.o xenbus.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .e820.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o e820.o e820.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .pci.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o pci.o pci.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .pir.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o pir.o pir.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .ctype.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o ctype.o ctype.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .hvm_param.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o hvm_param.o hvm_param.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .tests.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o tests.o tests.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .optionroms.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o optionroms.o optionroms.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .32bitbios_support.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o 32bitbios_support.o 32bitbios_support.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .rombios.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o rombios.o rombios.c 
gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -D__XEN_TOOLS__ -MMD -MF .seabios.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float -I/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader/../../../tools/include -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o seabios.o seabios.c 
ld -melf_i386 -N -Ttext 0x100000 -o hvmloader.tmp hvmloader.o mp_tables.o util.o smbios.o smp.o cacheattr.o xenbus.o e820.o pci.o pir.o ctype.o hvm_param.o tests.o optionroms.o 32bitbios_support.o rombios.o seabios.o acpi/acpi.a
objcopy hvmloader.tmp hvmloader
rm -f hvmloader.tmp
make[1]: Leaving directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader'
make: Leaving directory '/local/scratch/ianc/devel/xen.git/tools/firmware/hvmloader'



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:47:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 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 1Y0TBh-0005iJ-30; Mon, 15 Dec 2014 10:47: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 1Y0TBf-0005iB-Hg
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:47:36 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	98/FC-25727-64CBE845; Mon, 15 Dec 2014 10:47:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418640452!13416004!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 1287 invoked from network); 15 Dec 2014 10:47: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 Dec 2014 10:47:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204379785"
Message-ID: <1418640450.16425.82.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 15 Dec 2014 10:47:30 +0000
In-Reply-To: <1418489645-7689-1-git-send-email-wei.liu2@citrix.com>
References: <1418489645-7689-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: tlviewer@yahoo.com, M A Young <m.a.young@durham.ac.uk>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-13 at 16:54 +0000, Wei Liu wrote:
> In commit d36a3734a ("xl: fix migration failure with xl migrate
> --debug"), message is printed to stderr for both debug mode
> and dryrun mode. That caused rdname() in xendomains fails to parse
> domain name since it's expecting input from xl's stdout.
> 
> So this patch separates those two cases. If xl is running in debug mode,
> then message is printed to stderr; if xl is running in dryrun mode and
> debug is not enabled, message is printed to stdout. This will fix
> xendomains and other scripts that use "xl create --dryrun", as well as
> not re-introducing the old bug fixed in d36a3734a.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: M A Young <m.a.young@durham.ac.uk>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Konrad Wilk <konrad.wilk@oracle.com>
> ---
> This is a regression, and this bug is so subtle that's a bit hard to
> debug from user's point of view. So I think this should go into 4.5.

Agreed.

> Mark posted a workaround in
> <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
> but to be honest I don't think it's nice to have everyone patch their
> scripts in order to work around this.

Right.

> ---
>  tools/libxl/xl_cmdimpl.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3737c7e..0a5f7c8 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2472,8 +2472,10 @@ static uint32_t create_domain(struct domain_create *dom_info)
>          }
>      }
>  
> -    if (debug || dom_info->dryrun)
> +    if (debug)
>          printf_info(default_output_format, -1, &d_config, stderr);
> +    if (!debug && dom_info->dryrun)

       else if ( dom_info->dry-run )

is the same (right?) and less thinking for the reader.

Or the whole thing could be just:
    if (debug || dom_info->dryrun)
          printf_info(default_output_format, -1, &d_config, debug ? stderr : stdout);

Less repetitive.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:47:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 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 1Y0TBh-0005iJ-30; Mon, 15 Dec 2014 10:47: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 1Y0TBf-0005iB-Hg
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:47:36 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	98/FC-25727-64CBE845; Mon, 15 Dec 2014 10:47:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418640452!13416004!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 1287 invoked from network); 15 Dec 2014 10:47: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 Dec 2014 10:47:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204379785"
Message-ID: <1418640450.16425.82.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 15 Dec 2014 10:47:30 +0000
In-Reply-To: <1418489645-7689-1-git-send-email-wei.liu2@citrix.com>
References: <1418489645-7689-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: tlviewer@yahoo.com, M A Young <m.a.young@durham.ac.uk>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-13 at 16:54 +0000, Wei Liu wrote:
> In commit d36a3734a ("xl: fix migration failure with xl migrate
> --debug"), message is printed to stderr for both debug mode
> and dryrun mode. That caused rdname() in xendomains fails to parse
> domain name since it's expecting input from xl's stdout.
> 
> So this patch separates those two cases. If xl is running in debug mode,
> then message is printed to stderr; if xl is running in dryrun mode and
> debug is not enabled, message is printed to stdout. This will fix
> xendomains and other scripts that use "xl create --dryrun", as well as
> not re-introducing the old bug fixed in d36a3734a.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: M A Young <m.a.young@durham.ac.uk>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Konrad Wilk <konrad.wilk@oracle.com>
> ---
> This is a regression, and this bug is so subtle that's a bit hard to
> debug from user's point of view. So I think this should go into 4.5.

Agreed.

> Mark posted a workaround in
> <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
> but to be honest I don't think it's nice to have everyone patch their
> scripts in order to work around this.

Right.

> ---
>  tools/libxl/xl_cmdimpl.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 3737c7e..0a5f7c8 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2472,8 +2472,10 @@ static uint32_t create_domain(struct domain_create *dom_info)
>          }
>      }
>  
> -    if (debug || dom_info->dryrun)
> +    if (debug)
>          printf_info(default_output_format, -1, &d_config, stderr);
> +    if (!debug && dom_info->dryrun)

       else if ( dom_info->dry-run )

is the same (right?) and less thinking for the reader.

Or the whole thing could be just:
    if (debug || dom_info->dryrun)
          printf_info(default_output_format, -1, &d_config, debug ? stderr : stdout);

Less repetitive.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:48:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 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 1Y0TCa-0005nU-Gv; Mon, 15 Dec 2014 10:48:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0TCY-0005nD-RT
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:48:30 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	BA/F2-28865-E7CBE845; Mon, 15 Dec 2014 10:48:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418640505!9234763!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 10245 invoked from network); 15 Dec 2014 10:48: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;
	15 Dec 2014 10:48:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204379910"
Message-ID: <1418640502.16425.83.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 15 Dec 2014 10:48:22 +0000
In-Reply-To: <20141213184650.GA32014@laptop.dumpdata.com>
References: <1418489645-7689-1-git-send-email-wei.liu2@citrix.com>
	<20141213183716.GD31121@laptop.dumpdata.com>
	<20141213184209.GE2285@zion.uk.xensource.com>
	<20141213184650.GA32014@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: tlviewer@yahoo.com, M A Young <m.a.young@durham.ac.uk>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-13 at 13:46 -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Dec 13, 2014 at 06:42:09PM +0000, Wei Liu wrote:
> > On Sat, Dec 13, 2014 at 01:37:16PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Sat, Dec 13, 2014 at 04:54:05PM +0000, Wei Liu wrote:
> > > > In commit d36a3734a ("xl: fix migration failure with xl migrate
> > > > --debug"), message is printed to stderr for both debug mode
> > > > and dryrun mode. That caused rdname() in xendomains fails to parse
> > > > domain name since it's expecting input from xl's stdout.
> > > > 
> > > > So this patch separates those two cases. If xl is running in debug mode,
> > > > then message is printed to stderr; if xl is running in dryrun mode and
> > > > debug is not enabled, message is printed to stdout. This will fix
> > > > xendomains and other scripts that use "xl create --dryrun", as well as
> > > > not re-introducing the old bug fixed in d36a3734a.
> > > > 
> > > > Reported-by: Mark Pryor <tlviewer@yahoo.com>
> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > Cc: M A Young <m.a.young@durham.ac.uk>
> > > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > > > ---
> > > > This is a regression, and this bug is so subtle that's a bit hard to
> > > > debug from user's point of view. So I think this should go into 4.5.
> > > > 
> > > > Mark posted a workaround in
> > > > <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
> > > > but to be honest I don't think it's nice to have everyone patch their
> > > > scripts in order to work around this.
> > > > ---
> > > >  tools/libxl/xl_cmdimpl.c |    4 +++-
> > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > > > index 3737c7e..0a5f7c8 100644
> > > > --- a/tools/libxl/xl_cmdimpl.c
> > > > +++ b/tools/libxl/xl_cmdimpl.c
> > > > @@ -2472,8 +2472,10 @@ static uint32_t create_domain(struct domain_create *dom_info)
> > > >          }
> > > >      }
> > > >  
> > > > -    if (debug || dom_info->dryrun)
> > > > +    if (debug)
> > > >          printf_info(default_output_format, -1, &d_config, stderr);
> > > > +    if (!debug && dom_info->dryrun)
> > > 
> > > Could this 'else if (dom_info->dry_run)' ?
> > > 
> > > I know that semantically it is exactly the same as the 'if (!debug ..)' but
> > > it just "feels" more proper? Thought since you are the maintainer in that
> > > area - your opinion on how you want to do that is of course authoritive.
> > > 
> > 
> > I don't have strong preference on this. I just happened to type in
> > whatever style that flowed though my mind at that particular point. If
> > Ian and you both feel strongly about this I can certainly resend. :-)
> 
> Lets wait to see what Ian says (or what he ends up checking in).

I really ought to read the thread before replying. I do prefer the else
if style, or the ternary operator one I also proposed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:48:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 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 1Y0TCa-0005nU-Gv; Mon, 15 Dec 2014 10:48:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0TCY-0005nD-RT
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:48:30 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	BA/F2-28865-E7CBE845; Mon, 15 Dec 2014 10:48:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418640505!9234763!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 10245 invoked from network); 15 Dec 2014 10:48: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;
	15 Dec 2014 10:48:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204379910"
Message-ID: <1418640502.16425.83.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 15 Dec 2014 10:48:22 +0000
In-Reply-To: <20141213184650.GA32014@laptop.dumpdata.com>
References: <1418489645-7689-1-git-send-email-wei.liu2@citrix.com>
	<20141213183716.GD31121@laptop.dumpdata.com>
	<20141213184209.GE2285@zion.uk.xensource.com>
	<20141213184650.GA32014@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: tlviewer@yahoo.com, M A Young <m.a.young@durham.ac.uk>,
	Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5] xl: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-13 at 13:46 -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Dec 13, 2014 at 06:42:09PM +0000, Wei Liu wrote:
> > On Sat, Dec 13, 2014 at 01:37:16PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Sat, Dec 13, 2014 at 04:54:05PM +0000, Wei Liu wrote:
> > > > In commit d36a3734a ("xl: fix migration failure with xl migrate
> > > > --debug"), message is printed to stderr for both debug mode
> > > > and dryrun mode. That caused rdname() in xendomains fails to parse
> > > > domain name since it's expecting input from xl's stdout.
> > > > 
> > > > So this patch separates those two cases. If xl is running in debug mode,
> > > > then message is printed to stderr; if xl is running in dryrun mode and
> > > > debug is not enabled, message is printed to stdout. This will fix
> > > > xendomains and other scripts that use "xl create --dryrun", as well as
> > > > not re-introducing the old bug fixed in d36a3734a.
> > > > 
> > > > Reported-by: Mark Pryor <tlviewer@yahoo.com>
> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > Cc: M A Young <m.a.young@durham.ac.uk>
> > > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > > Cc: Konrad Wilk <konrad.wilk@oracle.com>
> > > > ---
> > > > This is a regression, and this bug is so subtle that's a bit hard to
> > > > debug from user's point of view. So I think this should go into 4.5.
> > > > 
> > > > Mark posted a workaround in
> > > > <104017455.78913.1418434454763.JavaMail.yahoo@jws10624.mail.bf1.yahoo.com>
> > > > but to be honest I don't think it's nice to have everyone patch their
> > > > scripts in order to work around this.
> > > > ---
> > > >  tools/libxl/xl_cmdimpl.c |    4 +++-
> > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > > > index 3737c7e..0a5f7c8 100644
> > > > --- a/tools/libxl/xl_cmdimpl.c
> > > > +++ b/tools/libxl/xl_cmdimpl.c
> > > > @@ -2472,8 +2472,10 @@ static uint32_t create_domain(struct domain_create *dom_info)
> > > >          }
> > > >      }
> > > >  
> > > > -    if (debug || dom_info->dryrun)
> > > > +    if (debug)
> > > >          printf_info(default_output_format, -1, &d_config, stderr);
> > > > +    if (!debug && dom_info->dryrun)
> > > 
> > > Could this 'else if (dom_info->dry_run)' ?
> > > 
> > > I know that semantically it is exactly the same as the 'if (!debug ..)' but
> > > it just "feels" more proper? Thought since you are the maintainer in that
> > > area - your opinion on how you want to do that is of course authoritive.
> > > 
> > 
> > I don't have strong preference on this. I just happened to type in
> > whatever style that flowed though my mind at that particular point. If
> > Ian and you both feel strongly about this I can certainly resend. :-)
> 
> Lets wait to see what Ian says (or what he ends up checking in).

I really ought to read the thread before replying. I do prefer the else
if style, or the ternary operator one I also proposed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:52:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10: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 1Y0TGg-000690-73; Mon, 15 Dec 2014 10:52:46 +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 1Y0TGe-00068t-QY
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:52:44 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	5A/CD-02702-C7DBE845; Mon, 15 Dec 2014 10:52:44 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418640762!15079980!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 7954 invoked from network); 15 Dec 2014 10:52:43 -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;
	15 Dec 2014 10:52:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204837950"
Message-ID: <548EBD78.8080904@citrix.com>
Date: Mon, 15 Dec 2014 10:52:40 +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: Wei Liu <wei.liu2@citrix.com>, <xen-devel@lists.xen.org>
References: <20141027123328.GA9067@zion.uk.xensource.com>
In-Reply-To: <20141027123328.GA9067@zion.uk.xensource.com>
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] Linux Xen Balloon Driver Improvement (Draft 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 27/10/14 12:33, Wei Liu wrote:
> 
> ### Periodically exchange normal size pages with huge pages
> 
> Worker thread wakes up periodically to check if there are enough pages
> in normal size page queue to coalesce into a huge page. If so, it will
> try to exchange that huge page into a number of normal size pages with
> XENMEM\_exchange hypercall.

As Andrew recently pointed out[1], changes to a guest's p2m are not
properly handled during migration.  This would have to be fixed before
we can have any sort of background memory exchange process.

David

[1] http://lists.xen.org/archives/html/xen-devel/2014-11/msg01954.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:52:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10: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 1Y0TGg-000690-73; Mon, 15 Dec 2014 10:52:46 +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 1Y0TGe-00068t-QY
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:52:44 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	5A/CD-02702-C7DBE845; Mon, 15 Dec 2014 10:52:44 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418640762!15079980!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 7954 invoked from network); 15 Dec 2014 10:52:43 -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;
	15 Dec 2014 10:52:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204837950"
Message-ID: <548EBD78.8080904@citrix.com>
Date: Mon, 15 Dec 2014 10:52:40 +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: Wei Liu <wei.liu2@citrix.com>, <xen-devel@lists.xen.org>
References: <20141027123328.GA9067@zion.uk.xensource.com>
In-Reply-To: <20141027123328.GA9067@zion.uk.xensource.com>
X-DLP: MIA1
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] Linux Xen Balloon Driver Improvement (Draft 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 27/10/14 12:33, Wei Liu wrote:
> 
> ### Periodically exchange normal size pages with huge pages
> 
> Worker thread wakes up periodically to check if there are enough pages
> in normal size page queue to coalesce into a huge page. If so, it will
> try to exchange that huge page into a number of normal size pages with
> XENMEM\_exchange hypercall.

As Andrew recently pointed out[1], changes to a guest's p2m are not
properly handled during migration.  This would have to be fixed before
we can have any sort of background memory exchange process.

David

[1] http://lists.xen.org/archives/html/xen-devel/2014-11/msg01954.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:56:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TKJ-0006Jz-RF; Mon, 15 Dec 2014 10:56:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Y0TKI-0006Jr-7i
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:56:30 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E9/64-27584-D5EBE845; Mon, 15 Dec 2014 10:56:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418640986!7955110!1
X-Originating-IP: [66.165.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 14351 invoked from network); 15 Dec 2014 10:56: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 Dec 2014 10:56:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204382400"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 05:56: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 1Y0TKC-0005Zh-Si;
	Mon, 15 Dec 2014 10:56:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 15 Dec 2014 10:56:24 +0000
Message-ID: <1418640984-21639-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>, ian.campbell@citrix.com,
	m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH for-4.5 v2] xl: print message to stdout when
	(!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 commit d36a3734a ("xl: fix migration failure with xl migrate
--debug"), message is printed to stderr for both debug mode
and dryrun mode. That caused rdname() in xendomains fails to parse
domain name since it's expecting input from xl's stdout.

So this patch separates those two cases. If xl is running in debug mode,
then message is printed to stderr; if xl is running in dryrun mode and
debug is not enabled, message is printed to stdout. This will fix
xendomains and other scripts that use "xl create --dryrun", as well as
not re-introducing the old bug fixed in d36a3734a.

Reported-by: Mark Pryor <tlviewer@yahoo.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Ian Campbell <ian.campbell@citrix.com>
Release-Acked-by: Konrad Wilk <konrad.wilk@oracle.com>
---
 tools/libxl/xl_cmdimpl.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3737c7e..ed0d478 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2473,7 +2473,8 @@ static uint32_t create_domain(struct domain_create *dom_info)
     }
 
     if (debug || dom_info->dryrun)
-        printf_info(default_output_format, -1, &d_config, stderr);
+        printf_info(default_output_format, -1, &d_config,
+                    debug ? stderr : stdout);
 
     ret = 0;
     if (dom_info->dryrun)
-- 
1.7.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 Dec 15 10:56:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TKJ-0006Jz-RF; Mon, 15 Dec 2014 10:56:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Y0TKI-0006Jr-7i
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:56:30 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	E9/64-27584-D5EBE845; Mon, 15 Dec 2014 10:56:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418640986!7955110!1
X-Originating-IP: [66.165.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 14351 invoked from network); 15 Dec 2014 10:56: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 Dec 2014 10:56:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204382400"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 05:56: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 1Y0TKC-0005Zh-Si;
	Mon, 15 Dec 2014 10:56:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 15 Dec 2014 10:56:24 +0000
Message-ID: <1418640984-21639-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>, ian.campbell@citrix.com,
	m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH for-4.5 v2] xl: print message to stdout when
	(!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 commit d36a3734a ("xl: fix migration failure with xl migrate
--debug"), message is printed to stderr for both debug mode
and dryrun mode. That caused rdname() in xendomains fails to parse
domain name since it's expecting input from xl's stdout.

So this patch separates those two cases. If xl is running in debug mode,
then message is printed to stderr; if xl is running in dryrun mode and
debug is not enabled, message is printed to stdout. This will fix
xendomains and other scripts that use "xl create --dryrun", as well as
not re-introducing the old bug fixed in d36a3734a.

Reported-by: Mark Pryor <tlviewer@yahoo.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Ian Campbell <ian.campbell@citrix.com>
Release-Acked-by: Konrad Wilk <konrad.wilk@oracle.com>
---
 tools/libxl/xl_cmdimpl.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3737c7e..ed0d478 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2473,7 +2473,8 @@ static uint32_t create_domain(struct domain_create *dom_info)
     }
 
     if (debug || dom_info->dryrun)
-        printf_info(default_output_format, -1, &d_config, stderr);
+        printf_info(default_output_format, -1, &d_config,
+                    debug ? stderr : stdout);
 
     ret = 0;
     if (dom_info->dryrun)
-- 
1.7.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 Dec 15 10:58:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10: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 1Y0TLg-0006Ph-A5; Mon, 15 Dec 2014 10:57:56 +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 1Y0TLe-0006PV-G2
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:57:54 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	79/33-02576-1BEBE845; Mon, 15 Dec 2014 10:57:53 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418641072!15081072!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9814 invoked from network); 15 Dec 2014 10:57:53 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 10:57:53 -0000
Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89])
	by mail.moloch.sk (Postfix) with ESMTPSA id 985AC180AF55;
	Mon, 15 Dec 2014 11:57:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1418641072;
	bh=7WF9QEjM6lJqcRe9zkMOD8hrDFP3YHETOt0jY3yXqb8=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=tdljiGwO4J6KnzcLLYpwXubErtz1VJRh8Eu0kfzTJOxBFvM7zqoltiPSh5rZxA6wo
	k1ZYfKa5Jj3lEAHteY5FdnBg2DZAjbub96mi0+8gytcFjfhZeL4D7btEmcuta6E8Ix
	cyox1dj+bw6FnfD9EmDEkV39h7bnqczkMicZBTNdCipuq4Cd+WN42Gx6c0teZro/7c
	iAQpdmWwooDdo5PImmiAWFfSI1JgDpyweHTSZJJJoM7EzkhxdH2UWaB1q4FSUffqDE
	nNO2besnIVu3XULUjgTkPWFsYOlNRhLYb7BqlDRyyhEwadhcfhc3s7F3n5fRihz3wf
	gAMrJA4WHDqEA==
Received: by nodbug.moloch.sk (Postfix, from userid 1000)
	id 35E9B4C0E2E; Mon, 15 Dec 2014 11:58:28 +0100 (CET)
Date: Mon, 15 Dec 2014 11:58:28 +0100
From: Martin Lucina <martin@lucina.net>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, xen-devel@lists.xen.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
Message-ID: <20141215105828.GA27080@nodbug.moloch.sk>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
References: <20141204135550.GC11192@dezo.moloch.sk>
	<20141207195343.GC3141@type.youpi.perso.aquilenet.fr>
	<20141211120959.GA3218@dezo.moloch.sk>
	<20141214235903.GB2983@type.youpi.perso.aquilenet.fr>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141214235903.GB2983@type.youpi.perso.aquilenet.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] [PATCH] Mini-OS: netfront: Fix rx ring starvation
 in network_rx
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

samuel.thibault@ens-lyon.org said:
> > From: Martin Lucina <martin@lucina.net>
> > Date: Thu, 4 Dec 2014 14:33:53 +0100
> > Subject: [PATCH] Mini-OS: netfront: Fix rx ring starvation in network_rx
> > 
> > In network_rx() we must push the same amount of requests back onto the
> > ring in the second loop that we consumed in the first loop. Otherwise
> > the ring will eventually starve itself of free request slots and no
> > packets will be delivered.
> > 
> > Further, we make the HAVE_LIBC codepath clearer to follow by removing
> > the "some" variable from the for loop initialisation and conditions.
> > 
> > Signed-off-by: Martin Lucina <martin@lucina.net>
> 
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Thanks. I will merge a suitable version of this patch into our downstream
tree.

Is there anything else I need to do to ensure this change lands in xen.git?

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:58:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10: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 1Y0TLg-0006Ph-A5; Mon, 15 Dec 2014 10:57:56 +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 1Y0TLe-0006PV-G2
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:57:54 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	79/33-02576-1BEBE845; Mon, 15 Dec 2014 10:57:53 +0000
X-Env-Sender: martin@lucina.net
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418641072!15081072!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9814 invoked from network); 15 Dec 2014 10:57:53 -0000
Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 10:57:53 -0000
Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89])
	by mail.moloch.sk (Postfix) with ESMTPSA id 985AC180AF55;
	Mon, 15 Dec 2014 11:57:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net;
	s=dkim-201309; t=1418641072;
	bh=7WF9QEjM6lJqcRe9zkMOD8hrDFP3YHETOt0jY3yXqb8=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=tdljiGwO4J6KnzcLLYpwXubErtz1VJRh8Eu0kfzTJOxBFvM7zqoltiPSh5rZxA6wo
	k1ZYfKa5Jj3lEAHteY5FdnBg2DZAjbub96mi0+8gytcFjfhZeL4D7btEmcuta6E8Ix
	cyox1dj+bw6FnfD9EmDEkV39h7bnqczkMicZBTNdCipuq4Cd+WN42Gx6c0teZro/7c
	iAQpdmWwooDdo5PImmiAWFfSI1JgDpyweHTSZJJJoM7EzkhxdH2UWaB1q4FSUffqDE
	nNO2besnIVu3XULUjgTkPWFsYOlNRhLYb7BqlDRyyhEwadhcfhc3s7F3n5fRihz3wf
	gAMrJA4WHDqEA==
Received: by nodbug.moloch.sk (Postfix, from userid 1000)
	id 35E9B4C0E2E; Mon, 15 Dec 2014 11:58:28 +0100 (CET)
Date: Mon, 15 Dec 2014 11:58:28 +0100
From: Martin Lucina <martin@lucina.net>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, xen-devel@lists.xen.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
Message-ID: <20141215105828.GA27080@nodbug.moloch.sk>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	rumpkernel-users@lists.sourceforge.net
References: <20141204135550.GC11192@dezo.moloch.sk>
	<20141207195343.GC3141@type.youpi.perso.aquilenet.fr>
	<20141211120959.GA3218@dezo.moloch.sk>
	<20141214235903.GB2983@type.youpi.perso.aquilenet.fr>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141214235903.GB2983@type.youpi.perso.aquilenet.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] [PATCH] Mini-OS: netfront: Fix rx ring starvation
 in network_rx
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

samuel.thibault@ens-lyon.org said:
> > From: Martin Lucina <martin@lucina.net>
> > Date: Thu, 4 Dec 2014 14:33:53 +0100
> > Subject: [PATCH] Mini-OS: netfront: Fix rx ring starvation in network_rx
> > 
> > In network_rx() we must push the same amount of requests back onto the
> > ring in the second loop that we consumed in the first loop. Otherwise
> > the ring will eventually starve itself of free request slots and no
> > packets will be delivered.
> > 
> > Further, we make the HAVE_LIBC codepath clearer to follow by removing
> > the "some" variable from the for loop initialisation and conditions.
> > 
> > Signed-off-by: Martin Lucina <martin@lucina.net>
> 
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Thanks. I will merge a suitable version of this patch into our downstream
tree.

Is there anything else I need to do to ensure this change lands in xen.git?

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:58:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10:58:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TMY-0006Uw-Ol; Mon, 15 Dec 2014 10:58:50 +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 1Y0TMX-0006Uk-Fl
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:58:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	ED/C6-09842-8EEBE845; Mon, 15 Dec 2014 10:58:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418641124!15643859!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 5236 invoked from network); 15 Dec 2014 10:58:48 -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;
	15 Dec 2014 10:58:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204839812"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 05:58: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 1Y0TMU-0005fw-Pj;
	Mon, 15 Dec 2014 10:58:46 +0000
Date: Mon, 15 Dec 2014 10:58:46 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141215105846.GG2285@zion.uk.xensource.com>
References: <20141027123328.GA9067@zion.uk.xensource.com>
	<548EBD78.8080904@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548EBD78.8080904@citrix.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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] Linux Xen Balloon Driver Improvement (Draft 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, Dec 15, 2014 at 10:52:40AM +0000, David Vrabel wrote:
> On 27/10/14 12:33, Wei Liu wrote:
> > 
> > ### Periodically exchange normal size pages with huge pages
> > 
> > Worker thread wakes up periodically to check if there are enough pages
> > in normal size page queue to coalesce into a huge page. If so, it will
> > try to exchange that huge page into a number of normal size pages with
> > XENMEM\_exchange hypercall.
> 
> As Andrew recently pointed out[1], changes to a guest's p2m are not
> properly handled during migration.  This would have to be fixed before
> we can have any sort of background memory exchange process.
> 

Thanks for the pointer. I read that thread already.

Wei.

> David
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2014-11/msg01954.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 10:58:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 10:58:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TMY-0006Uw-Ol; Mon, 15 Dec 2014 10:58:50 +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 1Y0TMX-0006Uk-Fl
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 10:58:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	ED/C6-09842-8EEBE845; Mon, 15 Dec 2014 10:58:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418641124!15643859!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 5236 invoked from network); 15 Dec 2014 10:58:48 -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;
	15 Dec 2014 10:58:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204839812"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 05:58: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 1Y0TMU-0005fw-Pj;
	Mon, 15 Dec 2014 10:58:46 +0000
Date: Mon, 15 Dec 2014 10:58:46 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141215105846.GG2285@zion.uk.xensource.com>
References: <20141027123328.GA9067@zion.uk.xensource.com>
	<548EBD78.8080904@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <548EBD78.8080904@citrix.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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] Linux Xen Balloon Driver Improvement (Draft 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, Dec 15, 2014 at 10:52:40AM +0000, David Vrabel wrote:
> On 27/10/14 12:33, Wei Liu wrote:
> > 
> > ### Periodically exchange normal size pages with huge pages
> > 
> > Worker thread wakes up periodically to check if there are enough pages
> > in normal size page queue to coalesce into a huge page. If so, it will
> > try to exchange that huge page into a number of normal size pages with
> > XENMEM\_exchange hypercall.
> 
> As Andrew recently pointed out[1], changes to a guest's p2m are not
> properly handled during migration.  This would have to be fixed before
> we can have any sort of background memory exchange process.
> 

Thanks for the pointer. I read that thread already.

Wei.

> David
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2014-11/msg01954.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:00:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:00:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TNt-0006g2-87; Mon, 15 Dec 2014 11:00:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0TNs-0006ft-Fd
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:00:12 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	69/8C-14727-B3FBE845; Mon, 15 Dec 2014 11:00:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418641209!5776143!1
X-Originating-IP: [66.165.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 10172 invoked from network); 15 Dec 2014 11:00:10 -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;
	15 Dec 2014 11:00:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204383219"
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.210.2; Mon, 15 Dec 2014 05:59: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 1Y0TNQ-0000MQ-N6;
	Mon, 15 Dec 2014 10:59:44 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0TNQ-0006ds-Hs;
	Mon, 15 Dec 2014 10:59:44 +0000
Date: Mon, 15 Dec 2014 10:59:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32377-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 9854
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32377: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1083696926274362712=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1083696926274362712==
Content-Type: text/plain
Content-Length: 9557
Content-Transfer-Encoding: quoted-printable

flight 32377 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32377/

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. 32194
 build-amd64                   5 xen-build                 fail REGR. vs. 32194
 build-i386                    5 xen-build                 fail REGR. vs. 32194

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      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  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-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl           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            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  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-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-amd64-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-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-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-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-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-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-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-pair         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-qemut-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-amd64-xl-qemuu-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-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-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a

version targeted for testing:
 qemuu                99c9c3cb24e566258a0a141178934f9cb5198842
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Amos Kong <akong@redhat.com>
  Anton Blanchard <anton@samba.org>
  Antony Pavlov <antonynpavlov@gmail.com>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Christoffer Dall <christoffer.dall@linaro.org>
  Dr. David Alan Gilbert <dgilbert@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>
  Jeff Cody <jcody@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  lijun <junmuzi@gmail.com>
  Liviu Ionescu <ilg@livius.net>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael Mueller <mimu@linux.vnet.ibm.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Nikita Belov <zodiac@ispras.ru>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-libvirt                                          blocked 
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 2395 lines long.)


--===============1083696926274362712==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1083696926274362712==--

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:00:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:00:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TNt-0006g2-87; Mon, 15 Dec 2014 11:00:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0TNs-0006ft-Fd
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:00:12 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	69/8C-14727-B3FBE845; Mon, 15 Dec 2014 11:00:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418641209!5776143!1
X-Originating-IP: [66.165.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 10172 invoked from network); 15 Dec 2014 11:00:10 -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;
	15 Dec 2014 11:00:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204383219"
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.210.2; Mon, 15 Dec 2014 05:59: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 1Y0TNQ-0000MQ-N6;
	Mon, 15 Dec 2014 10:59:44 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0TNQ-0006ds-Hs;
	Mon, 15 Dec 2014 10:59:44 +0000
Date: Mon, 15 Dec 2014 10:59:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32377-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 9854
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32377: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1083696926274362712=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1083696926274362712==
Content-Type: text/plain
Content-Length: 9557
Content-Transfer-Encoding: quoted-printable

flight 32377 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32377/

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. 32194
 build-amd64                   5 xen-build                 fail REGR. vs. 32194
 build-i386                    5 xen-build                 fail REGR. vs. 32194

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      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  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-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-credit2    1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl           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            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf-pin  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-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-amd64-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-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1)         blocked n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-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-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)               blocked n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)              blocked n/a
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-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-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-i386-xl-qemuu-debianhvm-amd64  1 build-check(1)         blocked n/a
 test-amd64-amd64-pair         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-qemut-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-amd64-xl-qemuu-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-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-winxpsp3   1 build-check(1)               blocked  n/a
 test-amd64-i386-pair          1 build-check(1)               blocked  n/a

version targeted for testing:
 qemuu                99c9c3cb24e566258a0a141178934f9cb5198842
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Amos Kong <akong@redhat.com>
  Anton Blanchard <anton@samba.org>
  Antony Pavlov <antonynpavlov@gmail.com>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Christoffer Dall <christoffer.dall@linaro.org>
  Dr. David Alan Gilbert <dgilbert@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>
  Jeff Cody <jcody@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  lijun <junmuzi@gmail.com>
  Liviu Ionescu <ilg@livius.net>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael Mueller <mimu@linux.vnet.ibm.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Nikita Belov <zodiac@ispras.ru>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@linux.vnet.ibm.com>
  zhanghailiang <zhang.zhanghailiang@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-libvirt                                          blocked 
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 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=3Fp=3Dosstest.git;a=3Dsummary


Not pushing.

(No revision log; it would be 2395 lines long.)


--===============1083696926274362712==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1083696926274362712==--

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:00:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0TOI-0006kA-7r; Mon, 15 Dec 2014 11:00: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 1Y0TOG-0006jm-AY
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:00:36 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	90/C7-22819-25FBE845; Mon, 15 Dec 2014 11:00:34 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418641233!7956167!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_50_75
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21364 invoked from network); 15 Dec 2014 11:00:34 -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; 15 Dec 2014 11:00:34 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 830D7AD17;
	Mon, 15 Dec 2014 11:00:33 +0000 (UTC)
Message-ID: <548EBF50.1080100@suse.com>
Date: Mon, 15 Dec 2014 12:00: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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <548AEAE7.8020604@suse.com>
	<20141212164407.GB28140@laptop.dumpdata.com>
In-Reply-To: <20141212164407.GB28140@laptop.dumpdata.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Xen's Linux kernel config 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/12/2014 05:44 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 12, 2014 at 02:17:27PM +0100, Juergen Gross wrote:
>> Hi,
>>
>> This is a design proposal for a rework of the config options on the
>> Linux kernel which are related to Xen.
>>
>> The need to do so arose from the fact that it is currently not
>> possible to build the Xen frontend drivers for a non-pvops kernel,
>> e.g. to run them in a HVM-domain. There are more drawbacks in the
>> current config options to which I'll come later.
>>
>> Current Xen related config options are as follows:
>>
>> Option                          Selects                 Depends
>> ---------------------------------------------------------------------
>> XEN                             PARAVIRT_CLOCK(x86)     PARAVIRT(x86)
>>                                  XEN_HAVE_PVMMU(x86)
>>                                  SWIOTLB_XEN(arm,arm64)
>>    PCI_XEN(x86)                  SWIOTLB_XEN
>>    XEN_DOM0                                              PCI_XEN(x86)
>>      XEN_BACKEND
>>        XEN_BLKDEV_BACKEND
>>        XEN_PCIDEV_BACKEND(x86)
>>        XEN_SCSI_BACKEND
>>        XEN_NETDEV_BACKEND
>>      XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
>>      XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
>>      XEN_MCE_LOG(x86)
>>    XEN_PVHVM(x86)
>>      XEN_PVH(x86)
>>    XEN_MAX_DOMAIN_MEMORY(x86)
>>    XEN_SAVE_RESTORE(x86)
>>    XEN_DEBUG_FS(x86)
>>    XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
>>                                  INPUT_XEN_KBDDEV_FRONTEND
>>    XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
>>    HVC_XEN
>>      HVC_XEN_FRONTEND            XEN_XENBUS_FRONTEND
>>    TCG_XEN                       XEN_XENBUS_FRONTEND
>>    XEN_PCIDEV_FRONTEND           PCI_XEN
>>                                  XEN_XENBUS_FRONTEND
>>    XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
>>    INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
>>    XEN_WDT
>>    XEN_BALLOON
>>      XEN_SELFBALLOONING                                  XEN_TMEM
>>      XEN_BALLOON_MEMORY_HOTPLUG
>>      XEN_SCRUB_PAGES
>>    XEN_DEV_EVTCHN
>>    XENFS                         XEN_PRIVCMD
>>      XEN_COMPAT_XENFS
>>    XEN_SYS_HYPERVISOR
>>    XEN_XENBUS_FRONTEND
>>    XEN_GNTDEV
>>    XEN_GRANT_DEV_ALLOC
>>    SWIOTLB_XEN
>>    XEN_TMEM(x86)
>>    XEN_PRIVCMD
>>    XEN_STUB(x86_64)                                      BROKEN
>>    XEN_ACPI_PROCESSOR(x86)
>>    XEN_HAVE_PVMMU
>>    XEN_EFI(x64)
>>    XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND
>>
>> Legend:
>> - The first column are the Xen config options. Indentation in this
>>    column reflects the dependency between those options (e.g.
>>    XEN_SCSI_BACKEND depends on XEN_BACKEND, which in turn depends on
>>    XEN_DOM0, which depends on XEN).
>> - The second column shows the options which are selected automatically
>>    if the corresponding option in the first column is configured.
>> - The last column shows additional dependencies which can't be shown via
>>    the indentation level of the first column.
>> - Some options or dependencies are architecture specific, they are
>>    listed in brackets (e.g. XEN_TMEM which is available for x86 only).
>> - Non-Xen options are mentioned only if they seem to be really relevant,
>>    like e.g. PARAVIRT or BROKEN.
>>
>> There are several reasons to change the config options:
>> - Be able to build Xen frontend drivers for HVM domains without the need
>>    for choosing a pvops kernel: currently the frontend drivers need XEN
>>    configured which depends on PARAVIRT.
>> - Be able to build a Dom0 using XEN_PVH without having to configure
>>    XEN_HAVE_PVMMU.
>> - Be able to build HVM driver domains.
>> - Some features are available for x86 only, in spite of being not
>>    architecture specific, e.g. XEN_DEBUG_FS or XEN_TMEM.
>>
>> As a first draft I'd suggest the following:
>>
>> Option                          Selects                 Depends
>> ----------------------------------------------------------------------
>> XEN                             SWIOTLB_XEN(arm,arm64)
>>    XEN_PV(x86)                   XEN_HAVE_PVMMU
>>                                  PARAVIRT
>>                                  PARAVIRT_CLOCK
>>    XEN_PVH(x86)                  XEN_PVHVM
>>                                  PARAVIRT
>>                                  PARAVIRT_CLOCK
>>    XEN_BACKEND                                           XEN_PV(x86) ||
>>                                                          XEN_PVH(x86) ||
>>                                                          XEN_PVHVM
>>      XEN_BLKDEV_BACKEND
>>      XEN_PCIDEV_BACKEND(x86)
>>      XEN_SCSI_BACKEND
>>      XEN_NETDEV_BACKEND
>>    PCI_XEN(x86)                  SWIOTLB_XEN
>>    XEN_DOM0                      XEN_BACKEND             XEN_PV(x86) ||
>>                                  PCI_XEN(x86)            XEN_PVH(x86)
>
> Could XEN_DOM0 be removed completly? And instead we just have
> an 'backend' and 'frontend' type options?

What about (physical) memory/cpu hotplug and mce?

We could rename XEN_DOM0 to XEN_HWDOM, however.

>
>
>>      XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
>>      XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
>>      XEN_MCE_LOG(x86)
>>    XEN_MAX_DOMAIN_MEMORY(x86)
>>    XEN_SAVE_RESTORE(x86)
>>    XEN_DEBUG_FS
>>    XEN_WDT
>>    XEN_BALLOON
>>      XEN_SELFBALLOONING                                  XEN_TMEM
>>      XEN_BALLOON_MEMORY_HOTPLUG
>>      XEN_SCRUB_PAGES
>>    XENFS                         XEN_PRIVCMD
>>      XEN_COMPAT_XENFS
>>    XEN_SYS_HYPERVISOR
>>    XEN_DEV_EVTCHN
>>    XEN_GNTDEV
>>    XEN_GRANT_DEV_ALLOC
>>    SWIOTLB_XEN
>>    XEN_TMEM
>>    XEN_PRIVCMD
>>    XEN_STUB(x86_64)                                      BROKEN
>>    XEN_ACPI_PROCESSOR(x86)
>>    XEN_HAVE_PVMMU
>>    XEN_EFI(x64)
>> XEN_PVHVM
>> XEN_FRONTEND                                            XEN_PV ||
>>                                                          XEN_PVH ||
>>                                                          XEN_PVHVM
>>    XEN_XENBUS_FRONTEND
>>    XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
>>                                  INPUT_XEN_KBDDEV_FRONTEND
>>    XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
>>    HVC_XEN_FRONTEND              XEN_XENBUS_FRONTEND
>>                                  HVC_XEN
>>    TCG_XEN                       XEN_XENBUS_FRONTEND
>>    XEN_PCIDEV_FRONTEND           PCI_XEN
>>                                  XEN_XENBUS_FRONTEND
>>    XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
>>    INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
>>    XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND
>>
>> There might be some further adjustments needed (should XEN_DEV_EVTCHN
>> and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The
>> main difference to the current status is the XEN setting no longer
>> controlling all other options.
>>
>> Changing the config options in this way surely will need some
>> adjustments in the drivers, but this can be discussed when we agree
>> on the future config dependencies.
>>
>>
>> Juergen
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:00:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0TOI-0006kA-7r; Mon, 15 Dec 2014 11:00: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 1Y0TOG-0006jm-AY
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:00:36 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	90/C7-22819-25FBE845; Mon, 15 Dec 2014 11:00:34 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418641233!7956167!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_50_75
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21364 invoked from network); 15 Dec 2014 11:00:34 -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; 15 Dec 2014 11:00:34 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 830D7AD17;
	Mon, 15 Dec 2014 11:00:33 +0000 (UTC)
Message-ID: <548EBF50.1080100@suse.com>
Date: Mon, 15 Dec 2014 12:00: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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <548AEAE7.8020604@suse.com>
	<20141212164407.GB28140@laptop.dumpdata.com>
In-Reply-To: <20141212164407.GB28140@laptop.dumpdata.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Xen's Linux kernel config 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/12/2014 05:44 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 12, 2014 at 02:17:27PM +0100, Juergen Gross wrote:
>> Hi,
>>
>> This is a design proposal for a rework of the config options on the
>> Linux kernel which are related to Xen.
>>
>> The need to do so arose from the fact that it is currently not
>> possible to build the Xen frontend drivers for a non-pvops kernel,
>> e.g. to run them in a HVM-domain. There are more drawbacks in the
>> current config options to which I'll come later.
>>
>> Current Xen related config options are as follows:
>>
>> Option                          Selects                 Depends
>> ---------------------------------------------------------------------
>> XEN                             PARAVIRT_CLOCK(x86)     PARAVIRT(x86)
>>                                  XEN_HAVE_PVMMU(x86)
>>                                  SWIOTLB_XEN(arm,arm64)
>>    PCI_XEN(x86)                  SWIOTLB_XEN
>>    XEN_DOM0                                              PCI_XEN(x86)
>>      XEN_BACKEND
>>        XEN_BLKDEV_BACKEND
>>        XEN_PCIDEV_BACKEND(x86)
>>        XEN_SCSI_BACKEND
>>        XEN_NETDEV_BACKEND
>>      XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
>>      XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
>>      XEN_MCE_LOG(x86)
>>    XEN_PVHVM(x86)
>>      XEN_PVH(x86)
>>    XEN_MAX_DOMAIN_MEMORY(x86)
>>    XEN_SAVE_RESTORE(x86)
>>    XEN_DEBUG_FS(x86)
>>    XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
>>                                  INPUT_XEN_KBDDEV_FRONTEND
>>    XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
>>    HVC_XEN
>>      HVC_XEN_FRONTEND            XEN_XENBUS_FRONTEND
>>    TCG_XEN                       XEN_XENBUS_FRONTEND
>>    XEN_PCIDEV_FRONTEND           PCI_XEN
>>                                  XEN_XENBUS_FRONTEND
>>    XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
>>    INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
>>    XEN_WDT
>>    XEN_BALLOON
>>      XEN_SELFBALLOONING                                  XEN_TMEM
>>      XEN_BALLOON_MEMORY_HOTPLUG
>>      XEN_SCRUB_PAGES
>>    XEN_DEV_EVTCHN
>>    XENFS                         XEN_PRIVCMD
>>      XEN_COMPAT_XENFS
>>    XEN_SYS_HYPERVISOR
>>    XEN_XENBUS_FRONTEND
>>    XEN_GNTDEV
>>    XEN_GRANT_DEV_ALLOC
>>    SWIOTLB_XEN
>>    XEN_TMEM(x86)
>>    XEN_PRIVCMD
>>    XEN_STUB(x86_64)                                      BROKEN
>>    XEN_ACPI_PROCESSOR(x86)
>>    XEN_HAVE_PVMMU
>>    XEN_EFI(x64)
>>    XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND
>>
>> Legend:
>> - The first column are the Xen config options. Indentation in this
>>    column reflects the dependency between those options (e.g.
>>    XEN_SCSI_BACKEND depends on XEN_BACKEND, which in turn depends on
>>    XEN_DOM0, which depends on XEN).
>> - The second column shows the options which are selected automatically
>>    if the corresponding option in the first column is configured.
>> - The last column shows additional dependencies which can't be shown via
>>    the indentation level of the first column.
>> - Some options or dependencies are architecture specific, they are
>>    listed in brackets (e.g. XEN_TMEM which is available for x86 only).
>> - Non-Xen options are mentioned only if they seem to be really relevant,
>>    like e.g. PARAVIRT or BROKEN.
>>
>> There are several reasons to change the config options:
>> - Be able to build Xen frontend drivers for HVM domains without the need
>>    for choosing a pvops kernel: currently the frontend drivers need XEN
>>    configured which depends on PARAVIRT.
>> - Be able to build a Dom0 using XEN_PVH without having to configure
>>    XEN_HAVE_PVMMU.
>> - Be able to build HVM driver domains.
>> - Some features are available for x86 only, in spite of being not
>>    architecture specific, e.g. XEN_DEBUG_FS or XEN_TMEM.
>>
>> As a first draft I'd suggest the following:
>>
>> Option                          Selects                 Depends
>> ----------------------------------------------------------------------
>> XEN                             SWIOTLB_XEN(arm,arm64)
>>    XEN_PV(x86)                   XEN_HAVE_PVMMU
>>                                  PARAVIRT
>>                                  PARAVIRT_CLOCK
>>    XEN_PVH(x86)                  XEN_PVHVM
>>                                  PARAVIRT
>>                                  PARAVIRT_CLOCK
>>    XEN_BACKEND                                           XEN_PV(x86) ||
>>                                                          XEN_PVH(x86) ||
>>                                                          XEN_PVHVM
>>      XEN_BLKDEV_BACKEND
>>      XEN_PCIDEV_BACKEND(x86)
>>      XEN_SCSI_BACKEND
>>      XEN_NETDEV_BACKEND
>>    PCI_XEN(x86)                  SWIOTLB_XEN
>>    XEN_DOM0                      XEN_BACKEND             XEN_PV(x86) ||
>>                                  PCI_XEN(x86)            XEN_PVH(x86)
>
> Could XEN_DOM0 be removed completly? And instead we just have
> an 'backend' and 'frontend' type options?

What about (physical) memory/cpu hotplug and mce?

We could rename XEN_DOM0 to XEN_HWDOM, however.

>
>
>>      XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
>>      XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
>>      XEN_MCE_LOG(x86)
>>    XEN_MAX_DOMAIN_MEMORY(x86)
>>    XEN_SAVE_RESTORE(x86)
>>    XEN_DEBUG_FS
>>    XEN_WDT
>>    XEN_BALLOON
>>      XEN_SELFBALLOONING                                  XEN_TMEM
>>      XEN_BALLOON_MEMORY_HOTPLUG
>>      XEN_SCRUB_PAGES
>>    XENFS                         XEN_PRIVCMD
>>      XEN_COMPAT_XENFS
>>    XEN_SYS_HYPERVISOR
>>    XEN_DEV_EVTCHN
>>    XEN_GNTDEV
>>    XEN_GRANT_DEV_ALLOC
>>    SWIOTLB_XEN
>>    XEN_TMEM
>>    XEN_PRIVCMD
>>    XEN_STUB(x86_64)                                      BROKEN
>>    XEN_ACPI_PROCESSOR(x86)
>>    XEN_HAVE_PVMMU
>>    XEN_EFI(x64)
>> XEN_PVHVM
>> XEN_FRONTEND                                            XEN_PV ||
>>                                                          XEN_PVH ||
>>                                                          XEN_PVHVM
>>    XEN_XENBUS_FRONTEND
>>    XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
>>                                  INPUT_XEN_KBDDEV_FRONTEND
>>    XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
>>    HVC_XEN_FRONTEND              XEN_XENBUS_FRONTEND
>>                                  HVC_XEN
>>    TCG_XEN                       XEN_XENBUS_FRONTEND
>>    XEN_PCIDEV_FRONTEND           PCI_XEN
>>                                  XEN_XENBUS_FRONTEND
>>    XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
>>    INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
>>    XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND
>>
>> There might be some further adjustments needed (should XEN_DEV_EVTCHN
>> and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The
>> main difference to the current status is the XEN setting no longer
>> controlling all other options.
>>
>> Changing the config options in this way surely will need some
>> adjustments in the drivers, but this can be discussed when we agree
>> on the future config dependencies.
>>
>>
>> Juergen
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:00:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0TOU-0006nG-Ks; Mon, 15 Dec 2014 11:00:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0TOT-0006mr-5e
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:00:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0D/6B-09842-06FBE845; Mon, 15 Dec 2014 11:00:48 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418641246!15601622!1
X-Originating-IP: [66.165.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 10351 invoked from network); 15 Dec 2014 11:00:47 -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;
	15 Dec 2014 11:00:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204840551"
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.210.2; Mon, 15 Dec 2014 06: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 1Y0TOP-0000Mr-Gs;
	Mon, 15 Dec 2014 11: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 1Y0TOP-0006kI-C4;
	Mon, 15 Dec 2014 11:00:45 +0000
Date: Mon, 15 Dec 2014 11:00:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32379-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] 32379: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32379 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32379/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   5 xen-build                 fail REGR. vs. 26303
 build-i386                    5 xen-build                 fail REGR. vs. 26303
 build-i386-pvops              5 kernel-build              fail REGR. vs. 26303
 build-amd64-pvops             5 kernel-build              fail REGR. vs. 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  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-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 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-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl           1 build-check(1)               blocked  n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 build-amd64-rumpuserxen       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-vcpus1  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-winxpsp3   1 build-check(1)               blocked  n/a
 build-i386-rumpuserxen        1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-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-xl-qemut-winxpsp3  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-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-pair         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-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-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 build-i386-libvirt            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-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-qemut-win7-amd64  1 build-check(1)              blocked n/a
 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-amd64-xl-qemut-winxpsp3  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                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-libvirt                                          blocked 
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 build-amd64-rumpuserxen                                      blocked 
 build-i386-rumpuserxen                                       blocked 
 test-amd64-amd64-xl                                          blocked 
 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                    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-rumpuserxen-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-i386-rumpuserxen-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.

(No revision log; it would be 34178 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 Dec 15 11:00:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0TOU-0006nG-Ks; Mon, 15 Dec 2014 11:00:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0TOT-0006mr-5e
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:00:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0D/6B-09842-06FBE845; Mon, 15 Dec 2014 11:00:48 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418641246!15601622!1
X-Originating-IP: [66.165.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 10351 invoked from network); 15 Dec 2014 11:00:47 -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;
	15 Dec 2014 11:00:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204840551"
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.210.2; Mon, 15 Dec 2014 06: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 1Y0TOP-0000Mr-Gs;
	Mon, 15 Dec 2014 11: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 1Y0TOP-0006kI-C4;
	Mon, 15 Dec 2014 11:00:45 +0000
Date: Mon, 15 Dec 2014 11:00:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32379-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] 32379: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32379 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32379/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   5 xen-build                 fail REGR. vs. 26303
 build-i386                    5 xen-build                 fail REGR. vs. 26303
 build-i386-pvops              5 kernel-build              fail REGR. vs. 26303
 build-amd64-pvops             5 kernel-build              fail REGR. vs. 26303

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  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-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 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-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl           1 build-check(1)               blocked  n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)               blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1)         blocked n/a
 build-amd64-rumpuserxen       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-vcpus1  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-winxpsp3   1 build-check(1)               blocked  n/a
 build-i386-rumpuserxen        1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-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-xl-qemut-winxpsp3  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-win7-amd64  1 build-check(1)             blocked n/a
 test-amd64-amd64-pair         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-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-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 build-i386-libvirt            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-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-qemut-win7-amd64  1 build-check(1)              blocked n/a
 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-amd64-xl-qemut-winxpsp3  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                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-libvirt                                          blocked 
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           blocked 
 build-amd64-pvops                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             fail    
 build-amd64-rumpuserxen                                      blocked 
 build-i386-rumpuserxen                                       blocked 
 test-amd64-amd64-xl                                          blocked 
 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                    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-rumpuserxen-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-i386-rumpuserxen-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.

(No revision log; it would be 34178 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 Dec 15 11:07:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0TUH-0007MR-FU; Mon, 15 Dec 2014 11:06: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 1Y0TUG-0007MM-63
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 11:06:48 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	2F/C0-14727-7C0CE845; Mon, 15 Dec 2014 11:06:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418641605!9239784!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 21164 invoked from network); 15 Dec 2014 11:06:46 -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;
	15 Dec 2014 11:06:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204842196"
Message-ID: <1418641603.16425.89.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 15 Dec 2014 11:06:43 +0000
In-Reply-To: <1418640984-21639-1-git-send-email-wei.liu2@citrix.com>
References: <1418640984-21639-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: m.a.young@durham.ac.uk, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] xl: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-15 at 10:56 +0000, Wei Liu wrote:
> In commit d36a3734a ("xl: fix migration failure with xl migrate
> --debug"), message is printed to stderr for both debug mode
> and dryrun mode. That caused rdname() in xendomains fails to parse
> domain name since it's expecting input from xl's stdout.
> 
> So this patch separates those two cases. If xl is running in debug mode,
> then message is printed to stderr; if xl is running in dryrun mode and
> debug is not enabled, message is printed to stdout. This will fix
> xendomains and other scripts that use "xl create --dryrun", as well as
> not re-introducing the old bug fixed in d36a3734a.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: M A Young <m.a.young@durham.ac.uk>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Release-Acked-by: Konrad Wilk <konrad.wilk@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 Mon Dec 15 11:07:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0TUH-0007MR-FU; Mon, 15 Dec 2014 11:06: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 1Y0TUG-0007MM-63
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 11:06:48 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	2F/C0-14727-7C0CE845; Mon, 15 Dec 2014 11:06:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418641605!9239784!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 21164 invoked from network); 15 Dec 2014 11:06:46 -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;
	15 Dec 2014 11:06:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204842196"
Message-ID: <1418641603.16425.89.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 15 Dec 2014 11:06:43 +0000
In-Reply-To: <1418640984-21639-1-git-send-email-wei.liu2@citrix.com>
References: <1418640984-21639-1-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: m.a.young@durham.ac.uk, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] xl: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-15 at 10:56 +0000, Wei Liu wrote:
> In commit d36a3734a ("xl: fix migration failure with xl migrate
> --debug"), message is printed to stderr for both debug mode
> and dryrun mode. That caused rdname() in xendomains fails to parse
> domain name since it's expecting input from xl's stdout.
> 
> So this patch separates those two cases. If xl is running in debug mode,
> then message is printed to stderr; if xl is running in dryrun mode and
> debug is not enabled, message is printed to stdout. This will fix
> xendomains and other scripts that use "xl create --dryrun", as well as
> not re-introducing the old bug fixed in d36a3734a.
> 
> Reported-by: Mark Pryor <tlviewer@yahoo.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: M A Young <m.a.young@durham.ac.uk>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Release-Acked-by: Konrad Wilk <konrad.wilk@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 Mon Dec 15 11:08:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TVw-0007Rh-Ur; Mon, 15 Dec 2014 11:08:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Y0TVv-0007RZ-Hb
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:08:31 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	E2/14-26652-E21CE845; Mon, 15 Dec 2014 11:08:30 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418641708!5778601!1
X-Originating-IP: [66.165.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 22476 invoked from network); 15 Dec 2014 11:08:30 -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;
	15 Dec 2014 11:08:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204385807"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 06:08: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 1Y0TVr-0005sb-CU;
	Mon, 15 Dec 2014 11:08:27 +0000
Date: Mon, 15 Dec 2014 11:08:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jie Shen <jshen25@hawk.iit.edu>
In-Reply-To: <CADUQMeiZ6yF-MdSFC86R-Sn8y2+kPEDUVqgp0SGC7eXihOUF=w@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1412151055150.30971@kaball.uk.xensource.com>
References: <CADUQMeiZ6yF-MdSFC86R-Sn8y2+kPEDUVqgp0SGC7eXihOUF=w@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1859286638-1418641038=:30971"
Content-ID: <alpine.DEB.2.02.1412151105050.30971@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, vincent.hanquez@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] libxl.c::definition::can not find itb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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-1859286638-1418641038=:30971
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.02.1412151105051.30971@kaball.uk.xensource.com>

On Fri, 12 Dec 2014, Jie Shen wrote:
> Hello Vincent and Stefano,

Hello Jie,
please ask libxl related questions on the xen mailing list
(xen-devel@lists.xen.org), CC'ed.



> I am working on a project to change xen's code.
>=20
> Unfortunately I can not find the MACRO def :
> such as :
>=20
> LIBXL_SCHEDULER_SEDF:
>=20
> where I can find it :
>=20
> thank you very much!
>=20
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =C2=A0 switch (sched) {
> =C2=A0 =C2=A0 case LIBXL_SCHEDULER_SEDF:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_sedf_domain_set(gc, domid, scinfo=
);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> =C2=A0 =C2=A0 case LIBXL_SCHEDULER_CREDIT:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_credit_domain_set(gc, domid, scin=
fo);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> =C2=A0 =C2=A0 case LIBXL_SCHEDULER_CREDIT2:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_credit2_domain_set(gc, domid, sci=
nfo);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> =C2=A0 =C2=A0 case LIBXL_SCHEDULER_RTGLOBAL:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_rtglobal_domain_set(gc, domid, sc=
info);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> =C2=A0 =C2=A0 case LIBXL_SCHEDULER_RTPARTITION:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_rtpartition_domain_set(gc, domid,=
 scinfo);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 break; =C2=A0 =C2=A0=C2=A0
> =C2=A0 =C2=A0 case LIBXL_SCHEDULER_ARINC653:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_arinc653_domain_set(gc, domid, sc
>=20

It is defined in _libxl_types.h, that is autogenerated by gentypes.py.


>=20
>=20
>=20
> =3D=3D=3D=3D=3D
>=20
>=20
>=20
>=20
>=20
> =C2=A0Best regards
> Jie Shen
>=20
>=20
> Graduate Student in Computer Science
> Illinois Institute of Technology=C2=A0=C2=A0=C2=A0
> Stuart Building=C2=A0 Chicago, IL 60616
> +1=C2=A0 312 404 0122
>=20
>=20
>=20
--1342847746-1859286638-1418641038=:30971
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1859286638-1418641038=:30971--


From xen-devel-bounces@lists.xen.org Mon Dec 15 11:08:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TW3-0007SH-AY; Mon, 15 Dec 2014 11:08: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 1Y0TW2-0007S5-80
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 11:08:38 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	FD/3F-22819-531CE845; Mon, 15 Dec 2014 11:08:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418641715!13407175!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9899 invoked from network); 15 Dec 2014 11:08:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 11:08:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204385825"
Message-ID: <1418641713.16425.90.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Galla Rao <gallagnv.rao@gmail.com>
Date: Mon, 15 Dec 2014 11:08:33 +0000
In-Reply-To: <CANtx2ovOxN_R0BQskE_OyA_1YjU22x4f4DWhmgzrjbe3iRO6xg@mail.gmail.com>
References: <CANtx2outtiqeGzvbnCX0kY9jocp_+qCUjpxr8ypfWUMjx5A1gA@mail.gmail.com>
	<20141214143408.GB19091@reaktio.net>
	<CANtx2ovOxN_R0BQskE_OyA_1YjU22x4f4DWhmgzrjbe3iRO6xg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] SRIOV on a NIC card
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-14 at 21:09 +0530, Galla Rao wrote:
> True it is not on Xen, it is on solaris platform
> 
> 
> As SRIOV (PCIe) spec is same on all platforms, the feature
> implementation
> should not change
> 
> 
> May be not an appropriate group for posting this query.

If you aren't using Xen then of course xen-devel (a list for the
development of Xen) isn't an appropriate forum.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:08:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TVw-0007Rh-Ur; Mon, 15 Dec 2014 11:08:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Y0TVv-0007RZ-Hb
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:08:31 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	E2/14-26652-E21CE845; Mon, 15 Dec 2014 11:08:30 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418641708!5778601!1
X-Originating-IP: [66.165.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 22476 invoked from network); 15 Dec 2014 11:08:30 -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;
	15 Dec 2014 11:08:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204385807"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 06:08: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 1Y0TVr-0005sb-CU;
	Mon, 15 Dec 2014 11:08:27 +0000
Date: Mon, 15 Dec 2014 11:08:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jie Shen <jshen25@hawk.iit.edu>
In-Reply-To: <CADUQMeiZ6yF-MdSFC86R-Sn8y2+kPEDUVqgp0SGC7eXihOUF=w@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1412151055150.30971@kaball.uk.xensource.com>
References: <CADUQMeiZ6yF-MdSFC86R-Sn8y2+kPEDUVqgp0SGC7eXihOUF=w@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1859286638-1418641038=:30971"
Content-ID: <alpine.DEB.2.02.1412151105050.30971@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: xen-devel@lists.xensource.com, vincent.hanquez@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] libxl.c::definition::can not find itb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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-1859286638-1418641038=:30971
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.02.1412151105051.30971@kaball.uk.xensource.com>

On Fri, 12 Dec 2014, Jie Shen wrote:
> Hello Vincent and Stefano,

Hello Jie,
please ask libxl related questions on the xen mailing list
(xen-devel@lists.xen.org), CC'ed.



> I am working on a project to change xen's code.
>=20
> Unfortunately I can not find the MACRO def :
> such as :
>=20
> LIBXL_SCHEDULER_SEDF:
>=20
> where I can find it :
>=20
> thank you very much!
>=20
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =C2=A0 switch (sched) {
> =C2=A0 =C2=A0 case LIBXL_SCHEDULER_SEDF:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_sedf_domain_set(gc, domid, scinfo=
);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> =C2=A0 =C2=A0 case LIBXL_SCHEDULER_CREDIT:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_credit_domain_set(gc, domid, scin=
fo);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> =C2=A0 =C2=A0 case LIBXL_SCHEDULER_CREDIT2:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_credit2_domain_set(gc, domid, sci=
nfo);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> =C2=A0 =C2=A0 case LIBXL_SCHEDULER_RTGLOBAL:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_rtglobal_domain_set(gc, domid, sc=
info);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> =C2=A0 =C2=A0 case LIBXL_SCHEDULER_RTPARTITION:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_rtpartition_domain_set(gc, domid,=
 scinfo);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 break; =C2=A0 =C2=A0=C2=A0
> =C2=A0 =C2=A0 case LIBXL_SCHEDULER_ARINC653:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=3Dsched_arinc653_domain_set(gc, domid, sc
>=20

It is defined in _libxl_types.h, that is autogenerated by gentypes.py.


>=20
>=20
>=20
> =3D=3D=3D=3D=3D
>=20
>=20
>=20
>=20
>=20
> =C2=A0Best regards
> Jie Shen
>=20
>=20
> Graduate Student in Computer Science
> Illinois Institute of Technology=C2=A0=C2=A0=C2=A0
> Stuart Building=C2=A0 Chicago, IL 60616
> +1=C2=A0 312 404 0122
>=20
>=20
>=20
--1342847746-1859286638-1418641038=:30971
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1859286638-1418641038=:30971--


From xen-devel-bounces@lists.xen.org Mon Dec 15 11:08:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TW3-0007SH-AY; Mon, 15 Dec 2014 11:08: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 1Y0TW2-0007S5-80
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 11:08:38 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	FD/3F-22819-531CE845; Mon, 15 Dec 2014 11:08:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418641715!13407175!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9899 invoked from network); 15 Dec 2014 11:08:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 11:08:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204385825"
Message-ID: <1418641713.16425.90.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Galla Rao <gallagnv.rao@gmail.com>
Date: Mon, 15 Dec 2014 11:08:33 +0000
In-Reply-To: <CANtx2ovOxN_R0BQskE_OyA_1YjU22x4f4DWhmgzrjbe3iRO6xg@mail.gmail.com>
References: <CANtx2outtiqeGzvbnCX0kY9jocp_+qCUjpxr8ypfWUMjx5A1gA@mail.gmail.com>
	<20141214143408.GB19091@reaktio.net>
	<CANtx2ovOxN_R0BQskE_OyA_1YjU22x4f4DWhmgzrjbe3iRO6xg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] SRIOV on a NIC card
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-14 at 21:09 +0530, Galla Rao wrote:
> True it is not on Xen, it is on solaris platform
> 
> 
> As SRIOV (PCIe) spec is same on all platforms, the feature
> implementation
> should not change
> 
> 
> May be not an appropriate group for posting this query.

If you aren't using Xen then of course xen-devel (a list for the
development of Xen) isn't an appropriate forum.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:11:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TYj-0007mC-5w; Mon, 15 Dec 2014 11:11:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Y0TYh-0007m0-RV
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 11:11:23 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	B8/0C-27623-BD1CE845; Mon, 15 Dec 2014 11:11:23 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418641880!13407751!1
X-Originating-IP: [66.165.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 30621 invoked from network); 15 Dec 2014 11:11:22 -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;
	15 Dec 2014 11:11:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204386482"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 06:11:09 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Y0TYR-0005wa-Lv;
	Mon, 15 Dec 2014 11:11:07 +0000
Message-ID: <548EC1C2.5030900@eu.citrix.com>
Date: Mon, 15 Dec 2014 11:10:58 +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>, Wei Liu <wei.liu2@citrix.com>
References: <1411365561-29242-1-git-send-email-wency@cn.fujitsu.com>	
	<1411365561-29242-4-git-send-email-wency@cn.fujitsu.com>	
	<CAFLBxZbzSAFSZZrW9p+Gz-VTbts+q4Z1xT_+d9jrYJ8jjXVy8g@mail.gmail.com>	
	<20141213170605.GD2285@zion.uk.xensource.com>
	<1418638732.16425.70.camel@citrix.com>
In-Reply-To: <1418638732.16425.70.camel@citrix.com>
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Wen Congyang <wency@cn.fujitsu.com>, xen devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC Patch v4 3/9] pass correct file to qemu if we
 use blktap2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/15/2014 10:18 AM, Ian Campbell wrote:
> On Sat, 2014-12-13 at 17:06 +0000, Wei Liu wrote:
>> On Thu, Dec 11, 2014 at 04:45:09PM +0000, George Dunlap wrote:
>>> On Mon, Sep 22, 2014 at 6:59 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
>>>> If we use blktap2, the correct file should be blktap device
>>>> not the pdev_path.
>>>>
>>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>>>> Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>
>>> If I'm reading this correctly, this is actually a fairly serious bug
>>> in libxl -- it means that when using backend=tap with HVM domains,
>>> qemu will actually *bypass entirely* the tapdisk process and access
>>> the underlying file directly.
>>>
>>
>> Is it because qemu will corrupt the underlying file so it's very
>> serious? 
> 
> I think it ends up being reasonably safe due to the unplug stuff, in
> general only one of the two paths should be active at any given time and
> there is appropriate flushing/syncing on the unplug etc.
> 
> In fact, I'm not 100% sure this wasn't a deliberate design decision at
> one point to avoid the overhead of doing both qdisk and tapdisk. (I'm
> not going to argue that this still makes sense though).
> 
> If qemu is corrupting files then that's a different matter, which would
> indeed be serious, and which this change might paper over/avoid.

Yes, I think when I wrote that I had forgotten that even with just PV /
emulated there's usually a duplicate datapath that we need to sort out,
and that we already sort that out with the device unplug protocol.

Since half the point of tapdisk was to be able to do things like
snapshotting / other fancy tricks as colo does, not just implement
specific image formats, then if it was deliberate it was kind of dumb.
I'd rather just assume that it was overlooked. :-)

In any case, as it's already fixed in 4.5, I don't think the exact
degree of seriousness matters too much: it's above the threshold for
"should be backported" IMHO, and well below the threshold of "needs the
security response process".  So it should just be backported to 4.4,
4.3, and 4.2  (or some subset thereof, if we're designating stable trees).

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:11:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TYj-0007mC-5w; Mon, 15 Dec 2014 11:11:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1Y0TYh-0007m0-RV
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 11:11:23 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	B8/0C-27623-BD1CE845; Mon, 15 Dec 2014 11:11:23 +0000
X-Env-Sender: George.Dunlap@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418641880!13407751!1
X-Originating-IP: [66.165.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 30621 invoked from network); 15 Dec 2014 11:11:22 -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;
	15 Dec 2014 11:11:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204386482"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 06:11:09 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1Y0TYR-0005wa-Lv;
	Mon, 15 Dec 2014 11:11:07 +0000
Message-ID: <548EC1C2.5030900@eu.citrix.com>
Date: Mon, 15 Dec 2014 11:10:58 +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>, Wei Liu <wei.liu2@citrix.com>
References: <1411365561-29242-1-git-send-email-wency@cn.fujitsu.com>	
	<1411365561-29242-4-git-send-email-wency@cn.fujitsu.com>	
	<CAFLBxZbzSAFSZZrW9p+Gz-VTbts+q4Z1xT_+d9jrYJ8jjXVy8g@mail.gmail.com>	
	<20141213170605.GD2285@zion.uk.xensource.com>
	<1418638732.16425.70.camel@citrix.com>
In-Reply-To: <1418638732.16425.70.camel@citrix.com>
X-DLP: MIA1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Wen Congyang <wency@cn.fujitsu.com>, xen devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC Patch v4 3/9] pass correct file to qemu if we
 use blktap2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/15/2014 10:18 AM, Ian Campbell wrote:
> On Sat, 2014-12-13 at 17:06 +0000, Wei Liu wrote:
>> On Thu, Dec 11, 2014 at 04:45:09PM +0000, George Dunlap wrote:
>>> On Mon, Sep 22, 2014 at 6:59 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
>>>> If we use blktap2, the correct file should be blktap device
>>>> not the pdev_path.
>>>>
>>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>>>> Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>
>>> If I'm reading this correctly, this is actually a fairly serious bug
>>> in libxl -- it means that when using backend=tap with HVM domains,
>>> qemu will actually *bypass entirely* the tapdisk process and access
>>> the underlying file directly.
>>>
>>
>> Is it because qemu will corrupt the underlying file so it's very
>> serious? 
> 
> I think it ends up being reasonably safe due to the unplug stuff, in
> general only one of the two paths should be active at any given time and
> there is appropriate flushing/syncing on the unplug etc.
> 
> In fact, I'm not 100% sure this wasn't a deliberate design decision at
> one point to avoid the overhead of doing both qdisk and tapdisk. (I'm
> not going to argue that this still makes sense though).
> 
> If qemu is corrupting files then that's a different matter, which would
> indeed be serious, and which this change might paper over/avoid.

Yes, I think when I wrote that I had forgotten that even with just PV /
emulated there's usually a duplicate datapath that we need to sort out,
and that we already sort that out with the device unplug protocol.

Since half the point of tapdisk was to be able to do things like
snapshotting / other fancy tricks as colo does, not just implement
specific image formats, then if it was deliberate it was kind of dumb.
I'd rather just assume that it was overlooked. :-)

In any case, as it's already fixed in 4.5, I don't think the exact
degree of seriousness matters too much: it's above the threshold for
"should be backported" IMHO, and well below the threshold of "needs the
security response process".  So it should just be backported to 4.4,
4.3, and 4.2  (or some subset thereof, if we're designating stable trees).

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:11:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TYv-0007ok-I7; Mon, 15 Dec 2014 11:11:37 +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 1Y0TYu-0007oQ-55
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:11:36 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	F4/D1-23865-7E1CE845; Mon, 15 Dec 2014 11:11:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418641892!8961551!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 19356 invoked from network); 15 Dec 2014 11:11:33 -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;
	15 Dec 2014 11:11:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204386622"
Message-ID: <548EC1DB.6070301@citrix.com>
Date: Mon, 15 Dec 2014 11:11:23 +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: "Christopher S. Aker" <caker@theshore.net>, xen devel
	<xen-devel@lists.xensource.com>
References: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>
In-Reply-To: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>
X-DLP: MIA2
Subject: Re: [Xen-devel] WARNING: at drivers/xen/gntdev.c:426
 unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/14 15:12, Christopher S. Aker wrote:
> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
> Dom0: 3.17.4
> 
> Things go badly after a day or four.  We've hit this on a number of previously healthy hosts, since moving from 3.10.x dom0 to 3.17.4:
> 
> printk: 5441 messages suppressed.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.

Can you provide more details about your networking and storage setup.
In particular, do you have a domU providing networked storage (iscsi for
example) to other domains on the same host?

David

> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) printk: 4857 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 4846 callbacks suppressed
> (XEN) printk: 4699 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1569 callbacks suppressed
> (XEN) printk: 1809 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2327 callbacks suppressed
> (XEN) printk: 2779 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2509 callbacks suppressed
> (XEN) printk: 2022 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2282 callbacks suppressed
> (XEN) printk: 2778 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2385 callbacks suppressed
> (XEN) printk: 1560 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1714 callbacks suppressed
> (XEN) printk: 1713 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1619 callbacks suppressed
> (XEN) printk: 1852 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1895 callbacks suppressed
> (XEN) printk: 2058 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1797 callbacks suppressed
> (XEN) printk: 1530 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1440 callbacks suppressed
> (XEN) printk: 1306 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> 
> (...this repeats a few hundred times over the course of 30 minutes...)
> 
> net_ratelimit: 1221 callbacks suppressed
> (XEN) printk: 1719 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1747 callbacks suppressed
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1496 callbacks suppressed
> br0: port 80(vif242.0) entered disabled state
> device vif242.0 left promiscuous mode
> br0: port 80(vif242.0) entered disabled state
> device vif249.0 entered promiscuous mode
> xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi) persistent grants
> xen-blkback:ring-ref 9, event-channel 10, protocol 1 (x86_64-abi) persistent grants
> (XEN) printk: 1107 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 648 callbacks suppressed
> m2p_remove_override: pfn 10828f2 mfn 8000000005b4284e, failed to modify kernel mappings
> ------------[ cut here ]------------
> WARNING: CPU: 6 PID: 23911 at drivers/xen/gntdev.c:426 unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
> Modules linked in: xt_u32 xt_physdev ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ip6table_mangle ip6_tables ebtable_nat xen_acpi_processor xen_pciback xen_gntalloc xen_gntdev bonding ebtable_filter 8021q mrp ixgbe mdio ptp pps_core
> CPU: 6 PID: 23911 Comm: qemu-dm Not tainted 3.17.4-1 #1
> Hardware name: Supermicro X9DRE-TF+/X9DR7-TF+/X9DRE-TF+/X9DR7-TF+, BIOS 3.0a 12/04/2013
>  0000000000000009 ffff880043dafcc8 ffffffff81876bcb 0000000000000001
>  0000000000000000 ffff880043dafd08 ffffffff81069777 ffff880043dafd18
>  ffff880020154690 00007f8add804000 00007f8add80f000 ffff880020154660
> Call Trace:
>  [<ffffffff81876bcb>] dump_stack+0x46/0x58
>  [<ffffffff81069777>] warn_slowpath_common+0x87/0xb0
>  [<ffffffff810697b5>] warn_slowpath_null+0x15/0x20
>  [<ffffffffa012d29d>] unmap_if_in_range+0x5d/0x60 [xen_gntdev]
>  [<ffffffffa012d46e>] mn_invl_range_start+0x4e/0xa0 [xen_gntdev]
>  [<ffffffff811615cb>] __mmu_notifier_invalidate_range_start+0x5b/0x90
>  [<ffffffff811469a9>] unmap_vmas+0x79/0x90
>  [<ffffffff8114bb13>] unmap_region+0xa3/0x120
>  [<ffffffff8116b339>] ? new_sync_read+0x79/0xb0
>  [<ffffffff8114bfb1>] ? vma_rb_erase+0x121/0x210
>  [<ffffffff8114dba0>] do_munmap+0x2a0/0x3b0
>  [<ffffffff8114dcf9>] vm_munmap+0x49/0x70
>  [<ffffffff8114ecd6>] SyS_munmap+0x26/0x40
>  [<ffffffff81880169>] system_call_fastpath+0x16/0x1b
> ---[ end trace 25ca87f9adc0ad78 ]---
> INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 32, t=60002 jiffies, g=26177592, c=26177591, q=1229)
> Task dump for CPU 0:
> swapper/0       R  running task    14072     0      0 0x00000008
>  00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
>  ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
>  000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
> Call Trace:
>  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
>  [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
>  [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
>  [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
>  [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
>  [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
>  [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
>  [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
>  [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
>  [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
> INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 34, t=240007 jiffies, g=26177592, c=26177591, q=4592)
> Task dump for CPU 0:
> swapper/0       R  running task    14072     0      0 0x00000008
>  00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
>  ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
>  000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
> Call Trace:
>  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
>  [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
>  [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
>  [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
>  [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
>  [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
>  [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
>  [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
>  [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
>  [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
> INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 34, t=420012 jiffies, g=26177592, c=26177591, q=8255)
> Task dump for CPU 0:
> swapper/0       R  running task    14072     0      0 0x00000008
>  00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
>  ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
>  000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
> Call Trace:
>  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
>  [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
>  [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
>  [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
>  [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
>  [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
>  [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
>  [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
>  [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
>  [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
> 
> Then the dom0 is unresponsive, and requires a reboot.
> 
> Any ideas?
> 
> -Chris
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:11:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TYv-0007ok-I7; Mon, 15 Dec 2014 11:11:37 +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 1Y0TYu-0007oQ-55
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:11:36 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	F4/D1-23865-7E1CE845; Mon, 15 Dec 2014 11:11:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418641892!8961551!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 19356 invoked from network); 15 Dec 2014 11:11:33 -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;
	15 Dec 2014 11:11:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204386622"
Message-ID: <548EC1DB.6070301@citrix.com>
Date: Mon, 15 Dec 2014 11:11:23 +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: "Christopher S. Aker" <caker@theshore.net>, xen devel
	<xen-devel@lists.xensource.com>
References: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>
In-Reply-To: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>
X-DLP: MIA2
Subject: Re: [Xen-devel] WARNING: at drivers/xen/gntdev.c:426
 unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/14 15:12, Christopher S. Aker wrote:
> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
> Dom0: 3.17.4
> 
> Things go badly after a day or four.  We've hit this on a number of previously healthy hosts, since moving from 3.10.x dom0 to 3.17.4:
> 
> printk: 5441 messages suppressed.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.

Can you provide more details about your networking and storage setup.
In particular, do you have a domU providing networked storage (iscsi for
example) to other domains on the same host?

David

> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) printk: 4857 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 4846 callbacks suppressed
> (XEN) printk: 4699 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1569 callbacks suppressed
> (XEN) printk: 1809 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2327 callbacks suppressed
> (XEN) printk: 2779 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2509 callbacks suppressed
> (XEN) printk: 2022 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2282 callbacks suppressed
> (XEN) printk: 2778 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 2385 callbacks suppressed
> (XEN) printk: 1560 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1714 callbacks suppressed
> (XEN) printk: 1713 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1619 callbacks suppressed
> (XEN) printk: 1852 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1895 callbacks suppressed
> (XEN) printk: 2058 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1797 callbacks suppressed
> (XEN) printk: 1530 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1440 callbacks suppressed
> (XEN) printk: 1306 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> 
> (...this repeats a few hundred times over the course of 30 minutes...)
> 
> net_ratelimit: 1221 callbacks suppressed
> (XEN) printk: 1719 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1747 callbacks suppressed
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 1496 callbacks suppressed
> br0: port 80(vif242.0) entered disabled state
> device vif242.0 left promiscuous mode
> br0: port 80(vif242.0) entered disabled state
> device vif249.0 entered promiscuous mode
> xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi) persistent grants
> xen-blkback:ring-ref 9, event-channel 10, protocol 1 (x86_64-abi) persistent grants
> (XEN) printk: 1107 messages suppressed.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> (XEN) grant_table.c:567:d0 Failed to obtain maptrack handle.
> net_ratelimit: 648 callbacks suppressed
> m2p_remove_override: pfn 10828f2 mfn 8000000005b4284e, failed to modify kernel mappings
> ------------[ cut here ]------------
> WARNING: CPU: 6 PID: 23911 at drivers/xen/gntdev.c:426 unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
> Modules linked in: xt_u32 xt_physdev ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ip6table_mangle ip6_tables ebtable_nat xen_acpi_processor xen_pciback xen_gntalloc xen_gntdev bonding ebtable_filter 8021q mrp ixgbe mdio ptp pps_core
> CPU: 6 PID: 23911 Comm: qemu-dm Not tainted 3.17.4-1 #1
> Hardware name: Supermicro X9DRE-TF+/X9DR7-TF+/X9DRE-TF+/X9DR7-TF+, BIOS 3.0a 12/04/2013
>  0000000000000009 ffff880043dafcc8 ffffffff81876bcb 0000000000000001
>  0000000000000000 ffff880043dafd08 ffffffff81069777 ffff880043dafd18
>  ffff880020154690 00007f8add804000 00007f8add80f000 ffff880020154660
> Call Trace:
>  [<ffffffff81876bcb>] dump_stack+0x46/0x58
>  [<ffffffff81069777>] warn_slowpath_common+0x87/0xb0
>  [<ffffffff810697b5>] warn_slowpath_null+0x15/0x20
>  [<ffffffffa012d29d>] unmap_if_in_range+0x5d/0x60 [xen_gntdev]
>  [<ffffffffa012d46e>] mn_invl_range_start+0x4e/0xa0 [xen_gntdev]
>  [<ffffffff811615cb>] __mmu_notifier_invalidate_range_start+0x5b/0x90
>  [<ffffffff811469a9>] unmap_vmas+0x79/0x90
>  [<ffffffff8114bb13>] unmap_region+0xa3/0x120
>  [<ffffffff8116b339>] ? new_sync_read+0x79/0xb0
>  [<ffffffff8114bfb1>] ? vma_rb_erase+0x121/0x210
>  [<ffffffff8114dba0>] do_munmap+0x2a0/0x3b0
>  [<ffffffff8114dcf9>] vm_munmap+0x49/0x70
>  [<ffffffff8114ecd6>] SyS_munmap+0x26/0x40
>  [<ffffffff81880169>] system_call_fastpath+0x16/0x1b
> ---[ end trace 25ca87f9adc0ad78 ]---
> INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 32, t=60002 jiffies, g=26177592, c=26177591, q=1229)
> Task dump for CPU 0:
> swapper/0       R  running task    14072     0      0 0x00000008
>  00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
>  ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
>  000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
> Call Trace:
>  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
>  [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
>  [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
>  [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
>  [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
>  [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
>  [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
>  [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
>  [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
>  [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
> INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 34, t=240007 jiffies, g=26177592, c=26177591, q=4592)
> Task dump for CPU 0:
> swapper/0       R  running task    14072     0      0 0x00000008
>  00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
>  ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
>  000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
> Call Trace:
>  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
>  [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
>  [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
>  [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
>  [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
>  [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
>  [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
>  [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
>  [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
>  [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
> INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 34, t=420012 jiffies, g=26177592, c=26177591, q=8255)
> Task dump for CPU 0:
> swapper/0       R  running task    14072     0      0 0x00000008
>  00000000ffffffed 0000000000000000 0000000000000001 ffffffffffffffff
>  ffffffff810013aa 000000000000e030 0000000000000246 ffffffff81e03e30
>  000000000000e02b 0000000000000000 0000000000000000 ffffffff8100a0c0
> Call Trace:
>  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
>  [<ffffffff8100a0c0>] ? xen_safe_halt+0x10/0x20
>  [<ffffffff8101d73f>] ? default_idle+0x1f/0xb0
>  [<ffffffff8101dfea>] ? arch_cpu_idle+0xa/0x10
>  [<ffffffff8109ead4>] ? cpu_startup_entry+0x284/0x330
>  [<ffffffff8186ec7d>] ? rest_init+0x6d/0x70
>  [<ffffffff81eea081>] ? start_kernel+0x41d/0x42a
>  [<ffffffff81ee9a51>] ? set_init_arg+0x58/0x58
>  [<ffffffff81ee95f0>] ? x86_64_start_reservations+0x2a/0x2c
>  [<ffffffff81eed774>] ? xen_start_kernel+0x540/0x542
> 
> Then the dom0 is unresponsive, and requires a reboot.
> 
> Any ideas?
> 
> -Chris
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:12:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0TZp-00083B-0P; Mon, 15 Dec 2014 11:12: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 1Y0TZo-000832-Bn
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:12:32 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	E6/31-17694-F12CE845; Mon, 15 Dec 2014 11:12:31 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418641950!13414630!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17546 invoked from network); 15 Dec 2014 11:12:30 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 11:12:30 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9E758AD17;
	Mon, 15 Dec 2014 11:12:30 +0000 (UTC)
Message-ID: <548EC21D.1040701@suse.com>
Date: Mon, 15 Dec 2014 12:12: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: David Vrabel <david.vrabel@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, 
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <548AEAE7.8020604@suse.com> <548B25FC.6020601@citrix.com>
In-Reply-To: <548B25FC.6020601@citrix.com>
Subject: Re: [Xen-devel] Xen's Linux kernel config 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/12/2014 06:29 PM, David Vrabel wrote:
> On 12/12/14 13:17, Juergen Gross wrote:
>>
>>
>> As a first draft I'd suggest the following:
>
> Some rough thoughts below.
>
>> Option                          Selects                 Depends
>> ----------------------------------------------------------------------
>> XEN                             SWIOTLB_XEN(arm,arm64)
>
> XEN should get you basic support for making hypercalls and allowing
> guest to identify themselves as running on Xen.  I don't think it should
> select SWIOTLB_XEN even on ARM as it is only needed for guests with
> access to real hardware.

Okay.

>
>>    XEN_PV(x86)                   XEN_HAVE_PVMMU
>>                                  PARAVIRT
>>                                  PARAVIRT_CLOCK
>>    XEN_PVH(x86)                  XEN_PVHVM
>>                                  PARAVIRT
>>                                  PARAVIRT_CLOCK
>>    XEN_BACKEND                                           XEN_PV(x86) ||
>>                                                          XEN_PVH(x86) ||
>>                                                          XEN_PVHVM
>>      XEN_BLKDEV_BACKEND
>>      XEN_PCIDEV_BACKEND(x86)
>>      XEN_SCSI_BACKEND
>>      XEN_NETDEV_BACKEND
> [...]
>> XEN_PVHVM
>
> Move XEN_PVHVM under XEN and have it select PARAVIRT and PARAVIRT_CLOCK.

Okay.

>
>> XEN_FRONTEND                                            XEN_PV ||
>>                                                          XEN_PVH ||
>>                                                          XEN_PVHVM
>
> This enables all the basic infrastructure for frontends: event channels,
> grant tables and Xenbus.
>
> Don't make XEN_FRONTEND depend on any XEN_* variant.  It should be
> possible to have frontend drivers without support for any of the
> PV/PVHVM/PVH guest types.  Frontends only need event channels, grant
> table and xenbus.

Okay.

> Perhaps have XEN_FRONTEND select XEN instead?

Hmm, with XEN not selecting anything else automatically (apart from
stuff needed by frontends AND backends) this would be okay, I think.

> You need an additional option to enable the Xen platform PCI device.
> This should depend on XEN_FRONTEND.

Yep.

>
>>    XEN_XENBUS_FRONTEND
>
> Fold this into XEN_FRONTEND?

Hmm, what about Xenstore in an own domain? I'd say XEN_FRONTEND should
select XEN_XENBUS_FRONTEND, but XEN_XENBUS_FRONTEND should be available
to non-frontend domains as well.

>
>>    XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
>>                                  INPUT_XEN_KBDDEV_FRONTEND
>>    XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
>>    HVC_XEN_FRONTEND              XEN_XENBUS_FRONTEND
>>                                  HVC_XEN
>>    TCG_XEN                       XEN_XENBUS_FRONTEND
>>    XEN_PCIDEV_FRONTEND           PCI_XEN
>>                                  XEN_XENBUS_FRONTEND
>>    XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
>>    INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
>>    XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND
>>
>> There might be some further adjustments needed (should XEN_DEV_EVTCHN
>> and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The
>> main difference to the current status is the XEN setting no longer
>> controlling all other options.
>
> XEN_DEV_EVTCH and XEN_GNTDEV are useful to non-backends (e.g., for
> interdomain comms).

Okay.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:12:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0TZp-00083B-0P; Mon, 15 Dec 2014 11:12: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 1Y0TZo-000832-Bn
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:12:32 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	E6/31-17694-F12CE845; Mon, 15 Dec 2014 11:12:31 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418641950!13414630!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17546 invoked from network); 15 Dec 2014 11:12:30 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 11:12:30 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9E758AD17;
	Mon, 15 Dec 2014 11:12:30 +0000 (UTC)
Message-ID: <548EC21D.1040701@suse.com>
Date: Mon, 15 Dec 2014 12:12: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: David Vrabel <david.vrabel@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, 
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <548AEAE7.8020604@suse.com> <548B25FC.6020601@citrix.com>
In-Reply-To: <548B25FC.6020601@citrix.com>
Subject: Re: [Xen-devel] Xen's Linux kernel config 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/12/2014 06:29 PM, David Vrabel wrote:
> On 12/12/14 13:17, Juergen Gross wrote:
>>
>>
>> As a first draft I'd suggest the following:
>
> Some rough thoughts below.
>
>> Option                          Selects                 Depends
>> ----------------------------------------------------------------------
>> XEN                             SWIOTLB_XEN(arm,arm64)
>
> XEN should get you basic support for making hypercalls and allowing
> guest to identify themselves as running on Xen.  I don't think it should
> select SWIOTLB_XEN even on ARM as it is only needed for guests with
> access to real hardware.

Okay.

>
>>    XEN_PV(x86)                   XEN_HAVE_PVMMU
>>                                  PARAVIRT
>>                                  PARAVIRT_CLOCK
>>    XEN_PVH(x86)                  XEN_PVHVM
>>                                  PARAVIRT
>>                                  PARAVIRT_CLOCK
>>    XEN_BACKEND                                           XEN_PV(x86) ||
>>                                                          XEN_PVH(x86) ||
>>                                                          XEN_PVHVM
>>      XEN_BLKDEV_BACKEND
>>      XEN_PCIDEV_BACKEND(x86)
>>      XEN_SCSI_BACKEND
>>      XEN_NETDEV_BACKEND
> [...]
>> XEN_PVHVM
>
> Move XEN_PVHVM under XEN and have it select PARAVIRT and PARAVIRT_CLOCK.

Okay.

>
>> XEN_FRONTEND                                            XEN_PV ||
>>                                                          XEN_PVH ||
>>                                                          XEN_PVHVM
>
> This enables all the basic infrastructure for frontends: event channels,
> grant tables and Xenbus.
>
> Don't make XEN_FRONTEND depend on any XEN_* variant.  It should be
> possible to have frontend drivers without support for any of the
> PV/PVHVM/PVH guest types.  Frontends only need event channels, grant
> table and xenbus.

Okay.

> Perhaps have XEN_FRONTEND select XEN instead?

Hmm, with XEN not selecting anything else automatically (apart from
stuff needed by frontends AND backends) this would be okay, I think.

> You need an additional option to enable the Xen platform PCI device.
> This should depend on XEN_FRONTEND.

Yep.

>
>>    XEN_XENBUS_FRONTEND
>
> Fold this into XEN_FRONTEND?

Hmm, what about Xenstore in an own domain? I'd say XEN_FRONTEND should
select XEN_XENBUS_FRONTEND, but XEN_XENBUS_FRONTEND should be available
to non-frontend domains as well.

>
>>    XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
>>                                  INPUT_XEN_KBDDEV_FRONTEND
>>    XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
>>    HVC_XEN_FRONTEND              XEN_XENBUS_FRONTEND
>>                                  HVC_XEN
>>    TCG_XEN                       XEN_XENBUS_FRONTEND
>>    XEN_PCIDEV_FRONTEND           PCI_XEN
>>                                  XEN_XENBUS_FRONTEND
>>    XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
>>    INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
>>    XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND
>>
>> There might be some further adjustments needed (should XEN_DEV_EVTCHN
>> and XEN_GNTDEV belong to XEN_BACKEND?), but these are minor nits. The
>> main difference to the current status is the XEN setting no longer
>> controlling all other options.
>
> XEN_DEV_EVTCH and XEN_GNTDEV are useful to non-backends (e.g., for
> interdomain comms).

Okay.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:13:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:13:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Tb2-0008CF-FJ; Mon, 15 Dec 2014 11:13:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Y0Tb1-0008Bu-6l
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:13:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E3/87-09842-962CE845; Mon, 15 Dec 2014 11:13:45 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418642022!15584183!1
X-Originating-IP: [66.165.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 8269 invoked from network); 15 Dec 2014 11:13:43 -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;
	15 Dec 2014 11:13:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204844400"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 06:13: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 1Y0Taj-0005yy-Q0;
	Mon, 15 Dec 2014 11:13:29 +0000
Date: Mon, 15 Dec 2014 11:13:06 +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: <20141212165035.GA28592@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1412151108370.30971@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
	<1999787702.20141212161352@eikelenboom.it>
	<20141212165035.GA28592@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 \(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>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [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 Fri, 12 Dec 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote:
> > Hi Konrad,
> > 
> > This doesn't seem to be applied yet, nor does it seem to have a release-(N)ACK 
> > from you ?
> 
> Hm, Stefano:
> 
> - Is this a regression?

I don't think so. Probably a regression compared to the xend toolstack
though.


> - What are the risks of this not going in? I presume that it just means
>   we haven't reset it in sysfs. But the xc_deassign_device operation
>   if not done will not affect the hypervisor - which will move the
>   device to dom0 upon guest teardown.

The device becomes unusable until somebody manually resets it.


> > 
> > --
> > Sander
> > 
> > 
> > 
> > Friday, November 28, 2014, 5:53:09 PM, you wrote:
> > 
> > > 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 Mon Dec 15 11:13:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:13:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Tb2-0008CF-FJ; Mon, 15 Dec 2014 11:13:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Y0Tb1-0008Bu-6l
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:13:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E3/87-09842-962CE845; Mon, 15 Dec 2014 11:13:45 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418642022!15584183!1
X-Originating-IP: [66.165.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 8269 invoked from network); 15 Dec 2014 11:13:43 -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;
	15 Dec 2014 11:13:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204844400"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 06:13: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 1Y0Taj-0005yy-Q0;
	Mon, 15 Dec 2014 11:13:29 +0000
Date: Mon, 15 Dec 2014 11:13:06 +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: <20141212165035.GA28592@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1412151108370.30971@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
	<1999787702.20141212161352@eikelenboom.it>
	<20141212165035.GA28592@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 \(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>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [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 Fri, 12 Dec 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote:
> > Hi Konrad,
> > 
> > This doesn't seem to be applied yet, nor does it seem to have a release-(N)ACK 
> > from you ?
> 
> Hm, Stefano:
> 
> - Is this a regression?

I don't think so. Probably a regression compared to the xend toolstack
though.


> - What are the risks of this not going in? I presume that it just means
>   we haven't reset it in sysfs. But the xc_deassign_device operation
>   if not done will not affect the hypervisor - which will move the
>   device to dom0 upon guest teardown.

The device becomes unusable until somebody manually resets it.


> > 
> > --
> > Sander
> > 
> > 
> > 
> > Friday, November 28, 2014, 5:53:09 PM, you wrote:
> > 
> > > 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 Mon Dec 15 11:20:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0Thf-0008RB-BF; Mon, 15 Dec 2014 11:20:39 +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 1Y0The-0008R6-7O
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 11:20:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F3/8A-25276-504CE845; Mon, 15 Dec 2014 11:20:37 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418642435!15650730!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19570 invoked from network); 15 Dec 2014 11:20:36 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-21.messagelabs.com with SMTP;
	15 Dec 2014 11:20:36 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 15 Dec 2014 03:20:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,579,1413270000"; d="scan'208";a="637688650"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by fmsmga001.fm.intel.com with ESMTP; 15 Dec 2014 03:20:32 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 15 Dec 2014 19:16:17 +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; Mon, 15 Dec 2014 19:16:15 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQGC/gTnKCuINaSEuNrOPaD/DIeJyP0EwAgACJvQD//4DVAIAAo/BA
Date: Mon, 15 Dec 2014 11:16:15 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611B0C7@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
	<548EB672020000780004F7D2@mail.emea.novell.com>
In-Reply-To: <548EB672020000780004F7D2@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: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, December 15, 2014 5:23 PM
> 
> >>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
> > yes, definitely host RAM is the upper limit, and what I'm concerning here
> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
> > resource, w/o collision with other PFN reservation usage (ballooning
> > should be fine since it's operating existing RAM ranges in dom0 e820
> > table).
> 
> I don't think ballooning is restricted to the regions named RAM in
> Dom0's E820 table (at least it shouldn't be, and wasn't in the
> classic Xen kernels).

well, nice to know that.

> 
> > Maybe we can reserve a big-enough reserved region in dom0's
> > e820 table at boot time, for all PFN reservation usages, and then allocate
> > them on-demand for specific usages?
> 
> What would "big enough" here mean (i.e. how would one determine
> the needed size up front)? Plus any form of allocation would need a
> reasonable approach to avoid fragmentation. And anyway I'm not
> getting what position you're on: Do you expect to be able to fit
> everything that needs mapping into the available mapping space (as
> your reply above seems to imply) or do you think there won't be
> enough mapping space (as earlier replies of yours appeared to
> indicate)?
> 

I expect to have everything mapped into the available mapping space,
and is asking for suggestions what's the best way to find and reserve
available PFNs in a way not conflicting with other usages (either
virtualization features like ballooning that you mentioned, or bare 
metal features like PCI hotplug or memory hotplug).

Tanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:20:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0Thf-0008RB-BF; Mon, 15 Dec 2014 11:20:39 +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 1Y0The-0008R6-7O
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 11:20:38 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F3/8A-25276-504CE845; Mon, 15 Dec 2014 11:20:37 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418642435!15650730!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19570 invoked from network); 15 Dec 2014 11:20:36 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-21.messagelabs.com with SMTP;
	15 Dec 2014 11:20:36 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 15 Dec 2014 03:20:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,579,1413270000"; d="scan'208";a="637688650"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by fmsmga001.fm.intel.com with ESMTP; 15 Dec 2014 03:20:32 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Mon, 15 Dec 2014 19:16:17 +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; Mon, 15 Dec 2014 19:16:15 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
Thread-Index: AQHQGC/gTnKCuINaSEuNrOPaD/DIeJyP0EwAgACJvQD//4DVAIAAo/BA
Date: Mon, 15 Dec 2014 11:16:15 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D12611B0C7@SHSMSX101.ccr.corp.intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
	<548EB672020000780004F7D2@mail.emea.novell.com>
In-Reply-To: <548EB672020000780004F7D2@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: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, December 15, 2014 5:23 PM
> 
> >>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
> > yes, definitely host RAM is the upper limit, and what I'm concerning here
> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
> > resource, w/o collision with other PFN reservation usage (ballooning
> > should be fine since it's operating existing RAM ranges in dom0 e820
> > table).
> 
> I don't think ballooning is restricted to the regions named RAM in
> Dom0's E820 table (at least it shouldn't be, and wasn't in the
> classic Xen kernels).

well, nice to know that.

> 
> > Maybe we can reserve a big-enough reserved region in dom0's
> > e820 table at boot time, for all PFN reservation usages, and then allocate
> > them on-demand for specific usages?
> 
> What would "big enough" here mean (i.e. how would one determine
> the needed size up front)? Plus any form of allocation would need a
> reasonable approach to avoid fragmentation. And anyway I'm not
> getting what position you're on: Do you expect to be able to fit
> everything that needs mapping into the available mapping space (as
> your reply above seems to imply) or do you think there won't be
> enough mapping space (as earlier replies of yours appeared to
> indicate)?
> 

I expect to have everything mapped into the available mapping space,
and is asking for suggestions what's the best way to find and reserve
available PFNs in a way not conflicting with other usages (either
virtualization features like ballooning that you mentioned, or bare 
metal features like PCI hotplug or memory hotplug).

Tanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:24:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0Tl6-0000Rs-3j; Mon, 15 Dec 2014 11:24: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 1Y0Tl5-0000Rm-4d
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 11:24:11 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	CA/34-24124-AD4CE845; Mon, 15 Dec 2014 11:24:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418642647!7962287!1
X-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 31502 invoked from network); 15 Dec 2014 11:24:08 -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; 15 Dec 2014 11:24:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 11:24:07 +0000
Message-Id: <548ED2E3020000780004F8CB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 11:24:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418640268.16425.79.camel@citrix.com>
In-Reply-To: <1418640268.16425.79.camel@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] Lots of ACPI warnings from newer iasl (20140926).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 11:44, <Ian.Campbell@citrix.com> wrote:
> isal 20140926-1 in Debian Jessie is rather vocal about
> tools/firmware/hvmloader/acpi. See below. Essentially, a few of these:
>         Control Method should be made Serialized (due to creation of
>         named objects within)
> a slew of:
>         Object is not referenced ^  (Name is within method [_CRS])
> and a load of:
>         ^ Reserved method should not return a value (_L02)
> 
> 4.4 seems to produce a similar looking set of warnings, so I think this
> is a case of newer iasl having more warnings rather than a regression in
> our code.
> 
> I also tried iasl from 20141107-1 Sid and it is similarly vocal.

I had noticed some of these too, and was intending to address them
eventually. As usual, other things continued to take higher priority.
But the lack of serialization of some of the methods I didn't notice so
far, and those seem more relevant to fix than the others. I'll see to
get to this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:24:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0Tl6-0000Rs-3j; Mon, 15 Dec 2014 11:24: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 1Y0Tl5-0000Rm-4d
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 11:24:11 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	CA/34-24124-AD4CE845; Mon, 15 Dec 2014 11:24:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418642647!7962287!1
X-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 31502 invoked from network); 15 Dec 2014 11:24:08 -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; 15 Dec 2014 11:24:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 11:24:07 +0000
Message-Id: <548ED2E3020000780004F8CB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 11:24:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418640268.16425.79.camel@citrix.com>
In-Reply-To: <1418640268.16425.79.camel@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] Lots of ACPI warnings from newer iasl (20140926).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 11:44, <Ian.Campbell@citrix.com> wrote:
> isal 20140926-1 in Debian Jessie is rather vocal about
> tools/firmware/hvmloader/acpi. See below. Essentially, a few of these:
>         Control Method should be made Serialized (due to creation of
>         named objects within)
> a slew of:
>         Object is not referenced ^  (Name is within method [_CRS])
> and a load of:
>         ^ Reserved method should not return a value (_L02)
> 
> 4.4 seems to produce a similar looking set of warnings, so I think this
> is a case of newer iasl having more warnings rather than a regression in
> our code.
> 
> I also tried iasl from 20141107-1 Sid and it is similarly vocal.

I had noticed some of these too, and was intending to address them
eventually. As usual, other things continued to take higher priority.
But the lack of serialization of some of the methods I didn't notice so
far, and those seem more relevant to fix than the others. I'll see to
get to this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:27:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:27:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0ToG-0000Zu-NX; Mon, 15 Dec 2014 11:27: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 1Y0ToF-0000Zp-TO
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 11:27:28 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	18/A2-02699-F95CE845; Mon, 15 Dec 2014 11:27:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418642846!15077286!1
X-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 4291 invoked from network); 15 Dec 2014 11:27:26 -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; 15 Dec 2014 11:27:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 11:27:25 +0000
Message-Id: <548ED3AA020000780004F8D7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 11:27:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
	<548EB672020000780004F7D2@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611B0C7@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611B0C7@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 12:16, <kevin.tian@intel.com> wrote:
> I expect to have everything mapped into the available mapping space,
> and is asking for suggestions what's the best way to find and reserve
> available PFNs in a way not conflicting with other usages (either
> virtualization features like ballooning that you mentioned, or bare 
> metal features like PCI hotplug or memory hotplug).

Not conflicting with memory hotplug ought to be technically possible
(using SRAT information), but if all physical address space is marked
as possibly being used for hotplug memory this wouldn't help your
case. PCI hotplug (or even just dynamic resource re-assignment)
might be quite a bit more tricky, or would require (as you suggested
earlier) to mark certain regions as reserved in the E820 Dom0
receives. Not conflicting with ballooning is - just like memory hotplug -
simply dependent on enough space not being used for that purpose.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:27:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:27:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0ToG-0000Zu-NX; Mon, 15 Dec 2014 11:27: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 1Y0ToF-0000Zp-TO
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 11:27:28 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	18/A2-02699-F95CE845; Mon, 15 Dec 2014 11:27:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418642846!15077286!1
X-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 4291 invoked from network); 15 Dec 2014 11:27:26 -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; 15 Dec 2014 11:27:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 11:27:25 +0000
Message-Id: <548ED3AA020000780004F8D7@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 11:27:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
	<548EB672020000780004F7D2@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611B0C7@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611B0C7@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, Tim Deegan <tim@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 12:16, <kevin.tian@intel.com> wrote:
> I expect to have everything mapped into the available mapping space,
> and is asking for suggestions what's the best way to find and reserve
> available PFNs in a way not conflicting with other usages (either
> virtualization features like ballooning that you mentioned, or bare 
> metal features like PCI hotplug or memory hotplug).

Not conflicting with memory hotplug ought to be technically possible
(using SRAT information), but if all physical address space is marked
as possibly being used for hotplug memory this wouldn't help your
case. PCI hotplug (or even just dynamic resource re-assignment)
might be quite a bit more tricky, or would require (as you suggested
earlier) to mark certain regions as reserved in the E820 Dom0
receives. Not conflicting with ballooning is - just like memory hotplug -
simply dependent on enough space not being used for that purpose.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:29:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0TqM-0000gM-8B; Mon, 15 Dec 2014 11:29:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Y0TqK-0000gF-82
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 11:29:36 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	28/03-25727-F16CE845; Mon, 15 Dec 2014 11:29:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418642973!13368219!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 20234 invoked from network); 15 Dec 2014 11:29:34 -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;
	15 Dec 2014 11:29:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; 
	d="scan'208,217";a="204849711"
Message-ID: <548EC61B.6000806@citrix.com>
Date: Mon, 15 Dec 2014 11:29: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: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <548EB4E9020000780004F7BE@mail.emea.novell.com>
In-Reply-To: <548EB4E9020000780004F7BE@mail.emea.novell.com>
X-DLP: MIA1
Cc: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/AMD-ucode: correct multiple container
 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: multipart/mixed; boundary="===============7630040474445199251=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7630040474445199251==
Content-Type: multipart/alternative;
	boundary="------------050004020708090308040904"

--------------050004020708090308040904
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

On 15/12/14 09:16, Jan Beulich wrote:
> Avoid emitting an error message referring to an incorrect or corrupt
> container file just because no entry was found for the running CPU.
>
> Additionally switch the order of data validation and consumption in
> cpu_request_microcode()'s first loop, and also check the types of
> skipped blocks in container_fast_forward().
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

>
> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -331,12 +331,17 @@ static int container_fast_forward(const=20
>               header[1] =3D=3D UCODE_EQUIV_CPU_TABLE_TYPE )
>              break;
> =20
> +        if ( header[0] !=3D UCODE_UCODE_TYPE )
> +            return -EINVAL;
>          size =3D header[1] + SECTION_HDR_SIZE;
>          if ( size < PATCH_HDR_SIZE || size_left < size )
>              return -EINVAL;
> =20
>          size_left -=3D size;
>          *offset +=3D size;
> +
> +        if ( !size_left )
> +            return -ENODATA;
>      }
> =20
>      return 0;
> @@ -386,10 +391,6 @@ static int cpu_request_microcode(int cpu
>              break;
>          }
> =20
> -        if ( find_equiv_cpu_id(mc_amd->equiv_cpu_table, current_cpu_id=
,
> -                               &equiv_cpu_id) )
> -                break;
> -
>          /*
>           * Could happen as we advance 'offset' early
>           * in install_equiv_cpu_table
> @@ -401,7 +402,16 @@ static int cpu_request_microcode(int cpu
>              break;
>          }
> =20
> +        if ( find_equiv_cpu_id(mc_amd->equiv_cpu_table, current_cpu_id=
,
> +                               &equiv_cpu_id) )
> +            break;
> +
>          error =3D container_fast_forward(buf, bufsize - offset, &offse=
t);
> +        if ( error =3D=3D -ENODATA )
> +        {
> +            ASSERT(offset =3D=3D bufsize);
> +            break;
> +        }
>          if ( error )
>          {
>              printk(KERN_ERR "microcode: CPU%d incorrect or corrupt con=
tainer file\n"
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------050004020708090308040904
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 15/12/14 09:16, Jan Beulich wrote:<br>
    </div>
    <blockquote cite="mid:548EB4E9020000780004F7BE@mail.emea.novell.com"
      type="cite">
      <pre wrap="">Avoid emitting an error message referring to an incorrect or corrupt
container file just because no entry was found for the running CPU.

Additionally switch the order of data validation and consumption in
cpu_request_microcode()'s first loop, and also check the types of
skipped blocks in container_fast_forward().

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:548EB4E9020000780004F7BE@mail.emea.novell.com"
      type="cite">
      <pre wrap="">

--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -331,12 +331,17 @@ static int container_fast_forward(const 
              header[1] == UCODE_EQUIV_CPU_TABLE_TYPE )
             break;
 
+        if ( header[0] != UCODE_UCODE_TYPE )
+            return -EINVAL;
         size = header[1] + SECTION_HDR_SIZE;
         if ( size &lt; PATCH_HDR_SIZE || size_left &lt; size )
             return -EINVAL;
 
         size_left -= size;
         *offset += size;
+
+        if ( !size_left )
+            return -ENODATA;
     }
 
     return 0;
@@ -386,10 +391,6 @@ static int cpu_request_microcode(int cpu
             break;
         }
 
-        if ( find_equiv_cpu_id(mc_amd-&gt;equiv_cpu_table, current_cpu_id,
-                               &amp;equiv_cpu_id) )
-                break;
-
         /*
          * Could happen as we advance 'offset' early
          * in install_equiv_cpu_table
@@ -401,7 +402,16 @@ static int cpu_request_microcode(int cpu
             break;
         }
 
+        if ( find_equiv_cpu_id(mc_amd-&gt;equiv_cpu_table, current_cpu_id,
+                               &amp;equiv_cpu_id) )
+            break;
+
         error = container_fast_forward(buf, bufsize - offset, &amp;offset);
+        if ( error == -ENODATA )
+        {
+            ASSERT(offset == bufsize);
+            break;
+        }
         if ( error )
         {
             printk(KERN_ERR "microcode: CPU%d incorrect or corrupt container file\n"



</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>

--------------050004020708090308040904--


--===============7630040474445199251==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7630040474445199251==--


From xen-devel-bounces@lists.xen.org Mon Dec 15 11:29:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11: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 1Y0TqM-0000gM-8B; Mon, 15 Dec 2014 11:29:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Y0TqK-0000gF-82
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 11:29:36 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	28/03-25727-F16CE845; Mon, 15 Dec 2014 11:29:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418642973!13368219!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 20234 invoked from network); 15 Dec 2014 11:29:34 -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;
	15 Dec 2014 11:29:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; 
	d="scan'208,217";a="204849711"
Message-ID: <548EC61B.6000806@citrix.com>
Date: Mon, 15 Dec 2014 11:29: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: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <548EB4E9020000780004F7BE@mail.emea.novell.com>
In-Reply-To: <548EB4E9020000780004F7BE@mail.emea.novell.com>
X-DLP: MIA1
Cc: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/AMD-ucode: correct multiple container
 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: multipart/mixed; boundary="===============7630040474445199251=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7630040474445199251==
Content-Type: multipart/alternative;
	boundary="------------050004020708090308040904"

--------------050004020708090308040904
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

On 15/12/14 09:16, Jan Beulich wrote:
> Avoid emitting an error message referring to an incorrect or corrupt
> container file just because no entry was found for the running CPU.
>
> Additionally switch the order of data validation and consumption in
> cpu_request_microcode()'s first loop, and also check the types of
> skipped blocks in container_fast_forward().
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

>
> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -331,12 +331,17 @@ static int container_fast_forward(const=20
>               header[1] =3D=3D UCODE_EQUIV_CPU_TABLE_TYPE )
>              break;
> =20
> +        if ( header[0] !=3D UCODE_UCODE_TYPE )
> +            return -EINVAL;
>          size =3D header[1] + SECTION_HDR_SIZE;
>          if ( size < PATCH_HDR_SIZE || size_left < size )
>              return -EINVAL;
> =20
>          size_left -=3D size;
>          *offset +=3D size;
> +
> +        if ( !size_left )
> +            return -ENODATA;
>      }
> =20
>      return 0;
> @@ -386,10 +391,6 @@ static int cpu_request_microcode(int cpu
>              break;
>          }
> =20
> -        if ( find_equiv_cpu_id(mc_amd->equiv_cpu_table, current_cpu_id=
,
> -                               &equiv_cpu_id) )
> -                break;
> -
>          /*
>           * Could happen as we advance 'offset' early
>           * in install_equiv_cpu_table
> @@ -401,7 +402,16 @@ static int cpu_request_microcode(int cpu
>              break;
>          }
> =20
> +        if ( find_equiv_cpu_id(mc_amd->equiv_cpu_table, current_cpu_id=
,
> +                               &equiv_cpu_id) )
> +            break;
> +
>          error =3D container_fast_forward(buf, bufsize - offset, &offse=
t);
> +        if ( error =3D=3D -ENODATA )
> +        {
> +            ASSERT(offset =3D=3D bufsize);
> +            break;
> +        }
>          if ( error )
>          {
>              printk(KERN_ERR "microcode: CPU%d incorrect or corrupt con=
tainer file\n"
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------050004020708090308040904
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 15/12/14 09:16, Jan Beulich wrote:<br>
    </div>
    <blockquote cite="mid:548EB4E9020000780004F7BE@mail.emea.novell.com"
      type="cite">
      <pre wrap="">Avoid emitting an error message referring to an incorrect or corrupt
container file just because no entry was found for the running CPU.

Additionally switch the order of data validation and consumption in
cpu_request_microcode()'s first loop, and also check the types of
skipped blocks in container_fast_forward().

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:548EB4E9020000780004F7BE@mail.emea.novell.com"
      type="cite">
      <pre wrap="">

--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -331,12 +331,17 @@ static int container_fast_forward(const 
              header[1] == UCODE_EQUIV_CPU_TABLE_TYPE )
             break;
 
+        if ( header[0] != UCODE_UCODE_TYPE )
+            return -EINVAL;
         size = header[1] + SECTION_HDR_SIZE;
         if ( size &lt; PATCH_HDR_SIZE || size_left &lt; size )
             return -EINVAL;
 
         size_left -= size;
         *offset += size;
+
+        if ( !size_left )
+            return -ENODATA;
     }
 
     return 0;
@@ -386,10 +391,6 @@ static int cpu_request_microcode(int cpu
             break;
         }
 
-        if ( find_equiv_cpu_id(mc_amd-&gt;equiv_cpu_table, current_cpu_id,
-                               &amp;equiv_cpu_id) )
-                break;
-
         /*
          * Could happen as we advance 'offset' early
          * in install_equiv_cpu_table
@@ -401,7 +402,16 @@ static int cpu_request_microcode(int cpu
             break;
         }
 
+        if ( find_equiv_cpu_id(mc_amd-&gt;equiv_cpu_table, current_cpu_id,
+                               &amp;equiv_cpu_id) )
+            break;
+
         error = container_fast_forward(buf, bufsize - offset, &amp;offset);
+        if ( error == -ENODATA )
+        {
+            ASSERT(offset == bufsize);
+            break;
+        }
         if ( error )
         {
             printk(KERN_ERR "microcode: CPU%d incorrect or corrupt container file\n"



</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>

--------------050004020708090308040904--


--===============7630040474445199251==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7630040474445199251==--


From xen-devel-bounces@lists.xen.org Mon Dec 15 11:39:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TzE-00014y-9j; Mon, 15 Dec 2014 11:38:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Y0TzD-00014t-9B
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:38:47 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	1C/FB-22777-648CE845; Mon, 15 Dec 2014 11:38:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418643524!13373874!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 12305 invoked from network); 15 Dec 2014 11:38: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;
	15 Dec 2014 11:38:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204394282"
Message-ID: <548EC841.2000107@citrix.com>
Date: Mon, 15 Dec 2014 11:38:41 +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: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<x86@kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, 
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
	<mmarek@suse.cz>, <linux-kbuild@vger.kernel.org>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-2-git-send-email-jgross@suse.com>
In-Reply-To: <1418321065-10212-2-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/14 18:04, Juergen Gross wrote:
> Today there are several places in the kernel which build tables
> containing one entry for each possible Xen hypercall. Create an
> infrastructure to be able to generate these tables at build time.

Does arm and arm64 need something similar?  If so are the tools here
suitable for them?

> --- a/arch/x86/syscalls/Makefile
> +++ b/arch/x86/syscalls/Makefile

Why are these changes here and not in arch/x86/xen/Makefile?

> @@ -19,6 +19,9 @@ quiet_cmd_syshdr = SYSHDR  $@
>  quiet_cmd_systbl = SYSTBL  $@
>        cmd_systbl = $(CONFIG_SHELL) '$(systbl)' $< $@
>  
> +quiet_cmd_hypercalls = HYPERCALLS $@
> +      cmd_hypercalls = $(CONFIG_SHELL) '$<' $@ $(filter-out $<,$^)
> +
>  syshdr_abi_unistd_32 := i386
>  $(uapi)/unistd_32.h: $(syscall32) $(syshdr)
>  	$(call if_changed,syshdr)
> @@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
>  $(out)/syscalls_64.h: $(syscall64) $(systbl)
>  	$(call if_changed,systbl)
>  
> +$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
> +	$(call if_changed,hypercalls)
> +
> +$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h

The generated header should end up in asm/xen/

> --- /dev/null
> +++ b/scripts/xen-hypercalls.sh
> @@ -0,0 +1,11 @@
> +#!/bin/sh
> +out="$1"
> +shift
> +in="$@"
> +
> +for i in $in; do
> +	eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
> +done | \
> +awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
> +	END {for (i in v) if (!(v[i] in v))
> +		print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out

Include a comment in the generated output saying what generated it. e.g.,

/* auto-generated by scripts/xen-hypercall.sh */

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:39:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0TzE-00014y-9j; Mon, 15 Dec 2014 11:38:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Y0TzD-00014t-9B
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:38:47 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	1C/FB-22777-648CE845; Mon, 15 Dec 2014 11:38:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418643524!13373874!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 12305 invoked from network); 15 Dec 2014 11:38: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;
	15 Dec 2014 11:38:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204394282"
Message-ID: <548EC841.2000107@citrix.com>
Date: Mon, 15 Dec 2014 11:38:41 +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: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<x86@kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, 
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
	<mmarek@suse.cz>, <linux-kbuild@vger.kernel.org>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-2-git-send-email-jgross@suse.com>
In-Reply-To: <1418321065-10212-2-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/14 18:04, Juergen Gross wrote:
> Today there are several places in the kernel which build tables
> containing one entry for each possible Xen hypercall. Create an
> infrastructure to be able to generate these tables at build time.

Does arm and arm64 need something similar?  If so are the tools here
suitable for them?

> --- a/arch/x86/syscalls/Makefile
> +++ b/arch/x86/syscalls/Makefile

Why are these changes here and not in arch/x86/xen/Makefile?

> @@ -19,6 +19,9 @@ quiet_cmd_syshdr = SYSHDR  $@
>  quiet_cmd_systbl = SYSTBL  $@
>        cmd_systbl = $(CONFIG_SHELL) '$(systbl)' $< $@
>  
> +quiet_cmd_hypercalls = HYPERCALLS $@
> +      cmd_hypercalls = $(CONFIG_SHELL) '$<' $@ $(filter-out $<,$^)
> +
>  syshdr_abi_unistd_32 := i386
>  $(uapi)/unistd_32.h: $(syscall32) $(syshdr)
>  	$(call if_changed,syshdr)
> @@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
>  $(out)/syscalls_64.h: $(syscall64) $(systbl)
>  	$(call if_changed,systbl)
>  
> +$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
> +	$(call if_changed,hypercalls)
> +
> +$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h

The generated header should end up in asm/xen/

> --- /dev/null
> +++ b/scripts/xen-hypercalls.sh
> @@ -0,0 +1,11 @@
> +#!/bin/sh
> +out="$1"
> +shift
> +in="$@"
> +
> +for i in $in; do
> +	eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
> +done | \
> +awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
> +	END {for (i in v) if (!(v[i] in v))
> +		print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out

Include a comment in the generated output saying what generated it. e.g.,

/* auto-generated by scripts/xen-hypercall.sh */

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:45:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0U5i-0001IR-7I; Mon, 15 Dec 2014 11:45:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1Y0U5g-0001IM-O6
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:45:28 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	D3/8A-22777-8D9CE845; Mon, 15 Dec 2014 11:45:28 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418643927!8080751!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28273 invoked from network); 15 Dec 2014 11:45:27 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 11:45:27 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so8695718wiv.8
	for <xen-devel@lists.xensource.com>;
	Mon, 15 Dec 2014 03:45:27 -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:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=i48nHMUOzRZVFuIGHqV8o+oX+1jD3WINTSDN4Ge559Q=;
	b=GPLREjimcfTZ8HS1fXnBGZYS18d/AIP8zo79uJM8lKbSmRrtmuqZQLWb6n4wOm7sBl
	0wI1Oju0cnLp6OfNiZe9I2dTC8NZ+X6GUvc6fHcBleKzGKrIANSfRZ6HA52B559DEdQ8
	jMoVUO1fsN8D0JXQlMJIu80F+SwCKTDXCppyTe3pkK2CCuM8P64A2R+SydTEhZRuR1kn
	Nt8HsQ4qX4DuHHHQfVAtcWuWgnXT47DcOHFKh2Z/iK6moeK6oReVQ8eStrKvqWxbSJ7/
	7tpBLUYbH2/M/a1RQ3sV8UruiwyfoLApvUur+hd3niU+/MehnLBk50w21miD6j4ipYKT
	kTPQ==
X-Received: by 10.194.188.39 with SMTP id fx7mr49449312wjc.113.1418643927239; 
	Mon, 15 Dec 2014 03:45:27 -0800 (PST)
Received: from [10.80.2.76] ([185.25.64.249])
	by mx.google.com with ESMTPSA id dr3sm5056253wib.4.2014.12.15.03.45.25
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 15 Dec 2014 03:45:26 -0800 (PST)
Message-ID: <548EC9D4.6080706@cantab.net>
Date: Mon, 15 Dec 2014 11:45:24 +0000
From: David Vrabel <dvrabel@cantab.net>
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>, linux-kernel@vger.kernel.org, 
	x86@kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz, 
	linux-kbuild@vger.kernel.org
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-3-git-send-email-jgross@suse.com>
In-Reply-To: <1418321065-10212-3-git-send-email-jgross@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/4] xen: synchronize
 include/xen/interface/xen.h with xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/14 18:04, Juergen Gross wrote:
> The header include/xen/interface/xen.h doesn't contain all definitions
> from Xen's version of that header. Update it accordingly.

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 Mon Dec 15 11:45:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0U5i-0001IR-7I; Mon, 15 Dec 2014 11:45:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1Y0U5g-0001IM-O6
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:45:28 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	D3/8A-22777-8D9CE845; Mon, 15 Dec 2014 11:45:28 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418643927!8080751!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28273 invoked from network); 15 Dec 2014 11:45:27 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 11:45:27 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so8695718wiv.8
	for <xen-devel@lists.xensource.com>;
	Mon, 15 Dec 2014 03:45:27 -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:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=i48nHMUOzRZVFuIGHqV8o+oX+1jD3WINTSDN4Ge559Q=;
	b=GPLREjimcfTZ8HS1fXnBGZYS18d/AIP8zo79uJM8lKbSmRrtmuqZQLWb6n4wOm7sBl
	0wI1Oju0cnLp6OfNiZe9I2dTC8NZ+X6GUvc6fHcBleKzGKrIANSfRZ6HA52B559DEdQ8
	jMoVUO1fsN8D0JXQlMJIu80F+SwCKTDXCppyTe3pkK2CCuM8P64A2R+SydTEhZRuR1kn
	Nt8HsQ4qX4DuHHHQfVAtcWuWgnXT47DcOHFKh2Z/iK6moeK6oReVQ8eStrKvqWxbSJ7/
	7tpBLUYbH2/M/a1RQ3sV8UruiwyfoLApvUur+hd3niU+/MehnLBk50w21miD6j4ipYKT
	kTPQ==
X-Received: by 10.194.188.39 with SMTP id fx7mr49449312wjc.113.1418643927239; 
	Mon, 15 Dec 2014 03:45:27 -0800 (PST)
Received: from [10.80.2.76] ([185.25.64.249])
	by mx.google.com with ESMTPSA id dr3sm5056253wib.4.2014.12.15.03.45.25
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 15 Dec 2014 03:45:26 -0800 (PST)
Message-ID: <548EC9D4.6080706@cantab.net>
Date: Mon, 15 Dec 2014 11:45:24 +0000
From: David Vrabel <dvrabel@cantab.net>
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>, linux-kernel@vger.kernel.org, 
	x86@kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz, 
	linux-kbuild@vger.kernel.org
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-3-git-send-email-jgross@suse.com>
In-Reply-To: <1418321065-10212-3-git-send-email-jgross@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/4] xen: synchronize
 include/xen/interface/xen.h with xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/14 18:04, Juergen Gross wrote:
> The header include/xen/interface/xen.h doesn't contain all definitions
> from Xen's version of that header. Update it accordingly.

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 Mon Dec 15 11:46:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0U6l-0001Mz-LT; Mon, 15 Dec 2014 11:46: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 1Y0U6k-0001Mq-BJ
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:46:34 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	6D/0B-03148-91ACE845; Mon, 15 Dec 2014 11:46:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418643991!15128626!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9603 invoked from network); 15 Dec 2014 11:46:32 -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;
	15 Dec 2014 11:46:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204396251"
Message-ID: <548ECA14.9040805@citrix.com>
Date: Mon, 15 Dec 2014 11:46:28 +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: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<x86@kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, 
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
	<mmarek@suse.cz>, <linux-kbuild@vger.kernel.org>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-4-git-send-email-jgross@suse.com>
In-Reply-To: <1418321065-10212-4-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 3/4] xen: use generated hypervisor symbols
 in arch/x86/xen/trace.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 11/12/14 18:04, Juergen Gross wrote:
> Instead of manually list all hypervisor calls in arch/x86/xen/trace.c
> use the auto generated list.

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 Mon Dec 15 11:46:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0U6l-0001Mz-LT; Mon, 15 Dec 2014 11:46: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 1Y0U6k-0001Mq-BJ
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 11:46:34 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	6D/0B-03148-91ACE845; Mon, 15 Dec 2014 11:46:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418643991!15128626!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9603 invoked from network); 15 Dec 2014 11:46:32 -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;
	15 Dec 2014 11:46:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204396251"
Message-ID: <548ECA14.9040805@citrix.com>
Date: Mon, 15 Dec 2014 11:46:28 +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: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<x86@kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, 
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
	<mmarek@suse.cz>, <linux-kbuild@vger.kernel.org>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-4-git-send-email-jgross@suse.com>
In-Reply-To: <1418321065-10212-4-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 3/4] xen: use generated hypervisor symbols
 in arch/x86/xen/trace.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 11/12/14 18:04, Juergen Gross wrote:
> Instead of manually list all hypervisor calls in arch/x86/xen/trace.c
> use the auto generated list.

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 Mon Dec 15 11:47:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0U7Q-0001RJ-2R; Mon, 15 Dec 2014 11:47: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 1Y0U7O-0001RA-PH
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 11:47:14 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	03/1C-02698-24ACE845; Mon, 15 Dec 2014 11:47:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418644033!15030138!1
X-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 18741 invoked from network); 15 Dec 2014 11:47:13 -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; 15 Dec 2014 11:47:13 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 11:47:12 +0000
Message-Id: <548ED84D020000780004F8FB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 11:47:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <david.vrabel@citrix.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-2-git-send-email-jgross@suse.com>
	<548EC841.2000107@citrix.com>
In-Reply-To: <548EC841.2000107@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Juergen Gross <JGross@suse.com>, mmarek@suse.cz, x86@kernel.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
	xen-devel <xen-devel@lists.xenproject.org>, tglx@linutronix.de,
	boris.ostrovsky@oracle.com, linux-kbuild@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 12:38, <david.vrabel@citrix.com> wrote:
> On 11/12/14 18:04, Juergen Gross wrote:
>> --- a/arch/x86/syscalls/Makefile
>> +++ b/arch/x86/syscalls/Makefile
> 
> Why are these changes here and not in arch/x86/xen/Makefile?

Because this needs to be done in a step that (afaict) has no hook
in the Xen-specific Makefile.

>> @@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
>>  $(out)/syscalls_64.h: $(syscall64) $(systbl)
>>  	$(call if_changed,systbl)
>>  
>> +$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
>> +	$(call if_changed,hypercalls)
>> +
>> +$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
> 
> The generated header should end up in asm/xen/

Why is generated/asm/ not good enough?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:47:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0U7Q-0001RJ-2R; Mon, 15 Dec 2014 11:47: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 1Y0U7O-0001RA-PH
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 11:47:14 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	03/1C-02698-24ACE845; Mon, 15 Dec 2014 11:47:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418644033!15030138!1
X-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 18741 invoked from network); 15 Dec 2014 11:47:13 -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; 15 Dec 2014 11:47:13 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 11:47:12 +0000
Message-Id: <548ED84D020000780004F8FB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 11:47:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <david.vrabel@citrix.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-2-git-send-email-jgross@suse.com>
	<548EC841.2000107@citrix.com>
In-Reply-To: <548EC841.2000107@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Juergen Gross <JGross@suse.com>, mmarek@suse.cz, x86@kernel.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
	xen-devel <xen-devel@lists.xenproject.org>, tglx@linutronix.de,
	boris.ostrovsky@oracle.com, linux-kbuild@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 12:38, <david.vrabel@citrix.com> wrote:
> On 11/12/14 18:04, Juergen Gross wrote:
>> --- a/arch/x86/syscalls/Makefile
>> +++ b/arch/x86/syscalls/Makefile
> 
> Why are these changes here and not in arch/x86/xen/Makefile?

Because this needs to be done in a step that (afaict) has no hook
in the Xen-specific Makefile.

>> @@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
>>  $(out)/syscalls_64.h: $(syscall64) $(systbl)
>>  	$(call if_changed,systbl)
>>  
>> +$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
>> +	$(call if_changed,hypercalls)
>> +
>> +$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
> 
> The generated header should end up in asm/xen/

Why is generated/asm/ not good enough?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 11:58:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0UIU-00025p-BQ; Mon, 15 Dec 2014 11:58: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 1Y0UIT-00025k-Cu
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 11:58:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4E/42-09842-0FCCE845; Mon, 15 Dec 2014 11:58:40 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418644720!12219440!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15052 invoked from network); 15 Dec 2014 11:58:40 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 11:58:40 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so14359335wgh.3
	for <xen-devel@lists.xenproject.org>;
	Mon, 15 Dec 2014 03:58: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
	:content-transfer-encoding;
	bh=9vOVRGaPGqQSQEEqdh7LERzq4KRq3YyTTIQD46TxpkY=;
	b=hrCNhg6+6kxd7ehJrimUmURhK8h79JbGI2bg3JAdNvjmk+OtZNW3y44qm/DoVIevq4
	QpWBo24RfXNGKN++xyiClL2cS6zkZJYgQ3h+DFnq+jKNXW7wa+e3q7Tc2dIgt3kpzJmk
	mQnuGwLnVrl3UHstD3dcoMQ4AgHc73iaHS7zt4wC3rPOHiseB6mQAyEV/MSNmZYtSMGX
	uvq/10afCexTUh2AHTq4qpslfPzCM5I5xwVrWkh9MzeNsqd+R1xG2kftLFWlo2Jc/W0U
	k/ybH83woTwvN/i4GlCfaMXQlEOoym493Ikrb9CIKCVuvc4hjiNH0f8zO8qZD3Bv1NfJ
	0NmQ==
X-Gm-Message-State: ALoCoQkWfZHmUQP/7+Z8lgfMewDbJ18CQLNcBM2B8eakuiOG7li/OybLfzaOT4myswtaiL2wkMwN
X-Received: by 10.180.13.7 with SMTP id d7mr31169854wic.57.1418644720063;
	Mon, 15 Dec 2014 03:58:40 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	js5sm12878460wid.11.2014.12.15.03.58.37
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 15 Dec 2014 03:58:38 -0800 (PST)
Message-ID: <548ECCEA.5040500@linaro.org>
Date: Mon, 15 Dec 2014 11:58:34 +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: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>, hpa@zytor.com, 
	josh@joshtriplett.org, sam@ravnborg.org
References: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
	<1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
In-Reply-To: <1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, bpoirier@suse.de,
	Borislav Petkov <bp@suse.de>, levinsasha928@gmail.com,
	David Rientjes <rientjes@google.com>,
	xen-devel@lists.xenproject.org, fengguang.wu@intel.com,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86, arm, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Luis,

On 09/12/14 23:35, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> This lets you build a kernel which can support xen dom0
> or xen guests by just using:
> 
>    make xenconfig
> 
> on both x86 and arm64 kernels. This also splits out the
> options which are available currently to be built with x86
> and 'make ARCH=arm64' under a shared config.

I guess this is also working for arm (32bits)?

> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
> new file mode 100644
> index 0000000..d2ec010
> --- /dev/null
> +++ b/kernel/configs/xen.config
> @@ -0,0 +1,30 @@
> +# generic config
> +CONFIG_XEN=y
> +CONFIG_XEN_DOM0=y
> +CONFIG_PCI_XEN=y
> +CONFIG_XEN_PCIDEV_FRONTEND=m
> +CONFIG_XEN_BLKDEV_FRONTEND=m
> +CONFIG_XEN_BLKDEV_BACKEND=m
> +CONFIG_XEN_NETDEV_FRONTEND=m
> +CONFIG_XEN_NETDEV_BACKEND=m
> +CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
> +CONFIG_HVC_XEN=y
> +CONFIG_HVC_XEN_FRONTEND=y
> +CONFIG_TCG_XEN=m
> +CONFIG_XEN_WDT=m
> +CONFIG_XEN_FBDEV_FRONTEND=y
> +CONFIG_XEN_BALLOON=y
> +CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
> +CONFIG_XEN_SCRUB_PAGES=y
> +CONFIG_XEN_DEV_EVTCHN=m
> +CONFIG_XEN_BACKEND=y
> +CONFIG_XENFS=m
> +CONFIG_XEN_COMPAT_XENFS=y
> +CONFIG_XEN_SYS_HYPERVISOR=y
> +CONFIG_XEN_XENBUS_FRONTEND=y
> +CONFIG_XEN_GNTDEV=m
> +CONFIG_XEN_GRANT_DEV_ALLOC=m
> +CONFIG_SWIOTLB_XEN=y
> +CONFIG_XEN_PCIDEV_BACKEND=m
> +CONFIG_XEN_PRIVCMD=m
> +CONFIG_XEN_ACPI_PROCESSOR=m

The common fragment config looks good for both ARM32 and ARM64:

Acked-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 Mon Dec 15 11:58:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 11:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0UIU-00025p-BQ; Mon, 15 Dec 2014 11:58: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 1Y0UIT-00025k-Cu
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 11:58:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4E/42-09842-0FCCE845; Mon, 15 Dec 2014 11:58:40 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418644720!12219440!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15052 invoked from network); 15 Dec 2014 11:58:40 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 11:58:40 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so14359335wgh.3
	for <xen-devel@lists.xenproject.org>;
	Mon, 15 Dec 2014 03:58: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
	:content-transfer-encoding;
	bh=9vOVRGaPGqQSQEEqdh7LERzq4KRq3YyTTIQD46TxpkY=;
	b=hrCNhg6+6kxd7ehJrimUmURhK8h79JbGI2bg3JAdNvjmk+OtZNW3y44qm/DoVIevq4
	QpWBo24RfXNGKN++xyiClL2cS6zkZJYgQ3h+DFnq+jKNXW7wa+e3q7Tc2dIgt3kpzJmk
	mQnuGwLnVrl3UHstD3dcoMQ4AgHc73iaHS7zt4wC3rPOHiseB6mQAyEV/MSNmZYtSMGX
	uvq/10afCexTUh2AHTq4qpslfPzCM5I5xwVrWkh9MzeNsqd+R1xG2kftLFWlo2Jc/W0U
	k/ybH83woTwvN/i4GlCfaMXQlEOoym493Ikrb9CIKCVuvc4hjiNH0f8zO8qZD3Bv1NfJ
	0NmQ==
X-Gm-Message-State: ALoCoQkWfZHmUQP/7+Z8lgfMewDbJ18CQLNcBM2B8eakuiOG7li/OybLfzaOT4myswtaiL2wkMwN
X-Received: by 10.180.13.7 with SMTP id d7mr31169854wic.57.1418644720063;
	Mon, 15 Dec 2014 03:58:40 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	js5sm12878460wid.11.2014.12.15.03.58.37
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 15 Dec 2014 03:58:38 -0800 (PST)
Message-ID: <548ECCEA.5040500@linaro.org>
Date: Mon, 15 Dec 2014 11:58:34 +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: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>, hpa@zytor.com, 
	josh@joshtriplett.org, sam@ravnborg.org
References: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
	<1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
In-Reply-To: <1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
Cc: Michal Marek <mmarek@suse.cz>, Randy Dunlap <rdunlap@infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	Pekka Enberg <penberg@kernel.org>, bpoirier@suse.de,
	Borislav Petkov <bp@suse.de>, levinsasha928@gmail.com,
	David Rientjes <rientjes@google.com>,
	xen-devel@lists.xenproject.org, fengguang.wu@intel.com,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86, arm, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Luis,

On 09/12/14 23:35, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> This lets you build a kernel which can support xen dom0
> or xen guests by just using:
> 
>    make xenconfig
> 
> on both x86 and arm64 kernels. This also splits out the
> options which are available currently to be built with x86
> and 'make ARCH=arm64' under a shared config.

I guess this is also working for arm (32bits)?

> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
> new file mode 100644
> index 0000000..d2ec010
> --- /dev/null
> +++ b/kernel/configs/xen.config
> @@ -0,0 +1,30 @@
> +# generic config
> +CONFIG_XEN=y
> +CONFIG_XEN_DOM0=y
> +CONFIG_PCI_XEN=y
> +CONFIG_XEN_PCIDEV_FRONTEND=m
> +CONFIG_XEN_BLKDEV_FRONTEND=m
> +CONFIG_XEN_BLKDEV_BACKEND=m
> +CONFIG_XEN_NETDEV_FRONTEND=m
> +CONFIG_XEN_NETDEV_BACKEND=m
> +CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
> +CONFIG_HVC_XEN=y
> +CONFIG_HVC_XEN_FRONTEND=y
> +CONFIG_TCG_XEN=m
> +CONFIG_XEN_WDT=m
> +CONFIG_XEN_FBDEV_FRONTEND=y
> +CONFIG_XEN_BALLOON=y
> +CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
> +CONFIG_XEN_SCRUB_PAGES=y
> +CONFIG_XEN_DEV_EVTCHN=m
> +CONFIG_XEN_BACKEND=y
> +CONFIG_XENFS=m
> +CONFIG_XEN_COMPAT_XENFS=y
> +CONFIG_XEN_SYS_HYPERVISOR=y
> +CONFIG_XEN_XENBUS_FRONTEND=y
> +CONFIG_XEN_GNTDEV=m
> +CONFIG_XEN_GRANT_DEV_ALLOC=m
> +CONFIG_SWIOTLB_XEN=y
> +CONFIG_XEN_PCIDEV_BACKEND=m
> +CONFIG_XEN_PRIVCMD=m
> +CONFIG_XEN_ACPI_PROCESSOR=m

The common fragment config looks good for both ARM32 and ARM64:

Acked-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 Mon Dec 15 12:06:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 12:06:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0UPj-0002Uf-T9; Mon, 15 Dec 2014 12:06:11 +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 1Y0UPi-0002UX-88
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 12:06:10 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F5/AD-15461-1BECE845; Mon, 15 Dec 2014 12:06:09 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418645167!15635530!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 10698 invoked from network); 15 Dec 2014 12:06:09 -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;
	15 Dec 2014 12:06:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204402245"
Message-ID: <548ECE9B.3040105@citrix.com>
Date: Mon, 15 Dec 2014 12:05:47 +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: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<x86@kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, 
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
	<mmarek@suse.cz>, <linux-kbuild@vger.kernel.org>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-5-git-send-email-jgross@suse.com>
In-Reply-To: <1418321065-10212-5-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 4/4] xen: use generated hypercall symbols in
 arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/14 18:04, Juergen Gross wrote:
> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
> use the auto generated symbol list.
> 
> This also corrects the wrong address of xen_hypercall_mca which was
> located 32 bytes higher than it should.
> 
> Symbol addresses have been verified to match the correct ones via
> objdump output.
[...]
> +
> +#define HYPERCALL(n) \
> +	.equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \
> +	.type xen_hypercall_##n, function; .size xen_hypercall_##n, 32
> +#include <asm/xen-hypercalls.h>
> +#undef HYPERCALL

The gas manual[1] suggests the syntax you've used for .type is invalid
and suggest using .type <name>, STT_FUNC

> +
>  	.balign PAGE_SIZE

You can remove this .balign.

David

[1] https://sourceware.org/binutils/docs/as/Type.html#Type

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 12:06:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 12:06:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0UPj-0002Uf-T9; Mon, 15 Dec 2014 12:06:11 +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 1Y0UPi-0002UX-88
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 12:06:10 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F5/AD-15461-1BECE845; Mon, 15 Dec 2014 12:06:09 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418645167!15635530!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 10698 invoked from network); 15 Dec 2014 12:06:09 -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;
	15 Dec 2014 12:06:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204402245"
Message-ID: <548ECE9B.3040105@citrix.com>
Date: Mon, 15 Dec 2014 12:05:47 +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: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<x86@kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, 
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
	<mmarek@suse.cz>, <linux-kbuild@vger.kernel.org>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-5-git-send-email-jgross@suse.com>
In-Reply-To: <1418321065-10212-5-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH 4/4] xen: use generated hypercall symbols in
 arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/14 18:04, Juergen Gross wrote:
> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
> use the auto generated symbol list.
> 
> This also corrects the wrong address of xen_hypercall_mca which was
> located 32 bytes higher than it should.
> 
> Symbol addresses have been verified to match the correct ones via
> objdump output.
[...]
> +
> +#define HYPERCALL(n) \
> +	.equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \
> +	.type xen_hypercall_##n, function; .size xen_hypercall_##n, 32
> +#include <asm/xen-hypercalls.h>
> +#undef HYPERCALL

The gas manual[1] suggests the syntax you've used for .type is invalid
and suggest using .type <name>, STT_FUNC

> +
>  	.balign PAGE_SIZE

You can remove this .balign.

David

[1] https://sourceware.org/binutils/docs/as/Type.html#Type

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 12:09:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 12: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 1Y0UTB-0002cp-Ht; Mon, 15 Dec 2014 12:09:45 +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 1Y0UT9-0002ch-V3
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 12:09:44 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	2A/65-26858-78FCE845; Mon, 15 Dec 2014 12:09:43 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418645382!13442623!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5412 invoked from network); 15 Dec 2014 12:09:42 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 12:09:42 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so8777053wiw.10
	for <xen-devel@lists.xen.org>; Mon, 15 Dec 2014 04:09: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=vapB65ODqSgtlDldQ/Bb6jiu8c6ncfK10X8fb0XLybc=;
	b=T2hleMa77LZ0m+AizLEJjyXVr0pPM2E7l2rKFC0abifrYhE6LzaTDmJQFCHtYUyCm+
	S8+/fj+nOdCTmNDllhVBtEE72T9MKkgqTBhCotxdDW//DDByUvftPBrvOnKkyelilRtr
	C0fX2oL3LX77dwXKJ8YVcP0gq9CumbdNf1RogcCp9LMNKFuCDRFgzh/bdwuj+uZ62RAu
	B4upHaUsddibWSF/gobiromXGrZt6IMHu7lz+IbIiUSFk9XPTN4/dy3orqtZYZFITavT
	1zKnp8CMA89h09jHUiZh+NT0KVrzIIBRCU15hvROA8H0BWZCrbdIiuYwk1PzbgbFGd2s
	CPOA==
X-Gm-Message-State: ALoCoQmiUFBQ9n9+wPjzzwlvWBPn0h9qYp1uifHMdUCNkrCaQnjhHbdx80qymXmQdpHepmObUw5i
X-Received: by 10.180.105.131 with SMTP id gm3mr31421457wib.34.1418645382517; 
	Mon, 15 Dec 2014 04:09:42 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	hz9sm12809042wjb.17.2014.12.15.04.09.40 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 15 Dec 2014 04:09:41 -0800 (PST)
Message-ID: <548ECF81.5030507@linaro.org>
Date: Mon, 15 Dec 2014 12:09:37 +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>, vijay.kilari@gmail.com
References: <1418099995-22777-1-git-send-email-vijay.kilari@gmail.com>
	<1418300672.10394.35.camel@citrix.com>
In-Reply-To: <1418300672.10394.35.camel@citrix.com>
Cc: Keir Fraser <keir@xen.org>, stefano.stabellini@eu.citrix.com,
	Prasun.Kapoor@caviumnetworks.com,
	manish.jaggi@caviumnetworks.com, tim@xen.org,
	xen-devel@lists.xen.org, stefano.stabellini@citrix.com,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Subject: Re: [Xen-devel] [PATCH v1] xen/arm: Manage pl011 uart TX interrupt
	correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/14 12:24, Ian Campbell wrote:
> These last two changes require that you cc the common serial maintainer,
> not just the ARM maintainers. In this case that means Keir, who I have
> CCd.

> ./scripts/get_maintainers.pl can help automate this.

The serial code lives in the "THE REST" category. So I don't think it's
mandatory to have Keir's ack 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 Mon Dec 15 12:09:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 12: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 1Y0UTB-0002cp-Ht; Mon, 15 Dec 2014 12:09:45 +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 1Y0UT9-0002ch-V3
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 12:09:44 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	2A/65-26858-78FCE845; Mon, 15 Dec 2014 12:09:43 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418645382!13442623!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5412 invoked from network); 15 Dec 2014 12:09:42 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 12:09:42 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so8777053wiw.10
	for <xen-devel@lists.xen.org>; Mon, 15 Dec 2014 04:09: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=vapB65ODqSgtlDldQ/Bb6jiu8c6ncfK10X8fb0XLybc=;
	b=T2hleMa77LZ0m+AizLEJjyXVr0pPM2E7l2rKFC0abifrYhE6LzaTDmJQFCHtYUyCm+
	S8+/fj+nOdCTmNDllhVBtEE72T9MKkgqTBhCotxdDW//DDByUvftPBrvOnKkyelilRtr
	C0fX2oL3LX77dwXKJ8YVcP0gq9CumbdNf1RogcCp9LMNKFuCDRFgzh/bdwuj+uZ62RAu
	B4upHaUsddibWSF/gobiromXGrZt6IMHu7lz+IbIiUSFk9XPTN4/dy3orqtZYZFITavT
	1zKnp8CMA89h09jHUiZh+NT0KVrzIIBRCU15hvROA8H0BWZCrbdIiuYwk1PzbgbFGd2s
	CPOA==
X-Gm-Message-State: ALoCoQmiUFBQ9n9+wPjzzwlvWBPn0h9qYp1uifHMdUCNkrCaQnjhHbdx80qymXmQdpHepmObUw5i
X-Received: by 10.180.105.131 with SMTP id gm3mr31421457wib.34.1418645382517; 
	Mon, 15 Dec 2014 04:09:42 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	hz9sm12809042wjb.17.2014.12.15.04.09.40 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 15 Dec 2014 04:09:41 -0800 (PST)
Message-ID: <548ECF81.5030507@linaro.org>
Date: Mon, 15 Dec 2014 12:09:37 +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>, vijay.kilari@gmail.com
References: <1418099995-22777-1-git-send-email-vijay.kilari@gmail.com>
	<1418300672.10394.35.camel@citrix.com>
In-Reply-To: <1418300672.10394.35.camel@citrix.com>
Cc: Keir Fraser <keir@xen.org>, stefano.stabellini@eu.citrix.com,
	Prasun.Kapoor@caviumnetworks.com,
	manish.jaggi@caviumnetworks.com, tim@xen.org,
	xen-devel@lists.xen.org, stefano.stabellini@citrix.com,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Subject: Re: [Xen-devel] [PATCH v1] xen/arm: Manage pl011 uart TX interrupt
	correctly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/12/14 12:24, Ian Campbell wrote:
> These last two changes require that you cc the common serial maintainer,
> not just the ARM maintainers. In this case that means Keir, who I have
> CCd.

> ./scripts/get_maintainers.pl can help automate this.

The serial code lives in the "THE REST" category. So I don't think it's
mandatory to have Keir's ack 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 Mon Dec 15 13:18:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 13: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 1Y0VWz-0004FB-Ss; Mon, 15 Dec 2014 13:17:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0VWx-0004F4-QL
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 13:17:43 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C1/02-29352-77FDE845; Mon, 15 Dec 2014 13:17:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418649460!5812776!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 30950 invoked from network); 15 Dec 2014 13:17:42 -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;
	15 Dec 2014 13:17:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204426337"
Message-ID: <1418649458.16425.108.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Mon, 15 Dec 2014 13:17:38 +0000
In-Reply-To: <1418407116.16425.53.camel@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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] 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 Fri, 2014-12-12 at 17:58 +0000, Ian Campbell wrote:
> (adding Ian J who knows a bit more about C xenstored than me...)
> 
>  On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
> > Hello Ian,
> > 
> > On 12.12.2014 17:56, Ian Campbell wrote:
> > > On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
> > >> On 12.12.2014 17:32, Ian Campbell wrote:
> > >>> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
> > >>>> We did enable tracing and now have the xenstored-trace.log of one crash:
> > >>>> It contains 1.6 billion lines and is 83 GiB.
> > >>>> It just shows xenstored to crash on TRANSACTION_START.
> > >>>>
> > >>>> Is there some tool to feed that trace back into a newly launched xenstored?
> > >>>
> > >>> Not that I know of I'm afraid.
> > >>
> > >> Okay, then I have to continue with my own tool.
> > > 
> > > If you do end up developing a tool to replay a xenstore trace then I
> > > think that'd be something great to have in tree!
> > 
> > I just need to figure out how to talk to xenstored on the wire: for some
> > strange reason xenstored is closing the connection to the UNIX socket on
> > the first write inside a transaction.
> > Or switch to /usr/share/pyshared/xen/xend/xenstore/xstransact.py...
> > 
> > >>> Do you get a core dump when this happens? You might need to fiddle with
> > >>> ulimits (some distros disable by default). IIRC there is also some /proc
> > >>> nob which controls where core dumps go on the filesystem.
> > >>
> > >> Not for that specific trace: We first enabled generating core files, but
> > >> only then discovered that this is not enough.
> > > 
> > > How wasn't it enough? You mean you couldn't use gdb to extract a
> > > backtrace from the core file? Or was something else wrong?
> > 
> > The 1st and 2nd trace look like this: ptr in frame #2 looks very bogus.
> > 
> > (gdb) bt full
> > #0  talloc_chunk_from_ptr (ptr=0xff00000000) at talloc.c:116
> >         tc = <value optimized out>
> > #1  0x0000000000407edf in talloc_free (ptr=0xff00000000) at talloc.c:551
> >         tc = <value optimized out>
> > #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0
> > "/var/lib/xenstored/tdb.0x1935bb0",
> 
> I've timed out for tonight will try and have another look next week.

I've had another dig, and have instrumented all of the error paths from
this function and I can't see any way for an invalid pointer to be
produced, let alone freed. I've been running under valgrind which should
have caught any uninitialised memory type errors.

> >     hash_size=<value optimized out>, tdb_flags=0, open_flags=<value
> > optimized out>, mode=<value optimized out>,
> >     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at
> > tdb.c:1958

Please can you confirm what is at line 1958 of your copy of tdb.c. I
think it will be tdb->locked, but I'd like to be sure.

You are running a 64-bit dom0, correct? I've only just noticed that
0xff00000000 is >32bits. My testing so far was 32-bit, I don't think it
should matter wrt use of uninitialised data etc.

I can't help feeling that 0xff00000000 must be some sort of magic
sentinel value to someone. I can't figure out what though.

Have you observed the xenstored processes growing especially large
before this happens? I'm wondering if there might be a leak somewhere
which after a time is resulting a 

I'm about to send out a patch which plumbs tdb's logging into
xenstored's logging, in the hopes that next time you see this it might
say something as it dies.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 13:18:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 13: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 1Y0VWz-0004FB-Ss; Mon, 15 Dec 2014 13:17:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0VWx-0004F4-QL
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 13:17:43 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	C1/02-29352-77FDE845; Mon, 15 Dec 2014 13:17:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418649460!5812776!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 30950 invoked from network); 15 Dec 2014 13:17:42 -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;
	15 Dec 2014 13:17:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204426337"
Message-ID: <1418649458.16425.108.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Mon, 15 Dec 2014 13:17:38 +0000
In-Reply-To: <1418407116.16425.53.camel@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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] 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 Fri, 2014-12-12 at 17:58 +0000, Ian Campbell wrote:
> (adding Ian J who knows a bit more about C xenstored than me...)
> 
>  On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
> > Hello Ian,
> > 
> > On 12.12.2014 17:56, Ian Campbell wrote:
> > > On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
> > >> On 12.12.2014 17:32, Ian Campbell wrote:
> > >>> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
> > >>>> We did enable tracing and now have the xenstored-trace.log of one crash:
> > >>>> It contains 1.6 billion lines and is 83 GiB.
> > >>>> It just shows xenstored to crash on TRANSACTION_START.
> > >>>>
> > >>>> Is there some tool to feed that trace back into a newly launched xenstored?
> > >>>
> > >>> Not that I know of I'm afraid.
> > >>
> > >> Okay, then I have to continue with my own tool.
> > > 
> > > If you do end up developing a tool to replay a xenstore trace then I
> > > think that'd be something great to have in tree!
> > 
> > I just need to figure out how to talk to xenstored on the wire: for some
> > strange reason xenstored is closing the connection to the UNIX socket on
> > the first write inside a transaction.
> > Or switch to /usr/share/pyshared/xen/xend/xenstore/xstransact.py...
> > 
> > >>> Do you get a core dump when this happens? You might need to fiddle with
> > >>> ulimits (some distros disable by default). IIRC there is also some /proc
> > >>> nob which controls where core dumps go on the filesystem.
> > >>
> > >> Not for that specific trace: We first enabled generating core files, but
> > >> only then discovered that this is not enough.
> > > 
> > > How wasn't it enough? You mean you couldn't use gdb to extract a
> > > backtrace from the core file? Or was something else wrong?
> > 
> > The 1st and 2nd trace look like this: ptr in frame #2 looks very bogus.
> > 
> > (gdb) bt full
> > #0  talloc_chunk_from_ptr (ptr=0xff00000000) at talloc.c:116
> >         tc = <value optimized out>
> > #1  0x0000000000407edf in talloc_free (ptr=0xff00000000) at talloc.c:551
> >         tc = <value optimized out>
> > #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0
> > "/var/lib/xenstored/tdb.0x1935bb0",
> 
> I've timed out for tonight will try and have another look next week.

I've had another dig, and have instrumented all of the error paths from
this function and I can't see any way for an invalid pointer to be
produced, let alone freed. I've been running under valgrind which should
have caught any uninitialised memory type errors.

> >     hash_size=<value optimized out>, tdb_flags=0, open_flags=<value
> > optimized out>, mode=<value optimized out>,
> >     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at
> > tdb.c:1958

Please can you confirm what is at line 1958 of your copy of tdb.c. I
think it will be tdb->locked, but I'd like to be sure.

You are running a 64-bit dom0, correct? I've only just noticed that
0xff00000000 is >32bits. My testing so far was 32-bit, I don't think it
should matter wrt use of uninitialised data etc.

I can't help feeling that 0xff00000000 must be some sort of magic
sentinel value to someone. I can't figure out what though.

Have you observed the xenstored processes growing especially large
before this happens? I'm wondering if there might be a leak somewhere
which after a time is resulting a 

I'm about to send out a patch which plumbs tdb's logging into
xenstored's logging, in the hopes that next time you see this it might
say something as it dies.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 13:19:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 13:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0VYE-0004It-AQ; Mon, 15 Dec 2014 13: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.Campbell@citrix.com>) id 1Y0VYD-0004Im-Vo
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 13:19:02 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	45/26-02954-4CFDE845; Mon, 15 Dec 2014 13:19:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418649537!15110589!1
X-Originating-IP: [66.165.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 7777 invoked from network); 15 Dec 2014 13:18:59 -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;
	15 Dec 2014 13:18:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204886082"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 08:18:25 -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
	1Y0VXb-0008Q1-Ew; Mon, 15 Dec 2014 13:18:24 +0000
Received: by localhost.localdomain (sSMTP sendmail emulation); Mon, 15 Dec
	2014 13:18:23 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 15 Dec 2014 13:18:23 +0000
Message-ID: <1418649503-31440-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: Philipp Hahn <hahn@univention.de>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH for-4.6] xenstored: log tdb message via
	xenstored's logging mechanisms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TDB provides us with a callback for this purpose. Use it in both
xenstored and xs_tdb_dump.

While at it make the existing log() macro tollerate memory failures.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_core.c |   39 +++++++++++++++++++++++++++++++++------
 tools/xenstore/xs_tdb_dump.c    |   12 +++++++++++-
 2 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 4eaff57..3fd9a20 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -89,9 +89,14 @@ static void check_store(void);
 #define log(...)							\
 	do {								\
 		char *s = talloc_asprintf(NULL, __VA_ARGS__);		\
-		trace("%s\n", s);					\
-		syslog(LOG_ERR, "%s",  s);				\
-		talloc_free(s);						\
+		if (s) {						\
+			trace("%s\n", s);				\
+			syslog(LOG_ERR, "%s",  s);			\
+			talloc_free(s);					\
+		} else {						\
+			trace("talloc failure during logging\n");	\
+			syslog(LOG_ERR, "talloc failure during logging\n"); \
+		}							\
 	} while (0)
 
 
@@ -1479,13 +1484,35 @@ static void manual_node(const char *name, const char *child)
 	talloc_free(node);
 }
 
+static void tdb_logger(TDB_CONTEXT *tdb, int level, const char * fmt, ...)
+{
+	va_list ap;
+	char *s;
+
+	va_start(ap, fmt);
+	s = talloc_vasprintf(NULL, fmt, ap);
+	va_end(ap);
+
+	if (s) {
+		trace("TDB: %s\n", s);
+		syslog(LOG_ERR, "TDB: %s",  s);
+		if (verbose)
+			xprintf("TDB: %s", s);
+		talloc_free(s);
+	} else {
+		trace("talloc failure during logging\n");
+		syslog(LOG_ERR, "talloc failure during logging\n");
+	}
+}
+
 static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
 
 	if (!(tdb_flags & TDB_INTERNAL))
-		tdb_ctx = tdb_open(tdbname, 0, tdb_flags, O_RDWR, 0);
+		tdb_ctx = tdb_open_ex(tdbname, 0, tdb_flags, O_RDWR, 0,
+				      &tdb_logger, NULL);
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1516,8 +1543,8 @@ static void setup_structure(void)
 		talloc_free(tlocal);
 	}
 	else {
-		tdb_ctx = tdb_open(tdbname, 7919, tdb_flags, O_RDWR|O_CREAT,
-				   0640);
+		tdb_ctx = tdb_open_ex(tdbname, 7919, tdb_flags, O_RDWR|O_CREAT,
+				      0640, &tdb_logger, NULL);
 		if (!tdb_ctx)
 			barf_perror("Could not create tdb file %s", tdbname);
 
diff --git a/tools/xenstore/xs_tdb_dump.c b/tools/xenstore/xs_tdb_dump.c
index b91cdef..7a034c0 100644
--- a/tools/xenstore/xs_tdb_dump.c
+++ b/tools/xenstore/xs_tdb_dump.c
@@ -33,6 +33,15 @@ static char perm_to_char(enum xs_perm_type perm)
 		'?';
 }
 
+static void tdb_logger(TDB_CONTEXT *tdb, int level, const char * fmt, ...)
+{
+	va_list ap;
+
+	va_start(ap, fmt);
+	vfprintf(stderr, fmt, ap);
+	va_end(ap);
+}
+
 int main(int argc, char *argv[])
 {
 	TDB_DATA key;
@@ -41,7 +50,8 @@ int main(int argc, char *argv[])
 	if (argc != 2)
 		barf("Usage: xs_tdb_dump <tdbfile>");
 
-	tdb = tdb_open(talloc_strdup(NULL, argv[1]), 0, 0, O_RDONLY, 0);
+	tdb = tdb_open_ex(talloc_strdup(NULL, argv[1]), 0, 0, O_RDONLY, 0,
+			  tdb_logger, NULL);
 	if (!tdb)
 		barf_perror("Could not open %s", argv[1]);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 13:19:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 13:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0VYE-0004It-AQ; Mon, 15 Dec 2014 13: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.Campbell@citrix.com>) id 1Y0VYD-0004Im-Vo
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 13:19:02 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	45/26-02954-4CFDE845; Mon, 15 Dec 2014 13:19:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418649537!15110589!1
X-Originating-IP: [66.165.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 7777 invoked from network); 15 Dec 2014 13:18:59 -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;
	15 Dec 2014 13:18:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="204886082"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 08:18:25 -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
	1Y0VXb-0008Q1-Ew; Mon, 15 Dec 2014 13:18:24 +0000
Received: by localhost.localdomain (sSMTP sendmail emulation); Mon, 15 Dec
	2014 13:18:23 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <ian.jackson@eu.citrix.com>
Date: Mon, 15 Dec 2014 13:18:23 +0000
Message-ID: <1418649503-31440-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: Philipp Hahn <hahn@univention.de>, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH for-4.6] xenstored: log tdb message via
	xenstored's logging mechanisms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TDB provides us with a callback for this purpose. Use it in both
xenstored and xs_tdb_dump.

While at it make the existing log() macro tollerate memory failures.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_core.c |   39 +++++++++++++++++++++++++++++++++------
 tools/xenstore/xs_tdb_dump.c    |   12 +++++++++++-
 2 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 4eaff57..3fd9a20 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -89,9 +89,14 @@ static void check_store(void);
 #define log(...)							\
 	do {								\
 		char *s = talloc_asprintf(NULL, __VA_ARGS__);		\
-		trace("%s\n", s);					\
-		syslog(LOG_ERR, "%s",  s);				\
-		talloc_free(s);						\
+		if (s) {						\
+			trace("%s\n", s);				\
+			syslog(LOG_ERR, "%s",  s);			\
+			talloc_free(s);					\
+		} else {						\
+			trace("talloc failure during logging\n");	\
+			syslog(LOG_ERR, "talloc failure during logging\n"); \
+		}							\
 	} while (0)
 
 
@@ -1479,13 +1484,35 @@ static void manual_node(const char *name, const char *child)
 	talloc_free(node);
 }
 
+static void tdb_logger(TDB_CONTEXT *tdb, int level, const char * fmt, ...)
+{
+	va_list ap;
+	char *s;
+
+	va_start(ap, fmt);
+	s = talloc_vasprintf(NULL, fmt, ap);
+	va_end(ap);
+
+	if (s) {
+		trace("TDB: %s\n", s);
+		syslog(LOG_ERR, "TDB: %s",  s);
+		if (verbose)
+			xprintf("TDB: %s", s);
+		talloc_free(s);
+	} else {
+		trace("talloc failure during logging\n");
+		syslog(LOG_ERR, "talloc failure during logging\n");
+	}
+}
+
 static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
 
 	if (!(tdb_flags & TDB_INTERNAL))
-		tdb_ctx = tdb_open(tdbname, 0, tdb_flags, O_RDWR, 0);
+		tdb_ctx = tdb_open_ex(tdbname, 0, tdb_flags, O_RDWR, 0,
+				      &tdb_logger, NULL);
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1516,8 +1543,8 @@ static void setup_structure(void)
 		talloc_free(tlocal);
 	}
 	else {
-		tdb_ctx = tdb_open(tdbname, 7919, tdb_flags, O_RDWR|O_CREAT,
-				   0640);
+		tdb_ctx = tdb_open_ex(tdbname, 7919, tdb_flags, O_RDWR|O_CREAT,
+				      0640, &tdb_logger, NULL);
 		if (!tdb_ctx)
 			barf_perror("Could not create tdb file %s", tdbname);
 
diff --git a/tools/xenstore/xs_tdb_dump.c b/tools/xenstore/xs_tdb_dump.c
index b91cdef..7a034c0 100644
--- a/tools/xenstore/xs_tdb_dump.c
+++ b/tools/xenstore/xs_tdb_dump.c
@@ -33,6 +33,15 @@ static char perm_to_char(enum xs_perm_type perm)
 		'?';
 }
 
+static void tdb_logger(TDB_CONTEXT *tdb, int level, const char * fmt, ...)
+{
+	va_list ap;
+
+	va_start(ap, fmt);
+	vfprintf(stderr, fmt, ap);
+	va_end(ap);
+}
+
 int main(int argc, char *argv[])
 {
 	TDB_DATA key;
@@ -41,7 +50,8 @@ int main(int argc, char *argv[])
 	if (argc != 2)
 		barf("Usage: xs_tdb_dump <tdbfile>");
 
-	tdb = tdb_open(talloc_strdup(NULL, argv[1]), 0, 0, O_RDONLY, 0);
+	tdb = tdb_open_ex(talloc_strdup(NULL, argv[1]), 0, 0, O_RDONLY, 0,
+			  tdb_logger, NULL);
 	if (!tdb)
 		barf_perror("Could not open %s", argv[1]);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 13:32:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 13:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Vky-00050P-OC; Mon, 15 Dec 2014 13:32:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jferlan@redhat.com>) id 1Y0Vkx-00050K-N8
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 13:32:11 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C0/B6-02957-9D2EE845; Mon, 15 Dec 2014 13:32:09 +0000
X-Env-Sender: jferlan@redhat.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418650327!15116879!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31589 invoked from network); 15 Dec 2014 13:32:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 13:32:09 -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 sBFDW4m8003103
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 15 Dec 2014 08:32:04 -0500
Received: from localhost.localdomain (ovpn-113-67.phx2.redhat.com
	[10.3.113.67])
	by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBFDW3qQ003104; Mon, 15 Dec 2014 08:32:04 -0500
Message-ID: <548EE2D3.8020100@redhat.com>
Date: Mon, 15 Dec 2014 08:32:03 -0500
From: John Ferlan <jferlan@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: Wei Liu <wei.liu2@citrix.com>, libvir-list@redhat.com
References: <1418569097-19322-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1418569097-19322-1-git-send-email-wei.liu2@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [libvirt] [PATCH] xenconfig: fix boot device parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/14/2014 09:58 AM, Wei Liu wrote:
> The original code always checked *boot which was in effect boot[0]. It
> should use boot[i].

In the future, when you do the investigation, just reference the commit
id that caused the regression.  In this case it seems to be commit id
'547bd71a' (7/25/08 - quite a while ago)!

I'll work on getting this pushed shortly -

John
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  src/xenconfig/xen_common.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c
> index 7f4ec89..48431a7 100644
> --- a/src/xenconfig/xen_common.c
> +++ b/src/xenconfig/xen_common.c
> @@ -1071,7 +1071,7 @@ xenParseOS(virConfPtr conf, virDomainDefPtr def)
>              return -1;
>  
>          for (i = 0; i < VIR_DOMAIN_BOOT_LAST && boot[i]; i++) {
> -            switch (*boot) {
> +            switch (boot[i]) {
>              case 'a':
>                  def->os.bootDevs[i] = VIR_DOMAIN_BOOT_FLOPPY;
>                  break;
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 13:32:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 13:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Vky-00050P-OC; Mon, 15 Dec 2014 13:32:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jferlan@redhat.com>) id 1Y0Vkx-00050K-N8
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 13:32:11 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C0/B6-02957-9D2EE845; Mon, 15 Dec 2014 13:32:09 +0000
X-Env-Sender: jferlan@redhat.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418650327!15116879!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31589 invoked from network); 15 Dec 2014 13:32:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 13:32:09 -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 sBFDW4m8003103
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 15 Dec 2014 08:32:04 -0500
Received: from localhost.localdomain (ovpn-113-67.phx2.redhat.com
	[10.3.113.67])
	by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBFDW3qQ003104; Mon, 15 Dec 2014 08:32:04 -0500
Message-ID: <548EE2D3.8020100@redhat.com>
Date: Mon, 15 Dec 2014 08:32:03 -0500
From: John Ferlan <jferlan@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: Wei Liu <wei.liu2@citrix.com>, libvir-list@redhat.com
References: <1418569097-19322-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1418569097-19322-1-git-send-email-wei.liu2@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [libvirt] [PATCH] xenconfig: fix boot device parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/14/2014 09:58 AM, Wei Liu wrote:
> The original code always checked *boot which was in effect boot[0]. It
> should use boot[i].

In the future, when you do the investigation, just reference the commit
id that caused the regression.  In this case it seems to be commit id
'547bd71a' (7/25/08 - quite a while ago)!

I'll work on getting this pushed shortly -

John
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  src/xenconfig/xen_common.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c
> index 7f4ec89..48431a7 100644
> --- a/src/xenconfig/xen_common.c
> +++ b/src/xenconfig/xen_common.c
> @@ -1071,7 +1071,7 @@ xenParseOS(virConfPtr conf, virDomainDefPtr def)
>              return -1;
>  
>          for (i = 0; i < VIR_DOMAIN_BOOT_LAST && boot[i]; i++) {
> -            switch (*boot) {
> +            switch (boot[i]) {
>              case 'a':
>                  def->os.bootDevs[i] = VIR_DOMAIN_BOOT_FLOPPY;
>                  break;
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 13:40:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 13:40:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0VsS-000596-Le; Mon, 15 Dec 2014 13:39:56 +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 1Y0VsQ-000591-QP
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 13:39:54 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	3E/74-22819-AA4EE845; Mon, 15 Dec 2014 13:39:54 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418650792!13405604!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16218 invoked from network); 15 Dec 2014 13:39:53 -0000
Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com)
	(209.85.220.169)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 13:39:53 -0000
Received: by mail-vc0-f169.google.com with SMTP id hy10so5579308vcb.0
	for <xen-devel@lists.xen.org>; Mon, 15 Dec 2014 05:39: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=Isisg6DJGv3qXvwfXtEgvdhjeMaDZJkgOGCj8x+yNQQ=;
	b=b+0n0nlDcMzPNqRrTdcsar3K8uAgxjhlNcoqKPP84swV3Z6NNsDarmwAC4slXnt18G
	1TzoxF6uT5pJgka8WqiCNo/oOry34+a707TQnnBJ2awenQ/uxQx1BdI1HZ+q0XaFMSkp
	Ty2lrWVhXeAMIgrYRIWtJ5VMKVkUSdUdap/T4uMkX7V/0sPDgoD1l+2vpARhckbR1T+f
	7Lc0NBJTDjNas0gu2tz7K8IdeD46cpROhBx4rmiOBLvSaoDGI+Dtc0dqkXAmOAjkgPmY
	xbd67eoGIHbVhVoKjUOGtvUhJZjzGE4CBt4REISoUTON6NsQRrIe4vkl+Ql1P7je95yh
	b+rw==
MIME-Version: 1.0
X-Received: by 10.52.165.10 with SMTP id yu10mr16407599vdb.3.1418650792424;
	Mon, 15 Dec 2014 05:39:52 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Mon, 15 Dec 2014 05:39:52 -0800 (PST)
In-Reply-To: <1418400081.16425.14.camel@citrix.com>
References: <CAHt6W4da7s=UcxucNnfYvWD8cMvVHSuQUiYWPTNu_V7X1ejq9w@mail.gmail.com>
	<1418399945.16425.13.camel@citrix.com>
	<1418400081.16425.14.camel@citrix.com>
Date: Mon, 15 Dec 2014 13:39:52 +0000
Message-ID: <CAHt6W4e8DOWoYZ=qdRbuzzbdKjsOQQgAZFhzCH351F-OWod-rg@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Porting 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>
Content-Type: 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-12-12 16:01 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
> On Fri, 2014-12-12 at 15:59 +0000, Ian Campbell wrote:
>> On Mon, 2014-12-08 at 15:47 +0000, Frediano Ziglio wrote:
>> > Hi,
>> >   while I was porting D01 platform
>> > (https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
>> > trying to describe the step I made and problems I encountered hoping
>> > it could useful to other people. The idea is to put such documentation
>> > in a wiki page or in the docs directory.
>> >
>> > Let me know what do you think.
>>
>> I've only skimmed the headings etc but I see no harm in posting it
>> somewhere publicly. I don't know if wiki or in tree docs would be
>> better. Maybe just post it on the list? At least then it will be in the
>> archives.

The problem with ML is that is not that "live", content is not easy changeable.

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 13:40:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 13:40:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0VsS-000596-Le; Mon, 15 Dec 2014 13:39:56 +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 1Y0VsQ-000591-QP
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 13:39:54 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	3E/74-22819-AA4EE845; Mon, 15 Dec 2014 13:39:54 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418650792!13405604!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16218 invoked from network); 15 Dec 2014 13:39:53 -0000
Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com)
	(209.85.220.169)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 13:39:53 -0000
Received: by mail-vc0-f169.google.com with SMTP id hy10so5579308vcb.0
	for <xen-devel@lists.xen.org>; Mon, 15 Dec 2014 05:39: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=Isisg6DJGv3qXvwfXtEgvdhjeMaDZJkgOGCj8x+yNQQ=;
	b=b+0n0nlDcMzPNqRrTdcsar3K8uAgxjhlNcoqKPP84swV3Z6NNsDarmwAC4slXnt18G
	1TzoxF6uT5pJgka8WqiCNo/oOry34+a707TQnnBJ2awenQ/uxQx1BdI1HZ+q0XaFMSkp
	Ty2lrWVhXeAMIgrYRIWtJ5VMKVkUSdUdap/T4uMkX7V/0sPDgoD1l+2vpARhckbR1T+f
	7Lc0NBJTDjNas0gu2tz7K8IdeD46cpROhBx4rmiOBLvSaoDGI+Dtc0dqkXAmOAjkgPmY
	xbd67eoGIHbVhVoKjUOGtvUhJZjzGE4CBt4REISoUTON6NsQRrIe4vkl+Ql1P7je95yh
	b+rw==
MIME-Version: 1.0
X-Received: by 10.52.165.10 with SMTP id yu10mr16407599vdb.3.1418650792424;
	Mon, 15 Dec 2014 05:39:52 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Mon, 15 Dec 2014 05:39:52 -0800 (PST)
In-Reply-To: <1418400081.16425.14.camel@citrix.com>
References: <CAHt6W4da7s=UcxucNnfYvWD8cMvVHSuQUiYWPTNu_V7X1ejq9w@mail.gmail.com>
	<1418399945.16425.13.camel@citrix.com>
	<1418400081.16425.14.camel@citrix.com>
Date: Mon, 15 Dec 2014 13:39:52 +0000
Message-ID: <CAHt6W4e8DOWoYZ=qdRbuzzbdKjsOQQgAZFhzCH351F-OWod-rg@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Porting 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>
Content-Type: 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-12-12 16:01 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
> On Fri, 2014-12-12 at 15:59 +0000, Ian Campbell wrote:
>> On Mon, 2014-12-08 at 15:47 +0000, Frediano Ziglio wrote:
>> > Hi,
>> >   while I was porting D01 platform
>> > (https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
>> > trying to describe the step I made and problems I encountered hoping
>> > it could useful to other people. The idea is to put such documentation
>> > in a wiki page or in the docs directory.
>> >
>> > Let me know what do you think.
>>
>> I've only skimmed the headings etc but I see no harm in posting it
>> somewhere publicly. I don't know if wiki or in tree docs would be
>> better. Maybe just post it on the list? At least then it will be in the
>> archives.

The problem with ML is that is not that "live", content is not easy changeable.

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 14:20:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 14:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0WUs-00064K-2Y; Mon, 15 Dec 2014 14:19:38 +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 1Y0WUr-00064F-4l
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 14:19:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E2/B5-09842-8FDEE845; Mon, 15 Dec 2014 14:19:36 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418653175!15723714!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18267 invoked from network); 15 Dec 2014 14:19:35 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 14:19:35 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id 297F51100CBD;
	Mon, 15 Dec 2014 15:19:35 +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 R0BznUX_eX9Y; Mon, 15 Dec 2014 15:19:34 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id C5E7C1100CBA;
	Mon, 15 Dec 2014 15:19:33 +0100 (CET)
Message-ID: <548EEDF5.20808@univention.de>
Date: Mon, 15 Dec 2014 15:19:33 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>	
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>	
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>	
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>	
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com>
In-Reply-To: <1418649458.16425.108.camel@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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

Hello Ian,

On 15.12.2014 14:17, Ian Campbell wrote:
> On Fri, 2014-12-12 at 17:58 +0000, Ian Campbell wrote:
>>  On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
>>> On 12.12.2014 17:56, Ian Campbell wrote:
>>>> On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
>>>>> On 12.12.2014 17:32, Ian Campbell wrote:
>>>>>> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
...
>>> The 1st and 2nd trace look like this: ptr in frame #2 looks very bogus.
>>>
>>> (gdb) bt full
>>> #0  talloc_chunk_from_ptr (ptr=0xff00000000) at talloc.c:116
>>>         tc = <value optimized out>
>>> #1  0x0000000000407edf in talloc_free (ptr=0xff00000000) at talloc.c:551
>>>         tc = <value optimized out>
>>> #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0
>>> "/var/lib/xenstored/tdb.0x1935bb0",

I just noticed something strange:

> #3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
> 0xff00000000 out of bounds>, hash_size=0,
>     tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
> #4  0x000000000040a70b in tdb_copy (tdb=0x192e540, outfile=0x1941fb0
> "/var/lib/xenstored/tdb.0x1935bb0")

Why does gdb-7.0.1 print "name=0xff000000" here for frame 3, but for
frame 2 and 4 the pointers are correct again?
Verifying the values with an explicit "print" shows them as correct.

>> I've timed out for tonight will try and have another look next week.
> 
> I've had another dig, and have instrumented all of the error paths from
> this function and I can't see any way for an invalid pointer to be
> produced, let alone freed. I've been running under valgrind which should
> have caught any uninitialised memory type errors.

Thank you for testing that.

>>>     hash_size=<value optimized out>, tdb_flags=0, open_flags=<value
>>> optimized out>, mode=<value optimized out>,
>>>     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at
>>> tdb.c:1958
> 
> Please can you confirm what is at line 1958 of your copy of tdb.c. I
> think it will be tdb->locked, but I'd like to be sure.

Yes, that's the line:
# sed -ne 1958p tdb.c
        SAFE_FREE(tdb->locked);

> You are running a 64-bit dom0, correct?

yes: x86_64

> I've only just noticed that
> 0xff00000000 is >32bits. My testing so far was 32-bit, I don't think it
> should matter wrt use of uninitialised data etc.
> 
> I can't help feeling that 0xff00000000 must be some sort of magic
> sentinel value to someone. I can't figure out what though.

0xff is too much for bit flip errors. and also two crashes on different
machines in the same location very much rules out any HW error for me.

My 2nd idea was that someone decremented 0 one too many, but then that
would have to be an 8 bit value - reading the code I didn't see anything
like that.

> Have you observed the xenstored processes growing especially large
> before this happens? I'm wondering if there might be a leak somewhere
> which after a time is resulting a 

I have no monitoring of the memory usage for the crashed systems, but
the core files look reasonable sane.
Looking at the test-system running
/usr/share/pyshared/xen/xend/xenstore/tests/stress_xs.py the memory
usage stays constant since last Friday.

> I'm about to send out a patch which plumbs tdb's logging into
> xenstored's logging, in the hopes that next time you see this it might
> say something as it dies.

Thank you for the patch: I'll try to incorporate it and will continue
trying to reproduce the crash.


One more thing we noticed: /var/lib/xenstored/ contained the tdb file
and to bit-identical copies after the crash, so I would read that as two
transactions being in progress at the time of the crash. Might be that
this is important.
But /usr/share/pyshared/xen/xend/xenstore/tests/stress_xs.py seems to
create more transaction in parallel and my test system so far has
survived this since Friday.

Sincerely
Philipp Hahn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 14:20:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 14:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0WUs-00064K-2Y; Mon, 15 Dec 2014 14:19:38 +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 1Y0WUr-00064F-4l
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 14:19:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	E2/B5-09842-8FDEE845; Mon, 15 Dec 2014 14:19:36 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418653175!15723714!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18267 invoked from network); 15 Dec 2014 14:19:35 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 14:19:35 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id 297F51100CBD;
	Mon, 15 Dec 2014 15:19:35 +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 R0BznUX_eX9Y; Mon, 15 Dec 2014 15:19:34 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id C5E7C1100CBA;
	Mon, 15 Dec 2014 15:19:33 +0100 (CET)
Message-ID: <548EEDF5.20808@univention.de>
Date: Mon, 15 Dec 2014 15:19:33 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>	
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>	
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>	
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>	
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com>
In-Reply-To: <1418649458.16425.108.camel@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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

Hello Ian,

On 15.12.2014 14:17, Ian Campbell wrote:
> On Fri, 2014-12-12 at 17:58 +0000, Ian Campbell wrote:
>>  On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
>>> On 12.12.2014 17:56, Ian Campbell wrote:
>>>> On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
>>>>> On 12.12.2014 17:32, Ian Campbell wrote:
>>>>>> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
...
>>> The 1st and 2nd trace look like this: ptr in frame #2 looks very bogus.
>>>
>>> (gdb) bt full
>>> #0  talloc_chunk_from_ptr (ptr=0xff00000000) at talloc.c:116
>>>         tc = <value optimized out>
>>> #1  0x0000000000407edf in talloc_free (ptr=0xff00000000) at talloc.c:551
>>>         tc = <value optimized out>
>>> #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0
>>> "/var/lib/xenstored/tdb.0x1935bb0",

I just noticed something strange:

> #3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
> 0xff00000000 out of bounds>, hash_size=0,
>     tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
> #4  0x000000000040a70b in tdb_copy (tdb=0x192e540, outfile=0x1941fb0
> "/var/lib/xenstored/tdb.0x1935bb0")

Why does gdb-7.0.1 print "name=0xff000000" here for frame 3, but for
frame 2 and 4 the pointers are correct again?
Verifying the values with an explicit "print" shows them as correct.

>> I've timed out for tonight will try and have another look next week.
> 
> I've had another dig, and have instrumented all of the error paths from
> this function and I can't see any way for an invalid pointer to be
> produced, let alone freed. I've been running under valgrind which should
> have caught any uninitialised memory type errors.

Thank you for testing that.

>>>     hash_size=<value optimized out>, tdb_flags=0, open_flags=<value
>>> optimized out>, mode=<value optimized out>,
>>>     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at
>>> tdb.c:1958
> 
> Please can you confirm what is at line 1958 of your copy of tdb.c. I
> think it will be tdb->locked, but I'd like to be sure.

Yes, that's the line:
# sed -ne 1958p tdb.c
        SAFE_FREE(tdb->locked);

> You are running a 64-bit dom0, correct?

yes: x86_64

> I've only just noticed that
> 0xff00000000 is >32bits. My testing so far was 32-bit, I don't think it
> should matter wrt use of uninitialised data etc.
> 
> I can't help feeling that 0xff00000000 must be some sort of magic
> sentinel value to someone. I can't figure out what though.

0xff is too much for bit flip errors. and also two crashes on different
machines in the same location very much rules out any HW error for me.

My 2nd idea was that someone decremented 0 one too many, but then that
would have to be an 8 bit value - reading the code I didn't see anything
like that.

> Have you observed the xenstored processes growing especially large
> before this happens? I'm wondering if there might be a leak somewhere
> which after a time is resulting a 

I have no monitoring of the memory usage for the crashed systems, but
the core files look reasonable sane.
Looking at the test-system running
/usr/share/pyshared/xen/xend/xenstore/tests/stress_xs.py the memory
usage stays constant since last Friday.

> I'm about to send out a patch which plumbs tdb's logging into
> xenstored's logging, in the hopes that next time you see this it might
> say something as it dies.

Thank you for the patch: I'll try to incorporate it and will continue
trying to reproduce the crash.


One more thing we noticed: /var/lib/xenstored/ contained the tdb file
and to bit-identical copies after the crash, so I would read that as two
transactions being in progress at the time of the crash. Might be that
this is important.
But /usr/share/pyshared/xen/xend/xenstore/tests/stress_xs.py seems to
create more transaction in parallel and my test system so far has
survived this since Friday.

Sincerely
Philipp Hahn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 14:44:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 14:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Wsv-0006rw-GG; Mon, 15 Dec 2014 14:44: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 1Y0Wst-0006rr-L4
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 14:44:27 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	72/F4-17735-AC3FE845; Mon, 15 Dec 2014 14:44:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418654665!13327735!1
X-Originating-IP: [66.165.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 28766 invoked from network); 15 Dec 2014 14:44:26 -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;
	15 Dec 2014 14:44:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204457379"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 09:44: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 1Y0We3-0001HQ-LP;
	Mon, 15 Dec 2014 14:29:07 +0000
Date: Mon, 15 Dec 2014 14:28:43 +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: <CAHA9rcigQRkg=zDydK5c720o9jVOor4ctde1GOL9LkLV6NRDCQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1412151417410.30971@kaball.uk.xensource.com>
References: <B1F3C9049C680C4FA4346583280217104D6AF38B@CMEXMB1.ad.emulex.com>
	<CAHA9rcigQRkg=zDydK5c720o9jVOor4ctde1GOL9LkLV6NRDCQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-824805934-1418653457=:30971"
Content-ID: <alpine.DEB.2.02.1412151425040.30971@kaball.uk.xensource.com>
X-DLP: MIA1
Cc: Eric.McLaughlin@emulex.com, linux-arm-kernel@lists.infradead.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] EXPORT_SYMBOL_GPL(xen_dma_os) causes build issues,
 Was: ubuntu ARM64 cross-compile issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-824805934-1418653457=:30971
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.02.1412151425041.30971@kaball.uk.xensource.com>

On Mon, 15 Dec 2014, Eric McLaughlin wrote:
> Hi Stefano,
>=20
> =C2=A0 Would you be able to help us resolve the following issue?
>=20
> =C2=A0 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348442

I don't want to encourage third party closed source linux modules, but I
don't want to stand in your way either.  I can live with relaxing the
EXPORT_SYMBOL_GPL(xen_dma_ops) into EXPORT_SYMBOL.

If you (or somebody else) submit a patch, I'll queue it up.
--1342847746-824805934-1418653457=:30971
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-824805934-1418653457=:30971--


From xen-devel-bounces@lists.xen.org Mon Dec 15 14:44:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 14:44:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Wsv-0006rw-GG; Mon, 15 Dec 2014 14:44: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 1Y0Wst-0006rr-L4
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 14:44:27 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	72/F4-17735-AC3FE845; Mon, 15 Dec 2014 14:44:26 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418654665!13327735!1
X-Originating-IP: [66.165.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 28766 invoked from network); 15 Dec 2014 14:44:26 -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;
	15 Dec 2014 14:44:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204457379"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 09:44: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 1Y0We3-0001HQ-LP;
	Mon, 15 Dec 2014 14:29:07 +0000
Date: Mon, 15 Dec 2014 14:28:43 +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: <CAHA9rcigQRkg=zDydK5c720o9jVOor4ctde1GOL9LkLV6NRDCQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1412151417410.30971@kaball.uk.xensource.com>
References: <B1F3C9049C680C4FA4346583280217104D6AF38B@CMEXMB1.ad.emulex.com>
	<CAHA9rcigQRkg=zDydK5c720o9jVOor4ctde1GOL9LkLV6NRDCQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-824805934-1418653457=:30971"
Content-ID: <alpine.DEB.2.02.1412151425040.30971@kaball.uk.xensource.com>
X-DLP: MIA1
Cc: Eric.McLaughlin@emulex.com, linux-arm-kernel@lists.infradead.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] EXPORT_SYMBOL_GPL(xen_dma_os) causes build issues,
 Was: ubuntu ARM64 cross-compile issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-824805934-1418653457=:30971
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.02.1412151425041.30971@kaball.uk.xensource.com>

On Mon, 15 Dec 2014, Eric McLaughlin wrote:
> Hi Stefano,
>=20
> =C2=A0 Would you be able to help us resolve the following issue?
>=20
> =C2=A0 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348442

I don't want to encourage third party closed source linux modules, but I
don't want to stand in your way either.  I can live with relaxing the
EXPORT_SYMBOL_GPL(xen_dma_ops) into EXPORT_SYMBOL.

If you (or somebody else) submit a patch, I'll queue it up.
--1342847746-824805934-1418653457=:30971
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-824805934-1418653457=:30971--


From xen-devel-bounces@lists.xen.org Mon Dec 15 14:50:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 14: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 1Y0Wya-00070r-A8; Mon, 15 Dec 2014 14:50: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 1Y0WyZ-00070m-2h
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 14:50:19 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	32/EB-02712-A25FE845; Mon, 15 Dec 2014 14:50:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418655016!10519028!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 17800 invoked from network); 15 Dec 2014 14:50:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 14:50:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204919209"
Message-ID: <1418655014.16425.138.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Mon, 15 Dec 2014 14:50:14 +0000
In-Reply-To: <548EEDF5.20808@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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] 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 Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
> Hello Ian,
> 
> On 15.12.2014 14:17, Ian Campbell wrote:
> > On Fri, 2014-12-12 at 17:58 +0000, Ian Campbell wrote:
> >>  On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
> >>> On 12.12.2014 17:56, Ian Campbell wrote:
> >>>> On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
> >>>>> On 12.12.2014 17:32, Ian Campbell wrote:
> >>>>>> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
> ...
> >>> The 1st and 2nd trace look like this: ptr in frame #2 looks very bogus.
> >>>
> >>> (gdb) bt full
> >>> #0  talloc_chunk_from_ptr (ptr=0xff00000000) at talloc.c:116
> >>>         tc = <value optimized out>
> >>> #1  0x0000000000407edf in talloc_free (ptr=0xff00000000) at talloc.c:551
> >>>         tc = <value optimized out>
> >>> #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0
> >>> "/var/lib/xenstored/tdb.0x1935bb0",
> 
> I just noticed something strange:
> 
> > #3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
> > 0xff00000000 out of bounds>, hash_size=0,
> >     tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
> > #4  0x000000000040a70b in tdb_copy (tdb=0x192e540, outfile=0x1941fb0
> > "/var/lib/xenstored/tdb.0x1935bb0")
> 
> Why does gdb-7.0.1 print "name=0xff000000" here for frame 3, but for
> frame 2 and 4 the pointers are correct again?
> Verifying the values with an explicit "print" shows them as correct.

I has just noticed that and was wondering about that same thing. I'm
starting to worry that 0xff00000000 might just be a gdb thing, similar
to <value optimized out>, but infinitely more misleading.

I've also noticed in
https://forge.univention.org/bugzilla/show_bug.cgi?id=35104 that the
constant can be either 0xff000000, 0xff00000000 or 0xff0000000000 (6, 8
or 10 zeroes).

> >>>     hash_size=<value optimized out>, tdb_flags=0, open_flags=<value
> >>> optimized out>, mode=<value optimized out>,
> >>>     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at
> >>> tdb.c:1958
> > 
> > Please can you confirm what is at line 1958 of your copy of tdb.c. I
> > think it will be tdb->locked, but I'd like to be sure.
> 
> Yes, that's the line:
> # sed -ne 1958p tdb.c
>         SAFE_FREE(tdb->locked);

Good, thanks.

> > You are running a 64-bit dom0, correct?
> 
> yes: x86_64

Thanks for confirming. I'm resurrecting the 64-bit root partition on my
test box (which it turns out was still Debian Squeeze!)

> 
> > I've only just noticed that
> > 0xff00000000 is >32bits. My testing so far was 32-bit, I don't think it
> > should matter wrt use of uninitialised data etc.
> > 
> > I can't help feeling that 0xff00000000 must be some sort of magic
> > sentinel value to someone. I can't figure out what though.
> 
> 0xff is too much for bit flip errors. and also two crashes on different
> machines in the same location very much rules out any HW error for me.
> 
> My 2nd idea was that someone decremented 0 one too many, but then that
> would have to be an 8 bit value - reading the code I didn't see anything
> like that.

I was wondering if it was an overflow or sign-extension thing, but it
doesn't seem likely, not enough high bits set for one thing.

> One more thing we noticed: /var/lib/xenstored/ contained the tdb file
> and to bit-identical copies after the crash, so I would read that as two
> transactions being in progress at the time of the crash. Might be that
> this is important.

It's certainly worth noting, 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 Dec 15 14:50:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 14: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 1Y0Wya-00070r-A8; Mon, 15 Dec 2014 14:50: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 1Y0WyZ-00070m-2h
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 14:50:19 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	32/EB-02712-A25FE845; Mon, 15 Dec 2014 14:50:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418655016!10519028!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 17800 invoked from network); 15 Dec 2014 14:50:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 14:50:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204919209"
Message-ID: <1418655014.16425.138.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Mon, 15 Dec 2014 14:50:14 +0000
In-Reply-To: <548EEDF5.20808@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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] 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 Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
> Hello Ian,
> 
> On 15.12.2014 14:17, Ian Campbell wrote:
> > On Fri, 2014-12-12 at 17:58 +0000, Ian Campbell wrote:
> >>  On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
> >>> On 12.12.2014 17:56, Ian Campbell wrote:
> >>>> On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
> >>>>> On 12.12.2014 17:32, Ian Campbell wrote:
> >>>>>> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
> ...
> >>> The 1st and 2nd trace look like this: ptr in frame #2 looks very bogus.
> >>>
> >>> (gdb) bt full
> >>> #0  talloc_chunk_from_ptr (ptr=0xff00000000) at talloc.c:116
> >>>         tc = <value optimized out>
> >>> #1  0x0000000000407edf in talloc_free (ptr=0xff00000000) at talloc.c:551
> >>>         tc = <value optimized out>
> >>> #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0
> >>> "/var/lib/xenstored/tdb.0x1935bb0",
> 
> I just noticed something strange:
> 
> > #3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
> > 0xff00000000 out of bounds>, hash_size=0,
> >     tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
> > #4  0x000000000040a70b in tdb_copy (tdb=0x192e540, outfile=0x1941fb0
> > "/var/lib/xenstored/tdb.0x1935bb0")
> 
> Why does gdb-7.0.1 print "name=0xff000000" here for frame 3, but for
> frame 2 and 4 the pointers are correct again?
> Verifying the values with an explicit "print" shows them as correct.

I has just noticed that and was wondering about that same thing. I'm
starting to worry that 0xff00000000 might just be a gdb thing, similar
to <value optimized out>, but infinitely more misleading.

I've also noticed in
https://forge.univention.org/bugzilla/show_bug.cgi?id=35104 that the
constant can be either 0xff000000, 0xff00000000 or 0xff0000000000 (6, 8
or 10 zeroes).

> >>>     hash_size=<value optimized out>, tdb_flags=0, open_flags=<value
> >>> optimized out>, mode=<value optimized out>,
> >>>     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at
> >>> tdb.c:1958
> > 
> > Please can you confirm what is at line 1958 of your copy of tdb.c. I
> > think it will be tdb->locked, but I'd like to be sure.
> 
> Yes, that's the line:
> # sed -ne 1958p tdb.c
>         SAFE_FREE(tdb->locked);

Good, thanks.

> > You are running a 64-bit dom0, correct?
> 
> yes: x86_64

Thanks for confirming. I'm resurrecting the 64-bit root partition on my
test box (which it turns out was still Debian Squeeze!)

> 
> > I've only just noticed that
> > 0xff00000000 is >32bits. My testing so far was 32-bit, I don't think it
> > should matter wrt use of uninitialised data etc.
> > 
> > I can't help feeling that 0xff00000000 must be some sort of magic
> > sentinel value to someone. I can't figure out what though.
> 
> 0xff is too much for bit flip errors. and also two crashes on different
> machines in the same location very much rules out any HW error for me.
> 
> My 2nd idea was that someone decremented 0 one too many, but then that
> would have to be an 8 bit value - reading the code I didn't see anything
> like that.

I was wondering if it was an overflow or sign-extension thing, but it
doesn't seem likely, not enough high bits set for one thing.

> One more thing we noticed: /var/lib/xenstored/ contained the tdb file
> and to bit-identical copies after the crash, so I would read that as two
> transactions being in progress at the time of the crash. Might be that
> this is important.

It's certainly worth noting, 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 Dec 15 14:59:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 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 1Y0X6u-0007KG-Bv; Mon, 15 Dec 2014 14:58:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Y0X6t-0007KB-9P
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 14:58:55 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	17/E7-25547-E27FE845; Mon, 15 Dec 2014 14:58:54 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418655532!13485874!1
X-Originating-IP: [66.165.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 9612 invoked from network); 15 Dec 2014 14:58:53 -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;
	15 Dec 2014 14:58:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204462646"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 09:58: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 1Y0X6o-0002A8-1I;
	Mon, 15 Dec 2014 14:58:50 +0000
Date: Mon, 15 Dec 2014 14:58:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
In-Reply-To: <1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
Message-ID: <alpine.DEB.2.02.1412151441360.30971@kaball.uk.xensource.com>
References: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
	<1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Michal Marek <mmarek@suse.cz>, x86@kernel.org,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>,
	Randy Dunlap <rdunlap@infradead.org>, josh@joshtriplett.org,
	linux-kernel@vger.kernel.org, Pekka Enberg <penberg@kernel.org>,
	mtosatti@redhat.com, bpoirier@suse.de,
	Borislav Petkov <bp@suse.de>, levinsasha928@gmail.com,
	hpa@zytor.com, David Rientjes <rientjes@google.com>,
	fengguang.wu@intel.com, sam@ravnborg.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86, arm, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 9 Dec 2014, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> This lets you build a kernel which can support xen dom0
> or xen guests by just using:
> 
>    make xenconfig
> 
> on both x86 and arm64 kernels. This also splits out the
> options which are available currently to be built with x86
> and 'make ARCH=arm64' under a shared config.
> 
> Technically xen supports a dom0 kernel and also a guest
> kernel configuration but upon review with the xen team
> since we don't have many dom0 options its best to just
> combine these two into one.
> 
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Pekka Enberg <penberg@kernel.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Michal Marek <mmarek@suse.cz>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: penberg@kernel.org
> Cc: levinsasha928@gmail.com
> Cc: mtosatti@redhat.com
> Cc: fengguang.wu@intel.com
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xenproject.org
> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>  arch/x86/configs/xen.config |  7 +++++++
>  kernel/configs/xen.config   | 30 ++++++++++++++++++++++++++++++
>  scripts/kconfig/Makefile    |  5 +++++
>  3 files changed, 42 insertions(+)
>  create mode 100644 arch/x86/configs/xen.config
>  create mode 100644 kernel/configs/xen.config
> 
> diff --git a/arch/x86/configs/xen.config b/arch/x86/configs/xen.config
> new file mode 100644
> index 0000000..92b8587f
> --- /dev/null
> +++ b/arch/x86/configs/xen.config
> @@ -0,0 +1,7 @@
> +# x86 xen specific config options
> +CONFIG_XEN_PVHVM=y
> +CONFIG_XEN_MAX_DOMAIN_MEMORY=500
> +CONFIG_XEN_SAVE_RESTORE=y
> +# CONFIG_XEN_DEBUG_FS is not set
> +CONFIG_XEN_PVH=y
> +CONFIG_XEN_MCE_LOG=y
> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
> new file mode 100644
> index 0000000..d2ec010
> --- /dev/null
> +++ b/kernel/configs/xen.config
> @@ -0,0 +1,30 @@
> +# generic config
> +CONFIG_XEN=y
> +CONFIG_XEN_DOM0=y
> +CONFIG_PCI_XEN=y

This shouldn't be here


> +CONFIG_XEN_PCIDEV_FRONTEND=m
> +CONFIG_XEN_BLKDEV_FRONTEND=m
> +CONFIG_XEN_BLKDEV_BACKEND=m
> +CONFIG_XEN_NETDEV_FRONTEND=m
> +CONFIG_XEN_NETDEV_BACKEND=m
> +CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
> +CONFIG_HVC_XEN=y
> +CONFIG_HVC_XEN_FRONTEND=y
> +CONFIG_TCG_XEN=m

neither should this


> +CONFIG_XEN_WDT=m
> +CONFIG_XEN_FBDEV_FRONTEND=y
> +CONFIG_XEN_BALLOON=y
> +CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
> +CONFIG_XEN_SCRUB_PAGES=y
> +CONFIG_XEN_DEV_EVTCHN=m
> +CONFIG_XEN_BACKEND=y
> +CONFIG_XENFS=m
> +CONFIG_XEN_COMPAT_XENFS=y
> +CONFIG_XEN_SYS_HYPERVISOR=y
> +CONFIG_XEN_XENBUS_FRONTEND=y
> +CONFIG_XEN_GNTDEV=m
> +CONFIG_XEN_GRANT_DEV_ALLOC=m
> +CONFIG_SWIOTLB_XEN=y
> +CONFIG_XEN_PCIDEV_BACKEND=m
> +CONFIG_XEN_PRIVCMD=m
> +CONFIG_XEN_ACPI_PROCESSOR=m

and this


> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index ff612b0..f4a8f89 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -117,6 +117,10 @@ PHONY += kvmconfig
>  kvmconfig:
>  	$(call mergeconfig,kvm_guest)
>  
> +PHONY += xenconfig
> +xenconfig:
> +	$(call mergeconfig,xen)
> +
>  PHONY += tinyconfig
>  tinyconfig: allnoconfig
>  	$(call mergeconfig,tiny)
> @@ -142,6 +146,7 @@ help:
>  	@echo  '  listnewconfig   - List new options'
>  	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
>  	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
> +	@echo  '  xenconfig       - Enable additional options for xen dom0 and guest kernel support'
>  	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
>  
>  # lxdialog stuff
> -- 
> 2.1.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 14:59:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 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 1Y0X6u-0007KG-Bv; Mon, 15 Dec 2014 14:58:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Y0X6t-0007KB-9P
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 14:58:55 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	17/E7-25547-E27FE845; Mon, 15 Dec 2014 14:58:54 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418655532!13485874!1
X-Originating-IP: [66.165.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 9612 invoked from network); 15 Dec 2014 14:58:53 -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;
	15 Dec 2014 14:58:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204462646"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 09:58: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 1Y0X6o-0002A8-1I;
	Mon, 15 Dec 2014 14:58:50 +0000
Date: Mon, 15 Dec 2014 14:58:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
In-Reply-To: <1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
Message-ID: <alpine.DEB.2.02.1412151441360.30971@kaball.uk.xensource.com>
References: <1418168138-6425-1-git-send-email-mcgrof@do-not-panic.com>
	<1418168138-6425-3-git-send-email-mcgrof@do-not-panic.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: Michal Marek <mmarek@suse.cz>, x86@kernel.org,
	Ian Campbell <Ian.Campbell@citrix.com>, kvm@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>,
	Randy Dunlap <rdunlap@infradead.org>, josh@joshtriplett.org,
	linux-kernel@vger.kernel.org, Pekka Enberg <penberg@kernel.org>,
	mtosatti@redhat.com, bpoirier@suse.de,
	Borislav Petkov <bp@suse.de>, levinsasha928@gmail.com,
	hpa@zytor.com, David Rientjes <rientjes@google.com>,
	fengguang.wu@intel.com, sam@ravnborg.org,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86, arm, platform, xen,
 kconfig: add xen defconfig helper
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 9 Dec 2014, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> This lets you build a kernel which can support xen dom0
> or xen guests by just using:
> 
>    make xenconfig
> 
> on both x86 and arm64 kernels. This also splits out the
> options which are available currently to be built with x86
> and 'make ARCH=arm64' under a shared config.
> 
> Technically xen supports a dom0 kernel and also a guest
> kernel configuration but upon review with the xen team
> since we don't have many dom0 options its best to just
> combine these two into one.
> 
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Pekka Enberg <penberg@kernel.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Michal Marek <mmarek@suse.cz>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: penberg@kernel.org
> Cc: levinsasha928@gmail.com
> Cc: mtosatti@redhat.com
> Cc: fengguang.wu@intel.com
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xenproject.org
> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>  arch/x86/configs/xen.config |  7 +++++++
>  kernel/configs/xen.config   | 30 ++++++++++++++++++++++++++++++
>  scripts/kconfig/Makefile    |  5 +++++
>  3 files changed, 42 insertions(+)
>  create mode 100644 arch/x86/configs/xen.config
>  create mode 100644 kernel/configs/xen.config
> 
> diff --git a/arch/x86/configs/xen.config b/arch/x86/configs/xen.config
> new file mode 100644
> index 0000000..92b8587f
> --- /dev/null
> +++ b/arch/x86/configs/xen.config
> @@ -0,0 +1,7 @@
> +# x86 xen specific config options
> +CONFIG_XEN_PVHVM=y
> +CONFIG_XEN_MAX_DOMAIN_MEMORY=500
> +CONFIG_XEN_SAVE_RESTORE=y
> +# CONFIG_XEN_DEBUG_FS is not set
> +CONFIG_XEN_PVH=y
> +CONFIG_XEN_MCE_LOG=y
> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
> new file mode 100644
> index 0000000..d2ec010
> --- /dev/null
> +++ b/kernel/configs/xen.config
> @@ -0,0 +1,30 @@
> +# generic config
> +CONFIG_XEN=y
> +CONFIG_XEN_DOM0=y
> +CONFIG_PCI_XEN=y

This shouldn't be here


> +CONFIG_XEN_PCIDEV_FRONTEND=m
> +CONFIG_XEN_BLKDEV_FRONTEND=m
> +CONFIG_XEN_BLKDEV_BACKEND=m
> +CONFIG_XEN_NETDEV_FRONTEND=m
> +CONFIG_XEN_NETDEV_BACKEND=m
> +CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
> +CONFIG_HVC_XEN=y
> +CONFIG_HVC_XEN_FRONTEND=y
> +CONFIG_TCG_XEN=m

neither should this


> +CONFIG_XEN_WDT=m
> +CONFIG_XEN_FBDEV_FRONTEND=y
> +CONFIG_XEN_BALLOON=y
> +CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
> +CONFIG_XEN_SCRUB_PAGES=y
> +CONFIG_XEN_DEV_EVTCHN=m
> +CONFIG_XEN_BACKEND=y
> +CONFIG_XENFS=m
> +CONFIG_XEN_COMPAT_XENFS=y
> +CONFIG_XEN_SYS_HYPERVISOR=y
> +CONFIG_XEN_XENBUS_FRONTEND=y
> +CONFIG_XEN_GNTDEV=m
> +CONFIG_XEN_GRANT_DEV_ALLOC=m
> +CONFIG_SWIOTLB_XEN=y
> +CONFIG_XEN_PCIDEV_BACKEND=m
> +CONFIG_XEN_PRIVCMD=m
> +CONFIG_XEN_ACPI_PROCESSOR=m

and this


> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index ff612b0..f4a8f89 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -117,6 +117,10 @@ PHONY += kvmconfig
>  kvmconfig:
>  	$(call mergeconfig,kvm_guest)
>  
> +PHONY += xenconfig
> +xenconfig:
> +	$(call mergeconfig,xen)
> +
>  PHONY += tinyconfig
>  tinyconfig: allnoconfig
>  	$(call mergeconfig,tiny)
> @@ -142,6 +146,7 @@ help:
>  	@echo  '  listnewconfig   - List new options'
>  	@echo  '  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value'
>  	@echo  '  kvmconfig	  - Enable additional options for kvm guest kernel support'
> +	@echo  '  xenconfig       - Enable additional options for xen dom0 and guest kernel support'
>  	@echo  '  tinyconfig	  - Configure the tiniest possible kernel'
>  
>  # lxdialog stuff
> -- 
> 2.1.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 15:18:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:18:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0XPe-000819-6A; Mon, 15 Dec 2014 15:18: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 1Y0XPc-000812-Je
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 15:18:16 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	D4/2C-31453-7BBFE845; Mon, 15 Dec 2014 15:18:15 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418656693!8023433!1
X-Originating-IP: [66.165.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 13422 invoked from network); 15 Dec 2014 15:18:14 -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 Dec 2014 15:18:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204472850"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 10:18: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 1Y0XPX-0002cI-Ic;
	Mon, 15 Dec 2014 15:18:11 +0000
Date: Mon, 15 Dec 2014 15:17:47 +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: <548B25FC.6020601@citrix.com>
Message-ID: <alpine.DEB.2.02.1412151516560.30971@kaball.uk.xensource.com>
References: <548AEAE7.8020604@suse.com> <548B25FC.6020601@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] Xen's Linux kernel config options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Dec 2014, David Vrabel wrote:
> On 12/12/14 13:17, Juergen Gross wrote:
> > 
> > 
> > As a first draft I'd suggest the following:
> 
> Some rough thoughts below.
> 
> > Option                          Selects                 Depends
> > ----------------------------------------------------------------------
> > XEN                             SWIOTLB_XEN(arm,arm64)
> 
> XEN should get you basic support for making hypercalls and allowing
> guest to identify themselves as running on Xen.  I don't think it should
> select SWIOTLB_XEN even on ARM as it is only needed for guests with
> access to real hardware.

In that case XEN_BACKEND should select SWIOTLB_XEN.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 15:18:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:18:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0XPe-000819-6A; Mon, 15 Dec 2014 15:18: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 1Y0XPc-000812-Je
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 15:18:16 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	D4/2C-31453-7BBFE845; Mon, 15 Dec 2014 15:18:15 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418656693!8023433!1
X-Originating-IP: [66.165.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 13422 invoked from network); 15 Dec 2014 15:18:14 -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 Dec 2014 15:18:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204472850"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 10:18: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 1Y0XPX-0002cI-Ic;
	Mon, 15 Dec 2014 15:18:11 +0000
Date: Mon, 15 Dec 2014 15:17:47 +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: <548B25FC.6020601@citrix.com>
Message-ID: <alpine.DEB.2.02.1412151516560.30971@kaball.uk.xensource.com>
References: <548AEAE7.8020604@suse.com> <548B25FC.6020601@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Juergen Gross <jgross@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] Xen's Linux kernel config options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Dec 2014, David Vrabel wrote:
> On 12/12/14 13:17, Juergen Gross wrote:
> > 
> > 
> > As a first draft I'd suggest the following:
> 
> Some rough thoughts below.
> 
> > Option                          Selects                 Depends
> > ----------------------------------------------------------------------
> > XEN                             SWIOTLB_XEN(arm,arm64)
> 
> XEN should get you basic support for making hypercalls and allowing
> guest to identify themselves as running on Xen.  I don't think it should
> select SWIOTLB_XEN even on ARM as it is only needed for guests with
> access to real hardware.

In that case XEN_BACKEND should select SWIOTLB_XEN.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 15:22:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0XTv-0008VH-Dl; Mon, 15 Dec 2014 15:22:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Y0XTt-0008V8-Ej
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 15:22:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7B/CC-09842-0CCFE845; Mon, 15 Dec 2014 15:22:40 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418656959!15722537!1
X-Originating-IP: [66.165.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 6778 invoked from network); 15 Dec 2014 15:22:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 15:22:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204934239"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 10:22: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 1Y0XTp-0002kB-KZ;
	Mon, 15 Dec 2014 15:22:37 +0000
Date: Mon, 15 Dec 2014 15:22:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <548EB672020000780004F7D2@mail.emea.novell.com>
Message-ID: <alpine.DEB.2.02.1412151521400.30971@kaball.uk.xensource.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
	<548EB672020000780004F7D2@mail.emea.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Kevin Tian <kevin.tian@intel.com>, "keir@xen.org" <keir@xen.org>,
	Tim Deegan <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Dec 2014, Jan Beulich wrote:
> >>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
> > yes, definitely host RAM is the upper limit, and what I'm concerning here
> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
> > resource, w/o collision with other PFN reservation usage (ballooning
> > should be fine since it's operating existing RAM ranges in dom0 e820
> > table).
> 
> I don't think ballooning is restricted to the regions named RAM in
> Dom0's E820 table (at least it shouldn't be, and wasn't in the
> classic Xen kernels).

Could you please elaborate more on this? It seems counter-intuitive at best.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 15:22:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0XTv-0008VH-Dl; Mon, 15 Dec 2014 15:22:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@citrix.com>) id 1Y0XTt-0008V8-Ej
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 15:22:41 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	7B/CC-09842-0CCFE845; Mon, 15 Dec 2014 15:22:40 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418656959!15722537!1
X-Originating-IP: [66.165.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 6778 invoked from network); 15 Dec 2014 15:22:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 15:22:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204934239"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 10:22: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 1Y0XTp-0002kB-KZ;
	Mon, 15 Dec 2014 15:22:37 +0000
Date: Mon, 15 Dec 2014 15:22:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <548EB672020000780004F7D2@mail.emea.novell.com>
Message-ID: <alpine.DEB.2.02.1412151521400.30971@kaball.uk.xensource.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
	<548EB672020000780004F7D2@mail.emea.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Kevin Tian <kevin.tian@intel.com>, "keir@xen.org" <keir@xen.org>,
	Tim Deegan <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Dec 2014, Jan Beulich wrote:
> >>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
> > yes, definitely host RAM is the upper limit, and what I'm concerning here
> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
> > resource, w/o collision with other PFN reservation usage (ballooning
> > should be fine since it's operating existing RAM ranges in dom0 e820
> > table).
> 
> I don't think ballooning is restricted to the regions named RAM in
> Dom0's E820 table (at least it shouldn't be, and wasn't in the
> classic Xen kernels).

Could you please elaborate more on this? It seems counter-intuitive at best.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 15:29:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:29:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Xa8-0000K3-81; Mon, 15 Dec 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 1Y0Xa7-0000Jt-4t
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 15:29:07 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	7E/56-24859-24EFE845; Mon, 15 Dec 2014 15:29:06 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418657343!13489720!1
X-Originating-IP: [66.165.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 12669 invoked from network); 15 Dec 2014 15:29:05 -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 Dec 2014 15:29:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204477806"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 10:29:02 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Y0Xa1-0002qi-5u;
	Mon, 15 Dec 2014 15:29:01 +0000
Date: Mon, 15 Dec 2014 15:29:00 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20141215152900.GB8049@zion.uk.xensource.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418133859-27763-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] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 02:04:19PM +0000, George Dunlap wrote:
[...]
> While preparing this patch, I also noticed that cdroms will ignore the
> backend parameter and treat everything as a file.  This is a bug

create !
title it CDROM's backend ignored and always treated as file
thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 15:29:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:29:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Xa8-0000K3-81; Mon, 15 Dec 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 1Y0Xa7-0000Jt-4t
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 15:29:07 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	7E/56-24859-24EFE845; Mon, 15 Dec 2014 15:29:06 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418657343!13489720!1
X-Originating-IP: [66.165.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 12669 invoked from network); 15 Dec 2014 15:29:05 -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 Dec 2014 15:29:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204477806"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 10:29:02 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Y0Xa1-0002qi-5u;
	Mon, 15 Dec 2014 15:29:01 +0000
Date: Mon, 15 Dec 2014 15:29:00 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20141215152900.GB8049@zion.uk.xensource.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418133859-27763-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] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 09, 2014 at 02:04:19PM +0000, George Dunlap wrote:
[...]
> While preparing this patch, I also noticed that cdroms will ignore the
> backend parameter and treat everything as a file.  This is a bug

create !
title it CDROM's backend ignored and always treated as file
thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 15:32:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Xde-0000Xe-Se; Mon, 15 Dec 2014 15:32: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 1Y0Xdd-0000XZ-B4
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 15:32:45 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	15/BE-25727-C1FFE845; Mon, 15 Dec 2014 15:32:44 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418657562!13492554!1
X-Originating-IP: [66.165.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 3422 invoked from network); 15 Dec 2014 15:32:43 -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;
	15 Dec 2014 15:32:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204939536"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 10:32: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 1Y0XdX-0002uZ-GT;
	Mon, 15 Dec 2014 15:32:39 +0000
Date: Mon, 15 Dec 2014 15:32:15 +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: <1418395392-30460-3-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1412151527310.30971@kaball.uk.xensource.com>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
	<1418395392-30460-3-git-send-email-julien.grall@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	xen-devel@lists.xenproject.org, parth.dixit@linaro.org,
	christoffer.dall@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.6 2/4] xen/arm: vgic: Keep track of
 vIRQ used by a domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Dec 2014, Julien Grall wrote:
> While it's easy to know which hardware IRQ is assigned to a domain, there
> is no way to know which IRQ is emulated by Xen for a specific domain.
> 
> Introduce a bitmap to keep track of every vIRQ used by a domain. This
> will be used later to find free vIRQ for interrupt device assignment and
> emulated interrupt.
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> ---
>  xen/arch/arm/domain_build.c          |  6 +++
>  xen/arch/arm/platforms/xgene-storm.c |  4 ++
>  xen/arch/arm/vgic.c                  | 76 ++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/vtimer.c                | 15 +++++++
>  xen/include/asm-arm/domain.h         |  1 +
>  xen/include/asm-arm/vgic.h           | 13 ++++++
>  6 files changed, 115 insertions(+)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index de180d8..c238c8f 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -968,6 +968,12 @@ static int map_device(struct domain *d, struct dt_device_node *dev)
>          irq = res;
>  
>          DPRINT("irq %u = %u\n", i, irq);
> +        /*
> +         * Checking the return of vgic_reserve_virq is not
> +         * necessary. It should not fail except when we try to map
> +         * twice the IRQ. This can happen if the IRQ is shared
> +         */
> +        vgic_reserve_virq(d, irq);
>          res = route_irq_to_guest(d, irq, dt_node_name(dev));
>          if ( res )
>          {
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 0b3492d..416d42c 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -71,6 +71,10 @@ static int map_one_spi(struct domain *d, const char *what,
>  
>      printk("Additional IRQ %u (%s)\n", irq, what);
>  
> +    if ( !vgic_reserve_virq(d, irq) )
> +        printk("Failed to reserve the vIRQ %u on dom%d\n",
> +               irq, d->domain_id);
> +
>      ret = route_irq_to_guest(d, irq, what);
>      if ( ret )
>          printk("Failed to route %s to dom%d\n", what, d->domain_id);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 75cb7ff..dbfc259 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -87,6 +87,8 @@ int domain_vgic_init(struct domain *d)
>          return -ENODEV;
>      }
>  
> +    spin_lock_init(&d->arch.vgic.lock);

you should probably explain in the commit message the reason why you are
making changes to the vgic lock


>      d->arch.vgic.shared_irqs =
>          xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
>      if ( d->arch.vgic.shared_irqs == NULL )
> @@ -107,6 +109,15 @@ int domain_vgic_init(struct domain *d)
>  
>      d->arch.vgic.handler->domain_init(d);
>  
> +    d->arch.vgic.allocated_irqs =
> +        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irqs(d)));
> +    if ( !d->arch.vgic.allocated_irqs )
> +        return -ENOMEM;
> +
> +    /* vIRQ0-15 (SGIs) are reserved */
> +    for (i = 0; i <= 15; i++)
> +        set_bit(i, d->arch.vgic.allocated_irqs);
> +
>      return 0;
>  }
>  
> @@ -119,6 +130,7 @@ void domain_vgic_free(struct domain *d)
>  {
>      xfree(d->arch.vgic.shared_irqs);
>      xfree(d->arch.vgic.pending_irqs);
> +    xfree(d->arch.vgic.allocated_irqs);
>  }
>  
>  int vcpu_vgic_init(struct vcpu *v)
> @@ -441,6 +453,70 @@ int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
>      return v->domain->arch.vgic.handler->emulate_sysreg(regs, hsr);
>  }
>  
> +bool_t vgic_reserve_virq(struct domain *d, unsigned int virq)
> +{
> +    bool_t reserved;
> +
> +    if ( virq >= vgic_num_irqs(d) )
> +        return 0;
> +
> +    spin_lock(&d->arch.vgic.lock);
> +    reserved = !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
> +    spin_unlock(&d->arch.vgic.lock);

test_and_set_bit is atomic, why do you need to take the lock?


> +    return reserved;
> +}
> +
> +int vgic_allocate_virq(struct domain *d, bool_t spi)
> +{
> +    int ret = -1;
> +    unsigned int virq;
> +
> +    spin_lock(&d->arch.vgic.lock);
> +    if ( !spi )
> +    {
> +        virq = find_first_zero_bit(d->arch.vgic.allocated_irqs, 32);
> +        if ( virq >= 32 )
> +            goto unlock;
> +    }
> +    else
> +    {
> +        virq = find_next_zero_bit(d->arch.vgic.allocated_irqs,
> +                                  32, vgic_num_irqs(d));
> +        if ( virq >= vgic_num_irqs(d) )
> +            goto unlock;
> +    }
> +
> +    set_bit(virq, d->arch.vgic.allocated_irqs);
> +    ret = virq;
> +
> +unlock:
> +    spin_unlock(&d->arch.vgic.lock);

you might be able to write this function without taking the lock too, by
using test_and_set_bit and retries:

retry:
    virq = find_first_zero_bit;
    if (test_and_set_bit(virq))
        goto retry;



> +    return ret;
> +}
> +
> +void vgic_free_virq(struct domain *d, unsigned int virq)
> +{
> +    unsigned int spi;
> +
> +    if ( is_hardware_domain(d) )
> +        return;
> +
> +    if ( virq < 32 && virq >= vgic_num_irqs(d) )
> +        return;
> +
> +    spi = virq - 32;
> +
> +    /* Taking the vGIC domain lock is not necessary. We don't care if
> +     * the bit is cleared a bit later. What only matters is bit to 1.
> +     *
> +     * With this solution vgic_allocate may fail to find an vIRQ if the
> +     * allocated_irqs is fully. But we don't care.
> +     */
> +    clear_bit(spi, d->arch.vgic.allocated_irqs);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 2e95ceb..de660bb 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -49,6 +49,21 @@ int domain_vtimer_init(struct domain *d)
>  {
>      d->arch.phys_timer_base.offset = NOW();
>      d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0);
> +
> +    /* At this stage vgic_reserve_virq can't fail */
> +    if ( is_hardware_domain(d) )
> +    {
> +        BUG_ON(!vgic_reserve_virq(d, timer_get_irq(TIMER_PHYS_SECURE_PPI)));
> +        BUG_ON(!vgic_reserve_virq(d, timer_get_irq(TIMER_PHYS_NONSECURE_PPI)));
> +        BUG_ON(!vgic_reserve_virq(d, timer_get_irq(TIMER_VIRT_PPI)));
> +    }
> +    else
> +    {
> +        BUG_ON(!vgic_reserve_virq(d, GUEST_TIMER_PHYS_S_PPI));
> +        BUG_ON(!vgic_reserve_virq(d, GUEST_TIMER_PHYS_NS_PPI));
> +        BUG_ON(!vgic_reserve_virq(d, GUEST_TIMER_VIRT_PPI));
> +    }
> +
>      return 0;
>  }
>  
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 8b7dd85..d302fc9 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -90,6 +90,7 @@ struct arch_domain
>          spinlock_t lock;
>          int ctlr;
>          int nr_spis; /* Number of SPIs */
> +        unsigned long *allocated_irqs; /* bitmap of IRQs allocated */
>          struct vgic_irq_rank *shared_irqs;
>          /*
>           * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 74d5a4e..9e167fa 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -199,6 +199,19 @@ extern int vgic_to_sgi(struct vcpu *v, register_t sgir,
>                         enum gic_sgi_mode irqmode, int virq,
>                         unsigned long vcpu_mask);
>  extern void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq);
> +
> +/* Reserve a specific guest vIRQ */
> +extern bool_t vgic_reserve_virq(struct domain *d, unsigned int virq);
> +
> +/*
> + * Allocate a guest VIRQ
> + *  - spi == 0 => allocate a PPI. It will be the same on every vCPU
> + *  - spi == 0 => allocate an SGI
> + */
> +extern int vgic_allocate_virq(struct domain *d, bool_t spi);
> +
> +extern void vgic_free_virq(struct domain *d, unsigned int irq);
> +
>  #endif /* __ASM_ARM_VGIC_H__ */
>  
>  /*
> -- 
> 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 Dec 15 15:32:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:32:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Xde-0000Xe-Se; Mon, 15 Dec 2014 15:32: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 1Y0Xdd-0000XZ-B4
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 15:32:45 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	15/BE-25727-C1FFE845; Mon, 15 Dec 2014 15:32:44 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418657562!13492554!1
X-Originating-IP: [66.165.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 3422 invoked from network); 15 Dec 2014 15:32:43 -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;
	15 Dec 2014 15:32:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204939536"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 10:32: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 1Y0XdX-0002uZ-GT;
	Mon, 15 Dec 2014 15:32:39 +0000
Date: Mon, 15 Dec 2014 15:32:15 +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: <1418395392-30460-3-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1412151527310.30971@kaball.uk.xensource.com>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
	<1418395392-30460-3-git-send-email-julien.grall@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.campbell@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	xen-devel@lists.xenproject.org, parth.dixit@linaro.org,
	christoffer.dall@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.6 2/4] xen/arm: vgic: Keep track of
 vIRQ used by a domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Dec 2014, Julien Grall wrote:
> While it's easy to know which hardware IRQ is assigned to a domain, there
> is no way to know which IRQ is emulated by Xen for a specific domain.
> 
> Introduce a bitmap to keep track of every vIRQ used by a domain. This
> will be used later to find free vIRQ for interrupt device assignment and
> emulated interrupt.
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> ---
>  xen/arch/arm/domain_build.c          |  6 +++
>  xen/arch/arm/platforms/xgene-storm.c |  4 ++
>  xen/arch/arm/vgic.c                  | 76 ++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/vtimer.c                | 15 +++++++
>  xen/include/asm-arm/domain.h         |  1 +
>  xen/include/asm-arm/vgic.h           | 13 ++++++
>  6 files changed, 115 insertions(+)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index de180d8..c238c8f 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -968,6 +968,12 @@ static int map_device(struct domain *d, struct dt_device_node *dev)
>          irq = res;
>  
>          DPRINT("irq %u = %u\n", i, irq);
> +        /*
> +         * Checking the return of vgic_reserve_virq is not
> +         * necessary. It should not fail except when we try to map
> +         * twice the IRQ. This can happen if the IRQ is shared
> +         */
> +        vgic_reserve_virq(d, irq);
>          res = route_irq_to_guest(d, irq, dt_node_name(dev));
>          if ( res )
>          {
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 0b3492d..416d42c 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -71,6 +71,10 @@ static int map_one_spi(struct domain *d, const char *what,
>  
>      printk("Additional IRQ %u (%s)\n", irq, what);
>  
> +    if ( !vgic_reserve_virq(d, irq) )
> +        printk("Failed to reserve the vIRQ %u on dom%d\n",
> +               irq, d->domain_id);
> +
>      ret = route_irq_to_guest(d, irq, what);
>      if ( ret )
>          printk("Failed to route %s to dom%d\n", what, d->domain_id);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 75cb7ff..dbfc259 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -87,6 +87,8 @@ int domain_vgic_init(struct domain *d)
>          return -ENODEV;
>      }
>  
> +    spin_lock_init(&d->arch.vgic.lock);

you should probably explain in the commit message the reason why you are
making changes to the vgic lock


>      d->arch.vgic.shared_irqs =
>          xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
>      if ( d->arch.vgic.shared_irqs == NULL )
> @@ -107,6 +109,15 @@ int domain_vgic_init(struct domain *d)
>  
>      d->arch.vgic.handler->domain_init(d);
>  
> +    d->arch.vgic.allocated_irqs =
> +        xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irqs(d)));
> +    if ( !d->arch.vgic.allocated_irqs )
> +        return -ENOMEM;
> +
> +    /* vIRQ0-15 (SGIs) are reserved */
> +    for (i = 0; i <= 15; i++)
> +        set_bit(i, d->arch.vgic.allocated_irqs);
> +
>      return 0;
>  }
>  
> @@ -119,6 +130,7 @@ void domain_vgic_free(struct domain *d)
>  {
>      xfree(d->arch.vgic.shared_irqs);
>      xfree(d->arch.vgic.pending_irqs);
> +    xfree(d->arch.vgic.allocated_irqs);
>  }
>  
>  int vcpu_vgic_init(struct vcpu *v)
> @@ -441,6 +453,70 @@ int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
>      return v->domain->arch.vgic.handler->emulate_sysreg(regs, hsr);
>  }
>  
> +bool_t vgic_reserve_virq(struct domain *d, unsigned int virq)
> +{
> +    bool_t reserved;
> +
> +    if ( virq >= vgic_num_irqs(d) )
> +        return 0;
> +
> +    spin_lock(&d->arch.vgic.lock);
> +    reserved = !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
> +    spin_unlock(&d->arch.vgic.lock);

test_and_set_bit is atomic, why do you need to take the lock?


> +    return reserved;
> +}
> +
> +int vgic_allocate_virq(struct domain *d, bool_t spi)
> +{
> +    int ret = -1;
> +    unsigned int virq;
> +
> +    spin_lock(&d->arch.vgic.lock);
> +    if ( !spi )
> +    {
> +        virq = find_first_zero_bit(d->arch.vgic.allocated_irqs, 32);
> +        if ( virq >= 32 )
> +            goto unlock;
> +    }
> +    else
> +    {
> +        virq = find_next_zero_bit(d->arch.vgic.allocated_irqs,
> +                                  32, vgic_num_irqs(d));
> +        if ( virq >= vgic_num_irqs(d) )
> +            goto unlock;
> +    }
> +
> +    set_bit(virq, d->arch.vgic.allocated_irqs);
> +    ret = virq;
> +
> +unlock:
> +    spin_unlock(&d->arch.vgic.lock);

you might be able to write this function without taking the lock too, by
using test_and_set_bit and retries:

retry:
    virq = find_first_zero_bit;
    if (test_and_set_bit(virq))
        goto retry;



> +    return ret;
> +}
> +
> +void vgic_free_virq(struct domain *d, unsigned int virq)
> +{
> +    unsigned int spi;
> +
> +    if ( is_hardware_domain(d) )
> +        return;
> +
> +    if ( virq < 32 && virq >= vgic_num_irqs(d) )
> +        return;
> +
> +    spi = virq - 32;
> +
> +    /* Taking the vGIC domain lock is not necessary. We don't care if
> +     * the bit is cleared a bit later. What only matters is bit to 1.
> +     *
> +     * With this solution vgic_allocate may fail to find an vIRQ if the
> +     * allocated_irqs is fully. But we don't care.
> +     */
> +    clear_bit(spi, d->arch.vgic.allocated_irqs);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 2e95ceb..de660bb 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -49,6 +49,21 @@ int domain_vtimer_init(struct domain *d)
>  {
>      d->arch.phys_timer_base.offset = NOW();
>      d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0);
> +
> +    /* At this stage vgic_reserve_virq can't fail */
> +    if ( is_hardware_domain(d) )
> +    {
> +        BUG_ON(!vgic_reserve_virq(d, timer_get_irq(TIMER_PHYS_SECURE_PPI)));
> +        BUG_ON(!vgic_reserve_virq(d, timer_get_irq(TIMER_PHYS_NONSECURE_PPI)));
> +        BUG_ON(!vgic_reserve_virq(d, timer_get_irq(TIMER_VIRT_PPI)));
> +    }
> +    else
> +    {
> +        BUG_ON(!vgic_reserve_virq(d, GUEST_TIMER_PHYS_S_PPI));
> +        BUG_ON(!vgic_reserve_virq(d, GUEST_TIMER_PHYS_NS_PPI));
> +        BUG_ON(!vgic_reserve_virq(d, GUEST_TIMER_VIRT_PPI));
> +    }
> +
>      return 0;
>  }
>  
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 8b7dd85..d302fc9 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -90,6 +90,7 @@ struct arch_domain
>          spinlock_t lock;
>          int ctlr;
>          int nr_spis; /* Number of SPIs */
> +        unsigned long *allocated_irqs; /* bitmap of IRQs allocated */
>          struct vgic_irq_rank *shared_irqs;
>          /*
>           * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 74d5a4e..9e167fa 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -199,6 +199,19 @@ extern int vgic_to_sgi(struct vcpu *v, register_t sgir,
>                         enum gic_sgi_mode irqmode, int virq,
>                         unsigned long vcpu_mask);
>  extern void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq);
> +
> +/* Reserve a specific guest vIRQ */
> +extern bool_t vgic_reserve_virq(struct domain *d, unsigned int virq);
> +
> +/*
> + * Allocate a guest VIRQ
> + *  - spi == 0 => allocate a PPI. It will be the same on every vCPU
> + *  - spi == 0 => allocate an SGI
> + */
> +extern int vgic_allocate_virq(struct domain *d, bool_t spi);
> +
> +extern void vgic_free_virq(struct domain *d, unsigned int irq);
> +
>  #endif /* __ASM_ARM_VGIC_H__ */
>  
>  /*
> -- 
> 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 Dec 15 15:36:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Xgz-0000ls-0T; Mon, 15 Dec 2014 15:36: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 1Y0Xgx-0000lm-Ke
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 15:36:11 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C8/00-25276-BEFFE845; Mon, 15 Dec 2014 15:36:11 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418657769!7685505!1
X-Originating-IP: [66.165.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 11913 invoked from network); 15 Dec 2014 15:36: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;
	15 Dec 2014 15:36:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204481503"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 10:35: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 1Y0Xgi-0002z0-Pi;
	Mon, 15 Dec 2014 15:35:56 +0000
Date: Mon, 15 Dec 2014 15:35:32 +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: <1418395392-30460-5-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1412151534320.30971@kaball.uk.xensource.com>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
	<1418395392-30460-5-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: ian.campbell@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	xen-devel@lists.xenproject.org, parth.dixit@linaro.org,
	christoffer.dall@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.6 4/4] xen/arm: Find automatically a
 PPI for the DOM0 event channel interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Dec 2014, Julien Grall wrote:
> Use the new vgic interface to know which virtual PPI is free and use it
> for the event channel code.
> 
> At the DOM0 creation time, Xen still don't know which vIRQ will be free.
> All the vIRQ will be reserved when we parse the device tree. So allocate
> when the hypervisor node is created.
> 
> It's safe to defer the allocation because no vIRQ can be injected as
> long as the vCPU is not online.
> 
> Also correct the check in arch_domain_create to use is_hardware_domain.
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> ---
>  xen/arch/arm/domain.c                | 13 ++++++++++---
>  xen/arch/arm/domain_build.c          | 10 ++++++++++
>  xen/arch/arm/platform.c              |  7 -------
>  xen/arch/arm/platforms/xgene-storm.c |  1 -
>  xen/include/asm-arm/platform.h       |  4 ----
>  5 files changed, 20 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 7221bc8..7d14377 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -543,10 +543,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = domain_vtimer_init(d)) != 0 )
>          goto fail;
>  
> -    if ( d->domain_id )
> +    /*
> +     * The hardware domain will get a PPI later in
> +     * arch/arm/domain_build.c  depending on the
> +     * interrupt map of the hardware.
> +     */
> +    if ( !is_hardware_domain(d) )
> +    {
>          d->arch.evtchn_irq = GUEST_EVTCHN_PPI;
> -    else
> -        d->arch.evtchn_irq = platform_dom0_evtchn_ppi();
> +        /* At this stage vgic_reserve_virq should never fail */
> +        BUG_ON(vgic_reserve_virq(d, GUEST_EVTCHN_PPI));
> +    }

Why do we still need this, if we have another vgic_allocate_virq call in
make_hypervisor_node? Wouldn't that work for DomUs too?


>      /*
>       * Virtual UART is only used by linux early printk and decompress code.
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index c238c8f..8dedc60 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -625,6 +625,16 @@ static int make_hypervisor_node(struct domain *d,
>          return res;
>  
>      /*
> +     * The allocation of the event channel IRQ has been deferred until
> +     * now. At this time, all PPIs use by DOM0 has been registered
> +     */
> +    res = vgic_allocate_virq(d, 0);
> +    if ( res < 0 )
> +        return -FDT_ERR_XEN(ENOSPC);
> +
> +    d->arch.evtchn_irq = res;
> +
> +    /*
>       * interrupts is evtchn upcall:
>       *  - Active-low level-sensitive
>       *  - All cpus
> diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
> index cb4cda8..d016797 100644
> --- a/xen/arch/arm/platform.c
> +++ b/xen/arch/arm/platform.c
> @@ -160,13 +160,6 @@ bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
>      return dt_match_node(blacklist, node);
>  }
>  
> -unsigned int platform_dom0_evtchn_ppi(void)
> -{
> -    if ( platform && platform->dom0_evtchn_ppi )
> -        return platform->dom0_evtchn_ppi;
> -    return GUEST_EVTCHN_PPI;
> -}
> -
>  void platform_dom0_gnttab(paddr_t *start, paddr_t *size)
>  {
>      if ( platform && platform->dom0_gnttab_size )
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 416d42c..b0808b8 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -232,7 +232,6 @@ PLATFORM_START(xgene_storm, "APM X-GENE STORM")
>      .quirks = xgene_storm_quirks,
>      .specific_mapping = xgene_storm_specific_mapping,
>  
> -    .dom0_evtchn_ppi = 24,
>      .dom0_gnttab_start = 0x1f800000,
>      .dom0_gnttab_size = 0x20000,
>  PLATFORM_END
> diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
> index eefaca6..4eba37b 100644
> --- a/xen/include/asm-arm/platform.h
> +++ b/xen/include/asm-arm/platform.h
> @@ -38,10 +38,6 @@ struct platform_desc {
>       */
>      const struct dt_device_match *blacklist_dev;
>      /*
> -     * The IRQ (PPI) to use to inject event channels to dom0.
> -     */
> -    unsigned int dom0_evtchn_ppi;
> -    /*
>       * The location of a region of physical address space which dom0
>       * can use for grant table mappings. If size is zero defaults to
>       * 0xb0000000-0xb0020000.
> -- 
> 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 Dec 15 15:36:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Xh0-0000m6-Cb; Mon, 15 Dec 2014 15:36: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 1Y0Xgy-0000lr-PI
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 15:36:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	51/CA-15461-CEFFE845; Mon, 15 Dec 2014 15:36:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418657770!15685880!1
X-Originating-IP: [66.165.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 5183 invoked from network); 15 Dec 2014 15:36:11 -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;
	15 Dec 2014 15:36:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204481491"
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.210.2; Mon, 15 Dec 2014 10:35: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 1Y0Xgh-0001gg-G0;
	Mon, 15 Dec 2014 15:35:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0Xgh-0004nI-8N;
	Mon, 15 Dec 2014 15:35:55 +0000
Date: Mon, 15 Dec 2014 15:35:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32361-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 13724
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 32361: 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="===============9040295745678283792=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9040295745678283792==
Content-Type: text/plain
Content-Length: 13525
Content-Transfer-Encoding: quoted-printable

flight 32361 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32361/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                    fail pass in 32316
 test-amd64-i386-rumpuserxen-i386 3 host-install(3) broken in 32316 pass in 32361
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 32316 pass in 32361
 test-amd64-amd64-xl           3 host-install(3)  broken in 32316 pass in 32361
 test-amd64-i386-xl            3 host-install(3)  broken in 32316 pass in 32361
 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 32316 pass in 32361
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 32316 pass in 32361
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 32316 pass in 32361
 test-amd64-i386-pair  4 host-install/dst_host(4) broken in 32316 pass in 32361

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-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-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-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-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-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-amd64-xl-qemut-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                  7e73a6e7f12ae080222c5d339799905de3443a6e
baseline version:
 xen                  60ce518a1b1caf2c1e4c1b203e87fb0b179ba687

------------------------------------------------------------
People who touched revisions under test:
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
  Mukesh Rathor <mukesh.rathor@oracle.com>
  Roger Pau Monn=C3=A9 <roger.pau@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                               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=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dxen-unstable
+ revision=3D7e73a6e7f12ae080222c5d339799905de3443a6e
+ . 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 xen-unstable 7e73a6e7f12ae080222c5d339799905de3443a6e
+ branch=3Dxen-unstable
+ revision=3D7e73a6e7f12ae080222c5d339799905de3443a6e
+ . 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=3Dxen
+ xenbranch=3Dxen-unstable
+ '[' xxen =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.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=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 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 7e73a6e7f12ae080222c5d339799905de3443a6e:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   60ce518..7e73a6e  7e73a6e7f12ae080222c5d339799905de3443a6e -> master


--===============9040295745678283792==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9040295745678283792==--

From xen-devel-bounces@lists.xen.org Mon Dec 15 15:36:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Xgz-0000ls-0T; Mon, 15 Dec 2014 15:36: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 1Y0Xgx-0000lm-Ke
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 15:36:11 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	C8/00-25276-BEFFE845; Mon, 15 Dec 2014 15:36:11 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418657769!7685505!1
X-Originating-IP: [66.165.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 11913 invoked from network); 15 Dec 2014 15:36: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;
	15 Dec 2014 15:36:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204481503"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 10:35: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 1Y0Xgi-0002z0-Pi;
	Mon, 15 Dec 2014 15:35:56 +0000
Date: Mon, 15 Dec 2014 15:35:32 +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: <1418395392-30460-5-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1412151534320.30971@kaball.uk.xensource.com>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
	<1418395392-30460-5-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: ian.campbell@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	xen-devel@lists.xenproject.org, parth.dixit@linaro.org,
	christoffer.dall@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.6 4/4] xen/arm: Find automatically a
 PPI for the DOM0 event channel interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Dec 2014, Julien Grall wrote:
> Use the new vgic interface to know which virtual PPI is free and use it
> for the event channel code.
> 
> At the DOM0 creation time, Xen still don't know which vIRQ will be free.
> All the vIRQ will be reserved when we parse the device tree. So allocate
> when the hypervisor node is created.
> 
> It's safe to defer the allocation because no vIRQ can be injected as
> long as the vCPU is not online.
> 
> Also correct the check in arch_domain_create to use is_hardware_domain.
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> ---
>  xen/arch/arm/domain.c                | 13 ++++++++++---
>  xen/arch/arm/domain_build.c          | 10 ++++++++++
>  xen/arch/arm/platform.c              |  7 -------
>  xen/arch/arm/platforms/xgene-storm.c |  1 -
>  xen/include/asm-arm/platform.h       |  4 ----
>  5 files changed, 20 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 7221bc8..7d14377 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -543,10 +543,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = domain_vtimer_init(d)) != 0 )
>          goto fail;
>  
> -    if ( d->domain_id )
> +    /*
> +     * The hardware domain will get a PPI later in
> +     * arch/arm/domain_build.c  depending on the
> +     * interrupt map of the hardware.
> +     */
> +    if ( !is_hardware_domain(d) )
> +    {
>          d->arch.evtchn_irq = GUEST_EVTCHN_PPI;
> -    else
> -        d->arch.evtchn_irq = platform_dom0_evtchn_ppi();
> +        /* At this stage vgic_reserve_virq should never fail */
> +        BUG_ON(vgic_reserve_virq(d, GUEST_EVTCHN_PPI));
> +    }

Why do we still need this, if we have another vgic_allocate_virq call in
make_hypervisor_node? Wouldn't that work for DomUs too?


>      /*
>       * Virtual UART is only used by linux early printk and decompress code.
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index c238c8f..8dedc60 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -625,6 +625,16 @@ static int make_hypervisor_node(struct domain *d,
>          return res;
>  
>      /*
> +     * The allocation of the event channel IRQ has been deferred until
> +     * now. At this time, all PPIs use by DOM0 has been registered
> +     */
> +    res = vgic_allocate_virq(d, 0);
> +    if ( res < 0 )
> +        return -FDT_ERR_XEN(ENOSPC);
> +
> +    d->arch.evtchn_irq = res;
> +
> +    /*
>       * interrupts is evtchn upcall:
>       *  - Active-low level-sensitive
>       *  - All cpus
> diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
> index cb4cda8..d016797 100644
> --- a/xen/arch/arm/platform.c
> +++ b/xen/arch/arm/platform.c
> @@ -160,13 +160,6 @@ bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
>      return dt_match_node(blacklist, node);
>  }
>  
> -unsigned int platform_dom0_evtchn_ppi(void)
> -{
> -    if ( platform && platform->dom0_evtchn_ppi )
> -        return platform->dom0_evtchn_ppi;
> -    return GUEST_EVTCHN_PPI;
> -}
> -
>  void platform_dom0_gnttab(paddr_t *start, paddr_t *size)
>  {
>      if ( platform && platform->dom0_gnttab_size )
> diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
> index 416d42c..b0808b8 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -232,7 +232,6 @@ PLATFORM_START(xgene_storm, "APM X-GENE STORM")
>      .quirks = xgene_storm_quirks,
>      .specific_mapping = xgene_storm_specific_mapping,
>  
> -    .dom0_evtchn_ppi = 24,
>      .dom0_gnttab_start = 0x1f800000,
>      .dom0_gnttab_size = 0x20000,
>  PLATFORM_END
> diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
> index eefaca6..4eba37b 100644
> --- a/xen/include/asm-arm/platform.h
> +++ b/xen/include/asm-arm/platform.h
> @@ -38,10 +38,6 @@ struct platform_desc {
>       */
>      const struct dt_device_match *blacklist_dev;
>      /*
> -     * The IRQ (PPI) to use to inject event channels to dom0.
> -     */
> -    unsigned int dom0_evtchn_ppi;
> -    /*
>       * The location of a region of physical address space which dom0
>       * can use for grant table mappings. If size is zero defaults to
>       * 0xb0000000-0xb0020000.
> -- 
> 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 Dec 15 15:36:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Xh0-0000m6-Cb; Mon, 15 Dec 2014 15:36: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 1Y0Xgy-0000lr-PI
	for xen-devel@lists.xensource.com; Mon, 15 Dec 2014 15:36:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	51/CA-15461-CEFFE845; Mon, 15 Dec 2014 15:36:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418657770!15685880!1
X-Originating-IP: [66.165.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 5183 invoked from network); 15 Dec 2014 15:36:11 -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;
	15 Dec 2014 15:36:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204481491"
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.210.2; Mon, 15 Dec 2014 10:35: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 1Y0Xgh-0001gg-G0;
	Mon, 15 Dec 2014 15:35:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0Xgh-0004nI-8N;
	Mon, 15 Dec 2014 15:35:55 +0000
Date: Mon, 15 Dec 2014 15:35:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32361-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 13724
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 32361: 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="===============9040295745678283792=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9040295745678283792==
Content-Type: text/plain
Content-Length: 13525
Content-Transfer-Encoding: quoted-printable

flight 32361 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32361/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                    fail pass in 32316
 test-amd64-i386-rumpuserxen-i386 3 host-install(3) broken in 32316 pass in 32361
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 32316 pass in 32361
 test-amd64-amd64-xl           3 host-install(3)  broken in 32316 pass in 32361
 test-amd64-i386-xl            3 host-install(3)  broken in 32316 pass in 32361
 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 32316 pass in 32361
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 32316 pass in 32361
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 32316 pass in 32361
 test-amd64-i386-pair  4 host-install/dst_host(4) broken in 32316 pass in 32361

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-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-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-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-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-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-amd64-xl-qemut-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                  7e73a6e7f12ae080222c5d339799905de3443a6e
baseline version:
 xen                  60ce518a1b1caf2c1e4c1b203e87fb0b179ba687

------------------------------------------------------------
People who touched revisions under test:
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
  Mukesh Rathor <mukesh.rathor@oracle.com>
  Roger Pau Monn=C3=A9 <roger.pau@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                               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=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dxen-unstable
+ revision=3D7e73a6e7f12ae080222c5d339799905de3443a6e
+ . 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 xen-unstable 7e73a6e7f12ae080222c5d339799905de3443a6e
+ branch=3Dxen-unstable
+ revision=3D7e73a6e7f12ae080222c5d339799905de3443a6e
+ . 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=3Dxen
+ xenbranch=3Dxen-unstable
+ '[' xxen =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.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=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 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 7e73a6e7f12ae080222c5d339799905de3443a6e:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   60ce518..7e73a6e  7e73a6e7f12ae080222c5d339799905de3443a6e -> master


--===============9040295745678283792==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9040295745678283792==--

From xen-devel-bounces@lists.xen.org Mon Dec 15 15:50:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Xue-0001LH-R6; Mon, 15 Dec 2014 15:50:20 +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 1Y0Xud-0001LC-BE
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 15:50:19 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1C/E8-25276-A330F845; Mon, 15 Dec 2014 15:50:18 +0000
X-Env-Sender: xen-devel-bugs@bugs.xenproject.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418658617!8416086!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28986 invoked from network); 15 Dec 2014 15:50:18 -0000
Received: from bugs.xenproject.org (HELO bugs.xenproject.org) (50.56.82.209)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 15 Dec 2014 15:50:18 -0000
Received: from xen-devel-bugs by bugs.xenproject.org with local (Exim 4.80)
	(envelope-from <xen-devel-bugs@bugs.xenproject.org>)
	id 1Y0Y42-0006Jt-1l; Mon, 15 Dec 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: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Message-ID: <control-reply-1418659201.24295@bugs.xenproject.org>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
	<20141215154710.GC8049@zion.uk.xensource.com>
In-Reply-To: <20141215154710.GC8049@zion.uk.xensource.com>
X-Emesinae-Message: control
X-Emesinae-Control-From: Wei Liu <wei.liu2@citrix.com>
X-Emesinae-Control-Number-Commands: 3
Date: Mon, 15 Dec 2014 16:00:02 +0000
Subject: [Xen-devel] Processed: Re: [PATCH for 4.5] libxl: Tell qemu to use
 raw format when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 #47 rooted at `<20141215154710.GC8049@zion.uk.xensource.com>'
Title: `Re: [PATCH for 4.5] libxl: Tell qemu to use raw format when using a tapdisk'
> title it CDROM backend ignored and always treated as file
Set title for #47 to `CDROM backend ignored and always treated as file'
> thanks
Finished processing.

Modified/created Bugs:
 - 47: http://bugs.xenproject.org/xen/bug/47 (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 Mon Dec 15 15:50:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Xue-0001LH-R6; Mon, 15 Dec 2014 15:50:20 +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 1Y0Xud-0001LC-BE
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 15:50:19 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1C/E8-25276-A330F845; Mon, 15 Dec 2014 15:50:18 +0000
X-Env-Sender: xen-devel-bugs@bugs.xenproject.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418658617!8416086!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28986 invoked from network); 15 Dec 2014 15:50:18 -0000
Received: from bugs.xenproject.org (HELO bugs.xenproject.org) (50.56.82.209)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 15 Dec 2014 15:50:18 -0000
Received: from xen-devel-bugs by bugs.xenproject.org with local (Exim 4.80)
	(envelope-from <xen-devel-bugs@bugs.xenproject.org>)
	id 1Y0Y42-0006Jt-1l; Mon, 15 Dec 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: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Message-ID: <control-reply-1418659201.24295@bugs.xenproject.org>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
	<20141215154710.GC8049@zion.uk.xensource.com>
In-Reply-To: <20141215154710.GC8049@zion.uk.xensource.com>
X-Emesinae-Message: control
X-Emesinae-Control-From: Wei Liu <wei.liu2@citrix.com>
X-Emesinae-Control-Number-Commands: 3
Date: Mon, 15 Dec 2014 16:00:02 +0000
Subject: [Xen-devel] Processed: Re: [PATCH for 4.5] libxl: Tell qemu to use
 raw format when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 #47 rooted at `<20141215154710.GC8049@zion.uk.xensource.com>'
Title: `Re: [PATCH for 4.5] libxl: Tell qemu to use raw format when using a tapdisk'
> title it CDROM backend ignored and always treated as file
Set title for #47 to `CDROM backend ignored and always treated as file'
> thanks
Finished processing.

Modified/created Bugs:
 - 47: http://bugs.xenproject.org/xen/bug/47 (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 Mon Dec 15 15:56:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15: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 1Y0Y04-0001ea-ND; Mon, 15 Dec 2014 15:55:56 +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 1Y0Y03-0001eQ-Ou
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 15:55:55 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	1D/DF-02707-A840F845; Mon, 15 Dec 2014 15:55:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418658953!13426943!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24844 invoked from network); 15 Dec 2014 15:55:54 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-2.tower-206.messagelabs.com with SMTP;
	15 Dec 2014 15:55:54 -0000
X-TM-IMSS-Message-ID: <99c138c3000cad27@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 99c138c3000cad27 ;
	Mon, 15 Dec 2014 10:56:01 -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 sBFFtQqR021648; 
	Mon, 15 Dec 2014 10:55:36 -0500
Message-ID: <548F046F.9030208@tycho.nsa.gov>
Date: Mon, 15 Dec 2014 10: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:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Quan Xu <quan.xu@intel.com>, xen-devel@lists.xen.org
References: <1418558993-13681-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1418558993-13681-1-git-send-email-quan.xu@intel.com>
Cc: samuel.thibault@ens-lyon.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 09/12] vTPM/TPM2: Support '--tpm2' extra
	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

On 12/14/2014 07:09 AM, Quan Xu wrote:
> Make vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
> Add:
> ..
>       extra="--tpm2"
> ..
> to launch vtpm-stubdom domain on TPM 2.0, ignore it on TPM 1.x. for
> example,
> vtpm-stubdom domain configuration on TPM 2.0:
>
> kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
> memory=16
> disk=["file:/var/scale/vdisk/vmgr,hda,w"]
> name="vtpmmgr"
> iomem=["fed40,5"]
> extra="--tpm2"
>
> vtpm-stubdom domain configuration on TPM 1.x:
>
> kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
> memory=16
> disk=["file:/var/scale/vdisk/vmgr,hda,w"]
> name="vtpmmgr"
> iomem=["fed40,5"]

This would be useful to add to docs/misc/vtpmmgr.txt; it is difficult
to find this documentation later if it is only present the commit
message.  Also, existing command line options are of the form "tpm2"
or "tpm2=1" rather than "--tpm2"; it would be nice if new options
remained consistent.

-- 
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 Dec 15 15:56:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15: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 1Y0Y06-0001eh-3y; Mon, 15 Dec 2014 15:55:58 +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 1Y0Y04-0001eR-Ac
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 15:55:56 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	94/D1-27584-B840F845; Mon, 15 Dec 2014 15:55:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418658954!9314571!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4988 invoked from network); 15 Dec 2014 15:55:55 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-11.tower-206.messagelabs.com with SMTP;
	15 Dec 2014 15:55:55 -0000
X-TM-IMSS-Message-ID: <08f3fd8f000092fe@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 08f3fd8f000092fe ;
	Mon, 15 Dec 2014 10:56:28 -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 sBFFtXLD021650; 
	Mon, 15 Dec 2014 10:55:43 -0500
Message-ID: <548F0476.6000408@tycho.nsa.gov>
Date: Mon, 15 Dec 2014 10:55: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: Quan Xu <quan.xu@intel.com>, xen-devel@lists.xen.org
References: <1418558998-13755-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1418558998-13755-1-git-send-email-quan.xu@intel.com>
Cc: samuel.thibault@ens-lyon.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 11/12] vTPM/TPM2: Bind group keys and
 sectors data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/14/2014 07:09 AM, Quan Xu wrote:
[...]
> +        /*TPM 2.0 bind | TPM 1.x seal*/
> +        if (hw_is_tpm2()) {
> +            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
> +        } else {
> +            dst->pcr_selection = src->seals[i].pcr_selection;
> +            memcpy(&dst->digest_release, &src->seals[i].digest_release, 20);
> +            TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
> +            TPM_disk_seal(dst, &sblob, sizeof(sblob));
> +        }

It appears that the secrets for the vTPMs are only being bound to the
presence of the physical TPM and not the measurements of the hypervisor
and other TCB components.  This does not provide as much security as it
did for TPM 1.2: an attacker with access to the boot disk can boot into
a compromised environment and extract the vTPM keys and disk images.

The TPM2_Create/TPM2_Unseal operations should be capable of performing
the same functionality.  If only SHA1 PCRs are used, they should be able
to be drop-in replacements, but supporting other hash algorithms may be
a feature that users who have a TPM2 will want.

-- 
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 Dec 15 15:56:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15: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 1Y0Y06-0001eh-3y; Mon, 15 Dec 2014 15:55:58 +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 1Y0Y04-0001eR-Ac
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 15:55:56 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	94/D1-27584-B840F845; Mon, 15 Dec 2014 15:55:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418658954!9314571!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4988 invoked from network); 15 Dec 2014 15:55:55 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-11.tower-206.messagelabs.com with SMTP;
	15 Dec 2014 15:55:55 -0000
X-TM-IMSS-Message-ID: <08f3fd8f000092fe@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 08f3fd8f000092fe ;
	Mon, 15 Dec 2014 10:56:28 -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 sBFFtXLD021650; 
	Mon, 15 Dec 2014 10:55:43 -0500
Message-ID: <548F0476.6000408@tycho.nsa.gov>
Date: Mon, 15 Dec 2014 10:55: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: Quan Xu <quan.xu@intel.com>, xen-devel@lists.xen.org
References: <1418558998-13755-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1418558998-13755-1-git-send-email-quan.xu@intel.com>
Cc: samuel.thibault@ens-lyon.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 11/12] vTPM/TPM2: Bind group keys and
 sectors data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/14/2014 07:09 AM, Quan Xu wrote:
[...]
> +        /*TPM 2.0 bind | TPM 1.x seal*/
> +        if (hw_is_tpm2()) {
> +            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
> +        } else {
> +            dst->pcr_selection = src->seals[i].pcr_selection;
> +            memcpy(&dst->digest_release, &src->seals[i].digest_release, 20);
> +            TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
> +            TPM_disk_seal(dst, &sblob, sizeof(sblob));
> +        }

It appears that the secrets for the vTPMs are only being bound to the
presence of the physical TPM and not the measurements of the hypervisor
and other TCB components.  This does not provide as much security as it
did for TPM 1.2: an attacker with access to the boot disk can boot into
a compromised environment and extract the vTPM keys and disk images.

The TPM2_Create/TPM2_Unseal operations should be capable of performing
the same functionality.  If only SHA1 PCRs are used, they should be able
to be drop-in replacements, but supporting other hash algorithms may be
a feature that users who have a TPM2 will want.

-- 
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 Dec 15 15:56:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15: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 1Y0Y04-0001ea-ND; Mon, 15 Dec 2014 15:55:56 +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 1Y0Y03-0001eQ-Ou
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 15:55:55 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	1D/DF-02707-A840F845; Mon, 15 Dec 2014 15:55:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418658953!13426943!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24844 invoked from network); 15 Dec 2014 15:55:54 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO emvm-gh1-uea09.nsa.gov)
	(63.239.67.10) by server-2.tower-206.messagelabs.com with SMTP;
	15 Dec 2014 15:55:54 -0000
X-TM-IMSS-Message-ID: <99c138c3000cad27@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 99c138c3000cad27 ;
	Mon, 15 Dec 2014 10:56:01 -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 sBFFtQqR021648; 
	Mon, 15 Dec 2014 10:55:36 -0500
Message-ID: <548F046F.9030208@tycho.nsa.gov>
Date: Mon, 15 Dec 2014 10: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:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Quan Xu <quan.xu@intel.com>, xen-devel@lists.xen.org
References: <1418558993-13681-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1418558993-13681-1-git-send-email-quan.xu@intel.com>
Cc: samuel.thibault@ens-lyon.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 09/12] vTPM/TPM2: Support '--tpm2' extra
	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

On 12/14/2014 07:09 AM, Quan Xu wrote:
> Make vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
> Add:
> ..
>       extra="--tpm2"
> ..
> to launch vtpm-stubdom domain on TPM 2.0, ignore it on TPM 1.x. for
> example,
> vtpm-stubdom domain configuration on TPM 2.0:
>
> kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
> memory=16
> disk=["file:/var/scale/vdisk/vmgr,hda,w"]
> name="vtpmmgr"
> iomem=["fed40,5"]
> extra="--tpm2"
>
> vtpm-stubdom domain configuration on TPM 1.x:
>
> kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
> memory=16
> disk=["file:/var/scale/vdisk/vmgr,hda,w"]
> name="vtpmmgr"
> iomem=["fed40,5"]

This would be useful to add to docs/misc/vtpmmgr.txt; it is difficult
to find this documentation later if it is only present the commit
message.  Also, existing command line options are of the form "tpm2"
or "tpm2=1" rather than "--tpm2"; it would be nice if new options
remained consistent.

-- 
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 Dec 15 15:57:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:57:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Y1X-0001qD-Px; Mon, 15 Dec 2014 15:57:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Aravind.Gopalakrishnan@amd.com>) id 1Y0Y1W-0001q1-9u
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 15:57:26 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F8/CD-09842-5E40F845; Mon, 15 Dec 2014 15:57:25 +0000
X-Env-Sender: Aravind.Gopalakrishnan@amd.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418659043!15745507!1
X-Originating-IP: [157.56.111.146]
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 17673 invoked from network); 15 Dec 2014 15:57:25 -0000
Received: from mail-bn1bon0146.outbound.protection.outlook.com (HELO
	na01-bn1-obe.outbound.protection.outlook.com) (157.56.111.146)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Dec 2014 15:57:25 -0000
Received: from BY2PR02CA0040.namprd02.prod.outlook.com (10.141.216.30) by
	BY2PR02MB203.namprd02.prod.outlook.com (10.242.232.25) with Microsoft
	SMTP Server (TLS) id 15.1.31.17; Mon, 15 Dec 2014 15:57:23 +0000
Received: from BY2FFO11FD034.protection.gbl (2a01:111:f400:7c0c::160) by
	BY2PR02CA0040.outlook.office365.com (2a01:111:e400:2c40::30) with
	Microsoft
	SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Mon, 15 Dec 2014
	15:57:22 +0000
Received: from atltwp01.amd.com (165.204.84.221) by
	BY2FFO11FD034.mail.protection.outlook.com (10.1.14.219) with Microsoft
	SMTP Server id 15.1.26.17 via Frontend Transport;
	Mon, 15 Dec 2014 15:57:22 +0000
X-WSS-ID: 0NGMSBK-07-A24-02
X-M-MSG: 
Received: from satlvexedge01.amd.com (satlvexedge01.amd.com [10.177.96.28])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by atltwp01.amd.com (Axway MailGate 5.3.1) with ESMTPS id 2B6AC12C0011; 
	Mon, 15 Dec 2014 09:57:20 -0600 (CST)
Received: from SATLEXDAG03.amd.com (10.181.40.7) by satlvexedge01.amd.com
	(10.177.96.28) with Microsoft SMTP Server (TLS) id 14.3.195.1;
	Mon, 15 Dec 2014 09:57:28 -0600
Received: from [127.0.0.1] (10.180.168.240) by satlexdag03.amd.com
	(10.181.40.7) with Microsoft SMTP Server (TLS) id 14.3.195.1;
	Mon, 15 Dec 2014 10:57:19 -0500
Message-ID: <548F04DC.3060306@amd.com>
Date: Mon, 15 Dec 2014 09:57:16 -0600
From: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.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: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <548EB4E9020000780004F7BE@mail.emea.novell.com>
	<548EC61B.6000806@citrix.com>
In-Reply-To: <548EC61B.6000806@citrix.com>
X-Originating-IP: [10.180.168.240]
X-EOPAttributedMessage: 0
Received-SPF: None (protection.outlook.com: amd.com does not designate
	permitted sender hosts)
X-Forefront-Antispam-Report: CIP:165.204.84.221; CTRY:US; IPV:NLI; EFV:NLI;
	SFV:NSPM;
	SFS:(10019020)(6009001)(428002)(189002)(479174004)(199003)(377454003)(24454002)(51704005)(33656002)(80316001)(86362001)(87266999)(92566001)(65816999)(77096005)(23746002)(76176999)(105586002)(97736003)(83506001)(50986999)(87936001)(84676001)(54356999)(19580405001)(64706001)(19580395003)(65956001)(47776003)(101416001)(64126003)(46102003)(68736005)(120916001)(4396001)(20776003)(36756003)(50466002)(62966003)(99396003)(31966008)(21056001)(77156002)(106466001)(107046002)(7059030);
	DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR02MB203; H:atltwp01.amd.com;
	FPR:; SPF:None; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1;
	LANG:en; 
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR02MB203;
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601003);
	SRVR:BY2PR02MB203; 
X-Forefront-PRVS: 04267075BD
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY2PR02MB203;
X-OriginatorOrg: amd4.onmicrosoft.com
Cc: Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/AMD-ucode: correct multiple container
 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 12/15/2014 5:29 AM, Andrew Cooper wrote:
> On 15/12/14 09:16, Jan Beulich wrote:
>> Avoid emitting an error message referring to an incorrect or corrupt
>> container file just because no entry was found for the running CPU.
>>
>> Additionally switch the order of data validation and consumption in
>> cpu_request_microcode()'s first loop, and also check the types of
>> skipped blocks in container_fast_forward().
>>
>> Signed-off-by: Jan Beulich<jbeulich@suse.com>
>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
>

Reviewed-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 15:57:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 15:57:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Y1X-0001qD-Px; Mon, 15 Dec 2014 15:57:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Aravind.Gopalakrishnan@amd.com>) id 1Y0Y1W-0001q1-9u
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 15:57:26 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F8/CD-09842-5E40F845; Mon, 15 Dec 2014 15:57:25 +0000
X-Env-Sender: Aravind.Gopalakrishnan@amd.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418659043!15745507!1
X-Originating-IP: [157.56.111.146]
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 17673 invoked from network); 15 Dec 2014 15:57:25 -0000
Received: from mail-bn1bon0146.outbound.protection.outlook.com (HELO
	na01-bn1-obe.outbound.protection.outlook.com) (157.56.111.146)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Dec 2014 15:57:25 -0000
Received: from BY2PR02CA0040.namprd02.prod.outlook.com (10.141.216.30) by
	BY2PR02MB203.namprd02.prod.outlook.com (10.242.232.25) with Microsoft
	SMTP Server (TLS) id 15.1.31.17; Mon, 15 Dec 2014 15:57:23 +0000
Received: from BY2FFO11FD034.protection.gbl (2a01:111:f400:7c0c::160) by
	BY2PR02CA0040.outlook.office365.com (2a01:111:e400:2c40::30) with
	Microsoft
	SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Mon, 15 Dec 2014
	15:57:22 +0000
Received: from atltwp01.amd.com (165.204.84.221) by
	BY2FFO11FD034.mail.protection.outlook.com (10.1.14.219) with Microsoft
	SMTP Server id 15.1.26.17 via Frontend Transport;
	Mon, 15 Dec 2014 15:57:22 +0000
X-WSS-ID: 0NGMSBK-07-A24-02
X-M-MSG: 
Received: from satlvexedge01.amd.com (satlvexedge01.amd.com [10.177.96.28])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by atltwp01.amd.com (Axway MailGate 5.3.1) with ESMTPS id 2B6AC12C0011; 
	Mon, 15 Dec 2014 09:57:20 -0600 (CST)
Received: from SATLEXDAG03.amd.com (10.181.40.7) by satlvexedge01.amd.com
	(10.177.96.28) with Microsoft SMTP Server (TLS) id 14.3.195.1;
	Mon, 15 Dec 2014 09:57:28 -0600
Received: from [127.0.0.1] (10.180.168.240) by satlexdag03.amd.com
	(10.181.40.7) with Microsoft SMTP Server (TLS) id 14.3.195.1;
	Mon, 15 Dec 2014 10:57:19 -0500
Message-ID: <548F04DC.3060306@amd.com>
Date: Mon, 15 Dec 2014 09:57:16 -0600
From: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.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: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
References: <548EB4E9020000780004F7BE@mail.emea.novell.com>
	<548EC61B.6000806@citrix.com>
In-Reply-To: <548EC61B.6000806@citrix.com>
X-Originating-IP: [10.180.168.240]
X-EOPAttributedMessage: 0
Received-SPF: None (protection.outlook.com: amd.com does not designate
	permitted sender hosts)
X-Forefront-Antispam-Report: CIP:165.204.84.221; CTRY:US; IPV:NLI; EFV:NLI;
	SFV:NSPM;
	SFS:(10019020)(6009001)(428002)(189002)(479174004)(199003)(377454003)(24454002)(51704005)(33656002)(80316001)(86362001)(87266999)(92566001)(65816999)(77096005)(23746002)(76176999)(105586002)(97736003)(83506001)(50986999)(87936001)(84676001)(54356999)(19580405001)(64706001)(19580395003)(65956001)(47776003)(101416001)(64126003)(46102003)(68736005)(120916001)(4396001)(20776003)(36756003)(50466002)(62966003)(99396003)(31966008)(21056001)(77156002)(106466001)(107046002)(7059030);
	DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR02MB203; H:atltwp01.amd.com;
	FPR:; SPF:None; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1;
	LANG:en; 
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR02MB203;
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601003);
	SRVR:BY2PR02MB203; 
X-Forefront-PRVS: 04267075BD
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY2PR02MB203;
X-OriginatorOrg: amd4.onmicrosoft.com
Cc: Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/AMD-ucode: correct multiple container
 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 12/15/2014 5:29 AM, Andrew Cooper wrote:
> On 15/12/14 09:16, Jan Beulich wrote:
>> Avoid emitting an error message referring to an incorrect or corrupt
>> container file just because no entry was found for the running CPU.
>>
>> Additionally switch the order of data validation and consumption in
>> cpu_request_microcode()'s first loop, and also check the types of
>> skipped blocks in container_fast_forward().
>>
>> Signed-off-by: Jan Beulich<jbeulich@suse.com>
>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
>

Reviewed-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 16:02:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16:02:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Y5f-0002Ts-G2; Mon, 15 Dec 2014 16:01: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 1Y0Y5e-0002Tn-FW
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 16:01:42 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	49/EF-02712-5E50F845; Mon, 15 Dec 2014 16:01:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418659300!15199789!1
X-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 19205 invoked from network); 15 Dec 2014 16:01:41 -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; 15 Dec 2014 16:01:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 16:01:40 +0000
Message-Id: <548F13F0020000780004FAA0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 16:01:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
	<548EB672020000780004F7D2@mail.emea.novell.com>
	<alpine.DEB.2.02.1412151521400.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412151521400.30971@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>, "keir@xen.org" <keir@xen.org>,
	TimDeegan <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 16:22, <stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
>> >>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
>> > yes, definitely host RAM is the upper limit, and what I'm concerning here
>> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
>> > resource, w/o collision with other PFN reservation usage (ballooning
>> > should be fine since it's operating existing RAM ranges in dom0 e820
>> > table).
>> 
>> I don't think ballooning is restricted to the regions named RAM in
>> Dom0's E820 table (at least it shouldn't be, and wasn't in the
>> classic Xen kernels).
> 
> Could you please elaborate more on this? It seems counter-intuitive at best.

I don't see what's counter-intuitive here. How can the hypervisor
(Dom0) or tool stack (DomU) know what ballooning intentions a
guest kernel may have? It's solely the guest kernel's responsibility
to make sure its ballooning activities don't collide with anything
else address-wise.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 16:02:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16:02:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0Y5f-0002Ts-G2; Mon, 15 Dec 2014 16:01: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 1Y0Y5e-0002Tn-FW
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 16:01:42 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	49/EF-02712-5E50F845; Mon, 15 Dec 2014 16:01:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418659300!15199789!1
X-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 19205 invoked from network); 15 Dec 2014 16:01:41 -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; 15 Dec 2014 16:01:41 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 16:01:40 +0000
Message-Id: <548F13F0020000780004FAA0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 16:01:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
	<548EB672020000780004F7D2@mail.emea.novell.com>
	<alpine.DEB.2.02.1412151521400.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412151521400.30971@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>, "keir@xen.org" <keir@xen.org>,
	TimDeegan <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 16:22, <stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
>> >>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
>> > yes, definitely host RAM is the upper limit, and what I'm concerning here
>> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
>> > resource, w/o collision with other PFN reservation usage (ballooning
>> > should be fine since it's operating existing RAM ranges in dom0 e820
>> > table).
>> 
>> I don't think ballooning is restricted to the regions named RAM in
>> Dom0's E820 table (at least it shouldn't be, and wasn't in the
>> classic Xen kernels).
> 
> Could you please elaborate more on this? It seems counter-intuitive at best.

I don't see what's counter-intuitive here. How can the hypervisor
(Dom0) or tool stack (DomU) know what ballooning intentions a
guest kernel may have? It's solely the guest kernel's responsibility
to make sure its ballooning activities don't collide with anything
else address-wise.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 16:07:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16:07:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0YB9-0002n5-Jh; Mon, 15 Dec 2014 16:07:23 +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 1Y0YB7-0002n0-Sj
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 16:07:21 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	84/22-29352-9370F845; Mon, 15 Dec 2014 16:07:21 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418659640!8148089!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24198 invoked from network); 15 Dec 2014 16:07:20 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 16:07:20 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so9574355wiw.4
	for <xen-devel@lists.xenproject.org>;
	Mon, 15 Dec 2014 08:07: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=Df2TIVDTIUvYtQmMdSHPYDAlsWJuZS9f0PVDn6JZtnI=;
	b=KpeYjcMPI85bBb5uq7AV9Q6odOZs+WAuXPueIbzDboNU3x/X4+TJRi1/YjzWg5LYDb
	itF7XTLZynxD3CI3e72U6OJ10SA1uG+Qwo7329LUbIyF30LFuCTj4mxC52D64lwnMq48
	QCGx9L3ADHoLm2PvbTQrpCUdGBHhhK9cx3pWUvpu3xDgDFIdohCPwNr5BOD04rIhHHBb
	TQUYF+3S7r6BqDSv7GbQf89fmf1C8jgnSO+yiN7roCuUHEbsK4lQkHYPROfUlivSDet4
	W/j99WxNL2oxP+up/3mDngYu6lyDoK5DIOGR8+ttjCUu71NGE8PbkxRHmMt9tSBlT8PS
	+rvg==
X-Gm-Message-State: ALoCoQknx7kTuD/61AHjN5wLfwtmRcuoFj1SBYZShkCcUw4zudeTnUiFHYNQT86GYdqV04+ByMLy
X-Received: by 10.180.94.230 with SMTP id df6mr33181850wib.25.1418659639989;
	Mon, 15 Dec 2014 08:07:19 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	nj9sm13764777wic.10.2014.12.15.08.07.18 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 15 Dec 2014 08:07:19 -0800 (PST)
Message-ID: <548F0733.2020108@linaro.org>
Date: Mon, 15 Dec 2014 16:07:15 +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>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
	<1418395392-30460-3-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1412151527310.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412151527310.30971@kaball.uk.xensource.com>
Cc: ian.campbell@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	xen-devel@lists.xenproject.org, parth.dixit@linaro.org,
	christoffer.dall@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.6 2/4] xen/arm: vgic: Keep track of
 vIRQ used by a domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 15/12/14 15:32, Stefano Stabellini wrote:
> On Fri, 12 Dec 2014, Julien Grall wrote:
>> +    spin_lock_init(&d->arch.vgic.lock);
> 
> you should probably explain in the commit message the reason why you are
> making changes to the vgic lock

Actually the domain vgic lock was never used. Only the per-vcpu vgic
lock was in used.

So I don't make any change to the vgic lock. If I don't use it, I will
add a patch to drop it.

>> @@ -441,6 +453,70 @@ int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
>>      return v->domain->arch.vgic.handler->emulate_sysreg(regs, hsr);
>>  }
>>  
>> +bool_t vgic_reserve_virq(struct domain *d, unsigned int virq)
>> +{
>> +    bool_t reserved;
>> +
>> +    if ( virq >= vgic_num_irqs(d) )
>> +        return 0;
>> +
>> +    spin_lock(&d->arch.vgic.lock);
>> +    reserved = !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
>> +    spin_unlock(&d->arch.vgic.lock);
> 
> test_and_set_bit is atomic, why do you need to take the lock?

To avoid race condition with vgic_allocate_virq.

Anyway, I will dropped it with your suggestion to implement
vgic_allocate_virq without lock.

[..]

>> +int vgic_allocate_virq(struct domain *d, bool_t spi)
>> +{
>> +    int ret = -1;
>> +    unsigned int virq;
>> +
>> +    spin_lock(&d->arch.vgic.lock);
>> +    if ( !spi )
>> +    {
>> +        virq = find_first_zero_bit(d->arch.vgic.allocated_irqs, 32);
>> +        if ( virq >= 32 )
>> +            goto unlock;
>> +    }
>> +    else
>> +    {
>> +        virq = find_next_zero_bit(d->arch.vgic.allocated_irqs,
>> +                                  32, vgic_num_irqs(d));
>> +        if ( virq >= vgic_num_irqs(d) )
>> +            goto unlock;
>> +    }
>> +
>> +    set_bit(virq, d->arch.vgic.allocated_irqs);
>> +    ret = virq;
>> +
>> +unlock:
>> +    spin_unlock(&d->arch.vgic.lock);
> 
> you might be able to write this function without taking the lock too, by
> using test_and_set_bit and retries:
> 
> retry:
>     virq = find_first_zero_bit;
>     if (test_and_set_bit(virq))
>         goto retry;

I will give a look to it. I will also to limit the number of retry
(maybe to the number of vIRQ) for safety.

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 Dec 15 16:07:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16:07:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0YB9-0002n5-Jh; Mon, 15 Dec 2014 16:07:23 +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 1Y0YB7-0002n0-Sj
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 16:07:21 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	84/22-29352-9370F845; Mon, 15 Dec 2014 16:07:21 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418659640!8148089!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24198 invoked from network); 15 Dec 2014 16:07:20 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 16:07:20 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so9574355wiw.4
	for <xen-devel@lists.xenproject.org>;
	Mon, 15 Dec 2014 08:07: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=Df2TIVDTIUvYtQmMdSHPYDAlsWJuZS9f0PVDn6JZtnI=;
	b=KpeYjcMPI85bBb5uq7AV9Q6odOZs+WAuXPueIbzDboNU3x/X4+TJRi1/YjzWg5LYDb
	itF7XTLZynxD3CI3e72U6OJ10SA1uG+Qwo7329LUbIyF30LFuCTj4mxC52D64lwnMq48
	QCGx9L3ADHoLm2PvbTQrpCUdGBHhhK9cx3pWUvpu3xDgDFIdohCPwNr5BOD04rIhHHBb
	TQUYF+3S7r6BqDSv7GbQf89fmf1C8jgnSO+yiN7roCuUHEbsK4lQkHYPROfUlivSDet4
	W/j99WxNL2oxP+up/3mDngYu6lyDoK5DIOGR8+ttjCUu71NGE8PbkxRHmMt9tSBlT8PS
	+rvg==
X-Gm-Message-State: ALoCoQknx7kTuD/61AHjN5wLfwtmRcuoFj1SBYZShkCcUw4zudeTnUiFHYNQT86GYdqV04+ByMLy
X-Received: by 10.180.94.230 with SMTP id df6mr33181850wib.25.1418659639989;
	Mon, 15 Dec 2014 08:07:19 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	nj9sm13764777wic.10.2014.12.15.08.07.18 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 15 Dec 2014 08:07:19 -0800 (PST)
Message-ID: <548F0733.2020108@linaro.org>
Date: Mon, 15 Dec 2014 16:07:15 +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>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
	<1418395392-30460-3-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1412151527310.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412151527310.30971@kaball.uk.xensource.com>
Cc: ian.campbell@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	xen-devel@lists.xenproject.org, parth.dixit@linaro.org,
	christoffer.dall@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.6 2/4] xen/arm: vgic: Keep track of
 vIRQ used by a domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 15/12/14 15:32, Stefano Stabellini wrote:
> On Fri, 12 Dec 2014, Julien Grall wrote:
>> +    spin_lock_init(&d->arch.vgic.lock);
> 
> you should probably explain in the commit message the reason why you are
> making changes to the vgic lock

Actually the domain vgic lock was never used. Only the per-vcpu vgic
lock was in used.

So I don't make any change to the vgic lock. If I don't use it, I will
add a patch to drop it.

>> @@ -441,6 +453,70 @@ int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
>>      return v->domain->arch.vgic.handler->emulate_sysreg(regs, hsr);
>>  }
>>  
>> +bool_t vgic_reserve_virq(struct domain *d, unsigned int virq)
>> +{
>> +    bool_t reserved;
>> +
>> +    if ( virq >= vgic_num_irqs(d) )
>> +        return 0;
>> +
>> +    spin_lock(&d->arch.vgic.lock);
>> +    reserved = !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
>> +    spin_unlock(&d->arch.vgic.lock);
> 
> test_and_set_bit is atomic, why do you need to take the lock?

To avoid race condition with vgic_allocate_virq.

Anyway, I will dropped it with your suggestion to implement
vgic_allocate_virq without lock.

[..]

>> +int vgic_allocate_virq(struct domain *d, bool_t spi)
>> +{
>> +    int ret = -1;
>> +    unsigned int virq;
>> +
>> +    spin_lock(&d->arch.vgic.lock);
>> +    if ( !spi )
>> +    {
>> +        virq = find_first_zero_bit(d->arch.vgic.allocated_irqs, 32);
>> +        if ( virq >= 32 )
>> +            goto unlock;
>> +    }
>> +    else
>> +    {
>> +        virq = find_next_zero_bit(d->arch.vgic.allocated_irqs,
>> +                                  32, vgic_num_irqs(d));
>> +        if ( virq >= vgic_num_irqs(d) )
>> +            goto unlock;
>> +    }
>> +
>> +    set_bit(virq, d->arch.vgic.allocated_irqs);
>> +    ret = virq;
>> +
>> +unlock:
>> +    spin_unlock(&d->arch.vgic.lock);
> 
> you might be able to write this function without taking the lock too, by
> using test_and_set_bit and retries:
> 
> retry:
>     virq = find_first_zero_bit;
>     if (test_and_set_bit(virq))
>         goto retry;

I will give a look to it. I will also to limit the number of retry
(maybe to the number of vIRQ) for safety.

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 Dec 15 16:09:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16:09:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0YDF-0002st-4r; Mon, 15 Dec 2014 16:09:33 +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 1Y0YDE-0002sn-0O
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 16:09:32 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	C0/D5-14214-BB70F845; Mon, 15 Dec 2014 16:09:31 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418659770!10086404!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4842 invoked from network); 15 Dec 2014 16:09:30 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 16:09:30 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so9411074wiv.5
	for <xen-devel@lists.xenproject.org>;
	Mon, 15 Dec 2014 08:09: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=3EcbXN52PE+fZTLBYAp2MnP2kkEZyitNMxvvYmWTq08=;
	b=jXdIjORLANh7EByjA6iix+CrCZuRD4r1fp139/mO2JIe93q3OvPKV9XzhAmPpux+QW
	mTINpC59XAj6tu/CFKcCxuegwE2MYVBVkdAwFMwfN/sME07MwXDCw61+3SNu+e/vXXXZ
	ZPPXSUOLzWq02/GzMEkeX7VUg2wUHCDqmmgF5h4V3ZB4A1EcLC9NX+baz/Acp3BdQYS8
	ufPFjVDywE4qlp5/zeazbLdauMJ6K5jR2XCexkWqOZGg3jQaNL1b/HLhzEfwHykpXLqe
	wPyS1GoatR/wYvtCMankjR6yBUV3PeqkB3kbNAcWZxXox5kD0J2kGlhC202Xei2hSXj6
	BSQw==
X-Gm-Message-State: ALoCoQmWgXbmJrMQrT/8zKeweo0v4g3vWUhVmhHSQFe6Bcgsker58rOOD61c7OkphOx5jMfpOdG9
X-Received: by 10.194.52.37 with SMTP id q5mr52462907wjo.39.1418659770554;
	Mon, 15 Dec 2014 08:09:30 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	ry19sm13570136wjb.3.2014.12.15.08.09.28 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 15 Dec 2014 08:09:29 -0800 (PST)
Message-ID: <548F07B5.5020601@linaro.org>
Date: Mon, 15 Dec 2014 16:09: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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
	<1418395392-30460-5-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1412151534320.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412151534320.30971@kaball.uk.xensource.com>
Cc: ian.campbell@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	xen-devel@lists.xenproject.org, parth.dixit@linaro.org,
	christoffer.dall@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.6 4/4] xen/arm: Find automatically a
 PPI for the DOM0 event channel interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On 15/12/14 15:35, Stefano Stabellini wrote:
> On Fri, 12 Dec 2014, Julien Grall wrote:
>> Use the new vgic interface to know which virtual PPI is free and use it
>> for the event channel code.
>>
>> At the DOM0 creation time, Xen still don't know which vIRQ will be free.
>> All the vIRQ will be reserved when we parse the device tree. So allocate
>> when the hypervisor node is created.
>>
>> It's safe to defer the allocation because no vIRQ can be injected as
>> long as the vCPU is not online.
>>
>> Also correct the check in arch_domain_create to use is_hardware_domain.
>>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>> ---
>>  xen/arch/arm/domain.c                | 13 ++++++++++---
>>  xen/arch/arm/domain_build.c          | 10 ++++++++++
>>  xen/arch/arm/platform.c              |  7 -------
>>  xen/arch/arm/platforms/xgene-storm.c |  1 -
>>  xen/include/asm-arm/platform.h       |  4 ----
>>  5 files changed, 20 insertions(+), 15 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index 7221bc8..7d14377 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -543,10 +543,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>>      if ( (rc = domain_vtimer_init(d)) != 0 )
>>          goto fail;
>>  
>> -    if ( d->domain_id )
>> +    /*
>> +     * The hardware domain will get a PPI later in
>> +     * arch/arm/domain_build.c  depending on the
>> +     * interrupt map of the hardware.
>> +     */
>> +    if ( !is_hardware_domain(d) )
>> +    {
>>          d->arch.evtchn_irq = GUEST_EVTCHN_PPI;
>> -    else
>> -        d->arch.evtchn_irq = platform_dom0_evtchn_ppi();
>> +        /* At this stage vgic_reserve_virq should never fail */
>> +        BUG_ON(vgic_reserve_virq(d, GUEST_EVTCHN_PPI));
>> +    }
> 
> Why do we still need this, if we have another vgic_allocate_virq call in
> make_hypervisor_node? Wouldn't that work for DomUs too?

Because make_hypervisor_node is only used for DOM0. Futhermore, DOMUs
are using a specific hardcoded layout (see xen/include/public/arch-arm.h).

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 Dec 15 16:09:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16:09:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0YDF-0002st-4r; Mon, 15 Dec 2014 16:09:33 +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 1Y0YDE-0002sn-0O
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 16:09:32 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	C0/D5-14214-BB70F845; Mon, 15 Dec 2014 16:09:31 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418659770!10086404!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4842 invoked from network); 15 Dec 2014 16:09:30 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 16:09:30 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so9411074wiv.5
	for <xen-devel@lists.xenproject.org>;
	Mon, 15 Dec 2014 08:09: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=3EcbXN52PE+fZTLBYAp2MnP2kkEZyitNMxvvYmWTq08=;
	b=jXdIjORLANh7EByjA6iix+CrCZuRD4r1fp139/mO2JIe93q3OvPKV9XzhAmPpux+QW
	mTINpC59XAj6tu/CFKcCxuegwE2MYVBVkdAwFMwfN/sME07MwXDCw61+3SNu+e/vXXXZ
	ZPPXSUOLzWq02/GzMEkeX7VUg2wUHCDqmmgF5h4V3ZB4A1EcLC9NX+baz/Acp3BdQYS8
	ufPFjVDywE4qlp5/zeazbLdauMJ6K5jR2XCexkWqOZGg3jQaNL1b/HLhzEfwHykpXLqe
	wPyS1GoatR/wYvtCMankjR6yBUV3PeqkB3kbNAcWZxXox5kD0J2kGlhC202Xei2hSXj6
	BSQw==
X-Gm-Message-State: ALoCoQmWgXbmJrMQrT/8zKeweo0v4g3vWUhVmhHSQFe6Bcgsker58rOOD61c7OkphOx5jMfpOdG9
X-Received: by 10.194.52.37 with SMTP id q5mr52462907wjo.39.1418659770554;
	Mon, 15 Dec 2014 08:09:30 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id
	ry19sm13570136wjb.3.2014.12.15.08.09.28 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 15 Dec 2014 08:09:29 -0800 (PST)
Message-ID: <548F07B5.5020601@linaro.org>
Date: Mon, 15 Dec 2014 16:09: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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
	<1418395392-30460-5-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1412151534320.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412151534320.30971@kaball.uk.xensource.com>
Cc: ian.campbell@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	xen-devel@lists.xenproject.org, parth.dixit@linaro.org,
	christoffer.dall@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.6 4/4] xen/arm: Find automatically a
 PPI for the DOM0 event channel interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Stefano,

On 15/12/14 15:35, Stefano Stabellini wrote:
> On Fri, 12 Dec 2014, Julien Grall wrote:
>> Use the new vgic interface to know which virtual PPI is free and use it
>> for the event channel code.
>>
>> At the DOM0 creation time, Xen still don't know which vIRQ will be free.
>> All the vIRQ will be reserved when we parse the device tree. So allocate
>> when the hypervisor node is created.
>>
>> It's safe to defer the allocation because no vIRQ can be injected as
>> long as the vCPU is not online.
>>
>> Also correct the check in arch_domain_create to use is_hardware_domain.
>>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>> ---
>>  xen/arch/arm/domain.c                | 13 ++++++++++---
>>  xen/arch/arm/domain_build.c          | 10 ++++++++++
>>  xen/arch/arm/platform.c              |  7 -------
>>  xen/arch/arm/platforms/xgene-storm.c |  1 -
>>  xen/include/asm-arm/platform.h       |  4 ----
>>  5 files changed, 20 insertions(+), 15 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index 7221bc8..7d14377 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -543,10 +543,17 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>>      if ( (rc = domain_vtimer_init(d)) != 0 )
>>          goto fail;
>>  
>> -    if ( d->domain_id )
>> +    /*
>> +     * The hardware domain will get a PPI later in
>> +     * arch/arm/domain_build.c  depending on the
>> +     * interrupt map of the hardware.
>> +     */
>> +    if ( !is_hardware_domain(d) )
>> +    {
>>          d->arch.evtchn_irq = GUEST_EVTCHN_PPI;
>> -    else
>> -        d->arch.evtchn_irq = platform_dom0_evtchn_ppi();
>> +        /* At this stage vgic_reserve_virq should never fail */
>> +        BUG_ON(vgic_reserve_virq(d, GUEST_EVTCHN_PPI));
>> +    }
> 
> Why do we still need this, if we have another vgic_allocate_virq call in
> make_hypervisor_node? Wouldn't that work for DomUs too?

Because make_hypervisor_node is only used for DOM0. Futhermore, DOMUs
are using a specific hardcoded layout (see xen/include/public/arch-arm.h).

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 Dec 15 16:16:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16:16:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0YJo-0003FK-AO; Mon, 15 Dec 2014 16:16: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 1Y0YJm-0003FF-AL
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 16:16:18 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	10/AD-02696-1590F845; Mon, 15 Dec 2014 16:16:17 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418660174!15185885!1
X-Originating-IP: [66.165.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 31964 invoked from network); 15 Dec 2014 16:16:16 -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;
	15 Dec 2014 16:16:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204501462"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 11:15: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 1Y0YJB-0003ic-Kv;
	Mon, 15 Dec 2014 16:15:41 +0000
Date: Mon, 15 Dec 2014 16:15:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <548F13F0020000780004FAA0@mail.emea.novell.com>
Message-ID: <alpine.DEB.2.02.1412151606040.30971@kaball.uk.xensource.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
	<548EB672020000780004F7D2@mail.emea.novell.com>
	<alpine.DEB.2.02.1412151521400.30971@kaball.uk.xensource.com>
	<548F13F0020000780004FAA0@mail.emea.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Kevin Tian <kevin.tian@intel.com>, "keir@xen.org" <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	TimDeegan <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Dec 2014, Jan Beulich wrote:
> >>> On 15.12.14 at 16:22, <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 15 Dec 2014, Jan Beulich wrote:
> >> >>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
> >> > yes, definitely host RAM is the upper limit, and what I'm concerning here
> >> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
> >> > resource, w/o collision with other PFN reservation usage (ballooning
> >> > should be fine since it's operating existing RAM ranges in dom0 e820
> >> > table).
> >> 
> >> I don't think ballooning is restricted to the regions named RAM in
> >> Dom0's E820 table (at least it shouldn't be, and wasn't in the
> >> classic Xen kernels).
> > 
> > Could you please elaborate more on this? It seems counter-intuitive at best.
> 
> I don't see what's counter-intuitive here. How can the hypervisor
> (Dom0) or tool stack (DomU) know what ballooning intentions a
> guest kernel may have?

The hypervisor checks that the memory the guest is giving back is
actually ram, as a consequence the ballooning interface only supports
ram. Do you agree?

Ballooning is restricted to regions named RAM in the e820 table, because
Linux respects e820 in its pfn->mfn mappings. However it is true that
respecting the e820 in dom0 is not part of the interface.


> It's solely the guest kernel's responsibility
> to make sure its ballooning activities don't collide with anything
> else address-wise.

In the sense that it is in the guest kernel's responsibility to use the
interface properly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 16:16:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16:16:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0YJo-0003FK-AO; Mon, 15 Dec 2014 16:16: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 1Y0YJm-0003FF-AL
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 16:16:18 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	10/AD-02696-1590F845; Mon, 15 Dec 2014 16:16:17 +0000
X-Env-Sender: Stefano.Stabellini@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418660174!15185885!1
X-Originating-IP: [66.165.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 31964 invoked from network); 15 Dec 2014 16:16:16 -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;
	15 Dec 2014 16:16:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204501462"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 11:15: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 1Y0YJB-0003ic-Kv;
	Mon, 15 Dec 2014 16:15:41 +0000
Date: Mon, 15 Dec 2014 16:15:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <548F13F0020000780004FAA0@mail.emea.novell.com>
Message-ID: <alpine.DEB.2.02.1412151606040.30971@kaball.uk.xensource.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
	<548EB672020000780004F7D2@mail.emea.novell.com>
	<alpine.DEB.2.02.1412151521400.30971@kaball.uk.xensource.com>
	<548F13F0020000780004FAA0@mail.emea.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-DLP: MIA1
Cc: Kevin Tian <kevin.tian@intel.com>, "keir@xen.org" <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	TimDeegan <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Dec 2014, Jan Beulich wrote:
> >>> On 15.12.14 at 16:22, <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 15 Dec 2014, Jan Beulich wrote:
> >> >>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
> >> > yes, definitely host RAM is the upper limit, and what I'm concerning here
> >> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
> >> > resource, w/o collision with other PFN reservation usage (ballooning
> >> > should be fine since it's operating existing RAM ranges in dom0 e820
> >> > table).
> >> 
> >> I don't think ballooning is restricted to the regions named RAM in
> >> Dom0's E820 table (at least it shouldn't be, and wasn't in the
> >> classic Xen kernels).
> > 
> > Could you please elaborate more on this? It seems counter-intuitive at best.
> 
> I don't see what's counter-intuitive here. How can the hypervisor
> (Dom0) or tool stack (DomU) know what ballooning intentions a
> guest kernel may have?

The hypervisor checks that the memory the guest is giving back is
actually ram, as a consequence the ballooning interface only supports
ram. Do you agree?

Ballooning is restricted to regions named RAM in the e820 table, because
Linux respects e820 in its pfn->mfn mappings. However it is true that
respecting the e820 in dom0 is not part of the interface.


> It's solely the guest kernel's responsibility
> to make sure its ballooning activities don't collide with anything
> else address-wise.

In the sense that it is in the guest kernel's responsibility to use the
interface properly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 16:28:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0YVK-0003Zu-Pg; Mon, 15 Dec 2014 16:28:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Y0YVI-0003Zp-NW
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 16:28:12 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	3C/C2-24124-C1C0F845; Mon, 15 Dec 2014 16:28:12 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418660889!8152823!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25916 invoked from network); 15 Dec 2014 16:28:11 -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;
	15 Dec 2014 16:28:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204966815"
Message-ID: <548F0C16.1080609@citrix.com>
Date: Mon, 15 Dec 2014 16:28:06 +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>, Jan Beulich
	<JBeulich@suse.com>
References: <5486CAAF.9070807@linux.intel.com>	<20141209104633.GC75319@deinos.phlegethon.org>	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>	<20141210105505.GA64596@deinos.phlegethon.org>	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>	<20141211164632.GF53811@deinos.phlegethon.org>	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>	<548AD75B020000780004F342@mail.emea.novell.com>	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>	<548EAD94020000780004F76D@mail.emea.novell.com>	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>	<548EB672020000780004F7D2@mail.emea.novell.com>	<alpine.DEB.2.02.1412151521400.30971@kaball.uk.xensource.com>	<548F13F0020000780004FAA0@mail.emea.novell.com>
	<alpine.DEB.2.02.1412151606040.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412151606040.30971@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: Kevin Tian <kevin.tian@intel.com>, "keir@xen.org" <keir@xen.org>,
	TimDeegan <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/12/14 16:15, Stefano Stabellini wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
>>>>> On 15.12.14 at 16:22, <stefano.stabellini@eu.citrix.com> wrote:
>>> On Mon, 15 Dec 2014, Jan Beulich wrote:
>>>>>>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
>>>>> yes, definitely host RAM is the upper limit, and what I'm concerning here
>>>>> is how to reserve (at boot time) or allocate (on-demand) such large PFN
>>>>> resource, w/o collision with other PFN reservation usage (ballooning
>>>>> should be fine since it's operating existing RAM ranges in dom0 e820
>>>>> table).
>>>>
>>>> I don't think ballooning is restricted to the regions named RAM in
>>>> Dom0's E820 table (at least it shouldn't be, and wasn't in the
>>>> classic Xen kernels).
>>>
>>> Could you please elaborate more on this? It seems counter-intuitive at best.
>>
>> I don't see what's counter-intuitive here. How can the hypervisor
>> (Dom0) or tool stack (DomU) know what ballooning intentions a
>> guest kernel may have?
> 
> The hypervisor checks that the memory the guest is giving back is
> actually ram, as a consequence the ballooning interface only supports
> ram. Do you agree?
> 
> Ballooning is restricted to regions named RAM in the e820 table, because
> Linux respects e820 in its pfn->mfn mappings. However it is true that
> respecting the e820 in dom0 is not part of the interface.

Linux will quite happily allow you to add memory outside of the initial
e820 RAM regions.  The current balloon driver even supports this using
the kernel's generic memory hotplug infrastructure.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 16:28:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0YVK-0003Zu-Pg; Mon, 15 Dec 2014 16:28:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Y0YVI-0003Zp-NW
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 16:28:12 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	3C/C2-24124-C1C0F845; Mon, 15 Dec 2014 16:28:12 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418660889!8152823!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25916 invoked from network); 15 Dec 2014 16:28:11 -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;
	15 Dec 2014 16:28:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204966815"
Message-ID: <548F0C16.1080609@citrix.com>
Date: Mon, 15 Dec 2014 16:28:06 +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>, Jan Beulich
	<JBeulich@suse.com>
References: <5486CAAF.9070807@linux.intel.com>	<20141209104633.GC75319@deinos.phlegethon.org>	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>	<20141210105505.GA64596@deinos.phlegethon.org>	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>	<20141211164632.GF53811@deinos.phlegethon.org>	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>	<548AD75B020000780004F342@mail.emea.novell.com>	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>	<548EAD94020000780004F76D@mail.emea.novell.com>	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>	<548EB672020000780004F7D2@mail.emea.novell.com>	<alpine.DEB.2.02.1412151521400.30971@kaball.uk.xensource.com>	<548F13F0020000780004FAA0@mail.emea.novell.com>
	<alpine.DEB.2.02.1412151606040.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412151606040.30971@kaball.uk.xensource.com>
X-DLP: MIA2
Cc: Kevin Tian <kevin.tian@intel.com>, "keir@xen.org" <keir@xen.org>,
	TimDeegan <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/12/14 16:15, Stefano Stabellini wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
>>>>> On 15.12.14 at 16:22, <stefano.stabellini@eu.citrix.com> wrote:
>>> On Mon, 15 Dec 2014, Jan Beulich wrote:
>>>>>>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
>>>>> yes, definitely host RAM is the upper limit, and what I'm concerning here
>>>>> is how to reserve (at boot time) or allocate (on-demand) such large PFN
>>>>> resource, w/o collision with other PFN reservation usage (ballooning
>>>>> should be fine since it's operating existing RAM ranges in dom0 e820
>>>>> table).
>>>>
>>>> I don't think ballooning is restricted to the regions named RAM in
>>>> Dom0's E820 table (at least it shouldn't be, and wasn't in the
>>>> classic Xen kernels).
>>>
>>> Could you please elaborate more on this? It seems counter-intuitive at best.
>>
>> I don't see what's counter-intuitive here. How can the hypervisor
>> (Dom0) or tool stack (DomU) know what ballooning intentions a
>> guest kernel may have?
> 
> The hypervisor checks that the memory the guest is giving back is
> actually ram, as a consequence the ballooning interface only supports
> ram. Do you agree?
> 
> Ballooning is restricted to regions named RAM in the e820 table, because
> Linux respects e820 in its pfn->mfn mappings. However it is true that
> respecting the e820 in dom0 is not part of the interface.

Linux will quite happily allow you to add memory outside of the initial
e820 RAM regions.  The current balloon driver even supports this using
the kernel's generic memory hotplug infrastructure.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 16:29:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16:29:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0YWB-0003e1-Dr; Mon, 15 Dec 2014 16:29:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y0YWA-0003dn-5j
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 16:29:06 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	51/75-24859-15C0F845; Mon, 15 Dec 2014 16:29:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418660944!13442805!1
X-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 531 invoked from network); 15 Dec 2014 16:29:04 -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; 15 Dec 2014 16:29:04 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 16:29:03 +0000
Message-Id: <548F1A5B020000780004FAE2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 16:28:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
	<548EB672020000780004F7D2@mail.emea.novell.com>
	<alpine.DEB.2.02.1412151521400.30971@kaball.uk.xensource.com>
	<548F13F0020000780004FAA0@mail.emea.novell.com>
	<alpine.DEB.2.02.1412151606040.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412151606040.30971@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>, "keir@xen.org" <keir@xen.org>,
	TimDeegan <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 17:15, <stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
>> >>> On 15.12.14 at 16:22, <stefano.stabellini@eu.citrix.com> wrote:
>> > On Mon, 15 Dec 2014, Jan Beulich wrote:
>> >> >>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
>> >> > yes, definitely host RAM is the upper limit, and what I'm concerning here
>> >> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
>> >> > resource, w/o collision with other PFN reservation usage (ballooning
>> >> > should be fine since it's operating existing RAM ranges in dom0 e820
>> >> > table).
>> >> 
>> >> I don't think ballooning is restricted to the regions named RAM in
>> >> Dom0's E820 table (at least it shouldn't be, and wasn't in the
>> >> classic Xen kernels).
>> > 
>> > Could you please elaborate more on this? It seems counter-intuitive at best.
>> 
>> I don't see what's counter-intuitive here. How can the hypervisor
>> (Dom0) or tool stack (DomU) know what ballooning intentions a
>> guest kernel may have?
> 
> The hypervisor checks that the memory the guest is giving back is
> actually ram, as a consequence the ballooning interface only supports
> ram. Do you agree?

Of course.

> Ballooning is restricted to regions named RAM in the e820 table, because
> Linux respects e820 in its pfn->mfn mappings. However it is true that
> respecting the e820 in dom0 is not part of the interface.

Right. Plus the kernel is free to extend the region(s) perceived as
RAM in the E820 is sees (makes up) at boot time.

>> It's solely the guest kernel's responsibility
>> to make sure its ballooning activities don't collide with anything
>> else address-wise.
> 
> In the sense that it is in the guest kernel's responsibility to use the
> interface properly.

That's a given for this discussion. The important aspect is that neither
tools nor hypervisor have any influence on how a PV kernel
partitions its PFN space - the only thing they control is the boot time
state thereof.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 16:29:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16:29:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0YWB-0003e1-Dr; Mon, 15 Dec 2014 16:29:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y0YWA-0003dn-5j
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 16:29:06 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	51/75-24859-15C0F845; Mon, 15 Dec 2014 16:29:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418660944!13442805!1
X-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 531 invoked from network); 15 Dec 2014 16:29:04 -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; 15 Dec 2014 16:29:04 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Mon, 15 Dec 2014 16:29:03 +0000
Message-Id: <548F1A5B020000780004FAE2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 15 Dec 2014 16:28:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
	<548AD75B020000780004F342@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AA2B@SHSMSX101.ccr.corp.intel.com>
	<548EAD94020000780004F76D@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611AE3F@SHSMSX101.ccr.corp.intel.com>
	<548EB672020000780004F7D2@mail.emea.novell.com>
	<alpine.DEB.2.02.1412151521400.30971@kaball.uk.xensource.com>
	<548F13F0020000780004FAA0@mail.emea.novell.com>
	<alpine.DEB.2.02.1412151606040.30971@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1412151606040.30971@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>, "keir@xen.org" <keir@xen.org>,
	TimDeegan <tim@xen.org>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Zhang Yu <yu.c.zhang@linux.intel.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 17:15, <stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
>> >>> On 15.12.14 at 16:22, <stefano.stabellini@eu.citrix.com> wrote:
>> > On Mon, 15 Dec 2014, Jan Beulich wrote:
>> >> >>> On 15.12.14 at 10:05, <kevin.tian@intel.com> wrote:
>> >> > yes, definitely host RAM is the upper limit, and what I'm concerning here
>> >> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
>> >> > resource, w/o collision with other PFN reservation usage (ballooning
>> >> > should be fine since it's operating existing RAM ranges in dom0 e820
>> >> > table).
>> >> 
>> >> I don't think ballooning is restricted to the regions named RAM in
>> >> Dom0's E820 table (at least it shouldn't be, and wasn't in the
>> >> classic Xen kernels).
>> > 
>> > Could you please elaborate more on this? It seems counter-intuitive at best.
>> 
>> I don't see what's counter-intuitive here. How can the hypervisor
>> (Dom0) or tool stack (DomU) know what ballooning intentions a
>> guest kernel may have?
> 
> The hypervisor checks that the memory the guest is giving back is
> actually ram, as a consequence the ballooning interface only supports
> ram. Do you agree?

Of course.

> Ballooning is restricted to regions named RAM in the e820 table, because
> Linux respects e820 in its pfn->mfn mappings. However it is true that
> respecting the e820 in dom0 is not part of the interface.

Right. Plus the kernel is free to extend the region(s) perceived as
RAM in the E820 is sees (makes up) at boot time.

>> It's solely the guest kernel's responsibility
>> to make sure its ballooning activities don't collide with anything
>> else address-wise.
> 
> In the sense that it is in the guest kernel's responsibility to use the
> interface properly.

That's a given for this discussion. The important aspect is that neither
tools nor hypervisor have any influence on how a PV kernel
partitions its PFN space - the only thing they control is the boot time
state thereof.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 16:31:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16: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 1Y0YYD-0003o4-Ud; Mon, 15 Dec 2014 16:31:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Y0YYC-0003nt-E5
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 16:31:12 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	C0/17-01660-FCC0F845; Mon, 15 Dec 2014 16:31:11 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418661070!10091289!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5162 invoked from network); 15 Dec 2014 16:31:11 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-15.tower-206.messagelabs.com with SMTP;
	15 Dec 2014 16:31:11 -0000
X-TM-IMSS-Message-ID: <0914307100009d28@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 0914307100009d28 ;
	Mon, 15 Dec 2014 11:31: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 sBFGUcA9023279; 
	Mon, 15 Dec 2014 11:30:48 -0500
Message-ID: <548F0CAF.2040206@tycho.nsa.gov>
Date: Mon, 15 Dec 2014 11:30:39 -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: Quan Xu <quan.xu@intel.com>, xen-devel@lists.xen.org
References: <1418558965-13342-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1418558965-13342-1-git-send-email-quan.xu@intel.com>
Cc: samuel.thibault@ens-lyon.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 00/12] Enable vTPM subsystem on TPM 2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/14/2014 07:09 AM, Quan Xu wrote:
> This series of patch enable the virtual Trusted Platform Module (vTPM)
> subsystem for Xen on TPM 2.0.
>
> Noted, functionality for a virtual guest operating system (a DomU) is still
> TPM 1.2. The main modifcation is on vtpmmgr-stubdom. The challenge is that
> TPM 2.0 is not backward compatibility with TPM 1.2.
>

This series looks good.  Other than a minor comment on #9, my only concern is
the use of bind/unbind instead of seal/unseal (mentioned in my reply to #11,
but it really applies to the series as a whole).  Changing the data structures
to support hashes, authdata, and other measurements larger than 20 bytes is
probably best done sooner so that the management commands can be changed before
much infrastructure is built using the existing ones, but it doesn't have to be
done as part of the introduction of TPM2 support.

Due to the holidays, I will not be able to review further patches until January.

-- 
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 Dec 15 16:31:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16: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 1Y0YYD-0003o4-Ud; Mon, 15 Dec 2014 16:31:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Y0YYC-0003nt-E5
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 16:31:12 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	C0/17-01660-FCC0F845; Mon, 15 Dec 2014 16:31:11 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418661070!10091289!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5162 invoked from network); 15 Dec 2014 16:31:11 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO emvm-gh1-uea08.nsa.gov)
	(63.239.67.9) by server-15.tower-206.messagelabs.com with SMTP;
	15 Dec 2014 16:31:11 -0000
X-TM-IMSS-Message-ID: <0914307100009d28@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 0914307100009d28 ;
	Mon, 15 Dec 2014 11:31: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 sBFGUcA9023279; 
	Mon, 15 Dec 2014 11:30:48 -0500
Message-ID: <548F0CAF.2040206@tycho.nsa.gov>
Date: Mon, 15 Dec 2014 11:30:39 -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: Quan Xu <quan.xu@intel.com>, xen-devel@lists.xen.org
References: <1418558965-13342-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1418558965-13342-1-git-send-email-quan.xu@intel.com>
Cc: samuel.thibault@ens-lyon.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 00/12] Enable vTPM subsystem on TPM 2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/14/2014 07:09 AM, Quan Xu wrote:
> This series of patch enable the virtual Trusted Platform Module (vTPM)
> subsystem for Xen on TPM 2.0.
>
> Noted, functionality for a virtual guest operating system (a DomU) is still
> TPM 1.2. The main modifcation is on vtpmmgr-stubdom. The challenge is that
> TPM 2.0 is not backward compatibility with TPM 1.2.
>

This series looks good.  Other than a minor comment on #9, my only concern is
the use of bind/unbind instead of seal/unseal (mentioned in my reply to #11,
but it really applies to the series as a whole).  Changing the data structures
to support hashes, authdata, and other measurements larger than 20 bytes is
probably best done sooner so that the management commands can be changed before
much infrastructure is built using the existing ones, but it doesn't have to be
done as part of the introduction of TPM2 support.

Due to the holidays, I will not be able to review further patches until January.

-- 
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 Dec 15 16:47:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16: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 1Y0Yni-0004Mj-Fi; Mon, 15 Dec 2014 16:47:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Y0Ynh-0004Me-LY
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 16:47:13 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1B/71-25276-1901F845; Mon, 15 Dec 2014 16:47:13 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418662032!7703730!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24830 invoked from network); 15 Dec 2014 16:47:12 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 16:47:12 -0000
Received: by mail-wg0-f48.google.com with SMTP id y19so15042202wgg.21
	for <xen-devel@lists.xen.org>; Mon, 15 Dec 2014 08:47: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=ST9pA6H4n32GDpeQVCgSXkJPgPyVxgIwrgkrd3gQFi0=;
	b=oxjNS8CfnzMK+xFqPLv0tRLX/4hz6AK4zxEeP/iE6hqZsFzT5hnDUsE688WbZwZ3Jm
	6fTPhDodQHbMaDSB0Bw2jJfLBJr3NooRryYEqwWJZfiBtabYJuA/KlzzMwtXsdzy/JCE
	kZvp5Ut2JEUhYAfTaLpcSNTomvmGWIB2BAkVl6/tK820KP9aUnYZYLPgRAOwSKB6vnhp
	qsaLY6GJShCxWdZPGwLJiEKiGNJUmQDK5eqioK+zcnP1SKTpYh4q2mxe20JtNwvvS53I
	D82+OEJlWEEt0wn89ry+ChPembNpkruUBaorh4vrysVDtH/jQPvt/KJYC+QrjtNfrPca
	Rr3w==
MIME-Version: 1.0
X-Received: by 10.194.187.235 with SMTP id fv11mr53829935wjc.16.1418662031985; 
	Mon, 15 Dec 2014 08:47:11 -0800 (PST)
Received: by 10.194.163.70 with HTTP; Mon, 15 Dec 2014 08:47:11 -0800 (PST)
In-Reply-To: <20141210163046.GF4268@laptop.dumpdata.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
	<1418136501.14361.83.camel@citrix.com>
	<20141210163046.GF4268@laptop.dumpdata.com>
Date: Mon, 15 Dec 2014 16:47:11 +0000
X-Google-Sender-Auth: qXvCtvJTBmA5OJ7AQf3oMm1hC1w
Message-ID: <CAFLBxZbOyDq63c8groyCSE5etDV1K+5htTwoNqqhRj2CL2fmqw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Ian Jackson <ian.jackson@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 4.5] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 4:30 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Dec 09, 2014 at 02:48:21PM +0000, Ian Campbell wrote:
>> On Tue, 2014-12-09 at 14:04 +0000, George Dunlap wrote:
>> > At the moment libxl unconditinally passes the underlying file format
>> > to qemu in the device string.  However, when tapdisk is in use,
>> > tapdisk handles the underlying format and presents qemu with
>> > effectively a raw disk.  When qemu looks at the tapdisk block device
>> > and doesn't find the image format it was looking for, it will fail.
>> >
>> > This effectively means that tapdisk cannot be used with HVM domains at
>> > the moment except for raw files.
>> >
>> > Instead, if we're using a tapdisk backend, tell qemu to use a raw file
>> > format.
>> >
>> > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>>
>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This doesn't seem to have been applied yet.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 16:47:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 16: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 1Y0Yni-0004Mj-Fi; Mon, 15 Dec 2014 16:47:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Y0Ynh-0004Me-LY
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 16:47:13 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	1B/71-25276-1901F845; Mon, 15 Dec 2014 16:47:13 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418662032!7703730!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24830 invoked from network); 15 Dec 2014 16:47:12 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 16:47:12 -0000
Received: by mail-wg0-f48.google.com with SMTP id y19so15042202wgg.21
	for <xen-devel@lists.xen.org>; Mon, 15 Dec 2014 08:47: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=ST9pA6H4n32GDpeQVCgSXkJPgPyVxgIwrgkrd3gQFi0=;
	b=oxjNS8CfnzMK+xFqPLv0tRLX/4hz6AK4zxEeP/iE6hqZsFzT5hnDUsE688WbZwZ3Jm
	6fTPhDodQHbMaDSB0Bw2jJfLBJr3NooRryYEqwWJZfiBtabYJuA/KlzzMwtXsdzy/JCE
	kZvp5Ut2JEUhYAfTaLpcSNTomvmGWIB2BAkVl6/tK820KP9aUnYZYLPgRAOwSKB6vnhp
	qsaLY6GJShCxWdZPGwLJiEKiGNJUmQDK5eqioK+zcnP1SKTpYh4q2mxe20JtNwvvS53I
	D82+OEJlWEEt0wn89ry+ChPembNpkruUBaorh4vrysVDtH/jQPvt/KJYC+QrjtNfrPca
	Rr3w==
MIME-Version: 1.0
X-Received: by 10.194.187.235 with SMTP id fv11mr53829935wjc.16.1418662031985; 
	Mon, 15 Dec 2014 08:47:11 -0800 (PST)
Received: by 10.194.163.70 with HTTP; Mon, 15 Dec 2014 08:47:11 -0800 (PST)
In-Reply-To: <20141210163046.GF4268@laptop.dumpdata.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
	<1418136501.14361.83.camel@citrix.com>
	<20141210163046.GF4268@laptop.dumpdata.com>
Date: Mon, 15 Dec 2014 16:47:11 +0000
X-Google-Sender-Auth: qXvCtvJTBmA5OJ7AQf3oMm1hC1w
Message-ID: <CAFLBxZbOyDq63c8groyCSE5etDV1K+5htTwoNqqhRj2CL2fmqw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Ian Jackson <ian.jackson@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 4.5] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 10, 2014 at 4:30 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Dec 09, 2014 at 02:48:21PM +0000, Ian Campbell wrote:
>> On Tue, 2014-12-09 at 14:04 +0000, George Dunlap wrote:
>> > At the moment libxl unconditinally passes the underlying file format
>> > to qemu in the device string.  However, when tapdisk is in use,
>> > tapdisk handles the underlying format and presents qemu with
>> > effectively a raw disk.  When qemu looks at the tapdisk block device
>> > and doesn't find the image format it was looking for, it will fail.
>> >
>> > This effectively means that tapdisk cannot be used with HVM domains at
>> > the moment except for raw files.
>> >
>> > Instead, if we're using a tapdisk backend, tell qemu to use a raw file
>> > format.
>> >
>> > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>>
>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This doesn't seem to have been applied yet.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 17:13:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 17: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 1Y0ZD9-0005Hd-BQ; Mon, 15 Dec 2014 17:13:31 +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 1Y0ZD8-0005HY-39
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 17:13:30 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	1C/DA-09284-9B61F845; Mon, 15 Dec 2014 17:13:29 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418663607!13492588!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18207 invoked from network); 15 Dec 2014 17:13:28 -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; 15 Dec 2014 17:13: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 sBFHDPms015966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Dec 2014 17:13:26 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
	sBFHDNqB007321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 15 Dec 2014 17:13:24 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
	sBFHDNVP017101; Mon, 15 Dec 2014 17:13:23 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, 15 Dec 2014 09:13:23 -0800
Message-ID: <548F172A.6010508@oracle.com>
Date: Mon, 15 Dec 2014 12:15:22 -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: <1418419248-2863-1-git-send-email-boris.ostrovsky@oracle.com>
	<548EC102020000780004F810@mail.emea.novell.com>
In-Reply-To: <548EC102020000780004F810@mail.emea.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/15/2014 05:07 AM, Jan Beulich wrote:
>>>> On 12.12.14 at 22:20, <boris.ostrovsky@oracle.com> wrote:
>> --- a/xen/arch/x86/hvm/vpmu.c
>> +++ b/xen/arch/x86/hvm/vpmu.c
>> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
>>       }
>>   }
>>   
>> +static void vpmu_clear_last(void *arg)
>> +{
>> +    struct vcpu *v = (struct vcpu *)arg;
> Please drop this pointless cast, or perhaps the entire variable, as ...
>
>> +
>> +    if ( this_cpu(last_vcpu) == v )
> ... you don't really need it to be of "struct vcpu *" type - "void *"
> is quite fine for a comparison.
>
>> +        this_cpu(last_vcpu) = NULL;
>> +}
>> +
>>   void vpmu_destroy(struct vcpu *v)
>>   {
>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>   
>> +    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
>> +    {
>> +        /* Need to clear last_vcpu in case it points to v */
>> +        if ( vpmu->last_pcpu != smp_processor_id() )
>> +            on_selected_cpus(cpumask_of(vpmu->last_pcpu),
>> +                             vpmu_clear_last, (void *)v, 1);
> The cast here is pointless too. But considering your subsequent
> reply this code may go away altogether anyway; if it doesn't,
> explaining (in the commit message) why you need to use an IPI
> here would seem necessary.

If I do simply
     if (per_cpu(last_vcpu, vpmu->last_pcpu) == v)
         per_cpu(last_vcpu, vpmu->last_pcpu) = NULL

then there is a (rather theoretical) possibility that between the test 
and subsequent clearing the remote cpu (i.e. vpmu->last_pcpu) will do 
load_vpmu() and then save_vpmu() for another VCPU. The former will clear 
last_vcpu and the latter will set last_vcpu to something else. And then 
the destroy_vpmu() will set it again to NULL, which is bad.

Doing it in in IPI will guarantee that nothing can happen between test 
and setting it to NULL.

Again, this very much theoretical, but that's why I have it. (BTW, doing 
this via IPI also preserves assumption that last_vcpu is always updated 
on local CPU.)

My changes for next version would make the need to do the IPIs less 
frequent. But if last_cpu needs to be cleared it would still be via IPI.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 17:13:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 17: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 1Y0ZD9-0005Hd-BQ; Mon, 15 Dec 2014 17:13:31 +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 1Y0ZD8-0005HY-39
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 17:13:30 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	1C/DA-09284-9B61F845; Mon, 15 Dec 2014 17:13:29 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418663607!13492588!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18207 invoked from network); 15 Dec 2014 17:13:28 -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; 15 Dec 2014 17:13: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 sBFHDPms015966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Dec 2014 17:13:26 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
	sBFHDNqB007321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 15 Dec 2014 17:13:24 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
	sBFHDNVP017101; Mon, 15 Dec 2014 17:13:23 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, 15 Dec 2014 09:13:23 -0800
Message-ID: <548F172A.6010508@oracle.com>
Date: Mon, 15 Dec 2014 12:15:22 -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: <1418419248-2863-1-git-send-email-boris.ostrovsky@oracle.com>
	<548EC102020000780004F810@mail.emea.novell.com>
In-Reply-To: <548EC102020000780004F810@mail.emea.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/15/2014 05:07 AM, Jan Beulich wrote:
>>>> On 12.12.14 at 22:20, <boris.ostrovsky@oracle.com> wrote:
>> --- a/xen/arch/x86/hvm/vpmu.c
>> +++ b/xen/arch/x86/hvm/vpmu.c
>> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
>>       }
>>   }
>>   
>> +static void vpmu_clear_last(void *arg)
>> +{
>> +    struct vcpu *v = (struct vcpu *)arg;
> Please drop this pointless cast, or perhaps the entire variable, as ...
>
>> +
>> +    if ( this_cpu(last_vcpu) == v )
> ... you don't really need it to be of "struct vcpu *" type - "void *"
> is quite fine for a comparison.
>
>> +        this_cpu(last_vcpu) = NULL;
>> +}
>> +
>>   void vpmu_destroy(struct vcpu *v)
>>   {
>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>   
>> +    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
>> +    {
>> +        /* Need to clear last_vcpu in case it points to v */
>> +        if ( vpmu->last_pcpu != smp_processor_id() )
>> +            on_selected_cpus(cpumask_of(vpmu->last_pcpu),
>> +                             vpmu_clear_last, (void *)v, 1);
> The cast here is pointless too. But considering your subsequent
> reply this code may go away altogether anyway; if it doesn't,
> explaining (in the commit message) why you need to use an IPI
> here would seem necessary.

If I do simply
     if (per_cpu(last_vcpu, vpmu->last_pcpu) == v)
         per_cpu(last_vcpu, vpmu->last_pcpu) = NULL

then there is a (rather theoretical) possibility that between the test 
and subsequent clearing the remote cpu (i.e. vpmu->last_pcpu) will do 
load_vpmu() and then save_vpmu() for another VCPU. The former will clear 
last_vcpu and the latter will set last_vcpu to something else. And then 
the destroy_vpmu() will set it again to NULL, which is bad.

Doing it in in IPI will guarantee that nothing can happen between test 
and setting it to NULL.

Again, this very much theoretical, but that's why I have it. (BTW, doing 
this via IPI also preserves assumption that last_vcpu is always updated 
on local CPU.)

My changes for next version would make the need to do the IPIs less 
frequent. But if last_cpu needs to be cleared it would still be via IPI.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 17:15:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 17: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 1Y0ZEx-0005Mu-RI; Mon, 15 Dec 2014 17:15:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Y0ZEw-0005Mm-0b
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 17:15:22 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	74/96-09842-9271F845; Mon, 15 Dec 2014 17:15:21 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418663719!15706194!1
X-Originating-IP: [66.165.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 18986 invoked from network); 15 Dec 2014 17:15:20 -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;
	15 Dec 2014 17:15:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204986309"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 12:07:57 -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 1Y0Z7l-0004hu-6j;
	Mon, 15 Dec 2014 17:07:57 +0000
Date: Mon, 15 Dec 2014 17:07:57 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141215170757.GA1705@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418314995.23309.7.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 04:23:15PM +0000, Ian Campbell wrote:
> On Thu, 2014-12-11 at 16:16 +0000, Anthony PERARD wrote:
> > On Tue, Dec 09, 2014 at 03:56:02PM +0000, Ian Campbell wrote:
> > > On Tue, 2014-12-09 at 15:39 +0000, Anthony PERARD wrote:
> > > > The path to the pty of a Xen PV console is set only in
> > > > virDomainOpenConsole. But this is done too late. A call to
> > > > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > > > the pty, but a call after OpenConsole will.
> > > > 
> > > > e.g. of the current issue.
> > > > Starting a domain with '<console type="pty"/>'
> > > > Then:
> > > > virDomainGetXMLDesc():
> > > >   <devices>
> > > >     <console type='pty'>
> > > >       <target type='xen' port='0'/>
> > > >     </console>
> > > >   </devices>
> > > > virDomainOpenConsole()
> > > > virDomainGetXMLDesc():
> > > >   <devices>
> > > >     <console type='pty' tty='/dev/pts/30'>
> > > >       <source path='/dev/pts/30'/>
> > > >       <target type='xen' port='0'/>
> > > >     </console>
> > > >   </devices>
> > > > 
> > > > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > > > This is done by setting up the path at domain start up instead of in
> > > > OpenConsole.
> > > > 
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > > > 
> > > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > > > 
> > > > ---
> > > > Change in V2:
> > > >   Adding bug report link.
> > > >   Reword the last part of the patch description.
> > > >   Cleanup the code.
> > > >   Use VIR_FREE before VIR_STRDUP.
> > > >   Remove the code from OpenConsole as it is now a duplicate.
> > > > ---
> > > >  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
> > > >  src/libxl/libxl_driver.c | 15 ---------------
> > > >  2 files changed, 20 insertions(+), 15 deletions(-)
> > > > 
> > > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > > index 9c62291..325de79 100644
> > > > --- a/src/libxl/libxl_domain.c
> > > > +++ b/src/libxl/libxl_domain.c
> > > > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> > > >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > > >          goto cleanup_dom;
> > > >  
> > > > +    if (vm->def->nconsoles) {
> > > > +        virDomainChrDefPtr chr = vm->def->consoles[0];
> > > 
> > > Given vm->def->nconsoles should we loop and do them all?
> > 
> > Maybe. libvirt it self will not be able to access any console that is
> > not the first one (virDomainOpenConsole only provide access to console
> > 0), but a consumer of libvirt could.
> > 
> > > Also, and I really should know the answer to this (and sorry for not
> > > thinking of it earlier), but:
> > > 
> > > > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > > > +                                        chr->target.port, console_type,
> > > > +                                        &console);
> > > 
> > > Might this race against xenconsoled writing the node to xenstore and
> > > therefore be prone to failing when starting multiple guests all at once?
> > 
> > I've look through out libxl, xenconsoled and libvirt, and I could not
> > find any synchronisation point. So I guest it's possible.
> > 
> > > Is there a hook which is called on virsh dumpxml which could update
> > > things on the fly (i.e. lookup the console iff it isn't already set)?
> > 
> > I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
> > to do the check, or having a xenstore watch on the path (if that is
> > possible).
> 
> The aop_console_how option to libxl_domain_create_new and
> libxl_domain_create_restore is documented as:
> 
>   /* A progress report will be made via ao_console_how, of type
>    * domain_create_console_available, when the domain's primary
>    * console is available and can be connected to.
>    */
> 
> Which sounds like exactly what is needed?

It looks like the progress is reported before the main function finish,
from the description of the type libxl_asyncprogress_how (in libxl.h).

Also, I tryied to use it, it works if xenconsoled is running. But if
xenconsoled is not running, then the callback is also called and
libxl_console_get_tty() return an empty string.

Or, maybe my test case is not relevant, so another question: Will
libxl wait for xenconsoled to process the new domain before calling the
callback?
Or, should I set the callback to NULL and have the
domain_create_console_available event sent through
the callback set by libxl_event_register_callbacks()?

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 17:15:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 17: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 1Y0ZEx-0005Mu-RI; Mon, 15 Dec 2014 17:15:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Y0ZEw-0005Mm-0b
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 17:15:22 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	74/96-09842-9271F845; Mon, 15 Dec 2014 17:15:21 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418663719!15706194!1
X-Originating-IP: [66.165.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 18986 invoked from network); 15 Dec 2014 17:15:20 -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;
	15 Dec 2014 17:15:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,580,1413244800"; d="scan'208";a="204986309"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 15 Dec 2014 12:07:57 -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 1Y0Z7l-0004hu-6j;
	Mon, 15 Dec 2014 17:07:57 +0000
Date: Mon, 15 Dec 2014 17:07:57 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141215170757.GA1705@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418314995.23309.7.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 11, 2014 at 04:23:15PM +0000, Ian Campbell wrote:
> On Thu, 2014-12-11 at 16:16 +0000, Anthony PERARD wrote:
> > On Tue, Dec 09, 2014 at 03:56:02PM +0000, Ian Campbell wrote:
> > > On Tue, 2014-12-09 at 15:39 +0000, Anthony PERARD wrote:
> > > > The path to the pty of a Xen PV console is set only in
> > > > virDomainOpenConsole. But this is done too late. A call to
> > > > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > > > the pty, but a call after OpenConsole will.
> > > > 
> > > > e.g. of the current issue.
> > > > Starting a domain with '<console type="pty"/>'
> > > > Then:
> > > > virDomainGetXMLDesc():
> > > >   <devices>
> > > >     <console type='pty'>
> > > >       <target type='xen' port='0'/>
> > > >     </console>
> > > >   </devices>
> > > > virDomainOpenConsole()
> > > > virDomainGetXMLDesc():
> > > >   <devices>
> > > >     <console type='pty' tty='/dev/pts/30'>
> > > >       <source path='/dev/pts/30'/>
> > > >       <target type='xen' port='0'/>
> > > >     </console>
> > > >   </devices>
> > > > 
> > > > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > > > This is done by setting up the path at domain start up instead of in
> > > > OpenConsole.
> > > > 
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > > > 
> > > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > > > 
> > > > ---
> > > > Change in V2:
> > > >   Adding bug report link.
> > > >   Reword the last part of the patch description.
> > > >   Cleanup the code.
> > > >   Use VIR_FREE before VIR_STRDUP.
> > > >   Remove the code from OpenConsole as it is now a duplicate.
> > > > ---
> > > >  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
> > > >  src/libxl/libxl_driver.c | 15 ---------------
> > > >  2 files changed, 20 insertions(+), 15 deletions(-)
> > > > 
> > > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > > index 9c62291..325de79 100644
> > > > --- a/src/libxl/libxl_domain.c
> > > > +++ b/src/libxl/libxl_domain.c
> > > > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> > > >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > > >          goto cleanup_dom;
> > > >  
> > > > +    if (vm->def->nconsoles) {
> > > > +        virDomainChrDefPtr chr = vm->def->consoles[0];
> > > 
> > > Given vm->def->nconsoles should we loop and do them all?
> > 
> > Maybe. libvirt it self will not be able to access any console that is
> > not the first one (virDomainOpenConsole only provide access to console
> > 0), but a consumer of libvirt could.
> > 
> > > Also, and I really should know the answer to this (and sorry for not
> > > thinking of it earlier), but:
> > > 
> > > > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > > > +                                        chr->target.port, console_type,
> > > > +                                        &console);
> > > 
> > > Might this race against xenconsoled writing the node to xenstore and
> > > therefore be prone to failing when starting multiple guests all at once?
> > 
> > I've look through out libxl, xenconsoled and libvirt, and I could not
> > find any synchronisation point. So I guest it's possible.
> > 
> > > Is there a hook which is called on virsh dumpxml which could update
> > > things on the fly (i.e. lookup the console iff it isn't already set)?
> > 
> > I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
> > to do the check, or having a xenstore watch on the path (if that is
> > possible).
> 
> The aop_console_how option to libxl_domain_create_new and
> libxl_domain_create_restore is documented as:
> 
>   /* A progress report will be made via ao_console_how, of type
>    * domain_create_console_available, when the domain's primary
>    * console is available and can be connected to.
>    */
> 
> Which sounds like exactly what is needed?

It looks like the progress is reported before the main function finish,
from the description of the type libxl_asyncprogress_how (in libxl.h).

Also, I tryied to use it, it works if xenconsoled is running. But if
xenconsoled is not running, then the callback is also called and
libxl_console_get_tty() return an empty string.

Or, maybe my test case is not relevant, so another question: Will
libxl wait for xenconsoled to process the new domain before calling the
callback?
Or, should I set the callback to NULL and have the
domain_create_console_available event sent through
the callback set by libxl_event_register_callbacks()?

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 18:05:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 18:05:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0a0w-0006dY-Uz; Mon, 15 Dec 2014 18:04:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1Y0a0v-0006dT-Oh
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 18:04:57 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	24/16-02699-9C22F845; Mon, 15 Dec 2014 18:04:57 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418666696!15208358!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18908 invoked from network); 15 Dec 2014 18:04:56 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 18:04:56 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so15267068wgh.40
	for <xen-devel@lists.xenproject.org>;
	Mon, 15 Dec 2014 10:04:56 -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:to:cc:subject
	:content-type:content-transfer-encoding;
	bh=cM1+EPJswGfl1IsJ9PPwfAklKoPNJvCu3DDYVW2mTA4=;
	b=o2qaoXZq+hrj2TwEOpAD5RgGENe9YERRAG78XflSPcytuqRkrV31oxDdyb/qAgSOlD
	xVhynKUy8FIAYoeT/TO+BCJWTZGvfaSWZTqXWbFEAzfIno0ZCe0iaF6NAEdOQCCjE17d
	KhZwjkxVSruae09n2Jq0OOBi3iAty3ec6NWe747PeSY0QOYbjGbdnFUX6CmLwZ5qim5d
	5xgOBU+fuGjO4+IaGMA6QxJLHEdfLa3d+0Fd3sVMt2Thc5ua56LoZ0PEL+y2+00I/XoY
	ZIqAafKREwhzCR9qAqH1f0MfxZVLL5a25UjzQwJUt0V4hc0y9xql78O8Sm8T1eCl4CEW
	pnLg==
X-Received: by 10.180.218.74 with SMTP id pe10mr33872226wic.48.1418666695621; 
	Mon, 15 Dec 2014 10:04:55 -0800 (PST)
Received: from [10.80.2.76] ([185.25.64.249])
	by mx.google.com with ESMTPSA id o2sm13883019wja.45.2014.12.15.10.04.54
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 15 Dec 2014 10:04:54 -0800 (PST)
Message-ID: <548F22C5.70401@cantab.net>
Date: Mon, 15 Dec 2014 18:04:53 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <Boris.Ostrovsky@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [GIT PULL] xen: additional features for 3.19-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git stable/for-linus-3.19-rc0b-tag

xen: additional features for 3.19-rc0

- - Linear p2m for x86 PV guests which simplifies the p2m code, improves
  performance and will allow for > 512 GB PV guests in the future.

Thanks.

A last-minute, configuration specific issue was discovered with this change
which is why it was not included in my previous pull request.  This is now been
fixed and tested.

David

 arch/x86/include/asm/pgtable_types.h |    1 +
 arch/x86/include/asm/xen/page.h      |   64 +-
 arch/x86/mm/pageattr.c               |   20 +
 arch/x86/xen/mmu.c                   |   40 +-
 arch/x86/xen/p2m.c                   | 1172 +++++++++++++---------------------
 arch/x86/xen/setup.c                 |  441 ++++++-------
 arch/x86/xen/xen-ops.h               |    6 +-
 7 files changed, 779 insertions(+), 965 deletions(-)

David Vrabel (1):
      Revert "swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single"

Juergen Gross (13):
      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
      xen: introduce helper functions to do safe read and write accesses
      xen: annotate xen_set_identity_and_remap_chunk() with __init
      xen: switch to post-init routines in xen mmu.c earlier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUjyK/AAoJEFxbo/MsZsTR2sQIAKpHjcGBVCKFoOGzfMjKGlab
cB/dAoTJD3iqde0ic0CH9hz2ZVHGz2yDA3PSBmuJf4QPMX2uCmE8K0RVZAtzntFj
YPsHWXDrsJBfBKBpi7gnmsNwA1VEVTW+3KYumPVprKOoAgYlVPzI/NdJxW+hucCo
gg8/f74OtEiyq8lOBo1Z7gYjh5nv4lc+1WgsaBGSWYWnn0zma6TGmB3jtBdryIuN
/KnPO4cFfkbx/nFwhlJ/mpMeC/ZI7aTU1u5Y1wAlcK3a9fItJT/WsD5orsGANddQ
rgeOceBCegd6YIQ6Q/CAu4uEqjNFgKz8G+0NyYI327/KaAQDykh8sKYQqUiK1Ew=
=UBAl
-----END PGP SIGNATURE-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 18:05:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 18:05:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0a0w-0006dY-Uz; Mon, 15 Dec 2014 18:04:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1Y0a0v-0006dT-Oh
	for xen-devel@lists.xenproject.org; Mon, 15 Dec 2014 18:04:57 +0000
Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id
	24/16-02699-9C22F845; Mon, 15 Dec 2014 18:04:57 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418666696!15208358!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18908 invoked from network); 15 Dec 2014 18:04:56 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 18:04:56 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so15267068wgh.40
	for <xen-devel@lists.xenproject.org>;
	Mon, 15 Dec 2014 10:04:56 -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:to:cc:subject
	:content-type:content-transfer-encoding;
	bh=cM1+EPJswGfl1IsJ9PPwfAklKoPNJvCu3DDYVW2mTA4=;
	b=o2qaoXZq+hrj2TwEOpAD5RgGENe9YERRAG78XflSPcytuqRkrV31oxDdyb/qAgSOlD
	xVhynKUy8FIAYoeT/TO+BCJWTZGvfaSWZTqXWbFEAzfIno0ZCe0iaF6NAEdOQCCjE17d
	KhZwjkxVSruae09n2Jq0OOBi3iAty3ec6NWe747PeSY0QOYbjGbdnFUX6CmLwZ5qim5d
	5xgOBU+fuGjO4+IaGMA6QxJLHEdfLa3d+0Fd3sVMt2Thc5ua56LoZ0PEL+y2+00I/XoY
	ZIqAafKREwhzCR9qAqH1f0MfxZVLL5a25UjzQwJUt0V4hc0y9xql78O8Sm8T1eCl4CEW
	pnLg==
X-Received: by 10.180.218.74 with SMTP id pe10mr33872226wic.48.1418666695621; 
	Mon, 15 Dec 2014 10:04:55 -0800 (PST)
Received: from [10.80.2.76] ([185.25.64.249])
	by mx.google.com with ESMTPSA id o2sm13883019wja.45.2014.12.15.10.04.54
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 15 Dec 2014 10:04:54 -0800 (PST)
Message-ID: <548F22C5.70401@cantab.net>
Date: Mon, 15 Dec 2014 18:04:53 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <Boris.Ostrovsky@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [GIT PULL] xen: additional features for 3.19-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git stable/for-linus-3.19-rc0b-tag

xen: additional features for 3.19-rc0

- - Linear p2m for x86 PV guests which simplifies the p2m code, improves
  performance and will allow for > 512 GB PV guests in the future.

Thanks.

A last-minute, configuration specific issue was discovered with this change
which is why it was not included in my previous pull request.  This is now been
fixed and tested.

David

 arch/x86/include/asm/pgtable_types.h |    1 +
 arch/x86/include/asm/xen/page.h      |   64 +-
 arch/x86/mm/pageattr.c               |   20 +
 arch/x86/xen/mmu.c                   |   40 +-
 arch/x86/xen/p2m.c                   | 1172 +++++++++++++---------------------
 arch/x86/xen/setup.c                 |  441 ++++++-------
 arch/x86/xen/xen-ops.h               |    6 +-
 7 files changed, 779 insertions(+), 965 deletions(-)

David Vrabel (1):
      Revert "swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single"

Juergen Gross (13):
      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
      xen: introduce helper functions to do safe read and write accesses
      xen: annotate xen_set_identity_and_remap_chunk() with __init
      xen: switch to post-init routines in xen mmu.c earlier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUjyK/AAoJEFxbo/MsZsTR2sQIAKpHjcGBVCKFoOGzfMjKGlab
cB/dAoTJD3iqde0ic0CH9hz2ZVHGz2yDA3PSBmuJf4QPMX2uCmE8K0RVZAtzntFj
YPsHWXDrsJBfBKBpi7gnmsNwA1VEVTW+3KYumPVprKOoAgYlVPzI/NdJxW+hucCo
gg8/f74OtEiyq8lOBo1Z7gYjh5nv4lc+1WgsaBGSWYWnn0zma6TGmB3jtBdryIuN
/KnPO4cFfkbx/nFwhlJ/mpMeC/ZI7aTU1u5Y1wAlcK3a9fItJT/WsD5orsGANddQ
rgeOceBCegd6YIQ6Q/CAu4uEqjNFgKz8G+0NyYI327/KaAQDykh8sKYQqUiK1Ew=
=UBAl
-----END PGP SIGNATURE-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 18:14:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 18:14:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0a9V-0006zB-55; Mon, 15 Dec 2014 18:13: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 1Y0a9T-0006z6-4s
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 18:13:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6F/64-09842-AD42F845; Mon, 15 Dec 2014 18:13:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418667224!15733607!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 19943 invoked from network); 15 Dec 2014 18:13:45 -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;
	15 Dec 2014 18:13:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,581,1413244800"; d="scan'208";a="205006011"
Message-ID: <1418665524.16425.171.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Mon, 15 Dec 2014 17:45:24 +0000
In-Reply-To: <1418655014.16425.138.camel@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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 Mon, 2014-12-15 at 14:50 +0000, Ian Campbell wrote:
> On Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
> > I just noticed something strange:
> > 
> > > #3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
> > > 0xff00000000 out of bounds>, hash_size=0,
> > >     tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
> > > #4  0x000000000040a70b in tdb_copy (tdb=0x192e540, outfile=0x1941fb0
> > > "/var/lib/xenstored/tdb.0x1935bb0")
> > 
> > Why does gdb-7.0.1 print "name=0xff000000" here for frame 3, but for
> > frame 2 and 4 the pointers are correct again?
> > Verifying the values with an explicit "print" shows them as correct.
> 
> I has just noticed that and was wondering about that same thing. I'm
> starting to worry that 0xff00000000 might just be a gdb thing, similar
> to <value optimized out>, but infinitely more misleading.

I'm reasonably convinced now that this is just a weird artefact of
running gdb on an optimised binary, probably a shortcoming in the debug
info leading to gdb getting confused.

Unfortunately this also calls into doubt the parameter to talloc_free,
perhaps in that context 0xff0000000 is a similar artefact.

Please can you print the entire contents of tdb in the second frame
("print *tdb" ought to do it). I'm curious whether it is all sane or
not.

Please can you also print "info regs" at the point of the segv (in frame
0) as well as "disas" at that point.

Can you also "p $_siginfo._sifields._sigfault.si_addr" (in frame 0).
This ought to be the actual faulting address, which ought to give a hint
on how much we can trust the parameters in the stack trace.

Since I'm asking for the world I may as well ask you to dump the raw
stack too "x/64x $sp" ought to be a good starting point.

I notice in your bugzilla (for a different occurrence, I think):
> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]

Which appears to have faulted access 0xff000000000 too. It looks like
this process is a python thing, it's nothing to do with xenstored I
assume? It seems rather coincidental that it should be accessing the 
same sort of address and be faulting.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 18:14:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 18:14:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0a9V-0006zB-55; Mon, 15 Dec 2014 18:13: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 1Y0a9T-0006z6-4s
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 18:13:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6F/64-09842-AD42F845; Mon, 15 Dec 2014 18:13:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418667224!15733607!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 19943 invoked from network); 15 Dec 2014 18:13:45 -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;
	15 Dec 2014 18:13:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,581,1413244800"; d="scan'208";a="205006011"
Message-ID: <1418665524.16425.171.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Mon, 15 Dec 2014 17:45:24 +0000
In-Reply-To: <1418655014.16425.138.camel@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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 Mon, 2014-12-15 at 14:50 +0000, Ian Campbell wrote:
> On Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
> > I just noticed something strange:
> > 
> > > #3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
> > > 0xff00000000 out of bounds>, hash_size=0,
> > >     tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
> > > #4  0x000000000040a70b in tdb_copy (tdb=0x192e540, outfile=0x1941fb0
> > > "/var/lib/xenstored/tdb.0x1935bb0")
> > 
> > Why does gdb-7.0.1 print "name=0xff000000" here for frame 3, but for
> > frame 2 and 4 the pointers are correct again?
> > Verifying the values with an explicit "print" shows them as correct.
> 
> I has just noticed that and was wondering about that same thing. I'm
> starting to worry that 0xff00000000 might just be a gdb thing, similar
> to <value optimized out>, but infinitely more misleading.

I'm reasonably convinced now that this is just a weird artefact of
running gdb on an optimised binary, probably a shortcoming in the debug
info leading to gdb getting confused.

Unfortunately this also calls into doubt the parameter to talloc_free,
perhaps in that context 0xff0000000 is a similar artefact.

Please can you print the entire contents of tdb in the second frame
("print *tdb" ought to do it). I'm curious whether it is all sane or
not.

Please can you also print "info regs" at the point of the segv (in frame
0) as well as "disas" at that point.

Can you also "p $_siginfo._sifields._sigfault.si_addr" (in frame 0).
This ought to be the actual faulting address, which ought to give a hint
on how much we can trust the parameters in the stack trace.

Since I'm asking for the world I may as well ask you to dump the raw
stack too "x/64x $sp" ought to be a good starting point.

I notice in your bugzilla (for a different occurrence, I think):
> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]

Which appears to have faulted access 0xff000000000 too. It looks like
this process is a python thing, it's nothing to do with xenstored I
assume? It seems rather coincidental that it should be accessing the 
same sort of address and be faulting.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 19:34:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 19:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0bOj-00010i-St; Mon, 15 Dec 2014 19:33:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek.xen@gmail.com>)
	id 1Y0bOh-000102-UE; Mon, 15 Dec 2014 19:33:36 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	11/AA-28865-F873F845; Mon, 15 Dec 2014 19:33:35 +0000
X-Env-Sender: russell.pavlicek.xen@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418672014!13452195!1
X-Originating-IP: [209.85.215.44]
X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP,
  SUSPICIOUS_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26279 invoked from network); 15 Dec 2014 19:33:34 -0000
Received: from mail-la0-f44.google.com (HELO mail-la0-f44.google.com)
	(209.85.215.44)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 19:33:34 -0000
Received: by mail-la0-f44.google.com with SMTP id gd6so10151006lab.17
	for <multiple recipients>; Mon, 15 Dec 2014 11:33:33 -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=7JCCyf6D6ODSy4vnOa90gWOm+uFIx/9shetJ8P46w/w=;
	b=0lPeIKL1KavE5vlhlt0ZK3siMWqX/67GZ8psLRisgiAHyEOjPthGVoQwtRJKht0HyI
	i3lmi75MXlnJ7j7x/ZI4IpVa+Gm53icpQib0WbAhjw5+CHh9kIQ4uT/n8X91UxvbHYZp
	Z6TbOPE53maVPP4fhIRDF+oBw3FShl0MKpJ86fJavhwh7a+gSzUGjP/LT9AVyXY39QHp
	k0f9Dqzpjtr1bNmuAXW0gEDKe6KIHyaa5LqJSYll4Bh/8JCH3OO0YdeiekJNSjmw+1dG
	VT1ukNLUvL/AJVYb0ZDxMfFSRQ+K4nAesRFCHadpVMj1ekQxX7CboxLzNV80nsqj+mb+
	z7CA==
MIME-Version: 1.0
X-Received: by 10.152.22.199 with SMTP id g7mr32128361laf.23.1418672013522;
	Mon, 15 Dec 2014 11:33:33 -0800 (PST)
Received: by 10.112.0.104 with HTTP; Mon, 15 Dec 2014 11:33:33 -0800 (PST)
Date: Mon, 15 Dec 2014 14:33:33 -0500
X-Google-Sender-Auth: yMPoFFj8CUUqcuCLhNWJRWHDkNI
Message-ID: <CAHehzX0pBPaWuUjZE-wMR+D=2_A06VJN7Nr=rrmxpYiVCQTNug@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-announce@lists.xenproject.org, 
	xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org, 
	xen-api@lists.xen.org
Subject: [Xen-devel] Xen Project 4.5 RC4 is Ready Today;
	Test Day is Wednesday
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Wednesday, December 17, is our fourth and FINAL Test Day
for the 4.5 release cycle (barring any changes which may result from
Wednesday's Test Day). Release Candidate 4 is available for
assessment today.

If you've held off testing the new release until it matures, delay no
longer!  Test and state your concerns now or the next release you
see could be the official one

Information about testing this release can be found here:
http://wiki.xenproject.org/wiki/Xen_4.5_RC4_test_instructions

To learn more about Test Days, including the scheduled date
for the final release, check out:
http://wiki.xenproject.org/wiki/Xen_Project_Test_Days

See you in #xentest on IRC this Wednesday 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 Mon Dec 15 19:34:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 19:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0bOj-00010i-St; Mon, 15 Dec 2014 19:33:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek.xen@gmail.com>)
	id 1Y0bOh-000102-UE; Mon, 15 Dec 2014 19:33:36 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	11/AA-28865-F873F845; Mon, 15 Dec 2014 19:33:35 +0000
X-Env-Sender: russell.pavlicek.xen@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418672014!13452195!1
X-Originating-IP: [209.85.215.44]
X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP,
  SUSPICIOUS_RECIPS
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26279 invoked from network); 15 Dec 2014 19:33:34 -0000
Received: from mail-la0-f44.google.com (HELO mail-la0-f44.google.com)
	(209.85.215.44)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Dec 2014 19:33:34 -0000
Received: by mail-la0-f44.google.com with SMTP id gd6so10151006lab.17
	for <multiple recipients>; Mon, 15 Dec 2014 11:33:33 -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=7JCCyf6D6ODSy4vnOa90gWOm+uFIx/9shetJ8P46w/w=;
	b=0lPeIKL1KavE5vlhlt0ZK3siMWqX/67GZ8psLRisgiAHyEOjPthGVoQwtRJKht0HyI
	i3lmi75MXlnJ7j7x/ZI4IpVa+Gm53icpQib0WbAhjw5+CHh9kIQ4uT/n8X91UxvbHYZp
	Z6TbOPE53maVPP4fhIRDF+oBw3FShl0MKpJ86fJavhwh7a+gSzUGjP/LT9AVyXY39QHp
	k0f9Dqzpjtr1bNmuAXW0gEDKe6KIHyaa5LqJSYll4Bh/8JCH3OO0YdeiekJNSjmw+1dG
	VT1ukNLUvL/AJVYb0ZDxMfFSRQ+K4nAesRFCHadpVMj1ekQxX7CboxLzNV80nsqj+mb+
	z7CA==
MIME-Version: 1.0
X-Received: by 10.152.22.199 with SMTP id g7mr32128361laf.23.1418672013522;
	Mon, 15 Dec 2014 11:33:33 -0800 (PST)
Received: by 10.112.0.104 with HTTP; Mon, 15 Dec 2014 11:33:33 -0800 (PST)
Date: Mon, 15 Dec 2014 14:33:33 -0500
X-Google-Sender-Auth: yMPoFFj8CUUqcuCLhNWJRWHDkNI
Message-ID: <CAHehzX0pBPaWuUjZE-wMR+D=2_A06VJN7Nr=rrmxpYiVCQTNug@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-announce@lists.xenproject.org, 
	xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org, 
	xen-api@lists.xen.org
Subject: [Xen-devel] Xen Project 4.5 RC4 is Ready Today;
	Test Day is Wednesday
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Wednesday, December 17, is our fourth and FINAL Test Day
for the 4.5 release cycle (barring any changes which may result from
Wednesday's Test Day). Release Candidate 4 is available for
assessment today.

If you've held off testing the new release until it matures, delay no
longer!  Test and state your concerns now or the next release you
see could be the official one

Information about testing this release can be found here:
http://wiki.xenproject.org/wiki/Xen_4.5_RC4_test_instructions

To learn more about Test Days, including the scheduled date
for the final release, check out:
http://wiki.xenproject.org/wiki/Xen_Project_Test_Days

See you in #xentest on IRC this Wednesday 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 Mon Dec 15 21:57:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 21: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 1Y0ddG-0004VK-9v; Mon, 15 Dec 2014 21:56:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Y0ddF-0004VF-8M
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 21:56:45 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	CA/83-02712-C195F845; Mon, 15 Dec 2014 21:56:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418680602!15221359!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22609 invoked from network); 15 Dec 2014 21:56:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 21:56: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 sBFLuf60008677
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Dec 2014 21:56: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
	sBFLuerN005462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 15 Dec 2014 21:56:40 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
	sBFLue6S005453; Mon, 15 Dec 2014 21:56:40 GMT
Received: from ovs101.us.oracle.com (/10.149.76.201)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 15 Dec 2014 13:56:39 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, konrad.wilk@oracle.com
Date: Mon, 15 Dec 2014 17:24:35 -0500
Message-Id: <1418682275-2505-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 for 4.5] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.

We have to do this via IPI since otherwise there is a (somewheat
theoretical) chance that between test and subsequent clearing
of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
both load_vpmu() and then save_vpmu() for another VCPU. The former
will clear last_vcpu and the latter will set it to something else.

Performing this operation via IPI will guarantee that nothing can
happen on the remote processor between testing and clearing of
last_vcpu.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/vpmu.c |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

Changes in v2:
 * Test last_vcpu locally before IPI
 * Don't handle local pcpu as a special case --- on_selected_cpus
   will take care of that
 * Dont't cast variables unnecessarily

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1df74c2..37f0d9f 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -247,10 +247,30 @@ void vpmu_initialise(struct vcpu *v)
     }
 }
 
+static void vpmu_clear_last(void *arg)
+{
+    if ( this_cpu(last_vcpu) == arg )
+        this_cpu(last_vcpu) = NULL;
+}
+
 void vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
+        return;
+
+    /*
+     * Need to clear last_vcpu in case it points to v.
+     * We can check here non-atomically whether it is 'v' since
+     * last_vcpu can never become 'v' again at this point.
+     * We will test it again in vpmu_clear_last() with interrupts
+     * disabled to make sure we don't clear someone else.
+     */
+    if ( per_cpu(last_vcpu, vpmu->last_pcpu) == v )
+        on_selected_cpus(cpumask_of(vpmu->last_pcpu),
+                         vpmu_clear_last, v, 1);
+
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
         vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
 }
-- 
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 Dec 15 21:57:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 21: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 1Y0ddG-0004VK-9v; Mon, 15 Dec 2014 21:56:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Y0ddF-0004VF-8M
	for xen-devel@lists.xen.org; Mon, 15 Dec 2014 21:56:45 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	CA/83-02712-C195F845; Mon, 15 Dec 2014 21:56:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418680602!15221359!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22609 invoked from network); 15 Dec 2014 21:56:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 21:56: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 sBFLuf60008677
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Dec 2014 21:56: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
	sBFLuerN005462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 15 Dec 2014 21:56:40 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
	sBFLue6S005453; Mon, 15 Dec 2014 21:56:40 GMT
Received: from ovs101.us.oracle.com (/10.149.76.201)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 15 Dec 2014 13:56:39 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, konrad.wilk@oracle.com
Date: Mon, 15 Dec 2014 17:24:35 -0500
Message-Id: <1418682275-2505-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 for 4.5] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.

We have to do this via IPI since otherwise there is a (somewheat
theoretical) chance that between test and subsequent clearing
of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
both load_vpmu() and then save_vpmu() for another VCPU. The former
will clear last_vcpu and the latter will set it to something else.

Performing this operation via IPI will guarantee that nothing can
happen on the remote processor between testing and clearing of
last_vcpu.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/vpmu.c |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

Changes in v2:
 * Test last_vcpu locally before IPI
 * Don't handle local pcpu as a special case --- on_selected_cpus
   will take care of that
 * Dont't cast variables unnecessarily

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1df74c2..37f0d9f 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -247,10 +247,30 @@ void vpmu_initialise(struct vcpu *v)
     }
 }
 
+static void vpmu_clear_last(void *arg)
+{
+    if ( this_cpu(last_vcpu) == arg )
+        this_cpu(last_vcpu) = NULL;
+}
+
 void vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
+        return;
+
+    /*
+     * Need to clear last_vcpu in case it points to v.
+     * We can check here non-atomically whether it is 'v' since
+     * last_vcpu can never become 'v' again at this point.
+     * We will test it again in vpmu_clear_last() with interrupts
+     * disabled to make sure we don't clear someone else.
+     */
+    if ( per_cpu(last_vcpu, vpmu->last_pcpu) == v )
+        on_selected_cpus(cpumask_of(vpmu->last_pcpu),
+                         vpmu_clear_last, v, 1);
+
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
         vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
 }
-- 
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 Dec 15 22:29:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 22: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 1Y0e8s-0005Cu-6l; Mon, 15 Dec 2014 22:29:26 +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 1Y0e8q-0005Cp-6F
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 22:29:24 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	19/40-09842-3C06F845; Mon, 15 Dec 2014 22:29:23 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418682562!15811728!1
X-Originating-IP: [82.198.197.8]
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 15045 invoked from network); 15 Dec 2014 22:29:22 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 22:29:22 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id C278D1101276;
	Mon, 15 Dec 2014 23:29:21 +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 5kXFkOXy04Xo; Mon, 15 Dec 2014 23:29:21 +0100 (CET)
Received: from [192.168.1.35] (x2f1b67d.dyn.telefonica.de [2.241.182.125])
	by solig.knut.univention.de (Postfix) with ESMTPSA id B04C81101279;
	Mon, 15 Dec 2014 23:29:20 +0100 (CET)
Message-ID: <548F60BF.4020901@univention.de>
Date: Mon, 15 Dec 2014 23:29:19 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>	
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>	
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>	
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>	
	<1418407116.16425.53.camel@citrix.com>	
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>	
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
In-Reply-To: <1418665524.16425.171.camel@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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

Hello Ian,

On 15.12.2014 18:45, Ian Campbell wrote:
> On Mon, 2014-12-15 at 14:50 +0000, Ian Campbell wrote:
>> On Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
>>> I just noticed something strange:
>>>
>>>> #3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
>>>> 0xff00000000 out of bounds>, hash_size=0,
>>>>     tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
...
> I'm reasonably convinced now that this is just a weird artefact of
> running gdb on an optimised binary, probably a shortcoming in the debug
> info leading to gdb getting confused.
> 
> Unfortunately this also calls into doubt the parameter to talloc_free,
> perhaps in that context 0xff0000000 is a similar artefact.
> 
> Please can you print the entire contents of tdb in the second frame
> ("print *tdb" ought to do it). I'm curious whether it is all sane or
> not.

(gdb) print *tdb
$1 = {name = 0x0, map_ptr = 0x0, fd = 47, map_size = 65280, read_only =
16711680,
  locked = 0xff0000000000, ecode = 16711680, header = {
    magic_food =
"\000\000\000\000\000\000\000\000\000\377\000\000\000\000\377\000\000\000\000\000\000\000\000\000\000\377\000\000\000\000\377",
version = 0, hash_size = 0,
    rwlocks = 65280, reserved = {16711680, 0, 0, 65280, 16711680, 0, 0,
65280,
      16711680, 0, 0, 65280, 16711680, 0, 0, 65280, 16711680, 0, 0,
65280, 16711680,
      0, 0, 65280, 16711680, 0, 0, 65280, 16711680, 0, 0}}, flags = 0,
travlocks = {
    next = 0xff0000, off = 0, hash = 65280}, next = 0xff0000,
  device = 280375465082880, inode = 16711680, log_fn = 0x4093b0
<null_log_fn>,
  hash_fn = 0x4092f0 <default_tdb_hash>, open_flags = 2}

> Please can you also print "info regs" at the point of the segv (in frame
> 0) as well as "disas" at that point.

(gdb) info registers
rax            0x0      0
rbx            0x16bff70        23854960
rcx            0xffffffffffffffff       -1
rdx            0x40ecd0 4254928
rsi            0x0      0
rdi            0xff0000000000   280375465082880
rbp            0x7fcaed6c96a8   0x7fcaed6c96a8
rsp            0x7fff9dc86330   0x7fff9dc86330
r8             0x7fcaece54c08   140509534571528
r9             0xff00000000000000       -72057594037927936
r10            0x7fcaed08c14c   140509536895308
r11            0x246    582
r12            0xd      13
r13            0xff0000000000   280375465082880
r14            0x4093b0 4232112
r15            0x167d620        23582240
rip            0x4075c4 0x4075c4 <talloc_chunk_from_ptr+4>
eflags         0x10206  [ PF IF RF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
fctrl          0x0      0
fstat          0x0      0
ftag           0x0      0
fiseg          0x0      0
fioff          0x0      0
foseg          0x0      0
fooff          0x0      0
fop            0x0      0
mxcsr          0x0      [ ]

(gdb) disassemble
Dump of assembler code for function talloc_chunk_from_ptr:
0x00000000004075c0 <talloc_chunk_from_ptr+0>:   sub    $0x8,%rsp
0x00000000004075c4 <talloc_chunk_from_ptr+4>:   mov    -0x8(%rdi),%edx
0x00000000004075c7 <talloc_chunk_from_ptr+7>:   lea    -0x50(%rdi),%rax
0x00000000004075cb <talloc_chunk_from_ptr+11>:  mov    %edx,%ecx
0x00000000004075cd <talloc_chunk_from_ptr+13>:  and
$0xfffffffffffffff0,%ecx
0x00000000004075d0 <talloc_chunk_from_ptr+16>:  cmp    $0xe814ec70,%ecx
0x00000000004075d6 <talloc_chunk_from_ptr+22>:  jne    0x4075e2
<talloc_chunk_from_ptr+34>
0x00000000004075d8 <talloc_chunk_from_ptr+24>:  and    $0x1,%edx
0x00000000004075db <talloc_chunk_from_ptr+27>:  jne    0x4075e2
<talloc_chunk_from_ptr+34>
0x00000000004075dd <talloc_chunk_from_ptr+29>:  add    $0x8,%rsp
0x00000000004075e1 <talloc_chunk_from_ptr+33>:  retq
0x00000000004075e2 <talloc_chunk_from_ptr+34>:  nopw   0x0(%rax,%rax,1)
0x00000000004075e8 <talloc_chunk_from_ptr+40>:  callq  0x401b98 <abort@plt>

> Can you also "p $_siginfo._sifields._sigfault.si_addr" (in frame 0).
> This ought to be the actual faulting address, which ought to give a hint
> on how much we can trust the parameters in the stack trace.

Hmm, my gdb refused to access $_siginfo:
(gdb) show convenience
$_siginfo = Unable to read siginfo

> Since I'm asking for the world I may as well ask you to dump the raw
> stack too "x/64x $sp" ought to be a good starting point.

(gdb) x/64x $sp
0x7fff9dc86330: 0xed6c96a8      0x00007fca      0x00407edf      0x00000000
0x7fff9dc86340: 0x00000000      0x00000000      0x016bff70      0x00000000
0x7fff9dc86350: 0xed6c96a8      0x00007fca      0x0000000d      0x00000000
0x7fff9dc86360: 0x00000000      0x00000000      0x004093b0      0x00000000
0x7fff9dc86370: 0x0167d620      0x00000000      0x0040a348      0x00000000
0x7fff9dc86380: 0x00000000      0x00000000      0x00000000      0x00000000
0x7fff9dc86390: 0x00000000      0x00000000      0x00000000      0x00000000
0x7fff9dc863a0: 0x00000011      0x00000000      0x411d4816      0x00000000
0x7fff9dc863b0: 0x00000001      0x00000000      0x000081a0      0x00000000
0x7fff9dc863c0: 0x00000000      0x00000000      0x00000000      0x00000000
0x7fff9dc863d0: 0x00096000      0x00000000      0x00001000      0x00000000
0x7fff9dc863e0: 0x000004b0      0x00000000      0x5438ba01      0x00000000
0x7fff9dc863f0: 0x07fd332e      0x00000000      0x5438ba01      0x00000000
0x7fff9dc86400: 0x07fd332e      0x00000000      0x5438ba01      0x00000000
0x7fff9dc86410: 0x07fd332e      0x00000000      0x00000000      0x00000000
0x7fff9dc86420: 0x00000000      0x00000000      0x00000000      0x00000000

> I notice in your bugzilla (for a different occurrence, I think):
>> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
> 
> Which appears to have faulted access 0xff000000000 too. It looks like
> this process is a python thing, it's nothing to do with xenstored I
> assume?

Yes, that's one univention-config, which is completely independent of
xen(stored).

> It seems rather coincidental that it should be accessing the 
> same sort of address and be faulting.

Yes, good catch. I'll have another look at those core dumps.

> Ian.

Thank you for your help.
Philipp Hahn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 15 22:29:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Dec 2014 22: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 1Y0e8s-0005Cu-6l; Mon, 15 Dec 2014 22:29:26 +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 1Y0e8q-0005Cp-6F
	for Xen-devel@lists.xen.org; Mon, 15 Dec 2014 22:29:24 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	19/40-09842-3C06F845; Mon, 15 Dec 2014 22:29:23 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418682562!15811728!1
X-Originating-IP: [82.198.197.8]
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 15045 invoked from network); 15 Dec 2014 22:29:22 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Dec 2014 22:29:22 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id C278D1101276;
	Mon, 15 Dec 2014 23:29:21 +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 5kXFkOXy04Xo; Mon, 15 Dec 2014 23:29:21 +0100 (CET)
Received: from [192.168.1.35] (x2f1b67d.dyn.telefonica.de [2.241.182.125])
	by solig.knut.univention.de (Postfix) with ESMTPSA id B04C81101279;
	Mon, 15 Dec 2014 23:29:20 +0100 (CET)
Message-ID: <548F60BF.4020901@univention.de>
Date: Mon, 15 Dec 2014 23:29:19 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>	
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>	
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>	
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>	
	<1418407116.16425.53.camel@citrix.com>	
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>	
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
In-Reply-To: <1418665524.16425.171.camel@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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

Hello Ian,

On 15.12.2014 18:45, Ian Campbell wrote:
> On Mon, 2014-12-15 at 14:50 +0000, Ian Campbell wrote:
>> On Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
>>> I just noticed something strange:
>>>
>>>> #3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
>>>> 0xff00000000 out of bounds>, hash_size=0,
>>>>     tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
...
> I'm reasonably convinced now that this is just a weird artefact of
> running gdb on an optimised binary, probably a shortcoming in the debug
> info leading to gdb getting confused.
> 
> Unfortunately this also calls into doubt the parameter to talloc_free,
> perhaps in that context 0xff0000000 is a similar artefact.
> 
> Please can you print the entire contents of tdb in the second frame
> ("print *tdb" ought to do it). I'm curious whether it is all sane or
> not.

(gdb) print *tdb
$1 = {name = 0x0, map_ptr = 0x0, fd = 47, map_size = 65280, read_only =
16711680,
  locked = 0xff0000000000, ecode = 16711680, header = {
    magic_food =
"\000\000\000\000\000\000\000\000\000\377\000\000\000\000\377\000\000\000\000\000\000\000\000\000\000\377\000\000\000\000\377",
version = 0, hash_size = 0,
    rwlocks = 65280, reserved = {16711680, 0, 0, 65280, 16711680, 0, 0,
65280,
      16711680, 0, 0, 65280, 16711680, 0, 0, 65280, 16711680, 0, 0,
65280, 16711680,
      0, 0, 65280, 16711680, 0, 0, 65280, 16711680, 0, 0}}, flags = 0,
travlocks = {
    next = 0xff0000, off = 0, hash = 65280}, next = 0xff0000,
  device = 280375465082880, inode = 16711680, log_fn = 0x4093b0
<null_log_fn>,
  hash_fn = 0x4092f0 <default_tdb_hash>, open_flags = 2}

> Please can you also print "info regs" at the point of the segv (in frame
> 0) as well as "disas" at that point.

(gdb) info registers
rax            0x0      0
rbx            0x16bff70        23854960
rcx            0xffffffffffffffff       -1
rdx            0x40ecd0 4254928
rsi            0x0      0
rdi            0xff0000000000   280375465082880
rbp            0x7fcaed6c96a8   0x7fcaed6c96a8
rsp            0x7fff9dc86330   0x7fff9dc86330
r8             0x7fcaece54c08   140509534571528
r9             0xff00000000000000       -72057594037927936
r10            0x7fcaed08c14c   140509536895308
r11            0x246    582
r12            0xd      13
r13            0xff0000000000   280375465082880
r14            0x4093b0 4232112
r15            0x167d620        23582240
rip            0x4075c4 0x4075c4 <talloc_chunk_from_ptr+4>
eflags         0x10206  [ PF IF RF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
fctrl          0x0      0
fstat          0x0      0
ftag           0x0      0
fiseg          0x0      0
fioff          0x0      0
foseg          0x0      0
fooff          0x0      0
fop            0x0      0
mxcsr          0x0      [ ]

(gdb) disassemble
Dump of assembler code for function talloc_chunk_from_ptr:
0x00000000004075c0 <talloc_chunk_from_ptr+0>:   sub    $0x8,%rsp
0x00000000004075c4 <talloc_chunk_from_ptr+4>:   mov    -0x8(%rdi),%edx
0x00000000004075c7 <talloc_chunk_from_ptr+7>:   lea    -0x50(%rdi),%rax
0x00000000004075cb <talloc_chunk_from_ptr+11>:  mov    %edx,%ecx
0x00000000004075cd <talloc_chunk_from_ptr+13>:  and
$0xfffffffffffffff0,%ecx
0x00000000004075d0 <talloc_chunk_from_ptr+16>:  cmp    $0xe814ec70,%ecx
0x00000000004075d6 <talloc_chunk_from_ptr+22>:  jne    0x4075e2
<talloc_chunk_from_ptr+34>
0x00000000004075d8 <talloc_chunk_from_ptr+24>:  and    $0x1,%edx
0x00000000004075db <talloc_chunk_from_ptr+27>:  jne    0x4075e2
<talloc_chunk_from_ptr+34>
0x00000000004075dd <talloc_chunk_from_ptr+29>:  add    $0x8,%rsp
0x00000000004075e1 <talloc_chunk_from_ptr+33>:  retq
0x00000000004075e2 <talloc_chunk_from_ptr+34>:  nopw   0x0(%rax,%rax,1)
0x00000000004075e8 <talloc_chunk_from_ptr+40>:  callq  0x401b98 <abort@plt>

> Can you also "p $_siginfo._sifields._sigfault.si_addr" (in frame 0).
> This ought to be the actual faulting address, which ought to give a hint
> on how much we can trust the parameters in the stack trace.

Hmm, my gdb refused to access $_siginfo:
(gdb) show convenience
$_siginfo = Unable to read siginfo

> Since I'm asking for the world I may as well ask you to dump the raw
> stack too "x/64x $sp" ought to be a good starting point.

(gdb) x/64x $sp
0x7fff9dc86330: 0xed6c96a8      0x00007fca      0x00407edf      0x00000000
0x7fff9dc86340: 0x00000000      0x00000000      0x016bff70      0x00000000
0x7fff9dc86350: 0xed6c96a8      0x00007fca      0x0000000d      0x00000000
0x7fff9dc86360: 0x00000000      0x00000000      0x004093b0      0x00000000
0x7fff9dc86370: 0x0167d620      0x00000000      0x0040a348      0x00000000
0x7fff9dc86380: 0x00000000      0x00000000      0x00000000      0x00000000
0x7fff9dc86390: 0x00000000      0x00000000      0x00000000      0x00000000
0x7fff9dc863a0: 0x00000011      0x00000000      0x411d4816      0x00000000
0x7fff9dc863b0: 0x00000001      0x00000000      0x000081a0      0x00000000
0x7fff9dc863c0: 0x00000000      0x00000000      0x00000000      0x00000000
0x7fff9dc863d0: 0x00096000      0x00000000      0x00001000      0x00000000
0x7fff9dc863e0: 0x000004b0      0x00000000      0x5438ba01      0x00000000
0x7fff9dc863f0: 0x07fd332e      0x00000000      0x5438ba01      0x00000000
0x7fff9dc86400: 0x07fd332e      0x00000000      0x5438ba01      0x00000000
0x7fff9dc86410: 0x07fd332e      0x00000000      0x00000000      0x00000000
0x7fff9dc86420: 0x00000000      0x00000000      0x00000000      0x00000000

> I notice in your bugzilla (for a different occurrence, I think):
>> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
> 
> Which appears to have faulted access 0xff000000000 too. It looks like
> this process is a python thing, it's nothing to do with xenstored I
> assume?

Yes, that's one univention-config, which is completely independent of
xen(stored).

> It seems rather coincidental that it should be accessing the 
> same sort of address and be faulting.

Yes, good catch. I'll have another look at those core dumps.

> Ian.

Thank you for your help.
Philipp Hahn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 02:02:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 02: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 1Y0hSg-0005XW-OJ; Tue, 16 Dec 2014 02:02:06 +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 1Y0hSf-0005XR-1y
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 02:02:05 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	F2/FA-02698-C929F845; Tue, 16 Dec 2014 02:02:04 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418695322!15275971!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12124 invoked from network); 16 Dec 2014 02:02:03 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-27.messagelabs.com with SMTP;
	16 Dec 2014 02:02:03 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 15 Dec 2014 18:02:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="429405339"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by FMSMGA003.fm.intel.com with ESMTP; 15 Dec 2014 17:50:57 -0800
Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 16 Dec 2014 10:01:58 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 16 Dec 2014 10:01:58 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.67]) with mapi id
	14.03.0195.001; Tue, 16 Dec 2014 10:01:58 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [PATCH 09/12] vTPM/TPM2: Support '--tpm2' extra command line.
Thread-Index: AQHQGH+Li0lPaHnAvkqzBkmML6uXAZyRdYOw
Date: Tue, 16 Dec 2014 02:01:57 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E84CD32@SHSMSX101.ccr.corp.intel.com>
References: <1418558993-13681-1-git-send-email-quan.xu@intel.com>
	<548F046F.9030208@tycho.nsa.gov>
In-Reply-To: <548F046F.9030208@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>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 09/12] vTPM/TPM2: Support '--tpm2' extra
	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



> -----Original Message-----
> From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> Sent: Monday, December 15, 2014 11:55 PM
> To: Xu, Quan; xen-devel@lists.xen.org
> Cc: stefano.stabellini@eu.citrix.com; samuel.thibault@ens-lyon.org
> Subject: Re: [PATCH 09/12] vTPM/TPM2: Support '--tpm2' extra command
> line.
> 
> On 12/14/2014 07:09 AM, Quan Xu wrote:
> > Make vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
> > Add:
> > ..
> >       extra="--tpm2"
> > ..
> > to launch vtpm-stubdom domain on TPM 2.0, ignore it on TPM 1.x. for
> > example, vtpm-stubdom domain configuration on TPM 2.0:
> >
> > kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
> > memory=16
> > disk=["file:/var/scale/vdisk/vmgr,hda,w"]
> > name="vtpmmgr"
> > iomem=["fed40,5"]
> > extra="--tpm2"
> >
> > vtpm-stubdom domain configuration on TPM 1.x:
> >
> > kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
> > memory=16
> > disk=["file:/var/scale/vdisk/vmgr,hda,w"]
> > name="vtpmmgr"
> > iomem=["fed40,5"]
> 
> This would be useful to add to docs/misc/vtpmmgr.txt; it is difficult to find
> this documentation later if it is only present the commit message.  Also,
> existing command line options are of the form "tpm2"
> or "tpm2=1" rather than "--tpm2"; it would be nice if new options remained
> consistent.
> 
Thanks Daniel.
I will add it to docs/misc/vtpmmgr.txt. I prefer 'tpm2=1'. 

> --
> Daniel De Graaf
> National Security Agency

Intel
Quan Xu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 02:02:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 02: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 1Y0hSg-0005XW-OJ; Tue, 16 Dec 2014 02:02:06 +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 1Y0hSf-0005XR-1y
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 02:02:05 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	F2/FA-02698-C929F845; Tue, 16 Dec 2014 02:02:04 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418695322!15275971!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12124 invoked from network); 16 Dec 2014 02:02:03 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-27.messagelabs.com with SMTP;
	16 Dec 2014 02:02:03 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 15 Dec 2014 18:02:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="429405339"
Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87])
	by FMSMGA003.fm.intel.com with ESMTP; 15 Dec 2014 17:50:57 -0800
Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by
	KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 16 Dec 2014 10:01:58 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 16 Dec 2014 10:01:58 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.67]) with mapi id
	14.03.0195.001; Tue, 16 Dec 2014 10:01:58 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [PATCH 09/12] vTPM/TPM2: Support '--tpm2' extra command line.
Thread-Index: AQHQGH+Li0lPaHnAvkqzBkmML6uXAZyRdYOw
Date: Tue, 16 Dec 2014 02:01:57 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E84CD32@SHSMSX101.ccr.corp.intel.com>
References: <1418558993-13681-1-git-send-email-quan.xu@intel.com>
	<548F046F.9030208@tycho.nsa.gov>
In-Reply-To: <548F046F.9030208@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>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 09/12] vTPM/TPM2: Support '--tpm2' extra
	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



> -----Original Message-----
> From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> Sent: Monday, December 15, 2014 11:55 PM
> To: Xu, Quan; xen-devel@lists.xen.org
> Cc: stefano.stabellini@eu.citrix.com; samuel.thibault@ens-lyon.org
> Subject: Re: [PATCH 09/12] vTPM/TPM2: Support '--tpm2' extra command
> line.
> 
> On 12/14/2014 07:09 AM, Quan Xu wrote:
> > Make vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
> > Add:
> > ..
> >       extra="--tpm2"
> > ..
> > to launch vtpm-stubdom domain on TPM 2.0, ignore it on TPM 1.x. for
> > example, vtpm-stubdom domain configuration on TPM 2.0:
> >
> > kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
> > memory=16
> > disk=["file:/var/scale/vdisk/vmgr,hda,w"]
> > name="vtpmmgr"
> > iomem=["fed40,5"]
> > extra="--tpm2"
> >
> > vtpm-stubdom domain configuration on TPM 1.x:
> >
> > kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
> > memory=16
> > disk=["file:/var/scale/vdisk/vmgr,hda,w"]
> > name="vtpmmgr"
> > iomem=["fed40,5"]
> 
> This would be useful to add to docs/misc/vtpmmgr.txt; it is difficult to find
> this documentation later if it is only present the commit message.  Also,
> existing command line options are of the form "tpm2"
> or "tpm2=1" rather than "--tpm2"; it would be nice if new options remained
> consistent.
> 
Thanks Daniel.
I will add it to docs/misc/vtpmmgr.txt. I prefer 'tpm2=1'. 

> --
> Daniel De Graaf
> National Security Agency

Intel
Quan Xu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 02:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 02: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 1Y0heh-0005zN-4h; Tue, 16 Dec 2014 02:14:31 +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 1Y0hef-0005zI-KL
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 02:14:29 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	90/97-15461-4859F845; Tue, 16 Dec 2014 02:14:28 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418696066!7774949!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 5094 invoked from network); 16 Dec 2014 02:14:27 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-21.messagelabs.com with SMTP;
	16 Dec 2014 02:14:27 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 15 Dec 2014 18:12:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,583,1413270000"; d="scan'208";a="624313566"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by orsmga001.jf.intel.com with ESMTP; 15 Dec 2014 18:14:24 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 16 Dec 2014 10:14:20 +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; Tue, 16 Dec 2014 10:14:19 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [PATCH 11/12] vTPM/TPM2: Bind group keys and sectors data on disk
Thread-Index: AQHQGH+PZC7Hv+R5pUiKR+g5Ap7T/ZyReGYg
Date: Tue, 16 Dec 2014 02:14:19 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E84CD83@SHSMSX101.ccr.corp.intel.com>
References: <1418558998-13755-1-git-send-email-quan.xu@intel.com>
	<548F0476.6000408@tycho.nsa.gov>
In-Reply-To: <548F0476.6000408@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>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 11/12] vTPM/TPM2: Bind group keys and
 sectors data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> Sent: Monday, December 15, 2014 11:56 PM
> To: Xu, Quan; xen-devel@lists.xen.org
> Cc: stefano.stabellini@eu.citrix.com; samuel.thibault@ens-lyon.org
> Subject: Re: [PATCH 11/12] vTPM/TPM2: Bind group keys and sectors data
> on disk
> 
> On 12/14/2014 07:09 AM, Quan Xu wrote:
> [...]
> > +        /*TPM 2.0 bind | TPM 1.x seal*/
> > +        if (hw_is_tpm2()) {
> > +            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
> > +        } else {
> > +            dst->pcr_selection = src->seals[i].pcr_selection;
> > +            memcpy(&dst->digest_release, &src->seals[i].digest_release,
> 20);
> > +            TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
> > +            TPM_disk_seal(dst, &sblob, sizeof(sblob));
> > +        }
> 
> It appears that the secrets for the vTPMs are only being bound to the
> presence of the physical TPM and not the measurements of the hypervisor
> and other TCB components.  This does not provide as much security as it
> did for TPM 1.2: an attacker with access to the boot disk can boot into a
> compromised environment and extract the vTPM keys and disk images.
> 
Agree with it.
I will bind more information, such as measurements of the hypervisor and other TCB components
In next version.


> The TPM2_Create/TPM2_Unseal operations should be capable of performing
> the same functionality.  If only SHA1 PCRs are used, they should be able to
> be drop-in replacements, but supporting other hash algorithms may be a
> feature that users who have a TPM2 will want.
> 
Interesting:)..
I will continue to develop and maintain vTPM on TPM 2.0. Make it stable and robust.

> --
> Daniel De Graaf
> National Security Agency


Intel
Quan Xu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 02:14:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 02: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 1Y0heh-0005zN-4h; Tue, 16 Dec 2014 02:14:31 +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 1Y0hef-0005zI-KL
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 02:14:29 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	90/97-15461-4859F845; Tue, 16 Dec 2014 02:14:28 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418696066!7774949!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 5094 invoked from network); 16 Dec 2014 02:14:27 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-21.messagelabs.com with SMTP;
	16 Dec 2014 02:14:27 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 15 Dec 2014 18:12:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,583,1413270000"; d="scan'208";a="624313566"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
	by orsmga001.jf.intel.com with ESMTP; 15 Dec 2014 18:14:24 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Tue, 16 Dec 2014 10:14:20 +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; Tue, 16 Dec 2014 10:14:19 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [PATCH 11/12] vTPM/TPM2: Bind group keys and sectors data on disk
Thread-Index: AQHQGH+PZC7Hv+R5pUiKR+g5Ap7T/ZyReGYg
Date: Tue, 16 Dec 2014 02:14:19 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E84CD83@SHSMSX101.ccr.corp.intel.com>
References: <1418558998-13755-1-git-send-email-quan.xu@intel.com>
	<548F0476.6000408@tycho.nsa.gov>
In-Reply-To: <548F0476.6000408@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>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 11/12] vTPM/TPM2: Bind group keys and
 sectors data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> Sent: Monday, December 15, 2014 11:56 PM
> To: Xu, Quan; xen-devel@lists.xen.org
> Cc: stefano.stabellini@eu.citrix.com; samuel.thibault@ens-lyon.org
> Subject: Re: [PATCH 11/12] vTPM/TPM2: Bind group keys and sectors data
> on disk
> 
> On 12/14/2014 07:09 AM, Quan Xu wrote:
> [...]
> > +        /*TPM 2.0 bind | TPM 1.x seal*/
> > +        if (hw_is_tpm2()) {
> > +            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
> > +        } else {
> > +            dst->pcr_selection = src->seals[i].pcr_selection;
> > +            memcpy(&dst->digest_release, &src->seals[i].digest_release,
> 20);
> > +            TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
> > +            TPM_disk_seal(dst, &sblob, sizeof(sblob));
> > +        }
> 
> It appears that the secrets for the vTPMs are only being bound to the
> presence of the physical TPM and not the measurements of the hypervisor
> and other TCB components.  This does not provide as much security as it
> did for TPM 1.2: an attacker with access to the boot disk can boot into a
> compromised environment and extract the vTPM keys and disk images.
> 
Agree with it.
I will bind more information, such as measurements of the hypervisor and other TCB components
In next version.


> The TPM2_Create/TPM2_Unseal operations should be capable of performing
> the same functionality.  If only SHA1 PCRs are used, they should be able to
> be drop-in replacements, but supporting other hash algorithms may be a
> feature that users who have a TPM2 will want.
> 
Interesting:)..
I will continue to develop and maintain vTPM on TPM 2.0. Make it stable and robust.

> --
> Daniel De Graaf
> National Security Agency


Intel
Quan Xu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 04:08:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 04:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0jQc-0008CA-8K; Tue, 16 Dec 2014 04:08: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 1Y0jQa-0008C5-Ls
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 04:08:04 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	B7/86-03145-320BF845; Tue, 16 Dec 2014 04:08:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418702882!15274629!1
X-Originating-IP: [66.165.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 29711 invoked from network); 16 Dec 2014 04:08:03 -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;
	16 Dec 2014 04:08:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,584,1413244800"; d="scan'208";a="205214201"
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.210.2; Mon, 15 Dec 2014 23:08: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 1Y0jQW-0005He-Mx;
	Tue, 16 Dec 2014 04:08:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0jQW-0000YK-Gh;
	Tue, 16 Dec 2014 04:08:00 +0000
Date: Tue, 16 Dec 2014 04:08:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32386-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] 32386: 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 32386 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32386/

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-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 31241
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 31241
 test-amd64-amd64-xl          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
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3)    broken REGR. vs. 31241
 test-amd64-amd64-pair        16 guest-start/debian        fail REGR. vs. 31241
 test-amd64-i386-xl-qemuu-debianhvm-amd64 11 guest-saverestore.2 fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 31241
 test-amd64-i386-pair         16 guest-start/debian        fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 31241
 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-amd64-xl-sedf     14 guest-localmigrate.2      fail REGR. vs. 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-xl-pcipt-intel  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-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-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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                67e2c3883828b39548cee2091b36656787775d95
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1671 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                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 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                     fail    
 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                            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

broken-step test-amd64-i386-qemuu-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-xl-qemuu-winxpsp3 host-install(3)
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 host-install(3)

Not pushing.

(No revision log; it would be 178219 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 Dec 16 04:08:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 04:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0jQc-0008CA-8K; Tue, 16 Dec 2014 04:08: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 1Y0jQa-0008C5-Ls
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 04:08:04 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	B7/86-03145-320BF845; Tue, 16 Dec 2014 04:08:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418702882!15274629!1
X-Originating-IP: [66.165.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 29711 invoked from network); 16 Dec 2014 04:08:03 -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;
	16 Dec 2014 04:08:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,584,1413244800"; d="scan'208";a="205214201"
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.210.2; Mon, 15 Dec 2014 23:08: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 1Y0jQW-0005He-Mx;
	Tue, 16 Dec 2014 04:08:00 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0jQW-0000YK-Gh;
	Tue, 16 Dec 2014 04:08:00 +0000
Date: Tue, 16 Dec 2014 04:08:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32386-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] 32386: 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 32386 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32386/

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-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 31241
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 31241
 test-amd64-amd64-xl          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
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3)    broken REGR. vs. 31241
 test-amd64-amd64-pair        16 guest-start/debian        fail REGR. vs. 31241
 test-amd64-i386-xl-qemuu-debianhvm-amd64 11 guest-saverestore.2 fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 31241
 test-amd64-i386-pair         16 guest-start/debian        fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 31241
 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-amd64-xl-sedf     14 guest-localmigrate.2      fail REGR. vs. 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-xl-pcipt-intel  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-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-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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                67e2c3883828b39548cee2091b36656787775d95
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1671 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                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 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                     fail    
 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                            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

broken-step test-amd64-i386-qemuu-rhel6hvm-amd host-install(3)
broken-step test-amd64-i386-xl-qemuu-winxpsp3 host-install(3)
broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 host-install(3)

Not pushing.

(No revision log; it would be 178219 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 Dec 16 05:56:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 05: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 1Y0l6s-0002Dk-V4; Tue, 16 Dec 2014 05:55:50 +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 1Y0l6r-0002Df-BP
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 05:55:49 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	B3/1A-02953-469CF845; Tue, 16 Dec 2014 05:55:48 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418709347!15294733!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 3072 invoked from network); 16 Dec 2014 05:55:48 -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; 16 Dec 2014 05:55:48 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 05549AD6F;
	Tue, 16 Dec 2014 05:55:43 +0000 (UTC)
Message-ID: <548FC95E.70903@suse.com>
Date: Tue, 16 Dec 2014 06:55: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: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	x86@kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, tglx@linutronix.de, mingo@redhat.com, 
	hpa@zytor.com, mmarek@suse.cz, linux-kbuild@vger.kernel.org
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-5-git-send-email-jgross@suse.com>
	<548ECE9B.3040105@citrix.com>
In-Reply-To: <548ECE9B.3040105@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/4] xen: use generated hypercall symbols in
 arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/15/2014 01:05 PM, David Vrabel wrote:
> On 11/12/14 18:04, Juergen Gross wrote:
>> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
>> use the auto generated symbol list.
>>
>> This also corrects the wrong address of xen_hypercall_mca which was
>> located 32 bytes higher than it should.
>>
>> Symbol addresses have been verified to match the correct ones via
>> objdump output.
> [...]
>> +
>> +#define HYPERCALL(n) \
>> +	.equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \
>> +	.type xen_hypercall_##n, function; .size xen_hypercall_##n, 32
>> +#include <asm/xen-hypercalls.h>
>> +#undef HYPERCALL
>
> The gas manual[1] suggests the syntax you've used for .type is invalid
> and suggest using .type <name>, STT_FUNC

Really? In the link below I see:

The types supported are:

STT_FUNC
function
     Mark the symbol as being a function name.
...

So "function" seems to be okay.

>
>> +
>>   	.balign PAGE_SIZE
>
> You can remove this .balign.

Indeed.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 05:56:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 05: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 1Y0l6s-0002Dk-V4; Tue, 16 Dec 2014 05:55:50 +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 1Y0l6r-0002Df-BP
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 05:55:49 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	B3/1A-02953-469CF845; Tue, 16 Dec 2014 05:55:48 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418709347!15294733!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 3072 invoked from network); 16 Dec 2014 05:55:48 -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; 16 Dec 2014 05:55:48 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 05549AD6F;
	Tue, 16 Dec 2014 05:55:43 +0000 (UTC)
Message-ID: <548FC95E.70903@suse.com>
Date: Tue, 16 Dec 2014 06:55: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: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	x86@kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, tglx@linutronix.de, mingo@redhat.com, 
	hpa@zytor.com, mmarek@suse.cz, linux-kbuild@vger.kernel.org
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-5-git-send-email-jgross@suse.com>
	<548ECE9B.3040105@citrix.com>
In-Reply-To: <548ECE9B.3040105@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/4] xen: use generated hypercall symbols in
 arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/15/2014 01:05 PM, David Vrabel wrote:
> On 11/12/14 18:04, Juergen Gross wrote:
>> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
>> use the auto generated symbol list.
>>
>> This also corrects the wrong address of xen_hypercall_mca which was
>> located 32 bytes higher than it should.
>>
>> Symbol addresses have been verified to match the correct ones via
>> objdump output.
> [...]
>> +
>> +#define HYPERCALL(n) \
>> +	.equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \
>> +	.type xen_hypercall_##n, function; .size xen_hypercall_##n, 32
>> +#include <asm/xen-hypercalls.h>
>> +#undef HYPERCALL
>
> The gas manual[1] suggests the syntax you've used for .type is invalid
> and suggest using .type <name>, STT_FUNC

Really? In the link below I see:

The types supported are:

STT_FUNC
function
     Mark the symbol as being a function name.
...

So "function" seems to be okay.

>
>> +
>>   	.balign PAGE_SIZE
>
> You can remove this .balign.

Indeed.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 06:33:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 06:33:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0lhJ-00038G-TS; Tue, 16 Dec 2014 06:33:29 +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 1Y0lhI-00037o-1P
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 06:33:28 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	21/38-26858-732DF845; Tue, 16 Dec 2014 06:33:27 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418711603!9876866!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28631 invoked from network); 16 Dec 2014 06:33:26 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 06:33:26 -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, 15 Dec 2014 23:33:15 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 14:32:55 +0800
Message-Id: <1418711577-15449-3-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1418711577-15449-1-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 V8:
  * add an overview document, so that one can has a overall look
    about the whole domain snapshot work, limits, requirements,
    how to do, etc.

=====================================================================
Domain snapshot overview

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 usually includes:
a) create a domain snapshot
b) roll back (or called "revert") to a domain snapshot
c) delete a domain snapshot
d) list all domain snapshots

But following the existing xl idioms of managing storage and saved
VM images via existing CLI command (qemu-img, lvcreate, ls, mv,
cp etc), xl snapshot functionality would be kept as simple as
possible:
* xl will do a) and b), creating a snapshot and reverting a
  domain to a snapshot.
* xl will NOT do c) and d), xl won't manage snapshots, as xl
  doesn't maintain saved images created by 'xl save'. So xl
  will have no idea of the existence of domain snapshots and
  the chain relationship between snapshots. It will depends on
  user to take care of the snapshots, know the snapshot chain
  info, and delete snapshots.

Domain Snapshot Support and Not Support:
* support live snapshot
* support internal disk snapshot and external disk snapshot
* support different disk backend types.
  (Basic goal is to support 'raw' and 'qcow2' only).

* not support snapshot when domain is shutdowning or dying.
* not support disk-only snapshot [1].

 [1] 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.


2. Requirements

General Requirements:
* ability to save/restore domain memory
* ability to create/delete/apply disk snapshot [2]
* ability to parse user config file

  [2] Disk snapshot requirements:
  - external tools: qemu-img, lvcreate, vhd-util, etc.
  - for basic goal, we support 'raw' and 'qcow2' backend types
    only. Then it requires:
    libxl qmp command or "qemu-img" (when qemu process does not
    exist)


3. Interaction with other operations:

No.


4. General workflow

Create a snapshot:
  * parse user cfg file if passed in
  * check snapshot operation is allowed or not
  * save domain, saving memory status to file (refer to: save_domain)
  * take disk snapshot (e.g. call qmp command)
  * unpause domain

Revert to snapshot:
  * parse use cfg file (xl doesn't manage snapshots, so it has no
    idea of snapshot existence. User MUST supply configuration file)
  * destroy this domain
  * create a new domain from snapshot info
    - apply disk snapshot (e.g. call qemu-img)
    - a process like restore domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 06:33:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 06:33:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0lhK-00038N-8D; Tue, 16 Dec 2014 06:33:30 +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 1Y0lhI-00037t-C4
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 06:33:28 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	C6/9F-20609-732DF845; Tue, 16 Dec 2014 06:33:27 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418711603!15286418!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13368 invoked from network); 16 Dec 2014 06:33:25 -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; 16 Dec 2014 06:33:25 -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, 15 Dec 2014 23:33:09 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 14:32:53 +0800
Message-Id: <1418711577-15449-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V9 0/4] 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

Changes to V8:
  - xl removes snapshot-delete/snapshot-list, keeps
    snapshot-create/snapshot-revert only.
  - libxl removes unnecessary domain snapshot functionality
    libxl_domain_snapshot_create/delete/revert. Instead,
    export disk snapshot functionality for xl/libvirt usage
    in libxl/libxlu.
  - Add more introduction to the overall work.

V8 is here:
   http://lists.xen.org/archives/html/xen-devel/2014-11/msg00734.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 06:33:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 06:33:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0lhI-000389-He; Tue, 16 Dec 2014 06:33:28 +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 1Y0lhH-00037j-Hq
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 06:33:27 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	06/AA-26652-632DF845; Tue, 16 Dec 2014 06:33:26 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418711604!13569947!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17615 invoked from network); 16 Dec 2014 06:33:25 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 06:33:25 -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, 15 Dec 2014 23:33:18 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 14:32:56 +0800
Message-Id: <1418711577-15449-4-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1418711577-15449-1-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V9 3/4] domain snapshot design: 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>
MIME-Version: 1.0
Content-Type: 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 V8:
  * xl won't manage snapshots, that means it won't maintain json files,
    won't maintain snapshot chain relationship, and then as a result
    won't take care of deleting snapshot and listing snapshots.
  * remove snapshot-delete and snapshot-list interface
  * update snapshot-revert interface
  * update snapshot-create/revert implementaion

===========================================================================

XL Design

1. User Interface

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, use cfgfile. (e.g. if --name specifies a name,
    meanwhile there is name specified in cfgfile, name in cfgfile will
    be used.)


xl snapshot-revert:
  Revert domain to status of a snapshot.

  SYNOPSIS:
      snapshot-revert <domain> <cfgfile> [--running] [--force]

  OPTIONS:
    --running        after reverting, change state to running
    --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.



2. cfgfile syntax

#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
#For easier parse config work, reuse disk configuration in xl.cfg, but
#with different meanings.
#disk syntax meaning: 'external path, external format, target device'

#e.g. to specify exernal disk snapshot, like this:
#disks=['/tmp/hda_snapshot.qcow2,qcow2,hda',
        '/tmp/hdb_snapshot.qcow2,qcow2,hdb',]

#e.g. to specify internal disk snapshot, like this:
disks=[',,hda',',,hdb',]


3. xl snapshot-xxx implementation

"xl snapshot-create"

    1), parse args or user configuration file.
    2), save domain (store saved memory to memory_path)
    3), create disk snapshots according to disk snapshot configuration
    4), unpause domain

"xl snapshot-revert"

    1), parse user configuration file
    2), destroy current domain
    3), revert disk snapshots according to disk snapshot configuration
    4), restore domain from saved memory.

4. Notes

* user should take care of those snapshots, like: saved memory file, disk
  snapshots info (internal, external, etc.), snapshot chain relationship
* user should delete snapshots by themselves with CLI commands like: rm,
  qemu-img, etc.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 06:33:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 06:33:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0lhW-0003A4-Kx; Tue, 16 Dec 2014 06:33:42 +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 1Y0lhV-00039f-6w
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 06:33:41 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F3/F3-15461-442DF845; Tue, 16 Dec 2014 06:33:40 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418711618!15840776!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27535 invoked from network); 16 Dec 2014 06:33:39 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 06:33:39 -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, 15 Dec 2014 23:33:20 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 14:32:57 +0800
Message-Id: <1418711577-15449-5-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1418711577-15449-1-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 V8:
  * remove libxl_domain_snapshot_create/delete/revert API
  * export disk snapshot functionality for both xl and libvirt usage

===========================================================================
Libxl/libxlu Design

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),
    ])


2. New Functions

Since there're already APIs for saving memory (libxl_domain_suspend)
and restoring domain from saved memory (libxl_domain_create_restore), to
xl domain snapshot tasks, the missing part is disk snapshot functionality.
And the disk snapshot functionality would be used by libvirt too.

Considering there is qmp handling in creating/deleting disk snapshot,
will add following new functions to libxl (?):

int libxl_disk_snapshot_create(libxl_ctx *ctx, uint32_t domid,
                               libxl_disk_snapshot *snapshot, int nb);

    Taking disk snapshots to a group of domain disks according to
    configuration. For qcow2 disk backend type, it will call qmp
    "transaction" command to do the work. For other disk backend types,
    might call other external commands.

    Parameters:
       ctx (INPUT):
           context
       domid (INPUT):
           domain id
       snapshot (INPUT):
           array of disk snapshot configuration. Has "nb" members.

           libxl_device_disk:
               structure to represent which disk.
           name:
               snapshot name.
           external:
               internal snapshot or external snapshot.
               '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.
       nb (INPUT):
           number of disks that need to take disk snapshot.

    Return:
       0 on success, -1 on error.


/*  This API might not be used by xl, since xl won't take care of deleting
 *  snapshots. But for libvirt, since libvirt manages snapshots and will
 *  delete snapshot, this API will be used.
 */
int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid,
                               libxl_disk_snapshot *snapshot, int nb);

    Delete disk snapshot of a group of domain disks according to
    configuration. For qcow2 disk backend type, it will call qmp command
    to delete internal disk snapshot. For other disk backend types, might
    call other external commands.

    Parameters:
       ctx (INPUT):
           context
       domid (INPUT):
           domain id
       snapshot (INPUT):
           array of disk snapshot configuration. Has "nb" members.
       nb (INPUT):
           number of disks that need to take disk snapshot.

    Return:
       0 on success, -1 on error.


int libxl_disk_to_snapshot(libxl_ctx *ctx, uint32_t domid,
                           libxl_disk_snapshot **snapshot, int *num);

    This is for domain snapshot create. If user doesn't specify disks,
    then by default it will take internal disk snapshot to each domain
    disk. This function will fill libxl_disk_snapshot according to domain
    disks info.

    Parameters:
       ctx (INPUT):
           context
       domid (INPUT):
           domain id
       snapshot (OUTPUT):
           array of disk snapshot configuration.
       num (OUTPUT):
           number of disks.

    Return:
       0 on success, -1 on error.



For disk snapshot revert, no qmp command for that, it always calls
external commands to finish the work, so put in libxlu (?):

int xlu_disk_snapshot_revert(libxl_disk_snapshot *snapshot, int nb);

    Apply disk snapshot for a group of disks according to configuration. To
    different disk backend types, call different external commands to do
    the work.

    Parameters:
       snapshot (INPUT):
           array of disk snapshot configuration. Has "nb" members.
       nb (INPUT):
           number of disks that need to take disk snapshot.

    Return:
       0 on success, -1 on error.



3. Simple Architecture View

Creating domain snapshot:
(* means new functions we will need in libxl/libxlu)

  "xl snapshot-create"
         |
  parse configuration ----> libxl_disk_to_snapshot (*)
         |
  saving memory ----> libxl_domain_suspend
         |
 taking disk snapshot ----> libxl_disk_snapshot_create (*)
         |                     |
         |                     --> libxl_qmp_disk_snapshot_transaction (*)
         |
    unpause domain ---->libxl_domain_unpause
         |
        End


Reverting to a snapshot:
(* means new functions we will need in libxl/libxlu)

  "xl snapshot-revert"
         |
   parse configuration
         |
   destroy domain ---->libxl_domain_destroy
         |
 reverting disk snapshot ----> xlu_disk_snapshot_revert (*)
         |                       |
         |                       --> call 'qemu-img' to apply disk snapshot
         |
 restore domain from saved memory ----> libxl_domain_create_restore
         |
        End

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 06:33:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 06:33:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0lhK-00038N-8D; Tue, 16 Dec 2014 06:33:30 +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 1Y0lhI-00037t-C4
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 06:33:28 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	C6/9F-20609-732DF845; Tue, 16 Dec 2014 06:33:27 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418711603!15286418!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13368 invoked from network); 16 Dec 2014 06:33:25 -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; 16 Dec 2014 06:33:25 -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, 15 Dec 2014 23:33:09 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 14:32:53 +0800
Message-Id: <1418711577-15449-1-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V9 0/4] 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

Changes to V8:
  - xl removes snapshot-delete/snapshot-list, keeps
    snapshot-create/snapshot-revert only.
  - libxl removes unnecessary domain snapshot functionality
    libxl_domain_snapshot_create/delete/revert. Instead,
    export disk snapshot functionality for xl/libvirt usage
    in libxl/libxlu.
  - Add more introduction to the overall work.

V8 is here:
   http://lists.xen.org/archives/html/xen-devel/2014-11/msg00734.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 06:33:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 06:33:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0lhI-00037v-6V; Tue, 16 Dec 2014 06:33:28 +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 1Y0lhG-00037i-U6
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 06:33:27 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	23/FB-08051-632DF845; Tue, 16 Dec 2014 06:33:26 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418711603!15289461!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=SUBJECT_DRUG_GAP_P
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19819 invoked from network); 16 Dec 2014 06:33:25 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 06:33:25 -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, 15 Dec 2014 23:33:12 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 14:32:54 +0800
Message-Id: <1418711577-15449-2-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1418711577-15449-1-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V9 1/4] domain snapshot terms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 V8:
  * add a document for domain snapshot related terms, they will be
    referred in later documents.

=====================================================================
Terms

* 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.

  Contents of disks (whether a subset or all disks associated with
  the domain) are saved at a given point of time, and can be restored
  back to that state. On a running guest, a disk-only snapshot is
  likely to be only crash-consistent rather than clean (that is, it
  represents the state of the disk on a sudden power outage); on an
  inactive guest, a disk-only snapshot is clean if the disks were
  clean when the guest was last shut down.

* Live Snapshot:

  Like live migration, it will increase size of the memory dump file,
  but reducess downtime of the guest.

* Internal Disk Snapshot

  File formats such as qcow2 track both the snapshot and changes
  since the snapshot in a single file.

* External Disk Snapshot

  The snapshot is one file, and the changes since the snapshot
  are in another file.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 06:33:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 06:33:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0lhJ-00038G-TS; Tue, 16 Dec 2014 06:33:29 +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 1Y0lhI-00037o-1P
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 06:33:28 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	21/38-26858-732DF845; Tue, 16 Dec 2014 06:33:27 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418711603!9876866!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28631 invoked from network); 16 Dec 2014 06:33:26 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 06:33:26 -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, 15 Dec 2014 23:33:15 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 14:32:55 +0800
Message-Id: <1418711577-15449-3-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1418711577-15449-1-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 V8:
  * add an overview document, so that one can has a overall look
    about the whole domain snapshot work, limits, requirements,
    how to do, etc.

=====================================================================
Domain snapshot overview

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 usually includes:
a) create a domain snapshot
b) roll back (or called "revert") to a domain snapshot
c) delete a domain snapshot
d) list all domain snapshots

But following the existing xl idioms of managing storage and saved
VM images via existing CLI command (qemu-img, lvcreate, ls, mv,
cp etc), xl snapshot functionality would be kept as simple as
possible:
* xl will do a) and b), creating a snapshot and reverting a
  domain to a snapshot.
* xl will NOT do c) and d), xl won't manage snapshots, as xl
  doesn't maintain saved images created by 'xl save'. So xl
  will have no idea of the existence of domain snapshots and
  the chain relationship between snapshots. It will depends on
  user to take care of the snapshots, know the snapshot chain
  info, and delete snapshots.

Domain Snapshot Support and Not Support:
* support live snapshot
* support internal disk snapshot and external disk snapshot
* support different disk backend types.
  (Basic goal is to support 'raw' and 'qcow2' only).

* not support snapshot when domain is shutdowning or dying.
* not support disk-only snapshot [1].

 [1] 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.


2. Requirements

General Requirements:
* ability to save/restore domain memory
* ability to create/delete/apply disk snapshot [2]
* ability to parse user config file

  [2] Disk snapshot requirements:
  - external tools: qemu-img, lvcreate, vhd-util, etc.
  - for basic goal, we support 'raw' and 'qcow2' backend types
    only. Then it requires:
    libxl qmp command or "qemu-img" (when qemu process does not
    exist)


3. Interaction with other operations:

No.


4. General workflow

Create a snapshot:
  * parse user cfg file if passed in
  * check snapshot operation is allowed or not
  * save domain, saving memory status to file (refer to: save_domain)
  * take disk snapshot (e.g. call qmp command)
  * unpause domain

Revert to snapshot:
  * parse use cfg file (xl doesn't manage snapshots, so it has no
    idea of snapshot existence. User MUST supply configuration file)
  * destroy this domain
  * create a new domain from snapshot info
    - apply disk snapshot (e.g. call qemu-img)
    - a process like restore domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 06:33:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 06:33:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0lhW-0003A4-Kx; Tue, 16 Dec 2014 06:33:42 +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 1Y0lhV-00039f-6w
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 06:33:41 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F3/F3-15461-442DF845; Tue, 16 Dec 2014 06:33:40 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418711618!15840776!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27535 invoked from network); 16 Dec 2014 06:33:39 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 06:33:39 -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, 15 Dec 2014 23:33:20 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 14:32:57 +0800
Message-Id: <1418711577-15449-5-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1418711577-15449-1-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 V8:
  * remove libxl_domain_snapshot_create/delete/revert API
  * export disk snapshot functionality for both xl and libvirt usage

===========================================================================
Libxl/libxlu Design

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),
    ])


2. New Functions

Since there're already APIs for saving memory (libxl_domain_suspend)
and restoring domain from saved memory (libxl_domain_create_restore), to
xl domain snapshot tasks, the missing part is disk snapshot functionality.
And the disk snapshot functionality would be used by libvirt too.

Considering there is qmp handling in creating/deleting disk snapshot,
will add following new functions to libxl (?):

int libxl_disk_snapshot_create(libxl_ctx *ctx, uint32_t domid,
                               libxl_disk_snapshot *snapshot, int nb);

    Taking disk snapshots to a group of domain disks according to
    configuration. For qcow2 disk backend type, it will call qmp
    "transaction" command to do the work. For other disk backend types,
    might call other external commands.

    Parameters:
       ctx (INPUT):
           context
       domid (INPUT):
           domain id
       snapshot (INPUT):
           array of disk snapshot configuration. Has "nb" members.

           libxl_device_disk:
               structure to represent which disk.
           name:
               snapshot name.
           external:
               internal snapshot or external snapshot.
               '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.
       nb (INPUT):
           number of disks that need to take disk snapshot.

    Return:
       0 on success, -1 on error.


/*  This API might not be used by xl, since xl won't take care of deleting
 *  snapshots. But for libvirt, since libvirt manages snapshots and will
 *  delete snapshot, this API will be used.
 */
int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid,
                               libxl_disk_snapshot *snapshot, int nb);

    Delete disk snapshot of a group of domain disks according to
    configuration. For qcow2 disk backend type, it will call qmp command
    to delete internal disk snapshot. For other disk backend types, might
    call other external commands.

    Parameters:
       ctx (INPUT):
           context
       domid (INPUT):
           domain id
       snapshot (INPUT):
           array of disk snapshot configuration. Has "nb" members.
       nb (INPUT):
           number of disks that need to take disk snapshot.

    Return:
       0 on success, -1 on error.


int libxl_disk_to_snapshot(libxl_ctx *ctx, uint32_t domid,
                           libxl_disk_snapshot **snapshot, int *num);

    This is for domain snapshot create. If user doesn't specify disks,
    then by default it will take internal disk snapshot to each domain
    disk. This function will fill libxl_disk_snapshot according to domain
    disks info.

    Parameters:
       ctx (INPUT):
           context
       domid (INPUT):
           domain id
       snapshot (OUTPUT):
           array of disk snapshot configuration.
       num (OUTPUT):
           number of disks.

    Return:
       0 on success, -1 on error.



For disk snapshot revert, no qmp command for that, it always calls
external commands to finish the work, so put in libxlu (?):

int xlu_disk_snapshot_revert(libxl_disk_snapshot *snapshot, int nb);

    Apply disk snapshot for a group of disks according to configuration. To
    different disk backend types, call different external commands to do
    the work.

    Parameters:
       snapshot (INPUT):
           array of disk snapshot configuration. Has "nb" members.
       nb (INPUT):
           number of disks that need to take disk snapshot.

    Return:
       0 on success, -1 on error.



3. Simple Architecture View

Creating domain snapshot:
(* means new functions we will need in libxl/libxlu)

  "xl snapshot-create"
         |
  parse configuration ----> libxl_disk_to_snapshot (*)
         |
  saving memory ----> libxl_domain_suspend
         |
 taking disk snapshot ----> libxl_disk_snapshot_create (*)
         |                     |
         |                     --> libxl_qmp_disk_snapshot_transaction (*)
         |
    unpause domain ---->libxl_domain_unpause
         |
        End


Reverting to a snapshot:
(* means new functions we will need in libxl/libxlu)

  "xl snapshot-revert"
         |
   parse configuration
         |
   destroy domain ---->libxl_domain_destroy
         |
 reverting disk snapshot ----> xlu_disk_snapshot_revert (*)
         |                       |
         |                       --> call 'qemu-img' to apply disk snapshot
         |
 restore domain from saved memory ----> libxl_domain_create_restore
         |
        End

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 06:33:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 06:33:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0lhI-000389-He; Tue, 16 Dec 2014 06:33:28 +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 1Y0lhH-00037j-Hq
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 06:33:27 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	06/AA-26652-632DF845; Tue, 16 Dec 2014 06:33:26 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418711604!13569947!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17615 invoked from network); 16 Dec 2014 06:33:25 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 06:33:25 -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, 15 Dec 2014 23:33:18 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 14:32:56 +0800
Message-Id: <1418711577-15449-4-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1418711577-15449-1-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V9 3/4] domain snapshot design: 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>
MIME-Version: 1.0
Content-Type: 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 V8:
  * xl won't manage snapshots, that means it won't maintain json files,
    won't maintain snapshot chain relationship, and then as a result
    won't take care of deleting snapshot and listing snapshots.
  * remove snapshot-delete and snapshot-list interface
  * update snapshot-revert interface
  * update snapshot-create/revert implementaion

===========================================================================

XL Design

1. User Interface

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, use cfgfile. (e.g. if --name specifies a name,
    meanwhile there is name specified in cfgfile, name in cfgfile will
    be used.)


xl snapshot-revert:
  Revert domain to status of a snapshot.

  SYNOPSIS:
      snapshot-revert <domain> <cfgfile> [--running] [--force]

  OPTIONS:
    --running        after reverting, change state to running
    --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.



2. cfgfile syntax

#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
#For easier parse config work, reuse disk configuration in xl.cfg, but
#with different meanings.
#disk syntax meaning: 'external path, external format, target device'

#e.g. to specify exernal disk snapshot, like this:
#disks=['/tmp/hda_snapshot.qcow2,qcow2,hda',
        '/tmp/hdb_snapshot.qcow2,qcow2,hdb',]

#e.g. to specify internal disk snapshot, like this:
disks=[',,hda',',,hdb',]


3. xl snapshot-xxx implementation

"xl snapshot-create"

    1), parse args or user configuration file.
    2), save domain (store saved memory to memory_path)
    3), create disk snapshots according to disk snapshot configuration
    4), unpause domain

"xl snapshot-revert"

    1), parse user configuration file
    2), destroy current domain
    3), revert disk snapshots according to disk snapshot configuration
    4), restore domain from saved memory.

4. Notes

* user should take care of those snapshots, like: saved memory file, disk
  snapshots info (internal, external, etc.), snapshot chain relationship
* user should delete snapshots by themselves with CLI commands like: rm,
  qemu-img, etc.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 06:33:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 06:33:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0lhI-00037v-6V; Tue, 16 Dec 2014 06:33:28 +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 1Y0lhG-00037i-U6
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 06:33:27 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	23/FB-08051-632DF845; Tue, 16 Dec 2014 06:33:26 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418711603!15289461!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=SUBJECT_DRUG_GAP_P
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19819 invoked from network); 16 Dec 2014 06:33:25 -0000
Received: from victor.provo.novell.com (HELO prv3-mh.provo.novell.com)
	(137.65.250.26)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 06:33:25 -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, 15 Dec 2014 23:33:12 -0700
From: Chunyan Liu <cyliu@suse.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 14:32:54 +0800
Message-Id: <1418711577-15449-2-git-send-email-cyliu@suse.com>
X-Mailer: git-send-email 1.8.4.5
In-Reply-To: <1418711577-15449-1-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, Chunyan Liu <cyliu@suse.com>
Subject: [Xen-devel] [RFC V9 1/4] domain snapshot terms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 V8:
  * add a document for domain snapshot related terms, they will be
    referred in later documents.

=====================================================================
Terms

* 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.

  Contents of disks (whether a subset or all disks associated with
  the domain) are saved at a given point of time, and can be restored
  back to that state. On a running guest, a disk-only snapshot is
  likely to be only crash-consistent rather than clean (that is, it
  represents the state of the disk on a sudden power outage); on an
  inactive guest, a disk-only snapshot is clean if the disks were
  clean when the guest was last shut down.

* Live Snapshot:

  Like live migration, it will increase size of the memory dump file,
  but reducess downtime of the guest.

* Internal Disk Snapshot

  File formats such as qcow2 track both the snapshot and changes
  since the snapshot in a single file.

* External Disk Snapshot

  The snapshot is one file, and the changes since the snapshot
  are in another file.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 08:08:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 08:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0nAX-00069Z-Mg; Tue, 16 Dec 2014 08:07: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 1Y0nAW-00069S-Ka
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 08:07:44 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	FE/98-24859-F48EF845; Tue, 16 Dec 2014 08:07:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418717263!13541565!1
X-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 4967 invoked from network); 16 Dec 2014 08:07:43 -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; 16 Dec 2014 08:07:43 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 16 Dec 2014 08:07:42 +0000
Message-Id: <548FF65C020000780004FC58@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 16 Dec 2014 08:07:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418419248-2863-1-git-send-email-boris.ostrovsky@oracle.com>
	<548EC102020000780004F810@mail.emea.novell.com>
	<548F172A.6010508@oracle.com>
In-Reply-To: <548F172A.6010508@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] x86/VPMU: Clear last_vcpu when
 destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 18:15, <boris.ostrovsky@oracle.com> wrote:
> On 12/15/2014 05:07 AM, Jan Beulich wrote:
>>>>> On 12.12.14 at 22:20, <boris.ostrovsky@oracle.com> wrote:
>>> --- a/xen/arch/x86/hvm/vpmu.c
>>> +++ b/xen/arch/x86/hvm/vpmu.c
>>> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
>>>       }
>>>   }
>>>   
>>> +static void vpmu_clear_last(void *arg)
>>> +{
>>> +    struct vcpu *v = (struct vcpu *)arg;
>> Please drop this pointless cast, or perhaps the entire variable, as ...
>>
>>> +
>>> +    if ( this_cpu(last_vcpu) == v )
>> ... you don't really need it to be of "struct vcpu *" type - "void *"
>> is quite fine for a comparison.
>>
>>> +        this_cpu(last_vcpu) = NULL;
>>> +}
>>> +
>>>   void vpmu_destroy(struct vcpu *v)
>>>   {
>>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>>   
>>> +    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
>>> +    {
>>> +        /* Need to clear last_vcpu in case it points to v */
>>> +        if ( vpmu->last_pcpu != smp_processor_id() )
>>> +            on_selected_cpus(cpumask_of(vpmu->last_pcpu),
>>> +                             vpmu_clear_last, (void *)v, 1);
>> The cast here is pointless too. But considering your subsequent
>> reply this code may go away altogether anyway; if it doesn't,
>> explaining (in the commit message) why you need to use an IPI
>> here would seem necessary.
> 
> If I do simply
>      if (per_cpu(last_vcpu, vpmu->last_pcpu) == v)
>          per_cpu(last_vcpu, vpmu->last_pcpu) = NULL
> 
> then there is a (rather theoretical) possibility that between the test 
> and subsequent clearing the remote cpu (i.e. vpmu->last_pcpu) will do 
> load_vpmu() and then save_vpmu() for another VCPU. The former will clear 
> last_vcpu and the latter will set last_vcpu to something else. And then 
> the destroy_vpmu() will set it again to NULL, which is bad.

So how about using cmpxchg then?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 08:08:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 08:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0nAX-00069Z-Mg; Tue, 16 Dec 2014 08:07: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 1Y0nAW-00069S-Ka
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 08:07:44 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	FE/98-24859-F48EF845; Tue, 16 Dec 2014 08:07:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418717263!13541565!1
X-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 4967 invoked from network); 16 Dec 2014 08:07:43 -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; 16 Dec 2014 08:07:43 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 16 Dec 2014 08:07:42 +0000
Message-Id: <548FF65C020000780004FC58@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 16 Dec 2014 08:07:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418419248-2863-1-git-send-email-boris.ostrovsky@oracle.com>
	<548EC102020000780004F810@mail.emea.novell.com>
	<548F172A.6010508@oracle.com>
In-Reply-To: <548F172A.6010508@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH for 4.5] x86/VPMU: Clear last_vcpu when
 destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 18:15, <boris.ostrovsky@oracle.com> wrote:
> On 12/15/2014 05:07 AM, Jan Beulich wrote:
>>>>> On 12.12.14 at 22:20, <boris.ostrovsky@oracle.com> wrote:
>>> --- a/xen/arch/x86/hvm/vpmu.c
>>> +++ b/xen/arch/x86/hvm/vpmu.c
>>> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
>>>       }
>>>   }
>>>   
>>> +static void vpmu_clear_last(void *arg)
>>> +{
>>> +    struct vcpu *v = (struct vcpu *)arg;
>> Please drop this pointless cast, or perhaps the entire variable, as ...
>>
>>> +
>>> +    if ( this_cpu(last_vcpu) == v )
>> ... you don't really need it to be of "struct vcpu *" type - "void *"
>> is quite fine for a comparison.
>>
>>> +        this_cpu(last_vcpu) = NULL;
>>> +}
>>> +
>>>   void vpmu_destroy(struct vcpu *v)
>>>   {
>>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>>   
>>> +    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
>>> +    {
>>> +        /* Need to clear last_vcpu in case it points to v */
>>> +        if ( vpmu->last_pcpu != smp_processor_id() )
>>> +            on_selected_cpus(cpumask_of(vpmu->last_pcpu),
>>> +                             vpmu_clear_last, (void *)v, 1);
>> The cast here is pointless too. But considering your subsequent
>> reply this code may go away altogether anyway; if it doesn't,
>> explaining (in the commit message) why you need to use an IPI
>> here would seem necessary.
> 
> If I do simply
>      if (per_cpu(last_vcpu, vpmu->last_pcpu) == v)
>          per_cpu(last_vcpu, vpmu->last_pcpu) = NULL
> 
> then there is a (rather theoretical) possibility that between the test 
> and subsequent clearing the remote cpu (i.e. vpmu->last_pcpu) will do 
> load_vpmu() and then save_vpmu() for another VCPU. The former will clear 
> last_vcpu and the latter will set last_vcpu to something else. And then 
> the destroy_vpmu() will set it again to NULL, which is bad.

So how about using cmpxchg then?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 08:58:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 08:58:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0nx9-0007Cf-SZ; Tue, 16 Dec 2014 08:57:59 +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 1Y0nx9-0007Ca-0Z
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 08:57:59 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	D9/AC-28865-514FF845; Tue, 16 Dec 2014 08:57:57 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418720275!13597449!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 15673 invoked from network); 16 Dec 2014 08:57:57 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-206.messagelabs.com with SMTP;
	16 Dec 2014 08:57:57 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 16 Dec 2014 00:56:15 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,585,1413270000"; d="scan'208";a="638247648"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by fmsmga001.fm.intel.com with ESMTP; 16 Dec 2014 00:56:01 -0800
Date: Tue, 16 Dec 2014 16:55:59 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: JBeulich@suse.com
Message-ID: <20141216085559.GB3105@pengc-linux.bj.intel.com>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	will.auld@intel.com, wei.liu2@citrix.com, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
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

Hi Jan,

Any comments from you? It would be greatly appreciated if you can look
at this when you have time. Your comments are always important to me :)

Thanks,
Chao

On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote:
> Hi all, we plan to bring Intel CAT into XEN. This is the initial
> design for that. Comments/suggestions are welcome.
> 
> Background
> ==========
> Traditionally, all Virtual Machines ("VMs") share the same set of system
> cache resources. There is no hardware support to control allocation or
> availability of cache resources to individual VMs. The lack of such
> partition mechanism for cache resource makes the cache utilization for
> different types of VMs inefficient. While on the other side, more and
> more cache resources become available on modern server platforms.
> 
> With the introduction of Intel Cache Allocation Technology ("CAT"), now
> Virtualization Machine Monitor ("VMM") has the ability to partition the
> cache allocation per VM, based on the priority of VM.
> 
> 
> CAT Introduction
> ================
> Generally speaking, CAT introduces a mechanism for software to enable
> cache allocation based on application priority or Class of Service
> ("COS"). Cache allocation for the respective applications is then
> restricted based on the COS with which they are associated. Each COS can
> be configured using capacity bitmasks ("CBM") which represent cache
> capacity and indicate the degree of overlap and isolation between
> classes. For each logical processor there is a register
> exposed(IA32_PQR_ASSOC MSR) to allow the OS/VMM to specify a COS when an
> application, thread or VM is scheduled. Cache allocation for the
> indicated application/thread/VM is then controlled automatically by the
> hardware based on the COS and the CBM associated with that class.
> Hardware initializes COS of each logical processor to 0 and the
> corresponding CBM is set to all-ones, means all the system cache
> resource can be used for each application.
> 
> For more information please refer to Section 17.15 in the Intel SDM [1].
> 
> 
> Design Overview
> ===============
> - Domain COS/CBM association
> When enforcing cache allocation for VMs, the minimum granularity is
> defined as the domain. All Virtual CPUs ("VCPUs") of a domain have the
> same COS, and therefore, correspond to the same CBM. COS is used only in
> hypervisor and is transparent to tool stack/user. System administrator
> can specify the initial CBM for each domain or change it at runtime using 
> tool stack. Hypervisor then choses a free COS to associate it with that
> CBM or find a existed COS which has the same CBM.
> 
> - VCPU Schedule
> When VCPU is scheduled on the physical CPU ("PCPU"), its COS value is
> then written to MSR (IA32_PQR_ASSOC) of PCPU to notify hardware to use 
> the new COS. The cache allocation is then enforced by hardware.
> 
> - Multi-Socket
> In multi-socket environment, each VCPU may be scheduled on different
> sockets. The hardware CAT ability(such as maximum supported COS and length
> of CBM) maybe different among sockets. For such system, per-socket COS/CBM
> configuration of a domain is specified. Hypervisor then use this per-socket
> CBM information for VCPU schedule.
> 
> 
> Implementation Description
> ==========================
> In this design, one principal is that only implementing the cache
> enforcement mechanism in hypervisor but leaving the cache allocation
> policy to user space tool stack. In this way some complex governors then
> can be implemented in tool stack. 
> 
> In summary, hypervisor changes include:
> 1) A new field "cat_info" in domain structure to indicate the CAT
>    information for each socket. It points to array of structure:
>    struct domain_socket_cat_info {
>        unsigned int cbm; /* CBM specified by toolstack  */
>        unsigned int cos; /* COS allocated by Hypervisor */
>    }
> 2) A new SYSCTL to expose the CAT information to tool stack:
>      * Whether CAT is enabled;
>      * Max COS supported;
>      * Length of CBM;
>      * Other needed information from host cpuid;
> 3) A new DOMCTL to allow tool stack to set/get CBM for a specified domain
>    for each socket.
> 4) Context switch: write COS of domain to MSR (IA32_PQR_ASSOC) of PCPU.
> 5) XSM policy to restrict the functions visibility to control domain only.
> 
> Hypervisor interfaces:
> 1) Boot line param: "psr=cat" to enable the feature.
> 2) SYSCTL: XEN_SYSCTL_psr_cat_op
>      - XEN_SYSCTL_PSR_CAT_INFO_GET: Get system CAT information;
> 3) DOMCTL: XEN_DOMCTL_psr_cat_op
>      - XEN_DOMCTL_PSR_CAT_OP_CBM_SET: Set CBM value for a domain.
>      - XEN_DOMCTL_PSR_CAT_OP_CBM_GET: Get CBM value for a domain.
> 
> xl interfaces:
> 1) psr-cat-show: Show system/runtime CAT information.
>      => XEN_SYSCTL_PSR_CAT_INFO_GET/XEN_DOMCTL_PSR_CAT_OP_CBM_GET
> 2) psr-cat-cbm-set [dom] [cbm] [socket]: Set CBM for a domain.
>      => XEN_DOMCTL_PSR_CAT_OP_CBM_SET
> 
> 
> Hardware Limitation & Performance Improvement
> =============================================
> As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
> switch. If the change is frequent then hardware may fail to strictly
> enforce the cache allocation basing on the specified COS. Due to this
> the strict placement characteristic would soften if VCPU is migrated on
> different PCPU frequently.
> 
> For this reason, lazy updating for IA32_PQR_ASSOC will be done. Also this
> design allows CAT to run in two modes:
> 
> 1) Non Affinitized mode: Each VM can be freely scheduled on any PCPU
> assigning its COS as it does.
> 
> 2) Affinitized mode: Each PCPU is assigned a fixed COS and a VM can be
> scheduled on the PCPU only when it has a same COS. It's less flexible
> but can be an option for those who must have strict COS placement or in
> cases where problems have arisen because of the less strict nature of the
> non-affinitized mode.
> 
> However, no additional code is designed to support these two modes. CAT is
> already running in non affinitized mode by default. If affinitized mode
> is desirable, then existed "xl vcpu-pin" command can be used to pin all
> the VCPUs which has the same COS to certain fixed PCPUs so that these 
> PCPUs always have the same COS set.
> 
> [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
> 
> 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 Tue Dec 16 08:58:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 08:58:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0nx9-0007Cf-SZ; Tue, 16 Dec 2014 08:57:59 +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 1Y0nx9-0007Ca-0Z
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 08:57:59 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	D9/AC-28865-514FF845; Tue, 16 Dec 2014 08:57:57 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418720275!13597449!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 15673 invoked from network); 16 Dec 2014 08:57:57 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-206.messagelabs.com with SMTP;
	16 Dec 2014 08:57:57 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 16 Dec 2014 00:56:15 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,585,1413270000"; d="scan'208";a="638247648"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by fmsmga001.fm.intel.com with ESMTP; 16 Dec 2014 00:56:01 -0800
Date: Tue, 16 Dec 2014 16:55:59 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: JBeulich@suse.com
Message-ID: <20141216085559.GB3105@pengc-linux.bj.intel.com>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	will.auld@intel.com, wei.liu2@citrix.com, dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
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

Hi Jan,

Any comments from you? It would be greatly appreciated if you can look
at this when you have time. Your comments are always important to me :)

Thanks,
Chao

On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote:
> Hi all, we plan to bring Intel CAT into XEN. This is the initial
> design for that. Comments/suggestions are welcome.
> 
> Background
> ==========
> Traditionally, all Virtual Machines ("VMs") share the same set of system
> cache resources. There is no hardware support to control allocation or
> availability of cache resources to individual VMs. The lack of such
> partition mechanism for cache resource makes the cache utilization for
> different types of VMs inefficient. While on the other side, more and
> more cache resources become available on modern server platforms.
> 
> With the introduction of Intel Cache Allocation Technology ("CAT"), now
> Virtualization Machine Monitor ("VMM") has the ability to partition the
> cache allocation per VM, based on the priority of VM.
> 
> 
> CAT Introduction
> ================
> Generally speaking, CAT introduces a mechanism for software to enable
> cache allocation based on application priority or Class of Service
> ("COS"). Cache allocation for the respective applications is then
> restricted based on the COS with which they are associated. Each COS can
> be configured using capacity bitmasks ("CBM") which represent cache
> capacity and indicate the degree of overlap and isolation between
> classes. For each logical processor there is a register
> exposed(IA32_PQR_ASSOC MSR) to allow the OS/VMM to specify a COS when an
> application, thread or VM is scheduled. Cache allocation for the
> indicated application/thread/VM is then controlled automatically by the
> hardware based on the COS and the CBM associated with that class.
> Hardware initializes COS of each logical processor to 0 and the
> corresponding CBM is set to all-ones, means all the system cache
> resource can be used for each application.
> 
> For more information please refer to Section 17.15 in the Intel SDM [1].
> 
> 
> Design Overview
> ===============
> - Domain COS/CBM association
> When enforcing cache allocation for VMs, the minimum granularity is
> defined as the domain. All Virtual CPUs ("VCPUs") of a domain have the
> same COS, and therefore, correspond to the same CBM. COS is used only in
> hypervisor and is transparent to tool stack/user. System administrator
> can specify the initial CBM for each domain or change it at runtime using 
> tool stack. Hypervisor then choses a free COS to associate it with that
> CBM or find a existed COS which has the same CBM.
> 
> - VCPU Schedule
> When VCPU is scheduled on the physical CPU ("PCPU"), its COS value is
> then written to MSR (IA32_PQR_ASSOC) of PCPU to notify hardware to use 
> the new COS. The cache allocation is then enforced by hardware.
> 
> - Multi-Socket
> In multi-socket environment, each VCPU may be scheduled on different
> sockets. The hardware CAT ability(such as maximum supported COS and length
> of CBM) maybe different among sockets. For such system, per-socket COS/CBM
> configuration of a domain is specified. Hypervisor then use this per-socket
> CBM information for VCPU schedule.
> 
> 
> Implementation Description
> ==========================
> In this design, one principal is that only implementing the cache
> enforcement mechanism in hypervisor but leaving the cache allocation
> policy to user space tool stack. In this way some complex governors then
> can be implemented in tool stack. 
> 
> In summary, hypervisor changes include:
> 1) A new field "cat_info" in domain structure to indicate the CAT
>    information for each socket. It points to array of structure:
>    struct domain_socket_cat_info {
>        unsigned int cbm; /* CBM specified by toolstack  */
>        unsigned int cos; /* COS allocated by Hypervisor */
>    }
> 2) A new SYSCTL to expose the CAT information to tool stack:
>      * Whether CAT is enabled;
>      * Max COS supported;
>      * Length of CBM;
>      * Other needed information from host cpuid;
> 3) A new DOMCTL to allow tool stack to set/get CBM for a specified domain
>    for each socket.
> 4) Context switch: write COS of domain to MSR (IA32_PQR_ASSOC) of PCPU.
> 5) XSM policy to restrict the functions visibility to control domain only.
> 
> Hypervisor interfaces:
> 1) Boot line param: "psr=cat" to enable the feature.
> 2) SYSCTL: XEN_SYSCTL_psr_cat_op
>      - XEN_SYSCTL_PSR_CAT_INFO_GET: Get system CAT information;
> 3) DOMCTL: XEN_DOMCTL_psr_cat_op
>      - XEN_DOMCTL_PSR_CAT_OP_CBM_SET: Set CBM value for a domain.
>      - XEN_DOMCTL_PSR_CAT_OP_CBM_GET: Get CBM value for a domain.
> 
> xl interfaces:
> 1) psr-cat-show: Show system/runtime CAT information.
>      => XEN_SYSCTL_PSR_CAT_INFO_GET/XEN_DOMCTL_PSR_CAT_OP_CBM_GET
> 2) psr-cat-cbm-set [dom] [cbm] [socket]: Set CBM for a domain.
>      => XEN_DOMCTL_PSR_CAT_OP_CBM_SET
> 
> 
> Hardware Limitation & Performance Improvement
> =============================================
> As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
> switch. If the change is frequent then hardware may fail to strictly
> enforce the cache allocation basing on the specified COS. Due to this
> the strict placement characteristic would soften if VCPU is migrated on
> different PCPU frequently.
> 
> For this reason, lazy updating for IA32_PQR_ASSOC will be done. Also this
> design allows CAT to run in two modes:
> 
> 1) Non Affinitized mode: Each VM can be freely scheduled on any PCPU
> assigning its COS as it does.
> 
> 2) Affinitized mode: Each PCPU is assigned a fixed COS and a VM can be
> scheduled on the PCPU only when it has a same COS. It's less flexible
> but can be an option for those who must have strict COS placement or in
> cases where problems have arisen because of the less strict nature of the
> non-affinitized mode.
> 
> However, no additional code is designed to support these two modes. CAT is
> already running in non affinitized mode by default. If affinitized mode
> is desirable, then existed "xl vcpu-pin" command can be used to pin all
> the VCPUs which has the same COS to certain fixed PCPUs so that these 
> PCPUs always have the same COS set.
> 
> [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
> 
> 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 Tue Dec 16 09:30:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 09:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0oSg-00087M-6S; Tue, 16 Dec 2014 09:30: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 1Y0oSf-00087H-CN
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 09:30:33 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	9A/68-02702-8BBFF845; Tue, 16 Dec 2014 09:30:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418722230!15328874!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25196 invoked from network); 16 Dec 2014 09:30:31 -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;
	16 Dec 2014 09:30:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="205279090"
Message-ID: <1418722228.16425.179.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 16 Dec 2014 09:30:28 +0000
In-Reply-To: <20141215170757.GA1705@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
	<20141215170757.GA1705@perard.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: libvir-list@redhat.com, Jim
	Fehlig <jfehlig@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-15 at 17:07 +0000, Anthony PERARD wrote:
> On Thu, Dec 11, 2014 at 04:23:15PM +0000, Ian Campbell wrote:
> > On Thu, 2014-12-11 at 16:16 +0000, Anthony PERARD wrote:
> > > On Tue, Dec 09, 2014 at 03:56:02PM +0000, Ian Campbell wrote:
> > > > On Tue, 2014-12-09 at 15:39 +0000, Anthony PERARD wrote:
> > > > > The path to the pty of a Xen PV console is set only in
> > > > > virDomainOpenConsole. But this is done too late. A call to
> > > > > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > > > > the pty, but a call after OpenConsole will.
> > > > > 
> > > > > e.g. of the current issue.
> > > > > Starting a domain with '<console type="pty"/>'
> > > > > Then:
> > > > > virDomainGetXMLDesc():
> > > > >   <devices>
> > > > >     <console type='pty'>
> > > > >       <target type='xen' port='0'/>
> > > > >     </console>
> > > > >   </devices>
> > > > > virDomainOpenConsole()
> > > > > virDomainGetXMLDesc():
> > > > >   <devices>
> > > > >     <console type='pty' tty='/dev/pts/30'>
> > > > >       <source path='/dev/pts/30'/>
> > > > >       <target type='xen' port='0'/>
> > > > >     </console>
> > > > >   </devices>
> > > > > 
> > > > > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > > > > This is done by setting up the path at domain start up instead of in
> > > > > OpenConsole.
> > > > > 
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > > > > 
> > > > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > > > > 
> > > > > ---
> > > > > Change in V2:
> > > > >   Adding bug report link.
> > > > >   Reword the last part of the patch description.
> > > > >   Cleanup the code.
> > > > >   Use VIR_FREE before VIR_STRDUP.
> > > > >   Remove the code from OpenConsole as it is now a duplicate.
> > > > > ---
> > > > >  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
> > > > >  src/libxl/libxl_driver.c | 15 ---------------
> > > > >  2 files changed, 20 insertions(+), 15 deletions(-)
> > > > > 
> > > > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > > > index 9c62291..325de79 100644
> > > > > --- a/src/libxl/libxl_domain.c
> > > > > +++ b/src/libxl/libxl_domain.c
> > > > > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> > > > >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > > > >          goto cleanup_dom;
> > > > >  
> > > > > +    if (vm->def->nconsoles) {
> > > > > +        virDomainChrDefPtr chr = vm->def->consoles[0];
> > > > 
> > > > Given vm->def->nconsoles should we loop and do them all?
> > > 
> > > Maybe. libvirt it self will not be able to access any console that is
> > > not the first one (virDomainOpenConsole only provide access to console
> > > 0), but a consumer of libvirt could.
> > > 
> > > > Also, and I really should know the answer to this (and sorry for not
> > > > thinking of it earlier), but:
> > > > 
> > > > > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > > > > +                                        chr->target.port, console_type,
> > > > > +                                        &console);
> > > > 
> > > > Might this race against xenconsoled writing the node to xenstore and
> > > > therefore be prone to failing when starting multiple guests all at once?
> > > 
> > > I've look through out libxl, xenconsoled and libvirt, and I could not
> > > find any synchronisation point. So I guest it's possible.
> > > 
> > > > Is there a hook which is called on virsh dumpxml which could update
> > > > things on the fly (i.e. lookup the console iff it isn't already set)?
> > > 
> > > I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
> > > to do the check, or having a xenstore watch on the path (if that is
> > > possible).
> > 
> > The aop_console_how option to libxl_domain_create_new and
> > libxl_domain_create_restore is documented as:
> > 
> >   /* A progress report will be made via ao_console_how, of type
> >    * domain_create_console_available, when the domain's primary
> >    * console is available and can be connected to.
> >    */
> > 
> > Which sounds like exactly what is needed?
> 
> It looks like the progress is reported before the main function finish,
> from the description of the type libxl_asyncprogress_how (in libxl.h).

Correct.

> Also, I tryied to use it, it works if xenconsoled is running. But if
> xenconsoled is not running, then the callback is also called and
> libxl_console_get_tty() return an empty string.

I'm not sure xenconsoled not running is a configuration we need to worry
about, or at least it could be expected not to get a console in that
case.

Unless by "not running" you meant bottlenecked or not keeping up
perhaps.

> Or, maybe my test case is not relevant, so another question: Will
> libxl wait for xenconsoled to process the new domain before calling the
> callback?

I don't see an explicit wait in the code, but I don't know if it has
arranged the sequencing some other way.

> Or, should I set the callback to NULL and have the
> domain_create_console_available event sent through
> the callback set by libxl_event_register_callbacks()?

That would make sense, except I don't see libxl_evdisable_foo for these
events, so I'm not sure it 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 Tue Dec 16 09:30:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 09:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0oSg-00087M-6S; Tue, 16 Dec 2014 09:30: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 1Y0oSf-00087H-CN
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 09:30:33 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	9A/68-02702-8BBFF845; Tue, 16 Dec 2014 09:30:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418722230!15328874!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 25196 invoked from network); 16 Dec 2014 09:30:31 -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;
	16 Dec 2014 09:30:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="205279090"
Message-ID: <1418722228.16425.179.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 16 Dec 2014 09:30:28 +0000
In-Reply-To: <20141215170757.GA1705@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
	<20141215170757.GA1705@perard.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: libvir-list@redhat.com, Jim
	Fehlig <jfehlig@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-15 at 17:07 +0000, Anthony PERARD wrote:
> On Thu, Dec 11, 2014 at 04:23:15PM +0000, Ian Campbell wrote:
> > On Thu, 2014-12-11 at 16:16 +0000, Anthony PERARD wrote:
> > > On Tue, Dec 09, 2014 at 03:56:02PM +0000, Ian Campbell wrote:
> > > > On Tue, 2014-12-09 at 15:39 +0000, Anthony PERARD wrote:
> > > > > The path to the pty of a Xen PV console is set only in
> > > > > virDomainOpenConsole. But this is done too late. A call to
> > > > > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > > > > the pty, but a call after OpenConsole will.
> > > > > 
> > > > > e.g. of the current issue.
> > > > > Starting a domain with '<console type="pty"/>'
> > > > > Then:
> > > > > virDomainGetXMLDesc():
> > > > >   <devices>
> > > > >     <console type='pty'>
> > > > >       <target type='xen' port='0'/>
> > > > >     </console>
> > > > >   </devices>
> > > > > virDomainOpenConsole()
> > > > > virDomainGetXMLDesc():
> > > > >   <devices>
> > > > >     <console type='pty' tty='/dev/pts/30'>
> > > > >       <source path='/dev/pts/30'/>
> > > > >       <target type='xen' port='0'/>
> > > > >     </console>
> > > > >   </devices>
> > > > > 
> > > > > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > > > > This is done by setting up the path at domain start up instead of in
> > > > > OpenConsole.
> > > > > 
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > > > > 
> > > > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > > > > 
> > > > > ---
> > > > > Change in V2:
> > > > >   Adding bug report link.
> > > > >   Reword the last part of the patch description.
> > > > >   Cleanup the code.
> > > > >   Use VIR_FREE before VIR_STRDUP.
> > > > >   Remove the code from OpenConsole as it is now a duplicate.
> > > > > ---
> > > > >  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
> > > > >  src/libxl/libxl_driver.c | 15 ---------------
> > > > >  2 files changed, 20 insertions(+), 15 deletions(-)
> > > > > 
> > > > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > > > index 9c62291..325de79 100644
> > > > > --- a/src/libxl/libxl_domain.c
> > > > > +++ b/src/libxl/libxl_domain.c
> > > > > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> > > > >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > > > >          goto cleanup_dom;
> > > > >  
> > > > > +    if (vm->def->nconsoles) {
> > > > > +        virDomainChrDefPtr chr = vm->def->consoles[0];
> > > > 
> > > > Given vm->def->nconsoles should we loop and do them all?
> > > 
> > > Maybe. libvirt it self will not be able to access any console that is
> > > not the first one (virDomainOpenConsole only provide access to console
> > > 0), but a consumer of libvirt could.
> > > 
> > > > Also, and I really should know the answer to this (and sorry for not
> > > > thinking of it earlier), but:
> > > > 
> > > > > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > > > > +                                        chr->target.port, console_type,
> > > > > +                                        &console);
> > > > 
> > > > Might this race against xenconsoled writing the node to xenstore and
> > > > therefore be prone to failing when starting multiple guests all at once?
> > > 
> > > I've look through out libxl, xenconsoled and libvirt, and I could not
> > > find any synchronisation point. So I guest it's possible.
> > > 
> > > > Is there a hook which is called on virsh dumpxml which could update
> > > > things on the fly (i.e. lookup the console iff it isn't already set)?
> > > 
> > > I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
> > > to do the check, or having a xenstore watch on the path (if that is
> > > possible).
> > 
> > The aop_console_how option to libxl_domain_create_new and
> > libxl_domain_create_restore is documented as:
> > 
> >   /* A progress report will be made via ao_console_how, of type
> >    * domain_create_console_available, when the domain's primary
> >    * console is available and can be connected to.
> >    */
> > 
> > Which sounds like exactly what is needed?
> 
> It looks like the progress is reported before the main function finish,
> from the description of the type libxl_asyncprogress_how (in libxl.h).

Correct.

> Also, I tryied to use it, it works if xenconsoled is running. But if
> xenconsoled is not running, then the callback is also called and
> libxl_console_get_tty() return an empty string.

I'm not sure xenconsoled not running is a configuration we need to worry
about, or at least it could be expected not to get a console in that
case.

Unless by "not running" you meant bottlenecked or not keeping up
perhaps.

> Or, maybe my test case is not relevant, so another question: Will
> libxl wait for xenconsoled to process the new domain before calling the
> callback?

I don't see an explicit wait in the code, but I don't know if it has
arranged the sequencing some other way.

> Or, should I set the callback to NULL and have the
> domain_create_console_available event sent through
> the callback set by libxl_event_register_callbacks()?

That would make sense, except I don't see libxl_evdisable_foo for these
events, so I'm not sure it 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 Tue Dec 16 09:31:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 09:31:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0oTc-0008BD-LW; Tue, 16 Dec 2014 09:31:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y0oTb-0008B2-Oa
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 09:31:31 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	12/EA-08051-3FBFF845; Tue, 16 Dec 2014 09:31:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418722289!11997579!1
X-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 31936 invoked from network); 16 Dec 2014 09:31:30 -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; 16 Dec 2014 09:31:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 16 Dec 2014 09:31:23 +0000
Message-Id: <549009F9020000780004FCB3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 16 Dec 2014 09:31:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418682275-2505-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418682275-2505-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 v2 for 4.5] x86/VPMU: Clear last_vcpu when
 destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 23:24, <boris.ostrovsky@oracle.com> wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try to dereference it in
> the future, when VCPU is gone.
> 
> We have to do this via IPI since otherwise there is a (somewheat
> theoretical) chance that between test and subsequent clearing
> of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
> both load_vpmu() and then save_vpmu() for another VCPU. The former
> will clear last_vcpu and the latter will set it to something else.

Apart from the question of using cmpxchg instead of the IPI (I can
see with the current model that using an IPI is the only clean way,
i.e. the alternative - if usable - would mean altering existing logic
too), please be sure such descriptions are accurate: There are no
functions with the names you mention, and vpmu_load() alters
last_vcpu only indirectly (via vpmu_save_force()).

>  void vpmu_destroy(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> +    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> +        return;

This appears to make unnecessary the respective checks in
amd_vpmu_destroy() and core2_vpmu_destroy().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 09:31:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 09:31:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0oTc-0008BD-LW; Tue, 16 Dec 2014 09:31:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y0oTb-0008B2-Oa
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 09:31:31 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	12/EA-08051-3FBFF845; Tue, 16 Dec 2014 09:31:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418722289!11997579!1
X-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 31936 invoked from network); 16 Dec 2014 09:31:30 -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; 16 Dec 2014 09:31:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 16 Dec 2014 09:31:23 +0000
Message-Id: <549009F9020000780004FCB3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 16 Dec 2014 09:31:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418682275-2505-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418682275-2505-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 v2 for 4.5] x86/VPMU: Clear last_vcpu when
 destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 23:24, <boris.ostrovsky@oracle.com> wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try to dereference it in
> the future, when VCPU is gone.
> 
> We have to do this via IPI since otherwise there is a (somewheat
> theoretical) chance that between test and subsequent clearing
> of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
> both load_vpmu() and then save_vpmu() for another VCPU. The former
> will clear last_vcpu and the latter will set it to something else.

Apart from the question of using cmpxchg instead of the IPI (I can
see with the current model that using an IPI is the only clean way,
i.e. the alternative - if usable - would mean altering existing logic
too), please be sure such descriptions are accurate: There are no
functions with the names you mention, and vpmu_load() alters
last_vcpu only indirectly (via vpmu_save_force()).

>  void vpmu_destroy(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> +    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> +        return;

This appears to make unnecessary the respective checks in
amd_vpmu_destroy() and core2_vpmu_destroy().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 09:38:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 09: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 1Y0oa8-0000AT-HD; Tue, 16 Dec 2014 09:38:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y0oa7-0000AN-1o
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 09:38:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C3/8A-09842-68DFF845; Tue, 16 Dec 2014 09:38:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418722693!8571249!1
X-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 18111 invoked from network); 16 Dec 2014 09:38:13 -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; 16 Dec 2014 09:38:13 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 16 Dec 2014 09:38:12 +0000
Message-Id: <54900B91020000780004FCC2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 16 Dec 2014 09:38:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Chao Peng" <chao.p.peng@linux.intel.com>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141216085559.GB3105@pengc-linux.bj.intel.com>
In-Reply-To: <20141216085559.GB3105@pengc-linux.bj.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, George.Dunlap@eu.citrix.com,
	andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, will.auld@intel.com, keir@xen.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.12.14 at 09:55, <chao.p.peng@linux.intel.com> wrote:
> Any comments from you? It would be greatly appreciated if you can look
> at this when you have time. Your comments are always important to me :)

I don't think I have to say much here:

> On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote:
>> Implementation Description
>> ==========================
>> In this design, one principal is that only implementing the cache
>> enforcement mechanism in hypervisor but leaving the cache allocation
>> policy to user space tool stack. In this way some complex governors then
>> can be implemented in tool stack. 

With this, the changes to the hypervisor ought to be quite limited,
even if length of the list you give seems long at a first glance, and
hence I'm fine with the concept.

>> Hardware Limitation & Performance Improvement
>> =============================================
>> As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
>> switch. If the change is frequent then hardware may fail to strictly
>> enforce the cache allocation basing on the specified COS.

This certainly would deserve a little more explanation: What's the
value of the functionality if one can't rely on it being enforced by
hardware at all times?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 09:38:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 09: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 1Y0oa8-0000AT-HD; Tue, 16 Dec 2014 09:38:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y0oa7-0000AN-1o
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 09:38:15 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C3/8A-09842-68DFF845; Tue, 16 Dec 2014 09:38:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418722693!8571249!1
X-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 18111 invoked from network); 16 Dec 2014 09:38:13 -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; 16 Dec 2014 09:38:13 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 16 Dec 2014 09:38:12 +0000
Message-Id: <54900B91020000780004FCC2@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 16 Dec 2014 09:38:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Chao Peng" <chao.p.peng@linux.intel.com>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141216085559.GB3105@pengc-linux.bj.intel.com>
In-Reply-To: <20141216085559.GB3105@pengc-linux.bj.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, George.Dunlap@eu.citrix.com,
	andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, will.auld@intel.com, keir@xen.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.12.14 at 09:55, <chao.p.peng@linux.intel.com> wrote:
> Any comments from you? It would be greatly appreciated if you can look
> at this when you have time. Your comments are always important to me :)

I don't think I have to say much here:

> On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote:
>> Implementation Description
>> ==========================
>> In this design, one principal is that only implementing the cache
>> enforcement mechanism in hypervisor but leaving the cache allocation
>> policy to user space tool stack. In this way some complex governors then
>> can be implemented in tool stack. 

With this, the changes to the hypervisor ought to be quite limited,
even if length of the list you give seems long at a first glance, and
hence I'm fine with the concept.

>> Hardware Limitation & Performance Improvement
>> =============================================
>> As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
>> switch. If the change is frequent then hardware may fail to strictly
>> enforce the cache allocation basing on the specified COS.

This certainly would deserve a little more explanation: What's the
value of the functionality if one can't rely on it being enforced by
hardware at all times?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 09:46:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 09:46:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0ohq-0000Up-Fe; Tue, 16 Dec 2014 09:46:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0oho-0000Uk-Kg
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 09:46:12 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	58/C7-07724-36FFF845; Tue, 16 Dec 2014 09:46:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418723168!9224487!1
X-Originating-IP: [66.165.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 6193 invoked from network); 16 Dec 2014 09:46:10 -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;
	16 Dec 2014 09:46:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="205282403"
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.210.2; Tue, 16 Dec 2014 04:46: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 1Y0ohj-0006vi-7P;
	Tue, 16 Dec 2014 09:46:07 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0ohj-0007J7-1R;
	Tue, 16 Dec 2014 09:46:07 +0000
Date: Tue, 16 Dec 2014 09:46:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32387-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8233
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32387: 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="===============0354901306785417808=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0354901306785417808==
Content-Type: text/plain
Content-Length: 7918
Content-Transfer-Encoding: quoted-printable

flight 32387 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32387/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64  3 host-install(3)      broken REGR. vs. 32194
 test-amd64-amd64-xl-qemut-win7-amd64 6 leak-check/basis(6) fail REGR. vs. 32194

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32194

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-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-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-armhf-armhf-xl          10 migrate-support-check        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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                54600752a1dd67844c2cf3c467db562c39499838
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Amos Kong <akong@redhat.com>
  Anton Blanchard <anton@samba.org>
  Antony Pavlov <antonynpavlov@gmail.com>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Christoffer Dall <christoffer.dall@linaro.org>
  Dmitry Poletaev <poletaev-qemu@yandex.ru>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gary R Hook <gary.hook@nimboxx.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Jeff Cody <jcody@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  lijun <junmuzi@gmail.com>
  Liviu Ionescu <ilg@livius.net>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael Mueller <mimu@linux.vnet.ibm.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Nikita Belov <zodiac@ispras.ru>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
  Peter Maydell <peter.maydell@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@linux.vnet.ibm.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                              broken  
 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=3Fp=3Dosstest.git;a=3Dsummary

broken-step test-amd64-i386-freebsd10-amd64 host-install(3)

Not pushing.

(No revision log; it would be 2812 lines long.)


--===============0354901306785417808==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0354901306785417808==--

From xen-devel-bounces@lists.xen.org Tue Dec 16 09:46:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 09:46:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0ohq-0000Up-Fe; Tue, 16 Dec 2014 09:46:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0oho-0000Uk-Kg
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 09:46:12 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	58/C7-07724-36FFF845; Tue, 16 Dec 2014 09:46:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418723168!9224487!1
X-Originating-IP: [66.165.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 6193 invoked from network); 16 Dec 2014 09:46:10 -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;
	16 Dec 2014 09:46:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="205282403"
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.210.2; Tue, 16 Dec 2014 04:46: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 1Y0ohj-0006vi-7P;
	Tue, 16 Dec 2014 09:46:07 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0ohj-0007J7-1R;
	Tue, 16 Dec 2014 09:46:07 +0000
Date: Tue, 16 Dec 2014 09:46:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32387-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8233
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32387: 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="===============0354901306785417808=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0354901306785417808==
Content-Type: text/plain
Content-Length: 7918
Content-Transfer-Encoding: quoted-printable

flight 32387 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32387/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64  3 host-install(3)      broken REGR. vs. 32194
 test-amd64-amd64-xl-qemut-win7-amd64 6 leak-check/basis(6) fail REGR. vs. 32194

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32194

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-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-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-armhf-armhf-xl          10 migrate-support-check        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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                54600752a1dd67844c2cf3c467db562c39499838
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Amos Kong <akong@redhat.com>
  Anton Blanchard <anton@samba.org>
  Antony Pavlov <antonynpavlov@gmail.com>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Christoffer Dall <christoffer.dall@linaro.org>
  Dmitry Poletaev <poletaev-qemu@yandex.ru>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gary R Hook <gary.hook@nimboxx.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Jeff Cody <jcody@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  lijun <junmuzi@gmail.com>
  Liviu Ionescu <ilg@livius.net>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael Mueller <mimu@linux.vnet.ibm.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Nikita Belov <zodiac@ispras.ru>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
  Peter Maydell <peter.maydell@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@linux.vnet.ibm.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                              broken  
 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=3Fp=3Dosstest.git;a=3Dsummary

broken-step test-amd64-i386-freebsd10-amd64 host-install(3)

Not pushing.

(No revision log; it would be 2812 lines long.)


--===============0354901306785417808==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0354901306785417808==--

From xen-devel-bounces@lists.xen.org Tue Dec 16 09:51:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 09: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 1Y0omm-0000fF-Dt; Tue, 16 Dec 2014 09:51: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 1Y0oml-0000fA-8c
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 09:51:19 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	53/85-11608-69000945; Tue, 16 Dec 2014 09:51:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418723476!13603327!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 2643 invoked from network); 16 Dec 2014 09:51:17 -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;
	16 Dec 2014 09:51:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="204822128"
Message-ID: <1418723474.16425.193.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Tue, 16 Dec 2014 09:51:14 +0000
In-Reply-To: <548F60BF.4020901@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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] 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 Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> Hello Ian,
> 
> On 15.12.2014 18:45, Ian Campbell wrote:
> > On Mon, 2014-12-15 at 14:50 +0000, Ian Campbell wrote:
> >> On Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
> >>> I just noticed something strange:
> >>>
> >>>> #3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
> >>>> 0xff00000000 out of bounds>, hash_size=0,
> >>>>     tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
> ...
> > I'm reasonably convinced now that this is just a weird artefact of
> > running gdb on an optimised binary, probably a shortcoming in the debug
> > info leading to gdb getting confused.
> > 
> > Unfortunately this also calls into doubt the parameter to talloc_free,
> > perhaps in that context 0xff0000000 is a similar artefact.
> > 
> > Please can you print the entire contents of tdb in the second frame
> > ("print *tdb" ought to do it). I'm curious whether it is all sane or
> > not.
> 
> (gdb) print *tdb
> $1 = {name = 0x0, map_ptr = 0x0, fd = 47, map_size = 65280, read_only =
> 16711680,
>   locked = 0xff0000000000,

So it really does seem to be 0xff0000000000 in memory.

> flags = 0,
> travlocks = {
>     next = 0xff0000, off = 0, hash = 65280}, next = 0xff0000,
>   device = 280375465082880, inode = 16711680, log_fn = 0x4093b0
> <null_log_fn>,
>   hash_fn = 0x4092f0 <default_tdb_hash>, open_flags = 2}

And here we can see tdb->{flags,open_flags} == 0 and 2, contrary to what
the stack trace says we were called with, which was nonsense. Since 0
and 2 are sensible and correspond to what the caller passes I think the
stack trace is just confused.

> (gdb) info registers
> rax            0x0      0
> rbx            0x16bff70        23854960
> rcx            0xffffffffffffffff       -1
> rdx            0x40ecd0 4254928
> rsi            0x0      0
> rdi            0xff0000000000   280375465082880

And here it is in the registers.

> rbp            0x7fcaed6c96a8   0x7fcaed6c96a8
> rsp            0x7fff9dc86330   0x7fff9dc86330
> r8             0x7fcaece54c08   140509534571528
> r9             0xff00000000000000       -72057594037927936
> r10            0x7fcaed08c14c   140509536895308
> r11            0x246    582
> r12            0xd      13
> r13            0xff0000000000   280375465082880

And again.

> r14            0x4093b0 4232112
> r15            0x167d620        23582240
> rip            0x4075c4 0x4075c4 <talloc_chunk_from_ptr+4>

This must be the faulting address.

> eflags         0x10206  [ PF IF RF ]
> cs             0x33     51
> ss             0x2b     43
> ds             0x0      0
> es             0x0      0
> fs             0x0      0
> gs             0x0      0
> fctrl          0x0      0
> fstat          0x0      0
> ftag           0x0      0
> fiseg          0x0      0
> fioff          0x0      0
> foseg          0x0      0
> fooff          0x0      0
> fop            0x0      0
> mxcsr          0x0      [ ]
> 
> (gdb) disassemble
> Dump of assembler code for function talloc_chunk_from_ptr:
> 0x00000000004075c0 <talloc_chunk_from_ptr+0>:   sub    $0x8,%rsp
> 0x00000000004075c4 <talloc_chunk_from_ptr+4>:   mov    -0x8(%rdi),%edx

This is the line corresponding to %rip above which is doing a read via %
rdi, which is 0xff0000000000.

It's reading tc->flags. It's been optimised, tc = pp - SIZE, so it is
loading *(pp-SIZE+offsetof(flags)), which is pp-8 (flags is the last
field in the struct).

So rdi contains pp which == the ptr given as an argument to the
function, so ptr was bogus.

So it seems we really do have tdb->locked containing 0xff0000000000.

This is only allocated in one place which is:
	tdb->locked = talloc_zero_array(tdb, struct tdb_lock_type,
					tdb->header.hash_size+1);
midway through tdb_open_ex. It might be worth inserting a check+log for
this returning  0xff, 0xff00, 0xff0000 ... 0xff0000000000 etc.

> 0x00000000004075c7 <talloc_chunk_from_ptr+7>:   lea    -0x50(%rdi),%rax

This is actually calculating tc, ready for return upon success.

> 0x00000000004075cb <talloc_chunk_from_ptr+11>:  mov    %edx,%ecx
> 0x00000000004075cd <talloc_chunk_from_ptr+13>:  and    $0xfffffffffffffff0,%ecx
> 0x00000000004075d0 <talloc_chunk_from_ptr+16>:  cmp    $0xe814ec70,%ecx
> 0x00000000004075d6 <talloc_chunk_from_ptr+22>:  jne    0x4075e2 <talloc_chunk_from_ptr+34>

(tc->flags & ~0xF) != TALLOC_MAGIC

> 0x00000000004075d8 <talloc_chunk_from_ptr+24>:  and    $0x1,%edx
> 0x00000000004075db <talloc_chunk_from_ptr+27>:  jne    0x4075e2 <talloc_chunk_from_ptr+34>

tc->flags & TALLOC_FLAG_FREE

> 0x00000000004075dd <talloc_chunk_from_ptr+29>:  add    $0x8,%rsp
> 0x00000000004075e1 <talloc_chunk_from_ptr+33>:  retq

Success, return.

> 0x00000000004075e2 <talloc_chunk_from_ptr+34>:  nopw   0x0(%rax,%rax,1)
> 0x00000000004075e8 <talloc_chunk_from_ptr+40>:  callq  0x401b98 <abort@plt>

The two TALLOC_ABORTS both end up here if the checks above fail.

> > Can you also "p $_siginfo._sifields._sigfault.si_addr" (in frame 0).
> > This ought to be the actual faulting address, which ought to give a hint
> > on how much we can trust the parameters in the stack trace.
> 
> Hmm, my gdb refused to access $_siginfo:
> (gdb) show convenience
> $_siginfo = Unable to read siginfo

That's ok, I think I've convinced myself above what the crash is.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 09:51:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 09: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 1Y0omm-0000fF-Dt; Tue, 16 Dec 2014 09:51: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 1Y0oml-0000fA-8c
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 09:51:19 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	53/85-11608-69000945; Tue, 16 Dec 2014 09:51:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418723476!13603327!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 2643 invoked from network); 16 Dec 2014 09:51:17 -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;
	16 Dec 2014 09:51:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="204822128"
Message-ID: <1418723474.16425.193.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Tue, 16 Dec 2014 09:51:14 +0000
In-Reply-To: <548F60BF.4020901@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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] 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 Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> Hello Ian,
> 
> On 15.12.2014 18:45, Ian Campbell wrote:
> > On Mon, 2014-12-15 at 14:50 +0000, Ian Campbell wrote:
> >> On Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
> >>> I just noticed something strange:
> >>>
> >>>> #3  0x000000000040a684 in tdb_open (name=0xff00000000 <Address
> >>>> 0xff00000000 out of bounds>, hash_size=0,
> >>>>     tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
> ...
> > I'm reasonably convinced now that this is just a weird artefact of
> > running gdb on an optimised binary, probably a shortcoming in the debug
> > info leading to gdb getting confused.
> > 
> > Unfortunately this also calls into doubt the parameter to talloc_free,
> > perhaps in that context 0xff0000000 is a similar artefact.
> > 
> > Please can you print the entire contents of tdb in the second frame
> > ("print *tdb" ought to do it). I'm curious whether it is all sane or
> > not.
> 
> (gdb) print *tdb
> $1 = {name = 0x0, map_ptr = 0x0, fd = 47, map_size = 65280, read_only =
> 16711680,
>   locked = 0xff0000000000,

So it really does seem to be 0xff0000000000 in memory.

> flags = 0,
> travlocks = {
>     next = 0xff0000, off = 0, hash = 65280}, next = 0xff0000,
>   device = 280375465082880, inode = 16711680, log_fn = 0x4093b0
> <null_log_fn>,
>   hash_fn = 0x4092f0 <default_tdb_hash>, open_flags = 2}

And here we can see tdb->{flags,open_flags} == 0 and 2, contrary to what
the stack trace says we were called with, which was nonsense. Since 0
and 2 are sensible and correspond to what the caller passes I think the
stack trace is just confused.

> (gdb) info registers
> rax            0x0      0
> rbx            0x16bff70        23854960
> rcx            0xffffffffffffffff       -1
> rdx            0x40ecd0 4254928
> rsi            0x0      0
> rdi            0xff0000000000   280375465082880

And here it is in the registers.

> rbp            0x7fcaed6c96a8   0x7fcaed6c96a8
> rsp            0x7fff9dc86330   0x7fff9dc86330
> r8             0x7fcaece54c08   140509534571528
> r9             0xff00000000000000       -72057594037927936
> r10            0x7fcaed08c14c   140509536895308
> r11            0x246    582
> r12            0xd      13
> r13            0xff0000000000   280375465082880

And again.

> r14            0x4093b0 4232112
> r15            0x167d620        23582240
> rip            0x4075c4 0x4075c4 <talloc_chunk_from_ptr+4>

This must be the faulting address.

> eflags         0x10206  [ PF IF RF ]
> cs             0x33     51
> ss             0x2b     43
> ds             0x0      0
> es             0x0      0
> fs             0x0      0
> gs             0x0      0
> fctrl          0x0      0
> fstat          0x0      0
> ftag           0x0      0
> fiseg          0x0      0
> fioff          0x0      0
> foseg          0x0      0
> fooff          0x0      0
> fop            0x0      0
> mxcsr          0x0      [ ]
> 
> (gdb) disassemble
> Dump of assembler code for function talloc_chunk_from_ptr:
> 0x00000000004075c0 <talloc_chunk_from_ptr+0>:   sub    $0x8,%rsp
> 0x00000000004075c4 <talloc_chunk_from_ptr+4>:   mov    -0x8(%rdi),%edx

This is the line corresponding to %rip above which is doing a read via %
rdi, which is 0xff0000000000.

It's reading tc->flags. It's been optimised, tc = pp - SIZE, so it is
loading *(pp-SIZE+offsetof(flags)), which is pp-8 (flags is the last
field in the struct).

So rdi contains pp which == the ptr given as an argument to the
function, so ptr was bogus.

So it seems we really do have tdb->locked containing 0xff0000000000.

This is only allocated in one place which is:
	tdb->locked = talloc_zero_array(tdb, struct tdb_lock_type,
					tdb->header.hash_size+1);
midway through tdb_open_ex. It might be worth inserting a check+log for
this returning  0xff, 0xff00, 0xff0000 ... 0xff0000000000 etc.

> 0x00000000004075c7 <talloc_chunk_from_ptr+7>:   lea    -0x50(%rdi),%rax

This is actually calculating tc, ready for return upon success.

> 0x00000000004075cb <talloc_chunk_from_ptr+11>:  mov    %edx,%ecx
> 0x00000000004075cd <talloc_chunk_from_ptr+13>:  and    $0xfffffffffffffff0,%ecx
> 0x00000000004075d0 <talloc_chunk_from_ptr+16>:  cmp    $0xe814ec70,%ecx
> 0x00000000004075d6 <talloc_chunk_from_ptr+22>:  jne    0x4075e2 <talloc_chunk_from_ptr+34>

(tc->flags & ~0xF) != TALLOC_MAGIC

> 0x00000000004075d8 <talloc_chunk_from_ptr+24>:  and    $0x1,%edx
> 0x00000000004075db <talloc_chunk_from_ptr+27>:  jne    0x4075e2 <talloc_chunk_from_ptr+34>

tc->flags & TALLOC_FLAG_FREE

> 0x00000000004075dd <talloc_chunk_from_ptr+29>:  add    $0x8,%rsp
> 0x00000000004075e1 <talloc_chunk_from_ptr+33>:  retq

Success, return.

> 0x00000000004075e2 <talloc_chunk_from_ptr+34>:  nopw   0x0(%rax,%rax,1)
> 0x00000000004075e8 <talloc_chunk_from_ptr+40>:  callq  0x401b98 <abort@plt>

The two TALLOC_ABORTS both end up here if the checks above fail.

> > Can you also "p $_siginfo._sifields._sigfault.si_addr" (in frame 0).
> > This ought to be the actual faulting address, which ought to give a hint
> > on how much we can trust the parameters in the stack trace.
> 
> Hmm, my gdb refused to access $_siginfo:
> (gdb) show convenience
> $_siginfo = Unable to read siginfo

That's ok, I think I've convinced myself above what the crash is.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 10:12:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 10:12:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0p79-0001bU-3N; Tue, 16 Dec 2014 10:12:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bob.liu@oracle.com>) id 1Y0p78-0001bO-JO
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 10:12:22 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6F/79-25276-58500945; Tue, 16 Dec 2014 10:12:21 +0000
X-Env-Sender: bob.liu@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418724739!15885080!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14682 invoked from network); 16 Dec 2014 10:12:21 -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; 16 Dec 2014 10:12: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 sBGACFjc003699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Dec 2014 10:12: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
	sBGACEso013865
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 16 Dec 2014 10:12:14 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
	sBGACDva013780; Tue, 16 Dec 2014 10:12:13 GMT
Received: from boliuliu.home (/218.82.189.246)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Dec 2014 02:12:13 -0800
From: Bob Liu <bob.liu@oracle.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 18:11:36 +0800
Message-Id: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>
X-Mailer: git-send-email 1.7.10.4
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Bob Liu <bob.liu@oracle.com>, david.vrabel@citrix.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen/blkfront: increase the default value of
	xen_blkif_max_segments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The default maximum value of segments in indirect requests was 32, IO
operations with bigger block size(>32*4k) would be split and performance start
to drop.

Nowadays backend device usually support 512k max_sectors_kb on desktop, and
may larger on server machines with high-end storage system.
The default size 128k was not very appropriate, this patch increases the default
maximum value to 128(128*4k=512k).

Signed-off-by: Bob Liu <bob.liu@oracle.com>
---
 drivers/block/xen-blkfront.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2236c6f..1bf2429 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -94,9 +94,9 @@ static const struct block_device_operations xlvbd_block_fops;
  * by the backend driver.
  */
 
-static unsigned int xen_blkif_max_segments = 32;
+static unsigned int xen_blkif_max_segments = 128;
 module_param_named(max, xen_blkif_max_segments, int, S_IRUGO);
-MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests (default is 32)");
+MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests (default is 128)");
 
 #define BLK_RING_SIZE __CONST_RING_SIZE(blkif, PAGE_SIZE)
 
-- 
1.7.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 Dec 16 10:12:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 10:12:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0p79-0001bU-3N; Tue, 16 Dec 2014 10:12:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bob.liu@oracle.com>) id 1Y0p78-0001bO-JO
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 10:12:22 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	6F/79-25276-58500945; Tue, 16 Dec 2014 10:12:21 +0000
X-Env-Sender: bob.liu@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1418724739!15885080!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14682 invoked from network); 16 Dec 2014 10:12:21 -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; 16 Dec 2014 10:12: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 sBGACFjc003699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Dec 2014 10:12: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
	sBGACEso013865
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 16 Dec 2014 10:12:14 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
	sBGACDva013780; Tue, 16 Dec 2014 10:12:13 GMT
Received: from boliuliu.home (/218.82.189.246)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Dec 2014 02:12:13 -0800
From: Bob Liu <bob.liu@oracle.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 18:11:36 +0800
Message-Id: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>
X-Mailer: git-send-email 1.7.10.4
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Bob Liu <bob.liu@oracle.com>, david.vrabel@citrix.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen/blkfront: increase the default value of
	xen_blkif_max_segments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The default maximum value of segments in indirect requests was 32, IO
operations with bigger block size(>32*4k) would be split and performance start
to drop.

Nowadays backend device usually support 512k max_sectors_kb on desktop, and
may larger on server machines with high-end storage system.
The default size 128k was not very appropriate, this patch increases the default
maximum value to 128(128*4k=512k).

Signed-off-by: Bob Liu <bob.liu@oracle.com>
---
 drivers/block/xen-blkfront.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2236c6f..1bf2429 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -94,9 +94,9 @@ static const struct block_device_operations xlvbd_block_fops;
  * by the backend driver.
  */
 
-static unsigned int xen_blkif_max_segments = 32;
+static unsigned int xen_blkif_max_segments = 128;
 module_param_named(max, xen_blkif_max_segments, int, S_IRUGO);
-MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests (default is 32)");
+MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests (default is 128)");
 
 #define BLK_RING_SIZE __CONST_RING_SIZE(blkif, PAGE_SIZE)
 
-- 
1.7.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 Dec 16 10:25:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 10:25:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0pJD-0002Lp-Nu; Tue, 16 Dec 2014 10:24:51 +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 1Y0pJC-0002Lf-HN
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 10:24:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9A/40-15461-17800945; Tue, 16 Dec 2014 10:24:49 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418725488!15857044!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 14009 invoked from network); 16 Dec 2014 10:24:49 -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;
	16 Dec 2014 10:24:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="205291520"
Message-ID: <5490086D.2060808@citrix.com>
Date: Tue, 16 Dec 2014 10:24:45 +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: Juergen Gross <jgross@suse.com>, David Vrabel <david.vrabel@citrix.com>,
	<linux-kernel@vger.kernel.org>, <x86@kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<boris.ostrovsky@oracle.com>, <tglx@linutronix.de>, <mingo@redhat.com>, 
	<hpa@zytor.com>, <mmarek@suse.cz>, <linux-kbuild@vger.kernel.org>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>	<1418321065-10212-5-git-send-email-jgross@suse.com>	<548ECE9B.3040105@citrix.com>
	<548FC95E.70903@suse.com>
In-Reply-To: <548FC95E.70903@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH 4/4] xen: use generated hypercall symbols in
 arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/12/14 05:55, Juergen Gross wrote:
> On 12/15/2014 01:05 PM, David Vrabel wrote:
>> On 11/12/14 18:04, Juergen Gross wrote:
>>> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
>>> use the auto generated symbol list.
>>>
>>> This also corrects the wrong address of xen_hypercall_mca which was
>>> located 32 bytes higher than it should.
>>>
>>> Symbol addresses have been verified to match the correct ones via
>>> objdump output.
>> [...]
>>> +
>>> +#define HYPERCALL(n) \
>>> +    .equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \
>>> +    .type xen_hypercall_##n, function; .size xen_hypercall_##n, 32
>>> +#include <asm/xen-hypercalls.h>
>>> +#undef HYPERCALL
>>
>> The gas manual[1] suggests the syntax you've used for .type is invalid
>> and suggest using .type <name>, STT_FUNC
> 
> Really? In the link below I see:
> 
> The types supported are:
> 
> STT_FUNC
> function
>     Mark the symbol as being a function name.
> ...
> 
> So "function" seems to be okay.

>From the manual

    The syntaxes supported are:

       .type <name> STT_<TYPE_IN_UPPER_CASE>
       .type <name>,#<type>
       .type <name>,@<type>
       .type <name>,%<type>
       .type <name>,"<type>"

And

    The first variant will be accepted by the GNU assembler on all
    architectures...

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 10:25:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 10:25:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0pJD-0002Lp-Nu; Tue, 16 Dec 2014 10:24:51 +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 1Y0pJC-0002Lf-HN
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 10:24:50 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	9A/40-15461-17800945; Tue, 16 Dec 2014 10:24:49 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418725488!15857044!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 14009 invoked from network); 16 Dec 2014 10:24:49 -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;
	16 Dec 2014 10:24:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="205291520"
Message-ID: <5490086D.2060808@citrix.com>
Date: Tue, 16 Dec 2014 10:24:45 +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: Juergen Gross <jgross@suse.com>, David Vrabel <david.vrabel@citrix.com>,
	<linux-kernel@vger.kernel.org>, <x86@kernel.org>,
	<xen-devel@lists.xensource.com>, <konrad.wilk@oracle.com>,
	<boris.ostrovsky@oracle.com>, <tglx@linutronix.de>, <mingo@redhat.com>, 
	<hpa@zytor.com>, <mmarek@suse.cz>, <linux-kbuild@vger.kernel.org>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>	<1418321065-10212-5-git-send-email-jgross@suse.com>	<548ECE9B.3040105@citrix.com>
	<548FC95E.70903@suse.com>
In-Reply-To: <548FC95E.70903@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [PATCH 4/4] xen: use generated hypercall symbols in
 arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/12/14 05:55, Juergen Gross wrote:
> On 12/15/2014 01:05 PM, David Vrabel wrote:
>> On 11/12/14 18:04, Juergen Gross wrote:
>>> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
>>> use the auto generated symbol list.
>>>
>>> This also corrects the wrong address of xen_hypercall_mca which was
>>> located 32 bytes higher than it should.
>>>
>>> Symbol addresses have been verified to match the correct ones via
>>> objdump output.
>> [...]
>>> +
>>> +#define HYPERCALL(n) \
>>> +    .equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \
>>> +    .type xen_hypercall_##n, function; .size xen_hypercall_##n, 32
>>> +#include <asm/xen-hypercalls.h>
>>> +#undef HYPERCALL
>>
>> The gas manual[1] suggests the syntax you've used for .type is invalid
>> and suggest using .type <name>, STT_FUNC
> 
> Really? In the link below I see:
> 
> The types supported are:
> 
> STT_FUNC
> function
>     Mark the symbol as being a function name.
> ...
> 
> So "function" seems to be okay.

>From the manual

    The syntaxes supported are:

       .type <name> STT_<TYPE_IN_UPPER_CASE>
       .type <name>,#<type>
       .type <name>,@<type>
       .type <name>,%<type>
       .type <name>,"<type>"

And

    The first variant will be accepted by the GNU assembler on all
    architectures...

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 10:26:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 10:26:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0pKL-0002Tn-GZ; Tue, 16 Dec 2014 10:26:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0pKK-0002Tc-92
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 10:26:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	41/88-09842-7B800945; Tue, 16 Dec 2014 10:25:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418725557!15899086!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 26622 invoked from network); 16 Dec 2014 10:25:58 -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;
	16 Dec 2014 10:25:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="205291742"
Message-ID: <1418725555.16425.205.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Tue, 16 Dec 2014 10:25:55 +0000
In-Reply-To: <548F60BF.4020901@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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 Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> (gdb) print *tdb
> $1 = {name = 0x0, map_ptr = 0x0, fd = 47, map_size = 65280, read_only =
> 16711680,
>   locked = 0xff0000000000, ecode = 16711680, header = {
>     magic_food =
> "\000\000\000\000\000\000\000\000\000\377\000\000\000\000\377\000\000\000\000\000\000\000\000\000\000\377\000\000\000\000\377",
> version = 0, hash_size = 0,

tdb->fd has been initialised, but version and hash_size have not yet.
This means we must have failed somewhere between the open() and the call
to tdb_new_database() (the second one, the first one is only if
TDB_INTERNAL, which is not the case here).

There are three interesting actions in that space.

The first is tdb_brlock, which could have gone wrong.

The second is ftruncate(). This is not a candidate because tdb->flags
doesn't have TDB_CLEAR_IF_FIRST (the actual test is on tdb_flags, which
is changed by the time of the stack trace, but it is stored in
tdb->flags where we can see it. tdb_flags isn't changed before the
check, so baring compiler problems I think we can rule that out).

The third is the read of the header itself. The fact that
tdb->header.magic_food isn't either all zeroes or the requisite magic
string "TDB file\n" is suspicious. Instead it is mostly zero with the
off 0xff in it. An interesting pattern of 0xff..00..00, may be a
coincidence, or not.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 10:26:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 10:26:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0pKL-0002Tn-GZ; Tue, 16 Dec 2014 10:26:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0pKK-0002Tc-92
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 10:26:00 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	41/88-09842-7B800945; Tue, 16 Dec 2014 10:25:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418725557!15899086!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 26622 invoked from network); 16 Dec 2014 10:25:58 -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;
	16 Dec 2014 10:25:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="205291742"
Message-ID: <1418725555.16425.205.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Tue, 16 Dec 2014 10:25:55 +0000
In-Reply-To: <548F60BF.4020901@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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 Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> (gdb) print *tdb
> $1 = {name = 0x0, map_ptr = 0x0, fd = 47, map_size = 65280, read_only =
> 16711680,
>   locked = 0xff0000000000, ecode = 16711680, header = {
>     magic_food =
> "\000\000\000\000\000\000\000\000\000\377\000\000\000\000\377\000\000\000\000\000\000\000\000\000\000\377\000\000\000\000\377",
> version = 0, hash_size = 0,

tdb->fd has been initialised, but version and hash_size have not yet.
This means we must have failed somewhere between the open() and the call
to tdb_new_database() (the second one, the first one is only if
TDB_INTERNAL, which is not the case here).

There are three interesting actions in that space.

The first is tdb_brlock, which could have gone wrong.

The second is ftruncate(). This is not a candidate because tdb->flags
doesn't have TDB_CLEAR_IF_FIRST (the actual test is on tdb_flags, which
is changed by the time of the stack trace, but it is stored in
tdb->flags where we can see it. tdb_flags isn't changed before the
check, so baring compiler problems I think we can rule that out).

The third is the read of the header itself. The fact that
tdb->header.magic_food isn't either all zeroes or the requisite magic
string "TDB file\n" is suspicious. Instead it is mostly zero with the
off 0xff in it. An interesting pattern of 0xff..00..00, may be a
coincidence, or not.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 10:32:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 10:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0pQk-0002wv-E9; Tue, 16 Dec 2014 10:32:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Y0pQj-0002vr-8t
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 10:32:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6A/7B-09842-44A00945; Tue, 16 Dec 2014 10:32:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418725954!15548406!1
X-Originating-IP: [66.165.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 27373 invoked from network); 16 Dec 2014 10:32:36 -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;
	16 Dec 2014 10:32:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="204831253"
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.210.2;
	Tue, 16 Dec 2014 05:32:34 -0500
Message-ID: <54900A3F.7070300@citrix.com>
Date: Tue, 16 Dec 2014 11:32:31 +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.3.0
MIME-Version: 1.0
To: Bob Liu <bob.liu@oracle.com>, <xen-devel@lists.xen.org>
References: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>
In-Reply-To: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>
X-DLP: MIA2
Cc: david.vrabel@citrix.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: increase the default value of
 xen_blkif_max_segments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 16/12/14 a les 11.11, Bob Liu ha escrit:
> The default maximum value of segments in indirect requests was 32, IO
> operations with bigger block size(>32*4k) would be split and performance start
> to drop.
> 
> Nowadays backend device usually support 512k max_sectors_kb on desktop, and
> may larger on server machines with high-end storage system.
> The default size 128k was not very appropriate, this patch increases the default
> maximum value to 128(128*4k=512k).

This looks fine, do you have any data/graphs to backup your reasoning?

I would also add to the commit message that this change implies we can
now have 32*128+32 = 4128 in-flight grants, which greatly surpasses the
default amount of persistent grants blkback can handle, so the LRU in
blkback will kick in.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 10:32:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 10:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0pQk-0002wv-E9; Tue, 16 Dec 2014 10:32:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Y0pQj-0002vr-8t
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 10:32:37 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6A/7B-09842-44A00945; Tue, 16 Dec 2014 10:32:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418725954!15548406!1
X-Originating-IP: [66.165.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 27373 invoked from network); 16 Dec 2014 10:32:36 -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;
	16 Dec 2014 10:32:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="204831253"
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.210.2;
	Tue, 16 Dec 2014 05:32:34 -0500
Message-ID: <54900A3F.7070300@citrix.com>
Date: Tue, 16 Dec 2014 11:32:31 +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.3.0
MIME-Version: 1.0
To: Bob Liu <bob.liu@oracle.com>, <xen-devel@lists.xen.org>
References: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>
In-Reply-To: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>
X-DLP: MIA2
Cc: david.vrabel@citrix.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: increase the default value of
 xen_blkif_max_segments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 16/12/14 a les 11.11, Bob Liu ha escrit:
> The default maximum value of segments in indirect requests was 32, IO
> operations with bigger block size(>32*4k) would be split and performance start
> to drop.
> 
> Nowadays backend device usually support 512k max_sectors_kb on desktop, and
> may larger on server machines with high-end storage system.
> The default size 128k was not very appropriate, this patch increases the default
> maximum value to 128(128*4k=512k).

This looks fine, do you have any data/graphs to backup your reasoning?

I would also add to the commit message that this change implies we can
now have 32*128+32 = 4128 in-flight grants, which greatly surpasses the
default amount of persistent grants blkback can handle, so the LRU in
blkback will kick in.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 10:45:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 10:45:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0pd0-0003Lu-OA; Tue, 16 Dec 2014 10:45:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0pcz-0003Lp-6Y
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 10:45:17 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	9A/8F-18267-C3D00945; Tue, 16 Dec 2014 10:45:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418726714!13703161!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 14642 invoked from network); 16 Dec 2014 10:45:15 -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;
	16 Dec 2014 10:45:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,586,1413244800"; d="scan'208";a="205295880"
Message-ID: <1418726712.16425.213.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Tue, 16 Dec 2014 10:45:12 +0000
In-Reply-To: <548F60BF.4020901@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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] 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 Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> > I notice in your bugzilla (for a different occurrence, I think):
> >> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
> > 
> > Which appears to have faulted access 0xff000000000 too. It looks like
> > this process is a python thing, it's nothing to do with xenstored I
> > assume?
> 
> Yes, that's one univention-config, which is completely independent of
> xen(stored).
> 
> > It seems rather coincidental that it should be accessing the 
> > same sort of address and be faulting.
> 
> Yes, good catch. I'll have another look at those core dumps.

With this in mind, please can you confirm what model of machines you've
seen this on, and in particular whether they are all the same class of
machine or whether they are significantly different.

The reason being that randomly placed 0xff values in a field of 0x00
could possibly indicate hardware (e.g. a GPU) DMAing over the wrong
memory pages.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 10:45:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 10:45:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0pd0-0003Lu-OA; Tue, 16 Dec 2014 10:45:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0pcz-0003Lp-6Y
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 10:45:17 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	9A/8F-18267-C3D00945; Tue, 16 Dec 2014 10:45:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418726714!13703161!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 14642 invoked from network); 16 Dec 2014 10:45:15 -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;
	16 Dec 2014 10:45:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,586,1413244800"; d="scan'208";a="205295880"
Message-ID: <1418726712.16425.213.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Tue, 16 Dec 2014 10:45:12 +0000
In-Reply-To: <548F60BF.4020901@univention.de>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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] 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 Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> > I notice in your bugzilla (for a different occurrence, I think):
> >> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
> > 
> > Which appears to have faulted access 0xff000000000 too. It looks like
> > this process is a python thing, it's nothing to do with xenstored I
> > assume?
> 
> Yes, that's one univention-config, which is completely independent of
> xen(stored).
> 
> > It seems rather coincidental that it should be accessing the 
> > same sort of address and be faulting.
> 
> Yes, good catch. I'll have another look at those core dumps.

With this in mind, please can you confirm what model of machines you've
seen this on, and in particular whether they are all the same class of
machine or whether they are significantly different.

The reason being that randomly placed 0xff values in a field of 0x00
could possibly indicate hardware (e.g. a GPU) DMAing over the wrong
memory pages.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 11:06:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 11:06:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0pxI-0003vA-QY; Tue, 16 Dec 2014 11:06: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 1Y0pxG-0003v5-V8
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 11:06:15 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	D4/24-22777-62210945; Tue, 16 Dec 2014 11:06:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418727972!13610953!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 27813 invoked from network); 16 Dec 2014 11:06:13 -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;
	16 Dec 2014 11:06:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,586,1413244800"; d="scan'208";a="205300607"
Message-ID: <1418727970.16425.217.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Tue, 16 Dec 2014 11:06:10 +0000
In-Reply-To: <1418726712.16425.213.camel@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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] 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 Tue, 2014-12-16 at 10:45 +0000, Ian Campbell wrote:
> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> > > I notice in your bugzilla (for a different occurrence, I think):
> > >> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
> > > 
> > > Which appears to have faulted access 0xff000000000 too. It looks like
> > > this process is a python thing, it's nothing to do with xenstored I
> > > assume?
> > 
> > Yes, that's one univention-config, which is completely independent of
> > xen(stored).
> > 
> > > It seems rather coincidental that it should be accessing the 
> > > same sort of address and be faulting.
> > 
> > Yes, good catch. I'll have another look at those core dumps.
> 
> With this in mind, please can you confirm what model of machines you've
> seen this on, and in particular whether they are all the same class of
> machine or whether they are significantly different.
> 
> The reason being that randomly placed 0xff values in a field of 0x00
> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong
> memory pages.

Thanks for giving me access to the core files. This is very suspicious:
(gdb) frame 2
#2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0 "/var/lib/xenstored/tdb.0x1935bb0", hash_size=<value optimized out>, tdb_flags=0, open_flags=<value optimized out>, mode=<value optimized out>, 
    log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at tdb.c:1958
1958		SAFE_FREE(tdb->locked);

(gdb) x/96x tdb
0x1921270:	0x00000000	0x00000000	0x00000000	0x00000000
0x1921280:	0x0000001f	0x000000ff	0x0000ff00	0x000000ff
0x1921290:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212a0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212b0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212c0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212d0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212e0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212f0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921300:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921310:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921320:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921330:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921340:	0x00000000	0x00000000	0x0000ff00	0x000000ff
0x1921350:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921360:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921370:	0x004093b0	0x00000000	0x004092f0	0x00000000
0x1921380:	0x00000002	0x00000000	0x00000091	0x00000000
0x1921390:	0x0193de70	0x00000000	0x01963600	0x00000000
0x19213a0:	0x00000000	0x00000000	0x0193fbb0	0x00000000
0x19213b0:	0x00000000	0x00000000	0x00000000	0x00000000
0x19213c0:	0x00405870	0x00000000	0x0040e3e0	0x00000000
0x19213d0:	0x00000038	0x00000000	0xe814ec70	0x6f2f6567
0x19213e0:	0x01963650	0x00000000	0x0193dec0	0x00000000

Something has clearly done a number on the ram of this process.
0x1921270 through 0x192136f is 256 bytes...

Since it appears to be happening to other processes too I would hazard
that this is not a xenstored issue.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 11:06:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 11:06:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0pxI-0003vA-QY; Tue, 16 Dec 2014 11:06: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 1Y0pxG-0003v5-V8
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 11:06:15 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	D4/24-22777-62210945; Tue, 16 Dec 2014 11:06:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418727972!13610953!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 27813 invoked from network); 16 Dec 2014 11:06:13 -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;
	16 Dec 2014 11:06:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,586,1413244800"; d="scan'208";a="205300607"
Message-ID: <1418727970.16425.217.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Tue, 16 Dec 2014 11:06:10 +0000
In-Reply-To: <1418726712.16425.213.camel@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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] 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 Tue, 2014-12-16 at 10:45 +0000, Ian Campbell wrote:
> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> > > I notice in your bugzilla (for a different occurrence, I think):
> > >> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
> > > 
> > > Which appears to have faulted access 0xff000000000 too. It looks like
> > > this process is a python thing, it's nothing to do with xenstored I
> > > assume?
> > 
> > Yes, that's one univention-config, which is completely independent of
> > xen(stored).
> > 
> > > It seems rather coincidental that it should be accessing the 
> > > same sort of address and be faulting.
> > 
> > Yes, good catch. I'll have another look at those core dumps.
> 
> With this in mind, please can you confirm what model of machines you've
> seen this on, and in particular whether they are all the same class of
> machine or whether they are significantly different.
> 
> The reason being that randomly placed 0xff values in a field of 0x00
> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong
> memory pages.

Thanks for giving me access to the core files. This is very suspicious:
(gdb) frame 2
#2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0 "/var/lib/xenstored/tdb.0x1935bb0", hash_size=<value optimized out>, tdb_flags=0, open_flags=<value optimized out>, mode=<value optimized out>, 
    log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at tdb.c:1958
1958		SAFE_FREE(tdb->locked);

(gdb) x/96x tdb
0x1921270:	0x00000000	0x00000000	0x00000000	0x00000000
0x1921280:	0x0000001f	0x000000ff	0x0000ff00	0x000000ff
0x1921290:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212a0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212b0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212c0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212d0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212e0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212f0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921300:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921310:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921320:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921330:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921340:	0x00000000	0x00000000	0x0000ff00	0x000000ff
0x1921350:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921360:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x1921370:	0x004093b0	0x00000000	0x004092f0	0x00000000
0x1921380:	0x00000002	0x00000000	0x00000091	0x00000000
0x1921390:	0x0193de70	0x00000000	0x01963600	0x00000000
0x19213a0:	0x00000000	0x00000000	0x0193fbb0	0x00000000
0x19213b0:	0x00000000	0x00000000	0x00000000	0x00000000
0x19213c0:	0x00405870	0x00000000	0x0040e3e0	0x00000000
0x19213d0:	0x00000038	0x00000000	0xe814ec70	0x6f2f6567
0x19213e0:	0x01963650	0x00000000	0x0193dec0	0x00000000

Something has clearly done a number on the ram of this process.
0x1921270 through 0x192136f is 256 bytes...

Since it appears to be happening to other processes too I would hazard
that this is not a xenstored issue.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 11:20:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 11:20:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0qAi-0004IO-EC; Tue, 16 Dec 2014 11:20: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 1Y0qAh-0004IG-Kj
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 11:20:07 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	38/0E-27785-76510945; Tue, 16 Dec 2014 11:20:07 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418728806!15384298!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 1245 invoked from network); 16 Dec 2014 11:20:06 -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; 16 Dec 2014 11:20:06 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 6FEB8AD71;
	Tue, 16 Dec 2014 11:20:05 +0000 (UTC)
Message-ID: <54901564.6070201@suse.com>
Date: Tue, 16 Dec 2014 12:20: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: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	x86@kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, tglx@linutronix.de, mingo@redhat.com, 
	hpa@zytor.com, mmarek@suse.cz, linux-kbuild@vger.kernel.org
References: <1418321065-10212-1-git-send-email-jgross@suse.com>	<1418321065-10212-5-git-send-email-jgross@suse.com>	<548ECE9B.3040105@citrix.com>
	<548FC95E.70903@suse.com> <5490086D.2060808@citrix.com>
In-Reply-To: <5490086D.2060808@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/4] xen: use generated hypercall symbols in
 arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/16/2014 11:24 AM, David Vrabel wrote:
> On 16/12/14 05:55, Juergen Gross wrote:
>> On 12/15/2014 01:05 PM, David Vrabel wrote:
>>> On 11/12/14 18:04, Juergen Gross wrote:
>>>> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
>>>> use the auto generated symbol list.
>>>>
>>>> This also corrects the wrong address of xen_hypercall_mca which was
>>>> located 32 bytes higher than it should.
>>>>
>>>> Symbol addresses have been verified to match the correct ones via
>>>> objdump output.
>>> [...]
>>>> +
>>>> +#define HYPERCALL(n) \
>>>> +    .equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \
>>>> +    .type xen_hypercall_##n, function; .size xen_hypercall_##n, 32
>>>> +#include <asm/xen-hypercalls.h>
>>>> +#undef HYPERCALL
>>>
>>> The gas manual[1] suggests the syntax you've used for .type is invalid
>>> and suggest using .type <name>, STT_FUNC
>>
>> Really? In the link below I see:
>>
>> The types supported are:
>>
>> STT_FUNC
>> function
>>      Mark the symbol as being a function name.
>> ...
>>
>> So "function" seems to be okay.
>
>>From the manual
>
>      The syntaxes supported are:
>
>         .type <name> STT_<TYPE_IN_UPPER_CASE>
>         .type <name>,#<type>
>         .type <name>,@<type>
>         .type <name>,%<type>
>         .type <name>,"<type>"
>
> And
>
>      The first variant will be accepted by the GNU assembler on all
>      architectures...

grepping through the x86 assembler sources

.type <name>,@function

seems to be the preferred syntax (100%). I think I'll switch to that.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 11:20:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 11:20:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0qAi-0004IO-EC; Tue, 16 Dec 2014 11:20: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 1Y0qAh-0004IG-Kj
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 11:20:07 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	38/0E-27785-76510945; Tue, 16 Dec 2014 11:20:07 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418728806!15384298!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 1245 invoked from network); 16 Dec 2014 11:20:06 -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; 16 Dec 2014 11:20:06 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 6FEB8AD71;
	Tue, 16 Dec 2014 11:20:05 +0000 (UTC)
Message-ID: <54901564.6070201@suse.com>
Date: Tue, 16 Dec 2014 12:20: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: David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org, 
	x86@kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, tglx@linutronix.de, mingo@redhat.com, 
	hpa@zytor.com, mmarek@suse.cz, linux-kbuild@vger.kernel.org
References: <1418321065-10212-1-git-send-email-jgross@suse.com>	<1418321065-10212-5-git-send-email-jgross@suse.com>	<548ECE9B.3040105@citrix.com>
	<548FC95E.70903@suse.com> <5490086D.2060808@citrix.com>
In-Reply-To: <5490086D.2060808@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/4] xen: use generated hypercall symbols in
 arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/16/2014 11:24 AM, David Vrabel wrote:
> On 16/12/14 05:55, Juergen Gross wrote:
>> On 12/15/2014 01:05 PM, David Vrabel wrote:
>>> On 11/12/14 18:04, Juergen Gross wrote:
>>>> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
>>>> use the auto generated symbol list.
>>>>
>>>> This also corrects the wrong address of xen_hypercall_mca which was
>>>> located 32 bytes higher than it should.
>>>>
>>>> Symbol addresses have been verified to match the correct ones via
>>>> objdump output.
>>> [...]
>>>> +
>>>> +#define HYPERCALL(n) \
>>>> +    .equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \
>>>> +    .type xen_hypercall_##n, function; .size xen_hypercall_##n, 32
>>>> +#include <asm/xen-hypercalls.h>
>>>> +#undef HYPERCALL
>>>
>>> The gas manual[1] suggests the syntax you've used for .type is invalid
>>> and suggest using .type <name>, STT_FUNC
>>
>> Really? In the link below I see:
>>
>> The types supported are:
>>
>> STT_FUNC
>> function
>>      Mark the symbol as being a function name.
>> ...
>>
>> So "function" seems to be okay.
>
>>From the manual
>
>      The syntaxes supported are:
>
>         .type <name> STT_<TYPE_IN_UPPER_CASE>
>         .type <name>,#<type>
>         .type <name>,@<type>
>         .type <name>,%<type>
>         .type <name>,"<type>"
>
> And
>
>      The first variant will be accepted by the GNU assembler on all
>      architectures...

grepping through the x86 assembler sources

.type <name>,@function

seems to be the preferred syntax (100%). I think I'll switch to that.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 11:31:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 11: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 1Y0qKj-0004co-IA; Tue, 16 Dec 2014 11:30:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <freddy77@gmail.com>) id 1Y0qKh-0004cj-I3
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 11:30:27 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	6A/9A-07724-2D710945; Tue, 16 Dec 2014 11:30:26 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418729425!13719675!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17424 invoked from network); 16 Dec 2014 11:30:26 -0000
Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com)
	(209.85.220.181)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 11:30:26 -0000
Received: by mail-vc0-f181.google.com with SMTP id le20so6271158vcb.26
	for <Xen-devel@lists.xen.org>; Tue, 16 Dec 2014 03:30: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;
	bh=/K3bLmcU5bEuQ4F4kI1jF5fgdKgCEyAXi+dCMeahJyY=;
	b=ILHX3I6ivs/yQ+06hlJ2TY1mn2iYoSuy6CZu45eT+lFfDBh+TQNtM0OfBUhO1WJSMZ
	frTpP/7g4d0E3uYSZoigLQB2UVSy1jph5wjaw2z1W12cO10schlAMF/ABTDVEK0cfZhK
	Whwq0b9LkfGUgGvK96CwHY6Y8rNB78DtJtnBsu/sg07xxM+Xyj6rf6/ef39AzMYdJZ/p
	Rgk0rXlkcW+ONCAa6MJjPvtfRS90gdDTM3107XTqN5OW497m9juAedfbQM/CWntDyWtC
	QKEKsYpo/nVG4ZIRyZaNUiBP0MOs3OIXEWn3grMo76ZJXusd4arr68k3naabO1hnwqdE
	1P1A==
MIME-Version: 1.0
X-Received: by 10.220.178.3 with SMTP id bk3mr15260954vcb.16.1418729424854;
	Tue, 16 Dec 2014 03:30:24 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Tue, 16 Dec 2014 03:30:24 -0800 (PST)
In-Reply-To: <1418727970.16425.217.camel@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
Date: Tue, 16 Dec 2014 11:30:24 +0000
Message-ID: <CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Xen-devel@lists.xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>
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

2014-12-16 11:06 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
> On Tue, 2014-12-16 at 10:45 +0000, Ian Campbell wrote:
>> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
>> > > I notice in your bugzilla (for a different occurrence, I think):
>> > >> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
>> > >
>> > > Which appears to have faulted access 0xff000000000 too. It looks like
>> > > this process is a python thing, it's nothing to do with xenstored I
>> > > assume?
>> >
>> > Yes, that's one univention-config, which is completely independent of
>> > xen(stored).
>> >
>> > > It seems rather coincidental that it should be accessing the
>> > > same sort of address and be faulting.
>> >
>> > Yes, good catch. I'll have another look at those core dumps.
>>
>> With this in mind, please can you confirm what model of machines you've
>> seen this on, and in particular whether they are all the same class of
>> machine or whether they are significantly different.
>>
>> The reason being that randomly placed 0xff values in a field of 0x00
>> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong
>> memory pages.
>
> Thanks for giving me access to the core files. This is very suspicious:
> (gdb) frame 2
> #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0 "/var/lib/xenstored/tdb.0x1935bb0", hash_size=<value optimized out>, tdb_flags=0, open_flags=<value optimized out>, mode=<value optimized out>,
>     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at tdb.c:1958
> 1958            SAFE_FREE(tdb->locked);
>
> (gdb) x/96x tdb
> 0x1921270:      0x00000000      0x00000000      0x00000000      0x00000000
> 0x1921280:      0x0000001f      0x000000ff      0x0000ff00      0x000000ff
> 0x1921290:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212a0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212b0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212c0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212d0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212e0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212f0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921300:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921310:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921320:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921330:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921340:      0x00000000      0x00000000      0x0000ff00      0x000000ff
> 0x1921350:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921360:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921370:      0x004093b0      0x00000000      0x004092f0      0x00000000
> 0x1921380:      0x00000002      0x00000000      0x00000091      0x00000000
> 0x1921390:      0x0193de70      0x00000000      0x01963600      0x00000000
> 0x19213a0:      0x00000000      0x00000000      0x0193fbb0      0x00000000
> 0x19213b0:      0x00000000      0x00000000      0x00000000      0x00000000
> 0x19213c0:      0x00405870      0x00000000      0x0040e3e0      0x00000000
> 0x19213d0:      0x00000038      0x00000000      0xe814ec70      0x6f2f6567
> 0x19213e0:      0x01963650      0x00000000      0x0193dec0      0x00000000
>
> Something has clearly done a number on the ram of this process.
> 0x1921270 through 0x192136f is 256 bytes...
>
> Since it appears to be happening to other processes too I would hazard
> that this is not a xenstored issue.
>
> Ian.
>

Good catch Ian!

Strange corruption. Probably not related to xenstored as you
suggested. I would be curious to see what's before the tdb pointer and
where does the corruption starts. I also don't understand where the
"fd = 47" came from a previous mail. 0x1f is 31, not 47 (which is
0x2f).

I would not be surprised about a strange bug in libc or the kernel.

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 11:31:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 11: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 1Y0qKj-0004co-IA; Tue, 16 Dec 2014 11:30:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <freddy77@gmail.com>) id 1Y0qKh-0004cj-I3
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 11:30:27 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	6A/9A-07724-2D710945; Tue, 16 Dec 2014 11:30:26 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418729425!13719675!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17424 invoked from network); 16 Dec 2014 11:30:26 -0000
Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com)
	(209.85.220.181)
	by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 11:30:26 -0000
Received: by mail-vc0-f181.google.com with SMTP id le20so6271158vcb.26
	for <Xen-devel@lists.xen.org>; Tue, 16 Dec 2014 03:30: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;
	bh=/K3bLmcU5bEuQ4F4kI1jF5fgdKgCEyAXi+dCMeahJyY=;
	b=ILHX3I6ivs/yQ+06hlJ2TY1mn2iYoSuy6CZu45eT+lFfDBh+TQNtM0OfBUhO1WJSMZ
	frTpP/7g4d0E3uYSZoigLQB2UVSy1jph5wjaw2z1W12cO10schlAMF/ABTDVEK0cfZhK
	Whwq0b9LkfGUgGvK96CwHY6Y8rNB78DtJtnBsu/sg07xxM+Xyj6rf6/ef39AzMYdJZ/p
	Rgk0rXlkcW+ONCAa6MJjPvtfRS90gdDTM3107XTqN5OW497m9juAedfbQM/CWntDyWtC
	QKEKsYpo/nVG4ZIRyZaNUiBP0MOs3OIXEWn3grMo76ZJXusd4arr68k3naabO1hnwqdE
	1P1A==
MIME-Version: 1.0
X-Received: by 10.220.178.3 with SMTP id bk3mr15260954vcb.16.1418729424854;
	Tue, 16 Dec 2014 03:30:24 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Tue, 16 Dec 2014 03:30:24 -0800 (PST)
In-Reply-To: <1418727970.16425.217.camel@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
Date: Tue, 16 Dec 2014 11:30:24 +0000
Message-ID: <CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Xen-devel@lists.xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>
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

2014-12-16 11:06 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
> On Tue, 2014-12-16 at 10:45 +0000, Ian Campbell wrote:
>> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
>> > > I notice in your bugzilla (for a different occurrence, I think):
>> > >> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
>> > >
>> > > Which appears to have faulted access 0xff000000000 too. It looks like
>> > > this process is a python thing, it's nothing to do with xenstored I
>> > > assume?
>> >
>> > Yes, that's one univention-config, which is completely independent of
>> > xen(stored).
>> >
>> > > It seems rather coincidental that it should be accessing the
>> > > same sort of address and be faulting.
>> >
>> > Yes, good catch. I'll have another look at those core dumps.
>>
>> With this in mind, please can you confirm what model of machines you've
>> seen this on, and in particular whether they are all the same class of
>> machine or whether they are significantly different.
>>
>> The reason being that randomly placed 0xff values in a field of 0x00
>> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong
>> memory pages.
>
> Thanks for giving me access to the core files. This is very suspicious:
> (gdb) frame 2
> #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0 "/var/lib/xenstored/tdb.0x1935bb0", hash_size=<value optimized out>, tdb_flags=0, open_flags=<value optimized out>, mode=<value optimized out>,
>     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at tdb.c:1958
> 1958            SAFE_FREE(tdb->locked);
>
> (gdb) x/96x tdb
> 0x1921270:      0x00000000      0x00000000      0x00000000      0x00000000
> 0x1921280:      0x0000001f      0x000000ff      0x0000ff00      0x000000ff
> 0x1921290:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212a0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212b0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212c0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212d0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212e0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212f0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921300:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921310:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921320:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921330:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921340:      0x00000000      0x00000000      0x0000ff00      0x000000ff
> 0x1921350:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921360:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x1921370:      0x004093b0      0x00000000      0x004092f0      0x00000000
> 0x1921380:      0x00000002      0x00000000      0x00000091      0x00000000
> 0x1921390:      0x0193de70      0x00000000      0x01963600      0x00000000
> 0x19213a0:      0x00000000      0x00000000      0x0193fbb0      0x00000000
> 0x19213b0:      0x00000000      0x00000000      0x00000000      0x00000000
> 0x19213c0:      0x00405870      0x00000000      0x0040e3e0      0x00000000
> 0x19213d0:      0x00000038      0x00000000      0xe814ec70      0x6f2f6567
> 0x19213e0:      0x01963650      0x00000000      0x0193dec0      0x00000000
>
> Something has clearly done a number on the ram of this process.
> 0x1921270 through 0x192136f is 256 bytes...
>
> Since it appears to be happening to other processes too I would hazard
> that this is not a xenstored issue.
>
> Ian.
>

Good catch Ian!

Strange corruption. Probably not related to xenstored as you
suggested. I would be curious to see what's before the tdb pointer and
where does the corruption starts. I also don't understand where the
"fd = 47" came from a previous mail. 0x1f is 31, not 47 (which is
0x2f).

I would not be surprised about a strange bug in libc or the kernel.

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 11:32:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 11: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 1Y0qMt-0004p2-3a; Tue, 16 Dec 2014 11:32:43 +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 1Y0qMq-0004ow-Rv
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 11:32:41 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	74/3E-28296-85810945; Tue, 16 Dec 2014 11:32:40 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418729558!13638680!1
X-Originating-IP: [66.165.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 9843 invoked from network); 16 Dec 2014 11:32:39 -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;
	16 Dec 2014 11:32:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,586,1413244800"; d="scan'208";a="204846054"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 16 Dec 2014 06:32:36 -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 1Y0qMl-0004Xa-Nd;
	Tue, 16 Dec 2014 11:32:35 +0000
Date: Tue, 16 Dec 2014 11:32:35 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141216113235.GB1705@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
	<20141215170757.GA1705@perard.uk.xensource.com>
	<1418722228.16425.179.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418722228.16425.179.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 09:30:28AM +0000, Ian Campbell wrote:
> On Mon, 2014-12-15 at 17:07 +0000, Anthony PERARD wrote:
> > On Thu, Dec 11, 2014 at 04:23:15PM +0000, Ian Campbell wrote:
> > > On Thu, 2014-12-11 at 16:16 +0000, Anthony PERARD wrote:
> > > > On Tue, Dec 09, 2014 at 03:56:02PM +0000, Ian Campbell wrote:
> > > > > On Tue, 2014-12-09 at 15:39 +0000, Anthony PERARD wrote:
> > > > > > The path to the pty of a Xen PV console is set only in
> > > > > > virDomainOpenConsole. But this is done too late. A call to
> > > > > > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > > > > > the pty, but a call after OpenConsole will.
> > > > > > 
> > > > > > e.g. of the current issue.
> > > > > > Starting a domain with '<console type="pty"/>'
> > > > > > Then:
> > > > > > virDomainGetXMLDesc():
> > > > > >   <devices>
> > > > > >     <console type='pty'>
> > > > > >       <target type='xen' port='0'/>
> > > > > >     </console>
> > > > > >   </devices>
> > > > > > virDomainOpenConsole()
> > > > > > virDomainGetXMLDesc():
> > > > > >   <devices>
> > > > > >     <console type='pty' tty='/dev/pts/30'>
> > > > > >       <source path='/dev/pts/30'/>
> > > > > >       <target type='xen' port='0'/>
> > > > > >     </console>
> > > > > >   </devices>
> > > > > > 
> > > > > > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > > > > > This is done by setting up the path at domain start up instead of in
> > > > > > OpenConsole.
> > > > > > 
> > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > > > > > 
> > > > > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > > > > > 
> > > > > > ---
> > > > > > Change in V2:
> > > > > >   Adding bug report link.
> > > > > >   Reword the last part of the patch description.
> > > > > >   Cleanup the code.
> > > > > >   Use VIR_FREE before VIR_STRDUP.
> > > > > >   Remove the code from OpenConsole as it is now a duplicate.
> > > > > > ---
> > > > > >  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
> > > > > >  src/libxl/libxl_driver.c | 15 ---------------
> > > > > >  2 files changed, 20 insertions(+), 15 deletions(-)
> > > > > > 
> > > > > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > > > > index 9c62291..325de79 100644
> > > > > > --- a/src/libxl/libxl_domain.c
> > > > > > +++ b/src/libxl/libxl_domain.c
> > > > > > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> > > > > >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > > > > >          goto cleanup_dom;
> > > > > >  
> > > > > > +    if (vm->def->nconsoles) {
> > > > > > +        virDomainChrDefPtr chr = vm->def->consoles[0];
> > > > > 
> > > > > Given vm->def->nconsoles should we loop and do them all?
> > > > 
> > > > Maybe. libvirt it self will not be able to access any console that is
> > > > not the first one (virDomainOpenConsole only provide access to console
> > > > 0), but a consumer of libvirt could.
> > > > 
> > > > > Also, and I really should know the answer to this (and sorry for not
> > > > > thinking of it earlier), but:
> > > > > 
> > > > > > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > > > > > +                                        chr->target.port, console_type,
> > > > > > +                                        &console);
> > > > > 
> > > > > Might this race against xenconsoled writing the node to xenstore and
> > > > > therefore be prone to failing when starting multiple guests all at once?
> > > > 
> > > > I've look through out libxl, xenconsoled and libvirt, and I could not
> > > > find any synchronisation point. So I guest it's possible.
> > > > 
> > > > > Is there a hook which is called on virsh dumpxml which could update
> > > > > things on the fly (i.e. lookup the console iff it isn't already set)?
> > > > 
> > > > I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
> > > > to do the check, or having a xenstore watch on the path (if that is
> > > > possible).
> > > 
> > > The aop_console_how option to libxl_domain_create_new and
> > > libxl_domain_create_restore is documented as:
> > > 
> > >   /* A progress report will be made via ao_console_how, of type
> > >    * domain_create_console_available, when the domain's primary
> > >    * console is available and can be connected to.
> > >    */
> > > 
> > > Which sounds like exactly what is needed?
> > 
> > It looks like the progress is reported before the main function finish,
> > from the description of the type libxl_asyncprogress_how (in libxl.h).
> 
> Correct.
> 
> > Also, I tryied to use it, it works if xenconsoled is running. But if
> > xenconsoled is not running, then the callback is also called and
> > libxl_console_get_tty() return an empty string.
> 
> I'm not sure xenconsoled not running is a configuration we need to worry
> about, or at least it could be expected not to get a console in that
> case.
> 
> Unless by "not running" you meant bottlenecked or not keeping up
> perhaps.

Well, I did meant no xenconsoled process. But after, I also tried `kill
-STOP`, but the same things is happening.

> > Or, maybe my test case is not relevant, so another question: Will
> > libxl wait for xenconsoled to process the new domain before calling the
> > callback?
> 
> I don't see an explicit wait in the code, but I don't know if it has
> arranged the sequencing some other way.
> 
> > Or, should I set the callback to NULL and have the
> > domain_create_console_available event sent through
> > the callback set by libxl_event_register_callbacks()?
> 
> That would make sense, except I don't see libxl_evdisable_foo for these
> events, so I'm not sure it is possible.

Well, the domain_create_console_available event is report by
libxl__ao_progress_report which will either callback() or call
libxl__event_occurred(). So does not seams better to set callback to
NULL.

So, from this, I think I'm going to stick with the original patch and
add some hooks in GetXMLDesc and OpenConsole.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 11:32:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 11: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 1Y0qMt-0004p2-3a; Tue, 16 Dec 2014 11:32:43 +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 1Y0qMq-0004ow-Rv
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 11:32:41 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	74/3E-28296-85810945; Tue, 16 Dec 2014 11:32:40 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418729558!13638680!1
X-Originating-IP: [66.165.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 9843 invoked from network); 16 Dec 2014 11:32:39 -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;
	16 Dec 2014 11:32:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,586,1413244800"; d="scan'208";a="204846054"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 16 Dec 2014 06:32:36 -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 1Y0qMl-0004Xa-Nd;
	Tue, 16 Dec 2014 11:32:35 +0000
Date: Tue, 16 Dec 2014 11:32:35 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141216113235.GB1705@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
	<20141215170757.GA1705@perard.uk.xensource.com>
	<1418722228.16425.179.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418722228.16425.179.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 09:30:28AM +0000, Ian Campbell wrote:
> On Mon, 2014-12-15 at 17:07 +0000, Anthony PERARD wrote:
> > On Thu, Dec 11, 2014 at 04:23:15PM +0000, Ian Campbell wrote:
> > > On Thu, 2014-12-11 at 16:16 +0000, Anthony PERARD wrote:
> > > > On Tue, Dec 09, 2014 at 03:56:02PM +0000, Ian Campbell wrote:
> > > > > On Tue, 2014-12-09 at 15:39 +0000, Anthony PERARD wrote:
> > > > > > The path to the pty of a Xen PV console is set only in
> > > > > > virDomainOpenConsole. But this is done too late. A call to
> > > > > > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > > > > > the pty, but a call after OpenConsole will.
> > > > > > 
> > > > > > e.g. of the current issue.
> > > > > > Starting a domain with '<console type="pty"/>'
> > > > > > Then:
> > > > > > virDomainGetXMLDesc():
> > > > > >   <devices>
> > > > > >     <console type='pty'>
> > > > > >       <target type='xen' port='0'/>
> > > > > >     </console>
> > > > > >   </devices>
> > > > > > virDomainOpenConsole()
> > > > > > virDomainGetXMLDesc():
> > > > > >   <devices>
> > > > > >     <console type='pty' tty='/dev/pts/30'>
> > > > > >       <source path='/dev/pts/30'/>
> > > > > >       <target type='xen' port='0'/>
> > > > > >     </console>
> > > > > >   </devices>
> > > > > > 
> > > > > > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > > > > > This is done by setting up the path at domain start up instead of in
> > > > > > OpenConsole.
> > > > > > 
> > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > > > > > 
> > > > > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > > > > > 
> > > > > > ---
> > > > > > Change in V2:
> > > > > >   Adding bug report link.
> > > > > >   Reword the last part of the patch description.
> > > > > >   Cleanup the code.
> > > > > >   Use VIR_FREE before VIR_STRDUP.
> > > > > >   Remove the code from OpenConsole as it is now a duplicate.
> > > > > > ---
> > > > > >  src/libxl/libxl_domain.c | 20 ++++++++++++++++++++
> > > > > >  src/libxl/libxl_driver.c | 15 ---------------
> > > > > >  2 files changed, 20 insertions(+), 15 deletions(-)
> > > > > > 
> > > > > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > > > > index 9c62291..325de79 100644
> > > > > > --- a/src/libxl/libxl_domain.c
> > > > > > +++ b/src/libxl/libxl_domain.c
> > > > > > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
> > > > > >      if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > > > > >          goto cleanup_dom;
> > > > > >  
> > > > > > +    if (vm->def->nconsoles) {
> > > > > > +        virDomainChrDefPtr chr = vm->def->consoles[0];
> > > > > 
> > > > > Given vm->def->nconsoles should we loop and do them all?
> > > > 
> > > > Maybe. libvirt it self will not be able to access any console that is
> > > > not the first one (virDomainOpenConsole only provide access to console
> > > > 0), but a consumer of libvirt could.
> > > > 
> > > > > Also, and I really should know the answer to this (and sorry for not
> > > > > thinking of it earlier), but:
> > > > > 
> > > > > > +            ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > > > > > +                                        chr->target.port, console_type,
> > > > > > +                                        &console);
> > > > > 
> > > > > Might this race against xenconsoled writing the node to xenstore and
> > > > > therefore be prone to failing when starting multiple guests all at once?
> > > > 
> > > > I've look through out libxl, xenconsoled and libvirt, and I could not
> > > > find any synchronisation point. So I guest it's possible.
> > > > 
> > > > > Is there a hook which is called on virsh dumpxml which could update
> > > > > things on the fly (i.e. lookup the console iff it isn't already set)?
> > > > 
> > > > I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
> > > > to do the check, or having a xenstore watch on the path (if that is
> > > > possible).
> > > 
> > > The aop_console_how option to libxl_domain_create_new and
> > > libxl_domain_create_restore is documented as:
> > > 
> > >   /* A progress report will be made via ao_console_how, of type
> > >    * domain_create_console_available, when the domain's primary
> > >    * console is available and can be connected to.
> > >    */
> > > 
> > > Which sounds like exactly what is needed?
> > 
> > It looks like the progress is reported before the main function finish,
> > from the description of the type libxl_asyncprogress_how (in libxl.h).
> 
> Correct.
> 
> > Also, I tryied to use it, it works if xenconsoled is running. But if
> > xenconsoled is not running, then the callback is also called and
> > libxl_console_get_tty() return an empty string.
> 
> I'm not sure xenconsoled not running is a configuration we need to worry
> about, or at least it could be expected not to get a console in that
> case.
> 
> Unless by "not running" you meant bottlenecked or not keeping up
> perhaps.

Well, I did meant no xenconsoled process. But after, I also tried `kill
-STOP`, but the same things is happening.

> > Or, maybe my test case is not relevant, so another question: Will
> > libxl wait for xenconsoled to process the new domain before calling the
> > callback?
> 
> I don't see an explicit wait in the code, but I don't know if it has
> arranged the sequencing some other way.
> 
> > Or, should I set the callback to NULL and have the
> > domain_create_console_available event sent through
> > the callback set by libxl_event_register_callbacks()?
> 
> That would make sense, except I don't see libxl_evdisable_foo for these
> events, so I'm not sure it is possible.

Well, the domain_create_console_available event is report by
libxl__ao_progress_report which will either callback() or call
libxl__event_occurred(). So does not seams better to set callback to
NULL.

So, from this, I think I'm going to stick with the original patch and
add some hooks in GetXMLDesc and OpenConsole.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 12:04:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 12: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 1Y0qrR-0005wP-Sx; Tue, 16 Dec 2014 12:04:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1Y0qrQ-0005wJ-Qc
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 12:04:16 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	D1/71-03145-0CF10945; Tue, 16 Dec 2014 12:04:16 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418731455!15339868!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7051 invoked from network); 16 Dec 2014 12:04:15 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 12:04:15 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id 856AC1101B1D;
	Tue, 16 Dec 2014 13:04:14 +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 fgoVZrk-vbef; Tue, 16 Dec 2014 13:04:14 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id F01B11101ADD;
	Tue, 16 Dec 2014 13:04:13 +0100 (CET)
Message-ID: <54901FBD.3090706@univention.de>
Date: Tue, 16 Dec 2014 13:04:13 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>		
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>		
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>		
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>		
	<1418407116.16425.53.camel@citrix.com>		
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>		
	<1418655014.16425.138.camel@citrix.com>	
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
In-Reply-To: <1418726712.16425.213.camel@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Frediano Ziglio <freddy77@gmail.com>, 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

Hello,

On 16.12.2014 11:45, Ian Campbell wrote:
> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
>>> I notice in your bugzilla (for a different occurrence, I think):
>>>> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
>>>
>>> Which appears to have faulted access 0xff000000000 too. It looks like
>>> this process is a python thing, it's nothing to do with xenstored I
>>> assume?
>>
>> Yes, that's one univention-config, which is completely independent of
>> xen(stored).
>>
>>> It seems rather coincidental that it should be accessing the 
>>> same sort of address and be faulting.
>>
>> Yes, good catch. I'll have another look at those core dumps.
> 
> With this in mind, please can you confirm what model of machines you've
> seen this on, and in particular whether they are all the same class of
> machine or whether they are significantly different.

They are all from the same vendor, but I have to check the individual
models and firmware versions, which might take some time.

> The reason being that randomly placed 0xff values in a field of 0x00
> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong
> memory pages.

Good catch: that would explain why it only happens for us and no one
other has seen that strange bug before.

Thanks you again.
Philipp Hahn


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 12:04:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 12: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 1Y0qrR-0005wP-Sx; Tue, 16 Dec 2014 12:04:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1Y0qrQ-0005wJ-Qc
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 12:04:16 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	D1/71-03145-0CF10945; Tue, 16 Dec 2014 12:04:16 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418731455!15339868!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7051 invoked from network); 16 Dec 2014 12:04:15 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 12:04:15 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id 856AC1101B1D;
	Tue, 16 Dec 2014 13:04:14 +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 fgoVZrk-vbef; Tue, 16 Dec 2014 13:04:14 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id F01B11101ADD;
	Tue, 16 Dec 2014 13:04:13 +0100 (CET)
Message-ID: <54901FBD.3090706@univention.de>
Date: Tue, 16 Dec 2014 13:04:13 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>		
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>		
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>		
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>		
	<1418407116.16425.53.camel@citrix.com>		
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>		
	<1418655014.16425.138.camel@citrix.com>	
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
In-Reply-To: <1418726712.16425.213.camel@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Frediano Ziglio <freddy77@gmail.com>, 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

Hello,

On 16.12.2014 11:45, Ian Campbell wrote:
> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
>>> I notice in your bugzilla (for a different occurrence, I think):
>>>> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
>>>
>>> Which appears to have faulted access 0xff000000000 too. It looks like
>>> this process is a python thing, it's nothing to do with xenstored I
>>> assume?
>>
>> Yes, that's one univention-config, which is completely independent of
>> xen(stored).
>>
>>> It seems rather coincidental that it should be accessing the 
>>> same sort of address and be faulting.
>>
>> Yes, good catch. I'll have another look at those core dumps.
> 
> With this in mind, please can you confirm what model of machines you've
> seen this on, and in particular whether they are all the same class of
> machine or whether they are significantly different.

They are all from the same vendor, but I have to check the individual
models and firmware versions, which might take some time.

> The reason being that randomly placed 0xff values in a field of 0x00
> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong
> memory pages.

Good catch: that would explain why it only happens for us and no one
other has seen that strange bug before.

Thanks you again.
Philipp Hahn


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 12:24:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 12: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 1Y0rAY-0006UV-Of; Tue, 16 Dec 2014 12:24: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 1Y0rAX-0006UQ-47
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 12:24:01 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	45/51-22737-06420945; Tue, 16 Dec 2014 12:24:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418732637!10260080!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 20549 invoked from network); 16 Dec 2014 12:23:58 -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;
	16 Dec 2014 12:23:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,586,1413244800"; d="scan'208";a="205322216"
Message-ID: <1418732635.16425.221.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <freddy77@gmail.com>
Date: Tue, 16 Dec 2014 12:23:55 +0000
In-Reply-To: <CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Xen-devel@lists.xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>
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 Tue, 2014-12-16 at 11:30 +0000, Frediano Ziglio wrote:
> 2014-12-16 11:06 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
> > On Tue, 2014-12-16 at 10:45 +0000, Ian Campbell wrote:
> >> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> >> > > I notice in your bugzilla (for a different occurrence, I think):
> >> > >> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
> >> > >
> >> > > Which appears to have faulted access 0xff000000000 too. It looks like
> >> > > this process is a python thing, it's nothing to do with xenstored I
> >> > > assume?
> >> >
> >> > Yes, that's one univention-config, which is completely independent of
> >> > xen(stored).
> >> >
> >> > > It seems rather coincidental that it should be accessing the
> >> > > same sort of address and be faulting.
> >> >
> >> > Yes, good catch. I'll have another look at those core dumps.
> >>
> >> With this in mind, please can you confirm what model of machines you've
> >> seen this on, and in particular whether they are all the same class of
> >> machine or whether they are significantly different.
> >>
> >> The reason being that randomly placed 0xff values in a field of 0x00
> >> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong
> >> memory pages.
> >
> > Thanks for giving me access to the core files. This is very suspicious:
> > (gdb) frame 2
> > #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0 "/var/lib/xenstored/tdb.0x1935bb0", hash_size=<value optimized out>, tdb_flags=0, open_flags=<value optimized out>, mode=<value optimized out>,
> >     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at tdb.c:1958
> > 1958            SAFE_FREE(tdb->locked);
> >
> > (gdb) x/96x tdb
> > 0x1921270:      0x00000000      0x00000000      0x00000000      0x00000000
> > 0x1921280:      0x0000001f      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921290:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x19212a0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x19212b0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x19212c0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x19212d0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x19212e0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x19212f0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921300:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921310:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921320:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921330:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921340:      0x00000000      0x00000000      0x0000ff00      0x000000ff
> > 0x1921350:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921360:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921370:      0x004093b0      0x00000000      0x004092f0      0x00000000
> > 0x1921380:      0x00000002      0x00000000      0x00000091      0x00000000
> > 0x1921390:      0x0193de70      0x00000000      0x01963600      0x00000000
> > 0x19213a0:      0x00000000      0x00000000      0x0193fbb0      0x00000000
> > 0x19213b0:      0x00000000      0x00000000      0x00000000      0x00000000
> > 0x19213c0:      0x00405870      0x00000000      0x0040e3e0      0x00000000
> > 0x19213d0:      0x00000038      0x00000000      0xe814ec70      0x6f2f6567
> > 0x19213e0:      0x01963650      0x00000000      0x0193dec0      0x00000000
> >
> > Something has clearly done a number on the ram of this process.
> > 0x1921270 through 0x192136f is 256 bytes...
> >
> > Since it appears to be happening to other processes too I would hazard
> > that this is not a xenstored issue.
> >
> > Ian.
> >
> 
> Good catch Ian!
> 
> Strange corruption. Probably not related to xenstored as you
> suggested. I would be curious to see what's before the tdb pointer and
> where does the corruption starts.

(gdb) print tdb
$2 = (TDB_CONTEXT *) 0x1921270
(gdb) x/64x 0x1921200
0x1921200:	0x01921174	0x00000000	0x00000000	0x00000000
0x1921210:	0x01921174	0x00000000	0x00000171	0x00000000
0x1921220:	0x00000000	0x00000000	0x00000000	0x00000000
0x1921230:	0x01941f60	0x00000000	0x00000000	0x00000000
0x1921240:	0x00000000	0x00000000	0x00000000	0x6f630065
0x1921250:	0x00000000	0x00000000	0x0040e8a7	0x00000000
0x1921260:	0x00000118	0x00000000	0xe814ec70	0x00000000
0x1921270:	0x00000000	0x00000000	0x00000000	0x00000000
0x1921280:	0x0000001f	0x000000ff	0x0000ff00	0x000000ff
0x1921290:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212a0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212b0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212c0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212d0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212e0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212f0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff

So it appears to start at 0x1921270 or maybe ...6c.

>  I also don't understand where the
> "fd = 47" came from a previous mail. 0x1f is 31, not 47 (which is
> 0x2f).

I must have been using a different coredump to the origianl report
(there are several). 

In the one which corresponds to the above:

(gdb) print *tdb
$3 = {name = 0x0, map_ptr = 0x0, fd = 31, map_size = 255, 
  read_only = 65280, locked = 0xff00000000, ecode = 65280, header = {
    magic_food = "\377\000\000\000\000\000\000\000\377\000\000\000\000\377\000\000\377\000\000\000\000\000\000\000\377\000\000\000\000\377\000", version = 255, hash_size = 0, rwlocks = 255, reserved = {65280, 
      255, 0, 255, 65280, 255, 0, 255, 65280, 255, 0, 255, 65280, 
      255, 0, 255, 65280, 255, 0, 255, 65280, 255, 0, 255, 65280, 
      255, 0, 255, 65280, 255, 0}}, flags = 0, travlocks = {
    next = 0xff0000ff00, off = 0, hash = 255}, next = 0xff0000ff00, 
  device = 1095216660480, inode = 1095216725760, 
  log_fn = 0x4093b0 <null_log_fn>, 
  hash_fn = 0x4092f0 <default_tdb_hash>, open_flags = 2}
(gdb) print/x *tdb
$4 = {name = 0x0, map_ptr = 0x0, fd = 0x1f, map_size = 0xff, 
  read_only = 0xff00, locked = 0xff00000000, ecode = 0xff00, 
  header = {magic_food = {0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
      0xff, 0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0, 
      0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0}, 
    version = 0xff, hash_size = 0x0, rwlocks = 0xff, reserved = {
      0xff00, 0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 0xff, 0xff00, 
      0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 
      0xff, 0xff00, 0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 0xff, 
      0xff00, 0xff, 0x0}}, flags = 0x0, travlocks = {
    next = 0xff0000ff00, off = 0x0, hash = 0xff}, 
  next = 0xff0000ff00, device = 0xff00000000, inode = 0xff0000ff00, 
  log_fn = 0x4093b0, hash_fn = 0x4092f0, open_flags = 0x2}

which is consistent.

> I would not be surprised about a strange bug in libc or the kernel.

Or even Xen itself, or the h/w.

Ian,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 12:24:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 12: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 1Y0rAY-0006UV-Of; Tue, 16 Dec 2014 12:24: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 1Y0rAX-0006UQ-47
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 12:24:01 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	45/51-22737-06420945; Tue, 16 Dec 2014 12:24:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418732637!10260080!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 20549 invoked from network); 16 Dec 2014 12:23:58 -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;
	16 Dec 2014 12:23:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,586,1413244800"; d="scan'208";a="205322216"
Message-ID: <1418732635.16425.221.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <freddy77@gmail.com>
Date: Tue, 16 Dec 2014 12:23:55 +0000
In-Reply-To: <CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Xen-devel@lists.xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>
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 Tue, 2014-12-16 at 11:30 +0000, Frediano Ziglio wrote:
> 2014-12-16 11:06 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
> > On Tue, 2014-12-16 at 10:45 +0000, Ian Campbell wrote:
> >> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> >> > > I notice in your bugzilla (for a different occurrence, I think):
> >> > >> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
> >> > >
> >> > > Which appears to have faulted access 0xff000000000 too. It looks like
> >> > > this process is a python thing, it's nothing to do with xenstored I
> >> > > assume?
> >> >
> >> > Yes, that's one univention-config, which is completely independent of
> >> > xen(stored).
> >> >
> >> > > It seems rather coincidental that it should be accessing the
> >> > > same sort of address and be faulting.
> >> >
> >> > Yes, good catch. I'll have another look at those core dumps.
> >>
> >> With this in mind, please can you confirm what model of machines you've
> >> seen this on, and in particular whether they are all the same class of
> >> machine or whether they are significantly different.
> >>
> >> The reason being that randomly placed 0xff values in a field of 0x00
> >> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong
> >> memory pages.
> >
> > Thanks for giving me access to the core files. This is very suspicious:
> > (gdb) frame 2
> > #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0 "/var/lib/xenstored/tdb.0x1935bb0", hash_size=<value optimized out>, tdb_flags=0, open_flags=<value optimized out>, mode=<value optimized out>,
> >     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at tdb.c:1958
> > 1958            SAFE_FREE(tdb->locked);
> >
> > (gdb) x/96x tdb
> > 0x1921270:      0x00000000      0x00000000      0x00000000      0x00000000
> > 0x1921280:      0x0000001f      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921290:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x19212a0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x19212b0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x19212c0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x19212d0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x19212e0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x19212f0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921300:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921310:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921320:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921330:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921340:      0x00000000      0x00000000      0x0000ff00      0x000000ff
> > 0x1921350:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921360:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> > 0x1921370:      0x004093b0      0x00000000      0x004092f0      0x00000000
> > 0x1921380:      0x00000002      0x00000000      0x00000091      0x00000000
> > 0x1921390:      0x0193de70      0x00000000      0x01963600      0x00000000
> > 0x19213a0:      0x00000000      0x00000000      0x0193fbb0      0x00000000
> > 0x19213b0:      0x00000000      0x00000000      0x00000000      0x00000000
> > 0x19213c0:      0x00405870      0x00000000      0x0040e3e0      0x00000000
> > 0x19213d0:      0x00000038      0x00000000      0xe814ec70      0x6f2f6567
> > 0x19213e0:      0x01963650      0x00000000      0x0193dec0      0x00000000
> >
> > Something has clearly done a number on the ram of this process.
> > 0x1921270 through 0x192136f is 256 bytes...
> >
> > Since it appears to be happening to other processes too I would hazard
> > that this is not a xenstored issue.
> >
> > Ian.
> >
> 
> Good catch Ian!
> 
> Strange corruption. Probably not related to xenstored as you
> suggested. I would be curious to see what's before the tdb pointer and
> where does the corruption starts.

(gdb) print tdb
$2 = (TDB_CONTEXT *) 0x1921270
(gdb) x/64x 0x1921200
0x1921200:	0x01921174	0x00000000	0x00000000	0x00000000
0x1921210:	0x01921174	0x00000000	0x00000171	0x00000000
0x1921220:	0x00000000	0x00000000	0x00000000	0x00000000
0x1921230:	0x01941f60	0x00000000	0x00000000	0x00000000
0x1921240:	0x00000000	0x00000000	0x00000000	0x6f630065
0x1921250:	0x00000000	0x00000000	0x0040e8a7	0x00000000
0x1921260:	0x00000118	0x00000000	0xe814ec70	0x00000000
0x1921270:	0x00000000	0x00000000	0x00000000	0x00000000
0x1921280:	0x0000001f	0x000000ff	0x0000ff00	0x000000ff
0x1921290:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212a0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212b0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212c0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212d0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212e0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff
0x19212f0:	0x00000000	0x000000ff	0x0000ff00	0x000000ff

So it appears to start at 0x1921270 or maybe ...6c.

>  I also don't understand where the
> "fd = 47" came from a previous mail. 0x1f is 31, not 47 (which is
> 0x2f).

I must have been using a different coredump to the origianl report
(there are several). 

In the one which corresponds to the above:

(gdb) print *tdb
$3 = {name = 0x0, map_ptr = 0x0, fd = 31, map_size = 255, 
  read_only = 65280, locked = 0xff00000000, ecode = 65280, header = {
    magic_food = "\377\000\000\000\000\000\000\000\377\000\000\000\000\377\000\000\377\000\000\000\000\000\000\000\377\000\000\000\000\377\000", version = 255, hash_size = 0, rwlocks = 255, reserved = {65280, 
      255, 0, 255, 65280, 255, 0, 255, 65280, 255, 0, 255, 65280, 
      255, 0, 255, 65280, 255, 0, 255, 65280, 255, 0, 255, 65280, 
      255, 0, 255, 65280, 255, 0}}, flags = 0, travlocks = {
    next = 0xff0000ff00, off = 0, hash = 255}, next = 0xff0000ff00, 
  device = 1095216660480, inode = 1095216725760, 
  log_fn = 0x4093b0 <null_log_fn>, 
  hash_fn = 0x4092f0 <default_tdb_hash>, open_flags = 2}
(gdb) print/x *tdb
$4 = {name = 0x0, map_ptr = 0x0, fd = 0x1f, map_size = 0xff, 
  read_only = 0xff00, locked = 0xff00000000, ecode = 0xff00, 
  header = {magic_food = {0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
      0xff, 0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0, 
      0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0}, 
    version = 0xff, hash_size = 0x0, rwlocks = 0xff, reserved = {
      0xff00, 0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 0xff, 0xff00, 
      0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 
      0xff, 0xff00, 0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 0xff, 
      0xff00, 0xff, 0x0}}, flags = 0x0, travlocks = {
    next = 0xff0000ff00, off = 0x0, hash = 0xff}, 
  next = 0xff0000ff00, device = 0xff00000000, inode = 0xff0000ff00, 
  log_fn = 0x4093b0, hash_fn = 0x4092f0, open_flags = 0x2}

which is consistent.

> I would not be surprised about a strange bug in libc or the kernel.

Or even Xen itself, or the h/w.

Ian,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 12:37:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 12:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0rN6-0006xs-OF; Tue, 16 Dec 2014 12:37:00 +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 1Y0rN4-0006xm-Mx
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 12:36:58 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	00/42-02712-A6720945; Tue, 16 Dec 2014 12:36:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418733416!15407266!1
X-Originating-IP: [66.165.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 5095 invoked from network); 16 Dec 2014 12:36:57 -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;
	16 Dec 2014 12:36:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,586,1413244800"; d="scan'208";a="204865147"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 16 Dec 2014 07:36: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 1Y0rN0-00063A-K6;
	Tue, 16 Dec 2014 12:36:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0rN0-0000c6-1F;
	Tue, 16 Dec 2014 12:36:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21648.10085.606371.543997@mariner.uk.xensource.com>
Date: Tue, 16 Dec 2014 12:36:53 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <20141216113235.GB1705@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
	<20141215170757.GA1705@perard.uk.xensource.com>
	<1418722228.16425.179.camel@citrix.com>
	<20141216113235.GB1705@perard.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup."):
> On Tue, Dec 16, 2014 at 09:30:28AM +0000, Ian Campbell wrote:
> > Unless by "not running" you meant bottlenecked or not keeping up
> > perhaps.
> 
> Well, I did meant no xenconsoled process. But after, I also tried `kill
> -STOP`, but the same things is happening.

I think this is a bug.  I imagine that you can cause `xl create -c' to
malfunction too.

> > > Or, should I set the callback to NULL and have the
> > > domain_create_console_available event sent through
> > > the callback set by libxl_event_register_callbacks()?
> > 
> > That would make sense, except I don't see libxl_evdisable_foo for these
> > events, so I'm not sure it is possible.
> 
> Well, the domain_create_console_available event is report by
> libxl__ao_progress_report which will either callback() or call
> libxl__event_occurred(). So does not seams better to set callback to
> NULL.

The console available notification is only available via the ao
progress mechanism.  So you have to pass a non-NULL aop_console_how,
and the notification will always be generated during the create.

Your options for having the notification delivered are:

I. aop_console_how->callback != NULL:

   libxl will call
     aop_console_how->callback(aop_console_how->for_callback)

II. aop_console_how->callback == NULL:

   libxl will construct an libxl_event *event with
      event->domid = the domid of the domain being constructed
      event->domuuid = its uuid
      event->for_user = aop_console_how->for_event
      event->type = LIBXL_EVENT_TYPE_DOMAIN_CREATE_CONSOLE_AVAILABLE

    What happens to that event depends on whether and how
    libxl_event_register_callbacks has been called.

II(a): If libxl_event_register_callbacks(,hooks,user) was called
   and also the bit is set ie
     !!(hooks->event_occurs_mask
      & (1UL << LIBXL_EVENT_TYPE_DOMAIN_CREATE_CONSOLE_AVAILABLE)):

   libxl will call
      hooks->event_occurs(user,event)

II(b): If libxl_event_register_callbacks(,hooks,user) was NOT called
   or if the bit is clear:

   libxl will queue the event for retrieval by libxl_event_check
   or libxl_event-wait.  (And if the application doesn't call those,
   the application will never be notified; the event will be
   retained until the libxl ctx is destroyed and then discarded.)

I mention all of these for completeness, and for future reference for
anyone reading the archives later.

In libxl you want option I.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 12:37:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 12:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0rN6-0006xs-OF; Tue, 16 Dec 2014 12:37:00 +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 1Y0rN4-0006xm-Mx
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 12:36:58 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	00/42-02712-A6720945; Tue, 16 Dec 2014 12:36:58 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418733416!15407266!1
X-Originating-IP: [66.165.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 5095 invoked from network); 16 Dec 2014 12:36:57 -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;
	16 Dec 2014 12:36:57 -0000
X-IronPort-AV: E=Sophos;i="5.07,586,1413244800"; d="scan'208";a="204865147"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 16 Dec 2014 07:36: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 1Y0rN0-00063A-K6;
	Tue, 16 Dec 2014 12:36:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0rN0-0000c6-1F;
	Tue, 16 Dec 2014 12:36:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21648.10085.606371.543997@mariner.uk.xensource.com>
Date: Tue, 16 Dec 2014 12:36:53 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <20141216113235.GB1705@perard.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
	<20141215170757.GA1705@perard.uk.xensource.com>
	<1418722228.16425.179.camel@citrix.com>
	<20141216113235.GB1705@perard.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA2
Cc: libvir-list@redhat.com, Jim Fehlig <jfehlig@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup."):
> On Tue, Dec 16, 2014 at 09:30:28AM +0000, Ian Campbell wrote:
> > Unless by "not running" you meant bottlenecked or not keeping up
> > perhaps.
> 
> Well, I did meant no xenconsoled process. But after, I also tried `kill
> -STOP`, but the same things is happening.

I think this is a bug.  I imagine that you can cause `xl create -c' to
malfunction too.

> > > Or, should I set the callback to NULL and have the
> > > domain_create_console_available event sent through
> > > the callback set by libxl_event_register_callbacks()?
> > 
> > That would make sense, except I don't see libxl_evdisable_foo for these
> > events, so I'm not sure it is possible.
> 
> Well, the domain_create_console_available event is report by
> libxl__ao_progress_report which will either callback() or call
> libxl__event_occurred(). So does not seams better to set callback to
> NULL.

The console available notification is only available via the ao
progress mechanism.  So you have to pass a non-NULL aop_console_how,
and the notification will always be generated during the create.

Your options for having the notification delivered are:

I. aop_console_how->callback != NULL:

   libxl will call
     aop_console_how->callback(aop_console_how->for_callback)

II. aop_console_how->callback == NULL:

   libxl will construct an libxl_event *event with
      event->domid = the domid of the domain being constructed
      event->domuuid = its uuid
      event->for_user = aop_console_how->for_event
      event->type = LIBXL_EVENT_TYPE_DOMAIN_CREATE_CONSOLE_AVAILABLE

    What happens to that event depends on whether and how
    libxl_event_register_callbacks has been called.

II(a): If libxl_event_register_callbacks(,hooks,user) was called
   and also the bit is set ie
     !!(hooks->event_occurs_mask
      & (1UL << LIBXL_EVENT_TYPE_DOMAIN_CREATE_CONSOLE_AVAILABLE)):

   libxl will call
      hooks->event_occurs(user,event)

II(b): If libxl_event_register_callbacks(,hooks,user) was NOT called
   or if the bit is clear:

   libxl will queue the event for retrieval by libxl_event_check
   or libxl_event-wait.  (And if the application doesn't call those,
   the application will never be notified; the event will be
   retained until the libxl ctx is destroyed and then discarded.)

I mention all of these for completeness, and for future reference for
anyone reading the archives later.

In libxl you want option I.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 12:37:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 12: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 1Y0rNd-00070R-5K; Tue, 16 Dec 2014 12:37: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 1Y0rNb-000706-Pp
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 12:37:31 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	3B/49-31453-A8720945; Tue, 16 Dec 2014 12:37:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418733448!13600753!1
X-Originating-IP: [66.165.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 14937 invoked from network); 16 Dec 2014 12:37:30 -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;
	16 Dec 2014 12:37:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,586,1413244800"; d="scan'208";a="204865265"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 16 Dec 2014 07:37: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 1Y0rNX-00064i-33;
	Tue, 16 Dec 2014 12:37:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0rNW-0000cI-IB;
	Tue, 16 Dec 2014 12:37:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21648.10118.263041.736612@mariner.uk.xensource.com>
Date: Tue, 16 Dec 2014 12:37:26 +0000
To: Anthony PERARD <anthony.perard@citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>, <libvir-list@redhat.com>, Jim Fehlig
	<jfehlig@suse.com>, Xen Devel <xen-devel@lists.xen.org>
In-Reply-To: <21648.10085.606371.543997@mariner.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
	<20141215170757.GA1705@perard.uk.xensource.com>
	<1418722228.16425.179.camel@citrix.com>
	<20141216113235.GB1705@perard.uk.xensource.com>
	<21648.10085.606371.543997@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] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup."):
> I mention all of these for completeness, and for future reference for
> anyone reading the archives later.
> 
> In libxl you want option I.

I mean `in xl you want option I'.  In libvirt you probably want that
too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 12:37:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 12: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 1Y0rNd-00070R-5K; Tue, 16 Dec 2014 12:37: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 1Y0rNb-000706-Pp
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 12:37:31 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	3B/49-31453-A8720945; Tue, 16 Dec 2014 12:37:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418733448!13600753!1
X-Originating-IP: [66.165.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 14937 invoked from network); 16 Dec 2014 12:37:30 -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;
	16 Dec 2014 12:37:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,586,1413244800"; d="scan'208";a="204865265"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 16 Dec 2014 07:37: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 1Y0rNX-00064i-33;
	Tue, 16 Dec 2014 12:37:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0rNW-0000cI-IB;
	Tue, 16 Dec 2014 12:37:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <21648.10118.263041.736612@mariner.uk.xensource.com>
Date: Tue, 16 Dec 2014 12:37:26 +0000
To: Anthony PERARD <anthony.perard@citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>, <libvir-list@redhat.com>, Jim Fehlig
	<jfehlig@suse.com>, Xen Devel <xen-devel@lists.xen.org>
In-Reply-To: <21648.10085.606371.543997@mariner.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
	<20141215170757.GA1705@perard.uk.xensource.com>
	<1418722228.16425.179.camel@citrix.com>
	<20141216113235.GB1705@perard.uk.xensource.com>
	<21648.10085.606371.543997@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] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup."):
> I mention all of these for completeness, and for future reference for
> anyone reading the archives later.
> 
> In libxl you want option I.

I mean `in xl you want option I'.  In libvirt you probably want that
too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 13:16:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 13:16:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0ryv-00087v-FK; Tue, 16 Dec 2014 13:16:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0ryu-00087q-IT
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 13:16:04 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	BC/A0-25714-39030945; Tue, 16 Dec 2014 13:16:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418735761!13607057!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5677 invoked from network); 16 Dec 2014 13:16:03 -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;
	16 Dec 2014 13:16:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="205338538"
Message-ID: <1418735759.16425.235.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 16 Dec 2014 13:15:59 +0000
In-Reply-To: <21648.10085.606371.543997@mariner.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
	<20141215170757.GA1705@perard.uk.xensource.com>
	<1418722228.16425.179.camel@citrix.com>
	<20141216113235.GB1705@perard.uk.xensource.com>
	<21648.10085.606371.543997@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony PERARD <anthony.perard@citrix.com>, libvir-list@redhat.com,
	Jim Fehlig <jfehlig@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-16 at 12:36 +0000, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup."):
> > On Tue, Dec 16, 2014 at 09:30:28AM +0000, Ian Campbell wrote:
> > > Unless by "not running" you meant bottlenecked or not keeping up
> > > perhaps.
> > 
> > Well, I did meant no xenconsoled process. But after, I also tried `kill
> > -STOP`, but the same things is happening.
> 
> I think this is a bug.  I imagine that you can cause `xl create -c' to
> malfunction too.

Presumably the libxl side fix is to register an ev_xswatch (and an
ev_timeout) on the console path (which differs by guest type, see guts
of libxl_console_get_tty) and call the callback out of that instead of
directly at the end of domcreate_....

Depending on how racy this is (not very, I suspect) libvirt could ignore
this possibility and assume the event works (and we'll independently fix
it so it always does), or it could be a bit belt and braces and in
addition to handling the callback also check for NULL and-recheck on the
libvirt internal accessors.

Anthony, you should also note that the callback can happen more than
once, e.g. if you are using pygrub you get it once for the bootloader
pty and then again for the actual guests pty.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 13:16:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 13:16:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0ryv-00087v-FK; Tue, 16 Dec 2014 13:16:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0ryu-00087q-IT
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 13:16:04 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	BC/A0-25714-39030945; Tue, 16 Dec 2014 13:16:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418735761!13607057!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5677 invoked from network); 16 Dec 2014 13:16:03 -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;
	16 Dec 2014 13:16:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="205338538"
Message-ID: <1418735759.16425.235.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 16 Dec 2014 13:15:59 +0000
In-Reply-To: <21648.10085.606371.543997@mariner.uk.xensource.com>
References: <1418139599-23884-1-git-send-email-anthony.perard@citrix.com>
	<1418140562.19809.14.camel@citrix.com>
	<20141211161636.GE1900@perard.uk.xensource.com>
	<1418314995.23309.7.camel@citrix.com>
	<20141215170757.GA1705@perard.uk.xensource.com>
	<1418722228.16425.179.camel@citrix.com>
	<20141216113235.GB1705@perard.uk.xensource.com>
	<21648.10085.606371.543997@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Anthony PERARD <anthony.perard@citrix.com>, libvir-list@redhat.com,
	Jim Fehlig <jfehlig@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain
 startup.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-16 at 12:36 +0000, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup."):
> > On Tue, Dec 16, 2014 at 09:30:28AM +0000, Ian Campbell wrote:
> > > Unless by "not running" you meant bottlenecked or not keeping up
> > > perhaps.
> > 
> > Well, I did meant no xenconsoled process. But after, I also tried `kill
> > -STOP`, but the same things is happening.
> 
> I think this is a bug.  I imagine that you can cause `xl create -c' to
> malfunction too.

Presumably the libxl side fix is to register an ev_xswatch (and an
ev_timeout) on the console path (which differs by guest type, see guts
of libxl_console_get_tty) and call the callback out of that instead of
directly at the end of domcreate_....

Depending on how racy this is (not very, I suspect) libvirt could ignore
this possibility and assume the event works (and we'll independently fix
it so it always does), or it could be a bit belt and braces and in
addition to handling the callback also check for NULL and-recheck on the
libvirt internal accessors.

Anthony, you should also note that the callback can happen more than
once, e.g. if you are using pygrub you get it once for the bootloader
pty and then again for the actual guests pty.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 13:48:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 13:48:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0sTU-0000PA-8k; Tue, 16 Dec 2014 13:47:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1Y0sTS-0000P5-6A
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 13:47:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A1/CD-09842-9F730945; Tue, 16 Dec 2014 13:47:37 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418737656!7922974!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21732 invoked from network); 16 Dec 2014 13:47:36 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-2.tower-21.messagelabs.com with SMTP;
	16 Dec 2014 13:47:36 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 4E162C561D3;
	Tue, 16 Dec 2014 13:47:36 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alex.org.uk; s=mail;
	t=1418737656; bh=U9m7RrO2+Q4ZKjb9Lw+ubbel+r4XBj0Fg0+LVv4ZqVc=;
	h=From:Content-Type:Content-Transfer-Encoding:Subject:Date:
	Message-Id:Cc:To:Mime-Version;
	b=hk/yv5f98KveuHkftOGHygkaNbbcJexvOP0xtzqW77MstaDux1G68woJUkmHvh/Fy
	pldJtn1oyfVcB/3EB8494BjKRS25wNc6Xs0KnHirN3hRsEi1kxaPfiuv5tCiKMWCPH
	wGx6MXxZ9OCoLvNR+xAukACydUMv+k19ui3xEsSE=
From: Alex Bligh <alex@alex.org.uk>
Date: Tue, 16 Dec 2014 13:47:35 +0000
Message-Id: <6FD25049-90E4-461A-93D4-DA7D848496FF@alex.org.uk>
To: Xen Devel <xen-devel@lists.xen.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Cc: Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] dom0 reboot hangs with VMs created with 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

I am running Ubuntu's xen 4.4 (4.4.1-0ubuntu0.14.04.2), but creating VMs
with libxl.

When I do a 'shutdown -r' or similar with no VMs running, dom0 reboots
fine. When I do this with one or more VMs running, I get:

"INFO: task reboot:11897 blocked for more than 120 seconds."

repeatedly, and the machine never reboots. I'm taking this is because
nothing is forcibly destroying the VMs running.

I think this is a bug, but I'm not sure whether it's solely a bug
in the Debian / Ubuntu packaging. What is meant to destroy VMs
on a clean reboot?


-- 
Alex Bligh





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 13:48:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 13:48:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0sTU-0000PA-8k; Tue, 16 Dec 2014 13:47:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1Y0sTS-0000P5-6A
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 13:47:38 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A1/CD-09842-9F730945; Tue, 16 Dec 2014 13:47:37 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418737656!7922974!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21732 invoked from network); 16 Dec 2014 13:47:36 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-2.tower-21.messagelabs.com with SMTP;
	16 Dec 2014 13:47:36 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 4E162C561D3;
	Tue, 16 Dec 2014 13:47:36 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alex.org.uk; s=mail;
	t=1418737656; bh=U9m7RrO2+Q4ZKjb9Lw+ubbel+r4XBj0Fg0+LVv4ZqVc=;
	h=From:Content-Type:Content-Transfer-Encoding:Subject:Date:
	Message-Id:Cc:To:Mime-Version;
	b=hk/yv5f98KveuHkftOGHygkaNbbcJexvOP0xtzqW77MstaDux1G68woJUkmHvh/Fy
	pldJtn1oyfVcB/3EB8494BjKRS25wNc6Xs0KnHirN3hRsEi1kxaPfiuv5tCiKMWCPH
	wGx6MXxZ9OCoLvNR+xAukACydUMv+k19ui3xEsSE=
From: Alex Bligh <alex@alex.org.uk>
Date: Tue, 16 Dec 2014 13:47:35 +0000
Message-Id: <6FD25049-90E4-461A-93D4-DA7D848496FF@alex.org.uk>
To: Xen Devel <xen-devel@lists.xen.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Cc: Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] dom0 reboot hangs with VMs created with 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

I am running Ubuntu's xen 4.4 (4.4.1-0ubuntu0.14.04.2), but creating VMs
with libxl.

When I do a 'shutdown -r' or similar with no VMs running, dom0 reboots
fine. When I do this with one or more VMs running, I get:

"INFO: task reboot:11897 blocked for more than 120 seconds."

repeatedly, and the machine never reboots. I'm taking this is because
nothing is forcibly destroying the VMs running.

I think this is a bug, but I'm not sure whether it's solely a bug
in the Debian / Ubuntu packaging. What is meant to destroy VMs
on a clean reboot?


-- 
Alex Bligh





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 14:00:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 14:00:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0sfU-0000vf-Io; Tue, 16 Dec 2014 14:00:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0sfT-0000va-Le
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 14:00:03 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	07/72-24859-2EA30945; Tue, 16 Dec 2014 14:00:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418738400!13716725!1
X-Originating-IP: [66.165.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 26150 invoked from network); 16 Dec 2014 14:00:02 -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;
	16 Dec 2014 14:00:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204893361"
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.210.2; Tue, 16 Dec 2014 08:59: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 1Y0sfO-0008A0-Gm;
	Tue, 16 Dec 2014 13:59:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0sfO-000585-7M;
	Tue, 16 Dec 2014 13:59:58 +0000
Date: Tue, 16 Dec 2014 13:59:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32391-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] 32391: 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 32391 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32391/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 32348
 test-armhf-armhf-xl           3 host-install(3)         broken REGR. vs. 32348
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 32348
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 32348
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32348
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 32348
 test-armhf-armhf-libvirt      5 xen-boot                  fail REGR. vs. 32348
 test-amd64-i386-freebsd10-amd64  5 xen-boot               fail REGR. vs. 32348
 test-amd64-i386-freebsd10-i386  5 xen-boot                fail REGR. vs. 32348
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot           fail REGR. vs. 32348
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32348
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot             fail REGR. vs. 32348
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32348
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32348
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32348
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32348
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 32348
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 32348
 test-amd64-i386-xl-winxpsp3   5 xen-boot                  fail REGR. vs. 32348
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot             fail REGR. vs. 32348
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 32348
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32348
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 32348

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt       5 xen-boot                 fail blocked in 32348
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10   fail blocked in 32348
 test-amd64-i386-xl-credit2    5 xen-boot                 fail blocked in 32348
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start        fail blocked in 32348
 test-amd64-amd64-xl           9 guest-start              fail blocked in 32348
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10   fail blocked in 32348
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot         fail blocked in 32348
 test-amd64-i386-rhel6hvm-intel  5 xen-boot               fail blocked in 32348
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot         fail blocked in 32348
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot          fail blocked in 32348
 test-amd64-amd64-pair        16 guest-start/debian       fail blocked in 32348
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install    fail blocked in 32348
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install    fail blocked in 32348

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-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-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                15229b5a1674f7096a547f590f2c70a2a86ae744
baseline version:
 linux                9ea18f8cab5f1c36cdd0f09717e35ceb48c36a87

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                                          broken  
 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                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 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                               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 Tue Dec 16 14:00:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 14:00:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0sfU-0000vf-Io; Tue, 16 Dec 2014 14:00:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0sfT-0000va-Le
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 14:00:03 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	07/72-24859-2EA30945; Tue, 16 Dec 2014 14:00:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418738400!13716725!1
X-Originating-IP: [66.165.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 26150 invoked from network); 16 Dec 2014 14:00:02 -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;
	16 Dec 2014 14:00:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204893361"
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.210.2; Tue, 16 Dec 2014 08:59: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 1Y0sfO-0008A0-Gm;
	Tue, 16 Dec 2014 13:59:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0sfO-000585-7M;
	Tue, 16 Dec 2014 13:59:58 +0000
Date: Tue, 16 Dec 2014 13:59:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32391-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] 32391: 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 32391 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32391/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 32348
 test-armhf-armhf-xl           3 host-install(3)         broken REGR. vs. 32348
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 32348
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 32348
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32348
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 32348
 test-armhf-armhf-libvirt      5 xen-boot                  fail REGR. vs. 32348
 test-amd64-i386-freebsd10-amd64  5 xen-boot               fail REGR. vs. 32348
 test-amd64-i386-freebsd10-i386  5 xen-boot                fail REGR. vs. 32348
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot           fail REGR. vs. 32348
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32348
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot             fail REGR. vs. 32348
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32348
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32348
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32348
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32348
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 32348
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 32348
 test-amd64-i386-xl-winxpsp3   5 xen-boot                  fail REGR. vs. 32348
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot             fail REGR. vs. 32348
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 32348
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32348
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 32348

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt       5 xen-boot                 fail blocked in 32348
 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10   fail blocked in 32348
 test-amd64-i386-xl-credit2    5 xen-boot                 fail blocked in 32348
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start        fail blocked in 32348
 test-amd64-amd64-xl           9 guest-start              fail blocked in 32348
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10   fail blocked in 32348
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot         fail blocked in 32348
 test-amd64-i386-rhel6hvm-intel  5 xen-boot               fail blocked in 32348
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot         fail blocked in 32348
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot          fail blocked in 32348
 test-amd64-amd64-pair        16 guest-start/debian       fail blocked in 32348
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install    fail blocked in 32348
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install    fail blocked in 32348

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-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-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                15229b5a1674f7096a547f590f2c70a2a86ae744
baseline version:
 linux                9ea18f8cab5f1c36cdd0f09717e35ceb48c36a87

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                                          broken  
 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                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 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                               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 Tue Dec 16 14:40:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 14: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 1Y0tIJ-00027q-Lz; Tue, 16 Dec 2014 14:40: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 1Y0tIF-00027h-LF
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 14:40:09 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	37/4E-14214-64440945; Tue, 16 Dec 2014 14:40:06 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418740806!13653930!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 5529 invoked from network); 16 Dec 2014 14:40:06 -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; 16 Dec 2014 14:40:06 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 4FAE1AC06;
	Tue, 16 Dec 2014 14:40:05 +0000 (UTC)
Message-ID: <54904443.5050806@suse.com>
Date: Tue, 16 Dec 2014 15:40:03 +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, 
	x86@kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, tglx@linutronix.de, mingo@redhat.com, 
	hpa@zytor.com, mmarek@suse.cz, linux-kbuild@vger.kernel.org
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-2-git-send-email-jgross@suse.com>
	<548EC841.2000107@citrix.com>
In-Reply-To: <548EC841.2000107@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/15/2014 12:38 PM, David Vrabel wrote:
> On 11/12/14 18:04, Juergen Gross wrote:
>> Today there are several places in the kernel which build tables
>> containing one entry for each possible Xen hypercall. Create an
>> infrastructure to be able to generate these tables at build time.
>
> Does arm and arm64 need something similar?  If so are the tools here
> suitable for them?

I don't think arm* needs this. But in case it does, the tools would
support arm as well.


Juergen

>
>> --- a/arch/x86/syscalls/Makefile
>> +++ b/arch/x86/syscalls/Makefile
>
> Why are these changes here and not in arch/x86/xen/Makefile?
>
>> @@ -19,6 +19,9 @@ quiet_cmd_syshdr = SYSHDR  $@
>>   quiet_cmd_systbl = SYSTBL  $@
>>         cmd_systbl = $(CONFIG_SHELL) '$(systbl)' $< $@
>>
>> +quiet_cmd_hypercalls = HYPERCALLS $@
>> +      cmd_hypercalls = $(CONFIG_SHELL) '$<' $@ $(filter-out $<,$^)
>> +
>>   syshdr_abi_unistd_32 := i386
>>   $(uapi)/unistd_32.h: $(syscall32) $(syshdr)
>>   	$(call if_changed,syshdr)
>> @@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
>>   $(out)/syscalls_64.h: $(syscall64) $(systbl)
>>   	$(call if_changed,systbl)
>>
>> +$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
>> +	$(call if_changed,hypercalls)
>> +
>> +$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
>
> The generated header should end up in asm/xen/
>
>> --- /dev/null
>> +++ b/scripts/xen-hypercalls.sh
>> @@ -0,0 +1,11 @@
>> +#!/bin/sh
>> +out="$1"
>> +shift
>> +in="$@"
>> +
>> +for i in $in; do
>> +	eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
>> +done | \
>> +awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
>> +	END {for (i in v) if (!(v[i] in v))
>> +		print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
>
> Include a comment in the generated output saying what generated it. e.g.,
>
> /* auto-generated by scripts/xen-hypercall.sh */
>
> David
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 14:40:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 14: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 1Y0tIJ-00027q-Lz; Tue, 16 Dec 2014 14:40: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 1Y0tIF-00027h-LF
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 14:40:09 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	37/4E-14214-64440945; Tue, 16 Dec 2014 14:40:06 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418740806!13653930!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 5529 invoked from network); 16 Dec 2014 14:40:06 -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; 16 Dec 2014 14:40:06 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 4FAE1AC06;
	Tue, 16 Dec 2014 14:40:05 +0000 (UTC)
Message-ID: <54904443.5050806@suse.com>
Date: Tue, 16 Dec 2014 15:40:03 +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, 
	x86@kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, 
	boris.ostrovsky@oracle.com, tglx@linutronix.de, mingo@redhat.com, 
	hpa@zytor.com, mmarek@suse.cz, linux-kbuild@vger.kernel.org
References: <1418321065-10212-1-git-send-email-jgross@suse.com>
	<1418321065-10212-2-git-send-email-jgross@suse.com>
	<548EC841.2000107@citrix.com>
In-Reply-To: <548EC841.2000107@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/15/2014 12:38 PM, David Vrabel wrote:
> On 11/12/14 18:04, Juergen Gross wrote:
>> Today there are several places in the kernel which build tables
>> containing one entry for each possible Xen hypercall. Create an
>> infrastructure to be able to generate these tables at build time.
>
> Does arm and arm64 need something similar?  If so are the tools here
> suitable for them?

I don't think arm* needs this. But in case it does, the tools would
support arm as well.


Juergen

>
>> --- a/arch/x86/syscalls/Makefile
>> +++ b/arch/x86/syscalls/Makefile
>
> Why are these changes here and not in arch/x86/xen/Makefile?
>
>> @@ -19,6 +19,9 @@ quiet_cmd_syshdr = SYSHDR  $@
>>   quiet_cmd_systbl = SYSTBL  $@
>>         cmd_systbl = $(CONFIG_SHELL) '$(systbl)' $< $@
>>
>> +quiet_cmd_hypercalls = HYPERCALLS $@
>> +      cmd_hypercalls = $(CONFIG_SHELL) '$<' $@ $(filter-out $<,$^)
>> +
>>   syshdr_abi_unistd_32 := i386
>>   $(uapi)/unistd_32.h: $(syscall32) $(syshdr)
>>   	$(call if_changed,syshdr)
>> @@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
>>   $(out)/syscalls_64.h: $(syscall64) $(systbl)
>>   	$(call if_changed,systbl)
>>
>> +$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
>> +	$(call if_changed,hypercalls)
>> +
>> +$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
>
> The generated header should end up in asm/xen/
>
>> --- /dev/null
>> +++ b/scripts/xen-hypercalls.sh
>> @@ -0,0 +1,11 @@
>> +#!/bin/sh
>> +out="$1"
>> +shift
>> +in="$@"
>> +
>> +for i in $in; do
>> +	eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
>> +done | \
>> +awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
>> +	END {for (i in v) if (!(v[i] in v))
>> +		print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
>
> Include a comment in the generated output saying what generated it. e.g.,
>
> /* auto-generated by scripts/xen-hypercall.sh */
>
> David
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 14:52:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 14:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0tTs-0002ZJ-V7; Tue, 16 Dec 2014 14:52:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Y0tTs-0002ZB-CA
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 14:52:08 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	E3/DA-14214-71740945; Tue, 16 Dec 2014 14:52:07 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418741524!13651352!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 24038 invoked from network); 16 Dec 2014 14:52:06 -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;
	16 Dec 2014 14:52:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204917762"
Message-ID: <549046D4.8030304@citrix.com>
Date: Tue, 16 Dec 2014 14:51:00 +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>, <david.vrabel@citrix.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>	<1418321065-10212-2-git-send-email-jgross@suse.com>	<548EC841.2000107@citrix.com>
	<548ED84D020000780004F8FB@mail.emea.novell.com>
In-Reply-To: <548ED84D020000780004F8FB@mail.emea.novell.com>
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
	xen-devel <xen-devel@lists.xenproject.org>, tglx@linutronix.de,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/12/14 11:47, Jan Beulich wrote:
>>>> On 15.12.14 at 12:38, <david.vrabel@citrix.com> wrote:
>> On 11/12/14 18:04, Juergen Gross wrote:
>>> --- a/arch/x86/syscalls/Makefile
>>> +++ b/arch/x86/syscalls/Makefile
>>
>> Why are these changes here and not in arch/x86/xen/Makefile?
> 
> Because this needs to be done in a step that (afaict) has no hook
> in the Xen-specific Makefile.
> 
>>> @@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
>>>  $(out)/syscalls_64.h: $(syscall64) $(systbl)
>>>  	$(call if_changed,systbl)
>>>  
>>> +$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
>>> +	$(call if_changed,hypercalls)
>>> +
>>> +$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
>>
>> The generated header should end up in asm/xen/
> 
> Why is generated/asm/ not good enough?

I meant something like generated/asm/xen/hypercall-macros.h

So a "xen/" prefix which is consistent with all the other xen specific
headers.

But if this is non-trivial it's not a major issue.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 14:52:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 14:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0tTs-0002ZJ-V7; Tue, 16 Dec 2014 14:52:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Y0tTs-0002ZB-CA
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 14:52:08 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	E3/DA-14214-71740945; Tue, 16 Dec 2014 14:52:07 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418741524!13651352!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 24038 invoked from network); 16 Dec 2014 14:52:06 -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;
	16 Dec 2014 14:52:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204917762"
Message-ID: <549046D4.8030304@citrix.com>
Date: Tue, 16 Dec 2014 14:51:00 +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>, <david.vrabel@citrix.com>
References: <1418321065-10212-1-git-send-email-jgross@suse.com>	<1418321065-10212-2-git-send-email-jgross@suse.com>	<548EC841.2000107@citrix.com>
	<548ED84D020000780004F8FB@mail.emea.novell.com>
In-Reply-To: <548ED84D020000780004F8FB@mail.emea.novell.com>
X-DLP: MIA1
Cc: Juergen Gross <JGross@suse.com>, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
	xen-devel <xen-devel@lists.xenproject.org>, tglx@linutronix.de,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/12/14 11:47, Jan Beulich wrote:
>>>> On 15.12.14 at 12:38, <david.vrabel@citrix.com> wrote:
>> On 11/12/14 18:04, Juergen Gross wrote:
>>> --- a/arch/x86/syscalls/Makefile
>>> +++ b/arch/x86/syscalls/Makefile
>>
>> Why are these changes here and not in arch/x86/xen/Makefile?
> 
> Because this needs to be done in a step that (afaict) has no hook
> in the Xen-specific Makefile.
> 
>>> @@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
>>>  $(out)/syscalls_64.h: $(syscall64) $(systbl)
>>>  	$(call if_changed,systbl)
>>>  
>>> +$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
>>> +	$(call if_changed,hypercalls)
>>> +
>>> +$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
>>
>> The generated header should end up in asm/xen/
> 
> Why is generated/asm/ not good enough?

I meant something like generated/asm/xen/hypercall-macros.h

So a "xen/" prefix which is consistent with all the other xen specific
headers.

But if this is non-trivial it's not a major issue.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 15:10:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 15:10:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0tlI-00036Q-Ob; Tue, 16 Dec 2014 15:10: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 1Y0tlH-00036I-8y
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 15:10:07 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	C0/E6-02696-E4B40945; Tue, 16 Dec 2014 15:10:06 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418742604!9992962!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10450 invoked from network); 16 Dec 2014 15:10:05 -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; 16 Dec 2014 15:10: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 sBGFA2QP010418
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Dec 2014 15:10:03 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
	sBGFA1Uf006273
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Dec 2014 15:10:01 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
	sBGFA00q006113; Tue, 16 Dec 2014 15:10: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 ; Tue, 16 Dec 2014 07:10:00 -0800
Message-ID: <54904BC1.10604@oracle.com>
Date: Tue, 16 Dec 2014 10:12:01 -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: <1418682275-2505-1-git-send-email-boris.ostrovsky@oracle.com>
	<549009F9020000780004FCB3@mail.emea.novell.com>
In-Reply-To: <549009F9020000780004FCB3@mail.emea.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] x86/VPMU: Clear last_vcpu when
 destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/16/2014 04:31 AM, Jan Beulich wrote:
>>>> On 15.12.14 at 23:24, <boris.ostrovsky@oracle.com> wrote:
>> We need to make sure that last_vcpu is not pointing to VCPU whose
>> VPMU is being destroyed. Otherwise we may try to dereference it in
>> the future, when VCPU is gone.
>>
>> We have to do this via IPI since otherwise there is a (somewheat
>> theoretical) chance that between test and subsequent clearing
>> of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
>> both load_vpmu() and then save_vpmu() for another VCPU. The former
>> will clear last_vcpu and the latter will set it to something else.
> Apart from the question of using cmpxchg instead of the IPI (I can
> see with the current model that using an IPI is the only clean way,
> i.e. the alternative - if usable - would mean altering existing logic
> too),


You mean something like

     struct vcpu **last = &per_cpu(last_vcpu, vpmu->last_pcpu);
     cmpxchg(last, v, NULL);

Yes, that could work.

-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 15:10:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 15:10:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0tlI-00036Q-Ob; Tue, 16 Dec 2014 15:10: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 1Y0tlH-00036I-8y
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 15:10:07 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	C0/E6-02696-E4B40945; Tue, 16 Dec 2014 15:10:06 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418742604!9992962!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10450 invoked from network); 16 Dec 2014 15:10:05 -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; 16 Dec 2014 15:10: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 sBGFA2QP010418
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Dec 2014 15:10:03 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
	sBGFA1Uf006273
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Dec 2014 15:10:01 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
	sBGFA00q006113; Tue, 16 Dec 2014 15:10: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 ; Tue, 16 Dec 2014 07:10:00 -0800
Message-ID: <54904BC1.10604@oracle.com>
Date: Tue, 16 Dec 2014 10:12:01 -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: <1418682275-2505-1-git-send-email-boris.ostrovsky@oracle.com>
	<549009F9020000780004FCB3@mail.emea.novell.com>
In-Reply-To: <549009F9020000780004FCB3@mail.emea.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 for 4.5] x86/VPMU: Clear last_vcpu when
 destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/16/2014 04:31 AM, Jan Beulich wrote:
>>>> On 15.12.14 at 23:24, <boris.ostrovsky@oracle.com> wrote:
>> We need to make sure that last_vcpu is not pointing to VCPU whose
>> VPMU is being destroyed. Otherwise we may try to dereference it in
>> the future, when VCPU is gone.
>>
>> We have to do this via IPI since otherwise there is a (somewheat
>> theoretical) chance that between test and subsequent clearing
>> of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
>> both load_vpmu() and then save_vpmu() for another VCPU. The former
>> will clear last_vcpu and the latter will set it to something else.
> Apart from the question of using cmpxchg instead of the IPI (I can
> see with the current model that using an IPI is the only clean way,
> i.e. the alternative - if usable - would mean altering existing logic
> too),


You mean something like

     struct vcpu **last = &per_cpu(last_vcpu, vpmu->last_pcpu);
     cmpxchg(last, v, NULL);

Yes, that could work.

-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 15:57:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 15:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0uUL-0004V7-4w; Tue, 16 Dec 2014 15:56:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0uUJ-0004V2-NJ
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 15:56:39 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	BB/D9-31453-73650945; Tue, 16 Dec 2014 15:56:39 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418745396!13660864!1
X-Originating-IP: [66.165.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 3319 invoked from network); 16 Dec 2014 15:56:37 -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;
	16 Dec 2014 15:56:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204951203"
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.210.2; Tue, 16 Dec 2014 10:55: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 1Y0uTa-0000Ga-BC;
	Tue, 16 Dec 2014 15:55:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0uTa-0001de-3H;
	Tue, 16 Dec 2014 15:55:54 +0000
Date: Tue, 16 Dec 2014 15:55:54 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32413-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] 32413: 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 32413 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32413/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          2c9e812bc368cb68a6249b99b1fb51ef3299d81c
baseline version:
 rumpuserxen          d40acc2019bd352e1de13842459b5fecf5bc565e

------------------------------------------------------------
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=2c9e812bc368cb68a6249b99b1fb51ef3299d81c
+ . 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 2c9e812bc368cb68a6249b99b1fb51ef3299d81c
+ branch=rumpuserxen
+ revision=2c9e812bc368cb68a6249b99b1fb51ef3299d81c
+ . 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 2c9e812bc368cb68a6249b99b1fb51ef3299d81c:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   d40acc2..2c9e812  2c9e812bc368cb68a6249b99b1fb51ef3299d81c -> 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 Dec 16 15:57:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 15:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0uUL-0004V7-4w; Tue, 16 Dec 2014 15:56:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0uUJ-0004V2-NJ
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 15:56:39 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	BB/D9-31453-73650945; Tue, 16 Dec 2014 15:56:39 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418745396!13660864!1
X-Originating-IP: [66.165.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 3319 invoked from network); 16 Dec 2014 15:56:37 -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;
	16 Dec 2014 15:56:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204951203"
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.210.2; Tue, 16 Dec 2014 10:55: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 1Y0uTa-0000Ga-BC;
	Tue, 16 Dec 2014 15:55:54 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0uTa-0001de-3H;
	Tue, 16 Dec 2014 15:55:54 +0000
Date: Tue, 16 Dec 2014 15:55:54 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32413-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] 32413: 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 32413 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32413/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          2c9e812bc368cb68a6249b99b1fb51ef3299d81c
baseline version:
 rumpuserxen          d40acc2019bd352e1de13842459b5fecf5bc565e

------------------------------------------------------------
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=2c9e812bc368cb68a6249b99b1fb51ef3299d81c
+ . 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 2c9e812bc368cb68a6249b99b1fb51ef3299d81c
+ branch=rumpuserxen
+ revision=2c9e812bc368cb68a6249b99b1fb51ef3299d81c
+ . 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 2c9e812bc368cb68a6249b99b1fb51ef3299d81c:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   d40acc2..2c9e812  2c9e812bc368cb68a6249b99b1fb51ef3299d81c -> 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 Dec 16 16:14:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16: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 1Y0ul9-0005Tt-LE; Tue, 16 Dec 2014 16:14:03 +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 1Y0ul7-0005To-MD
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 16:14:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	39/D1-15461-94A50945; Tue, 16 Dec 2014 16:14:01 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418746439!15978802!1
X-Originating-IP: [209.85.220.178]
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 31358 invoked from network); 16 Dec 2014 16:14:00 -0000
Received: from mail-vc0-f178.google.com (HELO mail-vc0-f178.google.com)
	(209.85.220.178)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 16:14:00 -0000
Received: by mail-vc0-f178.google.com with SMTP id hq11so6641671vcb.37
	for <Xen-devel@lists.xen.org>; Tue, 16 Dec 2014 08:13:59 -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=nJwLQFoyd7KxeMlaEeu8MDjxGqjNEP8A681Dk/pz5W0=;
	b=fhfve3YKzBe0OvaDxvC1jlxpMXapOz5q4ujOTVUvQrQBVIPWQ1spGgv4ngmih2RcN9
	87lUmPirVATCtt5yghM79XNWTQ92esLBLXy3EmcEwdJHbwWUKSS3eU5gWzafonTPG088
	XgzuvCn056UzeXfnWw5l3W/p++aGlLgkcM9mSPpdnlOEoU3HSnh9N14RaGFugmXo2FEn
	L/L6DoeZA6zKNChzwhAjUz72K20RjybrOR3ORvwqj0ab2ij0xxV9PRc4sZc8hSwQ8oK+
	aBt4rSeYJZ2nXEnHmcl2lVZ/oRdKslQcbJXDxjuYrzT5gZl4AtPBhLzhe9k+WmWltS3L
	g9Ng==
MIME-Version: 1.0
X-Received: by 10.52.37.72 with SMTP id w8mr19495278vdj.28.1418746439285; Tue,
	16 Dec 2014 08:13:59 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Tue, 16 Dec 2014 08:13:59 -0800 (PST)
In-Reply-To: <1418732635.16425.221.camel@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
Date: Tue, 16 Dec 2014 16:13:59 +0000
Message-ID: <CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Xen-devel@lists.xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>
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

2014-12-16 12:23 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
> On Tue, 2014-12-16 at 11:30 +0000, Frediano Ziglio wrote:
>> 2014-12-16 11:06 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
>> > On Tue, 2014-12-16 at 10:45 +0000, Ian Campbell wrote:
>> >> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
>> >> > > I notice in your bugzilla (for a different occurrence, I think):
>> >> > >> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
>> >> > >
>> >> > > Which appears to have faulted access 0xff000000000 too. It looks like
>> >> > > this process is a python thing, it's nothing to do with xenstored I
>> >> > > assume?
>> >> >
>> >> > Yes, that's one univention-config, which is completely independent of
>> >> > xen(stored).
>> >> >
>> >> > > It seems rather coincidental that it should be accessing the
>> >> > > same sort of address and be faulting.
>> >> >
>> >> > Yes, good catch. I'll have another look at those core dumps.
>> >>
>> >> With this in mind, please can you confirm what model of machines you've
>> >> seen this on, and in particular whether they are all the same class of
>> >> machine or whether they are significantly different.
>> >>
>> >> The reason being that randomly placed 0xff values in a field of 0x00
>> >> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong
>> >> memory pages.
>> >
>> > Thanks for giving me access to the core files. This is very suspicious:
>> > (gdb) frame 2
>> > #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0 "/var/lib/xenstored/tdb.0x1935bb0", hash_size=<value optimized out>, tdb_flags=0, open_flags=<value optimized out>, mode=<value optimized out>,
>> >     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at tdb.c:1958
>> > 1958            SAFE_FREE(tdb->locked);
>> >
>> > (gdb) x/96x tdb
>> > 0x1921270:      0x00000000      0x00000000      0x00000000      0x00000000
>> > 0x1921280:      0x0000001f      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921290:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x19212a0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x19212b0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x19212c0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x19212d0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x19212e0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x19212f0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921300:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921310:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921320:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921330:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921340:      0x00000000      0x00000000      0x0000ff00      0x000000ff
>> > 0x1921350:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921360:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921370:      0x004093b0      0x00000000      0x004092f0      0x00000000
>> > 0x1921380:      0x00000002      0x00000000      0x00000091      0x00000000
>> > 0x1921390:      0x0193de70      0x00000000      0x01963600      0x00000000
>> > 0x19213a0:      0x00000000      0x00000000      0x0193fbb0      0x00000000
>> > 0x19213b0:      0x00000000      0x00000000      0x00000000      0x00000000
>> > 0x19213c0:      0x00405870      0x00000000      0x0040e3e0      0x00000000
>> > 0x19213d0:      0x00000038      0x00000000      0xe814ec70      0x6f2f6567
>> > 0x19213e0:      0x01963650      0x00000000      0x0193dec0      0x00000000
>> >
>> > Something has clearly done a number on the ram of this process.
>> > 0x1921270 through 0x192136f is 256 bytes...
>> >
>> > Since it appears to be happening to other processes too I would hazard
>> > that this is not a xenstored issue.
>> >
>> > Ian.
>> >
>>
>> Good catch Ian!
>>
>> Strange corruption. Probably not related to xenstored as you
>> suggested. I would be curious to see what's before the tdb pointer and
>> where does the corruption starts.
>
> (gdb) print tdb
> $2 = (TDB_CONTEXT *) 0x1921270
> (gdb) x/64x 0x1921200
> 0x1921200:      0x01921174      0x00000000      0x00000000      0x00000000
> 0x1921210:      0x01921174      0x00000000      0x00000171      0x00000000
> 0x1921220:      0x00000000      0x00000000      0x00000000      0x00000000

0x0 next (u64)
0x0 prev (u64)

> 0x1921230:      0x01941f60      0x00000000      0x00000000      0x00000000

0x01941f60 parent (u64), make sense is not NULL
0x0 child (u64)

> 0x1921240:      0x00000000      0x00000000      0x00000000      0x6f630065

0x0 refs (u64)
0x0 null_refs (u32)
0x6f630065 pad, garbage (u32)

> 0x1921250:      0x00000000      0x00000000      0x0040e8a7      0x00000000

0x0 destructor (u64)
0x0040e8a7 name (u64)

> 0x1921260:      0x00000118      0x00000000      0xe814ec70      0x00000000

0x118, size (u64)
0xe814ec70 magic (u32)
0x0 pad (u32)

Well... all the talloc header seems fine to me.


> 0x1921270:      0x00000000      0x00000000      0x00000000      0x00000000
> 0x1921280:      0x0000001f      0x000000ff      0x0000ff00      0x000000ff
> 0x1921290:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212a0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212b0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212c0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212d0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212e0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212f0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>
> So it appears to start at 0x1921270 or maybe ...6c.
>

It looks like that there is a pattern like

 0x00000000      0x000000ff      0x0000ff00      0x000000ff

only exceptions are when field is set after talloc_zero (fd, flags,
functions). Something like the memset inside the talloc_zero fill with
this pattern instead of zeroes. Note that a pattern of 16 bytes is
compatible with SSE instructions size. Some bug in the save/restore
for SSE registers? Some bug on SSE emulation?

What does "info all-registers" gdb command say about SSE registers?

Do we have a bug in Xen that affect SSE instructions (possibly already
fixed after Philipp version) ?

>>  I also don't understand where the
>> "fd = 47" came from a previous mail. 0x1f is 31, not 47 (which is
>> 0x2f).
>
> I must have been using a different coredump to the origianl report
> (there are several).
>
> In the one which corresponds to the above:
>
> (gdb) print *tdb
> $3 = {name = 0x0, map_ptr = 0x0, fd = 31, map_size = 255,
>   read_only = 65280, locked = 0xff00000000, ecode = 65280, header = {
>     magic_food = "\377\000\000\000\000\000\000\000\377\000\000\000\000\377\000\000\377\000\000\000\000\000\000\000\377\000\000\000\000\377\000", version = 255, hash_size = 0, rwlocks = 255, reserved = {65280,
>       255, 0, 255, 65280, 255, 0, 255, 65280, 255, 0, 255, 65280,
>       255, 0, 255, 65280, 255, 0, 255, 65280, 255, 0, 255, 65280,
>       255, 0, 255, 65280, 255, 0}}, flags = 0, travlocks = {
>     next = 0xff0000ff00, off = 0, hash = 255}, next = 0xff0000ff00,
>   device = 1095216660480, inode = 1095216725760,
>   log_fn = 0x4093b0 <null_log_fn>,
>   hash_fn = 0x4092f0 <default_tdb_hash>, open_flags = 2}
> (gdb) print/x *tdb
> $4 = {name = 0x0, map_ptr = 0x0, fd = 0x1f, map_size = 0xff,
>   read_only = 0xff00, locked = 0xff00000000, ecode = 0xff00,
>   header = {magic_food = {0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>       0xff, 0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0,
>       0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0},
>     version = 0xff, hash_size = 0x0, rwlocks = 0xff, reserved = {
>       0xff00, 0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 0xff, 0xff00,
>       0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 0xff, 0xff00, 0xff, 0x0,
>       0xff, 0xff00, 0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 0xff,
>       0xff00, 0xff, 0x0}}, flags = 0x0, travlocks = {
>     next = 0xff0000ff00, off = 0x0, hash = 0xff},
>   next = 0xff0000ff00, device = 0xff00000000, inode = 0xff0000ff00,
>   log_fn = 0x4093b0, hash_fn = 0x4092f0, open_flags = 0x2}
>
> which is consistent.
>
>> I would not be surprised about a strange bug in libc or the kernel.
>
> Or even Xen itself, or the h/w.
>
> Ian,
>

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 16:14:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16: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 1Y0ul9-0005Tt-LE; Tue, 16 Dec 2014 16:14:03 +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 1Y0ul7-0005To-MD
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 16:14:01 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	39/D1-15461-94A50945; Tue, 16 Dec 2014 16:14:01 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418746439!15978802!1
X-Originating-IP: [209.85.220.178]
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 31358 invoked from network); 16 Dec 2014 16:14:00 -0000
Received: from mail-vc0-f178.google.com (HELO mail-vc0-f178.google.com)
	(209.85.220.178)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 16:14:00 -0000
Received: by mail-vc0-f178.google.com with SMTP id hq11so6641671vcb.37
	for <Xen-devel@lists.xen.org>; Tue, 16 Dec 2014 08:13:59 -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=nJwLQFoyd7KxeMlaEeu8MDjxGqjNEP8A681Dk/pz5W0=;
	b=fhfve3YKzBe0OvaDxvC1jlxpMXapOz5q4ujOTVUvQrQBVIPWQ1spGgv4ngmih2RcN9
	87lUmPirVATCtt5yghM79XNWTQ92esLBLXy3EmcEwdJHbwWUKSS3eU5gWzafonTPG088
	XgzuvCn056UzeXfnWw5l3W/p++aGlLgkcM9mSPpdnlOEoU3HSnh9N14RaGFugmXo2FEn
	L/L6DoeZA6zKNChzwhAjUz72K20RjybrOR3ORvwqj0ab2ij0xxV9PRc4sZc8hSwQ8oK+
	aBt4rSeYJZ2nXEnHmcl2lVZ/oRdKslQcbJXDxjuYrzT5gZl4AtPBhLzhe9k+WmWltS3L
	g9Ng==
MIME-Version: 1.0
X-Received: by 10.52.37.72 with SMTP id w8mr19495278vdj.28.1418746439285; Tue,
	16 Dec 2014 08:13:59 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Tue, 16 Dec 2014 08:13:59 -0800 (PST)
In-Reply-To: <1418732635.16425.221.camel@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
Date: Tue, 16 Dec 2014 16:13:59 +0000
Message-ID: <CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Xen-devel@lists.xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>
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

2014-12-16 12:23 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
> On Tue, 2014-12-16 at 11:30 +0000, Frediano Ziglio wrote:
>> 2014-12-16 11:06 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
>> > On Tue, 2014-12-16 at 10:45 +0000, Ian Campbell wrote:
>> >> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
>> >> > > I notice in your bugzilla (for a different occurrence, I think):
>> >> > >> [2090451.721705] univention-conf[2512]: segfault at ff00000000 ip 000000000045e238 sp 00007ffff68dfa30 error 6 in python2.6[400000+21e000]
>> >> > >
>> >> > > Which appears to have faulted access 0xff000000000 too. It looks like
>> >> > > this process is a python thing, it's nothing to do with xenstored I
>> >> > > assume?
>> >> >
>> >> > Yes, that's one univention-config, which is completely independent of
>> >> > xen(stored).
>> >> >
>> >> > > It seems rather coincidental that it should be accessing the
>> >> > > same sort of address and be faulting.
>> >> >
>> >> > Yes, good catch. I'll have another look at those core dumps.
>> >>
>> >> With this in mind, please can you confirm what model of machines you've
>> >> seen this on, and in particular whether they are all the same class of
>> >> machine or whether they are significantly different.
>> >>
>> >> The reason being that randomly placed 0xff values in a field of 0x00
>> >> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong
>> >> memory pages.
>> >
>> > Thanks for giving me access to the core files. This is very suspicious:
>> > (gdb) frame 2
>> > #2  0x000000000040a348 in tdb_open_ex (name=0x1941fb0 "/var/lib/xenstored/tdb.0x1935bb0", hash_size=<value optimized out>, tdb_flags=0, open_flags=<value optimized out>, mode=<value optimized out>,
>> >     log_fn=0x4093b0 <null_log_fn>, hash_fn=<value optimized out>) at tdb.c:1958
>> > 1958            SAFE_FREE(tdb->locked);
>> >
>> > (gdb) x/96x tdb
>> > 0x1921270:      0x00000000      0x00000000      0x00000000      0x00000000
>> > 0x1921280:      0x0000001f      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921290:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x19212a0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x19212b0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x19212c0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x19212d0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x19212e0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x19212f0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921300:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921310:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921320:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921330:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921340:      0x00000000      0x00000000      0x0000ff00      0x000000ff
>> > 0x1921350:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921360:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>> > 0x1921370:      0x004093b0      0x00000000      0x004092f0      0x00000000
>> > 0x1921380:      0x00000002      0x00000000      0x00000091      0x00000000
>> > 0x1921390:      0x0193de70      0x00000000      0x01963600      0x00000000
>> > 0x19213a0:      0x00000000      0x00000000      0x0193fbb0      0x00000000
>> > 0x19213b0:      0x00000000      0x00000000      0x00000000      0x00000000
>> > 0x19213c0:      0x00405870      0x00000000      0x0040e3e0      0x00000000
>> > 0x19213d0:      0x00000038      0x00000000      0xe814ec70      0x6f2f6567
>> > 0x19213e0:      0x01963650      0x00000000      0x0193dec0      0x00000000
>> >
>> > Something has clearly done a number on the ram of this process.
>> > 0x1921270 through 0x192136f is 256 bytes...
>> >
>> > Since it appears to be happening to other processes too I would hazard
>> > that this is not a xenstored issue.
>> >
>> > Ian.
>> >
>>
>> Good catch Ian!
>>
>> Strange corruption. Probably not related to xenstored as you
>> suggested. I would be curious to see what's before the tdb pointer and
>> where does the corruption starts.
>
> (gdb) print tdb
> $2 = (TDB_CONTEXT *) 0x1921270
> (gdb) x/64x 0x1921200
> 0x1921200:      0x01921174      0x00000000      0x00000000      0x00000000
> 0x1921210:      0x01921174      0x00000000      0x00000171      0x00000000
> 0x1921220:      0x00000000      0x00000000      0x00000000      0x00000000

0x0 next (u64)
0x0 prev (u64)

> 0x1921230:      0x01941f60      0x00000000      0x00000000      0x00000000

0x01941f60 parent (u64), make sense is not NULL
0x0 child (u64)

> 0x1921240:      0x00000000      0x00000000      0x00000000      0x6f630065

0x0 refs (u64)
0x0 null_refs (u32)
0x6f630065 pad, garbage (u32)

> 0x1921250:      0x00000000      0x00000000      0x0040e8a7      0x00000000

0x0 destructor (u64)
0x0040e8a7 name (u64)

> 0x1921260:      0x00000118      0x00000000      0xe814ec70      0x00000000

0x118, size (u64)
0xe814ec70 magic (u32)
0x0 pad (u32)

Well... all the talloc header seems fine to me.


> 0x1921270:      0x00000000      0x00000000      0x00000000      0x00000000
> 0x1921280:      0x0000001f      0x000000ff      0x0000ff00      0x000000ff
> 0x1921290:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212a0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212b0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212c0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212d0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212e0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
> 0x19212f0:      0x00000000      0x000000ff      0x0000ff00      0x000000ff
>
> So it appears to start at 0x1921270 or maybe ...6c.
>

It looks like that there is a pattern like

 0x00000000      0x000000ff      0x0000ff00      0x000000ff

only exceptions are when field is set after talloc_zero (fd, flags,
functions). Something like the memset inside the talloc_zero fill with
this pattern instead of zeroes. Note that a pattern of 16 bytes is
compatible with SSE instructions size. Some bug in the save/restore
for SSE registers? Some bug on SSE emulation?

What does "info all-registers" gdb command say about SSE registers?

Do we have a bug in Xen that affect SSE instructions (possibly already
fixed after Philipp version) ?

>>  I also don't understand where the
>> "fd = 47" came from a previous mail. 0x1f is 31, not 47 (which is
>> 0x2f).
>
> I must have been using a different coredump to the origianl report
> (there are several).
>
> In the one which corresponds to the above:
>
> (gdb) print *tdb
> $3 = {name = 0x0, map_ptr = 0x0, fd = 31, map_size = 255,
>   read_only = 65280, locked = 0xff00000000, ecode = 65280, header = {
>     magic_food = "\377\000\000\000\000\000\000\000\377\000\000\000\000\377\000\000\377\000\000\000\000\000\000\000\377\000\000\000\000\377\000", version = 255, hash_size = 0, rwlocks = 255, reserved = {65280,
>       255, 0, 255, 65280, 255, 0, 255, 65280, 255, 0, 255, 65280,
>       255, 0, 255, 65280, 255, 0, 255, 65280, 255, 0, 255, 65280,
>       255, 0, 255, 65280, 255, 0}}, flags = 0, travlocks = {
>     next = 0xff0000ff00, off = 0, hash = 255}, next = 0xff0000ff00,
>   device = 1095216660480, inode = 1095216725760,
>   log_fn = 0x4093b0 <null_log_fn>,
>   hash_fn = 0x4092f0 <default_tdb_hash>, open_flags = 2}
> (gdb) print/x *tdb
> $4 = {name = 0x0, map_ptr = 0x0, fd = 0x1f, map_size = 0xff,
>   read_only = 0xff00, locked = 0xff00000000, ecode = 0xff00,
>   header = {magic_food = {0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>       0xff, 0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0,
>       0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0},
>     version = 0xff, hash_size = 0x0, rwlocks = 0xff, reserved = {
>       0xff00, 0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 0xff, 0xff00,
>       0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 0xff, 0xff00, 0xff, 0x0,
>       0xff, 0xff00, 0xff, 0x0, 0xff, 0xff00, 0xff, 0x0, 0xff,
>       0xff00, 0xff, 0x0}}, flags = 0x0, travlocks = {
>     next = 0xff0000ff00, off = 0x0, hash = 0xff},
>   next = 0xff0000ff00, device = 0xff00000000, inode = 0xff0000ff00,
>   log_fn = 0x4093b0, hash_fn = 0x4092f0, open_flags = 0x2}
>
> which is consistent.
>
>> I would not be surprised about a strange bug in libc or the kernel.
>
> Or even Xen itself, or the h/w.
>
> Ian,
>

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 16:16:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0unL-0005bb-Fb; Tue, 16 Dec 2014 16:16: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 1Y0unJ-0005bQ-T1
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 16:16:18 +0000
Content-Length: 17510
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	43/C6-29352-1DA50945; Tue, 16 Dec 2014 16:16:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418746574!8384621!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9717 invoked from network); 16 Dec 2014 16:16:15 -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 Dec 2014 16:16:15 -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 sBGGE1MM004259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Dec 2014 16:14:02 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
	sBGGDwAD019845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 16 Dec 2014 16:13:59 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
	sBGGDuLA028294; Tue, 16 Dec 2014 16:13:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Dec 2014 08:13:56 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 504FA124EF2; Tue, 16 Dec 2014 11:13:52 -0500 (EST)
From: konrad.wilk@oracle.com
To: <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>,
	<tiejun.chen@intel.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>, <dario.faggioli@citrix.com>,
	<caobosimon@gmail.com>, <jgross@suse.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>,
	<Wei.Liu2@citrix.com>, <konrad.wilk@oracle.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>, <m.a.young@durham.ac.uk>, <mcgrof@suse.com>
Message-Id: <20141216161352.504FA124EF2@laptop.dumpdata.com>
Date: Tue, 16 Dec 2014 11:13:52 -0500 (EST)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0837419940347576829=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0837419940347576829==
Content-Length: 17697
Content-Transfer-Encoding: quoted-printable

Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
we have the General Release on Jan 7th!

Details for the test-day are at

http://wiki.xen.org/wiki/Xen_4.5_RC4_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

[ 'mmio_hole' fix it, but the ultimate way is to fix it in QEMU]

#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
#46 qemu-upstream: limitation on 4 emulated NICs prevents guest from starting unless PV override is used.

=3D Timeline =3D

We wer planning on a 9-month release cycle - but it is more like an
10 month.  Based on that, below are the estimated dates:


* Feature Freeze: 24th September 2014
* First RC: 24th October [Friday!]
* RC2: Nov 11th
* RC2 Test-day: Nov 13th
* RC3: Dec 3rd.
* RC3 Test-day: Dec 4th
* RC4: Dec 15th

<=3D=3D=3D=3D WE ARE HERE =3D=3D=3D>

* RC4 Test-day: Dec 17th

 Release Date: Jan 7th.

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.

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 Bug Fixes =3D

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.

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 

=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

=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 

*  xc_reserved_device_memory_map in hvmloader to avoid conflicting MMIO/RAM (good)
   v7 posted.
   Treating pieces as bug-fixes only.
   Low likehood of making it in Xen 4.5. Deferred
  -  Tiejun Chen

*  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

*  HT enabled with credit has 7.9 per perf drop. (none)
   kernbench demonstrated it
   http://www.gossamer-threads.com/lists/xen/devel/339409
   This has existed since credit1 introduction.
  -  Dario Faggioli

=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

*  ucode=3Dscan also scan compressed initramfs (none)
  -  Konrad Rzeszutek Wilk

*  adjust log buffer based on memmap size (none)
  -  Konrad Rzeszutek Wilk

=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 

*  Regression in PCI passthrough of INTx legacy devices can trigger list corruption (good)
   Sander reported it. Two different types of patches available.
  -  Konrad Rzeszutek Wilk

*  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 

*  pygrub does not handle certain configurations. (done)
   went in after RC3
  -  Andrew Cooper and Boris Ostrovsky

*  regression libxl bitmap handling during a restore.
  -  Boris Ostrovsky and Wei Liu
  -  done

*  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

*  vAPIC in PVHVM guests (Linux side) (done)
   Going in for 3.19
  -  Boris Ostrovsky



--===============0837419940347576829==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0837419940347576829==--

From xen-devel-bounces@lists.xen.org Tue Dec 16 16:16:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0unL-0005bb-Fb; Tue, 16 Dec 2014 16:16: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 1Y0unJ-0005bQ-T1
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 16:16:18 +0000
Content-Length: 17510
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	43/C6-29352-1DA50945; Tue, 16 Dec 2014 16:16:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418746574!8384621!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9717 invoked from network); 16 Dec 2014 16:16:15 -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 Dec 2014 16:16:15 -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 sBGGE1MM004259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Dec 2014 16:14:02 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
	sBGGDwAD019845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 16 Dec 2014 16:13:59 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
	sBGGDuLA028294; Tue, 16 Dec 2014 16:13:56 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Dec 2014 08:13:56 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 504FA124EF2; Tue, 16 Dec 2014 11:13:52 -0500 (EST)
From: konrad.wilk@oracle.com
To: <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>,
	<tiejun.chen@intel.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>, <dario.faggioli@citrix.com>,
	<caobosimon@gmail.com>, <jgross@suse.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>,
	<Wei.Liu2@citrix.com>, <konrad.wilk@oracle.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>, <m.a.young@durham.ac.uk>, <mcgrof@suse.com>
Message-Id: <20141216161352.504FA124EF2@laptop.dumpdata.com>
Date: Tue, 16 Dec 2014 11:13:52 -0500 (EST)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0837419940347576829=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0837419940347576829==
Content-Length: 17697
Content-Transfer-Encoding: quoted-printable

Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
we have the General Release on Jan 7th!

Details for the test-day are at

http://wiki.xen.org/wiki/Xen_4.5_RC4_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

[ 'mmio_hole' fix it, but the ultimate way is to fix it in QEMU]

#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
#46 qemu-upstream: limitation on 4 emulated NICs prevents guest from starting unless PV override is used.

=3D Timeline =3D

We wer planning on a 9-month release cycle - but it is more like an
10 month.  Based on that, below are the estimated dates:


* Feature Freeze: 24th September 2014
* First RC: 24th October [Friday!]
* RC2: Nov 11th
* RC2 Test-day: Nov 13th
* RC3: Dec 3rd.
* RC3 Test-day: Dec 4th
* RC4: Dec 15th

<=3D=3D=3D=3D WE ARE HERE =3D=3D=3D>

* RC4 Test-day: Dec 17th

 Release Date: Jan 7th.

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.

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 Bug Fixes =3D

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.

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 

=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

=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 

*  xc_reserved_device_memory_map in hvmloader to avoid conflicting MMIO/RAM (good)
   v7 posted.
   Treating pieces as bug-fixes only.
   Low likehood of making it in Xen 4.5. Deferred
  -  Tiejun Chen

*  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

*  HT enabled with credit has 7.9 per perf drop. (none)
   kernbench demonstrated it
   http://www.gossamer-threads.com/lists/xen/devel/339409
   This has existed since credit1 introduction.
  -  Dario Faggioli

=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

*  ucode=3Dscan also scan compressed initramfs (none)
  -  Konrad Rzeszutek Wilk

*  adjust log buffer based on memmap size (none)
  -  Konrad Rzeszutek Wilk

=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 

*  Regression in PCI passthrough of INTx legacy devices can trigger list corruption (good)
   Sander reported it. Two different types of patches available.
  -  Konrad Rzeszutek Wilk

*  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 

*  pygrub does not handle certain configurations. (done)
   went in after RC3
  -  Andrew Cooper and Boris Ostrovsky

*  regression libxl bitmap handling during a restore.
  -  Boris Ostrovsky and Wei Liu
  -  done

*  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

*  vAPIC in PVHVM guests (Linux side) (done)
   Going in for 3.19
  -  Boris Ostrovsky



--===============0837419940347576829==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0837419940347576829==--

From xen-devel-bounces@lists.xen.org Tue Dec 16 16:21:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16: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 1Y0us3-0005mb-6m; Tue, 16 Dec 2014 16:21: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 1Y0us1-0005mW-Db
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 16:21:09 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	90/CF-03145-4FB50945; Tue, 16 Dec 2014 16:21:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418746867!15412580!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_50_75
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3890 invoked from network); 16 Dec 2014 16:21: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; 16 Dec 2014 16:21:08 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 11DB8AB09;
	Tue, 16 Dec 2014 16:21:07 +0000 (UTC)
Message-ID: <54905BF1.2050608@suse.com>
Date: Tue, 16 Dec 2014 17:21:05 +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>, 
	David Vrabel <david.vrabel@citrix.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, 
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] Xen's Linux kernel config options 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: 7bit
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,

This is a design proposal for a rework of the config options on the
Linux kernel which are related to Xen.

The need to do so arose from the fact that it is currently not
possible to build the Xen frontend drivers for a non-pvops kernel,
e.g. to run them in a HVM-domain. There are more drawbacks in the
current config options to which I'll come later.

Current Xen related config options are as follows:

Option                          Selects                 Depends
---------------------------------------------------------------------
XEN                             PARAVIRT_CLOCK(x86)     PARAVIRT(x86)
                                 XEN_HAVE_PVMMU(x86)
                                 SWIOTLB_XEN(arm,arm64)
   PCI_XEN(x86)                  SWIOTLB_XEN
   XEN_DOM0                                              PCI_XEN(x86)
     XEN_BACKEND
       XEN_BLKDEV_BACKEND
       XEN_PCIDEV_BACKEND(x86)
       XEN_SCSI_BACKEND
       XEN_NETDEV_BACKEND
     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
     XEN_MCE_LOG(x86)
   XEN_PVHVM(x86)
     XEN_PVH(x86)
   XEN_MAX_DOMAIN_MEMORY(x86)
   XEN_SAVE_RESTORE(x86)
   XEN_DEBUG_FS(x86)
   XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
                                 INPUT_XEN_KBDDEV_FRONTEND
   XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
   HVC_XEN
     HVC_XEN_FRONTEND            XEN_XENBUS_FRONTEND
   TCG_XEN                       XEN_XENBUS_FRONTEND
   XEN_PCIDEV_FRONTEND           PCI_XEN
                                 XEN_XENBUS_FRONTEND
   XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
   INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
   XEN_WDT
   XEN_BALLOON
     XEN_SELFBALLOONING                                  XEN_TMEM
     XEN_BALLOON_MEMORY_HOTPLUG
     XEN_SCRUB_PAGES
   XEN_DEV_EVTCHN
   XENFS                         XEN_PRIVCMD
     XEN_COMPAT_XENFS
   XEN_SYS_HYPERVISOR
   XEN_XENBUS_FRONTEND
   XEN_GNTDEV
   XEN_GRANT_DEV_ALLOC
   SWIOTLB_XEN
   XEN_TMEM(x86)
   XEN_PRIVCMD
   XEN_STUB(x86_64)                                      BROKEN
   XEN_ACPI_PROCESSOR(x86)
   XEN_HAVE_PVMMU
   XEN_EFI(x64)
   XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND

Legend:
- The first column are the Xen config options. Indentation in this
   column reflects the dependency between those options (e.g.
   XEN_SCSI_BACKEND depends on XEN_BACKEND, which in turn depends on
   XEN_DOM0, which depends on XEN).
- The second column shows the options which are selected automatically
   if the corresponding option in the first column is configured.
- The last column shows additional dependencies which can't be shown via
   the indentation level of the first column.
- Some options or dependencies are architecture specific, they are
   listed in brackets (e.g. XEN_TMEM which is available for x86 only).
- Non-Xen options are mentioned only if they seem to be really relevant,
   like e.g. PARAVIRT or BROKEN.

There are several reasons to change the config options:
- Be able to build Xen frontend drivers for HVM domains without the need
   for choosing a pvops kernel: currently the frontend drivers need XEN
   configured which depends on PARAVIRT.
- Be able to build a Dom0 using XEN_PVH without having to configure
   XEN_HAVE_PVMMU.
- Be able to build HVM driver domains.
- Some features are available for x86 only, in spite of being not
   architecture specific, e.g. XEN_DEBUG_FS or XEN_TMEM.

After some feedback for the first draft I'd suggest the following:

Option                          Selects                 Depends
----------------------------------------------------------------------
XEN
   XEN_PV(x86)                   XEN_HAVE_PVMMU
                                 PARAVIRT
                                 PARAVIRT_CLOCK
   XEN_PVH(x86)                  XEN_PVHVM
                                 PARAVIRT
                                 PARAVIRT_CLOCK
   XEN_PVHVM                     PARAVIRT
                                 PARAVIRT_CLOCK
   XEN_BACKEND                   SWIOTLB_XEN(arm,arm64)  XEN_PV(x86) ||
                                                         XEN_PVH(x86) ||
                                                         XEN_PVHVM
     XEN_BLKDEV_BACKEND
     XEN_PCIDEV_BACKEND(x86)
     XEN_SCSI_BACKEND
     XEN_NETDEV_BACKEND
   PCI_XEN(x86)                  SWIOTLB_XEN
   XEN_DOM0                      XEN_BACKEND             XEN_PV(x86) ||
                                 PCI_XEN(x86)            XEN_PVH(x86)
     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
     XEN_MCE_LOG(x86)
   XEN_MAX_DOMAIN_MEMORY(x86)
   XEN_SAVE_RESTORE(x86)
   XEN_DEBUG_FS
   XEN_WDT
   XEN_BALLOON
     XEN_SELFBALLOONING                                  XEN_TMEM
     XEN_BALLOON_MEMORY_HOTPLUG
     XEN_SCRUB_PAGES
   XENFS                         XEN_PRIVCMD
     XEN_COMPAT_XENFS
   XEN_SYS_HYPERVISOR
   XEN_DEV_EVTCHN
   XEN_GNTDEV
   XEN_GRANT_DEV_ALLOC
   SWIOTLB_XEN
   XEN_TMEM
   XEN_PRIVCMD
   XEN_STUB(x86_64)                                      BROKEN
   XEN_ACPI_PROCESSOR(x86)
   XEN_HAVE_PVMMU
   XEN_EFI(x64)
   XEN_XENBUS_FRONTEND
XEN_FRONTEND                    XEN
                                 XEN_XENBUS_FRONTEND
   XEN_FBDEV_FRONTEND            INPUT_XEN_KBDDEV_FRONTEND
   XEN_BLKDEV_FRONTEND
   HVC_XEN_FRONTEND              HVC_XEN
   TCG_XEN
   XEN_PCIDEV_FRONTEND           PCI_XEN
   XEN_SCSI_FRONTEND
   INPUT_XEN_KBDDEV_FRONTEND
   XEN_NETDEV_FRONTEND
   XEN_PLATFORM_PCI

The main difference to the current status is the XEN setting no longer
controlling all other options.

Changing the config options in this way surely will need some
adjustments in the drivers, but this can be discussed when we agree
on the future config dependencies.


Changes in V2:
- XEN doesn't select SWIOTLB_XEN on arm, this is done by XEN_BACKEND now
   (David Vrabel and Stefano Stabellini)
- XEN_PVHVM now under XEN, selects PARAVIRT and PARAVIRT_CLOCK (David)
- XEN_FRONTEND independent from any XEN_* variant, selects XEN and
   XEN_XENBUS_FRONTEND (David, Juergen)
- added XEN_PLATFORM_PCI (David)

Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 16:21:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16: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 1Y0us3-0005mb-6m; Tue, 16 Dec 2014 16:21: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 1Y0us1-0005mW-Db
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 16:21:09 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	90/CF-03145-4FB50945; Tue, 16 Dec 2014 16:21:08 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418746867!15412580!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_50_75
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3890 invoked from network); 16 Dec 2014 16:21: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; 16 Dec 2014 16:21:08 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 11DB8AB09;
	Tue, 16 Dec 2014 16:21:07 +0000 (UTC)
Message-ID: <54905BF1.2050608@suse.com>
Date: Tue, 16 Dec 2014 17:21:05 +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>, 
	David Vrabel <david.vrabel@citrix.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, 
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] Xen's Linux kernel config options 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: 7bit
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,

This is a design proposal for a rework of the config options on the
Linux kernel which are related to Xen.

The need to do so arose from the fact that it is currently not
possible to build the Xen frontend drivers for a non-pvops kernel,
e.g. to run them in a HVM-domain. There are more drawbacks in the
current config options to which I'll come later.

Current Xen related config options are as follows:

Option                          Selects                 Depends
---------------------------------------------------------------------
XEN                             PARAVIRT_CLOCK(x86)     PARAVIRT(x86)
                                 XEN_HAVE_PVMMU(x86)
                                 SWIOTLB_XEN(arm,arm64)
   PCI_XEN(x86)                  SWIOTLB_XEN
   XEN_DOM0                                              PCI_XEN(x86)
     XEN_BACKEND
       XEN_BLKDEV_BACKEND
       XEN_PCIDEV_BACKEND(x86)
       XEN_SCSI_BACKEND
       XEN_NETDEV_BACKEND
     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
     XEN_MCE_LOG(x86)
   XEN_PVHVM(x86)
     XEN_PVH(x86)
   XEN_MAX_DOMAIN_MEMORY(x86)
   XEN_SAVE_RESTORE(x86)
   XEN_DEBUG_FS(x86)
   XEN_FBDEV_FRONTEND            XEN_XENBUS_FRONTEND
                                 INPUT_XEN_KBDDEV_FRONTEND
   XEN_BLKDEV_FRONTEND           XEN_XENBUS_FRONTEND
   HVC_XEN
     HVC_XEN_FRONTEND            XEN_XENBUS_FRONTEND
   TCG_XEN                       XEN_XENBUS_FRONTEND
   XEN_PCIDEV_FRONTEND           PCI_XEN
                                 XEN_XENBUS_FRONTEND
   XEN_SCSI_FRONTEND             XEN_XENBUS_FRONTEND
   INPUT_XEN_KBDDEV_FRONTEND     XEN_XENBUS_FRONTEND
   XEN_WDT
   XEN_BALLOON
     XEN_SELFBALLOONING                                  XEN_TMEM
     XEN_BALLOON_MEMORY_HOTPLUG
     XEN_SCRUB_PAGES
   XEN_DEV_EVTCHN
   XENFS                         XEN_PRIVCMD
     XEN_COMPAT_XENFS
   XEN_SYS_HYPERVISOR
   XEN_XENBUS_FRONTEND
   XEN_GNTDEV
   XEN_GRANT_DEV_ALLOC
   SWIOTLB_XEN
   XEN_TMEM(x86)
   XEN_PRIVCMD
   XEN_STUB(x86_64)                                      BROKEN
   XEN_ACPI_PROCESSOR(x86)
   XEN_HAVE_PVMMU
   XEN_EFI(x64)
   XEN_NETDEV_FRONTEND           XEN_XENBUS_FRONTEND

Legend:
- The first column are the Xen config options. Indentation in this
   column reflects the dependency between those options (e.g.
   XEN_SCSI_BACKEND depends on XEN_BACKEND, which in turn depends on
   XEN_DOM0, which depends on XEN).
- The second column shows the options which are selected automatically
   if the corresponding option in the first column is configured.
- The last column shows additional dependencies which can't be shown via
   the indentation level of the first column.
- Some options or dependencies are architecture specific, they are
   listed in brackets (e.g. XEN_TMEM which is available for x86 only).
- Non-Xen options are mentioned only if they seem to be really relevant,
   like e.g. PARAVIRT or BROKEN.

There are several reasons to change the config options:
- Be able to build Xen frontend drivers for HVM domains without the need
   for choosing a pvops kernel: currently the frontend drivers need XEN
   configured which depends on PARAVIRT.
- Be able to build a Dom0 using XEN_PVH without having to configure
   XEN_HAVE_PVMMU.
- Be able to build HVM driver domains.
- Some features are available for x86 only, in spite of being not
   architecture specific, e.g. XEN_DEBUG_FS or XEN_TMEM.

After some feedback for the first draft I'd suggest the following:

Option                          Selects                 Depends
----------------------------------------------------------------------
XEN
   XEN_PV(x86)                   XEN_HAVE_PVMMU
                                 PARAVIRT
                                 PARAVIRT_CLOCK
   XEN_PVH(x86)                  XEN_PVHVM
                                 PARAVIRT
                                 PARAVIRT_CLOCK
   XEN_PVHVM                     PARAVIRT
                                 PARAVIRT_CLOCK
   XEN_BACKEND                   SWIOTLB_XEN(arm,arm64)  XEN_PV(x86) ||
                                                         XEN_PVH(x86) ||
                                                         XEN_PVHVM
     XEN_BLKDEV_BACKEND
     XEN_PCIDEV_BACKEND(x86)
     XEN_SCSI_BACKEND
     XEN_NETDEV_BACKEND
   PCI_XEN(x86)                  SWIOTLB_XEN
   XEN_DOM0                      XEN_BACKEND             XEN_PV(x86) ||
                                 PCI_XEN(x86)            XEN_PVH(x86)
     XEN_ACPI_HOTPLUG_MEMORY                             XEN_STUB
     XEN_ACPI_HOTPLUG_CPU                                XEN_STUB
     XEN_MCE_LOG(x86)
   XEN_MAX_DOMAIN_MEMORY(x86)
   XEN_SAVE_RESTORE(x86)
   XEN_DEBUG_FS
   XEN_WDT
   XEN_BALLOON
     XEN_SELFBALLOONING                                  XEN_TMEM
     XEN_BALLOON_MEMORY_HOTPLUG
     XEN_SCRUB_PAGES
   XENFS                         XEN_PRIVCMD
     XEN_COMPAT_XENFS
   XEN_SYS_HYPERVISOR
   XEN_DEV_EVTCHN
   XEN_GNTDEV
   XEN_GRANT_DEV_ALLOC
   SWIOTLB_XEN
   XEN_TMEM
   XEN_PRIVCMD
   XEN_STUB(x86_64)                                      BROKEN
   XEN_ACPI_PROCESSOR(x86)
   XEN_HAVE_PVMMU
   XEN_EFI(x64)
   XEN_XENBUS_FRONTEND
XEN_FRONTEND                    XEN
                                 XEN_XENBUS_FRONTEND
   XEN_FBDEV_FRONTEND            INPUT_XEN_KBDDEV_FRONTEND
   XEN_BLKDEV_FRONTEND
   HVC_XEN_FRONTEND              HVC_XEN
   TCG_XEN
   XEN_PCIDEV_FRONTEND           PCI_XEN
   XEN_SCSI_FRONTEND
   INPUT_XEN_KBDDEV_FRONTEND
   XEN_NETDEV_FRONTEND
   XEN_PLATFORM_PCI

The main difference to the current status is the XEN setting no longer
controlling all other options.

Changing the config options in this way surely will need some
adjustments in the drivers, but this can be discussed when we agree
on the future config dependencies.


Changes in V2:
- XEN doesn't select SWIOTLB_XEN on arm, this is done by XEN_BACKEND now
   (David Vrabel and Stefano Stabellini)
- XEN_PVHVM now under XEN, selects PARAVIRT and PARAVIRT_CLOCK (David)
- XEN_FRONTEND independent from any XEN_* variant, selects XEN and
   XEN_XENBUS_FRONTEND (David, Juergen)
- added XEN_PLATFORM_PCI (David)

Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 16:23:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16: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 1Y0uuh-00064l-Or; Tue, 16 Dec 2014 16:23: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 1Y0uug-00064e-3o
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 16:23:54 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	17/85-02953-99C50945; Tue, 16 Dec 2014 16:23:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418747031!12119744!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 31931 invoked from network); 16 Dec 2014 16:23:52 -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;
	16 Dec 2014 16:23:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204968835"
Message-ID: <1418747029.16425.238.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <freddy77@gmail.com>
Date: Tue, 16 Dec 2014 16:23:49 +0000
In-Reply-To: <CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Philipp Hahn <hahn@univention.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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 Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
> What does "info all-registers" gdb command say about SSE registers?

All zeroes. No ffs anywhere.

> Do we have a bug in Xen that affect SSE instructions (possibly already
> fixed after Philipp version) ?

Possibly. When this was thought to be xenstored (which doesn't change
all that much) debugging 4.1 seemed plausible, but since it could be
anywhere else I think we either need a plausible reproduction, or a
repro on a newer hypervisor (or possibly kernel) I'm afraid.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 16:23:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16: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 1Y0uuh-00064l-Or; Tue, 16 Dec 2014 16:23: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 1Y0uug-00064e-3o
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 16:23:54 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	17/85-02953-99C50945; Tue, 16 Dec 2014 16:23:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418747031!12119744!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 31931 invoked from network); 16 Dec 2014 16:23:52 -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;
	16 Dec 2014 16:23:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204968835"
Message-ID: <1418747029.16425.238.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <freddy77@gmail.com>
Date: Tue, 16 Dec 2014 16:23:49 +0000
In-Reply-To: <CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Philipp Hahn <hahn@univention.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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 Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
> What does "info all-registers" gdb command say about SSE registers?

All zeroes. No ffs anywhere.

> Do we have a bug in Xen that affect SSE instructions (possibly already
> fixed after Philipp version) ?

Possibly. When this was thought to be xenstored (which doesn't change
all that much) debugging 4.1 seemed plausible, but since it could be
anywhere else I think we either need a plausible reproduction, or a
repro on a newer hypervisor (or possibly kernel) I'm afraid.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 16:35:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16: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 1Y0v5P-0006U1-3q; Tue, 16 Dec 2014 16:34:59 +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 1Y0v5N-0006Tw-PJ
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 16:34:58 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	00/46-15461-13F50945; Tue, 16 Dec 2014 16:34:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418747696!15984132!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6875 invoked from network); 16 Dec 2014 16:34:56 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 16:34:56 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418747696; l=261;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=mSCdtb/oSoVq80ToBzROC7Z9Etg=;
	b=XG0HcsOni9gEonLEOpIsN0KHxgCYYCYxrPa92AcbpkAwYbHmOCnv+YatOjNcIDOR80N
	iO6L71x31t7vTfV6MdoXlPJD5Rq3mF7oOGTlrFN/xnd0PK+EK7ES79o1Xq5lmeTvd2eQw
	00EAUNcX00wyrx/teVFLzoiSAujLYLbTaDk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id K05c87qBGGYqvpd
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 16 Dec 2014 17:34:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0885B50161; Tue, 16 Dec 2014 17:34:51 +0100 (CET)
Date: Tue, 16 Dec 2014 17:34:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: konrad.wilk@oracle.com
Message-ID: <20141216163451.GA18976@aepfle.de>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141216161352.504FA124EF2@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, konrad.wilk@oracle.com wrote:

> In terms of bugs, we have:

... systemd SELinux, but its not listed.

Whats your plan with the failures you see? Should I continue to be
concerned about that, or will all the be postponed to 4.6?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 16:35:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16: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 1Y0v5P-0006U1-3q; Tue, 16 Dec 2014 16:34:59 +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 1Y0v5N-0006Tw-PJ
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 16:34:58 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	00/46-15461-13F50945; Tue, 16 Dec 2014 16:34:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418747696!15984132!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6875 invoked from network); 16 Dec 2014 16:34:56 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 16:34:56 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418747696; l=261;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=mSCdtb/oSoVq80ToBzROC7Z9Etg=;
	b=XG0HcsOni9gEonLEOpIsN0KHxgCYYCYxrPa92AcbpkAwYbHmOCnv+YatOjNcIDOR80N
	iO6L71x31t7vTfV6MdoXlPJD5Rq3mF7oOGTlrFN/xnd0PK+EK7ES79o1Xq5lmeTvd2eQw
	00EAUNcX00wyrx/teVFLzoiSAujLYLbTaDk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id K05c87qBGGYqvpd
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Tue, 16 Dec 2014 17:34:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0885B50161; Tue, 16 Dec 2014 17:34:51 +0100 (CET)
Date: Tue, 16 Dec 2014 17:34:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: konrad.wilk@oracle.com
Message-ID: <20141216163451.GA18976@aepfle.de>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141216161352.504FA124EF2@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, konrad.wilk@oracle.com wrote:

> In terms of bugs, we have:

... systemd SELinux, but its not listed.

Whats your plan with the failures you see? Should I continue to be
concerned about that, or will all the be postponed to 4.6?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 16:44:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16:44:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0vEO-0006kB-54; Tue, 16 Dec 2014 16:44:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <freddy77@gmail.com>) id 1Y0vEM-0006k6-JR
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 16:44:14 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	4B/2C-02699-D5160945; Tue, 16 Dec 2014 16:44:13 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418748252!15474510!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23664 invoked from network); 16 Dec 2014 16:44:13 -0000
Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com)
	(209.85.220.169)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 16:44:13 -0000
Received: by mail-vc0-f169.google.com with SMTP id hy10so6726754vcb.0
	for <Xen-devel@lists.xen.org>; Tue, 16 Dec 2014 08:44:11 -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=+FvCVQ2mQOgeKpiN9w02IihJUnaqLdsGMyZQZXf/sAc=;
	b=fzAMbc1xUL3+wwEdks1HsVmdu+junIvd0BNWXUCU8qWGsMB/obuNLSv1ZV459bP/3b
	7oO2R5ryQUZG5sMGFjLI0dsSYLdxF3+pFwvFZ4/twqNIqOPhapKvmzQxOq0N+0iczSFz
	hMtVR3NC6qzRKxNeuE7Dvl9o4LU0Br0L5+tZlpOZMJJPlNiFVMJ+lKU+7AB6Ki5CggFP
	6+SsmhLKw5PcYdSPlYwwxBowSLxmOs5FU5LUBtJUTtqEd+LHndNpui/PGLMKxrG86Pd/
	v6gZnmeglcYHdVl9tc3IrgXfYfejy7dqRGGlYOvYsR8IVcVTUAKiMbWFQmjL727Y6a4g
	dDMA==
MIME-Version: 1.0
X-Received: by 10.220.178.3 with SMTP id bk3mr15806195vcb.16.1418748251863;
	Tue, 16 Dec 2014 08:44:11 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Tue, 16 Dec 2014 08:44:11 -0800 (PST)
In-Reply-To: <1418747029.16425.238.camel@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418747029.16425.238.camel@citrix.com>
Date: Tue, 16 Dec 2014 16:44:11 +0000
Message-ID: <CAHt6W4e6mR4cX1MfpJ+drupzzRHjf0SHaJ=y5QRZxh84mq5rBA@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Philipp Hahn <hahn@univention.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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

2014-12-16 16:23 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
> On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
>> What does "info all-registers" gdb command say about SSE registers?
>
> All zeroes. No ffs anywhere.
>

Could be that core does not dump these registers for some reasons? On
my machine I got some FFs even just before the main is reached.

>> Do we have a bug in Xen that affect SSE instructions (possibly already
>> fixed after Philipp version) ?
>
> Possibly. When this was thought to be xenstored (which doesn't change
> all that much) debugging 4.1 seemed plausible, but since it could be
> anywhere else I think we either need a plausible reproduction, or a
> repro on a newer hypervisor (or possibly kernel) I'm afraid.
>
> Ian.
>

I found these

1) https://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.2.8
2) https://sourceware.org/bugzilla/show_bug.cgi?id=16064

1 seems to indicate a problem with kernel 3.2. Second with glibc 2.18.

First we (I'll try when I reach home) can check if memset in glibc (or
the version called from talloc_zero) can use SSE. A possible dmesg
output and /proc/cpuinfo content could help too but I think SSE are
now quite common.

For the reproduction could be that a program doing some memset(0)
continuously while another fill SSE register with garbage could
help... at least if they execute on the same CPU (so could be limiting
Xen to one CPU). Also doing some FPU operation which could lead to
exception could help too.

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 16:44:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16:44:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0vEO-0006kB-54; Tue, 16 Dec 2014 16:44:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <freddy77@gmail.com>) id 1Y0vEM-0006k6-JR
	for Xen-devel@lists.xen.org; Tue, 16 Dec 2014 16:44:14 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	4B/2C-02699-D5160945; Tue, 16 Dec 2014 16:44:13 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418748252!15474510!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23664 invoked from network); 16 Dec 2014 16:44:13 -0000
Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com)
	(209.85.220.169)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 16:44:13 -0000
Received: by mail-vc0-f169.google.com with SMTP id hy10so6726754vcb.0
	for <Xen-devel@lists.xen.org>; Tue, 16 Dec 2014 08:44:11 -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=+FvCVQ2mQOgeKpiN9w02IihJUnaqLdsGMyZQZXf/sAc=;
	b=fzAMbc1xUL3+wwEdks1HsVmdu+junIvd0BNWXUCU8qWGsMB/obuNLSv1ZV459bP/3b
	7oO2R5ryQUZG5sMGFjLI0dsSYLdxF3+pFwvFZ4/twqNIqOPhapKvmzQxOq0N+0iczSFz
	hMtVR3NC6qzRKxNeuE7Dvl9o4LU0Br0L5+tZlpOZMJJPlNiFVMJ+lKU+7AB6Ki5CggFP
	6+SsmhLKw5PcYdSPlYwwxBowSLxmOs5FU5LUBtJUTtqEd+LHndNpui/PGLMKxrG86Pd/
	v6gZnmeglcYHdVl9tc3IrgXfYfejy7dqRGGlYOvYsR8IVcVTUAKiMbWFQmjL727Y6a4g
	dDMA==
MIME-Version: 1.0
X-Received: by 10.220.178.3 with SMTP id bk3mr15806195vcb.16.1418748251863;
	Tue, 16 Dec 2014 08:44:11 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Tue, 16 Dec 2014 08:44:11 -0800 (PST)
In-Reply-To: <1418747029.16425.238.camel@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418747029.16425.238.camel@citrix.com>
Date: Tue, 16 Dec 2014 16:44:11 +0000
Message-ID: <CAHt6W4e6mR4cX1MfpJ+drupzzRHjf0SHaJ=y5QRZxh84mq5rBA@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Philipp Hahn <hahn@univention.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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

2014-12-16 16:23 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
> On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
>> What does "info all-registers" gdb command say about SSE registers?
>
> All zeroes. No ffs anywhere.
>

Could be that core does not dump these registers for some reasons? On
my machine I got some FFs even just before the main is reached.

>> Do we have a bug in Xen that affect SSE instructions (possibly already
>> fixed after Philipp version) ?
>
> Possibly. When this was thought to be xenstored (which doesn't change
> all that much) debugging 4.1 seemed plausible, but since it could be
> anywhere else I think we either need a plausible reproduction, or a
> repro on a newer hypervisor (or possibly kernel) I'm afraid.
>
> Ian.
>

I found these

1) https://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.2.8
2) https://sourceware.org/bugzilla/show_bug.cgi?id=16064

1 seems to indicate a problem with kernel 3.2. Second with glibc 2.18.

First we (I'll try when I reach home) can check if memset in glibc (or
the version called from talloc_zero) can use SSE. A possible dmesg
output and /proc/cpuinfo content could help too but I think SSE are
now quite common.

For the reproduction could be that a program doing some memset(0)
continuously while another fill SSE register with garbage could
help... at least if they execute on the same CPU (so could be limiting
Xen to one CPU). Also doing some FPU operation which could lead to
exception could help too.

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 16:45:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 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 1Y0vFj-0006oU-LN; Tue, 16 Dec 2014 16:45: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 1Y0vFh-0006oL-TZ
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 16:45:38 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	EE/67-15461-1B160945; Tue, 16 Dec 2014 16:45:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418748335!15986591!1
X-Originating-IP: [66.165.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 22239 invoked from network); 16 Dec 2014 16:45:36 -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;
	16 Dec 2014 16:45:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="205442899"
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.210.2; Tue, 16 Dec 2014 11:45: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 1Y0vFd-0000Vz-Bq;
	Tue, 16 Dec 2014 16:45:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0vFd-0000BT-5j;
	Tue, 16 Dec 2014 16:45:33 +0000
Date: Tue, 16 Dec 2014 16:45:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32390-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] 32390: 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 32390 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32390/

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  5 xen-boot            fail pass in 32359
 test-amd64-amd64-xl-sedf      9 guest-start        fail in 32359 pass in 32390
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot      fail in 32359 pass in 32390

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen       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

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-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     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-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-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-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-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 14 guest-stop                fail never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                                      broken  
 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                           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                             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

broken-step build-amd64-rumpuserxen host-install(3)

Not pushing.

(No revision log; it would be 34178 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 Dec 16 16:45:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 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 1Y0vFj-0006oU-LN; Tue, 16 Dec 2014 16:45: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 1Y0vFh-0006oL-TZ
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 16:45:38 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	EE/67-15461-1B160945; Tue, 16 Dec 2014 16:45:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418748335!15986591!1
X-Originating-IP: [66.165.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 22239 invoked from network); 16 Dec 2014 16:45:36 -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;
	16 Dec 2014 16:45:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="205442899"
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.210.2; Tue, 16 Dec 2014 11:45: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 1Y0vFd-0000Vz-Bq;
	Tue, 16 Dec 2014 16:45:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0vFd-0000BT-5j;
	Tue, 16 Dec 2014 16:45:33 +0000
Date: Tue, 16 Dec 2014 16:45:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32390-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] 32390: 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 32390 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32390/

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  5 xen-boot            fail pass in 32359
 test-amd64-amd64-xl-sedf      9 guest-start        fail in 32359 pass in 32390
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot      fail in 32359 pass in 32390

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen       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

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-amd64-rumpuserxen-amd64  1 build-check(1)               blocked n/a
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-armhf-armhf-xl           5 xen-boot                     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-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-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-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-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 14 guest-stop                fail never pass

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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                                      broken  
 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                           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                             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

broken-step build-amd64-rumpuserxen host-install(3)

Not pushing.

(No revision log; it would be 34178 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 Dec 16 16:48:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16: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 1Y0vIU-0006yq-78; Tue, 16 Dec 2014 16:48:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0vIS-0006yj-N4
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 16:48:28 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	5D/13-24124-C5260945; Tue, 16 Dec 2014 16:48:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418748505!13667180!1
X-Originating-IP: [66.165.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 27622 invoked from network); 16 Dec 2014 16:48:27 -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;
	16 Dec 2014 16:48:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204981589"
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.210.2; Tue, 16 Dec 2014 11:48: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 1Y0vIO-0000Wv-4M;
	Tue, 16 Dec 2014 16:48:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0vIN-0000bd-Vd;
	Tue, 16 Dec 2014 16:48:23 +0000
Date: Tue, 16 Dec 2014 16:48:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32414-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] 32414: 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 32414 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32414/

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              a93a3b975cd0bad37ccae508d9b7a69aa72b6181
baseline version:
 libvirt              c5a54917d5ae97653d29dbfe4995f2efcf5717d6

------------------------------------------------------------
People who touched revisions under test:
  Daniel P. Berrange <berrange@redhat.com>
  Dmitry Guryanov <dguryanov@parallels.com>
  Erik Skultety <eskultet@redhat.com>
  Laine Stump <laine@laine.org>
  Luyao Huang <lhuang@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Wang Rui <moon.wangrui@huawei.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-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=a93a3b975cd0bad37ccae508d9b7a69aa72b6181
+ . 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 a93a3b975cd0bad37ccae508d9b7a69aa72b6181
+ branch=libvirt
+ revision=a93a3b975cd0bad37ccae508d9b7a69aa72b6181
+ . 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 a93a3b975cd0bad37ccae508d9b7a69aa72b6181:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   c5a5491..a93a3b9  a93a3b975cd0bad37ccae508d9b7a69aa72b6181 -> 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 Dec 16 16:48:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 16: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 1Y0vIU-0006yq-78; Tue, 16 Dec 2014 16:48:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0vIS-0006yj-N4
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 16:48:28 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	5D/13-24124-C5260945; Tue, 16 Dec 2014 16:48:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418748505!13667180!1
X-Originating-IP: [66.165.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 27622 invoked from network); 16 Dec 2014 16:48:27 -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;
	16 Dec 2014 16:48:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204981589"
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.210.2; Tue, 16 Dec 2014 11:48: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 1Y0vIO-0000Wv-4M;
	Tue, 16 Dec 2014 16:48:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0vIN-0000bd-Vd;
	Tue, 16 Dec 2014 16:48:23 +0000
Date: Tue, 16 Dec 2014 16:48:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32414-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] 32414: 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 32414 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32414/

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              a93a3b975cd0bad37ccae508d9b7a69aa72b6181
baseline version:
 libvirt              c5a54917d5ae97653d29dbfe4995f2efcf5717d6

------------------------------------------------------------
People who touched revisions under test:
  Daniel P. Berrange <berrange@redhat.com>
  Dmitry Guryanov <dguryanov@parallels.com>
  Erik Skultety <eskultet@redhat.com>
  Laine Stump <laine@laine.org>
  Luyao Huang <lhuang@redhat.com>
  Michal Privoznik <mprivozn@redhat.com>
  Wang Rui <moon.wangrui@huawei.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-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=a93a3b975cd0bad37ccae508d9b7a69aa72b6181
+ . 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 a93a3b975cd0bad37ccae508d9b7a69aa72b6181
+ branch=libvirt
+ revision=a93a3b975cd0bad37ccae508d9b7a69aa72b6181
+ . 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 a93a3b975cd0bad37ccae508d9b7a69aa72b6181:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   c5a5491..a93a3b9  a93a3b975cd0bad37ccae508d9b7a69aa72b6181 -> 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 Dec 16 17:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 17:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0vjX-0007sn-Nf; Tue, 16 Dec 2014 17:16: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 1Y0vjW-0007si-Gj
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 17:16:26 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	67/0D-02696-9E860945; Tue, 16 Dec 2014 17:16:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418750182!15372993!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 18140 invoked from network); 16 Dec 2014 17:16:25 -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;
	16 Dec 2014 17:16:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="205456902"
Message-ID: <1418750054.16425.239.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 16 Dec 2014 17:14:14 +0000
In-Reply-To: <20141209162602.GA10129@laptop.dumpdata.com>
References: <1418046707-6900-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1418136450.14361.82.camel@citrix.com>
	<CAN58jisYpvQLDwCmcg0CFHf_HurgtwtHVkH3=QyOP-JjgBczOA@mail.gmail.com>
	<20141209162602.GA10129@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>,
	Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-09 at 11:26 -0500, Konrad Rzeszutek Wilk wrote:

> > I'm fully happy with proposed wording (and want the both bits to be used)

Done and committed.

> > 
> > > Konrad, this is a bug fix for a particular piece of hardware, it can't
> > > affect anything other than the OMAP ARM platform.
> 
> OK, 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 Dec 16 17:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 17:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0vjX-0007sn-Nf; Tue, 16 Dec 2014 17:16: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 1Y0vjW-0007si-Gj
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 17:16:26 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	67/0D-02696-9E860945; Tue, 16 Dec 2014 17:16:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418750182!15372993!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 18140 invoked from network); 16 Dec 2014 17:16:25 -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;
	16 Dec 2014 17:16:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="205456902"
Message-ID: <1418750054.16425.239.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 16 Dec 2014 17:14:14 +0000
In-Reply-To: <20141209162602.GA10129@laptop.dumpdata.com>
References: <1418046707-6900-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1418136450.14361.82.camel@citrix.com>
	<CAN58jisYpvQLDwCmcg0CFHf_HurgtwtHVkH3=QyOP-JjgBczOA@mail.gmail.com>
	<20141209162602.GA10129@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Tim Deegan <tim@xen.org>,
	Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] xen/serial: setup UART idle mode for OMAP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-09 at 11:26 -0500, Konrad Rzeszutek Wilk wrote:

> > I'm fully happy with proposed wording (and want the both bits to be used)

Done and committed.

> > 
> > > Konrad, this is a bug fix for a particular piece of hardware, it can't
> > > affect anything other than the OMAP ARM platform.
> 
> OK, 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 Dec 16 17:19:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 17:19:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0vmT-00081E-FX; Tue, 16 Dec 2014 17:19: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 1Y0vmR-000818-Gx
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 17:19:27 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	8F/4D-31453-E9960945; Tue, 16 Dec 2014 17:19:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418750364!6105753!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 1308 invoked from network); 16 Dec 2014 17:19:26 -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;
	16 Dec 2014 17:19:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="205458393"
Message-ID: <1418750185.20265.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 16 Dec 2014 17:16:25 +0000
In-Reply-To: <20141210171345.GM4268@laptop.dumpdata.com>
References: <20141209162048.GB9585@laptop.dumpdata.com>
	<1418143402-29674-1-git-send-email-andrew.cooper3@citrix.com>
	<20141210171345.GM4268@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 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 Wed, 2014-12-10 at 12:13 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 09, 2014 at 04:43:22PM +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.
> > 
> > Coverity also complains about passing a non-NUL terminated string to
> > xc_flask_context_to_sid().  xc_flask_context_to_sid() doesn't actually take a
> > NUL terminated string, but it does take a char* which, in context, used to be
> > a string, which is why Coverity complains.
> > 
> > One solution would be to use strdup(ctx) which is simpler than a
> > strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated
> > string being used with xc_flask_context_to_sid().
> > 
> > However, ctx is strictly an input to the hypercall and is not mutated along
> > the way.  Both these issues can be fixed, and the error logic simplified, by
> > not duplicating ctx in the first place.
> > 
> > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > Coverity-IDs: 1055305 1055721
> > Acked-by: 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>
> > 
> > ---
> > v2: Expand the commit message.  No code change
> 
> Thank you.
> 
> 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 Tue Dec 16 17:19:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 17:19:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0vmT-00081E-FX; Tue, 16 Dec 2014 17:19: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 1Y0vmR-000818-Gx
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 17:19:27 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	8F/4D-31453-E9960945; Tue, 16 Dec 2014 17:19:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418750364!6105753!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 1308 invoked from network); 16 Dec 2014 17:19:26 -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;
	16 Dec 2014 17:19:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="205458393"
Message-ID: <1418750185.20265.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 16 Dec 2014 17:16:25 +0000
In-Reply-To: <20141210171345.GM4268@laptop.dumpdata.com>
References: <20141209162048.GB9585@laptop.dumpdata.com>
	<1418143402-29674-1-git-send-email-andrew.cooper3@citrix.com>
	<20141210171345.GM4268@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Xen Coverity Team <coverity@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 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 Wed, 2014-12-10 at 12:13 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 09, 2014 at 04:43:22PM +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.
> > 
> > Coverity also complains about passing a non-NUL terminated string to
> > xc_flask_context_to_sid().  xc_flask_context_to_sid() doesn't actually take a
> > NUL terminated string, but it does take a char* which, in context, used to be
> > a string, which is why Coverity complains.
> > 
> > One solution would be to use strdup(ctx) which is simpler than a
> > strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated
> > string being used with xc_flask_context_to_sid().
> > 
> > However, ctx is strictly an input to the hypercall and is not mutated along
> > the way.  Both these issues can be fixed, and the error logic simplified, by
> > not duplicating ctx in the first place.
> > 
> > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > Coverity-IDs: 1055305 1055721
> > Acked-by: 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>
> > 
> > ---
> > v2: Expand the commit message.  No code change
> 
> Thank you.
> 
> 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 Tue Dec 16 17:24:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 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 1Y0vqj-0008OE-9g; Tue, 16 Dec 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 <Ian.Campbell@citrix.com>) id 1Y0vqh-0008O9-2t
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 17:23:51 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	3E/5D-17958-6AA60945; Tue, 16 Dec 2014 17:23:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418750628!10080428!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16222 invoked from network); 16 Dec 2014 17:23: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;
	16 Dec 2014 17:23:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204996214"
Message-ID: <1418750228.20265.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 16 Dec 2014 17:17:08 +0000
In-Reply-To: <1418408762-9691-1-git-send-email-andrew.cooper3@citrix.com>
References: <1418408762-9691-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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: Minor formatting
 fixes and 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 Fri, 2014-12-12 at 18:26 +0000, Andrew Cooper wrote:
> `font` had a trailing single quote which was out of place.
> 
> `gnttab_max_frames` was missing escapes for the underscores which caused the
> underscores to take their markdown meaning, causing 'max' in the middle to be
> italicised.  Escape the underscores, and make all command line parameters
> bold, to be consistent with the existing style.
> 
> Clarify how the default for `nmi` changes between debug and non debug builds
> of Xen.
> 
> 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>
> 
> ---
> Requesting for 4.5, under the "strictly a documentation change" allowance

Acked + applied.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 17:24:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 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 1Y0vqn-0008Ob-Lm; Tue, 16 Dec 2014 17:23: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 1Y0vqm-0008ON-7L
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 17:23:56 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	41/18-24859-BAA60945; Tue, 16 Dec 2014 17:23:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418750628!10080428!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16632 invoked from network); 16 Dec 2014 17:23:54 -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;
	16 Dec 2014 17:23:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204996420"
Message-ID: <1418750244.20265.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 16 Dec 2014 17:17:24 +0000
In-Reply-To: <1418641603.16425.89.camel@citrix.com>
References: <1418640984-21639-1-git-send-email-wei.liu2@citrix.com>
	<1418641603.16425.89.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, m.a.young@durham.ac.uk
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] xl: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-15 at 11:06 +0000, Ian Campbell wrote:

> > Release-Acked-by: Konrad Wilk <konrad.wilk@oracle.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 17:24:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 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 1Y0vqj-0008OE-9g; Tue, 16 Dec 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 <Ian.Campbell@citrix.com>) id 1Y0vqh-0008O9-2t
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 17:23:51 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	3E/5D-17958-6AA60945; Tue, 16 Dec 2014 17:23:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418750628!10080428!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16222 invoked from network); 16 Dec 2014 17:23: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;
	16 Dec 2014 17:23:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204996214"
Message-ID: <1418750228.20265.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 16 Dec 2014 17:17:08 +0000
In-Reply-To: <1418408762-9691-1-git-send-email-andrew.cooper3@citrix.com>
References: <1418408762-9691-1-git-send-email-andrew.cooper3@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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: Minor formatting
 fixes and 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 Fri, 2014-12-12 at 18:26 +0000, Andrew Cooper wrote:
> `font` had a trailing single quote which was out of place.
> 
> `gnttab_max_frames` was missing escapes for the underscores which caused the
> underscores to take their markdown meaning, causing 'max' in the middle to be
> italicised.  Escape the underscores, and make all command line parameters
> bold, to be consistent with the existing style.
> 
> Clarify how the default for `nmi` changes between debug and non debug builds
> of Xen.
> 
> 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>
> 
> ---
> Requesting for 4.5, under the "strictly a documentation change" allowance

Acked + applied.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 17:24:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 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 1Y0vqn-0008Ob-Lm; Tue, 16 Dec 2014 17:23: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 1Y0vqm-0008ON-7L
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 17:23:56 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	41/18-24859-BAA60945; Tue, 16 Dec 2014 17:23:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418750628!10080428!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16632 invoked from network); 16 Dec 2014 17:23:54 -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;
	16 Dec 2014 17:23:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="204996420"
Message-ID: <1418750244.20265.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 16 Dec 2014 17:17:24 +0000
In-Reply-To: <1418641603.16425.89.camel@citrix.com>
References: <1418640984-21639-1-git-send-email-wei.liu2@citrix.com>
	<1418641603.16425.89.camel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org, m.a.young@durham.ac.uk
Subject: Re: [Xen-devel] [PATCH for-4.5 v2] xl: print message to stdout when
 (!debug && dryrun)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-15 at 11:06 +0000, Ian Campbell wrote:

> > Release-Acked-by: Konrad Wilk <konrad.wilk@oracle.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 17:25:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 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 1Y0vsG-00006n-4U; Tue, 16 Dec 2014 17:25:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0vsF-00006f-3x
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 17:25:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DC/03-25276-60B60945; Tue, 16 Dec 2014 17:25:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418750724!8709140!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 21365 invoked from network); 16 Dec 2014 17:25:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 17:25:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="205460324"
Message-ID: <1418750365.20265.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 16 Dec 2014 17:19:25 +0000
In-Reply-To: <CAFLBxZbOyDq63c8groyCSE5etDV1K+5htTwoNqqhRj2CL2fmqw@mail.gmail.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
	<1418136501.14361.83.camel@citrix.com>
	<20141210163046.GF4268@laptop.dumpdata.com>
	<CAFLBxZbOyDq63c8groyCSE5etDV1K+5htTwoNqqhRj2CL2fmqw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH for 4.5] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-15 at 16:47 +0000, George Dunlap wrote:
> On Wed, Dec 10, 2014 at 4:30 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Tue, Dec 09, 2014 at 02:48:21PM +0000, Ian Campbell wrote:
> >> On Tue, 2014-12-09 at 14:04 +0000, George Dunlap wrote:
> >> > At the moment libxl unconditinally passes the underlying file format
> >> > to qemu in the device string.  However, when tapdisk is in use,
> >> > tapdisk handles the underlying format and presents qemu with
> >> > effectively a raw disk.  When qemu looks at the tapdisk block device
> >> > and doesn't find the image format it was looking for, it will fail.
> >> >
> >> > This effectively means that tapdisk cannot be used with HVM domains at
> >> > the moment except for raw files.
> >> >
> >> > Instead, if we're using a tapdisk backend, tell qemu to use a raw file
> >> > format.
> >> >
> >> > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> >>
> >> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >
> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> This doesn't seem to have been applied yet.

Now applied, nuking the extra blank line which way noticed on the way.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 17:25:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 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 1Y0vsG-00006n-4U; Tue, 16 Dec 2014 17:25:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y0vsF-00006f-3x
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 17:25:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	DC/03-25276-60B60945; Tue, 16 Dec 2014 17:25:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418750724!8709140!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 21365 invoked from network); 16 Dec 2014 17:25:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 17:25:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,587,1413244800"; d="scan'208";a="205460324"
Message-ID: <1418750365.20265.6.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 16 Dec 2014 17:19:25 +0000
In-Reply-To: <CAFLBxZbOyDq63c8groyCSE5etDV1K+5htTwoNqqhRj2CL2fmqw@mail.gmail.com>
References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com>
	<1418136501.14361.83.camel@citrix.com>
	<20141210163046.GF4268@laptop.dumpdata.com>
	<CAFLBxZbOyDq63c8groyCSE5etDV1K+5htTwoNqqhRj2CL2fmqw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Ian Jackson <ian.jackson@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH for 4.5] libxl: Tell qemu to use raw format
 when using a tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-15 at 16:47 +0000, George Dunlap wrote:
> On Wed, Dec 10, 2014 at 4:30 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Tue, Dec 09, 2014 at 02:48:21PM +0000, Ian Campbell wrote:
> >> On Tue, 2014-12-09 at 14:04 +0000, George Dunlap wrote:
> >> > At the moment libxl unconditinally passes the underlying file format
> >> > to qemu in the device string.  However, when tapdisk is in use,
> >> > tapdisk handles the underlying format and presents qemu with
> >> > effectively a raw disk.  When qemu looks at the tapdisk block device
> >> > and doesn't find the image format it was looking for, it will fail.
> >> >
> >> > This effectively means that tapdisk cannot be used with HVM domains at
> >> > the moment except for raw files.
> >> >
> >> > Instead, if we're using a tapdisk backend, tell qemu to use a raw file
> >> > format.
> >> >
> >> > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> >>
> >> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >
> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> This doesn't seem to have been applied yet.

Now applied, nuking the extra blank line which way noticed on the way.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 17:49:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 17:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0wFT-0000nZ-CH; Tue, 16 Dec 2014 17:49:27 +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 1Y0wFR-0000nU-JN
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 17:49:25 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	3D/97-22819-4A070945; Tue, 16 Dec 2014 17:49:24 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418752162!8402734!1
X-Originating-IP: [66.165.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 22449 invoked from network); 16 Dec 2014 17:49:24 -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;
	16 Dec 2014 17:49:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205006212"
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.210.2;
	Tue, 16 Dec 2014 12:34:54 -0500
Message-ID: <54906D3D.2060807@citrix.com>
Date: Tue, 16 Dec 2014 18:34:53 +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.3.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xenproject.org>
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] IO-APIC interrupts getting stuck
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

While working on the FreeBSD PVH Dom0 port I've realized that IO-APIC 
interrupts get stuck in a very strange state very easily with the 
current PIRQ implementation that I'm using on FreeBSD.

Since I'm not sure what is going on, I would like to ask for some 
feedback and possible solutions, because at this point I'm running out 
of ideas of what's happening.

In this case I'm going to use IRQ 17 as an example, which is shared 
between an Intel(R) PRO/1000 nic, a Broadcom NetXtreme Gigabit nic and 
an Intel 82801JI (ICH10) USB controller.

Usually during the boot process, or very shortly after it, Dom0 looses 
interrupts from IRQ 17, dumping IRQ information from Xen ('i' key), 
gives the following output:

(XEN)    IRQ:  17 affinity:00000001 vec:a8 type=IO-APIC-level   status=00000010 in-flight=0 domain-list=0: 17(---),
...
(XEN)     IRQ 17 Vec168:
(XEN)       Apic 0x00, Pin 17: vec=a8 delivery=LoPri dest=L status=1 polarity=1 irr=1 trig=L mask=0 dest_id:1

I've also added some event channel debug functions to the FreeBSD 
in-kernel debugger in order to print the status of event channels:

Port 15 Type: PIRQ
        Pirq: 17 ActiveHi: 0 EdgeTrigger: 0 NeedsEOI: 1
        Masked: 0 Pending: 0
        Per-CPU Masks: cpu#0: 0 cpu#1: 0 cpu#2: 1 cpu#3: 0 cpu#4: 0 cpu#5: 0 cpu#6: 0 cpu#7: 0

And the corresponding line from the Xen 'e' debug key:

(XEN)       15 [0/0/1]: s=4 n=2 x=0 p=17 i=17

This makes me thing that the FreeBSD kernel is failing to EOI the 
vector (because of the irr=1 in the Xen IRQ debug info), so I've also 
added a function to the debugger that allows me to EOI a vector from 
it. But even after issuing a PHYSDEVOP_eoi hypercall on the affected 
PIRQ (17), the status is exactly the same, because pirq->masked == 0, 
so desc_guest_eoi fails to EOI the vector (see xen/arch/x86/irq.c:1433).

So now I'm wondering, how can I "unstuck" this IRQ, and how did it get 
into this strange state?

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 17:49:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 17:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0wFT-0000nZ-CH; Tue, 16 Dec 2014 17:49:27 +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 1Y0wFR-0000nU-JN
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 17:49:25 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	3D/97-22819-4A070945; Tue, 16 Dec 2014 17:49:24 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418752162!8402734!1
X-Originating-IP: [66.165.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 22449 invoked from network); 16 Dec 2014 17:49:24 -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;
	16 Dec 2014 17:49:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205006212"
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.210.2;
	Tue, 16 Dec 2014 12:34:54 -0500
Message-ID: <54906D3D.2060807@citrix.com>
Date: Tue, 16 Dec 2014 18:34:53 +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.3.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xenproject.org>
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] IO-APIC interrupts getting stuck
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

While working on the FreeBSD PVH Dom0 port I've realized that IO-APIC 
interrupts get stuck in a very strange state very easily with the 
current PIRQ implementation that I'm using on FreeBSD.

Since I'm not sure what is going on, I would like to ask for some 
feedback and possible solutions, because at this point I'm running out 
of ideas of what's happening.

In this case I'm going to use IRQ 17 as an example, which is shared 
between an Intel(R) PRO/1000 nic, a Broadcom NetXtreme Gigabit nic and 
an Intel 82801JI (ICH10) USB controller.

Usually during the boot process, or very shortly after it, Dom0 looses 
interrupts from IRQ 17, dumping IRQ information from Xen ('i' key), 
gives the following output:

(XEN)    IRQ:  17 affinity:00000001 vec:a8 type=IO-APIC-level   status=00000010 in-flight=0 domain-list=0: 17(---),
...
(XEN)     IRQ 17 Vec168:
(XEN)       Apic 0x00, Pin 17: vec=a8 delivery=LoPri dest=L status=1 polarity=1 irr=1 trig=L mask=0 dest_id:1

I've also added some event channel debug functions to the FreeBSD 
in-kernel debugger in order to print the status of event channels:

Port 15 Type: PIRQ
        Pirq: 17 ActiveHi: 0 EdgeTrigger: 0 NeedsEOI: 1
        Masked: 0 Pending: 0
        Per-CPU Masks: cpu#0: 0 cpu#1: 0 cpu#2: 1 cpu#3: 0 cpu#4: 0 cpu#5: 0 cpu#6: 0 cpu#7: 0

And the corresponding line from the Xen 'e' debug key:

(XEN)       15 [0/0/1]: s=4 n=2 x=0 p=17 i=17

This makes me thing that the FreeBSD kernel is failing to EOI the 
vector (because of the irr=1 in the Xen IRQ debug info), so I've also 
added a function to the debugger that allows me to EOI a vector from 
it. But even after issuing a PHYSDEVOP_eoi hypercall on the affected 
PIRQ (17), the status is exactly the same, because pirq->masked == 0, 
so desc_guest_eoi fails to EOI the vector (see xen/arch/x86/irq.c:1433).

So now I'm wondering, how can I "unstuck" this IRQ, and how did it get 
into this strange state?

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 17:56:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 17:56:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0wLh-0001A5-8q; Tue, 16 Dec 2014 17:55: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 1Y0wLg-0001A0-Gl
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 17:55:52 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	25/24-24124-72270945; Tue, 16 Dec 2014 17:55:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418752549!13698193!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 3382 invoked from network); 16 Dec 2014 17:55: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;
	16 Dec 2014 17:55:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205009773"
Message-ID: <54906F2C.8030800@citrix.com>
Date: Tue, 16 Dec 2014 17:43:08 +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.wilk@oracle.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
In-Reply-To: <20141216161352.504FA124EF2@laptop.dumpdata.com>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/12/14 16:13, konrad.wilk@oracle.com wrote:
> Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
> we have the General Release on Jan 7th!
>
> Details for the test-day are at
>
> http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions
>
> In terms of bugs, we have:

>From the XenServer testing.

* Fail to reliably boot on IBM Flex x222 blades, apparent regression
from 4.4

I have declared this a latent BIOS bug, and not a regression from 4.4. 
Across regular reboots, the exact positions of the ACPI tables, and the
e820 layout is unstable.  The first consistent difference between 4.4
and 4.5 is that 4.4 reports 1 MBR signature while 4.5 reports 0.  This
is because the int $0x13, ah=2 call is returning differently.  I can get
the call to return differently (and correctly for 4.5) by simply making
the boot trampoline larger (with my debugging routines but not being
called).

* VM fail to resume on upgrade from Xen < 4.5

This is the issue I am currently looking into.  Currently, all the
"upgrade from older XenServer" tests are failing due to VMs crashing on
resume.  I have not yet identified whether this is a XenServer issue or
a Xen issue.  Lifecycle operations on 4.5 itself are all fine including
both suspend/resume and 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 Dec 16 17:56:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 17:56:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0wLh-0001A5-8q; Tue, 16 Dec 2014 17:55: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 1Y0wLg-0001A0-Gl
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 17:55:52 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	25/24-24124-72270945; Tue, 16 Dec 2014 17:55:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418752549!13698193!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 3382 invoked from network); 16 Dec 2014 17:55: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;
	16 Dec 2014 17:55:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205009773"
Message-ID: <54906F2C.8030800@citrix.com>
Date: Tue, 16 Dec 2014 17:43:08 +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.wilk@oracle.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
In-Reply-To: <20141216161352.504FA124EF2@laptop.dumpdata.com>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/12/14 16:13, konrad.wilk@oracle.com wrote:
> Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
> we have the General Release on Jan 7th!
>
> Details for the test-day are at
>
> http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions
>
> In terms of bugs, we have:

>From the XenServer testing.

* Fail to reliably boot on IBM Flex x222 blades, apparent regression
from 4.4

I have declared this a latent BIOS bug, and not a regression from 4.4. 
Across regular reboots, the exact positions of the ACPI tables, and the
e820 layout is unstable.  The first consistent difference between 4.4
and 4.5 is that 4.4 reports 1 MBR signature while 4.5 reports 0.  This
is because the int $0x13, ah=2 call is returning differently.  I can get
the call to return differently (and correctly for 4.5) by simply making
the boot trampoline larger (with my debugging routines but not being
called).

* VM fail to resume on upgrade from Xen < 4.5

This is the issue I am currently looking into.  Currently, all the
"upgrade from older XenServer" tests are failing due to VMs crashing on
resume.  I have not yet identified whether this is a XenServer issue or
a Xen issue.  Lifecycle operations on 4.5 itself are all fine including
both suspend/resume and 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 Dec 16 17:56:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 17:56:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0wML-0001DS-Lk; Tue, 16 Dec 2014 17:56: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 1Y0wMK-0001DA-83
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 17:56:32 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	78/EA-02712-F4270945; Tue, 16 Dec 2014 17:56:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418752588!15480974!1
X-Originating-IP: [66.165.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 19760 invoked from network); 16 Dec 2014 17:56:30 -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;
	16 Dec 2014 17:56:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205475099"
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.210.2; Tue, 16 Dec 2014 12:50: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 1Y0wFz-0000p2-Tf;
	Tue, 16 Dec 2014 17:49:59 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0wFz-0007Lb-NP;
	Tue, 16 Dec 2014 17:49:59 +0000
Date: Tue, 16 Dec 2014 17:49:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32392-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] 32392: 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 32392 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32392/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 32361

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-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-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-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-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-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-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-amd64-xl-qemut-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                  2676bc915157ab474ee478d929b0928cf696b385
baseline version:
 xen                  7e73a6e7f12ae080222c5d339799905de3443a6e

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com> (ARM and generic bits)
  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-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                                         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


Pushing revision :

+ branch=xen-unstable
+ revision=2676bc915157ab474ee478d929b0928cf696b385
+ . 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 2676bc915157ab474ee478d929b0928cf696b385
+ branch=xen-unstable
+ revision=2676bc915157ab474ee478d929b0928cf696b385
+ . 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 2676bc915157ab474ee478d929b0928cf696b385:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   7e73a6e..2676bc9  2676bc915157ab474ee478d929b0928cf696b385 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 17:56:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 17:56:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0wML-0001DS-Lk; Tue, 16 Dec 2014 17:56: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 1Y0wMK-0001DA-83
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 17:56:32 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	78/EA-02712-F4270945; Tue, 16 Dec 2014 17:56:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418752588!15480974!1
X-Originating-IP: [66.165.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 19760 invoked from network); 16 Dec 2014 17:56:30 -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;
	16 Dec 2014 17:56:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205475099"
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.210.2; Tue, 16 Dec 2014 12:50: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 1Y0wFz-0000p2-Tf;
	Tue, 16 Dec 2014 17:49:59 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0wFz-0007Lb-NP;
	Tue, 16 Dec 2014 17:49:59 +0000
Date: Tue, 16 Dec 2014 17:49:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32392-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] 32392: 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 32392 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32392/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 32361

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-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-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-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-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-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-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-amd64-xl-qemut-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                  2676bc915157ab474ee478d929b0928cf696b385
baseline version:
 xen                  7e73a6e7f12ae080222c5d339799905de3443a6e

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com> (ARM and generic bits)
  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-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                                         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


Pushing revision :

+ branch=xen-unstable
+ revision=2676bc915157ab474ee478d929b0928cf696b385
+ . 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 2676bc915157ab474ee478d929b0928cf696b385
+ branch=xen-unstable
+ revision=2676bc915157ab474ee478d929b0928cf696b385
+ . 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 2676bc915157ab474ee478d929b0928cf696b385:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   7e73a6e..2676bc9  2676bc915157ab474ee478d929b0928cf696b385 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 18:07:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 18:07:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0wWI-0001jU-0x; Tue, 16 Dec 2014 18:06: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 1Y0wWF-0001jP-Ou
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 18:06:47 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	E7/99-02576-7B470945; Tue, 16 Dec 2014 18:06:47 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418753204!15495901!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 29308 invoked from network); 16 Dec 2014 18:06:46 -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;
	16 Dec 2014 18:06:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205017721"
Message-ID: <549072FE.40500@citrix.com>
Date: Tue, 16 Dec 2014 17:59:26 +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: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>, xen-devel
	<xen-devel@lists.xenproject.org>
References: <54906D3D.2060807@citrix.com>
In-Reply-To: <54906D3D.2060807@citrix.com>
X-DLP: MIA1
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] IO-APIC interrupts getting stuck
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTYvMTIvMTQgMTc6MzQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4gSGVsbG8sCj4KPiBX
aGlsZSB3b3JraW5nIG9uIHRoZSBGcmVlQlNEIFBWSCBEb20wIHBvcnQgSSd2ZSByZWFsaXplZCB0
aGF0IElPLUFQSUMgCj4gaW50ZXJydXB0cyBnZXQgc3R1Y2sgaW4gYSB2ZXJ5IHN0cmFuZ2Ugc3Rh
dGUgdmVyeSBlYXNpbHkgd2l0aCB0aGUgCj4gY3VycmVudCBQSVJRIGltcGxlbWVudGF0aW9uIHRo
YXQgSSdtIHVzaW5nIG9uIEZyZWVCU0QuCj4KPiBTaW5jZSBJJ20gbm90IHN1cmUgd2hhdCBpcyBn
b2luZyBvbiwgSSB3b3VsZCBsaWtlIHRvIGFzayBmb3Igc29tZSAKPiBmZWVkYmFjayBhbmQgcG9z
c2libGUgc29sdXRpb25zLCBiZWNhdXNlIGF0IHRoaXMgcG9pbnQgSSdtIHJ1bm5pbmcgb3V0IAo+
IG9mIGlkZWFzIG9mIHdoYXQncyBoYXBwZW5pbmcuCj4KPiBJbiB0aGlzIGNhc2UgSSdtIGdvaW5n
IHRvIHVzZSBJUlEgMTcgYXMgYW4gZXhhbXBsZSwgd2hpY2ggaXMgc2hhcmVkIAo+IGJldHdlZW4g
YW4gSW50ZWwoUikgUFJPLzEwMDAgbmljLCBhIEJyb2FkY29tIE5ldFh0cmVtZSBHaWdhYml0IG5p
YyBhbmQgCj4gYW4gSW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9sbGVyLgo+Cj4gVXN1
YWxseSBkdXJpbmcgdGhlIGJvb3QgcHJvY2Vzcywgb3IgdmVyeSBzaG9ydGx5IGFmdGVyIGl0LCBE
b20wIGxvb3NlcyAKPiBpbnRlcnJ1cHRzIGZyb20gSVJRIDE3LCBkdW1waW5nIElSUSBpbmZvcm1h
dGlvbiBmcm9tIFhlbiAoJ2knIGtleSksIAo+IGdpdmVzIHRoZSBmb2xsb3dpbmcgb3V0cHV0Ogo+
Cj4gKFhFTikgICAgSVJROiAgMTcgYWZmaW5pdHk6MDAwMDAwMDEgdmVjOmE4IHR5cGU9SU8tQVBJ
Qy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOiAxNygt
LS0pLAo+IC4uLgo+IChYRU4pICAgICBJUlEgMTcgVmVjMTY4Ogo+IChYRU4pICAgICAgIEFwaWMg
MHgwMCwgUGluIDE3OiB2ZWM9YTggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0xIHBvbGFy
aXR5PTEgaXJyPTEgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjEKPgo+IEkndmUgYWxzbyBhZGRlZCBz
b21lIGV2ZW50IGNoYW5uZWwgZGVidWcgZnVuY3Rpb25zIHRvIHRoZSBGcmVlQlNEIAo+IGluLWtl
cm5lbCBkZWJ1Z2dlciBpbiBvcmRlciB0byBwcmludCB0aGUgc3RhdHVzIG9mIGV2ZW50IGNoYW5u
ZWxzOgo+Cj4gUG9ydCAxNSBUeXBlOiBQSVJRCj4gICAgICAgICBQaXJxOiAxNyBBY3RpdmVIaTog
MCBFZGdlVHJpZ2dlcjogMCBOZWVkc0VPSTogMQo+ICAgICAgICAgTWFza2VkOiAwIFBlbmRpbmc6
IDAKPiAgICAgICAgIFBlci1DUFUgTWFza3M6IGNwdSMwOiAwIGNwdSMxOiAwIGNwdSMyOiAxIGNw
dSMzOiAwIGNwdSM0OiAwIGNwdSM1OiAwIGNwdSM2OiAwIGNwdSM3OiAwCj4KPiBBbmQgdGhlIGNv
cnJlc3BvbmRpbmcgbGluZSBmcm9tIHRoZSBYZW4gJ2UnIGRlYnVnIGtleToKPgo+IChYRU4pICAg
ICAgIDE1IFswLzAvMV06IHM9NCBuPTIgeD0wIHA9MTcgaT0xNwo+Cj4gVGhpcyBtYWtlcyBtZSB0
aGluZyB0aGF0IHRoZSBGcmVlQlNEIGtlcm5lbCBpcyBmYWlsaW5nIHRvIEVPSSB0aGUgCj4gdmVj
dG9yIChiZWNhdXNlIG9mIHRoZSBpcnI9MSBpbiB0aGUgWGVuIElSUSBkZWJ1ZyBpbmZvKSwgc28g
SSd2ZSBhbHNvIAo+IGFkZGVkIGEgZnVuY3Rpb24gdG8gdGhlIGRlYnVnZ2VyIHRoYXQgYWxsb3dz
IG1lIHRvIEVPSSBhIHZlY3RvciBmcm9tIAo+IGl0LiBCdXQgZXZlbiBhZnRlciBpc3N1aW5nIGEg
UEhZU0RFVk9QX2VvaSBoeXBlcmNhbGwgb24gdGhlIGFmZmVjdGVkIAo+IFBJUlEgKDE3KSwgdGhl
IHN0YXR1cyBpcyBleGFjdGx5IHRoZSBzYW1lLCBiZWNhdXNlIHBpcnEtPm1hc2tlZCA9PSAwLCAK
PiBzbyBkZXNjX2d1ZXN0X2VvaSBmYWlscyB0byBFT0kgdGhlIHZlY3RvciAoc2VlIHhlbi9hcmNo
L3g4Ni9pcnEuYzoxNDMzKS4KPgo+IFNvIG5vdyBJJ20gd29uZGVyaW5nLCBob3cgY2FuIEkgInVu
c3R1Y2siIHRoaXMgSVJRLCBhbmQgaG93IGRpZCBpdCBnZXQgCj4gaW50byB0aGlzIHN0cmFuZ2Ug
c3RhdGU/Cj4KPiBSb2dlci4KCkRvIHlvdSBoYXZlIGEgeGVuIGRtZXNnIHdpdGggZnVsbCBkZWJ1
Z2dpbmc/ICBBY2NvcmRpbmcgdG8gdGhlIGZpcnN0CmxpbmUgZnJvbSAnaScsIFhlbiBiZWxpZXZl
cyB0aGF0IHRoZSBpcnEgaW4gcXVlc3Rpb24gaXMgbm90IGluIG5lZWQgb2YKYW4gRU9JLCB3aGlj
aCBpcyBjbGVhcmx5IGNvbnRyYXJ5IHRvIHRoZSBJT0FQSUNzIHZpZXcgb2YgdGhlIHdvcmxkLgoK
U29tZSByYW5kb20gc3VnZ2VzdGlvbnM6IGRvZXMgYWx0ZXJpbmcgaW50ZXJydXB0IHJlbWFwcGlu
ZyBtYWtlIGEKZGlmZmVyZW5jZT8gZG9lcyBhbHRlcmluZyB0aGUgaW9hcGljX2Fja19tb2RlIG1h
a2UgYSBkaWZmZXJlbmNlPwoKfkFuZHJldwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Dec 16 18:07:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 18:07:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0wWI-0001jU-0x; Tue, 16 Dec 2014 18:06: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 1Y0wWF-0001jP-Ou
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 18:06:47 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	E7/99-02576-7B470945; Tue, 16 Dec 2014 18:06:47 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418753204!15495901!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 29308 invoked from network); 16 Dec 2014 18:06:46 -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;
	16 Dec 2014 18:06:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205017721"
Message-ID: <549072FE.40500@citrix.com>
Date: Tue, 16 Dec 2014 17:59:26 +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: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>, xen-devel
	<xen-devel@lists.xenproject.org>
References: <54906D3D.2060807@citrix.com>
In-Reply-To: <54906D3D.2060807@citrix.com>
X-DLP: MIA1
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] IO-APIC interrupts getting stuck
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTYvMTIvMTQgMTc6MzQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4gSGVsbG8sCj4KPiBX
aGlsZSB3b3JraW5nIG9uIHRoZSBGcmVlQlNEIFBWSCBEb20wIHBvcnQgSSd2ZSByZWFsaXplZCB0
aGF0IElPLUFQSUMgCj4gaW50ZXJydXB0cyBnZXQgc3R1Y2sgaW4gYSB2ZXJ5IHN0cmFuZ2Ugc3Rh
dGUgdmVyeSBlYXNpbHkgd2l0aCB0aGUgCj4gY3VycmVudCBQSVJRIGltcGxlbWVudGF0aW9uIHRo
YXQgSSdtIHVzaW5nIG9uIEZyZWVCU0QuCj4KPiBTaW5jZSBJJ20gbm90IHN1cmUgd2hhdCBpcyBn
b2luZyBvbiwgSSB3b3VsZCBsaWtlIHRvIGFzayBmb3Igc29tZSAKPiBmZWVkYmFjayBhbmQgcG9z
c2libGUgc29sdXRpb25zLCBiZWNhdXNlIGF0IHRoaXMgcG9pbnQgSSdtIHJ1bm5pbmcgb3V0IAo+
IG9mIGlkZWFzIG9mIHdoYXQncyBoYXBwZW5pbmcuCj4KPiBJbiB0aGlzIGNhc2UgSSdtIGdvaW5n
IHRvIHVzZSBJUlEgMTcgYXMgYW4gZXhhbXBsZSwgd2hpY2ggaXMgc2hhcmVkIAo+IGJldHdlZW4g
YW4gSW50ZWwoUikgUFJPLzEwMDAgbmljLCBhIEJyb2FkY29tIE5ldFh0cmVtZSBHaWdhYml0IG5p
YyBhbmQgCj4gYW4gSW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9sbGVyLgo+Cj4gVXN1
YWxseSBkdXJpbmcgdGhlIGJvb3QgcHJvY2Vzcywgb3IgdmVyeSBzaG9ydGx5IGFmdGVyIGl0LCBE
b20wIGxvb3NlcyAKPiBpbnRlcnJ1cHRzIGZyb20gSVJRIDE3LCBkdW1waW5nIElSUSBpbmZvcm1h
dGlvbiBmcm9tIFhlbiAoJ2knIGtleSksIAo+IGdpdmVzIHRoZSBmb2xsb3dpbmcgb3V0cHV0Ogo+
Cj4gKFhFTikgICAgSVJROiAgMTcgYWZmaW5pdHk6MDAwMDAwMDEgdmVjOmE4IHR5cGU9SU8tQVBJ
Qy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAxMCBpbi1mbGlnaHQ9MCBkb21haW4tbGlzdD0wOiAxNygt
LS0pLAo+IC4uLgo+IChYRU4pICAgICBJUlEgMTcgVmVjMTY4Ogo+IChYRU4pICAgICAgIEFwaWMg
MHgwMCwgUGluIDE3OiB2ZWM9YTggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0xIHBvbGFy
aXR5PTEgaXJyPTEgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjEKPgo+IEkndmUgYWxzbyBhZGRlZCBz
b21lIGV2ZW50IGNoYW5uZWwgZGVidWcgZnVuY3Rpb25zIHRvIHRoZSBGcmVlQlNEIAo+IGluLWtl
cm5lbCBkZWJ1Z2dlciBpbiBvcmRlciB0byBwcmludCB0aGUgc3RhdHVzIG9mIGV2ZW50IGNoYW5u
ZWxzOgo+Cj4gUG9ydCAxNSBUeXBlOiBQSVJRCj4gICAgICAgICBQaXJxOiAxNyBBY3RpdmVIaTog
MCBFZGdlVHJpZ2dlcjogMCBOZWVkc0VPSTogMQo+ICAgICAgICAgTWFza2VkOiAwIFBlbmRpbmc6
IDAKPiAgICAgICAgIFBlci1DUFUgTWFza3M6IGNwdSMwOiAwIGNwdSMxOiAwIGNwdSMyOiAxIGNw
dSMzOiAwIGNwdSM0OiAwIGNwdSM1OiAwIGNwdSM2OiAwIGNwdSM3OiAwCj4KPiBBbmQgdGhlIGNv
cnJlc3BvbmRpbmcgbGluZSBmcm9tIHRoZSBYZW4gJ2UnIGRlYnVnIGtleToKPgo+IChYRU4pICAg
ICAgIDE1IFswLzAvMV06IHM9NCBuPTIgeD0wIHA9MTcgaT0xNwo+Cj4gVGhpcyBtYWtlcyBtZSB0
aGluZyB0aGF0IHRoZSBGcmVlQlNEIGtlcm5lbCBpcyBmYWlsaW5nIHRvIEVPSSB0aGUgCj4gdmVj
dG9yIChiZWNhdXNlIG9mIHRoZSBpcnI9MSBpbiB0aGUgWGVuIElSUSBkZWJ1ZyBpbmZvKSwgc28g
SSd2ZSBhbHNvIAo+IGFkZGVkIGEgZnVuY3Rpb24gdG8gdGhlIGRlYnVnZ2VyIHRoYXQgYWxsb3dz
IG1lIHRvIEVPSSBhIHZlY3RvciBmcm9tIAo+IGl0LiBCdXQgZXZlbiBhZnRlciBpc3N1aW5nIGEg
UEhZU0RFVk9QX2VvaSBoeXBlcmNhbGwgb24gdGhlIGFmZmVjdGVkIAo+IFBJUlEgKDE3KSwgdGhl
IHN0YXR1cyBpcyBleGFjdGx5IHRoZSBzYW1lLCBiZWNhdXNlIHBpcnEtPm1hc2tlZCA9PSAwLCAK
PiBzbyBkZXNjX2d1ZXN0X2VvaSBmYWlscyB0byBFT0kgdGhlIHZlY3RvciAoc2VlIHhlbi9hcmNo
L3g4Ni9pcnEuYzoxNDMzKS4KPgo+IFNvIG5vdyBJJ20gd29uZGVyaW5nLCBob3cgY2FuIEkgInVu
c3R1Y2siIHRoaXMgSVJRLCBhbmQgaG93IGRpZCBpdCBnZXQgCj4gaW50byB0aGlzIHN0cmFuZ2Ug
c3RhdGU/Cj4KPiBSb2dlci4KCkRvIHlvdSBoYXZlIGEgeGVuIGRtZXNnIHdpdGggZnVsbCBkZWJ1
Z2dpbmc/ICBBY2NvcmRpbmcgdG8gdGhlIGZpcnN0CmxpbmUgZnJvbSAnaScsIFhlbiBiZWxpZXZl
cyB0aGF0IHRoZSBpcnEgaW4gcXVlc3Rpb24gaXMgbm90IGluIG5lZWQgb2YKYW4gRU9JLCB3aGlj
aCBpcyBjbGVhcmx5IGNvbnRyYXJ5IHRvIHRoZSBJT0FQSUNzIHZpZXcgb2YgdGhlIHdvcmxkLgoK
U29tZSByYW5kb20gc3VnZ2VzdGlvbnM6IGRvZXMgYWx0ZXJpbmcgaW50ZXJydXB0IHJlbWFwcGlu
ZyBtYWtlIGEKZGlmZmVyZW5jZT8gZG9lcyBhbHRlcmluZyB0aGUgaW9hcGljX2Fja19tb2RlIG1h
a2UgYSBkaWZmZXJlbmNlPwoKfkFuZHJldwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Dec 16 19:01:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 19: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 1Y0xMF-00032v-Is; Tue, 16 Dec 2014 19:00:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Y0xME-00032q-2a
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 19:00:30 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	66/67-26858-D4180945; Tue, 16 Dec 2014 19:00:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418756426!10097302!1
X-Originating-IP: [66.165.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 18083 invoked from network); 16 Dec 2014 19:00: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;
	16 Dec 2014 19:00:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205046569"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 16 Dec 2014 13:59:57 -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 1Y0xLg-0006Ha-QB;
	Tue, 16 Dec 2014 18:59:56 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <netdev@vger.kernel.org>
Date: Tue, 16 Dec 2014 18:59:46 +0000
Message-ID: <1418756386-6940-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: xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>, Eric Dumazet <edumazet@google.com>
Subject: [Xen-devel] [PATCHv1 net] xen-netfront: use napi_complete()
	correctly to prevent Rx stalling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
masking in NAPI) the napi instance is removed from the per-cpu list
prior to calling the n->poll(), and is only requeued if all of the
budget was used.  This inadvertently broke netfront because netfront
does not use NAPI correctly.

If netfront had not used all of its budget it would do a final check
for any Rx responses and avoid calling napi_complete() if there were
more responses.  It would still return under budget so it would never
be rescheduled.  The final check would also not re-enable the Rx
interrupt.

Additionally, xenvif_poll() would also call napi_complete() /after/
enabling the interrupt.  This resulted in a race between the
napi_complete() and the napi_schedule() in the interrupt handler.  The
use of local_irq_save/restore() avoided by race iff the handler is
running on the same CPU but not if it was running on a different CPU.

Fix both of these by always calling napi_compete() if the budget was
not all used, and then calling napi_schedule() if the final checks
says there's more work.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Eric Dumazet <edumazet@google.com>
---
 drivers/net/xen-netfront.c |   11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 2f0a9ce..22bcb4e 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -977,7 +977,6 @@ static int xennet_poll(struct napi_struct *napi, int budget)
 	struct sk_buff_head rxq;
 	struct sk_buff_head errq;
 	struct sk_buff_head tmpq;
-	unsigned long flags;
 	int err;
 
 	spin_lock(&queue->rx_lock);
@@ -1050,15 +1049,11 @@ err:
 	if (work_done < budget) {
 		int more_to_do = 0;
 
-		napi_gro_flush(napi, false);
-
-		local_irq_save(flags);
+		napi_complete(napi);
 
 		RING_FINAL_CHECK_FOR_RESPONSES(&queue->rx, more_to_do);
-		if (!more_to_do)
-			__napi_complete(napi);
-
-		local_irq_restore(flags);
+		if (more_to_do)
+			napi_schedule(napi);
 	}
 
 	spin_unlock(&queue->rx_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 Tue Dec 16 19:01:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 19: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 1Y0xMF-00032v-Is; Tue, 16 Dec 2014 19:00:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Y0xME-00032q-2a
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 19:00:30 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	66/67-26858-D4180945; Tue, 16 Dec 2014 19:00:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418756426!10097302!1
X-Originating-IP: [66.165.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 18083 invoked from network); 16 Dec 2014 19:00: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;
	16 Dec 2014 19:00:28 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205046569"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 16 Dec 2014 13:59:57 -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 1Y0xLg-0006Ha-QB;
	Tue, 16 Dec 2014 18:59:56 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <netdev@vger.kernel.org>
Date: Tue, 16 Dec 2014 18:59:46 +0000
Message-ID: <1418756386-6940-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: xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>, Eric Dumazet <edumazet@google.com>
Subject: [Xen-devel] [PATCHv1 net] xen-netfront: use napi_complete()
	correctly to prevent Rx stalling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
masking in NAPI) the napi instance is removed from the per-cpu list
prior to calling the n->poll(), and is only requeued if all of the
budget was used.  This inadvertently broke netfront because netfront
does not use NAPI correctly.

If netfront had not used all of its budget it would do a final check
for any Rx responses and avoid calling napi_complete() if there were
more responses.  It would still return under budget so it would never
be rescheduled.  The final check would also not re-enable the Rx
interrupt.

Additionally, xenvif_poll() would also call napi_complete() /after/
enabling the interrupt.  This resulted in a race between the
napi_complete() and the napi_schedule() in the interrupt handler.  The
use of local_irq_save/restore() avoided by race iff the handler is
running on the same CPU but not if it was running on a different CPU.

Fix both of these by always calling napi_compete() if the budget was
not all used, and then calling napi_schedule() if the final checks
says there's more work.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Eric Dumazet <edumazet@google.com>
---
 drivers/net/xen-netfront.c |   11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 2f0a9ce..22bcb4e 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -977,7 +977,6 @@ static int xennet_poll(struct napi_struct *napi, int budget)
 	struct sk_buff_head rxq;
 	struct sk_buff_head errq;
 	struct sk_buff_head tmpq;
-	unsigned long flags;
 	int err;
 
 	spin_lock(&queue->rx_lock);
@@ -1050,15 +1049,11 @@ err:
 	if (work_done < budget) {
 		int more_to_do = 0;
 
-		napi_gro_flush(napi, false);
-
-		local_irq_save(flags);
+		napi_complete(napi);
 
 		RING_FINAL_CHECK_FOR_RESPONSES(&queue->rx, more_to_do);
-		if (!more_to_do)
-			__napi_complete(napi);
-
-		local_irq_restore(flags);
+		if (more_to_do)
+			napi_schedule(napi);
 	}
 
 	spin_unlock(&queue->rx_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 Tue Dec 16 19:35:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 19: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 1Y0xtN-00042m-Fg; Tue, 16 Dec 2014 19:34:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1Y0xtM-00042h-NA
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 19:34:44 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	41/DA-25714-45980945; Tue, 16 Dec 2014 19:34:44 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418758482!9585565!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 31007 invoked from network); 16 Dec 2014 19:34:43 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2014 19:34:43 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=X90IqrrLF2+wEix9BFsTHRSkw1p8OdBm4TsGprXsASK6EKPLj6YE5xSKuxTUqn+1NtNXGv15p8s5MCEowdKSdZO3KEff8qr1fzycN7qDGR80+Jh5+H2BOcUj4sGxf2R4fLf+zZ2ROBHeoC07r8Zd6ddTjmM7JtM3g5+O46vkhbEzgS+jg/IiCdt8hY+kmKueZAJ7H3O2bg7OZnUzKt+kgjUKldnSS/ikV8HZxb90krjCyBy6+jZsRBLpNZsRtLaKUmJFmCSmMvIIB7OAPfS7l+Vo6/ovGYn4l8Iopb2rwTldGxO2tGuwO6SWXwCrpgYrPa04F46qqv6Na5Tve3r6eA==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:MIME-Version: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=from:to
	:cc:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=TUervrCkuarKcjrQHb2ANv
	YIMgE=; b=l+5sQvSxMcgOOWP+x2BD2teZpLPKzNinO1s7CcjQFyo7EbiYLf1Ch+
	fkuZbJ0WbPsTuLovYAxGIt/C4ULNwHcnQsIXieTE2L4+khpM0JBFMj0Ulk5APtjv
	v029aP0FVYbIxC3ZbGg5YpqThYKsGR7hZ42eZauIl+byIN8riKcMBx6+spdPgijF
	iUmHDtPBJQQqmfXGd5wKHYmsGFipd5iFcs60eRsjRmbEz3snJxDkNPA3yNoE0jRn
	hzlBC/fRJd2Vq4Ufu+WYeEn3C4PjiJI3VNLMbC4HJiq5wVJcJSdMwPU4iot9Y+wn
	XYu6KcoE05UfngUkvlLgwskfTzNGb3eg==
Received: (qmail 20256 invoked from network); 16 Dec 2014 21:34:41 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	16 Dec 2014 21:34:41 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 4E31B80438
	for <xen-devel@lists.xen.org>; Tue, 16 Dec 2014 21:34:41 +0200 (EET)
Received: (qmail 12653 invoked from network); 16 Dec 2014 21:34:41 +0200
Received: from unknown (HELO mdontu-l.dsd.bitdefender.biz)
	(mdontu@bitdefender.com@195.210.5.22)
	by smtp02.buh.bitdefender.net with SMTP; 16 Dec 2014 21:34:40 +0200
From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 21:33:25 +0200
Message-Id: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
X-Mailer: git-send-email 2.2.0
MIME-Version: 1.0
Content-Length: 9240
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.58337
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374748,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; 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.1.4; Id: 2m1ghdn.199a3dmp4.7fp1],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: [Xen-devel] [PATCH v4] xmalloc: add support for checking the pool
	integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SW1wbGVtZW50ZWQgeG1lbV9wb29sX2NoZWNrKCksIHhtZW1fcG9vbF9jaGVja19sb2NrZWQoKSBh
bmQKeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKCkgdG8gdmVyaXR5IHRoZSBpbnRlZ3JpdHkgb2Yg
dGhlIFRMU0YgbWF0cml4LgoKU2lnbmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0
ZGVmZW5kZXIuY29tPgoKLS0tCkNoYW5nZXMgc2luY2UgdjM6CiAtIHRyeSBoYXJkZXIgdG8gcmVz
cGVjdCB0aGUgODAgY29sdW1uIGxpbWl0CiAtIHVzZSAndW5zaWduZWQgaW50JyBpbnN0ZWFkIG9m
ICdpbnQnIHdoZXJlIHBvc3NpYmxlCiAtIG1hZGUgdGhlIGxvZ2dlZCBtZXNzYWdlcyBldmVuIHNo
b3J0ZXIKIC0gZHJvcHBlZCB0aGUgdXNlIG9mIGdvdG8gKGRpZG4ndCByZWFsbHkgbWFrZSBzZW5z
ZSkKCkNoYW5nZXMgc2luY2UgdjI6CiAtIHByaW50IHRoZSBuYW1lIG9mIHRoZSBjb3JydXB0ZWQg
cG9vbAogLSBhZGp1c3RlZCB0aGUgbWVzc2FnZXMgdG8gYmV0dGVyIGZpdCB3aXRoaW4gODAgY29s
dW1ucwogLSBtaW5vciBzdHlsZSBjaGFuZ2UgKGEgPyBhIDogYiAtPiBhID86IGIpCgpDaGFuZ2Vz
IHNpbmNlIHYxOgogLSBmaXhlZCB0aGUgY29kaW5nc3R5bGUKIC0gc3dhcGVkIF9sb2NrZWQvX3Vu
bG9ja2VkIG5hbWluZwogLSByZXdvcmtlZCBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoKSBhIGJp
dAogLSB1c2VkIGJvb2xfdCB3aGVyZSBhcHByb3ByaWF0ZQogLSBtYWRlIHhtZW1fcG9vbF9jaGVj
aygpIHRha2UgYSBwb29sIGFyZ3VtZW50IHdoaWNoIGNhbiBiZSBOVUxMCi0tLQogeGVuL2NvbW1v
bi94bWFsbG9jX3Rsc2YuYyB8IDEyMSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKystCiB4ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oIHwgICA3ICsrKwogMiBmaWxl
cyBjaGFuZ2VkLCAxMjYgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg
YS94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jIGIveGVuL2NvbW1vbi94bWFsbG9jX3Rsc2YuYwpp
bmRleCBhNTc2OWM5Li5lY2E0ZjFjIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3htYWxsb2NfdGxz
Zi5jCisrKyBiL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMKQEAgLTEyMCw5ICsxMjAsMTIyIEBA
IHN0cnVjdCB4bWVtX3Bvb2wgewogICAgIGNoYXIgbmFtZVtNQVhfUE9PTF9OQU1FX0xFTl07CiB9
OwogCitzdGF0aWMgc3RydWN0IHhtZW1fcG9vbCAqeGVucG9vbDsKKworc3RhdGljIGlubGluZSB2
b2lkIE1BUFBJTkdfSU5TRVJUKHVuc2lnbmVkIGxvbmcgciwgaW50ICpmbCwgaW50ICpzbCk7CisK
IC8qCiAgKiBIZWxwaW5nIGZ1bmN0aW9ucwogICovCisjaWZuZGVmIE5ERUJVRworc3RhdGljIGJv
b2xfdCB4bWVtX3Bvb2xfY2hlY2tfc2l6ZShjb25zdCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sLAor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgZmwsIGludCBzbCkKK3sKKyAg
ICBjb25zdCBzdHJ1Y3QgYmhkciAqYiA9IHBvb2wtPm1hdHJpeFtmbF1bc2xdOworCisgICAgd2hp
bGUgKCBiICkKKyAgICB7CisgICAgICAgIGludCBfX2ZsOworICAgICAgICBpbnQgX19zbDsKKwor
ICAgICAgICBNQVBQSU5HX0lOU0VSVChiLT5zaXplLCAmX19mbCwgJl9fc2wpOworICAgICAgICBp
ZiAoIF9fZmwgIT0gZmwgfHwgX19zbCAhPSBzbCApCisgICAgICAgIHsKKyAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfRVJSCisgICAgICAgICAgICAgICAgICAgInhtZW1fcG9vbDogJXM6IG1pc3Bs
YWNlZCBibG9jayAlcDoldSAoeyVkLCVkfSAtPiB7JWQsJWR9KVxuIiwKKyAgICAgICAgICAgICAg
ICAgICBwb29sLT5uYW1lLCBiLCBiLT5zaXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOworICAgICAg
ICAgICAgcmV0dXJuIDA7CisgICAgICAgIH0KKyAgICAgICAgYiA9IGItPnB0ci5mcmVlX3B0ci5u
ZXh0OworICAgIH0KKyAgICByZXR1cm4gMTsKK30KKworLyoKKyAqIFRoaXMgZnVuY3Rpb24gbXVz
dCBiZSBjYWxsZWQgZnJvbSBhIGNvbnRleHQgd2hlcmUgcG9vbC0+bG9jayBpcworICogYWxyZWFk
eSBhY3F1aXJlZC4KKyAqCisgKiBSZXR1cm5zIHRydWUgaWYgdGhlIHBvb2wgaGFzIGJlZW4gY29y
cnVwdGVkLCBmYWxzZSBvdGhlcndpc2UKKyAqLworI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfbG9j
a2VkKHBvb2wpIFwKKyAgICBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoX19GSUxFX18sIF9fTElO
RV9fLCBwb29sKQorc3RhdGljIGJvb2xfdCBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoY29uc3Qg
Y2hhciAqZmlsZSwgaW50IGxpbmUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBjb25zdCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQoreworICAgIHVuc2lnbmVkIGludCBp
OworICAgIHN0YXRpYyBib29sX3Qgb25jZSA9IDE7CisKKyAgICBpZiAoICFvbmNlICkKKyAgICAg
ICAgcmV0dXJuIDE7CisgICAgZm9yICggaSA9IDA7IGkgPCBSRUFMX0ZMSTsgaSsrICkKKyAgICB7
CisgICAgICAgIGludCBmbCA9IChwb29sLT5mbF9iaXRtYXAgJiAoMSA8PCBpKSkgPyBpIDogLTE7
CisKKyAgICAgICAgaWYgKCBmbCA+PSAwICkKKyAgICAgICAgeworICAgICAgICAgICAgdW5zaWdu
ZWQgaW50IGo7CisKKyAgICAgICAgICAgIGlmICggIXBvb2wtPnNsX2JpdG1hcFtmbF0gKQorICAg
ICAgICAgICAgeworICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSCisgICAgICAgICAg
ICAgICAgICAgICAgICJ4bWVtX3Bvb2w6ICVzOiBUTFNGIGJpdG1hcCBjb3JydXB0ICghZW1wdHkg
RkwsIGVtcHR5IFNMKVxuIiwKKyAgICAgICAgICAgICAgICAgICAgICAgcG9vbC0+bmFtZSk7Cisg
ICAgICAgICAgICAgICAgX193YXJuKGZpbGUsIGxpbmUpOworICAgICAgICAgICAgICAgIG9uY2Ug
PSAwOworICAgICAgICAgICAgICAgIGJyZWFrOworICAgICAgICAgICAgfQorICAgICAgICAgICAg
Zm9yICggaiA9IDA7IGogPCBNQVhfU0xJOyBqKysgKQorICAgICAgICAgICAgeworICAgICAgICAg
ICAgICAgIGludCBzbCA9IChwb29sLT5zbF9iaXRtYXBbZmxdICYgKDEgPDwgaikpID8gaiA6IC0x
OworCisgICAgICAgICAgICAgICAgaWYgKCBzbCA8IDAgKQorICAgICAgICAgICAgICAgICAgICBj
b250aW51ZTsKKyAgICAgICAgICAgICAgICBpZiAoICFwb29sLT5tYXRyaXhbZmxdW3NsXSApCisg
ICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUgor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgInhtZW1fcG9vbDogJXM6IFRMU0YgYml0bWFwIGNv
cnJ1cHQgKCFtYXRyaXhbJWRdWyVkXSlcbiIsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBw
b29sLT5uYW1lLCBmbCwgc2wpOworICAgICAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGlu
ZSk7CisgICAgICAgICAgICAgICAgICAgIG9uY2UgPSAwOworICAgICAgICAgICAgICAgICAgICBi
cmVhazsKKyAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgaWYgKCAheG1lbV9wb29s
X2NoZWNrX3NpemUocG9vbCwgZmwsIHNsKSApCisgICAgICAgICAgICAgICAgeworICAgICAgICAg
ICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9wb29sOiAlczogVExTRiBjaHVuayBt
YXRyaXggY29ycnVwdFxuIiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHBvb2wtPm5hbWUp
OworICAgICAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGluZSk7CisgICAgICAgICAgICAg
ICAgICAgIG9uY2UgPSAwOworICAgICAgICAgICAgICAgICAgICBicmVhazsKKyAgICAgICAgICAg
ICAgICB9CisgICAgICAgICAgICB9CisgICAgICAgICAgICBpZiAoICFvbmNlICkKKyAgICAgICAg
ICAgICAgICBicmVhazsKKyAgICAgICAgfQorICAgIH0KKyAgICByZXR1cm4gIW9uY2U7Cit9CisK
KyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKHBvb2wpIFwKKyAgICBfX3htZW1fcG9v
bF9jaGVja191bmxvY2tlZChfX0ZJTEVfXywgX19MSU5FX18sIHBvb2wpCitzdGF0aWMgYm9vbF90
IF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLAor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgeG1lbV9wb29s
ICpwb29sKQoreworICAgIGJvb2xfdCBvb3BzOworCisgICAgc3Bpbl9sb2NrKCZwb29sLT5sb2Nr
KTsKKyAgICBvb3BzID0gX194bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wp
OworICAgIHNwaW5fdW5sb2NrKCZwb29sLT5sb2NrKTsKKyAgICByZXR1cm4gb29wczsKK30KKwor
Ym9vbF90IF9feG1lbV9wb29sX2NoZWNrKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBzdHJ1
Y3QgeG1lbV9wb29sICpwb29sKQoreworICAgIHJldHVybiBfX3htZW1fcG9vbF9jaGVja191bmxv
Y2tlZChmaWxlLCBsaW5lLCBwb29sID86IHhlbnBvb2wpOworfQorI2Vsc2UKKyNkZWZpbmUgeG1l
bV9wb29sX2NoZWNrX2xvY2tlZChwb29sKSAoKHZvaWQpKHBvb2wpKQorI2RlZmluZSB4bWVtX3Bv
b2xfY2hlY2tfdW5sb2NrZWQocG9vbCkgKCh2b2lkKShwb29sKSkKKyNlbmRpZgogCiAvKioKICAq
IFJldHVybnMgaW5kZXhlcyAoZmwsIHNsKSBvZiB0aGUgbGlzdCB1c2VkIHRvIHNlcnZlIHJlcXVl
c3Qgb2Ygc2l6ZSByCkBAIC0zODEsNiArNDk0LDggQEAgdm9pZCAqeG1lbV9wb29sX2FsbG9jKHVu
c2lnbmVkIGxvbmcgc2l6ZSwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKICAgICBpbnQgZmwsIHNs
OwogICAgIHVuc2lnbmVkIGxvbmcgdG1wX3NpemU7CiAKKyAgICB4bWVtX3Bvb2xfY2hlY2tfdW5s
b2NrZWQocG9vbCk7CisKICAgICBpZiAoIHBvb2wtPmluaXRfcmVnaW9uID09IE5VTEwgKQogICAg
IHsKICAgICAgICAgaWYgKCAocmVnaW9uID0gcG9vbC0+Z2V0X21lbShwb29sLT5pbml0X3NpemUp
KSA9PSBOVUxMICkKQEAgLTQ0MiwxMSArNTU3LDEzIEBAIHZvaWQgKnhtZW1fcG9vbF9hbGxvYyh1
bnNpZ25lZCBsb25nIHNpemUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCiAKICAgICBwb29sLT51
c2VkX3NpemUgKz0gKGItPnNpemUgJiBCTE9DS19TSVpFX01BU0spICsgQkhEUl9PVkVSSEVBRDsK
IAorICAgIHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCk7CiAgICAgc3Bpbl91bmxvY2soJnBv
b2wtPmxvY2spOwogICAgIHJldHVybiAodm9pZCAqKWItPnB0ci5idWZmZXI7CiAKICAgICAvKiBG
YWlsZWQgYWxsb2MgKi8KICBvdXRfbG9ja2VkOgorICAgIHhtZW1fcG9vbF9jaGVja19sb2NrZWQo
cG9vbCk7CiAgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwogCiAgb3V0OgpAQCAtNDY0LDYg
KzU4MSw3IEBAIHZvaWQgeG1lbV9wb29sX2ZyZWUodm9pZCAqcHRyLCBzdHJ1Y3QgeG1lbV9wb29s
ICpwb29sKQogICAgIGIgPSAoc3RydWN0IGJoZHIgKikoKGNoYXIgKikgcHRyIC0gQkhEUl9PVkVS
SEVBRCk7CiAKICAgICBzcGluX2xvY2soJnBvb2wtPmxvY2spOworICAgIHhtZW1fcG9vbF9jaGVj
a19sb2NrZWQocG9vbCk7CiAgICAgYi0+c2l6ZSB8PSBGUkVFX0JMT0NLOwogICAgIHBvb2wtPnVz
ZWRfc2l6ZSAtPSAoYi0+c2l6ZSAmIEJMT0NLX1NJWkVfTUFTSykgKyBCSERSX09WRVJIRUFEOwog
ICAgIGItPnB0ci5mcmVlX3B0ciA9IChzdHJ1Y3QgZnJlZV9wdHIpIHsgTlVMTCwgTlVMTH07CkBA
IC01MDAsNiArNjE4LDcgQEAgdm9pZCB4bWVtX3Bvb2xfZnJlZSh2b2lkICpwdHIsIHN0cnVjdCB4
bWVtX3Bvb2wgKnBvb2wpCiAgICAgdG1wX2ItPnNpemUgfD0gUFJFVl9GUkVFOwogICAgIHRtcF9i
LT5wcmV2X2hkciA9IGI7CiAgb3V0OgorICAgIHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCk7
CiAgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwogfQogCkBAIC01MTIsOCArNjMxLDYgQEAg
aW50IHhtZW1fcG9vbF9tYXhhbGxvYyhzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQogICogR2x1ZSBm
b3IgeG1hbGxvYygpLgogICovCiAKLXN0YXRpYyBzdHJ1Y3QgeG1lbV9wb29sICp4ZW5wb29sOwot
CiBzdGF0aWMgdm9pZCAqeG1hbGxvY19wb29sX2dldCh1bnNpZ25lZCBsb25nIHNpemUpCiB7CiAg
ICAgQVNTRVJUKHNpemUgPT0gUEFHRV9TSVpFKTsKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hl
bi94bWFsbG9jLmggYi94ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCmluZGV4IDI0YTk5YWMuLmFk
NDg5MzAgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKKysrIGIveGVuL2lu
Y2x1ZGUveGVuL3htYWxsb2MuaApAQCAtMTIzLDQgKzEyMywxMSBAQCB1bnNpZ25lZCBsb25nIHht
ZW1fcG9vbF9nZXRfdXNlZF9zaXplKHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpOwogICovCiB1bnNp
Z25lZCBsb25nIHhtZW1fcG9vbF9nZXRfdG90YWxfc2l6ZShzdHJ1Y3QgeG1lbV9wb29sICpwb29s
KTsKIAorI2lmbmRlZiBOREVCVUcKKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrKHBvb2wpIF9feG1l
bV9wb29sX2NoZWNrKF9fRklMRV9fLCBfX0xJTkVfXywgcG9vbCkKK2Jvb2xfdCBfX3htZW1fcG9v
bF9jaGVjayhjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgc3RydWN0IHhtZW1fcG9vbCAqcG9v
bCk7CisjZWxzZQorI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2socG9vbCkgKCh2b2lkKTApCisjZW5k
aWYKKwogI2VuZGlmIC8qIF9fWE1BTExPQ19IX18gKi8KLS0gCjIuMi4wCgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Dec 16 19:35:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 19: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 1Y0xtN-00042m-Fg; Tue, 16 Dec 2014 19:34:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mdontu@bitdefender.com>) id 1Y0xtM-00042h-NA
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 19:34:44 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	41/DA-25714-45980945; Tue, 16 Dec 2014 19:34:44 +0000
X-Env-Sender: mdontu@bitdefender.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418758482!9585565!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 31007 invoked from network); 16 Dec 2014 19:34:43 -0000
Received: from mx01.buh.bitdefender.com (HELO mx.bitdefender.com)
	(91.199.104.161)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Dec 2014 19:34:43 -0000
Comment: DomainKeys? See http://domainkeys.sourceforge.net/
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com;
	b=X90IqrrLF2+wEix9BFsTHRSkw1p8OdBm4TsGprXsASK6EKPLj6YE5xSKuxTUqn+1NtNXGv15p8s5MCEowdKSdZO3KEff8qr1fzycN7qDGR80+Jh5+H2BOcUj4sGxf2R4fLf+zZ2ROBHeoC07r8Zd6ddTjmM7JtM3g5+O46vkhbEzgS+jg/IiCdt8hY+kmKueZAJ7H3O2bg7OZnUzKt+kgjUKldnSS/ikV8HZxb90krjCyBy6+jZsRBLpNZsRtLaKUmJFmCSmMvIIB7OAPfS7l+Vo6/ovGYn4l8Iopb2rwTldGxO2tGuwO6SWXwCrpgYrPa04F46qqv6Na5Tve3r6eA==;
	h=Received:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:MIME-Version: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=from:to
	:cc:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=TUervrCkuarKcjrQHb2ANv
	YIMgE=; b=l+5sQvSxMcgOOWP+x2BD2teZpLPKzNinO1s7CcjQFyo7EbiYLf1Ch+
	fkuZbJ0WbPsTuLovYAxGIt/C4ULNwHcnQsIXieTE2L4+khpM0JBFMj0Ulk5APtjv
	v029aP0FVYbIxC3ZbGg5YpqThYKsGR7hZ42eZauIl+byIN8riKcMBx6+spdPgijF
	iUmHDtPBJQQqmfXGd5wKHYmsGFipd5iFcs60eRsjRmbEz3snJxDkNPA3yNoE0jRn
	hzlBC/fRJd2Vq4Ufu+WYeEn3C4PjiJI3VNLMbC4HJiq5wVJcJSdMwPU4iot9Y+wn
	XYu6KcoE05UfngUkvlLgwskfTzNGb3eg==
Received: (qmail 20256 invoked from network); 16 Dec 2014 21:34:41 +0200
Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103)
	by mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP;
	16 Dec 2014 21:34:41 +0200
Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76])
	by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 4E31B80438
	for <xen-devel@lists.xen.org>; Tue, 16 Dec 2014 21:34:41 +0200 (EET)
Received: (qmail 12653 invoked from network); 16 Dec 2014 21:34:41 +0200
Received: from unknown (HELO mdontu-l.dsd.bitdefender.biz)
	(mdontu@bitdefender.com@195.210.5.22)
	by smtp02.buh.bitdefender.net with SMTP; 16 Dec 2014 21:34:40 +0200
From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= <mdontu@bitdefender.com>
To: xen-devel@lists.xen.org
Date: Tue, 16 Dec 2014 21:33:25 +0200
Message-Id: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
X-Mailer: git-send-email 2.2.0
MIME-Version: 1.0
Content-Length: 9240
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.4 on
	smtp02.buh.bitdefender.net, sigver: 7.58337
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.15.5.538, Dats: 374748,
	Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled],
	APM: [Enabled, Score: 500, Flags: 5D42B0B5; 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.1.4; Id: 2m1ghdn.199a3dmp4.7fp1],
	total: 0(775)
X-BitDefender-CF-Stamp: none
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: [Xen-devel] [PATCH v4] xmalloc: add support for checking the pool
	integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SW1wbGVtZW50ZWQgeG1lbV9wb29sX2NoZWNrKCksIHhtZW1fcG9vbF9jaGVja19sb2NrZWQoKSBh
bmQKeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKCkgdG8gdmVyaXR5IHRoZSBpbnRlZ3JpdHkgb2Yg
dGhlIFRMU0YgbWF0cml4LgoKU2lnbmVkLW9mZi1ieTogTWloYWkgRG9uyJt1IDxtZG9udHVAYml0
ZGVmZW5kZXIuY29tPgoKLS0tCkNoYW5nZXMgc2luY2UgdjM6CiAtIHRyeSBoYXJkZXIgdG8gcmVz
cGVjdCB0aGUgODAgY29sdW1uIGxpbWl0CiAtIHVzZSAndW5zaWduZWQgaW50JyBpbnN0ZWFkIG9m
ICdpbnQnIHdoZXJlIHBvc3NpYmxlCiAtIG1hZGUgdGhlIGxvZ2dlZCBtZXNzYWdlcyBldmVuIHNo
b3J0ZXIKIC0gZHJvcHBlZCB0aGUgdXNlIG9mIGdvdG8gKGRpZG4ndCByZWFsbHkgbWFrZSBzZW5z
ZSkKCkNoYW5nZXMgc2luY2UgdjI6CiAtIHByaW50IHRoZSBuYW1lIG9mIHRoZSBjb3JydXB0ZWQg
cG9vbAogLSBhZGp1c3RlZCB0aGUgbWVzc2FnZXMgdG8gYmV0dGVyIGZpdCB3aXRoaW4gODAgY29s
dW1ucwogLSBtaW5vciBzdHlsZSBjaGFuZ2UgKGEgPyBhIDogYiAtPiBhID86IGIpCgpDaGFuZ2Vz
IHNpbmNlIHYxOgogLSBmaXhlZCB0aGUgY29kaW5nc3R5bGUKIC0gc3dhcGVkIF9sb2NrZWQvX3Vu
bG9ja2VkIG5hbWluZwogLSByZXdvcmtlZCBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoKSBhIGJp
dAogLSB1c2VkIGJvb2xfdCB3aGVyZSBhcHByb3ByaWF0ZQogLSBtYWRlIHhtZW1fcG9vbF9jaGVj
aygpIHRha2UgYSBwb29sIGFyZ3VtZW50IHdoaWNoIGNhbiBiZSBOVUxMCi0tLQogeGVuL2NvbW1v
bi94bWFsbG9jX3Rsc2YuYyB8IDEyMSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKystCiB4ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oIHwgICA3ICsrKwogMiBmaWxl
cyBjaGFuZ2VkLCAxMjYgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg
YS94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jIGIveGVuL2NvbW1vbi94bWFsbG9jX3Rsc2YuYwpp
bmRleCBhNTc2OWM5Li5lY2E0ZjFjIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3htYWxsb2NfdGxz
Zi5jCisrKyBiL3hlbi9jb21tb24veG1hbGxvY190bHNmLmMKQEAgLTEyMCw5ICsxMjAsMTIyIEBA
IHN0cnVjdCB4bWVtX3Bvb2wgewogICAgIGNoYXIgbmFtZVtNQVhfUE9PTF9OQU1FX0xFTl07CiB9
OwogCitzdGF0aWMgc3RydWN0IHhtZW1fcG9vbCAqeGVucG9vbDsKKworc3RhdGljIGlubGluZSB2
b2lkIE1BUFBJTkdfSU5TRVJUKHVuc2lnbmVkIGxvbmcgciwgaW50ICpmbCwgaW50ICpzbCk7CisK
IC8qCiAgKiBIZWxwaW5nIGZ1bmN0aW9ucwogICovCisjaWZuZGVmIE5ERUJVRworc3RhdGljIGJv
b2xfdCB4bWVtX3Bvb2xfY2hlY2tfc2l6ZShjb25zdCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sLAor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgZmwsIGludCBzbCkKK3sKKyAg
ICBjb25zdCBzdHJ1Y3QgYmhkciAqYiA9IHBvb2wtPm1hdHJpeFtmbF1bc2xdOworCisgICAgd2hp
bGUgKCBiICkKKyAgICB7CisgICAgICAgIGludCBfX2ZsOworICAgICAgICBpbnQgX19zbDsKKwor
ICAgICAgICBNQVBQSU5HX0lOU0VSVChiLT5zaXplLCAmX19mbCwgJl9fc2wpOworICAgICAgICBp
ZiAoIF9fZmwgIT0gZmwgfHwgX19zbCAhPSBzbCApCisgICAgICAgIHsKKyAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfRVJSCisgICAgICAgICAgICAgICAgICAgInhtZW1fcG9vbDogJXM6IG1pc3Bs
YWNlZCBibG9jayAlcDoldSAoeyVkLCVkfSAtPiB7JWQsJWR9KVxuIiwKKyAgICAgICAgICAgICAg
ICAgICBwb29sLT5uYW1lLCBiLCBiLT5zaXplLCBmbCwgc2wsIF9fZmwsIF9fc2wpOworICAgICAg
ICAgICAgcmV0dXJuIDA7CisgICAgICAgIH0KKyAgICAgICAgYiA9IGItPnB0ci5mcmVlX3B0ci5u
ZXh0OworICAgIH0KKyAgICByZXR1cm4gMTsKK30KKworLyoKKyAqIFRoaXMgZnVuY3Rpb24gbXVz
dCBiZSBjYWxsZWQgZnJvbSBhIGNvbnRleHQgd2hlcmUgcG9vbC0+bG9jayBpcworICogYWxyZWFk
eSBhY3F1aXJlZC4KKyAqCisgKiBSZXR1cm5zIHRydWUgaWYgdGhlIHBvb2wgaGFzIGJlZW4gY29y
cnVwdGVkLCBmYWxzZSBvdGhlcndpc2UKKyAqLworI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfbG9j
a2VkKHBvb2wpIFwKKyAgICBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoX19GSUxFX18sIF9fTElO
RV9fLCBwb29sKQorc3RhdGljIGJvb2xfdCBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoY29uc3Qg
Y2hhciAqZmlsZSwgaW50IGxpbmUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBjb25zdCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQoreworICAgIHVuc2lnbmVkIGludCBp
OworICAgIHN0YXRpYyBib29sX3Qgb25jZSA9IDE7CisKKyAgICBpZiAoICFvbmNlICkKKyAgICAg
ICAgcmV0dXJuIDE7CisgICAgZm9yICggaSA9IDA7IGkgPCBSRUFMX0ZMSTsgaSsrICkKKyAgICB7
CisgICAgICAgIGludCBmbCA9IChwb29sLT5mbF9iaXRtYXAgJiAoMSA8PCBpKSkgPyBpIDogLTE7
CisKKyAgICAgICAgaWYgKCBmbCA+PSAwICkKKyAgICAgICAgeworICAgICAgICAgICAgdW5zaWdu
ZWQgaW50IGo7CisKKyAgICAgICAgICAgIGlmICggIXBvb2wtPnNsX2JpdG1hcFtmbF0gKQorICAg
ICAgICAgICAgeworICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSCisgICAgICAgICAg
ICAgICAgICAgICAgICJ4bWVtX3Bvb2w6ICVzOiBUTFNGIGJpdG1hcCBjb3JydXB0ICghZW1wdHkg
RkwsIGVtcHR5IFNMKVxuIiwKKyAgICAgICAgICAgICAgICAgICAgICAgcG9vbC0+bmFtZSk7Cisg
ICAgICAgICAgICAgICAgX193YXJuKGZpbGUsIGxpbmUpOworICAgICAgICAgICAgICAgIG9uY2Ug
PSAwOworICAgICAgICAgICAgICAgIGJyZWFrOworICAgICAgICAgICAgfQorICAgICAgICAgICAg
Zm9yICggaiA9IDA7IGogPCBNQVhfU0xJOyBqKysgKQorICAgICAgICAgICAgeworICAgICAgICAg
ICAgICAgIGludCBzbCA9IChwb29sLT5zbF9iaXRtYXBbZmxdICYgKDEgPDwgaikpID8gaiA6IC0x
OworCisgICAgICAgICAgICAgICAgaWYgKCBzbCA8IDAgKQorICAgICAgICAgICAgICAgICAgICBj
b250aW51ZTsKKyAgICAgICAgICAgICAgICBpZiAoICFwb29sLT5tYXRyaXhbZmxdW3NsXSApCisg
ICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUgor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgInhtZW1fcG9vbDogJXM6IFRMU0YgYml0bWFwIGNv
cnJ1cHQgKCFtYXRyaXhbJWRdWyVkXSlcbiIsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBw
b29sLT5uYW1lLCBmbCwgc2wpOworICAgICAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGlu
ZSk7CisgICAgICAgICAgICAgICAgICAgIG9uY2UgPSAwOworICAgICAgICAgICAgICAgICAgICBi
cmVhazsKKyAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgaWYgKCAheG1lbV9wb29s
X2NoZWNrX3NpemUocG9vbCwgZmwsIHNsKSApCisgICAgICAgICAgICAgICAgeworICAgICAgICAg
ICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAieG1lbV9wb29sOiAlczogVExTRiBjaHVuayBt
YXRyaXggY29ycnVwdFxuIiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHBvb2wtPm5hbWUp
OworICAgICAgICAgICAgICAgICAgICBfX3dhcm4oZmlsZSwgbGluZSk7CisgICAgICAgICAgICAg
ICAgICAgIG9uY2UgPSAwOworICAgICAgICAgICAgICAgICAgICBicmVhazsKKyAgICAgICAgICAg
ICAgICB9CisgICAgICAgICAgICB9CisgICAgICAgICAgICBpZiAoICFvbmNlICkKKyAgICAgICAg
ICAgICAgICBicmVhazsKKyAgICAgICAgfQorICAgIH0KKyAgICByZXR1cm4gIW9uY2U7Cit9CisK
KyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKHBvb2wpIFwKKyAgICBfX3htZW1fcG9v
bF9jaGVja191bmxvY2tlZChfX0ZJTEVfXywgX19MSU5FX18sIHBvb2wpCitzdGF0aWMgYm9vbF90
IF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLAor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgeG1lbV9wb29s
ICpwb29sKQoreworICAgIGJvb2xfdCBvb3BzOworCisgICAgc3Bpbl9sb2NrKCZwb29sLT5sb2Nr
KTsKKyAgICBvb3BzID0gX194bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wp
OworICAgIHNwaW5fdW5sb2NrKCZwb29sLT5sb2NrKTsKKyAgICByZXR1cm4gb29wczsKK30KKwor
Ym9vbF90IF9feG1lbV9wb29sX2NoZWNrKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBzdHJ1
Y3QgeG1lbV9wb29sICpwb29sKQoreworICAgIHJldHVybiBfX3htZW1fcG9vbF9jaGVja191bmxv
Y2tlZChmaWxlLCBsaW5lLCBwb29sID86IHhlbnBvb2wpOworfQorI2Vsc2UKKyNkZWZpbmUgeG1l
bV9wb29sX2NoZWNrX2xvY2tlZChwb29sKSAoKHZvaWQpKHBvb2wpKQorI2RlZmluZSB4bWVtX3Bv
b2xfY2hlY2tfdW5sb2NrZWQocG9vbCkgKCh2b2lkKShwb29sKSkKKyNlbmRpZgogCiAvKioKICAq
IFJldHVybnMgaW5kZXhlcyAoZmwsIHNsKSBvZiB0aGUgbGlzdCB1c2VkIHRvIHNlcnZlIHJlcXVl
c3Qgb2Ygc2l6ZSByCkBAIC0zODEsNiArNDk0LDggQEAgdm9pZCAqeG1lbV9wb29sX2FsbG9jKHVu
c2lnbmVkIGxvbmcgc2l6ZSwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKICAgICBpbnQgZmwsIHNs
OwogICAgIHVuc2lnbmVkIGxvbmcgdG1wX3NpemU7CiAKKyAgICB4bWVtX3Bvb2xfY2hlY2tfdW5s
b2NrZWQocG9vbCk7CisKICAgICBpZiAoIHBvb2wtPmluaXRfcmVnaW9uID09IE5VTEwgKQogICAg
IHsKICAgICAgICAgaWYgKCAocmVnaW9uID0gcG9vbC0+Z2V0X21lbShwb29sLT5pbml0X3NpemUp
KSA9PSBOVUxMICkKQEAgLTQ0MiwxMSArNTU3LDEzIEBAIHZvaWQgKnhtZW1fcG9vbF9hbGxvYyh1
bnNpZ25lZCBsb25nIHNpemUsIHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCiAKICAgICBwb29sLT51
c2VkX3NpemUgKz0gKGItPnNpemUgJiBCTE9DS19TSVpFX01BU0spICsgQkhEUl9PVkVSSEVBRDsK
IAorICAgIHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCk7CiAgICAgc3Bpbl91bmxvY2soJnBv
b2wtPmxvY2spOwogICAgIHJldHVybiAodm9pZCAqKWItPnB0ci5idWZmZXI7CiAKICAgICAvKiBG
YWlsZWQgYWxsb2MgKi8KICBvdXRfbG9ja2VkOgorICAgIHhtZW1fcG9vbF9jaGVja19sb2NrZWQo
cG9vbCk7CiAgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwogCiAgb3V0OgpAQCAtNDY0LDYg
KzU4MSw3IEBAIHZvaWQgeG1lbV9wb29sX2ZyZWUodm9pZCAqcHRyLCBzdHJ1Y3QgeG1lbV9wb29s
ICpwb29sKQogICAgIGIgPSAoc3RydWN0IGJoZHIgKikoKGNoYXIgKikgcHRyIC0gQkhEUl9PVkVS
SEVBRCk7CiAKICAgICBzcGluX2xvY2soJnBvb2wtPmxvY2spOworICAgIHhtZW1fcG9vbF9jaGVj
a19sb2NrZWQocG9vbCk7CiAgICAgYi0+c2l6ZSB8PSBGUkVFX0JMT0NLOwogICAgIHBvb2wtPnVz
ZWRfc2l6ZSAtPSAoYi0+c2l6ZSAmIEJMT0NLX1NJWkVfTUFTSykgKyBCSERSX09WRVJIRUFEOwog
ICAgIGItPnB0ci5mcmVlX3B0ciA9IChzdHJ1Y3QgZnJlZV9wdHIpIHsgTlVMTCwgTlVMTH07CkBA
IC01MDAsNiArNjE4LDcgQEAgdm9pZCB4bWVtX3Bvb2xfZnJlZSh2b2lkICpwdHIsIHN0cnVjdCB4
bWVtX3Bvb2wgKnBvb2wpCiAgICAgdG1wX2ItPnNpemUgfD0gUFJFVl9GUkVFOwogICAgIHRtcF9i
LT5wcmV2X2hkciA9IGI7CiAgb3V0OgorICAgIHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCk7
CiAgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwogfQogCkBAIC01MTIsOCArNjMxLDYgQEAg
aW50IHhtZW1fcG9vbF9tYXhhbGxvYyhzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQogICogR2x1ZSBm
b3IgeG1hbGxvYygpLgogICovCiAKLXN0YXRpYyBzdHJ1Y3QgeG1lbV9wb29sICp4ZW5wb29sOwot
CiBzdGF0aWMgdm9pZCAqeG1hbGxvY19wb29sX2dldCh1bnNpZ25lZCBsb25nIHNpemUpCiB7CiAg
ICAgQVNTRVJUKHNpemUgPT0gUEFHRV9TSVpFKTsKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hl
bi94bWFsbG9jLmggYi94ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCmluZGV4IDI0YTk5YWMuLmFk
NDg5MzAgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKKysrIGIveGVuL2lu
Y2x1ZGUveGVuL3htYWxsb2MuaApAQCAtMTIzLDQgKzEyMywxMSBAQCB1bnNpZ25lZCBsb25nIHht
ZW1fcG9vbF9nZXRfdXNlZF9zaXplKHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpOwogICovCiB1bnNp
Z25lZCBsb25nIHhtZW1fcG9vbF9nZXRfdG90YWxfc2l6ZShzdHJ1Y3QgeG1lbV9wb29sICpwb29s
KTsKIAorI2lmbmRlZiBOREVCVUcKKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrKHBvb2wpIF9feG1l
bV9wb29sX2NoZWNrKF9fRklMRV9fLCBfX0xJTkVfXywgcG9vbCkKK2Jvb2xfdCBfX3htZW1fcG9v
bF9jaGVjayhjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgc3RydWN0IHhtZW1fcG9vbCAqcG9v
bCk7CisjZWxzZQorI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2socG9vbCkgKCh2b2lkKTApCisjZW5k
aWYKKwogI2VuZGlmIC8qIF9fWE1BTExPQ19IX18gKi8KLS0gCjIuMi4wCgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yQt-0004lE-Md; Tue, 16 Dec 2014 20:09:23 +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 1Y0yQs-0004l3-5F
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:22 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	4C/AF-27584-17190945; Tue, 16 Dec 2014 20:09:21 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418760560!9589683!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3189 invoked from network); 16 Dec 2014 20:09:20 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:20 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so18362794wgh.32
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=7iEo3OoQF0KRcxGWu63aBJw1GlHCIVIt1PUXCJmnBdc=;
	b=AVFKngnFe/00j0aegZo+2M4PkDNHabntidbiGss91JuC5wToJUihQzOdjywwejCtuD
	WS4jT0iW+fI24KcsOE+zPeAlExUJNrtbjJytJIL2lwt4fj0mqo311blwvE6g4AFoJcdY
	/zezbpeO/5sIi8Bk77ID+Ly1gBsU14JK+3qErnlaWIcCOnrW/KzwMf2ksCBUzDWQ1Mrv
	J+GuuZCvLtqnIH5GuidAp8nMtK+OscMCdkBi9RoYGZqgTRT+ODG7Z81OANQ8fHEUcmh8
	dHrocnOyWa19x7QqlC4/a41BDoI+v6qQqpsp8I82KhHC9+QxT7QMYxv86RAhV6nPA9XQ
	dWfQ==
X-Gm-Message-State: ALoCoQnMUCdbf4PV2MNHVHEdRvs/xXXIOsNjV4k48ojf1Qi3C/tbaBsN57skSpUuk4AuwABsppIq
X-Received: by 10.194.108.98 with SMTP id hj2mr65710399wjb.102.1418760560238; 
	Tue, 16 Dec 2014 12:09:20 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.18
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:19 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:43 +0000
Message-Id: <1418760534-18163-3-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 02/13] xen/arm: vgic: Drop unecessary
	include asm/device.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

The header asm/device.h has been included in the vgic code during
splitting to support multiple version. But no code within those files
requires it.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/vgic-v2.c | 1 -
 xen/arch/arm/vgic-v3.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 1369f78..259d04f 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -26,7 +26,6 @@
 #include <xen/sched.h>
 
 #include <asm/current.h>
-#include <asm/device.h>
 
 #include <asm/mmio.h>
 #include <asm/gic.h>
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index ff99e50..da27605 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -27,7 +27,6 @@
 #include <xen/sched.h>
 #include <xen/sizes.h>
 #include <asm/current.h>
-#include <asm/device.h>
 #include <asm/mmio.h>
 #include <asm/gic_v3_defs.h>
 #include <asm/gic.h>
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yRA-0004tU-NO; Tue, 16 Dec 2014 20:09:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Y0yR9-0004r7-06
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:39 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	1E/B0-17735-28190945; Tue, 16 Dec 2014 20:09:38 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418760577!13701295!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30414 invoked from network); 16 Dec 2014 20:09:37 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:37 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so18363402wgh.32
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:in-reply-to
	:references;
	bh=KjaTxnjl8hQiADC0gkrtIY9FvnSCbtTlJs7PVFDewSM=;
	b=ViI+UVA9rKCbDHJGpFlMqBmad3+sxOoGn0w+hkYqQVBJSh8zaUno65A9K/zFitxp1F
	nkVrnznUE5aPK5gQk2xqvScaCA/7Jcm1FZcv6MXnpkihW2QUH2C0QRIXHOqNYY94e4gj
	Zl32+T3BCUkImzO5eQ5k0e903i2znGaoxts7DCDFXbTB6+xyKTH9+Pu1KDVy4o24IssA
	uX8Ig/gXNuYjLMG+gKxM5BUKkTyEvVUyKNvu0uLbCfR4MbJOPsv9StJ9N5ghxre8WWQM
	Z2UrhleWYZm0z4xT73EMFKg6vUef9b0951qyEc4odRafFyIpauOYSexdgQcZzm0MMBZo
	H1jw==
X-Gm-Message-State: ALoCoQn6Mhy2Fl+jpiEJftvsLgZ8h715E778bq/CEz2yRzD9xn2FEsq5gWRrdRvjx2E46aiMFpvH
X-Received: by 10.194.222.98 with SMTP id ql2mr65819715wjc.36.1418760576146;
	Tue, 16 Dec 2014 12:09:36 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.34
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:35 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:52 +0000
Message-Id: <1418760534-18163-12-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: ian.campbell@citrix.com,
	Andreas Herrmann <herrmann.der.user@googlemail.com>,
	manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com,
	Andreas Herrmann <andreas.herrmann@calxeda.com>
Subject: [Xen-devel] [PATCH for 4.6 11/13] xen/iommu: smmu: Check for
	duplicate stream IDs when registering master 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

From: Andreas Herrmann <andreas.herrmann@calxeda.com>

If DT information lists one stream ID twice for the master devices of
an SMMU this can cause a multi match when stream ID matching is used.
For stream ID indexing this might trigger an overwrite of an S2CR that
is already in use.

So better check for duplicates when DT information is parsed.

Taken from the linux ML:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226099.html

Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/drivers/passthrough/arm/smmu.c | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
index 6cd47b7..bfc1069 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -51,6 +51,9 @@
 /* Maximum number of stream IDs assigned to a single device */
 #define MAX_MASTER_STREAMIDS		MAX_PHANDLE_ARGS
 
+/* Maximum stream ID */
+#define ARM_SMMU_MAX_STREAMID		(SZ_64K - 1)
+
 /* Maximum number of context banks per SMMU */
 #define ARM_SMMU_MAX_CBS		128
 
@@ -519,7 +522,8 @@ static int insert_smmu_master(struct arm_smmu_device *smmu,
 
 static int register_smmu_master(struct arm_smmu_device *smmu,
 				struct device *dev,
-				struct of_phandle_args *masterspec)
+				struct of_phandle_args *masterspec,
+				unsigned long *smmu_sids)
 {
 	int i;
 	struct arm_smmu_master *master;
@@ -556,6 +560,12 @@ static int register_smmu_master(struct arm_smmu_device *smmu,
 				masterspec->np->name, smmu->num_mapping_groups);
 			return -ERANGE;
 		}
+
+		if (test_and_set_bit(streamid, smmu_sids)) {
+			dev_err(dev, "duplicate stream ID (%d)\n", streamid);
+			return -EEXIST;
+		}
+
 		master->cfg.streamids[i] = streamid;
 	}
 	return insert_smmu_master(smmu, master);
@@ -1977,6 +1987,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct rb_node *node;
 	struct of_phandle_args masterspec;
+	unsigned long *smmu_sids;
 	int num_irqs, i, err;
 
 	smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
@@ -2035,20 +2046,30 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 	if (err)
 		return err;
 
+	smmu_sids = kzalloc(BITS_TO_LONGS(ARM_SMMU_MAX_STREAMID) *
+			sizeof(long), GFP_KERNEL);
+	if (!smmu_sids) {
+		dev_err(dev,
+			"failed to allocate bitmap for stream ID tracking\n");
+		return -ENOMEM;
+	}
+
 	i = 0;
 	smmu->masters = RB_ROOT;
 	while (!of_parse_phandle_with_args(dev->of_node, "mmu-masters",
 					   "#stream-id-cells", i,
 					   &masterspec)) {
-		err = register_smmu_master(smmu, dev, &masterspec);
+		err = register_smmu_master(smmu, dev, &masterspec, smmu_sids);
 		if (err) {
 			dev_err(dev, "failed to add master %s\n",
 				masterspec.np->name);
+			kfree(smmu_sids);
 			goto out_put_masters;
 		}
 
 		i++;
 	}
+	kfree(smmu_sids);
 	dev_notice(dev, "registered %d master devices\n", i);
 
 	parse_driver_options(smmu);
-- 
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 Dec 16 20:09:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0yRC-0004v8-8G; Tue, 16 Dec 2014 20:09: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 1Y0yRA-0004sc-EK
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:40 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	87/61-28865-38190945; Tue, 16 Dec 2014 20:09:39 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418760578!13709243!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13929 invoked from network); 16 Dec 2014 20:09:39 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:39 -0000
Received: by mail-wg0-f51.google.com with SMTP id x12so18238783wgg.38
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=22HiC/jsQkEfpC/jk6dpNNLJ4CAft6EavTkjDz75u0A=;
	b=P87DUPw5+Xs3WKv8BEqDDUogAwfqgvpdhqN4PKVFV4LWbAregMRSFMRwWIdRq9VbX4
	E6Lrxu1qT627dZcznHSOYbyDLwPaPSzSdFL+MelxmhxoTsfr1ZKHyFaEf9HDJbqEdRJC
	KBhg/i5pvLeDBjWqa9SKVguqdhRNeSJfM+UP1vGdaa9O4uJh5kicUnzleFKp7gqFRa0L
	xxrkU+NQ0W8kO/obnvmZAzPSYWkh+4nV/cjEDMOg3fmwnYFxUNqHjlmAWckP66Hr7IgW
	nYLYhQ34gFjRQYo54DKoOP3e6TwcGiAeL0xAnf4XD5+ubiQUzOxDUgQRiolIBUIMvLTO
	TQ9w==
X-Gm-Message-State: ALoCoQlVWwL9BJK2C1W8ASTTu6pXOd7IcQp3TODzswSvO2OecAKh+Um+VghZNovuysQ6hrBTM29I
X-Received: by 10.180.11.140 with SMTP id q12mr7757101wib.45.1418760577637;
	Tue, 16 Dec 2014 12:09:37 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.36
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:36 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:53 +0000
Message-Id: <1418760534-18163-13-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: ian.campbell@citrix.com,
	Andreas Herrmann <herrmann.der.user@googlemail.com>,
	manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com,
	Andreas Herrmann <andreas.herrmann@calxeda.com>
Subject: [Xen-devel] [PATCH for 4.6 12/13] xen/iommu: smmu: Introduce
	automatic stream-id-masking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Andreas Herrmann <andreas.herrmann@calxeda.com>

Try to determine mask/id values that match several stream IDs of a
master device when doing Stream ID matching. Thus the number of used
SMR groups that are required to map all stream IDs of a master device
to a context should be less than the number of SMR groups used so far
(currently one SMR group is used for one stream ID).

Taken from the Linux ML:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226100.html

Changes compare to the Linux ML version:
    - _fls doesn't exist on Xen so use fls
    - Use num_s2crs rather than num_streamids in the arm_smmu_free_smrs.
    This former is the field used to configure SRMS

Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/drivers/passthrough/arm/smmu.c | 177 +++++++++++++++++++++++++++++++++----
 1 file changed, 162 insertions(+), 15 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
index bfc1069..8a6514f 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -43,6 +43,7 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/bitops.h>
 
 #include <linux/amba/bus.h>
 
@@ -346,8 +347,10 @@ struct arm_smmu_smr {
 };
 
 struct arm_smmu_master_cfg {
-	int				num_streamids;
+	u32				num_streamids;
 	u16				streamids[MAX_MASTER_STREAMIDS];
+	int				num_s2crs;
+
 	struct arm_smmu_smr		*smrs;
 };
 
@@ -392,6 +395,9 @@ struct arm_smmu_device {
 	u32				num_context_irqs;
 	unsigned int			*irqs;
 
+	u32				smr_mask_mask;
+	u32				smr_id_mask;
+
 	struct list_head		list;
 	struct rb_root			masters;
 };
@@ -1113,6 +1119,137 @@ static void arm_smmu_free_pgtables(struct arm_smmu_domain *smmu_domain)
 	kfree(pgd_base);
 }
 
+/*
+ * For a given set N of 2**order different stream IDs (no duplicates
+ * please!) we determine values mask and id such that
+ *
+ * (1)          (x & mask) == id
+ *
+ * for each stream ID x from the given set N.
+ *
+ * If the number of bits that are set in mask equals n, then there
+ * exist 2**n different values y for which
+ *
+ * (2)          (y & mask) == id
+ *
+ * Thus if n equals order we know that for the calculated mask and id
+ * values there are exactly 2**order == 2**n stream IDs for which (1)
+ * is true. And we finally can use mask and id to configure an SMR to
+ * match all stream IDs in the set N.
+ */
+static int determine_smr_mask(struct arm_smmu_device *smmu,
+			      struct arm_smmu_master_cfg *cfg,
+			      struct arm_smmu_smr *smr, int start, int order)
+{
+	u16 i, zero_bits_mask, one_bits_mask, const_mask;
+	int nr;
+
+	nr = 1 << order;
+
+	if (nr == 1) {
+		/* no mask, use streamid to match and be done with it */
+		smr->mask = 0;
+		smr->id = cfg->streamids[start];
+		return 0;
+	}
+
+	zero_bits_mask = 0;
+	one_bits_mask = 0xffff;
+	for (i = start; i < start + nr; i++) {
+		zero_bits_mask |= cfg->streamids[i];	/* const 0 bits */
+		one_bits_mask &= cfg->streamids[i];	/* const 1 bits */
+	}
+	zero_bits_mask = ~zero_bits_mask;
+
+	/* bits having constant values (either 0 or 1) */
+	const_mask = zero_bits_mask | one_bits_mask;
+
+	i = hweight16(~const_mask);
+	if (i == order) {
+		/*
+		 * We have found a mask/id pair that matches exactly
+		 * nr = 2**order stream IDs which we used for its
+		 * calculation.
+		 */
+		smr->mask = ~const_mask;
+		smr->id = one_bits_mask;
+	} else {
+		/*
+		 * No usable mask/id pair for this set of streamids.
+		 * If i > order then mask/id would match more than nr
+		 * streamids.
+		 * If i < order then mask/id would match less than nr
+		 * streamids. (In this case we potentially have used
+		 * some duplicate streamids for the calculation.)
+		 */
+		return 1;
+	}
+
+	if (((smr->mask & smmu->smr_mask_mask) != smr->mask) ||
+		((smr->id & smmu->smr_id_mask) != smr->id))
+		/* insufficient number of mask/id bits */
+		return 1;
+
+	return 0;
+}
+
+static int determine_smr_mapping(struct arm_smmu_device *smmu,
+				 struct arm_smmu_master_cfg *cfg,
+				 struct arm_smmu_smr *smrs, int max_smrs)
+{
+	int nr_sid, nr, i, bit, start;
+
+	/*
+	 * This function is called only once -- when a master is added
+	 * to a domain. If cfg->num_s2crs != 0 then this master
+	 * was already added to a domain.
+	 */
+	if (cfg->num_s2crs)
+		return -EINVAL;
+
+	start = nr = 0;
+	nr_sid = cfg->num_streamids;
+	do {
+		/*
+		 * largest power-of-2 number of streamids for which to
+		 * determine a usable mask/id pair for stream matching
+		 */
+		bit = fls(nr_sid) - 1;
+		if (bit < 0)
+			return 0;
+
+		/*
+		 * iterate over power-of-2 numbers to determine
+		 * largest possible mask/id pair for stream matching
+		 * of next 2**i streamids
+		 */
+		for (i = bit; i >= 0; i--) {
+			if (!determine_smr_mask(smmu, cfg,
+						&smrs[cfg->num_s2crs],
+						start, i))
+				break;
+		}
+
+		if (i < 0)
+			goto out;
+
+		nr = 1 << i;
+		nr_sid -= nr;
+		start += nr;
+		cfg->num_s2crs++;
+	} while (cfg->num_s2crs <= max_smrs);
+
+out:
+	if (nr_sid) {
+		/* not enough mapping groups available */
+		cfg->num_s2crs = 0;
+		return -ENOSPC;
+	}
+
+	return 0;
+}
+
+
 static void arm_smmu_domain_destroy(struct iommu_domain *domain)
 {
 	struct arm_smmu_domain *smmu_domain = domain->priv;
@@ -1129,7 +1266,7 @@ static void arm_smmu_domain_destroy(struct iommu_domain *domain)
 static int arm_smmu_master_configure_smrs(struct arm_smmu_device *smmu,
 					  struct arm_smmu_master_cfg *cfg)
 {
-	int i;
+	int i, max_smrs, ret;
 	struct arm_smmu_smr *smrs;
 	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
 
@@ -1139,31 +1276,32 @@ static int arm_smmu_master_configure_smrs(struct arm_smmu_device *smmu,
 	if (cfg->smrs)
 		return -EEXIST;
 
-	smrs = kmalloc_array(cfg->num_streamids, sizeof(*smrs), GFP_KERNEL);
+	max_smrs = min(smmu->num_mapping_groups, cfg->num_streamids);
+	smrs = kmalloc(sizeof(*smrs) * max_smrs, GFP_KERNEL);
 	if (!smrs) {
 		dev_err(smmu->dev, "failed to allocate %d SMRs\n",
-			cfg->num_streamids);
+			max_smrs);
 		return -ENOMEM;
 	}
 
+	ret = determine_smr_mapping(smmu, cfg, smrs, max_smrs);
+	if (ret)
+		goto err_free_smrs;
+
 	/* Allocate the SMRs on the SMMU */
-	for (i = 0; i < cfg->num_streamids; ++i) {
+	for (i = 0; i < cfg->num_s2crs; ++i) {
 		int idx = __arm_smmu_alloc_bitmap(smmu->smr_map, 0,
 						  smmu->num_mapping_groups);
 		if (IS_ERR_VALUE(idx)) {
 			dev_err(smmu->dev, "failed to allocate free SMR\n");
-			goto err_free_smrs;
+			goto err_free_bitmap;
 		}
 
-		smrs[i] = (struct arm_smmu_smr) {
-			.idx	= idx,
-			.mask	= 0, /* We don't currently share SMRs */
-			.id	= cfg->streamids[i],
-		};
+		smrs[i].idx = idx;
 	}
 
 	/* It worked! Now, poke the actual hardware */
-	for (i = 0; i < cfg->num_streamids; ++i) {
+	for (i = 0; i < cfg->num_s2crs; ++i) {
 		u32 reg = SMR_VALID | smrs[i].id << SMR_ID_SHIFT |
 			  smrs[i].mask << SMR_MASK_SHIFT;
 		writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_SMR(smrs[i].idx));
@@ -1172,9 +1310,11 @@ static int arm_smmu_master_configure_smrs(struct arm_smmu_device *smmu,
 	cfg->smrs = smrs;
 	return 0;
 
-err_free_smrs:
+err_free_bitmap:
 	while (--i >= 0)
 		__arm_smmu_free_bitmap(smmu->smr_map, smrs[i].idx);
+	cfg->num_s2crs = 0;
+err_free_smrs:
 	kfree(smrs);
 	return -ENOSPC;
 }
@@ -1190,13 +1330,15 @@ static void arm_smmu_master_free_smrs(struct arm_smmu_device *smmu,
 		return;
 
 	/* Invalidate the SMRs before freeing back to the allocator */
-	for (i = 0; i < cfg->num_streamids; ++i) {
+	for (i = 0; i < cfg->num_s2crs; ++i) {
 		u8 idx = smrs[i].idx;
 
 		writel_relaxed(~SMR_VALID, gr0_base + ARM_SMMU_GR0_SMR(idx));
 		__arm_smmu_free_bitmap(smmu->smr_map, idx);
 	}
 
+	cfg->num_s2crs = 0;
+
 	cfg->smrs = NULL;
 	kfree(smrs);
 }
@@ -1213,12 +1355,15 @@ static int arm_smmu_domain_add_master(struct arm_smmu_domain *smmu_domain,
 	if (ret)
 		return ret == -EEXIST ? 0 : ret;
 
-	for (i = 0; i < cfg->num_streamids; ++i) {
+	if (!cfg->num_s2crs)
+		cfg->num_s2crs = cfg->num_streamids;
+	for (i = 0; i < cfg->num_s2crs; ++i) {
 		u32 idx, s2cr;
 
 		idx = cfg->smrs ? cfg->smrs[i].idx : cfg->streamids[i];
 		s2cr = S2CR_TYPE_TRANS |
 		       (smmu_domain->cfg.cbndx << S2CR_CBNDX_SHIFT);
+		dev_dbg(smmu->dev, "S2CR%d: 0x%x\n", idx, s2cr);
 		writel_relaxed(s2cr, gr0_base + ARM_SMMU_GR0_S2CR(idx));
 	}
 
@@ -1890,6 +2035,8 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
 				mask, sid);
 			return -ENODEV;
 		}
+		smmu->smr_mask_mask = mask;
+		smmu->smr_id_mask = sid;
 
 		dev_notice(smmu->dev,
 			   "\tstream matching with %u register groups, mask 0x%x",
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yQy-0004mW-Et; Tue, 16 Dec 2014 20:09:28 +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 1Y0yQw-0004m6-SQ
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:26 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	23/64-02697-67190945; Tue, 16 Dec 2014 20:09:26 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418760565!13732323!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17798 invoked from network); 16 Dec 2014 20:09:25 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:25 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so14844743wib.1
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=l/HuTzVwQLAYGQ03c/KQMM0l+NZKWle3HG8EqTyC+Ec=;
	b=lTGYTaLEDMQpWUivKTwEO56jVi+WMjuvC56NktOtCjEq5SUpLut+07BJVqDYNsSpCu
	vAb4VF0eZdpyIOh6tk7vViy/3i5MxHPacObx1MdZCAcpvFjVNrUcrJxhOCSAm5wW0MiV
	kkGhxfOJu5sh4+kcT5/PNMxwW+dSoWoU41RK1dlHdCL5PvcJ0RSNVZ7YqZJePV3PlsYt
	Vzo8W+yifEt8lqxW6LaUKz6Hy5YhDZbHcIiaqcDK0ex3iagEXQ3X87cPNIwAsDIM8DnG
	zXz2lYPV4wvpjPRhzvVKOXByGfU9EZrHZXdd1DXyHma51ALAkqPDFGclFti1nxOHrrHg
	bGjA==
X-Gm-Message-State: ALoCoQluryHnqYmvGdtfraz8fbGVN+xOHsY4Mzxpv5MTCqr4Uaq0+3aELb6DqqdLqMA9qBZG5un2
X-Received: by 10.194.242.196 with SMTP id ws4mr32207316wjc.1.1418760565432;
	Tue, 16 Dec 2014 12:09:25 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.23
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:24 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:46 +0000
Message-Id: <1418760534-18163-6-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 05/13] xen/arm: device: Rename
	device_type into device_match
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This enum was used for matching a specific device and not to get the
type of device.

Hence the name device_type will be used for another purpose later.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/device.c        | 4 ++--
 xen/include/asm-arm/device.h | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 59e94c0..693b9af 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -40,7 +40,7 @@ static bool_t __init device_is_compatible(const struct device_desc *desc,
     return 0;
 }
 
-int __init device_init(struct dt_device_node *dev, enum device_type type,
+int __init device_init(struct dt_device_node *dev, enum device_match type,
                        const void *data)
 {
     const struct device_desc *desc;
@@ -67,7 +67,7 @@ int __init device_init(struct dt_device_node *dev, enum device_type type,
     return -EBADF;
 }
 
-enum device_type device_get_type(const struct dt_device_node *dev)
+enum device_match device_get_type(const struct dt_device_node *dev)
 {
     const struct device_desc *desc;
 
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 74a80c6..72a9028 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -4,7 +4,7 @@
 #include <xen/init.h>
 #include <xen/device_tree.h>
 
-enum device_type
+enum device_match
 {
     DEVICE_SERIAL,
     DEVICE_IOMMU,
@@ -17,7 +17,7 @@ struct device_desc {
     /* Device name */
     const char *name;
     /* Device type */
-    enum device_type type;
+    enum device_match type;
     /* Array of device tree 'compatible' strings */
     const char *const *compatible;
     /* Device initialization */
@@ -32,7 +32,7 @@ struct device_desc {
  *
  *  Return 0 on success.
  */
-int __init device_init(struct dt_device_node *dev, enum device_type type,
+int __init device_init(struct dt_device_node *dev, enum device_match type,
                        const void *data);
 
 /**
@@ -41,7 +41,7 @@ int __init device_init(struct dt_device_node *dev, enum device_type type,
  *
  * Return the device type on success or DEVICE_ANY on failure
  */
-enum device_type device_get_type(const struct dt_device_node *dev);
+enum device_match device_get_type(const struct dt_device_node *dev);
 
 #define DT_DEVICE_START(_name, _namestr, _type)                     \
 static const struct device_desc __dev_desc_##_name __used           \
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yR2-0004oH-UO; Tue, 16 Dec 2014 20:09:32 +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 1Y0yR1-0004nY-HE
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:31 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	6B/04-24859-A7190945; Tue, 16 Dec 2014 20:09:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418760567!13854758!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6378 invoked from network); 16 Dec 2014 20:09:27 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:27 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so18393908wgg.19
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=/Gab5CmP+INPq6SF2ADC1M7h2D67CF8nvpnxIOuw4eM=;
	b=K1rvZAQKt5tAUTJAkDxmPjhXsQmYbynZWYLTmd4I5jyR69GVdpaKisqaLXYxrP5Woe
	vPJChszaFk72bGcm47Rf/LSve7vob0IqmBeUiMv2PJ7+I4oNIi72S86XIwGb/q8R+J9L
	mKYcn98Q7TzMGOGgy21SgZQ1nvS/8BUAOlFSKqO4FikNWV8eha19xvn1YsysBcImFFGk
	2+FJznbCt9XHaZxYr60JgyEsk0SKsiooFcNUV6DUEpVM3Rs1UQzRIobTakE6DBYuO4H8
	hXg1q8ZJ/HSd28pScCcyFdEMimWmLo9hgB9kF+CKplHuzw6AzONR3OuyczemHtsFC636
	b5+g==
X-Gm-Message-State: ALoCoQllXB8RXHgJ8R5wYgDkPYUvnXHVmgfaWSF+mO1DeV0VhKf06HNPEXusVjGm+kHCSOSuozQ9
X-Received: by 10.180.75.42 with SMTP id z10mr7758750wiv.70.1418760567101;
	Tue, 16 Dec 2014 12:09:27 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.25
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:26 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:47 +0000
Message-Id: <1418760534-18163-7-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 06/13] xen/iommu: arm: Remove temporary
	the SMMU 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

The current SMMU driver has completly diverged. That makes me hard to
maintain.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/drivers/passthrough/arm/Makefile |    1 -
 xen/drivers/passthrough/arm/smmu.c   | 1784 ----------------------------------
 2 files changed, 1785 deletions(-)
 delete mode 100644 xen/drivers/passthrough/arm/smmu.c

diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile
index f4cd26e..0484b79 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1 @@
 obj-y += iommu.o
-obj-y += smmu.o
diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
deleted file mode 100644
index 42bde75..0000000
--- a/xen/drivers/passthrough/arm/smmu.c
+++ /dev/null
@@ -1,1784 +0,0 @@
-/*
- * IOMMU API for ARM architected SMMU implementations.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- *
- * Based on Linux drivers/iommu/arm-smmu.c (commit 89a23cd)
- * Copyright (C) 2013 ARM Limited
- *
- * Author: Will Deacon <will.deacon@arm.com>
- *
- * Xen modification:
- * Julien Grall <julien.grall@linaro.org>
- * Copyright (C) 2014 Linaro Limited.
- *
- * This driver currently supports:
- *  - SMMUv1 and v2 implementations (didn't try v2 SMMU)
- *  - Stream-matching and stream-indexing
- *  - v7/v8 long-descriptor format
- *  - Non-secure access to the SMMU
- *  - 4k pages, p2m shared with the processor
- *  - Up to 40-bit addressing
- *  - Context fault reporting
- */
-
-#include <xen/config.h>
-#include <xen/delay.h>
-#include <xen/errno.h>
-#include <xen/irq.h>
-#include <xen/lib.h>
-#include <xen/list.h>
-#include <xen/mm.h>
-#include <xen/vmap.h>
-#include <xen/rbtree.h>
-#include <xen/sched.h>
-#include <asm/atomic.h>
-#include <asm/device.h>
-#include <asm/io.h>
-#include <asm/platform.h>
-
-/* Driver options */
-#define SMMU_OPT_SECURE_CONFIG_ACCESS   (1 << 0)
-
-/* Maximum number of stream IDs assigned to a single device */
-#define MAX_MASTER_STREAMIDS    MAX_PHANDLE_ARGS
-
-/* Maximum stream ID */
-#define SMMU_MAX_STREAMIDS      (PAGE_SIZE_64K - 1)
-
-/* Maximum number of context banks per SMMU */
-#define SMMU_MAX_CBS        128
-
-/* Maximum number of mapping groups per SMMU */
-#define SMMU_MAX_SMRS       128
-
-/* SMMU global address space */
-#define SMMU_GR0(smmu)      ((smmu)->base)
-#define SMMU_GR1(smmu)      ((smmu)->base + (smmu)->pagesize)
-
-/*
- * SMMU global address space with conditional offset to access secure aliases of
- * non-secure registers (e.g. nsCR0: 0x400, nsGFSR: 0x448, nsGFSYNR0: 0x450)
- */
-#define SMMU_GR0_NS(smmu)                                   \
-    ((smmu)->base +                                         \
-     ((smmu->options & SMMU_OPT_SECURE_CONFIG_ACCESS)    \
-        ? 0x400 : 0))
-
-/* Page table bits */
-#define SMMU_PTE_PAGE           (((pteval_t)3) << 0)
-#define SMMU_PTE_CONT           (((pteval_t)1) << 52)
-#define SMMU_PTE_AF             (((pteval_t)1) << 10)
-#define SMMU_PTE_SH_NS          (((pteval_t)0) << 8)
-#define SMMU_PTE_SH_OS          (((pteval_t)2) << 8)
-#define SMMU_PTE_SH_IS          (((pteval_t)3) << 8)
-
-#if PAGE_SIZE == PAGE_SIZE_4K
-#define SMMU_PTE_CONT_ENTRIES   16
-#elif PAGE_SIZE == PAGE_SIZE_64K
-#define SMMU_PTE_CONT_ENTRIES   32
-#else
-#define SMMU_PTE_CONT_ENTRIES   1
-#endif
-
-#define SMMU_PTE_CONT_SIZE      (PAGE_SIZE * SMMU_PTE_CONT_ENTRIES)
-#define SMMU_PTE_CONT_MASK      (~(SMMU_PTE_CONT_SIZE - 1))
-#define SMMU_PTE_HWTABLE_SIZE   (PTRS_PER_PTE * sizeof(pte_t))
-
-/* Stage-1 PTE */
-#define SMMU_PTE_AP_UNPRIV      (((pteval_t)1) << 6)
-#define SMMU_PTE_AP_RDONLY      (((pteval_t)2) << 6)
-#define SMMU_PTE_ATTRINDX_SHIFT 2
-#define SMMU_PTE_nG             (((pteval_t)1) << 11)
-
-/* Stage-2 PTE */
-#define SMMU_PTE_HAP_FAULT      (((pteval_t)0) << 6)
-#define SMMU_PTE_HAP_READ       (((pteval_t)1) << 6)
-#define SMMU_PTE_HAP_WRITE      (((pteval_t)2) << 6)
-#define SMMU_PTE_MEMATTR_OIWB   (((pteval_t)0xf) << 2)
-#define SMMU_PTE_MEMATTR_NC     (((pteval_t)0x5) << 2)
-#define SMMU_PTE_MEMATTR_DEV    (((pteval_t)0x1) << 2)
-
-/* Configuration registers */
-#define SMMU_GR0_sCR0           0x0
-#define SMMU_sCR0_CLIENTPD      (1 << 0)
-#define SMMU_sCR0_GFRE          (1 << 1)
-#define SMMU_sCR0_GFIE          (1 << 2)
-#define SMMU_sCR0_GCFGFRE       (1 << 4)
-#define SMMU_sCR0_GCFGFIE       (1 << 5)
-#define SMMU_sCR0_USFCFG        (1 << 10)
-#define SMMU_sCR0_VMIDPNE       (1 << 11)
-#define SMMU_sCR0_PTM           (1 << 12)
-#define SMMU_sCR0_FB            (1 << 13)
-#define SMMU_sCR0_BSU_SHIFT     14
-#define SMMU_sCR0_BSU_MASK      0x3
-
-/* Identification registers */
-#define SMMU_GR0_ID0            0x20
-#define SMMU_GR0_ID1            0x24
-#define SMMU_GR0_ID2            0x28
-#define SMMU_GR0_ID3            0x2c
-#define SMMU_GR0_ID4            0x30
-#define SMMU_GR0_ID5            0x34
-#define SMMU_GR0_ID6            0x38
-#define SMMU_GR0_ID7            0x3c
-#define SMMU_GR0_sGFSR          0x48
-#define SMMU_GR0_sGFSYNR0       0x50
-#define SMMU_GR0_sGFSYNR1       0x54
-#define SMMU_GR0_sGFSYNR2       0x58
-#define SMMU_GR0_PIDR0          0xfe0
-#define SMMU_GR0_PIDR1          0xfe4
-#define SMMU_GR0_PIDR2          0xfe8
-
-#define SMMU_ID0_S1TS           (1 << 30)
-#define SMMU_ID0_S2TS           (1 << 29)
-#define SMMU_ID0_NTS            (1 << 28)
-#define SMMU_ID0_SMS            (1 << 27)
-#define SMMU_ID0_PTFS_SHIFT     24
-#define SMMU_ID0_PTFS_MASK      0x2
-#define SMMU_ID0_PTFS_V8_ONLY   0x2
-#define SMMU_ID0_CTTW           (1 << 14)
-#define SMMU_ID0_NUMIRPT_SHIFT  16
-#define SMMU_ID0_NUMIRPT_MASK   0xff
-#define SMMU_ID0_NUMSMRG_SHIFT  0
-#define SMMU_ID0_NUMSMRG_MASK   0xff
-
-#define SMMU_ID1_PAGESIZE            (1 << 31)
-#define SMMU_ID1_NUMPAGENDXB_SHIFT   28
-#define SMMU_ID1_NUMPAGENDXB_MASK    7
-#define SMMU_ID1_NUMS2CB_SHIFT       16
-#define SMMU_ID1_NUMS2CB_MASK        0xff
-#define SMMU_ID1_NUMCB_SHIFT         0
-#define SMMU_ID1_NUMCB_MASK          0xff
-
-#define SMMU_ID2_OAS_SHIFT           4
-#define SMMU_ID2_OAS_MASK            0xf
-#define SMMU_ID2_IAS_SHIFT           0
-#define SMMU_ID2_IAS_MASK            0xf
-#define SMMU_ID2_UBS_SHIFT           8
-#define SMMU_ID2_UBS_MASK            0xf
-#define SMMU_ID2_PTFS_4K             (1 << 12)
-#define SMMU_ID2_PTFS_16K            (1 << 13)
-#define SMMU_ID2_PTFS_64K            (1 << 14)
-
-#define SMMU_PIDR2_ARCH_SHIFT        4
-#define SMMU_PIDR2_ARCH_MASK         0xf
-
-/* Global TLB invalidation */
-#define SMMU_GR0_STLBIALL           0x60
-#define SMMU_GR0_TLBIVMID           0x64
-#define SMMU_GR0_TLBIALLNSNH        0x68
-#define SMMU_GR0_TLBIALLH           0x6c
-#define SMMU_GR0_sTLBGSYNC          0x70
-#define SMMU_GR0_sTLBGSTATUS        0x74
-#define SMMU_sTLBGSTATUS_GSACTIVE   (1 << 0)
-#define SMMU_TLB_LOOP_TIMEOUT       1000000 /* 1s! */
-
-/* Stream mapping registers */
-#define SMMU_GR0_SMR(n)             (0x800 + ((n) << 2))
-#define SMMU_SMR_VALID              (1 << 31)
-#define SMMU_SMR_MASK_SHIFT         16
-#define SMMU_SMR_MASK_MASK          0x7fff
-#define SMMU_SMR_ID_SHIFT           0
-#define SMMU_SMR_ID_MASK            0x7fff
-
-#define SMMU_GR0_S2CR(n)        (0xc00 + ((n) << 2))
-#define SMMU_S2CR_CBNDX_SHIFT   0
-#define SMMU_S2CR_CBNDX_MASK    0xff
-#define SMMU_S2CR_TYPE_SHIFT    16
-#define SMMU_S2CR_TYPE_MASK     0x3
-#define SMMU_S2CR_TYPE_TRANS    (0 << SMMU_S2CR_TYPE_SHIFT)
-#define SMMU_S2CR_TYPE_BYPASS   (1 << SMMU_S2CR_TYPE_SHIFT)
-#define SMMU_S2CR_TYPE_FAULT    (2 << SMMU_S2CR_TYPE_SHIFT)
-
-/* Context bank attribute registers */
-#define SMMU_GR1_CBAR(n)                    (0x0 + ((n) << 2))
-#define SMMU_CBAR_VMID_SHIFT                0
-#define SMMU_CBAR_VMID_MASK                 0xff
-#define SMMU_CBAR_S1_MEMATTR_SHIFT          12
-#define SMMU_CBAR_S1_MEMATTR_MASK           0xf
-#define SMMU_CBAR_S1_MEMATTR_WB             0xf
-#define SMMU_CBAR_TYPE_SHIFT                16
-#define SMMU_CBAR_TYPE_MASK                 0x3
-#define SMMU_CBAR_TYPE_S2_TRANS             (0 << SMMU_CBAR_TYPE_SHIFT)
-#define SMMU_CBAR_TYPE_S1_TRANS_S2_BYPASS   (1 << SMMU_CBAR_TYPE_SHIFT)
-#define SMMU_CBAR_TYPE_S1_TRANS_S2_FAULT    (2 << SMMU_CBAR_TYPE_SHIFT)
-#define SMMU_CBAR_TYPE_S1_TRANS_S2_TRANS    (3 << SMMU_CBAR_TYPE_SHIFT)
-#define SMMU_CBAR_IRPTNDX_SHIFT             24
-#define SMMU_CBAR_IRPTNDX_MASK              0xff
-
-#define SMMU_GR1_CBA2R(n)                   (0x800 + ((n) << 2))
-#define SMMU_CBA2R_RW64_32BIT               (0 << 0)
-#define SMMU_CBA2R_RW64_64BIT               (1 << 0)
-
-/* Translation context bank */
-#define SMMU_CB_BASE(smmu)                  ((smmu)->base + ((smmu)->size >> 1))
-#define SMMU_CB(smmu, n)                    ((n) * (smmu)->pagesize)
-
-#define SMMU_CB_SCTLR                       0x0
-#define SMMU_CB_RESUME                      0x8
-#define SMMU_CB_TCR2                        0x10
-#define SMMU_CB_TTBR0_LO                    0x20
-#define SMMU_CB_TTBR0_HI                    0x24
-#define SMMU_CB_TCR                         0x30
-#define SMMU_CB_S1_MAIR0                    0x38
-#define SMMU_CB_FSR                         0x58
-#define SMMU_CB_FAR_LO                      0x60
-#define SMMU_CB_FAR_HI                      0x64
-#define SMMU_CB_FSYNR0                      0x68
-#define SMMU_CB_S1_TLBIASID                 0x610
-
-#define SMMU_SCTLR_S1_ASIDPNE               (1 << 12)
-#define SMMU_SCTLR_CFCFG                    (1 << 7)
-#define SMMU_SCTLR_CFIE                     (1 << 6)
-#define SMMU_SCTLR_CFRE                     (1 << 5)
-#define SMMU_SCTLR_E                        (1 << 4)
-#define SMMU_SCTLR_AFE                      (1 << 2)
-#define SMMU_SCTLR_TRE                      (1 << 1)
-#define SMMU_SCTLR_M                        (1 << 0)
-#define SMMU_SCTLR_EAE_SBOP                 (SMMU_SCTLR_AFE | SMMU_SCTLR_TRE)
-
-#define SMMU_RESUME_RETRY                   (0 << 0)
-#define SMMU_RESUME_TERMINATE               (1 << 0)
-
-#define SMMU_TCR_EAE                        (1 << 31)
-
-#define SMMU_TCR_PASIZE_SHIFT               16
-#define SMMU_TCR_PASIZE_MASK                0x7
-
-#define SMMU_TCR_TG0_4K                     (0 << 14)
-#define SMMU_TCR_TG0_64K                    (1 << 14)
-
-#define SMMU_TCR_SH0_SHIFT                  12
-#define SMMU_TCR_SH0_MASK                   0x3
-#define SMMU_TCR_SH_NS                      0
-#define SMMU_TCR_SH_OS                      2
-#define SMMU_TCR_SH_IS                      3
-
-#define SMMU_TCR_ORGN0_SHIFT                10
-#define SMMU_TCR_IRGN0_SHIFT                8
-#define SMMU_TCR_RGN_MASK                   0x3
-#define SMMU_TCR_RGN_NC                     0
-#define SMMU_TCR_RGN_WBWA                   1
-#define SMMU_TCR_RGN_WT                     2
-#define SMMU_TCR_RGN_WB                     3
-
-#define SMMU_TCR_SL0_SHIFT                  6
-#define SMMU_TCR_SL0_MASK                   0x3
-#define SMMU_TCR_SL0_LVL_2                  0
-#define SMMU_TCR_SL0_LVL_1                  1
-
-#define SMMU_TCR_T1SZ_SHIFT                 16
-#define SMMU_TCR_T0SZ_SHIFT                 0
-#define SMMU_TCR_SZ_MASK                    0xf
-
-#define SMMU_TCR2_SEP_SHIFT                 15
-#define SMMU_TCR2_SEP_MASK                  0x7
-
-#define SMMU_TCR2_PASIZE_SHIFT              0
-#define SMMU_TCR2_PASIZE_MASK               0x7
-
-/* Common definitions for PASize and SEP fields */
-#define SMMU_TCR2_ADDR_32                   0
-#define SMMU_TCR2_ADDR_36                   1
-#define SMMU_TCR2_ADDR_40                   2
-#define SMMU_TCR2_ADDR_42                   3
-#define SMMU_TCR2_ADDR_44                   4
-#define SMMU_TCR2_ADDR_48                   5
-
-#define SMMU_TTBRn_HI_ASID_SHIFT            16
-
-#define SMMU_MAIR_ATTR_SHIFT(n)             ((n) << 3)
-#define SMMU_MAIR_ATTR_MASK                 0xff
-#define SMMU_MAIR_ATTR_DEVICE               0x04
-#define SMMU_MAIR_ATTR_NC                   0x44
-#define SMMU_MAIR_ATTR_WBRWA                0xff
-#define SMMU_MAIR_ATTR_IDX_NC               0
-#define SMMU_MAIR_ATTR_IDX_CACHE            1
-#define SMMU_MAIR_ATTR_IDX_DEV              2
-
-#define SMMU_FSR_MULTI                      (1 << 31)
-#define SMMU_FSR_SS                         (1 << 30)
-#define SMMU_FSR_UUT                        (1 << 8)
-#define SMMU_FSR_ASF                        (1 << 7)
-#define SMMU_FSR_TLBLKF                     (1 << 6)
-#define SMMU_FSR_TLBMCF                     (1 << 5)
-#define SMMU_FSR_EF                         (1 << 4)
-#define SMMU_FSR_PF                         (1 << 3)
-#define SMMU_FSR_AFF                        (1 << 2)
-#define SMMU_FSR_TF                         (1 << 1)
-
-#define SMMU_FSR_IGN                        (SMMU_FSR_AFF | SMMU_FSR_ASF |    \
-                                             SMMU_FSR_TLBMCF | SMMU_FSR_TLBLKF)
-#define SMMU_FSR_FAULT                      (SMMU_FSR_MULTI | SMMU_FSR_SS |   \
-                                             SMMU_FSR_UUT | SMMU_FSR_EF |     \
-                                             SMMU_FSR_PF | SMMU_FSR_TF |      \
-                                             SMMU_FSR_IGN)
-
-#define SMMU_FSYNR0_WNR                     (1 << 4)
-
-#define smmu_print(dev, lvl, fmt, ...)                                        \
-    printk(lvl "smmu: %s: " fmt, dt_node_full_name(dev->node), ## __VA_ARGS__)
-
-#define smmu_err(dev, fmt, ...) smmu_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
-
-#define smmu_dbg(dev, fmt, ...)                                             \
-    smmu_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__)
-
-#define smmu_info(dev, fmt, ...)                                            \
-    smmu_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__)
-
-#define smmu_warn(dev, fmt, ...)                                            \
-    smmu_print(dev, XENLOG_WARNING, fmt, ## __VA_ARGS__)
-
-struct arm_smmu_device {
-    const struct dt_device_node *node;
-
-    void __iomem                *base;
-    unsigned long               size;
-    unsigned long               pagesize;
-
-#define SMMU_FEAT_COHERENT_WALK (1 << 0)
-#define SMMU_FEAT_STREAM_MATCH  (1 << 1)
-#define SMMU_FEAT_TRANS_S1      (1 << 2)
-#define SMMU_FEAT_TRANS_S2      (1 << 3)
-#define SMMU_FEAT_TRANS_NESTED  (1 << 4)
-    u32                         features;
-    u32                         options;
-    int                         version;
-
-    u32                         num_context_banks;
-    u32                         num_s2_context_banks;
-    DECLARE_BITMAP(context_map, SMMU_MAX_CBS);
-    atomic_t                    irptndx;
-
-    u32                         num_mapping_groups;
-    DECLARE_BITMAP(smr_map, SMMU_MAX_SMRS);
-
-    unsigned long               input_size;
-    unsigned long               s1_output_size;
-    unsigned long               s2_output_size;
-
-    u32                         num_global_irqs;
-    u32                         num_context_irqs;
-    unsigned int                *irqs;
-
-    u32                         smr_mask_mask;
-    u32                         smr_id_mask;
-
-    unsigned long               *sids;
-
-    struct list_head            list;
-    struct rb_root              masters;
-};
-
-struct arm_smmu_smr {
-    u8                          idx;
-    u16                         mask;
-    u16                         id;
-};
-
-#define INVALID_IRPTNDX         0xff
-
-#define SMMU_CB_ASID(cfg)       ((cfg)->cbndx)
-#define SMMU_CB_VMID(cfg)       ((cfg)->cbndx + 1)
-
-struct arm_smmu_domain_cfg {
-    struct arm_smmu_device  *smmu;
-    u8                      cbndx;
-    u8                      irptndx;
-    u32                     cbar;
-    /* Domain associated to this device */
-    struct domain           *domain;
-    /* List of master which use this structure */
-    struct list_head        masters;
-
-    /* Used to link domain context for a same domain */
-    struct list_head        list;
-};
-
-struct arm_smmu_master {
-    const struct dt_device_node *dt_node;
-
-    /*
-     * The following is specific to the master's position in the
-     * SMMU chain.
-     */
-    struct rb_node              node;
-    u32                         num_streamids;
-    u16                         streamids[MAX_MASTER_STREAMIDS];
-    int                         num_s2crs;
-
-    struct arm_smmu_smr         *smrs;
-    struct arm_smmu_domain_cfg  *cfg;
-
-    /* Used to link masters in a same domain context */
-    struct list_head            list;
-};
-
-static LIST_HEAD(arm_smmu_devices);
-
-struct arm_smmu_domain {
-    spinlock_t lock;
-    struct list_head contexts;
-};
-
-struct arm_smmu_option_prop {
-    u32         opt;
-    const char  *prop;
-};
-
-static const struct arm_smmu_option_prop arm_smmu_options [] __initconst =
-{
-    { SMMU_OPT_SECURE_CONFIG_ACCESS, "calxeda,smmu-secure-config-access" },
-    { 0, NULL},
-};
-
-static void __init check_driver_options(struct arm_smmu_device *smmu)
-{
-    int i = 0;
-
-    do {
-        if ( dt_property_read_bool(smmu->node, arm_smmu_options[i].prop) )
-        {
-            smmu->options |= arm_smmu_options[i].opt;
-            smmu_dbg(smmu, "option %s\n", arm_smmu_options[i].prop);
-        }
-    } while ( arm_smmu_options[++i].opt );
-}
-
-static void arm_smmu_context_fault(int irq, void *data,
-                                   struct cpu_user_regs *regs)
-{
-    u32 fsr, far, fsynr;
-    uint64_t iova;
-    struct arm_smmu_domain_cfg *cfg = data;
-    struct arm_smmu_device *smmu = cfg->smmu;
-    void __iomem *cb_base;
-
-    cb_base = SMMU_CB_BASE(smmu) + SMMU_CB(smmu, cfg->cbndx);
-    fsr = readl_relaxed(cb_base + SMMU_CB_FSR);
-
-    if ( !(fsr & SMMU_FSR_FAULT) )
-        return;
-
-    if ( fsr & SMMU_FSR_IGN )
-        smmu_err(smmu, "Unexpected context fault (fsr 0x%u)\n", fsr);
-
-    fsynr = readl_relaxed(cb_base + SMMU_CB_FSYNR0);
-    far = readl_relaxed(cb_base + SMMU_CB_FAR_LO);
-    iova = far;
-    far = readl_relaxed(cb_base + SMMU_CB_FAR_HI);
-    iova |= ((uint64_t)far << 32);
-
-    smmu_err(smmu, "Unhandled context fault for domain %u\n",
-             cfg->domain->domain_id);
-    smmu_err(smmu, "\tFSR 0x%x, IOVA 0x%"PRIx64", FSYNR 0x%x,  CB %d\n",
-             fsr, iova, fsynr, cfg->cbndx);
-
-    /* Clear the faulting FSR */
-    writel(fsr, cb_base + SMMU_CB_FSR);
-
-    /* Terminate any stalled transactions */
-    if ( fsr & SMMU_FSR_SS )
-        writel_relaxed(SMMU_RESUME_TERMINATE, cb_base + SMMU_CB_RESUME);
-}
-
-static void arm_smmu_global_fault(int irq, void *data,
-                                  struct cpu_user_regs *regs)
-{
-    u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
-    struct arm_smmu_device *smmu = data;
-    void __iomem *gr0_base = SMMU_GR0_NS(smmu);
-
-    gfsr = readl_relaxed(gr0_base + SMMU_GR0_sGFSR);
-    gfsynr0 = readl_relaxed(gr0_base + SMMU_GR0_sGFSYNR0);
-    gfsynr1 = readl_relaxed(gr0_base + SMMU_GR0_sGFSYNR1);
-    gfsynr2 = readl_relaxed(gr0_base + SMMU_GR0_sGFSYNR2);
-
-    if ( !gfsr )
-        return;
-
-    smmu_err(smmu, "Unexpected global fault, this could be serious\n");
-    smmu_err(smmu,
-             "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
-             gfsr, gfsynr0, gfsynr1, gfsynr2);
-    writel(gfsr, gr0_base + SMMU_GR0_sGFSR);
-}
-
-static struct arm_smmu_master *
-find_smmu_master(struct arm_smmu_device *smmu,
-                 const struct dt_device_node *dev_node)
-{
-    struct rb_node *node = smmu->masters.rb_node;
-
-    while ( node )
-    {
-        struct arm_smmu_master *master;
-
-        master = container_of(node, struct arm_smmu_master, node);
-
-        if ( dev_node < master->dt_node )
-            node = node->rb_left;
-        else if ( dev_node > master->dt_node )
-            node = node->rb_right;
-        else
-            return master;
-    }
-
-    return NULL;
-}
-
-static __init int insert_smmu_master(struct arm_smmu_device *smmu,
-                                     struct arm_smmu_master *master)
-{
-    struct rb_node **new, *parent;
-
-    new = &smmu->masters.rb_node;
-    parent = NULL;
-    while ( *new )
-    {
-        struct arm_smmu_master *this;
-
-        this = container_of(*new, struct arm_smmu_master, node);
-
-        parent = *new;
-        if ( master->dt_node < this->dt_node )
-            new = &((*new)->rb_left);
-        else if (master->dt_node > this->dt_node)
-            new = &((*new)->rb_right);
-        else
-            return -EEXIST;
-    }
-
-    rb_link_node(&master->node, parent, new);
-    rb_insert_color(&master->node, &smmu->masters);
-    return 0;
-}
-
-static __init int register_smmu_master(struct arm_smmu_device *smmu,
-                                       struct dt_phandle_args *masterspec)
-{
-    int i, sid;
-    struct arm_smmu_master *master;
-    int rc = 0;
-
-    smmu_dbg(smmu, "Try to add master %s\n", masterspec->np->name);
-
-    master = find_smmu_master(smmu, masterspec->np);
-    if ( master )
-    {
-        smmu_err(smmu,
-                 "rejecting multiple registrations for master device %s\n",
-                 masterspec->np->name);
-        return -EBUSY;
-    }
-
-    if ( masterspec->args_count > MAX_MASTER_STREAMIDS )
-    {
-        smmu_err(smmu,
-            "reached maximum number (%d) of stream IDs for master device %s\n",
-            MAX_MASTER_STREAMIDS, masterspec->np->name);
-        return -ENOSPC;
-    }
-
-    master = xzalloc(struct arm_smmu_master);
-    if ( !master )
-        return -ENOMEM;
-
-    INIT_LIST_HEAD(&master->list);
-    master->dt_node = masterspec->np;
-    master->num_streamids = masterspec->args_count;
-
-    dt_device_set_protected(masterspec->np);
-
-    for ( i = 0; i < master->num_streamids; ++i )
-    {
-        sid = masterspec->args[i];
-        if ( test_and_set_bit(sid, smmu->sids) )
-        {
-            smmu_err(smmu, "duplicate stream ID (%d)\n", sid);
-            xfree(master);
-            return -EEXIST;
-        }
-        master->streamids[i] = masterspec->args[i];
-    }
-
-    rc = insert_smmu_master(smmu, master);
-    /* Insertion should never fail */
-    ASSERT(rc == 0);
-
-    return 0;
-}
-
-static int __arm_smmu_alloc_bitmap(unsigned long *map, int start, int end)
-{
-    int idx;
-
-    do
-    {
-        idx = find_next_zero_bit(map, end, start);
-        if ( idx == end )
-            return -ENOSPC;
-    } while ( test_and_set_bit(idx, map) );
-
-    return idx;
-}
-
-static void __arm_smmu_free_bitmap(unsigned long *map, int idx)
-{
-    clear_bit(idx, map);
-}
-
-static void arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
-{
-    int count = 0;
-    void __iomem *gr0_base = SMMU_GR0(smmu);
-
-    writel_relaxed(0, gr0_base + SMMU_GR0_sTLBGSYNC);
-    while ( readl_relaxed(gr0_base + SMMU_GR0_sTLBGSTATUS) &
-            SMMU_sTLBGSTATUS_GSACTIVE )
-    {
-        cpu_relax();
-        if ( ++count == SMMU_TLB_LOOP_TIMEOUT )
-        {
-            smmu_err(smmu, "TLB sync timed out -- SMMU may be deadlocked\n");
-            return;
-        }
-        udelay(1);
-    }
-}
-
-static void arm_smmu_tlb_inv_context(struct arm_smmu_domain_cfg *cfg)
-{
-    struct arm_smmu_device *smmu = cfg->smmu;
-    void __iomem *base = SMMU_GR0(smmu);
-
-    writel_relaxed(SMMU_CB_VMID(cfg),
-                   base + SMMU_GR0_TLBIVMID);
-
-    arm_smmu_tlb_sync(smmu);
-}
-
-static void arm_smmu_iotlb_flush_all(struct domain *d)
-{
-    struct arm_smmu_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
-    struct arm_smmu_domain_cfg *cfg;
-
-    spin_lock(&smmu_domain->lock);
-    list_for_each_entry(cfg, &smmu_domain->contexts, list)
-        arm_smmu_tlb_inv_context(cfg);
-    spin_unlock(&smmu_domain->lock);
-}
-
-static void arm_smmu_iotlb_flush(struct domain *d, unsigned long gfn,
-                                 unsigned int page_count)
-{
-    /* ARM SMMU v1 doesn't have flush by VMA and VMID */
-    arm_smmu_iotlb_flush_all(d);
-}
-
-static int determine_smr_mask(struct arm_smmu_device *smmu,
-                              struct arm_smmu_master *master,
-                              struct arm_smmu_smr *smr, int start, int order)
-{
-    u16 i, zero_bits_mask, one_bits_mask, const_mask;
-    int nr;
-
-    nr = 1 << order;
-
-    if ( nr == 1 )
-    {
-        /* no mask, use streamid to match and be done with it */
-        smr->mask = 0;
-        smr->id = master->streamids[start];
-        return 0;
-    }
-
-    zero_bits_mask = 0;
-    one_bits_mask = 0xffff;
-    for ( i = start; i < start + nr; i++)
-    {
-        zero_bits_mask |= master->streamids[i];   /* const 0 bits */
-        one_bits_mask &= master->streamids[i]; /* const 1 bits */
-    }
-    zero_bits_mask = ~zero_bits_mask;
-
-    /* bits having constant values (either 0 or 1) */
-    const_mask = zero_bits_mask | one_bits_mask;
-
-    i = hweight16(~const_mask);
-    if ( (1 << i) == nr )
-    {
-        smr->mask = ~const_mask;
-        smr->id = one_bits_mask;
-    }
-    else
-        /* no usable mask for this set of streamids */
-        return 1;
-
-    if ( ((smr->mask & smmu->smr_mask_mask) != smr->mask) ||
-         ((smr->id & smmu->smr_id_mask) != smr->id) )
-        /* insufficient number of mask/id bits */
-        return 1;
-
-    return 0;
-}
-
-static int determine_smr_mapping(struct arm_smmu_device *smmu,
-                                 struct arm_smmu_master *master,
-                                 struct arm_smmu_smr *smrs, int max_smrs)
-{
-    int nr_sid, nr, i, bit, start;
-
-    /*
-     * This function is called only once -- when a master is added
-     * to a domain. If master->num_s2crs != 0 then this master
-     * was already added to a domain.
-     */
-    BUG_ON(master->num_s2crs);
-
-    start = nr = 0;
-    nr_sid = master->num_streamids;
-    do
-    {
-        /*
-         * largest power-of-2 number of streamids for which to
-         * determine a usable mask/id pair for stream matching
-         */
-        bit = fls(nr_sid);
-        if (!bit)
-            return 0;
-
-        /*
-         * iterate over power-of-2 numbers to determine
-         * largest possible mask/id pair for stream matching
-         * of next 2**i streamids
-         */
-        for ( i = bit - 1; i >= 0; i-- )
-        {
-            if( !determine_smr_mask(smmu, master,
-                                    &smrs[master->num_s2crs],
-                                    start, i))
-                break;
-        }
-
-        if ( i < 0 )
-            goto out;
-
-        nr = 1 << i;
-        nr_sid -= nr;
-        start += nr;
-        master->num_s2crs++;
-    } while ( master->num_s2crs <= max_smrs );
-
-out:
-    if ( nr_sid )
-    {
-        /* not enough mapping groups available */
-        master->num_s2crs = 0;
-        return -ENOSPC;
-    }
-
-    return 0;
-}
-
-static int arm_smmu_master_configure_smrs(struct arm_smmu_device *smmu,
-                                          struct arm_smmu_master *master)
-{
-    int i, max_smrs, ret;
-    struct arm_smmu_smr *smrs;
-    void __iomem *gr0_base = SMMU_GR0(smmu);
-
-    if ( !(smmu->features & SMMU_FEAT_STREAM_MATCH) )
-        return 0;
-
-    if ( master->smrs )
-        return -EEXIST;
-
-    max_smrs = min(smmu->num_mapping_groups, master->num_streamids);
-    smrs = xmalloc_array(struct arm_smmu_smr, max_smrs);
-    if ( !smrs )
-    {
-        smmu_err(smmu, "failed to allocated %d SMRs for master %s\n",
-                 max_smrs, dt_node_name(master->dt_node));
-        return -ENOMEM;
-    }
-
-    ret = determine_smr_mapping(smmu, master, smrs, max_smrs);
-    if ( ret )
-        goto err_free_smrs;
-
-    /* Allocate the SMRs on the root SMMU */
-    for ( i = 0; i < master->num_s2crs; ++i )
-    {
-        int idx = __arm_smmu_alloc_bitmap(smmu->smr_map, 0,
-                                          smmu->num_mapping_groups);
-        if ( idx < 0 )
-        {
-            smmu_err(smmu, "failed to allocate free SMR\n");
-            goto err_free_bitmap;
-        }
-        smrs[i].idx = idx;
-    }
-
-    /* It worked! Now, poke the actual hardware */
-    for ( i = 0; i < master->num_s2crs; ++i )
-    {
-        u32 reg = SMMU_SMR_VALID | smrs[i].id << SMMU_SMR_ID_SHIFT |
-            smrs[i].mask << SMMU_SMR_MASK_SHIFT;
-        smmu_dbg(smmu, "SMR%d: 0x%x\n", smrs[i].idx, reg);
-        writel_relaxed(reg, gr0_base + SMMU_GR0_SMR(smrs[i].idx));
-    }
-
-    master->smrs = smrs;
-    return 0;
-
-err_free_bitmap:
-    while (--i >= 0)
-        __arm_smmu_free_bitmap(smmu->smr_map, smrs[i].idx);
-    master->num_s2crs = 0;
-err_free_smrs:
-    xfree(smrs);
-    return -ENOSPC;
-}
-
-/* Forward declaration */
-static void arm_smmu_destroy_domain_context(struct arm_smmu_domain_cfg *cfg);
-
-static int arm_smmu_domain_add_master(struct domain *d,
-                                      struct arm_smmu_domain_cfg *cfg,
-                                      struct arm_smmu_master *master)
-{
-    int i, ret;
-    struct arm_smmu_device *smmu = cfg->smmu;
-    void __iomem *gr0_base = SMMU_GR0(smmu);
-    struct arm_smmu_smr *smrs = master->smrs;
-
-    if ( master->cfg )
-        return -EBUSY;
-
-    ret = arm_smmu_master_configure_smrs(smmu, master);
-    if ( ret )
-        return ret;
-
-    /* Now we're at the root, time to point at our context bank */
-    if ( !master->num_s2crs )
-        master->num_s2crs = master->num_streamids;
-
-    for ( i = 0; i < master->num_s2crs; ++i )
-    {
-        u32 idx, s2cr;
-
-        idx = smrs ? smrs[i].idx : master->streamids[i];
-        s2cr = (SMMU_S2CR_TYPE_TRANS << SMMU_S2CR_TYPE_SHIFT) |
-            (cfg->cbndx << SMMU_S2CR_CBNDX_SHIFT);
-        smmu_dbg(smmu, "S2CR%d: 0x%x\n", idx, s2cr);
-        writel_relaxed(s2cr, gr0_base + SMMU_GR0_S2CR(idx));
-    }
-
-    master->cfg = cfg;
-    list_add(&master->list, &cfg->masters);
-
-    return 0;
-}
-
-static void arm_smmu_domain_remove_master(struct arm_smmu_master *master)
-{
-    int i;
-    struct arm_smmu_domain_cfg *cfg = master->cfg;
-    struct arm_smmu_device *smmu = cfg->smmu;
-    void __iomem *gr0_base = SMMU_GR0(smmu);
-    struct arm_smmu_smr *smrs = master->smrs;
-
-    /*
-     * We *must* clear the S2CR first, because freeing the SMR means
-     * that it can be reallocated immediately
-     */
-    for ( i = 0; i < master->num_streamids; ++i )
-    {
-        u16 sid = master->streamids[i];
-        writel_relaxed(SMMU_S2CR_TYPE_FAULT,
-                       gr0_base + SMMU_GR0_S2CR(sid));
-    }
-
-    /* Invalidate the SMRs before freeing back to the allocator */
-    for (i = 0; i < master->num_s2crs; ++i) {
-        u8 idx = smrs[i].idx;
-        writel_relaxed(~SMMU_SMR_VALID, gr0_base + SMMU_GR0_SMR(idx));
-        __arm_smmu_free_bitmap(smmu->smr_map, idx);
-    }
-
-    master->smrs = NULL;
-    master->num_s2crs = 0;
-    xfree(smrs);
-
-    master->cfg = NULL;
-    list_del(&master->list);
-    INIT_LIST_HEAD(&master->list);
-}
-
-static void arm_smmu_init_context_bank(struct arm_smmu_domain_cfg *cfg)
-{
-    u32 reg;
-    struct arm_smmu_device *smmu = cfg->smmu;
-    void __iomem *cb_base, *gr1_base;
-    paddr_t p2maddr;
-
-    ASSERT(cfg->domain != NULL);
-    p2maddr = page_to_maddr(cfg->domain->arch.p2m.root);
-
-    gr1_base = SMMU_GR1(smmu);
-    cb_base = SMMU_CB_BASE(smmu) + SMMU_CB(smmu, cfg->cbndx);
-
-    /* CBAR */
-    reg = cfg->cbar;
-    if ( smmu->version == 1 )
-        reg |= cfg->irptndx << SMMU_CBAR_IRPTNDX_SHIFT;
-
-    reg |= SMMU_CB_VMID(cfg) << SMMU_CBAR_VMID_SHIFT;
-    writel_relaxed(reg, gr1_base + SMMU_GR1_CBAR(cfg->cbndx));
-
-    if ( smmu->version > 1 )
-    {
-        /* CBA2R */
-#ifdef CONFIG_ARM_64
-        reg = SMMU_CBA2R_RW64_64BIT;
-#else
-        reg = SMMU_CBA2R_RW64_32BIT;
-#endif
-        writel_relaxed(reg, gr1_base + SMMU_GR1_CBA2R(cfg->cbndx));
-    }
-
-    /* TTBR0 */
-    reg = (p2maddr & ((1ULL << 32) - 1));
-    writel_relaxed(reg, cb_base + SMMU_CB_TTBR0_LO);
-    reg = (p2maddr >> 32);
-    writel_relaxed(reg, cb_base + SMMU_CB_TTBR0_HI);
-
-    /*
-     * TCR
-     * We use long descriptor, with inner-shareable WBWA tables in TTBR0.
-     */
-    if ( smmu->version > 1 )
-    {
-        /* 4K Page Table */
-        if ( PAGE_SIZE == PAGE_SIZE_4K )
-            reg = SMMU_TCR_TG0_4K;
-        else
-            reg = SMMU_TCR_TG0_64K;
-
-        switch ( smmu->s2_output_size ) {
-        case 32:
-            reg |= (SMMU_TCR2_ADDR_32 << SMMU_TCR_PASIZE_SHIFT);
-            break;
-        case 36:
-            reg |= (SMMU_TCR2_ADDR_36 << SMMU_TCR_PASIZE_SHIFT);
-            break;
-        case 40:
-            reg |= (SMMU_TCR2_ADDR_40 << SMMU_TCR_PASIZE_SHIFT);
-            break;
-        case 42:
-            reg |= (SMMU_TCR2_ADDR_42 << SMMU_TCR_PASIZE_SHIFT);
-            break;
-        case 44:
-            reg |= (SMMU_TCR2_ADDR_44 << SMMU_TCR_PASIZE_SHIFT);
-            break;
-        case 48:
-            reg |= (SMMU_TCR2_ADDR_48 << SMMU_TCR_PASIZE_SHIFT);
-            break;
-        }
-    }
-    else
-        reg = 0;
-
-    /* The attribute to walk the page table should be the same as VTCR_EL2 */
-    reg |= SMMU_TCR_EAE |
-        (SMMU_TCR_SH_IS << SMMU_TCR_SH0_SHIFT) |
-        (SMMU_TCR_RGN_WBWA << SMMU_TCR_ORGN0_SHIFT) |
-        (SMMU_TCR_RGN_WBWA << SMMU_TCR_IRGN0_SHIFT) |
-        (SMMU_TCR_SL0_LVL_1 << SMMU_TCR_SL0_SHIFT) |
-        /* T0SZ=(1)100 = -8 ( 32 -(-8) = 40 bit physical addresses ) */
-        (0x18 << SMMU_TCR_T0SZ_SHIFT);
-    writel_relaxed(reg, cb_base + SMMU_CB_TCR);
-
-    /* SCTLR */
-    reg = SMMU_SCTLR_CFCFG |
-        SMMU_SCTLR_CFIE |
-        SMMU_SCTLR_CFRE |
-        SMMU_SCTLR_M |
-        SMMU_SCTLR_EAE_SBOP;
-
-    writel_relaxed(reg, cb_base + SMMU_CB_SCTLR);
-}
-
-static struct arm_smmu_domain_cfg *
-arm_smmu_alloc_domain_context(struct domain *d,
-                              struct arm_smmu_device *smmu)
-{
-    unsigned int irq;
-    int ret, start;
-    struct arm_smmu_domain_cfg *cfg;
-    struct arm_smmu_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
-
-    ASSERT(spin_is_locked(&smmu_domain->lock));
-
-    cfg = xzalloc(struct arm_smmu_domain_cfg);
-    if ( !cfg )
-        return NULL;
-
-    /* Master already initialized to another domain ... */
-    if ( cfg->domain != NULL )
-        goto out_free_mem;
-
-    cfg->cbar = SMMU_CBAR_TYPE_S2_TRANS;
-    start = 0;
-
-    ret = __arm_smmu_alloc_bitmap(smmu->context_map, start,
-                                  smmu->num_context_banks);
-    if ( ret < 0 )
-        goto out_free_mem;
-
-    cfg->cbndx = ret;
-    if ( smmu->version == 1 )
-    {
-        cfg->irptndx = atomic_inc_return(&smmu->irptndx);
-        cfg->irptndx %= smmu->num_context_irqs;
-    }
-    else
-        cfg->irptndx = cfg->cbndx;
-
-    irq = smmu->irqs[smmu->num_global_irqs + cfg->irptndx];
-    ret = request_irq(irq, IRQF_SHARED, arm_smmu_context_fault,
-                      "arm-smmu-context-fault", cfg);
-    if ( ret )
-    {
-        smmu_err(smmu, "failed to request context IRQ %d (%u)\n",
-                 cfg->irptndx, irq);
-        cfg->irptndx = INVALID_IRPTNDX;
-        goto out_free_context;
-    }
-
-    cfg->domain = d;
-    cfg->smmu = smmu;
-    if ( smmu->features & SMMU_FEAT_COHERENT_WALK )
-        iommu_set_feature(d, IOMMU_FEAT_COHERENT_WALK);
-
-    arm_smmu_init_context_bank(cfg);
-    list_add(&cfg->list, &smmu_domain->contexts);
-    INIT_LIST_HEAD(&cfg->masters);
-
-    return cfg;
-
-out_free_context:
-    __arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
-out_free_mem:
-    xfree(cfg);
-
-    return NULL;
-}
-
-static void arm_smmu_destroy_domain_context(struct arm_smmu_domain_cfg *cfg)
-{
-    struct domain *d = cfg->domain;
-    struct arm_smmu_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
-    struct arm_smmu_device *smmu = cfg->smmu;
-    void __iomem *cb_base;
-    unsigned int irq;
-
-    ASSERT(spin_is_locked(&smmu_domain->lock));
-    BUG_ON(!list_empty(&cfg->masters));
-
-    /* Disable the context bank and nuke the TLB before freeing it */
-    cb_base = SMMU_CB_BASE(smmu) + SMMU_CB(smmu, cfg->cbndx);
-    writel_relaxed(0, cb_base + SMMU_CB_SCTLR);
-    arm_smmu_tlb_inv_context(cfg);
-
-    if ( cfg->irptndx != INVALID_IRPTNDX )
-    {
-        irq = smmu->irqs[smmu->num_global_irqs + cfg->irptndx];
-        release_irq(irq, cfg);
-    }
-
-    __arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
-    list_del(&cfg->list);
-    xfree(cfg);
-}
-
-static struct arm_smmu_device *
-arm_smmu_find_smmu_by_dev(const struct dt_device_node *dev)
-{
-    struct arm_smmu_device *smmu;
-    struct arm_smmu_master *master = NULL;
-
-    list_for_each_entry( smmu, &arm_smmu_devices, list )
-    {
-        master = find_smmu_master(smmu, dev);
-        if ( master )
-            break;
-    }
-
-    if ( !master )
-        return NULL;
-
-    return smmu;
-}
-
-static int arm_smmu_attach_dev(struct domain *d,
-                               const struct dt_device_node *dev)
-{
-    struct arm_smmu_device *smmu = arm_smmu_find_smmu_by_dev(dev);
-    struct arm_smmu_master *master;
-    struct arm_smmu_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
-    struct arm_smmu_domain_cfg *cfg = NULL;
-    struct arm_smmu_domain_cfg *curr;
-    int ret;
-
-    printk(XENLOG_DEBUG "arm-smmu: attach %s to domain %d\n",
-           dt_node_full_name(dev), d->domain_id);
-
-    if ( !smmu )
-    {
-        printk(XENLOG_ERR "%s: cannot attach to SMMU, is it on the same bus?\n",
-               dt_node_full_name(dev));
-        return -ENODEV;
-    }
-
-    master = find_smmu_master(smmu, dev);
-    BUG_ON(master == NULL);
-
-    /* Check if the device is already assigned to someone */
-    if ( master->cfg )
-        return -EBUSY;
-
-    spin_lock(&smmu_domain->lock);
-    list_for_each_entry( curr, &smmu_domain->contexts, list )
-    {
-        if ( curr->smmu == smmu )
-        {
-            cfg = curr;
-            break;
-        }
-    }
-
-    if ( !cfg )
-    {
-        cfg = arm_smmu_alloc_domain_context(d, smmu);
-        if ( !cfg )
-        {
-            smmu_err(smmu, "unable to allocate context for domain %u\n",
-                     d->domain_id);
-            spin_unlock(&smmu_domain->lock);
-            return -ENOMEM;
-        }
-    }
-    spin_unlock(&smmu_domain->lock);
-
-    ret = arm_smmu_domain_add_master(d, cfg, master);
-    if ( ret )
-    {
-        spin_lock(&smmu_domain->lock);
-        if ( list_empty(&cfg->masters) )
-            arm_smmu_destroy_domain_context(cfg);
-        spin_unlock(&smmu_domain->lock);
-    }
-
-    return ret;
-}
-
-static int arm_smmu_detach_dev(struct domain *d,
-                               const struct dt_device_node *dev)
-{
-    struct arm_smmu_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
-    struct arm_smmu_master *master;
-    struct arm_smmu_device *smmu = arm_smmu_find_smmu_by_dev(dev);
-    struct arm_smmu_domain_cfg *cfg;
-
-    printk(XENLOG_DEBUG "arm-smmu: detach %s to domain %d\n",
-           dt_node_full_name(dev), d->domain_id);
-
-    if ( !smmu )
-    {
-        printk(XENLOG_ERR "%s: cannot find the SMMU, is it on the same bus?\n",
-               dt_node_full_name(dev));
-        return -ENODEV;
-    }
-
-    master = find_smmu_master(smmu, dev);
-    BUG_ON(master == NULL);
-
-    cfg = master->cfg;
-
-    /* Sanity check to avoid removing a device that doesn't belong to
-     * the domain
-     */
-    if ( !cfg || cfg->domain != d )
-    {
-        printk(XENLOG_ERR "%s: was not attach to domain %d\n",
-               dt_node_full_name(dev), d->domain_id);
-        return -ESRCH;
-    }
-
-    arm_smmu_domain_remove_master(master);
-
-    spin_lock(&smmu_domain->lock);
-    if ( list_empty(&cfg->masters) )
-        arm_smmu_destroy_domain_context(cfg);
-    spin_unlock(&smmu_domain->lock);
-
-    return 0;
-}
-
-static int arm_smmu_reassign_dt_dev(struct domain *s, struct domain *t,
-                                    const struct dt_device_node *dev)
-{
-    int ret = 0;
-
-    /* Don't allow remapping on other domain than hwdom */
-    if ( t != hardware_domain )
-        return -EPERM;
-
-    if ( t == s )
-        return 0;
-
-    ret = arm_smmu_detach_dev(s, dev);
-    if ( ret )
-        return ret;
-
-    ret = arm_smmu_attach_dev(t, dev);
-
-    return ret;
-}
-
-static __init int arm_smmu_id_size_to_bits(int size)
-{
-    switch ( size )
-    {
-    case 0:
-        return 32;
-    case 1:
-        return 36;
-    case 2:
-        return 40;
-    case 3:
-        return 42;
-    case 4:
-        return 44;
-    case 5:
-    default:
-        return 48;
-    }
-}
-
-static __init int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
-{
-    unsigned long size;
-    void __iomem *gr0_base = SMMU_GR0(smmu);
-    u32 id;
-
-    smmu_info(smmu, "probing hardware configuration...\n");
-
-    /*
-     * Primecell ID
-     */
-    id = readl_relaxed(gr0_base + SMMU_GR0_PIDR2);
-    smmu->version = ((id >> SMMU_PIDR2_ARCH_SHIFT) & SMMU_PIDR2_ARCH_MASK) + 1;
-    smmu_info(smmu, "SMMUv%d with:\n", smmu->version);
-
-    /* ID0 */
-    id = readl_relaxed(gr0_base + SMMU_GR0_ID0);
-#ifndef CONFIG_ARM_64
-    if ( ((id >> SMMU_ID0_PTFS_SHIFT) & SMMU_ID0_PTFS_MASK) ==
-            SMMU_ID0_PTFS_V8_ONLY )
-    {
-        smmu_err(smmu, "\tno v7 descriptor support!\n");
-        return -ENODEV;
-    }
-#endif
-    if ( id & SMMU_ID0_S1TS )
-    {
-        smmu->features |= SMMU_FEAT_TRANS_S1;
-        smmu_info(smmu, "\tstage 1 translation\n");
-    }
-
-    if ( id & SMMU_ID0_S2TS )
-    {
-        smmu->features |= SMMU_FEAT_TRANS_S2;
-        smmu_info(smmu, "\tstage 2 translation\n");
-    }
-
-    if ( id & SMMU_ID0_NTS )
-    {
-        smmu->features |= SMMU_FEAT_TRANS_NESTED;
-        smmu_info(smmu, "\tnested translation\n");
-    }
-
-    if ( !(smmu->features &
-           (SMMU_FEAT_TRANS_S1 | SMMU_FEAT_TRANS_S2 |
-            SMMU_FEAT_TRANS_NESTED)) )
-    {
-        smmu_err(smmu, "\tno translation support!\n");
-        return -ENODEV;
-    }
-
-    /* We need at least support for Stage 2 */
-    if ( !(smmu->features & SMMU_FEAT_TRANS_S2) )
-    {
-        smmu_err(smmu, "\tno stage 2 translation!\n");
-        return -ENODEV;
-    }
-
-    if ( id & SMMU_ID0_CTTW )
-    {
-        smmu->features |= SMMU_FEAT_COHERENT_WALK;
-        smmu_info(smmu, "\tcoherent table walk\n");
-    }
-
-    if ( id & SMMU_ID0_SMS )
-    {
-        u32 smr, sid, mask;
-
-        smmu->features |= SMMU_FEAT_STREAM_MATCH;
-        smmu->num_mapping_groups = (id >> SMMU_ID0_NUMSMRG_SHIFT) &
-            SMMU_ID0_NUMSMRG_MASK;
-        if ( smmu->num_mapping_groups == 0 )
-        {
-            smmu_err(smmu,
-                     "stream-matching supported, but no SMRs present!\n");
-            return -ENODEV;
-        }
-
-        smr = SMMU_SMR_MASK_MASK << SMMU_SMR_MASK_SHIFT;
-        smr |= (SMMU_SMR_ID_MASK << SMMU_SMR_ID_SHIFT);
-        writel_relaxed(smr, gr0_base + SMMU_GR0_SMR(0));
-        smr = readl_relaxed(gr0_base + SMMU_GR0_SMR(0));
-
-        mask = (smr >> SMMU_SMR_MASK_SHIFT) & SMMU_SMR_MASK_MASK;
-        sid = (smr >> SMMU_SMR_ID_SHIFT) & SMMU_SMR_ID_MASK;
-        if ( (mask & sid) != sid )
-        {
-            smmu_err(smmu,
-                     "SMR mask bits (0x%x) insufficient for ID field (0x%x)\n",
-                     mask, sid);
-            return -ENODEV;
-        }
-        smmu->smr_mask_mask = mask;
-        smmu->smr_id_mask = sid;
-
-        smmu_info(smmu,
-                  "\tstream matching with %u register groups, mask 0x%x\n",
-                  smmu->num_mapping_groups, mask);
-    }
-
-    /* ID1 */
-    id = readl_relaxed(gr0_base + SMMU_GR0_ID1);
-    smmu->pagesize = (id & SMMU_ID1_PAGESIZE) ? PAGE_SIZE_64K : PAGE_SIZE_4K;
-
-    /* Check for size mismatch of SMMU address space from mapped region */
-    size = 1 << (((id >> SMMU_ID1_NUMPAGENDXB_SHIFT) &
-                  SMMU_ID1_NUMPAGENDXB_MASK) + 1);
-    size *= (smmu->pagesize << 1);
-    if ( smmu->size != size )
-        smmu_warn(smmu, "SMMU address space size (0x%lx) differs "
-                  "from mapped region size (0x%lx)!\n", size, smmu->size);
-
-    smmu->num_s2_context_banks = (id >> SMMU_ID1_NUMS2CB_SHIFT) &
-        SMMU_ID1_NUMS2CB_MASK;
-    smmu->num_context_banks = (id >> SMMU_ID1_NUMCB_SHIFT) &
-        SMMU_ID1_NUMCB_MASK;
-    if ( smmu->num_s2_context_banks > smmu->num_context_banks )
-    {
-        smmu_err(smmu, "impossible number of S2 context banks!\n");
-        return -ENODEV;
-    }
-    smmu_info(smmu, "\t%u context banks (%u stage-2 only)\n",
-              smmu->num_context_banks, smmu->num_s2_context_banks);
-
-    /* ID2 */
-    id = readl_relaxed(gr0_base + SMMU_GR0_ID2);
-    size = arm_smmu_id_size_to_bits((id >> SMMU_ID2_IAS_SHIFT) &
-                                    SMMU_ID2_IAS_MASK);
-
-    /*
-     * Stage-1 output limited by stage-2 input size due to VTCR_EL2
-     * setup (see setup_virt_paging)
-     */
-    /* Current maximum output size of 40 bits */
-    smmu->s1_output_size = min(40UL, size);
-
-    /* The stage-2 output mask is also applied for bypass */
-    size = arm_smmu_id_size_to_bits((id >> SMMU_ID2_OAS_SHIFT) &
-                                    SMMU_ID2_OAS_MASK);
-    smmu->s2_output_size = min((unsigned long)PADDR_BITS, size);
-
-    if ( smmu->version == 1 )
-        smmu->input_size = 32;
-    else
-    {
-#ifdef CONFIG_ARM_64
-        size = (id >> SMMU_ID2_UBS_SHIFT) & SMMU_ID2_UBS_MASK;
-        size = min(39, arm_smmu_id_size_to_bits(size));
-#else
-        size = 32;
-#endif
-        smmu->input_size = size;
-
-        if ( (PAGE_SIZE == PAGE_SIZE_4K && !(id & SMMU_ID2_PTFS_4K) ) ||
-             (PAGE_SIZE == PAGE_SIZE_64K && !(id & SMMU_ID2_PTFS_64K)) ||
-             (PAGE_SIZE != PAGE_SIZE_4K && PAGE_SIZE != PAGE_SIZE_64K) )
-        {
-            smmu_err(smmu, "CPU page size 0x%lx unsupported\n",
-                     PAGE_SIZE);
-            return -ENODEV;
-        }
-    }
-
-    smmu_info(smmu, "\t%lu-bit VA, %lu-bit IPA, %lu-bit PA\n",
-              smmu->input_size, smmu->s1_output_size, smmu->s2_output_size);
-    return 0;
-}
-
-static __init void arm_smmu_device_reset(struct arm_smmu_device *smmu)
-{
-    void __iomem *gr0_base = SMMU_GR0(smmu);
-    void __iomem *cb_base;
-    int i = 0;
-    u32 reg;
-
-    smmu_dbg(smmu, "device reset\n");
-
-    /* Clear Global FSR */
-    reg = readl_relaxed(SMMU_GR0_NS(smmu) + SMMU_GR0_sGFSR);
-    writel(reg, SMMU_GR0_NS(smmu) + SMMU_GR0_sGFSR);
-
-    /* Mark all SMRn as invalid and all S2CRn as fault */
-    for ( i = 0; i < smmu->num_mapping_groups; ++i )
-    {
-        writel_relaxed(~SMMU_SMR_VALID, gr0_base + SMMU_GR0_SMR(i));
-        writel_relaxed(SMMU_S2CR_TYPE_FAULT, gr0_base + SMMU_GR0_S2CR(i));
-    }
-
-    /* Make sure all context banks are disabled and clear CB_FSR  */
-    for ( i = 0; i < smmu->num_context_banks; ++i )
-    {
-        cb_base = SMMU_CB_BASE(smmu) + SMMU_CB(smmu, i);
-        writel_relaxed(0, cb_base + SMMU_CB_SCTLR);
-        writel_relaxed(SMMU_FSR_FAULT, cb_base + SMMU_CB_FSR);
-    }
-
-    /* Invalidate the TLB, just in case */
-    writel_relaxed(0, gr0_base + SMMU_GR0_STLBIALL);
-    writel_relaxed(0, gr0_base + SMMU_GR0_TLBIALLH);
-    writel_relaxed(0, gr0_base + SMMU_GR0_TLBIALLNSNH);
-
-    reg = readl_relaxed(SMMU_GR0_NS(smmu) + SMMU_GR0_sCR0);
-
-    /* Enable fault reporting */
-    reg |= (SMMU_sCR0_GFRE | SMMU_sCR0_GFIE |
-            SMMU_sCR0_GCFGFRE | SMMU_sCR0_GCFGFIE);
-
-    /* Disable TLB broadcasting. */
-    reg |= (SMMU_sCR0_VMIDPNE | SMMU_sCR0_PTM);
-
-    /* Enable client access, generate a fault if no mapping is found */
-    reg &= ~(SMMU_sCR0_CLIENTPD);
-    reg |= SMMU_sCR0_USFCFG;
-
-    /* Disable forced broadcasting */
-    reg &= ~SMMU_sCR0_FB;
-
-    /* Don't upgrade barriers when client devices are not mapped to
-     * a translation context banks (just here for clarity as Xen policy
-     * is to deny invalid transaction). */
-    reg &= ~(SMMU_sCR0_BSU_MASK << SMMU_sCR0_BSU_SHIFT);
-
-    /* Push the button */
-    arm_smmu_tlb_sync(smmu);
-    writel_relaxed(reg, SMMU_GR0_NS(smmu) + SMMU_GR0_sCR0);
-}
-
-static int arm_smmu_iommu_domain_init(struct domain *d)
-{
-    struct arm_smmu_domain *smmu_domain;
-
-    smmu_domain = xzalloc(struct arm_smmu_domain);
-    if ( !smmu_domain )
-        return -ENOMEM;
-
-    spin_lock_init(&smmu_domain->lock);
-    INIT_LIST_HEAD(&smmu_domain->contexts);
-
-    domain_hvm_iommu(d)->arch.priv = smmu_domain;
-
-    return 0;
-}
-
-static void __hwdom_init arm_smmu_iommu_hwdom_init(struct domain *d)
-{
-}
-
-static void arm_smmu_iommu_domain_teardown(struct domain *d)
-{
-    struct arm_smmu_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
-
-    ASSERT(list_empty(&smmu_domain->contexts));
-    xfree(smmu_domain);
-}
-
-static int arm_smmu_map_page(struct domain *d, unsigned long gfn,
-                             unsigned long mfn, unsigned int flags)
-{
-    p2m_type_t t;
-
-    /* Grant mappings can be used for DMA requests. The dev_bus_addr returned by
-     * the hypercall is the MFN (not the IPA). For device protected by
-     * an IOMMU, Xen needs to add a 1:1 mapping in the domain p2m to
-     * allow DMA request to work.
-     * This is only valid when the domain is directed mapped. Hence this
-     * function should only be used by gnttab code with gfn == mfn.
-     */
-    BUG_ON(!is_domain_direct_mapped(d));
-    BUG_ON(mfn != gfn);
-
-    /* We only support readable and writable flags */
-    if ( !(flags & (IOMMUF_readable | IOMMUF_writable)) )
-        return -EINVAL;
-
-    t = (flags & IOMMUF_writable) ? p2m_iommu_map_rw : p2m_iommu_map_ro;
-
-    /* The function guest_physmap_add_entry replaces the current mapping
-     * if there is already one...
-     */
-    return guest_physmap_add_entry(d, gfn, mfn, 0, t);
-}
-
-static int arm_smmu_unmap_page(struct domain *d, unsigned long gfn)
-{
-    /* This function should only be used by gnttab code when the domain
-     * is direct mapped
-     */
-    if ( !is_domain_direct_mapped(d) )
-        return -EINVAL;
-
-    guest_physmap_remove_page(d, gfn, gfn, 0);
-
-    return 0;
-}
-
-static const struct iommu_ops arm_smmu_iommu_ops = {
-    .init = arm_smmu_iommu_domain_init,
-    .hwdom_init = arm_smmu_iommu_hwdom_init,
-    .teardown = arm_smmu_iommu_domain_teardown,
-    .iotlb_flush = arm_smmu_iotlb_flush,
-    .iotlb_flush_all = arm_smmu_iotlb_flush_all,
-    .assign_dt_device = arm_smmu_attach_dev,
-    .reassign_dt_device = arm_smmu_reassign_dt_dev,
-    .map_page = arm_smmu_map_page,
-    .unmap_page = arm_smmu_unmap_page,
-};
-
-static int __init smmu_init(struct dt_device_node *dev,
-                            const void *data)
-{
-    struct arm_smmu_device *smmu;
-    int res;
-    u64 addr, size;
-    unsigned int num_irqs, i;
-    struct dt_phandle_args masterspec;
-    struct rb_node *node;
-
-    /* Even if the device can't be initialized, we don't want to give
-     * the smmu device to dom0.
-     */
-    dt_device_set_used_by(dev, DOMID_XEN);
-
-    smmu = xzalloc(struct arm_smmu_device);
-    if ( !smmu )
-    {
-        printk(XENLOG_ERR "%s: failed to allocate arm_smmu_device\n",
-               dt_node_full_name(dev));
-        return -ENOMEM;
-    }
-
-    smmu->node = dev;
-    check_driver_options(smmu);
-
-    res = dt_device_get_address(smmu->node, 0, &addr, &size);
-    if ( res )
-    {
-        smmu_err(smmu, "unable to retrieve the base address of the SMMU\n");
-        goto out_err;
-    }
-
-    smmu->base = ioremap_nocache(addr, size);
-    if ( !smmu->base )
-    {
-        smmu_err(smmu, "unable to map the SMMU memory\n");
-        goto out_err;
-    }
-
-    smmu->size = size;
-
-    if ( !dt_property_read_u32(smmu->node, "#global-interrupts",
-                               &smmu->num_global_irqs) )
-    {
-        smmu_err(smmu, "missing #global-interrupts\n");
-        goto out_unmap;
-    }
-
-    num_irqs = dt_number_of_irq(smmu->node);
-    if ( num_irqs > smmu->num_global_irqs )
-        smmu->num_context_irqs = num_irqs - smmu->num_global_irqs;
-
-    if ( !smmu->num_context_irqs )
-    {
-        smmu_err(smmu, "found %d interrupts but expected at least %d\n",
-                 num_irqs, smmu->num_global_irqs + 1);
-        goto out_unmap;
-    }
-
-    smmu->irqs = xzalloc_array(unsigned int, num_irqs);
-    if ( !smmu->irqs )
-    {
-        smmu_err(smmu, "failed to allocated %d irqs\n", num_irqs);
-        goto out_unmap;
-    }
-
-    for ( i = 0; i < num_irqs; i++ )
-    {
-        res = platform_get_irq(smmu->node, i);
-        if ( res < 0 )
-        {
-            smmu_err(smmu, "failed to get irq index %d\n", i);
-            goto out_free_irqs;
-        }
-        smmu->irqs[i] = res;
-    }
-
-    smmu->sids = xzalloc_array(unsigned long,
-                               BITS_TO_LONGS(SMMU_MAX_STREAMIDS));
-    if ( !smmu->sids )
-    {
-        smmu_err(smmu, "failed to allocated bitmap for stream ID tracking\n");
-        goto out_free_masters;
-    }
-
-
-    i = 0;
-    smmu->masters = RB_ROOT;
-    while ( !dt_parse_phandle_with_args(smmu->node, "mmu-masters",
-                                        "#stream-id-cells", i, &masterspec) )
-    {
-        res = register_smmu_master(smmu, &masterspec);
-        if ( res )
-        {
-            smmu_err(smmu, "failed to add master %s\n",
-                     masterspec.np->name);
-            goto out_free_masters;
-        }
-        i++;
-    }
-
-    smmu_info(smmu, "registered %d master devices\n", i);
-
-    res = arm_smmu_device_cfg_probe(smmu);
-    if ( res )
-    {
-        smmu_err(smmu, "failed to probe the SMMU\n");
-        goto out_free_masters;
-    }
-
-    if ( smmu->version > 1 &&
-         smmu->num_context_banks != smmu->num_context_irqs )
-    {
-        smmu_err(smmu,
-                 "found only %d context interrupt(s) but %d required\n",
-                 smmu->num_context_irqs, smmu->num_context_banks);
-        goto out_free_masters;
-    }
-
-    smmu_dbg(smmu, "register global IRQs handler\n");
-
-    for ( i = 0; i < smmu->num_global_irqs; ++i )
-    {
-        smmu_dbg(smmu, "\t- global IRQ %u\n", smmu->irqs[i]);
-        res = request_irq(smmu->irqs[i], IRQF_SHARED, arm_smmu_global_fault,
-                          "arm-smmu global fault", smmu);
-        if ( res )
-        {
-            smmu_err(smmu, "failed to request global IRQ %d (%u)\n",
-                     i, smmu->irqs[i]);
-            goto out_release_irqs;
-        }
-    }
-
-    INIT_LIST_HEAD(&smmu->list);
-    list_add(&smmu->list, &arm_smmu_devices);
-
-    arm_smmu_device_reset(smmu);
-
-    iommu_set_ops(&arm_smmu_iommu_ops);
-
-    /* sids field can be freed... */
-    xfree(smmu->sids);
-    smmu->sids = NULL;
-
-    return 0;
-
-out_release_irqs:
-    while (i--)
-        release_irq(smmu->irqs[i], smmu);
-
-out_free_masters:
-    for ( node = rb_first(&smmu->masters); node; node = rb_next(node) )
-    {
-        struct arm_smmu_master *master;
-
-        master = container_of(node, struct arm_smmu_master, node);
-        xfree(master);
-    }
-
-    xfree(smmu->sids);
-
-out_free_irqs:
-    xfree(smmu->irqs);
-
-out_unmap:
-    iounmap(smmu->base);
-
-out_err:
-    xfree(smmu);
-
-    return -ENODEV;
-}
-
-static const char * const smmu_dt_compat[] __initconst =
-{
-    "arm,mmu-400",
-    NULL
-};
-
-DT_DEVICE_START(smmu, "ARM SMMU", DEVICE_IOMMU)
-    .compatible = smmu_dt_compat,
-    .init = smmu_init,
-DT_DEVICE_END
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yQx-0004m8-11; Tue, 16 Dec 2014 20:09: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 1Y0yQv-0004ln-Dk
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:25 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	D6/35-26858-47190945; Tue, 16 Dec 2014 20:09:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418760563!13822115!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20969 invoked from network); 16 Dec 2014 20:09:24 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:24 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so13487902wib.4
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:in-reply-to
	:references;
	bh=2Z7BqoOVEVCC76a/Ky8UOb0m6/eVODAyGoCDfIR31DQ=;
	b=lPnvD2sx3bixmzNlxWBqkee3ZkHZLv6tDcmOAq1IG2rvhx6Xni59nzgLU7m9l2wDCZ
	boJY/EuctNoLhW/ixiPrayCVCsklGzr0xV/3bVv1YecMdRaLFfDssSqzaUDx8Et1+fJp
	gkELxI/ioTFKZx+3Bv9U7oSQWagZIcydQx8ZbzUuKW8S310Qi3yQh4Yb9NEV/WtvIeAO
	F7C2oa+Nr/TJgeU4zZ6FCHui1NBTjY13npDsKYWaCLt1OYQ4CnBLyu5zBLDox785OOXd
	BYGPozZRo5YEKdvLDZypMCK3SzEsV05V/aV/xfKutUH1wMsq41z/L/68HVKb8SC/3e6I
	mjaA==
X-Gm-Message-State: ALoCoQl9CxdT7JRGebsHHGHZqvSDOSX5RsIVRjB+tdW8NBc4RC0KPFPOJyYDQxAZWbb+qh1F7faH
X-Received: by 10.194.80.68 with SMTP id p4mr28995818wjx.108.1418760563774;
	Tue, 16 Dec 2014 12:09:23 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.21
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:22 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:45 +0000
Message-Id: <1418760534-18163-5-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 04/13] xen/dt: Extend dt_device_match to
	possibly store 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>
MIME-Version: 1.0
Content-Type: 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 drivers may want to configure differently the device depending on
the compatible string.

Also modify the return type of dt_match_node to return the matching
structure.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/platform.c       |  2 +-
 xen/common/device_tree.c      | 12 ++++++------
 xen/include/xen/device_tree.h |  6 ++++--
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index cb4cda8..a79a098 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -157,7 +157,7 @@ bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
     if ( platform && platform->blacklist_dev )
         blacklist = platform->blacklist_dev;
 
-    return dt_match_node(blacklist, node);
+    return (dt_match_node(blacklist, node) != NULL);
 }
 
 unsigned int platform_dom0_evtchn_ppi(void)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f72b2e9..34a1b9e 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -290,11 +290,12 @@ struct dt_device_node *dt_find_node_by_alias(const char *alias)
     return NULL;
 }
 
-bool_t dt_match_node(const struct dt_device_match *matches,
-                     const struct dt_device_node *node)
+const struct dt_device_match *
+dt_match_node(const struct dt_device_match *matches,
+              const struct dt_device_node *node)
 {
     if ( !matches )
-        return 0;
+        return NULL;
 
     while ( matches->path || matches->type ||
             matches->compatible || matches->not_available )
@@ -314,12 +315,11 @@ bool_t dt_match_node(const struct dt_device_match *matches,
             match &= !dt_device_is_available(node);
 
         if ( match )
-            return match;
-
+            return matches;
         matches++;
     }
 
-    return 0;
+    return NULL;
 }
 
 const struct dt_device_node *dt_get_parent(const struct dt_device_node *node)
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 08db8bc..6502369 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -28,6 +28,7 @@ struct dt_device_match {
     const char *type;
     const char *compatible;
     const bool_t not_available;
+    const void *data;
 };
 
 #define DT_MATCH_PATH(p)                { .path = p }
@@ -547,8 +548,9 @@ bool_t dt_device_is_available(const struct dt_device_node *device);
  *
  * Returns true if the device node match one of dt_device_match.
  */
-bool_t dt_match_node(const struct dt_device_match *matches,
-                     const struct dt_device_node *node);
+const struct dt_device_match *
+dt_match_node(const struct dt_device_match *matches,
+              const struct dt_device_node *node);
 
 /**
  * dt_find_matching_node - Find a node based on an dt_device_match match table
-- 
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 Dec 16 20:09:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0yQu-0004lh-KY; Tue, 16 Dec 2014 20:09: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 1Y0yQt-0004lD-TT
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:24 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	63/BF-27584-37190945; Tue, 16 Dec 2014 20:09:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418760562!13733923!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6578 invoked from network); 16 Dec 2014 20:09:22 -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;
	16 Dec 2014 20:09:22 -0000
Received: by mail-wg0-f42.google.com with SMTP id k14so2230477wgh.1
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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=/enVbuj4T+LLzDE553Ymsf/7ET5WXHoqDbSYX+IORXQ=;
	b=Ngj3Rn13HfguWVC6+DHKJt56lwZiE5d4qCO13gjKIwDQrTgwh8NsPGMyWlOL0GFSL1
	CvdPtYw6Aq/JaWa9wIGg5YdQ3FYJbX4zQsf33RLGThyfQITD+e9LlE8CnMI5ZgoyKOCf
	AzLZZwqKjJmdPoJ/Trsz+8KsuchKSOUqgIlk29ffrl7mfDX4e25NI3ELjcw+jWSxipjv
	VxZRnmlPUHdpOvVrYYA+RzPUmiTlhndrZSTjQxdNp2BgSkY9d0jiI7RyGJJkehIfxXIA
	lTJUvWm5/gvdCM/zQy9wecCzPzIfw2MaqBEXKTTRwLqqEofl34ol2uOH4H8rATVghzjz
	5q+Q==
X-Gm-Message-State: ALoCoQlg3nwzdknXL6wxTMJhkkiUSIjv6hQTL4i9dZCTvkb3KNYzNdEEhUZPhQs13nlPsAHa9nsG
X-Received: by 10.194.89.3 with SMTP id bk3mr11484775wjb.92.1418760561921;
	Tue, 16 Dec 2014 12:09:21 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.20
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:21 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:44 +0000
Message-Id: <1418760534-18163-4-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This macro can be used in drivers imported from Linux.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Keir Fraser <keir@xen.org>
---
 xen/include/xen/compiler.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index 4b3472d..57eb7a6 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -90,4 +90,18 @@
     __asm__ ("" : "=r"(__ptr) : "0"(ptr));      \
     (typeof(ptr)) (__ptr + (off)); })
 
+/*
+ * Prevent the compiler from merging or refetching accesses.  The compiler
+ * is also forbidden from reordering successive instances of ACCESS_ONCE(),
+ * but only when the compiler is aware of some particular ordering.  One way
+ * to make the compiler aware of ordering is to put the two invocations of
+ * ACCESS_ONCE() in different C statements.
+ *
+ * This macro does absolutely -nothing- to prevent the CPU from reordering,
+ * merging, or refetching absolutely anything at any time.  Its main intended
+ * use is to mediate communication between process-level code and irq/NMI
+ * handlers, all running on the same CPU.
+ */
+#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
+
 #endif /* __LINUX_COMPILER_H */
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yQq-0004kw-Aj; Tue, 16 Dec 2014 20:09: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 1Y0yQp-0004kr-IY
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:19 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	F3/6C-25547-E6190945; Tue, 16 Dec 2014 20:09:18 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418760557!13822091!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19994 invoked from network); 16 Dec 2014 20:09:18 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:18 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so18393568wgg.19
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id;
	bh=475IzZf5L/OQOXHYfYCmv9DhWErdDMQZGFRlYEncnYI=;
	b=camUb/ahfYSVmnOTdszMtDcqJk/wwOQGNiM07K3kIB8P/7KAkxrKtYGe+jYRc+OC8M
	+zGbwQOGSgjQkgB4889G+68eJlTb5rnoBXiVgVHV51zMrc8X32WbRHiVwov4Lz+kDsbI
	GlZGF6DLSgz1d6TV3VMmndVDb9HxGd9U0FxMTnA4t4TWPRnTjYHdwHZrwpcjpQ6RxQTO
	Mo1TePI8slp2uqKP5Ou7rid9+UmhOURycUEQQGgk6DBvSWZnviW7N0FBkMOHmbDGBC/X
	xLk9YQaxvvqnif/lyd6vMmyRXZOEhuh2iN7IGRGsDzU5YegbmSz7yeERLe63Ka1nejDR
	0mTg==
X-Gm-Message-State: ALoCoQkyrgcE7Kgy8+fMAE9y8C90bcdmun6HHrwHfRUpM4AbOL///NFaDSxcD6nOtkvEUcL7kPxD
X-Received: by 10.194.174.72 with SMTP id bq8mr63024577wjc.120.1418760556951; 
	Tue, 16 Dec 2014 12:09:16 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.15
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:15 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:41 +0000
Message-Id: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 00/13] xen/arm: Resync the SMMU driver
	with the Linux 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

Hello,

The SMMU drivers has diverged from Linux. Having our own driver doesn't make
any benefits and make difficult to backport fixes and/or porting features such
as PCI.

With this series, the core of the SMMU drivers (i.e copied from Linux) is mostly
not modified. If it's the case a comment /* Xen: ... */ has been added
to explain why.

To make the change obvious the resync of the SMMU code is mode in several
step:
    1) Revert the current SMMU driver (patch #6)
    2) Import as it is the driver from Linux (patch #10)
    3) Apply 2 fixes useful to correctly use the SATA with the SMMU on
    calxeda. I don't know why Linux didn't yet applied (patch #11-12)
    4) Changes for Xen (patch #13)

I also took the opportunity of the resync to consolidate the iommu ops in
a single set. When I added the IOMMU set to handle device tree passthrough (
ops assign_dt_device and reassign_dt_device), I didn't think about
merging the ops with the PCI one. In fact Linux is using a single set
and have only few lines per driver specific to each set (PCI or device tree).

A branch is available with all the changes:
    git://xenbits.xen.org/people/julieng/xen-unstable.git branch smmu-rework

Sincerely yours,

Andreas Herrmann (2):
  xen/iommu: smmu: Check for duplicate stream IDs when registering
    master devices
  xen/iommu: smmu: Introduce automatic stream-id-masking

Julien Grall (11):
  xen/arm: gic-v2: Change the device name in DT_DEVICE_START
  xen/arm: vgic: Drop unecessary include asm/device.h
  xen: Introduce ACCESS_ONCE macro
  xen/dt: Extend dt_device_match to possibly store data
  xen/arm: device: Rename device_type into device_match
  xen/iommu: arm: Remove temporary the SMMU driver
  xen: Introduce a generic way to describe device
  xen/iommu: Consolidate device assignment ops into a single set
  xen/arm: Describe device supported by a driver with dt_match_node
  xen/iommu: arm: Import the SMMU driver from Linux
  xen/iommu: smmu: Add Xen specific code to be able to use the driver

 xen/arch/arm/device.c                       |   27 +-
 xen/arch/arm/domain_build.c                 |    2 +-
 xen/arch/arm/gic-v2.c                       |   15 +-
 xen/arch/arm/gic-v3.c                       |   10 +-
 xen/arch/arm/gic.c                          |    2 +-
 xen/arch/arm/platform.c                     |    2 +-
 xen/arch/arm/vgic-v2.c                      |    1 -
 xen/arch/arm/vgic-v3.c                      |    1 -
 xen/common/Makefile                         |    1 +
 xen/common/device.c                         |   21 +
 xen/common/device_tree.c                    |   13 +-
 xen/drivers/char/dt-uart.c                  |    4 +-
 xen/drivers/char/exynos4210-uart.c          |   10 +-
 xen/drivers/char/ns16550.c                  |   14 +-
 xen/drivers/char/omap-uart.c                |   10 +-
 xen/drivers/char/pl011.c                    |   10 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c |   14 +-
 xen/drivers/passthrough/arm/iommu.c         |    2 +-
 xen/drivers/passthrough/arm/smmu.c          | 4107 +++++++++++++++++----------
 xen/drivers/passthrough/device_tree.c       |    5 +-
 xen/drivers/passthrough/pci.c               |   22 +-
 xen/drivers/passthrough/vtd/iommu.c         |   19 +-
 xen/include/asm-arm/device.h                |   19 +-
 xen/include/asm-arm/gic.h                   |   15 +-
 xen/include/asm-x86/device.h                |   17 +
 xen/include/xen/compiler.h                  |   14 +
 xen/include/xen/device.h                    |   40 +
 xen/include/xen/device_tree.h               |   19 +-
 xen/include/xen/iommu.h                     |   18 +-
 xen/include/xen/pci.h                       |   12 +
 30 files changed, 2843 insertions(+), 1623 deletions(-)
 create mode 100644 xen/common/device.c
 create mode 100644 xen/include/asm-x86/device.h
 create mode 100644 xen/include/xen/device.h

-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yQu-0004lL-1z; Tue, 16 Dec 2014 20:09:24 +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 1Y0yQs-0004l4-AP
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:22 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	8E/C7-03145-17190945; Tue, 16 Dec 2014 20:09:21 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418760558!15456600!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30757 invoked from network); 16 Dec 2014 20:09:18 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:18 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so13515548wiw.2
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=IsLaah21BAZoisIBljlP+O0/Yw8Xt7G7kFX+BoClczI=;
	b=SlNwxfNbRTFcbH0WLmlZUy28PTi3hY3PKiUIOlZ6O6SVOy1S+UVI/jIafhUwTp4l9m
	1CLGejWB5DkqUaK47H69ERP3ULsUrRXneg3SE9gVw806POWV65OGt8k0Ln2zx8ij7Mp0
	7b7klE4TcWN8EV277baizFA9tWdlbh6mNh3fYpyqFPrYK85GpcTfZxakglw2cSuhs0Yx
	co9tfa07NpfZUFDJA8RVSH2wThKeqftmKq2ltKgubfj3xskpic4xX+B8Fn07o9DUOssF
	9dpOvoNeLhznnkMdkGDk8yt5wAs67UX1idz1rNOZeEc4Mjelbh2tjVCGh7eAybCpq8Gw
	XF2w==
X-Gm-Message-State: ALoCoQkvLZ+Ah9JvIYDbtcWnTqCk7kd+dwlvze8trL8N1q2huubsmcViFHqg1fpAM+F4HqU9yy8e
X-Received: by 10.180.210.236 with SMTP id mx12mr7912770wic.16.1418760558683; 
	Tue, 16 Dec 2014 12:09:18 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.17
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:17 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:42 +0000
Message-Id: <1418760534-18163-2-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 01/13] xen/arm: gic-v2: Change the
	device name in DT_DEVICE_START
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm not sure why a ':' has been added in the name... But none of the
other usages doesn't have it.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/gic-v2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..f149e09 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -772,7 +772,7 @@ static const char * const gicv2_dt_compat[] __initconst =
     NULL
 };
 
-DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
+DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
         .compatible = gicv2_dt_compat,
         .init = gicv2_init,
 DT_DEVICE_END
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yR3-0004oV-BV; Tue, 16 Dec 2014 20:09:33 +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 1Y0yR1-0004nM-6c
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:32 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	46/90-22777-A7190945; Tue, 16 Dec 2014 20:09:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418760569!9589699!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3568 invoked from network); 16 Dec 2014 20:09:29 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:29 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so13488122wib.4
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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=dshB9d5U0zcsWf2ka1POEPTFDdGq+Ylr3zWcnMCfz8g=;
	b=bCW8uX2X9vlYmHngbII3ICr7GjU9XdEPFqbWOYFQ3dDwOhGBwktNLkgYWZpWZef9dJ
	sOcsJuavq17HDH0pzSMPcaWkE0RpW5WNc6AO6Fa3Z/2g5wL8oy5nervFqnSn8DK6edFR
	LWUH6J+CitsMIUYEoLwEKZW2SyN8dqn8BOo9fEOV06DYgZISzF3GQ+XNYHzPjD0HR950
	YHcrOj60g2kF9rZAdkY3F3d4CRiHBhTKrqx2UA00Tt9O6pzB5BPUHOTkVmQyxnWlx1p5
	vXtE271/ZX1EgigwT7tx1I+j+zEw2x0fx1mhHXKj2SvGz6JyaYZY9SvQZKfMJTBUeuIu
	zK1A==
X-Gm-Message-State: ALoCoQk94AmArR3T8HkxZNWNfC9c9gGRq2YfdIHkf4sAjamkhrct8hm1ln6/f5Wt6OL4xvFamXSp
X-Received: by 10.180.77.7 with SMTP id o7mr7549763wiw.81.1418760569099;
	Tue, 16 Dec 2014 12:09:29 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.27
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:27 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:48 +0000
Message-Id: <1418760534-18163-8-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way to
	describe 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

Currently, Xen is supporting PCI and Platform device (based on Device Tree).

While we don't support both at the same time: platform device for ARM
and PCI for x86, ARM will gain support on PCI soon.

Some drivers, such as IOMMU drivers, may handle PCI and platform device in
the same way. Only few lines of code differs.

Rather than requesting to provide 2 set of functions (one for PCI and
one for platform device), introduce a generic structure "device" which
is embedded in each specialized device.

At the same time replace any use of asm/device.h by xen/device.h. This
is required to be able to compile ARM correctly.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
CC: Jan Beulich <jbeulich@suse.com>
CC: Keir Fraser <keir@xen.org>
---
 xen/arch/arm/device.c               |  2 +-
 xen/arch/arm/domain_build.c         |  2 +-
 xen/arch/arm/gic-v2.c               |  3 +--
 xen/arch/arm/gic-v3.c               |  2 +-
 xen/arch/arm/gic.c                  |  2 +-
 xen/common/Makefile                 |  1 +
 xen/common/device.c                 | 21 +++++++++++++++++++
 xen/common/device_tree.c            |  1 +
 xen/drivers/char/dt-uart.c          |  4 ++--
 xen/drivers/char/exynos4210-uart.c  |  2 +-
 xen/drivers/char/ns16550.c          |  2 +-
 xen/drivers/char/omap-uart.c        |  2 +-
 xen/drivers/char/pl011.c            |  2 +-
 xen/drivers/passthrough/arm/iommu.c |  2 +-
 xen/drivers/passthrough/pci.c       |  2 ++
 xen/include/asm-arm/device.h        |  3 ++-
 xen/include/asm-x86/device.h        | 17 ++++++++++++++++
 xen/include/xen/device.h            | 40 +++++++++++++++++++++++++++++++++++++
 xen/include/xen/device_tree.h       | 13 ++++++++++++
 xen/include/xen/pci.h               | 12 +++++++++++
 20 files changed, 121 insertions(+), 14 deletions(-)
 create mode 100644 xen/common/device.c
 create mode 100644 xen/include/asm-x86/device.h
 create mode 100644 xen/include/xen/device.h

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 693b9af..de702ff 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -17,7 +17,7 @@
  * GNU General Public License for more details.
  */
 
-#include <asm/device.h>
+#include <xen/device.h>
 #include <xen/errno.h>
 #include <xen/lib.h>
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index de180d8..b701a2f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -9,10 +9,10 @@
 #include <asm/regs.h>
 #include <xen/errno.h>
 #include <xen/device_tree.h>
+#include <xen/device.h>
 #include <xen/libfdt/libfdt.h>
 #include <xen/guest_access.h>
 #include <xen/iocap.h>
-#include <asm/device.h>
 #include <asm/setup.h>
 #include <asm/platform.h>
 #include <asm/psci.h>
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index f149e09..048350b 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -27,12 +27,11 @@
 #include <xen/softirq.h>
 #include <xen/list.h>
 #include <xen/device_tree.h>
+#include <xen/device.h>
 #include <xen/libfdt/libfdt.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 #include <asm/platform.h>
-#include <asm/device.h>
-
 #include <asm/io.h>
 #include <asm/gic.h>
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 076aa62..c6d1876 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -31,12 +31,12 @@
 #include <xen/errno.h>
 #include <xen/delay.h>
 #include <xen/device_tree.h>
+#include <xen/device.h>
 #include <xen/sizes.h>
 #include <xen/libfdt/libfdt.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 #include <asm/io.h>
-#include <asm/device.h>
 #include <asm/gic.h>
 #include <asm/gic_v3_defs.h>
 #include <asm/cpufeature.h>
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index e7a1af5..d1ab6b5 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -27,10 +27,10 @@
 #include <xen/softirq.h>
 #include <xen/list.h>
 #include <xen/device_tree.h>
+#include <xen/device.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 #include <asm/platform.h>
-#include <asm/device.h>
 #include <asm/io.h>
 #include <asm/gic.h>
 #include <asm/vgic.h>
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 8391246..03ed719 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -2,6 +2,7 @@ obj-y += bitmap.o
 obj-y += core_parking.o
 obj-y += cpu.o
 obj-y += cpupool.o
+obj-y += device.o
 obj-$(HAS_DEVICE_TREE) += device_tree.o
 obj-y += domctl.o
 obj-y += domain.o
diff --git a/xen/common/device.c b/xen/common/device.c
new file mode 100644
index 0000000..3450f20
--- /dev/null
+++ b/xen/common/device.c
@@ -0,0 +1,21 @@
+#include <xen/types.h>
+#include <xen/device.h>
+
+void device_initialize(struct device *dev, enum device_type type)
+{
+    dev->type = type;
+
+#ifdef HAS_DEVICE_TREE
+    if ( type == DEV_DT )
+        dev->of_node = dev_to_dt(dev);
+#endif
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 34a1b9e..f471008 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1450,6 +1450,7 @@ static unsigned long __init unflatten_dt_node(const void *fdt,
             prev_pp = &pp->next;
 #endif
             np->name = pp->value;
+            device_initialize(&np->dev, DEV_DT);
             memcpy(pp->value, ps, sz - 1);
             ((char *)pp->value)[sz - 1] = 0;
             dt_dprintk("fixed up name for %s -> %s\n", pathp,
diff --git a/xen/drivers/char/dt-uart.c b/xen/drivers/char/dt-uart.c
index fa92b5c..01eced1 100644
--- a/xen/drivers/char/dt-uart.c
+++ b/xen/drivers/char/dt-uart.c
@@ -17,11 +17,11 @@
  * GNU General Public License for more details.
  */
 
-#include <asm/device.h>
-#include <asm/types.h>
+#include <xen/device.h>
 #include <xen/console.h>
 #include <xen/device_tree.h>
 #include <xen/serial.h>
+#include <asm/types.h>
 
 /*
  * Configure UART port with a string:
diff --git a/xen/drivers/char/exynos4210-uart.c b/xen/drivers/char/exynos4210-uart.c
index cba8729..75246e1 100644
--- a/xen/drivers/char/exynos4210-uart.c
+++ b/xen/drivers/char/exynos4210-uart.c
@@ -24,7 +24,7 @@
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/mm.h>
-#include <asm/device.h>
+#include <xen/device.h>
 #include <asm/exynos4210-uart.h>
 #include <asm/io.h>
 
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 161b251..6df3f95 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -25,7 +25,7 @@
 #include <xen/vmap.h>
 #include <asm/io.h>
 #ifdef HAS_DEVICE_TREE
-#include <asm/device.h>
+#include <xen/device.h>
 #endif
 #ifdef CONFIG_X86
 #include <asm/fixmap.h>
diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
index 16d1454..c4cd442 100644
--- a/xen/drivers/char/omap-uart.c
+++ b/xen/drivers/char/omap-uart.c
@@ -16,7 +16,7 @@
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/device_tree.h>
-#include <asm/device.h>
+#include <xen/device.h>
 #include <xen/errno.h>
 #include <xen/mm.h>
 #include <xen/vmap.h>
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..cc91224 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -23,8 +23,8 @@
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/device_tree.h>
+#include <xen/device.h>
 #include <xen/errno.h>
-#include <asm/device.h>
 #include <xen/mm.h>
 #include <xen/vmap.h>
 #include <asm/pl011-uart.h>
diff --git a/xen/drivers/passthrough/arm/iommu.c b/xen/drivers/passthrough/arm/iommu.c
index 3007b99..3e9303a 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -18,7 +18,7 @@
 #include <xen/lib.h>
 #include <xen/iommu.h>
 #include <xen/device_tree.h>
-#include <asm/device.h>
+#include <xen/device.h>
 
 static const struct iommu_ops *iommu_ops;
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..9fbd2a2 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -278,6 +278,8 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
     if ( !pdev )
         return NULL;
 
+    device_initialize(&pdev->dev, DEV_PCI);
+
     *(u16*) &pdev->seg = pseg->nr;
     *((u8*) &pdev->bus) = bus;
     *((u8*) &pdev->devfn) = devfn;
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 72a9028..fdcd097 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -2,7 +2,8 @@
 #define __ASM_ARM_DEVICE_H
 
 #include <xen/init.h>
-#include <xen/device_tree.h>
+
+struct dt_device_node;
 
 enum device_match
 {
diff --git a/xen/include/asm-x86/device.h b/xen/include/asm-x86/device.h
new file mode 100644
index 0000000..9d4c352
--- /dev/null
+++ b/xen/include/asm-x86/device.h
@@ -0,0 +1,17 @@
+#ifndef __ASM_X86_DEVICE_H
+#define __ASM_X86_DEVICE_H
+
+struct dev_archdata {
+    /* No device specific arch data */
+};
+
+#endif /* __ASM_X86_DEVICE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/device.h b/xen/include/xen/device.h
new file mode 100644
index 0000000..a9e20ad
--- /dev/null
+++ b/xen/include/xen/device.h
@@ -0,0 +1,40 @@
+#ifndef __XEN_DEVICE_H__
+#define __XEN_DEVICE_H__
+
+#include <asm/device.h>
+
+enum device_type
+{
+    DEV_PCI,
+    DEV_DT,
+};
+
+/* struct device - The basic device structure */
+struct device
+{
+    enum device_type type;
+#ifdef HAS_DEVICE_TREE
+    struct dt_device_node *of_node; /* Used by drivers imported from Linux */
+#endif
+    struct dev_archdata archdata;
+};
+
+#define dev_is_pci(dev) ((dev)->type == DEV_PCI)
+#define dev_is_dt(dev)  ((dev->type == DEV_DT)
+
+#ifdef HAS_DEVICE_TREE
+#include <xen/device_tree.h>
+#endif
+
+void device_initialize(struct device *dev, enum device_type type);
+
+#endif /* __XEN_DEVICE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 6502369..890d356 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -12,6 +12,8 @@
 
 #include <asm/byteorder.h>
 #include <public/xen.h>
+#include <xen/device.h>
+#include <xen/kernel.h>
 #include <xen/init.h>
 #include <xen/string.h>
 #include <xen/types.h>
@@ -80,8 +82,19 @@ struct dt_device_node {
     /* IOMMU specific fields */
     bool is_protected;
     struct list_head domain_list;
+
+    struct device dev;
 };
 
+#define dt_to_dev(dt_node)  (&(dt_node)->dev)
+
+static inline struct dt_device_node *dev_to_dt(struct device *dev)
+{
+    ASSERT(dev->type == DEV_DT);
+
+    return container_of(dev, struct dt_device_node, dev);
+}
+
 #define MAX_PHANDLE_ARGS 16
 struct dt_phandle_args {
     struct dt_device_node *np;
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 5f295f3..6ace79d 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -13,6 +13,7 @@
 #include <xen/irq.h>
 #include <xen/pci_regs.h>
 #include <xen/pfn.h>
+#include <xen/device.h>
 #include <asm/pci.h>
 
 /*
@@ -75,8 +76,19 @@ struct pci_dev {
 #define PT_FAULT_THRESHOLD 10
     } fault;
     u64 vf_rlen[6];
+
+    struct device dev;
 };
 
+#define pci_to_dev(pcidev)  (&(pcidev)->dev)
+
+static inline struct pci_dev *dev_to_pci(struct device *dev)
+{
+    ASSERT(dev->type == DEV_PCI);
+
+    return container_of(dev, struct pci_dev, dev);
+}
+
 #define for_each_pdev(domain, pdev) \
     list_for_each_entry(pdev, &(domain->arch.pdev_list), domain_list)
 
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yR9-0004sX-Tp; Tue, 16 Dec 2014 20:09:39 +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 1Y0yR8-0004qw-B0
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:38 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	DF/51-28865-18190945; Tue, 16 Dec 2014 20:09:37 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418760574!10358407!1
X-Originating-IP: [209.85.212.173]
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 2561 invoked from network); 16 Dec 2014 20:09:34 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:34 -0000
Received: by mail-wi0-f173.google.com with SMTP id r20so13484364wiv.12
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=wjZH/KY85lS0vsvPzCZjq5MOCd5nZXy6j5mmcWZJrgA=;
	b=DNFzL2JOFcoDjYn2xK8Mr52HiKisCKhrdnFgsCpl2k+brm+PhsZTzuk1X1SRpImAy1
	kkHltGhFkj3opJjoYqzMI/2bFvWnWAAaIQD2CnrEqD7sZ7oQLiKAfbdmSYCcFWoyKZYk
	nSl/xPph4zcz7FumKRPk1DCSzLf/OEIZqtfubPgEToMOkG5oGIAllt2XE5aH3rY/UkR8
	zA5MlXx6muvcBxIbxeH6QY5U/I6P7WX4AXr1AYL5yjWbCaPpqvQ317N8Ie7GEq+bYHp6
	HlInqevqoeRWbvmoA4Eqp9UxnIsZE5y+UvnNModoAx/6cv9D91x/cAD3gPCrRjTcPwq0
	sxcg==
X-Gm-Message-State: ALoCoQkBaeInmOku1mo+Pnw2nXdmfkRhjsKnETfZXazOObb8b3qua9XGnfYvY2cyglJkLWoJ6XbY
X-Received: by 10.194.5.227 with SMTP id v3mr66328438wjv.63.1418760574585;
	Tue, 16 Dec 2014 12:09:34 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.32
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:33 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:51 +0000
Message-Id: <1418760534-18163-11-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 10/13] xen/iommu: arm: Import the SMMU
	driver from Linux
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3.

It's a basic copy of the Linux SMMU drivers code. No Xen code has yet been added
and not build.

Compare to the previous drivers it gains support of PCI. Though it will
need a bit of plumbing for Xen.

Signed-of-by: Julien Grall <julien.grall@linaro.org>
---
 xen/drivers/passthrough/arm/smmu.c | 2193 ++++++++++++++++++++++++++++++++++++
 1 file changed, 2193 insertions(+)
 create mode 100644 xen/drivers/passthrough/arm/smmu.c

diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
new file mode 100644
index 0000000..6cd47b7
--- /dev/null
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -0,0 +1,2193 @@
+/*
+ * IOMMU API for ARM architected SMMU implementations.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) 2013 ARM Limited
+ *
+ * Author: Will Deacon <will.deacon@arm.com>
+ *
+ * This driver currently supports:
+ *	- SMMUv1 and v2 implementations
+ *	- Stream-matching and stream-indexing
+ *	- v7/v8 long-descriptor format
+ *	- Non-secure access to the SMMU
+ *	- 4k and 64k pages, with contiguous pte hints.
+ *	- Up to 48-bit addressing (dependent on VA_BITS)
+ *	- Context fault reporting
+ */
+
+#define pr_fmt(fmt) "arm-smmu: " fmt
+
+#include <linux/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iommu.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+
+#include <linux/amba/bus.h>
+
+#include <asm/pgalloc.h>
+
+/* Maximum number of stream IDs assigned to a single device */
+#define MAX_MASTER_STREAMIDS		MAX_PHANDLE_ARGS
+
+/* Maximum number of context banks per SMMU */
+#define ARM_SMMU_MAX_CBS		128
+
+/* Maximum number of mapping groups per SMMU */
+#define ARM_SMMU_MAX_SMRS		128
+
+/* SMMU global address space */
+#define ARM_SMMU_GR0(smmu)		((smmu)->base)
+#define ARM_SMMU_GR1(smmu)		((smmu)->base + (1 << (smmu)->pgshift))
+
+/*
+ * SMMU global address space with conditional offset to access secure
+ * aliases of non-secure registers (e.g. nsCR0: 0x400, nsGFSR: 0x448,
+ * nsGFSYNR0: 0x450)
+ */
+#define ARM_SMMU_GR0_NS(smmu)						\
+	((smmu)->base +							\
+		((smmu->options & ARM_SMMU_OPT_SECURE_CFG_ACCESS)	\
+			? 0x400 : 0))
+
+/* Page table bits */
+#define ARM_SMMU_PTE_XN			(((pteval_t)3) << 53)
+#define ARM_SMMU_PTE_CONT		(((pteval_t)1) << 52)
+#define ARM_SMMU_PTE_AF			(((pteval_t)1) << 10)
+#define ARM_SMMU_PTE_SH_NS		(((pteval_t)0) << 8)
+#define ARM_SMMU_PTE_SH_OS		(((pteval_t)2) << 8)
+#define ARM_SMMU_PTE_SH_IS		(((pteval_t)3) << 8)
+#define ARM_SMMU_PTE_PAGE		(((pteval_t)3) << 0)
+
+#if PAGE_SIZE == SZ_4K
+#define ARM_SMMU_PTE_CONT_ENTRIES	16
+#elif PAGE_SIZE == SZ_64K
+#define ARM_SMMU_PTE_CONT_ENTRIES	32
+#else
+#define ARM_SMMU_PTE_CONT_ENTRIES	1
+#endif
+
+#define ARM_SMMU_PTE_CONT_SIZE		(PAGE_SIZE * ARM_SMMU_PTE_CONT_ENTRIES)
+#define ARM_SMMU_PTE_CONT_MASK		(~(ARM_SMMU_PTE_CONT_SIZE - 1))
+
+/* Stage-1 PTE */
+#define ARM_SMMU_PTE_AP_UNPRIV		(((pteval_t)1) << 6)
+#define ARM_SMMU_PTE_AP_RDONLY		(((pteval_t)2) << 6)
+#define ARM_SMMU_PTE_ATTRINDX_SHIFT	2
+#define ARM_SMMU_PTE_nG			(((pteval_t)1) << 11)
+
+/* Stage-2 PTE */
+#define ARM_SMMU_PTE_HAP_FAULT		(((pteval_t)0) << 6)
+#define ARM_SMMU_PTE_HAP_READ		(((pteval_t)1) << 6)
+#define ARM_SMMU_PTE_HAP_WRITE		(((pteval_t)2) << 6)
+#define ARM_SMMU_PTE_MEMATTR_OIWB	(((pteval_t)0xf) << 2)
+#define ARM_SMMU_PTE_MEMATTR_NC		(((pteval_t)0x5) << 2)
+#define ARM_SMMU_PTE_MEMATTR_DEV	(((pteval_t)0x1) << 2)
+
+/* Configuration registers */
+#define ARM_SMMU_GR0_sCR0		0x0
+#define sCR0_CLIENTPD			(1 << 0)
+#define sCR0_GFRE			(1 << 1)
+#define sCR0_GFIE			(1 << 2)
+#define sCR0_GCFGFRE			(1 << 4)
+#define sCR0_GCFGFIE			(1 << 5)
+#define sCR0_USFCFG			(1 << 10)
+#define sCR0_VMIDPNE			(1 << 11)
+#define sCR0_PTM			(1 << 12)
+#define sCR0_FB				(1 << 13)
+#define sCR0_BSU_SHIFT			14
+#define sCR0_BSU_MASK			0x3
+
+/* Identification registers */
+#define ARM_SMMU_GR0_ID0		0x20
+#define ARM_SMMU_GR0_ID1		0x24
+#define ARM_SMMU_GR0_ID2		0x28
+#define ARM_SMMU_GR0_ID3		0x2c
+#define ARM_SMMU_GR0_ID4		0x30
+#define ARM_SMMU_GR0_ID5		0x34
+#define ARM_SMMU_GR0_ID6		0x38
+#define ARM_SMMU_GR0_ID7		0x3c
+#define ARM_SMMU_GR0_sGFSR		0x48
+#define ARM_SMMU_GR0_sGFSYNR0		0x50
+#define ARM_SMMU_GR0_sGFSYNR1		0x54
+#define ARM_SMMU_GR0_sGFSYNR2		0x58
+#define ARM_SMMU_GR0_PIDR0		0xfe0
+#define ARM_SMMU_GR0_PIDR1		0xfe4
+#define ARM_SMMU_GR0_PIDR2		0xfe8
+
+#define ID0_S1TS			(1 << 30)
+#define ID0_S2TS			(1 << 29)
+#define ID0_NTS				(1 << 28)
+#define ID0_SMS				(1 << 27)
+#define ID0_PTFS_SHIFT			24
+#define ID0_PTFS_MASK			0x2
+#define ID0_PTFS_V8_ONLY		0x2
+#define ID0_CTTW			(1 << 14)
+#define ID0_NUMIRPT_SHIFT		16
+#define ID0_NUMIRPT_MASK		0xff
+#define ID0_NUMSIDB_SHIFT		9
+#define ID0_NUMSIDB_MASK		0xf
+#define ID0_NUMSMRG_SHIFT		0
+#define ID0_NUMSMRG_MASK		0xff
+
+#define ID1_PAGESIZE			(1 << 31)
+#define ID1_NUMPAGENDXB_SHIFT		28
+#define ID1_NUMPAGENDXB_MASK		7
+#define ID1_NUMS2CB_SHIFT		16
+#define ID1_NUMS2CB_MASK		0xff
+#define ID1_NUMCB_SHIFT			0
+#define ID1_NUMCB_MASK			0xff
+
+#define ID2_OAS_SHIFT			4
+#define ID2_OAS_MASK			0xf
+#define ID2_IAS_SHIFT			0
+#define ID2_IAS_MASK			0xf
+#define ID2_UBS_SHIFT			8
+#define ID2_UBS_MASK			0xf
+#define ID2_PTFS_4K			(1 << 12)
+#define ID2_PTFS_16K			(1 << 13)
+#define ID2_PTFS_64K			(1 << 14)
+
+#define PIDR2_ARCH_SHIFT		4
+#define PIDR2_ARCH_MASK			0xf
+
+/* Global TLB invalidation */
+#define ARM_SMMU_GR0_STLBIALL		0x60
+#define ARM_SMMU_GR0_TLBIVMID		0x64
+#define ARM_SMMU_GR0_TLBIALLNSNH	0x68
+#define ARM_SMMU_GR0_TLBIALLH		0x6c
+#define ARM_SMMU_GR0_sTLBGSYNC		0x70
+#define ARM_SMMU_GR0_sTLBGSTATUS	0x74
+#define sTLBGSTATUS_GSACTIVE		(1 << 0)
+#define TLB_LOOP_TIMEOUT		1000000	/* 1s! */
+
+/* Stream mapping registers */
+#define ARM_SMMU_GR0_SMR(n)		(0x800 + ((n) << 2))
+#define SMR_VALID			(1 << 31)
+#define SMR_MASK_SHIFT			16
+#define SMR_MASK_MASK			0x7fff
+#define SMR_ID_SHIFT			0
+#define SMR_ID_MASK			0x7fff
+
+#define ARM_SMMU_GR0_S2CR(n)		(0xc00 + ((n) << 2))
+#define S2CR_CBNDX_SHIFT		0
+#define S2CR_CBNDX_MASK			0xff
+#define S2CR_TYPE_SHIFT			16
+#define S2CR_TYPE_MASK			0x3
+#define S2CR_TYPE_TRANS			(0 << S2CR_TYPE_SHIFT)
+#define S2CR_TYPE_BYPASS		(1 << S2CR_TYPE_SHIFT)
+#define S2CR_TYPE_FAULT			(2 << S2CR_TYPE_SHIFT)
+
+/* Context bank attribute registers */
+#define ARM_SMMU_GR1_CBAR(n)		(0x0 + ((n) << 2))
+#define CBAR_VMID_SHIFT			0
+#define CBAR_VMID_MASK			0xff
+#define CBAR_S1_BPSHCFG_SHIFT		8
+#define CBAR_S1_BPSHCFG_MASK		3
+#define CBAR_S1_BPSHCFG_NSH		3
+#define CBAR_S1_MEMATTR_SHIFT		12
+#define CBAR_S1_MEMATTR_MASK		0xf
+#define CBAR_S1_MEMATTR_WB		0xf
+#define CBAR_TYPE_SHIFT			16
+#define CBAR_TYPE_MASK			0x3
+#define CBAR_TYPE_S2_TRANS		(0 << CBAR_TYPE_SHIFT)
+#define CBAR_TYPE_S1_TRANS_S2_BYPASS	(1 << CBAR_TYPE_SHIFT)
+#define CBAR_TYPE_S1_TRANS_S2_FAULT	(2 << CBAR_TYPE_SHIFT)
+#define CBAR_TYPE_S1_TRANS_S2_TRANS	(3 << CBAR_TYPE_SHIFT)
+#define CBAR_IRPTNDX_SHIFT		24
+#define CBAR_IRPTNDX_MASK		0xff
+
+#define ARM_SMMU_GR1_CBA2R(n)		(0x800 + ((n) << 2))
+#define CBA2R_RW64_32BIT		(0 << 0)
+#define CBA2R_RW64_64BIT		(1 << 0)
+
+/* Translation context bank */
+#define ARM_SMMU_CB_BASE(smmu)		((smmu)->base + ((smmu)->size >> 1))
+#define ARM_SMMU_CB(smmu, n)		((n) * (1 << (smmu)->pgshift))
+
+#define ARM_SMMU_CB_SCTLR		0x0
+#define ARM_SMMU_CB_RESUME		0x8
+#define ARM_SMMU_CB_TTBCR2		0x10
+#define ARM_SMMU_CB_TTBR0_LO		0x20
+#define ARM_SMMU_CB_TTBR0_HI		0x24
+#define ARM_SMMU_CB_TTBCR		0x30
+#define ARM_SMMU_CB_S1_MAIR0		0x38
+#define ARM_SMMU_CB_FSR			0x58
+#define ARM_SMMU_CB_FAR_LO		0x60
+#define ARM_SMMU_CB_FAR_HI		0x64
+#define ARM_SMMU_CB_FSYNR0		0x68
+#define ARM_SMMU_CB_S1_TLBIASID		0x610
+
+#define SCTLR_S1_ASIDPNE		(1 << 12)
+#define SCTLR_CFCFG			(1 << 7)
+#define SCTLR_CFIE			(1 << 6)
+#define SCTLR_CFRE			(1 << 5)
+#define SCTLR_E				(1 << 4)
+#define SCTLR_AFE			(1 << 2)
+#define SCTLR_TRE			(1 << 1)
+#define SCTLR_M				(1 << 0)
+#define SCTLR_EAE_SBOP			(SCTLR_AFE | SCTLR_TRE)
+
+#define RESUME_RETRY			(0 << 0)
+#define RESUME_TERMINATE		(1 << 0)
+
+#define TTBCR_EAE			(1 << 31)
+
+#define TTBCR_PASIZE_SHIFT		16
+#define TTBCR_PASIZE_MASK		0x7
+
+#define TTBCR_TG0_4K			(0 << 14)
+#define TTBCR_TG0_64K			(1 << 14)
+
+#define TTBCR_SH0_SHIFT			12
+#define TTBCR_SH0_MASK			0x3
+#define TTBCR_SH_NS			0
+#define TTBCR_SH_OS			2
+#define TTBCR_SH_IS			3
+
+#define TTBCR_ORGN0_SHIFT		10
+#define TTBCR_IRGN0_SHIFT		8
+#define TTBCR_RGN_MASK			0x3
+#define TTBCR_RGN_NC			0
+#define TTBCR_RGN_WBWA			1
+#define TTBCR_RGN_WT			2
+#define TTBCR_RGN_WB			3
+
+#define TTBCR_SL0_SHIFT			6
+#define TTBCR_SL0_MASK			0x3
+#define TTBCR_SL0_LVL_2			0
+#define TTBCR_SL0_LVL_1			1
+
+#define TTBCR_T1SZ_SHIFT		16
+#define TTBCR_T0SZ_SHIFT		0
+#define TTBCR_SZ_MASK			0xf
+
+#define TTBCR2_SEP_SHIFT		15
+#define TTBCR2_SEP_MASK			0x7
+
+#define TTBCR2_PASIZE_SHIFT		0
+#define TTBCR2_PASIZE_MASK		0x7
+
+/* Common definitions for PASize and SEP fields */
+#define TTBCR2_ADDR_32			0
+#define TTBCR2_ADDR_36			1
+#define TTBCR2_ADDR_40			2
+#define TTBCR2_ADDR_42			3
+#define TTBCR2_ADDR_44			4
+#define TTBCR2_ADDR_48			5
+
+#define TTBRn_HI_ASID_SHIFT		16
+
+#define MAIR_ATTR_SHIFT(n)		((n) << 3)
+#define MAIR_ATTR_MASK			0xff
+#define MAIR_ATTR_DEVICE		0x04
+#define MAIR_ATTR_NC			0x44
+#define MAIR_ATTR_WBRWA			0xff
+#define MAIR_ATTR_IDX_NC		0
+#define MAIR_ATTR_IDX_CACHE		1
+#define MAIR_ATTR_IDX_DEV		2
+
+#define FSR_MULTI			(1 << 31)
+#define FSR_SS				(1 << 30)
+#define FSR_UUT				(1 << 8)
+#define FSR_ASF				(1 << 7)
+#define FSR_TLBLKF			(1 << 6)
+#define FSR_TLBMCF			(1 << 5)
+#define FSR_EF				(1 << 4)
+#define FSR_PF				(1 << 3)
+#define FSR_AFF				(1 << 2)
+#define FSR_TF				(1 << 1)
+
+#define FSR_IGN				(FSR_AFF | FSR_ASF | \
+					 FSR_TLBMCF | FSR_TLBLKF)
+#define FSR_FAULT			(FSR_MULTI | FSR_SS | FSR_UUT | \
+					 FSR_EF | FSR_PF | FSR_TF | FSR_IGN)
+
+#define FSYNR0_WNR			(1 << 4)
+
+static int force_stage;
+module_param_named(force_stage, force_stage, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(force_stage,
+	"Force SMMU mappings to be installed at a particular stage of translation. A value of '1' or '2' forces the corresponding stage. All other values are ignored (i.e. no stage is forced). Note that selecting a specific stage will disable support for nested translation.");
+
+enum arm_smmu_arch_version {
+	ARM_SMMU_V1 = 1,
+	ARM_SMMU_V2,
+};
+
+struct arm_smmu_smr {
+	u8				idx;
+	u16				mask;
+	u16				id;
+};
+
+struct arm_smmu_master_cfg {
+	int				num_streamids;
+	u16				streamids[MAX_MASTER_STREAMIDS];
+	struct arm_smmu_smr		*smrs;
+};
+
+struct arm_smmu_master {
+	struct device_node		*of_node;
+	struct rb_node			node;
+	struct arm_smmu_master_cfg	cfg;
+};
+
+struct arm_smmu_device {
+	struct device			*dev;
+
+	void __iomem			*base;
+	unsigned long			size;
+	unsigned long			pgshift;
+
+#define ARM_SMMU_FEAT_COHERENT_WALK	(1 << 0)
+#define ARM_SMMU_FEAT_STREAM_MATCH	(1 << 1)
+#define ARM_SMMU_FEAT_TRANS_S1		(1 << 2)
+#define ARM_SMMU_FEAT_TRANS_S2		(1 << 3)
+#define ARM_SMMU_FEAT_TRANS_NESTED	(1 << 4)
+	u32				features;
+
+#define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
+	u32				options;
+	enum arm_smmu_arch_version	version;
+
+	u32				num_context_banks;
+	u32				num_s2_context_banks;
+	DECLARE_BITMAP(context_map, ARM_SMMU_MAX_CBS);
+	atomic_t			irptndx;
+
+	u32				num_mapping_groups;
+	DECLARE_BITMAP(smr_map, ARM_SMMU_MAX_SMRS);
+
+	unsigned long			s1_input_size;
+	unsigned long			s1_output_size;
+	unsigned long			s2_input_size;
+	unsigned long			s2_output_size;
+
+	u32				num_global_irqs;
+	u32				num_context_irqs;
+	unsigned int			*irqs;
+
+	struct list_head		list;
+	struct rb_root			masters;
+};
+
+struct arm_smmu_cfg {
+	u8				cbndx;
+	u8				irptndx;
+	u32				cbar;
+	pgd_t				*pgd;
+};
+#define INVALID_IRPTNDX			0xff
+
+#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
+#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
+
+enum arm_smmu_domain_stage {
+	ARM_SMMU_DOMAIN_S1 = 0,
+	ARM_SMMU_DOMAIN_S2,
+	ARM_SMMU_DOMAIN_NESTED,
+};
+
+struct arm_smmu_domain {
+	struct arm_smmu_device		*smmu;
+	struct arm_smmu_cfg		cfg;
+	enum arm_smmu_domain_stage	stage;
+	spinlock_t			lock;
+};
+
+static DEFINE_SPINLOCK(arm_smmu_devices_lock);
+static LIST_HEAD(arm_smmu_devices);
+
+struct arm_smmu_option_prop {
+	u32 opt;
+	const char *prop;
+};
+
+static struct arm_smmu_option_prop arm_smmu_options[] = {
+	{ ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
+	{ 0, NULL},
+};
+
+static void parse_driver_options(struct arm_smmu_device *smmu)
+{
+	int i = 0;
+
+	do {
+		if (of_property_read_bool(smmu->dev->of_node,
+						arm_smmu_options[i].prop)) {
+			smmu->options |= arm_smmu_options[i].opt;
+			dev_notice(smmu->dev, "option %s\n",
+				arm_smmu_options[i].prop);
+		}
+	} while (arm_smmu_options[++i].opt);
+}
+
+static struct device_node *dev_get_dev_node(struct device *dev)
+{
+	if (dev_is_pci(dev)) {
+		struct pci_bus *bus = to_pci_dev(dev)->bus;
+
+		while (!pci_is_root_bus(bus))
+			bus = bus->parent;
+		return bus->bridge->parent->of_node;
+	}
+
+	return dev->of_node;
+}
+
+static struct arm_smmu_master *find_smmu_master(struct arm_smmu_device *smmu,
+						struct device_node *dev_node)
+{
+	struct rb_node *node = smmu->masters.rb_node;
+
+	while (node) {
+		struct arm_smmu_master *master;
+
+		master = container_of(node, struct arm_smmu_master, node);
+
+		if (dev_node < master->of_node)
+			node = node->rb_left;
+		else if (dev_node > master->of_node)
+			node = node->rb_right;
+		else
+			return master;
+	}
+
+	return NULL;
+}
+
+static struct arm_smmu_master_cfg *
+find_smmu_master_cfg(struct device *dev)
+{
+	struct arm_smmu_master_cfg *cfg = NULL;
+	struct iommu_group *group = iommu_group_get(dev);
+
+	if (group) {
+		cfg = iommu_group_get_iommudata(group);
+		iommu_group_put(group);
+	}
+
+	return cfg;
+}
+
+static int insert_smmu_master(struct arm_smmu_device *smmu,
+			      struct arm_smmu_master *master)
+{
+	struct rb_node **new, *parent;
+
+	new = &smmu->masters.rb_node;
+	parent = NULL;
+	while (*new) {
+		struct arm_smmu_master *this
+			= container_of(*new, struct arm_smmu_master, node);
+
+		parent = *new;
+		if (master->of_node < this->of_node)
+			new = &((*new)->rb_left);
+		else if (master->of_node > this->of_node)
+			new = &((*new)->rb_right);
+		else
+			return -EEXIST;
+	}
+
+	rb_link_node(&master->node, parent, new);
+	rb_insert_color(&master->node, &smmu->masters);
+	return 0;
+}
+
+static int register_smmu_master(struct arm_smmu_device *smmu,
+				struct device *dev,
+				struct of_phandle_args *masterspec)
+{
+	int i;
+	struct arm_smmu_master *master;
+
+	master = find_smmu_master(smmu, masterspec->np);
+	if (master) {
+		dev_err(dev,
+			"rejecting multiple registrations for master device %s\n",
+			masterspec->np->name);
+		return -EBUSY;
+	}
+
+	if (masterspec->args_count > MAX_MASTER_STREAMIDS) {
+		dev_err(dev,
+			"reached maximum number (%d) of stream IDs for master device %s\n",
+			MAX_MASTER_STREAMIDS, masterspec->np->name);
+		return -ENOSPC;
+	}
+
+	master = devm_kzalloc(dev, sizeof(*master), GFP_KERNEL);
+	if (!master)
+		return -ENOMEM;
+
+	master->of_node			= masterspec->np;
+	master->cfg.num_streamids	= masterspec->args_count;
+
+	for (i = 0; i < master->cfg.num_streamids; ++i) {
+		u16 streamid = masterspec->args[i];
+
+		if (!(smmu->features & ARM_SMMU_FEAT_STREAM_MATCH) &&
+		     (streamid >= smmu->num_mapping_groups)) {
+			dev_err(dev,
+				"stream ID for master device %s greater than maximum allowed (%d)\n",
+				masterspec->np->name, smmu->num_mapping_groups);
+			return -ERANGE;
+		}
+		master->cfg.streamids[i] = streamid;
+	}
+	return insert_smmu_master(smmu, master);
+}
+
+static struct arm_smmu_device *find_smmu_for_device(struct device *dev)
+{
+	struct arm_smmu_device *smmu;
+	struct arm_smmu_master *master = NULL;
+	struct device_node *dev_node = dev_get_dev_node(dev);
+
+	spin_lock(&arm_smmu_devices_lock);
+	list_for_each_entry(smmu, &arm_smmu_devices, list) {
+		master = find_smmu_master(smmu, dev_node);
+		if (master)
+			break;
+	}
+	spin_unlock(&arm_smmu_devices_lock);
+
+	return master ? smmu : NULL;
+}
+
+static int __arm_smmu_alloc_bitmap(unsigned long *map, int start, int end)
+{
+	int idx;
+
+	do {
+		idx = find_next_zero_bit(map, end, start);
+		if (idx == end)
+			return -ENOSPC;
+	} while (test_and_set_bit(idx, map));
+
+	return idx;
+}
+
+static void __arm_smmu_free_bitmap(unsigned long *map, int idx)
+{
+	clear_bit(idx, map);
+}
+
+/* Wait for any pending TLB invalidations to complete */
+static void arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
+{
+	int count = 0;
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+
+	writel_relaxed(0, gr0_base + ARM_SMMU_GR0_sTLBGSYNC);
+	while (readl_relaxed(gr0_base + ARM_SMMU_GR0_sTLBGSTATUS)
+	       & sTLBGSTATUS_GSACTIVE) {
+		cpu_relax();
+		if (++count == TLB_LOOP_TIMEOUT) {
+			dev_err_ratelimited(smmu->dev,
+			"TLB sync timed out -- SMMU may be deadlocked\n");
+			return;
+		}
+		udelay(1);
+	}
+}
+
+static void arm_smmu_tlb_inv_context(struct arm_smmu_domain *smmu_domain)
+{
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	void __iomem *base = ARM_SMMU_GR0(smmu);
+	bool stage1 = cfg->cbar != CBAR_TYPE_S2_TRANS;
+
+	if (stage1) {
+		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
+		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
+			       base + ARM_SMMU_CB_S1_TLBIASID);
+	} else {
+		base = ARM_SMMU_GR0(smmu);
+		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
+			       base + ARM_SMMU_GR0_TLBIVMID);
+	}
+
+	arm_smmu_tlb_sync(smmu);
+}
+
+static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
+{
+	int flags, ret;
+	u32 fsr, far, fsynr, resume;
+	unsigned long iova;
+	struct iommu_domain *domain = dev;
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	void __iomem *cb_base;
+
+	cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
+	fsr = readl_relaxed(cb_base + ARM_SMMU_CB_FSR);
+
+	if (!(fsr & FSR_FAULT))
+		return IRQ_NONE;
+
+	if (fsr & FSR_IGN)
+		dev_err_ratelimited(smmu->dev,
+				    "Unexpected context fault (fsr 0x%x)\n",
+				    fsr);
+
+	fsynr = readl_relaxed(cb_base + ARM_SMMU_CB_FSYNR0);
+	flags = fsynr & FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ;
+
+	far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_LO);
+	iova = far;
+#ifdef CONFIG_64BIT
+	far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_HI);
+	iova |= ((unsigned long)far << 32);
+#endif
+
+	if (!report_iommu_fault(domain, smmu->dev, iova, flags)) {
+		ret = IRQ_HANDLED;
+		resume = RESUME_RETRY;
+	} else {
+		dev_err_ratelimited(smmu->dev,
+		    "Unhandled context fault: iova=0x%08lx, fsynr=0x%x, cb=%d\n",
+		    iova, fsynr, cfg->cbndx);
+		ret = IRQ_NONE;
+		resume = RESUME_TERMINATE;
+	}
+
+	/* Clear the faulting FSR */
+	writel(fsr, cb_base + ARM_SMMU_CB_FSR);
+
+	/* Retry or terminate any stalled transactions */
+	if (fsr & FSR_SS)
+		writel_relaxed(resume, cb_base + ARM_SMMU_CB_RESUME);
+
+	return ret;
+}
+
+static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
+{
+	u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
+	struct arm_smmu_device *smmu = dev;
+	void __iomem *gr0_base = ARM_SMMU_GR0_NS(smmu);
+
+	gfsr = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSR);
+	gfsynr0 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR0);
+	gfsynr1 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR1);
+	gfsynr2 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR2);
+
+	if (!gfsr)
+		return IRQ_NONE;
+
+	dev_err_ratelimited(smmu->dev,
+		"Unexpected global fault, this could be serious\n");
+	dev_err_ratelimited(smmu->dev,
+		"\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
+		gfsr, gfsynr0, gfsynr1, gfsynr2);
+
+	writel(gfsr, gr0_base + ARM_SMMU_GR0_sGFSR);
+	return IRQ_HANDLED;
+}
+
+static void arm_smmu_flush_pgtable(struct arm_smmu_device *smmu, void *addr,
+				   size_t size)
+{
+	unsigned long offset = (unsigned long)addr & ~PAGE_MASK;
+
+
+	/* Ensure new page tables are visible to the hardware walker */
+	if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK) {
+		dsb(ishst);
+	} else {
+		/*
+		 * If the SMMU can't walk tables in the CPU caches, treat them
+		 * like non-coherent DMA since we need to flush the new entries
+		 * all the way out to memory. There's no possibility of
+		 * recursion here as the SMMU table walker will not be wired
+		 * through another SMMU.
+		 */
+		dma_map_page(smmu->dev, virt_to_page(addr), offset, size,
+				DMA_TO_DEVICE);
+	}
+}
+
+static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
+{
+	u32 reg;
+	bool stage1;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	void __iomem *cb_base, *gr0_base, *gr1_base;
+
+	gr0_base = ARM_SMMU_GR0(smmu);
+	gr1_base = ARM_SMMU_GR1(smmu);
+	stage1 = cfg->cbar != CBAR_TYPE_S2_TRANS;
+	cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
+
+	/* CBAR */
+	reg = cfg->cbar;
+	if (smmu->version == ARM_SMMU_V1)
+		reg |= cfg->irptndx << CBAR_IRPTNDX_SHIFT;
+
+	/*
+	 * Use the weakest shareability/memory types, so they are
+	 * overridden by the ttbcr/pte.
+	 */
+	if (stage1) {
+		reg |= (CBAR_S1_BPSHCFG_NSH << CBAR_S1_BPSHCFG_SHIFT) |
+			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
+	} else {
+		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
+	}
+	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
+
+	if (smmu->version > ARM_SMMU_V1) {
+		/* CBA2R */
+#ifdef CONFIG_64BIT
+		reg = CBA2R_RW64_64BIT;
+#else
+		reg = CBA2R_RW64_32BIT;
+#endif
+		writel_relaxed(reg,
+			       gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
+
+		/* TTBCR2 */
+		switch (smmu->s1_input_size) {
+		case 32:
+			reg = (TTBCR2_ADDR_32 << TTBCR2_SEP_SHIFT);
+			break;
+		case 36:
+			reg = (TTBCR2_ADDR_36 << TTBCR2_SEP_SHIFT);
+			break;
+		case 39:
+		case 40:
+			reg = (TTBCR2_ADDR_40 << TTBCR2_SEP_SHIFT);
+			break;
+		case 42:
+			reg = (TTBCR2_ADDR_42 << TTBCR2_SEP_SHIFT);
+			break;
+		case 44:
+			reg = (TTBCR2_ADDR_44 << TTBCR2_SEP_SHIFT);
+			break;
+		case 48:
+			reg = (TTBCR2_ADDR_48 << TTBCR2_SEP_SHIFT);
+			break;
+		}
+
+		switch (smmu->s1_output_size) {
+		case 32:
+			reg |= (TTBCR2_ADDR_32 << TTBCR2_PASIZE_SHIFT);
+			break;
+		case 36:
+			reg |= (TTBCR2_ADDR_36 << TTBCR2_PASIZE_SHIFT);
+			break;
+		case 39:
+		case 40:
+			reg |= (TTBCR2_ADDR_40 << TTBCR2_PASIZE_SHIFT);
+			break;
+		case 42:
+			reg |= (TTBCR2_ADDR_42 << TTBCR2_PASIZE_SHIFT);
+			break;
+		case 44:
+			reg |= (TTBCR2_ADDR_44 << TTBCR2_PASIZE_SHIFT);
+			break;
+		case 48:
+			reg |= (TTBCR2_ADDR_48 << TTBCR2_PASIZE_SHIFT);
+			break;
+		}
+
+		if (stage1)
+			writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBCR2);
+	}
+
+	/* TTBR0 */
+	arm_smmu_flush_pgtable(smmu, cfg->pgd,
+			       PTRS_PER_PGD * sizeof(pgd_t));
+	reg = __pa(cfg->pgd);
+	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
+	reg = (phys_addr_t)__pa(cfg->pgd) >> 32;
+	if (stage1)
+		reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
+	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
+
+	/*
+	 * TTBCR
+	 * We use long descriptor, with inner-shareable WBWA tables in TTBR0.
+	 */
+	if (smmu->version > ARM_SMMU_V1) {
+		if (PAGE_SIZE == SZ_4K)
+			reg = TTBCR_TG0_4K;
+		else
+			reg = TTBCR_TG0_64K;
+
+		if (!stage1) {
+			reg |= (64 - smmu->s2_input_size) << TTBCR_T0SZ_SHIFT;
+
+			switch (smmu->s2_output_size) {
+			case 32:
+				reg |= (TTBCR2_ADDR_32 << TTBCR_PASIZE_SHIFT);
+				break;
+			case 36:
+				reg |= (TTBCR2_ADDR_36 << TTBCR_PASIZE_SHIFT);
+				break;
+			case 40:
+				reg |= (TTBCR2_ADDR_40 << TTBCR_PASIZE_SHIFT);
+				break;
+			case 42:
+				reg |= (TTBCR2_ADDR_42 << TTBCR_PASIZE_SHIFT);
+				break;
+			case 44:
+				reg |= (TTBCR2_ADDR_44 << TTBCR_PASIZE_SHIFT);
+				break;
+			case 48:
+				reg |= (TTBCR2_ADDR_48 << TTBCR_PASIZE_SHIFT);
+				break;
+			}
+		} else {
+			reg |= (64 - smmu->s1_input_size) << TTBCR_T0SZ_SHIFT;
+		}
+	} else {
+		reg = 0;
+	}
+
+	reg |= TTBCR_EAE |
+	      (TTBCR_SH_IS << TTBCR_SH0_SHIFT) |
+	      (TTBCR_RGN_WBWA << TTBCR_ORGN0_SHIFT) |
+	      (TTBCR_RGN_WBWA << TTBCR_IRGN0_SHIFT);
+
+	if (!stage1)
+		reg |= (TTBCR_SL0_LVL_1 << TTBCR_SL0_SHIFT);
+
+	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBCR);
+
+	/* MAIR0 (stage-1 only) */
+	if (stage1) {
+		reg = (MAIR_ATTR_NC << MAIR_ATTR_SHIFT(MAIR_ATTR_IDX_NC)) |
+		      (MAIR_ATTR_WBRWA << MAIR_ATTR_SHIFT(MAIR_ATTR_IDX_CACHE)) |
+		      (MAIR_ATTR_DEVICE << MAIR_ATTR_SHIFT(MAIR_ATTR_IDX_DEV));
+		writel_relaxed(reg, cb_base + ARM_SMMU_CB_S1_MAIR0);
+	}
+
+	/* SCTLR */
+	reg = SCTLR_CFCFG | SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP;
+	if (stage1)
+		reg |= SCTLR_S1_ASIDPNE;
+#ifdef __BIG_ENDIAN
+	reg |= SCTLR_E;
+#endif
+	writel_relaxed(reg, cb_base + ARM_SMMU_CB_SCTLR);
+}
+
+static int arm_smmu_init_domain_context(struct iommu_domain *domain,
+					struct arm_smmu_device *smmu)
+{
+	int irq, start, ret = 0;
+	unsigned long flags;
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+
+	spin_lock_irqsave(&smmu_domain->lock, flags);
+	if (smmu_domain->smmu)
+		goto out_unlock;
+
+	/*
+	 * Mapping the requested stage onto what we support is surprisingly
+	 * complicated, mainly because the spec allows S1+S2 SMMUs without
+	 * support for nested translation. That means we end up with the
+	 * following table:
+	 *
+	 * Requested        Supported        Actual
+	 *     S1               N              S1
+	 *     S1             S1+S2            S1
+	 *     S1               S2             S2
+	 *     S1               S1             S1
+	 *     N                N              N
+	 *     N              S1+S2            S2
+	 *     N                S2             S2
+	 *     N                S1             S1
+	 *
+	 * Note that you can't actually request stage-2 mappings.
+	 */
+	if (!(smmu->features & ARM_SMMU_FEAT_TRANS_S1))
+		smmu_domain->stage = ARM_SMMU_DOMAIN_S2;
+	if (!(smmu->features & ARM_SMMU_FEAT_TRANS_S2))
+		smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
+
+	switch (smmu_domain->stage) {
+	case ARM_SMMU_DOMAIN_S1:
+		cfg->cbar = CBAR_TYPE_S1_TRANS_S2_BYPASS;
+		start = smmu->num_s2_context_banks;
+		break;
+	case ARM_SMMU_DOMAIN_NESTED:
+		/*
+		 * We will likely want to change this if/when KVM gets
+		 * involved.
+		 */
+	case ARM_SMMU_DOMAIN_S2:
+		cfg->cbar = CBAR_TYPE_S2_TRANS;
+		start = 0;
+		break;
+	default:
+		ret = -EINVAL;
+		goto out_unlock;
+	}
+
+	ret = __arm_smmu_alloc_bitmap(smmu->context_map, start,
+				      smmu->num_context_banks);
+	if (IS_ERR_VALUE(ret))
+		goto out_unlock;
+
+	cfg->cbndx = ret;
+	if (smmu->version == ARM_SMMU_V1) {
+		cfg->irptndx = atomic_inc_return(&smmu->irptndx);
+		cfg->irptndx %= smmu->num_context_irqs;
+	} else {
+		cfg->irptndx = cfg->cbndx;
+	}
+
+	ACCESS_ONCE(smmu_domain->smmu) = smmu;
+	arm_smmu_init_context_bank(smmu_domain);
+	spin_unlock_irqrestore(&smmu_domain->lock, flags);
+
+	irq = smmu->irqs[smmu->num_global_irqs + cfg->irptndx];
+	ret = request_irq(irq, arm_smmu_context_fault, IRQF_SHARED,
+			  "arm-smmu-context-fault", domain);
+	if (IS_ERR_VALUE(ret)) {
+		dev_err(smmu->dev, "failed to request context IRQ %d (%u)\n",
+			cfg->irptndx, irq);
+		cfg->irptndx = INVALID_IRPTNDX;
+	}
+
+	return 0;
+
+out_unlock:
+	spin_unlock_irqrestore(&smmu_domain->lock, flags);
+	return ret;
+}
+
+static void arm_smmu_destroy_domain_context(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+	void __iomem *cb_base;
+	int irq;
+
+	if (!smmu)
+		return;
+
+	/* Disable the context bank and nuke the TLB before freeing it. */
+	cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
+	writel_relaxed(0, cb_base + ARM_SMMU_CB_SCTLR);
+	arm_smmu_tlb_inv_context(smmu_domain);
+
+	if (cfg->irptndx != INVALID_IRPTNDX) {
+		irq = smmu->irqs[smmu->num_global_irqs + cfg->irptndx];
+		free_irq(irq, domain);
+	}
+
+	__arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
+}
+
+static int arm_smmu_domain_init(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain;
+	pgd_t *pgd;
+
+	/*
+	 * Allocate the domain and initialise some of its data structures.
+	 * We can't really do anything meaningful until we've added a
+	 * master.
+	 */
+	smmu_domain = kzalloc(sizeof(*smmu_domain), GFP_KERNEL);
+	if (!smmu_domain)
+		return -ENOMEM;
+
+	pgd = kcalloc(PTRS_PER_PGD, sizeof(pgd_t), GFP_KERNEL);
+	if (!pgd)
+		goto out_free_domain;
+	smmu_domain->cfg.pgd = pgd;
+
+	spin_lock_init(&smmu_domain->lock);
+	domain->priv = smmu_domain;
+	return 0;
+
+out_free_domain:
+	kfree(smmu_domain);
+	return -ENOMEM;
+}
+
+static void arm_smmu_free_ptes(pmd_t *pmd)
+{
+	pgtable_t table = pmd_pgtable(*pmd);
+
+	__free_page(table);
+}
+
+static void arm_smmu_free_pmds(pud_t *pud)
+{
+	int i;
+	pmd_t *pmd, *pmd_base = pmd_offset(pud, 0);
+
+	pmd = pmd_base;
+	for (i = 0; i < PTRS_PER_PMD; ++i) {
+		if (pmd_none(*pmd))
+			continue;
+
+		arm_smmu_free_ptes(pmd);
+		pmd++;
+	}
+
+	pmd_free(NULL, pmd_base);
+}
+
+static void arm_smmu_free_puds(pgd_t *pgd)
+{
+	int i;
+	pud_t *pud, *pud_base = pud_offset(pgd, 0);
+
+	pud = pud_base;
+	for (i = 0; i < PTRS_PER_PUD; ++i) {
+		if (pud_none(*pud))
+			continue;
+
+		arm_smmu_free_pmds(pud);
+		pud++;
+	}
+
+	pud_free(NULL, pud_base);
+}
+
+static void arm_smmu_free_pgtables(struct arm_smmu_domain *smmu_domain)
+{
+	int i;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+	pgd_t *pgd, *pgd_base = cfg->pgd;
+
+	/*
+	 * Recursively free the page tables for this domain. We don't
+	 * care about speculative TLB filling because the tables should
+	 * not be active in any context bank at this point (SCTLR.M is 0).
+	 */
+	pgd = pgd_base;
+	for (i = 0; i < PTRS_PER_PGD; ++i) {
+		if (pgd_none(*pgd))
+			continue;
+		arm_smmu_free_puds(pgd);
+		pgd++;
+	}
+
+	kfree(pgd_base);
+}
+
+static void arm_smmu_domain_destroy(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+
+	/*
+	 * Free the domain resources. We assume that all devices have
+	 * already been detached.
+	 */
+	arm_smmu_destroy_domain_context(domain);
+	arm_smmu_free_pgtables(smmu_domain);
+	kfree(smmu_domain);
+}
+
+static int arm_smmu_master_configure_smrs(struct arm_smmu_device *smmu,
+					  struct arm_smmu_master_cfg *cfg)
+{
+	int i;
+	struct arm_smmu_smr *smrs;
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+
+	if (!(smmu->features & ARM_SMMU_FEAT_STREAM_MATCH))
+		return 0;
+
+	if (cfg->smrs)
+		return -EEXIST;
+
+	smrs = kmalloc_array(cfg->num_streamids, sizeof(*smrs), GFP_KERNEL);
+	if (!smrs) {
+		dev_err(smmu->dev, "failed to allocate %d SMRs\n",
+			cfg->num_streamids);
+		return -ENOMEM;
+	}
+
+	/* Allocate the SMRs on the SMMU */
+	for (i = 0; i < cfg->num_streamids; ++i) {
+		int idx = __arm_smmu_alloc_bitmap(smmu->smr_map, 0,
+						  smmu->num_mapping_groups);
+		if (IS_ERR_VALUE(idx)) {
+			dev_err(smmu->dev, "failed to allocate free SMR\n");
+			goto err_free_smrs;
+		}
+
+		smrs[i] = (struct arm_smmu_smr) {
+			.idx	= idx,
+			.mask	= 0, /* We don't currently share SMRs */
+			.id	= cfg->streamids[i],
+		};
+	}
+
+	/* It worked! Now, poke the actual hardware */
+	for (i = 0; i < cfg->num_streamids; ++i) {
+		u32 reg = SMR_VALID | smrs[i].id << SMR_ID_SHIFT |
+			  smrs[i].mask << SMR_MASK_SHIFT;
+		writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_SMR(smrs[i].idx));
+	}
+
+	cfg->smrs = smrs;
+	return 0;
+
+err_free_smrs:
+	while (--i >= 0)
+		__arm_smmu_free_bitmap(smmu->smr_map, smrs[i].idx);
+	kfree(smrs);
+	return -ENOSPC;
+}
+
+static void arm_smmu_master_free_smrs(struct arm_smmu_device *smmu,
+				      struct arm_smmu_master_cfg *cfg)
+{
+	int i;
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+	struct arm_smmu_smr *smrs = cfg->smrs;
+
+	if (!smrs)
+		return;
+
+	/* Invalidate the SMRs before freeing back to the allocator */
+	for (i = 0; i < cfg->num_streamids; ++i) {
+		u8 idx = smrs[i].idx;
+
+		writel_relaxed(~SMR_VALID, gr0_base + ARM_SMMU_GR0_SMR(idx));
+		__arm_smmu_free_bitmap(smmu->smr_map, idx);
+	}
+
+	cfg->smrs = NULL;
+	kfree(smrs);
+}
+
+static int arm_smmu_domain_add_master(struct arm_smmu_domain *smmu_domain,
+				      struct arm_smmu_master_cfg *cfg)
+{
+	int i, ret;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+
+	/* Devices in an IOMMU group may already be configured */
+	ret = arm_smmu_master_configure_smrs(smmu, cfg);
+	if (ret)
+		return ret == -EEXIST ? 0 : ret;
+
+	for (i = 0; i < cfg->num_streamids; ++i) {
+		u32 idx, s2cr;
+
+		idx = cfg->smrs ? cfg->smrs[i].idx : cfg->streamids[i];
+		s2cr = S2CR_TYPE_TRANS |
+		       (smmu_domain->cfg.cbndx << S2CR_CBNDX_SHIFT);
+		writel_relaxed(s2cr, gr0_base + ARM_SMMU_GR0_S2CR(idx));
+	}
+
+	return 0;
+}
+
+static void arm_smmu_domain_remove_master(struct arm_smmu_domain *smmu_domain,
+					  struct arm_smmu_master_cfg *cfg)
+{
+	int i;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+
+	/* An IOMMU group is torn down by the first device to be removed */
+	if ((smmu->features & ARM_SMMU_FEAT_STREAM_MATCH) && !cfg->smrs)
+		return;
+
+	/*
+	 * We *must* clear the S2CR first, because freeing the SMR means
+	 * that it can be re-allocated immediately.
+	 */
+	for (i = 0; i < cfg->num_streamids; ++i) {
+		u32 idx = cfg->smrs ? cfg->smrs[i].idx : cfg->streamids[i];
+
+		writel_relaxed(S2CR_TYPE_BYPASS,
+			       gr0_base + ARM_SMMU_GR0_S2CR(idx));
+	}
+
+	arm_smmu_master_free_smrs(smmu, cfg);
+}
+
+static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
+{
+	int ret;
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+	struct arm_smmu_device *smmu, *dom_smmu;
+	struct arm_smmu_master_cfg *cfg;
+
+	smmu = find_smmu_for_device(dev);
+	if (!smmu) {
+		dev_err(dev, "cannot attach to SMMU, is it on the same bus?\n");
+		return -ENXIO;
+	}
+
+	if (dev->archdata.iommu) {
+		dev_err(dev, "already attached to IOMMU domain\n");
+		return -EEXIST;
+	}
+
+	/*
+	 * Sanity check the domain. We don't support domains across
+	 * different SMMUs.
+	 */
+	dom_smmu = ACCESS_ONCE(smmu_domain->smmu);
+	if (!dom_smmu) {
+		/* Now that we have a master, we can finalise the domain */
+		ret = arm_smmu_init_domain_context(domain, smmu);
+		if (IS_ERR_VALUE(ret))
+			return ret;
+
+		dom_smmu = smmu_domain->smmu;
+	}
+
+	if (dom_smmu != smmu) {
+		dev_err(dev,
+			"cannot attach to SMMU %s whilst already attached to domain on SMMU %s\n",
+			dev_name(smmu_domain->smmu->dev), dev_name(smmu->dev));
+		return -EINVAL;
+	}
+
+	/* Looks ok, so add the device to the domain */
+	cfg = find_smmu_master_cfg(dev);
+	if (!cfg)
+		return -ENODEV;
+
+	ret = arm_smmu_domain_add_master(smmu_domain, cfg);
+	if (!ret)
+		dev->archdata.iommu = domain;
+	return ret;
+}
+
+static void arm_smmu_detach_dev(struct iommu_domain *domain, struct device *dev)
+{
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+	struct arm_smmu_master_cfg *cfg;
+
+	cfg = find_smmu_master_cfg(dev);
+	if (!cfg)
+		return;
+
+	dev->archdata.iommu = NULL;
+	arm_smmu_domain_remove_master(smmu_domain, cfg);
+}
+
+static bool arm_smmu_pte_is_contiguous_range(unsigned long addr,
+					     unsigned long end)
+{
+	return !(addr & ~ARM_SMMU_PTE_CONT_MASK) &&
+		(addr + ARM_SMMU_PTE_CONT_SIZE <= end);
+}
+
+static int arm_smmu_alloc_init_pte(struct arm_smmu_device *smmu, pmd_t *pmd,
+				   unsigned long addr, unsigned long end,
+				   unsigned long pfn, int prot, int stage)
+{
+	pte_t *pte, *start;
+	pteval_t pteval = ARM_SMMU_PTE_PAGE | ARM_SMMU_PTE_AF;
+
+	if (pmd_none(*pmd)) {
+		/* Allocate a new set of tables */
+		pgtable_t table = alloc_page(GFP_ATOMIC|__GFP_ZERO);
+
+		if (!table)
+			return -ENOMEM;
+
+		arm_smmu_flush_pgtable(smmu, page_address(table), PAGE_SIZE);
+		pmd_populate(NULL, pmd, table);
+		arm_smmu_flush_pgtable(smmu, pmd, sizeof(*pmd));
+	}
+
+	if (stage == 1) {
+		pteval |= ARM_SMMU_PTE_AP_UNPRIV | ARM_SMMU_PTE_nG;
+		if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
+			pteval |= ARM_SMMU_PTE_AP_RDONLY;
+
+		if (prot & IOMMU_CACHE)
+			pteval |= (MAIR_ATTR_IDX_CACHE <<
+				   ARM_SMMU_PTE_ATTRINDX_SHIFT);
+	} else {
+		pteval |= ARM_SMMU_PTE_HAP_FAULT;
+		if (prot & IOMMU_READ)
+			pteval |= ARM_SMMU_PTE_HAP_READ;
+		if (prot & IOMMU_WRITE)
+			pteval |= ARM_SMMU_PTE_HAP_WRITE;
+		if (prot & IOMMU_CACHE)
+			pteval |= ARM_SMMU_PTE_MEMATTR_OIWB;
+		else
+			pteval |= ARM_SMMU_PTE_MEMATTR_NC;
+	}
+
+	if (prot & IOMMU_NOEXEC)
+		pteval |= ARM_SMMU_PTE_XN;
+
+	/* If no access, create a faulting entry to avoid TLB fills */
+	if (!(prot & (IOMMU_READ | IOMMU_WRITE)))
+		pteval &= ~ARM_SMMU_PTE_PAGE;
+
+	pteval |= ARM_SMMU_PTE_SH_IS;
+	start = pmd_page_vaddr(*pmd) + pte_index(addr);
+	pte = start;
+
+	/*
+	 * Install the page table entries. This is fairly complicated
+	 * since we attempt to make use of the contiguous hint in the
+	 * ptes where possible. The contiguous hint indicates a series
+	 * of ARM_SMMU_PTE_CONT_ENTRIES ptes mapping a physically
+	 * contiguous region with the following constraints:
+	 *
+	 *   - The region start is aligned to ARM_SMMU_PTE_CONT_SIZE
+	 *   - Each pte in the region has the contiguous hint bit set
+	 *
+	 * This complicates unmapping (also handled by this code, when
+	 * neither IOMMU_READ or IOMMU_WRITE are set) because it is
+	 * possible, yet highly unlikely, that a client may unmap only
+	 * part of a contiguous range. This requires clearing of the
+	 * contiguous hint bits in the range before installing the new
+	 * faulting entries.
+	 *
+	 * Note that re-mapping an address range without first unmapping
+	 * it is not supported, so TLB invalidation is not required here
+	 * and is instead performed at unmap and domain-init time.
+	 */
+	do {
+		int i = 1;
+
+		pteval &= ~ARM_SMMU_PTE_CONT;
+
+		if (arm_smmu_pte_is_contiguous_range(addr, end)) {
+			i = ARM_SMMU_PTE_CONT_ENTRIES;
+			pteval |= ARM_SMMU_PTE_CONT;
+		} else if (pte_val(*pte) &
+			   (ARM_SMMU_PTE_CONT | ARM_SMMU_PTE_PAGE)) {
+			int j;
+			pte_t *cont_start;
+			unsigned long idx = pte_index(addr);
+
+			idx &= ~(ARM_SMMU_PTE_CONT_ENTRIES - 1);
+			cont_start = pmd_page_vaddr(*pmd) + idx;
+			for (j = 0; j < ARM_SMMU_PTE_CONT_ENTRIES; ++j)
+				pte_val(*(cont_start + j)) &=
+					~ARM_SMMU_PTE_CONT;
+
+			arm_smmu_flush_pgtable(smmu, cont_start,
+					       sizeof(*pte) *
+					       ARM_SMMU_PTE_CONT_ENTRIES);
+		}
+
+		do {
+			*pte = pfn_pte(pfn, __pgprot(pteval));
+		} while (pte++, pfn++, addr += PAGE_SIZE, --i);
+	} while (addr != end);
+
+	arm_smmu_flush_pgtable(smmu, start, sizeof(*pte) * (pte - start));
+	return 0;
+}
+
+static int arm_smmu_alloc_init_pmd(struct arm_smmu_device *smmu, pud_t *pud,
+				   unsigned long addr, unsigned long end,
+				   phys_addr_t phys, int prot, int stage)
+{
+	int ret;
+	pmd_t *pmd;
+	unsigned long next, pfn = __phys_to_pfn(phys);
+
+#ifndef __PAGETABLE_PMD_FOLDED
+	if (pud_none(*pud)) {
+		pmd = (pmd_t *)get_zeroed_page(GFP_ATOMIC);
+		if (!pmd)
+			return -ENOMEM;
+
+		arm_smmu_flush_pgtable(smmu, pmd, PAGE_SIZE);
+		pud_populate(NULL, pud, pmd);
+		arm_smmu_flush_pgtable(smmu, pud, sizeof(*pud));
+
+		pmd += pmd_index(addr);
+	} else
+#endif
+		pmd = pmd_offset(pud, addr);
+
+	do {
+		next = pmd_addr_end(addr, end);
+		ret = arm_smmu_alloc_init_pte(smmu, pmd, addr, next, pfn,
+					      prot, stage);
+		phys += next - addr;
+		pfn = __phys_to_pfn(phys);
+	} while (pmd++, addr = next, addr < end);
+
+	return ret;
+}
+
+static int arm_smmu_alloc_init_pud(struct arm_smmu_device *smmu, pgd_t *pgd,
+				   unsigned long addr, unsigned long end,
+				   phys_addr_t phys, int prot, int stage)
+{
+	int ret = 0;
+	pud_t *pud;
+	unsigned long next;
+
+#ifndef __PAGETABLE_PUD_FOLDED
+	if (pgd_none(*pgd)) {
+		pud = (pud_t *)get_zeroed_page(GFP_ATOMIC);
+		if (!pud)
+			return -ENOMEM;
+
+		arm_smmu_flush_pgtable(smmu, pud, PAGE_SIZE);
+		pgd_populate(NULL, pgd, pud);
+		arm_smmu_flush_pgtable(smmu, pgd, sizeof(*pgd));
+
+		pud += pud_index(addr);
+	} else
+#endif
+		pud = pud_offset(pgd, addr);
+
+	do {
+		next = pud_addr_end(addr, end);
+		ret = arm_smmu_alloc_init_pmd(smmu, pud, addr, next, phys,
+					      prot, stage);
+		phys += next - addr;
+	} while (pud++, addr = next, addr < end);
+
+	return ret;
+}
+
+static int arm_smmu_handle_mapping(struct arm_smmu_domain *smmu_domain,
+				   unsigned long iova, phys_addr_t paddr,
+				   size_t size, int prot)
+{
+	int ret, stage;
+	unsigned long end;
+	phys_addr_t input_mask, output_mask;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+	pgd_t *pgd = cfg->pgd;
+	unsigned long flags;
+
+	if (cfg->cbar == CBAR_TYPE_S2_TRANS) {
+		stage = 2;
+		input_mask = (1ULL << smmu->s2_input_size) - 1;
+		output_mask = (1ULL << smmu->s2_output_size) - 1;
+	} else {
+		stage = 1;
+		input_mask = (1ULL << smmu->s1_input_size) - 1;
+		output_mask = (1ULL << smmu->s1_output_size) - 1;
+	}
+
+	if (!pgd)
+		return -EINVAL;
+
+	if (size & ~PAGE_MASK)
+		return -EINVAL;
+
+	if ((phys_addr_t)iova & ~input_mask)
+		return -ERANGE;
+
+	if (paddr & ~output_mask)
+		return -ERANGE;
+
+	spin_lock_irqsave(&smmu_domain->lock, flags);
+	pgd += pgd_index(iova);
+	end = iova + size;
+	do {
+		unsigned long next = pgd_addr_end(iova, end);
+
+		ret = arm_smmu_alloc_init_pud(smmu, pgd, iova, next, paddr,
+					      prot, stage);
+		if (ret)
+			goto out_unlock;
+
+		paddr += next - iova;
+		iova = next;
+	} while (pgd++, iova != end);
+
+out_unlock:
+	spin_unlock_irqrestore(&smmu_domain->lock, flags);
+
+	return ret;
+}
+
+static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova,
+			phys_addr_t paddr, size_t size, int prot)
+{
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+
+	if (!smmu_domain)
+		return -ENODEV;
+
+	return arm_smmu_handle_mapping(smmu_domain, iova, paddr, size, prot);
+}
+
+static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,
+			     size_t size)
+{
+	int ret;
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+
+	ret = arm_smmu_handle_mapping(smmu_domain, iova, 0, size, 0);
+	arm_smmu_tlb_inv_context(smmu_domain);
+	return ret ? 0 : size;
+}
+
+static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
+					 dma_addr_t iova)
+{
+	pgd_t *pgdp, pgd;
+	pud_t pud;
+	pmd_t pmd;
+	pte_t pte;
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+
+	pgdp = cfg->pgd;
+	if (!pgdp)
+		return 0;
+
+	pgd = *(pgdp + pgd_index(iova));
+	if (pgd_none(pgd))
+		return 0;
+
+	pud = *pud_offset(&pgd, iova);
+	if (pud_none(pud))
+		return 0;
+
+	pmd = *pmd_offset(&pud, iova);
+	if (pmd_none(pmd))
+		return 0;
+
+	pte = *(pmd_page_vaddr(pmd) + pte_index(iova));
+	if (pte_none(pte))
+		return 0;
+
+	return __pfn_to_phys(pte_pfn(pte)) | (iova & ~PAGE_MASK);
+}
+
+static bool arm_smmu_capable(enum iommu_cap cap)
+{
+	switch (cap) {
+	case IOMMU_CAP_CACHE_COHERENCY:
+		/*
+		 * Return true here as the SMMU can always send out coherent
+		 * requests.
+		 */
+		return true;
+	case IOMMU_CAP_INTR_REMAP:
+		return true; /* MSIs are just memory writes */
+	case IOMMU_CAP_NOEXEC:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static int __arm_smmu_get_pci_sid(struct pci_dev *pdev, u16 alias, void *data)
+{
+	*((u16 *)data) = alias;
+	return 0; /* Continue walking */
+}
+
+static void __arm_smmu_release_pci_iommudata(void *data)
+{
+	kfree(data);
+}
+
+static int arm_smmu_add_device(struct device *dev)
+{
+	struct arm_smmu_device *smmu;
+	struct arm_smmu_master_cfg *cfg;
+	struct iommu_group *group;
+	void (*releasefn)(void *) = NULL;
+	int ret;
+
+	smmu = find_smmu_for_device(dev);
+	if (!smmu)
+		return -ENODEV;
+
+	group = iommu_group_alloc();
+	if (IS_ERR(group)) {
+		dev_err(dev, "Failed to allocate IOMMU group\n");
+		return PTR_ERR(group);
+	}
+
+	if (dev_is_pci(dev)) {
+		struct pci_dev *pdev = to_pci_dev(dev);
+
+		cfg = kzalloc(sizeof(*cfg), GFP_KERNEL);
+		if (!cfg) {
+			ret = -ENOMEM;
+			goto out_put_group;
+		}
+
+		cfg->num_streamids = 1;
+		/*
+		 * Assume Stream ID == Requester ID for now.
+		 * We need a way to describe the ID mappings in FDT.
+		 */
+		pci_for_each_dma_alias(pdev, __arm_smmu_get_pci_sid,
+				       &cfg->streamids[0]);
+		releasefn = __arm_smmu_release_pci_iommudata;
+	} else {
+		struct arm_smmu_master *master;
+
+		master = find_smmu_master(smmu, dev->of_node);
+		if (!master) {
+			ret = -ENODEV;
+			goto out_put_group;
+		}
+
+		cfg = &master->cfg;
+	}
+
+	iommu_group_set_iommudata(group, cfg, releasefn);
+	ret = iommu_group_add_device(group, dev);
+
+out_put_group:
+	iommu_group_put(group);
+	return ret;
+}
+
+static void arm_smmu_remove_device(struct device *dev)
+{
+	iommu_group_remove_device(dev);
+}
+
+static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
+				    enum iommu_attr attr, void *data)
+{
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+
+	switch (attr) {
+	case DOMAIN_ATTR_NESTING:
+		*(int *)data = (smmu_domain->stage == ARM_SMMU_DOMAIN_NESTED);
+		return 0;
+	default:
+		return -ENODEV;
+	}
+}
+
+static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
+				    enum iommu_attr attr, void *data)
+{
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+
+	switch (attr) {
+	case DOMAIN_ATTR_NESTING:
+		if (smmu_domain->smmu)
+			return -EPERM;
+		if (*(int *)data)
+			smmu_domain->stage = ARM_SMMU_DOMAIN_NESTED;
+		else
+			smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
+
+		return 0;
+	default:
+		return -ENODEV;
+	}
+}
+
+static const struct iommu_ops arm_smmu_ops = {
+	.capable		= arm_smmu_capable,
+	.domain_init		= arm_smmu_domain_init,
+	.domain_destroy		= arm_smmu_domain_destroy,
+	.attach_dev		= arm_smmu_attach_dev,
+	.detach_dev		= arm_smmu_detach_dev,
+	.map			= arm_smmu_map,
+	.unmap			= arm_smmu_unmap,
+	.map_sg			= default_iommu_map_sg,
+	.iova_to_phys		= arm_smmu_iova_to_phys,
+	.add_device		= arm_smmu_add_device,
+	.remove_device		= arm_smmu_remove_device,
+	.domain_get_attr	= arm_smmu_domain_get_attr,
+	.domain_set_attr	= arm_smmu_domain_set_attr,
+	.pgsize_bitmap		= (SECTION_SIZE |
+				   ARM_SMMU_PTE_CONT_SIZE |
+				   PAGE_SIZE),
+};
+
+static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
+{
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+	void __iomem *cb_base;
+	int i = 0;
+	u32 reg;
+
+	/* clear global FSR */
+	reg = readl_relaxed(ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sGFSR);
+	writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sGFSR);
+
+	/* Mark all SMRn as invalid and all S2CRn as bypass */
+	for (i = 0; i < smmu->num_mapping_groups; ++i) {
+		writel_relaxed(0, gr0_base + ARM_SMMU_GR0_SMR(i));
+		writel_relaxed(S2CR_TYPE_BYPASS,
+			gr0_base + ARM_SMMU_GR0_S2CR(i));
+	}
+
+	/* Make sure all context banks are disabled and clear CB_FSR  */
+	for (i = 0; i < smmu->num_context_banks; ++i) {
+		cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, i);
+		writel_relaxed(0, cb_base + ARM_SMMU_CB_SCTLR);
+		writel_relaxed(FSR_FAULT, cb_base + ARM_SMMU_CB_FSR);
+	}
+
+	/* Invalidate the TLB, just in case */
+	writel_relaxed(0, gr0_base + ARM_SMMU_GR0_STLBIALL);
+	writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLH);
+	writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLNSNH);
+
+	reg = readl_relaxed(ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
+
+	/* Enable fault reporting */
+	reg |= (sCR0_GFRE | sCR0_GFIE | sCR0_GCFGFRE | sCR0_GCFGFIE);
+
+	/* Disable TLB broadcasting. */
+	reg |= (sCR0_VMIDPNE | sCR0_PTM);
+
+	/* Enable client access, but bypass when no mapping is found */
+	reg &= ~(sCR0_CLIENTPD | sCR0_USFCFG);
+
+	/* Disable forced broadcasting */
+	reg &= ~sCR0_FB;
+
+	/* Don't upgrade barriers */
+	reg &= ~(sCR0_BSU_MASK << sCR0_BSU_SHIFT);
+
+	/* Push the button */
+	arm_smmu_tlb_sync(smmu);
+	writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
+}
+
+static int arm_smmu_id_size_to_bits(int size)
+{
+	switch (size) {
+	case 0:
+		return 32;
+	case 1:
+		return 36;
+	case 2:
+		return 40;
+	case 3:
+		return 42;
+	case 4:
+		return 44;
+	case 5:
+	default:
+		return 48;
+	}
+}
+
+static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
+{
+	unsigned long size;
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+	u32 id;
+
+	dev_notice(smmu->dev, "probing hardware configuration...\n");
+	dev_notice(smmu->dev, "SMMUv%d with:\n", smmu->version);
+
+	/* ID0 */
+	id = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID0);
+#ifndef CONFIG_64BIT
+	if (((id >> ID0_PTFS_SHIFT) & ID0_PTFS_MASK) == ID0_PTFS_V8_ONLY) {
+		dev_err(smmu->dev, "\tno v7 descriptor support!\n");
+		return -ENODEV;
+	}
+#endif
+
+	/* Restrict available stages based on module parameter */
+	if (force_stage == 1)
+		id &= ~(ID0_S2TS | ID0_NTS);
+	else if (force_stage == 2)
+		id &= ~(ID0_S1TS | ID0_NTS);
+
+	if (id & ID0_S1TS) {
+		smmu->features |= ARM_SMMU_FEAT_TRANS_S1;
+		dev_notice(smmu->dev, "\tstage 1 translation\n");
+	}
+
+	if (id & ID0_S2TS) {
+		smmu->features |= ARM_SMMU_FEAT_TRANS_S2;
+		dev_notice(smmu->dev, "\tstage 2 translation\n");
+	}
+
+	if (id & ID0_NTS) {
+		smmu->features |= ARM_SMMU_FEAT_TRANS_NESTED;
+		dev_notice(smmu->dev, "\tnested translation\n");
+	}
+
+	if (!(smmu->features &
+		(ARM_SMMU_FEAT_TRANS_S1 | ARM_SMMU_FEAT_TRANS_S2))) {
+		dev_err(smmu->dev, "\tno translation support!\n");
+		return -ENODEV;
+	}
+
+	if (id & ID0_CTTW) {
+		smmu->features |= ARM_SMMU_FEAT_COHERENT_WALK;
+		dev_notice(smmu->dev, "\tcoherent table walk\n");
+	}
+
+	if (id & ID0_SMS) {
+		u32 smr, sid, mask;
+
+		smmu->features |= ARM_SMMU_FEAT_STREAM_MATCH;
+		smmu->num_mapping_groups = (id >> ID0_NUMSMRG_SHIFT) &
+					   ID0_NUMSMRG_MASK;
+		if (smmu->num_mapping_groups == 0) {
+			dev_err(smmu->dev,
+				"stream-matching supported, but no SMRs present!\n");
+			return -ENODEV;
+		}
+
+		smr = SMR_MASK_MASK << SMR_MASK_SHIFT;
+		smr |= (SMR_ID_MASK << SMR_ID_SHIFT);
+		writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
+		smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
+
+		mask = (smr >> SMR_MASK_SHIFT) & SMR_MASK_MASK;
+		sid = (smr >> SMR_ID_SHIFT) & SMR_ID_MASK;
+		if ((mask & sid) != sid) {
+			dev_err(smmu->dev,
+				"SMR mask bits (0x%x) insufficient for ID field (0x%x)\n",
+				mask, sid);
+			return -ENODEV;
+		}
+
+		dev_notice(smmu->dev,
+			   "\tstream matching with %u register groups, mask 0x%x",
+			   smmu->num_mapping_groups, mask);
+	} else {
+		smmu->num_mapping_groups = (id >> ID0_NUMSIDB_SHIFT) &
+					   ID0_NUMSIDB_MASK;
+	}
+
+	/* ID1 */
+	id = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID1);
+	smmu->pgshift = (id & ID1_PAGESIZE) ? 16 : 12;
+
+	/* Check for size mismatch of SMMU address space from mapped region */
+	size = 1 <<
+		(((id >> ID1_NUMPAGENDXB_SHIFT) & ID1_NUMPAGENDXB_MASK) + 1);
+	size *= 2 << smmu->pgshift;
+	if (smmu->size != size)
+		dev_warn(smmu->dev,
+			"SMMU address space size (0x%lx) differs from mapped region size (0x%lx)!\n",
+			size, smmu->size);
+
+	smmu->num_s2_context_banks = (id >> ID1_NUMS2CB_SHIFT) &
+				      ID1_NUMS2CB_MASK;
+	smmu->num_context_banks = (id >> ID1_NUMCB_SHIFT) & ID1_NUMCB_MASK;
+	if (smmu->num_s2_context_banks > smmu->num_context_banks) {
+		dev_err(smmu->dev, "impossible number of S2 context banks!\n");
+		return -ENODEV;
+	}
+	dev_notice(smmu->dev, "\t%u context banks (%u stage-2 only)\n",
+		   smmu->num_context_banks, smmu->num_s2_context_banks);
+
+	/* ID2 */
+	id = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID2);
+	size = arm_smmu_id_size_to_bits((id >> ID2_IAS_SHIFT) & ID2_IAS_MASK);
+	smmu->s1_output_size = min_t(unsigned long, PHYS_MASK_SHIFT, size);
+
+	/* Stage-2 input size limited due to pgd allocation (PTRS_PER_PGD) */
+#ifdef CONFIG_64BIT
+	smmu->s2_input_size = min_t(unsigned long, VA_BITS, size);
+#else
+	smmu->s2_input_size = min(32UL, size);
+#endif
+
+	/* The stage-2 output mask is also applied for bypass */
+	size = arm_smmu_id_size_to_bits((id >> ID2_OAS_SHIFT) & ID2_OAS_MASK);
+	smmu->s2_output_size = min_t(unsigned long, PHYS_MASK_SHIFT, size);
+
+	if (smmu->version == ARM_SMMU_V1) {
+		smmu->s1_input_size = 32;
+	} else {
+#ifdef CONFIG_64BIT
+		size = (id >> ID2_UBS_SHIFT) & ID2_UBS_MASK;
+		size = min(VA_BITS, arm_smmu_id_size_to_bits(size));
+#else
+		size = 32;
+#endif
+		smmu->s1_input_size = size;
+
+		if ((PAGE_SIZE == SZ_4K && !(id & ID2_PTFS_4K)) ||
+		    (PAGE_SIZE == SZ_64K && !(id & ID2_PTFS_64K)) ||
+		    (PAGE_SIZE != SZ_4K && PAGE_SIZE != SZ_64K)) {
+			dev_err(smmu->dev, "CPU page size 0x%lx unsupported\n",
+				PAGE_SIZE);
+			return -ENODEV;
+		}
+	}
+
+	if (smmu->features & ARM_SMMU_FEAT_TRANS_S1)
+		dev_notice(smmu->dev, "\tStage-1: %lu-bit VA -> %lu-bit IPA\n",
+			   smmu->s1_input_size, smmu->s1_output_size);
+
+	if (smmu->features & ARM_SMMU_FEAT_TRANS_S2)
+		dev_notice(smmu->dev, "\tStage-2: %lu-bit IPA -> %lu-bit PA\n",
+			   smmu->s2_input_size, smmu->s2_output_size);
+
+	return 0;
+}
+
+static const struct of_device_id arm_smmu_of_match[] = {
+	{ .compatible = "arm,smmu-v1", .data = (void *)ARM_SMMU_V1 },
+	{ .compatible = "arm,smmu-v2", .data = (void *)ARM_SMMU_V2 },
+	{ .compatible = "arm,mmu-400", .data = (void *)ARM_SMMU_V1 },
+	{ .compatible = "arm,mmu-401", .data = (void *)ARM_SMMU_V1 },
+	{ .compatible = "arm,mmu-500", .data = (void *)ARM_SMMU_V2 },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
+
+static int arm_smmu_device_dt_probe(struct platform_device *pdev)
+{
+	const struct of_device_id *of_id;
+	struct resource *res;
+	struct arm_smmu_device *smmu;
+	struct device *dev = &pdev->dev;
+	struct rb_node *node;
+	struct of_phandle_args masterspec;
+	int num_irqs, i, err;
+
+	smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
+	if (!smmu) {
+		dev_err(dev, "failed to allocate arm_smmu_device\n");
+		return -ENOMEM;
+	}
+	smmu->dev = dev;
+
+	of_id = of_match_node(arm_smmu_of_match, dev->of_node);
+	smmu->version = (enum arm_smmu_arch_version)of_id->data;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	smmu->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(smmu->base))
+		return PTR_ERR(smmu->base);
+	smmu->size = resource_size(res);
+
+	if (of_property_read_u32(dev->of_node, "#global-interrupts",
+				 &smmu->num_global_irqs)) {
+		dev_err(dev, "missing #global-interrupts property\n");
+		return -ENODEV;
+	}
+
+	num_irqs = 0;
+	while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, num_irqs))) {
+		num_irqs++;
+		if (num_irqs > smmu->num_global_irqs)
+			smmu->num_context_irqs++;
+	}
+
+	if (!smmu->num_context_irqs) {
+		dev_err(dev, "found %d interrupts but expected at least %d\n",
+			num_irqs, smmu->num_global_irqs + 1);
+		return -ENODEV;
+	}
+
+	smmu->irqs = devm_kzalloc(dev, sizeof(*smmu->irqs) * num_irqs,
+				  GFP_KERNEL);
+	if (!smmu->irqs) {
+		dev_err(dev, "failed to allocate %d irqs\n", num_irqs);
+		return -ENOMEM;
+	}
+
+	for (i = 0; i < num_irqs; ++i) {
+		int irq = platform_get_irq(pdev, i);
+
+		if (irq < 0) {
+			dev_err(dev, "failed to get irq index %d\n", i);
+			return -ENODEV;
+		}
+		smmu->irqs[i] = irq;
+	}
+
+	err = arm_smmu_device_cfg_probe(smmu);
+	if (err)
+		return err;
+
+	i = 0;
+	smmu->masters = RB_ROOT;
+	while (!of_parse_phandle_with_args(dev->of_node, "mmu-masters",
+					   "#stream-id-cells", i,
+					   &masterspec)) {
+		err = register_smmu_master(smmu, dev, &masterspec);
+		if (err) {
+			dev_err(dev, "failed to add master %s\n",
+				masterspec.np->name);
+			goto out_put_masters;
+		}
+
+		i++;
+	}
+	dev_notice(dev, "registered %d master devices\n", i);
+
+	parse_driver_options(smmu);
+
+	if (smmu->version > ARM_SMMU_V1 &&
+	    smmu->num_context_banks != smmu->num_context_irqs) {
+		dev_err(dev,
+			"found only %d context interrupt(s) but %d required\n",
+			smmu->num_context_irqs, smmu->num_context_banks);
+		err = -ENODEV;
+		goto out_put_masters;
+	}
+
+	for (i = 0; i < smmu->num_global_irqs; ++i) {
+		err = request_irq(smmu->irqs[i],
+				  arm_smmu_global_fault,
+				  IRQF_SHARED,
+				  "arm-smmu global fault",
+				  smmu);
+		if (err) {
+			dev_err(dev, "failed to request global IRQ %d (%u)\n",
+				i, smmu->irqs[i]);
+			goto out_free_irqs;
+		}
+	}
+
+	INIT_LIST_HEAD(&smmu->list);
+	spin_lock(&arm_smmu_devices_lock);
+	list_add(&smmu->list, &arm_smmu_devices);
+	spin_unlock(&arm_smmu_devices_lock);
+
+	arm_smmu_device_reset(smmu);
+	return 0;
+
+out_free_irqs:
+	while (i--)
+		free_irq(smmu->irqs[i], smmu);
+
+out_put_masters:
+	for (node = rb_first(&smmu->masters); node; node = rb_next(node)) {
+		struct arm_smmu_master *master
+			= container_of(node, struct arm_smmu_master, node);
+		of_node_put(master->of_node);
+	}
+
+	return err;
+}
+
+static int arm_smmu_device_remove(struct platform_device *pdev)
+{
+	int i;
+	struct device *dev = &pdev->dev;
+	struct arm_smmu_device *curr, *smmu = NULL;
+	struct rb_node *node;
+
+	spin_lock(&arm_smmu_devices_lock);
+	list_for_each_entry(curr, &arm_smmu_devices, list) {
+		if (curr->dev == dev) {
+			smmu = curr;
+			list_del(&smmu->list);
+			break;
+		}
+	}
+	spin_unlock(&arm_smmu_devices_lock);
+
+	if (!smmu)
+		return -ENODEV;
+
+	for (node = rb_first(&smmu->masters); node; node = rb_next(node)) {
+		struct arm_smmu_master *master
+			= container_of(node, struct arm_smmu_master, node);
+		of_node_put(master->of_node);
+	}
+
+	if (!bitmap_empty(smmu->context_map, ARM_SMMU_MAX_CBS))
+		dev_err(dev, "removing device with active domains!\n");
+
+	for (i = 0; i < smmu->num_global_irqs; ++i)
+		free_irq(smmu->irqs[i], smmu);
+
+	/* Turn the thing off */
+	writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
+	return 0;
+}
+
+static struct platform_driver arm_smmu_driver = {
+	.driver	= {
+		.name		= "arm-smmu",
+		.of_match_table	= of_match_ptr(arm_smmu_of_match),
+	},
+	.probe	= arm_smmu_device_dt_probe,
+	.remove	= arm_smmu_device_remove,
+};
+
+static int __init arm_smmu_init(void)
+{
+	struct device_node *np;
+	int ret;
+
+	/*
+	 * Play nice with systems that don't have an ARM SMMU by checking that
+	 * an ARM SMMU exists in the system before proceeding with the driver
+	 * and IOMMU bus operation registration.
+	 */
+	np = of_find_matching_node(NULL, arm_smmu_of_match);
+	if (!np)
+		return 0;
+
+	of_node_put(np);
+
+	ret = platform_driver_register(&arm_smmu_driver);
+	if (ret)
+		return ret;
+
+	/* Oh, for a proper bus abstraction */
+	if (!iommu_present(&platform_bus_type))
+		bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
+
+#ifdef CONFIG_ARM_AMBA
+	if (!iommu_present(&amba_bustype))
+		bus_set_iommu(&amba_bustype, &arm_smmu_ops);
+#endif
+
+#ifdef CONFIG_PCI
+	if (!iommu_present(&pci_bus_type))
+		bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
+#endif
+
+	return 0;
+}
+
+static void __exit arm_smmu_exit(void)
+{
+	return platform_driver_unregister(&arm_smmu_driver);
+}
+
+subsys_initcall(arm_smmu_init);
+module_exit(arm_smmu_exit);
+
+MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
+MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
+MODULE_LICENSE("GPL v2");
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yRE-0004xz-Ny; Tue, 16 Dec 2014 20:09:44 +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 1Y0yRD-0004w0-Af
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:43 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	0D/FB-25714-68190945; Tue, 16 Dec 2014 20:09:42 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418760580!10358423!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2804 invoked from network); 16 Dec 2014 20:09:40 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:40 -0000
Received: by mail-wi0-f169.google.com with SMTP id r20so14837980wiv.2
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=tt8da0oBo4GLxBOmU9YJnQWfQ9lTtcOZFjbUTVTr1Ro=;
	b=VN2ONlmA+5bl2gsiVlIaNNEIVRqRHFnDwZku1StA5HRYc7yLyZCHBj3tf3ziOGx1c2
	JLcYuR7LprahaDEPO62o4kVUuaErksB6G+nMk4wKBg6n6w+fb1X8fMPkUNscHVumFJho
	/ZyrQ8N8v30yLKnYDCtknhugMluAslyPySebRmeGi9ote8n9p28714MOrdYo7bEefI3v
	uedAmEr6ag8vmDGBK11A+OzLHfcmf+Komu3v1WHKrOXQplT8dDJ1CAYlQHch8xQZSjf6
	F7e29IqVm4XMv4854mBUUejSEUYjFJsSZIrTuvMg3zcQfYNYIPv62d3lArUwfN5P5MCL
	DrZg==
X-Gm-Message-State: ALoCoQl90RPcoq9iSkG155XrbgQ0QyAHKXMvTG8IHFoGa+7+seQFB3pUMPKkISuSZfZi/++6Z4Ko
X-Received: by 10.180.218.133 with SMTP id pg5mr7753819wic.70.1418760579316;
	Tue, 16 Dec 2014 12:09:39 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.37
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:38 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:54 +0000
Message-Id: <1418760534-18163-14-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 13/13] xen/iommu: smmu: Add Xen specific
	code to be able to use the 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

The main goal is to modify as little the Linux code to be able to port
easily new feature added in Linux repo for the driver.

To achieve that we:
    - Add helpers to Linux function not implemented on Xen
    - Add callbacks used by Xen to do our own stuff and call Linux ones
    - Only modify when required the code which comes from Linux. If so a
    comment has been added with /* Xen: ... */ explaining why it's
    necessary.

The support for PCI has been commented because it's not yet supported by
Xen ARM and therefore won't compile.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/drivers/passthrough/arm/Makefile |   1 +
 xen/drivers/passthrough/arm/smmu.c   | 668 +++++++++++++++++++++++++++++++----
 2 files changed, 602 insertions(+), 67 deletions(-)

diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile
index 0484b79..f4cd26e 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1 +1,2 @@
 obj-y += iommu.o
+obj-y += smmu.o
diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
index 8a6514f..3cf1773 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -18,6 +18,13 @@
  *
  * Author: Will Deacon <will.deacon@arm.com>
  *
+ * Based on Linux drivers/iommu/arm-smmu.c
+ *	=> commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3
+ *
+ * Xen modification:
+ * Julien Grall <julien.grall@linaro.org>
+ * Copyright (C) 2014 Linaro Limited.
+ *
  * This driver currently supports:
  *	- SMMUv1 and v2 implementations
  *	- Stream-matching and stream-indexing
@@ -28,26 +35,154 @@
  *	- Context fault reporting
  */
 
-#define pr_fmt(fmt) "arm-smmu: " fmt
 
-#include <linux/delay.h>
-#include <linux/dma-mapping.h>
-#include <linux/err.h>
-#include <linux/interrupt.h>
-#include <linux/io.h>
-#include <linux/iommu.h>
-#include <linux/mm.h>
-#include <linux/module.h>
-#include <linux/of.h>
-#include <linux/pci.h>
-#include <linux/platform_device.h>
-#include <linux/slab.h>
-#include <linux/spinlock.h>
-#include <linux/bitops.h>
+#include <xen/config.h>
+#include <xen/delay.h>
+#include <xen/device.h>
+#include <xen/errno.h>
+#include <xen/err.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/list.h>
+#include <xen/mm.h>
+#include <xen/vmap.h>
+#include <xen/rbtree.h>
+#include <xen/sched.h>
+#include <xen/sizes.h>
+#include <asm/atomic.h>
+#include <asm/io.h>
+#include <asm/platform.h>
+
+/* Xen: The below defines are redefined within the file. Undef it */
+#undef SCTLR_AFE
+#undef SCTLR_TRE
+#undef SCTLR_M
+#undef TTBCR_EAE
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource
+{
+	u64 addr;
+	u64 size;
+	unsigned int type;
+};
+
+#define resource_size(res) (res)->size;
+
+#define platform_device dt_device_node
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+					      unsigned int type,
+					      unsigned int num)
+{
+	/*
+	 * The resource is only used between 2 calls of platform_get_resource.
+	 * It's quite ugly but it's avoid to add too much code in the part
+	 * imported from Linux
+	 */
+	static struct resource res;
+	int ret = 0;
+
+	res.type = type;
+
+	switch (type) {
+	case IORESOURCE_MEM:
+		ret = dt_device_get_address(pdev, num, &res.addr, &res.size);
+
+		return ((ret) ? NULL : &res);
+
+	case IORESOURCE_IRQ:
+		ret = platform_get_irq(pdev, num);
+		if (ret < 0)
+			return NULL;
+
+		res.addr = ret;
+		res.size = 1;
+
+		return &res;
+
+	default:
+		return NULL;
+	}
+}
+
+/* Alias to Xen IRQ functions */
+#define request_irq(irq, func, flags, name, dev) request_irq(irq, flags, func, name, dev)
+#define free_irq release_irq
+
+/*
+ * Device logger functions
+ * TODO: Handle PCI
+ */
+#define dev_print(dev, lvl, fmt, ...)						\
+	 printk(lvl "smmu: %s: " fmt, dt_node_full_name(dev_to_dt(dev)), ## __VA_ARGS__)
+
+#define dev_dbg(dev, fmt, ...) dev_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__)
+#define dev_notice(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__)
+#define dev_warn(dev, fmt, ...) dev_print(dev, XENLOG_WARNING, fmt, ## __VA_ARGS__)
+#define dev_err(dev, fmt, ...) dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
+
+#define dev_err_ratelimited(dev, fmt, ...)					\
+	 dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
 
-#include <linux/amba/bus.h>
+#define dev_name(dev) dt_node_full_name(dev_to_dt(dev))
 
-#include <asm/pgalloc.h>
+/* Alias to Xen allocation helpers */
+#define kfree xfree
+#define kmalloc(size, flags)		_xmalloc(size, sizeof(void *))
+#define kzalloc(size, flags)		_xzalloc(size, sizeof(void *))
+#define devm_kzalloc(dev, size, flags)	_xzalloc(size, sizeof(void *))
+#define kmalloc_array(size, n, flags)	_xmalloc_array(size, sizeof(void *), n)
+
+static void __iomem *devm_ioremap_resource(struct device *dev,
+					   struct resource *res)
+{
+	void __iomem *ptr;
+
+	if (!res || res->type != IORESOURCE_MEM) {
+		dev_err(dev, "Invalid resource\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	ptr = ioremap_nocache(res->addr, res->size);
+	if (!ptr) {
+		dev_err(dev,
+			"ioremap failed (addr 0x%"PRIx64" size 0x%"PRIx64")\n",
+			res->addr, res->size);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	return ptr;
+}
+
+/* Xen doesn't handle IOMMU fault */
+#define report_iommu_fault(...)	1
+
+#define IOMMU_FAULT_READ	0
+#define IOMMU_FAULT_WRITE	1
+
+/* Xen: misc */
+#define PHYS_MASK_SHIFT		PADDR_BITS
+
+#ifdef CONFIG_ARM_64
+# define CONFIG_64BIT
+#endif
+
+#define VA_BITS		0	/* Only used for configuring stage-1 input size */
+
+/***** Start of SMMU definitions *****/
 
 /* Maximum number of stream IDs assigned to a single device */
 #define MAX_MASTER_STREAMIDS		MAX_PHANDLE_ARGS
@@ -330,10 +465,14 @@
 
 #define FSYNR0_WNR			(1 << 4)
 
-static int force_stage;
-module_param_named(force_stage, force_stage, int, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(force_stage,
-	"Force SMMU mappings to be installed at a particular stage of translation. A value of '1' or '2' forces the corresponding stage. All other values are ignored (i.e. no stage is forced). Note that selecting a specific stage will disable support for nested translation.");
+/* Force SMMU mapping to be installed at a particular stage of translation.
+ * A value of '1' or '2' forces the corresponding state. All other values
+ * are ignored (i.e no stage is forced). Note that selecting a specific stage
+ * will disable support for nested translation.
+ *
+ * Xen is only supported stage-2 translation, so force the value to 2.
+ */
+static const int force_stage = 2;
 
 enum arm_smmu_arch_version {
 	ARM_SMMU_V1 = 1,
@@ -406,7 +545,9 @@ struct arm_smmu_cfg {
 	u8				cbndx;
 	u8				irptndx;
 	u32				cbar;
-	pgd_t				*pgd;
+
+	/* Xen: Domain associated to this configuration */
+	struct domain			*domain;
 };
 #define INVALID_IRPTNDX			0xff
 
@@ -426,6 +567,90 @@ struct arm_smmu_domain {
 	spinlock_t			lock;
 };
 
+/* Xen: Dummy iommu_domain */
+struct iommu_domain
+{
+	struct arm_smmu_domain		*priv;
+
+	/* Used to link domain contexts for a same domain */
+	struct list_head		list;
+};
+
+/* Xen: Describes informations required for a Xen domain */
+struct arm_smmu_xen_domain {
+	spinlock_t			lock;
+	/* List of context (i.e iommu_domain) associated to this domain */
+	struct list_head		contexts;
+};
+
+/* Xen: Information about each device stored in dev->archdata.iommu */
+struct arm_smmu_xen_device {
+	struct iommu_domain *domain;
+	struct iommu_group *group;
+};
+
+#define dev_archdata(dev) ((struct arm_smmu_xen_device *)dev->archdata.iommu)
+#define dev_iommu_domain(dev) (dev_archdata(dev)->domain)
+#define dev_iommu_group(dev) (dev_archdata(dev)->group)
+
+/* Xen: Dummy iommu_group */
+struct iommu_group
+{
+	struct arm_smmu_master_cfg *cfg;
+
+	atomic_t ref;
+};
+
+static struct iommu_group *iommu_group_alloc(void)
+{
+	struct iommu_group *group = xzalloc(struct iommu_group);
+
+	if (!group)
+		return ERR_PTR(-ENOMEM);
+
+	atomic_set(&group->ref, 1);
+
+	return group;
+}
+
+static void iommu_group_put(struct iommu_group *group)
+{
+	if (atomic_dec_and_test(&group->ref))
+		xfree(group);
+}
+
+static void iommu_group_set_iommudata(struct iommu_group *group,
+				      struct arm_smmu_master_cfg *cfg,
+				      void (*releasefn)(void *))
+{
+	/* TODO: Store the releasefn for the PCI */
+	ASSERT(releasefn == NULL);
+
+	group->cfg = cfg;
+}
+
+static int iommu_group_add_device(struct iommu_group *group,
+				  struct device *dev)
+{
+	dev_iommu_group(dev) = group;
+
+	atomic_inc(&group->ref);
+
+	return 0;
+}
+
+static struct iommu_group *iommu_group_get(struct device *dev)
+{
+	struct iommu_group *group = dev_iommu_group(dev);
+
+	if (group)
+		atomic_inc(&group->ref);
+
+	return group;
+}
+
+#define iommu_group_get_iommudata(group) (group)->cfg
+
 static DEFINE_SPINLOCK(arm_smmu_devices_lock);
 static LIST_HEAD(arm_smmu_devices);
 
@@ -455,6 +680,8 @@ static void parse_driver_options(struct arm_smmu_device *smmu)
 
 static struct device_node *dev_get_dev_node(struct device *dev)
 {
+	/* Xen: TODO: Add support for PCI */
+#if 0
 	if (dev_is_pci(dev)) {
 		struct pci_bus *bus = to_pci_dev(dev)->bus;
 
@@ -462,7 +689,7 @@ static struct device_node *dev_get_dev_node(struct device *dev)
 			bus = bus->parent;
 		return bus->bridge->parent->of_node;
 	}
-
+#endif
 	return dev->of_node;
 }
 
@@ -556,6 +783,9 @@ static int register_smmu_master(struct arm_smmu_device *smmu,
 	master->of_node			= masterspec->np;
 	master->cfg.num_streamids	= masterspec->args_count;
 
+	/* Xen: Let Xen knows that the device is protected by an SMMU */
+	dt_device_set_protected(masterspec->np);
+
 	for (i = 0; i < master->cfg.num_streamids; ++i) {
 		u16 streamid = masterspec->args[i];
 
@@ -651,11 +881,12 @@ static void arm_smmu_tlb_inv_context(struct arm_smmu_domain *smmu_domain)
 	arm_smmu_tlb_sync(smmu);
 }
 
-static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
+static void arm_smmu_context_fault(int irq, void *dev,
+				   struct cpu_user_regs *regs)
 {
-	int flags, ret;
+	int flags;
 	u32 fsr, far, fsynr, resume;
-	unsigned long iova;
+	paddr_t iova;
 	struct iommu_domain *domain = dev;
 	struct arm_smmu_domain *smmu_domain = domain->priv;
 	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
@@ -666,7 +897,7 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
 	fsr = readl_relaxed(cb_base + ARM_SMMU_CB_FSR);
 
 	if (!(fsr & FSR_FAULT))
-		return IRQ_NONE;
+		return;
 
 	if (fsr & FSR_IGN)
 		dev_err_ratelimited(smmu->dev,
@@ -678,19 +909,16 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
 
 	far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_LO);
 	iova = far;
-#ifdef CONFIG_64BIT
+	/* Xen: The fault address maybe higher than 32 bits on arm32 */
 	far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_HI);
-	iova |= ((unsigned long)far << 32);
-#endif
+	iova |= ((paddr_t)far << 32);
 
 	if (!report_iommu_fault(domain, smmu->dev, iova, flags)) {
-		ret = IRQ_HANDLED;
 		resume = RESUME_RETRY;
 	} else {
 		dev_err_ratelimited(smmu->dev,
-		    "Unhandled context fault: iova=0x%08lx, fsynr=0x%x, cb=%d\n",
+		    "Unhandled context fault: iova=0x%"PRIpaddr", fsynr=0x%x, cb=%d\n",
 		    iova, fsynr, cfg->cbndx);
-		ret = IRQ_NONE;
 		resume = RESUME_TERMINATE;
 	}
 
@@ -700,11 +928,10 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
 	/* Retry or terminate any stalled transactions */
 	if (fsr & FSR_SS)
 		writel_relaxed(resume, cb_base + ARM_SMMU_CB_RESUME);
-
-	return ret;
 }
 
-static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
+static void arm_smmu_global_fault(int irq, void *dev,
+                                  struct cpu_user_regs *regs)
 {
 	u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
 	struct arm_smmu_device *smmu = dev;
@@ -716,7 +943,7 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
 	gfsynr2 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR2);
 
 	if (!gfsr)
-		return IRQ_NONE;
+		return;
 
 	dev_err_ratelimited(smmu->dev,
 		"Unexpected global fault, this could be serious\n");
@@ -725,9 +952,10 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
 		gfsr, gfsynr0, gfsynr1, gfsynr2);
 
 	writel(gfsr, gr0_base + ARM_SMMU_GR0_sGFSR);
-	return IRQ_HANDLED;
 }
 
+/* Xen: Page tables are shared with the processor */
+#if 0
 static void arm_smmu_flush_pgtable(struct arm_smmu_device *smmu, void *addr,
 				   size_t size)
 {
@@ -749,6 +977,7 @@ static void arm_smmu_flush_pgtable(struct arm_smmu_device *smmu, void *addr,
 				DMA_TO_DEVICE);
 	}
 }
+#endif
 
 static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 {
@@ -757,6 +986,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
 	struct arm_smmu_device *smmu = smmu_domain->smmu;
 	void __iomem *cb_base, *gr0_base, *gr1_base;
+	paddr_t p2maddr;
 
 	gr0_base = ARM_SMMU_GR0(smmu);
 	gr1_base = ARM_SMMU_GR1(smmu);
@@ -840,11 +1070,16 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 	}
 
 	/* TTBR0 */
-	arm_smmu_flush_pgtable(smmu, cfg->pgd,
-			       PTRS_PER_PGD * sizeof(pgd_t));
-	reg = __pa(cfg->pgd);
+	/* Xen: The page table is shared with the P2M code */
+	ASSERT(smmu_domain->cfg.domain != NULL);
+	p2maddr = page_to_maddr(smmu_domain->cfg.domain->arch.p2m.root);
+
+	dev_notice(smmu->dev, "d%u: p2maddr 0x%"PRIpaddr"\n",
+		   smmu_domain->cfg.domain->domain_id, p2maddr);
+
+	reg = (p2maddr & ((1ULL << 32) - 1));
 	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
-	reg = (phys_addr_t)__pa(cfg->pgd) >> 32;
+	reg = (p2maddr >> 32);
 	if (stage1)
 		reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
 	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
@@ -886,9 +1121,21 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 			reg |= (64 - smmu->s1_input_size) << TTBCR_T0SZ_SHIFT;
 		}
 	} else {
+#if CONFIG_ARM_32
+		/* Xen: Midway is using 40-bit address space. Though it may
+		 * not work on other ARM32 platform with SMMU-v1.
+		 * TODO: A quirk may be necessary if we have to support
+		 * other ARM32 platform with SMMU-v1.
+		 */
+		reg = 0x18 << TTBCR_T0SZ_SHIFT;
+#else
 		reg = 0;
+#endif
 	}
 
+	/* Xen: The attributes to walk the page table should be the same as
+	 * VTCR_EL2. Currently doesn't differ from Linux ones.
+	 */
 	reg |= TTBCR_EAE |
 	      (TTBCR_SH_IS << TTBCR_SH0_SHIFT) |
 	      (TTBCR_RGN_WBWA << TTBCR_ORGN0_SHIFT) |
@@ -1031,7 +1278,6 @@ static void arm_smmu_destroy_domain_context(struct iommu_domain *domain)
 static int arm_smmu_domain_init(struct iommu_domain *domain)
 {
 	struct arm_smmu_domain *smmu_domain;
-	pgd_t *pgd;
 
 	/*
 	 * Allocate the domain and initialise some of its data structures.
@@ -1042,20 +1288,12 @@ static int arm_smmu_domain_init(struct iommu_domain *domain)
 	if (!smmu_domain)
 		return -ENOMEM;
 
-	pgd = kcalloc(PTRS_PER_PGD, sizeof(pgd_t), GFP_KERNEL);
-	if (!pgd)
-		goto out_free_domain;
-	smmu_domain->cfg.pgd = pgd;
-
 	spin_lock_init(&smmu_domain->lock);
 	domain->priv = smmu_domain;
 	return 0;
-
-out_free_domain:
-	kfree(smmu_domain);
-	return -ENOMEM;
 }
 
+#if 0
 static void arm_smmu_free_ptes(pmd_t *pmd)
 {
 	pgtable_t table = pmd_pgtable(*pmd);
@@ -1118,6 +1356,7 @@ static void arm_smmu_free_pgtables(struct arm_smmu_domain *smmu_domain)
 
 	kfree(pgd_base);
 }
+#endif
 
 /*
  * For a given set N of 2**order different stream IDs (no duplicates
@@ -1259,7 +1498,6 @@ static void arm_smmu_domain_destroy(struct iommu_domain *domain)
 	 * already been detached.
 	 */
 	arm_smmu_destroy_domain_context(domain);
-	arm_smmu_free_pgtables(smmu_domain);
 	kfree(smmu_domain);
 }
 
@@ -1384,11 +1622,12 @@ static void arm_smmu_domain_remove_master(struct arm_smmu_domain *smmu_domain,
 	/*
 	 * We *must* clear the S2CR first, because freeing the SMR means
 	 * that it can be re-allocated immediately.
+	 * Xen: Unlike Linux, any access to non-configured stream will fault.
 	 */
 	for (i = 0; i < cfg->num_streamids; ++i) {
 		u32 idx = cfg->smrs ? cfg->smrs[i].idx : cfg->streamids[i];
 
-		writel_relaxed(S2CR_TYPE_BYPASS,
+		writel_relaxed(S2CR_TYPE_FAULT,
 			       gr0_base + ARM_SMMU_GR0_S2CR(idx));
 	}
 
@@ -1408,7 +1647,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 		return -ENXIO;
 	}
 
-	if (dev->archdata.iommu) {
+	if (dev_iommu_domain(dev)) {
 		dev_err(dev, "already attached to IOMMU domain\n");
 		return -EEXIST;
 	}
@@ -1440,8 +1679,9 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 		return -ENODEV;
 
 	ret = arm_smmu_domain_add_master(smmu_domain, cfg);
+
 	if (!ret)
-		dev->archdata.iommu = domain;
+		dev_iommu_domain(dev) = domain;
 	return ret;
 }
 
@@ -1454,10 +1694,14 @@ static void arm_smmu_detach_dev(struct iommu_domain *domain, struct device *dev)
 	if (!cfg)
 		return;
 
-	dev->archdata.iommu = NULL;
+	dev_iommu_domain(dev) = NULL;
 	arm_smmu_domain_remove_master(smmu_domain, cfg);
 }
 
+/* Xen: the page table is shared with the processor, therefore helpers to
+ * implement separate is not necessary.
+ */
+#if 0
 static bool arm_smmu_pte_is_contiguous_range(unsigned long addr,
 					     unsigned long end)
 {
@@ -1746,7 +1990,10 @@ static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
 
 	return __pfn_to_phys(pte_pfn(pte)) | (iova & ~PAGE_MASK);
 }
+#endif
 
+/* Xen: Functions are not used at the moment */
+#if 0
 static bool arm_smmu_capable(enum iommu_cap cap)
 {
 	switch (cap) {
@@ -1775,6 +2022,7 @@ static void __arm_smmu_release_pci_iommudata(void *data)
 {
 	kfree(data);
 }
+#endif
 
 static int arm_smmu_add_device(struct device *dev)
 {
@@ -1784,6 +2032,10 @@ static int arm_smmu_add_device(struct device *dev)
 	void (*releasefn)(void *) = NULL;
 	int ret;
 
+	/* Xen: Check if the device has already been added */
+	if (dev_iommu_group(dev))
+		return -EBUSY;
+
 	smmu = find_smmu_for_device(dev);
 	if (!smmu)
 		return -ENODEV;
@@ -1795,6 +2047,9 @@ static int arm_smmu_add_device(struct device *dev)
 	}
 
 	if (dev_is_pci(dev)) {
+		/* Xen: TODO: Add PCI support */
+		BUG();
+#if 0
 		struct pci_dev *pdev = to_pci_dev(dev);
 
 		cfg = kzalloc(sizeof(*cfg), GFP_KERNEL);
@@ -1811,6 +2066,7 @@ static int arm_smmu_add_device(struct device *dev)
 		pci_for_each_dma_alias(pdev, __arm_smmu_get_pci_sid,
 				       &cfg->streamids[0]);
 		releasefn = __arm_smmu_release_pci_iommudata;
+#endif
 	} else {
 		struct arm_smmu_master *master;
 
@@ -1831,6 +2087,8 @@ out_put_group:
 	return ret;
 }
 
+/* Xen: We don't support remove device for now. Will be useful for PCI */
+#if 0
 static void arm_smmu_remove_device(struct device *dev)
 {
 	iommu_group_remove_device(dev);
@@ -1888,6 +2146,7 @@ static const struct iommu_ops arm_smmu_ops = {
 				   ARM_SMMU_PTE_CONT_SIZE |
 				   PAGE_SIZE),
 };
+#endif
 
 static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 {
@@ -1903,7 +2162,11 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 	/* Mark all SMRn as invalid and all S2CRn as bypass */
 	for (i = 0; i < smmu->num_mapping_groups; ++i) {
 		writel_relaxed(0, gr0_base + ARM_SMMU_GR0_SMR(i));
-		writel_relaxed(S2CR_TYPE_BYPASS,
+		/*
+		 * Xen: Unlike Linux, any access to a non-configure stream
+		 * will fault by default.
+		 */
+		writel_relaxed(S2CR_TYPE_FAULT,
 			gr0_base + ARM_SMMU_GR0_S2CR(i));
 	}
 
@@ -1929,6 +2192,8 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 
 	/* Enable client access, but bypass when no mapping is found */
 	reg &= ~(sCR0_CLIENTPD | sCR0_USFCFG);
+	/* Xen: Unlike Linux, generate a fault when no mapping is found */
+	reg |= sCR0_USFCFG;
 
 	/* Disable forced broadcasting */
 	reg &= ~sCR0_FB;
@@ -2039,7 +2304,7 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
 		smmu->smr_id_mask = sid;
 
 		dev_notice(smmu->dev,
-			   "\tstream matching with %u register groups, mask 0x%x",
+			   "\tstream matching with %u register groups, mask 0x%x\n",
 			   smmu->num_mapping_groups, mask);
 	} else {
 		smmu->num_mapping_groups = (id >> ID0_NUMSIDB_SHIFT) &
@@ -2074,12 +2339,30 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
 	size = arm_smmu_id_size_to_bits((id >> ID2_IAS_SHIFT) & ID2_IAS_MASK);
 	smmu->s1_output_size = min_t(unsigned long, PHYS_MASK_SHIFT, size);
 
+	/* Xen: Stage-2 input size is not restricted */
+	smmu->s2_input_size = size;
+#if 0
 	/* Stage-2 input size limited due to pgd allocation (PTRS_PER_PGD) */
 #ifdef CONFIG_64BIT
 	smmu->s2_input_size = min_t(unsigned long, VA_BITS, size);
 #else
 	smmu->s2_input_size = min(32UL, size);
 #endif
+#endif
+
+	/*
+	 * Xen: SMMU v1: Only 40 bits input address size is supported for
+ 	 * arm32. See arm_smmu_init_context_bank
+	 */
+#ifdef CONFIG_ARM_32
+	if ( smmu->version == ARM_SMMU_V1 && smmu->s2_input_size != 40 )
+	{
+		dev_err(smmu->dev,
+			"Stage-2 Input size %ld not supported for SMMUv1\n",
+			smmu->s2_input_size);
+		return -ENODEV;;
+	}
+#endif
 
 	/* The stage-2 output mask is also applied for bypass */
 	size = arm_smmu_id_size_to_bits((id >> ID2_OAS_SHIFT) & ID2_OAS_MASK);
@@ -2124,8 +2407,11 @@ static const struct of_device_id arm_smmu_of_match[] = {
 	{ .compatible = "arm,mmu-500", .data = (void *)ARM_SMMU_V2 },
 	{ },
 };
-MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
 
+/*
+ * Xen: We don't have refcount allocated memory so manually free memory when
+ * an error occured.
+ */
 static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 {
 	const struct of_device_id *of_id;
@@ -2149,14 +2435,17 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	smmu->base = devm_ioremap_resource(dev, res);
-	if (IS_ERR(smmu->base))
-		return PTR_ERR(smmu->base);
+	if (IS_ERR(smmu->base)) {
+		err = PTR_ERR(smmu->base);
+		goto out_free;
+	}
 	smmu->size = resource_size(res);
 
 	if (of_property_read_u32(dev->of_node, "#global-interrupts",
 				 &smmu->num_global_irqs)) {
 		dev_err(dev, "missing #global-interrupts property\n");
-		return -ENODEV;
+		err = -ENODEV;
+		goto out_free;
 	}
 
 	num_irqs = 0;
@@ -2169,14 +2458,16 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 	if (!smmu->num_context_irqs) {
 		dev_err(dev, "found %d interrupts but expected at least %d\n",
 			num_irqs, smmu->num_global_irqs + 1);
-		return -ENODEV;
+		err = -ENODEV;
+		goto out_free;
 	}
 
 	smmu->irqs = devm_kzalloc(dev, sizeof(*smmu->irqs) * num_irqs,
 				  GFP_KERNEL);
 	if (!smmu->irqs) {
 		dev_err(dev, "failed to allocate %d irqs\n", num_irqs);
-		return -ENOMEM;
+		err = -ENOMEM;
+		goto out_free;
 	}
 
 	for (i = 0; i < num_irqs; ++i) {
@@ -2184,7 +2475,8 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 
 		if (irq < 0) {
 			dev_err(dev, "failed to get irq index %d\n", i);
-			return -ENODEV;
+			err = -ENODEV;
+			goto out_free;
 		}
 		smmu->irqs[i] = irq;
 	}
@@ -2259,12 +2551,20 @@ out_put_masters:
 	for (node = rb_first(&smmu->masters); node; node = rb_next(node)) {
 		struct arm_smmu_master *master
 			= container_of(node, struct arm_smmu_master, node);
-		of_node_put(master->of_node);
+		kfree(master);
 	}
 
+out_free:
+	kfree(smmu->irqs);
+	if (!IS_ERR(smmu->base))
+		iounmap(smmu->base);
+	kfree(smmu);
+
 	return err;
 }
 
+/* Xen: We never remove SMMU */
+#if 0
 static int arm_smmu_device_remove(struct platform_device *pdev)
 {
 	int i;
@@ -2359,3 +2659,237 @@ module_exit(arm_smmu_exit);
 MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
 MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
 MODULE_LICENSE("GPL v2");
+#endif
+
+/* Xen specific function */
+
+static void arm_smmu_iotlb_flush_all(struct domain *d)
+{
+	struct arm_smmu_xen_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
+	struct iommu_domain *cfg;
+
+	spin_lock(&smmu_domain->lock);
+	list_for_each_entry(cfg, &smmu_domain->contexts, list) {
+		/*
+		 * Only invalidate the context when SMMU is present.
+		 * This is because the context initialization is delayed
+		 * until a master has been added.
+		 */
+		if (unlikely(!ACCESS_ONCE(cfg->priv->smmu)))
+			continue;
+		arm_smmu_tlb_inv_context(cfg->priv);
+	}
+	spin_unlock(&smmu_domain->lock);
+}
+
+static void arm_smmu_iotlb_flush(struct domain *d, unsigned long gfn,
+                                 unsigned int page_count)
+{
+    /* ARM SMMU v1 doesn't have flush by VMA and VMID */
+    arm_smmu_iotlb_flush_all(d);
+}
+
+static int arm_smmu_assign_dev(struct domain *d, u8 devfn,
+			       struct device *dev)
+{
+	struct iommu_domain *domain;
+	struct arm_smmu_xen_domain *xen_domain;
+	int ret;
+
+	xen_domain = domain_hvm_iommu(d)->arch.priv;
+
+	if (!dev->archdata.iommu) {
+		dev->archdata.iommu = xzalloc(struct arm_smmu_xen_device);
+		if (!dev->archdata.iommu)
+			return -ENOMEM;
+	}
+
+	if (!dev_iommu_group(dev)) {
+		ret = arm_smmu_add_device(dev);
+		if (ret)
+			return ret;
+	}
+
+	/*
+	 * TODO: Share the context bank (i.e iommu_domain) when the device is
+	 * under the same SMMU as another device assigned to this domain.
+	 * Would it useful for PCI
+	 */
+	domain = xzalloc(struct iommu_domain);
+	if (!domain)
+		return -ENOMEM;
+
+	ret = arm_smmu_domain_init(domain);
+	if (ret)
+		goto err_dom_init;
+
+	domain->priv->cfg.domain = d;
+
+	ret = arm_smmu_attach_dev(domain, dev);
+	if (ret)
+		goto err_attach_dev;
+
+	spin_lock(&xen_domain->lock);
+	/* Chain the new context to the domain */
+	list_add(&domain->list, &xen_domain->contexts);
+	spin_unlock(&xen_domain->lock);
+
+	return 0;
+
+err_attach_dev:
+	arm_smmu_domain_destroy(domain);
+err_dom_init:
+	xfree(domain);
+
+	return ret;
+}
+
+static int arm_smmu_deassign_dev(struct domain *d, struct device *dev)
+{
+	struct iommu_domain *domain = dev_iommu_domain(dev);
+	struct arm_smmu_xen_domain *xen_domain;
+
+	xen_domain = domain_hvm_iommu(d)->arch.priv;
+
+	if (!domain || domain->priv->cfg.domain != d) {
+		dev_err(dev, " not attached to domain %d\n", d->domain_id);
+		return -ESRCH;
+	}
+
+	arm_smmu_detach_dev(domain, dev);
+
+	spin_lock(&xen_domain->lock);
+	list_del(&domain->list);
+	spin_unlock(&xen_domain->lock);
+
+	arm_smmu_domain_destroy(domain);
+	xfree(domain);
+
+	return 0;
+}
+
+static int arm_smmu_reassign_dev(struct domain *s, struct domain *t,
+				 u8 devfn,  struct device *dev)
+{
+	int ret = 0;
+
+	/* Don't allow remapping on other domain than hwdom */
+	if (t != hardware_domain)
+		return -EPERM;
+
+	if (t == s)
+		return 0;
+
+	ret = arm_smmu_deassign_dev(s, dev);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int arm_smmu_iommu_domain_init(struct domain *d)
+{
+	struct arm_smmu_xen_domain *xen_domain;
+
+	xen_domain = xzalloc(struct arm_smmu_xen_domain);
+	if ( !xen_domain )
+		return -ENOMEM;
+
+	spin_lock_init(&xen_domain->lock);
+	INIT_LIST_HEAD(&xen_domain->contexts);
+
+	domain_hvm_iommu(d)->arch.priv = xen_domain;
+
+	return 0;
+}
+
+static void __hwdom_init arm_smmu_iommu_hwdom_init(struct domain *d)
+{
+}
+
+static void arm_smmu_iommu_domain_teardown(struct domain *d)
+{
+	struct arm_smmu_xen_domain *xen_domain = domain_hvm_iommu(d)->arch.priv;
+
+	ASSERT(list_empty(&xen_domain->contexts));
+	xfree(xen_domain);
+}
+
+
+static int arm_smmu_map_page(struct domain *d, unsigned long gfn,
+			     unsigned long mfn, unsigned int flags)
+{
+	p2m_type_t t;
+
+	/*
+	 * Grant mappings can be used for DMA requests. The dev_bus_addr
+	 * returned by the hypercall is the MFN (not the IPA). For device
+	 * protected by an IOMMU, Xen needs to add a 1:1 mapping in the domain
+	 * p2m to allow DMA request to work.
+	 * This is only valid when the domain is directed mapped. Hence this
+	 * function should only be used by gnttab code with gfn == mfn.
+	 */
+	BUG_ON(!is_domain_direct_mapped(d));
+	BUG_ON(mfn != gfn);
+
+	/* We only support readable and writable flags */
+	if (!(flags & (IOMMUF_readable | IOMMUF_writable)))
+		return -EINVAL;
+
+	t = (flags & IOMMUF_writable) ? p2m_iommu_map_rw : p2m_iommu_map_ro;
+
+	/*
+	 * The function guest_physmap_add_entry replaces the current mapping
+	 * if there is already one...
+	 */
+	return guest_physmap_add_entry(d, gfn, mfn, 0, t);
+}
+
+static int arm_smmu_unmap_page(struct domain *d, unsigned long gfn)
+{
+	/*
+	 * This function should only be used by gnttab code when the domain
+	 * is direct mapped
+	 */
+	if ( !is_domain_direct_mapped(d) )
+		return -EINVAL;
+
+	guest_physmap_remove_page(d, gfn, gfn, 0);
+
+	return 0;
+}
+
+static const struct iommu_ops arm_smmu_iommu_ops = {
+    .init = arm_smmu_iommu_domain_init,
+    .hwdom_init = arm_smmu_iommu_hwdom_init,
+    .teardown = arm_smmu_iommu_domain_teardown,
+    .iotlb_flush = arm_smmu_iotlb_flush,
+    .iotlb_flush_all = arm_smmu_iotlb_flush_all,
+    .assign_device = arm_smmu_assign_dev,
+    .reassign_device = arm_smmu_reassign_dev,
+    .map_page = arm_smmu_map_page,
+    .unmap_page = arm_smmu_unmap_page,
+};
+
+static __init int arm_smmu_dt_init(struct dt_device_node *dev,
+				   const void *data)
+{
+	int rc;
+
+	/*
+	 * Even if the device can't be initialized, we don't want to
+	 * give the SMMU device to dom0.
+	 */
+	dt_device_set_used_by(dev, DOMID_XEN);
+
+	rc = arm_smmu_device_dt_probe(dev);
+	if ( !rc )
+		iommu_set_ops(&arm_smmu_iommu_ops);
+
+	return rc;
+}
+
+DT_DEVICE_START(smmu, "ARM SMMU", DEVICE_IOMMU)
+	.dt_match = arm_smmu_of_match,
+	.init = arm_smmu_dt_init,
+DT_DEVICE_END
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yR4-0004pM-SD; Tue, 16 Dec 2014 20:09:34 +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 1Y0yR3-0004oF-9N
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:33 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	8B/48-23865-C7190945; Tue, 16 Dec 2014 20:09:32 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418760571!10107944!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3817 invoked from network); 16 Dec 2014 20:09:31 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:31 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so13440695wib.16
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09:31 -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=IpWq8nDRn7CvvN/tiBXqxoBcBpCCcYMqGBAv6BOOyw0=;
	b=BdWhNGj7fb0+Utg9dm8IU2DDAmIzTmTIU7wX4rCgUdldSDjaVerN2hZ4nnJVKtkhCQ
	NkWQKUQvzOUVY8DCP2YZbooyEHAAIBbi7sbJSJQsrsuBKyS9DxnVJFUUnw5hZoSRhekW
	TzNlhkrmFMor5OyzrF/YxOzzAOtSTQqAmn4/w2YhUXOjosR1zn5xyMucnBFUXJu3f4R7
	8M4ZQlQyGG1hBpb2iTT7jSGSm61fFTR6PNVqOJvsOIse+VFdIkYFtpLFg3SoW6Y56PM+
	ANSfDeK4o40lPhcLVB71eZe4knbTkjV1SSQZ7ZCq+uvW3coQy5MiHwQqjBGlzEjozZaZ
	nzag==
X-Gm-Message-State: ALoCoQksZGnTy809na7CTmKCrwkVUInj+2g5WJXEvr9/TdYnqsXYBA+Ujcx/xJ/Paxm+AyOOdg3t
X-Received: by 10.194.108.98 with SMTP id hj2mr65711698wjb.102.1418760571184; 
	Tue, 16 Dec 2014 12:09:31 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.29
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:29 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:49 +0000
Message-Id: <1418760534-18163-9-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: Kevin Tian <kevin.tian@intel.com>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	Jan Beulich <jbeulich@suse.com>, stefano.stabellini@citrix.com,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Yang Zhang <yang.z.zhang@intel.com>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
Subject: [Xen-devel] [PATCH for 4.6 08/13] xen/iommu: Consolidate device
	assignment ops into a single set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM, the way to assign device tree node is exactly the same as PCI.
Futhermore, all devices can be represented by a "struct device'.
Therefore there is no need to add separate ops.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
CC: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
CC: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Yang Zhang <yang.z.zhang@intel.com>
CC: Kevin Tian <kevin.tian@intel.com>
---
 xen/drivers/passthrough/amd/pci_amd_iommu.c | 14 +++++++++-----
 xen/drivers/passthrough/device_tree.c       |  5 +++--
 xen/drivers/passthrough/pci.c               | 20 +++++++++++---------
 xen/drivers/passthrough/vtd/iommu.c         | 19 ++++++++++++-------
 xen/include/xen/iommu.h                     | 18 +++++++-----------
 5 files changed, 42 insertions(+), 34 deletions(-)

diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index e83bb35..0af13fb 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -355,8 +355,9 @@ void amd_iommu_disable_domain_device(struct domain *domain,
 }
 
 static int reassign_device(struct domain *source, struct domain *target,
-                           u8 devfn, struct pci_dev *pdev)
+                           u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct amd_iommu *iommu;
     int bdf;
     struct hvm_iommu *t = domain_hvm_iommu(target);
@@ -394,8 +395,9 @@ static int reassign_device(struct domain *source, struct domain *target,
 }
 
 static int amd_iommu_assign_device(struct domain *d, u8 devfn,
-                                   struct pci_dev *pdev)
+                                   struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(pdev->seg);
     int bdf = PCI_BDF2(pdev->bus, devfn);
     int req_id = get_dma_requestor_id(pdev->seg, bdf);
@@ -410,7 +412,7 @@ static int amd_iommu_assign_device(struct domain *d, u8 devfn,
             ivrs_mappings[req_id].read_permission);
     }
 
-    return reassign_device(hardware_domain, d, devfn, pdev);
+    return reassign_device(hardware_domain, d, devfn, dev);
 }
 
 static void deallocate_next_page_table(struct page_info *pg, int level)
@@ -481,8 +483,9 @@ static void amd_iommu_domain_destroy(struct domain *d)
     amd_iommu_flush_all_pages(d);
 }
 
-static int amd_iommu_add_device(u8 devfn, struct pci_dev *pdev)
+static int amd_iommu_add_device(u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct amd_iommu *iommu;
     u16 bdf;
     if ( !pdev->domain )
@@ -503,8 +506,9 @@ static int amd_iommu_add_device(u8 devfn, struct pci_dev *pdev)
     return 0;
 }
 
-static int amd_iommu_remove_device(u8 devfn, struct pci_dev *pdev)
+static int amd_iommu_remove_device(u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct amd_iommu *iommu;
     u16 bdf;
     if ( !pdev->domain )
diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c
index 3e47df5..377d41d 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -41,7 +41,7 @@ int iommu_assign_dt_device(struct domain *d, struct dt_device_node *dev)
     if ( !list_empty(&dev->domain_list) )
         goto fail;
 
-    rc = hd->platform_ops->assign_dt_device(d, dev);
+    rc = hd->platform_ops->assign_device(d, 0, dt_to_dev(dev));
 
     if ( rc )
         goto fail;
@@ -68,7 +68,8 @@ int iommu_deassign_dt_device(struct domain *d, struct dt_device_node *dev)
 
     spin_lock(&dtdevs_lock);
 
-    rc = hd->platform_ops->reassign_dt_device(d, hardware_domain, dev);
+    rc = hd->platform_ops->reassign_device(d, hardware_domain,
+                                           0, dt_to_dev(dev));
     if ( rc )
         goto fail;
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 9fbd2a2..43ce5dc 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1256,7 +1256,7 @@ int iommu_add_device(struct pci_dev *pdev)
     if ( !iommu_enabled || !hd->platform_ops )
         return 0;
 
-    rc = hd->platform_ops->add_device(pdev->devfn, pdev);
+    rc = hd->platform_ops->add_device(pdev->devfn, pci_to_dev(pdev));
     if ( rc || !pdev->phantom_stride )
         return rc;
 
@@ -1265,7 +1265,7 @@ int iommu_add_device(struct pci_dev *pdev)
         devfn += pdev->phantom_stride;
         if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
             return 0;
-        rc = hd->platform_ops->add_device(devfn, pdev);
+        rc = hd->platform_ops->add_device(devfn, pci_to_dev(pdev));
         if ( rc )
             printk(XENLOG_WARNING "IOMMU: add %04x:%02x:%02x.%u failed (%d)\n",
                    pdev->seg, pdev->bus, PCI_SLOT(devfn), PCI_FUNC(devfn), rc);
@@ -1286,7 +1286,7 @@ int iommu_enable_device(struct pci_dev *pdev)
          !hd->platform_ops->enable_device )
         return 0;
 
-    return hd->platform_ops->enable_device(pdev);
+    return hd->platform_ops->enable_device(pci_to_dev(pdev));
 }
 
 int iommu_remove_device(struct pci_dev *pdev)
@@ -1308,7 +1308,7 @@ int iommu_remove_device(struct pci_dev *pdev)
         devfn += pdev->phantom_stride;
         if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
             break;
-        rc = hd->platform_ops->remove_device(devfn, pdev);
+        rc = hd->platform_ops->remove_device(devfn, pci_to_dev(pdev));
         if ( !rc )
             continue;
 
@@ -1317,7 +1317,7 @@ int iommu_remove_device(struct pci_dev *pdev)
         return rc;
     }
 
-    return hd->platform_ops->remove_device(pdev->devfn, pdev);
+    return hd->platform_ops->remove_device(pdev->devfn, pci_to_dev(pdev));
 }
 
 /*
@@ -1378,7 +1378,7 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
 
     pdev->fault.count = 0;
 
-    if ( (rc = hd->platform_ops->assign_device(d, devfn, pdev)) )
+    if ( (rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev))) )
         goto done;
 
     for ( ; pdev->phantom_stride; rc = 0 )
@@ -1386,7 +1386,7 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
         devfn += pdev->phantom_stride;
         if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
             break;
-        rc = hd->platform_ops->assign_device(d, devfn, pdev);
+        rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev));
         if ( rc )
             printk(XENLOG_G_WARNING "d%d: assign %04x:%02x:%02x.%u failed (%d)\n",
                    d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
@@ -1421,7 +1421,8 @@ int deassign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
         devfn += pdev->phantom_stride;
         if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
             break;
-        ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn, pdev);
+        ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn,
+                                                pci_to_dev(pdev));
         if ( !ret )
             continue;
 
@@ -1431,7 +1432,8 @@ int deassign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
     }
 
     devfn = pdev->devfn;
-    ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn, pdev);
+    ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn,
+                                            pci_to_dev(pdev));
     if ( ret )
     {
         dprintk(XENLOG_G_ERR,
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index 19d8165..213a471 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1875,8 +1875,9 @@ static int rmrr_identity_mapping(struct domain *d, bool_t map,
     return 0;
 }
 
-static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
+static int intel_iommu_add_device(u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct acpi_rmrr_unit *rmrr;
     u16 bdf;
     int ret, i;
@@ -1910,8 +1911,9 @@ static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
     return 0;
 }
 
-static int intel_iommu_enable_device(struct pci_dev *pdev)
+static int intel_iommu_enable_device(struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
     int ret = drhd ? ats_device(pdev, drhd) : -ENODEV;
 
@@ -1925,8 +1927,9 @@ static int intel_iommu_enable_device(struct pci_dev *pdev)
     return ret >= 0 ? 0 : ret;
 }
 
-static int intel_iommu_remove_device(u8 devfn, struct pci_dev *pdev)
+static int intel_iommu_remove_device(u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct acpi_rmrr_unit *rmrr;
     u16 bdf;
     int i;
@@ -2212,8 +2215,9 @@ int __init intel_vtd_setup(void)
 static int reassign_device_ownership(
     struct domain *source,
     struct domain *target,
-    u8 devfn, struct pci_dev *pdev)
+    u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     int ret;
 
     /*
@@ -2266,8 +2270,9 @@ static int reassign_device_ownership(
 }
 
 static int intel_iommu_assign_device(
-    struct domain *d, u8 devfn, struct pci_dev *pdev)
+    struct domain *d, u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct acpi_rmrr_unit *rmrr;
     int ret = 0, i;
     u16 bdf, seg;
@@ -2276,7 +2281,7 @@ static int intel_iommu_assign_device(
     if ( list_empty(&acpi_drhd_units) )
         return -ENODEV;
 
-    ret = reassign_device_ownership(hardware_domain, d, devfn, pdev);
+    ret = reassign_device_ownership(hardware_domain, d, devfn, dev);
     if ( ret )
         return ret;
 
@@ -2298,7 +2303,7 @@ static int intel_iommu_assign_device(
             ret = rmrr_identity_mapping(d, 1, rmrr);
             if ( ret )
             {
-                reassign_device_ownership(d, hardware_domain, devfn, pdev);
+                reassign_device_ownership(d, hardware_domain, devfn, dev);
                 printk(XENLOG_G_ERR VTDPREFIX
                        " cannot map reserved region (%"PRIx64",%"PRIx64"] for Dom%d (%d)\n",
                        rmrr->base_address, rmrr->end_address,
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 8eb764a..d0f99ef 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -23,6 +23,7 @@
 #include <xen/init.h>
 #include <xen/spinlock.h>
 #include <xen/pci.h>
+#include <xen/device.h>
 #include <public/hvm/ioreq.h>
 #include <public/domctl.h>
 #include <asm/iommu.h>
@@ -123,22 +124,17 @@ struct page_info;
 struct iommu_ops {
     int (*init)(struct domain *d);
     void (*hwdom_init)(struct domain *d);
-#ifdef HAS_PCI
-    int (*add_device)(u8 devfn, struct pci_dev *);
-    int (*enable_device)(struct pci_dev *pdev);
-    int (*remove_device)(u8 devfn, struct pci_dev *);
-    int (*assign_device)(struct domain *, u8 devfn, struct pci_dev *);
+    int (*add_device)(u8 devfn, struct device *);
+    int (*enable_device)(struct device *dev);
+    int (*remove_device)(u8 devfn, struct device *);
+    int (*assign_device)(struct domain *, u8 devfn, struct device *);
     int (*reassign_device)(struct domain *s, struct domain *t,
-			   u8 devfn, struct pci_dev *);
+                           u8 devfn, struct device *);
+#ifdef HAS_PCI
     int (*get_device_group_id)(u16 seg, u8 bus, u8 devfn);
     int (*update_ire_from_msi)(struct msi_desc *msi_desc, struct msi_msg *msg);
     void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct msi_msg *msg);
 #endif /* HAS_PCI */
-#ifdef HAS_DEVICE_TREE
-    int (*assign_dt_device)(struct domain *d, const struct dt_device_node *dev);
-    int (*reassign_dt_device)(struct domain *s, struct domain *t,
-                              const struct dt_device_node *dev);
-#endif
 
     void (*teardown)(struct domain *d);
     int (*map_page)(struct domain *d, unsigned long gfn, unsigned long mfn,
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yR7-0004qL-AG; Tue, 16 Dec 2014 20:09:37 +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 1Y0yR5-0004pj-W2
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:36 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	46/14-02696-F7190945; Tue, 16 Dec 2014 20:09:35 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418760574!15504407!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31596 invoked from network); 16 Dec 2014 20:09:34 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:34 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so14845137wib.1
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=XYSpGQOswUe9pDTIAJCMYrH5Vlf6V9EDF7ijvfTFVj4=;
	b=gg8Bv+JSjq7jsNCvltIH1vt9sgz2mr1h6x2jwC5PWAZ0yEq3SWxq9nfiz271udWK7H
	IDpx2cJPU/dCkOvoQv9KJ7m66HOYhJWtixOirbg1QN2odKJfuIIBI6JfBEC0EJWW095Z
	O/imPaXcz4wRxb5QjZrWpLikricgipy2zRnX4Sz33R53gl5wNc+CHjcQWza+tQxUZ/8p
	L9vYWMbqCFoGALxd5vYlN6IkSokmXtvdXBbjwI1IwSedH7Dgo4URIyM+jLoxcTcCqPsP
	i0pP6r8I4G2kzWNVUL9zOxKB3xPAAcHeRBkua73f4JpI2L9HbSDu0s4NEdJKrbl2I5Ca
	Typw==
X-Gm-Message-State: ALoCoQkp0FwCz3Ql/MLeltDE6A4SGCFJ68Ip1CgdnRI1ize5n0clxg6AfYAyJNbaGcztEROYEAFU
X-Received: by 10.194.241.194 with SMTP id wk2mr65135860wjc.132.1418760572673; 
	Tue, 16 Dec 2014 12:09:32 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.31
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:31 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:50 +0000
Message-Id: <1418760534-18163-10-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 09/13] xen/arm: Describe device
	supported by a driver with dt_match_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xen is currently using list a compatible string to know if the driver
can use device node. This leads to have double definition in the GIC
code.

Futhermore Linux drivers is using dt_match_node (actually called of_device_id
in Linux) to list device supported by the drivers.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/device.c              | 21 ++-------------------
 xen/arch/arm/gic-v2.c              | 10 ++++------
 xen/arch/arm/gic-v3.c              |  8 ++++----
 xen/drivers/char/exynos4210-uart.c |  8 ++++----
 xen/drivers/char/ns16550.c         | 12 ++++++------
 xen/drivers/char/omap-uart.c       |  8 ++++----
 xen/drivers/char/pl011.c           |  8 ++++----
 xen/include/asm-arm/device.h       |  8 ++++++--
 xen/include/asm-arm/gic.h          | 15 +++++----------
 9 files changed, 39 insertions(+), 59 deletions(-)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index de702ff..1993929 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -23,23 +23,6 @@
 
 extern const struct device_desc _sdevice[], _edevice[];
 
-static bool_t __init device_is_compatible(const struct device_desc *desc,
-                                          const struct dt_device_node *dev)
-{
-    const char *const *compat;
-
-    if ( !desc->compatible )
-        return 0;
-
-    for ( compat = desc->compatible; *compat; compat++ )
-    {
-        if ( dt_device_is_compatible(dev, *compat) )
-            return 1;
-    }
-
-    return 0;
-}
-
 int __init device_init(struct dt_device_node *dev, enum device_match type,
                        const void *data)
 {
@@ -55,7 +38,7 @@ int __init device_init(struct dt_device_node *dev, enum device_match type,
         if ( desc->type != type )
             continue;
 
-        if ( device_is_compatible(desc, dev) )
+        if ( dt_match_node(desc->dt_match, dev) )
         {
             ASSERT(desc->init != NULL);
 
@@ -75,7 +58,7 @@ enum device_match device_get_type(const struct dt_device_node *dev)
 
     for ( desc = _sdevice; desc != _edevice; desc++ )
     {
-        if ( device_is_compatible(desc, dev) )
+        if ( dt_match_node(desc->dt_match, dev) )
             return desc->type;
     }
 
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 048350b..db3795d 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -763,16 +763,14 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
     return 0;
 }
 
-static const char * const gicv2_dt_compat[] __initconst =
+static const struct dt_device_match gicv2_dt_match[] __initconst =
 {
-    DT_COMPAT_GIC_CORTEX_A15,
-    DT_COMPAT_GIC_CORTEX_A7,
-    DT_COMPAT_GIC_400,
-    NULL
+    DT_MATCH_GIC_V2,
+    { /* sentinel */ },
 };
 
 DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
-        .compatible = gicv2_dt_compat,
+        .dt_match = gicv2_dt_match,
         .init = gicv2_init,
 DT_DEVICE_END
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index c6d1876..1191cb7 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1278,14 +1278,14 @@ static int __init gicv3_init(struct dt_device_node *node, const void *data)
     return res;
 }
 
-static const char * const gicv3_dt_compat[] __initconst =
+static const struct dt_device_match gicv3_dt_match[] __initconst =
 {
-    DT_COMPAT_GIC_V3,
-    NULL
+    DT_MATCH_GIC_V3,
+    { /* sentinel */ },
 };
 
 DT_DEVICE_START(gicv3, "GICv3", DEVICE_GIC)
-        .compatible = gicv3_dt_compat,
+        .dt_match = gicv3_dt_match,
         .init = gicv3_init,
 DT_DEVICE_END
 
diff --git a/xen/drivers/char/exynos4210-uart.c b/xen/drivers/char/exynos4210-uart.c
index 75246e1..b59e64a 100644
--- a/xen/drivers/char/exynos4210-uart.c
+++ b/xen/drivers/char/exynos4210-uart.c
@@ -352,14 +352,14 @@ static int __init exynos4210_uart_init(struct dt_device_node *dev,
     return 0;
 }
 
-static const char * const exynos4210_dt_compat[] __initconst =
+static const struct dt_device_match exynos4210_dt_match[] __initconst =
 {
-    "samsung,exynos4210-uart",
-    NULL
+    DT_MATCH_COMPATIBLE("samsung,exynos4210-uart"),
+    { /* sentinel */ },
 };
 
 DT_DEVICE_START(exynos4210, "Exynos 4210 UART", DEVICE_SERIAL)
-        .compatible = exynos4210_dt_compat,
+        .dt_match = exynos4210_dt_match,
         .init = exynos4210_uart_init,
 DT_DEVICE_END
 
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 6df3f95..a0373a9 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1185,16 +1185,16 @@ static int __init ns16550_uart_dt_init(struct dt_device_node *dev,
     return 0;
 }
 
-static const char * const ns16550_dt_compat[] __initconst =
+static const struct dt_device_match ns16550_dt_match[] __initconst =
 {
-    "ns16550",
-    "ns16550a",
-    "snps,dw-apb-uart",
-    NULL
+    DT_MATCH_COMPATIBLE("ns16550"),
+    DT_MATCH_COMPATIBLE("ns16550a"),
+    DT_MATCH_COMPATIBLE("snps,dw-apb-uart"),
+    { /* sentinel */ },
 };
 
 DT_DEVICE_START(ns16550, "NS16550 UART", DEVICE_SERIAL)
-        .compatible = ns16550_dt_compat,
+        .dt_match = ns16550_dt_match,
         .init = ns16550_uart_dt_init,
 DT_DEVICE_END
 
diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
index c4cd442..3df80cf 100644
--- a/xen/drivers/char/omap-uart.c
+++ b/xen/drivers/char/omap-uart.c
@@ -350,14 +350,14 @@ static int __init omap_uart_init(struct dt_device_node *dev,
     return 0;
 }
 
-static const char * const omap_uart_dt_compat[] __initconst =
+static const struct dt_device_match omap_uart_dt_match[] __initconst =
 {
-    "ti,omap4-uart",
-    NULL
+    DT_MATCH_COMPATIBLE("ti,omap4-uart"),
+    { /* sentinel */ },
 };
 
 DT_DEVICE_START(omap_uart, "OMAP UART", DEVICE_SERIAL)
-    .compatible = omap_uart_dt_compat,
+    .dt_match = omap_uart_dt_match,
     .init = omap_uart_init,
 DT_DEVICE_END
 
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index cc91224..e6ecf0b 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -269,14 +269,14 @@ static int __init pl011_uart_init(struct dt_device_node *dev,
     return 0;
 }
 
-static const char * const pl011_dt_compat[] __initconst =
+static const struct dt_device_match pl011_dt_match[] __initconst =
 {
-    "arm,pl011",
-    NULL
+    DT_MATCH_COMPATIBLE("arm,pl011"),
+    { /* sentinel */ },
 };
 
 DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
-        .compatible = pl011_dt_compat,
+        .dt_match = pl011_dt_match,
         .init = pl011_uart_init,
 DT_DEVICE_END
 
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index fdcd097..a2711a3 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -3,6 +3,10 @@
 
 #include <xen/init.h>
 
+struct dev_archdata {
+    void *iommu;    /* IOMMU private data */
+};
+
 struct dt_device_node;
 
 enum device_match
@@ -19,8 +23,8 @@ struct device_desc {
     const char *name;
     /* Device type */
     enum device_match type;
-    /* Array of device tree 'compatible' strings */
-    const char *const *compatible;
+    /* List of devices supported by this driver */
+    const struct dt_device_match *dt_match;
     /* Device initialization */
     int (*init)(struct dt_device_node *dev, const void *data);
 };
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 187dc46..73ca3cf 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -152,17 +152,12 @@
 #include <xen/irq.h>
 #include <asm-arm/vgic.h>
 
-#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_MATCH_GIC_V2                                             \
+    DT_MATCH_COMPATIBLE("arm,cortex-a15-gic"),                      \
+    DT_MATCH_COMPATIBLE("arm,cortex-a7-gic"),                       \
+    DT_MATCH_COMPATIBLE("arm,gic-400")
 
-#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)
-
-#define DT_COMPAT_GIC_V3             "arm,gic-v3"
-
-#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_V3)
+#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3")
 
 /*
  * GICv3 registers that needs to be saved/restored
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yR3-0004oV-BV; Tue, 16 Dec 2014 20:09:33 +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 1Y0yR1-0004nM-6c
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:32 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	46/90-22777-A7190945; Tue, 16 Dec 2014 20:09:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418760569!9589699!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3568 invoked from network); 16 Dec 2014 20:09:29 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:29 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so13488122wib.4
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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=dshB9d5U0zcsWf2ka1POEPTFDdGq+Ylr3zWcnMCfz8g=;
	b=bCW8uX2X9vlYmHngbII3ICr7GjU9XdEPFqbWOYFQ3dDwOhGBwktNLkgYWZpWZef9dJ
	sOcsJuavq17HDH0pzSMPcaWkE0RpW5WNc6AO6Fa3Z/2g5wL8oy5nervFqnSn8DK6edFR
	LWUH6J+CitsMIUYEoLwEKZW2SyN8dqn8BOo9fEOV06DYgZISzF3GQ+XNYHzPjD0HR950
	YHcrOj60g2kF9rZAdkY3F3d4CRiHBhTKrqx2UA00Tt9O6pzB5BPUHOTkVmQyxnWlx1p5
	vXtE271/ZX1EgigwT7tx1I+j+zEw2x0fx1mhHXKj2SvGz6JyaYZY9SvQZKfMJTBUeuIu
	zK1A==
X-Gm-Message-State: ALoCoQk94AmArR3T8HkxZNWNfC9c9gGRq2YfdIHkf4sAjamkhrct8hm1ln6/f5Wt6OL4xvFamXSp
X-Received: by 10.180.77.7 with SMTP id o7mr7549763wiw.81.1418760569099;
	Tue, 16 Dec 2014 12:09:29 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.27
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:27 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:48 +0000
Message-Id: <1418760534-18163-8-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way to
	describe 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

Currently, Xen is supporting PCI and Platform device (based on Device Tree).

While we don't support both at the same time: platform device for ARM
and PCI for x86, ARM will gain support on PCI soon.

Some drivers, such as IOMMU drivers, may handle PCI and platform device in
the same way. Only few lines of code differs.

Rather than requesting to provide 2 set of functions (one for PCI and
one for platform device), introduce a generic structure "device" which
is embedded in each specialized device.

At the same time replace any use of asm/device.h by xen/device.h. This
is required to be able to compile ARM correctly.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
CC: Jan Beulich <jbeulich@suse.com>
CC: Keir Fraser <keir@xen.org>
---
 xen/arch/arm/device.c               |  2 +-
 xen/arch/arm/domain_build.c         |  2 +-
 xen/arch/arm/gic-v2.c               |  3 +--
 xen/arch/arm/gic-v3.c               |  2 +-
 xen/arch/arm/gic.c                  |  2 +-
 xen/common/Makefile                 |  1 +
 xen/common/device.c                 | 21 +++++++++++++++++++
 xen/common/device_tree.c            |  1 +
 xen/drivers/char/dt-uart.c          |  4 ++--
 xen/drivers/char/exynos4210-uart.c  |  2 +-
 xen/drivers/char/ns16550.c          |  2 +-
 xen/drivers/char/omap-uart.c        |  2 +-
 xen/drivers/char/pl011.c            |  2 +-
 xen/drivers/passthrough/arm/iommu.c |  2 +-
 xen/drivers/passthrough/pci.c       |  2 ++
 xen/include/asm-arm/device.h        |  3 ++-
 xen/include/asm-x86/device.h        | 17 ++++++++++++++++
 xen/include/xen/device.h            | 40 +++++++++++++++++++++++++++++++++++++
 xen/include/xen/device_tree.h       | 13 ++++++++++++
 xen/include/xen/pci.h               | 12 +++++++++++
 20 files changed, 121 insertions(+), 14 deletions(-)
 create mode 100644 xen/common/device.c
 create mode 100644 xen/include/asm-x86/device.h
 create mode 100644 xen/include/xen/device.h

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 693b9af..de702ff 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -17,7 +17,7 @@
  * GNU General Public License for more details.
  */
 
-#include <asm/device.h>
+#include <xen/device.h>
 #include <xen/errno.h>
 #include <xen/lib.h>
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index de180d8..b701a2f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -9,10 +9,10 @@
 #include <asm/regs.h>
 #include <xen/errno.h>
 #include <xen/device_tree.h>
+#include <xen/device.h>
 #include <xen/libfdt/libfdt.h>
 #include <xen/guest_access.h>
 #include <xen/iocap.h>
-#include <asm/device.h>
 #include <asm/setup.h>
 #include <asm/platform.h>
 #include <asm/psci.h>
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index f149e09..048350b 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -27,12 +27,11 @@
 #include <xen/softirq.h>
 #include <xen/list.h>
 #include <xen/device_tree.h>
+#include <xen/device.h>
 #include <xen/libfdt/libfdt.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 #include <asm/platform.h>
-#include <asm/device.h>
-
 #include <asm/io.h>
 #include <asm/gic.h>
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 076aa62..c6d1876 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -31,12 +31,12 @@
 #include <xen/errno.h>
 #include <xen/delay.h>
 #include <xen/device_tree.h>
+#include <xen/device.h>
 #include <xen/sizes.h>
 #include <xen/libfdt/libfdt.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 #include <asm/io.h>
-#include <asm/device.h>
 #include <asm/gic.h>
 #include <asm/gic_v3_defs.h>
 #include <asm/cpufeature.h>
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index e7a1af5..d1ab6b5 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -27,10 +27,10 @@
 #include <xen/softirq.h>
 #include <xen/list.h>
 #include <xen/device_tree.h>
+#include <xen/device.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 #include <asm/platform.h>
-#include <asm/device.h>
 #include <asm/io.h>
 #include <asm/gic.h>
 #include <asm/vgic.h>
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 8391246..03ed719 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -2,6 +2,7 @@ obj-y += bitmap.o
 obj-y += core_parking.o
 obj-y += cpu.o
 obj-y += cpupool.o
+obj-y += device.o
 obj-$(HAS_DEVICE_TREE) += device_tree.o
 obj-y += domctl.o
 obj-y += domain.o
diff --git a/xen/common/device.c b/xen/common/device.c
new file mode 100644
index 0000000..3450f20
--- /dev/null
+++ b/xen/common/device.c
@@ -0,0 +1,21 @@
+#include <xen/types.h>
+#include <xen/device.h>
+
+void device_initialize(struct device *dev, enum device_type type)
+{
+    dev->type = type;
+
+#ifdef HAS_DEVICE_TREE
+    if ( type == DEV_DT )
+        dev->of_node = dev_to_dt(dev);
+#endif
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 34a1b9e..f471008 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1450,6 +1450,7 @@ static unsigned long __init unflatten_dt_node(const void *fdt,
             prev_pp = &pp->next;
 #endif
             np->name = pp->value;
+            device_initialize(&np->dev, DEV_DT);
             memcpy(pp->value, ps, sz - 1);
             ((char *)pp->value)[sz - 1] = 0;
             dt_dprintk("fixed up name for %s -> %s\n", pathp,
diff --git a/xen/drivers/char/dt-uart.c b/xen/drivers/char/dt-uart.c
index fa92b5c..01eced1 100644
--- a/xen/drivers/char/dt-uart.c
+++ b/xen/drivers/char/dt-uart.c
@@ -17,11 +17,11 @@
  * GNU General Public License for more details.
  */
 
-#include <asm/device.h>
-#include <asm/types.h>
+#include <xen/device.h>
 #include <xen/console.h>
 #include <xen/device_tree.h>
 #include <xen/serial.h>
+#include <asm/types.h>
 
 /*
  * Configure UART port with a string:
diff --git a/xen/drivers/char/exynos4210-uart.c b/xen/drivers/char/exynos4210-uart.c
index cba8729..75246e1 100644
--- a/xen/drivers/char/exynos4210-uart.c
+++ b/xen/drivers/char/exynos4210-uart.c
@@ -24,7 +24,7 @@
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/mm.h>
-#include <asm/device.h>
+#include <xen/device.h>
 #include <asm/exynos4210-uart.h>
 #include <asm/io.h>
 
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 161b251..6df3f95 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -25,7 +25,7 @@
 #include <xen/vmap.h>
 #include <asm/io.h>
 #ifdef HAS_DEVICE_TREE
-#include <asm/device.h>
+#include <xen/device.h>
 #endif
 #ifdef CONFIG_X86
 #include <asm/fixmap.h>
diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
index 16d1454..c4cd442 100644
--- a/xen/drivers/char/omap-uart.c
+++ b/xen/drivers/char/omap-uart.c
@@ -16,7 +16,7 @@
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/device_tree.h>
-#include <asm/device.h>
+#include <xen/device.h>
 #include <xen/errno.h>
 #include <xen/mm.h>
 #include <xen/vmap.h>
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..cc91224 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -23,8 +23,8 @@
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/device_tree.h>
+#include <xen/device.h>
 #include <xen/errno.h>
-#include <asm/device.h>
 #include <xen/mm.h>
 #include <xen/vmap.h>
 #include <asm/pl011-uart.h>
diff --git a/xen/drivers/passthrough/arm/iommu.c b/xen/drivers/passthrough/arm/iommu.c
index 3007b99..3e9303a 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -18,7 +18,7 @@
 #include <xen/lib.h>
 #include <xen/iommu.h>
 #include <xen/device_tree.h>
-#include <asm/device.h>
+#include <xen/device.h>
 
 static const struct iommu_ops *iommu_ops;
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..9fbd2a2 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -278,6 +278,8 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
     if ( !pdev )
         return NULL;
 
+    device_initialize(&pdev->dev, DEV_PCI);
+
     *(u16*) &pdev->seg = pseg->nr;
     *((u8*) &pdev->bus) = bus;
     *((u8*) &pdev->devfn) = devfn;
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 72a9028..fdcd097 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -2,7 +2,8 @@
 #define __ASM_ARM_DEVICE_H
 
 #include <xen/init.h>
-#include <xen/device_tree.h>
+
+struct dt_device_node;
 
 enum device_match
 {
diff --git a/xen/include/asm-x86/device.h b/xen/include/asm-x86/device.h
new file mode 100644
index 0000000..9d4c352
--- /dev/null
+++ b/xen/include/asm-x86/device.h
@@ -0,0 +1,17 @@
+#ifndef __ASM_X86_DEVICE_H
+#define __ASM_X86_DEVICE_H
+
+struct dev_archdata {
+    /* No device specific arch data */
+};
+
+#endif /* __ASM_X86_DEVICE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/device.h b/xen/include/xen/device.h
new file mode 100644
index 0000000..a9e20ad
--- /dev/null
+++ b/xen/include/xen/device.h
@@ -0,0 +1,40 @@
+#ifndef __XEN_DEVICE_H__
+#define __XEN_DEVICE_H__
+
+#include <asm/device.h>
+
+enum device_type
+{
+    DEV_PCI,
+    DEV_DT,
+};
+
+/* struct device - The basic device structure */
+struct device
+{
+    enum device_type type;
+#ifdef HAS_DEVICE_TREE
+    struct dt_device_node *of_node; /* Used by drivers imported from Linux */
+#endif
+    struct dev_archdata archdata;
+};
+
+#define dev_is_pci(dev) ((dev)->type == DEV_PCI)
+#define dev_is_dt(dev)  ((dev->type == DEV_DT)
+
+#ifdef HAS_DEVICE_TREE
+#include <xen/device_tree.h>
+#endif
+
+void device_initialize(struct device *dev, enum device_type type);
+
+#endif /* __XEN_DEVICE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 6502369..890d356 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -12,6 +12,8 @@
 
 #include <asm/byteorder.h>
 #include <public/xen.h>
+#include <xen/device.h>
+#include <xen/kernel.h>
 #include <xen/init.h>
 #include <xen/string.h>
 #include <xen/types.h>
@@ -80,8 +82,19 @@ struct dt_device_node {
     /* IOMMU specific fields */
     bool is_protected;
     struct list_head domain_list;
+
+    struct device dev;
 };
 
+#define dt_to_dev(dt_node)  (&(dt_node)->dev)
+
+static inline struct dt_device_node *dev_to_dt(struct device *dev)
+{
+    ASSERT(dev->type == DEV_DT);
+
+    return container_of(dev, struct dt_device_node, dev);
+}
+
 #define MAX_PHANDLE_ARGS 16
 struct dt_phandle_args {
     struct dt_device_node *np;
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 5f295f3..6ace79d 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -13,6 +13,7 @@
 #include <xen/irq.h>
 #include <xen/pci_regs.h>
 #include <xen/pfn.h>
+#include <xen/device.h>
 #include <asm/pci.h>
 
 /*
@@ -75,8 +76,19 @@ struct pci_dev {
 #define PT_FAULT_THRESHOLD 10
     } fault;
     u64 vf_rlen[6];
+
+    struct device dev;
 };
 
+#define pci_to_dev(pcidev)  (&(pcidev)->dev)
+
+static inline struct pci_dev *dev_to_pci(struct device *dev)
+{
+    ASSERT(dev->type == DEV_PCI);
+
+    return container_of(dev, struct pci_dev, dev);
+}
+
 #define for_each_pdev(domain, pdev) \
     list_for_each_entry(pdev, &(domain->arch.pdev_list), domain_list)
 
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yR4-0004pM-SD; Tue, 16 Dec 2014 20:09:34 +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 1Y0yR3-0004oF-9N
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:33 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	8B/48-23865-C7190945; Tue, 16 Dec 2014 20:09:32 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418760571!10107944!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3817 invoked from network); 16 Dec 2014 20:09:31 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:31 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so13440695wib.16
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09:31 -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=IpWq8nDRn7CvvN/tiBXqxoBcBpCCcYMqGBAv6BOOyw0=;
	b=BdWhNGj7fb0+Utg9dm8IU2DDAmIzTmTIU7wX4rCgUdldSDjaVerN2hZ4nnJVKtkhCQ
	NkWQKUQvzOUVY8DCP2YZbooyEHAAIBbi7sbJSJQsrsuBKyS9DxnVJFUUnw5hZoSRhekW
	TzNlhkrmFMor5OyzrF/YxOzzAOtSTQqAmn4/w2YhUXOjosR1zn5xyMucnBFUXJu3f4R7
	8M4ZQlQyGG1hBpb2iTT7jSGSm61fFTR6PNVqOJvsOIse+VFdIkYFtpLFg3SoW6Y56PM+
	ANSfDeK4o40lPhcLVB71eZe4knbTkjV1SSQZ7ZCq+uvW3coQy5MiHwQqjBGlzEjozZaZ
	nzag==
X-Gm-Message-State: ALoCoQksZGnTy809na7CTmKCrwkVUInj+2g5WJXEvr9/TdYnqsXYBA+Ujcx/xJ/Paxm+AyOOdg3t
X-Received: by 10.194.108.98 with SMTP id hj2mr65711698wjb.102.1418760571184; 
	Tue, 16 Dec 2014 12:09:31 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.29
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:29 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:49 +0000
Message-Id: <1418760534-18163-9-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: Kevin Tian <kevin.tian@intel.com>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	Jan Beulich <jbeulich@suse.com>, stefano.stabellini@citrix.com,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Yang Zhang <yang.z.zhang@intel.com>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
Subject: [Xen-devel] [PATCH for 4.6 08/13] xen/iommu: Consolidate device
	assignment ops into a single set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM, the way to assign device tree node is exactly the same as PCI.
Futhermore, all devices can be represented by a "struct device'.
Therefore there is no need to add separate ops.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
CC: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
CC: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Yang Zhang <yang.z.zhang@intel.com>
CC: Kevin Tian <kevin.tian@intel.com>
---
 xen/drivers/passthrough/amd/pci_amd_iommu.c | 14 +++++++++-----
 xen/drivers/passthrough/device_tree.c       |  5 +++--
 xen/drivers/passthrough/pci.c               | 20 +++++++++++---------
 xen/drivers/passthrough/vtd/iommu.c         | 19 ++++++++++++-------
 xen/include/xen/iommu.h                     | 18 +++++++-----------
 5 files changed, 42 insertions(+), 34 deletions(-)

diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index e83bb35..0af13fb 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -355,8 +355,9 @@ void amd_iommu_disable_domain_device(struct domain *domain,
 }
 
 static int reassign_device(struct domain *source, struct domain *target,
-                           u8 devfn, struct pci_dev *pdev)
+                           u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct amd_iommu *iommu;
     int bdf;
     struct hvm_iommu *t = domain_hvm_iommu(target);
@@ -394,8 +395,9 @@ static int reassign_device(struct domain *source, struct domain *target,
 }
 
 static int amd_iommu_assign_device(struct domain *d, u8 devfn,
-                                   struct pci_dev *pdev)
+                                   struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(pdev->seg);
     int bdf = PCI_BDF2(pdev->bus, devfn);
     int req_id = get_dma_requestor_id(pdev->seg, bdf);
@@ -410,7 +412,7 @@ static int amd_iommu_assign_device(struct domain *d, u8 devfn,
             ivrs_mappings[req_id].read_permission);
     }
 
-    return reassign_device(hardware_domain, d, devfn, pdev);
+    return reassign_device(hardware_domain, d, devfn, dev);
 }
 
 static void deallocate_next_page_table(struct page_info *pg, int level)
@@ -481,8 +483,9 @@ static void amd_iommu_domain_destroy(struct domain *d)
     amd_iommu_flush_all_pages(d);
 }
 
-static int amd_iommu_add_device(u8 devfn, struct pci_dev *pdev)
+static int amd_iommu_add_device(u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct amd_iommu *iommu;
     u16 bdf;
     if ( !pdev->domain )
@@ -503,8 +506,9 @@ static int amd_iommu_add_device(u8 devfn, struct pci_dev *pdev)
     return 0;
 }
 
-static int amd_iommu_remove_device(u8 devfn, struct pci_dev *pdev)
+static int amd_iommu_remove_device(u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct amd_iommu *iommu;
     u16 bdf;
     if ( !pdev->domain )
diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c
index 3e47df5..377d41d 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -41,7 +41,7 @@ int iommu_assign_dt_device(struct domain *d, struct dt_device_node *dev)
     if ( !list_empty(&dev->domain_list) )
         goto fail;
 
-    rc = hd->platform_ops->assign_dt_device(d, dev);
+    rc = hd->platform_ops->assign_device(d, 0, dt_to_dev(dev));
 
     if ( rc )
         goto fail;
@@ -68,7 +68,8 @@ int iommu_deassign_dt_device(struct domain *d, struct dt_device_node *dev)
 
     spin_lock(&dtdevs_lock);
 
-    rc = hd->platform_ops->reassign_dt_device(d, hardware_domain, dev);
+    rc = hd->platform_ops->reassign_device(d, hardware_domain,
+                                           0, dt_to_dev(dev));
     if ( rc )
         goto fail;
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 9fbd2a2..43ce5dc 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1256,7 +1256,7 @@ int iommu_add_device(struct pci_dev *pdev)
     if ( !iommu_enabled || !hd->platform_ops )
         return 0;
 
-    rc = hd->platform_ops->add_device(pdev->devfn, pdev);
+    rc = hd->platform_ops->add_device(pdev->devfn, pci_to_dev(pdev));
     if ( rc || !pdev->phantom_stride )
         return rc;
 
@@ -1265,7 +1265,7 @@ int iommu_add_device(struct pci_dev *pdev)
         devfn += pdev->phantom_stride;
         if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
             return 0;
-        rc = hd->platform_ops->add_device(devfn, pdev);
+        rc = hd->platform_ops->add_device(devfn, pci_to_dev(pdev));
         if ( rc )
             printk(XENLOG_WARNING "IOMMU: add %04x:%02x:%02x.%u failed (%d)\n",
                    pdev->seg, pdev->bus, PCI_SLOT(devfn), PCI_FUNC(devfn), rc);
@@ -1286,7 +1286,7 @@ int iommu_enable_device(struct pci_dev *pdev)
          !hd->platform_ops->enable_device )
         return 0;
 
-    return hd->platform_ops->enable_device(pdev);
+    return hd->platform_ops->enable_device(pci_to_dev(pdev));
 }
 
 int iommu_remove_device(struct pci_dev *pdev)
@@ -1308,7 +1308,7 @@ int iommu_remove_device(struct pci_dev *pdev)
         devfn += pdev->phantom_stride;
         if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
             break;
-        rc = hd->platform_ops->remove_device(devfn, pdev);
+        rc = hd->platform_ops->remove_device(devfn, pci_to_dev(pdev));
         if ( !rc )
             continue;
 
@@ -1317,7 +1317,7 @@ int iommu_remove_device(struct pci_dev *pdev)
         return rc;
     }
 
-    return hd->platform_ops->remove_device(pdev->devfn, pdev);
+    return hd->platform_ops->remove_device(pdev->devfn, pci_to_dev(pdev));
 }
 
 /*
@@ -1378,7 +1378,7 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
 
     pdev->fault.count = 0;
 
-    if ( (rc = hd->platform_ops->assign_device(d, devfn, pdev)) )
+    if ( (rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev))) )
         goto done;
 
     for ( ; pdev->phantom_stride; rc = 0 )
@@ -1386,7 +1386,7 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
         devfn += pdev->phantom_stride;
         if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
             break;
-        rc = hd->platform_ops->assign_device(d, devfn, pdev);
+        rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev));
         if ( rc )
             printk(XENLOG_G_WARNING "d%d: assign %04x:%02x:%02x.%u failed (%d)\n",
                    d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
@@ -1421,7 +1421,8 @@ int deassign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
         devfn += pdev->phantom_stride;
         if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
             break;
-        ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn, pdev);
+        ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn,
+                                                pci_to_dev(pdev));
         if ( !ret )
             continue;
 
@@ -1431,7 +1432,8 @@ int deassign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
     }
 
     devfn = pdev->devfn;
-    ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn, pdev);
+    ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn,
+                                            pci_to_dev(pdev));
     if ( ret )
     {
         dprintk(XENLOG_G_ERR,
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index 19d8165..213a471 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1875,8 +1875,9 @@ static int rmrr_identity_mapping(struct domain *d, bool_t map,
     return 0;
 }
 
-static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
+static int intel_iommu_add_device(u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct acpi_rmrr_unit *rmrr;
     u16 bdf;
     int ret, i;
@@ -1910,8 +1911,9 @@ static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
     return 0;
 }
 
-static int intel_iommu_enable_device(struct pci_dev *pdev)
+static int intel_iommu_enable_device(struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
     int ret = drhd ? ats_device(pdev, drhd) : -ENODEV;
 
@@ -1925,8 +1927,9 @@ static int intel_iommu_enable_device(struct pci_dev *pdev)
     return ret >= 0 ? 0 : ret;
 }
 
-static int intel_iommu_remove_device(u8 devfn, struct pci_dev *pdev)
+static int intel_iommu_remove_device(u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct acpi_rmrr_unit *rmrr;
     u16 bdf;
     int i;
@@ -2212,8 +2215,9 @@ int __init intel_vtd_setup(void)
 static int reassign_device_ownership(
     struct domain *source,
     struct domain *target,
-    u8 devfn, struct pci_dev *pdev)
+    u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     int ret;
 
     /*
@@ -2266,8 +2270,9 @@ static int reassign_device_ownership(
 }
 
 static int intel_iommu_assign_device(
-    struct domain *d, u8 devfn, struct pci_dev *pdev)
+    struct domain *d, u8 devfn, struct device *dev)
 {
+    struct pci_dev *pdev = dev_to_pci(dev);
     struct acpi_rmrr_unit *rmrr;
     int ret = 0, i;
     u16 bdf, seg;
@@ -2276,7 +2281,7 @@ static int intel_iommu_assign_device(
     if ( list_empty(&acpi_drhd_units) )
         return -ENODEV;
 
-    ret = reassign_device_ownership(hardware_domain, d, devfn, pdev);
+    ret = reassign_device_ownership(hardware_domain, d, devfn, dev);
     if ( ret )
         return ret;
 
@@ -2298,7 +2303,7 @@ static int intel_iommu_assign_device(
             ret = rmrr_identity_mapping(d, 1, rmrr);
             if ( ret )
             {
-                reassign_device_ownership(d, hardware_domain, devfn, pdev);
+                reassign_device_ownership(d, hardware_domain, devfn, dev);
                 printk(XENLOG_G_ERR VTDPREFIX
                        " cannot map reserved region (%"PRIx64",%"PRIx64"] for Dom%d (%d)\n",
                        rmrr->base_address, rmrr->end_address,
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 8eb764a..d0f99ef 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -23,6 +23,7 @@
 #include <xen/init.h>
 #include <xen/spinlock.h>
 #include <xen/pci.h>
+#include <xen/device.h>
 #include <public/hvm/ioreq.h>
 #include <public/domctl.h>
 #include <asm/iommu.h>
@@ -123,22 +124,17 @@ struct page_info;
 struct iommu_ops {
     int (*init)(struct domain *d);
     void (*hwdom_init)(struct domain *d);
-#ifdef HAS_PCI
-    int (*add_device)(u8 devfn, struct pci_dev *);
-    int (*enable_device)(struct pci_dev *pdev);
-    int (*remove_device)(u8 devfn, struct pci_dev *);
-    int (*assign_device)(struct domain *, u8 devfn, struct pci_dev *);
+    int (*add_device)(u8 devfn, struct device *);
+    int (*enable_device)(struct device *dev);
+    int (*remove_device)(u8 devfn, struct device *);
+    int (*assign_device)(struct domain *, u8 devfn, struct device *);
     int (*reassign_device)(struct domain *s, struct domain *t,
-			   u8 devfn, struct pci_dev *);
+                           u8 devfn, struct device *);
+#ifdef HAS_PCI
     int (*get_device_group_id)(u16 seg, u8 bus, u8 devfn);
     int (*update_ire_from_msi)(struct msi_desc *msi_desc, struct msi_msg *msg);
     void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct msi_msg *msg);
 #endif /* HAS_PCI */
-#ifdef HAS_DEVICE_TREE
-    int (*assign_dt_device)(struct domain *d, const struct dt_device_node *dev);
-    int (*reassign_dt_device)(struct domain *s, struct domain *t,
-                              const struct dt_device_node *dev);
-#endif
 
     void (*teardown)(struct domain *d);
     int (*map_page)(struct domain *d, unsigned long gfn, unsigned long mfn,
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yR9-0004sX-Tp; Tue, 16 Dec 2014 20:09:39 +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 1Y0yR8-0004qw-B0
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:38 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	DF/51-28865-18190945; Tue, 16 Dec 2014 20:09:37 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418760574!10358407!1
X-Originating-IP: [209.85.212.173]
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 2561 invoked from network); 16 Dec 2014 20:09:34 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:34 -0000
Received: by mail-wi0-f173.google.com with SMTP id r20so13484364wiv.12
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=wjZH/KY85lS0vsvPzCZjq5MOCd5nZXy6j5mmcWZJrgA=;
	b=DNFzL2JOFcoDjYn2xK8Mr52HiKisCKhrdnFgsCpl2k+brm+PhsZTzuk1X1SRpImAy1
	kkHltGhFkj3opJjoYqzMI/2bFvWnWAAaIQD2CnrEqD7sZ7oQLiKAfbdmSYCcFWoyKZYk
	nSl/xPph4zcz7FumKRPk1DCSzLf/OEIZqtfubPgEToMOkG5oGIAllt2XE5aH3rY/UkR8
	zA5MlXx6muvcBxIbxeH6QY5U/I6P7WX4AXr1AYL5yjWbCaPpqvQ317N8Ie7GEq+bYHp6
	HlInqevqoeRWbvmoA4Eqp9UxnIsZE5y+UvnNModoAx/6cv9D91x/cAD3gPCrRjTcPwq0
	sxcg==
X-Gm-Message-State: ALoCoQkBaeInmOku1mo+Pnw2nXdmfkRhjsKnETfZXazOObb8b3qua9XGnfYvY2cyglJkLWoJ6XbY
X-Received: by 10.194.5.227 with SMTP id v3mr66328438wjv.63.1418760574585;
	Tue, 16 Dec 2014 12:09:34 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.32
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:33 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:51 +0000
Message-Id: <1418760534-18163-11-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 10/13] xen/iommu: arm: Import the SMMU
	driver from Linux
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3.

It's a basic copy of the Linux SMMU drivers code. No Xen code has yet been added
and not build.

Compare to the previous drivers it gains support of PCI. Though it will
need a bit of plumbing for Xen.

Signed-of-by: Julien Grall <julien.grall@linaro.org>
---
 xen/drivers/passthrough/arm/smmu.c | 2193 ++++++++++++++++++++++++++++++++++++
 1 file changed, 2193 insertions(+)
 create mode 100644 xen/drivers/passthrough/arm/smmu.c

diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
new file mode 100644
index 0000000..6cd47b7
--- /dev/null
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -0,0 +1,2193 @@
+/*
+ * IOMMU API for ARM architected SMMU implementations.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) 2013 ARM Limited
+ *
+ * Author: Will Deacon <will.deacon@arm.com>
+ *
+ * This driver currently supports:
+ *	- SMMUv1 and v2 implementations
+ *	- Stream-matching and stream-indexing
+ *	- v7/v8 long-descriptor format
+ *	- Non-secure access to the SMMU
+ *	- 4k and 64k pages, with contiguous pte hints.
+ *	- Up to 48-bit addressing (dependent on VA_BITS)
+ *	- Context fault reporting
+ */
+
+#define pr_fmt(fmt) "arm-smmu: " fmt
+
+#include <linux/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iommu.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+
+#include <linux/amba/bus.h>
+
+#include <asm/pgalloc.h>
+
+/* Maximum number of stream IDs assigned to a single device */
+#define MAX_MASTER_STREAMIDS		MAX_PHANDLE_ARGS
+
+/* Maximum number of context banks per SMMU */
+#define ARM_SMMU_MAX_CBS		128
+
+/* Maximum number of mapping groups per SMMU */
+#define ARM_SMMU_MAX_SMRS		128
+
+/* SMMU global address space */
+#define ARM_SMMU_GR0(smmu)		((smmu)->base)
+#define ARM_SMMU_GR1(smmu)		((smmu)->base + (1 << (smmu)->pgshift))
+
+/*
+ * SMMU global address space with conditional offset to access secure
+ * aliases of non-secure registers (e.g. nsCR0: 0x400, nsGFSR: 0x448,
+ * nsGFSYNR0: 0x450)
+ */
+#define ARM_SMMU_GR0_NS(smmu)						\
+	((smmu)->base +							\
+		((smmu->options & ARM_SMMU_OPT_SECURE_CFG_ACCESS)	\
+			? 0x400 : 0))
+
+/* Page table bits */
+#define ARM_SMMU_PTE_XN			(((pteval_t)3) << 53)
+#define ARM_SMMU_PTE_CONT		(((pteval_t)1) << 52)
+#define ARM_SMMU_PTE_AF			(((pteval_t)1) << 10)
+#define ARM_SMMU_PTE_SH_NS		(((pteval_t)0) << 8)
+#define ARM_SMMU_PTE_SH_OS		(((pteval_t)2) << 8)
+#define ARM_SMMU_PTE_SH_IS		(((pteval_t)3) << 8)
+#define ARM_SMMU_PTE_PAGE		(((pteval_t)3) << 0)
+
+#if PAGE_SIZE == SZ_4K
+#define ARM_SMMU_PTE_CONT_ENTRIES	16
+#elif PAGE_SIZE == SZ_64K
+#define ARM_SMMU_PTE_CONT_ENTRIES	32
+#else
+#define ARM_SMMU_PTE_CONT_ENTRIES	1
+#endif
+
+#define ARM_SMMU_PTE_CONT_SIZE		(PAGE_SIZE * ARM_SMMU_PTE_CONT_ENTRIES)
+#define ARM_SMMU_PTE_CONT_MASK		(~(ARM_SMMU_PTE_CONT_SIZE - 1))
+
+/* Stage-1 PTE */
+#define ARM_SMMU_PTE_AP_UNPRIV		(((pteval_t)1) << 6)
+#define ARM_SMMU_PTE_AP_RDONLY		(((pteval_t)2) << 6)
+#define ARM_SMMU_PTE_ATTRINDX_SHIFT	2
+#define ARM_SMMU_PTE_nG			(((pteval_t)1) << 11)
+
+/* Stage-2 PTE */
+#define ARM_SMMU_PTE_HAP_FAULT		(((pteval_t)0) << 6)
+#define ARM_SMMU_PTE_HAP_READ		(((pteval_t)1) << 6)
+#define ARM_SMMU_PTE_HAP_WRITE		(((pteval_t)2) << 6)
+#define ARM_SMMU_PTE_MEMATTR_OIWB	(((pteval_t)0xf) << 2)
+#define ARM_SMMU_PTE_MEMATTR_NC		(((pteval_t)0x5) << 2)
+#define ARM_SMMU_PTE_MEMATTR_DEV	(((pteval_t)0x1) << 2)
+
+/* Configuration registers */
+#define ARM_SMMU_GR0_sCR0		0x0
+#define sCR0_CLIENTPD			(1 << 0)
+#define sCR0_GFRE			(1 << 1)
+#define sCR0_GFIE			(1 << 2)
+#define sCR0_GCFGFRE			(1 << 4)
+#define sCR0_GCFGFIE			(1 << 5)
+#define sCR0_USFCFG			(1 << 10)
+#define sCR0_VMIDPNE			(1 << 11)
+#define sCR0_PTM			(1 << 12)
+#define sCR0_FB				(1 << 13)
+#define sCR0_BSU_SHIFT			14
+#define sCR0_BSU_MASK			0x3
+
+/* Identification registers */
+#define ARM_SMMU_GR0_ID0		0x20
+#define ARM_SMMU_GR0_ID1		0x24
+#define ARM_SMMU_GR0_ID2		0x28
+#define ARM_SMMU_GR0_ID3		0x2c
+#define ARM_SMMU_GR0_ID4		0x30
+#define ARM_SMMU_GR0_ID5		0x34
+#define ARM_SMMU_GR0_ID6		0x38
+#define ARM_SMMU_GR0_ID7		0x3c
+#define ARM_SMMU_GR0_sGFSR		0x48
+#define ARM_SMMU_GR0_sGFSYNR0		0x50
+#define ARM_SMMU_GR0_sGFSYNR1		0x54
+#define ARM_SMMU_GR0_sGFSYNR2		0x58
+#define ARM_SMMU_GR0_PIDR0		0xfe0
+#define ARM_SMMU_GR0_PIDR1		0xfe4
+#define ARM_SMMU_GR0_PIDR2		0xfe8
+
+#define ID0_S1TS			(1 << 30)
+#define ID0_S2TS			(1 << 29)
+#define ID0_NTS				(1 << 28)
+#define ID0_SMS				(1 << 27)
+#define ID0_PTFS_SHIFT			24
+#define ID0_PTFS_MASK			0x2
+#define ID0_PTFS_V8_ONLY		0x2
+#define ID0_CTTW			(1 << 14)
+#define ID0_NUMIRPT_SHIFT		16
+#define ID0_NUMIRPT_MASK		0xff
+#define ID0_NUMSIDB_SHIFT		9
+#define ID0_NUMSIDB_MASK		0xf
+#define ID0_NUMSMRG_SHIFT		0
+#define ID0_NUMSMRG_MASK		0xff
+
+#define ID1_PAGESIZE			(1 << 31)
+#define ID1_NUMPAGENDXB_SHIFT		28
+#define ID1_NUMPAGENDXB_MASK		7
+#define ID1_NUMS2CB_SHIFT		16
+#define ID1_NUMS2CB_MASK		0xff
+#define ID1_NUMCB_SHIFT			0
+#define ID1_NUMCB_MASK			0xff
+
+#define ID2_OAS_SHIFT			4
+#define ID2_OAS_MASK			0xf
+#define ID2_IAS_SHIFT			0
+#define ID2_IAS_MASK			0xf
+#define ID2_UBS_SHIFT			8
+#define ID2_UBS_MASK			0xf
+#define ID2_PTFS_4K			(1 << 12)
+#define ID2_PTFS_16K			(1 << 13)
+#define ID2_PTFS_64K			(1 << 14)
+
+#define PIDR2_ARCH_SHIFT		4
+#define PIDR2_ARCH_MASK			0xf
+
+/* Global TLB invalidation */
+#define ARM_SMMU_GR0_STLBIALL		0x60
+#define ARM_SMMU_GR0_TLBIVMID		0x64
+#define ARM_SMMU_GR0_TLBIALLNSNH	0x68
+#define ARM_SMMU_GR0_TLBIALLH		0x6c
+#define ARM_SMMU_GR0_sTLBGSYNC		0x70
+#define ARM_SMMU_GR0_sTLBGSTATUS	0x74
+#define sTLBGSTATUS_GSACTIVE		(1 << 0)
+#define TLB_LOOP_TIMEOUT		1000000	/* 1s! */
+
+/* Stream mapping registers */
+#define ARM_SMMU_GR0_SMR(n)		(0x800 + ((n) << 2))
+#define SMR_VALID			(1 << 31)
+#define SMR_MASK_SHIFT			16
+#define SMR_MASK_MASK			0x7fff
+#define SMR_ID_SHIFT			0
+#define SMR_ID_MASK			0x7fff
+
+#define ARM_SMMU_GR0_S2CR(n)		(0xc00 + ((n) << 2))
+#define S2CR_CBNDX_SHIFT		0
+#define S2CR_CBNDX_MASK			0xff
+#define S2CR_TYPE_SHIFT			16
+#define S2CR_TYPE_MASK			0x3
+#define S2CR_TYPE_TRANS			(0 << S2CR_TYPE_SHIFT)
+#define S2CR_TYPE_BYPASS		(1 << S2CR_TYPE_SHIFT)
+#define S2CR_TYPE_FAULT			(2 << S2CR_TYPE_SHIFT)
+
+/* Context bank attribute registers */
+#define ARM_SMMU_GR1_CBAR(n)		(0x0 + ((n) << 2))
+#define CBAR_VMID_SHIFT			0
+#define CBAR_VMID_MASK			0xff
+#define CBAR_S1_BPSHCFG_SHIFT		8
+#define CBAR_S1_BPSHCFG_MASK		3
+#define CBAR_S1_BPSHCFG_NSH		3
+#define CBAR_S1_MEMATTR_SHIFT		12
+#define CBAR_S1_MEMATTR_MASK		0xf
+#define CBAR_S1_MEMATTR_WB		0xf
+#define CBAR_TYPE_SHIFT			16
+#define CBAR_TYPE_MASK			0x3
+#define CBAR_TYPE_S2_TRANS		(0 << CBAR_TYPE_SHIFT)
+#define CBAR_TYPE_S1_TRANS_S2_BYPASS	(1 << CBAR_TYPE_SHIFT)
+#define CBAR_TYPE_S1_TRANS_S2_FAULT	(2 << CBAR_TYPE_SHIFT)
+#define CBAR_TYPE_S1_TRANS_S2_TRANS	(3 << CBAR_TYPE_SHIFT)
+#define CBAR_IRPTNDX_SHIFT		24
+#define CBAR_IRPTNDX_MASK		0xff
+
+#define ARM_SMMU_GR1_CBA2R(n)		(0x800 + ((n) << 2))
+#define CBA2R_RW64_32BIT		(0 << 0)
+#define CBA2R_RW64_64BIT		(1 << 0)
+
+/* Translation context bank */
+#define ARM_SMMU_CB_BASE(smmu)		((smmu)->base + ((smmu)->size >> 1))
+#define ARM_SMMU_CB(smmu, n)		((n) * (1 << (smmu)->pgshift))
+
+#define ARM_SMMU_CB_SCTLR		0x0
+#define ARM_SMMU_CB_RESUME		0x8
+#define ARM_SMMU_CB_TTBCR2		0x10
+#define ARM_SMMU_CB_TTBR0_LO		0x20
+#define ARM_SMMU_CB_TTBR0_HI		0x24
+#define ARM_SMMU_CB_TTBCR		0x30
+#define ARM_SMMU_CB_S1_MAIR0		0x38
+#define ARM_SMMU_CB_FSR			0x58
+#define ARM_SMMU_CB_FAR_LO		0x60
+#define ARM_SMMU_CB_FAR_HI		0x64
+#define ARM_SMMU_CB_FSYNR0		0x68
+#define ARM_SMMU_CB_S1_TLBIASID		0x610
+
+#define SCTLR_S1_ASIDPNE		(1 << 12)
+#define SCTLR_CFCFG			(1 << 7)
+#define SCTLR_CFIE			(1 << 6)
+#define SCTLR_CFRE			(1 << 5)
+#define SCTLR_E				(1 << 4)
+#define SCTLR_AFE			(1 << 2)
+#define SCTLR_TRE			(1 << 1)
+#define SCTLR_M				(1 << 0)
+#define SCTLR_EAE_SBOP			(SCTLR_AFE | SCTLR_TRE)
+
+#define RESUME_RETRY			(0 << 0)
+#define RESUME_TERMINATE		(1 << 0)
+
+#define TTBCR_EAE			(1 << 31)
+
+#define TTBCR_PASIZE_SHIFT		16
+#define TTBCR_PASIZE_MASK		0x7
+
+#define TTBCR_TG0_4K			(0 << 14)
+#define TTBCR_TG0_64K			(1 << 14)
+
+#define TTBCR_SH0_SHIFT			12
+#define TTBCR_SH0_MASK			0x3
+#define TTBCR_SH_NS			0
+#define TTBCR_SH_OS			2
+#define TTBCR_SH_IS			3
+
+#define TTBCR_ORGN0_SHIFT		10
+#define TTBCR_IRGN0_SHIFT		8
+#define TTBCR_RGN_MASK			0x3
+#define TTBCR_RGN_NC			0
+#define TTBCR_RGN_WBWA			1
+#define TTBCR_RGN_WT			2
+#define TTBCR_RGN_WB			3
+
+#define TTBCR_SL0_SHIFT			6
+#define TTBCR_SL0_MASK			0x3
+#define TTBCR_SL0_LVL_2			0
+#define TTBCR_SL0_LVL_1			1
+
+#define TTBCR_T1SZ_SHIFT		16
+#define TTBCR_T0SZ_SHIFT		0
+#define TTBCR_SZ_MASK			0xf
+
+#define TTBCR2_SEP_SHIFT		15
+#define TTBCR2_SEP_MASK			0x7
+
+#define TTBCR2_PASIZE_SHIFT		0
+#define TTBCR2_PASIZE_MASK		0x7
+
+/* Common definitions for PASize and SEP fields */
+#define TTBCR2_ADDR_32			0
+#define TTBCR2_ADDR_36			1
+#define TTBCR2_ADDR_40			2
+#define TTBCR2_ADDR_42			3
+#define TTBCR2_ADDR_44			4
+#define TTBCR2_ADDR_48			5
+
+#define TTBRn_HI_ASID_SHIFT		16
+
+#define MAIR_ATTR_SHIFT(n)		((n) << 3)
+#define MAIR_ATTR_MASK			0xff
+#define MAIR_ATTR_DEVICE		0x04
+#define MAIR_ATTR_NC			0x44
+#define MAIR_ATTR_WBRWA			0xff
+#define MAIR_ATTR_IDX_NC		0
+#define MAIR_ATTR_IDX_CACHE		1
+#define MAIR_ATTR_IDX_DEV		2
+
+#define FSR_MULTI			(1 << 31)
+#define FSR_SS				(1 << 30)
+#define FSR_UUT				(1 << 8)
+#define FSR_ASF				(1 << 7)
+#define FSR_TLBLKF			(1 << 6)
+#define FSR_TLBMCF			(1 << 5)
+#define FSR_EF				(1 << 4)
+#define FSR_PF				(1 << 3)
+#define FSR_AFF				(1 << 2)
+#define FSR_TF				(1 << 1)
+
+#define FSR_IGN				(FSR_AFF | FSR_ASF | \
+					 FSR_TLBMCF | FSR_TLBLKF)
+#define FSR_FAULT			(FSR_MULTI | FSR_SS | FSR_UUT | \
+					 FSR_EF | FSR_PF | FSR_TF | FSR_IGN)
+
+#define FSYNR0_WNR			(1 << 4)
+
+static int force_stage;
+module_param_named(force_stage, force_stage, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(force_stage,
+	"Force SMMU mappings to be installed at a particular stage of translation. A value of '1' or '2' forces the corresponding stage. All other values are ignored (i.e. no stage is forced). Note that selecting a specific stage will disable support for nested translation.");
+
+enum arm_smmu_arch_version {
+	ARM_SMMU_V1 = 1,
+	ARM_SMMU_V2,
+};
+
+struct arm_smmu_smr {
+	u8				idx;
+	u16				mask;
+	u16				id;
+};
+
+struct arm_smmu_master_cfg {
+	int				num_streamids;
+	u16				streamids[MAX_MASTER_STREAMIDS];
+	struct arm_smmu_smr		*smrs;
+};
+
+struct arm_smmu_master {
+	struct device_node		*of_node;
+	struct rb_node			node;
+	struct arm_smmu_master_cfg	cfg;
+};
+
+struct arm_smmu_device {
+	struct device			*dev;
+
+	void __iomem			*base;
+	unsigned long			size;
+	unsigned long			pgshift;
+
+#define ARM_SMMU_FEAT_COHERENT_WALK	(1 << 0)
+#define ARM_SMMU_FEAT_STREAM_MATCH	(1 << 1)
+#define ARM_SMMU_FEAT_TRANS_S1		(1 << 2)
+#define ARM_SMMU_FEAT_TRANS_S2		(1 << 3)
+#define ARM_SMMU_FEAT_TRANS_NESTED	(1 << 4)
+	u32				features;
+
+#define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
+	u32				options;
+	enum arm_smmu_arch_version	version;
+
+	u32				num_context_banks;
+	u32				num_s2_context_banks;
+	DECLARE_BITMAP(context_map, ARM_SMMU_MAX_CBS);
+	atomic_t			irptndx;
+
+	u32				num_mapping_groups;
+	DECLARE_BITMAP(smr_map, ARM_SMMU_MAX_SMRS);
+
+	unsigned long			s1_input_size;
+	unsigned long			s1_output_size;
+	unsigned long			s2_input_size;
+	unsigned long			s2_output_size;
+
+	u32				num_global_irqs;
+	u32				num_context_irqs;
+	unsigned int			*irqs;
+
+	struct list_head		list;
+	struct rb_root			masters;
+};
+
+struct arm_smmu_cfg {
+	u8				cbndx;
+	u8				irptndx;
+	u32				cbar;
+	pgd_t				*pgd;
+};
+#define INVALID_IRPTNDX			0xff
+
+#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
+#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
+
+enum arm_smmu_domain_stage {
+	ARM_SMMU_DOMAIN_S1 = 0,
+	ARM_SMMU_DOMAIN_S2,
+	ARM_SMMU_DOMAIN_NESTED,
+};
+
+struct arm_smmu_domain {
+	struct arm_smmu_device		*smmu;
+	struct arm_smmu_cfg		cfg;
+	enum arm_smmu_domain_stage	stage;
+	spinlock_t			lock;
+};
+
+static DEFINE_SPINLOCK(arm_smmu_devices_lock);
+static LIST_HEAD(arm_smmu_devices);
+
+struct arm_smmu_option_prop {
+	u32 opt;
+	const char *prop;
+};
+
+static struct arm_smmu_option_prop arm_smmu_options[] = {
+	{ ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
+	{ 0, NULL},
+};
+
+static void parse_driver_options(struct arm_smmu_device *smmu)
+{
+	int i = 0;
+
+	do {
+		if (of_property_read_bool(smmu->dev->of_node,
+						arm_smmu_options[i].prop)) {
+			smmu->options |= arm_smmu_options[i].opt;
+			dev_notice(smmu->dev, "option %s\n",
+				arm_smmu_options[i].prop);
+		}
+	} while (arm_smmu_options[++i].opt);
+}
+
+static struct device_node *dev_get_dev_node(struct device *dev)
+{
+	if (dev_is_pci(dev)) {
+		struct pci_bus *bus = to_pci_dev(dev)->bus;
+
+		while (!pci_is_root_bus(bus))
+			bus = bus->parent;
+		return bus->bridge->parent->of_node;
+	}
+
+	return dev->of_node;
+}
+
+static struct arm_smmu_master *find_smmu_master(struct arm_smmu_device *smmu,
+						struct device_node *dev_node)
+{
+	struct rb_node *node = smmu->masters.rb_node;
+
+	while (node) {
+		struct arm_smmu_master *master;
+
+		master = container_of(node, struct arm_smmu_master, node);
+
+		if (dev_node < master->of_node)
+			node = node->rb_left;
+		else if (dev_node > master->of_node)
+			node = node->rb_right;
+		else
+			return master;
+	}
+
+	return NULL;
+}
+
+static struct arm_smmu_master_cfg *
+find_smmu_master_cfg(struct device *dev)
+{
+	struct arm_smmu_master_cfg *cfg = NULL;
+	struct iommu_group *group = iommu_group_get(dev);
+
+	if (group) {
+		cfg = iommu_group_get_iommudata(group);
+		iommu_group_put(group);
+	}
+
+	return cfg;
+}
+
+static int insert_smmu_master(struct arm_smmu_device *smmu,
+			      struct arm_smmu_master *master)
+{
+	struct rb_node **new, *parent;
+
+	new = &smmu->masters.rb_node;
+	parent = NULL;
+	while (*new) {
+		struct arm_smmu_master *this
+			= container_of(*new, struct arm_smmu_master, node);
+
+		parent = *new;
+		if (master->of_node < this->of_node)
+			new = &((*new)->rb_left);
+		else if (master->of_node > this->of_node)
+			new = &((*new)->rb_right);
+		else
+			return -EEXIST;
+	}
+
+	rb_link_node(&master->node, parent, new);
+	rb_insert_color(&master->node, &smmu->masters);
+	return 0;
+}
+
+static int register_smmu_master(struct arm_smmu_device *smmu,
+				struct device *dev,
+				struct of_phandle_args *masterspec)
+{
+	int i;
+	struct arm_smmu_master *master;
+
+	master = find_smmu_master(smmu, masterspec->np);
+	if (master) {
+		dev_err(dev,
+			"rejecting multiple registrations for master device %s\n",
+			masterspec->np->name);
+		return -EBUSY;
+	}
+
+	if (masterspec->args_count > MAX_MASTER_STREAMIDS) {
+		dev_err(dev,
+			"reached maximum number (%d) of stream IDs for master device %s\n",
+			MAX_MASTER_STREAMIDS, masterspec->np->name);
+		return -ENOSPC;
+	}
+
+	master = devm_kzalloc(dev, sizeof(*master), GFP_KERNEL);
+	if (!master)
+		return -ENOMEM;
+
+	master->of_node			= masterspec->np;
+	master->cfg.num_streamids	= masterspec->args_count;
+
+	for (i = 0; i < master->cfg.num_streamids; ++i) {
+		u16 streamid = masterspec->args[i];
+
+		if (!(smmu->features & ARM_SMMU_FEAT_STREAM_MATCH) &&
+		     (streamid >= smmu->num_mapping_groups)) {
+			dev_err(dev,
+				"stream ID for master device %s greater than maximum allowed (%d)\n",
+				masterspec->np->name, smmu->num_mapping_groups);
+			return -ERANGE;
+		}
+		master->cfg.streamids[i] = streamid;
+	}
+	return insert_smmu_master(smmu, master);
+}
+
+static struct arm_smmu_device *find_smmu_for_device(struct device *dev)
+{
+	struct arm_smmu_device *smmu;
+	struct arm_smmu_master *master = NULL;
+	struct device_node *dev_node = dev_get_dev_node(dev);
+
+	spin_lock(&arm_smmu_devices_lock);
+	list_for_each_entry(smmu, &arm_smmu_devices, list) {
+		master = find_smmu_master(smmu, dev_node);
+		if (master)
+			break;
+	}
+	spin_unlock(&arm_smmu_devices_lock);
+
+	return master ? smmu : NULL;
+}
+
+static int __arm_smmu_alloc_bitmap(unsigned long *map, int start, int end)
+{
+	int idx;
+
+	do {
+		idx = find_next_zero_bit(map, end, start);
+		if (idx == end)
+			return -ENOSPC;
+	} while (test_and_set_bit(idx, map));
+
+	return idx;
+}
+
+static void __arm_smmu_free_bitmap(unsigned long *map, int idx)
+{
+	clear_bit(idx, map);
+}
+
+/* Wait for any pending TLB invalidations to complete */
+static void arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
+{
+	int count = 0;
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+
+	writel_relaxed(0, gr0_base + ARM_SMMU_GR0_sTLBGSYNC);
+	while (readl_relaxed(gr0_base + ARM_SMMU_GR0_sTLBGSTATUS)
+	       & sTLBGSTATUS_GSACTIVE) {
+		cpu_relax();
+		if (++count == TLB_LOOP_TIMEOUT) {
+			dev_err_ratelimited(smmu->dev,
+			"TLB sync timed out -- SMMU may be deadlocked\n");
+			return;
+		}
+		udelay(1);
+	}
+}
+
+static void arm_smmu_tlb_inv_context(struct arm_smmu_domain *smmu_domain)
+{
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	void __iomem *base = ARM_SMMU_GR0(smmu);
+	bool stage1 = cfg->cbar != CBAR_TYPE_S2_TRANS;
+
+	if (stage1) {
+		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
+		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
+			       base + ARM_SMMU_CB_S1_TLBIASID);
+	} else {
+		base = ARM_SMMU_GR0(smmu);
+		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
+			       base + ARM_SMMU_GR0_TLBIVMID);
+	}
+
+	arm_smmu_tlb_sync(smmu);
+}
+
+static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
+{
+	int flags, ret;
+	u32 fsr, far, fsynr, resume;
+	unsigned long iova;
+	struct iommu_domain *domain = dev;
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	void __iomem *cb_base;
+
+	cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
+	fsr = readl_relaxed(cb_base + ARM_SMMU_CB_FSR);
+
+	if (!(fsr & FSR_FAULT))
+		return IRQ_NONE;
+
+	if (fsr & FSR_IGN)
+		dev_err_ratelimited(smmu->dev,
+				    "Unexpected context fault (fsr 0x%x)\n",
+				    fsr);
+
+	fsynr = readl_relaxed(cb_base + ARM_SMMU_CB_FSYNR0);
+	flags = fsynr & FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ;
+
+	far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_LO);
+	iova = far;
+#ifdef CONFIG_64BIT
+	far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_HI);
+	iova |= ((unsigned long)far << 32);
+#endif
+
+	if (!report_iommu_fault(domain, smmu->dev, iova, flags)) {
+		ret = IRQ_HANDLED;
+		resume = RESUME_RETRY;
+	} else {
+		dev_err_ratelimited(smmu->dev,
+		    "Unhandled context fault: iova=0x%08lx, fsynr=0x%x, cb=%d\n",
+		    iova, fsynr, cfg->cbndx);
+		ret = IRQ_NONE;
+		resume = RESUME_TERMINATE;
+	}
+
+	/* Clear the faulting FSR */
+	writel(fsr, cb_base + ARM_SMMU_CB_FSR);
+
+	/* Retry or terminate any stalled transactions */
+	if (fsr & FSR_SS)
+		writel_relaxed(resume, cb_base + ARM_SMMU_CB_RESUME);
+
+	return ret;
+}
+
+static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
+{
+	u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
+	struct arm_smmu_device *smmu = dev;
+	void __iomem *gr0_base = ARM_SMMU_GR0_NS(smmu);
+
+	gfsr = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSR);
+	gfsynr0 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR0);
+	gfsynr1 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR1);
+	gfsynr2 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR2);
+
+	if (!gfsr)
+		return IRQ_NONE;
+
+	dev_err_ratelimited(smmu->dev,
+		"Unexpected global fault, this could be serious\n");
+	dev_err_ratelimited(smmu->dev,
+		"\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
+		gfsr, gfsynr0, gfsynr1, gfsynr2);
+
+	writel(gfsr, gr0_base + ARM_SMMU_GR0_sGFSR);
+	return IRQ_HANDLED;
+}
+
+static void arm_smmu_flush_pgtable(struct arm_smmu_device *smmu, void *addr,
+				   size_t size)
+{
+	unsigned long offset = (unsigned long)addr & ~PAGE_MASK;
+
+
+	/* Ensure new page tables are visible to the hardware walker */
+	if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK) {
+		dsb(ishst);
+	} else {
+		/*
+		 * If the SMMU can't walk tables in the CPU caches, treat them
+		 * like non-coherent DMA since we need to flush the new entries
+		 * all the way out to memory. There's no possibility of
+		 * recursion here as the SMMU table walker will not be wired
+		 * through another SMMU.
+		 */
+		dma_map_page(smmu->dev, virt_to_page(addr), offset, size,
+				DMA_TO_DEVICE);
+	}
+}
+
+static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
+{
+	u32 reg;
+	bool stage1;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	void __iomem *cb_base, *gr0_base, *gr1_base;
+
+	gr0_base = ARM_SMMU_GR0(smmu);
+	gr1_base = ARM_SMMU_GR1(smmu);
+	stage1 = cfg->cbar != CBAR_TYPE_S2_TRANS;
+	cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
+
+	/* CBAR */
+	reg = cfg->cbar;
+	if (smmu->version == ARM_SMMU_V1)
+		reg |= cfg->irptndx << CBAR_IRPTNDX_SHIFT;
+
+	/*
+	 * Use the weakest shareability/memory types, so they are
+	 * overridden by the ttbcr/pte.
+	 */
+	if (stage1) {
+		reg |= (CBAR_S1_BPSHCFG_NSH << CBAR_S1_BPSHCFG_SHIFT) |
+			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
+	} else {
+		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
+	}
+	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
+
+	if (smmu->version > ARM_SMMU_V1) {
+		/* CBA2R */
+#ifdef CONFIG_64BIT
+		reg = CBA2R_RW64_64BIT;
+#else
+		reg = CBA2R_RW64_32BIT;
+#endif
+		writel_relaxed(reg,
+			       gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
+
+		/* TTBCR2 */
+		switch (smmu->s1_input_size) {
+		case 32:
+			reg = (TTBCR2_ADDR_32 << TTBCR2_SEP_SHIFT);
+			break;
+		case 36:
+			reg = (TTBCR2_ADDR_36 << TTBCR2_SEP_SHIFT);
+			break;
+		case 39:
+		case 40:
+			reg = (TTBCR2_ADDR_40 << TTBCR2_SEP_SHIFT);
+			break;
+		case 42:
+			reg = (TTBCR2_ADDR_42 << TTBCR2_SEP_SHIFT);
+			break;
+		case 44:
+			reg = (TTBCR2_ADDR_44 << TTBCR2_SEP_SHIFT);
+			break;
+		case 48:
+			reg = (TTBCR2_ADDR_48 << TTBCR2_SEP_SHIFT);
+			break;
+		}
+
+		switch (smmu->s1_output_size) {
+		case 32:
+			reg |= (TTBCR2_ADDR_32 << TTBCR2_PASIZE_SHIFT);
+			break;
+		case 36:
+			reg |= (TTBCR2_ADDR_36 << TTBCR2_PASIZE_SHIFT);
+			break;
+		case 39:
+		case 40:
+			reg |= (TTBCR2_ADDR_40 << TTBCR2_PASIZE_SHIFT);
+			break;
+		case 42:
+			reg |= (TTBCR2_ADDR_42 << TTBCR2_PASIZE_SHIFT);
+			break;
+		case 44:
+			reg |= (TTBCR2_ADDR_44 << TTBCR2_PASIZE_SHIFT);
+			break;
+		case 48:
+			reg |= (TTBCR2_ADDR_48 << TTBCR2_PASIZE_SHIFT);
+			break;
+		}
+
+		if (stage1)
+			writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBCR2);
+	}
+
+	/* TTBR0 */
+	arm_smmu_flush_pgtable(smmu, cfg->pgd,
+			       PTRS_PER_PGD * sizeof(pgd_t));
+	reg = __pa(cfg->pgd);
+	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
+	reg = (phys_addr_t)__pa(cfg->pgd) >> 32;
+	if (stage1)
+		reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
+	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
+
+	/*
+	 * TTBCR
+	 * We use long descriptor, with inner-shareable WBWA tables in TTBR0.
+	 */
+	if (smmu->version > ARM_SMMU_V1) {
+		if (PAGE_SIZE == SZ_4K)
+			reg = TTBCR_TG0_4K;
+		else
+			reg = TTBCR_TG0_64K;
+
+		if (!stage1) {
+			reg |= (64 - smmu->s2_input_size) << TTBCR_T0SZ_SHIFT;
+
+			switch (smmu->s2_output_size) {
+			case 32:
+				reg |= (TTBCR2_ADDR_32 << TTBCR_PASIZE_SHIFT);
+				break;
+			case 36:
+				reg |= (TTBCR2_ADDR_36 << TTBCR_PASIZE_SHIFT);
+				break;
+			case 40:
+				reg |= (TTBCR2_ADDR_40 << TTBCR_PASIZE_SHIFT);
+				break;
+			case 42:
+				reg |= (TTBCR2_ADDR_42 << TTBCR_PASIZE_SHIFT);
+				break;
+			case 44:
+				reg |= (TTBCR2_ADDR_44 << TTBCR_PASIZE_SHIFT);
+				break;
+			case 48:
+				reg |= (TTBCR2_ADDR_48 << TTBCR_PASIZE_SHIFT);
+				break;
+			}
+		} else {
+			reg |= (64 - smmu->s1_input_size) << TTBCR_T0SZ_SHIFT;
+		}
+	} else {
+		reg = 0;
+	}
+
+	reg |= TTBCR_EAE |
+	      (TTBCR_SH_IS << TTBCR_SH0_SHIFT) |
+	      (TTBCR_RGN_WBWA << TTBCR_ORGN0_SHIFT) |
+	      (TTBCR_RGN_WBWA << TTBCR_IRGN0_SHIFT);
+
+	if (!stage1)
+		reg |= (TTBCR_SL0_LVL_1 << TTBCR_SL0_SHIFT);
+
+	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBCR);
+
+	/* MAIR0 (stage-1 only) */
+	if (stage1) {
+		reg = (MAIR_ATTR_NC << MAIR_ATTR_SHIFT(MAIR_ATTR_IDX_NC)) |
+		      (MAIR_ATTR_WBRWA << MAIR_ATTR_SHIFT(MAIR_ATTR_IDX_CACHE)) |
+		      (MAIR_ATTR_DEVICE << MAIR_ATTR_SHIFT(MAIR_ATTR_IDX_DEV));
+		writel_relaxed(reg, cb_base + ARM_SMMU_CB_S1_MAIR0);
+	}
+
+	/* SCTLR */
+	reg = SCTLR_CFCFG | SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP;
+	if (stage1)
+		reg |= SCTLR_S1_ASIDPNE;
+#ifdef __BIG_ENDIAN
+	reg |= SCTLR_E;
+#endif
+	writel_relaxed(reg, cb_base + ARM_SMMU_CB_SCTLR);
+}
+
+static int arm_smmu_init_domain_context(struct iommu_domain *domain,
+					struct arm_smmu_device *smmu)
+{
+	int irq, start, ret = 0;
+	unsigned long flags;
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+
+	spin_lock_irqsave(&smmu_domain->lock, flags);
+	if (smmu_domain->smmu)
+		goto out_unlock;
+
+	/*
+	 * Mapping the requested stage onto what we support is surprisingly
+	 * complicated, mainly because the spec allows S1+S2 SMMUs without
+	 * support for nested translation. That means we end up with the
+	 * following table:
+	 *
+	 * Requested        Supported        Actual
+	 *     S1               N              S1
+	 *     S1             S1+S2            S1
+	 *     S1               S2             S2
+	 *     S1               S1             S1
+	 *     N                N              N
+	 *     N              S1+S2            S2
+	 *     N                S2             S2
+	 *     N                S1             S1
+	 *
+	 * Note that you can't actually request stage-2 mappings.
+	 */
+	if (!(smmu->features & ARM_SMMU_FEAT_TRANS_S1))
+		smmu_domain->stage = ARM_SMMU_DOMAIN_S2;
+	if (!(smmu->features & ARM_SMMU_FEAT_TRANS_S2))
+		smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
+
+	switch (smmu_domain->stage) {
+	case ARM_SMMU_DOMAIN_S1:
+		cfg->cbar = CBAR_TYPE_S1_TRANS_S2_BYPASS;
+		start = smmu->num_s2_context_banks;
+		break;
+	case ARM_SMMU_DOMAIN_NESTED:
+		/*
+		 * We will likely want to change this if/when KVM gets
+		 * involved.
+		 */
+	case ARM_SMMU_DOMAIN_S2:
+		cfg->cbar = CBAR_TYPE_S2_TRANS;
+		start = 0;
+		break;
+	default:
+		ret = -EINVAL;
+		goto out_unlock;
+	}
+
+	ret = __arm_smmu_alloc_bitmap(smmu->context_map, start,
+				      smmu->num_context_banks);
+	if (IS_ERR_VALUE(ret))
+		goto out_unlock;
+
+	cfg->cbndx = ret;
+	if (smmu->version == ARM_SMMU_V1) {
+		cfg->irptndx = atomic_inc_return(&smmu->irptndx);
+		cfg->irptndx %= smmu->num_context_irqs;
+	} else {
+		cfg->irptndx = cfg->cbndx;
+	}
+
+	ACCESS_ONCE(smmu_domain->smmu) = smmu;
+	arm_smmu_init_context_bank(smmu_domain);
+	spin_unlock_irqrestore(&smmu_domain->lock, flags);
+
+	irq = smmu->irqs[smmu->num_global_irqs + cfg->irptndx];
+	ret = request_irq(irq, arm_smmu_context_fault, IRQF_SHARED,
+			  "arm-smmu-context-fault", domain);
+	if (IS_ERR_VALUE(ret)) {
+		dev_err(smmu->dev, "failed to request context IRQ %d (%u)\n",
+			cfg->irptndx, irq);
+		cfg->irptndx = INVALID_IRPTNDX;
+	}
+
+	return 0;
+
+out_unlock:
+	spin_unlock_irqrestore(&smmu_domain->lock, flags);
+	return ret;
+}
+
+static void arm_smmu_destroy_domain_context(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+	void __iomem *cb_base;
+	int irq;
+
+	if (!smmu)
+		return;
+
+	/* Disable the context bank and nuke the TLB before freeing it. */
+	cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
+	writel_relaxed(0, cb_base + ARM_SMMU_CB_SCTLR);
+	arm_smmu_tlb_inv_context(smmu_domain);
+
+	if (cfg->irptndx != INVALID_IRPTNDX) {
+		irq = smmu->irqs[smmu->num_global_irqs + cfg->irptndx];
+		free_irq(irq, domain);
+	}
+
+	__arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
+}
+
+static int arm_smmu_domain_init(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain;
+	pgd_t *pgd;
+
+	/*
+	 * Allocate the domain and initialise some of its data structures.
+	 * We can't really do anything meaningful until we've added a
+	 * master.
+	 */
+	smmu_domain = kzalloc(sizeof(*smmu_domain), GFP_KERNEL);
+	if (!smmu_domain)
+		return -ENOMEM;
+
+	pgd = kcalloc(PTRS_PER_PGD, sizeof(pgd_t), GFP_KERNEL);
+	if (!pgd)
+		goto out_free_domain;
+	smmu_domain->cfg.pgd = pgd;
+
+	spin_lock_init(&smmu_domain->lock);
+	domain->priv = smmu_domain;
+	return 0;
+
+out_free_domain:
+	kfree(smmu_domain);
+	return -ENOMEM;
+}
+
+static void arm_smmu_free_ptes(pmd_t *pmd)
+{
+	pgtable_t table = pmd_pgtable(*pmd);
+
+	__free_page(table);
+}
+
+static void arm_smmu_free_pmds(pud_t *pud)
+{
+	int i;
+	pmd_t *pmd, *pmd_base = pmd_offset(pud, 0);
+
+	pmd = pmd_base;
+	for (i = 0; i < PTRS_PER_PMD; ++i) {
+		if (pmd_none(*pmd))
+			continue;
+
+		arm_smmu_free_ptes(pmd);
+		pmd++;
+	}
+
+	pmd_free(NULL, pmd_base);
+}
+
+static void arm_smmu_free_puds(pgd_t *pgd)
+{
+	int i;
+	pud_t *pud, *pud_base = pud_offset(pgd, 0);
+
+	pud = pud_base;
+	for (i = 0; i < PTRS_PER_PUD; ++i) {
+		if (pud_none(*pud))
+			continue;
+
+		arm_smmu_free_pmds(pud);
+		pud++;
+	}
+
+	pud_free(NULL, pud_base);
+}
+
+static void arm_smmu_free_pgtables(struct arm_smmu_domain *smmu_domain)
+{
+	int i;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+	pgd_t *pgd, *pgd_base = cfg->pgd;
+
+	/*
+	 * Recursively free the page tables for this domain. We don't
+	 * care about speculative TLB filling because the tables should
+	 * not be active in any context bank at this point (SCTLR.M is 0).
+	 */
+	pgd = pgd_base;
+	for (i = 0; i < PTRS_PER_PGD; ++i) {
+		if (pgd_none(*pgd))
+			continue;
+		arm_smmu_free_puds(pgd);
+		pgd++;
+	}
+
+	kfree(pgd_base);
+}
+
+static void arm_smmu_domain_destroy(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+
+	/*
+	 * Free the domain resources. We assume that all devices have
+	 * already been detached.
+	 */
+	arm_smmu_destroy_domain_context(domain);
+	arm_smmu_free_pgtables(smmu_domain);
+	kfree(smmu_domain);
+}
+
+static int arm_smmu_master_configure_smrs(struct arm_smmu_device *smmu,
+					  struct arm_smmu_master_cfg *cfg)
+{
+	int i;
+	struct arm_smmu_smr *smrs;
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+
+	if (!(smmu->features & ARM_SMMU_FEAT_STREAM_MATCH))
+		return 0;
+
+	if (cfg->smrs)
+		return -EEXIST;
+
+	smrs = kmalloc_array(cfg->num_streamids, sizeof(*smrs), GFP_KERNEL);
+	if (!smrs) {
+		dev_err(smmu->dev, "failed to allocate %d SMRs\n",
+			cfg->num_streamids);
+		return -ENOMEM;
+	}
+
+	/* Allocate the SMRs on the SMMU */
+	for (i = 0; i < cfg->num_streamids; ++i) {
+		int idx = __arm_smmu_alloc_bitmap(smmu->smr_map, 0,
+						  smmu->num_mapping_groups);
+		if (IS_ERR_VALUE(idx)) {
+			dev_err(smmu->dev, "failed to allocate free SMR\n");
+			goto err_free_smrs;
+		}
+
+		smrs[i] = (struct arm_smmu_smr) {
+			.idx	= idx,
+			.mask	= 0, /* We don't currently share SMRs */
+			.id	= cfg->streamids[i],
+		};
+	}
+
+	/* It worked! Now, poke the actual hardware */
+	for (i = 0; i < cfg->num_streamids; ++i) {
+		u32 reg = SMR_VALID | smrs[i].id << SMR_ID_SHIFT |
+			  smrs[i].mask << SMR_MASK_SHIFT;
+		writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_SMR(smrs[i].idx));
+	}
+
+	cfg->smrs = smrs;
+	return 0;
+
+err_free_smrs:
+	while (--i >= 0)
+		__arm_smmu_free_bitmap(smmu->smr_map, smrs[i].idx);
+	kfree(smrs);
+	return -ENOSPC;
+}
+
+static void arm_smmu_master_free_smrs(struct arm_smmu_device *smmu,
+				      struct arm_smmu_master_cfg *cfg)
+{
+	int i;
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+	struct arm_smmu_smr *smrs = cfg->smrs;
+
+	if (!smrs)
+		return;
+
+	/* Invalidate the SMRs before freeing back to the allocator */
+	for (i = 0; i < cfg->num_streamids; ++i) {
+		u8 idx = smrs[i].idx;
+
+		writel_relaxed(~SMR_VALID, gr0_base + ARM_SMMU_GR0_SMR(idx));
+		__arm_smmu_free_bitmap(smmu->smr_map, idx);
+	}
+
+	cfg->smrs = NULL;
+	kfree(smrs);
+}
+
+static int arm_smmu_domain_add_master(struct arm_smmu_domain *smmu_domain,
+				      struct arm_smmu_master_cfg *cfg)
+{
+	int i, ret;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+
+	/* Devices in an IOMMU group may already be configured */
+	ret = arm_smmu_master_configure_smrs(smmu, cfg);
+	if (ret)
+		return ret == -EEXIST ? 0 : ret;
+
+	for (i = 0; i < cfg->num_streamids; ++i) {
+		u32 idx, s2cr;
+
+		idx = cfg->smrs ? cfg->smrs[i].idx : cfg->streamids[i];
+		s2cr = S2CR_TYPE_TRANS |
+		       (smmu_domain->cfg.cbndx << S2CR_CBNDX_SHIFT);
+		writel_relaxed(s2cr, gr0_base + ARM_SMMU_GR0_S2CR(idx));
+	}
+
+	return 0;
+}
+
+static void arm_smmu_domain_remove_master(struct arm_smmu_domain *smmu_domain,
+					  struct arm_smmu_master_cfg *cfg)
+{
+	int i;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+
+	/* An IOMMU group is torn down by the first device to be removed */
+	if ((smmu->features & ARM_SMMU_FEAT_STREAM_MATCH) && !cfg->smrs)
+		return;
+
+	/*
+	 * We *must* clear the S2CR first, because freeing the SMR means
+	 * that it can be re-allocated immediately.
+	 */
+	for (i = 0; i < cfg->num_streamids; ++i) {
+		u32 idx = cfg->smrs ? cfg->smrs[i].idx : cfg->streamids[i];
+
+		writel_relaxed(S2CR_TYPE_BYPASS,
+			       gr0_base + ARM_SMMU_GR0_S2CR(idx));
+	}
+
+	arm_smmu_master_free_smrs(smmu, cfg);
+}
+
+static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
+{
+	int ret;
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+	struct arm_smmu_device *smmu, *dom_smmu;
+	struct arm_smmu_master_cfg *cfg;
+
+	smmu = find_smmu_for_device(dev);
+	if (!smmu) {
+		dev_err(dev, "cannot attach to SMMU, is it on the same bus?\n");
+		return -ENXIO;
+	}
+
+	if (dev->archdata.iommu) {
+		dev_err(dev, "already attached to IOMMU domain\n");
+		return -EEXIST;
+	}
+
+	/*
+	 * Sanity check the domain. We don't support domains across
+	 * different SMMUs.
+	 */
+	dom_smmu = ACCESS_ONCE(smmu_domain->smmu);
+	if (!dom_smmu) {
+		/* Now that we have a master, we can finalise the domain */
+		ret = arm_smmu_init_domain_context(domain, smmu);
+		if (IS_ERR_VALUE(ret))
+			return ret;
+
+		dom_smmu = smmu_domain->smmu;
+	}
+
+	if (dom_smmu != smmu) {
+		dev_err(dev,
+			"cannot attach to SMMU %s whilst already attached to domain on SMMU %s\n",
+			dev_name(smmu_domain->smmu->dev), dev_name(smmu->dev));
+		return -EINVAL;
+	}
+
+	/* Looks ok, so add the device to the domain */
+	cfg = find_smmu_master_cfg(dev);
+	if (!cfg)
+		return -ENODEV;
+
+	ret = arm_smmu_domain_add_master(smmu_domain, cfg);
+	if (!ret)
+		dev->archdata.iommu = domain;
+	return ret;
+}
+
+static void arm_smmu_detach_dev(struct iommu_domain *domain, struct device *dev)
+{
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+	struct arm_smmu_master_cfg *cfg;
+
+	cfg = find_smmu_master_cfg(dev);
+	if (!cfg)
+		return;
+
+	dev->archdata.iommu = NULL;
+	arm_smmu_domain_remove_master(smmu_domain, cfg);
+}
+
+static bool arm_smmu_pte_is_contiguous_range(unsigned long addr,
+					     unsigned long end)
+{
+	return !(addr & ~ARM_SMMU_PTE_CONT_MASK) &&
+		(addr + ARM_SMMU_PTE_CONT_SIZE <= end);
+}
+
+static int arm_smmu_alloc_init_pte(struct arm_smmu_device *smmu, pmd_t *pmd,
+				   unsigned long addr, unsigned long end,
+				   unsigned long pfn, int prot, int stage)
+{
+	pte_t *pte, *start;
+	pteval_t pteval = ARM_SMMU_PTE_PAGE | ARM_SMMU_PTE_AF;
+
+	if (pmd_none(*pmd)) {
+		/* Allocate a new set of tables */
+		pgtable_t table = alloc_page(GFP_ATOMIC|__GFP_ZERO);
+
+		if (!table)
+			return -ENOMEM;
+
+		arm_smmu_flush_pgtable(smmu, page_address(table), PAGE_SIZE);
+		pmd_populate(NULL, pmd, table);
+		arm_smmu_flush_pgtable(smmu, pmd, sizeof(*pmd));
+	}
+
+	if (stage == 1) {
+		pteval |= ARM_SMMU_PTE_AP_UNPRIV | ARM_SMMU_PTE_nG;
+		if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
+			pteval |= ARM_SMMU_PTE_AP_RDONLY;
+
+		if (prot & IOMMU_CACHE)
+			pteval |= (MAIR_ATTR_IDX_CACHE <<
+				   ARM_SMMU_PTE_ATTRINDX_SHIFT);
+	} else {
+		pteval |= ARM_SMMU_PTE_HAP_FAULT;
+		if (prot & IOMMU_READ)
+			pteval |= ARM_SMMU_PTE_HAP_READ;
+		if (prot & IOMMU_WRITE)
+			pteval |= ARM_SMMU_PTE_HAP_WRITE;
+		if (prot & IOMMU_CACHE)
+			pteval |= ARM_SMMU_PTE_MEMATTR_OIWB;
+		else
+			pteval |= ARM_SMMU_PTE_MEMATTR_NC;
+	}
+
+	if (prot & IOMMU_NOEXEC)
+		pteval |= ARM_SMMU_PTE_XN;
+
+	/* If no access, create a faulting entry to avoid TLB fills */
+	if (!(prot & (IOMMU_READ | IOMMU_WRITE)))
+		pteval &= ~ARM_SMMU_PTE_PAGE;
+
+	pteval |= ARM_SMMU_PTE_SH_IS;
+	start = pmd_page_vaddr(*pmd) + pte_index(addr);
+	pte = start;
+
+	/*
+	 * Install the page table entries. This is fairly complicated
+	 * since we attempt to make use of the contiguous hint in the
+	 * ptes where possible. The contiguous hint indicates a series
+	 * of ARM_SMMU_PTE_CONT_ENTRIES ptes mapping a physically
+	 * contiguous region with the following constraints:
+	 *
+	 *   - The region start is aligned to ARM_SMMU_PTE_CONT_SIZE
+	 *   - Each pte in the region has the contiguous hint bit set
+	 *
+	 * This complicates unmapping (also handled by this code, when
+	 * neither IOMMU_READ or IOMMU_WRITE are set) because it is
+	 * possible, yet highly unlikely, that a client may unmap only
+	 * part of a contiguous range. This requires clearing of the
+	 * contiguous hint bits in the range before installing the new
+	 * faulting entries.
+	 *
+	 * Note that re-mapping an address range without first unmapping
+	 * it is not supported, so TLB invalidation is not required here
+	 * and is instead performed at unmap and domain-init time.
+	 */
+	do {
+		int i = 1;
+
+		pteval &= ~ARM_SMMU_PTE_CONT;
+
+		if (arm_smmu_pte_is_contiguous_range(addr, end)) {
+			i = ARM_SMMU_PTE_CONT_ENTRIES;
+			pteval |= ARM_SMMU_PTE_CONT;
+		} else if (pte_val(*pte) &
+			   (ARM_SMMU_PTE_CONT | ARM_SMMU_PTE_PAGE)) {
+			int j;
+			pte_t *cont_start;
+			unsigned long idx = pte_index(addr);
+
+			idx &= ~(ARM_SMMU_PTE_CONT_ENTRIES - 1);
+			cont_start = pmd_page_vaddr(*pmd) + idx;
+			for (j = 0; j < ARM_SMMU_PTE_CONT_ENTRIES; ++j)
+				pte_val(*(cont_start + j)) &=
+					~ARM_SMMU_PTE_CONT;
+
+			arm_smmu_flush_pgtable(smmu, cont_start,
+					       sizeof(*pte) *
+					       ARM_SMMU_PTE_CONT_ENTRIES);
+		}
+
+		do {
+			*pte = pfn_pte(pfn, __pgprot(pteval));
+		} while (pte++, pfn++, addr += PAGE_SIZE, --i);
+	} while (addr != end);
+
+	arm_smmu_flush_pgtable(smmu, start, sizeof(*pte) * (pte - start));
+	return 0;
+}
+
+static int arm_smmu_alloc_init_pmd(struct arm_smmu_device *smmu, pud_t *pud,
+				   unsigned long addr, unsigned long end,
+				   phys_addr_t phys, int prot, int stage)
+{
+	int ret;
+	pmd_t *pmd;
+	unsigned long next, pfn = __phys_to_pfn(phys);
+
+#ifndef __PAGETABLE_PMD_FOLDED
+	if (pud_none(*pud)) {
+		pmd = (pmd_t *)get_zeroed_page(GFP_ATOMIC);
+		if (!pmd)
+			return -ENOMEM;
+
+		arm_smmu_flush_pgtable(smmu, pmd, PAGE_SIZE);
+		pud_populate(NULL, pud, pmd);
+		arm_smmu_flush_pgtable(smmu, pud, sizeof(*pud));
+
+		pmd += pmd_index(addr);
+	} else
+#endif
+		pmd = pmd_offset(pud, addr);
+
+	do {
+		next = pmd_addr_end(addr, end);
+		ret = arm_smmu_alloc_init_pte(smmu, pmd, addr, next, pfn,
+					      prot, stage);
+		phys += next - addr;
+		pfn = __phys_to_pfn(phys);
+	} while (pmd++, addr = next, addr < end);
+
+	return ret;
+}
+
+static int arm_smmu_alloc_init_pud(struct arm_smmu_device *smmu, pgd_t *pgd,
+				   unsigned long addr, unsigned long end,
+				   phys_addr_t phys, int prot, int stage)
+{
+	int ret = 0;
+	pud_t *pud;
+	unsigned long next;
+
+#ifndef __PAGETABLE_PUD_FOLDED
+	if (pgd_none(*pgd)) {
+		pud = (pud_t *)get_zeroed_page(GFP_ATOMIC);
+		if (!pud)
+			return -ENOMEM;
+
+		arm_smmu_flush_pgtable(smmu, pud, PAGE_SIZE);
+		pgd_populate(NULL, pgd, pud);
+		arm_smmu_flush_pgtable(smmu, pgd, sizeof(*pgd));
+
+		pud += pud_index(addr);
+	} else
+#endif
+		pud = pud_offset(pgd, addr);
+
+	do {
+		next = pud_addr_end(addr, end);
+		ret = arm_smmu_alloc_init_pmd(smmu, pud, addr, next, phys,
+					      prot, stage);
+		phys += next - addr;
+	} while (pud++, addr = next, addr < end);
+
+	return ret;
+}
+
+static int arm_smmu_handle_mapping(struct arm_smmu_domain *smmu_domain,
+				   unsigned long iova, phys_addr_t paddr,
+				   size_t size, int prot)
+{
+	int ret, stage;
+	unsigned long end;
+	phys_addr_t input_mask, output_mask;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+	pgd_t *pgd = cfg->pgd;
+	unsigned long flags;
+
+	if (cfg->cbar == CBAR_TYPE_S2_TRANS) {
+		stage = 2;
+		input_mask = (1ULL << smmu->s2_input_size) - 1;
+		output_mask = (1ULL << smmu->s2_output_size) - 1;
+	} else {
+		stage = 1;
+		input_mask = (1ULL << smmu->s1_input_size) - 1;
+		output_mask = (1ULL << smmu->s1_output_size) - 1;
+	}
+
+	if (!pgd)
+		return -EINVAL;
+
+	if (size & ~PAGE_MASK)
+		return -EINVAL;
+
+	if ((phys_addr_t)iova & ~input_mask)
+		return -ERANGE;
+
+	if (paddr & ~output_mask)
+		return -ERANGE;
+
+	spin_lock_irqsave(&smmu_domain->lock, flags);
+	pgd += pgd_index(iova);
+	end = iova + size;
+	do {
+		unsigned long next = pgd_addr_end(iova, end);
+
+		ret = arm_smmu_alloc_init_pud(smmu, pgd, iova, next, paddr,
+					      prot, stage);
+		if (ret)
+			goto out_unlock;
+
+		paddr += next - iova;
+		iova = next;
+	} while (pgd++, iova != end);
+
+out_unlock:
+	spin_unlock_irqrestore(&smmu_domain->lock, flags);
+
+	return ret;
+}
+
+static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova,
+			phys_addr_t paddr, size_t size, int prot)
+{
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+
+	if (!smmu_domain)
+		return -ENODEV;
+
+	return arm_smmu_handle_mapping(smmu_domain, iova, paddr, size, prot);
+}
+
+static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,
+			     size_t size)
+{
+	int ret;
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+
+	ret = arm_smmu_handle_mapping(smmu_domain, iova, 0, size, 0);
+	arm_smmu_tlb_inv_context(smmu_domain);
+	return ret ? 0 : size;
+}
+
+static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
+					 dma_addr_t iova)
+{
+	pgd_t *pgdp, pgd;
+	pud_t pud;
+	pmd_t pmd;
+	pte_t pte;
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+
+	pgdp = cfg->pgd;
+	if (!pgdp)
+		return 0;
+
+	pgd = *(pgdp + pgd_index(iova));
+	if (pgd_none(pgd))
+		return 0;
+
+	pud = *pud_offset(&pgd, iova);
+	if (pud_none(pud))
+		return 0;
+
+	pmd = *pmd_offset(&pud, iova);
+	if (pmd_none(pmd))
+		return 0;
+
+	pte = *(pmd_page_vaddr(pmd) + pte_index(iova));
+	if (pte_none(pte))
+		return 0;
+
+	return __pfn_to_phys(pte_pfn(pte)) | (iova & ~PAGE_MASK);
+}
+
+static bool arm_smmu_capable(enum iommu_cap cap)
+{
+	switch (cap) {
+	case IOMMU_CAP_CACHE_COHERENCY:
+		/*
+		 * Return true here as the SMMU can always send out coherent
+		 * requests.
+		 */
+		return true;
+	case IOMMU_CAP_INTR_REMAP:
+		return true; /* MSIs are just memory writes */
+	case IOMMU_CAP_NOEXEC:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static int __arm_smmu_get_pci_sid(struct pci_dev *pdev, u16 alias, void *data)
+{
+	*((u16 *)data) = alias;
+	return 0; /* Continue walking */
+}
+
+static void __arm_smmu_release_pci_iommudata(void *data)
+{
+	kfree(data);
+}
+
+static int arm_smmu_add_device(struct device *dev)
+{
+	struct arm_smmu_device *smmu;
+	struct arm_smmu_master_cfg *cfg;
+	struct iommu_group *group;
+	void (*releasefn)(void *) = NULL;
+	int ret;
+
+	smmu = find_smmu_for_device(dev);
+	if (!smmu)
+		return -ENODEV;
+
+	group = iommu_group_alloc();
+	if (IS_ERR(group)) {
+		dev_err(dev, "Failed to allocate IOMMU group\n");
+		return PTR_ERR(group);
+	}
+
+	if (dev_is_pci(dev)) {
+		struct pci_dev *pdev = to_pci_dev(dev);
+
+		cfg = kzalloc(sizeof(*cfg), GFP_KERNEL);
+		if (!cfg) {
+			ret = -ENOMEM;
+			goto out_put_group;
+		}
+
+		cfg->num_streamids = 1;
+		/*
+		 * Assume Stream ID == Requester ID for now.
+		 * We need a way to describe the ID mappings in FDT.
+		 */
+		pci_for_each_dma_alias(pdev, __arm_smmu_get_pci_sid,
+				       &cfg->streamids[0]);
+		releasefn = __arm_smmu_release_pci_iommudata;
+	} else {
+		struct arm_smmu_master *master;
+
+		master = find_smmu_master(smmu, dev->of_node);
+		if (!master) {
+			ret = -ENODEV;
+			goto out_put_group;
+		}
+
+		cfg = &master->cfg;
+	}
+
+	iommu_group_set_iommudata(group, cfg, releasefn);
+	ret = iommu_group_add_device(group, dev);
+
+out_put_group:
+	iommu_group_put(group);
+	return ret;
+}
+
+static void arm_smmu_remove_device(struct device *dev)
+{
+	iommu_group_remove_device(dev);
+}
+
+static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
+				    enum iommu_attr attr, void *data)
+{
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+
+	switch (attr) {
+	case DOMAIN_ATTR_NESTING:
+		*(int *)data = (smmu_domain->stage == ARM_SMMU_DOMAIN_NESTED);
+		return 0;
+	default:
+		return -ENODEV;
+	}
+}
+
+static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
+				    enum iommu_attr attr, void *data)
+{
+	struct arm_smmu_domain *smmu_domain = domain->priv;
+
+	switch (attr) {
+	case DOMAIN_ATTR_NESTING:
+		if (smmu_domain->smmu)
+			return -EPERM;
+		if (*(int *)data)
+			smmu_domain->stage = ARM_SMMU_DOMAIN_NESTED;
+		else
+			smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
+
+		return 0;
+	default:
+		return -ENODEV;
+	}
+}
+
+static const struct iommu_ops arm_smmu_ops = {
+	.capable		= arm_smmu_capable,
+	.domain_init		= arm_smmu_domain_init,
+	.domain_destroy		= arm_smmu_domain_destroy,
+	.attach_dev		= arm_smmu_attach_dev,
+	.detach_dev		= arm_smmu_detach_dev,
+	.map			= arm_smmu_map,
+	.unmap			= arm_smmu_unmap,
+	.map_sg			= default_iommu_map_sg,
+	.iova_to_phys		= arm_smmu_iova_to_phys,
+	.add_device		= arm_smmu_add_device,
+	.remove_device		= arm_smmu_remove_device,
+	.domain_get_attr	= arm_smmu_domain_get_attr,
+	.domain_set_attr	= arm_smmu_domain_set_attr,
+	.pgsize_bitmap		= (SECTION_SIZE |
+				   ARM_SMMU_PTE_CONT_SIZE |
+				   PAGE_SIZE),
+};
+
+static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
+{
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+	void __iomem *cb_base;
+	int i = 0;
+	u32 reg;
+
+	/* clear global FSR */
+	reg = readl_relaxed(ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sGFSR);
+	writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sGFSR);
+
+	/* Mark all SMRn as invalid and all S2CRn as bypass */
+	for (i = 0; i < smmu->num_mapping_groups; ++i) {
+		writel_relaxed(0, gr0_base + ARM_SMMU_GR0_SMR(i));
+		writel_relaxed(S2CR_TYPE_BYPASS,
+			gr0_base + ARM_SMMU_GR0_S2CR(i));
+	}
+
+	/* Make sure all context banks are disabled and clear CB_FSR  */
+	for (i = 0; i < smmu->num_context_banks; ++i) {
+		cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, i);
+		writel_relaxed(0, cb_base + ARM_SMMU_CB_SCTLR);
+		writel_relaxed(FSR_FAULT, cb_base + ARM_SMMU_CB_FSR);
+	}
+
+	/* Invalidate the TLB, just in case */
+	writel_relaxed(0, gr0_base + ARM_SMMU_GR0_STLBIALL);
+	writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLH);
+	writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLNSNH);
+
+	reg = readl_relaxed(ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
+
+	/* Enable fault reporting */
+	reg |= (sCR0_GFRE | sCR0_GFIE | sCR0_GCFGFRE | sCR0_GCFGFIE);
+
+	/* Disable TLB broadcasting. */
+	reg |= (sCR0_VMIDPNE | sCR0_PTM);
+
+	/* Enable client access, but bypass when no mapping is found */
+	reg &= ~(sCR0_CLIENTPD | sCR0_USFCFG);
+
+	/* Disable forced broadcasting */
+	reg &= ~sCR0_FB;
+
+	/* Don't upgrade barriers */
+	reg &= ~(sCR0_BSU_MASK << sCR0_BSU_SHIFT);
+
+	/* Push the button */
+	arm_smmu_tlb_sync(smmu);
+	writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
+}
+
+static int arm_smmu_id_size_to_bits(int size)
+{
+	switch (size) {
+	case 0:
+		return 32;
+	case 1:
+		return 36;
+	case 2:
+		return 40;
+	case 3:
+		return 42;
+	case 4:
+		return 44;
+	case 5:
+	default:
+		return 48;
+	}
+}
+
+static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
+{
+	unsigned long size;
+	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+	u32 id;
+
+	dev_notice(smmu->dev, "probing hardware configuration...\n");
+	dev_notice(smmu->dev, "SMMUv%d with:\n", smmu->version);
+
+	/* ID0 */
+	id = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID0);
+#ifndef CONFIG_64BIT
+	if (((id >> ID0_PTFS_SHIFT) & ID0_PTFS_MASK) == ID0_PTFS_V8_ONLY) {
+		dev_err(smmu->dev, "\tno v7 descriptor support!\n");
+		return -ENODEV;
+	}
+#endif
+
+	/* Restrict available stages based on module parameter */
+	if (force_stage == 1)
+		id &= ~(ID0_S2TS | ID0_NTS);
+	else if (force_stage == 2)
+		id &= ~(ID0_S1TS | ID0_NTS);
+
+	if (id & ID0_S1TS) {
+		smmu->features |= ARM_SMMU_FEAT_TRANS_S1;
+		dev_notice(smmu->dev, "\tstage 1 translation\n");
+	}
+
+	if (id & ID0_S2TS) {
+		smmu->features |= ARM_SMMU_FEAT_TRANS_S2;
+		dev_notice(smmu->dev, "\tstage 2 translation\n");
+	}
+
+	if (id & ID0_NTS) {
+		smmu->features |= ARM_SMMU_FEAT_TRANS_NESTED;
+		dev_notice(smmu->dev, "\tnested translation\n");
+	}
+
+	if (!(smmu->features &
+		(ARM_SMMU_FEAT_TRANS_S1 | ARM_SMMU_FEAT_TRANS_S2))) {
+		dev_err(smmu->dev, "\tno translation support!\n");
+		return -ENODEV;
+	}
+
+	if (id & ID0_CTTW) {
+		smmu->features |= ARM_SMMU_FEAT_COHERENT_WALK;
+		dev_notice(smmu->dev, "\tcoherent table walk\n");
+	}
+
+	if (id & ID0_SMS) {
+		u32 smr, sid, mask;
+
+		smmu->features |= ARM_SMMU_FEAT_STREAM_MATCH;
+		smmu->num_mapping_groups = (id >> ID0_NUMSMRG_SHIFT) &
+					   ID0_NUMSMRG_MASK;
+		if (smmu->num_mapping_groups == 0) {
+			dev_err(smmu->dev,
+				"stream-matching supported, but no SMRs present!\n");
+			return -ENODEV;
+		}
+
+		smr = SMR_MASK_MASK << SMR_MASK_SHIFT;
+		smr |= (SMR_ID_MASK << SMR_ID_SHIFT);
+		writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
+		smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
+
+		mask = (smr >> SMR_MASK_SHIFT) & SMR_MASK_MASK;
+		sid = (smr >> SMR_ID_SHIFT) & SMR_ID_MASK;
+		if ((mask & sid) != sid) {
+			dev_err(smmu->dev,
+				"SMR mask bits (0x%x) insufficient for ID field (0x%x)\n",
+				mask, sid);
+			return -ENODEV;
+		}
+
+		dev_notice(smmu->dev,
+			   "\tstream matching with %u register groups, mask 0x%x",
+			   smmu->num_mapping_groups, mask);
+	} else {
+		smmu->num_mapping_groups = (id >> ID0_NUMSIDB_SHIFT) &
+					   ID0_NUMSIDB_MASK;
+	}
+
+	/* ID1 */
+	id = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID1);
+	smmu->pgshift = (id & ID1_PAGESIZE) ? 16 : 12;
+
+	/* Check for size mismatch of SMMU address space from mapped region */
+	size = 1 <<
+		(((id >> ID1_NUMPAGENDXB_SHIFT) & ID1_NUMPAGENDXB_MASK) + 1);
+	size *= 2 << smmu->pgshift;
+	if (smmu->size != size)
+		dev_warn(smmu->dev,
+			"SMMU address space size (0x%lx) differs from mapped region size (0x%lx)!\n",
+			size, smmu->size);
+
+	smmu->num_s2_context_banks = (id >> ID1_NUMS2CB_SHIFT) &
+				      ID1_NUMS2CB_MASK;
+	smmu->num_context_banks = (id >> ID1_NUMCB_SHIFT) & ID1_NUMCB_MASK;
+	if (smmu->num_s2_context_banks > smmu->num_context_banks) {
+		dev_err(smmu->dev, "impossible number of S2 context banks!\n");
+		return -ENODEV;
+	}
+	dev_notice(smmu->dev, "\t%u context banks (%u stage-2 only)\n",
+		   smmu->num_context_banks, smmu->num_s2_context_banks);
+
+	/* ID2 */
+	id = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID2);
+	size = arm_smmu_id_size_to_bits((id >> ID2_IAS_SHIFT) & ID2_IAS_MASK);
+	smmu->s1_output_size = min_t(unsigned long, PHYS_MASK_SHIFT, size);
+
+	/* Stage-2 input size limited due to pgd allocation (PTRS_PER_PGD) */
+#ifdef CONFIG_64BIT
+	smmu->s2_input_size = min_t(unsigned long, VA_BITS, size);
+#else
+	smmu->s2_input_size = min(32UL, size);
+#endif
+
+	/* The stage-2 output mask is also applied for bypass */
+	size = arm_smmu_id_size_to_bits((id >> ID2_OAS_SHIFT) & ID2_OAS_MASK);
+	smmu->s2_output_size = min_t(unsigned long, PHYS_MASK_SHIFT, size);
+
+	if (smmu->version == ARM_SMMU_V1) {
+		smmu->s1_input_size = 32;
+	} else {
+#ifdef CONFIG_64BIT
+		size = (id >> ID2_UBS_SHIFT) & ID2_UBS_MASK;
+		size = min(VA_BITS, arm_smmu_id_size_to_bits(size));
+#else
+		size = 32;
+#endif
+		smmu->s1_input_size = size;
+
+		if ((PAGE_SIZE == SZ_4K && !(id & ID2_PTFS_4K)) ||
+		    (PAGE_SIZE == SZ_64K && !(id & ID2_PTFS_64K)) ||
+		    (PAGE_SIZE != SZ_4K && PAGE_SIZE != SZ_64K)) {
+			dev_err(smmu->dev, "CPU page size 0x%lx unsupported\n",
+				PAGE_SIZE);
+			return -ENODEV;
+		}
+	}
+
+	if (smmu->features & ARM_SMMU_FEAT_TRANS_S1)
+		dev_notice(smmu->dev, "\tStage-1: %lu-bit VA -> %lu-bit IPA\n",
+			   smmu->s1_input_size, smmu->s1_output_size);
+
+	if (smmu->features & ARM_SMMU_FEAT_TRANS_S2)
+		dev_notice(smmu->dev, "\tStage-2: %lu-bit IPA -> %lu-bit PA\n",
+			   smmu->s2_input_size, smmu->s2_output_size);
+
+	return 0;
+}
+
+static const struct of_device_id arm_smmu_of_match[] = {
+	{ .compatible = "arm,smmu-v1", .data = (void *)ARM_SMMU_V1 },
+	{ .compatible = "arm,smmu-v2", .data = (void *)ARM_SMMU_V2 },
+	{ .compatible = "arm,mmu-400", .data = (void *)ARM_SMMU_V1 },
+	{ .compatible = "arm,mmu-401", .data = (void *)ARM_SMMU_V1 },
+	{ .compatible = "arm,mmu-500", .data = (void *)ARM_SMMU_V2 },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
+
+static int arm_smmu_device_dt_probe(struct platform_device *pdev)
+{
+	const struct of_device_id *of_id;
+	struct resource *res;
+	struct arm_smmu_device *smmu;
+	struct device *dev = &pdev->dev;
+	struct rb_node *node;
+	struct of_phandle_args masterspec;
+	int num_irqs, i, err;
+
+	smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
+	if (!smmu) {
+		dev_err(dev, "failed to allocate arm_smmu_device\n");
+		return -ENOMEM;
+	}
+	smmu->dev = dev;
+
+	of_id = of_match_node(arm_smmu_of_match, dev->of_node);
+	smmu->version = (enum arm_smmu_arch_version)of_id->data;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	smmu->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(smmu->base))
+		return PTR_ERR(smmu->base);
+	smmu->size = resource_size(res);
+
+	if (of_property_read_u32(dev->of_node, "#global-interrupts",
+				 &smmu->num_global_irqs)) {
+		dev_err(dev, "missing #global-interrupts property\n");
+		return -ENODEV;
+	}
+
+	num_irqs = 0;
+	while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, num_irqs))) {
+		num_irqs++;
+		if (num_irqs > smmu->num_global_irqs)
+			smmu->num_context_irqs++;
+	}
+
+	if (!smmu->num_context_irqs) {
+		dev_err(dev, "found %d interrupts but expected at least %d\n",
+			num_irqs, smmu->num_global_irqs + 1);
+		return -ENODEV;
+	}
+
+	smmu->irqs = devm_kzalloc(dev, sizeof(*smmu->irqs) * num_irqs,
+				  GFP_KERNEL);
+	if (!smmu->irqs) {
+		dev_err(dev, "failed to allocate %d irqs\n", num_irqs);
+		return -ENOMEM;
+	}
+
+	for (i = 0; i < num_irqs; ++i) {
+		int irq = platform_get_irq(pdev, i);
+
+		if (irq < 0) {
+			dev_err(dev, "failed to get irq index %d\n", i);
+			return -ENODEV;
+		}
+		smmu->irqs[i] = irq;
+	}
+
+	err = arm_smmu_device_cfg_probe(smmu);
+	if (err)
+		return err;
+
+	i = 0;
+	smmu->masters = RB_ROOT;
+	while (!of_parse_phandle_with_args(dev->of_node, "mmu-masters",
+					   "#stream-id-cells", i,
+					   &masterspec)) {
+		err = register_smmu_master(smmu, dev, &masterspec);
+		if (err) {
+			dev_err(dev, "failed to add master %s\n",
+				masterspec.np->name);
+			goto out_put_masters;
+		}
+
+		i++;
+	}
+	dev_notice(dev, "registered %d master devices\n", i);
+
+	parse_driver_options(smmu);
+
+	if (smmu->version > ARM_SMMU_V1 &&
+	    smmu->num_context_banks != smmu->num_context_irqs) {
+		dev_err(dev,
+			"found only %d context interrupt(s) but %d required\n",
+			smmu->num_context_irqs, smmu->num_context_banks);
+		err = -ENODEV;
+		goto out_put_masters;
+	}
+
+	for (i = 0; i < smmu->num_global_irqs; ++i) {
+		err = request_irq(smmu->irqs[i],
+				  arm_smmu_global_fault,
+				  IRQF_SHARED,
+				  "arm-smmu global fault",
+				  smmu);
+		if (err) {
+			dev_err(dev, "failed to request global IRQ %d (%u)\n",
+				i, smmu->irqs[i]);
+			goto out_free_irqs;
+		}
+	}
+
+	INIT_LIST_HEAD(&smmu->list);
+	spin_lock(&arm_smmu_devices_lock);
+	list_add(&smmu->list, &arm_smmu_devices);
+	spin_unlock(&arm_smmu_devices_lock);
+
+	arm_smmu_device_reset(smmu);
+	return 0;
+
+out_free_irqs:
+	while (i--)
+		free_irq(smmu->irqs[i], smmu);
+
+out_put_masters:
+	for (node = rb_first(&smmu->masters); node; node = rb_next(node)) {
+		struct arm_smmu_master *master
+			= container_of(node, struct arm_smmu_master, node);
+		of_node_put(master->of_node);
+	}
+
+	return err;
+}
+
+static int arm_smmu_device_remove(struct platform_device *pdev)
+{
+	int i;
+	struct device *dev = &pdev->dev;
+	struct arm_smmu_device *curr, *smmu = NULL;
+	struct rb_node *node;
+
+	spin_lock(&arm_smmu_devices_lock);
+	list_for_each_entry(curr, &arm_smmu_devices, list) {
+		if (curr->dev == dev) {
+			smmu = curr;
+			list_del(&smmu->list);
+			break;
+		}
+	}
+	spin_unlock(&arm_smmu_devices_lock);
+
+	if (!smmu)
+		return -ENODEV;
+
+	for (node = rb_first(&smmu->masters); node; node = rb_next(node)) {
+		struct arm_smmu_master *master
+			= container_of(node, struct arm_smmu_master, node);
+		of_node_put(master->of_node);
+	}
+
+	if (!bitmap_empty(smmu->context_map, ARM_SMMU_MAX_CBS))
+		dev_err(dev, "removing device with active domains!\n");
+
+	for (i = 0; i < smmu->num_global_irqs; ++i)
+		free_irq(smmu->irqs[i], smmu);
+
+	/* Turn the thing off */
+	writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
+	return 0;
+}
+
+static struct platform_driver arm_smmu_driver = {
+	.driver	= {
+		.name		= "arm-smmu",
+		.of_match_table	= of_match_ptr(arm_smmu_of_match),
+	},
+	.probe	= arm_smmu_device_dt_probe,
+	.remove	= arm_smmu_device_remove,
+};
+
+static int __init arm_smmu_init(void)
+{
+	struct device_node *np;
+	int ret;
+
+	/*
+	 * Play nice with systems that don't have an ARM SMMU by checking that
+	 * an ARM SMMU exists in the system before proceeding with the driver
+	 * and IOMMU bus operation registration.
+	 */
+	np = of_find_matching_node(NULL, arm_smmu_of_match);
+	if (!np)
+		return 0;
+
+	of_node_put(np);
+
+	ret = platform_driver_register(&arm_smmu_driver);
+	if (ret)
+		return ret;
+
+	/* Oh, for a proper bus abstraction */
+	if (!iommu_present(&platform_bus_type))
+		bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
+
+#ifdef CONFIG_ARM_AMBA
+	if (!iommu_present(&amba_bustype))
+		bus_set_iommu(&amba_bustype, &arm_smmu_ops);
+#endif
+
+#ifdef CONFIG_PCI
+	if (!iommu_present(&pci_bus_type))
+		bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
+#endif
+
+	return 0;
+}
+
+static void __exit arm_smmu_exit(void)
+{
+	return platform_driver_unregister(&arm_smmu_driver);
+}
+
+subsys_initcall(arm_smmu_init);
+module_exit(arm_smmu_exit);
+
+MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
+MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
+MODULE_LICENSE("GPL v2");
-- 
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 Dec 16 20:09:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0yRC-0004v8-8G; Tue, 16 Dec 2014 20:09: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 1Y0yRA-0004sc-EK
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:40 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	87/61-28865-38190945; Tue, 16 Dec 2014 20:09:39 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418760578!13709243!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13929 invoked from network); 16 Dec 2014 20:09:39 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:39 -0000
Received: by mail-wg0-f51.google.com with SMTP id x12so18238783wgg.38
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=22HiC/jsQkEfpC/jk6dpNNLJ4CAft6EavTkjDz75u0A=;
	b=P87DUPw5+Xs3WKv8BEqDDUogAwfqgvpdhqN4PKVFV4LWbAregMRSFMRwWIdRq9VbX4
	E6Lrxu1qT627dZcznHSOYbyDLwPaPSzSdFL+MelxmhxoTsfr1ZKHyFaEf9HDJbqEdRJC
	KBhg/i5pvLeDBjWqa9SKVguqdhRNeSJfM+UP1vGdaa9O4uJh5kicUnzleFKp7gqFRa0L
	xxrkU+NQ0W8kO/obnvmZAzPSYWkh+4nV/cjEDMOg3fmwnYFxUNqHjlmAWckP66Hr7IgW
	nYLYhQ34gFjRQYo54DKoOP3e6TwcGiAeL0xAnf4XD5+ubiQUzOxDUgQRiolIBUIMvLTO
	TQ9w==
X-Gm-Message-State: ALoCoQlVWwL9BJK2C1W8ASTTu6pXOd7IcQp3TODzswSvO2OecAKh+Um+VghZNovuysQ6hrBTM29I
X-Received: by 10.180.11.140 with SMTP id q12mr7757101wib.45.1418760577637;
	Tue, 16 Dec 2014 12:09:37 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.36
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:36 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:53 +0000
Message-Id: <1418760534-18163-13-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: ian.campbell@citrix.com,
	Andreas Herrmann <herrmann.der.user@googlemail.com>,
	manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com,
	Andreas Herrmann <andreas.herrmann@calxeda.com>
Subject: [Xen-devel] [PATCH for 4.6 12/13] xen/iommu: smmu: Introduce
	automatic stream-id-masking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Andreas Herrmann <andreas.herrmann@calxeda.com>

Try to determine mask/id values that match several stream IDs of a
master device when doing Stream ID matching. Thus the number of used
SMR groups that are required to map all stream IDs of a master device
to a context should be less than the number of SMR groups used so far
(currently one SMR group is used for one stream ID).

Taken from the Linux ML:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226100.html

Changes compare to the Linux ML version:
    - _fls doesn't exist on Xen so use fls
    - Use num_s2crs rather than num_streamids in the arm_smmu_free_smrs.
    This former is the field used to configure SRMS

Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/drivers/passthrough/arm/smmu.c | 177 +++++++++++++++++++++++++++++++++----
 1 file changed, 162 insertions(+), 15 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
index bfc1069..8a6514f 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -43,6 +43,7 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/bitops.h>
 
 #include <linux/amba/bus.h>
 
@@ -346,8 +347,10 @@ struct arm_smmu_smr {
 };
 
 struct arm_smmu_master_cfg {
-	int				num_streamids;
+	u32				num_streamids;
 	u16				streamids[MAX_MASTER_STREAMIDS];
+	int				num_s2crs;
+
 	struct arm_smmu_smr		*smrs;
 };
 
@@ -392,6 +395,9 @@ struct arm_smmu_device {
 	u32				num_context_irqs;
 	unsigned int			*irqs;
 
+	u32				smr_mask_mask;
+	u32				smr_id_mask;
+
 	struct list_head		list;
 	struct rb_root			masters;
 };
@@ -1113,6 +1119,137 @@ static void arm_smmu_free_pgtables(struct arm_smmu_domain *smmu_domain)
 	kfree(pgd_base);
 }
 
+/*
+ * For a given set N of 2**order different stream IDs (no duplicates
+ * please!) we determine values mask and id such that
+ *
+ * (1)          (x & mask) == id
+ *
+ * for each stream ID x from the given set N.
+ *
+ * If the number of bits that are set in mask equals n, then there
+ * exist 2**n different values y for which
+ *
+ * (2)          (y & mask) == id
+ *
+ * Thus if n equals order we know that for the calculated mask and id
+ * values there are exactly 2**order == 2**n stream IDs for which (1)
+ * is true. And we finally can use mask and id to configure an SMR to
+ * match all stream IDs in the set N.
+ */
+static int determine_smr_mask(struct arm_smmu_device *smmu,
+			      struct arm_smmu_master_cfg *cfg,
+			      struct arm_smmu_smr *smr, int start, int order)
+{
+	u16 i, zero_bits_mask, one_bits_mask, const_mask;
+	int nr;
+
+	nr = 1 << order;
+
+	if (nr == 1) {
+		/* no mask, use streamid to match and be done with it */
+		smr->mask = 0;
+		smr->id = cfg->streamids[start];
+		return 0;
+	}
+
+	zero_bits_mask = 0;
+	one_bits_mask = 0xffff;
+	for (i = start; i < start + nr; i++) {
+		zero_bits_mask |= cfg->streamids[i];	/* const 0 bits */
+		one_bits_mask &= cfg->streamids[i];	/* const 1 bits */
+	}
+	zero_bits_mask = ~zero_bits_mask;
+
+	/* bits having constant values (either 0 or 1) */
+	const_mask = zero_bits_mask | one_bits_mask;
+
+	i = hweight16(~const_mask);
+	if (i == order) {
+		/*
+		 * We have found a mask/id pair that matches exactly
+		 * nr = 2**order stream IDs which we used for its
+		 * calculation.
+		 */
+		smr->mask = ~const_mask;
+		smr->id = one_bits_mask;
+	} else {
+		/*
+		 * No usable mask/id pair for this set of streamids.
+		 * If i > order then mask/id would match more than nr
+		 * streamids.
+		 * If i < order then mask/id would match less than nr
+		 * streamids. (In this case we potentially have used
+		 * some duplicate streamids for the calculation.)
+		 */
+		return 1;
+	}
+
+	if (((smr->mask & smmu->smr_mask_mask) != smr->mask) ||
+		((smr->id & smmu->smr_id_mask) != smr->id))
+		/* insufficient number of mask/id bits */
+		return 1;
+
+	return 0;
+}
+
+static int determine_smr_mapping(struct arm_smmu_device *smmu,
+				 struct arm_smmu_master_cfg *cfg,
+				 struct arm_smmu_smr *smrs, int max_smrs)
+{
+	int nr_sid, nr, i, bit, start;
+
+	/*
+	 * This function is called only once -- when a master is added
+	 * to a domain. If cfg->num_s2crs != 0 then this master
+	 * was already added to a domain.
+	 */
+	if (cfg->num_s2crs)
+		return -EINVAL;
+
+	start = nr = 0;
+	nr_sid = cfg->num_streamids;
+	do {
+		/*
+		 * largest power-of-2 number of streamids for which to
+		 * determine a usable mask/id pair for stream matching
+		 */
+		bit = fls(nr_sid) - 1;
+		if (bit < 0)
+			return 0;
+
+		/*
+		 * iterate over power-of-2 numbers to determine
+		 * largest possible mask/id pair for stream matching
+		 * of next 2**i streamids
+		 */
+		for (i = bit; i >= 0; i--) {
+			if (!determine_smr_mask(smmu, cfg,
+						&smrs[cfg->num_s2crs],
+						start, i))
+				break;
+		}
+
+		if (i < 0)
+			goto out;
+
+		nr = 1 << i;
+		nr_sid -= nr;
+		start += nr;
+		cfg->num_s2crs++;
+	} while (cfg->num_s2crs <= max_smrs);
+
+out:
+	if (nr_sid) {
+		/* not enough mapping groups available */
+		cfg->num_s2crs = 0;
+		return -ENOSPC;
+	}
+
+	return 0;
+}
+
+
 static void arm_smmu_domain_destroy(struct iommu_domain *domain)
 {
 	struct arm_smmu_domain *smmu_domain = domain->priv;
@@ -1129,7 +1266,7 @@ static void arm_smmu_domain_destroy(struct iommu_domain *domain)
 static int arm_smmu_master_configure_smrs(struct arm_smmu_device *smmu,
 					  struct arm_smmu_master_cfg *cfg)
 {
-	int i;
+	int i, max_smrs, ret;
 	struct arm_smmu_smr *smrs;
 	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
 
@@ -1139,31 +1276,32 @@ static int arm_smmu_master_configure_smrs(struct arm_smmu_device *smmu,
 	if (cfg->smrs)
 		return -EEXIST;
 
-	smrs = kmalloc_array(cfg->num_streamids, sizeof(*smrs), GFP_KERNEL);
+	max_smrs = min(smmu->num_mapping_groups, cfg->num_streamids);
+	smrs = kmalloc(sizeof(*smrs) * max_smrs, GFP_KERNEL);
 	if (!smrs) {
 		dev_err(smmu->dev, "failed to allocate %d SMRs\n",
-			cfg->num_streamids);
+			max_smrs);
 		return -ENOMEM;
 	}
 
+	ret = determine_smr_mapping(smmu, cfg, smrs, max_smrs);
+	if (ret)
+		goto err_free_smrs;
+
 	/* Allocate the SMRs on the SMMU */
-	for (i = 0; i < cfg->num_streamids; ++i) {
+	for (i = 0; i < cfg->num_s2crs; ++i) {
 		int idx = __arm_smmu_alloc_bitmap(smmu->smr_map, 0,
 						  smmu->num_mapping_groups);
 		if (IS_ERR_VALUE(idx)) {
 			dev_err(smmu->dev, "failed to allocate free SMR\n");
-			goto err_free_smrs;
+			goto err_free_bitmap;
 		}
 
-		smrs[i] = (struct arm_smmu_smr) {
-			.idx	= idx,
-			.mask	= 0, /* We don't currently share SMRs */
-			.id	= cfg->streamids[i],
-		};
+		smrs[i].idx = idx;
 	}
 
 	/* It worked! Now, poke the actual hardware */
-	for (i = 0; i < cfg->num_streamids; ++i) {
+	for (i = 0; i < cfg->num_s2crs; ++i) {
 		u32 reg = SMR_VALID | smrs[i].id << SMR_ID_SHIFT |
 			  smrs[i].mask << SMR_MASK_SHIFT;
 		writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_SMR(smrs[i].idx));
@@ -1172,9 +1310,11 @@ static int arm_smmu_master_configure_smrs(struct arm_smmu_device *smmu,
 	cfg->smrs = smrs;
 	return 0;
 
-err_free_smrs:
+err_free_bitmap:
 	while (--i >= 0)
 		__arm_smmu_free_bitmap(smmu->smr_map, smrs[i].idx);
+	cfg->num_s2crs = 0;
+err_free_smrs:
 	kfree(smrs);
 	return -ENOSPC;
 }
@@ -1190,13 +1330,15 @@ static void arm_smmu_master_free_smrs(struct arm_smmu_device *smmu,
 		return;
 
 	/* Invalidate the SMRs before freeing back to the allocator */
-	for (i = 0; i < cfg->num_streamids; ++i) {
+	for (i = 0; i < cfg->num_s2crs; ++i) {
 		u8 idx = smrs[i].idx;
 
 		writel_relaxed(~SMR_VALID, gr0_base + ARM_SMMU_GR0_SMR(idx));
 		__arm_smmu_free_bitmap(smmu->smr_map, idx);
 	}
 
+	cfg->num_s2crs = 0;
+
 	cfg->smrs = NULL;
 	kfree(smrs);
 }
@@ -1213,12 +1355,15 @@ static int arm_smmu_domain_add_master(struct arm_smmu_domain *smmu_domain,
 	if (ret)
 		return ret == -EEXIST ? 0 : ret;
 
-	for (i = 0; i < cfg->num_streamids; ++i) {
+	if (!cfg->num_s2crs)
+		cfg->num_s2crs = cfg->num_streamids;
+	for (i = 0; i < cfg->num_s2crs; ++i) {
 		u32 idx, s2cr;
 
 		idx = cfg->smrs ? cfg->smrs[i].idx : cfg->streamids[i];
 		s2cr = S2CR_TYPE_TRANS |
 		       (smmu_domain->cfg.cbndx << S2CR_CBNDX_SHIFT);
+		dev_dbg(smmu->dev, "S2CR%d: 0x%x\n", idx, s2cr);
 		writel_relaxed(s2cr, gr0_base + ARM_SMMU_GR0_S2CR(idx));
 	}
 
@@ -1890,6 +2035,8 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
 				mask, sid);
 			return -ENODEV;
 		}
+		smmu->smr_mask_mask = mask;
+		smmu->smr_id_mask = sid;
 
 		dev_notice(smmu->dev,
 			   "\tstream matching with %u register groups, mask 0x%x",
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yQq-0004kw-Aj; Tue, 16 Dec 2014 20:09: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 1Y0yQp-0004kr-IY
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:19 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	F3/6C-25547-E6190945; Tue, 16 Dec 2014 20:09:18 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418760557!13822091!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19994 invoked from network); 16 Dec 2014 20:09:18 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:18 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so18393568wgg.19
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id;
	bh=475IzZf5L/OQOXHYfYCmv9DhWErdDMQZGFRlYEncnYI=;
	b=camUb/ahfYSVmnOTdszMtDcqJk/wwOQGNiM07K3kIB8P/7KAkxrKtYGe+jYRc+OC8M
	+zGbwQOGSgjQkgB4889G+68eJlTb5rnoBXiVgVHV51zMrc8X32WbRHiVwov4Lz+kDsbI
	GlZGF6DLSgz1d6TV3VMmndVDb9HxGd9U0FxMTnA4t4TWPRnTjYHdwHZrwpcjpQ6RxQTO
	Mo1TePI8slp2uqKP5Ou7rid9+UmhOURycUEQQGgk6DBvSWZnviW7N0FBkMOHmbDGBC/X
	xLk9YQaxvvqnif/lyd6vMmyRXZOEhuh2iN7IGRGsDzU5YegbmSz7yeERLe63Ka1nejDR
	0mTg==
X-Gm-Message-State: ALoCoQkyrgcE7Kgy8+fMAE9y8C90bcdmun6HHrwHfRUpM4AbOL///NFaDSxcD6nOtkvEUcL7kPxD
X-Received: by 10.194.174.72 with SMTP id bq8mr63024577wjc.120.1418760556951; 
	Tue, 16 Dec 2014 12:09:16 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.15
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:15 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:41 +0000
Message-Id: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 00/13] xen/arm: Resync the SMMU driver
	with the Linux 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

Hello,

The SMMU drivers has diverged from Linux. Having our own driver doesn't make
any benefits and make difficult to backport fixes and/or porting features such
as PCI.

With this series, the core of the SMMU drivers (i.e copied from Linux) is mostly
not modified. If it's the case a comment /* Xen: ... */ has been added
to explain why.

To make the change obvious the resync of the SMMU code is mode in several
step:
    1) Revert the current SMMU driver (patch #6)
    2) Import as it is the driver from Linux (patch #10)
    3) Apply 2 fixes useful to correctly use the SATA with the SMMU on
    calxeda. I don't know why Linux didn't yet applied (patch #11-12)
    4) Changes for Xen (patch #13)

I also took the opportunity of the resync to consolidate the iommu ops in
a single set. When I added the IOMMU set to handle device tree passthrough (
ops assign_dt_device and reassign_dt_device), I didn't think about
merging the ops with the PCI one. In fact Linux is using a single set
and have only few lines per driver specific to each set (PCI or device tree).

A branch is available with all the changes:
    git://xenbits.xen.org/people/julieng/xen-unstable.git branch smmu-rework

Sincerely yours,

Andreas Herrmann (2):
  xen/iommu: smmu: Check for duplicate stream IDs when registering
    master devices
  xen/iommu: smmu: Introduce automatic stream-id-masking

Julien Grall (11):
  xen/arm: gic-v2: Change the device name in DT_DEVICE_START
  xen/arm: vgic: Drop unecessary include asm/device.h
  xen: Introduce ACCESS_ONCE macro
  xen/dt: Extend dt_device_match to possibly store data
  xen/arm: device: Rename device_type into device_match
  xen/iommu: arm: Remove temporary the SMMU driver
  xen: Introduce a generic way to describe device
  xen/iommu: Consolidate device assignment ops into a single set
  xen/arm: Describe device supported by a driver with dt_match_node
  xen/iommu: arm: Import the SMMU driver from Linux
  xen/iommu: smmu: Add Xen specific code to be able to use the driver

 xen/arch/arm/device.c                       |   27 +-
 xen/arch/arm/domain_build.c                 |    2 +-
 xen/arch/arm/gic-v2.c                       |   15 +-
 xen/arch/arm/gic-v3.c                       |   10 +-
 xen/arch/arm/gic.c                          |    2 +-
 xen/arch/arm/platform.c                     |    2 +-
 xen/arch/arm/vgic-v2.c                      |    1 -
 xen/arch/arm/vgic-v3.c                      |    1 -
 xen/common/Makefile                         |    1 +
 xen/common/device.c                         |   21 +
 xen/common/device_tree.c                    |   13 +-
 xen/drivers/char/dt-uart.c                  |    4 +-
 xen/drivers/char/exynos4210-uart.c          |   10 +-
 xen/drivers/char/ns16550.c                  |   14 +-
 xen/drivers/char/omap-uart.c                |   10 +-
 xen/drivers/char/pl011.c                    |   10 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c |   14 +-
 xen/drivers/passthrough/arm/iommu.c         |    2 +-
 xen/drivers/passthrough/arm/smmu.c          | 4107 +++++++++++++++++----------
 xen/drivers/passthrough/device_tree.c       |    5 +-
 xen/drivers/passthrough/pci.c               |   22 +-
 xen/drivers/passthrough/vtd/iommu.c         |   19 +-
 xen/include/asm-arm/device.h                |   19 +-
 xen/include/asm-arm/gic.h                   |   15 +-
 xen/include/asm-x86/device.h                |   17 +
 xen/include/xen/compiler.h                  |   14 +
 xen/include/xen/device.h                    |   40 +
 xen/include/xen/device_tree.h               |   19 +-
 xen/include/xen/iommu.h                     |   18 +-
 xen/include/xen/pci.h                       |   12 +
 30 files changed, 2843 insertions(+), 1623 deletions(-)
 create mode 100644 xen/common/device.c
 create mode 100644 xen/include/asm-x86/device.h
 create mode 100644 xen/include/xen/device.h

-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yR7-0004qL-AG; Tue, 16 Dec 2014 20:09:37 +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 1Y0yR5-0004pj-W2
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:36 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	46/14-02696-F7190945; Tue, 16 Dec 2014 20:09:35 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418760574!15504407!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31596 invoked from network); 16 Dec 2014 20:09:34 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:34 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so14845137wib.1
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=XYSpGQOswUe9pDTIAJCMYrH5Vlf6V9EDF7ijvfTFVj4=;
	b=gg8Bv+JSjq7jsNCvltIH1vt9sgz2mr1h6x2jwC5PWAZ0yEq3SWxq9nfiz271udWK7H
	IDpx2cJPU/dCkOvoQv9KJ7m66HOYhJWtixOirbg1QN2odKJfuIIBI6JfBEC0EJWW095Z
	O/imPaXcz4wRxb5QjZrWpLikricgipy2zRnX4Sz33R53gl5wNc+CHjcQWza+tQxUZ/8p
	L9vYWMbqCFoGALxd5vYlN6IkSokmXtvdXBbjwI1IwSedH7Dgo4URIyM+jLoxcTcCqPsP
	i0pP6r8I4G2kzWNVUL9zOxKB3xPAAcHeRBkua73f4JpI2L9HbSDu0s4NEdJKrbl2I5Ca
	Typw==
X-Gm-Message-State: ALoCoQkp0FwCz3Ql/MLeltDE6A4SGCFJ68Ip1CgdnRI1ize5n0clxg6AfYAyJNbaGcztEROYEAFU
X-Received: by 10.194.241.194 with SMTP id wk2mr65135860wjc.132.1418760572673; 
	Tue, 16 Dec 2014 12:09:32 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.31
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:31 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:50 +0000
Message-Id: <1418760534-18163-10-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 09/13] xen/arm: Describe device
	supported by a driver with dt_match_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xen is currently using list a compatible string to know if the driver
can use device node. This leads to have double definition in the GIC
code.

Futhermore Linux drivers is using dt_match_node (actually called of_device_id
in Linux) to list device supported by the drivers.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/device.c              | 21 ++-------------------
 xen/arch/arm/gic-v2.c              | 10 ++++------
 xen/arch/arm/gic-v3.c              |  8 ++++----
 xen/drivers/char/exynos4210-uart.c |  8 ++++----
 xen/drivers/char/ns16550.c         | 12 ++++++------
 xen/drivers/char/omap-uart.c       |  8 ++++----
 xen/drivers/char/pl011.c           |  8 ++++----
 xen/include/asm-arm/device.h       |  8 ++++++--
 xen/include/asm-arm/gic.h          | 15 +++++----------
 9 files changed, 39 insertions(+), 59 deletions(-)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index de702ff..1993929 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -23,23 +23,6 @@
 
 extern const struct device_desc _sdevice[], _edevice[];
 
-static bool_t __init device_is_compatible(const struct device_desc *desc,
-                                          const struct dt_device_node *dev)
-{
-    const char *const *compat;
-
-    if ( !desc->compatible )
-        return 0;
-
-    for ( compat = desc->compatible; *compat; compat++ )
-    {
-        if ( dt_device_is_compatible(dev, *compat) )
-            return 1;
-    }
-
-    return 0;
-}
-
 int __init device_init(struct dt_device_node *dev, enum device_match type,
                        const void *data)
 {
@@ -55,7 +38,7 @@ int __init device_init(struct dt_device_node *dev, enum device_match type,
         if ( desc->type != type )
             continue;
 
-        if ( device_is_compatible(desc, dev) )
+        if ( dt_match_node(desc->dt_match, dev) )
         {
             ASSERT(desc->init != NULL);
 
@@ -75,7 +58,7 @@ enum device_match device_get_type(const struct dt_device_node *dev)
 
     for ( desc = _sdevice; desc != _edevice; desc++ )
     {
-        if ( device_is_compatible(desc, dev) )
+        if ( dt_match_node(desc->dt_match, dev) )
             return desc->type;
     }
 
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 048350b..db3795d 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -763,16 +763,14 @@ static int __init gicv2_init(struct dt_device_node *node, const void *data)
     return 0;
 }
 
-static const char * const gicv2_dt_compat[] __initconst =
+static const struct dt_device_match gicv2_dt_match[] __initconst =
 {
-    DT_COMPAT_GIC_CORTEX_A15,
-    DT_COMPAT_GIC_CORTEX_A7,
-    DT_COMPAT_GIC_400,
-    NULL
+    DT_MATCH_GIC_V2,
+    { /* sentinel */ },
 };
 
 DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
-        .compatible = gicv2_dt_compat,
+        .dt_match = gicv2_dt_match,
         .init = gicv2_init,
 DT_DEVICE_END
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index c6d1876..1191cb7 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1278,14 +1278,14 @@ static int __init gicv3_init(struct dt_device_node *node, const void *data)
     return res;
 }
 
-static const char * const gicv3_dt_compat[] __initconst =
+static const struct dt_device_match gicv3_dt_match[] __initconst =
 {
-    DT_COMPAT_GIC_V3,
-    NULL
+    DT_MATCH_GIC_V3,
+    { /* sentinel */ },
 };
 
 DT_DEVICE_START(gicv3, "GICv3", DEVICE_GIC)
-        .compatible = gicv3_dt_compat,
+        .dt_match = gicv3_dt_match,
         .init = gicv3_init,
 DT_DEVICE_END
 
diff --git a/xen/drivers/char/exynos4210-uart.c b/xen/drivers/char/exynos4210-uart.c
index 75246e1..b59e64a 100644
--- a/xen/drivers/char/exynos4210-uart.c
+++ b/xen/drivers/char/exynos4210-uart.c
@@ -352,14 +352,14 @@ static int __init exynos4210_uart_init(struct dt_device_node *dev,
     return 0;
 }
 
-static const char * const exynos4210_dt_compat[] __initconst =
+static const struct dt_device_match exynos4210_dt_match[] __initconst =
 {
-    "samsung,exynos4210-uart",
-    NULL
+    DT_MATCH_COMPATIBLE("samsung,exynos4210-uart"),
+    { /* sentinel */ },
 };
 
 DT_DEVICE_START(exynos4210, "Exynos 4210 UART", DEVICE_SERIAL)
-        .compatible = exynos4210_dt_compat,
+        .dt_match = exynos4210_dt_match,
         .init = exynos4210_uart_init,
 DT_DEVICE_END
 
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 6df3f95..a0373a9 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1185,16 +1185,16 @@ static int __init ns16550_uart_dt_init(struct dt_device_node *dev,
     return 0;
 }
 
-static const char * const ns16550_dt_compat[] __initconst =
+static const struct dt_device_match ns16550_dt_match[] __initconst =
 {
-    "ns16550",
-    "ns16550a",
-    "snps,dw-apb-uart",
-    NULL
+    DT_MATCH_COMPATIBLE("ns16550"),
+    DT_MATCH_COMPATIBLE("ns16550a"),
+    DT_MATCH_COMPATIBLE("snps,dw-apb-uart"),
+    { /* sentinel */ },
 };
 
 DT_DEVICE_START(ns16550, "NS16550 UART", DEVICE_SERIAL)
-        .compatible = ns16550_dt_compat,
+        .dt_match = ns16550_dt_match,
         .init = ns16550_uart_dt_init,
 DT_DEVICE_END
 
diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
index c4cd442..3df80cf 100644
--- a/xen/drivers/char/omap-uart.c
+++ b/xen/drivers/char/omap-uart.c
@@ -350,14 +350,14 @@ static int __init omap_uart_init(struct dt_device_node *dev,
     return 0;
 }
 
-static const char * const omap_uart_dt_compat[] __initconst =
+static const struct dt_device_match omap_uart_dt_match[] __initconst =
 {
-    "ti,omap4-uart",
-    NULL
+    DT_MATCH_COMPATIBLE("ti,omap4-uart"),
+    { /* sentinel */ },
 };
 
 DT_DEVICE_START(omap_uart, "OMAP UART", DEVICE_SERIAL)
-    .compatible = omap_uart_dt_compat,
+    .dt_match = omap_uart_dt_match,
     .init = omap_uart_init,
 DT_DEVICE_END
 
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index cc91224..e6ecf0b 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -269,14 +269,14 @@ static int __init pl011_uart_init(struct dt_device_node *dev,
     return 0;
 }
 
-static const char * const pl011_dt_compat[] __initconst =
+static const struct dt_device_match pl011_dt_match[] __initconst =
 {
-    "arm,pl011",
-    NULL
+    DT_MATCH_COMPATIBLE("arm,pl011"),
+    { /* sentinel */ },
 };
 
 DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
-        .compatible = pl011_dt_compat,
+        .dt_match = pl011_dt_match,
         .init = pl011_uart_init,
 DT_DEVICE_END
 
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index fdcd097..a2711a3 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -3,6 +3,10 @@
 
 #include <xen/init.h>
 
+struct dev_archdata {
+    void *iommu;    /* IOMMU private data */
+};
+
 struct dt_device_node;
 
 enum device_match
@@ -19,8 +23,8 @@ struct device_desc {
     const char *name;
     /* Device type */
     enum device_match type;
-    /* Array of device tree 'compatible' strings */
-    const char *const *compatible;
+    /* List of devices supported by this driver */
+    const struct dt_device_match *dt_match;
     /* Device initialization */
     int (*init)(struct dt_device_node *dev, const void *data);
 };
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 187dc46..73ca3cf 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -152,17 +152,12 @@
 #include <xen/irq.h>
 #include <asm-arm/vgic.h>
 
-#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_MATCH_GIC_V2                                             \
+    DT_MATCH_COMPATIBLE("arm,cortex-a15-gic"),                      \
+    DT_MATCH_COMPATIBLE("arm,cortex-a7-gic"),                       \
+    DT_MATCH_COMPATIBLE("arm,gic-400")
 
-#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)
-
-#define DT_COMPAT_GIC_V3             "arm,gic-v3"
-
-#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_V3)
+#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3")
 
 /*
  * GICv3 registers that needs to be saved/restored
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yQu-0004lL-1z; Tue, 16 Dec 2014 20:09:24 +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 1Y0yQs-0004l4-AP
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:22 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	8E/C7-03145-17190945; Tue, 16 Dec 2014 20:09:21 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418760558!15456600!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30757 invoked from network); 16 Dec 2014 20:09:18 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:18 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so13515548wiw.2
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=IsLaah21BAZoisIBljlP+O0/Yw8Xt7G7kFX+BoClczI=;
	b=SlNwxfNbRTFcbH0WLmlZUy28PTi3hY3PKiUIOlZ6O6SVOy1S+UVI/jIafhUwTp4l9m
	1CLGejWB5DkqUaK47H69ERP3ULsUrRXneg3SE9gVw806POWV65OGt8k0Ln2zx8ij7Mp0
	7b7klE4TcWN8EV277baizFA9tWdlbh6mNh3fYpyqFPrYK85GpcTfZxakglw2cSuhs0Yx
	co9tfa07NpfZUFDJA8RVSH2wThKeqftmKq2ltKgubfj3xskpic4xX+B8Fn07o9DUOssF
	9dpOvoNeLhznnkMdkGDk8yt5wAs67UX1idz1rNOZeEc4Mjelbh2tjVCGh7eAybCpq8Gw
	XF2w==
X-Gm-Message-State: ALoCoQkvLZ+Ah9JvIYDbtcWnTqCk7kd+dwlvze8trL8N1q2huubsmcViFHqg1fpAM+F4HqU9yy8e
X-Received: by 10.180.210.236 with SMTP id mx12mr7912770wic.16.1418760558683; 
	Tue, 16 Dec 2014 12:09:18 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.17
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:17 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:42 +0000
Message-Id: <1418760534-18163-2-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 01/13] xen/arm: gic-v2: Change the
	device name in DT_DEVICE_START
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm not sure why a ':' has been added in the name... But none of the
other usages doesn't have it.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/gic-v2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..f149e09 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -772,7 +772,7 @@ static const char * const gicv2_dt_compat[] __initconst =
     NULL
 };
 
-DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
+DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
         .compatible = gicv2_dt_compat,
         .init = gicv2_init,
 DT_DEVICE_END
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yRA-0004tU-NO; Tue, 16 Dec 2014 20:09:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Y0yR9-0004r7-06
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:39 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	1E/B0-17735-28190945; Tue, 16 Dec 2014 20:09:38 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418760577!13701295!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30414 invoked from network); 16 Dec 2014 20:09:37 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:37 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so18363402wgh.32
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:in-reply-to
	:references;
	bh=KjaTxnjl8hQiADC0gkrtIY9FvnSCbtTlJs7PVFDewSM=;
	b=ViI+UVA9rKCbDHJGpFlMqBmad3+sxOoGn0w+hkYqQVBJSh8zaUno65A9K/zFitxp1F
	nkVrnznUE5aPK5gQk2xqvScaCA/7Jcm1FZcv6MXnpkihW2QUH2C0QRIXHOqNYY94e4gj
	Zl32+T3BCUkImzO5eQ5k0e903i2znGaoxts7DCDFXbTB6+xyKTH9+Pu1KDVy4o24IssA
	uX8Ig/gXNuYjLMG+gKxM5BUKkTyEvVUyKNvu0uLbCfR4MbJOPsv9StJ9N5ghxre8WWQM
	Z2UrhleWYZm0z4xT73EMFKg6vUef9b0951qyEc4odRafFyIpauOYSexdgQcZzm0MMBZo
	H1jw==
X-Gm-Message-State: ALoCoQn6Mhy2Fl+jpiEJftvsLgZ8h715E778bq/CEz2yRzD9xn2FEsq5gWRrdRvjx2E46aiMFpvH
X-Received: by 10.194.222.98 with SMTP id ql2mr65819715wjc.36.1418760576146;
	Tue, 16 Dec 2014 12:09:36 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.34
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:35 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:52 +0000
Message-Id: <1418760534-18163-12-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: ian.campbell@citrix.com,
	Andreas Herrmann <herrmann.der.user@googlemail.com>,
	manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	stefano.stabellini@citrix.com,
	Andreas Herrmann <andreas.herrmann@calxeda.com>
Subject: [Xen-devel] [PATCH for 4.6 11/13] xen/iommu: smmu: Check for
	duplicate stream IDs when registering master 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

From: Andreas Herrmann <andreas.herrmann@calxeda.com>

If DT information lists one stream ID twice for the master devices of
an SMMU this can cause a multi match when stream ID matching is used.
For stream ID indexing this might trigger an overwrite of an S2CR that
is already in use.

So better check for duplicates when DT information is parsed.

Taken from the linux ML:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226099.html

Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/drivers/passthrough/arm/smmu.c | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
index 6cd47b7..bfc1069 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -51,6 +51,9 @@
 /* Maximum number of stream IDs assigned to a single device */
 #define MAX_MASTER_STREAMIDS		MAX_PHANDLE_ARGS
 
+/* Maximum stream ID */
+#define ARM_SMMU_MAX_STREAMID		(SZ_64K - 1)
+
 /* Maximum number of context banks per SMMU */
 #define ARM_SMMU_MAX_CBS		128
 
@@ -519,7 +522,8 @@ static int insert_smmu_master(struct arm_smmu_device *smmu,
 
 static int register_smmu_master(struct arm_smmu_device *smmu,
 				struct device *dev,
-				struct of_phandle_args *masterspec)
+				struct of_phandle_args *masterspec,
+				unsigned long *smmu_sids)
 {
 	int i;
 	struct arm_smmu_master *master;
@@ -556,6 +560,12 @@ static int register_smmu_master(struct arm_smmu_device *smmu,
 				masterspec->np->name, smmu->num_mapping_groups);
 			return -ERANGE;
 		}
+
+		if (test_and_set_bit(streamid, smmu_sids)) {
+			dev_err(dev, "duplicate stream ID (%d)\n", streamid);
+			return -EEXIST;
+		}
+
 		master->cfg.streamids[i] = streamid;
 	}
 	return insert_smmu_master(smmu, master);
@@ -1977,6 +1987,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct rb_node *node;
 	struct of_phandle_args masterspec;
+	unsigned long *smmu_sids;
 	int num_irqs, i, err;
 
 	smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
@@ -2035,20 +2046,30 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 	if (err)
 		return err;
 
+	smmu_sids = kzalloc(BITS_TO_LONGS(ARM_SMMU_MAX_STREAMID) *
+			sizeof(long), GFP_KERNEL);
+	if (!smmu_sids) {
+		dev_err(dev,
+			"failed to allocate bitmap for stream ID tracking\n");
+		return -ENOMEM;
+	}
+
 	i = 0;
 	smmu->masters = RB_ROOT;
 	while (!of_parse_phandle_with_args(dev->of_node, "mmu-masters",
 					   "#stream-id-cells", i,
 					   &masterspec)) {
-		err = register_smmu_master(smmu, dev, &masterspec);
+		err = register_smmu_master(smmu, dev, &masterspec, smmu_sids);
 		if (err) {
 			dev_err(dev, "failed to add master %s\n",
 				masterspec.np->name);
+			kfree(smmu_sids);
 			goto out_put_masters;
 		}
 
 		i++;
 	}
+	kfree(smmu_sids);
 	dev_notice(dev, "registered %d master devices\n", i);
 
 	parse_driver_options(smmu);
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yQy-0004mW-Et; Tue, 16 Dec 2014 20:09:28 +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 1Y0yQw-0004m6-SQ
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:26 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	23/64-02697-67190945; Tue, 16 Dec 2014 20:09:26 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418760565!13732323!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17798 invoked from network); 16 Dec 2014 20:09:25 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:25 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so14844743wib.1
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=l/HuTzVwQLAYGQ03c/KQMM0l+NZKWle3HG8EqTyC+Ec=;
	b=lTGYTaLEDMQpWUivKTwEO56jVi+WMjuvC56NktOtCjEq5SUpLut+07BJVqDYNsSpCu
	vAb4VF0eZdpyIOh6tk7vViy/3i5MxHPacObx1MdZCAcpvFjVNrUcrJxhOCSAm5wW0MiV
	kkGhxfOJu5sh4+kcT5/PNMxwW+dSoWoU41RK1dlHdCL5PvcJ0RSNVZ7YqZJePV3PlsYt
	Vzo8W+yifEt8lqxW6LaUKz6Hy5YhDZbHcIiaqcDK0ex3iagEXQ3X87cPNIwAsDIM8DnG
	zXz2lYPV4wvpjPRhzvVKOXByGfU9EZrHZXdd1DXyHma51ALAkqPDFGclFti1nxOHrrHg
	bGjA==
X-Gm-Message-State: ALoCoQluryHnqYmvGdtfraz8fbGVN+xOHsY4Mzxpv5MTCqr4Uaq0+3aELb6DqqdLqMA9qBZG5un2
X-Received: by 10.194.242.196 with SMTP id ws4mr32207316wjc.1.1418760565432;
	Tue, 16 Dec 2014 12:09:25 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.23
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:24 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:46 +0000
Message-Id: <1418760534-18163-6-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 05/13] xen/arm: device: Rename
	device_type into device_match
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This enum was used for matching a specific device and not to get the
type of device.

Hence the name device_type will be used for another purpose later.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/device.c        | 4 ++--
 xen/include/asm-arm/device.h | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 59e94c0..693b9af 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -40,7 +40,7 @@ static bool_t __init device_is_compatible(const struct device_desc *desc,
     return 0;
 }
 
-int __init device_init(struct dt_device_node *dev, enum device_type type,
+int __init device_init(struct dt_device_node *dev, enum device_match type,
                        const void *data)
 {
     const struct device_desc *desc;
@@ -67,7 +67,7 @@ int __init device_init(struct dt_device_node *dev, enum device_type type,
     return -EBADF;
 }
 
-enum device_type device_get_type(const struct dt_device_node *dev)
+enum device_match device_get_type(const struct dt_device_node *dev)
 {
     const struct device_desc *desc;
 
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 74a80c6..72a9028 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -4,7 +4,7 @@
 #include <xen/init.h>
 #include <xen/device_tree.h>
 
-enum device_type
+enum device_match
 {
     DEVICE_SERIAL,
     DEVICE_IOMMU,
@@ -17,7 +17,7 @@ struct device_desc {
     /* Device name */
     const char *name;
     /* Device type */
-    enum device_type type;
+    enum device_match type;
     /* Array of device tree 'compatible' strings */
     const char *const *compatible;
     /* Device initialization */
@@ -32,7 +32,7 @@ struct device_desc {
  *
  *  Return 0 on success.
  */
-int __init device_init(struct dt_device_node *dev, enum device_type type,
+int __init device_init(struct dt_device_node *dev, enum device_match type,
                        const void *data);
 
 /**
@@ -41,7 +41,7 @@ int __init device_init(struct dt_device_node *dev, enum device_type type,
  *
  * Return the device type on success or DEVICE_ANY on failure
  */
-enum device_type device_get_type(const struct dt_device_node *dev);
+enum device_match device_get_type(const struct dt_device_node *dev);
 
 #define DT_DEVICE_START(_name, _namestr, _type)                     \
 static const struct device_desc __dev_desc_##_name __used           \
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yQx-0004m8-11; Tue, 16 Dec 2014 20:09: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 1Y0yQv-0004ln-Dk
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:25 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	D6/35-26858-47190945; Tue, 16 Dec 2014 20:09:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418760563!13822115!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20969 invoked from network); 16 Dec 2014 20:09:24 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:24 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so13487902wib.4
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:in-reply-to
	:references;
	bh=2Z7BqoOVEVCC76a/Ky8UOb0m6/eVODAyGoCDfIR31DQ=;
	b=lPnvD2sx3bixmzNlxWBqkee3ZkHZLv6tDcmOAq1IG2rvhx6Xni59nzgLU7m9l2wDCZ
	boJY/EuctNoLhW/ixiPrayCVCsklGzr0xV/3bVv1YecMdRaLFfDssSqzaUDx8Et1+fJp
	gkELxI/ioTFKZx+3Bv9U7oSQWagZIcydQx8ZbzUuKW8S310Qi3yQh4Yb9NEV/WtvIeAO
	F7C2oa+Nr/TJgeU4zZ6FCHui1NBTjY13npDsKYWaCLt1OYQ4CnBLyu5zBLDox785OOXd
	BYGPozZRo5YEKdvLDZypMCK3SzEsV05V/aV/xfKutUH1wMsq41z/L/68HVKb8SC/3e6I
	mjaA==
X-Gm-Message-State: ALoCoQl9CxdT7JRGebsHHGHZqvSDOSX5RsIVRjB+tdW8NBc4RC0KPFPOJyYDQxAZWbb+qh1F7faH
X-Received: by 10.194.80.68 with SMTP id p4mr28995818wjx.108.1418760563774;
	Tue, 16 Dec 2014 12:09:23 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.21
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:22 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:45 +0000
Message-Id: <1418760534-18163-5-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 04/13] xen/dt: Extend dt_device_match to
	possibly store 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>
MIME-Version: 1.0
Content-Type: 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 drivers may want to configure differently the device depending on
the compatible string.

Also modify the return type of dt_match_node to return the matching
structure.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/platform.c       |  2 +-
 xen/common/device_tree.c      | 12 ++++++------
 xen/include/xen/device_tree.h |  6 ++++--
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index cb4cda8..a79a098 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -157,7 +157,7 @@ bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
     if ( platform && platform->blacklist_dev )
         blacklist = platform->blacklist_dev;
 
-    return dt_match_node(blacklist, node);
+    return (dt_match_node(blacklist, node) != NULL);
 }
 
 unsigned int platform_dom0_evtchn_ppi(void)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f72b2e9..34a1b9e 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -290,11 +290,12 @@ struct dt_device_node *dt_find_node_by_alias(const char *alias)
     return NULL;
 }
 
-bool_t dt_match_node(const struct dt_device_match *matches,
-                     const struct dt_device_node *node)
+const struct dt_device_match *
+dt_match_node(const struct dt_device_match *matches,
+              const struct dt_device_node *node)
 {
     if ( !matches )
-        return 0;
+        return NULL;
 
     while ( matches->path || matches->type ||
             matches->compatible || matches->not_available )
@@ -314,12 +315,11 @@ bool_t dt_match_node(const struct dt_device_match *matches,
             match &= !dt_device_is_available(node);
 
         if ( match )
-            return match;
-
+            return matches;
         matches++;
     }
 
-    return 0;
+    return NULL;
 }
 
 const struct dt_device_node *dt_get_parent(const struct dt_device_node *node)
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 08db8bc..6502369 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -28,6 +28,7 @@ struct dt_device_match {
     const char *type;
     const char *compatible;
     const bool_t not_available;
+    const void *data;
 };
 
 #define DT_MATCH_PATH(p)                { .path = p }
@@ -547,8 +548,9 @@ bool_t dt_device_is_available(const struct dt_device_node *device);
  *
  * Returns true if the device node match one of dt_device_match.
  */
-bool_t dt_match_node(const struct dt_device_match *matches,
-                     const struct dt_device_node *node);
+const struct dt_device_match *
+dt_match_node(const struct dt_device_match *matches,
+              const struct dt_device_node *node);
 
 /**
  * dt_find_matching_node - Find a node based on an dt_device_match match table
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yR2-0004oH-UO; Tue, 16 Dec 2014 20:09:32 +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 1Y0yR1-0004nY-HE
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:31 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	6B/04-24859-A7190945; Tue, 16 Dec 2014 20:09:30 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418760567!13854758!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6378 invoked from network); 16 Dec 2014 20:09:27 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:27 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so18393908wgg.19
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=/Gab5CmP+INPq6SF2ADC1M7h2D67CF8nvpnxIOuw4eM=;
	b=K1rvZAQKt5tAUTJAkDxmPjhXsQmYbynZWYLTmd4I5jyR69GVdpaKisqaLXYxrP5Woe
	vPJChszaFk72bGcm47Rf/LSve7vob0IqmBeUiMv2PJ7+I4oNIi72S86XIwGb/q8R+J9L
	mKYcn98Q7TzMGOGgy21SgZQ1nvS/8BUAOlFSKqO4FikNWV8eha19xvn1YsysBcImFFGk
	2+FJznbCt9XHaZxYr60JgyEsk0SKsiooFcNUV6DUEpVM3Rs1UQzRIobTakE6DBYuO4H8
	hXg1q8ZJ/HSd28pScCcyFdEMimWmLo9hgB9kF+CKplHuzw6AzONR3OuyczemHtsFC636
	b5+g==
X-Gm-Message-State: ALoCoQllXB8RXHgJ8R5wYgDkPYUvnXHVmgfaWSF+mO1DeV0VhKf06HNPEXusVjGm+kHCSOSuozQ9
X-Received: by 10.180.75.42 with SMTP id z10mr7758750wiv.70.1418760567101;
	Tue, 16 Dec 2014 12:09:27 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.25
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:26 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:47 +0000
Message-Id: <1418760534-18163-7-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 06/13] xen/iommu: arm: Remove temporary
	the SMMU 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

The current SMMU driver has completly diverged. That makes me hard to
maintain.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/drivers/passthrough/arm/Makefile |    1 -
 xen/drivers/passthrough/arm/smmu.c   | 1784 ----------------------------------
 2 files changed, 1785 deletions(-)
 delete mode 100644 xen/drivers/passthrough/arm/smmu.c

diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile
index f4cd26e..0484b79 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1 @@
 obj-y += iommu.o
-obj-y += smmu.o
diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
deleted file mode 100644
index 42bde75..0000000
--- a/xen/drivers/passthrough/arm/smmu.c
+++ /dev/null
@@ -1,1784 +0,0 @@
-/*
- * IOMMU API for ARM architected SMMU implementations.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- *
- * Based on Linux drivers/iommu/arm-smmu.c (commit 89a23cd)
- * Copyright (C) 2013 ARM Limited
- *
- * Author: Will Deacon <will.deacon@arm.com>
- *
- * Xen modification:
- * Julien Grall <julien.grall@linaro.org>
- * Copyright (C) 2014 Linaro Limited.
- *
- * This driver currently supports:
- *  - SMMUv1 and v2 implementations (didn't try v2 SMMU)
- *  - Stream-matching and stream-indexing
- *  - v7/v8 long-descriptor format
- *  - Non-secure access to the SMMU
- *  - 4k pages, p2m shared with the processor
- *  - Up to 40-bit addressing
- *  - Context fault reporting
- */
-
-#include <xen/config.h>
-#include <xen/delay.h>
-#include <xen/errno.h>
-#include <xen/irq.h>
-#include <xen/lib.h>
-#include <xen/list.h>
-#include <xen/mm.h>
-#include <xen/vmap.h>
-#include <xen/rbtree.h>
-#include <xen/sched.h>
-#include <asm/atomic.h>
-#include <asm/device.h>
-#include <asm/io.h>
-#include <asm/platform.h>
-
-/* Driver options */
-#define SMMU_OPT_SECURE_CONFIG_ACCESS   (1 << 0)
-
-/* Maximum number of stream IDs assigned to a single device */
-#define MAX_MASTER_STREAMIDS    MAX_PHANDLE_ARGS
-
-/* Maximum stream ID */
-#define SMMU_MAX_STREAMIDS      (PAGE_SIZE_64K - 1)
-
-/* Maximum number of context banks per SMMU */
-#define SMMU_MAX_CBS        128
-
-/* Maximum number of mapping groups per SMMU */
-#define SMMU_MAX_SMRS       128
-
-/* SMMU global address space */
-#define SMMU_GR0(smmu)      ((smmu)->base)
-#define SMMU_GR1(smmu)      ((smmu)->base + (smmu)->pagesize)
-
-/*
- * SMMU global address space with conditional offset to access secure aliases of
- * non-secure registers (e.g. nsCR0: 0x400, nsGFSR: 0x448, nsGFSYNR0: 0x450)
- */
-#define SMMU_GR0_NS(smmu)                                   \
-    ((smmu)->base +                                         \
-     ((smmu->options & SMMU_OPT_SECURE_CONFIG_ACCESS)    \
-        ? 0x400 : 0))
-
-/* Page table bits */
-#define SMMU_PTE_PAGE           (((pteval_t)3) << 0)
-#define SMMU_PTE_CONT           (((pteval_t)1) << 52)
-#define SMMU_PTE_AF             (((pteval_t)1) << 10)
-#define SMMU_PTE_SH_NS          (((pteval_t)0) << 8)
-#define SMMU_PTE_SH_OS          (((pteval_t)2) << 8)
-#define SMMU_PTE_SH_IS          (((pteval_t)3) << 8)
-
-#if PAGE_SIZE == PAGE_SIZE_4K
-#define SMMU_PTE_CONT_ENTRIES   16
-#elif PAGE_SIZE == PAGE_SIZE_64K
-#define SMMU_PTE_CONT_ENTRIES   32
-#else
-#define SMMU_PTE_CONT_ENTRIES   1
-#endif
-
-#define SMMU_PTE_CONT_SIZE      (PAGE_SIZE * SMMU_PTE_CONT_ENTRIES)
-#define SMMU_PTE_CONT_MASK      (~(SMMU_PTE_CONT_SIZE - 1))
-#define SMMU_PTE_HWTABLE_SIZE   (PTRS_PER_PTE * sizeof(pte_t))
-
-/* Stage-1 PTE */
-#define SMMU_PTE_AP_UNPRIV      (((pteval_t)1) << 6)
-#define SMMU_PTE_AP_RDONLY      (((pteval_t)2) << 6)
-#define SMMU_PTE_ATTRINDX_SHIFT 2
-#define SMMU_PTE_nG             (((pteval_t)1) << 11)
-
-/* Stage-2 PTE */
-#define SMMU_PTE_HAP_FAULT      (((pteval_t)0) << 6)
-#define SMMU_PTE_HAP_READ       (((pteval_t)1) << 6)
-#define SMMU_PTE_HAP_WRITE      (((pteval_t)2) << 6)
-#define SMMU_PTE_MEMATTR_OIWB   (((pteval_t)0xf) << 2)
-#define SMMU_PTE_MEMATTR_NC     (((pteval_t)0x5) << 2)
-#define SMMU_PTE_MEMATTR_DEV    (((pteval_t)0x1) << 2)
-
-/* Configuration registers */
-#define SMMU_GR0_sCR0           0x0
-#define SMMU_sCR0_CLIENTPD      (1 << 0)
-#define SMMU_sCR0_GFRE          (1 << 1)
-#define SMMU_sCR0_GFIE          (1 << 2)
-#define SMMU_sCR0_GCFGFRE       (1 << 4)
-#define SMMU_sCR0_GCFGFIE       (1 << 5)
-#define SMMU_sCR0_USFCFG        (1 << 10)
-#define SMMU_sCR0_VMIDPNE       (1 << 11)
-#define SMMU_sCR0_PTM           (1 << 12)
-#define SMMU_sCR0_FB            (1 << 13)
-#define SMMU_sCR0_BSU_SHIFT     14
-#define SMMU_sCR0_BSU_MASK      0x3
-
-/* Identification registers */
-#define SMMU_GR0_ID0            0x20
-#define SMMU_GR0_ID1            0x24
-#define SMMU_GR0_ID2            0x28
-#define SMMU_GR0_ID3            0x2c
-#define SMMU_GR0_ID4            0x30
-#define SMMU_GR0_ID5            0x34
-#define SMMU_GR0_ID6            0x38
-#define SMMU_GR0_ID7            0x3c
-#define SMMU_GR0_sGFSR          0x48
-#define SMMU_GR0_sGFSYNR0       0x50
-#define SMMU_GR0_sGFSYNR1       0x54
-#define SMMU_GR0_sGFSYNR2       0x58
-#define SMMU_GR0_PIDR0          0xfe0
-#define SMMU_GR0_PIDR1          0xfe4
-#define SMMU_GR0_PIDR2          0xfe8
-
-#define SMMU_ID0_S1TS           (1 << 30)
-#define SMMU_ID0_S2TS           (1 << 29)
-#define SMMU_ID0_NTS            (1 << 28)
-#define SMMU_ID0_SMS            (1 << 27)
-#define SMMU_ID0_PTFS_SHIFT     24
-#define SMMU_ID0_PTFS_MASK      0x2
-#define SMMU_ID0_PTFS_V8_ONLY   0x2
-#define SMMU_ID0_CTTW           (1 << 14)
-#define SMMU_ID0_NUMIRPT_SHIFT  16
-#define SMMU_ID0_NUMIRPT_MASK   0xff
-#define SMMU_ID0_NUMSMRG_SHIFT  0
-#define SMMU_ID0_NUMSMRG_MASK   0xff
-
-#define SMMU_ID1_PAGESIZE            (1 << 31)
-#define SMMU_ID1_NUMPAGENDXB_SHIFT   28
-#define SMMU_ID1_NUMPAGENDXB_MASK    7
-#define SMMU_ID1_NUMS2CB_SHIFT       16
-#define SMMU_ID1_NUMS2CB_MASK        0xff
-#define SMMU_ID1_NUMCB_SHIFT         0
-#define SMMU_ID1_NUMCB_MASK          0xff
-
-#define SMMU_ID2_OAS_SHIFT           4
-#define SMMU_ID2_OAS_MASK            0xf
-#define SMMU_ID2_IAS_SHIFT           0
-#define SMMU_ID2_IAS_MASK            0xf
-#define SMMU_ID2_UBS_SHIFT           8
-#define SMMU_ID2_UBS_MASK            0xf
-#define SMMU_ID2_PTFS_4K             (1 << 12)
-#define SMMU_ID2_PTFS_16K            (1 << 13)
-#define SMMU_ID2_PTFS_64K            (1 << 14)
-
-#define SMMU_PIDR2_ARCH_SHIFT        4
-#define SMMU_PIDR2_ARCH_MASK         0xf
-
-/* Global TLB invalidation */
-#define SMMU_GR0_STLBIALL           0x60
-#define SMMU_GR0_TLBIVMID           0x64
-#define SMMU_GR0_TLBIALLNSNH        0x68
-#define SMMU_GR0_TLBIALLH           0x6c
-#define SMMU_GR0_sTLBGSYNC          0x70
-#define SMMU_GR0_sTLBGSTATUS        0x74
-#define SMMU_sTLBGSTATUS_GSACTIVE   (1 << 0)
-#define SMMU_TLB_LOOP_TIMEOUT       1000000 /* 1s! */
-
-/* Stream mapping registers */
-#define SMMU_GR0_SMR(n)             (0x800 + ((n) << 2))
-#define SMMU_SMR_VALID              (1 << 31)
-#define SMMU_SMR_MASK_SHIFT         16
-#define SMMU_SMR_MASK_MASK          0x7fff
-#define SMMU_SMR_ID_SHIFT           0
-#define SMMU_SMR_ID_MASK            0x7fff
-
-#define SMMU_GR0_S2CR(n)        (0xc00 + ((n) << 2))
-#define SMMU_S2CR_CBNDX_SHIFT   0
-#define SMMU_S2CR_CBNDX_MASK    0xff
-#define SMMU_S2CR_TYPE_SHIFT    16
-#define SMMU_S2CR_TYPE_MASK     0x3
-#define SMMU_S2CR_TYPE_TRANS    (0 << SMMU_S2CR_TYPE_SHIFT)
-#define SMMU_S2CR_TYPE_BYPASS   (1 << SMMU_S2CR_TYPE_SHIFT)
-#define SMMU_S2CR_TYPE_FAULT    (2 << SMMU_S2CR_TYPE_SHIFT)
-
-/* Context bank attribute registers */
-#define SMMU_GR1_CBAR(n)                    (0x0 + ((n) << 2))
-#define SMMU_CBAR_VMID_SHIFT                0
-#define SMMU_CBAR_VMID_MASK                 0xff
-#define SMMU_CBAR_S1_MEMATTR_SHIFT          12
-#define SMMU_CBAR_S1_MEMATTR_MASK           0xf
-#define SMMU_CBAR_S1_MEMATTR_WB             0xf
-#define SMMU_CBAR_TYPE_SHIFT                16
-#define SMMU_CBAR_TYPE_MASK                 0x3
-#define SMMU_CBAR_TYPE_S2_TRANS             (0 << SMMU_CBAR_TYPE_SHIFT)
-#define SMMU_CBAR_TYPE_S1_TRANS_S2_BYPASS   (1 << SMMU_CBAR_TYPE_SHIFT)
-#define SMMU_CBAR_TYPE_S1_TRANS_S2_FAULT    (2 << SMMU_CBAR_TYPE_SHIFT)
-#define SMMU_CBAR_TYPE_S1_TRANS_S2_TRANS    (3 << SMMU_CBAR_TYPE_SHIFT)
-#define SMMU_CBAR_IRPTNDX_SHIFT             24
-#define SMMU_CBAR_IRPTNDX_MASK              0xff
-
-#define SMMU_GR1_CBA2R(n)                   (0x800 + ((n) << 2))
-#define SMMU_CBA2R_RW64_32BIT               (0 << 0)
-#define SMMU_CBA2R_RW64_64BIT               (1 << 0)
-
-/* Translation context bank */
-#define SMMU_CB_BASE(smmu)                  ((smmu)->base + ((smmu)->size >> 1))
-#define SMMU_CB(smmu, n)                    ((n) * (smmu)->pagesize)
-
-#define SMMU_CB_SCTLR                       0x0
-#define SMMU_CB_RESUME                      0x8
-#define SMMU_CB_TCR2                        0x10
-#define SMMU_CB_TTBR0_LO                    0x20
-#define SMMU_CB_TTBR0_HI                    0x24
-#define SMMU_CB_TCR                         0x30
-#define SMMU_CB_S1_MAIR0                    0x38
-#define SMMU_CB_FSR                         0x58
-#define SMMU_CB_FAR_LO                      0x60
-#define SMMU_CB_FAR_HI                      0x64
-#define SMMU_CB_FSYNR0                      0x68
-#define SMMU_CB_S1_TLBIASID                 0x610
-
-#define SMMU_SCTLR_S1_ASIDPNE               (1 << 12)
-#define SMMU_SCTLR_CFCFG                    (1 << 7)
-#define SMMU_SCTLR_CFIE                     (1 << 6)
-#define SMMU_SCTLR_CFRE                     (1 << 5)
-#define SMMU_SCTLR_E                        (1 << 4)
-#define SMMU_SCTLR_AFE                      (1 << 2)
-#define SMMU_SCTLR_TRE                      (1 << 1)
-#define SMMU_SCTLR_M                        (1 << 0)
-#define SMMU_SCTLR_EAE_SBOP                 (SMMU_SCTLR_AFE | SMMU_SCTLR_TRE)
-
-#define SMMU_RESUME_RETRY                   (0 << 0)
-#define SMMU_RESUME_TERMINATE               (1 << 0)
-
-#define SMMU_TCR_EAE                        (1 << 31)
-
-#define SMMU_TCR_PASIZE_SHIFT               16
-#define SMMU_TCR_PASIZE_MASK                0x7
-
-#define SMMU_TCR_TG0_4K                     (0 << 14)
-#define SMMU_TCR_TG0_64K                    (1 << 14)
-
-#define SMMU_TCR_SH0_SHIFT                  12
-#define SMMU_TCR_SH0_MASK                   0x3
-#define SMMU_TCR_SH_NS                      0
-#define SMMU_TCR_SH_OS                      2
-#define SMMU_TCR_SH_IS                      3
-
-#define SMMU_TCR_ORGN0_SHIFT                10
-#define SMMU_TCR_IRGN0_SHIFT                8
-#define SMMU_TCR_RGN_MASK                   0x3
-#define SMMU_TCR_RGN_NC                     0
-#define SMMU_TCR_RGN_WBWA                   1
-#define SMMU_TCR_RGN_WT                     2
-#define SMMU_TCR_RGN_WB                     3
-
-#define SMMU_TCR_SL0_SHIFT                  6
-#define SMMU_TCR_SL0_MASK                   0x3
-#define SMMU_TCR_SL0_LVL_2                  0
-#define SMMU_TCR_SL0_LVL_1                  1
-
-#define SMMU_TCR_T1SZ_SHIFT                 16
-#define SMMU_TCR_T0SZ_SHIFT                 0
-#define SMMU_TCR_SZ_MASK                    0xf
-
-#define SMMU_TCR2_SEP_SHIFT                 15
-#define SMMU_TCR2_SEP_MASK                  0x7
-
-#define SMMU_TCR2_PASIZE_SHIFT              0
-#define SMMU_TCR2_PASIZE_MASK               0x7
-
-/* Common definitions for PASize and SEP fields */
-#define SMMU_TCR2_ADDR_32                   0
-#define SMMU_TCR2_ADDR_36                   1
-#define SMMU_TCR2_ADDR_40                   2
-#define SMMU_TCR2_ADDR_42                   3
-#define SMMU_TCR2_ADDR_44                   4
-#define SMMU_TCR2_ADDR_48                   5
-
-#define SMMU_TTBRn_HI_ASID_SHIFT            16
-
-#define SMMU_MAIR_ATTR_SHIFT(n)             ((n) << 3)
-#define SMMU_MAIR_ATTR_MASK                 0xff
-#define SMMU_MAIR_ATTR_DEVICE               0x04
-#define SMMU_MAIR_ATTR_NC                   0x44
-#define SMMU_MAIR_ATTR_WBRWA                0xff
-#define SMMU_MAIR_ATTR_IDX_NC               0
-#define SMMU_MAIR_ATTR_IDX_CACHE            1
-#define SMMU_MAIR_ATTR_IDX_DEV              2
-
-#define SMMU_FSR_MULTI                      (1 << 31)
-#define SMMU_FSR_SS                         (1 << 30)
-#define SMMU_FSR_UUT                        (1 << 8)
-#define SMMU_FSR_ASF                        (1 << 7)
-#define SMMU_FSR_TLBLKF                     (1 << 6)
-#define SMMU_FSR_TLBMCF                     (1 << 5)
-#define SMMU_FSR_EF                         (1 << 4)
-#define SMMU_FSR_PF                         (1 << 3)
-#define SMMU_FSR_AFF                        (1 << 2)
-#define SMMU_FSR_TF                         (1 << 1)
-
-#define SMMU_FSR_IGN                        (SMMU_FSR_AFF | SMMU_FSR_ASF |    \
-                                             SMMU_FSR_TLBMCF | SMMU_FSR_TLBLKF)
-#define SMMU_FSR_FAULT                      (SMMU_FSR_MULTI | SMMU_FSR_SS |   \
-                                             SMMU_FSR_UUT | SMMU_FSR_EF |     \
-                                             SMMU_FSR_PF | SMMU_FSR_TF |      \
-                                             SMMU_FSR_IGN)
-
-#define SMMU_FSYNR0_WNR                     (1 << 4)
-
-#define smmu_print(dev, lvl, fmt, ...)                                        \
-    printk(lvl "smmu: %s: " fmt, dt_node_full_name(dev->node), ## __VA_ARGS__)
-
-#define smmu_err(dev, fmt, ...) smmu_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
-
-#define smmu_dbg(dev, fmt, ...)                                             \
-    smmu_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__)
-
-#define smmu_info(dev, fmt, ...)                                            \
-    smmu_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__)
-
-#define smmu_warn(dev, fmt, ...)                                            \
-    smmu_print(dev, XENLOG_WARNING, fmt, ## __VA_ARGS__)
-
-struct arm_smmu_device {
-    const struct dt_device_node *node;
-
-    void __iomem                *base;
-    unsigned long               size;
-    unsigned long               pagesize;
-
-#define SMMU_FEAT_COHERENT_WALK (1 << 0)
-#define SMMU_FEAT_STREAM_MATCH  (1 << 1)
-#define SMMU_FEAT_TRANS_S1      (1 << 2)
-#define SMMU_FEAT_TRANS_S2      (1 << 3)
-#define SMMU_FEAT_TRANS_NESTED  (1 << 4)
-    u32                         features;
-    u32                         options;
-    int                         version;
-
-    u32                         num_context_banks;
-    u32                         num_s2_context_banks;
-    DECLARE_BITMAP(context_map, SMMU_MAX_CBS);
-    atomic_t                    irptndx;
-
-    u32                         num_mapping_groups;
-    DECLARE_BITMAP(smr_map, SMMU_MAX_SMRS);
-
-    unsigned long               input_size;
-    unsigned long               s1_output_size;
-    unsigned long               s2_output_size;
-
-    u32                         num_global_irqs;
-    u32                         num_context_irqs;
-    unsigned int                *irqs;
-
-    u32                         smr_mask_mask;
-    u32                         smr_id_mask;
-
-    unsigned long               *sids;
-
-    struct list_head            list;
-    struct rb_root              masters;
-};
-
-struct arm_smmu_smr {
-    u8                          idx;
-    u16                         mask;
-    u16                         id;
-};
-
-#define INVALID_IRPTNDX         0xff
-
-#define SMMU_CB_ASID(cfg)       ((cfg)->cbndx)
-#define SMMU_CB_VMID(cfg)       ((cfg)->cbndx + 1)
-
-struct arm_smmu_domain_cfg {
-    struct arm_smmu_device  *smmu;
-    u8                      cbndx;
-    u8                      irptndx;
-    u32                     cbar;
-    /* Domain associated to this device */
-    struct domain           *domain;
-    /* List of master which use this structure */
-    struct list_head        masters;
-
-    /* Used to link domain context for a same domain */
-    struct list_head        list;
-};
-
-struct arm_smmu_master {
-    const struct dt_device_node *dt_node;
-
-    /*
-     * The following is specific to the master's position in the
-     * SMMU chain.
-     */
-    struct rb_node              node;
-    u32                         num_streamids;
-    u16                         streamids[MAX_MASTER_STREAMIDS];
-    int                         num_s2crs;
-
-    struct arm_smmu_smr         *smrs;
-    struct arm_smmu_domain_cfg  *cfg;
-
-    /* Used to link masters in a same domain context */
-    struct list_head            list;
-};
-
-static LIST_HEAD(arm_smmu_devices);
-
-struct arm_smmu_domain {
-    spinlock_t lock;
-    struct list_head contexts;
-};
-
-struct arm_smmu_option_prop {
-    u32         opt;
-    const char  *prop;
-};
-
-static const struct arm_smmu_option_prop arm_smmu_options [] __initconst =
-{
-    { SMMU_OPT_SECURE_CONFIG_ACCESS, "calxeda,smmu-secure-config-access" },
-    { 0, NULL},
-};
-
-static void __init check_driver_options(struct arm_smmu_device *smmu)
-{
-    int i = 0;
-
-    do {
-        if ( dt_property_read_bool(smmu->node, arm_smmu_options[i].prop) )
-        {
-            smmu->options |= arm_smmu_options[i].opt;
-            smmu_dbg(smmu, "option %s\n", arm_smmu_options[i].prop);
-        }
-    } while ( arm_smmu_options[++i].opt );
-}
-
-static void arm_smmu_context_fault(int irq, void *data,
-                                   struct cpu_user_regs *regs)
-{
-    u32 fsr, far, fsynr;
-    uint64_t iova;
-    struct arm_smmu_domain_cfg *cfg = data;
-    struct arm_smmu_device *smmu = cfg->smmu;
-    void __iomem *cb_base;
-
-    cb_base = SMMU_CB_BASE(smmu) + SMMU_CB(smmu, cfg->cbndx);
-    fsr = readl_relaxed(cb_base + SMMU_CB_FSR);
-
-    if ( !(fsr & SMMU_FSR_FAULT) )
-        return;
-
-    if ( fsr & SMMU_FSR_IGN )
-        smmu_err(smmu, "Unexpected context fault (fsr 0x%u)\n", fsr);
-
-    fsynr = readl_relaxed(cb_base + SMMU_CB_FSYNR0);
-    far = readl_relaxed(cb_base + SMMU_CB_FAR_LO);
-    iova = far;
-    far = readl_relaxed(cb_base + SMMU_CB_FAR_HI);
-    iova |= ((uint64_t)far << 32);
-
-    smmu_err(smmu, "Unhandled context fault for domain %u\n",
-             cfg->domain->domain_id);
-    smmu_err(smmu, "\tFSR 0x%x, IOVA 0x%"PRIx64", FSYNR 0x%x,  CB %d\n",
-             fsr, iova, fsynr, cfg->cbndx);
-
-    /* Clear the faulting FSR */
-    writel(fsr, cb_base + SMMU_CB_FSR);
-
-    /* Terminate any stalled transactions */
-    if ( fsr & SMMU_FSR_SS )
-        writel_relaxed(SMMU_RESUME_TERMINATE, cb_base + SMMU_CB_RESUME);
-}
-
-static void arm_smmu_global_fault(int irq, void *data,
-                                  struct cpu_user_regs *regs)
-{
-    u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
-    struct arm_smmu_device *smmu = data;
-    void __iomem *gr0_base = SMMU_GR0_NS(smmu);
-
-    gfsr = readl_relaxed(gr0_base + SMMU_GR0_sGFSR);
-    gfsynr0 = readl_relaxed(gr0_base + SMMU_GR0_sGFSYNR0);
-    gfsynr1 = readl_relaxed(gr0_base + SMMU_GR0_sGFSYNR1);
-    gfsynr2 = readl_relaxed(gr0_base + SMMU_GR0_sGFSYNR2);
-
-    if ( !gfsr )
-        return;
-
-    smmu_err(smmu, "Unexpected global fault, this could be serious\n");
-    smmu_err(smmu,
-             "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
-             gfsr, gfsynr0, gfsynr1, gfsynr2);
-    writel(gfsr, gr0_base + SMMU_GR0_sGFSR);
-}
-
-static struct arm_smmu_master *
-find_smmu_master(struct arm_smmu_device *smmu,
-                 const struct dt_device_node *dev_node)
-{
-    struct rb_node *node = smmu->masters.rb_node;
-
-    while ( node )
-    {
-        struct arm_smmu_master *master;
-
-        master = container_of(node, struct arm_smmu_master, node);
-
-        if ( dev_node < master->dt_node )
-            node = node->rb_left;
-        else if ( dev_node > master->dt_node )
-            node = node->rb_right;
-        else
-            return master;
-    }
-
-    return NULL;
-}
-
-static __init int insert_smmu_master(struct arm_smmu_device *smmu,
-                                     struct arm_smmu_master *master)
-{
-    struct rb_node **new, *parent;
-
-    new = &smmu->masters.rb_node;
-    parent = NULL;
-    while ( *new )
-    {
-        struct arm_smmu_master *this;
-
-        this = container_of(*new, struct arm_smmu_master, node);
-
-        parent = *new;
-        if ( master->dt_node < this->dt_node )
-            new = &((*new)->rb_left);
-        else if (master->dt_node > this->dt_node)
-            new = &((*new)->rb_right);
-        else
-            return -EEXIST;
-    }
-
-    rb_link_node(&master->node, parent, new);
-    rb_insert_color(&master->node, &smmu->masters);
-    return 0;
-}
-
-static __init int register_smmu_master(struct arm_smmu_device *smmu,
-                                       struct dt_phandle_args *masterspec)
-{
-    int i, sid;
-    struct arm_smmu_master *master;
-    int rc = 0;
-
-    smmu_dbg(smmu, "Try to add master %s\n", masterspec->np->name);
-
-    master = find_smmu_master(smmu, masterspec->np);
-    if ( master )
-    {
-        smmu_err(smmu,
-                 "rejecting multiple registrations for master device %s\n",
-                 masterspec->np->name);
-        return -EBUSY;
-    }
-
-    if ( masterspec->args_count > MAX_MASTER_STREAMIDS )
-    {
-        smmu_err(smmu,
-            "reached maximum number (%d) of stream IDs for master device %s\n",
-            MAX_MASTER_STREAMIDS, masterspec->np->name);
-        return -ENOSPC;
-    }
-
-    master = xzalloc(struct arm_smmu_master);
-    if ( !master )
-        return -ENOMEM;
-
-    INIT_LIST_HEAD(&master->list);
-    master->dt_node = masterspec->np;
-    master->num_streamids = masterspec->args_count;
-
-    dt_device_set_protected(masterspec->np);
-
-    for ( i = 0; i < master->num_streamids; ++i )
-    {
-        sid = masterspec->args[i];
-        if ( test_and_set_bit(sid, smmu->sids) )
-        {
-            smmu_err(smmu, "duplicate stream ID (%d)\n", sid);
-            xfree(master);
-            return -EEXIST;
-        }
-        master->streamids[i] = masterspec->args[i];
-    }
-
-    rc = insert_smmu_master(smmu, master);
-    /* Insertion should never fail */
-    ASSERT(rc == 0);
-
-    return 0;
-}
-
-static int __arm_smmu_alloc_bitmap(unsigned long *map, int start, int end)
-{
-    int idx;
-
-    do
-    {
-        idx = find_next_zero_bit(map, end, start);
-        if ( idx == end )
-            return -ENOSPC;
-    } while ( test_and_set_bit(idx, map) );
-
-    return idx;
-}
-
-static void __arm_smmu_free_bitmap(unsigned long *map, int idx)
-{
-    clear_bit(idx, map);
-}
-
-static void arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
-{
-    int count = 0;
-    void __iomem *gr0_base = SMMU_GR0(smmu);
-
-    writel_relaxed(0, gr0_base + SMMU_GR0_sTLBGSYNC);
-    while ( readl_relaxed(gr0_base + SMMU_GR0_sTLBGSTATUS) &
-            SMMU_sTLBGSTATUS_GSACTIVE )
-    {
-        cpu_relax();
-        if ( ++count == SMMU_TLB_LOOP_TIMEOUT )
-        {
-            smmu_err(smmu, "TLB sync timed out -- SMMU may be deadlocked\n");
-            return;
-        }
-        udelay(1);
-    }
-}
-
-static void arm_smmu_tlb_inv_context(struct arm_smmu_domain_cfg *cfg)
-{
-    struct arm_smmu_device *smmu = cfg->smmu;
-    void __iomem *base = SMMU_GR0(smmu);
-
-    writel_relaxed(SMMU_CB_VMID(cfg),
-                   base + SMMU_GR0_TLBIVMID);
-
-    arm_smmu_tlb_sync(smmu);
-}
-
-static void arm_smmu_iotlb_flush_all(struct domain *d)
-{
-    struct arm_smmu_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
-    struct arm_smmu_domain_cfg *cfg;
-
-    spin_lock(&smmu_domain->lock);
-    list_for_each_entry(cfg, &smmu_domain->contexts, list)
-        arm_smmu_tlb_inv_context(cfg);
-    spin_unlock(&smmu_domain->lock);
-}
-
-static void arm_smmu_iotlb_flush(struct domain *d, unsigned long gfn,
-                                 unsigned int page_count)
-{
-    /* ARM SMMU v1 doesn't have flush by VMA and VMID */
-    arm_smmu_iotlb_flush_all(d);
-}
-
-static int determine_smr_mask(struct arm_smmu_device *smmu,
-                              struct arm_smmu_master *master,
-                              struct arm_smmu_smr *smr, int start, int order)
-{
-    u16 i, zero_bits_mask, one_bits_mask, const_mask;
-    int nr;
-
-    nr = 1 << order;
-
-    if ( nr == 1 )
-    {
-        /* no mask, use streamid to match and be done with it */
-        smr->mask = 0;
-        smr->id = master->streamids[start];
-        return 0;
-    }
-
-    zero_bits_mask = 0;
-    one_bits_mask = 0xffff;
-    for ( i = start; i < start + nr; i++)
-    {
-        zero_bits_mask |= master->streamids[i];   /* const 0 bits */
-        one_bits_mask &= master->streamids[i]; /* const 1 bits */
-    }
-    zero_bits_mask = ~zero_bits_mask;
-
-    /* bits having constant values (either 0 or 1) */
-    const_mask = zero_bits_mask | one_bits_mask;
-
-    i = hweight16(~const_mask);
-    if ( (1 << i) == nr )
-    {
-        smr->mask = ~const_mask;
-        smr->id = one_bits_mask;
-    }
-    else
-        /* no usable mask for this set of streamids */
-        return 1;
-
-    if ( ((smr->mask & smmu->smr_mask_mask) != smr->mask) ||
-         ((smr->id & smmu->smr_id_mask) != smr->id) )
-        /* insufficient number of mask/id bits */
-        return 1;
-
-    return 0;
-}
-
-static int determine_smr_mapping(struct arm_smmu_device *smmu,
-                                 struct arm_smmu_master *master,
-                                 struct arm_smmu_smr *smrs, int max_smrs)
-{
-    int nr_sid, nr, i, bit, start;
-
-    /*
-     * This function is called only once -- when a master is added
-     * to a domain. If master->num_s2crs != 0 then this master
-     * was already added to a domain.
-     */
-    BUG_ON(master->num_s2crs);
-
-    start = nr = 0;
-    nr_sid = master->num_streamids;
-    do
-    {
-        /*
-         * largest power-of-2 number of streamids for which to
-         * determine a usable mask/id pair for stream matching
-         */
-        bit = fls(nr_sid);
-        if (!bit)
-            return 0;
-
-        /*
-         * iterate over power-of-2 numbers to determine
-         * largest possible mask/id pair for stream matching
-         * of next 2**i streamids
-         */
-        for ( i = bit - 1; i >= 0; i-- )
-        {
-            if( !determine_smr_mask(smmu, master,
-                                    &smrs[master->num_s2crs],
-                                    start, i))
-                break;
-        }
-
-        if ( i < 0 )
-            goto out;
-
-        nr = 1 << i;
-        nr_sid -= nr;
-        start += nr;
-        master->num_s2crs++;
-    } while ( master->num_s2crs <= max_smrs );
-
-out:
-    if ( nr_sid )
-    {
-        /* not enough mapping groups available */
-        master->num_s2crs = 0;
-        return -ENOSPC;
-    }
-
-    return 0;
-}
-
-static int arm_smmu_master_configure_smrs(struct arm_smmu_device *smmu,
-                                          struct arm_smmu_master *master)
-{
-    int i, max_smrs, ret;
-    struct arm_smmu_smr *smrs;
-    void __iomem *gr0_base = SMMU_GR0(smmu);
-
-    if ( !(smmu->features & SMMU_FEAT_STREAM_MATCH) )
-        return 0;
-
-    if ( master->smrs )
-        return -EEXIST;
-
-    max_smrs = min(smmu->num_mapping_groups, master->num_streamids);
-    smrs = xmalloc_array(struct arm_smmu_smr, max_smrs);
-    if ( !smrs )
-    {
-        smmu_err(smmu, "failed to allocated %d SMRs for master %s\n",
-                 max_smrs, dt_node_name(master->dt_node));
-        return -ENOMEM;
-    }
-
-    ret = determine_smr_mapping(smmu, master, smrs, max_smrs);
-    if ( ret )
-        goto err_free_smrs;
-
-    /* Allocate the SMRs on the root SMMU */
-    for ( i = 0; i < master->num_s2crs; ++i )
-    {
-        int idx = __arm_smmu_alloc_bitmap(smmu->smr_map, 0,
-                                          smmu->num_mapping_groups);
-        if ( idx < 0 )
-        {
-            smmu_err(smmu, "failed to allocate free SMR\n");
-            goto err_free_bitmap;
-        }
-        smrs[i].idx = idx;
-    }
-
-    /* It worked! Now, poke the actual hardware */
-    for ( i = 0; i < master->num_s2crs; ++i )
-    {
-        u32 reg = SMMU_SMR_VALID | smrs[i].id << SMMU_SMR_ID_SHIFT |
-            smrs[i].mask << SMMU_SMR_MASK_SHIFT;
-        smmu_dbg(smmu, "SMR%d: 0x%x\n", smrs[i].idx, reg);
-        writel_relaxed(reg, gr0_base + SMMU_GR0_SMR(smrs[i].idx));
-    }
-
-    master->smrs = smrs;
-    return 0;
-
-err_free_bitmap:
-    while (--i >= 0)
-        __arm_smmu_free_bitmap(smmu->smr_map, smrs[i].idx);
-    master->num_s2crs = 0;
-err_free_smrs:
-    xfree(smrs);
-    return -ENOSPC;
-}
-
-/* Forward declaration */
-static void arm_smmu_destroy_domain_context(struct arm_smmu_domain_cfg *cfg);
-
-static int arm_smmu_domain_add_master(struct domain *d,
-                                      struct arm_smmu_domain_cfg *cfg,
-                                      struct arm_smmu_master *master)
-{
-    int i, ret;
-    struct arm_smmu_device *smmu = cfg->smmu;
-    void __iomem *gr0_base = SMMU_GR0(smmu);
-    struct arm_smmu_smr *smrs = master->smrs;
-
-    if ( master->cfg )
-        return -EBUSY;
-
-    ret = arm_smmu_master_configure_smrs(smmu, master);
-    if ( ret )
-        return ret;
-
-    /* Now we're at the root, time to point at our context bank */
-    if ( !master->num_s2crs )
-        master->num_s2crs = master->num_streamids;
-
-    for ( i = 0; i < master->num_s2crs; ++i )
-    {
-        u32 idx, s2cr;
-
-        idx = smrs ? smrs[i].idx : master->streamids[i];
-        s2cr = (SMMU_S2CR_TYPE_TRANS << SMMU_S2CR_TYPE_SHIFT) |
-            (cfg->cbndx << SMMU_S2CR_CBNDX_SHIFT);
-        smmu_dbg(smmu, "S2CR%d: 0x%x\n", idx, s2cr);
-        writel_relaxed(s2cr, gr0_base + SMMU_GR0_S2CR(idx));
-    }
-
-    master->cfg = cfg;
-    list_add(&master->list, &cfg->masters);
-
-    return 0;
-}
-
-static void arm_smmu_domain_remove_master(struct arm_smmu_master *master)
-{
-    int i;
-    struct arm_smmu_domain_cfg *cfg = master->cfg;
-    struct arm_smmu_device *smmu = cfg->smmu;
-    void __iomem *gr0_base = SMMU_GR0(smmu);
-    struct arm_smmu_smr *smrs = master->smrs;
-
-    /*
-     * We *must* clear the S2CR first, because freeing the SMR means
-     * that it can be reallocated immediately
-     */
-    for ( i = 0; i < master->num_streamids; ++i )
-    {
-        u16 sid = master->streamids[i];
-        writel_relaxed(SMMU_S2CR_TYPE_FAULT,
-                       gr0_base + SMMU_GR0_S2CR(sid));
-    }
-
-    /* Invalidate the SMRs before freeing back to the allocator */
-    for (i = 0; i < master->num_s2crs; ++i) {
-        u8 idx = smrs[i].idx;
-        writel_relaxed(~SMMU_SMR_VALID, gr0_base + SMMU_GR0_SMR(idx));
-        __arm_smmu_free_bitmap(smmu->smr_map, idx);
-    }
-
-    master->smrs = NULL;
-    master->num_s2crs = 0;
-    xfree(smrs);
-
-    master->cfg = NULL;
-    list_del(&master->list);
-    INIT_LIST_HEAD(&master->list);
-}
-
-static void arm_smmu_init_context_bank(struct arm_smmu_domain_cfg *cfg)
-{
-    u32 reg;
-    struct arm_smmu_device *smmu = cfg->smmu;
-    void __iomem *cb_base, *gr1_base;
-    paddr_t p2maddr;
-
-    ASSERT(cfg->domain != NULL);
-    p2maddr = page_to_maddr(cfg->domain->arch.p2m.root);
-
-    gr1_base = SMMU_GR1(smmu);
-    cb_base = SMMU_CB_BASE(smmu) + SMMU_CB(smmu, cfg->cbndx);
-
-    /* CBAR */
-    reg = cfg->cbar;
-    if ( smmu->version == 1 )
-        reg |= cfg->irptndx << SMMU_CBAR_IRPTNDX_SHIFT;
-
-    reg |= SMMU_CB_VMID(cfg) << SMMU_CBAR_VMID_SHIFT;
-    writel_relaxed(reg, gr1_base + SMMU_GR1_CBAR(cfg->cbndx));
-
-    if ( smmu->version > 1 )
-    {
-        /* CBA2R */
-#ifdef CONFIG_ARM_64
-        reg = SMMU_CBA2R_RW64_64BIT;
-#else
-        reg = SMMU_CBA2R_RW64_32BIT;
-#endif
-        writel_relaxed(reg, gr1_base + SMMU_GR1_CBA2R(cfg->cbndx));
-    }
-
-    /* TTBR0 */
-    reg = (p2maddr & ((1ULL << 32) - 1));
-    writel_relaxed(reg, cb_base + SMMU_CB_TTBR0_LO);
-    reg = (p2maddr >> 32);
-    writel_relaxed(reg, cb_base + SMMU_CB_TTBR0_HI);
-
-    /*
-     * TCR
-     * We use long descriptor, with inner-shareable WBWA tables in TTBR0.
-     */
-    if ( smmu->version > 1 )
-    {
-        /* 4K Page Table */
-        if ( PAGE_SIZE == PAGE_SIZE_4K )
-            reg = SMMU_TCR_TG0_4K;
-        else
-            reg = SMMU_TCR_TG0_64K;
-
-        switch ( smmu->s2_output_size ) {
-        case 32:
-            reg |= (SMMU_TCR2_ADDR_32 << SMMU_TCR_PASIZE_SHIFT);
-            break;
-        case 36:
-            reg |= (SMMU_TCR2_ADDR_36 << SMMU_TCR_PASIZE_SHIFT);
-            break;
-        case 40:
-            reg |= (SMMU_TCR2_ADDR_40 << SMMU_TCR_PASIZE_SHIFT);
-            break;
-        case 42:
-            reg |= (SMMU_TCR2_ADDR_42 << SMMU_TCR_PASIZE_SHIFT);
-            break;
-        case 44:
-            reg |= (SMMU_TCR2_ADDR_44 << SMMU_TCR_PASIZE_SHIFT);
-            break;
-        case 48:
-            reg |= (SMMU_TCR2_ADDR_48 << SMMU_TCR_PASIZE_SHIFT);
-            break;
-        }
-    }
-    else
-        reg = 0;
-
-    /* The attribute to walk the page table should be the same as VTCR_EL2 */
-    reg |= SMMU_TCR_EAE |
-        (SMMU_TCR_SH_IS << SMMU_TCR_SH0_SHIFT) |
-        (SMMU_TCR_RGN_WBWA << SMMU_TCR_ORGN0_SHIFT) |
-        (SMMU_TCR_RGN_WBWA << SMMU_TCR_IRGN0_SHIFT) |
-        (SMMU_TCR_SL0_LVL_1 << SMMU_TCR_SL0_SHIFT) |
-        /* T0SZ=(1)100 = -8 ( 32 -(-8) = 40 bit physical addresses ) */
-        (0x18 << SMMU_TCR_T0SZ_SHIFT);
-    writel_relaxed(reg, cb_base + SMMU_CB_TCR);
-
-    /* SCTLR */
-    reg = SMMU_SCTLR_CFCFG |
-        SMMU_SCTLR_CFIE |
-        SMMU_SCTLR_CFRE |
-        SMMU_SCTLR_M |
-        SMMU_SCTLR_EAE_SBOP;
-
-    writel_relaxed(reg, cb_base + SMMU_CB_SCTLR);
-}
-
-static struct arm_smmu_domain_cfg *
-arm_smmu_alloc_domain_context(struct domain *d,
-                              struct arm_smmu_device *smmu)
-{
-    unsigned int irq;
-    int ret, start;
-    struct arm_smmu_domain_cfg *cfg;
-    struct arm_smmu_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
-
-    ASSERT(spin_is_locked(&smmu_domain->lock));
-
-    cfg = xzalloc(struct arm_smmu_domain_cfg);
-    if ( !cfg )
-        return NULL;
-
-    /* Master already initialized to another domain ... */
-    if ( cfg->domain != NULL )
-        goto out_free_mem;
-
-    cfg->cbar = SMMU_CBAR_TYPE_S2_TRANS;
-    start = 0;
-
-    ret = __arm_smmu_alloc_bitmap(smmu->context_map, start,
-                                  smmu->num_context_banks);
-    if ( ret < 0 )
-        goto out_free_mem;
-
-    cfg->cbndx = ret;
-    if ( smmu->version == 1 )
-    {
-        cfg->irptndx = atomic_inc_return(&smmu->irptndx);
-        cfg->irptndx %= smmu->num_context_irqs;
-    }
-    else
-        cfg->irptndx = cfg->cbndx;
-
-    irq = smmu->irqs[smmu->num_global_irqs + cfg->irptndx];
-    ret = request_irq(irq, IRQF_SHARED, arm_smmu_context_fault,
-                      "arm-smmu-context-fault", cfg);
-    if ( ret )
-    {
-        smmu_err(smmu, "failed to request context IRQ %d (%u)\n",
-                 cfg->irptndx, irq);
-        cfg->irptndx = INVALID_IRPTNDX;
-        goto out_free_context;
-    }
-
-    cfg->domain = d;
-    cfg->smmu = smmu;
-    if ( smmu->features & SMMU_FEAT_COHERENT_WALK )
-        iommu_set_feature(d, IOMMU_FEAT_COHERENT_WALK);
-
-    arm_smmu_init_context_bank(cfg);
-    list_add(&cfg->list, &smmu_domain->contexts);
-    INIT_LIST_HEAD(&cfg->masters);
-
-    return cfg;
-
-out_free_context:
-    __arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
-out_free_mem:
-    xfree(cfg);
-
-    return NULL;
-}
-
-static void arm_smmu_destroy_domain_context(struct arm_smmu_domain_cfg *cfg)
-{
-    struct domain *d = cfg->domain;
-    struct arm_smmu_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
-    struct arm_smmu_device *smmu = cfg->smmu;
-    void __iomem *cb_base;
-    unsigned int irq;
-
-    ASSERT(spin_is_locked(&smmu_domain->lock));
-    BUG_ON(!list_empty(&cfg->masters));
-
-    /* Disable the context bank and nuke the TLB before freeing it */
-    cb_base = SMMU_CB_BASE(smmu) + SMMU_CB(smmu, cfg->cbndx);
-    writel_relaxed(0, cb_base + SMMU_CB_SCTLR);
-    arm_smmu_tlb_inv_context(cfg);
-
-    if ( cfg->irptndx != INVALID_IRPTNDX )
-    {
-        irq = smmu->irqs[smmu->num_global_irqs + cfg->irptndx];
-        release_irq(irq, cfg);
-    }
-
-    __arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
-    list_del(&cfg->list);
-    xfree(cfg);
-}
-
-static struct arm_smmu_device *
-arm_smmu_find_smmu_by_dev(const struct dt_device_node *dev)
-{
-    struct arm_smmu_device *smmu;
-    struct arm_smmu_master *master = NULL;
-
-    list_for_each_entry( smmu, &arm_smmu_devices, list )
-    {
-        master = find_smmu_master(smmu, dev);
-        if ( master )
-            break;
-    }
-
-    if ( !master )
-        return NULL;
-
-    return smmu;
-}
-
-static int arm_smmu_attach_dev(struct domain *d,
-                               const struct dt_device_node *dev)
-{
-    struct arm_smmu_device *smmu = arm_smmu_find_smmu_by_dev(dev);
-    struct arm_smmu_master *master;
-    struct arm_smmu_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
-    struct arm_smmu_domain_cfg *cfg = NULL;
-    struct arm_smmu_domain_cfg *curr;
-    int ret;
-
-    printk(XENLOG_DEBUG "arm-smmu: attach %s to domain %d\n",
-           dt_node_full_name(dev), d->domain_id);
-
-    if ( !smmu )
-    {
-        printk(XENLOG_ERR "%s: cannot attach to SMMU, is it on the same bus?\n",
-               dt_node_full_name(dev));
-        return -ENODEV;
-    }
-
-    master = find_smmu_master(smmu, dev);
-    BUG_ON(master == NULL);
-
-    /* Check if the device is already assigned to someone */
-    if ( master->cfg )
-        return -EBUSY;
-
-    spin_lock(&smmu_domain->lock);
-    list_for_each_entry( curr, &smmu_domain->contexts, list )
-    {
-        if ( curr->smmu == smmu )
-        {
-            cfg = curr;
-            break;
-        }
-    }
-
-    if ( !cfg )
-    {
-        cfg = arm_smmu_alloc_domain_context(d, smmu);
-        if ( !cfg )
-        {
-            smmu_err(smmu, "unable to allocate context for domain %u\n",
-                     d->domain_id);
-            spin_unlock(&smmu_domain->lock);
-            return -ENOMEM;
-        }
-    }
-    spin_unlock(&smmu_domain->lock);
-
-    ret = arm_smmu_domain_add_master(d, cfg, master);
-    if ( ret )
-    {
-        spin_lock(&smmu_domain->lock);
-        if ( list_empty(&cfg->masters) )
-            arm_smmu_destroy_domain_context(cfg);
-        spin_unlock(&smmu_domain->lock);
-    }
-
-    return ret;
-}
-
-static int arm_smmu_detach_dev(struct domain *d,
-                               const struct dt_device_node *dev)
-{
-    struct arm_smmu_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
-    struct arm_smmu_master *master;
-    struct arm_smmu_device *smmu = arm_smmu_find_smmu_by_dev(dev);
-    struct arm_smmu_domain_cfg *cfg;
-
-    printk(XENLOG_DEBUG "arm-smmu: detach %s to domain %d\n",
-           dt_node_full_name(dev), d->domain_id);
-
-    if ( !smmu )
-    {
-        printk(XENLOG_ERR "%s: cannot find the SMMU, is it on the same bus?\n",
-               dt_node_full_name(dev));
-        return -ENODEV;
-    }
-
-    master = find_smmu_master(smmu, dev);
-    BUG_ON(master == NULL);
-
-    cfg = master->cfg;
-
-    /* Sanity check to avoid removing a device that doesn't belong to
-     * the domain
-     */
-    if ( !cfg || cfg->domain != d )
-    {
-        printk(XENLOG_ERR "%s: was not attach to domain %d\n",
-               dt_node_full_name(dev), d->domain_id);
-        return -ESRCH;
-    }
-
-    arm_smmu_domain_remove_master(master);
-
-    spin_lock(&smmu_domain->lock);
-    if ( list_empty(&cfg->masters) )
-        arm_smmu_destroy_domain_context(cfg);
-    spin_unlock(&smmu_domain->lock);
-
-    return 0;
-}
-
-static int arm_smmu_reassign_dt_dev(struct domain *s, struct domain *t,
-                                    const struct dt_device_node *dev)
-{
-    int ret = 0;
-
-    /* Don't allow remapping on other domain than hwdom */
-    if ( t != hardware_domain )
-        return -EPERM;
-
-    if ( t == s )
-        return 0;
-
-    ret = arm_smmu_detach_dev(s, dev);
-    if ( ret )
-        return ret;
-
-    ret = arm_smmu_attach_dev(t, dev);
-
-    return ret;
-}
-
-static __init int arm_smmu_id_size_to_bits(int size)
-{
-    switch ( size )
-    {
-    case 0:
-        return 32;
-    case 1:
-        return 36;
-    case 2:
-        return 40;
-    case 3:
-        return 42;
-    case 4:
-        return 44;
-    case 5:
-    default:
-        return 48;
-    }
-}
-
-static __init int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
-{
-    unsigned long size;
-    void __iomem *gr0_base = SMMU_GR0(smmu);
-    u32 id;
-
-    smmu_info(smmu, "probing hardware configuration...\n");
-
-    /*
-     * Primecell ID
-     */
-    id = readl_relaxed(gr0_base + SMMU_GR0_PIDR2);
-    smmu->version = ((id >> SMMU_PIDR2_ARCH_SHIFT) & SMMU_PIDR2_ARCH_MASK) + 1;
-    smmu_info(smmu, "SMMUv%d with:\n", smmu->version);
-
-    /* ID0 */
-    id = readl_relaxed(gr0_base + SMMU_GR0_ID0);
-#ifndef CONFIG_ARM_64
-    if ( ((id >> SMMU_ID0_PTFS_SHIFT) & SMMU_ID0_PTFS_MASK) ==
-            SMMU_ID0_PTFS_V8_ONLY )
-    {
-        smmu_err(smmu, "\tno v7 descriptor support!\n");
-        return -ENODEV;
-    }
-#endif
-    if ( id & SMMU_ID0_S1TS )
-    {
-        smmu->features |= SMMU_FEAT_TRANS_S1;
-        smmu_info(smmu, "\tstage 1 translation\n");
-    }
-
-    if ( id & SMMU_ID0_S2TS )
-    {
-        smmu->features |= SMMU_FEAT_TRANS_S2;
-        smmu_info(smmu, "\tstage 2 translation\n");
-    }
-
-    if ( id & SMMU_ID0_NTS )
-    {
-        smmu->features |= SMMU_FEAT_TRANS_NESTED;
-        smmu_info(smmu, "\tnested translation\n");
-    }
-
-    if ( !(smmu->features &
-           (SMMU_FEAT_TRANS_S1 | SMMU_FEAT_TRANS_S2 |
-            SMMU_FEAT_TRANS_NESTED)) )
-    {
-        smmu_err(smmu, "\tno translation support!\n");
-        return -ENODEV;
-    }
-
-    /* We need at least support for Stage 2 */
-    if ( !(smmu->features & SMMU_FEAT_TRANS_S2) )
-    {
-        smmu_err(smmu, "\tno stage 2 translation!\n");
-        return -ENODEV;
-    }
-
-    if ( id & SMMU_ID0_CTTW )
-    {
-        smmu->features |= SMMU_FEAT_COHERENT_WALK;
-        smmu_info(smmu, "\tcoherent table walk\n");
-    }
-
-    if ( id & SMMU_ID0_SMS )
-    {
-        u32 smr, sid, mask;
-
-        smmu->features |= SMMU_FEAT_STREAM_MATCH;
-        smmu->num_mapping_groups = (id >> SMMU_ID0_NUMSMRG_SHIFT) &
-            SMMU_ID0_NUMSMRG_MASK;
-        if ( smmu->num_mapping_groups == 0 )
-        {
-            smmu_err(smmu,
-                     "stream-matching supported, but no SMRs present!\n");
-            return -ENODEV;
-        }
-
-        smr = SMMU_SMR_MASK_MASK << SMMU_SMR_MASK_SHIFT;
-        smr |= (SMMU_SMR_ID_MASK << SMMU_SMR_ID_SHIFT);
-        writel_relaxed(smr, gr0_base + SMMU_GR0_SMR(0));
-        smr = readl_relaxed(gr0_base + SMMU_GR0_SMR(0));
-
-        mask = (smr >> SMMU_SMR_MASK_SHIFT) & SMMU_SMR_MASK_MASK;
-        sid = (smr >> SMMU_SMR_ID_SHIFT) & SMMU_SMR_ID_MASK;
-        if ( (mask & sid) != sid )
-        {
-            smmu_err(smmu,
-                     "SMR mask bits (0x%x) insufficient for ID field (0x%x)\n",
-                     mask, sid);
-            return -ENODEV;
-        }
-        smmu->smr_mask_mask = mask;
-        smmu->smr_id_mask = sid;
-
-        smmu_info(smmu,
-                  "\tstream matching with %u register groups, mask 0x%x\n",
-                  smmu->num_mapping_groups, mask);
-    }
-
-    /* ID1 */
-    id = readl_relaxed(gr0_base + SMMU_GR0_ID1);
-    smmu->pagesize = (id & SMMU_ID1_PAGESIZE) ? PAGE_SIZE_64K : PAGE_SIZE_4K;
-
-    /* Check for size mismatch of SMMU address space from mapped region */
-    size = 1 << (((id >> SMMU_ID1_NUMPAGENDXB_SHIFT) &
-                  SMMU_ID1_NUMPAGENDXB_MASK) + 1);
-    size *= (smmu->pagesize << 1);
-    if ( smmu->size != size )
-        smmu_warn(smmu, "SMMU address space size (0x%lx) differs "
-                  "from mapped region size (0x%lx)!\n", size, smmu->size);
-
-    smmu->num_s2_context_banks = (id >> SMMU_ID1_NUMS2CB_SHIFT) &
-        SMMU_ID1_NUMS2CB_MASK;
-    smmu->num_context_banks = (id >> SMMU_ID1_NUMCB_SHIFT) &
-        SMMU_ID1_NUMCB_MASK;
-    if ( smmu->num_s2_context_banks > smmu->num_context_banks )
-    {
-        smmu_err(smmu, "impossible number of S2 context banks!\n");
-        return -ENODEV;
-    }
-    smmu_info(smmu, "\t%u context banks (%u stage-2 only)\n",
-              smmu->num_context_banks, smmu->num_s2_context_banks);
-
-    /* ID2 */
-    id = readl_relaxed(gr0_base + SMMU_GR0_ID2);
-    size = arm_smmu_id_size_to_bits((id >> SMMU_ID2_IAS_SHIFT) &
-                                    SMMU_ID2_IAS_MASK);
-
-    /*
-     * Stage-1 output limited by stage-2 input size due to VTCR_EL2
-     * setup (see setup_virt_paging)
-     */
-    /* Current maximum output size of 40 bits */
-    smmu->s1_output_size = min(40UL, size);
-
-    /* The stage-2 output mask is also applied for bypass */
-    size = arm_smmu_id_size_to_bits((id >> SMMU_ID2_OAS_SHIFT) &
-                                    SMMU_ID2_OAS_MASK);
-    smmu->s2_output_size = min((unsigned long)PADDR_BITS, size);
-
-    if ( smmu->version == 1 )
-        smmu->input_size = 32;
-    else
-    {
-#ifdef CONFIG_ARM_64
-        size = (id >> SMMU_ID2_UBS_SHIFT) & SMMU_ID2_UBS_MASK;
-        size = min(39, arm_smmu_id_size_to_bits(size));
-#else
-        size = 32;
-#endif
-        smmu->input_size = size;
-
-        if ( (PAGE_SIZE == PAGE_SIZE_4K && !(id & SMMU_ID2_PTFS_4K) ) ||
-             (PAGE_SIZE == PAGE_SIZE_64K && !(id & SMMU_ID2_PTFS_64K)) ||
-             (PAGE_SIZE != PAGE_SIZE_4K && PAGE_SIZE != PAGE_SIZE_64K) )
-        {
-            smmu_err(smmu, "CPU page size 0x%lx unsupported\n",
-                     PAGE_SIZE);
-            return -ENODEV;
-        }
-    }
-
-    smmu_info(smmu, "\t%lu-bit VA, %lu-bit IPA, %lu-bit PA\n",
-              smmu->input_size, smmu->s1_output_size, smmu->s2_output_size);
-    return 0;
-}
-
-static __init void arm_smmu_device_reset(struct arm_smmu_device *smmu)
-{
-    void __iomem *gr0_base = SMMU_GR0(smmu);
-    void __iomem *cb_base;
-    int i = 0;
-    u32 reg;
-
-    smmu_dbg(smmu, "device reset\n");
-
-    /* Clear Global FSR */
-    reg = readl_relaxed(SMMU_GR0_NS(smmu) + SMMU_GR0_sGFSR);
-    writel(reg, SMMU_GR0_NS(smmu) + SMMU_GR0_sGFSR);
-
-    /* Mark all SMRn as invalid and all S2CRn as fault */
-    for ( i = 0; i < smmu->num_mapping_groups; ++i )
-    {
-        writel_relaxed(~SMMU_SMR_VALID, gr0_base + SMMU_GR0_SMR(i));
-        writel_relaxed(SMMU_S2CR_TYPE_FAULT, gr0_base + SMMU_GR0_S2CR(i));
-    }
-
-    /* Make sure all context banks are disabled and clear CB_FSR  */
-    for ( i = 0; i < smmu->num_context_banks; ++i )
-    {
-        cb_base = SMMU_CB_BASE(smmu) + SMMU_CB(smmu, i);
-        writel_relaxed(0, cb_base + SMMU_CB_SCTLR);
-        writel_relaxed(SMMU_FSR_FAULT, cb_base + SMMU_CB_FSR);
-    }
-
-    /* Invalidate the TLB, just in case */
-    writel_relaxed(0, gr0_base + SMMU_GR0_STLBIALL);
-    writel_relaxed(0, gr0_base + SMMU_GR0_TLBIALLH);
-    writel_relaxed(0, gr0_base + SMMU_GR0_TLBIALLNSNH);
-
-    reg = readl_relaxed(SMMU_GR0_NS(smmu) + SMMU_GR0_sCR0);
-
-    /* Enable fault reporting */
-    reg |= (SMMU_sCR0_GFRE | SMMU_sCR0_GFIE |
-            SMMU_sCR0_GCFGFRE | SMMU_sCR0_GCFGFIE);
-
-    /* Disable TLB broadcasting. */
-    reg |= (SMMU_sCR0_VMIDPNE | SMMU_sCR0_PTM);
-
-    /* Enable client access, generate a fault if no mapping is found */
-    reg &= ~(SMMU_sCR0_CLIENTPD);
-    reg |= SMMU_sCR0_USFCFG;
-
-    /* Disable forced broadcasting */
-    reg &= ~SMMU_sCR0_FB;
-
-    /* Don't upgrade barriers when client devices are not mapped to
-     * a translation context banks (just here for clarity as Xen policy
-     * is to deny invalid transaction). */
-    reg &= ~(SMMU_sCR0_BSU_MASK << SMMU_sCR0_BSU_SHIFT);
-
-    /* Push the button */
-    arm_smmu_tlb_sync(smmu);
-    writel_relaxed(reg, SMMU_GR0_NS(smmu) + SMMU_GR0_sCR0);
-}
-
-static int arm_smmu_iommu_domain_init(struct domain *d)
-{
-    struct arm_smmu_domain *smmu_domain;
-
-    smmu_domain = xzalloc(struct arm_smmu_domain);
-    if ( !smmu_domain )
-        return -ENOMEM;
-
-    spin_lock_init(&smmu_domain->lock);
-    INIT_LIST_HEAD(&smmu_domain->contexts);
-
-    domain_hvm_iommu(d)->arch.priv = smmu_domain;
-
-    return 0;
-}
-
-static void __hwdom_init arm_smmu_iommu_hwdom_init(struct domain *d)
-{
-}
-
-static void arm_smmu_iommu_domain_teardown(struct domain *d)
-{
-    struct arm_smmu_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
-
-    ASSERT(list_empty(&smmu_domain->contexts));
-    xfree(smmu_domain);
-}
-
-static int arm_smmu_map_page(struct domain *d, unsigned long gfn,
-                             unsigned long mfn, unsigned int flags)
-{
-    p2m_type_t t;
-
-    /* Grant mappings can be used for DMA requests. The dev_bus_addr returned by
-     * the hypercall is the MFN (not the IPA). For device protected by
-     * an IOMMU, Xen needs to add a 1:1 mapping in the domain p2m to
-     * allow DMA request to work.
-     * This is only valid when the domain is directed mapped. Hence this
-     * function should only be used by gnttab code with gfn == mfn.
-     */
-    BUG_ON(!is_domain_direct_mapped(d));
-    BUG_ON(mfn != gfn);
-
-    /* We only support readable and writable flags */
-    if ( !(flags & (IOMMUF_readable | IOMMUF_writable)) )
-        return -EINVAL;
-
-    t = (flags & IOMMUF_writable) ? p2m_iommu_map_rw : p2m_iommu_map_ro;
-
-    /* The function guest_physmap_add_entry replaces the current mapping
-     * if there is already one...
-     */
-    return guest_physmap_add_entry(d, gfn, mfn, 0, t);
-}
-
-static int arm_smmu_unmap_page(struct domain *d, unsigned long gfn)
-{
-    /* This function should only be used by gnttab code when the domain
-     * is direct mapped
-     */
-    if ( !is_domain_direct_mapped(d) )
-        return -EINVAL;
-
-    guest_physmap_remove_page(d, gfn, gfn, 0);
-
-    return 0;
-}
-
-static const struct iommu_ops arm_smmu_iommu_ops = {
-    .init = arm_smmu_iommu_domain_init,
-    .hwdom_init = arm_smmu_iommu_hwdom_init,
-    .teardown = arm_smmu_iommu_domain_teardown,
-    .iotlb_flush = arm_smmu_iotlb_flush,
-    .iotlb_flush_all = arm_smmu_iotlb_flush_all,
-    .assign_dt_device = arm_smmu_attach_dev,
-    .reassign_dt_device = arm_smmu_reassign_dt_dev,
-    .map_page = arm_smmu_map_page,
-    .unmap_page = arm_smmu_unmap_page,
-};
-
-static int __init smmu_init(struct dt_device_node *dev,
-                            const void *data)
-{
-    struct arm_smmu_device *smmu;
-    int res;
-    u64 addr, size;
-    unsigned int num_irqs, i;
-    struct dt_phandle_args masterspec;
-    struct rb_node *node;
-
-    /* Even if the device can't be initialized, we don't want to give
-     * the smmu device to dom0.
-     */
-    dt_device_set_used_by(dev, DOMID_XEN);
-
-    smmu = xzalloc(struct arm_smmu_device);
-    if ( !smmu )
-    {
-        printk(XENLOG_ERR "%s: failed to allocate arm_smmu_device\n",
-               dt_node_full_name(dev));
-        return -ENOMEM;
-    }
-
-    smmu->node = dev;
-    check_driver_options(smmu);
-
-    res = dt_device_get_address(smmu->node, 0, &addr, &size);
-    if ( res )
-    {
-        smmu_err(smmu, "unable to retrieve the base address of the SMMU\n");
-        goto out_err;
-    }
-
-    smmu->base = ioremap_nocache(addr, size);
-    if ( !smmu->base )
-    {
-        smmu_err(smmu, "unable to map the SMMU memory\n");
-        goto out_err;
-    }
-
-    smmu->size = size;
-
-    if ( !dt_property_read_u32(smmu->node, "#global-interrupts",
-                               &smmu->num_global_irqs) )
-    {
-        smmu_err(smmu, "missing #global-interrupts\n");
-        goto out_unmap;
-    }
-
-    num_irqs = dt_number_of_irq(smmu->node);
-    if ( num_irqs > smmu->num_global_irqs )
-        smmu->num_context_irqs = num_irqs - smmu->num_global_irqs;
-
-    if ( !smmu->num_context_irqs )
-    {
-        smmu_err(smmu, "found %d interrupts but expected at least %d\n",
-                 num_irqs, smmu->num_global_irqs + 1);
-        goto out_unmap;
-    }
-
-    smmu->irqs = xzalloc_array(unsigned int, num_irqs);
-    if ( !smmu->irqs )
-    {
-        smmu_err(smmu, "failed to allocated %d irqs\n", num_irqs);
-        goto out_unmap;
-    }
-
-    for ( i = 0; i < num_irqs; i++ )
-    {
-        res = platform_get_irq(smmu->node, i);
-        if ( res < 0 )
-        {
-            smmu_err(smmu, "failed to get irq index %d\n", i);
-            goto out_free_irqs;
-        }
-        smmu->irqs[i] = res;
-    }
-
-    smmu->sids = xzalloc_array(unsigned long,
-                               BITS_TO_LONGS(SMMU_MAX_STREAMIDS));
-    if ( !smmu->sids )
-    {
-        smmu_err(smmu, "failed to allocated bitmap for stream ID tracking\n");
-        goto out_free_masters;
-    }
-
-
-    i = 0;
-    smmu->masters = RB_ROOT;
-    while ( !dt_parse_phandle_with_args(smmu->node, "mmu-masters",
-                                        "#stream-id-cells", i, &masterspec) )
-    {
-        res = register_smmu_master(smmu, &masterspec);
-        if ( res )
-        {
-            smmu_err(smmu, "failed to add master %s\n",
-                     masterspec.np->name);
-            goto out_free_masters;
-        }
-        i++;
-    }
-
-    smmu_info(smmu, "registered %d master devices\n", i);
-
-    res = arm_smmu_device_cfg_probe(smmu);
-    if ( res )
-    {
-        smmu_err(smmu, "failed to probe the SMMU\n");
-        goto out_free_masters;
-    }
-
-    if ( smmu->version > 1 &&
-         smmu->num_context_banks != smmu->num_context_irqs )
-    {
-        smmu_err(smmu,
-                 "found only %d context interrupt(s) but %d required\n",
-                 smmu->num_context_irqs, smmu->num_context_banks);
-        goto out_free_masters;
-    }
-
-    smmu_dbg(smmu, "register global IRQs handler\n");
-
-    for ( i = 0; i < smmu->num_global_irqs; ++i )
-    {
-        smmu_dbg(smmu, "\t- global IRQ %u\n", smmu->irqs[i]);
-        res = request_irq(smmu->irqs[i], IRQF_SHARED, arm_smmu_global_fault,
-                          "arm-smmu global fault", smmu);
-        if ( res )
-        {
-            smmu_err(smmu, "failed to request global IRQ %d (%u)\n",
-                     i, smmu->irqs[i]);
-            goto out_release_irqs;
-        }
-    }
-
-    INIT_LIST_HEAD(&smmu->list);
-    list_add(&smmu->list, &arm_smmu_devices);
-
-    arm_smmu_device_reset(smmu);
-
-    iommu_set_ops(&arm_smmu_iommu_ops);
-
-    /* sids field can be freed... */
-    xfree(smmu->sids);
-    smmu->sids = NULL;
-
-    return 0;
-
-out_release_irqs:
-    while (i--)
-        release_irq(smmu->irqs[i], smmu);
-
-out_free_masters:
-    for ( node = rb_first(&smmu->masters); node; node = rb_next(node) )
-    {
-        struct arm_smmu_master *master;
-
-        master = container_of(node, struct arm_smmu_master, node);
-        xfree(master);
-    }
-
-    xfree(smmu->sids);
-
-out_free_irqs:
-    xfree(smmu->irqs);
-
-out_unmap:
-    iounmap(smmu->base);
-
-out_err:
-    xfree(smmu);
-
-    return -ENODEV;
-}
-
-static const char * const smmu_dt_compat[] __initconst =
-{
-    "arm,mmu-400",
-    NULL
-};
-
-DT_DEVICE_START(smmu, "ARM SMMU", DEVICE_IOMMU)
-    .compatible = smmu_dt_compat,
-    .init = smmu_init,
-DT_DEVICE_END
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yRE-0004xz-Ny; Tue, 16 Dec 2014 20:09:44 +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 1Y0yRD-0004w0-Af
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:43 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	0D/FB-25714-68190945; Tue, 16 Dec 2014 20:09:42 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418760580!10358423!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2804 invoked from network); 16 Dec 2014 20:09:40 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:40 -0000
Received: by mail-wi0-f169.google.com with SMTP id r20so14837980wiv.2
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=tt8da0oBo4GLxBOmU9YJnQWfQ9lTtcOZFjbUTVTr1Ro=;
	b=VN2ONlmA+5bl2gsiVlIaNNEIVRqRHFnDwZku1StA5HRYc7yLyZCHBj3tf3ziOGx1c2
	JLcYuR7LprahaDEPO62o4kVUuaErksB6G+nMk4wKBg6n6w+fb1X8fMPkUNscHVumFJho
	/ZyrQ8N8v30yLKnYDCtknhugMluAslyPySebRmeGi9ote8n9p28714MOrdYo7bEefI3v
	uedAmEr6ag8vmDGBK11A+OzLHfcmf+Komu3v1WHKrOXQplT8dDJ1CAYlQHch8xQZSjf6
	F7e29IqVm4XMv4854mBUUejSEUYjFJsSZIrTuvMg3zcQfYNYIPv62d3lArUwfN5P5MCL
	DrZg==
X-Gm-Message-State: ALoCoQl90RPcoq9iSkG155XrbgQ0QyAHKXMvTG8IHFoGa+7+seQFB3pUMPKkISuSZfZi/++6Z4Ko
X-Received: by 10.180.218.133 with SMTP id pg5mr7753819wic.70.1418760579316;
	Tue, 16 Dec 2014 12:09:39 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.37
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:38 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:54 +0000
Message-Id: <1418760534-18163-14-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 13/13] xen/iommu: smmu: Add Xen specific
	code to be able to use the 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

The main goal is to modify as little the Linux code to be able to port
easily new feature added in Linux repo for the driver.

To achieve that we:
    - Add helpers to Linux function not implemented on Xen
    - Add callbacks used by Xen to do our own stuff and call Linux ones
    - Only modify when required the code which comes from Linux. If so a
    comment has been added with /* Xen: ... */ explaining why it's
    necessary.

The support for PCI has been commented because it's not yet supported by
Xen ARM and therefore won't compile.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/drivers/passthrough/arm/Makefile |   1 +
 xen/drivers/passthrough/arm/smmu.c   | 668 +++++++++++++++++++++++++++++++----
 2 files changed, 602 insertions(+), 67 deletions(-)

diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile
index 0484b79..f4cd26e 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1 +1,2 @@
 obj-y += iommu.o
+obj-y += smmu.o
diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
index 8a6514f..3cf1773 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -18,6 +18,13 @@
  *
  * Author: Will Deacon <will.deacon@arm.com>
  *
+ * Based on Linux drivers/iommu/arm-smmu.c
+ *	=> commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3
+ *
+ * Xen modification:
+ * Julien Grall <julien.grall@linaro.org>
+ * Copyright (C) 2014 Linaro Limited.
+ *
  * This driver currently supports:
  *	- SMMUv1 and v2 implementations
  *	- Stream-matching and stream-indexing
@@ -28,26 +35,154 @@
  *	- Context fault reporting
  */
 
-#define pr_fmt(fmt) "arm-smmu: " fmt
 
-#include <linux/delay.h>
-#include <linux/dma-mapping.h>
-#include <linux/err.h>
-#include <linux/interrupt.h>
-#include <linux/io.h>
-#include <linux/iommu.h>
-#include <linux/mm.h>
-#include <linux/module.h>
-#include <linux/of.h>
-#include <linux/pci.h>
-#include <linux/platform_device.h>
-#include <linux/slab.h>
-#include <linux/spinlock.h>
-#include <linux/bitops.h>
+#include <xen/config.h>
+#include <xen/delay.h>
+#include <xen/device.h>
+#include <xen/errno.h>
+#include <xen/err.h>
+#include <xen/irq.h>
+#include <xen/lib.h>
+#include <xen/list.h>
+#include <xen/mm.h>
+#include <xen/vmap.h>
+#include <xen/rbtree.h>
+#include <xen/sched.h>
+#include <xen/sizes.h>
+#include <asm/atomic.h>
+#include <asm/io.h>
+#include <asm/platform.h>
+
+/* Xen: The below defines are redefined within the file. Undef it */
+#undef SCTLR_AFE
+#undef SCTLR_TRE
+#undef SCTLR_M
+#undef TTBCR_EAE
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource
+{
+	u64 addr;
+	u64 size;
+	unsigned int type;
+};
+
+#define resource_size(res) (res)->size;
+
+#define platform_device dt_device_node
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+					      unsigned int type,
+					      unsigned int num)
+{
+	/*
+	 * The resource is only used between 2 calls of platform_get_resource.
+	 * It's quite ugly but it's avoid to add too much code in the part
+	 * imported from Linux
+	 */
+	static struct resource res;
+	int ret = 0;
+
+	res.type = type;
+
+	switch (type) {
+	case IORESOURCE_MEM:
+		ret = dt_device_get_address(pdev, num, &res.addr, &res.size);
+
+		return ((ret) ? NULL : &res);
+
+	case IORESOURCE_IRQ:
+		ret = platform_get_irq(pdev, num);
+		if (ret < 0)
+			return NULL;
+
+		res.addr = ret;
+		res.size = 1;
+
+		return &res;
+
+	default:
+		return NULL;
+	}
+}
+
+/* Alias to Xen IRQ functions */
+#define request_irq(irq, func, flags, name, dev) request_irq(irq, flags, func, name, dev)
+#define free_irq release_irq
+
+/*
+ * Device logger functions
+ * TODO: Handle PCI
+ */
+#define dev_print(dev, lvl, fmt, ...)						\
+	 printk(lvl "smmu: %s: " fmt, dt_node_full_name(dev_to_dt(dev)), ## __VA_ARGS__)
+
+#define dev_dbg(dev, fmt, ...) dev_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__)
+#define dev_notice(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__)
+#define dev_warn(dev, fmt, ...) dev_print(dev, XENLOG_WARNING, fmt, ## __VA_ARGS__)
+#define dev_err(dev, fmt, ...) dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
+
+#define dev_err_ratelimited(dev, fmt, ...)					\
+	 dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
 
-#include <linux/amba/bus.h>
+#define dev_name(dev) dt_node_full_name(dev_to_dt(dev))
 
-#include <asm/pgalloc.h>
+/* Alias to Xen allocation helpers */
+#define kfree xfree
+#define kmalloc(size, flags)		_xmalloc(size, sizeof(void *))
+#define kzalloc(size, flags)		_xzalloc(size, sizeof(void *))
+#define devm_kzalloc(dev, size, flags)	_xzalloc(size, sizeof(void *))
+#define kmalloc_array(size, n, flags)	_xmalloc_array(size, sizeof(void *), n)
+
+static void __iomem *devm_ioremap_resource(struct device *dev,
+					   struct resource *res)
+{
+	void __iomem *ptr;
+
+	if (!res || res->type != IORESOURCE_MEM) {
+		dev_err(dev, "Invalid resource\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	ptr = ioremap_nocache(res->addr, res->size);
+	if (!ptr) {
+		dev_err(dev,
+			"ioremap failed (addr 0x%"PRIx64" size 0x%"PRIx64")\n",
+			res->addr, res->size);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	return ptr;
+}
+
+/* Xen doesn't handle IOMMU fault */
+#define report_iommu_fault(...)	1
+
+#define IOMMU_FAULT_READ	0
+#define IOMMU_FAULT_WRITE	1
+
+/* Xen: misc */
+#define PHYS_MASK_SHIFT		PADDR_BITS
+
+#ifdef CONFIG_ARM_64
+# define CONFIG_64BIT
+#endif
+
+#define VA_BITS		0	/* Only used for configuring stage-1 input size */
+
+/***** Start of SMMU definitions *****/
 
 /* Maximum number of stream IDs assigned to a single device */
 #define MAX_MASTER_STREAMIDS		MAX_PHANDLE_ARGS
@@ -330,10 +465,14 @@
 
 #define FSYNR0_WNR			(1 << 4)
 
-static int force_stage;
-module_param_named(force_stage, force_stage, int, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(force_stage,
-	"Force SMMU mappings to be installed at a particular stage of translation. A value of '1' or '2' forces the corresponding stage. All other values are ignored (i.e. no stage is forced). Note that selecting a specific stage will disable support for nested translation.");
+/* Force SMMU mapping to be installed at a particular stage of translation.
+ * A value of '1' or '2' forces the corresponding state. All other values
+ * are ignored (i.e no stage is forced). Note that selecting a specific stage
+ * will disable support for nested translation.
+ *
+ * Xen is only supported stage-2 translation, so force the value to 2.
+ */
+static const int force_stage = 2;
 
 enum arm_smmu_arch_version {
 	ARM_SMMU_V1 = 1,
@@ -406,7 +545,9 @@ struct arm_smmu_cfg {
 	u8				cbndx;
 	u8				irptndx;
 	u32				cbar;
-	pgd_t				*pgd;
+
+	/* Xen: Domain associated to this configuration */
+	struct domain			*domain;
 };
 #define INVALID_IRPTNDX			0xff
 
@@ -426,6 +567,90 @@ struct arm_smmu_domain {
 	spinlock_t			lock;
 };
 
+/* Xen: Dummy iommu_domain */
+struct iommu_domain
+{
+	struct arm_smmu_domain		*priv;
+
+	/* Used to link domain contexts for a same domain */
+	struct list_head		list;
+};
+
+/* Xen: Describes informations required for a Xen domain */
+struct arm_smmu_xen_domain {
+	spinlock_t			lock;
+	/* List of context (i.e iommu_domain) associated to this domain */
+	struct list_head		contexts;
+};
+
+/* Xen: Information about each device stored in dev->archdata.iommu */
+struct arm_smmu_xen_device {
+	struct iommu_domain *domain;
+	struct iommu_group *group;
+};
+
+#define dev_archdata(dev) ((struct arm_smmu_xen_device *)dev->archdata.iommu)
+#define dev_iommu_domain(dev) (dev_archdata(dev)->domain)
+#define dev_iommu_group(dev) (dev_archdata(dev)->group)
+
+/* Xen: Dummy iommu_group */
+struct iommu_group
+{
+	struct arm_smmu_master_cfg *cfg;
+
+	atomic_t ref;
+};
+
+static struct iommu_group *iommu_group_alloc(void)
+{
+	struct iommu_group *group = xzalloc(struct iommu_group);
+
+	if (!group)
+		return ERR_PTR(-ENOMEM);
+
+	atomic_set(&group->ref, 1);
+
+	return group;
+}
+
+static void iommu_group_put(struct iommu_group *group)
+{
+	if (atomic_dec_and_test(&group->ref))
+		xfree(group);
+}
+
+static void iommu_group_set_iommudata(struct iommu_group *group,
+				      struct arm_smmu_master_cfg *cfg,
+				      void (*releasefn)(void *))
+{
+	/* TODO: Store the releasefn for the PCI */
+	ASSERT(releasefn == NULL);
+
+	group->cfg = cfg;
+}
+
+static int iommu_group_add_device(struct iommu_group *group,
+				  struct device *dev)
+{
+	dev_iommu_group(dev) = group;
+
+	atomic_inc(&group->ref);
+
+	return 0;
+}
+
+static struct iommu_group *iommu_group_get(struct device *dev)
+{
+	struct iommu_group *group = dev_iommu_group(dev);
+
+	if (group)
+		atomic_inc(&group->ref);
+
+	return group;
+}
+
+#define iommu_group_get_iommudata(group) (group)->cfg
+
 static DEFINE_SPINLOCK(arm_smmu_devices_lock);
 static LIST_HEAD(arm_smmu_devices);
 
@@ -455,6 +680,8 @@ static void parse_driver_options(struct arm_smmu_device *smmu)
 
 static struct device_node *dev_get_dev_node(struct device *dev)
 {
+	/* Xen: TODO: Add support for PCI */
+#if 0
 	if (dev_is_pci(dev)) {
 		struct pci_bus *bus = to_pci_dev(dev)->bus;
 
@@ -462,7 +689,7 @@ static struct device_node *dev_get_dev_node(struct device *dev)
 			bus = bus->parent;
 		return bus->bridge->parent->of_node;
 	}
-
+#endif
 	return dev->of_node;
 }
 
@@ -556,6 +783,9 @@ static int register_smmu_master(struct arm_smmu_device *smmu,
 	master->of_node			= masterspec->np;
 	master->cfg.num_streamids	= masterspec->args_count;
 
+	/* Xen: Let Xen knows that the device is protected by an SMMU */
+	dt_device_set_protected(masterspec->np);
+
 	for (i = 0; i < master->cfg.num_streamids; ++i) {
 		u16 streamid = masterspec->args[i];
 
@@ -651,11 +881,12 @@ static void arm_smmu_tlb_inv_context(struct arm_smmu_domain *smmu_domain)
 	arm_smmu_tlb_sync(smmu);
 }
 
-static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
+static void arm_smmu_context_fault(int irq, void *dev,
+				   struct cpu_user_regs *regs)
 {
-	int flags, ret;
+	int flags;
 	u32 fsr, far, fsynr, resume;
-	unsigned long iova;
+	paddr_t iova;
 	struct iommu_domain *domain = dev;
 	struct arm_smmu_domain *smmu_domain = domain->priv;
 	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
@@ -666,7 +897,7 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
 	fsr = readl_relaxed(cb_base + ARM_SMMU_CB_FSR);
 
 	if (!(fsr & FSR_FAULT))
-		return IRQ_NONE;
+		return;
 
 	if (fsr & FSR_IGN)
 		dev_err_ratelimited(smmu->dev,
@@ -678,19 +909,16 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
 
 	far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_LO);
 	iova = far;
-#ifdef CONFIG_64BIT
+	/* Xen: The fault address maybe higher than 32 bits on arm32 */
 	far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_HI);
-	iova |= ((unsigned long)far << 32);
-#endif
+	iova |= ((paddr_t)far << 32);
 
 	if (!report_iommu_fault(domain, smmu->dev, iova, flags)) {
-		ret = IRQ_HANDLED;
 		resume = RESUME_RETRY;
 	} else {
 		dev_err_ratelimited(smmu->dev,
-		    "Unhandled context fault: iova=0x%08lx, fsynr=0x%x, cb=%d\n",
+		    "Unhandled context fault: iova=0x%"PRIpaddr", fsynr=0x%x, cb=%d\n",
 		    iova, fsynr, cfg->cbndx);
-		ret = IRQ_NONE;
 		resume = RESUME_TERMINATE;
 	}
 
@@ -700,11 +928,10 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
 	/* Retry or terminate any stalled transactions */
 	if (fsr & FSR_SS)
 		writel_relaxed(resume, cb_base + ARM_SMMU_CB_RESUME);
-
-	return ret;
 }
 
-static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
+static void arm_smmu_global_fault(int irq, void *dev,
+                                  struct cpu_user_regs *regs)
 {
 	u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
 	struct arm_smmu_device *smmu = dev;
@@ -716,7 +943,7 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
 	gfsynr2 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR2);
 
 	if (!gfsr)
-		return IRQ_NONE;
+		return;
 
 	dev_err_ratelimited(smmu->dev,
 		"Unexpected global fault, this could be serious\n");
@@ -725,9 +952,10 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
 		gfsr, gfsynr0, gfsynr1, gfsynr2);
 
 	writel(gfsr, gr0_base + ARM_SMMU_GR0_sGFSR);
-	return IRQ_HANDLED;
 }
 
+/* Xen: Page tables are shared with the processor */
+#if 0
 static void arm_smmu_flush_pgtable(struct arm_smmu_device *smmu, void *addr,
 				   size_t size)
 {
@@ -749,6 +977,7 @@ static void arm_smmu_flush_pgtable(struct arm_smmu_device *smmu, void *addr,
 				DMA_TO_DEVICE);
 	}
 }
+#endif
 
 static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 {
@@ -757,6 +986,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 	struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
 	struct arm_smmu_device *smmu = smmu_domain->smmu;
 	void __iomem *cb_base, *gr0_base, *gr1_base;
+	paddr_t p2maddr;
 
 	gr0_base = ARM_SMMU_GR0(smmu);
 	gr1_base = ARM_SMMU_GR1(smmu);
@@ -840,11 +1070,16 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 	}
 
 	/* TTBR0 */
-	arm_smmu_flush_pgtable(smmu, cfg->pgd,
-			       PTRS_PER_PGD * sizeof(pgd_t));
-	reg = __pa(cfg->pgd);
+	/* Xen: The page table is shared with the P2M code */
+	ASSERT(smmu_domain->cfg.domain != NULL);
+	p2maddr = page_to_maddr(smmu_domain->cfg.domain->arch.p2m.root);
+
+	dev_notice(smmu->dev, "d%u: p2maddr 0x%"PRIpaddr"\n",
+		   smmu_domain->cfg.domain->domain_id, p2maddr);
+
+	reg = (p2maddr & ((1ULL << 32) - 1));
 	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
-	reg = (phys_addr_t)__pa(cfg->pgd) >> 32;
+	reg = (p2maddr >> 32);
 	if (stage1)
 		reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
 	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
@@ -886,9 +1121,21 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 			reg |= (64 - smmu->s1_input_size) << TTBCR_T0SZ_SHIFT;
 		}
 	} else {
+#if CONFIG_ARM_32
+		/* Xen: Midway is using 40-bit address space. Though it may
+		 * not work on other ARM32 platform with SMMU-v1.
+		 * TODO: A quirk may be necessary if we have to support
+		 * other ARM32 platform with SMMU-v1.
+		 */
+		reg = 0x18 << TTBCR_T0SZ_SHIFT;
+#else
 		reg = 0;
+#endif
 	}
 
+	/* Xen: The attributes to walk the page table should be the same as
+	 * VTCR_EL2. Currently doesn't differ from Linux ones.
+	 */
 	reg |= TTBCR_EAE |
 	      (TTBCR_SH_IS << TTBCR_SH0_SHIFT) |
 	      (TTBCR_RGN_WBWA << TTBCR_ORGN0_SHIFT) |
@@ -1031,7 +1278,6 @@ static void arm_smmu_destroy_domain_context(struct iommu_domain *domain)
 static int arm_smmu_domain_init(struct iommu_domain *domain)
 {
 	struct arm_smmu_domain *smmu_domain;
-	pgd_t *pgd;
 
 	/*
 	 * Allocate the domain and initialise some of its data structures.
@@ -1042,20 +1288,12 @@ static int arm_smmu_domain_init(struct iommu_domain *domain)
 	if (!smmu_domain)
 		return -ENOMEM;
 
-	pgd = kcalloc(PTRS_PER_PGD, sizeof(pgd_t), GFP_KERNEL);
-	if (!pgd)
-		goto out_free_domain;
-	smmu_domain->cfg.pgd = pgd;
-
 	spin_lock_init(&smmu_domain->lock);
 	domain->priv = smmu_domain;
 	return 0;
-
-out_free_domain:
-	kfree(smmu_domain);
-	return -ENOMEM;
 }
 
+#if 0
 static void arm_smmu_free_ptes(pmd_t *pmd)
 {
 	pgtable_t table = pmd_pgtable(*pmd);
@@ -1118,6 +1356,7 @@ static void arm_smmu_free_pgtables(struct arm_smmu_domain *smmu_domain)
 
 	kfree(pgd_base);
 }
+#endif
 
 /*
  * For a given set N of 2**order different stream IDs (no duplicates
@@ -1259,7 +1498,6 @@ static void arm_smmu_domain_destroy(struct iommu_domain *domain)
 	 * already been detached.
 	 */
 	arm_smmu_destroy_domain_context(domain);
-	arm_smmu_free_pgtables(smmu_domain);
 	kfree(smmu_domain);
 }
 
@@ -1384,11 +1622,12 @@ static void arm_smmu_domain_remove_master(struct arm_smmu_domain *smmu_domain,
 	/*
 	 * We *must* clear the S2CR first, because freeing the SMR means
 	 * that it can be re-allocated immediately.
+	 * Xen: Unlike Linux, any access to non-configured stream will fault.
 	 */
 	for (i = 0; i < cfg->num_streamids; ++i) {
 		u32 idx = cfg->smrs ? cfg->smrs[i].idx : cfg->streamids[i];
 
-		writel_relaxed(S2CR_TYPE_BYPASS,
+		writel_relaxed(S2CR_TYPE_FAULT,
 			       gr0_base + ARM_SMMU_GR0_S2CR(idx));
 	}
 
@@ -1408,7 +1647,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 		return -ENXIO;
 	}
 
-	if (dev->archdata.iommu) {
+	if (dev_iommu_domain(dev)) {
 		dev_err(dev, "already attached to IOMMU domain\n");
 		return -EEXIST;
 	}
@@ -1440,8 +1679,9 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 		return -ENODEV;
 
 	ret = arm_smmu_domain_add_master(smmu_domain, cfg);
+
 	if (!ret)
-		dev->archdata.iommu = domain;
+		dev_iommu_domain(dev) = domain;
 	return ret;
 }
 
@@ -1454,10 +1694,14 @@ static void arm_smmu_detach_dev(struct iommu_domain *domain, struct device *dev)
 	if (!cfg)
 		return;
 
-	dev->archdata.iommu = NULL;
+	dev_iommu_domain(dev) = NULL;
 	arm_smmu_domain_remove_master(smmu_domain, cfg);
 }
 
+/* Xen: the page table is shared with the processor, therefore helpers to
+ * implement separate is not necessary.
+ */
+#if 0
 static bool arm_smmu_pte_is_contiguous_range(unsigned long addr,
 					     unsigned long end)
 {
@@ -1746,7 +1990,10 @@ static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
 
 	return __pfn_to_phys(pte_pfn(pte)) | (iova & ~PAGE_MASK);
 }
+#endif
 
+/* Xen: Functions are not used at the moment */
+#if 0
 static bool arm_smmu_capable(enum iommu_cap cap)
 {
 	switch (cap) {
@@ -1775,6 +2022,7 @@ static void __arm_smmu_release_pci_iommudata(void *data)
 {
 	kfree(data);
 }
+#endif
 
 static int arm_smmu_add_device(struct device *dev)
 {
@@ -1784,6 +2032,10 @@ static int arm_smmu_add_device(struct device *dev)
 	void (*releasefn)(void *) = NULL;
 	int ret;
 
+	/* Xen: Check if the device has already been added */
+	if (dev_iommu_group(dev))
+		return -EBUSY;
+
 	smmu = find_smmu_for_device(dev);
 	if (!smmu)
 		return -ENODEV;
@@ -1795,6 +2047,9 @@ static int arm_smmu_add_device(struct device *dev)
 	}
 
 	if (dev_is_pci(dev)) {
+		/* Xen: TODO: Add PCI support */
+		BUG();
+#if 0
 		struct pci_dev *pdev = to_pci_dev(dev);
 
 		cfg = kzalloc(sizeof(*cfg), GFP_KERNEL);
@@ -1811,6 +2066,7 @@ static int arm_smmu_add_device(struct device *dev)
 		pci_for_each_dma_alias(pdev, __arm_smmu_get_pci_sid,
 				       &cfg->streamids[0]);
 		releasefn = __arm_smmu_release_pci_iommudata;
+#endif
 	} else {
 		struct arm_smmu_master *master;
 
@@ -1831,6 +2087,8 @@ out_put_group:
 	return ret;
 }
 
+/* Xen: We don't support remove device for now. Will be useful for PCI */
+#if 0
 static void arm_smmu_remove_device(struct device *dev)
 {
 	iommu_group_remove_device(dev);
@@ -1888,6 +2146,7 @@ static const struct iommu_ops arm_smmu_ops = {
 				   ARM_SMMU_PTE_CONT_SIZE |
 				   PAGE_SIZE),
 };
+#endif
 
 static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 {
@@ -1903,7 +2162,11 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 	/* Mark all SMRn as invalid and all S2CRn as bypass */
 	for (i = 0; i < smmu->num_mapping_groups; ++i) {
 		writel_relaxed(0, gr0_base + ARM_SMMU_GR0_SMR(i));
-		writel_relaxed(S2CR_TYPE_BYPASS,
+		/*
+		 * Xen: Unlike Linux, any access to a non-configure stream
+		 * will fault by default.
+		 */
+		writel_relaxed(S2CR_TYPE_FAULT,
 			gr0_base + ARM_SMMU_GR0_S2CR(i));
 	}
 
@@ -1929,6 +2192,8 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 
 	/* Enable client access, but bypass when no mapping is found */
 	reg &= ~(sCR0_CLIENTPD | sCR0_USFCFG);
+	/* Xen: Unlike Linux, generate a fault when no mapping is found */
+	reg |= sCR0_USFCFG;
 
 	/* Disable forced broadcasting */
 	reg &= ~sCR0_FB;
@@ -2039,7 +2304,7 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
 		smmu->smr_id_mask = sid;
 
 		dev_notice(smmu->dev,
-			   "\tstream matching with %u register groups, mask 0x%x",
+			   "\tstream matching with %u register groups, mask 0x%x\n",
 			   smmu->num_mapping_groups, mask);
 	} else {
 		smmu->num_mapping_groups = (id >> ID0_NUMSIDB_SHIFT) &
@@ -2074,12 +2339,30 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
 	size = arm_smmu_id_size_to_bits((id >> ID2_IAS_SHIFT) & ID2_IAS_MASK);
 	smmu->s1_output_size = min_t(unsigned long, PHYS_MASK_SHIFT, size);
 
+	/* Xen: Stage-2 input size is not restricted */
+	smmu->s2_input_size = size;
+#if 0
 	/* Stage-2 input size limited due to pgd allocation (PTRS_PER_PGD) */
 #ifdef CONFIG_64BIT
 	smmu->s2_input_size = min_t(unsigned long, VA_BITS, size);
 #else
 	smmu->s2_input_size = min(32UL, size);
 #endif
+#endif
+
+	/*
+	 * Xen: SMMU v1: Only 40 bits input address size is supported for
+ 	 * arm32. See arm_smmu_init_context_bank
+	 */
+#ifdef CONFIG_ARM_32
+	if ( smmu->version == ARM_SMMU_V1 && smmu->s2_input_size != 40 )
+	{
+		dev_err(smmu->dev,
+			"Stage-2 Input size %ld not supported for SMMUv1\n",
+			smmu->s2_input_size);
+		return -ENODEV;;
+	}
+#endif
 
 	/* The stage-2 output mask is also applied for bypass */
 	size = arm_smmu_id_size_to_bits((id >> ID2_OAS_SHIFT) & ID2_OAS_MASK);
@@ -2124,8 +2407,11 @@ static const struct of_device_id arm_smmu_of_match[] = {
 	{ .compatible = "arm,mmu-500", .data = (void *)ARM_SMMU_V2 },
 	{ },
 };
-MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
 
+/*
+ * Xen: We don't have refcount allocated memory so manually free memory when
+ * an error occured.
+ */
 static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 {
 	const struct of_device_id *of_id;
@@ -2149,14 +2435,17 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	smmu->base = devm_ioremap_resource(dev, res);
-	if (IS_ERR(smmu->base))
-		return PTR_ERR(smmu->base);
+	if (IS_ERR(smmu->base)) {
+		err = PTR_ERR(smmu->base);
+		goto out_free;
+	}
 	smmu->size = resource_size(res);
 
 	if (of_property_read_u32(dev->of_node, "#global-interrupts",
 				 &smmu->num_global_irqs)) {
 		dev_err(dev, "missing #global-interrupts property\n");
-		return -ENODEV;
+		err = -ENODEV;
+		goto out_free;
 	}
 
 	num_irqs = 0;
@@ -2169,14 +2458,16 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 	if (!smmu->num_context_irqs) {
 		dev_err(dev, "found %d interrupts but expected at least %d\n",
 			num_irqs, smmu->num_global_irqs + 1);
-		return -ENODEV;
+		err = -ENODEV;
+		goto out_free;
 	}
 
 	smmu->irqs = devm_kzalloc(dev, sizeof(*smmu->irqs) * num_irqs,
 				  GFP_KERNEL);
 	if (!smmu->irqs) {
 		dev_err(dev, "failed to allocate %d irqs\n", num_irqs);
-		return -ENOMEM;
+		err = -ENOMEM;
+		goto out_free;
 	}
 
 	for (i = 0; i < num_irqs; ++i) {
@@ -2184,7 +2475,8 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 
 		if (irq < 0) {
 			dev_err(dev, "failed to get irq index %d\n", i);
-			return -ENODEV;
+			err = -ENODEV;
+			goto out_free;
 		}
 		smmu->irqs[i] = irq;
 	}
@@ -2259,12 +2551,20 @@ out_put_masters:
 	for (node = rb_first(&smmu->masters); node; node = rb_next(node)) {
 		struct arm_smmu_master *master
 			= container_of(node, struct arm_smmu_master, node);
-		of_node_put(master->of_node);
+		kfree(master);
 	}
 
+out_free:
+	kfree(smmu->irqs);
+	if (!IS_ERR(smmu->base))
+		iounmap(smmu->base);
+	kfree(smmu);
+
 	return err;
 }
 
+/* Xen: We never remove SMMU */
+#if 0
 static int arm_smmu_device_remove(struct platform_device *pdev)
 {
 	int i;
@@ -2359,3 +2659,237 @@ module_exit(arm_smmu_exit);
 MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
 MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
 MODULE_LICENSE("GPL v2");
+#endif
+
+/* Xen specific function */
+
+static void arm_smmu_iotlb_flush_all(struct domain *d)
+{
+	struct arm_smmu_xen_domain *smmu_domain = domain_hvm_iommu(d)->arch.priv;
+	struct iommu_domain *cfg;
+
+	spin_lock(&smmu_domain->lock);
+	list_for_each_entry(cfg, &smmu_domain->contexts, list) {
+		/*
+		 * Only invalidate the context when SMMU is present.
+		 * This is because the context initialization is delayed
+		 * until a master has been added.
+		 */
+		if (unlikely(!ACCESS_ONCE(cfg->priv->smmu)))
+			continue;
+		arm_smmu_tlb_inv_context(cfg->priv);
+	}
+	spin_unlock(&smmu_domain->lock);
+}
+
+static void arm_smmu_iotlb_flush(struct domain *d, unsigned long gfn,
+                                 unsigned int page_count)
+{
+    /* ARM SMMU v1 doesn't have flush by VMA and VMID */
+    arm_smmu_iotlb_flush_all(d);
+}
+
+static int arm_smmu_assign_dev(struct domain *d, u8 devfn,
+			       struct device *dev)
+{
+	struct iommu_domain *domain;
+	struct arm_smmu_xen_domain *xen_domain;
+	int ret;
+
+	xen_domain = domain_hvm_iommu(d)->arch.priv;
+
+	if (!dev->archdata.iommu) {
+		dev->archdata.iommu = xzalloc(struct arm_smmu_xen_device);
+		if (!dev->archdata.iommu)
+			return -ENOMEM;
+	}
+
+	if (!dev_iommu_group(dev)) {
+		ret = arm_smmu_add_device(dev);
+		if (ret)
+			return ret;
+	}
+
+	/*
+	 * TODO: Share the context bank (i.e iommu_domain) when the device is
+	 * under the same SMMU as another device assigned to this domain.
+	 * Would it useful for PCI
+	 */
+	domain = xzalloc(struct iommu_domain);
+	if (!domain)
+		return -ENOMEM;
+
+	ret = arm_smmu_domain_init(domain);
+	if (ret)
+		goto err_dom_init;
+
+	domain->priv->cfg.domain = d;
+
+	ret = arm_smmu_attach_dev(domain, dev);
+	if (ret)
+		goto err_attach_dev;
+
+	spin_lock(&xen_domain->lock);
+	/* Chain the new context to the domain */
+	list_add(&domain->list, &xen_domain->contexts);
+	spin_unlock(&xen_domain->lock);
+
+	return 0;
+
+err_attach_dev:
+	arm_smmu_domain_destroy(domain);
+err_dom_init:
+	xfree(domain);
+
+	return ret;
+}
+
+static int arm_smmu_deassign_dev(struct domain *d, struct device *dev)
+{
+	struct iommu_domain *domain = dev_iommu_domain(dev);
+	struct arm_smmu_xen_domain *xen_domain;
+
+	xen_domain = domain_hvm_iommu(d)->arch.priv;
+
+	if (!domain || domain->priv->cfg.domain != d) {
+		dev_err(dev, " not attached to domain %d\n", d->domain_id);
+		return -ESRCH;
+	}
+
+	arm_smmu_detach_dev(domain, dev);
+
+	spin_lock(&xen_domain->lock);
+	list_del(&domain->list);
+	spin_unlock(&xen_domain->lock);
+
+	arm_smmu_domain_destroy(domain);
+	xfree(domain);
+
+	return 0;
+}
+
+static int arm_smmu_reassign_dev(struct domain *s, struct domain *t,
+				 u8 devfn,  struct device *dev)
+{
+	int ret = 0;
+
+	/* Don't allow remapping on other domain than hwdom */
+	if (t != hardware_domain)
+		return -EPERM;
+
+	if (t == s)
+		return 0;
+
+	ret = arm_smmu_deassign_dev(s, dev);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int arm_smmu_iommu_domain_init(struct domain *d)
+{
+	struct arm_smmu_xen_domain *xen_domain;
+
+	xen_domain = xzalloc(struct arm_smmu_xen_domain);
+	if ( !xen_domain )
+		return -ENOMEM;
+
+	spin_lock_init(&xen_domain->lock);
+	INIT_LIST_HEAD(&xen_domain->contexts);
+
+	domain_hvm_iommu(d)->arch.priv = xen_domain;
+
+	return 0;
+}
+
+static void __hwdom_init arm_smmu_iommu_hwdom_init(struct domain *d)
+{
+}
+
+static void arm_smmu_iommu_domain_teardown(struct domain *d)
+{
+	struct arm_smmu_xen_domain *xen_domain = domain_hvm_iommu(d)->arch.priv;
+
+	ASSERT(list_empty(&xen_domain->contexts));
+	xfree(xen_domain);
+}
+
+
+static int arm_smmu_map_page(struct domain *d, unsigned long gfn,
+			     unsigned long mfn, unsigned int flags)
+{
+	p2m_type_t t;
+
+	/*
+	 * Grant mappings can be used for DMA requests. The dev_bus_addr
+	 * returned by the hypercall is the MFN (not the IPA). For device
+	 * protected by an IOMMU, Xen needs to add a 1:1 mapping in the domain
+	 * p2m to allow DMA request to work.
+	 * This is only valid when the domain is directed mapped. Hence this
+	 * function should only be used by gnttab code with gfn == mfn.
+	 */
+	BUG_ON(!is_domain_direct_mapped(d));
+	BUG_ON(mfn != gfn);
+
+	/* We only support readable and writable flags */
+	if (!(flags & (IOMMUF_readable | IOMMUF_writable)))
+		return -EINVAL;
+
+	t = (flags & IOMMUF_writable) ? p2m_iommu_map_rw : p2m_iommu_map_ro;
+
+	/*
+	 * The function guest_physmap_add_entry replaces the current mapping
+	 * if there is already one...
+	 */
+	return guest_physmap_add_entry(d, gfn, mfn, 0, t);
+}
+
+static int arm_smmu_unmap_page(struct domain *d, unsigned long gfn)
+{
+	/*
+	 * This function should only be used by gnttab code when the domain
+	 * is direct mapped
+	 */
+	if ( !is_domain_direct_mapped(d) )
+		return -EINVAL;
+
+	guest_physmap_remove_page(d, gfn, gfn, 0);
+
+	return 0;
+}
+
+static const struct iommu_ops arm_smmu_iommu_ops = {
+    .init = arm_smmu_iommu_domain_init,
+    .hwdom_init = arm_smmu_iommu_hwdom_init,
+    .teardown = arm_smmu_iommu_domain_teardown,
+    .iotlb_flush = arm_smmu_iotlb_flush,
+    .iotlb_flush_all = arm_smmu_iotlb_flush_all,
+    .assign_device = arm_smmu_assign_dev,
+    .reassign_device = arm_smmu_reassign_dev,
+    .map_page = arm_smmu_map_page,
+    .unmap_page = arm_smmu_unmap_page,
+};
+
+static __init int arm_smmu_dt_init(struct dt_device_node *dev,
+				   const void *data)
+{
+	int rc;
+
+	/*
+	 * Even if the device can't be initialized, we don't want to
+	 * give the SMMU device to dom0.
+	 */
+	dt_device_set_used_by(dev, DOMID_XEN);
+
+	rc = arm_smmu_device_dt_probe(dev);
+	if ( !rc )
+		iommu_set_ops(&arm_smmu_iommu_ops);
+
+	return rc;
+}
+
+DT_DEVICE_START(smmu, "ARM SMMU", DEVICE_IOMMU)
+	.dt_match = arm_smmu_of_match,
+	.init = arm_smmu_dt_init,
+DT_DEVICE_END
-- 
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 Dec 16 20:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0yQt-0004lE-Md; Tue, 16 Dec 2014 20:09:23 +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 1Y0yQs-0004l3-5F
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:22 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	4C/AF-27584-17190945; Tue, 16 Dec 2014 20:09:21 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418760560!9589683!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3189 invoked from network); 16 Dec 2014 20:09:20 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 20:09:20 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so18362794wgh.32
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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:from:to:cc:subject:date:message-id:in-reply-to
	:references;
	bh=7iEo3OoQF0KRcxGWu63aBJw1GlHCIVIt1PUXCJmnBdc=;
	b=AVFKngnFe/00j0aegZo+2M4PkDNHabntidbiGss91JuC5wToJUihQzOdjywwejCtuD
	WS4jT0iW+fI24KcsOE+zPeAlExUJNrtbjJytJIL2lwt4fj0mqo311blwvE6g4AFoJcdY
	/zezbpeO/5sIi8Bk77ID+Ly1gBsU14JK+3qErnlaWIcCOnrW/KzwMf2ksCBUzDWQ1Mrv
	J+GuuZCvLtqnIH5GuidAp8nMtK+OscMCdkBi9RoYGZqgTRT+ODG7Z81OANQ8fHEUcmh8
	dHrocnOyWa19x7QqlC4/a41BDoI+v6qQqpsp8I82KhHC9+QxT7QMYxv86RAhV6nPA9XQ
	dWfQ==
X-Gm-Message-State: ALoCoQnMUCdbf4PV2MNHVHEdRvs/xXXIOsNjV4k48ojf1Qi3C/tbaBsN57skSpUuk4AuwABsppIq
X-Received: by 10.194.108.98 with SMTP id hj2mr65710399wjb.102.1418760560238; 
	Tue, 16 Dec 2014 12:09:20 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.18
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:19 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:43 +0000
Message-Id: <1418760534-18163-3-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: stefano.stabellini@citrix.com, manish.jaggi@caviumnetworks.com,
	Julien Grall <julien.grall@linaro.org>, tim@xen.org,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH for 4.6 02/13] xen/arm: vgic: Drop unecessary
	include asm/device.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

The header asm/device.h has been included in the vgic code during
splitting to support multiple version. But no code within those files
requires it.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/arch/arm/vgic-v2.c | 1 -
 xen/arch/arm/vgic-v3.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 1369f78..259d04f 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -26,7 +26,6 @@
 #include <xen/sched.h>
 
 #include <asm/current.h>
-#include <asm/device.h>
 
 #include <asm/mmio.h>
 #include <asm/gic.h>
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index ff99e50..da27605 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -27,7 +27,6 @@
 #include <xen/sched.h>
 #include <xen/sizes.h>
 #include <asm/current.h>
-#include <asm/device.h>
 #include <asm/mmio.h>
 #include <asm/gic_v3_defs.h>
 #include <asm/gic.h>
-- 
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 Dec 16 20:09:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0yQu-0004lh-KY; Tue, 16 Dec 2014 20:09: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 1Y0yQt-0004lD-TT
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:09:24 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	63/BF-27584-37190945; Tue, 16 Dec 2014 20:09:23 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418760562!13733923!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6578 invoked from network); 16 Dec 2014 20:09:22 -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;
	16 Dec 2014 20:09:22 -0000
Received: by mail-wg0-f42.google.com with SMTP id k14so2230477wgh.1
	for <xen-devel@lists.xenproject.org>;
	Tue, 16 Dec 2014 12:09: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=/enVbuj4T+LLzDE553Ymsf/7ET5WXHoqDbSYX+IORXQ=;
	b=Ngj3Rn13HfguWVC6+DHKJt56lwZiE5d4qCO13gjKIwDQrTgwh8NsPGMyWlOL0GFSL1
	CvdPtYw6Aq/JaWa9wIGg5YdQ3FYJbX4zQsf33RLGThyfQITD+e9LlE8CnMI5ZgoyKOCf
	AzLZZwqKjJmdPoJ/Trsz+8KsuchKSOUqgIlk29ffrl7mfDX4e25NI3ELjcw+jWSxipjv
	VxZRnmlPUHdpOvVrYYA+RzPUmiTlhndrZSTjQxdNp2BgSkY9d0jiI7RyGJJkehIfxXIA
	lTJUvWm5/gvdCM/zQy9wecCzPzIfw2MaqBEXKTTRwLqqEofl34ol2uOH4H8rATVghzjz
	5q+Q==
X-Gm-Message-State: ALoCoQlg3nwzdknXL6wxTMJhkkiUSIjv6hQTL4i9dZCTvkb3KNYzNdEEhUZPhQs13nlPsAHa9nsG
X-Received: by 10.194.89.3 with SMTP id bk3mr11484775wjb.92.1418760561921;
	Tue, 16 Dec 2014 12:09:21 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id b10sm3382705wiw.9.2014.12.16.12.09.20
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 16 Dec 2014 12:09:21 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Tue, 16 Dec 2014 20:08:44 +0000
Message-Id: <1418760534-18163-4-git-send-email-julien.grall@linaro.org>
X-Mailer: git-send-email 2.1.3
In-Reply-To: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This macro can be used in drivers imported from Linux.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Keir Fraser <keir@xen.org>
---
 xen/include/xen/compiler.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index 4b3472d..57eb7a6 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -90,4 +90,18 @@
     __asm__ ("" : "=r"(__ptr) : "0"(ptr));      \
     (typeof(ptr)) (__ptr + (off)); })
 
+/*
+ * Prevent the compiler from merging or refetching accesses.  The compiler
+ * is also forbidden from reordering successive instances of ACCESS_ONCE(),
+ * but only when the compiler is aware of some particular ordering.  One way
+ * to make the compiler aware of ordering is to put the two invocations of
+ * ACCESS_ONCE() in different C statements.
+ *
+ * This macro does absolutely -nothing- to prevent the CPU from reordering,
+ * merging, or refetching absolutely anything at any time.  Its main intended
+ * use is to mediate communication between process-level code and irq/NMI
+ * handlers, all running on the same CPU.
+ */
+#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
+
 #endif /* __LINUX_COMPILER_H */
-- 
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 Dec 16 20:22:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0ydU-00077z-H8; Tue, 16 Dec 2014 20:22:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Y0ydS-00076M-Nt
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:22:22 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	C3/B0-03145-E7490945; Tue, 16 Dec 2014 20:22:22 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418761340!15458152!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 25505 invoked from network); 16 Dec 2014 20:22:21 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-7.tower-27.messagelabs.com with SMTP;
	16 Dec 2014 20:22:21 -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 4BBD158C4BF;
	Tue, 16 Dec 2014 12:22:18 -0800 (PST)
Date: Tue, 16 Dec 2014 15:22:17 -0500 (EST)
Message-Id: <20141216.152217.15156261870362937.davem@davemloft.net>
To: david.vrabel@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1418756386-6940-1-git-send-email-david.vrabel@citrix.com>
References: <1418756386-6940-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, 16 Dec 2014 12:22:19 -0800 (PST)
Cc: netdev@vger.kernel.org, boris.ostrovsky@oracle.com, edumazet@google.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net] xen-netfront: use napi_complete()
 correctly to prevent Rx stalling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Tue, 16 Dec 2014 18:59:46 +0000

> After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
> masking in NAPI) the napi instance is removed from the per-cpu list
> prior to calling the n->poll(), and is only requeued if all of the
> budget was used.  This inadvertently broke netfront because netfront
> does not use NAPI correctly.
> 
> If netfront had not used all of its budget it would do a final check
> for any Rx responses and avoid calling napi_complete() if there were
> more responses.  It would still return under budget so it would never
> be rescheduled.  The final check would also not re-enable the Rx
> interrupt.
> 
> Additionally, xenvif_poll() would also call napi_complete() /after/
> enabling the interrupt.  This resulted in a race between the
> napi_complete() and the napi_schedule() in the interrupt handler.  The
> use of local_irq_save/restore() avoided by race iff the handler is
> running on the same CPU but not if it was running on a different CPU.
> 
> Fix both of these by always calling napi_compete() if the budget was
> not all used, and then calling napi_schedule() if the final checks
> says there's more work.
> 
> 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 Tue Dec 16 20:22:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0ydU-00077z-H8; Tue, 16 Dec 2014 20:22:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Y0ydS-00076M-Nt
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:22:22 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	C3/B0-03145-E7490945; Tue, 16 Dec 2014 20:22:22 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418761340!15458152!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 25505 invoked from network); 16 Dec 2014 20:22:21 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-7.tower-27.messagelabs.com with SMTP;
	16 Dec 2014 20:22:21 -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 4BBD158C4BF;
	Tue, 16 Dec 2014 12:22:18 -0800 (PST)
Date: Tue, 16 Dec 2014 15:22:17 -0500 (EST)
Message-Id: <20141216.152217.15156261870362937.davem@davemloft.net>
To: david.vrabel@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1418756386-6940-1-git-send-email-david.vrabel@citrix.com>
References: <1418756386-6940-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, 16 Dec 2014 12:22:19 -0800 (PST)
Cc: netdev@vger.kernel.org, boris.ostrovsky@oracle.com, edumazet@google.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net] xen-netfront: use napi_complete()
 correctly to prevent Rx stalling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Tue, 16 Dec 2014 18:59:46 +0000

> After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
> masking in NAPI) the napi instance is removed from the per-cpu list
> prior to calling the n->poll(), and is only requeued if all of the
> budget was used.  This inadvertently broke netfront because netfront
> does not use NAPI correctly.
> 
> If netfront had not used all of its budget it would do a final check
> for any Rx responses and avoid calling napi_complete() if there were
> more responses.  It would still return under budget so it would never
> be rescheduled.  The final check would also not re-enable the Rx
> interrupt.
> 
> Additionally, xenvif_poll() would also call napi_complete() /after/
> enabling the interrupt.  This resulted in a race between the
> napi_complete() and the napi_schedule() in the interrupt handler.  The
> use of local_irq_save/restore() avoided by race iff the handler is
> running on the same CPU but not if it was running on a different CPU.
> 
> Fix both of these by always calling napi_compete() if the budget was
> not all used, and then calling napi_schedule() if the final checks
> says there's more work.
> 
> 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 Tue Dec 16 20:28:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0yjK-0007Hy-I2; Tue, 16 Dec 2014 20:28:26 +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 1Y0yjJ-0007Ht-Cp
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 20:28:25 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	98/BA-25547-8E590945; Tue, 16 Dec 2014 20:28:24 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418761702!13703846!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 6105 invoked from network); 16 Dec 2014 20:28:23 -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;
	16 Dec 2014 20:28:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205085332"
Message-ID: <549095E3.30202@citrix.com>
Date: Tue, 16 Dec 2014 20:28: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: =?UTF-8?B?TWloYWkgRG9uyJt1?= <mdontu@bitdefender.com>,
	<xen-devel@lists.xen.org>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
In-Reply-To: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, keir@xen.org, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTYvMTIvMTQgMTk6MzMsIE1paGFpIERvbsibdSB3cm90ZToKPiBJbXBsZW1lbnRlZCB4bWVt
X3Bvb2xfY2hlY2soKSwgeG1lbV9wb29sX2NoZWNrX2xvY2tlZCgpIGFuZAo+IHhtZW1fcG9vbF9j
aGVja191bmxvY2tlZCgpIHRvIHZlcml0eSB0aGUgaW50ZWdyaXR5IG9mIHRoZSBUTFNGIG1hdHJp
eC4KPgo+IFNpZ25lZC1vZmYtYnk6IE1paGFpIERvbsibdSA8bWRvbnR1QGJpdGRlZmVuZGVyLmNv
bT4KPgo+IC0tLQo+IENoYW5nZXMgc2luY2UgdjM6Cj4gIC0gdHJ5IGhhcmRlciB0byByZXNwZWN0
IHRoZSA4MCBjb2x1bW4gbGltaXQKPiAgLSB1c2UgJ3Vuc2lnbmVkIGludCcgaW5zdGVhZCBvZiAn
aW50JyB3aGVyZSBwb3NzaWJsZQo+ICAtIG1hZGUgdGhlIGxvZ2dlZCBtZXNzYWdlcyBldmVuIHNo
b3J0ZXIKPiAgLSBkcm9wcGVkIHRoZSB1c2Ugb2YgZ290byAoZGlkbid0IHJlYWxseSBtYWtlIHNl
bnNlKQo+Cj4gQ2hhbmdlcyBzaW5jZSB2MjoKPiAgLSBwcmludCB0aGUgbmFtZSBvZiB0aGUgY29y
cnVwdGVkIHBvb2wKPiAgLSBhZGp1c3RlZCB0aGUgbWVzc2FnZXMgdG8gYmV0dGVyIGZpdCB3aXRo
aW4gODAgY29sdW1ucwo+ICAtIG1pbm9yIHN0eWxlIGNoYW5nZSAoYSA/IGEgOiBiIC0+IGEgPzog
YikKPgo+IENoYW5nZXMgc2luY2UgdjE6Cj4gIC0gZml4ZWQgdGhlIGNvZGluZ3N0eWxlCj4gIC0g
c3dhcGVkIF9sb2NrZWQvX3VubG9ja2VkIG5hbWluZwo+ICAtIHJld29ya2VkIF9feG1lbV9wb29s
X2NoZWNrX2xvY2tlZCgpIGEgYml0Cj4gIC0gdXNlZCBib29sX3Qgd2hlcmUgYXBwcm9wcmlhdGUK
PiAgLSBtYWRlIHhtZW1fcG9vbF9jaGVjaygpIHRha2UgYSBwb29sIGFyZ3VtZW50IHdoaWNoIGNh
biBiZSBOVUxMCj4gLS0tCj4gIHhlbi9jb21tb24veG1hbGxvY190bHNmLmMgfCAxMjEgKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQo+ICB4ZW4vaW5jbHVkZS94
ZW4veG1hbGxvYy5oIHwgICA3ICsrKwo+ICAyIGZpbGVzIGNoYW5nZWQsIDEyNiBpbnNlcnRpb25z
KCspLCAyIGRlbGV0aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL3hlbi9jb21tb24veG1hbGxvY190
bHNmLmMgYi94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jCj4gaW5kZXggYTU3NjljOS4uZWNhNGYx
YyAxMDA2NDQKPiAtLS0gYS94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jCj4gKysrIGIveGVuL2Nv
bW1vbi94bWFsbG9jX3Rsc2YuYwo+IEBAIC0xMjAsOSArMTIwLDEyMiBAQCBzdHJ1Y3QgeG1lbV9w
b29sIHsKPiAgICAgIGNoYXIgbmFtZVtNQVhfUE9PTF9OQU1FX0xFTl07Cj4gIH07Cj4gIAo+ICtz
dGF0aWMgc3RydWN0IHhtZW1fcG9vbCAqeGVucG9vbDsKPiArCj4gK3N0YXRpYyBpbmxpbmUgdm9p
ZCBNQVBQSU5HX0lOU0VSVCh1bnNpZ25lZCBsb25nIHIsIGludCAqZmwsIGludCAqc2wpOwo+ICsK
PiAgLyoKPiAgICogSGVscGluZyBmdW5jdGlvbnMKPiAgICovCj4gKyNpZm5kZWYgTkRFQlVHCj4g
K3N0YXRpYyBib29sX3QgeG1lbV9wb29sX2NoZWNrX3NpemUoY29uc3Qgc3RydWN0IHhtZW1fcG9v
bCAqcG9vbCwKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgZmwsIGlu
dCBzbCkKPiArewo+ICsgICAgY29uc3Qgc3RydWN0IGJoZHIgKmIgPSBwb29sLT5tYXRyaXhbZmxd
W3NsXTsKPiArCj4gKyAgICB3aGlsZSAoIGIgKQo+ICsgICAgewo+ICsgICAgICAgIGludCBfX2Zs
Owo+ICsgICAgICAgIGludCBfX3NsOwo+ICsKPiArICAgICAgICBNQVBQSU5HX0lOU0VSVChiLT5z
aXplLCAmX19mbCwgJl9fc2wpOwo+ICsgICAgICAgIGlmICggX19mbCAhPSBmbCB8fCBfX3NsICE9
IHNsICkKPiArICAgICAgICB7Cj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSCj4gKyAg
ICAgICAgICAgICAgICAgICAieG1lbV9wb29sOiAlczogbWlzcGxhY2VkIGJsb2NrICVwOiV1ICh7
JWQsJWR9IC0+IHslZCwlZH0pXG4iLAoKSXMgaXQgbGlhYmxlIHRvIGdldCBjb25mdXNpbmcgd2l0
aCBhIGhleCBudW1iZXIgYW5kIGEgZGVjaW1hbCBudW1iZXIKY29tYmluZWQgd2l0aCBqdXN0IGEg
Y29sb24/CgpJcyBiIGV2ZW4gdXNlZnVsPyAgWW91IGhhdmUgdGhlIHBvb2wgbmFtZSwgaW5kaWNp
ZXMgYW5kIHNpemUgd2hpY2ggc2VlbQp0byBiZSB0aGUgc2FsaWVudCBpbmZvcm1hdGlvbi4KCj4g
KyAgICAgICAgICAgICAgICAgICBwb29sLT5uYW1lLCBiLCBiLT5zaXplLCBmbCwgc2wsIF9fZmws
IF9fc2wpOwo+ICsgICAgICAgICAgICByZXR1cm4gMDsKPiArICAgICAgICB9Cj4gKyAgICAgICAg
YiA9IGItPnB0ci5mcmVlX3B0ci5uZXh0Owo+ICsgICAgfQo+ICsgICAgcmV0dXJuIDE7Cj4gK30K
PiArCj4gKy8qCj4gKyAqIFRoaXMgZnVuY3Rpb24gbXVzdCBiZSBjYWxsZWQgZnJvbSBhIGNvbnRl
eHQgd2hlcmUgcG9vbC0+bG9jayBpcwo+ICsgKiBhbHJlYWR5IGFjcXVpcmVkLgo+ICsgKgo+ICsg
KiBSZXR1cm5zIHRydWUgaWYgdGhlIHBvb2wgaGFzIGJlZW4gY29ycnVwdGVkLCBmYWxzZSBvdGhl
cndpc2UKPiArICovCj4gKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKSBcCj4g
KyAgICBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoX19GSUxFX18sIF9fTElORV9fLCBwb29sKQo+
ICtzdGF0aWMgYm9vbF90IF9feG1lbV9wb29sX2NoZWNrX2xvY2tlZChjb25zdCBjaGFyICpmaWxl
LCBpbnQgbGluZSwKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29u
c3Qgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiArewo+ICsgICAgdW5zaWduZWQgaW50IGk7Cj4g
KyAgICBzdGF0aWMgYm9vbF90IG9uY2UgPSAxOwoKV2hhdCBpcyB0aGlzIHN0YXRpYyBkb2luZz8g
IFN1cmVseSBjb3JydXB0aW9uIGNvcnJ1cHRpb24gaW4gb25lIHBvb2wgaGFzCm5vIGVmZmVjdCBv
biBjb3JydXB0aW9uIGluIGEgc2VwYXJhdGUgcG9vbCAob3RoZXIgdGhhbiB0aGUgdXN1YWwgc2lk
ZQplZmZlY3RzIG9mIGdlbmVyYWwgbWVtb3J5IGNvcnJ1cHRpb24sIHdoaWNoIHRlbmQgdG8gYmUg
YmFkKS4KCkl0IGxvb2tzIGFzIGlmIGl0IHdhbnRzIHRvIGJlIGFuIGV4dHJhIGZpZWxkIGluIGFu
IHhtZW1fcG9vbC4KCj4gKwo+ICsgICAgaWYgKCAhb25jZSApCj4gKyAgICAgICAgcmV0dXJuIDE7
Cj4gKyAgICBmb3IgKCBpID0gMDsgaSA8IFJFQUxfRkxJOyBpKysgKQo+ICsgICAgewo+ICsgICAg
ICAgIGludCBmbCA9IChwb29sLT5mbF9iaXRtYXAgJiAoMSA8PCBpKSkgPyBpIDogLTE7Cj4gKwo+
ICsgICAgICAgIGlmICggZmwgPj0gMCApCj4gKyAgICAgICAgewo+ICsgICAgICAgICAgICB1bnNp
Z25lZCBpbnQgajsKPiArCj4gKyAgICAgICAgICAgIGlmICggIXBvb2wtPnNsX2JpdG1hcFtmbF0g
KQo+ICsgICAgICAgICAgICB7Cj4gKyAgICAgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUgo+
ICsgICAgICAgICAgICAgICAgICAgICAgICJ4bWVtX3Bvb2w6ICVzOiBUTFNGIGJpdG1hcCBjb3Jy
dXB0ICghZW1wdHkgRkwsIGVtcHR5IFNMKVxuIiwKPiArICAgICAgICAgICAgICAgICAgICAgICBw
b29sLT5uYW1lKTsKPiArICAgICAgICAgICAgICAgIF9fd2FybihmaWxlLCBsaW5lKTsKClRoZSBf
X3dhcm4oKXMgaGVyZSB3aWxsIGN1cnJlbnRseSBkbyBhIGZ1bGwgcmVnaXN0ZXIgZHVtcCwgYXMg
d2VsbCBhcwpzdGFjayBkdW1wIGFuZCBzdGFjayB0cmFjZS4gIEl0IG9jY3VycyB0byBtZSB0aGF0
IG9ubHkgdGhlIHN0YWNrIHRyYWNlCml0c2VsZiBpcyB1c2VmdWwgYXQgdGhpcyBwb2ludC4KCl9f
YnVnIGFuZCBfX3dhcm4oKSBhcmUgY3VycmVudGx5IHVudXNlZCAoSSBhbSBzdHJ1Z2dsaW5nIHRv
IHdvcmsgb3V0CmV4YWN0bHkgd2hlbiB0aGV5IHdlcmUgb3JwaGFuZWQ7IHRoZXkgZG8gbm90IGZv
cm0gcGFydCBvZiByZWd1bGFyCkJVRygpL1dBUk4oKSBvcGVyYXRpb25zLCB3aGljaCBhcmUgaGFu
ZGxlZCBpbiBkb19pbnZhbGlkX29wKCkpLiAgVGhleQphcmUgYWxzbyBub3QgZmFudGFzdGljYWxs
eSB1c2VmdWwgYXMgdGhleSB3aWxsIGFsd2F5cyBpZGVudGlmeQp0aGVtc2VsdmVzIGluIHRoZSBw
cmludGVkIGluZm9ybWF0aW9uLCBub3QgdGhlaXIgY2FsbGVyLiAgSSBzdXNwZWN0IHRoZXkKY2Fu
IGp1c3QgYmUgZHJvcHBlZCBjb21wbGV0ZWx5LgoKSSBzdXNwZWN0IHlvdSBhbHNvIHdvdWxkIGJl
IGJldHRlciwgYW5kIGNlcnRhaW5seSBtb3JlIGJyaWVmLCB3aXRoCiJydW5faW5fZXhjZXB0aW9u
X2hhbmRsZXIoc2hvd19zdGFjaykiIGluc3RlYWQsIHdoaWNoIHdpbGwganVzdCBwcmludCBhCnN0
YWNrIHRyYWNlLCBidXQgbm90aGluZyBtb3JlLgoKPiArICAgICAgICAgICAgICAgIG9uY2UgPSAw
Owo+ICsgICAgICAgICAgICAgICAgYnJlYWs7Cj4gKyAgICAgICAgICAgIH0KPiArICAgICAgICAg
ICAgZm9yICggaiA9IDA7IGogPCBNQVhfU0xJOyBqKysgKQo+ICsgICAgICAgICAgICB7Cj4gKyAg
ICAgICAgICAgICAgICBpbnQgc2wgPSAocG9vbC0+c2xfYml0bWFwW2ZsXSAmICgxIDw8IGopKSA/
IGogOiAtMTsKPiArCj4gKyAgICAgICAgICAgICAgICBpZiAoIHNsIDwgMCApCj4gKyAgICAgICAg
ICAgICAgICAgICAgY29udGludWU7Cj4gKyAgICAgICAgICAgICAgICBpZiAoICFwb29sLT5tYXRy
aXhbZmxdW3NsXSApCj4gKyAgICAgICAgICAgICAgICB7Cj4gKyAgICAgICAgICAgICAgICAgICAg
cHJpbnRrKFhFTkxPR19FUlIKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgInhtZW1fcG9v
bDogJXM6IFRMU0YgYml0bWFwIGNvcnJ1cHQgKCFtYXRyaXhbJWRdWyVkXSlcbiIsCj4gKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHBvb2wtPm5hbWUsIGZsLCBzbCk7Cj4gKyAgICAgICAgICAg
ICAgICAgICAgX193YXJuKGZpbGUsIGxpbmUpOwo+ICsgICAgICAgICAgICAgICAgICAgIG9uY2Ug
PSAwOwo+ICsgICAgICAgICAgICAgICAgICAgIGJyZWFrOwo+ICsgICAgICAgICAgICAgICAgfQo+
ICsgICAgICAgICAgICAgICAgaWYgKCAheG1lbV9wb29sX2NoZWNrX3NpemUocG9vbCwgZmwsIHNs
KSApCj4gKyAgICAgICAgICAgICAgICB7Cj4gKyAgICAgICAgICAgICAgICAgICAgcHJpbnRrKFhF
TkxPR19FUlIgInhtZW1fcG9vbDogJXM6IFRMU0YgY2h1bmsgbWF0cml4IGNvcnJ1cHRcbiIsCj4g
KyAgICAgICAgICAgICAgICAgICAgICAgICAgIHBvb2wtPm5hbWUpOwo+ICsgICAgICAgICAgICAg
ICAgICAgIF9fd2FybihmaWxlLCBsaW5lKTsKPiArICAgICAgICAgICAgICAgICAgICBvbmNlID0g
MDsKPiArICAgICAgICAgICAgICAgICAgICBicmVhazsKPiArICAgICAgICAgICAgICAgIH0KPiAr
ICAgICAgICAgICAgfQo+ICsgICAgICAgICAgICBpZiAoICFvbmNlICkKPiArICAgICAgICAgICAg
ICAgIGJyZWFrOwo+ICsgICAgICAgIH0KPiArICAgIH0KPiArICAgIHJldHVybiAhb25jZTsKPiAr
fQo+ICsKPiArI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQocG9vbCkgXAo+ICsgICAg
X194bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoX19GSUxFX18sIF9fTElORV9fLCBwb29sKQo+ICtz
dGF0aWMgYm9vbF90IF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKGNvbnN0IGNoYXIgKmZpbGUs
IGludCBsaW5lLAo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0
cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gK3sKPiArICAgIGJvb2xfdCBvb3BzOwo+ICsKPiArICAg
IHNwaW5fbG9jaygmcG9vbC0+bG9jayk7Cj4gKyAgICBvb3BzID0gX194bWVtX3Bvb2xfY2hlY2tf
bG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wpOwo+ICsgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2sp
Owo+ICsgICAgcmV0dXJuIG9vcHM7Cj4gK30KPiArCj4gK2Jvb2xfdCBfX3htZW1fcG9vbF9jaGVj
ayhjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAr
ewo+ICsgICAgcmV0dXJuIF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKGZpbGUsIGxpbmUsIHBv
b2wgPzogeGVucG9vbCk7CgpXaHkgc2hvdWxkIGEgTlVMTCBwb29sIGJlIHRvbGVyYXRlZCBoZXJl
PyAgVGhpcyBpcyBkZWJ1ZyBjb2RlIG9ubHksIHNvCndlIGNhbiByZXF1aXJlIGFuZCB0cnVzdCB0
aGF0IHdlIGFyZSBjYWxsZWQgYXBwcm9wcmlhdGVseS4KCj4gK30KPiArI2Vsc2UKPiArI2RlZmlu
ZSB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpICgodm9pZCkocG9vbCkpCj4gKyNkZWZpbmUg
eG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKHBvb2wpICgodm9pZCkocG9vbCkpCj4gKyNlbmRpZgo+
ICAKPiAgLyoqCj4gICAqIFJldHVybnMgaW5kZXhlcyAoZmwsIHNsKSBvZiB0aGUgbGlzdCB1c2Vk
IHRvIHNlcnZlIHJlcXVlc3Qgb2Ygc2l6ZSByCj4gQEAgLTM4MSw2ICs0OTQsOCBAQCB2b2lkICp4
bWVtX3Bvb2xfYWxsb2ModW5zaWduZWQgbG9uZyBzaXplLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29s
KQo+ICAgICAgaW50IGZsLCBzbDsKPiAgICAgIHVuc2lnbmVkIGxvbmcgdG1wX3NpemU7Cj4gIAo+
ICsgICAgeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKHBvb2wpOwo+ICsKPiAgICAgIGlmICggcG9v
bC0+aW5pdF9yZWdpb24gPT0gTlVMTCApCj4gICAgICB7Cj4gICAgICAgICAgaWYgKCAocmVnaW9u
ID0gcG9vbC0+Z2V0X21lbShwb29sLT5pbml0X3NpemUpKSA9PSBOVUxMICkKPiBAQCAtNDQyLDEx
ICs1NTcsMTMgQEAgdm9pZCAqeG1lbV9wb29sX2FsbG9jKHVuc2lnbmVkIGxvbmcgc2l6ZSwgc3Ry
dWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAgCj4gICAgICBwb29sLT51c2VkX3NpemUgKz0gKGItPnNp
emUgJiBCTE9DS19TSVpFX01BU0spICsgQkhEUl9PVkVSSEVBRDsKPiAgCj4gKyAgICB4bWVtX3Bv
b2xfY2hlY2tfbG9ja2VkKHBvb2wpOwo+ICAgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwo+
ICAgICAgcmV0dXJuICh2b2lkICopYi0+cHRyLmJ1ZmZlcjsKPiAgCj4gICAgICAvKiBGYWlsZWQg
YWxsb2MgKi8KPiAgIG91dF9sb2NrZWQ6Cj4gKyAgICB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBv
b2wpOwo+ICAgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwo+ICAKPiAgIG91dDoKPiBAQCAt
NDY0LDYgKzU4MSw3IEBAIHZvaWQgeG1lbV9wb29sX2ZyZWUodm9pZCAqcHRyLCBzdHJ1Y3QgeG1l
bV9wb29sICpwb29sKQo+ICAgICAgYiA9IChzdHJ1Y3QgYmhkciAqKSgoY2hhciAqKSBwdHIgLSBC
SERSX09WRVJIRUFEKTsKPiAgCj4gICAgICBzcGluX2xvY2soJnBvb2wtPmxvY2spOwo+ICsgICAg
eG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKTsKPiAgICAgIGItPnNpemUgfD0gRlJFRV9CTE9D
SzsKPiAgICAgIHBvb2wtPnVzZWRfc2l6ZSAtPSAoYi0+c2l6ZSAmIEJMT0NLX1NJWkVfTUFTSykg
KyBCSERSX09WRVJIRUFEOwo+ICAgICAgYi0+cHRyLmZyZWVfcHRyID0gKHN0cnVjdCBmcmVlX3B0
cikgeyBOVUxMLCBOVUxMfTsKPiBAQCAtNTAwLDYgKzYxOCw3IEBAIHZvaWQgeG1lbV9wb29sX2Zy
ZWUodm9pZCAqcHRyLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ICAgICAgdG1wX2ItPnNpemUg
fD0gUFJFVl9GUkVFOwo+ICAgICAgdG1wX2ItPnByZXZfaGRyID0gYjsKPiAgIG91dDoKPiArICAg
IHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCk7Cj4gICAgICBzcGluX3VubG9jaygmcG9vbC0+
bG9jayk7Cj4gIH0KPiAgCj4gQEAgLTUxMiw4ICs2MzEsNiBAQCBpbnQgeG1lbV9wb29sX21heGFs
bG9jKHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gICAqIEdsdWUgZm9yIHhtYWxsb2MoKS4KPiAg
ICovCj4gIAo+IC1zdGF0aWMgc3RydWN0IHhtZW1fcG9vbCAqeGVucG9vbDsKPiAtCj4gIHN0YXRp
YyB2b2lkICp4bWFsbG9jX3Bvb2xfZ2V0KHVuc2lnbmVkIGxvbmcgc2l6ZSkKPiAgewo+ICAgICAg
QVNTRVJUKHNpemUgPT0gUEFHRV9TSVpFKTsKPiBkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVu
L3htYWxsb2MuaCBiL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKPiBpbmRleCAyNGE5OWFjLi5h
ZDQ4OTMwIDEwMDY0NAo+IC0tLSBhL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKPiArKysgYi94
ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCj4gQEAgLTEyMyw0ICsxMjMsMTEgQEAgdW5zaWduZWQg
bG9uZyB4bWVtX3Bvb2xfZ2V0X3VzZWRfc2l6ZShzdHJ1Y3QgeG1lbV9wb29sICpwb29sKTsKPiAg
ICovCj4gIHVuc2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF90b3RhbF9zaXplKHN0cnVjdCB4bWVt
X3Bvb2wgKnBvb2wpOwo+ICAKPiArI2lmbmRlZiBOREVCVUcKPiArI2RlZmluZSB4bWVtX3Bvb2xf
Y2hlY2socG9vbCkgX194bWVtX3Bvb2xfY2hlY2soX19GSUxFX18sIF9fTElORV9fLCBwb29sKQo+
ICtib29sX3QgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsIHN0
cnVjdCB4bWVtX3Bvb2wgKnBvb2wpOwo+ICsjZWxzZQo+ICsjZGVmaW5lIHhtZW1fcG9vbF9jaGVj
ayhwb29sKSAoKHZvaWQpMCkKClRoaXMgbmVlZHMgdG8gYmUgKCh2b2lkKShwb29sKSkgdG8gZXZh
bHVhdGUgdGhlIHBvdGVudGlhbCBzaWRlIGVmZmVjdHMuIApIb3dldmVyLCBJIHRoaW5rIHlvdSBu
ZWVkIHRvIGNvbmRpdGlvbmFsbHkgY2hhbmdlIF9feG1lbV9wb29sX2NoZWNrKCkKYW5kIG1vdmUg
I2RlZmluZSB4bWVtX3Bvb2xfY2hlY2sgb3V0c2lkZSB0aGUgY29uZGl0aW9uYWwsIHRvIGNvdmVy
CmZ1dHVyZSBjb25zdW1lcnMgd2hvIG1pZ2h0IGNob29zZSB0byBjYWxsIF9feG1lbV9wb29sX2No
ZWNrKCkgZGlyZWN0bHkuCgoKV2hhdCBhcmUgdGhlIG92ZXJoZWFkcyBvZiBwb29sIGNvbnNpc3Rl
bmN5IGNoZWNraW5nPyAgSXQgbG9va3MgdG8gYmUKbW9kZXJhdGVseSBoaWdoLCBnaXZlbiBhIGZ1
bGwgaW5zcGVjdGlvbiBvZiB0aGUgbWF0cml4IG9uIGVhY2gKYWxsb2NhdGlvbiBhbmQgZnJlZS4g
IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGhhdmUgb25lIGVhc3ktdG8tYWx0ZXIKY29tcGlsZSB0
aW1lIGtub2Igc28gdGhlIGRlZmF1bHQgY2FuIGJlIG92ZXJyaWRkZW4gaW4gYSBzaW5nbGUgbG9j
YXRpb24/CgpQZXJoYXBzIHNvbWV0aGluZyBsaWtlOgoKI2lmbmRlZiBOREVCVUcKI2RlZmluZSBY
TUVNX1BPT0xfQ0hFQ0tTCiNlbmRpZgoKI2lmZGVmIFhNRU1fUE9PTF9DSEVDS1MKLi4uCiNlbHNl
Ci4uLgojZW5kaWYKCn5BbmRyZXcKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Dec 16 20:28:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0yjK-0007Hy-I2; Tue, 16 Dec 2014 20:28:26 +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 1Y0yjJ-0007Ht-Cp
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 20:28:25 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	98/BA-25547-8E590945; Tue, 16 Dec 2014 20:28:24 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418761702!13703846!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 6105 invoked from network); 16 Dec 2014 20:28:23 -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;
	16 Dec 2014 20:28:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205085332"
Message-ID: <549095E3.30202@citrix.com>
Date: Tue, 16 Dec 2014 20:28: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: =?UTF-8?B?TWloYWkgRG9uyJt1?= <mdontu@bitdefender.com>,
	<xen-devel@lists.xen.org>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
In-Reply-To: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, keir@xen.org, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTYvMTIvMTQgMTk6MzMsIE1paGFpIERvbsibdSB3cm90ZToKPiBJbXBsZW1lbnRlZCB4bWVt
X3Bvb2xfY2hlY2soKSwgeG1lbV9wb29sX2NoZWNrX2xvY2tlZCgpIGFuZAo+IHhtZW1fcG9vbF9j
aGVja191bmxvY2tlZCgpIHRvIHZlcml0eSB0aGUgaW50ZWdyaXR5IG9mIHRoZSBUTFNGIG1hdHJp
eC4KPgo+IFNpZ25lZC1vZmYtYnk6IE1paGFpIERvbsibdSA8bWRvbnR1QGJpdGRlZmVuZGVyLmNv
bT4KPgo+IC0tLQo+IENoYW5nZXMgc2luY2UgdjM6Cj4gIC0gdHJ5IGhhcmRlciB0byByZXNwZWN0
IHRoZSA4MCBjb2x1bW4gbGltaXQKPiAgLSB1c2UgJ3Vuc2lnbmVkIGludCcgaW5zdGVhZCBvZiAn
aW50JyB3aGVyZSBwb3NzaWJsZQo+ICAtIG1hZGUgdGhlIGxvZ2dlZCBtZXNzYWdlcyBldmVuIHNo
b3J0ZXIKPiAgLSBkcm9wcGVkIHRoZSB1c2Ugb2YgZ290byAoZGlkbid0IHJlYWxseSBtYWtlIHNl
bnNlKQo+Cj4gQ2hhbmdlcyBzaW5jZSB2MjoKPiAgLSBwcmludCB0aGUgbmFtZSBvZiB0aGUgY29y
cnVwdGVkIHBvb2wKPiAgLSBhZGp1c3RlZCB0aGUgbWVzc2FnZXMgdG8gYmV0dGVyIGZpdCB3aXRo
aW4gODAgY29sdW1ucwo+ICAtIG1pbm9yIHN0eWxlIGNoYW5nZSAoYSA/IGEgOiBiIC0+IGEgPzog
YikKPgo+IENoYW5nZXMgc2luY2UgdjE6Cj4gIC0gZml4ZWQgdGhlIGNvZGluZ3N0eWxlCj4gIC0g
c3dhcGVkIF9sb2NrZWQvX3VubG9ja2VkIG5hbWluZwo+ICAtIHJld29ya2VkIF9feG1lbV9wb29s
X2NoZWNrX2xvY2tlZCgpIGEgYml0Cj4gIC0gdXNlZCBib29sX3Qgd2hlcmUgYXBwcm9wcmlhdGUK
PiAgLSBtYWRlIHhtZW1fcG9vbF9jaGVjaygpIHRha2UgYSBwb29sIGFyZ3VtZW50IHdoaWNoIGNh
biBiZSBOVUxMCj4gLS0tCj4gIHhlbi9jb21tb24veG1hbGxvY190bHNmLmMgfCAxMjEgKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQo+ICB4ZW4vaW5jbHVkZS94
ZW4veG1hbGxvYy5oIHwgICA3ICsrKwo+ICAyIGZpbGVzIGNoYW5nZWQsIDEyNiBpbnNlcnRpb25z
KCspLCAyIGRlbGV0aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL3hlbi9jb21tb24veG1hbGxvY190
bHNmLmMgYi94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jCj4gaW5kZXggYTU3NjljOS4uZWNhNGYx
YyAxMDA2NDQKPiAtLS0gYS94ZW4vY29tbW9uL3htYWxsb2NfdGxzZi5jCj4gKysrIGIveGVuL2Nv
bW1vbi94bWFsbG9jX3Rsc2YuYwo+IEBAIC0xMjAsOSArMTIwLDEyMiBAQCBzdHJ1Y3QgeG1lbV9w
b29sIHsKPiAgICAgIGNoYXIgbmFtZVtNQVhfUE9PTF9OQU1FX0xFTl07Cj4gIH07Cj4gIAo+ICtz
dGF0aWMgc3RydWN0IHhtZW1fcG9vbCAqeGVucG9vbDsKPiArCj4gK3N0YXRpYyBpbmxpbmUgdm9p
ZCBNQVBQSU5HX0lOU0VSVCh1bnNpZ25lZCBsb25nIHIsIGludCAqZmwsIGludCAqc2wpOwo+ICsK
PiAgLyoKPiAgICogSGVscGluZyBmdW5jdGlvbnMKPiAgICovCj4gKyNpZm5kZWYgTkRFQlVHCj4g
K3N0YXRpYyBib29sX3QgeG1lbV9wb29sX2NoZWNrX3NpemUoY29uc3Qgc3RydWN0IHhtZW1fcG9v
bCAqcG9vbCwKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgZmwsIGlu
dCBzbCkKPiArewo+ICsgICAgY29uc3Qgc3RydWN0IGJoZHIgKmIgPSBwb29sLT5tYXRyaXhbZmxd
W3NsXTsKPiArCj4gKyAgICB3aGlsZSAoIGIgKQo+ICsgICAgewo+ICsgICAgICAgIGludCBfX2Zs
Owo+ICsgICAgICAgIGludCBfX3NsOwo+ICsKPiArICAgICAgICBNQVBQSU5HX0lOU0VSVChiLT5z
aXplLCAmX19mbCwgJl9fc2wpOwo+ICsgICAgICAgIGlmICggX19mbCAhPSBmbCB8fCBfX3NsICE9
IHNsICkKPiArICAgICAgICB7Cj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSCj4gKyAg
ICAgICAgICAgICAgICAgICAieG1lbV9wb29sOiAlczogbWlzcGxhY2VkIGJsb2NrICVwOiV1ICh7
JWQsJWR9IC0+IHslZCwlZH0pXG4iLAoKSXMgaXQgbGlhYmxlIHRvIGdldCBjb25mdXNpbmcgd2l0
aCBhIGhleCBudW1iZXIgYW5kIGEgZGVjaW1hbCBudW1iZXIKY29tYmluZWQgd2l0aCBqdXN0IGEg
Y29sb24/CgpJcyBiIGV2ZW4gdXNlZnVsPyAgWW91IGhhdmUgdGhlIHBvb2wgbmFtZSwgaW5kaWNp
ZXMgYW5kIHNpemUgd2hpY2ggc2VlbQp0byBiZSB0aGUgc2FsaWVudCBpbmZvcm1hdGlvbi4KCj4g
KyAgICAgICAgICAgICAgICAgICBwb29sLT5uYW1lLCBiLCBiLT5zaXplLCBmbCwgc2wsIF9fZmws
IF9fc2wpOwo+ICsgICAgICAgICAgICByZXR1cm4gMDsKPiArICAgICAgICB9Cj4gKyAgICAgICAg
YiA9IGItPnB0ci5mcmVlX3B0ci5uZXh0Owo+ICsgICAgfQo+ICsgICAgcmV0dXJuIDE7Cj4gK30K
PiArCj4gKy8qCj4gKyAqIFRoaXMgZnVuY3Rpb24gbXVzdCBiZSBjYWxsZWQgZnJvbSBhIGNvbnRl
eHQgd2hlcmUgcG9vbC0+bG9jayBpcwo+ICsgKiBhbHJlYWR5IGFjcXVpcmVkLgo+ICsgKgo+ICsg
KiBSZXR1cm5zIHRydWUgaWYgdGhlIHBvb2wgaGFzIGJlZW4gY29ycnVwdGVkLCBmYWxzZSBvdGhl
cndpc2UKPiArICovCj4gKyNkZWZpbmUgeG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKSBcCj4g
KyAgICBfX3htZW1fcG9vbF9jaGVja19sb2NrZWQoX19GSUxFX18sIF9fTElORV9fLCBwb29sKQo+
ICtzdGF0aWMgYm9vbF90IF9feG1lbV9wb29sX2NoZWNrX2xvY2tlZChjb25zdCBjaGFyICpmaWxl
LCBpbnQgbGluZSwKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29u
c3Qgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiArewo+ICsgICAgdW5zaWduZWQgaW50IGk7Cj4g
KyAgICBzdGF0aWMgYm9vbF90IG9uY2UgPSAxOwoKV2hhdCBpcyB0aGlzIHN0YXRpYyBkb2luZz8g
IFN1cmVseSBjb3JydXB0aW9uIGNvcnJ1cHRpb24gaW4gb25lIHBvb2wgaGFzCm5vIGVmZmVjdCBv
biBjb3JydXB0aW9uIGluIGEgc2VwYXJhdGUgcG9vbCAob3RoZXIgdGhhbiB0aGUgdXN1YWwgc2lk
ZQplZmZlY3RzIG9mIGdlbmVyYWwgbWVtb3J5IGNvcnJ1cHRpb24sIHdoaWNoIHRlbmQgdG8gYmUg
YmFkKS4KCkl0IGxvb2tzIGFzIGlmIGl0IHdhbnRzIHRvIGJlIGFuIGV4dHJhIGZpZWxkIGluIGFu
IHhtZW1fcG9vbC4KCj4gKwo+ICsgICAgaWYgKCAhb25jZSApCj4gKyAgICAgICAgcmV0dXJuIDE7
Cj4gKyAgICBmb3IgKCBpID0gMDsgaSA8IFJFQUxfRkxJOyBpKysgKQo+ICsgICAgewo+ICsgICAg
ICAgIGludCBmbCA9IChwb29sLT5mbF9iaXRtYXAgJiAoMSA8PCBpKSkgPyBpIDogLTE7Cj4gKwo+
ICsgICAgICAgIGlmICggZmwgPj0gMCApCj4gKyAgICAgICAgewo+ICsgICAgICAgICAgICB1bnNp
Z25lZCBpbnQgajsKPiArCj4gKyAgICAgICAgICAgIGlmICggIXBvb2wtPnNsX2JpdG1hcFtmbF0g
KQo+ICsgICAgICAgICAgICB7Cj4gKyAgICAgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUgo+
ICsgICAgICAgICAgICAgICAgICAgICAgICJ4bWVtX3Bvb2w6ICVzOiBUTFNGIGJpdG1hcCBjb3Jy
dXB0ICghZW1wdHkgRkwsIGVtcHR5IFNMKVxuIiwKPiArICAgICAgICAgICAgICAgICAgICAgICBw
b29sLT5uYW1lKTsKPiArICAgICAgICAgICAgICAgIF9fd2FybihmaWxlLCBsaW5lKTsKClRoZSBf
X3dhcm4oKXMgaGVyZSB3aWxsIGN1cnJlbnRseSBkbyBhIGZ1bGwgcmVnaXN0ZXIgZHVtcCwgYXMg
d2VsbCBhcwpzdGFjayBkdW1wIGFuZCBzdGFjayB0cmFjZS4gIEl0IG9jY3VycyB0byBtZSB0aGF0
IG9ubHkgdGhlIHN0YWNrIHRyYWNlCml0c2VsZiBpcyB1c2VmdWwgYXQgdGhpcyBwb2ludC4KCl9f
YnVnIGFuZCBfX3dhcm4oKSBhcmUgY3VycmVudGx5IHVudXNlZCAoSSBhbSBzdHJ1Z2dsaW5nIHRv
IHdvcmsgb3V0CmV4YWN0bHkgd2hlbiB0aGV5IHdlcmUgb3JwaGFuZWQ7IHRoZXkgZG8gbm90IGZv
cm0gcGFydCBvZiByZWd1bGFyCkJVRygpL1dBUk4oKSBvcGVyYXRpb25zLCB3aGljaCBhcmUgaGFu
ZGxlZCBpbiBkb19pbnZhbGlkX29wKCkpLiAgVGhleQphcmUgYWxzbyBub3QgZmFudGFzdGljYWxs
eSB1c2VmdWwgYXMgdGhleSB3aWxsIGFsd2F5cyBpZGVudGlmeQp0aGVtc2VsdmVzIGluIHRoZSBw
cmludGVkIGluZm9ybWF0aW9uLCBub3QgdGhlaXIgY2FsbGVyLiAgSSBzdXNwZWN0IHRoZXkKY2Fu
IGp1c3QgYmUgZHJvcHBlZCBjb21wbGV0ZWx5LgoKSSBzdXNwZWN0IHlvdSBhbHNvIHdvdWxkIGJl
IGJldHRlciwgYW5kIGNlcnRhaW5seSBtb3JlIGJyaWVmLCB3aXRoCiJydW5faW5fZXhjZXB0aW9u
X2hhbmRsZXIoc2hvd19zdGFjaykiIGluc3RlYWQsIHdoaWNoIHdpbGwganVzdCBwcmludCBhCnN0
YWNrIHRyYWNlLCBidXQgbm90aGluZyBtb3JlLgoKPiArICAgICAgICAgICAgICAgIG9uY2UgPSAw
Owo+ICsgICAgICAgICAgICAgICAgYnJlYWs7Cj4gKyAgICAgICAgICAgIH0KPiArICAgICAgICAg
ICAgZm9yICggaiA9IDA7IGogPCBNQVhfU0xJOyBqKysgKQo+ICsgICAgICAgICAgICB7Cj4gKyAg
ICAgICAgICAgICAgICBpbnQgc2wgPSAocG9vbC0+c2xfYml0bWFwW2ZsXSAmICgxIDw8IGopKSA/
IGogOiAtMTsKPiArCj4gKyAgICAgICAgICAgICAgICBpZiAoIHNsIDwgMCApCj4gKyAgICAgICAg
ICAgICAgICAgICAgY29udGludWU7Cj4gKyAgICAgICAgICAgICAgICBpZiAoICFwb29sLT5tYXRy
aXhbZmxdW3NsXSApCj4gKyAgICAgICAgICAgICAgICB7Cj4gKyAgICAgICAgICAgICAgICAgICAg
cHJpbnRrKFhFTkxPR19FUlIKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgInhtZW1fcG9v
bDogJXM6IFRMU0YgYml0bWFwIGNvcnJ1cHQgKCFtYXRyaXhbJWRdWyVkXSlcbiIsCj4gKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHBvb2wtPm5hbWUsIGZsLCBzbCk7Cj4gKyAgICAgICAgICAg
ICAgICAgICAgX193YXJuKGZpbGUsIGxpbmUpOwo+ICsgICAgICAgICAgICAgICAgICAgIG9uY2Ug
PSAwOwo+ICsgICAgICAgICAgICAgICAgICAgIGJyZWFrOwo+ICsgICAgICAgICAgICAgICAgfQo+
ICsgICAgICAgICAgICAgICAgaWYgKCAheG1lbV9wb29sX2NoZWNrX3NpemUocG9vbCwgZmwsIHNs
KSApCj4gKyAgICAgICAgICAgICAgICB7Cj4gKyAgICAgICAgICAgICAgICAgICAgcHJpbnRrKFhF
TkxPR19FUlIgInhtZW1fcG9vbDogJXM6IFRMU0YgY2h1bmsgbWF0cml4IGNvcnJ1cHRcbiIsCj4g
KyAgICAgICAgICAgICAgICAgICAgICAgICAgIHBvb2wtPm5hbWUpOwo+ICsgICAgICAgICAgICAg
ICAgICAgIF9fd2FybihmaWxlLCBsaW5lKTsKPiArICAgICAgICAgICAgICAgICAgICBvbmNlID0g
MDsKPiArICAgICAgICAgICAgICAgICAgICBicmVhazsKPiArICAgICAgICAgICAgICAgIH0KPiAr
ICAgICAgICAgICAgfQo+ICsgICAgICAgICAgICBpZiAoICFvbmNlICkKPiArICAgICAgICAgICAg
ICAgIGJyZWFrOwo+ICsgICAgICAgIH0KPiArICAgIH0KPiArICAgIHJldHVybiAhb25jZTsKPiAr
fQo+ICsKPiArI2RlZmluZSB4bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQocG9vbCkgXAo+ICsgICAg
X194bWVtX3Bvb2xfY2hlY2tfdW5sb2NrZWQoX19GSUxFX18sIF9fTElORV9fLCBwb29sKQo+ICtz
dGF0aWMgYm9vbF90IF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKGNvbnN0IGNoYXIgKmZpbGUs
IGludCBsaW5lLAo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0
cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gK3sKPiArICAgIGJvb2xfdCBvb3BzOwo+ICsKPiArICAg
IHNwaW5fbG9jaygmcG9vbC0+bG9jayk7Cj4gKyAgICBvb3BzID0gX194bWVtX3Bvb2xfY2hlY2tf
bG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wpOwo+ICsgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2sp
Owo+ICsgICAgcmV0dXJuIG9vcHM7Cj4gK30KPiArCj4gK2Jvb2xfdCBfX3htZW1fcG9vbF9jaGVj
ayhjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgc3RydWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAr
ewo+ICsgICAgcmV0dXJuIF9feG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKGZpbGUsIGxpbmUsIHBv
b2wgPzogeGVucG9vbCk7CgpXaHkgc2hvdWxkIGEgTlVMTCBwb29sIGJlIHRvbGVyYXRlZCBoZXJl
PyAgVGhpcyBpcyBkZWJ1ZyBjb2RlIG9ubHksIHNvCndlIGNhbiByZXF1aXJlIGFuZCB0cnVzdCB0
aGF0IHdlIGFyZSBjYWxsZWQgYXBwcm9wcmlhdGVseS4KCj4gK30KPiArI2Vsc2UKPiArI2RlZmlu
ZSB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBvb2wpICgodm9pZCkocG9vbCkpCj4gKyNkZWZpbmUg
eG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKHBvb2wpICgodm9pZCkocG9vbCkpCj4gKyNlbmRpZgo+
ICAKPiAgLyoqCj4gICAqIFJldHVybnMgaW5kZXhlcyAoZmwsIHNsKSBvZiB0aGUgbGlzdCB1c2Vk
IHRvIHNlcnZlIHJlcXVlc3Qgb2Ygc2l6ZSByCj4gQEAgLTM4MSw2ICs0OTQsOCBAQCB2b2lkICp4
bWVtX3Bvb2xfYWxsb2ModW5zaWduZWQgbG9uZyBzaXplLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29s
KQo+ICAgICAgaW50IGZsLCBzbDsKPiAgICAgIHVuc2lnbmVkIGxvbmcgdG1wX3NpemU7Cj4gIAo+
ICsgICAgeG1lbV9wb29sX2NoZWNrX3VubG9ja2VkKHBvb2wpOwo+ICsKPiAgICAgIGlmICggcG9v
bC0+aW5pdF9yZWdpb24gPT0gTlVMTCApCj4gICAgICB7Cj4gICAgICAgICAgaWYgKCAocmVnaW9u
ID0gcG9vbC0+Z2V0X21lbShwb29sLT5pbml0X3NpemUpKSA9PSBOVUxMICkKPiBAQCAtNDQyLDEx
ICs1NTcsMTMgQEAgdm9pZCAqeG1lbV9wb29sX2FsbG9jKHVuc2lnbmVkIGxvbmcgc2l6ZSwgc3Ry
dWN0IHhtZW1fcG9vbCAqcG9vbCkKPiAgCj4gICAgICBwb29sLT51c2VkX3NpemUgKz0gKGItPnNp
emUgJiBCTE9DS19TSVpFX01BU0spICsgQkhEUl9PVkVSSEVBRDsKPiAgCj4gKyAgICB4bWVtX3Bv
b2xfY2hlY2tfbG9ja2VkKHBvb2wpOwo+ICAgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwo+
ICAgICAgcmV0dXJuICh2b2lkICopYi0+cHRyLmJ1ZmZlcjsKPiAgCj4gICAgICAvKiBGYWlsZWQg
YWxsb2MgKi8KPiAgIG91dF9sb2NrZWQ6Cj4gKyAgICB4bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKHBv
b2wpOwo+ICAgICAgc3Bpbl91bmxvY2soJnBvb2wtPmxvY2spOwo+ICAKPiAgIG91dDoKPiBAQCAt
NDY0LDYgKzU4MSw3IEBAIHZvaWQgeG1lbV9wb29sX2ZyZWUodm9pZCAqcHRyLCBzdHJ1Y3QgeG1l
bV9wb29sICpwb29sKQo+ICAgICAgYiA9IChzdHJ1Y3QgYmhkciAqKSgoY2hhciAqKSBwdHIgLSBC
SERSX09WRVJIRUFEKTsKPiAgCj4gICAgICBzcGluX2xvY2soJnBvb2wtPmxvY2spOwo+ICsgICAg
eG1lbV9wb29sX2NoZWNrX2xvY2tlZChwb29sKTsKPiAgICAgIGItPnNpemUgfD0gRlJFRV9CTE9D
SzsKPiAgICAgIHBvb2wtPnVzZWRfc2l6ZSAtPSAoYi0+c2l6ZSAmIEJMT0NLX1NJWkVfTUFTSykg
KyBCSERSX09WRVJIRUFEOwo+ICAgICAgYi0+cHRyLmZyZWVfcHRyID0gKHN0cnVjdCBmcmVlX3B0
cikgeyBOVUxMLCBOVUxMfTsKPiBAQCAtNTAwLDYgKzYxOCw3IEBAIHZvaWQgeG1lbV9wb29sX2Zy
ZWUodm9pZCAqcHRyLCBzdHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+ICAgICAgdG1wX2ItPnNpemUg
fD0gUFJFVl9GUkVFOwo+ICAgICAgdG1wX2ItPnByZXZfaGRyID0gYjsKPiAgIG91dDoKPiArICAg
IHhtZW1fcG9vbF9jaGVja19sb2NrZWQocG9vbCk7Cj4gICAgICBzcGluX3VubG9jaygmcG9vbC0+
bG9jayk7Cj4gIH0KPiAgCj4gQEAgLTUxMiw4ICs2MzEsNiBAQCBpbnQgeG1lbV9wb29sX21heGFs
bG9jKHN0cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4gICAqIEdsdWUgZm9yIHhtYWxsb2MoKS4KPiAg
ICovCj4gIAo+IC1zdGF0aWMgc3RydWN0IHhtZW1fcG9vbCAqeGVucG9vbDsKPiAtCj4gIHN0YXRp
YyB2b2lkICp4bWFsbG9jX3Bvb2xfZ2V0KHVuc2lnbmVkIGxvbmcgc2l6ZSkKPiAgewo+ICAgICAg
QVNTRVJUKHNpemUgPT0gUEFHRV9TSVpFKTsKPiBkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVu
L3htYWxsb2MuaCBiL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKPiBpbmRleCAyNGE5OWFjLi5h
ZDQ4OTMwIDEwMDY0NAo+IC0tLSBhL3hlbi9pbmNsdWRlL3hlbi94bWFsbG9jLmgKPiArKysgYi94
ZW4vaW5jbHVkZS94ZW4veG1hbGxvYy5oCj4gQEAgLTEyMyw0ICsxMjMsMTEgQEAgdW5zaWduZWQg
bG9uZyB4bWVtX3Bvb2xfZ2V0X3VzZWRfc2l6ZShzdHJ1Y3QgeG1lbV9wb29sICpwb29sKTsKPiAg
ICovCj4gIHVuc2lnbmVkIGxvbmcgeG1lbV9wb29sX2dldF90b3RhbF9zaXplKHN0cnVjdCB4bWVt
X3Bvb2wgKnBvb2wpOwo+ICAKPiArI2lmbmRlZiBOREVCVUcKPiArI2RlZmluZSB4bWVtX3Bvb2xf
Y2hlY2socG9vbCkgX194bWVtX3Bvb2xfY2hlY2soX19GSUxFX18sIF9fTElORV9fLCBwb29sKQo+
ICtib29sX3QgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsIHN0
cnVjdCB4bWVtX3Bvb2wgKnBvb2wpOwo+ICsjZWxzZQo+ICsjZGVmaW5lIHhtZW1fcG9vbF9jaGVj
ayhwb29sKSAoKHZvaWQpMCkKClRoaXMgbmVlZHMgdG8gYmUgKCh2b2lkKShwb29sKSkgdG8gZXZh
bHVhdGUgdGhlIHBvdGVudGlhbCBzaWRlIGVmZmVjdHMuIApIb3dldmVyLCBJIHRoaW5rIHlvdSBu
ZWVkIHRvIGNvbmRpdGlvbmFsbHkgY2hhbmdlIF9feG1lbV9wb29sX2NoZWNrKCkKYW5kIG1vdmUg
I2RlZmluZSB4bWVtX3Bvb2xfY2hlY2sgb3V0c2lkZSB0aGUgY29uZGl0aW9uYWwsIHRvIGNvdmVy
CmZ1dHVyZSBjb25zdW1lcnMgd2hvIG1pZ2h0IGNob29zZSB0byBjYWxsIF9feG1lbV9wb29sX2No
ZWNrKCkgZGlyZWN0bHkuCgoKV2hhdCBhcmUgdGhlIG92ZXJoZWFkcyBvZiBwb29sIGNvbnNpc3Rl
bmN5IGNoZWNraW5nPyAgSXQgbG9va3MgdG8gYmUKbW9kZXJhdGVseSBoaWdoLCBnaXZlbiBhIGZ1
bGwgaW5zcGVjdGlvbiBvZiB0aGUgbWF0cml4IG9uIGVhY2gKYWxsb2NhdGlvbiBhbmQgZnJlZS4g
IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGhhdmUgb25lIGVhc3ktdG8tYWx0ZXIKY29tcGlsZSB0
aW1lIGtub2Igc28gdGhlIGRlZmF1bHQgY2FuIGJlIG92ZXJyaWRkZW4gaW4gYSBzaW5nbGUgbG9j
YXRpb24/CgpQZXJoYXBzIHNvbWV0aGluZyBsaWtlOgoKI2lmbmRlZiBOREVCVUcKI2RlZmluZSBY
TUVNX1BPT0xfQ0hFQ0tTCiNlbmRpZgoKI2lmZGVmIFhNRU1fUE9PTF9DSEVDS1MKLi4uCiNlbHNl
Ci4uLgojZW5kaWYKCn5BbmRyZXcKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Dec 16 20:39:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0ytg-0007UP-Ly; Tue, 16 Dec 2014 20:39:08 +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 1Y0ytf-0007UH-5Z
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 20:39:07 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	53/8A-22737-A6890945; Tue, 16 Dec 2014 20:39:06 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418762345!13718126!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20081 invoked from network); 16 Dec 2014 20:39:05 -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; 16 Dec 2014 20:39:05 -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 sBGKcmcM000346;
	Tue, 16 Dec 2014 20:38:52 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 sBGKcgsV001727
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Dec 2014 20:38:42 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 sBGKcgS6007765;
	Tue, 16 Dec 2014 20:38:42 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sBGKcgf8007761; Tue, 16 Dec 2014 20:38:42 GMT
Date: Tue, 16 Dec 2014 20:38:42 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141201211117.GF22021@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1412162036540.9237@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com>
	<1417176581.23604.25.camel@citrix.com>
	<20141201211117.GF22021@laptop.dumpdata.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: sBGKcmcM000346
Cc: Wei Liu <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
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-Transfer-Encoding: 7bit
Content-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, 1 Dec 2014, Konrad Rzeszutek Wilk wrote:

> On Fri, Nov 28, 2014 at 12:09:41PM +0000, Ian Campbell wrote:
>> 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...
>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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));
>>>>

Is this patch going to get committed in time for xen 4.5?

 	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 Dec 16 20:39:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y0ytg-0007UP-Ly; Tue, 16 Dec 2014 20:39:08 +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 1Y0ytf-0007UH-5Z
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 20:39:07 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	53/8A-22737-A6890945; Tue, 16 Dec 2014 20:39:06 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418762345!13718126!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20081 invoked from network); 16 Dec 2014 20:39:05 -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; 16 Dec 2014 20:39:05 -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 sBGKcmcM000346;
	Tue, 16 Dec 2014 20:38:52 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 sBGKcgsV001727
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Dec 2014 20:38:42 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 sBGKcgS6007765;
	Tue, 16 Dec 2014 20:38:42 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sBGKcgf8007761; Tue, 16 Dec 2014 20:38:42 GMT
Date: Tue, 16 Dec 2014 20:38:42 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20141201211117.GF22021@laptop.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1412162036540.9237@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com>
	<1417176581.23604.25.camel@citrix.com>
	<20141201211117.GF22021@laptop.dumpdata.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: sBGKcmcM000346
Cc: Wei Liu <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
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-Transfer-Encoding: 7bit
Content-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, 1 Dec 2014, Konrad Rzeszutek Wilk wrote:

> On Fri, Nov 28, 2014 at 12:09:41PM +0000, Ian Campbell wrote:
>> 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...
>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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));
>>>>

Is this patch going to get committed in time for xen 4.5?

 	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 Dec 16 20:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0z0b-00088M-CA; Tue, 16 Dec 2014 20:46: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 1Y0z0a-00088A-36
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:46:16 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	71/5A-03148-71A90945; Tue, 16 Dec 2014 20:46:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418762773!15489008!1
X-Originating-IP: [156.151.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 10865 invoked from network); 16 Dec 2014 20:46:14 -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; 16 Dec 2014 20:46: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 sBGKk9l4011359
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Dec 2014 20:46:10 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
	sBGKk8vY011807
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 16 Dec 2014 20:46:08 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
	sBGKk7sw002607; Tue, 16 Dec 2014 20:46:07 GMT
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Dec 2014 12:46:07 -0800
Date: Tue, 16 Dec 2014 15:46:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141216204601.GA11551@konrad-lan.dumpdata.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<20141216163451.GA18976@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141216163451.GA18976@aepfle.de>
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
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 05:34:51PM +0100, Olaf Hering wrote:
> On Tue, Dec 16, konrad.wilk@oracle.com wrote:
> 
> > In terms of bugs, we have:
> 
> ... systemd SELinux, but its not listed.

> 
> Whats your plan with the failures you see? Should I continue to be
> concerned about that, or will all the be postponed to 4.6?

I was under the impression you had some patches which would solve a
majority of the issues? And after the discussion with Ian Jackson the
way to exec was solved?

And for the other - the SELinux context and how to figure this out -
I thought (I will have to double-check it tomorrow) that I mentioned it might
make sense to talk to the SELinux maintainers to see if they have any
recommendation?

> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 20:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0z0I-00086I-Q4; Tue, 16 Dec 2014 20:45:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0z0H-00086D-Fe
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 20:45:57 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	32/AF-02696-40A90945; Tue, 16 Dec 2014 20:45:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418762754!15508359!1
X-Originating-IP: [66.165.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 18861 invoked from network); 16 Dec 2014 20:45:55 -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;
	16 Dec 2014 20:45:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205552977"
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.210.2; Tue, 16 Dec 2014 15:45: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 1Y0z0C-0001gI-M6;
	Tue, 16 Dec 2014 20:45:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0z0C-0002mO-F9;
	Tue, 16 Dec 2014 20:45:52 +0000
Date: Tue, 16 Dec 2014 20:45:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32412-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] 32412: 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 32412 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32412/

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          14 guest-localmigrate.2      fail REGR. vs. 31241
 test-amd64-amd64-pair        16 guest-start/debian        fail REGR. vs. 31241
 build-i386-pvops              4 host-build-prep           fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot            fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot     fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 11 guest-saverestore         fail REGR. vs. 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10    fail REGR. vs. 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-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 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-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-freebsd10-i386  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-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            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  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-qemut-debianhvm-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-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-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-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                2dbfca5a181973558277b28b1f4c36362291f5e0
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1848 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                                             broken  
 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                    fail    
 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


Not pushing.

(No revision log; it would be 218669 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 Dec 16 20:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0z0b-00088M-CA; Tue, 16 Dec 2014 20:46: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 1Y0z0a-00088A-36
	for xen-devel@lists.xenproject.org; Tue, 16 Dec 2014 20:46:16 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	71/5A-03148-71A90945; Tue, 16 Dec 2014 20:46:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418762773!15489008!1
X-Originating-IP: [156.151.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 10865 invoked from network); 16 Dec 2014 20:46:14 -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; 16 Dec 2014 20:46: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 sBGKk9l4011359
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Dec 2014 20:46:10 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
	sBGKk8vY011807
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 16 Dec 2014 20:46:08 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
	sBGKk7sw002607; Tue, 16 Dec 2014 20:46:07 GMT
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Dec 2014 12:46:07 -0800
Date: Tue, 16 Dec 2014 15:46:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141216204601.GA11551@konrad-lan.dumpdata.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<20141216163451.GA18976@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141216163451.GA18976@aepfle.de>
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
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 05:34:51PM +0100, Olaf Hering wrote:
> On Tue, Dec 16, konrad.wilk@oracle.com wrote:
> 
> > In terms of bugs, we have:
> 
> ... systemd SELinux, but its not listed.

> 
> Whats your plan with the failures you see? Should I continue to be
> concerned about that, or will all the be postponed to 4.6?

I was under the impression you had some patches which would solve a
majority of the issues? And after the discussion with Ian Jackson the
way to exec was solved?

And for the other - the SELinux context and how to figure this out -
I thought (I will have to double-check it tomorrow) that I mentioned it might
make sense to talk to the SELinux maintainers to see if they have any
recommendation?

> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 20:46:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0z0I-00086I-Q4; Tue, 16 Dec 2014 20:45:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y0z0H-00086D-Fe
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 20:45:57 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	32/AF-02696-40A90945; Tue, 16 Dec 2014 20:45:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418762754!15508359!1
X-Originating-IP: [66.165.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 18861 invoked from network); 16 Dec 2014 20:45:55 -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;
	16 Dec 2014 20:45:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208";a="205552977"
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.210.2; Tue, 16 Dec 2014 15:45: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 1Y0z0C-0001gI-M6;
	Tue, 16 Dec 2014 20:45:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y0z0C-0002mO-F9;
	Tue, 16 Dec 2014 20:45:52 +0000
Date: Tue, 16 Dec 2014 20:45:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32412-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] 32412: 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 32412 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32412/

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          14 guest-localmigrate.2      fail REGR. vs. 31241
 test-amd64-amd64-pair        16 guest-start/debian        fail REGR. vs. 31241
 build-i386-pvops              4 host-build-prep           fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot            fail REGR. vs. 31241
 test-amd64-amd64-xl-qemut-debianhvm-amd64  5 xen-boot     fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 11 guest-saverestore         fail REGR. vs. 31241
 test-armhf-armhf-xl           9 guest-start                  fail   like 31241
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10    fail REGR. vs. 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-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 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-qemut-rhel6hvm-amd  1 build-check(1)               blocked n/a
 test-amd64-i386-freebsd10-i386  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-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            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  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-qemut-debianhvm-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-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-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-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                2dbfca5a181973558277b28b1f4c36362291f5e0
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1848 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                                             broken  
 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                    fail    
 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


Not pushing.

(No revision log; it would be 218669 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 Dec 16 20:49:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0z3O-0008M3-Vv; Tue, 16 Dec 2014 20:49: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 1Y0z3M-0008Lr-SN
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 20:49:08 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	7B/BE-22819-4CA90945; Tue, 16 Dec 2014 20:49:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418762946!13699895!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13028 invoked from network); 16 Dec 2014 20:49:07 -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; 16 Dec 2014 20:49:07 -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 sBGKn4hQ008201
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Dec 2014 20:49:04 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
	sBGKn36T011789
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 16 Dec 2014 20:49:03 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
	sBGKn2Hr011783; Tue, 16 Dec 2014 20:49:02 GMT
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Dec 2014 12:49:02 -0800
Date: Tue, 16 Dec 2014 15:49:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141216204900.GB11551@konrad-lan.dumpdata.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54906F2C.8030800@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 05:43:08PM +0000, Andrew Cooper wrote:
> On 16/12/14 16:13, konrad.wilk@oracle.com wrote:
> > Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
> > we have the General Release on Jan 7th!
> >
> > Details for the test-day are at
> >
> > http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions
> >
> > In terms of bugs, we have:
> 
> From the XenServer testing.

Thank you for doing this testing!
> 
> * Fail to reliably boot on IBM Flex x222 blades, apparent regression
> from 4.4
> 
> I have declared this a latent BIOS bug, and not a regression from 4.4. 
> Across regular reboots, the exact positions of the ACPI tables, and the
> e820 layout is unstable.  The first consistent difference between 4.4
> and 4.5 is that 4.4 reports 1 MBR signature while 4.5 reports 0.  This
> is because the int $0x13, ah=2 call is returning differently.  I can get
> the call to return differently (and correctly for 4.5) by simply making
> the boot trampoline larger (with my debugging routines but not being
> called).

This sounds very familiar, but I can't place where I saw mention of
a similar issue.
> 
> * VM fail to resume on upgrade from Xen < 4.5
> 
> This is the issue I am currently looking into.  Currently, all the
> "upgrade from older XenServer" tests are failing due to VMs crashing on
> resume.  I have not yet identified whether this is a XenServer issue or

Ugh.
> a Xen issue.  Lifecycle operations on 4.5 itself are all fine including
> both suspend/resume and 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 Dec 16 20:49:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 20: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 1Y0z3O-0008M3-Vv; Tue, 16 Dec 2014 20:49: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 1Y0z3M-0008Lr-SN
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 20:49:08 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	7B/BE-22819-4CA90945; Tue, 16 Dec 2014 20:49:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418762946!13699895!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13028 invoked from network); 16 Dec 2014 20:49:07 -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; 16 Dec 2014 20:49:07 -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 sBGKn4hQ008201
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Dec 2014 20:49:04 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
	sBGKn36T011789
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 16 Dec 2014 20:49:03 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
	sBGKn2Hr011783; Tue, 16 Dec 2014 20:49:02 GMT
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Dec 2014 12:49:02 -0800
Date: Tue, 16 Dec 2014 15:49:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141216204900.GB11551@konrad-lan.dumpdata.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54906F2C.8030800@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 05:43:08PM +0000, Andrew Cooper wrote:
> On 16/12/14 16:13, konrad.wilk@oracle.com wrote:
> > Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
> > we have the General Release on Jan 7th!
> >
> > Details for the test-day are at
> >
> > http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions
> >
> > In terms of bugs, we have:
> 
> From the XenServer testing.

Thank you for doing this testing!
> 
> * Fail to reliably boot on IBM Flex x222 blades, apparent regression
> from 4.4
> 
> I have declared this a latent BIOS bug, and not a regression from 4.4. 
> Across regular reboots, the exact positions of the ACPI tables, and the
> e820 layout is unstable.  The first consistent difference between 4.4
> and 4.5 is that 4.4 reports 1 MBR signature while 4.5 reports 0.  This
> is because the int $0x13, ah=2 call is returning differently.  I can get
> the call to return differently (and correctly for 4.5) by simply making
> the boot trampoline larger (with my debugging routines but not being
> called).

This sounds very familiar, but I can't place where I saw mention of
a similar issue.
> 
> * VM fail to resume on upgrade from Xen < 4.5
> 
> This is the issue I am currently looking into.  Currently, all the
> "upgrade from older XenServer" tests are failing due to VMs crashing on
> resume.  I have not yet identified whether this is a XenServer issue or

Ugh.
> a Xen issue.  Lifecycle operations on 4.5 itself are all fine including
> both suspend/resume and 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 Dec 16 21:56:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 21: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 1Y106D-0001vW-O5; Tue, 16 Dec 2014 21:56:09 +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 1Y106C-0001vR-Nx
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 21:56:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FA/9D-09842-87AA0945; Tue, 16 Dec 2014 21:56:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418766966!16059993!1
X-Originating-IP: [66.165.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 25387 invoked from network); 16 Dec 2014 21:56:07 -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;
	16 Dec 2014 21:56:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,589,1413244800"; d="scan'208";a="205120231"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 16 Dec 2014 16:55: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 1Y105q-00019g-EN;
	Tue, 16 Dec 2014 21:55:46 +0000
Date: Tue, 16 Dec 2014 21:55:46 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141216215546.GA19797@zion.uk.xensource.com>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com>
	<1417176581.23604.25.camel@citrix.com>
	<20141201211117.GF22021@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412162036540.9237@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1412162036540.9237@procyon.dur.ac.uk>
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>,
	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
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 Tue, Dec 16, 2014 at 08:38:42PM +0000, M A Young wrote:
[...]
> Is this patch going to get committed in time for xen 4.5?
> 

Yes. See d36a3734a6.

And there's a subsequence patch to fix a regression caused by that
patch. See 09b7ff1a.

Wei.

> 	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 Dec 16 21:56:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 21: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 1Y106D-0001vW-O5; Tue, 16 Dec 2014 21:56:09 +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 1Y106C-0001vR-Nx
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 21:56:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FA/9D-09842-87AA0945; Tue, 16 Dec 2014 21:56:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418766966!16059993!1
X-Originating-IP: [66.165.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 25387 invoked from network); 16 Dec 2014 21:56:07 -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;
	16 Dec 2014 21:56:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,589,1413244800"; d="scan'208";a="205120231"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 16 Dec 2014 16:55: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 1Y105q-00019g-EN;
	Tue, 16 Dec 2014 21:55:46 +0000
Date: Tue, 16 Dec 2014 21:55:46 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141216215546.GA19797@zion.uk.xensource.com>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com>
	<1417176581.23604.25.camel@citrix.com>
	<20141201211117.GF22021@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412162036540.9237@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1412162036540.9237@procyon.dur.ac.uk>
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>,
	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
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 Tue, Dec 16, 2014 at 08:38:42PM +0000, M A Young wrote:
[...]
> Is this patch going to get committed in time for xen 4.5?
> 

Yes. See d36a3734a6.

And there's a subsequence patch to fix a regression caused by that
patch. See 09b7ff1a.

Wei.

> 	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 Dec 16 22:05:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 22:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y10EZ-0002L3-OI; Tue, 16 Dec 2014 22:04:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Y10EY-0002Ky-GZ
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 22:04:46 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	04/91-15461-D7CA0945; Tue, 16 Dec 2014 22:04:45 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418767485!16060812!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 3583 invoked from network); 16 Dec 2014 22:04:45 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 22:04:45 -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 sBGM4UI4017449;
	Tue, 16 Dec 2014 22:04:34 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 sBGM4QrZ011517
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Dec 2014 22:04:26 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 sBGM4QiV007981;
	Tue, 16 Dec 2014 22:04:26 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sBGM4PRk007977; Tue, 16 Dec 2014 22:04:25 GMT
Date: Tue, 16 Dec 2014 22:04:25 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <20141216215546.GA19797@zion.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1412162203060.9237@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com>
	<1417176581.23604.25.camel@citrix.com>
	<20141201211117.GF22021@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412162036540.9237@procyon.dur.ac.uk>
	<20141216215546.GA19797@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: sBGM4UI4017449
Cc: 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
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-Transfer-Encoding: 7bit
Content-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, 16 Dec 2014, Wei Liu wrote:

> On Tue, Dec 16, 2014 at 08:38:42PM +0000, M A Young wrote:
> [...]
>> Is this patch going to get committed in time for xen 4.5?
>>
>
> Yes. See d36a3734a6.
>
> And there's a subsequence patch to fix a regression caused by that
> patch. See 09b7ff1a.
>
> Wei.

No that is the other bug in xl migrate --debug (it fails rather than 
segfaults).

 	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 Dec 16 22:05:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 22:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y10EZ-0002L3-OI; Tue, 16 Dec 2014 22:04:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Y10EY-0002Ky-GZ
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 22:04:46 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	04/91-15461-D7CA0945; Tue, 16 Dec 2014 22:04:45 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418767485!16060812!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 3583 invoked from network); 16 Dec 2014 22:04:45 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 22:04:45 -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 sBGM4UI4017449;
	Tue, 16 Dec 2014 22:04:34 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 sBGM4QrZ011517
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Dec 2014 22:04:26 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 sBGM4QiV007981;
	Tue, 16 Dec 2014 22:04:26 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	sBGM4PRk007977; Tue, 16 Dec 2014 22:04:25 GMT
Date: Tue, 16 Dec 2014 22:04:25 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <20141216215546.GA19797@zion.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1412162203060.9237@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com>
	<1417176581.23604.25.camel@citrix.com>
	<20141201211117.GF22021@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412162036540.9237@procyon.dur.ac.uk>
	<20141216215546.GA19797@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: sBGM4UI4017449
Cc: 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
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-Transfer-Encoding: 7bit
Content-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, 16 Dec 2014, Wei Liu wrote:

> On Tue, Dec 16, 2014 at 08:38:42PM +0000, M A Young wrote:
> [...]
>> Is this patch going to get committed in time for xen 4.5?
>>
>
> Yes. See d36a3734a6.
>
> And there's a subsequence patch to fix a regression caused by that
> patch. See 09b7ff1a.
>
> Wei.

No that is the other bug in xl migrate --debug (it fails rather than 
segfaults).

 	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 Dec 16 22:56:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 22:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y112I-0003cH-W5; Tue, 16 Dec 2014 22:56:10 +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 1Y112H-0003cC-JT
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 22:56:09 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	D1/DB-02954-888B0945; Tue, 16 Dec 2014 22:56:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418770566!10859259!1
X-Originating-IP: [66.165.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 9336 invoked from network); 16 Dec 2014 22:56:08 -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;
	16 Dec 2014 22:56:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,590,1413244800"; d="scan'208";a="205139572"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 16 Dec 2014 17:55: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 1Y111u-0002AU-J6;
	Tue, 16 Dec 2014 22:55:46 +0000
Date: Tue, 16 Dec 2014 22:55:46 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141216225546.GA20393@zion.uk.xensource.com>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com>
	<1417176581.23604.25.camel@citrix.com>
	<20141201211117.GF22021@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412162036540.9237@procyon.dur.ac.uk>
	<20141216215546.GA19797@zion.uk.xensource.com>
	<alpine.DEB.2.00.1412162203060.9237@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1412162203060.9237@procyon.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>,
	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
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 Tue, Dec 16, 2014 at 10:04:25PM +0000, M A Young wrote:
> On Tue, 16 Dec 2014, Wei Liu wrote:
> 
> >On Tue, Dec 16, 2014 at 08:38:42PM +0000, M A Young wrote:
> >[...]
> >>Is this patch going to get committed in time for xen 4.5?
> >>
> >
> >Yes. See d36a3734a6.
> >
> >And there's a subsequence patch to fix a regression caused by that
> >patch. See 09b7ff1a.
> >
> >Wei.
> 
> No that is the other bug in xl migrate --debug (it fails rather than
> segfaults).
> 

Ah, I misread. Sorry.

> 	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 Dec 16 22:56:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 22:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y112I-0003cH-W5; Tue, 16 Dec 2014 22:56:10 +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 1Y112H-0003cC-JT
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 22:56:09 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	D1/DB-02954-888B0945; Tue, 16 Dec 2014 22:56:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418770566!10859259!1
X-Originating-IP: [66.165.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 9336 invoked from network); 16 Dec 2014 22:56:08 -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;
	16 Dec 2014 22:56:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,590,1413244800"; d="scan'208";a="205139572"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Tue, 16 Dec 2014 17:55: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 1Y111u-0002AU-J6;
	Tue, 16 Dec 2014 22:55:46 +0000
Date: Tue, 16 Dec 2014 22:55:46 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20141216225546.GA20393@zion.uk.xensource.com>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com>
	<1417176581.23604.25.camel@citrix.com>
	<20141201211117.GF22021@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412162036540.9237@procyon.dur.ac.uk>
	<20141216215546.GA19797@zion.uk.xensource.com>
	<alpine.DEB.2.00.1412162203060.9237@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1412162203060.9237@procyon.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>,
	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
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 Tue, Dec 16, 2014 at 10:04:25PM +0000, M A Young wrote:
> On Tue, 16 Dec 2014, Wei Liu wrote:
> 
> >On Tue, Dec 16, 2014 at 08:38:42PM +0000, M A Young wrote:
> >[...]
> >>Is this patch going to get committed in time for xen 4.5?
> >>
> >
> >Yes. See d36a3734a6.
> >
> >And there's a subsequence patch to fix a regression caused by that
> >patch. See 09b7ff1a.
> >
> >Wei.
> 
> No that is the other bug in xl migrate --debug (it fails rather than
> segfaults).
> 

Ah, I misread. Sorry.

> 	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 Dec 16 23:05:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 23:05:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y11Ad-00048f-2T; Tue, 16 Dec 2014 23:04:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1Y11Ab-00048a-NN
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 23:04:45 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	03/34-15461-C8AB0945; Tue, 16 Dec 2014 23:04:44 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418771083!16028601!1
X-Originating-IP: [96.126.108.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23939 invoked from network); 16 Dec 2014 23:04:44 -0000
Received: from mail1.linode.com (HELO mail1.linode.com) (96.126.108.55)
	by server-11.tower-21.messagelabs.com with SMTP;
	16 Dec 2014 23:04:44 -0000
Received: from imap-newark.linode.com (unknown
	[IPv6:2600:3c03::f03c:91ff:fedf:57d1])
	by mail1.linode.com (Postfix) with ESMTP id 804892663A;
	Tue, 16 Dec 2014 18:04:43 -0500 (EST)
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by imap-newark.linode.com (Postfix) with ESMTPSA id 6F9E8AAAF;
	Tue, 16 Dec 2014 18:04:43 -0500 (EST)
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: "Christopher S. Aker" <caker@theshore.net>
In-Reply-To: <548EC1DB.6070301@citrix.com>
Date: Tue, 16 Dec 2014 18:04:42 -0500
Message-Id: <0F780C62-4064-4227-9CCD-43FE21F968F0@theshore.net>
References: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>
	<548EC1DB.6070301@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
X-Mailer: Apple Mail (2.1990.1)
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] WARNING: at drivers/xen/gntdev.c:426
	unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Dec 15, 2014, at 6:11 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 11/12/14 15:12, Christopher S. Aker wrote:
>> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
>> Dom0: 3.17.4
>> 
>> Things go badly after a day or four.  We've hit this on a number of previously healthy hosts, since moving from 3.10.x dom0 to 3.17.4:
>> 
>> printk: 5441 messages suppressed.
>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>> grant_table.c:567:d0 Failed to obtain maptrack handle.
> 
> Can you provide more details about your networking and storage setup.
> In particular, do you have a domU providing networked storage (iscsi for
> example) to other domains on the same host?

Certainly. Thanks for the response. We're not using iscsi, but we do have some serious kit going on. This is the setup:

Storage: BBU hardware RAID (LSI), SSD drives, LVM logical volumes exported to the guests via blkback.

Network: Four 10Gbit links, ixgbe, bonded, then bridged onto br0, exported via netback via vifs.

Nothing fancier than that :)

-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 23:05:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 23:05:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y11Ad-00048f-2T; Tue, 16 Dec 2014 23:04:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1Y11Ab-00048a-NN
	for xen-devel@lists.xensource.com; Tue, 16 Dec 2014 23:04:45 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	03/34-15461-C8AB0945; Tue, 16 Dec 2014 23:04:44 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418771083!16028601!1
X-Originating-IP: [96.126.108.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23939 invoked from network); 16 Dec 2014 23:04:44 -0000
Received: from mail1.linode.com (HELO mail1.linode.com) (96.126.108.55)
	by server-11.tower-21.messagelabs.com with SMTP;
	16 Dec 2014 23:04:44 -0000
Received: from imap-newark.linode.com (unknown
	[IPv6:2600:3c03::f03c:91ff:fedf:57d1])
	by mail1.linode.com (Postfix) with ESMTP id 804892663A;
	Tue, 16 Dec 2014 18:04:43 -0500 (EST)
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by imap-newark.linode.com (Postfix) with ESMTPSA id 6F9E8AAAF;
	Tue, 16 Dec 2014 18:04:43 -0500 (EST)
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: "Christopher S. Aker" <caker@theshore.net>
In-Reply-To: <548EC1DB.6070301@citrix.com>
Date: Tue, 16 Dec 2014 18:04:42 -0500
Message-Id: <0F780C62-4064-4227-9CCD-43FE21F968F0@theshore.net>
References: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>
	<548EC1DB.6070301@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
X-Mailer: Apple Mail (2.1990.1)
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] WARNING: at drivers/xen/gntdev.c:426
	unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Dec 15, 2014, at 6:11 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 11/12/14 15:12, Christopher S. Aker wrote:
>> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
>> Dom0: 3.17.4
>> 
>> Things go badly after a day or four.  We've hit this on a number of previously healthy hosts, since moving from 3.10.x dom0 to 3.17.4:
>> 
>> printk: 5441 messages suppressed.
>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>> grant_table.c:567:d0 Failed to obtain maptrack handle.
> 
> Can you provide more details about your networking and storage setup.
> In particular, do you have a domU providing networked storage (iscsi for
> example) to other domains on the same host?

Certainly. Thanks for the response. We're not using iscsi, but we do have some serious kit going on. This is the setup:

Storage: BBU hardware RAID (LSI), SSD drives, LVM logical volumes exported to the guests via blkback.

Network: Four 10Gbit links, ixgbe, bonded, then bridged onto br0, exported via netback via vifs.

Nothing fancier than that :)

-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 23:06:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 23: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 1Y11C6-0004EB-Hk; Tue, 16 Dec 2014 23:06:18 +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 1Y11C4-0004E4-SX
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 23:06:16 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	CD/F2-02696-8EAB0945; Tue, 16 Dec 2014 23:06:16 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418771175!15532538!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9463 invoked from network); 16 Dec 2014 23:06:15 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 23:06:15 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so13921385wiw.2
	for <xen-devel@lists.xen.org>; Tue, 16 Dec 2014 15: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:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=7LBtnFJ14/aS/ZgWQjBUlWncm5AgWPWJmVvPmEQMU6Y=;
	b=Rlhptc8QOUeNfJnz1TyEOp8dpE7CCd1EFpZnA4Z2SM21X4qIC2lgbO+Fx1AalcMFPs
	4oE0385AbXScImYN5q4k8X7gwIksamBMKLD+qWihmfDsaKidn1mNpyER19p+3hhvrCYs
	Puj/ZqSifHuBoUXwVtn1zqYheZdp13ZpTae5GtJ2kACmdOfrXOhOodW6dBnqJt7y8RGU
	b2DesnA11ZhM7ZB96KglCESIJwGY3GSH0hmgl9WeIV3tleUI2j1sNYbVYDN7bZu475oV
	QEDQirEHVDaOSbenRgrLnHdExThXIxA6CSpKTmFvm1Fvxcu1NYPdjDmsqo9lDxM9465Z
	LLaA==
X-Gm-Message-State: ALoCoQn7NP4x2WyuVcFsowX1LC9qM26KsQB1ySRsiN2o3qIDvuu1MLKYh1hewVKFOBy2Q+niBYRR
X-Received: by 10.180.198.52 with SMTP id iz20mr8847876wic.60.1418771175494;
	Tue, 16 Dec 2014 15:06:15 -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 jp3sm18658353wid.9.2014.12.16.15.06.13
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 16 Dec 2014 15:06:14 -0800 (PST)
Message-ID: <5490BAE4.5070108@linaro.org>
Date: Tue, 16 Dec 2014 23:06:12 +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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?B?TWloYWkgRG9uyJt1?=
	<mdontu@bitdefender.com>, xen-devel@lists.xen.org
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com>
In-Reply-To: <549095E3.30202@citrix.com>
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 16/12/2014 20:28, Andrew Cooper wrote:
> I suspect you also would be better, and certainly more brief, with
> "run_in_exception_handler(show_stack)" instead, which will just print a
> stack trace, but nothing more.

FIY, run_in_exception_handler doesn't exists on ARM.

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 Dec 16 23:06:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 23: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 1Y11C6-0004EB-Hk; Tue, 16 Dec 2014 23:06:18 +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 1Y11C4-0004E4-SX
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 23:06:16 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	CD/F2-02696-8EAB0945; Tue, 16 Dec 2014 23:06:16 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418771175!15532538!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9463 invoked from network); 16 Dec 2014 23:06:15 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 23:06:15 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so13921385wiw.2
	for <xen-devel@lists.xen.org>; Tue, 16 Dec 2014 15: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:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=7LBtnFJ14/aS/ZgWQjBUlWncm5AgWPWJmVvPmEQMU6Y=;
	b=Rlhptc8QOUeNfJnz1TyEOp8dpE7CCd1EFpZnA4Z2SM21X4qIC2lgbO+Fx1AalcMFPs
	4oE0385AbXScImYN5q4k8X7gwIksamBMKLD+qWihmfDsaKidn1mNpyER19p+3hhvrCYs
	Puj/ZqSifHuBoUXwVtn1zqYheZdp13ZpTae5GtJ2kACmdOfrXOhOodW6dBnqJt7y8RGU
	b2DesnA11ZhM7ZB96KglCESIJwGY3GSH0hmgl9WeIV3tleUI2j1sNYbVYDN7bZu475oV
	QEDQirEHVDaOSbenRgrLnHdExThXIxA6CSpKTmFvm1Fvxcu1NYPdjDmsqo9lDxM9465Z
	LLaA==
X-Gm-Message-State: ALoCoQn7NP4x2WyuVcFsowX1LC9qM26KsQB1ySRsiN2o3qIDvuu1MLKYh1hewVKFOBy2Q+niBYRR
X-Received: by 10.180.198.52 with SMTP id iz20mr8847876wic.60.1418771175494;
	Tue, 16 Dec 2014 15:06:15 -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 jp3sm18658353wid.9.2014.12.16.15.06.13
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 16 Dec 2014 15:06:14 -0800 (PST)
Message-ID: <5490BAE4.5070108@linaro.org>
Date: Tue, 16 Dec 2014 23:06:12 +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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?B?TWloYWkgRG9uyJt1?=
	<mdontu@bitdefender.com>, xen-devel@lists.xen.org
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com>
In-Reply-To: <549095E3.30202@citrix.com>
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 16/12/2014 20:28, Andrew Cooper wrote:
> I suspect you also would be better, and certainly more brief, with
> "run_in_exception_handler(show_stack)" instead, which will just print a
> stack trace, but nothing more.

FIY, run_in_exception_handler doesn't exists on ARM.

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 Dec 16 23:27:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 23:27:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y11W7-0004wV-H9; Tue, 16 Dec 2014 23:26:59 +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 1Y11W6-0004wQ-Sq
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 23:26:58 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	25/8F-02696-2CFB0945; Tue, 16 Dec 2014 23:26:58 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418772417!15474017!1
X-Originating-IP: [131.111.8.140]
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 9712 invoked from network); 16 Dec 2014 23:26:57 -0000
Received: from ppsw-40.csi.cam.ac.uk (HELO ppsw-40.csi.cam.ac.uk)
	(131.111.8.140)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 23:26:57 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-82-25-227-239.glfd.adsl.virginm.net
	([82.25.227.239]:50641 helo=[192.168.1.193])
	by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1Y11W3-0007ER-jH (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 16 Dec 2014 23:26:55 +0000
Message-ID: <5490BFBD.7010809@citrix.com>
Date: Tue, 16 Dec 2014 23:26:53 +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>, =?UTF-8?B?TWloYWkgRG9uyJt1?=
	<mdontu@bitdefender.com>, xen-devel@lists.xen.org
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
In-Reply-To: <5490BAE4.5070108@linaro.org>
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/12/2014 23:06, Julien Grall wrote:
> Hi,
>
> On 16/12/2014 20:28, Andrew Cooper wrote:
>> I suspect you also would be better, and certainly more brief, with
>> "run_in_exception_handler(show_stack)" instead, which will just print a
>> stack trace, but nothing more.
>
> FIY, run_in_exception_handler doesn't exists on ARM.
>
> Regards,
>

In which case it even more lucky that __bug() and __warn() are orphaned
functions, as they don't work correctly on arm.  Even more reason to
remove them.

It doesn't look like run_in_exception_handler() would be hard to add to
arm at all.  It already has broadly similar bug/warn/assert infrastructure.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 23:27:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 23:27:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y11W7-0004wV-H9; Tue, 16 Dec 2014 23:26:59 +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 1Y11W6-0004wQ-Sq
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 23:26:58 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	25/8F-02696-2CFB0945; Tue, 16 Dec 2014 23:26:58 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418772417!15474017!1
X-Originating-IP: [131.111.8.140]
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 9712 invoked from network); 16 Dec 2014 23:26:57 -0000
Received: from ppsw-40.csi.cam.ac.uk (HELO ppsw-40.csi.cam.ac.uk)
	(131.111.8.140)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Dec 2014 23:26:57 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from client-82-25-227-239.glfd.adsl.virginm.net
	([82.25.227.239]:50641 helo=[192.168.1.193])
	by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1:DHE-RSA-AES128-SHA:128)
	id 1Y11W3-0007ER-jH (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 16 Dec 2014 23:26:55 +0000
Message-ID: <5490BFBD.7010809@citrix.com>
Date: Tue, 16 Dec 2014 23:26:53 +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>, =?UTF-8?B?TWloYWkgRG9uyJt1?=
	<mdontu@bitdefender.com>, xen-devel@lists.xen.org
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
In-Reply-To: <5490BAE4.5070108@linaro.org>
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/12/2014 23:06, Julien Grall wrote:
> Hi,
>
> On 16/12/2014 20:28, Andrew Cooper wrote:
>> I suspect you also would be better, and certainly more brief, with
>> "run_in_exception_handler(show_stack)" instead, which will just print a
>> stack trace, but nothing more.
>
> FIY, run_in_exception_handler doesn't exists on ARM.
>
> Regards,
>

In which case it even more lucky that __bug() and __warn() are orphaned
functions, as they don't work correctly on arm.  Even more reason to
remove them.

It doesn't look like run_in_exception_handler() would be hard to add to
arm at all.  It already has broadly similar bug/warn/assert infrastructure.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 16 23:37:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 23: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 1Y11gE-0005LN-Lm; Tue, 16 Dec 2014 23:37:26 +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 1Y11gD-0005LI-3H
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 23:37:25 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	CD/06-22777-432C0945; Tue, 16 Dec 2014 23:37:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418773042!13721888!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30631 invoked from network); 16 Dec 2014 23:37:22 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 23:37:22 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so14274974wiw.4
	for <xen-devel@lists.xen.org>; Tue, 16 Dec 2014 15:37: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=UqYRsVNUz98JOXhn5d+UvqnunHbrP62ff8RVIrcqwFE=;
	b=hH47iAHoi63e3mlMysdvhAI1g+oXgpuS9M3V0p87GPerJ1D7PAk8mUc4rvSEcPACUn
	bb3HR63mz4Z97/zBrp9NPoj0aPoYWnPKj09Eua4noUK7rM870nASTP+ovvDGcFPiUfrn
	5Y74w4DXpTN4u15N5kJ4yBXU76kwjwlgc0xEl3KIKrBHs+YvU2F5WAO5UMsdtdkSCwi6
	8vysJAIxARQryFdZ8LwSgXSHxzHcu6hD7dp1B4HlCrZE6CCt2Dbb4GCvaZBc4i92TzzM
	URHMB+UJBCYG2PM+QfM7Ney8RE5sYSTIMHOYTuLlCGbNMdg6OZuPTCl9qOIZt9YjlULo
	pPcw==
X-Gm-Message-State: ALoCoQmR0v9rU/CWxBXHkYz62cfw8AgEi1Ntr8ehPrfYOpgUM4UB+5ZdYnV1gUSGbV3uNGZ5sfCL
X-Received: by 10.194.222.34 with SMTP id qj2mr67503742wjc.80.1418773042051;
	Tue, 16 Dec 2014 15:37: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
	gs10sm4820778wib.12.2014.12.16.15.37.20
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 16 Dec 2014 15:37:21 -0800 (PST)
Message-ID: <5490C22F.4020505@linaro.org>
Date: Tue, 16 Dec 2014 23:37: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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?B?TWloYWkgRG9uyJt1?=
	<mdontu@bitdefender.com>, xen-devel@lists.xen.org
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
	<5490BFBD.7010809@citrix.com>
In-Reply-To: <5490BFBD.7010809@citrix.com>
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 16/12/2014 23:26, Andrew Cooper wrote:
> On 16/12/2014 23:06, Julien Grall wrote:
>> Hi,
>>
>> On 16/12/2014 20:28, Andrew Cooper wrote:
>>> I suspect you also would be better, and certainly more brief, with
>>> "run_in_exception_handler(show_stack)" instead, which will just print a
>>> stack trace, but nothing more.
>>
>> FIY, run_in_exception_handler doesn't exists on ARM.
>>
>> Regards,
>>
>
> In which case it even more lucky that __bug() and __warn() are orphaned
> functions, as they don't work correctly on arm.  Even more reason to
> remove them.
>
> It doesn't look like run_in_exception_handler() would be hard to add to
> arm at all.  It already has broadly similar bug/warn/assert infrastructure.

It's more difficult than you think. For ARM we had to use a different 
infrastructure than x86 to setup the BUG_FRAME. This is because %c is 
not correctly support on most ARM compiler today.

So I don't think it worth to spend time on it just for one call.

How about introducing dump_stack() which would call 
run_in_exception_handler() on x86 and something different (maybe a new 
BUG_FRAME type) on ARM?

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 Dec 16 23:37:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Dec 2014 23: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 1Y11gE-0005LN-Lm; Tue, 16 Dec 2014 23:37:26 +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 1Y11gD-0005LI-3H
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 23:37:25 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	CD/06-22777-432C0945; Tue, 16 Dec 2014 23:37:24 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418773042!13721888!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30631 invoked from network); 16 Dec 2014 23:37:22 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 23:37:22 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so14274974wiw.4
	for <xen-devel@lists.xen.org>; Tue, 16 Dec 2014 15:37: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=UqYRsVNUz98JOXhn5d+UvqnunHbrP62ff8RVIrcqwFE=;
	b=hH47iAHoi63e3mlMysdvhAI1g+oXgpuS9M3V0p87GPerJ1D7PAk8mUc4rvSEcPACUn
	bb3HR63mz4Z97/zBrp9NPoj0aPoYWnPKj09Eua4noUK7rM870nASTP+ovvDGcFPiUfrn
	5Y74w4DXpTN4u15N5kJ4yBXU76kwjwlgc0xEl3KIKrBHs+YvU2F5WAO5UMsdtdkSCwi6
	8vysJAIxARQryFdZ8LwSgXSHxzHcu6hD7dp1B4HlCrZE6CCt2Dbb4GCvaZBc4i92TzzM
	URHMB+UJBCYG2PM+QfM7Ney8RE5sYSTIMHOYTuLlCGbNMdg6OZuPTCl9qOIZt9YjlULo
	pPcw==
X-Gm-Message-State: ALoCoQmR0v9rU/CWxBXHkYz62cfw8AgEi1Ntr8ehPrfYOpgUM4UB+5ZdYnV1gUSGbV3uNGZ5sfCL
X-Received: by 10.194.222.34 with SMTP id qj2mr67503742wjc.80.1418773042051;
	Tue, 16 Dec 2014 15:37: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
	gs10sm4820778wib.12.2014.12.16.15.37.20
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 16 Dec 2014 15:37:21 -0800 (PST)
Message-ID: <5490C22F.4020505@linaro.org>
Date: Tue, 16 Dec 2014 23:37: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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?B?TWloYWkgRG9uyJt1?=
	<mdontu@bitdefender.com>, xen-devel@lists.xen.org
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
	<5490BFBD.7010809@citrix.com>
In-Reply-To: <5490BFBD.7010809@citrix.com>
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 16/12/2014 23:26, Andrew Cooper wrote:
> On 16/12/2014 23:06, Julien Grall wrote:
>> Hi,
>>
>> On 16/12/2014 20:28, Andrew Cooper wrote:
>>> I suspect you also would be better, and certainly more brief, with
>>> "run_in_exception_handler(show_stack)" instead, which will just print a
>>> stack trace, but nothing more.
>>
>> FIY, run_in_exception_handler doesn't exists on ARM.
>>
>> Regards,
>>
>
> In which case it even more lucky that __bug() and __warn() are orphaned
> functions, as they don't work correctly on arm.  Even more reason to
> remove them.
>
> It doesn't look like run_in_exception_handler() would be hard to add to
> arm at all.  It already has broadly similar bug/warn/assert infrastructure.

It's more difficult than you think. For ARM we had to use a different 
infrastructure than x86 to setup the BUG_FRAME. This is because %c is 
not correctly support on most ARM compiler today.

So I don't think it worth to spend time on it just for one call.

How about introducing dump_stack() which would call 
run_in_exception_handler() on x86 and something different (maybe a new 
BUG_FRAME type) on ARM?

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 Dec 17 01:49:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 01: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 1Y13jR-000455-QB; Wed, 17 Dec 2014 01:48:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y13jQ-000450-7R
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 01:48:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	13/3F-25276-301E0945; Wed, 17 Dec 2014 01:48:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418780929!12642398!1
X-Originating-IP: [66.165.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 21493 invoked from network); 17 Dec 2014 01:48:50 -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;
	17 Dec 2014 01:48:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,590,1413244800"; d="scan'208";a="205641196"
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.210.2; Tue, 16 Dec 2014 20:48: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 1Y13jL-0003Lg-Cb;
	Wed, 17 Dec 2014 01:48:47 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y13jL-0004xp-71;
	Wed, 17 Dec 2014 01:48:47 +0000
Date: Wed, 17 Dec 2014 01:48:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32418-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 13680
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32418: 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="===============7187381886189353724=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7187381886189353724==
Content-Type: text/plain
Content-Length: 13492
Content-Transfer-Encoding: quoted-printable

flight 32418 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32418/

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 32194

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-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-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-armhf-armhf-xl          10 migrate-support-check        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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                54600752a1dd67844c2cf3c467db562c39499838
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Amos Kong <akong@redhat.com>
  Anton Blanchard <anton@samba.org>
  Antony Pavlov <antonynpavlov@gmail.com>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Christoffer Dall <christoffer.dall@linaro.org>
  Dmitry Poletaev <poletaev-qemu@yandex.ru>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gary R Hook <gary.hook@nimboxx.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Jeff Cody <jcody@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  lijun <junmuzi@gmail.com>
  Liviu Ionescu <ilg@livius.net>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael Mueller <mimu@linux.vnet.ibm.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Nikita Belov <zodiac@ispras.ru>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
  Peter Maydell <peter.maydell@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@linux.vnet.ibm.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=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dqemu-mainline
+ revision=3D54600752a1dd67844c2cf3c467db562c39499838
+ . 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-mainline 54600752a1dd67844c2cf3c467db562c39499838
+ branch=3Dqemu-mainline
+ revision=3D54600752a1dd67844c2cf3c467db562c39499838
+ . 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
+ qemuubranch=3Dqemu-mainline
+ '[' xqemuu =3D xlinux ']'
+ linuxbranch=3D
+ '[' xqemu-mainline =3D 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=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-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=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-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 54600752a1dd67844c2cf3c467db562c39499838:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   45e1611..5460075  54600752a1dd67844c2cf3c467db562c39499838 -> mainline/xen-tested-master


--===============7187381886189353724==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7187381886189353724==--

From xen-devel-bounces@lists.xen.org Wed Dec 17 01:49:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 01: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 1Y13jR-000455-QB; Wed, 17 Dec 2014 01:48:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y13jQ-000450-7R
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 01:48:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	13/3F-25276-301E0945; Wed, 17 Dec 2014 01:48:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418780929!12642398!1
X-Originating-IP: [66.165.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 21493 invoked from network); 17 Dec 2014 01:48:50 -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;
	17 Dec 2014 01:48:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,590,1413244800"; d="scan'208";a="205641196"
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.210.2; Tue, 16 Dec 2014 20:48: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 1Y13jL-0003Lg-Cb;
	Wed, 17 Dec 2014 01:48:47 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y13jL-0004xp-71;
	Wed, 17 Dec 2014 01:48:47 +0000
Date: Wed, 17 Dec 2014 01:48:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32418-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 13680
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32418: 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="===============7187381886189353724=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7187381886189353724==
Content-Type: text/plain
Content-Length: 13492
Content-Transfer-Encoding: quoted-printable

flight 32418 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32418/

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 32194

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-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-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-armhf-armhf-xl          10 migrate-support-check        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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                54600752a1dd67844c2cf3c467db562c39499838
baseline version:
 qemuu                45e1611de8be0eae55967694dd6e627c2dc354f2

------------------------------------------------------------
People who touched revisions under test:
  Alex Benn=C3=A9e <alex.bennee@linaro.org>
  Amos Kong <akong@redhat.com>
  Anton Blanchard <anton@samba.org>
  Antony Pavlov <antonynpavlov@gmail.com>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Christoffer Dall <christoffer.dall@linaro.org>
  Dmitry Poletaev <poletaev-qemu@yandex.ru>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Fabian Aggeler <aggelerf@ethz.ch>
  Fam Zheng <famz@redhat.com>
  Gary R Hook <gary.hook@nimboxx.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Greg Bellows <greg.bellows@linaro.org>
  Jeff Cody <jcody@redhat.com>
  Jun Li <junmuzi@gmail.com>
  Kevin Wolf <kwolf@redhat.com>
  lijun <junmuzi@gmail.com>
  Liviu Ionescu <ilg@livius.net>
  Markus Armbruster <armbru@redhat.com>
  Max Reitz <mreitz@redhat.com>
  Michael Mueller <mimu@linux.vnet.ibm.com>
  Michael Tokarev <mjt@tls.msk.ru>
  Nikita Belov <zodiac@ispras.ru>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
  Peter Maydell <peter.maydell@linaro.org>
  Richard Henderson <rth@twiddle.net>
  Sergey Fedorov <s.fedorov@samsung.com>
  Stefan Hajnoczi <stefanha@redhat.com>
  Thomas Huth <thuth@linux.vnet.ibm.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=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dqemu-mainline
+ revision=3D54600752a1dd67844c2cf3c467db562c39499838
+ . 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-mainline 54600752a1dd67844c2cf3c467db562c39499838
+ branch=3Dqemu-mainline
+ revision=3D54600752a1dd67844c2cf3c467db562c39499838
+ . 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
+ qemuubranch=3Dqemu-mainline
+ '[' xqemuu =3D xlinux ']'
+ linuxbranch=3D
+ '[' xqemu-mainline =3D 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=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-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=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-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 54600752a1dd67844c2cf3c467db562c39499838:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   45e1611..5460075  54600752a1dd67844c2cf3c467db562c39499838 -> mainline/xen-tested-master


--===============7187381886189353724==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7187381886189353724==--

From xen-devel-bounces@lists.xen.org Wed Dec 17 07:55:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 07: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 1Y19S4-00032l-3N; Wed, 17 Dec 2014 07:55:20 +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 1Y19S1-00032g-MC
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 07:55:18 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	57/B6-09284-4E631945; Wed, 17 Dec 2014 07:55:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418802915!13838845!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13250 invoked from network); 17 Dec 2014 07:55:15 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 07:55:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418802915; l=1570;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=KAGzjhucesY/w8VR+CyoDfq08jo=;
	b=WbZ3+AX19FYEaLXu0z/BqMv1b6PP+CTKvh7mRKcOMlqIDc0cmjkarCZ70wnX2H1FK81
	1ny/3o/UXs4bGcSrR6DVjt3+mOoLBd85+A5HB6XUxr54i5mBaq+wQ71J6ri3R/Rin6pVD
	6RLu1NAV6QL6byu9TX+48BIPujayi0pOD5Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id D00c53qBH7tB0ab
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 17 Dec 2014 08:55:11 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id E523350161; Wed, 17 Dec 2014 08:55:10 +0100 (CET)
Date: Wed, 17 Dec 2014 08:55:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141217075510.GA678@aepfle.de>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<20141216163451.GA18976@aepfle.de>
	<20141216204601.GA11551@konrad-lan.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141216204601.GA11551@konrad-lan.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, Konrad Rzeszutek Wilk wrote:

> On Tue, Dec 16, 2014 at 05:34:51PM +0100, Olaf Hering wrote:
> > On Tue, Dec 16, konrad.wilk@oracle.com wrote:
> > 
> > > In terms of bugs, we have:
> > 
> > ... systemd SELinux, but its not listed.
> 
> > 
> > Whats your plan with the failures you see? Should I continue to be
> > concerned about that, or will all the be postponed to 4.6?
> 
> I was under the impression you had some patches which would solve a
> majority of the issues? And after the discussion with Ian Jackson the
> way to exec was solved?

No. What I did was to handle XENSTORED_TRACE which is just a bool to
pass "-T /log/file" to xenstored. I think xenstored can not access the
sockets if it was launched with a shell script as it is done now. 
No idea how to solve that. Maybe "/usr/bin/env $XENSTORED" could be a
workaround for the SELinux socket access issue. But perhaps launching it
via env or sh fails either way.

> And for the other - the SELinux context and how to figure this out -
> I thought (I will have to double-check it tomorrow) that I mentioned it might
> make sense to talk to the SELinux maintainers to see if they have any
> recommendation?

For xen-4.5 the easy way would be to remove the context= option and let
people who build from source and who want to use SELinux put the
required options into /etc/fstab. This would also resolve the issue
Anthony is seeing, his mount or kernel does not understand context= at
all. No idea how he got into that state in his Arch Linux installation.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 07:55:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 07: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 1Y19S4-00032l-3N; Wed, 17 Dec 2014 07:55:20 +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 1Y19S1-00032g-MC
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 07:55:18 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	57/B6-09284-4E631945; Wed, 17 Dec 2014 07:55:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418802915!13838845!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13250 invoked from network); 17 Dec 2014 07:55:15 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 07:55:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418802915; l=1570;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=KAGzjhucesY/w8VR+CyoDfq08jo=;
	b=WbZ3+AX19FYEaLXu0z/BqMv1b6PP+CTKvh7mRKcOMlqIDc0cmjkarCZ70wnX2H1FK81
	1ny/3o/UXs4bGcSrR6DVjt3+mOoLBd85+A5HB6XUxr54i5mBaq+wQ71J6ri3R/Rin6pVD
	6RLu1NAV6QL6byu9TX+48BIPujayi0pOD5Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id D00c53qBH7tB0ab
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 17 Dec 2014 08:55:11 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id E523350161; Wed, 17 Dec 2014 08:55:10 +0100 (CET)
Date: Wed, 17 Dec 2014 08:55:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141217075510.GA678@aepfle.de>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<20141216163451.GA18976@aepfle.de>
	<20141216204601.GA11551@konrad-lan.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141216204601.GA11551@konrad-lan.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, Konrad Rzeszutek Wilk wrote:

> On Tue, Dec 16, 2014 at 05:34:51PM +0100, Olaf Hering wrote:
> > On Tue, Dec 16, konrad.wilk@oracle.com wrote:
> > 
> > > In terms of bugs, we have:
> > 
> > ... systemd SELinux, but its not listed.
> 
> > 
> > Whats your plan with the failures you see? Should I continue to be
> > concerned about that, or will all the be postponed to 4.6?
> 
> I was under the impression you had some patches which would solve a
> majority of the issues? And after the discussion with Ian Jackson the
> way to exec was solved?

No. What I did was to handle XENSTORED_TRACE which is just a bool to
pass "-T /log/file" to xenstored. I think xenstored can not access the
sockets if it was launched with a shell script as it is done now. 
No idea how to solve that. Maybe "/usr/bin/env $XENSTORED" could be a
workaround for the SELinux socket access issue. But perhaps launching it
via env or sh fails either way.

> And for the other - the SELinux context and how to figure this out -
> I thought (I will have to double-check it tomorrow) that I mentioned it might
> make sense to talk to the SELinux maintainers to see if they have any
> recommendation?

For xen-4.5 the easy way would be to remove the context= option and let
people who build from source and who want to use SELinux put the
required options into /etc/fstab. This would also resolve the issue
Anthony is seeing, his mount or kernel does not understand context= at
all. No idea how he got into that state in his Arch Linux installation.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 07:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 07:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y19UT-00037s-Kq; Wed, 17 Dec 2014 07:57:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.sivertsen@gmail.com>) id 1Y0zX7-0000uc-1r
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 21:19:53 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	A5/E5-02712-8F1A0945; Tue, 16 Dec 2014 21:19:52 +0000
X-Env-Sender: julian.sivertsen@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418764791!15479357!1
X-Originating-IP: [74.125.82.52]
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 9466 invoked from network); 16 Dec 2014 21:19:51 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 21:19:51 -0000
Received: by mail-wg0-f52.google.com with SMTP id x12so18538601wgg.39
	for <xen-devel@lists.xen.org>; Tue, 16 Dec 2014 13:19:51 -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=Su0I50qd6Stc5pEye/POmeCk7DJ/8RKXdARi/B66KUw=;
	b=WXA/PXmOi8geUayj1/etaLEF543XFih3fJ43y9nqxuUMmqJBm7B74NWZUeYtCOkyaG
	6xPH6hX0YJt1gmnXgzez13+iUs3yhKBGnymMzgfHU5eG1Ezc+kNP6BmdGwOTWMeeBKRB
	4oBfYpKgmKqPRYhAJgaTEiMjQYTSXbBTnWXwuafPQYMp9SjVjj50wfK6AB8C9CyZxi0f
	TA/IssUwEYBUa0hDVkfTfhit2SXKGqK43noK1qXuQstkoFcB/6/A+5uFU4pJM1zPDnGD
	jyJ6fmn7b8WGXTAVr/R0UYxH4DnW6n9d5exIbShlpOMIQdxINlGQGcfnZVFBttTVrsEr
	MyEA==
MIME-Version: 1.0
X-Received: by 10.180.101.200 with SMTP id fi8mr8097331wib.77.1418764791527;
	Tue, 16 Dec 2014 13:19:51 -0800 (PST)
Received: by 10.194.23.66 with HTTP; Tue, 16 Dec 2014 13:19:51 -0800 (PST)
Date: Tue, 16 Dec 2014 22:19:51 +0100
X-Google-Sender-Auth: BOU91R5u8g-zSC2_zdvFgEtHcBI
Message-ID: <CAKGZkHt7b-=1ApG0BrETU2NMAmWnHBmh=EZeJCzoZ8aTtgeDBA@mail.gmail.com>
From: Julian Sivertsen <julian.sivertsen+xen@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Wed, 17 Dec 2014 07:57:49 +0000
Subject: [Xen-devel] Packaging xen 4.5.0 RC4 on Arch Linux
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I am creating an Arch Linux AUR package for Xen 4.5 RC4. As this
doesn't exist and I am playing around with a xen server. Hopefully
I'll be done in time for the test day. (AUR is a package repository
for build scripts that make packages for the Arch Linux package
manager). The idea is to have something that is usable to build a xen
4.5 RC4 system using Arch Linux as the Dom0.

At the moment I have managed to get xen to build from the 4.5 RC4
tarball, using the following commands in the build script:

    PYTHON=/usr/bin/python2 BISON=/bin/true ./configure \
        --prefix=/usr \
        --sbindir=/usr/bin \
        --enable-systemd \
        --disable-debug
    PYTHON=python2 make dist
    dist/install.sh "$pkgdir"

The directory tree at $pkgdir is what gets installed when the
resulting package is installed with the package manager. Installing
this mostly works out of the box, with one problem. The default Arch
Linux kernel does not have SELinux, causing the
var-lib-xenstored.mount unit to fail due to an invalid context. This
can be worked around by removing the context option from the mount
options in that unit file.

I couldn't find out which systemd unit files that are supposed to be
enabled for xen to be properly initialized. I'm guessing that
xen-init-dom0 is important as without it, xl doesn't work at all. The
xendomains service mentions it in the After parameter, but After only
does ordering. Is it correct that xen-init-dom0 should not be started
when starting the xendomains.service? Without xen-init-dom0, the
xendomains service does nothing but spew out errrors on my system.

It would be reallly helpful if could get some pointers on how xen
should be built for packaging into a distribution, and whether I'm on
the right track.


Regards Julian Sivertsen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 07:57:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 07:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y19UT-00037s-Kq; Wed, 17 Dec 2014 07:57:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.sivertsen@gmail.com>) id 1Y0zX7-0000uc-1r
	for xen-devel@lists.xen.org; Tue, 16 Dec 2014 21:19:53 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	A5/E5-02712-8F1A0945; Tue, 16 Dec 2014 21:19:52 +0000
X-Env-Sender: julian.sivertsen@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418764791!15479357!1
X-Originating-IP: [74.125.82.52]
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 9466 invoked from network); 16 Dec 2014 21:19:51 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Dec 2014 21:19:51 -0000
Received: by mail-wg0-f52.google.com with SMTP id x12so18538601wgg.39
	for <xen-devel@lists.xen.org>; Tue, 16 Dec 2014 13:19:51 -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=Su0I50qd6Stc5pEye/POmeCk7DJ/8RKXdARi/B66KUw=;
	b=WXA/PXmOi8geUayj1/etaLEF543XFih3fJ43y9nqxuUMmqJBm7B74NWZUeYtCOkyaG
	6xPH6hX0YJt1gmnXgzez13+iUs3yhKBGnymMzgfHU5eG1Ezc+kNP6BmdGwOTWMeeBKRB
	4oBfYpKgmKqPRYhAJgaTEiMjQYTSXbBTnWXwuafPQYMp9SjVjj50wfK6AB8C9CyZxi0f
	TA/IssUwEYBUa0hDVkfTfhit2SXKGqK43noK1qXuQstkoFcB/6/A+5uFU4pJM1zPDnGD
	jyJ6fmn7b8WGXTAVr/R0UYxH4DnW6n9d5exIbShlpOMIQdxINlGQGcfnZVFBttTVrsEr
	MyEA==
MIME-Version: 1.0
X-Received: by 10.180.101.200 with SMTP id fi8mr8097331wib.77.1418764791527;
	Tue, 16 Dec 2014 13:19:51 -0800 (PST)
Received: by 10.194.23.66 with HTTP; Tue, 16 Dec 2014 13:19:51 -0800 (PST)
Date: Tue, 16 Dec 2014 22:19:51 +0100
X-Google-Sender-Auth: BOU91R5u8g-zSC2_zdvFgEtHcBI
Message-ID: <CAKGZkHt7b-=1ApG0BrETU2NMAmWnHBmh=EZeJCzoZ8aTtgeDBA@mail.gmail.com>
From: Julian Sivertsen <julian.sivertsen+xen@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Wed, 17 Dec 2014 07:57:49 +0000
Subject: [Xen-devel] Packaging xen 4.5.0 RC4 on Arch Linux
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I am creating an Arch Linux AUR package for Xen 4.5 RC4. As this
doesn't exist and I am playing around with a xen server. Hopefully
I'll be done in time for the test day. (AUR is a package repository
for build scripts that make packages for the Arch Linux package
manager). The idea is to have something that is usable to build a xen
4.5 RC4 system using Arch Linux as the Dom0.

At the moment I have managed to get xen to build from the 4.5 RC4
tarball, using the following commands in the build script:

    PYTHON=/usr/bin/python2 BISON=/bin/true ./configure \
        --prefix=/usr \
        --sbindir=/usr/bin \
        --enable-systemd \
        --disable-debug
    PYTHON=python2 make dist
    dist/install.sh "$pkgdir"

The directory tree at $pkgdir is what gets installed when the
resulting package is installed with the package manager. Installing
this mostly works out of the box, with one problem. The default Arch
Linux kernel does not have SELinux, causing the
var-lib-xenstored.mount unit to fail due to an invalid context. This
can be worked around by removing the context option from the mount
options in that unit file.

I couldn't find out which systemd unit files that are supposed to be
enabled for xen to be properly initialized. I'm guessing that
xen-init-dom0 is important as without it, xl doesn't work at all. The
xendomains service mentions it in the After parameter, but After only
does ordering. Is it correct that xen-init-dom0 should not be started
when starting the xendomains.service? Without xen-init-dom0, the
xendomains service does nothing but spew out errrors on my system.

It would be reallly helpful if could get some pointers on how xen
should be built for packaging into a distribution, and whether I'm on
the right track.


Regards Julian Sivertsen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 08:01:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 08: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 1Y19Y5-0003l9-9d; Wed, 17 Dec 2014 08:01:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Y19Y4-0003l1-3E
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 08:01:32 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	0D/60-23865-B5831945; Wed, 17 Dec 2014 08:01:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418803290!10198203!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28277 invoked from network); 17 Dec 2014 08:01:31 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 08:01:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418803290; l=464;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=t0/6saNlfXGRhKhA063UsaJLv1g=;
	b=Ecq7p4ICr7d7O5LbY4ge5D0TLhFSN9xgDCog3tSStl5e30si+4Nbp9A5uNwn+3S4PMh
	ZcwunWtxmSdBeFvNYZ3GzQbolRRKjWL2j3NVZthYDxhRwOF3WPO530GrdhKm876xMg8O/
	t0ylBiYjIVZD1Ox2CSNZjY3yGFYaUE31gfo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id z03c9cqBH81UwpE
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 17 Dec 2014 09:01:30 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 7964750161; Wed, 17 Dec 2014 09:01:30 +0100 (CET)
Date: Wed, 17 Dec 2014 09:01:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Julian Sivertsen <julian.sivertsen+xen@gmail.com>
Message-ID: <20141217080130.GA1680@aepfle.de>
References: <CAKGZkHt7b-=1ApG0BrETU2NMAmWnHBmh=EZeJCzoZ8aTtgeDBA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKGZkHt7b-=1ApG0BrETU2NMAmWnHBmh=EZeJCzoZ8aTtgeDBA@mail.gmail.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Packaging xen 4.5.0 RC4 on Arch Linux
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, Julian Sivertsen wrote:

> The default Arch Linux kernel does not have SELinux, causing the
> var-lib-xenstored.mount unit to fail due to an invalid context. This
> can be worked around by removing the context option from the mount
> options in that unit file.

Mine does not have SELinux either and context= is handled. But maybe I'm
just lucky. Please confirm that the lack of SELinux is really the cause
for the mount failure.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 08:01:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 08: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 1Y19Y5-0003l9-9d; Wed, 17 Dec 2014 08:01:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Y19Y4-0003l1-3E
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 08:01:32 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	0D/60-23865-B5831945; Wed, 17 Dec 2014 08:01:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418803290!10198203!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODk3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28277 invoked from network); 17 Dec 2014 08:01:31 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.161)
	by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 08:01:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418803290; l=464;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=t0/6saNlfXGRhKhA063UsaJLv1g=;
	b=Ecq7p4ICr7d7O5LbY4ge5D0TLhFSN9xgDCog3tSStl5e30si+4Nbp9A5uNwn+3S4PMh
	ZcwunWtxmSdBeFvNYZ3GzQbolRRKjWL2j3NVZthYDxhRwOF3WPO530GrdhKm876xMg8O/
	t0ylBiYjIVZD1Ox2CSNZjY3yGFYaUE31gfo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id z03c9cqBH81UwpE
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 17 Dec 2014 09:01:30 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 7964750161; Wed, 17 Dec 2014 09:01:30 +0100 (CET)
Date: Wed, 17 Dec 2014 09:01:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Julian Sivertsen <julian.sivertsen+xen@gmail.com>
Message-ID: <20141217080130.GA1680@aepfle.de>
References: <CAKGZkHt7b-=1ApG0BrETU2NMAmWnHBmh=EZeJCzoZ8aTtgeDBA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKGZkHt7b-=1ApG0BrETU2NMAmWnHBmh=EZeJCzoZ8aTtgeDBA@mail.gmail.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Packaging xen 4.5.0 RC4 on Arch Linux
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, Julian Sivertsen wrote:

> The default Arch Linux kernel does not have SELinux, causing the
> var-lib-xenstored.mount unit to fail due to an invalid context. This
> can be worked around by removing the context option from the mount
> options in that unit file.

Mine does not have SELinux either and context= is handled. But maybe I'm
just lucky. Please confirm that the lack of SELinux is really the cause
for the mount failure.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 08:02:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 08: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 1Y19Yt-0003zR-Qb; Wed, 17 Dec 2014 08:02:23 +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 1Y19Yq-0003zC-Vq
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 08:02:21 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	4C/5F-03148-C8831945; Wed, 17 Dec 2014 08:02:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418803339!15550429!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1748 invoked from network); 17 Dec 2014 08:02:19 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 08:02:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418803339; l=264;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=4Ap5cbgqRKeWouIloOiIY2x+ueo=;
	b=Nf9qcxBP8D2+IttC1Cd5q5BnSnpzspkMbzQkWsU5AK9MMU0l3HBdel3PxayjMxcJi6N
	eKdiLRDK5c8L2hmi3GQ9Bo6AENAJcmJYg8MQZ6SFB3LF8QcwrcZ/spStkdTvwhNYuYwef
	cklAqXnXfRlyKo/EruL01ygRnogxrcPyPG8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id K00c8aqBH82Jzo8
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 17 Dec 2014 09:02:19 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 41C6F50161; Wed, 17 Dec 2014 09:02:19 +0100 (CET)
Date: Wed, 17 Dec 2014 09:02:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Julian Sivertsen <julian.sivertsen+xen@gmail.com>
Message-ID: <20141217080219.GA2332@aepfle.de>
References: <CAKGZkHt7b-=1ApG0BrETU2NMAmWnHBmh=EZeJCzoZ8aTtgeDBA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKGZkHt7b-=1ApG0BrETU2NMAmWnHBmh=EZeJCzoZ8aTtgeDBA@mail.gmail.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Packaging xen 4.5.0 RC4 on Arch Linux
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, Julian Sivertsen wrote:

> It would be reallly helpful if could get some pointers on how xen
> should be built for packaging into a distribution, and whether I'm on
> the right track.

See the INSTALL file in the toplevel directory.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 08:02:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 08: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 1Y19Yt-0003zR-Qb; Wed, 17 Dec 2014 08:02:23 +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 1Y19Yq-0003zC-Vq
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 08:02:21 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	4C/5F-03148-C8831945; Wed, 17 Dec 2014 08:02:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418803339!15550429!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1748 invoked from network); 17 Dec 2014 08:02:19 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.218)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 08:02:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418803339; l=264;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=4Ap5cbgqRKeWouIloOiIY2x+ueo=;
	b=Nf9qcxBP8D2+IttC1Cd5q5BnSnpzspkMbzQkWsU5AK9MMU0l3HBdel3PxayjMxcJi6N
	eKdiLRDK5c8L2hmi3GQ9Bo6AENAJcmJYg8MQZ6SFB3LF8QcwrcZ/spStkdTvwhNYuYwef
	cklAqXnXfRlyKo/EruL01ygRnogxrcPyPG8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id K00c8aqBH82Jzo8
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Wed, 17 Dec 2014 09:02:19 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 41C6F50161; Wed, 17 Dec 2014 09:02:19 +0100 (CET)
Date: Wed, 17 Dec 2014 09:02:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Julian Sivertsen <julian.sivertsen+xen@gmail.com>
Message-ID: <20141217080219.GA2332@aepfle.de>
References: <CAKGZkHt7b-=1ApG0BrETU2NMAmWnHBmh=EZeJCzoZ8aTtgeDBA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKGZkHt7b-=1ApG0BrETU2NMAmWnHBmh=EZeJCzoZ8aTtgeDBA@mail.gmail.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Packaging xen 4.5.0 RC4 on Arch Linux
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, Julian Sivertsen wrote:

> It would be reallly helpful if could get some pointers on how xen
> should be built for packaging into a distribution, and whether I'm on
> the right track.

See the INSTALL file in the toplevel directory.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 08:19:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 08: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 1Y19p7-0004PU-Og; Wed, 17 Dec 2014 08:19:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bob.liu@oracle.com>) id 1Y19p6-0004PP-VQ
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 08:19:09 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	1A/A9-02954-C7C31945; Wed, 17 Dec 2014 08:19:08 +0000
X-Env-Sender: bob.liu@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418804346!15589670!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15935 invoked from network); 17 Dec 2014 08:19:07 -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; 17 Dec 2014 08:19:07 -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 sBH8J4Jd017336
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 08:19:04 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
	sBH8J2vr021453
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 08:19:03 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
	sBH8J2lR026216; Wed, 17 Dec 2014 08:19:02 GMT
Received: from [10.191.0.135] (/10.191.0.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 00:19:02 -0800
Message-ID: <54913C72.7090704@oracle.com>
Date: Wed, 17 Dec 2014 16:18:58 +0800
From: Bob Liu <bob.liu@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
References: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>
	<54900A3F.7070300@citrix.com>
In-Reply-To: <54900A3F.7070300@citrix.com>
Content-Length: 1641
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: increase the default value of
 xen_blkif_max_segments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 12/16/2014 06:32 PM, Roger Pau Monn=E9 wrote:
> El 16/12/14 a les 11.11, Bob Liu ha escrit:
>> The default maximum value of segments in indirect requests was 32, IO
>> operations with bigger block size(>32*4k) would be split and performance=
 start
>> to drop.
>>
>> Nowadays backend device usually support 512k max_sectors_kb on desktop, =
and
>> may larger on server machines with high-end storage system.
>> The default size 128k was not very appropriate, this patch increases the=
 default
>> maximum value to 128(128*4k=3D512k).
> =

> This looks fine, do you have any data/graphs to backup your reasoning?
> =


I only have some results for 1M block size FIO test but I think that's
enough.

xen_blkfront.max 	Rate (MB/s) 	Percent of Dom-0
32 	11.1 	31.0%
48 	15.3 	42.7%
64 	19.8 	55.3%
80 	19.9 	55.6%
96 	23.0 	64.2%
112 	23.7 	66.2%
128 	31.6 	88.3%

The rates above are compared against the dom-0 rate of 35.8 MB/s.

> I would also add to the commit message that this change implies we can
> now have 32*128+32 =3D 4128 in-flight grants, which greatly surpasses the

The number could be larger if using more pages as the
xen-blkfront/backend ring based on Wei Liu's patch "xenbus_client:
extend interface to suppurt multi-page ring", it helped improve the IO
performance a lot on our system connected with high-end storage.
I'm preparing resend related patches.

> default amount of persistent grants blkback can handle, so the LRU in
> blkback will kick in.
> =


Sounds good.

-- =

Regards,
-Bob

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 08:19:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 08: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 1Y19p7-0004PU-Og; Wed, 17 Dec 2014 08:19:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bob.liu@oracle.com>) id 1Y19p6-0004PP-VQ
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 08:19:09 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	1A/A9-02954-C7C31945; Wed, 17 Dec 2014 08:19:08 +0000
X-Env-Sender: bob.liu@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418804346!15589670!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15935 invoked from network); 17 Dec 2014 08:19:07 -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; 17 Dec 2014 08:19:07 -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 sBH8J4Jd017336
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 08:19:04 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
	sBH8J2vr021453
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 08:19:03 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
	sBH8J2lR026216; Wed, 17 Dec 2014 08:19:02 GMT
Received: from [10.191.0.135] (/10.191.0.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 00:19:02 -0800
Message-ID: <54913C72.7090704@oracle.com>
Date: Wed, 17 Dec 2014 16:18:58 +0800
From: Bob Liu <bob.liu@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
References: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>
	<54900A3F.7070300@citrix.com>
In-Reply-To: <54900A3F.7070300@citrix.com>
Content-Length: 1641
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: increase the default value of
 xen_blkif_max_segments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 12/16/2014 06:32 PM, Roger Pau Monn=E9 wrote:
> El 16/12/14 a les 11.11, Bob Liu ha escrit:
>> The default maximum value of segments in indirect requests was 32, IO
>> operations with bigger block size(>32*4k) would be split and performance=
 start
>> to drop.
>>
>> Nowadays backend device usually support 512k max_sectors_kb on desktop, =
and
>> may larger on server machines with high-end storage system.
>> The default size 128k was not very appropriate, this patch increases the=
 default
>> maximum value to 128(128*4k=3D512k).
> =

> This looks fine, do you have any data/graphs to backup your reasoning?
> =


I only have some results for 1M block size FIO test but I think that's
enough.

xen_blkfront.max 	Rate (MB/s) 	Percent of Dom-0
32 	11.1 	31.0%
48 	15.3 	42.7%
64 	19.8 	55.3%
80 	19.9 	55.6%
96 	23.0 	64.2%
112 	23.7 	66.2%
128 	31.6 	88.3%

The rates above are compared against the dom-0 rate of 35.8 MB/s.

> I would also add to the commit message that this change implies we can
> now have 32*128+32 =3D 4128 in-flight grants, which greatly surpasses the

The number could be larger if using more pages as the
xen-blkfront/backend ring based on Wei Liu's patch "xenbus_client:
extend interface to suppurt multi-page ring", it helped improve the IO
performance a lot on our system connected with high-end storage.
I'm preparing resend related patches.

> default amount of persistent grants blkback can handle, so the LRU in
> blkback will kick in.
> =


Sounds good.

-- =

Regards,
-Bob

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 09:15:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 09: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 1Y1Agc-0005fO-JO; Wed, 17 Dec 2014 09:14:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <freddy77@gmail.com>) id 1Y1Agb-0005fJ-3I
	for Xen-devel@lists.xen.org; Wed, 17 Dec 2014 09:14:25 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	61/65-16982-07941945; Wed, 17 Dec 2014 09:14:24 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418807662!13936941!1
X-Originating-IP: [209.85.220.176]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1018 invoked from network); 17 Dec 2014 09:14:23 -0000
Received: from mail-vc0-f176.google.com (HELO mail-vc0-f176.google.com)
	(209.85.220.176)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 09:14:23 -0000
Received: by mail-vc0-f176.google.com with SMTP id hq12so6931216vcb.21
	for <Xen-devel@lists.xen.org>; Wed, 17 Dec 2014 01:14: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=Ehcf8BBGs3IRUkIPNT5CcoQRrTBMCYX60+EqisLVSRQ=;
	b=TMef8Vi7uoFoRk3mYdw3vLh8GhJMvxJjIOh6/nIKXIPOiv/+YgXqZjIHMphfPp/gkC
	wvDhmnifwTOrq/7NdXBy/Pip8cFA4mdLSKAR7FXNB91ddxZYM3I0src6oTYmCHcoc4Cm
	DGAkKf4xS6DDKDwidjz3EerETGbxkp7fn+2O7LbGfU8aNNlbbkOkPT34MbsHYY6GgUjo
	Edr4XsU5WtSLFmwJteaQ7ILTuwpvVMlQOBZ5SJi25OB90jJVM5AtN7JV3O75Q5mCG26Z
	GEI8SrsjN8imzBP426bIrIUbFnTKWXEkNVzQv0cF6yiuutJ2vZL/XvUKju5yUyoTYRws
	jkYw==
MIME-Version: 1.0
X-Received: by 10.52.29.172 with SMTP id l12mr21010755vdh.33.1418807662034;
	Wed, 17 Dec 2014 01:14:22 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Wed, 17 Dec 2014 01:14:21 -0800 (PST)
In-Reply-To: <CAHt6W4e6mR4cX1MfpJ+drupzzRHjf0SHaJ=y5QRZxh84mq5rBA@mail.gmail.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418747029.16425.238.camel@citrix.com>
	<CAHt6W4e6mR4cX1MfpJ+drupzzRHjf0SHaJ=y5QRZxh84mq5rBA@mail.gmail.com>
Date: Wed, 17 Dec 2014 09:14:21 +0000
Message-ID: <CAHt6W4dnDwFpb3CV73JOejjgiVCJuNxE3wX5s3vGKiujAuM1Hg@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Philipp Hahn <hahn@univention.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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

2014-12-16 16:44 GMT+00:00 Frediano Ziglio <freddy77@gmail.com>:
> 2014-12-16 16:23 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
>> On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
>>> What does "info all-registers" gdb command say about SSE registers?
>>
>> All zeroes. No ffs anywhere.
>>
>
> Could be that core does not dump these registers for some reasons? On
> my machine I got some FFs even just before the main is reached.
>
>>> Do we have a bug in Xen that affect SSE instructions (possibly already
>>> fixed after Philipp version) ?
>>
>> Possibly. When this was thought to be xenstored (which doesn't change
>> all that much) debugging 4.1 seemed plausible, but since it could be
>> anywhere else I think we either need a plausible reproduction, or a
>> repro on a newer hypervisor (or possibly kernel) I'm afraid.
>>
>> Ian.
>>
>
> I found these
>
> 1) https://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.2.8
> 2) https://sourceware.org/bugzilla/show_bug.cgi?id=16064
>
> 1 seems to indicate a problem with kernel 3.2. Second with glibc 2.18.
>
> First we (I'll try when I reach home) can check if memset in glibc (or
> the version called from talloc_zero) can use SSE. A possible dmesg
> output and /proc/cpuinfo content could help too but I think SSE are
> now quite common.
>

I have access to some core dumps. glibc memset is using SSE,
specifically xmm0 register.

Unfortunately is seems that core dumps contains only standard
registers, so all register appears zeroed. If you try with a newer gdb
version is shows that registers are not available.

> For the reproduction could be that a program doing some memset(0)
> continuously while another fill SSE register with garbage could
> help... at least if they execute on the same CPU (so could be limiting
> Xen to one CPU). Also doing some FPU operation which could lead to
> exception could help too.
>

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 09:15:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 09: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 1Y1Agc-0005fO-JO; Wed, 17 Dec 2014 09:14:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <freddy77@gmail.com>) id 1Y1Agb-0005fJ-3I
	for Xen-devel@lists.xen.org; Wed, 17 Dec 2014 09:14:25 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	61/65-16982-07941945; Wed, 17 Dec 2014 09:14:24 +0000
X-Env-Sender: freddy77@gmail.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418807662!13936941!1
X-Originating-IP: [209.85.220.176]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1018 invoked from network); 17 Dec 2014 09:14:23 -0000
Received: from mail-vc0-f176.google.com (HELO mail-vc0-f176.google.com)
	(209.85.220.176)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 09:14:23 -0000
Received: by mail-vc0-f176.google.com with SMTP id hq12so6931216vcb.21
	for <Xen-devel@lists.xen.org>; Wed, 17 Dec 2014 01:14: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=Ehcf8BBGs3IRUkIPNT5CcoQRrTBMCYX60+EqisLVSRQ=;
	b=TMef8Vi7uoFoRk3mYdw3vLh8GhJMvxJjIOh6/nIKXIPOiv/+YgXqZjIHMphfPp/gkC
	wvDhmnifwTOrq/7NdXBy/Pip8cFA4mdLSKAR7FXNB91ddxZYM3I0src6oTYmCHcoc4Cm
	DGAkKf4xS6DDKDwidjz3EerETGbxkp7fn+2O7LbGfU8aNNlbbkOkPT34MbsHYY6GgUjo
	Edr4XsU5WtSLFmwJteaQ7ILTuwpvVMlQOBZ5SJi25OB90jJVM5AtN7JV3O75Q5mCG26Z
	GEI8SrsjN8imzBP426bIrIUbFnTKWXEkNVzQv0cF6yiuutJ2vZL/XvUKju5yUyoTYRws
	jkYw==
MIME-Version: 1.0
X-Received: by 10.52.29.172 with SMTP id l12mr21010755vdh.33.1418807662034;
	Wed, 17 Dec 2014 01:14:22 -0800 (PST)
Received: by 10.52.132.97 with HTTP; Wed, 17 Dec 2014 01:14:21 -0800 (PST)
In-Reply-To: <CAHt6W4e6mR4cX1MfpJ+drupzzRHjf0SHaJ=y5QRZxh84mq5rBA@mail.gmail.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418747029.16425.238.camel@citrix.com>
	<CAHt6W4e6mR4cX1MfpJ+drupzzRHjf0SHaJ=y5QRZxh84mq5rBA@mail.gmail.com>
Date: Wed, 17 Dec 2014 09:14:21 +0000
Message-ID: <CAHt6W4dnDwFpb3CV73JOejjgiVCJuNxE3wX5s3vGKiujAuM1Hg@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Philipp Hahn <hahn@univention.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	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

2014-12-16 16:44 GMT+00:00 Frediano Ziglio <freddy77@gmail.com>:
> 2014-12-16 16:23 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
>> On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
>>> What does "info all-registers" gdb command say about SSE registers?
>>
>> All zeroes. No ffs anywhere.
>>
>
> Could be that core does not dump these registers for some reasons? On
> my machine I got some FFs even just before the main is reached.
>
>>> Do we have a bug in Xen that affect SSE instructions (possibly already
>>> fixed after Philipp version) ?
>>
>> Possibly. When this was thought to be xenstored (which doesn't change
>> all that much) debugging 4.1 seemed plausible, but since it could be
>> anywhere else I think we either need a plausible reproduction, or a
>> repro on a newer hypervisor (or possibly kernel) I'm afraid.
>>
>> Ian.
>>
>
> I found these
>
> 1) https://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.2.8
> 2) https://sourceware.org/bugzilla/show_bug.cgi?id=16064
>
> 1 seems to indicate a problem with kernel 3.2. Second with glibc 2.18.
>
> First we (I'll try when I reach home) can check if memset in glibc (or
> the version called from talloc_zero) can use SSE. A possible dmesg
> output and /proc/cpuinfo content could help too but I think SSE are
> now quite common.
>

I have access to some core dumps. glibc memset is using SSE,
specifically xmm0 register.

Unfortunately is seems that core dumps contains only standard
registers, so all register appears zeroed. If you try with a newer gdb
version is shows that registers are not available.

> For the reproduction could be that a program doing some memset(0)
> continuously while another fill SSE register with garbage could
> help... at least if they execute on the same CPU (so could be limiting
> Xen to one CPU). Also doing some FPU operation which could lead to
> exception could help too.
>

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 09:51:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 09:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BFn-0006Lv-OM; Wed, 17 Dec 2014 09:50: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 1Y1BFl-0006LD-HT
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 09:50:45 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	7D/F0-22819-4F151945; Wed, 17 Dec 2014 09:50:44 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418809843!10454389!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 16776 invoked from network); 17 Dec 2014 09:50:44 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Dec 2014 09:50:44 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 94390ADB8;
	Wed, 17 Dec 2014 09:50:43 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Wed, 17 Dec 2014 10:50:37 +0100
Message-Id: <1418809838-14123-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418809838-14123-1-git-send-email-jgross@suse.com>
References: <1418809838-14123-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [Patch V2 3/4] xen: use generated hypervisor symbols in
	arch/x86/xen/trace.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 manually list all hypervisor calls in arch/x86/xen/trace.c
use the auto generated list.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/trace.c | 50 ++++----------------------------------------------
 1 file changed, 4 insertions(+), 46 deletions(-)

diff --git a/arch/x86/xen/trace.c b/arch/x86/xen/trace.c
index 8296cdf..a702ec2 100644
--- a/arch/x86/xen/trace.c
+++ b/arch/x86/xen/trace.c
@@ -1,54 +1,12 @@
 #include <linux/ftrace.h>
 #include <xen/interface/xen.h>
+#include <xen/interface/xen-mca.h>
 
-#define N(x)	[__HYPERVISOR_##x] = "("#x")"
+#define HYPERCALL(x)	[__HYPERVISOR_##x] = "("#x")",
 static const char *xen_hypercall_names[] = {
-	N(set_trap_table),
-	N(mmu_update),
-	N(set_gdt),
-	N(stack_switch),
-	N(set_callbacks),
-	N(fpu_taskswitch),
-	N(sched_op_compat),
-	N(dom0_op),
-	N(set_debugreg),
-	N(get_debugreg),
-	N(update_descriptor),
-	N(memory_op),
-	N(multicall),
-	N(update_va_mapping),
-	N(set_timer_op),
-	N(event_channel_op_compat),
-	N(xen_version),
-	N(console_io),
-	N(physdev_op_compat),
-	N(grant_table_op),
-	N(vm_assist),
-	N(update_va_mapping_otherdomain),
-	N(iret),
-	N(vcpu_op),
-	N(set_segment_base),
-	N(mmuext_op),
-	N(xsm_op),
-	N(nmi_op),
-	N(sched_op),
-	N(callback_op),
-	N(xenoprof_op),
-	N(event_channel_op),
-	N(physdev_op),
-	N(hvm_op),
-
-/* Architecture-specific hypercall definitions. */
-	N(arch_0),
-	N(arch_1),
-	N(arch_2),
-	N(arch_3),
-	N(arch_4),
-	N(arch_5),
-	N(arch_6),
-	N(arch_7),
+#include <asm/xen-hypercalls.h>
 };
-#undef N
+#undef HYPERCALL
 
 static const char *xen_hypercall_name(unsigned op)
 {
-- 
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 Dec 17 09:51:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 09:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BFl-0006LN-LM; Wed, 17 Dec 2014 09:50:45 +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 1Y1BFk-0006LB-Op
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 09:50:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6A/D8-09842-4F151945; Wed, 17 Dec 2014 09:50:44 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418809843!15807822!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 20457 invoked from network); 17 Dec 2014 09:50:43 -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; 17 Dec 2014 09:50:43 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3BCB6ADB5;
	Wed, 17 Dec 2014 09:50:43 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Wed, 17 Dec 2014 10:50:36 +0100
Message-Id: <1418809838-14123-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418809838-14123-1-git-send-email-jgross@suse.com>
References: <1418809838-14123-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [Patch V2 2/4] xen: synchronize
	include/xen/interface/xen.h with xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The header include/xen/interface/xen.h doesn't contain all definitions
from Xen's version of that header. Update it accordingly.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/trace.c        | 2 +-
 include/xen/interface/xen.h | 6 +++++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/trace.c b/arch/x86/xen/trace.c
index 520022d..8296cdf 100644
--- a/arch/x86/xen/trace.c
+++ b/arch/x86/xen/trace.c
@@ -29,7 +29,7 @@ static const char *xen_hypercall_names[] = {
 	N(vcpu_op),
 	N(set_segment_base),
 	N(mmuext_op),
-	N(acm_op),
+	N(xsm_op),
 	N(nmi_op),
 	N(sched_op),
 	N(callback_op),
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index f68719f..a483789 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -67,7 +67,7 @@
 #define __HYPERVISOR_vcpu_op              24
 #define __HYPERVISOR_set_segment_base     25 /* x86/64 only */
 #define __HYPERVISOR_mmuext_op            26
-#define __HYPERVISOR_acm_op               27
+#define __HYPERVISOR_xsm_op               27
 #define __HYPERVISOR_nmi_op               28
 #define __HYPERVISOR_sched_op             29
 #define __HYPERVISOR_callback_op          30
@@ -75,7 +75,11 @@
 #define __HYPERVISOR_event_channel_op     32
 #define __HYPERVISOR_physdev_op           33
 #define __HYPERVISOR_hvm_op               34
+#define __HYPERVISOR_sysctl               35
+#define __HYPERVISOR_domctl               36
+#define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
+#define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient */
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
-- 
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 Dec 17 09:51:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 09:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BFm-0006Ld-0J; Wed, 17 Dec 2014 09:50: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 1Y1BFl-0006LC-0P
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 09:50:45 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	F5/BC-02954-4F151945; Wed, 17 Dec 2014 09:50:44 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418809843!15596508!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 13076 invoked from network); 17 Dec 2014 09:50:43 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 09:50:43 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9D6A1AD91;
	Wed, 17 Dec 2014 09:50:42 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Wed, 17 Dec 2014 10:50:34 +0100
Message-Id: <1418809838-14123-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/4] xen: auto-generate symbols for xen
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Xen hypercalls are defined in include/xen/interface/xen.h. There
are some places where for each hypercall a table element is created.
Instead of manually add each hypercall element to these tables use
an auto generated header built during the make process of the kernel.

Changes in V2:
- add "autogenerated" comment to generated header file as suggested by
  David Vrabel (patch 1)
- some minor adjustments to patch 4 as suggested by David Vrabel

Juergen Gross (4):
  xen: build infrastructure for generating hypercall depending symbols
  xen: synchronize include/xen/interface/xen.h with xen
  xen: use generated hypervisor symbols in arch/x86/xen/trace.c
  xen: use generated hypercall symbols in arch/x86/xen/xen-head.S

 arch/x86/syscalls/Makefile  |  9 +++++++
 arch/x86/xen/trace.c        | 50 +++--------------------------------
 arch/x86/xen/xen-head.S     | 63 +++++++--------------------------------------
 include/xen/interface/xen.h |  6 ++++-
 scripts/xen-hypercalls.sh   | 12 +++++++++
 5 files changed, 40 insertions(+), 100 deletions(-)
 create mode 100644 scripts/xen-hypercalls.sh

-- 
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 Dec 17 09:51:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 09:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BFo-0006M2-3F; Wed, 17 Dec 2014 09:50:48 +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 1Y1BFm-0006LZ-8B
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 09:50:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	43/E8-09842-4F151945; Wed, 17 Dec 2014 09:50:44 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418809844!12720139!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9300 invoked from network); 17 Dec 2014 09:50:44 -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; 17 Dec 2014 09:50:44 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DCC0AADB9;
	Wed, 17 Dec 2014 09:50:43 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Wed, 17 Dec 2014 10:50:38 +0100
Message-Id: <1418809838-14123-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418809838-14123-1-git-send-email-jgross@suse.com>
References: <1418809838-14123-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [Patch V2 4/4] xen: use generated hypercall symbols in
	arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 manually list each hypercall in arch/x86/xen/xen-head.S
use the auto generated symbol list.

This also corrects the wrong address of xen_hypercall_mca which was
located 32 bytes higher than it should.

Symbol addresses have been verified to match the correct ones via
objdump output.

Based-on-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/xen-head.S | 63 ++++++++-----------------------------------------
 1 file changed, 10 insertions(+), 53 deletions(-)

diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 674b2225..8afdfcc 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -12,6 +12,8 @@
 
 #include <xen/interface/elfnote.h>
 #include <xen/interface/features.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/xen-mca.h>
 #include <asm/xen/interface.h>
 
 #ifdef CONFIG_XEN_PVH
@@ -85,59 +87,14 @@ ENTRY(xen_pvh_early_cpu_init)
 .pushsection .text
 	.balign PAGE_SIZE
 ENTRY(hypercall_page)
-#define NEXT_HYPERCALL(x) \
-	ENTRY(xen_hypercall_##x) \
-	.skip 32
-
-NEXT_HYPERCALL(set_trap_table)
-NEXT_HYPERCALL(mmu_update)
-NEXT_HYPERCALL(set_gdt)
-NEXT_HYPERCALL(stack_switch)
-NEXT_HYPERCALL(set_callbacks)
-NEXT_HYPERCALL(fpu_taskswitch)
-NEXT_HYPERCALL(sched_op_compat)
-NEXT_HYPERCALL(platform_op)
-NEXT_HYPERCALL(set_debugreg)
-NEXT_HYPERCALL(get_debugreg)
-NEXT_HYPERCALL(update_descriptor)
-NEXT_HYPERCALL(ni)
-NEXT_HYPERCALL(memory_op)
-NEXT_HYPERCALL(multicall)
-NEXT_HYPERCALL(update_va_mapping)
-NEXT_HYPERCALL(set_timer_op)
-NEXT_HYPERCALL(event_channel_op_compat)
-NEXT_HYPERCALL(xen_version)
-NEXT_HYPERCALL(console_io)
-NEXT_HYPERCALL(physdev_op_compat)
-NEXT_HYPERCALL(grant_table_op)
-NEXT_HYPERCALL(vm_assist)
-NEXT_HYPERCALL(update_va_mapping_otherdomain)
-NEXT_HYPERCALL(iret)
-NEXT_HYPERCALL(vcpu_op)
-NEXT_HYPERCALL(set_segment_base)
-NEXT_HYPERCALL(mmuext_op)
-NEXT_HYPERCALL(xsm_op)
-NEXT_HYPERCALL(nmi_op)
-NEXT_HYPERCALL(sched_op)
-NEXT_HYPERCALL(callback_op)
-NEXT_HYPERCALL(xenoprof_op)
-NEXT_HYPERCALL(event_channel_op)
-NEXT_HYPERCALL(physdev_op)
-NEXT_HYPERCALL(hvm_op)
-NEXT_HYPERCALL(sysctl)
-NEXT_HYPERCALL(domctl)
-NEXT_HYPERCALL(kexec_op)
-NEXT_HYPERCALL(tmem_op) /* 38 */
-ENTRY(xen_hypercall_rsvr)
-	.skip 320
-NEXT_HYPERCALL(mca) /* 48 */
-NEXT_HYPERCALL(arch_1)
-NEXT_HYPERCALL(arch_2)
-NEXT_HYPERCALL(arch_3)
-NEXT_HYPERCALL(arch_4)
-NEXT_HYPERCALL(arch_5)
-NEXT_HYPERCALL(arch_6)
-	.balign PAGE_SIZE
+	.skip PAGE_SIZE
+
+#define HYPERCALL(n) \
+	.equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \
+	.type xen_hypercall_##n, @function; .size xen_hypercall_##n, 32
+#include <asm/xen-hypercalls.h>
+#undef HYPERCALL
+
 .popsection
 
 	ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS,       .asciz "linux")
-- 
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 Dec 17 09:51:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 09:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BFn-0006Lo-Bp; Wed, 17 Dec 2014 09:50:47 +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 1Y1BFl-0006LI-Gm
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 09:50:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BA/D8-09842-4F151945; Wed, 17 Dec 2014 09:50:44 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418809843!15807823!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 20463 invoked from network); 17 Dec 2014 09:50:43 -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; 17 Dec 2014 09:50:43 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DF994ABCA;
	Wed, 17 Dec 2014 09:50:42 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Wed, 17 Dec 2014 10:50:35 +0100
Message-Id: <1418809838-14123-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418809838-14123-1-git-send-email-jgross@suse.com>
References: <1418809838-14123-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [Patch V2 1/4] xen: build infrastructure for generating
	hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 there are several places in the kernel which build tables
containing one entry for each possible Xen hypercall. Create an
infrastructure to be able to generate these tables at build time.

Based-on-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/syscalls/Makefile |  9 +++++++++
 scripts/xen-hypercalls.sh  | 12 ++++++++++++
 2 files changed, 21 insertions(+)
 create mode 100644 scripts/xen-hypercalls.sh

diff --git a/arch/x86/syscalls/Makefile b/arch/x86/syscalls/Makefile
index 3323c27..a55abb9 100644
--- a/arch/x86/syscalls/Makefile
+++ b/arch/x86/syscalls/Makefile
@@ -19,6 +19,9 @@ quiet_cmd_syshdr = SYSHDR  $@
 quiet_cmd_systbl = SYSTBL  $@
       cmd_systbl = $(CONFIG_SHELL) '$(systbl)' $< $@
 
+quiet_cmd_hypercalls = HYPERCALLS $@
+      cmd_hypercalls = $(CONFIG_SHELL) '$<' $@ $(filter-out $<,$^)
+
 syshdr_abi_unistd_32 := i386
 $(uapi)/unistd_32.h: $(syscall32) $(syshdr)
 	$(call if_changed,syshdr)
@@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
 $(out)/syscalls_64.h: $(syscall64) $(systbl)
 	$(call if_changed,systbl)
 
+$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
+	$(call if_changed,hypercalls)
+
+$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
+
 uapisyshdr-y			+= unistd_32.h unistd_64.h unistd_x32.h
 syshdr-y			+= syscalls_32.h
 syshdr-$(CONFIG_X86_64)		+= unistd_32_ia32.h unistd_64_x32.h
 syshdr-$(CONFIG_X86_64)		+= syscalls_64.h
+syshdr-$(CONFIG_XEN)		+= xen-hypercalls.h
 
 targets	+= $(uapisyshdr-y) $(syshdr-y)
 
diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
new file mode 100644
index 0000000..676d922
--- /dev/null
+++ b/scripts/xen-hypercalls.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+out="$1"
+shift
+in="$@"
+
+for i in $in; do
+	eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
+done | \
+awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
+	END {   print "/* auto-generated by scripts/xen-hypercall.sh */"
+		for (i in v) if (!(v[i] in v))
+			print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
-- 
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 Dec 17 09:51:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 09:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BFm-0006Ld-0J; Wed, 17 Dec 2014 09:50: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 1Y1BFl-0006LC-0P
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 09:50:45 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	F5/BC-02954-4F151945; Wed, 17 Dec 2014 09:50:44 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418809843!15596508!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 13076 invoked from network); 17 Dec 2014 09:50:43 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 09:50:43 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9D6A1AD91;
	Wed, 17 Dec 2014 09:50:42 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Wed, 17 Dec 2014 10:50:34 +0100
Message-Id: <1418809838-14123-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/4] xen: auto-generate symbols for xen
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Xen hypercalls are defined in include/xen/interface/xen.h. There
are some places where for each hypercall a table element is created.
Instead of manually add each hypercall element to these tables use
an auto generated header built during the make process of the kernel.

Changes in V2:
- add "autogenerated" comment to generated header file as suggested by
  David Vrabel (patch 1)
- some minor adjustments to patch 4 as suggested by David Vrabel

Juergen Gross (4):
  xen: build infrastructure for generating hypercall depending symbols
  xen: synchronize include/xen/interface/xen.h with xen
  xen: use generated hypervisor symbols in arch/x86/xen/trace.c
  xen: use generated hypercall symbols in arch/x86/xen/xen-head.S

 arch/x86/syscalls/Makefile  |  9 +++++++
 arch/x86/xen/trace.c        | 50 +++--------------------------------
 arch/x86/xen/xen-head.S     | 63 +++++++--------------------------------------
 include/xen/interface/xen.h |  6 ++++-
 scripts/xen-hypercalls.sh   | 12 +++++++++
 5 files changed, 40 insertions(+), 100 deletions(-)
 create mode 100644 scripts/xen-hypercalls.sh

-- 
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 Dec 17 09:51:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 09:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BFn-0006Lv-OM; Wed, 17 Dec 2014 09:50: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 1Y1BFl-0006LD-HT
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 09:50:45 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	7D/F0-22819-4F151945; Wed, 17 Dec 2014 09:50:44 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1418809843!10454389!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 16776 invoked from network); 17 Dec 2014 09:50:44 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Dec 2014 09:50:44 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 94390ADB8;
	Wed, 17 Dec 2014 09:50:43 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Wed, 17 Dec 2014 10:50:37 +0100
Message-Id: <1418809838-14123-4-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418809838-14123-1-git-send-email-jgross@suse.com>
References: <1418809838-14123-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [Patch V2 3/4] xen: use generated hypervisor symbols in
	arch/x86/xen/trace.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 manually list all hypervisor calls in arch/x86/xen/trace.c
use the auto generated list.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/trace.c | 50 ++++----------------------------------------------
 1 file changed, 4 insertions(+), 46 deletions(-)

diff --git a/arch/x86/xen/trace.c b/arch/x86/xen/trace.c
index 8296cdf..a702ec2 100644
--- a/arch/x86/xen/trace.c
+++ b/arch/x86/xen/trace.c
@@ -1,54 +1,12 @@
 #include <linux/ftrace.h>
 #include <xen/interface/xen.h>
+#include <xen/interface/xen-mca.h>
 
-#define N(x)	[__HYPERVISOR_##x] = "("#x")"
+#define HYPERCALL(x)	[__HYPERVISOR_##x] = "("#x")",
 static const char *xen_hypercall_names[] = {
-	N(set_trap_table),
-	N(mmu_update),
-	N(set_gdt),
-	N(stack_switch),
-	N(set_callbacks),
-	N(fpu_taskswitch),
-	N(sched_op_compat),
-	N(dom0_op),
-	N(set_debugreg),
-	N(get_debugreg),
-	N(update_descriptor),
-	N(memory_op),
-	N(multicall),
-	N(update_va_mapping),
-	N(set_timer_op),
-	N(event_channel_op_compat),
-	N(xen_version),
-	N(console_io),
-	N(physdev_op_compat),
-	N(grant_table_op),
-	N(vm_assist),
-	N(update_va_mapping_otherdomain),
-	N(iret),
-	N(vcpu_op),
-	N(set_segment_base),
-	N(mmuext_op),
-	N(xsm_op),
-	N(nmi_op),
-	N(sched_op),
-	N(callback_op),
-	N(xenoprof_op),
-	N(event_channel_op),
-	N(physdev_op),
-	N(hvm_op),
-
-/* Architecture-specific hypercall definitions. */
-	N(arch_0),
-	N(arch_1),
-	N(arch_2),
-	N(arch_3),
-	N(arch_4),
-	N(arch_5),
-	N(arch_6),
-	N(arch_7),
+#include <asm/xen-hypercalls.h>
 };
-#undef N
+#undef HYPERCALL
 
 static const char *xen_hypercall_name(unsigned op)
 {
-- 
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 Dec 17 09:51:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 09:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BFl-0006LN-LM; Wed, 17 Dec 2014 09:50:45 +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 1Y1BFk-0006LB-Op
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 09:50:44 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	6A/D8-09842-4F151945; Wed, 17 Dec 2014 09:50:44 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418809843!15807822!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 20457 invoked from network); 17 Dec 2014 09:50:43 -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; 17 Dec 2014 09:50:43 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 3BCB6ADB5;
	Wed, 17 Dec 2014 09:50:43 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Wed, 17 Dec 2014 10:50:36 +0100
Message-Id: <1418809838-14123-3-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418809838-14123-1-git-send-email-jgross@suse.com>
References: <1418809838-14123-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [Patch V2 2/4] xen: synchronize
	include/xen/interface/xen.h with xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The header include/xen/interface/xen.h doesn't contain all definitions
from Xen's version of that header. Update it accordingly.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
---
 arch/x86/xen/trace.c        | 2 +-
 include/xen/interface/xen.h | 6 +++++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/trace.c b/arch/x86/xen/trace.c
index 520022d..8296cdf 100644
--- a/arch/x86/xen/trace.c
+++ b/arch/x86/xen/trace.c
@@ -29,7 +29,7 @@ static const char *xen_hypercall_names[] = {
 	N(vcpu_op),
 	N(set_segment_base),
 	N(mmuext_op),
-	N(acm_op),
+	N(xsm_op),
 	N(nmi_op),
 	N(sched_op),
 	N(callback_op),
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index f68719f..a483789 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -67,7 +67,7 @@
 #define __HYPERVISOR_vcpu_op              24
 #define __HYPERVISOR_set_segment_base     25 /* x86/64 only */
 #define __HYPERVISOR_mmuext_op            26
-#define __HYPERVISOR_acm_op               27
+#define __HYPERVISOR_xsm_op               27
 #define __HYPERVISOR_nmi_op               28
 #define __HYPERVISOR_sched_op             29
 #define __HYPERVISOR_callback_op          30
@@ -75,7 +75,11 @@
 #define __HYPERVISOR_event_channel_op     32
 #define __HYPERVISOR_physdev_op           33
 #define __HYPERVISOR_hvm_op               34
+#define __HYPERVISOR_sysctl               35
+#define __HYPERVISOR_domctl               36
+#define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
+#define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient */
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
-- 
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 Dec 17 09:51:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 09:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BFo-0006M2-3F; Wed, 17 Dec 2014 09:50:48 +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 1Y1BFm-0006LZ-8B
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 09:50:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	43/E8-09842-4F151945; Wed, 17 Dec 2014 09:50:44 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418809844!12720139!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9300 invoked from network); 17 Dec 2014 09:50:44 -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; 17 Dec 2014 09:50:44 -0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DCC0AADB9;
	Wed, 17 Dec 2014 09:50:43 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Wed, 17 Dec 2014 10:50:38 +0100
Message-Id: <1418809838-14123-5-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418809838-14123-1-git-send-email-jgross@suse.com>
References: <1418809838-14123-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [Patch V2 4/4] xen: use generated hypercall symbols in
	arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 manually list each hypercall in arch/x86/xen/xen-head.S
use the auto generated symbol list.

This also corrects the wrong address of xen_hypercall_mca which was
located 32 bytes higher than it should.

Symbol addresses have been verified to match the correct ones via
objdump output.

Based-on-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/xen-head.S | 63 ++++++++-----------------------------------------
 1 file changed, 10 insertions(+), 53 deletions(-)

diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 674b2225..8afdfcc 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -12,6 +12,8 @@
 
 #include <xen/interface/elfnote.h>
 #include <xen/interface/features.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/xen-mca.h>
 #include <asm/xen/interface.h>
 
 #ifdef CONFIG_XEN_PVH
@@ -85,59 +87,14 @@ ENTRY(xen_pvh_early_cpu_init)
 .pushsection .text
 	.balign PAGE_SIZE
 ENTRY(hypercall_page)
-#define NEXT_HYPERCALL(x) \
-	ENTRY(xen_hypercall_##x) \
-	.skip 32
-
-NEXT_HYPERCALL(set_trap_table)
-NEXT_HYPERCALL(mmu_update)
-NEXT_HYPERCALL(set_gdt)
-NEXT_HYPERCALL(stack_switch)
-NEXT_HYPERCALL(set_callbacks)
-NEXT_HYPERCALL(fpu_taskswitch)
-NEXT_HYPERCALL(sched_op_compat)
-NEXT_HYPERCALL(platform_op)
-NEXT_HYPERCALL(set_debugreg)
-NEXT_HYPERCALL(get_debugreg)
-NEXT_HYPERCALL(update_descriptor)
-NEXT_HYPERCALL(ni)
-NEXT_HYPERCALL(memory_op)
-NEXT_HYPERCALL(multicall)
-NEXT_HYPERCALL(update_va_mapping)
-NEXT_HYPERCALL(set_timer_op)
-NEXT_HYPERCALL(event_channel_op_compat)
-NEXT_HYPERCALL(xen_version)
-NEXT_HYPERCALL(console_io)
-NEXT_HYPERCALL(physdev_op_compat)
-NEXT_HYPERCALL(grant_table_op)
-NEXT_HYPERCALL(vm_assist)
-NEXT_HYPERCALL(update_va_mapping_otherdomain)
-NEXT_HYPERCALL(iret)
-NEXT_HYPERCALL(vcpu_op)
-NEXT_HYPERCALL(set_segment_base)
-NEXT_HYPERCALL(mmuext_op)
-NEXT_HYPERCALL(xsm_op)
-NEXT_HYPERCALL(nmi_op)
-NEXT_HYPERCALL(sched_op)
-NEXT_HYPERCALL(callback_op)
-NEXT_HYPERCALL(xenoprof_op)
-NEXT_HYPERCALL(event_channel_op)
-NEXT_HYPERCALL(physdev_op)
-NEXT_HYPERCALL(hvm_op)
-NEXT_HYPERCALL(sysctl)
-NEXT_HYPERCALL(domctl)
-NEXT_HYPERCALL(kexec_op)
-NEXT_HYPERCALL(tmem_op) /* 38 */
-ENTRY(xen_hypercall_rsvr)
-	.skip 320
-NEXT_HYPERCALL(mca) /* 48 */
-NEXT_HYPERCALL(arch_1)
-NEXT_HYPERCALL(arch_2)
-NEXT_HYPERCALL(arch_3)
-NEXT_HYPERCALL(arch_4)
-NEXT_HYPERCALL(arch_5)
-NEXT_HYPERCALL(arch_6)
-	.balign PAGE_SIZE
+	.skip PAGE_SIZE
+
+#define HYPERCALL(n) \
+	.equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \
+	.type xen_hypercall_##n, @function; .size xen_hypercall_##n, 32
+#include <asm/xen-hypercalls.h>
+#undef HYPERCALL
+
 .popsection
 
 	ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS,       .asciz "linux")
-- 
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 Dec 17 09:51:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 09:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BFn-0006Lo-Bp; Wed, 17 Dec 2014 09:50:47 +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 1Y1BFl-0006LI-Gm
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 09:50:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BA/D8-09842-4F151945; Wed, 17 Dec 2014 09:50:44 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418809843!15807823!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 20463 invoked from network); 17 Dec 2014 09:50:43 -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; 17 Dec 2014 09:50:43 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id DF994ABCA;
	Wed, 17 Dec 2014 09:50:42 +0000 (UTC)
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, mmarek@suse.cz,
	linux-kbuild@vger.kernel.org
Date: Wed, 17 Dec 2014 10:50:35 +0100
Message-Id: <1418809838-14123-2-git-send-email-jgross@suse.com>
X-Mailer: git-send-email 2.1.2
In-Reply-To: <1418809838-14123-1-git-send-email-jgross@suse.com>
References: <1418809838-14123-1-git-send-email-jgross@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Subject: [Xen-devel] [Patch V2 1/4] xen: build infrastructure for generating
	hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 there are several places in the kernel which build tables
containing one entry for each possible Xen hypercall. Create an
infrastructure to be able to generate these tables at build time.

Based-on-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/syscalls/Makefile |  9 +++++++++
 scripts/xen-hypercalls.sh  | 12 ++++++++++++
 2 files changed, 21 insertions(+)
 create mode 100644 scripts/xen-hypercalls.sh

diff --git a/arch/x86/syscalls/Makefile b/arch/x86/syscalls/Makefile
index 3323c27..a55abb9 100644
--- a/arch/x86/syscalls/Makefile
+++ b/arch/x86/syscalls/Makefile
@@ -19,6 +19,9 @@ quiet_cmd_syshdr = SYSHDR  $@
 quiet_cmd_systbl = SYSTBL  $@
       cmd_systbl = $(CONFIG_SHELL) '$(systbl)' $< $@
 
+quiet_cmd_hypercalls = HYPERCALLS $@
+      cmd_hypercalls = $(CONFIG_SHELL) '$<' $@ $(filter-out $<,$^)
+
 syshdr_abi_unistd_32 := i386
 $(uapi)/unistd_32.h: $(syscall32) $(syshdr)
 	$(call if_changed,syshdr)
@@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
 $(out)/syscalls_64.h: $(syscall64) $(systbl)
 	$(call if_changed,systbl)
 
+$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
+	$(call if_changed,hypercalls)
+
+$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
+
 uapisyshdr-y			+= unistd_32.h unistd_64.h unistd_x32.h
 syshdr-y			+= syscalls_32.h
 syshdr-$(CONFIG_X86_64)		+= unistd_32_ia32.h unistd_64_x32.h
 syshdr-$(CONFIG_X86_64)		+= syscalls_64.h
+syshdr-$(CONFIG_XEN)		+= xen-hypercalls.h
 
 targets	+= $(uapisyshdr-y) $(syshdr-y)
 
diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
new file mode 100644
index 0000000..676d922
--- /dev/null
+++ b/scripts/xen-hypercalls.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+out="$1"
+shift
+in="$@"
+
+for i in $in; do
+	eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
+done | \
+awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
+	END {   print "/* auto-generated by scripts/xen-hypercall.sh */"
+		for (i in v) if (!(v[i] in v))
+			print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
-- 
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 Dec 17 09:59:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 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 1Y1BO3-0007Bg-8e; Wed, 17 Dec 2014 09:59:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1BO1-0007Bb-Il
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 09:59:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1E/44-15461-4F351945; Wed, 17 Dec 2014 09:59:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418810356!15811000!1
X-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 18265 invoked from network); 17 Dec 2014 09:59:16 -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; 17 Dec 2014 09:59:16 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 09:59:15 +0000
Message-Id: <54916201020000780005026A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 09:59:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com>
In-Reply-To: <549095E3.30202@citrix.com>
Mime-Version: 1.0
Content-Length: 1593
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, ian.jackson@eu.citrix.com,
	mdontu@bitdefender.com, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDE2LjEyLjE0IGF0IDIxOjI4LCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4gT24gMTYvMTIvMTQgMTk6MzMsIE1paGFpIERvbsibdSB3cm90ZToKPj4gK3N0YXRpYyBi
b29sX3QgX194bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5l
LAo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0
IHhtZW1fcG9vbCAqcG9vbCkKPj4gK3sKPj4gKyAgICB1bnNpZ25lZCBpbnQgaTsKPj4gKyAgICBz
dGF0aWMgYm9vbF90IG9uY2UgPSAxOwo+IAo+IFdoYXQgaXMgdGhpcyBzdGF0aWMgZG9pbmc/ICBT
dXJlbHkgY29ycnVwdGlvbiBjb3JydXB0aW9uIGluIG9uZSBwb29sIGhhcwo+IG5vIGVmZmVjdCBv
biBjb3JydXB0aW9uIGluIGEgc2VwYXJhdGUgcG9vbCAob3RoZXIgdGhhbiB0aGUgdXN1YWwgc2lk
ZQo+IGVmZmVjdHMgb2YgZ2VuZXJhbCBtZW1vcnkgY29ycnVwdGlvbiwgd2hpY2ggdGVuZCB0byBi
ZSBiYWQpLgo+IAo+IEl0IGxvb2tzIGFzIGlmIGl0IHdhbnRzIHRvIGJlIGFuIGV4dHJhIGZpZWxk
IGluIGFuIHhtZW1fcG9vbC4KClF1ZXN0aW9uIGlzIHdoZXRoZXIgbG9nZ2luZyBtb3JlIHRoYW4g
dGhlIGZpcnN0IGNvcnJ1cHRpb24gZXZlciBpcwpyZWFsbHkgYWxsIHRoYXQgdXNlZnVsLgoKCj4+
ICtib29sX3QgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsIHN0
cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4+ICt7Cj4+ICsgICAgcmV0dXJuIF9feG1lbV9wb29sX2No
ZWNrX3VubG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wgPzogeGVucG9vbCk7Cj4gCj4gV2h5IHNob3Vs
ZCBhIE5VTEwgcG9vbCBiZSB0b2xlcmF0ZWQgaGVyZT8gIFRoaXMgaXMgZGVidWcgY29kZSBvbmx5
LCBzbwo+IHdlIGNhbiByZXF1aXJlIGFuZCB0cnVzdCB0aGF0IHdlIGFyZSBjYWxsZWQgYXBwcm9w
cmlhdGVseS4KCnhlbnBvb2wgaXMgbm90IGFuZCBzaG91bGQgbm90IGJlIHZpc2libGUgdG8gY29k
ZSBvdXRzaWRlIHRoaXMgZmlsZS4KCkphbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Dec 17 09:59:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 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 1Y1BO3-0007Bg-8e; Wed, 17 Dec 2014 09:59:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1BO1-0007Bb-Il
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 09:59:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1E/44-15461-4F351945; Wed, 17 Dec 2014 09:59:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418810356!15811000!1
X-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 18265 invoked from network); 17 Dec 2014 09:59:16 -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; 17 Dec 2014 09:59:16 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 09:59:15 +0000
Message-Id: <54916201020000780005026A@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 09:59:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com>
In-Reply-To: <549095E3.30202@citrix.com>
Mime-Version: 1.0
Content-Length: 1593
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, ian.jackson@eu.citrix.com,
	mdontu@bitdefender.com, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDE2LjEyLjE0IGF0IDIxOjI4LCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4gT24gMTYvMTIvMTQgMTk6MzMsIE1paGFpIERvbsibdSB3cm90ZToKPj4gK3N0YXRpYyBi
b29sX3QgX194bWVtX3Bvb2xfY2hlY2tfbG9ja2VkKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5l
LAo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0
IHhtZW1fcG9vbCAqcG9vbCkKPj4gK3sKPj4gKyAgICB1bnNpZ25lZCBpbnQgaTsKPj4gKyAgICBz
dGF0aWMgYm9vbF90IG9uY2UgPSAxOwo+IAo+IFdoYXQgaXMgdGhpcyBzdGF0aWMgZG9pbmc/ICBT
dXJlbHkgY29ycnVwdGlvbiBjb3JydXB0aW9uIGluIG9uZSBwb29sIGhhcwo+IG5vIGVmZmVjdCBv
biBjb3JydXB0aW9uIGluIGEgc2VwYXJhdGUgcG9vbCAob3RoZXIgdGhhbiB0aGUgdXN1YWwgc2lk
ZQo+IGVmZmVjdHMgb2YgZ2VuZXJhbCBtZW1vcnkgY29ycnVwdGlvbiwgd2hpY2ggdGVuZCB0byBi
ZSBiYWQpLgo+IAo+IEl0IGxvb2tzIGFzIGlmIGl0IHdhbnRzIHRvIGJlIGFuIGV4dHJhIGZpZWxk
IGluIGFuIHhtZW1fcG9vbC4KClF1ZXN0aW9uIGlzIHdoZXRoZXIgbG9nZ2luZyBtb3JlIHRoYW4g
dGhlIGZpcnN0IGNvcnJ1cHRpb24gZXZlciBpcwpyZWFsbHkgYWxsIHRoYXQgdXNlZnVsLgoKCj4+
ICtib29sX3QgX194bWVtX3Bvb2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsIHN0
cnVjdCB4bWVtX3Bvb2wgKnBvb2wpCj4+ICt7Cj4+ICsgICAgcmV0dXJuIF9feG1lbV9wb29sX2No
ZWNrX3VubG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wgPzogeGVucG9vbCk7Cj4gCj4gV2h5IHNob3Vs
ZCBhIE5VTEwgcG9vbCBiZSB0b2xlcmF0ZWQgaGVyZT8gIFRoaXMgaXMgZGVidWcgY29kZSBvbmx5
LCBzbwo+IHdlIGNhbiByZXF1aXJlIGFuZCB0cnVzdCB0aGF0IHdlIGFyZSBjYWxsZWQgYXBwcm9w
cmlhdGVseS4KCnhlbnBvb2wgaXMgbm90IGFuZCBzaG91bGQgbm90IGJlIHZpc2libGUgdG8gY29k
ZSBvdXRzaWRlIHRoaXMgZmlsZS4KCkphbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:05:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:05:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BTy-0007ZG-3m; Wed, 17 Dec 2014 10:05:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1BTx-0007ZB-81
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 10:05:25 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	49/7A-09284-46551945; Wed, 17 Dec 2014 10:05:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418810723!13983877!1
X-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 25172 invoked from network); 17 Dec 2014 10:05:24 -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; 17 Dec 2014 10:05:24 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 10:05:23 +0000
Message-Id: <5491636F020000780005027B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 10:05:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-4-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1418760534-18163-4-git-send-email-julien.grall@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE
	macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -90,4 +90,18 @@
>      __asm__ ("" : "=r"(__ptr) : "0"(ptr));      \
>      (typeof(ptr)) (__ptr + (off)); })
>  
> +/*
> + * Prevent the compiler from merging or refetching accesses.  The compiler
> + * is also forbidden from reordering successive instances of ACCESS_ONCE(),
> + * but only when the compiler is aware of some particular ordering.  One way
> + * to make the compiler aware of ordering is to put the two invocations of
> + * ACCESS_ONCE() in different C statements.
> + *
> + * This macro does absolutely -nothing- to prevent the CPU from reordering,
> + * merging, or refetching absolutely anything at any time.  Its main intended
> + * use is to mediate communication between process-level code and irq/NMI
> + * handlers, all running on the same CPU.
> + */
> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))

Any reason not to simply use {read,write}_atomic() instead, which we
already have?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:05:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:05:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BTy-0007ZG-3m; Wed, 17 Dec 2014 10:05:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1BTx-0007ZB-81
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 10:05:25 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	49/7A-09284-46551945; Wed, 17 Dec 2014 10:05:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418810723!13983877!1
X-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 25172 invoked from network); 17 Dec 2014 10:05:24 -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; 17 Dec 2014 10:05:24 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 10:05:23 +0000
Message-Id: <5491636F020000780005027B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 10:05:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-4-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1418760534-18163-4-git-send-email-julien.grall@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE
	macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -90,4 +90,18 @@
>      __asm__ ("" : "=r"(__ptr) : "0"(ptr));      \
>      (typeof(ptr)) (__ptr + (off)); })
>  
> +/*
> + * Prevent the compiler from merging or refetching accesses.  The compiler
> + * is also forbidden from reordering successive instances of ACCESS_ONCE(),
> + * but only when the compiler is aware of some particular ordering.  One way
> + * to make the compiler aware of ordering is to put the two invocations of
> + * ACCESS_ONCE() in different C statements.
> + *
> + * This macro does absolutely -nothing- to prevent the CPU from reordering,
> + * merging, or refetching absolutely anything at any time.  Its main intended
> + * use is to mediate communication between process-level code and irq/NMI
> + * handlers, all running on the same CPU.
> + */
> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))

Any reason not to simply use {read,write}_atomic() instead, which we
already have?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:08:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:08:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BXK-0007hK-5g; Wed, 17 Dec 2014 10:08:54 +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 1Y1BXJ-0007hD-5N
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 10:08:53 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	E3/3F-02699-43651945; Wed, 17 Dec 2014 10:08:52 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418810930!15616017!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22022 invoked from network); 17 Dec 2014 10:08:51 -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;
	17 Dec 2014 10:08:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,592,1413244800"; d="scan'208";a="205736741"
Message-ID: <54915630.8020302@citrix.com>
Date: Wed, 17 Dec 2014 10:08: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: Jan Beulich <JBeulich@suse.com>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com>
	<54916201020000780005026A@mail.emea.novell.com>
In-Reply-To: <54916201020000780005026A@mail.emea.novell.com>
Content-Length: 2108
X-DLP: MIA2
Cc: keir@xen.org, ian.campbell@citrix.com, ian.jackson@eu.citrix.com,
	mdontu@bitdefender.com, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTcvMTIvMTQgMDk6NTksIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+IE9uIDE2LjEyLjE0IGF0
IDIxOjI4LCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3JvdGU6Cj4+IE9uIDE2LzEyLzE0
IDE5OjMzLCBNaWhhaSBEb27Im3Ugd3JvdGU6Cj4+PiArc3RhdGljIGJvb2xfdCBfX3htZW1fcG9v
bF9jaGVja19sb2NrZWQoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsCj4+PiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IHhtZW1fcG9vbCAqcG9v
bCkKPj4+ICt7Cj4+PiArICAgIHVuc2lnbmVkIGludCBpOwo+Pj4gKyAgICBzdGF0aWMgYm9vbF90
IG9uY2UgPSAxOwo+PiBXaGF0IGlzIHRoaXMgc3RhdGljIGRvaW5nPyAgU3VyZWx5IGNvcnJ1cHRp
b24gY29ycnVwdGlvbiBpbiBvbmUgcG9vbCBoYXMKPj4gbm8gZWZmZWN0IG9uIGNvcnJ1cHRpb24g
aW4gYSBzZXBhcmF0ZSBwb29sIChvdGhlciB0aGFuIHRoZSB1c3VhbCBzaWRlCj4+IGVmZmVjdHMg
b2YgZ2VuZXJhbCBtZW1vcnkgY29ycnVwdGlvbiwgd2hpY2ggdGVuZCB0byBiZSBiYWQpLgo+Pgo+
PiBJdCBsb29rcyBhcyBpZiBpdCB3YW50cyB0byBiZSBhbiBleHRyYSBmaWVsZCBpbiBhbiB4bWVt
X3Bvb2wuCj4gUXVlc3Rpb24gaXMgd2hldGhlciBsb2dnaW5nIG1vcmUgdGhhbiB0aGUgZmlyc3Qg
Y29ycnVwdGlvbiBldmVyIGlzCj4gcmVhbGx5IGFsbCB0aGF0IHVzZWZ1bC4KClRydWUgLSBhcyBz
b29uIGFzIG9uZSBiaXQgb2YgbWVtb3J5IGNvcnJ1cHRpb24gaXMgZGV0ZWN0ZWQsIGFsbCBvdGhl
cgpiZXRzIGFyZSBvZmYuCgpNaWdodCBpdCBwZXJoYXBzIGJlIHBydWRlbnQgdG8gdGhlbiBwYW5p
YygpIG9uIGEgcG9zaXRpdmUgZGV0ZWN0aW9uIG9mCm1lbW9yeSBjb3JydXB0aW9uPwoKPgo+Cj4+
PiArYm9vbF90IF9feG1lbV9wb29sX2NoZWNrKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBz
dHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+Pj4gK3sKPj4+ICsgICAgcmV0dXJuIF9feG1lbV9wb29s
X2NoZWNrX3VubG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wgPzogeGVucG9vbCk7Cj4+IFdoeSBzaG91
bGQgYSBOVUxMIHBvb2wgYmUgdG9sZXJhdGVkIGhlcmU/ICBUaGlzIGlzIGRlYnVnIGNvZGUgb25s
eSwgc28KPj4gd2UgY2FuIHJlcXVpcmUgYW5kIHRydXN0IHRoYXQgd2UgYXJlIGNhbGxlZCBhcHBy
b3ByaWF0ZWx5Lgo+IHhlbnBvb2wgaXMgbm90IGFuZCBzaG91bGQgbm90IGJlIHZpc2libGUgdG8g
Y29kZSBvdXRzaWRlIHRoaXMgZmlsZS4KClF1aXRlLCBidXQgdGhlIG9ubHkgcGxhdXNpYmxlIGV4
dGVybmFsIGNhbGxlcnMgd2lsbCBiZSBjaGVja2luZyBwb29scyBvZgp0aGVpciBvd24uICBUaGlz
IHBhdGNoIGFkZHMgaW50ZXJuYWwgY2FsbGVycyBmb3IgY2hlY2tpbmcgdGhlIHhlbnBvb2wuCgp+
QW5kcmV3CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0
cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:08:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:08:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BXK-0007hK-5g; Wed, 17 Dec 2014 10:08:54 +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 1Y1BXJ-0007hD-5N
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 10:08:53 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	E3/3F-02699-43651945; Wed, 17 Dec 2014 10:08:52 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418810930!15616017!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22022 invoked from network); 17 Dec 2014 10:08:51 -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;
	17 Dec 2014 10:08:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,592,1413244800"; d="scan'208";a="205736741"
Message-ID: <54915630.8020302@citrix.com>
Date: Wed, 17 Dec 2014 10:08: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: Jan Beulich <JBeulich@suse.com>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com>
	<54916201020000780005026A@mail.emea.novell.com>
In-Reply-To: <54916201020000780005026A@mail.emea.novell.com>
Content-Length: 2108
X-DLP: MIA2
Cc: keir@xen.org, ian.campbell@citrix.com, ian.jackson@eu.citrix.com,
	mdontu@bitdefender.com, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTcvMTIvMTQgMDk6NTksIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+IE9uIDE2LjEyLjE0IGF0
IDIxOjI4LCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3JvdGU6Cj4+IE9uIDE2LzEyLzE0
IDE5OjMzLCBNaWhhaSBEb27Im3Ugd3JvdGU6Cj4+PiArc3RhdGljIGJvb2xfdCBfX3htZW1fcG9v
bF9jaGVja19sb2NrZWQoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsCj4+PiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IHhtZW1fcG9vbCAqcG9v
bCkKPj4+ICt7Cj4+PiArICAgIHVuc2lnbmVkIGludCBpOwo+Pj4gKyAgICBzdGF0aWMgYm9vbF90
IG9uY2UgPSAxOwo+PiBXaGF0IGlzIHRoaXMgc3RhdGljIGRvaW5nPyAgU3VyZWx5IGNvcnJ1cHRp
b24gY29ycnVwdGlvbiBpbiBvbmUgcG9vbCBoYXMKPj4gbm8gZWZmZWN0IG9uIGNvcnJ1cHRpb24g
aW4gYSBzZXBhcmF0ZSBwb29sIChvdGhlciB0aGFuIHRoZSB1c3VhbCBzaWRlCj4+IGVmZmVjdHMg
b2YgZ2VuZXJhbCBtZW1vcnkgY29ycnVwdGlvbiwgd2hpY2ggdGVuZCB0byBiZSBiYWQpLgo+Pgo+
PiBJdCBsb29rcyBhcyBpZiBpdCB3YW50cyB0byBiZSBhbiBleHRyYSBmaWVsZCBpbiBhbiB4bWVt
X3Bvb2wuCj4gUXVlc3Rpb24gaXMgd2hldGhlciBsb2dnaW5nIG1vcmUgdGhhbiB0aGUgZmlyc3Qg
Y29ycnVwdGlvbiBldmVyIGlzCj4gcmVhbGx5IGFsbCB0aGF0IHVzZWZ1bC4KClRydWUgLSBhcyBz
b29uIGFzIG9uZSBiaXQgb2YgbWVtb3J5IGNvcnJ1cHRpb24gaXMgZGV0ZWN0ZWQsIGFsbCBvdGhl
cgpiZXRzIGFyZSBvZmYuCgpNaWdodCBpdCBwZXJoYXBzIGJlIHBydWRlbnQgdG8gdGhlbiBwYW5p
YygpIG9uIGEgcG9zaXRpdmUgZGV0ZWN0aW9uIG9mCm1lbW9yeSBjb3JydXB0aW9uPwoKPgo+Cj4+
PiArYm9vbF90IF9feG1lbV9wb29sX2NoZWNrKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBz
dHJ1Y3QgeG1lbV9wb29sICpwb29sKQo+Pj4gK3sKPj4+ICsgICAgcmV0dXJuIF9feG1lbV9wb29s
X2NoZWNrX3VubG9ja2VkKGZpbGUsIGxpbmUsIHBvb2wgPzogeGVucG9vbCk7Cj4+IFdoeSBzaG91
bGQgYSBOVUxMIHBvb2wgYmUgdG9sZXJhdGVkIGhlcmU/ICBUaGlzIGlzIGRlYnVnIGNvZGUgb25s
eSwgc28KPj4gd2UgY2FuIHJlcXVpcmUgYW5kIHRydXN0IHRoYXQgd2UgYXJlIGNhbGxlZCBhcHBy
b3ByaWF0ZWx5Lgo+IHhlbnBvb2wgaXMgbm90IGFuZCBzaG91bGQgbm90IGJlIHZpc2libGUgdG8g
Y29kZSBvdXRzaWRlIHRoaXMgZmlsZS4KClF1aXRlLCBidXQgdGhlIG9ubHkgcGxhdXNpYmxlIGV4
dGVybmFsIGNhbGxlcnMgd2lsbCBiZSBjaGVja2luZyBwb29scyBvZgp0aGVpciBvd24uICBUaGlz
IHBhdGNoIGFkZHMgaW50ZXJuYWwgY2FsbGVycyBmb3IgY2hlY2tpbmcgdGhlIHhlbnBvb2wuCgp+
QW5kcmV3CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0
cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:11:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10: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 1Y1BZg-0007oU-O0; Wed, 17 Dec 2014 10:11:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Y1BZe-0007oN-OO
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 10:11:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	30/A4-25276-6C651945; Wed, 17 Dec 2014 10:11:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418811076!16170113!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 30894 invoked from network); 17 Dec 2014 10:11: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;
	17 Dec 2014 10:11:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,592,1413244800"; d="scan'208";a="205737262"
Message-ID: <549156C1.5000708@citrix.com>
Date: Wed, 17 Dec 2014 10:11: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: Julien Grall <julien.grall@linaro.org>, =?UTF-8?B?TWloYWkgRG9uyJt1?=
	<mdontu@bitdefender.com>, <xen-devel@lists.xen.org>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
	<5490BFBD.7010809@citrix.com> <5490C22F.4020505@linaro.org>
In-Reply-To: <5490C22F.4020505@linaro.org>
X-DLP: MIA2
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/12/14 23:37, Julien Grall wrote:
>
>
> On 16/12/2014 23:26, Andrew Cooper wrote:
>> On 16/12/2014 23:06, Julien Grall wrote:
>>> Hi,
>>>
>>> On 16/12/2014 20:28, Andrew Cooper wrote:
>>>> I suspect you also would be better, and certainly more brief, with
>>>> "run_in_exception_handler(show_stack)" instead, which will just
>>>> print a
>>>> stack trace, but nothing more.
>>>
>>> FIY, run_in_exception_handler doesn't exists on ARM.
>>>
>>> Regards,
>>>
>>
>> In which case it even more lucky that __bug() and __warn() are orphaned
>> functions, as they don't work correctly on arm.  Even more reason to
>> remove them.
>>
>> It doesn't look like run_in_exception_handler() would be hard to add to
>> arm at all.  It already has broadly similar bug/warn/assert
>> infrastructure.
>
> It's more difficult than you think. For ARM we had to use a different
> infrastructure than x86 to setup the BUG_FRAME. This is because %c is
> not correctly support on most ARM compiler today.
>
> So I don't think it worth to spend time on it just for one call.
>
> How about introducing dump_stack() which would call
> run_in_exception_handler() on x86 and something different (maybe a new
> BUG_FRAME type) on ARM?

Introducing a new bugframe is precicely what I meant by "this doesn't
look hard".  x86 currently has one more bugframe than arm, being
BUGFRAME_run_fn.

At this point, run_in_exception_handler() effectively becomes common.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:11:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10: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 1Y1BZg-0007oU-O0; Wed, 17 Dec 2014 10:11:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Y1BZe-0007oN-OO
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 10:11:18 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	30/A4-25276-6C651945; Wed, 17 Dec 2014 10:11:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418811076!16170113!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 30894 invoked from network); 17 Dec 2014 10:11: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;
	17 Dec 2014 10:11:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,592,1413244800"; d="scan'208";a="205737262"
Message-ID: <549156C1.5000708@citrix.com>
Date: Wed, 17 Dec 2014 10:11: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: Julien Grall <julien.grall@linaro.org>, =?UTF-8?B?TWloYWkgRG9uyJt1?=
	<mdontu@bitdefender.com>, <xen-devel@lists.xen.org>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
	<5490BFBD.7010809@citrix.com> <5490C22F.4020505@linaro.org>
In-Reply-To: <5490C22F.4020505@linaro.org>
X-DLP: MIA2
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/12/14 23:37, Julien Grall wrote:
>
>
> On 16/12/2014 23:26, Andrew Cooper wrote:
>> On 16/12/2014 23:06, Julien Grall wrote:
>>> Hi,
>>>
>>> On 16/12/2014 20:28, Andrew Cooper wrote:
>>>> I suspect you also would be better, and certainly more brief, with
>>>> "run_in_exception_handler(show_stack)" instead, which will just
>>>> print a
>>>> stack trace, but nothing more.
>>>
>>> FIY, run_in_exception_handler doesn't exists on ARM.
>>>
>>> Regards,
>>>
>>
>> In which case it even more lucky that __bug() and __warn() are orphaned
>> functions, as they don't work correctly on arm.  Even more reason to
>> remove them.
>>
>> It doesn't look like run_in_exception_handler() would be hard to add to
>> arm at all.  It already has broadly similar bug/warn/assert
>> infrastructure.
>
> It's more difficult than you think. For ARM we had to use a different
> infrastructure than x86 to setup the BUG_FRAME. This is because %c is
> not correctly support on most ARM compiler today.
>
> So I don't think it worth to spend time on it just for one call.
>
> How about introducing dump_stack() which would call
> run_in_exception_handler() on x86 and something different (maybe a new
> BUG_FRAME type) on ARM?

Introducing a new bugframe is precicely what I meant by "this doesn't
look hard".  x86 currently has one more bugframe than arm, being
BUGFRAME_run_fn.

At this point, run_in_exception_handler() effectively becomes common.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:16:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BeL-00089t-Fb; Wed, 17 Dec 2014 10:16:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1BeJ-00089g-FJ
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 10:16:07 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	11/8F-09842-6E751945; Wed, 17 Dec 2014 10:16:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418811365!16145295!1
X-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 10066 invoked from network); 17 Dec 2014 10:16:05 -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; 17 Dec 2014 10:16:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 10:16:04 +0000
Message-Id: <549165F102000078000502B8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 10:16:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1418760534-18163-8-git-send-email-julien.grall@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com, tim@xen.org,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe 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 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -2,6 +2,7 @@ obj-y += bitmap.o
>  obj-y += core_parking.o
>  obj-y += cpu.o
>  obj-y += cpupool.o
> +obj-y += device.o

Shouldn't this instead be two lines, one using HAS_PCI and the second
HAS_DEVICE_TREE?

> @@ -75,8 +76,19 @@ struct pci_dev {
>  #define PT_FAULT_THRESHOLD 10
>      } fault;
>      u64 vf_rlen[6];
> +
> +    struct device dev;
>  };

I'm not convinced yet that growing this structure (of which we have
quite many instances on some systems) is really worth it, in particular
on x86 where we (so far) only have one device type anyway.

> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
> +
> +static inline struct pci_dev *dev_to_pci(struct device *dev)
> +{
> +    ASSERT(dev->type == DEV_PCI);
> +
> +    return container_of(dev, struct pci_dev, dev);
> +}

While the former is const-correct, I dislike the inability of passing
pointers to const into helper functions like the latter. I can't think
of a good solution other than introducing a second const variant
of it, but I suppose we should try to find alternatives before
adding such a construct that moves us in a direction opposite to
getting our code more const-correct.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:16:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BeL-00089t-Fb; Wed, 17 Dec 2014 10:16:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1BeJ-00089g-FJ
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 10:16:07 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	11/8F-09842-6E751945; Wed, 17 Dec 2014 10:16:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418811365!16145295!1
X-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 10066 invoked from network); 17 Dec 2014 10:16:05 -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; 17 Dec 2014 10:16:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 10:16:04 +0000
Message-Id: <549165F102000078000502B8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 10:16:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1418760534-18163-8-git-send-email-julien.grall@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com, tim@xen.org,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe 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 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -2,6 +2,7 @@ obj-y += bitmap.o
>  obj-y += core_parking.o
>  obj-y += cpu.o
>  obj-y += cpupool.o
> +obj-y += device.o

Shouldn't this instead be two lines, one using HAS_PCI and the second
HAS_DEVICE_TREE?

> @@ -75,8 +76,19 @@ struct pci_dev {
>  #define PT_FAULT_THRESHOLD 10
>      } fault;
>      u64 vf_rlen[6];
> +
> +    struct device dev;
>  };

I'm not convinced yet that growing this structure (of which we have
quite many instances on some systems) is really worth it, in particular
on x86 where we (so far) only have one device type anyway.

> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
> +
> +static inline struct pci_dev *dev_to_pci(struct device *dev)
> +{
> +    ASSERT(dev->type == DEV_PCI);
> +
> +    return container_of(dev, struct pci_dev, dev);
> +}

While the former is const-correct, I dislike the inability of passing
pointers to const into helper functions like the latter. I can't think
of a good solution other than introducing a second const variant
of it, but I suppose we should try to find alternatives before
adding such a construct that moves us in a direction opposite to
getting our code more const-correct.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:20:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:20:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BiF-0008J6-8v; Wed, 17 Dec 2014 10:20: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 1Y1BiD-0008J0-W1
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 10:20:10 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	29/A1-20609-9D851945; Wed, 17 Dec 2014 10:20:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418811607!15521895!1
X-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 31621 invoked from network); 17 Dec 2014 10:20: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; 17 Dec 2014 10:20:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 10:20:07 +0000
Message-Id: <549166E602000078000502CD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 10:20:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-9-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1418760534-18163-9-git-send-email-julien.grall@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com, tim@xen.org,
	stefano.stabellini@citrix.com,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	xen-devel@lists.xenproject.org, Yang Zhang <yang.z.zhang@intel.com>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
Subject: Re: [Xen-devel] [PATCH for 4.6 08/13] xen/iommu: Consolidate device
 assignment ops into a single set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
> @@ -123,22 +124,17 @@ struct page_info;
>  struct iommu_ops {
>      int (*init)(struct domain *d);
>      void (*hwdom_init)(struct domain *d);
> -#ifdef HAS_PCI
> -    int (*add_device)(u8 devfn, struct pci_dev *);
> -    int (*enable_device)(struct pci_dev *pdev);
> -    int (*remove_device)(u8 devfn, struct pci_dev *);
> -    int (*assign_device)(struct domain *, u8 devfn, struct pci_dev *);
> +    int (*add_device)(u8 devfn, struct device *);
> +    int (*enable_device)(struct device *dev);
> +    int (*remove_device)(u8 devfn, struct device *);
> +    int (*assign_device)(struct domain *, u8 devfn, struct device *);
>      int (*reassign_device)(struct domain *s, struct domain *t,
> -			   u8 devfn, struct pci_dev *);
> +                           u8 devfn, struct device *);

Please be consistent and either drop the parameter name from all
struct device * instances (my preference), or add one everywhere
(apparently the preference of a some other folks).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:20:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:20:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BiF-0008J6-8v; Wed, 17 Dec 2014 10:20: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 1Y1BiD-0008J0-W1
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 10:20:10 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	29/A1-20609-9D851945; Wed, 17 Dec 2014 10:20:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418811607!15521895!1
X-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 31621 invoked from network); 17 Dec 2014 10:20: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; 17 Dec 2014 10:20:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 10:20:07 +0000
Message-Id: <549166E602000078000502CD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 10:20:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-9-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1418760534-18163-9-git-send-email-julien.grall@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kevin Tian <kevin.tian@intel.com>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com, tim@xen.org,
	stefano.stabellini@citrix.com,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	xen-devel@lists.xenproject.org, Yang Zhang <yang.z.zhang@intel.com>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
Subject: Re: [Xen-devel] [PATCH for 4.6 08/13] xen/iommu: Consolidate device
 assignment ops into a single set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
> @@ -123,22 +124,17 @@ struct page_info;
>  struct iommu_ops {
>      int (*init)(struct domain *d);
>      void (*hwdom_init)(struct domain *d);
> -#ifdef HAS_PCI
> -    int (*add_device)(u8 devfn, struct pci_dev *);
> -    int (*enable_device)(struct pci_dev *pdev);
> -    int (*remove_device)(u8 devfn, struct pci_dev *);
> -    int (*assign_device)(struct domain *, u8 devfn, struct pci_dev *);
> +    int (*add_device)(u8 devfn, struct device *);
> +    int (*enable_device)(struct device *dev);
> +    int (*remove_device)(u8 devfn, struct device *);
> +    int (*assign_device)(struct domain *, u8 devfn, struct device *);
>      int (*reassign_device)(struct domain *s, struct domain *t,
> -			   u8 devfn, struct pci_dev *);
> +                           u8 devfn, struct device *);

Please be consistent and either drop the parameter name from all
struct device * instances (my preference), or add one everywhere
(apparently the preference of a some other folks).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:22:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:22:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Bkk-0000AH-Ql; Wed, 17 Dec 2014 10:22: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 1Y1Bkj-0000A9-CI
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 10:22:45 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	57/0C-25714-47951945; Wed, 17 Dec 2014 10:22:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418811762!13810242!1
X-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 9423 invoked from network); 17 Dec 2014 10:22:43 -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; 17 Dec 2014 10:22:43 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 10:22:42 +0000
Message-Id: <5491678102000078000502D0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 10:22:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com>
	<54916201020000780005026A@mail.emea.novell.com>
	<54915630.8020302@citrix.com>
In-Reply-To: <54915630.8020302@citrix.com>
Mime-Version: 1.0
Content-Length: 2501
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, ian.jackson@eu.citrix.com,
	mdontu@bitdefender.com, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDE3LjEyLjE0IGF0IDExOjA4LCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4gT24gMTcvMTIvMTQgMDk6NTksIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+PiBPbiAxNi4x
Mi4xNCBhdCAyMToyOCwgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+IHdyb3RlOgo+Pj4gT24g
MTYvMTIvMTQgMTk6MzMsIE1paGFpIERvbsibdSB3cm90ZToKPj4+PiArc3RhdGljIGJvb2xfdCBf
X3htZW1fcG9vbF9jaGVja19sb2NrZWQoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsCj4+Pj4g
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0cnVjdCB4bWVt
X3Bvb2wgKnBvb2wpCj4+Pj4gK3sKPj4+PiArICAgIHVuc2lnbmVkIGludCBpOwo+Pj4+ICsgICAg
c3RhdGljIGJvb2xfdCBvbmNlID0gMTsKPj4+IFdoYXQgaXMgdGhpcyBzdGF0aWMgZG9pbmc/ICBT
dXJlbHkgY29ycnVwdGlvbiBjb3JydXB0aW9uIGluIG9uZSBwb29sIGhhcwo+Pj4gbm8gZWZmZWN0
IG9uIGNvcnJ1cHRpb24gaW4gYSBzZXBhcmF0ZSBwb29sIChvdGhlciB0aGFuIHRoZSB1c3VhbCBz
aWRlCj4+PiBlZmZlY3RzIG9mIGdlbmVyYWwgbWVtb3J5IGNvcnJ1cHRpb24sIHdoaWNoIHRlbmQg
dG8gYmUgYmFkKS4KPj4+Cj4+PiBJdCBsb29rcyBhcyBpZiBpdCB3YW50cyB0byBiZSBhbiBleHRy
YSBmaWVsZCBpbiBhbiB4bWVtX3Bvb2wuCj4+IFF1ZXN0aW9uIGlzIHdoZXRoZXIgbG9nZ2luZyBt
b3JlIHRoYW4gdGhlIGZpcnN0IGNvcnJ1cHRpb24gZXZlciBpcwo+PiByZWFsbHkgYWxsIHRoYXQg
dXNlZnVsLgo+IAo+IFRydWUgLSBhcyBzb29uIGFzIG9uZSBiaXQgb2YgbWVtb3J5IGNvcnJ1cHRp
b24gaXMgZGV0ZWN0ZWQsIGFsbCBvdGhlcgo+IGJldHMgYXJlIG9mZi4KPiAKPiBNaWdodCBpdCBw
ZXJoYXBzIGJlIHBydWRlbnQgdG8gdGhlbiBwYW5pYygpIG9uIGEgcG9zaXRpdmUgZGV0ZWN0aW9u
IG9mCj4gbWVtb3J5IGNvcnJ1cHRpb24/CgpJbmRlZWQuCgo+Pj4+ICtib29sX3QgX194bWVtX3Bv
b2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsIHN0cnVjdCB4bWVtX3Bvb2wgCj4g
KnBvb2wpCj4+Pj4gK3sKPj4+PiArICAgIHJldHVybiBfX3htZW1fcG9vbF9jaGVja191bmxvY2tl
ZChmaWxlLCBsaW5lLCBwb29sID86IHhlbnBvb2wpOwo+Pj4gV2h5IHNob3VsZCBhIE5VTEwgcG9v
bCBiZSB0b2xlcmF0ZWQgaGVyZT8gIFRoaXMgaXMgZGVidWcgY29kZSBvbmx5LCBzbwo+Pj4gd2Ug
Y2FuIHJlcXVpcmUgYW5kIHRydXN0IHRoYXQgd2UgYXJlIGNhbGxlZCBhcHByb3ByaWF0ZWx5Lgo+
PiB4ZW5wb29sIGlzIG5vdCBhbmQgc2hvdWxkIG5vdCBiZSB2aXNpYmxlIHRvIGNvZGUgb3V0c2lk
ZSB0aGlzIGZpbGUuCj4gCj4gUXVpdGUsIGJ1dCB0aGUgb25seSBwbGF1c2libGUgZXh0ZXJuYWwg
Y2FsbGVycyB3aWxsIGJlIGNoZWNraW5nIHBvb2xzIG9mCj4gdGhlaXIgb3duLiAgVGhpcyBwYXRj
aCBhZGRzIGludGVybmFsIGNhbGxlcnMgZm9yIGNoZWNraW5nIHRoZSB4ZW5wb29sLgoKSWYgeW91
IGxvb2sgdXAgZWFybGllciBjb252ZXJzYXRpb24gb24gdGhpcyBwYXRjaCBhbmQgaXRzIG9yaWdp
biwgSQp0aGluayB5b3UnbGwgZmluZCB0aGF0IGl0IGlzIHNwZWNpZmljYWxseSBpbnRlbmRlZCBm
b3IgY2FsbHMgdG8gdGhpcyB0byBiZQphZGRhYmxlIGF0IGFyYml0cmFyeSBwbGFjZXMgaW4gdGhl
IGNvZGUuCgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:22:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:22:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Bkk-0000AH-Ql; Wed, 17 Dec 2014 10:22: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 1Y1Bkj-0000A9-CI
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 10:22:45 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	57/0C-25714-47951945; Wed, 17 Dec 2014 10:22:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418811762!13810242!1
X-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 9423 invoked from network); 17 Dec 2014 10:22:43 -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; 17 Dec 2014 10:22:43 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 10:22:42 +0000
Message-Id: <5491678102000078000502D0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 10:22:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com>
	<54916201020000780005026A@mail.emea.novell.com>
	<54915630.8020302@citrix.com>
In-Reply-To: <54915630.8020302@citrix.com>
Mime-Version: 1.0
Content-Length: 2501
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, ian.jackson@eu.citrix.com,
	mdontu@bitdefender.com, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDE3LjEyLjE0IGF0IDExOjA4LCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4gT24gMTcvMTIvMTQgMDk6NTksIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+PiBPbiAxNi4x
Mi4xNCBhdCAyMToyOCwgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+IHdyb3RlOgo+Pj4gT24g
MTYvMTIvMTQgMTk6MzMsIE1paGFpIERvbsibdSB3cm90ZToKPj4+PiArc3RhdGljIGJvb2xfdCBf
X3htZW1fcG9vbF9jaGVja19sb2NrZWQoY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsCj4+Pj4g
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0cnVjdCB4bWVt
X3Bvb2wgKnBvb2wpCj4+Pj4gK3sKPj4+PiArICAgIHVuc2lnbmVkIGludCBpOwo+Pj4+ICsgICAg
c3RhdGljIGJvb2xfdCBvbmNlID0gMTsKPj4+IFdoYXQgaXMgdGhpcyBzdGF0aWMgZG9pbmc/ICBT
dXJlbHkgY29ycnVwdGlvbiBjb3JydXB0aW9uIGluIG9uZSBwb29sIGhhcwo+Pj4gbm8gZWZmZWN0
IG9uIGNvcnJ1cHRpb24gaW4gYSBzZXBhcmF0ZSBwb29sIChvdGhlciB0aGFuIHRoZSB1c3VhbCBz
aWRlCj4+PiBlZmZlY3RzIG9mIGdlbmVyYWwgbWVtb3J5IGNvcnJ1cHRpb24sIHdoaWNoIHRlbmQg
dG8gYmUgYmFkKS4KPj4+Cj4+PiBJdCBsb29rcyBhcyBpZiBpdCB3YW50cyB0byBiZSBhbiBleHRy
YSBmaWVsZCBpbiBhbiB4bWVtX3Bvb2wuCj4+IFF1ZXN0aW9uIGlzIHdoZXRoZXIgbG9nZ2luZyBt
b3JlIHRoYW4gdGhlIGZpcnN0IGNvcnJ1cHRpb24gZXZlciBpcwo+PiByZWFsbHkgYWxsIHRoYXQg
dXNlZnVsLgo+IAo+IFRydWUgLSBhcyBzb29uIGFzIG9uZSBiaXQgb2YgbWVtb3J5IGNvcnJ1cHRp
b24gaXMgZGV0ZWN0ZWQsIGFsbCBvdGhlcgo+IGJldHMgYXJlIG9mZi4KPiAKPiBNaWdodCBpdCBw
ZXJoYXBzIGJlIHBydWRlbnQgdG8gdGhlbiBwYW5pYygpIG9uIGEgcG9zaXRpdmUgZGV0ZWN0aW9u
IG9mCj4gbWVtb3J5IGNvcnJ1cHRpb24/CgpJbmRlZWQuCgo+Pj4+ICtib29sX3QgX194bWVtX3Bv
b2xfY2hlY2soY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUsIHN0cnVjdCB4bWVtX3Bvb2wgCj4g
KnBvb2wpCj4+Pj4gK3sKPj4+PiArICAgIHJldHVybiBfX3htZW1fcG9vbF9jaGVja191bmxvY2tl
ZChmaWxlLCBsaW5lLCBwb29sID86IHhlbnBvb2wpOwo+Pj4gV2h5IHNob3VsZCBhIE5VTEwgcG9v
bCBiZSB0b2xlcmF0ZWQgaGVyZT8gIFRoaXMgaXMgZGVidWcgY29kZSBvbmx5LCBzbwo+Pj4gd2Ug
Y2FuIHJlcXVpcmUgYW5kIHRydXN0IHRoYXQgd2UgYXJlIGNhbGxlZCBhcHByb3ByaWF0ZWx5Lgo+
PiB4ZW5wb29sIGlzIG5vdCBhbmQgc2hvdWxkIG5vdCBiZSB2aXNpYmxlIHRvIGNvZGUgb3V0c2lk
ZSB0aGlzIGZpbGUuCj4gCj4gUXVpdGUsIGJ1dCB0aGUgb25seSBwbGF1c2libGUgZXh0ZXJuYWwg
Y2FsbGVycyB3aWxsIGJlIGNoZWNraW5nIHBvb2xzIG9mCj4gdGhlaXIgb3duLiAgVGhpcyBwYXRj
aCBhZGRzIGludGVybmFsIGNhbGxlcnMgZm9yIGNoZWNraW5nIHRoZSB4ZW5wb29sLgoKSWYgeW91
IGxvb2sgdXAgZWFybGllciBjb252ZXJzYXRpb24gb24gdGhpcyBwYXRjaCBhbmQgaXRzIG9yaWdp
biwgSQp0aGluayB5b3UnbGwgZmluZCB0aGF0IGl0IGlzIHNwZWNpZmljYWxseSBpbnRlbmRlZCBm
b3IgY2FsbHMgdG8gdGhpcyB0byBiZQphZGRhYmxlIGF0IGFyYml0cmFyeSBwbGFjZXMgaW4gdGhl
IGNvZGUuCgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:24:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10: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 1Y1BmN-0000HI-AO; Wed, 17 Dec 2014 10:24: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 1Y1BmL-0000HB-T9
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 10:24:25 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	28/04-09842-9D951945; Wed, 17 Dec 2014 10:24:25 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418811864!15821345!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26405 invoked from network); 17 Dec 2014 10:24:24 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 10:24:24 -0000
Received: by mail-wi0-f178.google.com with SMTP id em10so15444892wid.5
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 02:24: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=eRfx5hKv3fMJ9TIB5+Q/4VoKHbUK1Lc5vjJ1Qr5T+M8=;
	b=StS1gDI69U/2cWRlfHjyZskPdsnEVTgkEdJciCpxRJZPS1BIrNVzEtbvF89ryRPWNL
	uid+TCy/9rwwGIYjjOjqxCPs0asaf6ePlBX6+jKYR/wqywVvOqN4qqTTQS9vJLSUw5vY
	UFU9ZGm7X+LeFFzANC+E76y7Of8IUeyjNtoWEHJr015jKfWIhKYdiZWJuKWQauE0s9Qu
	ItJzTk5yg1lxafTzfBrx6v+VR+YbS60XXEhG0HrNr7xL8TNla7kCIpzCMQsXGIEW97Qk
	vNRtFPba6w4uHCRPY6eFuZRASUmIycAdHd8cUuM7NzQZ8Zj2UzVcX0pqGFTK2R+OQRJ+
	GD/A==
X-Gm-Message-State: ALoCoQl3lTJGEb5tO5znqAfvPEKo4Cr3zfM6h/OIDaPfpLU+B484ayN8U1Mbg5JT1tbvhmwv2pfR
X-Received: by 10.180.206.79 with SMTP id lm15mr4186154wic.67.1418811864587;
	Wed, 17 Dec 2014 02:24:24 -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
	mo12sm4497911wjc.35.2014.12.17.02.24.23
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Dec 2014 02:24:23 -0800 (PST)
Message-ID: <549159D4.2040304@linaro.org>
Date: Wed, 17 Dec 2014 10:24: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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?B?TWloYWkgRG9uyJt1?=
	<mdontu@bitdefender.com>, xen-devel@lists.xen.org
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
	<5490BFBD.7010809@citrix.com> <5490C22F.4020505@linaro.org>
	<549156C1.5000708@citrix.com>
In-Reply-To: <549156C1.5000708@citrix.com>
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 17/12/2014 10:11, Andrew Cooper wrote:
> On 16/12/14 23:37, Julien Grall wrote:
> Introducing a new bugframe is precicely what I meant by "this doesn't
> look hard".  x86 currently has one more bugframe than arm, being
> BUGFRAME_run_fn.

And how do you pass the pointer of the function? As I said, ARM lacks of 
%c because of compiler issue.

I'm out of idea on how to do simply on ARM. Let me know if you have a 
good solution.

What I meant with introduce a new bug frame adding BUGFRAM_dump_stack.

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 Dec 17 10:24:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10: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 1Y1BmN-0000HI-AO; Wed, 17 Dec 2014 10:24: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 1Y1BmL-0000HB-T9
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 10:24:25 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	28/04-09842-9D951945; Wed, 17 Dec 2014 10:24:25 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418811864!15821345!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26405 invoked from network); 17 Dec 2014 10:24:24 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 10:24:24 -0000
Received: by mail-wi0-f178.google.com with SMTP id em10so15444892wid.5
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 02:24: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=eRfx5hKv3fMJ9TIB5+Q/4VoKHbUK1Lc5vjJ1Qr5T+M8=;
	b=StS1gDI69U/2cWRlfHjyZskPdsnEVTgkEdJciCpxRJZPS1BIrNVzEtbvF89ryRPWNL
	uid+TCy/9rwwGIYjjOjqxCPs0asaf6ePlBX6+jKYR/wqywVvOqN4qqTTQS9vJLSUw5vY
	UFU9ZGm7X+LeFFzANC+E76y7Of8IUeyjNtoWEHJr015jKfWIhKYdiZWJuKWQauE0s9Qu
	ItJzTk5yg1lxafTzfBrx6v+VR+YbS60XXEhG0HrNr7xL8TNla7kCIpzCMQsXGIEW97Qk
	vNRtFPba6w4uHCRPY6eFuZRASUmIycAdHd8cUuM7NzQZ8Zj2UzVcX0pqGFTK2R+OQRJ+
	GD/A==
X-Gm-Message-State: ALoCoQl3lTJGEb5tO5znqAfvPEKo4Cr3zfM6h/OIDaPfpLU+B484ayN8U1Mbg5JT1tbvhmwv2pfR
X-Received: by 10.180.206.79 with SMTP id lm15mr4186154wic.67.1418811864587;
	Wed, 17 Dec 2014 02:24:24 -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
	mo12sm4497911wjc.35.2014.12.17.02.24.23
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Dec 2014 02:24:23 -0800 (PST)
Message-ID: <549159D4.2040304@linaro.org>
Date: Wed, 17 Dec 2014 10:24: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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?B?TWloYWkgRG9uyJt1?=
	<mdontu@bitdefender.com>, xen-devel@lists.xen.org
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
	<5490BFBD.7010809@citrix.com> <5490C22F.4020505@linaro.org>
	<549156C1.5000708@citrix.com>
In-Reply-To: <549156C1.5000708@citrix.com>
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 17/12/2014 10:11, Andrew Cooper wrote:
> On 16/12/14 23:37, Julien Grall wrote:
> Introducing a new bugframe is precicely what I meant by "this doesn't
> look hard".  x86 currently has one more bugframe than arm, being
> BUGFRAME_run_fn.

And how do you pass the pointer of the function? As I said, ARM lacks of 
%c because of compiler issue.

I'm out of idea on how to do simply on ARM. Let me know if you have a 
good solution.

What I meant with introduce a new bug frame adding BUGFRAM_dump_stack.

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 Dec 17 10:27:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Boh-0000QK-S2; Wed, 17 Dec 2014 10:26:51 +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 1Y1Bog-0000QC-BS
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 10:26:50 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	69/3D-02699-96A51945; Wed, 17 Dec 2014 10:26:49 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418812008!15609565!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8738 invoked from network); 17 Dec 2014 10:26:49 -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;
	17 Dec 2014 10:26:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205741187"
Message-ID: <54915A65.4030605@citrix.com>
Date: Wed, 17 Dec 2014 10:26:45 +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: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<x86@kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, 
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
	<mmarek@suse.cz>, <linux-kbuild@vger.kernel.org>
References: <1418809838-14123-1-git-send-email-jgross@suse.com>
	<1418809838-14123-2-git-send-email-jgross@suse.com>
In-Reply-To: <1418809838-14123-2-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [Patch V2 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 09:50, Juergen Gross wrote:
> Today there are several places in the kernel which build tables
> containing one entry for each possible Xen hypercall. Create an
> infrastructure to be able to generate these tables at build time.

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 Wed Dec 17 10:27:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Boh-0000QK-S2; Wed, 17 Dec 2014 10:26:51 +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 1Y1Bog-0000QC-BS
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 10:26:50 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	69/3D-02699-96A51945; Wed, 17 Dec 2014 10:26:49 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418812008!15609565!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8738 invoked from network); 17 Dec 2014 10:26:49 -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;
	17 Dec 2014 10:26:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205741187"
Message-ID: <54915A65.4030605@citrix.com>
Date: Wed, 17 Dec 2014 10:26:45 +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: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<x86@kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, 
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
	<mmarek@suse.cz>, <linux-kbuild@vger.kernel.org>
References: <1418809838-14123-1-git-send-email-jgross@suse.com>
	<1418809838-14123-2-git-send-email-jgross@suse.com>
In-Reply-To: <1418809838-14123-2-git-send-email-jgross@suse.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [Patch V2 1/4] xen: build infrastructure for
 generating hypercall depending symbols
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 09:50, Juergen Gross wrote:
> Today there are several places in the kernel which build tables
> containing one entry for each possible Xen hypercall. Create an
> infrastructure to be able to generate these tables at build time.

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 Wed Dec 17 10:27:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10: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 1Y1Bpf-0000XL-FH; Wed, 17 Dec 2014 10:27:51 +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 1Y1Bpe-0000X5-Df
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 10:27:50 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	78/BD-17735-5AA51945; Wed, 17 Dec 2014 10:27:49 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418812068!13992938!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 32412 invoked from network); 17 Dec 2014 10:27:49 -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 Dec 2014 10:27:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205272485"
Message-ID: <54915A85.10403@citrix.com>
Date: Wed, 17 Dec 2014 10:27:17 +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: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<x86@kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, 
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
	<mmarek@suse.cz>, <linux-kbuild@vger.kernel.org>
References: <1418809838-14123-1-git-send-email-jgross@suse.com>
	<1418809838-14123-5-git-send-email-jgross@suse.com>
In-Reply-To: <1418809838-14123-5-git-send-email-jgross@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [Patch V2 4/4] xen: use generated hypercall symbols
 in arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/12/14 09:50, Juergen Gross wrote:
> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
> use the auto generated symbol list.
> 
> This also corrects the wrong address of xen_hypercall_mca which was
> located 32 bytes higher than it should.
> 
> Symbol addresses have been verified to match the correct ones via
> objdump output.

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 Wed Dec 17 10:27:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10: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 1Y1Bpf-0000XL-FH; Wed, 17 Dec 2014 10:27:51 +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 1Y1Bpe-0000X5-Df
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 10:27:50 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	78/BD-17735-5AA51945; Wed, 17 Dec 2014 10:27:49 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418812068!13992938!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 32412 invoked from network); 17 Dec 2014 10:27:49 -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 Dec 2014 10:27:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205272485"
Message-ID: <54915A85.10403@citrix.com>
Date: Wed, 17 Dec 2014 10:27:17 +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: Juergen Gross <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
	<x86@kernel.org>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, 
	<david.vrabel@citrix.com>, <boris.ostrovsky@oracle.com>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
	<mmarek@suse.cz>, <linux-kbuild@vger.kernel.org>
References: <1418809838-14123-1-git-send-email-jgross@suse.com>
	<1418809838-14123-5-git-send-email-jgross@suse.com>
In-Reply-To: <1418809838-14123-5-git-send-email-jgross@suse.com>
X-DLP: MIA2
Subject: Re: [Xen-devel] [Patch V2 4/4] xen: use generated hypercall symbols
 in arch/x86/xen/xen-head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/12/14 09:50, Juergen Gross wrote:
> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
> use the auto generated symbol list.
> 
> This also corrects the wrong address of xen_hypercall_mca which was
> located 32 bytes higher than it should.
> 
> Symbol addresses have been verified to match the correct ones via
> objdump output.

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 Wed Dec 17 10:30:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BsF-0000jD-18; Wed, 17 Dec 2014 10:30:31 +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 1Y1BsD-0000iq-OO
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 10:30:29 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	7F/06-27584-24B51945; Wed, 17 Dec 2014 10:30:26 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418812225!9700361!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2472 invoked from network); 17 Dec 2014 10:30:25 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 10:30:25 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so19816218wgg.28
	for <xen-devel@lists.xenproject.org>;
	Wed, 17 Dec 2014 02:30: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=gPMw9n2dClrwQOC6bpnZCoIbDw1TyurhSZTuWzrUWng=;
	b=QSyCVBF6wXPA5Q7W6MClWCydfOSMlP4u8p2JFrICMXR15kmCiAX4MIwtFoPZMb7BGW
	6iSGc2M1sVWByC3cPqF0OIkoSGwlI5yieCQLCsC3jgNl9+JqCD10ODaXpp5VCOvClw62
	0UYS+wcX0ZcnB1yeUWV7g/VXcyGxf6fNUMkyqiMvVqRUptfNYH9fELbeI6Q9mN3pz6qK
	KOl2xQVN1bvD2gM9730auA54CCO06VJcnrXovGFl2R74jvwJqa9WXeeba/K08CVw8HUp
	VVCU0MlKrP4+HHP5tHeUf9SnEWFfeOD9QhPR6+S/t+KE1vsmnFzmNJLvlZ21mjWv/TQ+
	DGig==
X-Gm-Message-State: ALoCoQlgS+GHcX68ATkUhmAewzLAB4XO2j+/6KlkY+G0cxqtKSnnfHBvtDOUZ9w1YXD/i+k0xYdb
X-Received: by 10.194.161.202 with SMTP id xu10mr71760798wjb.4.1418812224908; 
	Wed, 17 Dec 2014 02:30:24 -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 cz3sm4531503wjb.23.2014.12.17.02.30.23
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Dec 2014 02:30:24 -0800 (PST)
Message-ID: <54915B3E.4010702@linaro.org>
Date: Wed, 17 Dec 2014 10:30:22 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
In-Reply-To: <549165F102000078000502B8@mail.emea.novell.com>
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com, tim@xen.org,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 17/12/2014 10:16, Jan Beulich wrote:
>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -2,6 +2,7 @@ obj-y += bitmap.o
>>   obj-y += core_parking.o
>>   obj-y += cpu.o
>>   obj-y += cpupool.o
>> +obj-y += device.o
>
> Shouldn't this instead be two lines, one using HAS_PCI and the second
> HAS_DEVICE_TREE?

When ARM will gain PCI will, it will fail to compile because device.o is 
included twice.

>
>> @@ -75,8 +76,19 @@ struct pci_dev {
>>   #define PT_FAULT_THRESHOLD 10
>>       } fault;
>>       u64 vf_rlen[6];
>> +
>> +    struct device dev;
>>   };
>
> I'm not convinced yet that growing this structure (of which we have
> quite many instances on some systems) is really worth it, in particular
> on x86 where we (so far) only have one device type anyway.

Actually this will growing by only sizeof (enum type) on x86.

Having a generic way to describe device will really help ARM code (see 
IOMMU).

If we don't have a such thing, we may need to duplicate quite a lots of 
code. Which will make hard to maintain.

>> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
>> +
>> +static inline struct pci_dev *dev_to_pci(struct device *dev)
>> +{
>> +    ASSERT(dev->type == DEV_PCI);
>> +
>> +    return container_of(dev, struct pci_dev, dev);
>> +}
>
> While the former is const-correct, I dislike the inability of passing
> pointers to const into helper functions like the latter. I can't think
> of a good solution other than introducing a second const variant
> of it, but I suppose we should try to find alternatives before
> adding such a construct that moves us in a direction opposite to
> getting our code more const-correct.

Oh right. I didn't though about that case. I will turn this inline 
function into a macro.

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 Dec 17 10:30:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1BsF-0000jD-18; Wed, 17 Dec 2014 10:30:31 +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 1Y1BsD-0000iq-OO
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 10:30:29 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	7F/06-27584-24B51945; Wed, 17 Dec 2014 10:30:26 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418812225!9700361!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2472 invoked from network); 17 Dec 2014 10:30:25 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 10:30:25 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so19816218wgg.28
	for <xen-devel@lists.xenproject.org>;
	Wed, 17 Dec 2014 02:30: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=gPMw9n2dClrwQOC6bpnZCoIbDw1TyurhSZTuWzrUWng=;
	b=QSyCVBF6wXPA5Q7W6MClWCydfOSMlP4u8p2JFrICMXR15kmCiAX4MIwtFoPZMb7BGW
	6iSGc2M1sVWByC3cPqF0OIkoSGwlI5yieCQLCsC3jgNl9+JqCD10ODaXpp5VCOvClw62
	0UYS+wcX0ZcnB1yeUWV7g/VXcyGxf6fNUMkyqiMvVqRUptfNYH9fELbeI6Q9mN3pz6qK
	KOl2xQVN1bvD2gM9730auA54CCO06VJcnrXovGFl2R74jvwJqa9WXeeba/K08CVw8HUp
	VVCU0MlKrP4+HHP5tHeUf9SnEWFfeOD9QhPR6+S/t+KE1vsmnFzmNJLvlZ21mjWv/TQ+
	DGig==
X-Gm-Message-State: ALoCoQlgS+GHcX68ATkUhmAewzLAB4XO2j+/6KlkY+G0cxqtKSnnfHBvtDOUZ9w1YXD/i+k0xYdb
X-Received: by 10.194.161.202 with SMTP id xu10mr71760798wjb.4.1418812224908; 
	Wed, 17 Dec 2014 02:30:24 -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 cz3sm4531503wjb.23.2014.12.17.02.30.23
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Dec 2014 02:30:24 -0800 (PST)
Message-ID: <54915B3E.4010702@linaro.org>
Date: Wed, 17 Dec 2014 10:30:22 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
In-Reply-To: <549165F102000078000502B8@mail.emea.novell.com>
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com, tim@xen.org,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 17/12/2014 10:16, Jan Beulich wrote:
>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -2,6 +2,7 @@ obj-y += bitmap.o
>>   obj-y += core_parking.o
>>   obj-y += cpu.o
>>   obj-y += cpupool.o
>> +obj-y += device.o
>
> Shouldn't this instead be two lines, one using HAS_PCI and the second
> HAS_DEVICE_TREE?

When ARM will gain PCI will, it will fail to compile because device.o is 
included twice.

>
>> @@ -75,8 +76,19 @@ struct pci_dev {
>>   #define PT_FAULT_THRESHOLD 10
>>       } fault;
>>       u64 vf_rlen[6];
>> +
>> +    struct device dev;
>>   };
>
> I'm not convinced yet that growing this structure (of which we have
> quite many instances on some systems) is really worth it, in particular
> on x86 where we (so far) only have one device type anyway.

Actually this will growing by only sizeof (enum type) on x86.

Having a generic way to describe device will really help ARM code (see 
IOMMU).

If we don't have a such thing, we may need to duplicate quite a lots of 
code. Which will make hard to maintain.

>> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
>> +
>> +static inline struct pci_dev *dev_to_pci(struct device *dev)
>> +{
>> +    ASSERT(dev->type == DEV_PCI);
>> +
>> +    return container_of(dev, struct pci_dev, dev);
>> +}
>
> While the former is const-correct, I dislike the inability of passing
> pointers to const into helper functions like the latter. I can't think
> of a good solution other than introducing a second const variant
> of it, but I suppose we should try to find alternatives before
> adding such a construct that moves us in a direction opposite to
> getting our code more const-correct.

Oh right. I didn't though about that case. I will turn this inline 
function into a macro.

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 Dec 17 10:39:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10: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 1Y1C0e-0000xr-2d; Wed, 17 Dec 2014 10:39:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Y1C0d-0000xm-7A
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 10:39:11 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	CF/F8-28865-E4D51945; Wed, 17 Dec 2014 10:39:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418812746!13817175!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28666 invoked from network); 17 Dec 2014 10:39:07 -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;
	17 Dec 2014 10:39:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205744039"
Message-ID: <54915D47.3020400@citrix.com>
Date: Wed, 17 Dec 2014 10:39:03 +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: Julien Grall <julien.grall@linaro.org>, =?UTF-8?B?TWloYWkgRG9uyJt1?=
	<mdontu@bitdefender.com>, <xen-devel@lists.xen.org>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
	<5490BFBD.7010809@citrix.com> <5490C22F.4020505@linaro.org>
	<549156C1.5000708@citrix.com> <549159D4.2040304@linaro.org>
In-Reply-To: <549159D4.2040304@linaro.org>
X-DLP: MIA1
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 10:24, Julien Grall wrote:
>
>
> On 17/12/2014 10:11, Andrew Cooper wrote:
>> On 16/12/14 23:37, Julien Grall wrote:
>> Introducing a new bugframe is precicely what I meant by "this doesn't
>> look hard".  x86 currently has one more bugframe than arm, being
>> BUGFRAME_run_fn.
>
> And how do you pass the pointer of the function? As I said, ARM lacks
> of %c because of compiler issue.
>
> I'm out of idea on how to do simply on ARM. Let me know if you have a
> good solution.
>
> What I meant with introduce a new bug frame adding BUGFRAM_dump_stack.
>
> Regards,
>

I don't know about good, but stringly typing the function pointer and
stashing it in the same way as the assert message would work.

(I can see now why you suggested BUGFRAME_dump_stack, but it would be
nice to find a more generic alternative if possible.)

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:39:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10: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 1Y1C0e-0000xr-2d; Wed, 17 Dec 2014 10:39:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Y1C0d-0000xm-7A
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 10:39:11 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	CF/F8-28865-E4D51945; Wed, 17 Dec 2014 10:39:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418812746!13817175!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28666 invoked from network); 17 Dec 2014 10:39:07 -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;
	17 Dec 2014 10:39:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205744039"
Message-ID: <54915D47.3020400@citrix.com>
Date: Wed, 17 Dec 2014 10:39:03 +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: Julien Grall <julien.grall@linaro.org>, =?UTF-8?B?TWloYWkgRG9uyJt1?=
	<mdontu@bitdefender.com>, <xen-devel@lists.xen.org>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
	<5490BFBD.7010809@citrix.com> <5490C22F.4020505@linaro.org>
	<549156C1.5000708@citrix.com> <549159D4.2040304@linaro.org>
In-Reply-To: <549159D4.2040304@linaro.org>
X-DLP: MIA1
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	jbeulich@suse.com, tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 10:24, Julien Grall wrote:
>
>
> On 17/12/2014 10:11, Andrew Cooper wrote:
>> On 16/12/14 23:37, Julien Grall wrote:
>> Introducing a new bugframe is precicely what I meant by "this doesn't
>> look hard".  x86 currently has one more bugframe than arm, being
>> BUGFRAME_run_fn.
>
> And how do you pass the pointer of the function? As I said, ARM lacks
> of %c because of compiler issue.
>
> I'm out of idea on how to do simply on ARM. Let me know if you have a
> good solution.
>
> What I meant with introduce a new bug frame adding BUGFRAM_dump_stack.
>
> Regards,
>

I don't know about good, but stringly typing the function pointer and
stashing it in the same way as the assert message would work.

(I can see now why you suggested BUGFRAME_dump_stack, but it would be
nice to find a more generic alternative if possible.)

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:40:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1C26-00012o-I2; Wed, 17 Dec 2014 10:40:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1C25-00012g-5l
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 10:40:41 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	A1/6B-02954-8AD51945; Wed, 17 Dec 2014 10:40:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418812839!15632789!1
X-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 28438 invoked from network); 17 Dec 2014 10:40:40 -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; 17 Dec 2014 10:40:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 10:40:39 +0000
Message-Id: <54916BB40200007800050317@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 10:40:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
	<5490BFBD.7010809@citrix.com> <5490C22F.4020505@linaro.org>
	<549156C1.5000708@citrix.com> <549159D4.2040304@linaro.org>
In-Reply-To: <549159D4.2040304@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, keir@xen.org, ian.campbell@citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	mdontu@bitdefender.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 11:24, <julien.grall@linaro.org> wrote:
> On 17/12/2014 10:11, Andrew Cooper wrote:
>> On 16/12/14 23:37, Julien Grall wrote:
>> Introducing a new bugframe is precicely what I meant by "this doesn't
>> look hard".  x86 currently has one more bugframe than arm, being
>> BUGFRAME_run_fn.
> 
> And how do you pass the pointer of the function? As I said, ARM lacks of 
> %c because of compiler issue.

First of all can you explain what compiler issue there is? Both
{arm,aarch64}_print_operand() handle 'c' (but of course I can't
tell whether correctly).

And then can't you possibly find ways to deal with the # prefix
added when not using 'c'? For the section name (if you need the
section split in the first place) I would think a # should be fine,
and the uses in expressions can surely be worked around by
interposing an assembler macro (even if that macro may end up
looking quite ugly).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:40:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1C26-00012o-I2; Wed, 17 Dec 2014 10:40:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1C25-00012g-5l
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 10:40:41 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	A1/6B-02954-8AD51945; Wed, 17 Dec 2014 10:40:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418812839!15632789!1
X-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 28438 invoked from network); 17 Dec 2014 10:40:40 -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; 17 Dec 2014 10:40:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 10:40:39 +0000
Message-Id: <54916BB40200007800050317@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 10:40:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
	<5490BFBD.7010809@citrix.com> <5490C22F.4020505@linaro.org>
	<549156C1.5000708@citrix.com> <549159D4.2040304@linaro.org>
In-Reply-To: <549159D4.2040304@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, keir@xen.org, ian.campbell@citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	mdontu@bitdefender.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 11:24, <julien.grall@linaro.org> wrote:
> On 17/12/2014 10:11, Andrew Cooper wrote:
>> On 16/12/14 23:37, Julien Grall wrote:
>> Introducing a new bugframe is precicely what I meant by "this doesn't
>> look hard".  x86 currently has one more bugframe than arm, being
>> BUGFRAME_run_fn.
> 
> And how do you pass the pointer of the function? As I said, ARM lacks of 
> %c because of compiler issue.

First of all can you explain what compiler issue there is? Both
{arm,aarch64}_print_operand() handle 'c' (but of course I can't
tell whether correctly).

And then can't you possibly find ways to deal with the # prefix
added when not using 'c'? For the section name (if you need the
section split in the first place) I would think a # should be fine,
and the uses in expressions can surely be worked around by
interposing an assembler macro (even if that macro may end up
looking quite ugly).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:46:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1C7P-0001YN-DY; Wed, 17 Dec 2014 10:46: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 1Y1C7N-0001YI-Gu
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 10:46:09 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	B1/DB-02696-0FE51945; Wed, 17 Dec 2014 10:46:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418813168!15638229!1
X-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 17322 invoked from network); 17 Dec 2014 10:46:08 -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; 17 Dec 2014 10:46:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 10:46:07 +0000
Message-Id: <54916CFA020000780005032F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 10:46:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
	<54915B3E.4010702@linaro.org>
In-Reply-To: <54915B3E.4010702@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com, tim@xen.org,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe 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 17.12.14 at 11:30, <julien.grall@linaro.org> wrote:
> On 17/12/2014 10:16, Jan Beulich wrote:
>>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>>> --- a/xen/common/Makefile
>>> +++ b/xen/common/Makefile
>>> @@ -2,6 +2,7 @@ obj-y += bitmap.o
>>>   obj-y += core_parking.o
>>>   obj-y += cpu.o
>>>   obj-y += cpupool.o
>>> +obj-y += device.o
>>
>> Shouldn't this instead be two lines, one using HAS_PCI and the second
>> HAS_DEVICE_TREE?
> 
> When ARM will gain PCI will, it will fail to compile because device.o is 
> included twice.

Not necessarily: If we don't do this already, we should eliminate
duplicates from $(obj-y) just like Linux does.

>>> @@ -75,8 +76,19 @@ struct pci_dev {
>>>   #define PT_FAULT_THRESHOLD 10
>>>       } fault;
>>>       u64 vf_rlen[6];
>>> +
>>> +    struct device dev;
>>>   };
>>
>> I'm not convinced yet that growing this structure (of which we have
>> quite many instances on some systems) is really worth it, in particular
>> on x86 where we (so far) only have one device type anyway.
> 
> Actually this will growing by only sizeof (enum type) on x86.

No, by 8 bytes (due to padding).

> Having a generic way to describe device will really help ARM code (see 
> IOMMU).
> 
> If we don't have a such thing, we may need to duplicate quite a lots of 
> code. Which will make hard to maintain.

Not really, if e.g. "device" was simply an alias of "pci_dev" on x86.

>>> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
>>> +
>>> +static inline struct pci_dev *dev_to_pci(struct device *dev)
>>> +{
>>> +    ASSERT(dev->type == DEV_PCI);
>>> +
>>> +    return container_of(dev, struct pci_dev, dev);
>>> +}
>>
>> While the former is const-correct, I dislike the inability of passing
>> pointers to const into helper functions like the latter. I can't think
>> of a good solution other than introducing a second const variant
>> of it, but I suppose we should try to find alternatives before
>> adding such a construct that moves us in a direction opposite to
>> getting our code more const-correct.
> 
> Oh right. I didn't though about that case. I will turn this inline 
> function into a macro.

I'm afraid that won't help, as you still need to specify a type as
2nd argument to container_of(), and that type can't be both
const and non-const at the same time, i.e. you can't easily
inherit the const-ness of the passed in pointer.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:46:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 10:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1C7P-0001YN-DY; Wed, 17 Dec 2014 10:46: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 1Y1C7N-0001YI-Gu
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 10:46:09 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	B1/DB-02696-0FE51945; Wed, 17 Dec 2014 10:46:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418813168!15638229!1
X-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 17322 invoked from network); 17 Dec 2014 10:46:08 -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; 17 Dec 2014 10:46:08 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 10:46:07 +0000
Message-Id: <54916CFA020000780005032F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 10:46:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
	<54915B3E.4010702@linaro.org>
In-Reply-To: <54915B3E.4010702@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com, tim@xen.org,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe 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 17.12.14 at 11:30, <julien.grall@linaro.org> wrote:
> On 17/12/2014 10:16, Jan Beulich wrote:
>>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>>> --- a/xen/common/Makefile
>>> +++ b/xen/common/Makefile
>>> @@ -2,6 +2,7 @@ obj-y += bitmap.o
>>>   obj-y += core_parking.o
>>>   obj-y += cpu.o
>>>   obj-y += cpupool.o
>>> +obj-y += device.o
>>
>> Shouldn't this instead be two lines, one using HAS_PCI and the second
>> HAS_DEVICE_TREE?
> 
> When ARM will gain PCI will, it will fail to compile because device.o is 
> included twice.

Not necessarily: If we don't do this already, we should eliminate
duplicates from $(obj-y) just like Linux does.

>>> @@ -75,8 +76,19 @@ struct pci_dev {
>>>   #define PT_FAULT_THRESHOLD 10
>>>       } fault;
>>>       u64 vf_rlen[6];
>>> +
>>> +    struct device dev;
>>>   };
>>
>> I'm not convinced yet that growing this structure (of which we have
>> quite many instances on some systems) is really worth it, in particular
>> on x86 where we (so far) only have one device type anyway.
> 
> Actually this will growing by only sizeof (enum type) on x86.

No, by 8 bytes (due to padding).

> Having a generic way to describe device will really help ARM code (see 
> IOMMU).
> 
> If we don't have a such thing, we may need to duplicate quite a lots of 
> code. Which will make hard to maintain.

Not really, if e.g. "device" was simply an alias of "pci_dev" on x86.

>>> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
>>> +
>>> +static inline struct pci_dev *dev_to_pci(struct device *dev)
>>> +{
>>> +    ASSERT(dev->type == DEV_PCI);
>>> +
>>> +    return container_of(dev, struct pci_dev, dev);
>>> +}
>>
>> While the former is const-correct, I dislike the inability of passing
>> pointers to const into helper functions like the latter. I can't think
>> of a good solution other than introducing a second const variant
>> of it, but I suppose we should try to find alternatives before
>> adding such a construct that moves us in a direction opposite to
>> getting our code more const-correct.
> 
> Oh right. I didn't though about that case. I will turn this inline 
> function into a macro.

I'm afraid that won't help, as you still need to specify a type as
2nd argument to container_of(), and that type can't be both
const and non-const at the same time, i.e. you can't easily
inherit the const-ness of the passed in pointer.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:48:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 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 1Y1C9F-0001e0-Tf; Wed, 17 Dec 2014 10:48:05 +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 1Y1C9D-0001dp-Fl
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 10:48:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8C/9C-15461-26F51945; Wed, 17 Dec 2014 10:48:02 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418813279!16141954!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28787 invoked from network); 17 Dec 2014 10:48:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 10:48:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205746920"
Message-ID: <54915F5D.6030906@citrix.com>
Date: Wed, 17 Dec 2014 10:47:57 +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: "Christopher S. Aker" <caker@theshore.net>, David Vrabel
	<david.vrabel@citrix.com>
References: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>	<548EC1DB.6070301@citrix.com>
	<0F780C62-4064-4227-9CCD-43FE21F968F0@theshore.net>
In-Reply-To: <0F780C62-4064-4227-9CCD-43FE21F968F0@theshore.net>
X-DLP: MIA1
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] WARNING: at drivers/xen/gntdev.c:426
 unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/12/14 23:04, Christopher S. Aker wrote:
> On Dec 15, 2014, at 6:11 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 11/12/14 15:12, Christopher S. Aker wrote:
>>> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
>>> Dom0: 3.17.4
>>>
>>> Things go badly after a day or four.  We've hit this on a number of previously healthy hosts, since moving from 3.10.x dom0 to 3.17.4:
>>>
>>> printk: 5441 messages suppressed.
>>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>>
>> Can you provide more details about your networking and storage setup.
>> In particular, do you have a domU providing networked storage (iscsi for
>> example) to other domains on the same host?
> 
> Certainly. Thanks for the response. We're not using iscsi, but we do
> have some serious kit going on. This is the setup:
> 
> Storage: BBU hardware RAID (LSI), SSD drives, LVM logical volumes
> exported to the guests via blkback.
> 
> Network: Four 10Gbit links, ixgbe, bonded, then bridged onto br0,
> exported via netback via vifs.

That hardware or configuration isn't that exciting or unusual.  What's
the total number of VIFs and VBDs you have?  It may be that you're just
running out of space in the maptrack table.  There's a command line
option to increase this (indirectly, by increasing the maximum number of
grant table frames with the gnttab_max_nr_frames option).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 10:48:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 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 1Y1C9F-0001e0-Tf; Wed, 17 Dec 2014 10:48:05 +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 1Y1C9D-0001dp-Fl
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 10:48:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8C/9C-15461-26F51945; Wed, 17 Dec 2014 10:48:02 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418813279!16141954!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28787 invoked from network); 17 Dec 2014 10:48:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 10:48:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205746920"
Message-ID: <54915F5D.6030906@citrix.com>
Date: Wed, 17 Dec 2014 10:47:57 +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: "Christopher S. Aker" <caker@theshore.net>, David Vrabel
	<david.vrabel@citrix.com>
References: <F8DF2DBE-7E43-4F1E-8303-6634693666F8@theshore.net>	<548EC1DB.6070301@citrix.com>
	<0F780C62-4064-4227-9CCD-43FE21F968F0@theshore.net>
In-Reply-To: <0F780C62-4064-4227-9CCD-43FE21F968F0@theshore.net>
X-DLP: MIA1
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] WARNING: at drivers/xen/gntdev.c:426
 unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/12/14 23:04, Christopher S. Aker wrote:
> On Dec 15, 2014, at 6:11 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 11/12/14 15:12, Christopher S. Aker wrote:
>>> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
>>> Dom0: 3.17.4
>>>
>>> Things go badly after a day or four.  We've hit this on a number of previously healthy hosts, since moving from 3.10.x dom0 to 3.17.4:
>>>
>>> printk: 5441 messages suppressed.
>>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>>> grant_table.c:567:d0 Failed to obtain maptrack handle.
>>
>> Can you provide more details about your networking and storage setup.
>> In particular, do you have a domU providing networked storage (iscsi for
>> example) to other domains on the same host?
> 
> Certainly. Thanks for the response. We're not using iscsi, but we do
> have some serious kit going on. This is the setup:
> 
> Storage: BBU hardware RAID (LSI), SSD drives, LVM logical volumes
> exported to the guests via blkback.
> 
> Network: Four 10Gbit links, ixgbe, bonded, then bridged onto br0,
> exported via netback via vifs.

That hardware or configuration isn't that exciting or unusual.  What's
the total number of VIFs and VBDs you have?  It may be that you're just
running out of space in the maptrack table.  There's a command line
option to increase this (indirectly, by increasing the maximum number of
grant table frames with the gnttab_max_nr_frames option).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 11:08:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 11:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1CSW-0002GV-Py; Wed, 17 Dec 2014 11:08:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1Y1CSV-0002GQ-2O
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 11:07:59 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8D/04-09842-E0461945; Wed, 17 Dec 2014 11:07:58 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418814476!16192315!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 14986 invoked from network); 17 Dec 2014 11:07:57 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-8.tower-21.messagelabs.com with SMTP;
	17 Dec 2014 11:07:57 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 17 Dec 2014 03:07:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="430097554"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by FMSMGA003.fm.intel.com with ESMTP; 17 Dec 2014 02:56:27 -0800
Date: Wed, 17 Dec 2014 19:07:33 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141217110733.GC3105@pengc-linux.bj.intel.com>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141216085559.GB3105@pengc-linux.bj.intel.com>
	<54900B91020000780004FCC2@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54900B91020000780004FCC2@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, George.Dunlap@eu.citrix.com,
	andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, will.auld@intel.com, keir@xen.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
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 Tue, Dec 16, 2014 at 09:38:09AM +0000, Jan Beulich wrote:
> >>> On 16.12.14 at 09:55, <chao.p.peng@linux.intel.com> wrote:
> > Any comments from you? It would be greatly appreciated if you can look
> > at this when you have time. Your comments are always important to me :)
> 
> I don't think I have to say much here:
> 
> > On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote:
> >> Implementation Description
> >> ==========================
> >> In this design, one principal is that only implementing the cache
> >> enforcement mechanism in hypervisor but leaving the cache allocation
> >> policy to user space tool stack. In this way some complex governors then
> >> can be implemented in tool stack. 
> 
> With this, the changes to the hypervisor ought to be quite limited,
> even if length of the list you give seems long at a first glance, and
> hence I'm fine with the concept.
Thanks for your input.
> 
> >> Hardware Limitation & Performance Improvement
> >> =============================================
> >> As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
> >> switch. If the change is frequent then hardware may fail to strictly
> >> enforce the cache allocation basing on the specified COS.
> 
> This certainly would deserve a little more explanation: What's the
> value of the functionality if one can't rely on it being enforced by
> hardware at all times?
OK. The hardware just can't enforce that strictly when cos is changed
frequently. But the performance is likely better overall because CAT limits
the amount of thrashing that the lower priority VM gets more cache.

If affinitized mode can be used, then strictly enforcement is guaranteed
by hardware. This is actually useful for scenarios like OpenStack NFV appliance
where vcpu are affinitized to specific logical threads.

Thanks,
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 Wed Dec 17 11:08:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 11:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1CSW-0002GV-Py; Wed, 17 Dec 2014 11:08:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1Y1CSV-0002GQ-2O
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 11:07:59 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	8D/04-09842-E0461945; Wed, 17 Dec 2014 11:07:58 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418814476!16192315!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 14986 invoked from network); 17 Dec 2014 11:07:57 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-8.tower-21.messagelabs.com with SMTP;
	17 Dec 2014 11:07:57 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 17 Dec 2014 03:07:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="430097554"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by FMSMGA003.fm.intel.com with ESMTP; 17 Dec 2014 02:56:27 -0800
Date: Wed, 17 Dec 2014 19:07:33 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141217110733.GC3105@pengc-linux.bj.intel.com>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141216085559.GB3105@pengc-linux.bj.intel.com>
	<54900B91020000780004FCC2@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54900B91020000780004FCC2@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, George.Dunlap@eu.citrix.com,
	andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, will.auld@intel.com, keir@xen.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
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 Tue, Dec 16, 2014 at 09:38:09AM +0000, Jan Beulich wrote:
> >>> On 16.12.14 at 09:55, <chao.p.peng@linux.intel.com> wrote:
> > Any comments from you? It would be greatly appreciated if you can look
> > at this when you have time. Your comments are always important to me :)
> 
> I don't think I have to say much here:
> 
> > On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote:
> >> Implementation Description
> >> ==========================
> >> In this design, one principal is that only implementing the cache
> >> enforcement mechanism in hypervisor but leaving the cache allocation
> >> policy to user space tool stack. In this way some complex governors then
> >> can be implemented in tool stack. 
> 
> With this, the changes to the hypervisor ought to be quite limited,
> even if length of the list you give seems long at a first glance, and
> hence I'm fine with the concept.
Thanks for your input.
> 
> >> Hardware Limitation & Performance Improvement
> >> =============================================
> >> As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
> >> switch. If the change is frequent then hardware may fail to strictly
> >> enforce the cache allocation basing on the specified COS.
> 
> This certainly would deserve a little more explanation: What's the
> value of the functionality if one can't rely on it being enforced by
> hardware at all times?
OK. The hardware just can't enforce that strictly when cos is changed
frequently. But the performance is likely better overall because CAT limits
the amount of thrashing that the lower priority VM gets more cache.

If affinitized mode can be used, then strictly enforcement is guaranteed
by hardware. This is actually useful for scenarios like OpenStack NFV appliance
where vcpu are affinitized to specific logical threads.

Thanks,
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 Wed Dec 17 11:40:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 11:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Cxh-00033L-2x; Wed, 17 Dec 2014 11:40:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Y1Cxf-00033G-QH
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 11:40:12 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	04/08-02576-B9B61945; Wed, 17 Dec 2014 11:40:11 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418816408!15665476!1
X-Originating-IP: [66.165.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 2636 invoked from network); 17 Dec 2014 11:40:09 -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;
	17 Dec 2014 11:40:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205758065"
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.210.2;
	Wed, 17 Dec 2014 06:40:06 -0500
Message-ID: <54916B95.3000609@citrix.com>
Date: Wed, 17 Dec 2014 12:40:05 +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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel
	<xen-devel@lists.xenproject.org>
References: <54906D3D.2060807@citrix.com> <549072FE.40500@citrix.com>
In-Reply-To: <549072FE.40500@citrix.com>
Content-Length:120696
X-DLP: MIA1
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] IO-APIC interrupts getting stuck
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RWwgMTYvMTIvMTQgYSBsZXMgMTguNTksIEFuZHJldyBDb29wZXIgaGEgZXNjcml0Ogo+IE9uIDE2
LzEyLzE0IDE3OjM0LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiBIZWxsbywKPj4KPj4gV2hp
bGUgd29ya2luZyBvbiB0aGUgRnJlZUJTRCBQVkggRG9tMCBwb3J0IEkndmUgcmVhbGl6ZWQgdGhh
dCBJTy1BUElDIAo+PiBpbnRlcnJ1cHRzIGdldCBzdHVjayBpbiBhIHZlcnkgc3RyYW5nZSBzdGF0
ZSB2ZXJ5IGVhc2lseSB3aXRoIHRoZSAKPj4gY3VycmVudCBQSVJRIGltcGxlbWVudGF0aW9uIHRo
YXQgSSdtIHVzaW5nIG9uIEZyZWVCU0QuCj4+Cj4+IFNpbmNlIEknbSBub3Qgc3VyZSB3aGF0IGlz
IGdvaW5nIG9uLCBJIHdvdWxkIGxpa2UgdG8gYXNrIGZvciBzb21lIAo+PiBmZWVkYmFjayBhbmQg
cG9zc2libGUgc29sdXRpb25zLCBiZWNhdXNlIGF0IHRoaXMgcG9pbnQgSSdtIHJ1bm5pbmcgb3V0
IAo+PiBvZiBpZGVhcyBvZiB3aGF0J3MgaGFwcGVuaW5nLgo+Pgo+PiBJbiB0aGlzIGNhc2UgSSdt
IGdvaW5nIHRvIHVzZSBJUlEgMTcgYXMgYW4gZXhhbXBsZSwgd2hpY2ggaXMgc2hhcmVkIAo+PiBi
ZXR3ZWVuIGFuIEludGVsKFIpIFBSTy8xMDAwIG5pYywgYSBCcm9hZGNvbSBOZXRYdHJlbWUgR2ln
YWJpdCBuaWMgYW5kIAo+PiBhbiBJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIu
Cj4+Cj4+IFVzdWFsbHkgZHVyaW5nIHRoZSBib290IHByb2Nlc3MsIG9yIHZlcnkgc2hvcnRseSBh
ZnRlciBpdCwgRG9tMCBsb29zZXMgCj4+IGludGVycnVwdHMgZnJvbSBJUlEgMTcsIGR1bXBpbmcg
SVJRIGluZm9ybWF0aW9uIGZyb20gWGVuICgnaScga2V5KSwgCj4+IGdpdmVzIHRoZSBmb2xsb3dp
bmcgb3V0cHV0Ogo+Pgo+PiAoWEVOKSAgICBJUlE6ICAxNyBhZmZpbml0eTowMDAwMDAwMSB2ZWM6
YTggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFp
bi1saXN0PTA6IDE3KC0tLSksCj4+IC4uLgo+PiAoWEVOKSAgICAgSVJRIDE3IFZlYzE2ODoKPj4g
KFhFTikgICAgICAgQXBpYyAweDAwLCBQaW4gMTc6IHZlYz1hOCBkZWxpdmVyeT1Mb1ByaSBkZXN0
PUwgc3RhdHVzPTEgcG9sYXJpdHk9MSBpcnI9MSB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQo+Pgo+
PiBJJ3ZlIGFsc28gYWRkZWQgc29tZSBldmVudCBjaGFubmVsIGRlYnVnIGZ1bmN0aW9ucyB0byB0
aGUgRnJlZUJTRCAKPj4gaW4ta2VybmVsIGRlYnVnZ2VyIGluIG9yZGVyIHRvIHByaW50IHRoZSBz
dGF0dXMgb2YgZXZlbnQgY2hhbm5lbHM6Cj4+Cj4+IFBvcnQgMTUgVHlwZTogUElSUQo+PiAgICAg
ICAgIFBpcnE6IDE3IEFjdGl2ZUhpOiAwIEVkZ2VUcmlnZ2VyOiAwIE5lZWRzRU9JOiAxCj4+ICAg
ICAgICAgTWFza2VkOiAwIFBlbmRpbmc6IDAKPj4gICAgICAgICBQZXItQ1BVIE1hc2tzOiBjcHUj
MDogMCBjcHUjMTogMCBjcHUjMjogMSBjcHUjMzogMCBjcHUjNDogMCBjcHUjNTogMCBjcHUjNjog
MCBjcHUjNzogMAo+Pgo+PiBBbmQgdGhlIGNvcnJlc3BvbmRpbmcgbGluZSBmcm9tIHRoZSBYZW4g
J2UnIGRlYnVnIGtleToKPj4KPj4gKFhFTikgICAgICAgMTUgWzAvMC8xXTogcz00IG49MiB4PTAg
cD0xNyBpPTE3Cj4+Cj4+IFRoaXMgbWFrZXMgbWUgdGhpbmcgdGhhdCB0aGUgRnJlZUJTRCBrZXJu
ZWwgaXMgZmFpbGluZyB0byBFT0kgdGhlIAo+PiB2ZWN0b3IgKGJlY2F1c2Ugb2YgdGhlIGlycj0x
IGluIHRoZSBYZW4gSVJRIGRlYnVnIGluZm8pLCBzbyBJJ3ZlIGFsc28gCj4+IGFkZGVkIGEgZnVu
Y3Rpb24gdG8gdGhlIGRlYnVnZ2VyIHRoYXQgYWxsb3dzIG1lIHRvIEVPSSBhIHZlY3RvciBmcm9t
IAo+PiBpdC4gQnV0IGV2ZW4gYWZ0ZXIgaXNzdWluZyBhIFBIWVNERVZPUF9lb2kgaHlwZXJjYWxs
IG9uIHRoZSBhZmZlY3RlZCAKPj4gUElSUSAoMTcpLCB0aGUgc3RhdHVzIGlzIGV4YWN0bHkgdGhl
IHNhbWUsIGJlY2F1c2UgcGlycS0+bWFza2VkID09IDAsIAo+PiBzbyBkZXNjX2d1ZXN0X2VvaSBm
YWlscyB0byBFT0kgdGhlIHZlY3RvciAoc2VlIHhlbi9hcmNoL3g4Ni9pcnEuYzoxNDMzKS4KPj4K
Pj4gU28gbm93IEknbSB3b25kZXJpbmcsIGhvdyBjYW4gSSAidW5zdHVjayIgdGhpcyBJUlEsIGFu
ZCBob3cgZGlkIGl0IGdldCAKPj4gaW50byB0aGlzIHN0cmFuZ2Ugc3RhdGU/Cj4+Cj4+IFJvZ2Vy
Lgo+IAo+IERvIHlvdSBoYXZlIGEgeGVuIGRtZXNnIHdpdGggZnVsbCBkZWJ1Z2dpbmc/ICBBY2Nv
cmRpbmcgdG8gdGhlIGZpcnN0Cj4gbGluZSBmcm9tICdpJywgWGVuIGJlbGlldmVzIHRoYXQgdGhl
IGlycSBpbiBxdWVzdGlvbiBpcyBub3QgaW4gbmVlZCBvZgo+IGFuIEVPSSwgd2hpY2ggaXMgY2xl
YXJseSBjb250cmFyeSB0byB0aGUgSU9BUElDcyB2aWV3IG9mIHRoZSB3b3JsZC4KPiAKPiBTb21l
IHJhbmRvbSBzdWdnZXN0aW9uczogZG9lcyBhbHRlcmluZyBpbnRlcnJ1cHQgcmVtYXBwaW5nIG1h
a2UgYQo+IGRpZmZlcmVuY2U/IGRvZXMgYWx0ZXJpbmcgdGhlIGlvYXBpY19hY2tfbW9kZSBtYWtl
IGEgZGlmZmVyZW5jZT8KCkkgaGF2ZW4ndCBiZWVuIGFibGUgdG8gZ2V0IGludG8gdGhpcyBzdHVj
ayBzdGF0ZSB3aXRoIGlvYXBpY19hY2s9b2xkLCAKYnV0IEkgaGF2ZSBhbm90aGVyIGJveCB3aXRo
IHRoZSBzYW1lIGhhcmR3YXJlIHJ1bm5pbmcgYSBMaW51eCBQVkggRG9tMCAKd2l0aCBpb2FwaWNf
YWNrPW5ldyB3aGljaCBkb2Vzbid0IGV4aGliaXQgdGhpcyBpc3N1ZSBBRkFJQ1QuIFNvIGl0J3Mg
CmVpdGhlciBhIHByb2JsZW0gaW4gdGhlIFBJUlEgaW1wbGVtZW50YXRpb24gb24gRnJlZUJTRCwg
b3Igc29tZSBxdWljayAKb24gdGhlIGhhcmR3YXJlIHRoYXQncyB0cmlnZ2VyZWQgYnkgdGhlIGlt
cGxlbWVudGF0aW9uIGluIEZyZWVCU0QuCgpIZXJlIGlzIHRoZSBmdWxsIGRtZXNnOgoKT0sgc2V0
IGh3LnBjaS5lbmFibGVfbXNpeD0wCk9LIHNldCBody5wY2kuZW5hYmxlX21zaT0wCk9LIGJvb3QK
Qm9vdGluZy4uLgogWGVuIDQuNS4wLXJjCihYRU4pIFhlbiB2ZXJzaW9uIDQuNS4wLXJjIChyb290
QCkgKGdjYzQ3IChGcmVlQlNEIFBvcnRzIENvbGxlY3Rpb24pIDQuNy40KSBkZWJ1Zz15IFRodSBE
ZWMgMTEgMTE6NTg6NDIgVVRDIDIwMTQKKFhFTikgTGF0ZXN0IENoYW5nZVNldDogVGh1IERlYyAx
MSAxMjo1MDo1NSAyMDE0ICswMTAwIGdpdDo0YTZjOTM1CihYRU4pIEJvb3Rsb2FkZXI6IHVua25v
d24KKFhFTikgQ29tbWFuZCBsaW5lOiBkb20wX21lbT0yMDQ4TSBpb21tdT1kZWJ1Zyxuby1pbnRy
ZW1hcCBkb20wX21heF92Y3B1cz04IGRvbTBwdmg9MSBndWVzdF9sb2dsdmw9YWxsIGxvZ2x2bD1h
bGwgY29uc29sZT1jb20xIG5taT1kb20wCihYRU4pIFZpZGVvIGluZm9ybWF0aW9uOgooWEVOKSAg
VkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9udCA4eDE2CihYRU4pICBWQkUvRERDIG1ldGhvZHM6
IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDEgc2Vjb25kcwooWEVOKSAgRURJRCBpbmZvIG5vdCBy
ZXRyaWV2ZWQgYmVjYXVzZSBvZiByZWFzb25zIHVua25vd24KKFhFTikgRGlzYyBpbmZvcm1hdGlv
bjoKKFhFTikgIEZvdW5kIDEgTUJSIHNpZ25hdHVyZXMKKFhFTikgIEZvdW5kIDIgRUREIGluZm9y
bWF0aW9uIHN0cnVjdHVyZXMKKFhFTikgWGVuLWU4MjAgUkFNIG1hcDoKKFhFTikgIDAwMDAwMDAw
MDAwMDAwMDAgLSAwMDAwMDAwMDAwMDkyODAwICh1c2FibGUpCihYRU4pICAwMDAwMDAwMDAwMGYw
MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDAwMTAwMDAw
IC0gMDAwMDAwMDBkZmRmOWMwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDBkZmRmOWMwMCAtIDAw
MDAwMDAwZGZlNGJjMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAwMDBkZmU0YmMwMCAtIDAwMDAw
MDAwZGZlNGRjMDAgKEFDUEkgZGF0YSkKKFhFTikgIDAwMDAwMDAwZGZlNGRjMDAgLSAwMDAwMDAw
MGUwMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZjgwMDAwMDAgLSAwMDAwMDAwMGZk
MDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmUwMDAwMDAgLSAwMDAwMDAwMGZlZDAw
NDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZjAwMDAw
IChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmZiMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChy
ZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMWEwMDAwMDAwICh1c2Fi
bGUpCihYRU4pIEFDUEk6IFJTRFAgMDAwRkVDMzAsIDAwMjQgKHIyIERFTEwgICkKKFhFTikgQUNQ
STogWFNEVCAwMDBGQ0NDNywgMDA3QyAocjEgREVMTCAgICBCMTBLICAgICAgICAgIDE1IEFTTCAg
ICAgICAgNjEpCihYRU4pIEFDUEk6IEZBQ1AgMDAwRkNEQjcsIDAwRjQgKHIzIERFTEwgICAgQjEw
SyAgICAgICAgICAxNSBBU0wgICAgICAgIDYxKQooWEVOKSBBQ1BJOiBEU0RUIEZGRTlFOTUxLCA0
QTc0IChyMSAgIERFTEwgICAgZHRfZXggICAgIDEwMDAgSU5UTCAyMDA1MDYyNCkKKFhFTikgQUNQ
STogRkFDUyBERkRGOUMwMCwgMDA0MAooWEVOKSBBQ1BJOiBTU0RUIEZGRUEzNEQ2LCAwMDlDIChy
MSAgIERFTEwgICAgc3RfZXggICAgIDEwMDAgSU5UTCAyMDA1MDYyNCkKKFhFTikgQUNQSTogQVBJ
QyAwMDBGQ0VBQiwgMDE1RSAocjEgREVMTCAgICBCMTBLICAgICAgICAgIDE1IEFTTCAgICAgICAg
NjEpCihYRU4pIEFDUEk6IEJPT1QgMDAwRkQwMDksIDAwMjggKHIxIERFTEwgICAgQjEwSyAgICAg
ICAgICAxNSBBU0wgICAgICAgIDYxKQooWEVOKSBBQ1BJOiBBU0YhIDAwMEZEMDMxLCAwMDk2IChy
MzIgREVMTCAgICBCMTBLICAgICAgICAgIDE1IEFTTCAgICAgICAgNjEpCihYRU4pIEFDUEk6IE1D
RkcgMDAwRkQwQzcsIDAwM0MgKHIxIERFTEwgICAgQjEwSyAgICAgICAgICAxNSBBU0wgICAgICAg
IDYxKQooWEVOKSBBQ1BJOiBIUEVUIDAwMEZEMTAzLCAwMDM4IChyMSBERUxMICAgIEIxMEsgICAg
ICAgICAgMTUgQVNMICAgICAgICA2MSkKKFhFTikgQUNQSTogVENQQSAwMDBGRDM1RiwgMDAzMiAo
cjEgREVMTCAgICBCMTBLICAgICAgICAgIDE1IEFTTCAgICAgICAgNjEpCihYRU4pIEFDUEk6IERN
QVIgMDAwRkQzOTEsIDAwQzggKHIxIERFTEwgICAgQjEwSyAgICAgICAgICAxNSBBU0wgICAgICAg
IDYxKQooWEVOKSBBQ1BJOiBTTElDIDAwMEZEMTNCLCAwMTc2IChyMSBERUxMICAgIEIxMEsgICAg
ICAgICAgMTUgQVNMICAgICAgICA2MSkKKFhFTikgQUNQSTogU1NEVCBERkU0REMwMCwgMTVDNCAo
cjEgIElOVEVMIFBQTSBSQ00gIDgwMDAwMDAxIElOVEwgMjAwNjExMDkpCihYRU4pIFN5c3RlbSBS
QU06IDYxNDFNQiAoNjI4ODk0MGtCKQooWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQK
KFhFTikgRmFraW5nIGEgbm9kZSBhdCAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAxYTAwMDAwMDAK
KFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQKKFhFTikgRE1JIDIuNSBwcmVzZW50LgooWEVO
KSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0CihYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6
IDB4ODA4CihYRU4pIEFDUEk6IFNMRUVQIElORk86IHBtMXhfY250WzE6ODA0LDE6MF0sIHBtMXhf
ZXZ0WzE6ODAwLDE6MF0KKFhFTikgQUNQSTogICAgICAgICAgICAgd2FrZXVwX3ZlY1tkZmRmOWMw
Y10sIHZlY19zaXplWzIwXQooWEVOKSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAw
MAooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVk
KQooWEVOKSBQcm9jZXNzb3IgIzAgNzoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29y
ICMyIDc6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNd
IGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjNCA3OjEwIEFQSUMgdmVy
c2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDA2XSBl
bmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzYgNzoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkKKFhFTikgUHJv
Y2Vzc29yICMxIDc6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MDZdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjMyA3OjEwIEFQ
SUMgdmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA3XSBsYXBpY19pZFsw
eDA1XSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzUgNzoxMCBBUElDIHZlcnNpb24gMjEKKFhF
TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOF0gbGFwaWNfaWRbMHgwN10gZW5hYmxlZCkKKFhF
TikgUHJvY2Vzc29yICM3IDc6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4MDldIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDBhXSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwYl0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4pIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4MGNdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDBkXSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwZV0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4pIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MGZdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDEwXSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgxMV0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4pIEFDUEk6
IExBUElDIChhY3BpX2lkWzB4MTJdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDEzXSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgxNF0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4pIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MTVdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDE2XSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikg
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxN10gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4p
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MThdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDE5XSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhF
TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxYV0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihY
RU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MWJdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQoo
WEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDFjXSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkK
KFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxZF0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQp
CihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MWVdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVk
KQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDFmXSBsYXBpY19pZFsweDAwXSBkaXNhYmxl
ZCkKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyMF0gbGFwaWNfaWRbMHgwMF0gZGlzYWJs
ZWQpCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweGZmXSBoaWdoIGxldmVsIGxpbnRb
MHgxXSkKKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA4XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdz
aV9iYXNlWzBdKQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgOCwgdmVyc2lvbiAzMiwgYWRkcmVz
cyAweGZlYzAwMDAwLCBHU0kgMC0yMwooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDldIGFkZHJl
c3NbMHhmZWM4MDAwMF0gZ3NpX2Jhc2VbMjRdKQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgOSwg
dmVyc2lvbiAzMiwgYWRkcmVzcyAweGZlYzgwMDAwLCBHU0kgMjQtNDcKKFhFTikgQUNQSTogSU5U
X1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKKFhFTikgQUNQ
STogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBsZXZlbCkK
KFhFTikgQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBBQ1BJOiBJUlEyIHVzZWQg
Ynkgb3ZlcnJpZGUuCihYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KKFhFTikgRW5h
YmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDIgSS9PIEFQSUNzCihYRU4pIEFDUEk6IEhQ
RVQgaWQ6IDB4ODA4NmEzMDEgYmFzZTogMHhmZWQwMDAwMAooWEVOKSBbVlQtRF1kbWFyLmM6Nzg4
OiBIb3N0IGFkZHJlc3Mgd2lkdGggMzYKKFhFTikgW1ZULURdZG1hci5jOjgwMjogZm91bmQgQUNQ
SV9ETUFSX0RSSEQ6CihYRU4pIFtWVC1EXWRtYXIuYzo0NzI6ICAgZG1hcnUtPmFkZHJlc3MgPSBm
ZWRjMDAwMAooWEVOKSBbVlQtRF1pb21tdS5jOjExNDY6IGRyaGQtPmFkZHJlc3MgPSBmZWRjMDAw
MCBpb21tdS0+cmVnID0gZmZmZjgyYzAwMDIwMTAwMAooWEVOKSBbVlQtRF1pb21tdS5jOjExNDg6
IGNhcCA9IGM5MDc4MDEwNmYwNDYyIGVjYXAgPSBmMDIwZmUKKFhFTikgW1ZULURdZG1hci5jOjM5
NzogIElPQVBJQzogMDAwMDowMDoxMy4wCihYRU4pIFtWVC1EXWRtYXIuYzozOTc6ICBJT0FQSUM6
IDAwMDA6MDA6MWYuNwooWEVOKSBbVlQtRF1kbWFyLmM6NDg2OiAgIGZsYWdzOiBJTkNMVURFX0FM
TAooWEVOKSBbVlQtRF1kbWFyLmM6ODA3OiBmb3VuZCBBQ1BJX0RNQVJfUk1SUjoKKFhFTikgW1ZU
LURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFkLjAKKFhFTikgW1ZULURdZG1hci5j
OjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFkLjEKKFhFTikgW1ZULURdZG1hci5jOjM4MzogIGVu
ZHBvaW50OiAwMDAwOjAwOjFkLjIKKFhFTikgW1ZULURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAw
MDAwOjAwOjFkLjcKKFhFTikgW1ZULURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFh
LjAKKFhFTikgW1ZULURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFhLjEKKFhFTikg
W1ZULURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFhLjIKKFhFTikgW1ZULURdZG1h
ci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFhLjcKKFhFTikgW1ZULURdZG1hci5jOjY3Njog
ICBSTVJSIHJlZ2lvbjogYmFzZV9hZGRyIGRmZTU4MDAwIGVuZF9hZGRyZXNzIGRmZTZmZmZmCihY
RU4pIFtWVC1EXWRtYXIuYzo4MTI6IGZvdW5kIEFDUElfRE1BUl9BVFNSOgooWEVOKSBbVlQtRF1k
bWFyLmM6NzA1OiAgIGF0c3J1LT5hbGxfcG9ydHM6IDAKKFhFTikgW1ZULURdZG1hci5jOjM1Mzog
IGJyaWRnZTogMDAwMDowMDowMS4wIHN0YXJ0PTAgc2VjPTEgc3ViPTEKKFhFTikgW1ZULURdZG1h
ci5jOjM1MzogIGJyaWRnZTogMDAwMDowMDowMy4wIHN0YXJ0PTAgc2VjPTIgc3ViPTIKKFhFTikg
W1ZULURdZG1hci5jOjM1MzogIGJyaWRnZTogMDAwMDowMDowNy4wIHN0YXJ0PTAgc2VjPTMgc3Vi
PTMKKFhFTikgRVJTVCB0YWJsZSB3YXMgbm90IGZvdW5kCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQp
IGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgooWEVOKSBTTVA6IEFsbG93aW5nIDMy
IENQVXMgKDI0IGhvdHBsdWcgQ1BVcykKKFhFTikgSVJRIGxpbWl0czogNDggR1NJLCAxNTA0IE1T
SS9NU0ktWAooWEVOKSBVc2luZyBzY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVk
aXQpCihYRU4pIERldGVjdGVkIDMwNjYuODg1IE1IeiBwcm9jZXNzb3IuCihYRU4pIEluaXRpbmcg
bWVtb3J5IHNoYXJpbmcuCihYRU4pIG1jZV9pbnRlbC5jOjcxOTogTUNBIENhcGFiaWxpdHk6IEJD
QVNUIDEgU0VSIDAgQ01DSSAxIGZpcnN0YmFuayAwIGV4dGVuZGVkIE1DRSBNU1IgMAooWEVOKSBJ
bnRlbCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkCihYRU4pIGFsdCB0YWJsZSBmZmZm
ODJkMDgwMmQ5ZTEwIC0+IGZmZmY4MmQwODAyZGFlMzAKKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3Vy
YXRpb24gMDogYmFzZSBmODAwMDAwMCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSAzZgooWEVOKSBQ
Q0k6IE1DRkcgYXJlYSBhdCBmODAwMDAwMCByZXNlcnZlZCBpbiBFODIwCihYRU4pIFBDSTogVXNp
bmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAwMC0zZgooWEVOKSBJbnRlbCBWVC1kIGlvbW11
IDAgc3VwcG9ydGVkIHBhZ2Ugc2l6ZXM6IDRrQi4KKFhFTikgSW50ZWwgVlQtZCBTbm9vcCBDb250
cm9sIGVuYWJsZWQuCihYRU4pIEludGVsIFZULWQgRG9tMCBETUEgUGFzc3Rocm91Z2ggbm90IGVu
YWJsZWQuCihYRU4pIEludGVsIFZULWQgUXVldWVkIEludmFsaWRhdGlvbiBlbmFibGVkLgooWEVO
KSBJbnRlbCBWVC1kIEludGVycnVwdCBSZW1hcHBpbmcgbm90IGVuYWJsZWQuCihYRU4pIEludGVs
IFZULWQgU2hhcmVkIEVQVCB0YWJsZXMgbm90IGVuYWJsZWQuCihYRU4pIEkvTyB2aXJ0dWFsaXNh
dGlvbiBlbmFibGVkCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZAooWEVOKSBJbnRlcnJ1cHQg
cmVtYXBwaW5nIGRpc2FibGVkCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcwooWEVOKSAgLT4g
VXNpbmcgbmV3IEFDSyBtZXRob2QKKFhFTikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBw
aW4xPTIgYXBpYzI9LTEgcGluMj0tMQooWEVOKSBQbGF0Zm9ybSB0aW1lciBpcyAxNC4zMThNSHog
SFBFVAooWEVOKSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4KKFhFTikgbXdhaXQt
aWRsZTogTVdBSVQgc3Vic3RhdGVzOiAweDExMjAKKFhFTikgbXdhaXQtaWRsZTogdjAuNCBtb2Rl
bCAweDFhCihYRU4pIG13YWl0LWlkbGU6IGxhcGljX3RpbWVyX3JlbGlhYmxlX3N0YXRlcyAweDIK
KFhFTikgSFBFVDogMCB0aW1lcnMgdXNhYmxlIGZvciBicm9hZGNhc3QgKDQgdG90YWwpCihYRU4p
IFZNWDogU3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOgooWEVOKSAgLSBBUElDIE1NSU8gYWNj
ZXNzIHZpcnR1YWxpc2F0aW9uCihYRU4pICAtIEFQSUMgVFBSIHNoYWRvdwooWEVOKSAgLSBFeHRl
bmRlZCBQYWdlIFRhYmxlcyAoRVBUKQooWEVOKSAgLSBWaXJ0dWFsLVByb2Nlc3NvciBJZGVudGlm
aWVycyAoVlBJRCkKKFhFTikgIC0gVmlydHVhbCBOTUkKKFhFTikgIC0gTVNSIGRpcmVjdC1hY2Nl
c3MgYml0bWFwCihYRU4pIEhWTTogQVNJRHMgZW5hYmxlZC4KKFhFTikgSFZNOiBWTVggZW5hYmxl
ZAooWEVOKSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyAoSEFQKSBkZXRlY3RlZAooWEVO
KSBIVk06IEhBUCBwYWdlIHNpemVzOiA0a0IsIDJNQgooWEVOKSBCcm91Z2h0IHVwIDggQ1BVcwoo
WEVOKSBBQ1BJIHNsZWVwIG1vZGVzOiBTMwooWEVOKSBtY2hlY2tfcG9sbDogTWFjaGluZSBjaGVj
ayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuCihYRU4pICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgoo
WEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weGZmZmZmZmZmODAyMDAwMDAgbWVt
c3o9MHgxMDFmZmI4CihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4ZmZmZmZm
ZmY4MTQyMDAwMCBtZW1zej0weDUyODc5MAooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6
IDB4ZmZmZmZmZmY4MDIwMDAwMCAtPiAweGZmZmZmZmZmODE5NDg3OTAKKFhFTikgZWxmX3hlbl9w
YXJzZV9ub3RlOiBHVUVTVF9PUyA9ICJGcmVlQlNEIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6
IEdVRVNUX1ZFUlNJT04gPSAiMHgxMGM5MTEiCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVO
X1ZFUlNJT04gPSAieGVuLTMuMCIKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0Ug
PSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZT
RVQgPSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBFTlRSWSA9
IDB4ZmZmZmZmZmY4MGQ0YjAwMAooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9Q
QUdFID0gMHhmZmZmZmZmZjgwZDRhMDAwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RB
UlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVB
VFVSRVMgPSAid3JpdGFibGVfZGVzY3JpcHRvcl90YWJsZXN8YXV0b190cmFuc2xhdGVkX3BoeXNt
YXB8c3VwZXJ2aXNvcl9tb2RlX2tlcm5lbHxodm1fY2FsbGJhY2tfdmVjdG9yIgooWEVOKSBlbGZf
eGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3Rl
OiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IExP
QURFUiA9ICJnZW5lcmljIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VM
ID0gMHgwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogQlNEX1NZTVRBQiA9ICJ5ZXMiCihYRU4p
IGVsZl94ZW5fcGFyc2U6IHVzaW5nIG5vdGVzIGZyb20gU0hUX05PVEUgc2VjdGlvbgooWEVOKSBl
bGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2VzOgooWEVOKSAgICAgdmlydF9iYXNlICAg
ICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMAooWEVOKSAgICAgZWxmX3BhZGRyX29mZnNldCA9IDB4
ZmZmZmZmZmY4MDAwMDAwMAooWEVOKSAgICAgdmlydF9vZmZzZXQgICAgICA9IDB4MAooWEVOKSAg
ICAgdmlydF9rc3RhcnQgICAgICA9IDB4ZmZmZmZmZmY4MDIwMDAwMAooWEVOKSAgICAgdmlydF9r
ZW5kICAgICAgICA9IDB4ZmZmZmZmZmY4MWM0ZDNiMAooWEVOKSAgICAgdmlydF9lbnRyeSAgICAg
ICA9IDB4ZmZmZmZmZmY4MGQ0YjAwMAooWEVOKSAgICAgcDJtX2Jhc2UgICAgICAgICA9IDB4ZmZm
ZmZmZmZmZmZmZmZmZgooWEVOKSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMgoo
WEVOKSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4ZmZmZmZmZmY4MDIw
MDAwMCAtPiAweGZmZmZmZmZmODE5NDg3OTAKKFhFTikgIERvbTAgc3ltYm9sIG1hcCAweGZmZmZm
ZmZmODE5NDg3OTAgLT4gMHhmZmZmZmZmZjgxYzRkM2IwCihYRU4pIFBIWVNJQ0FMIE1FTU9SWSBB
UlJBTkdFTUVOVDoKKFhFTikgIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAxOTQwMDAwMDAtPjAwMDAw
MDAxOTgwMDAwMDAgKDUwNzAwMCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4pICBJbml0LiBy
YW1kaXNrOiAwMDAwMDAwMTlmYzc4MDAwLT4wMDAwMDAwMWEwMDAwMDAwCihYRU4pIFZJUlRVQUwg
TUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MDIwMDAw
MC0+ZmZmZmZmZmY4MWM0ZDNiMAooWEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MWM0ZTAw
MC0+ZmZmZmZmZmY4MWZkNjAwMAooWEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4MWZkNjAw
MC0+ZmZmZmZmZmY4MjNkNjAwMAooWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4MjNkNjAw
MC0+ZmZmZmZmZmY4MjNkNzRiNAooWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4MjNkODAw
MC0+ZmZmZmZmZmY4MjNlZjAwMAooWEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4MjNlZjAw
MC0+ZmZmZmZmZmY4MjNmMDAwMAooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAw
MC0+ZmZmZmZmZmY4MjgwMDAwMAooWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MGQ0YjAw
MAooWEVOKSBEb20wIGhhcyBtYXhpbXVtIDggVkNQVXMKKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBw
aGRyIDIgYXQgMHhmZmZmZmZmZjgwMjAwMDAwIC0+IDB4ZmZmZmZmZmY4MTIxZmZiOAooWEVOKSBl
bGZfbG9hZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZmODE0MjAwMDAgLT4gMHhmZmZmZmZm
ZjgxNTRkYmEwCihYRU4pIGVsZl9sb2FkX2JzZHN5bXM6IHNoZHIgNCBhdCAweGZmZmY4MzAxOWU4
NDdjMTAgLT4gMHhmZmZmZmZmZjgxOTQ5MzE4CihYRU4pIGVsZl9sb2FkX2JzZHN5bXM6IHNoZHIg
NDIgYXQgMHhmZmZmODMwMTlmOWM4ZTkzIC0+IDB4ZmZmZmZmZmY4MTk5ZjEwOAooWEVOKSBlbGZf
bG9hZF9ic2RzeW1zOiBzaGRyIDQzIGF0IDB4ZmZmZjgzMDE5ZjljOWMyMCAtPiAweGZmZmZmZmZm
ODE5OWYzNTgKKFhFTikgZWxmX2xvYWRfYnNkc3ltczogc2hkciA0NCBhdCAweGZmZmY4MzAxOWZi
MTJmYTggLT4gMHhmZmZmZmZmZjgxYWU4NmUwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6
SG9zdGJyaWRnZTogc2tpcCAwMDAwOjAwOjAwLjAgbWFwCihYRU4pIEZvdW5kIG1hc2tlZCBVUiBz
aWduYWxpbmcgb24gMDAwMDowMDowMC4wCihYRU4pIEZvdW5kIG1hc2tlZCBVUiBzaWduYWxpbmcg
b24gMDAwMDowMDowMS4wCihYRU4pIEZvdW5kIG1hc2tlZCBVUiBzaWduYWxpbmcgb24gMDAwMDow
MDowMy4wCihYRU4pIEZvdW5kIG1hc2tlZCBVUiBzaWduYWxpbmcgb24gMDAwMDowMDowNy4wCihY
RU4pIFtWVC1EXWlvbW11LmM6MTQ0NDogZDA6UENJZTogbWFwIDAwMDA6MDA6MTQuMAooWEVOKSBN
YXNrZWQgVlQtZCBlcnJvciBzaWduYWxpbmcgb24gMDAwMDowMDoxNC4wCihYRU4pIFtWVC1EXWlv
bW11LmM6MTQ0NDogZDA6UENJZTogbWFwIDAwMDA6MDA6MTQuMQooWEVOKSBbVlQtRF1pb21tdS5j
OjE0NDQ6IGQwOlBDSWU6IG1hcCAwMDAwOjAwOjE0LjIKKFhFTikgW1ZULURdaW9tbXUuYzoxNDU2
OiBkMDpQQ0k6IG1hcCAwMDAwOjAwOjFhLjAKKFhFTikgW1ZULURdaW9tbXUuYzoxNDU2OiBkMDpQ
Q0k6IG1hcCAwMDAwOjAwOjFhLjEKKFhFTikgW1ZULURdaW9tbXUuYzoxNDU2OiBkMDpQQ0k6IG1h
cCAwMDAwOjAwOjFhLjIKKFhFTikgW1ZULURdaW9tbXUuYzoxNDU2OiBkMDpQQ0k6IG1hcCAwMDAw
OjAwOjFhLjcKKFhFTikgW1ZULURdaW9tbXUuYzoxNDQ0OiBkMDpQQ0llOiBtYXAgMDAwMDowMDox
Yi4wCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxZC4wCihY
RU4pIFtWVC1EXWlvbW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxZC4xCihYRU4pIFtW
VC1EXWlvbW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxZC4yCihYRU4pIFtWVC1EXWlv
bW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxZC43CihYRU4pIFtWVC1EXWlvbW11LmM6
MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxZi4wCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ1Njog
ZDA6UENJOiBtYXAgMDAwMDowMDoxZi4yCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ1NjogZDA6UENJ
OiBtYXAgMDAwMDowMDoxZi4zCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0NDogZDA6UENJZTogbWFw
IDAwMDA6MDE6MDAuMAooWEVOKSBbVlQtRF1pb21tdS5jOjE0NDQ6IGQwOlBDSWU6IG1hcCAwMDAw
OjAxOjAwLjEKKFhFTikgW1ZULURdaW9tbXUuYzoxNDQ0OiBkMDpQQ0llOiBtYXAgMDAwMDowMjow
MC4wCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0NDogZDA6UENJZTogbWFwIDAwMDA6MDQ6MDAuMAoo
WEVOKSBbVlQtRF1pb21tdS5jOjE0NDQ6IGQwOlBDSWU6IG1hcCAwMDAwOjA0OjAwLjEKKFhFTikg
W1ZULURdaW9tbXUuYzoxNDQ0OiBkMDpQQ0llOiBtYXAgMDAwMDowNTowMC4wCihYRU4pIFtWVC1E
XWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjAwLjAgbWFwCihYRU4p
IFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjAwLjEgbWFw
CihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjAy
LjAgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAw
OjNmOjAyLjEgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tp
cCAwMDAwOjNmOjAzLjAgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRn
ZTogc2tpcCAwMDAwOjNmOjAzLjEgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9z
dGJyaWRnZTogc2tpcCAwMDAwOjNmOjAzLjQgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDog
ZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA0LjAgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6
MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA0LjEgbWFwCihYRU4pIFtWVC1EXWlv
bW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA0LjIgbWFwCihYRU4pIFtW
VC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA0LjMgbWFwCihY
RU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA1LjAg
bWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNm
OjA1LjEgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAw
MDAwOjNmOjA1LjIgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTog
c2tpcCAwMDAwOjNmOjA1LjMgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJy
aWRnZTogc2tpcCAwMDAwOjNmOjA2LjAgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6
SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA2LjEgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQz
MDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA2LjIgbWFwCihYRU4pIFtWVC1EXWlvbW11
LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA2LjMgbWFwCihYRU4pIFtWVC1E
XWlvbW11LmM6NzM5OiBpb21tdV9lbmFibGVfdHJhbnNsYXRpb246IGlvbW11LT5yZWcgPSBmZmZm
ODJjMDAwMjAxMDAwCihYRU4pIFNjcnViYmluZyBGcmVlIFJBTSBvbiAxIG5vZGVzIHVzaW5nIDQg
Q1BVcwooWEVOKSAuLi4uLi4uLi4uLi4uZG9uZS4KKFhFTikgSW5pdGlhbCBsb3cgbWVtb3J5IHZp
cnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuCihYRU4pIFN0ZC4gTG9nbGV2ZWw6IEFs
bAooWEVOKSBHdWVzdCBMb2dsZXZlbDogQWxsCihYRU4pICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9N
MCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQooWEVO
KSBGcmVlZCAyODhrQiBpbml0IG1lbW9yeS4KRnJlZUJTRCBQVkggcnVubmluZyBvbiB4ZW4tMy4w
LXg4Nl82NHAKR0RCOiBubyBkZWJ1ZyBwb3J0cyBwcmVzZW50CktEQjogZGVidWdnZXIgYmFja2Vu
ZHM6IGRkYgpLREI6IGN1cnJlbnQgYmFja2VuZDogZGRiClNNQVAgdHlwZT0wMSBiYXNlPTAwMDAw
MDAwMDAwMDAwMDAgbGVuPTAwMDAwMDAwMDAwOTI4MDAKU01BUCB0eXBlPTAyIGJhc2U9MDAwMDAw
MDAwMDBmMDAwMCBsZW49MDAwMDAwMDAwMDAxMDAwMApTTUFQIHR5cGU9MDEgYmFzZT0wMDAwMDAw
MDAwMTAwMDAwIGxlbj0wMDAwMDAwMDdmZjZkMDAwClNNQVAgdHlwZT0wNCBiYXNlPTAwMDAwMDAw
ZGZkZjljMDAgbGVuPTAwMDAwMDAwMDAwNTIwMDAKU01BUCB0eXBlPTAzIGJhc2U9MDAwMDAwMDBk
ZmU0YmMwMCBsZW49MDAwMDAwMDAwMDAwMjAwMApTTUFQIHR5cGU9MDIgYmFzZT0wMDAwMDAwMGRm
ZTRkYzAwIGxlbj0wMDAwMDAwMDAwMWIyNDAwClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwZjgw
MDAwMDAgbGVuPTAwMDAwMDAwMDUwMDAwMDAKU01BUCB0eXBlPTAyIGJhc2U9MDAwMDAwMDBmZTAw
MDAwMCBsZW49MDAwMDAwMDAwMGQwMDQwMApTTUFQIHR5cGU9MDIgYmFzZT0wMDAwMDAwMGZlZTAw
MDAwIGxlbj0wMDAwMDAwMDAwMTAwMDAwClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwZmZiMDAw
MDAgbGVuPTAwMDAwMDAwMDA1MDAwMDAKVGFibGUgJ0ZBQ1AnIGF0IDB4ZmNkYjcKVGFibGUgJ1NT
RFQnIGF0IDB4ZmZlYTM0ZDYKVGFibGUgJ0FQSUMnIGF0IDB4ZmNlYWIKQVBJQzogRm91bmQgdGFi
bGUgYXQgMHhmY2VhYgpBUElDOiBVc2luZyB0aGUgWGVuIFBWIGVudW1lcmF0b3IuClNNUDogQWRk
ZWQgQ1BVIDAgKEJTUCkKU01QOiBBZGRlZCBDUFUgMiAoQVApClNNUDogQWRkZWQgQ1BVIDQgKEFQ
KQpTTVA6IEFkZGVkIENQVSA2IChBUCkKU01QOiBBZGRlZCBDUFUgOCAoQVApClNNUDogQWRkZWQg
Q1BVIDEwIChBUCkKU01QOiBBZGRlZCBDUFUgMTIgKEFQKQpTTVA6IEFkZGVkIENQVSAxNCAoQVAp
CkNvcHlyaWdodCAoYykgMTk5Mi0yMDE0IFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdodCAo
YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5Mywg
MTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJp
Z2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBG
cmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgMTEuMC1DVVJSRU5UICMxNDcgYjdkNTljZihwdmhf
ZG9tMCktZGlydHk6IFdlZCBEZWMgMTcgMTA6NDA6MTQgVVRDIDIwMTQKICAgIHJvb3RAb2Rpbjov
dXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDIGFtZDY0CkZyZWVCU0QgY2xhbmcgdmVyc2lvbiAz
LjQuMSAodGFncy9SRUxFQVNFXzM0L2RvdDEtZmluYWwgMjA4MDMyKSAyMDE0MDUxMgpXQVJOSU5H
OiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KVlQ6
IHJ1bm5pbmcgd2l0aCBkcml2ZXIgInZnYSIuCihYRU4pIGlycS5jOjM4MDogRG9tMCBjYWxsYmFj
ayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVjdG9yIDB4OTMKUHJlbG9hZGVkIGVsZiBtdWx0aWJv
b3Qga2VybmVsICIvYm9vdC94ZW42IiBhdCAweGZmZmZmZmZmODFjNGUwMDAuClByZWxvYWRlZCBl
bGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGZmZmZmZmZmODFjNGUxOTguClBy
ZWxvYWRlZCBlbGYgb2JqIG1vZHVsZSAiL2Jvb3Qva2VybmVsL3pmcy5rbyIgYXQgMHhmZmZmZmZm
ZjgxYzRlMjcwLgpQcmVsb2FkZWQgZWxmIG9iaiBtb2R1bGUgIi9ib290L2tlcm5lbC9vcGVuc29s
YXJpcy5rbyIgYXQgMHhmZmZmZmZmZjgxYzRlYTk4LgpDYWxpYnJhdGluZyBUU0MgY2xvY2sgLi4u
IFRTQyBjbG9jazogMzA2Njc4MTc2NyBIegpDUFU6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAg
ICAgICBXMzU1MCAgQCAzLjA3R0h6ICgzMDY2Ljc4LU1IeiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2lu
PSJHZW51aW5lSW50ZWwiICBJZD0weDEwNmE1ICBGYW1pbHk9MHg2ICBNb2RlbD0weDFhICBTdGVw
cGluZz01CiAgRmVhdHVyZXM9MHgxZmMzZWJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxN
Q0UsQ1g4LEFQSUMsU0VQLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQUNQSSxNTVgsRlhTUixTU0Us
U1NFMixTUyxIVFQ+CiAgRmVhdHVyZXMyPTB4ODA5ODIyODE8U1NFMyxFU1QsU1NTRTMsQ1gxNixT
U0U0LjEsU1NFNC4yLFBPUENOVCxIVj4KICBBTUQgRmVhdHVyZXM9MHgyMDEwMDgwMDxTWVNDQUxM
LE5YLExNPgogIEFNRCBGZWF0dXJlczI9MHgxPExBSEY+CiAgVFNDOiBQLXN0YXRlIGludmFyaWFu
dCwgcGVyZm9ybWFuY2Ugc3RhdGlzdGljcwpEYXRhIFRMQjogNCBLQiBwYWdlcywgNC13YXkgc2V0
IGFzc29jaWF0aXZlLCA2NCBlbnRyaWVzCjFzdC1sZXZlbCBkYXRhIGNhY2hlOiAzMiBLQiwgOC13
YXkgc2V0IGFzc29jaWF0aXZlLCA2NCBieXRlIGxpbmUgc2l6ZQpMMiBjYWNoZTogMjU2IGtieXRl
cywgOC13YXkgYXNzb2NpYXRpdmUsIDY0IGJ5dGVzL2xpbmUKSHlwZXJ2aXNvcjogT3JpZ2luID0g
IlhlblZNTVhlblZNTSIKcmVhbCBtZW1vcnkgID0gMjE0NzkzMDExMiAoMjA0OCBNQikKUGh5c2lj
YWwgbWVtb3J5IGNodW5rKHMpOgoweDAwMDAwMDAwMDAwMDEwMDAgLSAweDAwMDAwMDAwMDAwOTFm
ZmYsIDU5MzkyMCBieXRlcyAoMTQ1IHBhZ2VzKQoweDAwMDAwMDAwMDAxMDAwMDAgLSAweDAwMDAw
MDAwMDAxZmZmZmYsIDEwNDg1NzYgYnl0ZXMgKDI1NiBwYWdlcykKMHgwMDAwMDAwMDAyNDIwMDAw
IC0gMHgwMDAwMDAwMDdjYmRmZmZmLCAyMDU0OTQ2ODE2IGJ5dGVzICg1MDE2OTYgcGFnZXMpCmF2
YWlsIG1lbW9yeSA9IDIwMzE5NjAwNjQgKDE5MzcgTUIpCklOVFI6IEFkZGluZyBsb2NhbCBBUElD
IDIgYXMgYSB0YXJnZXQKSU5UUjogQWRkaW5nIGxvY2FsIEFQSUMgNCBhcyBhIHRhcmdldApJTlRS
OiBBZGRpbmcgbG9jYWwgQVBJQyA2IGFzIGEgdGFyZ2V0CklOVFI6IEFkZGluZyBsb2NhbCBBUElD
IDggYXMgYSB0YXJnZXQKSU5UUjogQWRkaW5nIGxvY2FsIEFQSUMgMTAgYXMgYSB0YXJnZXQKSU5U
UjogQWRkaW5nIGxvY2FsIEFQSUMgMTIgYXMgYSB0YXJnZXQKSU5UUjogQWRkaW5nIGxvY2FsIEFQ
SUMgMTQgYXMgYSB0YXJnZXQKRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRl
Y3RlZDogOCBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2thZ2UocykgeCA4IGNvcmUocykKIGNwdTAg
KEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAyCiBjcHUyIChBUCk6IEFQ
SUMgSUQ6ICA0CiBjcHUzIChBUCk6IEFQSUMgSUQ6ICA2CiBjcHU0IChBUCk6IEFQSUMgSUQ6ICA4
CiBjcHU1IChBUCk6IEFQSUMgSUQ6IDEwCiBjcHU2IChBUCk6IEFQSUMgSUQ6IDEyCiBjcHU3IChB
UCk6IEFQSUMgSUQ6IDE0Cng4NmJpb3M6ICBJVlQgMHgwMDAwMDAtMHgwMDA0ZmYgYXQgMHhmZmZm
ZjgwMDAwMDAwMDAwCng4NmJpb3M6IFNTRUcgMHgwMDEwMDAtMHgwMDFmZmYgYXQgMHhmZmZmZmUw
MDdiNWNkMDAwCng4NmJpb3M6ICBST00gMHgwYTAwMDAtMHgwZmVmZmYgYXQgMHhmZmZmZjgwMDAw
MGEwMDAwCnJhbmRvbSBkZXZpY2Ugbm90IGxvYWRlZC9hY3RpdmU7IHVzaW5nIGluc2VjdXJlIHBz
ZXVkby1yYW5kb20gbnVtYmVyIGdlbmVyYXRvcgpVTEU6IHNldHVwIGNwdSAwClVMRTogc2V0dXAg
Y3B1IDEKVUxFOiBzZXR1cCBjcHUgMgpVTEU6IHNldHVwIGNwdSAzClVMRTogc2V0dXAgY3B1IDQK
VUxFOiBzZXR1cCBjcHUgNQpVTEU6IHNldHVwIGNwdSA2ClVMRTogc2V0dXAgY3B1IDcKWGVuIGlu
dGVycnVwdCBzeXN0ZW0gaW5pdGlhbGl6ZWQKVGFibGUgJ0ZBQ1AnIGF0IDB4ZmNkYjcKVGFibGUg
J1NTRFQnIGF0IDB4ZmZlYTM0ZDYKVGFibGUgJ0FQSUMnIGF0IDB4ZmNlYWIKQVBJQzogRm91bmQg
dGFibGUgYXQgMHhmY2VhYgpBQ1BJOiBSU0RQIDB4MDAwMDAwMDAwMDBGRUMzMCAwMDAwMjQgKHYw
MiBERUxMICApCkFDUEk6IFhTRFQgMHgwMDAwMDAwMDAwMEZDQ0M3IDAwMDA3QyAodjAxIERFTEwg
ICBCMTBLICAgICAwMDAwMDAxNSBBU0wgIDAwMDAwMDYxKQpBQ1BJOiBGQUNQIDB4MDAwMDAwMDAw
MDBGQ0RCNyAwMDAwRjQgKHYwMyBERUxMICAgQjEwSyAgICAgMDAwMDAwMTUgQVNMICAwMDAwMDA2
MSkKQUNQSSBCSU9TIFdhcm5pbmcgKGJ1Zyk6IDMyLzY0WCBsZW5ndGggbWlzbWF0Y2ggaW4gRkFE
VC9HcGUwQmxvY2s6IDEyOC82NCAoMjAxNDA5MjYvdGJmYWR0LTY0NikKQUNQSTogRFNEVCAweDAw
MDAwMDAwRkZFOUU5NTEgMDA0QTc0ICh2MDEgREVMTCAgIGR0X2V4ICAgIDAwMDAxMDAwIElOVEwg
MjAwNTA2MjQpCkFDUEk6IEZBQ1MgMHgwMDAwMDAwMERGREY5QzAwIDAwMDA0MApBQ1BJOiBTU0RU
IDB4MDAwMDAwMDBGRkVBMzRENiAwMDAwOUMgKHYwMSBERUxMICAgc3RfZXggICAgMDAwMDEwMDAg
SU5UTCAyMDA1MDYyNCkKQUNQSTogQVBJQyAweDAwMDAwMDAwMDAwRkNFQUIgMDAwMTVFICh2MDEg
REVMTCAgIEIxMEsgICAgIDAwMDAwMDE1IEFTTCAgMDAwMDAwNjEpCkFDUEk6IEJPT1QgMHgwMDAw
MDAwMDAwMEZEMDA5IDAwMDAyOCAodjAxIERFTEwgICBCMTBLICAgICAwMDAwMDAxNSBBU0wgIDAw
MDAwMDYxKQpBQ1BJOiBBU0YhIDB4MDAwMDAwMDAwMDBGRDAzMSAwMDAwOTYgKHYzMiBERUxMICAg
QjEwSyAgICAgMDAwMDAwMTUgQVNMICAwMDAwMDA2MSkKQUNQSTogTUNGRyAweDAwMDAwMDAwMDAw
RkQwQzcgMDAwMDNDICh2MDEgREVMTCAgIEIxMEsgICAgIDAwMDAwMDE1IEFTTCAgMDAwMDAwNjEp
CkFDUEk6IEhQRVQgMHgwMDAwMDAwMDAwMEZEMTAzIDAwMDAzOCAodjAxIERFTEwgICBCMTBLICAg
ICAwMDAwMDAxNSBBU0wgIDAwMDAwMDYxKQpBQ1BJOiBUQ1BBIDB4MDAwMDAwMDAwMDBGRDM1RiAw
MDAwMzIgKHYwMSBERUxMICAgQjEwSyAgICAgMDAwMDAwMTUgQVNMICAwMDAwMDA2MSkKQUNQSTog
RE1BUiAweDAwMDAwMDAwMDAwRkQzOTEgMDAwMEM4ICh2MDEgREVMTCAgIEIxMEsgICAgIDAwMDAw
MDE1IEFTTCAgMDAwMDAwNjEpCkFDUEk6IFNMSUMgMHgwMDAwMDAwMDAwMEZEMTNCIDAwMDE3NiAo
djAxIERFTEwgICBCMTBLICAgICAwMDAwMDAxNSBBU0wgIDAwMDAwMDYxKQpBQ1BJOiBTU0RUIDB4
MDAwMDAwMDBERkU0REMwMCAwMDE1QzQgKHYwMSBJTlRFTCAgUFBNIFJDTSAgODAwMDAwMDEgSU5U
TCAyMDA2MTEwOSkKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgMCwgaXJxIDIKeGVu
OiByZWdpc3RlciBJUlEjMgpNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSA5LCBpcnEg
OQp4ZW46IHJlZ2lzdGVyIElSUSM5CmNwdTAgQlNQIFhFTiBQViBMQVBJQwpzbmRfdW5pdF9pbml0
KCkgdT0weDAwZmY4MDAwIFs1MTJdIGQ9MHgwMDAwN2MwMCBbMzJdIGM9MHgwMDAwMDNmZiBbMTAy
NF0KZmVlZGVyX3JlZ2lzdGVyOiBzbmRfdW5pdD0tMSBzbmRfbWF4YXV0b3ZjaGFucz0xNiBsYXRl
bmN5PTUgZmVlZGVyX3JhdGVfbWluPTEgZmVlZGVyX3JhdGVfbWF4PTIwMTYwMDAgZmVlZGVyX3Jh
dGVfcm91bmQ9MjUKd2xhbjogPDgwMi4xMSBMaW5rIExheWVyPgpyYW5kb206IGVudHJvcHkgZGV2
aWNlIGluZnJhc3RydWN0dXJlIGRyaXZlcgpyYW5kb206IHNlbGVjdGluZyBoaWdoZXN0IHByaW9y
aXR5IGFkYXB0b3IgPER1bW15PgprYmQ6IG5ldyBhcnJheSBzaXplIDQKa2JkMSBhdCBrYmRtdXgw
Cm1lbTogPG1lbW9yeT4KbmZzbG9jazogcHNldWRvLWRldmljZQpuZXRtYXA6IGxvYWRlZCBtb2R1
bGUKbnVsbDogPGZ1bGwgZGV2aWNlLCBudWxsIGRldmljZSwgemVybyBkZXZpY2U+Cm1vZHVsZV9y
ZWdpc3Rlcl9pbml0OiBNT0RfTE9BRCAodmVzYSwgMHhmZmZmZmZmZjgwZGQ1NGEwLCAwKSBlcnJv
ciAxOQppbzogPEkvTz4KcmFuZG9tOiBTT0ZUOiB5YXJyb3cgaW5pdCgpCnJhbmRvbTogc2VsZWN0
aW5nIGhpZ2hlc3QgcHJpb3JpdHkgYWRhcHRvciA8WWFycm93PgpWTUJVUzogbG9hZApocHRycjog
Um9ja2V0UkFJRCAxN3h4LzJ4eHggU0FUQSBjb250cm9sbGVyIGRyaXZlciB2MS4yCmhwdG5yOiBS
NzUwL0RDNzI4MCBjb250cm9sbGVyIGRyaXZlciB2MS4wLjEKaHB0Mjd4eDogUm9ja2V0UkFJRCAy
N3h4IGNvbnRyb2xsZXIgZHJpdmVyIHYxLjEKdnR2Z2EwOiA8dnRfdmdhIGRyaXZlcj4gb24gbW90
aGVyYm9hcmQKeGVucHYwOiA8WGVuIFBWIGJ1cz4gb24gbW90aGVyYm9hcmQKZ3JhbnR0YWJsZTA6
IDxYZW4gR3JhbnQtdGFibGUgRGV2aWNlPiBvbiB4ZW5wdjAKR3JhbnQgdGFibGUgaW5pdGlhbGl6
ZWQKeGMwOiA8WGVuIENvbnNvbGU+IG9uIHhlbnB2MAp4ZW5fZXQwOiA8WGVuIFBWIENsb2NrPiBv
biB4ZW5wdjAKRXZlbnQgdGltZXIgIlhFTlRJTUVSIiBmcmVxdWVuY3kgMTAwMDAwMDAwMCBIeiBx
dWFsaXR5IDk1MApUaW1lY291bnRlciAiWEVOVElNRVIiIGZyZXF1ZW5jeSAxMDAwMDAwMDAwIEh6
IHF1YWxpdHkgOTUwCnhlbl9ldDA6IHJlZ2lzdGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9jayAo
cmVzb2x1dGlvbiAxMDAwMDAwMHVzLCBhZGp1c3RtZW50IDUuMDAwMDAwMDAwcykKcHZjcHUwOiA8
WGVuIFBWIENQVT4gb24geGVucHYwCnB2Y3B1MTogPFhlbiBQViBDUFU+IG9uIHhlbnB2MApwdmNw
dTI6IDxYZW4gUFYgQ1BVPiBvbiB4ZW5wdjAKcHZjcHUzOiA8WGVuIFBWIENQVT4gb24geGVucHYw
CnB2Y3B1NDogPFhlbiBQViBDUFU+IG9uIHhlbnB2MApwdmNwdTU6IDxYZW4gUFYgQ1BVPiBvbiB4
ZW5wdjAKcHZjcHU2OiA8WGVuIFBWIENQVT4gb24geGVucHYwCnB2Y3B1NzogPFhlbiBQViBDUFU+
IG9uIHhlbnB2MAp4ZW5zdG9yZTA6IDxYZW5TdG9yZT4gb24geGVucHYwCnhzZF9kZXYwOiA8WGVu
c3RvcmVkIHVzZXItc3BhY2UgZGV2aWNlPiBvbiB4ZW5wdjAKZXZ0Y2huMDogPFhlbiBldmVudCBj
aGFubmVsIHVzZXItc3BhY2UgZGV2aWNlPiBvbiB4ZW5wdjAKcHJpdmNtZDA6IDxYZW4gcHJpdmls
ZWdlZCBpbnRlcmZhY2UgdXNlci1zcGFjZSBkZXZpY2U+IG9uIHhlbnB2MAppc2EwOiA8SVNBIGJ1
cz4gb24geGVucHYwCmFjcGkwOiA8REVMTCBCMTBLICAgPiBvbiBtb3RoZXJib2FyZApBQ1BJOiBB
bGwgQUNQSSBUYWJsZXMgc3VjY2Vzc2Z1bGx5IGFjcXVpcmVkClBDSWU6IE1lbW9yeSBNYXBwZWQg
Y29uZmlndXJhdGlvbiBiYXNlIEAgMHhmODAwMDAwMAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhl
ZCkKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDdmIGlycSA4IG9uIGFj
cGkwCmF0cnRjMDogbm90IGluc3RhbGxlZCBhcyB0aW1lLW9mLWRheSBjbG9jazogY2xvY2sgeGVu
X2V0IGhhcyBoaWdoZXIgcmVzb2x1dGlvbgphdHJ0YzA6IENhbid0IG1hcCBpbnRlcnJ1cHQuCmF0
dGltZXIwOiA8QVQgdGltZXI+IHBvcnQgMHg0MC0weDVmIGlycSAwIG9uIGFjcGkwClRpbWVjb3Vu
dGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCmF0dGltZXIwOiBDYW4n
dCBtYXAgaW50ZXJydXB0LgpwY2lfbGluazA6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAg
SVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkg
MTAgMTEgMTIgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1
IDYgNyA5IDEwIDExIDEyIDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAw
ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNQpwY2lfbGluazE6ICAgICAgICBJbmRleCAgSVJRICBS
dGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0
IDUgNiA3IDkgMTAgMTEgMTIgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMCAgIE4gICAg
IDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUg
ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNQpwY2lfbGluazI6ICAgICAgICBJbmRl
eCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA1ICAgTiAg
ICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAg
NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAg
ICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNQpwY2lfbGluazM6ICAg
ICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAg
MjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTUKICBWYWxpZGF0aW9uICAgICAg
ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE1CiAgQWZ0ZXIgRGlz
YWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNQpwY2lf
bGluazQ6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUg
ICAgICAgMCAgICA5ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTUKICBWYWxpZGF0
aW9uICAgICAgICAgIDAgICAgOSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE1CiAg
QWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAx
MiAxNQpwY2lfbGluazU6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRp
YWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTUK
ICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDEx
IDEyIDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcg
OSAxMCAxMSAxMiAxNQpwY2lfbGluazY6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJR
cwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA5ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAg
MTEgMTIgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAgOSAgIE4gICAgIDAgIDMgNCA1IDYg
NyA5IDEwIDExIDEyIDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAz
IDQgNSA2IDcgOSAxMCAxMSAxMiAxNQpwY2lfbGluazc6ICAgICAgICBJbmRleCAgSVJRICBSdGQg
IFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA1ICAgTiAgICAgMCAgMyA0IDUg
NiA3IDkgMTAgMTEgMTIgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAgNSAgIE4gICAgIDAg
IDMgNCA1IDYgNyA5IDEwIDExIDEyIDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBO
ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNQphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0
b24+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhj
ZmYgb24gYWNwaTAKcGNpYjA6IGRlY29kaW5nIDUgcmFuZ2UgMC0weGZmCnBjaWIwOiBkZWNvZGlu
ZyA0IHJhbmdlIDAtMHhjZjcKcGNpYjA6IGRlY29kaW5nIDQgcmFuZ2UgMHhkMDAtMHhmZmZmCnBj
aWIwOiBkZWNvZGluZyAzIHJhbmdlIDB4YTAwMDAtMHhiZmZmZgpwY2liMDogZGVjb2RpbmcgMyBy
YW5nZSAweGMwMDAwLTB4ZGZmZmYKcGNpYjA6IGRlY29kaW5nIDMgcmFuZ2UgMHhlMDAwMC0weGZm
ZmZmCnBjaWIwOiBkZWNvZGluZyAzIHJhbmdlIDB4ZGZmMDAwMDAtMHhmN2ZmZmZmZgpwY2liMDog
ZGVjb2RpbmcgMyByYW5nZSAweGZmOTgwMDAwLTB4ZmY5ODBmZmYKcGNpYjA6IGRlY29kaW5nIDMg
cmFuZ2UgMHhmZjk3YzAwMC0weGZmOTdmZmZmCnBjaWIwOiBkZWNvZGluZyAzIHJhbmdlIDB4ZmVk
MjAwMDAtMHhmZWQ5ZmZmZgpwY2kwOiA8WGVuIEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpMDog
ZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQw
NSwgcmV2aWQ9MHgyMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDYt
MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwMCwgc3RhdHJlZz0weDAw
MTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w
eDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNw
ZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2Vz
LCB2ZWN0b3IgbWFza3MKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMC5JTlRBCnBjaWIwOiBz
bG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CnhlbjogcmVnaXN0ZXIgSVJRIzE2CihYRU4p
IEZvdW5kIG1hc2tlZCBVUiBzaWduYWxpbmcgb24gMDAwMDowMDowMC4wCihYRU4pIFBDSSBhZGQg
ZGV2aWNlIDAwMDA6MDA6MDAuMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDM0MDgsIHJl
dmlkPTB4MjIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAw
LCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMDEwLCBj
YWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMiAo
NTAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMg
MyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCB2
ZWN0b3IgbWFza3MKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMS5JTlRBCnBjaWIwOiBzbG90
IDEgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CglzZWNidXM9MSwgc3ViYnVzPTEKKFhFTikgRm91
bmQgbWFza2VkIFVSIHNpZ25hbGluZyBvbiAwMDAwOjAwOjAxLjAKKFhFTikgUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDowMS4wCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQwYSwgcmV2aWQ9
MHgyMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhk
cnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hl
bG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDBhICgyNTAw
IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMyAg
c3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCB2ZWN0
b3IgbWFza3MKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMy5JTlRBCnBjaWIwOiBzbG90IDMg
SU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CglzZWNidXM9Miwgc3ViYnVzPTIKKFhFTikgRm91bmQg
bWFza2VkIFVSIHNpZ25hbGluZyBvbiAwMDAwOjAwOjAzLjAKKFhFTikgUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDowMy4wCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQwZSwgcmV2aWQ9MHgy
MgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTcsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5
cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z
ej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAyICg1MDAgbnMp
LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAzICBzdXBw
b3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIHZlY3RvciBt
YXNrcwpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC43LklOVEEKcGNpYjA6IHNsb3QgNyBJTlRB
IGhhcmR3aXJlZCB0byBJUlEgMTYKCXNlY2J1cz0zLCBzdWJidXM9MwooWEVOKSBGb3VuZCBtYXNr
ZWQgVVIgc2lnbmFsaW5nIG9uIDAwMDA6MDA6MDcuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjA3LjAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDJlLCByZXZpZD0weDIyCglk
b21haW49MCwgYnVzPTAsIHNsb3Q9MjAsIGZ1bmM9MAoJY2xhc3M9MDgtMDAtMDAsIGhkcnR5cGU9
MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0x
NiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4
bGF0PTB4MDAgKDAgbnMpCihYRU4pIE1hc2tlZCBWVC1kIGVycm9yIHNpZ25hbGluZyBvbiAwMDAw
OjAwOjE0LjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wCmZvdW5kLT4JdmVuZG9y
PTB4ODA4NiwgZGV2PTB4MzQyMiwgcmV2aWQ9MHgyMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIw
LCBmdW5jPTEKCWNsYXNzPTA4LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0w
eDAwMDAsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4
MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQooWEVOKSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjEKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgz
NDIzLCByZXZpZD0weDIyCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjAsIGZ1bmM9MgoJY2xhc3M9
MDgtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0w
eDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu
dD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDA6MTQuMgpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNhMzcsIHJldmlkPTB4MDAK
CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNiwgZnVuYz0wCgljbGFzcz0wYy0wMy0wMCwgaGRydHlw
ZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6
PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h
eGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJbWFwWzIwXTogdHlwZSBJL08gUG9y
dCwgcmFuZ2UgMzIsIGJhc2UgMHhmZjIwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0
ZWQgdHlwZSA0ICgweGZmMjAtMHhmZjNmKSBmb3IgcmlkIDIwIG9mIHBjaTA6MDoyNjowCnBjaWIw
OiBtYXRjaGVkIGVudHJ5IGZvciAwLjI2LklOVEEKcGNpYjA6IHNsb3QgMjYgSU5UQSBoYXJkd2ly
ZWQgdG8gSVJRIDE2CihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MWEuMApmb3VuZC0+CXZl
bmRvcj0weDgwODYsIGRldj0weDNhMzgsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xv
dD0yNiwgZnVuYz0xCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRy
ZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVy
PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50
cGluPWIsIGlycT0xMAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhm
ZjAwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweGZmMDAtMHhm
ZjFmKSBmb3IgcmlkIDIwIG9mIHBjaTA6MDoyNjoxCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAw
LjI2LklOVEIKcGNpYjA6IHNsb3QgMjYgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDE3CnhlbjogcmVn
aXN0ZXIgSVJRIzE3CihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MWEuMQpmb3VuZC0+CXZl
bmRvcj0weDgwODYsIGRldj0weDNhMzksIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xv
dD0yNiwgZnVuYz0yCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRy
ZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVy
PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50
cGluPWMsIGlycT05CgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGZj
MDAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4ZmMwMC0weGZj
MWYpIGZvciByaWQgMjAgb2YgcGNpMDowOjI2OjIKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAu
MjYuSU5UQwpwY2liMDogc2xvdCAyNiBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMjIKeGVuOiByZWdp
c3RlciBJUlEjMjIKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxYS4yCmZvdW5kLT4JdmVu
ZG9yPTB4ODA4NiwgZGV2PTB4M2EzYywgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90
PTI2LCBmdW5jPTcKCWNsYXNzPTBjLTAzLTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJl
Zz0weDAxMDYsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9
MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRw
aW49YywgaXJxPTkKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFw
WzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZjdmZmEwMDAsIHNpemUgMTAsIGVu
YWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZjdmZmEwMDAtMHhmN2ZmYTNmZikgZm9y
IHJpZCAxMCBvZiBwY2kwOjA6MjY6NwpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yNi5JTlRD
CnBjaWIwOiBzbG90IDI2IElOVEMgaGFyZHdpcmVkIHRvIElSUSAyMgooWEVOKSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjFhLjcKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTNlLCByZXZp
ZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjcsIGZ1bmM9MAoJY2xhc3M9MDQtMDMtMDAs
IGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNiwgc3RhdHJlZz0weDAwMTAsIGNh
Y2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw
IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAg
c3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJp
dAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZjdmZmMwMDAsIHNpemUg
MTQsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZjdmZmMwMDAtMHhmN2ZmZmZm
ZikgZm9yIHJpZCAxMCBvZiBwY2kwOjA6Mjc6MApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4y
Ny5JTlRBCnBjaWIwOiBzbG90IDI3IElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgooWEVOKSBQQ0kg
YWRkIGRldmljZSAwMDAwOjAwOjFiLjAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTQw
LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjgsIGZ1bmM9MAoJY2xhc3M9MDYt
MDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAw
MTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w
eDAyICg1MDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vy
c3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2Fn
ZQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOC5JTlRBCnBjaWIwOiBzbG90IDI4IElOVEEg
aGFyZHdpcmVkIHRvIElSUSAxNgoJc2VjYnVzPTQsIHN1YmJ1cz00CihYRU4pIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MWMuMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNhNGEsIHJldmlk
PTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOCwgZnVuYz01CgljbGFzcz0wNi0wNC0wMCwg
aGRydHlwZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDAxMCwgY2Fj
aGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDIgKDUw
MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMAoJcG93ZXJzcGVjIDIg
IHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCnBjaWIw
OiBtYXRjaGVkIGVudHJ5IGZvciAwLjI4LklOVEIKcGNpYjA6IHNsb3QgMjggSU5UQiBoYXJkd2ly
ZWQgdG8gSVJRIDE3CglzZWNidXM9NSwgc3ViYnVzPTUKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxYy41CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2EzNCwgcmV2aWQ9MHgwMAoJ
ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTAKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBl
PTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9
MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4
bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTUKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQs
IHJhbmdlIDMyLCBiYXNlIDB4ZmY4MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVk
IHR5cGUgNCAoMHhmZjgwLTB4ZmY5ZikgZm9yIHJpZCAyMCBvZiBwY2kwOjA6Mjk6MApwY2liMDog
bWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRBCnBjaWIwOiBzbG90IDI5IElOVEEgaGFyZHdpcmVk
IHRvIElSUSAyMwp4ZW46IHJlZ2lzdGVyIElSUSMyMwooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjFkLjAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTM1LCByZXZpZD0weDAwCglk
b21haW49MCwgYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MQoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9
MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0w
IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs
YXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MTAKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQs
IHJhbmdlIDMyLCBiYXNlIDB4ZmY2MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVk
IHR5cGUgNCAoMHhmZjYwLTB4ZmY3ZikgZm9yIHJpZCAyMCBvZiBwY2kwOjA6Mjk6MQpwY2liMDog
bWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRCCnBjaWIwOiBzbG90IDI5IElOVEIgaGFyZHdpcmVk
IHRvIElSUSAxNwooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjFkLjEKZm91bmQtPgl2ZW5k
b3I9MHg4MDg2LCBkZXY9MHgzYTM2LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9
MjksIGZ1bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVn
PTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0w
eDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBp
bj1jLCBpcnE9NQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhmZjQw
LCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweGZmNDAtMHhmZjVm
KSBmb3IgcmlkIDIwIG9mIHBjaTA6MDoyOToyCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5
LklOVEMKcGNpYjA6IHNsb3QgMjkgSU5UQyBoYXJkd2lyZWQgdG8gSVJRIDE4CnhlbjogcmVnaXN0
ZXIgSVJRIzE4CihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MWQuMgpmb3VuZC0+CXZlbmRv
cj0weDgwODYsIGRldj0weDNhM2EsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0y
OSwgZnVuYz03CgljbGFzcz0wYy0wMy0yMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9
MHgwMTA2LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4
MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGlu
PWEsIGlycT01Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsx
MF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZmOTgwMDAwLCBzaXplIDEwLCBlbmFi
bGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGZmOTgwMDAwLTB4ZmY5ODAzZmYpIGZvciBy
aWQgMTAgb2YgcGNpMDowOjI5OjcKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQQpw
Y2liMDogc2xvdCAyOSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjMKKFhFTikgUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxZC43CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjQ0ZSwgcmV2aWQ9
MHg5MAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMwLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAxLCBo
ZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNo
ZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAyICg1MDAg
bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXNlY2J1cz02LCBzdWJidXM9NgooWEVOKSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjFlLjAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTE2LCBy
ZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MAoJY2xhc3M9MDYtMDEt
MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAyMTAs
IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg
KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
Zi4wCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjgyMiwgcmV2aWQ9MHgwMAoJZG9tYWlu
PTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTIKCWNsYXNzPTAxLTA0LTAwLCBoZHJ0eXBlPTB4MDAs
IG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9MCAoZHdv
cmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4
MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTkKCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAg
Y3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDE2IG1lc3NhZ2VzCgltYXBbMTBdOiB0eXBlIEkvTyBQ
b3J0LCByYW5nZSAzMiwgYmFzZSAweGZlMDAsIHNpemUgIDMsIGVuYWJsZWQKcGNpYjA6IGFsbG9j
YXRlZCB0eXBlIDQgKDB4ZmUwMC0weGZlMDcpIGZvciByaWQgMTAgb2YgcGNpMDowOjMxOjIKCW1h
cFsxNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZmUxMCwgc2l6ZSAgMiwgZW5h
YmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhmZTEwLTB4ZmUxMykgZm9yIHJpZCAxNCBv
ZiBwY2kwOjA6MzE6MgoJbWFwWzE4XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhm
ZTIwLCBzaXplICAzLCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweGZlMjAtMHhm
ZTI3KSBmb3IgcmlkIDE4IG9mIHBjaTA6MDozMToyCgltYXBbMWNdOiB0eXBlIEkvTyBQb3J0LCBy
YW5nZSAzMiwgYmFzZSAweGZlMzAsIHNpemUgIDIsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0
eXBlIDQgKDB4ZmUzMC0weGZlMzMpIGZvciByaWQgMWMgb2YgcGNpMDowOjMxOjIKCW1hcFsyMF06
IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZmVjMCwgc2l6ZSAgNSwgZW5hYmxlZApw
Y2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhmZWMwLTB4ZmVkZikgZm9yIHJpZCAyMCBvZiBwY2kw
OjA6MzE6MgoJbWFwWzI0XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmY5NzAwMDAs
IHNpemUgMTEsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMzEuSU5UQwpwY2li
MDogc2xvdCAzMSBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMjAKeGVuOiByZWdpc3RlciBJUlEjMjAK
KFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxZi4yCmZvdW5kLT4JdmVuZG9yPTB4ODA4Niwg
ZGV2PTB4M2EzMCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTMK
CWNsYXNzPTBjLTA1LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDMsIHN0
YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks
IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTkK
CW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGY3ZmZiMDAwLCBzaXplICA4
LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGY3ZmZiMDAwLTB4ZjdmZmIwZmYp
IGZvciByaWQgMTAgb2YgcGNpMDowOjMxOjMKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdl
IDMyLCBiYXNlIDB4ZWNlMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUg
NCAoMHhlY2UwLTB4ZWNmZikgZm9yIHJpZCAyMCBvZiBwY2kwOjA6MzE6MwpwY2liMDogbWF0Y2hl
ZCBlbnRyeSBmb3IgMC4zMS5JTlRDCnBjaWIwOiBzbG90IDMxIElOVEMgaGFyZHdpcmVkIHRvIElS
USAyMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjFmLjMKcGNpYjE6IDxBQ1BJIFBDSS1Q
Q0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDEuMCBvbiBwY2kwCnBjaWIwOiBhbGxvY2F0ZWQg
dHlwZSAzICgweGYyMDAwMDAwLTB4ZjdiZmZmZmYpIGZvciByaWQgMjAgb2YgcGNpYjEKcGNpYjE6
ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAxCnBjaWIx
OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEKcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmMjAw
MDAwMC0weGY3YmZmZmZmCnBjaTE6IDxYZW4gQUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2liMTog
YWxsb2NhdGVkIGJ1cyByYW5nZSAoMS0xKSBmb3IgcmlkIDAgb2YgcGNpMQpwY2kxOiBkb21haW49
MCwgcGh5c2ljYWwgYnVzPTEKZm91bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNjM5LCByZXZp
ZD0weDIwCglkb21haW49MCwgYnVzPTEsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwg
aGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDAxMCwgY2Fj
aGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg
bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAzICBz
dXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDE2IG1lc3NhZ2VzLCA2NCBi
aXQKCU1TSS1YIHN1cHBvcnRzIDkgbWVzc2FnZXMgaW4gbWFwIDB4MTAKCW1hcFsxMF06IHR5cGUg
TWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGYyMDAwMDAwLCBzaXplIDI1LCBlbmFibGVkCnBjaWIx
OiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweGYyMDAwMDAwLTB4ZjNmZmZmZmYpIGZvciByaWQg
MTAgb2YgcGNpMDoxOjA6MApwY2liMTogbWF0Y2hlZCBlbnRyeSBmb3IgMS4wLklOVEEKcGNpYjE6
IHNsb3QgMCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjgKeGVuOiByZWdpc3RlciBJUlEjMjgKKFhF
TikgUENJIGFkZCBkZXZpY2UgMDAwMDowMTowMC4wCmZvdW5kLT4JdmVuZG9yPTB4MTRlNCwgZGV2
PTB4MTYzOSwgcmV2aWQ9MHgyMAoJZG9tYWluPTAsIGJ1cz0xLCBzbG90PTAsIGZ1bmM9MQoJY2xh
c3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNiwgc3RhdHJl
Zz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p
bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTEwCglw
b3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxNiBt
ZXNzYWdlcywgNjQgYml0CglNU0ktWCBzdXBwb3J0cyA5IG1lc3NhZ2VzIGluIG1hcCAweDEwCglt
YXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmNDAwMDAwMCwgc2l6ZSAyNSwg
ZW5hYmxlZApwY2liMTogYWxsb2NhdGVkIG1lbW9yeSByYW5nZSAoMHhmNDAwMDAwMC0weGY1ZmZm
ZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6MTowOjEKcGNpYjE6IG1hdGNoZWQgZW50cnkgZm9yIDEu
MC5JTlRCCnBjaWIxOiBzbG90IDAgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDQwCnhlbjogcmVnaXN0
ZXIgSVJRIzQwCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDE6MDAuMQpiY2UwOiA8UUxvZ2lj
IE5ldFh0cmVtZSBJSSBCQ001NzA5IDEwMDBCYXNlLVQgKEMwKT4gbWVtIDB4ZjIwMDAwMDAtMHhm
M2ZmZmZmZiBpcnEgMjggYXQgZGV2aWNlIDAuMCBvbiBwY2kxCmJjZTA6IC91c3Ivc3JjL3N5cy9k
ZXYvYmNlL2lmX2JjZS5jKDExNDEpOiBNU0kgYWxsb2NhdGlvbiBmYWlsZWQhIGVycm9yID0gMTkK
bWlpYnVzMDogPE1JSSBidXM+IG9uIGJjZTAKYnJncGh5MDogPEJDTTU3MDkgMTAvMTAwLzEwMDBi
YXNlVCBQSFk+IFBIWSAxIG9uIG1paWJ1czAKYnJncGh5MDogT1VJIDB4MDAwYWY3LCBtb2RlbCAw
eDAwM2MsIHJldi4gOApicmdwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwg
MTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VULCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRY
LCAxMDAwYmFzZVQtRkRYLW1hc3RlciwgYXV0bywgYXV0by1mbG93CmJjZTA6IFVzaW5nIGRlZmF1
bHRzIGZvciBUU086IDY1NTE4LzM1LzIwNDgKYmNlMDogYnBmIGF0dGFjaGVkCmJjZTA6IEV0aGVy
bmV0IGFkZHJlc3M6IDAwOjEwOjE4OmUwOjA1OjI4CmJjZTA6IEFTSUMgKDB4NTcwOTIwMDMpOyBS
ZXYgKEMwKTsgQnVzIChQQ0llIHg0LCAyLjVHYnBzKTsgQi9DICg1LjIuMyk7IEJ1ZnMgKFJYOjI7
VFg6MjtQRzo4KTsgRmxhZ3MgKFNQTFQpCkNvYWwgKFJYOjYsNiwxOCwxODsgVFg6MjAsMjAsODAs
ODApCmJjZTE6IDxRTG9naWMgTmV0WHRyZW1lIElJIEJDTTU3MDkgMTAwMEJhc2UtVCAoQzApPiBt
ZW0gMHhmNDAwMDAwMC0weGY1ZmZmZmZmIGlycSA0MCBhdCBkZXZpY2UgMC4xIG9uIHBjaTEKYmNl
MTogL3Vzci9zcmMvc3lzL2Rldi9iY2UvaWZfYmNlLmMoMTE0MSk6IE1TSSBhbGxvY2F0aW9uIGZh
aWxlZCEgZXJyb3IgPSAxOQptaWlidXMxOiA8TUlJIGJ1cz4gb24gYmNlMQpicmdwaHkxOiA8QkNN
NTcwOSAxMC8xMDAvMTAwMGJhc2VUIFBIWT4gUEhZIDEgb24gbWlpYnVzMQpicmdwaHkxOiBPVUkg
MHgwMDBhZjcsIG1vZGVsIDB4MDAzYywgcmV2LiA4CmJyZ3BoeTE6ICAxMGJhc2VULCAxMGJhc2VU
LUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1tYXN0
ZXIsIDEwMDBiYXNlVC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCBhdXRvLCBhdXRvLWZsb3cK
YmNlMTogVXNpbmcgZGVmYXVsdHMgZm9yIFRTTzogNjU1MTgvMzUvMjA0OApiY2UxOiBicGYgYXR0
YWNoZWQKYmNlMTogRXRoZXJuZXQgYWRkcmVzczogMDA6MTA6MTg6ZTA6MDU6MmEKYmNlMTogQVNJ
QyAoMHg1NzA5MjAwMyk7IFJldiAoQzApOyBCdXMgKFBDSWUgeDQsIDIuNUdicHMpOyBCL0MgKDUu
Mi4zKTsgQnVmcyAoUlg6MjtUWDoyO1BHOjgpOyBGbGFncyAoU1BMVCkKQ29hbCAoUlg6Niw2LDE4
LDE4OyBUWDoyMCwyMCw4MCw4MCkKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYg
YXQgZGV2aWNlIDMuMCBvbiBwY2kwCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweGQwMDAtMHhk
ZmZmKSBmb3IgcmlkIDFjIG9mIHBjaWIyCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGY3ZDAw
MDAwLTB4ZjdlZmZmZmYpIGZvciByaWQgMjAgb2YgcGNpYjIKcGNpYjA6IGFsbG9jYXRlZCB0eXBl
IDMgKDB4ZTAwMDAwMDAtMHhlZmZmZmZmZikgZm9yIHJpZCAyNCBvZiBwY2liMgpwY2liMjogICBk
b21haW4gICAgICAgICAgICAwCnBjaWIyOiAgIHNlY29uZGFyeSBidXMgICAgIDIKcGNpYjI6ICAg
c3Vib3JkaW5hdGUgYnVzICAgMgpwY2liMjogICBJL08gZGVjb2RlICAgICAgICAweGQwMDAtMHhk
ZmZmCnBjaWIyOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZjdkMDAwMDAtMHhmN2VmZmZmZgpwY2li
MjogICBwcmVmZXRjaGVkIGRlY29kZSAweGUwMDAwMDAwLTB4ZWZmZmZmZmYKcGNpYjI6ICAgc3Bl
Y2lhbCBkZWNvZGUgICAgVkdBCnBjaTI6IDxYZW4gQUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2li
MjogYWxsb2NhdGVkIGJ1cyByYW5nZSAoMi0yKSBmb3IgcmlkIDAgb2YgcGNpMgpwY2kyOiBkb21h
aW49MCwgcGh5c2ljYWwgYnVzPTIKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg5NWNmLCBy
ZXZpZD0weDAwCglkb21haW49MCwgYnVzPTIsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMy0wMC0w
MCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDAzLCBzdGF0cmVnPTB4MDAxMCwg
Y2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg
KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAz
ICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2Fn
ZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIFByZWZldGNoYWJsZSBNZW1vcnksIHJhbmdlIDY0LCBi
YXNlIDB4ZTAwMDAwMDAsIHNpemUgMjgsIGVuYWJsZWQKcGNpYjI6IGFsbG9jYXRlZCBwcmVmZXRj
aCByYW5nZSAoMHhlMDAwMDAwMC0weGVmZmZmZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6MjowOjAK
CW1hcFsxOF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGY3ZGYwMDAwLCBzaXplIDE2
LCBlbmFibGVkCnBjaWIyOiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweGY3ZGYwMDAwLTB4Zjdk
ZmZmZmYpIGZvciByaWQgMTggb2YgcGNpMDoyOjA6MAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwg
cmFuZ2UgMzIsIGJhc2UgMHhkYzAwLCBzaXplICA4LCBlbmFibGVkCnBjaWIyOiBhbGxvY2F0ZWQg
SS9PIHBvcnQgcmFuZ2UgKDB4ZGMwMC0weGRjZmYpIGZvciByaWQgMjAgb2YgcGNpMDoyOjA6MApw
Y2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi4wLklOVEEKcGNpYjI6IHNsb3QgMCBJTlRBIGhhcmR3
aXJlZCB0byBJUlEgMjQKeGVuOiByZWdpc3RlciBJUlEjMjQKKFhFTikgUENJIGFkZCBkZXZpY2Ug
MDAwMDowMjowMC4wCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4ZGMw
MC0weGRjZmYgbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZiwweGY3ZGYwMDAwLTB4ZjdkZmZmZmYg
aXJxIDI0IGF0IGRldmljZSAwLjAgb24gcGNpMgp2Z2FwY2kwOiBCb290IHZpZGVvIGRldmljZQpw
Y2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAK
cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZjdjMDAwMDAtMHhmN2NmZmZmZikgZm9yIHJpZCAy
MCBvZiBwY2liMwpwY2liMzogICBkb21haW4gICAgICAgICAgICAwCnBjaWIzOiAgIHNlY29uZGFy
eSBidXMgICAgIDMKcGNpYjM6ICAgc3Vib3JkaW5hdGUgYnVzICAgMwpwY2liMzogICBtZW1vcnkg
ZGVjb2RlICAgICAweGY3YzAwMDAwLTB4ZjdjZmZmZmYKcGNpMzogPFhlbiBBQ1BJIFBDSSBidXM+
IG9uIHBjaWIzCnBjaWIzOiBhbGxvY2F0ZWQgYnVzIHJhbmdlICgzLTMpIGZvciByaWQgMCBvZiBw
Y2kzCnBjaTM6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MwpwY2kwOiA8YmFzZSBwZXJpcGhlcmFs
LCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDIwLjAgKG5vIGRyaXZlciBhdHRhY2hl
ZCkKcGNpMDogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmlj
ZSAyMC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWwsIGludGVy
cnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMjAuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQp1aGNp
MDogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItRD4gcG9ydCAweGZm
MjAtMHhmZjNmIGlycSAxNiBhdCBkZXZpY2UgMjYuMCBvbiBwY2kwCnVoY2kwOiBMZWdTdXAgPSAw
eDJmMDAKdXNidXMwIG9uIHVoY2kwCnVoY2kwOiB1c2JwZjogQXR0YWNoZWQKdWhjaTE6IDxJbnRl
bCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUU+IHBvcnQgMHhmZjAwLTB4ZmYx
ZiBpcnEgMTcgYXQgZGV2aWNlIDI2LjEgb24gcGNpMAp1aGNpMTogTGVnU3VwID0gMHgyZjAwCnVz
YnVzMSBvbiB1aGNpMQp1aGNpMTogdXNicGY6IEF0dGFjaGVkCnVoY2kyOiA8SW50ZWwgODI4MDFK
SSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1GPiBwb3J0IDB4ZmMwMC0weGZjMWYgaXJxIDIy
IGF0IGRldmljZSAyNi4yIG9uIHBjaTAKdWhjaTI6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czIgb24g
dWhjaTIKdWhjaTI6IHVzYnBmOiBBdHRhY2hlZAplaGNpMDogPEludGVsIDgyODAxSkkgKElDSDEw
KSBVU0IgMi4wIGNvbnRyb2xsZXIgVVNCLUI+IG1lbSAweGY3ZmZhMDAwLTB4ZjdmZmEzZmYgaXJx
IDIyIGF0IGRldmljZSAyNi43IG9uIHBjaTAKdXNidXMzOiBFSENJIHZlcnNpb24gMS4wCnVzYnVz
MyBvbiBlaGNpMAplaGNpMDogdXNicGY6IEF0dGFjaGVkCmhkYWMwOiA8SW50ZWwgODI4MDFKSSBI
REEgQ29udHJvbGxlcj4gbWVtIDB4ZjdmZmMwMDAtMHhmN2ZmZmZmZiBpcnEgMTYgYXQgZGV2aWNl
IDI3LjAgb24gcGNpMApoZGFjMDogUENJIGNhcmQgdmVuZG9yOiAweDEwMjgsIGRldmljZTogMHgw
MjkzCmhkYWMwOiBIREEgRHJpdmVyIFJldmlzaW9uOiAyMDEyMDEyNl8wMDAyCmhkYWMwOiBDb25m
aWcgb3B0aW9uczogb249MHgwMDAwMDAwMCBvZmY9MHgwMDAwMDAwMApoZGFjMDogQ2FwczogT1NT
IDQsIElTUyA0LCBCU1MgMCwgTlNETyAxLCA2NGJpdCwgQ09SQiAyNTYsIFJJUkIgMjU2CnBjaWI0
OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAyOC4wIG9uIHBjaTAKcGNp
YjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4YzAwMC0weGNmZmYpIGZvciByaWQgMWMgb2YgcGNpYjQK
cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZjFlMDAwMDAtMHhmMWZmZmZmZikgZm9yIHJpZCAy
MCBvZiBwY2liNApwY2liNDogICBkb21haW4gICAgICAgICAgICAwCnBjaWI0OiAgIHNlY29uZGFy
eSBidXMgICAgIDQKcGNpYjQ6ICAgc3Vib3JkaW5hdGUgYnVzICAgNApwY2liNDogICBJL08gZGVj
b2RlICAgICAgICAweGMwMDAtMHhjZmZmCnBjaWI0OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZjFl
MDAwMDAtMHhmMWZmZmZmZgpwY2k0OiA8WGVuIEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKcGNpYjQ6
IGFsbG9jYXRlZCBidXMgcmFuZ2UgKDQtNCkgZm9yIHJpZCAwIG9mIHBjaTQKcGNpNDogZG9tYWlu
PTAsIHBoeXNpY2FsIGJ1cz00CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MTA1ZSwgcmV2
aWQ9MHgwNgoJZG9tYWluPTAsIGJ1cz00LCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAs
IGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNh
Y2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw
IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAg
c3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJp
dAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZjFlODAwMDAsIHNpemUg
MTcsIGVuYWJsZWQKcGNpYjQ6IGFsbG9jYXRlZCBtZW1vcnkgcmFuZ2UgKDB4ZjFlODAwMDAtMHhm
MWU5ZmZmZikgZm9yIHJpZCAxMCBvZiBwY2kwOjQ6MDowCgltYXBbMTRdOiB0eXBlIE1lbW9yeSwg
cmFuZ2UgMzIsIGJhc2UgMHhmMWVhMDAwMCwgc2l6ZSAxNywgZW5hYmxlZApwY2liNDogYWxsb2Nh
dGVkIG1lbW9yeSByYW5nZSAoMHhmMWVhMDAwMC0weGYxZWJmZmZmKSBmb3IgcmlkIDE0IG9mIHBj
aTA6NDowOjAKCW1hcFsxOF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4Y2NjMCwg
c2l6ZSAgNSwgZW5hYmxlZApwY2liNDogYWxsb2NhdGVkIEkvTyBwb3J0IHJhbmdlICgweGNjYzAt
MHhjY2RmKSBmb3IgcmlkIDE4IG9mIHBjaTA6NDowOjAKcGNpYjQ6IG1hdGNoZWQgZW50cnkgZm9y
IDQuMC5JTlRBCnBjaWI0OiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CihYRU4pIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDEw
NWUsIHJldmlkPTB4MDYKCWRvbWFpbj0wLCBidXM9NCwgc2xvdD0wLCBmdW5jPTEKCWNsYXNzPTAy
LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgw
MDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9
MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMAoJcG93ZXJz
cGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdl
LCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGYxZWMwMDAw
LCBzaXplIDE3LCBlbmFibGVkCnBjaWI0OiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweGYxZWMw
MDAwLTB4ZjFlZGZmZmYpIGZvciByaWQgMTAgb2YgcGNpMDo0OjA6MQoJbWFwWzE0XTogdHlwZSBN
ZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZjFlZTAwMDAsIHNpemUgMTcsIGVuYWJsZWQKcGNpYjQ6
IGFsbG9jYXRlZCBtZW1vcnkgcmFuZ2UgKDB4ZjFlZTAwMDAtMHhmMWVmZmZmZikgZm9yIHJpZCAx
NCBvZiBwY2kwOjQ6MDoxCgltYXBbMThdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAw
eGNjZTAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjQ6IGFsbG9jYXRlZCBJL08gcG9ydCByYW5nZSAo
MHhjY2UwLTB4Y2NmZikgZm9yIHJpZCAxOCBvZiBwY2kwOjQ6MDoxCnBjaWI0OiBtYXRjaGVkIGVu
dHJ5IGZvciA0LjAuSU5UQgpwY2liNDogc2xvdCAwIElOVEIgaGFyZHdpcmVkIHRvIElSUSAxNwoo
WEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjEKZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAg
TmV0d29yayBDb25uZWN0aW9uIDcuNC4yPiBwb3J0IDB4Y2NjMC0weGNjZGYgbWVtIDB4ZjFlODAw
MDAtMHhmMWU5ZmZmZiwweGYxZWEwMDAwLTB4ZjFlYmZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAg
b24gcGNpNAplbTA6IE5vIE1TSS9NU0lYIHVzaW5nIGEgTGVnYWN5IElSUQplbTA6IGJwZiBhdHRh
Y2hlZAplbTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjFiOjIxOmM2OmU5OmFlCjAwMS4wMDAwMTAg
WzI3MThdIG5ldG1hcF9hdHRhY2ggICAgICAgICAgICAgc3VjY2VzcyBmb3IgZW0wIHR4IDEvMTAy
NCByeCAxLzEwMjQgcXVldWVzL3Nsb3RzCmVtMTogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsg
Q29ubmVjdGlvbiA3LjQuMj4gcG9ydCAweGNjZTAtMHhjY2ZmIG1lbSAweGYxZWMwMDAwLTB4ZjFl
ZGZmZmYsMHhmMWVlMDAwMC0weGYxZWZmZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4xIG9uIHBjaTQK
ZW0xOiBObyBNU0kvTVNJWCB1c2luZyBhIExlZ2FjeSBJUlEKZW0xOiBicGYgYXR0YWNoZWQKZW0x
OiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxYjoyMTpjNjplOTphZgowMDEuMDAwMDExIFsyNzE4XSBu
ZXRtYXBfYXR0YWNoICAgICAgICAgICAgIHN1Y2Nlc3MgZm9yIGVtMSB0eCAxLzEwMjQgcnggMS8x
MDI0IHF1ZXVlcy9zbG90cwpwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNyBhdCBk
ZXZpY2UgMjguNSBvbiBwY2kwCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGYxZDAwMDAwLTB4
ZjFkZmZmZmYpIGZvciByaWQgMjAgb2YgcGNpYjUKcGNpYjU6ICAgZG9tYWluICAgICAgICAgICAg
MApwY2liNTogICBzZWNvbmRhcnkgYnVzICAgICA1CnBjaWI1OiAgIHN1Ym9yZGluYXRlIGJ1cyAg
IDUKcGNpYjU6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmMWQwMDAwMC0weGYxZGZmZmZmCnBjaTU6
IDxYZW4gQUNQSSBQQ0kgYnVzPiBvbiBwY2liNQpwY2liNTogYWxsb2NhdGVkIGJ1cyByYW5nZSAo
NS01KSBmb3IgcmlkIDAgb2YgcGNpNQpwY2k1OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTUKZm91
bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNjgxLCByZXZpZD0weDEwCglkb21haW49MCwgYnVz
PTUsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0w
CgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCgls
YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu
cykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVu
dCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIE1lbW9y
eSwgcmFuZ2UgNjQsIGJhc2UgMHhmMWRlMDAwMCwgc2l6ZSAxNiwgZW5hYmxlZApwY2liNTogYWxs
b2NhdGVkIG1lbW9yeSByYW5nZSAoMHhmMWRlMDAwMC0weGYxZGVmZmZmKSBmb3IgcmlkIDEwIG9m
IHBjaTA6NTowOjAKCW1hcFsxOF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGYxZGYw
MDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWI1OiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweGYx
ZGYwMDAwLTB4ZjFkZmZmZmYpIGZvciByaWQgMTggb2YgcGNpMDo1OjA6MApwY2liNTogbWF0Y2hl
ZCBlbnRyeSBmb3IgNS4wLklOVEEKcGNpYjU6IHNsb3QgMCBJTlRBIGhhcmR3aXJlZCB0byBJUlEg
MTcKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4wCmJnZTA6IDxCcm9hZGNvbSBOZXRY
dHJlbWUgR2lnYWJpdCBFdGhlcm5ldCBDb250cm9sbGVyLCBBU0lDIHJldi4gMHg1NzYxMTAwPiBt
ZW0gMHhmMWRlMDAwMC0weGYxZGVmZmZmLDB4ZjFkZjAwMDAtMHhmMWRmZmZmZiBpcnEgMTcgYXQg
ZGV2aWNlIDAuMCBvbiBwY2k1CmJnZTA6IENISVAgSUQgMHgwNTc2MTEwMDsgQVNJQyBSRVYgMHg1
NzYxOyBDSElQIFJFViAweDU3NjExOyBQQ0ktRQpiZ2UwOiBEaXNhYmxpbmcgZmFzdGJvb3QKbWlp
YnVzMjogPE1JSSBidXM+IG9uIGJnZTAKYnJncGh5MjogPEJDTTU3NjEgMTAvMTAwLzEwMDBiYXNl
VCBQSFk+IFBIWSAxIG9uIG1paWJ1czIKYnJncGh5MjogT1VJIDB4MDAwYWY3LCBtb2RlbCAweDAw
M2QsIHJldi4gMApicmdwaHkyOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAw
YmFzZVRYLUZEWCwgMTAwMGJhc2VULCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLCAx
MDAwYmFzZVQtRkRYLW1hc3RlciwgYXV0bywgYXV0by1mbG93CmJnZTA6IFVzaW5nIGRlZmF1bHRz
IGZvciBUU086IDY1NTE4LzM1LzIwNDgKYmdlMDogYnBmIGF0dGFjaGVkCmJnZTA6IEV0aGVybmV0
IGFkZHJlc3M6IGQ0OmFlOjUyOmMxOmQ0OjNkCnVoY2kzOiA8SW50ZWwgODI4MDFKSSAoSUNIMTAp
IFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4ZmY4MC0weGZmOWYgaXJxIDIzIGF0IGRldmlj
ZSAyOS4wIG9uIHBjaTAKdXNidXM0IG9uIHVoY2kzCnVoY2kzOiB1c2JwZjogQXR0YWNoZWQKdWhj
aTQ6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IHBvcnQgMHhm
ZjYwLTB4ZmY3ZiBpcnEgMTcgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1c2J1czUgb24gdWhjaTQK
dWhjaTQ6IHVzYnBmOiBBdHRhY2hlZAp1aGNpNTogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0Ig
Y29udHJvbGxlciBVU0ItQz4gcG9ydCAweGZmNDAtMHhmZjVmIGlycSAxOCBhdCBkZXZpY2UgMjku
MiBvbiBwY2kwCnVzYnVzNiBvbiB1aGNpNQp1aGNpNTogdXNicGY6IEF0dGFjaGVkCmVoY2kxOiA8
SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiAyLjAgY29udHJvbGxlciBVU0ItQT4gbWVtIDB4ZmY5
ODAwMDAtMHhmZjk4MDNmZiBpcnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAp1c2J1czc6IEVI
Q0kgdmVyc2lvbiAxLjAKdXNidXM3IG9uIGVoY2kxCmVoY2kxOiB1c2JwZjogQXR0YWNoZWQKcGNp
YjY6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaWI2OiAg
IGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjY6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgNgpwY2liNjog
ICBzdWJvcmRpbmF0ZSBidXMgICA2CnBjaWI2OiAgIHNwZWNpYWwgZGVjb2RlICAgIHN1YnRyYWN0
aXZlCnBjaTY6IDxYZW4gQUNQSSBQQ0kgYnVzPiBvbiBwY2liNgpwY2liNjogYWxsb2NhdGVkIGJ1
cyByYW5nZSAoNi02KSBmb3IgcmlkIDAgb2YgcGNpNgpwY2k2OiBkb21haW49MCwgcGh5c2ljYWwg
YnVzPTYKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2E6
IGlzYTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmRldmljZV9hdHRhY2g6IGlzYWIwIGF0
dGFjaCByZXR1cm5lZCA2CmFoY2kwOiA8SW50ZWwgSUNIOCBBSENJIFNBVEEgY29udHJvbGxlcj4g
cG9ydCAweGZlMDAtMHhmZTA3LDB4ZmUxMC0weGZlMTMsMHhmZTIwLTB4ZmUyNywweGZlMzAtMHhm
ZTMzLDB4ZmVjMC0weGZlZGYgbWVtIDB4ZmY5NzAwMDAtMHhmZjk3MDdmZiBpcnEgMjAgYXQgZGV2
aWNlIDMxLjIgb24gcGNpMAphaGNpMDogQUhDSSB2MS4yMCB3aXRoIDYgM0dicHMgcG9ydHMsIFBv
cnQgTXVsdGlwbGllciBub3Qgc3VwcG9ydGVkCmFoY2kwOiBDYXBzOiA2NGJpdCBOQ1EgU05URiBB
TCBDTE8gM0dicHMgUE1EIDMyY21kIENDQyBFTSBlU0FUQSA2cG9ydHMKYWhjaTA6IENhcHMyOgph
aGNpY2gwOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gYWhjaTAKYWhjaWNoMDogQ2Fw
czoKYWhjaWNoMTogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwCmFoY2ljaDE6
IENhcHM6CmFoY2ljaDI6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMiBvbiBhaGNpMAphaGNp
Y2gyOiBDYXBzOgphaGNpY2gzOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDMgb24gYWhjaTAK
YWhjaWNoMzogQ2FwczoKYWhjaWNoNDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA0IG9uIGFo
Y2kwCmFoY2ljaDQ6IENhcHM6CmFoY2ljaDU6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNSBv
biBhaGNpMAphaGNpY2g1OiBDYXBzOiBIUENQIEVTUAphaGNpZW0wOiA8QUhDSSBlbmNsb3N1cmUg
bWFuYWdlbWVudCBicmlkZ2U+IG9uIGFoY2kwCmFoY2llbTA6IENhcHM6IEFMSEQgWE1UIFNNQiBM
RUQKcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0
dGFjaGVkKQpwcGMwOiB1c2luZyBleHRlbmRlZCBJL08gcG9ydCByYW5nZQpwcGMwOiBTUFAgRUNQ
ICBFQ1ArRVBQCnBwYzA6IDxQYXJhbGxlbCBwb3J0PiBwb3J0IDB4Mzc4LTB4MzdmLDB4Nzc4LTB4
NzdmIGlycSA3IG9uIGFjcGkwCnBwYzA6IFNNQy1saWtlIGNoaXBzZXQgKEVDUC9FUFAvUFMyL05J
QkJMRSkgaW4gQ09NUEFUSUJMRSBtb2RlCnBwYzA6IEZJRk8gd2l0aCAxNi8xNi84IGJ5dGVzIHRo
cmVzaG9sZApwcGJ1czA6IDxQYXJhbGxlbCBwb3J0IGJ1cz4gb24gcHBjMApscHQwOiA8UHJpbnRl
cj4gb24gcHBidXMwCmxwdDA6IFBvbGxlZCBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBw
YnVzMAp1YXJ0MTogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMg
b24gYWNwaTAKdWFydDE6IHBvbGxlZCBtb2RlICg1MEh6KQpBQ1BJOiBFbmFibGVkIDMgR1BFcyBp
biBibG9jayAwMCB0byAzRgpxcGkwOiA8UVBJIHN5c3RlbSBidXM+IG9uIG1vdGhlcmJvYXJkCmFj
cGkwOiB3YWtldXAgY29kZSB2YSAweGZmZmZmZTAwOTZkYjcwMDAgcGEgMHg0MDAwCmFoY19pc2Ff
aWRlbnRpZnkgMDogaW9wb3J0IDB4YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDEy
OiBpb3BvcnQgMHhjYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDEzOiBpb3BvcnQg
MHhkYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDE0OiBpb3BvcnQgMHhlYzAwIGFs
bG9jIGZhaWxlZApleF9pc2FfaWRlbnRpZnkoKQppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGlu
ZyBQblAgZGV2aWNlcwphdHJ0YzogYXRydGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAph
dHRpbWVyOiBhdHRpbWVyMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKcHBjOiBwcGMwIGFs
cmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzYzogc2MwIGFscmVhZHkgZXhpc3RzOyBza2lwcGlu
ZyBpdAp1YXJ0OiB1YXJ0MSBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2No
aWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2aWNlcwpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBh
dCBpb21lbSAweGQwMDAwLTB4ZGE3ZmYsMHhkYTgwMC0weGRjN2ZmLDB4ZGM4MDAtMHhkZTdmZiww
eGRlODAwLTB4ZTBmZmYsMHhlMTAwMC0weGUzZmZmIG9uIGlzYTAKc2MwIGZhaWxlZCB0byBwcm9i
ZSBvbiBpc2EwCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYjAtMHgzYmIgaW9t
ZW0gMHhiMDAwMC0weGI3ZmZmIG9uIGlzYTAKYXRrYmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9y
dCAweDYwIG9uIGlzYTAKZmRjMDogY2Fubm90IHJlc2VydmUgaW50ZXJydXB0IGxpbmUKZmRjMCBm
YWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBp
c2EwCnVhcnQwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2Y4IGlycSA0IG9uIGlzYTAKd2J3
ZDAgZmFpbGVkIHRvIHByb2JlIG9uIGlzYTAKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBu
UCBkZXZpY2VzCkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLgpwcm9jZnMgcmVnaXN0ZXJl
ZApaRlMgTk9USUNFOiBQcmVmZXRjaCBpcyBkaXNhYmxlZCBieSBkZWZhdWx0IGlmIGxlc3MgdGhh
biA0R0Igb2YgUkFNIGlzIHByZXNlbnQ7CiAgICAgICAgICAgIHRvIGVuYWJsZSwgYWRkICJ2ZnMu
emZzLnByZWZldGNoX2Rpc2FibGU9MCIgdG8gL2Jvb3QvbG9hZGVyLmNvbmYuClpGUyBmaWxlc3lz
dGVtIHZlcnNpb246IDUKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uOiBmZWF0dXJlcyBzdXBwb3J0
ICg1MDAwKQpUaW1lY291bnRlcnMgdGljayBldmVyeSAxMC4wMDAgbXNlYwp2bGFuOiBpbml0aWFs
aXplZCwgdXNpbmcgaGFzaCB0YWJsZXMgd2l0aCBjaGFpbmluZwp0Y3BfaW5pdDogbmV0LmluZXQu
dGNwLnRjYmhhc2hzaXplIGF1dG8gdHVuZWQgdG8gMTYzODQKbG8wOiBicGYgYXR0YWNoZWQKaHB0
cnI6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQuCmhwdG5yOiBubyBjb250cm9sbGVyIGRldGVjdGVk
LgpocHQyN3h4OiBubyBjb250cm9sbGVyIGRldGVjdGVkLgpoZGFjYzA6IDxBbmFsb2cgRGV2aWNl
cyBBRDE5ODRBIEhEQSBDT0RFQz4gYXQgY2FkIDAgb24gaGRhYzAKaGRhYTA6IDxBbmFsb2cgRGV2
aWNlcyBBRDE5ODRBIEF1ZGlvIEZ1bmN0aW9uIEdyb3VwPiBhdCBuaWQgMSBvbiBoZGFjYzAKaGRh
YTA6IFN1YnN5c3RlbSBJRDogMHgxMDI4MDI5MwpoZGFhMDogTnVtR1BJTz0zIE51bUdQTz0wIE51
bUdQST0wIEdQSVdha2U9MCBHUElVbnNvbD0xCmhkYWEwOiAgR1BJTzA6IGRpc2FibGVkCmhkYWEw
OiAgR1BJTzE6IGRpc2FibGVkCmhkYWEwOiAgR1BJTzI6IGRpc2FibGVkCmhkYWEwOiBXQVJOSU5H
OiBuaWQ9NDIgaGFzIGNuaWQgb3V0c2lkZSBvZiB0aGUgQUZHIHJhbmdlIGo9MCBlbnRudW09NCBp
bmRleD0wIHJlcz0weDAwMDAyNzAxCmhkYWEwOiBPcmlnaW5hbCBwaW5zIGNvbmZpZ3VyYXRpb246
CmhkYWEwOiBuaWQgICAweCAgICBhcyBzZXEgZGV2aWNlICAgICAgIGNvbm4gIGphY2sgICAgbG9j
ICAgICAgICBjb2xvciAgIG1pc2MKaGRhYTA6IDE3IDAyMjE0MDQwIDQgIDAgIEhlYWRwaG9uZXMg
ICAgSmFjayAgMS84ICAgICBGcm9udCAgICAgIEdyZWVuICAgMApoZGFhMDogMTggMDEwMTQwMTAg
MSAgMCAgTGluZS1vdXQgICAgICBKYWNrICAxLzggICAgIFJlYXIgICAgICAgR3JlZW4gICAwCmhk
YWEwOiAxOSA5OTEzMDFmMCAxNSAwICBTcGVha2VyICAgICAgIEZpeGVkIEFUQVBJICAgT25ib2Fy
ZCAgICBVbmtub3duIDEKaGRhYTA6IDIwIDAyYTE5MDIwIDIgIDAgIE1pYyAgICAgICAgICAgSmFj
ayAgMS84ICAgICBGcm9udCAgICAgIFBpbmsgICAgMApoZGFhMDogMjEgMDE4MTMwMzAgMyAgMCAg
TGluZS1pbiAgICAgICBKYWNrICAxLzggICAgIFJlYXIgICAgICAgQmx1ZSAgICAwCmhkYWEwOiAy
MiA0MTMzMDFmMCAxNSAwICBDRCAgICAgICAgICAgIE5vbmUgIEFUQVBJICAgUmVhciAgICAgICBV
bmtub3duIDEKaGRhYTA6IDIzIDQxYTYwMWYwIDE1IDAgIE1pYyAgICAgICAgICAgTm9uZSAgRGln
aXRhbCBSZWFyICAgICAgIFVua25vd24gMQpoZGFhMDogMjYgNDFmMzAxZjAgMTUgMCAgT3RoZXIg
ICAgICAgICBOb25lICBBVEFQSSAgIFJlYXIgICAgICAgVW5rbm93biAxCmhkYWEwOiAyNyA0MTQ1
MDFmMCAxNSAwICBTUERJRi1vdXQgICAgIE5vbmUgIE9wdGljYWwgUmVhciAgICAgICBVbmtub3du
IDEKaGRhYTA6IDI4IDQxMzMwMWYwIDE1IDAgIENEICAgICAgICAgICAgTm9uZSAgQVRBUEkgICBS
ZWFyICAgICAgIFVua25vd24gMQpoZGFhMDogUGF0Y2hpbmcgd2lkZ2V0IGNhcHMgbmlkPTIzIDB4
MDA0MDAyMGIgLT4gMHgwMDQwMDAwYgpoZGFhMDogUGF0Y2hpbmcgd2lkZ2V0IGNhcHMgbmlkPTI2
IDB4MDA0MDAwMDAgLT4gMHgwMDcwMDAwMApoZGFhMDogUGF0Y2hlZCBwaW5zIGNvbmZpZ3VyYXRp
b246CmhkYWEwOiBuaWQgICAweCAgICBhcyBzZXEgZGV2aWNlICAgICAgIGNvbm4gIGphY2sgICAg
bG9jICAgICAgICBjb2xvciAgIG1pc2MKaGRhYTA6IDE3IDAyMjE0MDQwIDQgIDAgIEhlYWRwaG9u
ZXMgICAgSmFjayAgMS84ICAgICBGcm9udCAgICAgIEdyZWVuICAgMApoZGFhMDogMTggMDEwMTQw
MTAgMSAgMCAgTGluZS1vdXQgICAgICBKYWNrICAxLzggICAgIFJlYXIgICAgICAgR3JlZW4gICAw
CmhkYWEwOiAxOSA5OTEzMDFmMCAxNSAwICBTcGVha2VyICAgICAgIEZpeGVkIEFUQVBJICAgT25i
b2FyZCAgICBVbmtub3duIDEKaGRhYTA6IDIwIDAyYTE5MDIwIDIgIDAgIE1pYyAgICAgICAgICAg
SmFjayAgMS84ICAgICBGcm9udCAgICAgIFBpbmsgICAgMApoZGFhMDogMjEgMDE4MTMwMzAgMyAg
MCAgTGluZS1pbiAgICAgICBKYWNrICAxLzggICAgIFJlYXIgICAgICAgQmx1ZSAgICAwCmhkYWEw
OiAyMiA0MTMzMDFmMCAxNSAwICBDRCAgICAgICAgICAgIE5vbmUgIEFUQVBJICAgUmVhciAgICAg
ICBVbmtub3duIDEgRElTQQpoZGFhMDogMjMgNDFhNjAxZjAgMTUgMCAgTWljICAgICAgICAgICBO
b25lICBEaWdpdGFsIFJlYXIgICAgICAgVW5rbm93biAxIERJU0EKaGRhYTA6IDI3IDQxNDUwMWYw
IDE1IDAgIFNQRElGLW91dCAgICAgTm9uZSAgT3B0aWNhbCBSZWFyICAgICAgIFVua25vd24gMSBE
SVNBCmhkYWEwOiAyOCA0MTMzMDFmMCAxNSAwICBDRCAgICAgICAgICAgIE5vbmUgIEFUQVBJICAg
UmVhciAgICAgICBVbmtub3duIDEgRElTQQpoZGFhMDogNSBhc3NvY2lhdGlvbnMgZm91bmQ6Cmhk
YWEwOiBBc3NvY2lhdGlvbiAwICgxKSBvdXQ6CmhkYWEwOiAgUGluIG5pZD0xOCBzZXE9MApoZGFh
MDogQXNzb2NpYXRpb24gMSAoMikgaW46CmhkYWEwOiAgUGluIG5pZD0yMCBzZXE9MApoZGFhMDog
QXNzb2NpYXRpb24gMiAoMykgaW46CmhkYWEwOiAgUGluIG5pZD0yMSBzZXE9MApoZGFhMDogQXNz
b2NpYXRpb24gMyAoNCkgb3V0OgpoZGFhMDogIFBpbiBuaWQ9MTcgc2VxPTAKaGRhYTA6IEFzc29j
aWF0aW9uIDQgKDE1KSBvdXQ6CmhkYWEwOiAgUGluIG5pZD0xOSBzZXE9MApoZGFhMDogVHJhY2lu
ZyBhc3NvY2lhdGlvbiAwICgxKQpoZGFhMDogIFBpbiAxOCB0cmFjZWQgdG8gREFDIDMKaGRhYTA6
IEFzc29jaWF0aW9uIDAgKDEpIHRyYWNlIHN1Y2NlZWRlZApoZGFhMDogVHJhY2luZyBhc3NvY2lh
dGlvbiAxICgyKQpoZGFhMDogIFBpbiAyMCB0cmFjZWQgdG8gQURDIDgKaGRhYTA6IEFzc29jaWF0
aW9uIDEgKDIpIHRyYWNlIHN1Y2NlZWRlZApoZGFhMDogVHJhY2luZyBhc3NvY2lhdGlvbiAyICgz
KQpoZGFhMDogIFBpbiAyMSB0cmFjZWQgdG8gQURDIDkKaGRhYTA6IEFzc29jaWF0aW9uIDIgKDMp
IHRyYWNlIHN1Y2NlZWRlZApoZGFhMDogVHJhY2luZyBhc3NvY2lhdGlvbiAzICg0KQpoZGFhMDog
IFBpbiAxNyB0cmFjZWQgdG8gREFDIDQKaGRhYTA6IEFzc29jaWF0aW9uIDMgKDQpIHRyYWNlIHN1
Y2NlZWRlZApoZGFhMDogVHJhY2luZyBhc3NvY2lhdGlvbiA0ICgxNSkKaGRhYTA6ICBVbmFibGUg
dG8gdHJhY2UgcGluIDE5IHNlcSAwIHdpdGggbWluIG5pZCAwCmhkYWEwOiBBc3NvY2lhdGlvbiA0
ICgxNSkgdHJhY2UgZmFpbGVkCmhkYWEwOiBMb29raW5nIGZvciBhZGRpdGlvbmFsIERBQyBmb3Ig
YXNzb2NpYXRpb24gMCAoMSkKaGRhYTA6IExvb2tpbmcgZm9yIGFkZGl0aW9uYWwgQURDIGZvciBh
c3NvY2lhdGlvbiAxICgyKQpoZGFhMDogTG9va2luZyBmb3IgYWRkaXRpb25hbCBBREMgZm9yIGFz
c29jaWF0aW9uIDIgKDMpCmhkYWEwOiBMb29raW5nIGZvciBhZGRpdGlvbmFsIERBQyBmb3IgYXNz
b2NpYXRpb24gMyAoNCkKaGRhYTA6IFRyYWNpbmcgaW5wdXQgbW9uaXRvcgpoZGFhMDogVHJhY2lu
ZyBvdGhlciBpbnB1dCBtb25pdG9ycwpoZGFhMDogIFRyYWNpbmcgbmlkIDIwIHRvIG91dApoZGFh
MDogIG5pZCAyMCBpcyBpbnB1dCBtb25pdG9yCmhkYWEwOiAgVHJhY2luZyBuaWQgMjEgdG8gb3V0
CmhkYWEwOiAgbmlkIDIxIGlzIGlucHV0IG1vbml0b3IKaGRhYTA6IFRyYWNpbmcgYmVlcGVyCmhk
YWEwOiAgbmlkIDI2IHRyYWNlZCB0byBvdXQKaGRhYTA6IEZHIGNvbmZpZy9xdWlya3M6IGZvcmNl
c3RlcmVvIGl2cmVmNTAgaXZyZWY4MCBpdnJlZjEwMCBpdnJlZgpwY20wOiA8QW5hbG9nIERldmlj
ZXMgQUQxOTg0QSAoQW5hbG9nKT4gYXQgbmlkIDE4IGFuZCAyMCBvbiBoZGFhMApwY20wOiBQbGF5
YmFjazoKcGNtMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxIFBDTQpwY20wOiAgICAgICAg
IFBDTSBjYXA6IDB4MDAwZTA3ZmYgMTYgMjAgMjQgYml0cywgOCAxMSAxNiAyMiAzMiA0NCA0OCA4
OCA5NiAxNzYgMTkyIEtIegpwY20wOiAgICAgICAgICAgICBEQUM6IDMKcGNtMDoKcGNtMDogICAg
IG5pZD0xOCBbcGluOiBMaW5lLW91dCAoR3JlZW4gSmFjayldCnBjbTA6ICAgICAgICsgPC0gbmlk
PTEwIFthdWRpbyBtaXhlcl0gW3NyYzogcGNtLCBzcGVha2VyLCBsaW5lLCBtaWNdCnBjbTA6ICAg
ICAgICAgICAgICArIDwtIG5pZD0zMyBbYXVkaW8gc2VsZWN0b3JdIFtzcmM6IHBjbSwgc3BlYWtl
ciwgbGluZSwgbWljXQpwY20wOiAgICAgICAgICAgICAgICAgICAgICsgPC0gbmlkPTMyIFthdWRp
byBtaXhlcl0gW3NyYzogcGNtLCBzcGVha2VyLCBsaW5lLCBtaWNdCnBjbTA6ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICsgPC0gbmlkPTIwIFtwaW46IE1pYyAoUGluayBKYWNrKV0gW3NyYzog
bWljXQpwY20wOiAgICAgICAgICAgICAgICAgICAgICAgICAgICArIDwtIG5pZD0yMSBbcGluOiBM
aW5lLWluIChCbHVlIEphY2spXSBbc3JjOiBsaW5lXQpwY20wOiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICArIDwtIG5pZD0yNiBbYmVlcCB3aWRnZXRdIFtzcmM6IHNwZWFrZXJdCnBjbTA6ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICsgPC0gbmlkPTMgW2F1ZGlvIG91dHB1dF0gW3NyYzog
cGNtXQpwY20wOgpwY20wOiBSZWNvcmQ6CnBjbTA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAw
MSBQQ00KcGNtMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwN2ZmIDE2IDIwIDI0IGJpdHMsIDgg
MTEgMTYgMjIgMzIgNDQgNDggODggOTYgMTc2IDE5MiBLSHoKcGNtMDogICAgICAgICAgICAgQURD
OiA4CnBjbTA6CnBjbTA6ICAgICBuaWQ9OCBbYXVkaW8gaW5wdXRdCnBjbTA6ICAgICAgICsgPC0g
bmlkPTEyIFthdWRpbyBzZWxlY3Rvcl0gW3NyYzogbWljXQpwY20wOiAgICAgICAgICAgICAgKyA8
LSBuaWQ9MjAgW3BpbjogTWljIChQaW5rIEphY2spXSBbc3JjOiBtaWNdCnBjbTA6CnBjbTA6IE1h
c3RlciBWb2x1bWUgKE9TUzogdm9sKTogLTQ2LzBkQgpwY20wOiAgICArLSBjdGwgIDEgKG5pZCAg
IDMgb3V0KTogICAgLTU4LzBkQiAoNDAgc3RlcHMpCnBjbTA6ICAgICstIGN0bCAgNiAobmlkICAx
MCBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0bCAxMyAobmlkICAxOCBpbiApOiAgICBtdXRl
CnBjbTA6ICAgICstIGN0bCAyMyAobmlkICAzMiBpbiAgIDApOiAtMzQvMTJkQiAoMzIgc3RlcHMp
ICsgbXV0ZQpwY20wOiAgICArLSBjdGwgMjQgKG5pZCAgMzIgaW4gICAxKTogLTM0LzEyZEIgKDMy
IHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0gY3RsIDI2IChuaWQgIDMyIGluICAgMyk6IC0zNC8x
MmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6ICAgICstIGN0bCAyOCAobmlkICAzMiBpbiAgIDUp
OiAtMzQvMTJkQiAoMzIgc3RlcHMpICsgbXV0ZQpwY20wOiAgICArLSBjdGwgMzAgKG5pZCAgMzMg
b3V0KTogICAgLTQ2LzBkQiAoMzIgc3RlcHMpICsgbXV0ZQpwY20wOgpwY20wOiBQQ00gVm9sdW1l
IChPU1M6IHBjbSk6IC01OC8wZEIKcGNtMDogICAgKy0gY3RsICAxIChuaWQgICAzIG91dCk6ICAg
IC01OC8wZEIgKDQwIHN0ZXBzKQpwY20wOiAgICArLSBjdGwgMjggKG5pZCAgMzIgaW4gICA1KTog
LTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDoKcGNtMDogTWljcm9waG9uZSBWb2x1bWUg
KE9TUzogbWljKTogMC8zMGRCCnBjbTA6ICAgICstIGN0bCAgOSAobmlkICAxMiBvdXQpOiAgICAt
NTgvMjJkQiAoNTUgc3RlcHMpICsgbXV0ZQpwY20wOiAgICArLSBjdGwgMTUgKG5pZCAgMjAgb3V0
KTogICAgMC8zMGRCICg0IHN0ZXBzKQpwY20wOiAgICArLSBjdGwgMjMgKG5pZCAgMzIgaW4gICAw
KTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDoKcGNtMDogTGluZS1pbiBWb2x1bWUg
KE9TUzogbGluZSkKcGNtMDogICAgKy0gY3RsIDI0IChuaWQgIDMyIGluICAgMSk6IC0zNC8xMmRC
ICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6CnBjbTA6IFNwZWFrZXIvQmVlcCBWb2x1bWUgKE9TUzog
c3BlYWtlcik6IC0zNC8wZEIKcGNtMDogICAgKy0gY3RsIDExIChuaWQgIDE2IG91dCk6ICAgIC00
NS8wZEIgKDE2IHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0gY3RsIDI2IChuaWQgIDMyIGluICAg
Myk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6CnBjbTA6IFJlY29yZGluZyBMZXZl
bCAoT1NTOiByZWMpOiAtNTgvMjJkQgpwY20wOiAgICArLSBjdGwgIDkgKG5pZCAgMTIgb3V0KTog
ICAgLTU4LzIyZEIgKDU1IHN0ZXBzKSArIG11dGUKcGNtMDoKcGNtMDogSW5wdXQgTW9uaXRvcmlu
ZyBMZXZlbCAoT1NTOiBpZ2Fpbik6IC0zNC8xMmRCCnBjbTA6ICAgICstIGN0bCAyMyAobmlkICAz
MiBpbiAgIDApOiAtMzQvMTJkQiAoMzIgc3RlcHMpICsgbXV0ZQpwY20wOiAgICArLSBjdGwgMjQg
KG5pZCAgMzIgaW4gICAxKTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0g
Y3RsIDI2IChuaWQgIDMyIGluICAgMyk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6
CnBjbTA6IE1peGVyICJ2b2wiOgpwY20wOiBNaXhlciAicGNtIjoKcGNtMDogTWl4ZXIgInNwZWFr
ZXIiOgpwY20wOiBNaXhlciAibWljIjoKcGNtMDogTWl4ZXIgInJlYyI6CnBjbTA6IE1peGVyICJp
Z2FpbiI6CnBjbTA6IE1peGVyICJvZ2FpbiI6CnBjbTA6IFBsYXliYWNrIGNoYW5uZWwgc2V0IGlz
OiBGcm9udCBMZWZ0LCBGcm9udCBSaWdodCwKcGNtMDogUGxheWJhY2sgY2hhbm5lbCBtYXRyaXgg
aXM6IDIuMCAoZGlzY29ubmVjdGVkKQpwY20wOiBSZWNvcmRpbmcgY2hhbm5lbCBzZXQgaXM6IEZy
b250IExlZnQsIEZyb250IFJpZ2h0LApwY20wOiBSZWNvcmRpbmcgY2hhbm5lbCBtYXRyaXggaXM6
IDIuMCAoZGlzY29ubmVjdGVkKQpwY20xOiA8QW5hbG9nIERldmljZXMgQUQxOTg0QSAoQW5hbG9n
KT4gYXQgbmlkIDE3IGFuZCAyMSBvbiBoZGFhMApwY20xOiBQbGF5YmFjazoKcGNtMTogICAgICBT
dHJlYW0gY2FwOiAweDAwMDAwMDAxIFBDTQpwY20xOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA3
ZmYgMTYgMjAgMjQgYml0cywgOCAxMSAxNiAyMiAzMiA0NCA0OCA4OCA5NiAxNzYgMTkyIEtIegpw
Y20xOiAgICAgICAgICAgICBEQUM6IDQKcGNtMToKcGNtMTogICAgIG5pZD0xNyBbcGluOiBIZWFk
cGhvbmVzIChHcmVlbiBKYWNrKV0KcGNtMTogICAgICAgKyA8LSBuaWQ9NyBbYXVkaW8gbWl4ZXJd
IFtzcmM6IHBjbV0KcGNtMTogICAgICAgICAgICAgICsgPC0gbmlkPTM0IFthdWRpbyBzZWxlY3Rv
cl0gW3NyYzogcGNtXQpwY20xOiAgICAgICAgICAgICAgICAgICAgICsgPC0gbmlkPTQgW2F1ZGlv
IG91dHB1dF0gW3NyYzogcGNtXQpwY20xOgpwY20xOiBSZWNvcmQ6CnBjbTE6ICAgICAgU3RyZWFt
IGNhcDogMHgwMDAwMDAwMSBQQ00KcGNtMTogICAgICAgICBQQ00gY2FwOiAweDAwMGUwN2ZmIDE2
IDIwIDI0IGJpdHMsIDggMTEgMTYgMjIgMzIgNDQgNDggODggOTYgMTc2IDE5MiBLSHoKcGNtMTog
ICAgICAgICAgICAgQURDOiA5CnBjbTE6CnBjbTE6ICAgICBuaWQ9OSBbYXVkaW8gaW5wdXRdCnBj
bTE6ICAgICAgICsgPC0gbmlkPTEzIFthdWRpbyBzZWxlY3Rvcl0gW3NyYzogbGluZV0KcGNtMTog
ICAgICAgICAgICAgICsgPC0gbmlkPTIxIFtwaW46IExpbmUtaW4gKEJsdWUgSmFjayldIFtzcmM6
IGxpbmVdCnBjbTE6CnBjbTE6IE1hc3RlciBWb2x1bWUgKE9TUzogdm9sKTogLTU4LzBkQgpwY20x
OiAgICArLSBjdGwgIDIgKG5pZCAgIDQgb3V0KTogICAgLTU4LzBkQiAoNDAgc3RlcHMpCnBjbTE6
ICAgICstIGN0bCAgMyAobmlkICAgNyBpbiAgIDApOiBtdXRlCnBjbTE6ICAgICstIGN0bCAxMiAo
bmlkICAxNyBpbiApOiAgICBtdXRlCnBjbTE6CnBjbTE6IFBDTSBWb2x1bWUgKE9TUzogcGNtKTog
LTU4LzBkQgpwY20xOiAgICArLSBjdGwgIDIgKG5pZCAgIDQgb3V0KTogICAgLTU4LzBkQiAoNDAg
c3RlcHMpCnBjbTE6ICAgICstIGN0bCAgMyAobmlkICAgNyBpbiAgIDApOiBtdXRlCnBjbTE6ICAg
ICstIGN0bCAxMiAobmlkICAxNyBpbiApOiAgICBtdXRlCnBjbTE6CnBjbTE6IExpbmUtaW4gVm9s
dW1lIChPU1M6IGxpbmUpOiAwLzMwZEIKcGNtMTogICAgKy0gY3RsIDEwIChuaWQgIDEzIG91dCk6
ICAgIC01OC8yMmRCICg1NSBzdGVwcykgKyBtdXRlCnBjbTE6ICAgICstIGN0bCAxNiAobmlkICAy
MSBvdXQpOiAgICAwLzMwZEIgKDQgc3RlcHMpCnBjbTE6CnBjbTE6IFJlY29yZGluZyBMZXZlbCAo
T1NTOiByZWMpOiAtNTgvMjJkQgpwY20xOiAgICArLSBjdGwgMTAgKG5pZCAgMTMgb3V0KTogICAg
LTU4LzIyZEIgKDU1IHN0ZXBzKSArIG11dGUKcGNtMToKcGNtMTogTWl4ZXIgInZvbCI6CnBjbTE6
IE1peGVyICJwY20iOgpwY20xOiBNaXhlciAibGluZSI6CnBjbTE6IE1peGVyICJyZWMiOgpwY20x
OiBQbGF5YmFjayBjaGFubmVsIHNldCBpczogRnJvbnQgTGVmdCwgRnJvbnQgUmlnaHQsCnBjbTE6
IFBsYXliYWNrIGNoYW5uZWwgbWF0cml4IGlzOiAyLjAgKGRpc2Nvbm5lY3RlZCkKcGNtMTogUmVj
b3JkaW5nIGNoYW5uZWwgc2V0IGlzOiBGcm9udCBMZWZ0LCBGcm9udCBSaWdodCwKcGNtMTogUmVj
b3JkaW5nIGNoYW5uZWwgbWF0cml4IGlzOiAyLjAgKGRpc2Nvbm5lY3RlZCkKdXNidXMwOiAxMk1i
cHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4w
CnVzYnVzMjogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMzOiA0ODBNYnBzIEhpZ2gg
U3BlZWQgVVNCIHYyLjAKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1YjA6IDxJbnRlbCBV
SENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMx
CnVnZW4wLjE6IDxJbnRlbD4gYXQgdXNidXMwCnVodWIxOiA8SW50ZWwgVUhDSSByb290IEhVQiwg
Y2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMi4xOiA8SW50
ZWw+IGF0IHVzYnVzMgp1aHViMjogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2
IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdWdlbjMuMTogPEludGVsPiBhdCB1c2J1czMK
dWh1YjM6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFk
ZHIgMT4gb24gdXNidXMzCnVzYnVzNDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM1
OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czY6IDEyTWJwcyBGdWxsIFNwZWVkIFVT
QiB2MS4wCnVnZW40LjE6IDxJbnRlbD4gYXQgdXNidXM0CnVodWI0OiA8SW50ZWwgVUhDSSByb290
IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNAp1Z2VuNS4x
OiA8SW50ZWw+IGF0IHVzYnVzNQp1aHViNTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkv
MCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czUKdWdlbjYuMTogPEludGVsPiBhdCB1
c2J1czYKdWh1YjY6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu
MDAsIGFkZHIgMT4gb24gdXNidXM2CnVzYnVzNzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4w
CmFoY2ljaDA6IEFIQ0kgcmVzZXQuLi4KYWhjaWNoMDogU0FUQSBjb25uZWN0IHRpbWU9MTAwdXMg
c3RhdHVzPTAwMDAwMTIzCnVnZW43LjE6IDxJbnRlbD4gYXQgdXNidXM3CnVodWI3OiA8SW50ZWwg
RUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVz
NwphaGNpY2gwOiBBSENJIHJlc2V0OiBkZXZpY2UgZm91bmQKYWhjaWNoMDogQUhDSSByZXNldDog
ZGV2aWNlIHJlYWR5IGFmdGVyIDBtcwphaGNpY2gxOiBBSENJIHJlc2V0Li4uCmFoY2ljaDE6IFNB
VEEgY29ubmVjdCB0aW1lPTEwMHVzIHN0YXR1cz0wMDAwMDEyMwphaGNpY2gxOiBBSENJIHJlc2V0
OiBkZXZpY2UgZm91bmQKYWhjaWNoMTogQUhDSSByZXNldDogZGV2aWNlIHJlYWR5IGFmdGVyIDBt
cwphaGNpY2gyOiBBSENJIHJlc2V0Li4uCmFoY2ljaDI6IFNBVEEgY29ubmVjdCB0aW1lPTEwMDB1
cyBzdGF0dXM9MDAwMDAxMTMKYWhjaWNoMjogQUhDSSByZXNldDogZGV2aWNlIGZvdW5kCmFoY2lj
aDI6IEFIQ0kgcmVzZXQ6IGRldmljZSByZWFkeSBhZnRlciAwbXMKYWhjaWNoMzogQUhDSSByZXNl
dC4uLgphaGNpY2gzOiBTQVRBIG9mZmxpbmUgc3RhdHVzPTAwMDAwMDA0CmFoY2ljaDM6IEFIQ0kg
cmVzZXQ6IGRldmljZSBub3QgZm91bmQKYWhjaWNoNDogQUhDSSByZXNldC4uLgphaGNpY2g0OiBT
QVRBIG9mZmxpbmUgc3RhdHVzPTAwMDAwMDA0CmFoY2ljaDQ6IEFIQ0kgcmVzZXQ6IGRldmljZSBu
b3QgZm91bmQKYWhjaWNoNTogQUhDSSByZXNldC4uLgphaGNpY2g1OiBTQVRBIGNvbm5lY3QgdGlt
ZW91dCB0aW1lPTEwMDAwdXMgc3RhdHVzPTAwMDAwMDAwCmFoY2ljaDU6IEFIQ0kgcmVzZXQ6IGRl
dmljZSBub3QgZm91bmQKc2VzMCBhdCBhaGNpZW0wIGJ1cyAwIHNjYnVzNiB0YXJnZXQgMCBsdW4g
MApzZXMwOiA8QUhDSSBTR1BJTyBFbmNsb3N1cmUgMS4wMCAwMDAxPiBTRU1CIFMtRS1TIDIuMDAg
ZGV2aWNlCnNlczA6IFNFTUIgU0VTIERldmljZQphZGEwIGF0IGFoY2ljaDAgYnVzIDAgc2NidXMw
IHRhcmdldCAwIGx1biAwCmFkYTA6IDxTVDUwMERNMDAyLTFCRDE0MiBLQzQ1PiBBVEEtOCBTQVRB
IDMueCBkZXZpY2UKYWRhMDogU2VyaWFsIE51bWJlciBaM1QzRkpYTAphZGEwOiAzMDAuMDAwTUIv
cyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJieXRlcykKYWRhMDogQ29tbWFu
ZCBRdWV1ZWluZyBlbmFibGVkCmFkYTA6IDQ3Njk0ME1CICg5NzY3NzMxNjggNTEyIGJ5dGUgc2Vj
dG9yczogMTZIIDYzUy9UIDE2MzgzQykKc2VzMDogR2VuZXJhdGlvbiBDb2RlIDB4MCBoYXMgMSBT
dWJFbmNsb3N1cmVzCnNlczA6ICBTdWJFbmNsb3N1cmUgSUQgMCwgMSBUeXBlcyBXaXRoIHRoaXMg
SUQsIERlc2NyaXB0b3IgTGVuZ3RoIDM2LCBvZmZzZXQgOApzZXMwOiBXV046IDAKc2VzMDogIFR5
cGUgRGVzY1swXTogVHlwZSAweDE3LCBNYXhFbHQgNiwgSW4gU3ViZW5jIDAsIFRleHQgTGVuZ3Ro
IDA6CkdFT006IG5ldyBkaXNrIGFkYTAKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwg
c2VsZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJl
ZAphZGEwOiBxdWlya3M9MHgxPDRLPgphZGEwOiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDQK
dWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmFkYTEgYXQgYWhj
aWNoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAKYWRhMTogPFNUNTAwRE0wMDItMUJEMTQy
IEtDNDU+IEFUQS04IFNBVEEgMy54IGRldmljZQphZGExOiBTZXJpYWwgTnVtYmVyIFozVDNIQkVT
CmFkYTE6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5
dGVzKQphZGExOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhMTogNDc2OTQwTUIgKDk3Njc3
MzE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQp1aHViNDogMiBwb3J0cyB3
aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjU6IDIgcG9ydHMgd2l0aCAyIHJlbW92
YWJsZSwgc2VsZiBwb3dlcmVkCmFkYTE6IHF1aXJrcz0weDE8NEs+CmFkYTE6IFByZXZpb3VzbHkg
d2FzIGtub3duIGFzIGFkNgp1aHViNjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBv
d2VyZWQKcGFzczAgYXQgYWhjaWNoMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKcGFzczA6
IDxTVDUwMERNMDAyLTFCRDE0MiBLQzQ1PiBBVEEtOCBTQVRBIDMueCBkZXZpY2UKcGFzczA6IFNl
cmlhbCBOdW1iZXIgWjNUM0ZKWEwKcGFzczA6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAy
LngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQpwYXNzMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVk
CnBhc3MxIGF0IGFoY2ljaDEgYnVzIDAgc2NidXMxIHRhcmdldCAwIGx1biAwCnBhc3MxOiA8U1Q1
MDBETTAwMi0xQkQxNDIgS0M0NT4gQVRBLTggU0FUQSAzLnggZGV2aWNlCnBhc3MxOiBTZXJpYWwg
TnVtYmVyIFozVDNIQkVTCnBhc3MxOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBV
RE1BNiwgUElPIDgxOTJieXRlcykKcGFzczE6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApwYXNz
MiBhdCBhaGNpY2gyIGJ1cyAwIHNjYnVzMiB0YXJnZXQgMCBsdW4gMApwYXNzMjogPFRTU1Rjb3Jw
IERWRCstUlcgU0gtMjE2QkIgRDEwMD4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNlCnBh
c3MyOiBTZXJpYWwgTnVtYmVyIFI4VTQ2R0FDNjAxNVdGCnBhc3MyOiAxNTAuMDAwTUIvcyB0cmFu
c2ZlcnMgKFNBVEEgMS54LCBVRE1BNSwgQVRBUEkgMTJieXRlcywgUElPIDgxOTJieXRlcykKcGFz
czMgYXQgYWhjaWVtMCBidXMgMCBzY2J1czYgdGFyZ2V0IDAgbHVuIDAKcGFzczM6IDxBSENJIFNH
UElPIEVuY2xvc3VyZSAxLjAwIDAwMDE+IFNFTUIgUy1FLVMgMi4wMCBkZXZpY2UKcmFuZG9tOiB1
bmJsb2NraW5nIGRldmljZS4KTmV0dnNjIGluaXRpYWxpemluZy4uLiBkb25lIQpTTVA6IEFQIENQ
VSAjMSBMYXVuY2hlZCEKY3B1MSBBUCBYRU4gUFYgTEFQSUMKU01QOiBBUCBDUFUgIzQgTGF1bmNo
ZWQhCmNwdTQgQVAgWEVOIFBWIExBUElDClNNUDogQVAgQ1BVICM3IExhdW5jaGVkIQpjcHU3IEFQ
IFhFTiBQViBMQVBJQwpTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCEKY3B1MiBBUCBYRU4gUFYgTEFQ
SUMKU01QOiBBUCBDUFUgIzUgTGF1bmNoZWQhCmNwdTUgQVAgWEVOIFBWIExBUElDClNNUDogQVAg
Q1BVICMzIExhdW5jaGVkIQpjcHUzIEFQIFhFTiBQViBMQVBJQwpTTVA6IEFQIENQVSAjNiBMYXVu
Y2hlZCEKY3B1NiBBUCBYRU4gUFYgTEFQSUMKVFNDIHRpbWVjb3VudGVyIGRpc2NhcmRzIGxvd2Vy
IDEgYml0KHMpClRpbWVjb3VudGVyICJUU0MtbG93IiBmcmVxdWVuY3kgMTUzMzM5MDg4MyBIeiBx
dWFsaXR5IC0xMDAKV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVj
ZWQgcGVyZm9ybWFuY2UuCmNkMCBhdCBhaGNpY2gyIGJ1cyAwIHNjYnVzMiB0YXJnZXQgMCBsdW4g
MApjZDA6IDxUU1NUY29ycCBEVkQrLVJXIFNILTIxNkJCIEQxMDA+IFJlbW92YWJsZSBDRC1ST00g
U0NTSS0wIGRldmljZQpjZDA6IFNlcmlhbCBOdW1iZXIgUjhVNDZHQUM2MDE1V0YKY2QwOiAxNTAu
MDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMS54LCBVRE1BNSwgQVRBUEkgMTJieXRlcywgUElPIDgx
OTJieXRlcykKY2QwOiBBdHRlbXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJF
QURZLCBNZWRpdW0gbm90IHByZXNlbnQgLSB0cmF5IGNsb3NlZApHRU9NOiBuZXcgZGlzayBhZGEx
CkdFT006IG5ldyBkaXNrIGNkMApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czcgdXNidXMz
ClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNyB1c2J1czMKdWh1YjM6IDYgcG9ydHMgd2l0
aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI3OiA2IHBvcnRzIHdpdGggNiByZW1vdmFi
bGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czMKVHJ5aW5nIHRv
IG1vdW50IHJvb3QgZnJvbSB6ZnM6dGFuay9yb290IFtdLi4uCmJnZTA6IGxpbmsgc3RhdGUgY2hh
bmdlZCB0byBVUAp1Z2VuMS4yOiA8REVMTD4gYXQgdXNidXMxCnVrYmQwOiA8REVMTCBEZWxsIFVT
QiBFbnRyeSBLZXlib2FyZCwgY2xhc3MgMC8wLCByZXYgMS4xMC8xLjc4LCBhZGRyIDI+IG9uIHVz
YnVzMQprYmQyIGF0IHVrYmQwCmtiZDI6IHVrYmQwLCBnZW5lcmljICgwKSwgY29uZmlnOjB4MCwg
ZmxhZ3M6MHgzZDAwMDAKc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQKdWdlbjEuMzogPERF
TEw+IGF0IHVzYnVzMQpHRU9NX1BBUlQ6IHBhcnRpdGlvbiAyIGlzIG5vdCBhbGlnbmVkIG9uIDgx
OTIgYnl0ZXMKR0VPTV9QQVJUOiBwYXJ0aXRpb24gMiBpcyBub3QgYWxpZ25lZCBvbiA4MTkyIGJ5
dGVzCkdFT01fUEFSVDogcGFydGl0aW9uIDEgaXMgbm90IGFsaWduZWQgb24gODE5MiBieXRlcwpH
RU9NX1BBUlQ6IHBhcnRpdGlvbiAyIGlzIG5vdCBhbGlnbmVkIG9uIDgxOTIgYnl0ZXMKR0VPTV9Q
QVJUOiBwYXJ0aXRpb24gMyBpcyBub3QgYWxpZ25lZCBvbiA4MTkyIGJ5dGVzCkdFT01fUEFSVDog
cGFydGl0aW9uIDEgaXMgbm90IGFsaWduZWQgb24gODE5MiBieXRlcwpHRU9NX1BBUlQ6IHBhcnRp
dGlvbiAyIGlzIG5vdCBhbGlnbmVkIG9uIDgxOTIgYnl0ZXMKR0VPTV9QQVJUOiBwYXJ0aXRpb24g
MyBpcyBub3QgYWxpZ25lZCBvbiA4MTkyIGJ5dGVzCkdFT01fUEFSVDogcGFydGl0aW9uIDEgaXMg
bm90IGFsaWduZWQgb24gODE5MiBieXRlcwpHRU9NX1BBUlQ6IHBhcnRpdGlvbiAyIGlzIG5vdCBh
bGlnbmVkIG9uIDgxOTIgYnl0ZXMKR0VPTV9QQVJUOiBwYXJ0aXRpb24gMyBpcyBub3QgYWxpZ25l
ZCBvbiA4MTkyIGJ5dGVzCkdFT01fUEFSVDogcGFydGl0aW9uIDEgaXMgbm90IGFsaWduZWQgb24g
ODE5MiBieXRlcwpHRU9NX1BBUlQ6IHBhcnRpdGlvbiAyIGlzIG5vdCBhbGlnbmVkIG9uIDgxOTIg
Ynl0ZXMKR0VPTV9QQVJUOiBwYXJ0aXRpb24gMyBpcyBub3QgYWxpZ25lZCBvbiA4MTkyIGJ5dGVz
CkdFT01fUEFSVDogcGFydGl0aW9uIDIgaXMgbm90IGFsaWduZWQgb24gODE5MiBieXRlcwpTZXR0
aW5nIGhvc3R1dWlkOiA0NDQ1NGM0Yy0zMzAwLTEwNTctODAzNi1iM2MwNGY0NzM1NGEuClNldHRp
bmcgaG9zdGlkOiAweDAzM2NjNzI1LgpFbnRyb3B5IGhhcnZlc3Rpbmc6c3lzY3RsOiB1bmtub3du
IG9pZCAna2Vybi5yYW5kb20uc3lzLmhhcnZlc3QuaW50ZXJydXB0JzogTm8gc3VjaCBmaWxlIG9y
IGRpcmVjdG9yeQogaW50ZXJydXB0c3N5c2N0bDogdW5rbm93biBvaWQgJ2tlcm4ucmFuZG9tLnN5
cy5oYXJ2ZXN0LmV0aGVybmV0JzogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQogZXRoZXJuZXRz
eXNjdGw6IHVua25vd24gb2lkICdrZXJuLnJhbmRvbS5zeXMuaGFydmVzdC5wb2ludF90b19wb2lu
dCc6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKIHBvaW50X3RvX3BvaW50c3lzY3RsOiB1bmtu
b3duIG9pZCAna2Vybi5yYW5kb20uc3lzLmhhcnZlc3Quc3dpJzogTm8gc3VjaCBmaWxlIG9yIGRp
cmVjdG9yeQogc3dpLgpTdGFydGluZyBmaWxlIHN5c3RlbSBjaGVja3M6Ck1vdW50aW5nIGxvY2Fs
IGZpbGUgc3lzdGVtczouCkxvYWRpbmcga2VybmVsIG1vZHVsZXM6CldyaXRpbmcgZW50cm9weSBm
aWxlOi4KL2V0Yy9yYzogV0FSTklORzogJGhvc3RuYW1lIGlzIG5vdCBzZXQgLS0gc2VlIHJjLmNv
bmYoNSkuCmJyaWRnZTA6IGJwZiBhdHRhY2hlZApicmlkZ2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAw
MjowMzozYzpjNzoyNTowMApicmlkZ2UxOiBicGYgYXR0YWNoZWQKYnJpZGdlMTogRXRoZXJuZXQg
YWRkcmVzczogMDI6MDM6M2M6Yzc6MjU6MDEKQ3JlYXRlZCBjbG9uZSBpbnRlcmZhY2VzOiBicmlk
Z2UwIGJyaWRnZTEuCmJnZTA6IERpc2FibGluZyBmYXN0Ym9vdApiZ2UwOiBEaXNhYmxpbmcgZmFz
dGJvb3QKYmdlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KYmdlMDogcHJvbWlzY3VvdXMg
bW9kZSBlbmFibGVkCmJyaWRnZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dOClN0YXJ0aW5n
IGRoY2xpZW50LgpESENQUkVRVUVTVCBvbiBicmlkZ2UwIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0
IDY3CmVtMTogTGluayBpcyB1cCAxMDAwIE1icHMgRnVsbCBEdXBsZXgKZW0xOiBsaW5rIHN0YXRl
IGNoYW5nZWQgdG8gVVAKYmdlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCmJyaWRnZTA6IGxp
bmsgc3RhdGUgY2hhbmdlZCB0byBVUApESENQUkVRVUVTVCBvbiBicmlkZ2UwIHRvIDI1NS4yNTUu
MjU1LjI1NSBwb3J0IDY3CkRIQ1BBQ0sgZnJvbSAxNzIuMTYuMS4xCmJvdW5kIHRvIDE3Mi4xNi4x
LjIwIC0tIHJlbmV3YWwgaW4gMjE0NzQ4MzY0NyBzZWNvbmRzLgplbTE6IHByb21pc2N1b3VzIG1v
ZGUgZW5hYmxlZApicmlkZ2UxOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKU3RhcnRpbmcgZGhj
bGllbnQuCkRIQ1BSRVFVRVNUIG9uIGJyaWRnZTEgdG8gMjU1LjI1NS4yNTUuMjU1IHBvcnQgNjcK
REhDUFJFUVVFU1Qgb24gYnJpZGdlMSB0byAyNTUuMjU1LjI1NS4yNTUgcG9ydCA2NwpESENQRElT
Q09WRVIgb24gYnJpZGdlMSB0byAyNTUuMjU1LjI1NS4yNTUgcG9ydCA2NyBpbnRlcnZhbCA3CkRI
Q1BESVNDT1ZFUiBvbiBicmlkZ2UxIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3IGludGVydmFs
IDIxCkRIQ1BESVNDT1ZFUiBvbiBicmlkZ2UxIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3IGlu
dGVydmFsIDE2CkRIQ1BESVNDT1ZFUiBvbiBicmlkZ2UxIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0
IDY3IGludGVydmFsIDExCkRIQ1BESVNDT1ZFUiBvbiBicmlkZ2UxIHRvIDI1NS4yNTUuMjU1LjI1
NSBwb3J0IDY3IGludGVydmFsIDUKTm8gREhDUE9GRkVSUyByZWNlaXZlZC4KVHJ5aW5nIHJlY29y
ZGVkIGxlYXNlIDE3Mi4xNi4xLjEzOApib3VuZDogcmVuZXdhbCBpbiA0MzAyMCBzZWNvbmRzLgpT
dGFydGluZyBOZXR3b3JrOiBsbzAgYmNlMCBiY2UxIGVtMCBlbTEgYmdlMCBicmlkZ2UwIGJyaWRn
ZTEuCmxvMDogZmxhZ3M9ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FTVD4gbWV0cmlj
IDAgbXR1IDE2Mzg0CglvcHRpb25zPTYwMDAwMzxSWENTVU0sVFhDU1VNLFJYQ1NVTV9JUFY2LFRY
Q1NVTV9JUFY2PgoJaW5ldDYgOjoxIHByZWZpeGxlbiAxMjgKCWluZXQ2IGZlODA6OjElbG8wIHBy
ZWZpeGxlbiA2NCBzY29wZWlkIDB4NgoJaW5ldCAxMjcuMC4wLjEgbmV0bWFzayAweGZmMDAwMDAw
CgluZDYgb3B0aW9ucz0yMTxQRVJGT1JNTlVELEFVVE9fTElOS0xPQ0FMPgpiY2UwOiBmbGFncz04
ODAyPEJST0FEQ0FTVCxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKCW9wdGlv
bnM9YzAxYmI8UlhDU1VNLFRYQ1NVTSxWTEFOX01UVSxWTEFOX0hXVEFHR0lORyxKVU1CT19NVFUs
VkxBTl9IV0NTVU0sVFNPNCxWTEFOX0hXVFNPLExJTktTVEFURT4KCWV0aGVyIDAwOjEwOjE4OmUw
OjA1OjI4CgluZDYgb3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9D
QUw+CgltZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdApiY2UxOiBmbGFncz04ODAyPEJST0FEQ0FT
VCxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKCW9wdGlvbnM9YzAxYmI8UlhD
U1VNLFRYQ1NVTSxWTEFOX01UVSxWTEFOX0hXVEFHR0lORyxKVU1CT19NVFUsVkxBTl9IV0NTVU0s
VFNPNCxWTEFOX0hXVFNPLExJTktTVEFURT4KCWV0aGVyIDAwOjEwOjE4OmUwOjA1OjJhCgluZDYg
b3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+CgltZWRpYTog
RXRoZXJuZXQgYXV0b3NlbGVjdAplbTA6IGZsYWdzPThjMDI8QlJPQURDQVNULE9BQ1RJVkUsU0lN
UExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTQwMTliPFJYQ1NVTSxU
WENTVU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0sVFNPNCxWTEFOX0hXVFNP
PgoJZXRoZXIgMDA6MWI6MjE6YzY6ZTk6YWUKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZE
SVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0CglzdGF0
dXM6IG5vIGNhcnJpZXIKZW0xOiBmbGFncz04OTQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFBST01J
U0MsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTQwMTliPFJY
Q1NVTSxUWENTVU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0sVFNPNCxWTEFO
X0hXVFNPPgoJZXRoZXIgMDA6MWI6MjE6YzY6ZTk6YWYKCWluZXQ2IGZlODA6OjIxYjoyMWZmOmZl
YzY6ZTlhZiVlbTEgcHJlZml4bGVuIDY0IHRlbnRhdGl2ZSBzY29wZWlkIDB4NAoJbmQ2IG9wdGlv
bnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgoJbWVkaWE6IEV0aGVy
bmV0IGF1dG9zZWxlY3QgKDEwMDBiYXNlVCA8ZnVsbC1kdXBsZXg+KQoJc3RhdHVzOiBhY3RpdmUK
YmdlMDogZmxhZ3M9ODk0MzxVUCxCUk9BRENBU1QsUlVOTklORyxQUk9NSVNDLFNJTVBMRVgsTVVM
VElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAoJb3B0aW9ucz1jMDE5YjxSWENTVU0sVFhDU1VNLFZM
QU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdDU1VNLFRTTzQsVkxBTl9IV1RTTyxMSU5LU1RB
VEU+CglldGhlciBkNDphZTo1MjpjMTpkNDozZAoJaW5ldDYgZmU4MDo6ZDZhZTo1MmZmOmZlYzE6
ZDQzZCViZ2UwIHByZWZpeGxlbiA2NCB0ZW50YXRpdmUgc2NvcGVpZCAweDUKCW5kNiBvcHRpb25z
PTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KCW1lZGlhOiBFdGhlcm5l
dCBhdXRvc2VsZWN0ICgxMDAwYmFzZVQgPGZ1bGwtZHVwbGV4PikKCXN0YXR1czogYWN0aXZlCmJy
aWRnZTA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+
IG1ldHJpYyAwIG10dSAxNTAwCglldGhlciBkNDphZTo1MjpjMTpkNDozZAoJaW5ldCAxNzIuMTYu
MS4yMCBuZXRtYXNrIDB4ZmZmZmZmMDAgYnJvYWRjYXN0IDE3Mi4xNi4xLjI1NQoJbmQ2IG9wdGlv
bnM9OTxQRVJGT1JNTlVELElGRElTQUJMRUQ+CglpZCAwMDowMDowMDowMDowMDowMCBwcmlvcml0
eSAzMjc2OCBoZWxsb3RpbWUgMiBmd2RkZWxheSAxNQoJbWF4YWdlIDIwIGhvbGRjbnQgNiBwcm90
byByc3RwIG1heGFkZHIgMjAwMCB0aW1lb3V0IDEyMDAKCXJvb3QgaWQgMDA6MDA6MDA6MDA6MDA6
MDAgcHJpb3JpdHkgMzI3NjggaWZjb3N0IDAgcG9ydCAwCgltZW1iZXI6IGJnZTAgZmxhZ3M9MTQz
PExFQVJOSU5HLERJU0NPVkVSLEFVVE9FREdFLEFVVE9QVFA+CgkgICAgICAgIGlmbWF4YWRkciAw
IHBvcnQgNSBwcmlvcml0eSAxMjggcGF0aCBjb3N0IDU1CmJyaWRnZTE6IGZsYWdzPTg4NDM8VVAs
QlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCgll
dGhlciAwMDoxYjoyMTpjNjplOTphZgoJbmQ2IG9wdGlvbnM9OTxQRVJGT1JNTlVELElGRElTQUJM
RUQ+CglpZCAwMDowMDowMDowMDowMDowMCBwcmlvcml0eSAzMjc2OCBoZWxsb3RpbWUgMiBmd2Rk
ZWxheSAxNQoJbWF4YWdlIDIwIGhvbGRjbnQgNiBwcm90byByc3RwIG1heGFkZHIgMjAwMCB0aW1l
b3V0IDEyMDAKCXJvb3QgaWQgMDA6MDA6MDA6MDA6MDA6MDAgcHJpb3JpdHkgMzI3NjggaWZjb3N0
IDAgcG9ydCAwCgltZW1iZXI6IGVtMSBmbGFncz0xNDM8TEVBUk5JTkcsRElTQ09WRVIsQVVUT0VE
R0UsQVVUT1BUUD4KCSAgICAgICAgaWZtYXhhZGRyIDAgcG9ydCA0IHByaW9yaXR5IDEyOCBwYXRo
IGNvc3QgMjAwMDAKU3RhcnRpbmcgZGV2ZC4KU3RhcnRpbmcgTmV0d29yazogYmNlMC4KYmNlMDog
ZmxhZ3M9ODgwMjxCUk9BRENBU1QsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAw
CglvcHRpb25zPWMwMWJiPFJYQ1NVTSxUWENTVU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsSlVN
Qk9fTVRVLFZMQU5fSFdDU1VNLFRTTzQsVkxBTl9IV1RTTyxMSU5LU1RBVEU+CglldGhlciAwMDox
MDoxODplMDowNToyOAoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9f
TElOS0xPQ0FMPgoJbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QKU3RhcnRpbmcgTmV0d29yazog
YmNlMS4KYmNlMTogZmxhZ3M9ODgwMjxCUk9BRENBU1QsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJp
YyAwIG10dSAxNTAwCglvcHRpb25zPWMwMWJiPFJYQ1NVTSxUWENTVU0sVkxBTl9NVFUsVkxBTl9I
V1RBR0dJTkcsSlVNQk9fTVRVLFZMQU5fSFdDU1VNLFRTTzQsVkxBTl9IV1RTTyxMSU5LU1RBVEU+
CglldGhlciAwMDoxMDoxODplMDowNToyYQoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJ
U0FCTEVELEFVVE9fTElOS0xPQ0FMPgoJbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QKU3RhcnRp
bmcgTmV0d29yazogZW0wLgplbTA6IGZsYWdzPThjMDI8QlJPQURDQVNULE9BQ1RJVkUsU0lNUExF
WCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTQwMTliPFJYQ1NVTSxUWENT
VU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0sVFNPNCxWTEFOX0hXVFNPPgoJ
ZXRoZXIgMDA6MWI6MjE6YzY6ZTk6YWUKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNB
QkxFRCxBVVRPX0xJTktMT0NBTD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0CglzdGF0dXM6
IG5vIGNhcnJpZXIKYmdlMDogd2F0Y2hkb2cgdGltZW91dCAtLSByZXNldHRpbmcKYmdlMDogRGlz
YWJsaW5nIGZhc3Rib290CmJnZTA6IGxpbmsgRE9XTgpiZ2UwOiBEaXNhYmxpbmcgZmFzdGJvb3QK
YmdlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KYnJpZGdlMDogbGluayBzdGF0ZSBjaGFu
Z2VkIHRvIERPV04KYWRkIG5ldCBmZTgwOjo6IGdhdGV3YXkgOjoxCmFkZCBuZXQgZmYwMjo6OiBn
YXRld2F5IDo6MQphZGQgbmV0IDo6ZmZmZjowLjAuMC4wOiBnYXRld2F5IDo6MQphZGQgbmV0IDo6
MC4wLjAuMDogZ2F0ZXdheSA6OjEKRUxGIGxkY29uZmlnIHBhdGg6IC9saWIgL3Vzci9saWIgL3Vz
ci9saWIvY29tcGF0IC91c3IvbG9jYWwvbGliIC91c3IvbG9jYWwvbGliL2djYzQ3CjMyLWJpdCBj
b21wYXRpYmlsaXR5IGxkY29uZmlnIHBhdGg6IC91c3IvbGliMzIKQ3JlYXRpbmcgYW5kL29yIHRy
aW1taW5nIGxvZyBmaWxlcy4KU3RhcnRpbmcgc3lzbG9nZC4KQ2xlYXJpbmcgL3RtcCAoWCByZWxh
dGVkKS4KQ2xlYW5pbmcgeGVuc3RvcmUgZGF0YWJhc2UuClN0YXJ0aW5nIHhlbnNlcnZpY2VzOiB4
ZW5zdG9yZWQsIHhlbmNvbnNvbGVkLkRlYyAxNyAxMDo1MjowNiBvZGluIHhlbnN0b3JlZDogQ2hl
Y2tpbmcgc3RvcmUgLi4uCkRlYyAxNyAxMDo1MjowNiBvZGluIHhlbnN0b3JlZDogQ2hlY2tpbmcg
c3RvcmUgY29tcGxldGUuCldBUk5JTkc6IEZhaWxlZCB0byBvcGVuIGNvbm5lY3Rpb24gdG8gZ250
dGFiCnhlbmJhbGxvb24wOiA8WGVuIEJhbGxvb24gRGV2aWNlPiBvbiB4ZW5zdG9yZTAKeGN0cmww
OiA8WGVuIENvbnRyb2wgRGV2aWNlPiBvbiB4ZW5zdG9yZTAKeHNfZGV2MDogPFhlbnN0b3JlIHVz
ZXItc3BhY2UgZGV2aWNlPiBvbiB4ZW5zdG9yZTAKeGVuYnVzYl9mcm9udDA6IDxYZW4gRnJvbnRl
bmQgRGV2aWNlcz4gb24geGVuc3RvcmUwCnhlbmJ1c2JfYmFjazA6IDxYZW4gQmFja2VuZCBEZXZp
Y2VzPiBvbiB4ZW5zdG9yZTAKClNldHRpbmcgZG9tYWluIDAgbmFtZSwgZG9taWQgYW5kIEpTT04g
Y29uZmlnLi4uCnVtczA6IDxERUxMIERFTEwgVVNCIExhc2VyIE1vdXNlLCBjbGFzcyAwLzAsIHJl
diAyLjAwLzU3LjAwLCBhZGRyIDM+IG9uIHVzYnVzMQp1bXMwOiBlcnJvciByZWFkaW5nIHJlcG9y
dCBkZXNjcmlwdGlvbgpkZXZpY2VfYXR0YWNoOiB1bXMwIGF0dGFjaCByZXR1cm5lZCAxMgphaGNp
Y2gwOiBUaW1lb3V0IG9uIHNsb3QgNiBwb3J0IDAKYWhjaWNoMDogaXMgMDAwMDAwMDggY3MgMDAw
MDAwMDAgc3MgMDAwMDAwMDAgcnMgMDAwMDAwNzggdGZkIDQwIHNlcnIgMDAwMDAwMDAgY21kIDAw
MDBjNjE3CmFoY2ljaDA6IEFIQ0kgcmVzZXQuLi4KKGFkYTA6YWhjaWNoMDowOjA6MCk6IFdSSVRF
X0ZQRE1BX1FVRVVFRC4gQUNCOiA2MSA1OCA5MCAzOCAwMCA0MCAxMCAwMCAwMCAwMCAwMCAwMAoo
YWRhMDphaGNpY2gwOjA6MDowKTogQ0FNIHN0YXR1czogQ29tbWFuZCB0aW1lb3V0CihhZGEwOmFo
Y2ljaDA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCmFoY2ljaDA6IFNBVEEgY29ubmVjdCB0aW1l
PTEwMHVzIHN0YXR1cz0wMDAwMDEyMwphaGNpY2gwOiBBSENJIHJlc2V0OiBkZXZpY2UgZm91bmQK
YWhjaWNoMDogQUhDSSByZXNldDogZGV2aWNlIHJlYWR5IGFmdGVyIDEwMG1zCihYRU4pICoqKiBT
ZXJpYWwgaW5wdXQgLT4gWGVuICh0eXBlICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBp
bnB1dCB0byBET00wKQooWEVOKSBJUlEgaW5mb3JtYXRpb246CihYRU4pICAgIElSUTogICAwIGFm
ZmluaXR5OjAwMDAwMDAxIHZlYzpmMCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAw
MDAgdGltZXJfaW50ZXJydXB0KCkKKFhFTikgICAgSVJROiAgIDEgYWZmaW5pdHk6MDAwMDAwMDEg
dmVjOjMwIHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwNiBtYXBwZWQsIHVuYm91
bmQKKFhFTikgICAgSVJROiAgIDMgYWZmaW5pdHk6MDAwMDAwMDEgdmVjOjM4IHR5cGU9SU8tQVBJ
Qy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwNiBtYXBwZWQsIHVuYm91bmQKKFhFTikgICAgSVJROiAg
IDQgYWZmaW5pdHk6MDAwMDAwMDEgdmVjOmYxIHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0w
MDAwMDAwMCBuczE2NTUwX2ludGVycnVwdCgpCihYRU4pICAgIElSUTogICA1IGFmZmluaXR5OjAw
MDAwMDAxIHZlYzo0MCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVk
LCB1bmJvdW5kCihYRU4pICAgIElSUTogICA2IGFmZmluaXR5OjAwMDAwMDAxIHZlYzo0OCB0eXBl
PUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pICAg
IElSUTogICA3IGFmZmluaXR5OjAwMDAwMDAxIHZlYzo1MCB0eXBlPUlPLUFQSUMtZWRnZSAgICBz
dGF0dXM9MDAwMDAwMDYgbWFwcGVkLCB1bmJvdW5kCihYRU4pICAgIElSUTogICA4IGFmZmluaXR5
OjAwMDAwMDAxIHZlYzo1OCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDIgbWFw
cGVkLCB1bmJvdW5kCihYRU4pICAgIElSUTogICA5IGFmZmluaXR5OjAwMDAwMDAxIHZlYzo2MCB0
eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxp
c3Q9MDogIDkoLS0tKSwKKFhFTikgICAgSVJROiAgMTAgYWZmaW5pdHk6MDAwMDAwMDEgdmVjOjY4
IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhF
TikgICAgSVJROiAgMTEgYWZmaW5pdHk6MDAwMDAwMDEgdmVjOjcwIHR5cGU9SU8tQVBJQy1lZGdl
ICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgICAgSVJROiAgMTIgYWZm
aW5pdHk6MDAwMDAwMDEgdmVjOjc4IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAw
MiBtYXBwZWQsIHVuYm91bmQKKFhFTikgICAgSVJROiAgMTMgYWZmaW5pdHk6MDAwMDAwMDEgdmVj
Ojg4IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQK
KFhFTikgICAgSVJROiAgMTQgYWZmaW5pdHk6MDAwMDAwMDEgdmVjOjkwIHR5cGU9SU8tQVBJQy1l
ZGdlICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgICAgSVJROiAgMTUg
YWZmaW5pdHk6MDAwMDAwMDEgdmVjOjk4IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAw
MDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgICAgSVJROiAgMTYgYWZmaW5pdHk6MDAwMDAwMDEg
dmVjOmEwIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBk
b21haW4tbGlzdD0wOiAxNigtLS0pLAooWEVOKSAgICBJUlE6ICAxNyBhZmZpbml0eTowMDAwMDA0
MCB2ZWM6YTggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0w
IGRvbWFpbi1saXN0PTA6IDE3KC0tLSksCihYRU4pICAgIElSUTogIDE4IGFmZmluaXR5OjAwMDAw
MDAxIHZlYzpjMCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0
PTAgZG9tYWluLWxpc3Q9MDogMTgoLS0tKSwKKFhFTikgICAgSVJROiAgMjAgYWZmaW5pdHk6MDAw
MDAwMDQgdmVjOmM4IHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAxMCBpbi1mbGln
aHQ9MCBkb21haW4tbGlzdD0wOiAyMCgtLS0pLAooWEVOKSAgICBJUlE6ICAyMiBhZmZpbml0eTow
MDAwMDAyMCB2ZWM6YjAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZs
aWdodD0wIGRvbWFpbi1saXN0PTA6IDIyKC0tLSksCihYRU4pICAgIElSUTogIDIzIGFmZmluaXR5
OjAwMDAwMDAxIHZlYzpiOCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMzAgaW4t
ZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDogMjMoLS0tKSwKKFhFTikgICAgSVJROiAgMjQgYWZmaW5p
dHk6MDAwMDAwZmYgdmVjOjIxIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBt
YXBwZWQsIHVuYm91bmQKKFhFTikgICAgSVJROiAgMjggYWZmaW5pdHk6MDAwMDAwMDEgdmVjOmQw
IHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4t
bGlzdD0wOiAyOCgtLS0pLAooWEVOKSAgICBJUlE6ICA0MCBhZmZpbml0eTowMDAwMDAwMSB2ZWM6
ZDggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFp
bi1saXN0PTA6IDQwKC0tLSksCihYRU4pICAgIElSUTogIDQ4IGFmZmluaXR5OjAwMDAwMGZmIHZl
YzoyOCB0eXBlPURNQV9NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDAgaW9tbXVfcGFnZV9mYXVs
dCgpCihYRU4pIERpcmVjdCB2ZWN0b3IgaW5mb3JtYXRpb246CihYRU4pICAgIDB4MjAgLT4gaXJx
X21vdmVfY2xlYW51cF9pbnRlcnJ1cHQoKQooWEVOKSAgICAweGYyIC0+IGNtY2lfaW50ZXJydXB0
KCkKKFhFTikgICAgMHhmMyAtPiBpbnRlbF90aGVybWFsX2ludGVycnVwdCgpCihYRU4pICAgIDB4
ZjkgLT4gcG11X2FwaWNfaW50ZXJydXB0KCkKKFhFTikgICAgMHhmYSAtPiBhcGljX3RpbWVyX2lu
dGVycnVwdCgpCihYRU4pICAgIDB4ZmIgLT4gY2FsbF9mdW5jdGlvbl9pbnRlcnJ1cHQoKQooWEVO
KSAgICAweGZjIC0+IGV2ZW50X2NoZWNrX2ludGVycnVwdCgpCihYRU4pICAgIDB4ZmQgLT4gaW52
YWxpZGF0ZV9pbnRlcnJ1cHQoKQooWEVOKSAgICAweGZlIC0+IGVycm9yX2ludGVycnVwdCgpCihY
RU4pICAgIDB4ZmYgLT4gc3B1cmlvdXNfaW50ZXJydXB0KCkKKFhFTikgSU8tQVBJQyBpbnRlcnJ1
cHQgaW5mb3JtYXRpb246CihYRU4pICAgICBJUlEgIDAgVmVjMjQwOgooWEVOKSAgICAgICBBcGlj
IDB4MDAsIFBpbiAgMjogdmVjPWYwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xh
cml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgIDEgVmVj
IDQ4OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAgMTogdmVjPTMwIGRlbGl2ZXJ5PUxvUHJp
IGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTEgZGVzdF9pZDox
CihYRU4pICAgICBJUlEgIDMgVmVjIDU2OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAgMzog
dmVjPTM4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRy
aWc9RSBtYXNrPTEgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgIDQgVmVjMjQxOgooWEVOKSAgICAg
ICBBcGljIDB4MDAsIFBpbiAgNDogdmVjPWYxIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9
MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEg
IDUgVmVjIDY0OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAgNTogdmVjPTQwIGRlbGl2ZXJ5
PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVz
dF9pZDoxCihYRU4pICAgICBJUlEgIDYgVmVjIDcyOgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBp
biAgNjogdmVjPTQ4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGly
cj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgIDcgVmVjIDgwOgooWEVO
KSAgICAgICBBcGljIDB4MDAsIFBpbiAgNzogdmVjPTUwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBz
dGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAg
ICBJUlEgIDggVmVjIDg4OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAgODogdmVjPTU4IGRl
bGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNr
PTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgIDkgVmVjIDk2OgooWEVOKSAgICAgICBBcGljIDB4
MDAsIFBpbiAgOTogdmVjPTYwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0
eT0wIGlycj0wIHRyaWc9TCBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgMTAgVmVjMTA0
OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAxMDogdmVjPTY4IGRlbGl2ZXJ5PUxvUHJpIGRl
c3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihY
RU4pICAgICBJUlEgMTEgVmVjMTEyOgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAxMTogdmVj
PTcwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9
RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgMTIgVmVjMTIwOgooWEVOKSAgICAgICBB
cGljIDB4MDAsIFBpbiAxMjogdmVjPTc4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBw
b2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgMTMg
VmVjMTM2OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAxMzogdmVjPTg4IGRlbGl2ZXJ5PUxv
UHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9p
ZDoxCihYRU4pICAgICBJUlEgMTQgVmVjMTQ0OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAx
NDogdmVjPTkwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0w
IHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgMTUgVmVjMTUyOgooWEVOKSAg
ICAgICBBcGljIDB4MDAsIFBpbiAxNTogdmVjPTk4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0
dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJ
UlEgMTYgVmVjMTYwOgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAxNjogdmVjPWEwIGRlbGl2
ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTAg
ZGVzdF9pZDoxCihYRU4pICAgICBJUlEgMTcgVmVjMTY4OgooWEVOKSAgICAgICBBcGljIDB4MDAs
IFBpbiAxNzogdmVjPWE4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MSBwb2xhcml0eT0x
IGlycj0xIHRyaWc9TCBtYXNrPTAgZGVzdF9pZDo2NAooWEVOKSAgICAgSVJRIDE4IFZlYzE5MjoK
KFhFTikgICAgICAgQXBpYyAweDAwLCBQaW4gMTg6IHZlYz1jMCBkZWxpdmVyeT1Mb1ByaSBkZXN0
PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQooWEVO
KSAgICAgSVJRIDIwIFZlYzIwMDoKKFhFTikgICAgICAgQXBpYyAweDAwLCBQaW4gMjA6IHZlYz1j
OCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTEgcG9sYXJpdHk9MSBpcnI9MSB0cmlnPUwg
bWFzaz0wIGRlc3RfaWQ6NAooWEVOKSAgICAgSVJRIDIyIFZlYzE3NjoKKFhFTikgICAgICAgQXBp
YyAweDAwLCBQaW4gMjI6IHZlYz1iMCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9s
YXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MzIKKFhFTikgICAgIElSUSAyMyBW
ZWMxODQ6CihYRU4pICAgICAgIEFwaWMgMHgwMCwgUGluIDIzOiB2ZWM9YjggZGVsaXZlcnk9TG9Q
cmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lk
OjEKKFhFTikgICAgIElSUSAyNCBWZWMgMzM6CihYRU4pICAgICAgIEFwaWMgMHgwMSwgUGluICAw
OiB2ZWM9MjEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAg
dHJpZz1MIG1hc2s9MSBkZXN0X2lkOjI1NQooWEVOKSAgICAgSVJRIDI4IFZlYzIwODoKKFhFTikg
ICAgICAgQXBpYyAweDAxLCBQaW4gIDQ6IHZlYz1kMCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3Rh
dHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSAgICAg
SVJRIDQwIFZlYzIxNjoKKFhFTikgICAgICAgQXBpYyAweDAxLCBQaW4gMTY6IHZlYz1kOCBkZWxp
dmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0w
IGRlc3RfaWQ6MQooWEVOKSAnZScgcHJlc3NlZCAtPiBkdW1waW5nIGV2ZW50LWNoYW5uZWwgaW5m
bwooWEVOKSBFdmVudCBjaGFubmVsIGluZm9ybWF0aW9uIGZvciBkb21haW4gMDoKKFhFTikgUG9s
bGluZyB2Q1BVczoge30KKFhFTikgICAgIHBvcnQgW3AvbS9zXQooWEVOKSAgICAgICAgMSBbMC8w
LzBdOiBzPTUgbj0wIHg9MCB2PTIKKFhFTikgICAgICAgIDIgWzAvMC8wXTogcz01IG49MCB4PTAg
dj0wCihYRU4pICAgICAgICAzIFswLzAvMF06IHM9NSBuPTEgeD0wIHY9MAooWEVOKSAgICAgICAg
NCBbMC8wLzBdOiBzPTUgbj0yIHg9MCB2PTAKKFhFTikgICAgICAgIDUgWzAvMC8wXTogcz01IG49
MyB4PTAgdj0wCihYRU4pICAgICAgICA2IFswLzAvMF06IHM9NSBuPTQgeD0wIHY9MAooWEVOKSAg
ICAgICAgNyBbMC8wLzBdOiBzPTUgbj01IHg9MCB2PTAKKFhFTikgICAgICAgIDggWzAvMC8wXTog
cz01IG49NiB4PTAgdj0wCihYRU4pICAgICAgICA5IFswLzAvMF06IHM9NSBuPTcgeD0wIHY9MAoo
WEVOKSAgICAgICAxMCBbMC8wLzBdOiBzPTMgbj0xIHg9MCBkPTAgcD05MgooWEVOKSAgICAgICAx
MSBbMC8wLzBdOiBzPTQgbj0wIHg9MCBwPTkgaT05CihYRU4pICAgICAgIDEyIFswLzAvMF06IHM9
NCBuPTcgeD0wIHA9MjggaT0yOAooWEVOKSAgICAgICAxMyBbMC8wLzBdOiBzPTQgbj0wIHg9MCBw
PTQwIGk9NDAKKFhFTikgICAgICAgMTQgWzAvMC8wXTogcz00IG49MSB4PTAgcD0xNiBpPTE2CihY
RU4pICAgICAgIDE1IFswLzAvMF06IHM9NCBuPTIgeD0wIHA9MTcgaT0xNwooWEVOKSAgICAgICAx
NiBbMC8wLzBdOiBzPTQgbj01IHg9MCBwPTIyIGk9MjIKKFhFTikgICAgICAgMTcgWzAvMC8wXTog
cz00IG49NiB4PTAgcD0yMyBpPTIzCihYRU4pICAgICAgIDE4IFswLzAvMF06IHM9NCBuPTMgeD0w
IHA9MTggaT0xOAooWEVOKSAgICAgICAxOSBbMC8wLzBdOiBzPTQgbj00IHg9MCBwPTIwIGk9MjAK
KFhFTikgICAgICAgMjAgWzAvMC8wXTogcz02IG49MCB4PTAKKFhFTikgICAgICAgMjEgWzAvMC8w
XTogcz02IG49MCB4PTAKKFhFTikgICAgICAgMjIgWzAvMC8wXTogcz02IG49MCB4PTAKKFhFTikg
ICAgICAgMjMgWzAvMC8wXTogcz02IG49MCB4PTAKKFhFTikgICAgICAgMjQgWzAvMC8wXTogcz02
IG49MCB4PTAKKFhFTikgICAgICAgMjUgWzAvMC8wXTogcz02IG49MCB4PTAKKFhFTikgICAgICAg
MjYgWzAvMC8wXTogcz02IG49MCB4PTAKKFhFTikgICAgICAgMjcgWzAvMC8wXTogcz02IG49MCB4
PTAKKFhFTikgICAgICAgMjggWzAvMC8wXTogcz02IG49MCB4PTAKKFhFTikgICAgICAgMjkgWzAv
MC8wXTogcz02IG49MSB4PTAKKFhFTikgICAgICAgMzAgWzAvMC8wXTogcz02IG49MSB4PTAKKFhF
TikgICAgICAgMzEgWzAvMC8wXTogcz02IG49MSB4PTAKKFhFTikgICAgICAgMzIgWzAvMC8wXTog
cz02IG49MSB4PTAKKFhFTikgICAgICAgMzMgWzAvMC8wXTogcz02IG49MSB4PTAKKFhFTikgICAg
ICAgMzQgWzAvMC8wXTogcz02IG49MSB4PTAKKFhFTikgICAgICAgMzUgWzAvMC8wXTogcz02IG49
MSB4PTAKKFhFTikgICAgICAgMzYgWzAvMC8wXTogcz02IG49MSB4PTAKKFhFTikgICAgICAgMzcg
WzAvMC8wXTogcz02IG49MSB4PTAKKFhFTikgICAgICAgMzggWzAvMC8wXTogcz02IG49MiB4PTAK
KFhFTikgICAgICAgMzkgWzAvMC8wXTogcz02IG49MiB4PTAKKFhFTikgICAgICAgNDAgWzAvMC8w
XTogcz02IG49MiB4PTAKKFhFTikgICAgICAgNDEgWzAvMC8wXTogcz02IG49MiB4PTAKKFhFTikg
ICAgICAgNDIgWzAvMC8wXTogcz02IG49MiB4PTAKKFhFTikgICAgICAgNDMgWzAvMC8wXTogcz02
IG49MiB4PTAKKFhFTikgICAgICAgNDQgWzAvMC8wXTogcz02IG49MiB4PTAKKFhFTikgICAgICAg
NDUgWzAvMC8wXTogcz02IG49MiB4PTAKKFhFTikgICAgICAgNDYgWzAvMC8wXTogcz02IG49MiB4
PTAKKFhFTikgICAgICAgNDcgWzAvMC8wXTogcz02IG49MyB4PTAKKFhFTikgICAgICAgNDggWzAv
MC8wXTogcz02IG49MyB4PTAKKFhFTikgICAgICAgNDkgWzAvMC8wXTogcz02IG49MyB4PTAKKFhF
TikgICAgICAgNTAgWzAvMC8wXTogcz02IG49MyB4PTAKKFhFTikgICAgICAgNTEgWzAvMC8wXTog
cz02IG49MyB4PTAKKFhFTikgICAgICAgNTIgWzAvMC8wXTogcz02IG49MyB4PTAKKFhFTikgICAg
ICAgNTMgWzAvMC8wXTogcz02IG49MyB4PTAKKFhFTikgICAgICAgNTQgWzAvMC8wXTogcz02IG49
MyB4PTAKKFhFTikgICAgICAgNTUgWzAvMC8wXTogcz02IG49MyB4PTAKKFhFTikgICAgICAgNTYg
WzAvMC8wXTogcz02IG49NCB4PTAKKFhFTikgICAgICAgNTcgWzAvMC8wXTogcz02IG49NCB4PTAK
KFhFTikgICAgICAgNTggWzAvMC8wXTogcz02IG49NCB4PTAKKFhFTikgICAgICAgNTkgWzAvMC8w
XTogcz02IG49NCB4PTAKKFhFTikgICAgICAgNjAgWzAvMC8wXTogcz02IG49NCB4PTAKKFhFTikg
ICAgICAgNjEgWzAvMC8wXTogcz02IG49NCB4PTAKKFhFTikgICAgICAgNjIgWzAvMC8wXTogcz02
IG49NCB4PTAKKFhFTikgICAgICAgNjMgWzAvMC8wXTogcz02IG49NCB4PTAKKFhFTikgICAgICAg
NjQgWzAvMC8wXTogcz02IG49NCB4PTAKKFhFTikgICAgICAgNjUgWzAvMC8wXTogcz02IG49NSB4
PTAKKFhFTikgICAgICAgNjYgWzAvMC8wXTogcz02IG49NSB4PTAKKFhFTikgICAgICAgNjcgWzAv
MC8wXTogcz02IG49NSB4PTAKKFhFTikgICAgICAgNjggWzAvMC8wXTogcz02IG49NSB4PTAKKFhF
TikgICAgICAgNjkgWzAvMC8wXTogcz02IG49NSB4PTAKKFhFTikgICAgICAgNzAgWzAvMC8wXTog
cz02IG49NSB4PTAKKFhFTikgICAgICAgNzEgWzAvMC8wXTogcz02IG49NSB4PTAKKFhFTikgICAg
ICAgNzIgWzAvMC8wXTogcz02IG49NSB4PTAKKFhFTikgICAgICAgNzMgWzAvMC8wXTogcz02IG49
NSB4PTAKKFhFTikgICAgICAgNzQgWzAvMC8wXTogcz02IG49NiB4PTAKKFhFTikgICAgICAgNzUg
WzAvMC8wXTogcz02IG49NiB4PTAKKFhFTikgICAgICAgNzYgWzAvMC8wXTogcz02IG49NiB4PTAK
KFhFTikgICAgICAgNzcgWzAvMC8wXTogcz02IG49NiB4PTAKKFhFTikgICAgICAgNzggWzAvMC8w
XTogcz02IG49NiB4PTAKKFhFTikgICAgICAgNzkgWzAvMC8wXTogcz02IG49NiB4PTAKKFhFTikg
ICAgICAgODAgWzAvMC8wXTogcz02IG49NiB4PTAKKFhFTikgICAgICAgODEgWzAvMC8wXTogcz02
IG49NiB4PTAKKFhFTikgICAgICAgODIgWzAvMC8wXTogcz02IG49NiB4PTAKKFhFTikgICAgICAg
ODMgWzAvMC8wXTogcz02IG49NyB4PTAKKFhFTikgICAgICAgODQgWzAvMC8wXTogcz02IG49NyB4
PTAKKFhFTikgICAgICAgODUgWzAvMC8wXTogcz02IG49NyB4PTAKKFhFTikgICAgICAgODYgWzAv
MC8wXTogcz02IG49NyB4PTAKKFhFTikgICAgICAgODcgWzAvMC8wXTogcz02IG49NyB4PTAKKFhF
TikgICAgICAgODggWzAvMC8wXTogcz02IG49NyB4PTAKKFhFTikgICAgICAgODkgWzAvMC8wXTog
cz02IG49NyB4PTAKKFhFTikgICAgICAgOTAgWzAvMC8wXTogcz02IG49NyB4PTAKKFhFTikgICAg
ICAgOTEgWzAvMC8wXTogcz02IG49NyB4PTAKKFhFTikgICAgICAgOTIgWzAvMC8wXTogcz0zIG49
MiB4PTAgZD0wIHA9MTAKKFhFTikgICAgICAgOTMgWzAvMC8wXTogcz01IG49MCB4PTAgdj0zCihY
RU4pIG51bWJlciBvZiBNUCBJUlEgc291cmNlczogMTUuCihYRU4pIG51bWJlciBvZiBJTy1BUElD
ICM4IHJlZ2lzdGVyczogMjQuCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM5IHJlZ2lzdGVyczog
MjQuCihYRU4pIHRlc3RpbmcgdGhlIElPIEFQSUMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLgooWEVO
KSBJTyBBUElDICM4Li4uLi4uCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAwMDAwMDAwMAooWEVO
KSAuLi4uLi4uICAgIDogcGh5c2ljYWwgQVBJQyBpZDogMDAKKFhFTikgLi4uLi4uLiAgICA6IERl
bGl2ZXJ5IFR5cGU6IDAKKFhFTikgLi4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDAKKFhFTikg
Li4uLiByZWdpc3RlciAjMDE6IDAwMTcwMDIwCihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGly
ZWN0aW9uIGVudHJpZXM6IDAwMTcKKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6
IDAKKFhFTikgLi4uLi4uLiAgICAgOiBJTyBBUElDIHZlcnNpb246IDAwMjAKKFhFTikgLi4uLiBJ
UlEgcmVkaXJlY3Rpb24gdGFibGU6CihYRU4pICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9s
IFN0YXQgRGVzdCBEZWxpIFZlY3Q6CihYRU4pICAwMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwMSAwMDEgMDEgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMSAgICAxICAgIDMwCihYRU4pICAwMiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAg
MSAgICAxICAgIEYwCihYRU4pICAwMyAwMDEgMDEgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMSAg
ICAxICAgIDM4CihYRU4pICAwNCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIEYxCihYRU4pICAwNSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDQwCihYRU4pICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4
CihYRU4pICAwNyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDUwCihY
RU4pICAwOCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4CihYRU4p
ICAwOSAwMDEgMDEgIDAgICAgMSAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDYwCihYRU4pICAw
YSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDY4CihYRU4pICAwYiAw
MDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwCihYRU4pICAwYyAwMDEg
MDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4CihYRU4pICAwZCAwMDEgMDEg
IDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDg4CihYRU4pICAwZSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwCihYRU4pICAwZiAwMDEgMDEgIDAgICAg
MCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDk4CihYRU4pICAxMCAwMDEgMDEgIDAgICAgMSAg
ICAwICAgMSAgIDAgICAgMSAgICAxICAgIEEwCihYRU4pICAxMSAwNDAgMDAgIDAgICAgMSAgICAx
ICAgMSAgIDEgICAgMSAgICAxICAgIEE4CihYRU4pICAxMiAwMDEgMDEgIDAgICAgMSAgICAwICAg
MSAgIDAgICAgMSAgICAxICAgIEMwCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwCihYRU4pICAxNCAwMDQgMDQgIDAgICAgMSAgICAxICAgMSAgIDEg
ICAgMSAgICAxICAgIEM4CihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwCihYRU4pICAxNiAwMjAgMDAgIDAgICAgMSAgICAwICAgMSAgIDAgICAgMSAg
ICAxICAgIEIwCihYRU4pICAxNyAwMDEgMDEgIDAgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAx
ICAgIEI4CihYRU4pIElPIEFQSUMgIzkuLi4uLi4KKFhFTikgLi4uLiByZWdpc3RlciAjMDA6IDAw
MDAwMDAwCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwMAooWEVOKSAuLi4u
Li4uICAgIDogRGVsaXZlcnkgVHlwZTogMAooWEVOKSAuLi4uLi4uICAgIDogTFRTICAgICAgICAg
IDogMAooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzAwMjAKKFhFTikgLi4uLi4uLiAgICAg
OiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNwooWEVOKSAuLi4uLi4uICAgICA6IFBSUSBp
bXBsZW1lbnRlZDogMAooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMAoo
WEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDAwMDAwMDAKKFhFTikgLi4uLi4uLiAgICAgOiBhcmJp
dHJhdGlvbjogMDAKKFhFTikgLi4uLiByZWdpc3RlciAjMDM6IDAwMDAwMDAxCihYRU4pIC4uLi4u
Li4gICAgIDogQm9vdCBEVCAgICA6IDEKKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6
CihYRU4pICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6
CihYRU4pICAwMCAwRkYgMEYgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDIxCihY
RU4pICAwMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4p
ICAwMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwNCAw
MDEgMDEgIDAgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIEQwCihYRU4pICAwNSAwMDAg
MDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwNiAwMDAgMDAg
IDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwNyAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwOCAwMDAgMDAgIDEgICAg
MCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwOSAwMDAgMDAgIDEgICAgMCAg
ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwYSAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwCihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwCihYRU4pICAwZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwCihYRU4pICAxMCAwMDEgMDEgIDAgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAx
ICAgIEQ4CihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
CihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihY
RU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4p
ICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAxNyAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pIFVzaW5nIHZl
Y3Rvci1iYXNlZCBpbmRleGluZwooWEVOKSBJUlEgdG8gcGluIG1hcHBpbmdzOgooWEVOKSBJUlEy
NDAgLT4gMDoyCihYRU4pIElSUTQ4IC0+IDA6MQooWEVOKSBJUlE1NiAtPiAwOjMKKFhFTikgSVJR
MjQxIC0+IDA6NAooWEVOKSBJUlE2NCAtPiAwOjUKKFhFTikgSVJRNzIgLT4gMDo2CihYRU4pIElS
UTgwIC0+IDA6NwooWEVOKSBJUlE4OCAtPiAwOjgKKFhFTikgSVJROTYgLT4gMDo5CihYRU4pIElS
UTEwNCAtPiAwOjEwCihYRU4pIElSUTExMiAtPiAwOjExCihYRU4pIElSUTEyMCAtPiAwOjEyCihY
RU4pIElSUTEzNiAtPiAwOjEzCihYRU4pIElSUTE0NCAtPiAwOjE0CihYRU4pIElSUTE1MiAtPiAw
OjE1CihYRU4pIElSUTE2MCAtPiAwOjE2CihYRU4pIElSUTE2OCAtPiAwOjE3CihYRU4pIElSUTE5
MiAtPiAwOjE4CihYRU4pIElSUTIwMCAtPiAwOjIwCihYRU4pIElSUTE3NiAtPiAwOjIyCihYRU4p
IElSUTE4NCAtPiAwOjIzCihYRU4pIElSUTMzIC0+IDE6MAooWEVOKSBJUlEyMDggLT4gMTo0CihY
RU4pIElSUTIxNiAtPiAxOjE2CihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLiBkb25lLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Dec 17 11:40:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 11:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Cxh-00033L-2x; Wed, 17 Dec 2014 11:40:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Y1Cxf-00033G-QH
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 11:40:12 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	04/08-02576-B9B61945; Wed, 17 Dec 2014 11:40:11 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418816408!15665476!1
X-Originating-IP: [66.165.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 2636 invoked from network); 17 Dec 2014 11:40:09 -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;
	17 Dec 2014 11:40:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205758065"
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.210.2;
	Wed, 17 Dec 2014 06:40:06 -0500
Message-ID: <54916B95.3000609@citrix.com>
Date: Wed, 17 Dec 2014 12:40:05 +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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel
	<xen-devel@lists.xenproject.org>
References: <54906D3D.2060807@citrix.com> <549072FE.40500@citrix.com>
In-Reply-To: <549072FE.40500@citrix.com>
Content-Length:120696
X-DLP: MIA1
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] IO-APIC interrupts getting stuck
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RWwgMTYvMTIvMTQgYSBsZXMgMTguNTksIEFuZHJldyBDb29wZXIgaGEgZXNjcml0Ogo+IE9uIDE2
LzEyLzE0IDE3OjM0LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiBIZWxsbywKPj4KPj4gV2hp
bGUgd29ya2luZyBvbiB0aGUgRnJlZUJTRCBQVkggRG9tMCBwb3J0IEkndmUgcmVhbGl6ZWQgdGhh
dCBJTy1BUElDIAo+PiBpbnRlcnJ1cHRzIGdldCBzdHVjayBpbiBhIHZlcnkgc3RyYW5nZSBzdGF0
ZSB2ZXJ5IGVhc2lseSB3aXRoIHRoZSAKPj4gY3VycmVudCBQSVJRIGltcGxlbWVudGF0aW9uIHRo
YXQgSSdtIHVzaW5nIG9uIEZyZWVCU0QuCj4+Cj4+IFNpbmNlIEknbSBub3Qgc3VyZSB3aGF0IGlz
IGdvaW5nIG9uLCBJIHdvdWxkIGxpa2UgdG8gYXNrIGZvciBzb21lIAo+PiBmZWVkYmFjayBhbmQg
cG9zc2libGUgc29sdXRpb25zLCBiZWNhdXNlIGF0IHRoaXMgcG9pbnQgSSdtIHJ1bm5pbmcgb3V0
IAo+PiBvZiBpZGVhcyBvZiB3aGF0J3MgaGFwcGVuaW5nLgo+Pgo+PiBJbiB0aGlzIGNhc2UgSSdt
IGdvaW5nIHRvIHVzZSBJUlEgMTcgYXMgYW4gZXhhbXBsZSwgd2hpY2ggaXMgc2hhcmVkIAo+PiBi
ZXR3ZWVuIGFuIEludGVsKFIpIFBSTy8xMDAwIG5pYywgYSBCcm9hZGNvbSBOZXRYdHJlbWUgR2ln
YWJpdCBuaWMgYW5kIAo+PiBhbiBJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIu
Cj4+Cj4+IFVzdWFsbHkgZHVyaW5nIHRoZSBib290IHByb2Nlc3MsIG9yIHZlcnkgc2hvcnRseSBh
ZnRlciBpdCwgRG9tMCBsb29zZXMgCj4+IGludGVycnVwdHMgZnJvbSBJUlEgMTcsIGR1bXBpbmcg
SVJRIGluZm9ybWF0aW9uIGZyb20gWGVuICgnaScga2V5KSwgCj4+IGdpdmVzIHRoZSBmb2xsb3dp
bmcgb3V0cHV0Ogo+Pgo+PiAoWEVOKSAgICBJUlE6ICAxNyBhZmZpbml0eTowMDAwMDAwMSB2ZWM6
YTggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFp
bi1saXN0PTA6IDE3KC0tLSksCj4+IC4uLgo+PiAoWEVOKSAgICAgSVJRIDE3IFZlYzE2ODoKPj4g
KFhFTikgICAgICAgQXBpYyAweDAwLCBQaW4gMTc6IHZlYz1hOCBkZWxpdmVyeT1Mb1ByaSBkZXN0
PUwgc3RhdHVzPTEgcG9sYXJpdHk9MSBpcnI9MSB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQo+Pgo+
PiBJJ3ZlIGFsc28gYWRkZWQgc29tZSBldmVudCBjaGFubmVsIGRlYnVnIGZ1bmN0aW9ucyB0byB0
aGUgRnJlZUJTRCAKPj4gaW4ta2VybmVsIGRlYnVnZ2VyIGluIG9yZGVyIHRvIHByaW50IHRoZSBz
dGF0dXMgb2YgZXZlbnQgY2hhbm5lbHM6Cj4+Cj4+IFBvcnQgMTUgVHlwZTogUElSUQo+PiAgICAg
ICAgIFBpcnE6IDE3IEFjdGl2ZUhpOiAwIEVkZ2VUcmlnZ2VyOiAwIE5lZWRzRU9JOiAxCj4+ICAg
ICAgICAgTWFza2VkOiAwIFBlbmRpbmc6IDAKPj4gICAgICAgICBQZXItQ1BVIE1hc2tzOiBjcHUj
MDogMCBjcHUjMTogMCBjcHUjMjogMSBjcHUjMzogMCBjcHUjNDogMCBjcHUjNTogMCBjcHUjNjog
MCBjcHUjNzogMAo+Pgo+PiBBbmQgdGhlIGNvcnJlc3BvbmRpbmcgbGluZSBmcm9tIHRoZSBYZW4g
J2UnIGRlYnVnIGtleToKPj4KPj4gKFhFTikgICAgICAgMTUgWzAvMC8xXTogcz00IG49MiB4PTAg
cD0xNyBpPTE3Cj4+Cj4+IFRoaXMgbWFrZXMgbWUgdGhpbmcgdGhhdCB0aGUgRnJlZUJTRCBrZXJu
ZWwgaXMgZmFpbGluZyB0byBFT0kgdGhlIAo+PiB2ZWN0b3IgKGJlY2F1c2Ugb2YgdGhlIGlycj0x
IGluIHRoZSBYZW4gSVJRIGRlYnVnIGluZm8pLCBzbyBJJ3ZlIGFsc28gCj4+IGFkZGVkIGEgZnVu
Y3Rpb24gdG8gdGhlIGRlYnVnZ2VyIHRoYXQgYWxsb3dzIG1lIHRvIEVPSSBhIHZlY3RvciBmcm9t
IAo+PiBpdC4gQnV0IGV2ZW4gYWZ0ZXIgaXNzdWluZyBhIFBIWVNERVZPUF9lb2kgaHlwZXJjYWxs
IG9uIHRoZSBhZmZlY3RlZCAKPj4gUElSUSAoMTcpLCB0aGUgc3RhdHVzIGlzIGV4YWN0bHkgdGhl
IHNhbWUsIGJlY2F1c2UgcGlycS0+bWFza2VkID09IDAsIAo+PiBzbyBkZXNjX2d1ZXN0X2VvaSBm
YWlscyB0byBFT0kgdGhlIHZlY3RvciAoc2VlIHhlbi9hcmNoL3g4Ni9pcnEuYzoxNDMzKS4KPj4K
Pj4gU28gbm93IEknbSB3b25kZXJpbmcsIGhvdyBjYW4gSSAidW5zdHVjayIgdGhpcyBJUlEsIGFu
ZCBob3cgZGlkIGl0IGdldCAKPj4gaW50byB0aGlzIHN0cmFuZ2Ugc3RhdGU/Cj4+Cj4+IFJvZ2Vy
Lgo+IAo+IERvIHlvdSBoYXZlIGEgeGVuIGRtZXNnIHdpdGggZnVsbCBkZWJ1Z2dpbmc/ICBBY2Nv
cmRpbmcgdG8gdGhlIGZpcnN0Cj4gbGluZSBmcm9tICdpJywgWGVuIGJlbGlldmVzIHRoYXQgdGhl
IGlycSBpbiBxdWVzdGlvbiBpcyBub3QgaW4gbmVlZCBvZgo+IGFuIEVPSSwgd2hpY2ggaXMgY2xl
YXJseSBjb250cmFyeSB0byB0aGUgSU9BUElDcyB2aWV3IG9mIHRoZSB3b3JsZC4KPiAKPiBTb21l
IHJhbmRvbSBzdWdnZXN0aW9uczogZG9lcyBhbHRlcmluZyBpbnRlcnJ1cHQgcmVtYXBwaW5nIG1h
a2UgYQo+IGRpZmZlcmVuY2U/IGRvZXMgYWx0ZXJpbmcgdGhlIGlvYXBpY19hY2tfbW9kZSBtYWtl
IGEgZGlmZmVyZW5jZT8KCkkgaGF2ZW4ndCBiZWVuIGFibGUgdG8gZ2V0IGludG8gdGhpcyBzdHVj
ayBzdGF0ZSB3aXRoIGlvYXBpY19hY2s9b2xkLCAKYnV0IEkgaGF2ZSBhbm90aGVyIGJveCB3aXRo
IHRoZSBzYW1lIGhhcmR3YXJlIHJ1bm5pbmcgYSBMaW51eCBQVkggRG9tMCAKd2l0aCBpb2FwaWNf
YWNrPW5ldyB3aGljaCBkb2Vzbid0IGV4aGliaXQgdGhpcyBpc3N1ZSBBRkFJQ1QuIFNvIGl0J3Mg
CmVpdGhlciBhIHByb2JsZW0gaW4gdGhlIFBJUlEgaW1wbGVtZW50YXRpb24gb24gRnJlZUJTRCwg
b3Igc29tZSBxdWljayAKb24gdGhlIGhhcmR3YXJlIHRoYXQncyB0cmlnZ2VyZWQgYnkgdGhlIGlt
cGxlbWVudGF0aW9uIGluIEZyZWVCU0QuCgpIZXJlIGlzIHRoZSBmdWxsIGRtZXNnOgoKT0sgc2V0
IGh3LnBjaS5lbmFibGVfbXNpeD0wCk9LIHNldCBody5wY2kuZW5hYmxlX21zaT0wCk9LIGJvb3QK
Qm9vdGluZy4uLgogWGVuIDQuNS4wLXJjCihYRU4pIFhlbiB2ZXJzaW9uIDQuNS4wLXJjIChyb290
QCkgKGdjYzQ3IChGcmVlQlNEIFBvcnRzIENvbGxlY3Rpb24pIDQuNy40KSBkZWJ1Zz15IFRodSBE
ZWMgMTEgMTE6NTg6NDIgVVRDIDIwMTQKKFhFTikgTGF0ZXN0IENoYW5nZVNldDogVGh1IERlYyAx
MSAxMjo1MDo1NSAyMDE0ICswMTAwIGdpdDo0YTZjOTM1CihYRU4pIEJvb3Rsb2FkZXI6IHVua25v
d24KKFhFTikgQ29tbWFuZCBsaW5lOiBkb20wX21lbT0yMDQ4TSBpb21tdT1kZWJ1Zyxuby1pbnRy
ZW1hcCBkb20wX21heF92Y3B1cz04IGRvbTBwdmg9MSBndWVzdF9sb2dsdmw9YWxsIGxvZ2x2bD1h
bGwgY29uc29sZT1jb20xIG5taT1kb20wCihYRU4pIFZpZGVvIGluZm9ybWF0aW9uOgooWEVOKSAg
VkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9udCA4eDE2CihYRU4pICBWQkUvRERDIG1ldGhvZHM6
IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDEgc2Vjb25kcwooWEVOKSAgRURJRCBpbmZvIG5vdCBy
ZXRyaWV2ZWQgYmVjYXVzZSBvZiByZWFzb25zIHVua25vd24KKFhFTikgRGlzYyBpbmZvcm1hdGlv
bjoKKFhFTikgIEZvdW5kIDEgTUJSIHNpZ25hdHVyZXMKKFhFTikgIEZvdW5kIDIgRUREIGluZm9y
bWF0aW9uIHN0cnVjdHVyZXMKKFhFTikgWGVuLWU4MjAgUkFNIG1hcDoKKFhFTikgIDAwMDAwMDAw
MDAwMDAwMDAgLSAwMDAwMDAwMDAwMDkyODAwICh1c2FibGUpCihYRU4pICAwMDAwMDAwMDAwMGYw
MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDAwMTAwMDAw
IC0gMDAwMDAwMDBkZmRmOWMwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDBkZmRmOWMwMCAtIDAw
MDAwMDAwZGZlNGJjMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAwMDAwMDBkZmU0YmMwMCAtIDAwMDAw
MDAwZGZlNGRjMDAgKEFDUEkgZGF0YSkKKFhFTikgIDAwMDAwMDAwZGZlNGRjMDAgLSAwMDAwMDAw
MGUwMDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZjgwMDAwMDAgLSAwMDAwMDAwMGZk
MDAwMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmUwMDAwMDAgLSAwMDAwMDAwMGZlZDAw
NDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZjAwMDAw
IChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmZiMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChy
ZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMWEwMDAwMDAwICh1c2Fi
bGUpCihYRU4pIEFDUEk6IFJTRFAgMDAwRkVDMzAsIDAwMjQgKHIyIERFTEwgICkKKFhFTikgQUNQ
STogWFNEVCAwMDBGQ0NDNywgMDA3QyAocjEgREVMTCAgICBCMTBLICAgICAgICAgIDE1IEFTTCAg
ICAgICAgNjEpCihYRU4pIEFDUEk6IEZBQ1AgMDAwRkNEQjcsIDAwRjQgKHIzIERFTEwgICAgQjEw
SyAgICAgICAgICAxNSBBU0wgICAgICAgIDYxKQooWEVOKSBBQ1BJOiBEU0RUIEZGRTlFOTUxLCA0
QTc0IChyMSAgIERFTEwgICAgZHRfZXggICAgIDEwMDAgSU5UTCAyMDA1MDYyNCkKKFhFTikgQUNQ
STogRkFDUyBERkRGOUMwMCwgMDA0MAooWEVOKSBBQ1BJOiBTU0RUIEZGRUEzNEQ2LCAwMDlDIChy
MSAgIERFTEwgICAgc3RfZXggICAgIDEwMDAgSU5UTCAyMDA1MDYyNCkKKFhFTikgQUNQSTogQVBJ
QyAwMDBGQ0VBQiwgMDE1RSAocjEgREVMTCAgICBCMTBLICAgICAgICAgIDE1IEFTTCAgICAgICAg
NjEpCihYRU4pIEFDUEk6IEJPT1QgMDAwRkQwMDksIDAwMjggKHIxIERFTEwgICAgQjEwSyAgICAg
ICAgICAxNSBBU0wgICAgICAgIDYxKQooWEVOKSBBQ1BJOiBBU0YhIDAwMEZEMDMxLCAwMDk2IChy
MzIgREVMTCAgICBCMTBLICAgICAgICAgIDE1IEFTTCAgICAgICAgNjEpCihYRU4pIEFDUEk6IE1D
RkcgMDAwRkQwQzcsIDAwM0MgKHIxIERFTEwgICAgQjEwSyAgICAgICAgICAxNSBBU0wgICAgICAg
IDYxKQooWEVOKSBBQ1BJOiBIUEVUIDAwMEZEMTAzLCAwMDM4IChyMSBERUxMICAgIEIxMEsgICAg
ICAgICAgMTUgQVNMICAgICAgICA2MSkKKFhFTikgQUNQSTogVENQQSAwMDBGRDM1RiwgMDAzMiAo
cjEgREVMTCAgICBCMTBLICAgICAgICAgIDE1IEFTTCAgICAgICAgNjEpCihYRU4pIEFDUEk6IERN
QVIgMDAwRkQzOTEsIDAwQzggKHIxIERFTEwgICAgQjEwSyAgICAgICAgICAxNSBBU0wgICAgICAg
IDYxKQooWEVOKSBBQ1BJOiBTTElDIDAwMEZEMTNCLCAwMTc2IChyMSBERUxMICAgIEIxMEsgICAg
ICAgICAgMTUgQVNMICAgICAgICA2MSkKKFhFTikgQUNQSTogU1NEVCBERkU0REMwMCwgMTVDNCAo
cjEgIElOVEVMIFBQTSBSQ00gIDgwMDAwMDAxIElOVEwgMjAwNjExMDkpCihYRU4pIFN5c3RlbSBS
QU06IDYxNDFNQiAoNjI4ODk0MGtCKQooWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQK
KFhFTikgRmFraW5nIGEgbm9kZSBhdCAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAxYTAwMDAwMDAK
KFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQKKFhFTikgRE1JIDIuNSBwcmVzZW50LgooWEVO
KSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0CihYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6
IDB4ODA4CihYRU4pIEFDUEk6IFNMRUVQIElORk86IHBtMXhfY250WzE6ODA0LDE6MF0sIHBtMXhf
ZXZ0WzE6ODAwLDE6MF0KKFhFTikgQUNQSTogICAgICAgICAgICAgd2FrZXVwX3ZlY1tkZmRmOWMw
Y10sIHZlY19zaXplWzIwXQooWEVOKSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAw
MAooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVk
KQooWEVOKSBQcm9jZXNzb3IgIzAgNzoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29y
ICMyIDc6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNd
IGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjNCA3OjEwIEFQSUMgdmVy
c2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDA2XSBl
bmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzYgNzoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkKKFhFTikgUHJv
Y2Vzc29yICMxIDc6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MDZdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjMyA3OjEwIEFQ
SUMgdmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA3XSBsYXBpY19pZFsw
eDA1XSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzUgNzoxMCBBUElDIHZlcnNpb24gMjEKKFhF
TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOF0gbGFwaWNfaWRbMHgwN10gZW5hYmxlZCkKKFhF
TikgUHJvY2Vzc29yICM3IDc6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4MDldIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDBhXSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwYl0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4pIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4MGNdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDBkXSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwZV0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4pIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MGZdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDEwXSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgxMV0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4pIEFDUEk6
IExBUElDIChhY3BpX2lkWzB4MTJdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDEzXSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgxNF0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4pIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MTVdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBB
Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDE2XSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikg
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxN10gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4p
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MThdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDE5XSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhF
TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxYV0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihY
RU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MWJdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQoo
WEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDFjXSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkK
KFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxZF0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQp
CihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MWVdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVk
KQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDFmXSBsYXBpY19pZFsweDAwXSBkaXNhYmxl
ZCkKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgyMF0gbGFwaWNfaWRbMHgwMF0gZGlzYWJs
ZWQpCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweGZmXSBoaWdoIGxldmVsIGxpbnRb
MHgxXSkKKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA4XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdz
aV9iYXNlWzBdKQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgOCwgdmVyc2lvbiAzMiwgYWRkcmVz
cyAweGZlYzAwMDAwLCBHU0kgMC0yMwooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDldIGFkZHJl
c3NbMHhmZWM4MDAwMF0gZ3NpX2Jhc2VbMjRdKQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgOSwg
dmVyc2lvbiAzMiwgYWRkcmVzcyAweGZlYzgwMDAwLCBHU0kgMjQtNDcKKFhFTikgQUNQSTogSU5U
X1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKKFhFTikgQUNQ
STogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBsZXZlbCkK
KFhFTikgQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBBQ1BJOiBJUlEyIHVzZWQg
Ynkgb3ZlcnJpZGUuCihYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KKFhFTikgRW5h
YmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDIgSS9PIEFQSUNzCihYRU4pIEFDUEk6IEhQ
RVQgaWQ6IDB4ODA4NmEzMDEgYmFzZTogMHhmZWQwMDAwMAooWEVOKSBbVlQtRF1kbWFyLmM6Nzg4
OiBIb3N0IGFkZHJlc3Mgd2lkdGggMzYKKFhFTikgW1ZULURdZG1hci5jOjgwMjogZm91bmQgQUNQ
SV9ETUFSX0RSSEQ6CihYRU4pIFtWVC1EXWRtYXIuYzo0NzI6ICAgZG1hcnUtPmFkZHJlc3MgPSBm
ZWRjMDAwMAooWEVOKSBbVlQtRF1pb21tdS5jOjExNDY6IGRyaGQtPmFkZHJlc3MgPSBmZWRjMDAw
MCBpb21tdS0+cmVnID0gZmZmZjgyYzAwMDIwMTAwMAooWEVOKSBbVlQtRF1pb21tdS5jOjExNDg6
IGNhcCA9IGM5MDc4MDEwNmYwNDYyIGVjYXAgPSBmMDIwZmUKKFhFTikgW1ZULURdZG1hci5jOjM5
NzogIElPQVBJQzogMDAwMDowMDoxMy4wCihYRU4pIFtWVC1EXWRtYXIuYzozOTc6ICBJT0FQSUM6
IDAwMDA6MDA6MWYuNwooWEVOKSBbVlQtRF1kbWFyLmM6NDg2OiAgIGZsYWdzOiBJTkNMVURFX0FM
TAooWEVOKSBbVlQtRF1kbWFyLmM6ODA3OiBmb3VuZCBBQ1BJX0RNQVJfUk1SUjoKKFhFTikgW1ZU
LURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFkLjAKKFhFTikgW1ZULURdZG1hci5j
OjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFkLjEKKFhFTikgW1ZULURdZG1hci5jOjM4MzogIGVu
ZHBvaW50OiAwMDAwOjAwOjFkLjIKKFhFTikgW1ZULURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAw
MDAwOjAwOjFkLjcKKFhFTikgW1ZULURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFh
LjAKKFhFTikgW1ZULURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFhLjEKKFhFTikg
W1ZULURdZG1hci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFhLjIKKFhFTikgW1ZULURdZG1h
ci5jOjM4MzogIGVuZHBvaW50OiAwMDAwOjAwOjFhLjcKKFhFTikgW1ZULURdZG1hci5jOjY3Njog
ICBSTVJSIHJlZ2lvbjogYmFzZV9hZGRyIGRmZTU4MDAwIGVuZF9hZGRyZXNzIGRmZTZmZmZmCihY
RU4pIFtWVC1EXWRtYXIuYzo4MTI6IGZvdW5kIEFDUElfRE1BUl9BVFNSOgooWEVOKSBbVlQtRF1k
bWFyLmM6NzA1OiAgIGF0c3J1LT5hbGxfcG9ydHM6IDAKKFhFTikgW1ZULURdZG1hci5jOjM1Mzog
IGJyaWRnZTogMDAwMDowMDowMS4wIHN0YXJ0PTAgc2VjPTEgc3ViPTEKKFhFTikgW1ZULURdZG1h
ci5jOjM1MzogIGJyaWRnZTogMDAwMDowMDowMy4wIHN0YXJ0PTAgc2VjPTIgc3ViPTIKKFhFTikg
W1ZULURdZG1hci5jOjM1MzogIGJyaWRnZTogMDAwMDowMDowNy4wIHN0YXJ0PTAgc2VjPTMgc3Vi
PTMKKFhFTikgRVJTVCB0YWJsZSB3YXMgbm90IGZvdW5kCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQp
IGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgooWEVOKSBTTVA6IEFsbG93aW5nIDMy
IENQVXMgKDI0IGhvdHBsdWcgQ1BVcykKKFhFTikgSVJRIGxpbWl0czogNDggR1NJLCAxNTA0IE1T
SS9NU0ktWAooWEVOKSBVc2luZyBzY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVk
aXQpCihYRU4pIERldGVjdGVkIDMwNjYuODg1IE1IeiBwcm9jZXNzb3IuCihYRU4pIEluaXRpbmcg
bWVtb3J5IHNoYXJpbmcuCihYRU4pIG1jZV9pbnRlbC5jOjcxOTogTUNBIENhcGFiaWxpdHk6IEJD
QVNUIDEgU0VSIDAgQ01DSSAxIGZpcnN0YmFuayAwIGV4dGVuZGVkIE1DRSBNU1IgMAooWEVOKSBJ
bnRlbCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkCihYRU4pIGFsdCB0YWJsZSBmZmZm
ODJkMDgwMmQ5ZTEwIC0+IGZmZmY4MmQwODAyZGFlMzAKKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3Vy
YXRpb24gMDogYmFzZSBmODAwMDAwMCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSAzZgooWEVOKSBQ
Q0k6IE1DRkcgYXJlYSBhdCBmODAwMDAwMCByZXNlcnZlZCBpbiBFODIwCihYRU4pIFBDSTogVXNp
bmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAwMC0zZgooWEVOKSBJbnRlbCBWVC1kIGlvbW11
IDAgc3VwcG9ydGVkIHBhZ2Ugc2l6ZXM6IDRrQi4KKFhFTikgSW50ZWwgVlQtZCBTbm9vcCBDb250
cm9sIGVuYWJsZWQuCihYRU4pIEludGVsIFZULWQgRG9tMCBETUEgUGFzc3Rocm91Z2ggbm90IGVu
YWJsZWQuCihYRU4pIEludGVsIFZULWQgUXVldWVkIEludmFsaWRhdGlvbiBlbmFibGVkLgooWEVO
KSBJbnRlbCBWVC1kIEludGVycnVwdCBSZW1hcHBpbmcgbm90IGVuYWJsZWQuCihYRU4pIEludGVs
IFZULWQgU2hhcmVkIEVQVCB0YWJsZXMgbm90IGVuYWJsZWQuCihYRU4pIEkvTyB2aXJ0dWFsaXNh
dGlvbiBlbmFibGVkCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZAooWEVOKSBJbnRlcnJ1cHQg
cmVtYXBwaW5nIGRpc2FibGVkCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcwooWEVOKSAgLT4g
VXNpbmcgbmV3IEFDSyBtZXRob2QKKFhFTikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBw
aW4xPTIgYXBpYzI9LTEgcGluMj0tMQooWEVOKSBQbGF0Zm9ybSB0aW1lciBpcyAxNC4zMThNSHog
SFBFVAooWEVOKSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4KKFhFTikgbXdhaXQt
aWRsZTogTVdBSVQgc3Vic3RhdGVzOiAweDExMjAKKFhFTikgbXdhaXQtaWRsZTogdjAuNCBtb2Rl
bCAweDFhCihYRU4pIG13YWl0LWlkbGU6IGxhcGljX3RpbWVyX3JlbGlhYmxlX3N0YXRlcyAweDIK
KFhFTikgSFBFVDogMCB0aW1lcnMgdXNhYmxlIGZvciBicm9hZGNhc3QgKDQgdG90YWwpCihYRU4p
IFZNWDogU3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOgooWEVOKSAgLSBBUElDIE1NSU8gYWNj
ZXNzIHZpcnR1YWxpc2F0aW9uCihYRU4pICAtIEFQSUMgVFBSIHNoYWRvdwooWEVOKSAgLSBFeHRl
bmRlZCBQYWdlIFRhYmxlcyAoRVBUKQooWEVOKSAgLSBWaXJ0dWFsLVByb2Nlc3NvciBJZGVudGlm
aWVycyAoVlBJRCkKKFhFTikgIC0gVmlydHVhbCBOTUkKKFhFTikgIC0gTVNSIGRpcmVjdC1hY2Nl
c3MgYml0bWFwCihYRU4pIEhWTTogQVNJRHMgZW5hYmxlZC4KKFhFTikgSFZNOiBWTVggZW5hYmxl
ZAooWEVOKSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyAoSEFQKSBkZXRlY3RlZAooWEVO
KSBIVk06IEhBUCBwYWdlIHNpemVzOiA0a0IsIDJNQgooWEVOKSBCcm91Z2h0IHVwIDggQ1BVcwoo
WEVOKSBBQ1BJIHNsZWVwIG1vZGVzOiBTMwooWEVOKSBtY2hlY2tfcG9sbDogTWFjaGluZSBjaGVj
ayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuCihYRU4pICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgoo
WEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weGZmZmZmZmZmODAyMDAwMDAgbWVt
c3o9MHgxMDFmZmI4CihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4ZmZmZmZm
ZmY4MTQyMDAwMCBtZW1zej0weDUyODc5MAooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6
IDB4ZmZmZmZmZmY4MDIwMDAwMCAtPiAweGZmZmZmZmZmODE5NDg3OTAKKFhFTikgZWxmX3hlbl9w
YXJzZV9ub3RlOiBHVUVTVF9PUyA9ICJGcmVlQlNEIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6
IEdVRVNUX1ZFUlNJT04gPSAiMHgxMGM5MTEiCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVO
X1ZFUlNJT04gPSAieGVuLTMuMCIKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0Ug
PSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZT
RVQgPSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBFTlRSWSA9
IDB4ZmZmZmZmZmY4MGQ0YjAwMAooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9Q
QUdFID0gMHhmZmZmZmZmZjgwZDRhMDAwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RB
UlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVB
VFVSRVMgPSAid3JpdGFibGVfZGVzY3JpcHRvcl90YWJsZXN8YXV0b190cmFuc2xhdGVkX3BoeXNt
YXB8c3VwZXJ2aXNvcl9tb2RlX2tlcm5lbHxodm1fY2FsbGJhY2tfdmVjdG9yIgooWEVOKSBlbGZf
eGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIKKFhFTikgZWxmX3hlbl9wYXJzZV9ub3Rl
OiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IExP
QURFUiA9ICJnZW5lcmljIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VM
ID0gMHgwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogQlNEX1NZTVRBQiA9ICJ5ZXMiCihYRU4p
IGVsZl94ZW5fcGFyc2U6IHVzaW5nIG5vdGVzIGZyb20gU0hUX05PVEUgc2VjdGlvbgooWEVOKSBl
bGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2VzOgooWEVOKSAgICAgdmlydF9iYXNlICAg
ICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMAooWEVOKSAgICAgZWxmX3BhZGRyX29mZnNldCA9IDB4
ZmZmZmZmZmY4MDAwMDAwMAooWEVOKSAgICAgdmlydF9vZmZzZXQgICAgICA9IDB4MAooWEVOKSAg
ICAgdmlydF9rc3RhcnQgICAgICA9IDB4ZmZmZmZmZmY4MDIwMDAwMAooWEVOKSAgICAgdmlydF9r
ZW5kICAgICAgICA9IDB4ZmZmZmZmZmY4MWM0ZDNiMAooWEVOKSAgICAgdmlydF9lbnRyeSAgICAg
ICA9IDB4ZmZmZmZmZmY4MGQ0YjAwMAooWEVOKSAgICAgcDJtX2Jhc2UgICAgICAgICA9IDB4ZmZm
ZmZmZmZmZmZmZmZmZgooWEVOKSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMgoo
WEVOKSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4ZmZmZmZmZmY4MDIw
MDAwMCAtPiAweGZmZmZmZmZmODE5NDg3OTAKKFhFTikgIERvbTAgc3ltYm9sIG1hcCAweGZmZmZm
ZmZmODE5NDg3OTAgLT4gMHhmZmZmZmZmZjgxYzRkM2IwCihYRU4pIFBIWVNJQ0FMIE1FTU9SWSBB
UlJBTkdFTUVOVDoKKFhFTikgIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAxOTQwMDAwMDAtPjAwMDAw
MDAxOTgwMDAwMDAgKDUwNzAwMCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4pICBJbml0LiBy
YW1kaXNrOiAwMDAwMDAwMTlmYzc4MDAwLT4wMDAwMDAwMWEwMDAwMDAwCihYRU4pIFZJUlRVQUwg
TUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MDIwMDAw
MC0+ZmZmZmZmZmY4MWM0ZDNiMAooWEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MWM0ZTAw
MC0+ZmZmZmZmZmY4MWZkNjAwMAooWEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4MWZkNjAw
MC0+ZmZmZmZmZmY4MjNkNjAwMAooWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4MjNkNjAw
MC0+ZmZmZmZmZmY4MjNkNzRiNAooWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4MjNkODAw
MC0+ZmZmZmZmZmY4MjNlZjAwMAooWEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4MjNlZjAw
MC0+ZmZmZmZmZmY4MjNmMDAwMAooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAw
MC0+ZmZmZmZmZmY4MjgwMDAwMAooWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MGQ0YjAw
MAooWEVOKSBEb20wIGhhcyBtYXhpbXVtIDggVkNQVXMKKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBw
aGRyIDIgYXQgMHhmZmZmZmZmZjgwMjAwMDAwIC0+IDB4ZmZmZmZmZmY4MTIxZmZiOAooWEVOKSBl
bGZfbG9hZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZmODE0MjAwMDAgLT4gMHhmZmZmZmZm
ZjgxNTRkYmEwCihYRU4pIGVsZl9sb2FkX2JzZHN5bXM6IHNoZHIgNCBhdCAweGZmZmY4MzAxOWU4
NDdjMTAgLT4gMHhmZmZmZmZmZjgxOTQ5MzE4CihYRU4pIGVsZl9sb2FkX2JzZHN5bXM6IHNoZHIg
NDIgYXQgMHhmZmZmODMwMTlmOWM4ZTkzIC0+IDB4ZmZmZmZmZmY4MTk5ZjEwOAooWEVOKSBlbGZf
bG9hZF9ic2RzeW1zOiBzaGRyIDQzIGF0IDB4ZmZmZjgzMDE5ZjljOWMyMCAtPiAweGZmZmZmZmZm
ODE5OWYzNTgKKFhFTikgZWxmX2xvYWRfYnNkc3ltczogc2hkciA0NCBhdCAweGZmZmY4MzAxOWZi
MTJmYTggLT4gMHhmZmZmZmZmZjgxYWU4NmUwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6
SG9zdGJyaWRnZTogc2tpcCAwMDAwOjAwOjAwLjAgbWFwCihYRU4pIEZvdW5kIG1hc2tlZCBVUiBz
aWduYWxpbmcgb24gMDAwMDowMDowMC4wCihYRU4pIEZvdW5kIG1hc2tlZCBVUiBzaWduYWxpbmcg
b24gMDAwMDowMDowMS4wCihYRU4pIEZvdW5kIG1hc2tlZCBVUiBzaWduYWxpbmcgb24gMDAwMDow
MDowMy4wCihYRU4pIEZvdW5kIG1hc2tlZCBVUiBzaWduYWxpbmcgb24gMDAwMDowMDowNy4wCihY
RU4pIFtWVC1EXWlvbW11LmM6MTQ0NDogZDA6UENJZTogbWFwIDAwMDA6MDA6MTQuMAooWEVOKSBN
YXNrZWQgVlQtZCBlcnJvciBzaWduYWxpbmcgb24gMDAwMDowMDoxNC4wCihYRU4pIFtWVC1EXWlv
bW11LmM6MTQ0NDogZDA6UENJZTogbWFwIDAwMDA6MDA6MTQuMQooWEVOKSBbVlQtRF1pb21tdS5j
OjE0NDQ6IGQwOlBDSWU6IG1hcCAwMDAwOjAwOjE0LjIKKFhFTikgW1ZULURdaW9tbXUuYzoxNDU2
OiBkMDpQQ0k6IG1hcCAwMDAwOjAwOjFhLjAKKFhFTikgW1ZULURdaW9tbXUuYzoxNDU2OiBkMDpQ
Q0k6IG1hcCAwMDAwOjAwOjFhLjEKKFhFTikgW1ZULURdaW9tbXUuYzoxNDU2OiBkMDpQQ0k6IG1h
cCAwMDAwOjAwOjFhLjIKKFhFTikgW1ZULURdaW9tbXUuYzoxNDU2OiBkMDpQQ0k6IG1hcCAwMDAw
OjAwOjFhLjcKKFhFTikgW1ZULURdaW9tbXUuYzoxNDQ0OiBkMDpQQ0llOiBtYXAgMDAwMDowMDox
Yi4wCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxZC4wCihY
RU4pIFtWVC1EXWlvbW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxZC4xCihYRU4pIFtW
VC1EXWlvbW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxZC4yCihYRU4pIFtWVC1EXWlv
bW11LmM6MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxZC43CihYRU4pIFtWVC1EXWlvbW11LmM6
MTQ1NjogZDA6UENJOiBtYXAgMDAwMDowMDoxZi4wCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ1Njog
ZDA6UENJOiBtYXAgMDAwMDowMDoxZi4yCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ1NjogZDA6UENJ
OiBtYXAgMDAwMDowMDoxZi4zCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0NDogZDA6UENJZTogbWFw
IDAwMDA6MDE6MDAuMAooWEVOKSBbVlQtRF1pb21tdS5jOjE0NDQ6IGQwOlBDSWU6IG1hcCAwMDAw
OjAxOjAwLjEKKFhFTikgW1ZULURdaW9tbXUuYzoxNDQ0OiBkMDpQQ0llOiBtYXAgMDAwMDowMjow
MC4wCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0NDogZDA6UENJZTogbWFwIDAwMDA6MDQ6MDAuMAoo
WEVOKSBbVlQtRF1pb21tdS5jOjE0NDQ6IGQwOlBDSWU6IG1hcCAwMDAwOjA0OjAwLjEKKFhFTikg
W1ZULURdaW9tbXUuYzoxNDQ0OiBkMDpQQ0llOiBtYXAgMDAwMDowNTowMC4wCihYRU4pIFtWVC1E
XWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjAwLjAgbWFwCihYRU4p
IFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjAwLjEgbWFw
CihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjAy
LjAgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAw
OjNmOjAyLjEgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tp
cCAwMDAwOjNmOjAzLjAgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRn
ZTogc2tpcCAwMDAwOjNmOjAzLjEgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9z
dGJyaWRnZTogc2tpcCAwMDAwOjNmOjAzLjQgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDog
ZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA0LjAgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6
MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA0LjEgbWFwCihYRU4pIFtWVC1EXWlv
bW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA0LjIgbWFwCihYRU4pIFtW
VC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA0LjMgbWFwCihY
RU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA1LjAg
bWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNm
OjA1LjEgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAw
MDAwOjNmOjA1LjIgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJyaWRnZTog
c2tpcCAwMDAwOjNmOjA1LjMgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6SG9zdGJy
aWRnZTogc2tpcCAwMDAwOjNmOjA2LjAgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzMDogZDA6
SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA2LjEgbWFwCihYRU4pIFtWVC1EXWlvbW11LmM6MTQz
MDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA2LjIgbWFwCihYRU4pIFtWVC1EXWlvbW11
LmM6MTQzMDogZDA6SG9zdGJyaWRnZTogc2tpcCAwMDAwOjNmOjA2LjMgbWFwCihYRU4pIFtWVC1E
XWlvbW11LmM6NzM5OiBpb21tdV9lbmFibGVfdHJhbnNsYXRpb246IGlvbW11LT5yZWcgPSBmZmZm
ODJjMDAwMjAxMDAwCihYRU4pIFNjcnViYmluZyBGcmVlIFJBTSBvbiAxIG5vZGVzIHVzaW5nIDQg
Q1BVcwooWEVOKSAuLi4uLi4uLi4uLi4uZG9uZS4KKFhFTikgSW5pdGlhbCBsb3cgbWVtb3J5IHZp
cnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuCihYRU4pIFN0ZC4gTG9nbGV2ZWw6IEFs
bAooWEVOKSBHdWVzdCBMb2dsZXZlbDogQWxsCihYRU4pICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9N
MCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQooWEVO
KSBGcmVlZCAyODhrQiBpbml0IG1lbW9yeS4KRnJlZUJTRCBQVkggcnVubmluZyBvbiB4ZW4tMy4w
LXg4Nl82NHAKR0RCOiBubyBkZWJ1ZyBwb3J0cyBwcmVzZW50CktEQjogZGVidWdnZXIgYmFja2Vu
ZHM6IGRkYgpLREI6IGN1cnJlbnQgYmFja2VuZDogZGRiClNNQVAgdHlwZT0wMSBiYXNlPTAwMDAw
MDAwMDAwMDAwMDAgbGVuPTAwMDAwMDAwMDAwOTI4MDAKU01BUCB0eXBlPTAyIGJhc2U9MDAwMDAw
MDAwMDBmMDAwMCBsZW49MDAwMDAwMDAwMDAxMDAwMApTTUFQIHR5cGU9MDEgYmFzZT0wMDAwMDAw
MDAwMTAwMDAwIGxlbj0wMDAwMDAwMDdmZjZkMDAwClNNQVAgdHlwZT0wNCBiYXNlPTAwMDAwMDAw
ZGZkZjljMDAgbGVuPTAwMDAwMDAwMDAwNTIwMDAKU01BUCB0eXBlPTAzIGJhc2U9MDAwMDAwMDBk
ZmU0YmMwMCBsZW49MDAwMDAwMDAwMDAwMjAwMApTTUFQIHR5cGU9MDIgYmFzZT0wMDAwMDAwMGRm
ZTRkYzAwIGxlbj0wMDAwMDAwMDAwMWIyNDAwClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwZjgw
MDAwMDAgbGVuPTAwMDAwMDAwMDUwMDAwMDAKU01BUCB0eXBlPTAyIGJhc2U9MDAwMDAwMDBmZTAw
MDAwMCBsZW49MDAwMDAwMDAwMGQwMDQwMApTTUFQIHR5cGU9MDIgYmFzZT0wMDAwMDAwMGZlZTAw
MDAwIGxlbj0wMDAwMDAwMDAwMTAwMDAwClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwZmZiMDAw
MDAgbGVuPTAwMDAwMDAwMDA1MDAwMDAKVGFibGUgJ0ZBQ1AnIGF0IDB4ZmNkYjcKVGFibGUgJ1NT
RFQnIGF0IDB4ZmZlYTM0ZDYKVGFibGUgJ0FQSUMnIGF0IDB4ZmNlYWIKQVBJQzogRm91bmQgdGFi
bGUgYXQgMHhmY2VhYgpBUElDOiBVc2luZyB0aGUgWGVuIFBWIGVudW1lcmF0b3IuClNNUDogQWRk
ZWQgQ1BVIDAgKEJTUCkKU01QOiBBZGRlZCBDUFUgMiAoQVApClNNUDogQWRkZWQgQ1BVIDQgKEFQ
KQpTTVA6IEFkZGVkIENQVSA2IChBUCkKU01QOiBBZGRlZCBDUFUgOCAoQVApClNNUDogQWRkZWQg
Q1BVIDEwIChBUCkKU01QOiBBZGRlZCBDUFUgMTIgKEFQKQpTTVA6IEFkZGVkIENQVSAxNCAoQVAp
CkNvcHlyaWdodCAoYykgMTk5Mi0yMDE0IFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdodCAo
YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5Mywg
MTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJp
Z2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBG
cmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgMTEuMC1DVVJSRU5UICMxNDcgYjdkNTljZihwdmhf
ZG9tMCktZGlydHk6IFdlZCBEZWMgMTcgMTA6NDA6MTQgVVRDIDIwMTQKICAgIHJvb3RAb2Rpbjov
dXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDIGFtZDY0CkZyZWVCU0QgY2xhbmcgdmVyc2lvbiAz
LjQuMSAodGFncy9SRUxFQVNFXzM0L2RvdDEtZmluYWwgMjA4MDMyKSAyMDE0MDUxMgpXQVJOSU5H
OiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KVlQ6
IHJ1bm5pbmcgd2l0aCBkcml2ZXIgInZnYSIuCihYRU4pIGlycS5jOjM4MDogRG9tMCBjYWxsYmFj
ayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVjdG9yIDB4OTMKUHJlbG9hZGVkIGVsZiBtdWx0aWJv
b3Qga2VybmVsICIvYm9vdC94ZW42IiBhdCAweGZmZmZmZmZmODFjNGUwMDAuClByZWxvYWRlZCBl
bGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGZmZmZmZmZmODFjNGUxOTguClBy
ZWxvYWRlZCBlbGYgb2JqIG1vZHVsZSAiL2Jvb3Qva2VybmVsL3pmcy5rbyIgYXQgMHhmZmZmZmZm
ZjgxYzRlMjcwLgpQcmVsb2FkZWQgZWxmIG9iaiBtb2R1bGUgIi9ib290L2tlcm5lbC9vcGVuc29s
YXJpcy5rbyIgYXQgMHhmZmZmZmZmZjgxYzRlYTk4LgpDYWxpYnJhdGluZyBUU0MgY2xvY2sgLi4u
IFRTQyBjbG9jazogMzA2Njc4MTc2NyBIegpDUFU6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAg
ICAgICBXMzU1MCAgQCAzLjA3R0h6ICgzMDY2Ljc4LU1IeiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2lu
PSJHZW51aW5lSW50ZWwiICBJZD0weDEwNmE1ICBGYW1pbHk9MHg2ICBNb2RlbD0weDFhICBTdGVw
cGluZz01CiAgRmVhdHVyZXM9MHgxZmMzZWJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxN
Q0UsQ1g4LEFQSUMsU0VQLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQUNQSSxNTVgsRlhTUixTU0Us
U1NFMixTUyxIVFQ+CiAgRmVhdHVyZXMyPTB4ODA5ODIyODE8U1NFMyxFU1QsU1NTRTMsQ1gxNixT
U0U0LjEsU1NFNC4yLFBPUENOVCxIVj4KICBBTUQgRmVhdHVyZXM9MHgyMDEwMDgwMDxTWVNDQUxM
LE5YLExNPgogIEFNRCBGZWF0dXJlczI9MHgxPExBSEY+CiAgVFNDOiBQLXN0YXRlIGludmFyaWFu
dCwgcGVyZm9ybWFuY2Ugc3RhdGlzdGljcwpEYXRhIFRMQjogNCBLQiBwYWdlcywgNC13YXkgc2V0
IGFzc29jaWF0aXZlLCA2NCBlbnRyaWVzCjFzdC1sZXZlbCBkYXRhIGNhY2hlOiAzMiBLQiwgOC13
YXkgc2V0IGFzc29jaWF0aXZlLCA2NCBieXRlIGxpbmUgc2l6ZQpMMiBjYWNoZTogMjU2IGtieXRl
cywgOC13YXkgYXNzb2NpYXRpdmUsIDY0IGJ5dGVzL2xpbmUKSHlwZXJ2aXNvcjogT3JpZ2luID0g
IlhlblZNTVhlblZNTSIKcmVhbCBtZW1vcnkgID0gMjE0NzkzMDExMiAoMjA0OCBNQikKUGh5c2lj
YWwgbWVtb3J5IGNodW5rKHMpOgoweDAwMDAwMDAwMDAwMDEwMDAgLSAweDAwMDAwMDAwMDAwOTFm
ZmYsIDU5MzkyMCBieXRlcyAoMTQ1IHBhZ2VzKQoweDAwMDAwMDAwMDAxMDAwMDAgLSAweDAwMDAw
MDAwMDAxZmZmZmYsIDEwNDg1NzYgYnl0ZXMgKDI1NiBwYWdlcykKMHgwMDAwMDAwMDAyNDIwMDAw
IC0gMHgwMDAwMDAwMDdjYmRmZmZmLCAyMDU0OTQ2ODE2IGJ5dGVzICg1MDE2OTYgcGFnZXMpCmF2
YWlsIG1lbW9yeSA9IDIwMzE5NjAwNjQgKDE5MzcgTUIpCklOVFI6IEFkZGluZyBsb2NhbCBBUElD
IDIgYXMgYSB0YXJnZXQKSU5UUjogQWRkaW5nIGxvY2FsIEFQSUMgNCBhcyBhIHRhcmdldApJTlRS
OiBBZGRpbmcgbG9jYWwgQVBJQyA2IGFzIGEgdGFyZ2V0CklOVFI6IEFkZGluZyBsb2NhbCBBUElD
IDggYXMgYSB0YXJnZXQKSU5UUjogQWRkaW5nIGxvY2FsIEFQSUMgMTAgYXMgYSB0YXJnZXQKSU5U
UjogQWRkaW5nIGxvY2FsIEFQSUMgMTIgYXMgYSB0YXJnZXQKSU5UUjogQWRkaW5nIGxvY2FsIEFQ
SUMgMTQgYXMgYSB0YXJnZXQKRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRl
Y3RlZDogOCBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2thZ2UocykgeCA4IGNvcmUocykKIGNwdTAg
KEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAyCiBjcHUyIChBUCk6IEFQ
SUMgSUQ6ICA0CiBjcHUzIChBUCk6IEFQSUMgSUQ6ICA2CiBjcHU0IChBUCk6IEFQSUMgSUQ6ICA4
CiBjcHU1IChBUCk6IEFQSUMgSUQ6IDEwCiBjcHU2IChBUCk6IEFQSUMgSUQ6IDEyCiBjcHU3IChB
UCk6IEFQSUMgSUQ6IDE0Cng4NmJpb3M6ICBJVlQgMHgwMDAwMDAtMHgwMDA0ZmYgYXQgMHhmZmZm
ZjgwMDAwMDAwMDAwCng4NmJpb3M6IFNTRUcgMHgwMDEwMDAtMHgwMDFmZmYgYXQgMHhmZmZmZmUw
MDdiNWNkMDAwCng4NmJpb3M6ICBST00gMHgwYTAwMDAtMHgwZmVmZmYgYXQgMHhmZmZmZjgwMDAw
MGEwMDAwCnJhbmRvbSBkZXZpY2Ugbm90IGxvYWRlZC9hY3RpdmU7IHVzaW5nIGluc2VjdXJlIHBz
ZXVkby1yYW5kb20gbnVtYmVyIGdlbmVyYXRvcgpVTEU6IHNldHVwIGNwdSAwClVMRTogc2V0dXAg
Y3B1IDEKVUxFOiBzZXR1cCBjcHUgMgpVTEU6IHNldHVwIGNwdSAzClVMRTogc2V0dXAgY3B1IDQK
VUxFOiBzZXR1cCBjcHUgNQpVTEU6IHNldHVwIGNwdSA2ClVMRTogc2V0dXAgY3B1IDcKWGVuIGlu
dGVycnVwdCBzeXN0ZW0gaW5pdGlhbGl6ZWQKVGFibGUgJ0ZBQ1AnIGF0IDB4ZmNkYjcKVGFibGUg
J1NTRFQnIGF0IDB4ZmZlYTM0ZDYKVGFibGUgJ0FQSUMnIGF0IDB4ZmNlYWIKQVBJQzogRm91bmQg
dGFibGUgYXQgMHhmY2VhYgpBQ1BJOiBSU0RQIDB4MDAwMDAwMDAwMDBGRUMzMCAwMDAwMjQgKHYw
MiBERUxMICApCkFDUEk6IFhTRFQgMHgwMDAwMDAwMDAwMEZDQ0M3IDAwMDA3QyAodjAxIERFTEwg
ICBCMTBLICAgICAwMDAwMDAxNSBBU0wgIDAwMDAwMDYxKQpBQ1BJOiBGQUNQIDB4MDAwMDAwMDAw
MDBGQ0RCNyAwMDAwRjQgKHYwMyBERUxMICAgQjEwSyAgICAgMDAwMDAwMTUgQVNMICAwMDAwMDA2
MSkKQUNQSSBCSU9TIFdhcm5pbmcgKGJ1Zyk6IDMyLzY0WCBsZW5ndGggbWlzbWF0Y2ggaW4gRkFE
VC9HcGUwQmxvY2s6IDEyOC82NCAoMjAxNDA5MjYvdGJmYWR0LTY0NikKQUNQSTogRFNEVCAweDAw
MDAwMDAwRkZFOUU5NTEgMDA0QTc0ICh2MDEgREVMTCAgIGR0X2V4ICAgIDAwMDAxMDAwIElOVEwg
MjAwNTA2MjQpCkFDUEk6IEZBQ1MgMHgwMDAwMDAwMERGREY5QzAwIDAwMDA0MApBQ1BJOiBTU0RU
IDB4MDAwMDAwMDBGRkVBMzRENiAwMDAwOUMgKHYwMSBERUxMICAgc3RfZXggICAgMDAwMDEwMDAg
SU5UTCAyMDA1MDYyNCkKQUNQSTogQVBJQyAweDAwMDAwMDAwMDAwRkNFQUIgMDAwMTVFICh2MDEg
REVMTCAgIEIxMEsgICAgIDAwMDAwMDE1IEFTTCAgMDAwMDAwNjEpCkFDUEk6IEJPT1QgMHgwMDAw
MDAwMDAwMEZEMDA5IDAwMDAyOCAodjAxIERFTEwgICBCMTBLICAgICAwMDAwMDAxNSBBU0wgIDAw
MDAwMDYxKQpBQ1BJOiBBU0YhIDB4MDAwMDAwMDAwMDBGRDAzMSAwMDAwOTYgKHYzMiBERUxMICAg
QjEwSyAgICAgMDAwMDAwMTUgQVNMICAwMDAwMDA2MSkKQUNQSTogTUNGRyAweDAwMDAwMDAwMDAw
RkQwQzcgMDAwMDNDICh2MDEgREVMTCAgIEIxMEsgICAgIDAwMDAwMDE1IEFTTCAgMDAwMDAwNjEp
CkFDUEk6IEhQRVQgMHgwMDAwMDAwMDAwMEZEMTAzIDAwMDAzOCAodjAxIERFTEwgICBCMTBLICAg
ICAwMDAwMDAxNSBBU0wgIDAwMDAwMDYxKQpBQ1BJOiBUQ1BBIDB4MDAwMDAwMDAwMDBGRDM1RiAw
MDAwMzIgKHYwMSBERUxMICAgQjEwSyAgICAgMDAwMDAwMTUgQVNMICAwMDAwMDA2MSkKQUNQSTog
RE1BUiAweDAwMDAwMDAwMDAwRkQzOTEgMDAwMEM4ICh2MDEgREVMTCAgIEIxMEsgICAgIDAwMDAw
MDE1IEFTTCAgMDAwMDAwNjEpCkFDUEk6IFNMSUMgMHgwMDAwMDAwMDAwMEZEMTNCIDAwMDE3NiAo
djAxIERFTEwgICBCMTBLICAgICAwMDAwMDAxNSBBU0wgIDAwMDAwMDYxKQpBQ1BJOiBTU0RUIDB4
MDAwMDAwMDBERkU0REMwMCAwMDE1QzQgKHYwMSBJTlRFTCAgUFBNIFJDTSAgODAwMDAwMDEgSU5U
TCAyMDA2MTEwOSkKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgMCwgaXJxIDIKeGVu
OiByZWdpc3RlciBJUlEjMgpNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSA5LCBpcnEg
OQp4ZW46IHJlZ2lzdGVyIElSUSM5CmNwdTAgQlNQIFhFTiBQViBMQVBJQwpzbmRfdW5pdF9pbml0
KCkgdT0weDAwZmY4MDAwIFs1MTJdIGQ9MHgwMDAwN2MwMCBbMzJdIGM9MHgwMDAwMDNmZiBbMTAy
NF0KZmVlZGVyX3JlZ2lzdGVyOiBzbmRfdW5pdD0tMSBzbmRfbWF4YXV0b3ZjaGFucz0xNiBsYXRl
bmN5PTUgZmVlZGVyX3JhdGVfbWluPTEgZmVlZGVyX3JhdGVfbWF4PTIwMTYwMDAgZmVlZGVyX3Jh
dGVfcm91bmQ9MjUKd2xhbjogPDgwMi4xMSBMaW5rIExheWVyPgpyYW5kb206IGVudHJvcHkgZGV2
aWNlIGluZnJhc3RydWN0dXJlIGRyaXZlcgpyYW5kb206IHNlbGVjdGluZyBoaWdoZXN0IHByaW9y
aXR5IGFkYXB0b3IgPER1bW15PgprYmQ6IG5ldyBhcnJheSBzaXplIDQKa2JkMSBhdCBrYmRtdXgw
Cm1lbTogPG1lbW9yeT4KbmZzbG9jazogcHNldWRvLWRldmljZQpuZXRtYXA6IGxvYWRlZCBtb2R1
bGUKbnVsbDogPGZ1bGwgZGV2aWNlLCBudWxsIGRldmljZSwgemVybyBkZXZpY2U+Cm1vZHVsZV9y
ZWdpc3Rlcl9pbml0OiBNT0RfTE9BRCAodmVzYSwgMHhmZmZmZmZmZjgwZGQ1NGEwLCAwKSBlcnJv
ciAxOQppbzogPEkvTz4KcmFuZG9tOiBTT0ZUOiB5YXJyb3cgaW5pdCgpCnJhbmRvbTogc2VsZWN0
aW5nIGhpZ2hlc3QgcHJpb3JpdHkgYWRhcHRvciA8WWFycm93PgpWTUJVUzogbG9hZApocHRycjog
Um9ja2V0UkFJRCAxN3h4LzJ4eHggU0FUQSBjb250cm9sbGVyIGRyaXZlciB2MS4yCmhwdG5yOiBS
NzUwL0RDNzI4MCBjb250cm9sbGVyIGRyaXZlciB2MS4wLjEKaHB0Mjd4eDogUm9ja2V0UkFJRCAy
N3h4IGNvbnRyb2xsZXIgZHJpdmVyIHYxLjEKdnR2Z2EwOiA8dnRfdmdhIGRyaXZlcj4gb24gbW90
aGVyYm9hcmQKeGVucHYwOiA8WGVuIFBWIGJ1cz4gb24gbW90aGVyYm9hcmQKZ3JhbnR0YWJsZTA6
IDxYZW4gR3JhbnQtdGFibGUgRGV2aWNlPiBvbiB4ZW5wdjAKR3JhbnQgdGFibGUgaW5pdGlhbGl6
ZWQKeGMwOiA8WGVuIENvbnNvbGU+IG9uIHhlbnB2MAp4ZW5fZXQwOiA8WGVuIFBWIENsb2NrPiBv
biB4ZW5wdjAKRXZlbnQgdGltZXIgIlhFTlRJTUVSIiBmcmVxdWVuY3kgMTAwMDAwMDAwMCBIeiBx
dWFsaXR5IDk1MApUaW1lY291bnRlciAiWEVOVElNRVIiIGZyZXF1ZW5jeSAxMDAwMDAwMDAwIEh6
IHF1YWxpdHkgOTUwCnhlbl9ldDA6IHJlZ2lzdGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9jayAo
cmVzb2x1dGlvbiAxMDAwMDAwMHVzLCBhZGp1c3RtZW50IDUuMDAwMDAwMDAwcykKcHZjcHUwOiA8
WGVuIFBWIENQVT4gb24geGVucHYwCnB2Y3B1MTogPFhlbiBQViBDUFU+IG9uIHhlbnB2MApwdmNw
dTI6IDxYZW4gUFYgQ1BVPiBvbiB4ZW5wdjAKcHZjcHUzOiA8WGVuIFBWIENQVT4gb24geGVucHYw
CnB2Y3B1NDogPFhlbiBQViBDUFU+IG9uIHhlbnB2MApwdmNwdTU6IDxYZW4gUFYgQ1BVPiBvbiB4
ZW5wdjAKcHZjcHU2OiA8WGVuIFBWIENQVT4gb24geGVucHYwCnB2Y3B1NzogPFhlbiBQViBDUFU+
IG9uIHhlbnB2MAp4ZW5zdG9yZTA6IDxYZW5TdG9yZT4gb24geGVucHYwCnhzZF9kZXYwOiA8WGVu
c3RvcmVkIHVzZXItc3BhY2UgZGV2aWNlPiBvbiB4ZW5wdjAKZXZ0Y2huMDogPFhlbiBldmVudCBj
aGFubmVsIHVzZXItc3BhY2UgZGV2aWNlPiBvbiB4ZW5wdjAKcHJpdmNtZDA6IDxYZW4gcHJpdmls
ZWdlZCBpbnRlcmZhY2UgdXNlci1zcGFjZSBkZXZpY2U+IG9uIHhlbnB2MAppc2EwOiA8SVNBIGJ1
cz4gb24geGVucHYwCmFjcGkwOiA8REVMTCBCMTBLICAgPiBvbiBtb3RoZXJib2FyZApBQ1BJOiBB
bGwgQUNQSSBUYWJsZXMgc3VjY2Vzc2Z1bGx5IGFjcXVpcmVkClBDSWU6IE1lbW9yeSBNYXBwZWQg
Y29uZmlndXJhdGlvbiBiYXNlIEAgMHhmODAwMDAwMAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhl
ZCkKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDdmIGlycSA4IG9uIGFj
cGkwCmF0cnRjMDogbm90IGluc3RhbGxlZCBhcyB0aW1lLW9mLWRheSBjbG9jazogY2xvY2sgeGVu
X2V0IGhhcyBoaWdoZXIgcmVzb2x1dGlvbgphdHJ0YzA6IENhbid0IG1hcCBpbnRlcnJ1cHQuCmF0
dGltZXIwOiA8QVQgdGltZXI+IHBvcnQgMHg0MC0weDVmIGlycSAwIG9uIGFjcGkwClRpbWVjb3Vu
dGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCmF0dGltZXIwOiBDYW4n
dCBtYXAgaW50ZXJydXB0LgpwY2lfbGluazA6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAg
SVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkg
MTAgMTEgMTIgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1
IDYgNyA5IDEwIDExIDEyIDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAw
ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNQpwY2lfbGluazE6ICAgICAgICBJbmRleCAgSVJRICBS
dGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0
IDUgNiA3IDkgMTAgMTEgMTIgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMCAgIE4gICAg
IDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUg
ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNQpwY2lfbGluazI6ICAgICAgICBJbmRl
eCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA1ICAgTiAg
ICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAg
NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAg
ICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNQpwY2lfbGluazM6ICAg
ICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAg
MjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTUKICBWYWxpZGF0aW9uICAgICAg
ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE1CiAgQWZ0ZXIgRGlz
YWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNQpwY2lf
bGluazQ6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUg
ICAgICAgMCAgICA5ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTUKICBWYWxpZGF0
aW9uICAgICAgICAgIDAgICAgOSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE1CiAg
QWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAx
MiAxNQpwY2lfbGluazU6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRp
YWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTUK
ICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDEx
IDEyIDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcg
OSAxMCAxMSAxMiAxNQpwY2lfbGluazY6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJR
cwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA5ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAg
MTEgMTIgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAgOSAgIE4gICAgIDAgIDMgNCA1IDYg
NyA5IDEwIDExIDEyIDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAz
IDQgNSA2IDcgOSAxMCAxMSAxMiAxNQpwY2lfbGluazc6ICAgICAgICBJbmRleCAgSVJRICBSdGQg
IFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA1ICAgTiAgICAgMCAgMyA0IDUg
NiA3IDkgMTAgMTEgMTIgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAgNSAgIE4gICAgIDAg
IDMgNCA1IDYgNyA5IDEwIDExIDEyIDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBO
ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNQphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0
b24+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhj
ZmYgb24gYWNwaTAKcGNpYjA6IGRlY29kaW5nIDUgcmFuZ2UgMC0weGZmCnBjaWIwOiBkZWNvZGlu
ZyA0IHJhbmdlIDAtMHhjZjcKcGNpYjA6IGRlY29kaW5nIDQgcmFuZ2UgMHhkMDAtMHhmZmZmCnBj
aWIwOiBkZWNvZGluZyAzIHJhbmdlIDB4YTAwMDAtMHhiZmZmZgpwY2liMDogZGVjb2RpbmcgMyBy
YW5nZSAweGMwMDAwLTB4ZGZmZmYKcGNpYjA6IGRlY29kaW5nIDMgcmFuZ2UgMHhlMDAwMC0weGZm
ZmZmCnBjaWIwOiBkZWNvZGluZyAzIHJhbmdlIDB4ZGZmMDAwMDAtMHhmN2ZmZmZmZgpwY2liMDog
ZGVjb2RpbmcgMyByYW5nZSAweGZmOTgwMDAwLTB4ZmY5ODBmZmYKcGNpYjA6IGRlY29kaW5nIDMg
cmFuZ2UgMHhmZjk3YzAwMC0weGZmOTdmZmZmCnBjaWIwOiBkZWNvZGluZyAzIHJhbmdlIDB4ZmVk
MjAwMDAtMHhmZWQ5ZmZmZgpwY2kwOiA8WGVuIEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpMDog
ZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQw
NSwgcmV2aWQ9MHgyMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDYt
MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwMCwgc3RhdHJlZz0weDAw
MTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w
eDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNw
ZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2Vz
LCB2ZWN0b3IgbWFza3MKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMC5JTlRBCnBjaWIwOiBz
bG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CnhlbjogcmVnaXN0ZXIgSVJRIzE2CihYRU4p
IEZvdW5kIG1hc2tlZCBVUiBzaWduYWxpbmcgb24gMDAwMDowMDowMC4wCihYRU4pIFBDSSBhZGQg
ZGV2aWNlIDAwMDA6MDA6MDAuMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDM0MDgsIHJl
dmlkPTB4MjIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAw
LCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMDEwLCBj
YWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMiAo
NTAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMg
MyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCB2
ZWN0b3IgbWFza3MKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMS5JTlRBCnBjaWIwOiBzbG90
IDEgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CglzZWNidXM9MSwgc3ViYnVzPTEKKFhFTikgRm91
bmQgbWFza2VkIFVSIHNpZ25hbGluZyBvbiAwMDAwOjAwOjAxLjAKKFhFTikgUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDowMS4wCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQwYSwgcmV2aWQ9
MHgyMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhk
cnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hl
bG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDBhICgyNTAw
IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMyAg
c3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCB2ZWN0
b3IgbWFza3MKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMy5JTlRBCnBjaWIwOiBzbG90IDMg
SU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CglzZWNidXM9Miwgc3ViYnVzPTIKKFhFTikgRm91bmQg
bWFza2VkIFVSIHNpZ25hbGluZyBvbiAwMDAwOjAwOjAzLjAKKFhFTikgUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDowMy4wCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQwZSwgcmV2aWQ9MHgy
MgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTcsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5
cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z
ej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAyICg1MDAgbnMp
LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAzICBzdXBw
b3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIHZlY3RvciBt
YXNrcwpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC43LklOVEEKcGNpYjA6IHNsb3QgNyBJTlRB
IGhhcmR3aXJlZCB0byBJUlEgMTYKCXNlY2J1cz0zLCBzdWJidXM9MwooWEVOKSBGb3VuZCBtYXNr
ZWQgVVIgc2lnbmFsaW5nIG9uIDAwMDA6MDA6MDcuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjA3LjAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDJlLCByZXZpZD0weDIyCglk
b21haW49MCwgYnVzPTAsIHNsb3Q9MjAsIGZ1bmM9MAoJY2xhc3M9MDgtMDAtMDAsIGhkcnR5cGU9
MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0x
NiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4
bGF0PTB4MDAgKDAgbnMpCihYRU4pIE1hc2tlZCBWVC1kIGVycm9yIHNpZ25hbGluZyBvbiAwMDAw
OjAwOjE0LjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wCmZvdW5kLT4JdmVuZG9y
PTB4ODA4NiwgZGV2PTB4MzQyMiwgcmV2aWQ9MHgyMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIw
LCBmdW5jPTEKCWNsYXNzPTA4LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0w
eDAwMDAsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4
MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQooWEVOKSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjEKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgz
NDIzLCByZXZpZD0weDIyCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjAsIGZ1bmM9MgoJY2xhc3M9
MDgtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0w
eDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu
dD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDA6MTQuMgpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNhMzcsIHJldmlkPTB4MDAK
CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNiwgZnVuYz0wCgljbGFzcz0wYy0wMy0wMCwgaGRydHlw
ZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6
PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h
eGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJbWFwWzIwXTogdHlwZSBJL08gUG9y
dCwgcmFuZ2UgMzIsIGJhc2UgMHhmZjIwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0
ZWQgdHlwZSA0ICgweGZmMjAtMHhmZjNmKSBmb3IgcmlkIDIwIG9mIHBjaTA6MDoyNjowCnBjaWIw
OiBtYXRjaGVkIGVudHJ5IGZvciAwLjI2LklOVEEKcGNpYjA6IHNsb3QgMjYgSU5UQSBoYXJkd2ly
ZWQgdG8gSVJRIDE2CihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MWEuMApmb3VuZC0+CXZl
bmRvcj0weDgwODYsIGRldj0weDNhMzgsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xv
dD0yNiwgZnVuYz0xCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRy
ZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVy
PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50
cGluPWIsIGlycT0xMAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhm
ZjAwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweGZmMDAtMHhm
ZjFmKSBmb3IgcmlkIDIwIG9mIHBjaTA6MDoyNjoxCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAw
LjI2LklOVEIKcGNpYjA6IHNsb3QgMjYgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDE3CnhlbjogcmVn
aXN0ZXIgSVJRIzE3CihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MWEuMQpmb3VuZC0+CXZl
bmRvcj0weDgwODYsIGRldj0weDNhMzksIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xv
dD0yNiwgZnVuYz0yCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRy
ZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVy
PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50
cGluPWMsIGlycT05CgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGZj
MDAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4ZmMwMC0weGZj
MWYpIGZvciByaWQgMjAgb2YgcGNpMDowOjI2OjIKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAu
MjYuSU5UQwpwY2liMDogc2xvdCAyNiBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMjIKeGVuOiByZWdp
c3RlciBJUlEjMjIKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxYS4yCmZvdW5kLT4JdmVu
ZG9yPTB4ODA4NiwgZGV2PTB4M2EzYywgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90
PTI2LCBmdW5jPTcKCWNsYXNzPTBjLTAzLTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJl
Zz0weDAxMDYsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9
MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRw
aW49YywgaXJxPTkKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFw
WzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZjdmZmEwMDAsIHNpemUgMTAsIGVu
YWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZjdmZmEwMDAtMHhmN2ZmYTNmZikgZm9y
IHJpZCAxMCBvZiBwY2kwOjA6MjY6NwpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yNi5JTlRD
CnBjaWIwOiBzbG90IDI2IElOVEMgaGFyZHdpcmVkIHRvIElSUSAyMgooWEVOKSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjFhLjcKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTNlLCByZXZp
ZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjcsIGZ1bmM9MAoJY2xhc3M9MDQtMDMtMDAs
IGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNiwgc3RhdHJlZz0weDAwMTAsIGNh
Y2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw
IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAg
c3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJp
dAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZjdmZmMwMDAsIHNpemUg
MTQsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZjdmZmMwMDAtMHhmN2ZmZmZm
ZikgZm9yIHJpZCAxMCBvZiBwY2kwOjA6Mjc6MApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4y
Ny5JTlRBCnBjaWIwOiBzbG90IDI3IElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgooWEVOKSBQQ0kg
YWRkIGRldmljZSAwMDAwOjAwOjFiLjAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTQw
LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjgsIGZ1bmM9MAoJY2xhc3M9MDYt
MDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAw
MTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w
eDAyICg1MDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vy
c3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2Fn
ZQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOC5JTlRBCnBjaWIwOiBzbG90IDI4IElOVEEg
aGFyZHdpcmVkIHRvIElSUSAxNgoJc2VjYnVzPTQsIHN1YmJ1cz00CihYRU4pIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MWMuMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNhNGEsIHJldmlk
PTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOCwgZnVuYz01CgljbGFzcz0wNi0wNC0wMCwg
aGRydHlwZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDAxMCwgY2Fj
aGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDIgKDUw
MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMAoJcG93ZXJzcGVjIDIg
IHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCnBjaWIw
OiBtYXRjaGVkIGVudHJ5IGZvciAwLjI4LklOVEIKcGNpYjA6IHNsb3QgMjggSU5UQiBoYXJkd2ly
ZWQgdG8gSVJRIDE3CglzZWNidXM9NSwgc3ViYnVzPTUKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxYy41CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2EzNCwgcmV2aWQ9MHgwMAoJ
ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTAKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBl
PTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9
MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4
bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTUKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQs
IHJhbmdlIDMyLCBiYXNlIDB4ZmY4MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVk
IHR5cGUgNCAoMHhmZjgwLTB4ZmY5ZikgZm9yIHJpZCAyMCBvZiBwY2kwOjA6Mjk6MApwY2liMDog
bWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRBCnBjaWIwOiBzbG90IDI5IElOVEEgaGFyZHdpcmVk
IHRvIElSUSAyMwp4ZW46IHJlZ2lzdGVyIElSUSMyMwooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjFkLjAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTM1LCByZXZpZD0weDAwCglk
b21haW49MCwgYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MQoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9
MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0w
IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs
YXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MTAKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQs
IHJhbmdlIDMyLCBiYXNlIDB4ZmY2MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVk
IHR5cGUgNCAoMHhmZjYwLTB4ZmY3ZikgZm9yIHJpZCAyMCBvZiBwY2kwOjA6Mjk6MQpwY2liMDog
bWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRCCnBjaWIwOiBzbG90IDI5IElOVEIgaGFyZHdpcmVk
IHRvIElSUSAxNwooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjFkLjEKZm91bmQtPgl2ZW5k
b3I9MHg4MDg2LCBkZXY9MHgzYTM2LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9
MjksIGZ1bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVn
PTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0w
eDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBp
bj1jLCBpcnE9NQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhmZjQw
LCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweGZmNDAtMHhmZjVm
KSBmb3IgcmlkIDIwIG9mIHBjaTA6MDoyOToyCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5
LklOVEMKcGNpYjA6IHNsb3QgMjkgSU5UQyBoYXJkd2lyZWQgdG8gSVJRIDE4CnhlbjogcmVnaXN0
ZXIgSVJRIzE4CihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MWQuMgpmb3VuZC0+CXZlbmRv
cj0weDgwODYsIGRldj0weDNhM2EsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0y
OSwgZnVuYz03CgljbGFzcz0wYy0wMy0yMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9
MHgwMTA2LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4
MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGlu
PWEsIGlycT01Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsx
MF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZmOTgwMDAwLCBzaXplIDEwLCBlbmFi
bGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGZmOTgwMDAwLTB4ZmY5ODAzZmYpIGZvciBy
aWQgMTAgb2YgcGNpMDowOjI5OjcKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQQpw
Y2liMDogc2xvdCAyOSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjMKKFhFTikgUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxZC43CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjQ0ZSwgcmV2aWQ9
MHg5MAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMwLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAxLCBo
ZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNo
ZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAyICg1MDAg
bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXNlY2J1cz02LCBzdWJidXM9NgooWEVOKSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjFlLjAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTE2LCBy
ZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MAoJY2xhc3M9MDYtMDEt
MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAyMTAs
IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg
KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
Zi4wCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjgyMiwgcmV2aWQ9MHgwMAoJZG9tYWlu
PTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTIKCWNsYXNzPTAxLTA0LTAwLCBoZHJ0eXBlPTB4MDAs
IG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9MCAoZHdv
cmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4
MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTkKCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAg
Y3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDE2IG1lc3NhZ2VzCgltYXBbMTBdOiB0eXBlIEkvTyBQ
b3J0LCByYW5nZSAzMiwgYmFzZSAweGZlMDAsIHNpemUgIDMsIGVuYWJsZWQKcGNpYjA6IGFsbG9j
YXRlZCB0eXBlIDQgKDB4ZmUwMC0weGZlMDcpIGZvciByaWQgMTAgb2YgcGNpMDowOjMxOjIKCW1h
cFsxNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZmUxMCwgc2l6ZSAgMiwgZW5h
YmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhmZTEwLTB4ZmUxMykgZm9yIHJpZCAxNCBv
ZiBwY2kwOjA6MzE6MgoJbWFwWzE4XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhm
ZTIwLCBzaXplICAzLCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweGZlMjAtMHhm
ZTI3KSBmb3IgcmlkIDE4IG9mIHBjaTA6MDozMToyCgltYXBbMWNdOiB0eXBlIEkvTyBQb3J0LCBy
YW5nZSAzMiwgYmFzZSAweGZlMzAsIHNpemUgIDIsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0
eXBlIDQgKDB4ZmUzMC0weGZlMzMpIGZvciByaWQgMWMgb2YgcGNpMDowOjMxOjIKCW1hcFsyMF06
IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZmVjMCwgc2l6ZSAgNSwgZW5hYmxlZApw
Y2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhmZWMwLTB4ZmVkZikgZm9yIHJpZCAyMCBvZiBwY2kw
OjA6MzE6MgoJbWFwWzI0XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmY5NzAwMDAs
IHNpemUgMTEsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMzEuSU5UQwpwY2li
MDogc2xvdCAzMSBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMjAKeGVuOiByZWdpc3RlciBJUlEjMjAK
KFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxZi4yCmZvdW5kLT4JdmVuZG9yPTB4ODA4Niwg
ZGV2PTB4M2EzMCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTMK
CWNsYXNzPTBjLTA1LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDMsIHN0
YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks
IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTkK
CW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGY3ZmZiMDAwLCBzaXplICA4
LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGY3ZmZiMDAwLTB4ZjdmZmIwZmYp
IGZvciByaWQgMTAgb2YgcGNpMDowOjMxOjMKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdl
IDMyLCBiYXNlIDB4ZWNlMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUg
NCAoMHhlY2UwLTB4ZWNmZikgZm9yIHJpZCAyMCBvZiBwY2kwOjA6MzE6MwpwY2liMDogbWF0Y2hl
ZCBlbnRyeSBmb3IgMC4zMS5JTlRDCnBjaWIwOiBzbG90IDMxIElOVEMgaGFyZHdpcmVkIHRvIElS
USAyMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjFmLjMKcGNpYjE6IDxBQ1BJIFBDSS1Q
Q0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDEuMCBvbiBwY2kwCnBjaWIwOiBhbGxvY2F0ZWQg
dHlwZSAzICgweGYyMDAwMDAwLTB4ZjdiZmZmZmYpIGZvciByaWQgMjAgb2YgcGNpYjEKcGNpYjE6
ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAxCnBjaWIx
OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEKcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmMjAw
MDAwMC0weGY3YmZmZmZmCnBjaTE6IDxYZW4gQUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2liMTog
YWxsb2NhdGVkIGJ1cyByYW5nZSAoMS0xKSBmb3IgcmlkIDAgb2YgcGNpMQpwY2kxOiBkb21haW49
MCwgcGh5c2ljYWwgYnVzPTEKZm91bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNjM5LCByZXZp
ZD0weDIwCglkb21haW49MCwgYnVzPTEsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwg
aGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDAxMCwgY2Fj
aGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg
bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAzICBz
dXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDE2IG1lc3NhZ2VzLCA2NCBi
aXQKCU1TSS1YIHN1cHBvcnRzIDkgbWVzc2FnZXMgaW4gbWFwIDB4MTAKCW1hcFsxMF06IHR5cGUg
TWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGYyMDAwMDAwLCBzaXplIDI1LCBlbmFibGVkCnBjaWIx
OiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweGYyMDAwMDAwLTB4ZjNmZmZmZmYpIGZvciByaWQg
MTAgb2YgcGNpMDoxOjA6MApwY2liMTogbWF0Y2hlZCBlbnRyeSBmb3IgMS4wLklOVEEKcGNpYjE6
IHNsb3QgMCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjgKeGVuOiByZWdpc3RlciBJUlEjMjgKKFhF
TikgUENJIGFkZCBkZXZpY2UgMDAwMDowMTowMC4wCmZvdW5kLT4JdmVuZG9yPTB4MTRlNCwgZGV2
PTB4MTYzOSwgcmV2aWQ9MHgyMAoJZG9tYWluPTAsIGJ1cz0xLCBzbG90PTAsIGZ1bmM9MQoJY2xh
c3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNiwgc3RhdHJl
Zz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p
bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTEwCglw
b3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxNiBt
ZXNzYWdlcywgNjQgYml0CglNU0ktWCBzdXBwb3J0cyA5IG1lc3NhZ2VzIGluIG1hcCAweDEwCglt
YXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmNDAwMDAwMCwgc2l6ZSAyNSwg
ZW5hYmxlZApwY2liMTogYWxsb2NhdGVkIG1lbW9yeSByYW5nZSAoMHhmNDAwMDAwMC0weGY1ZmZm
ZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6MTowOjEKcGNpYjE6IG1hdGNoZWQgZW50cnkgZm9yIDEu
MC5JTlRCCnBjaWIxOiBzbG90IDAgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDQwCnhlbjogcmVnaXN0
ZXIgSVJRIzQwCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDE6MDAuMQpiY2UwOiA8UUxvZ2lj
IE5ldFh0cmVtZSBJSSBCQ001NzA5IDEwMDBCYXNlLVQgKEMwKT4gbWVtIDB4ZjIwMDAwMDAtMHhm
M2ZmZmZmZiBpcnEgMjggYXQgZGV2aWNlIDAuMCBvbiBwY2kxCmJjZTA6IC91c3Ivc3JjL3N5cy9k
ZXYvYmNlL2lmX2JjZS5jKDExNDEpOiBNU0kgYWxsb2NhdGlvbiBmYWlsZWQhIGVycm9yID0gMTkK
bWlpYnVzMDogPE1JSSBidXM+IG9uIGJjZTAKYnJncGh5MDogPEJDTTU3MDkgMTAvMTAwLzEwMDBi
YXNlVCBQSFk+IFBIWSAxIG9uIG1paWJ1czAKYnJncGh5MDogT1VJIDB4MDAwYWY3LCBtb2RlbCAw
eDAwM2MsIHJldi4gOApicmdwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwg
MTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VULCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRY
LCAxMDAwYmFzZVQtRkRYLW1hc3RlciwgYXV0bywgYXV0by1mbG93CmJjZTA6IFVzaW5nIGRlZmF1
bHRzIGZvciBUU086IDY1NTE4LzM1LzIwNDgKYmNlMDogYnBmIGF0dGFjaGVkCmJjZTA6IEV0aGVy
bmV0IGFkZHJlc3M6IDAwOjEwOjE4OmUwOjA1OjI4CmJjZTA6IEFTSUMgKDB4NTcwOTIwMDMpOyBS
ZXYgKEMwKTsgQnVzIChQQ0llIHg0LCAyLjVHYnBzKTsgQi9DICg1LjIuMyk7IEJ1ZnMgKFJYOjI7
VFg6MjtQRzo4KTsgRmxhZ3MgKFNQTFQpCkNvYWwgKFJYOjYsNiwxOCwxODsgVFg6MjAsMjAsODAs
ODApCmJjZTE6IDxRTG9naWMgTmV0WHRyZW1lIElJIEJDTTU3MDkgMTAwMEJhc2UtVCAoQzApPiBt
ZW0gMHhmNDAwMDAwMC0weGY1ZmZmZmZmIGlycSA0MCBhdCBkZXZpY2UgMC4xIG9uIHBjaTEKYmNl
MTogL3Vzci9zcmMvc3lzL2Rldi9iY2UvaWZfYmNlLmMoMTE0MSk6IE1TSSBhbGxvY2F0aW9uIGZh
aWxlZCEgZXJyb3IgPSAxOQptaWlidXMxOiA8TUlJIGJ1cz4gb24gYmNlMQpicmdwaHkxOiA8QkNN
NTcwOSAxMC8xMDAvMTAwMGJhc2VUIFBIWT4gUEhZIDEgb24gbWlpYnVzMQpicmdwaHkxOiBPVUkg
MHgwMDBhZjcsIG1vZGVsIDB4MDAzYywgcmV2LiA4CmJyZ3BoeTE6ICAxMGJhc2VULCAxMGJhc2VU
LUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1tYXN0
ZXIsIDEwMDBiYXNlVC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCBhdXRvLCBhdXRvLWZsb3cK
YmNlMTogVXNpbmcgZGVmYXVsdHMgZm9yIFRTTzogNjU1MTgvMzUvMjA0OApiY2UxOiBicGYgYXR0
YWNoZWQKYmNlMTogRXRoZXJuZXQgYWRkcmVzczogMDA6MTA6MTg6ZTA6MDU6MmEKYmNlMTogQVNJ
QyAoMHg1NzA5MjAwMyk7IFJldiAoQzApOyBCdXMgKFBDSWUgeDQsIDIuNUdicHMpOyBCL0MgKDUu
Mi4zKTsgQnVmcyAoUlg6MjtUWDoyO1BHOjgpOyBGbGFncyAoU1BMVCkKQ29hbCAoUlg6Niw2LDE4
LDE4OyBUWDoyMCwyMCw4MCw4MCkKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYg
YXQgZGV2aWNlIDMuMCBvbiBwY2kwCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweGQwMDAtMHhk
ZmZmKSBmb3IgcmlkIDFjIG9mIHBjaWIyCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGY3ZDAw
MDAwLTB4ZjdlZmZmZmYpIGZvciByaWQgMjAgb2YgcGNpYjIKcGNpYjA6IGFsbG9jYXRlZCB0eXBl
IDMgKDB4ZTAwMDAwMDAtMHhlZmZmZmZmZikgZm9yIHJpZCAyNCBvZiBwY2liMgpwY2liMjogICBk
b21haW4gICAgICAgICAgICAwCnBjaWIyOiAgIHNlY29uZGFyeSBidXMgICAgIDIKcGNpYjI6ICAg
c3Vib3JkaW5hdGUgYnVzICAgMgpwY2liMjogICBJL08gZGVjb2RlICAgICAgICAweGQwMDAtMHhk
ZmZmCnBjaWIyOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZjdkMDAwMDAtMHhmN2VmZmZmZgpwY2li
MjogICBwcmVmZXRjaGVkIGRlY29kZSAweGUwMDAwMDAwLTB4ZWZmZmZmZmYKcGNpYjI6ICAgc3Bl
Y2lhbCBkZWNvZGUgICAgVkdBCnBjaTI6IDxYZW4gQUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2li
MjogYWxsb2NhdGVkIGJ1cyByYW5nZSAoMi0yKSBmb3IgcmlkIDAgb2YgcGNpMgpwY2kyOiBkb21h
aW49MCwgcGh5c2ljYWwgYnVzPTIKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg5NWNmLCBy
ZXZpZD0weDAwCglkb21haW49MCwgYnVzPTIsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMy0wMC0w
MCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDAzLCBzdGF0cmVnPTB4MDAxMCwg
Y2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg
KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAz
ICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2Fn
ZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIFByZWZldGNoYWJsZSBNZW1vcnksIHJhbmdlIDY0LCBi
YXNlIDB4ZTAwMDAwMDAsIHNpemUgMjgsIGVuYWJsZWQKcGNpYjI6IGFsbG9jYXRlZCBwcmVmZXRj
aCByYW5nZSAoMHhlMDAwMDAwMC0weGVmZmZmZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6MjowOjAK
CW1hcFsxOF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGY3ZGYwMDAwLCBzaXplIDE2
LCBlbmFibGVkCnBjaWIyOiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweGY3ZGYwMDAwLTB4Zjdk
ZmZmZmYpIGZvciByaWQgMTggb2YgcGNpMDoyOjA6MAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwg
cmFuZ2UgMzIsIGJhc2UgMHhkYzAwLCBzaXplICA4LCBlbmFibGVkCnBjaWIyOiBhbGxvY2F0ZWQg
SS9PIHBvcnQgcmFuZ2UgKDB4ZGMwMC0weGRjZmYpIGZvciByaWQgMjAgb2YgcGNpMDoyOjA6MApw
Y2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi4wLklOVEEKcGNpYjI6IHNsb3QgMCBJTlRBIGhhcmR3
aXJlZCB0byBJUlEgMjQKeGVuOiByZWdpc3RlciBJUlEjMjQKKFhFTikgUENJIGFkZCBkZXZpY2Ug
MDAwMDowMjowMC4wCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4ZGMw
MC0weGRjZmYgbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZiwweGY3ZGYwMDAwLTB4ZjdkZmZmZmYg
aXJxIDI0IGF0IGRldmljZSAwLjAgb24gcGNpMgp2Z2FwY2kwOiBCb290IHZpZGVvIGRldmljZQpw
Y2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAK
cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZjdjMDAwMDAtMHhmN2NmZmZmZikgZm9yIHJpZCAy
MCBvZiBwY2liMwpwY2liMzogICBkb21haW4gICAgICAgICAgICAwCnBjaWIzOiAgIHNlY29uZGFy
eSBidXMgICAgIDMKcGNpYjM6ICAgc3Vib3JkaW5hdGUgYnVzICAgMwpwY2liMzogICBtZW1vcnkg
ZGVjb2RlICAgICAweGY3YzAwMDAwLTB4ZjdjZmZmZmYKcGNpMzogPFhlbiBBQ1BJIFBDSSBidXM+
IG9uIHBjaWIzCnBjaWIzOiBhbGxvY2F0ZWQgYnVzIHJhbmdlICgzLTMpIGZvciByaWQgMCBvZiBw
Y2kzCnBjaTM6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MwpwY2kwOiA8YmFzZSBwZXJpcGhlcmFs
LCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDIwLjAgKG5vIGRyaXZlciBhdHRhY2hl
ZCkKcGNpMDogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmlj
ZSAyMC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWwsIGludGVy
cnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMjAuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQp1aGNp
MDogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItRD4gcG9ydCAweGZm
MjAtMHhmZjNmIGlycSAxNiBhdCBkZXZpY2UgMjYuMCBvbiBwY2kwCnVoY2kwOiBMZWdTdXAgPSAw
eDJmMDAKdXNidXMwIG9uIHVoY2kwCnVoY2kwOiB1c2JwZjogQXR0YWNoZWQKdWhjaTE6IDxJbnRl
bCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUU+IHBvcnQgMHhmZjAwLTB4ZmYx
ZiBpcnEgMTcgYXQgZGV2aWNlIDI2LjEgb24gcGNpMAp1aGNpMTogTGVnU3VwID0gMHgyZjAwCnVz
YnVzMSBvbiB1aGNpMQp1aGNpMTogdXNicGY6IEF0dGFjaGVkCnVoY2kyOiA8SW50ZWwgODI4MDFK
SSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1GPiBwb3J0IDB4ZmMwMC0weGZjMWYgaXJxIDIy
IGF0IGRldmljZSAyNi4yIG9uIHBjaTAKdWhjaTI6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czIgb24g
dWhjaTIKdWhjaTI6IHVzYnBmOiBBdHRhY2hlZAplaGNpMDogPEludGVsIDgyODAxSkkgKElDSDEw
KSBVU0IgMi4wIGNvbnRyb2xsZXIgVVNCLUI+IG1lbSAweGY3ZmZhMDAwLTB4ZjdmZmEzZmYgaXJx
IDIyIGF0IGRldmljZSAyNi43IG9uIHBjaTAKdXNidXMzOiBFSENJIHZlcnNpb24gMS4wCnVzYnVz
MyBvbiBlaGNpMAplaGNpMDogdXNicGY6IEF0dGFjaGVkCmhkYWMwOiA8SW50ZWwgODI4MDFKSSBI
REEgQ29udHJvbGxlcj4gbWVtIDB4ZjdmZmMwMDAtMHhmN2ZmZmZmZiBpcnEgMTYgYXQgZGV2aWNl
IDI3LjAgb24gcGNpMApoZGFjMDogUENJIGNhcmQgdmVuZG9yOiAweDEwMjgsIGRldmljZTogMHgw
MjkzCmhkYWMwOiBIREEgRHJpdmVyIFJldmlzaW9uOiAyMDEyMDEyNl8wMDAyCmhkYWMwOiBDb25m
aWcgb3B0aW9uczogb249MHgwMDAwMDAwMCBvZmY9MHgwMDAwMDAwMApoZGFjMDogQ2FwczogT1NT
IDQsIElTUyA0LCBCU1MgMCwgTlNETyAxLCA2NGJpdCwgQ09SQiAyNTYsIFJJUkIgMjU2CnBjaWI0
OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAyOC4wIG9uIHBjaTAKcGNp
YjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4YzAwMC0weGNmZmYpIGZvciByaWQgMWMgb2YgcGNpYjQK
cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZjFlMDAwMDAtMHhmMWZmZmZmZikgZm9yIHJpZCAy
MCBvZiBwY2liNApwY2liNDogICBkb21haW4gICAgICAgICAgICAwCnBjaWI0OiAgIHNlY29uZGFy
eSBidXMgICAgIDQKcGNpYjQ6ICAgc3Vib3JkaW5hdGUgYnVzICAgNApwY2liNDogICBJL08gZGVj
b2RlICAgICAgICAweGMwMDAtMHhjZmZmCnBjaWI0OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZjFl
MDAwMDAtMHhmMWZmZmZmZgpwY2k0OiA8WGVuIEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKcGNpYjQ6
IGFsbG9jYXRlZCBidXMgcmFuZ2UgKDQtNCkgZm9yIHJpZCAwIG9mIHBjaTQKcGNpNDogZG9tYWlu
PTAsIHBoeXNpY2FsIGJ1cz00CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MTA1ZSwgcmV2
aWQ9MHgwNgoJZG9tYWluPTAsIGJ1cz00LCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAs
IGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNh
Y2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw
IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAg
c3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJp
dAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZjFlODAwMDAsIHNpemUg
MTcsIGVuYWJsZWQKcGNpYjQ6IGFsbG9jYXRlZCBtZW1vcnkgcmFuZ2UgKDB4ZjFlODAwMDAtMHhm
MWU5ZmZmZikgZm9yIHJpZCAxMCBvZiBwY2kwOjQ6MDowCgltYXBbMTRdOiB0eXBlIE1lbW9yeSwg
cmFuZ2UgMzIsIGJhc2UgMHhmMWVhMDAwMCwgc2l6ZSAxNywgZW5hYmxlZApwY2liNDogYWxsb2Nh
dGVkIG1lbW9yeSByYW5nZSAoMHhmMWVhMDAwMC0weGYxZWJmZmZmKSBmb3IgcmlkIDE0IG9mIHBj
aTA6NDowOjAKCW1hcFsxOF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4Y2NjMCwg
c2l6ZSAgNSwgZW5hYmxlZApwY2liNDogYWxsb2NhdGVkIEkvTyBwb3J0IHJhbmdlICgweGNjYzAt
MHhjY2RmKSBmb3IgcmlkIDE4IG9mIHBjaTA6NDowOjAKcGNpYjQ6IG1hdGNoZWQgZW50cnkgZm9y
IDQuMC5JTlRBCnBjaWI0OiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CihYRU4pIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDEw
NWUsIHJldmlkPTB4MDYKCWRvbWFpbj0wLCBidXM9NCwgc2xvdD0wLCBmdW5jPTEKCWNsYXNzPTAy
LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgw
MDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9
MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMAoJcG93ZXJz
cGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdl
LCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGYxZWMwMDAw
LCBzaXplIDE3LCBlbmFibGVkCnBjaWI0OiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweGYxZWMw
MDAwLTB4ZjFlZGZmZmYpIGZvciByaWQgMTAgb2YgcGNpMDo0OjA6MQoJbWFwWzE0XTogdHlwZSBN
ZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZjFlZTAwMDAsIHNpemUgMTcsIGVuYWJsZWQKcGNpYjQ6
IGFsbG9jYXRlZCBtZW1vcnkgcmFuZ2UgKDB4ZjFlZTAwMDAtMHhmMWVmZmZmZikgZm9yIHJpZCAx
NCBvZiBwY2kwOjQ6MDoxCgltYXBbMThdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAw
eGNjZTAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjQ6IGFsbG9jYXRlZCBJL08gcG9ydCByYW5nZSAo
MHhjY2UwLTB4Y2NmZikgZm9yIHJpZCAxOCBvZiBwY2kwOjQ6MDoxCnBjaWI0OiBtYXRjaGVkIGVu
dHJ5IGZvciA0LjAuSU5UQgpwY2liNDogc2xvdCAwIElOVEIgaGFyZHdpcmVkIHRvIElSUSAxNwoo
WEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjEKZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAg
TmV0d29yayBDb25uZWN0aW9uIDcuNC4yPiBwb3J0IDB4Y2NjMC0weGNjZGYgbWVtIDB4ZjFlODAw
MDAtMHhmMWU5ZmZmZiwweGYxZWEwMDAwLTB4ZjFlYmZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAg
b24gcGNpNAplbTA6IE5vIE1TSS9NU0lYIHVzaW5nIGEgTGVnYWN5IElSUQplbTA6IGJwZiBhdHRh
Y2hlZAplbTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjFiOjIxOmM2OmU5OmFlCjAwMS4wMDAwMTAg
WzI3MThdIG5ldG1hcF9hdHRhY2ggICAgICAgICAgICAgc3VjY2VzcyBmb3IgZW0wIHR4IDEvMTAy
NCByeCAxLzEwMjQgcXVldWVzL3Nsb3RzCmVtMTogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsg
Q29ubmVjdGlvbiA3LjQuMj4gcG9ydCAweGNjZTAtMHhjY2ZmIG1lbSAweGYxZWMwMDAwLTB4ZjFl
ZGZmZmYsMHhmMWVlMDAwMC0weGYxZWZmZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4xIG9uIHBjaTQK
ZW0xOiBObyBNU0kvTVNJWCB1c2luZyBhIExlZ2FjeSBJUlEKZW0xOiBicGYgYXR0YWNoZWQKZW0x
OiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxYjoyMTpjNjplOTphZgowMDEuMDAwMDExIFsyNzE4XSBu
ZXRtYXBfYXR0YWNoICAgICAgICAgICAgIHN1Y2Nlc3MgZm9yIGVtMSB0eCAxLzEwMjQgcnggMS8x
MDI0IHF1ZXVlcy9zbG90cwpwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNyBhdCBk
ZXZpY2UgMjguNSBvbiBwY2kwCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGYxZDAwMDAwLTB4
ZjFkZmZmZmYpIGZvciByaWQgMjAgb2YgcGNpYjUKcGNpYjU6ICAgZG9tYWluICAgICAgICAgICAg
MApwY2liNTogICBzZWNvbmRhcnkgYnVzICAgICA1CnBjaWI1OiAgIHN1Ym9yZGluYXRlIGJ1cyAg
IDUKcGNpYjU6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmMWQwMDAwMC0weGYxZGZmZmZmCnBjaTU6
IDxYZW4gQUNQSSBQQ0kgYnVzPiBvbiBwY2liNQpwY2liNTogYWxsb2NhdGVkIGJ1cyByYW5nZSAo
NS01KSBmb3IgcmlkIDAgb2YgcGNpNQpwY2k1OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTUKZm91
bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNjgxLCByZXZpZD0weDEwCglkb21haW49MCwgYnVz
PTUsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0w
CgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCgls
YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu
cykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVu
dCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIE1lbW9y
eSwgcmFuZ2UgNjQsIGJhc2UgMHhmMWRlMDAwMCwgc2l6ZSAxNiwgZW5hYmxlZApwY2liNTogYWxs
b2NhdGVkIG1lbW9yeSByYW5nZSAoMHhmMWRlMDAwMC0weGYxZGVmZmZmKSBmb3IgcmlkIDEwIG9m
IHBjaTA6NTowOjAKCW1hcFsxOF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGYxZGYw
MDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWI1OiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweGYx
ZGYwMDAwLTB4ZjFkZmZmZmYpIGZvciByaWQgMTggb2YgcGNpMDo1OjA6MApwY2liNTogbWF0Y2hl
ZCBlbnRyeSBmb3IgNS4wLklOVEEKcGNpYjU6IHNsb3QgMCBJTlRBIGhhcmR3aXJlZCB0byBJUlEg
MTcKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4wCmJnZTA6IDxCcm9hZGNvbSBOZXRY
dHJlbWUgR2lnYWJpdCBFdGhlcm5ldCBDb250cm9sbGVyLCBBU0lDIHJldi4gMHg1NzYxMTAwPiBt
ZW0gMHhmMWRlMDAwMC0weGYxZGVmZmZmLDB4ZjFkZjAwMDAtMHhmMWRmZmZmZiBpcnEgMTcgYXQg
ZGV2aWNlIDAuMCBvbiBwY2k1CmJnZTA6IENISVAgSUQgMHgwNTc2MTEwMDsgQVNJQyBSRVYgMHg1
NzYxOyBDSElQIFJFViAweDU3NjExOyBQQ0ktRQpiZ2UwOiBEaXNhYmxpbmcgZmFzdGJvb3QKbWlp
YnVzMjogPE1JSSBidXM+IG9uIGJnZTAKYnJncGh5MjogPEJDTTU3NjEgMTAvMTAwLzEwMDBiYXNl
VCBQSFk+IFBIWSAxIG9uIG1paWJ1czIKYnJncGh5MjogT1VJIDB4MDAwYWY3LCBtb2RlbCAweDAw
M2QsIHJldi4gMApicmdwaHkyOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAw
YmFzZVRYLUZEWCwgMTAwMGJhc2VULCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLCAx
MDAwYmFzZVQtRkRYLW1hc3RlciwgYXV0bywgYXV0by1mbG93CmJnZTA6IFVzaW5nIGRlZmF1bHRz
IGZvciBUU086IDY1NTE4LzM1LzIwNDgKYmdlMDogYnBmIGF0dGFjaGVkCmJnZTA6IEV0aGVybmV0
IGFkZHJlc3M6IGQ0OmFlOjUyOmMxOmQ0OjNkCnVoY2kzOiA8SW50ZWwgODI4MDFKSSAoSUNIMTAp
IFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4ZmY4MC0weGZmOWYgaXJxIDIzIGF0IGRldmlj
ZSAyOS4wIG9uIHBjaTAKdXNidXM0IG9uIHVoY2kzCnVoY2kzOiB1c2JwZjogQXR0YWNoZWQKdWhj
aTQ6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IHBvcnQgMHhm
ZjYwLTB4ZmY3ZiBpcnEgMTcgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1c2J1czUgb24gdWhjaTQK
dWhjaTQ6IHVzYnBmOiBBdHRhY2hlZAp1aGNpNTogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0Ig
Y29udHJvbGxlciBVU0ItQz4gcG9ydCAweGZmNDAtMHhmZjVmIGlycSAxOCBhdCBkZXZpY2UgMjku
MiBvbiBwY2kwCnVzYnVzNiBvbiB1aGNpNQp1aGNpNTogdXNicGY6IEF0dGFjaGVkCmVoY2kxOiA8
SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiAyLjAgY29udHJvbGxlciBVU0ItQT4gbWVtIDB4ZmY5
ODAwMDAtMHhmZjk4MDNmZiBpcnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAp1c2J1czc6IEVI
Q0kgdmVyc2lvbiAxLjAKdXNidXM3IG9uIGVoY2kxCmVoY2kxOiB1c2JwZjogQXR0YWNoZWQKcGNp
YjY6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaWI2OiAg
IGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjY6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgNgpwY2liNjog
ICBzdWJvcmRpbmF0ZSBidXMgICA2CnBjaWI2OiAgIHNwZWNpYWwgZGVjb2RlICAgIHN1YnRyYWN0
aXZlCnBjaTY6IDxYZW4gQUNQSSBQQ0kgYnVzPiBvbiBwY2liNgpwY2liNjogYWxsb2NhdGVkIGJ1
cyByYW5nZSAoNi02KSBmb3IgcmlkIDAgb2YgcGNpNgpwY2k2OiBkb21haW49MCwgcGh5c2ljYWwg
YnVzPTYKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2E6
IGlzYTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmRldmljZV9hdHRhY2g6IGlzYWIwIGF0
dGFjaCByZXR1cm5lZCA2CmFoY2kwOiA8SW50ZWwgSUNIOCBBSENJIFNBVEEgY29udHJvbGxlcj4g
cG9ydCAweGZlMDAtMHhmZTA3LDB4ZmUxMC0weGZlMTMsMHhmZTIwLTB4ZmUyNywweGZlMzAtMHhm
ZTMzLDB4ZmVjMC0weGZlZGYgbWVtIDB4ZmY5NzAwMDAtMHhmZjk3MDdmZiBpcnEgMjAgYXQgZGV2
aWNlIDMxLjIgb24gcGNpMAphaGNpMDogQUhDSSB2MS4yMCB3aXRoIDYgM0dicHMgcG9ydHMsIFBv
cnQgTXVsdGlwbGllciBub3Qgc3VwcG9ydGVkCmFoY2kwOiBDYXBzOiA2NGJpdCBOQ1EgU05URiBB
TCBDTE8gM0dicHMgUE1EIDMyY21kIENDQyBFTSBlU0FUQSA2cG9ydHMKYWhjaTA6IENhcHMyOgph
aGNpY2gwOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gYWhjaTAKYWhjaWNoMDogQ2Fw
czoKYWhjaWNoMTogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwCmFoY2ljaDE6
IENhcHM6CmFoY2ljaDI6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMiBvbiBhaGNpMAphaGNp
Y2gyOiBDYXBzOgphaGNpY2gzOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDMgb24gYWhjaTAK
YWhjaWNoMzogQ2FwczoKYWhjaWNoNDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA0IG9uIGFo
Y2kwCmFoY2ljaDQ6IENhcHM6CmFoY2ljaDU6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNSBv
biBhaGNpMAphaGNpY2g1OiBDYXBzOiBIUENQIEVTUAphaGNpZW0wOiA8QUhDSSBlbmNsb3N1cmUg
bWFuYWdlbWVudCBicmlkZ2U+IG9uIGFoY2kwCmFoY2llbTA6IENhcHM6IEFMSEQgWE1UIFNNQiBM
RUQKcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0
dGFjaGVkKQpwcGMwOiB1c2luZyBleHRlbmRlZCBJL08gcG9ydCByYW5nZQpwcGMwOiBTUFAgRUNQ
ICBFQ1ArRVBQCnBwYzA6IDxQYXJhbGxlbCBwb3J0PiBwb3J0IDB4Mzc4LTB4MzdmLDB4Nzc4LTB4
NzdmIGlycSA3IG9uIGFjcGkwCnBwYzA6IFNNQy1saWtlIGNoaXBzZXQgKEVDUC9FUFAvUFMyL05J
QkJMRSkgaW4gQ09NUEFUSUJMRSBtb2RlCnBwYzA6IEZJRk8gd2l0aCAxNi8xNi84IGJ5dGVzIHRo
cmVzaG9sZApwcGJ1czA6IDxQYXJhbGxlbCBwb3J0IGJ1cz4gb24gcHBjMApscHQwOiA8UHJpbnRl
cj4gb24gcHBidXMwCmxwdDA6IFBvbGxlZCBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBw
YnVzMAp1YXJ0MTogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMg
b24gYWNwaTAKdWFydDE6IHBvbGxlZCBtb2RlICg1MEh6KQpBQ1BJOiBFbmFibGVkIDMgR1BFcyBp
biBibG9jayAwMCB0byAzRgpxcGkwOiA8UVBJIHN5c3RlbSBidXM+IG9uIG1vdGhlcmJvYXJkCmFj
cGkwOiB3YWtldXAgY29kZSB2YSAweGZmZmZmZTAwOTZkYjcwMDAgcGEgMHg0MDAwCmFoY19pc2Ff
aWRlbnRpZnkgMDogaW9wb3J0IDB4YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDEy
OiBpb3BvcnQgMHhjYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDEzOiBpb3BvcnQg
MHhkYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDE0OiBpb3BvcnQgMHhlYzAwIGFs
bG9jIGZhaWxlZApleF9pc2FfaWRlbnRpZnkoKQppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGlu
ZyBQblAgZGV2aWNlcwphdHJ0YzogYXRydGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAph
dHRpbWVyOiBhdHRpbWVyMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKcHBjOiBwcGMwIGFs
cmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzYzogc2MwIGFscmVhZHkgZXhpc3RzOyBza2lwcGlu
ZyBpdAp1YXJ0OiB1YXJ0MSBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2No
aWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2aWNlcwpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBh
dCBpb21lbSAweGQwMDAwLTB4ZGE3ZmYsMHhkYTgwMC0weGRjN2ZmLDB4ZGM4MDAtMHhkZTdmZiww
eGRlODAwLTB4ZTBmZmYsMHhlMTAwMC0weGUzZmZmIG9uIGlzYTAKc2MwIGZhaWxlZCB0byBwcm9i
ZSBvbiBpc2EwCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYjAtMHgzYmIgaW9t
ZW0gMHhiMDAwMC0weGI3ZmZmIG9uIGlzYTAKYXRrYmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9y
dCAweDYwIG9uIGlzYTAKZmRjMDogY2Fubm90IHJlc2VydmUgaW50ZXJydXB0IGxpbmUKZmRjMCBm
YWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBp
c2EwCnVhcnQwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2Y4IGlycSA0IG9uIGlzYTAKd2J3
ZDAgZmFpbGVkIHRvIHByb2JlIG9uIGlzYTAKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBu
UCBkZXZpY2VzCkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLgpwcm9jZnMgcmVnaXN0ZXJl
ZApaRlMgTk9USUNFOiBQcmVmZXRjaCBpcyBkaXNhYmxlZCBieSBkZWZhdWx0IGlmIGxlc3MgdGhh
biA0R0Igb2YgUkFNIGlzIHByZXNlbnQ7CiAgICAgICAgICAgIHRvIGVuYWJsZSwgYWRkICJ2ZnMu
emZzLnByZWZldGNoX2Rpc2FibGU9MCIgdG8gL2Jvb3QvbG9hZGVyLmNvbmYuClpGUyBmaWxlc3lz
dGVtIHZlcnNpb246IDUKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uOiBmZWF0dXJlcyBzdXBwb3J0
ICg1MDAwKQpUaW1lY291bnRlcnMgdGljayBldmVyeSAxMC4wMDAgbXNlYwp2bGFuOiBpbml0aWFs
aXplZCwgdXNpbmcgaGFzaCB0YWJsZXMgd2l0aCBjaGFpbmluZwp0Y3BfaW5pdDogbmV0LmluZXQu
dGNwLnRjYmhhc2hzaXplIGF1dG8gdHVuZWQgdG8gMTYzODQKbG8wOiBicGYgYXR0YWNoZWQKaHB0
cnI6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQuCmhwdG5yOiBubyBjb250cm9sbGVyIGRldGVjdGVk
LgpocHQyN3h4OiBubyBjb250cm9sbGVyIGRldGVjdGVkLgpoZGFjYzA6IDxBbmFsb2cgRGV2aWNl
cyBBRDE5ODRBIEhEQSBDT0RFQz4gYXQgY2FkIDAgb24gaGRhYzAKaGRhYTA6IDxBbmFsb2cgRGV2
aWNlcyBBRDE5ODRBIEF1ZGlvIEZ1bmN0aW9uIEdyb3VwPiBhdCBuaWQgMSBvbiBoZGFjYzAKaGRh
YTA6IFN1YnN5c3RlbSBJRDogMHgxMDI4MDI5MwpoZGFhMDogTnVtR1BJTz0zIE51bUdQTz0wIE51
bUdQST0wIEdQSVdha2U9MCBHUElVbnNvbD0xCmhkYWEwOiAgR1BJTzA6IGRpc2FibGVkCmhkYWEw
OiAgR1BJTzE6IGRpc2FibGVkCmhkYWEwOiAgR1BJTzI6IGRpc2FibGVkCmhkYWEwOiBXQVJOSU5H
OiBuaWQ9NDIgaGFzIGNuaWQgb3V0c2lkZSBvZiB0aGUgQUZHIHJhbmdlIGo9MCBlbnRudW09NCBp
bmRleD0wIHJlcz0weDAwMDAyNzAxCmhkYWEwOiBPcmlnaW5hbCBwaW5zIGNvbmZpZ3VyYXRpb246
CmhkYWEwOiBuaWQgICAweCAgICBhcyBzZXEgZGV2aWNlICAgICAgIGNvbm4gIGphY2sgICAgbG9j
ICAgICAgICBjb2xvciAgIG1pc2MKaGRhYTA6IDE3IDAyMjE0MDQwIDQgIDAgIEhlYWRwaG9uZXMg
ICAgSmFjayAgMS84ICAgICBGcm9udCAgICAgIEdyZWVuICAgMApoZGFhMDogMTggMDEwMTQwMTAg
MSAgMCAgTGluZS1vdXQgICAgICBKYWNrICAxLzggICAgIFJlYXIgICAgICAgR3JlZW4gICAwCmhk
YWEwOiAxOSA5OTEzMDFmMCAxNSAwICBTcGVha2VyICAgICAgIEZpeGVkIEFUQVBJICAgT25ib2Fy
ZCAgICBVbmtub3duIDEKaGRhYTA6IDIwIDAyYTE5MDIwIDIgIDAgIE1pYyAgICAgICAgICAgSmFj
ayAgMS84ICAgICBGcm9udCAgICAgIFBpbmsgICAgMApoZGFhMDogMjEgMDE4MTMwMzAgMyAgMCAg
TGluZS1pbiAgICAgICBKYWNrICAxLzggICAgIFJlYXIgICAgICAgQmx1ZSAgICAwCmhkYWEwOiAy
MiA0MTMzMDFmMCAxNSAwICBDRCAgICAgICAgICAgIE5vbmUgIEFUQVBJICAgUmVhciAgICAgICBV
bmtub3duIDEKaGRhYTA6IDIzIDQxYTYwMWYwIDE1IDAgIE1pYyAgICAgICAgICAgTm9uZSAgRGln
aXRhbCBSZWFyICAgICAgIFVua25vd24gMQpoZGFhMDogMjYgNDFmMzAxZjAgMTUgMCAgT3RoZXIg
ICAgICAgICBOb25lICBBVEFQSSAgIFJlYXIgICAgICAgVW5rbm93biAxCmhkYWEwOiAyNyA0MTQ1
MDFmMCAxNSAwICBTUERJRi1vdXQgICAgIE5vbmUgIE9wdGljYWwgUmVhciAgICAgICBVbmtub3du
IDEKaGRhYTA6IDI4IDQxMzMwMWYwIDE1IDAgIENEICAgICAgICAgICAgTm9uZSAgQVRBUEkgICBS
ZWFyICAgICAgIFVua25vd24gMQpoZGFhMDogUGF0Y2hpbmcgd2lkZ2V0IGNhcHMgbmlkPTIzIDB4
MDA0MDAyMGIgLT4gMHgwMDQwMDAwYgpoZGFhMDogUGF0Y2hpbmcgd2lkZ2V0IGNhcHMgbmlkPTI2
IDB4MDA0MDAwMDAgLT4gMHgwMDcwMDAwMApoZGFhMDogUGF0Y2hlZCBwaW5zIGNvbmZpZ3VyYXRp
b246CmhkYWEwOiBuaWQgICAweCAgICBhcyBzZXEgZGV2aWNlICAgICAgIGNvbm4gIGphY2sgICAg
bG9jICAgICAgICBjb2xvciAgIG1pc2MKaGRhYTA6IDE3IDAyMjE0MDQwIDQgIDAgIEhlYWRwaG9u
ZXMgICAgSmFjayAgMS84ICAgICBGcm9udCAgICAgIEdyZWVuICAgMApoZGFhMDogMTggMDEwMTQw
MTAgMSAgMCAgTGluZS1vdXQgICAgICBKYWNrICAxLzggICAgIFJlYXIgICAgICAgR3JlZW4gICAw
CmhkYWEwOiAxOSA5OTEzMDFmMCAxNSAwICBTcGVha2VyICAgICAgIEZpeGVkIEFUQVBJICAgT25i
b2FyZCAgICBVbmtub3duIDEKaGRhYTA6IDIwIDAyYTE5MDIwIDIgIDAgIE1pYyAgICAgICAgICAg
SmFjayAgMS84ICAgICBGcm9udCAgICAgIFBpbmsgICAgMApoZGFhMDogMjEgMDE4MTMwMzAgMyAg
MCAgTGluZS1pbiAgICAgICBKYWNrICAxLzggICAgIFJlYXIgICAgICAgQmx1ZSAgICAwCmhkYWEw
OiAyMiA0MTMzMDFmMCAxNSAwICBDRCAgICAgICAgICAgIE5vbmUgIEFUQVBJICAgUmVhciAgICAg
ICBVbmtub3duIDEgRElTQQpoZGFhMDogMjMgNDFhNjAxZjAgMTUgMCAgTWljICAgICAgICAgICBO
b25lICBEaWdpdGFsIFJlYXIgICAgICAgVW5rbm93biAxIERJU0EKaGRhYTA6IDI3IDQxNDUwMWYw
IDE1IDAgIFNQRElGLW91dCAgICAgTm9uZSAgT3B0aWNhbCBSZWFyICAgICAgIFVua25vd24gMSBE
SVNBCmhkYWEwOiAyOCA0MTMzMDFmMCAxNSAwICBDRCAgICAgICAgICAgIE5vbmUgIEFUQVBJICAg
UmVhciAgICAgICBVbmtub3duIDEgRElTQQpoZGFhMDogNSBhc3NvY2lhdGlvbnMgZm91bmQ6Cmhk
YWEwOiBBc3NvY2lhdGlvbiAwICgxKSBvdXQ6CmhkYWEwOiAgUGluIG5pZD0xOCBzZXE9MApoZGFh
MDogQXNzb2NpYXRpb24gMSAoMikgaW46CmhkYWEwOiAgUGluIG5pZD0yMCBzZXE9MApoZGFhMDog
QXNzb2NpYXRpb24gMiAoMykgaW46CmhkYWEwOiAgUGluIG5pZD0yMSBzZXE9MApoZGFhMDogQXNz
b2NpYXRpb24gMyAoNCkgb3V0OgpoZGFhMDogIFBpbiBuaWQ9MTcgc2VxPTAKaGRhYTA6IEFzc29j
aWF0aW9uIDQgKDE1KSBvdXQ6CmhkYWEwOiAgUGluIG5pZD0xOSBzZXE9MApoZGFhMDogVHJhY2lu
ZyBhc3NvY2lhdGlvbiAwICgxKQpoZGFhMDogIFBpbiAxOCB0cmFjZWQgdG8gREFDIDMKaGRhYTA6
IEFzc29jaWF0aW9uIDAgKDEpIHRyYWNlIHN1Y2NlZWRlZApoZGFhMDogVHJhY2luZyBhc3NvY2lh
dGlvbiAxICgyKQpoZGFhMDogIFBpbiAyMCB0cmFjZWQgdG8gQURDIDgKaGRhYTA6IEFzc29jaWF0
aW9uIDEgKDIpIHRyYWNlIHN1Y2NlZWRlZApoZGFhMDogVHJhY2luZyBhc3NvY2lhdGlvbiAyICgz
KQpoZGFhMDogIFBpbiAyMSB0cmFjZWQgdG8gQURDIDkKaGRhYTA6IEFzc29jaWF0aW9uIDIgKDMp
IHRyYWNlIHN1Y2NlZWRlZApoZGFhMDogVHJhY2luZyBhc3NvY2lhdGlvbiAzICg0KQpoZGFhMDog
IFBpbiAxNyB0cmFjZWQgdG8gREFDIDQKaGRhYTA6IEFzc29jaWF0aW9uIDMgKDQpIHRyYWNlIHN1
Y2NlZWRlZApoZGFhMDogVHJhY2luZyBhc3NvY2lhdGlvbiA0ICgxNSkKaGRhYTA6ICBVbmFibGUg
dG8gdHJhY2UgcGluIDE5IHNlcSAwIHdpdGggbWluIG5pZCAwCmhkYWEwOiBBc3NvY2lhdGlvbiA0
ICgxNSkgdHJhY2UgZmFpbGVkCmhkYWEwOiBMb29raW5nIGZvciBhZGRpdGlvbmFsIERBQyBmb3Ig
YXNzb2NpYXRpb24gMCAoMSkKaGRhYTA6IExvb2tpbmcgZm9yIGFkZGl0aW9uYWwgQURDIGZvciBh
c3NvY2lhdGlvbiAxICgyKQpoZGFhMDogTG9va2luZyBmb3IgYWRkaXRpb25hbCBBREMgZm9yIGFz
c29jaWF0aW9uIDIgKDMpCmhkYWEwOiBMb29raW5nIGZvciBhZGRpdGlvbmFsIERBQyBmb3IgYXNz
b2NpYXRpb24gMyAoNCkKaGRhYTA6IFRyYWNpbmcgaW5wdXQgbW9uaXRvcgpoZGFhMDogVHJhY2lu
ZyBvdGhlciBpbnB1dCBtb25pdG9ycwpoZGFhMDogIFRyYWNpbmcgbmlkIDIwIHRvIG91dApoZGFh
MDogIG5pZCAyMCBpcyBpbnB1dCBtb25pdG9yCmhkYWEwOiAgVHJhY2luZyBuaWQgMjEgdG8gb3V0
CmhkYWEwOiAgbmlkIDIxIGlzIGlucHV0IG1vbml0b3IKaGRhYTA6IFRyYWNpbmcgYmVlcGVyCmhk
YWEwOiAgbmlkIDI2IHRyYWNlZCB0byBvdXQKaGRhYTA6IEZHIGNvbmZpZy9xdWlya3M6IGZvcmNl
c3RlcmVvIGl2cmVmNTAgaXZyZWY4MCBpdnJlZjEwMCBpdnJlZgpwY20wOiA8QW5hbG9nIERldmlj
ZXMgQUQxOTg0QSAoQW5hbG9nKT4gYXQgbmlkIDE4IGFuZCAyMCBvbiBoZGFhMApwY20wOiBQbGF5
YmFjazoKcGNtMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxIFBDTQpwY20wOiAgICAgICAg
IFBDTSBjYXA6IDB4MDAwZTA3ZmYgMTYgMjAgMjQgYml0cywgOCAxMSAxNiAyMiAzMiA0NCA0OCA4
OCA5NiAxNzYgMTkyIEtIegpwY20wOiAgICAgICAgICAgICBEQUM6IDMKcGNtMDoKcGNtMDogICAg
IG5pZD0xOCBbcGluOiBMaW5lLW91dCAoR3JlZW4gSmFjayldCnBjbTA6ICAgICAgICsgPC0gbmlk
PTEwIFthdWRpbyBtaXhlcl0gW3NyYzogcGNtLCBzcGVha2VyLCBsaW5lLCBtaWNdCnBjbTA6ICAg
ICAgICAgICAgICArIDwtIG5pZD0zMyBbYXVkaW8gc2VsZWN0b3JdIFtzcmM6IHBjbSwgc3BlYWtl
ciwgbGluZSwgbWljXQpwY20wOiAgICAgICAgICAgICAgICAgICAgICsgPC0gbmlkPTMyIFthdWRp
byBtaXhlcl0gW3NyYzogcGNtLCBzcGVha2VyLCBsaW5lLCBtaWNdCnBjbTA6ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICsgPC0gbmlkPTIwIFtwaW46IE1pYyAoUGluayBKYWNrKV0gW3NyYzog
bWljXQpwY20wOiAgICAgICAgICAgICAgICAgICAgICAgICAgICArIDwtIG5pZD0yMSBbcGluOiBM
aW5lLWluIChCbHVlIEphY2spXSBbc3JjOiBsaW5lXQpwY20wOiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICArIDwtIG5pZD0yNiBbYmVlcCB3aWRnZXRdIFtzcmM6IHNwZWFrZXJdCnBjbTA6ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICsgPC0gbmlkPTMgW2F1ZGlvIG91dHB1dF0gW3NyYzog
cGNtXQpwY20wOgpwY20wOiBSZWNvcmQ6CnBjbTA6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAw
MSBQQ00KcGNtMDogICAgICAgICBQQ00gY2FwOiAweDAwMGUwN2ZmIDE2IDIwIDI0IGJpdHMsIDgg
MTEgMTYgMjIgMzIgNDQgNDggODggOTYgMTc2IDE5MiBLSHoKcGNtMDogICAgICAgICAgICAgQURD
OiA4CnBjbTA6CnBjbTA6ICAgICBuaWQ9OCBbYXVkaW8gaW5wdXRdCnBjbTA6ICAgICAgICsgPC0g
bmlkPTEyIFthdWRpbyBzZWxlY3Rvcl0gW3NyYzogbWljXQpwY20wOiAgICAgICAgICAgICAgKyA8
LSBuaWQ9MjAgW3BpbjogTWljIChQaW5rIEphY2spXSBbc3JjOiBtaWNdCnBjbTA6CnBjbTA6IE1h
c3RlciBWb2x1bWUgKE9TUzogdm9sKTogLTQ2LzBkQgpwY20wOiAgICArLSBjdGwgIDEgKG5pZCAg
IDMgb3V0KTogICAgLTU4LzBkQiAoNDAgc3RlcHMpCnBjbTA6ICAgICstIGN0bCAgNiAobmlkICAx
MCBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0bCAxMyAobmlkICAxOCBpbiApOiAgICBtdXRl
CnBjbTA6ICAgICstIGN0bCAyMyAobmlkICAzMiBpbiAgIDApOiAtMzQvMTJkQiAoMzIgc3RlcHMp
ICsgbXV0ZQpwY20wOiAgICArLSBjdGwgMjQgKG5pZCAgMzIgaW4gICAxKTogLTM0LzEyZEIgKDMy
IHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0gY3RsIDI2IChuaWQgIDMyIGluICAgMyk6IC0zNC8x
MmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6ICAgICstIGN0bCAyOCAobmlkICAzMiBpbiAgIDUp
OiAtMzQvMTJkQiAoMzIgc3RlcHMpICsgbXV0ZQpwY20wOiAgICArLSBjdGwgMzAgKG5pZCAgMzMg
b3V0KTogICAgLTQ2LzBkQiAoMzIgc3RlcHMpICsgbXV0ZQpwY20wOgpwY20wOiBQQ00gVm9sdW1l
IChPU1M6IHBjbSk6IC01OC8wZEIKcGNtMDogICAgKy0gY3RsICAxIChuaWQgICAzIG91dCk6ICAg
IC01OC8wZEIgKDQwIHN0ZXBzKQpwY20wOiAgICArLSBjdGwgMjggKG5pZCAgMzIgaW4gICA1KTog
LTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDoKcGNtMDogTWljcm9waG9uZSBWb2x1bWUg
KE9TUzogbWljKTogMC8zMGRCCnBjbTA6ICAgICstIGN0bCAgOSAobmlkICAxMiBvdXQpOiAgICAt
NTgvMjJkQiAoNTUgc3RlcHMpICsgbXV0ZQpwY20wOiAgICArLSBjdGwgMTUgKG5pZCAgMjAgb3V0
KTogICAgMC8zMGRCICg0IHN0ZXBzKQpwY20wOiAgICArLSBjdGwgMjMgKG5pZCAgMzIgaW4gICAw
KTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDoKcGNtMDogTGluZS1pbiBWb2x1bWUg
KE9TUzogbGluZSkKcGNtMDogICAgKy0gY3RsIDI0IChuaWQgIDMyIGluICAgMSk6IC0zNC8xMmRC
ICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6CnBjbTA6IFNwZWFrZXIvQmVlcCBWb2x1bWUgKE9TUzog
c3BlYWtlcik6IC0zNC8wZEIKcGNtMDogICAgKy0gY3RsIDExIChuaWQgIDE2IG91dCk6ICAgIC00
NS8wZEIgKDE2IHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0gY3RsIDI2IChuaWQgIDMyIGluICAg
Myk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6CnBjbTA6IFJlY29yZGluZyBMZXZl
bCAoT1NTOiByZWMpOiAtNTgvMjJkQgpwY20wOiAgICArLSBjdGwgIDkgKG5pZCAgMTIgb3V0KTog
ICAgLTU4LzIyZEIgKDU1IHN0ZXBzKSArIG11dGUKcGNtMDoKcGNtMDogSW5wdXQgTW9uaXRvcmlu
ZyBMZXZlbCAoT1NTOiBpZ2Fpbik6IC0zNC8xMmRCCnBjbTA6ICAgICstIGN0bCAyMyAobmlkICAz
MiBpbiAgIDApOiAtMzQvMTJkQiAoMzIgc3RlcHMpICsgbXV0ZQpwY20wOiAgICArLSBjdGwgMjQg
KG5pZCAgMzIgaW4gICAxKTogLTM0LzEyZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDogICAgKy0g
Y3RsIDI2IChuaWQgIDMyIGluICAgMyk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6
CnBjbTA6IE1peGVyICJ2b2wiOgpwY20wOiBNaXhlciAicGNtIjoKcGNtMDogTWl4ZXIgInNwZWFr
ZXIiOgpwY20wOiBNaXhlciAibWljIjoKcGNtMDogTWl4ZXIgInJlYyI6CnBjbTA6IE1peGVyICJp
Z2FpbiI6CnBjbTA6IE1peGVyICJvZ2FpbiI6CnBjbTA6IFBsYXliYWNrIGNoYW5uZWwgc2V0IGlz
OiBGcm9udCBMZWZ0LCBGcm9udCBSaWdodCwKcGNtMDogUGxheWJhY2sgY2hhbm5lbCBtYXRyaXgg
aXM6IDIuMCAoZGlzY29ubmVjdGVkKQpwY20wOiBSZWNvcmRpbmcgY2hhbm5lbCBzZXQgaXM6IEZy
b250IExlZnQsIEZyb250IFJpZ2h0LApwY20wOiBSZWNvcmRpbmcgY2hhbm5lbCBtYXRyaXggaXM6
IDIuMCAoZGlzY29ubmVjdGVkKQpwY20xOiA8QW5hbG9nIERldmljZXMgQUQxOTg0QSAoQW5hbG9n
KT4gYXQgbmlkIDE3IGFuZCAyMSBvbiBoZGFhMApwY20xOiBQbGF5YmFjazoKcGNtMTogICAgICBT
dHJlYW0gY2FwOiAweDAwMDAwMDAxIFBDTQpwY20xOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTA3
ZmYgMTYgMjAgMjQgYml0cywgOCAxMSAxNiAyMiAzMiA0NCA0OCA4OCA5NiAxNzYgMTkyIEtIegpw
Y20xOiAgICAgICAgICAgICBEQUM6IDQKcGNtMToKcGNtMTogICAgIG5pZD0xNyBbcGluOiBIZWFk
cGhvbmVzIChHcmVlbiBKYWNrKV0KcGNtMTogICAgICAgKyA8LSBuaWQ9NyBbYXVkaW8gbWl4ZXJd
IFtzcmM6IHBjbV0KcGNtMTogICAgICAgICAgICAgICsgPC0gbmlkPTM0IFthdWRpbyBzZWxlY3Rv
cl0gW3NyYzogcGNtXQpwY20xOiAgICAgICAgICAgICAgICAgICAgICsgPC0gbmlkPTQgW2F1ZGlv
IG91dHB1dF0gW3NyYzogcGNtXQpwY20xOgpwY20xOiBSZWNvcmQ6CnBjbTE6ICAgICAgU3RyZWFt
IGNhcDogMHgwMDAwMDAwMSBQQ00KcGNtMTogICAgICAgICBQQ00gY2FwOiAweDAwMGUwN2ZmIDE2
IDIwIDI0IGJpdHMsIDggMTEgMTYgMjIgMzIgNDQgNDggODggOTYgMTc2IDE5MiBLSHoKcGNtMTog
ICAgICAgICAgICAgQURDOiA5CnBjbTE6CnBjbTE6ICAgICBuaWQ9OSBbYXVkaW8gaW5wdXRdCnBj
bTE6ICAgICAgICsgPC0gbmlkPTEzIFthdWRpbyBzZWxlY3Rvcl0gW3NyYzogbGluZV0KcGNtMTog
ICAgICAgICAgICAgICsgPC0gbmlkPTIxIFtwaW46IExpbmUtaW4gKEJsdWUgSmFjayldIFtzcmM6
IGxpbmVdCnBjbTE6CnBjbTE6IE1hc3RlciBWb2x1bWUgKE9TUzogdm9sKTogLTU4LzBkQgpwY20x
OiAgICArLSBjdGwgIDIgKG5pZCAgIDQgb3V0KTogICAgLTU4LzBkQiAoNDAgc3RlcHMpCnBjbTE6
ICAgICstIGN0bCAgMyAobmlkICAgNyBpbiAgIDApOiBtdXRlCnBjbTE6ICAgICstIGN0bCAxMiAo
bmlkICAxNyBpbiApOiAgICBtdXRlCnBjbTE6CnBjbTE6IFBDTSBWb2x1bWUgKE9TUzogcGNtKTog
LTU4LzBkQgpwY20xOiAgICArLSBjdGwgIDIgKG5pZCAgIDQgb3V0KTogICAgLTU4LzBkQiAoNDAg
c3RlcHMpCnBjbTE6ICAgICstIGN0bCAgMyAobmlkICAgNyBpbiAgIDApOiBtdXRlCnBjbTE6ICAg
ICstIGN0bCAxMiAobmlkICAxNyBpbiApOiAgICBtdXRlCnBjbTE6CnBjbTE6IExpbmUtaW4gVm9s
dW1lIChPU1M6IGxpbmUpOiAwLzMwZEIKcGNtMTogICAgKy0gY3RsIDEwIChuaWQgIDEzIG91dCk6
ICAgIC01OC8yMmRCICg1NSBzdGVwcykgKyBtdXRlCnBjbTE6ICAgICstIGN0bCAxNiAobmlkICAy
MSBvdXQpOiAgICAwLzMwZEIgKDQgc3RlcHMpCnBjbTE6CnBjbTE6IFJlY29yZGluZyBMZXZlbCAo
T1NTOiByZWMpOiAtNTgvMjJkQgpwY20xOiAgICArLSBjdGwgMTAgKG5pZCAgMTMgb3V0KTogICAg
LTU4LzIyZEIgKDU1IHN0ZXBzKSArIG11dGUKcGNtMToKcGNtMTogTWl4ZXIgInZvbCI6CnBjbTE6
IE1peGVyICJwY20iOgpwY20xOiBNaXhlciAibGluZSI6CnBjbTE6IE1peGVyICJyZWMiOgpwY20x
OiBQbGF5YmFjayBjaGFubmVsIHNldCBpczogRnJvbnQgTGVmdCwgRnJvbnQgUmlnaHQsCnBjbTE6
IFBsYXliYWNrIGNoYW5uZWwgbWF0cml4IGlzOiAyLjAgKGRpc2Nvbm5lY3RlZCkKcGNtMTogUmVj
b3JkaW5nIGNoYW5uZWwgc2V0IGlzOiBGcm9udCBMZWZ0LCBGcm9udCBSaWdodCwKcGNtMTogUmVj
b3JkaW5nIGNoYW5uZWwgbWF0cml4IGlzOiAyLjAgKGRpc2Nvbm5lY3RlZCkKdXNidXMwOiAxMk1i
cHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4w
CnVzYnVzMjogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMzOiA0ODBNYnBzIEhpZ2gg
U3BlZWQgVVNCIHYyLjAKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1YjA6IDxJbnRlbCBV
SENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMx
CnVnZW4wLjE6IDxJbnRlbD4gYXQgdXNidXMwCnVodWIxOiA8SW50ZWwgVUhDSSByb290IEhVQiwg
Y2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMi4xOiA8SW50
ZWw+IGF0IHVzYnVzMgp1aHViMjogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2
IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdWdlbjMuMTogPEludGVsPiBhdCB1c2J1czMK
dWh1YjM6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFk
ZHIgMT4gb24gdXNidXMzCnVzYnVzNDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM1
OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czY6IDEyTWJwcyBGdWxsIFNwZWVkIFVT
QiB2MS4wCnVnZW40LjE6IDxJbnRlbD4gYXQgdXNidXM0CnVodWI0OiA8SW50ZWwgVUhDSSByb290
IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNAp1Z2VuNS4x
OiA8SW50ZWw+IGF0IHVzYnVzNQp1aHViNTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkv
MCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czUKdWdlbjYuMTogPEludGVsPiBhdCB1
c2J1czYKdWh1YjY6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu
MDAsIGFkZHIgMT4gb24gdXNidXM2CnVzYnVzNzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4w
CmFoY2ljaDA6IEFIQ0kgcmVzZXQuLi4KYWhjaWNoMDogU0FUQSBjb25uZWN0IHRpbWU9MTAwdXMg
c3RhdHVzPTAwMDAwMTIzCnVnZW43LjE6IDxJbnRlbD4gYXQgdXNidXM3CnVodWI3OiA8SW50ZWwg
RUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVz
NwphaGNpY2gwOiBBSENJIHJlc2V0OiBkZXZpY2UgZm91bmQKYWhjaWNoMDogQUhDSSByZXNldDog
ZGV2aWNlIHJlYWR5IGFmdGVyIDBtcwphaGNpY2gxOiBBSENJIHJlc2V0Li4uCmFoY2ljaDE6IFNB
VEEgY29ubmVjdCB0aW1lPTEwMHVzIHN0YXR1cz0wMDAwMDEyMwphaGNpY2gxOiBBSENJIHJlc2V0
OiBkZXZpY2UgZm91bmQKYWhjaWNoMTogQUhDSSByZXNldDogZGV2aWNlIHJlYWR5IGFmdGVyIDBt
cwphaGNpY2gyOiBBSENJIHJlc2V0Li4uCmFoY2ljaDI6IFNBVEEgY29ubmVjdCB0aW1lPTEwMDB1
cyBzdGF0dXM9MDAwMDAxMTMKYWhjaWNoMjogQUhDSSByZXNldDogZGV2aWNlIGZvdW5kCmFoY2lj
aDI6IEFIQ0kgcmVzZXQ6IGRldmljZSByZWFkeSBhZnRlciAwbXMKYWhjaWNoMzogQUhDSSByZXNl
dC4uLgphaGNpY2gzOiBTQVRBIG9mZmxpbmUgc3RhdHVzPTAwMDAwMDA0CmFoY2ljaDM6IEFIQ0kg
cmVzZXQ6IGRldmljZSBub3QgZm91bmQKYWhjaWNoNDogQUhDSSByZXNldC4uLgphaGNpY2g0OiBT
QVRBIG9mZmxpbmUgc3RhdHVzPTAwMDAwMDA0CmFoY2ljaDQ6IEFIQ0kgcmVzZXQ6IGRldmljZSBu
b3QgZm91bmQKYWhjaWNoNTogQUhDSSByZXNldC4uLgphaGNpY2g1OiBTQVRBIGNvbm5lY3QgdGlt
ZW91dCB0aW1lPTEwMDAwdXMgc3RhdHVzPTAwMDAwMDAwCmFoY2ljaDU6IEFIQ0kgcmVzZXQ6IGRl
dmljZSBub3QgZm91bmQKc2VzMCBhdCBhaGNpZW0wIGJ1cyAwIHNjYnVzNiB0YXJnZXQgMCBsdW4g
MApzZXMwOiA8QUhDSSBTR1BJTyBFbmNsb3N1cmUgMS4wMCAwMDAxPiBTRU1CIFMtRS1TIDIuMDAg
ZGV2aWNlCnNlczA6IFNFTUIgU0VTIERldmljZQphZGEwIGF0IGFoY2ljaDAgYnVzIDAgc2NidXMw
IHRhcmdldCAwIGx1biAwCmFkYTA6IDxTVDUwMERNMDAyLTFCRDE0MiBLQzQ1PiBBVEEtOCBTQVRB
IDMueCBkZXZpY2UKYWRhMDogU2VyaWFsIE51bWJlciBaM1QzRkpYTAphZGEwOiAzMDAuMDAwTUIv
cyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJieXRlcykKYWRhMDogQ29tbWFu
ZCBRdWV1ZWluZyBlbmFibGVkCmFkYTA6IDQ3Njk0ME1CICg5NzY3NzMxNjggNTEyIGJ5dGUgc2Vj
dG9yczogMTZIIDYzUy9UIDE2MzgzQykKc2VzMDogR2VuZXJhdGlvbiBDb2RlIDB4MCBoYXMgMSBT
dWJFbmNsb3N1cmVzCnNlczA6ICBTdWJFbmNsb3N1cmUgSUQgMCwgMSBUeXBlcyBXaXRoIHRoaXMg
SUQsIERlc2NyaXB0b3IgTGVuZ3RoIDM2LCBvZmZzZXQgOApzZXMwOiBXV046IDAKc2VzMDogIFR5
cGUgRGVzY1swXTogVHlwZSAweDE3LCBNYXhFbHQgNiwgSW4gU3ViZW5jIDAsIFRleHQgTGVuZ3Ro
IDA6CkdFT006IG5ldyBkaXNrIGFkYTAKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwg
c2VsZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJl
ZAphZGEwOiBxdWlya3M9MHgxPDRLPgphZGEwOiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDQK
dWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmFkYTEgYXQgYWhj
aWNoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAKYWRhMTogPFNUNTAwRE0wMDItMUJEMTQy
IEtDNDU+IEFUQS04IFNBVEEgMy54IGRldmljZQphZGExOiBTZXJpYWwgTnVtYmVyIFozVDNIQkVT
CmFkYTE6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5
dGVzKQphZGExOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhMTogNDc2OTQwTUIgKDk3Njc3
MzE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQp1aHViNDogMiBwb3J0cyB3
aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjU6IDIgcG9ydHMgd2l0aCAyIHJlbW92
YWJsZSwgc2VsZiBwb3dlcmVkCmFkYTE6IHF1aXJrcz0weDE8NEs+CmFkYTE6IFByZXZpb3VzbHkg
d2FzIGtub3duIGFzIGFkNgp1aHViNjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBv
d2VyZWQKcGFzczAgYXQgYWhjaWNoMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKcGFzczA6
IDxTVDUwMERNMDAyLTFCRDE0MiBLQzQ1PiBBVEEtOCBTQVRBIDMueCBkZXZpY2UKcGFzczA6IFNl
cmlhbCBOdW1iZXIgWjNUM0ZKWEwKcGFzczA6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAy
LngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQpwYXNzMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVk
CnBhc3MxIGF0IGFoY2ljaDEgYnVzIDAgc2NidXMxIHRhcmdldCAwIGx1biAwCnBhc3MxOiA8U1Q1
MDBETTAwMi0xQkQxNDIgS0M0NT4gQVRBLTggU0FUQSAzLnggZGV2aWNlCnBhc3MxOiBTZXJpYWwg
TnVtYmVyIFozVDNIQkVTCnBhc3MxOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBV
RE1BNiwgUElPIDgxOTJieXRlcykKcGFzczE6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApwYXNz
MiBhdCBhaGNpY2gyIGJ1cyAwIHNjYnVzMiB0YXJnZXQgMCBsdW4gMApwYXNzMjogPFRTU1Rjb3Jw
IERWRCstUlcgU0gtMjE2QkIgRDEwMD4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNlCnBh
c3MyOiBTZXJpYWwgTnVtYmVyIFI4VTQ2R0FDNjAxNVdGCnBhc3MyOiAxNTAuMDAwTUIvcyB0cmFu
c2ZlcnMgKFNBVEEgMS54LCBVRE1BNSwgQVRBUEkgMTJieXRlcywgUElPIDgxOTJieXRlcykKcGFz
czMgYXQgYWhjaWVtMCBidXMgMCBzY2J1czYgdGFyZ2V0IDAgbHVuIDAKcGFzczM6IDxBSENJIFNH
UElPIEVuY2xvc3VyZSAxLjAwIDAwMDE+IFNFTUIgUy1FLVMgMi4wMCBkZXZpY2UKcmFuZG9tOiB1
bmJsb2NraW5nIGRldmljZS4KTmV0dnNjIGluaXRpYWxpemluZy4uLiBkb25lIQpTTVA6IEFQIENQ
VSAjMSBMYXVuY2hlZCEKY3B1MSBBUCBYRU4gUFYgTEFQSUMKU01QOiBBUCBDUFUgIzQgTGF1bmNo
ZWQhCmNwdTQgQVAgWEVOIFBWIExBUElDClNNUDogQVAgQ1BVICM3IExhdW5jaGVkIQpjcHU3IEFQ
IFhFTiBQViBMQVBJQwpTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCEKY3B1MiBBUCBYRU4gUFYgTEFQ
SUMKU01QOiBBUCBDUFUgIzUgTGF1bmNoZWQhCmNwdTUgQVAgWEVOIFBWIExBUElDClNNUDogQVAg
Q1BVICMzIExhdW5jaGVkIQpjcHUzIEFQIFhFTiBQViBMQVBJQwpTTVA6IEFQIENQVSAjNiBMYXVu
Y2hlZCEKY3B1NiBBUCBYRU4gUFYgTEFQSUMKVFNDIHRpbWVjb3VudGVyIGRpc2NhcmRzIGxvd2Vy
IDEgYml0KHMpClRpbWVjb3VudGVyICJUU0MtbG93IiBmcmVxdWVuY3kgMTUzMzM5MDg4MyBIeiBx
dWFsaXR5IC0xMDAKV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVj
ZWQgcGVyZm9ybWFuY2UuCmNkMCBhdCBhaGNpY2gyIGJ1cyAwIHNjYnVzMiB0YXJnZXQgMCBsdW4g
MApjZDA6IDxUU1NUY29ycCBEVkQrLVJXIFNILTIxNkJCIEQxMDA+IFJlbW92YWJsZSBDRC1ST00g
U0NTSS0wIGRldmljZQpjZDA6IFNlcmlhbCBOdW1iZXIgUjhVNDZHQUM2MDE1V0YKY2QwOiAxNTAu
MDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMS54LCBVRE1BNSwgQVRBUEkgMTJieXRlcywgUElPIDgx
OTJieXRlcykKY2QwOiBBdHRlbXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJF
QURZLCBNZWRpdW0gbm90IHByZXNlbnQgLSB0cmF5IGNsb3NlZApHRU9NOiBuZXcgZGlzayBhZGEx
CkdFT006IG5ldyBkaXNrIGNkMApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czcgdXNidXMz
ClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNyB1c2J1czMKdWh1YjM6IDYgcG9ydHMgd2l0
aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI3OiA2IHBvcnRzIHdpdGggNiByZW1vdmFi
bGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czMKVHJ5aW5nIHRv
IG1vdW50IHJvb3QgZnJvbSB6ZnM6dGFuay9yb290IFtdLi4uCmJnZTA6IGxpbmsgc3RhdGUgY2hh
bmdlZCB0byBVUAp1Z2VuMS4yOiA8REVMTD4gYXQgdXNidXMxCnVrYmQwOiA8REVMTCBEZWxsIFVT
QiBFbnRyeSBLZXlib2FyZCwgY2xhc3MgMC8wLCByZXYgMS4xMC8xLjc4LCBhZGRyIDI+IG9uIHVz
YnVzMQprYmQyIGF0IHVrYmQwCmtiZDI6IHVrYmQwLCBnZW5lcmljICgwKSwgY29uZmlnOjB4MCwg
ZmxhZ3M6MHgzZDAwMDAKc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQKdWdlbjEuMzogPERF
TEw+IGF0IHVzYnVzMQpHRU9NX1BBUlQ6IHBhcnRpdGlvbiAyIGlzIG5vdCBhbGlnbmVkIG9uIDgx
OTIgYnl0ZXMKR0VPTV9QQVJUOiBwYXJ0aXRpb24gMiBpcyBub3QgYWxpZ25lZCBvbiA4MTkyIGJ5
dGVzCkdFT01fUEFSVDogcGFydGl0aW9uIDEgaXMgbm90IGFsaWduZWQgb24gODE5MiBieXRlcwpH
RU9NX1BBUlQ6IHBhcnRpdGlvbiAyIGlzIG5vdCBhbGlnbmVkIG9uIDgxOTIgYnl0ZXMKR0VPTV9Q
QVJUOiBwYXJ0aXRpb24gMyBpcyBub3QgYWxpZ25lZCBvbiA4MTkyIGJ5dGVzCkdFT01fUEFSVDog
cGFydGl0aW9uIDEgaXMgbm90IGFsaWduZWQgb24gODE5MiBieXRlcwpHRU9NX1BBUlQ6IHBhcnRp
dGlvbiAyIGlzIG5vdCBhbGlnbmVkIG9uIDgxOTIgYnl0ZXMKR0VPTV9QQVJUOiBwYXJ0aXRpb24g
MyBpcyBub3QgYWxpZ25lZCBvbiA4MTkyIGJ5dGVzCkdFT01fUEFSVDogcGFydGl0aW9uIDEgaXMg
bm90IGFsaWduZWQgb24gODE5MiBieXRlcwpHRU9NX1BBUlQ6IHBhcnRpdGlvbiAyIGlzIG5vdCBh
bGlnbmVkIG9uIDgxOTIgYnl0ZXMKR0VPTV9QQVJUOiBwYXJ0aXRpb24gMyBpcyBub3QgYWxpZ25l
ZCBvbiA4MTkyIGJ5dGVzCkdFT01fUEFSVDogcGFydGl0aW9uIDEgaXMgbm90IGFsaWduZWQgb24g
ODE5MiBieXRlcwpHRU9NX1BBUlQ6IHBhcnRpdGlvbiAyIGlzIG5vdCBhbGlnbmVkIG9uIDgxOTIg
Ynl0ZXMKR0VPTV9QQVJUOiBwYXJ0aXRpb24gMyBpcyBub3QgYWxpZ25lZCBvbiA4MTkyIGJ5dGVz
CkdFT01fUEFSVDogcGFydGl0aW9uIDIgaXMgbm90IGFsaWduZWQgb24gODE5MiBieXRlcwpTZXR0
aW5nIGhvc3R1dWlkOiA0NDQ1NGM0Yy0zMzAwLTEwNTctODAzNi1iM2MwNGY0NzM1NGEuClNldHRp
bmcgaG9zdGlkOiAweDAzM2NjNzI1LgpFbnRyb3B5IGhhcnZlc3Rpbmc6c3lzY3RsOiB1bmtub3du
IG9pZCAna2Vybi5yYW5kb20uc3lzLmhhcnZlc3QuaW50ZXJydXB0JzogTm8gc3VjaCBmaWxlIG9y
IGRpcmVjdG9yeQogaW50ZXJydXB0c3N5c2N0bDogdW5rbm93biBvaWQgJ2tlcm4ucmFuZG9tLnN5
cy5oYXJ2ZXN0LmV0aGVybmV0JzogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQogZXRoZXJuZXRz
eXNjdGw6IHVua25vd24gb2lkICdrZXJuLnJhbmRvbS5zeXMuaGFydmVzdC5wb2ludF90b19wb2lu
dCc6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKIHBvaW50X3RvX3BvaW50c3lzY3RsOiB1bmtu
b3duIG9pZCAna2Vybi5yYW5kb20uc3lzLmhhcnZlc3Quc3dpJzogTm8gc3VjaCBmaWxlIG9yIGRp
cmVjdG9yeQogc3dpLgpTdGFydGluZyBmaWxlIHN5c3RlbSBjaGVja3M6Ck1vdW50aW5nIGxvY2Fs
IGZpbGUgc3lzdGVtczouCkxvYWRpbmcga2VybmVsIG1vZHVsZXM6CldyaXRpbmcgZW50cm9weSBm
aWxlOi4KL2V0Yy9yYzogV0FSTklORzogJGhvc3RuYW1lIGlzIG5vdCBzZXQgLS0gc2VlIHJjLmNv
bmYoNSkuCmJyaWRnZTA6IGJwZiBhdHRhY2hlZApicmlkZ2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAw
MjowMzozYzpjNzoyNTowMApicmlkZ2UxOiBicGYgYXR0YWNoZWQKYnJpZGdlMTogRXRoZXJuZXQg
YWRkcmVzczogMDI6MDM6M2M6Yzc6MjU6MDEKQ3JlYXRlZCBjbG9uZSBpbnRlcmZhY2VzOiBicmlk
Z2UwIGJyaWRnZTEuCmJnZTA6IERpc2FibGluZyBmYXN0Ym9vdApiZ2UwOiBEaXNhYmxpbmcgZmFz
dGJvb3QKYmdlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KYmdlMDogcHJvbWlzY3VvdXMg
bW9kZSBlbmFibGVkCmJyaWRnZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dOClN0YXJ0aW5n
IGRoY2xpZW50LgpESENQUkVRVUVTVCBvbiBicmlkZ2UwIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0
IDY3CmVtMTogTGluayBpcyB1cCAxMDAwIE1icHMgRnVsbCBEdXBsZXgKZW0xOiBsaW5rIHN0YXRl
IGNoYW5nZWQgdG8gVVAKYmdlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCmJyaWRnZTA6IGxp
bmsgc3RhdGUgY2hhbmdlZCB0byBVUApESENQUkVRVUVTVCBvbiBicmlkZ2UwIHRvIDI1NS4yNTUu
MjU1LjI1NSBwb3J0IDY3CkRIQ1BBQ0sgZnJvbSAxNzIuMTYuMS4xCmJvdW5kIHRvIDE3Mi4xNi4x
LjIwIC0tIHJlbmV3YWwgaW4gMjE0NzQ4MzY0NyBzZWNvbmRzLgplbTE6IHByb21pc2N1b3VzIG1v
ZGUgZW5hYmxlZApicmlkZ2UxOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKU3RhcnRpbmcgZGhj
bGllbnQuCkRIQ1BSRVFVRVNUIG9uIGJyaWRnZTEgdG8gMjU1LjI1NS4yNTUuMjU1IHBvcnQgNjcK
REhDUFJFUVVFU1Qgb24gYnJpZGdlMSB0byAyNTUuMjU1LjI1NS4yNTUgcG9ydCA2NwpESENQRElT
Q09WRVIgb24gYnJpZGdlMSB0byAyNTUuMjU1LjI1NS4yNTUgcG9ydCA2NyBpbnRlcnZhbCA3CkRI
Q1BESVNDT1ZFUiBvbiBicmlkZ2UxIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3IGludGVydmFs
IDIxCkRIQ1BESVNDT1ZFUiBvbiBicmlkZ2UxIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3IGlu
dGVydmFsIDE2CkRIQ1BESVNDT1ZFUiBvbiBicmlkZ2UxIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0
IDY3IGludGVydmFsIDExCkRIQ1BESVNDT1ZFUiBvbiBicmlkZ2UxIHRvIDI1NS4yNTUuMjU1LjI1
NSBwb3J0IDY3IGludGVydmFsIDUKTm8gREhDUE9GRkVSUyByZWNlaXZlZC4KVHJ5aW5nIHJlY29y
ZGVkIGxlYXNlIDE3Mi4xNi4xLjEzOApib3VuZDogcmVuZXdhbCBpbiA0MzAyMCBzZWNvbmRzLgpT
dGFydGluZyBOZXR3b3JrOiBsbzAgYmNlMCBiY2UxIGVtMCBlbTEgYmdlMCBicmlkZ2UwIGJyaWRn
ZTEuCmxvMDogZmxhZ3M9ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FTVD4gbWV0cmlj
IDAgbXR1IDE2Mzg0CglvcHRpb25zPTYwMDAwMzxSWENTVU0sVFhDU1VNLFJYQ1NVTV9JUFY2LFRY
Q1NVTV9JUFY2PgoJaW5ldDYgOjoxIHByZWZpeGxlbiAxMjgKCWluZXQ2IGZlODA6OjElbG8wIHBy
ZWZpeGxlbiA2NCBzY29wZWlkIDB4NgoJaW5ldCAxMjcuMC4wLjEgbmV0bWFzayAweGZmMDAwMDAw
CgluZDYgb3B0aW9ucz0yMTxQRVJGT1JNTlVELEFVVE9fTElOS0xPQ0FMPgpiY2UwOiBmbGFncz04
ODAyPEJST0FEQ0FTVCxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKCW9wdGlv
bnM9YzAxYmI8UlhDU1VNLFRYQ1NVTSxWTEFOX01UVSxWTEFOX0hXVEFHR0lORyxKVU1CT19NVFUs
VkxBTl9IV0NTVU0sVFNPNCxWTEFOX0hXVFNPLExJTktTVEFURT4KCWV0aGVyIDAwOjEwOjE4OmUw
OjA1OjI4CgluZDYgb3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9D
QUw+CgltZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdApiY2UxOiBmbGFncz04ODAyPEJST0FEQ0FT
VCxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKCW9wdGlvbnM9YzAxYmI8UlhD
U1VNLFRYQ1NVTSxWTEFOX01UVSxWTEFOX0hXVEFHR0lORyxKVU1CT19NVFUsVkxBTl9IV0NTVU0s
VFNPNCxWTEFOX0hXVFNPLExJTktTVEFURT4KCWV0aGVyIDAwOjEwOjE4OmUwOjA1OjJhCgluZDYg
b3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+CgltZWRpYTog
RXRoZXJuZXQgYXV0b3NlbGVjdAplbTA6IGZsYWdzPThjMDI8QlJPQURDQVNULE9BQ1RJVkUsU0lN
UExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTQwMTliPFJYQ1NVTSxU
WENTVU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0sVFNPNCxWTEFOX0hXVFNP
PgoJZXRoZXIgMDA6MWI6MjE6YzY6ZTk6YWUKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZE
SVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0CglzdGF0
dXM6IG5vIGNhcnJpZXIKZW0xOiBmbGFncz04OTQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFBST01J
U0MsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTQwMTliPFJY
Q1NVTSxUWENTVU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0sVFNPNCxWTEFO
X0hXVFNPPgoJZXRoZXIgMDA6MWI6MjE6YzY6ZTk6YWYKCWluZXQ2IGZlODA6OjIxYjoyMWZmOmZl
YzY6ZTlhZiVlbTEgcHJlZml4bGVuIDY0IHRlbnRhdGl2ZSBzY29wZWlkIDB4NAoJbmQ2IG9wdGlv
bnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgoJbWVkaWE6IEV0aGVy
bmV0IGF1dG9zZWxlY3QgKDEwMDBiYXNlVCA8ZnVsbC1kdXBsZXg+KQoJc3RhdHVzOiBhY3RpdmUK
YmdlMDogZmxhZ3M9ODk0MzxVUCxCUk9BRENBU1QsUlVOTklORyxQUk9NSVNDLFNJTVBMRVgsTVVM
VElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAoJb3B0aW9ucz1jMDE5YjxSWENTVU0sVFhDU1VNLFZM
QU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdDU1VNLFRTTzQsVkxBTl9IV1RTTyxMSU5LU1RB
VEU+CglldGhlciBkNDphZTo1MjpjMTpkNDozZAoJaW5ldDYgZmU4MDo6ZDZhZTo1MmZmOmZlYzE6
ZDQzZCViZ2UwIHByZWZpeGxlbiA2NCB0ZW50YXRpdmUgc2NvcGVpZCAweDUKCW5kNiBvcHRpb25z
PTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KCW1lZGlhOiBFdGhlcm5l
dCBhdXRvc2VsZWN0ICgxMDAwYmFzZVQgPGZ1bGwtZHVwbGV4PikKCXN0YXR1czogYWN0aXZlCmJy
aWRnZTA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+
IG1ldHJpYyAwIG10dSAxNTAwCglldGhlciBkNDphZTo1MjpjMTpkNDozZAoJaW5ldCAxNzIuMTYu
MS4yMCBuZXRtYXNrIDB4ZmZmZmZmMDAgYnJvYWRjYXN0IDE3Mi4xNi4xLjI1NQoJbmQ2IG9wdGlv
bnM9OTxQRVJGT1JNTlVELElGRElTQUJMRUQ+CglpZCAwMDowMDowMDowMDowMDowMCBwcmlvcml0
eSAzMjc2OCBoZWxsb3RpbWUgMiBmd2RkZWxheSAxNQoJbWF4YWdlIDIwIGhvbGRjbnQgNiBwcm90
byByc3RwIG1heGFkZHIgMjAwMCB0aW1lb3V0IDEyMDAKCXJvb3QgaWQgMDA6MDA6MDA6MDA6MDA6
MDAgcHJpb3JpdHkgMzI3NjggaWZjb3N0IDAgcG9ydCAwCgltZW1iZXI6IGJnZTAgZmxhZ3M9MTQz
PExFQVJOSU5HLERJU0NPVkVSLEFVVE9FREdFLEFVVE9QVFA+CgkgICAgICAgIGlmbWF4YWRkciAw
IHBvcnQgNSBwcmlvcml0eSAxMjggcGF0aCBjb3N0IDU1CmJyaWRnZTE6IGZsYWdzPTg4NDM8VVAs
QlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCgll
dGhlciAwMDoxYjoyMTpjNjplOTphZgoJbmQ2IG9wdGlvbnM9OTxQRVJGT1JNTlVELElGRElTQUJM
RUQ+CglpZCAwMDowMDowMDowMDowMDowMCBwcmlvcml0eSAzMjc2OCBoZWxsb3RpbWUgMiBmd2Rk
ZWxheSAxNQoJbWF4YWdlIDIwIGhvbGRjbnQgNiBwcm90byByc3RwIG1heGFkZHIgMjAwMCB0aW1l
b3V0IDEyMDAKCXJvb3QgaWQgMDA6MDA6MDA6MDA6MDA6MDAgcHJpb3JpdHkgMzI3NjggaWZjb3N0
IDAgcG9ydCAwCgltZW1iZXI6IGVtMSBmbGFncz0xNDM8TEVBUk5JTkcsRElTQ09WRVIsQVVUT0VE
R0UsQVVUT1BUUD4KCSAgICAgICAgaWZtYXhhZGRyIDAgcG9ydCA0IHByaW9yaXR5IDEyOCBwYXRo
IGNvc3QgMjAwMDAKU3RhcnRpbmcgZGV2ZC4KU3RhcnRpbmcgTmV0d29yazogYmNlMC4KYmNlMDog
ZmxhZ3M9ODgwMjxCUk9BRENBU1QsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAw
CglvcHRpb25zPWMwMWJiPFJYQ1NVTSxUWENTVU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsSlVN
Qk9fTVRVLFZMQU5fSFdDU1VNLFRTTzQsVkxBTl9IV1RTTyxMSU5LU1RBVEU+CglldGhlciAwMDox
MDoxODplMDowNToyOAoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9f
TElOS0xPQ0FMPgoJbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QKU3RhcnRpbmcgTmV0d29yazog
YmNlMS4KYmNlMTogZmxhZ3M9ODgwMjxCUk9BRENBU1QsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJp
YyAwIG10dSAxNTAwCglvcHRpb25zPWMwMWJiPFJYQ1NVTSxUWENTVU0sVkxBTl9NVFUsVkxBTl9I
V1RBR0dJTkcsSlVNQk9fTVRVLFZMQU5fSFdDU1VNLFRTTzQsVkxBTl9IV1RTTyxMSU5LU1RBVEU+
CglldGhlciAwMDoxMDoxODplMDowNToyYQoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJ
U0FCTEVELEFVVE9fTElOS0xPQ0FMPgoJbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QKU3RhcnRp
bmcgTmV0d29yazogZW0wLgplbTA6IGZsYWdzPThjMDI8QlJPQURDQVNULE9BQ1RJVkUsU0lNUExF
WCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPTQwMTliPFJYQ1NVTSxUWENT
VU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0sVFNPNCxWTEFOX0hXVFNPPgoJ
ZXRoZXIgMDA6MWI6MjE6YzY6ZTk6YWUKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNB
QkxFRCxBVVRPX0xJTktMT0NBTD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0CglzdGF0dXM6
IG5vIGNhcnJpZXIKYmdlMDogd2F0Y2hkb2cgdGltZW91dCAtLSByZXNldHRpbmcKYmdlMDogRGlz
YWJsaW5nIGZhc3Rib290CmJnZTA6IGxpbmsgRE9XTgpiZ2UwOiBEaXNhYmxpbmcgZmFzdGJvb3QK
YmdlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KYnJpZGdlMDogbGluayBzdGF0ZSBjaGFu
Z2VkIHRvIERPV04KYWRkIG5ldCBmZTgwOjo6IGdhdGV3YXkgOjoxCmFkZCBuZXQgZmYwMjo6OiBn
YXRld2F5IDo6MQphZGQgbmV0IDo6ZmZmZjowLjAuMC4wOiBnYXRld2F5IDo6MQphZGQgbmV0IDo6
MC4wLjAuMDogZ2F0ZXdheSA6OjEKRUxGIGxkY29uZmlnIHBhdGg6IC9saWIgL3Vzci9saWIgL3Vz
ci9saWIvY29tcGF0IC91c3IvbG9jYWwvbGliIC91c3IvbG9jYWwvbGliL2djYzQ3CjMyLWJpdCBj
b21wYXRpYmlsaXR5IGxkY29uZmlnIHBhdGg6IC91c3IvbGliMzIKQ3JlYXRpbmcgYW5kL29yIHRy
aW1taW5nIGxvZyBmaWxlcy4KU3RhcnRpbmcgc3lzbG9nZC4KQ2xlYXJpbmcgL3RtcCAoWCByZWxh
dGVkKS4KQ2xlYW5pbmcgeGVuc3RvcmUgZGF0YWJhc2UuClN0YXJ0aW5nIHhlbnNlcnZpY2VzOiB4
ZW5zdG9yZWQsIHhlbmNvbnNvbGVkLkRlYyAxNyAxMDo1MjowNiBvZGluIHhlbnN0b3JlZDogQ2hl
Y2tpbmcgc3RvcmUgLi4uCkRlYyAxNyAxMDo1MjowNiBvZGluIHhlbnN0b3JlZDogQ2hlY2tpbmcg
c3RvcmUgY29tcGxldGUuCldBUk5JTkc6IEZhaWxlZCB0byBvcGVuIGNvbm5lY3Rpb24gdG8gZ250
dGFiCnhlbmJhbGxvb24wOiA8WGVuIEJhbGxvb24gRGV2aWNlPiBvbiB4ZW5zdG9yZTAKeGN0cmww
OiA8WGVuIENvbnRyb2wgRGV2aWNlPiBvbiB4ZW5zdG9yZTAKeHNfZGV2MDogPFhlbnN0b3JlIHVz
ZXItc3BhY2UgZGV2aWNlPiBvbiB4ZW5zdG9yZTAKeGVuYnVzYl9mcm9udDA6IDxYZW4gRnJvbnRl
bmQgRGV2aWNlcz4gb24geGVuc3RvcmUwCnhlbmJ1c2JfYmFjazA6IDxYZW4gQmFja2VuZCBEZXZp
Y2VzPiBvbiB4ZW5zdG9yZTAKClNldHRpbmcgZG9tYWluIDAgbmFtZSwgZG9taWQgYW5kIEpTT04g
Y29uZmlnLi4uCnVtczA6IDxERUxMIERFTEwgVVNCIExhc2VyIE1vdXNlLCBjbGFzcyAwLzAsIHJl
diAyLjAwLzU3LjAwLCBhZGRyIDM+IG9uIHVzYnVzMQp1bXMwOiBlcnJvciByZWFkaW5nIHJlcG9y
dCBkZXNjcmlwdGlvbgpkZXZpY2VfYXR0YWNoOiB1bXMwIGF0dGFjaCByZXR1cm5lZCAxMgphaGNp
Y2gwOiBUaW1lb3V0IG9uIHNsb3QgNiBwb3J0IDAKYWhjaWNoMDogaXMgMDAwMDAwMDggY3MgMDAw
MDAwMDAgc3MgMDAwMDAwMDAgcnMgMDAwMDAwNzggdGZkIDQwIHNlcnIgMDAwMDAwMDAgY21kIDAw
MDBjNjE3CmFoY2ljaDA6IEFIQ0kgcmVzZXQuLi4KKGFkYTA6YWhjaWNoMDowOjA6MCk6IFdSSVRF
X0ZQRE1BX1FVRVVFRC4gQUNCOiA2MSA1OCA5MCAzOCAwMCA0MCAxMCAwMCAwMCAwMCAwMCAwMAoo
YWRhMDphaGNpY2gwOjA6MDowKTogQ0FNIHN0YXR1czogQ29tbWFuZCB0aW1lb3V0CihhZGEwOmFo
Y2ljaDA6MDowOjApOiBSZXRyeWluZyBjb21tYW5kCmFoY2ljaDA6IFNBVEEgY29ubmVjdCB0aW1l
PTEwMHVzIHN0YXR1cz0wMDAwMDEyMwphaGNpY2gwOiBBSENJIHJlc2V0OiBkZXZpY2UgZm91bmQK
YWhjaWNoMDogQUhDSSByZXNldDogZGV2aWNlIHJlYWR5IGFmdGVyIDEwMG1zCihYRU4pICoqKiBT
ZXJpYWwgaW5wdXQgLT4gWGVuICh0eXBlICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBp
bnB1dCB0byBET00wKQooWEVOKSBJUlEgaW5mb3JtYXRpb246CihYRU4pICAgIElSUTogICAwIGFm
ZmluaXR5OjAwMDAwMDAxIHZlYzpmMCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAw
MDAgdGltZXJfaW50ZXJydXB0KCkKKFhFTikgICAgSVJROiAgIDEgYWZmaW5pdHk6MDAwMDAwMDEg
dmVjOjMwIHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwNiBtYXBwZWQsIHVuYm91
bmQKKFhFTikgICAgSVJROiAgIDMgYWZmaW5pdHk6MDAwMDAwMDEgdmVjOjM4IHR5cGU9SU8tQVBJ
Qy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwNiBtYXBwZWQsIHVuYm91bmQKKFhFTikgICAgSVJROiAg
IDQgYWZmaW5pdHk6MDAwMDAwMDEgdmVjOmYxIHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0w
MDAwMDAwMCBuczE2NTUwX2ludGVycnVwdCgpCihYRU4pICAgIElSUTogICA1IGFmZmluaXR5OjAw
MDAwMDAxIHZlYzo0MCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVk
LCB1bmJvdW5kCihYRU4pICAgIElSUTogICA2IGFmZmluaXR5OjAwMDAwMDAxIHZlYzo0OCB0eXBl
PUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDIgbWFwcGVkLCB1bmJvdW5kCihYRU4pICAg
IElSUTogICA3IGFmZmluaXR5OjAwMDAwMDAxIHZlYzo1MCB0eXBlPUlPLUFQSUMtZWRnZSAgICBz
dGF0dXM9MDAwMDAwMDYgbWFwcGVkLCB1bmJvdW5kCihYRU4pICAgIElSUTogICA4IGFmZmluaXR5
OjAwMDAwMDAxIHZlYzo1OCB0eXBlPUlPLUFQSUMtZWRnZSAgICBzdGF0dXM9MDAwMDAwMDIgbWFw
cGVkLCB1bmJvdW5kCihYRU4pICAgIElSUTogICA5IGFmZmluaXR5OjAwMDAwMDAxIHZlYzo2MCB0
eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0PTAgZG9tYWluLWxp
c3Q9MDogIDkoLS0tKSwKKFhFTikgICAgSVJROiAgMTAgYWZmaW5pdHk6MDAwMDAwMDEgdmVjOjY4
IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhF
TikgICAgSVJROiAgMTEgYWZmaW5pdHk6MDAwMDAwMDEgdmVjOjcwIHR5cGU9SU8tQVBJQy1lZGdl
ICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgICAgSVJROiAgMTIgYWZm
aW5pdHk6MDAwMDAwMDEgdmVjOjc4IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAw
MiBtYXBwZWQsIHVuYm91bmQKKFhFTikgICAgSVJROiAgMTMgYWZmaW5pdHk6MDAwMDAwMDEgdmVj
Ojg4IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQK
KFhFTikgICAgSVJROiAgMTQgYWZmaW5pdHk6MDAwMDAwMDEgdmVjOjkwIHR5cGU9SU8tQVBJQy1l
ZGdlICAgIHN0YXR1cz0wMDAwMDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgICAgSVJROiAgMTUg
YWZmaW5pdHk6MDAwMDAwMDEgdmVjOjk4IHR5cGU9SU8tQVBJQy1lZGdlICAgIHN0YXR1cz0wMDAw
MDAwMiBtYXBwZWQsIHVuYm91bmQKKFhFTikgICAgSVJROiAgMTYgYWZmaW5pdHk6MDAwMDAwMDEg
dmVjOmEwIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBk
b21haW4tbGlzdD0wOiAxNigtLS0pLAooWEVOKSAgICBJUlE6ICAxNyBhZmZpbml0eTowMDAwMDA0
MCB2ZWM6YTggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0w
IGRvbWFpbi1saXN0PTA6IDE3KC0tLSksCihYRU4pICAgIElSUTogIDE4IGFmZmluaXR5OjAwMDAw
MDAxIHZlYzpjMCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMzAgaW4tZmxpZ2h0
PTAgZG9tYWluLWxpc3Q9MDogMTgoLS0tKSwKKFhFTikgICAgSVJROiAgMjAgYWZmaW5pdHk6MDAw
MDAwMDQgdmVjOmM4IHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAxMCBpbi1mbGln
aHQ9MCBkb21haW4tbGlzdD0wOiAyMCgtLS0pLAooWEVOKSAgICBJUlE6ICAyMiBhZmZpbml0eTow
MDAwMDAyMCB2ZWM6YjAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZs
aWdodD0wIGRvbWFpbi1saXN0PTA6IDIyKC0tLSksCihYRU4pICAgIElSUTogIDIzIGFmZmluaXR5
OjAwMDAwMDAxIHZlYzpiOCB0eXBlPUlPLUFQSUMtbGV2ZWwgICBzdGF0dXM9MDAwMDAwMzAgaW4t
ZmxpZ2h0PTAgZG9tYWluLWxpc3Q9MDogMjMoLS0tKSwKKFhFTikgICAgSVJROiAgMjQgYWZmaW5p
dHk6MDAwMDAwZmYgdmVjOjIxIHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAwMiBt
YXBwZWQsIHVuYm91bmQKKFhFTikgICAgSVJROiAgMjggYWZmaW5pdHk6MDAwMDAwMDEgdmVjOmQw
IHR5cGU9SU8tQVBJQy1sZXZlbCAgIHN0YXR1cz0wMDAwMDAzMCBpbi1mbGlnaHQ9MCBkb21haW4t
bGlzdD0wOiAyOCgtLS0pLAooWEVOKSAgICBJUlE6ICA0MCBhZmZpbml0eTowMDAwMDAwMSB2ZWM6
ZDggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFp
bi1saXN0PTA6IDQwKC0tLSksCihYRU4pICAgIElSUTogIDQ4IGFmZmluaXR5OjAwMDAwMGZmIHZl
YzoyOCB0eXBlPURNQV9NU0kgICAgICAgICBzdGF0dXM9MDAwMDAwMDAgaW9tbXVfcGFnZV9mYXVs
dCgpCihYRU4pIERpcmVjdCB2ZWN0b3IgaW5mb3JtYXRpb246CihYRU4pICAgIDB4MjAgLT4gaXJx
X21vdmVfY2xlYW51cF9pbnRlcnJ1cHQoKQooWEVOKSAgICAweGYyIC0+IGNtY2lfaW50ZXJydXB0
KCkKKFhFTikgICAgMHhmMyAtPiBpbnRlbF90aGVybWFsX2ludGVycnVwdCgpCihYRU4pICAgIDB4
ZjkgLT4gcG11X2FwaWNfaW50ZXJydXB0KCkKKFhFTikgICAgMHhmYSAtPiBhcGljX3RpbWVyX2lu
dGVycnVwdCgpCihYRU4pICAgIDB4ZmIgLT4gY2FsbF9mdW5jdGlvbl9pbnRlcnJ1cHQoKQooWEVO
KSAgICAweGZjIC0+IGV2ZW50X2NoZWNrX2ludGVycnVwdCgpCihYRU4pICAgIDB4ZmQgLT4gaW52
YWxpZGF0ZV9pbnRlcnJ1cHQoKQooWEVOKSAgICAweGZlIC0+IGVycm9yX2ludGVycnVwdCgpCihY
RU4pICAgIDB4ZmYgLT4gc3B1cmlvdXNfaW50ZXJydXB0KCkKKFhFTikgSU8tQVBJQyBpbnRlcnJ1
cHQgaW5mb3JtYXRpb246CihYRU4pICAgICBJUlEgIDAgVmVjMjQwOgooWEVOKSAgICAgICBBcGlj
IDB4MDAsIFBpbiAgMjogdmVjPWYwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xh
cml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgIDEgVmVj
IDQ4OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAgMTogdmVjPTMwIGRlbGl2ZXJ5PUxvUHJp
IGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTEgZGVzdF9pZDox
CihYRU4pICAgICBJUlEgIDMgVmVjIDU2OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAgMzog
dmVjPTM4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRy
aWc9RSBtYXNrPTEgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgIDQgVmVjMjQxOgooWEVOKSAgICAg
ICBBcGljIDB4MDAsIFBpbiAgNDogdmVjPWYxIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9
MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEg
IDUgVmVjIDY0OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAgNTogdmVjPTQwIGRlbGl2ZXJ5
PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVz
dF9pZDoxCihYRU4pICAgICBJUlEgIDYgVmVjIDcyOgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBp
biAgNjogdmVjPTQ4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGly
cj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgIDcgVmVjIDgwOgooWEVO
KSAgICAgICBBcGljIDB4MDAsIFBpbiAgNzogdmVjPTUwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBz
dGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAg
ICBJUlEgIDggVmVjIDg4OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAgODogdmVjPTU4IGRl
bGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNr
PTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgIDkgVmVjIDk2OgooWEVOKSAgICAgICBBcGljIDB4
MDAsIFBpbiAgOTogdmVjPTYwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0
eT0wIGlycj0wIHRyaWc9TCBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgMTAgVmVjMTA0
OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAxMDogdmVjPTY4IGRlbGl2ZXJ5PUxvUHJpIGRl
c3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihY
RU4pICAgICBJUlEgMTEgVmVjMTEyOgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAxMTogdmVj
PTcwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9
RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgMTIgVmVjMTIwOgooWEVOKSAgICAgICBB
cGljIDB4MDAsIFBpbiAxMjogdmVjPTc4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBw
b2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgMTMg
VmVjMTM2OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAxMzogdmVjPTg4IGRlbGl2ZXJ5PUxv
UHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9p
ZDoxCihYRU4pICAgICBJUlEgMTQgVmVjMTQ0OgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAx
NDogdmVjPTkwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0w
IHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJUlEgMTUgVmVjMTUyOgooWEVOKSAg
ICAgICBBcGljIDB4MDAsIFBpbiAxNTogdmVjPTk4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0
dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxCihYRU4pICAgICBJ
UlEgMTYgVmVjMTYwOgooWEVOKSAgICAgICBBcGljIDB4MDAsIFBpbiAxNjogdmVjPWEwIGRlbGl2
ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTAg
ZGVzdF9pZDoxCihYRU4pICAgICBJUlEgMTcgVmVjMTY4OgooWEVOKSAgICAgICBBcGljIDB4MDAs
IFBpbiAxNzogdmVjPWE4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MSBwb2xhcml0eT0x
IGlycj0xIHRyaWc9TCBtYXNrPTAgZGVzdF9pZDo2NAooWEVOKSAgICAgSVJRIDE4IFZlYzE5MjoK
KFhFTikgICAgICAgQXBpYyAweDAwLCBQaW4gMTg6IHZlYz1jMCBkZWxpdmVyeT1Mb1ByaSBkZXN0
PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQooWEVO
KSAgICAgSVJRIDIwIFZlYzIwMDoKKFhFTikgICAgICAgQXBpYyAweDAwLCBQaW4gMjA6IHZlYz1j
OCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTEgcG9sYXJpdHk9MSBpcnI9MSB0cmlnPUwg
bWFzaz0wIGRlc3RfaWQ6NAooWEVOKSAgICAgSVJRIDIyIFZlYzE3NjoKKFhFTikgICAgICAgQXBp
YyAweDAwLCBQaW4gMjI6IHZlYz1iMCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9s
YXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MzIKKFhFTikgICAgIElSUSAyMyBW
ZWMxODQ6CihYRU4pICAgICAgIEFwaWMgMHgwMCwgUGluIDIzOiB2ZWM9YjggZGVsaXZlcnk9TG9Q
cmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lk
OjEKKFhFTikgICAgIElSUSAyNCBWZWMgMzM6CihYRU4pICAgICAgIEFwaWMgMHgwMSwgUGluICAw
OiB2ZWM9MjEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAg
dHJpZz1MIG1hc2s9MSBkZXN0X2lkOjI1NQooWEVOKSAgICAgSVJRIDI4IFZlYzIwODoKKFhFTikg
ICAgICAgQXBpYyAweDAxLCBQaW4gIDQ6IHZlYz1kMCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3Rh
dHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQooWEVOKSAgICAg
SVJRIDQwIFZlYzIxNjoKKFhFTikgICAgICAgQXBpYyAweDAxLCBQaW4gMTY6IHZlYz1kOCBkZWxp
dmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0w
IGRlc3RfaWQ6MQooWEVOKSAnZScgcHJlc3NlZCAtPiBkdW1waW5nIGV2ZW50LWNoYW5uZWwgaW5m
bwooWEVOKSBFdmVudCBjaGFubmVsIGluZm9ybWF0aW9uIGZvciBkb21haW4gMDoKKFhFTikgUG9s
bGluZyB2Q1BVczoge30KKFhFTikgICAgIHBvcnQgW3AvbS9zXQooWEVOKSAgICAgICAgMSBbMC8w
LzBdOiBzPTUgbj0wIHg9MCB2PTIKKFhFTikgICAgICAgIDIgWzAvMC8wXTogcz01IG49MCB4PTAg
dj0wCihYRU4pICAgICAgICAzIFswLzAvMF06IHM9NSBuPTEgeD0wIHY9MAooWEVOKSAgICAgICAg
NCBbMC8wLzBdOiBzPTUgbj0yIHg9MCB2PTAKKFhFTikgICAgICAgIDUgWzAvMC8wXTogcz01IG49
MyB4PTAgdj0wCihYRU4pICAgICAgICA2IFswLzAvMF06IHM9NSBuPTQgeD0wIHY9MAooWEVOKSAg
ICAgICAgNyBbMC8wLzBdOiBzPTUgbj01IHg9MCB2PTAKKFhFTikgICAgICAgIDggWzAvMC8wXTog
cz01IG49NiB4PTAgdj0wCihYRU4pICAgICAgICA5IFswLzAvMF06IHM9NSBuPTcgeD0wIHY9MAoo
WEVOKSAgICAgICAxMCBbMC8wLzBdOiBzPTMgbj0xIHg9MCBkPTAgcD05MgooWEVOKSAgICAgICAx
MSBbMC8wLzBdOiBzPTQgbj0wIHg9MCBwPTkgaT05CihYRU4pICAgICAgIDEyIFswLzAvMF06IHM9
NCBuPTcgeD0wIHA9MjggaT0yOAooWEVOKSAgICAgICAxMyBbMC8wLzBdOiBzPTQgbj0wIHg9MCBw
PTQwIGk9NDAKKFhFTikgICAgICAgMTQgWzAvMC8wXTogcz00IG49MSB4PTAgcD0xNiBpPTE2CihY
RU4pICAgICAgIDE1IFswLzAvMF06IHM9NCBuPTIgeD0wIHA9MTcgaT0xNwooWEVOKSAgICAgICAx
NiBbMC8wLzBdOiBzPTQgbj01IHg9MCBwPTIyIGk9MjIKKFhFTikgICAgICAgMTcgWzAvMC8wXTog
cz00IG49NiB4PTAgcD0yMyBpPTIzCihYRU4pICAgICAgIDE4IFswLzAvMF06IHM9NCBuPTMgeD0w
IHA9MTggaT0xOAooWEVOKSAgICAgICAxOSBbMC8wLzBdOiBzPTQgbj00IHg9MCBwPTIwIGk9MjAK
KFhFTikgICAgICAgMjAgWzAvMC8wXTogcz02IG49MCB4PTAKKFhFTikgICAgICAgMjEgWzAvMC8w
XTogcz02IG49MCB4PTAKKFhFTikgICAgICAgMjIgWzAvMC8wXTogcz02IG49MCB4PTAKKFhFTikg
ICAgICAgMjMgWzAvMC8wXTogcz02IG49MCB4PTAKKFhFTikgICAgICAgMjQgWzAvMC8wXTogcz02
IG49MCB4PTAKKFhFTikgICAgICAgMjUgWzAvMC8wXTogcz02IG49MCB4PTAKKFhFTikgICAgICAg
MjYgWzAvMC8wXTogcz02IG49MCB4PTAKKFhFTikgICAgICAgMjcgWzAvMC8wXTogcz02IG49MCB4
PTAKKFhFTikgICAgICAgMjggWzAvMC8wXTogcz02IG49MCB4PTAKKFhFTikgICAgICAgMjkgWzAv
MC8wXTogcz02IG49MSB4PTAKKFhFTikgICAgICAgMzAgWzAvMC8wXTogcz02IG49MSB4PTAKKFhF
TikgICAgICAgMzEgWzAvMC8wXTogcz02IG49MSB4PTAKKFhFTikgICAgICAgMzIgWzAvMC8wXTog
cz02IG49MSB4PTAKKFhFTikgICAgICAgMzMgWzAvMC8wXTogcz02IG49MSB4PTAKKFhFTikgICAg
ICAgMzQgWzAvMC8wXTogcz02IG49MSB4PTAKKFhFTikgICAgICAgMzUgWzAvMC8wXTogcz02IG49
MSB4PTAKKFhFTikgICAgICAgMzYgWzAvMC8wXTogcz02IG49MSB4PTAKKFhFTikgICAgICAgMzcg
WzAvMC8wXTogcz02IG49MSB4PTAKKFhFTikgICAgICAgMzggWzAvMC8wXTogcz02IG49MiB4PTAK
KFhFTikgICAgICAgMzkgWzAvMC8wXTogcz02IG49MiB4PTAKKFhFTikgICAgICAgNDAgWzAvMC8w
XTogcz02IG49MiB4PTAKKFhFTikgICAgICAgNDEgWzAvMC8wXTogcz02IG49MiB4PTAKKFhFTikg
ICAgICAgNDIgWzAvMC8wXTogcz02IG49MiB4PTAKKFhFTikgICAgICAgNDMgWzAvMC8wXTogcz02
IG49MiB4PTAKKFhFTikgICAgICAgNDQgWzAvMC8wXTogcz02IG49MiB4PTAKKFhFTikgICAgICAg
NDUgWzAvMC8wXTogcz02IG49MiB4PTAKKFhFTikgICAgICAgNDYgWzAvMC8wXTogcz02IG49MiB4
PTAKKFhFTikgICAgICAgNDcgWzAvMC8wXTogcz02IG49MyB4PTAKKFhFTikgICAgICAgNDggWzAv
MC8wXTogcz02IG49MyB4PTAKKFhFTikgICAgICAgNDkgWzAvMC8wXTogcz02IG49MyB4PTAKKFhF
TikgICAgICAgNTAgWzAvMC8wXTogcz02IG49MyB4PTAKKFhFTikgICAgICAgNTEgWzAvMC8wXTog
cz02IG49MyB4PTAKKFhFTikgICAgICAgNTIgWzAvMC8wXTogcz02IG49MyB4PTAKKFhFTikgICAg
ICAgNTMgWzAvMC8wXTogcz02IG49MyB4PTAKKFhFTikgICAgICAgNTQgWzAvMC8wXTogcz02IG49
MyB4PTAKKFhFTikgICAgICAgNTUgWzAvMC8wXTogcz02IG49MyB4PTAKKFhFTikgICAgICAgNTYg
WzAvMC8wXTogcz02IG49NCB4PTAKKFhFTikgICAgICAgNTcgWzAvMC8wXTogcz02IG49NCB4PTAK
KFhFTikgICAgICAgNTggWzAvMC8wXTogcz02IG49NCB4PTAKKFhFTikgICAgICAgNTkgWzAvMC8w
XTogcz02IG49NCB4PTAKKFhFTikgICAgICAgNjAgWzAvMC8wXTogcz02IG49NCB4PTAKKFhFTikg
ICAgICAgNjEgWzAvMC8wXTogcz02IG49NCB4PTAKKFhFTikgICAgICAgNjIgWzAvMC8wXTogcz02
IG49NCB4PTAKKFhFTikgICAgICAgNjMgWzAvMC8wXTogcz02IG49NCB4PTAKKFhFTikgICAgICAg
NjQgWzAvMC8wXTogcz02IG49NCB4PTAKKFhFTikgICAgICAgNjUgWzAvMC8wXTogcz02IG49NSB4
PTAKKFhFTikgICAgICAgNjYgWzAvMC8wXTogcz02IG49NSB4PTAKKFhFTikgICAgICAgNjcgWzAv
MC8wXTogcz02IG49NSB4PTAKKFhFTikgICAgICAgNjggWzAvMC8wXTogcz02IG49NSB4PTAKKFhF
TikgICAgICAgNjkgWzAvMC8wXTogcz02IG49NSB4PTAKKFhFTikgICAgICAgNzAgWzAvMC8wXTog
cz02IG49NSB4PTAKKFhFTikgICAgICAgNzEgWzAvMC8wXTogcz02IG49NSB4PTAKKFhFTikgICAg
ICAgNzIgWzAvMC8wXTogcz02IG49NSB4PTAKKFhFTikgICAgICAgNzMgWzAvMC8wXTogcz02IG49
NSB4PTAKKFhFTikgICAgICAgNzQgWzAvMC8wXTogcz02IG49NiB4PTAKKFhFTikgICAgICAgNzUg
WzAvMC8wXTogcz02IG49NiB4PTAKKFhFTikgICAgICAgNzYgWzAvMC8wXTogcz02IG49NiB4PTAK
KFhFTikgICAgICAgNzcgWzAvMC8wXTogcz02IG49NiB4PTAKKFhFTikgICAgICAgNzggWzAvMC8w
XTogcz02IG49NiB4PTAKKFhFTikgICAgICAgNzkgWzAvMC8wXTogcz02IG49NiB4PTAKKFhFTikg
ICAgICAgODAgWzAvMC8wXTogcz02IG49NiB4PTAKKFhFTikgICAgICAgODEgWzAvMC8wXTogcz02
IG49NiB4PTAKKFhFTikgICAgICAgODIgWzAvMC8wXTogcz02IG49NiB4PTAKKFhFTikgICAgICAg
ODMgWzAvMC8wXTogcz02IG49NyB4PTAKKFhFTikgICAgICAgODQgWzAvMC8wXTogcz02IG49NyB4
PTAKKFhFTikgICAgICAgODUgWzAvMC8wXTogcz02IG49NyB4PTAKKFhFTikgICAgICAgODYgWzAv
MC8wXTogcz02IG49NyB4PTAKKFhFTikgICAgICAgODcgWzAvMC8wXTogcz02IG49NyB4PTAKKFhF
TikgICAgICAgODggWzAvMC8wXTogcz02IG49NyB4PTAKKFhFTikgICAgICAgODkgWzAvMC8wXTog
cz02IG49NyB4PTAKKFhFTikgICAgICAgOTAgWzAvMC8wXTogcz02IG49NyB4PTAKKFhFTikgICAg
ICAgOTEgWzAvMC8wXTogcz02IG49NyB4PTAKKFhFTikgICAgICAgOTIgWzAvMC8wXTogcz0zIG49
MiB4PTAgZD0wIHA9MTAKKFhFTikgICAgICAgOTMgWzAvMC8wXTogcz01IG49MCB4PTAgdj0zCihY
RU4pIG51bWJlciBvZiBNUCBJUlEgc291cmNlczogMTUuCihYRU4pIG51bWJlciBvZiBJTy1BUElD
ICM4IHJlZ2lzdGVyczogMjQuCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM5IHJlZ2lzdGVyczog
MjQuCihYRU4pIHRlc3RpbmcgdGhlIElPIEFQSUMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLgooWEVO
KSBJTyBBUElDICM4Li4uLi4uCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAwMDAwMDAwMAooWEVO
KSAuLi4uLi4uICAgIDogcGh5c2ljYWwgQVBJQyBpZDogMDAKKFhFTikgLi4uLi4uLiAgICA6IERl
bGl2ZXJ5IFR5cGU6IDAKKFhFTikgLi4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDAKKFhFTikg
Li4uLiByZWdpc3RlciAjMDE6IDAwMTcwMDIwCihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGly
ZWN0aW9uIGVudHJpZXM6IDAwMTcKKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6
IDAKKFhFTikgLi4uLi4uLiAgICAgOiBJTyBBUElDIHZlcnNpb246IDAwMjAKKFhFTikgLi4uLiBJ
UlEgcmVkaXJlY3Rpb24gdGFibGU6CihYRU4pICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9s
IFN0YXQgRGVzdCBEZWxpIFZlY3Q6CihYRU4pICAwMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwMSAwMDEgMDEgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMSAgICAxICAgIDMwCihYRU4pICAwMiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAg
MSAgICAxICAgIEYwCihYRU4pICAwMyAwMDEgMDEgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMSAg
ICAxICAgIDM4CihYRU4pICAwNCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIEYxCihYRU4pICAwNSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDQwCihYRU4pICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4
CihYRU4pICAwNyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDUwCihY
RU4pICAwOCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4CihYRU4p
ICAwOSAwMDEgMDEgIDAgICAgMSAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDYwCihYRU4pICAw
YSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDY4CihYRU4pICAwYiAw
MDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwCihYRU4pICAwYyAwMDEg
MDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4CihYRU4pICAwZCAwMDEgMDEg
IDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDg4CihYRU4pICAwZSAwMDEgMDEgIDAg
ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwCihYRU4pICAwZiAwMDEgMDEgIDAgICAg
MCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDk4CihYRU4pICAxMCAwMDEgMDEgIDAgICAgMSAg
ICAwICAgMSAgIDAgICAgMSAgICAxICAgIEEwCihYRU4pICAxMSAwNDAgMDAgIDAgICAgMSAgICAx
ICAgMSAgIDEgICAgMSAgICAxICAgIEE4CihYRU4pICAxMiAwMDEgMDEgIDAgICAgMSAgICAwICAg
MSAgIDAgICAgMSAgICAxICAgIEMwCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwCihYRU4pICAxNCAwMDQgMDQgIDAgICAgMSAgICAxICAgMSAgIDEg
ICAgMSAgICAxICAgIEM4CihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwCihYRU4pICAxNiAwMjAgMDAgIDAgICAgMSAgICAwICAgMSAgIDAgICAgMSAg
ICAxICAgIEIwCihYRU4pICAxNyAwMDEgMDEgIDAgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAx
ICAgIEI4CihYRU4pIElPIEFQSUMgIzkuLi4uLi4KKFhFTikgLi4uLiByZWdpc3RlciAjMDA6IDAw
MDAwMDAwCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwMAooWEVOKSAuLi4u
Li4uICAgIDogRGVsaXZlcnkgVHlwZTogMAooWEVOKSAuLi4uLi4uICAgIDogTFRTICAgICAgICAg
IDogMAooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzAwMjAKKFhFTikgLi4uLi4uLiAgICAg
OiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNwooWEVOKSAuLi4uLi4uICAgICA6IFBSUSBp
bXBsZW1lbnRlZDogMAooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMAoo
WEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDAwMDAwMDAKKFhFTikgLi4uLi4uLiAgICAgOiBhcmJp
dHJhdGlvbjogMDAKKFhFTikgLi4uLiByZWdpc3RlciAjMDM6IDAwMDAwMDAxCihYRU4pIC4uLi4u
Li4gICAgIDogQm9vdCBEVCAgICA6IDEKKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6
CihYRU4pICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6
CihYRU4pICAwMCAwRkYgMEYgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDIxCihY
RU4pICAwMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4p
ICAwMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwNCAw
MDEgMDEgIDAgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIEQwCihYRU4pICAwNSAwMDAg
MDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwNiAwMDAgMDAg
IDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwNyAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwOCAwMDAgMDAgIDEgICAg
MCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwOSAwMDAgMDAgIDEgICAgMCAg
ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwYSAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwCihYRU4pICAwZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwCihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwCihYRU4pICAwZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwCihYRU4pICAxMCAwMDEgMDEgIDAgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAx
ICAgIEQ4CihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
CihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihY
RU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4p
ICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAxNyAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pIFVzaW5nIHZl
Y3Rvci1iYXNlZCBpbmRleGluZwooWEVOKSBJUlEgdG8gcGluIG1hcHBpbmdzOgooWEVOKSBJUlEy
NDAgLT4gMDoyCihYRU4pIElSUTQ4IC0+IDA6MQooWEVOKSBJUlE1NiAtPiAwOjMKKFhFTikgSVJR
MjQxIC0+IDA6NAooWEVOKSBJUlE2NCAtPiAwOjUKKFhFTikgSVJRNzIgLT4gMDo2CihYRU4pIElS
UTgwIC0+IDA6NwooWEVOKSBJUlE4OCAtPiAwOjgKKFhFTikgSVJROTYgLT4gMDo5CihYRU4pIElS
UTEwNCAtPiAwOjEwCihYRU4pIElSUTExMiAtPiAwOjExCihYRU4pIElSUTEyMCAtPiAwOjEyCihY
RU4pIElSUTEzNiAtPiAwOjEzCihYRU4pIElSUTE0NCAtPiAwOjE0CihYRU4pIElSUTE1MiAtPiAw
OjE1CihYRU4pIElSUTE2MCAtPiAwOjE2CihYRU4pIElSUTE2OCAtPiAwOjE3CihYRU4pIElSUTE5
MiAtPiAwOjE4CihYRU4pIElSUTIwMCAtPiAwOjIwCihYRU4pIElSUTE3NiAtPiAwOjIyCihYRU4p
IElSUTE4NCAtPiAwOjIzCihYRU4pIElSUTMzIC0+IDE6MAooWEVOKSBJUlEyMDggLT4gMTo0CihY
RU4pIElSUTIxNiAtPiAxOjE2CihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLiBkb25lLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Dec 17 12:18:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 12:18:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1DYP-000498-3h; Wed, 17 Dec 2014 12:18: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 1Y1DYM-000490-TI
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 12:18:07 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	79/B1-26858-E7471945; Wed, 17 Dec 2014 12:18:06 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418818683!10294704!1
X-Originating-IP: [66.165.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 12394 invoked from network); 17 Dec 2014 12:18:05 -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;
	17 Dec 2014 12:18:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205298648"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 17 Dec 2014 07:17:51 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Y1DY7-0001UZ-4n;
	Wed, 17 Dec 2014 12:17:51 +0000
Date: Wed, 17 Dec 2014 12:17:50 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Message-ID: <20141217121750.GF1904@zion.uk.xensource.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418711577-15449-3-git-send-email-cyliu@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 02:32:55PM +0800, Chunyan Liu wrote:
> Changes to V8:
>   * add an overview document, so that one can has a overall look
>     about the whole domain snapshot work, limits, requirements,
>     how to do, etc.
> 
> =====================================================================
> Domain snapshot overview
> 
> 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 usually includes:
> a) create a domain snapshot
> b) roll back (or called "revert") to a domain snapshot
> c) delete a domain snapshot
> d) list all domain snapshots
> 
> But following the existing xl idioms of managing storage and saved
> VM images via existing CLI command (qemu-img, lvcreate, ls, mv,
> cp etc), xl snapshot functionality would be kept as simple as
> possible:
> * xl will do a) and b), creating a snapshot and reverting a
>   domain to a snapshot.
> * xl will NOT do c) and d), xl won't manage snapshots, as xl
>   doesn't maintain saved images created by 'xl save'. So xl
>   will have no idea of the existence of domain snapshots and
>   the chain relationship between snapshots. It will depends on
>   user to take care of the snapshots, know the snapshot chain
>   info, and delete snapshots.
> 
> Domain Snapshot Support and Not Support:

I think this list applies to xl (last item and [1]). If so please state
clearly to prevent confusion with other toolstack (say, libvirt) and
functionalities of the library (libxl).

> * support live snapshot
> * support internal disk snapshot and external disk snapshot
> * support different disk backend types.
>   (Basic goal is to support 'raw' and 'qcow2' only).
> 
> * not support snapshot when domain is shutdowning or dying.
> * not support disk-only snapshot [1].
> 
>  [1] 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.
> 

I think I understand your reasoning, but it's a bit convoluted to me.

Domain can be in both active and inactive state (libvirt term) when
using xl.  When domain is active, we cannot guarantee in xl that domain
is quiesced so a disk-only snapshot may contain inconsistent data. When
domain is inactive, there's no point in taking a disk-only snapshot
because it would be the same as the base image. So the conclusion is
that xl doesn't need to support disk-only snapshot.

Does the above reasoning equals to yours? Is it clearer or more
confusing?

Wei.

> 
> 2. Requirements
> 
> General Requirements:
> * ability to save/restore domain memory
> * ability to create/delete/apply disk snapshot [2]
> * ability to parse user config file
> 
>   [2] Disk snapshot requirements:
>   - external tools: qemu-img, lvcreate, vhd-util, etc.
>   - for basic goal, we support 'raw' and 'qcow2' backend types
>     only. Then it requires:
>     libxl qmp command or "qemu-img" (when qemu process does not
>     exist)
> 
> 
> 3. Interaction with other operations:
> 
> No.
> 
> 
> 4. General workflow
> 
> Create a snapshot:
>   * parse user cfg file if passed in
>   * check snapshot operation is allowed or not
>   * save domain, saving memory status to file (refer to: save_domain)
>   * take disk snapshot (e.g. call qmp command)
>   * unpause domain
> 
> Revert to snapshot:
>   * parse use cfg file (xl doesn't manage snapshots, so it has no
>     idea of snapshot existence. User MUST supply configuration file)
>   * destroy this domain
>   * create a new domain from snapshot info
>     - apply disk snapshot (e.g. call qemu-img)
>     - a process like restore domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 12:18:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 12:18:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1DYP-000498-3h; Wed, 17 Dec 2014 12:18: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 1Y1DYM-000490-TI
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 12:18:07 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	79/B1-26858-E7471945; Wed, 17 Dec 2014 12:18:06 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418818683!10294704!1
X-Originating-IP: [66.165.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 12394 invoked from network); 17 Dec 2014 12:18:05 -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;
	17 Dec 2014 12:18:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205298648"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 17 Dec 2014 07:17:51 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Y1DY7-0001UZ-4n;
	Wed, 17 Dec 2014 12:17:51 +0000
Date: Wed, 17 Dec 2014 12:17:50 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Message-ID: <20141217121750.GF1904@zion.uk.xensource.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418711577-15449-3-git-send-email-cyliu@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 02:32:55PM +0800, Chunyan Liu wrote:
> Changes to V8:
>   * add an overview document, so that one can has a overall look
>     about the whole domain snapshot work, limits, requirements,
>     how to do, etc.
> 
> =====================================================================
> Domain snapshot overview
> 
> 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 usually includes:
> a) create a domain snapshot
> b) roll back (or called "revert") to a domain snapshot
> c) delete a domain snapshot
> d) list all domain snapshots
> 
> But following the existing xl idioms of managing storage and saved
> VM images via existing CLI command (qemu-img, lvcreate, ls, mv,
> cp etc), xl snapshot functionality would be kept as simple as
> possible:
> * xl will do a) and b), creating a snapshot and reverting a
>   domain to a snapshot.
> * xl will NOT do c) and d), xl won't manage snapshots, as xl
>   doesn't maintain saved images created by 'xl save'. So xl
>   will have no idea of the existence of domain snapshots and
>   the chain relationship between snapshots. It will depends on
>   user to take care of the snapshots, know the snapshot chain
>   info, and delete snapshots.
> 
> Domain Snapshot Support and Not Support:

I think this list applies to xl (last item and [1]). If so please state
clearly to prevent confusion with other toolstack (say, libvirt) and
functionalities of the library (libxl).

> * support live snapshot
> * support internal disk snapshot and external disk snapshot
> * support different disk backend types.
>   (Basic goal is to support 'raw' and 'qcow2' only).
> 
> * not support snapshot when domain is shutdowning or dying.
> * not support disk-only snapshot [1].
> 
>  [1] 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.
> 

I think I understand your reasoning, but it's a bit convoluted to me.

Domain can be in both active and inactive state (libvirt term) when
using xl.  When domain is active, we cannot guarantee in xl that domain
is quiesced so a disk-only snapshot may contain inconsistent data. When
domain is inactive, there's no point in taking a disk-only snapshot
because it would be the same as the base image. So the conclusion is
that xl doesn't need to support disk-only snapshot.

Does the above reasoning equals to yours? Is it clearer or more
confusing?

Wei.

> 
> 2. Requirements
> 
> General Requirements:
> * ability to save/restore domain memory
> * ability to create/delete/apply disk snapshot [2]
> * ability to parse user config file
> 
>   [2] Disk snapshot requirements:
>   - external tools: qemu-img, lvcreate, vhd-util, etc.
>   - for basic goal, we support 'raw' and 'qcow2' backend types
>     only. Then it requires:
>     libxl qmp command or "qemu-img" (when qemu process does not
>     exist)
> 
> 
> 3. Interaction with other operations:
> 
> No.
> 
> 
> 4. General workflow
> 
> Create a snapshot:
>   * parse user cfg file if passed in
>   * check snapshot operation is allowed or not
>   * save domain, saving memory status to file (refer to: save_domain)
>   * take disk snapshot (e.g. call qmp command)
>   * unpause domain
> 
> Revert to snapshot:
>   * parse use cfg file (xl doesn't manage snapshots, so it has no
>     idea of snapshot existence. User MUST supply configuration file)
>   * destroy this domain
>   * create a new domain from snapshot info
>     - apply disk snapshot (e.g. call qemu-img)
>     - a process like restore domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 12:25:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 12:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Dfj-0004Ph-0y; Wed, 17 Dec 2014 12:25:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y1Dfg-0004Pc-V5
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 12:25:41 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	11/47-09284-44671945; Wed, 17 Dec 2014 12:25:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418819137!14051648!1
X-Originating-IP: [66.165.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 19342 invoked from network); 17 Dec 2014 12:25:39 -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;
	17 Dec 2014 12:25:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205300621"
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.210.2; Wed, 17 Dec 2014 07:25: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 1Y1DfU-0006Rh-1B;
	Wed, 17 Dec 2014 12:25:28 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1DfT-0005wJ-OU;
	Wed, 17 Dec 2014 12:25:27 +0000
Date: Wed, 17 Dec 2014 12:25:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32422-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] 32422: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32422 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32422/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt       5 xen-boot                  fail REGR. vs. 32386
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 32386
 test-amd64-amd64-xl           9 guest-start               fail REGR. vs. 32386
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 32386
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 32386
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 32386
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32386
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 32386
 test-armhf-armhf-xl           5 xen-boot                  fail REGR. vs. 32386
 test-armhf-armhf-libvirt      5 xen-boot                  fail REGR. vs. 32386
 test-amd64-i386-freebsd10-amd64  5 xen-boot               fail REGR. vs. 32386
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 32386
 test-amd64-i386-freebsd10-i386  5 xen-boot                fail REGR. vs. 32386
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot           fail REGR. vs. 32386
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32386
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 32386
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot             fail REGR. vs. 32386
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32386
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32386
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot           fail REGR. vs. 32386
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32386
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 32386
 test-amd64-i386-xl-winxpsp3   5 xen-boot                  fail REGR. vs. 32386
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 32386
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32386
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32386
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32386
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 32386
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 32386

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start                  fail   like 32386
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start              fail like 32386
 test-amd64-amd64-xl-sedf     12 guest-localmigrate        fail REGR. vs. 32386
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot           fail blocked in 32386
 test-amd64-amd64-pair        16 guest-start/debian           fail   like 32386
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot            fail blocked in 32386
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32386

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-amd64-xl-pvh-amd   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-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-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                a0eda581bf3fdc7be6bdf4cb18ce087675699336
baseline version:
 linux                67e2c3883828b39548cee2091b36656787775d95

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-amd64-xl-pvh-amd                                  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                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 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-amd64-xl-pvh-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 Wed Dec 17 12:25:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 12:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Dfj-0004Ph-0y; Wed, 17 Dec 2014 12:25:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y1Dfg-0004Pc-V5
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 12:25:41 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	11/47-09284-44671945; Wed, 17 Dec 2014 12:25:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418819137!14051648!1
X-Originating-IP: [66.165.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 19342 invoked from network); 17 Dec 2014 12:25:39 -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;
	17 Dec 2014 12:25:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205300621"
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.210.2; Wed, 17 Dec 2014 07:25: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 1Y1DfU-0006Rh-1B;
	Wed, 17 Dec 2014 12:25:28 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1DfT-0005wJ-OU;
	Wed, 17 Dec 2014 12:25:27 +0000
Date: Wed, 17 Dec 2014 12:25:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32422-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] 32422: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32422 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32422/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt       5 xen-boot                  fail REGR. vs. 32386
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 32386
 test-amd64-amd64-xl           9 guest-start               fail REGR. vs. 32386
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 32386
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 32386
 test-amd64-i386-rumpuserxen-i386  5 xen-boot              fail REGR. vs. 32386
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32386
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 32386
 test-armhf-armhf-xl           5 xen-boot                  fail REGR. vs. 32386
 test-armhf-armhf-libvirt      5 xen-boot                  fail REGR. vs. 32386
 test-amd64-i386-freebsd10-amd64  5 xen-boot               fail REGR. vs. 32386
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 32386
 test-amd64-i386-freebsd10-i386  5 xen-boot                fail REGR. vs. 32386
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot           fail REGR. vs. 32386
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 32386
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot           fail REGR. vs. 32386
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot             fail REGR. vs. 32386
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 32386
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32386
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot           fail REGR. vs. 32386
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32386
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 32386
 test-amd64-i386-xl-winxpsp3   5 xen-boot                  fail REGR. vs. 32386
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 32386
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32386
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32386
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot      fail REGR. vs. 32386
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 32386
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 32386

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start                  fail   like 32386
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start              fail like 32386
 test-amd64-amd64-xl-sedf     12 guest-localmigrate        fail REGR. vs. 32386
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot           fail blocked in 32386
 test-amd64-amd64-pair        16 guest-start/debian           fail   like 32386
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot            fail blocked in 32386
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32386

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-amd64-xl-pvh-amd   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-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-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                a0eda581bf3fdc7be6bdf4cb18ce087675699336
baseline version:
 linux                67e2c3883828b39548cee2091b36656787775d95

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-amd64-xl-pvh-amd                                  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                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 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-amd64-xl-pvh-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 Wed Dec 17 12:28:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 12:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1DiZ-0004aa-Je; Wed, 17 Dec 2014 12:28:39 +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 1Y1DiY-0004aU-1J
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 12:28:38 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	B4/C1-03145-5F671945; Wed, 17 Dec 2014 12:28:37 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418819309!15665721!1
X-Originating-IP: [66.165.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 5179 invoked from network); 17 Dec 2014 12:28:31 -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;
	17 Dec 2014 12:28:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205301642"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 17 Dec 2014 07:28:19 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Y1DiE-0001gy-6F;
	Wed, 17 Dec 2014 12:28:18 +0000
Date: Wed, 17 Dec 2014 12:28:17 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Message-ID: <20141217122817.GG1904@zion.uk.xensource.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418711577-15449-4-git-send-email-cyliu@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 02:32:56PM +0800, Chunyan Liu wrote:
> Changes to V8:
>   * xl won't manage snapshots, that means it won't maintain json files,
>     won't maintain snapshot chain relationship, and then as a result
>     won't take care of deleting snapshot and listing snapshots.
>   * remove snapshot-delete and snapshot-list interface
>   * update snapshot-revert interface
>   * update snapshot-create/revert implementaion
> 
> ===========================================================================
> 
> XL Design
> 
> 1. User Interface
> 
> 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, use cfgfile. (e.g. if --name specifies a name,
>     meanwhile there is name specified in cfgfile, name in cfgfile will
>     be used.)
> 
> 
> xl snapshot-revert:
>   Revert domain to status of a snapshot.
> 
>   SYNOPSIS:
>       snapshot-revert <domain> <cfgfile> [--running] [--force]
> 
>   OPTIONS:
>     --running        after reverting, change state to running
>     --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.
> 
> 
> 
> 2. cfgfile syntax
> 
> #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
> #For easier parse config work, reuse disk configuration in xl.cfg, but
> #with different meanings.
> #disk syntax meaning: 'external path, external format, target device'
> 
> #e.g. to specify exernal disk snapshot, like this:
> #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda',
>         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',]
> 
> #e.g. to specify internal disk snapshot, like this:
> disks=[',,hda',',,hdb',]
> 

How is snapshot chain represented with this syntax? Does xl not need to
know about the chain? (Note, this is different than managing the chain)

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 12:28:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 12:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1DiZ-0004aa-Je; Wed, 17 Dec 2014 12:28:39 +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 1Y1DiY-0004aU-1J
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 12:28:38 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	B4/C1-03145-5F671945; Wed, 17 Dec 2014 12:28:37 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418819309!15665721!1
X-Originating-IP: [66.165.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 5179 invoked from network); 17 Dec 2014 12:28:31 -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;
	17 Dec 2014 12:28:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205301642"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 17 Dec 2014 07:28:19 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Y1DiE-0001gy-6F;
	Wed, 17 Dec 2014 12:28:18 +0000
Date: Wed, 17 Dec 2014 12:28:17 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Message-ID: <20141217122817.GG1904@zion.uk.xensource.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418711577-15449-4-git-send-email-cyliu@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 02:32:56PM +0800, Chunyan Liu wrote:
> Changes to V8:
>   * xl won't manage snapshots, that means it won't maintain json files,
>     won't maintain snapshot chain relationship, and then as a result
>     won't take care of deleting snapshot and listing snapshots.
>   * remove snapshot-delete and snapshot-list interface
>   * update snapshot-revert interface
>   * update snapshot-create/revert implementaion
> 
> ===========================================================================
> 
> XL Design
> 
> 1. User Interface
> 
> 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, use cfgfile. (e.g. if --name specifies a name,
>     meanwhile there is name specified in cfgfile, name in cfgfile will
>     be used.)
> 
> 
> xl snapshot-revert:
>   Revert domain to status of a snapshot.
> 
>   SYNOPSIS:
>       snapshot-revert <domain> <cfgfile> [--running] [--force]
> 
>   OPTIONS:
>     --running        after reverting, change state to running
>     --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.
> 
> 
> 
> 2. cfgfile syntax
> 
> #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
> #For easier parse config work, reuse disk configuration in xl.cfg, but
> #with different meanings.
> #disk syntax meaning: 'external path, external format, target device'
> 
> #e.g. to specify exernal disk snapshot, like this:
> #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda',
>         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',]
> 
> #e.g. to specify internal disk snapshot, like this:
> disks=[',,hda',',,hdb',]
> 

How is snapshot chain represented with this syntax? Does xl not need to
know about the chain? (Note, this is different than managing the chain)

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 12:48:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 12:48:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1E0f-0005D9-H7; Wed, 17 Dec 2014 12:47:21 +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 1Y1E0e-0005D4-3n
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 12:47:20 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	01/54-07724-75B71945; Wed, 17 Dec 2014 12:47:19 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418820437!14022684!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5573 invoked from network); 17 Dec 2014 12:47:17 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 12:47:17 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so20108693wgh.4
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 04:47: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
	:content-transfer-encoding;
	bh=78l0aoGZ+/YGHaDea/KHZgR45fHspBczOgPXkZiEGQ0=;
	b=RMJCsLhDO4a2VlxUp/Nwt3wYg+ToF6l3WjfPOWee8hgZvpQXePSSS8ABd3eDe8D7wq
	rIBzJqjTa2+2YYIlw0yN/g8PzeCfPL+5CREvVBE2hVKn/hHn6q3zmc9r8ozIsULCZdt9
	aYVB2YjH5dBeoYJP4zwzPj6tj4+wiy5kqX/aiN5U+QQmOJ4jetemL0C6Gl3eu2Eg7ZzM
	rQm9jalapzbHxCiIQQTS8mCXKLFqvP7FSpeNqd0b1FnTpcvT9WXvzPkW7/l3idVLNgMr
	crRAeWyLeUroYDBz2ykBmTQ/ICzxsBQLM2utqeTaxEFv9Wtk6T7A507xddwXwD/KglrN
	ZwwA==
X-Gm-Message-State: ALoCoQk7p2DRMM0URTNEFjoNTt/4vg8GbkMyrUkHsmI2/MSLtZUHo7yBP2Yk1PWjKbLgksjtcnxX
X-Received: by 10.194.85.17 with SMTP id d17mr39701831wjz.61.1418820437483;
	Wed, 17 Dec 2014 04:47:17 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id wz5sm4978721wjc.29.2014.12.17.04.47.15
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Dec 2014 04:47:16 -0800 (PST)
Message-ID: <54917B43.5060903@linaro.org>
Date: Wed, 17 Dec 2014 12:46:59 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
	<5490BFBD.7010809@citrix.com> <5490C22F.4020505@linaro.org>
	<549156C1.5000708@citrix.com> <549159D4.2040304@linaro.org>
	<54916BB40200007800050317@mail.emea.novell.com>
In-Reply-To: <54916BB40200007800050317@mail.emea.novell.com>
Cc: tim@xen.org, keir@xen.org, ian.campbell@citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	mdontu@bitdefender.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 17/12/14 10:40, Jan Beulich wrote:
>>>> On 17.12.14 at 11:24, <julien.grall@linaro.org> wrote:
>> On 17/12/2014 10:11, Andrew Cooper wrote:
>>> On 16/12/14 23:37, Julien Grall wrote:
>>> Introducing a new bugframe is precicely what I meant by "this doesn't
>>> look hard".  x86 currently has one more bugframe than arm, being
>>> BUGFRAME_run_fn.
>>
>> And how do you pass the pointer of the function? As I said, ARM lacks of 
>> %c because of compiler issue.
> 
> First of all can you explain what compiler issue there is? Both
> {arm,aarch64}_print_operand() handle 'c' (but of course I can't
> tell whether correctly).

This has been added recently on aarch64 (late 2013) and there was an
outstanding bug on some version of GCC for arm
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48637)

FYI, the BUG support has been borrowed from Linux.

> And then can't you possibly find ways to deal with the # prefix
> added when not using 'c'? For the section name (if you need the
> section split in the first place) I would think a # should be fine,
> and the uses in expressions can surely be worked around by
> interposing an assembler macro (even if that macro may end up
> looking quite ugly).

We already have a working solution without BUGFRAME_run_fn. See the
implementation in xen/include/asm-arm.h.

I don't plan to work on modifying this code. But I would be happy if
someone post a patch to support BUGFRAME_run_fn.

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 Dec 17 12:48:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 12:48:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1E0f-0005D9-H7; Wed, 17 Dec 2014 12:47:21 +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 1Y1E0e-0005D4-3n
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 12:47:20 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	01/54-07724-75B71945; Wed, 17 Dec 2014 12:47:19 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418820437!14022684!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5573 invoked from network); 17 Dec 2014 12:47:17 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 12:47:17 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so20108693wgh.4
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 04:47: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
	:content-transfer-encoding;
	bh=78l0aoGZ+/YGHaDea/KHZgR45fHspBczOgPXkZiEGQ0=;
	b=RMJCsLhDO4a2VlxUp/Nwt3wYg+ToF6l3WjfPOWee8hgZvpQXePSSS8ABd3eDe8D7wq
	rIBzJqjTa2+2YYIlw0yN/g8PzeCfPL+5CREvVBE2hVKn/hHn6q3zmc9r8ozIsULCZdt9
	aYVB2YjH5dBeoYJP4zwzPj6tj4+wiy5kqX/aiN5U+QQmOJ4jetemL0C6Gl3eu2Eg7ZzM
	rQm9jalapzbHxCiIQQTS8mCXKLFqvP7FSpeNqd0b1FnTpcvT9WXvzPkW7/l3idVLNgMr
	crRAeWyLeUroYDBz2ykBmTQ/ICzxsBQLM2utqeTaxEFv9Wtk6T7A507xddwXwD/KglrN
	ZwwA==
X-Gm-Message-State: ALoCoQk7p2DRMM0URTNEFjoNTt/4vg8GbkMyrUkHsmI2/MSLtZUHo7yBP2Yk1PWjKbLgksjtcnxX
X-Received: by 10.194.85.17 with SMTP id d17mr39701831wjz.61.1418820437483;
	Wed, 17 Dec 2014 04:47:17 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id wz5sm4978721wjc.29.2014.12.17.04.47.15
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Dec 2014 04:47:16 -0800 (PST)
Message-ID: <54917B43.5060903@linaro.org>
Date: Wed, 17 Dec 2014 12:46:59 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1418758405-32200-1-git-send-email-mdontu@bitdefender.com>
	<549095E3.30202@citrix.com> <5490BAE4.5070108@linaro.org>
	<5490BFBD.7010809@citrix.com> <5490C22F.4020505@linaro.org>
	<549156C1.5000708@citrix.com> <549159D4.2040304@linaro.org>
	<54916BB40200007800050317@mail.emea.novell.com>
In-Reply-To: <54916BB40200007800050317@mail.emea.novell.com>
Cc: tim@xen.org, keir@xen.org, ian.campbell@citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	mdontu@bitdefender.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the
 pool integrity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 17/12/14 10:40, Jan Beulich wrote:
>>>> On 17.12.14 at 11:24, <julien.grall@linaro.org> wrote:
>> On 17/12/2014 10:11, Andrew Cooper wrote:
>>> On 16/12/14 23:37, Julien Grall wrote:
>>> Introducing a new bugframe is precicely what I meant by "this doesn't
>>> look hard".  x86 currently has one more bugframe than arm, being
>>> BUGFRAME_run_fn.
>>
>> And how do you pass the pointer of the function? As I said, ARM lacks of 
>> %c because of compiler issue.
> 
> First of all can you explain what compiler issue there is? Both
> {arm,aarch64}_print_operand() handle 'c' (but of course I can't
> tell whether correctly).

This has been added recently on aarch64 (late 2013) and there was an
outstanding bug on some version of GCC for arm
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48637)

FYI, the BUG support has been borrowed from Linux.

> And then can't you possibly find ways to deal with the # prefix
> added when not using 'c'? For the section name (if you need the
> section split in the first place) I would think a # should be fine,
> and the uses in expressions can surely be worked around by
> interposing an assembler macro (even if that macro may end up
> looking quite ugly).

We already have a working solution without BUGFRAME_run_fn. See the
implementation in xen/include/asm-arm.h.

I don't plan to work on modifying this code. But I would be happy if
someone post a patch to support BUGFRAME_run_fn.

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 Dec 17 12:51:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 12: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 1Y1E53-0005Nh-8P; Wed, 17 Dec 2014 12:51: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 1Y1E51-0005MS-Pr
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 12:51:51 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	60/1C-26858-76C71945; Wed, 17 Dec 2014 12:51:51 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418820708!14056891!1
X-Originating-IP: [66.165.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 8688 invoked from network); 17 Dec 2014 12:51:50 -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 Dec 2014 12:51:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205777794"
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.210.2;
	Wed, 17 Dec 2014 07:51:47 -0500
Message-ID: <54917C62.709@citrix.com>
Date: Wed, 17 Dec 2014 13:51:46 +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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel
	<xen-devel@lists.xenproject.org>
References: <54906D3D.2060807@citrix.com> <549072FE.40500@citrix.com>
In-Reply-To: <549072FE.40500@citrix.com>
Content-Length: 4868
X-DLP: MIA2
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] IO-APIC interrupts getting stuck
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RWwgMTYvMTIvMTQgYSBsZXMgMTguNTksIEFuZHJldyBDb29wZXIgaGEgZXNjcml0Ogo+IE9uIDE2
LzEyLzE0IDE3OjM0LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiBIZWxsbywKPj4KPj4gV2hp
bGUgd29ya2luZyBvbiB0aGUgRnJlZUJTRCBQVkggRG9tMCBwb3J0IEkndmUgcmVhbGl6ZWQgdGhh
dCBJTy1BUElDIAo+PiBpbnRlcnJ1cHRzIGdldCBzdHVjayBpbiBhIHZlcnkgc3RyYW5nZSBzdGF0
ZSB2ZXJ5IGVhc2lseSB3aXRoIHRoZSAKPj4gY3VycmVudCBQSVJRIGltcGxlbWVudGF0aW9uIHRo
YXQgSSdtIHVzaW5nIG9uIEZyZWVCU0QuCj4+Cj4+IFNpbmNlIEknbSBub3Qgc3VyZSB3aGF0IGlz
IGdvaW5nIG9uLCBJIHdvdWxkIGxpa2UgdG8gYXNrIGZvciBzb21lIAo+PiBmZWVkYmFjayBhbmQg
cG9zc2libGUgc29sdXRpb25zLCBiZWNhdXNlIGF0IHRoaXMgcG9pbnQgSSdtIHJ1bm5pbmcgb3V0
IAo+PiBvZiBpZGVhcyBvZiB3aGF0J3MgaGFwcGVuaW5nLgo+Pgo+PiBJbiB0aGlzIGNhc2UgSSdt
IGdvaW5nIHRvIHVzZSBJUlEgMTcgYXMgYW4gZXhhbXBsZSwgd2hpY2ggaXMgc2hhcmVkIAo+PiBi
ZXR3ZWVuIGFuIEludGVsKFIpIFBSTy8xMDAwIG5pYywgYSBCcm9hZGNvbSBOZXRYdHJlbWUgR2ln
YWJpdCBuaWMgYW5kIAo+PiBhbiBJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIu
Cj4+Cj4+IFVzdWFsbHkgZHVyaW5nIHRoZSBib290IHByb2Nlc3MsIG9yIHZlcnkgc2hvcnRseSBh
ZnRlciBpdCwgRG9tMCBsb29zZXMgCj4+IGludGVycnVwdHMgZnJvbSBJUlEgMTcsIGR1bXBpbmcg
SVJRIGluZm9ybWF0aW9uIGZyb20gWGVuICgnaScga2V5KSwgCj4+IGdpdmVzIHRoZSBmb2xsb3dp
bmcgb3V0cHV0Ogo+Pgo+PiAoWEVOKSAgICBJUlE6ICAxNyBhZmZpbml0eTowMDAwMDAwMSB2ZWM6
YTggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFp
bi1saXN0PTA6IDE3KC0tLSksCj4+IC4uLgo+PiAoWEVOKSAgICAgSVJRIDE3IFZlYzE2ODoKPj4g
KFhFTikgICAgICAgQXBpYyAweDAwLCBQaW4gMTc6IHZlYz1hOCBkZWxpdmVyeT1Mb1ByaSBkZXN0
PUwgc3RhdHVzPTEgcG9sYXJpdHk9MSBpcnI9MSB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQo+Pgo+
PiBJJ3ZlIGFsc28gYWRkZWQgc29tZSBldmVudCBjaGFubmVsIGRlYnVnIGZ1bmN0aW9ucyB0byB0
aGUgRnJlZUJTRCAKPj4gaW4ta2VybmVsIGRlYnVnZ2VyIGluIG9yZGVyIHRvIHByaW50IHRoZSBz
dGF0dXMgb2YgZXZlbnQgY2hhbm5lbHM6Cj4+Cj4+IFBvcnQgMTUgVHlwZTogUElSUQo+PiAgICAg
ICAgIFBpcnE6IDE3IEFjdGl2ZUhpOiAwIEVkZ2VUcmlnZ2VyOiAwIE5lZWRzRU9JOiAxCj4+ICAg
ICAgICAgTWFza2VkOiAwIFBlbmRpbmc6IDAKPj4gICAgICAgICBQZXItQ1BVIE1hc2tzOiBjcHUj
MDogMCBjcHUjMTogMCBjcHUjMjogMSBjcHUjMzogMCBjcHUjNDogMCBjcHUjNTogMCBjcHUjNjog
MCBjcHUjNzogMAo+Pgo+PiBBbmQgdGhlIGNvcnJlc3BvbmRpbmcgbGluZSBmcm9tIHRoZSBYZW4g
J2UnIGRlYnVnIGtleToKPj4KPj4gKFhFTikgICAgICAgMTUgWzAvMC8xXTogcz00IG49MiB4PTAg
cD0xNyBpPTE3Cj4+Cj4+IFRoaXMgbWFrZXMgbWUgdGhpbmcgdGhhdCB0aGUgRnJlZUJTRCBrZXJu
ZWwgaXMgZmFpbGluZyB0byBFT0kgdGhlIAo+PiB2ZWN0b3IgKGJlY2F1c2Ugb2YgdGhlIGlycj0x
IGluIHRoZSBYZW4gSVJRIGRlYnVnIGluZm8pLCBzbyBJJ3ZlIGFsc28gCj4+IGFkZGVkIGEgZnVu
Y3Rpb24gdG8gdGhlIGRlYnVnZ2VyIHRoYXQgYWxsb3dzIG1lIHRvIEVPSSBhIHZlY3RvciBmcm9t
IAo+PiBpdC4gQnV0IGV2ZW4gYWZ0ZXIgaXNzdWluZyBhIFBIWVNERVZPUF9lb2kgaHlwZXJjYWxs
IG9uIHRoZSBhZmZlY3RlZCAKPj4gUElSUSAoMTcpLCB0aGUgc3RhdHVzIGlzIGV4YWN0bHkgdGhl
IHNhbWUsIGJlY2F1c2UgcGlycS0+bWFza2VkID09IDAsIAo+PiBzbyBkZXNjX2d1ZXN0X2VvaSBm
YWlscyB0byBFT0kgdGhlIHZlY3RvciAoc2VlIHhlbi9hcmNoL3g4Ni9pcnEuYzoxNDMzKS4KPj4K
Pj4gU28gbm93IEknbSB3b25kZXJpbmcsIGhvdyBjYW4gSSAidW5zdHVjayIgdGhpcyBJUlEsIGFu
ZCBob3cgZGlkIGl0IGdldCAKPj4gaW50byB0aGlzIHN0cmFuZ2Ugc3RhdGU/Cj4+Cj4+IFJvZ2Vy
Lgo+IAo+IERvIHlvdSBoYXZlIGEgeGVuIGRtZXNnIHdpdGggZnVsbCBkZWJ1Z2dpbmc/ICBBY2Nv
cmRpbmcgdG8gdGhlIGZpcnN0Cj4gbGluZSBmcm9tICdpJywgWGVuIGJlbGlldmVzIHRoYXQgdGhl
IGlycSBpbiBxdWVzdGlvbiBpcyBub3QgaW4gbmVlZCBvZgo+IGFuIEVPSSwgd2hpY2ggaXMgY2xl
YXJseSBjb250cmFyeSB0byB0aGUgSU9BUElDcyB2aWV3IG9mIHRoZSB3b3JsZC4KPiAKPiBTb21l
IHJhbmRvbSBzdWdnZXN0aW9uczogZG9lcyBhbHRlcmluZyBpbnRlcnJ1cHQgcmVtYXBwaW5nIG1h
a2UgYQo+IGRpZmZlcmVuY2U/IGRvZXMgYWx0ZXJpbmcgdGhlIGlvYXBpY19hY2tfbW9kZSBtYWtl
IGEgZGlmZmVyZW5jZT8KCkkndmUgYWxzbyBhZGRlZCB0aGUgZm9sbG93aW5nIHBhdGNoIHRvIFhl
biwgYW5kIGl0IHJlbGlhYmx5IHRyaWdnZXJzIG9uIApGcmVlQlNELCB3aGlsZSBpdCBzZWVtcyB0
byB3b3JrIGZpbmUgb24gTGludXg6CgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2lvX2FwaWMu
YyBiL3hlbi9hcmNoL3g4Ni9pb19hcGljLmMKaW5kZXggNmY4ZjYyYy4uNzA5NzdkYyAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2lvX2FwaWMuYworKysgYi94ZW4vYXJjaC94ODYvaW9fYXBpYy5j
CkBAIC0xNzI5LDYgKzE3MjksOCBAQCBzdGF0aWMgdm9pZCBlbmRfbGV2ZWxfaW9hcGljX2lycV9u
ZXcoc3RydWN0IGlycV9kZXNjICpkZXNjLCB1OCB2ZWN0b3IpCiAgKiBUaGUgaWRlYSBpcyBmcm9t
IE1hbmZyZWQgU3ByYXVsLiAgLS1tYWNybwogICovCiAgICAgdW5zaWduZWQgaW50IHYsIGkgPSBk
ZXNjLT5hcmNoLnZlY3RvcjsKKyAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSBydGU7Cisg
ICAgc3RydWN0IGlycV9waW5fbGlzdCAqZW50cnkgPSBpcnFfMl9waW4gKyBkZXNjLT5pcnE7CiAK
ICAgICAvKiBNYW51YWxseSBFT0kgdGhlIG9sZCB2ZWN0b3IgaWYgd2UgYXJlIG1vdmluZyB0byB0
aGUgbmV3ICovCiAgICAgaWYgKCB2ZWN0b3IgJiYgaSAhPSB2ZWN0b3IgKQpAQCAtMTc1MSw2ICsx
NzUzLDkgQEAgc3RhdGljIHZvaWQgZW5kX2xldmVsX2lvYXBpY19pcnFfbmV3KHN0cnVjdCBpcnFf
ZGVzYyAqZGVzYywgdTggdmVjdG9yKQogICAgICAgICAgICAgX191bm1hc2tfSU9fQVBJQ19pcnEo
ZGVzYy0+aXJxKTsKICAgICAgICAgc3Bpbl91bmxvY2soJmlvYXBpY19sb2NrKTsKICAgICB9CisK
KyAgICBydGUgPSBpb2FwaWNfcmVhZF9lbnRyeShlbnRyeS0+YXBpYywgZW50cnktPnBpbiwgMCk7
CisgICAgQVNTRVJUKHJ0ZS5pcnIgPT0gMCB8fCBydGUubWFzayAhPSAwKTsKIH0KIAogLyoKCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Dec 17 12:51:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 12: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 1Y1E53-0005Nh-8P; Wed, 17 Dec 2014 12:51: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 1Y1E51-0005MS-Pr
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 12:51:51 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	60/1C-26858-76C71945; Wed, 17 Dec 2014 12:51:51 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418820708!14056891!1
X-Originating-IP: [66.165.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 8688 invoked from network); 17 Dec 2014 12:51:50 -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 Dec 2014 12:51:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="205777794"
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.210.2;
	Wed, 17 Dec 2014 07:51:47 -0500
Message-ID: <54917C62.709@citrix.com>
Date: Wed, 17 Dec 2014 13:51:46 +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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel
	<xen-devel@lists.xenproject.org>
References: <54906D3D.2060807@citrix.com> <549072FE.40500@citrix.com>
In-Reply-To: <549072FE.40500@citrix.com>
Content-Length: 4868
X-DLP: MIA2
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] IO-APIC interrupts getting stuck
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RWwgMTYvMTIvMTQgYSBsZXMgMTguNTksIEFuZHJldyBDb29wZXIgaGEgZXNjcml0Ogo+IE9uIDE2
LzEyLzE0IDE3OjM0LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiBIZWxsbywKPj4KPj4gV2hp
bGUgd29ya2luZyBvbiB0aGUgRnJlZUJTRCBQVkggRG9tMCBwb3J0IEkndmUgcmVhbGl6ZWQgdGhh
dCBJTy1BUElDIAo+PiBpbnRlcnJ1cHRzIGdldCBzdHVjayBpbiBhIHZlcnkgc3RyYW5nZSBzdGF0
ZSB2ZXJ5IGVhc2lseSB3aXRoIHRoZSAKPj4gY3VycmVudCBQSVJRIGltcGxlbWVudGF0aW9uIHRo
YXQgSSdtIHVzaW5nIG9uIEZyZWVCU0QuCj4+Cj4+IFNpbmNlIEknbSBub3Qgc3VyZSB3aGF0IGlz
IGdvaW5nIG9uLCBJIHdvdWxkIGxpa2UgdG8gYXNrIGZvciBzb21lIAo+PiBmZWVkYmFjayBhbmQg
cG9zc2libGUgc29sdXRpb25zLCBiZWNhdXNlIGF0IHRoaXMgcG9pbnQgSSdtIHJ1bm5pbmcgb3V0
IAo+PiBvZiBpZGVhcyBvZiB3aGF0J3MgaGFwcGVuaW5nLgo+Pgo+PiBJbiB0aGlzIGNhc2UgSSdt
IGdvaW5nIHRvIHVzZSBJUlEgMTcgYXMgYW4gZXhhbXBsZSwgd2hpY2ggaXMgc2hhcmVkIAo+PiBi
ZXR3ZWVuIGFuIEludGVsKFIpIFBSTy8xMDAwIG5pYywgYSBCcm9hZGNvbSBOZXRYdHJlbWUgR2ln
YWJpdCBuaWMgYW5kIAo+PiBhbiBJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIu
Cj4+Cj4+IFVzdWFsbHkgZHVyaW5nIHRoZSBib290IHByb2Nlc3MsIG9yIHZlcnkgc2hvcnRseSBh
ZnRlciBpdCwgRG9tMCBsb29zZXMgCj4+IGludGVycnVwdHMgZnJvbSBJUlEgMTcsIGR1bXBpbmcg
SVJRIGluZm9ybWF0aW9uIGZyb20gWGVuICgnaScga2V5KSwgCj4+IGdpdmVzIHRoZSBmb2xsb3dp
bmcgb3V0cHV0Ogo+Pgo+PiAoWEVOKSAgICBJUlE6ICAxNyBhZmZpbml0eTowMDAwMDAwMSB2ZWM6
YTggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFp
bi1saXN0PTA6IDE3KC0tLSksCj4+IC4uLgo+PiAoWEVOKSAgICAgSVJRIDE3IFZlYzE2ODoKPj4g
KFhFTikgICAgICAgQXBpYyAweDAwLCBQaW4gMTc6IHZlYz1hOCBkZWxpdmVyeT1Mb1ByaSBkZXN0
PUwgc3RhdHVzPTEgcG9sYXJpdHk9MSBpcnI9MSB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQo+Pgo+
PiBJJ3ZlIGFsc28gYWRkZWQgc29tZSBldmVudCBjaGFubmVsIGRlYnVnIGZ1bmN0aW9ucyB0byB0
aGUgRnJlZUJTRCAKPj4gaW4ta2VybmVsIGRlYnVnZ2VyIGluIG9yZGVyIHRvIHByaW50IHRoZSBz
dGF0dXMgb2YgZXZlbnQgY2hhbm5lbHM6Cj4+Cj4+IFBvcnQgMTUgVHlwZTogUElSUQo+PiAgICAg
ICAgIFBpcnE6IDE3IEFjdGl2ZUhpOiAwIEVkZ2VUcmlnZ2VyOiAwIE5lZWRzRU9JOiAxCj4+ICAg
ICAgICAgTWFza2VkOiAwIFBlbmRpbmc6IDAKPj4gICAgICAgICBQZXItQ1BVIE1hc2tzOiBjcHUj
MDogMCBjcHUjMTogMCBjcHUjMjogMSBjcHUjMzogMCBjcHUjNDogMCBjcHUjNTogMCBjcHUjNjog
MCBjcHUjNzogMAo+Pgo+PiBBbmQgdGhlIGNvcnJlc3BvbmRpbmcgbGluZSBmcm9tIHRoZSBYZW4g
J2UnIGRlYnVnIGtleToKPj4KPj4gKFhFTikgICAgICAgMTUgWzAvMC8xXTogcz00IG49MiB4PTAg
cD0xNyBpPTE3Cj4+Cj4+IFRoaXMgbWFrZXMgbWUgdGhpbmcgdGhhdCB0aGUgRnJlZUJTRCBrZXJu
ZWwgaXMgZmFpbGluZyB0byBFT0kgdGhlIAo+PiB2ZWN0b3IgKGJlY2F1c2Ugb2YgdGhlIGlycj0x
IGluIHRoZSBYZW4gSVJRIGRlYnVnIGluZm8pLCBzbyBJJ3ZlIGFsc28gCj4+IGFkZGVkIGEgZnVu
Y3Rpb24gdG8gdGhlIGRlYnVnZ2VyIHRoYXQgYWxsb3dzIG1lIHRvIEVPSSBhIHZlY3RvciBmcm9t
IAo+PiBpdC4gQnV0IGV2ZW4gYWZ0ZXIgaXNzdWluZyBhIFBIWVNERVZPUF9lb2kgaHlwZXJjYWxs
IG9uIHRoZSBhZmZlY3RlZCAKPj4gUElSUSAoMTcpLCB0aGUgc3RhdHVzIGlzIGV4YWN0bHkgdGhl
IHNhbWUsIGJlY2F1c2UgcGlycS0+bWFza2VkID09IDAsIAo+PiBzbyBkZXNjX2d1ZXN0X2VvaSBm
YWlscyB0byBFT0kgdGhlIHZlY3RvciAoc2VlIHhlbi9hcmNoL3g4Ni9pcnEuYzoxNDMzKS4KPj4K
Pj4gU28gbm93IEknbSB3b25kZXJpbmcsIGhvdyBjYW4gSSAidW5zdHVjayIgdGhpcyBJUlEsIGFu
ZCBob3cgZGlkIGl0IGdldCAKPj4gaW50byB0aGlzIHN0cmFuZ2Ugc3RhdGU/Cj4+Cj4+IFJvZ2Vy
Lgo+IAo+IERvIHlvdSBoYXZlIGEgeGVuIGRtZXNnIHdpdGggZnVsbCBkZWJ1Z2dpbmc/ICBBY2Nv
cmRpbmcgdG8gdGhlIGZpcnN0Cj4gbGluZSBmcm9tICdpJywgWGVuIGJlbGlldmVzIHRoYXQgdGhl
IGlycSBpbiBxdWVzdGlvbiBpcyBub3QgaW4gbmVlZCBvZgo+IGFuIEVPSSwgd2hpY2ggaXMgY2xl
YXJseSBjb250cmFyeSB0byB0aGUgSU9BUElDcyB2aWV3IG9mIHRoZSB3b3JsZC4KPiAKPiBTb21l
IHJhbmRvbSBzdWdnZXN0aW9uczogZG9lcyBhbHRlcmluZyBpbnRlcnJ1cHQgcmVtYXBwaW5nIG1h
a2UgYQo+IGRpZmZlcmVuY2U/IGRvZXMgYWx0ZXJpbmcgdGhlIGlvYXBpY19hY2tfbW9kZSBtYWtl
IGEgZGlmZmVyZW5jZT8KCkkndmUgYWxzbyBhZGRlZCB0aGUgZm9sbG93aW5nIHBhdGNoIHRvIFhl
biwgYW5kIGl0IHJlbGlhYmx5IHRyaWdnZXJzIG9uIApGcmVlQlNELCB3aGlsZSBpdCBzZWVtcyB0
byB3b3JrIGZpbmUgb24gTGludXg6CgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2lvX2FwaWMu
YyBiL3hlbi9hcmNoL3g4Ni9pb19hcGljLmMKaW5kZXggNmY4ZjYyYy4uNzA5NzdkYyAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2lvX2FwaWMuYworKysgYi94ZW4vYXJjaC94ODYvaW9fYXBpYy5j
CkBAIC0xNzI5LDYgKzE3MjksOCBAQCBzdGF0aWMgdm9pZCBlbmRfbGV2ZWxfaW9hcGljX2lycV9u
ZXcoc3RydWN0IGlycV9kZXNjICpkZXNjLCB1OCB2ZWN0b3IpCiAgKiBUaGUgaWRlYSBpcyBmcm9t
IE1hbmZyZWQgU3ByYXVsLiAgLS1tYWNybwogICovCiAgICAgdW5zaWduZWQgaW50IHYsIGkgPSBk
ZXNjLT5hcmNoLnZlY3RvcjsKKyAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSBydGU7Cisg
ICAgc3RydWN0IGlycV9waW5fbGlzdCAqZW50cnkgPSBpcnFfMl9waW4gKyBkZXNjLT5pcnE7CiAK
ICAgICAvKiBNYW51YWxseSBFT0kgdGhlIG9sZCB2ZWN0b3IgaWYgd2UgYXJlIG1vdmluZyB0byB0
aGUgbmV3ICovCiAgICAgaWYgKCB2ZWN0b3IgJiYgaSAhPSB2ZWN0b3IgKQpAQCAtMTc1MSw2ICsx
NzUzLDkgQEAgc3RhdGljIHZvaWQgZW5kX2xldmVsX2lvYXBpY19pcnFfbmV3KHN0cnVjdCBpcnFf
ZGVzYyAqZGVzYywgdTggdmVjdG9yKQogICAgICAgICAgICAgX191bm1hc2tfSU9fQVBJQ19pcnEo
ZGVzYy0+aXJxKTsKICAgICAgICAgc3Bpbl91bmxvY2soJmlvYXBpY19sb2NrKTsKICAgICB9CisK
KyAgICBydGUgPSBpb2FwaWNfcmVhZF9lbnRyeShlbnRyeS0+YXBpYywgZW50cnktPnBpbiwgMCk7
CisgICAgQVNTRVJUKHJ0ZS5pcnIgPT0gMCB8fCBydGUubWFzayAhPSAwKTsKIH0KIAogLyoKCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Dec 17 12:55:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 12: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 1Y1E8G-0005is-2S; Wed, 17 Dec 2014 12:55:12 +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 1Y1E8E-0005im-N8
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 12:55:10 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	DB/2A-20609-E2D71945; Wed, 17 Dec 2014 12:55:10 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418820909!10227915!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22838 invoked from network); 17 Dec 2014 12:55:09 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 12:55:09 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so20273015wgg.0
	for <xen-devel@lists.xenproject.org>;
	Wed, 17 Dec 2014 04:55: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=FwAiTW3Xo3gRox/Yq2ficPIp3o+ZMfz5IHMjmzvoe08=;
	b=Iq7S3jSL7nKWYmOWTciUWzFaMtV3HEF4swVa3OfViyYtSTe9Hw2CtevOkr+CYZdmLq
	394TiWbkvm7C1E3XbfX8pRvL79pTZVUVP1siyvIo2Urv6WPfCbUyyposBxYWH28AWSDT
	KJpjlAEMXbAgsaZ9mDemBQxs4e3WXOJz8qw9TAiLpg+Lb0AuRCAV86ll5ahKqlR5s1/C
	f6Yk6NV4DYaKpBy9UT+ST8aY0mxE/PHkZ4PUrDlqXZUhjlBPtn5u8ehg14UZpB3Toq48
	1XMKdD49nLE/fj3uABtFjaAAA73m7xSsdehvXhE3t1nglZdqnsQvrmwYz/rKelH1uswp
	4oNg==
X-Gm-Message-State: ALoCoQmSXn4aQzq2Ogf9243FhGx+Ev08Sxfyqdq5T6eSc0wDcDlvkLx+bJBLgTcdFECmIdZonjoD
X-Received: by 10.180.221.72 with SMTP id qc8mr14412630wic.19.1418820909058;
	Wed, 17 Dec 2014 04:55:09 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id hz9sm5018224wjb.17.2014.12.17.04.55.07
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Dec 2014 04:55:08 -0800 (PST)
Message-ID: <54917D1C.3080908@linaro.org>
Date: Wed, 17 Dec 2014 12:54:52 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-4-git-send-email-julien.grall@linaro.org>
	<5491636F020000780005027B@mail.emea.novell.com>
In-Reply-To: <5491636F020000780005027B@mail.emea.novell.com>
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE
	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

Hi Jan,

On 17/12/14 10:05, Jan Beulich wrote:
>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>> --- a/xen/include/xen/compiler.h
>> +++ b/xen/include/xen/compiler.h
>> @@ -90,4 +90,18 @@
>>      __asm__ ("" : "=r"(__ptr) : "0"(ptr));      \
>>      (typeof(ptr)) (__ptr + (off)); })
>>  
>> +/*
>> + * Prevent the compiler from merging or refetching accesses.  The compiler
>> + * is also forbidden from reordering successive instances of ACCESS_ONCE(),
>> + * but only when the compiler is aware of some particular ordering.  One way
>> + * to make the compiler aware of ordering is to put the two invocations of
>> + * ACCESS_ONCE() in different C statements.
>> + *
>> + * This macro does absolutely -nothing- to prevent the CPU from reordering,
>> + * merging, or refetching absolutely anything at any time.  Its main intended
>> + * use is to mediate communication between process-level code and irq/NMI
>> + * handlers, all running on the same CPU.
>> + */
>> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
> 
> Any reason not to simply use {read,write}_atomic() instead, which we
> already have?

To avoid modifying Linux drivers when it's not necessary and doesn't harm.

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 Dec 17 12:55:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 12: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 1Y1E8G-0005is-2S; Wed, 17 Dec 2014 12:55:12 +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 1Y1E8E-0005im-N8
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 12:55:10 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	DB/2A-20609-E2D71945; Wed, 17 Dec 2014 12:55:10 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418820909!10227915!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22838 invoked from network); 17 Dec 2014 12:55:09 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 12:55:09 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so20273015wgg.0
	for <xen-devel@lists.xenproject.org>;
	Wed, 17 Dec 2014 04:55: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=FwAiTW3Xo3gRox/Yq2ficPIp3o+ZMfz5IHMjmzvoe08=;
	b=Iq7S3jSL7nKWYmOWTciUWzFaMtV3HEF4swVa3OfViyYtSTe9Hw2CtevOkr+CYZdmLq
	394TiWbkvm7C1E3XbfX8pRvL79pTZVUVP1siyvIo2Urv6WPfCbUyyposBxYWH28AWSDT
	KJpjlAEMXbAgsaZ9mDemBQxs4e3WXOJz8qw9TAiLpg+Lb0AuRCAV86ll5ahKqlR5s1/C
	f6Yk6NV4DYaKpBy9UT+ST8aY0mxE/PHkZ4PUrDlqXZUhjlBPtn5u8ehg14UZpB3Toq48
	1XMKdD49nLE/fj3uABtFjaAAA73m7xSsdehvXhE3t1nglZdqnsQvrmwYz/rKelH1uswp
	4oNg==
X-Gm-Message-State: ALoCoQmSXn4aQzq2Ogf9243FhGx+Ev08Sxfyqdq5T6eSc0wDcDlvkLx+bJBLgTcdFECmIdZonjoD
X-Received: by 10.180.221.72 with SMTP id qc8mr14412630wic.19.1418820909058;
	Wed, 17 Dec 2014 04:55:09 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id hz9sm5018224wjb.17.2014.12.17.04.55.07
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Dec 2014 04:55:08 -0800 (PST)
Message-ID: <54917D1C.3080908@linaro.org>
Date: Wed, 17 Dec 2014 12:54:52 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-4-git-send-email-julien.grall@linaro.org>
	<5491636F020000780005027B@mail.emea.novell.com>
In-Reply-To: <5491636F020000780005027B@mail.emea.novell.com>
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, Ian Jackson <ian.jackson@eu.citrix.com>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE
	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

Hi Jan,

On 17/12/14 10:05, Jan Beulich wrote:
>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>> --- a/xen/include/xen/compiler.h
>> +++ b/xen/include/xen/compiler.h
>> @@ -90,4 +90,18 @@
>>      __asm__ ("" : "=r"(__ptr) : "0"(ptr));      \
>>      (typeof(ptr)) (__ptr + (off)); })
>>  
>> +/*
>> + * Prevent the compiler from merging or refetching accesses.  The compiler
>> + * is also forbidden from reordering successive instances of ACCESS_ONCE(),
>> + * but only when the compiler is aware of some particular ordering.  One way
>> + * to make the compiler aware of ordering is to put the two invocations of
>> + * ACCESS_ONCE() in different C statements.
>> + *
>> + * This macro does absolutely -nothing- to prevent the CPU from reordering,
>> + * merging, or refetching absolutely anything at any time.  Its main intended
>> + * use is to mediate communication between process-level code and irq/NMI
>> + * handlers, all running on the same CPU.
>> + */
>> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
> 
> Any reason not to simply use {read,write}_atomic() instead, which we
> already have?

To avoid modifying Linux drivers when it's not necessary and doesn't harm.

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 Dec 17 13:04:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 13: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 1Y1EGj-00063G-B4; Wed, 17 Dec 2014 13:03: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 1Y1EGh-00063B-PK
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 13:03:55 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	A9/14-26652-B3F71945; Wed, 17 Dec 2014 13:03:55 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418821434!13852618!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9077 invoked from network); 17 Dec 2014 13:03:54 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 13:03:54 -0000
Received: by mail-wg0-f47.google.com with SMTP id n12so20226244wgh.34
	for <xen-devel@lists.xenproject.org>;
	Wed, 17 Dec 2014 05:03: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=AwxeUmFtE8aMcVoCCwbmx6NBAfDy5xJnf5QFPtKPco8=;
	b=Ju1J1UK/ENKuGDfI13HFtfLZR2WFndWq6E8X/ZY6vdaAfxB6rbxh7QiFpiHyYsffAZ
	l8JXG7rJQkpnqO0LdRHvS4t27SHpCU27rb8mHRoBSPgu1laO+xXFA/RZuadUzjnJM/30
	+iE+IXyBk67DdsGQYvVYlA0zleICz42tgdCZwJPsX1ja6nF+SNLSSwNCLeW64pPOBRQl
	O8rTmJOypwFLGWUKTurc8A0ooml6RyLMrHPX3/KdQHjwrfRaXG1c0FQemN6ek3E8mEMr
	8rSHhKDC948n7hdH82Z9i7Q376eirWdvgwHQNgAtMX8bgZFE34M4lHuABZRJDoReyS7p
	p39g==
X-Gm-Message-State: ALoCoQllNHcMjOX/K0+KEzA5od9bg4FK+LK0Jy67p99i+o6udzD99Im3bbTUBncoReTx4HQ/Rflu
X-Received: by 10.180.160.144 with SMTP id xk16mr14725924wib.12.1418821434030; 
	Wed, 17 Dec 2014 05:03:54 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id l9sm20872983wic.21.2014.12.17.05.03.52
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Dec 2014 05:03:53 -0800 (PST)
Message-ID: <54917F29.8070901@linaro.org>
Date: Wed, 17 Dec 2014 13:03:37 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
	<54915B3E.4010702@linaro.org>
	<54916CFA020000780005032F@mail.emea.novell.com>
In-Reply-To: <54916CFA020000780005032F@mail.emea.novell.com>
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com, tim@xen.org,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe 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 Jan,

On 17/12/14 10:46, Jan Beulich wrote:
>>>> On 17.12.14 at 11:30, <julien.grall@linaro.org> wrote:
>> On 17/12/2014 10:16, Jan Beulich wrote:
>>>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>>>> --- a/xen/common/Makefile
>>>> +++ b/xen/common/Makefile
>>>> @@ -2,6 +2,7 @@ obj-y += bitmap.o
>>>>   obj-y += core_parking.o
>>>>   obj-y += cpu.o
>>>>   obj-y += cpupool.o
>>>> +obj-y += device.o
>>>
>>> Shouldn't this instead be two lines, one using HAS_PCI and the second
>>> HAS_DEVICE_TREE?
>>
>> When ARM will gain PCI will, it will fail to compile because device.o is 
>> included twice.
> 
> Not necessarily: If we don't do this already, we should eliminate
> duplicates from $(obj-y) just like Linux does.

I will give a look.

>>>> @@ -75,8 +76,19 @@ struct pci_dev {
>>>>   #define PT_FAULT_THRESHOLD 10
>>>>       } fault;
>>>>       u64 vf_rlen[6];
>>>> +
>>>> +    struct device dev;
>>>>   };
>>>
>>> I'm not convinced yet that growing this structure (of which we have
>>> quite many instances on some systems) is really worth it, in particular
>>> on x86 where we (so far) only have one device type anyway.
>>
>> Actually this will growing by only sizeof (enum type) on x86.
> 
> No, by 8 bytes (due to padding).

>> Having a generic way to describe device will really help ARM code (see 
>> IOMMU).
>>
>> If we don't have a such thing, we may need to duplicate quite a lots of 
>> code. Which will make hard to maintain.
> 
> Not really, if e.g. "device" was simply an alias of "pci_dev" on x86.

How many pci_dev instance you could have on a platform? 1000? Though it
might be a high value but that mean we use 2k more of RAM.

It doesn't seem to bad for the benefit to have a clear code.

>>>> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
>>>> +
>>>> +static inline struct pci_dev *dev_to_pci(struct device *dev)
>>>> +{
>>>> +    ASSERT(dev->type == DEV_PCI);
>>>> +
>>>> +    return container_of(dev, struct pci_dev, dev);
>>>> +}
>>>
>>> While the former is const-correct, I dislike the inability of passing
>>> pointers to const into helper functions like the latter. I can't think
>>> of a good solution other than introducing a second const variant
>>> of it, but I suppose we should try to find alternatives before
>>> adding such a construct that moves us in a direction opposite to
>>> getting our code more const-correct.
>>
>> Oh right. I didn't though about that case. I will turn this inline 
>> function into a macro.
> 
> I'm afraid that won't help, as you still need to specify a type as
> 2nd argument to container_of(), and that type can't be both
> const and non-const at the same time, i.e. you can't easily
> inherit the const-ness of the passed in pointer.

I agree that we will drop the const-ness. But is it really an issue?

We won't have many place where we don't want to modify the pci_dev.

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 Dec 17 13:04:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 13: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 1Y1EGj-00063G-B4; Wed, 17 Dec 2014 13:03: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 1Y1EGh-00063B-PK
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 13:03:55 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	A9/14-26652-B3F71945; Wed, 17 Dec 2014 13:03:55 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418821434!13852618!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9077 invoked from network); 17 Dec 2014 13:03:54 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 13:03:54 -0000
Received: by mail-wg0-f47.google.com with SMTP id n12so20226244wgh.34
	for <xen-devel@lists.xenproject.org>;
	Wed, 17 Dec 2014 05:03: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=AwxeUmFtE8aMcVoCCwbmx6NBAfDy5xJnf5QFPtKPco8=;
	b=Ju1J1UK/ENKuGDfI13HFtfLZR2WFndWq6E8X/ZY6vdaAfxB6rbxh7QiFpiHyYsffAZ
	l8JXG7rJQkpnqO0LdRHvS4t27SHpCU27rb8mHRoBSPgu1laO+xXFA/RZuadUzjnJM/30
	+iE+IXyBk67DdsGQYvVYlA0zleICz42tgdCZwJPsX1ja6nF+SNLSSwNCLeW64pPOBRQl
	O8rTmJOypwFLGWUKTurc8A0ooml6RyLMrHPX3/KdQHjwrfRaXG1c0FQemN6ek3E8mEMr
	8rSHhKDC948n7hdH82Z9i7Q376eirWdvgwHQNgAtMX8bgZFE34M4lHuABZRJDoReyS7p
	p39g==
X-Gm-Message-State: ALoCoQllNHcMjOX/K0+KEzA5od9bg4FK+LK0Jy67p99i+o6udzD99Im3bbTUBncoReTx4HQ/Rflu
X-Received: by 10.180.160.144 with SMTP id xk16mr14725924wib.12.1418821434030; 
	Wed, 17 Dec 2014 05:03:54 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id l9sm20872983wic.21.2014.12.17.05.03.52
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Dec 2014 05:03:53 -0800 (PST)
Message-ID: <54917F29.8070901@linaro.org>
Date: Wed, 17 Dec 2014 13:03:37 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
	<54915B3E.4010702@linaro.org>
	<54916CFA020000780005032F@mail.emea.novell.com>
In-Reply-To: <54916CFA020000780005032F@mail.emea.novell.com>
Cc: Keir Fraser <keir@xen.org>, ian.campbell@citrix.com,
	manish.jaggi@caviumnetworks.com, tim@xen.org,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe 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 Jan,

On 17/12/14 10:46, Jan Beulich wrote:
>>>> On 17.12.14 at 11:30, <julien.grall@linaro.org> wrote:
>> On 17/12/2014 10:16, Jan Beulich wrote:
>>>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>>>> --- a/xen/common/Makefile
>>>> +++ b/xen/common/Makefile
>>>> @@ -2,6 +2,7 @@ obj-y += bitmap.o
>>>>   obj-y += core_parking.o
>>>>   obj-y += cpu.o
>>>>   obj-y += cpupool.o
>>>> +obj-y += device.o
>>>
>>> Shouldn't this instead be two lines, one using HAS_PCI and the second
>>> HAS_DEVICE_TREE?
>>
>> When ARM will gain PCI will, it will fail to compile because device.o is 
>> included twice.
> 
> Not necessarily: If we don't do this already, we should eliminate
> duplicates from $(obj-y) just like Linux does.

I will give a look.

>>>> @@ -75,8 +76,19 @@ struct pci_dev {
>>>>   #define PT_FAULT_THRESHOLD 10
>>>>       } fault;
>>>>       u64 vf_rlen[6];
>>>> +
>>>> +    struct device dev;
>>>>   };
>>>
>>> I'm not convinced yet that growing this structure (of which we have
>>> quite many instances on some systems) is really worth it, in particular
>>> on x86 where we (so far) only have one device type anyway.
>>
>> Actually this will growing by only sizeof (enum type) on x86.
> 
> No, by 8 bytes (due to padding).

>> Having a generic way to describe device will really help ARM code (see 
>> IOMMU).
>>
>> If we don't have a such thing, we may need to duplicate quite a lots of 
>> code. Which will make hard to maintain.
> 
> Not really, if e.g. "device" was simply an alias of "pci_dev" on x86.

How many pci_dev instance you could have on a platform? 1000? Though it
might be a high value but that mean we use 2k more of RAM.

It doesn't seem to bad for the benefit to have a clear code.

>>>> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
>>>> +
>>>> +static inline struct pci_dev *dev_to_pci(struct device *dev)
>>>> +{
>>>> +    ASSERT(dev->type == DEV_PCI);
>>>> +
>>>> +    return container_of(dev, struct pci_dev, dev);
>>>> +}
>>>
>>> While the former is const-correct, I dislike the inability of passing
>>> pointers to const into helper functions like the latter. I can't think
>>> of a good solution other than introducing a second const variant
>>> of it, but I suppose we should try to find alternatives before
>>> adding such a construct that moves us in a direction opposite to
>>> getting our code more const-correct.
>>
>> Oh right. I didn't though about that case. I will turn this inline 
>> function into a macro.
> 
> I'm afraid that won't help, as you still need to specify a type as
> 2nd argument to container_of(), and that type can't be both
> const and non-const at the same time, i.e. you can't easily
> inherit the const-ness of the passed in pointer.

I agree that we will drop the const-ness. But is it really an issue?

We won't have many place where we don't want to modify the pci_dev.

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 Dec 17 14:01:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 14:01:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1FAE-0007SN-5H; Wed, 17 Dec 2014 14:01:18 +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 1Y1FAC-0007SI-2U
	for Xen-devel@lists.xen.org; Wed, 17 Dec 2014 14:01:16 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	38/13-17694-BAC81945; Wed, 17 Dec 2014 14:01:15 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418824872!14079469!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28426 invoked from network); 17 Dec 2014 14:01:14 -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;
	17 Dec 2014 14:01:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208";a="205803350"
Message-ID: <54918C89.1020409@citrix.com>
Date: Wed, 17 Dec 2014 14:00:41 +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: David Vrabel <david.vrabel@citrix.com>, John <jw@nuclearfallout.net>
References: <54884DA8.7030003@nuclearfallout.net> <548854C3.7060008@citrix.com>
In-Reply-To: <548854C3.7060008@citrix.com>
X-DLP: MIA1
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	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] xen-netback: make feature-rx-notify mandatory --
 Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 14:12, David Vrabel wrote:
> On 10/12/14 13:42, John wrote:
>> David,
>>
>> This patch you put into 3.18.0 appears to break the latest version of
>> stubdomains. I found this out today when I tried to update a machine to
>> 3.18.0 and all of the domUs crashed on start with the dmesg output like
>> this:
> 
> Cc'ing the lists and relevant netback maintainers.
> 
> I guess the stubdoms are using minios's netfront?  This is something I
> forgot about when deciding if it was ok to make this feature mandatory.
> 
> The patch cannot be reverted as it's a prerequisite for a critical
> (security) bug fix.  I am also unconvinced that the no-feature-rx-notify
> support worked correctly anyway.
> 
> This can be resolved by:
> 
> - Fixing minios's netfront to support feature-rx-notify. This should be
> easy but wouldn't help existing Xen deployments.
> 
> Or:
> 
> - Reimplement feature-rx-notify support.  I think the easiest way is to
> queue packets on the guest Rx internal queue with a short expiry time.

This patch works for me.  I tested it with a hacked Linux frontend that
disabled feature-rx-notify, but not with a stubdom.

Can you give it a try, please?

David

8<--------------------------------------------------------------
xen-netback: support frontends without feature-rx-notify again

Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
feature-rx-notify mandatory) incorrectly assumed that there were no
frontends in use that did not support this feature.  But the frontend
driver in MiniOS does not and since this is used by (qemu) stubdoms,
these stopped working.

Netback sort of works as-is in this mode except:

- If there are no Rx requests and the internal Rx queue fills, only the
  drain timeout will wake the thread.  The default drain timeout of 10 s
  would give unacceptable pauses.

- If an Rx stall was detected and the internal Rx queue is drained, then
  the Rx thread would never wake.

Handle these two cases (when feature-rx-notify is disabled) by:

- Reducing the drain timeout to 30 ms.

- Disabling Rx stall detection.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/common.h    |    4 +++-
 drivers/net/xen-netback/interface.c |    4 +++-
 drivers/net/xen-netback/netback.c   |   27 ++++++++++++++-------------
 drivers/net/xen-netback/xenbus.c    |   12 +++++++++---
 4 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 083ecc9..5f1fda4 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -230,6 +230,8 @@ struct xenvif {
 	 */
 	bool disabled;
 	unsigned long status;
+	unsigned long drain_timeout;
+	unsigned long stall_timeout;
 
 	/* Queues */
 	struct xenvif_queue *queues;
@@ -328,7 +330,7 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id);
 extern bool separate_tx_rx_irq;
 
 extern unsigned int rx_drain_timeout_msecs;
-extern unsigned int rx_drain_timeout_jiffies;
+extern unsigned int rx_stall_timeout_msecs;
 extern unsigned int xenvif_max_queues;
 
 #ifdef CONFIG_DEBUG_FS
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index a6a32d3..9259a73 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -166,7 +166,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	cb = XENVIF_RX_CB(skb);
-	cb->expires = jiffies + rx_drain_timeout_jiffies;
+	cb->expires = jiffies + vif->drain_timeout;
 
 	xenvif_rx_queue_tail(queue, skb);
 	xenvif_kick_thread(queue);
@@ -414,6 +414,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif->ip_csum = 1;
 	vif->dev = dev;
 	vif->disabled = false;
+	vif->drain_timeout = msecs_to_jiffies(rx_drain_timeout_msecs);
+	vif->stall_timeout = msecs_to_jiffies(rx_stall_timeout_msecs);
 
 	/* Start out with no queues. */
 	vif->queues = NULL;
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 4a509f7..b0292e4 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -60,14 +60,12 @@ module_param(separate_tx_rx_irq, bool, 0644);
  */
 unsigned int rx_drain_timeout_msecs = 10000;
 module_param(rx_drain_timeout_msecs, uint, 0444);
-unsigned int rx_drain_timeout_jiffies;
 
 /* The length of time before the frontend is considered unresponsive
  * because it isn't providing Rx slots.
  */
-static unsigned int rx_stall_timeout_msecs = 60000;
+unsigned int rx_stall_timeout_msecs = 60000;
 module_param(rx_stall_timeout_msecs, uint, 0444);
-static unsigned int rx_stall_timeout_jiffies;
 
 unsigned int xenvif_max_queues;
 module_param_named(max_queues, xenvif_max_queues, uint, 0644);
@@ -2020,7 +2018,7 @@ static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)
 	return !queue->stalled
 		&& prod - cons < XEN_NETBK_RX_SLOTS_MAX
 		&& time_after(jiffies,
-			      queue->last_rx_time + rx_stall_timeout_jiffies);
+			      queue->last_rx_time + queue->vif->stall_timeout);
 }
 
 static bool xenvif_rx_queue_ready(struct xenvif_queue *queue)
@@ -2038,8 +2036,9 @@ static bool xenvif_have_rx_work(struct xenvif_queue *queue)
 {
 	return (!skb_queue_empty(&queue->rx_queue)
 		&& xenvif_rx_ring_slots_available(queue, XEN_NETBK_RX_SLOTS_MAX))
-		|| xenvif_rx_queue_stalled(queue)
-		|| xenvif_rx_queue_ready(queue)
+		|| (queue->vif->stall_timeout &&
+		    (xenvif_rx_queue_stalled(queue)
+		     || xenvif_rx_queue_ready(queue)))
 		|| kthread_should_stop()
 		|| queue->vif->disabled;
 }
@@ -2092,6 +2091,9 @@ int xenvif_kthread_guest_rx(void *data)
 	struct xenvif_queue *queue = data;
 	struct xenvif *vif = queue->vif;
 
+	if (!vif->stall_timeout)
+		xenvif_queue_carrier_on(queue);
+
 	for (;;) {
 		xenvif_wait_for_rx_work(queue);
 
@@ -2118,10 +2120,12 @@ int xenvif_kthread_guest_rx(void *data)
 		 * while it's probably not responsive, drop the
 		 * carrier so packets are dropped earlier.
 		 */
-		if (xenvif_rx_queue_stalled(queue))
-			xenvif_queue_carrier_off(queue);
-		else if (xenvif_rx_queue_ready(queue))
-			xenvif_queue_carrier_on(queue);
+		if (queue->vif->stall_timeout) {
+			if (xenvif_rx_queue_stalled(queue))
+				xenvif_queue_carrier_off(queue);
+			else if (xenvif_rx_queue_ready(queue))
+				xenvif_queue_carrier_on(queue);
+		}
 
 		/* Queued packets may have foreign pages from other
 		 * domains.  These cannot be queued indefinitely as
@@ -2192,9 +2196,6 @@ static int __init netback_init(void)
 	if (rc)
 		goto failed_init;
 
-	rx_drain_timeout_jiffies = msecs_to_jiffies(rx_drain_timeout_msecs);
-	rx_stall_timeout_jiffies = msecs_to_jiffies(rx_stall_timeout_msecs);
-
 #ifdef CONFIG_DEBUG_FS
 	xen_netback_dbg_root = debugfs_create_dir("xen-netback", NULL);
 	if (IS_ERR_OR_NULL(xen_netback_dbg_root))
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index d44cd19..efbaf2a 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -887,9 +887,15 @@ static int read_xenbus_vif_flags(struct backend_info *be)
 		return -EOPNOTSUPP;
 
 	if (xenbus_scanf(XBT_NIL, dev->otherend,
-			 "feature-rx-notify", "%d", &val) < 0 || val == 0) {
-		xenbus_dev_fatal(dev, -EINVAL, "feature-rx-notify is mandatory");
-		return -EINVAL;
+			 "feature-rx-notify", "%d", &val) < 0)
+		val = 0;
+	if (!val) {
+		/* - Reduce drain timeout to poll more frequently for
+		 *   Rx requests.
+		 * - Disable Rx stall detection.
+		 */
+		be->vif->drain_timeout = msecs_to_jiffies(30);
+		be->vif->stall_timeout = 0;
 	}
 
 	if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-sg",
-- 
1.7.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 Dec 17 14:01:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 14:01:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1FAE-0007SN-5H; Wed, 17 Dec 2014 14:01:18 +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 1Y1FAC-0007SI-2U
	for Xen-devel@lists.xen.org; Wed, 17 Dec 2014 14:01:16 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	38/13-17694-BAC81945; Wed, 17 Dec 2014 14:01:15 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418824872!14079469!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28426 invoked from network); 17 Dec 2014 14:01:14 -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;
	17 Dec 2014 14:01:14 -0000
X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208";a="205803350"
Message-ID: <54918C89.1020409@citrix.com>
Date: Wed, 17 Dec 2014 14:00:41 +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: David Vrabel <david.vrabel@citrix.com>, John <jw@nuclearfallout.net>
References: <54884DA8.7030003@nuclearfallout.net> <548854C3.7060008@citrix.com>
In-Reply-To: <548854C3.7060008@citrix.com>
X-DLP: MIA1
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	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] xen-netback: make feature-rx-notify mandatory --
 Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 14:12, David Vrabel wrote:
> On 10/12/14 13:42, John wrote:
>> David,
>>
>> This patch you put into 3.18.0 appears to break the latest version of
>> stubdomains. I found this out today when I tried to update a machine to
>> 3.18.0 and all of the domUs crashed on start with the dmesg output like
>> this:
> 
> Cc'ing the lists and relevant netback maintainers.
> 
> I guess the stubdoms are using minios's netfront?  This is something I
> forgot about when deciding if it was ok to make this feature mandatory.
> 
> The patch cannot be reverted as it's a prerequisite for a critical
> (security) bug fix.  I am also unconvinced that the no-feature-rx-notify
> support worked correctly anyway.
> 
> This can be resolved by:
> 
> - Fixing minios's netfront to support feature-rx-notify. This should be
> easy but wouldn't help existing Xen deployments.
> 
> Or:
> 
> - Reimplement feature-rx-notify support.  I think the easiest way is to
> queue packets on the guest Rx internal queue with a short expiry time.

This patch works for me.  I tested it with a hacked Linux frontend that
disabled feature-rx-notify, but not with a stubdom.

Can you give it a try, please?

David

8<--------------------------------------------------------------
xen-netback: support frontends without feature-rx-notify again

Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
feature-rx-notify mandatory) incorrectly assumed that there were no
frontends in use that did not support this feature.  But the frontend
driver in MiniOS does not and since this is used by (qemu) stubdoms,
these stopped working.

Netback sort of works as-is in this mode except:

- If there are no Rx requests and the internal Rx queue fills, only the
  drain timeout will wake the thread.  The default drain timeout of 10 s
  would give unacceptable pauses.

- If an Rx stall was detected and the internal Rx queue is drained, then
  the Rx thread would never wake.

Handle these two cases (when feature-rx-notify is disabled) by:

- Reducing the drain timeout to 30 ms.

- Disabling Rx stall detection.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/common.h    |    4 +++-
 drivers/net/xen-netback/interface.c |    4 +++-
 drivers/net/xen-netback/netback.c   |   27 ++++++++++++++-------------
 drivers/net/xen-netback/xenbus.c    |   12 +++++++++---
 4 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 083ecc9..5f1fda4 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -230,6 +230,8 @@ struct xenvif {
 	 */
 	bool disabled;
 	unsigned long status;
+	unsigned long drain_timeout;
+	unsigned long stall_timeout;
 
 	/* Queues */
 	struct xenvif_queue *queues;
@@ -328,7 +330,7 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id);
 extern bool separate_tx_rx_irq;
 
 extern unsigned int rx_drain_timeout_msecs;
-extern unsigned int rx_drain_timeout_jiffies;
+extern unsigned int rx_stall_timeout_msecs;
 extern unsigned int xenvif_max_queues;
 
 #ifdef CONFIG_DEBUG_FS
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index a6a32d3..9259a73 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -166,7 +166,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	cb = XENVIF_RX_CB(skb);
-	cb->expires = jiffies + rx_drain_timeout_jiffies;
+	cb->expires = jiffies + vif->drain_timeout;
 
 	xenvif_rx_queue_tail(queue, skb);
 	xenvif_kick_thread(queue);
@@ -414,6 +414,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif->ip_csum = 1;
 	vif->dev = dev;
 	vif->disabled = false;
+	vif->drain_timeout = msecs_to_jiffies(rx_drain_timeout_msecs);
+	vif->stall_timeout = msecs_to_jiffies(rx_stall_timeout_msecs);
 
 	/* Start out with no queues. */
 	vif->queues = NULL;
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 4a509f7..b0292e4 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -60,14 +60,12 @@ module_param(separate_tx_rx_irq, bool, 0644);
  */
 unsigned int rx_drain_timeout_msecs = 10000;
 module_param(rx_drain_timeout_msecs, uint, 0444);
-unsigned int rx_drain_timeout_jiffies;
 
 /* The length of time before the frontend is considered unresponsive
  * because it isn't providing Rx slots.
  */
-static unsigned int rx_stall_timeout_msecs = 60000;
+unsigned int rx_stall_timeout_msecs = 60000;
 module_param(rx_stall_timeout_msecs, uint, 0444);
-static unsigned int rx_stall_timeout_jiffies;
 
 unsigned int xenvif_max_queues;
 module_param_named(max_queues, xenvif_max_queues, uint, 0644);
@@ -2020,7 +2018,7 @@ static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)
 	return !queue->stalled
 		&& prod - cons < XEN_NETBK_RX_SLOTS_MAX
 		&& time_after(jiffies,
-			      queue->last_rx_time + rx_stall_timeout_jiffies);
+			      queue->last_rx_time + queue->vif->stall_timeout);
 }
 
 static bool xenvif_rx_queue_ready(struct xenvif_queue *queue)
@@ -2038,8 +2036,9 @@ static bool xenvif_have_rx_work(struct xenvif_queue *queue)
 {
 	return (!skb_queue_empty(&queue->rx_queue)
 		&& xenvif_rx_ring_slots_available(queue, XEN_NETBK_RX_SLOTS_MAX))
-		|| xenvif_rx_queue_stalled(queue)
-		|| xenvif_rx_queue_ready(queue)
+		|| (queue->vif->stall_timeout &&
+		    (xenvif_rx_queue_stalled(queue)
+		     || xenvif_rx_queue_ready(queue)))
 		|| kthread_should_stop()
 		|| queue->vif->disabled;
 }
@@ -2092,6 +2091,9 @@ int xenvif_kthread_guest_rx(void *data)
 	struct xenvif_queue *queue = data;
 	struct xenvif *vif = queue->vif;
 
+	if (!vif->stall_timeout)
+		xenvif_queue_carrier_on(queue);
+
 	for (;;) {
 		xenvif_wait_for_rx_work(queue);
 
@@ -2118,10 +2120,12 @@ int xenvif_kthread_guest_rx(void *data)
 		 * while it's probably not responsive, drop the
 		 * carrier so packets are dropped earlier.
 		 */
-		if (xenvif_rx_queue_stalled(queue))
-			xenvif_queue_carrier_off(queue);
-		else if (xenvif_rx_queue_ready(queue))
-			xenvif_queue_carrier_on(queue);
+		if (queue->vif->stall_timeout) {
+			if (xenvif_rx_queue_stalled(queue))
+				xenvif_queue_carrier_off(queue);
+			else if (xenvif_rx_queue_ready(queue))
+				xenvif_queue_carrier_on(queue);
+		}
 
 		/* Queued packets may have foreign pages from other
 		 * domains.  These cannot be queued indefinitely as
@@ -2192,9 +2196,6 @@ static int __init netback_init(void)
 	if (rc)
 		goto failed_init;
 
-	rx_drain_timeout_jiffies = msecs_to_jiffies(rx_drain_timeout_msecs);
-	rx_stall_timeout_jiffies = msecs_to_jiffies(rx_stall_timeout_msecs);
-
 #ifdef CONFIG_DEBUG_FS
 	xen_netback_dbg_root = debugfs_create_dir("xen-netback", NULL);
 	if (IS_ERR_OR_NULL(xen_netback_dbg_root))
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index d44cd19..efbaf2a 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -887,9 +887,15 @@ static int read_xenbus_vif_flags(struct backend_info *be)
 		return -EOPNOTSUPP;
 
 	if (xenbus_scanf(XBT_NIL, dev->otherend,
-			 "feature-rx-notify", "%d", &val) < 0 || val == 0) {
-		xenbus_dev_fatal(dev, -EINVAL, "feature-rx-notify is mandatory");
-		return -EINVAL;
+			 "feature-rx-notify", "%d", &val) < 0)
+		val = 0;
+	if (!val) {
+		/* - Reduce drain timeout to poll more frequently for
+		 *   Rx requests.
+		 * - Disable Rx stall detection.
+		 */
+		be->vif->drain_timeout = msecs_to_jiffies(30);
+		be->vif->stall_timeout = 0;
 	}
 
 	if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-sg",
-- 
1.7.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 Dec 17 14:12:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 14: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 1Y1FKM-0007ny-8f; Wed, 17 Dec 2014 14:11:46 +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 1Y1FKL-0007nt-Mp
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 14:11:45 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B3/54-15461-02F81945; Wed, 17 Dec 2014 14:11:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418825503!16229057!1
X-Originating-IP: [66.165.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 23609 invoked from network); 17 Dec 2014 14:11:44 -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 Dec 2014 14:11:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208";a="205807821"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 17 Dec 2014 09:09: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 1Y1FIc-0003Tc-CM;
	Wed, 17 Dec 2014 14:09:58 +0000
Date: Wed, 17 Dec 2014 14:09:58 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Message-ID: <20141217140958.GH1904@zion.uk.xensource.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418711577-15449-5-git-send-email-cyliu@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 02:32:57PM +0800, Chunyan Liu wrote:
> Changes to V8:
>   * remove libxl_domain_snapshot_create/delete/revert API
>   * export disk snapshot functionality for both xl and libvirt usage
> 
> ===========================================================================
> Libxl/libxlu Design
> 
> 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),
>     ])
> 

So you don't propose making libxl to have knowledge of the snapshot
chains? And in libvirt (or other toolstack that's interested in snapshot
management) you represent a snapshot as chains (or trees) of
libxl_disk_snapshot? (Not suggesting you do things the other way around,
just to confirm)

> 
> 2. New Functions
> 
> Since there're already APIs for saving memory (libxl_domain_suspend)
> and restoring domain from saved memory (libxl_domain_create_restore), to
> xl domain snapshot tasks, the missing part is disk snapshot functionality.
> And the disk snapshot functionality would be used by libvirt too.
> 
> Considering there is qmp handling in creating/deleting disk snapshot,
> will add following new functions to libxl (?):
> 
> int libxl_disk_snapshot_create(libxl_ctx *ctx, uint32_t domid,
>                                libxl_disk_snapshot *snapshot, int nb);
> 
>     Taking disk snapshots to a group of domain disks according to
>     configuration. For qcow2 disk backend type, it will call qmp
>     "transaction" command to do the work. For other disk backend types,
>     might call other external commands.
> 
>     Parameters:
>        ctx (INPUT):
>            context
>        domid (INPUT):
>            domain id
>        snapshot (INPUT):
>            array of disk snapshot configuration. Has "nb" members.
> 
>            libxl_device_disk:
>                structure to represent which disk.
>            name:
>                snapshot name.
>            external:
>                internal snapshot or external snapshot.
>                '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.
>        nb (INPUT):
>            number of disks that need to take disk snapshot.
> 
>     Return:
>        0 on success, -1 on error.
> 

It should return appropriate libxl error code (ERROR_*) on error.

> 
> /*  This API might not be used by xl, since xl won't take care of deleting
>  *  snapshots. But for libvirt, since libvirt manages snapshots and will
>  *  delete snapshot, this API will be used.
>  */
> int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid,
>                                libxl_disk_snapshot *snapshot, int nb);
> 
>     Delete disk snapshot of a group of domain disks according to
>     configuration. For qcow2 disk backend type, it will call qmp command
>     to delete internal disk snapshot. For other disk backend types, might
>     call other external commands.
> 
>     Parameters:
>        ctx (INPUT):
>            context
>        domid (INPUT):
>            domain id
>        snapshot (INPUT):
>            array of disk snapshot configuration. Has "nb" members.
>        nb (INPUT):
>            number of disks that need to take disk snapshot.
> 
>     Return:
>        0 on success, -1 on error.
> 
> 
> int libxl_disk_to_snapshot(libxl_ctx *ctx, uint32_t domid,
>                            libxl_disk_snapshot **snapshot, int *num);
> 
>     This is for domain snapshot create. If user doesn't specify disks,
>     then by default it will take internal disk snapshot to each domain
>     disk. This function will fill libxl_disk_snapshot according to domain
>     disks info.
> 
>     Parameters:
>        ctx (INPUT):
>            context
>        domid (INPUT):
>            domain id
>        snapshot (OUTPUT):
>            array of disk snapshot configuration.
>        num (OUTPUT):
>            number of disks.
> 
>     Return:
>        0 on success, -1 on error.
> 
> 
> 
> For disk snapshot revert, no qmp command for that, it always calls
> external commands to finish the work, so put in libxlu (?):
> 
> int xlu_disk_snapshot_revert(libxl_disk_snapshot *snapshot, int nb);
> 

IMHO it's fine for this to be in libxl. Calling out to other programs
is fine.

Wei.

>     Apply disk snapshot for a group of disks according to configuration. To
>     different disk backend types, call different external commands to do
>     the work.
> 
>     Parameters:
>        snapshot (INPUT):
>            array of disk snapshot configuration. Has "nb" members.
>        nb (INPUT):
>            number of disks that need to take disk snapshot.
> 
>     Return:
>        0 on success, -1 on error.
> 
> 
> 
> 3. Simple Architecture View
> 
> Creating domain snapshot:
> (* means new functions we will need in libxl/libxlu)
> 
>   "xl snapshot-create"
>          |
>   parse configuration ----> libxl_disk_to_snapshot (*)
>          |
>   saving memory ----> libxl_domain_suspend
>          |
>  taking disk snapshot ----> libxl_disk_snapshot_create (*)
>          |                     |
>          |                     --> libxl_qmp_disk_snapshot_transaction (*)
>          |
>     unpause domain ---->libxl_domain_unpause
>          |
>         End
> 
> 
> Reverting to a snapshot:
> (* means new functions we will need in libxl/libxlu)
> 
>   "xl snapshot-revert"
>          |
>    parse configuration
>          |
>    destroy domain ---->libxl_domain_destroy
>          |
>  reverting disk snapshot ----> xlu_disk_snapshot_revert (*)
>          |                       |
>          |                       --> call 'qemu-img' to apply disk snapshot
>          |
>  restore domain from saved memory ----> libxl_domain_create_restore
>          |
>         End

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 14:12:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 14: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 1Y1FKM-0007ny-8f; Wed, 17 Dec 2014 14:11:46 +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 1Y1FKL-0007nt-Mp
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 14:11:45 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B3/54-15461-02F81945; Wed, 17 Dec 2014 14:11:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418825503!16229057!1
X-Originating-IP: [66.165.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 23609 invoked from network); 17 Dec 2014 14:11:44 -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 Dec 2014 14:11:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208";a="205807821"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 17 Dec 2014 09:09: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 1Y1FIc-0003Tc-CM;
	Wed, 17 Dec 2014 14:09:58 +0000
Date: Wed, 17 Dec 2014 14:09:58 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Message-ID: <20141217140958.GH1904@zion.uk.xensource.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418711577-15449-5-git-send-email-cyliu@suse.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 02:32:57PM +0800, Chunyan Liu wrote:
> Changes to V8:
>   * remove libxl_domain_snapshot_create/delete/revert API
>   * export disk snapshot functionality for both xl and libvirt usage
> 
> ===========================================================================
> Libxl/libxlu Design
> 
> 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),
>     ])
> 

So you don't propose making libxl to have knowledge of the snapshot
chains? And in libvirt (or other toolstack that's interested in snapshot
management) you represent a snapshot as chains (or trees) of
libxl_disk_snapshot? (Not suggesting you do things the other way around,
just to confirm)

> 
> 2. New Functions
> 
> Since there're already APIs for saving memory (libxl_domain_suspend)
> and restoring domain from saved memory (libxl_domain_create_restore), to
> xl domain snapshot tasks, the missing part is disk snapshot functionality.
> And the disk snapshot functionality would be used by libvirt too.
> 
> Considering there is qmp handling in creating/deleting disk snapshot,
> will add following new functions to libxl (?):
> 
> int libxl_disk_snapshot_create(libxl_ctx *ctx, uint32_t domid,
>                                libxl_disk_snapshot *snapshot, int nb);
> 
>     Taking disk snapshots to a group of domain disks according to
>     configuration. For qcow2 disk backend type, it will call qmp
>     "transaction" command to do the work. For other disk backend types,
>     might call other external commands.
> 
>     Parameters:
>        ctx (INPUT):
>            context
>        domid (INPUT):
>            domain id
>        snapshot (INPUT):
>            array of disk snapshot configuration. Has "nb" members.
> 
>            libxl_device_disk:
>                structure to represent which disk.
>            name:
>                snapshot name.
>            external:
>                internal snapshot or external snapshot.
>                '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.
>        nb (INPUT):
>            number of disks that need to take disk snapshot.
> 
>     Return:
>        0 on success, -1 on error.
> 

It should return appropriate libxl error code (ERROR_*) on error.

> 
> /*  This API might not be used by xl, since xl won't take care of deleting
>  *  snapshots. But for libvirt, since libvirt manages snapshots and will
>  *  delete snapshot, this API will be used.
>  */
> int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid,
>                                libxl_disk_snapshot *snapshot, int nb);
> 
>     Delete disk snapshot of a group of domain disks according to
>     configuration. For qcow2 disk backend type, it will call qmp command
>     to delete internal disk snapshot. For other disk backend types, might
>     call other external commands.
> 
>     Parameters:
>        ctx (INPUT):
>            context
>        domid (INPUT):
>            domain id
>        snapshot (INPUT):
>            array of disk snapshot configuration. Has "nb" members.
>        nb (INPUT):
>            number of disks that need to take disk snapshot.
> 
>     Return:
>        0 on success, -1 on error.
> 
> 
> int libxl_disk_to_snapshot(libxl_ctx *ctx, uint32_t domid,
>                            libxl_disk_snapshot **snapshot, int *num);
> 
>     This is for domain snapshot create. If user doesn't specify disks,
>     then by default it will take internal disk snapshot to each domain
>     disk. This function will fill libxl_disk_snapshot according to domain
>     disks info.
> 
>     Parameters:
>        ctx (INPUT):
>            context
>        domid (INPUT):
>            domain id
>        snapshot (OUTPUT):
>            array of disk snapshot configuration.
>        num (OUTPUT):
>            number of disks.
> 
>     Return:
>        0 on success, -1 on error.
> 
> 
> 
> For disk snapshot revert, no qmp command for that, it always calls
> external commands to finish the work, so put in libxlu (?):
> 
> int xlu_disk_snapshot_revert(libxl_disk_snapshot *snapshot, int nb);
> 

IMHO it's fine for this to be in libxl. Calling out to other programs
is fine.

Wei.

>     Apply disk snapshot for a group of disks according to configuration. To
>     different disk backend types, call different external commands to do
>     the work.
> 
>     Parameters:
>        snapshot (INPUT):
>            array of disk snapshot configuration. Has "nb" members.
>        nb (INPUT):
>            number of disks that need to take disk snapshot.
> 
>     Return:
>        0 on success, -1 on error.
> 
> 
> 
> 3. Simple Architecture View
> 
> Creating domain snapshot:
> (* means new functions we will need in libxl/libxlu)
> 
>   "xl snapshot-create"
>          |
>   parse configuration ----> libxl_disk_to_snapshot (*)
>          |
>   saving memory ----> libxl_domain_suspend
>          |
>  taking disk snapshot ----> libxl_disk_snapshot_create (*)
>          |                     |
>          |                     --> libxl_qmp_disk_snapshot_transaction (*)
>          |
>     unpause domain ---->libxl_domain_unpause
>          |
>         End
> 
> 
> Reverting to a snapshot:
> (* means new functions we will need in libxl/libxlu)
> 
>   "xl snapshot-revert"
>          |
>    parse configuration
>          |
>    destroy domain ---->libxl_domain_destroy
>          |
>  reverting disk snapshot ----> xlu_disk_snapshot_revert (*)
>          |                       |
>          |                       --> call 'qemu-img' to apply disk snapshot
>          |
>  restore domain from saved memory ----> libxl_domain_create_restore
>          |
>         End

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 14:21:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 14:21:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1FTa-00089h-9v; Wed, 17 Dec 2014 14:21: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 1Y1FTY-00089c-Ph
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 14:21:16 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	1D/D7-17735-C5191945; Wed, 17 Dec 2014 14:21:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418826073!13937890!1
X-Originating-IP: [66.165.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 2269 invoked from network); 17 Dec 2014 14:21:15 -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;
	17 Dec 2014 14:21:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208";a="205813311"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 17 Dec 2014 09:20:46 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Y1FT3-0003ep-U8;
	Wed, 17 Dec 2014 14:20:45 +0000
Date: Wed, 17 Dec 2014 14:20:45 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20141217142045.GI1904@zion.uk.xensource.com>
References: <6FD25049-90E4-461A-93D4-DA7D848496FF@alex.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6FD25049-90E4-461A-93D4-DA7D848496FF@alex.org.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 reboot hangs with VMs created with libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 01:47:35PM +0000, Alex Bligh wrote:
> I am running Ubuntu's xen 4.4 (4.4.1-0ubuntu0.14.04.2), but creating VMs
> with libxl.
> 
> When I do a 'shutdown -r' or similar with no VMs running, dom0 reboots
> fine. When I do this with one or more VMs running, I get:
> 
> "INFO: task reboot:11897 blocked for more than 120 seconds."
> 
> repeatedly, and the machine never reboots. I'm taking this is because
> nothing is forcibly destroying the VMs running.
> 

Correct.

> I think this is a bug, but I'm not sure whether it's solely a bug
> in the Debian / Ubuntu packaging. What is meant to destroy VMs
> on a clean reboot?
> 

I think xendomains service can help (it already gets shipped amount
other services). It's probably not started by default. I've never used
it myself though.

Wei.

> 
> -- 
> Alex Bligh
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 17 14:21:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 14:21:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1FTa-00089h-9v; Wed, 17 Dec 2014 14:21: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 1Y1FTY-00089c-Ph
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 14:21:16 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	1D/D7-17735-C5191945; Wed, 17 Dec 2014 14:21:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418826073!13937890!1
X-Originating-IP: [66.165.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 2269 invoked from network); 17 Dec 2014 14:21:15 -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;
	17 Dec 2014 14:21:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208";a="205813311"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Wed, 17 Dec 2014 09:20:46 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Y1FT3-0003ep-U8;
	Wed, 17 Dec 2014 14:20:45 +0000
Date: Wed, 17 Dec 2014 14:20:45 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20141217142045.GI1904@zion.uk.xensource.com>
References: <6FD25049-90E4-461A-93D4-DA7D848496FF@alex.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6FD25049-90E4-461A-93D4-DA7D848496FF@alex.org.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: wei.liu2@citrix.com, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 reboot hangs with VMs created with libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 16, 2014 at 01:47:35PM +0000, Alex Bligh wrote:
> I am running Ubuntu's xen 4.4 (4.4.1-0ubuntu0.14.04.2), but creating VMs
> with libxl.
> 
> When I do a 'shutdown -r' or similar with no VMs running, dom0 reboots
> fine. When I do this with one or more VMs running, I get:
> 
> "INFO: task reboot:11897 blocked for more than 120 seconds."
> 
> repeatedly, and the machine never reboots. I'm taking this is because
> nothing is forcibly destroying the VMs running.
> 

Correct.

> I think this is a bug, but I'm not sure whether it's solely a bug
> in the Debian / Ubuntu packaging. What is meant to destroy VMs
> on a clean reboot?
> 

I think xendomains service can help (it already gets shipped amount
other services). It's probably not started by default. I've never used
it myself though.

Wei.

> 
> -- 
> Alex Bligh
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 17 15:08:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1GCc-00015q-Ju; Wed, 17 Dec 2014 15:07:50 +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 1Y1GCb-00015l-Gg
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:07:49 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	28/D1-27584-44C91945; Wed, 17 Dec 2014 15:07:48 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418828866!8619334!1
X-Originating-IP: [156.151.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 12746 invoked from network); 17 Dec 2014 15:07:47 -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 Dec 2014 15:07:47 -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 sBHF7jxS003438
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:07:46 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
	sBHF7iDJ000118
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:07:44 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
	sBHF7gZW001666; Wed, 17 Dec 2014 15:07:42 GMT
Received: from ovs101.us.oracle.com (/10.149.76.201)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 07:07:42 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, konrad.wilk@oracle.com
Date: Wed, 17 Dec 2014 10:35:47 -0500
Message-Id: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] x86/VPMU: Clear last_vcpu when destroying
	VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.

We have to do this atomically since otherwise there is a (somewhat
theoretical) chance that between test and subsequent clearing
of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
both vpmu_load() and then vpmu_save() for another VCPU. The former
will clear last_vcpu and the latter will set it to something else.

We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
avoid unnecessary cmpxchg() and arch-specific destroy ops. Thus
checks in AMD and Intel routines are no longer needed.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/svm/vpmu.c       |    3 ---
 xen/arch/x86/hvm/vmx/vpmu_core2.c |    2 --
 xen/arch/x86/hvm/vpmu.c           |    7 +++++++
 3 files changed, 7 insertions(+), 5 deletions(-)

Changes in v3:
 * Use cmpxchg instead of IPI
 * Use correct routine nemas in commit message
 * Remove duplicate test for VPMU_CONTEXT_ALLOCATED in arch-specific
   destroy ops

Changes in v2:
 * Test last_vcpu locally before IPI
 * Don't handle local pcpu as a special case --- on_selected_cpus
   will take care of that
 * Dont't cast variables unnecessarily

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 8e07a98..4c448bb 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -403,9 +403,6 @@ static void amd_vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
-        return;
-
     if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
         amd_vpmu_unset_msr_bitmap(v);
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 68b6272..590c2a9 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -818,8 +818,6 @@ 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 ( cpu_has_vmx_msr_bitmap )
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1df74c2..7cc95ae 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -250,6 +250,13 @@ void vpmu_initialise(struct vcpu *v)
 void vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    struct vcpu **last = &per_cpu(last_vcpu, vpmu->last_pcpu);
+
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
+        return;
+
+    /* Need to clear last_vcpu in case it points to v */
+    (void)cmpxchg(last, v, NULL);
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
         vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
-- 
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 Wed Dec 17 15:08:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1GCc-00015q-Ju; Wed, 17 Dec 2014 15:07:50 +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 1Y1GCb-00015l-Gg
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:07:49 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	28/D1-27584-44C91945; Wed, 17 Dec 2014 15:07:48 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418828866!8619334!1
X-Originating-IP: [156.151.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 12746 invoked from network); 17 Dec 2014 15:07:47 -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 Dec 2014 15:07:47 -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 sBHF7jxS003438
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:07:46 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
	sBHF7iDJ000118
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:07:44 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
	sBHF7gZW001666; Wed, 17 Dec 2014 15:07:42 GMT
Received: from ovs101.us.oracle.com (/10.149.76.201)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 07:07:42 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, konrad.wilk@oracle.com
Date: Wed, 17 Dec 2014 10:35:47 -0500
Message-Id: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.7.1
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] x86/VPMU: Clear last_vcpu when destroying
	VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.

We have to do this atomically since otherwise there is a (somewhat
theoretical) chance that between test and subsequent clearing
of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
both vpmu_load() and then vpmu_save() for another VCPU. The former
will clear last_vcpu and the latter will set it to something else.

We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
avoid unnecessary cmpxchg() and arch-specific destroy ops. Thus
checks in AMD and Intel routines are no longer needed.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/svm/vpmu.c       |    3 ---
 xen/arch/x86/hvm/vmx/vpmu_core2.c |    2 --
 xen/arch/x86/hvm/vpmu.c           |    7 +++++++
 3 files changed, 7 insertions(+), 5 deletions(-)

Changes in v3:
 * Use cmpxchg instead of IPI
 * Use correct routine nemas in commit message
 * Remove duplicate test for VPMU_CONTEXT_ALLOCATED in arch-specific
   destroy ops

Changes in v2:
 * Test last_vcpu locally before IPI
 * Don't handle local pcpu as a special case --- on_selected_cpus
   will take care of that
 * Dont't cast variables unnecessarily

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 8e07a98..4c448bb 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -403,9 +403,6 @@ static void amd_vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
-        return;
-
     if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
         amd_vpmu_unset_msr_bitmap(v);
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 68b6272..590c2a9 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -818,8 +818,6 @@ 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 ( cpu_has_vmx_msr_bitmap )
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1df74c2..7cc95ae 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -250,6 +250,13 @@ void vpmu_initialise(struct vcpu *v)
 void vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    struct vcpu **last = &per_cpu(last_vcpu, vpmu->last_pcpu);
+
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
+        return;
+
+    /* Need to clear last_vcpu in case it points to v */
+    (void)cmpxchg(last, v, NULL);
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
         vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
-- 
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 Wed Dec 17 15:24:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GS6-0001fY-6V; Wed, 17 Dec 2014 15:23: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 1Y1GS4-0001fT-26
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 15:23:48 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	98/F9-28296-300A1945; Wed, 17 Dec 2014 15:23:47 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418829824!14110430!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30117 invoked from network); 17 Dec 2014 15:23:45 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 15:23:45 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so16088266wiv.11
	for <xen-devel@lists.xenproject.org>;
	Wed, 17 Dec 2014 07:23: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=QQO0QOK3Ts8s6BizyaeJw65Em79/f2/VdcRtojG+dTY=;
	b=EmK0BvJrpKhfxOhTgUY42CjCBlrphV/ni0zEiCt8zv2GZqB+ybL33iWXRQpe0rFSeB
	U7qKPpeyPN8/GY/sYKEOGXPQ+cXGWxE9U8TQr2fmZA7HyX7HxwX6d4QR8bXRN3f7aj3t
	lBCDfyiEs9QfnKEJ5kJKvjIH96xDFVRM+3Nu7m9DDeAPUiK0pMS5u9LZqjW6n9mFza19
	AAQi3rVvwwUNSU+b1l/wBCgLbHRb5CRt8SoGxJFgq9QM1pwNSQNBtPdGrf57D1GmXNuB
	0NMm+7xgaCHL0UaCaiVM4AtxOMW1M9Dry2SVLf/Th1QZeCJxD74J2iiC4BwYyucVrkBT
	uY1A==
X-Gm-Message-State: ALoCoQm84DlnOre2eW4HlGO3/ure4uyMYSKLsq4dWXiZtAwOV6IwsYz0U79LBbGfBWBKSyW/j6ff
X-Received: by 10.180.208.112 with SMTP id md16mr15191448wic.37.1418829824550; 
	Wed, 17 Dec 2014 07:23:44 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ep9sm6526594wid.3.2014.12.17.07.23.42
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Dec 2014 07:23:43 -0800 (PST)
Message-ID: <54919FEF.1020308@linaro.org>
Date: Wed, 17 Dec 2014 15:23:27 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.3.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
	<1418395392-30460-3-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1412151527310.30971@kaball.uk.xensource.com>
	<548F0733.2020108@linaro.org>
In-Reply-To: <548F0733.2020108@linaro.org>
Cc: ian.campbell@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	xen-devel@lists.xenproject.org, parth.dixit@linaro.org,
	christoffer.dall@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.6 2/4] xen/arm: vgic: Keep track of
 vIRQ used by a domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/12/14 16:07, Julien Grall wrote:
> On 15/12/14 15:32, Stefano Stabellini wrote:
>> On Fri, 12 Dec 2014, Julien Grall wrote:
>>> +    spin_lock_init(&d->arch.vgic.lock);
>>
>> you should probably explain in the commit message the reason why you are
>> making changes to the vgic lock
> 
> Actually the domain vgic lock was never used. Only the per-vcpu vgic
> lock was in used.
> 
> So I don't make any change to the vgic lock. If I don't use it, I will
> add a patch to drop it.
> 
>>> @@ -441,6 +453,70 @@ int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
>>>      return v->domain->arch.vgic.handler->emulate_sysreg(regs, hsr);
>>>  }
>>>  
>>> +bool_t vgic_reserve_virq(struct domain *d, unsigned int virq)
>>> +{
>>> +    bool_t reserved;
>>> +
>>> +    if ( virq >= vgic_num_irqs(d) )
>>> +        return 0;
>>> +
>>> +    spin_lock(&d->arch.vgic.lock);
>>> +    reserved = !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
>>> +    spin_unlock(&d->arch.vgic.lock);
>>
>> test_and_set_bit is atomic, why do you need to take the lock?
> 
> To avoid race condition with vgic_allocate_virq.
> 
> Anyway, I will dropped it with your suggestion to implement
> vgic_allocate_virq without lock.

Hmmm ... I was wrong on this one. The domain vgic lock is used in the
macro vgic_lock.

But it has never been initialized. I will send a separate patch for
correctly initialize 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 Dec 17 15:24:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GS6-0001fY-6V; Wed, 17 Dec 2014 15:23: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 1Y1GS4-0001fT-26
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 15:23:48 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	98/F9-28296-300A1945; Wed, 17 Dec 2014 15:23:47 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418829824!14110430!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30117 invoked from network); 17 Dec 2014 15:23:45 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 15:23:45 -0000
Received: by mail-wi0-f172.google.com with SMTP id n3so16088266wiv.11
	for <xen-devel@lists.xenproject.org>;
	Wed, 17 Dec 2014 07:23: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=QQO0QOK3Ts8s6BizyaeJw65Em79/f2/VdcRtojG+dTY=;
	b=EmK0BvJrpKhfxOhTgUY42CjCBlrphV/ni0zEiCt8zv2GZqB+ybL33iWXRQpe0rFSeB
	U7qKPpeyPN8/GY/sYKEOGXPQ+cXGWxE9U8TQr2fmZA7HyX7HxwX6d4QR8bXRN3f7aj3t
	lBCDfyiEs9QfnKEJ5kJKvjIH96xDFVRM+3Nu7m9DDeAPUiK0pMS5u9LZqjW6n9mFza19
	AAQi3rVvwwUNSU+b1l/wBCgLbHRb5CRt8SoGxJFgq9QM1pwNSQNBtPdGrf57D1GmXNuB
	0NMm+7xgaCHL0UaCaiVM4AtxOMW1M9Dry2SVLf/Th1QZeCJxD74J2iiC4BwYyucVrkBT
	uY1A==
X-Gm-Message-State: ALoCoQm84DlnOre2eW4HlGO3/ure4uyMYSKLsq4dWXiZtAwOV6IwsYz0U79LBbGfBWBKSyW/j6ff
X-Received: by 10.180.208.112 with SMTP id md16mr15191448wic.37.1418829824550; 
	Wed, 17 Dec 2014 07:23:44 -0800 (PST)
Received: from [10.80.2.139] ([185.25.64.249])
	by mx.google.com with ESMTPSA id ep9sm6526594wid.3.2014.12.17.07.23.42
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Dec 2014 07:23:43 -0800 (PST)
Message-ID: <54919FEF.1020308@linaro.org>
Date: Wed, 17 Dec 2014 15:23:27 +0000
From: Julien Grall <julien.grall@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.3.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1418395392-30460-1-git-send-email-julien.grall@linaro.org>
	<1418395392-30460-3-git-send-email-julien.grall@linaro.org>
	<alpine.DEB.2.02.1412151527310.30971@kaball.uk.xensource.com>
	<548F0733.2020108@linaro.org>
In-Reply-To: <548F0733.2020108@linaro.org>
Cc: ian.campbell@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	xen-devel@lists.xenproject.org, parth.dixit@linaro.org,
	christoffer.dall@linaro.org
Subject: Re: [Xen-devel] [PATCH for-4.6 2/4] xen/arm: vgic: Keep track of
 vIRQ used by a domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/12/14 16:07, Julien Grall wrote:
> On 15/12/14 15:32, Stefano Stabellini wrote:
>> On Fri, 12 Dec 2014, Julien Grall wrote:
>>> +    spin_lock_init(&d->arch.vgic.lock);
>>
>> you should probably explain in the commit message the reason why you are
>> making changes to the vgic lock
> 
> Actually the domain vgic lock was never used. Only the per-vcpu vgic
> lock was in used.
> 
> So I don't make any change to the vgic lock. If I don't use it, I will
> add a patch to drop it.
> 
>>> @@ -441,6 +453,70 @@ int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
>>>      return v->domain->arch.vgic.handler->emulate_sysreg(regs, hsr);
>>>  }
>>>  
>>> +bool_t vgic_reserve_virq(struct domain *d, unsigned int virq)
>>> +{
>>> +    bool_t reserved;
>>> +
>>> +    if ( virq >= vgic_num_irqs(d) )
>>> +        return 0;
>>> +
>>> +    spin_lock(&d->arch.vgic.lock);
>>> +    reserved = !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
>>> +    spin_unlock(&d->arch.vgic.lock);
>>
>> test_and_set_bit is atomic, why do you need to take the lock?
> 
> To avoid race condition with vgic_allocate_virq.
> 
> Anyway, I will dropped it with your suggestion to implement
> vgic_allocate_virq without lock.

Hmmm ... I was wrong on this one. The domain vgic lock is used in the
macro vgic_lock.

But it has never been initialized. I will send a separate patch for
correctly initialize 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 Dec 17 15:41:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1GiV-00023P-3B; Wed, 17 Dec 2014 15:40: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 1Y1GiT-00023K-PJ
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 15:40:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5E/1A-09842-DF3A1945; Wed, 17 Dec 2014 15:40:45 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418830834!8971511!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7676 invoked from network); 17 Dec 2014 15:40:44 -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;
	17 Dec 2014 15:40:44 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so16543873wiw.10
	for <xen-devel@lists.xenproject.org>;
	Wed, 17 Dec 2014 07:40: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:from:to:cc:subject:date:message-id;
	bh=ro+DNGk6TK/bwwuy0NnWzw3hzsUU7Q8tAzlklkL8nRI=;
	b=gn4xzMxwJGCqNVPQUg+Dm9hu1VMlOL+vxVWGWdMf0OdY+Q8o4BreR2X+ZIuW0qMN1o
	dJH9Bn1C82vyirrisKXkWQ8ZHGl9MdJqjzJCqXKu4S3aXMAzT2pbTduVlfklDoHHtTqj
	wHhpIQTPx0DVjXyeaQnCiMCEIDUi8pm31appD7Woraqn6Txh/BAultniucZfao63QaUo
	oar8F6RYkxoHbMVE2R0ysJK2DmEfODo0k6ev6rLzKdioEmz49MF7MGnvAS9Zz4VQlxrx
	d+NbZ+u1mzo6kozmFkNWOLmWDHQ2M8ORgd2cNOzumUBAvSrkUZpiE3BMALP+24lBj9tr
	DatQ==
X-Gm-Message-State: ALoCoQk4PHx/KjT69k9aBkqYTww25Wx/ukqEqXuQ3LN5WgTZyLo9LAAcAoGaASZYxlybRf5BJeQn
X-Received: by 10.194.201.137 with SMTP id ka9mr74872405wjc.66.1418830834459; 
	Wed, 17 Dec 2014 07:40:34 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id lg7sm6584310wic.0.2014.12.17.07.40.32
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 17 Dec 2014 07:40:33 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Wed, 17 Dec 2014 15:40:15 +0000
Message-Id: <1418830815-4720-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: Initialize the domain vgic lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The domain vgic lock is used uninitialized.

Signed-off-by: Julien Grall <julien.grall@linaro.org>

---
    This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
    unitialized. Luckily we only use the field "raw" which is reset to 0
    during the domain allocation.

    There is no harm to apply for Xen 4.5 because it will correctly set
    the spin_lock structure for a later usage.
---
 xen/arch/arm/vgic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 97061ce..b8bd38b 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -90,6 +90,8 @@ int domain_vgic_init(struct domain *d)
         return -ENODEV;
     }
 
+    spin_lock_init(&d->arch.vgic.lock);
+
     d->arch.vgic.shared_irqs =
         xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
     if ( d->arch.vgic.shared_irqs == NULL )
-- 
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 Wed Dec 17 15:41:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1GiV-00023P-3B; Wed, 17 Dec 2014 15:40: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 1Y1GiT-00023K-PJ
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 15:40:45 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	5E/1A-09842-DF3A1945; Wed, 17 Dec 2014 15:40:45 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1418830834!8971511!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7676 invoked from network); 17 Dec 2014 15:40:44 -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;
	17 Dec 2014 15:40:44 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so16543873wiw.10
	for <xen-devel@lists.xenproject.org>;
	Wed, 17 Dec 2014 07:40: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:from:to:cc:subject:date:message-id;
	bh=ro+DNGk6TK/bwwuy0NnWzw3hzsUU7Q8tAzlklkL8nRI=;
	b=gn4xzMxwJGCqNVPQUg+Dm9hu1VMlOL+vxVWGWdMf0OdY+Q8o4BreR2X+ZIuW0qMN1o
	dJH9Bn1C82vyirrisKXkWQ8ZHGl9MdJqjzJCqXKu4S3aXMAzT2pbTduVlfklDoHHtTqj
	wHhpIQTPx0DVjXyeaQnCiMCEIDUi8pm31appD7Woraqn6Txh/BAultniucZfao63QaUo
	oar8F6RYkxoHbMVE2R0ysJK2DmEfODo0k6ev6rLzKdioEmz49MF7MGnvAS9Zz4VQlxrx
	d+NbZ+u1mzo6kozmFkNWOLmWDHQ2M8ORgd2cNOzumUBAvSrkUZpiE3BMALP+24lBj9tr
	DatQ==
X-Gm-Message-State: ALoCoQk4PHx/KjT69k9aBkqYTww25Wx/ukqEqXuQ3LN5WgTZyLo9LAAcAoGaASZYxlybRf5BJeQn
X-Received: by 10.194.201.137 with SMTP id ka9mr74872405wjc.66.1418830834459; 
	Wed, 17 Dec 2014 07:40:34 -0800 (PST)
Received: from chilopoda.uk.xensource.com. ([185.25.64.249])
	by mx.google.com with ESMTPSA id lg7sm6584310wic.0.2014.12.17.07.40.32
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 17 Dec 2014 07:40:33 -0800 (PST)
From: Julien Grall <julien.grall@linaro.org>
To: xen-devel@lists.xenproject.org
Date: Wed, 17 Dec 2014 15:40:15 +0000
Message-Id: <1418830815-4720-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: Initialize the domain vgic lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The domain vgic lock is used uninitialized.

Signed-off-by: Julien Grall <julien.grall@linaro.org>

---
    This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
    unitialized. Luckily we only use the field "raw" which is reset to 0
    during the domain allocation.

    There is no harm to apply for Xen 4.5 because it will correctly set
    the spin_lock structure for a later usage.
---
 xen/arch/arm/vgic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 97061ce..b8bd38b 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -90,6 +90,8 @@ int domain_vgic_init(struct domain *d)
         return -ENODEV;
     }
 
+    spin_lock_init(&d->arch.vgic.lock);
+
     d->arch.vgic.shared_irqs =
         xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
     if ( d->arch.vgic.shared_irqs == NULL )
-- 
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 Wed Dec 17 15:44:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Glq-0002Nf-N1; Wed, 17 Dec 2014 15:44: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 1Y1Glo-0002NX-Ur
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 15:44:13 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	4B/19-22819-CC4A1945; Wed, 17 Dec 2014 15:44:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418831049!8628651!1
X-Originating-IP: [66.165.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 27531 invoked from network); 17 Dec 2014 15:44:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 15:44:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208";a="205382720"
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.210.2; Wed, 17 Dec 2014 10:43: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 1Y1GlT-0007SL-9f;
	Wed, 17 Dec 2014 15:43:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1GlT-0008Ta-2h;
	Wed, 17 Dec 2014 15:43:51 +0000
Date: Wed, 17 Dec 2014 15:43:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32424-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] 32424: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32424 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32424/

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. 32392

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 32392

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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-amd64-xl-qemut-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                  7e88c23239591e2638bcc944151a660fcd53495b
baseline version:
 xen                  2676bc915157ab474ee478d929b0928cf696b385

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.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                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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.

------------------------------------------------------------
commit 7e88c23239591e2638bcc944151a660fcd53495b
Author: George Dunlap <george.dunlap@eu.citrix.com>
Date:   Tue Dec 9 14:04:19 2014 +0000

    libxl: Tell qemu to use raw format when using a tapdisk
    
    At the moment libxl unconditinally passes the underlying file format
    to qemu in the device string.  However, when tapdisk is in use,
    tapdisk handles the underlying format and presents qemu with
    effectively a raw disk.  When qemu looks at the tapdisk block device
    and doesn't find the image format it was looking for, it will fail.
    
    This effectively means that tapdisk cannot be used with HVM domains at
    the moment except for raw files.
    
    Instead, if we're using a tapdisk backend, tell qemu to use a raw file
    format.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    [ ijc -- nuked extra blank line ]

commit 09b7ff1a118f5e920ef12f5592f3ce991218962a
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Dec 15 10:56:24 2014 +0000

    xl: print message to stdout when (!debug && dryrun)
    
    In commit d36a3734a ("xl: fix migration failure with xl migrate
    --debug"), message is printed to stderr for both debug mode
    and dryrun mode. That caused rdname() in xendomains fails to parse
    domain name since it's expecting input from xl's stdout.
    
    So this patch separates those two cases. If xl is running in debug mode,
    then message is printed to stderr; if xl is running in dryrun mode and
    debug is not enabled, message is printed to stdout. This will fix
    xendomains and other scripts that use "xl create --dryrun", as well as
    not re-introducing the old bug fixed in d36a3734a.
    
    Reported-by: Mark Pryor <tlviewer@yahoo.com>
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Cc: M A Young <m.a.young@durham.ac.uk>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Wilk <konrad.wilk@oracle.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit afa3fd8753c944f37c1cd182d5ad7c436c7614da
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Fri Dec 12 18:26:02 2014 +0000

    docs/commandline: Minor formatting fixes and clarifications
    
    `font` had a trailing single quote which was out of place.
    
    `gnttab_max_frames` was missing escapes for the underscores which caused the
    underscores to take their markdown meaning, causing 'max' in the middle to be
    italicised.  Escape the underscores, and make all command line parameters
    bold, to be consistent with the existing style.
    
    Clarify how the default for `nmi` changes between debug and non debug builds
    of Xen.
    
    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>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 3f727fb1a7d5f3be2513ab2e692b067075325fb3
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Tue Dec 9 16:43:22 2014 +0000

    python/xc: Fix multiple issues in pyflask_context_to_sid()
    
    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.
    
    Coverity also complains about passing a non-NUL terminated string to
    xc_flask_context_to_sid().  xc_flask_context_to_sid() doesn't actually take a
    NUL terminated string, but it does take a char* which, in context, used to be
    a string, which is why Coverity complains.
    
    One solution would be to use strdup(ctx) which is simpler than a
    strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated
    string being used with xc_flask_context_to_sid().
    
    However, ctx is strictly an input to the hypercall and is not mutated along
    the way.  Both these issues can be fixed, and the error logic simplified, by
    not duplicating ctx in the first place.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Coverity-IDs: 1055305 1055721
    Acked-by: 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>

commit dcd84861b0b01b8895716d4c803c9d24c31c8cab
Author: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date:   Mon Dec 8 15:51:47 2014 +0200

    xen/serial: setup UART idle mode for OMAP
    
    The UART is not able to receive bytes when idle mode is not configured
    properly, therefore setup the UART with autoidle and wakeup enabled.
    
    Older Linux kernels (for example 3.8) configure hwmods for all devices
    even if the device tree nodes for those devices is absent in device
    tree, thus UART idle mode is configured too.  With such kernels we can
    workaround the issue by adding a fake node in the UART containing this
    MMIO range, which is therefore mapped by Xen to dom0, which
    reconfigures the UART, causing things to work normally.
    
    Newer Linux Kernels (3.12 and beyond) do not configure idle mode for
    UART and so this hack no longer works.
    
    Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    [ ijc -- updated commit message as discussed ]

commit 6c9b27d3f363889718e7e046511383927f257095
Merge: 2676bc9 05fecc3
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Dec 15 17:40:12 2014 +0000

    Merge tag '4.5.0-rc4' into staging
    
    Xen 4.5.0 RC4

commit 05fecc382e129731c6595268a377f4bff879f694
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Dec 15 11:35:59 2014 -0500

    Xen-4.5.0-rc4: Update tag for qemu-xen.
    
    QEMU-traditional has nothing new, so stay at rc1 there.
    
    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 Wed Dec 17 15:44:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Glq-0002Nf-N1; Wed, 17 Dec 2014 15:44: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 1Y1Glo-0002NX-Ur
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 15:44:13 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	4B/19-22819-CC4A1945; Wed, 17 Dec 2014 15:44:12 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418831049!8628651!1
X-Originating-IP: [66.165.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 27531 invoked from network); 17 Dec 2014 15:44:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 15:44:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208";a="205382720"
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.210.2; Wed, 17 Dec 2014 10:43: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 1Y1GlT-0007SL-9f;
	Wed, 17 Dec 2014 15:43:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1GlT-0008Ta-2h;
	Wed, 17 Dec 2014 15:43:51 +0000
Date: Wed, 17 Dec 2014 15:43:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32424-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] 32424: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32424 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32424/

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. 32392

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 32392

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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-amd64-xl-qemut-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                  7e88c23239591e2638bcc944151a660fcd53495b
baseline version:
 xen                  2676bc915157ab474ee478d929b0928cf696b385

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.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                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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.

------------------------------------------------------------
commit 7e88c23239591e2638bcc944151a660fcd53495b
Author: George Dunlap <george.dunlap@eu.citrix.com>
Date:   Tue Dec 9 14:04:19 2014 +0000

    libxl: Tell qemu to use raw format when using a tapdisk
    
    At the moment libxl unconditinally passes the underlying file format
    to qemu in the device string.  However, when tapdisk is in use,
    tapdisk handles the underlying format and presents qemu with
    effectively a raw disk.  When qemu looks at the tapdisk block device
    and doesn't find the image format it was looking for, it will fail.
    
    This effectively means that tapdisk cannot be used with HVM domains at
    the moment except for raw files.
    
    Instead, if we're using a tapdisk backend, tell qemu to use a raw file
    format.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    [ ijc -- nuked extra blank line ]

commit 09b7ff1a118f5e920ef12f5592f3ce991218962a
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Dec 15 10:56:24 2014 +0000

    xl: print message to stdout when (!debug && dryrun)
    
    In commit d36a3734a ("xl: fix migration failure with xl migrate
    --debug"), message is printed to stderr for both debug mode
    and dryrun mode. That caused rdname() in xendomains fails to parse
    domain name since it's expecting input from xl's stdout.
    
    So this patch separates those two cases. If xl is running in debug mode,
    then message is printed to stderr; if xl is running in dryrun mode and
    debug is not enabled, message is printed to stdout. This will fix
    xendomains and other scripts that use "xl create --dryrun", as well as
    not re-introducing the old bug fixed in d36a3734a.
    
    Reported-by: Mark Pryor <tlviewer@yahoo.com>
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Cc: M A Young <m.a.young@durham.ac.uk>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Wilk <konrad.wilk@oracle.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit afa3fd8753c944f37c1cd182d5ad7c436c7614da
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Fri Dec 12 18:26:02 2014 +0000

    docs/commandline: Minor formatting fixes and clarifications
    
    `font` had a trailing single quote which was out of place.
    
    `gnttab_max_frames` was missing escapes for the underscores which caused the
    underscores to take their markdown meaning, causing 'max' in the middle to be
    italicised.  Escape the underscores, and make all command line parameters
    bold, to be consistent with the existing style.
    
    Clarify how the default for `nmi` changes between debug and non debug builds
    of Xen.
    
    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>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 3f727fb1a7d5f3be2513ab2e692b067075325fb3
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Tue Dec 9 16:43:22 2014 +0000

    python/xc: Fix multiple issues in pyflask_context_to_sid()
    
    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.
    
    Coverity also complains about passing a non-NUL terminated string to
    xc_flask_context_to_sid().  xc_flask_context_to_sid() doesn't actually take a
    NUL terminated string, but it does take a char* which, in context, used to be
    a string, which is why Coverity complains.
    
    One solution would be to use strdup(ctx) which is simpler than a
    strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated
    string being used with xc_flask_context_to_sid().
    
    However, ctx is strictly an input to the hypercall and is not mutated along
    the way.  Both these issues can be fixed, and the error logic simplified, by
    not duplicating ctx in the first place.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Coverity-IDs: 1055305 1055721
    Acked-by: 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>

commit dcd84861b0b01b8895716d4c803c9d24c31c8cab
Author: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date:   Mon Dec 8 15:51:47 2014 +0200

    xen/serial: setup UART idle mode for OMAP
    
    The UART is not able to receive bytes when idle mode is not configured
    properly, therefore setup the UART with autoidle and wakeup enabled.
    
    Older Linux kernels (for example 3.8) configure hwmods for all devices
    even if the device tree nodes for those devices is absent in device
    tree, thus UART idle mode is configured too.  With such kernels we can
    workaround the issue by adding a fake node in the UART containing this
    MMIO range, which is therefore mapped by Xen to dom0, which
    reconfigures the UART, causing things to work normally.
    
    Newer Linux Kernels (3.12 and beyond) do not configure idle mode for
    UART and so this hack no longer works.
    
    Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    [ ijc -- updated commit message as discussed ]

commit 6c9b27d3f363889718e7e046511383927f257095
Merge: 2676bc9 05fecc3
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Dec 15 17:40:12 2014 +0000

    Merge tag '4.5.0-rc4' into staging
    
    Xen 4.5.0 RC4

commit 05fecc382e129731c6595268a377f4bff879f694
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Dec 15 11:35:59 2014 -0500

    Xen-4.5.0-rc4: Update tag for qemu-xen.
    
    QEMU-traditional has nothing new, so stay at rc1 there.
    
    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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr5-0002eB-ND; Wed, 17 Dec 2014 15:49:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Y1Gr4-0002bm-BZ
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:38 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	FE/B5-27584-116A1945; Wed, 17 Dec 2014 15:49:37 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418831375!13913785!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13565 invoked from network); 17 Dec 2014 15:49:36 -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 Dec 2014 15:49:36 -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 sBHFnTkF019690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:30 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
	sBHFnS4B018651
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:29 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
	sBHFnSXj020063; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:40 -0500
Message-Id: <1418830734-1558-10-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 09/23] 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr4-0002cy-VH; Wed, 17 Dec 2014 15:49: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 1Y1Gr3-0002bK-TL
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:38 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	15/2D-02699-116A1945; Wed, 17 Dec 2014 15:49:37 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418831374!10284613!1
X-Originating-IP: [156.151.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 14121 invoked from network); 17 Dec 2014 15:49:36 -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; 17 Dec 2014 15:49:36 -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 sBHFnRXm030232
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:28 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
	sBHFnQT0018712
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:27 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
	sBHFnQPU019980; Wed, 17 Dec 2014 15:49:26 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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:38 -0500
Message-Id: <1418830734-1558-8-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 07/23] 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrE-0002pJ-5t; Wed, 17 Dec 2014 15:49:48 +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 1Y1GrB-0002l7-RD
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:46 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	27/06-27584-816A1945; Wed, 17 Dec 2014 15:49:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418831381!13965445!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19516 invoked from network); 17 Dec 2014 15:49:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 15:49:43 -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 sBHFnZ9x019795
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:35 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
	sBHFnYGO019083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Dec 2014 15:49:34 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
	sBHFnXg5008639; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:45 -0500
Message-Id: <1418830734-1558-15-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 14/23] 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 2051609..6ba68df 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -375,57 +375,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);
@@ -500,30 +449,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 7d94b0b..e9325d0 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -724,62 +724,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);
@@ -849,23 +793,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" */
@@ -897,16 +898,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 4373b03..121d281 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -449,3 +449,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 1171b2a..cf32f82 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -62,7 +62,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 *);
 
 /* VPMU states */
-- 
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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrE-0002qE-Mq; Wed, 17 Dec 2014 15:49:48 +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 1Y1GrC-0002lI-03
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:46 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	64/3C-14214-916A1945; Wed, 17 Dec 2014 15:49:45 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418831383!8516988!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6718 invoked from network); 17 Dec 2014 15:49: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; 17 Dec 2014 15:49: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 sBHFnais019832
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49: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
	sBHFnab5019204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:36 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
	sBHFnZkZ019188; Wed, 17 Dec 2014 15:49:35 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 ; Wed, 17 Dec 2014 07:49:35 -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: Wed, 17 Dec 2014 10:38:48 -0500
Message-Id: <1418830734-1558-18-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 17/23] 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 59cca08..a8cb9ae 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1709,7 +1709,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:
@@ -1860,7 +1861,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 bd6fc8e..7df246c 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -324,7 +324,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) )
@@ -354,7 +354,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)
@@ -372,7 +372,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 07d775d..28fabf9 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -479,36 +479,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) )
         {
@@ -517,18 +522,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 )
@@ -551,6 +559,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) )
@@ -562,45 +573,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)
@@ -628,19 +611,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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrB-0002l4-BR; Wed, 17 Dec 2014 15:49: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 1Y1Gr9-0002hs-B6
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:43 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	B8/DF-24124-616A1945; Wed, 17 Dec 2014 15:49:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418831380!8629912!1
X-Originating-IP: [156.151.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 25480 invoked from network); 17 Dec 2014 15:49:41 -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 Dec 2014 15:49: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 sBHFnWTg030303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:33 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
	sBHFnW9h018975
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49: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
	sBHFnWD5018960; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:44 -0500
Message-Id: <1418830734-1558-14-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 13/23] 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                  |  25 +++-
 xen/arch/x86/hvm/vmx/vmcs.c                  |   7 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c            |  27 +++-
 xen/arch/x86/hvm/vpmu.c                      | 182 ++++++++++++++++++++++++++-
 xen/arch/x86/oprofile/nmi_int.c              |   3 +-
 xen/arch/x86/x86_64/compat/entry.S           |   4 +
 xen/arch/x86/x86_64/entry.S                  |   4 +
 xen/include/asm-x86/hvm/vmx/vmcs.h           |   7 +-
 xen/include/asm-x86/hvm/vpmu.h               |  33 +++--
 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 +
 20 files changed, 364 insertions(+), 30 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 4e45fa8..d00622d 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(vcpu_vpmu(prev));
+            vpmu_switch_from(vcpu_vpmu(prev), vcpu_vpmu(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(next) && (prev != next) )
         /* Must be done with interrupts enabled */
-        vpmu_load(vcpu_vpmu(next));
+        vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(next));
 
     context_saved(prev);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index bbe2733..2051609 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -253,6 +253,26 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
     return 1;
 }
 
+static void amd_vpmu_unload(struct vpmu_struct *vpmu)
+{
+    struct vcpu *v;
+
+    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_FROZEN) )
+    {
+        unsigned int i;
+
+        for ( i = 0; i < num_counters; i++ )
+            wrmsrl(ctrls[i], 0);
+        context_save(vpmu);
+    }
+
+    v = vpmu_vcpu(vpmu);
+    if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
+        amd_vpmu_unset_msr_bitmap(v);
+
+    vpmu_reset(vpmu, VPMU_FROZEN);
+}
+
 static void context_update(unsigned int msr, u64 msr_content)
 {
     unsigned int i;
@@ -474,17 +494,18 @@ struct arch_vpmu_ops amd_vpmu_ops = {
     .arch_vpmu_destroy = amd_vpmu_destroy,
     .arch_vpmu_save = amd_vpmu_save,
     .arch_vpmu_load = amd_vpmu_load,
+    .arch_vpmu_unload = amd_vpmu_unload,
     .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/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index b9e3ef8..f45ce93 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1183,11 +1183,10 @@ int vmx_read_guest_msr(u32 msr, u64 *val)
     return -ESRCH;
 }
 
-int vmx_write_guest_msr(u32 msr, u64 val)
+int vmx_write_guest_msr_vcpu(struct vcpu *v, u32 msr, u64 val)
 {
-    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 i, msr_count = v->arch.hvm_vmx.msr_count;
+    struct vmx_msr_entry *msr_area = v->arch.hvm_vmx.msr_area;
 
     for ( i = 0; i < msr_count; i++ )
     {
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 1b2d048..7d94b0b 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -320,6 +320,22 @@ static int core2_vpmu_save(struct vpmu_struct *vpmu)
     return 1;
 }
 
+static void core2_vpmu_unload(struct vpmu_struct *vpmu)
+{
+    struct vcpu *v = vpmu_vcpu(vpmu);
+
+    if ( !has_hvm_container_vcpu(v) )
+        wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+    else
+        vmx_write_guest_msr_vcpu(v, MSR_CORE_PERF_GLOBAL_CTRL, 0);
+
+    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
+        __core2_vpmu_save(vpmu);
+
+    if ( has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
+        core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
+}
+
 static inline void __core2_vpmu_load(struct vpmu_struct *vpmu)
 {
     unsigned int i, pmc_start;
@@ -708,13 +724,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) )
@@ -787,6 +803,7 @@ struct arch_vpmu_ops core2_vpmu_ops = {
     .arch_vpmu_destroy = core2_vpmu_destroy,
     .arch_vpmu_save = core2_vpmu_save,
     .arch_vpmu_load = core2_vpmu_load,
+    .arch_vpmu_unload = core2_vpmu_unload,
     .arch_vpmu_dump = core2_vpmu_dump
 };
 
@@ -829,7 +846,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 +854,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 +897,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 0a2e1a7..4373b03 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;
@@ -243,11 +255,11 @@ void vpmu_initialise(struct vcpu *v)
     switch ( vendor )
     {
     case X86_VENDOR_AMD:
-        ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
+        ret = svm_vpmu_initialise(v);
         break;
 
     case X86_VENDOR_INTEL:
-        ret = vmx_vpmu_initialise(v, opt_vpmu_enabled);
+        ret = vmx_vpmu_initialise(v);
         break;
 
     default:
@@ -277,3 +289,163 @@ void vpmu_dump(struct vcpu *v)
         vpmu->arch_vpmu_ops->arch_vpmu_dump(v);
 }
 
+void vpmu_unload(struct vpmu_struct *vpmu)
+{
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_RUNNING) )
+        return;
+
+    if (vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_unload)
+        vpmu->arch_vpmu_ops->arch_vpmu_unload(vpmu);
+
+    vpmu_reset(vpmu, VPMU_RUNNING | VPMU_RUNNING);
+}
+
+static cpumask_t vpmu_cpumask_unload;
+
+static long vpmu_unload_next(void *arg)
+{
+    struct vcpu *last;
+
+    local_irq_disable(); /* so that last_vcpu doesn't change under us. */
+
+    last = this_cpu(last_vcpu);
+    if ( last )
+    {
+        vpmu_unload(vcpu_vpmu(last));
+        this_cpu(last_vcpu) = NULL;
+    }
+
+    local_irq_enable();
+
+    cpumask_and(&vpmu_cpumask_unload, &vpmu_cpumask_unload, &cpu_online_map);
+    if ( cpumask_weight(&vpmu_cpumask_unload) > 1 )
+    {
+        int ret;
+        int cpu = cpumask_cycle(smp_processor_id(), &vpmu_cpumask_unload);
+
+        cpumask_clear_cpu(smp_processor_id(), &vpmu_cpumask_unload);
+
+        ret = continue_hypercall_on_cpu(cpu, vpmu_unload_next, arg);
+        if ( ret )
+        {
+            vpmu_mode = (unsigned long)arg;
+            cpumask_clear(&vpmu_cpumask_unload);
+            return ret;
+        }
+    }
+    else
+        cpumask_clear(&vpmu_cpumask_unload);
+
+    return 0;
+}
+
+static int vpmu_unload_all(unsigned long old_mode)
+{
+    int ret = 0;
+
+    vpmu_unload(vcpu_vpmu(current));
+
+    if ( nr_cpu_ids > 1 )
+    {
+        unsigned int cpu;
+
+        cpumask_or(&vpmu_cpumask_unload, &vpmu_cpumask_unload, &cpu_online_map);
+        cpu = cpumask_cycle(smp_processor_id(), &vpmu_cpumask_unload);
+
+        ret = continue_hypercall_on_cpu(cpu, vpmu_unload_next,
+                                        (void *)old_mode);
+        if ( ret )
+            cpumask_clear(&vpmu_cpumask_unload);
+    }
+
+    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:
+    {
+        unsigned int 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 ( !cpumask_empty(&vpmu_cpumask_unload) )
+        {
+            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. */
+            ret = vpmu_unload_all(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/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c
index 13534d4..3c3a37c 100644
--- a/xen/arch/x86/oprofile/nmi_int.c
+++ b/xen/arch/x86/oprofile/nmi_int.c
@@ -47,7 +47,8 @@ static int passive_domain_msr_op_checks(unsigned int msr, int *typep, int *index
 	if ( !model->is_arch_pmu_msr(msr, typep, indexp) )
 		return 0;
 
-	if ( !vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) )
+	if ( !vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED |
+                               VPMU_CONTEXT_ALLOCATED) )
 		if ( ! model->allocated_msr(current) )
 			return 0;
 	return 1;
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/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 949884b..5407379 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -489,7 +489,7 @@ extern const unsigned int vmx_introspection_force_enabled_msrs_size;
 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_write_guest_msr_vcpu(struct vcpu *v, u32 msr, u64 val);
 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);
@@ -509,6 +509,11 @@ static inline int vmx_add_host_load_msr(u32 msr)
     return vmx_add_msr(msr, VMX_HOST_MSR);
 }
 
+static inline int vmx_write_guest_msr(u32 msr, u64 val)
+{
+    return vmx_write_guest_msr_vcpu(current, msr, val);
+}
+
 DECLARE_PER_CPU(bool_t, vmxon);
 
 #endif /* ASM_X86_HVM_VMX_VMCS_H__ */
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 897d5de..1171b2a 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)
 
@@ -65,11 +58,12 @@ struct arch_vpmu_ops {
     void (*arch_vpmu_destroy)(struct vcpu *v);
     int (*arch_vpmu_save)(struct vpmu_struct *vpmu);
     void (*arch_vpmu_load)(struct vpmu_struct *vpmu);
+    void (*arch_vpmu_unload)(struct vpmu_struct *vpmu);
     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 *);
 
 /* VPMU states */
 #define VPMU_CONTEXT_ALLOCATED              0x1
@@ -111,10 +105,31 @@ void vpmu_initialise(struct vcpu *v);
 void vpmu_destroy(struct vcpu *v);
 void vpmu_save(struct vpmu_struct *vpmu);
 void vpmu_load(struct vpmu_struct *vpmu);
+void vpmu_unload(struct vpmu_struct *vpmu);
 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 */
+static inline void vpmu_switch_from(struct vpmu_struct *prev,
+                                    struct vpmu_struct *next)
+{
+    if ( vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+        vpmu_save(prev);
+}
+
+static inline void vpmu_switch_to(struct vpmu_struct *prev,
+                                  struct vpmu_struct *next)
+{
+    if ( vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+        vpmu_load(next);
+    else if ( vpmu_is_set(next, VPMU_CONTEXT_LOADED | VPMU_RUNNING) )
+        vpmu_unload(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 b6bef8c..f6f02e1 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -107,6 +107,7 @@
 ?	pmu_cntr_pair			arch-x86/pmu.h
 ?	pmu_intel_ctxt			arch-x86/pmu.h
 ?	pmu_regs			arch-x86/pmu.h
+?	pmu_params			pmu.h
 ?	flask_access			xsm/flask_op.h
 !	flask_boolean			xsm/flask_op.h
 ?	flask_cache_stats		xsm/flask_op.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 c589e49..a24c480 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1504,6 +1504,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);
@@ -1626,6 +1643,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 ed91c09..4786a39 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr0-0002Yy-Vw; Wed, 17 Dec 2014 15:49:34 +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 1Y1Gqz-0002Yh-Ut
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:34 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	F1/7B-25727-D06A1945; Wed, 17 Dec 2014 15:49:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418831370!14119915!1
X-Originating-IP: [156.151.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 8702 invoked from network); 17 Dec 2014 15:49:32 -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; 17 Dec 2014 15:49:32 -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 sBHFnPEZ030203
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:26 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
	sBHFnOMo008313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:25 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
	sBHFnOPM019857; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:36 -0500
Message-Id: <1418830734-1558-6-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 05/23] 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 9c4a297..5e7a806 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr1-0002ZX-O9; Wed, 17 Dec 2014 15:49:35 +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 1Y1Gr0-0002Yt-Vy
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:35 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	73/2F-28296-E06A1945; Wed, 17 Dec 2014 15:49:34 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418831371!14016643!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10226 invoked from network); 17 Dec 2014 15:49:33 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 15:49: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 sBHFnLxq019562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49: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
	sBHFnJIT008183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:20 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
	sBHFnJe3018373; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:31 -0500
Message-Id: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 00/23] 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 16 of PV(H) PMU patches.

* Many changes in VPMU mode patch (#13):
  * Replaced arguments to some vpmu routines (vcpu -> vpmu). New patch (#12)
  * Added vpmu_unload vpmu op to completely unload vpmu data (e.g clear
    MSR bitmaps). This routine may be called in context switch (vpmu_switch_to()).
  * Added vmx_write_guest_msr_vcpu() interface to write MSRs of non-current VCPU
  * Use cpumask_cycle instead of cpumask_next
  * Dropped timeout error
  * Adjusted types of mode variables
  * Don't allow oprofile to allocate its context on MSR access if VPMU context
    has already been allocated (which may happen when VMPU mode was set to off
    while the guest was running)
* vpmu_initialise() no longer turns off VPMU globally on failure. New patch (#2)
* vpmu_do_msr() will return 1 (failure) if vpmu_ops are not set. This is done to
  prevent PV guests that are not VPMU-enabled from wrongly assuming that they have
  access to counters (Linux check_hw_exists() will make this assumption) (patch #18)
* Add cpl field to shared structure that will be passed for HVM guests' samples
  (instead of PMU_SAMPLE_USER flag). Add PMU_SAMPLE_PV flag to mark whose sample
  is passed up. (Patches ## 10, 19, 22)

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 (23):
  common/symbols: Export hypervisor symbols to privileged guest
  x86/VPMU: Don't globally disable VPMU if initialization fails.
  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: Replace vcpu with vpmu as argument to some routines
  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                            | 896 +++++++++++++++++++++
 xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c}    | 289 ++++---
 .../x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} | 815 ++++++++++---------
 xen/arch/x86/domain.c                              |  27 +-
 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                        |  91 +--
 xen/arch/x86/hvm/vmx/vmx.c                         |  28 +-
 xen/arch/x86/hvm/vpmu.c                            | 266 ------
 xen/arch/x86/oprofile/nmi_int.c                    |   3 +-
 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                 |  25 +-
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h           |  51 --
 xen/include/asm-x86/hvm/vpmu.h                     | 105 ---
 xen/include/asm-x86/softirq.h                      |   3 +-
 xen/include/asm-x86/vpmu.h                         | 149 ++++
 xen/include/public/arch-arm.h                      |   3 +
 xen/include/public/arch-x86/pmu.h                  |  97 +++
 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 +
 45 files changed, 2194 insertions(+), 1040 deletions(-)
 create mode 100644 xen/arch/x86/cpu/vpmu.c
 rename xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} (64%)
 rename xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} (56%)
 delete mode 100644 xen/arch/x86/hvm/vpmu.c
 delete mode 100644 xen/include/asm-x86/hvm/vmx/vpmu_core2.h
 delete mode 100644 xen/include/asm-x86/hvm/vpmu.h
 create mode 100644 xen/include/asm-x86/vpmu.h
 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr8-0002hY-Kd; Wed, 17 Dec 2014 15:49:42 +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 1Y1Gr6-0002ev-Ns
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:41 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	86/0C-14214-416A1945; Wed, 17 Dec 2014 15:49:40 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418831377!9798565!1
X-Originating-IP: [156.151.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 8808 invoked from network); 17 Dec 2014 15:49:38 -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; 17 Dec 2014 15:49:38 -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 sBHFnUXe030284
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:31 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
	sBHFnU1K008516
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:30 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
	sBHFnTU5018671; Wed, 17 Dec 2014 15:49:29 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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:41 -0500
Message-Id: <1418830734-1558-11-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 10/23] 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        |  91 +++++++++++++++++++++++
 xen/include/public/pmu.h                 |  38 ++++++++++
 xen/include/xlat.lst                     |   4 +
 11 files changed, 275 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 d45a1ba..9f37bba 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
@@ -230,6 +237,9 @@ void vpmu_initialise(struct vcpu *v)
     if ( is_pvh_vcpu(v) )
         return;
 
+    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..8bbe341
--- /dev/null
+++ b/xen/include/public/arch-x86/pmu.h
@@ -0,0 +1,91 @@
+#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;
+    uint8_t cpl;
+    uint8_t pad[3];
+};
+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..b6bef8c 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_amd_ctxt			arch-x86/pmu.h
+?	pmu_cntr_pair			arch-x86/pmu.h
+?	pmu_intel_ctxt			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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr6-0002ej-4z; Wed, 17 Dec 2014 15:49: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 1Y1Gr5-0002ca-1h
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:39 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AC/8A-09842-216A1945; Wed, 17 Dec 2014 15:49:38 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418831376!16306342!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10017 invoked from network); 17 Dec 2014 15:49:37 -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; 17 Dec 2014 15:49:37 -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 sBHFnVZt019714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:31 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
	sBHFnUAk020191
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:30 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
	sBHFnUt9018902; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:42 -0500
Message-Id: <1418830734-1558-12-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 11/23] 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrF-0002sI-L5; Wed, 17 Dec 2014 15:49:49 +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 1Y1GrD-0002oN-Uz
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:48 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	63/0B-09284-B16A1945; Wed, 17 Dec 2014 15:49:47 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418831384!14016715!1
X-Originating-IP: [156.151.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 12289 invoked from network); 17 Dec 2014 15:49:46 -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; 17 Dec 2014 15:49: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 sBHFnbQi030382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:38 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
	sBHFnaAl020630
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:37 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
	sBHFna3T019235; Wed, 17 Dec 2014 15:49:36 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 ; Wed, 17 Dec 2014 07:49:36 -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: Wed, 17 Dec 2014 10:38:49 -0500
Message-Id: <1418830734-1558-19-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 18/23] 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. If vpmu ops
for VCPU are not initialized (which is the case, for example, for PV guests that
are not "VPMU-enlightened") access to MSRs will return failure.

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 | 53 +++++++++++++++++++++++++++++++--------
 xen/arch/x86/hvm/vpmu.c           |  4 +--
 xen/arch/x86/traps.c              | 50 +++++++++++++++++++++++++++++++++++-
 4 files changed, 95 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7d5d46b..db6e6ef 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2081,8 +2081,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 28fabf9..8e6386e 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,19 +300,23 @@ static inline void __core2_vpmu_save(struct vpmu_struct *vpmu)
         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(vpmu_vcpu(vpmu)) )
+        rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
 }
 
 static int core2_vpmu_save(struct vpmu_struct *vpmu)
 {
-    struct vcpu *v;
+    struct vcpu *v = vpmu_vcpu(vpmu);
+
+    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;
 
     __core2_vpmu_save(vpmu);
 
-    v = vpmu_vcpu(vpmu);
-
     /* Unset PMU MSR bitmap to trap lazy load. */
     if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
          has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
@@ -360,6 +365,13 @@ static inline void __core2_vpmu_load(struct vpmu_struct *vpmu)
     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(vpmu_vcpu(vpmu)) )
+    {
+        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 vpmu_struct *vpmu)
@@ -458,7 +470,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;
@@ -502,7 +513,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: "
@@ -530,14 +546,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 )
         {
@@ -562,7 +582,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;
@@ -576,9 +600,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);
@@ -605,7 +635,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/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 6503556..510b688 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -95,7 +95,7 @@ int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
         return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
-    return 0;
+    return 1;
 }
 
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
@@ -107,7 +107,7 @@ int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
         return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
-    return 0;
+    return 1;
 }
 
 void vpmu_do_interrupt(struct cpu_user_regs *regs)
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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrC-0002m5-2U; Wed, 17 Dec 2014 15:49: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 1Y1GrA-0002k9-SQ
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:45 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	17/06-27584-816A1945; Wed, 17 Dec 2014 15:49:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418831381!13941700!1
X-Originating-IP: [156.151.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 25171 invoked from network); 17 Dec 2014 15:49:43 -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; 17 Dec 2014 15:49:43 -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 sBHFnYgQ030335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:35 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
	sBHFnYXq019078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:34 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
	sBHFnXpX019064; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:46 -0500
Message-Id: <1418830734-1558-16-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 15/23] 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>
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>
---
 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            |  79 +++++++++++++++------
 xen/arch/x86/hvm/vpmu.c                      | 101 +++++++++++++++++++++++++--
 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, 211 insertions(+), 43 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 d00622d..a29db67 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 51ffc90..0c0ccb1 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 a7655bd..59cca08 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1166,7 +1166,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 6ba68df..bd6fc8e 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -382,17 +382,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 */
@@ -459,15 +461,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;
@@ -509,6 +515,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 e9325d0..07d775d 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -378,24 +378,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(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);
+    if ( has_hvm_container_vcpu(v) )
+    {
+        if ( is_hvm_vcpu(v) && !acquire_pmu_ownership(PMU_OWNER_HVM) )
+            goto out_err;
 
-    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;
+        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 +
@@ -408,10 +418,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",
@@ -731,12 +743,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 = {
@@ -847,6 +867,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;
@@ -912,5 +936,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 121d281..6503556 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>
@@ -241,9 +242,6 @@ void vpmu_initialise(struct vcpu *v)
     uint8_t vendor = current_cpu_data.x86_vendor;
     int ret;
 
-    if ( is_pvh_vcpu(v) )
-        return;
-
     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);
 
@@ -251,6 +249,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 )
     {
@@ -277,7 +276,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(). */
@@ -425,7 +506,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) )
@@ -443,6 +524,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 cf32f82..42a09f9 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -44,6 +44,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;
 };
 
 /* Arch specific operations shared by all vpmus */
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 a24c480..e98715d 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1517,6 +1517,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 4786a39..43908e8 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gqy-0002Ya-KD; Wed, 17 Dec 2014 15:49: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 1Y1Gqx-0002YV-3D
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:31 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	29/9E-25276-A06A1945; Wed, 17 Dec 2014 15:49:30 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418831368!16306310!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8970 invoked from network); 17 Dec 2014 15:49:29 -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; 17 Dec 2014 15:49:29 -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 sBHFnLnT019574
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:22 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
	sBHFnKJW019710
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:21 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
	sBHFnKpP018418; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:32 -0500
Message-Id: <1418830734-1558-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 01/23] 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 d48463f..c589e49 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1410,6 +1410,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 1da9f63..ed91c09 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrC-0002mt-Ig; Wed, 17 Dec 2014 15:49:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Y1GrB-0002kM-4L
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:45 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	C8/B5-02953-816A1945; Wed, 17 Dec 2014 15:49:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418831382!15748621!1
X-Originating-IP: [156.151.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 23870 invoked from network); 17 Dec 2014 15:49:43 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 15:49:43 -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 sBHFnaK3030360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49: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
	sBHFnZ3w008730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:35 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
	sBHFnYqQ020511; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:47 -0500
Message-Id: <1418830734-1558-17-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 16/23] 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 | 22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a29db67..7d5d46b 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1541,17 +1541,14 @@ 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(vcpu_vpmu(prev), vcpu_vpmu(next));
-
-        if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
-            pt_save_timer(prev);
+        _update_runstate_area(prev);
+        vpmu_switch_from(vcpu_vpmu(prev), vcpu_vpmu(next));
     }
 
+    if ( is_hvm_vcpu(prev) && !list_empty(&prev->arch.hvm_vcpu.tm_list) )
+        pt_save_timer(prev);
+
     local_irq_disable();
 
     set_current(next);
@@ -1589,15 +1586,16 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
                            !is_hardware_domain(next->domain));
     }
 
-    if ( is_hvm_vcpu(next) && (prev != next) )
-        /* Must be done with interrupts enabled */
-        vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(next));
-
     context_saved(prev);
 
     if ( prev != next )
+    {
         _update_runstate_area(next);
 
+        /* Must be done with interrupts enabled */
+        vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr1-0002ZA-Bx; Wed, 17 Dec 2014 15:49: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 1Y1Gr0-0002Yi-3X
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:34 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	E3/18-11581-D06A1945; Wed, 17 Dec 2014 15:49:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418831371!11043704!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10992 invoked from network); 17 Dec 2014 15:49:32 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Dec 2014 15:49:32 -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 sBHFnPWG019631
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49: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
	sBHFnOf2019850
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:25 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
	sBHFnNDZ018463; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:35 -0500
Message-Id: <1418830734-1558-5-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 04/23] 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr2-0002Zq-4E; Wed, 17 Dec 2014 15:49:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Y1Gr1-0002Yx-BT
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	30/7A-09842-E06A1945; Wed, 17 Dec 2014 15:49:34 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418831372!16246379!1
X-Originating-IP: [156.151.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 31207 invoked from network); 17 Dec 2014 15:49:34 -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; 17 Dec 2014 15:49:34 -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 sBHFnM23030159
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:23 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
	sBHFnMq5018413
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:22 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
	sBHFnLix018376; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:33 -0500
Message-Id: <1418830734-1558-3-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 02/23] x86/VPMU: Don't globally disable VPMU
	if initialization 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

The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
forever.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/vpmu.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1df74c2..b43ea80 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -218,6 +218,7 @@ void vpmu_initialise(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t vendor = current_cpu_data.x86_vendor;
+    int ret;
 
     if ( is_pvh_vcpu(v) )
         return;
@@ -230,21 +231,21 @@ 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;
+        ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
         break;
 
     case X86_VENDOR_INTEL:
-        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
-            opt_vpmu_enabled = 0;
+        ret = vmx_vpmu_initialise(v, opt_vpmu_enabled);
         break;
 
     default:
-        printk("VPMU: Initialization failed. "
-               "Unknown CPU vendor %d\n", vendor);
-        opt_vpmu_enabled = 0;
+        ret = -EINVAL;
+        printk(XENLOG_G_WARNING "VPMU: Unknown CPU vendor %d\n", vendor);
         break;
     }
+
+    if ( ret )
+        printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
 }
 
 void vpmu_destroy(struct vcpu *v)
-- 
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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr2-0002aH-HA; Wed, 17 Dec 2014 15:49:36 +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 1Y1Gr1-0002Yw-Ag
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:35 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	BE/18-11581-E06A1945; Wed, 17 Dec 2014 15:49:34 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418831372!13913776!1
X-Originating-IP: [156.151.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 13006 invoked from network); 17 Dec 2014 15:49:34 -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; 17 Dec 2014 15:49:34 -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 sBHFnShf030256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:29 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
	sBHFnRqw008422
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:28 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
	sBHFnRvj018754; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:39 -0500
Message-Id: <1418830734-1558-9-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 08/23] 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 72b6509..56b9d23 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 5e7a806..d45a1ba 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr4-0002cY-IN; Wed, 17 Dec 2014 15:49: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 1Y1Gr3-0002aT-7c
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:37 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	03/CD-17735-016A1945; Wed, 17 Dec 2014 15:49:36 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418831373!14016656!1
X-Originating-IP: [156.151.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 10728 invoked from network); 17 Dec 2014 15:49:35 -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; 17 Dec 2014 15:49: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 sBHFnREf030233
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49: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
	sBHFnQIo008390
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Dec 2014 15:49:27 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
	sBHFnPIO008343; Wed, 17 Dec 2014 15:49:26 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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:37 -0500
Message-Id: <1418830734-1558-7-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 06/23] 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr2-0002ap-Th; Wed, 17 Dec 2014 15:49:36 +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 1Y1Gr1-0002Z7-Kf
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:35 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	A5/1D-02699-E06A1945; Wed, 17 Dec 2014 15:49:34 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418831372!11072522!1
X-Originating-IP: [156.151.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 25632 invoked from network); 17 Dec 2014 15:49:34 -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; 17 Dec 2014 15:49: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 sBHFnO0c030187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:25 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
	sBHFnNCT018547
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:24 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
	sBHFnMEb018426; Wed, 17 Dec 2014 15:49:22 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 ; Wed, 17 Dec 2014 07:49:22 -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: Wed, 17 Dec 2014 10:38:34 -0500
Message-Id: <1418830734-1558-4-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 03/23] 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 b43ea80..9c4a297 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrC-0002mt-Ig; Wed, 17 Dec 2014 15:49:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Y1GrB-0002kM-4L
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:45 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	C8/B5-02953-816A1945; Wed, 17 Dec 2014 15:49:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418831382!15748621!1
X-Originating-IP: [156.151.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 23870 invoked from network); 17 Dec 2014 15:49:43 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 15:49:43 -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 sBHFnaK3030360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49: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
	sBHFnZ3w008730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:35 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
	sBHFnYqQ020511; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:47 -0500
Message-Id: <1418830734-1558-17-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 16/23] 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 | 22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a29db67..7d5d46b 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1541,17 +1541,14 @@ 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(vcpu_vpmu(prev), vcpu_vpmu(next));
-
-        if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
-            pt_save_timer(prev);
+        _update_runstate_area(prev);
+        vpmu_switch_from(vcpu_vpmu(prev), vcpu_vpmu(next));
     }
 
+    if ( is_hvm_vcpu(prev) && !list_empty(&prev->arch.hvm_vcpu.tm_list) )
+        pt_save_timer(prev);
+
     local_irq_disable();
 
     set_current(next);
@@ -1589,15 +1586,16 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
                            !is_hardware_domain(next->domain));
     }
 
-    if ( is_hvm_vcpu(next) && (prev != next) )
-        /* Must be done with interrupts enabled */
-        vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(next));
-
     context_saved(prev);
 
     if ( prev != next )
+    {
         _update_runstate_area(next);
 
+        /* Must be done with interrupts enabled */
+        vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr6-0002ej-4z; Wed, 17 Dec 2014 15:49: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 1Y1Gr5-0002ca-1h
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:39 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AC/8A-09842-216A1945; Wed, 17 Dec 2014 15:49:38 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418831376!16306342!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10017 invoked from network); 17 Dec 2014 15:49:37 -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; 17 Dec 2014 15:49:37 -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 sBHFnVZt019714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:31 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
	sBHFnUAk020191
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:30 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
	sBHFnUt9018902; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:42 -0500
Message-Id: <1418830734-1558-12-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 11/23] 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr1-0002ZA-Bx; Wed, 17 Dec 2014 15:49: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 1Y1Gr0-0002Yi-3X
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:34 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	E3/18-11581-D06A1945; Wed, 17 Dec 2014 15:49:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418831371!11043704!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10992 invoked from network); 17 Dec 2014 15:49:32 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Dec 2014 15:49:32 -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 sBHFnPWG019631
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49: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
	sBHFnOf2019850
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:25 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
	sBHFnNDZ018463; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:35 -0500
Message-Id: <1418830734-1558-5-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 04/23] 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr4-0002cY-IN; Wed, 17 Dec 2014 15:49: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 1Y1Gr3-0002aT-7c
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:37 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	03/CD-17735-016A1945; Wed, 17 Dec 2014 15:49:36 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418831373!14016656!1
X-Originating-IP: [156.151.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 10728 invoked from network); 17 Dec 2014 15:49:35 -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; 17 Dec 2014 15:49: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 sBHFnREf030233
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49: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
	sBHFnQIo008390
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Dec 2014 15:49:27 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
	sBHFnPIO008343; Wed, 17 Dec 2014 15:49:26 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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:37 -0500
Message-Id: <1418830734-1558-7-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 06/23] 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr1-0002ZX-O9; Wed, 17 Dec 2014 15:49:35 +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 1Y1Gr0-0002Yt-Vy
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:35 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	73/2F-28296-E06A1945; Wed, 17 Dec 2014 15:49:34 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418831371!14016643!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10226 invoked from network); 17 Dec 2014 15:49:33 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 15:49: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 sBHFnLxq019562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49: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
	sBHFnJIT008183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:20 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
	sBHFnJe3018373; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:31 -0500
Message-Id: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 00/23] 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 16 of PV(H) PMU patches.

* Many changes in VPMU mode patch (#13):
  * Replaced arguments to some vpmu routines (vcpu -> vpmu). New patch (#12)
  * Added vpmu_unload vpmu op to completely unload vpmu data (e.g clear
    MSR bitmaps). This routine may be called in context switch (vpmu_switch_to()).
  * Added vmx_write_guest_msr_vcpu() interface to write MSRs of non-current VCPU
  * Use cpumask_cycle instead of cpumask_next
  * Dropped timeout error
  * Adjusted types of mode variables
  * Don't allow oprofile to allocate its context on MSR access if VPMU context
    has already been allocated (which may happen when VMPU mode was set to off
    while the guest was running)
* vpmu_initialise() no longer turns off VPMU globally on failure. New patch (#2)
* vpmu_do_msr() will return 1 (failure) if vpmu_ops are not set. This is done to
  prevent PV guests that are not VPMU-enabled from wrongly assuming that they have
  access to counters (Linux check_hw_exists() will make this assumption) (patch #18)
* Add cpl field to shared structure that will be passed for HVM guests' samples
  (instead of PMU_SAMPLE_USER flag). Add PMU_SAMPLE_PV flag to mark whose sample
  is passed up. (Patches ## 10, 19, 22)

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 (23):
  common/symbols: Export hypervisor symbols to privileged guest
  x86/VPMU: Don't globally disable VPMU if initialization fails.
  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: Replace vcpu with vpmu as argument to some routines
  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                            | 896 +++++++++++++++++++++
 xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c}    | 289 ++++---
 .../x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} | 815 ++++++++++---------
 xen/arch/x86/domain.c                              |  27 +-
 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                        |  91 +--
 xen/arch/x86/hvm/vmx/vmx.c                         |  28 +-
 xen/arch/x86/hvm/vpmu.c                            | 266 ------
 xen/arch/x86/oprofile/nmi_int.c                    |   3 +-
 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                 |  25 +-
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h           |  51 --
 xen/include/asm-x86/hvm/vpmu.h                     | 105 ---
 xen/include/asm-x86/softirq.h                      |   3 +-
 xen/include/asm-x86/vpmu.h                         | 149 ++++
 xen/include/public/arch-arm.h                      |   3 +
 xen/include/public/arch-x86/pmu.h                  |  97 +++
 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 +
 45 files changed, 2194 insertions(+), 1040 deletions(-)
 create mode 100644 xen/arch/x86/cpu/vpmu.c
 rename xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} (64%)
 rename xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} (56%)
 delete mode 100644 xen/arch/x86/hvm/vpmu.c
 delete mode 100644 xen/include/asm-x86/hvm/vmx/vpmu_core2.h
 delete mode 100644 xen/include/asm-x86/hvm/vpmu.h
 create mode 100644 xen/include/asm-x86/vpmu.h
 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr2-0002aH-HA; Wed, 17 Dec 2014 15:49:36 +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 1Y1Gr1-0002Yw-Ag
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:35 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	BE/18-11581-E06A1945; Wed, 17 Dec 2014 15:49:34 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418831372!13913776!1
X-Originating-IP: [156.151.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 13006 invoked from network); 17 Dec 2014 15:49:34 -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; 17 Dec 2014 15:49:34 -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 sBHFnShf030256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:29 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
	sBHFnRqw008422
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:28 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
	sBHFnRvj018754; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:39 -0500
Message-Id: <1418830734-1558-9-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 08/23] 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 72b6509..56b9d23 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 5e7a806..d45a1ba 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr2-0002Zq-4E; Wed, 17 Dec 2014 15:49:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Y1Gr1-0002Yx-BT
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:35 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	30/7A-09842-E06A1945; Wed, 17 Dec 2014 15:49:34 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418831372!16246379!1
X-Originating-IP: [156.151.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 31207 invoked from network); 17 Dec 2014 15:49:34 -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; 17 Dec 2014 15:49:34 -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 sBHFnM23030159
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:23 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
	sBHFnMq5018413
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:22 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
	sBHFnLix018376; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:33 -0500
Message-Id: <1418830734-1558-3-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 02/23] x86/VPMU: Don't globally disable VPMU
	if initialization 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

The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
forever.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/vpmu.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1df74c2..b43ea80 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -218,6 +218,7 @@ void vpmu_initialise(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t vendor = current_cpu_data.x86_vendor;
+    int ret;
 
     if ( is_pvh_vcpu(v) )
         return;
@@ -230,21 +231,21 @@ 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;
+        ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
         break;
 
     case X86_VENDOR_INTEL:
-        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
-            opt_vpmu_enabled = 0;
+        ret = vmx_vpmu_initialise(v, opt_vpmu_enabled);
         break;
 
     default:
-        printk("VPMU: Initialization failed. "
-               "Unknown CPU vendor %d\n", vendor);
-        opt_vpmu_enabled = 0;
+        ret = -EINVAL;
+        printk(XENLOG_G_WARNING "VPMU: Unknown CPU vendor %d\n", vendor);
         break;
     }
+
+    if ( ret )
+        printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
 }
 
 void vpmu_destroy(struct vcpu *v)
-- 
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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr8-0002hY-Kd; Wed, 17 Dec 2014 15:49:42 +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 1Y1Gr6-0002ev-Ns
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:41 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	86/0C-14214-416A1945; Wed, 17 Dec 2014 15:49:40 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418831377!9798565!1
X-Originating-IP: [156.151.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 8808 invoked from network); 17 Dec 2014 15:49:38 -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; 17 Dec 2014 15:49:38 -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 sBHFnUXe030284
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:31 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
	sBHFnU1K008516
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:30 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
	sBHFnTU5018671; Wed, 17 Dec 2014 15:49:29 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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:41 -0500
Message-Id: <1418830734-1558-11-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 10/23] 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        |  91 +++++++++++++++++++++++
 xen/include/public/pmu.h                 |  38 ++++++++++
 xen/include/xlat.lst                     |   4 +
 11 files changed, 275 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 d45a1ba..9f37bba 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
@@ -230,6 +237,9 @@ void vpmu_initialise(struct vcpu *v)
     if ( is_pvh_vcpu(v) )
         return;
 
+    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..8bbe341
--- /dev/null
+++ b/xen/include/public/arch-x86/pmu.h
@@ -0,0 +1,91 @@
+#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;
+    uint8_t cpl;
+    uint8_t pad[3];
+};
+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..b6bef8c 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_amd_ctxt			arch-x86/pmu.h
+?	pmu_cntr_pair			arch-x86/pmu.h
+?	pmu_intel_ctxt			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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr0-0002Yy-Vw; Wed, 17 Dec 2014 15:49:34 +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 1Y1Gqz-0002Yh-Ut
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:34 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	F1/7B-25727-D06A1945; Wed, 17 Dec 2014 15:49:33 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418831370!14119915!1
X-Originating-IP: [156.151.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 8702 invoked from network); 17 Dec 2014 15:49:32 -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; 17 Dec 2014 15:49:32 -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 sBHFnPEZ030203
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:26 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
	sBHFnOMo008313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:25 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
	sBHFnOPM019857; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:36 -0500
Message-Id: <1418830734-1558-6-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 05/23] 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 9c4a297..5e7a806 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrE-0002pJ-5t; Wed, 17 Dec 2014 15:49:48 +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 1Y1GrB-0002l7-RD
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:46 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	27/06-27584-816A1945; Wed, 17 Dec 2014 15:49:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418831381!13965445!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19516 invoked from network); 17 Dec 2014 15:49:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 15:49:43 -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 sBHFnZ9x019795
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:35 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
	sBHFnYGO019083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Dec 2014 15:49:34 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
	sBHFnXg5008639; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:45 -0500
Message-Id: <1418830734-1558-15-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 14/23] 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 2051609..6ba68df 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -375,57 +375,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);
@@ -500,30 +449,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 7d94b0b..e9325d0 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -724,62 +724,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);
@@ -849,23 +793,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" */
@@ -897,16 +898,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 4373b03..121d281 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -449,3 +449,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 1171b2a..cf32f82 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -62,7 +62,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 *);
 
 /* VPMU states */
-- 
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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrC-0002m5-2U; Wed, 17 Dec 2014 15:49: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 1Y1GrA-0002k9-SQ
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:45 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	17/06-27584-816A1945; Wed, 17 Dec 2014 15:49:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418831381!13941700!1
X-Originating-IP: [156.151.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 25171 invoked from network); 17 Dec 2014 15:49:43 -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; 17 Dec 2014 15:49:43 -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 sBHFnYgQ030335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:35 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
	sBHFnYXq019078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:34 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
	sBHFnXpX019064; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:46 -0500
Message-Id: <1418830734-1558-16-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 15/23] 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>
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>
---
 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            |  79 +++++++++++++++------
 xen/arch/x86/hvm/vpmu.c                      | 101 +++++++++++++++++++++++++--
 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, 211 insertions(+), 43 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 d00622d..a29db67 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 51ffc90..0c0ccb1 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 a7655bd..59cca08 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1166,7 +1166,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 6ba68df..bd6fc8e 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -382,17 +382,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 */
@@ -459,15 +461,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;
@@ -509,6 +515,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 e9325d0..07d775d 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -378,24 +378,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(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);
+    if ( has_hvm_container_vcpu(v) )
+    {
+        if ( is_hvm_vcpu(v) && !acquire_pmu_ownership(PMU_OWNER_HVM) )
+            goto out_err;
 
-    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;
+        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 +
@@ -408,10 +418,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",
@@ -731,12 +743,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 = {
@@ -847,6 +867,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;
@@ -912,5 +936,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 121d281..6503556 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>
@@ -241,9 +242,6 @@ void vpmu_initialise(struct vcpu *v)
     uint8_t vendor = current_cpu_data.x86_vendor;
     int ret;
 
-    if ( is_pvh_vcpu(v) )
-        return;
-
     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);
 
@@ -251,6 +249,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 )
     {
@@ -277,7 +276,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(). */
@@ -425,7 +506,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) )
@@ -443,6 +524,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 cf32f82..42a09f9 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -44,6 +44,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;
 };
 
 /* Arch specific operations shared by all vpmus */
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 a24c480..e98715d 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1517,6 +1517,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 4786a39..43908e8 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrB-0002l4-BR; Wed, 17 Dec 2014 15:49: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 1Y1Gr9-0002hs-B6
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:43 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	B8/DF-24124-616A1945; Wed, 17 Dec 2014 15:49:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418831380!8629912!1
X-Originating-IP: [156.151.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 25480 invoked from network); 17 Dec 2014 15:49:41 -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 Dec 2014 15:49: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 sBHFnWTg030303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:33 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
	sBHFnW9h018975
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49: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
	sBHFnWD5018960; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:44 -0500
Message-Id: <1418830734-1558-14-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 13/23] 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                  |  25 +++-
 xen/arch/x86/hvm/vmx/vmcs.c                  |   7 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c            |  27 +++-
 xen/arch/x86/hvm/vpmu.c                      | 182 ++++++++++++++++++++++++++-
 xen/arch/x86/oprofile/nmi_int.c              |   3 +-
 xen/arch/x86/x86_64/compat/entry.S           |   4 +
 xen/arch/x86/x86_64/entry.S                  |   4 +
 xen/include/asm-x86/hvm/vmx/vmcs.h           |   7 +-
 xen/include/asm-x86/hvm/vpmu.h               |  33 +++--
 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 +
 20 files changed, 364 insertions(+), 30 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 4e45fa8..d00622d 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(vcpu_vpmu(prev));
+            vpmu_switch_from(vcpu_vpmu(prev), vcpu_vpmu(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(next) && (prev != next) )
         /* Must be done with interrupts enabled */
-        vpmu_load(vcpu_vpmu(next));
+        vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(next));
 
     context_saved(prev);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index bbe2733..2051609 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -253,6 +253,26 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
     return 1;
 }
 
+static void amd_vpmu_unload(struct vpmu_struct *vpmu)
+{
+    struct vcpu *v;
+
+    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_FROZEN) )
+    {
+        unsigned int i;
+
+        for ( i = 0; i < num_counters; i++ )
+            wrmsrl(ctrls[i], 0);
+        context_save(vpmu);
+    }
+
+    v = vpmu_vcpu(vpmu);
+    if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
+        amd_vpmu_unset_msr_bitmap(v);
+
+    vpmu_reset(vpmu, VPMU_FROZEN);
+}
+
 static void context_update(unsigned int msr, u64 msr_content)
 {
     unsigned int i;
@@ -474,17 +494,18 @@ struct arch_vpmu_ops amd_vpmu_ops = {
     .arch_vpmu_destroy = amd_vpmu_destroy,
     .arch_vpmu_save = amd_vpmu_save,
     .arch_vpmu_load = amd_vpmu_load,
+    .arch_vpmu_unload = amd_vpmu_unload,
     .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/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index b9e3ef8..f45ce93 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1183,11 +1183,10 @@ int vmx_read_guest_msr(u32 msr, u64 *val)
     return -ESRCH;
 }
 
-int vmx_write_guest_msr(u32 msr, u64 val)
+int vmx_write_guest_msr_vcpu(struct vcpu *v, u32 msr, u64 val)
 {
-    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 i, msr_count = v->arch.hvm_vmx.msr_count;
+    struct vmx_msr_entry *msr_area = v->arch.hvm_vmx.msr_area;
 
     for ( i = 0; i < msr_count; i++ )
     {
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 1b2d048..7d94b0b 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -320,6 +320,22 @@ static int core2_vpmu_save(struct vpmu_struct *vpmu)
     return 1;
 }
 
+static void core2_vpmu_unload(struct vpmu_struct *vpmu)
+{
+    struct vcpu *v = vpmu_vcpu(vpmu);
+
+    if ( !has_hvm_container_vcpu(v) )
+        wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+    else
+        vmx_write_guest_msr_vcpu(v, MSR_CORE_PERF_GLOBAL_CTRL, 0);
+
+    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
+        __core2_vpmu_save(vpmu);
+
+    if ( has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
+        core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
+}
+
 static inline void __core2_vpmu_load(struct vpmu_struct *vpmu)
 {
     unsigned int i, pmc_start;
@@ -708,13 +724,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) )
@@ -787,6 +803,7 @@ struct arch_vpmu_ops core2_vpmu_ops = {
     .arch_vpmu_destroy = core2_vpmu_destroy,
     .arch_vpmu_save = core2_vpmu_save,
     .arch_vpmu_load = core2_vpmu_load,
+    .arch_vpmu_unload = core2_vpmu_unload,
     .arch_vpmu_dump = core2_vpmu_dump
 };
 
@@ -829,7 +846,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 +854,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 +897,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 0a2e1a7..4373b03 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;
@@ -243,11 +255,11 @@ void vpmu_initialise(struct vcpu *v)
     switch ( vendor )
     {
     case X86_VENDOR_AMD:
-        ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
+        ret = svm_vpmu_initialise(v);
         break;
 
     case X86_VENDOR_INTEL:
-        ret = vmx_vpmu_initialise(v, opt_vpmu_enabled);
+        ret = vmx_vpmu_initialise(v);
         break;
 
     default:
@@ -277,3 +289,163 @@ void vpmu_dump(struct vcpu *v)
         vpmu->arch_vpmu_ops->arch_vpmu_dump(v);
 }
 
+void vpmu_unload(struct vpmu_struct *vpmu)
+{
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_RUNNING) )
+        return;
+
+    if (vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_unload)
+        vpmu->arch_vpmu_ops->arch_vpmu_unload(vpmu);
+
+    vpmu_reset(vpmu, VPMU_RUNNING | VPMU_RUNNING);
+}
+
+static cpumask_t vpmu_cpumask_unload;
+
+static long vpmu_unload_next(void *arg)
+{
+    struct vcpu *last;
+
+    local_irq_disable(); /* so that last_vcpu doesn't change under us. */
+
+    last = this_cpu(last_vcpu);
+    if ( last )
+    {
+        vpmu_unload(vcpu_vpmu(last));
+        this_cpu(last_vcpu) = NULL;
+    }
+
+    local_irq_enable();
+
+    cpumask_and(&vpmu_cpumask_unload, &vpmu_cpumask_unload, &cpu_online_map);
+    if ( cpumask_weight(&vpmu_cpumask_unload) > 1 )
+    {
+        int ret;
+        int cpu = cpumask_cycle(smp_processor_id(), &vpmu_cpumask_unload);
+
+        cpumask_clear_cpu(smp_processor_id(), &vpmu_cpumask_unload);
+
+        ret = continue_hypercall_on_cpu(cpu, vpmu_unload_next, arg);
+        if ( ret )
+        {
+            vpmu_mode = (unsigned long)arg;
+            cpumask_clear(&vpmu_cpumask_unload);
+            return ret;
+        }
+    }
+    else
+        cpumask_clear(&vpmu_cpumask_unload);
+
+    return 0;
+}
+
+static int vpmu_unload_all(unsigned long old_mode)
+{
+    int ret = 0;
+
+    vpmu_unload(vcpu_vpmu(current));
+
+    if ( nr_cpu_ids > 1 )
+    {
+        unsigned int cpu;
+
+        cpumask_or(&vpmu_cpumask_unload, &vpmu_cpumask_unload, &cpu_online_map);
+        cpu = cpumask_cycle(smp_processor_id(), &vpmu_cpumask_unload);
+
+        ret = continue_hypercall_on_cpu(cpu, vpmu_unload_next,
+                                        (void *)old_mode);
+        if ( ret )
+            cpumask_clear(&vpmu_cpumask_unload);
+    }
+
+    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:
+    {
+        unsigned int 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 ( !cpumask_empty(&vpmu_cpumask_unload) )
+        {
+            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. */
+            ret = vpmu_unload_all(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/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c
index 13534d4..3c3a37c 100644
--- a/xen/arch/x86/oprofile/nmi_int.c
+++ b/xen/arch/x86/oprofile/nmi_int.c
@@ -47,7 +47,8 @@ static int passive_domain_msr_op_checks(unsigned int msr, int *typep, int *index
 	if ( !model->is_arch_pmu_msr(msr, typep, indexp) )
 		return 0;
 
-	if ( !vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) )
+	if ( !vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED |
+                               VPMU_CONTEXT_ALLOCATED) )
 		if ( ! model->allocated_msr(current) )
 			return 0;
 	return 1;
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/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 949884b..5407379 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -489,7 +489,7 @@ extern const unsigned int vmx_introspection_force_enabled_msrs_size;
 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_write_guest_msr_vcpu(struct vcpu *v, u32 msr, u64 val);
 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);
@@ -509,6 +509,11 @@ static inline int vmx_add_host_load_msr(u32 msr)
     return vmx_add_msr(msr, VMX_HOST_MSR);
 }
 
+static inline int vmx_write_guest_msr(u32 msr, u64 val)
+{
+    return vmx_write_guest_msr_vcpu(current, msr, val);
+}
+
 DECLARE_PER_CPU(bool_t, vmxon);
 
 #endif /* ASM_X86_HVM_VMX_VMCS_H__ */
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 897d5de..1171b2a 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)
 
@@ -65,11 +58,12 @@ struct arch_vpmu_ops {
     void (*arch_vpmu_destroy)(struct vcpu *v);
     int (*arch_vpmu_save)(struct vpmu_struct *vpmu);
     void (*arch_vpmu_load)(struct vpmu_struct *vpmu);
+    void (*arch_vpmu_unload)(struct vpmu_struct *vpmu);
     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 *);
 
 /* VPMU states */
 #define VPMU_CONTEXT_ALLOCATED              0x1
@@ -111,10 +105,31 @@ void vpmu_initialise(struct vcpu *v);
 void vpmu_destroy(struct vcpu *v);
 void vpmu_save(struct vpmu_struct *vpmu);
 void vpmu_load(struct vpmu_struct *vpmu);
+void vpmu_unload(struct vpmu_struct *vpmu);
 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 */
+static inline void vpmu_switch_from(struct vpmu_struct *prev,
+                                    struct vpmu_struct *next)
+{
+    if ( vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+        vpmu_save(prev);
+}
+
+static inline void vpmu_switch_to(struct vpmu_struct *prev,
+                                  struct vpmu_struct *next)
+{
+    if ( vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+        vpmu_load(next);
+    else if ( vpmu_is_set(next, VPMU_CONTEXT_LOADED | VPMU_RUNNING) )
+        vpmu_unload(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 b6bef8c..f6f02e1 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -107,6 +107,7 @@
 ?	pmu_cntr_pair			arch-x86/pmu.h
 ?	pmu_intel_ctxt			arch-x86/pmu.h
 ?	pmu_regs			arch-x86/pmu.h
+?	pmu_params			pmu.h
 ?	flask_access			xsm/flask_op.h
 !	flask_boolean			xsm/flask_op.h
 ?	flask_cache_stats		xsm/flask_op.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 c589e49..a24c480 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1504,6 +1504,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);
@@ -1626,6 +1643,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 ed91c09..4786a39 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrF-0002sI-L5; Wed, 17 Dec 2014 15:49:49 +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 1Y1GrD-0002oN-Uz
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:48 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	63/0B-09284-B16A1945; Wed, 17 Dec 2014 15:49:47 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418831384!14016715!1
X-Originating-IP: [156.151.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 12289 invoked from network); 17 Dec 2014 15:49:46 -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; 17 Dec 2014 15:49: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 sBHFnbQi030382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:38 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
	sBHFnaAl020630
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:37 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
	sBHFna3T019235; Wed, 17 Dec 2014 15:49:36 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 ; Wed, 17 Dec 2014 07:49:36 -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: Wed, 17 Dec 2014 10:38:49 -0500
Message-Id: <1418830734-1558-19-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 18/23] 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. If vpmu ops
for VCPU are not initialized (which is the case, for example, for PV guests that
are not "VPMU-enlightened") access to MSRs will return failure.

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 | 53 +++++++++++++++++++++++++++++++--------
 xen/arch/x86/hvm/vpmu.c           |  4 +--
 xen/arch/x86/traps.c              | 50 +++++++++++++++++++++++++++++++++++-
 4 files changed, 95 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7d5d46b..db6e6ef 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2081,8 +2081,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 28fabf9..8e6386e 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,19 +300,23 @@ static inline void __core2_vpmu_save(struct vpmu_struct *vpmu)
         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(vpmu_vcpu(vpmu)) )
+        rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
 }
 
 static int core2_vpmu_save(struct vpmu_struct *vpmu)
 {
-    struct vcpu *v;
+    struct vcpu *v = vpmu_vcpu(vpmu);
+
+    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;
 
     __core2_vpmu_save(vpmu);
 
-    v = vpmu_vcpu(vpmu);
-
     /* Unset PMU MSR bitmap to trap lazy load. */
     if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
          has_hvm_container_vcpu(v) && cpu_has_vmx_msr_bitmap )
@@ -360,6 +365,13 @@ static inline void __core2_vpmu_load(struct vpmu_struct *vpmu)
     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(vpmu_vcpu(vpmu)) )
+    {
+        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 vpmu_struct *vpmu)
@@ -458,7 +470,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;
@@ -502,7 +513,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: "
@@ -530,14 +546,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 )
         {
@@ -562,7 +582,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;
@@ -576,9 +600,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);
@@ -605,7 +635,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/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 6503556..510b688 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -95,7 +95,7 @@ int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
         return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
-    return 0;
+    return 1;
 }
 
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
@@ -107,7 +107,7 @@ int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
         return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
-    return 0;
+    return 1;
 }
 
 void vpmu_do_interrupt(struct cpu_user_regs *regs)
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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gqy-0002Ya-KD; Wed, 17 Dec 2014 15:49: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 1Y1Gqx-0002YV-3D
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:31 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	29/9E-25276-A06A1945; Wed, 17 Dec 2014 15:49:30 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418831368!16306310!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8970 invoked from network); 17 Dec 2014 15:49:29 -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; 17 Dec 2014 15:49:29 -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 sBHFnLnT019574
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:22 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
	sBHFnKJW019710
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:21 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
	sBHFnKpP018418; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:32 -0500
Message-Id: <1418830734-1558-2-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 01/23] 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 d48463f..c589e49 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1410,6 +1410,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 1da9f63..ed91c09 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr5-0002eB-ND; Wed, 17 Dec 2014 15:49:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Y1Gr4-0002bm-BZ
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:38 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	FE/B5-27584-116A1945; Wed, 17 Dec 2014 15:49:37 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418831375!13913785!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13565 invoked from network); 17 Dec 2014 15:49:36 -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 Dec 2014 15:49:36 -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 sBHFnTkF019690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:30 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
	sBHFnS4B018651
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:29 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
	sBHFnSXj020063; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:40 -0500
Message-Id: <1418830734-1558-10-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 09/23] 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrE-0002qE-Mq; Wed, 17 Dec 2014 15:49:48 +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 1Y1GrC-0002lI-03
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:46 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	64/3C-14214-916A1945; Wed, 17 Dec 2014 15:49:45 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418831383!8516988!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6718 invoked from network); 17 Dec 2014 15:49: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; 17 Dec 2014 15:49: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 sBHFnais019832
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49: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
	sBHFnab5019204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:36 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
	sBHFnZkZ019188; Wed, 17 Dec 2014 15:49:35 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 ; Wed, 17 Dec 2014 07:49:35 -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: Wed, 17 Dec 2014 10:38:48 -0500
Message-Id: <1418830734-1558-18-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 17/23] 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 59cca08..a8cb9ae 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1709,7 +1709,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:
@@ -1860,7 +1861,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 bd6fc8e..7df246c 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -324,7 +324,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) )
@@ -354,7 +354,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)
@@ -372,7 +372,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 07d775d..28fabf9 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -479,36 +479,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) )
         {
@@ -517,18 +522,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 )
@@ -551,6 +559,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) )
@@ -562,45 +573,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)
@@ -628,19 +611,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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr4-0002cy-VH; Wed, 17 Dec 2014 15:49: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 1Y1Gr3-0002bK-TL
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:38 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	15/2D-02699-116A1945; Wed, 17 Dec 2014 15:49:37 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418831374!10284613!1
X-Originating-IP: [156.151.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 14121 invoked from network); 17 Dec 2014 15:49:36 -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; 17 Dec 2014 15:49:36 -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 sBHFnRXm030232
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:28 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
	sBHFnQT0018712
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:27 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
	sBHFnQPU019980; Wed, 17 Dec 2014 15:49:26 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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:38 -0500
Message-Id: <1418830734-1558-8-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 07/23] 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 Wed Dec 17 15:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gr2-0002ap-Th; Wed, 17 Dec 2014 15:49:36 +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 1Y1Gr1-0002Z7-Kf
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:35 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	A5/1D-02699-E06A1945; Wed, 17 Dec 2014 15:49:34 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418831372!11072522!1
X-Originating-IP: [156.151.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 25632 invoked from network); 17 Dec 2014 15:49:34 -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; 17 Dec 2014 15:49: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 sBHFnO0c030187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:25 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
	sBHFnNCT018547
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:24 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
	sBHFnMEb018426; Wed, 17 Dec 2014 15:49:22 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 ; Wed, 17 Dec 2014 07:49:22 -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: Wed, 17 Dec 2014 10:38:34 -0500
Message-Id: <1418830734-1558-4-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 03/23] 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 b43ea80..9c4a297 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 Wed Dec 17 15:49:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrH-0002xb-Bl; Wed, 17 Dec 2014 15:49:51 +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 1Y1GrF-0002qA-26
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:49 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	61/E0-02696-C16A1945; Wed, 17 Dec 2014 15:49:48 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418831386!15720740!1
X-Originating-IP: [156.151.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 29202 invoked from network); 17 Dec 2014 15:49:47 -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; 17 Dec 2014 15:49:47 -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 sBHFneop030408
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:40 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
	sBHFndT7008885
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Dec 2014 15:49:40 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
	sBHFncib008843; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49:38 -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: Wed, 17 Dec 2014 10:38:51 -0500
Message-Id: <1418830734-1558-21-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 20/23] 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, 38 insertions(+), 45 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 025ce1a..df03892 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -91,59 +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 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;
 
+    curr = current;
     vpmu = vcpu_vpmu(curr);
-    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
+    ops = vpmu->arch_vpmu_ops;
+    if ( !ops )
+        return 1;
+
+    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_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(vpmu);
-            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-        }
-        return ret;
+        vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+        ops->arch_vpmu_save(vpmu);
+        vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
     }
-    return 1;
-}
-
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
-{
-    struct vcpu *curr = current;
-    struct vpmu_struct *vpmu;
 
-    if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
-        return 0;
-
-    vpmu = vcpu_vpmu(curr);
-    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
-    {
-        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(vpmu);
-            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-        }
-        return ret;
-    }
-    return 1;
+    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 42a09f9..2c888cc 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -100,8 +100,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);
@@ -112,6 +112,16 @@ void vpmu_load(struct vpmu_struct *vpmu);
 void vpmu_unload(struct vpmu_struct *vpmu);
 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 Wed Dec 17 15:49:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrH-0002xb-Bl; Wed, 17 Dec 2014 15:49:51 +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 1Y1GrF-0002qA-26
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:49 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	61/E0-02696-C16A1945; Wed, 17 Dec 2014 15:49:48 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418831386!15720740!1
X-Originating-IP: [156.151.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 29202 invoked from network); 17 Dec 2014 15:49:47 -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; 17 Dec 2014 15:49:47 -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 sBHFneop030408
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:40 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
	sBHFndT7008885
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Dec 2014 15:49:40 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
	sBHFncib008843; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49:38 -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: Wed, 17 Dec 2014 10:38:51 -0500
Message-Id: <1418830734-1558-21-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 20/23] 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, 38 insertions(+), 45 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 025ce1a..df03892 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -91,59 +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 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;
 
+    curr = current;
     vpmu = vcpu_vpmu(curr);
-    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
+    ops = vpmu->arch_vpmu_ops;
+    if ( !ops )
+        return 1;
+
+    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_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(vpmu);
-            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-        }
-        return ret;
+        vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+        ops->arch_vpmu_save(vpmu);
+        vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
     }
-    return 1;
-}
-
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
-{
-    struct vcpu *curr = current;
-    struct vpmu_struct *vpmu;
 
-    if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
-        return 0;
-
-    vpmu = vcpu_vpmu(curr);
-    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
-    {
-        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(vpmu);
-            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-        }
-        return ret;
-    }
-    return 1;
+    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 42a09f9..2c888cc 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -100,8 +100,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);
@@ -112,6 +112,16 @@ void vpmu_load(struct vpmu_struct *vpmu);
 void vpmu_unload(struct vpmu_struct *vpmu);
 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 Wed Dec 17 15:49:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrK-00033L-KC; Wed, 17 Dec 2014 15:49:54 +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 1Y1GrF-0002qB-4v
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:49 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	AB/EA-02697-C16A1945; Wed, 17 Dec 2014 15:49:48 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418831386!13965461!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19810 invoked from network); 17 Dec 2014 15:49:47 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 15:49: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 sBHFndb9019881
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:39 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
	sBHFnce6008825
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:38 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
	sBHFnbib019288; Wed, 17 Dec 2014 15:49:37 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 ; Wed, 17 Dec 2014 07:49:37 -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: Wed, 17 Dec 2014 10:38:50 -0500
Message-Id: <1418830734-1558-20-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 19/23] 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           | 207 ++++++++++++++++++++++++++++++++++++--
 xen/include/public/arch-x86/pmu.h |   6 ++
 xen/include/public/pmu.h          |   2 +
 xen/include/xsm/dummy.h           |   4 +-
 xen/xsm/flask/hooks.c             |   2 +
 6 files changed, 212 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 7df246c..9b70291 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -225,17 +225,12 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
     struct vcpu *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 510b688..025ce1a 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -80,46 +80,207 @@ 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;
 
     if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
         return 0;
 
+    vpmu = vcpu_vpmu(curr);
     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(vpmu);
+            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+        }
+        return ret;
+    }
     return 1;
 }
 
 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;
 
     if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
         return 0;
 
+    vpmu = vcpu_vpmu(curr);
     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(vpmu);
+            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+        }
+        return ret;
+    }
     return 1;
 }
 
+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(vpmu);
+        vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+
+        if ( has_hvm_container_vcpu(sampled) )
+            *flags = 0;
+        else
+            *flags = PMU_SAMPLE_PV;
+
+        /* 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;
+                r->cpl = seg.attr.fields.dpl;
+                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 +293,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;
         }
     }
@@ -225,7 +386,9 @@ void vpmu_load(struct vpmu_struct *vpmu)
     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(vpmu_vcpu(vpmu)) &&
+          (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED)) )
         return;
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
@@ -244,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);
@@ -445,7 +610,9 @@ static int vpmu_unload_all(unsigned long 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 )
@@ -536,6 +703,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(vcpu_vpmu(curr));
+        break;
+
     default:
         ret = -EINVAL;
     }
diff --git a/xen/include/public/arch-x86/pmu.h b/xen/include/public/arch-x86/pmu.h
index 8bbe341..74a91ac 100644
--- a/xen/include/public/arch-x86/pmu.h
+++ b/xen/include/public/arch-x86/pmu.h
@@ -51,6 +51,12 @@ 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 */
+#define PMU_SAMPLE_PV      (1<<3) /* Sample from a PV guest */
+
 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 e98715d..ced1468 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1519,6 +1519,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 Wed Dec 17 15:49:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GrK-00033L-KC; Wed, 17 Dec 2014 15:49:54 +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 1Y1GrF-0002qB-4v
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:49 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	AB/EA-02697-C16A1945; Wed, 17 Dec 2014 15:49:48 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418831386!13965461!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19810 invoked from network); 17 Dec 2014 15:49:47 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 15:49: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 sBHFndb9019881
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:39 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
	sBHFnce6008825
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:38 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
	sBHFnbib019288; Wed, 17 Dec 2014 15:49:37 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 ; Wed, 17 Dec 2014 07:49:37 -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: Wed, 17 Dec 2014 10:38:50 -0500
Message-Id: <1418830734-1558-20-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 19/23] 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           | 207 ++++++++++++++++++++++++++++++++++++--
 xen/include/public/arch-x86/pmu.h |   6 ++
 xen/include/public/pmu.h          |   2 +
 xen/include/xsm/dummy.h           |   4 +-
 xen/xsm/flask/hooks.c             |   2 +
 6 files changed, 212 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 7df246c..9b70291 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -225,17 +225,12 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
     struct vcpu *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 510b688..025ce1a 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -80,46 +80,207 @@ 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;
 
     if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
         return 0;
 
+    vpmu = vcpu_vpmu(curr);
     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(vpmu);
+            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+        }
+        return ret;
+    }
     return 1;
 }
 
 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;
 
     if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
         return 0;
 
+    vpmu = vcpu_vpmu(curr);
     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(vpmu);
+            vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+        }
+        return ret;
+    }
     return 1;
 }
 
+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(vpmu);
+        vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+
+        if ( has_hvm_container_vcpu(sampled) )
+            *flags = 0;
+        else
+            *flags = PMU_SAMPLE_PV;
+
+        /* 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;
+                r->cpl = seg.attr.fields.dpl;
+                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 +293,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;
         }
     }
@@ -225,7 +386,9 @@ void vpmu_load(struct vpmu_struct *vpmu)
     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(vpmu_vcpu(vpmu)) &&
+          (vpmu->xenpmu_data->pmu.pmu_flags & PMU_CACHED)) )
         return;
 
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
@@ -244,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);
@@ -445,7 +610,9 @@ static int vpmu_unload_all(unsigned long 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 )
@@ -536,6 +703,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(vcpu_vpmu(curr));
+        break;
+
     default:
         ret = -EINVAL;
     }
diff --git a/xen/include/public/arch-x86/pmu.h b/xen/include/public/arch-x86/pmu.h
index 8bbe341..74a91ac 100644
--- a/xen/include/public/arch-x86/pmu.h
+++ b/xen/include/public/arch-x86/pmu.h
@@ -51,6 +51,12 @@ 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 */
+#define PMU_SAMPLE_PV      (1<<3) /* Sample from a PV guest */
+
 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 e98715d..ced1468 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1519,6 +1519,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 Wed Dec 17 15:49:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1GrM-00036R-Ef; Wed, 17 Dec 2014 15:49: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 1Y1GrG-0002s4-1x
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:50 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	81/C5-17694-D16A1945; Wed, 17 Dec 2014 15:49:49 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418831387!10372700!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27364 invoked from network); 17 Dec 2014 15:49:48 -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; 17 Dec 2014 15:49: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 sBHFnW47019731
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:33 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
	sBHFnVPI008566
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49: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
	sBHFnVhB020245; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:43 -0500
Message-Id: <1418830734-1558-13-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 12/23] x86/VPMU: Replace vcpu with vpmu as
	argument to some 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

A subsequent patch will add an inline routine to vpmu.h that will call vpmu_load().
This inline will try to access vcpu->vpmu which is not possible since struct
vcpu may not be fully defined at that point. So we will have that inline pass
vpmu pointer to vpmu_load() instead.

This change slightly simplifies some of vpmu code.

For symmetry also modify vpmu_save() (and vpmu_save_force()) to use vpmu
instead of vcpu.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/domain.c             |  4 ++--
 xen/arch/x86/hvm/svm/vpmu.c       | 23 +++++++++++------------
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 24 ++++++++++++------------
 xen/arch/x86/hvm/vpmu.c           | 31 +++++++++++++------------------
 xen/include/asm-x86/hvm/vpmu.h    | 26 +++++++++++++-------------
 5 files changed, 51 insertions(+), 57 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 11c7d9f..4e45fa8 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_save(vcpu_vpmu(prev));
 
         if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
             pt_save_timer(prev);
@@ -1589,7 +1589,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 
     if (is_hvm_vcpu(next) && (prev != next) )
         /* Must be done with interrupts enabled */
-        vpmu_load(next);
+        vpmu_load(vcpu_vpmu(next));
 
     context_saved(prev);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 0d30b37..bbe2733 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -173,10 +173,9 @@ static int amd_vpmu_do_interrupt(struct cpu_user_regs *regs)
     return 1;
 }
 
-static inline void context_load(struct vcpu *v)
+static inline void context_load(struct vpmu_struct *vpmu)
 {
     unsigned int i;
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
     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);
@@ -188,9 +187,8 @@ static inline void context_load(struct vcpu *v)
     }
 }
 
-static void amd_vpmu_load(struct vcpu *v)
+static void amd_vpmu_load(struct vpmu_struct *vpmu)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
     uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
@@ -208,13 +206,12 @@ static void amd_vpmu_load(struct vcpu *v)
 
     vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 
-    context_load(v);
+    context_load(vpmu);
 }
 
-static inline void context_save(struct vcpu *v)
+static inline void context_save(struct vpmu_struct *vpmu)
 {
     unsigned int i;
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
     uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
 
@@ -223,9 +220,9 @@ static inline void context_save(struct vcpu *v)
         rdmsrl(counters[i], counter_regs[i]);
 }
 
-static int amd_vpmu_save(struct vcpu *v)
+static int amd_vpmu_save(struct vpmu_struct *vpmu)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    struct vcpu *v;
     unsigned int i;
 
     /*
@@ -245,7 +242,9 @@ static int amd_vpmu_save(struct vcpu *v)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
         return 0;
 
-    context_save(v);
+    context_save(vpmu);
+
+    v = vpmu_vcpu(vpmu);
 
     if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
          has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
@@ -325,7 +324,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)
         || vpmu_is_set(vpmu, VPMU_FROZEN) )
     {
-        context_load(v);
+        context_load(vpmu);
         vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
         vpmu_reset(vpmu, VPMU_FROZEN);
     }
@@ -346,7 +345,7 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)
         || vpmu_is_set(vpmu, VPMU_FROZEN) )
     {
-        context_load(v);
+        context_load(vpmu);
         vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
         vpmu_reset(vpmu, VPMU_FROZEN);
     }
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index a6cca38..1b2d048 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -287,10 +287,10 @@ static void core2_vpmu_unset_msr_bitmap(unsigned long *msr_bitmap)
     set_bit(msraddr_to_bitpos(MSR_IA32_DS_AREA), msr_bitmap);
 }
 
-static inline void __core2_vpmu_save(struct vcpu *v)
+static inline void __core2_vpmu_save(struct vpmu_struct *vpmu)
 {
     int i;
-    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vpmu->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);
@@ -301,14 +301,16 @@ static inline void __core2_vpmu_save(struct vcpu *v)
         rdmsrl(MSR_IA32_PERFCTR0 + i, xen_pmu_cntr_pair[i].counter);
 }
 
-static int core2_vpmu_save(struct vcpu *v)
+static int core2_vpmu_save(struct vpmu_struct *vpmu)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    struct vcpu *v;
 
     if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED) )
         return 0;
 
-    __core2_vpmu_save(v);
+    __core2_vpmu_save(vpmu);
+
+    v = vpmu_vcpu(vpmu);
 
     /* Unset PMU MSR bitmap to trap lazy load. */
     if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
@@ -318,10 +320,10 @@ static int core2_vpmu_save(struct vcpu *v)
     return 1;
 }
 
-static inline void __core2_vpmu_load(struct vcpu *v)
+static inline void __core2_vpmu_load(struct vpmu_struct *vpmu)
 {
     unsigned int i, pmc_start;
-    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vpmu->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);
@@ -344,16 +346,14 @@ static inline void __core2_vpmu_load(struct vcpu *v)
     wrmsrl(MSR_IA32_PEBS_ENABLE, core2_vpmu_cxt->pebs_enable);
 }
 
-static void core2_vpmu_load(struct vcpu *v)
+static void core2_vpmu_load(struct vpmu_struct *vpmu)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
-
     if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
         return;
 
     vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 
-    __core2_vpmu_load(v);
+    __core2_vpmu_load(vpmu);
 }
 
 static int core2_vpmu_alloc_resource(struct vcpu *v)
@@ -418,7 +418,7 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int *type, int *index)
     /* Do the lazy load staff. */
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
     {
-        __core2_vpmu_load(current);
+        __core2_vpmu_load(vpmu);
         vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
         if ( has_hvm_container_vcpu(current) &&
              cpu_has_vmx_msr_bitmap )
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 9f37bba..0a2e1a7 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -137,8 +137,7 @@ void vpmu_do_cpuid(unsigned int input,
 
 static void vpmu_save_force(void *arg)
 {
-    struct vcpu *v = (struct vcpu *)arg;
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    struct vpmu_struct *vpmu = (struct vpmu_struct *)arg;
 
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
         return;
@@ -146,36 +145,34 @@ static void vpmu_save_force(void *arg)
     vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
 
     if ( vpmu->arch_vpmu_ops )
-        (void)vpmu->arch_vpmu_ops->arch_vpmu_save(v);
+        (void)vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu);
 
     vpmu_reset(vpmu, VPMU_CONTEXT_SAVE);
 
     per_cpu(last_vcpu, smp_processor_id()) = NULL;
 }
 
-void vpmu_save(struct vcpu *v)
+void vpmu_save(struct vpmu_struct *vpmu)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
     int pcpu = smp_processor_id();
 
     if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_ALLOCATED | VPMU_CONTEXT_LOADED) )
        return;
 
     vpmu->last_pcpu = pcpu;
-    per_cpu(last_vcpu, pcpu) = v;
+    per_cpu(last_vcpu, pcpu) = vpmu_vcpu(vpmu);
 
     if ( vpmu->arch_vpmu_ops )
-        if ( vpmu->arch_vpmu_ops->arch_vpmu_save(v) )
+        if ( vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu) )
             vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
 
     apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
 }
 
-void vpmu_load(struct vcpu *v)
+void vpmu_load(struct vpmu_struct *vpmu)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
     int pcpu = smp_processor_id();
-    struct vcpu *prev = NULL;
+    struct vcpu *prev;
 
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
@@ -193,7 +190,7 @@ void vpmu_load(struct vcpu *v)
         if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
         {
             on_selected_cpus(cpumask_of(vpmu->last_pcpu),
-                             vpmu_save_force, (void *)v, 1);
+                             vpmu_save_force, (void *)vpmu, 1);
             vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
         }
     } 
@@ -203,15 +200,13 @@ void vpmu_load(struct vcpu *v)
 
     prev = per_cpu(last_vcpu, pcpu);
 
-    if ( prev != v && prev )
+    if ( (prev != vpmu_vcpu(vpmu)) && prev )
     {
-        vpmu = vcpu_vpmu(prev);
+        struct vpmu_struct *vpmu_prev = vcpu_vpmu(prev);
 
         /* Someone ran here before us */
-        vpmu_save_force(prev);
-        vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
-
-        vpmu = vcpu_vpmu(v);
+        vpmu_save_force(vpmu_prev);
+        vpmu_reset(vpmu_prev, VPMU_CONTEXT_LOADED);
     }
 
     local_irq_enable();
@@ -224,7 +219,7 @@ void vpmu_load(struct vcpu *v)
     {
         apic_write_around(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
         /* Arch code needs to set VPMU_CONTEXT_LOADED */
-        vpmu->arch_vpmu_ops->arch_vpmu_load(v);
+        vpmu->arch_vpmu_ops->arch_vpmu_load(vpmu);
     }
 }
 
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 82bfa0e..897d5de 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -44,6 +44,15 @@
 #define vpmu_reg_pointer(ctxt, offset) ((void *)((uintptr_t)ctxt + \
                                                  (uintptr_t)ctxt->offset))
 
+struct vpmu_struct {
+    u32 flags;
+    u32 last_pcpu;
+    u32 hw_lapic_lvtpc;
+    void *context;      /* May be shared with PV guest */
+    void *priv_context; /* hypervisor-only */
+    struct arch_vpmu_ops *arch_vpmu_ops;
+};
+
 /* Arch specific operations shared by all vpmus */
 struct arch_vpmu_ops {
     int (*do_wrmsr)(unsigned int msr, uint64_t msr_content,
@@ -54,23 +63,14 @@ struct arch_vpmu_ops {
                      unsigned int *eax, unsigned int *ebx,
                      unsigned int *ecx, unsigned int *edx);
     void (*arch_vpmu_destroy)(struct vcpu *v);
-    int (*arch_vpmu_save)(struct vcpu *v);
-    void (*arch_vpmu_load)(struct vcpu *v);
+    int (*arch_vpmu_save)(struct vpmu_struct *vpmu);
+    void (*arch_vpmu_load)(struct vpmu_struct *vpmu);
     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);
 
-struct vpmu_struct {
-    u32 flags;
-    u32 last_pcpu;
-    u32 hw_lapic_lvtpc;
-    void *context;      /* May be shared with PV guest */
-    void *priv_context; /* hypervisor-only */
-    struct arch_vpmu_ops *arch_vpmu_ops;
-};
-
 /* VPMU states */
 #define VPMU_CONTEXT_ALLOCATED              0x1
 #define VPMU_CONTEXT_LOADED                 0x2
@@ -109,8 +109,8 @@ void vpmu_do_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
                                        unsigned int *ecx, unsigned int *edx);
 void vpmu_initialise(struct vcpu *v);
 void vpmu_destroy(struct vcpu *v);
-void vpmu_save(struct vcpu *v);
-void vpmu_load(struct vcpu *v);
+void vpmu_save(struct vpmu_struct *vpmu);
+void vpmu_load(struct vpmu_struct *vpmu);
 void vpmu_dump(struct vcpu *v);
 
 extern int acquire_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 Wed Dec 17 15:49:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1GrM-00036R-Ef; Wed, 17 Dec 2014 15:49: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 1Y1GrG-0002s4-1x
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:50 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	81/C5-17694-D16A1945; Wed, 17 Dec 2014 15:49:49 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418831387!10372700!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27364 invoked from network); 17 Dec 2014 15:49:48 -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; 17 Dec 2014 15:49: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 sBHFnW47019731
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:33 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
	sBHFnVPI008566
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49: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
	sBHFnVhB020245; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49: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: Wed, 17 Dec 2014 10:38:43 -0500
Message-Id: <1418830734-1558-13-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 12/23] x86/VPMU: Replace vcpu with vpmu as
	argument to some 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

A subsequent patch will add an inline routine to vpmu.h that will call vpmu_load().
This inline will try to access vcpu->vpmu which is not possible since struct
vcpu may not be fully defined at that point. So we will have that inline pass
vpmu pointer to vpmu_load() instead.

This change slightly simplifies some of vpmu code.

For symmetry also modify vpmu_save() (and vpmu_save_force()) to use vpmu
instead of vcpu.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/domain.c             |  4 ++--
 xen/arch/x86/hvm/svm/vpmu.c       | 23 +++++++++++------------
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 24 ++++++++++++------------
 xen/arch/x86/hvm/vpmu.c           | 31 +++++++++++++------------------
 xen/include/asm-x86/hvm/vpmu.h    | 26 +++++++++++++-------------
 5 files changed, 51 insertions(+), 57 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 11c7d9f..4e45fa8 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_save(vcpu_vpmu(prev));
 
         if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
             pt_save_timer(prev);
@@ -1589,7 +1589,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 
     if (is_hvm_vcpu(next) && (prev != next) )
         /* Must be done with interrupts enabled */
-        vpmu_load(next);
+        vpmu_load(vcpu_vpmu(next));
 
     context_saved(prev);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 0d30b37..bbe2733 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -173,10 +173,9 @@ static int amd_vpmu_do_interrupt(struct cpu_user_regs *regs)
     return 1;
 }
 
-static inline void context_load(struct vcpu *v)
+static inline void context_load(struct vpmu_struct *vpmu)
 {
     unsigned int i;
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
     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);
@@ -188,9 +187,8 @@ static inline void context_load(struct vcpu *v)
     }
 }
 
-static void amd_vpmu_load(struct vcpu *v)
+static void amd_vpmu_load(struct vpmu_struct *vpmu)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
     uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
@@ -208,13 +206,12 @@ static void amd_vpmu_load(struct vcpu *v)
 
     vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 
-    context_load(v);
+    context_load(vpmu);
 }
 
-static inline void context_save(struct vcpu *v)
+static inline void context_save(struct vpmu_struct *vpmu)
 {
     unsigned int i;
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
     uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
 
@@ -223,9 +220,9 @@ static inline void context_save(struct vcpu *v)
         rdmsrl(counters[i], counter_regs[i]);
 }
 
-static int amd_vpmu_save(struct vcpu *v)
+static int amd_vpmu_save(struct vpmu_struct *vpmu)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    struct vcpu *v;
     unsigned int i;
 
     /*
@@ -245,7 +242,9 @@ static int amd_vpmu_save(struct vcpu *v)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
         return 0;
 
-    context_save(v);
+    context_save(vpmu);
+
+    v = vpmu_vcpu(vpmu);
 
     if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
          has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
@@ -325,7 +324,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)
         || vpmu_is_set(vpmu, VPMU_FROZEN) )
     {
-        context_load(v);
+        context_load(vpmu);
         vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
         vpmu_reset(vpmu, VPMU_FROZEN);
     }
@@ -346,7 +345,7 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)
         || vpmu_is_set(vpmu, VPMU_FROZEN) )
     {
-        context_load(v);
+        context_load(vpmu);
         vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
         vpmu_reset(vpmu, VPMU_FROZEN);
     }
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index a6cca38..1b2d048 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -287,10 +287,10 @@ static void core2_vpmu_unset_msr_bitmap(unsigned long *msr_bitmap)
     set_bit(msraddr_to_bitpos(MSR_IA32_DS_AREA), msr_bitmap);
 }
 
-static inline void __core2_vpmu_save(struct vcpu *v)
+static inline void __core2_vpmu_save(struct vpmu_struct *vpmu)
 {
     int i;
-    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vpmu->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);
@@ -301,14 +301,16 @@ static inline void __core2_vpmu_save(struct vcpu *v)
         rdmsrl(MSR_IA32_PERFCTR0 + i, xen_pmu_cntr_pair[i].counter);
 }
 
-static int core2_vpmu_save(struct vcpu *v)
+static int core2_vpmu_save(struct vpmu_struct *vpmu)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    struct vcpu *v;
 
     if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED) )
         return 0;
 
-    __core2_vpmu_save(v);
+    __core2_vpmu_save(vpmu);
+
+    v = vpmu_vcpu(vpmu);
 
     /* Unset PMU MSR bitmap to trap lazy load. */
     if ( !vpmu_is_set(vpmu, VPMU_RUNNING) &&
@@ -318,10 +320,10 @@ static int core2_vpmu_save(struct vcpu *v)
     return 1;
 }
 
-static inline void __core2_vpmu_load(struct vcpu *v)
+static inline void __core2_vpmu_load(struct vpmu_struct *vpmu)
 {
     unsigned int i, pmc_start;
-    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vcpu_vpmu(v)->context;
+    struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vpmu->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);
@@ -344,16 +346,14 @@ static inline void __core2_vpmu_load(struct vcpu *v)
     wrmsrl(MSR_IA32_PEBS_ENABLE, core2_vpmu_cxt->pebs_enable);
 }
 
-static void core2_vpmu_load(struct vcpu *v)
+static void core2_vpmu_load(struct vpmu_struct *vpmu)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
-
     if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
         return;
 
     vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 
-    __core2_vpmu_load(v);
+    __core2_vpmu_load(vpmu);
 }
 
 static int core2_vpmu_alloc_resource(struct vcpu *v)
@@ -418,7 +418,7 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int *type, int *index)
     /* Do the lazy load staff. */
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
     {
-        __core2_vpmu_load(current);
+        __core2_vpmu_load(vpmu);
         vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
         if ( has_hvm_container_vcpu(current) &&
              cpu_has_vmx_msr_bitmap )
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 9f37bba..0a2e1a7 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -137,8 +137,7 @@ void vpmu_do_cpuid(unsigned int input,
 
 static void vpmu_save_force(void *arg)
 {
-    struct vcpu *v = (struct vcpu *)arg;
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    struct vpmu_struct *vpmu = (struct vpmu_struct *)arg;
 
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
         return;
@@ -146,36 +145,34 @@ static void vpmu_save_force(void *arg)
     vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
 
     if ( vpmu->arch_vpmu_ops )
-        (void)vpmu->arch_vpmu_ops->arch_vpmu_save(v);
+        (void)vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu);
 
     vpmu_reset(vpmu, VPMU_CONTEXT_SAVE);
 
     per_cpu(last_vcpu, smp_processor_id()) = NULL;
 }
 
-void vpmu_save(struct vcpu *v)
+void vpmu_save(struct vpmu_struct *vpmu)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
     int pcpu = smp_processor_id();
 
     if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_ALLOCATED | VPMU_CONTEXT_LOADED) )
        return;
 
     vpmu->last_pcpu = pcpu;
-    per_cpu(last_vcpu, pcpu) = v;
+    per_cpu(last_vcpu, pcpu) = vpmu_vcpu(vpmu);
 
     if ( vpmu->arch_vpmu_ops )
-        if ( vpmu->arch_vpmu_ops->arch_vpmu_save(v) )
+        if ( vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu) )
             vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
 
     apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
 }
 
-void vpmu_load(struct vcpu *v)
+void vpmu_load(struct vpmu_struct *vpmu)
 {
-    struct vpmu_struct *vpmu = vcpu_vpmu(v);
     int pcpu = smp_processor_id();
-    struct vcpu *prev = NULL;
+    struct vcpu *prev;
 
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
@@ -193,7 +190,7 @@ void vpmu_load(struct vcpu *v)
         if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
         {
             on_selected_cpus(cpumask_of(vpmu->last_pcpu),
-                             vpmu_save_force, (void *)v, 1);
+                             vpmu_save_force, (void *)vpmu, 1);
             vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
         }
     } 
@@ -203,15 +200,13 @@ void vpmu_load(struct vcpu *v)
 
     prev = per_cpu(last_vcpu, pcpu);
 
-    if ( prev != v && prev )
+    if ( (prev != vpmu_vcpu(vpmu)) && prev )
     {
-        vpmu = vcpu_vpmu(prev);
+        struct vpmu_struct *vpmu_prev = vcpu_vpmu(prev);
 
         /* Someone ran here before us */
-        vpmu_save_force(prev);
-        vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
-
-        vpmu = vcpu_vpmu(v);
+        vpmu_save_force(vpmu_prev);
+        vpmu_reset(vpmu_prev, VPMU_CONTEXT_LOADED);
     }
 
     local_irq_enable();
@@ -224,7 +219,7 @@ void vpmu_load(struct vcpu *v)
     {
         apic_write_around(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
         /* Arch code needs to set VPMU_CONTEXT_LOADED */
-        vpmu->arch_vpmu_ops->arch_vpmu_load(v);
+        vpmu->arch_vpmu_ops->arch_vpmu_load(vpmu);
     }
 }
 
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 82bfa0e..897d5de 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -44,6 +44,15 @@
 #define vpmu_reg_pointer(ctxt, offset) ((void *)((uintptr_t)ctxt + \
                                                  (uintptr_t)ctxt->offset))
 
+struct vpmu_struct {
+    u32 flags;
+    u32 last_pcpu;
+    u32 hw_lapic_lvtpc;
+    void *context;      /* May be shared with PV guest */
+    void *priv_context; /* hypervisor-only */
+    struct arch_vpmu_ops *arch_vpmu_ops;
+};
+
 /* Arch specific operations shared by all vpmus */
 struct arch_vpmu_ops {
     int (*do_wrmsr)(unsigned int msr, uint64_t msr_content,
@@ -54,23 +63,14 @@ struct arch_vpmu_ops {
                      unsigned int *eax, unsigned int *ebx,
                      unsigned int *ecx, unsigned int *edx);
     void (*arch_vpmu_destroy)(struct vcpu *v);
-    int (*arch_vpmu_save)(struct vcpu *v);
-    void (*arch_vpmu_load)(struct vcpu *v);
+    int (*arch_vpmu_save)(struct vpmu_struct *vpmu);
+    void (*arch_vpmu_load)(struct vpmu_struct *vpmu);
     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);
 
-struct vpmu_struct {
-    u32 flags;
-    u32 last_pcpu;
-    u32 hw_lapic_lvtpc;
-    void *context;      /* May be shared with PV guest */
-    void *priv_context; /* hypervisor-only */
-    struct arch_vpmu_ops *arch_vpmu_ops;
-};
-
 /* VPMU states */
 #define VPMU_CONTEXT_ALLOCATED              0x1
 #define VPMU_CONTEXT_LOADED                 0x2
@@ -109,8 +109,8 @@ void vpmu_do_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
                                        unsigned int *ecx, unsigned int *edx);
 void vpmu_initialise(struct vcpu *v);
 void vpmu_destroy(struct vcpu *v);
-void vpmu_save(struct vcpu *v);
-void vpmu_load(struct vcpu *v);
+void vpmu_save(struct vpmu_struct *vpmu);
+void vpmu_load(struct vpmu_struct *vpmu);
 void vpmu_dump(struct vcpu *v);
 
 extern int acquire_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 Wed Dec 17 15:50:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Grd-0003JR-Gl; Wed, 17 Dec 2014 15:50: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 1Y1GrH-0002w8-C0
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:51 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	63/6E-14727-E16A1945; Wed, 17 Dec 2014 15:49:50 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418831388!8629935!1
X-Originating-IP: [156.151.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 26105 invoked from network); 17 Dec 2014 15:49:49 -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 Dec 2014 15:49: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 sBHFnf7g030437
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:42 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
	sBHFne6t019379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:41 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
	sBHFndE7019086; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49:39 -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: Wed, 17 Dec 2014 10:38:52 -0500
Message-Id: <1418830734-1558-22-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 21/23] 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  | 43 +++++++++++++++++++++++++++++++------------
 xen/arch/x86/traps.c     | 12 ++++++++++++
 xen/include/public/pmu.h |  3 +++
 3 files changed, 46 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index df03892..dd3f5e0 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -94,15 +94,16 @@ 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)
 {
-    struct vcpu *curr;
+    struct vcpu *curr = current;
     struct vpmu_struct *vpmu;
     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;
     vpmu = vcpu_vpmu(curr);
     ops = vpmu->arch_vpmu_ops;
     if ( !ops )
@@ -144,8 +145,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 +160,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 +174,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;
 
@@ -182,6 +188,11 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
         else
             *flags = PMU_SAMPLE_PV;
 
+        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) )
@@ -210,7 +221,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;
@@ -440,7 +452,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) ||
@@ -520,6 +533,10 @@ void vpmu_dump(struct vcpu *v)
 
 void vpmu_unload(struct vpmu_struct *vpmu)
 {
+    if ( (vpmu_mode & XENPMU_MODE_ALL) &&
+         is_hardware_domain(vpmu_vcpu(vpmu)->domain) )
+        return;
+
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_RUNNING) )
         return;
 
@@ -611,11 +628,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;
 
         /*
@@ -634,7 +653,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. */
             ret = vpmu_unload_all(old_mode);
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 Wed Dec 17 15:50:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1Grf-0003M6-5V; Wed, 17 Dec 2014 15:50:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Y1GrI-0002zk-US
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:53 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	60/4E-26652-026A1945; Wed, 17 Dec 2014 15:49:52 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418831390!13965473!1
X-Originating-IP: [156.151.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 20069 invoked from network); 17 Dec 2014 15:49:51 -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; 17 Dec 2014 15:49: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 sBHFngWg030465
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:43 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
	sBHFnfEO020853
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:41 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
	sBHFnfvj020840; Wed, 17 Dec 2014 15:49:41 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 ; Wed, 17 Dec 2014 07:49:41 -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: Wed, 17 Dec 2014 10:38:54 -0500
Message-Id: <1418830734-1558-24-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 23/23] 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 74b30a8..779e3b8 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 97d545c..da62791 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 77f7795..43c741a 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 56b9d23..9ec5da1 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -33,12 +33,12 @@
 #include <asm/page.h>
 #include <asm/apic.h>
 #include <asm/io_apic.h>
+#include <asm/vpmu.h>
 #include <asm/hvm/hvm.h>
 #include <asm/hvm/io.h>
 #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>
 
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 5407379..a27dda5 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 Wed Dec 17 15:50:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Grd-0003JR-Gl; Wed, 17 Dec 2014 15:50: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 1Y1GrH-0002w8-C0
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:51 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	63/6E-14727-E16A1945; Wed, 17 Dec 2014 15:49:50 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418831388!8629935!1
X-Originating-IP: [156.151.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 26105 invoked from network); 17 Dec 2014 15:49:49 -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 Dec 2014 15:49: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 sBHFnf7g030437
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:42 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
	sBHFne6t019379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:41 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
	sBHFndE7019086; Wed, 17 Dec 2014 15:49: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 ; Wed, 17 Dec 2014 07:49:39 -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: Wed, 17 Dec 2014 10:38:52 -0500
Message-Id: <1418830734-1558-22-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 21/23] 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  | 43 +++++++++++++++++++++++++++++++------------
 xen/arch/x86/traps.c     | 12 ++++++++++++
 xen/include/public/pmu.h |  3 +++
 3 files changed, 46 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index df03892..dd3f5e0 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -94,15 +94,16 @@ 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)
 {
-    struct vcpu *curr;
+    struct vcpu *curr = current;
     struct vpmu_struct *vpmu;
     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;
     vpmu = vcpu_vpmu(curr);
     ops = vpmu->arch_vpmu_ops;
     if ( !ops )
@@ -144,8 +145,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 +160,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 +174,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;
 
@@ -182,6 +188,11 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
         else
             *flags = PMU_SAMPLE_PV;
 
+        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) )
@@ -210,7 +221,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;
@@ -440,7 +452,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) ||
@@ -520,6 +533,10 @@ void vpmu_dump(struct vcpu *v)
 
 void vpmu_unload(struct vpmu_struct *vpmu)
 {
+    if ( (vpmu_mode & XENPMU_MODE_ALL) &&
+         is_hardware_domain(vpmu_vcpu(vpmu)->domain) )
+        return;
+
     if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_RUNNING) )
         return;
 
@@ -611,11 +628,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;
 
         /*
@@ -634,7 +653,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. */
             ret = vpmu_unload_all(old_mode);
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 Wed Dec 17 15:50:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1Grf-0003M6-5V; Wed, 17 Dec 2014 15:50:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Y1GrI-0002zk-US
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:53 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	60/4E-26652-026A1945; Wed, 17 Dec 2014 15:49:52 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418831390!13965473!1
X-Originating-IP: [156.151.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 20069 invoked from network); 17 Dec 2014 15:49:51 -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; 17 Dec 2014 15:49: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 sBHFngWg030465
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:43 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
	sBHFnfEO020853
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:41 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
	sBHFnfvj020840; Wed, 17 Dec 2014 15:49:41 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 ; Wed, 17 Dec 2014 07:49:41 -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: Wed, 17 Dec 2014 10:38:54 -0500
Message-Id: <1418830734-1558-24-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 23/23] 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 74b30a8..779e3b8 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 97d545c..da62791 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 77f7795..43c741a 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 56b9d23..9ec5da1 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -33,12 +33,12 @@
 #include <asm/page.h>
 #include <asm/apic.h>
 #include <asm/io_apic.h>
+#include <asm/vpmu.h>
 #include <asm/hvm/hvm.h>
 #include <asm/hvm/io.h>
 #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>
 
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 5407379..a27dda5 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 Wed Dec 17 15:50:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:50:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Grl-0003PC-Pk; Wed, 17 Dec 2014 15:50:21 +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 1Y1GrK-00031m-4F
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:54 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	C2/65-17958-126A1945; Wed, 17 Dec 2014 15:49:53 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418831390!14120025!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12062 invoked from network); 17 Dec 2014 15:49:52 -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; 17 Dec 2014 15:49: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 sBHFnfH1019921
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:41 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
	sBHFneRP020797
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:41 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
	sBHFnecb019378; Wed, 17 Dec 2014 15:49:40 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 ; Wed, 17 Dec 2014 07:49:40 -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: Wed, 17 Dec 2014 10:38:53 -0500
Message-Id: <1418830734-1558-23-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 22/23] 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             | 226 ++++++++++++++++++++++++++++--------
 xen/include/asm-x86/hvm/vpmu.h      |   4 +-
 xen/include/asm-x86/softirq.h       |   3 +-
 6 files changed, 192 insertions(+), 55 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 311316a..3a82080 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1311,11 +1311,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. ...'
@@ -1327,6 +1327,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 9b70291..97d545c 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;
 }
@@ -220,6 +220,7 @@ static inline void context_save(struct vpmu_struct *vpmu)
         rdmsrl(counters[i], counter_regs[i]);
 }
 
+/* Must be NMI-safe */
 static int amd_vpmu_save(struct vpmu_struct *vpmu)
 {
     struct vcpu *v;
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 8e6386e..77f7795 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 vpmu_struct *vpmu)
         rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
 }
 
+/* Must be NMI-safe */
 static int core2_vpmu_save(struct vpmu_struct *vpmu)
 {
     struct vcpu *v = vpmu_vcpu(vpmu);
@@ -720,7 +721,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 dd3f5e0..74b30a8 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)
 {
@@ -140,7 +183,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;
@@ -154,7 +197,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
     {
         sampling = choose_hwdom_vcpu();
         if ( !sampling )
-            return;
+            return 0;
     }
     else
         sampling = sampled;
@@ -168,15 +211,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);
@@ -243,15 +286,20 @@ 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;
-                r->cpl = seg.attr.fields.dpl;
                 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;
+                    r->cpl = seg.attr.fields.dpl;
+                }
             }
         }
 
@@ -263,35 +311,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 vpmu_struct *vpmu)
@@ -335,7 +388,10 @@ void vpmu_save(struct vpmu_struct *vpmu)
         if ( vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu) )
             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 vpmu_struct *vpmu)
@@ -386,6 +442,9 @@ void vpmu_load(struct vpmu_struct *vpmu)
           (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);
@@ -409,7 +468,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 )
     {
@@ -445,6 +504,55 @@ 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;
+        r->cpl = seg.attr.fields.dpl; 
+    }
+
+    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;
@@ -740,6 +848,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:
@@ -756,7 +879,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 2c888cc..ed5dc8c 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -53,7 +53,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);
@@ -102,7 +102,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 ec787d6..fca110f 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -8,7 +8,8 @@
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
 #define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
 #define HVM_DPCI_SOFTIRQ       (NR_COMMON_SOFTIRQS + 5)
-#define NR_ARCH_SOFTIRQS       6
+#define PMU_SOFTIRQ            (NR_COMMON_SOFTIRQS + 6)
+#define NR_ARCH_SOFTIRQS       7
 
 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 Wed Dec 17 15:50:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:50:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Grl-0003PC-Pk; Wed, 17 Dec 2014 15:50:21 +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 1Y1GrK-00031m-4F
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:49:54 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	C2/65-17958-126A1945; Wed, 17 Dec 2014 15:49:53 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418831390!14120025!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12062 invoked from network); 17 Dec 2014 15:49:52 -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; 17 Dec 2014 15:49: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 sBHFnfH1019921
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 15:49:41 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
	sBHFneRP020797
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 15:49:41 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
	sBHFnecb019378; Wed, 17 Dec 2014 15:49:40 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 ; Wed, 17 Dec 2014 07:49:40 -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: Wed, 17 Dec 2014 10:38:53 -0500
Message-Id: <1418830734-1558-23-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.4
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, tim@xen.org,
	jun.nakajima@intel.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v16 22/23] 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             | 226 ++++++++++++++++++++++++++++--------
 xen/include/asm-x86/hvm/vpmu.h      |   4 +-
 xen/include/asm-x86/softirq.h       |   3 +-
 6 files changed, 192 insertions(+), 55 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 311316a..3a82080 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1311,11 +1311,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. ...'
@@ -1327,6 +1327,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 9b70291..97d545c 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;
 }
@@ -220,6 +220,7 @@ static inline void context_save(struct vpmu_struct *vpmu)
         rdmsrl(counters[i], counter_regs[i]);
 }
 
+/* Must be NMI-safe */
 static int amd_vpmu_save(struct vpmu_struct *vpmu)
 {
     struct vcpu *v;
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 8e6386e..77f7795 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 vpmu_struct *vpmu)
         rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
 }
 
+/* Must be NMI-safe */
 static int core2_vpmu_save(struct vpmu_struct *vpmu)
 {
     struct vcpu *v = vpmu_vcpu(vpmu);
@@ -720,7 +721,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 dd3f5e0..74b30a8 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)
 {
@@ -140,7 +183,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;
@@ -154,7 +197,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
     {
         sampling = choose_hwdom_vcpu();
         if ( !sampling )
-            return;
+            return 0;
     }
     else
         sampling = sampled;
@@ -168,15 +211,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);
@@ -243,15 +286,20 @@ 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;
-                r->cpl = seg.attr.fields.dpl;
                 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;
+                    r->cpl = seg.attr.fields.dpl;
+                }
             }
         }
 
@@ -263,35 +311,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 vpmu_struct *vpmu)
@@ -335,7 +388,10 @@ void vpmu_save(struct vpmu_struct *vpmu)
         if ( vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu) )
             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 vpmu_struct *vpmu)
@@ -386,6 +442,9 @@ void vpmu_load(struct vpmu_struct *vpmu)
           (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);
@@ -409,7 +468,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 )
     {
@@ -445,6 +504,55 @@ 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;
+        r->cpl = seg.attr.fields.dpl; 
+    }
+
+    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;
@@ -740,6 +848,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:
@@ -756,7 +879,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 2c888cc..ed5dc8c 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -53,7 +53,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);
@@ -102,7 +102,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 ec787d6..fca110f 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -8,7 +8,8 @@
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
 #define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
 #define HVM_DPCI_SOFTIRQ       (NR_COMMON_SOFTIRQS + 5)
-#define NR_ARCH_SOFTIRQS       6
+#define PMU_SOFTIRQ            (NR_COMMON_SOFTIRQS + 6)
+#define NR_ARCH_SOFTIRQS       7
 
 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 Wed Dec 17 15:55:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gwk-00068V-Nq; Wed, 17 Dec 2014 15:55:30 +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 1Y1Gwi-00067m-J9
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:28 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A2/9C-08051-F67A1945; Wed, 17 Dec 2014 15:55:27 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418831726!15686154!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 9774 invoked from network); 17 Dec 2014 15:55:27 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-27.messagelabs.com with SMTP;
	17 Dec 2014 15:55:27 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 17 Dec 2014 07:55:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="430193672"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 17 Dec 2014 07:44:16 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:40 -0500
Message-Id: <1418817100-5307-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 03/14] vTPM/TPM2: Add global data in
	vtpm_globals{}
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 data is for the Mini-os to access TPM 2.0 hardware.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/vtpmmgr.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 2d9d153..0d0c604 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -44,6 +44,7 @@
 #include "uuid.h"
 #include "tcg.h"
 #include "vtpm_manager.h"
+#include "tpm2_types.h"
 
 #define RSA_KEY_SIZE 0x0800
 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8)
@@ -59,6 +60,14 @@ struct vtpm_globals {
    ctr_drbg_context    ctr_drbg;
 
    int hw_locality;
+
+    /* TPM 2.0 */
+    TPM_AuthArea       pw_auth;
+    TPM_AuthArea       srk_auth_area;
+    TPM_HANDLE         srk_handle;
+    TPM_HANDLE         sk_handle;
+    TPM2B_NAME         sk_name;
+    TPM2_RSA_KEY       tpm2_storage_key;
 };
 
 struct tpm_opaque {
-- 
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 Dec 17 15:55:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gwi-00067o-KP; Wed, 17 Dec 2014 15:55:28 +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 1Y1Gwf-00067X-QQ
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:26 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	7A/88-14214-D67A1945; Wed, 17 Dec 2014 15:55:25 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418831723!13943009!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27365 invoked from network); 17 Dec 2014 15:55:24 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-206.messagelabs.com with SMTP;
	17 Dec 2014 15:55:24 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2014 07:55:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="649193273"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 17 Dec 2014 07:55:13 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:24 -0500
Message-Id: <1418817084-5194-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
MIME-Version: 1.0
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	tim@xen.org, ian.jackson@eu.citrix.com, jbeulich@suse.com,
	Quan Xu <quan.xu@intel.com>, samuel.thibault@ens-lyon.org,
	dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH v2 00/14] Enable vTPM subsystem on TPM 2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


This series of patch enable the virtual Trusted Platform Module (vTPM)
subsystem for Xen on TPM 2.0.

Noted, functionality for a virtual guest operating system (a DomU) is still
TPM 1.2. The main modifcation is on vtpmmgr-stubdom. The challenge is that
TPM 2.0 is not backward compatible with TPM 1.2.

------------------------------
DESIGN OVERVIEW
------------------------------
The architecture of vTPM subsystem on TPM 2.0 is described below:

+------------------+
|    Linux DomU    | ...
|       |  ^       |
|       v  |       |
|   xen-tpmfront   |
+------------------+
        |  ^
        v  |
+------------------+
| mini-os/tpmback  |
|       |  ^       |
|       v  |       |
|  vtpm-stubdom    | ...
|       |  ^       |
|       v  |       |
| mini-os/tpmfront |
+------------------+
        |  ^
        v  |
+------------------+
| mini-os/tpmback  |
|       |  ^       |
|       v  |       |
| vtpmmgr-stubdom  |
|       |  ^       |
|       v  |       |
| mini-os/tpm2_tis |
+------------------+
        |  ^
        v  |
+------------------+
| Hardware TPM 2.0 |
+------------------+
 * Linux DomU: The Linux based guest that wants to use a vTPM. There many be
               more than one of these.

 * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver
                    provides vTPM access to a para-virtualized Linux based DomU.

 * 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.  This domain regulates
               access to the physical TPM on the system and secures the
               persistent state of each vTPM.

 * mini-os/tpm2_tis: Mini-os TPM version 2.0 TPM Interface Specification (TIS)
                    driver. This driver used by vtpmmgr-stubdom to talk directly
                    to the hardware TPM 2.0. Communication is facilitated by mapping
                    hardware memory pages into vtpmmgr-stubdom.

 * Hardware TPM 2.0: The physical TPM 2.0 that is soldered onto the motherboard.

------------------------------
Key Hierarchy
------------------------------

    +------------------+
    |  vTPM's secrets  | ...
    +------------------+
            |  ^
            |  |(Bind / Unbind)
- - - - -  -v  |- - - - - - - - TPM 2.0
    +------------------+
    |        SK        +
    +------------------+
            |  ^
            v  |
    +------------------+
    |       SRK        |
    +------------------+
            |  ^
            v  |
    +------------------+
    | TPM 2.0 Storage  |
    |   Primary Seed   |
    +------------------+
------------------------------
INSTALLATION
------------------------------

Prerequisites:
--------------
You must have an x86 machine with a TPM on the motherboard.  The only extra
software requirement for compiling vTPM is cmake.  You must use libxl to manage
domains with vTPMs; 'xm' is deprecated and does not support vTPMs.

Compiling the Xen tree:
-----------------------

Compile and install the Xen tree as usual; be sure that the vTPM domains are
enabled when you run configure.

Compiling the LINUX dom0 kernel:
--------------------------------

Because the TPM manager uses direct access to the physical TPM, it may interfere
with access to the TPM by dom0.  The simplest solution for this is to prevent
dom0 from accessing the physical TPM by compiling the kernel without a driver or
blacklisting the module.

Compiling the LINUX domU kernel:
--------------------------------

The domU kernel used by domains with vtpms must include the xen-tpmfront.ko
driver. It can be built directly into the kernel or as a module; however, some
features such as IMA require the TPM to be built in to the kernel.


CONFIG_TCG_TPM=y
CONFIG_TCG_XEN=y

------------------------------
VTPM MANAGER SETUP
------------------------------

Manager disk image setup:
-------------------------

The vTPM Manager requires a disk image to store its encrypted data. The image
does not require a filesystem and can live anywhere on the host disk. The image
is not large; the Xen 4.5 vtpmmgr is limited to using the first 2MB of the image
but can support more than 20,000 vTPMs.

 dd if=/dev/zero of=/home/vtpm2/vmgr bs=16M count=1

Manager config file:
--------------------

The vTPM Manager domain (vtpmmgr-stubdom) must be started like any other Xen
virtual machine and requires a config file.  The manager requires a disk image
for storage and permission to access the hardware memory pages for the TPM. The
disk must be presented as "hda", and the TPM memory pages are passed using the
iomem configuration parameter. The TPM TIS uses 5 pages of IO memory (one per
locality) that start at physical address 0xfed40000. By default, the TPM manager
uses locality 0 (so only the page at 0xfed40 is needed).

Add:
..
     extra="tpm2"
..
extra option to launch vtpmmgr-stubdom domain on TPM 2.0, and ignore it on TPM
1.x. for example:

    kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
    memory=128
    disk=["file:/home/vtpm2/vmgr,hda,w"]
    name="vtpmmgr"
    iomem=["fed40,5"]
    extra="tpm2"


------------------------------
VTPM AND LINUX PVM SETUP
------------------------------
vTPM disk image setup:
----------------------

The vTPM requires a disk image to store its persistent data (RSA keys, NVRAM,
etc). The image does not require a filesystem. The image does not need to be
large; 2 Mb should be sufficient.

    dd if=/dev/zero of=/home/vtpm2/vtpm0 bs=2M count=1

vTPM config file:
-----------------

The vTPM domain requires a configuration file like any other domain. The vTPM
requires a disk image for storage and a TPM frontend driver to communicate with
the manager.  You are required to generate a uuid for this vtpm, which is
specified on the "vtpm=" line that describes its connection to the vTPM Manager.
for example:

    kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
    memory=8
    disk=["file:/home/vtpm2/vtpm0,hda,w"]
    name="vtpm0"
    vtpm=["backend=vtpmmgr,uuid=914fe389-e2c5-44e6-993f-2189637cf1de"]

If you wish to clear the vTPM data you can either recreate the disk image or
change the uuid.

Linux Guest config file:
------------------------
The Linux guest config file needs to be modified to include the Linux tpmfront
driver. Add the following line:

vtpm=["backend=vtpm0"]

Currently only Linux guests are supported (PV or HVM with PV drivers). My series
of patch for HVM virtual mahcine are still being reviewed and modifcated.

Using the vTPM in the guest:
----------------------------

If xen-tpmfront was compiled as a module, it must be loaded it in the guest.

# modprobe xen-tpmfront

After the Linux domain boots and the xen-tpmfront driver is loaded, you should
see the following on the vtpm console:

Info: VTPM attached to Frontend X/Y

You can quickly test the vTPM by using the sysfs interface:

# cat /sys/devices/vtpm-0/pubek
# cat /sys/devices/vtpm-0/pcrs
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

You should also see the command being sent to the vtpm console as well as the
vtpm saving its state. You should see the vtpm key being encrypted and stored on
the vtpmmgr console.

You may wish to write a script to start your vtpm and guest together and to
destroy the vtpm when the guest shuts down.

------------------------------
INTEGRATION WITH PV-GRUB
------------------------------

The vTPM currently starts up with all PCRs set to their default values (all
zeros for the lower 16).  This means that any decisions about the
trustworthiness of the created domain must be made based on the environment that
created the vTPM and the domU; for example, a system that only constructs images
using a trusted configuration and guest kernel be able to provide guarantees
about the guests and any measurements done that kernel (such as the IMA TCB
log).  Guests wishing to use a custom kernel in such a secure environment are
often started using the pv-grub bootloader as the kernel, which then can load
the untrusted kernel without needing to parse an untrusted filesystem and kernel
in dom0.  If the pv-grub stub domain succeeds in connecting to a vTPM, it will
extend the hash of the kernel that it boots into PCR #4, and will extend the
command line and initrd into PCR #5 before booting so that a domU booted in this
way can attest to its early boot state.

------------------------------
REFERENCES
------------------------------

Berlios TPM Emulator:
http://tpm-emulator.berlios.de/
Xen docs/misc/vtpm.txt
Xen docs/misc/vtpm-platforms.txt
Xen docs/misc/vtpmmgr.txt


--Changes in V2:
  1. Record some infomation in docs/misc/vtpmmgr.txt.
  2. Add TPM 2.0 PCRs read.
  3. Bind/Unbind the measurements of the hypervisor and other 
     TCB components.
  4. Change extra option from '--tpm2' to 'tpm2'



Quan Xu (14):
  vTPM/TPM2: Add TPM 2.0 data structures and commands definition
  vTPM/TPM2: TPM 2.0 data structures marshal
  vTPM/TPM2: Add global data in vtpm_globals{}
  vTPM/TPM2: Add TPM 2.0 Exposed APIs
  vTPM/TPM2: TPM 2.0 takes ownership and create SRK
  vTPM/TPM2: Create and load SK on TPM 2.0
  vTPM/TPM2: TPM2.0 TIS initialization and self test.
  vTPM/TPM2: Add main entrance vtpmmgr2_init()
  vTPM/TPM2: Support 'tpm2' extra command line.
  vTPM/TPM2: TPM 2.0 PCRs read
  vTPM/TPM2: Support TPM 2.0 bind and unbind data
  vTPM/TPM2: Bind group keys and sectors data on disk
  vTPM/TPM2: Unind group keys and sectors data on disk
  vTPM/TPM2: Record some infomation in docs/misc/vtpmmgr.txt about

 docs/misc/vtpmmgr.txt            | 150 +++++-
 extras/mini-os/include/tpm_tis.h |   1 +
 extras/mini-os/tpm_tis.c         | 156 +++++++
 stubdom/vtpmmgr/Makefile         |   2 +-
 stubdom/vtpmmgr/disk_read.c      |  16 +-
 stubdom/vtpmmgr/disk_tpm.c       |  42 +-
 stubdom/vtpmmgr/disk_tpm.h       |   4 +
 stubdom/vtpmmgr/disk_write.c     |  13 +-
 stubdom/vtpmmgr/init.c           | 315 +++++++++++++
 stubdom/vtpmmgr/tpm2.c           | 455 ++++++++++++++++++
 stubdom/vtpmmgr/tpm2.h           | 104 +++++
 stubdom/vtpmmgr/tpm2_marshal.h   | 673 +++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2_types.h     | 980 +++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.c        |  46 +-
 stubdom/vtpmmgr/vtpmmgr.h        |  29 ++
 15 files changed, 2972 insertions(+), 14 deletions(-)
 create mode 100644 stubdom/vtpmmgr/tpm2.c
 create mode 100644 stubdom/vtpmmgr/tpm2.h
 create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h
 create mode 100644 stubdom/vtpmmgr/tpm2_types.h

-- 
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 Dec 17 15:55:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gwj-00067z-4W; Wed, 17 Dec 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 <quan.xu@intel.com>) id 1Y1Gwg-00067f-Vx
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:27 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	E5/64-11581-E67A1945; Wed, 17 Dec 2014 15:55:26 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418831723!13943009!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28740 invoked from network); 17 Dec 2014 15:55:25 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-206.messagelabs.com with SMTP;
	17 Dec 2014 15:55:25 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2014 07:55:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="639067287"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 17 Dec 2014 07:55:17 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:33 -0500
Message-Id: <1418817093-5231-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 01/14] vTPM/TPM2: Add TPM 2.0 data structures
	and commands 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

Add TPM 2.0 data structures on Trusted Platform Module Library Part 2:
Structures and Trust Platform Module Library Part 3: Commands.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/tpm2_types.h | 978 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 978 insertions(+)
 create mode 100644 stubdom/vtpmmgr/tpm2_types.h

diff --git a/stubdom/vtpmmgr/tpm2_types.h b/stubdom/vtpmmgr/tpm2_types.h
new file mode 100644
index 0000000..214335c
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2_types.h
@@ -0,0 +1,978 @@
+#ifndef __TPM2_TYPES_H__
+#define __TPM2_TYPES_H__
+
+#include <stdlib.h>
+#include <stdint.h>
+
+// "implementation.h"
+// Table 212 -- Logic Values
+#define    YES      1
+#define    NO       0
+#ifndef    TRUE
+#define    TRUE     1
+#endif
+#ifndef    FALSE
+#define    FALSE    0
+#endif
+#ifndef    true
+#define    true     1
+#endif
+#ifndef    false
+#define    false    0
+#endif
+#define    SET      1
+#define    CLEAR    0
+
+
+// Table 214 -- Implemented Algorithms
+#define    ALG_RSA               YES    // 1
+#define    ALG_DES               NO     // 0
+#define    ALG__3DES             NO     // 0
+#define    ALG_SHA1              YES    // 1
+#define    ALG_HMAC              YES    // 1
+#define    ALG_AES               YES    // 1
+#define    ALG_MGF1              YES    // 1
+#define    ALG_XOR               YES    // 1
+#define    ALG_KEYEDHASH         YES    // 1
+#define    ALG_SHA256            YES    // 1
+#define    ALG_SHA384            YES    // 0
+#define    ALG_SHA512            YES    // 0
+#define    ALG_WHIRLPOOL512      YES    // 0
+#define    ALG_SM3_256           YES    // 1
+#define    ALG_SM4               YES    // 1
+#define    ALG_RSASSA            YES    // 1
+#define    ALG_RSAES             YES    // 1
+#define    ALG_RSAPSS            YES    // 1
+#define    ALG_OAEP              YES    // 1
+#define    ALG_ECC               YES    // 1
+#define    ALG_CFB               YES    // 1
+#define    ALG_ECDH              YES    // 1
+#define    ALG_ECDSA             YES    // 1
+#define    ALG_ECDAA             YES    // 1
+#define    ALG_SM2               YES    // 1
+#define    ALG_ECSCHNORR         YES    // 1
+#define    ALG_SYMCIPHER         YES    // 1
+#define    ALG_KDF1_SP800_56a    YES    // 1
+#define    ALG_KDF2              NO     // 0
+#define    ALG_KDF1_SP800_108    YES    // 1
+#define    ALG_CTR               YES    // 1
+#define    ALG_OFB               YES    // 1
+#define    ALG_CBC               YES    // 1
+
+#define HASH_COUNT (ALG_SHA1+ALG_SHA256+ALG_SHA384+ALG_SHA512+ALG_WHIRLPOOL512+ALG_SM3_256)
+
+// Table 216 -- RSA Algorithm Constants
+#define    RSA_KEY_SIZES_BITS    2048    // {1024,2048}
+#define    MAX_RSA_KEY_BITS      2048
+#define    MAX_RSA_KEY_BYTES     ((MAX_RSA_KEY_BITS + 7) / 8)    // 256
+
+// Table 218 -- AES Algorithm Constants
+#define    AES_KEY_SIZES_BITS          128
+#define    MAX_AES_KEY_BITS            128
+#define    MAX_AES_BLOCK_SIZE_BYTES    16
+#define    MAX_AES_KEY_BYTES           ((MAX_AES_KEY_BITS + 7) / 8)    // 16
+
+
+// Table 220 -- Symmetric Algorithm Constants
+#define    MAX_SYM_KEY_BITS      MAX_AES_KEY_BITS    // 128
+#define    MAX_SYM_KEY_BYTES     MAX_AES_KEY_BYTES    // 16
+#define    MAX_SYM_BLOCK_SIZE    MAX_AES_BLOCK_SIZE_BYTES    // 16
+
+#define    MAX_SYM_DATA         128
+#define    MAX_ECC_KEY_BITS     256
+#define    MAX_ECC_KEY_BYTES    ((MAX_ECC_KEY_BITS + 7) / 8)
+
+
+typedef unsigned char BYTE;
+typedef unsigned char BOOL;
+typedef uint8_t       UINT8;
+typedef uint16_t      UINT16;
+typedef uint32_t      UINT32;
+typedef uint64_t      UINT64;
+
+// TPM2 command code
+
+typedef UINT32 TPM_CC;
+#define    TPM_CC_FIRST                         (TPM_CC)(0x0000011F)
+#define    TPM_CC_PP_FIRST                      (TPM_CC)(0x0000011F)
+#define    TPM_CC_NV_UndefineSpaceSpecial       (TPM_CC)(0x0000011F)
+#define    TPM_CC_EvictControl                  (TPM_CC)(0x00000120)
+#define    TPM_CC_HierarchyControl              (TPM_CC)(0x00000121)
+#define    TPM_CC_NV_UndefineSpace              (TPM_CC)(0x00000122)
+#define    TPM_CC_ChangeEPS                     (TPM_CC)(0x00000124)
+#define    TPM_CC_ChangePPS                     (TPM_CC)(0x00000125)
+#define    TPM_CC_Clear                         (TPM_CC)(0x00000126)
+#define    TPM_CC_ClearControl                  (TPM_CC)(0x00000127)
+#define    TPM_CC_ClockSet                      (TPM_CC)(0x00000128)
+#define    TPM_CC_HierarchyChangeAuth           (TPM_CC)(0x00000129)
+#define    TPM_CC_NV_DefineSpace                (TPM_CC)(0x0000012A)
+#define    TPM_CC_PCR_Allocate                  (TPM_CC)(0x0000012B)
+#define    TPM_CC_PCR_SetAuthPolicy             (TPM_CC)(0x0000012C)
+#define    TPM_CC_PP_Commands                   (TPM_CC)(0x0000012D)
+#define    TPM_CC_SetPrimaryPolicy              (TPM_CC)(0x0000012E)
+#define    TPM_CC_FieldUpgradeStart             (TPM_CC)(0x0000012F)
+#define    TPM_CC_ClockRateAdjust               (TPM_CC)(0x00000130)
+#define    TPM_CC_CreatePrimary                 (TPM_CC)(0x00000131)
+#define    TPM_CC_NV_GlobalWriteLock            (TPM_CC)(0x00000132)
+#define    TPM_CC_PP_LAST                       (TPM_CC)(0x00000132)
+#define    TPM_CC_GetCommandAuditDigest         (TPM_CC)(0x00000133)
+#define    TPM_CC_NV_Increment                  (TPM_CC)(0x00000134)
+#define    TPM_CC_NV_SetBits                    (TPM_CC)(0x00000135)
+#define    TPM_CC_NV_Extend                     (TPM_CC)(0x00000136)
+#define    TPM_CC_NV_Write                      (TPM_CC)(0x00000137)
+#define    TPM_CC_NV_WriteLock                  (TPM_CC)(0x00000138)
+#define    TPM_CC_DictionaryAttackLockReset     (TPM_CC)(0x00000139)
+#define    TPM_CC_DictionaryAttackParameters    (TPM_CC)(0x0000013A)
+#define    TPM_CC_NV_ChangeAuth                 (TPM_CC)(0x0000013B)
+#define    TPM_CC_PCR_Event                     (TPM_CC)(0x0000013C)
+#define    TPM_CC_PCR_Reset                     (TPM_CC)(0x0000013D)
+#define    TPM_CC_SequenceComplete              (TPM_CC)(0x0000013E)
+#define    TPM_CC_SetAlgorithmSet               (TPM_CC)(0x0000013F)
+#define    TPM_CC_SetCommandCodeAuditStatus     (TPM_CC)(0x00000140)
+#define    TPM_CC_FieldUpgradeData              (TPM_CC)(0x00000141)
+#define    TPM_CC_IncrementalSelfTest           (TPM_CC)(0x00000142)
+#define    TPM_CC_SelfTest                      (TPM_CC)(0x00000143)
+#define    TPM_CC_Startup                       (TPM_CC)(0x00000144)
+#define    TPM_CC_Shutdown                      (TPM_CC)(0x00000145)
+#define    TPM_CC_StirRandom                    (TPM_CC)(0x00000146)
+#define    TPM_CC_ActivateCredential            (TPM_CC)(0x00000147)
+#define    TPM_CC_Certify                       (TPM_CC)(0x00000148)
+#define    TPM_CC_PolicyNV                      (TPM_CC)(0x00000149)
+#define    TPM_CC_CertifyCreation               (TPM_CC)(0x0000014A)
+#define    TPM_CC_Duplicate                     (TPM_CC)(0x0000014B)
+#define    TPM_CC_GetTime                       (TPM_CC)(0x0000014C)
+#define    TPM_CC_GetSessionAuditDigest         (TPM_CC)(0x0000014D)
+#define    TPM_CC_NV_Read                       (TPM_CC)(0x0000014E)
+#define    TPM_CC_NV_ReadLock                   (TPM_CC)(0x0000014F)
+#define    TPM_CC_ObjectChangeAuth              (TPM_CC)(0x00000150)
+#define    TPM_CC_PolicySecret                  (TPM_CC)(0x00000151)
+#define    TPM_CC_Rewrap                        (TPM_CC)(0x00000152)
+#define    TPM_CC_Create                        (TPM_CC)(0x00000153)
+#define    TPM_CC_ECDH_ZGen                     (TPM_CC)(0x00000154)
+#define    TPM_CC_HMAC                          (TPM_CC)(0x00000155)
+#define    TPM_CC_Import                        (TPM_CC)(0x00000156)
+#define    TPM_CC_Load                          (TPM_CC)(0x00000157)
+#define    TPM_CC_Quote                         (TPM_CC)(0x00000158)
+#define    TPM_CC_RSA_Decrypt                   (TPM_CC)(0x00000159)
+#define    TPM_CC_HMAC_Start                    (TPM_CC)(0x0000015B)
+#define    TPM_CC_SequenceUpdate                (TPM_CC)(0x0000015C)
+#define    TPM_CC_Sign                          (TPM_CC)(0x0000015D)
+#define    TPM_CC_Unseal                        (TPM_CC)(0x0000015E)
+#define    TPM_CC_PolicySigned                  (TPM_CC)(0x00000160)
+#define    TPM_CC_ContextLoad                   (TPM_CC)(0x00000161)
+#define    TPM_CC_ContextSave                   (TPM_CC)(0x00000162)
+#define    TPM_CC_ECDH_KeyGen                   (TPM_CC)(0x00000163)
+#define    TPM_CC_EncryptDecrypt                (TPM_CC)(0x00000164)
+#define    TPM_CC_FlushContext                  (TPM_CC)(0x00000165)
+#define    TPM_CC_LoadExternal                  (TPM_CC)(0x00000167)
+#define    TPM_CC_MakeCredential                (TPM_CC)(0x00000168)
+#define    TPM_CC_NV_ReadPublic                 (TPM_CC)(0x00000169)
+#define    TPM_CC_PolicyAuthorize               (TPM_CC)(0x0000016A)
+#define    TPM_CC_PolicyAuthValue               (TPM_CC)(0x0000016B)
+#define    TPM_CC_PolicyCommandCode             (TPM_CC)(0x0000016C)
+#define    TPM_CC_PolicyCounterTimer            (TPM_CC)(0x0000016D)
+#define    TPM_CC_PolicyCpHash                  (TPM_CC)(0x0000016E)
+#define    TPM_CC_PolicyLocality                (TPM_CC)(0x0000016F)
+#define    TPM_CC_PolicyNameHash                (TPM_CC)(0x00000170)
+#define    TPM_CC_PolicyOR                      (TPM_CC)(0x00000171)
+#define    TPM_CC_PolicyTicket                  (TPM_CC)(0x00000172)
+#define    TPM_CC_ReadPublic                    (TPM_CC)(0x00000173)
+#define    TPM_CC_RSA_Encrypt                   (TPM_CC)(0x00000174)
+#define    TPM_CC_StartAuthSession              (TPM_CC)(0x00000176)
+#define    TPM_CC_VerifySignature               (TPM_CC)(0x00000177)
+#define    TPM_CC_ECC_Parameters                (TPM_CC)(0x00000178)
+#define    TPM_CC_FirmwareRead                  (TPM_CC)(0x00000179)
+#define    TPM_CC_GetCapability                 (TPM_CC)(0x0000017A)
+#define    TPM_CC_GetRandom                     (TPM_CC)(0x0000017B)
+#define    TPM_CC_GetTestResult                 (TPM_CC)(0x0000017C)
+#define    TPM_CC_Hash                          (TPM_CC)(0x0000017D)
+#define    TPM_CC_PCR_Read                      (TPM_CC)(0x0000017E)
+#define    TPM_CC_PolicyPCR                     (TPM_CC)(0x0000017F)
+#define    TPM_CC_PolicyRestart                 (TPM_CC)(0x00000180)
+#define    TPM_CC_ReadClock                     (TPM_CC)(0x00000181)
+#define    TPM_CC_PCR_Extend                    (TPM_CC)(0x00000182)
+#define    TPM_CC_PCR_SetAuthValue              (TPM_CC)(0x00000183)
+#define    TPM_CC_NV_Certify                    (TPM_CC)(0x00000184)
+#define    TPM_CC_EventSequenceComplete         (TPM_CC)(0x00000185)
+#define    TPM_CC_HashSequenceStart             (TPM_CC)(0x00000186)
+#define    TPM_CC_PolicyPhysicalPresence        (TPM_CC)(0x00000187)
+#define    TPM_CC_PolicyDuplicationSelect       (TPM_CC)(0x00000188)
+#define    TPM_CC_PolicyGetDigest               (TPM_CC)(0x00000189)
+#define    TPM_CC_TestParms                     (TPM_CC)(0x0000018A)
+#define    TPM_CC_Commit                        (TPM_CC)(0x0000018B)
+#define    TPM_CC_PolicyPassword                (TPM_CC)(0x0000018C)
+#define    TPM_CC_SM2_ZGen                      (TPM_CC)(0x0000018D)
+#define    TPM_CC_LAST                          (TPM_CC)(0x0000018D)
+
+
+//TPM_RC
+typedef UINT32 TPM_RC;
+
+// TPM_ST Constants
+typedef UINT16 TPM_ST;
+#define    TPM_ST_NULL                    (TPM_ST)(0X8000)
+#define    TPM_ST_NO_SESSIONS             (TPM_ST)(0x8001)
+#define    TPM_ST_SESSIONS                (TPM_ST)(0x8002)
+
+
+// TPM Handle types
+typedef UINT32 TPM_HANDLE;
+typedef UINT8 TPM_HT;
+
+
+// TPM_RH Constants
+typedef UINT32 TPM_RH;
+
+#define    TPM_RH_FIRST          (TPM_RH)(0x40000000)
+#define    TPM_RH_SRK            (TPM_RH)(0x40000000)
+#define    TPM_RH_OWNER          (TPM_RH)(0x40000001)
+#define    TPM_RS_PW             (TPM_RH)(0x40000009)
+#define    TPM_RH_LOCKOUT        (TPM_RH)(0x4000000A)
+#define    TPM_RH_ENDORSEMENT    (TPM_RH)(0x4000000B)
+#define    TPM_RH_PLATFORM       (TPM_RH)(0x4000000C)
+#define    TPM_RH_LAST           (TPM_RH)(0x4000000C)
+
+// Table 4 -- DocumentationClarity Types <I/O>
+typedef UINT32    TPM_ALGORITHM_ID;
+typedef UINT32    TPM_MODIFIER_INDICATOR;
+typedef UINT32    TPM_SESSION_OFFSET;
+typedef UINT16    TPM_KEY_SIZE;
+typedef UINT16    TPM_KEY_BITS;
+typedef UINT64    TPM_SYSTEM_ADDRESS;
+typedef UINT32    TPM_SPEC;
+
+// Table 29 -- TPMA_ALGORITHM Bits <I/O>
+typedef struct {
+    unsigned int asymmetric:1;
+    unsigned int symmetric:1;
+    unsigned int hash:1;
+    unsigned int object:1;
+    unsigned int reserved5:4;
+    unsigned int signing:1;
+    unsigned int encrypting:1;
+    unsigned int method:1;
+    unsigned int reserved9:21;
+} TPMA_ALGORITHM;
+
+typedef UINT32 TPMA_OBJECT;
+typedef BYTE TPMA_SESSION;
+typedef BYTE TPMA_LOCALITY;
+
+// Table 37 -- TPMI_YES_NO Type <I/O>
+typedef BYTE TPMI_YES_NO;
+
+typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
+
+// Table 38 -- TPMI_DH_OBJECT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_OBJECT;
+
+// Table 39 -- TPMI_DH_PERSISTENT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_PERSISTENT;
+
+// Table 42 -- TPMI_SH_AUTH_SESSION Type <I/O>
+typedef TPM_HANDLE TPMI_SH_AUTH_SESSION;
+
+// Table 40 -- TPMI_DH_ENTITY Type <I>
+typedef TPM_HANDLE TPMI_DH_ENTITY;
+
+// Table 45 -- TPMI_DH_CONTEXT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_CONTEXT;
+
+// Table 46 -- TPMI_RH_HIERARCHY Type <I/O>
+typedef TPM_HANDLE TPMI_RH_HIERARCHY;
+
+// Table 47 -- TPMI_RH_HIERARCHY_AUTH Type <I>
+typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
+
+// Table 48 -- TPMI_RH_PLATFORM Type <I>
+typedef TPM_HANDLE TPMI_RH_PLATFORM;
+
+// Table 49 -- TPMI_RH_OWNER Type <I>
+typedef TPM_HANDLE TPMI_RH_OWNER;
+
+// Table 50 -- TPMI_RH_ENDORSEMENT Type <I>
+typedef TPM_HANDLE TPMI_RH_ENDORSEMENT;
+
+// Table 51 -- TPMI_RH_PROVISION Type <I>
+typedef TPM_HANDLE TPMI_RH_PROVISION;
+
+// Table 52 -- TPMI_RH_CLEAR Type <I>
+typedef TPM_HANDLE TPMI_RH_CLEAR;
+
+// Table 54 -- TPMI_RH_LOCKOUT Type <I>
+typedef TPM_HANDLE TPMI_RH_LOCKOUT;
+
+// Table 7 -- TPM_ALG_ID
+typedef UINT16 TPM_ALG_ID;
+typedef UINT16 TPM_ALG_ID;
+
+#define    TPM2_ALG_ERROR             (TPM_ALG_ID)(0x0000) // a: ; D:
+#define    TPM2_ALG_FIRST             (TPM_ALG_ID)(0x0001) // a: ; D:
+#if ALG_RSA == YES || ALG_ALL == YES
+#define    TPM2_ALG_RSA               (TPM_ALG_ID)(0x0001) // a: A O; D:
+#endif
+#if ALG_DES == YES || ALG_ALL == YES
+#define    TPM2_ALG_DES               (TPM_ALG_ID)(0x0002) // a: S; D:
+#endif
+#define    TPM2_ALG_SHA1              (TPM_ALG_ID)(0x0004) // a: H; D:
+#if ALG_HMAC == YES || ALG_ALL == YES
+#define    TPM2_ALG_HMAC              (TPM_ALG_ID)(0x0005) // a: H X; D:
+#endif
+#if ALG_AES == YES || ALG_ALL == YES
+#define    TPM2_ALG_AES               (TPM_ALG_ID)(0x0006) // a: S; D:
+#endif
+#if ALG_XOR == YES || ALG_ALL == YES
+#define    TPM2_ALG_XOR               (TPM_ALG_ID)(0x000A) // a: H S; D:
+#endif
+#if ALG_MGF1 == YES || ALG_ALL == YES
+#define    TPM2_ALG_MGF1              (TPM_ALG_ID)(0x0007) // a: H M; D:
+#endif
+#if ALG_KEYEDHASH == YES || ALG_ALL == YES
+#define    TPM2_ALG_KEYEDHASH         (TPM_ALG_ID)(0x0008) // a: H E X O; D:
+#endif
+#if ALG_SHA256 == YES || ALG_ALL == YES
+#define    TPM2_ALG_SHA256            (TPM_ALG_ID)(0x000B) // a: H; D:
+#endif
+#define    TPM2_ALG_NULL              (TPM_ALG_ID)(0x0010) // a: ; D:
+#if ALG_OAEP == YES || ALG_ALL == YES
+#define    TPM2_ALG_OAEP              (TPM_ALG_ID)(0x0017) // a: A E; D: RSA
+#endif
+#if ALG_ECC == YES || ALG_ALL == YES
+#define    TPM2_ALG_ECC               (TPM_ALG_ID)(0x0023) // a: A O; D:
+#endif
+#if ALG_SM4 == YES || ALG_ALL == YES
+#define    TPM2_ALG_SM4               (TPM_ALG_ID)(0x0013) // a: S; D:
+#endif
+#if ALG_SYMCIPHER == YES || ALG_ALL == YES
+#define    TPM2_ALG_SYMCIPHER         (TPM_ALG_ID)(0x0025) // a: O; D:
+#endif
+#if ALG_CFB == YES || ALG_ALL == YES
+#define    TPM2_ALG_CFB               (TPM_ALG_ID)(0x0043) // a: S E; D:
+#endif
+#define    TPM2_ALG_LAST              (TPM_ALG_ID)(0x0044)
+
+#define    SHA1_DIGEST_SIZE      20
+#define    SHA1_BLOCK_SIZE       64
+#define    SHA256_DIGEST_SIZE    32
+#define    SHA256_BLOCK_SIZE     64
+
+// Table 57 -- TPMI_ALG_ASYM Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_ASYM;
+
+// Table 56 -- TPMI_ALG_HASH Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_HASH;
+
+// Table 58 -- TPMI_ALG_SYM Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM;
+
+// Table 59 -- TPMI_ALG_SYM_OBJECT Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM_OBJECT;
+
+// Table 60 -- TPMI_ALG_SYM_MODE Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM_MODE;
+
+// Table 61 -- TPMI_ALG_KDF Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_KDF;
+
+// Table 62 -- TPMI_ALG_SIG_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SIG_SCHEME;
+
+// Table 65 -- TPMU_HA Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_SHA1
+    BYTE  sha1[SHA1_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA256
+    BYTE  sha256[SHA256_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SM3_256
+    BYTE  sm3_256[SM3_256_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA384
+    BYTE  sha384[SHA384_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA512
+    BYTE  sha512[SHA512_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_WHIRLPOOL512
+    BYTE  whirlpool[WHIRLPOOL512_DIGEST_SIZE];
+#endif
+
+} TPMU_HA;
+
+// Table 67 -- TPM2B_DIGEST Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[sizeof(TPMU_HA)];
+} TPM2B_DIGEST;
+
+// Table 69 -- TPM2B_NONCE Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_NONCE;
+
+typedef TPM2B_DIGEST    TPM2B_DATA;
+
+// Table 70 -- TPM2B_AUTH Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_AUTH;
+
+// Table 71 -- TPM2B_OPERAND Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_OPERAND;
+
+// Table 66 -- TPMT_HA Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    TPMU_HA          digest;
+} TPMT_HA;
+
+//Table 80 -- TPM2B_NAME Structure
+typedef struct {
+    UINT16 size;
+    BYTE name[sizeof(TPMT_HA)];
+} TPM2B_NAME;
+
+#define    IMPLEMENTATION_PCR   24
+#define    PLATFORM_PCR         24
+#define    PCR_SELECT_MAX       ((IMPLEMENTATION_PCR+7)/8)
+
+//Table 79 -- TPMS_PCR_SELECT Structure <I/O>
+typedef struct {
+    UINT8    sizeofSelect;
+    BYTE     pcrSelect[PCR_SELECT_MAX];
+} TPMS_PCR_SELECT;
+
+// Table 80 -- TPMS_PCR_SELECTION Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hash;
+    UINT8            sizeofSelect;
+    BYTE             pcrSelect[PCR_SELECT_MAX];
+} TPMS_PCR_SELECTION;
+
+// Table 83 -- TPMT_TK_CREATION Structure <I/O>
+typedef struct {
+    TPM_ST               tag;
+    TPMI_RH_HIERARCHY    hierarchy;
+    TPM2B_DIGEST         digest;
+} TPMT_TK_CREATION;
+
+// Table 96 -- Definition of TPML_DIGEST Structure <I/O>
+typedef struct {
+    UINT32               count;
+    TPM2B_DIGEST         digests[8];
+}TPML_DIGEST;
+
+// Table 97 -- TPML_PCR_SELECTION Structure <I/O>
+typedef struct {
+    UINT32                count;
+    TPMS_PCR_SELECTION    pcrSelections[HASH_COUNT];
+} TPML_PCR_SELECTION;
+
+// Table 119 -- TPMI_AES_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_AES_KEY_BITS;
+
+// Table 120 -- TPMI_SM4_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_SM4_KEY_BITS;
+
+// Table 121 -- TPMU_SYM_KEY_BITS Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_AES
+    TPMI_AES_KEY_BITS  aes;
+#endif
+#ifdef TPM2_ALG_SM4
+    TPMI_SM4_KEY_BITS  SM4;
+#endif
+    TPM_KEY_BITS  sym;
+#ifdef TPM2_ALG_XOR
+    TPMI_ALG_HASH  xor;
+#endif
+
+} TPMU_SYM_KEY_BITS;
+
+// Table 122 -- TPMU_SYM_MODE Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_AES
+    TPMI_ALG_SYM_MODE  aes;
+#endif
+#ifdef TPM2_ALG_SM4
+    TPMI_ALG_SYM_MODE  SM4;
+#endif
+    TPMI_ALG_SYM_MODE  sym;
+} TPMU_SYM_MODE ;
+
+// Table 124 -- TPMT_SYM_DEF Structure <I/O>
+typedef struct {
+    TPMI_ALG_SYM         algorithm;
+    TPMU_SYM_KEY_BITS    keyBits;
+    TPMU_SYM_MODE        mode;
+} TPMT_SYM_DEF;
+
+// Table 125 -- TPMT_SYM_DEF_OBJECT Structure <I/O>
+typedef struct {
+    TPMI_ALG_SYM_OBJECT    algorithm;
+    TPMU_SYM_KEY_BITS      keyBits;
+    TPMU_SYM_MODE          mode;
+} TPMT_SYM_DEF_OBJECT;
+
+// Table 126 -- TPM2B_SYM_KEY Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_SYM_KEY_BYTES];
+} TPM2B_SYM_KEY;
+
+// Table 127 -- TPMS_SYMCIPHER_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    sym;
+} TPMS_SYMCIPHER_PARMS;
+
+// Table 128 -- TPM2B_SENSITIVE_DATA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_SYM_DATA];
+} TPM2B_SENSITIVE_DATA;
+
+// Table 129 -- TPMS_SENSITIVE_CREATE Structure <I>
+typedef struct {
+    TPM2B_AUTH              userAuth;
+    TPM2B_SENSITIVE_DATA    data;
+} TPMS_SENSITIVE_CREATE;
+
+// Table 130 -- TPM2B_SENSITIVE_CREATE Structure <I,S>
+typedef struct {
+    UINT16                   size;
+    TPMS_SENSITIVE_CREATE    sensitive;
+} TPM2B_SENSITIVE_CREATE;
+
+// Table 131 -- TPMS_SCHEME_SIGHASH Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_SIGHASH;
+
+// Table 132 -- TPMI_ALG_KEYEDHASH_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_KEYEDHASH_SCHEME;
+
+// Table 133 -- HMAC_SIG_SCHEME Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_HMAC;
+
+// Table 134 -- TPMS_SCHEME_XOR Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    TPMI_ALG_KDF     kdf;
+} TPMS_SCHEME_XOR;
+
+// Table 135 -- TPMU_SCHEME_KEYEDHASH Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_HMAC
+    TPMS_SCHEME_HMAC  hmac;
+#endif
+#ifdef TPM2_ALG_XOR
+    TPMS_SCHEME_XOR  xor;
+#endif
+
+} TPMU_SCHEME_KEYEDHASH ;
+
+// Table 136 -- TPMT_KEYEDHASH_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_KEYEDHASH_SCHEME    scheme;
+    TPMU_SCHEME_KEYEDHASH        details;
+} TPMT_KEYEDHASH_SCHEME;
+
+// Table 137 -- RSA_SIG_SCHEMES Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_RSASSA;
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_RSAPSS;
+
+// Table 138 -- ECC_SIG_SCHEMES Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_ECDSA;
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_SM2;
+
+// Table 139 -- TPMS_SCHEME_ECDAA Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    UINT16           count;
+} TPMS_SCHEME_ECDAA;
+
+// Table 140 -- TPMS_SCHEME_ECSCHNORR Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    UINT16           count;
+} TPMS_SCHEME_ECSCHNORR;
+
+// Table 141 -- TPMU_SIG_SCHEME Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_RSASSA
+    TPMS_SCHEME_RSASSA  rsassa;
+#endif
+#ifdef TPM2_ALG_RSAPSS
+    TPMS_SCHEME_RSAPSS  rsapss;
+#endif
+#ifdef TPM2_ALG_ECDSA
+    TPMS_SCHEME_ECDSA  ecdsa;
+#endif
+#ifdef TPM2_ALG_SM2
+    TPMS_SCHEME_SM2  sm2;
+#endif
+#ifdef TPM2_ALG_ECDAA
+    TPMS_SCHEME_ECDAA  ecdaa;
+#endif
+#ifdef TPM2_ALG_ECSCHNORR
+    TPMS_SCHEME_ECSCHNORR  ecSchnorr;
+#endif
+#ifdef TPM2_ALG_HMAC
+    TPMS_SCHEME_HMAC  hmac;
+#endif
+    TPMS_SCHEME_SIGHASH  any;
+} TPMU_SIG_SCHEME;
+
+// Table 142 -- TPMT_SIG_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_SIG_SCHEME    scheme;
+    TPMU_SIG_SCHEME        details;
+} TPMT_SIG_SCHEME;
+
+// Table 143 -- TPMS_SCHEME_OAEP Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_OAEP;
+
+// Table 144 -- TPMS_SCHEME_ECDH Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_ECDH;
+
+// Table 145 -- TPMS_SCHEME_MGF1 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_MGF1;
+
+// Table 146 -- TPMS_SCHEME_KDF1_SP800_56a Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF1_SP800_56a;
+
+// Table 147 -- TPMS_SCHEME_KDF2 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF2;
+
+// Table 148 -- TPMS_SCHEME_KDF1_SP800_108 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF1_SP800_108;
+
+// Table 149 -- TPMU_KDF_SCHEME Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_MGF1
+    TPMS_SCHEME_MGF1  mgf1;
+#endif
+#ifdef TPM2_ALG_KDF1_SP800_56a
+    TPMS_SCHEME_KDF1_SP800_56a  kdf1_SP800_56a;
+#endif
+#ifdef TPM2_ALG_KDF2
+    TPMS_SCHEME_KDF2  kdf2;
+#endif
+#ifdef TPM2_ALG_KDF1_SP800_108
+    TPMS_SCHEME_KDF1_SP800_108  kdf1_sp800_108;
+#endif
+
+} TPMU_KDF_SCHEME;
+
+// Table 150 -- TPMT_KDF_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_KDF       scheme;
+    TPMU_KDF_SCHEME    details;
+} TPMT_KDF_SCHEME;
+typedef TPM_ALG_ID TPMI_ALG_ASYM_SCHEME;
+
+// Table 152 -- TPMU_ASYM_SCHEME Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_RSASSA
+    TPMS_SCHEME_RSASSA  rsassa;
+#endif
+#ifdef TPM2_ALG_RSAPSS
+    TPMS_SCHEME_RSAPSS  rsapss;
+#endif
+#ifdef TPM2_ALG_OAEP
+    TPMS_SCHEME_OAEP  oaep;
+#endif
+#ifdef TPM2_ALG_ECDSA
+    TPMS_SCHEME_ECDSA  ecdsa;
+#endif
+#ifdef TPM2_ALG_SM2
+    TPMS_SCHEME_SM2  sm2;
+#endif
+#ifdef TPM2_ALG_ECDAA
+    TPMS_SCHEME_ECDAA  ecdaa;
+#endif
+#ifdef TPM2_ALG_ECSCHNORR
+    TPMS_SCHEME_ECSCHNORR  ecSchnorr;
+#endif
+    TPMS_SCHEME_SIGHASH  anySig;
+} TPMU_ASYM_SCHEME;
+
+typedef struct {
+    TPMI_ALG_ASYM_SCHEME    scheme;
+    TPMU_ASYM_SCHEME        details;
+} TPMT_ASYM_SCHEME;
+
+// Table 154 -- TPMI_ALG_RSA_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_RSA_SCHEME;
+
+// Table 155 -- TPMT_RSA_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_RSA_SCHEME    scheme;
+    TPMU_ASYM_SCHEME       details;
+} TPMT_RSA_SCHEME;
+
+// Table 156 -- TPMI_ALG_RSA_DECRYPT Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_RSA_DECRYPT;
+
+// Table 157 -- TPMT_RSA_DECRYPT Structure <I/O>
+typedef struct {
+    TPMI_ALG_RSA_DECRYPT    scheme;
+    TPMU_ASYM_SCHEME        details;
+} TPMT_RSA_DECRYPT;
+
+// Table 158 -- TPM2B_PUBLIC_KEY_RSA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_RSA_KEY_BYTES];
+} TPM2B_PUBLIC_KEY_RSA;
+
+// Table 159 -- TPMI_RSA_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_RSA_KEY_BITS;
+
+// Table 160 -- TPM2B_PRIVATE_KEY_RSA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_RSA_KEY_BYTES/2];
+} TPM2B_PRIVATE_KEY_RSA;
+
+// Table 162 -- TPM2B_ECC_PARAMETER
+typedef struct {
+    UINT16 size;
+    BYTE buffer[MAX_ECC_KEY_BYTES];
+} TPM2B_ECC_PARAMETER;
+
+// Table 163 -- TPMS_ECC_POINT Structure <I/O>
+typedef struct {
+    TPM2B_ECC_PARAMETER    x;
+    TPM2B_ECC_PARAMETER    y;
+} TPMS_ECC_POINT;
+
+// Table 164 -- TPMI_ALG_ECC_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_ECC_SCHEME;
+
+typedef UINT16 TPM_ECC_CURVE;
+
+// Table 165 -- TPMI_ECC_CURVE Type <I/O>
+typedef TPM_ECC_CURVE TPMI_ECC_CURVE;
+
+// Table 166 -- TPMT_ECC_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_ECC_SCHEME    scheme;
+    TPMU_SIG_SCHEME        details;
+} TPMT_ECC_SCHEME;
+
+// Table 175 -- TPMI_ALG_PUBLIC Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_PUBLIC;
+
+// Table 176 -- TPMU_PUBLIC_ID Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_KEYEDHASH
+    TPM2B_DIGEST  keyedHash;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPM2B_DIGEST  sym;
+#endif
+#ifdef TPM2_ALG_RSA
+    TPM2B_PUBLIC_KEY_RSA  rsa;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPMS_ECC_POINT  ecc;
+#endif
+} TPMU_PUBLIC_ID;
+
+// Table 177 -- TPMS_KEYEDHASH_PARMS Structure <I/O>
+typedef struct {
+    TPMT_KEYEDHASH_SCHEME    scheme;
+} TPMS_KEYEDHASH_PARMS;
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_ASYM_SCHEME       scheme;
+} TPMS_ASYM_PARMS;
+
+// Table 179 -- TPMS_RSA_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_RSA_SCHEME        scheme;
+    TPMI_RSA_KEY_BITS      keyBits;
+    UINT32                 exponent;
+} TPMS_RSA_PARMS;
+
+// Table 180 -- TPMS_ECC_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_ECC_SCHEME        scheme;
+    TPMI_ECC_CURVE         curveID;
+    TPMT_KDF_SCHEME        kdf;
+} TPMS_ECC_PARMS;
+
+// Table 181 -- TPMU_PUBLIC_PARMS Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_KEYEDHASH
+    TPMS_KEYEDHASH_PARMS  keyedHashDetail;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPMT_SYM_DEF_OBJECT  symDetail;
+#endif
+#ifdef TPM2_ALG_RSA
+    TPMS_RSA_PARMS  rsaDetail;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPMS_ECC_PARMS  eccDetail;
+#endif
+    TPMS_ASYM_PARMS  asymDetail;
+} TPMU_PUBLIC_PARMS;
+
+// Table 182 -- TPMT_PUBLIC_PARMS Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC      type;
+    TPMU_PUBLIC_PARMS    parameters;
+} TPMT_PUBLIC_PARMS;
+
+// Table 183 -- TPMT_PUBLIC Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC      type;
+    TPMI_ALG_HASH        nameAlg;
+    TPMA_OBJECT          objectAttributes;
+    TPM2B_DIGEST         authPolicy;
+    TPMU_PUBLIC_PARMS    parameters;
+    TPMU_PUBLIC_ID       unique;
+} TPMT_PUBLIC;
+
+// Table 184 -- TPM2B_PUBLIC
+typedef struct {
+    UINT16         size;
+    TPMT_PUBLIC    publicArea;
+} TPM2B_PUBLIC;
+
+// Table 185 -- TPMU_SENSITIVE_COMPOSITE Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_RSA
+    TPM2B_PRIVATE_KEY_RSA  rsa;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPM2B_ECC_PARAMETER  ecc;
+#endif
+#ifdef TPM2_ALG_KEYEDHASH
+    TPM2B_SENSITIVE_DATA  bits;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPM2B_SYM_KEY  sym;
+#endif
+    TPM2B_SENSITIVE_DATA  any;
+} TPMU_SENSITIVE_COMPOSITE;
+
+// Table 186 -- TPMT_SENSITIVE Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC             sensitiveType;
+    TPM2B_AUTH                  authValue;
+    TPM2B_DIGEST                seedValue;
+    TPMU_SENSITIVE_COMPOSITE    sensitive;
+} TPMT_SENSITIVE;
+
+// Table 187 -- TPM2B_SENSITIVE Structure <I/O>
+typedef struct {
+    UINT16            size;
+    TPMT_SENSITIVE    sensitiveArea;
+} TPM2B_SENSITIVE;
+
+typedef struct {
+    TPM2B_DIGEST      integrityOuter;
+    TPM2B_DIGEST      integrityInner;
+    TPMT_SENSITIVE    sensitive;
+} _PRIVATE;
+
+// Table 189 -- TPM2B_PRIVATE Structure <I/O,S>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[sizeof(_PRIVATE)];
+} TPM2B_PRIVATE;
+
+// Table 204 -- TPMS_CREATION_DATA <OUT>
+typedef struct {
+    TPML_PCR_SELECTION    pcrSelect;
+    TPM2B_DIGEST          pcrDigest;
+    TPMA_LOCALITY         locality;
+    TPM_ALG_ID            parentNameAlg;
+    TPM2B_NAME            parentName;
+    TPM2B_NAME            parentQualifiedName;
+    TPM2B_DATA            outsideInfo;
+} TPMS_CREATION_DATA;
+
+// Table 205 -- TPM2B_CREATION_DATA <OUT>
+typedef struct {
+    UINT16 size;
+    TPMS_CREATION_DATA creationData;
+} TPM2B_CREATION_DATA;
+
+/* the following structs is not part of standard struct defined in TPM2 spec */
+typedef struct {
+    UINT32            size;
+    TPM_RH            sessionHandle;
+    TPM2B_NONCE       nonce;
+    TPMA_SESSION      sessionAttributes;
+    TPM2B_AUTH        auth;
+} TPM_AuthArea;
+
+typedef struct {
+    TPM2B_SENSITIVE_CREATE  inSensitive;
+    TPM2B_PUBLIC            inPublic;
+    TPM2B_DATA              outsideInfo;
+    TPML_PCR_SELECTION      creationPCR;
+} TPM2_Create_Params_in;
+
+typedef TPM2_Create_Params_in    TPM2_CreatePrimary_Params_in;
+
+typedef struct {
+    TPM2B_PUBLIC        outPublic;
+    TPM2B_CREATION_DATA creationData;
+    TPM2B_DIGEST        creationHash;
+    TPMT_TK_CREATION    creationTicket;
+    TPM2B_NAME          name;
+} TPM2_CreatePrimary_Params_out;
+
+typedef struct {
+    TPM2B_PRIVATE       outPrivate;
+    TPM2B_PUBLIC        outPublic;
+    TPM2B_CREATION_DATA creationData;
+    TPM2B_DIGEST        creationHash;
+    TPMT_TK_CREATION    creationTicket;
+} TPM2_Create_Params_out;
+typedef struct {
+    TPM2B_PRIVATE    Private;
+    TPM2B_PUBLIC     Public;
+} TPM2_RSA_KEY;
+
+/*
+ * TPM 2.0 Objects
+ */
+
+#define TPM_HT_TRANSIENT        0x80
+#define HR_SHIFT                24
+#define HR_PERMANENT            (TPM_HT_TRANSIENT << HR_SHIFT)
+#define TRANSIENT_FIRST         (HR_PERMANENT)
+#define MAX_LOADED_OBJECTS      3
+#define TRANSIENT_LAST          (TRANSIENT_FIRST+MAX_LOADED_OBJECTS-1)
+/*
+ * TPMA_OBJECT Bits
+ */
+#define fixedTPM                ((1 << 1))
+#define stClear                 ((1 << 2))
+#define fixedParent             ((1 << 4))
+#define sensitiveDataOrigin     ((1 << 5))
+#define userWithAuth            ((1 << 6))
+#define adminWithPolicy         ((1 << 7))
+#define noDA                    ((1 << 10))
+#define encryptedDuplication    ((1 << 11))
+#define restricted              ((1 << 16))
+#define decrypt                 ((1 << 17))
+#define sign                    ((1 << 18))
+#endif
-- 
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 Dec 17 15:55:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gwr-0006AJ-4W; Wed, 17 Dec 2014 15:55:37 +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 1Y1Gwp-00069l-Sp
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:36 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	0D/76-02697-777A1945; Wed, 17 Dec 2014 15:55:35 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418831733!11045048!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 19424 invoked from network); 17 Dec 2014 15:55:34 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-206.messagelabs.com with SMTP;
	17 Dec 2014 15:55:34 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 17 Dec 2014 07:55:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="649193380"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 17 Dec 2014 07:55:32 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:48 -0500
Message-Id: <1418817108-5383-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 05/14] vTPM/TPM2: TPM 2.0 takes ownership and
	create SRK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TPM2_CreatePrimary is used to create a Primary Object under one of
the Primary Seeds or a Temporary Object under TPM_RH_NULL. The command
uses a TPM2B_PUBLIC as a template for the object to be created. The
command will create and load a Primary Object. The sensitive area is
not returned. Any type of object and attributes combination that is
allowed by TPM2_Create() may be created by this command. The constraints
on templates and parameters are the same as TPM2_Create() except that a
Primary Storage Key and a Temporary Storage Key are not constrained to
use the algorithms of their parents.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/init.c    | 71 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.h |  3 ++
 2 files changed, 74 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index f3aa02f..c654071 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -51,6 +51,7 @@
 #include "vtpm_disk.h"
 #include "tpm.h"
 #include "marshal.h"
+#include "tpm2.h"
 
 struct Opts {
    enum {
@@ -509,3 +510,73 @@ void vtpmmgr_shutdown(void)
 
    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager stopped.\n");
 }
+
+/* TPM 2.0 */
+
+static void tpm2_AuthArea_ctor(const char *authValue, UINT32 authLen,
+                               TPM_AuthArea *auth)
+{
+    auth->sessionHandle = TPM_RS_PW;
+    auth->nonce.size = 0;
+    auth->sessionAttributes = 1;
+    auth->auth.size = authLen;
+    memcpy(auth->auth.buffer, authValue, authLen);
+    auth->size = 9 + authLen;
+}
+
+TPM_RC tpm2_take_ownership(void)
+{
+    TPM_RC status = TPM_SUCCESS;
+
+    tpm2_AuthArea_ctor(NULL, 0, &vtpm_globals.pw_auth);
+
+    /* create SRK */
+    TPM2_CreatePrimary_Params_in in = {
+        .inSensitive = {
+            .size = 4,
+            .sensitive = {
+                .userAuth.size = 0,
+                .userAuth.buffer = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\
+                                     0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+                .data.size = 0,
+            },
+        },
+        .inPublic = {
+            .size = 60,
+            .publicArea = {
+                .type = TPM2_ALG_RSA,
+                .nameAlg = TPM2_ALG_SHA256,
+#define SRK_OBJ_ATTR (fixedTPM | fixedParent  | userWithAuth | \
+                      sensitiveDataOrigin | restricted | decrypt)
+                .objectAttributes = SRK_OBJ_ATTR,
+                .authPolicy.size = 0,
+                .parameters.rsaDetail = {
+                    .symmetric = {
+                    .algorithm = TPM2_ALG_AES,
+                    .keyBits.aes = AES_KEY_SIZES_BITS,
+                    .mode.aes = TPM2_ALG_CFB,
+                    },
+                .scheme = { TPM2_ALG_NULL },
+                .keyBits = RSA_KEY_SIZES_BITS,
+                .exponent = 0,
+                },
+                .unique.rsa.size = 0,
+            },
+        },
+            .outsideInfo.size = 0,
+            .creationPCR.count = 0,
+    };
+
+    TPMTRYRETURN(TPM2_CreatePrimary(TPM_RH_OWNER,&in,
+                                    &vtpm_globals.srk_handle, NULL));
+    vtpmloginfo(VTPM_LOG_VTPM, "SRK handle: 0x%X\n", vtpm_globals.srk_handle);
+    {
+        const char data[20] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\
+                                0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+        tpm2_AuthArea_ctor(data, 20, &vtpm_globals.srk_auth_area);
+    }
+    /*end create SRK*/
+
+abort_egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 0d0c604..95519ba 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -93,4 +93,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
    return ctr_drbg_random(&vtpm_globals.ctr_drbg, bytes, num_bytes) == 0 ? 0 : TPM_FAIL;
 }
 
+/* TPM 2.0 */
+TPM_RC tpm2_take_ownership(void);
+
 #endif
-- 
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 Dec 17 15:55:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gwi-00067o-KP; Wed, 17 Dec 2014 15:55:28 +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 1Y1Gwf-00067X-QQ
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:26 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	7A/88-14214-D67A1945; Wed, 17 Dec 2014 15:55:25 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418831723!13943009!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27365 invoked from network); 17 Dec 2014 15:55:24 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-206.messagelabs.com with SMTP;
	17 Dec 2014 15:55:24 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2014 07:55:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="649193273"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 17 Dec 2014 07:55:13 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:24 -0500
Message-Id: <1418817084-5194-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
MIME-Version: 1.0
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	tim@xen.org, ian.jackson@eu.citrix.com, jbeulich@suse.com,
	Quan Xu <quan.xu@intel.com>, samuel.thibault@ens-lyon.org,
	dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH v2 00/14] Enable vTPM subsystem on TPM 2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


This series of patch enable the virtual Trusted Platform Module (vTPM)
subsystem for Xen on TPM 2.0.

Noted, functionality for a virtual guest operating system (a DomU) is still
TPM 1.2. The main modifcation is on vtpmmgr-stubdom. The challenge is that
TPM 2.0 is not backward compatible with TPM 1.2.

------------------------------
DESIGN OVERVIEW
------------------------------
The architecture of vTPM subsystem on TPM 2.0 is described below:

+------------------+
|    Linux DomU    | ...
|       |  ^       |
|       v  |       |
|   xen-tpmfront   |
+------------------+
        |  ^
        v  |
+------------------+
| mini-os/tpmback  |
|       |  ^       |
|       v  |       |
|  vtpm-stubdom    | ...
|       |  ^       |
|       v  |       |
| mini-os/tpmfront |
+------------------+
        |  ^
        v  |
+------------------+
| mini-os/tpmback  |
|       |  ^       |
|       v  |       |
| vtpmmgr-stubdom  |
|       |  ^       |
|       v  |       |
| mini-os/tpm2_tis |
+------------------+
        |  ^
        v  |
+------------------+
| Hardware TPM 2.0 |
+------------------+
 * Linux DomU: The Linux based guest that wants to use a vTPM. There many be
               more than one of these.

 * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver
                    provides vTPM access to a para-virtualized Linux based DomU.

 * 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.  This domain regulates
               access to the physical TPM on the system and secures the
               persistent state of each vTPM.

 * mini-os/tpm2_tis: Mini-os TPM version 2.0 TPM Interface Specification (TIS)
                    driver. This driver used by vtpmmgr-stubdom to talk directly
                    to the hardware TPM 2.0. Communication is facilitated by mapping
                    hardware memory pages into vtpmmgr-stubdom.

 * Hardware TPM 2.0: The physical TPM 2.0 that is soldered onto the motherboard.

------------------------------
Key Hierarchy
------------------------------

    +------------------+
    |  vTPM's secrets  | ...
    +------------------+
            |  ^
            |  |(Bind / Unbind)
- - - - -  -v  |- - - - - - - - TPM 2.0
    +------------------+
    |        SK        +
    +------------------+
            |  ^
            v  |
    +------------------+
    |       SRK        |
    +------------------+
            |  ^
            v  |
    +------------------+
    | TPM 2.0 Storage  |
    |   Primary Seed   |
    +------------------+
------------------------------
INSTALLATION
------------------------------

Prerequisites:
--------------
You must have an x86 machine with a TPM on the motherboard.  The only extra
software requirement for compiling vTPM is cmake.  You must use libxl to manage
domains with vTPMs; 'xm' is deprecated and does not support vTPMs.

Compiling the Xen tree:
-----------------------

Compile and install the Xen tree as usual; be sure that the vTPM domains are
enabled when you run configure.

Compiling the LINUX dom0 kernel:
--------------------------------

Because the TPM manager uses direct access to the physical TPM, it may interfere
with access to the TPM by dom0.  The simplest solution for this is to prevent
dom0 from accessing the physical TPM by compiling the kernel without a driver or
blacklisting the module.

Compiling the LINUX domU kernel:
--------------------------------

The domU kernel used by domains with vtpms must include the xen-tpmfront.ko
driver. It can be built directly into the kernel or as a module; however, some
features such as IMA require the TPM to be built in to the kernel.


CONFIG_TCG_TPM=y
CONFIG_TCG_XEN=y

------------------------------
VTPM MANAGER SETUP
------------------------------

Manager disk image setup:
-------------------------

The vTPM Manager requires a disk image to store its encrypted data. The image
does not require a filesystem and can live anywhere on the host disk. The image
is not large; the Xen 4.5 vtpmmgr is limited to using the first 2MB of the image
but can support more than 20,000 vTPMs.

 dd if=/dev/zero of=/home/vtpm2/vmgr bs=16M count=1

Manager config file:
--------------------

The vTPM Manager domain (vtpmmgr-stubdom) must be started like any other Xen
virtual machine and requires a config file.  The manager requires a disk image
for storage and permission to access the hardware memory pages for the TPM. The
disk must be presented as "hda", and the TPM memory pages are passed using the
iomem configuration parameter. The TPM TIS uses 5 pages of IO memory (one per
locality) that start at physical address 0xfed40000. By default, the TPM manager
uses locality 0 (so only the page at 0xfed40 is needed).

Add:
..
     extra="tpm2"
..
extra option to launch vtpmmgr-stubdom domain on TPM 2.0, and ignore it on TPM
1.x. for example:

    kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
    memory=128
    disk=["file:/home/vtpm2/vmgr,hda,w"]
    name="vtpmmgr"
    iomem=["fed40,5"]
    extra="tpm2"


------------------------------
VTPM AND LINUX PVM SETUP
------------------------------
vTPM disk image setup:
----------------------

The vTPM requires a disk image to store its persistent data (RSA keys, NVRAM,
etc). The image does not require a filesystem. The image does not need to be
large; 2 Mb should be sufficient.

    dd if=/dev/zero of=/home/vtpm2/vtpm0 bs=2M count=1

vTPM config file:
-----------------

The vTPM domain requires a configuration file like any other domain. The vTPM
requires a disk image for storage and a TPM frontend driver to communicate with
the manager.  You are required to generate a uuid for this vtpm, which is
specified on the "vtpm=" line that describes its connection to the vTPM Manager.
for example:

    kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
    memory=8
    disk=["file:/home/vtpm2/vtpm0,hda,w"]
    name="vtpm0"
    vtpm=["backend=vtpmmgr,uuid=914fe389-e2c5-44e6-993f-2189637cf1de"]

If you wish to clear the vTPM data you can either recreate the disk image or
change the uuid.

Linux Guest config file:
------------------------
The Linux guest config file needs to be modified to include the Linux tpmfront
driver. Add the following line:

vtpm=["backend=vtpm0"]

Currently only Linux guests are supported (PV or HVM with PV drivers). My series
of patch for HVM virtual mahcine are still being reviewed and modifcated.

Using the vTPM in the guest:
----------------------------

If xen-tpmfront was compiled as a module, it must be loaded it in the guest.

# modprobe xen-tpmfront

After the Linux domain boots and the xen-tpmfront driver is loaded, you should
see the following on the vtpm console:

Info: VTPM attached to Frontend X/Y

You can quickly test the vTPM by using the sysfs interface:

# cat /sys/devices/vtpm-0/pubek
# cat /sys/devices/vtpm-0/pcrs
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

You should also see the command being sent to the vtpm console as well as the
vtpm saving its state. You should see the vtpm key being encrypted and stored on
the vtpmmgr console.

You may wish to write a script to start your vtpm and guest together and to
destroy the vtpm when the guest shuts down.

------------------------------
INTEGRATION WITH PV-GRUB
------------------------------

The vTPM currently starts up with all PCRs set to their default values (all
zeros for the lower 16).  This means that any decisions about the
trustworthiness of the created domain must be made based on the environment that
created the vTPM and the domU; for example, a system that only constructs images
using a trusted configuration and guest kernel be able to provide guarantees
about the guests and any measurements done that kernel (such as the IMA TCB
log).  Guests wishing to use a custom kernel in such a secure environment are
often started using the pv-grub bootloader as the kernel, which then can load
the untrusted kernel without needing to parse an untrusted filesystem and kernel
in dom0.  If the pv-grub stub domain succeeds in connecting to a vTPM, it will
extend the hash of the kernel that it boots into PCR #4, and will extend the
command line and initrd into PCR #5 before booting so that a domU booted in this
way can attest to its early boot state.

------------------------------
REFERENCES
------------------------------

Berlios TPM Emulator:
http://tpm-emulator.berlios.de/
Xen docs/misc/vtpm.txt
Xen docs/misc/vtpm-platforms.txt
Xen docs/misc/vtpmmgr.txt


--Changes in V2:
  1. Record some infomation in docs/misc/vtpmmgr.txt.
  2. Add TPM 2.0 PCRs read.
  3. Bind/Unbind the measurements of the hypervisor and other 
     TCB components.
  4. Change extra option from '--tpm2' to 'tpm2'



Quan Xu (14):
  vTPM/TPM2: Add TPM 2.0 data structures and commands definition
  vTPM/TPM2: TPM 2.0 data structures marshal
  vTPM/TPM2: Add global data in vtpm_globals{}
  vTPM/TPM2: Add TPM 2.0 Exposed APIs
  vTPM/TPM2: TPM 2.0 takes ownership and create SRK
  vTPM/TPM2: Create and load SK on TPM 2.0
  vTPM/TPM2: TPM2.0 TIS initialization and self test.
  vTPM/TPM2: Add main entrance vtpmmgr2_init()
  vTPM/TPM2: Support 'tpm2' extra command line.
  vTPM/TPM2: TPM 2.0 PCRs read
  vTPM/TPM2: Support TPM 2.0 bind and unbind data
  vTPM/TPM2: Bind group keys and sectors data on disk
  vTPM/TPM2: Unind group keys and sectors data on disk
  vTPM/TPM2: Record some infomation in docs/misc/vtpmmgr.txt about

 docs/misc/vtpmmgr.txt            | 150 +++++-
 extras/mini-os/include/tpm_tis.h |   1 +
 extras/mini-os/tpm_tis.c         | 156 +++++++
 stubdom/vtpmmgr/Makefile         |   2 +-
 stubdom/vtpmmgr/disk_read.c      |  16 +-
 stubdom/vtpmmgr/disk_tpm.c       |  42 +-
 stubdom/vtpmmgr/disk_tpm.h       |   4 +
 stubdom/vtpmmgr/disk_write.c     |  13 +-
 stubdom/vtpmmgr/init.c           | 315 +++++++++++++
 stubdom/vtpmmgr/tpm2.c           | 455 ++++++++++++++++++
 stubdom/vtpmmgr/tpm2.h           | 104 +++++
 stubdom/vtpmmgr/tpm2_marshal.h   | 673 +++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2_types.h     | 980 +++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.c        |  46 +-
 stubdom/vtpmmgr/vtpmmgr.h        |  29 ++
 15 files changed, 2972 insertions(+), 14 deletions(-)
 create mode 100644 stubdom/vtpmmgr/tpm2.c
 create mode 100644 stubdom/vtpmmgr/tpm2.h
 create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h
 create mode 100644 stubdom/vtpmmgr/tpm2_types.h

-- 
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 Dec 17 15:55:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gwr-0006AJ-4W; Wed, 17 Dec 2014 15:55:37 +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 1Y1Gwp-00069l-Sp
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:36 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	0D/76-02697-777A1945; Wed, 17 Dec 2014 15:55:35 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418831733!11045048!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 19424 invoked from network); 17 Dec 2014 15:55:34 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-206.messagelabs.com with SMTP;
	17 Dec 2014 15:55:34 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 17 Dec 2014 07:55:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="649193380"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 17 Dec 2014 07:55:32 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:48 -0500
Message-Id: <1418817108-5383-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 05/14] vTPM/TPM2: TPM 2.0 takes ownership and
	create SRK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TPM2_CreatePrimary is used to create a Primary Object under one of
the Primary Seeds or a Temporary Object under TPM_RH_NULL. The command
uses a TPM2B_PUBLIC as a template for the object to be created. The
command will create and load a Primary Object. The sensitive area is
not returned. Any type of object and attributes combination that is
allowed by TPM2_Create() may be created by this command. The constraints
on templates and parameters are the same as TPM2_Create() except that a
Primary Storage Key and a Temporary Storage Key are not constrained to
use the algorithms of their parents.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/init.c    | 71 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.h |  3 ++
 2 files changed, 74 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index f3aa02f..c654071 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -51,6 +51,7 @@
 #include "vtpm_disk.h"
 #include "tpm.h"
 #include "marshal.h"
+#include "tpm2.h"
 
 struct Opts {
    enum {
@@ -509,3 +510,73 @@ void vtpmmgr_shutdown(void)
 
    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager stopped.\n");
 }
+
+/* TPM 2.0 */
+
+static void tpm2_AuthArea_ctor(const char *authValue, UINT32 authLen,
+                               TPM_AuthArea *auth)
+{
+    auth->sessionHandle = TPM_RS_PW;
+    auth->nonce.size = 0;
+    auth->sessionAttributes = 1;
+    auth->auth.size = authLen;
+    memcpy(auth->auth.buffer, authValue, authLen);
+    auth->size = 9 + authLen;
+}
+
+TPM_RC tpm2_take_ownership(void)
+{
+    TPM_RC status = TPM_SUCCESS;
+
+    tpm2_AuthArea_ctor(NULL, 0, &vtpm_globals.pw_auth);
+
+    /* create SRK */
+    TPM2_CreatePrimary_Params_in in = {
+        .inSensitive = {
+            .size = 4,
+            .sensitive = {
+                .userAuth.size = 0,
+                .userAuth.buffer = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\
+                                     0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+                .data.size = 0,
+            },
+        },
+        .inPublic = {
+            .size = 60,
+            .publicArea = {
+                .type = TPM2_ALG_RSA,
+                .nameAlg = TPM2_ALG_SHA256,
+#define SRK_OBJ_ATTR (fixedTPM | fixedParent  | userWithAuth | \
+                      sensitiveDataOrigin | restricted | decrypt)
+                .objectAttributes = SRK_OBJ_ATTR,
+                .authPolicy.size = 0,
+                .parameters.rsaDetail = {
+                    .symmetric = {
+                    .algorithm = TPM2_ALG_AES,
+                    .keyBits.aes = AES_KEY_SIZES_BITS,
+                    .mode.aes = TPM2_ALG_CFB,
+                    },
+                .scheme = { TPM2_ALG_NULL },
+                .keyBits = RSA_KEY_SIZES_BITS,
+                .exponent = 0,
+                },
+                .unique.rsa.size = 0,
+            },
+        },
+            .outsideInfo.size = 0,
+            .creationPCR.count = 0,
+    };
+
+    TPMTRYRETURN(TPM2_CreatePrimary(TPM_RH_OWNER,&in,
+                                    &vtpm_globals.srk_handle, NULL));
+    vtpmloginfo(VTPM_LOG_VTPM, "SRK handle: 0x%X\n", vtpm_globals.srk_handle);
+    {
+        const char data[20] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\
+                                0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+        tpm2_AuthArea_ctor(data, 20, &vtpm_globals.srk_auth_area);
+    }
+    /*end create SRK*/
+
+abort_egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 0d0c604..95519ba 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -93,4 +93,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
    return ctr_drbg_random(&vtpm_globals.ctr_drbg, bytes, num_bytes) == 0 ? 0 : TPM_FAIL;
 }
 
+/* TPM 2.0 */
+TPM_RC tpm2_take_ownership(void);
+
 #endif
-- 
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 Dec 17 15:55:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gwj-00067z-4W; Wed, 17 Dec 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 <quan.xu@intel.com>) id 1Y1Gwg-00067f-Vx
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:27 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	E5/64-11581-E67A1945; Wed, 17 Dec 2014 15:55:26 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418831723!13943009!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28740 invoked from network); 17 Dec 2014 15:55:25 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-206.messagelabs.com with SMTP;
	17 Dec 2014 15:55:25 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2014 07:55:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="639067287"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 17 Dec 2014 07:55:17 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:33 -0500
Message-Id: <1418817093-5231-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 01/14] vTPM/TPM2: Add TPM 2.0 data structures
	and commands 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

Add TPM 2.0 data structures on Trusted Platform Module Library Part 2:
Structures and Trust Platform Module Library Part 3: Commands.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/tpm2_types.h | 978 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 978 insertions(+)
 create mode 100644 stubdom/vtpmmgr/tpm2_types.h

diff --git a/stubdom/vtpmmgr/tpm2_types.h b/stubdom/vtpmmgr/tpm2_types.h
new file mode 100644
index 0000000..214335c
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2_types.h
@@ -0,0 +1,978 @@
+#ifndef __TPM2_TYPES_H__
+#define __TPM2_TYPES_H__
+
+#include <stdlib.h>
+#include <stdint.h>
+
+// "implementation.h"
+// Table 212 -- Logic Values
+#define    YES      1
+#define    NO       0
+#ifndef    TRUE
+#define    TRUE     1
+#endif
+#ifndef    FALSE
+#define    FALSE    0
+#endif
+#ifndef    true
+#define    true     1
+#endif
+#ifndef    false
+#define    false    0
+#endif
+#define    SET      1
+#define    CLEAR    0
+
+
+// Table 214 -- Implemented Algorithms
+#define    ALG_RSA               YES    // 1
+#define    ALG_DES               NO     // 0
+#define    ALG__3DES             NO     // 0
+#define    ALG_SHA1              YES    // 1
+#define    ALG_HMAC              YES    // 1
+#define    ALG_AES               YES    // 1
+#define    ALG_MGF1              YES    // 1
+#define    ALG_XOR               YES    // 1
+#define    ALG_KEYEDHASH         YES    // 1
+#define    ALG_SHA256            YES    // 1
+#define    ALG_SHA384            YES    // 0
+#define    ALG_SHA512            YES    // 0
+#define    ALG_WHIRLPOOL512      YES    // 0
+#define    ALG_SM3_256           YES    // 1
+#define    ALG_SM4               YES    // 1
+#define    ALG_RSASSA            YES    // 1
+#define    ALG_RSAES             YES    // 1
+#define    ALG_RSAPSS            YES    // 1
+#define    ALG_OAEP              YES    // 1
+#define    ALG_ECC               YES    // 1
+#define    ALG_CFB               YES    // 1
+#define    ALG_ECDH              YES    // 1
+#define    ALG_ECDSA             YES    // 1
+#define    ALG_ECDAA             YES    // 1
+#define    ALG_SM2               YES    // 1
+#define    ALG_ECSCHNORR         YES    // 1
+#define    ALG_SYMCIPHER         YES    // 1
+#define    ALG_KDF1_SP800_56a    YES    // 1
+#define    ALG_KDF2              NO     // 0
+#define    ALG_KDF1_SP800_108    YES    // 1
+#define    ALG_CTR               YES    // 1
+#define    ALG_OFB               YES    // 1
+#define    ALG_CBC               YES    // 1
+
+#define HASH_COUNT (ALG_SHA1+ALG_SHA256+ALG_SHA384+ALG_SHA512+ALG_WHIRLPOOL512+ALG_SM3_256)
+
+// Table 216 -- RSA Algorithm Constants
+#define    RSA_KEY_SIZES_BITS    2048    // {1024,2048}
+#define    MAX_RSA_KEY_BITS      2048
+#define    MAX_RSA_KEY_BYTES     ((MAX_RSA_KEY_BITS + 7) / 8)    // 256
+
+// Table 218 -- AES Algorithm Constants
+#define    AES_KEY_SIZES_BITS          128
+#define    MAX_AES_KEY_BITS            128
+#define    MAX_AES_BLOCK_SIZE_BYTES    16
+#define    MAX_AES_KEY_BYTES           ((MAX_AES_KEY_BITS + 7) / 8)    // 16
+
+
+// Table 220 -- Symmetric Algorithm Constants
+#define    MAX_SYM_KEY_BITS      MAX_AES_KEY_BITS    // 128
+#define    MAX_SYM_KEY_BYTES     MAX_AES_KEY_BYTES    // 16
+#define    MAX_SYM_BLOCK_SIZE    MAX_AES_BLOCK_SIZE_BYTES    // 16
+
+#define    MAX_SYM_DATA         128
+#define    MAX_ECC_KEY_BITS     256
+#define    MAX_ECC_KEY_BYTES    ((MAX_ECC_KEY_BITS + 7) / 8)
+
+
+typedef unsigned char BYTE;
+typedef unsigned char BOOL;
+typedef uint8_t       UINT8;
+typedef uint16_t      UINT16;
+typedef uint32_t      UINT32;
+typedef uint64_t      UINT64;
+
+// TPM2 command code
+
+typedef UINT32 TPM_CC;
+#define    TPM_CC_FIRST                         (TPM_CC)(0x0000011F)
+#define    TPM_CC_PP_FIRST                      (TPM_CC)(0x0000011F)
+#define    TPM_CC_NV_UndefineSpaceSpecial       (TPM_CC)(0x0000011F)
+#define    TPM_CC_EvictControl                  (TPM_CC)(0x00000120)
+#define    TPM_CC_HierarchyControl              (TPM_CC)(0x00000121)
+#define    TPM_CC_NV_UndefineSpace              (TPM_CC)(0x00000122)
+#define    TPM_CC_ChangeEPS                     (TPM_CC)(0x00000124)
+#define    TPM_CC_ChangePPS                     (TPM_CC)(0x00000125)
+#define    TPM_CC_Clear                         (TPM_CC)(0x00000126)
+#define    TPM_CC_ClearControl                  (TPM_CC)(0x00000127)
+#define    TPM_CC_ClockSet                      (TPM_CC)(0x00000128)
+#define    TPM_CC_HierarchyChangeAuth           (TPM_CC)(0x00000129)
+#define    TPM_CC_NV_DefineSpace                (TPM_CC)(0x0000012A)
+#define    TPM_CC_PCR_Allocate                  (TPM_CC)(0x0000012B)
+#define    TPM_CC_PCR_SetAuthPolicy             (TPM_CC)(0x0000012C)
+#define    TPM_CC_PP_Commands                   (TPM_CC)(0x0000012D)
+#define    TPM_CC_SetPrimaryPolicy              (TPM_CC)(0x0000012E)
+#define    TPM_CC_FieldUpgradeStart             (TPM_CC)(0x0000012F)
+#define    TPM_CC_ClockRateAdjust               (TPM_CC)(0x00000130)
+#define    TPM_CC_CreatePrimary                 (TPM_CC)(0x00000131)
+#define    TPM_CC_NV_GlobalWriteLock            (TPM_CC)(0x00000132)
+#define    TPM_CC_PP_LAST                       (TPM_CC)(0x00000132)
+#define    TPM_CC_GetCommandAuditDigest         (TPM_CC)(0x00000133)
+#define    TPM_CC_NV_Increment                  (TPM_CC)(0x00000134)
+#define    TPM_CC_NV_SetBits                    (TPM_CC)(0x00000135)
+#define    TPM_CC_NV_Extend                     (TPM_CC)(0x00000136)
+#define    TPM_CC_NV_Write                      (TPM_CC)(0x00000137)
+#define    TPM_CC_NV_WriteLock                  (TPM_CC)(0x00000138)
+#define    TPM_CC_DictionaryAttackLockReset     (TPM_CC)(0x00000139)
+#define    TPM_CC_DictionaryAttackParameters    (TPM_CC)(0x0000013A)
+#define    TPM_CC_NV_ChangeAuth                 (TPM_CC)(0x0000013B)
+#define    TPM_CC_PCR_Event                     (TPM_CC)(0x0000013C)
+#define    TPM_CC_PCR_Reset                     (TPM_CC)(0x0000013D)
+#define    TPM_CC_SequenceComplete              (TPM_CC)(0x0000013E)
+#define    TPM_CC_SetAlgorithmSet               (TPM_CC)(0x0000013F)
+#define    TPM_CC_SetCommandCodeAuditStatus     (TPM_CC)(0x00000140)
+#define    TPM_CC_FieldUpgradeData              (TPM_CC)(0x00000141)
+#define    TPM_CC_IncrementalSelfTest           (TPM_CC)(0x00000142)
+#define    TPM_CC_SelfTest                      (TPM_CC)(0x00000143)
+#define    TPM_CC_Startup                       (TPM_CC)(0x00000144)
+#define    TPM_CC_Shutdown                      (TPM_CC)(0x00000145)
+#define    TPM_CC_StirRandom                    (TPM_CC)(0x00000146)
+#define    TPM_CC_ActivateCredential            (TPM_CC)(0x00000147)
+#define    TPM_CC_Certify                       (TPM_CC)(0x00000148)
+#define    TPM_CC_PolicyNV                      (TPM_CC)(0x00000149)
+#define    TPM_CC_CertifyCreation               (TPM_CC)(0x0000014A)
+#define    TPM_CC_Duplicate                     (TPM_CC)(0x0000014B)
+#define    TPM_CC_GetTime                       (TPM_CC)(0x0000014C)
+#define    TPM_CC_GetSessionAuditDigest         (TPM_CC)(0x0000014D)
+#define    TPM_CC_NV_Read                       (TPM_CC)(0x0000014E)
+#define    TPM_CC_NV_ReadLock                   (TPM_CC)(0x0000014F)
+#define    TPM_CC_ObjectChangeAuth              (TPM_CC)(0x00000150)
+#define    TPM_CC_PolicySecret                  (TPM_CC)(0x00000151)
+#define    TPM_CC_Rewrap                        (TPM_CC)(0x00000152)
+#define    TPM_CC_Create                        (TPM_CC)(0x00000153)
+#define    TPM_CC_ECDH_ZGen                     (TPM_CC)(0x00000154)
+#define    TPM_CC_HMAC                          (TPM_CC)(0x00000155)
+#define    TPM_CC_Import                        (TPM_CC)(0x00000156)
+#define    TPM_CC_Load                          (TPM_CC)(0x00000157)
+#define    TPM_CC_Quote                         (TPM_CC)(0x00000158)
+#define    TPM_CC_RSA_Decrypt                   (TPM_CC)(0x00000159)
+#define    TPM_CC_HMAC_Start                    (TPM_CC)(0x0000015B)
+#define    TPM_CC_SequenceUpdate                (TPM_CC)(0x0000015C)
+#define    TPM_CC_Sign                          (TPM_CC)(0x0000015D)
+#define    TPM_CC_Unseal                        (TPM_CC)(0x0000015E)
+#define    TPM_CC_PolicySigned                  (TPM_CC)(0x00000160)
+#define    TPM_CC_ContextLoad                   (TPM_CC)(0x00000161)
+#define    TPM_CC_ContextSave                   (TPM_CC)(0x00000162)
+#define    TPM_CC_ECDH_KeyGen                   (TPM_CC)(0x00000163)
+#define    TPM_CC_EncryptDecrypt                (TPM_CC)(0x00000164)
+#define    TPM_CC_FlushContext                  (TPM_CC)(0x00000165)
+#define    TPM_CC_LoadExternal                  (TPM_CC)(0x00000167)
+#define    TPM_CC_MakeCredential                (TPM_CC)(0x00000168)
+#define    TPM_CC_NV_ReadPublic                 (TPM_CC)(0x00000169)
+#define    TPM_CC_PolicyAuthorize               (TPM_CC)(0x0000016A)
+#define    TPM_CC_PolicyAuthValue               (TPM_CC)(0x0000016B)
+#define    TPM_CC_PolicyCommandCode             (TPM_CC)(0x0000016C)
+#define    TPM_CC_PolicyCounterTimer            (TPM_CC)(0x0000016D)
+#define    TPM_CC_PolicyCpHash                  (TPM_CC)(0x0000016E)
+#define    TPM_CC_PolicyLocality                (TPM_CC)(0x0000016F)
+#define    TPM_CC_PolicyNameHash                (TPM_CC)(0x00000170)
+#define    TPM_CC_PolicyOR                      (TPM_CC)(0x00000171)
+#define    TPM_CC_PolicyTicket                  (TPM_CC)(0x00000172)
+#define    TPM_CC_ReadPublic                    (TPM_CC)(0x00000173)
+#define    TPM_CC_RSA_Encrypt                   (TPM_CC)(0x00000174)
+#define    TPM_CC_StartAuthSession              (TPM_CC)(0x00000176)
+#define    TPM_CC_VerifySignature               (TPM_CC)(0x00000177)
+#define    TPM_CC_ECC_Parameters                (TPM_CC)(0x00000178)
+#define    TPM_CC_FirmwareRead                  (TPM_CC)(0x00000179)
+#define    TPM_CC_GetCapability                 (TPM_CC)(0x0000017A)
+#define    TPM_CC_GetRandom                     (TPM_CC)(0x0000017B)
+#define    TPM_CC_GetTestResult                 (TPM_CC)(0x0000017C)
+#define    TPM_CC_Hash                          (TPM_CC)(0x0000017D)
+#define    TPM_CC_PCR_Read                      (TPM_CC)(0x0000017E)
+#define    TPM_CC_PolicyPCR                     (TPM_CC)(0x0000017F)
+#define    TPM_CC_PolicyRestart                 (TPM_CC)(0x00000180)
+#define    TPM_CC_ReadClock                     (TPM_CC)(0x00000181)
+#define    TPM_CC_PCR_Extend                    (TPM_CC)(0x00000182)
+#define    TPM_CC_PCR_SetAuthValue              (TPM_CC)(0x00000183)
+#define    TPM_CC_NV_Certify                    (TPM_CC)(0x00000184)
+#define    TPM_CC_EventSequenceComplete         (TPM_CC)(0x00000185)
+#define    TPM_CC_HashSequenceStart             (TPM_CC)(0x00000186)
+#define    TPM_CC_PolicyPhysicalPresence        (TPM_CC)(0x00000187)
+#define    TPM_CC_PolicyDuplicationSelect       (TPM_CC)(0x00000188)
+#define    TPM_CC_PolicyGetDigest               (TPM_CC)(0x00000189)
+#define    TPM_CC_TestParms                     (TPM_CC)(0x0000018A)
+#define    TPM_CC_Commit                        (TPM_CC)(0x0000018B)
+#define    TPM_CC_PolicyPassword                (TPM_CC)(0x0000018C)
+#define    TPM_CC_SM2_ZGen                      (TPM_CC)(0x0000018D)
+#define    TPM_CC_LAST                          (TPM_CC)(0x0000018D)
+
+
+//TPM_RC
+typedef UINT32 TPM_RC;
+
+// TPM_ST Constants
+typedef UINT16 TPM_ST;
+#define    TPM_ST_NULL                    (TPM_ST)(0X8000)
+#define    TPM_ST_NO_SESSIONS             (TPM_ST)(0x8001)
+#define    TPM_ST_SESSIONS                (TPM_ST)(0x8002)
+
+
+// TPM Handle types
+typedef UINT32 TPM_HANDLE;
+typedef UINT8 TPM_HT;
+
+
+// TPM_RH Constants
+typedef UINT32 TPM_RH;
+
+#define    TPM_RH_FIRST          (TPM_RH)(0x40000000)
+#define    TPM_RH_SRK            (TPM_RH)(0x40000000)
+#define    TPM_RH_OWNER          (TPM_RH)(0x40000001)
+#define    TPM_RS_PW             (TPM_RH)(0x40000009)
+#define    TPM_RH_LOCKOUT        (TPM_RH)(0x4000000A)
+#define    TPM_RH_ENDORSEMENT    (TPM_RH)(0x4000000B)
+#define    TPM_RH_PLATFORM       (TPM_RH)(0x4000000C)
+#define    TPM_RH_LAST           (TPM_RH)(0x4000000C)
+
+// Table 4 -- DocumentationClarity Types <I/O>
+typedef UINT32    TPM_ALGORITHM_ID;
+typedef UINT32    TPM_MODIFIER_INDICATOR;
+typedef UINT32    TPM_SESSION_OFFSET;
+typedef UINT16    TPM_KEY_SIZE;
+typedef UINT16    TPM_KEY_BITS;
+typedef UINT64    TPM_SYSTEM_ADDRESS;
+typedef UINT32    TPM_SPEC;
+
+// Table 29 -- TPMA_ALGORITHM Bits <I/O>
+typedef struct {
+    unsigned int asymmetric:1;
+    unsigned int symmetric:1;
+    unsigned int hash:1;
+    unsigned int object:1;
+    unsigned int reserved5:4;
+    unsigned int signing:1;
+    unsigned int encrypting:1;
+    unsigned int method:1;
+    unsigned int reserved9:21;
+} TPMA_ALGORITHM;
+
+typedef UINT32 TPMA_OBJECT;
+typedef BYTE TPMA_SESSION;
+typedef BYTE TPMA_LOCALITY;
+
+// Table 37 -- TPMI_YES_NO Type <I/O>
+typedef BYTE TPMI_YES_NO;
+
+typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
+
+// Table 38 -- TPMI_DH_OBJECT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_OBJECT;
+
+// Table 39 -- TPMI_DH_PERSISTENT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_PERSISTENT;
+
+// Table 42 -- TPMI_SH_AUTH_SESSION Type <I/O>
+typedef TPM_HANDLE TPMI_SH_AUTH_SESSION;
+
+// Table 40 -- TPMI_DH_ENTITY Type <I>
+typedef TPM_HANDLE TPMI_DH_ENTITY;
+
+// Table 45 -- TPMI_DH_CONTEXT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_CONTEXT;
+
+// Table 46 -- TPMI_RH_HIERARCHY Type <I/O>
+typedef TPM_HANDLE TPMI_RH_HIERARCHY;
+
+// Table 47 -- TPMI_RH_HIERARCHY_AUTH Type <I>
+typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
+
+// Table 48 -- TPMI_RH_PLATFORM Type <I>
+typedef TPM_HANDLE TPMI_RH_PLATFORM;
+
+// Table 49 -- TPMI_RH_OWNER Type <I>
+typedef TPM_HANDLE TPMI_RH_OWNER;
+
+// Table 50 -- TPMI_RH_ENDORSEMENT Type <I>
+typedef TPM_HANDLE TPMI_RH_ENDORSEMENT;
+
+// Table 51 -- TPMI_RH_PROVISION Type <I>
+typedef TPM_HANDLE TPMI_RH_PROVISION;
+
+// Table 52 -- TPMI_RH_CLEAR Type <I>
+typedef TPM_HANDLE TPMI_RH_CLEAR;
+
+// Table 54 -- TPMI_RH_LOCKOUT Type <I>
+typedef TPM_HANDLE TPMI_RH_LOCKOUT;
+
+// Table 7 -- TPM_ALG_ID
+typedef UINT16 TPM_ALG_ID;
+typedef UINT16 TPM_ALG_ID;
+
+#define    TPM2_ALG_ERROR             (TPM_ALG_ID)(0x0000) // a: ; D:
+#define    TPM2_ALG_FIRST             (TPM_ALG_ID)(0x0001) // a: ; D:
+#if ALG_RSA == YES || ALG_ALL == YES
+#define    TPM2_ALG_RSA               (TPM_ALG_ID)(0x0001) // a: A O; D:
+#endif
+#if ALG_DES == YES || ALG_ALL == YES
+#define    TPM2_ALG_DES               (TPM_ALG_ID)(0x0002) // a: S; D:
+#endif
+#define    TPM2_ALG_SHA1              (TPM_ALG_ID)(0x0004) // a: H; D:
+#if ALG_HMAC == YES || ALG_ALL == YES
+#define    TPM2_ALG_HMAC              (TPM_ALG_ID)(0x0005) // a: H X; D:
+#endif
+#if ALG_AES == YES || ALG_ALL == YES
+#define    TPM2_ALG_AES               (TPM_ALG_ID)(0x0006) // a: S; D:
+#endif
+#if ALG_XOR == YES || ALG_ALL == YES
+#define    TPM2_ALG_XOR               (TPM_ALG_ID)(0x000A) // a: H S; D:
+#endif
+#if ALG_MGF1 == YES || ALG_ALL == YES
+#define    TPM2_ALG_MGF1              (TPM_ALG_ID)(0x0007) // a: H M; D:
+#endif
+#if ALG_KEYEDHASH == YES || ALG_ALL == YES
+#define    TPM2_ALG_KEYEDHASH         (TPM_ALG_ID)(0x0008) // a: H E X O; D:
+#endif
+#if ALG_SHA256 == YES || ALG_ALL == YES
+#define    TPM2_ALG_SHA256            (TPM_ALG_ID)(0x000B) // a: H; D:
+#endif
+#define    TPM2_ALG_NULL              (TPM_ALG_ID)(0x0010) // a: ; D:
+#if ALG_OAEP == YES || ALG_ALL == YES
+#define    TPM2_ALG_OAEP              (TPM_ALG_ID)(0x0017) // a: A E; D: RSA
+#endif
+#if ALG_ECC == YES || ALG_ALL == YES
+#define    TPM2_ALG_ECC               (TPM_ALG_ID)(0x0023) // a: A O; D:
+#endif
+#if ALG_SM4 == YES || ALG_ALL == YES
+#define    TPM2_ALG_SM4               (TPM_ALG_ID)(0x0013) // a: S; D:
+#endif
+#if ALG_SYMCIPHER == YES || ALG_ALL == YES
+#define    TPM2_ALG_SYMCIPHER         (TPM_ALG_ID)(0x0025) // a: O; D:
+#endif
+#if ALG_CFB == YES || ALG_ALL == YES
+#define    TPM2_ALG_CFB               (TPM_ALG_ID)(0x0043) // a: S E; D:
+#endif
+#define    TPM2_ALG_LAST              (TPM_ALG_ID)(0x0044)
+
+#define    SHA1_DIGEST_SIZE      20
+#define    SHA1_BLOCK_SIZE       64
+#define    SHA256_DIGEST_SIZE    32
+#define    SHA256_BLOCK_SIZE     64
+
+// Table 57 -- TPMI_ALG_ASYM Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_ASYM;
+
+// Table 56 -- TPMI_ALG_HASH Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_HASH;
+
+// Table 58 -- TPMI_ALG_SYM Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM;
+
+// Table 59 -- TPMI_ALG_SYM_OBJECT Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM_OBJECT;
+
+// Table 60 -- TPMI_ALG_SYM_MODE Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM_MODE;
+
+// Table 61 -- TPMI_ALG_KDF Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_KDF;
+
+// Table 62 -- TPMI_ALG_SIG_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SIG_SCHEME;
+
+// Table 65 -- TPMU_HA Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_SHA1
+    BYTE  sha1[SHA1_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA256
+    BYTE  sha256[SHA256_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SM3_256
+    BYTE  sm3_256[SM3_256_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA384
+    BYTE  sha384[SHA384_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA512
+    BYTE  sha512[SHA512_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_WHIRLPOOL512
+    BYTE  whirlpool[WHIRLPOOL512_DIGEST_SIZE];
+#endif
+
+} TPMU_HA;
+
+// Table 67 -- TPM2B_DIGEST Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[sizeof(TPMU_HA)];
+} TPM2B_DIGEST;
+
+// Table 69 -- TPM2B_NONCE Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_NONCE;
+
+typedef TPM2B_DIGEST    TPM2B_DATA;
+
+// Table 70 -- TPM2B_AUTH Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_AUTH;
+
+// Table 71 -- TPM2B_OPERAND Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_OPERAND;
+
+// Table 66 -- TPMT_HA Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    TPMU_HA          digest;
+} TPMT_HA;
+
+//Table 80 -- TPM2B_NAME Structure
+typedef struct {
+    UINT16 size;
+    BYTE name[sizeof(TPMT_HA)];
+} TPM2B_NAME;
+
+#define    IMPLEMENTATION_PCR   24
+#define    PLATFORM_PCR         24
+#define    PCR_SELECT_MAX       ((IMPLEMENTATION_PCR+7)/8)
+
+//Table 79 -- TPMS_PCR_SELECT Structure <I/O>
+typedef struct {
+    UINT8    sizeofSelect;
+    BYTE     pcrSelect[PCR_SELECT_MAX];
+} TPMS_PCR_SELECT;
+
+// Table 80 -- TPMS_PCR_SELECTION Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hash;
+    UINT8            sizeofSelect;
+    BYTE             pcrSelect[PCR_SELECT_MAX];
+} TPMS_PCR_SELECTION;
+
+// Table 83 -- TPMT_TK_CREATION Structure <I/O>
+typedef struct {
+    TPM_ST               tag;
+    TPMI_RH_HIERARCHY    hierarchy;
+    TPM2B_DIGEST         digest;
+} TPMT_TK_CREATION;
+
+// Table 96 -- Definition of TPML_DIGEST Structure <I/O>
+typedef struct {
+    UINT32               count;
+    TPM2B_DIGEST         digests[8];
+}TPML_DIGEST;
+
+// Table 97 -- TPML_PCR_SELECTION Structure <I/O>
+typedef struct {
+    UINT32                count;
+    TPMS_PCR_SELECTION    pcrSelections[HASH_COUNT];
+} TPML_PCR_SELECTION;
+
+// Table 119 -- TPMI_AES_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_AES_KEY_BITS;
+
+// Table 120 -- TPMI_SM4_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_SM4_KEY_BITS;
+
+// Table 121 -- TPMU_SYM_KEY_BITS Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_AES
+    TPMI_AES_KEY_BITS  aes;
+#endif
+#ifdef TPM2_ALG_SM4
+    TPMI_SM4_KEY_BITS  SM4;
+#endif
+    TPM_KEY_BITS  sym;
+#ifdef TPM2_ALG_XOR
+    TPMI_ALG_HASH  xor;
+#endif
+
+} TPMU_SYM_KEY_BITS;
+
+// Table 122 -- TPMU_SYM_MODE Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_AES
+    TPMI_ALG_SYM_MODE  aes;
+#endif
+#ifdef TPM2_ALG_SM4
+    TPMI_ALG_SYM_MODE  SM4;
+#endif
+    TPMI_ALG_SYM_MODE  sym;
+} TPMU_SYM_MODE ;
+
+// Table 124 -- TPMT_SYM_DEF Structure <I/O>
+typedef struct {
+    TPMI_ALG_SYM         algorithm;
+    TPMU_SYM_KEY_BITS    keyBits;
+    TPMU_SYM_MODE        mode;
+} TPMT_SYM_DEF;
+
+// Table 125 -- TPMT_SYM_DEF_OBJECT Structure <I/O>
+typedef struct {
+    TPMI_ALG_SYM_OBJECT    algorithm;
+    TPMU_SYM_KEY_BITS      keyBits;
+    TPMU_SYM_MODE          mode;
+} TPMT_SYM_DEF_OBJECT;
+
+// Table 126 -- TPM2B_SYM_KEY Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_SYM_KEY_BYTES];
+} TPM2B_SYM_KEY;
+
+// Table 127 -- TPMS_SYMCIPHER_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    sym;
+} TPMS_SYMCIPHER_PARMS;
+
+// Table 128 -- TPM2B_SENSITIVE_DATA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_SYM_DATA];
+} TPM2B_SENSITIVE_DATA;
+
+// Table 129 -- TPMS_SENSITIVE_CREATE Structure <I>
+typedef struct {
+    TPM2B_AUTH              userAuth;
+    TPM2B_SENSITIVE_DATA    data;
+} TPMS_SENSITIVE_CREATE;
+
+// Table 130 -- TPM2B_SENSITIVE_CREATE Structure <I,S>
+typedef struct {
+    UINT16                   size;
+    TPMS_SENSITIVE_CREATE    sensitive;
+} TPM2B_SENSITIVE_CREATE;
+
+// Table 131 -- TPMS_SCHEME_SIGHASH Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_SIGHASH;
+
+// Table 132 -- TPMI_ALG_KEYEDHASH_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_KEYEDHASH_SCHEME;
+
+// Table 133 -- HMAC_SIG_SCHEME Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_HMAC;
+
+// Table 134 -- TPMS_SCHEME_XOR Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    TPMI_ALG_KDF     kdf;
+} TPMS_SCHEME_XOR;
+
+// Table 135 -- TPMU_SCHEME_KEYEDHASH Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_HMAC
+    TPMS_SCHEME_HMAC  hmac;
+#endif
+#ifdef TPM2_ALG_XOR
+    TPMS_SCHEME_XOR  xor;
+#endif
+
+} TPMU_SCHEME_KEYEDHASH ;
+
+// Table 136 -- TPMT_KEYEDHASH_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_KEYEDHASH_SCHEME    scheme;
+    TPMU_SCHEME_KEYEDHASH        details;
+} TPMT_KEYEDHASH_SCHEME;
+
+// Table 137 -- RSA_SIG_SCHEMES Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_RSASSA;
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_RSAPSS;
+
+// Table 138 -- ECC_SIG_SCHEMES Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_ECDSA;
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_SM2;
+
+// Table 139 -- TPMS_SCHEME_ECDAA Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    UINT16           count;
+} TPMS_SCHEME_ECDAA;
+
+// Table 140 -- TPMS_SCHEME_ECSCHNORR Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    UINT16           count;
+} TPMS_SCHEME_ECSCHNORR;
+
+// Table 141 -- TPMU_SIG_SCHEME Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_RSASSA
+    TPMS_SCHEME_RSASSA  rsassa;
+#endif
+#ifdef TPM2_ALG_RSAPSS
+    TPMS_SCHEME_RSAPSS  rsapss;
+#endif
+#ifdef TPM2_ALG_ECDSA
+    TPMS_SCHEME_ECDSA  ecdsa;
+#endif
+#ifdef TPM2_ALG_SM2
+    TPMS_SCHEME_SM2  sm2;
+#endif
+#ifdef TPM2_ALG_ECDAA
+    TPMS_SCHEME_ECDAA  ecdaa;
+#endif
+#ifdef TPM2_ALG_ECSCHNORR
+    TPMS_SCHEME_ECSCHNORR  ecSchnorr;
+#endif
+#ifdef TPM2_ALG_HMAC
+    TPMS_SCHEME_HMAC  hmac;
+#endif
+    TPMS_SCHEME_SIGHASH  any;
+} TPMU_SIG_SCHEME;
+
+// Table 142 -- TPMT_SIG_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_SIG_SCHEME    scheme;
+    TPMU_SIG_SCHEME        details;
+} TPMT_SIG_SCHEME;
+
+// Table 143 -- TPMS_SCHEME_OAEP Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_OAEP;
+
+// Table 144 -- TPMS_SCHEME_ECDH Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_ECDH;
+
+// Table 145 -- TPMS_SCHEME_MGF1 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_MGF1;
+
+// Table 146 -- TPMS_SCHEME_KDF1_SP800_56a Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF1_SP800_56a;
+
+// Table 147 -- TPMS_SCHEME_KDF2 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF2;
+
+// Table 148 -- TPMS_SCHEME_KDF1_SP800_108 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF1_SP800_108;
+
+// Table 149 -- TPMU_KDF_SCHEME Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_MGF1
+    TPMS_SCHEME_MGF1  mgf1;
+#endif
+#ifdef TPM2_ALG_KDF1_SP800_56a
+    TPMS_SCHEME_KDF1_SP800_56a  kdf1_SP800_56a;
+#endif
+#ifdef TPM2_ALG_KDF2
+    TPMS_SCHEME_KDF2  kdf2;
+#endif
+#ifdef TPM2_ALG_KDF1_SP800_108
+    TPMS_SCHEME_KDF1_SP800_108  kdf1_sp800_108;
+#endif
+
+} TPMU_KDF_SCHEME;
+
+// Table 150 -- TPMT_KDF_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_KDF       scheme;
+    TPMU_KDF_SCHEME    details;
+} TPMT_KDF_SCHEME;
+typedef TPM_ALG_ID TPMI_ALG_ASYM_SCHEME;
+
+// Table 152 -- TPMU_ASYM_SCHEME Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_RSASSA
+    TPMS_SCHEME_RSASSA  rsassa;
+#endif
+#ifdef TPM2_ALG_RSAPSS
+    TPMS_SCHEME_RSAPSS  rsapss;
+#endif
+#ifdef TPM2_ALG_OAEP
+    TPMS_SCHEME_OAEP  oaep;
+#endif
+#ifdef TPM2_ALG_ECDSA
+    TPMS_SCHEME_ECDSA  ecdsa;
+#endif
+#ifdef TPM2_ALG_SM2
+    TPMS_SCHEME_SM2  sm2;
+#endif
+#ifdef TPM2_ALG_ECDAA
+    TPMS_SCHEME_ECDAA  ecdaa;
+#endif
+#ifdef TPM2_ALG_ECSCHNORR
+    TPMS_SCHEME_ECSCHNORR  ecSchnorr;
+#endif
+    TPMS_SCHEME_SIGHASH  anySig;
+} TPMU_ASYM_SCHEME;
+
+typedef struct {
+    TPMI_ALG_ASYM_SCHEME    scheme;
+    TPMU_ASYM_SCHEME        details;
+} TPMT_ASYM_SCHEME;
+
+// Table 154 -- TPMI_ALG_RSA_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_RSA_SCHEME;
+
+// Table 155 -- TPMT_RSA_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_RSA_SCHEME    scheme;
+    TPMU_ASYM_SCHEME       details;
+} TPMT_RSA_SCHEME;
+
+// Table 156 -- TPMI_ALG_RSA_DECRYPT Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_RSA_DECRYPT;
+
+// Table 157 -- TPMT_RSA_DECRYPT Structure <I/O>
+typedef struct {
+    TPMI_ALG_RSA_DECRYPT    scheme;
+    TPMU_ASYM_SCHEME        details;
+} TPMT_RSA_DECRYPT;
+
+// Table 158 -- TPM2B_PUBLIC_KEY_RSA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_RSA_KEY_BYTES];
+} TPM2B_PUBLIC_KEY_RSA;
+
+// Table 159 -- TPMI_RSA_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_RSA_KEY_BITS;
+
+// Table 160 -- TPM2B_PRIVATE_KEY_RSA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_RSA_KEY_BYTES/2];
+} TPM2B_PRIVATE_KEY_RSA;
+
+// Table 162 -- TPM2B_ECC_PARAMETER
+typedef struct {
+    UINT16 size;
+    BYTE buffer[MAX_ECC_KEY_BYTES];
+} TPM2B_ECC_PARAMETER;
+
+// Table 163 -- TPMS_ECC_POINT Structure <I/O>
+typedef struct {
+    TPM2B_ECC_PARAMETER    x;
+    TPM2B_ECC_PARAMETER    y;
+} TPMS_ECC_POINT;
+
+// Table 164 -- TPMI_ALG_ECC_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_ECC_SCHEME;
+
+typedef UINT16 TPM_ECC_CURVE;
+
+// Table 165 -- TPMI_ECC_CURVE Type <I/O>
+typedef TPM_ECC_CURVE TPMI_ECC_CURVE;
+
+// Table 166 -- TPMT_ECC_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_ECC_SCHEME    scheme;
+    TPMU_SIG_SCHEME        details;
+} TPMT_ECC_SCHEME;
+
+// Table 175 -- TPMI_ALG_PUBLIC Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_PUBLIC;
+
+// Table 176 -- TPMU_PUBLIC_ID Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_KEYEDHASH
+    TPM2B_DIGEST  keyedHash;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPM2B_DIGEST  sym;
+#endif
+#ifdef TPM2_ALG_RSA
+    TPM2B_PUBLIC_KEY_RSA  rsa;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPMS_ECC_POINT  ecc;
+#endif
+} TPMU_PUBLIC_ID;
+
+// Table 177 -- TPMS_KEYEDHASH_PARMS Structure <I/O>
+typedef struct {
+    TPMT_KEYEDHASH_SCHEME    scheme;
+} TPMS_KEYEDHASH_PARMS;
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_ASYM_SCHEME       scheme;
+} TPMS_ASYM_PARMS;
+
+// Table 179 -- TPMS_RSA_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_RSA_SCHEME        scheme;
+    TPMI_RSA_KEY_BITS      keyBits;
+    UINT32                 exponent;
+} TPMS_RSA_PARMS;
+
+// Table 180 -- TPMS_ECC_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_ECC_SCHEME        scheme;
+    TPMI_ECC_CURVE         curveID;
+    TPMT_KDF_SCHEME        kdf;
+} TPMS_ECC_PARMS;
+
+// Table 181 -- TPMU_PUBLIC_PARMS Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_KEYEDHASH
+    TPMS_KEYEDHASH_PARMS  keyedHashDetail;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPMT_SYM_DEF_OBJECT  symDetail;
+#endif
+#ifdef TPM2_ALG_RSA
+    TPMS_RSA_PARMS  rsaDetail;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPMS_ECC_PARMS  eccDetail;
+#endif
+    TPMS_ASYM_PARMS  asymDetail;
+} TPMU_PUBLIC_PARMS;
+
+// Table 182 -- TPMT_PUBLIC_PARMS Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC      type;
+    TPMU_PUBLIC_PARMS    parameters;
+} TPMT_PUBLIC_PARMS;
+
+// Table 183 -- TPMT_PUBLIC Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC      type;
+    TPMI_ALG_HASH        nameAlg;
+    TPMA_OBJECT          objectAttributes;
+    TPM2B_DIGEST         authPolicy;
+    TPMU_PUBLIC_PARMS    parameters;
+    TPMU_PUBLIC_ID       unique;
+} TPMT_PUBLIC;
+
+// Table 184 -- TPM2B_PUBLIC
+typedef struct {
+    UINT16         size;
+    TPMT_PUBLIC    publicArea;
+} TPM2B_PUBLIC;
+
+// Table 185 -- TPMU_SENSITIVE_COMPOSITE Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_RSA
+    TPM2B_PRIVATE_KEY_RSA  rsa;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPM2B_ECC_PARAMETER  ecc;
+#endif
+#ifdef TPM2_ALG_KEYEDHASH
+    TPM2B_SENSITIVE_DATA  bits;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPM2B_SYM_KEY  sym;
+#endif
+    TPM2B_SENSITIVE_DATA  any;
+} TPMU_SENSITIVE_COMPOSITE;
+
+// Table 186 -- TPMT_SENSITIVE Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC             sensitiveType;
+    TPM2B_AUTH                  authValue;
+    TPM2B_DIGEST                seedValue;
+    TPMU_SENSITIVE_COMPOSITE    sensitive;
+} TPMT_SENSITIVE;
+
+// Table 187 -- TPM2B_SENSITIVE Structure <I/O>
+typedef struct {
+    UINT16            size;
+    TPMT_SENSITIVE    sensitiveArea;
+} TPM2B_SENSITIVE;
+
+typedef struct {
+    TPM2B_DIGEST      integrityOuter;
+    TPM2B_DIGEST      integrityInner;
+    TPMT_SENSITIVE    sensitive;
+} _PRIVATE;
+
+// Table 189 -- TPM2B_PRIVATE Structure <I/O,S>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[sizeof(_PRIVATE)];
+} TPM2B_PRIVATE;
+
+// Table 204 -- TPMS_CREATION_DATA <OUT>
+typedef struct {
+    TPML_PCR_SELECTION    pcrSelect;
+    TPM2B_DIGEST          pcrDigest;
+    TPMA_LOCALITY         locality;
+    TPM_ALG_ID            parentNameAlg;
+    TPM2B_NAME            parentName;
+    TPM2B_NAME            parentQualifiedName;
+    TPM2B_DATA            outsideInfo;
+} TPMS_CREATION_DATA;
+
+// Table 205 -- TPM2B_CREATION_DATA <OUT>
+typedef struct {
+    UINT16 size;
+    TPMS_CREATION_DATA creationData;
+} TPM2B_CREATION_DATA;
+
+/* the following structs is not part of standard struct defined in TPM2 spec */
+typedef struct {
+    UINT32            size;
+    TPM_RH            sessionHandle;
+    TPM2B_NONCE       nonce;
+    TPMA_SESSION      sessionAttributes;
+    TPM2B_AUTH        auth;
+} TPM_AuthArea;
+
+typedef struct {
+    TPM2B_SENSITIVE_CREATE  inSensitive;
+    TPM2B_PUBLIC            inPublic;
+    TPM2B_DATA              outsideInfo;
+    TPML_PCR_SELECTION      creationPCR;
+} TPM2_Create_Params_in;
+
+typedef TPM2_Create_Params_in    TPM2_CreatePrimary_Params_in;
+
+typedef struct {
+    TPM2B_PUBLIC        outPublic;
+    TPM2B_CREATION_DATA creationData;
+    TPM2B_DIGEST        creationHash;
+    TPMT_TK_CREATION    creationTicket;
+    TPM2B_NAME          name;
+} TPM2_CreatePrimary_Params_out;
+
+typedef struct {
+    TPM2B_PRIVATE       outPrivate;
+    TPM2B_PUBLIC        outPublic;
+    TPM2B_CREATION_DATA creationData;
+    TPM2B_DIGEST        creationHash;
+    TPMT_TK_CREATION    creationTicket;
+} TPM2_Create_Params_out;
+typedef struct {
+    TPM2B_PRIVATE    Private;
+    TPM2B_PUBLIC     Public;
+} TPM2_RSA_KEY;
+
+/*
+ * TPM 2.0 Objects
+ */
+
+#define TPM_HT_TRANSIENT        0x80
+#define HR_SHIFT                24
+#define HR_PERMANENT            (TPM_HT_TRANSIENT << HR_SHIFT)
+#define TRANSIENT_FIRST         (HR_PERMANENT)
+#define MAX_LOADED_OBJECTS      3
+#define TRANSIENT_LAST          (TRANSIENT_FIRST+MAX_LOADED_OBJECTS-1)
+/*
+ * TPMA_OBJECT Bits
+ */
+#define fixedTPM                ((1 << 1))
+#define stClear                 ((1 << 2))
+#define fixedParent             ((1 << 4))
+#define sensitiveDataOrigin     ((1 << 5))
+#define userWithAuth            ((1 << 6))
+#define adminWithPolicy         ((1 << 7))
+#define noDA                    ((1 << 10))
+#define encryptedDuplication    ((1 << 11))
+#define restricted              ((1 << 16))
+#define decrypt                 ((1 << 17))
+#define sign                    ((1 << 18))
+#endif
-- 
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 Dec 17 15:55:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gwk-00068V-Nq; Wed, 17 Dec 2014 15:55:30 +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 1Y1Gwi-00067m-J9
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:28 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A2/9C-08051-F67A1945; Wed, 17 Dec 2014 15:55:27 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418831726!15686154!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 9774 invoked from network); 17 Dec 2014 15:55:27 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-27.messagelabs.com with SMTP;
	17 Dec 2014 15:55:27 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga101.fm.intel.com with ESMTP; 17 Dec 2014 07:55:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="430193672"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 17 Dec 2014 07:44:16 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:40 -0500
Message-Id: <1418817100-5307-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 03/14] vTPM/TPM2: Add global data in
	vtpm_globals{}
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 data is for the Mini-os to access TPM 2.0 hardware.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/vtpmmgr.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 2d9d153..0d0c604 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -44,6 +44,7 @@
 #include "uuid.h"
 #include "tcg.h"
 #include "vtpm_manager.h"
+#include "tpm2_types.h"
 
 #define RSA_KEY_SIZE 0x0800
 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8)
@@ -59,6 +60,14 @@ struct vtpm_globals {
    ctr_drbg_context    ctr_drbg;
 
    int hw_locality;
+
+    /* TPM 2.0 */
+    TPM_AuthArea       pw_auth;
+    TPM_AuthArea       srk_auth_area;
+    TPM_HANDLE         srk_handle;
+    TPM_HANDLE         sk_handle;
+    TPM2B_NAME         sk_name;
+    TPM2_RSA_KEY       tpm2_storage_key;
 };
 
 struct tpm_opaque {
-- 
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 Dec 17 15:55:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gwt-0006Bg-RO; Wed, 17 Dec 2014 15:55:39 +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 1Y1Gws-0006Ag-5v
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:38 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	4D/51-22737-977A1945; Wed, 17 Dec 2014 15:55:37 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418831733!11045048!2
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 19694 invoked from network); 17 Dec 2014 15:55:36 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-206.messagelabs.com with SMTP;
	17 Dec 2014 15:55:36 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 17 Dec 2014 07:55:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="639067381"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 17 Dec 2014 07:55:34 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:51 -0500
Message-Id: <1418817111-5420-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
MIME-Version: 1.0
Content-Length: 6274
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 06/14] vTPM/TPM2: Create and load SK on TPM
	2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VFBNMl9DcmVhdGUgaXMgdXNlZCB0byBjcmVhdGUgYW4gb2JqZWN0IHRoYXQgY2FuIGJlIGxvYWRl
ZCBpbnRvIGEKVFBNIHVzaW5nIFRQTTJfTG9hZCgpLiBJZiB0aGUgY29tbWFuZCBjb21wbGV0ZXMg
c3VjY2Vzc2Z1bGx5LCB0aGUKVFBNIHdpbGwgY3JlYXRlIHRoZSBuZXcgb2JqZWN0IGFuZCByZXR1
cm4gdGhlIG9iamVjdOKAmXMgY3JlYXRpb24uCmRhdGEgKGNyZWF0aW9uRGF0YSksIGl0cyBwdWJs
aWMgYXJlYSAob3V0UHVibGljKSwgYW5kIGl0cyBlbmNyeXB0ZWQKc2Vuc2l0aXZlIGFyZWEgKG91
dFByaXZhdGUpLiBQcmVzZXJ2YXRpb24gb2YgdGhlIHJldHVybmVkIGRhdGEgaXMKdGhlIHJlc3Bv
bnNpYmlsaXR5IG9mIHRoZSBjYWxsZXIuIFRoZSBvYmplY3Qgd2lsbCBuZWVkIHRvIGJlIGxvYWRl
ZAooVFBNMl9Mb2FkKCkpLgpUUE0yX0xvYWQgaXMgdXNlZCB0byBsb2FkIG9iamVjdHMgaW50byB0
aGUgVFBNLiBUaGlzIGNvbW1hbmQgaXMgdXNlZAp3aGVuIGJvdGggYSBUUE0yQl9QVUJMSUMgYW5k
IFRQTTJCX1BSSVZBVEUgYXJlIHRvIGJlIGxvYWRlZC4gSWYgb25seQphIFRQTTJCX1BVQkxJQyBp
cyB0byBiZSBsb2FkZWQsIHRoZSBUUE0yX0xvYWRFeHRlcm5hbCBjb21tYW5kIGlzIHVzZWQuCgpT
aWduZWQtb2ZmLWJ5OiBRdWFuIFh1IDxxdWFuLnh1QGludGVsLmNvbT4KLS0tCiBzdHViZG9tL3Z0
cG1tZ3IvaW5pdC5jICAgIHwgMTAxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysKIHN0dWJkb20vdnRwbW1nci92dHBtbWdyLmggfCAgIDEgKwogMiBmaWxlcyBj
aGFuZ2VkLCAxMDIgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3N0dWJkb20vdnRwbW1nci9p
bml0LmMgYi9zdHViZG9tL3Z0cG1tZ3IvaW5pdC5jCmluZGV4IGM2NTQwNzEuLjgyNDRiYjAgMTAw
NjQ0Ci0tLSBhL3N0dWJkb20vdnRwbW1nci9pbml0LmMKKysrIGIvc3R1YmRvbS92dHBtbWdyL2lu
aXQuYwpAQCAtNTgwLDMgKzU4MCwxMDQgQEAgVFBNX1JDIHRwbTJfdGFrZV9vd25lcnNoaXAodm9p
ZCkKIGFib3J0X2VncmVzczoKICAgICByZXR1cm4gc3RhdHVzOwogfQorCitUUE1fUkVTVUxUIHZ0
cG1tZ3IyX2NyZWF0ZSh2b2lkKQoreworICAgIFRQTV9SRVNVTFQgc3RhdHVzID0gVFBNX1NVQ0NF
U1M7CisKKyAgICBUUE1UUllSRVRVUk4odHBtMl90YWtlX293bmVyc2hpcCgpKTsKKworICAgLyog
Y3JlYXRlIFNLICovCisgICAgVFBNMl9DcmVhdGVfUGFyYW1zX291dCBvdXQ7CisgICAgVFBNMl9D
cmVhdGVfUGFyYW1zX2luIGluID0geworICAgICAgICAuaW5TZW5zaXRpdmUgPSB7CisgICAgICAg
ICAgICAuc2l6ZSA9IDQgKyAyMCwKKyAgICAgICAgICAgIC5zZW5zaXRpdmUgPSB7CisgICAgICAg
ICAgICAgICAgLnVzZXJBdXRoLnNpemUgPSAyMCwKKyAgICAgICAgICAgICAgICAudXNlckF1dGgu
YnVmZmVyID0geyAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLFwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwIH0sCisg
ICAgICAgICAgICAgICAgLmRhdGEuc2l6ZSA9IDAsCisgICAgICAgICAgICB9LAorICAgICAgICB9
LAorICAgICAgICAuaW5QdWJsaWMgPSB7CisgICAgICAgICAgICAuc2l6ZSA9ICg2MCksCisgICAg
ICAgICAgICAucHVibGljQXJlYSA9IHsKKyAgICAgICAgICAgICAgICAgLnR5cGUgPSBUUE0yX0FM
R19SU0EsCisgICAgICAgICAgICAgICAgIC5uYW1lQWxnID0gVFBNMl9BTEdfU0hBMjU2LAorI2Rl
ZmluZSBTS19PQkpfQVRUUiAoZml4ZWRUUE0gfCBmaXhlZFBhcmVudCB8IHVzZXJXaXRoQXV0aCB8
XAorICAgICAgICAgICAgICAgICAgICAgc2Vuc2l0aXZlRGF0YU9yaWdpbiB8ZGVjcnlwdCkKKyAg
ICAgICAgICAgICAgICAgLm9iamVjdEF0dHJpYnV0ZXMgPSBTS19PQkpfQVRUUiwKKyAgICAgICAg
ICAgICAgICAgLmF1dGhQb2xpY3kuc2l6ZSA9IDAsCisgICAgICAgICAgICAgICAgIC5wYXJhbWV0
ZXJzLnJzYURldGFpbCA9IHsKKyAgICAgICAgICAgICAgICAgICAgIC5zeW1tZXRyaWMgPSB7Cisg
ICAgICAgICAgICAgICAgICAgICAgICAgLmFsZ29yaXRobSA9IFRQTTJfQUxHX05VTEwsCisgICAg
ICAgICAgICAgICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgICAgLnNjaGVtZSA9IHsKKyAg
ICAgICAgICAgICAgICAgICAgICAgICBUUE0yX0FMR19PQUVQLAorICAgICAgICAgICAgICAgICAg
ICAgICAgIC5kZXRhaWxzLm9hZXAuaGFzaEFsZyA9IFRQTTJfQUxHX1NIQTI1NiwKKyAgICAgICAg
ICAgICAgICAgICAgIH0sCisgICAgICAgICAgICAgICAgICAgICAua2V5Qml0cyA9IFJTQV9LRVlf
U0laRVNfQklUUywKKyAgICAgICAgICAgICAgICAgICAgIC5leHBvbmVudCA9IDAsCisgICAgICAg
ICAgICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgLnVuaXF1ZS5yc2Euc2l6ZSA9IDAsCisg
ICAgICAgICAgICB9LAorICAgICAgICB9LAorICAgICAgICAub3V0c2lkZUluZm8uc2l6ZSA9IDAs
CisgICAgICAgIC5jcmVhdGlvblBDUi5jb3VudCA9IDAsCisgICAgfTsvKmVuZCBpbiAqLworCisg
ICAgVFBNVFJZUkVUVVJOKFRQTTJfQ3JlYXRlKHZ0cG1fZ2xvYmFscy5zcmtfaGFuZGxlLCAmaW4s
ICZvdXQpKTsKKyAgICBUUE1UUllSRVRVUk4oVFBNMl9Mb2FkKHZ0cG1fZ2xvYmFscy5zcmtfaGFu
ZGxlLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZ0cG1fZ2xvYmFscy50cG0yX3N0b3Jh
Z2Vfa2V5LlByaXZhdGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAmdnRwbV9nbG9iYWxz
LnRwbTJfc3RvcmFnZV9rZXkuUHVibGljLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZ0
cG1fZ2xvYmFscy5za19oYW5kbGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAmdnRwbV9n
bG9iYWxzLnNrX25hbWUpKTsKKworICAgIHZ0cG1sb2dpbmZvKFZUUE1fTE9HX1ZUUE0sICJTSyBI
QU5ETEU6IDB4JVhcbiIsIHZ0cG1fZ2xvYmFscy5za19oYW5kbGUpOworICAgIC8qZW5kIGNyZWF0
ZSBTSyovCisKKyNpZiAwIC8qQmluZCAmIHVuQmluZCovCit7CisgICAgdW5zaWduZWQgY2hhciBy
YW5kWzIwXTsKKyAgICB1bnNpZ25lZCBjaGFyIGNpcGhlclsyNTZdLCBvdXRbMjU2XTsKKyAgICB2
dHBtbWdyX3JhbmQocmFuZCwgMjApOworICAgIGludCBpOworICAgIFVJTlQzMiBvbGVuOworCisg
ICAgcHJpbnRrKCJyYW5kOiAiKTsKKyAgICBmb3IgKGkgPSAwOyBpIDwgMjA7IGkrKykgeworICAg
ICAgICAgcHJpbnRrKCIgJXUgIiwgcmFuZFtpXSk7CisgICAgfQorICAgIHByaW50aygiXG4iKTsK
KyAgICBUUE1UUllSRVRVUk4oVFBNMl9CaW5kKHZ0cG1fZ2xvYmFscy5za19oYW5kbGUsCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICByYW5kLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg
MjAsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBjaXBoZXIpKTsKKyAgICBwcmludGsoImNp
cGhlciA6ICIpOworICAgIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykgeworICAgICAgICAgcHJp
bnRrKCIlMDJ4IiwgY2lwaGVyW2ldKTsKKyAgICB9CisgICAgcHJpbnRrKCJcbiIpOworICAgIFRQ
TVRSWVJFVFVSTihUUE0yX1VuQmluZCh2dHBtX2dsb2JhbHMuc2tfaGFuZGxlLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAyNTYsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNp
cGhlciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJm9sZW4sCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG91dCkpOworICAgIHByaW50aygib2xlbiA6ICVkIFxuIiwgb2xlbik7
CisgICAgcHJpbnRrKCJvdXQgOiAiKTsKKyAgICBmb3IgKGkgPSAwOyBpIDwgb2xlbjsgaSsrKQor
ICAgICAgICAgcHJpbnRrKCIgJXUgIiwgb3V0W2ldKTsKKyAgICBwcmludGsoIlxuIik7Cit9Cisj
ZW5kaWYKKworICAgIC8qQ3JlYXRlIG5ldyBkaXNrIGltYWdlKi8KKyAgICBUUE1UUllSRVRVUk4o
dnRwbV9uZXdfZGlzaygpKTsKKworICAgIGdvdG8gZWdyZXNzOworCithYm9ydF9lZ3Jlc3M6Citl
Z3Jlc3M6CisgICAgdnRwbWxvZ2luZm8oVlRQTV9MT0dfVlRQTSwgIkZpbmlzaGVkIGluaXRpYWxp
emVkIG5ldyBWVFBNIG1hbmFnZXJcbiIpOworICAgIHJldHVybiBzdGF0dXM7Cit9CmRpZmYgLS1n
aXQgYS9zdHViZG9tL3Z0cG1tZ3IvdnRwbW1nci5oIGIvc3R1YmRvbS92dHBtbWdyL3Z0cG1tZ3Iu
aAppbmRleCA5NTUxOWJhLi45ODg5ZmViIDEwMDY0NAotLS0gYS9zdHViZG9tL3Z0cG1tZ3IvdnRw
bW1nci5oCisrKyBiL3N0dWJkb20vdnRwbW1nci92dHBtbWdyLmgKQEAgLTk1LDUgKzk1LDYgQEAg
aW5saW5lIFRQTV9SRVNVTFQgdnRwbW1ncl9yYW5kKHVuc2lnbmVkIGNoYXIqIGJ5dGVzLCBzaXpl
X3QgbnVtX2J5dGVzKSB7CiAKIC8qIFRQTSAyLjAgKi8KIFRQTV9SQyB0cG0yX3Rha2Vfb3duZXJz
aGlwKHZvaWQpOworVFBNX1JFU1VMVCB2dHBtbWdyMl9jcmVhdGUodm9pZCk7CiAKICNlbmRpZgot
LSAKMS44LjMuMgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Dec 17 15:55:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gwt-0006Bg-RO; Wed, 17 Dec 2014 15:55:39 +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 1Y1Gws-0006Ag-5v
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:38 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	4D/51-22737-977A1945; Wed, 17 Dec 2014 15:55:37 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418831733!11045048!2
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 19694 invoked from network); 17 Dec 2014 15:55:36 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-206.messagelabs.com with SMTP;
	17 Dec 2014 15:55:36 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 17 Dec 2014 07:55:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="639067381"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 17 Dec 2014 07:55:34 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:51 -0500
Message-Id: <1418817111-5420-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
MIME-Version: 1.0
Content-Length: 6274
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 06/14] vTPM/TPM2: Create and load SK on TPM
	2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VFBNMl9DcmVhdGUgaXMgdXNlZCB0byBjcmVhdGUgYW4gb2JqZWN0IHRoYXQgY2FuIGJlIGxvYWRl
ZCBpbnRvIGEKVFBNIHVzaW5nIFRQTTJfTG9hZCgpLiBJZiB0aGUgY29tbWFuZCBjb21wbGV0ZXMg
c3VjY2Vzc2Z1bGx5LCB0aGUKVFBNIHdpbGwgY3JlYXRlIHRoZSBuZXcgb2JqZWN0IGFuZCByZXR1
cm4gdGhlIG9iamVjdOKAmXMgY3JlYXRpb24uCmRhdGEgKGNyZWF0aW9uRGF0YSksIGl0cyBwdWJs
aWMgYXJlYSAob3V0UHVibGljKSwgYW5kIGl0cyBlbmNyeXB0ZWQKc2Vuc2l0aXZlIGFyZWEgKG91
dFByaXZhdGUpLiBQcmVzZXJ2YXRpb24gb2YgdGhlIHJldHVybmVkIGRhdGEgaXMKdGhlIHJlc3Bv
bnNpYmlsaXR5IG9mIHRoZSBjYWxsZXIuIFRoZSBvYmplY3Qgd2lsbCBuZWVkIHRvIGJlIGxvYWRl
ZAooVFBNMl9Mb2FkKCkpLgpUUE0yX0xvYWQgaXMgdXNlZCB0byBsb2FkIG9iamVjdHMgaW50byB0
aGUgVFBNLiBUaGlzIGNvbW1hbmQgaXMgdXNlZAp3aGVuIGJvdGggYSBUUE0yQl9QVUJMSUMgYW5k
IFRQTTJCX1BSSVZBVEUgYXJlIHRvIGJlIGxvYWRlZC4gSWYgb25seQphIFRQTTJCX1BVQkxJQyBp
cyB0byBiZSBsb2FkZWQsIHRoZSBUUE0yX0xvYWRFeHRlcm5hbCBjb21tYW5kIGlzIHVzZWQuCgpT
aWduZWQtb2ZmLWJ5OiBRdWFuIFh1IDxxdWFuLnh1QGludGVsLmNvbT4KLS0tCiBzdHViZG9tL3Z0
cG1tZ3IvaW5pdC5jICAgIHwgMTAxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysKIHN0dWJkb20vdnRwbW1nci92dHBtbWdyLmggfCAgIDEgKwogMiBmaWxlcyBj
aGFuZ2VkLCAxMDIgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3N0dWJkb20vdnRwbW1nci9p
bml0LmMgYi9zdHViZG9tL3Z0cG1tZ3IvaW5pdC5jCmluZGV4IGM2NTQwNzEuLjgyNDRiYjAgMTAw
NjQ0Ci0tLSBhL3N0dWJkb20vdnRwbW1nci9pbml0LmMKKysrIGIvc3R1YmRvbS92dHBtbWdyL2lu
aXQuYwpAQCAtNTgwLDMgKzU4MCwxMDQgQEAgVFBNX1JDIHRwbTJfdGFrZV9vd25lcnNoaXAodm9p
ZCkKIGFib3J0X2VncmVzczoKICAgICByZXR1cm4gc3RhdHVzOwogfQorCitUUE1fUkVTVUxUIHZ0
cG1tZ3IyX2NyZWF0ZSh2b2lkKQoreworICAgIFRQTV9SRVNVTFQgc3RhdHVzID0gVFBNX1NVQ0NF
U1M7CisKKyAgICBUUE1UUllSRVRVUk4odHBtMl90YWtlX293bmVyc2hpcCgpKTsKKworICAgLyog
Y3JlYXRlIFNLICovCisgICAgVFBNMl9DcmVhdGVfUGFyYW1zX291dCBvdXQ7CisgICAgVFBNMl9D
cmVhdGVfUGFyYW1zX2luIGluID0geworICAgICAgICAuaW5TZW5zaXRpdmUgPSB7CisgICAgICAg
ICAgICAuc2l6ZSA9IDQgKyAyMCwKKyAgICAgICAgICAgIC5zZW5zaXRpdmUgPSB7CisgICAgICAg
ICAgICAgICAgLnVzZXJBdXRoLnNpemUgPSAyMCwKKyAgICAgICAgICAgICAgICAudXNlckF1dGgu
YnVmZmVyID0geyAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLFwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwIH0sCisg
ICAgICAgICAgICAgICAgLmRhdGEuc2l6ZSA9IDAsCisgICAgICAgICAgICB9LAorICAgICAgICB9
LAorICAgICAgICAuaW5QdWJsaWMgPSB7CisgICAgICAgICAgICAuc2l6ZSA9ICg2MCksCisgICAg
ICAgICAgICAucHVibGljQXJlYSA9IHsKKyAgICAgICAgICAgICAgICAgLnR5cGUgPSBUUE0yX0FM
R19SU0EsCisgICAgICAgICAgICAgICAgIC5uYW1lQWxnID0gVFBNMl9BTEdfU0hBMjU2LAorI2Rl
ZmluZSBTS19PQkpfQVRUUiAoZml4ZWRUUE0gfCBmaXhlZFBhcmVudCB8IHVzZXJXaXRoQXV0aCB8
XAorICAgICAgICAgICAgICAgICAgICAgc2Vuc2l0aXZlRGF0YU9yaWdpbiB8ZGVjcnlwdCkKKyAg
ICAgICAgICAgICAgICAgLm9iamVjdEF0dHJpYnV0ZXMgPSBTS19PQkpfQVRUUiwKKyAgICAgICAg
ICAgICAgICAgLmF1dGhQb2xpY3kuc2l6ZSA9IDAsCisgICAgICAgICAgICAgICAgIC5wYXJhbWV0
ZXJzLnJzYURldGFpbCA9IHsKKyAgICAgICAgICAgICAgICAgICAgIC5zeW1tZXRyaWMgPSB7Cisg
ICAgICAgICAgICAgICAgICAgICAgICAgLmFsZ29yaXRobSA9IFRQTTJfQUxHX05VTEwsCisgICAg
ICAgICAgICAgICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgICAgLnNjaGVtZSA9IHsKKyAg
ICAgICAgICAgICAgICAgICAgICAgICBUUE0yX0FMR19PQUVQLAorICAgICAgICAgICAgICAgICAg
ICAgICAgIC5kZXRhaWxzLm9hZXAuaGFzaEFsZyA9IFRQTTJfQUxHX1NIQTI1NiwKKyAgICAgICAg
ICAgICAgICAgICAgIH0sCisgICAgICAgICAgICAgICAgICAgICAua2V5Qml0cyA9IFJTQV9LRVlf
U0laRVNfQklUUywKKyAgICAgICAgICAgICAgICAgICAgIC5leHBvbmVudCA9IDAsCisgICAgICAg
ICAgICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgLnVuaXF1ZS5yc2Euc2l6ZSA9IDAsCisg
ICAgICAgICAgICB9LAorICAgICAgICB9LAorICAgICAgICAub3V0c2lkZUluZm8uc2l6ZSA9IDAs
CisgICAgICAgIC5jcmVhdGlvblBDUi5jb3VudCA9IDAsCisgICAgfTsvKmVuZCBpbiAqLworCisg
ICAgVFBNVFJZUkVUVVJOKFRQTTJfQ3JlYXRlKHZ0cG1fZ2xvYmFscy5zcmtfaGFuZGxlLCAmaW4s
ICZvdXQpKTsKKyAgICBUUE1UUllSRVRVUk4oVFBNMl9Mb2FkKHZ0cG1fZ2xvYmFscy5zcmtfaGFu
ZGxlLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZ0cG1fZ2xvYmFscy50cG0yX3N0b3Jh
Z2Vfa2V5LlByaXZhdGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAmdnRwbV9nbG9iYWxz
LnRwbTJfc3RvcmFnZV9rZXkuUHVibGljLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZ0
cG1fZ2xvYmFscy5za19oYW5kbGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAmdnRwbV9n
bG9iYWxzLnNrX25hbWUpKTsKKworICAgIHZ0cG1sb2dpbmZvKFZUUE1fTE9HX1ZUUE0sICJTSyBI
QU5ETEU6IDB4JVhcbiIsIHZ0cG1fZ2xvYmFscy5za19oYW5kbGUpOworICAgIC8qZW5kIGNyZWF0
ZSBTSyovCisKKyNpZiAwIC8qQmluZCAmIHVuQmluZCovCit7CisgICAgdW5zaWduZWQgY2hhciBy
YW5kWzIwXTsKKyAgICB1bnNpZ25lZCBjaGFyIGNpcGhlclsyNTZdLCBvdXRbMjU2XTsKKyAgICB2
dHBtbWdyX3JhbmQocmFuZCwgMjApOworICAgIGludCBpOworICAgIFVJTlQzMiBvbGVuOworCisg
ICAgcHJpbnRrKCJyYW5kOiAiKTsKKyAgICBmb3IgKGkgPSAwOyBpIDwgMjA7IGkrKykgeworICAg
ICAgICAgcHJpbnRrKCIgJXUgIiwgcmFuZFtpXSk7CisgICAgfQorICAgIHByaW50aygiXG4iKTsK
KyAgICBUUE1UUllSRVRVUk4oVFBNMl9CaW5kKHZ0cG1fZ2xvYmFscy5za19oYW5kbGUsCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICByYW5kLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg
MjAsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBjaXBoZXIpKTsKKyAgICBwcmludGsoImNp
cGhlciA6ICIpOworICAgIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykgeworICAgICAgICAgcHJp
bnRrKCIlMDJ4IiwgY2lwaGVyW2ldKTsKKyAgICB9CisgICAgcHJpbnRrKCJcbiIpOworICAgIFRQ
TVRSWVJFVFVSTihUUE0yX1VuQmluZCh2dHBtX2dsb2JhbHMuc2tfaGFuZGxlLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAyNTYsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNp
cGhlciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJm9sZW4sCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG91dCkpOworICAgIHByaW50aygib2xlbiA6ICVkIFxuIiwgb2xlbik7
CisgICAgcHJpbnRrKCJvdXQgOiAiKTsKKyAgICBmb3IgKGkgPSAwOyBpIDwgb2xlbjsgaSsrKQor
ICAgICAgICAgcHJpbnRrKCIgJXUgIiwgb3V0W2ldKTsKKyAgICBwcmludGsoIlxuIik7Cit9Cisj
ZW5kaWYKKworICAgIC8qQ3JlYXRlIG5ldyBkaXNrIGltYWdlKi8KKyAgICBUUE1UUllSRVRVUk4o
dnRwbV9uZXdfZGlzaygpKTsKKworICAgIGdvdG8gZWdyZXNzOworCithYm9ydF9lZ3Jlc3M6Citl
Z3Jlc3M6CisgICAgdnRwbWxvZ2luZm8oVlRQTV9MT0dfVlRQTSwgIkZpbmlzaGVkIGluaXRpYWxp
emVkIG5ldyBWVFBNIG1hbmFnZXJcbiIpOworICAgIHJldHVybiBzdGF0dXM7Cit9CmRpZmYgLS1n
aXQgYS9zdHViZG9tL3Z0cG1tZ3IvdnRwbW1nci5oIGIvc3R1YmRvbS92dHBtbWdyL3Z0cG1tZ3Iu
aAppbmRleCA5NTUxOWJhLi45ODg5ZmViIDEwMDY0NAotLS0gYS9zdHViZG9tL3Z0cG1tZ3IvdnRw
bW1nci5oCisrKyBiL3N0dWJkb20vdnRwbW1nci92dHBtbWdyLmgKQEAgLTk1LDUgKzk1LDYgQEAg
aW5saW5lIFRQTV9SRVNVTFQgdnRwbW1ncl9yYW5kKHVuc2lnbmVkIGNoYXIqIGJ5dGVzLCBzaXpl
X3QgbnVtX2J5dGVzKSB7CiAKIC8qIFRQTSAyLjAgKi8KIFRQTV9SQyB0cG0yX3Rha2Vfb3duZXJz
aGlwKHZvaWQpOworVFBNX1JFU1VMVCB2dHBtbWdyMl9jcmVhdGUodm9pZCk7CiAKICNlbmRpZgot
LSAKMS44LjMuMgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Dec 17 15:55:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gx3-0006Ib-0l; Wed, 17 Dec 2014 15:55: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 1Y1Gx1-0006Gm-C9
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:47 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	9E/9D-18267-287A1945; Wed, 17 Dec 2014 15:55:46 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418831745!14118492!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25227 invoked from network); 17 Dec 2014 15:55:46 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 15:55:46 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2014 07:55:44 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="430193757"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 17 Dec 2014 07:44:35 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:52:00 -0500
Message-Id: <1418817120-5533-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 09/14] vTPM/TPM2: Support 'tpm2' extra
	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>
MIME-Version: 1.0
Content-Type: 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 vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
Add:
..
     extra="tpm2"
..
to launch vtpm-stubdom domain on TPM 2.0, ignore it on TPM 1.x. for
example,
vtpm-stubdom domain configuration on TPM 2.0:

  kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
  memory=16
  disk=["file:/var/scale/vdisk/vmgr,hda,w"]
  name="vtpmmgr"
  iomem=["fed40,5"]
  extra="tpm2"

vtpm-stubdom domain configuration on TPM 1.x:

  kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
  memory=16
  disk=["file:/var/scale/vdisk/vmgr,hda,w"]
  name="vtpmmgr"
  iomem=["fed40,5"]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/vtpmmgr.c | 46 ++++++++++++++++++++++++++++++++++++++++------
 stubdom/vtpmmgr/vtpmmgr.h | 14 ++++++++++++++
 2 files changed, 54 insertions(+), 6 deletions(-)

diff --git a/stubdom/vtpmmgr/vtpmmgr.c b/stubdom/vtpmmgr/vtpmmgr.c
index 270ca8a..f743ca6 100644
--- a/stubdom/vtpmmgr/vtpmmgr.c
+++ b/stubdom/vtpmmgr/vtpmmgr.c
@@ -45,6 +45,27 @@
 #include "vtpmmgr.h"
 #include "tcg.h"
 
+struct tpm_hardware_version hardware_version = {
+    .hw_version = TPM1_HARDWARE,
+};
+
+int parse_cmdline_hw(int argc, char** argv)
+{
+    int i;
+
+    for (i = 1; i < argc; ++i) {
+        if (!strncmp(argv[i], TPM2_EXTRA_OPT, 4)) {
+            hardware_version.hw_version = TPM2_HARDWARE;
+            break;
+        }
+    }
+    return 0;
+}
+
+int hw_is_tpm2(void)
+{
+    return (hardware_version.hw_version == TPM2_HARDWARE) ? 1 : 0;
+}
 
 void main_loop(void) {
    tpmcmd_t* tpmcmd;
@@ -74,12 +95,25 @@ int main(int argc, char** argv)
    sleep(2);
    vtpmloginfo(VTPM_LOG_VTPM, "Starting vTPM manager domain\n");
 
-   /* Initialize the vtpm manager */
-   if(vtpmmgr_init(argc, argv) != TPM_SUCCESS) {
-      vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
-      rc = -1;
-      goto exit;
-   }
+    /*Parse TPM hardware in extra command line*/
+    parse_cmdline_hw(argc, argv);
+
+    /* Initialize the vtpm manager */
+    if (hw_is_tpm2()) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Hardware : --- TPM 2.0 ---\n");
+        if (vtpmmgr2_init(argc, argv) != TPM_SUCCESS) {
+            vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
+            rc = -1;
+            goto exit;
+        }
+    }else{
+        vtpmloginfo(VTPM_LOG_VTPM, "Hardware : --- TPM 1.x ---\n");
+        if (vtpmmgr_init(argc, argv) != TPM_SUCCESS) {
+            vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
+            rc = -1;
+            goto exit;
+        }
+    }
 
    main_loop();
 
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index c479443..6a76af4 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -46,9 +46,21 @@
 #include "vtpm_manager.h"
 #include "tpm2_types.h"
 
+#define TPM2_EXTRA_OPT "tpm2"
 #define RSA_KEY_SIZE 0x0800
 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8)
 
+enum {
+    TPM1_HARDWARE = 1,
+    TPM2_HARDWARE,
+} tpm_version;
+
+struct tpm_hardware_version {
+    int hw_version;
+};
+
+extern struct tpm_hardware_version hardware_version;
+
 struct vtpm_globals {
    int tpm_fd;
    TPM_AUTH_SESSION    oiap;                // OIAP session for storageKey
@@ -97,5 +109,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 TPM_RC tpm2_take_ownership(void);
 TPM_RESULT vtpmmgr2_create(void);
 TPM_RESULT vtpmmgr2_init(int argc, char** argv);
+int parse_cmdline_hw(int argc, char** argv);
+int hw_is_tpm2(void);
 
 #endif
-- 
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 Dec 17 15:55:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gx3-0006Ib-0l; Wed, 17 Dec 2014 15:55: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 1Y1Gx1-0006Gm-C9
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:47 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	9E/9D-18267-287A1945; Wed, 17 Dec 2014 15:55:46 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418831745!14118492!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25227 invoked from network); 17 Dec 2014 15:55:46 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 15:55:46 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2014 07:55:44 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="430193757"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 17 Dec 2014 07:44:35 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:52:00 -0500
Message-Id: <1418817120-5533-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 09/14] vTPM/TPM2: Support 'tpm2' extra
	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>
MIME-Version: 1.0
Content-Type: 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 vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
Add:
..
     extra="tpm2"
..
to launch vtpm-stubdom domain on TPM 2.0, ignore it on TPM 1.x. for
example,
vtpm-stubdom domain configuration on TPM 2.0:

  kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
  memory=16
  disk=["file:/var/scale/vdisk/vmgr,hda,w"]
  name="vtpmmgr"
  iomem=["fed40,5"]
  extra="tpm2"

vtpm-stubdom domain configuration on TPM 1.x:

  kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
  memory=16
  disk=["file:/var/scale/vdisk/vmgr,hda,w"]
  name="vtpmmgr"
  iomem=["fed40,5"]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/vtpmmgr.c | 46 ++++++++++++++++++++++++++++++++++++++++------
 stubdom/vtpmmgr/vtpmmgr.h | 14 ++++++++++++++
 2 files changed, 54 insertions(+), 6 deletions(-)

diff --git a/stubdom/vtpmmgr/vtpmmgr.c b/stubdom/vtpmmgr/vtpmmgr.c
index 270ca8a..f743ca6 100644
--- a/stubdom/vtpmmgr/vtpmmgr.c
+++ b/stubdom/vtpmmgr/vtpmmgr.c
@@ -45,6 +45,27 @@
 #include "vtpmmgr.h"
 #include "tcg.h"
 
+struct tpm_hardware_version hardware_version = {
+    .hw_version = TPM1_HARDWARE,
+};
+
+int parse_cmdline_hw(int argc, char** argv)
+{
+    int i;
+
+    for (i = 1; i < argc; ++i) {
+        if (!strncmp(argv[i], TPM2_EXTRA_OPT, 4)) {
+            hardware_version.hw_version = TPM2_HARDWARE;
+            break;
+        }
+    }
+    return 0;
+}
+
+int hw_is_tpm2(void)
+{
+    return (hardware_version.hw_version == TPM2_HARDWARE) ? 1 : 0;
+}
 
 void main_loop(void) {
    tpmcmd_t* tpmcmd;
@@ -74,12 +95,25 @@ int main(int argc, char** argv)
    sleep(2);
    vtpmloginfo(VTPM_LOG_VTPM, "Starting vTPM manager domain\n");
 
-   /* Initialize the vtpm manager */
-   if(vtpmmgr_init(argc, argv) != TPM_SUCCESS) {
-      vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
-      rc = -1;
-      goto exit;
-   }
+    /*Parse TPM hardware in extra command line*/
+    parse_cmdline_hw(argc, argv);
+
+    /* Initialize the vtpm manager */
+    if (hw_is_tpm2()) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Hardware : --- TPM 2.0 ---\n");
+        if (vtpmmgr2_init(argc, argv) != TPM_SUCCESS) {
+            vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
+            rc = -1;
+            goto exit;
+        }
+    }else{
+        vtpmloginfo(VTPM_LOG_VTPM, "Hardware : --- TPM 1.x ---\n");
+        if (vtpmmgr_init(argc, argv) != TPM_SUCCESS) {
+            vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
+            rc = -1;
+            goto exit;
+        }
+    }
 
    main_loop();
 
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index c479443..6a76af4 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -46,9 +46,21 @@
 #include "vtpm_manager.h"
 #include "tpm2_types.h"
 
+#define TPM2_EXTRA_OPT "tpm2"
 #define RSA_KEY_SIZE 0x0800
 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8)
 
+enum {
+    TPM1_HARDWARE = 1,
+    TPM2_HARDWARE,
+} tpm_version;
+
+struct tpm_hardware_version {
+    int hw_version;
+};
+
+extern struct tpm_hardware_version hardware_version;
+
 struct vtpm_globals {
    int tpm_fd;
    TPM_AUTH_SESSION    oiap;                // OIAP session for storageKey
@@ -97,5 +109,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 TPM_RC tpm2_take_ownership(void);
 TPM_RESULT vtpmmgr2_create(void);
 TPM_RESULT vtpmmgr2_init(int argc, char** argv);
+int parse_cmdline_hw(int argc, char** argv);
+int hw_is_tpm2(void);
 
 #endif
-- 
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 Dec 17 15:55:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gwv-0006Cj-Bn; Wed, 17 Dec 2014 15:55:41 +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 1Y1Gws-0006Ao-QI
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:39 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	A2/B9-02696-A77A1945; Wed, 17 Dec 2014 15:55:38 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418831735!15739311!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=1.2 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_03_06,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14485 invoked from network); 17 Dec 2014 15:55:35 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-10.tower-27.messagelabs.com with SMTP;
	17 Dec 2014 15:55:35 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 17 Dec 2014 07:53:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="655675836"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 17 Dec 2014 07:55:20 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:36 -0500
Message-Id: <1418817096-5270-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 02/14] vTPM/TPM2: TPM 2.0 data structures
	marshal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 TPM 2.0 data structure marshal for packing and unpacking TPM
2.0 data structures.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/tpm2_marshal.h | 673 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 673 insertions(+)
 create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h

diff --git a/stubdom/vtpmmgr/tpm2_marshal.h b/stubdom/vtpmmgr/tpm2_marshal.h
new file mode 100644
index 0000000..aaa4464
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2_marshal.h
@@ -0,0 +1,673 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef TPM2_MARSHAL_H
+#define TPM2_MARSHAL_H
+
+#include <stdlib.h>
+#include <mini-os/byteorder.h>
+#include <mini-os/endian.h>
+#include "tcg.h"
+#include "tpm2_types.h"
+#include <assert.h>
+
+#define pack_TPM_BUFFER(ptr, buf, size) pack_BUFFER(ptr, buf, size)
+#define unpack_TPM_BUFFER(ptr, buf, size) unpack_BUFFER(ptr, buf, size)
+
+inline BYTE* pack_BYTE_ARRAY(BYTE* ptr, const BYTE* array, UINT32 size)
+{
+    int i;
+    for (i = 0; i < size; i++)
+         ptr = pack_BYTE(ptr, array[i]);
+    return ptr;
+}
+
+inline BYTE* pack_TPMA_SESSION(BYTE* ptr, const TPMA_SESSION *attr)
+{
+    return pack_BYTE(ptr, (BYTE)(*attr));
+}
+
+inline BYTE* unpack_TPMA_SESSION(BYTE* ptr, TPMA_SESSION *attr)
+{
+    return unpack_BYTE(ptr, (BYTE *)attr);
+}
+
+inline BYTE* pack_TPMI_ALG_HASH(BYTE* ptr, const TPMI_ALG_HASH *hash)
+{
+    return pack_UINT16(ptr, *hash);
+}
+
+inline BYTE* unpack_TPMI_ALG_HASH(BYTE *ptr, TPMI_ALG_HASH *hash)
+{
+    return unpack_UINT16(ptr, hash);
+}
+
+#define pack_TPMA_OBJECT(ptr, t)                pack_UINT32(ptr, (UINT32)(*t))
+#define unpack_TPMA_OBJECT(ptr, t)              unpack_UINT32(ptr, (UINT32 *)(t))
+#define pack_TPM_RH(ptr, t)                     pack_UINT32(ptr, (UINT32)(*t))
+#define unpack_TPM_RH(ptr, t)                   unpack_UINT32(ptr, (UINT32 *)(t))
+#define pack_TPMA_LOCALITY(ptr, locality)       pack_BYTE(ptr, (BYTE)*locality)
+#define unpack_TPMA_LOCALITY(ptr, locality)     unpack_BYTE(ptr, (BYTE *)locality)
+#define pack_TPM_ST(ptr, tag)                   pack_UINT16(ptr, *tag)
+#define unpack_TPM_ST(ptr, tag)                 unpack_UINT16(ptr, tag)
+#define pack_TPM_KEY_BITS(ptr, t)               pack_UINT16(ptr, *t)
+#define unpack_TPM_KEY_BITS(ptr, t)             unpack_UINT16(ptr, t)
+#define pack_TPMI_AES_KEY_BITS(ptr, t)          pack_TPM_KEY_BITS(ptr, t)
+#define unpack_TPMI_AES_KEY_BITS(ptr, t)        unpack_TPM_KEY_BITS(ptr, t)
+#define pack_TPMI_RSA_KEY_BITS(ptr, t)          pack_TPM_KEY_BITS(ptr, t)
+#define unpack_TPMI_RSA_KEY_BITS(ptr, t)        unpack_TPM_KEY_BITS(ptr, t)
+#define pack_TPM_ALG_ID(ptr, id)                pack_UINT16(ptr, *id)
+#define unpack_TPM_ALG_ID(ptr, id)              unpack_UINT16(ptr, id)
+#define pack_TPM_ALG_SYM(ptr, t)                pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPM_ALG_SYM(ptr, t)              unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_ASYM(ptr, asym)           pack_TPM_ALG_ID(ptr, asym)
+#define unpack_TPMI_ALG_ASYM(ptr, asym)         unpack_TPM_ALG_ID(ptr, asym)
+#define pack_TPMI_ALG_SYM_OBJECT(ptr, t)        pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_SYM_OBJECT(ptr, t)      unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_SYM_MODE(ptr, t)          pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_SYM_MODE(ptr, t)        unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_KDF(ptr, t)               pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_KDF(ptr, t)             unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_PUBLIC(ptr, t)            pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_PUBLIC(ptr, t)          unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPM2_HANDLE(ptr, h)                pack_UINT32(ptr, *h)
+#define unpack_TPM2_HANDLE(ptr, h)              unpack_UINT32(ptr, h)
+#define pack_TPMI_ALG_RSA_SCHEME(ptr, t)        pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_RSA_SCHEME(ptr, t)      unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_DH_OBJECT(ptr, o)             pack_TPM2_HANDLE(ptr, o)
+#define unpack_TPMI_DH_OBJECT(PTR, O)           unpack_TPM2_HANDLE(ptr, o)
+#define pack_TPMI_RH_HIERACHY(ptr, h)           pack_TPM2_HANDLE(ptr, h)
+#define unpack_TPMI_RH_HIERACHY(ptr, h)         unpack_TPM2_HANDLE(ptr, h)
+#define pack_TPMI_RH_PLATFORM(ptr, p)           pack_TPM2_HANDLE(ptr, p)
+#define unpack_TPMI_RH_PLATFORM(ptr, p)         unpack_TPM2_HANDLE(ptr, p)
+#define pack_TPMI_RH_OWNER(ptr, o)              pack_TPM2_HANDLE(ptr, o)
+#define unpack_TPMI_RH_OWNER(ptr, o)            unpack_TPM2_HANDLE(ptr, o)
+#define pack_TPMI_RH_ENDORSEMENT(ptr, e)        pack_TPM2_HANDLE(ptr, e)
+#define unpack_TPMI_RH_ENDORSEMENT(ptr, e)      unpack_TPM2_HANDLE(ptr, e)
+#define pack_TPMI_RH_LOCKOUT(ptr, l)            pack_TPM2_HANDLE(ptr, l)
+#define unpack_TPMI_RH_LOCKOUT(ptr, l)          unpack_TPM2_HANDLE(ptr, l)
+
+inline BYTE* pack_TPM2B_DIGEST(BYTE* ptr, const TPM2B_DIGEST *digest)
+{
+    ptr = pack_UINT16(ptr, digest->size);
+    ptr = pack_BUFFER(ptr, digest->buffer, digest->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_DIGEST(BYTE* ptr, TPM2B_DIGEST *digest)
+{
+    ptr = unpack_UINT16(ptr, &digest->size);
+    ptr = unpack_BUFFER(ptr, digest->buffer, digest->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_TK_CREATION(BYTE* ptr,const TPMT_TK_CREATION *ticket )
+{
+    ptr = pack_TPM_ST(ptr , &ticket->tag);
+    ptr = pack_TPMI_RH_HIERACHY(ptr , &ticket->hierarchy);
+    ptr = pack_TPM2B_DIGEST(ptr, &ticket->digest);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_TK_CREATION(BYTE* ptr, TPMT_TK_CREATION *ticket )
+{
+    ptr = unpack_TPM_ST(ptr, &ticket->tag);
+    ptr = unpack_TPMI_RH_HIERACHY(ptr, &ticket->hierarchy);
+    ptr = unpack_TPM2B_DIGEST(ptr, &ticket->digest);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_NAME(BYTE* ptr,const TPM2B_NAME *name )
+{
+    ptr = pack_UINT16(ptr, name->size);
+    ptr = pack_TPM_BUFFER(ptr, name->name, name->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_NAME(BYTE* ptr, TPM2B_NAME *name)
+{
+    ptr = unpack_UINT16(ptr, &name->size);
+    ptr = unpack_TPM_BUFFER(ptr, name->name, name->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_NONCE(BYTE* ptr, const TPM2B_NONCE *nonce)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)nonce);
+}
+
+#define unpack_TPM2B_NONCE(ptr, nonce)  unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)nonce)
+
+inline BYTE* pack_TPM2B_AUTH(BYTE* ptr, const TPM2B_AUTH *auth)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)auth);
+}
+
+#define unpack_TPM2B_AUTH(ptr, auth)    unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)auth)
+
+inline BYTE* pack_TPM2B_DATA(BYTE* ptr, const TPM2B_DATA *data)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)data);
+}
+
+#define unpack_TPM2B_DATA(ptr, data)    unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)data)
+
+inline BYTE* pack_TPM2B_SENSITIVE_DATA(BYTE* ptr, const TPM2B_SENSITIVE_DATA *data)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)data);
+}
+
+#define unpack_TPM2B_SENSITIVE_DATA(ptr, data)  unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)data)
+
+inline BYTE* pack_TPM2B_PUBLIC_KEY_RSA(BYTE* ptr, const TPM2B_PUBLIC_KEY_RSA *rsa)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)rsa);
+}
+
+#define unpack_TPM2B_PUBLIC_KEY_RSA(ptr, rsa)   unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)rsa)
+
+inline BYTE* pack_TPM2B_PRIVATE(BYTE* ptr, const TPM2B_PRIVATE *Private)
+{
+    ptr = pack_UINT16(ptr, Private->size);
+    ptr = pack_TPM_BUFFER(ptr, Private->buffer, Private->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_PRIVATE(BYTE* ptr, TPM2B_PRIVATE *Private)
+{
+    ptr = unpack_UINT16(ptr, &Private->size);
+    ptr = unpack_BUFFER(ptr, Private->buffer, Private->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION_ARRAY(BYTE* ptr, const TPMS_PCR_SELECTION *sel, UINT32 count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+        ptr = pack_TPMI_ALG_HASH(ptr, &sel[i].hash);
+        ptr = pack_BYTE(ptr, sel[i].sizeofSelect);
+        ptr = pack_BUFFER(ptr, sel[i].pcrSelect, sel[i].sizeofSelect);
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_PCR_SELECTION_ARRAY(BYTE* ptr, TPMS_PCR_SELECTION *sel, UINT32 count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+        ptr = unpack_TPMI_ALG_HASH(ptr, &sel[i].hash);
+        ptr = unpack_BYTE(ptr, &sel[i].sizeofSelect);
+        ptr = unpack_BUFFER(ptr, sel[i].pcrSelect, sel[i].sizeofSelect);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPML_PCR_SELECTION(BYTE* ptr, const TPML_PCR_SELECTION *sel)
+{
+    ptr = pack_UINT32(ptr, sel->count);
+    ptr = pack_TPMS_PCR_SELECTION_ARRAY(ptr, sel->pcrSelections, sel->count);
+    return ptr;
+}
+
+inline BYTE* unpack_TPML_PCR_SELECTION(BYTE* ptr, TPML_PCR_SELECTION *sel)
+{
+    ptr = unpack_UINT32(ptr, &sel->count);
+    ptr = unpack_TPMS_PCR_SELECTION_ARRAY(ptr, sel->pcrSelections, sel->count);
+    return ptr;
+}
+
+inline BYTE* unpack_TPML_DIGEST(BYTE* ptr,TPML_DIGEST *digest)
+{
+    int i;
+    ptr = unpack_UINT32(ptr, &digest->count);
+    for (i=0;i<digest->count;i++)
+    {
+        ptr = unpack_TPM2B_DIGEST(ptr, &digest->digests[i]);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_CREATION_DATA(BYTE* ptr,const TPMS_CREATION_DATA *data)
+{
+    ptr = pack_TPML_PCR_SELECTION(ptr, &data->pcrSelect);
+    ptr = pack_TPM2B_DIGEST(ptr, &data->pcrDigest);
+    ptr = pack_TPMA_LOCALITY(ptr, &data->locality);
+    ptr = pack_TPM_ALG_ID(ptr, &data->parentNameAlg);
+    ptr = pack_TPM2B_NAME(ptr, &data->parentQualifiedName);
+    ptr = pack_TPM2B_DATA(ptr, &data->outsideInfo);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_CREATION_DATA(BYTE* ptr, TPMS_CREATION_DATA *data)
+{
+    ptr = unpack_TPML_PCR_SELECTION(ptr, &data->pcrSelect);
+    ptr = unpack_TPM2B_DIGEST(ptr, &data->pcrDigest);
+    ptr = unpack_TPMA_LOCALITY(ptr, &data->locality);
+    ptr = unpack_TPM_ALG_ID(ptr, &data->parentNameAlg);
+    ptr = unpack_TPM2B_NAME(ptr, &data->parentName);
+    ptr = unpack_TPM2B_NAME(ptr, &data->parentQualifiedName);
+    ptr = unpack_TPM2B_DATA(ptr, &data->outsideInfo);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_CREATION_DATA(BYTE* ptr, const TPM2B_CREATION_DATA *data )
+{
+    ptr = pack_UINT16(ptr, data->size);
+    ptr = pack_TPMS_CREATION_DATA(ptr, &data->creationData);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_CREATION_DATA(BYTE* ptr, TPM2B_CREATION_DATA * data)
+{
+    ptr = unpack_UINT16(ptr, &data->size);
+    ptr = unpack_TPMS_CREATION_DATA(ptr, &data->creationData);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_SENSITIVE_CREATE(BYTE* ptr, const TPMS_SENSITIVE_CREATE *create)
+{
+    ptr = pack_TPM2B_AUTH(ptr, &create->userAuth);
+    ptr = pack_TPM2B_SENSITIVE_DATA(ptr, &create->data);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_SENSITIVE_CREATE(BYTE* ptr, const TPM2B_SENSITIVE_CREATE *create)
+{
+    BYTE* sizePtr = ptr;
+    ptr += 2;
+    ptr = pack_TPMS_SENSITIVE_CREATE(ptr, &create->sensitive);
+    pack_UINT16(sizePtr, (UINT16)(ptr - sizePtr - 2));
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_SYM_MODE(BYTE* ptr, const TPMU_SYM_MODE *p,
+                                const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = pack_TPMI_ALG_SYM_MODE(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        case TPM2_ALG_XOR:
+        break;
+    default:
+        ptr = pack_TPMI_ALG_SYM_MODE(ptr, &p->sym);
+    }
+    return ptr;
+}
+inline BYTE* unpack_TPMU_SYM_MODE(BYTE* ptr, TPMU_SYM_MODE *p,
+                                  const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = unpack_TPMI_ALG_SYM_MODE(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+    case TPM2_ALG_XOR:
+        break;
+    default:
+        ptr = unpack_TPMI_ALG_SYM_MODE(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_SYM_KEY_BITS(BYTE* ptr, const TPMU_SYM_KEY_BITS *p,
+                                    const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = pack_TPMI_AES_KEY_BITS(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_XOR:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        ptr = pack_TPM_KEY_BITS(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMU_SYM_KEY_BITS(BYTE* ptr, TPMU_SYM_KEY_BITS *p,
+                                      const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = unpack_TPMI_AES_KEY_BITS(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_XOR:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        ptr = unpack_TPM_KEY_BITS(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_SYM_DEF_OBJECT(BYTE* ptr, const TPMT_SYM_DEF_OBJECT *p)
+{
+    ptr = pack_TPMI_ALG_SYM_OBJECT(ptr, &p->algorithm);
+    ptr = pack_TPMU_SYM_KEY_BITS(ptr, &p->keyBits, &p->algorithm);
+    ptr = pack_TPMU_SYM_MODE(ptr, &p->mode, &p->algorithm);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_SYM_DEF_OBJECT(BYTE *ptr, TPMT_SYM_DEF_OBJECT *p)
+{
+    ptr = unpack_TPMI_ALG_SYM_OBJECT(ptr, &p->algorithm);
+    ptr = unpack_TPMU_SYM_KEY_BITS(ptr, &p->keyBits, &p->algorithm);
+    ptr = unpack_TPMU_SYM_MODE(ptr, &p->mode, &p->algorithm);
+    return ptr;
+}
+
+#define pack_TPMS_SCHEME_OAEP(p, t)     pack_TPMI_ALG_HASH(p, &((t)->hashAlg))
+#define unpack_TPMS_SCHEME_OAEP(p, t)   unpack_TPMI_ALG_HASH(p, &((t)->hashAlg))
+
+inline BYTE* pack_TPMU_ASYM_SCHEME(BYTE *ptr, const TPMU_ASYM_SCHEME *p,
+                                   const TPMI_ALG_RSA_SCHEME *s)
+{
+    switch(*s) {
+#ifdef TPM2_ALG_RSASSA
+    case TPM2_ALG_RSASSA:
+        assert(false || "TPM2_ALG_RSASSA");
+        break;
+#endif
+#ifdef TPM2_ALG_OAEP
+    case TPM2_ALG_OAEP:
+        ptr = pack_TPMS_SCHEME_OAEP(ptr, &p->oaep);
+        break;
+#endif
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        assert(false || "DEFAULT");
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMU_ASYM_SCHEME(BYTE *ptr, TPMU_ASYM_SCHEME *p,
+                                     const TPMI_ALG_RSA_SCHEME *s)
+{
+    switch(*s) {
+    #ifdef TPM2_ALG_RSASSA
+    case TPM2_ALG_RSASSA:
+        printf("not support TPM_ALG_RSASSA\n");
+        assert(false);
+        break;
+    #endif
+    #ifdef TPM2_ALG_OAEP
+    case TPM2_ALG_OAEP:
+        ptr = unpack_TPMS_SCHEME_OAEP(ptr, &p->oaep);
+        break;
+    #endif
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        printf("default TPMI_ALG_RSA_SCHEME 0x%X\n", (UINT32)*s);
+        ptr = unpack_TPMI_ALG_HASH(ptr, &p->anySig.hashAlg);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_RSA_SCHEME(BYTE* ptr, const TPMT_RSA_SCHEME *p)
+{
+    ptr = pack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_RSA_SCHEME(BYTE* ptr, TPMT_RSA_SCHEME *p)
+{
+    ptr = unpack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = unpack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_RSA_DECRYPT(BYTE* ptr, const TPMT_RSA_DECRYPT *p)
+{
+    ptr = pack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_RSA_PARMS(BYTE* ptr, const TPMS_RSA_PARMS *p)
+{
+    ptr = pack_TPMT_SYM_DEF_OBJECT(ptr, &p->symmetric);
+    ptr = pack_TPMT_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMI_RSA_KEY_BITS(ptr, &p->keyBits);
+    ptr = pack_UINT32(ptr, p->exponent);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_RSA_PARMS(BYTE *ptr, TPMS_RSA_PARMS *p)
+{
+    ptr = unpack_TPMT_SYM_DEF_OBJECT(ptr, &p->symmetric);
+    ptr = unpack_TPMT_RSA_SCHEME(ptr, &p->scheme);
+    ptr = unpack_TPMI_RSA_KEY_BITS(ptr, &p->keyBits);
+    ptr = unpack_UINT32(ptr, &p->exponent);
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_PUBLIC_PARMS(BYTE* ptr, const TPMU_PUBLIC_PARMS *param,
+                                    const TPMI_ALG_PUBLIC *selector)
+{
+    switch(*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        assert(false);
+    case TPM2_ALG_SYMCIPHER:
+        assert(false);
+    case TPM2_ALG_RSA:
+        return pack_TPMS_RSA_PARMS(ptr, &param->rsaDetail);
+    case TPM2_ALG_ECC:
+        assert(false);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* unpack_TPMU_PUBLIC_PARMS(BYTE* ptr, TPMU_PUBLIC_PARMS *param,
+                                      const TPMI_ALG_PUBLIC *selector)
+{
+    switch(*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        assert(false);
+    case TPM2_ALG_SYMCIPHER:
+        assert(false);
+    case TPM2_ALG_RSA:
+        return unpack_TPMS_RSA_PARMS(ptr, &param->rsaDetail);
+    case TPM2_ALG_ECC:
+        assert(false);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* pack_TPMS_ECC_POINT(BYTE* ptr, const TPMS_ECC_POINT *point)
+{
+    assert(false);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_ECC_POINT(BYTE* ptr, TPMS_ECC_POINT *point)
+{
+    assert(false);
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_PUBLIC_ID(BYTE* ptr, const TPMU_PUBLIC_ID *id,
+                                 const TPMI_ALG_PUBLIC *selector)
+{
+    switch (*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        return pack_TPM2B_DIGEST(ptr, &id->keyedHash);
+    case TPM2_ALG_SYMCIPHER:
+        return pack_TPM2B_DIGEST(ptr, &id->sym);
+    case TPM2_ALG_RSA:
+        return pack_TPM2B_PUBLIC_KEY_RSA(ptr, &id->rsa);
+    case TPM2_ALG_ECC:
+        return pack_TPMS_ECC_POINT(ptr, &id->ecc);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* unpack_TPMU_PUBLIC_ID(BYTE* ptr, TPMU_PUBLIC_ID *id, TPMI_ALG_PUBLIC *selector)
+{
+    switch (*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        return unpack_TPM2B_DIGEST(ptr, &id->keyedHash);
+    case TPM2_ALG_SYMCIPHER:
+        return unpack_TPM2B_DIGEST(ptr, &id->sym);
+    case TPM2_ALG_RSA:
+        return unpack_TPM2B_PUBLIC_KEY_RSA(ptr, &id->rsa);
+    case TPM2_ALG_ECC:
+        return unpack_TPMS_ECC_POINT(ptr, &id->ecc);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* pack_TPMT_PUBLIC(BYTE* ptr, const TPMT_PUBLIC *public)
+{
+    ptr = pack_TPMI_ALG_PUBLIC(ptr, &public->type);
+    ptr = pack_TPMI_ALG_HASH(ptr, &public->nameAlg);
+    ptr = pack_TPMA_OBJECT(ptr, &public->objectAttributes);
+    ptr = pack_TPM2B_DIGEST(ptr, &public->authPolicy);
+    ptr = pack_TPMU_PUBLIC_PARMS(ptr, &public->parameters, &public->type);
+    ptr = pack_TPMU_PUBLIC_ID(ptr, &public->unique, &public->type);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_PUBLIC(BYTE* ptr, TPMT_PUBLIC *public)
+{
+    ptr = unpack_TPMI_ALG_PUBLIC(ptr, &public->type);
+    ptr = unpack_TPMI_ALG_HASH(ptr, &public->nameAlg);
+    ptr = unpack_TPMA_OBJECT(ptr, &public->objectAttributes);
+    ptr = unpack_TPM2B_DIGEST(ptr, &public->authPolicy);
+    ptr = unpack_TPMU_PUBLIC_PARMS(ptr, &public->parameters, &public->type);
+    ptr = unpack_TPMU_PUBLIC_ID(ptr, &public->unique, &public->type);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_PUBLIC(BYTE* ptr, const TPM2B_PUBLIC *public)
+{
+    BYTE *sizePtr = ptr;
+    ptr += 2;
+    ptr = pack_TPMT_PUBLIC(ptr, &public->publicArea);
+    pack_UINT16(sizePtr, (UINT16)(ptr - sizePtr - 2));
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_PUBLIC(BYTE* ptr, TPM2B_PUBLIC *public)
+{
+    ptr = unpack_UINT16(ptr, &public->size);
+    ptr = unpack_TPMT_PUBLIC(ptr, &public->publicArea);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION(BYTE* ptr, const TPMS_PCR_SELECTION *selection)
+{
+    ptr = pack_TPMI_ALG_HASH(ptr, &selection->hash);
+    ptr = pack_BYTE(ptr, selection->sizeofSelect);
+    ptr = pack_BYTE_ARRAY(ptr, selection->pcrSelect, selection->sizeofSelect);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION_Array(BYTE* ptr, const TPMS_PCR_SELECTION *selections,
+                                           const UINT32 cnt)
+{
+    int i;
+    for (i = 0; i < cnt; i++)
+        ptr = pack_TPMS_PCR_SELECTION(ptr, selections + i);
+    return ptr;
+}
+
+inline BYTE* pack_TPM_AuthArea(BYTE* ptr, const TPM_AuthArea *auth)
+{
+    BYTE* sizePtr = ptr;
+    ptr += sizeof(UINT32);
+    ptr = pack_TPM_RH(ptr, &auth->sessionHandle);
+    ptr = pack_TPM2B_NONCE(ptr, &auth->nonce);
+    ptr = pack_TPMA_SESSION(ptr, &auth->sessionAttributes);
+    ptr = pack_TPM2B_AUTH(ptr, &auth->auth);
+    pack_UINT32(sizePtr, ptr - sizePtr - sizeof(UINT32));
+    return ptr;
+}
+
+inline BYTE* unpack_TPM_AuthArea(BYTE* ptr, TPM_AuthArea *auth)
+{
+    ptr = unpack_UINT32(ptr, &auth->size);
+    ptr = unpack_TPM_RH(ptr, &auth->sessionHandle);
+    ptr = unpack_TPM2B_NONCE(ptr, &auth->nonce);
+    ptr = unpack_TPMA_SESSION(ptr, &auth->sessionAttributes);
+    ptr = unpack_TPM2B_AUTH(ptr, &auth->auth);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2_RSA_KEY(BYTE* ptr, const TPM2_RSA_KEY *key)
+{
+    ptr = pack_TPM2B_PRIVATE(ptr, &key->Private);
+    ptr = pack_TPM2B_PUBLIC(ptr, &key->Public);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2_RSA_KEY(BYTE* ptr, TPM2_RSA_KEY *key)
+{
+    ptr = unpack_TPM2B_PRIVATE(ptr, &key->Private);
+    ptr = unpack_TPM2B_PUBLIC(ptr, &key->Public);
+    return ptr;
+}
+#endif
-- 
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 Dec 17 15:55:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gwv-0006Cj-Bn; Wed, 17 Dec 2014 15:55:41 +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 1Y1Gws-0006Ao-QI
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:39 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	A2/B9-02696-A77A1945; Wed, 17 Dec 2014 15:55:38 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418831735!15739311!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=1.2 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_03_06,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14485 invoked from network); 17 Dec 2014 15:55:35 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-10.tower-27.messagelabs.com with SMTP;
	17 Dec 2014 15:55:35 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga103.jf.intel.com with ESMTP; 17 Dec 2014 07:53:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="655675836"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 17 Dec 2014 07:55:20 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:36 -0500
Message-Id: <1418817096-5270-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 02/14] vTPM/TPM2: TPM 2.0 data structures
	marshal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 TPM 2.0 data structure marshal for packing and unpacking TPM
2.0 data structures.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/tpm2_marshal.h | 673 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 673 insertions(+)
 create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h

diff --git a/stubdom/vtpmmgr/tpm2_marshal.h b/stubdom/vtpmmgr/tpm2_marshal.h
new file mode 100644
index 0000000..aaa4464
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2_marshal.h
@@ -0,0 +1,673 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef TPM2_MARSHAL_H
+#define TPM2_MARSHAL_H
+
+#include <stdlib.h>
+#include <mini-os/byteorder.h>
+#include <mini-os/endian.h>
+#include "tcg.h"
+#include "tpm2_types.h"
+#include <assert.h>
+
+#define pack_TPM_BUFFER(ptr, buf, size) pack_BUFFER(ptr, buf, size)
+#define unpack_TPM_BUFFER(ptr, buf, size) unpack_BUFFER(ptr, buf, size)
+
+inline BYTE* pack_BYTE_ARRAY(BYTE* ptr, const BYTE* array, UINT32 size)
+{
+    int i;
+    for (i = 0; i < size; i++)
+         ptr = pack_BYTE(ptr, array[i]);
+    return ptr;
+}
+
+inline BYTE* pack_TPMA_SESSION(BYTE* ptr, const TPMA_SESSION *attr)
+{
+    return pack_BYTE(ptr, (BYTE)(*attr));
+}
+
+inline BYTE* unpack_TPMA_SESSION(BYTE* ptr, TPMA_SESSION *attr)
+{
+    return unpack_BYTE(ptr, (BYTE *)attr);
+}
+
+inline BYTE* pack_TPMI_ALG_HASH(BYTE* ptr, const TPMI_ALG_HASH *hash)
+{
+    return pack_UINT16(ptr, *hash);
+}
+
+inline BYTE* unpack_TPMI_ALG_HASH(BYTE *ptr, TPMI_ALG_HASH *hash)
+{
+    return unpack_UINT16(ptr, hash);
+}
+
+#define pack_TPMA_OBJECT(ptr, t)                pack_UINT32(ptr, (UINT32)(*t))
+#define unpack_TPMA_OBJECT(ptr, t)              unpack_UINT32(ptr, (UINT32 *)(t))
+#define pack_TPM_RH(ptr, t)                     pack_UINT32(ptr, (UINT32)(*t))
+#define unpack_TPM_RH(ptr, t)                   unpack_UINT32(ptr, (UINT32 *)(t))
+#define pack_TPMA_LOCALITY(ptr, locality)       pack_BYTE(ptr, (BYTE)*locality)
+#define unpack_TPMA_LOCALITY(ptr, locality)     unpack_BYTE(ptr, (BYTE *)locality)
+#define pack_TPM_ST(ptr, tag)                   pack_UINT16(ptr, *tag)
+#define unpack_TPM_ST(ptr, tag)                 unpack_UINT16(ptr, tag)
+#define pack_TPM_KEY_BITS(ptr, t)               pack_UINT16(ptr, *t)
+#define unpack_TPM_KEY_BITS(ptr, t)             unpack_UINT16(ptr, t)
+#define pack_TPMI_AES_KEY_BITS(ptr, t)          pack_TPM_KEY_BITS(ptr, t)
+#define unpack_TPMI_AES_KEY_BITS(ptr, t)        unpack_TPM_KEY_BITS(ptr, t)
+#define pack_TPMI_RSA_KEY_BITS(ptr, t)          pack_TPM_KEY_BITS(ptr, t)
+#define unpack_TPMI_RSA_KEY_BITS(ptr, t)        unpack_TPM_KEY_BITS(ptr, t)
+#define pack_TPM_ALG_ID(ptr, id)                pack_UINT16(ptr, *id)
+#define unpack_TPM_ALG_ID(ptr, id)              unpack_UINT16(ptr, id)
+#define pack_TPM_ALG_SYM(ptr, t)                pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPM_ALG_SYM(ptr, t)              unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_ASYM(ptr, asym)           pack_TPM_ALG_ID(ptr, asym)
+#define unpack_TPMI_ALG_ASYM(ptr, asym)         unpack_TPM_ALG_ID(ptr, asym)
+#define pack_TPMI_ALG_SYM_OBJECT(ptr, t)        pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_SYM_OBJECT(ptr, t)      unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_SYM_MODE(ptr, t)          pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_SYM_MODE(ptr, t)        unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_KDF(ptr, t)               pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_KDF(ptr, t)             unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_PUBLIC(ptr, t)            pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_PUBLIC(ptr, t)          unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPM2_HANDLE(ptr, h)                pack_UINT32(ptr, *h)
+#define unpack_TPM2_HANDLE(ptr, h)              unpack_UINT32(ptr, h)
+#define pack_TPMI_ALG_RSA_SCHEME(ptr, t)        pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_RSA_SCHEME(ptr, t)      unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_DH_OBJECT(ptr, o)             pack_TPM2_HANDLE(ptr, o)
+#define unpack_TPMI_DH_OBJECT(PTR, O)           unpack_TPM2_HANDLE(ptr, o)
+#define pack_TPMI_RH_HIERACHY(ptr, h)           pack_TPM2_HANDLE(ptr, h)
+#define unpack_TPMI_RH_HIERACHY(ptr, h)         unpack_TPM2_HANDLE(ptr, h)
+#define pack_TPMI_RH_PLATFORM(ptr, p)           pack_TPM2_HANDLE(ptr, p)
+#define unpack_TPMI_RH_PLATFORM(ptr, p)         unpack_TPM2_HANDLE(ptr, p)
+#define pack_TPMI_RH_OWNER(ptr, o)              pack_TPM2_HANDLE(ptr, o)
+#define unpack_TPMI_RH_OWNER(ptr, o)            unpack_TPM2_HANDLE(ptr, o)
+#define pack_TPMI_RH_ENDORSEMENT(ptr, e)        pack_TPM2_HANDLE(ptr, e)
+#define unpack_TPMI_RH_ENDORSEMENT(ptr, e)      unpack_TPM2_HANDLE(ptr, e)
+#define pack_TPMI_RH_LOCKOUT(ptr, l)            pack_TPM2_HANDLE(ptr, l)
+#define unpack_TPMI_RH_LOCKOUT(ptr, l)          unpack_TPM2_HANDLE(ptr, l)
+
+inline BYTE* pack_TPM2B_DIGEST(BYTE* ptr, const TPM2B_DIGEST *digest)
+{
+    ptr = pack_UINT16(ptr, digest->size);
+    ptr = pack_BUFFER(ptr, digest->buffer, digest->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_DIGEST(BYTE* ptr, TPM2B_DIGEST *digest)
+{
+    ptr = unpack_UINT16(ptr, &digest->size);
+    ptr = unpack_BUFFER(ptr, digest->buffer, digest->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_TK_CREATION(BYTE* ptr,const TPMT_TK_CREATION *ticket )
+{
+    ptr = pack_TPM_ST(ptr , &ticket->tag);
+    ptr = pack_TPMI_RH_HIERACHY(ptr , &ticket->hierarchy);
+    ptr = pack_TPM2B_DIGEST(ptr, &ticket->digest);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_TK_CREATION(BYTE* ptr, TPMT_TK_CREATION *ticket )
+{
+    ptr = unpack_TPM_ST(ptr, &ticket->tag);
+    ptr = unpack_TPMI_RH_HIERACHY(ptr, &ticket->hierarchy);
+    ptr = unpack_TPM2B_DIGEST(ptr, &ticket->digest);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_NAME(BYTE* ptr,const TPM2B_NAME *name )
+{
+    ptr = pack_UINT16(ptr, name->size);
+    ptr = pack_TPM_BUFFER(ptr, name->name, name->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_NAME(BYTE* ptr, TPM2B_NAME *name)
+{
+    ptr = unpack_UINT16(ptr, &name->size);
+    ptr = unpack_TPM_BUFFER(ptr, name->name, name->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_NONCE(BYTE* ptr, const TPM2B_NONCE *nonce)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)nonce);
+}
+
+#define unpack_TPM2B_NONCE(ptr, nonce)  unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)nonce)
+
+inline BYTE* pack_TPM2B_AUTH(BYTE* ptr, const TPM2B_AUTH *auth)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)auth);
+}
+
+#define unpack_TPM2B_AUTH(ptr, auth)    unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)auth)
+
+inline BYTE* pack_TPM2B_DATA(BYTE* ptr, const TPM2B_DATA *data)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)data);
+}
+
+#define unpack_TPM2B_DATA(ptr, data)    unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)data)
+
+inline BYTE* pack_TPM2B_SENSITIVE_DATA(BYTE* ptr, const TPM2B_SENSITIVE_DATA *data)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)data);
+}
+
+#define unpack_TPM2B_SENSITIVE_DATA(ptr, data)  unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)data)
+
+inline BYTE* pack_TPM2B_PUBLIC_KEY_RSA(BYTE* ptr, const TPM2B_PUBLIC_KEY_RSA *rsa)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)rsa);
+}
+
+#define unpack_TPM2B_PUBLIC_KEY_RSA(ptr, rsa)   unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)rsa)
+
+inline BYTE* pack_TPM2B_PRIVATE(BYTE* ptr, const TPM2B_PRIVATE *Private)
+{
+    ptr = pack_UINT16(ptr, Private->size);
+    ptr = pack_TPM_BUFFER(ptr, Private->buffer, Private->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_PRIVATE(BYTE* ptr, TPM2B_PRIVATE *Private)
+{
+    ptr = unpack_UINT16(ptr, &Private->size);
+    ptr = unpack_BUFFER(ptr, Private->buffer, Private->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION_ARRAY(BYTE* ptr, const TPMS_PCR_SELECTION *sel, UINT32 count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+        ptr = pack_TPMI_ALG_HASH(ptr, &sel[i].hash);
+        ptr = pack_BYTE(ptr, sel[i].sizeofSelect);
+        ptr = pack_BUFFER(ptr, sel[i].pcrSelect, sel[i].sizeofSelect);
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_PCR_SELECTION_ARRAY(BYTE* ptr, TPMS_PCR_SELECTION *sel, UINT32 count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+        ptr = unpack_TPMI_ALG_HASH(ptr, &sel[i].hash);
+        ptr = unpack_BYTE(ptr, &sel[i].sizeofSelect);
+        ptr = unpack_BUFFER(ptr, sel[i].pcrSelect, sel[i].sizeofSelect);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPML_PCR_SELECTION(BYTE* ptr, const TPML_PCR_SELECTION *sel)
+{
+    ptr = pack_UINT32(ptr, sel->count);
+    ptr = pack_TPMS_PCR_SELECTION_ARRAY(ptr, sel->pcrSelections, sel->count);
+    return ptr;
+}
+
+inline BYTE* unpack_TPML_PCR_SELECTION(BYTE* ptr, TPML_PCR_SELECTION *sel)
+{
+    ptr = unpack_UINT32(ptr, &sel->count);
+    ptr = unpack_TPMS_PCR_SELECTION_ARRAY(ptr, sel->pcrSelections, sel->count);
+    return ptr;
+}
+
+inline BYTE* unpack_TPML_DIGEST(BYTE* ptr,TPML_DIGEST *digest)
+{
+    int i;
+    ptr = unpack_UINT32(ptr, &digest->count);
+    for (i=0;i<digest->count;i++)
+    {
+        ptr = unpack_TPM2B_DIGEST(ptr, &digest->digests[i]);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_CREATION_DATA(BYTE* ptr,const TPMS_CREATION_DATA *data)
+{
+    ptr = pack_TPML_PCR_SELECTION(ptr, &data->pcrSelect);
+    ptr = pack_TPM2B_DIGEST(ptr, &data->pcrDigest);
+    ptr = pack_TPMA_LOCALITY(ptr, &data->locality);
+    ptr = pack_TPM_ALG_ID(ptr, &data->parentNameAlg);
+    ptr = pack_TPM2B_NAME(ptr, &data->parentQualifiedName);
+    ptr = pack_TPM2B_DATA(ptr, &data->outsideInfo);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_CREATION_DATA(BYTE* ptr, TPMS_CREATION_DATA *data)
+{
+    ptr = unpack_TPML_PCR_SELECTION(ptr, &data->pcrSelect);
+    ptr = unpack_TPM2B_DIGEST(ptr, &data->pcrDigest);
+    ptr = unpack_TPMA_LOCALITY(ptr, &data->locality);
+    ptr = unpack_TPM_ALG_ID(ptr, &data->parentNameAlg);
+    ptr = unpack_TPM2B_NAME(ptr, &data->parentName);
+    ptr = unpack_TPM2B_NAME(ptr, &data->parentQualifiedName);
+    ptr = unpack_TPM2B_DATA(ptr, &data->outsideInfo);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_CREATION_DATA(BYTE* ptr, const TPM2B_CREATION_DATA *data )
+{
+    ptr = pack_UINT16(ptr, data->size);
+    ptr = pack_TPMS_CREATION_DATA(ptr, &data->creationData);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_CREATION_DATA(BYTE* ptr, TPM2B_CREATION_DATA * data)
+{
+    ptr = unpack_UINT16(ptr, &data->size);
+    ptr = unpack_TPMS_CREATION_DATA(ptr, &data->creationData);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_SENSITIVE_CREATE(BYTE* ptr, const TPMS_SENSITIVE_CREATE *create)
+{
+    ptr = pack_TPM2B_AUTH(ptr, &create->userAuth);
+    ptr = pack_TPM2B_SENSITIVE_DATA(ptr, &create->data);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_SENSITIVE_CREATE(BYTE* ptr, const TPM2B_SENSITIVE_CREATE *create)
+{
+    BYTE* sizePtr = ptr;
+    ptr += 2;
+    ptr = pack_TPMS_SENSITIVE_CREATE(ptr, &create->sensitive);
+    pack_UINT16(sizePtr, (UINT16)(ptr - sizePtr - 2));
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_SYM_MODE(BYTE* ptr, const TPMU_SYM_MODE *p,
+                                const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = pack_TPMI_ALG_SYM_MODE(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        case TPM2_ALG_XOR:
+        break;
+    default:
+        ptr = pack_TPMI_ALG_SYM_MODE(ptr, &p->sym);
+    }
+    return ptr;
+}
+inline BYTE* unpack_TPMU_SYM_MODE(BYTE* ptr, TPMU_SYM_MODE *p,
+                                  const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = unpack_TPMI_ALG_SYM_MODE(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+    case TPM2_ALG_XOR:
+        break;
+    default:
+        ptr = unpack_TPMI_ALG_SYM_MODE(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_SYM_KEY_BITS(BYTE* ptr, const TPMU_SYM_KEY_BITS *p,
+                                    const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = pack_TPMI_AES_KEY_BITS(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_XOR:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        ptr = pack_TPM_KEY_BITS(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMU_SYM_KEY_BITS(BYTE* ptr, TPMU_SYM_KEY_BITS *p,
+                                      const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = unpack_TPMI_AES_KEY_BITS(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_XOR:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        ptr = unpack_TPM_KEY_BITS(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_SYM_DEF_OBJECT(BYTE* ptr, const TPMT_SYM_DEF_OBJECT *p)
+{
+    ptr = pack_TPMI_ALG_SYM_OBJECT(ptr, &p->algorithm);
+    ptr = pack_TPMU_SYM_KEY_BITS(ptr, &p->keyBits, &p->algorithm);
+    ptr = pack_TPMU_SYM_MODE(ptr, &p->mode, &p->algorithm);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_SYM_DEF_OBJECT(BYTE *ptr, TPMT_SYM_DEF_OBJECT *p)
+{
+    ptr = unpack_TPMI_ALG_SYM_OBJECT(ptr, &p->algorithm);
+    ptr = unpack_TPMU_SYM_KEY_BITS(ptr, &p->keyBits, &p->algorithm);
+    ptr = unpack_TPMU_SYM_MODE(ptr, &p->mode, &p->algorithm);
+    return ptr;
+}
+
+#define pack_TPMS_SCHEME_OAEP(p, t)     pack_TPMI_ALG_HASH(p, &((t)->hashAlg))
+#define unpack_TPMS_SCHEME_OAEP(p, t)   unpack_TPMI_ALG_HASH(p, &((t)->hashAlg))
+
+inline BYTE* pack_TPMU_ASYM_SCHEME(BYTE *ptr, const TPMU_ASYM_SCHEME *p,
+                                   const TPMI_ALG_RSA_SCHEME *s)
+{
+    switch(*s) {
+#ifdef TPM2_ALG_RSASSA
+    case TPM2_ALG_RSASSA:
+        assert(false || "TPM2_ALG_RSASSA");
+        break;
+#endif
+#ifdef TPM2_ALG_OAEP
+    case TPM2_ALG_OAEP:
+        ptr = pack_TPMS_SCHEME_OAEP(ptr, &p->oaep);
+        break;
+#endif
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        assert(false || "DEFAULT");
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMU_ASYM_SCHEME(BYTE *ptr, TPMU_ASYM_SCHEME *p,
+                                     const TPMI_ALG_RSA_SCHEME *s)
+{
+    switch(*s) {
+    #ifdef TPM2_ALG_RSASSA
+    case TPM2_ALG_RSASSA:
+        printf("not support TPM_ALG_RSASSA\n");
+        assert(false);
+        break;
+    #endif
+    #ifdef TPM2_ALG_OAEP
+    case TPM2_ALG_OAEP:
+        ptr = unpack_TPMS_SCHEME_OAEP(ptr, &p->oaep);
+        break;
+    #endif
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        printf("default TPMI_ALG_RSA_SCHEME 0x%X\n", (UINT32)*s);
+        ptr = unpack_TPMI_ALG_HASH(ptr, &p->anySig.hashAlg);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_RSA_SCHEME(BYTE* ptr, const TPMT_RSA_SCHEME *p)
+{
+    ptr = pack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_RSA_SCHEME(BYTE* ptr, TPMT_RSA_SCHEME *p)
+{
+    ptr = unpack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = unpack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_RSA_DECRYPT(BYTE* ptr, const TPMT_RSA_DECRYPT *p)
+{
+    ptr = pack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_RSA_PARMS(BYTE* ptr, const TPMS_RSA_PARMS *p)
+{
+    ptr = pack_TPMT_SYM_DEF_OBJECT(ptr, &p->symmetric);
+    ptr = pack_TPMT_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMI_RSA_KEY_BITS(ptr, &p->keyBits);
+    ptr = pack_UINT32(ptr, p->exponent);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_RSA_PARMS(BYTE *ptr, TPMS_RSA_PARMS *p)
+{
+    ptr = unpack_TPMT_SYM_DEF_OBJECT(ptr, &p->symmetric);
+    ptr = unpack_TPMT_RSA_SCHEME(ptr, &p->scheme);
+    ptr = unpack_TPMI_RSA_KEY_BITS(ptr, &p->keyBits);
+    ptr = unpack_UINT32(ptr, &p->exponent);
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_PUBLIC_PARMS(BYTE* ptr, const TPMU_PUBLIC_PARMS *param,
+                                    const TPMI_ALG_PUBLIC *selector)
+{
+    switch(*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        assert(false);
+    case TPM2_ALG_SYMCIPHER:
+        assert(false);
+    case TPM2_ALG_RSA:
+        return pack_TPMS_RSA_PARMS(ptr, &param->rsaDetail);
+    case TPM2_ALG_ECC:
+        assert(false);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* unpack_TPMU_PUBLIC_PARMS(BYTE* ptr, TPMU_PUBLIC_PARMS *param,
+                                      const TPMI_ALG_PUBLIC *selector)
+{
+    switch(*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        assert(false);
+    case TPM2_ALG_SYMCIPHER:
+        assert(false);
+    case TPM2_ALG_RSA:
+        return unpack_TPMS_RSA_PARMS(ptr, &param->rsaDetail);
+    case TPM2_ALG_ECC:
+        assert(false);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* pack_TPMS_ECC_POINT(BYTE* ptr, const TPMS_ECC_POINT *point)
+{
+    assert(false);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_ECC_POINT(BYTE* ptr, TPMS_ECC_POINT *point)
+{
+    assert(false);
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_PUBLIC_ID(BYTE* ptr, const TPMU_PUBLIC_ID *id,
+                                 const TPMI_ALG_PUBLIC *selector)
+{
+    switch (*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        return pack_TPM2B_DIGEST(ptr, &id->keyedHash);
+    case TPM2_ALG_SYMCIPHER:
+        return pack_TPM2B_DIGEST(ptr, &id->sym);
+    case TPM2_ALG_RSA:
+        return pack_TPM2B_PUBLIC_KEY_RSA(ptr, &id->rsa);
+    case TPM2_ALG_ECC:
+        return pack_TPMS_ECC_POINT(ptr, &id->ecc);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* unpack_TPMU_PUBLIC_ID(BYTE* ptr, TPMU_PUBLIC_ID *id, TPMI_ALG_PUBLIC *selector)
+{
+    switch (*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        return unpack_TPM2B_DIGEST(ptr, &id->keyedHash);
+    case TPM2_ALG_SYMCIPHER:
+        return unpack_TPM2B_DIGEST(ptr, &id->sym);
+    case TPM2_ALG_RSA:
+        return unpack_TPM2B_PUBLIC_KEY_RSA(ptr, &id->rsa);
+    case TPM2_ALG_ECC:
+        return unpack_TPMS_ECC_POINT(ptr, &id->ecc);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* pack_TPMT_PUBLIC(BYTE* ptr, const TPMT_PUBLIC *public)
+{
+    ptr = pack_TPMI_ALG_PUBLIC(ptr, &public->type);
+    ptr = pack_TPMI_ALG_HASH(ptr, &public->nameAlg);
+    ptr = pack_TPMA_OBJECT(ptr, &public->objectAttributes);
+    ptr = pack_TPM2B_DIGEST(ptr, &public->authPolicy);
+    ptr = pack_TPMU_PUBLIC_PARMS(ptr, &public->parameters, &public->type);
+    ptr = pack_TPMU_PUBLIC_ID(ptr, &public->unique, &public->type);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_PUBLIC(BYTE* ptr, TPMT_PUBLIC *public)
+{
+    ptr = unpack_TPMI_ALG_PUBLIC(ptr, &public->type);
+    ptr = unpack_TPMI_ALG_HASH(ptr, &public->nameAlg);
+    ptr = unpack_TPMA_OBJECT(ptr, &public->objectAttributes);
+    ptr = unpack_TPM2B_DIGEST(ptr, &public->authPolicy);
+    ptr = unpack_TPMU_PUBLIC_PARMS(ptr, &public->parameters, &public->type);
+    ptr = unpack_TPMU_PUBLIC_ID(ptr, &public->unique, &public->type);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_PUBLIC(BYTE* ptr, const TPM2B_PUBLIC *public)
+{
+    BYTE *sizePtr = ptr;
+    ptr += 2;
+    ptr = pack_TPMT_PUBLIC(ptr, &public->publicArea);
+    pack_UINT16(sizePtr, (UINT16)(ptr - sizePtr - 2));
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_PUBLIC(BYTE* ptr, TPM2B_PUBLIC *public)
+{
+    ptr = unpack_UINT16(ptr, &public->size);
+    ptr = unpack_TPMT_PUBLIC(ptr, &public->publicArea);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION(BYTE* ptr, const TPMS_PCR_SELECTION *selection)
+{
+    ptr = pack_TPMI_ALG_HASH(ptr, &selection->hash);
+    ptr = pack_BYTE(ptr, selection->sizeofSelect);
+    ptr = pack_BYTE_ARRAY(ptr, selection->pcrSelect, selection->sizeofSelect);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION_Array(BYTE* ptr, const TPMS_PCR_SELECTION *selections,
+                                           const UINT32 cnt)
+{
+    int i;
+    for (i = 0; i < cnt; i++)
+        ptr = pack_TPMS_PCR_SELECTION(ptr, selections + i);
+    return ptr;
+}
+
+inline BYTE* pack_TPM_AuthArea(BYTE* ptr, const TPM_AuthArea *auth)
+{
+    BYTE* sizePtr = ptr;
+    ptr += sizeof(UINT32);
+    ptr = pack_TPM_RH(ptr, &auth->sessionHandle);
+    ptr = pack_TPM2B_NONCE(ptr, &auth->nonce);
+    ptr = pack_TPMA_SESSION(ptr, &auth->sessionAttributes);
+    ptr = pack_TPM2B_AUTH(ptr, &auth->auth);
+    pack_UINT32(sizePtr, ptr - sizePtr - sizeof(UINT32));
+    return ptr;
+}
+
+inline BYTE* unpack_TPM_AuthArea(BYTE* ptr, TPM_AuthArea *auth)
+{
+    ptr = unpack_UINT32(ptr, &auth->size);
+    ptr = unpack_TPM_RH(ptr, &auth->sessionHandle);
+    ptr = unpack_TPM2B_NONCE(ptr, &auth->nonce);
+    ptr = unpack_TPMA_SESSION(ptr, &auth->sessionAttributes);
+    ptr = unpack_TPM2B_AUTH(ptr, &auth->auth);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2_RSA_KEY(BYTE* ptr, const TPM2_RSA_KEY *key)
+{
+    ptr = pack_TPM2B_PRIVATE(ptr, &key->Private);
+    ptr = pack_TPM2B_PUBLIC(ptr, &key->Public);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2_RSA_KEY(BYTE* ptr, TPM2_RSA_KEY *key)
+{
+    ptr = unpack_TPM2B_PRIVATE(ptr, &key->Private);
+    ptr = unpack_TPM2B_PUBLIC(ptr, &key->Public);
+    return ptr;
+}
+#endif
-- 
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 Dec 17 15:55:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gx5-0006LA-Eq; Wed, 17 Dec 2014 15:55:51 +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 1Y1Gx3-0006Ik-LF
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:49 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	20/A1-26858-487A1945; Wed, 17 Dec 2014 15:55:48 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418831745!14118492!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25581 invoked from network); 17 Dec 2014 15:55:48 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 15:55:48 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2014 07:55:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="649193498"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 17 Dec 2014 07:55:46 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:52:03 -0500
Message-Id: <1418817123-5570-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 10/14] vTPM/TPM2: TPM 2.0 PCRs 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/init.c       | 34 ++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2_types.h |  2 ++
 stubdom/vtpmmgr/vtpmmgr.h    |  1 +
 3 files changed, 37 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 7e115a5..8bab764 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -51,6 +51,7 @@
 #include "vtpm_disk.h"
 #include "tpm.h"
 #include "marshal.h"
+#include "tpm2_marshal.h"
 #include "tpm2.h"
 
 struct Opts {
@@ -790,3 +791,36 @@ abort_egress:
 egress:
     return status;
 }
+
+TPM_RC tpm2_pcr_read(int index, uint8_t *buf)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+    TPML_PCR_SELECTION pcrSelectionIn = {
+        .count = 1,};
+
+    TPMS_PCR_SELECTION tpms_pcr_selection = {
+        .hash = TPM2_ALG_SHA1,
+        .sizeofSelect = PCR_SELECT_MAX,};
+
+    UINT32 pcrUpdateCounter;
+    TPML_PCR_SELECTION pcrSelectionOut;
+    TPML_DIGEST pcrValues;
+    TPM2B_DIGEST tpm2b_digest;
+
+    tpms_pcr_selection.pcrSelect[PCR_SELECT_NUM(index)] = PCR_SELECT_VALUE(index);
+    memcpy(&pcrSelectionIn.pcrSelections[0], &tpms_pcr_selection,
+           sizeof(TPMS_PCR_SELECTION));
+
+    TPMTRYRETURN(TPM2_PCR_Read(pcrSelectionIn, &pcrUpdateCounter,
+                               &pcrSelectionOut, &pcrValues));
+
+    if (pcrValues.count < 1)
+        goto egress;
+
+    unpack_TPM2B_DIGEST((uint8_t *) &pcrValues, &tpm2b_digest);
+    memcpy(buf, tpm2b_digest.buffer, SHA1_DIGEST_SIZE);
+
+abort_egress:
+egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/tpm2_types.h b/stubdom/vtpmmgr/tpm2_types.h
index 214335c..ac2830d 100644
--- a/stubdom/vtpmmgr/tpm2_types.h
+++ b/stubdom/vtpmmgr/tpm2_types.h
@@ -432,6 +432,8 @@ typedef struct {
 #define    IMPLEMENTATION_PCR   24
 #define    PLATFORM_PCR         24
 #define    PCR_SELECT_MAX       ((IMPLEMENTATION_PCR+7)/8)
+#define    PCR_SELECT_NUM(x)    (uint8_t)(x/8)
+#define    PCR_SELECT_VALUE(x)  (uint8_t)(0x1)<<(x%8)
 
 //Table 79 -- TPMS_PCR_SELECT Structure <I/O>
 typedef struct {
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 6a76af4..12ca71d 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -107,6 +107,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 
 /* TPM 2.0 */
 TPM_RC tpm2_take_ownership(void);
+TPM_RC tpm2_pcr_read(int index, uint8_t *buf);
 TPM_RESULT vtpmmgr2_create(void);
 TPM_RESULT vtpmmgr2_init(int argc, char** argv);
 int parse_cmdline_hw(int argc, char** argv);
-- 
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 Dec 17 15:55:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:55:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Gx5-0006LA-Eq; Wed, 17 Dec 2014 15:55:51 +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 1Y1Gx3-0006Ik-LF
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:49 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	20/A1-26858-487A1945; Wed, 17 Dec 2014 15:55:48 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418831745!14118492!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25581 invoked from network); 17 Dec 2014 15:55:48 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 15:55:48 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2014 07:55:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="649193498"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 17 Dec 2014 07:55:46 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:52:03 -0500
Message-Id: <1418817123-5570-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 10/14] vTPM/TPM2: TPM 2.0 PCRs 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/init.c       | 34 ++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2_types.h |  2 ++
 stubdom/vtpmmgr/vtpmmgr.h    |  1 +
 3 files changed, 37 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 7e115a5..8bab764 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -51,6 +51,7 @@
 #include "vtpm_disk.h"
 #include "tpm.h"
 #include "marshal.h"
+#include "tpm2_marshal.h"
 #include "tpm2.h"
 
 struct Opts {
@@ -790,3 +791,36 @@ abort_egress:
 egress:
     return status;
 }
+
+TPM_RC tpm2_pcr_read(int index, uint8_t *buf)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+    TPML_PCR_SELECTION pcrSelectionIn = {
+        .count = 1,};
+
+    TPMS_PCR_SELECTION tpms_pcr_selection = {
+        .hash = TPM2_ALG_SHA1,
+        .sizeofSelect = PCR_SELECT_MAX,};
+
+    UINT32 pcrUpdateCounter;
+    TPML_PCR_SELECTION pcrSelectionOut;
+    TPML_DIGEST pcrValues;
+    TPM2B_DIGEST tpm2b_digest;
+
+    tpms_pcr_selection.pcrSelect[PCR_SELECT_NUM(index)] = PCR_SELECT_VALUE(index);
+    memcpy(&pcrSelectionIn.pcrSelections[0], &tpms_pcr_selection,
+           sizeof(TPMS_PCR_SELECTION));
+
+    TPMTRYRETURN(TPM2_PCR_Read(pcrSelectionIn, &pcrUpdateCounter,
+                               &pcrSelectionOut, &pcrValues));
+
+    if (pcrValues.count < 1)
+        goto egress;
+
+    unpack_TPM2B_DIGEST((uint8_t *) &pcrValues, &tpm2b_digest);
+    memcpy(buf, tpm2b_digest.buffer, SHA1_DIGEST_SIZE);
+
+abort_egress:
+egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/tpm2_types.h b/stubdom/vtpmmgr/tpm2_types.h
index 214335c..ac2830d 100644
--- a/stubdom/vtpmmgr/tpm2_types.h
+++ b/stubdom/vtpmmgr/tpm2_types.h
@@ -432,6 +432,8 @@ typedef struct {
 #define    IMPLEMENTATION_PCR   24
 #define    PLATFORM_PCR         24
 #define    PCR_SELECT_MAX       ((IMPLEMENTATION_PCR+7)/8)
+#define    PCR_SELECT_NUM(x)    (uint8_t)(x/8)
+#define    PCR_SELECT_VALUE(x)  (uint8_t)(0x1)<<(x%8)
 
 //Table 79 -- TPMS_PCR_SELECT Structure <I/O>
 typedef struct {
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 6a76af4..12ca71d 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -107,6 +107,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 
 /* TPM 2.0 */
 TPM_RC tpm2_take_ownership(void);
+TPM_RC tpm2_pcr_read(int index, uint8_t *buf);
 TPM_RESULT vtpmmgr2_create(void);
 TPM_RESULT vtpmmgr2_init(int argc, char** argv);
 int parse_cmdline_hw(int argc, char** argv);
-- 
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 Dec 17 15:55:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 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 1Y1Gx6-0006Mg-TA; Wed, 17 Dec 2014 15:55: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 1Y1Gx4-0006JU-Fe
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:50 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	CF/4D-08051-587A1945; Wed, 17 Dec 2014 15:55:49 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418831747!15705655!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28372 invoked from network); 17 Dec 2014 15:55:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-27.messagelabs.com with SMTP;
	17 Dec 2014 15:55:48 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 17 Dec 2014 07:53:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="625307665"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 17 Dec 2014 07:55:40 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:57 -0500
Message-Id: <1418817117-5496-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 08/14] vTPM/TPM2: Add main entrance
	vtpmmgr2_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

Accept commands from the vtpm-stubdom domains via the mini-os TPM
backend driver. The vTPM manager communicates directly with hardware
TPM 2.0 using the mini-os tpm2_tis driver.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/init.c    | 109 ++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.h |   1 +
 2 files changed, 110 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 8244bb0..7e115a5 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -681,3 +681,112 @@ egress:
     vtpmloginfo(VTPM_LOG_VTPM, "Finished initialized new VTPM manager\n");
     return status;
 }
+
+static int tpm2_entropy_source(void* dummy, unsigned char* data,
+                               size_t len, size_t* olen)
+{
+    UINT32 sz = len;
+    TPM_RESULT rc = TPM2_GetRandom(&sz, data);
+    *olen = sz;
+    return rc == TPM_SUCCESS ? 0 : POLARSSL_ERR_ENTROPY_SOURCE_FAILED;
+}
+
+/*TPM 2.0 Objects flush */
+static TPM_RC flush_tpm2(void)
+{
+    int i;
+
+    for (i = TRANSIENT_FIRST; i < TRANSIENT_LAST; i++)
+         TPM2_FlushContext(i);
+
+    return TPM_SUCCESS;
+}
+
+TPM_RESULT vtpmmgr2_init(int argc, char** argv)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+
+    /* Default commandline options */
+    struct Opts opts = {
+        .tpmdriver = TPMDRV_TPM_TIS,
+        .tpmiomem = TPM_BASEADDR,
+        .tpmirq = 0,
+        .tpmlocality = 0,
+        .gen_owner_auth = 0,
+    };
+
+    if (parse_cmdline_opts(argc, argv, &opts) != 0) {
+        vtpmlogerror(VTPM_LOG_VTPM, "Command line parsing failed! exiting..\n");
+        status = TPM_BAD_PARAMETER;
+        goto abort_egress;
+    }
+
+    /*Setup storage system*/
+    if (vtpm_storage_init() != 0) {
+        vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize storage subsystem!\n");
+        status = TPM_IOERROR;
+        goto abort_egress;
+    }
+
+    /*Setup tpmback device*/
+    init_tpmback(set_opaque, free_opaque);
+
+    /*Setup tpm access*/
+    switch(opts.tpmdriver) {
+        case TPMDRV_TPM_TIS:
+        {
+            struct tpm_chip* tpm;
+            if ((tpm = init_tpm2_tis(opts.tpmiomem, TPM_TIS_LOCL_INT_TO_FLAG(opts.tpmlocality),
+                                     opts.tpmirq)) == NULL) {
+                vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize tpmfront device\n");
+                status = TPM_IOERROR;
+                goto abort_egress;
+            }
+            printk("init_tpm2_tis()       ...ok\n");
+            vtpm_globals.tpm_fd = tpm_tis_open(tpm);
+            tpm_tis_request_locality(tpm, opts.tpmlocality);
+        }
+        break;
+        case TPMDRV_TPMFRONT:
+        {
+            struct tpmfront_dev* tpmfront_dev;
+            if ((tpmfront_dev = init_tpmfront(NULL)) == NULL) {
+                vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize tpmfront device\n");
+                status = TPM_IOERROR;
+                goto abort_egress;
+            }
+            vtpm_globals.tpm_fd = tpmfront_open(tpmfront_dev);
+        }
+        break;
+    }
+    printk("TPM 2.0 access ...ok\n");
+    /* Blow away all stale handles left in the tpm*/
+    if (flush_tpm2() != TPM_SUCCESS) {
+        vtpmlogerror(VTPM_LOG_VTPM, "VTPM_FlushResources failed, continuing anyway..\n");
+    }
+
+    /* Initialize the rng */
+    entropy_init(&vtpm_globals.entropy);
+    entropy_add_source(&vtpm_globals.entropy, tpm2_entropy_source, NULL, 0);
+    entropy_gather(&vtpm_globals.entropy);
+    ctr_drbg_init(&vtpm_globals.ctr_drbg, entropy_func, &vtpm_globals.entropy, NULL, 0);
+    ctr_drbg_set_prediction_resistance( &vtpm_globals.ctr_drbg, CTR_DRBG_PR_OFF );
+
+    /* Generate Auth for Owner*/
+    if (opts.gen_owner_auth) {
+        vtpmmgr_rand(vtpm_globals.owner_auth, sizeof(TPM_AUTHDATA));
+    }
+
+    /* Load the Manager data, if it fails create a new manager */
+    if (vtpm_load_disk()) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Assuming first time initialization.\n");
+        TPMTRYRETURN(vtpmmgr2_create());
+    }
+
+    goto egress;
+
+abort_egress:
+    vtpmmgr_shutdown();
+egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 9889feb..c479443 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -96,5 +96,6 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 /* TPM 2.0 */
 TPM_RC tpm2_take_ownership(void);
 TPM_RESULT vtpmmgr2_create(void);
+TPM_RESULT vtpmmgr2_init(int argc, char** argv);
 
 #endif
-- 
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 Dec 17 15:55:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 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 1Y1Gx6-0006Mg-TA; Wed, 17 Dec 2014 15:55: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 1Y1Gx4-0006JU-Fe
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:50 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	CF/4D-08051-587A1945; Wed, 17 Dec 2014 15:55:49 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418831747!15705655!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28372 invoked from network); 17 Dec 2014 15:55:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-6.tower-27.messagelabs.com with SMTP;
	17 Dec 2014 15:55:48 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 17 Dec 2014 07:53:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="625307665"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 17 Dec 2014 07:55:40 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:57 -0500
Message-Id: <1418817117-5496-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 08/14] vTPM/TPM2: Add main entrance
	vtpmmgr2_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

Accept commands from the vtpm-stubdom domains via the mini-os TPM
backend driver. The vTPM manager communicates directly with hardware
TPM 2.0 using the mini-os tpm2_tis driver.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/init.c    | 109 ++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.h |   1 +
 2 files changed, 110 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 8244bb0..7e115a5 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -681,3 +681,112 @@ egress:
     vtpmloginfo(VTPM_LOG_VTPM, "Finished initialized new VTPM manager\n");
     return status;
 }
+
+static int tpm2_entropy_source(void* dummy, unsigned char* data,
+                               size_t len, size_t* olen)
+{
+    UINT32 sz = len;
+    TPM_RESULT rc = TPM2_GetRandom(&sz, data);
+    *olen = sz;
+    return rc == TPM_SUCCESS ? 0 : POLARSSL_ERR_ENTROPY_SOURCE_FAILED;
+}
+
+/*TPM 2.0 Objects flush */
+static TPM_RC flush_tpm2(void)
+{
+    int i;
+
+    for (i = TRANSIENT_FIRST; i < TRANSIENT_LAST; i++)
+         TPM2_FlushContext(i);
+
+    return TPM_SUCCESS;
+}
+
+TPM_RESULT vtpmmgr2_init(int argc, char** argv)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+
+    /* Default commandline options */
+    struct Opts opts = {
+        .tpmdriver = TPMDRV_TPM_TIS,
+        .tpmiomem = TPM_BASEADDR,
+        .tpmirq = 0,
+        .tpmlocality = 0,
+        .gen_owner_auth = 0,
+    };
+
+    if (parse_cmdline_opts(argc, argv, &opts) != 0) {
+        vtpmlogerror(VTPM_LOG_VTPM, "Command line parsing failed! exiting..\n");
+        status = TPM_BAD_PARAMETER;
+        goto abort_egress;
+    }
+
+    /*Setup storage system*/
+    if (vtpm_storage_init() != 0) {
+        vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize storage subsystem!\n");
+        status = TPM_IOERROR;
+        goto abort_egress;
+    }
+
+    /*Setup tpmback device*/
+    init_tpmback(set_opaque, free_opaque);
+
+    /*Setup tpm access*/
+    switch(opts.tpmdriver) {
+        case TPMDRV_TPM_TIS:
+        {
+            struct tpm_chip* tpm;
+            if ((tpm = init_tpm2_tis(opts.tpmiomem, TPM_TIS_LOCL_INT_TO_FLAG(opts.tpmlocality),
+                                     opts.tpmirq)) == NULL) {
+                vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize tpmfront device\n");
+                status = TPM_IOERROR;
+                goto abort_egress;
+            }
+            printk("init_tpm2_tis()       ...ok\n");
+            vtpm_globals.tpm_fd = tpm_tis_open(tpm);
+            tpm_tis_request_locality(tpm, opts.tpmlocality);
+        }
+        break;
+        case TPMDRV_TPMFRONT:
+        {
+            struct tpmfront_dev* tpmfront_dev;
+            if ((tpmfront_dev = init_tpmfront(NULL)) == NULL) {
+                vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize tpmfront device\n");
+                status = TPM_IOERROR;
+                goto abort_egress;
+            }
+            vtpm_globals.tpm_fd = tpmfront_open(tpmfront_dev);
+        }
+        break;
+    }
+    printk("TPM 2.0 access ...ok\n");
+    /* Blow away all stale handles left in the tpm*/
+    if (flush_tpm2() != TPM_SUCCESS) {
+        vtpmlogerror(VTPM_LOG_VTPM, "VTPM_FlushResources failed, continuing anyway..\n");
+    }
+
+    /* Initialize the rng */
+    entropy_init(&vtpm_globals.entropy);
+    entropy_add_source(&vtpm_globals.entropy, tpm2_entropy_source, NULL, 0);
+    entropy_gather(&vtpm_globals.entropy);
+    ctr_drbg_init(&vtpm_globals.ctr_drbg, entropy_func, &vtpm_globals.entropy, NULL, 0);
+    ctr_drbg_set_prediction_resistance( &vtpm_globals.ctr_drbg, CTR_DRBG_PR_OFF );
+
+    /* Generate Auth for Owner*/
+    if (opts.gen_owner_auth) {
+        vtpmmgr_rand(vtpm_globals.owner_auth, sizeof(TPM_AUTHDATA));
+    }
+
+    /* Load the Manager data, if it fails create a new manager */
+    if (vtpm_load_disk()) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Assuming first time initialization.\n");
+        TPMTRYRETURN(vtpmmgr2_create());
+    }
+
+    goto egress;
+
+abort_egress:
+    vtpmmgr_shutdown();
+egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 9889feb..c479443 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -96,5 +96,6 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 /* TPM 2.0 */
 TPM_RC tpm2_take_ownership(void);
 TPM_RESULT vtpmmgr2_create(void);
+TPM_RESULT vtpmmgr2_init(int argc, char** argv);
 
 #endif
-- 
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 Dec 17 15:55:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 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 1Y1Gx7-0006NW-EM; Wed, 17 Dec 2014 15:55:53 +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 1Y1Gx6-0006LF-1R
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:52 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	A2/74-23865-787A1945; Wed, 17 Dec 2014 15:55:51 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418831745!14118492!3
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25955 invoked from network); 17 Dec 2014 15:55:50 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 15:55:50 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2014 07:55:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="639067460"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 17 Dec 2014 07:55:49 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:52:05 -0500
Message-Id: <1418817125-5609-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 11/14] vTPM/TPM2: Support TPM 2.0 bind and
	unbind 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bind data with TPM2_RSA_Encrypt, which performs RSA encryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1). If the
scheme of keyHandle is TPM_ALG_NULL, then the caller may use inScheme
to specify the padding scheme.
Unbind data with TPM2_RSA_Decrypt, which performs RSA decryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1).

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/disk_tpm.c | 42 ++++++++++++++++++++++++++++++++++++++++--
 stubdom/vtpmmgr/disk_tpm.h |  4 ++++
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_tpm.c b/stubdom/vtpmmgr/disk_tpm.c
index d650fbc..45a326a 100644
--- a/stubdom/vtpmmgr/disk_tpm.c
+++ b/stubdom/vtpmmgr/disk_tpm.c
@@ -12,17 +12,20 @@
 #include <polarssl/sha1.h>
 
 #include "tpm.h"
+#include "tpm2.h"
 #include "tcg.h"
 
 #include "vtpmmgr.h"
 #include "vtpm_disk.h"
 #include "disk_tpm.h"
 
+#include "log.h"
 // Print out input/output of seal/unseal operations (includes keys)
 #undef DEBUG_SEAL_OPS
 
 #ifdef DEBUG_SEAL_OPS
 #include "marshal.h"
+#include "tpm2_marshal.h"
 #endif
 
 struct pcr_list {
@@ -31,11 +34,16 @@ struct pcr_list {
 
 static struct pcr_list hwtpm;
 
+/*Ignore PCR on TPM 2.0, read PCR values for TPM 1.x seal | unseal*/
 void TPM_read_pcrs(void)
 {
 	int i;
-	for(i=0; i < 24; i++)
-		TPM_PCR_Read(i, &hwtpm.pcrs[i]);
+	for (i=0; i < 24; i++) {
+        if (hw_is_tpm2())
+            tpm2_pcr_read(i, (uint8_t *)&hwtpm.pcrs[i]);
+        else
+		    TPM_PCR_Read(i, &hwtpm.pcrs[i]);
+    }
 }
 
 struct pcr_composite_3 {
@@ -138,6 +146,36 @@ int TPM_disk_seal(struct disk_seal_entry *dst, const void* src, size_t size)
 	return rc;
 }
 
+TPM_RC TPM2_disk_bind(struct disk_seal_entry *dst, void* src, unsigned int size)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+
+    TPMTRYRETURN(TPM2_Bind(vtpm_globals.sk_handle,
+                           src,
+                           size,
+                           dst->sealed_data));
+
+abort_egress:
+egress:
+   return status;
+}
+
+TPM_RC TPM2_disk_unbind(void *dst, unsigned int *size, const struct disk_seal_entry *src)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+    unsigned char buf[RSA_CIPHER_SIZE];
+
+    memcpy(buf, src->sealed_data, RSA_CIPHER_SIZE);
+    TPMTRYRETURN(TPM2_UnBind(vtpm_globals.sk_handle,
+                             RSA_CIPHER_SIZE,
+                             buf,
+                             size,
+                             dst));
+abort_egress:
+egress:
+   return status;
+}
+
 int TPM_disk_unseal(void *dst, size_t size, const struct disk_seal_entry *src)
 {
 	uint32_t rc;
diff --git a/stubdom/vtpmmgr/disk_tpm.h b/stubdom/vtpmmgr/disk_tpm.h
index b235895..57ae2a6 100644
--- a/stubdom/vtpmmgr/disk_tpm.h
+++ b/stubdom/vtpmmgr/disk_tpm.h
@@ -10,6 +10,10 @@ void TPM_pcr_digest(struct hash160 *buf, le32_t selection);
 int TPM_disk_seal(struct disk_seal_entry *dst, const void* src, size_t size);
 int TPM_disk_unseal(void *dst, size_t size, const struct disk_seal_entry *src);
 
+/*TPM 2.0 Bind and Unbind */
+TPM_RC TPM2_disk_bind(struct disk_seal_entry *dst, void* src, unsigned int size);
+TPM_RC TPM2_disk_unbind(void *dst, unsigned int *size, const struct disk_seal_entry *src);
+
 /* NVRAM to allow revocation of TM-KEY */
 int TPM_disk_nvalloc(be32_t *nvram_slot, struct tpm_authdata auth);
 int TPM_disk_nvread(void *buf, size_t bufsiz, be32_t nvram_slot, struct tpm_authdata auth);
-- 
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 Dec 17 15:55:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 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 1Y1Gx7-0006NW-EM; Wed, 17 Dec 2014 15:55:53 +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 1Y1Gx6-0006LF-1R
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:55:52 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	A2/74-23865-787A1945; Wed, 17 Dec 2014 15:55:51 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418831745!14118492!3
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25955 invoked from network); 17 Dec 2014 15:55:50 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 15:55:50 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2014 07:55:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="639067460"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 17 Dec 2014 07:55:49 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:52:05 -0500
Message-Id: <1418817125-5609-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 11/14] vTPM/TPM2: Support TPM 2.0 bind and
	unbind 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bind data with TPM2_RSA_Encrypt, which performs RSA encryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1). If the
scheme of keyHandle is TPM_ALG_NULL, then the caller may use inScheme
to specify the padding scheme.
Unbind data with TPM2_RSA_Decrypt, which performs RSA decryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1).

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/disk_tpm.c | 42 ++++++++++++++++++++++++++++++++++++++++--
 stubdom/vtpmmgr/disk_tpm.h |  4 ++++
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_tpm.c b/stubdom/vtpmmgr/disk_tpm.c
index d650fbc..45a326a 100644
--- a/stubdom/vtpmmgr/disk_tpm.c
+++ b/stubdom/vtpmmgr/disk_tpm.c
@@ -12,17 +12,20 @@
 #include <polarssl/sha1.h>
 
 #include "tpm.h"
+#include "tpm2.h"
 #include "tcg.h"
 
 #include "vtpmmgr.h"
 #include "vtpm_disk.h"
 #include "disk_tpm.h"
 
+#include "log.h"
 // Print out input/output of seal/unseal operations (includes keys)
 #undef DEBUG_SEAL_OPS
 
 #ifdef DEBUG_SEAL_OPS
 #include "marshal.h"
+#include "tpm2_marshal.h"
 #endif
 
 struct pcr_list {
@@ -31,11 +34,16 @@ struct pcr_list {
 
 static struct pcr_list hwtpm;
 
+/*Ignore PCR on TPM 2.0, read PCR values for TPM 1.x seal | unseal*/
 void TPM_read_pcrs(void)
 {
 	int i;
-	for(i=0; i < 24; i++)
-		TPM_PCR_Read(i, &hwtpm.pcrs[i]);
+	for (i=0; i < 24; i++) {
+        if (hw_is_tpm2())
+            tpm2_pcr_read(i, (uint8_t *)&hwtpm.pcrs[i]);
+        else
+		    TPM_PCR_Read(i, &hwtpm.pcrs[i]);
+    }
 }
 
 struct pcr_composite_3 {
@@ -138,6 +146,36 @@ int TPM_disk_seal(struct disk_seal_entry *dst, const void* src, size_t size)
 	return rc;
 }
 
+TPM_RC TPM2_disk_bind(struct disk_seal_entry *dst, void* src, unsigned int size)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+
+    TPMTRYRETURN(TPM2_Bind(vtpm_globals.sk_handle,
+                           src,
+                           size,
+                           dst->sealed_data));
+
+abort_egress:
+egress:
+   return status;
+}
+
+TPM_RC TPM2_disk_unbind(void *dst, unsigned int *size, const struct disk_seal_entry *src)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+    unsigned char buf[RSA_CIPHER_SIZE];
+
+    memcpy(buf, src->sealed_data, RSA_CIPHER_SIZE);
+    TPMTRYRETURN(TPM2_UnBind(vtpm_globals.sk_handle,
+                             RSA_CIPHER_SIZE,
+                             buf,
+                             size,
+                             dst));
+abort_egress:
+egress:
+   return status;
+}
+
 int TPM_disk_unseal(void *dst, size_t size, const struct disk_seal_entry *src)
 {
 	uint32_t rc;
diff --git a/stubdom/vtpmmgr/disk_tpm.h b/stubdom/vtpmmgr/disk_tpm.h
index b235895..57ae2a6 100644
--- a/stubdom/vtpmmgr/disk_tpm.h
+++ b/stubdom/vtpmmgr/disk_tpm.h
@@ -10,6 +10,10 @@ void TPM_pcr_digest(struct hash160 *buf, le32_t selection);
 int TPM_disk_seal(struct disk_seal_entry *dst, const void* src, size_t size);
 int TPM_disk_unseal(void *dst, size_t size, const struct disk_seal_entry *src);
 
+/*TPM 2.0 Bind and Unbind */
+TPM_RC TPM2_disk_bind(struct disk_seal_entry *dst, void* src, unsigned int size);
+TPM_RC TPM2_disk_unbind(void *dst, unsigned int *size, const struct disk_seal_entry *src);
+
 /* NVRAM to allow revocation of TM-KEY */
 int TPM_disk_nvalloc(be32_t *nvram_slot, struct tpm_authdata auth);
 int TPM_disk_nvread(void *buf, size_t bufsiz, be32_t nvram_slot, struct tpm_authdata auth);
-- 
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 Dec 17 15:56:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:56:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GxJ-0006Xw-NL; Wed, 17 Dec 2014 15:56:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Y1GxI-0006WU-Hk
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:56:04 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	29/F9-17735-397A1945; Wed, 17 Dec 2014 15:56:03 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418831762!14018644!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1579 invoked from network); 17 Dec 2014 15:56:02 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 15:56:02 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 17 Dec 2014 07:55:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="655676015"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 17 Dec 2014 07:55:37 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:54 -0500
Message-Id: <1418817114-5457-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 07/14] vTPM/TPM2: TPM2.0 TIS initialization
	and self test.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

call the TPM 2.0 various registers that allow communication between
the TPM 2.0 and platform hardware and software. TPM2_SelfTest causes
the TPM 2.0 to perform a test of its capabilities.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 extras/mini-os/include/tpm_tis.h |   1 +
 extras/mini-os/tpm_tis.c         | 156 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 157 insertions(+)

diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h
index 1faca0d..86e83f1 100644
--- a/extras/mini-os/include/tpm_tis.h
+++ b/extras/mini-os/include/tpm_tis.h
@@ -36,6 +36,7 @@
 struct tpm_chip;
 
 struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq);
+struct tpm_chip* init_tpm2_tis(unsigned long baseaddr, int localities, unsigned int irq);
 void shutdown_tpm_tis(struct tpm_chip* tpm);
 
 int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
index d78c465..debcc43 100644
--- a/extras/mini-os/tpm_tis.c
+++ b/extras/mini-os/tpm_tis.c
@@ -1363,5 +1363,161 @@ int tpm_tis_posix_fstat(int fd, struct stat* buf)
    return 0;
 }
 
+/* TPM 2.0 */
 
+/*TPM2.0 Selftest*/
+static void tpm2_selftest(struct tpm_chip* chip)
+{
+    uint8_t data[] = {
+        0x80, 0x1,
+        0x0, 0x0, 0x0, 0xb,
+        0x0, 0x0, 0x1, 0x43,
+        0x1,
+    };
+
+    tpm_transmit(chip, data, sizeof(data));
+}
+
+struct tpm_chip* init_tpm2_tis(unsigned long baseaddr, int localities, unsigned int irq)
+{
+    int i;
+    unsigned long addr;
+    struct tpm_chip* tpm = NULL;
+    uint32_t didvid;
+    uint32_t intfcaps;
+    uint32_t intmask;
+
+    printk("============= Init TPM2 TIS Driver ==============\n");
+
+    /*Sanity check the localities input */
+    if (localities & ~TPM_TIS_EN_LOCLALL) {
+        printk("init_tpm2_tis Invalid locality specification! %X\n", localities);
+        goto abort_egress;
+    }
+
+    printk("IOMEM Machine Base Address: %lX\n", baseaddr);
+
+    /* Create the tpm data structure */
+    tpm = malloc(sizeof(struct tpm_chip));
+    __init_tpm_chip(tpm);
+
+    /* Set the enabled localities - if 0 we leave default as all enabled */
+    if (localities != 0) {
+        tpm->enabled_localities = localities;
+    }
+    printk("Enabled Localities: ");
+    for (i = 0; i < 5; ++i) {
+        if (locality_enabled(tpm, i)) {
+            printk("%d ", i);
+        }
+    }
+    printk("\n");
+
+    /* Set the base machine address */
+    tpm->baseaddr = baseaddr;
+
+    /* Set default timeouts */
+    tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT);
+    tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT);
+    tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT);
+    tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT);
+
+    /*Map the mmio pages */
+    addr = tpm->baseaddr;
+    for (i = 0; i < 5; ++i) {
+        if (locality_enabled(tpm, i)) {
+
+            /* Map the page in now */
+            if ((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) {
+                printk("Unable to map iomem page a address %p\n", addr);
+                goto abort_egress;
+            }
+
+            /* Set default locality to the first enabled one */
+            if (tpm->locality < 0) {
+                if (tpm_tis_request_locality(tpm, i) < 0) {
+                    printk("Unable to request locality %d??\n", i);
+                    goto abort_egress;
+                }
+            }
+        }
+        addr += PAGE_SIZE;
+    }
+
+    /* Get the vendor and device ids */
+    didvid = ioread32(TPM_DID_VID(tpm, tpm->locality));
+    tpm->did = didvid >> 16;
+    tpm->vid = didvid & 0xFFFF;
+
+    /* Get the revision id */
+    tpm->rid = ioread8(TPM_RID(tpm, tpm->locality));
+    printk("2.0 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n",
+           tpm->did, tpm->vid, tpm->rid);
+
+    intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
+    printk("TPM interface capabilities (0x%x):\n", intfcaps);
+    if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
+        printk("\tBurst Count Static\n");
+    if (intfcaps & TPM_INTF_CMD_READY_INT)
+        printk("\tCommand Ready Int Support\n");
+    if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
+        printk("\tInterrupt Edge Falling\n");
+    if (intfcaps & TPM_INTF_INT_EDGE_RISING)
+        printk("\tInterrupt Edge Rising\n");
+    if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
+        printk("\tInterrupt Level Low\n");
+    if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
+        printk("\tInterrupt Level High\n");
+    if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
+        printk("\tLocality Change Int Support\n");
+    if (intfcaps & TPM_INTF_STS_VALID_INT)
+        printk("\tSts Valid Int Support\n");
+    if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
+        printk("\tData Avail Int Support\n");
+
+    /*Interupt setup */
+    intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
+
+    intmask |= TPM_INTF_CMD_READY_INT | TPM_INTF_LOCALITY_CHANGE_INT |
+               TPM_INTF_DATA_AVAIL_INT | TPM_INTF_STS_VALID_INT;
+
+    iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
+
+    /*If interupts are enabled, handle it */
+    if (irq) {
+        if (irq != TPM_PROBE_IRQ) {
+            tpm->irq = irq;
+        } else {
+        /*FIXME add irq probing feature later */
+        printk("IRQ probing not implemented\n");
+        }
+    }
+
+    if (tpm->irq) {
+        iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
+        if (bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) {
+            printk("Unabled to request irq: %u for use\n", tpm->irq);
+            printk("Will use polling mode\n");
+            tpm->irq = 0;
+        } else {
+
+            /* Clear all existing */
+            iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
+                                     ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
+
+            /* Turn on interrupts */
+            iowrite32(TPM_INT_ENABLE(tpm, tpm->locality),
+                                     intmask | TPM_GLOBAL_INT_ENABLE);
+        }
+    }
+
+    tpm2_selftest(tpm);
+    return tpm;
+
+abort_egress:
+    if (tpm != NULL) {
+        shutdown_tpm_tis(tpm);
+    }
+    return NULL;
+}
 #endif
-- 
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 Dec 17 15:56:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:56:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GxI-0006X6-Vt; Wed, 17 Dec 2014 15:56:04 +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 1Y1GxH-0006Vp-L4
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:56:03 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	CC/DE-05632-297A1945; Wed, 17 Dec 2014 15:56:02 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418831761!14125362!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12934 invoked from network); 17 Dec 2014 15:56:01 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 15:56:01 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2014 07:56:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="430193831"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 17 Dec 2014 07:44:50 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:52:15 -0500
Message-Id: <1418817135-5722-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, jbeulich@suse.com, Quan Xu <quan.xu@intel.com>
Subject: [Xen-devel] [PATCH v2 14/14] vTPM/TPM2: Record some infomation in
	docs/misc/vtpmmgr.txt about
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

'vtpmmgr on TPM 2.0'

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 docs/misc/vtpmmgr.txt | 150 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 149 insertions(+), 1 deletion(-)

diff --git a/docs/misc/vtpmmgr.txt b/docs/misc/vtpmmgr.txt
index 026c52b..1f1af4d 100644
--- a/docs/misc/vtpmmgr.txt
+++ b/docs/misc/vtpmmgr.txt
@@ -1,4 +1,8 @@
-Author: Daniel De Graaf <dgdegra@tycho.nsa.gov>
+================================================================================
+Authors:
+    Daniel De Graaf <dgdegra@tycho.nsa.gov>
+    Quan Xu <quan.xu@intel.com>
+================================================================================
 
 This document describes the operation and command line interface of
 vtpmmgr-stubdom. See docs/misc/vtpm.txt for details on the vTPM subsystem as a
@@ -163,3 +167,147 @@ would look like the following:
 This requires the migration domain to be added to the list of valid vTPM kernel
 hashes. In the current version of the vtpmmgr domain, this is the hash of the
 XSM label, not the kernel.
+
+================================================================================
+Appendix B: vtpmmgr on TPM 2.0
+================================================================================
+
+Manager disk image setup:
+-------------------------
+
+The vTPM Manager requires a disk image to store its encrypted data. The image
+does not require a filesystem and can live anywhere on the host disk. The image
+is not large; the Xen 4.5 vtpmmgr is limited to using the first 2MB of the image
+but can support more than 20,000 vTPMs.
+
+ dd if=/dev/zero of=/home/vtpm2/vmgr bs=16M count=1
+
+Manager config file:
+--------------------
+
+The vTPM Manager domain (vtpmmgr-stubdom) must be started like any other Xen
+virtual machine and requires a config file.  The manager requires a disk image
+for storage and permission to access the hardware memory pages for the TPM. The
+disk must be presented as "hda", and the TPM memory pages are passed using the
+iomem configuration parameter. The TPM TIS uses 5 pages of IO memory (one per
+locality) that start at physical address 0xfed40000. By default, the TPM manager
+uses locality 0 (so only the page at 0xfed40 is needed).
+
+Add:
+..
+     extra="tpm2"
+..
+extra option to launch vtpmmgr-stubdom domain on TPM 2.0, and ignore it on TPM
+1.x. for example:
+
+    kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
+    memory=128
+    disk=["file:/home/vtpm2/vmgr,hda,w"]
+    name="vtpmmgr"
+    iomem=["fed40,5"]
+    extra="tpm2"
+
+
+Key Hierarchy
+------------------------------
+
+    +------------------+
+    |  vTPM's secrets  | ...
+    +------------------+
+            |  ^
+            |  |(Bind / Unbind)
+- - - - -  -v  |- - - - - - - - TPM 2.0
+    +------------------+
+    |        SK        +
+    +------------------+
+            |  ^
+            v  |
+    +------------------+
+    |       SRK        |
+    +------------------+
+            |  ^
+            v  |
+    +------------------+
+    | TPM 2.0 Storage  |
+    |   Primary Seed   |
+    +------------------+
+
+
+DESIGN OVERVIEW
+------------------------------
+
+The architecture of vTPM subsystem on TPM 2.0 is described below:
+
++------------------+
+|    Linux DomU    | ...
+|       |  ^       |
+|       v  |       |
+|   xen-tpmfront   |
++------------------+
+        |  ^
+        v  |
++------------------+
+| mini-os/tpmback  |
+|       |  ^       |
+|       v  |       |
+|  vtpm-stubdom    | ...
+|       |  ^       |
+|       v  |       |
+| mini-os/tpmfront |
++------------------+
+        |  ^
+        v  |
++------------------+
+| mini-os/tpmback  |
+|       |  ^       |
+|       v  |       |
+| vtpmmgr-stubdom  |
+|       |  ^       |
+|       v  |       |
+| mini-os/tpm2_tis |
++------------------+
+        |  ^
+        v  |
++------------------+
+| Hardware TPM 2.0 |
++------------------+
+
+ * Linux DomU: The Linux based guest that wants to use a vTPM. There many be
+               more than one of these.
+
+ * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver
+                    provides vTPM access to a para-virtualized Linux based DomU.
+
+ * 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.  This domain regulates
+               access to the physical TPM on the system and secures the
+               persistent state of each vTPM.
+
+ * mini-os/tpm2_tis: Mini-os TPM version 2.0 TPM Interface Specification (TIS)
+                    driver. This driver used by vtpmmgr-stubdom to talk directly
+                    to the hardware TPM 2.0. Communication is facilitated by mapping
+                    hardware memory pages into vtpmmgr-stubdom.
+
+ * Hardware TPM 2.0: The physical TPM 2.0 that is soldered onto the motherboard.
+
+---------------------
+Noted:
+    functionality for a virtual guest operating system (a DomU) is still TPM 1.2.
-- 
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 Dec 17 15:56:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:56:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GxI-0006X6-Vt; Wed, 17 Dec 2014 15:56:04 +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 1Y1GxH-0006Vp-L4
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:56:03 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	CC/DE-05632-297A1945; Wed, 17 Dec 2014 15:56:02 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418831761!14125362!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12934 invoked from network); 17 Dec 2014 15:56:01 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 15:56:01 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2014 07:56:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="430193831"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 17 Dec 2014 07:44:50 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:52:15 -0500
Message-Id: <1418817135-5722-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, jbeulich@suse.com, Quan Xu <quan.xu@intel.com>
Subject: [Xen-devel] [PATCH v2 14/14] vTPM/TPM2: Record some infomation in
	docs/misc/vtpmmgr.txt about
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

'vtpmmgr on TPM 2.0'

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 docs/misc/vtpmmgr.txt | 150 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 149 insertions(+), 1 deletion(-)

diff --git a/docs/misc/vtpmmgr.txt b/docs/misc/vtpmmgr.txt
index 026c52b..1f1af4d 100644
--- a/docs/misc/vtpmmgr.txt
+++ b/docs/misc/vtpmmgr.txt
@@ -1,4 +1,8 @@
-Author: Daniel De Graaf <dgdegra@tycho.nsa.gov>
+================================================================================
+Authors:
+    Daniel De Graaf <dgdegra@tycho.nsa.gov>
+    Quan Xu <quan.xu@intel.com>
+================================================================================
 
 This document describes the operation and command line interface of
 vtpmmgr-stubdom. See docs/misc/vtpm.txt for details on the vTPM subsystem as a
@@ -163,3 +167,147 @@ would look like the following:
 This requires the migration domain to be added to the list of valid vTPM kernel
 hashes. In the current version of the vtpmmgr domain, this is the hash of the
 XSM label, not the kernel.
+
+================================================================================
+Appendix B: vtpmmgr on TPM 2.0
+================================================================================
+
+Manager disk image setup:
+-------------------------
+
+The vTPM Manager requires a disk image to store its encrypted data. The image
+does not require a filesystem and can live anywhere on the host disk. The image
+is not large; the Xen 4.5 vtpmmgr is limited to using the first 2MB of the image
+but can support more than 20,000 vTPMs.
+
+ dd if=/dev/zero of=/home/vtpm2/vmgr bs=16M count=1
+
+Manager config file:
+--------------------
+
+The vTPM Manager domain (vtpmmgr-stubdom) must be started like any other Xen
+virtual machine and requires a config file.  The manager requires a disk image
+for storage and permission to access the hardware memory pages for the TPM. The
+disk must be presented as "hda", and the TPM memory pages are passed using the
+iomem configuration parameter. The TPM TIS uses 5 pages of IO memory (one per
+locality) that start at physical address 0xfed40000. By default, the TPM manager
+uses locality 0 (so only the page at 0xfed40 is needed).
+
+Add:
+..
+     extra="tpm2"
+..
+extra option to launch vtpmmgr-stubdom domain on TPM 2.0, and ignore it on TPM
+1.x. for example:
+
+    kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
+    memory=128
+    disk=["file:/home/vtpm2/vmgr,hda,w"]
+    name="vtpmmgr"
+    iomem=["fed40,5"]
+    extra="tpm2"
+
+
+Key Hierarchy
+------------------------------
+
+    +------------------+
+    |  vTPM's secrets  | ...
+    +------------------+
+            |  ^
+            |  |(Bind / Unbind)
+- - - - -  -v  |- - - - - - - - TPM 2.0
+    +------------------+
+    |        SK        +
+    +------------------+
+            |  ^
+            v  |
+    +------------------+
+    |       SRK        |
+    +------------------+
+            |  ^
+            v  |
+    +------------------+
+    | TPM 2.0 Storage  |
+    |   Primary Seed   |
+    +------------------+
+
+
+DESIGN OVERVIEW
+------------------------------
+
+The architecture of vTPM subsystem on TPM 2.0 is described below:
+
++------------------+
+|    Linux DomU    | ...
+|       |  ^       |
+|       v  |       |
+|   xen-tpmfront   |
++------------------+
+        |  ^
+        v  |
++------------------+
+| mini-os/tpmback  |
+|       |  ^       |
+|       v  |       |
+|  vtpm-stubdom    | ...
+|       |  ^       |
+|       v  |       |
+| mini-os/tpmfront |
++------------------+
+        |  ^
+        v  |
++------------------+
+| mini-os/tpmback  |
+|       |  ^       |
+|       v  |       |
+| vtpmmgr-stubdom  |
+|       |  ^       |
+|       v  |       |
+| mini-os/tpm2_tis |
++------------------+
+        |  ^
+        v  |
++------------------+
+| Hardware TPM 2.0 |
++------------------+
+
+ * Linux DomU: The Linux based guest that wants to use a vTPM. There many be
+               more than one of these.
+
+ * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver
+                    provides vTPM access to a para-virtualized Linux based DomU.
+
+ * 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.  This domain regulates
+               access to the physical TPM on the system and secures the
+               persistent state of each vTPM.
+
+ * mini-os/tpm2_tis: Mini-os TPM version 2.0 TPM Interface Specification (TIS)
+                    driver. This driver used by vtpmmgr-stubdom to talk directly
+                    to the hardware TPM 2.0. Communication is facilitated by mapping
+                    hardware memory pages into vtpmmgr-stubdom.
+
+ * Hardware TPM 2.0: The physical TPM 2.0 that is soldered onto the motherboard.
+
+---------------------
+Noted:
+    functionality for a virtual guest operating system (a DomU) is still TPM 1.2.
-- 
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 Dec 17 15:56:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15:56:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1GxJ-0006Xw-NL; Wed, 17 Dec 2014 15:56:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <quan.xu@intel.com>) id 1Y1GxI-0006WU-Hk
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:56:04 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	29/F9-17735-397A1945; Wed, 17 Dec 2014 15:56:03 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418831762!14018644!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1579 invoked from network); 17 Dec 2014 15:56:02 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 15:56:02 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 17 Dec 2014 07:55:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="655676015"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 17 Dec 2014 07:55:37 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:54 -0500
Message-Id: <1418817114-5457-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 07/14] vTPM/TPM2: TPM2.0 TIS initialization
	and self test.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

call the TPM 2.0 various registers that allow communication between
the TPM 2.0 and platform hardware and software. TPM2_SelfTest causes
the TPM 2.0 to perform a test of its capabilities.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 extras/mini-os/include/tpm_tis.h |   1 +
 extras/mini-os/tpm_tis.c         | 156 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 157 insertions(+)

diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h
index 1faca0d..86e83f1 100644
--- a/extras/mini-os/include/tpm_tis.h
+++ b/extras/mini-os/include/tpm_tis.h
@@ -36,6 +36,7 @@
 struct tpm_chip;
 
 struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq);
+struct tpm_chip* init_tpm2_tis(unsigned long baseaddr, int localities, unsigned int irq);
 void shutdown_tpm_tis(struct tpm_chip* tpm);
 
 int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
index d78c465..debcc43 100644
--- a/extras/mini-os/tpm_tis.c
+++ b/extras/mini-os/tpm_tis.c
@@ -1363,5 +1363,161 @@ int tpm_tis_posix_fstat(int fd, struct stat* buf)
    return 0;
 }
 
+/* TPM 2.0 */
 
+/*TPM2.0 Selftest*/
+static void tpm2_selftest(struct tpm_chip* chip)
+{
+    uint8_t data[] = {
+        0x80, 0x1,
+        0x0, 0x0, 0x0, 0xb,
+        0x0, 0x0, 0x1, 0x43,
+        0x1,
+    };
+
+    tpm_transmit(chip, data, sizeof(data));
+}
+
+struct tpm_chip* init_tpm2_tis(unsigned long baseaddr, int localities, unsigned int irq)
+{
+    int i;
+    unsigned long addr;
+    struct tpm_chip* tpm = NULL;
+    uint32_t didvid;
+    uint32_t intfcaps;
+    uint32_t intmask;
+
+    printk("============= Init TPM2 TIS Driver ==============\n");
+
+    /*Sanity check the localities input */
+    if (localities & ~TPM_TIS_EN_LOCLALL) {
+        printk("init_tpm2_tis Invalid locality specification! %X\n", localities);
+        goto abort_egress;
+    }
+
+    printk("IOMEM Machine Base Address: %lX\n", baseaddr);
+
+    /* Create the tpm data structure */
+    tpm = malloc(sizeof(struct tpm_chip));
+    __init_tpm_chip(tpm);
+
+    /* Set the enabled localities - if 0 we leave default as all enabled */
+    if (localities != 0) {
+        tpm->enabled_localities = localities;
+    }
+    printk("Enabled Localities: ");
+    for (i = 0; i < 5; ++i) {
+        if (locality_enabled(tpm, i)) {
+            printk("%d ", i);
+        }
+    }
+    printk("\n");
+
+    /* Set the base machine address */
+    tpm->baseaddr = baseaddr;
+
+    /* Set default timeouts */
+    tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT);
+    tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT);
+    tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT);
+    tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT);
+
+    /*Map the mmio pages */
+    addr = tpm->baseaddr;
+    for (i = 0; i < 5; ++i) {
+        if (locality_enabled(tpm, i)) {
+
+            /* Map the page in now */
+            if ((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) {
+                printk("Unable to map iomem page a address %p\n", addr);
+                goto abort_egress;
+            }
+
+            /* Set default locality to the first enabled one */
+            if (tpm->locality < 0) {
+                if (tpm_tis_request_locality(tpm, i) < 0) {
+                    printk("Unable to request locality %d??\n", i);
+                    goto abort_egress;
+                }
+            }
+        }
+        addr += PAGE_SIZE;
+    }
+
+    /* Get the vendor and device ids */
+    didvid = ioread32(TPM_DID_VID(tpm, tpm->locality));
+    tpm->did = didvid >> 16;
+    tpm->vid = didvid & 0xFFFF;
+
+    /* Get the revision id */
+    tpm->rid = ioread8(TPM_RID(tpm, tpm->locality));
+    printk("2.0 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n",
+           tpm->did, tpm->vid, tpm->rid);
+
+    intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
+    printk("TPM interface capabilities (0x%x):\n", intfcaps);
+    if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
+        printk("\tBurst Count Static\n");
+    if (intfcaps & TPM_INTF_CMD_READY_INT)
+        printk("\tCommand Ready Int Support\n");
+    if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
+        printk("\tInterrupt Edge Falling\n");
+    if (intfcaps & TPM_INTF_INT_EDGE_RISING)
+        printk("\tInterrupt Edge Rising\n");
+    if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
+        printk("\tInterrupt Level Low\n");
+    if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
+        printk("\tInterrupt Level High\n");
+    if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
+        printk("\tLocality Change Int Support\n");
+    if (intfcaps & TPM_INTF_STS_VALID_INT)
+        printk("\tSts Valid Int Support\n");
+    if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
+        printk("\tData Avail Int Support\n");
+
+    /*Interupt setup */
+    intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
+
+    intmask |= TPM_INTF_CMD_READY_INT | TPM_INTF_LOCALITY_CHANGE_INT |
+               TPM_INTF_DATA_AVAIL_INT | TPM_INTF_STS_VALID_INT;
+
+    iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
+
+    /*If interupts are enabled, handle it */
+    if (irq) {
+        if (irq != TPM_PROBE_IRQ) {
+            tpm->irq = irq;
+        } else {
+        /*FIXME add irq probing feature later */
+        printk("IRQ probing not implemented\n");
+        }
+    }
+
+    if (tpm->irq) {
+        iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
+        if (bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) {
+            printk("Unabled to request irq: %u for use\n", tpm->irq);
+            printk("Will use polling mode\n");
+            tpm->irq = 0;
+        } else {
+
+            /* Clear all existing */
+            iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
+                                     ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
+
+            /* Turn on interrupts */
+            iowrite32(TPM_INT_ENABLE(tpm, tpm->locality),
+                                     intmask | TPM_GLOBAL_INT_ENABLE);
+        }
+    }
+
+    tpm2_selftest(tpm);
+    return tpm;
+
+abort_egress:
+    if (tpm != NULL) {
+        shutdown_tpm_tis(tpm);
+    }
+    return NULL;
+}
 #endif
-- 
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 Dec 17 15:56:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1GxQ-0006eB-29; Wed, 17 Dec 2014 15:56:12 +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 1Y1GxN-0006ba-5H
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:56:10 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	FB/22-17958-897A1945; Wed, 17 Dec 2014 15:56:08 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418831762!14018644!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2272 invoked from network); 17 Dec 2014 15:56:07 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 15:56:07 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 17 Dec 2014 07:55:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="655676094"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 17 Dec 2014 07:55:51 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:52:08 -0500
Message-Id: <1418817128-5646-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 12/14] vTPM/TPM2: Bind group keys and sectors
	data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/disk_write.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_write.c b/stubdom/vtpmmgr/disk_write.c
index 4c825c5..ab15a9a 100644
--- a/stubdom/vtpmmgr/disk_write.c
+++ b/stubdom/vtpmmgr/disk_write.c
@@ -88,7 +88,12 @@ static void generate_group_seals(struct mem_group *src, const struct mem_tpm_mgr
 		dst->pcr_selection = src->seals[i].pcr_selection;
 		memcpy(&dst->digest_release, &src->seals[i].digest_release, 20);
 		TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
-		TPM_disk_seal(dst, &sblob, sizeof(sblob));
+
+        /*TPM 2.0 bind | TPM 1.x seal*/
+        if (hw_is_tpm2())
+            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+        else
+            TPM_disk_seal(dst, &sblob, sizeof(sblob));
 	}
 	src->seal_bits.nr_cfgs = native_be32(src->nr_seals);
 
@@ -250,7 +255,11 @@ static void disk_write_seal_list(struct mem_tpm_mgr *mgr, struct mem_group *grou
 		memcpy(&dst->digest_release, &src->digest_release, 20);
 		TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
 
-		TPM_disk_seal(dst, &sblob, sizeof(sblob));
+        /*TPM 2.0 bind / TPM 1.x seal*/
+        if (hw_is_tpm2())
+            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+        else
+            TPM_disk_seal(dst, &sblob, sizeof(sblob));
 	}
 
 	memcpy(seal->hdr.magic, TPM_MGR_MAGIC, 12);
-- 
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 Dec 17 15:56:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1GxQ-0006eB-29; Wed, 17 Dec 2014 15:56:12 +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 1Y1GxN-0006ba-5H
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:56:10 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	FB/22-17958-897A1945; Wed, 17 Dec 2014 15:56:08 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418831762!14018644!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2272 invoked from network); 17 Dec 2014 15:56:07 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 15:56:07 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 17 Dec 2014 07:55:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="655676094"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 17 Dec 2014 07:55:51 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:52:08 -0500
Message-Id: <1418817128-5646-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 12/14] vTPM/TPM2: Bind group keys and sectors
	data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/disk_write.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_write.c b/stubdom/vtpmmgr/disk_write.c
index 4c825c5..ab15a9a 100644
--- a/stubdom/vtpmmgr/disk_write.c
+++ b/stubdom/vtpmmgr/disk_write.c
@@ -88,7 +88,12 @@ static void generate_group_seals(struct mem_group *src, const struct mem_tpm_mgr
 		dst->pcr_selection = src->seals[i].pcr_selection;
 		memcpy(&dst->digest_release, &src->seals[i].digest_release, 20);
 		TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
-		TPM_disk_seal(dst, &sblob, sizeof(sblob));
+
+        /*TPM 2.0 bind | TPM 1.x seal*/
+        if (hw_is_tpm2())
+            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+        else
+            TPM_disk_seal(dst, &sblob, sizeof(sblob));
 	}
 	src->seal_bits.nr_cfgs = native_be32(src->nr_seals);
 
@@ -250,7 +255,11 @@ static void disk_write_seal_list(struct mem_tpm_mgr *mgr, struct mem_group *grou
 		memcpy(&dst->digest_release, &src->digest_release, 20);
 		TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
 
-		TPM_disk_seal(dst, &sblob, sizeof(sblob));
+        /*TPM 2.0 bind / TPM 1.x seal*/
+        if (hw_is_tpm2())
+            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+        else
+            TPM_disk_seal(dst, &sblob, sizeof(sblob));
 	}
 
 	memcpy(seal->hdr.magic, TPM_MGR_MAGIC, 12);
-- 
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 Dec 17 15:56:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1GxR-0006gM-J7; Wed, 17 Dec 2014 15:56:13 +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 1Y1GxP-0006dM-8x
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:56:11 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	F9/56-02957-A97A1945; Wed, 17 Dec 2014 15:56:10 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418831767!15686362!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 15234 invoked from network); 17 Dec 2014 15:56:08 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-9.tower-27.messagelabs.com with SMTP;
	17 Dec 2014 15:56:08 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga102.jf.intel.com with ESMTP; 17 Dec 2014 07:53:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="500253227"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 17 Dec 2014 07:51:13 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:43 -0500
Message-Id: <1418817103-5344-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 04/14] vTPM/TPM2: Add TPM 2.0 Exposed APIs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 TPM 2.0 Exposed APIs for the Mini-os to access TPM 2.0
hardware.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/Makefile |   2 +-
 stubdom/vtpmmgr/tpm2.c   | 455 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2.h   | 104 +++++++++++
 3 files changed, 560 insertions(+), 1 deletion(-)
 create mode 100644 stubdom/vtpmmgr/tpm2.c
 create mode 100644 stubdom/vtpmmgr/tpm2.h

diff --git a/stubdom/vtpmmgr/Makefile b/stubdom/vtpmmgr/Makefile
index c5e17c5..6dae034 100644
--- a/stubdom/vtpmmgr/Makefile
+++ b/stubdom/vtpmmgr/Makefile
@@ -12,7 +12,7 @@
 XEN_ROOT=../..
 
 TARGET=vtpmmgr.a
-OBJS=vtpmmgr.o vtpm_cmd_handler.o init.o tpmrsa.o tpm.o log.o
+OBJS=vtpmmgr.o vtpm_cmd_handler.o init.o tpmrsa.o tpm.o tpm2.o log.o
 OBJS += vtpm_disk.o disk_tpm.o disk_io.o disk_crypto.o disk_read.o disk_write.o
 OBJS += mgmt_authority.o
 
diff --git a/stubdom/vtpmmgr/tpm2.c b/stubdom/vtpmmgr/tpm2.c
new file mode 100644
index 0000000..1903e27
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2.c
@@ -0,0 +1,455 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005/2006, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#include <stdio.h>
+#include <string.h>
+#include <malloc.h>
+#include <unistd.h>
+#include <errno.h>
+#include <polarssl/sha1.h>
+
+#include "tcg.h"
+#include "tpm.h"
+#include "tpm2.h"
+#include "log.h"
+#include "marshal.h"
+#include "tpm2_marshal.h"
+#include "tpmrsa.h"
+#include "vtpmmgr.h"
+
+#define TCPA_MAX_BUFFER_LENGTH 0x2000
+#define TPM_BEGIN(TAG, ORD) \
+    const TPM_TAG intag = TAG;\
+    TPM_TAG tag = intag;\
+    UINT32 paramSize;\
+    const TPM_COMMAND_CODE ordinal = ORD;\
+    TPM_RESULT status = TPM_SUCCESS;\
+    BYTE in_buf[TCPA_MAX_BUFFER_LENGTH];\
+    BYTE out_buf[TCPA_MAX_BUFFER_LENGTH];\
+    UINT32 out_len = sizeof(out_buf);\
+    BYTE* ptr = in_buf;\
+    /*Print a log message */\
+    vtpmloginfo(VTPM_LOG_TPM, "%s\n", __func__);\
+    /* Pack the header*/\
+    ptr = pack_TPM_TAG(ptr, tag);\
+    ptr += sizeof(UINT32);\
+    ptr = pack_TPM_COMMAND_CODE(ptr, ordinal)\
+
+#define TPM_AUTH_BEGIN() \
+    sha1_context sha1_ctx;\
+    BYTE* authbase = ptr - sizeof(TPM_COMMAND_CODE);\
+    TPM_DIGEST paramDigest;\
+    sha1_starts(&sha1_ctx)
+
+#define TPM_AUTH1_GEN(HMACkey, auth) do {\
+    sha1_finish(&sha1_ctx, paramDigest.digest);\
+    generateAuth(&paramDigest, HMACkey, auth);\
+    ptr = pack_TPM_AUTH_SESSION(ptr, auth);\
+} while(0)
+
+#define TPM_AUTH2_GEN(HMACkey, auth) do {\
+    generateAuth(&paramDigest, HMACkey, auth);\
+    ptr = pack_TPM_AUTH_SESSION(ptr, auth);\
+} while(0)
+
+#define TPM_TRANSMIT() do {\
+    /* Pack the command size */\
+    paramSize = ptr - in_buf;\
+    pack_UINT32(in_buf + sizeof(TPM_TAG), paramSize);\
+    if ((status = TPM_TransmitData(in_buf, paramSize, out_buf, &out_len)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH_VERIFY_BEGIN() do {\
+    UINT32 buf[2] = { cpu_to_be32(status), cpu_to_be32(ordinal) };\
+    sha1_starts(&sha1_ctx);\
+    sha1_update(&sha1_ctx, (unsigned char*)buf, sizeof(buf));\
+    authbase = ptr;\
+} while(0)
+
+#define TPM_AUTH1_VERIFY(HMACkey, auth) do {\
+    sha1_finish(&sha1_ctx, paramDigest.digest);\
+    ptr = unpack_TPM_AUTH_SESSION(ptr, auth);\
+    if ((status = verifyAuth(&paramDigest, HMACkey, auth)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH2_VERIFY(HMACkey, auth) do {\
+    ptr = unpack_TPM_AUTH_SESSION(ptr, auth);\
+    if ((status = verifyAuth(&paramDigest, HMACkey, auth)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_UNPACK_VERIFY() do { \
+    ptr = out_buf;\
+    ptr = unpack_TPM_RSP_HEADER(ptr, \
+          &(tag), &(paramSize), &(status));\
+    if ((status) != TPM_SUCCESS){ \
+        vtpmlogerror(VTPM_LOG_TPM, "Failed with return code %s\n", tpm_get_error_name(status));\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH_HASH() do {\
+    sha1_update(&sha1_ctx, authbase, ptr - authbase);\
+    authbase = ptr;\
+} while(0)
+
+#define TPM_AUTH_SKIP() do {\
+    authbase = ptr;\
+} while(0)
+
+TPM_RC TPM2_PCR_Read(TPML_PCR_SELECTION pcrSelectionIn,
+                     UINT32 *pcrUpdateCounter,
+                     TPML_PCR_SELECTION *pcrSelectionOut,
+                     TPML_DIGEST *pcrValues)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS,TPM_CC_PCR_Read);
+
+    /*pack in*/
+    ptr =  pack_TPML_PCR_SELECTION(ptr, &pcrSelectionIn);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    /*unpack out*/
+    ptr = unpack_UINT32(ptr, pcrUpdateCounter);
+    ptr = unpack_TPML_PCR_SELECTION(ptr, pcrSelectionOut);
+    ptr = unpack_TPML_DIGEST(ptr, pcrValues);
+
+    goto egress;
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_Load(TPMI_DH_OBJECT parentHandle,
+                 TPM2B_PRIVATE *inPrivate, /* in */
+                 TPM2B_PUBLIC *inPublic, /* in */
+                 TPM_HANDLE *objectHandle, /* out */
+                 TPM2B_NAME *name /* out */)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Load);
+
+    /* pack handle of parent for new object */
+    ptr =  pack_UINT32(ptr, parentHandle);
+
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+    ptr = pack_TPM2B_PRIVATE(ptr, inPrivate);
+    ptr = pack_TPM2B_PUBLIC(ptr, inPublic);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    if (objectHandle != NULL) {
+        ptr = unpack_TPM_HANDLE(ptr, objectHandle);
+    } else {
+        TPM_HANDLE tmp;
+        ptr = unpack_TPM_HANDLE(ptr, &tmp);
+    }
+
+    if (name != NULL)
+        ptr = unpack_TPM2B_NAME(ptr, name);
+    goto egress;
+
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_Create(TPMI_DH_OBJECT parentHandle,
+                   TPM2_Create_Params_in *in,
+                   TPM2_Create_Params_out *out)
+{
+    UINT32 param_size;
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Create);
+
+    /* pack handle of parent for new object */
+    ptr =  pack_UINT32(ptr, parentHandle);
+
+    /* pack Auth Area */
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+
+    /* pack inSensitive */
+    ptr = pack_TPM2B_SENSITIVE_CREATE(ptr, &in->inSensitive);
+
+    /* pack inPublic */
+    ptr = pack_TPM2B_PUBLIC(ptr, &in->inPublic);
+
+    /* pack outside Info */
+    ptr = pack_TPM2B_DATA(ptr, &in->outsideInfo);
+
+    /* pack createPCR */
+    ptr = pack_TPML_PCR_SELECTION(ptr, &in->creationPCR);
+
+    /* Send the command to the tpm */
+    TPM_TRANSMIT();
+
+    /* Unpack and validate the header */
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT32(ptr, &param_size);
+    if (out != NULL) {
+        ptr = unpack_TPM2B_PRIVATE(ptr, &vtpm_globals.tpm2_storage_key.Private);
+        ptr = unpack_TPM2B_PUBLIC(ptr, &vtpm_globals.tpm2_storage_key.Public);
+        ptr = unpack_TPM2B_CREATION_DATA(ptr, &out->creationData);
+        ptr = unpack_TPM2B_DIGEST(ptr, &out->creationHash);
+        ptr = unpack_TPMT_TK_CREATION(ptr, &out->creationTicket);
+    } else {
+           ptr += param_size;
+    }
+    goto egress;
+
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_CreatePrimary(TPMI_RH_HIERARCHY primaryHandle,
+                          TPM2_Create_Params_in *in,
+                          TPM_HANDLE *objHandle,
+                          TPM2_Create_Params_out *out)
+{
+    UINT32 param_size;
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_CreatePrimary);
+
+    /* pack primary handle */
+    ptr = pack_UINT32(ptr, primaryHandle);
+
+    /* pack Auth Area */
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+
+    /* pack inSenstive */
+    ptr = pack_TPM2B_SENSITIVE_CREATE(ptr, &in->inSensitive);
+
+    /* pack inPublic */
+    ptr = pack_TPM2B_PUBLIC(ptr, &in->inPublic);
+
+    /* pack outsideInfo */
+    ptr = pack_TPM2B_DATA(ptr, &in->outsideInfo);
+
+    /* pack creationPCR */
+    ptr = pack_TPML_PCR_SELECTION(ptr, &in->creationPCR);
+
+    /* Send the command to the tpm */
+    TPM_TRANSMIT();
+
+    /* Unpack and validate the header */
+    TPM_UNPACK_VERIFY();
+
+    if (objHandle != NULL)
+        ptr = unpack_TPM_HANDLE(ptr, objHandle);
+    else {
+        TPM_HANDLE handle;
+        ptr = unpack_TPM_HANDLE(ptr, &handle);
+    }
+    ptr = unpack_UINT32(ptr, &param_size);
+
+    if (out != NULL) {
+        ptr = unpack_TPM2B_PUBLIC(ptr, &out->outPublic);
+        ptr = unpack_TPM2B_CREATION_DATA(ptr, &out->creationData);
+        ptr = unpack_TPM2B_DIGEST(ptr, &out->creationHash);
+        ptr = unpack_TPMT_TK_CREATION(ptr, &out->creationTicket);
+    } else {
+        ptr += param_size;
+    }
+
+goto egress;
+
+abort_egress:
+egress:
+   return status;
+}
+
+TPM_RC TPM2_HierachyChangeAuth(TPMI_RH_HIERARCHY_AUTH authHandle, TPM2B_AUTH *newAuth)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_HierarchyChangeAuth);
+    ptr = pack_UINT32(ptr, authHandle);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+    ptr = pack_TPM2B_AUTH(ptr, newAuth);
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_RSA_ENCRYPT(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *message,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *outData)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_RSA_Encrypt);
+
+    ptr = pack_UINT32(ptr, keyHandle);
+    ptr = pack_TPM2B_PUBLIC_KEY_RSA(ptr, message);
+    ptr = pack_TPMT_RSA_DECRYPT(ptr, inScheme);
+    ptr = pack_TPM2B_DATA(ptr, label);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    if (outData != NULL)
+        unpack_TPM2B_PUBLIC_KEY_RSA(ptr, outData);
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_Bind(TPMI_DH_OBJECT keyHandle,
+                 void *buf,
+                 UINT32 len,
+                 void *out)
+{
+    TPM_RC status = TPM_SUCCESS;
+    TPM2B_PUBLIC_KEY_RSA message;
+    TPMT_RSA_DECRYPT inScheme;
+    TPM2B_DATA label;
+    TPM2B_PUBLIC_KEY_RSA outData;
+
+    message.size = len;
+    memcpy(message.buffer, buf, len);
+    inScheme.scheme = TPM2_ALG_NULL;
+    label.size = 0;
+    TPMTRYRETURN(TPM2_RSA_ENCRYPT(keyHandle, &message, &inScheme, &label, &outData));
+    memcpy(out, outData.buffer, outData.size);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_RSA_Decrypt(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *cipherText,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *message)
+{
+    UINT32 param_size;
+
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_RSA_Decrypt);
+    ptr = pack_UINT32(ptr, keyHandle);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+    ptr = pack_TPM2B_PUBLIC_KEY_RSA(ptr, cipherText);
+    ptr = pack_TPMT_RSA_DECRYPT(ptr, inScheme);
+    ptr = pack_TPM2B_DATA(ptr, label);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT32(ptr, &param_size);
+
+    if (message)
+        ptr = unpack_TPM2B_PUBLIC_KEY_RSA(ptr, message);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_UnBind(TPMI_DH_OBJECT keyHandle,
+                   UINT32 ilen,
+                   void *in,
+                   UINT32 *olen,
+                   void *out)
+{
+    UINT32 status;
+    TPM2B_PUBLIC_KEY_RSA cipher, message;
+    TPMT_RSA_DECRYPT inScheme;
+    TPM2B_DATA label;
+
+    cipher.size = ilen;
+    memcpy(cipher.buffer, in, ilen);
+    inScheme.scheme = TPM2_ALG_NULL;
+    label.size = 0;
+
+    TPMTRYRETURN(TPM2_RSA_Decrypt(keyHandle, &cipher, &inScheme, &label, &message));
+
+    *olen = message.size;
+    memcpy(out, message.buffer, *olen);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_CLEAR(void)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Clear);
+
+    ptr = pack_UINT32(ptr, TPM_RH_PLATFORM);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_GetRandom(UINT32 * bytesRequested, BYTE * randomBytes)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_GetRandom);
+
+    ptr = pack_UINT16(ptr, (UINT16)*bytesRequested);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT16(ptr, (UINT16 *)bytesRequested);
+    ptr = unpack_TPM_BUFFER(ptr, randomBytes, *bytesRequested);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_FlushContext(TPMI_DH_CONTEXT flushHandle)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_FlushContext);
+
+    ptr = pack_UINT32(ptr, flushHandle);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/tpm2.h b/stubdom/vtpmmgr/tpm2.h
new file mode 100644
index 0000000..9f597ee
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2.h
@@ -0,0 +1,104 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005/2006, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef __TPM2_H__
+#define __TPM2_H__
+
+#include "tcg.h"
+#include "tpm2_types.h"
+
+// ------------------------------------------------------------------
+// TPM 2.0 Exposed API
+// ------------------------------------------------------------------
+
+TPM_RC TPM2_PCR_Read(TPML_PCR_SELECTION pcrSelectionIn,
+                     UINT32 *pcrUpdateCounter,
+                     TPML_PCR_SELECTION *pcrSelectionOut,
+                     TPML_DIGEST *pcrValues);
+
+TPM_RC TPM2_Load(TPMI_DH_OBJECT parentHandle,
+                 TPM2B_PRIVATE *inPrivate,
+                 TPM2B_PUBLIC *inPublic,
+                 TPM_HANDLE *objectHandle,
+                 TPM2B_NAME *name);
+
+TPM_RC TPM2_Create(TPMI_DH_OBJECT parentHandle,
+                   TPM2_Create_Params_in *in,
+                   TPM2_Create_Params_out *out);
+
+TPM_RC TPM2_CreatePrimary(TPMI_RH_HIERARCHY primaryHandle,
+                          TPM2_Create_Params_in *objHandle,
+                          TPM_HANDLE *in,
+                          TPM2_Create_Params_out *out);
+
+TPM_RC TPM2_HierachyChangeAuth(TPMI_RH_HIERARCHY_AUTH authHandle,
+                               TPM2B_AUTH *newAuth);
+
+TPM_RC TPM2_RSA_ENCRYPT(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *message,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *outData);
+
+TPM_RC TPM2_Bind(TPMI_DH_OBJECT keyHandle,
+                 void *buf,
+                 UINT32 len,
+                 void *out);
+
+TPM_RC TPM2_RSA_Decrypt(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *cipherText,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *message);
+
+TPM_RC TPM2_UnBind(TPMI_DH_OBJECT keyHandle,
+                   UINT32 ilen,
+                   void *in,
+                   UINT32 *olen,
+                   void *out);
+
+TPM_RESULT TPM2_GetRandom(UINT32* bytesRequested,
+                          BYTE* randomBytes);
+
+TPM_RC TPM2_CLEAR(void);
+
+TPM_RC TPM2_FlushContext(TPMI_DH_CONTEXT);
+#endif //TPM2_H
-- 
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 Dec 17 15:56:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1GxR-0006gM-J7; Wed, 17 Dec 2014 15:56:13 +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 1Y1GxP-0006dM-8x
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:56:11 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	F9/56-02957-A97A1945; Wed, 17 Dec 2014 15:56:10 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418831767!15686362!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 15234 invoked from network); 17 Dec 2014 15:56:08 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-9.tower-27.messagelabs.com with SMTP;
	17 Dec 2014 15:56:08 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga102.jf.intel.com with ESMTP; 17 Dec 2014 07:53:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="500253227"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 17 Dec 2014 07:51:13 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:51:43 -0500
Message-Id: <1418817103-5344-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 04/14] vTPM/TPM2: Add TPM 2.0 Exposed APIs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 TPM 2.0 Exposed APIs for the Mini-os to access TPM 2.0
hardware.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/Makefile |   2 +-
 stubdom/vtpmmgr/tpm2.c   | 455 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2.h   | 104 +++++++++++
 3 files changed, 560 insertions(+), 1 deletion(-)
 create mode 100644 stubdom/vtpmmgr/tpm2.c
 create mode 100644 stubdom/vtpmmgr/tpm2.h

diff --git a/stubdom/vtpmmgr/Makefile b/stubdom/vtpmmgr/Makefile
index c5e17c5..6dae034 100644
--- a/stubdom/vtpmmgr/Makefile
+++ b/stubdom/vtpmmgr/Makefile
@@ -12,7 +12,7 @@
 XEN_ROOT=../..
 
 TARGET=vtpmmgr.a
-OBJS=vtpmmgr.o vtpm_cmd_handler.o init.o tpmrsa.o tpm.o log.o
+OBJS=vtpmmgr.o vtpm_cmd_handler.o init.o tpmrsa.o tpm.o tpm2.o log.o
 OBJS += vtpm_disk.o disk_tpm.o disk_io.o disk_crypto.o disk_read.o disk_write.o
 OBJS += mgmt_authority.o
 
diff --git a/stubdom/vtpmmgr/tpm2.c b/stubdom/vtpmmgr/tpm2.c
new file mode 100644
index 0000000..1903e27
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2.c
@@ -0,0 +1,455 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005/2006, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#include <stdio.h>
+#include <string.h>
+#include <malloc.h>
+#include <unistd.h>
+#include <errno.h>
+#include <polarssl/sha1.h>
+
+#include "tcg.h"
+#include "tpm.h"
+#include "tpm2.h"
+#include "log.h"
+#include "marshal.h"
+#include "tpm2_marshal.h"
+#include "tpmrsa.h"
+#include "vtpmmgr.h"
+
+#define TCPA_MAX_BUFFER_LENGTH 0x2000
+#define TPM_BEGIN(TAG, ORD) \
+    const TPM_TAG intag = TAG;\
+    TPM_TAG tag = intag;\
+    UINT32 paramSize;\
+    const TPM_COMMAND_CODE ordinal = ORD;\
+    TPM_RESULT status = TPM_SUCCESS;\
+    BYTE in_buf[TCPA_MAX_BUFFER_LENGTH];\
+    BYTE out_buf[TCPA_MAX_BUFFER_LENGTH];\
+    UINT32 out_len = sizeof(out_buf);\
+    BYTE* ptr = in_buf;\
+    /*Print a log message */\
+    vtpmloginfo(VTPM_LOG_TPM, "%s\n", __func__);\
+    /* Pack the header*/\
+    ptr = pack_TPM_TAG(ptr, tag);\
+    ptr += sizeof(UINT32);\
+    ptr = pack_TPM_COMMAND_CODE(ptr, ordinal)\
+
+#define TPM_AUTH_BEGIN() \
+    sha1_context sha1_ctx;\
+    BYTE* authbase = ptr - sizeof(TPM_COMMAND_CODE);\
+    TPM_DIGEST paramDigest;\
+    sha1_starts(&sha1_ctx)
+
+#define TPM_AUTH1_GEN(HMACkey, auth) do {\
+    sha1_finish(&sha1_ctx, paramDigest.digest);\
+    generateAuth(&paramDigest, HMACkey, auth);\
+    ptr = pack_TPM_AUTH_SESSION(ptr, auth);\
+} while(0)
+
+#define TPM_AUTH2_GEN(HMACkey, auth) do {\
+    generateAuth(&paramDigest, HMACkey, auth);\
+    ptr = pack_TPM_AUTH_SESSION(ptr, auth);\
+} while(0)
+
+#define TPM_TRANSMIT() do {\
+    /* Pack the command size */\
+    paramSize = ptr - in_buf;\
+    pack_UINT32(in_buf + sizeof(TPM_TAG), paramSize);\
+    if ((status = TPM_TransmitData(in_buf, paramSize, out_buf, &out_len)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH_VERIFY_BEGIN() do {\
+    UINT32 buf[2] = { cpu_to_be32(status), cpu_to_be32(ordinal) };\
+    sha1_starts(&sha1_ctx);\
+    sha1_update(&sha1_ctx, (unsigned char*)buf, sizeof(buf));\
+    authbase = ptr;\
+} while(0)
+
+#define TPM_AUTH1_VERIFY(HMACkey, auth) do {\
+    sha1_finish(&sha1_ctx, paramDigest.digest);\
+    ptr = unpack_TPM_AUTH_SESSION(ptr, auth);\
+    if ((status = verifyAuth(&paramDigest, HMACkey, auth)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH2_VERIFY(HMACkey, auth) do {\
+    ptr = unpack_TPM_AUTH_SESSION(ptr, auth);\
+    if ((status = verifyAuth(&paramDigest, HMACkey, auth)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_UNPACK_VERIFY() do { \
+    ptr = out_buf;\
+    ptr = unpack_TPM_RSP_HEADER(ptr, \
+          &(tag), &(paramSize), &(status));\
+    if ((status) != TPM_SUCCESS){ \
+        vtpmlogerror(VTPM_LOG_TPM, "Failed with return code %s\n", tpm_get_error_name(status));\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH_HASH() do {\
+    sha1_update(&sha1_ctx, authbase, ptr - authbase);\
+    authbase = ptr;\
+} while(0)
+
+#define TPM_AUTH_SKIP() do {\
+    authbase = ptr;\
+} while(0)
+
+TPM_RC TPM2_PCR_Read(TPML_PCR_SELECTION pcrSelectionIn,
+                     UINT32 *pcrUpdateCounter,
+                     TPML_PCR_SELECTION *pcrSelectionOut,
+                     TPML_DIGEST *pcrValues)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS,TPM_CC_PCR_Read);
+
+    /*pack in*/
+    ptr =  pack_TPML_PCR_SELECTION(ptr, &pcrSelectionIn);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    /*unpack out*/
+    ptr = unpack_UINT32(ptr, pcrUpdateCounter);
+    ptr = unpack_TPML_PCR_SELECTION(ptr, pcrSelectionOut);
+    ptr = unpack_TPML_DIGEST(ptr, pcrValues);
+
+    goto egress;
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_Load(TPMI_DH_OBJECT parentHandle,
+                 TPM2B_PRIVATE *inPrivate, /* in */
+                 TPM2B_PUBLIC *inPublic, /* in */
+                 TPM_HANDLE *objectHandle, /* out */
+                 TPM2B_NAME *name /* out */)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Load);
+
+    /* pack handle of parent for new object */
+    ptr =  pack_UINT32(ptr, parentHandle);
+
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+    ptr = pack_TPM2B_PRIVATE(ptr, inPrivate);
+    ptr = pack_TPM2B_PUBLIC(ptr, inPublic);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    if (objectHandle != NULL) {
+        ptr = unpack_TPM_HANDLE(ptr, objectHandle);
+    } else {
+        TPM_HANDLE tmp;
+        ptr = unpack_TPM_HANDLE(ptr, &tmp);
+    }
+
+    if (name != NULL)
+        ptr = unpack_TPM2B_NAME(ptr, name);
+    goto egress;
+
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_Create(TPMI_DH_OBJECT parentHandle,
+                   TPM2_Create_Params_in *in,
+                   TPM2_Create_Params_out *out)
+{
+    UINT32 param_size;
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Create);
+
+    /* pack handle of parent for new object */
+    ptr =  pack_UINT32(ptr, parentHandle);
+
+    /* pack Auth Area */
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+
+    /* pack inSensitive */
+    ptr = pack_TPM2B_SENSITIVE_CREATE(ptr, &in->inSensitive);
+
+    /* pack inPublic */
+    ptr = pack_TPM2B_PUBLIC(ptr, &in->inPublic);
+
+    /* pack outside Info */
+    ptr = pack_TPM2B_DATA(ptr, &in->outsideInfo);
+
+    /* pack createPCR */
+    ptr = pack_TPML_PCR_SELECTION(ptr, &in->creationPCR);
+
+    /* Send the command to the tpm */
+    TPM_TRANSMIT();
+
+    /* Unpack and validate the header */
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT32(ptr, &param_size);
+    if (out != NULL) {
+        ptr = unpack_TPM2B_PRIVATE(ptr, &vtpm_globals.tpm2_storage_key.Private);
+        ptr = unpack_TPM2B_PUBLIC(ptr, &vtpm_globals.tpm2_storage_key.Public);
+        ptr = unpack_TPM2B_CREATION_DATA(ptr, &out->creationData);
+        ptr = unpack_TPM2B_DIGEST(ptr, &out->creationHash);
+        ptr = unpack_TPMT_TK_CREATION(ptr, &out->creationTicket);
+    } else {
+           ptr += param_size;
+    }
+    goto egress;
+
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_CreatePrimary(TPMI_RH_HIERARCHY primaryHandle,
+                          TPM2_Create_Params_in *in,
+                          TPM_HANDLE *objHandle,
+                          TPM2_Create_Params_out *out)
+{
+    UINT32 param_size;
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_CreatePrimary);
+
+    /* pack primary handle */
+    ptr = pack_UINT32(ptr, primaryHandle);
+
+    /* pack Auth Area */
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+
+    /* pack inSenstive */
+    ptr = pack_TPM2B_SENSITIVE_CREATE(ptr, &in->inSensitive);
+
+    /* pack inPublic */
+    ptr = pack_TPM2B_PUBLIC(ptr, &in->inPublic);
+
+    /* pack outsideInfo */
+    ptr = pack_TPM2B_DATA(ptr, &in->outsideInfo);
+
+    /* pack creationPCR */
+    ptr = pack_TPML_PCR_SELECTION(ptr, &in->creationPCR);
+
+    /* Send the command to the tpm */
+    TPM_TRANSMIT();
+
+    /* Unpack and validate the header */
+    TPM_UNPACK_VERIFY();
+
+    if (objHandle != NULL)
+        ptr = unpack_TPM_HANDLE(ptr, objHandle);
+    else {
+        TPM_HANDLE handle;
+        ptr = unpack_TPM_HANDLE(ptr, &handle);
+    }
+    ptr = unpack_UINT32(ptr, &param_size);
+
+    if (out != NULL) {
+        ptr = unpack_TPM2B_PUBLIC(ptr, &out->outPublic);
+        ptr = unpack_TPM2B_CREATION_DATA(ptr, &out->creationData);
+        ptr = unpack_TPM2B_DIGEST(ptr, &out->creationHash);
+        ptr = unpack_TPMT_TK_CREATION(ptr, &out->creationTicket);
+    } else {
+        ptr += param_size;
+    }
+
+goto egress;
+
+abort_egress:
+egress:
+   return status;
+}
+
+TPM_RC TPM2_HierachyChangeAuth(TPMI_RH_HIERARCHY_AUTH authHandle, TPM2B_AUTH *newAuth)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_HierarchyChangeAuth);
+    ptr = pack_UINT32(ptr, authHandle);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+    ptr = pack_TPM2B_AUTH(ptr, newAuth);
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_RSA_ENCRYPT(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *message,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *outData)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_RSA_Encrypt);
+
+    ptr = pack_UINT32(ptr, keyHandle);
+    ptr = pack_TPM2B_PUBLIC_KEY_RSA(ptr, message);
+    ptr = pack_TPMT_RSA_DECRYPT(ptr, inScheme);
+    ptr = pack_TPM2B_DATA(ptr, label);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    if (outData != NULL)
+        unpack_TPM2B_PUBLIC_KEY_RSA(ptr, outData);
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_Bind(TPMI_DH_OBJECT keyHandle,
+                 void *buf,
+                 UINT32 len,
+                 void *out)
+{
+    TPM_RC status = TPM_SUCCESS;
+    TPM2B_PUBLIC_KEY_RSA message;
+    TPMT_RSA_DECRYPT inScheme;
+    TPM2B_DATA label;
+    TPM2B_PUBLIC_KEY_RSA outData;
+
+    message.size = len;
+    memcpy(message.buffer, buf, len);
+    inScheme.scheme = TPM2_ALG_NULL;
+    label.size = 0;
+    TPMTRYRETURN(TPM2_RSA_ENCRYPT(keyHandle, &message, &inScheme, &label, &outData));
+    memcpy(out, outData.buffer, outData.size);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_RSA_Decrypt(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *cipherText,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *message)
+{
+    UINT32 param_size;
+
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_RSA_Decrypt);
+    ptr = pack_UINT32(ptr, keyHandle);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+    ptr = pack_TPM2B_PUBLIC_KEY_RSA(ptr, cipherText);
+    ptr = pack_TPMT_RSA_DECRYPT(ptr, inScheme);
+    ptr = pack_TPM2B_DATA(ptr, label);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT32(ptr, &param_size);
+
+    if (message)
+        ptr = unpack_TPM2B_PUBLIC_KEY_RSA(ptr, message);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_UnBind(TPMI_DH_OBJECT keyHandle,
+                   UINT32 ilen,
+                   void *in,
+                   UINT32 *olen,
+                   void *out)
+{
+    UINT32 status;
+    TPM2B_PUBLIC_KEY_RSA cipher, message;
+    TPMT_RSA_DECRYPT inScheme;
+    TPM2B_DATA label;
+
+    cipher.size = ilen;
+    memcpy(cipher.buffer, in, ilen);
+    inScheme.scheme = TPM2_ALG_NULL;
+    label.size = 0;
+
+    TPMTRYRETURN(TPM2_RSA_Decrypt(keyHandle, &cipher, &inScheme, &label, &message));
+
+    *olen = message.size;
+    memcpy(out, message.buffer, *olen);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_CLEAR(void)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Clear);
+
+    ptr = pack_UINT32(ptr, TPM_RH_PLATFORM);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_GetRandom(UINT32 * bytesRequested, BYTE * randomBytes)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_GetRandom);
+
+    ptr = pack_UINT16(ptr, (UINT16)*bytesRequested);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT16(ptr, (UINT16 *)bytesRequested);
+    ptr = unpack_TPM_BUFFER(ptr, randomBytes, *bytesRequested);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_FlushContext(TPMI_DH_CONTEXT flushHandle)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_FlushContext);
+
+    ptr = pack_UINT32(ptr, flushHandle);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/tpm2.h b/stubdom/vtpmmgr/tpm2.h
new file mode 100644
index 0000000..9f597ee
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2.h
@@ -0,0 +1,104 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005/2006, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef __TPM2_H__
+#define __TPM2_H__
+
+#include "tcg.h"
+#include "tpm2_types.h"
+
+// ------------------------------------------------------------------
+// TPM 2.0 Exposed API
+// ------------------------------------------------------------------
+
+TPM_RC TPM2_PCR_Read(TPML_PCR_SELECTION pcrSelectionIn,
+                     UINT32 *pcrUpdateCounter,
+                     TPML_PCR_SELECTION *pcrSelectionOut,
+                     TPML_DIGEST *pcrValues);
+
+TPM_RC TPM2_Load(TPMI_DH_OBJECT parentHandle,
+                 TPM2B_PRIVATE *inPrivate,
+                 TPM2B_PUBLIC *inPublic,
+                 TPM_HANDLE *objectHandle,
+                 TPM2B_NAME *name);
+
+TPM_RC TPM2_Create(TPMI_DH_OBJECT parentHandle,
+                   TPM2_Create_Params_in *in,
+                   TPM2_Create_Params_out *out);
+
+TPM_RC TPM2_CreatePrimary(TPMI_RH_HIERARCHY primaryHandle,
+                          TPM2_Create_Params_in *objHandle,
+                          TPM_HANDLE *in,
+                          TPM2_Create_Params_out *out);
+
+TPM_RC TPM2_HierachyChangeAuth(TPMI_RH_HIERARCHY_AUTH authHandle,
+                               TPM2B_AUTH *newAuth);
+
+TPM_RC TPM2_RSA_ENCRYPT(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *message,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *outData);
+
+TPM_RC TPM2_Bind(TPMI_DH_OBJECT keyHandle,
+                 void *buf,
+                 UINT32 len,
+                 void *out);
+
+TPM_RC TPM2_RSA_Decrypt(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *cipherText,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *message);
+
+TPM_RC TPM2_UnBind(TPMI_DH_OBJECT keyHandle,
+                   UINT32 ilen,
+                   void *in,
+                   UINT32 *olen,
+                   void *out);
+
+TPM_RESULT TPM2_GetRandom(UINT32* bytesRequested,
+                          BYTE* randomBytes);
+
+TPM_RC TPM2_CLEAR(void);
+
+TPM_RC TPM2_FlushContext(TPMI_DH_CONTEXT);
+#endif //TPM2_H
-- 
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 Dec 17 15:56:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1Gxc-0006rW-FX; Wed, 17 Dec 2014 15:56: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 1Y1Gxb-0006qQ-Kv
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:56:23 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	BC/FF-22777-6A7A1945; Wed, 17 Dec 2014 15:56:22 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418831781!13943235!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 2373 invoked from network); 17 Dec 2014 15:56:22 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-206.messagelabs.com with SMTP;
	17 Dec 2014 15:56:22 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 17 Dec 2014 07:54:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="625307847"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 17 Dec 2014 07:55:56 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:52:11 -0500
Message-Id: <1418817131-5683-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 13/14] vTPM/TPM2: Unind group keys and
	sectors data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/disk_read.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_read.c b/stubdom/vtpmmgr/disk_read.c
index 33aacdd..e147e90 100644
--- a/stubdom/vtpmmgr/disk_read.c
+++ b/stubdom/vtpmmgr/disk_read.c
@@ -88,7 +88,13 @@ static int find_group_key(struct mem_group *dst,
 		TPM_pcr_digest(&buf, cfg->pcr_selection);
 		if (memcmp(&buf, &cfg->digest_release, 20))
 			continue;
-		rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
+
+        /*TPM 2.0 unbind | TPM 1.x unseal*/
+        if (hw_is_tpm2())
+            rc = TPM2_disk_unbind(&sealed, &olen, cfg);
+        else
+            rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
+
 		if (rc)
 			continue;
 		if (memcmp(&sealed.magic, DISK_GROUP_BOUND_MAGIC, 4))
@@ -112,9 +118,15 @@ static int find_group_key(struct mem_group *dst,
 static int parse_root_key(struct mem_tpm_mgr *dst, struct disk_seal_entry *src)
 {
 	int rc;
+    unsigned int olen;
 	struct disk_root_sealed_data sealed;
 
-	rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
+    /*TPM 2.0 unbind | TPM 1.x unseal*/
+    if (hw_is_tpm2())
+        rc = TPM2_disk_unbind(&sealed, &olen, src);
+    else
+        rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
+
 	if (rc)
 		return rc;
 
-- 
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 Dec 17 15:56:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 15: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 1Y1Gxc-0006rW-FX; Wed, 17 Dec 2014 15:56: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 1Y1Gxb-0006qQ-Kv
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 15:56:23 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	BC/FF-22777-6A7A1945; Wed, 17 Dec 2014 15:56:22 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418831781!13943235!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 2373 invoked from network); 17 Dec 2014 15:56:22 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-206.messagelabs.com with SMTP;
	17 Dec 2014 15:56:22 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 17 Dec 2014 07:54:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,594,1413270000"; d="scan'208";a="625307847"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 17 Dec 2014 07:55:56 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 17 Dec 2014 06:52:11 -0500
Message-Id: <1418817131-5683-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 13/14] vTPM/TPM2: Unind group keys and
	sectors data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/disk_read.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_read.c b/stubdom/vtpmmgr/disk_read.c
index 33aacdd..e147e90 100644
--- a/stubdom/vtpmmgr/disk_read.c
+++ b/stubdom/vtpmmgr/disk_read.c
@@ -88,7 +88,13 @@ static int find_group_key(struct mem_group *dst,
 		TPM_pcr_digest(&buf, cfg->pcr_selection);
 		if (memcmp(&buf, &cfg->digest_release, 20))
 			continue;
-		rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
+
+        /*TPM 2.0 unbind | TPM 1.x unseal*/
+        if (hw_is_tpm2())
+            rc = TPM2_disk_unbind(&sealed, &olen, cfg);
+        else
+            rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
+
 		if (rc)
 			continue;
 		if (memcmp(&sealed.magic, DISK_GROUP_BOUND_MAGIC, 4))
@@ -112,9 +118,15 @@ static int find_group_key(struct mem_group *dst,
 static int parse_root_key(struct mem_tpm_mgr *dst, struct disk_seal_entry *src)
 {
 	int rc;
+    unsigned int olen;
 	struct disk_root_sealed_data sealed;
 
-	rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
+    /*TPM 2.0 unbind | TPM 1.x unseal*/
+    if (hw_is_tpm2())
+        rc = TPM2_disk_unbind(&sealed, &olen, src);
+    else
+        rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
+
 	if (rc)
 		return rc;
 
-- 
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 Dec 17 16:14:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 16: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 1Y1HEB-0000cS-Ea; Wed, 17 Dec 2014 16: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 1Y1HE9-0000cL-Al
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 16:13:29 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	9C/95-22777-8ABA1945; Wed, 17 Dec 2014 16:13:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418832806!8522549!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24729 invoked from network); 17 Dec 2014 16:13:27 -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; 17 Dec 2014 16:13: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 sBHGDOdu025409
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 16:13:25 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
	sBHGDNmO028350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 16:13:24 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
	sBHGDNiE018874; Wed, 17 Dec 2014 16:13:23 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 08:13:23 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 54B3B12520A; Wed, 17 Dec 2014 11:13:23 -0500 (EST)
Date: Wed, 17 Dec 2014 11:13:23 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bob Liu <bob.liu@oracle.com>
Message-ID: <20141217161323.GA6414@laptop.dumpdata.com>
References: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>
	<54900A3F.7070300@citrix.com> <54913C72.7090704@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54913C72.7090704@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: david.vrabel@citrix.com, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: increase the default value of
 xen_blkif_max_segments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 17, 2014 at 04:18:58PM +0800, Bob Liu wrote:
> =

> On 12/16/2014 06:32 PM, Roger Pau Monn=E9 wrote:
> > El 16/12/14 a les 11.11, Bob Liu ha escrit:
> >> The default maximum value of segments in indirect requests was 32, IO
> >> operations with bigger block size(>32*4k) would be split and performan=
ce start
> >> to drop.
> >>
> >> Nowadays backend device usually support 512k max_sectors_kb on desktop=
, and
> >> may larger on server machines with high-end storage system.
> >> The default size 128k was not very appropriate, this patch increases t=
he default
> >> maximum value to 128(128*4k=3D512k).
> > =

> > This looks fine, do you have any data/graphs to backup your reasoning?
> > =

> =

> I only have some results for 1M block size FIO test but I think that's
> enough.
> =

> xen_blkfront.max 	Rate (MB/s) 	Percent of Dom-0
> 32 	11.1 	31.0%
> 48 	15.3 	42.7%
> 64 	19.8 	55.3%
> 80 	19.9 	55.6%
> 96 	23.0 	64.2%
> 112 	23.7 	66.2%
> 128 	31.6 	88.3%
> =

> The rates above are compared against the dom-0 rate of 35.8 MB/s.
> =

> > I would also add to the commit message that this change implies we can
> > now have 32*128+32 =3D 4128 in-flight grants, which greatly surpasses t=
he
> =

> The number could be larger if using more pages as the
> xen-blkfront/backend ring based on Wei Liu's patch "xenbus_client:
> extend interface to suppurt multi-page ring", it helped improve the IO
> performance a lot on our system connected with high-end storage.
> I'm preparing resend related patches.

Or potentially making the request and response be seperate rings - and the
response ring entries not tied in to the request. As in right now if we
have an request at say slot 1,5, and 7, we expect the response to be at
slot 1,5, and 7 as well. If we made the response ring producer index
not be tied to the request we could put the responses on the first available
slot - so say at 1, 2, and 3 (if all three responses came at the same time).

> =

> > default amount of persistent grants blkback can handle, so the LRU in
> > blkback will kick in.
> > =

> =

> Sounds good.
> =

> -- =

> Regards,
> -Bob
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 17 16:14:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 16: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 1Y1HEB-0000cS-Ea; Wed, 17 Dec 2014 16: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 1Y1HE9-0000cL-Al
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 16:13:29 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	9C/95-22777-8ABA1945; Wed, 17 Dec 2014 16:13:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418832806!8522549!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24729 invoked from network); 17 Dec 2014 16:13:27 -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; 17 Dec 2014 16:13: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 sBHGDOdu025409
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 16:13:25 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
	sBHGDNmO028350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 16:13:24 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
	sBHGDNiE018874; Wed, 17 Dec 2014 16:13:23 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 08:13:23 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 54B3B12520A; Wed, 17 Dec 2014 11:13:23 -0500 (EST)
Date: Wed, 17 Dec 2014 11:13:23 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bob Liu <bob.liu@oracle.com>
Message-ID: <20141217161323.GA6414@laptop.dumpdata.com>
References: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>
	<54900A3F.7070300@citrix.com> <54913C72.7090704@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54913C72.7090704@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: david.vrabel@citrix.com, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: increase the default value of
 xen_blkif_max_segments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 17, 2014 at 04:18:58PM +0800, Bob Liu wrote:
> =

> On 12/16/2014 06:32 PM, Roger Pau Monn=E9 wrote:
> > El 16/12/14 a les 11.11, Bob Liu ha escrit:
> >> The default maximum value of segments in indirect requests was 32, IO
> >> operations with bigger block size(>32*4k) would be split and performan=
ce start
> >> to drop.
> >>
> >> Nowadays backend device usually support 512k max_sectors_kb on desktop=
, and
> >> may larger on server machines with high-end storage system.
> >> The default size 128k was not very appropriate, this patch increases t=
he default
> >> maximum value to 128(128*4k=3D512k).
> > =

> > This looks fine, do you have any data/graphs to backup your reasoning?
> > =

> =

> I only have some results for 1M block size FIO test but I think that's
> enough.
> =

> xen_blkfront.max 	Rate (MB/s) 	Percent of Dom-0
> 32 	11.1 	31.0%
> 48 	15.3 	42.7%
> 64 	19.8 	55.3%
> 80 	19.9 	55.6%
> 96 	23.0 	64.2%
> 112 	23.7 	66.2%
> 128 	31.6 	88.3%
> =

> The rates above are compared against the dom-0 rate of 35.8 MB/s.
> =

> > I would also add to the commit message that this change implies we can
> > now have 32*128+32 =3D 4128 in-flight grants, which greatly surpasses t=
he
> =

> The number could be larger if using more pages as the
> xen-blkfront/backend ring based on Wei Liu's patch "xenbus_client:
> extend interface to suppurt multi-page ring", it helped improve the IO
> performance a lot on our system connected with high-end storage.
> I'm preparing resend related patches.

Or potentially making the request and response be seperate rings - and the
response ring entries not tied in to the request. As in right now if we
have an request at say slot 1,5, and 7, we expect the response to be at
slot 1,5, and 7 as well. If we made the response ring producer index
not be tied to the request we could put the responses on the first available
slot - so say at 1, 2, and 3 (if all three responses came at the same time).

> =

> > default amount of persistent grants blkback can handle, so the LRU in
> > blkback will kick in.
> > =

> =

> Sounds good.
> =

> -- =

> Regards,
> -Bob
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 17 16:21:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 16:21:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1HLs-0000vZ-DW; Wed, 17 Dec 2014 16:21: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 1Y1HLq-0000vQ-Q7
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 16:21:27 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	40/29-24124-68DA1945; Wed, 17 Dec 2014 16:21:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418833283!6345457!1
X-Originating-IP: [156.151.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 24978 invoked from network); 17 Dec 2014 16:21:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 16:21: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 sBHGLMAe013581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 16:21:23 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
	sBHGLKe4023940
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 16:21: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
	sBHGLKNe016397; Wed, 17 Dec 2014 16:21:20 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 08:21:20 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 24912125228; Wed, 17 Dec 2014 11:21:15 -0500 (EST)
Date: Wed, 17 Dec 2014 11:21:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141217162115.GD6414@laptop.dumpdata.com>
References: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 17, 2014 at 10:35:47AM -0500, Boris Ostrovsky wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try to dereference it in
> the future, when VCPU is gone.
> 
> We have to do this atomically since otherwise there is a (somewhat
> theoretical) chance that between test and subsequent clearing
> of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
> both vpmu_load() and then vpmu_save() for another VCPU. The former
> will clear last_vcpu and the latter will set it to something else.
> 
> We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
> avoid unnecessary cmpxchg() and arch-specific destroy ops. Thus
> checks in AMD and Intel routines are no longer needed.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  xen/arch/x86/hvm/svm/vpmu.c       |    3 ---
>  xen/arch/x86/hvm/vmx/vpmu_core2.c |    2 --
>  xen/arch/x86/hvm/vpmu.c           |    7 +++++++
>  3 files changed, 7 insertions(+), 5 deletions(-)
> 
> Changes in v3:
>  * Use cmpxchg instead of IPI
>  * Use correct routine nemas in commit message
>  * Remove duplicate test for VPMU_CONTEXT_ALLOCATED in arch-specific
>    destroy ops
> 
> Changes in v2:
>  * Test last_vcpu locally before IPI
>  * Don't handle local pcpu as a special case --- on_selected_cpus
>    will take care of that
>  * Dont't cast variables unnecessarily
> 
> diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
> index 8e07a98..4c448bb 100644
> --- a/xen/arch/x86/hvm/svm/vpmu.c
> +++ b/xen/arch/x86/hvm/svm/vpmu.c
> @@ -403,9 +403,6 @@ static void amd_vpmu_destroy(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> -    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> -        return;
> -
>      if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
>          amd_vpmu_unset_msr_bitmap(v);
>  
> diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> index 68b6272..590c2a9 100644
> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> @@ -818,8 +818,6 @@ 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 ( cpu_has_vmx_msr_bitmap )
> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
> index 1df74c2..7cc95ae 100644
> --- a/xen/arch/x86/hvm/vpmu.c
> +++ b/xen/arch/x86/hvm/vpmu.c
> @@ -250,6 +250,13 @@ void vpmu_initialise(struct vcpu *v)
>  void vpmu_destroy(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
> +    struct vcpu **last = &per_cpu(last_vcpu, vpmu->last_pcpu);
> +
> +    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> +        return;
> +

Could this just be:

	(void)cmpxchg(&per_cpu(last_vcpu, vpmu->last_pcpu), v, NULL);

so that we don't do the 'per_cpu' access in case we return because
VPMU_CONTEXT_ALLOCATED is not set?

Either way,

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thank you for spotting this.
> +    /* Need to clear last_vcpu in case it points to v */
> +    (void)cmpxchg(last, v, NULL);
>  
>      if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
> -- 
> 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 Wed Dec 17 16:21:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 16:21:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1HLs-0000vZ-DW; Wed, 17 Dec 2014 16:21: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 1Y1HLq-0000vQ-Q7
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 16:21:27 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	40/29-24124-68DA1945; Wed, 17 Dec 2014 16:21:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418833283!6345457!1
X-Originating-IP: [156.151.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 24978 invoked from network); 17 Dec 2014 16:21:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 16:21: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 sBHGLMAe013581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 16:21:23 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
	sBHGLKe4023940
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 16:21: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
	sBHGLKNe016397; Wed, 17 Dec 2014 16:21:20 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 08:21:20 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 24912125228; Wed, 17 Dec 2014 11:21:15 -0500 (EST)
Date: Wed, 17 Dec 2014 11:21:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141217162115.GD6414@laptop.dumpdata.com>
References: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 17, 2014 at 10:35:47AM -0500, Boris Ostrovsky wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try to dereference it in
> the future, when VCPU is gone.
> 
> We have to do this atomically since otherwise there is a (somewhat
> theoretical) chance that between test and subsequent clearing
> of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
> both vpmu_load() and then vpmu_save() for another VCPU. The former
> will clear last_vcpu and the latter will set it to something else.
> 
> We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
> avoid unnecessary cmpxchg() and arch-specific destroy ops. Thus
> checks in AMD and Intel routines are no longer needed.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  xen/arch/x86/hvm/svm/vpmu.c       |    3 ---
>  xen/arch/x86/hvm/vmx/vpmu_core2.c |    2 --
>  xen/arch/x86/hvm/vpmu.c           |    7 +++++++
>  3 files changed, 7 insertions(+), 5 deletions(-)
> 
> Changes in v3:
>  * Use cmpxchg instead of IPI
>  * Use correct routine nemas in commit message
>  * Remove duplicate test for VPMU_CONTEXT_ALLOCATED in arch-specific
>    destroy ops
> 
> Changes in v2:
>  * Test last_vcpu locally before IPI
>  * Don't handle local pcpu as a special case --- on_selected_cpus
>    will take care of that
>  * Dont't cast variables unnecessarily
> 
> diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
> index 8e07a98..4c448bb 100644
> --- a/xen/arch/x86/hvm/svm/vpmu.c
> +++ b/xen/arch/x86/hvm/svm/vpmu.c
> @@ -403,9 +403,6 @@ static void amd_vpmu_destroy(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> -    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> -        return;
> -
>      if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
>          amd_vpmu_unset_msr_bitmap(v);
>  
> diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> index 68b6272..590c2a9 100644
> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> @@ -818,8 +818,6 @@ 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 ( cpu_has_vmx_msr_bitmap )
> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
> index 1df74c2..7cc95ae 100644
> --- a/xen/arch/x86/hvm/vpmu.c
> +++ b/xen/arch/x86/hvm/vpmu.c
> @@ -250,6 +250,13 @@ void vpmu_initialise(struct vcpu *v)
>  void vpmu_destroy(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
> +    struct vcpu **last = &per_cpu(last_vcpu, vpmu->last_pcpu);
> +
> +    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> +        return;
> +

Could this just be:

	(void)cmpxchg(&per_cpu(last_vcpu, vpmu->last_pcpu), v, NULL);

so that we don't do the 'per_cpu' access in case we return because
VPMU_CONTEXT_ALLOCATED is not set?

Either way,

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thank you for spotting this.
> +    /* Need to clear last_vcpu in case it points to v */
> +    (void)cmpxchg(last, v, NULL);
>  
>      if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
> -- 
> 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 Wed Dec 17 16:35:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 16: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 1Y1HYo-0001tj-PK; Wed, 17 Dec 2014 16:34:50 +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 1Y1HYn-0001te-K0
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 16:34:49 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	E3/85-03145-8A0B1945; Wed, 17 Dec 2014 16:34:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418834083!15696178!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 26715 invoked from network); 17 Dec 2014 16:34:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 16:34:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208";a="205882075"
Message-ID: <5491B0A1.7080601@citrix.com>
Date: Wed, 17 Dec 2014 16:34:41 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Bob Liu
	<bob.liu@oracle.com>
References: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>	<54900A3F.7070300@citrix.com>
	<54913C72.7090704@oracle.com>
	<20141217161323.GA6414@laptop.dumpdata.com>
In-Reply-To: <20141217161323.GA6414@laptop.dumpdata.com>
Content-Length: 2110
X-DLP: MIA2
Cc: linux-kernel@vger.kernel.org,
	=?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>,
	david.vrabel@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: increase the default value of
 xen_blkif_max_segments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 17/12/14 16:13, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 17, 2014 at 04:18:58PM +0800, Bob Liu wrote:
>>
>> On 12/16/2014 06:32 PM, Roger Pau Monn=E9 wrote:
>>> El 16/12/14 a les 11.11, Bob Liu ha escrit:
>>>> The default maximum value of segments in indirect requests was 32, IO
>>>> operations with bigger block size(>32*4k) would be split and performan=
ce start
>>>> to drop.
>>>>
>>>> Nowadays backend device usually support 512k max_sectors_kb on desktop=
, and
>>>> may larger on server machines with high-end storage system.
>>>> The default size 128k was not very appropriate, this patch increases t=
he default
>>>> maximum value to 128(128*4k=3D512k).
>>>
>>> This looks fine, do you have any data/graphs to backup your reasoning?
>>>
>>
>> I only have some results for 1M block size FIO test but I think that's
>> enough.
>>
>> xen_blkfront.max 	Rate (MB/s) 	Percent of Dom-0
>> 32 	11.1 	31.0%
>> 48 	15.3 	42.7%
>> 64 	19.8 	55.3%
>> 80 	19.9 	55.6%
>> 96 	23.0 	64.2%
>> 112 	23.7 	66.2%
>> 128 	31.6 	88.3%
>>
>> The rates above are compared against the dom-0 rate of 35.8 MB/s.
>>
>>> I would also add to the commit message that this change implies we can
>>> now have 32*128+32 =3D 4128 in-flight grants, which greatly surpasses t=
he
>>
>> The number could be larger if using more pages as the
>> xen-blkfront/backend ring based on Wei Liu's patch "xenbus_client:
>> extend interface to suppurt multi-page ring", it helped improve the IO
>> performance a lot on our system connected with high-end storage.
>> I'm preparing resend related patches.
> =

> Or potentially making the request and response be seperate rings - and the
> response ring entries not tied in to the request. As in right now if we
> have an request at say slot 1,5, and 7, we expect the response to be at
> slot 1,5, and 7 as well.

No. Responses are placed in the first available slot.  The response is
associated with the original request by the ID field.

See make_response().

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 16:35:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 16: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 1Y1HYo-0001tj-PK; Wed, 17 Dec 2014 16:34:50 +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 1Y1HYn-0001te-K0
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 16:34:49 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	E3/85-03145-8A0B1945; Wed, 17 Dec 2014 16:34:48 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418834083!15696178!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 26715 invoked from network); 17 Dec 2014 16:34:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 16:34:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208";a="205882075"
Message-ID: <5491B0A1.7080601@citrix.com>
Date: Wed, 17 Dec 2014 16:34:41 +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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Bob Liu
	<bob.liu@oracle.com>
References: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>	<54900A3F.7070300@citrix.com>
	<54913C72.7090704@oracle.com>
	<20141217161323.GA6414@laptop.dumpdata.com>
In-Reply-To: <20141217161323.GA6414@laptop.dumpdata.com>
Content-Length: 2110
X-DLP: MIA2
Cc: linux-kernel@vger.kernel.org,
	=?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>,
	david.vrabel@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: increase the default value of
 xen_blkif_max_segments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 17/12/14 16:13, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 17, 2014 at 04:18:58PM +0800, Bob Liu wrote:
>>
>> On 12/16/2014 06:32 PM, Roger Pau Monn=E9 wrote:
>>> El 16/12/14 a les 11.11, Bob Liu ha escrit:
>>>> The default maximum value of segments in indirect requests was 32, IO
>>>> operations with bigger block size(>32*4k) would be split and performan=
ce start
>>>> to drop.
>>>>
>>>> Nowadays backend device usually support 512k max_sectors_kb on desktop=
, and
>>>> may larger on server machines with high-end storage system.
>>>> The default size 128k was not very appropriate, this patch increases t=
he default
>>>> maximum value to 128(128*4k=3D512k).
>>>
>>> This looks fine, do you have any data/graphs to backup your reasoning?
>>>
>>
>> I only have some results for 1M block size FIO test but I think that's
>> enough.
>>
>> xen_blkfront.max 	Rate (MB/s) 	Percent of Dom-0
>> 32 	11.1 	31.0%
>> 48 	15.3 	42.7%
>> 64 	19.8 	55.3%
>> 80 	19.9 	55.6%
>> 96 	23.0 	64.2%
>> 112 	23.7 	66.2%
>> 128 	31.6 	88.3%
>>
>> The rates above are compared against the dom-0 rate of 35.8 MB/s.
>>
>>> I would also add to the commit message that this change implies we can
>>> now have 32*128+32 =3D 4128 in-flight grants, which greatly surpasses t=
he
>>
>> The number could be larger if using more pages as the
>> xen-blkfront/backend ring based on Wei Liu's patch "xenbus_client:
>> extend interface to suppurt multi-page ring", it helped improve the IO
>> performance a lot on our system connected with high-end storage.
>> I'm preparing resend related patches.
> =

> Or potentially making the request and response be seperate rings - and the
> response ring entries not tied in to the request. As in right now if we
> have an request at say slot 1,5, and 7, we expect the response to be at
> slot 1,5, and 7 as well.

No. Responses are placed in the first available slot.  The response is
associated with the original request by the ID field.

See make_response().

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 16:47:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 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 1Y1Hkw-0002AJ-FA; Wed, 17 Dec 2014 16:47:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y1Hku-0002AE-US
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 16:47:21 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	B7/C5-02953-893B1945; Wed, 17 Dec 2014 16:47:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418834838!10299133!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10656 invoked from network); 17 Dec 2014 16:47:19 -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; 17 Dec 2014 16:47:19 -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 sBHGlE4T016922
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 16:47:15 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
	sBHGlD87015189
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 16:47:13 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
	sBHGlCwl028328; Wed, 17 Dec 2014 16:47:12 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 08:47:12 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 79FCA1252A1; Wed, 17 Dec 2014 11:47:12 -0500 (EST)
Date: Wed, 17 Dec 2014 11:47:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141217164712.GG6414@laptop.dumpdata.com>
References: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>
	<54900A3F.7070300@citrix.com> <54913C72.7090704@oracle.com>
	<20141217161323.GA6414@laptop.dumpdata.com>
	<5491B0A1.7080601@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5491B0A1.7080601@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: increase the default value of
 xen_blkif_max_segments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 17, 2014 at 04:34:41PM +0000, David Vrabel wrote:
> On 17/12/14 16:13, Konrad Rzeszutek Wilk wrote:
> > On Wed, Dec 17, 2014 at 04:18:58PM +0800, Bob Liu wrote:
> >>
> >> On 12/16/2014 06:32 PM, Roger Pau Monn=E9 wrote:
> >>> El 16/12/14 a les 11.11, Bob Liu ha escrit:
> >>>> The default maximum value of segments in indirect requests was 32, IO
> >>>> operations with bigger block size(>32*4k) would be split and perform=
ance start
> >>>> to drop.
> >>>>
> >>>> Nowadays backend device usually support 512k max_sectors_kb on deskt=
op, and
> >>>> may larger on server machines with high-end storage system.
> >>>> The default size 128k was not very appropriate, this patch increases=
 the default
> >>>> maximum value to 128(128*4k=3D512k).
> >>>
> >>> This looks fine, do you have any data/graphs to backup your reasoning?
> >>>
> >>
> >> I only have some results for 1M block size FIO test but I think that's
> >> enough.
> >>
> >> xen_blkfront.max 	Rate (MB/s) 	Percent of Dom-0
> >> 32 	11.1 	31.0%
> >> 48 	15.3 	42.7%
> >> 64 	19.8 	55.3%
> >> 80 	19.9 	55.6%
> >> 96 	23.0 	64.2%
> >> 112 	23.7 	66.2%
> >> 128 	31.6 	88.3%
> >>
> >> The rates above are compared against the dom-0 rate of 35.8 MB/s.
> >>
> >>> I would also add to the commit message that this change implies we can
> >>> now have 32*128+32 =3D 4128 in-flight grants, which greatly surpasses=
 the
> >>
> >> The number could be larger if using more pages as the
> >> xen-blkfront/backend ring based on Wei Liu's patch "xenbus_client:
> >> extend interface to suppurt multi-page ring", it helped improve the IO
> >> performance a lot on our system connected with high-end storage.
> >> I'm preparing resend related patches.
> > =

> > Or potentially making the request and response be seperate rings - and =
the
> > response ring entries not tied in to the request. As in right now if we
> > have an request at say slot 1,5, and 7, we expect the response to be at
> > slot 1,5, and 7 as well.
> =

> No. Responses are placed in the first available slot.  The response is
> associated with the original request by the ID field.
> =

> See make_response().

You are right! Thank you for the update.
> =

> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 16:47:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 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 1Y1Hkw-0002AJ-FA; Wed, 17 Dec 2014 16:47:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y1Hku-0002AE-US
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 16:47:21 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	B7/C5-02953-893B1945; Wed, 17 Dec 2014 16:47:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418834838!10299133!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10656 invoked from network); 17 Dec 2014 16:47:19 -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; 17 Dec 2014 16:47:19 -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 sBHGlE4T016922
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 16:47:15 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
	sBHGlD87015189
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 16:47:13 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
	sBHGlCwl028328; Wed, 17 Dec 2014 16:47:12 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 08:47:12 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 79FCA1252A1; Wed, 17 Dec 2014 11:47:12 -0500 (EST)
Date: Wed, 17 Dec 2014 11:47:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141217164712.GG6414@laptop.dumpdata.com>
References: <1418724696-23922-1-git-send-email-bob.liu@oracle.com>
	<54900A3F.7070300@citrix.com> <54913C72.7090704@oracle.com>
	<20141217161323.GA6414@laptop.dumpdata.com>
	<5491B0A1.7080601@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5491B0A1.7080601@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/blkfront: increase the default value of
 xen_blkif_max_segments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Dec 17, 2014 at 04:34:41PM +0000, David Vrabel wrote:
> On 17/12/14 16:13, Konrad Rzeszutek Wilk wrote:
> > On Wed, Dec 17, 2014 at 04:18:58PM +0800, Bob Liu wrote:
> >>
> >> On 12/16/2014 06:32 PM, Roger Pau Monn=E9 wrote:
> >>> El 16/12/14 a les 11.11, Bob Liu ha escrit:
> >>>> The default maximum value of segments in indirect requests was 32, IO
> >>>> operations with bigger block size(>32*4k) would be split and perform=
ance start
> >>>> to drop.
> >>>>
> >>>> Nowadays backend device usually support 512k max_sectors_kb on deskt=
op, and
> >>>> may larger on server machines with high-end storage system.
> >>>> The default size 128k was not very appropriate, this patch increases=
 the default
> >>>> maximum value to 128(128*4k=3D512k).
> >>>
> >>> This looks fine, do you have any data/graphs to backup your reasoning?
> >>>
> >>
> >> I only have some results for 1M block size FIO test but I think that's
> >> enough.
> >>
> >> xen_blkfront.max 	Rate (MB/s) 	Percent of Dom-0
> >> 32 	11.1 	31.0%
> >> 48 	15.3 	42.7%
> >> 64 	19.8 	55.3%
> >> 80 	19.9 	55.6%
> >> 96 	23.0 	64.2%
> >> 112 	23.7 	66.2%
> >> 128 	31.6 	88.3%
> >>
> >> The rates above are compared against the dom-0 rate of 35.8 MB/s.
> >>
> >>> I would also add to the commit message that this change implies we can
> >>> now have 32*128+32 =3D 4128 in-flight grants, which greatly surpasses=
 the
> >>
> >> The number could be larger if using more pages as the
> >> xen-blkfront/backend ring based on Wei Liu's patch "xenbus_client:
> >> extend interface to suppurt multi-page ring", it helped improve the IO
> >> performance a lot on our system connected with high-end storage.
> >> I'm preparing resend related patches.
> > =

> > Or potentially making the request and response be seperate rings - and =
the
> > response ring entries not tied in to the request. As in right now if we
> > have an request at say slot 1,5, and 7, we expect the response to be at
> > slot 1,5, and 7 as well.
> =

> No. Responses are placed in the first available slot.  The response is
> associated with the original request by the ID field.
> =

> See make_response().

You are right! Thank you for the update.
> =

> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 16:51:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 16: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 1Y1HpB-0002IP-6U; Wed, 17 Dec 2014 16:51: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 1Y1Hp9-0002IF-Gx
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 16:51:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8E/12-15461-E94B1945; Wed, 17 Dec 2014 16:51:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418835100!16321756!1
X-Originating-IP: [156.151.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 8894 invoked from network); 17 Dec 2014 16:51:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 16:51: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 sBHGpdOQ029788
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 16:51:40 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
	sBHGpcFA028325
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 16:51:39 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
	sBHGpchh027770; Wed, 17 Dec 2014 16:51:38 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 ; Wed, 17 Dec 2014 08:51:38 -0800
Message-ID: <5491B515.9060803@oracle.com>
Date: Wed, 17 Dec 2014 11:53:41 -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>
References: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141217162115.GD6414@laptop.dumpdata.com>
In-Reply-To: <20141217162115.GD6414@laptop.dumpdata.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/17/2014 11:21 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 17, 2014 at 10:35:47AM -0500, Boris Ostrovsky wrote:
>> We need to make sure that last_vcpu is not pointing to VCPU whose
>> VPMU is being destroyed. Otherwise we may try to dereference it in
>> the future, when VCPU is gone.
>>
>> We have to do this atomically since otherwise there is a (somewhat
>> theoretical) chance that between test and subsequent clearing
>> of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
>> both vpmu_load() and then vpmu_save() for another VCPU. The former
>> will clear last_vcpu and the latter will set it to something else.
>>
>> We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
>> avoid unnecessary cmpxchg() and arch-specific destroy ops. Thus
>> checks in AMD and Intel routines are no longer needed.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>   xen/arch/x86/hvm/svm/vpmu.c       |    3 ---
>>   xen/arch/x86/hvm/vmx/vpmu_core2.c |    2 --
>>   xen/arch/x86/hvm/vpmu.c           |    7 +++++++
>>   3 files changed, 7 insertions(+), 5 deletions(-)
>>
>> Changes in v3:
>>   * Use cmpxchg instead of IPI
>>   * Use correct routine nemas in commit message
>>   * Remove duplicate test for VPMU_CONTEXT_ALLOCATED in arch-specific
>>     destroy ops
>>
>> Changes in v2:
>>   * Test last_vcpu locally before IPI
>>   * Don't handle local pcpu as a special case --- on_selected_cpus
>>     will take care of that
>>   * Dont't cast variables unnecessarily
>>
>> diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
>> index 8e07a98..4c448bb 100644
>> --- a/xen/arch/x86/hvm/svm/vpmu.c
>> +++ b/xen/arch/x86/hvm/svm/vpmu.c
>> @@ -403,9 +403,6 @@ static void amd_vpmu_destroy(struct vcpu *v)
>>   {
>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>   
>> -    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
>> -        return;
>> -
>>       if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
>>           amd_vpmu_unset_msr_bitmap(v);
>>   
>> diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
>> index 68b6272..590c2a9 100644
>> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
>> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
>> @@ -818,8 +818,6 @@ 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 ( cpu_has_vmx_msr_bitmap )
>> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
>> index 1df74c2..7cc95ae 100644
>> --- a/xen/arch/x86/hvm/vpmu.c
>> +++ b/xen/arch/x86/hvm/vpmu.c
>> @@ -250,6 +250,13 @@ void vpmu_initialise(struct vcpu *v)
>>   void vpmu_destroy(struct vcpu *v)
>>   {
>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>> +    struct vcpu **last = &per_cpu(last_vcpu, vpmu->last_pcpu);
>> +
>> +    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
>> +        return;
>> +
> Could this just be:
>
> 	(void)cmpxchg(&per_cpu(last_vcpu, vpmu->last_pcpu), v, NULL);
>
> so that we don't do the 'per_cpu' access in case we return because
> VPMU_CONTEXT_ALLOCATED is not set?


Ugh. This is actually what I meant to send but I forgot to refresh the 
patch.

Do you want me to re-send it?

-boris


>
> Either way,
>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> Thank you for spotting this.
>> +    /* Need to clear last_vcpu in case it points to v */
>> +    (void)cmpxchg(last, v, NULL);
>>   
>>       if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>>           vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>> -- 
>> 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 Wed Dec 17 16:51:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 16: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 1Y1HpB-0002IP-6U; Wed, 17 Dec 2014 16:51: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 1Y1Hp9-0002IF-Gx
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 16:51:43 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	8E/12-15461-E94B1945; Wed, 17 Dec 2014 16:51:42 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418835100!16321756!1
X-Originating-IP: [156.151.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 8894 invoked from network); 17 Dec 2014 16:51:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 16:51: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 sBHGpdOQ029788
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 16:51:40 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
	sBHGpcFA028325
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 16:51:39 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
	sBHGpchh027770; Wed, 17 Dec 2014 16:51:38 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 ; Wed, 17 Dec 2014 08:51:38 -0800
Message-ID: <5491B515.9060803@oracle.com>
Date: Wed, 17 Dec 2014 11:53:41 -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>
References: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141217162115.GD6414@laptop.dumpdata.com>
In-Reply-To: <20141217162115.GD6414@laptop.dumpdata.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/17/2014 11:21 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 17, 2014 at 10:35:47AM -0500, Boris Ostrovsky wrote:
>> We need to make sure that last_vcpu is not pointing to VCPU whose
>> VPMU is being destroyed. Otherwise we may try to dereference it in
>> the future, when VCPU is gone.
>>
>> We have to do this atomically since otherwise there is a (somewhat
>> theoretical) chance that between test and subsequent clearing
>> of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
>> both vpmu_load() and then vpmu_save() for another VCPU. The former
>> will clear last_vcpu and the latter will set it to something else.
>>
>> We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
>> avoid unnecessary cmpxchg() and arch-specific destroy ops. Thus
>> checks in AMD and Intel routines are no longer needed.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>   xen/arch/x86/hvm/svm/vpmu.c       |    3 ---
>>   xen/arch/x86/hvm/vmx/vpmu_core2.c |    2 --
>>   xen/arch/x86/hvm/vpmu.c           |    7 +++++++
>>   3 files changed, 7 insertions(+), 5 deletions(-)
>>
>> Changes in v3:
>>   * Use cmpxchg instead of IPI
>>   * Use correct routine nemas in commit message
>>   * Remove duplicate test for VPMU_CONTEXT_ALLOCATED in arch-specific
>>     destroy ops
>>
>> Changes in v2:
>>   * Test last_vcpu locally before IPI
>>   * Don't handle local pcpu as a special case --- on_selected_cpus
>>     will take care of that
>>   * Dont't cast variables unnecessarily
>>
>> diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
>> index 8e07a98..4c448bb 100644
>> --- a/xen/arch/x86/hvm/svm/vpmu.c
>> +++ b/xen/arch/x86/hvm/svm/vpmu.c
>> @@ -403,9 +403,6 @@ static void amd_vpmu_destroy(struct vcpu *v)
>>   {
>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>   
>> -    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
>> -        return;
>> -
>>       if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
>>           amd_vpmu_unset_msr_bitmap(v);
>>   
>> diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
>> index 68b6272..590c2a9 100644
>> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
>> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
>> @@ -818,8 +818,6 @@ 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 ( cpu_has_vmx_msr_bitmap )
>> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
>> index 1df74c2..7cc95ae 100644
>> --- a/xen/arch/x86/hvm/vpmu.c
>> +++ b/xen/arch/x86/hvm/vpmu.c
>> @@ -250,6 +250,13 @@ void vpmu_initialise(struct vcpu *v)
>>   void vpmu_destroy(struct vcpu *v)
>>   {
>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>> +    struct vcpu **last = &per_cpu(last_vcpu, vpmu->last_pcpu);
>> +
>> +    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
>> +        return;
>> +
> Could this just be:
>
> 	(void)cmpxchg(&per_cpu(last_vcpu, vpmu->last_pcpu), v, NULL);
>
> so that we don't do the 'per_cpu' access in case we return because
> VPMU_CONTEXT_ALLOCATED is not set?


Ugh. This is actually what I meant to send but I forgot to refresh the 
patch.

Do you want me to re-send it?

-boris


>
> Either way,
>
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> Thank you for spotting this.
>> +    /* Need to clear last_vcpu in case it points to v */
>> +    (void)cmpxchg(last, v, NULL);
>>   
>>       if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>>           vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>> -- 
>> 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 Wed Dec 17 17:11:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17:11:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1I7g-0003Du-H8; Wed, 17 Dec 2014 17:10:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1Y1I7f-0003Dp-VE
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 17:10:52 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	B6/56-14214-B19B1945; Wed, 17 Dec 2014 17:10:51 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418836250!13935552!1
X-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 3523 invoked from network); 17 Dec 2014 17:10:50 -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; 17 Dec 2014 17:10:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 17:10:49 +0000
Message-Id: <5491B91802000078000C40B1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 17:10:48 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-4-git-send-email-julien.grall@linaro.org>
	<5491636F020000780005027B@mail.emea.novell.com>
	<54917D1C.3080908@linaro.org>
In-Reply-To: <54917D1C.3080908@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE
	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

>>> Julien Grall <julien.grall@linaro.org> 12/17/14 1:55 PM >>>
>On 17/12/14 10:05, Jan Beulich wrote:
>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>>> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
>> 
>> Any reason not to simply use {read,write}_atomic() instead, which we
>> already have?
>
>To avoid modifying Linux drivers when it's not necessary and doesn't harm.

I realize that's the motivation, but I also view it as problematic to have two
different constructs doing the same thing. Defining the new one in terms of
the existing ones doesn't seem possible (or else I would suggest that in
order for the connection to be obvious). We'll see what other maintainers
think...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 17:11:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17:11:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1I7g-0003Du-H8; Wed, 17 Dec 2014 17:10:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1Y1I7f-0003Dp-VE
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 17:10:52 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	B6/56-14214-B19B1945; Wed, 17 Dec 2014 17:10:51 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418836250!13935552!1
X-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 3523 invoked from network); 17 Dec 2014 17:10:50 -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; 17 Dec 2014 17:10:50 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 17:10:49 +0000
Message-Id: <5491B91802000078000C40B1@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 17:10:48 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-4-git-send-email-julien.grall@linaro.org>
	<5491636F020000780005027B@mail.emea.novell.com>
	<54917D1C.3080908@linaro.org>
In-Reply-To: <54917D1C.3080908@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE
	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

>>> Julien Grall <julien.grall@linaro.org> 12/17/14 1:55 PM >>>
>On 17/12/14 10:05, Jan Beulich wrote:
>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>>> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
>> 
>> Any reason not to simply use {read,write}_atomic() instead, which we
>> already have?
>
>To avoid modifying Linux drivers when it's not necessary and doesn't harm.

I realize that's the motivation, but I also view it as problematic to have two
different constructs doing the same thing. Defining the new one in terms of
the existing ones doesn't seem possible (or else I would suggest that in
order for the connection to be obvious). We'll see what other maintainers
think...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 17:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1IDG-0003eC-BB; Wed, 17 Dec 2014 17:16:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y1IDF-0003e7-2J
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 17:16:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	45/54-15461-47AB1945; Wed, 17 Dec 2014 17:16:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418836594!16267580!1
X-Originating-IP: [156.151.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 26994 invoked from network); 17 Dec 2014 17:16:35 -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; 17 Dec 2014 17:16: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 sBHHGWdT030623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 17:16:33 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
	sBHHGWMJ022276
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 17:16:32 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
	sBHHGVOP022269; Wed, 17 Dec 2014 17:16:31 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 09:16:31 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id CFB29125313; Wed, 17 Dec 2014 12:16:31 -0500 (EST)
Date: Wed, 17 Dec 2014 12:16:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141217171631.GC8142@laptop.dumpdata.com>
References: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141217162115.GD6414@laptop.dumpdata.com>
	<5491B515.9060803@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5491B515.9060803@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 17, 2014 at 11:53:41AM -0500, Boris Ostrovsky wrote:
> On 12/17/2014 11:21 AM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Dec 17, 2014 at 10:35:47AM -0500, Boris Ostrovsky wrote:
> >>We need to make sure that last_vcpu is not pointing to VCPU whose
> >>VPMU is being destroyed. Otherwise we may try to dereference it in
> >>the future, when VCPU is gone.
> >>
> >>We have to do this atomically since otherwise there is a (somewhat
> >>theoretical) chance that between test and subsequent clearing
> >>of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
> >>both vpmu_load() and then vpmu_save() for another VCPU. The former
> >>will clear last_vcpu and the latter will set it to something else.
> >>
> >>We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
> >>avoid unnecessary cmpxchg() and arch-specific destroy ops. Thus
> >>checks in AMD and Intel routines are no longer needed.
> >>
> >>Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> >>---
> >>  xen/arch/x86/hvm/svm/vpmu.c       |    3 ---
> >>  xen/arch/x86/hvm/vmx/vpmu_core2.c |    2 --
> >>  xen/arch/x86/hvm/vpmu.c           |    7 +++++++
> >>  3 files changed, 7 insertions(+), 5 deletions(-)
> >>
> >>Changes in v3:
> >>  * Use cmpxchg instead of IPI
> >>  * Use correct routine nemas in commit message
> >>  * Remove duplicate test for VPMU_CONTEXT_ALLOCATED in arch-specific
> >>    destroy ops
> >>
> >>Changes in v2:
> >>  * Test last_vcpu locally before IPI
> >>  * Don't handle local pcpu as a special case --- on_selected_cpus
> >>    will take care of that
> >>  * Dont't cast variables unnecessarily
> >>
> >>diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
> >>index 8e07a98..4c448bb 100644
> >>--- a/xen/arch/x86/hvm/svm/vpmu.c
> >>+++ b/xen/arch/x86/hvm/svm/vpmu.c
> >>@@ -403,9 +403,6 @@ static void amd_vpmu_destroy(struct vcpu *v)
> >>  {
> >>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
> >>-    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> >>-        return;
> >>-
> >>      if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
> >>          amd_vpmu_unset_msr_bitmap(v);
> >>diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> >>index 68b6272..590c2a9 100644
> >>--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> >>+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> >>@@ -818,8 +818,6 @@ 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 ( cpu_has_vmx_msr_bitmap )
> >>diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
> >>index 1df74c2..7cc95ae 100644
> >>--- a/xen/arch/x86/hvm/vpmu.c
> >>+++ b/xen/arch/x86/hvm/vpmu.c
> >>@@ -250,6 +250,13 @@ void vpmu_initialise(struct vcpu *v)
> >>  void vpmu_destroy(struct vcpu *v)
> >>  {
> >>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
> >>+    struct vcpu **last = &per_cpu(last_vcpu, vpmu->last_pcpu);
> >>+
> >>+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> >>+        return;
> >>+
> >Could this just be:
> >
> >	(void)cmpxchg(&per_cpu(last_vcpu, vpmu->last_pcpu), v, NULL);
> >
> >so that we don't do the 'per_cpu' access in case we return because
> >VPMU_CONTEXT_ALLOCATED is not set?
> 
> 
> Ugh. This is actually what I meant to send but I forgot to refresh the
> patch.
> 
> Do you want me to re-send it?

Never hurts. I would just respond to this email with the patch as attachment
and inline for easier commit.
> 
> -boris
> 
> 
> >
> >Either way,
> >
> >Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >
> >Thank you for spotting this.
> >>+    /* Need to clear last_vcpu in case it points to v */
> >>+    (void)cmpxchg(last, v, NULL);
> >>      if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
> >>          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
> >>-- 
> >>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 Wed Dec 17 17:16:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1IDG-0003eC-BB; Wed, 17 Dec 2014 17:16:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y1IDF-0003e7-2J
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 17:16:37 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	45/54-15461-47AB1945; Wed, 17 Dec 2014 17:16:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418836594!16267580!1
X-Originating-IP: [156.151.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 26994 invoked from network); 17 Dec 2014 17:16:35 -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; 17 Dec 2014 17:16: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 sBHHGWdT030623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 17:16:33 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
	sBHHGWMJ022276
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 17:16:32 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
	sBHHGVOP022269; Wed, 17 Dec 2014 17:16:31 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 09:16:31 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id CFB29125313; Wed, 17 Dec 2014 12:16:31 -0500 (EST)
Date: Wed, 17 Dec 2014 12:16:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20141217171631.GC8142@laptop.dumpdata.com>
References: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
	<20141217162115.GD6414@laptop.dumpdata.com>
	<5491B515.9060803@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5491B515.9060803@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 17, 2014 at 11:53:41AM -0500, Boris Ostrovsky wrote:
> On 12/17/2014 11:21 AM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Dec 17, 2014 at 10:35:47AM -0500, Boris Ostrovsky wrote:
> >>We need to make sure that last_vcpu is not pointing to VCPU whose
> >>VPMU is being destroyed. Otherwise we may try to dereference it in
> >>the future, when VCPU is gone.
> >>
> >>We have to do this atomically since otherwise there is a (somewhat
> >>theoretical) chance that between test and subsequent clearing
> >>of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
> >>both vpmu_load() and then vpmu_save() for another VCPU. The former
> >>will clear last_vcpu and the latter will set it to something else.
> >>
> >>We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
> >>avoid unnecessary cmpxchg() and arch-specific destroy ops. Thus
> >>checks in AMD and Intel routines are no longer needed.
> >>
> >>Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> >>---
> >>  xen/arch/x86/hvm/svm/vpmu.c       |    3 ---
> >>  xen/arch/x86/hvm/vmx/vpmu_core2.c |    2 --
> >>  xen/arch/x86/hvm/vpmu.c           |    7 +++++++
> >>  3 files changed, 7 insertions(+), 5 deletions(-)
> >>
> >>Changes in v3:
> >>  * Use cmpxchg instead of IPI
> >>  * Use correct routine nemas in commit message
> >>  * Remove duplicate test for VPMU_CONTEXT_ALLOCATED in arch-specific
> >>    destroy ops
> >>
> >>Changes in v2:
> >>  * Test last_vcpu locally before IPI
> >>  * Don't handle local pcpu as a special case --- on_selected_cpus
> >>    will take care of that
> >>  * Dont't cast variables unnecessarily
> >>
> >>diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
> >>index 8e07a98..4c448bb 100644
> >>--- a/xen/arch/x86/hvm/svm/vpmu.c
> >>+++ b/xen/arch/x86/hvm/svm/vpmu.c
> >>@@ -403,9 +403,6 @@ static void amd_vpmu_destroy(struct vcpu *v)
> >>  {
> >>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
> >>-    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> >>-        return;
> >>-
> >>      if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
> >>          amd_vpmu_unset_msr_bitmap(v);
> >>diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> >>index 68b6272..590c2a9 100644
> >>--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> >>+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> >>@@ -818,8 +818,6 @@ 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 ( cpu_has_vmx_msr_bitmap )
> >>diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
> >>index 1df74c2..7cc95ae 100644
> >>--- a/xen/arch/x86/hvm/vpmu.c
> >>+++ b/xen/arch/x86/hvm/vpmu.c
> >>@@ -250,6 +250,13 @@ void vpmu_initialise(struct vcpu *v)
> >>  void vpmu_destroy(struct vcpu *v)
> >>  {
> >>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
> >>+    struct vcpu **last = &per_cpu(last_vcpu, vpmu->last_pcpu);
> >>+
> >>+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> >>+        return;
> >>+
> >Could this just be:
> >
> >	(void)cmpxchg(&per_cpu(last_vcpu, vpmu->last_pcpu), v, NULL);
> >
> >so that we don't do the 'per_cpu' access in case we return because
> >VPMU_CONTEXT_ALLOCATED is not set?
> 
> 
> Ugh. This is actually what I meant to send but I forgot to refresh the
> patch.
> 
> Do you want me to re-send it?

Never hurts. I would just respond to this email with the patch as attachment
and inline for easier commit.
> 
> -boris
> 
> 
> >
> >Either way,
> >
> >Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >
> >Thank you for spotting this.
> >>+    /* Need to clear last_vcpu in case it points to v */
> >>+    (void)cmpxchg(last, v, NULL);
> >>      if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
> >>          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
> >>-- 
> >>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 Wed Dec 17 17:17:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17: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 1Y1IEQ-0003iP-PZ; Wed, 17 Dec 2014 17:17: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 1Y1IEP-0003iH-AI
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 17:17:49 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	E1/66-07724-CBAB1945; Wed, 17 Dec 2014 17:17:48 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418836667!14039340!1
X-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 31689 invoked from network); 17 Dec 2014 17:17:48 -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; 17 Dec 2014 17:17:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 17:17:47 +0000
Message-Id: <5491BAB902000078000C40C6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 17:17:45 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
	<54915B3E.4010702@linaro.org>
	<54916CFA020000780005032F@mail.emea.novell.com>
	<54917F29.8070901@linaro.org>
In-Reply-To: <54917F29.8070901@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, manish.jaggi@caviumnetworks.com,
	tim@xen.org, stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe 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

>>> Julien Grall <julien.grall@linaro.org> 12/17/14 2:04 PM >>>
>On 17/12/14 10:46, Jan Beulich wrote:
>>>>> On 17.12.14 at 11:30, <julien.grall@linaro.org> wrote:
>>> Having a generic way to describe device will really help ARM code (see 
>>> IOMMU).
>>>
>>> If we don't have a such thing, we may need to duplicate quite a lots of 
>>> code. Which will make hard to maintain.
>> 
>> Not really, if e.g. "device" was simply an alias of "pci_dev" on x86.
>
>How many pci_dev instance you could have on a platform? 1000? Though it
>might be a high value but that mean we use 2k more of RAM.

Sure the total amount isn't big. But these days everyone thinks that way, and
data size gets grown without much consideration. And you shouldn't just think
about RAM cache utilization.

>It doesn't seem to bad for the benefit to have a clear code.

Aliasing device and pci_dev for x86 would yield similar clarity afaict.

>>>>> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
>>>>> +
>>>>> +static inline struct pci_dev *dev_to_pci(struct device *dev)
>>>>> +{
>>>>> +    ASSERT(dev->type == DEV_PCI);
>>>>> +
>>>>> +    return container_of(dev, struct pci_dev, dev);
>>>>> +}
>>>>
>>>> While the former is const-correct, I dislike the inability of passing
>>>> pointers to const into helper functions like the latter. I can't think
>>>> of a good solution other than introducing a second const variant
>>>> of it, but I suppose we should try to find alternatives before
>>>> adding such a construct that moves us in a direction opposite to
>>>> getting our code more const-correct.
>>>
>>> Oh right. I didn't though about that case. I will turn this inline 
>>> function into a macro.
>> 
>> I'm afraid that won't help, as you still need to specify a type as
>> 2nd argument to container_of(), and that type can't be both
>> const and non-const at the same time, i.e. you can't easily
>> inherit the const-ness of the passed in pointer.
>
>I agree that we will drop the const-ness. But is it really an issue?
>
>We won't have many place where we don't want to modify the pci_dev.

Did you check (including places where const could be added)? But at least
you didn't have to drop and const-s, so I'm not heavily objecting the change
you propose.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 17:17:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17: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 1Y1IEQ-0003iP-PZ; Wed, 17 Dec 2014 17:17: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 1Y1IEP-0003iH-AI
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 17:17:49 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	E1/66-07724-CBAB1945; Wed, 17 Dec 2014 17:17:48 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418836667!14039340!1
X-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 31689 invoked from network); 17 Dec 2014 17:17:48 -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; 17 Dec 2014 17:17:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 17:17:47 +0000
Message-Id: <5491BAB902000078000C40C6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 17:17:45 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
	<54915B3E.4010702@linaro.org>
	<54916CFA020000780005032F@mail.emea.novell.com>
	<54917F29.8070901@linaro.org>
In-Reply-To: <54917F29.8070901@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, manish.jaggi@caviumnetworks.com,
	tim@xen.org, stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe 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

>>> Julien Grall <julien.grall@linaro.org> 12/17/14 2:04 PM >>>
>On 17/12/14 10:46, Jan Beulich wrote:
>>>>> On 17.12.14 at 11:30, <julien.grall@linaro.org> wrote:
>>> Having a generic way to describe device will really help ARM code (see 
>>> IOMMU).
>>>
>>> If we don't have a such thing, we may need to duplicate quite a lots of 
>>> code. Which will make hard to maintain.
>> 
>> Not really, if e.g. "device" was simply an alias of "pci_dev" on x86.
>
>How many pci_dev instance you could have on a platform? 1000? Though it
>might be a high value but that mean we use 2k more of RAM.

Sure the total amount isn't big. But these days everyone thinks that way, and
data size gets grown without much consideration. And you shouldn't just think
about RAM cache utilization.

>It doesn't seem to bad for the benefit to have a clear code.

Aliasing device and pci_dev for x86 would yield similar clarity afaict.

>>>>> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
>>>>> +
>>>>> +static inline struct pci_dev *dev_to_pci(struct device *dev)
>>>>> +{
>>>>> +    ASSERT(dev->type == DEV_PCI);
>>>>> +
>>>>> +    return container_of(dev, struct pci_dev, dev);
>>>>> +}
>>>>
>>>> While the former is const-correct, I dislike the inability of passing
>>>> pointers to const into helper functions like the latter. I can't think
>>>> of a good solution other than introducing a second const variant
>>>> of it, but I suppose we should try to find alternatives before
>>>> adding such a construct that moves us in a direction opposite to
>>>> getting our code more const-correct.
>>>
>>> Oh right. I didn't though about that case. I will turn this inline 
>>> function into a macro.
>> 
>> I'm afraid that won't help, as you still need to specify a type as
>> 2nd argument to container_of(), and that type can't be both
>> const and non-const at the same time, i.e. you can't easily
>> inherit the const-ness of the passed in pointer.
>
>I agree that we will drop the const-ness. But is it really an issue?
>
>We won't have many place where we don't want to modify the pci_dev.

Did you check (including places where const could be added)? But at least
you didn't have to drop and const-s, so I'm not heavily objecting the change
you propose.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 17:28:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17:28:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1IOD-0004C3-WE; Wed, 17 Dec 2014 17:27: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 1Y1IOB-0004By-SD
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 17:27:56 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	8A/10-02957-B1DB1945; Wed, 17 Dec 2014 17:27:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418837273!15712570!1
X-Originating-IP: [66.165.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 14278 invoked from network); 17 Dec 2014 17:27:54 -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;
	17 Dec 2014 17:27:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,595,1413244800"; d="scan'208";a="205430964"
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.210.2; Wed, 17 Dec 2014 12:17: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 1Y1IE7-0007uL-Ac;
	Wed, 17 Dec 2014 17:17:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1IE7-000776-4d;
	Wed, 17 Dec 2014 17:17:31 +0000
Date: Wed, 17 Dec 2014 17:17:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32423-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] 32423: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32423 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32423/

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  7 debian-hvm-install  fail pass in 32390
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot   fail in 32390 pass in 32423

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
 build-amd64-rumpuserxen     3 host-install(3) broken in 32390 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)      blocked in 32390 n/a

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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-amd64-xl-pvh-amd                                  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                         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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34178 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 Dec 17 17:28:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17:28:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1IOD-0004C3-WE; Wed, 17 Dec 2014 17:27: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 1Y1IOB-0004By-SD
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 17:27:56 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	8A/10-02957-B1DB1945; Wed, 17 Dec 2014 17:27:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418837273!15712570!1
X-Originating-IP: [66.165.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 14278 invoked from network); 17 Dec 2014 17:27:54 -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;
	17 Dec 2014 17:27:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,595,1413244800"; d="scan'208";a="205430964"
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.210.2; Wed, 17 Dec 2014 12:17: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 1Y1IE7-0007uL-Ac;
	Wed, 17 Dec 2014 17:17:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1IE7-000776-4d;
	Wed, 17 Dec 2014 17:17:31 +0000
Date: Wed, 17 Dec 2014 17:17:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32423-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] 32423: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32423 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32423/

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  7 debian-hvm-install  fail pass in 32390
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot   fail in 32390 pass in 32423

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
 build-amd64-rumpuserxen     3 host-install(3) broken in 32390 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)      blocked in 32390 n/a

version targeted for testing:
 linux                2f9ac85b35cce77eb36e415f8f7a36aefb7d977d
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
797 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-amd64-xl-pvh-amd                                  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                         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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34178 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 Dec 17 17:28:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17:28:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1IOo-0004EL-DH; Wed, 17 Dec 2014 17:28: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 1Y1IOn-0004EG-OT
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 17:28:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	38/65-09842-14DB1945; Wed, 17 Dec 2014 17:28:33 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418837312!16310128!1
X-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 25575 invoked from network); 17 Dec 2014 17:28:32 -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; 17 Dec 2014 17:28:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 17:28:31 +0000
Message-Id: <5491BD3D02000078000C40D3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 17:28:29 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <boris.ostrovsky@oracle.com>
References: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830547-2218-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 v3] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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> 12/17/14 4:10 PM >>>
>+    /* Need to clear last_vcpu in case it points to v */
>+    (void)cmpxchg(last, v, NULL);
 
In a (later) reply to v2 I had indicated that it doesn't seem safe to so here but
rely on an IPI in the other path altering that value. Can you explain why you
think this is safe without changing the others to CPU-atomic accesses too?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 17:28:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17:28:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1IOo-0004EL-DH; Wed, 17 Dec 2014 17:28: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 1Y1IOn-0004EG-OT
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 17:28:33 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	38/65-09842-14DB1945; Wed, 17 Dec 2014 17:28:33 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418837312!16310128!1
X-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 25575 invoked from network); 17 Dec 2014 17:28:32 -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; 17 Dec 2014 17:28:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 17:28:31 +0000
Message-Id: <5491BD3D02000078000C40D3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 17:28:29 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <boris.ostrovsky@oracle.com>
References: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830547-2218-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 v3] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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> 12/17/14 4:10 PM >>>
>+    /* Need to clear last_vcpu in case it points to v */
>+    (void)cmpxchg(last, v, NULL);
 
In a (later) reply to v2 I had indicated that it doesn't seem safe to so here but
rely on an IPI in the other path altering that value. Can you explain why you
think this is safe without changing the others to CPU-atomic accesses too?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 17:29:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17: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 1Y1IQ6-0004Li-UF; Wed, 17 Dec 2014 17:29:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.sivertsen@gmail.com>) id 1Y1INj-0004Be-Pp
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 17:27:27 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	A4/FB-02699-FFCB1945; Wed, 17 Dec 2014 17:27:27 +0000
X-Env-Sender: julian.sivertsen@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418837246!11095632!1
X-Originating-IP: [209.85.212.170]
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 7004 invoked from network); 17 Dec 2014 17:27:26 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 17:27:26 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so17738100wib.5
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 09:27:26 -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=LAff6mvkV2VCMi8dk6JCAvEx9gVANX1l6Vh5LQG8cgA=;
	b=TvWvZTVGHYUOqRouk2Z2jh2hhe2I3/6LIuiIIOmLIQ2zFMrIdc3gE4d2omGRe/rMLV
	umCrfTMAausQ7tYCVRR2z/SPmJ7QuHp/dLC0tTn57yjjeTP4gEyFVC+n196FNl6d6tQO
	6FJMR5ygyRGzR3VjLX4FmjYElF+uDY6aSNMSK7SaKeeTT2avOh7kyuVpvpCb/CkBVuAR
	/n/MxL5PNjMd/sbTOtjTzBzLqrZ86+tdl6Mt+w2R2DhwDN+CWDsAvIGAkr4hMjCgJYJF
	08UcFfQTGuNxWjRco0jClcx00QGtN/58RSjuHcRMxDZpviRNX0DCSLcXCfz5fBwlKr1H
	gFZA==
MIME-Version: 1.0
X-Received: by 10.180.88.165 with SMTP id bh5mr16563053wib.77.1418837246342;
	Wed, 17 Dec 2014 09:27:26 -0800 (PST)
Received: by 10.194.23.66 with HTTP; Wed, 17 Dec 2014 09:27:26 -0800 (PST)
In-Reply-To: <20141217080219.GA2332@aepfle.de>
References: <CAKGZkHt7b-=1ApG0BrETU2NMAmWnHBmh=EZeJCzoZ8aTtgeDBA@mail.gmail.com>
	<20141217080219.GA2332@aepfle.de>
Date: Wed, 17 Dec 2014 18:27:26 +0100
Message-ID: <CAKGZkHs8r3kncMgnQSPpOocrqD=3m5rN_0UKWN5yYu-U634PoQ@mail.gmail.com>
From: Julian Sivertsen <julian.sivertsen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
X-Mailman-Approved-At: Wed, 17 Dec 2014 17:29:53 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Packaging xen 4.5.0 RC4 on Arch Linux
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2014-12-17 9:02 GMT+01:00 Olaf Hering <olaf@aepfle.de>:
> See the INSTALL file in the toplevel directory.

I can't believe I didn't see that file, makes me feel rather dumb. Thank you so
much for the pointer, it clears up a lot of things.


Julian Sivertsen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 17:29:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17: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 1Y1IQ6-0004Li-UF; Wed, 17 Dec 2014 17:29:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.sivertsen@gmail.com>) id 1Y1INj-0004Be-Pp
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 17:27:27 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	A4/FB-02699-FFCB1945; Wed, 17 Dec 2014 17:27:27 +0000
X-Env-Sender: julian.sivertsen@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418837246!11095632!1
X-Originating-IP: [209.85.212.170]
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 7004 invoked from network); 17 Dec 2014 17:27:26 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 17:27:26 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so17738100wib.5
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 09:27:26 -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=LAff6mvkV2VCMi8dk6JCAvEx9gVANX1l6Vh5LQG8cgA=;
	b=TvWvZTVGHYUOqRouk2Z2jh2hhe2I3/6LIuiIIOmLIQ2zFMrIdc3gE4d2omGRe/rMLV
	umCrfTMAausQ7tYCVRR2z/SPmJ7QuHp/dLC0tTn57yjjeTP4gEyFVC+n196FNl6d6tQO
	6FJMR5ygyRGzR3VjLX4FmjYElF+uDY6aSNMSK7SaKeeTT2avOh7kyuVpvpCb/CkBVuAR
	/n/MxL5PNjMd/sbTOtjTzBzLqrZ86+tdl6Mt+w2R2DhwDN+CWDsAvIGAkr4hMjCgJYJF
	08UcFfQTGuNxWjRco0jClcx00QGtN/58RSjuHcRMxDZpviRNX0DCSLcXCfz5fBwlKr1H
	gFZA==
MIME-Version: 1.0
X-Received: by 10.180.88.165 with SMTP id bh5mr16563053wib.77.1418837246342;
	Wed, 17 Dec 2014 09:27:26 -0800 (PST)
Received: by 10.194.23.66 with HTTP; Wed, 17 Dec 2014 09:27:26 -0800 (PST)
In-Reply-To: <20141217080219.GA2332@aepfle.de>
References: <CAKGZkHt7b-=1ApG0BrETU2NMAmWnHBmh=EZeJCzoZ8aTtgeDBA@mail.gmail.com>
	<20141217080219.GA2332@aepfle.de>
Date: Wed, 17 Dec 2014 18:27:26 +0100
Message-ID: <CAKGZkHs8r3kncMgnQSPpOocrqD=3m5rN_0UKWN5yYu-U634PoQ@mail.gmail.com>
From: Julian Sivertsen <julian.sivertsen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
X-Mailman-Approved-At: Wed, 17 Dec 2014 17:29:53 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Packaging xen 4.5.0 RC4 on Arch Linux
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2014-12-17 9:02 GMT+01:00 Olaf Hering <olaf@aepfle.de>:
> See the INSTALL file in the toplevel directory.

I can't believe I didn't see that file, makes me feel rather dumb. Thank you so
much for the pointer, it clears up a lot of things.


Julian Sivertsen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 17:53:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17: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 1Y1ImK-0005R7-L7; Wed, 17 Dec 2014 17:52:52 +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 1Y1ImJ-0005R2-HM
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 17:52:51 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	81/A2-25547-2F2C1945; Wed, 17 Dec 2014 17:52:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418838768!14117913!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11235 invoked from network); 17 Dec 2014 17:52:50 -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;
	17 Dec 2014 17:52:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,595,1413244800"; d="scan'208";a="205917482"
Message-ID: <5491C2EE.4080603@citrix.com>
Date: Wed, 17 Dec 2014 17:52: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>, <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>	<1418760534-18163-4-git-send-email-julien.grall@linaro.org>	<5491636F020000780005027B@mail.emea.novell.com>	<54917D1C.3080908@linaro.org>
	<5491B91802000078000C40B1@mail.emea.novell.com>
In-Reply-To: <5491B91802000078000C40B1@mail.emea.novell.com>
X-DLP: MIA2
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE
 macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/12/14 17:10, Jan Beulich wrote:
>>>> Julien Grall <julien.grall@linaro.org> 12/17/14 1:55 PM >>>
>> On 17/12/14 10:05, Jan Beulich wrote:
>>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>>>> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
>>> Any reason not to simply use {read,write}_atomic() instead, which we
>>> already have?
>> To avoid modifying Linux drivers when it's not necessary and doesn't harm.
> I realize that's the motivation, but I also view it as problematic to have two
> different constructs doing the same thing. Defining the new one in terms of
> the existing ones doesn't seem possible (or else I would suggest that in
> order for the connection to be obvious). We'll see what other maintainers
> think...

Personally, I find the semantics of ACCESS_ONCE() more intuitive than
read/write_atomic(), and it is certainly more familiar to Linux developers.

Furthermore, ACCESS_ONCE() doesn't force an mov instruction if the
compiler can identify a better instruction to use.

There are only a handful of user users of read/write_atomic().  It would
not be hard to make a blanket switch, if we chose to go in that direction.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 17:53:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17: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 1Y1ImK-0005R7-L7; Wed, 17 Dec 2014 17:52:52 +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 1Y1ImJ-0005R2-HM
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 17:52:51 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	81/A2-25547-2F2C1945; Wed, 17 Dec 2014 17:52:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418838768!14117913!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11235 invoked from network); 17 Dec 2014 17:52:50 -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;
	17 Dec 2014 17:52:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,595,1413244800"; d="scan'208";a="205917482"
Message-ID: <5491C2EE.4080603@citrix.com>
Date: Wed, 17 Dec 2014 17:52: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>, <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>	<1418760534-18163-4-git-send-email-julien.grall@linaro.org>	<5491636F020000780005027B@mail.emea.novell.com>	<54917D1C.3080908@linaro.org>
	<5491B91802000078000C40B1@mail.emea.novell.com>
In-Reply-To: <5491B91802000078000C40B1@mail.emea.novell.com>
X-DLP: MIA2
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE
 macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/12/14 17:10, Jan Beulich wrote:
>>>> Julien Grall <julien.grall@linaro.org> 12/17/14 1:55 PM >>>
>> On 17/12/14 10:05, Jan Beulich wrote:
>>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>>>> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
>>> Any reason not to simply use {read,write}_atomic() instead, which we
>>> already have?
>> To avoid modifying Linux drivers when it's not necessary and doesn't harm.
> I realize that's the motivation, but I also view it as problematic to have two
> different constructs doing the same thing. Defining the new one in terms of
> the existing ones doesn't seem possible (or else I would suggest that in
> order for the connection to be obvious). We'll see what other maintainers
> think...

Personally, I find the semantics of ACCESS_ONCE() more intuitive than
read/write_atomic(), and it is certainly more familiar to Linux developers.

Furthermore, ACCESS_ONCE() doesn't force an mov instruction if the
compiler can identify a better instruction to use.

There are only a handful of user users of read/write_atomic().  It would
not be hard to make a blanket switch, if we chose to go in that direction.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 17:55:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17: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 1Y1Ioq-0005ao-8F; Wed, 17 Dec 2014 17:55:28 +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 1Y1Ioo-0005aE-8d
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 17:55:26 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0C/20-09842-D83C1945; Wed, 17 Dec 2014 17:55:25 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418838923!8275674!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6707 invoked from network); 17 Dec 2014 17:55:24 -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; 17 Dec 2014 17:55: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 sBHHtMsY012685
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 17:55:23 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
	sBHHtL5V003978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Dec 2014 17:55:22 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
	sBHHtKmA019365; Wed, 17 Dec 2014 17:55:21 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 ; Wed, 17 Dec 2014 09:55:20 -0800
Message-ID: <5491C402.80201@oracle.com>
Date: Wed, 17 Dec 2014 12:57:22 -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: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
	<5491BD3D02000078000C40D3@mail.emea.novell.com>
In-Reply-To: <5491BD3D02000078000C40D3@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 v3] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/17/2014 12:28 PM, Jan Beulich wrote:
>>>> Boris Ostrovsky <boris.ostrovsky@oracle.com> 12/17/14 4:10 PM >>>
>> +    /* Need to clear last_vcpu in case it points to v */
>> +    (void)cmpxchg(last, v, NULL);
>   
> In a (later) reply to v2 I had indicated that it doesn't seem safe to so here but
> rely on an IPI in the other path altering that value. Can you explain why you
> think this is safe without changing the others to CPU-atomic accesses too?


So the local access to last_vcpu in vpmu_load() may be still raced on (I 
was thinking that access in vpmu_load() would on the same processor as 
vpmu_destroy(), which is obviously not the case).

So I will have to go back to IPI (I don't want to use cmpxchg in 
vpmu_load()).

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 17:55:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 17: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 1Y1Ioq-0005ao-8F; Wed, 17 Dec 2014 17:55:28 +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 1Y1Ioo-0005aE-8d
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 17:55:26 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	0C/20-09842-D83C1945; Wed, 17 Dec 2014 17:55:25 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418838923!8275674!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6707 invoked from network); 17 Dec 2014 17:55:24 -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; 17 Dec 2014 17:55: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 sBHHtMsY012685
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 17:55:23 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
	sBHHtL5V003978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Dec 2014 17:55:22 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
	sBHHtKmA019365; Wed, 17 Dec 2014 17:55:21 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 ; Wed, 17 Dec 2014 09:55:20 -0800
Message-ID: <5491C402.80201@oracle.com>
Date: Wed, 17 Dec 2014 12:57:22 -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: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com>
	<5491BD3D02000078000C40D3@mail.emea.novell.com>
In-Reply-To: <5491BD3D02000078000C40D3@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 v3] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/17/2014 12:28 PM, Jan Beulich wrote:
>>>> Boris Ostrovsky <boris.ostrovsky@oracle.com> 12/17/14 4:10 PM >>>
>> +    /* Need to clear last_vcpu in case it points to v */
>> +    (void)cmpxchg(last, v, NULL);
>   
> In a (later) reply to v2 I had indicated that it doesn't seem safe to so here but
> rely on an IPI in the other path altering that value. Can you explain why you
> think this is safe without changing the others to CPU-atomic accesses too?


So the local access to last_vcpu in vpmu_load() may be still raced on (I 
was thinking that access in vpmu_load() would on the same processor as 
vpmu_destroy(), which is obviously not the case).

So I will have to go back to IPI (I don't want to use cmpxchg in 
vpmu_load()).

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 18:55:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 18: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 1Y1Jk2-0007Zv-5c; Wed, 17 Dec 2014 18:54:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y1Jk0-0007Zq-Mn
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 18:54:32 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	57/D3-22777-761D1945; Wed, 17 Dec 2014 18:54:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418842469!8548556!1
X-Originating-IP: [66.165.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 18858 invoked from network); 17 Dec 2014 18:54:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 18:54:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,595,1413244800"; d="scan'208";a="205946520"
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.210.2; Wed, 17 Dec 2014 13:54: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 1Y1Jjv-0008Mo-Rg;
	Wed, 17 Dec 2014 18:54:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1Jjv-0006mg-MU;
	Wed, 17 Dec 2014 18:54:27 +0000
Date: Wed, 17 Dec 2014 18:54:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32425-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] 32425: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32425 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32425/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32149

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair  18 guest-migrate/dst_host/src_host fail blocked in 32149

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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-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                83a926f7a4e39fb6be0576024e67fe161593defa
baseline version:
 linux                356a3e1fde11190febb8ace3cdab8694848ed220

------------------------------------------------------------
People who touched revisions under test:
  Aaro Koskinen <aaro.koskinen@iki.fi>
  Aaron Brown <aaron.f.brown@intel.com>
  Alex Deucher <alexander.deucher@amd.com>
  Alexander Kochetkov <al.kochet@gmail.com>
  Alexey Orishko <alexey.orishko@gmail.com>
  Andrew Morton <akpm@linux-foundation.org>
  Anton Blanchard <anton@samba.org>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Borislav Petkov <bp@suse.de>
  Chris Clayton <chris2553@googlemail.com>
  Clemens Ladisch <clemens@ladisch.de>
  Cong Wang <cwang@twopensource.com>
  Daniel Borkmann <dborkman@redhat.com>
  Daniel Forrest <dan.forrest@ssec.wisc.edu>
  Daniel Vetter <daniel.vetter@ffwll.ch>
  Daniel Vetter <daniel.vetter@intel.com>
  David S. Miller <davem@davemloft.net>
  Devin Ryles <devin.ryles@intel.com>
  Dmitry Torokhov <dtor@chromium.org>
  Eric Dumazet <edumazet@google.com>
  Felipe Balbi <balbi@ti.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Grygorii Strashko <grygorii.strashko@ti.com>
  Hugh Dickins <hughd@google.com>
  Ingo Molnar <mingo@kernel.org>
  Jack Morgenstein <jackm@dev.mellanox.co.il>
  Jani Nikula <jani.nikula@intel.com>
  Jeff Kirsher <jeffrey.t.kirsher@intel.com>
  Johannes Berg <johannes.berg@intel.com>
  Kan Liang <kan.liang@intel.com>
  Kees Cook <keescook@chromium.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  lu hua <huax.lu@intel.com>
  lucien <lucien.xin@gmail.com>
  Maggie Mae Roxas <maggie.mae.roxas@gmail.com>
  Marcelo Leitner <mleitner@redhat.com>
  Marcelo Ricardo Leitner <mleitner@redhat.com>
  Mathias Nyman <mathias.nyman@linux.intel.com>
  Mauro Carvalho Chehab <mchehab@osg.samsung.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Neil Horman <nhorman@tuxdriver.com>
  Nicolas Dichtel <nicolas.dichtel@6wind.com>
  Or Gerlitz <ogerlitz@mellanox.com>
  Peter Zijlstra <peterz@infradead.org>
  Petr Mladek <pmladek@suse.cz>
  Ronald Wahl <ronald.wahl@raritan.com>
  Sakari Ailus <sakari.ailus@iki.fi>
  Seth Forshee <seth.forshee@canonical.com>
  Takashi Iwai <tiwai@suse.de>
  Tejun Heo <tj@kernel.org>
  Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
  Thomas Gleixner <tglx@linutronix.de>
  Todd Fujinaka <todd.fujinaka@intel.com>
  Tom Herbert <therbert@google.com>
  Vlad Yasevich <vyasevich@gmail.com>
  Weijie Yang <weijie.yang@samsung.com>
  Willy Tarreau <w@1wt.eu>
  Wolfram Sang <wsa@the-dreams.de>
  Xin Long <lucien.xin@gmail.com>
  Yuri Chislov <yuri.chislov@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    
 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-amd64-xl-pvh-amd                                  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                     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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 1050 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 Dec 17 18:55:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 18: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 1Y1Jk2-0007Zv-5c; Wed, 17 Dec 2014 18:54:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y1Jk0-0007Zq-Mn
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 18:54:32 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	57/D3-22777-761D1945; Wed, 17 Dec 2014 18:54:31 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418842469!8548556!1
X-Originating-IP: [66.165.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 18858 invoked from network); 17 Dec 2014 18:54:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 18:54:30 -0000
X-IronPort-AV: E=Sophos;i="5.07,595,1413244800"; d="scan'208";a="205946520"
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.210.2; Wed, 17 Dec 2014 13:54: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 1Y1Jjv-0008Mo-Rg;
	Wed, 17 Dec 2014 18:54:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1Jjv-0006mg-MU;
	Wed, 17 Dec 2014 18:54:27 +0000
Date: Wed, 17 Dec 2014 18:54:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32425-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] 32425: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32425 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32425/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot      fail REGR. vs. 32149

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair  18 guest-migrate/dst_host/src_host fail blocked in 32149

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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-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                83a926f7a4e39fb6be0576024e67fe161593defa
baseline version:
 linux                356a3e1fde11190febb8ace3cdab8694848ed220

------------------------------------------------------------
People who touched revisions under test:
  Aaro Koskinen <aaro.koskinen@iki.fi>
  Aaron Brown <aaron.f.brown@intel.com>
  Alex Deucher <alexander.deucher@amd.com>
  Alexander Kochetkov <al.kochet@gmail.com>
  Alexey Orishko <alexey.orishko@gmail.com>
  Andrew Morton <akpm@linux-foundation.org>
  Anton Blanchard <anton@samba.org>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Borislav Petkov <bp@suse.de>
  Chris Clayton <chris2553@googlemail.com>
  Clemens Ladisch <clemens@ladisch.de>
  Cong Wang <cwang@twopensource.com>
  Daniel Borkmann <dborkman@redhat.com>
  Daniel Forrest <dan.forrest@ssec.wisc.edu>
  Daniel Vetter <daniel.vetter@ffwll.ch>
  Daniel Vetter <daniel.vetter@intel.com>
  David S. Miller <davem@davemloft.net>
  Devin Ryles <devin.ryles@intel.com>
  Dmitry Torokhov <dtor@chromium.org>
  Eric Dumazet <edumazet@google.com>
  Felipe Balbi <balbi@ti.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Grygorii Strashko <grygorii.strashko@ti.com>
  Hugh Dickins <hughd@google.com>
  Ingo Molnar <mingo@kernel.org>
  Jack Morgenstein <jackm@dev.mellanox.co.il>
  Jani Nikula <jani.nikula@intel.com>
  Jeff Kirsher <jeffrey.t.kirsher@intel.com>
  Johannes Berg <johannes.berg@intel.com>
  Kan Liang <kan.liang@intel.com>
  Kees Cook <keescook@chromium.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  lu hua <huax.lu@intel.com>
  lucien <lucien.xin@gmail.com>
  Maggie Mae Roxas <maggie.mae.roxas@gmail.com>
  Marcelo Leitner <mleitner@redhat.com>
  Marcelo Ricardo Leitner <mleitner@redhat.com>
  Mathias Nyman <mathias.nyman@linux.intel.com>
  Mauro Carvalho Chehab <mchehab@osg.samsung.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Neil Horman <nhorman@tuxdriver.com>
  Nicolas Dichtel <nicolas.dichtel@6wind.com>
  Or Gerlitz <ogerlitz@mellanox.com>
  Peter Zijlstra <peterz@infradead.org>
  Petr Mladek <pmladek@suse.cz>
  Ronald Wahl <ronald.wahl@raritan.com>
  Sakari Ailus <sakari.ailus@iki.fi>
  Seth Forshee <seth.forshee@canonical.com>
  Takashi Iwai <tiwai@suse.de>
  Tejun Heo <tj@kernel.org>
  Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
  Thomas Gleixner <tglx@linutronix.de>
  Todd Fujinaka <todd.fujinaka@intel.com>
  Tom Herbert <therbert@google.com>
  Vlad Yasevich <vyasevich@gmail.com>
  Weijie Yang <weijie.yang@samsung.com>
  Willy Tarreau <w@1wt.eu>
  Wolfram Sang <wsa@the-dreams.de>
  Xin Long <lucien.xin@gmail.com>
  Yuri Chislov <yuri.chislov@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    
 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-amd64-xl-pvh-amd                                  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                     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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 1050 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 Dec 17 19:42:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 19: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 1Y1KTx-0000ZQ-DS; Wed, 17 Dec 2014 19:42:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y1KTv-0000ZL-Ql
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 19:41:59 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	2D/9C-18267-78CD1945; Wed, 17 Dec 2014 19:41:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418845317!11699463!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5578 invoked from network); 17 Dec 2014 19:41:58 -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; 17 Dec 2014 19:41: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 sBHJfrOV025302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 19:41:53 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
	sBHJfp05007775
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Dec 2014 19:41:52 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
	sBHJfok6001499; Wed, 17 Dec 2014 19:41:51 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 11:41:50 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E42361255A9; Wed, 17 Dec 2014 14:41:50 -0500 (EST)
Date: Wed, 17 Dec 2014 14:41:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141217194150.GD29130@laptop.dumpdata.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<20141216163451.GA18976@aepfle.de>
	<20141216204601.GA11551@konrad-lan.dumpdata.com>
	<20141217075510.GA678@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141217075510.GA678@aepfle.de>
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
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 17, 2014 at 08:55:10AM +0100, Olaf Hering wrote:
> On Tue, Dec 16, Konrad Rzeszutek Wilk wrote:
> 
> > On Tue, Dec 16, 2014 at 05:34:51PM +0100, Olaf Hering wrote:
> > > On Tue, Dec 16, konrad.wilk@oracle.com wrote:
> > > 
> > > > In terms of bugs, we have:
> > > 
> > > ... systemd SELinux, but its not listed.
> > 
> > > 
> > > Whats your plan with the failures you see? Should I continue to be
> > > concerned about that, or will all the be postponed to 4.6?
> > 
> > I was under the impression you had some patches which would solve a
> > majority of the issues? And after the discussion with Ian Jackson the
> > way to exec was solved?
> 
> No. What I did was to handle XENSTORED_TRACE which is just a bool to
> pass "-T /log/file" to xenstored. I think xenstored can not access the
> sockets if it was launched with a shell script as it is done now. 
> No idea how to solve that. Maybe "/usr/bin/env $XENSTORED" could be a
> workaround for the SELinux socket access issue. But perhaps launching it
> via env or sh fails either way.
> 
> > And for the other - the SELinux context and how to figure this out -
> > I thought (I will have to double-check it tomorrow) that I mentioned it might
> > make sense to talk to the SELinux maintainers to see if they have any
> > recommendation?
> 
> For xen-4.5 the easy way would be to remove the context= option and let
> people who build from source and who want to use SELinux put the
> required options into /etc/fstab. This would also resolve the issue
> Anthony is seeing, his mount or kernel does not understand context= at
> all. No idea how he got into that state in his Arch Linux installation.

And also remove the EnvionmentFile and such. Anyhow I've taken for 
spin these patches:

 tools/hotplug: add wrapper to start xenstored
 tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service
 tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service
 tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service
 tools/hotplug: xendomains.service depends on network
 tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service
 tools/hotplug: remove SELinux options from var-lib-xenstored.mount

from you  https://github.com/olafhering/xen.git staging-for-4.5.0

and they fixed the issues I saw. That is I can boot Fedora Core 21 with
the sources being built out (plus said patches above)
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 19:42:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 19: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 1Y1KTx-0000ZQ-DS; Wed, 17 Dec 2014 19:42:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y1KTv-0000ZL-Ql
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 19:41:59 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	2D/9C-18267-78CD1945; Wed, 17 Dec 2014 19:41:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1418845317!11699463!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5578 invoked from network); 17 Dec 2014 19:41:58 -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; 17 Dec 2014 19:41: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 sBHJfrOV025302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 19:41:53 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
	sBHJfp05007775
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Dec 2014 19:41:52 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
	sBHJfok6001499; Wed, 17 Dec 2014 19:41:51 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 11:41:50 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id E42361255A9; Wed, 17 Dec 2014 14:41:50 -0500 (EST)
Date: Wed, 17 Dec 2014 14:41:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141217194150.GD29130@laptop.dumpdata.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<20141216163451.GA18976@aepfle.de>
	<20141216204601.GA11551@konrad-lan.dumpdata.com>
	<20141217075510.GA678@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141217075510.GA678@aepfle.de>
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
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 17, 2014 at 08:55:10AM +0100, Olaf Hering wrote:
> On Tue, Dec 16, Konrad Rzeszutek Wilk wrote:
> 
> > On Tue, Dec 16, 2014 at 05:34:51PM +0100, Olaf Hering wrote:
> > > On Tue, Dec 16, konrad.wilk@oracle.com wrote:
> > > 
> > > > In terms of bugs, we have:
> > > 
> > > ... systemd SELinux, but its not listed.
> > 
> > > 
> > > Whats your plan with the failures you see? Should I continue to be
> > > concerned about that, or will all the be postponed to 4.6?
> > 
> > I was under the impression you had some patches which would solve a
> > majority of the issues? And after the discussion with Ian Jackson the
> > way to exec was solved?
> 
> No. What I did was to handle XENSTORED_TRACE which is just a bool to
> pass "-T /log/file" to xenstored. I think xenstored can not access the
> sockets if it was launched with a shell script as it is done now. 
> No idea how to solve that. Maybe "/usr/bin/env $XENSTORED" could be a
> workaround for the SELinux socket access issue. But perhaps launching it
> via env or sh fails either way.
> 
> > And for the other - the SELinux context and how to figure this out -
> > I thought (I will have to double-check it tomorrow) that I mentioned it might
> > make sense to talk to the SELinux maintainers to see if they have any
> > recommendation?
> 
> For xen-4.5 the easy way would be to remove the context= option and let
> people who build from source and who want to use SELinux put the
> required options into /etc/fstab. This would also resolve the issue
> Anthony is seeing, his mount or kernel does not understand context= at
> all. No idea how he got into that state in his Arch Linux installation.

And also remove the EnvionmentFile and such. Anyhow I've taken for 
spin these patches:

 tools/hotplug: add wrapper to start xenstored
 tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service
 tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service
 tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service
 tools/hotplug: xendomains.service depends on network
 tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service
 tools/hotplug: remove SELinux options from var-lib-xenstored.mount

from you  https://github.com/olafhering/xen.git staging-for-4.5.0

and they fixed the issues I saw. That is I can boot Fedora Core 21 with
the sources being built out (plus said patches above)
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 20:37:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 20: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 1Y1LKi-000228-JI; Wed, 17 Dec 2014 20:36:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1Y1LKg-000223-CU
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 20:36:30 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	A9/13-02957-D49E1945; Wed, 17 Dec 2014 20:36:29 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418848583!11122608!1
X-Originating-IP: [209.85.213.170]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9027 invoked from network); 17 Dec 2014 20:36:24 -0000
Received: from mail-ig0-f170.google.com (HELO mail-ig0-f170.google.com)
	(209.85.213.170)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 20:36:24 -0000
Received: by mail-ig0-f170.google.com with SMTP id r2so10134353igi.5
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 12:36:23 -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=vznsQQ7wvQkHmJqtuI2oMj8o0gZCq8H6xUZS+1NHmgo=;
	b=RLNxZoPfYJeM4qnuX+JFk1DMA8NXwHyoNNTkkzXcniLcjY2teJdhntht715p0nENed
	qkLnKL1lZWLXSEsAd1AedJRxn1OUqtAxBHQKdt60zoTMoqLQ28xH2RtqtAAZwlsRHoku
	yW3CL/ddwgTHQNNWO4tXSCURMgF9hsPZxf6gEWAhakPx2C3leeI3z6wS8opstwrPtAMG
	JtMnkPEkI4V4ye/47lI2BnrM+OQp0yWN7dCvA4g9M9WOkLl3ONy69nuOd1fK0W7Tkvhm
	wX4XIbIHCye+wJoMh+WgesRPIlEw2XZ37QWgMKBgnBKRhbEG0EPZJ1UAQgBtXecM8Vm4
	7u0A==
MIME-Version: 1.0
X-Received: by 10.107.138.5 with SMTP id m5mr23979554iod.85.1418848583389;
	Wed, 17 Dec 2014 12:36:23 -0800 (PST)
Received: by 10.64.81.7 with HTTP; Wed, 17 Dec 2014 12:36:23 -0800 (PST)
In-Reply-To: <1409674013-10321-1-git-send-email-david.vrabel@citrix.com>
References: <1409674013-10321-1-git-send-email-david.vrabel@citrix.com>
Date: Wed, 17 Dec 2014 15:36:23 -0500
X-Google-Sender-Auth: nHjBj1qfj7K4sn26p5Y-CMA1sK0
Message-ID: <CACJDEmo1NPoFE-RaO97GSyn8a2tYA3Fw5TncdXTs5GXczZi1mQ@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: David Vrabel <david.vrabel@citrix.com>, annie li <annie.li@oracle.com>, 
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, X86 <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Suresh Siddha <sbsiddha@gmail.com>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCHv3] x86,
 fpu: remove the logic of non-eager fpu mem allocation at the first
 usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5576680560440703727=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5576680560440703727==
Content-Type: multipart/alternative; boundary=001a113fa606cd9a31050a6f6d6c

--001a113fa606cd9a31050a6f6d6c
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 2, 2014 at 12:06 PM, David Vrabel <david.vrabel@citrix.com>
wrote:
>
> From: Suresh Siddha <sbsiddha@gmail.com>
>
> For non-eager fpu mode, thread's fpu state is allocated during the first
> fpu usage (in the context of device not available exception). This can be
> a blocking call and hence we enable interrupts (which were originally
> disabled when the exception happened), allocate memory and disable
> interrupts etc. While this saves 512 bytes or so per-thread, there
> are some issues in general.
>
> a.  Most of the future cases will be anyway using eager
> FPU (because of processor features like xsaveopt, LWP, MPX etc) and
> they do the allocation at the thread creation itself. Nice to have
> one common mechanism as all the state save/restore code is
> shared. Avoids the confusion and minimizes the subtle bugs
> in the core piece involved with context-switch.
>
> b. If a parent thread uses FPU, during fork() we allocate
> the FPU state in the child and copy the state etc. Shortly after this,
> during exec() we free it up, so that we can later allocate during
> the first usage of FPU. So this free/allocate might be slower
> for some workloads.
>
> c. math_state_restore() is called from multiple places
> and it is error pone if the caller expects interrupts to be disabled
> throughout the execution of math_state_restore(). Can lead to subtle
> bugs like Ubuntu bug #1265841.
>
> Memory savings will be small anyways and the code complexity
> introducing subtle bugs is not worth it. So remove
> the logic of non-eager fpu mem allocation at the first usage.
>


ping?

>
> Signed-off-by: Suresh Siddha <sbsiddha@gmail.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
> v3:
> - Rebase on 3.17-rc3.
>
> v2:
> - Tweak condition for allocating the first thread's FPU state.
> ---
>  arch/x86/kernel/i387.c    |   20 +++++++++++---------
>  arch/x86/kernel/process.c |    6 ------
>  arch/x86/kernel/traps.c   |   16 ++--------------
>  arch/x86/kernel/xsave.c   |    2 --
>  4 files changed, 13 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
> index a9a4229..956ea86 100644
> --- a/arch/x86/kernel/i387.c
> +++ b/arch/x86/kernel/i387.c
> @@ -5,6 +5,7 @@
>   *  General FPU state handling cleanups
>   *     Gareth Hughes <gareth@valinux.com>, May 2000
>   */
> +#include <linux/bootmem.h>
>  #include <linux/module.h>
>  #include <linux/regset.h>
>  #include <linux/sched.h>
> @@ -197,6 +198,16 @@ void fpu_init(void)
>
>         mxcsr_feature_mask_init();
>         xsave_init();
> +
> +       /*
> +        * Now we know the final size of the xsave data, allocate the
> +        * FPU state area for the first task. All other tasks have
> +        * this allocated in arch_dup_task_struct().
> +        */
> +       if (!current->thread.fpu.state)
> +               current->thread.fpu.state =
> alloc_bootmem_align(xstate_size,
> +                               __alignof__(struct xsave_struct));
> +
>         eager_fpu_init();
>  }
>
> @@ -228,8 +239,6 @@ EXPORT_SYMBOL_GPL(fpu_finit);
>   */
>  int init_fpu(struct task_struct *tsk)
>  {
> -       int ret;
> -
>         if (tsk_used_math(tsk)) {
>                 if (cpu_has_fpu && tsk == current)
>                         unlazy_fpu(tsk);
> @@ -237,13 +246,6 @@ int init_fpu(struct task_struct *tsk)
>                 return 0;
>         }
>
> -       /*
> -        * Memory allocation at the first usage of the FPU and other state.
> -        */
> -       ret = fpu_alloc(&tsk->thread.fpu);
> -       if (ret)
> -               return ret;
> -
>         fpu_finit(&tsk->thread.fpu);
>
>         set_stopped_child_used_math(tsk);
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index f804dc9..4137f81 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -129,12 +129,6 @@ void flush_thread(void)
>         flush_ptrace_hw_breakpoint(tsk);
>         memset(tsk->thread.tls_array, 0, sizeof(tsk->thread.tls_array));
>         drop_init_fpu(tsk);
> -       /*
> -        * Free the FPU state for non xsave platforms. They get reallocated
> -        * lazily at the first use.
> -        */
> -       if (!use_eager_fpu())
> -               free_thread_xstate(tsk);
>  }
>
>  static void hard_disable_TSC(void)
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 0d0e922..36fc898 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -652,20 +652,8 @@ void math_state_restore(void)
>  {
>         struct task_struct *tsk = current;
>
> -       if (!tsk_used_math(tsk)) {
> -               local_irq_enable();
> -               /*
> -                * does a slab alloc which can sleep
> -                */
> -               if (init_fpu(tsk)) {
> -                       /*
> -                        * ran out of memory!
> -                        */
> -                       do_group_exit(SIGKILL);
> -                       return;
> -               }
> -               local_irq_disable();
> -       }
> +       if (!tsk_used_math(tsk))
> +               init_fpu(tsk);
>
>         __thread_fpu_begin(tsk);
>
> diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c
> index 940b142..eed95d6 100644
> --- a/arch/x86/kernel/xsave.c
> +++ b/arch/x86/kernel/xsave.c
> @@ -677,8 +677,6 @@ void xsave_init(void)
>
>  static inline void __init eager_fpu_init_bp(void)
>  {
> -       current->thread.fpu.state =
> -           alloc_bootmem_align(xstate_size, __alignof__(struct
> xsave_struct));
>         if (!init_xstate_buf)
>                 setup_init_fpu_buf();
>  }
> --
> 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://www.tux.org/lkml/
>

--001a113fa606cd9a31050a6f6d6c
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, Sep 2, 2014 at 12:06 PM, David Vrabel <span dir=3D"ltr">&lt;<a =
href=3D"mailto:david.vrabel@citrix.com" target=3D"_blank">david.vrabel@citr=
ix.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From: Suresh Sid=
dha &lt;<a href=3D"mailto:sbsiddha@gmail.com">sbsiddha@gmail.com</a>&gt;<br=
>
<br>
For non-eager fpu mode, thread&#39;s fpu state is allocated during the firs=
t<br>
fpu usage (in the context of device not available exception). This can be<b=
r>
a blocking call and hence we enable interrupts (which were originally<br>
disabled when the exception happened), allocate memory and disable<br>
interrupts etc. While this saves 512 bytes or so per-thread, there<br>
are some issues in general.<br>
<br>
a.=C2=A0 Most of the future cases will be anyway using eager<br>
FPU (because of processor features like xsaveopt, LWP, MPX etc) and<br>
they do the allocation at the thread creation itself. Nice to have<br>
one common mechanism as all the state save/restore code is<br>
shared. Avoids the confusion and minimizes the subtle bugs<br>
in the core piece involved with context-switch.<br>
<br>
b. If a parent thread uses FPU, during fork() we allocate<br>
the FPU state in the child and copy the state etc. Shortly after this,<br>
during exec() we free it up, so that we can later allocate during<br>
the first usage of FPU. So this free/allocate might be slower<br>
for some workloads.<br>
<br>
c. math_state_restore() is called from multiple places<br>
and it is error pone if the caller expects interrupts to be disabled<br>
throughout the execution of math_state_restore(). Can lead to subtle<br>
bugs like Ubuntu bug #1265841.<br>
<br>
Memory savings will be small anyways and the code complexity<br>
introducing subtle bugs is not worth it. So remove<br>
the logic of non-eager fpu mem allocation at the first usage.<br></blockquo=
te><div><br></div><div>=C2=A0</div><div>ping?</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<br>
Signed-off-by: Suresh Siddha &lt;<a href=3D"mailto:sbsiddha@gmail.com">sbsi=
ddha@gmail.com</a>&gt;<br>
Signed-off-by: David Vrabel &lt;<a href=3D"mailto:david.vrabel@citrix.com">=
david.vrabel@citrix.com</a>&gt;<br>
---<br>
v3:<br>
- Rebase on 3.17-rc3.<br>
<br>
v2:<br>
- Tweak condition for allocating the first thread&#39;s FPU state.<br>
---<br>
=C2=A0arch/x86/kernel/i387.c=C2=A0 =C2=A0 |=C2=A0 =C2=A020 +++++++++++-----=
----<br>
=C2=A0arch/x86/kernel/process.c |=C2=A0 =C2=A0 6 ------<br>
=C2=A0arch/x86/kernel/traps.c=C2=A0 =C2=A0|=C2=A0 =C2=A016 ++--------------=
<br>
=C2=A0arch/x86/kernel/xsave.c=C2=A0 =C2=A0|=C2=A0 =C2=A0 2 --<br>
=C2=A04 files changed, 13 insertions(+), 31 deletions(-)<br>
<br>
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c<br>
index a9a4229..956ea86 100644<br>
--- a/arch/x86/kernel/i387.c<br>
+++ b/arch/x86/kernel/i387.c<br>
@@ -5,6 +5,7 @@<br>
=C2=A0 *=C2=A0 General FPU state handling cleanups<br>
=C2=A0 *=C2=A0 =C2=A0 =C2=A0Gareth Hughes &lt;<a href=3D"mailto:gareth@vali=
nux.com">gareth@valinux.com</a>&gt;, May 2000<br>
=C2=A0 */<br>
+#include &lt;linux/bootmem.h&gt;<br>
=C2=A0#include &lt;linux/module.h&gt;<br>
=C2=A0#include &lt;linux/regset.h&gt;<br>
=C2=A0#include &lt;linux/sched.h&gt;<br>
@@ -197,6 +198,16 @@ void fpu_init(void)<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mxcsr_feature_mask_init();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 xsave_init();<br>
+<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0/*<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Now we know the final size of the xsave data=
, allocate the<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 * FPU state area for the first task. All other=
 tasks have<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 * this allocated in arch_dup_task_struct().<br=
>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 */<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!current-&gt;thread.fpu.state)<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0current-&gt;thread.=
fpu.state =3D alloc_bootmem_align(xstate_size,<br>
+=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 =C2=A0 =C2=A0 =C2=A0__alignof__(struct xsave_struct));<br=
>
+<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 eager_fpu_init();<br>
=C2=A0}<br>
<br>
@@ -228,8 +239,6 @@ EXPORT_SYMBOL_GPL(fpu_finit);<br>
=C2=A0 */<br>
=C2=A0int init_fpu(struct task_struct *tsk)<br>
=C2=A0{<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0int ret;<br>
-<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (tsk_used_math(tsk)) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (cpu_has_fpu &am=
p;&amp; tsk =3D=3D current)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 unlazy_fpu(tsk);<br>
@@ -237,13 +246,6 @@ int init_fpu(struct task_struct *tsk)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0/*<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Memory allocation at the first usage of the =
FPU and other state.<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 */<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0ret =3D fpu_alloc(&amp;tsk-&gt;thread.fpu);<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0if (ret)<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return ret;<br>
-<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 fpu_finit(&amp;tsk-&gt;thread.fpu);<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 set_stopped_child_used_math(tsk);<br>
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c<br>
index f804dc9..4137f81 100644<br>
--- a/arch/x86/kernel/process.c<br>
+++ b/arch/x86/kernel/process.c<br>
@@ -129,12 +129,6 @@ void flush_thread(void)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 flush_ptrace_hw_breakpoint(tsk);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 memset(tsk-&gt;thread.tls_array, 0, sizeof(tsk-=
&gt;thread.tls_array));<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 drop_init_fpu(tsk);<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0/*<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Free the FPU state for non xsave platforms. =
They get reallocated<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 * lazily at the first use.<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 */<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!use_eager_fpu())<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0free_thread_xstate(=
tsk);<br>
=C2=A0}<br>
<br>
=C2=A0static void hard_disable_TSC(void)<br>
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c<br>
index 0d0e922..36fc898 100644<br>
--- a/arch/x86/kernel/traps.c<br>
+++ b/arch/x86/kernel/traps.c<br>
@@ -652,20 +652,8 @@ void math_state_restore(void)<br>
=C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct task_struct *tsk =3D current;<br>
<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!tsk_used_math(tsk)) {<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0local_irq_enable();=
<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * does a slab allo=
c which can sleep<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (init_fpu(tsk)) =
{<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/*<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 * ran out of memory!<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 */<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0do_group_exit(SIGKILL);<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0return;<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0local_irq_disable()=
;<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!tsk_used_math(tsk))<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0init_fpu(tsk);<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __thread_fpu_begin(tsk);<br>
<br>
diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c<br>
index 940b142..eed95d6 100644<br>
--- a/arch/x86/kernel/xsave.c<br>
+++ b/arch/x86/kernel/xsave.c<br>
@@ -677,8 +677,6 @@ void xsave_init(void)<br>
<br>
=C2=A0static inline void __init eager_fpu_init_bp(void)<br>
=C2=A0{<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0current-&gt;thread.fpu.state =3D<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alloc_bootmem_align(xstate_size, =
__alignof__(struct xsave_struct));<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!init_xstate_buf)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 setup_init_fpu_buf(=
);<br>
=C2=A0}<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
1.7.10.4<br>
<br>
--<br>
To unsubscribe from this list: send the line &quot;unsubscribe linux-kernel=
&quot; in<br>
the body of a message to <a href=3D"mailto:majordomo@vger.kernel.org">major=
domo@vger.kernel.org</a><br>
More majordomo info at=C2=A0 <a href=3D"http://vger.kernel.org/majordomo-in=
fo.html" target=3D"_blank">http://vger.kernel.org/majordomo-info.html</a><b=
r>
Please read the FAQ at=C2=A0 <a href=3D"http://www.tux.org/lkml/" target=3D=
"_blank">http://www.tux.org/lkml/</a><br>
</font></span></blockquote></div></div></div>

--001a113fa606cd9a31050a6f6d6c--


--===============5576680560440703727==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5576680560440703727==--


From xen-devel-bounces@lists.xen.org Wed Dec 17 20:37:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 20: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 1Y1LKi-000228-JI; Wed, 17 Dec 2014 20:36:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1Y1LKg-000223-CU
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 20:36:30 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	A9/13-02957-D49E1945; Wed, 17 Dec 2014 20:36:29 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418848583!11122608!1
X-Originating-IP: [209.85.213.170]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9027 invoked from network); 17 Dec 2014 20:36:24 -0000
Received: from mail-ig0-f170.google.com (HELO mail-ig0-f170.google.com)
	(209.85.213.170)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Dec 2014 20:36:24 -0000
Received: by mail-ig0-f170.google.com with SMTP id r2so10134353igi.5
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 12:36:23 -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=vznsQQ7wvQkHmJqtuI2oMj8o0gZCq8H6xUZS+1NHmgo=;
	b=RLNxZoPfYJeM4qnuX+JFk1DMA8NXwHyoNNTkkzXcniLcjY2teJdhntht715p0nENed
	qkLnKL1lZWLXSEsAd1AedJRxn1OUqtAxBHQKdt60zoTMoqLQ28xH2RtqtAAZwlsRHoku
	yW3CL/ddwgTHQNNWO4tXSCURMgF9hsPZxf6gEWAhakPx2C3leeI3z6wS8opstwrPtAMG
	JtMnkPEkI4V4ye/47lI2BnrM+OQp0yWN7dCvA4g9M9WOkLl3ONy69nuOd1fK0W7Tkvhm
	wX4XIbIHCye+wJoMh+WgesRPIlEw2XZ37QWgMKBgnBKRhbEG0EPZJ1UAQgBtXecM8Vm4
	7u0A==
MIME-Version: 1.0
X-Received: by 10.107.138.5 with SMTP id m5mr23979554iod.85.1418848583389;
	Wed, 17 Dec 2014 12:36:23 -0800 (PST)
Received: by 10.64.81.7 with HTTP; Wed, 17 Dec 2014 12:36:23 -0800 (PST)
In-Reply-To: <1409674013-10321-1-git-send-email-david.vrabel@citrix.com>
References: <1409674013-10321-1-git-send-email-david.vrabel@citrix.com>
Date: Wed, 17 Dec 2014 15:36:23 -0500
X-Google-Sender-Auth: nHjBj1qfj7K4sn26p5Y-CMA1sK0
Message-ID: <CACJDEmo1NPoFE-RaO97GSyn8a2tYA3Fw5TncdXTs5GXczZi1mQ@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: David Vrabel <david.vrabel@citrix.com>, annie li <annie.li@oracle.com>, 
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, X86 <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Suresh Siddha <sbsiddha@gmail.com>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCHv3] x86,
 fpu: remove the logic of non-eager fpu mem allocation at the first
 usage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5576680560440703727=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5576680560440703727==
Content-Type: multipart/alternative; boundary=001a113fa606cd9a31050a6f6d6c

--001a113fa606cd9a31050a6f6d6c
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 2, 2014 at 12:06 PM, David Vrabel <david.vrabel@citrix.com>
wrote:
>
> From: Suresh Siddha <sbsiddha@gmail.com>
>
> For non-eager fpu mode, thread's fpu state is allocated during the first
> fpu usage (in the context of device not available exception). This can be
> a blocking call and hence we enable interrupts (which were originally
> disabled when the exception happened), allocate memory and disable
> interrupts etc. While this saves 512 bytes or so per-thread, there
> are some issues in general.
>
> a.  Most of the future cases will be anyway using eager
> FPU (because of processor features like xsaveopt, LWP, MPX etc) and
> they do the allocation at the thread creation itself. Nice to have
> one common mechanism as all the state save/restore code is
> shared. Avoids the confusion and minimizes the subtle bugs
> in the core piece involved with context-switch.
>
> b. If a parent thread uses FPU, during fork() we allocate
> the FPU state in the child and copy the state etc. Shortly after this,
> during exec() we free it up, so that we can later allocate during
> the first usage of FPU. So this free/allocate might be slower
> for some workloads.
>
> c. math_state_restore() is called from multiple places
> and it is error pone if the caller expects interrupts to be disabled
> throughout the execution of math_state_restore(). Can lead to subtle
> bugs like Ubuntu bug #1265841.
>
> Memory savings will be small anyways and the code complexity
> introducing subtle bugs is not worth it. So remove
> the logic of non-eager fpu mem allocation at the first usage.
>


ping?

>
> Signed-off-by: Suresh Siddha <sbsiddha@gmail.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
> v3:
> - Rebase on 3.17-rc3.
>
> v2:
> - Tweak condition for allocating the first thread's FPU state.
> ---
>  arch/x86/kernel/i387.c    |   20 +++++++++++---------
>  arch/x86/kernel/process.c |    6 ------
>  arch/x86/kernel/traps.c   |   16 ++--------------
>  arch/x86/kernel/xsave.c   |    2 --
>  4 files changed, 13 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
> index a9a4229..956ea86 100644
> --- a/arch/x86/kernel/i387.c
> +++ b/arch/x86/kernel/i387.c
> @@ -5,6 +5,7 @@
>   *  General FPU state handling cleanups
>   *     Gareth Hughes <gareth@valinux.com>, May 2000
>   */
> +#include <linux/bootmem.h>
>  #include <linux/module.h>
>  #include <linux/regset.h>
>  #include <linux/sched.h>
> @@ -197,6 +198,16 @@ void fpu_init(void)
>
>         mxcsr_feature_mask_init();
>         xsave_init();
> +
> +       /*
> +        * Now we know the final size of the xsave data, allocate the
> +        * FPU state area for the first task. All other tasks have
> +        * this allocated in arch_dup_task_struct().
> +        */
> +       if (!current->thread.fpu.state)
> +               current->thread.fpu.state =
> alloc_bootmem_align(xstate_size,
> +                               __alignof__(struct xsave_struct));
> +
>         eager_fpu_init();
>  }
>
> @@ -228,8 +239,6 @@ EXPORT_SYMBOL_GPL(fpu_finit);
>   */
>  int init_fpu(struct task_struct *tsk)
>  {
> -       int ret;
> -
>         if (tsk_used_math(tsk)) {
>                 if (cpu_has_fpu && tsk == current)
>                         unlazy_fpu(tsk);
> @@ -237,13 +246,6 @@ int init_fpu(struct task_struct *tsk)
>                 return 0;
>         }
>
> -       /*
> -        * Memory allocation at the first usage of the FPU and other state.
> -        */
> -       ret = fpu_alloc(&tsk->thread.fpu);
> -       if (ret)
> -               return ret;
> -
>         fpu_finit(&tsk->thread.fpu);
>
>         set_stopped_child_used_math(tsk);
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index f804dc9..4137f81 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -129,12 +129,6 @@ void flush_thread(void)
>         flush_ptrace_hw_breakpoint(tsk);
>         memset(tsk->thread.tls_array, 0, sizeof(tsk->thread.tls_array));
>         drop_init_fpu(tsk);
> -       /*
> -        * Free the FPU state for non xsave platforms. They get reallocated
> -        * lazily at the first use.
> -        */
> -       if (!use_eager_fpu())
> -               free_thread_xstate(tsk);
>  }
>
>  static void hard_disable_TSC(void)
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 0d0e922..36fc898 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -652,20 +652,8 @@ void math_state_restore(void)
>  {
>         struct task_struct *tsk = current;
>
> -       if (!tsk_used_math(tsk)) {
> -               local_irq_enable();
> -               /*
> -                * does a slab alloc which can sleep
> -                */
> -               if (init_fpu(tsk)) {
> -                       /*
> -                        * ran out of memory!
> -                        */
> -                       do_group_exit(SIGKILL);
> -                       return;
> -               }
> -               local_irq_disable();
> -       }
> +       if (!tsk_used_math(tsk))
> +               init_fpu(tsk);
>
>         __thread_fpu_begin(tsk);
>
> diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c
> index 940b142..eed95d6 100644
> --- a/arch/x86/kernel/xsave.c
> +++ b/arch/x86/kernel/xsave.c
> @@ -677,8 +677,6 @@ void xsave_init(void)
>
>  static inline void __init eager_fpu_init_bp(void)
>  {
> -       current->thread.fpu.state =
> -           alloc_bootmem_align(xstate_size, __alignof__(struct
> xsave_struct));
>         if (!init_xstate_buf)
>                 setup_init_fpu_buf();
>  }
> --
> 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://www.tux.org/lkml/
>

--001a113fa606cd9a31050a6f6d6c
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, Sep 2, 2014 at 12:06 PM, David Vrabel <span dir=3D"ltr">&lt;<a =
href=3D"mailto:david.vrabel@citrix.com" target=3D"_blank">david.vrabel@citr=
ix.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From: Suresh Sid=
dha &lt;<a href=3D"mailto:sbsiddha@gmail.com">sbsiddha@gmail.com</a>&gt;<br=
>
<br>
For non-eager fpu mode, thread&#39;s fpu state is allocated during the firs=
t<br>
fpu usage (in the context of device not available exception). This can be<b=
r>
a blocking call and hence we enable interrupts (which were originally<br>
disabled when the exception happened), allocate memory and disable<br>
interrupts etc. While this saves 512 bytes or so per-thread, there<br>
are some issues in general.<br>
<br>
a.=C2=A0 Most of the future cases will be anyway using eager<br>
FPU (because of processor features like xsaveopt, LWP, MPX etc) and<br>
they do the allocation at the thread creation itself. Nice to have<br>
one common mechanism as all the state save/restore code is<br>
shared. Avoids the confusion and minimizes the subtle bugs<br>
in the core piece involved with context-switch.<br>
<br>
b. If a parent thread uses FPU, during fork() we allocate<br>
the FPU state in the child and copy the state etc. Shortly after this,<br>
during exec() we free it up, so that we can later allocate during<br>
the first usage of FPU. So this free/allocate might be slower<br>
for some workloads.<br>
<br>
c. math_state_restore() is called from multiple places<br>
and it is error pone if the caller expects interrupts to be disabled<br>
throughout the execution of math_state_restore(). Can lead to subtle<br>
bugs like Ubuntu bug #1265841.<br>
<br>
Memory savings will be small anyways and the code complexity<br>
introducing subtle bugs is not worth it. So remove<br>
the logic of non-eager fpu mem allocation at the first usage.<br></blockquo=
te><div><br></div><div>=C2=A0</div><div>ping?</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<br>
Signed-off-by: Suresh Siddha &lt;<a href=3D"mailto:sbsiddha@gmail.com">sbsi=
ddha@gmail.com</a>&gt;<br>
Signed-off-by: David Vrabel &lt;<a href=3D"mailto:david.vrabel@citrix.com">=
david.vrabel@citrix.com</a>&gt;<br>
---<br>
v3:<br>
- Rebase on 3.17-rc3.<br>
<br>
v2:<br>
- Tweak condition for allocating the first thread&#39;s FPU state.<br>
---<br>
=C2=A0arch/x86/kernel/i387.c=C2=A0 =C2=A0 |=C2=A0 =C2=A020 +++++++++++-----=
----<br>
=C2=A0arch/x86/kernel/process.c |=C2=A0 =C2=A0 6 ------<br>
=C2=A0arch/x86/kernel/traps.c=C2=A0 =C2=A0|=C2=A0 =C2=A016 ++--------------=
<br>
=C2=A0arch/x86/kernel/xsave.c=C2=A0 =C2=A0|=C2=A0 =C2=A0 2 --<br>
=C2=A04 files changed, 13 insertions(+), 31 deletions(-)<br>
<br>
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c<br>
index a9a4229..956ea86 100644<br>
--- a/arch/x86/kernel/i387.c<br>
+++ b/arch/x86/kernel/i387.c<br>
@@ -5,6 +5,7 @@<br>
=C2=A0 *=C2=A0 General FPU state handling cleanups<br>
=C2=A0 *=C2=A0 =C2=A0 =C2=A0Gareth Hughes &lt;<a href=3D"mailto:gareth@vali=
nux.com">gareth@valinux.com</a>&gt;, May 2000<br>
=C2=A0 */<br>
+#include &lt;linux/bootmem.h&gt;<br>
=C2=A0#include &lt;linux/module.h&gt;<br>
=C2=A0#include &lt;linux/regset.h&gt;<br>
=C2=A0#include &lt;linux/sched.h&gt;<br>
@@ -197,6 +198,16 @@ void fpu_init(void)<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mxcsr_feature_mask_init();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 xsave_init();<br>
+<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0/*<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Now we know the final size of the xsave data=
, allocate the<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 * FPU state area for the first task. All other=
 tasks have<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 * this allocated in arch_dup_task_struct().<br=
>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 */<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!current-&gt;thread.fpu.state)<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0current-&gt;thread.=
fpu.state =3D alloc_bootmem_align(xstate_size,<br>
+=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 =C2=A0 =C2=A0 =C2=A0__alignof__(struct xsave_struct));<br=
>
+<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 eager_fpu_init();<br>
=C2=A0}<br>
<br>
@@ -228,8 +239,6 @@ EXPORT_SYMBOL_GPL(fpu_finit);<br>
=C2=A0 */<br>
=C2=A0int init_fpu(struct task_struct *tsk)<br>
=C2=A0{<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0int ret;<br>
-<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (tsk_used_math(tsk)) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (cpu_has_fpu &am=
p;&amp; tsk =3D=3D current)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 unlazy_fpu(tsk);<br>
@@ -237,13 +246,6 @@ int init_fpu(struct task_struct *tsk)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0/*<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Memory allocation at the first usage of the =
FPU and other state.<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 */<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0ret =3D fpu_alloc(&amp;tsk-&gt;thread.fpu);<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0if (ret)<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return ret;<br>
-<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 fpu_finit(&amp;tsk-&gt;thread.fpu);<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 set_stopped_child_used_math(tsk);<br>
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c<br>
index f804dc9..4137f81 100644<br>
--- a/arch/x86/kernel/process.c<br>
+++ b/arch/x86/kernel/process.c<br>
@@ -129,12 +129,6 @@ void flush_thread(void)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 flush_ptrace_hw_breakpoint(tsk);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 memset(tsk-&gt;thread.tls_array, 0, sizeof(tsk-=
&gt;thread.tls_array));<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 drop_init_fpu(tsk);<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0/*<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Free the FPU state for non xsave platforms. =
They get reallocated<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 * lazily at the first use.<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 */<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!use_eager_fpu())<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0free_thread_xstate(=
tsk);<br>
=C2=A0}<br>
<br>
=C2=A0static void hard_disable_TSC(void)<br>
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c<br>
index 0d0e922..36fc898 100644<br>
--- a/arch/x86/kernel/traps.c<br>
+++ b/arch/x86/kernel/traps.c<br>
@@ -652,20 +652,8 @@ void math_state_restore(void)<br>
=C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct task_struct *tsk =3D current;<br>
<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!tsk_used_math(tsk)) {<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0local_irq_enable();=
<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * does a slab allo=
c which can sleep<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (init_fpu(tsk)) =
{<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0/*<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 * ran out of memory!<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 */<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0do_group_exit(SIGKILL);<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0return;<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0local_irq_disable()=
;<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!tsk_used_math(tsk))<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0init_fpu(tsk);<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __thread_fpu_begin(tsk);<br>
<br>
diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c<br>
index 940b142..eed95d6 100644<br>
--- a/arch/x86/kernel/xsave.c<br>
+++ b/arch/x86/kernel/xsave.c<br>
@@ -677,8 +677,6 @@ void xsave_init(void)<br>
<br>
=C2=A0static inline void __init eager_fpu_init_bp(void)<br>
=C2=A0{<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0current-&gt;thread.fpu.state =3D<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alloc_bootmem_align(xstate_size, =
__alignof__(struct xsave_struct));<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!init_xstate_buf)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 setup_init_fpu_buf(=
);<br>
=C2=A0}<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
1.7.10.4<br>
<br>
--<br>
To unsubscribe from this list: send the line &quot;unsubscribe linux-kernel=
&quot; in<br>
the body of a message to <a href=3D"mailto:majordomo@vger.kernel.org">major=
domo@vger.kernel.org</a><br>
More majordomo info at=C2=A0 <a href=3D"http://vger.kernel.org/majordomo-in=
fo.html" target=3D"_blank">http://vger.kernel.org/majordomo-info.html</a><b=
r>
Please read the FAQ at=C2=A0 <a href=3D"http://www.tux.org/lkml/" target=3D=
"_blank">http://www.tux.org/lkml/</a><br>
</font></span></blockquote></div></div></div>

--001a113fa606cd9a31050a6f6d6c--


--===============5576680560440703727==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5576680560440703727==--


From xen-devel-bounces@lists.xen.org Wed Dec 17 20:53:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 20:53:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1LaT-0002bi-SJ; Wed, 17 Dec 2014 20:52:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y1LaR-0002b3-PX
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 20:52:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DB/61-09842-F1DE1945; Wed, 17 Dec 2014 20:52:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418849565!16339176!1
X-Originating-IP: [156.151.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 22623 invoked from network); 17 Dec 2014 20:52:46 -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; 17 Dec 2014 20:52: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 sBHKqfSc012407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 20:52: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
	sBHKqeJX008117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 20:52:40 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
	sBHKqeid008105; Wed, 17 Dec 2014 20:52:40 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 12:52:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 62C2C125677; Wed, 17 Dec 2014 15:52:40 -0500 (EST)
Date: Wed, 17 Dec 2014 15:52:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Schinker <ba1020@homie.homelinux.net>
Message-ID: <20141217205240.GA1829@laptop.dumpdata.com>
References: <1022891597.144.1418462628949.JavaMail.zimbra@homie.homelinux.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1022891597.144.1418462628949.JavaMail.zimbra@homie.homelinux.net>
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
Subject: Re: [Xen-devel] [TESTDAY] Test report  Xen 4.5.0-RC3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Dec 13, 2014 at 09:23:48AM +0000, Juergen Schinker wrote:
> Subject: [TESTDAY] Test report Xen 4.5.0-RC3
>  
> * Hardware:
>  Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz (4cores -1 socket)
>  32G Ram
> 
> * Software:
>   Debian Jessie
> 
> * Guest operating systems:
>   Debian Jessie
> * Functionality tested:
>   xl
>   pygrub
> 
> * Comments:
> 
> had to compile with
> configure --enable-githttp --enable-systemd


Thank you for posting that!
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 17 20:53:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 20:53:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1LaT-0002bi-SJ; Wed, 17 Dec 2014 20:52:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y1LaR-0002b3-PX
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 20:52:47 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DB/61-09842-F1DE1945; Wed, 17 Dec 2014 20:52:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418849565!16339176!1
X-Originating-IP: [156.151.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 22623 invoked from network); 17 Dec 2014 20:52:46 -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; 17 Dec 2014 20:52: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 sBHKqfSc012407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 20:52: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
	sBHKqeJX008117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 20:52:40 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
	sBHKqeid008105; Wed, 17 Dec 2014 20:52:40 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 12:52:40 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 62C2C125677; Wed, 17 Dec 2014 15:52:40 -0500 (EST)
Date: Wed, 17 Dec 2014 15:52:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Schinker <ba1020@homie.homelinux.net>
Message-ID: <20141217205240.GA1829@laptop.dumpdata.com>
References: <1022891597.144.1418462628949.JavaMail.zimbra@homie.homelinux.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1022891597.144.1418462628949.JavaMail.zimbra@homie.homelinux.net>
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
Subject: Re: [Xen-devel] [TESTDAY] Test report  Xen 4.5.0-RC3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Dec 13, 2014 at 09:23:48AM +0000, Juergen Schinker wrote:
> Subject: [TESTDAY] Test report Xen 4.5.0-RC3
>  
> * Hardware:
>  Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz (4cores -1 socket)
>  32G Ram
> 
> * Software:
>   Debian Jessie
> 
> * Guest operating systems:
>   Debian Jessie
> * Functionality tested:
>   xl
>   pygrub
> 
> * Comments:
> 
> had to compile with
> configure --enable-githttp --enable-systemd


Thank you for posting that!
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 17 20:55:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 20:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Lcz-0002nB-FP; Wed, 17 Dec 2014 20:55: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 1Y1Lcy-0002n5-Lq
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 20:55:24 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	86/E2-09842-CBDE1945; Wed, 17 Dec 2014 20:55:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418849722!16299062!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32543 invoked from network); 17 Dec 2014 20:55:23 -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; 17 Dec 2014 20:55:23 -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 sBHKsvpd013164
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 20:54: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
	sBHKsuah014606
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 20:54:56 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
	sBHKstJg003163; Wed, 17 Dec 2014 20:54:56 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 12:54:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 11F0D12567C; Wed, 17 Dec 2014 15:54:55 -0500 (EST)
Date: Wed, 17 Dec 2014 15:54:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141217205455.GB1829@laptop.dumpdata.com>
References: <321a64dc64db335460b51becfc040f4cb0e84a9e.1407146305.git.ian.campbell@citrix.com>
	<1418637751.16425.64.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418637751.16425.64.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Bastian Blank <waldi@debian.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: libxl: link libxlu against 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, Dec 15, 2014 at 10:02:31AM +0000, Ian Campbell wrote:
> On Mon, 2014-08-04 at 10:58 +0100, Ian Campbell wrote:
> 
> Ping again. This issue has resurfaced in the Debian packaging of the 4.5
> rcs. I think we should fix this for 4.5, the risks are minimal.

Ah, the patch did not have 'for-xen-4.5' in it :-P

> 
> > It uses libxl_defbool_set and must therefore be linked against the
> > right library.
> > 
> > Spotted by dpkg-shlibdeps and pointed out by Bastian Blank:
> > 
> > dpkg-shlibdeps: warning: symbol libxl_defbool_set used by debian/libxen-4.4/usr/lib/libxlutil-4.4.so found in none of the libraries
> > 
> > This required switching the make rule from $^ to an explicit
> > LIBXLU_OBJS since the former now includes libxenlight.so.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Bastian Blank <waldi@debian.org>

Shouldn't this be 'Reported-by: "

Anyhow,

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  tools/libxl/Makefile |    6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> > index bd0db3b..e61048d 100644
> > --- a/tools/libxl/Makefile
> > +++ b/tools/libxl/Makefile
> > @@ -35,7 +35,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
> >  LIBXL_LIBS += $(PTHREAD_LIBS)
> >  LIBXL_LIBS += $(LIBXL_LIBS-y)
> >  
> > -LIBXLU_LIBS =
> > +LIBXLU_LIBS = libxenlight.so
> >  
> >  LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
> >  ifeq ($(LIBXL_BLKTAP),y)
> > @@ -213,8 +213,8 @@ libxlutil.so: libxlutil.so.$(XLUMAJOR)
> >  libxlutil.so.$(XLUMAJOR): libxlutil.so.$(XLUMAJOR).$(XLUMINOR)
> >  	$(SYMLINK_SHLIB) $< $@
> >  
> > -libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS)
> > -	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxlutil.so.$(XLUMAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXLU_LIBS) $(APPEND_LDFLAGS)
> > +libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS) libxenlight.so
> > +	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxlutil.so.$(XLUMAJOR) $(SHLIB_LDFLAGS) -o $@ $(LIBXLU_OBJS) $(LIBXLU_LIBS) $(APPEND_LDFLAGS)
> >  
> >  libxlutil.a: $(LIBXLU_OBJS)
> >  	$(AR) rcs libxlutil.a $^
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 20:55:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 20:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Lcz-0002nB-FP; Wed, 17 Dec 2014 20:55: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 1Y1Lcy-0002n5-Lq
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 20:55:24 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	86/E2-09842-CBDE1945; Wed, 17 Dec 2014 20:55:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418849722!16299062!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32543 invoked from network); 17 Dec 2014 20:55:23 -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; 17 Dec 2014 20:55:23 -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 sBHKsvpd013164
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 20:54: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
	sBHKsuah014606
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 20:54:56 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
	sBHKstJg003163; Wed, 17 Dec 2014 20:54:56 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 12:54:55 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 11F0D12567C; Wed, 17 Dec 2014 15:54:55 -0500 (EST)
Date: Wed, 17 Dec 2014 15:54:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141217205455.GB1829@laptop.dumpdata.com>
References: <321a64dc64db335460b51becfc040f4cb0e84a9e.1407146305.git.ian.campbell@citrix.com>
	<1418637751.16425.64.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418637751.16425.64.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Bastian Blank <waldi@debian.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: libxl: link libxlu against 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, Dec 15, 2014 at 10:02:31AM +0000, Ian Campbell wrote:
> On Mon, 2014-08-04 at 10:58 +0100, Ian Campbell wrote:
> 
> Ping again. This issue has resurfaced in the Debian packaging of the 4.5
> rcs. I think we should fix this for 4.5, the risks are minimal.

Ah, the patch did not have 'for-xen-4.5' in it :-P

> 
> > It uses libxl_defbool_set and must therefore be linked against the
> > right library.
> > 
> > Spotted by dpkg-shlibdeps and pointed out by Bastian Blank:
> > 
> > dpkg-shlibdeps: warning: symbol libxl_defbool_set used by debian/libxen-4.4/usr/lib/libxlutil-4.4.so found in none of the libraries
> > 
> > This required switching the make rule from $^ to an explicit
> > LIBXLU_OBJS since the former now includes libxenlight.so.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Bastian Blank <waldi@debian.org>

Shouldn't this be 'Reported-by: "

Anyhow,

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  tools/libxl/Makefile |    6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> > index bd0db3b..e61048d 100644
> > --- a/tools/libxl/Makefile
> > +++ b/tools/libxl/Makefile
> > @@ -35,7 +35,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
> >  LIBXL_LIBS += $(PTHREAD_LIBS)
> >  LIBXL_LIBS += $(LIBXL_LIBS-y)
> >  
> > -LIBXLU_LIBS =
> > +LIBXLU_LIBS = libxenlight.so
> >  
> >  LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
> >  ifeq ($(LIBXL_BLKTAP),y)
> > @@ -213,8 +213,8 @@ libxlutil.so: libxlutil.so.$(XLUMAJOR)
> >  libxlutil.so.$(XLUMAJOR): libxlutil.so.$(XLUMAJOR).$(XLUMINOR)
> >  	$(SYMLINK_SHLIB) $< $@
> >  
> > -libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS)
> > -	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxlutil.so.$(XLUMAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXLU_LIBS) $(APPEND_LDFLAGS)
> > +libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS) libxenlight.so
> > +	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxlutil.so.$(XLUMAJOR) $(SHLIB_LDFLAGS) -o $@ $(LIBXLU_OBJS) $(LIBXLU_LIBS) $(APPEND_LDFLAGS)
> >  
> >  libxlutil.a: $(LIBXLU_OBJS)
> >  	$(AR) rcs libxlutil.a $^
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 21:08:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 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 1Y1Lp7-0003HC-PN; Wed, 17 Dec 2014 21:07:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y1Lp6-0003H7-Aa
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 21:07:56 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FA/0B-09842-BA0F1945; Wed, 17 Dec 2014 21:07:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418850473!12897927!1
X-Originating-IP: [156.151.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 18274 invoked from network); 17 Dec 2014 21:07:54 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 21:07:54 -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 sBHL7fsr004939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 21:07:42 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
	sBHL7eaV019829
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 21:07:41 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
	sBHL7d3D008759; Wed, 17 Dec 2014 21:07:39 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 13:07:39 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 657E7125698; Wed, 17 Dec 2014 16:07:39 -0500 (EST)
Date: Wed, 17 Dec 2014 16:07:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141217210739.GC1829@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
	<1999787702.20141212161352@eikelenboom.it>
	<20141212165035.GA28592@laptop.dumpdata.com>
	<alpine.DEB.2.02.1412151108370.30971@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1412151108370.30971@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>
Subject: Re: [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 Mon, Dec 15, 2014 at 11:13:06AM +0000, Stefano Stabellini wrote:
> On Fri, 12 Dec 2014, Konrad Rzeszutek Wilk wrote:
> > On Fri, Dec 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote:
> > > Hi Konrad,
> > > 
> > > This doesn't seem to be applied yet, nor does it seem to have a release-(N)ACK 
> > > from you ?
> > 
> > Hm, Stefano:
> > 
> > - Is this a regression?
> 
> I don't think so. Probably a regression compared to the xend toolstack
> though.

OK, so that is Xen 4.4 -> Xen 4.5 regression then.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks.
> 
> 
> > - What are the risks of this not going in? I presume that it just means
> >   we haven't reset it in sysfs. But the xc_deassign_device operation
> >   if not done will not affect the hypervisor - which will move the
> >   device to dom0 upon guest teardown.
> 
> The device becomes unusable until somebody manually resets it.
> 
> 
> > > 
> > > --
> > > Sander
> > > 
> > > 
> > > 
> > > Friday, November 28, 2014, 5:53:09 PM, you wrote:
> > > 
> > > > 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 Wed Dec 17 21:08:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 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 1Y1Lp7-0003HC-PN; Wed, 17 Dec 2014 21:07:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y1Lp6-0003H7-Aa
	for xen-devel@lists.xensource.com; Wed, 17 Dec 2014 21:07:56 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	FA/0B-09842-BA0F1945; Wed, 17 Dec 2014 21:07:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418850473!12897927!1
X-Originating-IP: [156.151.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 18274 invoked from network); 17 Dec 2014 21:07:54 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 21:07:54 -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 sBHL7fsr004939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 21:07:42 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
	sBHL7eaV019829
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 21:07:41 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
	sBHL7d3D008759; Wed, 17 Dec 2014 21:07:39 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 13:07:39 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 657E7125698; Wed, 17 Dec 2014 16:07:39 -0500 (EST)
Date: Wed, 17 Dec 2014 16:07:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20141217210739.GC1829@laptop.dumpdata.com>
References: <alpine.DEB.2.02.1411281648500.14135@kaball.uk.xensource.com>
	<1999787702.20141212161352@eikelenboom.it>
	<20141212165035.GA28592@laptop.dumpdata.com>
	<alpine.DEB.2.02.1412151108370.30971@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1412151108370.30971@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Sander Eikelenboom <linux@eikelenboom.it>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>
Subject: Re: [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 Mon, Dec 15, 2014 at 11:13:06AM +0000, Stefano Stabellini wrote:
> On Fri, 12 Dec 2014, Konrad Rzeszutek Wilk wrote:
> > On Fri, Dec 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote:
> > > Hi Konrad,
> > > 
> > > This doesn't seem to be applied yet, nor does it seem to have a release-(N)ACK 
> > > from you ?
> > 
> > Hm, Stefano:
> > 
> > - Is this a regression?
> 
> I don't think so. Probably a regression compared to the xend toolstack
> though.

OK, so that is Xen 4.4 -> Xen 4.5 regression then.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks.
> 
> 
> > - What are the risks of this not going in? I presume that it just means
> >   we haven't reset it in sysfs. But the xc_deassign_device operation
> >   if not done will not affect the hypervisor - which will move the
> >   device to dom0 upon guest teardown.
> 
> The device becomes unusable until somebody manually resets it.
> 
> 
> > > 
> > > --
> > > Sander
> > > 
> > > 
> > > 
> > > Friday, November 28, 2014, 5:53:09 PM, you wrote:
> > > 
> > > > 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 Wed Dec 17 21:44:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 21:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1MNi-0004Zf-Rz; Wed, 17 Dec 2014 21:43:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y1MNi-0004Za-Be
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 21:43:42 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	92/2C-02576-D09F1945; Wed, 17 Dec 2014 21:43:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418852619!11130397!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24572 invoked from network); 17 Dec 2014 21:43:40 -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; 17 Dec 2014 21:43: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 sBHLhZFb012303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 21:43:36 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
	sBHLhYsV016219
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 21:43:35 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
	sBHLhYs3016198; Wed, 17 Dec 2014 21:43:34 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 13:43:34 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 62902125770; Wed, 17 Dec 2014 16:43:34 -0500 (EST)
Date: Wed, 17 Dec 2014 16:43:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141217214333.GE1829@laptop.dumpdata.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<20141216163451.GA18976@aepfle.de>
	<20141216204601.GA11551@konrad-lan.dumpdata.com>
	<20141217075510.GA678@aepfle.de>
	<20141217194150.GD29130@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141217194150.GD29130@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
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCBEZWMgMTcsIDIwMTQgYXQgMDI6NDE6NTBQTSAtMDUwMCwgS29ucmFkIFJ6ZXN6dXRl
ayBXaWxrIHdyb3RlOgo+IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDA4OjU1OjEwQU0gKzAxMDAs
IE9sYWYgSGVyaW5nIHdyb3RlOgo+ID4gT24gVHVlLCBEZWMgMTYsIEtvbnJhZCBSemVzenV0ZWsg
V2lsayB3cm90ZToKPiA+IAo+ID4gPiBPbiBUdWUsIERlYyAxNiwgMjAxNCBhdCAwNTozNDo1MVBN
ICswMTAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiA+ID4gPiBPbiBUdWUsIERlYyAxNiwga29ucmFk
LndpbGtAb3JhY2xlLmNvbSB3cm90ZToKPiA+ID4gPiAKPiA+ID4gPiA+IEluIHRlcm1zIG9mIGJ1
Z3MsIHdlIGhhdmU6Cj4gPiA+ID4gCj4gPiA+ID4gLi4uIHN5c3RlbWQgU0VMaW51eCwgYnV0IGl0
cyBub3QgbGlzdGVkLgo+ID4gPiAKPiA+ID4gPiAKPiA+ID4gPiBXaGF0cyB5b3VyIHBsYW4gd2l0
aCB0aGUgZmFpbHVyZXMgeW91IHNlZT8gU2hvdWxkIEkgY29udGludWUgdG8gYmUKPiA+ID4gPiBj
b25jZXJuZWQgYWJvdXQgdGhhdCwgb3Igd2lsbCBhbGwgdGhlIGJlIHBvc3Rwb25lZCB0byA0LjY/
Cj4gPiA+IAo+ID4gPiBJIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB5b3UgaGFkIHNvbWUgcGF0
Y2hlcyB3aGljaCB3b3VsZCBzb2x2ZSBhCj4gPiA+IG1ham9yaXR5IG9mIHRoZSBpc3N1ZXM/IEFu
ZCBhZnRlciB0aGUgZGlzY3Vzc2lvbiB3aXRoIElhbiBKYWNrc29uIHRoZQo+ID4gPiB3YXkgdG8g
ZXhlYyB3YXMgc29sdmVkPwo+ID4gCj4gPiBOby4gV2hhdCBJIGRpZCB3YXMgdG8gaGFuZGxlIFhF
TlNUT1JFRF9UUkFDRSB3aGljaCBpcyBqdXN0IGEgYm9vbCB0bwo+ID4gcGFzcyAiLVQgL2xvZy9m
aWxlIiB0byB4ZW5zdG9yZWQuIEkgdGhpbmsgeGVuc3RvcmVkIGNhbiBub3QgYWNjZXNzIHRoZQo+
ID4gc29ja2V0cyBpZiBpdCB3YXMgbGF1bmNoZWQgd2l0aCBhIHNoZWxsIHNjcmlwdCBhcyBpdCBp
cyBkb25lIG5vdy4gCj4gPiBObyBpZGVhIGhvdyB0byBzb2x2ZSB0aGF0LiBNYXliZSAiL3Vzci9i
aW4vZW52ICRYRU5TVE9SRUQiIGNvdWxkIGJlIGEKPiA+IHdvcmthcm91bmQgZm9yIHRoZSBTRUxp
bnV4IHNvY2tldCBhY2Nlc3MgaXNzdWUuIEJ1dCBwZXJoYXBzIGxhdW5jaGluZyBpdAo+ID4gdmlh
IGVudiBvciBzaCBmYWlscyBlaXRoZXIgd2F5Lgo+ID4gCj4gPiA+IEFuZCBmb3IgdGhlIG90aGVy
IC0gdGhlIFNFTGludXggY29udGV4dCBhbmQgaG93IHRvIGZpZ3VyZSB0aGlzIG91dCAtCj4gPiA+
IEkgdGhvdWdodCAoSSB3aWxsIGhhdmUgdG8gZG91YmxlLWNoZWNrIGl0IHRvbW9ycm93KSB0aGF0
IEkgbWVudGlvbmVkIGl0IG1pZ2h0Cj4gPiA+IG1ha2Ugc2Vuc2UgdG8gdGFsayB0byB0aGUgU0VM
aW51eCBtYWludGFpbmVycyB0byBzZWUgaWYgdGhleSBoYXZlIGFueQo+ID4gPiByZWNvbW1lbmRh
dGlvbj8KPiA+IAo+ID4gRm9yIHhlbi00LjUgdGhlIGVhc3kgd2F5IHdvdWxkIGJlIHRvIHJlbW92
ZSB0aGUgY29udGV4dD0gb3B0aW9uIGFuZCBsZXQKPiA+IHBlb3BsZSB3aG8gYnVpbGQgZnJvbSBz
b3VyY2UgYW5kIHdobyB3YW50IHRvIHVzZSBTRUxpbnV4IHB1dCB0aGUKPiA+IHJlcXVpcmVkIG9w
dGlvbnMgaW50byAvZXRjL2ZzdGFiLiBUaGlzIHdvdWxkIGFsc28gcmVzb2x2ZSB0aGUgaXNzdWUK
PiA+IEFudGhvbnkgaXMgc2VlaW5nLCBoaXMgbW91bnQgb3Iga2VybmVsIGRvZXMgbm90IHVuZGVy
c3RhbmQgY29udGV4dD0gYXQKPiA+IGFsbC4gTm8gaWRlYSBob3cgaGUgZ290IGludG8gdGhhdCBz
dGF0ZSBpbiBoaXMgQXJjaCBMaW51eCBpbnN0YWxsYXRpb24uCj4gCj4gQW5kIGFsc28gcmVtb3Zl
IHRoZSBFbnZpb25tZW50RmlsZSBhbmQgc3VjaC4gQW55aG93IEkndmUgdGFrZW4gZm9yIAo+IHNw
aW4gdGhlc2UgcGF0Y2hlczoKPiAKPiAgdG9vbHMvaG90cGx1ZzogYWRkIHdyYXBwZXIgdG8gc3Rh
cnQgeGVuc3RvcmVkCj4gIHRvb2xzL2hvdHBsdWc6IHJlbW92ZSBFbnZpcm9ubWVudEZpbGUgZnJv
bSB4ZW4tcWVtdS1kb20wLWRpc2stYmFja2VuZC5zZXJ2aWNlCj4gIHRvb2xzL2hvdHBsdWc6IHVz
ZSBYRU5DT05TT0xFRF9UUkFDRSBpbiB4ZW5jb25zb2xlZC5zZXJ2aWNlCj4gIHRvb2xzL2hvdHBs
dWc6IHVzZSB4ZW5jb21tb25zIGFzIEVudmlyb25tZW50RmlsZSBpbiB4ZW5jb25zb2xlZC5zZXJ2
aWNlCj4gIHRvb2xzL2hvdHBsdWc6IHhlbmRvbWFpbnMuc2VydmljZSBkZXBlbmRzIG9uIG5ldHdv
cmsKPiAgdG9vbHMvaG90cGx1ZzogcmVtb3ZlIFhFTlNUT1JFRF9ST09URElSIGZyb20geGVuc3Rv
cmVkLnNlcnZpY2UKPiAgdG9vbHMvaG90cGx1ZzogcmVtb3ZlIFNFTGludXggb3B0aW9ucyBmcm9t
IHZhci1saWIteGVuc3RvcmVkLm1vdW50Cj4gCj4gZnJvbSB5b3UgIGh0dHBzOi8vZ2l0aHViLmNv
bS9vbGFmaGVyaW5nL3hlbi5naXQgc3RhZ2luZy1mb3ItNC41LjAKPiAKPiBhbmQgdGhleSBmaXhl
ZCB0aGUgaXNzdWVzIEkgc2F3LiBUaGF0IGlzIEkgY2FuIGJvb3QgRmVkb3JhIENvcmUgMjEgd2l0
aAo+IHRoZSBzb3VyY2VzIGJlaW5nIGJ1aWx0IG91dCAocGx1cyBzYWlkIHBhdGNoZXMgYWJvdmUp
CgpIbSwgdGhvdWdodCBub3cgSSBzZWU6Cgpbcm9vdEBsIGtvbnJhZF0jIHN5c3RlbWN0bCBzdGF0
dXMgeGVuc3RvcmVkLnNlcnZpY2UK4pePIHhlbnN0b3JlZC5zZXJ2aWNlIC0gVGhlIFhlbiB4ZW5z
dG9yZQogICBMb2FkZWQ6IGxvYWRlZCAoL3Vzci9saWIvc3lzdGVtZC9zeXN0ZW0veGVuc3RvcmVk
LnNlcnZpY2U7IGRpc2FibGVkKQogICBBY3RpdmU6IGZhaWxlZCAoUmVzdWx0OiB0aW1lb3V0KSBz
aW5jZSBXZWQgMjAxNC0xMi0xNyAxNjozOTozNSBFU1Q7IDJtaW4gMTBzIGFnbwogIFByb2Nlc3M6
IDc5MCBFeGVjU3RhcnQ9L3Vzci9saWIveGVuL2Jpbi94ZW5zdG9yZWQuc2ggLS1uby1mb3JrIChj
b2RlPWV4aXRlZCwgc3RhdHVzPTAvU1VDQ0VTUykKICBQcm9jZXNzOiA3ODcgRXhlY1N0YXJ0UHJl
PS9iaW4vbWtkaXIgLXAgL3Zhci9ydW4veGVuIChjb2RlPWV4aXRlZCwgc3RhdHVzPTAvU1VDQ0VT
UykKICBQcm9jZXNzOiA3ODQgRXhlY1N0YXJ0UHJlPS9iaW4vcm0gLWYgL3Zhci9saWIveGVuc3Rv
cmVkL3RkYiogKGNvZGU9ZXhpdGVkLCBzdGF0dXM9MC9TVUNDRVNTKQogIFByb2Nlc3M6IDc1OSBF
eGVjU3RhcnRQcmU9L2Jpbi9ncmVwIC1xIGNvbnRyb2xfZCAvcHJvYy94ZW4vY2FwYWJpbGl0aWVz
IChjb2RlPWV4aXRlZCwgc3RhdHVzPTAvU1VDQ0VTUykKIE1haW4gUElEOiA3OTAgKGNvZGU9ZXhp
dGVkLCBzdGF0dXM9MC9TVUNDRVNTKQoKRGVjIDE3IDE2OjM4OjA1IGwub3JhY2xlLmNvbSB4ZW5z
dG9yZWQuc2hbNzkwXTogWGVuIFN0b3JhZ2UgRGFlbW9uLCB2ZXJzaW9uIDEuMApEZWMgMTcgMTY6
Mzk6MzUgbC5vcmFjbGUuY29tIHN5c3RlbWRbMV06IHhlbnN0b3JlZC5zZXJ2aWNlIHN0YXJ0IG9w
ZXJhdGlvbiB0aW1lZCBvdXQuIFRlcm1pbmF0aW5nLgpEZWMgMTcgMTY6Mzk6MzUgbC5vcmFjbGUu
Y29tIHN5c3RlbWRbMV06IEZhaWxlZCB0byBzdGFydCBUaGUgWGVuIHhlbnN0b3JlLgpEZWMgMTcg
MTY6Mzk6MzUgbC5vcmFjbGUuY29tIHN5c3RlbWRbMV06IFVuaXQgeGVuc3RvcmVkLnNlcnZpY2Ug
ZW50ZXJlZCBmYWlsZWQgc3RhdGUuCkRlYyAxNyAxNjozOTozNSBsLm9yYWNsZS5jb20gc3lzdGVt
ZFsxXTogeGVuc3RvcmVkLnNlcnZpY2UgZmFpbGVkLgpbcm9vdEBsIGtvbnJhZF0jIHN5c3RlbWN0
bCBzdGFydCB4ZW5zdG9yZWQuc2VydmljZQoKCltyb290QGwgfl0jIHBzIC1lZmZ8Z3JlcCB4ZW5z
CnJvb3QgICAgICAyMDE4ICAxOTkzICAwIDE2OjQxIHB0cy8wICAgIDAwOjAwOjAwIHN5c3RlbWN0
bCBzdGFydCB4ZW5zdG9yZWQuc2VydmljZQpyb290ICAgICAgMjAyOSAgICAgMSAgMCAxNjo0MSA/
ICAgICAgICAwMDowMDowMCAvdXNyL3NiaW4vb3hlbnN0b3JlZCAtLW5vLWZvcmsKcm9vdCAgICAg
IDIwMzQgIDE3NjYgIDAgMTY6NDIgaHZjMCAgICAgMDA6MDA6MDAgZ3JlcCAtLWNvbG9yPWF1dG8g
eGVucwoKSSB0aGluayBJIGhhdmUgc29tZXRoaW5nIG1pc2NvbmZpZ3VyZWQgaGVyZS4uCj4gPiAK
PiA+IE9sYWYKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Dec 17 21:44:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 21:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1MNi-0004Zf-Rz; Wed, 17 Dec 2014 21:43:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y1MNi-0004Za-Be
	for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 21:43:42 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	92/2C-02576-D09F1945; Wed, 17 Dec 2014 21:43:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418852619!11130397!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24572 invoked from network); 17 Dec 2014 21:43:40 -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; 17 Dec 2014 21:43: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 sBHLhZFb012303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Dec 2014 21:43:36 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
	sBHLhYsV016219
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 17 Dec 2014 21:43:35 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
	sBHLhYs3016198; Wed, 17 Dec 2014 21:43:34 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Dec 2014 13:43:34 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 62902125770; Wed, 17 Dec 2014 16:43:34 -0500 (EST)
Date: Wed, 17 Dec 2014 16:43:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141217214333.GE1829@laptop.dumpdata.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<20141216163451.GA18976@aepfle.de>
	<20141216204601.GA11551@konrad-lan.dumpdata.com>
	<20141217075510.GA678@aepfle.de>
	<20141217194150.GD29130@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141217194150.GD29130@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
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCBEZWMgMTcsIDIwMTQgYXQgMDI6NDE6NTBQTSAtMDUwMCwgS29ucmFkIFJ6ZXN6dXRl
ayBXaWxrIHdyb3RlOgo+IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDA4OjU1OjEwQU0gKzAxMDAs
IE9sYWYgSGVyaW5nIHdyb3RlOgo+ID4gT24gVHVlLCBEZWMgMTYsIEtvbnJhZCBSemVzenV0ZWsg
V2lsayB3cm90ZToKPiA+IAo+ID4gPiBPbiBUdWUsIERlYyAxNiwgMjAxNCBhdCAwNTozNDo1MVBN
ICswMTAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiA+ID4gPiBPbiBUdWUsIERlYyAxNiwga29ucmFk
LndpbGtAb3JhY2xlLmNvbSB3cm90ZToKPiA+ID4gPiAKPiA+ID4gPiA+IEluIHRlcm1zIG9mIGJ1
Z3MsIHdlIGhhdmU6Cj4gPiA+ID4gCj4gPiA+ID4gLi4uIHN5c3RlbWQgU0VMaW51eCwgYnV0IGl0
cyBub3QgbGlzdGVkLgo+ID4gPiAKPiA+ID4gPiAKPiA+ID4gPiBXaGF0cyB5b3VyIHBsYW4gd2l0
aCB0aGUgZmFpbHVyZXMgeW91IHNlZT8gU2hvdWxkIEkgY29udGludWUgdG8gYmUKPiA+ID4gPiBj
b25jZXJuZWQgYWJvdXQgdGhhdCwgb3Igd2lsbCBhbGwgdGhlIGJlIHBvc3Rwb25lZCB0byA0LjY/
Cj4gPiA+IAo+ID4gPiBJIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB5b3UgaGFkIHNvbWUgcGF0
Y2hlcyB3aGljaCB3b3VsZCBzb2x2ZSBhCj4gPiA+IG1ham9yaXR5IG9mIHRoZSBpc3N1ZXM/IEFu
ZCBhZnRlciB0aGUgZGlzY3Vzc2lvbiB3aXRoIElhbiBKYWNrc29uIHRoZQo+ID4gPiB3YXkgdG8g
ZXhlYyB3YXMgc29sdmVkPwo+ID4gCj4gPiBOby4gV2hhdCBJIGRpZCB3YXMgdG8gaGFuZGxlIFhF
TlNUT1JFRF9UUkFDRSB3aGljaCBpcyBqdXN0IGEgYm9vbCB0bwo+ID4gcGFzcyAiLVQgL2xvZy9m
aWxlIiB0byB4ZW5zdG9yZWQuIEkgdGhpbmsgeGVuc3RvcmVkIGNhbiBub3QgYWNjZXNzIHRoZQo+
ID4gc29ja2V0cyBpZiBpdCB3YXMgbGF1bmNoZWQgd2l0aCBhIHNoZWxsIHNjcmlwdCBhcyBpdCBp
cyBkb25lIG5vdy4gCj4gPiBObyBpZGVhIGhvdyB0byBzb2x2ZSB0aGF0LiBNYXliZSAiL3Vzci9i
aW4vZW52ICRYRU5TVE9SRUQiIGNvdWxkIGJlIGEKPiA+IHdvcmthcm91bmQgZm9yIHRoZSBTRUxp
bnV4IHNvY2tldCBhY2Nlc3MgaXNzdWUuIEJ1dCBwZXJoYXBzIGxhdW5jaGluZyBpdAo+ID4gdmlh
IGVudiBvciBzaCBmYWlscyBlaXRoZXIgd2F5Lgo+ID4gCj4gPiA+IEFuZCBmb3IgdGhlIG90aGVy
IC0gdGhlIFNFTGludXggY29udGV4dCBhbmQgaG93IHRvIGZpZ3VyZSB0aGlzIG91dCAtCj4gPiA+
IEkgdGhvdWdodCAoSSB3aWxsIGhhdmUgdG8gZG91YmxlLWNoZWNrIGl0IHRvbW9ycm93KSB0aGF0
IEkgbWVudGlvbmVkIGl0IG1pZ2h0Cj4gPiA+IG1ha2Ugc2Vuc2UgdG8gdGFsayB0byB0aGUgU0VM
aW51eCBtYWludGFpbmVycyB0byBzZWUgaWYgdGhleSBoYXZlIGFueQo+ID4gPiByZWNvbW1lbmRh
dGlvbj8KPiA+IAo+ID4gRm9yIHhlbi00LjUgdGhlIGVhc3kgd2F5IHdvdWxkIGJlIHRvIHJlbW92
ZSB0aGUgY29udGV4dD0gb3B0aW9uIGFuZCBsZXQKPiA+IHBlb3BsZSB3aG8gYnVpbGQgZnJvbSBz
b3VyY2UgYW5kIHdobyB3YW50IHRvIHVzZSBTRUxpbnV4IHB1dCB0aGUKPiA+IHJlcXVpcmVkIG9w
dGlvbnMgaW50byAvZXRjL2ZzdGFiLiBUaGlzIHdvdWxkIGFsc28gcmVzb2x2ZSB0aGUgaXNzdWUK
PiA+IEFudGhvbnkgaXMgc2VlaW5nLCBoaXMgbW91bnQgb3Iga2VybmVsIGRvZXMgbm90IHVuZGVy
c3RhbmQgY29udGV4dD0gYXQKPiA+IGFsbC4gTm8gaWRlYSBob3cgaGUgZ290IGludG8gdGhhdCBz
dGF0ZSBpbiBoaXMgQXJjaCBMaW51eCBpbnN0YWxsYXRpb24uCj4gCj4gQW5kIGFsc28gcmVtb3Zl
IHRoZSBFbnZpb25tZW50RmlsZSBhbmQgc3VjaC4gQW55aG93IEkndmUgdGFrZW4gZm9yIAo+IHNw
aW4gdGhlc2UgcGF0Y2hlczoKPiAKPiAgdG9vbHMvaG90cGx1ZzogYWRkIHdyYXBwZXIgdG8gc3Rh
cnQgeGVuc3RvcmVkCj4gIHRvb2xzL2hvdHBsdWc6IHJlbW92ZSBFbnZpcm9ubWVudEZpbGUgZnJv
bSB4ZW4tcWVtdS1kb20wLWRpc2stYmFja2VuZC5zZXJ2aWNlCj4gIHRvb2xzL2hvdHBsdWc6IHVz
ZSBYRU5DT05TT0xFRF9UUkFDRSBpbiB4ZW5jb25zb2xlZC5zZXJ2aWNlCj4gIHRvb2xzL2hvdHBs
dWc6IHVzZSB4ZW5jb21tb25zIGFzIEVudmlyb25tZW50RmlsZSBpbiB4ZW5jb25zb2xlZC5zZXJ2
aWNlCj4gIHRvb2xzL2hvdHBsdWc6IHhlbmRvbWFpbnMuc2VydmljZSBkZXBlbmRzIG9uIG5ldHdv
cmsKPiAgdG9vbHMvaG90cGx1ZzogcmVtb3ZlIFhFTlNUT1JFRF9ST09URElSIGZyb20geGVuc3Rv
cmVkLnNlcnZpY2UKPiAgdG9vbHMvaG90cGx1ZzogcmVtb3ZlIFNFTGludXggb3B0aW9ucyBmcm9t
IHZhci1saWIteGVuc3RvcmVkLm1vdW50Cj4gCj4gZnJvbSB5b3UgIGh0dHBzOi8vZ2l0aHViLmNv
bS9vbGFmaGVyaW5nL3hlbi5naXQgc3RhZ2luZy1mb3ItNC41LjAKPiAKPiBhbmQgdGhleSBmaXhl
ZCB0aGUgaXNzdWVzIEkgc2F3LiBUaGF0IGlzIEkgY2FuIGJvb3QgRmVkb3JhIENvcmUgMjEgd2l0
aAo+IHRoZSBzb3VyY2VzIGJlaW5nIGJ1aWx0IG91dCAocGx1cyBzYWlkIHBhdGNoZXMgYWJvdmUp
CgpIbSwgdGhvdWdodCBub3cgSSBzZWU6Cgpbcm9vdEBsIGtvbnJhZF0jIHN5c3RlbWN0bCBzdGF0
dXMgeGVuc3RvcmVkLnNlcnZpY2UK4pePIHhlbnN0b3JlZC5zZXJ2aWNlIC0gVGhlIFhlbiB4ZW5z
dG9yZQogICBMb2FkZWQ6IGxvYWRlZCAoL3Vzci9saWIvc3lzdGVtZC9zeXN0ZW0veGVuc3RvcmVk
LnNlcnZpY2U7IGRpc2FibGVkKQogICBBY3RpdmU6IGZhaWxlZCAoUmVzdWx0OiB0aW1lb3V0KSBz
aW5jZSBXZWQgMjAxNC0xMi0xNyAxNjozOTozNSBFU1Q7IDJtaW4gMTBzIGFnbwogIFByb2Nlc3M6
IDc5MCBFeGVjU3RhcnQ9L3Vzci9saWIveGVuL2Jpbi94ZW5zdG9yZWQuc2ggLS1uby1mb3JrIChj
b2RlPWV4aXRlZCwgc3RhdHVzPTAvU1VDQ0VTUykKICBQcm9jZXNzOiA3ODcgRXhlY1N0YXJ0UHJl
PS9iaW4vbWtkaXIgLXAgL3Zhci9ydW4veGVuIChjb2RlPWV4aXRlZCwgc3RhdHVzPTAvU1VDQ0VT
UykKICBQcm9jZXNzOiA3ODQgRXhlY1N0YXJ0UHJlPS9iaW4vcm0gLWYgL3Zhci9saWIveGVuc3Rv
cmVkL3RkYiogKGNvZGU9ZXhpdGVkLCBzdGF0dXM9MC9TVUNDRVNTKQogIFByb2Nlc3M6IDc1OSBF
eGVjU3RhcnRQcmU9L2Jpbi9ncmVwIC1xIGNvbnRyb2xfZCAvcHJvYy94ZW4vY2FwYWJpbGl0aWVz
IChjb2RlPWV4aXRlZCwgc3RhdHVzPTAvU1VDQ0VTUykKIE1haW4gUElEOiA3OTAgKGNvZGU9ZXhp
dGVkLCBzdGF0dXM9MC9TVUNDRVNTKQoKRGVjIDE3IDE2OjM4OjA1IGwub3JhY2xlLmNvbSB4ZW5z
dG9yZWQuc2hbNzkwXTogWGVuIFN0b3JhZ2UgRGFlbW9uLCB2ZXJzaW9uIDEuMApEZWMgMTcgMTY6
Mzk6MzUgbC5vcmFjbGUuY29tIHN5c3RlbWRbMV06IHhlbnN0b3JlZC5zZXJ2aWNlIHN0YXJ0IG9w
ZXJhdGlvbiB0aW1lZCBvdXQuIFRlcm1pbmF0aW5nLgpEZWMgMTcgMTY6Mzk6MzUgbC5vcmFjbGUu
Y29tIHN5c3RlbWRbMV06IEZhaWxlZCB0byBzdGFydCBUaGUgWGVuIHhlbnN0b3JlLgpEZWMgMTcg
MTY6Mzk6MzUgbC5vcmFjbGUuY29tIHN5c3RlbWRbMV06IFVuaXQgeGVuc3RvcmVkLnNlcnZpY2Ug
ZW50ZXJlZCBmYWlsZWQgc3RhdGUuCkRlYyAxNyAxNjozOTozNSBsLm9yYWNsZS5jb20gc3lzdGVt
ZFsxXTogeGVuc3RvcmVkLnNlcnZpY2UgZmFpbGVkLgpbcm9vdEBsIGtvbnJhZF0jIHN5c3RlbWN0
bCBzdGFydCB4ZW5zdG9yZWQuc2VydmljZQoKCltyb290QGwgfl0jIHBzIC1lZmZ8Z3JlcCB4ZW5z
CnJvb3QgICAgICAyMDE4ICAxOTkzICAwIDE2OjQxIHB0cy8wICAgIDAwOjAwOjAwIHN5c3RlbWN0
bCBzdGFydCB4ZW5zdG9yZWQuc2VydmljZQpyb290ICAgICAgMjAyOSAgICAgMSAgMCAxNjo0MSA/
ICAgICAgICAwMDowMDowMCAvdXNyL3NiaW4vb3hlbnN0b3JlZCAtLW5vLWZvcmsKcm9vdCAgICAg
IDIwMzQgIDE3NjYgIDAgMTY6NDIgaHZjMCAgICAgMDA6MDA6MDAgZ3JlcCAtLWNvbG9yPWF1dG8g
eGVucwoKSSB0aGluayBJIGhhdmUgc29tZXRoaW5nIG1pc2NvbmZpZ3VyZWQgaGVyZS4uCj4gPiAK
PiA+IE9sYWYKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Dec 17 23:30:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 23:30:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1O2W-00082v-Jr; Wed, 17 Dec 2014 23:29:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.sivertsen@gmail.com>) id 1Y1O2V-00082q-FD
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 23:29:55 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C7/3C-09842-2F112945; Wed, 17 Dec 2014 23:29:54 +0000
X-Env-Sender: julian.sivertsen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418858993!16375865!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3474 invoked from network); 17 Dec 2014 23:29:53 -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;
	17 Dec 2014 23:29:53 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so132015wgh.2
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 15:29:53 -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=5CPQseqgH4zIWGzTx4Gd3o0G+zDiK56OMQhSu7sejjw=;
	b=tzZWAx4C84PDaiecT4LtfwLmFeOIohEznnH8DiemrXWPbvam0TuZ8OA3Auhn30vghU
	KAPfOjXvWWZkRVlbasmCoZxmJtE86xhHR2VDoWP9CMvgXnEa4XkQ5XHz5ffD0UN+EmV7
	6B+UIJ6SYTHYufBUSqB5JEvX8/hKIWZy8n3IHzKwEZIswFLU92Pq3ZXs2PIhbVUKamdX
	EUkLWQTyvBkQgEgw79Yz+531urYvNwJOcul287v0KcaNGv7Rm4YblzCJzp26hWKGShBR
	GT1CKvuisRQWKnQH2xgX/8sWOtzmDAj2Aa7fvelNt8doVaEl4sK9OvzwHkQut16U0nl0
	Oz+w==
MIME-Version: 1.0
X-Received: by 10.180.211.2 with SMTP id my2mr18529848wic.3.1418858993067;
	Wed, 17 Dec 2014 15:29:53 -0800 (PST)
Received: by 10.194.23.66 with HTTP; Wed, 17 Dec 2014 15:29:53 -0800 (PST)
Date: Thu, 18 Dec 2014 00:29:53 +0100
X-Google-Sender-Auth: Ad_SigRLGTf73vtPoYhGKqhYO2k
Message-ID: <CAKGZkHvCai_PwNyTpH10-2o4wT+-2+HNCwW-yH_kEeVHXXsjHA@mail.gmail.com>
From: Julian Sivertsen <julian.sivertsen+xen@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [Testday] Arch Linux Test report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

== Hardware ==
HP DL380 G5 (2x Intel Xeon 5130)

== Dom0 ==
Arch Linux 64-bit

== Functionality tested ==
Building xen 4.5 RC4 from the tarball, installing it and booting it up
with Arch Linux as the Dom0.

== Comments ==
Xen support on Arch Linux needs a bit of love. Nummerous problems
getting the build to work properly. These issues mainly concerrns
building and installing the xen-4.5-RC4 tarball on Arch Linux. They
would all be solved by the package maintainer of xen, but still presents
a challange for anyone who would want to build xen outside of the
Arch Linux package system. More test reports may follow once I get
guests to run on the system.

== Issues ===
Brief: Invalid FETCHER by ./configure
Importance: nuisance
Location: xen
Workaround: Install wget and reconfigure
The m4/fetcher.m4 script checks for the precence of wget before falling
back to "ftp -o". On Arch Linux curl is shipped and ftp does not support
the -o option. Resulting in the build failing when downloading zlib.

Brief: Grub script does not generate any entries for xen
Importance: low
Location: grub
Workaround: `echo CONFIG_XEN_DOM0=y > /boot/config-linux`
The 20_linux_xen grub configuration helper script shipped in the grub
package in Arch Linux does not generate any entries for xen after it is
installed as it expects a kernel config file to be present. It checks
for CONFIG_XEN_DOM0=y in this kernel config file to dertermine whether
or not the kernel in question supports being runned as a DOM0 under xen.
Additionally the variable ${alt_version} is used before it is defined.
Both of these issues are present in upstream grub.

Brief: error: context option is invalid
Importance: medium
location: unknown
Workaround: Edit out ",context=${...}" in var-lib-xenstored.mount
The context option is not understood somewhere between mount and the
kernel. Possibly SELinux specific, since the default Arch Linux kernel
does not ship with it.

Brief: libxenctrl.so.4.5 not found
Importance: low
Location: probably Arch Linux
Workaround: `echo /usr/local/lib > /etc/ld.so.conf.d/xen.cnf; ldconfig`
Something about the library path is messed up, as oxenstored fails when
launched by systemd. It needs the shared library libxenctrl.so.4.5 which
is located in the /usr/local/lib folder, but doesn't find it.


Julian Sivertsen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 17 23:30:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Dec 2014 23:30:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1O2W-00082v-Jr; Wed, 17 Dec 2014 23:29:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.sivertsen@gmail.com>) id 1Y1O2V-00082q-FD
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 23:29:55 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C7/3C-09842-2F112945; Wed, 17 Dec 2014 23:29:54 +0000
X-Env-Sender: julian.sivertsen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418858993!16375865!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3474 invoked from network); 17 Dec 2014 23:29:53 -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;
	17 Dec 2014 23:29:53 -0000
Received: by mail-wg0-f43.google.com with SMTP id l18so132015wgh.2
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 15:29:53 -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=5CPQseqgH4zIWGzTx4Gd3o0G+zDiK56OMQhSu7sejjw=;
	b=tzZWAx4C84PDaiecT4LtfwLmFeOIohEznnH8DiemrXWPbvam0TuZ8OA3Auhn30vghU
	KAPfOjXvWWZkRVlbasmCoZxmJtE86xhHR2VDoWP9CMvgXnEa4XkQ5XHz5ffD0UN+EmV7
	6B+UIJ6SYTHYufBUSqB5JEvX8/hKIWZy8n3IHzKwEZIswFLU92Pq3ZXs2PIhbVUKamdX
	EUkLWQTyvBkQgEgw79Yz+531urYvNwJOcul287v0KcaNGv7Rm4YblzCJzp26hWKGShBR
	GT1CKvuisRQWKnQH2xgX/8sWOtzmDAj2Aa7fvelNt8doVaEl4sK9OvzwHkQut16U0nl0
	Oz+w==
MIME-Version: 1.0
X-Received: by 10.180.211.2 with SMTP id my2mr18529848wic.3.1418858993067;
	Wed, 17 Dec 2014 15:29:53 -0800 (PST)
Received: by 10.194.23.66 with HTTP; Wed, 17 Dec 2014 15:29:53 -0800 (PST)
Date: Thu, 18 Dec 2014 00:29:53 +0100
X-Google-Sender-Auth: Ad_SigRLGTf73vtPoYhGKqhYO2k
Message-ID: <CAKGZkHvCai_PwNyTpH10-2o4wT+-2+HNCwW-yH_kEeVHXXsjHA@mail.gmail.com>
From: Julian Sivertsen <julian.sivertsen+xen@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [Testday] Arch Linux Test report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

== Hardware ==
HP DL380 G5 (2x Intel Xeon 5130)

== Dom0 ==
Arch Linux 64-bit

== Functionality tested ==
Building xen 4.5 RC4 from the tarball, installing it and booting it up
with Arch Linux as the Dom0.

== Comments ==
Xen support on Arch Linux needs a bit of love. Nummerous problems
getting the build to work properly. These issues mainly concerrns
building and installing the xen-4.5-RC4 tarball on Arch Linux. They
would all be solved by the package maintainer of xen, but still presents
a challange for anyone who would want to build xen outside of the
Arch Linux package system. More test reports may follow once I get
guests to run on the system.

== Issues ===
Brief: Invalid FETCHER by ./configure
Importance: nuisance
Location: xen
Workaround: Install wget and reconfigure
The m4/fetcher.m4 script checks for the precence of wget before falling
back to "ftp -o". On Arch Linux curl is shipped and ftp does not support
the -o option. Resulting in the build failing when downloading zlib.

Brief: Grub script does not generate any entries for xen
Importance: low
Location: grub
Workaround: `echo CONFIG_XEN_DOM0=y > /boot/config-linux`
The 20_linux_xen grub configuration helper script shipped in the grub
package in Arch Linux does not generate any entries for xen after it is
installed as it expects a kernel config file to be present. It checks
for CONFIG_XEN_DOM0=y in this kernel config file to dertermine whether
or not the kernel in question supports being runned as a DOM0 under xen.
Additionally the variable ${alt_version} is used before it is defined.
Both of these issues are present in upstream grub.

Brief: error: context option is invalid
Importance: medium
location: unknown
Workaround: Edit out ",context=${...}" in var-lib-xenstored.mount
The context option is not understood somewhere between mount and the
kernel. Possibly SELinux specific, since the default Arch Linux kernel
does not ship with it.

Brief: libxenctrl.so.4.5 not found
Importance: low
Location: probably Arch Linux
Workaround: `echo /usr/local/lib > /etc/ld.so.conf.d/xen.cnf; ldconfig`
Something about the library path is messed up, as oxenstored fails when
launched by systemd. It needs the shared library libxenctrl.so.4.5 which
is located in the /usr/local/lib folder, but doesn't find it.


Julian Sivertsen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 00:57:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 00: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 1Y1POX-0002qi-B1; Thu, 18 Dec 2014 00:56:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y1POV-0002qb-6C
	for xen-devel@lists.xensource.com; Thu, 18 Dec 2014 00:56:43 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	CB/17-08051-A4622945; Thu, 18 Dec 2014 00:56:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418864199!15813143!1
X-Originating-IP: [66.165.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 25826 invoked from network); 18 Dec 2014 00:56:40 -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;
	18 Dec 2014 00:56:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,597,1413244800"; d="scan'208";a="205601007"
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.210.2; Wed, 17 Dec 2014 19:56: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 1Y1POP-0001fR-Jq;
	Thu, 18 Dec 2014 00:56:37 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1POP-0008RK-F5;
	Thu, 18 Dec 2014 00:56:37 +0000
Date: Thu, 18 Dec 2014 00:56:37 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32432-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] 32432: 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 32432 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32432/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          0a0e61c12101ca4fe48da63f09971bccd331819c
baseline version:
 rumpuserxen          2c9e812bc368cb68a6249b99b1fb51ef3299d81c

------------------------------------------------------------
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=0a0e61c12101ca4fe48da63f09971bccd331819c
+ . 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 0a0e61c12101ca4fe48da63f09971bccd331819c
+ branch=rumpuserxen
+ revision=0a0e61c12101ca4fe48da63f09971bccd331819c
+ . 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 0a0e61c12101ca4fe48da63f09971bccd331819c:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   2c9e812..0a0e61c  0a0e61c12101ca4fe48da63f09971bccd331819c -> 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 Thu Dec 18 00:57:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 00: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 1Y1POX-0002qi-B1; Thu, 18 Dec 2014 00:56:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y1POV-0002qb-6C
	for xen-devel@lists.xensource.com; Thu, 18 Dec 2014 00:56:43 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	CB/17-08051-A4622945; Thu, 18 Dec 2014 00:56:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418864199!15813143!1
X-Originating-IP: [66.165.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 25826 invoked from network); 18 Dec 2014 00:56:40 -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;
	18 Dec 2014 00:56:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,597,1413244800"; d="scan'208";a="205601007"
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.210.2; Wed, 17 Dec 2014 19:56: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 1Y1POP-0001fR-Jq;
	Thu, 18 Dec 2014 00:56:37 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1POP-0008RK-F5;
	Thu, 18 Dec 2014 00:56:37 +0000
Date: Thu, 18 Dec 2014 00:56:37 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32432-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] 32432: 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 32432 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32432/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          0a0e61c12101ca4fe48da63f09971bccd331819c
baseline version:
 rumpuserxen          2c9e812bc368cb68a6249b99b1fb51ef3299d81c

------------------------------------------------------------
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=0a0e61c12101ca4fe48da63f09971bccd331819c
+ . 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 0a0e61c12101ca4fe48da63f09971bccd331819c
+ branch=rumpuserxen
+ revision=0a0e61c12101ca4fe48da63f09971bccd331819c
+ . 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 0a0e61c12101ca4fe48da63f09971bccd331819c:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   2c9e812..0a0e61c  0a0e61c12101ca4fe48da63f09971bccd331819c -> 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 Thu Dec 18 01:13:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 01:13:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Pep-0007dI-LY; Thu, 18 Dec 2014 01:13:35 +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 1Y1Peo-0007dD-HI
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 01:13:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	54/C6-09842-D3A22945; Thu, 18 Dec 2014 01:13:33 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418865210!16327083!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 25903 invoked from network); 18 Dec 2014 01:13:31 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-21.messagelabs.com with SMTP;
	18 Dec 2014 01:13:31 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 17 Dec 2014 17:13:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,597,1413270000"; d="scan'208";a="639374075"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by fmsmga001.fm.intel.com with ESMTP; 17 Dec 2014 17:13:06 -0800
Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 18 Dec 2014 09:12:55 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 18 Dec 2014 09:12:54 +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; Thu, 18 Dec 2014 09:12:53 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Julien Grall <julien.grall@linaro.org>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Thread-Topic: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
	to	describe device
Thread-Index: AQHQGW4Bxvp5T7zYHkWMtDRFPAyZTJyUirMQ
Date: Thu, 18 Dec 2014 01:12:53 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0AC04044@SHSMSX104.ccr.corp.intel.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1418760534-18163-8-git-send-email-julien.grall@linaro.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"manish.jaggi@caviumnetworks.com" <manish.jaggi@caviumnetworks.com>,
	"tim@xen.org" <tim@xen.org>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to	describe 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

Julien Grall wrote on 2014-12-17:
> diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h index
> 5f295f3..6ace79d 100644
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -13,6 +13,7 @@
>  #include <xen/irq.h> #include <xen/pci_regs.h> #include <xen/pfn.h>
>  +#include <xen/device.h> #include <asm/pci.h>
>  
>  /* @@ -75,8 +76,19 @@ struct pci_dev { #define PT_FAULT_THRESHOLD 10
>      } fault;
>      u64 vf_rlen[6];
> +
> +    struct device dev;
>  };
> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
> +
> +static inline struct pci_dev *dev_to_pci(struct device *dev) {
> +    ASSERT(dev->type == DEV_PCI);
> +
> +    return container_of(dev, struct pci_dev, dev); }
> +
>  #define for_each_pdev(domain, pdev) \
>      list_for_each_entry(pdev, &(domain->arch.pdev_list), domain_list)

I'd suggest splitting the changes to common code to a separate patch and also CC the VT-d/AMD maintainers. Because I didn't find those definitions when reviewing the 8th patch and I need to search the whole patch set to find them.

Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 01:13:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 01:13:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Pep-0007dI-LY; Thu, 18 Dec 2014 01:13:35 +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 1Y1Peo-0007dD-HI
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 01:13:34 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	54/C6-09842-D3A22945; Thu, 18 Dec 2014 01:13:33 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418865210!16327083!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 25903 invoked from network); 18 Dec 2014 01:13:31 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-21.messagelabs.com with SMTP;
	18 Dec 2014 01:13:31 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 17 Dec 2014 17:13:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,597,1413270000"; d="scan'208";a="639374075"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by fmsmga001.fm.intel.com with ESMTP; 17 Dec 2014 17:13:06 -0800
Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 18 Dec 2014 09:12:55 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 18 Dec 2014 09:12:54 +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; Thu, 18 Dec 2014 09:12:53 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Julien Grall <julien.grall@linaro.org>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Thread-Topic: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
	to	describe device
Thread-Index: AQHQGW4Bxvp5T7zYHkWMtDRFPAyZTJyUirMQ
Date: Thu, 18 Dec 2014 01:12:53 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0AC04044@SHSMSX104.ccr.corp.intel.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
In-Reply-To: <1418760534-18163-8-git-send-email-julien.grall@linaro.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"manish.jaggi@caviumnetworks.com" <manish.jaggi@caviumnetworks.com>,
	"tim@xen.org" <tim@xen.org>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to	describe 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

Julien Grall wrote on 2014-12-17:
> diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h index
> 5f295f3..6ace79d 100644
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -13,6 +13,7 @@
>  #include <xen/irq.h> #include <xen/pci_regs.h> #include <xen/pfn.h>
>  +#include <xen/device.h> #include <asm/pci.h>
>  
>  /* @@ -75,8 +76,19 @@ struct pci_dev { #define PT_FAULT_THRESHOLD 10
>      } fault;
>      u64 vf_rlen[6];
> +
> +    struct device dev;
>  };
> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
> +
> +static inline struct pci_dev *dev_to_pci(struct device *dev) {
> +    ASSERT(dev->type == DEV_PCI);
> +
> +    return container_of(dev, struct pci_dev, dev); }
> +
>  #define for_each_pdev(domain, pdev) \
>      list_for_each_entry(pdev, &(domain->arch.pdev_list), domain_list)

I'd suggest splitting the changes to common code to a separate patch and also CC the VT-d/AMD maintainers. Because I didn't find those definitions when reviewing the 8th patch and I need to search the whole patch set to find them.

Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 01:22:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 01: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 1Y1PnL-0007p8-Qy; Thu, 18 Dec 2014 01:22: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 1Y1PnK-0007p3-VF
	for xen-devel@lists.xensource.com; Thu, 18 Dec 2014 01:22:23 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	65/66-02953-E4C22945; Thu, 18 Dec 2014 01:22:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418865739!15766944!1
X-Originating-IP: [66.165.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 20097 invoked from network); 18 Dec 2014 01:22:21 -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 Dec 2014 01:22:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,597,1413244800"; d="scan'208";a="205614788"
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.210.2; Wed, 17 Dec 2014 20:22: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 1Y1PnG-0001oL-LV;
	Thu, 18 Dec 2014 01:22:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1PnG-0007dX-GN;
	Thu, 18 Dec 2014 01:22:18 +0000
Date: Thu, 18 Dec 2014 01:22:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32429-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 13566
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32429: 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="===============8814590383013085818=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8814590383013085818==
Content-Type: text/plain
Content-Length: 13370
Content-Transfer-Encoding: quoted-printable

flight 32429 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32429/

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 32418

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-armhf-armhf-xl          10 migrate-support-check        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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                d86fb03469e016af4e54f04efccbc20a8afa3e19
baseline version:
 qemuu                54600752a1dd67844c2cf3c467db562c39499838

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Amit Shah <amit.shah@redhat.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Drew DeVault <sir@cmpwn.com>
  Drew DeVault <sircmpwn@gmail.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Kevin O'Connor <kevin@koconnor.net>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Markus Armbruster <armbru@redhat.com>
  Michael S. Tsirkin <mst@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Maydell <peter.maydell@linaro.org>
  Wanpeng Li <wanpeng.li@linux.intel.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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


Pushing revision :

+ branch=3Dqemu-mainline
+ revision=3Dd86fb03469e016af4e54f04efccbc20a8afa3e19
+ . 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-mainline d86fb03469e016af4e54f04efccbc20a8afa3e19
+ branch=3Dqemu-mainline
+ revision=3Dd86fb03469e016af4e54f04efccbc20a8afa3e19
+ . 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
+ qemuubranch=3Dqemu-mainline
+ '[' xqemuu =3D xlinux ']'
+ linuxbranch=3D
+ '[' xqemu-mainline =3D 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=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-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=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-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 d86fb03469e016af4e54f04efccbc20a8afa3e19:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   5460075..d86fb03  d86fb03469e016af4e54f04efccbc20a8afa3e19 -> mainline/xen-tested-master


--===============8814590383013085818==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8814590383013085818==--

From xen-devel-bounces@lists.xen.org Thu Dec 18 01:22:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 01: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 1Y1PnL-0007p8-Qy; Thu, 18 Dec 2014 01:22: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 1Y1PnK-0007p3-VF
	for xen-devel@lists.xensource.com; Thu, 18 Dec 2014 01:22:23 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	65/66-02953-E4C22945; Thu, 18 Dec 2014 01:22:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418865739!15766944!1
X-Originating-IP: [66.165.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 20097 invoked from network); 18 Dec 2014 01:22:21 -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 Dec 2014 01:22:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,597,1413244800"; d="scan'208";a="205614788"
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.210.2; Wed, 17 Dec 2014 20:22: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 1Y1PnG-0001oL-LV;
	Thu, 18 Dec 2014 01:22:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1PnG-0007dX-GN;
	Thu, 18 Dec 2014 01:22:18 +0000
Date: Thu, 18 Dec 2014 01:22:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32429-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 13566
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32429: 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="===============8814590383013085818=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8814590383013085818==
Content-Type: text/plain
Content-Length: 13370
Content-Transfer-Encoding: quoted-printable

flight 32429 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32429/

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 32418

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-armhf-armhf-xl          10 migrate-support-check        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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                d86fb03469e016af4e54f04efccbc20a8afa3e19
baseline version:
 qemuu                54600752a1dd67844c2cf3c467db562c39499838

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Amit Shah <amit.shah@redhat.com>
  Aurelien Jarno <aurelien@aurel32.net>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Dr. David Alan Gilbert <dgilbert@redhat.com>
  Drew DeVault <sir@cmpwn.com>
  Drew DeVault <sircmpwn@gmail.com>
  Eduardo Habkost <ehabkost@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.com>
  Kevin O'Connor <kevin@koconnor.net>
  Marc-Andr=C3=A9 Lureau <marcandre.lureau@gmail.com>
  Markus Armbruster <armbru@redhat.com>
  Michael S. Tsirkin <mst@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
  Peter Maydell <peter.maydell@linaro.org>
  Wanpeng Li <wanpeng.li@linux.intel.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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


Pushing revision :

+ branch=3Dqemu-mainline
+ revision=3Dd86fb03469e016af4e54f04efccbc20a8afa3e19
+ . 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-mainline d86fb03469e016af4e54f04efccbc20a8afa3e19
+ branch=3Dqemu-mainline
+ revision=3Dd86fb03469e016af4e54f04efccbc20a8afa3e19
+ . 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
+ qemuubranch=3Dqemu-mainline
+ '[' xqemuu =3D xlinux ']'
+ linuxbranch=3D
+ '[' xqemu-mainline =3D 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=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-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=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-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 d86fb03469e016af4e54f04efccbc20a8afa3e19:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   5460075..d86fb03  d86fb03469e016af4e54f04efccbc20a8afa3e19 -> mainline/xen-tested-master


--===============8814590383013085818==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8814590383013085818==--

From xen-devel-bounces@lists.xen.org Thu Dec 18 01:56:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 01: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 1Y1QJy-0000fA-TS; Thu, 18 Dec 2014 01:56:06 +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 1Y1QJt-0000f5-6N
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 01:56:02 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	97/B5-07724-03432945; Thu, 18 Dec 2014 01:56:00 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418867758!9761184!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32662 invoked from network); 18 Dec 2014 01:55:59 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 01:55:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1418867759; x=1450403759;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=RCdzsUwNHv/Ra5xEqRHKShEkBxjtTNRY0YSsGZAyC9c=;
	b=I2Tw5KSRS1V+qBkZ2piRum65x5wTR0OxVAGTrszH5tYRYXQABRXypMCH
	b+C8gYsi0TJvCNdx1OwQ5KDQVujZfI5Qed9ky3ujp0x0pa2yjC0u2kVXY
	Or+evGxuWPFg/j62RNSRokquUbSvOttx20O0U/eiiP3npR4I7fY3vUlWj o=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 18 Dec 2014 01:55:38 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,597,1413244800"; d="scan'208";a="896633393"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.105.11])
	by fldsmtpi03.verizon.com with ESMTP; 18 Dec 2014 01:55:37 +0000
Message-ID: <54923419.3070902@terremark.com>
Date: Wed, 17 Dec 2014 20:55:37 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
References: <548740C4020000780004E471@mail.emea.novell.com>
	<1418299722.10394.29.camel@eu.citrix.com>
In-Reply-To: <1418299722.10394.29.camel@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xenproject.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 07:08, Ian Campbell wrote:
> On Tue, 2014-12-09 at 17:34 +0000, Jan Beulich wrote:
>> ... when "conring_size=" was specified on the command line. We can't
>> really do this as early as we would want to when the option was not
>> specified, as the default depends on knowing the system CPU count. Yet
>> the parsing of the ACPI tables is one of the things that generates a
>> lot of output especially on large systems.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com> (ARM  and generic bits)
> 

This change looks good to me, so:

Reviewed-by: Don Slutz <dslutz@verizon.com>

  -Don Slutz

>> ---
>> v2: Also adjust ARM (as requested by Julien). Rename new function to
>>     console_init_ring().
>>
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -745,6 +745,7 @@ void __init start_xen(unsigned long boot
>>  
>>      dt_uart_init();
>>      console_init_preirq();
>> +    console_init_ring();
>>  
>>      system_state = SYS_STATE_boot;
>>  
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1187,6 +1187,7 @@ void __init noreturn __start_xen(unsigne
>>      }
>>  
>>      vm_init();
>> +    console_init_ring();
>>      vesa_init();
>>  
>>      softirq_init();
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -744,15 +744,14 @@ void __init console_init_preirq(void)
>>      }
>>  }
>>  
>> -void __init console_init_postirq(void)
>> +void __init console_init_ring(void)
>>  {
>>      char *ring;
>>      unsigned int i, order, memflags;
>> -
>> -    serial_init_postirq();
>> +    unsigned long flags;
>>  
>>      if ( !opt_conring_size )
>> -        opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>> +        return;
>>  
>>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
>>      memflags = MEMF_bits(crashinfo_maxaddr_bits);
>> @@ -763,17 +762,30 @@ void __init console_init_postirq(void)
>>      }
>>      opt_conring_size = PAGE_SIZE << order;
>>  
>> -    spin_lock_irq(&console_lock);
>> +    spin_lock_irqsave(&console_lock, flags);
>>      for ( i = conringc ; i != conringp; i++ )
>>          ring[i & (opt_conring_size - 1)] = conring[i & (conring_size - 1)];
>>      conring = ring;
>>      smp_wmb(); /* Allow users of console_force_unlock() to see larger buffer. */
>>      conring_size = opt_conring_size;
>> -    spin_unlock_irq(&console_lock);
>> +    spin_unlock_irqrestore(&console_lock, flags);
>>  
>>      printk("Allocated console ring of %u KiB.\n", opt_conring_size >> 10);
>>  }
>>  
>> +void __init console_init_postirq(void)
>> +{
>> +    serial_init_postirq();
>> +
>> +    if ( conring != _conring )
>> +        return;
>> +
>> +    if ( !opt_conring_size )
>> +        opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>> +
>> +    console_init_ring();
>> +}
>> +
>>  void __init console_endboot(void)
>>  {
>>      int i, j;
>> --- a/xen/include/xen/console.h
>> +++ b/xen/include/xen/console.h
>> @@ -14,6 +14,7 @@ struct xen_sysctl_readconsole;
>>  long read_console_ring(struct xen_sysctl_readconsole *op);
>>  
>>  void console_init_preirq(void);
>> +void console_init_ring(void);
>>  void console_init_postirq(void);
>>  void console_endboot(void);
>>  int console_has(const char *device);
>>
>>
>>
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 18 01:56:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 01: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 1Y1QJy-0000fA-TS; Thu, 18 Dec 2014 01:56:06 +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 1Y1QJt-0000f5-6N
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 01:56:02 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	97/B5-07724-03432945; Thu, 18 Dec 2014 01:56:00 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418867758!9761184!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32662 invoked from network); 18 Dec 2014 01:55:59 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 01:55:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1418867759; x=1450403759;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=RCdzsUwNHv/Ra5xEqRHKShEkBxjtTNRY0YSsGZAyC9c=;
	b=I2Tw5KSRS1V+qBkZ2piRum65x5wTR0OxVAGTrszH5tYRYXQABRXypMCH
	b+C8gYsi0TJvCNdx1OwQ5KDQVujZfI5Qed9ky3ujp0x0pa2yjC0u2kVXY
	Or+evGxuWPFg/j62RNSRokquUbSvOttx20O0U/eiiP3npR4I7fY3vUlWj o=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 18 Dec 2014 01:55:38 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,597,1413244800"; d="scan'208";a="896633393"
Received: from unknown (HELO don-760.CloudSwitch.com) ([70.105.105.11])
	by fldsmtpi03.verizon.com with ESMTP; 18 Dec 2014 01:55:37 +0000
Message-ID: <54923419.3070902@terremark.com>
Date: Wed, 17 Dec 2014 20:55:37 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
References: <548740C4020000780004E471@mail.emea.novell.com>
	<1418299722.10394.29.camel@eu.citrix.com>
In-Reply-To: <1418299722.10394.29.camel@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xenproject.org>,
	Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] console: allocate ring buffer earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/11/14 07:08, Ian Campbell wrote:
> On Tue, 2014-12-09 at 17:34 +0000, Jan Beulich wrote:
>> ... when "conring_size=" was specified on the command line. We can't
>> really do this as early as we would want to when the option was not
>> specified, as the default depends on knowing the system CPU count. Yet
>> the parsing of the ACPI tables is one of the things that generates a
>> lot of output especially on large systems.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com> (ARM  and generic bits)
> 

This change looks good to me, so:

Reviewed-by: Don Slutz <dslutz@verizon.com>

  -Don Slutz

>> ---
>> v2: Also adjust ARM (as requested by Julien). Rename new function to
>>     console_init_ring().
>>
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -745,6 +745,7 @@ void __init start_xen(unsigned long boot
>>  
>>      dt_uart_init();
>>      console_init_preirq();
>> +    console_init_ring();
>>  
>>      system_state = SYS_STATE_boot;
>>  
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1187,6 +1187,7 @@ void __init noreturn __start_xen(unsigne
>>      }
>>  
>>      vm_init();
>> +    console_init_ring();
>>      vesa_init();
>>  
>>      softirq_init();
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -744,15 +744,14 @@ void __init console_init_preirq(void)
>>      }
>>  }
>>  
>> -void __init console_init_postirq(void)
>> +void __init console_init_ring(void)
>>  {
>>      char *ring;
>>      unsigned int i, order, memflags;
>> -
>> -    serial_init_postirq();
>> +    unsigned long flags;
>>  
>>      if ( !opt_conring_size )
>> -        opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>> +        return;
>>  
>>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
>>      memflags = MEMF_bits(crashinfo_maxaddr_bits);
>> @@ -763,17 +762,30 @@ void __init console_init_postirq(void)
>>      }
>>      opt_conring_size = PAGE_SIZE << order;
>>  
>> -    spin_lock_irq(&console_lock);
>> +    spin_lock_irqsave(&console_lock, flags);
>>      for ( i = conringc ; i != conringp; i++ )
>>          ring[i & (opt_conring_size - 1)] = conring[i & (conring_size - 1)];
>>      conring = ring;
>>      smp_wmb(); /* Allow users of console_force_unlock() to see larger buffer. */
>>      conring_size = opt_conring_size;
>> -    spin_unlock_irq(&console_lock);
>> +    spin_unlock_irqrestore(&console_lock, flags);
>>  
>>      printk("Allocated console ring of %u KiB.\n", opt_conring_size >> 10);
>>  }
>>  
>> +void __init console_init_postirq(void)
>> +{
>> +    serial_init_postirq();
>> +
>> +    if ( conring != _conring )
>> +        return;
>> +
>> +    if ( !opt_conring_size )
>> +        opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>> +
>> +    console_init_ring();
>> +}
>> +
>>  void __init console_endboot(void)
>>  {
>>      int i, j;
>> --- a/xen/include/xen/console.h
>> +++ b/xen/include/xen/console.h
>> @@ -14,6 +14,7 @@ struct xen_sysctl_readconsole;
>>  long read_console_ring(struct xen_sysctl_readconsole *op);
>>  
>>  void console_init_preirq(void);
>> +void console_init_ring(void);
>>  void console_init_postirq(void);
>>  void console_endboot(void);
>>  int console_has(const char *device);
>>
>>
>>
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 18 02:54:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 02: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 1Y1RE8-0002y2-Qg; Thu, 18 Dec 2014 02:54:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kaih.linux@gmail.com>) id 1Y1RE7-0002xu-J0
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 02:54:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4A/F6-25276-EC142945; Thu, 18 Dec 2014 02:54:06 +0000
X-Env-Sender: kaih.linux@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418871245!16348412!1
X-Originating-IP: [209.85.214.193]
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 32277 invoked from network); 18 Dec 2014 02:54:06 -0000
Received: from mail-ob0-f193.google.com (HELO mail-ob0-f193.google.com)
	(209.85.214.193)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 02:54:06 -0000
Received: by mail-ob0-f193.google.com with SMTP id va2so184555obc.0
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 18:54:05 -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=hXlY+ueNMZZk7KvJiB/WiKlj7ks7O9gdo2E1gFUuDao=;
	b=t0usQDgtp9fRon7eF/XR30AYhGbflOBWtPVRtbhmXuJeWBc6HXqsmJM/hycFojDJ91
	5/a/YqB5KRBPoH7fG+ILLdeWXh0rMZFc/C38l77pscQWBEWrS4WZ5A/55w/t+0hJ4SO6
	yX9xXmTGE+VS3sQ9ypDo6wOV3pYjBvMZ2ipO5ifELFYrCeljMoWxirHrNL2x5t7QuHMC
	jt6NfWg+ZhVVOoCrDLodgffv0XA9NjwCTaDCCp8PG2t1PLQGPWC4sYn0J7dbBwcn8z31
	R4MHkMvPNnwmxtE3Im3dn+Fq7SxkfY3MnT9lcpzSuEZnRobt5/Xr4x3NpJU/+WcD8mee
	+F0Q==
MIME-Version: 1.0
X-Received: by 10.202.0.7 with SMTP id 7mr26513716oia.96.1418871245023; Wed,
	17 Dec 2014 18:54:05 -0800 (PST)
Received: by 10.202.196.8 with HTTP; Wed, 17 Dec 2014 18:54:04 -0800 (PST)
Date: Thu, 18 Dec 2014 10:54:04 +0800
Message-ID: <CAB+V_5N8ZYBntz57yF=hWaugOHaC_XQLKgv9v-K5LeMK7nDmsA@mail.gmail.com>
From: Kai Huang <kaih.linux@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] XL doesn't work on latest upstream Xen?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 built and installed Xen from latest upstream Xen source code, but XL
always failed to work. Do you know what's going on here? My
environment is Lubuntu 14.04. Thanks in advance.

I always got "Permission denied" error.

root@kai-haswell:~# xl list
libxl: error: libxl.c:561:libxl_list_domain: geting domain info list:
Permission denied
libxl_list_domain failed.

xenstore looks is working fine after I manually start
/etc/init.d/xencommons services.

root@kai-haswell:~# xenstore-ls
tool = ""
 xenstored = ""
local = ""
 domain = ""
  0 = ""
   domid = "0"
   name = "Domain-0"
   device-model = ""
    0 = ""
     state = "running"

-- 
Thanks,
-Kai

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 02:54:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 02: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 1Y1RE8-0002y2-Qg; Thu, 18 Dec 2014 02:54:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kaih.linux@gmail.com>) id 1Y1RE7-0002xu-J0
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 02:54:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4A/F6-25276-EC142945; Thu, 18 Dec 2014 02:54:06 +0000
X-Env-Sender: kaih.linux@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418871245!16348412!1
X-Originating-IP: [209.85.214.193]
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 32277 invoked from network); 18 Dec 2014 02:54:06 -0000
Received: from mail-ob0-f193.google.com (HELO mail-ob0-f193.google.com)
	(209.85.214.193)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 02:54:06 -0000
Received: by mail-ob0-f193.google.com with SMTP id va2so184555obc.0
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 18:54:05 -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=hXlY+ueNMZZk7KvJiB/WiKlj7ks7O9gdo2E1gFUuDao=;
	b=t0usQDgtp9fRon7eF/XR30AYhGbflOBWtPVRtbhmXuJeWBc6HXqsmJM/hycFojDJ91
	5/a/YqB5KRBPoH7fG+ILLdeWXh0rMZFc/C38l77pscQWBEWrS4WZ5A/55w/t+0hJ4SO6
	yX9xXmTGE+VS3sQ9ypDo6wOV3pYjBvMZ2ipO5ifELFYrCeljMoWxirHrNL2x5t7QuHMC
	jt6NfWg+ZhVVOoCrDLodgffv0XA9NjwCTaDCCp8PG2t1PLQGPWC4sYn0J7dbBwcn8z31
	R4MHkMvPNnwmxtE3Im3dn+Fq7SxkfY3MnT9lcpzSuEZnRobt5/Xr4x3NpJU/+WcD8mee
	+F0Q==
MIME-Version: 1.0
X-Received: by 10.202.0.7 with SMTP id 7mr26513716oia.96.1418871245023; Wed,
	17 Dec 2014 18:54:05 -0800 (PST)
Received: by 10.202.196.8 with HTTP; Wed, 17 Dec 2014 18:54:04 -0800 (PST)
Date: Thu, 18 Dec 2014 10:54:04 +0800
Message-ID: <CAB+V_5N8ZYBntz57yF=hWaugOHaC_XQLKgv9v-K5LeMK7nDmsA@mail.gmail.com>
From: Kai Huang <kaih.linux@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] XL doesn't work on latest upstream Xen?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 built and installed Xen from latest upstream Xen source code, but XL
always failed to work. Do you know what's going on here? My
environment is Lubuntu 14.04. Thanks in advance.

I always got "Permission denied" error.

root@kai-haswell:~# xl list
libxl: error: libxl.c:561:libxl_list_domain: geting domain info list:
Permission denied
libxl_list_domain failed.

xenstore looks is working fine after I manually start
/etc/init.d/xencommons services.

root@kai-haswell:~# xenstore-ls
tool = ""
 xenstored = ""
local = ""
 domain = ""
  0 = ""
   domid = "0"
   name = "Domain-0"
   device-model = ""
    0 = ""
     state = "running"

-- 
Thanks,
-Kai

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 03:01:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 03:01:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1RLM-00038T-Pz; Thu, 18 Dec 2014 03:01:36 +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 1Y1RLK-00038O-Rf
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 03:01:35 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	DE/CD-08051-E8342945; Thu, 18 Dec 2014 03:01:34 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418871690!10372995!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1162 invoked from network); 18 Dec 2014 03:01:32 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 03:01:32 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 20:01:29 -0700
Message-Id: <5492B40102000066000863B9@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 20:01:21 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
	<20141217140958.GH1904@zion.uk.xensource.com>
In-Reply-To: <20141217140958.GH1904@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jim Fehlig <JFEHLIG@suse.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/17/2014 at 10:09 PM, in message
<20141217140958.GH1904@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
wrote: 
> On Tue, Dec 16, 2014 at 02:32:57PM +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * remove libxl_domain_snapshot_create/delete/revert API 
> >   * export disk snapshot functionality for both xl and libvirt usage 
> >  
> > =========================================================================== 
> > Libxl/libxlu Design 
> >  
> > 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), 
> >     ]) 
> >  
>  
> So you don't propose making libxl to have knowledge of the snapshot 
> chains? 
Right.

> And in libvirt (or other toolstack that's interested in snapshot 
> management) you represent a snapshot as chains (or trees) of 
> libxl_disk_snapshot? (Not suggesting you do things the other way around, 
> just to confirm) 

Libvirt has its own data structure to manage domain snapshots. libxl_disk_snapshot
is only used by libvirt to call libxl API to do disk snapshot work for it. In libvirt,
it has other data structure to represent disk snapshot information.


>  
> >  
> > 2. New Functions 
> >  
> > Since there're already APIs for saving memory (libxl_domain_suspend) 
> > and restoring domain from saved memory (libxl_domain_create_restore), to 
> > xl domain snapshot tasks, the missing part is disk snapshot functionality. 
> > And the disk snapshot functionality would be used by libvirt too. 
> >  
> > Considering there is qmp handling in creating/deleting disk snapshot, 
> > will add following new functions to libxl (?): 
> >  
> > int libxl_disk_snapshot_create(libxl_ctx *ctx, uint32_t domid, 
> >                                libxl_disk_snapshot *snapshot, int nb); 
> >  
> >     Taking disk snapshots to a group of domain disks according to 
> >     configuration. For qcow2 disk backend type, it will call qmp 
> >     "transaction" command to do the work. For other disk backend types, 
> >     might call other external commands. 
> >  
> >     Parameters: 
> >        ctx (INPUT): 
> >            context 
> >        domid (INPUT): 
> >            domain id 
> >        snapshot (INPUT): 
> >            array of disk snapshot configuration. Has "nb" members. 
> >  
> >            libxl_device_disk: 
> >                structure to represent which disk. 
> >            name: 
> >                snapshot name. 
> >            external: 
> >                internal snapshot or external snapshot. 
> >                '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. 
> >        nb (INPUT): 
> >            number of disks that need to take disk snapshot. 
> >  
> >     Return: 
> >        0 on success, -1 on error. 
> >  
>  
> It should return appropriate libxl error code (ERROR_*) on error. 

Thanks. That's better.

>  
> >  
> > /*  This API might not be used by xl, since xl won't take care of deleting 
> >  *  snapshots. But for libvirt, since libvirt manages snapshots and will 
> >  *  delete snapshot, this API will be used. 
> >  */ 
> > int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid, 
> >                                libxl_disk_snapshot *snapshot, int nb); 
> >  
> >     Delete disk snapshot of a group of domain disks according to 
> >     configuration. For qcow2 disk backend type, it will call qmp command 
> >     to delete internal disk snapshot. For other disk backend types, might 
> >     call other external commands. 
> >  
> >     Parameters: 
> >        ctx (INPUT): 
> >            context 
> >        domid (INPUT): 
> >            domain id 
> >        snapshot (INPUT): 
> >            array of disk snapshot configuration. Has "nb" members. 
> >        nb (INPUT): 
> >            number of disks that need to take disk snapshot. 
> >  
> >     Return: 
> >        0 on success, -1 on error. 
> >  
> >  
> > int libxl_disk_to_snapshot(libxl_ctx *ctx, uint32_t domid, 
> >                            libxl_disk_snapshot **snapshot, int *num); 
> >  
> >     This is for domain snapshot create. If user doesn't specify disks, 
> >     then by default it will take internal disk snapshot to each domain 
> >     disk. This function will fill libxl_disk_snapshot according to domain 
> >     disks info. 
> >  
> >     Parameters: 
> >        ctx (INPUT): 
> >            context 
> >        domid (INPUT): 
> >            domain id 
> >        snapshot (OUTPUT): 
> >            array of disk snapshot configuration. 
> >        num (OUTPUT): 
> >            number of disks. 
> >  
> >     Return: 
> >        0 on success, -1 on error. 
> >  
> >  
> >  
> > For disk snapshot revert, no qmp command for that, it always calls 
> > external commands to finish the work, so put in libxlu (?): 
> >  
> > int xlu_disk_snapshot_revert(libxl_disk_snapshot *snapshot, int nb); 
> >  
>  
> IMHO it's fine for this to be in libxl. Calling out to other programs 
> is fine. 

OK. Thanks. Then we can put all disk snapshot APIs in libxl.

>  
> Wei. 
>  
> >     Apply disk snapshot for a group of disks according to configuration. To 
> >     different disk backend types, call different external commands to do 
> >     the work. 
> >  
> >     Parameters: 
> >        snapshot (INPUT): 
> >            array of disk snapshot configuration. Has "nb" members. 
> >        nb (INPUT): 
> >            number of disks that need to take disk snapshot. 
> >  
> >     Return: 
> >        0 on success, -1 on error. 
> >  
> >  
> >  
> > 3. Simple Architecture View 
> >  
> > Creating domain snapshot: 
> > (* means new functions we will need in libxl/libxlu) 
> >  
> >   "xl snapshot-create" 
> >          | 
> >   parse configuration ----> libxl_disk_to_snapshot (*) 
> >          | 
> >   saving memory ----> libxl_domain_suspend 
> >          | 
> >  taking disk snapshot ----> libxl_disk_snapshot_create (*) 
> >          |                     | 
> >          |                     --> libxl_qmp_disk_snapshot_transaction (*) 
> >          | 
> >     unpause domain ---->libxl_domain_unpause 
> >          | 
> >         End 
> >  
> >  
> > Reverting to a snapshot: 
> > (* means new functions we will need in libxl/libxlu) 
> >  
> >   "xl snapshot-revert" 
> >          | 
> >    parse configuration 
> >          | 
> >    destroy domain ---->libxl_domain_destroy 
> >          | 
> >  reverting disk snapshot ----> xlu_disk_snapshot_revert (*) 
> >          |                       | 
> >          |                       --> call 'qemu-img' to apply disk snapshot 
> >          | 
> >  restore domain from saved memory ----> libxl_domain_create_restore 
> >          | 
> >         End 
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 03:01:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 03:01:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1RLM-00038T-Pz; Thu, 18 Dec 2014 03:01:36 +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 1Y1RLK-00038O-Rf
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 03:01:35 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	DE/CD-08051-E8342945; Thu, 18 Dec 2014 03:01:34 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418871690!10372995!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1162 invoked from network); 18 Dec 2014 03:01:32 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 03:01:32 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 20:01:29 -0700
Message-Id: <5492B40102000066000863B9@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 20:01:21 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
	<20141217140958.GH1904@zion.uk.xensource.com>
In-Reply-To: <20141217140958.GH1904@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jim Fehlig <JFEHLIG@suse.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/17/2014 at 10:09 PM, in message
<20141217140958.GH1904@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
wrote: 
> On Tue, Dec 16, 2014 at 02:32:57PM +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * remove libxl_domain_snapshot_create/delete/revert API 
> >   * export disk snapshot functionality for both xl and libvirt usage 
> >  
> > =========================================================================== 
> > Libxl/libxlu Design 
> >  
> > 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), 
> >     ]) 
> >  
>  
> So you don't propose making libxl to have knowledge of the snapshot 
> chains? 
Right.

> And in libvirt (or other toolstack that's interested in snapshot 
> management) you represent a snapshot as chains (or trees) of 
> libxl_disk_snapshot? (Not suggesting you do things the other way around, 
> just to confirm) 

Libvirt has its own data structure to manage domain snapshots. libxl_disk_snapshot
is only used by libvirt to call libxl API to do disk snapshot work for it. In libvirt,
it has other data structure to represent disk snapshot information.


>  
> >  
> > 2. New Functions 
> >  
> > Since there're already APIs for saving memory (libxl_domain_suspend) 
> > and restoring domain from saved memory (libxl_domain_create_restore), to 
> > xl domain snapshot tasks, the missing part is disk snapshot functionality. 
> > And the disk snapshot functionality would be used by libvirt too. 
> >  
> > Considering there is qmp handling in creating/deleting disk snapshot, 
> > will add following new functions to libxl (?): 
> >  
> > int libxl_disk_snapshot_create(libxl_ctx *ctx, uint32_t domid, 
> >                                libxl_disk_snapshot *snapshot, int nb); 
> >  
> >     Taking disk snapshots to a group of domain disks according to 
> >     configuration. For qcow2 disk backend type, it will call qmp 
> >     "transaction" command to do the work. For other disk backend types, 
> >     might call other external commands. 
> >  
> >     Parameters: 
> >        ctx (INPUT): 
> >            context 
> >        domid (INPUT): 
> >            domain id 
> >        snapshot (INPUT): 
> >            array of disk snapshot configuration. Has "nb" members. 
> >  
> >            libxl_device_disk: 
> >                structure to represent which disk. 
> >            name: 
> >                snapshot name. 
> >            external: 
> >                internal snapshot or external snapshot. 
> >                '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. 
> >        nb (INPUT): 
> >            number of disks that need to take disk snapshot. 
> >  
> >     Return: 
> >        0 on success, -1 on error. 
> >  
>  
> It should return appropriate libxl error code (ERROR_*) on error. 

Thanks. That's better.

>  
> >  
> > /*  This API might not be used by xl, since xl won't take care of deleting 
> >  *  snapshots. But for libvirt, since libvirt manages snapshots and will 
> >  *  delete snapshot, this API will be used. 
> >  */ 
> > int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid, 
> >                                libxl_disk_snapshot *snapshot, int nb); 
> >  
> >     Delete disk snapshot of a group of domain disks according to 
> >     configuration. For qcow2 disk backend type, it will call qmp command 
> >     to delete internal disk snapshot. For other disk backend types, might 
> >     call other external commands. 
> >  
> >     Parameters: 
> >        ctx (INPUT): 
> >            context 
> >        domid (INPUT): 
> >            domain id 
> >        snapshot (INPUT): 
> >            array of disk snapshot configuration. Has "nb" members. 
> >        nb (INPUT): 
> >            number of disks that need to take disk snapshot. 
> >  
> >     Return: 
> >        0 on success, -1 on error. 
> >  
> >  
> > int libxl_disk_to_snapshot(libxl_ctx *ctx, uint32_t domid, 
> >                            libxl_disk_snapshot **snapshot, int *num); 
> >  
> >     This is for domain snapshot create. If user doesn't specify disks, 
> >     then by default it will take internal disk snapshot to each domain 
> >     disk. This function will fill libxl_disk_snapshot according to domain 
> >     disks info. 
> >  
> >     Parameters: 
> >        ctx (INPUT): 
> >            context 
> >        domid (INPUT): 
> >            domain id 
> >        snapshot (OUTPUT): 
> >            array of disk snapshot configuration. 
> >        num (OUTPUT): 
> >            number of disks. 
> >  
> >     Return: 
> >        0 on success, -1 on error. 
> >  
> >  
> >  
> > For disk snapshot revert, no qmp command for that, it always calls 
> > external commands to finish the work, so put in libxlu (?): 
> >  
> > int xlu_disk_snapshot_revert(libxl_disk_snapshot *snapshot, int nb); 
> >  
>  
> IMHO it's fine for this to be in libxl. Calling out to other programs 
> is fine. 

OK. Thanks. Then we can put all disk snapshot APIs in libxl.

>  
> Wei. 
>  
> >     Apply disk snapshot for a group of disks according to configuration. To 
> >     different disk backend types, call different external commands to do 
> >     the work. 
> >  
> >     Parameters: 
> >        snapshot (INPUT): 
> >            array of disk snapshot configuration. Has "nb" members. 
> >        nb (INPUT): 
> >            number of disks that need to take disk snapshot. 
> >  
> >     Return: 
> >        0 on success, -1 on error. 
> >  
> >  
> >  
> > 3. Simple Architecture View 
> >  
> > Creating domain snapshot: 
> > (* means new functions we will need in libxl/libxlu) 
> >  
> >   "xl snapshot-create" 
> >          | 
> >   parse configuration ----> libxl_disk_to_snapshot (*) 
> >          | 
> >   saving memory ----> libxl_domain_suspend 
> >          | 
> >  taking disk snapshot ----> libxl_disk_snapshot_create (*) 
> >          |                     | 
> >          |                     --> libxl_qmp_disk_snapshot_transaction (*) 
> >          | 
> >     unpause domain ---->libxl_domain_unpause 
> >          | 
> >         End 
> >  
> >  
> > Reverting to a snapshot: 
> > (* means new functions we will need in libxl/libxlu) 
> >  
> >   "xl snapshot-revert" 
> >          | 
> >    parse configuration 
> >          | 
> >    destroy domain ---->libxl_domain_destroy 
> >          | 
> >  reverting disk snapshot ----> xlu_disk_snapshot_revert (*) 
> >          |                       | 
> >          |                       --> call 'qemu-img' to apply disk snapshot 
> >          | 
> >  restore domain from saved memory ----> libxl_domain_create_restore 
> >          | 
> >         End 
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 03:24:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 03: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 1Y1Rgv-0004An-4c; Thu, 18 Dec 2014 03:23:53 +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 1Y1Rgt-0004Ai-Um
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 03:23:52 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	92/2F-27623-7C842945; Thu, 18 Dec 2014 03:23:51 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418873028!14151630!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 31415 invoked from network); 18 Dec 2014 03:23:50 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 03:23:50 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 20:23:47 -0700
Message-Id: <5492B93D02000066000863D1@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 20:23:41 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
	<20141217122817.GG1904@zion.uk.xensource.com>
In-Reply-To: <20141217122817.GG1904@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jim Fehlig <JFEHLIG@suse.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 12/17/2014 at 08:28 PM, in message
<20141217122817.GG1904@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
wrote: 
> On Tue, Dec 16, 2014 at 02:32:56PM +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * xl won't manage snapshots, that means it won't maintain json files, 
> >     won't maintain snapshot chain relationship, and then as a result 
> >     won't take care of deleting snapshot and listing snapshots. 
> >   * remove snapshot-delete and snapshot-list interface 
> >   * update snapshot-revert interface 
> >   * update snapshot-create/revert implementaion 
> >  
> > =========================================================================== 
> >  
> > XL Design 
> >  
> > 1. User Interface 
> >  
> > 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, use cfgfile. (e.g. if --name specifies a name, 
> >     meanwhile there is name specified in cfgfile, name in cfgfile will 
> >     be used.) 
> >  
> >  
> > xl snapshot-revert: 
> >   Revert domain to status of a snapshot. 
> >  
> >   SYNOPSIS: 
> >       snapshot-revert <domain> <cfgfile> [--running] [--force] 
> >  
> >   OPTIONS: 
> >     --running        after reverting, change state to running 
> >     --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. 
> >  
> >  
> >  
> > 2. cfgfile syntax 
> >  
> > #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 
> > #For easier parse config work, reuse disk configuration in xl.cfg, but 
> > #with different meanings. 
> > #disk syntax meaning: 'external path, external format, target device' 
> >  
> > #e.g. to specify exernal disk snapshot, like this: 
> > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', 
> >         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] 
> >  
> > #e.g. to specify internal disk snapshot, like this: 
> > disks=[',,hda',',,hdb',] 
> >  
>  
> How is snapshot chain represented with this syntax? Does xl not need to 
> know about the chain? (Note, this is different than managing the chain) 

If only supply creating snapshot and restoring domain from a snapshot,
xl doesn't need to know the chain.

For creating snapshot, it's very easy to understand, no matter from base
or from a snapshot, saving memory and taking disk snapshot has no
difference. 

For restoring domain from snapshot, restoring memory has no difference;
applying disk snapshot, to those backend types we can expect:
qcow2 internal snapshot: no need to know chain
vhd, qcow2 external disk snapshot: both external disk snapshot, and 
both using backing file chain to implement, so apply disk snapshot
is very simple, just use the external snapshot file.
lvm: doesn't support snapshot of snapshot, so no such problem.
So, overall, it doesn't need to know the chain either.

> 
> Wei. 
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 03:24:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 03: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 1Y1Rgv-0004An-4c; Thu, 18 Dec 2014 03:23:53 +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 1Y1Rgt-0004Ai-Um
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 03:23:52 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	92/2F-27623-7C842945; Thu, 18 Dec 2014 03:23:51 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418873028!14151630!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 31415 invoked from network); 18 Dec 2014 03:23:50 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 03:23:50 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 20:23:47 -0700
Message-Id: <5492B93D02000066000863D1@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 20:23:41 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
	<20141217122817.GG1904@zion.uk.xensource.com>
In-Reply-To: <20141217122817.GG1904@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jim Fehlig <JFEHLIG@suse.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 12/17/2014 at 08:28 PM, in message
<20141217122817.GG1904@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
wrote: 
> On Tue, Dec 16, 2014 at 02:32:56PM +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * xl won't manage snapshots, that means it won't maintain json files, 
> >     won't maintain snapshot chain relationship, and then as a result 
> >     won't take care of deleting snapshot and listing snapshots. 
> >   * remove snapshot-delete and snapshot-list interface 
> >   * update snapshot-revert interface 
> >   * update snapshot-create/revert implementaion 
> >  
> > =========================================================================== 
> >  
> > XL Design 
> >  
> > 1. User Interface 
> >  
> > 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, use cfgfile. (e.g. if --name specifies a name, 
> >     meanwhile there is name specified in cfgfile, name in cfgfile will 
> >     be used.) 
> >  
> >  
> > xl snapshot-revert: 
> >   Revert domain to status of a snapshot. 
> >  
> >   SYNOPSIS: 
> >       snapshot-revert <domain> <cfgfile> [--running] [--force] 
> >  
> >   OPTIONS: 
> >     --running        after reverting, change state to running 
> >     --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. 
> >  
> >  
> >  
> > 2. cfgfile syntax 
> >  
> > #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 
> > #For easier parse config work, reuse disk configuration in xl.cfg, but 
> > #with different meanings. 
> > #disk syntax meaning: 'external path, external format, target device' 
> >  
> > #e.g. to specify exernal disk snapshot, like this: 
> > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', 
> >         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] 
> >  
> > #e.g. to specify internal disk snapshot, like this: 
> > disks=[',,hda',',,hdb',] 
> >  
>  
> How is snapshot chain represented with this syntax? Does xl not need to 
> know about the chain? (Note, this is different than managing the chain) 

If only supply creating snapshot and restoring domain from a snapshot,
xl doesn't need to know the chain.

For creating snapshot, it's very easy to understand, no matter from base
or from a snapshot, saving memory and taking disk snapshot has no
difference. 

For restoring domain from snapshot, restoring memory has no difference;
applying disk snapshot, to those backend types we can expect:
qcow2 internal snapshot: no need to know chain
vhd, qcow2 external disk snapshot: both external disk snapshot, and 
both using backing file chain to implement, so apply disk snapshot
is very simple, just use the external snapshot file.
lvm: doesn't support snapshot of snapshot, so no such problem.
So, overall, it doesn't need to know the chain either.

> 
> Wei. 
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 03:34:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 03: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 1Y1Rr4-0004e5-AZ; Thu, 18 Dec 2014 03:34:22 +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 1Y1Rr2-0004e0-Fg
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 03:34:20 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	D8/F9-02694-B3B42945; Thu, 18 Dec 2014 03:34:19 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418873656!15778020!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 23418 invoked from network); 18 Dec 2014 03:34:18 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 03:34:18 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 20:34:15 -0700
Message-Id: <5492BBAF02000066000863DD@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 20:34:07 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
	<20141217121750.GF1904@zion.uk.xensource.com>
In-Reply-To: <20141217121750.GF1904@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jim Fehlig <JFEHLIG@suse.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/17/2014 at 08:17 PM, in message
<20141217121750.GF1904@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
wrote: 
> On Tue, Dec 16, 2014 at 02:32:55PM +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * add an overview document, so that one can has a overall look 
> >     about the whole domain snapshot work, limits, requirements, 
> >     how to do, etc. 
> >  
> > ===================================================================== 
> > Domain snapshot overview 
> >  
> > 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 usually includes: 
> > a) create a domain snapshot 
> > b) roll back (or called "revert") to a domain snapshot 
> > c) delete a domain snapshot 
> > d) list all domain snapshots 
> >  
> > But following the existing xl idioms of managing storage and saved 
> > VM images via existing CLI command (qemu-img, lvcreate, ls, mv, 
> > cp etc), xl snapshot functionality would be kept as simple as 
> > possible: 
> > * xl will do a) and b), creating a snapshot and reverting a 
> >   domain to a snapshot. 
> > * xl will NOT do c) and d), xl won't manage snapshots, as xl 
> >   doesn't maintain saved images created by 'xl save'. So xl 
> >   will have no idea of the existence of domain snapshots and 
> >   the chain relationship between snapshots. It will depends on 
> >   user to take care of the snapshots, know the snapshot chain 
> >   info, and delete snapshots. 
> >  
> > Domain Snapshot Support and Not Support: 
>  
> I think this list applies to xl (last item and [1]). If so please state 
> clearly to prevent confusion with other toolstack (say, libvirt) and 
> functionalities of the library (libxl). 
>  
> > * support live snapshot 
> > * support internal disk snapshot and external disk snapshot 
> > * support different disk backend types. 
> >   (Basic goal is to support 'raw' and 'qcow2' only). 
> >  
> > * not support snapshot when domain is shutdowning or dying. 
> > * not support disk-only snapshot [1]. 
> >  
> >  [1] 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. 
> >  
>  
> I think I understand your reasoning, but it's a bit convoluted to me. 
>  
> Domain can be in both active and inactive state (libvirt term) when 
> using xl.  When domain is active, we cannot guarantee in xl that domain 
> is quiesced so a disk-only snapshot may contain inconsistent data.

That's right.

> When 
> domain is inactive, there's no point in taking a disk-only snapshot 
> because it would be the same as the base image.

xl doesn't have inactive domains. Libvirt has. (in libvirt, one can 'define'
a domain but not 'starte', like old xend which can 'new' a domain but not
'start' it.) xl only can 'create' a domain, when domain is shutdown, it's
not visible to user.

For inactive domain, disk-only snapshot is useful. Since later user
may run VM with base image and base image would change. Then the
disk-only snapshot is a usable backup.

That's why, libvirt can support disk-only snapshot, xl won't support
disk-only snapshot. Do I describe it clearly?

> So the conclusion is 
> that xl doesn't need to support disk-only snapshot. 
>  
> Does the above reasoning equals to yours? Is it clearer or more 
> confusing? 
>  
> Wei. 
>  
> >  
> > 2. Requirements 
> >  
> > General Requirements: 
> > * ability to save/restore domain memory 
> > * ability to create/delete/apply disk snapshot [2] 
> > * ability to parse user config file 
> >  
> >   [2] Disk snapshot requirements: 
> >   - external tools: qemu-img, lvcreate, vhd-util, etc. 
> >   - for basic goal, we support 'raw' and 'qcow2' backend types 
> >     only. Then it requires: 
> >     libxl qmp command or "qemu-img" (when qemu process does not 
> >     exist) 
> >  
> >  
> > 3. Interaction with other operations: 
> >  
> > No. 
> >  
> >  
> > 4. General workflow 
> >  
> > Create a snapshot: 
> >   * parse user cfg file if passed in 
> >   * check snapshot operation is allowed or not 
> >   * save domain, saving memory status to file (refer to: save_domain) 
> >   * take disk snapshot (e.g. call qmp command) 
> >   * unpause domain 
> >  
> > Revert to snapshot: 
> >   * parse use cfg file (xl doesn't manage snapshots, so it has no 
> >     idea of snapshot existence. User MUST supply configuration file) 
> >   * destroy this domain 
> >   * create a new domain from snapshot info 
> >     - apply disk snapshot (e.g. call qemu-img) 
> >     - a process like restore domain 
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 03:34:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 03: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 1Y1Rr4-0004e5-AZ; Thu, 18 Dec 2014 03:34:22 +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 1Y1Rr2-0004e0-Fg
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 03:34:20 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	D8/F9-02694-B3B42945; Thu, 18 Dec 2014 03:34:19 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1418873656!15778020!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 23418 invoked from network); 18 Dec 2014 03:34:18 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 03:34:18 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Wed, 17 Dec 2014 20:34:15 -0700
Message-Id: <5492BBAF02000066000863DD@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Wed, 17 Dec 2014 20:34:07 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
	<20141217121750.GF1904@zion.uk.xensource.com>
In-Reply-To: <20141217121750.GF1904@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jim Fehlig <JFEHLIG@suse.com>, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/17/2014 at 08:17 PM, in message
<20141217121750.GF1904@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
wrote: 
> On Tue, Dec 16, 2014 at 02:32:55PM +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * add an overview document, so that one can has a overall look 
> >     about the whole domain snapshot work, limits, requirements, 
> >     how to do, etc. 
> >  
> > ===================================================================== 
> > Domain snapshot overview 
> >  
> > 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 usually includes: 
> > a) create a domain snapshot 
> > b) roll back (or called "revert") to a domain snapshot 
> > c) delete a domain snapshot 
> > d) list all domain snapshots 
> >  
> > But following the existing xl idioms of managing storage and saved 
> > VM images via existing CLI command (qemu-img, lvcreate, ls, mv, 
> > cp etc), xl snapshot functionality would be kept as simple as 
> > possible: 
> > * xl will do a) and b), creating a snapshot and reverting a 
> >   domain to a snapshot. 
> > * xl will NOT do c) and d), xl won't manage snapshots, as xl 
> >   doesn't maintain saved images created by 'xl save'. So xl 
> >   will have no idea of the existence of domain snapshots and 
> >   the chain relationship between snapshots. It will depends on 
> >   user to take care of the snapshots, know the snapshot chain 
> >   info, and delete snapshots. 
> >  
> > Domain Snapshot Support and Not Support: 
>  
> I think this list applies to xl (last item and [1]). If so please state 
> clearly to prevent confusion with other toolstack (say, libvirt) and 
> functionalities of the library (libxl). 
>  
> > * support live snapshot 
> > * support internal disk snapshot and external disk snapshot 
> > * support different disk backend types. 
> >   (Basic goal is to support 'raw' and 'qcow2' only). 
> >  
> > * not support snapshot when domain is shutdowning or dying. 
> > * not support disk-only snapshot [1]. 
> >  
> >  [1] 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. 
> >  
>  
> I think I understand your reasoning, but it's a bit convoluted to me. 
>  
> Domain can be in both active and inactive state (libvirt term) when 
> using xl.  When domain is active, we cannot guarantee in xl that domain 
> is quiesced so a disk-only snapshot may contain inconsistent data.

That's right.

> When 
> domain is inactive, there's no point in taking a disk-only snapshot 
> because it would be the same as the base image.

xl doesn't have inactive domains. Libvirt has. (in libvirt, one can 'define'
a domain but not 'starte', like old xend which can 'new' a domain but not
'start' it.) xl only can 'create' a domain, when domain is shutdown, it's
not visible to user.

For inactive domain, disk-only snapshot is useful. Since later user
may run VM with base image and base image would change. Then the
disk-only snapshot is a usable backup.

That's why, libvirt can support disk-only snapshot, xl won't support
disk-only snapshot. Do I describe it clearly?

> So the conclusion is 
> that xl doesn't need to support disk-only snapshot. 
>  
> Does the above reasoning equals to yours? Is it clearer or more 
> confusing? 
>  
> Wei. 
>  
> >  
> > 2. Requirements 
> >  
> > General Requirements: 
> > * ability to save/restore domain memory 
> > * ability to create/delete/apply disk snapshot [2] 
> > * ability to parse user config file 
> >  
> >   [2] Disk snapshot requirements: 
> >   - external tools: qemu-img, lvcreate, vhd-util, etc. 
> >   - for basic goal, we support 'raw' and 'qcow2' backend types 
> >     only. Then it requires: 
> >     libxl qmp command or "qemu-img" (when qemu process does not 
> >     exist) 
> >  
> >  
> > 3. Interaction with other operations: 
> >  
> > No. 
> >  
> >  
> > 4. General workflow 
> >  
> > Create a snapshot: 
> >   * parse user cfg file if passed in 
> >   * check snapshot operation is allowed or not 
> >   * save domain, saving memory status to file (refer to: save_domain) 
> >   * take disk snapshot (e.g. call qmp command) 
> >   * unpause domain 
> >  
> > Revert to snapshot: 
> >   * parse use cfg file (xl doesn't manage snapshots, so it has no 
> >     idea of snapshot existence. User MUST supply configuration file) 
> >   * destroy this domain 
> >   * create a new domain from snapshot info 
> >     - apply disk snapshot (e.g. call qemu-img) 
> >     - a process like restore domain 
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 05:00:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 05: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 1Y1TBa-0007Uf-3i; Thu, 18 Dec 2014 04:59:38 +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 1Y1TBY-0007Ua-FD
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 04:59:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C2/C1-15461-73F52945; Thu, 18 Dec 2014 04:59:35 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418878774!16407383!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25230 invoked from network); 18 Dec 2014 04:59:34 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-21.messagelabs.com with SMTP;
	18 Dec 2014 04:59:34 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 17 Dec 2014 20:57:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,598,1413270000"; d="scan'208";a="625702585"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
	by orsmga001.jf.intel.com with ESMTP; 17 Dec 2014 20:59:30 -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; Thu, 18 Dec 2014 12:55:22 +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; Thu, 18 Dec 2014 12:55:21 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, "Ian.Jackson@eu.citrix.com"
	<Ian.Jackson@eu.citrix.com>, "Ian.Campbell@citrix.com"
	<Ian.Campbell@citrix.com>
Thread-Topic: Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by
	Intel.Was:Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/nWuLyPytmG9lUW9P9kyZB1iX5xvcsYQ///3QgCAAAVJgIAljQSA
Date: Thu, 18 Dec 2014 04:55:21 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31AA2F3B@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<546354D7.2040703@oracle.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A68B84@SHSMSX103.ccr.corp.intel.com>
	<20141124145421.GD3000@laptop.dumpdata.com>
	<54734B0D.1090201@oracle.com>
In-Reply-To: <54734B0D.1090201@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: "Wang, Wei W" <wei.w.wang@intel.com>, "Wang,
	Yong Y" <yong.y.wang@intel.com>, "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-Type: 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: Monday, November 24, 2014 11:13 PM
> To: Konrad Rzeszutek Wilk; Hu, Robert; Ian.Jackson@eu.citrix.com;
> Ian.Campbell@citrix.com
> Cc: xen-devel@lists.xen.org; JBeulich@suse.com
> Subject: Re: Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by
> Intel.Was:Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> 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
We verified this on RC4, it works.
Will your patch get in Xen 4.5 release? Otherwise hotplug vt-d device with a running guest will not work properly.
> 
> 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 Thu Dec 18 05:00:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 05: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 1Y1TBa-0007Uf-3i; Thu, 18 Dec 2014 04:59:38 +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 1Y1TBY-0007Ua-FD
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 04:59:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	C2/C1-15461-73F52945; Thu, 18 Dec 2014 04:59:35 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418878774!16407383!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25230 invoked from network); 18 Dec 2014 04:59:34 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-14.tower-21.messagelabs.com with SMTP;
	18 Dec 2014 04:59:34 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 17 Dec 2014 20:57:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,598,1413270000"; d="scan'208";a="625702585"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
	by orsmga001.jf.intel.com with ESMTP; 17 Dec 2014 20:59:30 -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; Thu, 18 Dec 2014 12:55:22 +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; Thu, 18 Dec 2014 12:55:21 +0800
From: "Hu, Robert" <robert.hu@intel.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>, "Ian.Jackson@eu.citrix.com"
	<Ian.Jackson@eu.citrix.com>, "Ian.Campbell@citrix.com"
	<Ian.Campbell@citrix.com>
Thread-Topic: Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by
	Intel.Was:Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
Thread-Index: AQHP/nWuLyPytmG9lUW9P9kyZB1iX5xvcsYQ///3QgCAAAVJgIAljQSA
Date: Thu, 18 Dec 2014 04:55:21 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31AA2F3B@SHSMSX103.ccr.corp.intel.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31A4C7A8@SHSMSX103.ccr.corp.intel.com>
	<546354D7.2040703@oracle.com>
	<9E79D1C9A97CFD4097BCE431828FDD31A68B84@SHSMSX103.ccr.corp.intel.com>
	<20141124145421.GD3000@laptop.dumpdata.com>
	<54734B0D.1090201@oracle.com>
In-Reply-To: <54734B0D.1090201@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: "Wang, Wei W" <wei.w.wang@intel.com>, "Wang,
	Yong Y" <yong.y.wang@intel.com>, "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-Type: 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: Monday, November 24, 2014 11:13 PM
> To: Konrad Rzeszutek Wilk; Hu, Robert; Ian.Jackson@eu.citrix.com;
> Ian.Campbell@citrix.com
> Cc: xen-devel@lists.xen.org; JBeulich@suse.com
> Subject: Re: Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by
> Intel.Was:Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
> 
> 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
We verified this on RC4, it works.
Will your patch get in Xen 4.5 release? Otherwise hotplug vt-d device with a running guest will not work properly.
> 
> 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 Thu Dec 18 07:22:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 07: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 1Y1VPZ-0004IH-F0; Thu, 18 Dec 2014 07:22:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y1VPY-0004IC-If
	for xen-devel@lists.xensource.com; Thu, 18 Dec 2014 07:22:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	35/EB-15461-3A082945; Thu, 18 Dec 2014 07:22:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418887328!16379111!1
X-Originating-IP: [66.165.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 18781 invoked from network); 18 Dec 2014 07:22:09 -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;
	18 Dec 2014 07:22:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,599,1413244800"; d="scan'208";a="206155601"
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.210.2; Thu, 18 Dec 2014 02:22: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 1Y1VPS-0003cf-NY;
	Thu, 18 Dec 2014 07:22:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1VPS-0005sb-HY;
	Thu, 18 Dec 2014 07:22:06 +0000
Date: Thu, 18 Dec 2014 07:22:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32433-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] 32433: 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 32433 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32433/

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              b1802714dab51bd5f0214a4d93a2c0b635bc5f14
baseline version:
 libvirt              a93a3b975cd0bad37ccae508d9b7a69aa72b6181

------------------------------------------------------------
People who touched revisions under test:
  Eric Blake <eblake@redhat.com>
  Jiri Denemark <jdenemar@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=b1802714dab51bd5f0214a4d93a2c0b635bc5f14
+ . 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 b1802714dab51bd5f0214a4d93a2c0b635bc5f14
+ branch=libvirt
+ revision=b1802714dab51bd5f0214a4d93a2c0b635bc5f14
+ . 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 b1802714dab51bd5f0214a4d93a2c0b635bc5f14:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   a93a3b9..b180271  b1802714dab51bd5f0214a4d93a2c0b635bc5f14 -> 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 Thu Dec 18 07:22:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 07: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 1Y1VPZ-0004IH-F0; Thu, 18 Dec 2014 07:22:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y1VPY-0004IC-If
	for xen-devel@lists.xensource.com; Thu, 18 Dec 2014 07:22:12 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	35/EB-15461-3A082945; Thu, 18 Dec 2014 07:22:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418887328!16379111!1
X-Originating-IP: [66.165.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 18781 invoked from network); 18 Dec 2014 07:22:09 -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;
	18 Dec 2014 07:22:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,599,1413244800"; d="scan'208";a="206155601"
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.210.2; Thu, 18 Dec 2014 02:22: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 1Y1VPS-0003cf-NY;
	Thu, 18 Dec 2014 07:22:06 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1VPS-0005sb-HY;
	Thu, 18 Dec 2014 07:22:06 +0000
Date: Thu, 18 Dec 2014 07:22:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32433-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] 32433: 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 32433 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32433/

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              b1802714dab51bd5f0214a4d93a2c0b635bc5f14
baseline version:
 libvirt              a93a3b975cd0bad37ccae508d9b7a69aa72b6181

------------------------------------------------------------
People who touched revisions under test:
  Eric Blake <eblake@redhat.com>
  Jiri Denemark <jdenemar@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=b1802714dab51bd5f0214a4d93a2c0b635bc5f14
+ . 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 b1802714dab51bd5f0214a4d93a2c0b635bc5f14
+ branch=libvirt
+ revision=b1802714dab51bd5f0214a4d93a2c0b635bc5f14
+ . 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 b1802714dab51bd5f0214a4d93a2c0b635bc5f14:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   a93a3b9..b180271  b1802714dab51bd5f0214a4d93a2c0b635bc5f14 -> 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 Thu Dec 18 08:04:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 08: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 1Y1W48-0006AS-9g; Thu, 18 Dec 2014 08:04:08 +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 1Y1W46-0006AK-Qh
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 08:04:06 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	DC/19-28865-67A82945; Thu, 18 Dec 2014 08:04:06 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418889841!14045991!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3131 invoked from network); 18 Dec 2014 08:04:02 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-206.messagelabs.com with SMTP;
	18 Dec 2014 08:04:02 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 18 Dec 2014 00:04:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,599,1413270000"; d="scan'208";a="625769951"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by orsmga001.jf.intel.com with ESMTP; 18 Dec 2014 00:03:59 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 18 Dec 2014 16:03:58 +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, 18 Dec 2014 16:03:57 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [PATCH v2 13/14] vTPM/TPM2: Unind group keys and sectors data
	on disk
Thread-Index: AQHQGhH+vAphcepe50CNxsyQZGDgkpyU/G3A
Date: Thu, 18 Dec 2014 08:03:57 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E84EF52@SHSMSX101.ccr.corp.intel.com>
References: <1418817131-5683-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1418817131-5683-1-git-send-email-quan.xu@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>,
	"dgdegra@tycho.nsa.gov" <dgdegra@tycho.nsa.gov>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 13/14] vTPM/TPM2: Unind group keys and
 sectors data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Xu, Quan
> Sent: Wednesday, December 17, 2014 7:52 PM
> To: xen-devel@lists.xen.org
> Cc: dgdegra@tycho.nsa.gov; stefano.stabellini@eu.citrix.com;
> samuel.thibault@ens-lyon.org; Xu, Quan
> Subject: [PATCH v2 13/14] vTPM/TPM2: Unind group keys and sectors data
> on disk
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> ---
>  stubdom/vtpmmgr/disk_read.c | 16 ++++++++++++++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/stubdom/vtpmmgr/disk_read.c b/stubdom/vtpmmgr/disk_read.c
> index 33aacdd..e147e90 100644
> --- a/stubdom/vtpmmgr/disk_read.c
> +++ b/stubdom/vtpmmgr/disk_read.c
> @@ -88,7 +88,13 @@ static int find_group_key(struct mem_group *dst,

Should define 'olen' parameter. Missing it when I split it into patch.  :( , I will add it in v3 with your comments fix. 

     int i, rc, rv = 1;
+    unsigned int olen;
     struct hash160 buf;


>  		TPM_pcr_digest(&buf, cfg->pcr_selection);
>  		if (memcmp(&buf, &cfg->digest_release, 20))
>  			continue;
> -		rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
> +
> +        /*TPM 2.0 unbind | TPM 1.x unseal*/
> +        if (hw_is_tpm2())
> +            rc = TPM2_disk_unbind(&sealed, &olen, cfg);
> +        else
> +            rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
> +
>  		if (rc)
>  			continue;
>  		if (memcmp(&sealed.magic, DISK_GROUP_BOUND_MAGIC, 4)) @@
> -112,9 +118,15 @@ static int find_group_key(struct mem_group *dst,
> static int parse_root_key(struct mem_tpm_mgr *dst, struct disk_seal_entry
> *src)  {
>  	int rc;
> +    unsigned int olen;
>  	struct disk_root_sealed_data sealed;
> 
> -	rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
> +    /*TPM 2.0 unbind | TPM 1.x unseal*/
> +    if (hw_is_tpm2())
> +        rc = TPM2_disk_unbind(&sealed, &olen, src);
> +    else
> +        rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
> +
>  	if (rc)
>  		return rc;
> 
> --
> 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 Dec 18 08:04:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 08: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 1Y1W48-0006AS-9g; Thu, 18 Dec 2014 08:04:08 +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 1Y1W46-0006AK-Qh
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 08:04:06 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	DC/19-28865-67A82945; Thu, 18 Dec 2014 08:04:06 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418889841!14045991!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3131 invoked from network); 18 Dec 2014 08:04:02 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-206.messagelabs.com with SMTP;
	18 Dec 2014 08:04:02 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 18 Dec 2014 00:04:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,599,1413270000"; d="scan'208";a="625769951"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by orsmga001.jf.intel.com with ESMTP; 18 Dec 2014 00:03:59 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 18 Dec 2014 16:03:58 +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, 18 Dec 2014 16:03:57 +0800
From: "Xu, Quan" <quan.xu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [PATCH v2 13/14] vTPM/TPM2: Unind group keys and sectors data
	on disk
Thread-Index: AQHQGhH+vAphcepe50CNxsyQZGDgkpyU/G3A
Date: Thu, 18 Dec 2014 08:03:57 +0000
Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E84EF52@SHSMSX101.ccr.corp.intel.com>
References: <1418817131-5683-1-git-send-email-quan.xu@intel.com>
In-Reply-To: <1418817131-5683-1-git-send-email-quan.xu@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>,
	"dgdegra@tycho.nsa.gov" <dgdegra@tycho.nsa.gov>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 13/14] vTPM/TPM2: Unind group keys and
 sectors data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Xu, Quan
> Sent: Wednesday, December 17, 2014 7:52 PM
> To: xen-devel@lists.xen.org
> Cc: dgdegra@tycho.nsa.gov; stefano.stabellini@eu.citrix.com;
> samuel.thibault@ens-lyon.org; Xu, Quan
> Subject: [PATCH v2 13/14] vTPM/TPM2: Unind group keys and sectors data
> on disk
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> ---
>  stubdom/vtpmmgr/disk_read.c | 16 ++++++++++++++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/stubdom/vtpmmgr/disk_read.c b/stubdom/vtpmmgr/disk_read.c
> index 33aacdd..e147e90 100644
> --- a/stubdom/vtpmmgr/disk_read.c
> +++ b/stubdom/vtpmmgr/disk_read.c
> @@ -88,7 +88,13 @@ static int find_group_key(struct mem_group *dst,

Should define 'olen' parameter. Missing it when I split it into patch.  :( , I will add it in v3 with your comments fix. 

     int i, rc, rv = 1;
+    unsigned int olen;
     struct hash160 buf;


>  		TPM_pcr_digest(&buf, cfg->pcr_selection);
>  		if (memcmp(&buf, &cfg->digest_release, 20))
>  			continue;
> -		rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
> +
> +        /*TPM 2.0 unbind | TPM 1.x unseal*/
> +        if (hw_is_tpm2())
> +            rc = TPM2_disk_unbind(&sealed, &olen, cfg);
> +        else
> +            rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
> +
>  		if (rc)
>  			continue;
>  		if (memcmp(&sealed.magic, DISK_GROUP_BOUND_MAGIC, 4)) @@
> -112,9 +118,15 @@ static int find_group_key(struct mem_group *dst,
> static int parse_root_key(struct mem_tpm_mgr *dst, struct disk_seal_entry
> *src)  {
>  	int rc;
> +    unsigned int olen;
>  	struct disk_root_sealed_data sealed;
> 
> -	rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
> +    /*TPM 2.0 unbind | TPM 1.x unseal*/
> +    if (hw_is_tpm2())
> +        rc = TPM2_disk_unbind(&sealed, &olen, src);
> +    else
> +        rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
> +
>  	if (rc)
>  		return rc;
> 
> --
> 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 Dec 18 08:14:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 08: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 1Y1WDi-0006dY-7I; Thu, 18 Dec 2014 08:14:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wenjianhn@gmail.com>) id 1Y1WDg-0006dT-I0
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 08:14:00 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	86/70-25276-7CC82945; Thu, 18 Dec 2014 08:13:59 +0000
X-Env-Sender: wenjianhn@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418890439!16419008!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21688 invoked from network); 18 Dec 2014 08:13:59 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 08:13:59 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so860599wiw.16
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 00:13:59 -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=rcD8BoszEANKbu+BC1NqJ1eBfbPYpybLG1/a0swnqsk=;
	b=IS7qao3uW67JkzEO4gUnyxzysm18naB0OTd5MqAnfx2n1RKLxvigBoW62JABOTuJWS
	TmKPHcqbRizlY5RCplHaiJnFppUTAnQvh75bzF34sRTmp5OVEm18pNsa22vByq9j0VvD
	GgOON8LEwn8PsThD7s1zveS2gYfnJqU5lWEMH4EK1+BmJhIS+pV33InHY9dBo/JY/F+y
	DkCUGuRwBV2XnF9G38PFAonuLecAM9xuOf0747spHPf+ZXi4LhWtU2IzSJl933ENSHAF
	+FGSf8rkuPLPD75skAtGoVZUK3j+h3rMBkHNu28YTtP1jVsnBzP4PtZHtuMkbf8hOcYO
	rrxQ==
X-Received: by 10.180.98.197 with SMTP id ek5mr22101134wib.35.1418890439216;
	Thu, 18 Dec 2014 00:13:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.139.82 with HTTP; Thu, 18 Dec 2014 00:13:18 -0800 (PST)
From: Jian Wen <wenjianhn@gmail.com>
Date: Thu, 18 Dec 2014 16:13:18 +0800
Message-ID: <CAMXzGWLStjfXdciYSzQNR9-ywOEmH5TRpQKGCJPTcBjynYnA0g@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 1/3][xen-netback] add a pseudo pps rate
	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

>On Tue, 2013-07-09 at 16:01 +0200, William Dauchy wrote:
>> On Jul09 15:48, Sander Eikelenboom wrote:
>> > Just wondering, why should this be done in the drivers ?
>> > Couldn't this also be achieved with netfilter and the recent/limit modules ?
>> > The limit module can already handle bursts.
>>
>> We indeed forgot to talk about it since we already got the question from
>> Wei.
>> The first thing is that your comment is also true for bandwidth which is
>> already present. Moreover PPS is linked to bandwidth.
>> By using netfilter, PPS shaping is done on backend level, once packet
>> has left the VM; which means after using an additional memory transaction
>> to copy packet from frontend. IMHO, at scale, shaping in this way should
>> save some memory transactions comparing to netfilter.
>
>Have you tried the netfilter approach and found it to be insufficient in
>practice?
>
>I'm not sure how netfilter recent/limit is implemented but if it queues
>rather than drops you would naturally find that you end up with back
>pressure onto the netback device where the ring would fill with
>in-progress requests and therefore netback would have to stop processing
>more packets.
>
>Ian.
>

The maximum limit rate of the netfilter limit module is 10000/s that is too
 small nowadays. Even if the size of the packet is 1500, the bandwidth is
as small as 14 MiB. So it is not a good practise to use the limit module.

$  sudo iptables -I INPUT -m limit --limit 10001/s --limit-burst 100 -j RETURN
iptables v1.4.19.1: Rate too fast "10001/s"


-- 
Best,

Jian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 08:14:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 08: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 1Y1WDi-0006dY-7I; Thu, 18 Dec 2014 08:14:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wenjianhn@gmail.com>) id 1Y1WDg-0006dT-I0
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 08:14:00 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	86/70-25276-7CC82945; Thu, 18 Dec 2014 08:13:59 +0000
X-Env-Sender: wenjianhn@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418890439!16419008!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21688 invoked from network); 18 Dec 2014 08:13:59 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 08:13:59 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so860599wiw.16
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 00:13:59 -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=rcD8BoszEANKbu+BC1NqJ1eBfbPYpybLG1/a0swnqsk=;
	b=IS7qao3uW67JkzEO4gUnyxzysm18naB0OTd5MqAnfx2n1RKLxvigBoW62JABOTuJWS
	TmKPHcqbRizlY5RCplHaiJnFppUTAnQvh75bzF34sRTmp5OVEm18pNsa22vByq9j0VvD
	GgOON8LEwn8PsThD7s1zveS2gYfnJqU5lWEMH4EK1+BmJhIS+pV33InHY9dBo/JY/F+y
	DkCUGuRwBV2XnF9G38PFAonuLecAM9xuOf0747spHPf+ZXi4LhWtU2IzSJl933ENSHAF
	+FGSf8rkuPLPD75skAtGoVZUK3j+h3rMBkHNu28YTtP1jVsnBzP4PtZHtuMkbf8hOcYO
	rrxQ==
X-Received: by 10.180.98.197 with SMTP id ek5mr22101134wib.35.1418890439216;
	Thu, 18 Dec 2014 00:13:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.139.82 with HTTP; Thu, 18 Dec 2014 00:13:18 -0800 (PST)
From: Jian Wen <wenjianhn@gmail.com>
Date: Thu, 18 Dec 2014 16:13:18 +0800
Message-ID: <CAMXzGWLStjfXdciYSzQNR9-ywOEmH5TRpQKGCJPTcBjynYnA0g@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 1/3][xen-netback] add a pseudo pps rate
	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

>On Tue, 2013-07-09 at 16:01 +0200, William Dauchy wrote:
>> On Jul09 15:48, Sander Eikelenboom wrote:
>> > Just wondering, why should this be done in the drivers ?
>> > Couldn't this also be achieved with netfilter and the recent/limit modules ?
>> > The limit module can already handle bursts.
>>
>> We indeed forgot to talk about it since we already got the question from
>> Wei.
>> The first thing is that your comment is also true for bandwidth which is
>> already present. Moreover PPS is linked to bandwidth.
>> By using netfilter, PPS shaping is done on backend level, once packet
>> has left the VM; which means after using an additional memory transaction
>> to copy packet from frontend. IMHO, at scale, shaping in this way should
>> save some memory transactions comparing to netfilter.
>
>Have you tried the netfilter approach and found it to be insufficient in
>practice?
>
>I'm not sure how netfilter recent/limit is implemented but if it queues
>rather than drops you would naturally find that you end up with back
>pressure onto the netback device where the ring would fill with
>in-progress requests and therefore netback would have to stop processing
>more packets.
>
>Ian.
>

The maximum limit rate of the netfilter limit module is 10000/s that is too
 small nowadays. Even if the size of the packet is 1500, the bandwidth is
as small as 14 MiB. So it is not a good practise to use the limit module.

$  sudo iptables -I INPUT -m limit --limit 10001/s --limit-burst 100 -j RETURN
iptables v1.4.19.1: Rate too fast "10001/s"


-- 
Best,

Jian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 08:15:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 08: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 1Y1WEx-0006iU-95; Thu, 18 Dec 2014 08:15:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ba1020@homie.homelinux.net>) id 1Y1N6c-0006DA-F1
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 22:30:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D1/A7-15461-DE302945; Wed, 17 Dec 2014 22:30:05 +0000
X-Env-Sender: ba1020@homie.homelinux.net
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418855405!16350412!1
X-Originating-IP: [87.81.139.118]
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 25468 invoked from network); 17 Dec 2014 22:30:05 -0000
Received: from 57518b76.skybroadband.com (HELO zimbra.homelinux.net)
	(87.81.139.118)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 22:30:05 -0000
Received: from localhost (ip6-localhost [IPv6:::1])
	by zimbra.homelinux.net (Postfix) with ESMTP id 83A2D2000C7
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 22:30:03 +0000 (GMT)
Received: from zimbra.homelinux.net ([IPv6:::1])
	by localhost (zimbra.homelinux.net [IPv6:::1]) (amavisd-new, port 10032)
	with ESMTP id V7jdTkiLbOdN for <xen-devel@lists.xen.org>;
	Wed, 17 Dec 2014 22:30:01 +0000 (GMT)
Received: from localhost (ip6-localhost [IPv6:::1])
	by zimbra.homelinux.net (Postfix) with ESMTP id A83252003E8
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 22:30:01 +0000 (GMT)
X-Virus-Scanned: amavisd-new at zimbra.homelinux.net
Received: from zimbra.homelinux.net ([IPv6:::1])
	by localhost (zimbra.homelinux.net [IPv6:::1]) (amavisd-new, port 10026)
	with ESMTP id CAZN_NwmJHFm for <xen-devel@lists.xen.org>;
	Wed, 17 Dec 2014 22:30:01 +0000 (GMT)
Received: from zimbra.homelinux.net (localhost [127.0.0.1])
	by zimbra.homelinux.net (Postfix) with ESMTP id 3D2EC2000C7
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 22:30:01 +0000 (GMT)
Date: Wed, 17 Dec 2014 22:30:01 +0000 (GMT)
From: Juergen Schinker <ba1020@homie.homelinux.net>
To: xen-devel@lists.xen.org
Message-ID: <950932225.512.1418855401102.JavaMail.zimbra@homie.homelinux.net>
MIME-Version: 1.0
X-Originating-IP: [2001:470:6984:1:216:3eff:fe68:9940]
X-Mailer: Zimbra 8.5.1_GA_3056 (ZimbraWebClient - FF31 (Linux)/8.5.1_GA_3056)
Thread-Topic: Test report Xen 4.5.0-RC4
Thread-Index: nZK9f5TErunbanMT91vjdlY1L/pOYQ==
X-Mailman-Approved-At: Thu, 18 Dec 2014 08:15:17 +0000
Subject: [Xen-devel] [TESTDAY] Test report Xen 4.5.0-RC4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Subject: [TESTDAY] Test report Xen 4.5.0-RC4
 
* Hardware:

 Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz (4cores -1 socket)
  32G Ram
 SSD Disk 1 T

* Software:
Debian Jessie as dom0

* Guest operating systems:
Debian Jessie and Ubuntu 14.10

* Functionality tested:
xl pygrub pvgrub openvswitch

* Comments:

 had to compile with
 configure --enable-githttp --enable-systemd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 08:15:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 08: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 1Y1WEx-0006ic-Rm; Thu, 18 Dec 2014 08:15:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jw@nuclearfallout.net>) id 1Y1O2D-00082W-Hk
	for Xen-devel@lists.xen.org; Wed, 17 Dec 2014 23:29:37 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	0D/BE-24859-0E112945; Wed, 17 Dec 2014 23:29:36 +0000
X-Env-Sender: jw@nuclearfallout.net
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418858975!14194305!1
X-Originating-IP: [208.146.45.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25327 invoked from network); 17 Dec 2014 23:29:35 -0000
Received: from mail.nuclearfallout.net (HELO mail.nuclearfallout.net)
	(208.146.45.251) by server-7.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 23:29:35 -0000
Message-ID: <549211E2.8030901@nuclearfallout.net>
Date: Wed, 17 Dec 2014 15:29:38 -0800
From: John <jw@nuclearfallout.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <54884DA8.7030003@nuclearfallout.net>
	<548854C3.7060008@citrix.com> <54918C89.1020409@citrix.com>
In-Reply-To: <54918C89.1020409@citrix.com>
X-Mailman-Approved-At: Thu, 18 Dec 2014 08:15:17 +0000
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	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] xen-netback: make feature-rx-notify mandatory --
 Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/17/2014 6:00 AM, David Vrabel wrote:
> This patch works for me.  I tested it with a hacked Linux frontend that
> disabled feature-rx-notify, but not with a stubdom.
>
> Can you give it a try, please?

I tested this and it does seem to work -- at least, a stubdom-based domU 
starts up and runs properly. That said, I'm not using the minios network 
functionality much, since all of my customer and test domains use PVHVM 
drivers.

-John

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 08:15:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 08: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 1Y1WEx-0006iU-95; Thu, 18 Dec 2014 08:15:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ba1020@homie.homelinux.net>) id 1Y1N6c-0006DA-F1
	for xen-devel@lists.xen.org; Wed, 17 Dec 2014 22:30:06 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D1/A7-15461-DE302945; Wed, 17 Dec 2014 22:30:05 +0000
X-Env-Sender: ba1020@homie.homelinux.net
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418855405!16350412!1
X-Originating-IP: [87.81.139.118]
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 25468 invoked from network); 17 Dec 2014 22:30:05 -0000
Received: from 57518b76.skybroadband.com (HELO zimbra.homelinux.net)
	(87.81.139.118)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Dec 2014 22:30:05 -0000
Received: from localhost (ip6-localhost [IPv6:::1])
	by zimbra.homelinux.net (Postfix) with ESMTP id 83A2D2000C7
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 22:30:03 +0000 (GMT)
Received: from zimbra.homelinux.net ([IPv6:::1])
	by localhost (zimbra.homelinux.net [IPv6:::1]) (amavisd-new, port 10032)
	with ESMTP id V7jdTkiLbOdN for <xen-devel@lists.xen.org>;
	Wed, 17 Dec 2014 22:30:01 +0000 (GMT)
Received: from localhost (ip6-localhost [IPv6:::1])
	by zimbra.homelinux.net (Postfix) with ESMTP id A83252003E8
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 22:30:01 +0000 (GMT)
X-Virus-Scanned: amavisd-new at zimbra.homelinux.net
Received: from zimbra.homelinux.net ([IPv6:::1])
	by localhost (zimbra.homelinux.net [IPv6:::1]) (amavisd-new, port 10026)
	with ESMTP id CAZN_NwmJHFm for <xen-devel@lists.xen.org>;
	Wed, 17 Dec 2014 22:30:01 +0000 (GMT)
Received: from zimbra.homelinux.net (localhost [127.0.0.1])
	by zimbra.homelinux.net (Postfix) with ESMTP id 3D2EC2000C7
	for <xen-devel@lists.xen.org>; Wed, 17 Dec 2014 22:30:01 +0000 (GMT)
Date: Wed, 17 Dec 2014 22:30:01 +0000 (GMT)
From: Juergen Schinker <ba1020@homie.homelinux.net>
To: xen-devel@lists.xen.org
Message-ID: <950932225.512.1418855401102.JavaMail.zimbra@homie.homelinux.net>
MIME-Version: 1.0
X-Originating-IP: [2001:470:6984:1:216:3eff:fe68:9940]
X-Mailer: Zimbra 8.5.1_GA_3056 (ZimbraWebClient - FF31 (Linux)/8.5.1_GA_3056)
Thread-Topic: Test report Xen 4.5.0-RC4
Thread-Index: nZK9f5TErunbanMT91vjdlY1L/pOYQ==
X-Mailman-Approved-At: Thu, 18 Dec 2014 08:15:17 +0000
Subject: [Xen-devel] [TESTDAY] Test report Xen 4.5.0-RC4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Subject: [TESTDAY] Test report Xen 4.5.0-RC4
 
* Hardware:

 Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz (4cores -1 socket)
  32G Ram
 SSD Disk 1 T

* Software:
Debian Jessie as dom0

* Guest operating systems:
Debian Jessie and Ubuntu 14.10

* Functionality tested:
xl pygrub pvgrub openvswitch

* Comments:

 had to compile with
 configure --enable-githttp --enable-systemd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 08:15:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 08: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 1Y1WEx-0006ic-Rm; Thu, 18 Dec 2014 08:15:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jw@nuclearfallout.net>) id 1Y1O2D-00082W-Hk
	for Xen-devel@lists.xen.org; Wed, 17 Dec 2014 23:29:37 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	0D/BE-24859-0E112945; Wed, 17 Dec 2014 23:29:36 +0000
X-Env-Sender: jw@nuclearfallout.net
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418858975!14194305!1
X-Originating-IP: [208.146.45.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25327 invoked from network); 17 Dec 2014 23:29:35 -0000
Received: from mail.nuclearfallout.net (HELO mail.nuclearfallout.net)
	(208.146.45.251) by server-7.tower-31.messagelabs.com with SMTP;
	17 Dec 2014 23:29:35 -0000
Message-ID: <549211E2.8030901@nuclearfallout.net>
Date: Wed, 17 Dec 2014 15:29:38 -0800
From: John <jw@nuclearfallout.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <54884DA8.7030003@nuclearfallout.net>
	<548854C3.7060008@citrix.com> <54918C89.1020409@citrix.com>
In-Reply-To: <54918C89.1020409@citrix.com>
X-Mailman-Approved-At: Thu, 18 Dec 2014 08:15:17 +0000
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	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] xen-netback: make feature-rx-notify mandatory --
 Breaks stubdoms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/17/2014 6:00 AM, David Vrabel wrote:
> This patch works for me.  I tested it with a hacked Linux frontend that
> disabled feature-rx-notify, but not with a stubdom.
>
> Can you give it a try, please?

I tested this and it does seem to work -- at least, a stubdom-based domU 
starts up and runs properly. That said, I'm not using the minios network 
functionality much, since all of my customer and test domains use PVHVM 
drivers.

-John

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 08:27:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 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 1Y1WQZ-0007LA-Ep; Thu, 18 Dec 2014 08:27:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Y1WQX-0007L5-Ns
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 08:27:18 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	3D/5A-18267-4EF82945; Thu, 18 Dec 2014 08:27:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418891236!14198181!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30411 invoked from network); 18 Dec 2014 08:27:16 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 08:27:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418891236; l=995;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=DD6AFxgwxjxa1vNwaAmjFWgbqqU=;
	b=d8c7i6Qs3aC4LlS6yJemvRPPwtAj1Mm6JbFATeMOa9hSbvuJAchi4tvDt4kc3gXy0LS
	bwchwRAaDcouXvSjHdn11XJb9NfxJo+hRNEMfP3H/6sz7F0XRL/RbAR3A3zsO4yUyPycI
	sb7jLiyZSKRF5hQeO0gOG0zE2alQf6wGSAc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id u05046qBI8RGBVO
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 18 Dec 2014 09:27:16 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0230350158; Thu, 18 Dec 2014 09:27:14 +0100 (CET)
Date: Thu, 18 Dec 2014 09:27:14 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Julian Sivertsen <julian.sivertsen+xen@gmail.com>
Message-ID: <20141218082714.GA15435@aepfle.de>
References: <CAKGZkHvCai_PwNyTpH10-2o4wT+-2+HNCwW-yH_kEeVHXXsjHA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKGZkHvCai_PwNyTpH10-2o4wT+-2+HNCwW-yH_kEeVHXXsjHA@mail.gmail.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Testday] Arch Linux Test report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 18, Julian Sivertsen wrote:

> == Issues ===
> Brief: Invalid FETCHER by ./configure
> Importance: nuisance
> Location: xen
> Workaround: Install wget and reconfigure
> The m4/fetcher.m4 script checks for the precence of wget before falling
> back to "ftp -o". On Arch Linux curl is shipped and ftp does not support
> the -o option. Resulting in the build failing when downloading zlib.

The requirement for wget or ftp is indeed not mentioned in README or
INSTALL.

> Brief: libxenctrl.so.4.5 not found
> Importance: low
> Location: probably Arch Linux
> Workaround: `echo /usr/local/lib > /etc/ld.so.conf.d/xen.cnf; ldconfig`
> Something about the library path is messed up, as oxenstored fails when
> launched by systemd. It needs the shared library libxenctrl.so.4.5 which
> is located in the /usr/local/lib folder, but doesn't find it.

Fix Arch Linux and add /usr/local/lib to the default /etc/ld.so.conf.
Workaround: ./configure --enable-rpath

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 08:27:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 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 1Y1WQZ-0007LA-Ep; Thu, 18 Dec 2014 08:27:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Y1WQX-0007L5-Ns
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 08:27:18 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	3D/5A-18267-4EF82945; Thu, 18 Dec 2014 08:27:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418891236!14198181!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30411 invoked from network); 18 Dec 2014 08:27:16 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 08:27:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418891236; l=995;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=DD6AFxgwxjxa1vNwaAmjFWgbqqU=;
	b=d8c7i6Qs3aC4LlS6yJemvRPPwtAj1Mm6JbFATeMOa9hSbvuJAchi4tvDt4kc3gXy0LS
	bwchwRAaDcouXvSjHdn11XJb9NfxJo+hRNEMfP3H/6sz7F0XRL/RbAR3A3zsO4yUyPycI
	sb7jLiyZSKRF5hQeO0gOG0zE2alQf6wGSAc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id u05046qBI8RGBVO
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 18 Dec 2014 09:27:16 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 0230350158; Thu, 18 Dec 2014 09:27:14 +0100 (CET)
Date: Thu, 18 Dec 2014 09:27:14 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Julian Sivertsen <julian.sivertsen+xen@gmail.com>
Message-ID: <20141218082714.GA15435@aepfle.de>
References: <CAKGZkHvCai_PwNyTpH10-2o4wT+-2+HNCwW-yH_kEeVHXXsjHA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKGZkHvCai_PwNyTpH10-2o4wT+-2+HNCwW-yH_kEeVHXXsjHA@mail.gmail.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Testday] Arch Linux Test report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 18, Julian Sivertsen wrote:

> == Issues ===
> Brief: Invalid FETCHER by ./configure
> Importance: nuisance
> Location: xen
> Workaround: Install wget and reconfigure
> The m4/fetcher.m4 script checks for the precence of wget before falling
> back to "ftp -o". On Arch Linux curl is shipped and ftp does not support
> the -o option. Resulting in the build failing when downloading zlib.

The requirement for wget or ftp is indeed not mentioned in README or
INSTALL.

> Brief: libxenctrl.so.4.5 not found
> Importance: low
> Location: probably Arch Linux
> Workaround: `echo /usr/local/lib > /etc/ld.so.conf.d/xen.cnf; ldconfig`
> Something about the library path is messed up, as oxenstored fails when
> launched by systemd. It needs the shared library libxenctrl.so.4.5 which
> is located in the /usr/local/lib folder, but doesn't find it.

Fix Arch Linux and add /usr/local/lib to the default /etc/ld.so.conf.
Workaround: ./configure --enable-rpath

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 08:50:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 08:50:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1WmE-00086Z-Eq; Thu, 18 Dec 2014 08:49:42 +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 1Y1WmD-00086U-5m
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 08:49:41 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	9B/49-02957-12592945; Thu, 18 Dec 2014 08:49:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418892576!15768762!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32504 invoked from network); 18 Dec 2014 08:49:37 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.219)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 08:49:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418892576; l=1735;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Transfer-Encoding:Content-Disposition:
	Content-Type:MIME-Version:References:Subject:Cc:To:From:Date;
	bh=zt76r6MeQNcVdAUUxQmrSMXjPg0=;
	b=iq+l69i5J9zQW7MXvpR7wPtLAVpHvvN0shqbYXlIQUGomD3mu6lnHkytrlMQ/Jjx69J
	unFqWqMTMa82hBL0GzaXildY/cvnp8ph+cbnAalcyLtuqI5+0UWE+aQdThJX3zTnYA9V/
	AHJnR0YgntWc7F8ObRGuUVaJZ0/Ah+cHpk8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id q03540qBI8nXEt7
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 18 Dec 2014 09:49:33 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id ADF7750161; Thu, 18 Dec 2014 09:49:32 +0100 (CET)
Date: Thu, 18 Dec 2014 09:49:32 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141218084932.GA20792@aepfle.de>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<20141216163451.GA18976@aepfle.de>
	<20141216204601.GA11551@konrad-lan.dumpdata.com>
	<20141217075510.GA678@aepfle.de>
	<20141217194150.GD29130@laptop.dumpdata.com>
	<20141217214333.GE1829@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Length: 2550
Content-Disposition: inline
In-Reply-To: <20141217214333.GE1829@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCBEZWMgMTcsIEtvbnJhZCBSemVzenV0ZWsgV2lsayB3cm90ZToKCj4gW3Jvb3RAbCBr
b25yYWRdIyBzeXN0ZW1jdGwgc3RhdHVzIHhlbnN0b3JlZC5zZXJ2aWNlCj4g4pePIHhlbnN0b3Jl
ZC5zZXJ2aWNlIC0gVGhlIFhlbiB4ZW5zdG9yZQo+ICAgIExvYWRlZDogbG9hZGVkICgvdXNyL2xp
Yi9zeXN0ZW1kL3N5c3RlbS94ZW5zdG9yZWQuc2VydmljZTsgZGlzYWJsZWQpCj4gICAgQWN0aXZl
OiBmYWlsZWQgKFJlc3VsdDogdGltZW91dCkgc2luY2UgV2VkIDIwMTQtMTItMTcgMTY6Mzk6MzUg
RVNUOyAybWluIDEwcyBhZ28KPiAgIFByb2Nlc3M6IDc5MCBFeGVjU3RhcnQ9L3Vzci9saWIveGVu
L2Jpbi94ZW5zdG9yZWQuc2ggLS1uby1mb3JrIChjb2RlPWV4aXRlZCwgc3RhdHVzPTAvU1VDQ0VT
UykKPiAgIFByb2Nlc3M6IDc4NyBFeGVjU3RhcnRQcmU9L2Jpbi9ta2RpciAtcCAvdmFyL3J1bi94
ZW4gKGNvZGU9ZXhpdGVkLCBzdGF0dXM9MC9TVUNDRVNTKQo+ICAgUHJvY2VzczogNzg0IEV4ZWNT
dGFydFByZT0vYmluL3JtIC1mIC92YXIvbGliL3hlbnN0b3JlZC90ZGIqIChjb2RlPWV4aXRlZCwg
c3RhdHVzPTAvU1VDQ0VTUykKPiAgIFByb2Nlc3M6IDc1OSBFeGVjU3RhcnRQcmU9L2Jpbi9ncmVw
IC1xIGNvbnRyb2xfZCAvcHJvYy94ZW4vY2FwYWJpbGl0aWVzIChjb2RlPWV4aXRlZCwgc3RhdHVz
PTAvU1VDQ0VTUykKPiAgTWFpbiBQSUQ6IDc5MCAoY29kZT1leGl0ZWQsIHN0YXR1cz0wL1NVQ0NF
U1MpCj4gCj4gRGVjIDE3IDE2OjM4OjA1IGwub3JhY2xlLmNvbSB4ZW5zdG9yZWQuc2hbNzkwXTog
WGVuIFN0b3JhZ2UgRGFlbW9uLCB2ZXJzaW9uIDEuMAo+IERlYyAxNyAxNjozOTozNSBsLm9yYWNs
ZS5jb20gc3lzdGVtZFsxXTogeGVuc3RvcmVkLnNlcnZpY2Ugc3RhcnQgb3BlcmF0aW9uIHRpbWVk
IG91dC4gVGVybWluYXRpbmcuCj4gRGVjIDE3IDE2OjM5OjM1IGwub3JhY2xlLmNvbSBzeXN0ZW1k
WzFdOiBGYWlsZWQgdG8gc3RhcnQgVGhlIFhlbiB4ZW5zdG9yZS4KPiBEZWMgMTcgMTY6Mzk6MzUg
bC5vcmFjbGUuY29tIHN5c3RlbWRbMV06IFVuaXQgeGVuc3RvcmVkLnNlcnZpY2UgZW50ZXJlZCBm
YWlsZWQgc3RhdGUuCj4gRGVjIDE3IDE2OjM5OjM1IGwub3JhY2xlLmNvbSBzeXN0ZW1kWzFdOiB4
ZW5zdG9yZWQuc2VydmljZSBmYWlsZWQuCj4gW3Jvb3RAbCBrb25yYWRdIyBzeXN0ZW1jdGwgc3Rh
cnQgeGVuc3RvcmVkLnNlcnZpY2UKPiAKPiAKPiBbcm9vdEBsIH5dIyBwcyAtZWZmfGdyZXAgeGVu
cwo+IHJvb3QgICAgICAyMDE4ICAxOTkzICAwIDE2OjQxIHB0cy8wICAgIDAwOjAwOjAwIHN5c3Rl
bWN0bCBzdGFydCB4ZW5zdG9yZWQuc2VydmljZQo+IHJvb3QgICAgICAyMDI5ICAgICAxICAwIDE2
OjQxID8gICAgICAgIDAwOjAwOjAwIC91c3Ivc2Jpbi9veGVuc3RvcmVkIC0tbm8tZm9yawo+IHJv
b3QgICAgICAyMDM0ICAxNzY2ICAwIDE2OjQyIGh2YzAgICAgIDAwOjAwOjAwIGdyZXAgLS1jb2xv
cj1hdXRvIHhlbnMKPiAKPiBJIHRoaW5rIEkgaGF2ZSBzb21ldGhpbmcgbWlzY29uZmlndXJlZCBo
ZXJlLi4KCkxvb2tzIGxpa2Ugd2hhdCBNYXJjIHJlcG9ydGVkLiB4ZW5zdG9yZWQgY2FuIG5vdCB1
c2UgdGhlIHNvY2tldHMuIERvZXMKcnVubmluZyB4ZW5zdG9yZWQgZGlyZWN0bHkgb3IgdmlhIGVu
digxKSB3b3JrIGFueSBiZXR0ZXI/CgpFeGVjU3RhcnQ9QFhFTlNUT1JFREAgLS1uby1mb3JrCkV4
ZWNTdGFydD0vdXNyL2Jpbi9lbnYgJFhFTlNUT1JFRCAtLW5vLWZvcmsKCk9sYWYKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Thu Dec 18 08:50:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 08:50:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1WmE-00086Z-Eq; Thu, 18 Dec 2014 08:49:42 +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 1Y1WmD-00086U-5m
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 08:49:41 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	9B/49-02957-12592945; Thu, 18 Dec 2014 08:49:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418892576!15768762!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32504 invoked from network); 18 Dec 2014 08:49:37 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.219)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 08:49:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418892576; l=1735;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Transfer-Encoding:Content-Disposition:
	Content-Type:MIME-Version:References:Subject:Cc:To:From:Date;
	bh=zt76r6MeQNcVdAUUxQmrSMXjPg0=;
	b=iq+l69i5J9zQW7MXvpR7wPtLAVpHvvN0shqbYXlIQUGomD3mu6lnHkytrlMQ/Jjx69J
	unFqWqMTMa82hBL0GzaXildY/cvnp8ph+cbnAalcyLtuqI5+0UWE+aQdThJX3zTnYA9V/
	AHJnR0YgntWc7F8ObRGuUVaJZ0/Ah+cHpk8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id q03540qBI8nXEt7
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Thu, 18 Dec 2014 09:49:33 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id ADF7750161; Thu, 18 Dec 2014 09:49:32 +0100 (CET)
Date: Thu, 18 Dec 2014 09:49:32 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141218084932.GA20792@aepfle.de>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<20141216163451.GA18976@aepfle.de>
	<20141216204601.GA11551@konrad-lan.dumpdata.com>
	<20141217075510.GA678@aepfle.de>
	<20141217194150.GD29130@laptop.dumpdata.com>
	<20141217214333.GE1829@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Length: 2550
Content-Disposition: inline
In-Reply-To: <20141217214333.GE1829@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCBEZWMgMTcsIEtvbnJhZCBSemVzenV0ZWsgV2lsayB3cm90ZToKCj4gW3Jvb3RAbCBr
b25yYWRdIyBzeXN0ZW1jdGwgc3RhdHVzIHhlbnN0b3JlZC5zZXJ2aWNlCj4g4pePIHhlbnN0b3Jl
ZC5zZXJ2aWNlIC0gVGhlIFhlbiB4ZW5zdG9yZQo+ICAgIExvYWRlZDogbG9hZGVkICgvdXNyL2xp
Yi9zeXN0ZW1kL3N5c3RlbS94ZW5zdG9yZWQuc2VydmljZTsgZGlzYWJsZWQpCj4gICAgQWN0aXZl
OiBmYWlsZWQgKFJlc3VsdDogdGltZW91dCkgc2luY2UgV2VkIDIwMTQtMTItMTcgMTY6Mzk6MzUg
RVNUOyAybWluIDEwcyBhZ28KPiAgIFByb2Nlc3M6IDc5MCBFeGVjU3RhcnQ9L3Vzci9saWIveGVu
L2Jpbi94ZW5zdG9yZWQuc2ggLS1uby1mb3JrIChjb2RlPWV4aXRlZCwgc3RhdHVzPTAvU1VDQ0VT
UykKPiAgIFByb2Nlc3M6IDc4NyBFeGVjU3RhcnRQcmU9L2Jpbi9ta2RpciAtcCAvdmFyL3J1bi94
ZW4gKGNvZGU9ZXhpdGVkLCBzdGF0dXM9MC9TVUNDRVNTKQo+ICAgUHJvY2VzczogNzg0IEV4ZWNT
dGFydFByZT0vYmluL3JtIC1mIC92YXIvbGliL3hlbnN0b3JlZC90ZGIqIChjb2RlPWV4aXRlZCwg
c3RhdHVzPTAvU1VDQ0VTUykKPiAgIFByb2Nlc3M6IDc1OSBFeGVjU3RhcnRQcmU9L2Jpbi9ncmVw
IC1xIGNvbnRyb2xfZCAvcHJvYy94ZW4vY2FwYWJpbGl0aWVzIChjb2RlPWV4aXRlZCwgc3RhdHVz
PTAvU1VDQ0VTUykKPiAgTWFpbiBQSUQ6IDc5MCAoY29kZT1leGl0ZWQsIHN0YXR1cz0wL1NVQ0NF
U1MpCj4gCj4gRGVjIDE3IDE2OjM4OjA1IGwub3JhY2xlLmNvbSB4ZW5zdG9yZWQuc2hbNzkwXTog
WGVuIFN0b3JhZ2UgRGFlbW9uLCB2ZXJzaW9uIDEuMAo+IERlYyAxNyAxNjozOTozNSBsLm9yYWNs
ZS5jb20gc3lzdGVtZFsxXTogeGVuc3RvcmVkLnNlcnZpY2Ugc3RhcnQgb3BlcmF0aW9uIHRpbWVk
IG91dC4gVGVybWluYXRpbmcuCj4gRGVjIDE3IDE2OjM5OjM1IGwub3JhY2xlLmNvbSBzeXN0ZW1k
WzFdOiBGYWlsZWQgdG8gc3RhcnQgVGhlIFhlbiB4ZW5zdG9yZS4KPiBEZWMgMTcgMTY6Mzk6MzUg
bC5vcmFjbGUuY29tIHN5c3RlbWRbMV06IFVuaXQgeGVuc3RvcmVkLnNlcnZpY2UgZW50ZXJlZCBm
YWlsZWQgc3RhdGUuCj4gRGVjIDE3IDE2OjM5OjM1IGwub3JhY2xlLmNvbSBzeXN0ZW1kWzFdOiB4
ZW5zdG9yZWQuc2VydmljZSBmYWlsZWQuCj4gW3Jvb3RAbCBrb25yYWRdIyBzeXN0ZW1jdGwgc3Rh
cnQgeGVuc3RvcmVkLnNlcnZpY2UKPiAKPiAKPiBbcm9vdEBsIH5dIyBwcyAtZWZmfGdyZXAgeGVu
cwo+IHJvb3QgICAgICAyMDE4ICAxOTkzICAwIDE2OjQxIHB0cy8wICAgIDAwOjAwOjAwIHN5c3Rl
bWN0bCBzdGFydCB4ZW5zdG9yZWQuc2VydmljZQo+IHJvb3QgICAgICAyMDI5ICAgICAxICAwIDE2
OjQxID8gICAgICAgIDAwOjAwOjAwIC91c3Ivc2Jpbi9veGVuc3RvcmVkIC0tbm8tZm9yawo+IHJv
b3QgICAgICAyMDM0ICAxNzY2ICAwIDE2OjQyIGh2YzAgICAgIDAwOjAwOjAwIGdyZXAgLS1jb2xv
cj1hdXRvIHhlbnMKPiAKPiBJIHRoaW5rIEkgaGF2ZSBzb21ldGhpbmcgbWlzY29uZmlndXJlZCBo
ZXJlLi4KCkxvb2tzIGxpa2Ugd2hhdCBNYXJjIHJlcG9ydGVkLiB4ZW5zdG9yZWQgY2FuIG5vdCB1
c2UgdGhlIHNvY2tldHMuIERvZXMKcnVubmluZyB4ZW5zdG9yZWQgZGlyZWN0bHkgb3IgdmlhIGVu
digxKSB3b3JrIGFueSBiZXR0ZXI/CgpFeGVjU3RhcnQ9QFhFTlNUT1JFREAgLS1uby1mb3JrCkV4
ZWNTdGFydD0vdXNyL2Jpbi9lbnYgJFhFTlNUT1JFRCAtLW5vLWZvcmsKCk9sYWYKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Thu Dec 18 08:52:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 08:52:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1WpB-0008Vd-1C; Thu, 18 Dec 2014 08:52:45 +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 1Y1Wp9-0008VQ-0l
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 08:52:43 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	22/4B-02702-AD592945; Thu, 18 Dec 2014 08:52:42 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418892751!10420572!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31079 invoked from network); 18 Dec 2014 08:52:41 -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;
	18 Dec 2014 08:52:41 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so988170wiw.2
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 00:52:31 -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=ToflpsqXVwSTSp/mFW73HnEkWR2lP8nqSELh3G+oX6A=;
	b=YpINVcjcPvSecw00xiTZokPa9raINIDBJpnHNsdkRYuMSCUEpMKRZGZ4fnVEU4SmAr
	TKqMiKMiL8reua/0GKgU5QHXy7r+q5RXlSQN1ZK4+G8AXG2m50c2l4/tFbpUlYyzKcES
	xK6rjRnoq+bp/VfC8oc+NCt/G9MNA7KwCtkXMl0nVhiwVGB2GlTwSmz7bP6E6PcXlGrH
	6HejKnKojdqSjjRjRMX5/seFGXa8xCrK+tzJHDlUR6c66T1wxSuoRKJ2iIB9+xgbAnt8
	xDBD0NcezUZk6ourXsA175+6XZVA8a928eOjjNwKbecL6tkoITmKFLe5fhAGRYFcswsm
	uJzw==
X-Gm-Message-State: ALoCoQk4t1VBEz2g/zyraTLbZW/aqSdmO/difmaBDkb5GMkKOtasd4zdhIC0BCbs8wKAxHLbZmLp
X-Received: by 10.194.95.196 with SMTP id dm4mr2012370wjb.41.1418892751366;
	Thu, 18 Dec 2014 00:52:31 -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 j1sm8092310wjw.25.2014.12.18.00.52.29
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 00:52:30 -0800 (PST)
Message-ID: <549295CC.2060309@linaro.org>
Date: Thu, 18 Dec 2014 08:52:28 +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.3.0
MIME-Version: 1.0
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, 
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0AC04044@SHSMSX104.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0AC04044@SHSMSX104.ccr.corp.intel.com>
Cc: Keir Fraser <keir@xen.org>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"manish.jaggi@caviumnetworks.com" <manish.jaggi@caviumnetworks.com>,
	"tim@xen.org" <tim@xen.org>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Zhang,

Please respect the netiquette and avoid lines over 80 characters.


On 18/12/2014 01:12, Zhang, Yang Z wrote:
> I'd suggest splitting the changes to common code to a separate patch and also CC the VT-d/AMD maintainers.

This patch is already common code. Though, there was some changes in 
arch/arm because of interdependency. Splitting more won't make more sense.

 > Because I didn't find those definitions when reviewing the 8th patch 
and I need to search the whole patch set to find them.

it's not a new problem. A patch may have a dependency on another patch 
who has dependency on another one... This would end up to be CCed on 
every patch and spam your inbox.

I usually provide a git repo with my patch series in the cover letter. 
So if you miss anything you can look to the code and found the relevant 
patch.

Anyway... I will CC next time

Sincerely yours,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 08:52:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 08:52:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1WpB-0008Vd-1C; Thu, 18 Dec 2014 08:52:45 +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 1Y1Wp9-0008VQ-0l
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 08:52:43 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	22/4B-02702-AD592945; Thu, 18 Dec 2014 08:52:42 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418892751!10420572!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31079 invoked from network); 18 Dec 2014 08:52:41 -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;
	18 Dec 2014 08:52:41 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so988170wiw.2
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 00:52:31 -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=ToflpsqXVwSTSp/mFW73HnEkWR2lP8nqSELh3G+oX6A=;
	b=YpINVcjcPvSecw00xiTZokPa9raINIDBJpnHNsdkRYuMSCUEpMKRZGZ4fnVEU4SmAr
	TKqMiKMiL8reua/0GKgU5QHXy7r+q5RXlSQN1ZK4+G8AXG2m50c2l4/tFbpUlYyzKcES
	xK6rjRnoq+bp/VfC8oc+NCt/G9MNA7KwCtkXMl0nVhiwVGB2GlTwSmz7bP6E6PcXlGrH
	6HejKnKojdqSjjRjRMX5/seFGXa8xCrK+tzJHDlUR6c66T1wxSuoRKJ2iIB9+xgbAnt8
	xDBD0NcezUZk6ourXsA175+6XZVA8a928eOjjNwKbecL6tkoITmKFLe5fhAGRYFcswsm
	uJzw==
X-Gm-Message-State: ALoCoQk4t1VBEz2g/zyraTLbZW/aqSdmO/difmaBDkb5GMkKOtasd4zdhIC0BCbs8wKAxHLbZmLp
X-Received: by 10.194.95.196 with SMTP id dm4mr2012370wjb.41.1418892751366;
	Thu, 18 Dec 2014 00:52:31 -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 j1sm8092310wjw.25.2014.12.18.00.52.29
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 00:52:30 -0800 (PST)
Message-ID: <549295CC.2060309@linaro.org>
Date: Thu, 18 Dec 2014 08:52:28 +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.3.0
MIME-Version: 1.0
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, 
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<A9667DDFB95DB7438FA9D7D576C3D87E0AC04044@SHSMSX104.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0AC04044@SHSMSX104.ccr.corp.intel.com>
Cc: Keir Fraser <keir@xen.org>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"manish.jaggi@caviumnetworks.com" <manish.jaggi@caviumnetworks.com>,
	"tim@xen.org" <tim@xen.org>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Zhang,

Please respect the netiquette and avoid lines over 80 characters.


On 18/12/2014 01:12, Zhang, Yang Z wrote:
> I'd suggest splitting the changes to common code to a separate patch and also CC the VT-d/AMD maintainers.

This patch is already common code. Though, there was some changes in 
arch/arm because of interdependency. Splitting more won't make more sense.

 > Because I didn't find those definitions when reviewing the 8th patch 
and I need to search the whole patch set to find them.

it's not a new problem. A patch may have a dependency on another patch 
who has dependency on another one... This would end up to be CCed on 
every patch and spam your inbox.

I usually provide a git repo with my patch series in the cover letter. 
So if you miss anything you can look to the code and found the relevant 
patch.

Anyway... I will CC next time

Sincerely yours,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 09:39:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 09:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1XXQ-0001jJ-7x; Thu, 18 Dec 2014 09:38: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 1Y1XXP-0001jE-7V
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 09:38:27 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	1A/66-02954-290A2945; Thu, 18 Dec 2014 09:38:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418895506!12540337!1
X-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 20408 invoked from network); 18 Dec 2014 09:38:26 -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; 18 Dec 2014 09:38:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 09:38:25 +0000
Message-Id: <5492AEA10200007800050819@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 09:38:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418640268.16425.79.camel@citrix.com>
In-Reply-To: <1418640268.16425.79.camel@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] Lots of ACPI warnings from newer iasl (20140926).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 11:44, <Ian.Campbell@citrix.com> wrote:
> isal 20140926-1 in Debian Jessie is rather vocal about
> tools/firmware/hvmloader/acpi. See below. Essentially, a few of these:
>         Control Method should be made Serialized (due to creation of
>         named objects within)

I fixed these. While they seemed important to get fixed at the first
glance, I don't think the fix deserves rushing in before 4.5 got
branched off: In the _CRS case it is rather unlikely that racing
invocations would be done by an OS. And in the _BST cases the
routine has custom serialization in place already. So the fix is rather
cosmetic afaict.

> a slew of:
>         Object is not referenced ^  (Name is within method [_CRS])

I have no idea how to avoid these - we have to name the two
respective memory regions, and not us accessing every of its
fields producing warnings seems more like an overacting iasl than
a source problem to me.

> and a load of:
>         ^ Reserved method should not return a value (_L02)

These were of course trivial to address, but are also purely
cosmetic. I'll defer posting the patch until after branching 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 Dec 18 09:39:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 09:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1XXQ-0001jJ-7x; Thu, 18 Dec 2014 09:38: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 1Y1XXP-0001jE-7V
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 09:38:27 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	1A/66-02954-290A2945; Thu, 18 Dec 2014 09:38:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418895506!12540337!1
X-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 20408 invoked from network); 18 Dec 2014 09:38:26 -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; 18 Dec 2014 09:38:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 09:38:25 +0000
Message-Id: <5492AEA10200007800050819@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 09:38:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418640268.16425.79.camel@citrix.com>
In-Reply-To: <1418640268.16425.79.camel@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] Lots of ACPI warnings from newer iasl (20140926).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.12.14 at 11:44, <Ian.Campbell@citrix.com> wrote:
> isal 20140926-1 in Debian Jessie is rather vocal about
> tools/firmware/hvmloader/acpi. See below. Essentially, a few of these:
>         Control Method should be made Serialized (due to creation of
>         named objects within)

I fixed these. While they seemed important to get fixed at the first
glance, I don't think the fix deserves rushing in before 4.5 got
branched off: In the _CRS case it is rather unlikely that racing
invocations would be done by an OS. And in the _BST cases the
routine has custom serialization in place already. So the fix is rather
cosmetic afaict.

> a slew of:
>         Object is not referenced ^  (Name is within method [_CRS])

I have no idea how to avoid these - we have to name the two
respective memory regions, and not us accessing every of its
fields producing warnings seems more like an overacting iasl than
a source problem to me.

> and a load of:
>         ^ Reserved method should not return a value (_L02)

These were of course trivial to address, but are also purely
cosmetic. I'll defer posting the patch until after branching 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 Dec 18 09:47:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 09:47:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1XgO-0002Aw-8b; Thu, 18 Dec 2014 09:47:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1XgM-0002Ap-RX
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 09:47:42 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	FB/5C-14214-EB2A2945; Thu, 18 Dec 2014 09:47:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418896059!14037278!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 21022 invoked from network); 18 Dec 2014 09:47:41 -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;
	18 Dec 2014 09:47:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,599,1413244800"; d="scan'208";a="205715472"
Message-ID: <1418896057.11882.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 18 Dec 2014 09:47:37 +0000
In-Reply-To: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>
References: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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: Initialize the domain vgic
	lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-12-17 at 15:40 +0000, Julien Grall wrote:
> The domain vgic lock is used uninitialized.
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>     This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
>     unitialized. Luckily we only use the field "raw" which is reset to 0
>     during the domain allocation.
> 
>     There is no harm to apply for Xen 4.5 because it will correctly set
>     the spin_lock structure for a later usage.

By your above reasoning there is also no point, is there? That said, I
think we should take this since as you say it is harmless and good
practice to initialise spinlocks even if not strictly necessary.

> ---
>  xen/arch/arm/vgic.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 97061ce..b8bd38b 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -90,6 +90,8 @@ int domain_vgic_init(struct domain *d)
>          return -ENODEV;
>      }
>  
> +    spin_lock_init(&d->arch.vgic.lock);
> +
>      d->arch.vgic.shared_irqs =
>          xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
>      if ( d->arch.vgic.shared_irqs == NULL )




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 09:47:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 09:47:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1XgO-0002Aw-8b; Thu, 18 Dec 2014 09:47:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1XgM-0002Ap-RX
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 09:47:42 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	FB/5C-14214-EB2A2945; Thu, 18 Dec 2014 09:47:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418896059!14037278!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 21022 invoked from network); 18 Dec 2014 09:47:41 -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;
	18 Dec 2014 09:47:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,599,1413244800"; d="scan'208";a="205715472"
Message-ID: <1418896057.11882.0.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 18 Dec 2014 09:47:37 +0000
In-Reply-To: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>
References: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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: Initialize the domain vgic
	lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2014-12-17 at 15:40 +0000, Julien Grall wrote:
> The domain vgic lock is used uninitialized.
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>     This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
>     unitialized. Luckily we only use the field "raw" which is reset to 0
>     during the domain allocation.
> 
>     There is no harm to apply for Xen 4.5 because it will correctly set
>     the spin_lock structure for a later usage.

By your above reasoning there is also no point, is there? That said, I
think we should take this since as you say it is harmless and good
practice to initialise spinlocks even if not strictly necessary.

> ---
>  xen/arch/arm/vgic.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 97061ce..b8bd38b 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -90,6 +90,8 @@ int domain_vgic_init(struct domain *d)
>          return -ENODEV;
>      }
>  
> +    spin_lock_init(&d->arch.vgic.lock);
> +
>      d->arch.vgic.shared_irqs =
>          xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
>      if ( d->arch.vgic.shared_irqs == NULL )




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 09:54:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 09:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1XmF-0002Yb-7L; Thu, 18 Dec 2014 09:53:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1XmE-0002YW-CA
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 09:53:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C6/40-09842-924A2945; Thu, 18 Dec 2014 09:53:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418896424!16407461!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9146 invoked from network); 18 Dec 2014 09:53:45 -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;
	18 Dec 2014 09:53:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,599,1413244800"; d="scan'208";a="205716938"
Message-ID: <1418896422.11882.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kai Huang <kaih.linux@gmail.com>
Date: Thu, 18 Dec 2014 09:53:42 +0000
In-Reply-To: <CAB+V_5N8ZYBntz57yF=hWaugOHaC_XQLKgv9v-K5LeMK7nDmsA@mail.gmail.com>
References: <CAB+V_5N8ZYBntz57yF=hWaugOHaC_XQLKgv9v-K5LeMK7nDmsA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] XL doesn't work on latest upstream Xen?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-18 at 10:54 +0800, Kai Huang wrote:
> Hi,
> 
> I built and installed Xen from latest upstream Xen source code, but XL
> always failed to work. Do you know what's going on here? My
> environment is Lubuntu 14.04. Thanks in advance.
> 
> I always got "Permission denied" error.
> 
> root@kai-haswell:~# xl list
> libxl: error: libxl.c:561:libxl_list_domain: geting domain info list:
> Permission denied
> libxl_list_domain failed.

Usually indicates that your tools and hypervisor are not in sync.

If you installed from source then you may have a second stale copy of
the tools around (perhaps from distro packaging).

Ian.

> 
> xenstore looks is working fine after I manually start
> /etc/init.d/xencommons services.
> 
> root@kai-haswell:~# xenstore-ls
> tool = ""
>  xenstored = ""
> local = ""
>  domain = ""
>   0 = ""
>    domid = "0"
>    name = "Domain-0"
>    device-model = ""
>     0 = ""
>      state = "running"
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 09:54:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 09:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1XmF-0002Yb-7L; Thu, 18 Dec 2014 09:53:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1XmE-0002YW-CA
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 09:53:46 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C6/40-09842-924A2945; Thu, 18 Dec 2014 09:53:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418896424!16407461!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9146 invoked from network); 18 Dec 2014 09:53:45 -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;
	18 Dec 2014 09:53:45 -0000
X-IronPort-AV: E=Sophos;i="5.07,599,1413244800"; d="scan'208";a="205716938"
Message-ID: <1418896422.11882.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kai Huang <kaih.linux@gmail.com>
Date: Thu, 18 Dec 2014 09:53:42 +0000
In-Reply-To: <CAB+V_5N8ZYBntz57yF=hWaugOHaC_XQLKgv9v-K5LeMK7nDmsA@mail.gmail.com>
References: <CAB+V_5N8ZYBntz57yF=hWaugOHaC_XQLKgv9v-K5LeMK7nDmsA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] XL doesn't work on latest upstream Xen?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-18 at 10:54 +0800, Kai Huang wrote:
> Hi,
> 
> I built and installed Xen from latest upstream Xen source code, but XL
> always failed to work. Do you know what's going on here? My
> environment is Lubuntu 14.04. Thanks in advance.
> 
> I always got "Permission denied" error.
> 
> root@kai-haswell:~# xl list
> libxl: error: libxl.c:561:libxl_list_domain: geting domain info list:
> Permission denied
> libxl_list_domain failed.

Usually indicates that your tools and hypervisor are not in sync.

If you installed from source then you may have a second stale copy of
the tools around (perhaps from distro packaging).

Ian.

> 
> xenstore looks is working fine after I manually start
> /etc/init.d/xencommons services.
> 
> root@kai-haswell:~# xenstore-ls
> tool = ""
>  xenstored = ""
> local = ""
>  domain = ""
>   0 = ""
>    domid = "0"
>    name = "Domain-0"
>    device-model = ""
>     0 = ""
>      state = "running"
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:01:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10: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 1Y1Xt1-0002sk-6s; Thu, 18 Dec 2014 10:00:47 +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 1Y1Xsz-0002sf-Vn
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:00:46 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	50/0C-02954-DC5A2945; Thu, 18 Dec 2014 10:00:45 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418896844!15878751!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6682 invoked from network); 18 Dec 2014 10:00:44 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 18 Dec 2014 10:00:44 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:49619 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Y1Xs3-0002kj-B2; Thu, 18 Dec 2014 10:59:47 +0100
Date: Thu, 18 Dec 2014 11:00:40 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <17310344164.20141218110040@eikelenboom.it>
To: Jian Wen <wenjianhn@gmail.com>
In-Reply-To: <CAMXzGWLStjfXdciYSzQNR9-ywOEmH5TRpQKGCJPTcBjynYnA0g@mail.gmail.com>
References: <CAMXzGWLStjfXdciYSzQNR9-ywOEmH5TRpQKGCJPTcBjynYnA0g@mail.gmail.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 1/3][xen-netback] add a pseudo pps rate
	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


Thursday, December 18, 2014, 9:13:18 AM, you wrote:

>>On Tue, 2013-07-09 at 16:01 +0200, William Dauchy wrote:
>>> On Jul09 15:48, Sander Eikelenboom wrote:
>>> > Just wondering, why should this be done in the drivers ?
>>> > Couldn't this also be achieved with netfilter and the recent/limit modules ?
>>> > The limit module can already handle bursts.
>>>
>>> We indeed forgot to talk about it since we already got the question from
>>> Wei.
>>> The first thing is that your comment is also true for bandwidth which is
>>> already present. Moreover PPS is linked to bandwidth.
>>> By using netfilter, PPS shaping is done on backend level, once packet
>>> has left the VM; which means after using an additional memory transaction
>>> to copy packet from frontend. IMHO, at scale, shaping in this way should
>>> save some memory transactions comparing to netfilter.
>>
>>Have you tried the netfilter approach and found it to be insufficient in
>>practice?
>>
>>I'm not sure how netfilter recent/limit is implemented but if it queues
>>rather than drops you would naturally find that you end up with back
>>pressure onto the netback device where the ring would fill with
>>in-progress requests and therefore netback would have to stop processing
>>more packets.
>>
>>Ian.
>>

> The maximum limit rate of the netfilter limit module is 10000/s that is too
>  small nowadays. Even if the size of the packet is 1500, the bandwidth is
> as small as 14 MiB. So it is not a good practise to use the limit module.

> $  sudo iptables -I INPUT -m limit --limit 10001/s --limit-burst 100 -j RETURN
> iptables v1.4.19.1: Rate too fast "10001/s"


And using TC / qdisc ? (http://lartc.org/manpages/tc.txt)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:01:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10: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 1Y1Xt1-0002sk-6s; Thu, 18 Dec 2014 10:00:47 +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 1Y1Xsz-0002sf-Vn
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:00:46 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	50/0C-02954-DC5A2945; Thu, 18 Dec 2014 10:00:45 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418896844!15878751!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6682 invoked from network); 18 Dec 2014 10:00:44 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 18 Dec 2014 10:00:44 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:49619 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Y1Xs3-0002kj-B2; Thu, 18 Dec 2014 10:59:47 +0100
Date: Thu, 18 Dec 2014 11:00:40 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <17310344164.20141218110040@eikelenboom.it>
To: Jian Wen <wenjianhn@gmail.com>
In-Reply-To: <CAMXzGWLStjfXdciYSzQNR9-ywOEmH5TRpQKGCJPTcBjynYnA0g@mail.gmail.com>
References: <CAMXzGWLStjfXdciYSzQNR9-ywOEmH5TRpQKGCJPTcBjynYnA0g@mail.gmail.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 1/3][xen-netback] add a pseudo pps rate
	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


Thursday, December 18, 2014, 9:13:18 AM, you wrote:

>>On Tue, 2013-07-09 at 16:01 +0200, William Dauchy wrote:
>>> On Jul09 15:48, Sander Eikelenboom wrote:
>>> > Just wondering, why should this be done in the drivers ?
>>> > Couldn't this also be achieved with netfilter and the recent/limit modules ?
>>> > The limit module can already handle bursts.
>>>
>>> We indeed forgot to talk about it since we already got the question from
>>> Wei.
>>> The first thing is that your comment is also true for bandwidth which is
>>> already present. Moreover PPS is linked to bandwidth.
>>> By using netfilter, PPS shaping is done on backend level, once packet
>>> has left the VM; which means after using an additional memory transaction
>>> to copy packet from frontend. IMHO, at scale, shaping in this way should
>>> save some memory transactions comparing to netfilter.
>>
>>Have you tried the netfilter approach and found it to be insufficient in
>>practice?
>>
>>I'm not sure how netfilter recent/limit is implemented but if it queues
>>rather than drops you would naturally find that you end up with back
>>pressure onto the netback device where the ring would fill with
>>in-progress requests and therefore netback would have to stop processing
>>more packets.
>>
>>Ian.
>>

> The maximum limit rate of the netfilter limit module is 10000/s that is too
>  small nowadays. Even if the size of the packet is 1500, the bandwidth is
> as small as 14 MiB. So it is not a good practise to use the limit module.

> $  sudo iptables -I INPUT -m limit --limit 10001/s --limit-burst 100 -j RETURN
> iptables v1.4.19.1: Rate too fast "10001/s"


And using TC / qdisc ? (http://lartc.org/manpages/tc.txt)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:07:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:07:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1XzP-0003Kj-1j; Thu, 18 Dec 2014 10:07:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1XzN-0003Ke-50
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 10:07:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BA/8B-25276-857A2945; Thu, 18 Dec 2014 10:07:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418897239!16412484!1
X-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 25606 invoked from network); 18 Dec 2014 10:07:20 -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; 18 Dec 2014 10:07:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 10:07:18 +0000
Message-Id: <5492B5650200007800050844@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 10:07:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-32424-mainreport@xen.org>
In-Reply-To: <osstest-32424-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] 32424: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 16:43, <Ian.Jackson@eu.citrix.com> wrote:
> flight 32424 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32424/ 
> 
> 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. 32392

Hmm, the mites develop that swiotlb problem now too. Was there
anything changed on them?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:07:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:07:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1XzP-0003Kj-1j; Thu, 18 Dec 2014 10:07:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1XzN-0003Ke-50
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 10:07:21 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BA/8B-25276-857A2945; Thu, 18 Dec 2014 10:07:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418897239!16412484!1
X-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 25606 invoked from network); 18 Dec 2014 10:07:20 -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; 18 Dec 2014 10:07:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 10:07:18 +0000
Message-Id: <5492B5650200007800050844@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 10:07:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-32424-mainreport@xen.org>
In-Reply-To: <osstest-32424-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] 32424: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 16:43, <Ian.Jackson@eu.citrix.com> wrote:
> flight 32424 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32424/ 
> 
> 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. 32392

Hmm, the mites develop that swiotlb problem now too. Was there
anything changed on them?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:17:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:17:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Y91-0003nR-6X; Thu, 18 Dec 2014 10:17:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wenjianhn@gmail.com>) id 1Y1Y8z-0003nM-Ld
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:17:17 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	56/E8-18267-CA9A2945; Thu, 18 Dec 2014 10:17:16 +0000
X-Env-Sender: wenjianhn@gmail.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418897834!10560496!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19946 invoked from network); 18 Dec 2014 10:17:14 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 10:17:14 -0000
Received: by mail-wi0-f182.google.com with SMTP id h11so1239567wiw.3
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 02:17:14 -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=24/KkDAJmEniuuAOsewfK7Cmi+wJSuepDG0JU8cfqv4=;
	b=i/AxtlOgLzb7zBF/PIv8b3M/ayE9JFkxA3N+zioy/oG8rwpcz1WMGQUjK3p+FEkoDs
	OTdZE4H3OE2GXsClkM1/iVToQPRKdJPDdhtjKujyAiRIO+Q7CKl/er791FJMpls2jQxp
	8vaKT3ZoBFWyjK56JIFgME77xc4CTVJDj9IYXqChJqc9HEbvHQH/esHMbC5vBFhDvSZU
	UaH1DP712udpO96ggT18Vr8ZyyFqKRvbcHVYzHY90ilrND9vIuIyz4+o6sorLYCnHxd4
	MHu9d+CIiusftbZXJUV3vBcUiUNcw888sNly3JeErrGUp0zKLZxmJs0Wsf/kt5jNei1H
	0sBg==
X-Received: by 10.181.8.193 with SMTP id dm1mr22545708wid.55.1418897834444;
	Thu, 18 Dec 2014 02:17:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.139.82 with HTTP; Thu, 18 Dec 2014 02:16:34 -0800 (PST)
In-Reply-To: <17310344164.20141218110040@eikelenboom.it>
References: <CAMXzGWLStjfXdciYSzQNR9-ywOEmH5TRpQKGCJPTcBjynYnA0g@mail.gmail.com>
	<17310344164.20141218110040@eikelenboom.it>
From: Jian Wen <wenjianhn@gmail.com>
Date: Thu, 18 Dec 2014 18:16:34 +0800
Message-ID: <CAMXzGWKcuoiPvW6QvDbQBVy1c-ZX1sQ9RHO7=10YbeswXGi7zw@mail.gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 1/3][xen-netback] add a pseudo pps rate
	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

AFAIK, TC doesn't support limiting packets per second.

2014-12-18 18:00 GMT+08:00 Sander Eikelenboom <linux@eikelenboom.it>:
>
> Thursday, December 18, 2014, 9:13:18 AM, you wrote:
>
>>>On Tue, 2013-07-09 at 16:01 +0200, William Dauchy wrote:
>>>> On Jul09 15:48, Sander Eikelenboom wrote:
>>>> > Just wondering, why should this be done in the drivers ?
>>>> > Couldn't this also be achieved with netfilter and the recent/limit modules ?
>>>> > The limit module can already handle bursts.
>>>>
>>>> We indeed forgot to talk about it since we already got the question from
>>>> Wei.
>>>> The first thing is that your comment is also true for bandwidth which is
>>>> already present. Moreover PPS is linked to bandwidth.
>>>> By using netfilter, PPS shaping is done on backend level, once packet
>>>> has left the VM; which means after using an additional memory transaction
>>>> to copy packet from frontend. IMHO, at scale, shaping in this way should
>>>> save some memory transactions comparing to netfilter.
>>>
>>>Have you tried the netfilter approach and found it to be insufficient in
>>>practice?
>>>
>>>I'm not sure how netfilter recent/limit is implemented but if it queues
>>>rather than drops you would naturally find that you end up with back
>>>pressure onto the netback device where the ring would fill with
>>>in-progress requests and therefore netback would have to stop processing
>>>more packets.
>>>
>>>Ian.
>>>
>
>> The maximum limit rate of the netfilter limit module is 10000/s that is too
>>  small nowadays. Even if the size of the packet is 1500, the bandwidth is
>> as small as 14 MiB. So it is not a good practise to use the limit module.
>
>> $  sudo iptables -I INPUT -m limit --limit 10001/s --limit-burst 100 -j RETURN
>> iptables v1.4.19.1: Rate too fast "10001/s"
>
>
> And using TC / qdisc ? (http://lartc.org/manpages/tc.txt)
>



-- 
Best,

Jian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:17:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:17:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Y91-0003nR-6X; Thu, 18 Dec 2014 10:17:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wenjianhn@gmail.com>) id 1Y1Y8z-0003nM-Ld
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:17:17 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	56/E8-18267-CA9A2945; Thu, 18 Dec 2014 10:17:16 +0000
X-Env-Sender: wenjianhn@gmail.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418897834!10560496!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19946 invoked from network); 18 Dec 2014 10:17:14 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 10:17:14 -0000
Received: by mail-wi0-f182.google.com with SMTP id h11so1239567wiw.3
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 02:17:14 -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=24/KkDAJmEniuuAOsewfK7Cmi+wJSuepDG0JU8cfqv4=;
	b=i/AxtlOgLzb7zBF/PIv8b3M/ayE9JFkxA3N+zioy/oG8rwpcz1WMGQUjK3p+FEkoDs
	OTdZE4H3OE2GXsClkM1/iVToQPRKdJPDdhtjKujyAiRIO+Q7CKl/er791FJMpls2jQxp
	8vaKT3ZoBFWyjK56JIFgME77xc4CTVJDj9IYXqChJqc9HEbvHQH/esHMbC5vBFhDvSZU
	UaH1DP712udpO96ggT18Vr8ZyyFqKRvbcHVYzHY90ilrND9vIuIyz4+o6sorLYCnHxd4
	MHu9d+CIiusftbZXJUV3vBcUiUNcw888sNly3JeErrGUp0zKLZxmJs0Wsf/kt5jNei1H
	0sBg==
X-Received: by 10.181.8.193 with SMTP id dm1mr22545708wid.55.1418897834444;
	Thu, 18 Dec 2014 02:17:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.139.82 with HTTP; Thu, 18 Dec 2014 02:16:34 -0800 (PST)
In-Reply-To: <17310344164.20141218110040@eikelenboom.it>
References: <CAMXzGWLStjfXdciYSzQNR9-ywOEmH5TRpQKGCJPTcBjynYnA0g@mail.gmail.com>
	<17310344164.20141218110040@eikelenboom.it>
From: Jian Wen <wenjianhn@gmail.com>
Date: Thu, 18 Dec 2014 18:16:34 +0800
Message-ID: <CAMXzGWKcuoiPvW6QvDbQBVy1c-ZX1sQ9RHO7=10YbeswXGi7zw@mail.gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 1/3][xen-netback] add a pseudo pps rate
	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

AFAIK, TC doesn't support limiting packets per second.

2014-12-18 18:00 GMT+08:00 Sander Eikelenboom <linux@eikelenboom.it>:
>
> Thursday, December 18, 2014, 9:13:18 AM, you wrote:
>
>>>On Tue, 2013-07-09 at 16:01 +0200, William Dauchy wrote:
>>>> On Jul09 15:48, Sander Eikelenboom wrote:
>>>> > Just wondering, why should this be done in the drivers ?
>>>> > Couldn't this also be achieved with netfilter and the recent/limit modules ?
>>>> > The limit module can already handle bursts.
>>>>
>>>> We indeed forgot to talk about it since we already got the question from
>>>> Wei.
>>>> The first thing is that your comment is also true for bandwidth which is
>>>> already present. Moreover PPS is linked to bandwidth.
>>>> By using netfilter, PPS shaping is done on backend level, once packet
>>>> has left the VM; which means after using an additional memory transaction
>>>> to copy packet from frontend. IMHO, at scale, shaping in this way should
>>>> save some memory transactions comparing to netfilter.
>>>
>>>Have you tried the netfilter approach and found it to be insufficient in
>>>practice?
>>>
>>>I'm not sure how netfilter recent/limit is implemented but if it queues
>>>rather than drops you would naturally find that you end up with back
>>>pressure onto the netback device where the ring would fill with
>>>in-progress requests and therefore netback would have to stop processing
>>>more packets.
>>>
>>>Ian.
>>>
>
>> The maximum limit rate of the netfilter limit module is 10000/s that is too
>>  small nowadays. Even if the size of the packet is 1500, the bandwidth is
>> as small as 14 MiB. So it is not a good practise to use the limit module.
>
>> $  sudo iptables -I INPUT -m limit --limit 10001/s --limit-burst 100 -j RETURN
>> iptables v1.4.19.1: Rate too fast "10001/s"
>
>
> And using TC / qdisc ? (http://lartc.org/manpages/tc.txt)
>



-- 
Best,

Jian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:17:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Y9a-0003pl-JM; Thu, 18 Dec 2014 10:17: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 1Y1Y9Z-0003pb-7G
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:17:53 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	45/70-19763-0D9A2945; Thu, 18 Dec 2014 10:17:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418897870!14060203!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 17032 invoked from network); 18 Dec 2014 10:17:51 -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 Dec 2014 10:17:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206197085"
Message-ID: <1418897867.11882.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <freddy77@gmail.com>
Date: Thu, 18 Dec 2014 10:17:47 +0000
In-Reply-To: <CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Xen-devel@lists.xen.org, David
	Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>
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 Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
> Do we have a bug in Xen that affect SSE instructions (possibly already
> fixed after Philipp version) ?

I've had a niggling feeling of Deja Vu over this which I'd been putting
down to an old Xen on ARM bug in the area of FPU register switching.

But it seems at some point (possibly even still) there was a similar
issue with pvops kernels on x86, see:
        http://bugs.xenproject.org/xen/bug/40

Philipp, what kernel are you guys using?

CCing Jan and the x86 kernel guys (and George since he registered the
bug). I'm not seeing anything in the kernel logs which looks like a fix
(there's some PVH related cr0 frobbing, but I don't think that's it).

I also can't quite shake the feeling that there was another much older
issue relating to FPU context switch on x86, but I think that was truly
ancient history (2.6.18 era stuff)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:17:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Y9a-0003pl-JM; Thu, 18 Dec 2014 10:17: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 1Y1Y9Z-0003pb-7G
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:17:53 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	45/70-19763-0D9A2945; Thu, 18 Dec 2014 10:17:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418897870!14060203!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 17032 invoked from network); 18 Dec 2014 10:17:51 -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 Dec 2014 10:17:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206197085"
Message-ID: <1418897867.11882.11.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <freddy77@gmail.com>
Date: Thu, 18 Dec 2014 10:17:47 +0000
In-Reply-To: <CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Xen-devel@lists.xen.org, David
	Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>
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 Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
> Do we have a bug in Xen that affect SSE instructions (possibly already
> fixed after Philipp version) ?

I've had a niggling feeling of Deja Vu over this which I'd been putting
down to an old Xen on ARM bug in the area of FPU register switching.

But it seems at some point (possibly even still) there was a similar
issue with pvops kernels on x86, see:
        http://bugs.xenproject.org/xen/bug/40

Philipp, what kernel are you guys using?

CCing Jan and the x86 kernel guys (and George since he registered the
bug). I'm not seeing anything in the kernel logs which looks like a fix
(there's some PVH related cr0 frobbing, but I don't think that's it).

I also can't quite shake the feeling that there was another much older
issue relating to FPU context switch on x86, but I think that was truly
ancient history (2.6.18 era stuff)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:18:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10: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 1Y1YAR-0003vu-15; Thu, 18 Dec 2014 10:18:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1YAP-0003vh-FU
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:18:45 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	A4/61-28865-40AA2945; Thu, 18 Dec 2014 10:18:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418897922!8659348!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 4187 invoked from network); 18 Dec 2014 10:18:44 -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 Dec 2014 10:18:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="205723926"
Message-ID: <1418897920.11882.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 18 Dec 2014 10:18:40 +0000
In-Reply-To: <20141216225546.GA20393@zion.uk.xensource.com>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com> <1417176581.23604.25.camel@citrix.com>
	<20141201211117.GF22021@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412162036540.9237@procyon.dur.ac.uk>
	<20141216215546.GA19797@zion.uk.xensource.com>
	<alpine.DEB.2.00.1412162203060.9237@procyon.dur.ac.uk>
	<20141216225546.GA20393@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: 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] 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 Tue, 2014-12-16 at 22:55 +0000, Wei Liu wrote:
> On Tue, Dec 16, 2014 at 10:04:25PM +0000, M A Young wrote:
> > On Tue, 16 Dec 2014, Wei Liu wrote:
> > 
> > >On Tue, Dec 16, 2014 at 08:38:42PM +0000, M A Young wrote:
> > >[...]
> > >>Is this patch going to get committed in time for xen 4.5?
> > >>
> > >
> > >Yes. See d36a3734a6.
> > >
> > >And there's a subsequence patch to fix a regression caused by that
> > >patch. See 09b7ff1a.
> > >
> > >Wei.
> > 
> > No that is the other bug in xl migrate --debug (it fails rather than
> > segfaults).
> > 
> 
> Ah, I misread. Sorry.

I think I'd confused the two as well. 

I've now applied the thing from
<alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>.

I had to jump through several hoops, first because of the attachment
containing the patch but the body containing the S-o-b and second
because the patch used DOS line endings.

Please could you investigate the use of git format-patch and/or git
send-email for future patch submissions (see
http://wiki.xen.org/wiki/Submitting_Xen_Patches for some hints on
driving those tools).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:18:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10: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 1Y1YAR-0003vu-15; Thu, 18 Dec 2014 10:18:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1YAP-0003vh-FU
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:18:45 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	A4/61-28865-40AA2945; Thu, 18 Dec 2014 10:18:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418897922!8659348!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 4187 invoked from network); 18 Dec 2014 10:18:44 -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 Dec 2014 10:18:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="205723926"
Message-ID: <1418897920.11882.12.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 18 Dec 2014 10:18:40 +0000
In-Reply-To: <20141216225546.GA20393@zion.uk.xensource.com>
References: <alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>
	<547643C8.5000806@citrix.com> <1417176581.23604.25.camel@citrix.com>
	<20141201211117.GF22021@laptop.dumpdata.com>
	<alpine.DEB.2.00.1412162036540.9237@procyon.dur.ac.uk>
	<20141216215546.GA19797@zion.uk.xensource.com>
	<alpine.DEB.2.00.1412162203060.9237@procyon.dur.ac.uk>
	<20141216225546.GA20393@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: 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] 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 Tue, 2014-12-16 at 22:55 +0000, Wei Liu wrote:
> On Tue, Dec 16, 2014 at 10:04:25PM +0000, M A Young wrote:
> > On Tue, 16 Dec 2014, Wei Liu wrote:
> > 
> > >On Tue, Dec 16, 2014 at 08:38:42PM +0000, M A Young wrote:
> > >[...]
> > >>Is this patch going to get committed in time for xen 4.5?
> > >>
> > >
> > >Yes. See d36a3734a6.
> > >
> > >And there's a subsequence patch to fix a regression caused by that
> > >patch. See 09b7ff1a.
> > >
> > >Wei.
> > 
> > No that is the other bug in xl migrate --debug (it fails rather than
> > segfaults).
> > 
> 
> Ah, I misread. Sorry.

I think I'd confused the two as well. 

I've now applied the thing from
<alpine.DEB.2.00.1411261906310.18561@procyon.dur.ac.uk>.

I had to jump through several hoops, first because of the attachment
containing the patch but the body containing the S-o-b and second
because the patch used DOS line endings.

Please could you investigate the use of git format-patch and/or git
send-email for future patch submissions (see
http://wiki.xen.org/wiki/Submitting_Xen_Patches for some hints on
driving those tools).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:20:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:20:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YBz-00045x-Gb; Thu, 18 Dec 2014 10:20:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1Y1YBy-00045p-Hz
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:20:22 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	B5/71-02954-56AA2945; Thu, 18 Dec 2014 10:20:21 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418898020!15851021!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12863 invoked from network); 18 Dec 2014 10:20:20 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 10:20:20 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id 03B071103961;
	Thu, 18 Dec 2014 11:20:19 +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 hONgxCxDktyE; Thu, 18 Dec 2014 11:20:19 +0100 (CET)
Received: from [192.168.178.24] (port-92-196-50-112.dynamic.qsc.de
	[92.196.50.112])
	by solig.knut.univention.de (Postfix) with ESMTPSA id 53CD5110395B;
	Thu, 18 Dec 2014 11:20:19 +0100 (CET)
Message-ID: <5492AA62.4000205@univention.de>
Date: Thu, 18 Dec 2014 11:20:18 +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.3.0
MIME-Version: 1.0
To: Frediano Ziglio <freddy77@gmail.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>	<1415869951.31613.26.camel@citrix.com>	<548B1472.5080302@univention.de>	<1418401932.16425.34.camel@citrix.com>	<548B1BA8.3090504@univention.de>	<1418403387.16425.38.camel@citrix.com>	<548B23FA.6070108@univention.de>	<1418407116.16425.53.camel@citrix.com>	<1418649458.16425.108.camel@citrix.com>	<548EEDF5.20808@univention.de>	<1418655014.16425.138.camel@citrix.com>	<1418665524.16425.171.camel@citrix.com>	<548F60BF.4020901@univention.de>	<1418726712.16425.213.camel@citrix.com>	<1418727970.16425.217.camel@citrix.com>	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>	<1418732635.16425.221.camel@citrix.com>	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>	<1418747029.16425.238.camel@citrix.com>	<CAHt6W4e6mR4cX1MfpJ+drupzzRHjf0SHaJ=y5QRZxh84mq5rBA@mail.gmail.com>
	<CAHt6W4dnDwFpb3CV73JOejjgiVCJuNxE3wX5s3vGKiujAuM1Hg@mail.gmail.com>
In-Reply-To: <CAHt6W4dnDwFpb3CV73JOejjgiVCJuNxE3wX5s3vGKiujAuM1Hg@mail.gmail.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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

Hello,

On 17.12.2014 10:14, Frediano Ziglio wrote:
> 2014-12-16 16:44 GMT+00:00 Frediano Ziglio <freddy77@gmail.com>:
>> 2014-12-16 16:23 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
...
>> First we (I'll try when I reach home) can check if memset in glibc (or
>> the version called from talloc_zero) can use SSE. A possible dmesg
>> output and /proc/cpuinfo content could help too but I think SSE are
>> now quite common.
> 
> I have access to some core dumps. glibc memset is using SSE,
> specifically xmm0 register.
> 
> Unfortunately is seems that core dumps contains only standard
> registers, so all register appears zeroed. If you try with a newer gdb
> version is shows that registers are not available.

I had another look myself and I'm confused now:

Using "info float" or "info vector" with gdb-7.0.1 shows the FP and MMX
registers to be all zero.
A newer gdb-7.2 shows the registers as "unavailable".

"eu-readelf --notes core" doesn't show a NT_FPREGSET note, so to me it
looks like at least the FP-registers were not dumped.
But is that also used for the MMX registers? If my memory is right, the
FP and MMX registers are "shared" in the CPU, but that might be old
knowledge.

I wrote a small SSE using program, which dumps core. If I run that
locally and do a "readelf --notes core", I get:
  CORE          0x00000200      NT_FPREGSET (floating point registers)

If I do the same in dom0, I don't get that note and gdb doesn't show the
register content.
SSE seems to be available in the dom0, as the program would crash with
SIGILL otherwise:
# grep ^flags /proc/cpuinfo
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 est ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor
lahf_lm ida dtherm

Look like that got fixed with a newer 3.10.61 kernel, so I'll urge our
admins to update to a later kernel (again), so we'll get more useful
core dumps for future crashes.

I'm still investigating the core files of the other programs, but it
takes some time. I don't know if I will be able to finish that in time,
as the Christmas holiday season starts tomorrow and I will be
unavailable for nearly two weeks,

So happy Christmas to everybody and thanks again for your help.

Philipp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:20:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:20:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YBz-00045x-Gb; Thu, 18 Dec 2014 10:20:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1Y1YBy-00045p-Hz
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:20:22 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	B5/71-02954-56AA2945; Thu, 18 Dec 2014 10:20:21 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418898020!15851021!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12863 invoked from network); 18 Dec 2014 10:20:20 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 10:20:20 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id 03B071103961;
	Thu, 18 Dec 2014 11:20:19 +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 hONgxCxDktyE; Thu, 18 Dec 2014 11:20:19 +0100 (CET)
Received: from [192.168.178.24] (port-92-196-50-112.dynamic.qsc.de
	[92.196.50.112])
	by solig.knut.univention.de (Postfix) with ESMTPSA id 53CD5110395B;
	Thu, 18 Dec 2014 11:20:19 +0100 (CET)
Message-ID: <5492AA62.4000205@univention.de>
Date: Thu, 18 Dec 2014 11:20:18 +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.3.0
MIME-Version: 1.0
To: Frediano Ziglio <freddy77@gmail.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>	<1415869951.31613.26.camel@citrix.com>	<548B1472.5080302@univention.de>	<1418401932.16425.34.camel@citrix.com>	<548B1BA8.3090504@univention.de>	<1418403387.16425.38.camel@citrix.com>	<548B23FA.6070108@univention.de>	<1418407116.16425.53.camel@citrix.com>	<1418649458.16425.108.camel@citrix.com>	<548EEDF5.20808@univention.de>	<1418655014.16425.138.camel@citrix.com>	<1418665524.16425.171.camel@citrix.com>	<548F60BF.4020901@univention.de>	<1418726712.16425.213.camel@citrix.com>	<1418727970.16425.217.camel@citrix.com>	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>	<1418732635.16425.221.camel@citrix.com>	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>	<1418747029.16425.238.camel@citrix.com>	<CAHt6W4e6mR4cX1MfpJ+drupzzRHjf0SHaJ=y5QRZxh84mq5rBA@mail.gmail.com>
	<CAHt6W4dnDwFpb3CV73JOejjgiVCJuNxE3wX5s3vGKiujAuM1Hg@mail.gmail.com>
In-Reply-To: <CAHt6W4dnDwFpb3CV73JOejjgiVCJuNxE3wX5s3vGKiujAuM1Hg@mail.gmail.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, 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

Hello,

On 17.12.2014 10:14, Frediano Ziglio wrote:
> 2014-12-16 16:44 GMT+00:00 Frediano Ziglio <freddy77@gmail.com>:
>> 2014-12-16 16:23 GMT+00:00 Ian Campbell <Ian.Campbell@citrix.com>:
...
>> First we (I'll try when I reach home) can check if memset in glibc (or
>> the version called from talloc_zero) can use SSE. A possible dmesg
>> output and /proc/cpuinfo content could help too but I think SSE are
>> now quite common.
> 
> I have access to some core dumps. glibc memset is using SSE,
> specifically xmm0 register.
> 
> Unfortunately is seems that core dumps contains only standard
> registers, so all register appears zeroed. If you try with a newer gdb
> version is shows that registers are not available.

I had another look myself and I'm confused now:

Using "info float" or "info vector" with gdb-7.0.1 shows the FP and MMX
registers to be all zero.
A newer gdb-7.2 shows the registers as "unavailable".

"eu-readelf --notes core" doesn't show a NT_FPREGSET note, so to me it
looks like at least the FP-registers were not dumped.
But is that also used for the MMX registers? If my memory is right, the
FP and MMX registers are "shared" in the CPU, but that might be old
knowledge.

I wrote a small SSE using program, which dumps core. If I run that
locally and do a "readelf --notes core", I get:
  CORE          0x00000200      NT_FPREGSET (floating point registers)

If I do the same in dom0, I don't get that note and gdb doesn't show the
register content.
SSE seems to be available in the dom0, as the program would crash with
SIGILL otherwise:
# grep ^flags /proc/cpuinfo
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 est ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor
lahf_lm ida dtherm

Look like that got fixed with a newer 3.10.61 kernel, so I'll urge our
admins to update to a later kernel (again), so we'll get more useful
core dumps for future crashes.

I'm still investigating the core files of the other programs, but it
takes some time. I don't know if I will be able to finish that in time,
as the Christmas holiday season starts tomorrow and I will be
unavailable for nearly two weeks,

So happy Christmas to everybody and thanks again for your help.

Philipp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:25:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:25:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YGh-0004fz-Ik; Thu, 18 Dec 2014 10:25: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 1Y1YGg-0004fu-Ji
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:25:14 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	0C/E0-28865-98BA2945; Thu, 18 Dec 2014 10:25:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418898311!14055892!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 2590 invoked from network); 18 Dec 2014 10:25:13 -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;
	18 Dec 2014 10:25:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="205725401"
Message-ID: <1418898309.11882.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 18 Dec 2014 10:25:09 +0000
In-Reply-To: <20141217205455.GB1829@laptop.dumpdata.com>
References: <321a64dc64db335460b51becfc040f4cb0e84a9e.1407146305.git.ian.campbell@citrix.com>
	<1418637751.16425.64.camel@citrix.com>
	<20141217205455.GB1829@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Bastian Blank <waldi@debian.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: libxl: link libxlu against 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-12-17 at 15:54 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 15, 2014 at 10:02:31AM +0000, Ian Campbell wrote:
> > On Mon, 2014-08-04 at 10:58 +0100, Ian Campbell wrote:
> > 
> > Ping again. This issue has resurfaced in the Debian packaging of the 4.5
> > rcs. I think we should fix this for 4.5, the risks are minimal.
> 
> Ah, the patch did not have 'for-xen-4.5' in it :-P

I originally posted this patch at the start of August, when it wouldn't
have needed one, I forgot to add one now.

> > 
> > > It uses libxl_defbool_set and must therefore be linked against the
> > > right library.
> > > 
> > > Spotted by dpkg-shlibdeps and pointed out by Bastian Blank:
> > > 
> > > dpkg-shlibdeps: warning: symbol libxl_defbool_set used by debian/libxen-4.4/usr/lib/libxlutil-4.4.so found in none of the libraries
> > > 
> > > This required switching the make rule from $^ to an explicit
> > > LIBXLU_OBJS since the former now includes libxenlight.so.
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Bastian Blank <waldi@debian.org>
> 
> Shouldn't this be 'Reported-by: "

Yes, I think it should.

> Anyhow,
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks. This still needs an maintainer ack from someone other than me.
Adding Wei who became a maintainer since i originally posted the patch.

> > > ---
> > >  tools/libxl/Makefile |    6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> > > index bd0db3b..e61048d 100644
> > > --- a/tools/libxl/Makefile
> > > +++ b/tools/libxl/Makefile
> > > @@ -35,7 +35,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
> > >  LIBXL_LIBS += $(PTHREAD_LIBS)
> > >  LIBXL_LIBS += $(LIBXL_LIBS-y)
> > >  
> > > -LIBXLU_LIBS =
> > > +LIBXLU_LIBS = libxenlight.so
> > >  
> > >  LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
> > >  ifeq ($(LIBXL_BLKTAP),y)
> > > @@ -213,8 +213,8 @@ libxlutil.so: libxlutil.so.$(XLUMAJOR)
> > >  libxlutil.so.$(XLUMAJOR): libxlutil.so.$(XLUMAJOR).$(XLUMINOR)
> > >  	$(SYMLINK_SHLIB) $< $@
> > >  
> > > -libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS)
> > > -	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxlutil.so.$(XLUMAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXLU_LIBS) $(APPEND_LDFLAGS)
> > > +libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS) libxenlight.so
> > > +	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxlutil.so.$(XLUMAJOR) $(SHLIB_LDFLAGS) -o $@ $(LIBXLU_OBJS) $(LIBXLU_LIBS) $(APPEND_LDFLAGS)
> > >  
> > >  libxlutil.a: $(LIBXLU_OBJS)
> > >  	$(AR) rcs libxlutil.a $^
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:25:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:25:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YGo-0004h2-3V; Thu, 18 Dec 2014 10:25:22 +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 1Y1YGm-0004ge-9s
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:25:20 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	1D/C8-17958-F8BA2945; Thu, 18 Dec 2014 10:25:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418898317!14276552!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3121 invoked from network); 18 Dec 2014 10:25:18 -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;
	18 Dec 2014 10:25:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206198741"
Message-ID: <5492AB8B.90201@citrix.com>
Date: Thu, 18 Dec 2014 10:25:15 +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: Ian Campbell <Ian.Campbell@citrix.com>, Frediano Ziglio
	<freddy77@gmail.com>
References: <546461A2.2070908@univention.de>	
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>	
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>	
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>	
	<1418407116.16425.53.camel@citrix.com>	
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>	
	<1418655014.16425.138.camel@citrix.com>	
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>	
	<1418726712.16425.213.camel@citrix.com>	
	<1418727970.16425.217.camel@citrix.com>	
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>	
	<1418732635.16425.221.camel@citrix.com>	
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418897867.11882.11.camel@citrix.com>
In-Reply-To: <1418897867.11882.11.camel@citrix.com>
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>
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 18/12/14 10:17, Ian Campbell wrote:
> On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
>> Do we have a bug in Xen that affect SSE instructions (possibly already
>> fixed after Philipp version) ?
> 
> I've had a niggling feeling of Deja Vu over this which I'd been putting
> down to an old Xen on ARM bug in the area of FPU register switching.
> 
> But it seems at some point (possibly even still) there was a similar
> issue with pvops kernels on x86, see:
>         http://bugs.xenproject.org/xen/bug/40
> 
> Philipp, what kernel are you guys using?
> 
> CCing Jan and the x86 kernel guys (and George since he registered the
> bug). I'm not seeing anything in the kernel logs which looks like a fix
> (there's some PVH related cr0 frobbing, but I don't think that's it).
> 
> I also can't quite shake the feeling that there was another much older
> issue relating to FPU context switch on x86, but I think that was truly
> ancient history (2.6.18 era stuff)

http://marc.info/?l=linux-kernel&m=139132566024357

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:25:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:25:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YGh-0004fz-Ik; Thu, 18 Dec 2014 10:25: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 1Y1YGg-0004fu-Ji
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:25:14 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	0C/E0-28865-98BA2945; Thu, 18 Dec 2014 10:25:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418898311!14055892!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 2590 invoked from network); 18 Dec 2014 10:25:13 -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;
	18 Dec 2014 10:25:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="205725401"
Message-ID: <1418898309.11882.16.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 18 Dec 2014 10:25:09 +0000
In-Reply-To: <20141217205455.GB1829@laptop.dumpdata.com>
References: <321a64dc64db335460b51becfc040f4cb0e84a9e.1407146305.git.ian.campbell@citrix.com>
	<1418637751.16425.64.camel@citrix.com>
	<20141217205455.GB1829@laptop.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: Bastian Blank <waldi@debian.org>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: libxl: link libxlu against 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-12-17 at 15:54 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 15, 2014 at 10:02:31AM +0000, Ian Campbell wrote:
> > On Mon, 2014-08-04 at 10:58 +0100, Ian Campbell wrote:
> > 
> > Ping again. This issue has resurfaced in the Debian packaging of the 4.5
> > rcs. I think we should fix this for 4.5, the risks are minimal.
> 
> Ah, the patch did not have 'for-xen-4.5' in it :-P

I originally posted this patch at the start of August, when it wouldn't
have needed one, I forgot to add one now.

> > 
> > > It uses libxl_defbool_set and must therefore be linked against the
> > > right library.
> > > 
> > > Spotted by dpkg-shlibdeps and pointed out by Bastian Blank:
> > > 
> > > dpkg-shlibdeps: warning: symbol libxl_defbool_set used by debian/libxen-4.4/usr/lib/libxlutil-4.4.so found in none of the libraries
> > > 
> > > This required switching the make rule from $^ to an explicit
> > > LIBXLU_OBJS since the former now includes libxenlight.so.
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Bastian Blank <waldi@debian.org>
> 
> Shouldn't this be 'Reported-by: "

Yes, I think it should.

> Anyhow,
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks. This still needs an maintainer ack from someone other than me.
Adding Wei who became a maintainer since i originally posted the patch.

> > > ---
> > >  tools/libxl/Makefile |    6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> > > index bd0db3b..e61048d 100644
> > > --- a/tools/libxl/Makefile
> > > +++ b/tools/libxl/Makefile
> > > @@ -35,7 +35,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
> > >  LIBXL_LIBS += $(PTHREAD_LIBS)
> > >  LIBXL_LIBS += $(LIBXL_LIBS-y)
> > >  
> > > -LIBXLU_LIBS =
> > > +LIBXLU_LIBS = libxenlight.so
> > >  
> > >  LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
> > >  ifeq ($(LIBXL_BLKTAP),y)
> > > @@ -213,8 +213,8 @@ libxlutil.so: libxlutil.so.$(XLUMAJOR)
> > >  libxlutil.so.$(XLUMAJOR): libxlutil.so.$(XLUMAJOR).$(XLUMINOR)
> > >  	$(SYMLINK_SHLIB) $< $@
> > >  
> > > -libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS)
> > > -	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxlutil.so.$(XLUMAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXLU_LIBS) $(APPEND_LDFLAGS)
> > > +libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS) libxenlight.so
> > > +	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxlutil.so.$(XLUMAJOR) $(SHLIB_LDFLAGS) -o $@ $(LIBXLU_OBJS) $(LIBXLU_LIBS) $(APPEND_LDFLAGS)
> > >  
> > >  libxlutil.a: $(LIBXLU_OBJS)
> > >  	$(AR) rcs libxlutil.a $^
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:25:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:25:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YGo-0004h2-3V; Thu, 18 Dec 2014 10:25:22 +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 1Y1YGm-0004ge-9s
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:25:20 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	1D/C8-17958-F8BA2945; Thu, 18 Dec 2014 10:25:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418898317!14276552!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 3121 invoked from network); 18 Dec 2014 10:25:18 -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;
	18 Dec 2014 10:25:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206198741"
Message-ID: <5492AB8B.90201@citrix.com>
Date: Thu, 18 Dec 2014 10:25:15 +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: Ian Campbell <Ian.Campbell@citrix.com>, Frediano Ziglio
	<freddy77@gmail.com>
References: <546461A2.2070908@univention.de>	
	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>	
	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>	
	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>	
	<1418407116.16425.53.camel@citrix.com>	
	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>	
	<1418655014.16425.138.camel@citrix.com>	
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>	
	<1418726712.16425.213.camel@citrix.com>	
	<1418727970.16425.217.camel@citrix.com>	
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>	
	<1418732635.16425.221.camel@citrix.com>	
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418897867.11882.11.camel@citrix.com>
In-Reply-To: <1418897867.11882.11.camel@citrix.com>
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>
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 18/12/14 10:17, Ian Campbell wrote:
> On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
>> Do we have a bug in Xen that affect SSE instructions (possibly already
>> fixed after Philipp version) ?
> 
> I've had a niggling feeling of Deja Vu over this which I'd been putting
> down to an old Xen on ARM bug in the area of FPU register switching.
> 
> But it seems at some point (possibly even still) there was a similar
> issue with pvops kernels on x86, see:
>         http://bugs.xenproject.org/xen/bug/40
> 
> Philipp, what kernel are you guys using?
> 
> CCing Jan and the x86 kernel guys (and George since he registered the
> bug). I'm not seeing anything in the kernel logs which looks like a fix
> (there's some PVH related cr0 frobbing, but I don't think that's it).
> 
> I also can't quite shake the feeling that there was another much older
> issue relating to FPU context switch on x86, but I think that was truly
> ancient history (2.6.18 era stuff)

http://marc.info/?l=linux-kernel&m=139132566024357

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:41:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YVy-0005Kl-Mk; Thu, 18 Dec 2014 10:41:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1YVx-0005Kg-Vk
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 10:41:02 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	EA/E4-24859-D3FA2945; Thu, 18 Dec 2014 10:41:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418899260!14307701!1
X-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 24027 invoked from network); 18 Dec 2014 10:41:00 -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; 18 Dec 2014 10:41:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 10:41:00 +0000
Message-Id: <5492BD4C0200007800050873@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 10:41:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <54906D3D.2060807@citrix.com> <549072FE.40500@citrix.com>
	<54917C62.709@citrix.com>
In-Reply-To: <54917C62.709@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] IO-APIC interrupts getting stuck
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 13:51, <roger.pau@citrix.com> wrote:
> I've also added the following patch to Xen, and it reliably triggers on 
> FreeBSD, while it seems to work fine on Linux:
> 
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -1729,6 +1729,8 @@ static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 vector)
>   * The idea is from Manfred Spraul.  --macro
>   */
>      unsigned int v, i = desc->arch.vector;
> +    struct IO_APIC_route_entry rte;
> +    struct irq_pin_list *entry = irq_2_pin + desc->irq;
>  
>      /* Manually EOI the old vector if we are moving to the new */
>      if ( vector && i != vector )
> @@ -1751,6 +1753,9 @@ static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 vector)
>              __unmask_IO_APIC_irq(desc->irq);
>          spin_unlock(&ioapic_lock);
>      }
> +
> +    rte = ioapic_read_entry(entry->apic, entry->pin, 0);
> +    ASSERT(rte.irr == 0 || rte.mask != 0);

Could you arrange for you to be able to determine which code
paths were taken in the routine when the ASSERT() triggers? I.e.
minimally make sure vector, i, and v can be determined from the
printed registers and stack contents. Plus maybe also read the
applicable APIC_I[RS]R bits.

And you're also apparently not seeing this on a system where
Linux'es IO-APIC re-route workaround might come into play (see
drivers/pci/quirks.c:quirk_reroute_to_boot_interrupts_intel()),
which then I would have suspected FreeBSD to not have such a
workaround...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:41:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YVy-0005Kl-Mk; Thu, 18 Dec 2014 10:41:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1YVx-0005Kg-Vk
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 10:41:02 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	EA/E4-24859-D3FA2945; Thu, 18 Dec 2014 10:41:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418899260!14307701!1
X-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 24027 invoked from network); 18 Dec 2014 10:41:00 -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; 18 Dec 2014 10:41:00 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 10:41:00 +0000
Message-Id: <5492BD4C0200007800050873@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 10:41:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <54906D3D.2060807@citrix.com> <549072FE.40500@citrix.com>
	<54917C62.709@citrix.com>
In-Reply-To: <54917C62.709@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] IO-APIC interrupts getting stuck
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 13:51, <roger.pau@citrix.com> wrote:
> I've also added the following patch to Xen, and it reliably triggers on 
> FreeBSD, while it seems to work fine on Linux:
> 
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -1729,6 +1729,8 @@ static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 vector)
>   * The idea is from Manfred Spraul.  --macro
>   */
>      unsigned int v, i = desc->arch.vector;
> +    struct IO_APIC_route_entry rte;
> +    struct irq_pin_list *entry = irq_2_pin + desc->irq;
>  
>      /* Manually EOI the old vector if we are moving to the new */
>      if ( vector && i != vector )
> @@ -1751,6 +1753,9 @@ static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 vector)
>              __unmask_IO_APIC_irq(desc->irq);
>          spin_unlock(&ioapic_lock);
>      }
> +
> +    rte = ioapic_read_entry(entry->apic, entry->pin, 0);
> +    ASSERT(rte.irr == 0 || rte.mask != 0);

Could you arrange for you to be able to determine which code
paths were taken in the routine when the ASSERT() triggers? I.e.
minimally make sure vector, i, and v can be determined from the
printed registers and stack contents. Plus maybe also read the
applicable APIC_I[RS]R bits.

And you're also apparently not seeing this on a system where
Linux'es IO-APIC re-route workaround might come into play (see
drivers/pci/quirks.c:quirk_reroute_to_boot_interrupts_intel()),
which then I would have suspected FreeBSD to not have such a
workaround...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:48:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:48:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Ycg-0005oH-MX; Thu, 18 Dec 2014 10:47:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Y1Ycf-0005oC-KL
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:47:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	03/49-09842-CD0B2945; Thu, 18 Dec 2014 10:47:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418899675!16465679!1
X-Originating-IP: [66.165.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 14542 invoked from network); 18 Dec 2014 10:47:56 -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;
	18 Dec 2014 10:47:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206203692"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 18 Dec 2014 05:47: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 1Y1Ycc-0002Un-0N;
	Thu, 18 Dec 2014 10:47:54 +0000
Date: Thu, 18 Dec 2014 10:47:53 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141218104753.GK1904@zion.uk.xensource.com>
References: <321a64dc64db335460b51becfc040f4cb0e84a9e.1407146305.git.ian.campbell@citrix.com>
	<1418637751.16425.64.camel@citrix.com>
	<20141217205455.GB1829@laptop.dumpdata.com>
	<1418898309.11882.16.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418898309.11882.16.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Bastian Blank <waldi@debian.org>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: libxl: link libxlu against 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

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 Thu Dec 18 10:48:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:48:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Ycg-0005oH-MX; Thu, 18 Dec 2014 10:47:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Y1Ycf-0005oC-KL
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:47:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	03/49-09842-CD0B2945; Thu, 18 Dec 2014 10:47:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418899675!16465679!1
X-Originating-IP: [66.165.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 14542 invoked from network); 18 Dec 2014 10:47:56 -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;
	18 Dec 2014 10:47:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206203692"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 18 Dec 2014 05:47: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 1Y1Ycc-0002Un-0N;
	Thu, 18 Dec 2014 10:47:54 +0000
Date: Thu, 18 Dec 2014 10:47:53 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141218104753.GK1904@zion.uk.xensource.com>
References: <321a64dc64db335460b51becfc040f4cb0e84a9e.1407146305.git.ian.campbell@citrix.com>
	<1418637751.16425.64.camel@citrix.com>
	<20141217205455.GB1829@laptop.dumpdata.com>
	<1418898309.11882.16.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418898309.11882.16.camel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: Bastian Blank <waldi@debian.org>, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: libxl: link libxlu against 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

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 Thu Dec 18 10:49:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:49:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YeN-0005tY-6h; Thu, 18 Dec 2014 10:49: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 1Y1YeL-0005tR-9n
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:49:41 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	41/F5-11581-441B2945; Thu, 18 Dec 2014 10:49:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418899779!14066315!1
X-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 9163 invoked from network); 18 Dec 2014 10:49:39 -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; 18 Dec 2014 10:49:39 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 10:49:39 +0000
Message-Id: <5492BF510200007800050889@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 10:49:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418897867.11882.11.camel@citrix.com>
In-Reply-To: <1418897867.11882.11.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Xen-devel@lists.xen.org,
	DavidVrabel <david.vrabel@citrix.com>, Frediano Ziglio <freddy77@gmail.com>
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 18.12.14 at 11:17, <Ian.Campbell@citrix.com> wrote:
> On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
>> Do we have a bug in Xen that affect SSE instructions (possibly already
>> fixed after Philipp version) ?
> 
> I've had a niggling feeling of Deja Vu over this which I'd been putting
> down to an old Xen on ARM bug in the area of FPU register switching.
> 
> But it seems at some point (possibly even still) there was a similar
> issue with pvops kernels on x86, see:
>         http://bugs.xenproject.org/xen/bug/40 
> 
> Philipp, what kernel are you guys using?
> 
> CCing Jan and the x86 kernel guys (and George since he registered the
> bug). I'm not seeing anything in the kernel logs which looks like a fix
> (there's some PVH related cr0 frobbing, but I don't think that's it).

I just went through the thread again and didn't find where kernel/
hypervisor logs were posted. You mentioning PVH made me want to
take a look - said FPU related bug would be exposed only by PV
kernels.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:49:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:49:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YeN-0005tY-6h; Thu, 18 Dec 2014 10:49: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 1Y1YeL-0005tR-9n
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:49:41 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	41/F5-11581-441B2945; Thu, 18 Dec 2014 10:49:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418899779!14066315!1
X-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 9163 invoked from network); 18 Dec 2014 10:49:39 -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; 18 Dec 2014 10:49:39 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 10:49:39 +0000
Message-Id: <5492BF510200007800050889@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 10:49:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418897867.11882.11.camel@citrix.com>
In-Reply-To: <1418897867.11882.11.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Xen-devel@lists.xen.org,
	DavidVrabel <david.vrabel@citrix.com>, Frediano Ziglio <freddy77@gmail.com>
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 18.12.14 at 11:17, <Ian.Campbell@citrix.com> wrote:
> On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
>> Do we have a bug in Xen that affect SSE instructions (possibly already
>> fixed after Philipp version) ?
> 
> I've had a niggling feeling of Deja Vu over this which I'd been putting
> down to an old Xen on ARM bug in the area of FPU register switching.
> 
> But it seems at some point (possibly even still) there was a similar
> issue with pvops kernels on x86, see:
>         http://bugs.xenproject.org/xen/bug/40 
> 
> Philipp, what kernel are you guys using?
> 
> CCing Jan and the x86 kernel guys (and George since he registered the
> bug). I'm not seeing anything in the kernel logs which looks like a fix
> (there's some PVH related cr0 frobbing, but I don't think that's it).

I just went through the thread again and didn't find where kernel/
hypervisor logs were posted. You mentioning PVH made me want to
take a look - said FPU related bug would be exposed only by PV
kernels.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:52:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YgZ-00065g-OK; Thu, 18 Dec 2014 10:51:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1YgX-00063m-U3
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:51:58 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	F5/E7-25547-DC1B2945; Thu, 18 Dec 2014 10:51:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418899915!14250711!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 12498 invoked from network); 18 Dec 2014 10:51:56 -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 Dec 2014 10:51:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206204625"
Message-ID: <1418899903.11882.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 18 Dec 2014 10:51:43 +0000
In-Reply-To: <5492BF510200007800050889@mail.emea.novell.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418897867.11882.11.camel@citrix.com>
	<5492BF510200007800050889@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Xen-devel@lists.xen.org,
	DavidVrabel <david.vrabel@citrix.com>, Frediano Ziglio <freddy77@gmail.com>
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-12-18 at 10:49 +0000, Jan Beulich wrote:
> >>> On 18.12.14 at 11:17, <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
> >> Do we have a bug in Xen that affect SSE instructions (possibly already
> >> fixed after Philipp version) ?
> > 
> > I've had a niggling feeling of Deja Vu over this which I'd been putting
> > down to an old Xen on ARM bug in the area of FPU register switching.
> > 
> > But it seems at some point (possibly even still) there was a similar
> > issue with pvops kernels on x86, see:
> >         http://bugs.xenproject.org/xen/bug/40 
> > 
> > Philipp, what kernel are you guys using?
> > 
> > CCing Jan and the x86 kernel guys (and George since he registered the
> > bug). I'm not seeing anything in the kernel logs which looks like a fix
> > (there's some PVH related cr0 frobbing, but I don't think that's it).
> 
> I just went through the thread again and didn't find where kernel/
> hypervisor logs were posted.

I don't think they were yet -- until recently it seemed like a xenstored
bug. Philipp, can you post them now?

Also the patch linked to by David seems like a good thing to try if you
are indeed running a kernel which is susceptible to this issue.

> You mentioning PVH made me want to take a look - said FPU related bug
> would be exposed only by PV kernels.

It's (almost certainly) not a PVH issue, I was saying that the patch
which touched PVH probably isn't relevant to this particular issue.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:52:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YgZ-00065g-OK; Thu, 18 Dec 2014 10:51:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1YgX-00063m-U3
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:51:58 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	F5/E7-25547-DC1B2945; Thu, 18 Dec 2014 10:51:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418899915!14250711!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 12498 invoked from network); 18 Dec 2014 10:51:56 -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 Dec 2014 10:51:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206204625"
Message-ID: <1418899903.11882.19.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 18 Dec 2014 10:51:43 +0000
In-Reply-To: <5492BF510200007800050889@mail.emea.novell.com>
References: <546461A2.2070908@univention.de>
	<1415869951.31613.26.camel@citrix.com> <548B1472.5080302@univention.de>
	<1418401932.16425.34.camel@citrix.com> <548B1BA8.3090504@univention.de>
	<1418403387.16425.38.camel@citrix.com> <548B23FA.6070108@univention.de>
	<1418407116.16425.53.camel@citrix.com>
	<1418649458.16425.108.camel@citrix.com> <548EEDF5.20808@univention.de>
	<1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418897867.11882.11.camel@citrix.com>
	<5492BF510200007800050889@mail.emea.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Philipp Hahn <hahn@univention.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Xen-devel@lists.xen.org,
	DavidVrabel <david.vrabel@citrix.com>, Frediano Ziglio <freddy77@gmail.com>
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-12-18 at 10:49 +0000, Jan Beulich wrote:
> >>> On 18.12.14 at 11:17, <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
> >> Do we have a bug in Xen that affect SSE instructions (possibly already
> >> fixed after Philipp version) ?
> > 
> > I've had a niggling feeling of Deja Vu over this which I'd been putting
> > down to an old Xen on ARM bug in the area of FPU register switching.
> > 
> > But it seems at some point (possibly even still) there was a similar
> > issue with pvops kernels on x86, see:
> >         http://bugs.xenproject.org/xen/bug/40 
> > 
> > Philipp, what kernel are you guys using?
> > 
> > CCing Jan and the x86 kernel guys (and George since he registered the
> > bug). I'm not seeing anything in the kernel logs which looks like a fix
> > (there's some PVH related cr0 frobbing, but I don't think that's it).
> 
> I just went through the thread again and didn't find where kernel/
> hypervisor logs were posted.

I don't think they were yet -- until recently it seemed like a xenstored
bug. Philipp, can you post them now?

Also the patch linked to by David seems like a good thing to try if you
are indeed running a kernel which is susceptible to this issue.

> You mentioning PVH made me want to take a look - said FPU related bug
> would be exposed only by PV kernels.

It's (almost certainly) not a PVH issue, I was saying that the patch
which touched PVH probably isn't relevant to this particular issue.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:58:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:58:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YmH-0006YH-Hr; Thu, 18 Dec 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 1Y1YmF-0006YC-Vv
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:57:52 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	BB/7E-26652-F23B2945; Thu, 18 Dec 2014 10:57:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418900269!14118918!1
X-Originating-IP: [66.165.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 19977 invoked from network); 18 Dec 2014 10:57:50 -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;
	18 Dec 2014 10:57:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206205948"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 18 Dec 2014 05:57: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 1Y1YmA-0002gM-VE;
	Thu, 18 Dec 2014 10:57:46 +0000
Date: Thu, 18 Dec 2014 10:57:46 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Message-ID: <20141218105746.GL1904@zion.uk.xensource.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
	<20141217121750.GF1904@zion.uk.xensource.com>
	<5492BBAF02000066000863DD@soto.provo.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5492BBAF02000066000863DD@soto.provo.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 17, 2014 at 08:34:07PM -0700, Chun Yan Liu wrote:
> 
> 
> >>> On 12/17/2014 at 08:17 PM, in message
> <20141217121750.GF1904@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
> wrote: 
> > On Tue, Dec 16, 2014 at 02:32:55PM +0800, Chunyan Liu wrote: 
> > > Changes to V8: 
> > >   * add an overview document, so that one can has a overall look 
> > >     about the whole domain snapshot work, limits, requirements, 
> > >     how to do, etc. 
> > >  
> > > ===================================================================== 
> > > Domain snapshot overview 
> > >  
> > > 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 usually includes: 
> > > a) create a domain snapshot 
> > > b) roll back (or called "revert") to a domain snapshot 
> > > c) delete a domain snapshot 
> > > d) list all domain snapshots 
> > >  
> > > But following the existing xl idioms of managing storage and saved 
> > > VM images via existing CLI command (qemu-img, lvcreate, ls, mv, 
> > > cp etc), xl snapshot functionality would be kept as simple as 
> > > possible: 
> > > * xl will do a) and b), creating a snapshot and reverting a 
> > >   domain to a snapshot. 
> > > * xl will NOT do c) and d), xl won't manage snapshots, as xl 
> > >   doesn't maintain saved images created by 'xl save'. So xl 
> > >   will have no idea of the existence of domain snapshots and 
> > >   the chain relationship between snapshots. It will depends on 
> > >   user to take care of the snapshots, know the snapshot chain 
> > >   info, and delete snapshots. 
> > >  
> > > Domain Snapshot Support and Not Support: 
> >  
> > I think this list applies to xl (last item and [1]). If so please state 
> > clearly to prevent confusion with other toolstack (say, libvirt) and 
> > functionalities of the library (libxl). 
> >  
> > > * support live snapshot 
> > > * support internal disk snapshot and external disk snapshot 
> > > * support different disk backend types. 
> > >   (Basic goal is to support 'raw' and 'qcow2' only). 
> > >  
> > > * not support snapshot when domain is shutdowning or dying. 
> > > * not support disk-only snapshot [1]. 
> > >  
> > >  [1] 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. 
> > >  
> >  
> > I think I understand your reasoning, but it's a bit convoluted to me. 
> >  
> > Domain can be in both active and inactive state (libvirt term) when 
> > using xl.  When domain is active, we cannot guarantee in xl that domain 
> > is quiesced so a disk-only snapshot may contain inconsistent data.
> 
> That's right.
> 
> > When 
> > domain is inactive, there's no point in taking a disk-only snapshot 
> > because it would be the same as the base image.
> 
> xl doesn't have inactive domains. Libvirt has. (in libvirt, one can 'define'
> a domain but not 'starte', like old xend which can 'new' a domain but not
> 'start' it.) xl only can 'create' a domain, when domain is shutdown, it's
> not visible to user.
> 

Per the definition in the first patch, inactive domain is a domain
"created but not started", so I thought the domain created by "xl create
-p dom.cfg" falls into this category. I was wrong.

I think the "created but not started" should be "defined but not
started" (using libvirt's terminology).

> For inactive domain, disk-only snapshot is useful. Since later user
> may run VM with base image and base image would change. Then the
> disk-only snapshot is a usable backup.
> 
> That's why, libvirt can support disk-only snapshot, xl won't support
> disk-only snapshot. Do I describe it clearly?
> 

Yes. I think the libvirt terminology is "defined", not "created".

http://wiki.libvirt.org/page/VM_lifecycle

Wei.

> > So the conclusion is 
> > that xl doesn't need to support disk-only snapshot. 
> >  
> > Does the above reasoning equals to yours? Is it clearer or more 
> > confusing? 
> >  
> > Wei. 
> >  
> > >  
> > > 2. Requirements 
> > >  
> > > General Requirements: 
> > > * ability to save/restore domain memory 
> > > * ability to create/delete/apply disk snapshot [2] 
> > > * ability to parse user config file 
> > >  
> > >   [2] Disk snapshot requirements: 
> > >   - external tools: qemu-img, lvcreate, vhd-util, etc. 
> > >   - for basic goal, we support 'raw' and 'qcow2' backend types 
> > >     only. Then it requires: 
> > >     libxl qmp command or "qemu-img" (when qemu process does not 
> > >     exist) 
> > >  
> > >  
> > > 3. Interaction with other operations: 
> > >  
> > > No. 
> > >  
> > >  
> > > 4. General workflow 
> > >  
> > > Create a snapshot: 
> > >   * parse user cfg file if passed in 
> > >   * check snapshot operation is allowed or not 
> > >   * save domain, saving memory status to file (refer to: save_domain) 
> > >   * take disk snapshot (e.g. call qmp command) 
> > >   * unpause domain 
> > >  
> > > Revert to snapshot: 
> > >   * parse use cfg file (xl doesn't manage snapshots, so it has no 
> > >     idea of snapshot existence. User MUST supply configuration file) 
> > >   * destroy this domain 
> > >   * create a new domain from snapshot info 
> > >     - apply disk snapshot (e.g. call qemu-img) 
> > >     - a process like restore domain 
> >  
> >  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 10:58:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 10:58:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1YmH-0006YH-Hr; Thu, 18 Dec 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 1Y1YmF-0006YC-Vv
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 10:57:52 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	BB/7E-26652-F23B2945; Thu, 18 Dec 2014 10:57:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1418900269!14118918!1
X-Originating-IP: [66.165.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 19977 invoked from network); 18 Dec 2014 10:57:50 -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;
	18 Dec 2014 10:57:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206205948"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 18 Dec 2014 05:57: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 1Y1YmA-0002gM-VE;
	Thu, 18 Dec 2014 10:57:46 +0000
Date: Thu, 18 Dec 2014 10:57:46 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Message-ID: <20141218105746.GL1904@zion.uk.xensource.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
	<20141217121750.GF1904@zion.uk.xensource.com>
	<5492BBAF02000066000863DD@soto.provo.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5492BBAF02000066000863DD@soto.provo.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 17, 2014 at 08:34:07PM -0700, Chun Yan Liu wrote:
> 
> 
> >>> On 12/17/2014 at 08:17 PM, in message
> <20141217121750.GF1904@zion.uk.xensource.com>, Wei Liu <wei.liu2@citrix.com>
> wrote: 
> > On Tue, Dec 16, 2014 at 02:32:55PM +0800, Chunyan Liu wrote: 
> > > Changes to V8: 
> > >   * add an overview document, so that one can has a overall look 
> > >     about the whole domain snapshot work, limits, requirements, 
> > >     how to do, etc. 
> > >  
> > > ===================================================================== 
> > > Domain snapshot overview 
> > >  
> > > 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 usually includes: 
> > > a) create a domain snapshot 
> > > b) roll back (or called "revert") to a domain snapshot 
> > > c) delete a domain snapshot 
> > > d) list all domain snapshots 
> > >  
> > > But following the existing xl idioms of managing storage and saved 
> > > VM images via existing CLI command (qemu-img, lvcreate, ls, mv, 
> > > cp etc), xl snapshot functionality would be kept as simple as 
> > > possible: 
> > > * xl will do a) and b), creating a snapshot and reverting a 
> > >   domain to a snapshot. 
> > > * xl will NOT do c) and d), xl won't manage snapshots, as xl 
> > >   doesn't maintain saved images created by 'xl save'. So xl 
> > >   will have no idea of the existence of domain snapshots and 
> > >   the chain relationship between snapshots. It will depends on 
> > >   user to take care of the snapshots, know the snapshot chain 
> > >   info, and delete snapshots. 
> > >  
> > > Domain Snapshot Support and Not Support: 
> >  
> > I think this list applies to xl (last item and [1]). If so please state 
> > clearly to prevent confusion with other toolstack (say, libvirt) and 
> > functionalities of the library (libxl). 
> >  
> > > * support live snapshot 
> > > * support internal disk snapshot and external disk snapshot 
> > > * support different disk backend types. 
> > >   (Basic goal is to support 'raw' and 'qcow2' only). 
> > >  
> > > * not support snapshot when domain is shutdowning or dying. 
> > > * not support disk-only snapshot [1]. 
> > >  
> > >  [1] 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. 
> > >  
> >  
> > I think I understand your reasoning, but it's a bit convoluted to me. 
> >  
> > Domain can be in both active and inactive state (libvirt term) when 
> > using xl.  When domain is active, we cannot guarantee in xl that domain 
> > is quiesced so a disk-only snapshot may contain inconsistent data.
> 
> That's right.
> 
> > When 
> > domain is inactive, there's no point in taking a disk-only snapshot 
> > because it would be the same as the base image.
> 
> xl doesn't have inactive domains. Libvirt has. (in libvirt, one can 'define'
> a domain but not 'starte', like old xend which can 'new' a domain but not
> 'start' it.) xl only can 'create' a domain, when domain is shutdown, it's
> not visible to user.
> 

Per the definition in the first patch, inactive domain is a domain
"created but not started", so I thought the domain created by "xl create
-p dom.cfg" falls into this category. I was wrong.

I think the "created but not started" should be "defined but not
started" (using libvirt's terminology).

> For inactive domain, disk-only snapshot is useful. Since later user
> may run VM with base image and base image would change. Then the
> disk-only snapshot is a usable backup.
> 
> That's why, libvirt can support disk-only snapshot, xl won't support
> disk-only snapshot. Do I describe it clearly?
> 

Yes. I think the libvirt terminology is "defined", not "created".

http://wiki.libvirt.org/page/VM_lifecycle

Wei.

> > So the conclusion is 
> > that xl doesn't need to support disk-only snapshot. 
> >  
> > Does the above reasoning equals to yours? Is it clearer or more 
> > confusing? 
> >  
> > Wei. 
> >  
> > >  
> > > 2. Requirements 
> > >  
> > > General Requirements: 
> > > * ability to save/restore domain memory 
> > > * ability to create/delete/apply disk snapshot [2] 
> > > * ability to parse user config file 
> > >  
> > >   [2] Disk snapshot requirements: 
> > >   - external tools: qemu-img, lvcreate, vhd-util, etc. 
> > >   - for basic goal, we support 'raw' and 'qcow2' backend types 
> > >     only. Then it requires: 
> > >     libxl qmp command or "qemu-img" (when qemu process does not 
> > >     exist) 
> > >  
> > >  
> > > 3. Interaction with other operations: 
> > >  
> > > No. 
> > >  
> > >  
> > > 4. General workflow 
> > >  
> > > Create a snapshot: 
> > >   * parse user cfg file if passed in 
> > >   * check snapshot operation is allowed or not 
> > >   * save domain, saving memory status to file (refer to: save_domain) 
> > >   * take disk snapshot (e.g. call qmp command) 
> > >   * unpause domain 
> > >  
> > > Revert to snapshot: 
> > >   * parse use cfg file (xl doesn't manage snapshots, so it has no 
> > >     idea of snapshot existence. User MUST supply configuration file) 
> > >   * destroy this domain 
> > >   * create a new domain from snapshot info 
> > >     - apply disk snapshot (e.g. call qemu-img) 
> > >     - a process like restore domain 
> >  
> >  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 11:02:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 11: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 1Y1Yqf-0006p9-BM; Thu, 18 Dec 2014 11:02:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Y1Yqd-0006oy-Km
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 11:02:23 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	A9/02-18267-E34B2945; Thu, 18 Dec 2014 11:02:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418900540!14315226!1
X-Originating-IP: [66.165.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 28000 invoked from network); 18 Dec 2014 11:02:22 -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;
	18 Dec 2014 11:02:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="205733564"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 18 Dec 2014 06:02: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 1Y1YqZ-0002n5-Do;
	Thu, 18 Dec 2014 11:02:19 +0000
Date: Thu, 18 Dec 2014 11:02:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Message-ID: <20141218110219.GM1904@zion.uk.xensource.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
	<20141217122817.GG1904@zion.uk.xensource.com>
	<5492B93D02000066000863D1@soto.provo.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5492B93D02000066000863D1@soto.provo.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 17, 2014 at 08:23:41PM -0700, Chun Yan Liu wrote:
[...]
> > >  
> > >  
> > > 2. cfgfile syntax 
> > >  
> > > #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 
> > > #For easier parse config work, reuse disk configuration in xl.cfg, but 
> > > #with different meanings. 
> > > #disk syntax meaning: 'external path, external format, target device' 
> > >  
> > > #e.g. to specify exernal disk snapshot, like this: 
> > > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', 
> > >         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] 
> > >  
> > > #e.g. to specify internal disk snapshot, like this: 
> > > disks=[',,hda',',,hdb',] 
> > >  
> >  
> > How is snapshot chain represented with this syntax? Does xl not need to 
> > know about the chain? (Note, this is different than managing the chain) 
> 
> If only supply creating snapshot and restoring domain from a snapshot,
> xl doesn't need to know the chain.
> 
> For creating snapshot, it's very easy to understand, no matter from base
> or from a snapshot, saving memory and taking disk snapshot has no
> difference. 
> 
> For restoring domain from snapshot, restoring memory has no difference;
> applying disk snapshot, to those backend types we can expect:
> qcow2 internal snapshot: no need to know chain
> vhd, qcow2 external disk snapshot: both external disk snapshot, and 
> both using backing file chain to implement, so apply disk snapshot
> is very simple, just use the external snapshot file.
> lvm: doesn't support snapshot of snapshot, so no such problem.
> So, overall, it doesn't need to know the chain either.
> 

Thanks for the explanation. Makes sense.

Wei.

> > 
> > Wei. 
> >  
> >  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 11:02:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 11: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 1Y1Yqf-0006p9-BM; Thu, 18 Dec 2014 11:02:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Y1Yqd-0006oy-Km
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 11:02:23 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	A9/02-18267-E34B2945; Thu, 18 Dec 2014 11:02:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418900540!14315226!1
X-Originating-IP: [66.165.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 28000 invoked from network); 18 Dec 2014 11:02:22 -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;
	18 Dec 2014 11:02:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="205733564"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 18 Dec 2014 06:02: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 1Y1YqZ-0002n5-Do;
	Thu, 18 Dec 2014 11:02:19 +0000
Date: Thu, 18 Dec 2014 11:02:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Message-ID: <20141218110219.GM1904@zion.uk.xensource.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
	<20141217122817.GG1904@zion.uk.xensource.com>
	<5492B93D02000066000863D1@soto.provo.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5492B93D02000066000863D1@soto.provo.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 17, 2014 at 08:23:41PM -0700, Chun Yan Liu wrote:
[...]
> > >  
> > >  
> > > 2. cfgfile syntax 
> > >  
> > > #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 
> > > #For easier parse config work, reuse disk configuration in xl.cfg, but 
> > > #with different meanings. 
> > > #disk syntax meaning: 'external path, external format, target device' 
> > >  
> > > #e.g. to specify exernal disk snapshot, like this: 
> > > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', 
> > >         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] 
> > >  
> > > #e.g. to specify internal disk snapshot, like this: 
> > > disks=[',,hda',',,hdb',] 
> > >  
> >  
> > How is snapshot chain represented with this syntax? Does xl not need to 
> > know about the chain? (Note, this is different than managing the chain) 
> 
> If only supply creating snapshot and restoring domain from a snapshot,
> xl doesn't need to know the chain.
> 
> For creating snapshot, it's very easy to understand, no matter from base
> or from a snapshot, saving memory and taking disk snapshot has no
> difference. 
> 
> For restoring domain from snapshot, restoring memory has no difference;
> applying disk snapshot, to those backend types we can expect:
> qcow2 internal snapshot: no need to know chain
> vhd, qcow2 external disk snapshot: both external disk snapshot, and 
> both using backing file chain to implement, so apply disk snapshot
> is very simple, just use the external snapshot file.
> lvm: doesn't support snapshot of snapshot, so no such problem.
> So, overall, it doesn't need to know the chain either.
> 

Thanks for the explanation. Makes sense.

Wei.

> > 
> > Wei. 
> >  
> >  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 11:13:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 11:13:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Z1F-0007O6-N6; Thu, 18 Dec 2014 11:13: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 1Y1Z1D-0007O1-SB
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 11:13:20 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	50/CC-14727-FC6B2945; Thu, 18 Dec 2014 11:13:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418901196!11203201!1
X-Originating-IP: [66.165.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 32288 invoked from network); 18 Dec 2014 11:13:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 11:13:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206209383"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 18 Dec 2014 06:13:16 -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 1Y1Z18-0002zb-UU;
	Thu, 18 Dec 2014 11:13:14 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <netdev@vger.kernel.org>
Date: Thu, 18 Dec 2014 11:13:06 +0000
Message-ID: <1418901186-14478-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, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCHv1 net] xen-netback: support frontends without
	feature-rx-notify again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
feature-rx-notify mandatory) incorrectly assumed that there were no
frontends in use that did not support this feature.  But the frontend
driver in MiniOS does not and since this is used by (qemu) stubdoms,
these stopped working.

Netback sort of works as-is in this mode except:

- If there are no Rx requests and the internal Rx queue fills, only
  the drain timeout will wake the thread.  The default drain timeout
  of 10 s would give unacceptable pauses.

- If an Rx stall was detected and the internal Rx queue is drained,
  then the Rx thread would never wake.

Handle these two cases (when feature-rx-notify is disabled) by:

- Reducing the drain timeout to 30 ms.

- Disabling Rx stall detection.

Reported-by: John <jw@nuclearfallout.net>
Tested-by: John <jw@nuclearfallout.net>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/common.h    |    4 +++-
 drivers/net/xen-netback/interface.c |    4 +++-
 drivers/net/xen-netback/netback.c   |   27 ++++++++++++++-------------
 drivers/net/xen-netback/xenbus.c    |   12 +++++++++---
 4 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 083ecc9..5f1fda4 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -230,6 +230,8 @@ struct xenvif {
 	 */
 	bool disabled;
 	unsigned long status;
+	unsigned long drain_timeout;
+	unsigned long stall_timeout;
 
 	/* Queues */
 	struct xenvif_queue *queues;
@@ -328,7 +330,7 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id);
 extern bool separate_tx_rx_irq;
 
 extern unsigned int rx_drain_timeout_msecs;
-extern unsigned int rx_drain_timeout_jiffies;
+extern unsigned int rx_stall_timeout_msecs;
 extern unsigned int xenvif_max_queues;
 
 #ifdef CONFIG_DEBUG_FS
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index a6a32d3..9259a73 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -166,7 +166,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	cb = XENVIF_RX_CB(skb);
-	cb->expires = jiffies + rx_drain_timeout_jiffies;
+	cb->expires = jiffies + vif->drain_timeout;
 
 	xenvif_rx_queue_tail(queue, skb);
 	xenvif_kick_thread(queue);
@@ -414,6 +414,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif->ip_csum = 1;
 	vif->dev = dev;
 	vif->disabled = false;
+	vif->drain_timeout = msecs_to_jiffies(rx_drain_timeout_msecs);
+	vif->stall_timeout = msecs_to_jiffies(rx_stall_timeout_msecs);
 
 	/* Start out with no queues. */
 	vif->queues = NULL;
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 4a509f7..908e65e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -60,14 +60,12 @@ module_param(separate_tx_rx_irq, bool, 0644);
  */
 unsigned int rx_drain_timeout_msecs = 10000;
 module_param(rx_drain_timeout_msecs, uint, 0444);
-unsigned int rx_drain_timeout_jiffies;
 
 /* The length of time before the frontend is considered unresponsive
  * because it isn't providing Rx slots.
  */
-static unsigned int rx_stall_timeout_msecs = 60000;
+unsigned int rx_stall_timeout_msecs = 60000;
 module_param(rx_stall_timeout_msecs, uint, 0444);
-static unsigned int rx_stall_timeout_jiffies;
 
 unsigned int xenvif_max_queues;
 module_param_named(max_queues, xenvif_max_queues, uint, 0644);
@@ -2020,7 +2018,7 @@ static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)
 	return !queue->stalled
 		&& prod - cons < XEN_NETBK_RX_SLOTS_MAX
 		&& time_after(jiffies,
-			      queue->last_rx_time + rx_stall_timeout_jiffies);
+			      queue->last_rx_time + queue->vif->stall_timeout);
 }
 
 static bool xenvif_rx_queue_ready(struct xenvif_queue *queue)
@@ -2038,8 +2036,9 @@ static bool xenvif_have_rx_work(struct xenvif_queue *queue)
 {
 	return (!skb_queue_empty(&queue->rx_queue)
 		&& xenvif_rx_ring_slots_available(queue, XEN_NETBK_RX_SLOTS_MAX))
-		|| xenvif_rx_queue_stalled(queue)
-		|| xenvif_rx_queue_ready(queue)
+		|| (queue->vif->stall_timeout &&
+		    (xenvif_rx_queue_stalled(queue)
+		     || xenvif_rx_queue_ready(queue)))
 		|| kthread_should_stop()
 		|| queue->vif->disabled;
 }
@@ -2092,6 +2091,9 @@ int xenvif_kthread_guest_rx(void *data)
 	struct xenvif_queue *queue = data;
 	struct xenvif *vif = queue->vif;
 
+	if (!vif->stall_timeout)
+		xenvif_queue_carrier_on(queue);
+
 	for (;;) {
 		xenvif_wait_for_rx_work(queue);
 
@@ -2118,10 +2120,12 @@ int xenvif_kthread_guest_rx(void *data)
 		 * while it's probably not responsive, drop the
 		 * carrier so packets are dropped earlier.
 		 */
-		if (xenvif_rx_queue_stalled(queue))
-			xenvif_queue_carrier_off(queue);
-		else if (xenvif_rx_queue_ready(queue))
-			xenvif_queue_carrier_on(queue);
+		if (vif->stall_timeout) {
+			if (xenvif_rx_queue_stalled(queue))
+				xenvif_queue_carrier_off(queue);
+			else if (xenvif_rx_queue_ready(queue))
+				xenvif_queue_carrier_on(queue);
+		}
 
 		/* Queued packets may have foreign pages from other
 		 * domains.  These cannot be queued indefinitely as
@@ -2192,9 +2196,6 @@ static int __init netback_init(void)
 	if (rc)
 		goto failed_init;
 
-	rx_drain_timeout_jiffies = msecs_to_jiffies(rx_drain_timeout_msecs);
-	rx_stall_timeout_jiffies = msecs_to_jiffies(rx_stall_timeout_msecs);
-
 #ifdef CONFIG_DEBUG_FS
 	xen_netback_dbg_root = debugfs_create_dir("xen-netback", NULL);
 	if (IS_ERR_OR_NULL(xen_netback_dbg_root))
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index d44cd19..efbaf2a 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -887,9 +887,15 @@ static int read_xenbus_vif_flags(struct backend_info *be)
 		return -EOPNOTSUPP;
 
 	if (xenbus_scanf(XBT_NIL, dev->otherend,
-			 "feature-rx-notify", "%d", &val) < 0 || val == 0) {
-		xenbus_dev_fatal(dev, -EINVAL, "feature-rx-notify is mandatory");
-		return -EINVAL;
+			 "feature-rx-notify", "%d", &val) < 0)
+		val = 0;
+	if (!val) {
+		/* - Reduce drain timeout to poll more frequently for
+		 *   Rx requests.
+		 * - Disable Rx stall detection.
+		 */
+		be->vif->drain_timeout = msecs_to_jiffies(30);
+		be->vif->stall_timeout = 0;
 	}
 
 	if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-sg",
-- 
1.7.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 Dec 18 11:13:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 11:13:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Z1F-0007O6-N6; Thu, 18 Dec 2014 11:13: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 1Y1Z1D-0007O1-SB
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 11:13:20 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	50/CC-14727-FC6B2945; Thu, 18 Dec 2014 11:13:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418901196!11203201!1
X-Originating-IP: [66.165.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 32288 invoked from network); 18 Dec 2014 11:13:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 11:13:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206209383"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 18 Dec 2014 06:13:16 -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 1Y1Z18-0002zb-UU;
	Thu, 18 Dec 2014 11:13:14 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <netdev@vger.kernel.org>
Date: Thu, 18 Dec 2014 11:13:06 +0000
Message-ID: <1418901186-14478-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, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCHv1 net] xen-netback: support frontends without
	feature-rx-notify again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
feature-rx-notify mandatory) incorrectly assumed that there were no
frontends in use that did not support this feature.  But the frontend
driver in MiniOS does not and since this is used by (qemu) stubdoms,
these stopped working.

Netback sort of works as-is in this mode except:

- If there are no Rx requests and the internal Rx queue fills, only
  the drain timeout will wake the thread.  The default drain timeout
  of 10 s would give unacceptable pauses.

- If an Rx stall was detected and the internal Rx queue is drained,
  then the Rx thread would never wake.

Handle these two cases (when feature-rx-notify is disabled) by:

- Reducing the drain timeout to 30 ms.

- Disabling Rx stall detection.

Reported-by: John <jw@nuclearfallout.net>
Tested-by: John <jw@nuclearfallout.net>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/common.h    |    4 +++-
 drivers/net/xen-netback/interface.c |    4 +++-
 drivers/net/xen-netback/netback.c   |   27 ++++++++++++++-------------
 drivers/net/xen-netback/xenbus.c    |   12 +++++++++---
 4 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 083ecc9..5f1fda4 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -230,6 +230,8 @@ struct xenvif {
 	 */
 	bool disabled;
 	unsigned long status;
+	unsigned long drain_timeout;
+	unsigned long stall_timeout;
 
 	/* Queues */
 	struct xenvif_queue *queues;
@@ -328,7 +330,7 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id);
 extern bool separate_tx_rx_irq;
 
 extern unsigned int rx_drain_timeout_msecs;
-extern unsigned int rx_drain_timeout_jiffies;
+extern unsigned int rx_stall_timeout_msecs;
 extern unsigned int xenvif_max_queues;
 
 #ifdef CONFIG_DEBUG_FS
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index a6a32d3..9259a73 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -166,7 +166,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	cb = XENVIF_RX_CB(skb);
-	cb->expires = jiffies + rx_drain_timeout_jiffies;
+	cb->expires = jiffies + vif->drain_timeout;
 
 	xenvif_rx_queue_tail(queue, skb);
 	xenvif_kick_thread(queue);
@@ -414,6 +414,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif->ip_csum = 1;
 	vif->dev = dev;
 	vif->disabled = false;
+	vif->drain_timeout = msecs_to_jiffies(rx_drain_timeout_msecs);
+	vif->stall_timeout = msecs_to_jiffies(rx_stall_timeout_msecs);
 
 	/* Start out with no queues. */
 	vif->queues = NULL;
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 4a509f7..908e65e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -60,14 +60,12 @@ module_param(separate_tx_rx_irq, bool, 0644);
  */
 unsigned int rx_drain_timeout_msecs = 10000;
 module_param(rx_drain_timeout_msecs, uint, 0444);
-unsigned int rx_drain_timeout_jiffies;
 
 /* The length of time before the frontend is considered unresponsive
  * because it isn't providing Rx slots.
  */
-static unsigned int rx_stall_timeout_msecs = 60000;
+unsigned int rx_stall_timeout_msecs = 60000;
 module_param(rx_stall_timeout_msecs, uint, 0444);
-static unsigned int rx_stall_timeout_jiffies;
 
 unsigned int xenvif_max_queues;
 module_param_named(max_queues, xenvif_max_queues, uint, 0644);
@@ -2020,7 +2018,7 @@ static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)
 	return !queue->stalled
 		&& prod - cons < XEN_NETBK_RX_SLOTS_MAX
 		&& time_after(jiffies,
-			      queue->last_rx_time + rx_stall_timeout_jiffies);
+			      queue->last_rx_time + queue->vif->stall_timeout);
 }
 
 static bool xenvif_rx_queue_ready(struct xenvif_queue *queue)
@@ -2038,8 +2036,9 @@ static bool xenvif_have_rx_work(struct xenvif_queue *queue)
 {
 	return (!skb_queue_empty(&queue->rx_queue)
 		&& xenvif_rx_ring_slots_available(queue, XEN_NETBK_RX_SLOTS_MAX))
-		|| xenvif_rx_queue_stalled(queue)
-		|| xenvif_rx_queue_ready(queue)
+		|| (queue->vif->stall_timeout &&
+		    (xenvif_rx_queue_stalled(queue)
+		     || xenvif_rx_queue_ready(queue)))
 		|| kthread_should_stop()
 		|| queue->vif->disabled;
 }
@@ -2092,6 +2091,9 @@ int xenvif_kthread_guest_rx(void *data)
 	struct xenvif_queue *queue = data;
 	struct xenvif *vif = queue->vif;
 
+	if (!vif->stall_timeout)
+		xenvif_queue_carrier_on(queue);
+
 	for (;;) {
 		xenvif_wait_for_rx_work(queue);
 
@@ -2118,10 +2120,12 @@ int xenvif_kthread_guest_rx(void *data)
 		 * while it's probably not responsive, drop the
 		 * carrier so packets are dropped earlier.
 		 */
-		if (xenvif_rx_queue_stalled(queue))
-			xenvif_queue_carrier_off(queue);
-		else if (xenvif_rx_queue_ready(queue))
-			xenvif_queue_carrier_on(queue);
+		if (vif->stall_timeout) {
+			if (xenvif_rx_queue_stalled(queue))
+				xenvif_queue_carrier_off(queue);
+			else if (xenvif_rx_queue_ready(queue))
+				xenvif_queue_carrier_on(queue);
+		}
 
 		/* Queued packets may have foreign pages from other
 		 * domains.  These cannot be queued indefinitely as
@@ -2192,9 +2196,6 @@ static int __init netback_init(void)
 	if (rc)
 		goto failed_init;
 
-	rx_drain_timeout_jiffies = msecs_to_jiffies(rx_drain_timeout_msecs);
-	rx_stall_timeout_jiffies = msecs_to_jiffies(rx_stall_timeout_msecs);
-
 #ifdef CONFIG_DEBUG_FS
 	xen_netback_dbg_root = debugfs_create_dir("xen-netback", NULL);
 	if (IS_ERR_OR_NULL(xen_netback_dbg_root))
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index d44cd19..efbaf2a 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -887,9 +887,15 @@ static int read_xenbus_vif_flags(struct backend_info *be)
 		return -EOPNOTSUPP;
 
 	if (xenbus_scanf(XBT_NIL, dev->otherend,
-			 "feature-rx-notify", "%d", &val) < 0 || val == 0) {
-		xenbus_dev_fatal(dev, -EINVAL, "feature-rx-notify is mandatory");
-		return -EINVAL;
+			 "feature-rx-notify", "%d", &val) < 0)
+		val = 0;
+	if (!val) {
+		/* - Reduce drain timeout to poll more frequently for
+		 *   Rx requests.
+		 * - Disable Rx stall detection.
+		 */
+		be->vif->drain_timeout = msecs_to_jiffies(30);
+		be->vif->stall_timeout = 0;
 	}
 
 	if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-sg",
-- 
1.7.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 Dec 18 11:37:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 11: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 1Y1ZOL-00004w-Fd; Thu, 18 Dec 2014 11:37:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1ZOK-00004r-5l
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 11:37:12 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	40/2D-02712-76CB2945; Thu, 18 Dec 2014 11:37:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418902630!12582933!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28053 invoked from network); 18 Dec 2014 11:37:10 -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; 18 Dec 2014 11:37:10 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 11:37:10 +0000
Message-Id: <5492CA7502000078000508E8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 11:37:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <chegger@amazon.de>
References: <1417616967-18720-1-git-send-email-chegger@amazon.de>
	<1417616967-18720-2-git-send-email-chegger@amazon.de>
In-Reply-To: <1417616967-18720-2-git-send-email-chegger@amazon.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Julien Grall <julien.grall@linaro.org>, Keir Fraser <keir@xen.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 1/2] gnttab: Introduce rwlock to protect
 updates to grant table 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 03.12.14 at 15:29, <chegger@amazon.de> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -227,23 +227,23 @@ double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
>  {
>      if ( lgt < rgt )
>      {
> -        spin_lock(&lgt->lock);
> -        spin_lock(&rgt->lock);
> +        spin_lock(&lgt->maptrack_lock);
> +        spin_lock(&rgt->maptrack_lock);
>      }
>      else
>      {
>          if ( lgt != rgt )
> -            spin_lock(&rgt->lock);
> -        spin_lock(&lgt->lock);
> +            spin_lock(&rgt->maptrack_lock);
> +        spin_lock(&lgt->maptrack_lock);
>      }
>  }

I think this function needs to be renamed with this change, to clarify
that it's not the general grant table locks which get acquired here.
Same for the unlock then of course. That'll also make stand out the
places where the function is used.

> @@ -891,28 +891,28 @@ __gnttab_unmap_common(
>      ld = current->domain;
>      lgt = ld->grant_table;
>  
> +    read_lock(&lgt->lock);
>      op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
>  
>      if ( unlikely(op->handle >= lgt->maptrack_limit) )
>      {
> +        read_unlock(&lgt->lock);
>          gdprintk(XENLOG_INFO, "Bad handle (%d).\n", op->handle);
>          op->status = GNTST_bad_handle;
>          return;
>      }
>  
> +    read_unlock(&lgt->lock);

The added locking here seems pointless, or else there would be a
bug in the existing code (which should then be fixed by a separate,
much smaller change).

>      op->map = &maptrack_entry(lgt, op->handle);
> -    spin_lock(&lgt->lock);
>  
>      if ( unlikely(!op->map->flags) )
>      {
> -        spin_unlock(&lgt->lock);
>          gdprintk(XENLOG_INFO, "Zero flags for handle (%d).\n", op->handle);
>          op->status = GNTST_bad_handle;
>          return;
>      }
>  
>      dom = op->map->domid;
> -    spin_unlock(&lgt->lock);

And the removed locking here needs special mentioning in the commit
message, explaining why no locking is needed.

> @@ -944,6 +944,7 @@ __gnttab_unmap_common(
>      }
>  
>      op->rd = rd;
> +    read_lock(&rgt->lock);
>      act = &active_entry(rgt, op->map->ref);
>  
>      if ( op->frame == 0 )

The nesting of the two locks should be mentioned in the doc change.

> @@ -1004,6 +1005,7 @@ __gnttab_unmap_common(
>  
>   unmap_out:
>      double_gt_unlock(lgt, rgt);
> +    read_unlock(&rgt->lock);

And I'd prefer unlocking sequence to be the inverse of the locking
one, just to avoid confusion about their nesting.

> @@ -1284,10 +1286,13 @@ gnttab_unpopulate_status_frames(struct domain *d, struct grant_table *gt)
>      gt->nr_status_frames = 0;
>  }
>  
> +/* Grow the grant table. The caller must hold the grant table's
> + * write lock before calling this function.
> + */

Coding style.

> @@ -1965,17 +1970,21 @@ __acquire_grant_for_copy(
>                  PIN_FAIL(unlock_out_clear, GNTST_general_error,
>                           "transitive grant referenced bad domain %d\n",
>                           trans_domid);
> -            spin_unlock(&rgt->lock);
> +
> +            /* __acquire_grant_for_copy() could take the read lock on
> +             * the right table (if rd == td), so we have to drop the
> +             * lock here and reacquire */

Coding style again.

> @@ -2900,7 +2910,7 @@ gnttab_release_mappings(
>          }
>  
>          rgt = rd->grant_table;
> -        spin_lock(&rgt->lock);
> +        read_lock(&rgt->lock);
>  
>          act = &active_entry(rgt, ref);
>          sha = shared_entry_header(rgt, ref);
> @@ -2960,7 +2970,7 @@ gnttab_release_mappings(
>          if ( act->pin == 0 )
>              gnttab_clear_flag(_GTF_reading, status);
>  
> -        spin_unlock(&rgt->lock);
> +        read_unlock(&rgt->lock);

The maptrack entries are being accessed between these two - don't
you need both locks here?

> --- a/xen/include/xen/grant_table.h
> +++ b/xen/include/xen/grant_table.h
> @@ -82,8 +82,11 @@ struct grant_table {
>      struct grant_mapping **maptrack;
>      unsigned int          maptrack_head;
>      unsigned int          maptrack_limit;
> -    /* Lock protecting updates to active and shared grant tables. */
> -    spinlock_t            lock;
> +    /* Lock protecting the maptrack page list, head, and limit */
> +    spinlock_t            maptrack_lock;
> +    /* Lock protecting updates to grant table state (version, active
> +       entry list, etc.) */
> +    rwlock_t              lock;
>      /* The defined versions are 1 and 2.  Set to 0 if we don't know
>         what version to use yet. */
>      unsigned              gt_version;

Coding style again - the malformed existing comment is no reason to
add another malformed 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 Dec 18 11:37:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 11: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 1Y1ZOL-00004w-Fd; Thu, 18 Dec 2014 11:37:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1ZOK-00004r-5l
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 11:37:12 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	40/2D-02712-76CB2945; Thu, 18 Dec 2014 11:37:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418902630!12582933!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28053 invoked from network); 18 Dec 2014 11:37:10 -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; 18 Dec 2014 11:37:10 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 11:37:10 +0000
Message-Id: <5492CA7502000078000508E8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 11:37:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <chegger@amazon.de>
References: <1417616967-18720-1-git-send-email-chegger@amazon.de>
	<1417616967-18720-2-git-send-email-chegger@amazon.de>
In-Reply-To: <1417616967-18720-2-git-send-email-chegger@amazon.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Julien Grall <julien.grall@linaro.org>, Keir Fraser <keir@xen.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 1/2] gnttab: Introduce rwlock to protect
 updates to grant table 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 03.12.14 at 15:29, <chegger@amazon.de> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -227,23 +227,23 @@ double_gt_lock(struct grant_table *lgt, struct grant_table *rgt)
>  {
>      if ( lgt < rgt )
>      {
> -        spin_lock(&lgt->lock);
> -        spin_lock(&rgt->lock);
> +        spin_lock(&lgt->maptrack_lock);
> +        spin_lock(&rgt->maptrack_lock);
>      }
>      else
>      {
>          if ( lgt != rgt )
> -            spin_lock(&rgt->lock);
> -        spin_lock(&lgt->lock);
> +            spin_lock(&rgt->maptrack_lock);
> +        spin_lock(&lgt->maptrack_lock);
>      }
>  }

I think this function needs to be renamed with this change, to clarify
that it's not the general grant table locks which get acquired here.
Same for the unlock then of course. That'll also make stand out the
places where the function is used.

> @@ -891,28 +891,28 @@ __gnttab_unmap_common(
>      ld = current->domain;
>      lgt = ld->grant_table;
>  
> +    read_lock(&lgt->lock);
>      op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
>  
>      if ( unlikely(op->handle >= lgt->maptrack_limit) )
>      {
> +        read_unlock(&lgt->lock);
>          gdprintk(XENLOG_INFO, "Bad handle (%d).\n", op->handle);
>          op->status = GNTST_bad_handle;
>          return;
>      }
>  
> +    read_unlock(&lgt->lock);

The added locking here seems pointless, or else there would be a
bug in the existing code (which should then be fixed by a separate,
much smaller change).

>      op->map = &maptrack_entry(lgt, op->handle);
> -    spin_lock(&lgt->lock);
>  
>      if ( unlikely(!op->map->flags) )
>      {
> -        spin_unlock(&lgt->lock);
>          gdprintk(XENLOG_INFO, "Zero flags for handle (%d).\n", op->handle);
>          op->status = GNTST_bad_handle;
>          return;
>      }
>  
>      dom = op->map->domid;
> -    spin_unlock(&lgt->lock);

And the removed locking here needs special mentioning in the commit
message, explaining why no locking is needed.

> @@ -944,6 +944,7 @@ __gnttab_unmap_common(
>      }
>  
>      op->rd = rd;
> +    read_lock(&rgt->lock);
>      act = &active_entry(rgt, op->map->ref);
>  
>      if ( op->frame == 0 )

The nesting of the two locks should be mentioned in the doc change.

> @@ -1004,6 +1005,7 @@ __gnttab_unmap_common(
>  
>   unmap_out:
>      double_gt_unlock(lgt, rgt);
> +    read_unlock(&rgt->lock);

And I'd prefer unlocking sequence to be the inverse of the locking
one, just to avoid confusion about their nesting.

> @@ -1284,10 +1286,13 @@ gnttab_unpopulate_status_frames(struct domain *d, struct grant_table *gt)
>      gt->nr_status_frames = 0;
>  }
>  
> +/* Grow the grant table. The caller must hold the grant table's
> + * write lock before calling this function.
> + */

Coding style.

> @@ -1965,17 +1970,21 @@ __acquire_grant_for_copy(
>                  PIN_FAIL(unlock_out_clear, GNTST_general_error,
>                           "transitive grant referenced bad domain %d\n",
>                           trans_domid);
> -            spin_unlock(&rgt->lock);
> +
> +            /* __acquire_grant_for_copy() could take the read lock on
> +             * the right table (if rd == td), so we have to drop the
> +             * lock here and reacquire */

Coding style again.

> @@ -2900,7 +2910,7 @@ gnttab_release_mappings(
>          }
>  
>          rgt = rd->grant_table;
> -        spin_lock(&rgt->lock);
> +        read_lock(&rgt->lock);
>  
>          act = &active_entry(rgt, ref);
>          sha = shared_entry_header(rgt, ref);
> @@ -2960,7 +2970,7 @@ gnttab_release_mappings(
>          if ( act->pin == 0 )
>              gnttab_clear_flag(_GTF_reading, status);
>  
> -        spin_unlock(&rgt->lock);
> +        read_unlock(&rgt->lock);

The maptrack entries are being accessed between these two - don't
you need both locks here?

> --- a/xen/include/xen/grant_table.h
> +++ b/xen/include/xen/grant_table.h
> @@ -82,8 +82,11 @@ struct grant_table {
>      struct grant_mapping **maptrack;
>      unsigned int          maptrack_head;
>      unsigned int          maptrack_limit;
> -    /* Lock protecting updates to active and shared grant tables. */
> -    spinlock_t            lock;
> +    /* Lock protecting the maptrack page list, head, and limit */
> +    spinlock_t            maptrack_lock;
> +    /* Lock protecting updates to grant table state (version, active
> +       entry list, etc.) */
> +    rwlock_t              lock;
>      /* The defined versions are 1 and 2.  Set to 0 if we don't know
>         what version to use yet. */
>      unsigned              gt_version;

Coding style again - the malformed existing comment is no reason to
add another malformed 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 Dec 18 11:51:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 11: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 1Y1Zc3-0000qV-RW; Thu, 18 Dec 2014 11:51: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 1Y1Zc2-0000qQ-6R
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 11:51:22 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	72/27-07724-9BFB2945; Thu, 18 Dec 2014 11:51:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418903479!14338945!1
X-Originating-IP: [66.165.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 24350 invoked from network); 18 Dec 2014 11:51:20 -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;
	18 Dec 2014 11:51:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206218266"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 18 Dec 2014 06:51: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 1Y1Zby-0003ey-7R;
	Thu, 18 Dec 2014 11:51:18 +0000
Date: Thu, 18 Dec 2014 11:51:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141218115117.GN1904@zion.uk.xensource.com>
References: <1418901186-14478-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418901186-14478-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: netdev@vger.kernel.org, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net] xen-netback: support frontends
 without feature-rx-notify again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 18, 2014 at 11:13:06AM +0000, David Vrabel wrote:
> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
> feature-rx-notify mandatory) incorrectly assumed that there were no
> frontends in use that did not support this feature.  But the frontend
> driver in MiniOS does not and since this is used by (qemu) stubdoms,
> these stopped working.
> 
> Netback sort of works as-is in this mode except:
> 
> - If there are no Rx requests and the internal Rx queue fills, only
>   the drain timeout will wake the thread.  The default drain timeout
>   of 10 s would give unacceptable pauses.
> 
> - If an Rx stall was detected and the internal Rx queue is drained,
>   then the Rx thread would never wake.
> 
> Handle these two cases (when feature-rx-notify is disabled) by:
> 
> - Reducing the drain timeout to 30 ms.
> 
> - Disabling Rx stall detection.
> 
> Reported-by: John <jw@nuclearfallout.net>
> Tested-by: John <jw@nuclearfallout.net>
> Signed-off-by: David Vrabel <david.vrabel@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 Dec 18 11:51:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 11: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 1Y1Zc3-0000qV-RW; Thu, 18 Dec 2014 11:51: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 1Y1Zc2-0000qQ-6R
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 11:51:22 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	72/27-07724-9BFB2945; Thu, 18 Dec 2014 11:51:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418903479!14338945!1
X-Originating-IP: [66.165.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 24350 invoked from network); 18 Dec 2014 11:51:20 -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;
	18 Dec 2014 11:51:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206218266"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 18 Dec 2014 06:51: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 1Y1Zby-0003ey-7R;
	Thu, 18 Dec 2014 11:51:18 +0000
Date: Thu, 18 Dec 2014 11:51:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141218115117.GN1904@zion.uk.xensource.com>
References: <1418901186-14478-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418901186-14478-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: netdev@vger.kernel.org, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net] xen-netback: support frontends
 without feature-rx-notify again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 18, 2014 at 11:13:06AM +0000, David Vrabel wrote:
> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
> feature-rx-notify mandatory) incorrectly assumed that there were no
> frontends in use that did not support this feature.  But the frontend
> driver in MiniOS does not and since this is used by (qemu) stubdoms,
> these stopped working.
> 
> Netback sort of works as-is in this mode except:
> 
> - If there are no Rx requests and the internal Rx queue fills, only
>   the drain timeout will wake the thread.  The default drain timeout
>   of 10 s would give unacceptable pauses.
> 
> - If an Rx stall was detected and the internal Rx queue is drained,
>   then the Rx thread would never wake.
> 
> Handle these two cases (when feature-rx-notify is disabled) by:
> 
> - Reducing the drain timeout to 30 ms.
> 
> - Disabling Rx stall detection.
> 
> Reported-by: John <jw@nuclearfallout.net>
> Tested-by: John <jw@nuclearfallout.net>
> Signed-off-by: David Vrabel <david.vrabel@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 Dec 18 12:06:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12: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 1Y1Zpt-0001nl-E9; Thu, 18 Dec 2014 12:05:41 +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 1Y1Zpr-0001ng-W2
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 12:05:40 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	39/92-23865-313C2945; Thu, 18 Dec 2014 12:05:39 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418904338!14302672!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1695 invoked from network); 18 Dec 2014 12:05:38 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 12:05:38 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so1536493wiv.13
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 04:05: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=p+hXumDuoABTayJxClIJuOo1wXKkFjEI1pbj247JztI=;
	b=WNtFi2gYKvUtiUJVU+MPty4iccvgoKSiHIL9uOdRu3mXuhKd0nahcW1FsO4wXtezyo
	4hs64KiTXQFcQM8hqeloBrVcziBJEzOWBGLAlx6ZBlNCgghr6S9uL7XF5pDWdI8jL8O6
	3wchYm/LTxE41I/nY79AfqqW1qHO8s1aAMux01AVWQNzB2wlOvHCFinOVW3/A08kyY3p
	cP3ACh8BgQGwy+6H9zXjR1DkyU7fssWLHQsU098S3idGgWlWohKcN3NVkLc3v5URmMrT
	XeIVzhOn78m7PfVA5G0bsdqJEm1K4/zhVBrDg2WBw3Ly68/W2L55xGfFTrmiBVxtAI+u
	6tFQ==
X-Gm-Message-State: ALoCoQnwuLcX+6J02wAA8fG3XwF+ibqbe8b6K5t3Jdq72ktCNmAN1hnvVJWcfIgudiVFVV2+P8xT
X-Received: by 10.180.186.40 with SMTP id fh8mr4648753wic.40.1418904338146;
	Thu, 18 Dec 2014 04:05:38 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([216.66.83.114])
	by mx.google.com with ESMTPSA id cp4sm8706604wjb.16.2014.12.18.04.05.36
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 04:05:37 -0800 (PST)
Message-ID: <5492C310.2050903@linaro.org>
Date: Thu, 18 Dec 2014 12:05: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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>
	<1418896057.11882.0.camel@citrix.com>
In-Reply-To: <1418896057.11882.0.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: Initialize the domain vgic
	lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 18/12/2014 09:47, Ian Campbell wrote:
> On Wed, 2014-12-17 at 15:40 +0000, Julien Grall wrote:
>> The domain vgic lock is used uninitialized.
>>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
>> ---
>>      This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
>>      unitialized. Luckily we only use the field "raw" which is reset to 0
>>      during the domain allocation.
>>
>>      There is no harm to apply for Xen 4.5 because it will correctly set
>>      the spin_lock structure for a later usage.
>
> By your above reasoning there is also no point, is there? That said, I
> think we should take this since as you say it is harmless and good
> practice to initialise spinlocks even if not strictly necessary.

It's necessary to initialize spinlocks, not all the field of the 
spinlock is using the value 0 at initialization time.

What I meant if the current usage is fine. But if we want to debug 
spinlock, it won't work.

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 Dec 18 12:06:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12: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 1Y1Zpt-0001nl-E9; Thu, 18 Dec 2014 12:05:41 +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 1Y1Zpr-0001ng-W2
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 12:05:40 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	39/92-23865-313C2945; Thu, 18 Dec 2014 12:05:39 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418904338!14302672!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1695 invoked from network); 18 Dec 2014 12:05:38 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 12:05:38 -0000
Received: by mail-wi0-f180.google.com with SMTP id n3so1536493wiv.13
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 04:05: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=p+hXumDuoABTayJxClIJuOo1wXKkFjEI1pbj247JztI=;
	b=WNtFi2gYKvUtiUJVU+MPty4iccvgoKSiHIL9uOdRu3mXuhKd0nahcW1FsO4wXtezyo
	4hs64KiTXQFcQM8hqeloBrVcziBJEzOWBGLAlx6ZBlNCgghr6S9uL7XF5pDWdI8jL8O6
	3wchYm/LTxE41I/nY79AfqqW1qHO8s1aAMux01AVWQNzB2wlOvHCFinOVW3/A08kyY3p
	cP3ACh8BgQGwy+6H9zXjR1DkyU7fssWLHQsU098S3idGgWlWohKcN3NVkLc3v5URmMrT
	XeIVzhOn78m7PfVA5G0bsdqJEm1K4/zhVBrDg2WBw3Ly68/W2L55xGfFTrmiBVxtAI+u
	6tFQ==
X-Gm-Message-State: ALoCoQnwuLcX+6J02wAA8fG3XwF+ibqbe8b6K5t3Jdq72ktCNmAN1hnvVJWcfIgudiVFVV2+P8xT
X-Received: by 10.180.186.40 with SMTP id fh8mr4648753wic.40.1418904338146;
	Thu, 18 Dec 2014 04:05:38 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([216.66.83.114])
	by mx.google.com with ESMTPSA id cp4sm8706604wjb.16.2014.12.18.04.05.36
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 04:05:37 -0800 (PST)
Message-ID: <5492C310.2050903@linaro.org>
Date: Thu, 18 Dec 2014 12:05: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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>
	<1418896057.11882.0.camel@citrix.com>
In-Reply-To: <1418896057.11882.0.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: Initialize the domain vgic
	lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 18/12/2014 09:47, Ian Campbell wrote:
> On Wed, 2014-12-17 at 15:40 +0000, Julien Grall wrote:
>> The domain vgic lock is used uninitialized.
>>
>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
>> ---
>>      This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
>>      unitialized. Luckily we only use the field "raw" which is reset to 0
>>      during the domain allocation.
>>
>>      There is no harm to apply for Xen 4.5 because it will correctly set
>>      the spin_lock structure for a later usage.
>
> By your above reasoning there is also no point, is there? That said, I
> think we should take this since as you say it is harmless and good
> practice to initialise spinlocks even if not strictly necessary.

It's necessary to initialize spinlocks, not all the field of the 
spinlock is using the value 0 at initialization time.

What I meant if the current usage is fine. But if we want to debug 
spinlock, it won't work.

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 Dec 18 12:12:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Zwf-00023k-Ch; Thu, 18 Dec 2014 12:12: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 1Y1Zwd-00023f-Lp
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 12:12:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	99/12-25276-7B4C2945; Thu, 18 Dec 2014 12:12:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418904757!16140072!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 4735 invoked from network); 18 Dec 2014 12:12:38 -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;
	18 Dec 2014 12:12:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206224639"
Message-ID: <1418904755.11882.43.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 18 Dec 2014 12:12:35 +0000
In-Reply-To: <5492C310.2050903@linaro.org>
References: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>
	<1418896057.11882.0.camel@citrix.com> <5492C310.2050903@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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: Initialize the domain vgic
	lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-12-18 at 12:05 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 18/12/2014 09:47, Ian Campbell wrote:
> > On Wed, 2014-12-17 at 15:40 +0000, Julien Grall wrote:
> >> The domain vgic lock is used uninitialized.
> >>
> >> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> >
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >
> >> ---
> >>      This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
> >>      unitialized. Luckily we only use the field "raw" which is reset to 0
> >>      during the domain allocation.
> >>
> >>      There is no harm to apply for Xen 4.5 because it will correctly set
> >>      the spin_lock structure for a later usage.
> >
> > By your above reasoning there is also no point, is there? That said, I
> > think we should take this since as you say it is harmless and good
> > practice to initialise spinlocks even if not strictly necessary.
> 
> It's necessary to initialize spinlocks, not all the field of the 
> spinlock is using the value 0 at initialization time.

You said "...we only use the field "raw" which is reset to 0...". Was
that statement inaccurate?

> What I meant if the current usage is fine. But if we want to debug 
> spinlock, it won't work.
> 
> Regards,
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 12:12:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1Zwf-00023k-Ch; Thu, 18 Dec 2014 12:12: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 1Y1Zwd-00023f-Lp
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 12:12:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	99/12-25276-7B4C2945; Thu, 18 Dec 2014 12:12:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418904757!16140072!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 4735 invoked from network); 18 Dec 2014 12:12:38 -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;
	18 Dec 2014 12:12:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="206224639"
Message-ID: <1418904755.11882.43.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Date: Thu, 18 Dec 2014 12:12:35 +0000
In-Reply-To: <5492C310.2050903@linaro.org>
References: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>
	<1418896057.11882.0.camel@citrix.com> <5492C310.2050903@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-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: Initialize the domain vgic
	lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2014-12-18 at 12:05 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 18/12/2014 09:47, Ian Campbell wrote:
> > On Wed, 2014-12-17 at 15:40 +0000, Julien Grall wrote:
> >> The domain vgic lock is used uninitialized.
> >>
> >> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> >
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >
> >> ---
> >>      This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
> >>      unitialized. Luckily we only use the field "raw" which is reset to 0
> >>      during the domain allocation.
> >>
> >>      There is no harm to apply for Xen 4.5 because it will correctly set
> >>      the spin_lock structure for a later usage.
> >
> > By your above reasoning there is also no point, is there? That said, I
> > think we should take this since as you say it is harmless and good
> > practice to initialise spinlocks even if not strictly necessary.
> 
> It's necessary to initialize spinlocks, not all the field of the 
> spinlock is using the value 0 at initialization time.

You said "...we only use the field "raw" which is reset to 0...". Was
that statement inaccurate?

> What I meant if the current usage is fine. But if we want to debug 
> spinlock, it won't work.
> 
> Regards,
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 12:15:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12:15:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ZzW-0002Nm-02; Thu, 18 Dec 2014 12:15:38 +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 1Y1ZzT-0002Nc-Sw
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 12:15:36 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	7A/62-17958-765C2945; Thu, 18 Dec 2014 12:15:35 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418904933!14356993!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2439 invoked from network); 18 Dec 2014 12:15:34 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 12:15:34 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=OBgkE4PtIgL+tRpkDlIfmg5f6s6EvRHqOnLa8vOerex+OvDuGzrInNGm
	Q46W6Uy5/NvmQbGJbHXoQW5+wq/Mbpn5P43Jkw6mQ7nH8SvWsoZdmf9u/
	+lvzGHY1tDMHMxac4KqzsPHH5AhIi3SVbh4VjXN/EeFfshE/hLPdt+h5d
	bn2GNkgQLFeEvwqFzKqHike36i19tf50hqC3ZLf8yVC3DQPO8bCB4nFLc
	Q6DRkZjXjF8xe5XJpT27GnSls2xdR;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1418904934; x=1450440934;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=TRVOYvUbgw+YBsn3D5Y+Hbz++HrJ+2I/cjCZg6xntHA=;
	b=J9eqRxJmcblUcEZD4QZ5J7+5m2viSXh+HF7IIHwX8oiVFi2t9LdbcRud
	pP8nd30xxxDI2e3lN0Xh5WYYEgCfRYtKVE5XvNBJthetYVUQCVOMQftvt
	TYNEXgvVdK8TxQB06TjG1y4BIhCKC3KTVTAkjgfo2hX12LuqzOe8uB9bE
	x3fLatYXkcJDOeBq62qmHKJAcvwLGQvgRWNbro68mN9wau/LbYN59F2T7
	l96KvsJ5i+G+z9M14BFwV8A4WQ8dX;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="5.07,600,1413237600"; d="scan'208";a="216797586"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 18 Dec 2014 13:15:33 +0100
X-IronPort-AV: E=Sophos;i="5.07,600,1413237600"; d="scan'208";a="56766851"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with ESMTP; 18 Dec 2014 13:15:33 +0100
Received: from amur.localnet (amur.mch.fsc.net [10.172.102.14])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 49478AB3BBC;
	Thu, 18 Dec 2014 13:15:33 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Thu, 18 Dec 2014 13:15:33 +0100
Message-ID: <2653567.YPYbLMrP7N@amur>
User-Agent: KMail/4.11.5 (Linux/3.11.10-21-xen; KDE/4.11.5; x86_64; ; )
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Cc: kevin.tian@intel.com, JBeulich@suse.com, jun.nakajima@intel.com,
	andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, suravee.suthikulpanit@amd.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v16 00/23] 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>
Content-Type: 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 17 Dezember 2014, 10:38:31 schrieb Boris Ostrovsky:
> Version 16 of PV(H) PMU patches.

Hi Boris,

I did a fast and simple test on a small Intel machine and all went fine. I'll
do some more after my vacation in 2015.
After adapting your sent linux kernel patches I'am interestet in tracing our
HVM guest from outside with perf. Are you already having some patches and would
you share these?
Thank you for your work!

Dietmar.

> 
> * Many changes in VPMU mode patch (#13):
>   * Replaced arguments to some vpmu routines (vcpu -> vpmu). New patch (#12)
>   * Added vpmu_unload vpmu op to completely unload vpmu data (e.g clear
>     MSR bitmaps). This routine may be called in context switch (vpmu_switch_to()).
>   * Added vmx_write_guest_msr_vcpu() interface to write MSRs of non-current VCPU
>   * Use cpumask_cycle instead of cpumask_next
>   * Dropped timeout error
>   * Adjusted types of mode variables
>   * Don't allow oprofile to allocate its context on MSR access if VPMU context
>     has already been allocated (which may happen when VMPU mode was set to off
>     while the guest was running)
> * vpmu_initialise() no longer turns off VPMU globally on failure. New patch (#2)
> * vpmu_do_msr() will return 1 (failure) if vpmu_ops are not set. This is done to
>   prevent PV guests that are not VPMU-enabled from wrongly assuming that they have
>   access to counters (Linux check_hw_exists() will make this assumption) (patch #18)
> * Add cpl field to shared structure that will be passed for HVM guests' samples
>   (instead of PMU_SAMPLE_USER flag). Add PMU_SAMPLE_PV flag to mark whose sample
>   is passed up. (Patches ## 10, 19, 22)
> 
> 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 (23):
>   common/symbols: Export hypervisor symbols to privileged guest
>   x86/VPMU: Don't globally disable VPMU if initialization fails.
>   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: Replace vcpu with vpmu as argument to some routines
>   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                            | 896 +++++++++++++++++++++
>  xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c}    | 289 ++++---
>  .../x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} | 815 ++++++++++---------
>  xen/arch/x86/domain.c                              |  27 +-
>  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                        |  91 +--
>  xen/arch/x86/hvm/vmx/vmx.c                         |  28 +-
>  xen/arch/x86/hvm/vpmu.c                            | 266 ------
>  xen/arch/x86/oprofile/nmi_int.c                    |   3 +-
>  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                 |  25 +-
>  xen/include/asm-x86/hvm/vmx/vpmu_core2.h           |  51 --
>  xen/include/asm-x86/hvm/vpmu.h                     | 105 ---
>  xen/include/asm-x86/softirq.h                      |   3 +-
>  xen/include/asm-x86/vpmu.h                         | 149 ++++
>  xen/include/public/arch-arm.h                      |   3 +
>  xen/include/public/arch-x86/pmu.h                  |  97 +++
>  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 +
>  45 files changed, 2194 insertions(+), 1040 deletions(-)
>  create mode 100644 xen/arch/x86/cpu/vpmu.c
>  rename xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} (64%)
>  rename xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} (56%)
>  delete mode 100644 xen/arch/x86/hvm/vpmu.c
>  delete mode 100644 xen/include/asm-x86/hvm/vmx/vpmu_core2.h
>  delete mode 100644 xen/include/asm-x86/hvm/vpmu.h
>  create mode 100644 xen/include/asm-x86/vpmu.h
>  create mode 100644 xen/include/public/arch-x86/pmu.h
>  create mode 100644 xen/include/public/pmu.h
> 
> 

-- 
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 Thu Dec 18 12:15:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12:15:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ZzW-0002Nm-02; Thu, 18 Dec 2014 12:15:38 +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 1Y1ZzT-0002Nc-Sw
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 12:15:36 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	7A/62-17958-765C2945; Thu, 18 Dec 2014 12:15:35 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418904933!14356993!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2439 invoked from network); 18 Dec 2014 12:15:34 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 12:15:34 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=OBgkE4PtIgL+tRpkDlIfmg5f6s6EvRHqOnLa8vOerex+OvDuGzrInNGm
	Q46W6Uy5/NvmQbGJbHXoQW5+wq/Mbpn5P43Jkw6mQ7nH8SvWsoZdmf9u/
	+lvzGHY1tDMHMxac4KqzsPHH5AhIi3SVbh4VjXN/EeFfshE/hLPdt+h5d
	bn2GNkgQLFeEvwqFzKqHike36i19tf50hqC3ZLf8yVC3DQPO8bCB4nFLc
	Q6DRkZjXjF8xe5XJpT27GnSls2xdR;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1418904934; x=1450440934;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=TRVOYvUbgw+YBsn3D5Y+Hbz++HrJ+2I/cjCZg6xntHA=;
	b=J9eqRxJmcblUcEZD4QZ5J7+5m2viSXh+HF7IIHwX8oiVFi2t9LdbcRud
	pP8nd30xxxDI2e3lN0Xh5WYYEgCfRYtKVE5XvNBJthetYVUQCVOMQftvt
	TYNEXgvVdK8TxQB06TjG1y4BIhCKC3KTVTAkjgfo2hX12LuqzOe8uB9bE
	x3fLatYXkcJDOeBq62qmHKJAcvwLGQvgRWNbro68mN9wau/LbYN59F2T7
	l96KvsJ5i+G+z9M14BFwV8A4WQ8dX;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="5.07,600,1413237600"; d="scan'208";a="216797586"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 18 Dec 2014 13:15:33 +0100
X-IronPort-AV: E=Sophos;i="5.07,600,1413237600"; d="scan'208";a="56766851"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with ESMTP; 18 Dec 2014 13:15:33 +0100
Received: from amur.localnet (amur.mch.fsc.net [10.172.102.14])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 49478AB3BBC;
	Thu, 18 Dec 2014 13:15:33 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Thu, 18 Dec 2014 13:15:33 +0100
Message-ID: <2653567.YPYbLMrP7N@amur>
User-Agent: KMail/4.11.5 (Linux/3.11.10-21-xen; KDE/4.11.5; x86_64; ; )
In-Reply-To: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Cc: kevin.tian@intel.com, JBeulich@suse.com, jun.nakajima@intel.com,
	andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, suravee.suthikulpanit@amd.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v16 00/23] 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>
Content-Type: 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 17 Dezember 2014, 10:38:31 schrieb Boris Ostrovsky:
> Version 16 of PV(H) PMU patches.

Hi Boris,

I did a fast and simple test on a small Intel machine and all went fine. I'll
do some more after my vacation in 2015.
After adapting your sent linux kernel patches I'am interestet in tracing our
HVM guest from outside with perf. Are you already having some patches and would
you share these?
Thank you for your work!

Dietmar.

> 
> * Many changes in VPMU mode patch (#13):
>   * Replaced arguments to some vpmu routines (vcpu -> vpmu). New patch (#12)
>   * Added vpmu_unload vpmu op to completely unload vpmu data (e.g clear
>     MSR bitmaps). This routine may be called in context switch (vpmu_switch_to()).
>   * Added vmx_write_guest_msr_vcpu() interface to write MSRs of non-current VCPU
>   * Use cpumask_cycle instead of cpumask_next
>   * Dropped timeout error
>   * Adjusted types of mode variables
>   * Don't allow oprofile to allocate its context on MSR access if VPMU context
>     has already been allocated (which may happen when VMPU mode was set to off
>     while the guest was running)
> * vpmu_initialise() no longer turns off VPMU globally on failure. New patch (#2)
> * vpmu_do_msr() will return 1 (failure) if vpmu_ops are not set. This is done to
>   prevent PV guests that are not VPMU-enabled from wrongly assuming that they have
>   access to counters (Linux check_hw_exists() will make this assumption) (patch #18)
> * Add cpl field to shared structure that will be passed for HVM guests' samples
>   (instead of PMU_SAMPLE_USER flag). Add PMU_SAMPLE_PV flag to mark whose sample
>   is passed up. (Patches ## 10, 19, 22)
> 
> 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 (23):
>   common/symbols: Export hypervisor symbols to privileged guest
>   x86/VPMU: Don't globally disable VPMU if initialization fails.
>   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: Replace vcpu with vpmu as argument to some routines
>   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                            | 896 +++++++++++++++++++++
>  xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c}    | 289 ++++---
>  .../x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} | 815 ++++++++++---------
>  xen/arch/x86/domain.c                              |  27 +-
>  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                        |  91 +--
>  xen/arch/x86/hvm/vmx/vmx.c                         |  28 +-
>  xen/arch/x86/hvm/vpmu.c                            | 266 ------
>  xen/arch/x86/oprofile/nmi_int.c                    |   3 +-
>  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                 |  25 +-
>  xen/include/asm-x86/hvm/vmx/vpmu_core2.h           |  51 --
>  xen/include/asm-x86/hvm/vpmu.h                     | 105 ---
>  xen/include/asm-x86/softirq.h                      |   3 +-
>  xen/include/asm-x86/vpmu.h                         | 149 ++++
>  xen/include/public/arch-arm.h                      |   3 +
>  xen/include/public/arch-x86/pmu.h                  |  97 +++
>  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 +
>  45 files changed, 2194 insertions(+), 1040 deletions(-)
>  create mode 100644 xen/arch/x86/cpu/vpmu.c
>  rename xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} (64%)
>  rename xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} (56%)
>  delete mode 100644 xen/arch/x86/hvm/vpmu.c
>  delete mode 100644 xen/include/asm-x86/hvm/vmx/vpmu_core2.h
>  delete mode 100644 xen/include/asm-x86/hvm/vpmu.h
>  create mode 100644 xen/include/asm-x86/vpmu.h
>  create mode 100644 xen/include/public/arch-x86/pmu.h
>  create mode 100644 xen/include/public/pmu.h
> 
> 

-- 
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 Thu Dec 18 12:19:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12: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 1Y1a2z-0002Yl-Q8; Thu, 18 Dec 2014 12:19:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y1a2y-0002Yf-Ki
	for xen-devel@lists.xensource.com; Thu, 18 Dec 2014 12:19:12 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	12/BE-22737-F36C2945; Thu, 18 Dec 2014 12:19:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418905148!8809070!1
X-Originating-IP: [66.165.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 15252 invoked from network); 18 Dec 2014 12:19:10 -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 Dec 2014 12:19:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="205752828"
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.210.2; Thu, 18 Dec 2014 07:19: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 1Y1a2t-00053M-E2;
	Thu, 18 Dec 2014 12:19:07 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1a2t-00037i-8C;
	Thu, 18 Dec 2014 12:19:07 +0000
Date: Thu, 18 Dec 2014 12:19:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32431-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] 32431: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32431 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32431/

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    9 guest-start               fail REGR. vs. 31241
 test-amd64-amd64-xl           9 guest-start               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-amd64-pair        16 guest-start/debian        fail REGR. vs. 31241
 test-amd64-i386-pair         16 guest-start/debian        fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 31241
 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-amd64-xl-sedf     15 guest-localmigrate/x10    fail REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-amd64-xl-pvh-amd   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-amd64-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-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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                603ba7e41bf5d405aba22294af5d075d8898176d
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1855 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                                           fail    
 test-amd64-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


Not pushing.

(No revision log; it would be 221731 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 Dec 18 12:19:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12: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 1Y1a2z-0002Yl-Q8; Thu, 18 Dec 2014 12:19:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y1a2y-0002Yf-Ki
	for xen-devel@lists.xensource.com; Thu, 18 Dec 2014 12:19:12 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	12/BE-22737-F36C2945; Thu, 18 Dec 2014 12:19:11 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418905148!8809070!1
X-Originating-IP: [66.165.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 15252 invoked from network); 18 Dec 2014 12:19:10 -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 Dec 2014 12:19:10 -0000
X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="205752828"
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.210.2; Thu, 18 Dec 2014 07:19: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 1Y1a2t-00053M-E2;
	Thu, 18 Dec 2014 12:19:07 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1a2t-00037i-8C;
	Thu, 18 Dec 2014 12:19:07 +0000
Date: Thu, 18 Dec 2014 12:19:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32431-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] 32431: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32431 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32431/

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    9 guest-start               fail REGR. vs. 31241
 test-amd64-amd64-xl           9 guest-start               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-amd64-pair        16 guest-start/debian        fail REGR. vs. 31241
 test-amd64-i386-pair         16 guest-start/debian        fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 31241
 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-amd64-xl-sedf     15 guest-localmigrate/x10    fail REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-amd64-xl-pvh-amd   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-amd64-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-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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                603ba7e41bf5d405aba22294af5d075d8898176d
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1855 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                                           fail    
 test-amd64-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


Not pushing.

(No revision log; it would be 221731 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 Dec 18 12:26:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12:26:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1a9h-00032r-M1; Thu, 18 Dec 2014 12:26:09 +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 1Y1a9e-00032j-Np
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 12:26:07 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	97/F1-02699-ED7C2945; Thu, 18 Dec 2014 12:26:06 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418905565!15924036!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13915 invoked from network); 18 Dec 2014 12:26:05 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 12:26:05 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so1606549wiw.10
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 04:26: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=cRjTMOHCcoXCoDYV+yRjPjlorQSXzj0pDhSpQwCjqm4=;
	b=P0+qdwbBeuxuzf/lRZwXNsTzg6FwMG2I+bpupg4N+nIWns3aczDQpnFpfwGbzk5vqb
	slweo2YL09povdS7XtZftaQJN9HHPxJcZFwvyAl0A2XctzklNTeUz/Q6RnmZqWpvvMKo
	qZICMTgc1pJzJf3K2ozYmif6TVC5QMuf0yyYWOiu8Ejwi3SMZezyoLp12DRpwA88HD+L
	1F/gMvBa5UC16m/5H63eF0q3/M23t9gTjWGEtlDojg1BqY4dlxKo6o8+FuE8dswRS56F
	mNwGq+ReVD2n95jhHVJS09hV+0HQbTAtRXCoGmNoet0DGSFwP+sBg45ffTF57FHE3LEk
	jEKw==
X-Gm-Message-State: ALoCoQlEiZ1Fvs1dWUqHufDuGJa6nk1Ey9i+EvtVyNHqQZ6g6Rxh8u9TSGsXOWfifMm8EZH17iNL
X-Received: by 10.180.8.70 with SMTP id p6mr24463737wia.72.1418905564827;
	Thu, 18 Dec 2014 04:26:04 -0800 (PST)
Received: from [192.168.43.124] (188.29.164.254.threembb.co.uk.
	[188.29.164.254])
	by mx.google.com with ESMTPSA id ej10sm9804971wib.2.2014.12.18.04.26.02
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 04:26:03 -0800 (PST)
Message-ID: <5492C7DA.8050301@linaro.org>
Date: Thu, 18 Dec 2014 12:26:02 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>	
	<1418896057.11882.0.camel@citrix.com> <5492C310.2050903@linaro.org>
	<1418904755.11882.43.camel@citrix.com>
In-Reply-To: <1418904755.11882.43.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: Initialize the domain vgic
	lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 18/12/2014 12:12, Ian Campbell wrote:
> On Thu, 2014-12-18 at 12:05 +0000, Julien Grall wrote:
>> Hi Ian,
>>
>> On 18/12/2014 09:47, Ian Campbell wrote:
>>> On Wed, 2014-12-17 at 15:40 +0000, Julien Grall wrote:
>>>> The domain vgic lock is used uninitialized.
>>>>
>>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>>
>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>
>>>> ---
>>>>       This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
>>>>       unitialized. Luckily we only use the field "raw" which is reset to 0
>>>>       during the domain allocation.
>>>>
>>>>       There is no harm to apply for Xen 4.5 because it will correctly set
>>>>       the spin_lock structure for a later usage.
>>>
>>> By your above reasoning there is also no point, is there? That said, I
>>> think we should take this since as you say it is harmless and good
>>> practice to initialise spinlocks even if not strictly necessary.
>>
>> It's necessary to initialize spinlocks, not all the field of the
>> spinlock is using the value 0 at initialization time.
>
> You said "...we only use the field "raw" which is reset to 0...". Was
> that statement inaccurate?

It's accurate in the current. I should have give more details earlier, 
sorry.

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 Dec 18 12:26:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12:26:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1a9h-00032r-M1; Thu, 18 Dec 2014 12:26:09 +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 1Y1a9e-00032j-Np
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 12:26:07 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	97/F1-02699-ED7C2945; Thu, 18 Dec 2014 12:26:06 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418905565!15924036!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13915 invoked from network); 18 Dec 2014 12:26:05 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 12:26:05 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so1606549wiw.10
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 04:26: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=cRjTMOHCcoXCoDYV+yRjPjlorQSXzj0pDhSpQwCjqm4=;
	b=P0+qdwbBeuxuzf/lRZwXNsTzg6FwMG2I+bpupg4N+nIWns3aczDQpnFpfwGbzk5vqb
	slweo2YL09povdS7XtZftaQJN9HHPxJcZFwvyAl0A2XctzklNTeUz/Q6RnmZqWpvvMKo
	qZICMTgc1pJzJf3K2ozYmif6TVC5QMuf0yyYWOiu8Ejwi3SMZezyoLp12DRpwA88HD+L
	1F/gMvBa5UC16m/5H63eF0q3/M23t9gTjWGEtlDojg1BqY4dlxKo6o8+FuE8dswRS56F
	mNwGq+ReVD2n95jhHVJS09hV+0HQbTAtRXCoGmNoet0DGSFwP+sBg45ffTF57FHE3LEk
	jEKw==
X-Gm-Message-State: ALoCoQlEiZ1Fvs1dWUqHufDuGJa6nk1Ey9i+EvtVyNHqQZ6g6Rxh8u9TSGsXOWfifMm8EZH17iNL
X-Received: by 10.180.8.70 with SMTP id p6mr24463737wia.72.1418905564827;
	Thu, 18 Dec 2014 04:26:04 -0800 (PST)
Received: from [192.168.43.124] (188.29.164.254.threembb.co.uk.
	[188.29.164.254])
	by mx.google.com with ESMTPSA id ej10sm9804971wib.2.2014.12.18.04.26.02
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 04:26:03 -0800 (PST)
Message-ID: <5492C7DA.8050301@linaro.org>
Date: Thu, 18 Dec 2014 12:26:02 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>	
	<1418896057.11882.0.camel@citrix.com> <5492C310.2050903@linaro.org>
	<1418904755.11882.43.camel@citrix.com>
In-Reply-To: <1418904755.11882.43.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: Initialize the domain vgic
	lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 18/12/2014 12:12, Ian Campbell wrote:
> On Thu, 2014-12-18 at 12:05 +0000, Julien Grall wrote:
>> Hi Ian,
>>
>> On 18/12/2014 09:47, Ian Campbell wrote:
>>> On Wed, 2014-12-17 at 15:40 +0000, Julien Grall wrote:
>>>> The domain vgic lock is used uninitialized.
>>>>
>>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>>
>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>
>>>> ---
>>>>       This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
>>>>       unitialized. Luckily we only use the field "raw" which is reset to 0
>>>>       during the domain allocation.
>>>>
>>>>       There is no harm to apply for Xen 4.5 because it will correctly set
>>>>       the spin_lock structure for a later usage.
>>>
>>> By your above reasoning there is also no point, is there? That said, I
>>> think we should take this since as you say it is harmless and good
>>> practice to initialise spinlocks even if not strictly necessary.
>>
>> It's necessary to initialize spinlocks, not all the field of the
>> spinlock is using the value 0 at initialization time.
>
> You said "...we only use the field "raw" which is reset to 0...". Was
> that statement inaccurate?

It's accurate in the current. I should have give more details earlier, 
sorry.

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 Dec 18 12:52:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12: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 1Y1aYR-0003vf-2Y; Thu, 18 Dec 2014 12:51: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 1Y1aYP-0003va-Ds
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 12:51:41 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	D2/8D-17735-CDDC2945; Thu, 18 Dec 2014 12:51:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418907099!14368826!1
X-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 4032 invoked from network); 18 Dec 2014 12:51:40 -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; 18 Dec 2014 12:51:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 12:51:39 +0000
Message-Id: <5492DBEA02000078000509AB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 12:51:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <chegger@amazon.de>
References: <1417616967-18720-1-git-send-email-chegger@amazon.de>
	<1417616967-18720-3-git-send-email-chegger@amazon.de>
In-Reply-To: <1417616967-18720-3-git-send-email-chegger@amazon.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Anthony Liguori <aliguori@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 2/2] gnttab: refactor locking for
	scalability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 15:29, <chegger@amazon.de> wrote:
> @@ -182,6 +185,29 @@ nr_active_grant_frames(struct grant_table *gt)
>      return num_act_frames_from_sha_frames(nr_grant_frames(gt));
>  }
>  
> +static inline struct active_grant_entry *
> +active_entry_acquire(struct grant_table *t, grant_ref_t e)
> +{
> +    struct active_grant_entry *act;
> +
> +#ifndef NDEBUG
> +    /* not perfect, but better than nothing for a debug build
> +     * sanity check
> +     */
> +    BUG_ON(!rw_is_locked(&t->lock));
> +#endif

ASSERT() is the canonical way to achieve this.

> @@ -508,17 +511,27 @@ static int grant_map_exists(const struct domain *ld,
>                     nr_grant_entries(rgt));
>      for ( ref = *ref_count; ref < max_iter; ref++ )
>      {
> -        act = &active_entry(rgt, ref);
> +        act = active_entry_acquire(rgt, ref);
>  
>          if ( !act->pin )
> +        {
> +            active_entry_release(act);
>              continue;
> +        }
>  
>          if ( act->domid != ld->domain_id )
> +        {
> +            active_entry_release(act);
>              continue;
> +        }
>  
>          if ( act->frame != mfn )
> +        {
> +            active_entry_release(act);
>              continue;
> +        }

With this repeated 3 times, perhaps simpler and easier to read if you
put this ahead of the increment inside the for() header?

> @@ -531,24 +544,44 @@ static int grant_map_exists(const struct domain *ld,
>      return -EINVAL;
>  }
>  
> +/* Count the number of mapped ro or rw entries tracked in the left
> + * grant table given a provided mfn provided by a foreign domain. 
> + *
> + * This function takes the maptrack lock from the left grant table and
> + * must be called with the right grant table's rwlock held.
> + */
>  static void mapcount(
>      struct grant_table *lgt, struct domain *rd, unsigned long mfn,
>      unsigned int *wrc, unsigned int *rdc)
>  {
>      struct grant_mapping *map;
>      grant_handle_t handle;
> +    struct active_grant_entry *act;

I don't see the need for this new local variable.

>      *wrc = *rdc = 0;
>  
> +    /* N.B.: while taking the left side maptrack spinlock prevents
> +     * any mapping changes, the right side active entries could be
> +     * changing while we are counting. To be perfectly correct, the
> +     * caller should hold the grant table write lock, or some other
> +     * mechanism should be used to prevent concurrent changes during
> +     * this operation. This is tricky because we can't promote a read
> +     * lock into a write lock.
> +     */
> +    spin_lock(&lgt->maptrack_lock);

We can't afford being less than "perfectly correct" here, as the
insertion/removal of IOMMU mappings is driven by the result of
this function. Or wait, together with the comment ahead of the
function, are you perhaps simply meaning "has to" instead of
"should", and perhaps without the "To be perfectly correct" pre-
condition? Also, to prevent changes holding the grant table lock
for reading ought to be sufficient.  Which you then should
ASSERT() is the case just like you do in active_entry_acquire().

> @@ -692,12 +724,9 @@ __gnttab_map_grant_ref(
>              GNTPIN_hstr_inc : GNTPIN_hstw_inc;
>  
>      frame = act->frame;
> -    act_pin = act->pin;
>  
>      cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
>  
> -    read_unlock(&rgt->lock);
> -
>      /* pg may be set, with a refcount included, from __get_paged_frame */
>      if ( !pg )
>      {
> @@ -772,8 +801,6 @@ __gnttab_map_grant_ref(
>          goto undo_out;
>      }
>  
> -    double_gt_lock(lgt, rgt);
> -
>      if ( gnttab_need_iommu_mapping(ld) )
>      {
>          unsigned int wrc, rdc;

Taking these two together - isn't patch 1 wrong then, in that it
acquires both maptrack locks in double_gt_lock()?

> @@ -891,9 +917,9 @@ __gnttab_unmap_common(
>      ld = current->domain;
>      lgt = ld->grant_table;
>  
> -    read_lock(&lgt->lock);
>      op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
>  
> +    read_lock(&lgt->lock);
>      if ( unlikely(op->handle >= lgt->maptrack_limit) )
>      {
>          read_unlock(&lgt->lock);

This should be done this way in patch 1.

> @@ -933,19 +959,18 @@ __gnttab_unmap_common(
>      TRACE_1D(TRC_MEM_PAGE_GRANT_UNMAP, dom);
>  
>      rgt = rd->grant_table;
> -    double_gt_lock(lgt, rgt);
>  
>      op->flags = op->map->flags;
>      if ( unlikely(!op->flags) || unlikely(op->map->domid != dom) )

How are these checks guarded now?

> @@ -1310,6 +1341,10 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
>          if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
>              goto active_alloc_failed;
>          clear_page(gt->active[i]);
> +        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
> +        {
> +            spin_lock_init(&gt->active[i][j].lock);
> +        }

Please omit the braces when the body is just a single statement.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 12:52:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12: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 1Y1aYR-0003vf-2Y; Thu, 18 Dec 2014 12:51: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 1Y1aYP-0003va-Ds
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 12:51:41 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	D2/8D-17735-CDDC2945; Thu, 18 Dec 2014 12:51:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418907099!14368826!1
X-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 4032 invoked from network); 18 Dec 2014 12:51:40 -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; 18 Dec 2014 12:51:40 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 12:51:39 +0000
Message-Id: <5492DBEA02000078000509AB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 12:51:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <chegger@amazon.de>
References: <1417616967-18720-1-git-send-email-chegger@amazon.de>
	<1417616967-18720-3-git-send-email-chegger@amazon.de>
In-Reply-To: <1417616967-18720-3-git-send-email-chegger@amazon.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>,
	Anthony Liguori <aliguori@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3 2/2] gnttab: refactor locking for
	scalability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 15:29, <chegger@amazon.de> wrote:
> @@ -182,6 +185,29 @@ nr_active_grant_frames(struct grant_table *gt)
>      return num_act_frames_from_sha_frames(nr_grant_frames(gt));
>  }
>  
> +static inline struct active_grant_entry *
> +active_entry_acquire(struct grant_table *t, grant_ref_t e)
> +{
> +    struct active_grant_entry *act;
> +
> +#ifndef NDEBUG
> +    /* not perfect, but better than nothing for a debug build
> +     * sanity check
> +     */
> +    BUG_ON(!rw_is_locked(&t->lock));
> +#endif

ASSERT() is the canonical way to achieve this.

> @@ -508,17 +511,27 @@ static int grant_map_exists(const struct domain *ld,
>                     nr_grant_entries(rgt));
>      for ( ref = *ref_count; ref < max_iter; ref++ )
>      {
> -        act = &active_entry(rgt, ref);
> +        act = active_entry_acquire(rgt, ref);
>  
>          if ( !act->pin )
> +        {
> +            active_entry_release(act);
>              continue;
> +        }
>  
>          if ( act->domid != ld->domain_id )
> +        {
> +            active_entry_release(act);
>              continue;
> +        }
>  
>          if ( act->frame != mfn )
> +        {
> +            active_entry_release(act);
>              continue;
> +        }

With this repeated 3 times, perhaps simpler and easier to read if you
put this ahead of the increment inside the for() header?

> @@ -531,24 +544,44 @@ static int grant_map_exists(const struct domain *ld,
>      return -EINVAL;
>  }
>  
> +/* Count the number of mapped ro or rw entries tracked in the left
> + * grant table given a provided mfn provided by a foreign domain. 
> + *
> + * This function takes the maptrack lock from the left grant table and
> + * must be called with the right grant table's rwlock held.
> + */
>  static void mapcount(
>      struct grant_table *lgt, struct domain *rd, unsigned long mfn,
>      unsigned int *wrc, unsigned int *rdc)
>  {
>      struct grant_mapping *map;
>      grant_handle_t handle;
> +    struct active_grant_entry *act;

I don't see the need for this new local variable.

>      *wrc = *rdc = 0;
>  
> +    /* N.B.: while taking the left side maptrack spinlock prevents
> +     * any mapping changes, the right side active entries could be
> +     * changing while we are counting. To be perfectly correct, the
> +     * caller should hold the grant table write lock, or some other
> +     * mechanism should be used to prevent concurrent changes during
> +     * this operation. This is tricky because we can't promote a read
> +     * lock into a write lock.
> +     */
> +    spin_lock(&lgt->maptrack_lock);

We can't afford being less than "perfectly correct" here, as the
insertion/removal of IOMMU mappings is driven by the result of
this function. Or wait, together with the comment ahead of the
function, are you perhaps simply meaning "has to" instead of
"should", and perhaps without the "To be perfectly correct" pre-
condition? Also, to prevent changes holding the grant table lock
for reading ought to be sufficient.  Which you then should
ASSERT() is the case just like you do in active_entry_acquire().

> @@ -692,12 +724,9 @@ __gnttab_map_grant_ref(
>              GNTPIN_hstr_inc : GNTPIN_hstw_inc;
>  
>      frame = act->frame;
> -    act_pin = act->pin;
>  
>      cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
>  
> -    read_unlock(&rgt->lock);
> -
>      /* pg may be set, with a refcount included, from __get_paged_frame */
>      if ( !pg )
>      {
> @@ -772,8 +801,6 @@ __gnttab_map_grant_ref(
>          goto undo_out;
>      }
>  
> -    double_gt_lock(lgt, rgt);
> -
>      if ( gnttab_need_iommu_mapping(ld) )
>      {
>          unsigned int wrc, rdc;

Taking these two together - isn't patch 1 wrong then, in that it
acquires both maptrack locks in double_gt_lock()?

> @@ -891,9 +917,9 @@ __gnttab_unmap_common(
>      ld = current->domain;
>      lgt = ld->grant_table;
>  
> -    read_lock(&lgt->lock);
>      op->frame = (unsigned long)(op->dev_bus_addr >> PAGE_SHIFT);
>  
> +    read_lock(&lgt->lock);
>      if ( unlikely(op->handle >= lgt->maptrack_limit) )
>      {
>          read_unlock(&lgt->lock);

This should be done this way in patch 1.

> @@ -933,19 +959,18 @@ __gnttab_unmap_common(
>      TRACE_1D(TRC_MEM_PAGE_GRANT_UNMAP, dom);
>  
>      rgt = rd->grant_table;
> -    double_gt_lock(lgt, rgt);
>  
>      op->flags = op->map->flags;
>      if ( unlikely(!op->flags) || unlikely(op->map->domid != dom) )

How are these checks guarded now?

> @@ -1310,6 +1341,10 @@ gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
>          if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
>              goto active_alloc_failed;
>          clear_page(gt->active[i]);
> +        for ( j = 0; j < ACGNT_PER_PAGE; j++ )
> +        {
> +            spin_lock_init(&gt->active[i][j].lock);
> +        }

Please omit the braces when the body is just a single statement.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 12:59:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12: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 1Y1afa-0004Pc-Vn; Thu, 18 Dec 2014 12:59: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 1Y1afZ-0004PX-Nw
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 12:59:05 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	ED/34-22777-89FC2945; Thu, 18 Dec 2014 12:59:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418907544!8706943!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11791 invoked from network); 18 Dec 2014 12:59:04 -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; 18 Dec 2014 12:59:04 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 12:59:04 +0000
Message-Id: <5492DDA602000078000509CB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 12:59:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-5-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-5-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> --- 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

If you want to abbreviate it, please make it HAS_TURBO. If you
want to spell it out, please use HAS_CPUFREQ_TURBO.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 12:59:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 12: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 1Y1afa-0004Pc-Vn; Thu, 18 Dec 2014 12:59: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 1Y1afZ-0004PX-Nw
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 12:59:05 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	ED/34-22777-89FC2945; Thu, 18 Dec 2014 12:59:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418907544!8706943!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11791 invoked from network); 18 Dec 2014 12:59:04 -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; 18 Dec 2014 12:59:04 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 12:59:04 +0000
Message-Id: <5492DDA602000078000509CB@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 12:59:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-5-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-5-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> --- 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

If you want to abbreviate it, please make it HAS_TURBO. If you
want to spell it out, please use HAS_CPUFREQ_TURBO.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:00:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:00:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1agT-0004UJ-Dt; Thu, 18 Dec 2014 13:00: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 1Y1agR-0004Tj-Nb
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 12:59:59 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	07/F2-02957-ECFC2945; Thu, 18 Dec 2014 12:59:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418907598!15934338!1
X-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 16894 invoked from network); 18 Dec 2014 12:59:58 -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; 18 Dec 2014 12:59:58 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 12:59:58 +0000
Message-Id: <5492DDDD02000078000509D3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 12:59:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> 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>

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 Dec 18 13:00:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:00:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1agT-0004UJ-Dt; Thu, 18 Dec 2014 13:00: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 1Y1agR-0004Tj-Nb
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 12:59:59 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	07/F2-02957-ECFC2945; Thu, 18 Dec 2014 12:59:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418907598!15934338!1
X-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 16894 invoked from network); 18 Dec 2014 12:59:58 -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; 18 Dec 2014 12:59:58 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 12:59:58 +0000
Message-Id: <5492DDDD02000078000509D3@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 12:59:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-6-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> 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>

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 Dec 18 13:00:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:00:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1agg-0004Xy-Qy; Thu, 18 Dec 2014 13:00:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1agf-0004Xd-KM
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:00:13 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	A6/2F-29352-CDFC2945; Thu, 18 Dec 2014 13:00:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418907612!9988734!1
X-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 14444 invoked from network); 18 Dec 2014 13:00:12 -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; 18 Dec 2014 13:00:12 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:00:12 +0000
Message-Id: <5492DDEC02000078000509D6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:00:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-2-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-2-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> 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>

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 Dec 18 13:00:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:00:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1agg-0004Xy-Qy; Thu, 18 Dec 2014 13:00:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1agf-0004Xd-KM
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:00:13 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	A6/2F-29352-CDFC2945; Thu, 18 Dec 2014 13:00:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418907612!9988734!1
X-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 14444 invoked from network); 18 Dec 2014 13:00:12 -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; 18 Dec 2014 13:00:12 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:00:12 +0000
Message-Id: <5492DDEC02000078000509D6@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:00:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-2-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-2-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> 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>

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 Dec 18 13:00:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13: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 1Y1ah2-0004c3-7P; Thu, 18 Dec 2014 13:00: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 1Y1ah0-0004bb-7r
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:00:34 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	5C/FD-03145-1FFC2945; Thu, 18 Dec 2014 13:00:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418907630!15934452!1
X-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 9939 invoked from network); 18 Dec 2014 13:00:30 -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; 18 Dec 2014 13:00:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:00:30 +0000
Message-Id: <5492DDFF02000078000509D9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:00:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> 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>

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 Dec 18 13:00:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13: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 1Y1ah2-0004c3-7P; Thu, 18 Dec 2014 13:00: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 1Y1ah0-0004bb-7r
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:00:34 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	5C/FD-03145-1FFC2945; Thu, 18 Dec 2014 13:00:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418907630!15934452!1
X-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 9939 invoked from network); 18 Dec 2014 13:00:30 -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; 18 Dec 2014 13:00:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:00:30 +0000
Message-Id: <5492DDFF02000078000509D9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:00:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-3-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> 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>

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 Dec 18 13:00:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:00:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ahD-0004fI-LY; Thu, 18 Dec 2014 13:00:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1ahC-0004eh-55
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:00:46 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	00/62-11581-DFFC2945; Thu, 18 Dec 2014 13:00:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418907644!11233820!1
X-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 27526 invoked from network); 18 Dec 2014 13:00:44 -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; 18 Dec 2014 13:00:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:00:44 +0000
Message-Id: <5492DE0B02000078000509DC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:00:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> 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>

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 Dec 18 13:00:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:00:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ahD-0004fI-LY; Thu, 18 Dec 2014 13:00:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1ahC-0004eh-55
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:00:46 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	00/62-11581-DFFC2945; Thu, 18 Dec 2014 13:00:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418907644!11233820!1
X-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 27526 invoked from network); 18 Dec 2014 13:00:44 -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; 18 Dec 2014 13:00:44 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:00:44 +0000
Message-Id: <5492DE0B02000078000509DC@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:00:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-4-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> 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>

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 Dec 18 13:10:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13: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 1Y1aqD-0005UG-Nt; Thu, 18 Dec 2014 13:10:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1aqC-0005UB-HW
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:10:04 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	01/C1-25727-B22D2945; Thu, 18 Dec 2014 13:10:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418908202!14374848!1
X-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 15719 invoked from network); 18 Dec 2014 13:10:03 -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 Dec 2014 13:10:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:10:02 +0000
Message-Id: <5492E03A0200007800050A22@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:10:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-7-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-7-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> @@ -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
> +                );

Please don't copy formatting breakage.

> @@ -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;

Why's that == instead of &. Also you appear to mean this function
to return a boolean value, in which case its return type ought to be
bool_t.

> +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 );

No spaces immediately inside the parentheses please.

>  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;

This just can't be right when !CONFIG_ACPI, but I think I commented
on the naming of such variables/fields already for an earlier version.

> --- 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

This is too generic a name to go without comment.

> --- 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

This might better be done inside xen/acpi.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 Dec 18 13:10:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13: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 1Y1aqD-0005UG-Nt; Thu, 18 Dec 2014 13:10:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1aqC-0005UB-HW
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:10:04 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	01/C1-25727-B22D2945; Thu, 18 Dec 2014 13:10:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418908202!14374848!1
X-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 15719 invoked from network); 18 Dec 2014 13:10:03 -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 Dec 2014 13:10:03 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:10:02 +0000
Message-Id: <5492E03A0200007800050A22@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:10:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-7-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-7-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> @@ -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
> +                );

Please don't copy formatting breakage.

> @@ -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;

Why's that == instead of &. Also you appear to mean this function
to return a boolean value, in which case its return type ought to be
bool_t.

> +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 );

No spaces immediately inside the parentheses please.

>  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;

This just can't be right when !CONFIG_ACPI, but I think I commented
on the naming of such variables/fields already for an earlier version.

> --- 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

This is too generic a name to go without comment.

> --- 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

This might better be done inside xen/acpi.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 Dec 18 13:11:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:11:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1arZ-0005Z9-6l; Thu, 18 Dec 2014 13:11:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1arX-0005Z1-Tw
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:11:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F4/46-25276-F72D2945; Thu, 18 Dec 2014 13:11:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418908286!13070473!1
X-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 26118 invoked from network); 18 Dec 2014 13:11:26 -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; 18 Dec 2014 13:11:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:11:26 +0000
Message-Id: <5492E08F0200007800050A25@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:11:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> Kernel uses this op to start/stop cpufreq notification
> events sending.

This is too little of an explanation for a public interface addition.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:11:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:11:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1arZ-0005Z9-6l; Thu, 18 Dec 2014 13:11:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1arX-0005Z1-Tw
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:11:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F4/46-25276-F72D2945; Thu, 18 Dec 2014 13:11:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1418908286!13070473!1
X-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 26118 invoked from network); 18 Dec 2014 13:11:26 -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; 18 Dec 2014 13:11:26 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:11:26 +0000
Message-Id: <5492E08F0200007800050A25@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:11:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-11-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> Kernel uses this op to start/stop cpufreq notification
> events sending.

This is too little of an explanation for a public interface addition.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:19:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1az5-00067F-4L; Thu, 18 Dec 2014 13:19: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 1Y1az3-00067A-JN
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:19:13 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	56/9F-17694-054D2945; Thu, 18 Dec 2014 13:19:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418908752!14303698!1
X-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 31311 invoked from network); 18 Dec 2014 13:19:12 -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; 18 Dec 2014 13:19:12 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:19:11 +0000
Message-Id: <5492E25F0200007800050A3C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:19:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-12-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-12-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> 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

Without proof that the architecturally more sound model of having
the hypervisor do the hardware manipulation is indeed unusable
I continue to not agree to this going in. I don't think I've seen any
numbers on the claimed slowness when using hypercalls for the
I2C accesses you need multiplexed for this, and the need to
multiplex them in the first place is a sign of a virtualization
unfriendly system design, which I'm not sure we really want/need
to accept a large piece of code to work around.

> --- 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

Unless you strictly need this at the end, this should go ahead of
utility.o. It's also questionable whether under cpufreq/ you need
to name a file *-cpufreq.*.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:19:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1az5-00067F-4L; Thu, 18 Dec 2014 13:19: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 1Y1az3-00067A-JN
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:19:13 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	56/9F-17694-054D2945; Thu, 18 Dec 2014 13:19:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418908752!14303698!1
X-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 31311 invoked from network); 18 Dec 2014 13:19:12 -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; 18 Dec 2014 13:19:12 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:19:11 +0000
Message-Id: <5492E25F0200007800050A3C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:19:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>
References: <1415711834-1740-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
	<1415711834-1740-12-git-send-email-oleksandr.dmytryshyn@globallogic.com>
In-Reply-To: <1415711834-1740-12-git-send-email-oleksandr.dmytryshyn@globallogic.com>
Mime-Version: 1.0
Content-Disposition: inline
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 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>
Content-Type: text/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 14:17, <oleksandr.dmytryshyn@globallogic.com> wrote:
> 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

Without proof that the architecturally more sound model of having
the hypervisor do the hardware manipulation is indeed unusable
I continue to not agree to this going in. I don't think I've seen any
numbers on the claimed slowness when using hypercalls for the
I2C accesses you need multiplexed for this, and the need to
multiplex them in the first place is a sign of a virtualization
unfriendly system design, which I'm not sure we really want/need
to accept a large piece of code to work around.

> --- 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

Unless you strictly need this at the end, this should go ahead of
utility.o. It's also questionable whether under cpufreq/ you need
to name a file *-cpufreq.*.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:23:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13: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 1Y1b30-0006LS-Rn; Thu, 18 Dec 2014 13:23:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1b30-0006LM-26
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:23:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	69/02-15461-545D2945; Thu, 18 Dec 2014 13:23:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418908996!16536558!1
X-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 26274 invoked from network); 18 Dec 2014 13:23:17 -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; 18 Dec 2014 13:23:17 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:23:16 +0000
Message-Id: <5492E3530200007800050A4D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:23:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
	<1418305541-5135-2-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-2-git-send-email-vkuznets@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Jones <drjones@redhat.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v5 1/9] xen: introduce DOMDYING_locked 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 11.12.14 at 14:45, <vkuznets@redhat.com> wrote:
> New dying state is requred to indicate that a particular domain
> is dying but cleanup procedure wasn't started. This state can be
> set from outside of domain_kill().

Without any user of the new state (yet), please be more verbose
here to explain what the intended use is (also allowing to
understand the naming choice).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:23:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13: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 1Y1b30-0006LS-Rn; Thu, 18 Dec 2014 13:23:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1b30-0006LM-26
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:23:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	69/02-15461-545D2945; Thu, 18 Dec 2014 13:23:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418908996!16536558!1
X-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 26274 invoked from network); 18 Dec 2014 13:23:17 -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; 18 Dec 2014 13:23:17 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:23:16 +0000
Message-Id: <5492E3530200007800050A4D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:23:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
	<1418305541-5135-2-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-2-git-send-email-vkuznets@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Jones <drjones@redhat.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v5 1/9] xen: introduce DOMDYING_locked 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 11.12.14 at 14:45, <vkuznets@redhat.com> wrote:
> New dying state is requred to indicate that a particular domain
> is dying but cleanup procedure wasn't started. This state can be
> set from outside of domain_kill().

Without any user of the new state (yet), please be more verbose
here to explain what the intended use is (also allowing to
understand the naming choice).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:28:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13: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 1Y1b7m-0006lM-J4; Thu, 18 Dec 2014 13:28:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1b7l-0006lH-2m
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:28:13 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	4C/DA-25714-C66D2945; Thu, 18 Dec 2014 13:28:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418909288!14112709!1
X-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 12721 invoked from network); 18 Dec 2014 13:28:11 -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; 18 Dec 2014 13:28:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:28:08 +0000
Message-Id: <5492E4780200007800050A64@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:28:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
	<1418305541-5135-3-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-3-git-send-email-vkuznets@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Jones <drjones@redhat.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v5 2/9] xen: introduce SHUTDOWN_soft_reset
 shutdown reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.14 at 14:45, <vkuznets@redhat.com> wrote:
> --- a/xen/common/shutdown.c
> +++ b/xen/common/shutdown.c
> @@ -71,6 +71,13 @@ void hwdom_shutdown(u8 reason)
>          break; /* not reached */
>      }
>  
> +    case SHUTDOWN_soft_reset:
> +    {
> +        printk("Domain 0 did soft reset but it is unsupported, rebooting.\n");

Please shorten the message by e.g. dropping "did" and "but it is",
and please also don't add pointless braces around this code (no
matter that other code above/below does so - actually the whole
function could use an overhaul, dropping these braces and
replacing the mention of "Domain 0" with either "Hardware domain"
or "Dom%d" using hwdom's correct ID).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:28:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13: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 1Y1b7m-0006lM-J4; Thu, 18 Dec 2014 13:28:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1b7l-0006lH-2m
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:28:13 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	4C/DA-25714-C66D2945; Thu, 18 Dec 2014 13:28:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418909288!14112709!1
X-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 12721 invoked from network); 18 Dec 2014 13:28:11 -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; 18 Dec 2014 13:28:11 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:28:08 +0000
Message-Id: <5492E4780200007800050A64@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:28:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
	<1418305541-5135-3-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-3-git-send-email-vkuznets@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Jones <drjones@redhat.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v5 2/9] xen: introduce SHUTDOWN_soft_reset
 shutdown reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.14 at 14:45, <vkuznets@redhat.com> wrote:
> --- a/xen/common/shutdown.c
> +++ b/xen/common/shutdown.c
> @@ -71,6 +71,13 @@ void hwdom_shutdown(u8 reason)
>          break; /* not reached */
>      }
>  
> +    case SHUTDOWN_soft_reset:
> +    {
> +        printk("Domain 0 did soft reset but it is unsupported, rebooting.\n");

Please shorten the message by e.g. dropping "did" and "but it is",
and please also don't add pointless braces around this code (no
matter that other code above/below does so - actually the whole
function could use an overhaul, dropping these braces and
replacing the mention of "Domain 0" with either "Hardware domain"
or "Dom%d" using hwdom's correct ID).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:39:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:39:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1bIE-0007GU-EY; Thu, 18 Dec 2014 13:39:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Y1bIB-0007GO-U7
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:39:00 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	EB/1F-26652-3F8D2945; Thu, 18 Dec 2014 13:38:59 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418909937!14143987!1
X-Originating-IP: [74.125.82.49]
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 17019 invoked from network); 18 Dec 2014 13:38:57 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 13:38:57 -0000
Received: by mail-wg0-f49.google.com with SMTP id n12so1645533wgh.22
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 05:38:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=B9r9sF5Zr3Uns8DquO0tGWgzk0jCbPuNXitKe7KGYcE=;
	b=ADrcHm0FofRVNQ8pTsCwHwcUrxNZjjLjiVCFIvhw5SO/wK++dbRzKJjD8SIQ0xM33U
	kDGZkHYlrupvFbaz3bJQ6OugeIoMTAo3L9y1BpUgdR1unAeMNoTbTqR/0aGK7X0ut6qZ
	sr9jjMhRECOiZLLgNRxLXEsbTcml3Zsyh8qIsg9arauUcqrsWv0p+vFss2OHxhuchdEp
	cMnB43Atz3/83FbhWFzjtRh2+zcH97dh7Ca914dHin93Z7EJx9sdlohhcFaJ+AVUBoAb
	TodUcfZDnb6KR32ewwPt3Q5sbvx/smVxLyrOaiHIGhFvrf995BcVU+55w80CZZB7iIal
	7Hug==
X-Received: by 10.180.81.7 with SMTP id v7mr5267547wix.74.1418909937266;
	Thu, 18 Dec 2014 05:38:57 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103]) by mx.google.com with ESMTPSA id
	mo12sm8982371wjc.35.2014.12.18.05.38.55
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 05:38:56 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 18 Dec 2014 14:38:54 +0100
Message-ID: <20141218133854.29909.50574.stgit@Abyss.station>
In-Reply-To: <20141218130919.29909.13566.stgit@Abyss.station>
References: <20141218130919.29909.13566.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 1/2] ts-cpupools: new test 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

for smoke testing cpupools a bit. It tries to partition
a live host in two cpupools, trying out the following 3
schedulers for the new cpupool (one after the other):
 credit, credit2 and RTDS.

It also tries to migrating a domain to the new cpupool
and then back to Pool-0.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
---
 ts-cpupools |  124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 124 insertions(+)
 create mode 100755 ts-cpupools

diff --git a/ts-cpupools b/ts-cpupools
new file mode 100755
index 0000000..fe612e1
--- /dev/null
+++ b/ts-cpupools
@@ -0,0 +1,124 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost,$gn)= @ARGV;
+$whhost ||= 'host';
+$gn ||= 'debian';
+
+our ($ho,$gho) = ts_get_host_guest($whhost,$gn);
+#our $ho= selecthost(@ARGV);
+
+our $default_cpupool= "Pool-0";
+our @schedulers= ("credit","credit2","rtds");
+our @cpulist;
+our $nr_cpus;
+
+sub check () {
+  my $out;
+
+  # Figure out the number of pCPUs of the host. We need to know
+  # that in order to decide with what pCPUs we want to create
+  # cpupools
+  my $xlinfo= target_cmd_output_root($ho, "xl info");
+  $xlinfo =~ /nr_cpus\s*:\s([0-9]*)/;
+  $nr_cpus= $1;
+  logm("Found $nr_cpus pCPUs");
+  die "Too few pCPUs to test cpupools: $nr_cpus" if $nr_cpus < 2;
+
+  # We want only 1 cpupool to exist
+  my $cppinfo= target_cmd_output_root($ho, "xl cpupool-list");
+  my $nr_cpupools= $cppinfo =~ tr/\n//;
+  logm("Found $nr_cpupools cpupools");
+  die "There already is more than one cpu pool!" if $nr_cpupools > 1;
+  die "Non-default cpupool configuration detected" if $cppinfo =~ /^$default_cpupool\b/;
+
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+}
+
+# List of the odd pCPUs
+sub prep_cpulist () {
+  if (! defined @cpulist) {
+    foreach my $cpu (0..$nr_cpus) {
+      next unless $cpu % 2;
+      push @cpulist, $cpu;
+    }
+  }
+}
+
+sub prep ($) {
+  my ($sched)= @_;
+
+  # Remove the pCPUs from in $cpulist from the default cpupool
+  my $cpustr= "[";
+  foreach my $cpu (@cpulist) {
+    target_cmd_root($ho,"xl cpupool-cpu-remove $default_cpupool $cpu");
+    $cpustr.= "\"$cpu\", ";
+  }
+  $cpustr.= "]";
+
+  logm("Creating config file for cpupool-osstest-$sched with cpus=$cpustr");
+  target_putfilecontents_stash($ho,100,<<"END","/etc/xen/cpupool-osstest-$sched");
+name = "cpupool-osstest-$sched"
+sched=\"$sched\"
+cpus=$cpustr
+END
+}
+
+check();
+prep_cpulist();
+foreach my $sched (@schedulers) {
+  my $out;
+
+  prep("$sched");
+
+  # For each cpupool:
+  #  * create it
+  #  * rename it
+  #  * move a domain in it
+  #  * move back a domain out of it
+  #  * add back the pcpus from it to the default pool
+  #  * destroy it
+  target_cmd_root($ho, "xl cpupool-create /etc/xen/cpupool-osstest-$sched");
+  target_cmd_output_root($ho, "xl cpupool-rename cpupool-osstest-$sched cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl vcpu-list"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} Pool-0");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+
+  foreach my $cpu (@cpulist) {
+    target_cmd_root($ho,"xl cpupool-cpu-remove cpupool-test $cpu");
+    target_cmd_root($ho,"xl cpupool-cpu-add $default_cpupool $cpu");
+  }
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-destroy cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+}
+


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:39:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:39:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1bI4-0007G8-MY; Thu, 18 Dec 2014 13:38:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Y1bI3-0007G3-3w
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:38:51 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	2D/91-05632-AE8D2945; Thu, 18 Dec 2014 13:38:50 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418909929!14275408!1
X-Originating-IP: [74.125.82.52]
X-SpamReason: No, hits=0.2 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	RCVD_ILLEGAL_IP,spamassassin: ,surbl: (ASYNC_NO) 
	c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRvbmVkOiBhYm91dC5tZS9kYXJpby5mYWdna
	W9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14360 invoked from network); 18 Dec 2014 13:38:49 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 13:38:49 -0000
Received: by mail-wg0-f52.google.com with SMTP id x12so1647044wgg.11
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 05:38:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:user-agent:mime-version
	:content-type:content-transfer-encoding;
	bh=koZtTIEWinF7v/wmMlkcMpjcvW5RQuMk1suURjkiJWY=;
	b=xQ4iLcHpnm5Pv/H0pbGLvuqp7q/10kDSe9ghRQ0v2eOdhpW0TpFDfxITDUSWYNGm6d
	r8/FVN3B7w3RweF8mYJ261AC1XTFfyEOkx+rSp+WfvJSuRd8YHFuUEQiyKb3e4rRF8iz
	cvO7VYMlOCya7pLNvFDFRMqoaqh0R4iOBwT5rG/IDG5TBLrYiyTTLHoptZ+q+NH7I6Gp
	Hrhl8vxO3z2tnOeAUaPLQsyQNE6uknSxq7G+KnOiiQZb7EIJ+Uo2Z4uQKd66VsatPmZ8
	5680S2hxcUn5I//ps4TGWl5Es6skUdZhHT2jsbGcffHLjr/6MelmZDVYKZcV516zCWMM
	CVBA==
X-Received: by 10.194.61.168 with SMTP id q8mr4392860wjr.53.1418909929009;
	Thu, 18 Dec 2014 05:38:49 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id j1sm8990502wjw.25.2014.12.18.05.38.46
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 05:38:47 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 18 Dec 2014 14:38:45 +0100
Message-ID: <20141218130919.29909.13566.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 0/2] Test case for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Just the fact that we are not doing anything to smoke test cpupools, while I
think we should. :-)

This add something quite basic, but it's, IMO, already representative one
typically does with cpupools. We can add more pCPU related tricks (removing,
adding, etc), or we can add more domains and move them around more, of course.
If anyone has any suggestion about operations that should really be part of
Osstest's runs, let me know and I'll include them.

As it is right now, the test is super quick, to the point that I considered
whether it wouldn't have been better to add some similar cpupool operations in
one of the existing jobs. I ended up deciding for having a separate job,
because this is, after all, a rather specific operation, and a different enough
thing from basic VM lifecycle, so I think it deserves its own job.

Thanks and Regards, Dario

---

Dario Faggioli (2):
      ts-cpupools: new test script
      Testing cpupools: recipe for it and job definition


 make-flight |   11 +++++
 sg-run-job  |    6 +++
 ts-cpupools |  124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 141 insertions(+)
 create mode 100755 ts-cpupools

--
<<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 Thu Dec 18 13:39:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:39:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1bIL-0007IL-11; Thu, 18 Dec 2014 13:39:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Y1bIJ-0007Hn-6e
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:39:07 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	5F/C6-08051-AF8D2945; Thu, 18 Dec 2014 13:39:06 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418909945!10511361!1
X-Originating-IP: [209.85.212.174]
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 7462 invoked from network); 18 Dec 2014 13:39:05 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 13:39:05 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so1812641wiw.1
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 05:39:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=xOZOHvH1pc7VNAHBK04avJEv5UY0QfyOy0CTWMjEMcI=;
	b=jT26nDT3+IWLfR39cyOtp2BlbhtlsF2aOjhmQBmU0TMcDvU99+7BLPL/AXUgrmU1e1
	Y03ZzBG5KTngRe64OBSwJCpKYB9bbAT+M/Cre0ExwSo4Rpn10q63BhjRhEn9Lgiw3rXc
	2zg2cP1B7jq83qNAaJ3tDNSKW2UwQtCqJLlcbjmW+faAEwiKY8N7n2Bxfm11Y/B8Jmu1
	qxEHS4EGEmAEdcGutJ0DBsTCWWS9gEM7QkGlivI9M7UVlj0K/CvP6vVlzew078BeBI6V
	Vgb89nJUOLKTtfjgBWsWCX4OHftjGczcUpdsezc8CBxD769DxdhNtN4SDcxcKjwArJ8e
	OiXA==
X-Received: by 10.194.200.234 with SMTP id jv10mr4609997wjc.110.1418909945543; 
	Thu, 18 Dec 2014 05:39:05 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id cp4sm9000268wjb.16.2014.12.18.05.39.03
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 05:39:04 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 18 Dec 2014 14:39:02 +0100
Message-ID: <20141218133902.29909.99057.stgit@Abyss.station>
In-Reply-To: <20141218130919.29909.13566.stgit@Abyss.station>
References: <20141218130919.29909.13566.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and
 job 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

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
---
 make-flight |   11 +++++++++++
 sg-run-job  |    6 ++++++
 2 files changed, 17 insertions(+)

diff --git a/make-flight b/make-flight
index a91f256..ce02c89 100755
--- a/make-flight
+++ b/make-flight
@@ -266,6 +266,16 @@ do_credit2_tests () {
             $debian_runvars all_hostflags=$most_hostflags
 }
 
+do_cpupools_tests () {
+  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
+    return
+  fi
+
+  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools            \
+       test-cpupools xl $xenarch $dom0arch                            \
+            $debian_runvars all_hostflags=$most_hostflags
+}
+
 do_passthrough_tests () {
   if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
     return
@@ -366,6 +376,7 @@ test_matrix_do_one () {
 
   do_sedf_tests
   do_credit2_tests
+  do_cpupools_tests
 
   if [ $xenarch = amd64 -a $dom0arch = i386 ]; then
 
diff --git a/sg-run-job b/sg-run-job
index 2cf810a..0250087 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -272,6 +272,12 @@ proc run-job/test-debianhvm {} {
     test-guest debianhvm
 }
 
+proc need-hosts/test-cpupools {} { return host }
+proc run-job/test-cpupools {} {
+    install-guest-debian
+    run-ts . = ts-cpupools
+}
+
 proc need-hosts/test-pair {} { return {src_host dst_host} }
 proc run-job/test-pair {} {
     run-ts . =              ts-debian-install      dst_host


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:39:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:39:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1bIE-0007GU-EY; Thu, 18 Dec 2014 13:39:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Y1bIB-0007GO-U7
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:39:00 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	EB/1F-26652-3F8D2945; Thu, 18 Dec 2014 13:38:59 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418909937!14143987!1
X-Originating-IP: [74.125.82.49]
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 17019 invoked from network); 18 Dec 2014 13:38:57 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 13:38:57 -0000
Received: by mail-wg0-f49.google.com with SMTP id n12so1645533wgh.22
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 05:38:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=B9r9sF5Zr3Uns8DquO0tGWgzk0jCbPuNXitKe7KGYcE=;
	b=ADrcHm0FofRVNQ8pTsCwHwcUrxNZjjLjiVCFIvhw5SO/wK++dbRzKJjD8SIQ0xM33U
	kDGZkHYlrupvFbaz3bJQ6OugeIoMTAo3L9y1BpUgdR1unAeMNoTbTqR/0aGK7X0ut6qZ
	sr9jjMhRECOiZLLgNRxLXEsbTcml3Zsyh8qIsg9arauUcqrsWv0p+vFss2OHxhuchdEp
	cMnB43Atz3/83FbhWFzjtRh2+zcH97dh7Ca914dHin93Z7EJx9sdlohhcFaJ+AVUBoAb
	TodUcfZDnb6KR32ewwPt3Q5sbvx/smVxLyrOaiHIGhFvrf995BcVU+55w80CZZB7iIal
	7Hug==
X-Received: by 10.180.81.7 with SMTP id v7mr5267547wix.74.1418909937266;
	Thu, 18 Dec 2014 05:38:57 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103]) by mx.google.com with ESMTPSA id
	mo12sm8982371wjc.35.2014.12.18.05.38.55
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 05:38:56 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 18 Dec 2014 14:38:54 +0100
Message-ID: <20141218133854.29909.50574.stgit@Abyss.station>
In-Reply-To: <20141218130919.29909.13566.stgit@Abyss.station>
References: <20141218130919.29909.13566.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 1/2] ts-cpupools: new test 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

for smoke testing cpupools a bit. It tries to partition
a live host in two cpupools, trying out the following 3
schedulers for the new cpupool (one after the other):
 credit, credit2 and RTDS.

It also tries to migrating a domain to the new cpupool
and then back to Pool-0.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
---
 ts-cpupools |  124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 124 insertions(+)
 create mode 100755 ts-cpupools

diff --git a/ts-cpupools b/ts-cpupools
new file mode 100755
index 0000000..fe612e1
--- /dev/null
+++ b/ts-cpupools
@@ -0,0 +1,124 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-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/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost,$gn)= @ARGV;
+$whhost ||= 'host';
+$gn ||= 'debian';
+
+our ($ho,$gho) = ts_get_host_guest($whhost,$gn);
+#our $ho= selecthost(@ARGV);
+
+our $default_cpupool= "Pool-0";
+our @schedulers= ("credit","credit2","rtds");
+our @cpulist;
+our $nr_cpus;
+
+sub check () {
+  my $out;
+
+  # Figure out the number of pCPUs of the host. We need to know
+  # that in order to decide with what pCPUs we want to create
+  # cpupools
+  my $xlinfo= target_cmd_output_root($ho, "xl info");
+  $xlinfo =~ /nr_cpus\s*:\s([0-9]*)/;
+  $nr_cpus= $1;
+  logm("Found $nr_cpus pCPUs");
+  die "Too few pCPUs to test cpupools: $nr_cpus" if $nr_cpus < 2;
+
+  # We want only 1 cpupool to exist
+  my $cppinfo= target_cmd_output_root($ho, "xl cpupool-list");
+  my $nr_cpupools= $cppinfo =~ tr/\n//;
+  logm("Found $nr_cpupools cpupools");
+  die "There already is more than one cpu pool!" if $nr_cpupools > 1;
+  die "Non-default cpupool configuration detected" if $cppinfo =~ /^$default_cpupool\b/;
+
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+}
+
+# List of the odd pCPUs
+sub prep_cpulist () {
+  if (! defined @cpulist) {
+    foreach my $cpu (0..$nr_cpus) {
+      next unless $cpu % 2;
+      push @cpulist, $cpu;
+    }
+  }
+}
+
+sub prep ($) {
+  my ($sched)= @_;
+
+  # Remove the pCPUs from in $cpulist from the default cpupool
+  my $cpustr= "[";
+  foreach my $cpu (@cpulist) {
+    target_cmd_root($ho,"xl cpupool-cpu-remove $default_cpupool $cpu");
+    $cpustr.= "\"$cpu\", ";
+  }
+  $cpustr.= "]";
+
+  logm("Creating config file for cpupool-osstest-$sched with cpus=$cpustr");
+  target_putfilecontents_stash($ho,100,<<"END","/etc/xen/cpupool-osstest-$sched");
+name = "cpupool-osstest-$sched"
+sched=\"$sched\"
+cpus=$cpustr
+END
+}
+
+check();
+prep_cpulist();
+foreach my $sched (@schedulers) {
+  my $out;
+
+  prep("$sched");
+
+  # For each cpupool:
+  #  * create it
+  #  * rename it
+  #  * move a domain in it
+  #  * move back a domain out of it
+  #  * add back the pcpus from it to the default pool
+  #  * destroy it
+  target_cmd_root($ho, "xl cpupool-create /etc/xen/cpupool-osstest-$sched");
+  target_cmd_output_root($ho, "xl cpupool-rename cpupool-osstest-$sched cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl vcpu-list"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} Pool-0");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+
+  foreach my $cpu (@cpulist) {
+    target_cmd_root($ho,"xl cpupool-cpu-remove cpupool-test $cpu");
+    target_cmd_root($ho,"xl cpupool-cpu-add $default_cpupool $cpu");
+  }
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-destroy cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+}
+


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:39:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:39:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1bI4-0007G8-MY; Thu, 18 Dec 2014 13:38:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Y1bI3-0007G3-3w
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:38:51 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	2D/91-05632-AE8D2945; Thu, 18 Dec 2014 13:38:50 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418909929!14275408!1
X-Originating-IP: [74.125.82.52]
X-SpamReason: No, hits=0.2 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	RCVD_ILLEGAL_IP,spamassassin: ,surbl: (ASYNC_NO) 
	c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRvbmVkOiBhYm91dC5tZS9kYXJpby5mYWdna
	W9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14360 invoked from network); 18 Dec 2014 13:38:49 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 13:38:49 -0000
Received: by mail-wg0-f52.google.com with SMTP id x12so1647044wgg.11
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 05:38:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:user-agent:mime-version
	:content-type:content-transfer-encoding;
	bh=koZtTIEWinF7v/wmMlkcMpjcvW5RQuMk1suURjkiJWY=;
	b=xQ4iLcHpnm5Pv/H0pbGLvuqp7q/10kDSe9ghRQ0v2eOdhpW0TpFDfxITDUSWYNGm6d
	r8/FVN3B7w3RweF8mYJ261AC1XTFfyEOkx+rSp+WfvJSuRd8YHFuUEQiyKb3e4rRF8iz
	cvO7VYMlOCya7pLNvFDFRMqoaqh0R4iOBwT5rG/IDG5TBLrYiyTTLHoptZ+q+NH7I6Gp
	Hrhl8vxO3z2tnOeAUaPLQsyQNE6uknSxq7G+KnOiiQZb7EIJ+Uo2Z4uQKd66VsatPmZ8
	5680S2hxcUn5I//ps4TGWl5Es6skUdZhHT2jsbGcffHLjr/6MelmZDVYKZcV516zCWMM
	CVBA==
X-Received: by 10.194.61.168 with SMTP id q8mr4392860wjr.53.1418909929009;
	Thu, 18 Dec 2014 05:38:49 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id j1sm8990502wjw.25.2014.12.18.05.38.46
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 05:38:47 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 18 Dec 2014 14:38:45 +0100
Message-ID: <20141218130919.29909.13566.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 0/2] Test case for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Just the fact that we are not doing anything to smoke test cpupools, while I
think we should. :-)

This add something quite basic, but it's, IMO, already representative one
typically does with cpupools. We can add more pCPU related tricks (removing,
adding, etc), or we can add more domains and move them around more, of course.
If anyone has any suggestion about operations that should really be part of
Osstest's runs, let me know and I'll include them.

As it is right now, the test is super quick, to the point that I considered
whether it wouldn't have been better to add some similar cpupool operations in
one of the existing jobs. I ended up deciding for having a separate job,
because this is, after all, a rather specific operation, and a different enough
thing from basic VM lifecycle, so I think it deserves its own job.

Thanks and Regards, Dario

---

Dario Faggioli (2):
      ts-cpupools: new test script
      Testing cpupools: recipe for it and job definition


 make-flight |   11 +++++
 sg-run-job  |    6 +++
 ts-cpupools |  124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 141 insertions(+)
 create mode 100755 ts-cpupools

--
<<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 Thu Dec 18 13:39:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:39:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1bIL-0007IL-11; Thu, 18 Dec 2014 13:39:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Y1bIJ-0007Hn-6e
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:39:07 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	5F/C6-08051-AF8D2945; Thu, 18 Dec 2014 13:39:06 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1418909945!10511361!1
X-Originating-IP: [209.85.212.174]
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 7462 invoked from network); 18 Dec 2014 13:39:05 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 13:39:05 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so1812641wiw.1
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 05:39:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:subject:from:to:cc:date:message-id:in-reply-to:references
	:user-agent:mime-version:content-type:content-transfer-encoding;
	bh=xOZOHvH1pc7VNAHBK04avJEv5UY0QfyOy0CTWMjEMcI=;
	b=jT26nDT3+IWLfR39cyOtp2BlbhtlsF2aOjhmQBmU0TMcDvU99+7BLPL/AXUgrmU1e1
	Y03ZzBG5KTngRe64OBSwJCpKYB9bbAT+M/Cre0ExwSo4Rpn10q63BhjRhEn9Lgiw3rXc
	2zg2cP1B7jq83qNAaJ3tDNSKW2UwQtCqJLlcbjmW+faAEwiKY8N7n2Bxfm11Y/B8Jmu1
	qxEHS4EGEmAEdcGutJ0DBsTCWWS9gEM7QkGlivI9M7UVlj0K/CvP6vVlzew078BeBI6V
	Vgb89nJUOLKTtfjgBWsWCX4OHftjGczcUpdsezc8CBxD769DxdhNtN4SDcxcKjwArJ8e
	OiXA==
X-Received: by 10.194.200.234 with SMTP id jv10mr4609997wjc.110.1418909945543; 
	Thu, 18 Dec 2014 05:39:05 -0800 (PST)
Received: from Abyss.station (net-2-39-70-103.cust.vodafonedsl.it.
	[2.39.70.103])
	by mx.google.com with ESMTPSA id cp4sm9000268wjb.16.2014.12.18.05.39.03
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 05:39:04 -0800 (PST)
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Date: Thu, 18 Dec 2014 14:39:02 +0100
Message-ID: <20141218133902.29909.99057.stgit@Abyss.station>
In-Reply-To: <20141218130919.29909.13566.stgit@Abyss.station>
References: <20141218130919.29909.13566.stgit@Abyss.station>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and
 job 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

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
---
 make-flight |   11 +++++++++++
 sg-run-job  |    6 ++++++
 2 files changed, 17 insertions(+)

diff --git a/make-flight b/make-flight
index a91f256..ce02c89 100755
--- a/make-flight
+++ b/make-flight
@@ -266,6 +266,16 @@ do_credit2_tests () {
             $debian_runvars all_hostflags=$most_hostflags
 }
 
+do_cpupools_tests () {
+  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
+    return
+  fi
+
+  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools            \
+       test-cpupools xl $xenarch $dom0arch                            \
+            $debian_runvars all_hostflags=$most_hostflags
+}
+
 do_passthrough_tests () {
   if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
     return
@@ -366,6 +376,7 @@ test_matrix_do_one () {
 
   do_sedf_tests
   do_credit2_tests
+  do_cpupools_tests
 
   if [ $xenarch = amd64 -a $dom0arch = i386 ]; then
 
diff --git a/sg-run-job b/sg-run-job
index 2cf810a..0250087 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -272,6 +272,12 @@ proc run-job/test-debianhvm {} {
     test-guest debianhvm
 }
 
+proc need-hosts/test-cpupools {} { return host }
+proc run-job/test-cpupools {} {
+    install-guest-debian
+    run-ts . = ts-cpupools
+}
+
 proc need-hosts/test-pair {} { return {src_host dst_host} }
 proc run-job/test-pair {} {
     run-ts . =              ts-debian-install      dst_host


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:44:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13: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 1Y1bNN-00085H-V7; Thu, 18 Dec 2014 13:44:21 +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 1Y1bNM-00085C-PZ
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:44:21 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	2A/C0-16982-33AD2945; Thu, 18 Dec 2014 13:44:19 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418910256!14336348!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22363 invoked from network); 18 Dec 2014 13:44:18 -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;
	18 Dec 2014 13:44:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; 
	d="asc'?scan'208";a="205779266"
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.210.2;
	Thu, 18 Dec 2014 08:44:15 -0500
Message-ID: <1418910253.10854.2.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 18 Dec 2014 14:44:13 +0100
In-Reply-To: <20141218130919.29909.13566.stgit@Abyss.station>
References: <20141218130919.29909.13566.stgit@Abyss.station>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [Xen-devel] [OSSTEST PATCH 0/2] Test case for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1747154549257282636=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1747154549257282636==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-k2saxISe9q19AVzck7qW"

--=-k2saxISe9q19AVzck7qW
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-12-18 at 14:38 +0100, Dario Faggioli wrote:
> Just the fact that we are not doing anything to smoke test cpupools, whil=
e I
> think we should. :-)
>=20
> This add something quite basic, but it's, IMO, already representative one
> typically does with cpupools. We can add more pCPU related tricks (removi=
ng,
> adding, etc), or we can add more domains and move them around more, of co=
urse.
> If anyone has any suggestion about operations that should really be part =
of
> Osstest's runs, let me know and I'll include them.
>=20
> As it is right now, the test is super quick, to the point that I consider=
ed
> whether it wouldn't have been better to add some similar cpupool operatio=
ns in
> one of the existing jobs. I ended up deciding for having a separate job,
> because this is, after all, a rather specific operation, and a different =
enough
> thing from basic VM lifecycle, so I think it deserves its own job.
>=20
And I forgot to say that I of course tested it, in standalone mode, like
this:

 $ ./standalone run-job -h ultralisk test-amd64-amd64-xl-cpupools

Here's also the runvars for the new job (really nothing special):

 test-amd64-amd64-xl-cpupools              all_hostflags               arch=
-amd64,arch-xen-amd64,suite-wheezy,purpose-test                            =
=20
 test-amd64-amd64-xl-cpupools              arch                        amd6=
4                                                                          =
=20
 test-amd64-amd64-xl-cpupools              buildjob                    buil=
d-amd64                                                                    =
=20
 test-amd64-amd64-xl-cpupools              console                     hvc0=
                                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_arch                 amd6=
4                                                                          =
=20
 test-amd64-amd64-xl-cpupools              debian_boot_timeout         40  =
                                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_cfgpath              /etc=
/xen/debian.guest.osstest.cfg                                              =
=20
 test-amd64-amd64-xl-cpupools              debian_console              hvc0=
                                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_disk_lv              debi=
an.guest.osstest-disk                                                      =
=20
 test-amd64-amd64-xl-cpupools              debian_domname              debi=
an.guest.osstest                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_ether                5e:3=
6:06:68:00:01                                                              =
=20
 test-amd64-amd64-xl-cpupools              debian_hostname             debi=
an.guest.osstest                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_kernkind             pvop=
s                                                                          =
=20
 test-amd64-amd64-xl-cpupools              debian_rootdev              xvda=
                                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_swap_lv              debi=
an.guest.osstest-swap                                                      =
=20
 test-amd64-amd64-xl-cpupools              debian_tcpcheckport         22  =
                                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_vg                   ultr=
alisk                                                                      =
=20
 test-amd64-amd64-xl-cpupools              host                        ultr=
alisk                                                                      =
=20
 test-amd64-amd64-xl-cpupools              kernbuildjob                buil=
d-amd64-pvops                                                              =
=20
 test-amd64-amd64-xl-cpupools              kernkind                    pvop=
s                                                                          =
=20
 test-amd64-amd64-xl-cpupools              toolstack                   xl  =
                                                                           =
=20
 test-amd64-amd64-xl-cpupools              xen_kernel_path             /boo=
t/vmlinuz-3.18.0-rc4                                                       =
=20
 test-amd64-amd64-xl-cpupools              xen_kernel_ver              3.18=
.0-rc4                                                                     =
=20
 test-amd64-amd64-xl-cpupools              xenbuildjob                 buil=
d-amd64

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)


--=-k2saxISe9q19AVzck7qW
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

iEYEABECAAYFAlSS2i4ACgkQk4XaBE3IOsS3ngCgjlnhRcBk0Ts61DYzGmpovJh8
JaUAnA//sc/Hkb8NoI/ex3kk6uMPi0o6
=BkEB
-----END PGP SIGNATURE-----

--=-k2saxISe9q19AVzck7qW--


--===============1747154549257282636==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1747154549257282636==--


From xen-devel-bounces@lists.xen.org Thu Dec 18 13:44:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13: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 1Y1bNN-00085H-V7; Thu, 18 Dec 2014 13:44:21 +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 1Y1bNM-00085C-PZ
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 13:44:21 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	2A/C0-16982-33AD2945; Thu, 18 Dec 2014 13:44:19 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418910256!14336348!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22363 invoked from network); 18 Dec 2014 13:44:18 -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;
	18 Dec 2014 13:44:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; 
	d="asc'?scan'208";a="205779266"
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.210.2;
	Thu, 18 Dec 2014 08:44:15 -0500
Message-ID: <1418910253.10854.2.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 18 Dec 2014 14:44:13 +0100
In-Reply-To: <20141218130919.29909.13566.stgit@Abyss.station>
References: <20141218130919.29909.13566.stgit@Abyss.station>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [Xen-devel] [OSSTEST PATCH 0/2] Test case for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1747154549257282636=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1747154549257282636==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-k2saxISe9q19AVzck7qW"

--=-k2saxISe9q19AVzck7qW
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-12-18 at 14:38 +0100, Dario Faggioli wrote:
> Just the fact that we are not doing anything to smoke test cpupools, whil=
e I
> think we should. :-)
>=20
> This add something quite basic, but it's, IMO, already representative one
> typically does with cpupools. We can add more pCPU related tricks (removi=
ng,
> adding, etc), or we can add more domains and move them around more, of co=
urse.
> If anyone has any suggestion about operations that should really be part =
of
> Osstest's runs, let me know and I'll include them.
>=20
> As it is right now, the test is super quick, to the point that I consider=
ed
> whether it wouldn't have been better to add some similar cpupool operatio=
ns in
> one of the existing jobs. I ended up deciding for having a separate job,
> because this is, after all, a rather specific operation, and a different =
enough
> thing from basic VM lifecycle, so I think it deserves its own job.
>=20
And I forgot to say that I of course tested it, in standalone mode, like
this:

 $ ./standalone run-job -h ultralisk test-amd64-amd64-xl-cpupools

Here's also the runvars for the new job (really nothing special):

 test-amd64-amd64-xl-cpupools              all_hostflags               arch=
-amd64,arch-xen-amd64,suite-wheezy,purpose-test                            =
=20
 test-amd64-amd64-xl-cpupools              arch                        amd6=
4                                                                          =
=20
 test-amd64-amd64-xl-cpupools              buildjob                    buil=
d-amd64                                                                    =
=20
 test-amd64-amd64-xl-cpupools              console                     hvc0=
                                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_arch                 amd6=
4                                                                          =
=20
 test-amd64-amd64-xl-cpupools              debian_boot_timeout         40  =
                                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_cfgpath              /etc=
/xen/debian.guest.osstest.cfg                                              =
=20
 test-amd64-amd64-xl-cpupools              debian_console              hvc0=
                                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_disk_lv              debi=
an.guest.osstest-disk                                                      =
=20
 test-amd64-amd64-xl-cpupools              debian_domname              debi=
an.guest.osstest                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_ether                5e:3=
6:06:68:00:01                                                              =
=20
 test-amd64-amd64-xl-cpupools              debian_hostname             debi=
an.guest.osstest                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_kernkind             pvop=
s                                                                          =
=20
 test-amd64-amd64-xl-cpupools              debian_rootdev              xvda=
                                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_swap_lv              debi=
an.guest.osstest-swap                                                      =
=20
 test-amd64-amd64-xl-cpupools              debian_tcpcheckport         22  =
                                                                           =
=20
 test-amd64-amd64-xl-cpupools              debian_vg                   ultr=
alisk                                                                      =
=20
 test-amd64-amd64-xl-cpupools              host                        ultr=
alisk                                                                      =
=20
 test-amd64-amd64-xl-cpupools              kernbuildjob                buil=
d-amd64-pvops                                                              =
=20
 test-amd64-amd64-xl-cpupools              kernkind                    pvop=
s                                                                          =
=20
 test-amd64-amd64-xl-cpupools              toolstack                   xl  =
                                                                           =
=20
 test-amd64-amd64-xl-cpupools              xen_kernel_path             /boo=
t/vmlinuz-3.18.0-rc4                                                       =
=20
 test-amd64-amd64-xl-cpupools              xen_kernel_ver              3.18=
.0-rc4                                                                     =
=20
 test-amd64-amd64-xl-cpupools              xenbuildjob                 buil=
d-amd64

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)


--=-k2saxISe9q19AVzck7qW
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

iEYEABECAAYFAlSS2i4ACgkQk4XaBE3IOsS3ngCgjlnhRcBk0Ts61DYzGmpovJh8
JaUAnA//sc/Hkb8NoI/ex3kk6uMPi0o6
=BkEB
-----END PGP SIGNATURE-----

--=-k2saxISe9q19AVzck7qW--


--===============1747154549257282636==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1747154549257282636==--


From xen-devel-bounces@lists.xen.org Thu Dec 18 13:58:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:58:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1baR-0000Af-DR; Thu, 18 Dec 2014 13:57: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 1Y1baQ-0000AY-6W
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:57:50 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	F2/D2-27584-D5DD2945; Thu, 18 Dec 2014 13:57:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418911068!14111087!1
X-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 28425 invoked from network); 18 Dec 2014 13:57:48 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 13:57:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:57:48 +0000
Message-Id: <5492EB6A0200007800050AA5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:57:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
	<1418305541-5135-5-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-5-git-send-email-vkuznets@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Jones <drjones@redhat.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v5 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.14 at 14:45, <vkuznets@redhat.com> wrote:
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1177,6 +1177,39 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>      }
>      break;
>  
> +    case XEN_DOMCTL_devour:
> +    {
> +        struct domain *recipient_dom;
> +
> +        if ( !d->recipient )
> +        {
> +            recipient_dom = get_domain_by_id(op->u.devour.recipient);
> +            if ( recipient_dom == NULL )
> +            {
> +                ret = -ESRCH;
> +                break;
> +            }
> +
> +            if ( recipient_dom->tot_pages != 0 )
> +            {
> +                put_domain(recipient_dom);
> +                ret = -EINVAL;
> +                break;
> +            }
> +            /*
> +             * Make sure no allocation/remapping is ongoing and set is_dying
> +             * flag to prevent such actions in future.
> +             */
> +            spin_lock(&d->page_alloc_lock);
> +            d->is_dying = DOMDYING_locked;
> +            d->recipient = recipient_dom;

Is d == recipient_dom a valid case (not leading to any issues)?

> +            smp_wmb(); /* make sure recipient was set before domain_kill() */

The spin_unlock() guarantees ordering already.

> +            spin_unlock(&d->page_alloc_lock);
> +        }
> +        ret = domain_kill(d);

Do you really mean to simply kill the domain when d->recipient was
already set on entry?

Also I would strongly suggest having this fall through into the
XEN_DOMCTL_destroydomain case - just look there for what code
you're missing right now. Of course the continuation then
shouldn't go through the whole if() above anymore, i.e. you may
want to permit the operation to succeed when d->recipient ==
recipient_dom.

> --- 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;

Please add these variable in the scope you need them in.

> @@ -1764,13 +1765,32 @@ 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);

This needs to be done more than once when order > 0, or else
you may trigger an ASSERT() in assign_pages().

> +            if ( assign_pages(d->recipient, pg, order, 0) )
> +                /* assign_pages reports the error by itself */
> +                goto out;
> +
> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
> +                printk(XENLOG_G_INFO
> +                       "Failed to add MFN %lx (GFN %lx) to Dom%d's physmap\n",
> +                       mfn, gmfn, d->recipient->domain_id);

And that's it? I understand that you can't propagate the error, but
wouldn't you better crash the recipient domain instead of leaving it
in an inconsistent state?

Also the message would better be more specific - e.g.

"Failed to re-add Dom%d's GFN %lx (MFN %lx) to Dom%d\n"

> +        }
>      }
>  
> +out:

You could do well without this label (in particular I think what you add
as else path would better move into to if() case several lines up, in
which case the use of a label may then indeed be warranted), but if
you really need one, please make sure it is indented by at least one
space.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:58:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:58:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1baR-0000Af-DR; Thu, 18 Dec 2014 13:57: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 1Y1baQ-0000AY-6W
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:57:50 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	F2/D2-27584-D5DD2945; Thu, 18 Dec 2014 13:57:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418911068!14111087!1
X-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 28425 invoked from network); 18 Dec 2014 13:57:48 -0000
Received: from mail.emea.novell.com (HELO mail.emea.novell.com)
	(130.57.118.101)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 13:57:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:57:48 +0000
Message-Id: <5492EB6A0200007800050AA5@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:57:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
	<1418305541-5135-5-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-5-git-send-email-vkuznets@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Jones <drjones@redhat.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v5 4/9] xen: introduce XEN_DOMCTL_devour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.14 at 14:45, <vkuznets@redhat.com> wrote:
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1177,6 +1177,39 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>      }
>      break;
>  
> +    case XEN_DOMCTL_devour:
> +    {
> +        struct domain *recipient_dom;
> +
> +        if ( !d->recipient )
> +        {
> +            recipient_dom = get_domain_by_id(op->u.devour.recipient);
> +            if ( recipient_dom == NULL )
> +            {
> +                ret = -ESRCH;
> +                break;
> +            }
> +
> +            if ( recipient_dom->tot_pages != 0 )
> +            {
> +                put_domain(recipient_dom);
> +                ret = -EINVAL;
> +                break;
> +            }
> +            /*
> +             * Make sure no allocation/remapping is ongoing and set is_dying
> +             * flag to prevent such actions in future.
> +             */
> +            spin_lock(&d->page_alloc_lock);
> +            d->is_dying = DOMDYING_locked;
> +            d->recipient = recipient_dom;

Is d == recipient_dom a valid case (not leading to any issues)?

> +            smp_wmb(); /* make sure recipient was set before domain_kill() */

The spin_unlock() guarantees ordering already.

> +            spin_unlock(&d->page_alloc_lock);
> +        }
> +        ret = domain_kill(d);

Do you really mean to simply kill the domain when d->recipient was
already set on entry?

Also I would strongly suggest having this fall through into the
XEN_DOMCTL_destroydomain case - just look there for what code
you're missing right now. Of course the continuation then
shouldn't go through the whole if() above anymore, i.e. you may
want to permit the operation to succeed when d->recipient ==
recipient_dom.

> --- 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;

Please add these variable in the scope you need them in.

> @@ -1764,13 +1765,32 @@ 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);

This needs to be done more than once when order > 0, or else
you may trigger an ASSERT() in assign_pages().

> +            if ( assign_pages(d->recipient, pg, order, 0) )
> +                /* assign_pages reports the error by itself */
> +                goto out;
> +
> +            if ( guest_physmap_add_page(d->recipient, gmfn, mfn, order) )
> +                printk(XENLOG_G_INFO
> +                       "Failed to add MFN %lx (GFN %lx) to Dom%d's physmap\n",
> +                       mfn, gmfn, d->recipient->domain_id);

And that's it? I understand that you can't propagate the error, but
wouldn't you better crash the recipient domain instead of leaving it
in an inconsistent state?

Also the message would better be more specific - e.g.

"Failed to re-add Dom%d's GFN %lx (MFN %lx) to Dom%d\n"

> +        }
>      }
>  
> +out:

You could do well without this label (in particular I think what you add
as else path would better move into to if() case several lines up, in
which case the use of a label may then indeed be warranted), but if
you really need one, please make sure it is indented by at least one
space.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:59:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:59:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1bc6-0000G3-T9; Thu, 18 Dec 2014 13:59:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1bc5-0000Fv-7t
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:59:33 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A6/03-17735-4CDD2945; Thu, 18 Dec 2014 13:59:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418911171!10641144!1
X-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 13103 invoked from network); 18 Dec 2014 13:59:32 -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; 18 Dec 2014 13:59:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:59:31 +0000
Message-Id: <5492EBD30200007800050AA8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:59:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
	<1418305541-5135-10-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-10-git-send-email-vkuznets@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Jones <drjones@redhat.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xsm: add XEN_DOMCTL_devour support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.14 at 14:45, <vkuznets@redhat.com> wrote:
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1190,6 +1190,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>                  break;
>              }
>  
> +            ret = xsm_devour(XSM_HOOK, d, recipient_dom);
> +            if ( ret ) {

Provided such a hook is needed in the first place, please move the
opening brace on its own line.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 13:59:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 13:59:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1bc6-0000G3-T9; Thu, 18 Dec 2014 13:59:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1bc5-0000Fv-7t
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:59:33 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A6/03-17735-4CDD2945; Thu, 18 Dec 2014 13:59:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1418911171!10641144!1
X-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 13103 invoked from network); 18 Dec 2014 13:59:32 -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; 18 Dec 2014 13:59:32 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 13:59:31 +0000
Message-Id: <5492EBD30200007800050AA8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 13:59:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Vitaly Kuznetsov" <vkuznets@redhat.com>
References: <1418305541-5135-1-git-send-email-vkuznets@redhat.com>
	<1418305541-5135-10-git-send-email-vkuznets@redhat.com>
In-Reply-To: <1418305541-5135-10-git-send-email-vkuznets@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@linaro.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Andrew Jones <drjones@redhat.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH v5 9/9] xsm: add XEN_DOMCTL_devour support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.14 at 14:45, <vkuznets@redhat.com> wrote:
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1190,6 +1190,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>                  break;
>              }
>  
> +            ret = xsm_devour(XSM_HOOK, d, recipient_dom);
> +            if ( ret ) {

Provided such a hook is needed in the first place, please move the
opening brace on its own line.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 14:10:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 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 1Y1bmZ-0000sv-2n; Thu, 18 Dec 2014 14:10:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1bmY-0000sq-4I
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:10:22 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	14/2A-02696-D40E2945; Thu, 18 Dec 2014 14:10:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418911820!15957939!1
X-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 12345 invoked from network); 18 Dec 2014 14:10:20 -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; 18 Dec 2014 14:10:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:10:20 +0000
Message-Id: <5492EE5C0200007800050AD9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:10:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-3-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-3-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 02/23] x86/VPMU: Don't globally disable
 VPMU if initialization 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 17.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
> forever.

Reported-by: Jan Beulich <jbeulich@suse.com>
(or Suggested-by if you like that better)

> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  xen/arch/x86/hvm/vpmu.c | 15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
> index 1df74c2..b43ea80 100644
> --- a/xen/arch/x86/hvm/vpmu.c
> +++ b/xen/arch/x86/hvm/vpmu.c
> @@ -218,6 +218,7 @@ void vpmu_initialise(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>      uint8_t vendor = current_cpu_data.x86_vendor;
> +    int ret;
>  
>      if ( is_pvh_vcpu(v) )
>          return;
> @@ -230,21 +231,21 @@ 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;
> +        ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
>          break;
>  
>      case X86_VENDOR_INTEL:
> -        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
> -            opt_vpmu_enabled = 0;
> +        ret = vmx_vpmu_initialise(v, opt_vpmu_enabled);
>          break;
>  
>      default:
> -        printk("VPMU: Initialization failed. "
> -               "Unknown CPU vendor %d\n", vendor);
> -        opt_vpmu_enabled = 0;
> +        ret = -EINVAL;
> +        printk(XENLOG_G_WARNING "VPMU: Unknown CPU vendor %d\n", vendor);
>          break;
>      }
> +
> +    if ( ret )
> +        printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);

Please avoid issuing two messages for the same problem. And the
one in the default case probably doesn't make sense to be issued
more than once (and then perhaps at boot time, if that doesn't
happen already).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 14:10:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 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 1Y1bmZ-0000sv-2n; Thu, 18 Dec 2014 14:10:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1bmY-0000sq-4I
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:10:22 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	14/2A-02696-D40E2945; Thu, 18 Dec 2014 14:10:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418911820!15957939!1
X-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 12345 invoked from network); 18 Dec 2014 14:10:20 -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; 18 Dec 2014 14:10:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:10:20 +0000
Message-Id: <5492EE5C0200007800050AD9@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:10:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-3-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-3-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 02/23] x86/VPMU: Don't globally disable
 VPMU if initialization 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 17.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
> forever.

Reported-by: Jan Beulich <jbeulich@suse.com>
(or Suggested-by if you like that better)

> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  xen/arch/x86/hvm/vpmu.c | 15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
> index 1df74c2..b43ea80 100644
> --- a/xen/arch/x86/hvm/vpmu.c
> +++ b/xen/arch/x86/hvm/vpmu.c
> @@ -218,6 +218,7 @@ void vpmu_initialise(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>      uint8_t vendor = current_cpu_data.x86_vendor;
> +    int ret;
>  
>      if ( is_pvh_vcpu(v) )
>          return;
> @@ -230,21 +231,21 @@ 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;
> +        ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
>          break;
>  
>      case X86_VENDOR_INTEL:
> -        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
> -            opt_vpmu_enabled = 0;
> +        ret = vmx_vpmu_initialise(v, opt_vpmu_enabled);
>          break;
>  
>      default:
> -        printk("VPMU: Initialization failed. "
> -               "Unknown CPU vendor %d\n", vendor);
> -        opt_vpmu_enabled = 0;
> +        ret = -EINVAL;
> +        printk(XENLOG_G_WARNING "VPMU: Unknown CPU vendor %d\n", vendor);
>          break;
>      }
> +
> +    if ( ret )
> +        printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);

Please avoid issuing two messages for the same problem. And the
one in the default case probably doesn't make sense to be issued
more than once (and then perhaps at boot time, if that doesn't
happen already).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 14:12:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14: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 1Y1bob-00018V-LP; Thu, 18 Dec 2014 14:12:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1boa-00016N-44
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:12:28 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	56/05-15461-BC0E2945; Thu, 18 Dec 2014 14:12:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418911946!16465349!1
X-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 29475 invoked from network); 18 Dec 2014 14:12:27 -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; 18 Dec 2014 14:12:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:12:26 +0000
Message-Id: <5492EED90200007800050AE4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:12:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-9-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-9-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 08/23] 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>
Content-Type: text/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.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> 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>

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 Dec 18 14:12:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14: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 1Y1bob-00018V-LP; Thu, 18 Dec 2014 14:12:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1boa-00016N-44
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:12:28 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	56/05-15461-BC0E2945; Thu, 18 Dec 2014 14:12:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418911946!16465349!1
X-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 29475 invoked from network); 18 Dec 2014 14:12:27 -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; 18 Dec 2014 14:12:27 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:12:26 +0000
Message-Id: <5492EED90200007800050AE4@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:12:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-9-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-9-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 08/23] 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>
Content-Type: text/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.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> 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>

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 Dec 18 14:17:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14: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 1Y1bt2-0001Tu-C0; Thu, 18 Dec 2014 14:17: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 1Y1bt0-0001Tp-Og
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:17:03 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	08/87-17735-DD1E2945; Thu, 18 Dec 2014 14:17:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418912221!9945171!1
X-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 8201 invoked from network); 18 Dec 2014 14:17:01 -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; 18 Dec 2014 14:17:01 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:17:00 +0000
Message-Id: <5492EFED0200007800050AFD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:17:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-11-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-11-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 10/23] 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.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> --- 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

This belongs further up into the (alphabetically sorted) set. With that
adjusted
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 Dec 18 14:17:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14: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 1Y1bt2-0001Tu-C0; Thu, 18 Dec 2014 14:17: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 1Y1bt0-0001Tp-Og
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:17:03 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	08/87-17735-DD1E2945; Thu, 18 Dec 2014 14:17:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418912221!9945171!1
X-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 8201 invoked from network); 18 Dec 2014 14:17:01 -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; 18 Dec 2014 14:17:01 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:17:00 +0000
Message-Id: <5492EFED0200007800050AFD@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:17:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-11-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-11-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 10/23] 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.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> --- 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

This belongs further up into the (alphabetically sorted) set. With that
adjusted
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 Dec 18 14:22:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1byO-000238-Es; Thu, 18 Dec 2014 14:22:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1byN-000233-Fs
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:22:35 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	25/01-25276-A23E2945; Thu, 18 Dec 2014 14:22:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418912554!16468336!1
X-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 24650 invoked from network); 18 Dec 2014 14:22:34 -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; 18 Dec 2014 14:22:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:22:33 +0000
Message-Id: <5492F1370200007800050B0F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:22:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-13-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-13-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 12/23] x86/VPMU: Replace vcpu with vpmu
 as argument to some routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> @@ -146,36 +145,34 @@ static void vpmu_save_force(void *arg)
>      vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
>  
>      if ( vpmu->arch_vpmu_ops )
> -        (void)vpmu->arch_vpmu_ops->arch_vpmu_save(v);
> +        (void)vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu);

Pointless cast.

> @@ -193,7 +190,7 @@ void vpmu_load(struct vcpu *v)
>          if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
>          {
>              on_selected_cpus(cpumask_of(vpmu->last_pcpu),
> -                             vpmu_save_force, (void *)v, 1);
> +                             vpmu_save_force, (void *)vpmu, 1);

Again.

Apart from that
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 Dec 18 14:22:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1byO-000238-Es; Thu, 18 Dec 2014 14:22:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1byN-000233-Fs
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:22:35 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	25/01-25276-A23E2945; Thu, 18 Dec 2014 14:22:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1418912554!16468336!1
X-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 24650 invoked from network); 18 Dec 2014 14:22:34 -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; 18 Dec 2014 14:22:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:22:33 +0000
Message-Id: <5492F1370200007800050B0F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:22:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-13-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-13-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 12/23] x86/VPMU: Replace vcpu with vpmu
 as argument to some routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> @@ -146,36 +145,34 @@ static void vpmu_save_force(void *arg)
>      vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
>  
>      if ( vpmu->arch_vpmu_ops )
> -        (void)vpmu->arch_vpmu_ops->arch_vpmu_save(v);
> +        (void)vpmu->arch_vpmu_ops->arch_vpmu_save(vpmu);

Pointless cast.

> @@ -193,7 +190,7 @@ void vpmu_load(struct vcpu *v)
>          if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
>          {
>              on_selected_cpus(cpumask_of(vpmu->last_pcpu),
> -                             vpmu_save_force, (void *)v, 1);
> +                             vpmu_save_force, (void *)vpmu, 1);

Again.

Apart from that
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 Dec 18 14:45:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14:45:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1cKJ-00030X-VO; Thu, 18 Dec 2014 14:45: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 1Y1cKI-00030S-FN
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:45:14 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	26/27-17694-978E2945; Thu, 18 Dec 2014 14:45:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418913912!14407138!1
X-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 12572 invoked from network); 18 Dec 2014 14:45:13 -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 Dec 2014 14:45:13 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:45:12 +0000
Message-Id: <5492F6870200007800050B2F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:45:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-14-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-14-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 13/23] 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.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> 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>

I don't see these being valid anymore, and I think this isn't the first
time I'm pointing out that you should drop such tags when making
more than really benign changes.

> @@ -277,3 +289,163 @@ void vpmu_dump(struct vcpu *v)
>          vpmu->arch_vpmu_ops->arch_vpmu_dump(v);
>  }
>  
> +void vpmu_unload(struct vpmu_struct *vpmu)
> +{
> +    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_RUNNING) )
> +        return;
> +
> +    if (vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_unload)
> +        vpmu->arch_vpmu_ops->arch_vpmu_unload(vpmu);
> +
> +    vpmu_reset(vpmu, VPMU_RUNNING | VPMU_RUNNING);

???

> +static long vpmu_unload_next(void *arg)
> +{
> +    struct vcpu *last;
> +
> +    local_irq_disable(); /* so that last_vcpu doesn't change under us. */
> +
> +    last = this_cpu(last_vcpu);
> +    if ( last )
> +    {
> +        vpmu_unload(vcpu_vpmu(last));
> +        this_cpu(last_vcpu) = NULL;
> +    }
> +
> +    local_irq_enable();
> +
> +    cpumask_and(&vpmu_cpumask_unload, &vpmu_cpumask_unload, &cpu_online_map);
> +    if ( cpumask_weight(&vpmu_cpumask_unload) > 1 )
> +    {
> +        int ret;
> +        int cpu = cpumask_cycle(smp_processor_id(), &vpmu_cpumask_unload);

CPU numbers are unsigned.

> +static int vpmu_unload_all(unsigned long old_mode)
> +{
> +    int ret = 0;
> +
> +    vpmu_unload(vcpu_vpmu(current));
> +
> +    if ( nr_cpu_ids > 1 )
> +    {
> +        unsigned int cpu;
> +
> +        cpumask_or(&vpmu_cpumask_unload, &vpmu_cpumask_unload, &cpu_online_map);

Why do you want to re-use old state here? I.e. don't you mean
cpumask_copy()?  I don't see why you need a static mask anyway
- just store the CPU number you started only in a static, and cycle
through cpu_online_map until you reach it again.

> +        cpu = cpumask_cycle(smp_processor_id(), &vpmu_cpumask_unload);

Nothing guarantees cpu < nr_cpus_ids here, as nr_cpu_ids > 1
doesn't mean there's more than one CPU online.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 14:45:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14:45:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1cKJ-00030X-VO; Thu, 18 Dec 2014 14:45: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 1Y1cKI-00030S-FN
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:45:14 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	26/27-17694-978E2945; Thu, 18 Dec 2014 14:45:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1418913912!14407138!1
X-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 12572 invoked from network); 18 Dec 2014 14:45:13 -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 Dec 2014 14:45:13 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:45:12 +0000
Message-Id: <5492F6870200007800050B2F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:45:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-14-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-14-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 13/23] 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.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> 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>

I don't see these being valid anymore, and I think this isn't the first
time I'm pointing out that you should drop such tags when making
more than really benign changes.

> @@ -277,3 +289,163 @@ void vpmu_dump(struct vcpu *v)
>          vpmu->arch_vpmu_ops->arch_vpmu_dump(v);
>  }
>  
> +void vpmu_unload(struct vpmu_struct *vpmu)
> +{
> +    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_RUNNING) )
> +        return;
> +
> +    if (vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_unload)
> +        vpmu->arch_vpmu_ops->arch_vpmu_unload(vpmu);
> +
> +    vpmu_reset(vpmu, VPMU_RUNNING | VPMU_RUNNING);

???

> +static long vpmu_unload_next(void *arg)
> +{
> +    struct vcpu *last;
> +
> +    local_irq_disable(); /* so that last_vcpu doesn't change under us. */
> +
> +    last = this_cpu(last_vcpu);
> +    if ( last )
> +    {
> +        vpmu_unload(vcpu_vpmu(last));
> +        this_cpu(last_vcpu) = NULL;
> +    }
> +
> +    local_irq_enable();
> +
> +    cpumask_and(&vpmu_cpumask_unload, &vpmu_cpumask_unload, &cpu_online_map);
> +    if ( cpumask_weight(&vpmu_cpumask_unload) > 1 )
> +    {
> +        int ret;
> +        int cpu = cpumask_cycle(smp_processor_id(), &vpmu_cpumask_unload);

CPU numbers are unsigned.

> +static int vpmu_unload_all(unsigned long old_mode)
> +{
> +    int ret = 0;
> +
> +    vpmu_unload(vcpu_vpmu(current));
> +
> +    if ( nr_cpu_ids > 1 )
> +    {
> +        unsigned int cpu;
> +
> +        cpumask_or(&vpmu_cpumask_unload, &vpmu_cpumask_unload, &cpu_online_map);

Why do you want to re-use old state here? I.e. don't you mean
cpumask_copy()?  I don't see why you need a static mask anyway
- just store the CPU number you started only in a static, and cycle
through cpu_online_map until you reach it again.

> +        cpu = cpumask_cycle(smp_processor_id(), &vpmu_cpumask_unload);

Nothing guarantees cpu < nr_cpus_ids here, as nr_cpu_ids > 1
doesn't mean there's more than one CPU online.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 14:53:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14:53:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1cRo-0003X2-5x; Thu, 18 Dec 2014 14:53: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 1Y1cRm-0003Wx-Tf
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:52:59 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	D3/65-31453-A4AE2945; Thu, 18 Dec 2014 14:52:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418914377!11264634!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14339 invoked from network); 18 Dec 2014 14:52:57 -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; 18 Dec 2014 14:52:57 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:52:57 +0000
Message-Id: <5492F8580200007800050B4D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:52:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-15-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-15-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 14/23] 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>
Content-Type: text/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.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> +int __init amd_vpmu_init(void)
> +{
> +    if ( current_cpu_data.x86_vendor != X86_VENDOR_AMD )
> +        return -EINVAL;

Your only caller guarantees this not to be the case.

> +int __init core2_vpmu_init(void)
> +{
> +    u64 caps;
> +
> +    if ( current_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> +        return -EINVAL;

Same here.

> +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;

Case labels indented to the same level as the containing switch
please, and break missing here.

> +    }
> +
> +    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);

Use __stringify()?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 14:53:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14:53:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1cRo-0003X2-5x; Thu, 18 Dec 2014 14:53: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 1Y1cRm-0003Wx-Tf
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:52:59 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	D3/65-31453-A4AE2945; Thu, 18 Dec 2014 14:52:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1418914377!11264634!1
X-Originating-IP: [130.57.118.101]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14339 invoked from network); 18 Dec 2014 14:52:57 -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; 18 Dec 2014 14:52:57 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:52:57 +0000
Message-Id: <5492F8580200007800050B4D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:52:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-15-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-15-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 14/23] 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>
Content-Type: text/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.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> +int __init amd_vpmu_init(void)
> +{
> +    if ( current_cpu_data.x86_vendor != X86_VENDOR_AMD )
> +        return -EINVAL;

Your only caller guarantees this not to be the case.

> +int __init core2_vpmu_init(void)
> +{
> +    u64 caps;
> +
> +    if ( current_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> +        return -EINVAL;

Same here.

> +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;

Case labels indented to the same level as the containing switch
please, and break missing here.

> +    }
> +
> +    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);

Use __stringify()?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 14:57:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14: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 1Y1cVi-0003f9-HU; Thu, 18 Dec 2014 14:57: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 1Y1cVg-0003f4-2G
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:57:00 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	35/99-14214-B3BE2945; Thu, 18 Dec 2014 14:56:59 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418914617!8852721!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12563 invoked from network); 18 Dec 2014 14:56:58 -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; 18 Dec 2014 14:56:58 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 047C6AC55;
	Thu, 18 Dec 2014 14:56:55 +0000 (UTC)
Message-ID: <5492EB37.3050004@suse.com>
Date: Thu, 18 Dec 2014 15:56:55 +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: Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org
References: <20141218130919.29909.13566.stgit@Abyss.station>
In-Reply-To: <20141218130919.29909.13566.stgit@Abyss.station>
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [OSSTEST PATCH 0/2] Test case for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/18/2014 02:38 PM, Dario Faggioli wrote:
> Just the fact that we are not doing anything to smoke test cpupools, while I
> think we should. :-)
>
> This add something quite basic, but it's, IMO, already representative one
> typically does with cpupools. We can add more pCPU related tricks (removing,
> adding, etc), or we can add more domains and move them around more, of course.
> If anyone has any suggestion about operations that should really be part of
> Osstest's runs, let me know and I'll include them.
>
> As it is right now, the test is super quick, to the point that I considered
> whether it wouldn't have been better to add some similar cpupool operations in
> one of the existing jobs. I ended up deciding for having a separate job,
> because this is, after all, a rather specific operation, and a different enough
> thing from basic VM lifecycle, so I think it deserves its own job.
>
> Thanks and Regards, Dario

Thanks for doing this!


Juergen

>
> ---
>
> Dario Faggioli (2):
>        ts-cpupools: new test script
>        Testing cpupools: recipe for it and job definition
>
>
>   make-flight |   11 +++++
>   sg-run-job  |    6 +++
>   ts-cpupools |  124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 141 insertions(+)
>   create mode 100755 ts-cpupools
>
> --
> <<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
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 14:57:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14: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 1Y1cVi-0003f9-HU; Thu, 18 Dec 2014 14:57: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 1Y1cVg-0003f4-2G
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:57:00 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	35/99-14214-B3BE2945; Thu, 18 Dec 2014 14:56:59 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418914617!8852721!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12563 invoked from network); 18 Dec 2014 14:56:58 -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; 18 Dec 2014 14:56:58 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 047C6AC55;
	Thu, 18 Dec 2014 14:56:55 +0000 (UTC)
Message-ID: <5492EB37.3050004@suse.com>
Date: Thu, 18 Dec 2014 15:56:55 +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: Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org
References: <20141218130919.29909.13566.stgit@Abyss.station>
In-Reply-To: <20141218130919.29909.13566.stgit@Abyss.station>
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [OSSTEST PATCH 0/2] Test case for cpupools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/18/2014 02:38 PM, Dario Faggioli wrote:
> Just the fact that we are not doing anything to smoke test cpupools, while I
> think we should. :-)
>
> This add something quite basic, but it's, IMO, already representative one
> typically does with cpupools. We can add more pCPU related tricks (removing,
> adding, etc), or we can add more domains and move them around more, of course.
> If anyone has any suggestion about operations that should really be part of
> Osstest's runs, let me know and I'll include them.
>
> As it is right now, the test is super quick, to the point that I considered
> whether it wouldn't have been better to add some similar cpupool operations in
> one of the existing jobs. I ended up deciding for having a separate job,
> because this is, after all, a rather specific operation, and a different enough
> thing from basic VM lifecycle, so I think it deserves its own job.
>
> Thanks and Regards, Dario

Thanks for doing this!


Juergen

>
> ---
>
> Dario Faggioli (2):
>        ts-cpupools: new test script
>        Testing cpupools: recipe for it and job definition
>
>
>   make-flight |   11 +++++
>   sg-run-job  |    6 +++
>   ts-cpupools |  124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 141 insertions(+)
>   create mode 100755 ts-cpupools
>
> --
> <<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
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 14:57:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1cWE-0003i7-VH; Thu, 18 Dec 2014 14:57: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 1Y1cWD-0003hp-54
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:57:33 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C1/EF-22737-C5BE2945; Thu, 18 Dec 2014 14:57:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418914651!14127913!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 5869 invoked from network); 18 Dec 2014 14:57:31 -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; 18 Dec 2014 14:57:31 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 585EDAC55;
	Thu, 18 Dec 2014 14:57:31 +0000 (UTC)
Message-ID: <5492EB5A.4060108@suse.com>
Date: Thu, 18 Dec 2014 15:57: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: Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133854.29909.50574.stgit@Abyss.station>
In-Reply-To: <20141218133854.29909.50574.stgit@Abyss.station>
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [OSSTEST PATCH 1/2] ts-cpupools: new test script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/18/2014 02:38 PM, Dario Faggioli wrote:
> for smoke testing cpupools a bit. It tries to partition
> a live host in two cpupools, trying out the following 3
> schedulers for the new cpupool (one after the other):
>   credit, credit2 and RTDS.
>
> It also tries to migrating a domain to the new cpupool
> and then back to Pool-0.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Juergen Gross <jgross@suse.com>

> ---
>   ts-cpupools |  124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 124 insertions(+)
>   create mode 100755 ts-cpupools
>
> diff --git a/ts-cpupools b/ts-cpupools
> new file mode 100755
> index 0000000..fe612e1
> --- /dev/null
> +++ b/ts-cpupools
> @@ -0,0 +1,124 @@
> +#!/usr/bin/perl -w
> +# This is part of "osstest", an automated testing framework for Xen.
> +# Copyright (C) 2009-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/>.
> +
> +use strict qw(vars);
> +use DBI;
> +use Osstest;
> +use Osstest::TestSupport;
> +
> +tsreadconfig();
> +
> +our ($whhost,$gn)= @ARGV;
> +$whhost ||= 'host';
> +$gn ||= 'debian';
> +
> +our ($ho,$gho) = ts_get_host_guest($whhost,$gn);
> +#our $ho= selecthost(@ARGV);
> +
> +our $default_cpupool= "Pool-0";
> +our @schedulers= ("credit","credit2","rtds");
> +our @cpulist;
> +our $nr_cpus;
> +
> +sub check () {
> +  my $out;
> +
> +  # Figure out the number of pCPUs of the host. We need to know
> +  # that in order to decide with what pCPUs we want to create
> +  # cpupools
> +  my $xlinfo= target_cmd_output_root($ho, "xl info");
> +  $xlinfo =~ /nr_cpus\s*:\s([0-9]*)/;
> +  $nr_cpus= $1;
> +  logm("Found $nr_cpus pCPUs");
> +  die "Too few pCPUs to test cpupools: $nr_cpus" if $nr_cpus < 2;
> +
> +  # We want only 1 cpupool to exist
> +  my $cppinfo= target_cmd_output_root($ho, "xl cpupool-list");
> +  my $nr_cpupools= $cppinfo =~ tr/\n//;
> +  logm("Found $nr_cpupools cpupools");
> +  die "There already is more than one cpu pool!" if $nr_cpupools > 1;
> +  die "Non-default cpupool configuration detected" if $cppinfo =~ /^$default_cpupool\b/;
> +
> +  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
> +  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
> +}
> +
> +# List of the odd pCPUs
> +sub prep_cpulist () {
> +  if (! defined @cpulist) {
> +    foreach my $cpu (0..$nr_cpus) {
> +      next unless $cpu % 2;
> +      push @cpulist, $cpu;
> +    }
> +  }
> +}
> +
> +sub prep ($) {
> +  my ($sched)= @_;
> +
> +  # Remove the pCPUs from in $cpulist from the default cpupool
> +  my $cpustr= "[";
> +  foreach my $cpu (@cpulist) {
> +    target_cmd_root($ho,"xl cpupool-cpu-remove $default_cpupool $cpu");
> +    $cpustr.= "\"$cpu\", ";
> +  }
> +  $cpustr.= "]";
> +
> +  logm("Creating config file for cpupool-osstest-$sched with cpus=$cpustr");
> +  target_putfilecontents_stash($ho,100,<<"END","/etc/xen/cpupool-osstest-$sched");
> +name = "cpupool-osstest-$sched"
> +sched=\"$sched\"
> +cpus=$cpustr
> +END
> +}
> +
> +check();
> +prep_cpulist();
> +foreach my $sched (@schedulers) {
> +  my $out;
> +
> +  prep("$sched");
> +
> +  # For each cpupool:
> +  #  * create it
> +  #  * rename it
> +  #  * move a domain in it
> +  #  * move back a domain out of it
> +  #  * add back the pcpus from it to the default pool
> +  #  * destroy it
> +  target_cmd_root($ho, "xl cpupool-create /etc/xen/cpupool-osstest-$sched");
> +  target_cmd_output_root($ho, "xl cpupool-rename cpupool-osstest-$sched cpupool-test");
> +  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
> +  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
> +
> +  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} cpupool-test");
> +  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
> +  $out= target_cmd_output_root($ho, "xl vcpu-list"); logm("$out");
> +
> +  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} Pool-0");
> +  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
> +
> +  foreach my $cpu (@cpulist) {
> +    target_cmd_root($ho,"xl cpupool-cpu-remove cpupool-test $cpu");
> +    target_cmd_root($ho,"xl cpupool-cpu-add $default_cpupool $cpu");
> +  }
> +  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
> +
> +  target_cmd_root($ho, "xl cpupool-destroy cpupool-test");
> +  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
> +}
> +
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 18 14:57:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1cWE-0003i7-VH; Thu, 18 Dec 2014 14:57: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 1Y1cWD-0003hp-54
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:57:33 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	C1/EF-22737-C5BE2945; Thu, 18 Dec 2014 14:57:32 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418914651!14127913!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 5869 invoked from network); 18 Dec 2014 14:57:31 -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; 18 Dec 2014 14:57:31 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 585EDAC55;
	Thu, 18 Dec 2014 14:57:31 +0000 (UTC)
Message-ID: <5492EB5A.4060108@suse.com>
Date: Thu, 18 Dec 2014 15:57: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: Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133854.29909.50574.stgit@Abyss.station>
In-Reply-To: <20141218133854.29909.50574.stgit@Abyss.station>
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [OSSTEST PATCH 1/2] ts-cpupools: new test script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/18/2014 02:38 PM, Dario Faggioli wrote:
> for smoke testing cpupools a bit. It tries to partition
> a live host in two cpupools, trying out the following 3
> schedulers for the new cpupool (one after the other):
>   credit, credit2 and RTDS.
>
> It also tries to migrating a domain to the new cpupool
> and then back to Pool-0.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Juergen Gross <jgross@suse.com>

> ---
>   ts-cpupools |  124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 124 insertions(+)
>   create mode 100755 ts-cpupools
>
> diff --git a/ts-cpupools b/ts-cpupools
> new file mode 100755
> index 0000000..fe612e1
> --- /dev/null
> +++ b/ts-cpupools
> @@ -0,0 +1,124 @@
> +#!/usr/bin/perl -w
> +# This is part of "osstest", an automated testing framework for Xen.
> +# Copyright (C) 2009-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/>.
> +
> +use strict qw(vars);
> +use DBI;
> +use Osstest;
> +use Osstest::TestSupport;
> +
> +tsreadconfig();
> +
> +our ($whhost,$gn)= @ARGV;
> +$whhost ||= 'host';
> +$gn ||= 'debian';
> +
> +our ($ho,$gho) = ts_get_host_guest($whhost,$gn);
> +#our $ho= selecthost(@ARGV);
> +
> +our $default_cpupool= "Pool-0";
> +our @schedulers= ("credit","credit2","rtds");
> +our @cpulist;
> +our $nr_cpus;
> +
> +sub check () {
> +  my $out;
> +
> +  # Figure out the number of pCPUs of the host. We need to know
> +  # that in order to decide with what pCPUs we want to create
> +  # cpupools
> +  my $xlinfo= target_cmd_output_root($ho, "xl info");
> +  $xlinfo =~ /nr_cpus\s*:\s([0-9]*)/;
> +  $nr_cpus= $1;
> +  logm("Found $nr_cpus pCPUs");
> +  die "Too few pCPUs to test cpupools: $nr_cpus" if $nr_cpus < 2;
> +
> +  # We want only 1 cpupool to exist
> +  my $cppinfo= target_cmd_output_root($ho, "xl cpupool-list");
> +  my $nr_cpupools= $cppinfo =~ tr/\n//;
> +  logm("Found $nr_cpupools cpupools");
> +  die "There already is more than one cpu pool!" if $nr_cpupools > 1;
> +  die "Non-default cpupool configuration detected" if $cppinfo =~ /^$default_cpupool\b/;
> +
> +  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
> +  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
> +}
> +
> +# List of the odd pCPUs
> +sub prep_cpulist () {
> +  if (! defined @cpulist) {
> +    foreach my $cpu (0..$nr_cpus) {
> +      next unless $cpu % 2;
> +      push @cpulist, $cpu;
> +    }
> +  }
> +}
> +
> +sub prep ($) {
> +  my ($sched)= @_;
> +
> +  # Remove the pCPUs from in $cpulist from the default cpupool
> +  my $cpustr= "[";
> +  foreach my $cpu (@cpulist) {
> +    target_cmd_root($ho,"xl cpupool-cpu-remove $default_cpupool $cpu");
> +    $cpustr.= "\"$cpu\", ";
> +  }
> +  $cpustr.= "]";
> +
> +  logm("Creating config file for cpupool-osstest-$sched with cpus=$cpustr");
> +  target_putfilecontents_stash($ho,100,<<"END","/etc/xen/cpupool-osstest-$sched");
> +name = "cpupool-osstest-$sched"
> +sched=\"$sched\"
> +cpus=$cpustr
> +END
> +}
> +
> +check();
> +prep_cpulist();
> +foreach my $sched (@schedulers) {
> +  my $out;
> +
> +  prep("$sched");
> +
> +  # For each cpupool:
> +  #  * create it
> +  #  * rename it
> +  #  * move a domain in it
> +  #  * move back a domain out of it
> +  #  * add back the pcpus from it to the default pool
> +  #  * destroy it
> +  target_cmd_root($ho, "xl cpupool-create /etc/xen/cpupool-osstest-$sched");
> +  target_cmd_output_root($ho, "xl cpupool-rename cpupool-osstest-$sched cpupool-test");
> +  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
> +  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
> +
> +  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} cpupool-test");
> +  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
> +  $out= target_cmd_output_root($ho, "xl vcpu-list"); logm("$out");
> +
> +  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} Pool-0");
> +  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
> +
> +  foreach my $cpu (@cpulist) {
> +    target_cmd_root($ho,"xl cpupool-cpu-remove cpupool-test $cpu");
> +    target_cmd_root($ho,"xl cpupool-cpu-add $default_cpupool $cpu");
> +  }
> +  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
> +
> +  target_cmd_root($ho, "xl cpupool-destroy cpupool-test");
> +  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
> +}
> +
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 18 14:57:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14:57:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1cWR-0003kw-Bv; Thu, 18 Dec 2014 14:57: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 1Y1cWQ-0003kZ-Gl
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:57:46 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	B9/D5-25727-96BE2945; Thu, 18 Dec 2014 14:57:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418914665!14396819!1
X-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 24135 invoked from network); 18 Dec 2014 14:57:45 -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; 18 Dec 2014 14:57:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:57:44 +0000
Message-Id: <5492F9780200007800050B69@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:57:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-20-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-20-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 19/23] 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.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> 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>

Acked-by: Jan Beulich <jbeulich@suse.com>
with one minor comment:

> +        /* 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;

Perhaps better > 1, to be on the safe side?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 14:57:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 14:57:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1cWR-0003kw-Bv; Thu, 18 Dec 2014 14:57: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 1Y1cWQ-0003kZ-Gl
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 14:57:46 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	B9/D5-25727-96BE2945; Thu, 18 Dec 2014 14:57:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1418914665!14396819!1
X-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 24135 invoked from network); 18 Dec 2014 14:57:45 -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; 18 Dec 2014 14:57:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 14:57:44 +0000
Message-Id: <5492F9780200007800050B69@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 14:57:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-20-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418830734-1558-20-git-send-email-boris.ostrovsky@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 19/23] 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.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
> 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>

Acked-by: Jan Beulich <jbeulich@suse.com>
with one minor comment:

> +        /* 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;

Perhaps better > 1, to be on the safe side?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 15:00:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:00:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1cYq-00041y-W6; Thu, 18 Dec 2014 15:00: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 1Y1cYp-00041l-MB
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:00:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5B/63-15461-FFBE2945; Thu, 18 Dec 2014 15:00:15 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418914814!16545555!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 6933 invoked from network); 18 Dec 2014 15:00:14 -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; 18 Dec 2014 15:00:14 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 694C2AD71;
	Thu, 18 Dec 2014 15:00:13 +0000 (UTC)
Message-ID: <5492EBFC.8010005@suse.com>
Date: Thu, 18 Dec 2014 16:00:12 +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: Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
In-Reply-To: <20141218133902.29909.99057.stgit@Abyss.station>
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/18/2014 02:39 PM, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> ---
>   make-flight |   11 +++++++++++
>   sg-run-job  |    6 ++++++
>   2 files changed, 17 insertions(+)
>
> diff --git a/make-flight b/make-flight
> index a91f256..ce02c89 100755
> --- a/make-flight
> +++ b/make-flight
> @@ -266,6 +266,16 @@ do_credit2_tests () {
>               $debian_runvars all_hostflags=$most_hostflags
>   }
>
> +do_cpupools_tests () {
> +  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
> +    return
> +  fi

Why can't you test cpupools on x86_64?


Juergen

> +
> +  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools            \
> +       test-cpupools xl $xenarch $dom0arch                            \
> +            $debian_runvars all_hostflags=$most_hostflags
> +}
> +
>   do_passthrough_tests () {
>     if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
>       return
> @@ -366,6 +376,7 @@ test_matrix_do_one () {
>
>     do_sedf_tests
>     do_credit2_tests
> +  do_cpupools_tests
>
>     if [ $xenarch = amd64 -a $dom0arch = i386 ]; then
>
> diff --git a/sg-run-job b/sg-run-job
> index 2cf810a..0250087 100755
> --- a/sg-run-job
> +++ b/sg-run-job
> @@ -272,6 +272,12 @@ proc run-job/test-debianhvm {} {
>       test-guest debianhvm
>   }
>
> +proc need-hosts/test-cpupools {} { return host }
> +proc run-job/test-cpupools {} {
> +    install-guest-debian
> +    run-ts . = ts-cpupools
> +}
> +
>   proc need-hosts/test-pair {} { return {src_host dst_host} }
>   proc run-job/test-pair {} {
>       run-ts . =              ts-debian-install      dst_host
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 18 15:00:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:00:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1cYq-00041y-W6; Thu, 18 Dec 2014 15:00: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 1Y1cYp-00041l-MB
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:00:15 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5B/63-15461-FFBE2945; Thu, 18 Dec 2014 15:00:15 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1418914814!16545555!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 6933 invoked from network); 18 Dec 2014 15:00:14 -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; 18 Dec 2014 15:00:14 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 694C2AD71;
	Thu, 18 Dec 2014 15:00:13 +0000 (UTC)
Message-ID: <5492EBFC.8010005@suse.com>
Date: Thu, 18 Dec 2014 16:00:12 +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: Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
In-Reply-To: <20141218133902.29909.99057.stgit@Abyss.station>
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/18/2014 02:39 PM, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> ---
>   make-flight |   11 +++++++++++
>   sg-run-job  |    6 ++++++
>   2 files changed, 17 insertions(+)
>
> diff --git a/make-flight b/make-flight
> index a91f256..ce02c89 100755
> --- a/make-flight
> +++ b/make-flight
> @@ -266,6 +266,16 @@ do_credit2_tests () {
>               $debian_runvars all_hostflags=$most_hostflags
>   }
>
> +do_cpupools_tests () {
> +  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
> +    return
> +  fi

Why can't you test cpupools on x86_64?


Juergen

> +
> +  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools            \
> +       test-cpupools xl $xenarch $dom0arch                            \
> +            $debian_runvars all_hostflags=$most_hostflags
> +}
> +
>   do_passthrough_tests () {
>     if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
>       return
> @@ -366,6 +376,7 @@ test_matrix_do_one () {
>
>     do_sedf_tests
>     do_credit2_tests
> +  do_cpupools_tests
>
>     if [ $xenarch = amd64 -a $dom0arch = i386 ]; then
>
> diff --git a/sg-run-job b/sg-run-job
> index 2cf810a..0250087 100755
> --- a/sg-run-job
> +++ b/sg-run-job
> @@ -272,6 +272,12 @@ proc run-job/test-debianhvm {} {
>       test-guest debianhvm
>   }
>
> +proc need-hosts/test-cpupools {} { return host }
> +proc run-job/test-cpupools {} {
> +    install-guest-debian
> +    run-ts . = ts-cpupools
> +}
> +
>   proc need-hosts/test-pair {} { return {src_host dst_host} }
>   proc run-job/test-pair {} {
>       run-ts . =              ts-debian-install      dst_host
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 18 15:04:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ccg-0004bn-Cy; Thu, 18 Dec 2014 15:04: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 1Y1ccf-0004bh-E4
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:04:13 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	CA/D1-02954-CECE2945; Thu, 18 Dec 2014 15:04:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418915050!15992190!1
X-Originating-IP: [66.165.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 29535 invoked from network); 18 Dec 2014 15:04:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 15:04:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="206284149"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 18 Dec 2014 10:04: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 1Y1ccb-0007iR-Ff;
	Thu, 18 Dec 2014 15:04:09 +0000
Date: Thu, 18 Dec 2014 15:04:09 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141218150409.GA2870@zion.uk.xensource.com>
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
	<5492EBFC.8010005@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5492EBFC.8010005@suse.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>,
	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
Subject: Re: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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, Dec 18, 2014 at 04:00:12PM +0100, Juergen Gross wrote:
> On 12/18/2014 02:39 PM, Dario Faggioli wrote:
> >Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >---
> >  make-flight |   11 +++++++++++
> >  sg-run-job  |    6 ++++++
> >  2 files changed, 17 insertions(+)
> >
> >diff --git a/make-flight b/make-flight
> >index a91f256..ce02c89 100755
> >--- a/make-flight
> >+++ b/make-flight
> >@@ -266,6 +266,16 @@ do_credit2_tests () {
> >              $debian_runvars all_hostflags=$most_hostflags
> >  }
> >
> >+do_cpupools_tests () {
> >+  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
> >+    return
> >+  fi
> 
> Why can't you test cpupools on x86_64?
> 

Don't worry. That's the name used for 64 bit (be it amd or intel) in
OSSTest. :-)

Wei.

> 
> Juergen
> 
> >+
> >+  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools            \
> >+       test-cpupools xl $xenarch $dom0arch                            \
> >+            $debian_runvars all_hostflags=$most_hostflags
> >+}
> >+
> >  do_passthrough_tests () {
> >    if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
> >      return
> >@@ -366,6 +376,7 @@ test_matrix_do_one () {
> >
> >    do_sedf_tests
> >    do_credit2_tests
> >+  do_cpupools_tests
> >
> >    if [ $xenarch = amd64 -a $dom0arch = i386 ]; then
> >
> >diff --git a/sg-run-job b/sg-run-job
> >index 2cf810a..0250087 100755
> >--- a/sg-run-job
> >+++ b/sg-run-job
> >@@ -272,6 +272,12 @@ proc run-job/test-debianhvm {} {
> >      test-guest debianhvm
> >  }
> >
> >+proc need-hosts/test-cpupools {} { return host }
> >+proc run-job/test-cpupools {} {
> >+    install-guest-debian
> >+    run-ts . = ts-cpupools
> >+}
> >+
> >  proc need-hosts/test-pair {} { return {src_host dst_host} }
> >  proc run-job/test-pair {} {
> >      run-ts . =              ts-debian-install      dst_host
> >
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xen.org
> >http://lists.xen.org/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 Dec 18 15:04:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ccg-0004bn-Cy; Thu, 18 Dec 2014 15:04: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 1Y1ccf-0004bh-E4
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:04:13 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	CA/D1-02954-CECE2945; Thu, 18 Dec 2014 15:04:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418915050!15992190!1
X-Originating-IP: [66.165.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 29535 invoked from network); 18 Dec 2014 15:04:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 15:04:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="206284149"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.3.210.2;
	Thu, 18 Dec 2014 10:04: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 1Y1ccb-0007iR-Ff;
	Thu, 18 Dec 2014 15:04:09 +0000
Date: Thu, 18 Dec 2014 15:04:09 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Juergen Gross <jgross@suse.com>
Message-ID: <20141218150409.GA2870@zion.uk.xensource.com>
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
	<5492EBFC.8010005@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5492EBFC.8010005@suse.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>,
	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
Subject: Re: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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, Dec 18, 2014 at 04:00:12PM +0100, Juergen Gross wrote:
> On 12/18/2014 02:39 PM, Dario Faggioli wrote:
> >Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >---
> >  make-flight |   11 +++++++++++
> >  sg-run-job  |    6 ++++++
> >  2 files changed, 17 insertions(+)
> >
> >diff --git a/make-flight b/make-flight
> >index a91f256..ce02c89 100755
> >--- a/make-flight
> >+++ b/make-flight
> >@@ -266,6 +266,16 @@ do_credit2_tests () {
> >              $debian_runvars all_hostflags=$most_hostflags
> >  }
> >
> >+do_cpupools_tests () {
> >+  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
> >+    return
> >+  fi
> 
> Why can't you test cpupools on x86_64?
> 

Don't worry. That's the name used for 64 bit (be it amd or intel) in
OSSTest. :-)

Wei.

> 
> Juergen
> 
> >+
> >+  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools            \
> >+       test-cpupools xl $xenarch $dom0arch                            \
> >+            $debian_runvars all_hostflags=$most_hostflags
> >+}
> >+
> >  do_passthrough_tests () {
> >    if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
> >      return
> >@@ -366,6 +376,7 @@ test_matrix_do_one () {
> >
> >    do_sedf_tests
> >    do_credit2_tests
> >+  do_cpupools_tests
> >
> >    if [ $xenarch = amd64 -a $dom0arch = i386 ]; then
> >
> >diff --git a/sg-run-job b/sg-run-job
> >index 2cf810a..0250087 100755
> >--- a/sg-run-job
> >+++ b/sg-run-job
> >@@ -272,6 +272,12 @@ proc run-job/test-debianhvm {} {
> >      test-guest debianhvm
> >  }
> >
> >+proc need-hosts/test-cpupools {} { return host }
> >+proc run-job/test-cpupools {} {
> >+    install-guest-debian
> >+    run-ts . = ts-cpupools
> >+}
> >+
> >  proc need-hosts/test-pair {} { return {src_host dst_host} }
> >  proc run-job/test-pair {} {
> >      run-ts . =              ts-debian-install      dst_host
> >
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xen.org
> >http://lists.xen.org/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 Dec 18 15:05:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:05:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ce1-0004gX-SF; Thu, 18 Dec 2014 15:05: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 1Y1ce0-0004gS-34
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:05:36 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	20/02-22819-F3DE2945; Thu, 18 Dec 2014 15:05:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418915132!6562252!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 18485 invoked from network); 18 Dec 2014 15:05:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 15:05:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="206284701"
Message-ID: <1418915119.11882.79.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Date: Thu, 18 Dec 2014 15:05:19 +0000
In-Reply-To: <1418711577-15449-2-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-2-git-send-email-cyliu@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 1/4] domain snapshot terms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-16 at 14:32 +0800, Chunyan Liu wrote:
> Changes to V8:
>   * add a document for domain snapshot related terms, they will be
>     referred in later documents.
> 
> =====================================================================
> Terms
> 
> * Active domain: domain created and started
> 
> * Inactive domain: domain created but not started

As Wei says I think you mean "defined" here, since created and started
are (essentially) synonyms for some toolstacks.

You'll probably want to define "defined" too for clarity.

> 
> * 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.
> 
>   Contents of disks (whether a subset or all disks associated with
>   the domain) are saved at a given point of time, and can be restored
>   back to that state. On a running guest, a disk-only snapshot is
>   likely to be only crash-consistent rather than clean (that is, it
>   represents the state of the disk on a sudden power outage); on an
>   inactive guest, a disk-only snapshot is clean if the disks were
>   clean when the guest was last shut down.

There is the possibility of doing clean snapshots if a guest agent is
involved to quiesce the disks at the right moment (e.g. I believe qemu
has such a thing, or at least I've seen talks about it being developed
at conferences). Are you including this possibility or explicitly ruling
it out of scope?

> * Live Snapshot:
> 
>   Like live migration, it will increase size of the memory dump file,
>   but reducess downtime of the guest.
> 
> * Internal Disk Snapshot
> 
>   File formats such as qcow2 track both the snapshot and changes
>   since the snapshot in a single file.
> 
> * External Disk Snapshot
> 
>   The snapshot is one file, and the changes since the snapshot
>   are in another file.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 15:05:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:05:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ce1-0004gX-SF; Thu, 18 Dec 2014 15:05: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 1Y1ce0-0004gS-34
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:05:36 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	20/02-22819-F3DE2945; Thu, 18 Dec 2014 15:05:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418915132!6562252!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 18485 invoked from network); 18 Dec 2014 15:05:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 15:05:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="206284701"
Message-ID: <1418915119.11882.79.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Date: Thu, 18 Dec 2014 15:05:19 +0000
In-Reply-To: <1418711577-15449-2-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-2-git-send-email-cyliu@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 1/4] domain snapshot terms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-16 at 14:32 +0800, Chunyan Liu wrote:
> Changes to V8:
>   * add a document for domain snapshot related terms, they will be
>     referred in later documents.
> 
> =====================================================================
> Terms
> 
> * Active domain: domain created and started
> 
> * Inactive domain: domain created but not started

As Wei says I think you mean "defined" here, since created and started
are (essentially) synonyms for some toolstacks.

You'll probably want to define "defined" too for clarity.

> 
> * 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.
> 
>   Contents of disks (whether a subset or all disks associated with
>   the domain) are saved at a given point of time, and can be restored
>   back to that state. On a running guest, a disk-only snapshot is
>   likely to be only crash-consistent rather than clean (that is, it
>   represents the state of the disk on a sudden power outage); on an
>   inactive guest, a disk-only snapshot is clean if the disks were
>   clean when the guest was last shut down.

There is the possibility of doing clean snapshots if a guest agent is
involved to quiesce the disks at the right moment (e.g. I believe qemu
has such a thing, or at least I've seen talks about it being developed
at conferences). Are you including this possibility or explicitly ruling
it out of scope?

> * Live Snapshot:
> 
>   Like live migration, it will increase size of the memory dump file,
>   but reducess downtime of the guest.
> 
> * Internal Disk Snapshot
> 
>   File formats such as qcow2 track both the snapshot and changes
>   since the snapshot in a single file.
> 
> * External Disk Snapshot
> 
>   The snapshot is one file, and the changes since the snapshot
>   are in another file.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 15:10:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15: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 1Y1cig-0004rn-KJ; Thu, 18 Dec 2014 15:10: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 1Y1cig-0004rh-6k
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:10:26 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	64/04-22737-16EE2945; Thu, 18 Dec 2014 15:10:25 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418915424!14131539!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 17429 invoked from network); 18 Dec 2014 15:10:25 -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; 18 Dec 2014 15:10:25 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id B08BFABCC;
	Thu, 18 Dec 2014 15:10:24 +0000 (UTC)
Message-ID: <5492EE60.5090005@suse.com>
Date: Thu, 18 Dec 2014 16:10: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: Wei Liu <wei.liu2@citrix.com>
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
	<5492EBFC.8010005@suse.com>
	<20141218150409.GA2870@zion.uk.xensource.com>
In-Reply-To: <20141218150409.GA2870@zion.uk.xensource.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/18/2014 04:04 PM, Wei Liu wrote:
> On Thu, Dec 18, 2014 at 04:00:12PM +0100, Juergen Gross wrote:
>> On 12/18/2014 02:39 PM, Dario Faggioli wrote:
>>> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>>> ---
>>>   make-flight |   11 +++++++++++
>>>   sg-run-job  |    6 ++++++
>>>   2 files changed, 17 insertions(+)
>>>
>>> diff --git a/make-flight b/make-flight
>>> index a91f256..ce02c89 100755
>>> --- a/make-flight
>>> +++ b/make-flight
>>> @@ -266,6 +266,16 @@ do_credit2_tests () {
>>>               $debian_runvars all_hostflags=$most_hostflags
>>>   }
>>>
>>> +do_cpupools_tests () {
>>> +  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
>>> +    return
>>> +  fi
>>
>> Why can't you test cpupools on x86_64?
>>
>
> Don't worry. That's the name used for 64 bit (be it amd or intel) in
> OSSTest. :-)

Aargh. Some automatic filter in my brain translated this to arm64 :-)

So: Why can't you test cpupools on ARM?


Juergen

>
> Wei.
>
>>
>> Juergen
>>
>>> +
>>> +  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools            \
>>> +       test-cpupools xl $xenarch $dom0arch                            \
>>> +            $debian_runvars all_hostflags=$most_hostflags
>>> +}
>>> +
>>>   do_passthrough_tests () {
>>>     if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
>>>       return
>>> @@ -366,6 +376,7 @@ test_matrix_do_one () {
>>>
>>>     do_sedf_tests
>>>     do_credit2_tests
>>> +  do_cpupools_tests
>>>
>>>     if [ $xenarch = amd64 -a $dom0arch = i386 ]; then
>>>
>>> diff --git a/sg-run-job b/sg-run-job
>>> index 2cf810a..0250087 100755
>>> --- a/sg-run-job
>>> +++ b/sg-run-job
>>> @@ -272,6 +272,12 @@ proc run-job/test-debianhvm {} {
>>>       test-guest debianhvm
>>>   }
>>>
>>> +proc need-hosts/test-cpupools {} { return host }
>>> +proc run-job/test-cpupools {} {
>>> +    install-guest-debian
>>> +    run-ts . = ts-cpupools
>>> +}
>>> +
>>>   proc need-hosts/test-pair {} { return {src_host dst_host} }
>>>   proc run-job/test-pair {} {
>>>       run-ts . =              ts-debian-install      dst_host
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/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 Dec 18 15:10:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15: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 1Y1cig-0004rn-KJ; Thu, 18 Dec 2014 15:10: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 1Y1cig-0004rh-6k
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:10:26 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	64/04-22737-16EE2945; Thu, 18 Dec 2014 15:10:25 +0000
X-Env-Sender: jgross@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418915424!14131539!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 17429 invoked from network); 18 Dec 2014 15:10:25 -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; 18 Dec 2014 15:10:25 -0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id B08BFABCC;
	Thu, 18 Dec 2014 15:10:24 +0000 (UTC)
Message-ID: <5492EE60.5090005@suse.com>
Date: Thu, 18 Dec 2014 16:10: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: Wei Liu <wei.liu2@citrix.com>
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
	<5492EBFC.8010005@suse.com>
	<20141218150409.GA2870@zion.uk.xensource.com>
In-Reply-To: <20141218150409.GA2870@zion.uk.xensource.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/18/2014 04:04 PM, Wei Liu wrote:
> On Thu, Dec 18, 2014 at 04:00:12PM +0100, Juergen Gross wrote:
>> On 12/18/2014 02:39 PM, Dario Faggioli wrote:
>>> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>>> ---
>>>   make-flight |   11 +++++++++++
>>>   sg-run-job  |    6 ++++++
>>>   2 files changed, 17 insertions(+)
>>>
>>> diff --git a/make-flight b/make-flight
>>> index a91f256..ce02c89 100755
>>> --- a/make-flight
>>> +++ b/make-flight
>>> @@ -266,6 +266,16 @@ do_credit2_tests () {
>>>               $debian_runvars all_hostflags=$most_hostflags
>>>   }
>>>
>>> +do_cpupools_tests () {
>>> +  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
>>> +    return
>>> +  fi
>>
>> Why can't you test cpupools on x86_64?
>>
>
> Don't worry. That's the name used for 64 bit (be it amd or intel) in
> OSSTest. :-)

Aargh. Some automatic filter in my brain translated this to arm64 :-)

So: Why can't you test cpupools on ARM?


Juergen

>
> Wei.
>
>>
>> Juergen
>>
>>> +
>>> +  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools            \
>>> +       test-cpupools xl $xenarch $dom0arch                            \
>>> +            $debian_runvars all_hostflags=$most_hostflags
>>> +}
>>> +
>>>   do_passthrough_tests () {
>>>     if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
>>>       return
>>> @@ -366,6 +376,7 @@ test_matrix_do_one () {
>>>
>>>     do_sedf_tests
>>>     do_credit2_tests
>>> +  do_cpupools_tests
>>>
>>>     if [ $xenarch = amd64 -a $dom0arch = i386 ]; then
>>>
>>> diff --git a/sg-run-job b/sg-run-job
>>> index 2cf810a..0250087 100755
>>> --- a/sg-run-job
>>> +++ b/sg-run-job
>>> @@ -272,6 +272,12 @@ proc run-job/test-debianhvm {} {
>>>       test-guest debianhvm
>>>   }
>>>
>>> +proc need-hosts/test-cpupools {} { return host }
>>> +proc run-job/test-cpupools {} {
>>> +    install-guest-debian
>>> +    run-ts . = ts-cpupools
>>> +}
>>> +
>>>   proc need-hosts/test-pair {} { return {src_host dst_host} }
>>>   proc run-job/test-pair {} {
>>>       run-ts . =              ts-debian-install      dst_host
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/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 Dec 18 15:12:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ckl-0005Co-52; Thu, 18 Dec 2014 15:12:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1ckk-0005AL-7O
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:12:34 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	45/D5-25547-1EEE2945; Thu, 18 Dec 2014 15:12:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418915550!14406676!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 6546 invoked from network); 18 Dec 2014 15:12:32 -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;
	18 Dec 2014 15:12:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="205813172"
Message-ID: <1418915443.11882.86.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Date: Thu, 18 Dec 2014 15:10:43 +0000
In-Reply-To: <1418711577-15449-3-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-16 at 14:32 +0800, Chunyan Liu wrote:
> Changes to V8:
>   * add an overview document, so that one can has a overall look
>     about the whole domain snapshot work, limits, requirements,
>     how to do, etc.
> 
> =====================================================================
> Domain snapshot overview

I don't see a similar section for disk snapshots, are you not
considering those here except as a part of a domain snapshot or is this
an oversight?

There are three main use cases (that I know of at least) for
snapshotting like behaviour.

One is as you've mentioned below for "backup", i.e. to preserve the VM
at a certain point in time in order to be able to roll back to it. Is
this the only usecase you are considering?

A second use case is to support "gold image" type deployments, i.e.
where you create one baseline single disk image and then clone it
multiple times to deploy lots of guests. I think this is usually a "disk
snapshot" type thing, but maybe it can be implemented as restoring a
gold domain snapshot multiple times (e.g. for start of day performance
reasons).

The third case, (which is similar to the first), is taking a disk
snapshot in order to be able to run you usual backup software on the
snapshot (which is now unchanging, which is handy) and then deleting the
disk snapshot (this differs from the first case in which disk is active
after the snapshot, and due to the lack of the memory part). 

Are you considering all three use cases here or are you explicitly
ruling out anything but the first? I think there might be some subtle
differences in the requirements, wrt which operations need to consider
the possibility of an active domain etc, depending on which cases are
considered. It would be good to be explicit about the use cases you are
not trying to address here so we are all on the same page.

If you are ruling these other usecases out then I think it would be
useful to briefly describe them and then note that they are out of scope
for this design, so that we have an agreed understanding of what is in
or out of scope and/or can debate to what extent such use cases ought to
be considered in the design if not the implementation.

> 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 usually includes:
> a) create a domain snapshot
> b) roll back (or called "revert") to a domain snapshot
> c) delete a domain snapshot
> d) list all domain snapshots
> 
> But following the existing xl idioms of managing storage and saved
> VM images via existing CLI command (qemu-img, lvcreate, ls, mv,
> cp etc), xl snapshot functionality would be kept as simple as
> possible:
> * xl will do a) and b), creating a snapshot and reverting a
>   domain to a snapshot.
> * xl will NOT do c) and d), xl won't manage snapshots, as xl
>   doesn't maintain saved images created by 'xl save'. So xl
>   will have no idea of the existence of domain snapshots and
>   the chain relationship between snapshots. It will depends on
>   user to take care of the snapshots, know the snapshot chain
>   info, and delete snapshots.

This is a case where the usecases being considered might apply. If the
third case I outlined above is in scope then xl may need to somehow
support deleting a snapshot from under the feet of an active domain etc
(which need not necessarily imply knowledge of snapshot chains or
snapshot management, but might involve a notification to the backend for
example).

> Domain Snapshot Support and Not Support:
> * support live snapshot
> * support internal disk snapshot and external disk snapshot
> * support different disk backend types.
>   (Basic goal is to support 'raw' and 'qcow2' only).
> 
> * not support snapshot when domain is shutdowning or dying.
> * not support disk-only snapshot [1].
> 
>  [1] 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.
> 
> 
> 2. Requirements
> 
> General Requirements:
> * ability to save/restore domain memory
> * ability to create/delete/apply disk snapshot [2]

Is "apply" the same as "revert to"? Worth adding to the terminology
section and using consistently.

> * ability to parse user config file
> 
>   [2] Disk snapshot requirements:
>   - external tools: qemu-img, lvcreate, vhd-util, etc.
>   - for basic goal, we support 'raw' and 'qcow2' backend types
>     only. Then it requires:
>     libxl qmp command or "qemu-img" (when qemu process does not
>     exist)
> 
> 
> 3. Interaction with other operations:
> 
> No.

What about shutdown/dying as you noted above? What about migration or
regular save/restore?

> 
> 4. General workflow
> 
> Create a snapshot:
>   * parse user cfg file if passed in
>   * check snapshot operation is allowed or not
>   * save domain, saving memory status to file (refer to: save_domain)
>   * take disk snapshot (e.g. call qmp command)
>   * unpause domain
> 
> Revert to snapshot:
>   * parse use cfg file (xl doesn't manage snapshots, so it has no
>     idea of snapshot existence. User MUST supply configuration file)
>   * destroy this domain
>   * create a new domain from snapshot info
>     - apply disk snapshot (e.g. call qemu-img)
>     - a process like restore domain



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 15:12:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ckl-0005Co-52; Thu, 18 Dec 2014 15:12:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1ckk-0005AL-7O
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:12:34 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	45/D5-25547-1EEE2945; Thu, 18 Dec 2014 15:12:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418915550!14406676!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 6546 invoked from network); 18 Dec 2014 15:12:32 -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;
	18 Dec 2014 15:12:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="205813172"
Message-ID: <1418915443.11882.86.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Date: Thu, 18 Dec 2014 15:10:43 +0000
In-Reply-To: <1418711577-15449-3-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-16 at 14:32 +0800, Chunyan Liu wrote:
> Changes to V8:
>   * add an overview document, so that one can has a overall look
>     about the whole domain snapshot work, limits, requirements,
>     how to do, etc.
> 
> =====================================================================
> Domain snapshot overview

I don't see a similar section for disk snapshots, are you not
considering those here except as a part of a domain snapshot or is this
an oversight?

There are three main use cases (that I know of at least) for
snapshotting like behaviour.

One is as you've mentioned below for "backup", i.e. to preserve the VM
at a certain point in time in order to be able to roll back to it. Is
this the only usecase you are considering?

A second use case is to support "gold image" type deployments, i.e.
where you create one baseline single disk image and then clone it
multiple times to deploy lots of guests. I think this is usually a "disk
snapshot" type thing, but maybe it can be implemented as restoring a
gold domain snapshot multiple times (e.g. for start of day performance
reasons).

The third case, (which is similar to the first), is taking a disk
snapshot in order to be able to run you usual backup software on the
snapshot (which is now unchanging, which is handy) and then deleting the
disk snapshot (this differs from the first case in which disk is active
after the snapshot, and due to the lack of the memory part). 

Are you considering all three use cases here or are you explicitly
ruling out anything but the first? I think there might be some subtle
differences in the requirements, wrt which operations need to consider
the possibility of an active domain etc, depending on which cases are
considered. It would be good to be explicit about the use cases you are
not trying to address here so we are all on the same page.

If you are ruling these other usecases out then I think it would be
useful to briefly describe them and then note that they are out of scope
for this design, so that we have an agreed understanding of what is in
or out of scope and/or can debate to what extent such use cases ought to
be considered in the design if not the implementation.

> 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 usually includes:
> a) create a domain snapshot
> b) roll back (or called "revert") to a domain snapshot
> c) delete a domain snapshot
> d) list all domain snapshots
> 
> But following the existing xl idioms of managing storage and saved
> VM images via existing CLI command (qemu-img, lvcreate, ls, mv,
> cp etc), xl snapshot functionality would be kept as simple as
> possible:
> * xl will do a) and b), creating a snapshot and reverting a
>   domain to a snapshot.
> * xl will NOT do c) and d), xl won't manage snapshots, as xl
>   doesn't maintain saved images created by 'xl save'. So xl
>   will have no idea of the existence of domain snapshots and
>   the chain relationship between snapshots. It will depends on
>   user to take care of the snapshots, know the snapshot chain
>   info, and delete snapshots.

This is a case where the usecases being considered might apply. If the
third case I outlined above is in scope then xl may need to somehow
support deleting a snapshot from under the feet of an active domain etc
(which need not necessarily imply knowledge of snapshot chains or
snapshot management, but might involve a notification to the backend for
example).

> Domain Snapshot Support and Not Support:
> * support live snapshot
> * support internal disk snapshot and external disk snapshot
> * support different disk backend types.
>   (Basic goal is to support 'raw' and 'qcow2' only).
> 
> * not support snapshot when domain is shutdowning or dying.
> * not support disk-only snapshot [1].
> 
>  [1] 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.
> 
> 
> 2. Requirements
> 
> General Requirements:
> * ability to save/restore domain memory
> * ability to create/delete/apply disk snapshot [2]

Is "apply" the same as "revert to"? Worth adding to the terminology
section and using consistently.

> * ability to parse user config file
> 
>   [2] Disk snapshot requirements:
>   - external tools: qemu-img, lvcreate, vhd-util, etc.
>   - for basic goal, we support 'raw' and 'qcow2' backend types
>     only. Then it requires:
>     libxl qmp command or "qemu-img" (when qemu process does not
>     exist)
> 
> 
> 3. Interaction with other operations:
> 
> No.

What about shutdown/dying as you noted above? What about migration or
regular save/restore?

> 
> 4. General workflow
> 
> Create a snapshot:
>   * parse user cfg file if passed in
>   * check snapshot operation is allowed or not
>   * save domain, saving memory status to file (refer to: save_domain)
>   * take disk snapshot (e.g. call qmp command)
>   * unpause domain
> 
> Revert to snapshot:
>   * parse use cfg file (xl doesn't manage snapshots, so it has no
>     idea of snapshot existence. User MUST supply configuration file)
>   * destroy this domain
>   * create a new domain from snapshot info
>     - apply disk snapshot (e.g. call qemu-img)
>     - a process like restore domain



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 15:19:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 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 1Y1cqx-0005Zs-2F; Thu, 18 Dec 2014 15:18: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 1Y1cqv-0005Zj-Ri
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:18:58 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	A2/52-14727-160F2945; Thu, 18 Dec 2014 15:18:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418915931!14143035!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 21834 invoked from network); 18 Dec 2014 15:18:56 -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;
	18 Dec 2014 15:18:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="206292017"
Message-ID: <1418915759.11882.91.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Date: Thu, 18 Dec 2014 15:15:59 +0000
In-Reply-To: <1418711577-15449-4-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:
> Changes to V8:
>   * xl won't manage snapshots, that means it won't maintain json files,
>     won't maintain snapshot chain relationship, and then as a result
>     won't take care of deleting snapshot and listing snapshots.
>   * remove snapshot-delete and snapshot-list interface
>   * update snapshot-revert interface
>   * update snapshot-create/revert implementaion
> 
> ===========================================================================
> 
> XL Design
> 
> 1. User Interface
> 
> 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, use cfgfile. (e.g. if --name specifies a name,
>     meanwhile there is name specified in cfgfile, name in cfgfile will
>     be used.)

If you do not specify cfgfile then where do things go? Is --name perhaps
also serving as a basename for a path to save things to?

I wonder if we can simplify this a bit and therefore avoid the need cfg
file in common case. e.g.

----8<-------
  xl snapshot-create [--live] [--internal|--external] <domain> <path>

<path> is a path to a directory, which must not exist. This path will be
created and the memory snapshot stored in it using some well defined
name.

If the snapshot is --external then the snapshot disks are created in
<path> with some well defined name based on the virtual device and
backend format in use.

If the snapshot is --internal then the snapshot disks are internal.

The default is <TBD, based on backends in use?>

--live is as you've already got it.
----8<-------

I'm not sure what name and description actually are here, so I've
omitted them.

Any of that could be overridden with e.g. more specific disk
configuration stanzas etc via the cfg file, if necessary.

This is just a suggestion, feel free to disagree.

NB xl create can accept a series of cfg file lines on the command line
too, and treats them as appended to the cfgfile (if any was given). I
think xl snapshot-create should include this functionality too.
> xl snapshot-revert:
>   Revert domain to status of a snapshot.
> 
>   SYNOPSIS:
>       snapshot-revert <domain> <cfgfile> [--running] [--force]
> 
>   OPTIONS:
>     --running        after reverting, change state to running
>     --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.
> 
> 
> 
> 2. cfgfile syntax
> 
> #snapshot name. If user doesn't provide a VM snapshot name, xl will generate
> #a name automatically by the creation time.
> name=""

What is name used for? (I guessed it might be output path above, but I'm
not sure).

> #snapshot description. Default is NULL.
> description=""

What is this used for? Is it embedded into e.g. qcow images or is it
just for the admin's own use (in which cases the existing support for
#comments ought to suffice).

> #memory location. This field should be filled when memory=1. Default is NULL.

The memory option isn't defined anywhere, and I think you've rules
disk-only snapshots out of scope for xl, so I think this is just a left
over from a previous revision.

> #e.g. to specify exernal disk snapshot, like this:
> #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda',
>         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',]
> 
> #e.g. to specify internal disk snapshot, like this:
> disks=[',,hda',',,hdb',]

Ideally one or the other of these behaviours would be possible without
needing to be quite so explicit.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 15:19:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 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 1Y1cqx-0005Zs-2F; Thu, 18 Dec 2014 15:18: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 1Y1cqv-0005Zj-Ri
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:18:58 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	A2/52-14727-160F2945; Thu, 18 Dec 2014 15:18:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1418915931!14143035!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 21834 invoked from network); 18 Dec 2014 15:18:56 -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;
	18 Dec 2014 15:18:56 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="206292017"
Message-ID: <1418915759.11882.91.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Date: Thu, 18 Dec 2014 15:15:59 +0000
In-Reply-To: <1418711577-15449-4-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:
> Changes to V8:
>   * xl won't manage snapshots, that means it won't maintain json files,
>     won't maintain snapshot chain relationship, and then as a result
>     won't take care of deleting snapshot and listing snapshots.
>   * remove snapshot-delete and snapshot-list interface
>   * update snapshot-revert interface
>   * update snapshot-create/revert implementaion
> 
> ===========================================================================
> 
> XL Design
> 
> 1. User Interface
> 
> 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, use cfgfile. (e.g. if --name specifies a name,
>     meanwhile there is name specified in cfgfile, name in cfgfile will
>     be used.)

If you do not specify cfgfile then where do things go? Is --name perhaps
also serving as a basename for a path to save things to?

I wonder if we can simplify this a bit and therefore avoid the need cfg
file in common case. e.g.

----8<-------
  xl snapshot-create [--live] [--internal|--external] <domain> <path>

<path> is a path to a directory, which must not exist. This path will be
created and the memory snapshot stored in it using some well defined
name.

If the snapshot is --external then the snapshot disks are created in
<path> with some well defined name based on the virtual device and
backend format in use.

If the snapshot is --internal then the snapshot disks are internal.

The default is <TBD, based on backends in use?>

--live is as you've already got it.
----8<-------

I'm not sure what name and description actually are here, so I've
omitted them.

Any of that could be overridden with e.g. more specific disk
configuration stanzas etc via the cfg file, if necessary.

This is just a suggestion, feel free to disagree.

NB xl create can accept a series of cfg file lines on the command line
too, and treats them as appended to the cfgfile (if any was given). I
think xl snapshot-create should include this functionality too.
> xl snapshot-revert:
>   Revert domain to status of a snapshot.
> 
>   SYNOPSIS:
>       snapshot-revert <domain> <cfgfile> [--running] [--force]
> 
>   OPTIONS:
>     --running        after reverting, change state to running
>     --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.
> 
> 
> 
> 2. cfgfile syntax
> 
> #snapshot name. If user doesn't provide a VM snapshot name, xl will generate
> #a name automatically by the creation time.
> name=""

What is name used for? (I guessed it might be output path above, but I'm
not sure).

> #snapshot description. Default is NULL.
> description=""

What is this used for? Is it embedded into e.g. qcow images or is it
just for the admin's own use (in which cases the existing support for
#comments ought to suffice).

> #memory location. This field should be filled when memory=1. Default is NULL.

The memory option isn't defined anywhere, and I think you've rules
disk-only snapshots out of scope for xl, so I think this is just a left
over from a previous revision.

> #e.g. to specify exernal disk snapshot, like this:
> #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda',
>         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',]
> 
> #e.g. to specify internal disk snapshot, like this:
> disks=[',,hda',',,hdb',]

Ideally one or the other of these behaviours would be possible without
needing to be quite so explicit.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 15:27:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1cys-00066a-19; Thu, 18 Dec 2014 15:27: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 1Y1cyq-00066V-CH
	for xen-devel@lists.xensource.com; Thu, 18 Dec 2014 15:27:08 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	5F/3C-25727-B42F2945; Thu, 18 Dec 2014 15:27:07 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418916424!14310976!1
X-Originating-IP: [66.165.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 12123 invoked from network); 18 Dec 2014 15:27:06 -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 Dec 2014 15:27:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="206297201"
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.210.2; Thu, 18 Dec 2014 10:24: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 1Y1cwf-0005x0-Ru;
	Thu, 18 Dec 2014 15:24:53 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1cwf-0006LQ-Mf;
	Thu, 18 Dec 2014 15:24:53 +0000
Date: Thu, 18 Dec 2014 15:24:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32438-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] 32438: 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 32438 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32438/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt       5 xen-boot                 fail blocked in 32412
 test-amd64-i386-xl            5 xen-boot                 fail blocked in 32412
 test-amd64-i386-xl-credit2    5 xen-boot                 fail blocked in 32412
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 32412
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start              fail like 32412
 test-amd64-i386-xl-multivcpu  5 xen-boot                 fail blocked in 32412
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken blocked in 32412
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                 fail blocked in 32412
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot           fail blocked in 32412
 test-amd64-i386-rumpuserxen-i386  5 xen-boot             fail blocked in 32412
 test-amd64-i386-freebsd10-amd64  5 xen-boot              fail blocked in 32412
 test-amd64-i386-rhel6hvm-intel  5 xen-boot               fail blocked in 32412
 test-amd64-i386-freebsd10-i386  5 xen-boot               fail blocked in 32412
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot          fail blocked in 32412
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot           fail blocked in 32412
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot          fail blocked in 32412
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot            fail blocked in 32412
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot         fail blocked in 32412
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot     fail blocked in 32412
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot          fail blocked in 32412
 test-amd64-amd64-pair 18 guest-migrate/dst_host/src_host fail blocked in 32412
 test-amd64-i386-pair          8 xen-boot/dst_host        fail blocked in 32412
 test-amd64-i386-pair          7 xen-boot/src_host        fail blocked in 32412
 test-amd64-i386-xl-winxpsp3   5 xen-boot                 fail blocked in 32412
 test-amd64-i386-xl-win7-amd64  5 xen-boot                fail blocked in 32412
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot     fail blocked in 32412
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot     fail blocked in 32412
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot     fail blocked in 32412
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot           fail blocked in 32412
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot            fail blocked in 32412
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install    fail blocked in 32412
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32412

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      9 guest-start                  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-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                5fef85d456eedf616809f7bf722b6f6a782d8a93
baseline version:
 linux                2dbfca5a181973558277b28b1f4c36362291f5e0

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                                           fail    
 test-amd64-amd64-xl-pvh-amd                                  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                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 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                              broken  
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 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                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Dec 18 15:27:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1cys-00066a-19; Thu, 18 Dec 2014 15:27: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 1Y1cyq-00066V-CH
	for xen-devel@lists.xensource.com; Thu, 18 Dec 2014 15:27:08 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	5F/3C-25727-B42F2945; Thu, 18 Dec 2014 15:27:07 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418916424!14310976!1
X-Originating-IP: [66.165.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 12123 invoked from network); 18 Dec 2014 15:27:06 -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 Dec 2014 15:27:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="206297201"
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.210.2; Thu, 18 Dec 2014 10:24: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 1Y1cwf-0005x0-Ru;
	Thu, 18 Dec 2014 15:24:53 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1cwf-0006LQ-Mf;
	Thu, 18 Dec 2014 15:24:53 +0000
Date: Thu, 18 Dec 2014 15:24:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32438-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] 32438: 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 32438 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32438/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt       5 xen-boot                 fail blocked in 32412
 test-amd64-i386-xl            5 xen-boot                 fail blocked in 32412
 test-amd64-i386-xl-credit2    5 xen-boot                 fail blocked in 32412
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 32412
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start              fail like 32412
 test-amd64-i386-xl-multivcpu  5 xen-boot                 fail blocked in 32412
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken blocked in 32412
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                 fail blocked in 32412
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot           fail blocked in 32412
 test-amd64-i386-rumpuserxen-i386  5 xen-boot             fail blocked in 32412
 test-amd64-i386-freebsd10-amd64  5 xen-boot              fail blocked in 32412
 test-amd64-i386-rhel6hvm-intel  5 xen-boot               fail blocked in 32412
 test-amd64-i386-freebsd10-i386  5 xen-boot               fail blocked in 32412
 test-amd64-i386-xl-qemut-win7-amd64  5 xen-boot          fail blocked in 32412
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-boot           fail blocked in 32412
 test-amd64-i386-xl-qemuu-win7-amd64  5 xen-boot          fail blocked in 32412
 test-amd64-i386-xl-qemut-winxpsp3  5 xen-boot            fail blocked in 32412
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot         fail blocked in 32412
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot     fail blocked in 32412
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot          fail blocked in 32412
 test-amd64-amd64-pair 18 guest-migrate/dst_host/src_host fail blocked in 32412
 test-amd64-i386-pair          8 xen-boot/dst_host        fail blocked in 32412
 test-amd64-i386-pair          7 xen-boot/src_host        fail blocked in 32412
 test-amd64-i386-xl-winxpsp3   5 xen-boot                 fail blocked in 32412
 test-amd64-i386-xl-win7-amd64  5 xen-boot                fail blocked in 32412
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot     fail blocked in 32412
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  5 xen-boot     fail blocked in 32412
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  5 xen-boot     fail blocked in 32412
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot           fail blocked in 32412
 test-amd64-i386-xl-qemuu-winxpsp3  5 xen-boot            fail blocked in 32412
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install    fail blocked in 32412
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32412

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      9 guest-start                  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-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                5fef85d456eedf616809f7bf722b6f6a782d8a93
baseline version:
 linux                2dbfca5a181973558277b28b1f4c36362291f5e0

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                                           fail    
 test-amd64-amd64-xl-pvh-amd                                  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                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     fail    
 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                              broken  
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         broken  
 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                                 pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Dec 18 15:29:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:29:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1d0g-0006Cq-NR; Thu, 18 Dec 2014 15:29: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 1Y1d0e-0006Ce-9l
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:29:00 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	4C/FF-25727-BB2F2945; Thu, 18 Dec 2014 15:28:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418916536!14265309!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 29083 invoked from network); 18 Dec 2014 15:28: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;
	18 Dec 2014 15:28:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="205821404"
Message-ID: <1418916436.11882.101.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Date: Thu, 18 Dec 2014 15:27:16 +0000
In-Reply-To: <1418711577-15449-5-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-16 at 14:32 +0800, Chunyan Liu wrote:
> Changes to V8:
>   * remove libxl_domain_snapshot_create/delete/revert API
>   * export disk snapshot functionality for both xl and libvirt usage
> 
> ===========================================================================
> Libxl/libxlu Design
> 
> 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),

Should this be a KeyedUnion over a new LIBXL_DISK_SNAPSHOT_KIND enum
(with values INTERNAL and EXTERNAL)? This would automatically make the
binding between external==true and the fields which depend on that.

external_format should be of type libxl_disk_format, unless it is
referring to something else?

Is it possible for format to differ from the format of the underlying
disk? Perhaps taking a snapshot of a raw disk as a qcow? In any case
passing in UNKNOWN and letting libxl choose (probably by picking the
same as the underlying disk) should be supported.

> /*  This API might not be used by xl, since xl won't take care of deleting
>  *  snapshots. But for libvirt, since libvirt manages snapshots and will
>  *  delete snapshot, this API will be used.
>  */
> int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid,
>                                libxl_disk_snapshot *snapshot, int nb);

The three usecases I mentioned in the previous mail are important here,
because depending on which usecases you are considering there maybe a
many to one relationship between domains and a given snapshot (gold
image case). This interface cannot support that I think.

When we discussed this in previous iterations I suggested a libxl
command to tell a VM that it needed to reexamine its disks to see if any
of the chains had changed. I'm sure that's not the only potential answer
though.

> int libxl_disk_to_snapshot(libxl_ctx *ctx, uint32_t domid,
>                            libxl_disk_snapshot **snapshot, int *num);
> 
>     This is for domain snapshot create. If user doesn't specify disks,
>     then by default it will take internal disk snapshot to each domain
>     disk. This function will fill libxl_disk_snapshot according to domain
>     disks info.

Is this just a helper to produce an array to pass to
libxl_disk_snapshot_create? Or does it actually do stuff?

I think it's the former, but it could be clarified. I *think* this is
just a special case of libxl_device_disk_list which returns plausible
snapshot objects instead of the disks themselves.
> 
> For disk snapshot revert, no qmp command for that, it always calls
> external commands to finish the work, so put in libxlu (?):

I think rather than "no qmp" the issue is that "revert" is (at least as
far as libxl knows) essentially, destroy, rollback disks, restore from
RAM snapshot. So there is no qemu to speak to during the rollback. Is
that 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 Dec 18 15:29:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:29:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1d0g-0006Cq-NR; Thu, 18 Dec 2014 15:29: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 1Y1d0e-0006Ce-9l
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:29:00 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	4C/FF-25727-BB2F2945; Thu, 18 Dec 2014 15:28:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418916536!14265309!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 29083 invoked from network); 18 Dec 2014 15:28: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;
	18 Dec 2014 15:28:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="205821404"
Message-ID: <1418916436.11882.101.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chunyan Liu <cyliu@suse.com>
Date: Thu, 18 Dec 2014 15:27:16 +0000
In-Reply-To: <1418711577-15449-5-git-send-email-cyliu@suse.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, jfehlig@suse.com, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-16 at 14:32 +0800, Chunyan Liu wrote:
> Changes to V8:
>   * remove libxl_domain_snapshot_create/delete/revert API
>   * export disk snapshot functionality for both xl and libvirt usage
> 
> ===========================================================================
> Libxl/libxlu Design
> 
> 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),

Should this be a KeyedUnion over a new LIBXL_DISK_SNAPSHOT_KIND enum
(with values INTERNAL and EXTERNAL)? This would automatically make the
binding between external==true and the fields which depend on that.

external_format should be of type libxl_disk_format, unless it is
referring to something else?

Is it possible for format to differ from the format of the underlying
disk? Perhaps taking a snapshot of a raw disk as a qcow? In any case
passing in UNKNOWN and letting libxl choose (probably by picking the
same as the underlying disk) should be supported.

> /*  This API might not be used by xl, since xl won't take care of deleting
>  *  snapshots. But for libvirt, since libvirt manages snapshots and will
>  *  delete snapshot, this API will be used.
>  */
> int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid,
>                                libxl_disk_snapshot *snapshot, int nb);

The three usecases I mentioned in the previous mail are important here,
because depending on which usecases you are considering there maybe a
many to one relationship between domains and a given snapshot (gold
image case). This interface cannot support that I think.

When we discussed this in previous iterations I suggested a libxl
command to tell a VM that it needed to reexamine its disks to see if any
of the chains had changed. I'm sure that's not the only potential answer
though.

> int libxl_disk_to_snapshot(libxl_ctx *ctx, uint32_t domid,
>                            libxl_disk_snapshot **snapshot, int *num);
> 
>     This is for domain snapshot create. If user doesn't specify disks,
>     then by default it will take internal disk snapshot to each domain
>     disk. This function will fill libxl_disk_snapshot according to domain
>     disks info.

Is this just a helper to produce an array to pass to
libxl_disk_snapshot_create? Or does it actually do stuff?

I think it's the former, but it could be clarified. I *think* this is
just a special case of libxl_device_disk_list which returns plausible
snapshot objects instead of the disks themselves.
> 
> For disk snapshot revert, no qmp command for that, it always calls
> external commands to finish the work, so put in libxlu (?):

I think rather than "no qmp" the issue is that "revert" is (at least as
far as libxl knows) essentially, destroy, rollback disks, restore from
RAM snapshot. So there is no qemu to speak to during the rollback. Is
that 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 Dec 18 15:47:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dIY-0007Do-T6; Thu, 18 Dec 2014 15:47:30 +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 1Y1dIX-0007Da-1Y
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:47:29 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	59/B9-05632-017F2945; Thu, 18 Dec 2014 15:47:28 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418917646!14417310!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10526 invoked from network); 18 Dec 2014 15:47:27 -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; 18 Dec 2014 15:47:27 -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 sBIFlIvY009625
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Dec 2014 15:47:18 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
	sBIFlHMf004886
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 18 Dec 2014 15:47:17 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
	sBIFlHLx004875; Thu, 18 Dec 2014 15:47:17 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, 18 Dec 2014 07:47:16 -0800
Message-ID: <5492F780.3050207@oracle.com>
Date: Thu, 18 Dec 2014 10:49:20 -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: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<2653567.YPYbLMrP7N@amur>
In-Reply-To: <2653567.YPYbLMrP7N@amur>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kevin.tian@intel.com, JBeulich@suse.com, jun.nakajima@intel.com,
	andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, suravee.suthikulpanit@amd.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v16 00/23] 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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/18/2014 07:15 AM, Dietmar Hahn wrote:
> Am Mittwoch 17 Dezember 2014, 10:38:31 schrieb Boris Ostrovsky:
>> Version 16 of PV(H) PMU patches.
> Hi Boris,
>
> I did a fast and simple test on a small Intel machine and all went fine. I'll
> do some more after my vacation in 2015.

Thanks!

> After adapting your sent linux kernel patches I'am interestet in tracing our
> HVM guest from outside with perf. Are you already having some patches and would
> you share these?

I have Linux patches that I will (re-)post as soon as we are done with 
the hypervisor part . They are pretty close to what they used be last 
time I posted them, save for the interface changes. I can send them to 
you if you want.

For the toolstack it's a bit more complicated: I have patches that will 
apply to (I think) 3.16 or 3.17 but not to the latest tree --- there is 
huge amount of churn there and I gave up for now trying to chase them. 
OTOH, since the interfaces are (or appear to be) stable the binary from 
early tree works fine on the mainline.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 15:47:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dIB-0007CW-Fb; Thu, 18 Dec 2014 15:47:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Y1dI9-0007CR-UU
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:47:06 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E7/59-09284-9F6F2945; Thu, 18 Dec 2014 15:47:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418917623!14385316!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 10947 invoked from network); 18 Dec 2014 15:47:04 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 15:47:04 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Y1dHp-000MxX-Ij; Thu, 18 Dec 2014 15:46:45 +0000
Date: Thu, 18 Dec 2014 16:46:45 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141218154645.GC67264@deinos.phlegethon.org>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.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: keir@xen.org, Xen-devel@lists.xen.org, Paul.Durrant@citrix.com, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	David Vrabel <david.vrabel@citrix.com>, JBeulich@suse.com,
	Malcolm Crossley <malcolm.crossley@citrix.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 07:24 +0000 on 12 Dec (1418365491), Tian, Kevin wrote:
> > I'm afraid not.  There's nothing worrying per se in a backend knowing
> > the MFNs of the pages -- the worry is that the backend can pass the
> > MFNs to hardware.  If the check happens only at lookup time, then XenGT
> > can (either through a bug or a security breach) just pass _any_ MFN to
> > the GPU for DMA.
> > 
> > But even without considering the security aspects, this model has bugs
> > that may be impossible for XenGT itself to even detect.  E.g.:
> >  1. Guest asks its virtual GPU to DMA to a frame of memory;
> >  2. XenGT looks up the GFN->MFN mapping;
> >  3. Guest balloons out the page;
> >  4. Xen allocates the page to a different guest;
> >  5. XenGT passes the MFN to the GPU, which DMAs to it.
> > 
> > Whereas if stage 2 is a _mapping_ operation, Xen can refcount the
> > underlying memory and make sure it doesn't get reallocated until XenGT
> > is finished with it.
> 
> yes, I see your point. Now we can't support ballooning in VM given above
> reason, and refcnt is required to close that gap.
> 
> but just to confirm one point. from my understanding whether it's a 
> mapping operation doesn't really matter. We can invent an interface
> to get p2m mapping and then increase refcnt. the key is refcnt here.
> when XenGT constructs a shadow GPU page table, it creates a reference
> to guest memory page so the refcnt must be increased. :-)

True. :)  But Xen does need to remember all the refcounts that were
created (so it can tidy up if the domain crashes).  If Xen is already
doing that it might as well do it in the IOMMU tables since that
solves other problems.

> > [First some hopefully-helpful diagrams to explain my thinking.  I'll
> >  borrow 'BFN' from Malcolm's discussion of IOMMUs to describe the
> >  addresses that devices issue their DMAs in:
> 
> what's 'BFN' short for? Bus Frame Number?

Yes, I think so.

> > If we replace that lookup with a _map_ hypercall, either with Xen
> > choosing the BFN (as happens in the PV grant map operation) or with
> > the guest choosing an unused address (as happens in the HVM/PVH
> > grant map operation), then:
> >  - the only extra code in XenGT itself is that you need to unmap
> >    when you change the GTT;
> >  - Xen can track and control exactly which MFNs XenGT/the GPU can access;
> >  - running XenGT in a driver domain or PVH dom0 ought to work; and
> >  - we fix the race condition I described above.
> 
> ok, I see your point here. It does sound like a better design to meet
> Xen hypervisor's security requirement and can also work with PVH
> Dom0 or driver domain. Previously even when we said a MFN is
> required, it's actually a BFN due to IOMMU existence, and it works
> just because we have a 1:1 identity mapping in-place. And by finding
> a BFN
> 
> some follow-up think here:
> 
> - one extra unmap call will have some performance impact, especially
> for media processing workloads where GPU page table modifications
> are hot. but suppose this can be optimized with batch request

Yep.  In general I'd hope that the extra overhead of unmap is small
compared with the trap + emulate + ioreq + schedule that's just
happened.  Though I know that IOTLB shootdowns are potentially rather
expensive right now so it might want some measurement.

> - is there existing _map_ call for this purpose per your knowledge, or
> a new one is required? If the latter, what's the additional logic to be
> implemented there?

For PVH, the XENMEM_add_to_physmap (gmfn_foreign) path ought to do
what you need, I think.  For PV, I think we probably need a new map
operation with sensible semantics.  My inclination would be to have it
follow the grant-map semantics (i.e. caller supplies domid + gfn,
hypervisor supplies BFN and success/failure code). 

Malcolm might have opinions about this -- it starts looking like the
sort of PV IOMMU interface he's suggested before. 

> - when you say _map_, do you expect this mapped into dom0's virtual
> address space, or just guest physical space?

For PVH, I mean into guest physical address space (and iommu tables,
since those are the same).  For PV, I mean just the IOMMU tables --
since the guest controls its own PFN space entirely there's nothing
Xen can to map things into it.

> - how is BFN or unused address (what do you mean by address here?)
> allocated? does it need present in guest physical memory at boot time,
> or just finding some holes?

That's really a question for the xen maintainers in the linux kernel.
I presume that whatever bookkeeping they currently do for grant-mapped
memory would suffice here just as well.

> - graphics memory size could be large. starting from BDW, there'll
> be 64bit page table format. Do you see any limitation here on finding
> BFN or address?

Not really.  The IOMMU tables are also 64-bit so there must be enough
addresses to map all of RAM.  There shouldn't be any need for these
mappings to be _contiguous_, btw.  You just need to have one free
address for each mapping.  Again, following how grant maps work, I'd
imagine that PVH guests will allocate an unused GFN for each mapping
and do enough bookkeeping to make sure they don't clash with other GFN
users (grant mapping, ballooning, &c).  PV guests will probably be
given a BFN by the hypervisor at map time (which will be == MFN in
practice) and just needs to pass the same BFN to the unmap call later
(it can store it in the GTT meanwhile).

> > The default policy I'm suggesting is that the XenGT backend domain
> > should be marked IS_PRIV_FOR (or similar) over the XenGT client VMs,
> > which will need a small extension in Xen since at the moment struct
> > domain has only one "target" field.
> 
> Is that connection setup by toolstack or by hypervisor today?

It's set up by the toolstack using XEN_DOMCTL_set_target.  Extending
that to something like XEN_DOMCTL_set_target_list would be OK, I
think, along with some sort of lookup call.  Or maybe an
add_target/remove_target pair would be easier?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 15:47:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dIY-0007Do-T6; Thu, 18 Dec 2014 15:47:30 +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 1Y1dIX-0007Da-1Y
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:47:29 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	59/B9-05632-017F2945; Thu, 18 Dec 2014 15:47:28 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418917646!14417310!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10526 invoked from network); 18 Dec 2014 15:47:27 -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; 18 Dec 2014 15:47:27 -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 sBIFlIvY009625
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Dec 2014 15:47:18 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
	sBIFlHMf004886
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 18 Dec 2014 15:47:17 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
	sBIFlHLx004875; Thu, 18 Dec 2014 15:47:17 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, 18 Dec 2014 07:47:16 -0800
Message-ID: <5492F780.3050207@oracle.com>
Date: Thu, 18 Dec 2014 10:49:20 -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: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<2653567.YPYbLMrP7N@amur>
In-Reply-To: <2653567.YPYbLMrP7N@amur>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kevin.tian@intel.com, JBeulich@suse.com, jun.nakajima@intel.com,
	andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	Aravind.Gopalakrishnan@amd.com, suravee.suthikulpanit@amd.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH v16 00/23] 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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/18/2014 07:15 AM, Dietmar Hahn wrote:
> Am Mittwoch 17 Dezember 2014, 10:38:31 schrieb Boris Ostrovsky:
>> Version 16 of PV(H) PMU patches.
> Hi Boris,
>
> I did a fast and simple test on a small Intel machine and all went fine. I'll
> do some more after my vacation in 2015.

Thanks!

> After adapting your sent linux kernel patches I'am interestet in tracing our
> HVM guest from outside with perf. Are you already having some patches and would
> you share these?

I have Linux patches that I will (re-)post as soon as we are done with 
the hypervisor part . They are pretty close to what they used be last 
time I posted them, save for the interface changes. I can send them to 
you if you want.

For the toolstack it's a bit more complicated: I have patches that will 
apply to (I think) 3.16 or 3.17 but not to the latest tree --- there is 
huge amount of churn there and I gave up for now trying to chase them. 
OTOH, since the interfaces are (or appear to be) stable the binary from 
early tree works fine on the mainline.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 15:47:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dIB-0007CW-Fb; Thu, 18 Dec 2014 15:47:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Y1dI9-0007CR-UU
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 15:47:06 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	E7/59-09284-9F6F2945; Thu, 18 Dec 2014 15:47:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418917623!14385316!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 10947 invoked from network); 18 Dec 2014 15:47:04 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 15:47:04 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Y1dHp-000MxX-Ij; Thu, 18 Dec 2014 15:46:45 +0000
Date: Thu, 18 Dec 2014 16:46:45 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141218154645.GC67264@deinos.phlegethon.org>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211164632.GF53811@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1261182F4@SHSMSX101.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: keir@xen.org, Xen-devel@lists.xen.org, Paul.Durrant@citrix.com, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	David Vrabel <david.vrabel@citrix.com>, JBeulich@suse.com,
	Malcolm Crossley <malcolm.crossley@citrix.com>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 07:24 +0000 on 12 Dec (1418365491), Tian, Kevin wrote:
> > I'm afraid not.  There's nothing worrying per se in a backend knowing
> > the MFNs of the pages -- the worry is that the backend can pass the
> > MFNs to hardware.  If the check happens only at lookup time, then XenGT
> > can (either through a bug or a security breach) just pass _any_ MFN to
> > the GPU for DMA.
> > 
> > But even without considering the security aspects, this model has bugs
> > that may be impossible for XenGT itself to even detect.  E.g.:
> >  1. Guest asks its virtual GPU to DMA to a frame of memory;
> >  2. XenGT looks up the GFN->MFN mapping;
> >  3. Guest balloons out the page;
> >  4. Xen allocates the page to a different guest;
> >  5. XenGT passes the MFN to the GPU, which DMAs to it.
> > 
> > Whereas if stage 2 is a _mapping_ operation, Xen can refcount the
> > underlying memory and make sure it doesn't get reallocated until XenGT
> > is finished with it.
> 
> yes, I see your point. Now we can't support ballooning in VM given above
> reason, and refcnt is required to close that gap.
> 
> but just to confirm one point. from my understanding whether it's a 
> mapping operation doesn't really matter. We can invent an interface
> to get p2m mapping and then increase refcnt. the key is refcnt here.
> when XenGT constructs a shadow GPU page table, it creates a reference
> to guest memory page so the refcnt must be increased. :-)

True. :)  But Xen does need to remember all the refcounts that were
created (so it can tidy up if the domain crashes).  If Xen is already
doing that it might as well do it in the IOMMU tables since that
solves other problems.

> > [First some hopefully-helpful diagrams to explain my thinking.  I'll
> >  borrow 'BFN' from Malcolm's discussion of IOMMUs to describe the
> >  addresses that devices issue their DMAs in:
> 
> what's 'BFN' short for? Bus Frame Number?

Yes, I think so.

> > If we replace that lookup with a _map_ hypercall, either with Xen
> > choosing the BFN (as happens in the PV grant map operation) or with
> > the guest choosing an unused address (as happens in the HVM/PVH
> > grant map operation), then:
> >  - the only extra code in XenGT itself is that you need to unmap
> >    when you change the GTT;
> >  - Xen can track and control exactly which MFNs XenGT/the GPU can access;
> >  - running XenGT in a driver domain or PVH dom0 ought to work; and
> >  - we fix the race condition I described above.
> 
> ok, I see your point here. It does sound like a better design to meet
> Xen hypervisor's security requirement and can also work with PVH
> Dom0 or driver domain. Previously even when we said a MFN is
> required, it's actually a BFN due to IOMMU existence, and it works
> just because we have a 1:1 identity mapping in-place. And by finding
> a BFN
> 
> some follow-up think here:
> 
> - one extra unmap call will have some performance impact, especially
> for media processing workloads where GPU page table modifications
> are hot. but suppose this can be optimized with batch request

Yep.  In general I'd hope that the extra overhead of unmap is small
compared with the trap + emulate + ioreq + schedule that's just
happened.  Though I know that IOTLB shootdowns are potentially rather
expensive right now so it might want some measurement.

> - is there existing _map_ call for this purpose per your knowledge, or
> a new one is required? If the latter, what's the additional logic to be
> implemented there?

For PVH, the XENMEM_add_to_physmap (gmfn_foreign) path ought to do
what you need, I think.  For PV, I think we probably need a new map
operation with sensible semantics.  My inclination would be to have it
follow the grant-map semantics (i.e. caller supplies domid + gfn,
hypervisor supplies BFN and success/failure code). 

Malcolm might have opinions about this -- it starts looking like the
sort of PV IOMMU interface he's suggested before. 

> - when you say _map_, do you expect this mapped into dom0's virtual
> address space, or just guest physical space?

For PVH, I mean into guest physical address space (and iommu tables,
since those are the same).  For PV, I mean just the IOMMU tables --
since the guest controls its own PFN space entirely there's nothing
Xen can to map things into it.

> - how is BFN or unused address (what do you mean by address here?)
> allocated? does it need present in guest physical memory at boot time,
> or just finding some holes?

That's really a question for the xen maintainers in the linux kernel.
I presume that whatever bookkeeping they currently do for grant-mapped
memory would suffice here just as well.

> - graphics memory size could be large. starting from BDW, there'll
> be 64bit page table format. Do you see any limitation here on finding
> BFN or address?

Not really.  The IOMMU tables are also 64-bit so there must be enough
addresses to map all of RAM.  There shouldn't be any need for these
mappings to be _contiguous_, btw.  You just need to have one free
address for each mapping.  Again, following how grant maps work, I'd
imagine that PVH guests will allocate an unused GFN for each mapping
and do enough bookkeeping to make sure they don't clash with other GFN
users (grant mapping, ballooning, &c).  PV guests will probably be
given a BFN by the hypervisor at map time (which will be == MFN in
practice) and just needs to pass the same BFN to the unmap call later
(it can store it in the GTT meanwhile).

> > The default policy I'm suggesting is that the XenGT backend domain
> > should be marked IS_PRIV_FOR (or similar) over the XenGT client VMs,
> > which will need a small extension in Xen since at the moment struct
> > domain has only one "target" field.
> 
> Is that connection setup by toolstack or by hypervisor today?

It's set up by the toolstack using XEN_DOMCTL_set_target.  Extending
that to something like XEN_DOMCTL_set_target_list would be OK, I
think, along with some sort of lookup call.  Or maybe an
add_target/remove_target pair would be easier?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 15:56:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:56:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dR4-0007rH-0j; Thu, 18 Dec 2014 15:56:18 +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 1Y1dR2-0007rC-8g
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 15:56:16 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A6/81-17735-C19F2945; Thu, 18 Dec 2014 15:56:12 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418918171!14378539!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14082 invoked from network); 18 Dec 2014 15:56:12 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 15:56:11 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so2024669wgh.31
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 07:56: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=Qo6p8WMvVhUWY7YTuz+01DUVtyr1gOUckiw0Cf/GoEA=;
	b=Caf/G7rLIcJYCuzAlfhpT+B3i74OoSgxQjJFm5lly4XD3PFpXgabLmBPn1TkPOZmo3
	+ec/KyApgvBCEuWZZb7dt9lnSIF49oJV8DAybS4kwWW+EK5AXPZqBU2mkpywflNw7KLh
	1UIZEZM2gsR9L3O5A+nINuq0KM8p8qKA0AZTgxEdNNwRbwp8LTf+66CwNGm1lbc0z6+P
	6KVhlLX/W0Ka3+Z6QttpqM3T+dQ+cHulvzVafTsOxQsbxzF1cm3qFroRZG9e2OhoYSgV
	9YV4efVfaHmnzOnyLg4JXUyAzZjxxImCaGm5WagDR/O7HJp56jCo0ge9EvZ6dWJSEmDo
	pnog==
X-Gm-Message-State: ALoCoQmZbWWftrkVDjUG9+WEVhqgEpmZrA4z1wgT8WUyXWSMEKXglnIfprkTEtXFzWYkpOYpPYnU
X-Received: by 10.180.104.9 with SMTP id ga9mr26184462wib.9.1418918171407;
	Thu, 18 Dec 2014 07:56:11 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([82.98.7.133])
	by mx.google.com with ESMTPSA id
	eu15sm10428143wid.18.2014.12.18.07.56.09
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 07:56:10 -0800 (PST)
Message-ID: <5492F919.2010701@linaro.org>
Date: Thu, 18 Dec 2014 15:56: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.3.0
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
	<54915B3E.4010702@linaro.org>
	<54916CFA020000780005032F@mail.emea.novell.com>
	<54917F29.8070901@linaro.org>
	<5491BAB902000078000C40C6@mail.emea.novell.com>
In-Reply-To: <5491BAB902000078000C40C6@mail.emea.novell.com>
Cc: keir@xen.org, ian.campbell@citrix.com, manish.jaggi@caviumnetworks.com,
	tim@xen.org, stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 17/12/2014 17:17, Jan Beulich wrote:
>>>> Julien Grall <julien.grall@linaro.org> 12/17/14 2:04 PM >>>
>> On 17/12/14 10:46, Jan Beulich wrote:
>>>>>> On 17.12.14 at 11:30, <julien.grall@linaro.org> wrote:
>>>> Having a generic way to describe device will really help ARM code (see
>>>> IOMMU).
>>>>
>>>> If we don't have a such thing, we may need to duplicate quite a lots of
>>>> code. Which will make hard to maintain.
>>>
>>> Not really, if e.g. "device" was simply an alias of "pci_dev" on x86.
>>
>> How many pci_dev instance you could have on a platform? 1000? Though it
>> might be a high value but that mean we use 2k more of RAM.
>
> Sure the total amount isn't big. But these days everyone thinks that way, and
> data size gets grown without much consideration. And you shouldn't just think
> about RAM cache utilization.

I will go ahead with the aliasing.

>> It doesn't seem to bad for the benefit to have a clear code.
>
> Aliasing device and pci_dev for x86 would yield similar clarity afaict.

To be sure, by aliasing you mean creating a typedef?

For x86:
typedef struct pci_dev device_t;

And for ARM:
typedef struct device device_t;

>
>>>>>> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
>>>>>> +
>>>>>> +static inline struct pci_dev *dev_to_pci(struct device *dev)
>>>>>> +{
>>>>>> +    ASSERT(dev->type == DEV_PCI);
>>>>>> +
>>>>>> +    return container_of(dev, struct pci_dev, dev);
>>>>>> +}
>>>>>
>>>>> While the former is const-correct, I dislike the inability of passing
>>>>> pointers to const into helper functions like the latter. I can't think
>>>>> of a good solution other than introducing a second const variant
>>>>> of it, but I suppose we should try to find alternatives before
>>>>> adding such a construct that moves us in a direction opposite to
>>>>> getting our code more const-correct.
>>>>
>>>> Oh right. I didn't though about that case. I will turn this inline
>>>> function into a macro.
>>>
>>> I'm afraid that won't help, as you still need to specify a type as
>>> 2nd argument to container_of(), and that type can't be both
>>> const and non-const at the same time, i.e. you can't easily
>>> inherit the const-ness of the passed in pointer.
>>
>> I agree that we will drop the const-ness. But is it really an issue?
>>
>> We won't have many place where we don't want to modify the pci_dev.
>
> Did you check (including places where const could be added)? But at least
> you didn't have to drop and const-s, so I'm not heavily objecting the change
> you propose.

The only usage will be in the IOMMU code where most of the time we 
require a non const version.

At least on the SMMU driver, we have to store data per-device. This is 
to know what is the SMMU master for this device.

-- 
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 Dec 18 15:56:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:56:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dR4-0007rH-0j; Thu, 18 Dec 2014 15:56:18 +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 1Y1dR2-0007rC-8g
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 15:56:16 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A6/81-17735-C19F2945; Thu, 18 Dec 2014 15:56:12 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418918171!14378539!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14082 invoked from network); 18 Dec 2014 15:56:12 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 15:56:11 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so2024669wgh.31
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 07:56: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=Qo6p8WMvVhUWY7YTuz+01DUVtyr1gOUckiw0Cf/GoEA=;
	b=Caf/G7rLIcJYCuzAlfhpT+B3i74OoSgxQjJFm5lly4XD3PFpXgabLmBPn1TkPOZmo3
	+ec/KyApgvBCEuWZZb7dt9lnSIF49oJV8DAybS4kwWW+EK5AXPZqBU2mkpywflNw7KLh
	1UIZEZM2gsR9L3O5A+nINuq0KM8p8qKA0AZTgxEdNNwRbwp8LTf+66CwNGm1lbc0z6+P
	6KVhlLX/W0Ka3+Z6QttpqM3T+dQ+cHulvzVafTsOxQsbxzF1cm3qFroRZG9e2OhoYSgV
	9YV4efVfaHmnzOnyLg4JXUyAzZjxxImCaGm5WagDR/O7HJp56jCo0ge9EvZ6dWJSEmDo
	pnog==
X-Gm-Message-State: ALoCoQmZbWWftrkVDjUG9+WEVhqgEpmZrA4z1wgT8WUyXWSMEKXglnIfprkTEtXFzWYkpOYpPYnU
X-Received: by 10.180.104.9 with SMTP id ga9mr26184462wib.9.1418918171407;
	Thu, 18 Dec 2014 07:56:11 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([82.98.7.133])
	by mx.google.com with ESMTPSA id
	eu15sm10428143wid.18.2014.12.18.07.56.09
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 07:56:10 -0800 (PST)
Message-ID: <5492F919.2010701@linaro.org>
Date: Thu, 18 Dec 2014 15:56: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.3.0
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
	<54915B3E.4010702@linaro.org>
	<54916CFA020000780005032F@mail.emea.novell.com>
	<54917F29.8070901@linaro.org>
	<5491BAB902000078000C40C6@mail.emea.novell.com>
In-Reply-To: <5491BAB902000078000C40C6@mail.emea.novell.com>
Cc: keir@xen.org, ian.campbell@citrix.com, manish.jaggi@caviumnetworks.com,
	tim@xen.org, stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan,

On 17/12/2014 17:17, Jan Beulich wrote:
>>>> Julien Grall <julien.grall@linaro.org> 12/17/14 2:04 PM >>>
>> On 17/12/14 10:46, Jan Beulich wrote:
>>>>>> On 17.12.14 at 11:30, <julien.grall@linaro.org> wrote:
>>>> Having a generic way to describe device will really help ARM code (see
>>>> IOMMU).
>>>>
>>>> If we don't have a such thing, we may need to duplicate quite a lots of
>>>> code. Which will make hard to maintain.
>>>
>>> Not really, if e.g. "device" was simply an alias of "pci_dev" on x86.
>>
>> How many pci_dev instance you could have on a platform? 1000? Though it
>> might be a high value but that mean we use 2k more of RAM.
>
> Sure the total amount isn't big. But these days everyone thinks that way, and
> data size gets grown without much consideration. And you shouldn't just think
> about RAM cache utilization.

I will go ahead with the aliasing.

>> It doesn't seem to bad for the benefit to have a clear code.
>
> Aliasing device and pci_dev for x86 would yield similar clarity afaict.

To be sure, by aliasing you mean creating a typedef?

For x86:
typedef struct pci_dev device_t;

And for ARM:
typedef struct device device_t;

>
>>>>>> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
>>>>>> +
>>>>>> +static inline struct pci_dev *dev_to_pci(struct device *dev)
>>>>>> +{
>>>>>> +    ASSERT(dev->type == DEV_PCI);
>>>>>> +
>>>>>> +    return container_of(dev, struct pci_dev, dev);
>>>>>> +}
>>>>>
>>>>> While the former is const-correct, I dislike the inability of passing
>>>>> pointers to const into helper functions like the latter. I can't think
>>>>> of a good solution other than introducing a second const variant
>>>>> of it, but I suppose we should try to find alternatives before
>>>>> adding such a construct that moves us in a direction opposite to
>>>>> getting our code more const-correct.
>>>>
>>>> Oh right. I didn't though about that case. I will turn this inline
>>>> function into a macro.
>>>
>>> I'm afraid that won't help, as you still need to specify a type as
>>> 2nd argument to container_of(), and that type can't be both
>>> const and non-const at the same time, i.e. you can't easily
>>> inherit the const-ness of the passed in pointer.
>>
>> I agree that we will drop the const-ness. But is it really an issue?
>>
>> We won't have many place where we don't want to modify the pci_dev.
>
> Did you check (including places where const could be added)? But at least
> you didn't have to drop and const-s, so I'm not heavily objecting the change
> you propose.

The only usage will be in the IOMMU code where most of the time we 
require a non const version.

At least on the SMMU driver, we have to store data per-device. This is 
to know what is the SMMU master for this device.

-- 
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 Dec 18 15:59:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:59:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dTa-0007xz-Nk; Thu, 18 Dec 2014 15:58:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Y1dTZ-0007xu-Ns
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 15:58:53 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	D9/17-02697-DB9F2945; Thu, 18 Dec 2014 15:58:53 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418918332!8868865!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3798 invoked from network); 18 Dec 2014 15:58:52 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 15:58:52 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so1993549wgh.40
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 07:58: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=f2cZpQXGvHTNWKQ5feNtNO6bVco6K2kz0UMNK7ncto8=;
	b=Mw3JvaRo0kFr7BWt5G2wcRny7opa/6Nf0s23SyYFcGZxVWv/vQWYFdtVc3n8JyLl3C
	sprWNqssT3CSGWRociUHI9KT2OMgUZjmaOj76+ND+wGzudFNiWnSiwGMbGkto4IZthhR
	JQHEf3Rlp0bRXMlXC5jkeLvn+w/YajsF6AdxUJUnLjL+TjxBG7s/2C5x6nmNlYsHFzvN
	CqPZB2SN8ozFICvVgaHvpAFQbb5RwTT8Cm9G5OV5XNS1gkzi0v0e0ZuQEGHrLXVtZdRo
	UH51WuAxQ8M3M79leYpGCnzvNrFD0T5ENXMVBQ+XDvgiICm/YnTs+6ukNrA6UXzXFoSa
	OkZw==
X-Gm-Message-State: ALoCoQmmM5YU2JCg6EM8wLrHMnuy+AzIk4uuA3JVadJ9oPE1M1cFarfrIcdjiGYfzDMjuan3R4pS
X-Received: by 10.180.73.108 with SMTP id k12mr6480937wiv.24.1418918332257;
	Thu, 18 Dec 2014 07:58:52 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([82.98.7.133])
	by mx.google.com with ESMTPSA id
	a14sm25237369wib.22.2014.12.18.07.58.50
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 07:58:51 -0800 (PST)
Message-ID: <5492F9BA.9090709@linaro.org>
Date: Thu, 18 Dec 2014 15:58:50 +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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>	<1418760534-18163-4-git-send-email-julien.grall@linaro.org>	<5491636F020000780005027B@mail.emea.novell.com>	<54917D1C.3080908@linaro.org>
	<5491B91802000078000C40B1@mail.emea.novell.com>
	<5491C2EE.4080603@citrix.com>
In-Reply-To: <5491C2EE.4080603@citrix.com>
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE
 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-Transfer-Encoding: 7bit
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 Andrew Cooper,

On 17/12/2014 17:52, Andrew Cooper wrote:
> On 17/12/14 17:10, Jan Beulich wrote:
>>>>> Julien Grall <julien.grall@linaro.org> 12/17/14 1:55 PM >>>
>>> On 17/12/14 10:05, Jan Beulich wrote:
>>>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>>>>> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
>>>> Any reason not to simply use {read,write}_atomic() instead, which we
>>>> already have?
>>> To avoid modifying Linux drivers when it's not necessary and doesn't harm.
>> I realize that's the motivation, but I also view it as problematic to have two
>> different constructs doing the same thing. Defining the new one in terms of
>> the existing ones doesn't seem possible (or else I would suggest that in
>> order for the connection to be obvious). We'll see what other maintainers
>> think...
>
> Personally, I find the semantics of ACCESS_ONCE() more intuitive than
> read/write_atomic(), and it is certainly more familiar to Linux developers.
>
> Furthermore, ACCESS_ONCE() doesn't force an mov instruction if the
> compiler can identify a better instruction to use.
>
> There are only a handful of user users of read/write_atomic().  It would
> not be hard to make a blanket switch, if we chose to go in that direction.

Do you mean replacing read/write_atomic() by

#define read_atomic(p) ACCESS_ONCE(p)
#define write_atomic(p, x) (ACCESS_ONCE(p) = x)

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 Dec 18 15:59:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:59:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dTa-0007xz-Nk; Thu, 18 Dec 2014 15:58:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Y1dTZ-0007xu-Ns
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 15:58:53 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	D9/17-02697-DB9F2945; Thu, 18 Dec 2014 15:58:53 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418918332!8868865!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3798 invoked from network); 18 Dec 2014 15:58:52 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 15:58:52 -0000
Received: by mail-wg0-f53.google.com with SMTP id l18so1993549wgh.40
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 07:58: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=f2cZpQXGvHTNWKQ5feNtNO6bVco6K2kz0UMNK7ncto8=;
	b=Mw3JvaRo0kFr7BWt5G2wcRny7opa/6Nf0s23SyYFcGZxVWv/vQWYFdtVc3n8JyLl3C
	sprWNqssT3CSGWRociUHI9KT2OMgUZjmaOj76+ND+wGzudFNiWnSiwGMbGkto4IZthhR
	JQHEf3Rlp0bRXMlXC5jkeLvn+w/YajsF6AdxUJUnLjL+TjxBG7s/2C5x6nmNlYsHFzvN
	CqPZB2SN8ozFICvVgaHvpAFQbb5RwTT8Cm9G5OV5XNS1gkzi0v0e0ZuQEGHrLXVtZdRo
	UH51WuAxQ8M3M79leYpGCnzvNrFD0T5ENXMVBQ+XDvgiICm/YnTs+6ukNrA6UXzXFoSa
	OkZw==
X-Gm-Message-State: ALoCoQmmM5YU2JCg6EM8wLrHMnuy+AzIk4uuA3JVadJ9oPE1M1cFarfrIcdjiGYfzDMjuan3R4pS
X-Received: by 10.180.73.108 with SMTP id k12mr6480937wiv.24.1418918332257;
	Thu, 18 Dec 2014 07:58:52 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([82.98.7.133])
	by mx.google.com with ESMTPSA id
	a14sm25237369wib.22.2014.12.18.07.58.50
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 07:58:51 -0800 (PST)
Message-ID: <5492F9BA.9090709@linaro.org>
Date: Thu, 18 Dec 2014 15:58:50 +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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>	<1418760534-18163-4-git-send-email-julien.grall@linaro.org>	<5491636F020000780005027B@mail.emea.novell.com>	<54917D1C.3080908@linaro.org>
	<5491B91802000078000C40B1@mail.emea.novell.com>
	<5491C2EE.4080603@citrix.com>
In-Reply-To: <5491C2EE.4080603@citrix.com>
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE
 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-Transfer-Encoding: 7bit
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 Andrew Cooper,

On 17/12/2014 17:52, Andrew Cooper wrote:
> On 17/12/14 17:10, Jan Beulich wrote:
>>>>> Julien Grall <julien.grall@linaro.org> 12/17/14 1:55 PM >>>
>>> On 17/12/14 10:05, Jan Beulich wrote:
>>>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>>>>> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
>>>> Any reason not to simply use {read,write}_atomic() instead, which we
>>>> already have?
>>> To avoid modifying Linux drivers when it's not necessary and doesn't harm.
>> I realize that's the motivation, but I also view it as problematic to have two
>> different constructs doing the same thing. Defining the new one in terms of
>> the existing ones doesn't seem possible (or else I would suggest that in
>> order for the connection to be obvious). We'll see what other maintainers
>> think...
>
> Personally, I find the semantics of ACCESS_ONCE() more intuitive than
> read/write_atomic(), and it is certainly more familiar to Linux developers.
>
> Furthermore, ACCESS_ONCE() doesn't force an mov instruction if the
> compiler can identify a better instruction to use.
>
> There are only a handful of user users of read/write_atomic().  It would
> not be hard to make a blanket switch, if we chose to go in that direction.

Do you mean replacing read/write_atomic() by

#define read_atomic(p) ACCESS_ONCE(p)
#define write_atomic(p, x) (ACCESS_ONCE(p) = x)

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 Dec 18 15:59:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:59:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dTk-0007zE-9H; Thu, 18 Dec 2014 15:59:04 +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 1Y1dTi-0007yl-5U
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 15:59:02 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	FE/70-01660-5C9F2945; Thu, 18 Dec 2014 15:59:01 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418918340!8868900!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4602 invoked from network); 18 Dec 2014 15:59:01 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 15:59:01 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so2244142wiw.14
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 07:59: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=2QDm4tIhLwqCR7COoSIJUu9RzgsCDvIK0ZxwPKcZxX8=;
	b=hUF2A0RXMJhGP3J/vZAXumlnE+qMRx9sIoSbsiU0/9kKnI7fyWTT3B1COZezBK6i5s
	W+w829mpGka69zLLuyzC1dUDXcLBK0C2PnOOSZJl8A/xketgBQkMw9wtcur94y4CxpoQ
	bfAI2h2SshqcESZYZEBk3367peJ6q0z31ACdQSl00KFUm0ggnTkrr6IAnNAo2XLyx+Au
	Lt844bi/cIPp7Sy8MJcstbN4UYvdI1wW7sVTeUo8F/QMC67pGtn41vRklxtZqBfI5KzX
	2ljeI0CYWWn6CevH8ERY9yP8+2nkK4rSdwcb8bKt1Y/mC2fJpX5HEpWrUkJXDOsL++AZ
	p/GQ==
X-Gm-Message-State: ALoCoQnodR336Otak6CMBbqZl+OQraa5SUN8ZwRDbLbmUD7xs0OEumtswwWkiksqbw4rw+Ltpf3J
X-Received: by 10.194.109.201 with SMTP id hu9mr5681602wjb.45.1418918340262;
	Thu, 18 Dec 2014 07:59:00 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([82.98.7.133])
	by mx.google.com with ESMTPSA id wa5sm9429568wjc.8.2014.12.18.07.58.58
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 07:58:59 -0800 (PST)
Message-ID: <5492F9C0.6090505@linaro.org>
Date: Thu, 18 Dec 2014 15:58:56 +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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>	<1418760534-18163-4-git-send-email-julien.grall@linaro.org>	<5491636F020000780005027B@mail.emea.novell.com>	<54917D1C.3080908@linaro.org>
	<5491B91802000078000C40B1@mail.emea.novell.com>
	<5491C2EE.4080603@citrix.com>
In-Reply-To: <5491C2EE.4080603@citrix.com>
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE
 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-Transfer-Encoding: 7bit
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 Andrew,

On 17/12/2014 17:52, Andrew Cooper wrote:
> On 17/12/14 17:10, Jan Beulich wrote:
>>>>> Julien Grall <julien.grall@linaro.org> 12/17/14 1:55 PM >>>
>>> On 17/12/14 10:05, Jan Beulich wrote:
>>>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>>>>> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
>>>> Any reason not to simply use {read,write}_atomic() instead, which we
>>>> already have?
>>> To avoid modifying Linux drivers when it's not necessary and doesn't harm.
>> I realize that's the motivation, but I also view it as problematic to have two
>> different constructs doing the same thing. Defining the new one in terms of
>> the existing ones doesn't seem possible (or else I would suggest that in
>> order for the connection to be obvious). We'll see what other maintainers
>> think...
>
> Personally, I find the semantics of ACCESS_ONCE() more intuitive than
> read/write_atomic(), and it is certainly more familiar to Linux developers.
>
> Furthermore, ACCESS_ONCE() doesn't force an mov instruction if the
> compiler can identify a better instruction to use.
>
> There are only a handful of user users of read/write_atomic().  It would
> not be hard to make a blanket switch, if we chose to go in that direction.

Do you mean replacing read/write_atomic() by

#define read_atomic(p) ACCESS_ONCE(p)
#define write_atomic(p, x) (ACCESS_ONCE(p) = x)

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 Dec 18 15:59:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 15:59:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dTk-0007zE-9H; Thu, 18 Dec 2014 15:59:04 +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 1Y1dTi-0007yl-5U
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 15:59:02 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	FE/70-01660-5C9F2945; Thu, 18 Dec 2014 15:59:01 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418918340!8868900!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4602 invoked from network); 18 Dec 2014 15:59:01 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 15:59:01 -0000
Received: by mail-wi0-f175.google.com with SMTP id l15so2244142wiw.14
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 07:59: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=2QDm4tIhLwqCR7COoSIJUu9RzgsCDvIK0ZxwPKcZxX8=;
	b=hUF2A0RXMJhGP3J/vZAXumlnE+qMRx9sIoSbsiU0/9kKnI7fyWTT3B1COZezBK6i5s
	W+w829mpGka69zLLuyzC1dUDXcLBK0C2PnOOSZJl8A/xketgBQkMw9wtcur94y4CxpoQ
	bfAI2h2SshqcESZYZEBk3367peJ6q0z31ACdQSl00KFUm0ggnTkrr6IAnNAo2XLyx+Au
	Lt844bi/cIPp7Sy8MJcstbN4UYvdI1wW7sVTeUo8F/QMC67pGtn41vRklxtZqBfI5KzX
	2ljeI0CYWWn6CevH8ERY9yP8+2nkK4rSdwcb8bKt1Y/mC2fJpX5HEpWrUkJXDOsL++AZ
	p/GQ==
X-Gm-Message-State: ALoCoQnodR336Otak6CMBbqZl+OQraa5SUN8ZwRDbLbmUD7xs0OEumtswwWkiksqbw4rw+Ltpf3J
X-Received: by 10.194.109.201 with SMTP id hu9mr5681602wjb.45.1418918340262;
	Thu, 18 Dec 2014 07:59:00 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([82.98.7.133])
	by mx.google.com with ESMTPSA id wa5sm9429568wjc.8.2014.12.18.07.58.58
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 07:58:59 -0800 (PST)
Message-ID: <5492F9C0.6090505@linaro.org>
Date: Thu, 18 Dec 2014 15:58:56 +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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>	<1418760534-18163-4-git-send-email-julien.grall@linaro.org>	<5491636F020000780005027B@mail.emea.novell.com>	<54917D1C.3080908@linaro.org>
	<5491B91802000078000C40B1@mail.emea.novell.com>
	<5491C2EE.4080603@citrix.com>
In-Reply-To: <5491C2EE.4080603@citrix.com>
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	manish.jaggi@caviumnetworks.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE
 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-Transfer-Encoding: 7bit
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 Andrew,

On 17/12/2014 17:52, Andrew Cooper wrote:
> On 17/12/14 17:10, Jan Beulich wrote:
>>>>> Julien Grall <julien.grall@linaro.org> 12/17/14 1:55 PM >>>
>>> On 17/12/14 10:05, Jan Beulich wrote:
>>>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>>>>> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
>>>> Any reason not to simply use {read,write}_atomic() instead, which we
>>>> already have?
>>> To avoid modifying Linux drivers when it's not necessary and doesn't harm.
>> I realize that's the motivation, but I also view it as problematic to have two
>> different constructs doing the same thing. Defining the new one in terms of
>> the existing ones doesn't seem possible (or else I would suggest that in
>> order for the connection to be obvious). We'll see what other maintainers
>> think...
>
> Personally, I find the semantics of ACCESS_ONCE() more intuitive than
> read/write_atomic(), and it is certainly more familiar to Linux developers.
>
> Furthermore, ACCESS_ONCE() doesn't force an mov instruction if the
> compiler can identify a better instruction to use.
>
> There are only a handful of user users of read/write_atomic().  It would
> not be hard to make a blanket switch, if we chose to go in that direction.

Do you mean replacing read/write_atomic() by

#define read_atomic(p) ACCESS_ONCE(p)
#define write_atomic(p, x) (ACCESS_ONCE(p) = x)

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 Dec 18 16:03:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:03:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dXB-0000cz-3t; Thu, 18 Dec 2014 16: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 1Y1dX9-0000cr-Rz
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 16:02:35 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	B3/38-27785-B9AF2945; Thu, 18 Dec 2014 16:02:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418918554!15989235!1
X-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 15177 invoked from network); 18 Dec 2014 16:02:34 -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; 18 Dec 2014 16:02:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 16:02:33 +0000
Message-Id: <549308A90200007800050BF8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 16:02:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
	<54915B3E.4010702@linaro.org>
	<54916CFA020000780005032F@mail.emea.novell.com>
	<54917F29.8070901@linaro.org>
	<5491BAB902000078000C40C6@mail.emea.novell.com>
	<5492F919.2010701@linaro.org>
In-Reply-To: <5492F919.2010701@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, manish.jaggi@caviumnetworks.com,
	tim@xen.org, stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe 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.12.14 at 16:56, <julien.grall@linaro.org> wrote:
> On 17/12/2014 17:17, Jan Beulich wrote:
>> Aliasing device and pci_dev for x86 would yield similar clarity afaict.
> 
> To be sure, by aliasing you mean creating a typedef?
> 
> For x86:
> typedef struct pci_dev device_t;
> 
> And for ARM:
> typedef struct device device_t;

Yes, I think that's the only reasonable thing. Using a #define would
seem ugly no matter which direction you did 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 Dec 18 16:03:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:03:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dXB-0000cz-3t; Thu, 18 Dec 2014 16: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 1Y1dX9-0000cr-Rz
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 16:02:35 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	B3/38-27785-B9AF2945; Thu, 18 Dec 2014 16:02:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418918554!15989235!1
X-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 15177 invoked from network); 18 Dec 2014 16:02:34 -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; 18 Dec 2014 16:02:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 16:02:33 +0000
Message-Id: <549308A90200007800050BF8@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 16:02:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@linaro.org>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
	<54915B3E.4010702@linaro.org>
	<54916CFA020000780005032F@mail.emea.novell.com>
	<54917F29.8070901@linaro.org>
	<5491BAB902000078000C40C6@mail.emea.novell.com>
	<5492F919.2010701@linaro.org>
In-Reply-To: <5492F919.2010701@linaro.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, ian.campbell@citrix.com, manish.jaggi@caviumnetworks.com,
	tim@xen.org, stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe 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.12.14 at 16:56, <julien.grall@linaro.org> wrote:
> On 17/12/2014 17:17, Jan Beulich wrote:
>> Aliasing device and pci_dev for x86 would yield similar clarity afaict.
> 
> To be sure, by aliasing you mean creating a typedef?
> 
> For x86:
> typedef struct pci_dev device_t;
> 
> And for ARM:
> typedef struct device device_t;

Yes, I think that's the only reasonable thing. Using a #define would
seem ugly no matter which direction you did 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 Dec 18 16:07:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:07:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dbS-0000mV-G9; Thu, 18 Dec 2014 16:07:02 +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 1Y1dbQ-0000mQ-1L
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 16:07:00 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	A6/B0-25727-3ABF2945; Thu, 18 Dec 2014 16:06:59 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418918816!14430585!1
X-Originating-IP: [156.151.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 31494 invoked from network); 18 Dec 2014 16:06:58 -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 Dec 2014 16:06: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 sBIG6mjI010989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Dec 2014 16:06:49 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
	sBIG6kqk010084
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Dec 2014 16:06:47 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
	sBIG6jfj009823; Thu, 18 Dec 2014 16:06:46 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, 18 Dec 2014 08:06:45 -0800
Message-ID: <5492FC11.8010305@oracle.com>
Date: Thu, 18 Dec 2014 11:08: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: Jan Beulich <JBeulich@suse.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-3-git-send-email-boris.ostrovsky@oracle.com>
	<5492EE5C0200007800050AD9@mail.emea.novell.com>
In-Reply-To: <5492EE5C0200007800050AD9@mail.emea.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, 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 v16 02/23] x86/VPMU: Don't globally disable
 VPMU if initialization 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/18/2014 09:10 AM, Jan Beulich wrote:
>>>> On 17.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
>> The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
>> forever.
> Reported-by: Jan Beulich <jbeulich@suse.com>
> (or Suggested-by if you like that better)
>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>   xen/arch/x86/hvm/vpmu.c | 15 ++++++++-------
>>   1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
>> index 1df74c2..b43ea80 100644
>> --- a/xen/arch/x86/hvm/vpmu.c
>> +++ b/xen/arch/x86/hvm/vpmu.c
>> @@ -218,6 +218,7 @@ void vpmu_initialise(struct vcpu *v)
>>   {
>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>       uint8_t vendor = current_cpu_data.x86_vendor;
>> +    int ret;
>>   
>>       if ( is_pvh_vcpu(v) )
>>           return;
>> @@ -230,21 +231,21 @@ 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;
>> +        ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
>>           break;
>>   
>>       case X86_VENDOR_INTEL:
>> -        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>> -            opt_vpmu_enabled = 0;
>> +        ret = vmx_vpmu_initialise(v, opt_vpmu_enabled);
>>           break;
>>   
>>       default:
>> -        printk("VPMU: Initialization failed. "
>> -               "Unknown CPU vendor %d\n", vendor);
>> -        opt_vpmu_enabled = 0;
>> +        ret = -EINVAL;
>> +        printk(XENLOG_G_WARNING "VPMU: Unknown CPU vendor %d\n", vendor);
>>           break;
>>       }
>> +
>> +    if ( ret )
>> +        printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
> Please avoid issuing two messages for the same problem. And the
> one in the default case probably doesn't make sense to be issued
> more than once (and then perhaps at boot time, if that doesn't
> happen already).

I see not doing this for default case but arch-specific inits may (at 
least in principle) fail for some VCPUs and not for others so I think I 
should keep warnings.

What I perhaps should do for default case (and in fact I do this in 
patch 14 where I moved some of this stuff into __initcalls) is to 
disable VPMU globally.

As for printing only once --- I often wondered whether we should have 
something similar to Linux' WARN_ONCE().

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 16:07:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:07:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dbS-0000mV-G9; Thu, 18 Dec 2014 16:07:02 +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 1Y1dbQ-0000mQ-1L
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 16:07:00 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	A6/B0-25727-3ABF2945; Thu, 18 Dec 2014 16:06:59 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418918816!14430585!1
X-Originating-IP: [156.151.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 31494 invoked from network); 18 Dec 2014 16:06:58 -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 Dec 2014 16:06: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 sBIG6mjI010989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Dec 2014 16:06:49 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
	sBIG6kqk010084
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Dec 2014 16:06:47 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
	sBIG6jfj009823; Thu, 18 Dec 2014 16:06:46 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, 18 Dec 2014 08:06:45 -0800
Message-ID: <5492FC11.8010305@oracle.com>
Date: Thu, 18 Dec 2014 11:08: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: Jan Beulich <JBeulich@suse.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-3-git-send-email-boris.ostrovsky@oracle.com>
	<5492EE5C0200007800050AD9@mail.emea.novell.com>
In-Reply-To: <5492EE5C0200007800050AD9@mail.emea.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kevin.tian@intel.com, 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 v16 02/23] x86/VPMU: Don't globally disable
 VPMU if initialization 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/18/2014 09:10 AM, Jan Beulich wrote:
>>>> On 17.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
>> The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
>> forever.
> Reported-by: Jan Beulich <jbeulich@suse.com>
> (or Suggested-by if you like that better)
>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>   xen/arch/x86/hvm/vpmu.c | 15 ++++++++-------
>>   1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
>> index 1df74c2..b43ea80 100644
>> --- a/xen/arch/x86/hvm/vpmu.c
>> +++ b/xen/arch/x86/hvm/vpmu.c
>> @@ -218,6 +218,7 @@ void vpmu_initialise(struct vcpu *v)
>>   {
>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>       uint8_t vendor = current_cpu_data.x86_vendor;
>> +    int ret;
>>   
>>       if ( is_pvh_vcpu(v) )
>>           return;
>> @@ -230,21 +231,21 @@ 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;
>> +        ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
>>           break;
>>   
>>       case X86_VENDOR_INTEL:
>> -        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>> -            opt_vpmu_enabled = 0;
>> +        ret = vmx_vpmu_initialise(v, opt_vpmu_enabled);
>>           break;
>>   
>>       default:
>> -        printk("VPMU: Initialization failed. "
>> -               "Unknown CPU vendor %d\n", vendor);
>> -        opt_vpmu_enabled = 0;
>> +        ret = -EINVAL;
>> +        printk(XENLOG_G_WARNING "VPMU: Unknown CPU vendor %d\n", vendor);
>>           break;
>>       }
>> +
>> +    if ( ret )
>> +        printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
> Please avoid issuing two messages for the same problem. And the
> one in the default case probably doesn't make sense to be issued
> more than once (and then perhaps at boot time, if that doesn't
> happen already).

I see not doing this for default case but arch-specific inits may (at 
least in principle) fail for some VCPUs and not for others so I think I 
should keep warnings.

What I perhaps should do for default case (and in fact I do this in 
patch 14 where I moved some of this stuff into __initcalls) is to 
disable VPMU globally.

As for printing only once --- I often wondered whether we should have 
something similar to Linux' WARN_ONCE().

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 16:07:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:07:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dbz-0000pe-TJ; Thu, 18 Dec 2014 16:07:35 +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 1Y1dby-0000pS-C4
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 16:07:34 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	ED/52-03145-5CBF2945; Thu, 18 Dec 2014 16:07:33 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418918853!15954471!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15670 invoked from network); 18 Dec 2014 16:07:33 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 16:07:33 -0000
Received: by mail-wi0-f169.google.com with SMTP id r20so2081476wiv.0
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 08:07:32 -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=ezdtTJSR8ajHq6vqsuc8AzuQV1Bu1EfxcJ5+ZlziNXQ=;
	b=RnBZ2F42lATlizG8J2oiag/TVg0YZvLYBf9TyogSJ87+7x+eZ5xeKTIeJTnQWRHuVT
	CI0bFCQYOI/rnuDwXHv+jrV0TyBpsnRQ+TWQ6deX9Xm8vFcvHD6TFjUSrOELCtjWEqoD
	ugAHjY02NFU+IpLUFCiwaKhuY62VfxHWL1u0cShWOcf7jrbW8sdgfEvFKRdDm0KKonQ7
	7qpNcoH5byC0113BmV4g5T5aRnOzWDfwnJ7piWn03HboM5y4NIrqK6qhHqTaYLzldZX5
	YI53B4dVFIMWc0pO9g29CXWM+0r2suiDKeOcLAgsbCa86CnlelYF6GCM+wHj7g4eR68w
	9U0A==
X-Gm-Message-State: ALoCoQnC0rTQ4lqhWprSn/XnXc27wn7AhkpIu2IolMqQ0qp9ztqb1PbocGcPHULe/NjnzHH/Rrwo
X-Received: by 10.181.23.199 with SMTP id ic7mr2967977wid.18.1418918851285;
	Thu, 18 Dec 2014 08:07:31 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([82.98.7.133])
	by mx.google.com with ESMTPSA id kn7sm2492749wjc.45.2014.12.18.08.07.29
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 08:07:30 -0800 (PST)
Message-ID: <5492FBC0.9070405@linaro.org>
Date: Thu, 18 Dec 2014 16:07:28 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
	<54915B3E.4010702@linaro.org>
	<54916CFA020000780005032F@mail.emea.novell.com>
	<54917F29.8070901@linaro.org>
	<5491BAB902000078000C40C6@mail.emea.novell.com>
	<5492F919.2010701@linaro.org>
	<549308A90200007800050BF8@mail.emea.novell.com>
In-Reply-To: <549308A90200007800050BF8@mail.emea.novell.com>
Cc: keir@xen.org, ian.campbell@citrix.com, manish.jaggi@caviumnetworks.com,
	tim@xen.org, stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/12/2014 16:02, Jan Beulich wrote:
>>>> On 18.12.14 at 16:56, <julien.grall@linaro.org> wrote:
>> On 17/12/2014 17:17, Jan Beulich wrote:
>>> Aliasing device and pci_dev for x86 would yield similar clarity afaict.
>>
>> To be sure, by aliasing you mean creating a typedef?
>>
>> For x86:
>> typedef struct pci_dev device_t;
>>
>> And for ARM:
>> typedef struct device device_t;
>
> Yes, I think that's the only reasonable thing. Using a #define would
> seem ugly no matter which direction you did it.

Right. We have some place where device and pci_device are used as 
variable. It would have introduced some strange compilation error.

I will go ahead with this 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 Thu Dec 18 16:07:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:07:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dbz-0000pe-TJ; Thu, 18 Dec 2014 16:07:35 +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 1Y1dby-0000pS-C4
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 16:07:34 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	ED/52-03145-5CBF2945; Thu, 18 Dec 2014 16:07:33 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418918853!15954471!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15670 invoked from network); 18 Dec 2014 16:07:33 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 16:07:33 -0000
Received: by mail-wi0-f169.google.com with SMTP id r20so2081476wiv.0
	for <xen-devel@lists.xenproject.org>;
	Thu, 18 Dec 2014 08:07:32 -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=ezdtTJSR8ajHq6vqsuc8AzuQV1Bu1EfxcJ5+ZlziNXQ=;
	b=RnBZ2F42lATlizG8J2oiag/TVg0YZvLYBf9TyogSJ87+7x+eZ5xeKTIeJTnQWRHuVT
	CI0bFCQYOI/rnuDwXHv+jrV0TyBpsnRQ+TWQ6deX9Xm8vFcvHD6TFjUSrOELCtjWEqoD
	ugAHjY02NFU+IpLUFCiwaKhuY62VfxHWL1u0cShWOcf7jrbW8sdgfEvFKRdDm0KKonQ7
	7qpNcoH5byC0113BmV4g5T5aRnOzWDfwnJ7piWn03HboM5y4NIrqK6qhHqTaYLzldZX5
	YI53B4dVFIMWc0pO9g29CXWM+0r2suiDKeOcLAgsbCa86CnlelYF6GCM+wHj7g4eR68w
	9U0A==
X-Gm-Message-State: ALoCoQnC0rTQ4lqhWprSn/XnXc27wn7AhkpIu2IolMqQ0qp9ztqb1PbocGcPHULe/NjnzHH/Rrwo
X-Received: by 10.181.23.199 with SMTP id ic7mr2967977wid.18.1418918851285;
	Thu, 18 Dec 2014 08:07:31 -0800 (PST)
Received: from Juliens-MacBook-Pro.local ([82.98.7.133])
	by mx.google.com with ESMTPSA id kn7sm2492749wjc.45.2014.12.18.08.07.29
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 18 Dec 2014 08:07:30 -0800 (PST)
Message-ID: <5492FBC0.9070405@linaro.org>
Date: Thu, 18 Dec 2014 16:07:28 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org>
	<1418760534-18163-8-git-send-email-julien.grall@linaro.org>
	<549165F102000078000502B8@mail.emea.novell.com>
	<54915B3E.4010702@linaro.org>
	<54916CFA020000780005032F@mail.emea.novell.com>
	<54917F29.8070901@linaro.org>
	<5491BAB902000078000C40C6@mail.emea.novell.com>
	<5492F919.2010701@linaro.org>
	<549308A90200007800050BF8@mail.emea.novell.com>
In-Reply-To: <549308A90200007800050BF8@mail.emea.novell.com>
Cc: keir@xen.org, ian.campbell@citrix.com, manish.jaggi@caviumnetworks.com,
	tim@xen.org, stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way
 to describe device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/12/2014 16:02, Jan Beulich wrote:
>>>> On 18.12.14 at 16:56, <julien.grall@linaro.org> wrote:
>> On 17/12/2014 17:17, Jan Beulich wrote:
>>> Aliasing device and pci_dev for x86 would yield similar clarity afaict.
>>
>> To be sure, by aliasing you mean creating a typedef?
>>
>> For x86:
>> typedef struct pci_dev device_t;
>>
>> And for ARM:
>> typedef struct device device_t;
>
> Yes, I think that's the only reasonable thing. Using a #define would
> seem ugly no matter which direction you did it.

Right. We have some place where device and pci_device are used as 
variable. It would have introduced some strange compilation error.

I will go ahead with this 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 Thu Dec 18 16:09:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:09:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ddY-0000yJ-Ch; Thu, 18 Dec 2014 16:09:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Y1ddW-0000y9-Qp
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 16:09:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	94/26-09842-62CF2945; Thu, 18 Dec 2014 16:09:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418918949!8525185!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 9575 invoked from network); 18 Dec 2014 16:09:09 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 16:09:09 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Y1dd8-000NMy-Tx; Thu, 18 Dec 2014 16:08:46 +0000
Date: Thu, 18 Dec 2014 17:08:46 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141218160846.GD67264@deinos.phlegethon.org>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211212904.GA91831@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611829E@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611829E@SHSMSX101.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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

At 06:29 +0000 on 12 Dec (1418362182), Tian, Kevin wrote:
> If we can't containerize Dom0's behavior completely, I would think dom0
> and Xen actually in the same trust zone, so putting XenGT in Dom0 shouldn't
> make things worse.

Ah, but it does -- it's putting thousands of lines of code into that
trust zone and adding a new attack surface.  So it would be much
better if we could put XenGT in its own domain where it doesn't have
full dom0 privileges.

> However I'm not on whether XenGT must be put
> in a driver domain as a hard requirement. It's nice to have (and some
> implementation opens let's discuss in another thread)

Sure -- it would take a lot of toolstack work to actually put XenGT
into a driver domain.  So although I strongly encourage it, I don't
think it's a hard requirement.  But I'd like to make sure that we
end up with a XenGT that _could_ go in a driver domain if that
toolstack plumbing was done.  

> yep. Just curious, I thought stubdomain is not popularly used. typical
> case is to have qemu in dom0. is this still true? :-)

Some do and some don't. :)  High-security distros like Qubes and
XenClient do.  You can enable it in xl config files pretty easily.
IIRC the xapi toolstack doesn't use it, but XenServer uses privilege
separation to isolate the qemu processes in dom0.

> sorry write a long detail in this high level discussion. Just write-down
> when thinking whether this is practical, and hope it answers our concern
> here. :-)

Thank you for that, it's helpful to have a clear idea about 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 Dec 18 16:09:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:09:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ddY-0000yJ-Ch; Thu, 18 Dec 2014 16:09:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Y1ddW-0000y9-Qp
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 16:09:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	94/26-09842-62CF2945; Thu, 18 Dec 2014 16:09:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418918949!8525185!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 9575 invoked from network); 18 Dec 2014 16:09:09 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 16:09:09 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Y1dd8-000NMy-Tx; Thu, 18 Dec 2014 16:08:46 +0000
Date: Thu, 18 Dec 2014 17:08:46 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141218160846.GD67264@deinos.phlegethon.org>
References: <5486CAAF.9070807@linux.intel.com>
	<20141209104633.GC75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>
	<20141210105505.GA64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>
	<20141211212904.GA91831@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D12611829E@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12611829E@SHSMSX101.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: "keir@xen.org" <keir@xen.org>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>, "Yu,
	Zhang" <yu.c.zhang@linux.intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
	to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

At 06:29 +0000 on 12 Dec (1418362182), Tian, Kevin wrote:
> If we can't containerize Dom0's behavior completely, I would think dom0
> and Xen actually in the same trust zone, so putting XenGT in Dom0 shouldn't
> make things worse.

Ah, but it does -- it's putting thousands of lines of code into that
trust zone and adding a new attack surface.  So it would be much
better if we could put XenGT in its own domain where it doesn't have
full dom0 privileges.

> However I'm not on whether XenGT must be put
> in a driver domain as a hard requirement. It's nice to have (and some
> implementation opens let's discuss in another thread)

Sure -- it would take a lot of toolstack work to actually put XenGT
into a driver domain.  So although I strongly encourage it, I don't
think it's a hard requirement.  But I'd like to make sure that we
end up with a XenGT that _could_ go in a driver domain if that
toolstack plumbing was done.  

> yep. Just curious, I thought stubdomain is not popularly used. typical
> case is to have qemu in dom0. is this still true? :-)

Some do and some don't. :)  High-security distros like Qubes and
XenClient do.  You can enable it in xl config files pretty easily.
IIRC the xapi toolstack doesn't use it, but XenServer uses privilege
separation to isolate the qemu processes in dom0.

> sorry write a long detail in this high level discussion. Just write-down
> when thinking whether this is practical, and hope it answers our concern
> here. :-)

Thank you for that, it's helpful to have a clear idea about 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 Dec 18 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dhy-0001PE-3i; Thu, 18 Dec 2014 16:13:46 +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 1Y1dhx-0001P9-Au
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 16:13:45 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	79/2E-03145-83DF2945; Thu, 18 Dec 2014 16:13:44 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418919224!15991752!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 15743 invoked from network); 18 Dec 2014 16:13:44 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 16:13:44 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Y1dhe-000NS7-0B; Thu, 18 Dec 2014 16:13:26 +0000
Date: Thu, 18 Dec 2014 17:13:25 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141218161325.GA75015@deinos.phlegethon.org>
References: <548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
	<20141210111213.GB64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261167AC@SHSMSX101.ccr.corp.intel.com>
	<20141211130946.GD53811@deinos.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141211130946.GD53811@deinos.phlegethon.org>
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@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Kevin,

At 14:09 +0100 on 11 Dec (1418303386), Tim Deegan wrote:
> At 02:03 +0000 on 11 Dec (1418259797), Tian, Kevin wrote:
> > > From: Tim Deegan [mailto:tim@xen.org]
> > > Now since the code's not going to be in 4.5 anyway, it should be
> > > possible to _develop_ it in this manner, possibly in a private branch,
> > > even if the early stages aren't getting applied immediately.  We
> > > should be able to set up an rmrr branch on the public servers if that
> > > helps.  But again, that relies on having a design worked out in
> > > advance that both developers and maintainers are (within reason)
> > > committed to.
> > 
> > that's a good suggestion. We'll send out a design review today, and then
> > based on discussion we can see whether making sense to do such 
> > incremental way.
> 
> Sounds good!

I haven't seen this design doc yet -- if I missed it can someone point
me to 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 Dec 18 16:13:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1dhy-0001PE-3i; Thu, 18 Dec 2014 16:13:46 +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 1Y1dhx-0001P9-Au
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 16:13:45 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	79/2E-03145-83DF2945; Thu, 18 Dec 2014 16:13:44 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418919224!15991752!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 15743 invoked from network); 18 Dec 2014 16:13:44 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 16:13:44 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Y1dhe-000NS7-0B; Thu, 18 Dec 2014 16:13:26 +0000
Date: Thu, 18 Dec 2014 17:13:25 +0100
From: Tim Deegan <tim@xen.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20141218161325.GA75015@deinos.phlegethon.org>
References: <548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
	<20141210111213.GB64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261167AC@SHSMSX101.ccr.corp.intel.com>
	<20141211130946.GD53811@deinos.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141211130946.GD53811@deinos.phlegethon.org>
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@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Xen-devel] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Kevin,

At 14:09 +0100 on 11 Dec (1418303386), Tim Deegan wrote:
> At 02:03 +0000 on 11 Dec (1418259797), Tian, Kevin wrote:
> > > From: Tim Deegan [mailto:tim@xen.org]
> > > Now since the code's not going to be in 4.5 anyway, it should be
> > > possible to _develop_ it in this manner, possibly in a private branch,
> > > even if the early stages aren't getting applied immediately.  We
> > > should be able to set up an rmrr branch on the public servers if that
> > > helps.  But again, that relies on having a design worked out in
> > > advance that both developers and maintainers are (within reason)
> > > committed to.
> > 
> > that's a good suggestion. We'll send out a design review today, and then
> > based on discussion we can see whether making sense to do such 
> > incremental way.
> 
> Sounds good!

I haven't seen this design doc yet -- if I missed it can someone point
me to 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 Dec 18 16:41:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:41:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1e8A-0002bE-NM; Thu, 18 Dec 2014 16:40:50 +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 1Y1e89-0002b9-Im
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 16:40:49 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	33/99-25276-09303945; Thu, 18 Dec 2014 16:40:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418920848!16532486!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 2316 invoked from network); 18 Dec 2014 16:40:48 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 16:40:48 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Y1e7o-000Nrb-Fi; Thu, 18 Dec 2014 16:40:28 +0000
Date: Thu, 18 Dec 2014 17:40:28 +0100
From: Tim Deegan <tim@xen.org>
To: Chao Peng <chao.p.peng@linux.intel.com>
Message-ID: <20141218164028.GB75015@deinos.phlegethon.org>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418387277-4613-1-git-send-email-chao.p.peng@linux.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: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	will.auld@intel.com, JBeulich@suse.com, wei.liu2@citrix.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design 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

Hi, 

Thanks for posting this - it's very useful.  I have a couple of
questions about the interface design. 

At 20:27 +0800 on 12 Dec (1418412477), Chao Peng wrote:
> Design Overview
> When enforcing cache allocation for VMs, the minimum granularity is
> defined as the domain. All Virtual CPUs ("VCPUs") of a domain have the
> same COS, and therefore, correspond to the same CBM. COS is used only in
> hypervisor and is transparent to tool stack/user. System administrator
> can specify the initial CBM for each domain or change it at runtime using 
> tool stack. Hypervisor then choses a free COS to associate it with that
> CBM or find a existed COS which has the same CBM.

What happens if there is no existing COS that matches, and all COSes
are in use?  Does Xen return an error?  Or try to change COS->CMB
mappings during context switches?

> - VCPU Schedule
> When VCPU is scheduled on the physical CPU ("PCPU"), its COS value is
> then written to MSR (IA32_PQR_ASSOC) of PCPU to notify hardware to use 
> the new COS. The cache allocation is then enforced by hardware.
> 
> - Multi-Socket
> In multi-socket environment, each VCPU may be scheduled on different
> sockets. The hardware CAT ability(such as maximum supported COS and length
> of CBM) maybe different among sockets. For such system, per-socket COS/CBM
> configuration of a domain is specified. Hypervisor then use this per-socket
> CBM information for VCPU schedule.

Is it OK to assume that in the common case all CPUs have the same CAT
capabilities?  Then Xen can just report the smallest set of
capabilities of any socket in the system, and the toolstack doesn't
have to mess about with per-socket settings.

I guess you can add that syntactic sugar on the tools if you want and
leave the more powerful hypecall interface in case it's useful. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 16:41:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:41:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1e8A-0002bE-NM; Thu, 18 Dec 2014 16:40:50 +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 1Y1e89-0002b9-Im
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 16:40:49 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	33/99-25276-09303945; Thu, 18 Dec 2014 16:40:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418920848!16532486!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 2316 invoked from network); 18 Dec 2014 16:40:48 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Dec 2014 16:40:48 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Y1e7o-000Nrb-Fi; Thu, 18 Dec 2014 16:40:28 +0000
Date: Thu, 18 Dec 2014 17:40:28 +0100
From: Tim Deegan <tim@xen.org>
To: Chao Peng <chao.p.peng@linux.intel.com>
Message-ID: <20141218164028.GB75015@deinos.phlegethon.org>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418387277-4613-1-git-send-email-chao.p.peng@linux.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: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	will.auld@intel.com, JBeulich@suse.com, wei.liu2@citrix.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design 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

Hi, 

Thanks for posting this - it's very useful.  I have a couple of
questions about the interface design. 

At 20:27 +0800 on 12 Dec (1418412477), Chao Peng wrote:
> Design Overview
> When enforcing cache allocation for VMs, the minimum granularity is
> defined as the domain. All Virtual CPUs ("VCPUs") of a domain have the
> same COS, and therefore, correspond to the same CBM. COS is used only in
> hypervisor and is transparent to tool stack/user. System administrator
> can specify the initial CBM for each domain or change it at runtime using 
> tool stack. Hypervisor then choses a free COS to associate it with that
> CBM or find a existed COS which has the same CBM.

What happens if there is no existing COS that matches, and all COSes
are in use?  Does Xen return an error?  Or try to change COS->CMB
mappings during context switches?

> - VCPU Schedule
> When VCPU is scheduled on the physical CPU ("PCPU"), its COS value is
> then written to MSR (IA32_PQR_ASSOC) of PCPU to notify hardware to use 
> the new COS. The cache allocation is then enforced by hardware.
> 
> - Multi-Socket
> In multi-socket environment, each VCPU may be scheduled on different
> sockets. The hardware CAT ability(such as maximum supported COS and length
> of CBM) maybe different among sockets. For such system, per-socket COS/CBM
> configuration of a domain is specified. Hypervisor then use this per-socket
> CBM information for VCPU schedule.

Is it OK to assume that in the common case all CPUs have the same CAT
capabilities?  Then Xen can just report the smallest set of
capabilities of any socket in the system, and the toolstack doesn't
have to mess about with per-socket settings.

I guess you can add that syntactic sugar on the tools if you want and
leave the more powerful hypecall interface in case it's useful. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 16:57:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1eNx-0003Wt-EJ; Thu, 18 Dec 2014 16:57:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1eNv-0003Wl-9C
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 16:57:07 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	FB/79-29352-26703945; Thu, 18 Dec 2014 16:57:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418921825!8882009!1
X-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 27390 invoked from network); 18 Dec 2014 16:57:05 -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; 18 Dec 2014 16:57:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 16:57:04 +0000
Message-Id: <5493156F0200007800050C35@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 16:57:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-3-git-send-email-boris.ostrovsky@oracle.com>
	<5492EE5C0200007800050AD9@mail.emea.novell.com>
	<5492FC11.8010305@oracle.com>
In-Reply-To: <5492FC11.8010305@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 02/23] x86/VPMU: Don't globally disable
 VPMU if initialization 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 18.12.14 at 17:08, <boris.ostrovsky@oracle.com> wrote:
> On 12/18/2014 09:10 AM, Jan Beulich wrote:
>>>>> On 17.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
>>> The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
>>> forever.
>> Reported-by: Jan Beulich <jbeulich@suse.com>
>> (or Suggested-by if you like that better)
>>
>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> ---
>>>   xen/arch/x86/hvm/vpmu.c | 15 ++++++++-------
>>>   1 file changed, 8 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
>>> index 1df74c2..b43ea80 100644
>>> --- a/xen/arch/x86/hvm/vpmu.c
>>> +++ b/xen/arch/x86/hvm/vpmu.c
>>> @@ -218,6 +218,7 @@ void vpmu_initialise(struct vcpu *v)
>>>   {
>>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>>       uint8_t vendor = current_cpu_data.x86_vendor;
>>> +    int ret;
>>>   
>>>       if ( is_pvh_vcpu(v) )
>>>           return;
>>> @@ -230,21 +231,21 @@ 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;
>>> +        ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
>>>           break;
>>>   
>>>       case X86_VENDOR_INTEL:
>>> -        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>>> -            opt_vpmu_enabled = 0;
>>> +        ret = vmx_vpmu_initialise(v, opt_vpmu_enabled);
>>>           break;
>>>   
>>>       default:
>>> -        printk("VPMU: Initialization failed. "
>>> -               "Unknown CPU vendor %d\n", vendor);
>>> -        opt_vpmu_enabled = 0;
>>> +        ret = -EINVAL;
>>> +        printk(XENLOG_G_WARNING "VPMU: Unknown CPU vendor %d\n", vendor);
>>>           break;
>>>       }
>>> +
>>> +    if ( ret )
>>> +        printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
>> Please avoid issuing two messages for the same problem. And the
>> one in the default case probably doesn't make sense to be issued
>> more than once (and then perhaps at boot time, if that doesn't
>> happen already).
> 
> I see not doing this for default case but arch-specific inits may (at 
> least in principle) fail for some VCPUs and not for others so I think I 
> should keep warnings.

Right - that's what I asked for. The two aspects I disliked are that
you print two messages for a single vCPU in the default case, and
repeatedly the default case message despite the condition being
invariable across vCPU-s.

> As for printing only once --- I often wondered whether we should have 
> something similar to Linux' WARN_ONCE().

It would have been printk_once() you want here, but with the
change you're planning that's probably moot now anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 16:57:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 16:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1eNx-0003Wt-EJ; Thu, 18 Dec 2014 16:57:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1eNv-0003Wl-9C
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 16:57:07 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	FB/79-29352-26703945; Thu, 18 Dec 2014 16:57:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418921825!8882009!1
X-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 27390 invoked from network); 18 Dec 2014 16:57:05 -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; 18 Dec 2014 16:57:05 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 16:57:04 +0000
Message-Id: <5493156F0200007800050C35@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 16:57:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418830734-1558-1-git-send-email-boris.ostrovsky@oracle.com>
	<1418830734-1558-3-git-send-email-boris.ostrovsky@oracle.com>
	<5492EE5C0200007800050AD9@mail.emea.novell.com>
	<5492FC11.8010305@oracle.com>
In-Reply-To: <5492FC11.8010305@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, 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 v16 02/23] x86/VPMU: Don't globally disable
 VPMU if initialization 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 18.12.14 at 17:08, <boris.ostrovsky@oracle.com> wrote:
> On 12/18/2014 09:10 AM, Jan Beulich wrote:
>>>>> On 17.12.14 at 16:38, <boris.ostrovsky@oracle.com> wrote:
>>> The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
>>> forever.
>> Reported-by: Jan Beulich <jbeulich@suse.com>
>> (or Suggested-by if you like that better)
>>
>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> ---
>>>   xen/arch/x86/hvm/vpmu.c | 15 ++++++++-------
>>>   1 file changed, 8 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
>>> index 1df74c2..b43ea80 100644
>>> --- a/xen/arch/x86/hvm/vpmu.c
>>> +++ b/xen/arch/x86/hvm/vpmu.c
>>> @@ -218,6 +218,7 @@ void vpmu_initialise(struct vcpu *v)
>>>   {
>>>       struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>>       uint8_t vendor = current_cpu_data.x86_vendor;
>>> +    int ret;
>>>   
>>>       if ( is_pvh_vcpu(v) )
>>>           return;
>>> @@ -230,21 +231,21 @@ 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;
>>> +        ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
>>>           break;
>>>   
>>>       case X86_VENDOR_INTEL:
>>> -        if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>>> -            opt_vpmu_enabled = 0;
>>> +        ret = vmx_vpmu_initialise(v, opt_vpmu_enabled);
>>>           break;
>>>   
>>>       default:
>>> -        printk("VPMU: Initialization failed. "
>>> -               "Unknown CPU vendor %d\n", vendor);
>>> -        opt_vpmu_enabled = 0;
>>> +        ret = -EINVAL;
>>> +        printk(XENLOG_G_WARNING "VPMU: Unknown CPU vendor %d\n", vendor);
>>>           break;
>>>       }
>>> +
>>> +    if ( ret )
>>> +        printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
>> Please avoid issuing two messages for the same problem. And the
>> one in the default case probably doesn't make sense to be issued
>> more than once (and then perhaps at boot time, if that doesn't
>> happen already).
> 
> I see not doing this for default case but arch-specific inits may (at 
> least in principle) fail for some VCPUs and not for others so I think I 
> should keep warnings.

Right - that's what I asked for. The two aspects I disliked are that
you print two messages for a single vCPU in the default case, and
repeatedly the default case message despite the condition being
invariable across vCPU-s.

> As for printing only once --- I often wondered whether we should have 
> something similar to Linux' WARN_ONCE().

It would have been printk_once() you want here, but with the
change you're planning that's probably moot now anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 17:22:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17:22:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1em7-0004hb-6y; Thu, 18 Dec 2014 17:22: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 1Y1em5-0004hW-WE
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 17:22:06 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	26/32-25276-D3D03945; Thu, 18 Dec 2014 17:22:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418923322!16553666!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 1866 invoked from network); 18 Dec 2014 17:22:04 -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 Dec 2014 17:22:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="206356991"
Message-ID: <54930868.7060603@citrix.com>
Date: Thu, 18 Dec 2014 17:01: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: Tim Deegan <tim@xen.org>, "Tian, Kevin" <kevin.tian@intel.com>
References: <5486CAAF.9070807@linux.intel.com>	<20141209104633.GC75319@deinos.phlegethon.org>	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>	<20141210105505.GA64596@deinos.phlegethon.org>	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>	<20141211212904.GA91831@deinos.phlegethon.org>	<AADFC41AFE54684AB9EE6CBC0274A5D12611829E@SHSMSX101.ccr.corp.intel.com>
	<20141218160846.GD67264@deinos.phlegethon.org>
In-Reply-To: <20141218160846.GD67264@deinos.phlegethon.org>
X-DLP: MIA2
Cc: "Yu, Zhang" <yu.c.zhang@linux.intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	"keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/12/14 16:08, Tim Deegan wrote:
>> yep. Just curious, I thought stubdomain is not popularly used. typical
>> > case is to have qemu in dom0. is this still true? :-)
> Some do and some don't. :)  High-security distros like Qubes and
> XenClient do.  You can enable it in xl config files pretty easily.
> IIRC the xapi toolstack doesn't use it, but XenServer uses privilege
> separation to isolate the qemu processes in dom0.
>

We are looking into stubdomains as part of future architectural roadmap,
but as identified, there is a lot of toolstack plumbing required before
this be feasible to put into XenServer.

Our privilege separate in qemu is a stopgap measure which we would like
to replace in due course.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 17:22:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17:22:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1em7-0004hb-6y; Thu, 18 Dec 2014 17:22: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 1Y1em5-0004hW-WE
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 17:22:06 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	26/32-25276-D3D03945; Thu, 18 Dec 2014 17:22:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418923322!16553666!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 1866 invoked from network); 18 Dec 2014 17:22:04 -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 Dec 2014 17:22:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="206356991"
Message-ID: <54930868.7060603@citrix.com>
Date: Thu, 18 Dec 2014 17:01: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: Tim Deegan <tim@xen.org>, "Tian, Kevin" <kevin.tian@intel.com>
References: <5486CAAF.9070807@linux.intel.com>	<20141209104633.GC75319@deinos.phlegethon.org>	<AADFC41AFE54684AB9EE6CBC0274A5D126114C9D@SHSMSX101.ccr.corp.intel.com>	<20141210105505.GA64596@deinos.phlegethon.org>	<AADFC41AFE54684AB9EE6CBC0274A5D12611673C@SHSMSX101.ccr.corp.intel.com>	<20141211212904.GA91831@deinos.phlegethon.org>	<AADFC41AFE54684AB9EE6CBC0274A5D12611829E@SHSMSX101.ccr.corp.intel.com>
	<20141218160846.GD67264@deinos.phlegethon.org>
In-Reply-To: <20141218160846.GD67264@deinos.phlegethon.org>
X-DLP: MIA2
Cc: "Yu, Zhang" <yu.c.zhang@linux.intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	"keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
 to mfn.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/12/14 16:08, Tim Deegan wrote:
>> yep. Just curious, I thought stubdomain is not popularly used. typical
>> > case is to have qemu in dom0. is this still true? :-)
> Some do and some don't. :)  High-security distros like Qubes and
> XenClient do.  You can enable it in xl config files pretty easily.
> IIRC the xapi toolstack doesn't use it, but XenServer uses privilege
> separation to isolate the qemu processes in dom0.
>

We are looking into stubdomains as part of future architectural roadmap,
but as identified, there is a lot of toolstack plumbing required before
this be feasible to put into XenServer.

Our privilege separate in qemu is a stopgap measure which we would like
to replace in due course.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 17:36:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1f08-0005Wz-LH; Thu, 18 Dec 2014 17:36:36 +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 1Y1f07-0005Wu-2F
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 17:36:35 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E5/DA-15461-2A013945; Thu, 18 Dec 2014 17:36:34 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418924190!16544477!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMTUxMDM2MiAo
	YWJhbmRvbmVkOiBhYm91dC5tZS9kYXJpby5m\nYWdnaW9saSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26381 invoked from network); 18 Dec 2014 17:36:31 -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;
	18 Dec 2014 17:36:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; 
	d="asc'?scan'208";a="205892421"
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.210.2;
	Thu, 18 Dec 2014 12:29:18 -0500
Message-ID: <1418923754.10854.25.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Juergen Gross <jgross@suse.com>
Date: Thu, 18 Dec 2014 18:29:14 +0100
In-Reply-To: <5492EE60.5090005@suse.com>
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
	<5492EBFC.8010005@suse.com>
	<20141218150409.GA2870@zion.uk.xensource.com>
	<5492EE60.5090005@suse.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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: multipart/mixed; boundary="===============6703313783915669567=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6703313783915669567==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-yRhIYXHNuVOqTIOSkbyS"

--=-yRhIYXHNuVOqTIOSkbyS
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-12-18 at 16:10 +0100, Juergen Gross wrote:
> On 12/18/2014 04:04 PM, Wei Liu wrote:
> > On Thu, Dec 18, 2014 at 04:00:12PM +0100, Juergen Gross wrote:
> >> On 12/18/2014 02:39 PM, Dario Faggioli wrote:
> >>> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >>> ---
> >>>   make-flight |   11 +++++++++++
> >>>   sg-run-job  |    6 ++++++
> >>>   2 files changed, 17 insertions(+)
> >>>
> >>> diff --git a/make-flight b/make-flight
> >>> index a91f256..ce02c89 100755
> >>> --- a/make-flight
> >>> +++ b/make-flight
> >>> @@ -266,6 +266,16 @@ do_credit2_tests () {
> >>>               $debian_runvars all_hostflags=3D$most_hostflags
> >>>   }
> >>>
> >>> +do_cpupools_tests () {
> >>> +  if [ $xenarch !=3D amd64 -o $dom0arch !=3D amd64 ]; then
> >>> +    return
> >>> +  fi
> >>
> >> Why can't you test cpupools on x86_64?
> >>
> >
> > Don't worry. That's the name used for 64 bit (be it amd or intel) in
> > OSSTest. :-)
>=20
Exactly, it comes from the Debian arches names.

> Aargh. Some automatic filter in my brain translated this to arm64 :-)
>=20
HeHe :-)

> So: Why can't you test cpupools on ARM?
>=20
We certainly can. ARM testing via OSSTest is a still experimental,
AFAIUI.

I don't even know if we have the hardware, yet, as I think the "rack" of
ARM dev board IanC was working on will be setup in the new testing COLO,
rather than in current OSSTest pool of hardware (someone correct me if
I'm wrong).

However, that seems to be taken into account by the fact that, in
make-flight, in test_matrix_do_one(), after only 2 jobs are created (the
basic debian one and a libvirt one) we have this:

  # No further arm tests at the moment
  if [ $dom0arch =3D armhf ]; then
      return
  fi

So, yes, I guess I can get rid of such filters in my new function, so
that, when ARM maintainers  will disable the safety catch above, a job
will actually be generated.

I'll give it a shot for v2.

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)


--=-yRhIYXHNuVOqTIOSkbyS
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

iEYEABECAAYFAlSTDusACgkQk4XaBE3IOsT1YwCdHkKEJ+l8AD4+mD3IsBG2runQ
mwAAnirfH0h7U7ElnO28BsIu43cg9i4Z
=nP/k
-----END PGP SIGNATURE-----

--=-yRhIYXHNuVOqTIOSkbyS--


--===============6703313783915669567==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6703313783915669567==--


From xen-devel-bounces@lists.xen.org Thu Dec 18 17:36:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1f08-0005Wz-LH; Thu, 18 Dec 2014 17:36:36 +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 1Y1f07-0005Wu-2F
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 17:36:35 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	E5/DA-15461-2A013945; Thu, 18 Dec 2014 17:36:34 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1418924190!16544477!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMTUxMDM2MiAo
	YWJhbmRvbmVkOiBhYm91dC5tZS9kYXJpby5m\nYWdnaW9saSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26381 invoked from network); 18 Dec 2014 17:36:31 -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;
	18 Dec 2014 17:36:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; 
	d="asc'?scan'208";a="205892421"
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.210.2;
	Thu, 18 Dec 2014 12:29:18 -0500
Message-ID: <1418923754.10854.25.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Juergen Gross <jgross@suse.com>
Date: Thu, 18 Dec 2014 18:29:14 +0100
In-Reply-To: <5492EE60.5090005@suse.com>
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
	<5492EBFC.8010005@suse.com>
	<20141218150409.GA2870@zion.uk.xensource.com>
	<5492EE60.5090005@suse.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
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>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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: multipart/mixed; boundary="===============6703313783915669567=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6703313783915669567==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-yRhIYXHNuVOqTIOSkbyS"

--=-yRhIYXHNuVOqTIOSkbyS
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2014-12-18 at 16:10 +0100, Juergen Gross wrote:
> On 12/18/2014 04:04 PM, Wei Liu wrote:
> > On Thu, Dec 18, 2014 at 04:00:12PM +0100, Juergen Gross wrote:
> >> On 12/18/2014 02:39 PM, Dario Faggioli wrote:
> >>> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >>> ---
> >>>   make-flight |   11 +++++++++++
> >>>   sg-run-job  |    6 ++++++
> >>>   2 files changed, 17 insertions(+)
> >>>
> >>> diff --git a/make-flight b/make-flight
> >>> index a91f256..ce02c89 100755
> >>> --- a/make-flight
> >>> +++ b/make-flight
> >>> @@ -266,6 +266,16 @@ do_credit2_tests () {
> >>>               $debian_runvars all_hostflags=3D$most_hostflags
> >>>   }
> >>>
> >>> +do_cpupools_tests () {
> >>> +  if [ $xenarch !=3D amd64 -o $dom0arch !=3D amd64 ]; then
> >>> +    return
> >>> +  fi
> >>
> >> Why can't you test cpupools on x86_64?
> >>
> >
> > Don't worry. That's the name used for 64 bit (be it amd or intel) in
> > OSSTest. :-)
>=20
Exactly, it comes from the Debian arches names.

> Aargh. Some automatic filter in my brain translated this to arm64 :-)
>=20
HeHe :-)

> So: Why can't you test cpupools on ARM?
>=20
We certainly can. ARM testing via OSSTest is a still experimental,
AFAIUI.

I don't even know if we have the hardware, yet, as I think the "rack" of
ARM dev board IanC was working on will be setup in the new testing COLO,
rather than in current OSSTest pool of hardware (someone correct me if
I'm wrong).

However, that seems to be taken into account by the fact that, in
make-flight, in test_matrix_do_one(), after only 2 jobs are created (the
basic debian one and a libvirt one) we have this:

  # No further arm tests at the moment
  if [ $dom0arch =3D armhf ]; then
      return
  fi

So, yes, I guess I can get rid of such filters in my new function, so
that, when ARM maintainers  will disable the safety catch above, a job
will actually be generated.

I'll give it a shot for v2.

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)


--=-yRhIYXHNuVOqTIOSkbyS
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

iEYEABECAAYFAlSTDusACgkQk4XaBE3IOsT1YwCdHkKEJ+l8AD4+mD3IsBG2runQ
mwAAnirfH0h7U7ElnO28BsIu43cg9i4Z
=nP/k
-----END PGP SIGNATURE-----

--=-yRhIYXHNuVOqTIOSkbyS--


--===============6703313783915669567==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6703313783915669567==--


From xen-devel-bounces@lists.xen.org Thu Dec 18 17:38:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17: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 1Y1f1x-0005cn-6Z; Thu, 18 Dec 2014 17:38:29 +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 1Y1f1v-0005cf-SI
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 17:38:28 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	A6/F6-03145-31113945; Thu, 18 Dec 2014 17:38:27 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418924305!15974518!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20246 invoked from network); 18 Dec 2014 17:38:26 -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 Dec 2014 17:38: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 sBIHcN0n026840
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Dec 2014 17:38:24 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
	sBIHcMPM009871
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 18 Dec 2014 17:38:23 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
	sBIHcMoO019842; Thu, 18 Dec 2014 17:38:22 GMT
Received: from ovs101.us.oracle.com (/10.149.76.201)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Dec 2014 09:38:22 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, konrad.wilk@oracle.com
Date: Thu, 18 Dec 2014 13:06:40 -0500
Message-Id: <1418926000-5953-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 v4 for 4.5] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.

We have to do this via IPI since otherwise there is a (somewheat
theoretical) chance that between test and subsequent clearing
of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
both vpmu_load() and then vpmu_save() for another VCPU. The former
will clear last_vcpu and the latter will set it to something else.

Performing this operation via IPI will guarantee that nothing can
happen on the remote processor between testing and clearing of
last_vcpu.

We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
avoid unnecessary percpu tests and arch-specific destroy ops. Thus
checks in AMD and Intel routines are no longer needed.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/svm/vpmu.c       |    3 ---
 xen/arch/x86/hvm/vmx/vpmu_core2.c |    2 --
 xen/arch/x86/hvm/vpmu.c           |   20 ++++++++++++++++++++
 3 files changed, 20 insertions(+), 5 deletions(-)

Changes in v4:
 * Back to v2's IPI implementation

Changes in v3:
 * Use cmpxchg instead of IPI
 * Use correct routine names in commit message
 * Remove duplicate test for VPMU_CONTEXT_ALLOCATED in arch-specific
   destroy ops

Changes in v2:
 * Test last_vcpu locally before IPI
 * Don't handle local pcpu as a special case --- on_selected_cpus
   will take care of that
 * Dont't cast variables unnecessarily


diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 8e07a98..4c448bb 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -403,9 +403,6 @@ static void amd_vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
-        return;
-
     if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
         amd_vpmu_unset_msr_bitmap(v);
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 68b6272..590c2a9 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -818,8 +818,6 @@ 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 ( cpu_has_vmx_msr_bitmap )
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1df74c2..37f0d9f 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -247,10 +247,30 @@ void vpmu_initialise(struct vcpu *v)
     }
 }
 
+static void vpmu_clear_last(void *arg)
+{
+    if ( this_cpu(last_vcpu) == arg )
+        this_cpu(last_vcpu) = NULL;
+}
+
 void vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
+        return;
+
+    /*
+     * Need to clear last_vcpu in case it points to v.
+     * We can check here non-atomically whether it is 'v' since
+     * last_vcpu can never become 'v' again at this point.
+     * We will test it again in vpmu_clear_last() with interrupts
+     * disabled to make sure we don't clear someone else.
+     */
+    if ( per_cpu(last_vcpu, vpmu->last_pcpu) == v )
+        on_selected_cpus(cpumask_of(vpmu->last_pcpu),
+                         vpmu_clear_last, v, 1);
+
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
         vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
 }
-- 
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 Dec 18 17:38:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17: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 1Y1f1x-0005cn-6Z; Thu, 18 Dec 2014 17:38:29 +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 1Y1f1v-0005cf-SI
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 17:38:28 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	A6/F6-03145-31113945; Thu, 18 Dec 2014 17:38:27 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418924305!15974518!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20246 invoked from network); 18 Dec 2014 17:38:26 -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 Dec 2014 17:38: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 sBIHcN0n026840
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Dec 2014 17:38:24 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
	sBIHcMPM009871
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 18 Dec 2014 17:38:23 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
	sBIHcMoO019842; Thu, 18 Dec 2014 17:38:22 GMT
Received: from ovs101.us.oracle.com (/10.149.76.201)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Dec 2014 09:38:22 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, konrad.wilk@oracle.com
Date: Thu, 18 Dec 2014 13:06:40 -0500
Message-Id: <1418926000-5953-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 v4 for 4.5] x86/VPMU: Clear last_vcpu when
	destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.

We have to do this via IPI since otherwise there is a (somewheat
theoretical) chance that between test and subsequent clearing
of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
both vpmu_load() and then vpmu_save() for another VCPU. The former
will clear last_vcpu and the latter will set it to something else.

Performing this operation via IPI will guarantee that nothing can
happen on the remote processor between testing and clearing of
last_vcpu.

We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
avoid unnecessary percpu tests and arch-specific destroy ops. Thus
checks in AMD and Intel routines are no longer needed.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/svm/vpmu.c       |    3 ---
 xen/arch/x86/hvm/vmx/vpmu_core2.c |    2 --
 xen/arch/x86/hvm/vpmu.c           |   20 ++++++++++++++++++++
 3 files changed, 20 insertions(+), 5 deletions(-)

Changes in v4:
 * Back to v2's IPI implementation

Changes in v3:
 * Use cmpxchg instead of IPI
 * Use correct routine names in commit message
 * Remove duplicate test for VPMU_CONTEXT_ALLOCATED in arch-specific
   destroy ops

Changes in v2:
 * Test last_vcpu locally before IPI
 * Don't handle local pcpu as a special case --- on_selected_cpus
   will take care of that
 * Dont't cast variables unnecessarily


diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 8e07a98..4c448bb 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -403,9 +403,6 @@ static void amd_vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
-        return;
-
     if ( ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
         amd_vpmu_unset_msr_bitmap(v);
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 68b6272..590c2a9 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -818,8 +818,6 @@ 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 ( cpu_has_vmx_msr_bitmap )
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1df74c2..37f0d9f 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -247,10 +247,30 @@ void vpmu_initialise(struct vcpu *v)
     }
 }
 
+static void vpmu_clear_last(void *arg)
+{
+    if ( this_cpu(last_vcpu) == arg )
+        this_cpu(last_vcpu) = NULL;
+}
+
 void vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
+        return;
+
+    /*
+     * Need to clear last_vcpu in case it points to v.
+     * We can check here non-atomically whether it is 'v' since
+     * last_vcpu can never become 'v' again at this point.
+     * We will test it again in vpmu_clear_last() with interrupts
+     * disabled to make sure we don't clear someone else.
+     */
+    if ( per_cpu(last_vcpu, vpmu->last_pcpu) == v )
+        on_selected_cpus(cpumask_of(vpmu->last_pcpu),
+                         vpmu_clear_last, v, 1);
+
     if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
         vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
 }
-- 
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 Dec 18 17:50:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17: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 1Y1fDK-0006DD-EF; Thu, 18 Dec 2014 17:50:14 +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 1Y1fDJ-0006D8-FW
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 17:50:13 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	8D/08-02957-4D313945; Thu, 18 Dec 2014 17:50:12 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418925011!16040190!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11238 invoked from network); 18 Dec 2014 17:50:12 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-15.tower-27.messagelabs.com with SMTP;
	18 Dec 2014 17:50:12 -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 9784C5823EC;
	Thu, 18 Dec 2014 09:50:10 -0800 (PST)
Date: Thu, 18 Dec 2014 12:50:09 -0500 (EST)
Message-Id: <20141218.125009.1837191564956948256.davem@davemloft.net>
To: david.vrabel@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1418901186-14478-1-git-send-email-david.vrabel@citrix.com>
References: <1418901186-14478-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, 18 Dec 2014 09:50:11 -0800 (PST)
Cc: netdev@vger.kernel.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net] xen-netback: support frontends
 without feature-rx-notify again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 18 Dec 2014 11:13:06 +0000

> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
> feature-rx-notify mandatory) incorrectly assumed that there were no
> frontends in use that did not support this feature.  But the frontend
> driver in MiniOS does not and since this is used by (qemu) stubdoms,
> these stopped working.
> 
> Netback sort of works as-is in this mode except:
> 
> - If there are no Rx requests and the internal Rx queue fills, only
>   the drain timeout will wake the thread.  The default drain timeout
>   of 10 s would give unacceptable pauses.
> 
> - If an Rx stall was detected and the internal Rx queue is drained,
>   then the Rx thread would never wake.
> 
> Handle these two cases (when feature-rx-notify is disabled) by:
> 
> - Reducing the drain timeout to 30 ms.
> 
> - Disabling Rx stall detection.
> 
> Reported-by: John <jw@nuclearfallout.net>
> Tested-by: John <jw@nuclearfallout.net>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Applied, and I assume that 3.18 -stable needs this as well?

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 17:50:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17: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 1Y1fDK-0006DD-EF; Thu, 18 Dec 2014 17:50:14 +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 1Y1fDJ-0006D8-FW
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 17:50:13 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	8D/08-02957-4D313945; Thu, 18 Dec 2014 17:50:12 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-15.tower-27.messagelabs.com!1418925011!16040190!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11238 invoked from network); 18 Dec 2014 17:50:12 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-15.tower-27.messagelabs.com with SMTP;
	18 Dec 2014 17:50:12 -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 9784C5823EC;
	Thu, 18 Dec 2014 09:50:10 -0800 (PST)
Date: Thu, 18 Dec 2014 12:50:09 -0500 (EST)
Message-Id: <20141218.125009.1837191564956948256.davem@davemloft.net>
To: david.vrabel@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1418901186-14478-1-git-send-email-david.vrabel@citrix.com>
References: <1418901186-14478-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, 18 Dec 2014 09:50:11 -0800 (PST)
Cc: netdev@vger.kernel.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net] xen-netback: support frontends
 without feature-rx-notify again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 18 Dec 2014 11:13:06 +0000

> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
> feature-rx-notify mandatory) incorrectly assumed that there were no
> frontends in use that did not support this feature.  But the frontend
> driver in MiniOS does not and since this is used by (qemu) stubdoms,
> these stopped working.
> 
> Netback sort of works as-is in this mode except:
> 
> - If there are no Rx requests and the internal Rx queue fills, only
>   the drain timeout will wake the thread.  The default drain timeout
>   of 10 s would give unacceptable pauses.
> 
> - If an Rx stall was detected and the internal Rx queue is drained,
>   then the Rx thread would never wake.
> 
> Handle these two cases (when feature-rx-notify is disabled) by:
> 
> - Reducing the drain timeout to 30 ms.
> 
> - Disabling Rx stall detection.
> 
> Reported-by: John <jw@nuclearfallout.net>
> Tested-by: John <jw@nuclearfallout.net>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Applied, and I assume that 3.18 -stable needs this as well?

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 17:54:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17: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 1Y1fHe-0006XG-5Z; Thu, 18 Dec 2014 17:54:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <will.auld@intel.com>) id 1Y1fHc-0006XB-4T
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 17:54:40 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	43/55-20609-FD413945; Thu, 18 Dec 2014 17:54:39 +0000
X-Env-Sender: will.auld@intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418925278!16033638!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16940 invoked from network); 18 Dec 2014 17:54:38 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-27.messagelabs.com with SMTP;
	18 Dec 2014 17:54:38 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 18 Dec 2014 09:54:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,602,1413270000"; d="scan'208";a="639845004"
Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8])
	by fmsmga001.fm.intel.com with ESMTP; 18 Dec 2014 09:54:37 -0800
Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by
	ORSMSX110.amr.corp.intel.com (10.22.240.8) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 18 Dec 2014 09:54:36 -0800
Received: from orsmsx105.amr.corp.intel.com ([169.254.4.126]) by
	ORSMSX153.amr.corp.intel.com ([169.254.12.250]) with mapi id
	14.03.0195.001; Thu, 18 Dec 2014 09:54:36 -0800
From: "Auld, Will" <will.auld@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Chao Peng <chao.p.peng@linux.intel.com>
Thread-Topic: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
Thread-Index: AQHQGQ4y/kXWSfpXNEK9oEuLTBdw8JySfACAgAMm6MA=
Date: Thu, 18 Dec 2014 17:54:36 +0000
Message-ID: <96EC5A4F3149B74492D2D9B9B1602C2734A1CFC9@ORSMSX105.amr.corp.intel.com>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141216085559.GB3105@pengc-linux.bj.intel.com>
	<54900B91020000780004FCC2@mail.emea.novell.com>
In-Reply-To: <54900B91020000780004FCC2@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: "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>,
	"George.Dunlap@eu.citrix.com" <George.Dunlap@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>, "Auld,
	Will" <will.auld@intel.com>, "keir@xen.org" <keir@xen.org>,
	"dgdegra@tycho.nsa.gov" <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design 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



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, December 16, 2014 1:38 AM
> To: Chao Peng
> Cc: andrew.cooper3@citrix.com; Ian.Campbell@citrix.com;
> wei.liu2@citrix.com; George.Dunlap@eu.citrix.com;
> Ian.Jackson@eu.citrix.com; stefano.stabellini@eu.citrix.com; Auld,
> Will; xen-devel@lists.xen.org; dgdegra@tycho.nsa.gov; keir@xen.org
> Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for
> XEN
> 
> >>> On 16.12.14 at 09:55, <chao.p.peng@linux.intel.com> wrote:
> > Any comments from you? It would be greatly appreciated if you can
> look
> > at this when you have time. Your comments are always important to me
> > :)
> 
> I don't think I have to say much here:
> 
> > On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote:
> >> Implementation Description
> >> ==========================
> >> In this design, one principal is that only implementing the cache
> >> enforcement mechanism in hypervisor but leaving the cache allocation
> >> policy to user space tool stack. In this way some complex governors
> >> then can be implemented in tool stack.
> 
> With this, the changes to the hypervisor ought to be quite limited,
> even if length of the list you give seems long at a first glance, and
> hence I'm fine with the concept.
> 
> >> Hardware Limitation & Performance Improvement
> >> =============================================
> >> As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
> >> switch. If the change is frequent then hardware may fail to strictly
> >> enforce the cache allocation basing on the specified COS.
> 
> This certainly would deserve a little more explanation: What's the
> value of the functionality if one can't rely on it being enforced by
> hardware at all times?
> 
> Jan

The majority of the time it should work as expected without additional configuration. Cases requiring additional configuration for higher accuracy will have COS exclusively affinitized to CPU(s) removing the source of error.    

Thanks,

Will 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 17:54:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17: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 1Y1fHe-0006XG-5Z; Thu, 18 Dec 2014 17:54:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <will.auld@intel.com>) id 1Y1fHc-0006XB-4T
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 17:54:40 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	43/55-20609-FD413945; Thu, 18 Dec 2014 17:54:39 +0000
X-Env-Sender: will.auld@intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418925278!16033638!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16940 invoked from network); 18 Dec 2014 17:54:38 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-27.messagelabs.com with SMTP;
	18 Dec 2014 17:54:38 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 18 Dec 2014 09:54:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,602,1413270000"; d="scan'208";a="639845004"
Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8])
	by fmsmga001.fm.intel.com with ESMTP; 18 Dec 2014 09:54:37 -0800
Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by
	ORSMSX110.amr.corp.intel.com (10.22.240.8) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 18 Dec 2014 09:54:36 -0800
Received: from orsmsx105.amr.corp.intel.com ([169.254.4.126]) by
	ORSMSX153.amr.corp.intel.com ([169.254.12.250]) with mapi id
	14.03.0195.001; Thu, 18 Dec 2014 09:54:36 -0800
From: "Auld, Will" <will.auld@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Chao Peng <chao.p.peng@linux.intel.com>
Thread-Topic: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
Thread-Index: AQHQGQ4y/kXWSfpXNEK9oEuLTBdw8JySfACAgAMm6MA=
Date: Thu, 18 Dec 2014 17:54:36 +0000
Message-ID: <96EC5A4F3149B74492D2D9B9B1602C2734A1CFC9@ORSMSX105.amr.corp.intel.com>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141216085559.GB3105@pengc-linux.bj.intel.com>
	<54900B91020000780004FCC2@mail.emea.novell.com>
In-Reply-To: <54900B91020000780004FCC2@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: "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>,
	"George.Dunlap@eu.citrix.com" <George.Dunlap@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>, "Auld,
	Will" <will.auld@intel.com>, "keir@xen.org" <keir@xen.org>,
	"dgdegra@tycho.nsa.gov" <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design 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



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, December 16, 2014 1:38 AM
> To: Chao Peng
> Cc: andrew.cooper3@citrix.com; Ian.Campbell@citrix.com;
> wei.liu2@citrix.com; George.Dunlap@eu.citrix.com;
> Ian.Jackson@eu.citrix.com; stefano.stabellini@eu.citrix.com; Auld,
> Will; xen-devel@lists.xen.org; dgdegra@tycho.nsa.gov; keir@xen.org
> Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for
> XEN
> 
> >>> On 16.12.14 at 09:55, <chao.p.peng@linux.intel.com> wrote:
> > Any comments from you? It would be greatly appreciated if you can
> look
> > at this when you have time. Your comments are always important to me
> > :)
> 
> I don't think I have to say much here:
> 
> > On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote:
> >> Implementation Description
> >> ==========================
> >> In this design, one principal is that only implementing the cache
> >> enforcement mechanism in hypervisor but leaving the cache allocation
> >> policy to user space tool stack. In this way some complex governors
> >> then can be implemented in tool stack.
> 
> With this, the changes to the hypervisor ought to be quite limited,
> even if length of the list you give seems long at a first glance, and
> hence I'm fine with the concept.
> 
> >> Hardware Limitation & Performance Improvement
> >> =============================================
> >> As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
> >> switch. If the change is frequent then hardware may fail to strictly
> >> enforce the cache allocation basing on the specified COS.
> 
> This certainly would deserve a little more explanation: What's the
> value of the functionality if one can't rely on it being enforced by
> hardware at all times?
> 
> Jan

The majority of the time it should work as expected without additional configuration. Cases requiring additional configuration for higher accuracy will have COS exclusively affinitized to CPU(s) removing the source of error.    

Thanks,

Will 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 17:56:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17: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 1Y1fJG-0006cP-KD; Thu, 18 Dec 2014 17:56:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Y1fJF-0006cG-BD
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 17:56:21 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	0A/43-25714-44513945; Thu, 18 Dec 2014 17:56:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418925378!10060363!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 6776 invoked from network); 18 Dec 2014 17:56:19 -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 Dec 2014 17:56:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="205905878"
Message-ID: <54931513.8040606@citrix.com>
Date: Thu, 18 Dec 2014 17:55:31 +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: David Miller <davem@davemloft.net>
References: <1418901186-14478-1-git-send-email-david.vrabel@citrix.com>
	<20141218.125009.1837191564956948256.davem@davemloft.net>
In-Reply-To: <20141218.125009.1837191564956948256.davem@davemloft.net>
X-DLP: MIA1
Cc: netdev@vger.kernel.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net] xen-netback: support frontends
 without feature-rx-notify again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 17:50, David Miller wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Thu, 18 Dec 2014 11:13:06 +0000
> 
>> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
>> feature-rx-notify mandatory) incorrectly assumed that there were no
>> frontends in use that did not support this feature.  But the frontend
>> driver in MiniOS does not and since this is used by (qemu) stubdoms,
>> these stopped working.
>>
>> Netback sort of works as-is in this mode except:
>>
>> - If there are no Rx requests and the internal Rx queue fills, only
>>   the drain timeout will wake the thread.  The default drain timeout
>>   of 10 s would give unacceptable pauses.
>>
>> - If an Rx stall was detected and the internal Rx queue is drained,
>>   then the Rx thread would never wake.
>>
>> Handle these two cases (when feature-rx-notify is disabled) by:
>>
>> - Reducing the drain timeout to 30 ms.
>>
>> - Disabling Rx stall detection.
>>
>> Reported-by: John <jw@nuclearfallout.net>
>> Tested-by: John <jw@nuclearfallout.net>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> Applied, and I assume that 3.18 -stable needs this as well?

Yes, please.  Without it, netback just doesn't work with an important
use case.

Thanks.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 17:56:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17: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 1Y1fJG-0006cP-KD; Thu, 18 Dec 2014 17:56:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Y1fJF-0006cG-BD
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 17:56:21 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	0A/43-25714-44513945; Thu, 18 Dec 2014 17:56:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1418925378!10060363!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 6776 invoked from network); 18 Dec 2014 17:56:19 -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 Dec 2014 17:56:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="205905878"
Message-ID: <54931513.8040606@citrix.com>
Date: Thu, 18 Dec 2014 17:55:31 +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: David Miller <davem@davemloft.net>
References: <1418901186-14478-1-git-send-email-david.vrabel@citrix.com>
	<20141218.125009.1837191564956948256.davem@davemloft.net>
In-Reply-To: <20141218.125009.1837191564956948256.davem@davemloft.net>
X-DLP: MIA1
Cc: netdev@vger.kernel.org, wei.liu2@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCHv1 net] xen-netback: support frontends
 without feature-rx-notify again
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 17:50, David Miller wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Thu, 18 Dec 2014 11:13:06 +0000
> 
>> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
>> feature-rx-notify mandatory) incorrectly assumed that there were no
>> frontends in use that did not support this feature.  But the frontend
>> driver in MiniOS does not and since this is used by (qemu) stubdoms,
>> these stopped working.
>>
>> Netback sort of works as-is in this mode except:
>>
>> - If there are no Rx requests and the internal Rx queue fills, only
>>   the drain timeout will wake the thread.  The default drain timeout
>>   of 10 s would give unacceptable pauses.
>>
>> - If an Rx stall was detected and the internal Rx queue is drained,
>>   then the Rx thread would never wake.
>>
>> Handle these two cases (when feature-rx-notify is disabled) by:
>>
>> - Reducing the drain timeout to 30 ms.
>>
>> - Disabling Rx stall detection.
>>
>> Reported-by: John <jw@nuclearfallout.net>
>> Tested-by: John <jw@nuclearfallout.net>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> Applied, and I assume that 3.18 -stable needs this as well?

Yes, please.  Without it, netback just doesn't work with an important
use case.

Thanks.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 17:56:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17: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 1Y1fJU-0006e3-0a; Thu, 18 Dec 2014 17:56:36 +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 1Y1fJS-0006dj-FX
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 17:56:34 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	25/F6-17694-15513945; Thu, 18 Dec 2014 17:56:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418925391!10007025!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 20928 invoked from network); 18 Dec 2014 17:56:33 -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 Dec 2014 17:56:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="205906071"
Message-ID: <54931527.3070204@citrix.com>
Date: Thu, 18 Dec 2014 17:55:51 +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: David Vrabel <david.vrabel@citrix.com>, "Xen-devel@lists.xen.org"
	<Xen-devel@lists.xen.org>
References: <543BD686.3080006@citrix.com>
In-Reply-To: <543BD686.3080006@citrix.com>
X-DLP: MIA2
Cc: Jennifer Herbert <jennifer.herbert@citrix.com>
Subject: Re: [Xen-devel] Linux grant map/unmap improvement proposal (Draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/10/14 14:41, David Vrabel wrote:
> 
> Design
> ======

Jennifer has put together most of the initial implementation of this so
expect a full series some time next year.

It didn't quite end up as described here.

> Userspace address to page translation
> -------------------------------------
> 
> The m2p_override table shall be removed.
> 
> Each VMA (struct vm_struct) shall contain an additional pointer to an
> optional array of pages.  This array shall be sized to cover the full
> extent of the VMA.
> 
> The gntdev driver populates this array with the relevant pages for the
> foreign mappings as they are mapped.  It shall also clear them when
> unmapping.  The gntdev driver must ensure it properly splits the page
> array when the VMA itself is split.
> 
> Since the m2p lookup will not return a local PFN, the native
> get_user_pages_fast() call will fail.  Prior to attempting to fault in
> the pages, get_user_pages() can simply look up the pages in the VMA's
> page array.

This was not true.  Instead, we mark the userspace PTEs as special
(_PAGE_SPECIAL set) which causes the generic x86 code to skip the fast path.

We also changed vm_normal_page() to look in vma->pages which puts the
extra code outside of any common use case (i.e., away from any handling
of non-special mappings), further reducing the impact on existing use cases.

For the curious, the 3-liner mm/memory.c change is below (although this
does not handle VMA splitting yet, but that should be straight-forwards).

> Userspace grant performance
> ---------------------------
> 
> - Lazily map grants into userspace on faults.  For applications that
>   do not access the foreign frames by the userspace mappings (such as
>   block backends using direct I/O) this would avoid a set of maps and
>   unmaps. This lazy mode would have to be requested by the userspace
>   program (since faulting many pages would be much more expensive than
>   a single batched map).

This does not look possible without more invasive changes to core MM
code.  Although we can lazily fault in the mappings we still need PTEs
to allow get_user_pages() to work, so map-on-fault isn't useful.

David

--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -289,6 +289,7 @@ struct vm_area_struct {
 #ifdef CONFIG_NUMA
 	struct mempolicy *vm_policy;	/* NUMA policy for the VMA */
 #endif
+	struct page	**pages;
 };

 struct core_thread {
diff --git a/mm/memory.c b/mm/memory.c
index 4b60011..3ca13bb 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -774,6 +774,8 @@ struct page *vm_normal_page(struct vm_area_struct
*vma, unsigned long addr,
 	if (HAVE_PTE_SPECIAL) {
 		if (likely(!pte_special(pte)))
 			goto check_pfn;
+		if (vma->pages)
+			return vma->pages[(addr - vma->vm_start) >> PAGE_SHIFT];
 		if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
 			return NULL;
 		if (!is_zero_pfn(pfn))
-- 
1.7.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 Dec 18 17:56:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 17: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 1Y1fJU-0006e3-0a; Thu, 18 Dec 2014 17:56:36 +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 1Y1fJS-0006dj-FX
	for Xen-devel@lists.xen.org; Thu, 18 Dec 2014 17:56:34 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	25/F6-17694-15513945; Thu, 18 Dec 2014 17:56:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418925391!10007025!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 20928 invoked from network); 18 Dec 2014 17:56:33 -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 Dec 2014 17:56:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="205906071"
Message-ID: <54931527.3070204@citrix.com>
Date: Thu, 18 Dec 2014 17:55:51 +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: David Vrabel <david.vrabel@citrix.com>, "Xen-devel@lists.xen.org"
	<Xen-devel@lists.xen.org>
References: <543BD686.3080006@citrix.com>
In-Reply-To: <543BD686.3080006@citrix.com>
X-DLP: MIA2
Cc: Jennifer Herbert <jennifer.herbert@citrix.com>
Subject: Re: [Xen-devel] Linux grant map/unmap improvement proposal (Draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/10/14 14:41, David Vrabel wrote:
> 
> Design
> ======

Jennifer has put together most of the initial implementation of this so
expect a full series some time next year.

It didn't quite end up as described here.

> Userspace address to page translation
> -------------------------------------
> 
> The m2p_override table shall be removed.
> 
> Each VMA (struct vm_struct) shall contain an additional pointer to an
> optional array of pages.  This array shall be sized to cover the full
> extent of the VMA.
> 
> The gntdev driver populates this array with the relevant pages for the
> foreign mappings as they are mapped.  It shall also clear them when
> unmapping.  The gntdev driver must ensure it properly splits the page
> array when the VMA itself is split.
> 
> Since the m2p lookup will not return a local PFN, the native
> get_user_pages_fast() call will fail.  Prior to attempting to fault in
> the pages, get_user_pages() can simply look up the pages in the VMA's
> page array.

This was not true.  Instead, we mark the userspace PTEs as special
(_PAGE_SPECIAL set) which causes the generic x86 code to skip the fast path.

We also changed vm_normal_page() to look in vma->pages which puts the
extra code outside of any common use case (i.e., away from any handling
of non-special mappings), further reducing the impact on existing use cases.

For the curious, the 3-liner mm/memory.c change is below (although this
does not handle VMA splitting yet, but that should be straight-forwards).

> Userspace grant performance
> ---------------------------
> 
> - Lazily map grants into userspace on faults.  For applications that
>   do not access the foreign frames by the userspace mappings (such as
>   block backends using direct I/O) this would avoid a set of maps and
>   unmaps. This lazy mode would have to be requested by the userspace
>   program (since faulting many pages would be much more expensive than
>   a single batched map).

This does not look possible without more invasive changes to core MM
code.  Although we can lazily fault in the mappings we still need PTEs
to allow get_user_pages() to work, so map-on-fault isn't useful.

David

--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -289,6 +289,7 @@ struct vm_area_struct {
 #ifdef CONFIG_NUMA
 	struct mempolicy *vm_policy;	/* NUMA policy for the VMA */
 #endif
+	struct page	**pages;
 };

 struct core_thread {
diff --git a/mm/memory.c b/mm/memory.c
index 4b60011..3ca13bb 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -774,6 +774,8 @@ struct page *vm_normal_page(struct vm_area_struct
*vma, unsigned long addr,
 	if (HAVE_PTE_SPECIAL) {
 		if (likely(!pte_special(pte)))
 			goto check_pfn;
+		if (vma->pages)
+			return vma->pages[(addr - vma->vm_start) >> PAGE_SHIFT];
 		if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
 			return NULL;
 		if (!is_zero_pfn(pfn))
-- 
1.7.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 Dec 18 18:04:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 18: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 1Y1fQl-0007eV-6n; Thu, 18 Dec 2014 18:04:07 +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 1Y1fQf-0007eQ-NK
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 18:04:05 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	08/27-24124-01713945; Thu, 18 Dec 2014 18:04:00 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418925838!14174121!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 8038 invoked from network); 18 Dec 2014 18:04:00 -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;
	18 Dec 2014 18:04:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="205909734"
Message-ID: <549316D1.4060707@citrix.com>
Date: Thu, 18 Dec 2014 18:02: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: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>, Aravind
	Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
X-DLP: MIA1
Cc: Jan Beulich <JBeulich@suse.com>, Xen-devel List <xen-devel@lists.xen.org>
Subject: [Xen-devel] Spinlock inversion in amd/iommu_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

Hi,

XenServers Coverity scanning has identified a spinlock inversion, where
enable_iommu() takes the iommu lock and irq_desc lock in an opposite
order to the rest of the interrupt handling.  (I suspect Coverity Scan
is not identifying this as it is not configured to perform function
pointer analysis.)

This codepath is used during boot, and on resume from S3, and presumably
has not been hit in practice as the irq_desc lock is only taken when
interrupts from the IOMMU are quiesced.

In terms of fixing the locking inversion, I think the affinity setting
part of enable_iommu() can safely move to set_iommu_interrupt_handler().

Having said that, it occurs to me that nothing currently changes the msi
affinity at all, as cpus come up and down.  Furthermore, it seems unwise
to have the affinity any bigger than the local numa set anyway, as this
interrupt is specifically not associated with a vcpu.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 18:04:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 18: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 1Y1fQl-0007eV-6n; Thu, 18 Dec 2014 18:04:07 +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 1Y1fQf-0007eQ-NK
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 18:04:05 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	08/27-24124-01713945; Thu, 18 Dec 2014 18:04:00 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418925838!14174121!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 8038 invoked from network); 18 Dec 2014 18:04:00 -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;
	18 Dec 2014 18:04:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="205909734"
Message-ID: <549316D1.4060707@citrix.com>
Date: Thu, 18 Dec 2014 18:02: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: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>, Aravind
	Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
X-DLP: MIA1
Cc: Jan Beulich <JBeulich@suse.com>, Xen-devel List <xen-devel@lists.xen.org>
Subject: [Xen-devel] Spinlock inversion in amd/iommu_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

Hi,

XenServers Coverity scanning has identified a spinlock inversion, where
enable_iommu() takes the iommu lock and irq_desc lock in an opposite
order to the rest of the interrupt handling.  (I suspect Coverity Scan
is not identifying this as it is not configured to perform function
pointer analysis.)

This codepath is used during boot, and on resume from S3, and presumably
has not been hit in practice as the irq_desc lock is only taken when
interrupts from the IOMMU are quiesced.

In terms of fixing the locking inversion, I think the affinity setting
part of enable_iommu() can safely move to set_iommu_interrupt_handler().

Having said that, it occurs to me that nothing currently changes the msi
affinity at all, as cpus come up and down.  Furthermore, it seems unwise
to have the affinity any bigger than the local numa set anyway, as this
interrupt is specifically not associated with a vcpu.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 18:28:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 18:28:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1fnd-0000CF-CD; Thu, 18 Dec 2014 18:27:45 +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 1Y1fnc-0000C8-SO
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 18:27:44 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	4F/25-25727-0AC13945; Thu, 18 Dec 2014 18:27:44 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418927261!14309712!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 24817 invoked from network); 18 Dec 2014 18:27:43 -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 Dec 2014 18:27:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="205921390"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 18 Dec 2014 19:27:03 +0100
Message-ID: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.9.3 (Apple Git-50)
MIME-Version: 1.0
X-DLP: MIA2
Subject: [Xen-devel] [PATCH v1 for-4.6 1/2] xen: fixes for PVH Dom0 MMIO
	regions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

This series contains a bug-fix for PVH Dom0, that prevents Xen from adding 
MMIO regions that should not be accesible to Dom0. The second patch also 
prevents Dom0 from accessing the HPET, which AFAICT is used by Xen.

I'm not sure if there's a reason why the HPET MMIO region wasn't added to 
iomem_deny_access, but I don't think Dom0 should access it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 18:28:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 18:28:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1fnd-0000CF-CD; Thu, 18 Dec 2014 18:27:45 +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 1Y1fnc-0000C8-SO
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 18:27:44 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	4F/25-25727-0AC13945; Thu, 18 Dec 2014 18:27:44 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418927261!14309712!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 24817 invoked from network); 18 Dec 2014 18:27:43 -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 Dec 2014 18:27:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="205921390"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 18 Dec 2014 19:27:03 +0100
Message-ID: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.9.3 (Apple Git-50)
MIME-Version: 1.0
X-DLP: MIA2
Subject: [Xen-devel] [PATCH v1 for-4.6 1/2] xen: fixes for PVH Dom0 MMIO
	regions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

This series contains a bug-fix for PVH Dom0, that prevents Xen from adding 
MMIO regions that should not be accesible to Dom0. The second patch also 
prevents Dom0 from accessing the HPET, which AFAICT is used by Xen.

I'm not sure if there's a reason why the HPET MMIO region wasn't added to 
iomem_deny_access, but I don't think Dom0 should access it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 18:33:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 18:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ftH-0000jg-5V; Thu, 18 Dec 2014 18:33:35 +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 1Y1ftG-0000jb-Bd
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 18:33:34 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	35/77-16982-DFD13945; Thu, 18 Dec 2014 18:33:33 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418927611!14460445!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8218 invoked from network); 18 Dec 2014 18:33:33 -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;
	18 Dec 2014 18:33:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="206401256"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 18 Dec 2014 19:27:04 +0100
Message-ID: <1418927225-60266-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.9.3 (Apple Git-50)
In-Reply-To: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Length: 2854
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v1 for-4.6 1/2] xen/pvh: check permissions when
	adding MMIO regions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Q2hlY2sgdGhhdCBNTUlPIHJlZ2lvbnMgYWRkZWQgdG8gUFZIIERvbTAgYXJlIGFsbG93ZWQuIFBy
ZXZpb3VzbHkgYSBQVkggRG9tMAp3b3VsZCBoYXZlIGFjY2VzcyB0byB0aGUgZnVsbCBNTUlPIHJh
bmdlLgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j
b20+CkNjOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CkNjOiBBbmRyZXcgQ29vcGVy
IDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgotLS0KIHhlbi9hcmNoL3g4Ni9kb21haW5fYnVp
bGQuYyB8IDMxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIDEgZmlsZSBjaGFuZ2Vk
LCAzMSBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2RvbWFpbl9idWls
ZC5jIGIveGVuL2FyY2gveDg2L2RvbWFpbl9idWlsZC5jCmluZGV4IDdhNmFmZWEuLmFhM2JmMGYg
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9kb21haW5fYnVpbGQuYworKysgYi94ZW4vYXJjaC94
ODYvZG9tYWluX2J1aWxkLmMKQEAgLTMxMiwxNiArMzEyLDQ3IEBAIHN0YXRpYyBfX2luaXQgdm9p
ZCBwdmhfYWRkX21lbV9tYXBwaW5nKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGxvbmcgZ2Zu
LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBt
Zm4sIHVuc2lnbmVkIGxvbmcgbnJfbWZucykKIHsKICAgICB1bnNpZ25lZCBsb25nIGk7CisgICAg
eGVubWVtX2FjY2Vzc190IGRlZl9hY2Nlc3M7CisgICAgYm9vbF90IHJfb25seSA9IGZhbHNlOwog
ICAgIGludCByYzsKIAogICAgIGZvciAoIGkgPSAwOyBpIDwgbnJfbWZuczsgaSsrICkKICAgICB7
CisgICAgICAgIGlmICggIWlvbWVtX2FjY2Vzc19wZXJtaXR0ZWQoZCwgbWZuICsgaSwgbWZuICsg
aSkgKQorICAgICAgICAgICAgZ290byBuZXh0OworCisgICAgICAgIGlmICggcmFuZ2VzZXRfY29u
dGFpbnNfc2luZ2xldG9uKG1taW9fcm9fcmFuZ2VzLCBtZm4gKyBpKSAmJiAhcl9vbmx5ICkKKyAg
ICAgICAgeworICAgICAgICAgICAgcmMgPSBwMm1fZ2V0X21lbV9hY2Nlc3MoZCwgfjB1bCwgJmRl
Zl9hY2Nlc3MpOworICAgICAgICAgICAgQlVHX09OKHJjKTsKKyAgICAgICAgICAgIC8qIFNldCBk
ZWZhdWx0IGFjY2VzcyB0byByZWFkLW9ubHkgKi8KKyAgICAgICAgICAgIHJjID0gcDJtX3NldF9t
ZW1fYWNjZXNzKGQsIH4wdWwsIDAsIDAsIDAsIFhFTk1FTV9hY2Nlc3Nfcik7CisgICAgICAgICAg
ICBCVUdfT04ocmMpOworICAgICAgICAgICAgcl9vbmx5ID0gdHJ1ZTsKKyAgICAgICAgfQorICAg
ICAgICBlbHNlIGlmICggcl9vbmx5ICkKKyAgICAgICAgeworICAgICAgICAgICAgLyogU2V0IHRo
ZSBkZWZhdWx0IGJhY2sgKi8KKyAgICAgICAgICAgIHJjID0gcDJtX3NldF9tZW1fYWNjZXNzKGQs
IH4wdWwsIDAsIDAsIDAsIGRlZl9hY2Nlc3MpOworICAgICAgICAgICAgQlVHX09OKHJjKTsKKyAg
ICAgICAgICAgIHJfb25seSA9IGZhbHNlOworICAgICAgICB9CisKICAgICAgICAgaWYgKCAocmMg
PSBzZXRfbW1pb19wMm1fZW50cnkoZCwgZ2ZuICsgaSwgX21mbihtZm4gKyBpKSkpICkKICAgICAg
ICAgICAgIHBhbmljKCJwdmhfYWRkX21lbV9tYXBwaW5nOiBnZm46JWx4IG1mbjolbHggaTolbGQg
cmM6JWRcbiIsCiAgICAgICAgICAgICAgICAgICBnZm4sIG1mbiwgaSwgcmMpOworCisgbmV4dDoK
ICAgICAgICAgaWYgKCAhKGkgJiAweGZmZmZmKSApCiAgICAgICAgICAgICAgICAgcHJvY2Vzc19w
ZW5kaW5nX3NvZnRpcnFzKCk7CiAgICAgfQorCisgICAgaWYgKCByX29ubHkgKQorICAgIHsKKyAg
ICAgICAgLyogU2V0IHRoZSBkZWZhdWx0IGJhY2sgKi8KKyAgICAgICAgcmMgPSBwMm1fc2V0X21l
bV9hY2Nlc3MoZCwgfjB1bCwgMCwgMCwgMCwgZGVmX2FjY2Vzcyk7CisgICAgICAgIEJVR19PTihy
Yyk7CisgICAgfQogfQogCiAvKgotLSAKMS45LjMgKEFwcGxlIEdpdC01MCkKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Thu Dec 18 18:33:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 18:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ftJ-0000jw-HD; Thu, 18 Dec 2014 18:33:37 +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 1Y1ftH-0000jm-Ui
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 18:33:36 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	BF/E1-09284-FFD13945; Thu, 18 Dec 2014 18:33:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418927611!14460445!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 8621 invoked from network); 18 Dec 2014 18:33:34 -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;
	18 Dec 2014 18:33:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="206401258"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 18 Dec 2014 19:27:05 +0100
Message-ID: <1418927225-60266-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.9.3 (Apple Git-50)
In-Reply-To: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Length: 1682
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET from
	Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UHJldmVudCBEb20wIGZyb20gYWNjZXNzaW5nIEhQRVQgTU1JTyByZWdpb24gYnkgYWRkaW5nIGl0
IHRvIHRoZSBsaXN0IG9mCmRlbmllZCBtZW1vcnkgcmVnaW9ucy4KClNpZ25lZC1vZmYtYnk6IFJv
Z2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpDYzogSmFuIEJldWxpY2ggPGpi
ZXVsaWNoQHN1c2UuY29tPgpDYzogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4
LmNvbT4KLS0tCiB4ZW4vYXJjaC94ODYvZG9tYWluX2J1aWxkLmMgfCAxMiArKysrKysrKysrKysK
IDEgZmlsZSBjaGFuZ2VkLCAxMiBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2RvbWFpbl9idWlsZC5jIGIveGVuL2FyY2gveDg2L2RvbWFpbl9idWlsZC5jCmluZGV4IGFh
M2JmMGYuLjc4OGY3ZGIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9kb21haW5fYnVpbGQuYwor
KysgYi94ZW4vYXJjaC94ODYvZG9tYWluX2J1aWxkLmMKQEAgLTM2LDYgKzM2LDkgQEAKICNpbmNs
dWRlIDxhc20vYnppbWFnZS5oPiAvKiBmb3IgYnppbWFnZV9wYXJzZSAqLwogI2luY2x1ZGUgPGFz
bS9pb19hcGljLmg+CiAjaW5jbHVkZSA8YXNtL2hhcC5oPgorI2lmZGVmIENPTkZJR19IUEVUX1RJ
TUVSCisjaW5jbHVkZSA8YXNtL2hwZXQuaD4gLyogZm9yIGhwZXRfYWRkcmVzcyAqLworI2VuZGlm
CiAKICNpbmNsdWRlIDxwdWJsaWMvdmVyc2lvbi5oPgogCkBAIC0xNTE2LDYgKzE1MTksMTUgQEAg
aW50IF9faW5pdCBjb25zdHJ1Y3RfZG9tMCgKICAgICAgICAgICAgIHJjIHw9IGlvbWVtX2Rlbnlf
YWNjZXNzKGQsIHNmbiwgZWZuKTsKICAgICB9CiAKKyNpZmRlZiBDT05GSUdfSFBFVF9USU1FUgor
ICAgIC8qIFByZXZlbnQgYWNjZXNzIHRvIEhQRVQgKi8KKyAgICBpZiAoIGhwZXRfYWRkcmVzcyAh
PSAwICkKKyAgICB7CisgICAgICAgIG1mbiA9IHBhZGRyX3RvX3BmbihocGV0X2FkZHJlc3MpOwor
ICAgICAgICByYyB8PSBpb21lbV9kZW55X2FjY2VzcyhkLCBtZm4sIG1mbik7CisgICAgfQorI2Vu
ZGlmCisKICAgICBCVUdfT04ocmMgIT0gMCk7CiAKICAgICBpZiAoIGVsZl9jaGVja19icm9rZW4o
JmVsZikgKQotLSAKMS45LjMgKEFwcGxlIEdpdC01MCkKCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Dec 18 18:33:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 18:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ftH-0000jg-5V; Thu, 18 Dec 2014 18:33:35 +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 1Y1ftG-0000jb-Bd
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 18:33:34 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	35/77-16982-DFD13945; Thu, 18 Dec 2014 18:33:33 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418927611!14460445!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 8218 invoked from network); 18 Dec 2014 18:33:33 -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;
	18 Dec 2014 18:33:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="206401256"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 18 Dec 2014 19:27:04 +0100
Message-ID: <1418927225-60266-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.9.3 (Apple Git-50)
In-Reply-To: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Length: 2854
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v1 for-4.6 1/2] xen/pvh: check permissions when
	adding MMIO regions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Q2hlY2sgdGhhdCBNTUlPIHJlZ2lvbnMgYWRkZWQgdG8gUFZIIERvbTAgYXJlIGFsbG93ZWQuIFBy
ZXZpb3VzbHkgYSBQVkggRG9tMAp3b3VsZCBoYXZlIGFjY2VzcyB0byB0aGUgZnVsbCBNTUlPIHJh
bmdlLgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j
b20+CkNjOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CkNjOiBBbmRyZXcgQ29vcGVy
IDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgotLS0KIHhlbi9hcmNoL3g4Ni9kb21haW5fYnVp
bGQuYyB8IDMxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIDEgZmlsZSBjaGFuZ2Vk
LCAzMSBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2RvbWFpbl9idWls
ZC5jIGIveGVuL2FyY2gveDg2L2RvbWFpbl9idWlsZC5jCmluZGV4IDdhNmFmZWEuLmFhM2JmMGYg
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9kb21haW5fYnVpbGQuYworKysgYi94ZW4vYXJjaC94
ODYvZG9tYWluX2J1aWxkLmMKQEAgLTMxMiwxNiArMzEyLDQ3IEBAIHN0YXRpYyBfX2luaXQgdm9p
ZCBwdmhfYWRkX21lbV9tYXBwaW5nKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGxvbmcgZ2Zu
LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBt
Zm4sIHVuc2lnbmVkIGxvbmcgbnJfbWZucykKIHsKICAgICB1bnNpZ25lZCBsb25nIGk7CisgICAg
eGVubWVtX2FjY2Vzc190IGRlZl9hY2Nlc3M7CisgICAgYm9vbF90IHJfb25seSA9IGZhbHNlOwog
ICAgIGludCByYzsKIAogICAgIGZvciAoIGkgPSAwOyBpIDwgbnJfbWZuczsgaSsrICkKICAgICB7
CisgICAgICAgIGlmICggIWlvbWVtX2FjY2Vzc19wZXJtaXR0ZWQoZCwgbWZuICsgaSwgbWZuICsg
aSkgKQorICAgICAgICAgICAgZ290byBuZXh0OworCisgICAgICAgIGlmICggcmFuZ2VzZXRfY29u
dGFpbnNfc2luZ2xldG9uKG1taW9fcm9fcmFuZ2VzLCBtZm4gKyBpKSAmJiAhcl9vbmx5ICkKKyAg
ICAgICAgeworICAgICAgICAgICAgcmMgPSBwMm1fZ2V0X21lbV9hY2Nlc3MoZCwgfjB1bCwgJmRl
Zl9hY2Nlc3MpOworICAgICAgICAgICAgQlVHX09OKHJjKTsKKyAgICAgICAgICAgIC8qIFNldCBk
ZWZhdWx0IGFjY2VzcyB0byByZWFkLW9ubHkgKi8KKyAgICAgICAgICAgIHJjID0gcDJtX3NldF9t
ZW1fYWNjZXNzKGQsIH4wdWwsIDAsIDAsIDAsIFhFTk1FTV9hY2Nlc3Nfcik7CisgICAgICAgICAg
ICBCVUdfT04ocmMpOworICAgICAgICAgICAgcl9vbmx5ID0gdHJ1ZTsKKyAgICAgICAgfQorICAg
ICAgICBlbHNlIGlmICggcl9vbmx5ICkKKyAgICAgICAgeworICAgICAgICAgICAgLyogU2V0IHRo
ZSBkZWZhdWx0IGJhY2sgKi8KKyAgICAgICAgICAgIHJjID0gcDJtX3NldF9tZW1fYWNjZXNzKGQs
IH4wdWwsIDAsIDAsIDAsIGRlZl9hY2Nlc3MpOworICAgICAgICAgICAgQlVHX09OKHJjKTsKKyAg
ICAgICAgICAgIHJfb25seSA9IGZhbHNlOworICAgICAgICB9CisKICAgICAgICAgaWYgKCAocmMg
PSBzZXRfbW1pb19wMm1fZW50cnkoZCwgZ2ZuICsgaSwgX21mbihtZm4gKyBpKSkpICkKICAgICAg
ICAgICAgIHBhbmljKCJwdmhfYWRkX21lbV9tYXBwaW5nOiBnZm46JWx4IG1mbjolbHggaTolbGQg
cmM6JWRcbiIsCiAgICAgICAgICAgICAgICAgICBnZm4sIG1mbiwgaSwgcmMpOworCisgbmV4dDoK
ICAgICAgICAgaWYgKCAhKGkgJiAweGZmZmZmKSApCiAgICAgICAgICAgICAgICAgcHJvY2Vzc19w
ZW5kaW5nX3NvZnRpcnFzKCk7CiAgICAgfQorCisgICAgaWYgKCByX29ubHkgKQorICAgIHsKKyAg
ICAgICAgLyogU2V0IHRoZSBkZWZhdWx0IGJhY2sgKi8KKyAgICAgICAgcmMgPSBwMm1fc2V0X21l
bV9hY2Nlc3MoZCwgfjB1bCwgMCwgMCwgMCwgZGVmX2FjY2Vzcyk7CisgICAgICAgIEJVR19PTihy
Yyk7CisgICAgfQogfQogCiAvKgotLSAKMS45LjMgKEFwcGxlIEdpdC01MCkKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Thu Dec 18 18:33:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 18:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ftJ-0000jw-HD; Thu, 18 Dec 2014 18:33:37 +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 1Y1ftH-0000jm-Ui
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 18:33:36 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	BF/E1-09284-FFD13945; Thu, 18 Dec 2014 18:33:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418927611!14460445!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 8621 invoked from network); 18 Dec 2014 18:33:34 -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;
	18 Dec 2014 18:33:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="206401258"
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Date: Thu, 18 Dec 2014 19:27:05 +0100
Message-ID: <1418927225-60266-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.9.3 (Apple Git-50)
In-Reply-To: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Length: 1682
X-DLP: MIA1
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET from
	Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UHJldmVudCBEb20wIGZyb20gYWNjZXNzaW5nIEhQRVQgTU1JTyByZWdpb24gYnkgYWRkaW5nIGl0
IHRvIHRoZSBsaXN0IG9mCmRlbmllZCBtZW1vcnkgcmVnaW9ucy4KClNpZ25lZC1vZmYtYnk6IFJv
Z2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpDYzogSmFuIEJldWxpY2ggPGpi
ZXVsaWNoQHN1c2UuY29tPgpDYzogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4
LmNvbT4KLS0tCiB4ZW4vYXJjaC94ODYvZG9tYWluX2J1aWxkLmMgfCAxMiArKysrKysrKysrKysK
IDEgZmlsZSBjaGFuZ2VkLCAxMiBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2RvbWFpbl9idWlsZC5jIGIveGVuL2FyY2gveDg2L2RvbWFpbl9idWlsZC5jCmluZGV4IGFh
M2JmMGYuLjc4OGY3ZGIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9kb21haW5fYnVpbGQuYwor
KysgYi94ZW4vYXJjaC94ODYvZG9tYWluX2J1aWxkLmMKQEAgLTM2LDYgKzM2LDkgQEAKICNpbmNs
dWRlIDxhc20vYnppbWFnZS5oPiAvKiBmb3IgYnppbWFnZV9wYXJzZSAqLwogI2luY2x1ZGUgPGFz
bS9pb19hcGljLmg+CiAjaW5jbHVkZSA8YXNtL2hhcC5oPgorI2lmZGVmIENPTkZJR19IUEVUX1RJ
TUVSCisjaW5jbHVkZSA8YXNtL2hwZXQuaD4gLyogZm9yIGhwZXRfYWRkcmVzcyAqLworI2VuZGlm
CiAKICNpbmNsdWRlIDxwdWJsaWMvdmVyc2lvbi5oPgogCkBAIC0xNTE2LDYgKzE1MTksMTUgQEAg
aW50IF9faW5pdCBjb25zdHJ1Y3RfZG9tMCgKICAgICAgICAgICAgIHJjIHw9IGlvbWVtX2Rlbnlf
YWNjZXNzKGQsIHNmbiwgZWZuKTsKICAgICB9CiAKKyNpZmRlZiBDT05GSUdfSFBFVF9USU1FUgor
ICAgIC8qIFByZXZlbnQgYWNjZXNzIHRvIEhQRVQgKi8KKyAgICBpZiAoIGhwZXRfYWRkcmVzcyAh
PSAwICkKKyAgICB7CisgICAgICAgIG1mbiA9IHBhZGRyX3RvX3BmbihocGV0X2FkZHJlc3MpOwor
ICAgICAgICByYyB8PSBpb21lbV9kZW55X2FjY2VzcyhkLCBtZm4sIG1mbik7CisgICAgfQorI2Vu
ZGlmCisKICAgICBCVUdfT04ocmMgIT0gMCk7CiAKICAgICBpZiAoIGVsZl9jaGVja19icm9rZW4o
JmVsZikgKQotLSAKMS45LjMgKEFwcGxlIEdpdC01MCkKCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Dec 18 18:41:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 18:41:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1g0v-00010P-F9; Thu, 18 Dec 2014 18: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 1Y1g0t-00010K-SK
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 18:41:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FB/CE-25276-7DF13945; Thu, 18 Dec 2014 18:41:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418928083!16614750!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11467 invoked from network); 18 Dec 2014 18:41:24 -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;
	18 Dec 2014 18:41:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="206407315"
Message-ID: <54931F5C.4000403@citrix.com>
Date: Thu, 18 Dec 2014 18:39: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: Roger Pau Monne <roger.pau@citrix.com>, <xen-devel@lists.xenproject.org>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 1/2] xen: fixes for PVH Dom0 MMIO
 regions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 18:27, Roger Pau Monne wrote:
> Hello,
>
> This series contains a bug-fix for PVH Dom0, that prevents Xen from adding 
> MMIO regions that should not be accesible to Dom0. The second patch also 
> prevents Dom0 from accessing the HPET, which AFAICT is used by Xen.
>
> I'm not sure if there's a reason why the HPET MMIO region wasn't added to 
> iomem_deny_access, but I don't think Dom0 should access it.

The HPET region is awkward.  It is only 1024 bytes wide.

Dom0 may legitimately need access to other MMIO which lives in the
remainder of page.

Having said that, the HPET ACPI table does have a flag indicating that
the HPET page has nothing else in the remainder of the page.  We
probably should deny dom0 access in the case that the BIOS has told us
it is safe to do so.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 18:41:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 18:41:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1g0v-00010P-F9; Thu, 18 Dec 2014 18: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 1Y1g0t-00010K-SK
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 18:41:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	FB/CE-25276-7DF13945; Thu, 18 Dec 2014 18:41:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1418928083!16614750!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11467 invoked from network); 18 Dec 2014 18:41:24 -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;
	18 Dec 2014 18:41:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="206407315"
Message-ID: <54931F5C.4000403@citrix.com>
Date: Thu, 18 Dec 2014 18:39: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: Roger Pau Monne <roger.pau@citrix.com>, <xen-devel@lists.xenproject.org>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
X-DLP: MIA1
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 1/2] xen: fixes for PVH Dom0 MMIO
 regions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 18:27, Roger Pau Monne wrote:
> Hello,
>
> This series contains a bug-fix for PVH Dom0, that prevents Xen from adding 
> MMIO regions that should not be accesible to Dom0. The second patch also 
> prevents Dom0 from accessing the HPET, which AFAICT is used by Xen.
>
> I'm not sure if there's a reason why the HPET MMIO region wasn't added to 
> iomem_deny_access, but I don't think Dom0 should access it.

The HPET region is awkward.  It is only 1024 bytes wide.

Dom0 may legitimately need access to other MMIO which lives in the
remainder of page.

Having said that, the HPET ACPI table does have a flag indicating that
the HPET page has nothing else in the remainder of the page.  We
probably should deny dom0 access in the case that the BIOS has told us
it is safe to do so.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 18:52:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 18:52:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1gB9-0001hB-KU; Thu, 18 Dec 2014 18:52:03 +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 1Y1gB8-0001h6-DJ
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 18:52:02 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	71/82-16982-15223945; Thu, 18 Dec 2014 18:52:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418928719!14457792!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 24771 invoked from network); 18 Dec 2014 18:52:01 -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;
	18 Dec 2014 18:52:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="206413096"
Message-ID: <5493224D.9050001@citrix.com>
Date: Thu, 18 Dec 2014 18:51: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: Roger Pau Monne <roger.pau@citrix.com>, <xen-devel@lists.xenproject.org>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1418927225-60266-3-git-send-email-roger.pau@citrix.com>
Content-Length: 2108
X-DLP: MIA2
Cc: Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
	from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTgvMTIvMTQgMTg6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPiBQcmV2ZW50IERvbTAg
ZnJvbSBhY2Nlc3NpbmcgSFBFVCBNTUlPIHJlZ2lvbiBieSBhZGRpbmcgaXQgdG8gdGhlIGxpc3Qg
b2YKPiBkZW5pZWQgbWVtb3J5IHJlZ2lvbnMuCj4KPiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUg
TW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPiBDYzogSmFuIEJldWxpY2ggPGpiZXVsaWNo
QHN1c2UuY29tPgo+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29t
PgoKQXBvbG9naWVzIHRoYXQgdGhpcyByZXBseSBpcyBzcGxpdCBiZXR3ZWVuIHBhdGNoIDAgYW5k
IDIgLSBJIHJlcGxpZWQgdG8KeW91ciBjb3ZlciBsZXR0ZXIgYmVmb3JlIHJlYWRpbmcgdGhpcyBw
YXRjaC4KCkRlbnlpbmcgYWNjZXNzIGlzIG9ubHkgdmFsaWQgaWYgYWNwaV90YWJsZV9ocGV0LmZs
YWdzICYgCkFDUElfSFBFVF9QQUdFX1BST1RFQ1Q0IGlzIHRydWUuCgp+QW5kcmV3Cgo+IC0tLQo+
ICB4ZW4vYXJjaC94ODYvZG9tYWluX2J1aWxkLmMgfCAxMiArKysrKysrKysrKysKPiAgMSBmaWxl
IGNoYW5nZWQsIDEyIGluc2VydGlvbnMoKykKPgo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
ZG9tYWluX2J1aWxkLmMgYi94ZW4vYXJjaC94ODYvZG9tYWluX2J1aWxkLmMKPiBpbmRleCBhYTNi
ZjBmLi43ODhmN2RiIDEwMDY0NAo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9kb21haW5fYnVpbGQuYwo+
ICsrKyBiL3hlbi9hcmNoL3g4Ni9kb21haW5fYnVpbGQuYwo+IEBAIC0zNiw2ICszNiw5IEBACj4g
ICNpbmNsdWRlIDxhc20vYnppbWFnZS5oPiAvKiBmb3IgYnppbWFnZV9wYXJzZSAqLwo+ICAjaW5j
bHVkZSA8YXNtL2lvX2FwaWMuaD4KPiAgI2luY2x1ZGUgPGFzbS9oYXAuaD4KPiArI2lmZGVmIENP
TkZJR19IUEVUX1RJTUVSCj4gKyNpbmNsdWRlIDxhc20vaHBldC5oPiAvKiBmb3IgaHBldF9hZGRy
ZXNzICovCj4gKyNlbmRpZgo+ICAKPiAgI2luY2x1ZGUgPHB1YmxpYy92ZXJzaW9uLmg+Cj4gIAo+
IEBAIC0xNTE2LDYgKzE1MTksMTUgQEAgaW50IF9faW5pdCBjb25zdHJ1Y3RfZG9tMCgKPiAgICAg
ICAgICAgICAgcmMgfD0gaW9tZW1fZGVueV9hY2Nlc3MoZCwgc2ZuLCBlZm4pOwo+ICAgICAgfQo+
ICAKPiArI2lmZGVmIENPTkZJR19IUEVUX1RJTUVSCj4gKyAgICAvKiBQcmV2ZW50IGFjY2VzcyB0
byBIUEVUICovCj4gKyAgICBpZiAoIGhwZXRfYWRkcmVzcyAhPSAwICkKPiArICAgIHsKPiArICAg
ICAgICBtZm4gPSBwYWRkcl90b19wZm4oaHBldF9hZGRyZXNzKTsKPiArICAgICAgICByYyB8PSBp
b21lbV9kZW55X2FjY2VzcyhkLCBtZm4sIG1mbik7Cj4gKyAgICB9Cj4gKyNlbmRpZgo+ICsKPiAg
ICAgIEJVR19PTihyYyAhPSAwKTsKPiAgCj4gICAgICBpZiAoIGVsZl9jaGVja19icm9rZW4oJmVs
ZikgKQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Dec 18 18:52:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 18:52:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1gB9-0001hB-KU; Thu, 18 Dec 2014 18:52:03 +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 1Y1gB8-0001h6-DJ
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 18:52:02 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	71/82-16982-15223945; Thu, 18 Dec 2014 18:52:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418928719!14457792!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 24771 invoked from network); 18 Dec 2014 18:52:01 -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;
	18 Dec 2014 18:52:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="206413096"
Message-ID: <5493224D.9050001@citrix.com>
Date: Thu, 18 Dec 2014 18:51: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: Roger Pau Monne <roger.pau@citrix.com>, <xen-devel@lists.xenproject.org>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1418927225-60266-3-git-send-email-roger.pau@citrix.com>
Content-Length: 2108
X-DLP: MIA2
Cc: Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
	from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTgvMTIvMTQgMTg6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPiBQcmV2ZW50IERvbTAg
ZnJvbSBhY2Nlc3NpbmcgSFBFVCBNTUlPIHJlZ2lvbiBieSBhZGRpbmcgaXQgdG8gdGhlIGxpc3Qg
b2YKPiBkZW5pZWQgbWVtb3J5IHJlZ2lvbnMuCj4KPiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUg
TW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPiBDYzogSmFuIEJldWxpY2ggPGpiZXVsaWNo
QHN1c2UuY29tPgo+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29t
PgoKQXBvbG9naWVzIHRoYXQgdGhpcyByZXBseSBpcyBzcGxpdCBiZXR3ZWVuIHBhdGNoIDAgYW5k
IDIgLSBJIHJlcGxpZWQgdG8KeW91ciBjb3ZlciBsZXR0ZXIgYmVmb3JlIHJlYWRpbmcgdGhpcyBw
YXRjaC4KCkRlbnlpbmcgYWNjZXNzIGlzIG9ubHkgdmFsaWQgaWYgYWNwaV90YWJsZV9ocGV0LmZs
YWdzICYgCkFDUElfSFBFVF9QQUdFX1BST1RFQ1Q0IGlzIHRydWUuCgp+QW5kcmV3Cgo+IC0tLQo+
ICB4ZW4vYXJjaC94ODYvZG9tYWluX2J1aWxkLmMgfCAxMiArKysrKysrKysrKysKPiAgMSBmaWxl
IGNoYW5nZWQsIDEyIGluc2VydGlvbnMoKykKPgo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
ZG9tYWluX2J1aWxkLmMgYi94ZW4vYXJjaC94ODYvZG9tYWluX2J1aWxkLmMKPiBpbmRleCBhYTNi
ZjBmLi43ODhmN2RiIDEwMDY0NAo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9kb21haW5fYnVpbGQuYwo+
ICsrKyBiL3hlbi9hcmNoL3g4Ni9kb21haW5fYnVpbGQuYwo+IEBAIC0zNiw2ICszNiw5IEBACj4g
ICNpbmNsdWRlIDxhc20vYnppbWFnZS5oPiAvKiBmb3IgYnppbWFnZV9wYXJzZSAqLwo+ICAjaW5j
bHVkZSA8YXNtL2lvX2FwaWMuaD4KPiAgI2luY2x1ZGUgPGFzbS9oYXAuaD4KPiArI2lmZGVmIENP
TkZJR19IUEVUX1RJTUVSCj4gKyNpbmNsdWRlIDxhc20vaHBldC5oPiAvKiBmb3IgaHBldF9hZGRy
ZXNzICovCj4gKyNlbmRpZgo+ICAKPiAgI2luY2x1ZGUgPHB1YmxpYy92ZXJzaW9uLmg+Cj4gIAo+
IEBAIC0xNTE2LDYgKzE1MTksMTUgQEAgaW50IF9faW5pdCBjb25zdHJ1Y3RfZG9tMCgKPiAgICAg
ICAgICAgICAgcmMgfD0gaW9tZW1fZGVueV9hY2Nlc3MoZCwgc2ZuLCBlZm4pOwo+ICAgICAgfQo+
ICAKPiArI2lmZGVmIENPTkZJR19IUEVUX1RJTUVSCj4gKyAgICAvKiBQcmV2ZW50IGFjY2VzcyB0
byBIUEVUICovCj4gKyAgICBpZiAoIGhwZXRfYWRkcmVzcyAhPSAwICkKPiArICAgIHsKPiArICAg
ICAgICBtZm4gPSBwYWRkcl90b19wZm4oaHBldF9hZGRyZXNzKTsKPiArICAgICAgICByYyB8PSBp
b21lbV9kZW55X2FjY2VzcyhkLCBtZm4sIG1mbik7Cj4gKyAgICB9Cj4gKyNlbmRpZgo+ICsKPiAg
ICAgIEJVR19PTihyYyAhPSAwKTsKPiAgCj4gICAgICBpZiAoIGVsZl9jaGVja19icm9rZW4oJmVs
ZikgKQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Dec 18 19:06:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 19:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1gOq-0002Xp-1f; Thu, 18 Dec 2014 19:06:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Y1gOo-0002Xk-Dd
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 19:06:10 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	38/44-31453-1A523945; Thu, 18 Dec 2014 19:06:09 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418929567!14195137!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28368 invoked from network); 18 Dec 2014 19:06: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;
	18 Dec 2014 19:06:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="206419098"
Message-ID: <54932565.2020801@citrix.com>
Date: Thu, 18 Dec 2014 19:05:09 +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: Roger Pau Monne <roger.pau@citrix.com>, <xen-devel@lists.xenproject.org>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-2-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1418927225-60266-2-git-send-email-roger.pau@citrix.com>
X-DLP: MIA2
Cc: Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 1/2] xen/pvh: check permissions
 when adding MMIO regions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTgvMTIvMTQgMTg6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPiBDaGVjayB0aGF0IE1N
SU8gcmVnaW9ucyBhZGRlZCB0byBQVkggRG9tMCBhcmUgYWxsb3dlZC4gUHJldmlvdXNseSBhIFBW
SCBEb20wCj4gd291bGQgaGF2ZSBhY2Nlc3MgdG8gdGhlIGZ1bGwgTU1JTyByYW5nZS4KPgo+IFNp
Z25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgo+IENj
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Cj4gQ2M6IEFuZHJldyBDb29wZXIgPGFu
ZHJldy5jb29wZXIzQGNpdHJpeC5jb20+Cj4gLS0tCj4gIHhlbi9hcmNoL3g4Ni9kb21haW5fYnVp
bGQuYyB8IDMxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKPiAgMSBmaWxlIGNoYW5n
ZWQsIDMxIGluc2VydGlvbnMoKykKPgo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvZG9tYWlu
X2J1aWxkLmMgYi94ZW4vYXJjaC94ODYvZG9tYWluX2J1aWxkLmMKPiBpbmRleCA3YTZhZmVhLi5h
YTNiZjBmIDEwMDY0NAo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9kb21haW5fYnVpbGQuYwo+ICsrKyBi
L3hlbi9hcmNoL3g4Ni9kb21haW5fYnVpbGQuYwo+IEBAIC0zMTIsMTYgKzMxMiw0NyBAQCBzdGF0
aWMgX19pbml0IHZvaWQgcHZoX2FkZF9tZW1fbWFwcGluZyhzdHJ1Y3QgZG9tYWluICpkLCB1bnNp
Z25lZCBsb25nIGdmbiwKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
dW5zaWduZWQgbG9uZyBtZm4sIHVuc2lnbmVkIGxvbmcgbnJfbWZucykKPiAgewo+ICAgICAgdW5z
aWduZWQgbG9uZyBpOwo+ICsgICAgeGVubWVtX2FjY2Vzc190IGRlZl9hY2Nlc3M7Cj4gKyAgICBi
b29sX3Qgcl9vbmx5ID0gZmFsc2U7Cj4gICAgICBpbnQgcmM7Cj4gIAo+ICAgICAgZm9yICggaSA9
IDA7IGkgPCBucl9tZm5zOyBpKysgKQo+ICAgICAgewo+ICsgICAgICAgIGlmICggIWlvbWVtX2Fj
Y2Vzc19wZXJtaXR0ZWQoZCwgbWZuICsgaSwgbWZuICsgaSkgKQo+ICsgICAgICAgICAgICBnb3Rv
IG5leHQ7Cj4gKwo+ICsgICAgICAgIGlmICggcmFuZ2VzZXRfY29udGFpbnNfc2luZ2xldG9uKG1t
aW9fcm9fcmFuZ2VzLCBtZm4gKyBpKSAmJiAhcl9vbmx5ICkKPiArICAgICAgICB7Cj4gKyAgICAg
ICAgICAgIHJjID0gcDJtX2dldF9tZW1fYWNjZXNzKGQsIH4wdWwsICZkZWZfYWNjZXNzKTsKPiAr
ICAgICAgICAgICAgQlVHX09OKHJjKTsKPiArICAgICAgICAgICAgLyogU2V0IGRlZmF1bHQgYWNj
ZXNzIHRvIHJlYWQtb25seSAqLwo+ICsgICAgICAgICAgICByYyA9IHAybV9zZXRfbWVtX2FjY2Vz
cyhkLCB+MHVsLCAwLCAwLCAwLCBYRU5NRU1fYWNjZXNzX3IpOwo+ICsgICAgICAgICAgICBCVUdf
T04ocmMpOwo+ICsgICAgICAgICAgICByX29ubHkgPSB0cnVlOwo+ICsgICAgICAgIH0KPiArICAg
ICAgICBlbHNlIGlmICggcl9vbmx5ICkKPiArICAgICAgICB7Cj4gKyAgICAgICAgICAgIC8qIFNl
dCB0aGUgZGVmYXVsdCBiYWNrICovCj4gKyAgICAgICAgICAgIHJjID0gcDJtX3NldF9tZW1fYWNj
ZXNzKGQsIH4wdWwsIDAsIDAsIDAsIGRlZl9hY2Nlc3MpOwo+ICsgICAgICAgICAgICBCVUdfT04o
cmMpOwo+ICsgICAgICAgICAgICByX29ubHkgPSBmYWxzZTsKPiArICAgICAgICB9CgpBbSBJIG1p
c3Npbmcgc29tZXRoaW5nIG9idmlvdXMsIG9yIHdvdWxkIGFsbCB0aGlzIHJfb25seSBqdWdnbGlu
ZyBiZSBmYXIKbW9yZSBlYXN5IGlmIHNldF9tbWlvX3AybV9lbnRyeSgpIGhhZCBhIHJvL3J3IGJv
b2xlYW4gcGFyYW1ldGVyPwoKQXMgdGhlc2UgZW50cmllcyBhcmUgZG9uZSBvbmUgYXQgYSB0aW1l
LCBpdCB3b3VsZCBzZWVtIHRvIGJlIGZhciBsZXNzCmVycm9yIHByb25lIHRvIGV4cGxpY2l0bHkg
Y2hvb3NlIGEgcmVhZC1vbmx5IG9yIHJlYWQtd3JpdGUgbW1pbyBtYXBwaW5nLApyYXRoZXIgdGhh
biBwbGF5aW5nIHdpdGggdGhlIGVudGlyZSBkZWZhdWx0LgoKPiArCj4gICAgICAgICAgaWYgKCAo
cmMgPSBzZXRfbW1pb19wMm1fZW50cnkoZCwgZ2ZuICsgaSwgX21mbihtZm4gKyBpKSkpICkKPiAg
ICAgICAgICAgICAgcGFuaWMoInB2aF9hZGRfbWVtX21hcHBpbmc6IGdmbjolbHggbWZuOiVseCBp
OiVsZCByYzolZFxuIiwKPiAgICAgICAgICAgICAgICAgICAgZ2ZuLCBtZm4sIGksIHJjKTsKPiAr
Cj4gKyBuZXh0Ogo+ICAgICAgICAgIGlmICggIShpICYgMHhmZmZmZikgKQo+ICAgICAgICAgICAg
ICAgICAgcHJvY2Vzc19wZW5kaW5nX3NvZnRpcnFzKCk7CgpZb3UgY291bGQgcmVtb3ZlIHRoZSBu
ZXh0IGxhYmVsIGJ5IG1vdmluZyB0aGlzIGNsYXVzZSB0byB0aGUgdG9wIGFuZAphZGRpbmcgYW4g
aSAhPSAwIGNoZWNrLgoKPiAgICAgIH0KPiArCj4gKyAgICBpZiAoIHJfb25seSApCj4gKyAgICB7
Cj4gKyAgICAgICAgLyogU2V0IHRoZSBkZWZhdWx0IGJhY2sgKi8KPiArICAgICAgICByYyA9IHAy
bV9zZXRfbWVtX2FjY2VzcyhkLCB+MHVsLCAwLCAwLCAwLCBkZWZfYWNjZXNzKTsKClRoaXMgd2ls
bCBjbG9iYmVyIHRoZSBwMm0gZGVmYXVsdCBhY2Nlc3MgdHlwZSBiYXNlZCBvbiB3aGV0aGVyIHRo
ZSBmaW5hbAptZm4gaXMgcmVhZC1vbmx5IG9yIHJlYWQtd3JpdGUuCgp+QW5kcmV3Cgo+ICsgICAg
ICAgIEJVR19PTihyYyk7Cj4gKyAgICB9Cj4gIH0KPiAgCj4gIC8qCgoKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Dec 18 19:06:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 19:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1gOq-0002Xp-1f; Thu, 18 Dec 2014 19:06:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Y1gOo-0002Xk-Dd
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 19:06:10 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	38/44-31453-1A523945; Thu, 18 Dec 2014 19:06:09 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1418929567!14195137!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 28368 invoked from network); 18 Dec 2014 19:06: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;
	18 Dec 2014 19:06:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="206419098"
Message-ID: <54932565.2020801@citrix.com>
Date: Thu, 18 Dec 2014 19:05:09 +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: Roger Pau Monne <roger.pau@citrix.com>, <xen-devel@lists.xenproject.org>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-2-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1418927225-60266-2-git-send-email-roger.pau@citrix.com>
X-DLP: MIA2
Cc: Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 1/2] xen/pvh: check permissions
 when adding MMIO regions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTgvMTIvMTQgMTg6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPiBDaGVjayB0aGF0IE1N
SU8gcmVnaW9ucyBhZGRlZCB0byBQVkggRG9tMCBhcmUgYWxsb3dlZC4gUHJldmlvdXNseSBhIFBW
SCBEb20wCj4gd291bGQgaGF2ZSBhY2Nlc3MgdG8gdGhlIGZ1bGwgTU1JTyByYW5nZS4KPgo+IFNp
Z25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgo+IENj
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Cj4gQ2M6IEFuZHJldyBDb29wZXIgPGFu
ZHJldy5jb29wZXIzQGNpdHJpeC5jb20+Cj4gLS0tCj4gIHhlbi9hcmNoL3g4Ni9kb21haW5fYnVp
bGQuYyB8IDMxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKPiAgMSBmaWxlIGNoYW5n
ZWQsIDMxIGluc2VydGlvbnMoKykKPgo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvZG9tYWlu
X2J1aWxkLmMgYi94ZW4vYXJjaC94ODYvZG9tYWluX2J1aWxkLmMKPiBpbmRleCA3YTZhZmVhLi5h
YTNiZjBmIDEwMDY0NAo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9kb21haW5fYnVpbGQuYwo+ICsrKyBi
L3hlbi9hcmNoL3g4Ni9kb21haW5fYnVpbGQuYwo+IEBAIC0zMTIsMTYgKzMxMiw0NyBAQCBzdGF0
aWMgX19pbml0IHZvaWQgcHZoX2FkZF9tZW1fbWFwcGluZyhzdHJ1Y3QgZG9tYWluICpkLCB1bnNp
Z25lZCBsb25nIGdmbiwKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
dW5zaWduZWQgbG9uZyBtZm4sIHVuc2lnbmVkIGxvbmcgbnJfbWZucykKPiAgewo+ICAgICAgdW5z
aWduZWQgbG9uZyBpOwo+ICsgICAgeGVubWVtX2FjY2Vzc190IGRlZl9hY2Nlc3M7Cj4gKyAgICBi
b29sX3Qgcl9vbmx5ID0gZmFsc2U7Cj4gICAgICBpbnQgcmM7Cj4gIAo+ICAgICAgZm9yICggaSA9
IDA7IGkgPCBucl9tZm5zOyBpKysgKQo+ICAgICAgewo+ICsgICAgICAgIGlmICggIWlvbWVtX2Fj
Y2Vzc19wZXJtaXR0ZWQoZCwgbWZuICsgaSwgbWZuICsgaSkgKQo+ICsgICAgICAgICAgICBnb3Rv
IG5leHQ7Cj4gKwo+ICsgICAgICAgIGlmICggcmFuZ2VzZXRfY29udGFpbnNfc2luZ2xldG9uKG1t
aW9fcm9fcmFuZ2VzLCBtZm4gKyBpKSAmJiAhcl9vbmx5ICkKPiArICAgICAgICB7Cj4gKyAgICAg
ICAgICAgIHJjID0gcDJtX2dldF9tZW1fYWNjZXNzKGQsIH4wdWwsICZkZWZfYWNjZXNzKTsKPiAr
ICAgICAgICAgICAgQlVHX09OKHJjKTsKPiArICAgICAgICAgICAgLyogU2V0IGRlZmF1bHQgYWNj
ZXNzIHRvIHJlYWQtb25seSAqLwo+ICsgICAgICAgICAgICByYyA9IHAybV9zZXRfbWVtX2FjY2Vz
cyhkLCB+MHVsLCAwLCAwLCAwLCBYRU5NRU1fYWNjZXNzX3IpOwo+ICsgICAgICAgICAgICBCVUdf
T04ocmMpOwo+ICsgICAgICAgICAgICByX29ubHkgPSB0cnVlOwo+ICsgICAgICAgIH0KPiArICAg
ICAgICBlbHNlIGlmICggcl9vbmx5ICkKPiArICAgICAgICB7Cj4gKyAgICAgICAgICAgIC8qIFNl
dCB0aGUgZGVmYXVsdCBiYWNrICovCj4gKyAgICAgICAgICAgIHJjID0gcDJtX3NldF9tZW1fYWNj
ZXNzKGQsIH4wdWwsIDAsIDAsIDAsIGRlZl9hY2Nlc3MpOwo+ICsgICAgICAgICAgICBCVUdfT04o
cmMpOwo+ICsgICAgICAgICAgICByX29ubHkgPSBmYWxzZTsKPiArICAgICAgICB9CgpBbSBJIG1p
c3Npbmcgc29tZXRoaW5nIG9idmlvdXMsIG9yIHdvdWxkIGFsbCB0aGlzIHJfb25seSBqdWdnbGlu
ZyBiZSBmYXIKbW9yZSBlYXN5IGlmIHNldF9tbWlvX3AybV9lbnRyeSgpIGhhZCBhIHJvL3J3IGJv
b2xlYW4gcGFyYW1ldGVyPwoKQXMgdGhlc2UgZW50cmllcyBhcmUgZG9uZSBvbmUgYXQgYSB0aW1l
LCBpdCB3b3VsZCBzZWVtIHRvIGJlIGZhciBsZXNzCmVycm9yIHByb25lIHRvIGV4cGxpY2l0bHkg
Y2hvb3NlIGEgcmVhZC1vbmx5IG9yIHJlYWQtd3JpdGUgbW1pbyBtYXBwaW5nLApyYXRoZXIgdGhh
biBwbGF5aW5nIHdpdGggdGhlIGVudGlyZSBkZWZhdWx0LgoKPiArCj4gICAgICAgICAgaWYgKCAo
cmMgPSBzZXRfbW1pb19wMm1fZW50cnkoZCwgZ2ZuICsgaSwgX21mbihtZm4gKyBpKSkpICkKPiAg
ICAgICAgICAgICAgcGFuaWMoInB2aF9hZGRfbWVtX21hcHBpbmc6IGdmbjolbHggbWZuOiVseCBp
OiVsZCByYzolZFxuIiwKPiAgICAgICAgICAgICAgICAgICAgZ2ZuLCBtZm4sIGksIHJjKTsKPiAr
Cj4gKyBuZXh0Ogo+ICAgICAgICAgIGlmICggIShpICYgMHhmZmZmZikgKQo+ICAgICAgICAgICAg
ICAgICAgcHJvY2Vzc19wZW5kaW5nX3NvZnRpcnFzKCk7CgpZb3UgY291bGQgcmVtb3ZlIHRoZSBu
ZXh0IGxhYmVsIGJ5IG1vdmluZyB0aGlzIGNsYXVzZSB0byB0aGUgdG9wIGFuZAphZGRpbmcgYW4g
aSAhPSAwIGNoZWNrLgoKPiAgICAgIH0KPiArCj4gKyAgICBpZiAoIHJfb25seSApCj4gKyAgICB7
Cj4gKyAgICAgICAgLyogU2V0IHRoZSBkZWZhdWx0IGJhY2sgKi8KPiArICAgICAgICByYyA9IHAy
bV9zZXRfbWVtX2FjY2VzcyhkLCB+MHVsLCAwLCAwLCAwLCBkZWZfYWNjZXNzKTsKClRoaXMgd2ls
bCBjbG9iYmVyIHRoZSBwMm0gZGVmYXVsdCBhY2Nlc3MgdHlwZSBiYXNlZCBvbiB3aGV0aGVyIHRo
ZSBmaW5hbAptZm4gaXMgcmVhZC1vbmx5IG9yIHJlYWQtd3JpdGUuCgp+QW5kcmV3Cgo+ICsgICAg
ICAgIEJVR19PTihyYyk7Cj4gKyAgICB9Cj4gIH0KPiAgCj4gIC8qCgoKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Dec 18 19:24:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 19: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 1Y1ggG-0003Vc-Nd; Thu, 18 Dec 2014 19:24:12 +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 1Y1ggF-0003VX-7B
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 19:24:11 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	1C/4B-03148-AD923945; Thu, 18 Dec 2014 19:24:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418930648!16027016!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26602 invoked from network); 18 Dec 2014 19:24:09 -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; 18 Dec 2014 19:24:09 -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 sBIJNOEb026668
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Dec 2014 19:23:25 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
	sBIJNHA9006087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 18 Dec 2014 19:23: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
	sBIJNHHQ017103; Thu, 18 Dec 2014 19:23:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Dec 2014 11:23:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id AC609125B2D; Thu, 18 Dec 2014 14:23:14 -0500 (EST)
Date: Thu, 18 Dec 2014 14:23:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Message-ID: <20141218192313.GA19507@laptop.dumpdata.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: jgross@suse.com, peterz@infradead.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, mingo@redhat.com, david.vrabel@citrix.com,
	JBeulich@suse.com, hpa@zytor.com,
	masami.hiramatsu.pt@hitachi.com, xen-devel@lists.xenproject.org,
	tglx@linutronix.de, Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
 be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> index 0000000..b5a3e98
> --- /dev/null
> +++ b/drivers/xen/preempt.c
> @@ -0,0 +1,17 @@
> +/*
> + * Preemptible hypercalls
> + *
> + * Copyright (C) 2014 Citrix Systems R&D ltd.
> + *
> + * This source code is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + */
> +
> +#include <xen/xen-ops.h>
> +
> +#ifndef CONFIG_PREEMPT
> +DEFINE_PER_CPU(bool, xen_in_preemptible_hcall);
> +EXPORT_SYMBOL_GPL(xen_in_preemptible_hcall);
> +#endif

Please also add this in the patch:


diff --git a/drivers/xen/preempt.c b/drivers/xen/preempt.c
index b5a3e98..5d773dc 100644
--- a/drivers/xen/preempt.c
+++ b/drivers/xen/preempt.c
@@ -13,5 +13,5 @@
 
 #ifndef CONFIG_PREEMPT
 DEFINE_PER_CPU(bool, xen_in_preemptible_hcall);
-EXPORT_SYMBOL_GPL(xen_in_preemptible_hcall);
+EXPORT_PER_CPU_SYMBOL_GPL(xen_in_preemptible_hcall);
 #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 19:24:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 19: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 1Y1ggG-0003Vc-Nd; Thu, 18 Dec 2014 19:24:12 +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 1Y1ggF-0003VX-7B
	for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 19:24:11 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	1C/4B-03148-AD923945; Thu, 18 Dec 2014 19:24:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1418930648!16027016!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26602 invoked from network); 18 Dec 2014 19:24:09 -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; 18 Dec 2014 19:24:09 -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 sBIJNOEb026668
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Dec 2014 19:23:25 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
	sBIJNHA9006087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 18 Dec 2014 19:23: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
	sBIJNHHQ017103; Thu, 18 Dec 2014 19:23:17 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Dec 2014 11:23:17 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id AC609125B2D; Thu, 18 Dec 2014 14:23:14 -0500 (EST)
Date: Thu, 18 Dec 2014 14:23:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Message-ID: <20141218192313.GA19507@laptop.dumpdata.com>
References: <1418254487-9988-1-git-send-email-mcgrof@do-not-panic.com>
	<1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418254487-9988-3-git-send-email-mcgrof@do-not-panic.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: jgross@suse.com, peterz@infradead.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	luto@amacapital.net, mingo@redhat.com, david.vrabel@citrix.com,
	JBeulich@suse.com, hpa@zytor.com,
	masami.hiramatsu.pt@hitachi.com, xen-devel@lists.xenproject.org,
	tglx@linutronix.de, Borislav Petkov <bp@suse.de>, bpoirier@suse.de
Subject: Re: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to
 be preempted
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> index 0000000..b5a3e98
> --- /dev/null
> +++ b/drivers/xen/preempt.c
> @@ -0,0 +1,17 @@
> +/*
> + * Preemptible hypercalls
> + *
> + * Copyright (C) 2014 Citrix Systems R&D ltd.
> + *
> + * This source code is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + */
> +
> +#include <xen/xen-ops.h>
> +
> +#ifndef CONFIG_PREEMPT
> +DEFINE_PER_CPU(bool, xen_in_preemptible_hcall);
> +EXPORT_SYMBOL_GPL(xen_in_preemptible_hcall);
> +#endif

Please also add this in the patch:


diff --git a/drivers/xen/preempt.c b/drivers/xen/preempt.c
index b5a3e98..5d773dc 100644
--- a/drivers/xen/preempt.c
+++ b/drivers/xen/preempt.c
@@ -13,5 +13,5 @@
 
 #ifndef CONFIG_PREEMPT
 DEFINE_PER_CPU(bool, xen_in_preemptible_hcall);
-EXPORT_SYMBOL_GPL(xen_in_preemptible_hcall);
+EXPORT_PER_CPU_SYMBOL_GPL(xen_in_preemptible_hcall);
 #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 18 21:48:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 21:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ivu-0000Eu-OO; Thu, 18 Dec 2014 21:48:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <akorzan@gmail.com>) id 1Y1ivs-0000Eo-Qh
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 21:48:29 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	1D/CB-02694-CAB43945; Thu, 18 Dec 2014 21:48:28 +0000
X-Env-Sender: akorzan@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418939305!16063296!1
X-Originating-IP: [209.85.160.181]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23335 invoked from network); 18 Dec 2014 21:48:26 -0000
Received: from mail-yk0-f181.google.com (HELO mail-yk0-f181.google.com)
	(209.85.160.181)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 21:48:26 -0000
Received: by mail-yk0-f181.google.com with SMTP id 142so910452ykq.26
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 13:48:25 -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=kwcJcpbj7DK+nc9z8NHXi0cygHVGAkyAsOOXMksi6gw=;
	b=V6/PX/LnFLGAmSBJ5XyMlJ/NLCXrPvUXRpjEky9i+pyTJIURMUXHQmLX8iBfOjosk1
	+1seXJx+1VDl9HCckQtii23OxSbPRmOwTIj9szJzg+U9MPcbMGg+MNrNn7lSkSB2fl47
	NtKuq2JvLAkpqV3U2oYk7l9/7S+WRQHdYu3LWB1p2BBPLeWIYAokJQaIh2vkxL1q3a73
	K2ysPMZbLiCgc0fwwVsa5hE50tzZog4K5rHplMr5CvVpvIOZrcPaIXfhGg1IU0/LoiyC
	RvglpnBgbRussIabm6fCM+883jeHSEIAJ/GUKXeuGCwcyg8jK61xtSc3LG5H66Nh0oc1
	N2cg==
X-Received: by 10.170.150.213 with SMTP id r204mr4341629ykc.48.1418939305516; 
	Thu, 18 Dec 2014 13:48:25 -0800 (PST)
Received: from [192.168.1.12] (pool-72-83-187-210.washdc.fios.verizon.net.
	[72.83.187.210])
	by mx.google.com with ESMTPSA id s29sm4658364yhf.33.2014.12.18.13.48.23
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 18 Dec 2014 13:48:24 -0800 (PST)
From: Anthony Korzan <akorzan@gmail.com>
Date: Thu, 18 Dec 2014 16:48:26 -0500
Message-Id: <788CC804-7FC8-40C4-B17B-E02CDB7F2683@gmail.com>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Cc: rshriram@cs.ubc.ca, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [Xen 4.5-rc] remus-drbd incompatible with Linux 3.6+
	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: multipart/mixed; boundary="===============1412405884240860388=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1412405884240860388==
Content-Type: multipart/alternative; boundary="Apple-Mail=_65198439-598B-4081-AD97-C797BB088862"


--Apple-Mail=_65198439-598B-4081-AD97-C797BB088862
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello!

I have only managed to get Xen 4.5's Remus "working" on Linux Kernels =
less than 3.5. The provided remus-drbd, as detailed in docs/README.remus =
and available from https://github.com/rshriram/remus-drbd will not =
compile with Linux Kernels 3.6 and above.

One of these errors is that remus-drbd uses a two argument version of =
the macro kunmap_atomic found in include/linux/highmem.h
This was deprecated and is no longer included in any Kernels above 3.6.

"error: macro "kunmap_atomic" passed 2 arguments, but takes just 1"

Is there a patch available?  If not, what set up do the Remus devs use =
to test?  I just need a "stable-ish" platform to modify remus on.


Now I did get Remus "working" on Linux 3.4, Ubuntu 14.04, and the custom =
remus-drbd.  The issue I run into is that Remus only plugs and unplugs a =
few hundred times until there is a "Connection timeout error."  It could =
be that I am using an "old" linux kernel version without much Xen =
integration, but I'm stumped about this error:

###
...
xc: progress: Reloading memory pages: 895015/65536  1365%
xc: Saving memory: iter 1416 (last sent 568 skipped 0): 65536/65536  =
100%=20
...
xc: Saving memory: iter 1420 (last sent 567 skipped 0): 65536/65536  =
100%=20
xc: error: rdexact failed (select returned 0): Internal error
xc: error: Error when reading batch size (110 =3D Connection timed out): =
Internal error
xc: error: error when buffering batch, finishing (110 =3D Connection =
timed out): Internal error
migration target: Remus Failover for domain 5
libxl: error: libxl_utils.c:430:libxl_read_exactly: file/stream =
truncated reading ipc msg header from domain 5 save/restore helper =
stdout pipe
libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 5 =
save/restore helper [-1] died due to fatal signal Broken pipe
libxl: warning: libxl_dom.c:2015:domain_suspend_done: Remus: Domain =
suspend terminated with rc -3, teardown Remus devices...
Remus: Backup failed? resuming domain at primary.
xc: error: Dom 5 not suspended: (shutdown 0, reason 255): Internal error =
=20
libxl: error: libxl.c:505:libxl__domain_resume: xc_domain_resume failed =
for domain 5: Invalid argument
###

Sincerely,
Anthony=

--Apple-Mail=_65198439-598B-4081-AD97-C797BB088862
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;">Hello!<div><br></div><div>I have only managed to get =
Xen 4.5's Remus "working" on Linux Kernels less than 3.5. The provided =
remus-drbd, as detailed in docs/README.remus and available from&nbsp;<a =
href=3D"https://github.com/rshriram/remus-drbd">https://github.com/rshrira=
m/remus-drbd</a>&nbsp;will not compile with Linux Kernels 3.6 and =
above.</div><div><br></div><div>One of these errors is that remus-drbd =
uses a two argument version of the macro kunmap_atomic found in =
include/linux/highmem.h</div><div>This was deprecated and is no longer =
included in any Kernels above 3.6.</div><div><br></div><div>"error: =
macro "kunmap_atomic" passed 2 arguments, but takes just =
1"</div><div><br></div><div>Is there a patch available? &nbsp;If not, =
what set up do the Remus devs use to test? &nbsp;I just need a =
"stable-ish" platform to modify remus =
on.</div><div><br></div><div><br></div><div>Now I did get Remus =
"working" on Linux 3.4, Ubuntu 14.04, and the custom remus-drbd. =
&nbsp;The issue I run into is that Remus only plugs and unplugs a few =
hundred times until there is a "Connection timeout error." &nbsp;It =
could be that I am using an "old" linux kernel version without much Xen =
integration, but I'm stumped about this =
error:</div><div><br></div><div>###</div><div>...</div><div><div>xc: =
progress: Reloading memory pages: 895015/65536 &nbsp;1365%</div><div>xc: =
Saving memory: iter 1416 (last sent 568 skipped 0): 65536/65536 =
&nbsp;100%&nbsp;</div><div>...</div><div>xc: Saving memory: iter 1420 =
(last sent 567 skipped 0): 65536/65536 &nbsp;100%&nbsp;</div><div>xc: =
error: rdexact failed (select returned 0): Internal error</div><div>xc: =
error: Error when reading batch size (110 =3D Connection timed out): =
Internal error</div><div>xc: error: error when buffering batch, =
finishing (110 =3D Connection timed out): Internal =
error</div><div>migration target: Remus Failover for domain =
5</div><div>libxl: error: libxl_utils.c:430:libxl_read_exactly: =
file/stream truncated reading ipc msg header from domain 5 save/restore =
helper stdout pipe</div><div>libxl: error: =
libxl_exec.c:129:libxl_report_child_exitstatus: domain 5 save/restore =
helper [-1] died due to fatal signal Broken pipe</div><div>libxl: =
warning: libxl_dom.c:2015:domain_suspend_done: Remus: Domain suspend =
terminated with rc -3, teardown Remus devices...</div><div>Remus: Backup =
failed? resuming domain at primary.</div><div>xc: error: Dom 5 not =
suspended: (shutdown 0, reason 255): Internal error =
&nbsp;</div><div>libxl: error: libxl.c:505:libxl__domain_resume: =
xc_domain_resume failed for domain 5: Invalid =
argument</div></div><div>###</div><div><br></div><div>Sincerely,</div><div=
>Anthony</div></body></html>=

--Apple-Mail=_65198439-598B-4081-AD97-C797BB088862--


--===============1412405884240860388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1412405884240860388==--


From xen-devel-bounces@lists.xen.org Thu Dec 18 21:48:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 21:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ivu-0000Eu-OO; Thu, 18 Dec 2014 21:48:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <akorzan@gmail.com>) id 1Y1ivs-0000Eo-Qh
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 21:48:29 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	1D/CB-02694-CAB43945; Thu, 18 Dec 2014 21:48:28 +0000
X-Env-Sender: akorzan@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418939305!16063296!1
X-Originating-IP: [209.85.160.181]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23335 invoked from network); 18 Dec 2014 21:48:26 -0000
Received: from mail-yk0-f181.google.com (HELO mail-yk0-f181.google.com)
	(209.85.160.181)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 21:48:26 -0000
Received: by mail-yk0-f181.google.com with SMTP id 142so910452ykq.26
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 13:48:25 -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=kwcJcpbj7DK+nc9z8NHXi0cygHVGAkyAsOOXMksi6gw=;
	b=V6/PX/LnFLGAmSBJ5XyMlJ/NLCXrPvUXRpjEky9i+pyTJIURMUXHQmLX8iBfOjosk1
	+1seXJx+1VDl9HCckQtii23OxSbPRmOwTIj9szJzg+U9MPcbMGg+MNrNn7lSkSB2fl47
	NtKuq2JvLAkpqV3U2oYk7l9/7S+WRQHdYu3LWB1p2BBPLeWIYAokJQaIh2vkxL1q3a73
	K2ysPMZbLiCgc0fwwVsa5hE50tzZog4K5rHplMr5CvVpvIOZrcPaIXfhGg1IU0/LoiyC
	RvglpnBgbRussIabm6fCM+883jeHSEIAJ/GUKXeuGCwcyg8jK61xtSc3LG5H66Nh0oc1
	N2cg==
X-Received: by 10.170.150.213 with SMTP id r204mr4341629ykc.48.1418939305516; 
	Thu, 18 Dec 2014 13:48:25 -0800 (PST)
Received: from [192.168.1.12] (pool-72-83-187-210.washdc.fios.verizon.net.
	[72.83.187.210])
	by mx.google.com with ESMTPSA id s29sm4658364yhf.33.2014.12.18.13.48.23
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 18 Dec 2014 13:48:24 -0800 (PST)
From: Anthony Korzan <akorzan@gmail.com>
Date: Thu, 18 Dec 2014 16:48:26 -0500
Message-Id: <788CC804-7FC8-40C4-B17B-E02CDB7F2683@gmail.com>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Cc: rshriram@cs.ubc.ca, yanghy@cn.fujitsu.com
Subject: [Xen-devel] [Xen 4.5-rc] remus-drbd incompatible with Linux 3.6+
	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: multipart/mixed; boundary="===============1412405884240860388=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1412405884240860388==
Content-Type: multipart/alternative; boundary="Apple-Mail=_65198439-598B-4081-AD97-C797BB088862"


--Apple-Mail=_65198439-598B-4081-AD97-C797BB088862
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello!

I have only managed to get Xen 4.5's Remus "working" on Linux Kernels =
less than 3.5. The provided remus-drbd, as detailed in docs/README.remus =
and available from https://github.com/rshriram/remus-drbd will not =
compile with Linux Kernels 3.6 and above.

One of these errors is that remus-drbd uses a two argument version of =
the macro kunmap_atomic found in include/linux/highmem.h
This was deprecated and is no longer included in any Kernels above 3.6.

"error: macro "kunmap_atomic" passed 2 arguments, but takes just 1"

Is there a patch available?  If not, what set up do the Remus devs use =
to test?  I just need a "stable-ish" platform to modify remus on.


Now I did get Remus "working" on Linux 3.4, Ubuntu 14.04, and the custom =
remus-drbd.  The issue I run into is that Remus only plugs and unplugs a =
few hundred times until there is a "Connection timeout error."  It could =
be that I am using an "old" linux kernel version without much Xen =
integration, but I'm stumped about this error:

###
...
xc: progress: Reloading memory pages: 895015/65536  1365%
xc: Saving memory: iter 1416 (last sent 568 skipped 0): 65536/65536  =
100%=20
...
xc: Saving memory: iter 1420 (last sent 567 skipped 0): 65536/65536  =
100%=20
xc: error: rdexact failed (select returned 0): Internal error
xc: error: Error when reading batch size (110 =3D Connection timed out): =
Internal error
xc: error: error when buffering batch, finishing (110 =3D Connection =
timed out): Internal error
migration target: Remus Failover for domain 5
libxl: error: libxl_utils.c:430:libxl_read_exactly: file/stream =
truncated reading ipc msg header from domain 5 save/restore helper =
stdout pipe
libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 5 =
save/restore helper [-1] died due to fatal signal Broken pipe
libxl: warning: libxl_dom.c:2015:domain_suspend_done: Remus: Domain =
suspend terminated with rc -3, teardown Remus devices...
Remus: Backup failed? resuming domain at primary.
xc: error: Dom 5 not suspended: (shutdown 0, reason 255): Internal error =
=20
libxl: error: libxl.c:505:libxl__domain_resume: xc_domain_resume failed =
for domain 5: Invalid argument
###

Sincerely,
Anthony=

--Apple-Mail=_65198439-598B-4081-AD97-C797BB088862
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;">Hello!<div><br></div><div>I have only managed to get =
Xen 4.5's Remus "working" on Linux Kernels less than 3.5. The provided =
remus-drbd, as detailed in docs/README.remus and available from&nbsp;<a =
href=3D"https://github.com/rshriram/remus-drbd">https://github.com/rshrira=
m/remus-drbd</a>&nbsp;will not compile with Linux Kernels 3.6 and =
above.</div><div><br></div><div>One of these errors is that remus-drbd =
uses a two argument version of the macro kunmap_atomic found in =
include/linux/highmem.h</div><div>This was deprecated and is no longer =
included in any Kernels above 3.6.</div><div><br></div><div>"error: =
macro "kunmap_atomic" passed 2 arguments, but takes just =
1"</div><div><br></div><div>Is there a patch available? &nbsp;If not, =
what set up do the Remus devs use to test? &nbsp;I just need a =
"stable-ish" platform to modify remus =
on.</div><div><br></div><div><br></div><div>Now I did get Remus =
"working" on Linux 3.4, Ubuntu 14.04, and the custom remus-drbd. =
&nbsp;The issue I run into is that Remus only plugs and unplugs a few =
hundred times until there is a "Connection timeout error." &nbsp;It =
could be that I am using an "old" linux kernel version without much Xen =
integration, but I'm stumped about this =
error:</div><div><br></div><div>###</div><div>...</div><div><div>xc: =
progress: Reloading memory pages: 895015/65536 &nbsp;1365%</div><div>xc: =
Saving memory: iter 1416 (last sent 568 skipped 0): 65536/65536 =
&nbsp;100%&nbsp;</div><div>...</div><div>xc: Saving memory: iter 1420 =
(last sent 567 skipped 0): 65536/65536 &nbsp;100%&nbsp;</div><div>xc: =
error: rdexact failed (select returned 0): Internal error</div><div>xc: =
error: Error when reading batch size (110 =3D Connection timed out): =
Internal error</div><div>xc: error: error when buffering batch, =
finishing (110 =3D Connection timed out): Internal =
error</div><div>migration target: Remus Failover for domain =
5</div><div>libxl: error: libxl_utils.c:430:libxl_read_exactly: =
file/stream truncated reading ipc msg header from domain 5 save/restore =
helper stdout pipe</div><div>libxl: error: =
libxl_exec.c:129:libxl_report_child_exitstatus: domain 5 save/restore =
helper [-1] died due to fatal signal Broken pipe</div><div>libxl: =
warning: libxl_dom.c:2015:domain_suspend_done: Remus: Domain suspend =
terminated with rc -3, teardown Remus devices...</div><div>Remus: Backup =
failed? resuming domain at primary.</div><div>xc: error: Dom 5 not =
suspended: (shutdown 0, reason 255): Internal error =
&nbsp;</div><div>libxl: error: libxl.c:505:libxl__domain_resume: =
xc_domain_resume failed for domain 5: Invalid =
argument</div></div><div>###</div><div><br></div><div>Sincerely,</div><div=
>Anthony</div></body></html>=

--Apple-Mail=_65198439-598B-4081-AD97-C797BB088862--


--===============1412405884240860388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1412405884240860388==--


From xen-devel-bounces@lists.xen.org Thu Dec 18 22:36:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 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 1Y1jfz-0002Vz-Vv; Thu, 18 Dec 2014 22:36:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <syllopsium@syllopsium.co.uk>) id 1Y1jfy-0002Vu-KA
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 22:36:06 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	3E/A6-26740-5D653945; Thu, 18 Dec 2014 22:36:05 +0000
X-Env-Sender: syllopsium@syllopsium.co.uk
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418942163!14491950!1
X-Originating-IP: [209.85.214.177]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19799 invoked from network); 18 Dec 2014 22:36:05 -0000
Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com)
	(209.85.214.177)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 22:36:05 -0000
Received: by mail-ob0-f177.google.com with SMTP id va2so6452854obc.8
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 14:36: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:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=XJQtcrwsQNag668LhrmAhDrph1bQt8sa0T5A+45bwEk=;
	b=SXPKza5ouhERbEZ1FecWyU0FsPaw7f+nAJk9akODYJ4/nZ2y6lJWNyb7jemz+8R7e5
	/XfrYaJfyxIjtaua9N6shAyqnT1dRkqqz8kGwvJTj8ExLOI2GHdNUx4+M2aNoDOQyaZr
	P49KhD0d+r0q2Dv9gnKDezVdTtf0gLgZ8wPgou7JREvEPpCoO6CqJjXbXE5Ctia4cbs3
	GeIIxpmEmebVD5wVvUCZfHT5AegNRs/uehoo2x6oGap/qOEENKR75y8xfLWDUhkkH6o2
	39zOoEG4tVXCAE9sh1oFdxG8LLSFbG8Rzvc1DuwBLeZymm6Wz/gI8arSyuOU9aY/1RMY
	xsbw==
X-Gm-Message-State: ALoCoQmrUOTNC850cbzWKDTqUBOAiCQcgQ/lm1zWSK35vZAsobLQvxa2bvXGEzQA+zgOC4nfdZUk
MIME-Version: 1.0
X-Received: by 10.202.227.212 with SMTP id a203mr591157oih.126.1418942163492; 
	Thu, 18 Dec 2014 14:36:03 -0800 (PST)
Received: by 10.60.158.169 with HTTP; Thu, 18 Dec 2014 14:36:03 -0800 (PST)
X-Originating-IP: [87.81.134.115]
Date: Thu, 18 Dec 2014 22:36:03 +0000
Message-ID: <CAN4Onoho_BKS48ECqXf=wF=MMLCah80yGZyEmm1O7G6fDEQtHA@mail.gmail.com>
From: Peter Kay <syllopsium@syllopsium.co.uk>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Parallel make 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: multipart/mixed; boundary="===============2565917648014230066=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2565917648014230066==
Content-Type: multipart/alternative; boundary=001a114088c69cba10050a85374b

--001a114088c69cba10050a85374b
Content-Type: text/plain; charset=UTF-8

Is parallel make supported for xen? If I compile 4.5 rc4 (although the
error exists with many other prior releases too) with make -j4 world it
fails part way through with an error 2. This does not occur with a straight
'make world'

PK

--001a114088c69cba10050a85374b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Is parallel make supported for xen? If I compile 4.5 =
rc4 (although the error exists with many other prior releases too) with mak=
e -j4 world it fails part way through with an error 2. This does not occur =
with a straight &#39;make world&#39;<br><br></div>PK<br></div>

--001a114088c69cba10050a85374b--


--===============2565917648014230066==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2565917648014230066==--


From xen-devel-bounces@lists.xen.org Thu Dec 18 22:36:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 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 1Y1jfz-0002Vz-Vv; Thu, 18 Dec 2014 22:36:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <syllopsium@syllopsium.co.uk>) id 1Y1jfy-0002Vu-KA
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 22:36:06 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	3E/A6-26740-5D653945; Thu, 18 Dec 2014 22:36:05 +0000
X-Env-Sender: syllopsium@syllopsium.co.uk
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418942163!14491950!1
X-Originating-IP: [209.85.214.177]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19799 invoked from network); 18 Dec 2014 22:36:05 -0000
Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com)
	(209.85.214.177)
	by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 22:36:05 -0000
Received: by mail-ob0-f177.google.com with SMTP id va2so6452854obc.8
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 14:36: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:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=XJQtcrwsQNag668LhrmAhDrph1bQt8sa0T5A+45bwEk=;
	b=SXPKza5ouhERbEZ1FecWyU0FsPaw7f+nAJk9akODYJ4/nZ2y6lJWNyb7jemz+8R7e5
	/XfrYaJfyxIjtaua9N6shAyqnT1dRkqqz8kGwvJTj8ExLOI2GHdNUx4+M2aNoDOQyaZr
	P49KhD0d+r0q2Dv9gnKDezVdTtf0gLgZ8wPgou7JREvEPpCoO6CqJjXbXE5Ctia4cbs3
	GeIIxpmEmebVD5wVvUCZfHT5AegNRs/uehoo2x6oGap/qOEENKR75y8xfLWDUhkkH6o2
	39zOoEG4tVXCAE9sh1oFdxG8LLSFbG8Rzvc1DuwBLeZymm6Wz/gI8arSyuOU9aY/1RMY
	xsbw==
X-Gm-Message-State: ALoCoQmrUOTNC850cbzWKDTqUBOAiCQcgQ/lm1zWSK35vZAsobLQvxa2bvXGEzQA+zgOC4nfdZUk
MIME-Version: 1.0
X-Received: by 10.202.227.212 with SMTP id a203mr591157oih.126.1418942163492; 
	Thu, 18 Dec 2014 14:36:03 -0800 (PST)
Received: by 10.60.158.169 with HTTP; Thu, 18 Dec 2014 14:36:03 -0800 (PST)
X-Originating-IP: [87.81.134.115]
Date: Thu, 18 Dec 2014 22:36:03 +0000
Message-ID: <CAN4Onoho_BKS48ECqXf=wF=MMLCah80yGZyEmm1O7G6fDEQtHA@mail.gmail.com>
From: Peter Kay <syllopsium@syllopsium.co.uk>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Parallel make 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: multipart/mixed; boundary="===============2565917648014230066=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2565917648014230066==
Content-Type: multipart/alternative; boundary=001a114088c69cba10050a85374b

--001a114088c69cba10050a85374b
Content-Type: text/plain; charset=UTF-8

Is parallel make supported for xen? If I compile 4.5 rc4 (although the
error exists with many other prior releases too) with make -j4 world it
fails part way through with an error 2. This does not occur with a straight
'make world'

PK

--001a114088c69cba10050a85374b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Is parallel make supported for xen? If I compile 4.5 =
rc4 (although the error exists with many other prior releases too) with mak=
e -j4 world it fails part way through with an error 2. This does not occur =
with a straight &#39;make world&#39;<br><br></div>PK<br></div>

--001a114088c69cba10050a85374b--


--===============2565917648014230066==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2565917648014230066==--


From xen-devel-bounces@lists.xen.org Thu Dec 18 22:56:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 22:56:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1jzR-0003TJ-U4; Thu, 18 Dec 2014 22:56:13 +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 1Y1jzP-0003TE-MV
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 22:56:11 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B9/81-27584-B8B53945; Thu, 18 Dec 2014 22:56:11 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418943369!14196166!1
X-Originating-IP: [209.85.192.46]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28217 invoked from network); 18 Dec 2014 22:56:09 -0000
Received: from mail-qg0-f46.google.com (HELO mail-qg0-f46.google.com)
	(209.85.192.46)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 22:56:09 -0000
Received: by mail-qg0-f46.google.com with SMTP id q107so1607131qgd.19
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 14:56: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=+YNdiyFBWpemTjRfFb0cFZMqjW89//3P40HO1cq5DCU=;
	b=U9OpZ5gAUk7Lvsj8qaiF8gGVZj4KNrCCs6kfXiw15CbNnHDlVRIDLr0tuOzET4M8AE
	+1UWAsVFHOWP+hcb/5cTceRMv174ftxZ9Pjj/DihRICAuwiXnPS+TuodPDe1QPC6zfco
	rMiZSiIijAL7gHKNdB6KHVEdB9uBexqQdsZUDQynMQV4a+Qb4atFN6ANVc9ZVguJfk2n
	cNbWHxK8UXi195GpZ+G7Cv0YHy2bNFT0FfYQoAu98/mDM+TS6Y2Y8JhKydxrpAakiHnA
	X8qRiC4rr9EPe4sIUUK5fj3IyM/5nl8PAmBiTJH2wEDfmoqyNLzJ8MJtKVrKR97lFank
	BS/A==
X-Gm-Message-State: ALoCoQl3HQr3OGWS4CK1Fj1Sdfl37n6MmYOEmiHblHkmi8S4DX1XjUiQhz/AY9VPhxJp0PE/XGPl
MIME-Version: 1.0
X-Received: by 10.140.108.9 with SMTP id i9mr7942597qgf.73.1418943368717; Thu,
	18 Dec 2014 14:56:08 -0800 (PST)
Received: by 10.229.176.69 with HTTP; Thu, 18 Dec 2014 14:56:08 -0800 (PST)
In-Reply-To: <547DD2B6.1020202@linaro.org>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
	<547DD2B6.1020202@linaro.org>
Date: Thu, 18 Dec 2014 17:56:08 -0500
Message-ID: <CAErYnshnp+ZqNTTs0hWDa-st5ZgzQVVGaWwEaNWKexJ8RRR3BA@mail.gmail.com>
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>, yang.z.zhang@intel.com,
	Tiejun Chen <tiejun.chen@intel.com>,
	Tamas K Lengyel <tklengyel@sec.in.tum.de>
Subject: Re: [Xen-devel] [v8][PATCH 13/17] xen/mem_access: don't allow
 accessing reserved device memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3532232944225551516=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3532232944225551516==
Content-Type: multipart/alternative; boundary=001a113a519873024f050a857fac

--001a113a519873024f050a857fac
Content-Type: text/plain; charset=ISO-8859-1

I agree with Julien below, this should probably be put into the p2m layer.
The ARM definition of the function could then simply be an inline
definition that just returns 0.

Tamas

On Tue, Dec 2, 2014 at 9:54 AM, Julien Grall <julien.grall@linaro.org>
wrote:
>
> Hi,
>
> CC Tamas as he did some work on memaccess for ARM.
>
> On 01/12/14 09:24, Tiejun Chen wrote:
> > We can't expost those reserved device memory in case of mem_access
>
> s/expost/expose/
>
> > since any access may corrupt device usage.
> >
> > Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> > ---
> >  xen/common/mem_access.c | 41 +++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 41 insertions(+)
> >
> > diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
> > index 6c2724b..72a807a 100644
> > --- a/xen/common/mem_access.c
> > +++ b/xen/common/mem_access.c
> > @@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)
> >      }
> >  }
> >
> > +/* We can't expose reserved device memory. */
> > +static int mem_access_check_rdm(struct domain *d, uint64_aligned_t
> start,
> > +                                uint32_t nr)
> > +{
> > +    uint32_t i;
> > +    struct p2m_get_reserved_device_memory pgrdm;
>
> p2m_get_reserved_device_memory is only defined on x86. This will fail to
> compile on ARM when memaccess is enabled.
>
> > +    int rc = 0;
> > +
> > +    if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )
> > +    {
> > +        for ( i = 0; i < nr; i++ )
> > +        {
> > +            pgrdm.gfn = start + i;
> > +            pgrdm.domain = d;
> > +            rc =
> iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> > +                                                  &pgrdm);
>
> Same here.
>
> Overall, I'm not sure if it's worth to introduce this code in the common
> part has it doesn't seem useful for ARM.
>
> In any case, you have to at least stub those bits for ARM.
>
> Regards,
>
> --
> Julien Grall
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--001a113a519873024f050a857fac
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I agree with Julien below, this should probably be pu=
t into the p2m layer. The ARM definition of the function could then simply =
be an inline definition that just returns 0.<br><br>Tamas<br></div><div><di=
v><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tu=
e, Dec 2, 2014 at 9:54 AM, Julien Grall <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:julien.grall@linaro.org" target=3D"_blank">julien.grall@linaro.org</a>=
&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
CC Tamas as he did some work on memaccess for ARM.<br>
<span class=3D""><br>
On 01/12/14 09:24, Tiejun Chen wrote:<br>
&gt; We can&#39;t expost those reserved device memory in case of mem_access=
<br>
<br>
</span>s/expost/expose/<br>
<span class=3D""><br>
&gt; since any access may corrupt device usage.<br>
&gt;<br>
&gt; Signed-off-by: Tiejun Chen &lt;<a href=3D"mailto:tiejun.chen@intel.com=
">tiejun.chen@intel.com</a>&gt;<br>
&gt; ---<br>
&gt;=A0 xen/common/mem_access.c | 41 ++++++++++++++++++++++++++++++++++++++=
+++<br>
&gt;=A0 1 file changed, 41 insertions(+)<br>
&gt;<br>
&gt; diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c<br>
&gt; index 6c2724b..72a807a 100644<br>
&gt; --- a/xen/common/mem_access.c<br>
&gt; +++ b/xen/common/mem_access.c<br>
&gt; @@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)<br>
&gt;=A0 =A0 =A0 }<br>
&gt;=A0 }<br>
&gt;<br>
&gt; +/* We can&#39;t expose reserved device memory. */<br>
&gt; +static int mem_access_check_rdm(struct domain *d, uint64_aligned_t st=
art,<br>
&gt; +=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint3=
2_t nr)<br>
&gt; +{<br>
&gt; +=A0 =A0 uint32_t i;<br>
&gt; +=A0 =A0 struct p2m_get_reserved_device_memory pgrdm;<br>
<br>
</span>p2m_get_reserved_device_memory is only defined on x86. This will fai=
l to<br>
compile on ARM when memaccess is enabled.<br>
<span class=3D""><br>
&gt; +=A0 =A0 int rc =3D 0;<br>
&gt; +<br>
&gt; +=A0 =A0 if ( !is_hardware_domain(d) &amp;&amp; iommu_use_hap_pt(d) )<=
br>
&gt; +=A0 =A0 {<br>
&gt; +=A0 =A0 =A0 =A0 for ( i =3D 0; i &lt; nr; i++ )<br>
&gt; +=A0 =A0 =A0 =A0 {<br>
&gt; +=A0 =A0 =A0 =A0 =A0 =A0 pgrdm.gfn =3D start + i;<br>
&gt; +=A0 =A0 =A0 =A0 =A0 =A0 pgrdm.domain =3D d;<br>
&gt; +=A0 =A0 =A0 =A0 =A0 =A0 rc =3D iommu_get_reserved_device_memory(p2m_c=
heck_reserved_device_memory,<br>
&gt; +=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &amp;pgrdm);<br>
<br>
</span>Same here.<br>
<br>
Overall, I&#39;m not sure if it&#39;s worth to introduce this code in the c=
ommon<br>
part has it doesn&#39;t seem useful for ARM.<br>
<br>
In any case, you have to at least stub those bits for ARM.<br>
<br>
Regards,<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Julien Grall<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
</div></div></blockquote></div></div></div></div></div></div></div>

--001a113a519873024f050a857fac--


--===============3532232944225551516==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3532232944225551516==--


From xen-devel-bounces@lists.xen.org Thu Dec 18 22:56:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Dec 2014 22:56:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1jzR-0003TJ-U4; Thu, 18 Dec 2014 22:56:13 +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 1Y1jzP-0003TE-MV
	for xen-devel@lists.xen.org; Thu, 18 Dec 2014 22:56:11 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B9/81-27584-B8B53945; Thu, 18 Dec 2014 22:56:11 +0000
X-Env-Sender: tamas.lengyel@zentific.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1418943369!14196166!1
X-Originating-IP: [209.85.192.46]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28217 invoked from network); 18 Dec 2014 22:56:09 -0000
Received: from mail-qg0-f46.google.com (HELO mail-qg0-f46.google.com)
	(209.85.192.46)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Dec 2014 22:56:09 -0000
Received: by mail-qg0-f46.google.com with SMTP id q107so1607131qgd.19
	for <xen-devel@lists.xen.org>; Thu, 18 Dec 2014 14:56: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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=+YNdiyFBWpemTjRfFb0cFZMqjW89//3P40HO1cq5DCU=;
	b=U9OpZ5gAUk7Lvsj8qaiF8gGVZj4KNrCCs6kfXiw15CbNnHDlVRIDLr0tuOzET4M8AE
	+1UWAsVFHOWP+hcb/5cTceRMv174ftxZ9Pjj/DihRICAuwiXnPS+TuodPDe1QPC6zfco
	rMiZSiIijAL7gHKNdB6KHVEdB9uBexqQdsZUDQynMQV4a+Qb4atFN6ANVc9ZVguJfk2n
	cNbWHxK8UXi195GpZ+G7Cv0YHy2bNFT0FfYQoAu98/mDM+TS6Y2Y8JhKydxrpAakiHnA
	X8qRiC4rr9EPe4sIUUK5fj3IyM/5nl8PAmBiTJH2wEDfmoqyNLzJ8MJtKVrKR97lFank
	BS/A==
X-Gm-Message-State: ALoCoQl3HQr3OGWS4CK1Fj1Sdfl37n6MmYOEmiHblHkmi8S4DX1XjUiQhz/AY9VPhxJp0PE/XGPl
MIME-Version: 1.0
X-Received: by 10.140.108.9 with SMTP id i9mr7942597qgf.73.1418943368717; Thu,
	18 Dec 2014 14:56:08 -0800 (PST)
Received: by 10.229.176.69 with HTTP; Thu, 18 Dec 2014 14:56:08 -0800 (PST)
In-Reply-To: <547DD2B6.1020202@linaro.org>
References: <1417425875-9634-1-git-send-email-tiejun.chen@intel.com>
	<1417425875-9634-14-git-send-email-tiejun.chen@intel.com>
	<547DD2B6.1020202@linaro.org>
Date: Thu, 18 Dec 2014 17:56:08 -0500
Message-ID: <CAErYnshnp+ZqNTTs0hWDa-st5ZgzQVVGaWwEaNWKexJ8RRR3BA@mail.gmail.com>
From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, wei.liu2@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>, yang.z.zhang@intel.com,
	Tiejun Chen <tiejun.chen@intel.com>,
	Tamas K Lengyel <tklengyel@sec.in.tum.de>
Subject: Re: [Xen-devel] [v8][PATCH 13/17] xen/mem_access: don't allow
 accessing reserved device memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3532232944225551516=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3532232944225551516==
Content-Type: multipart/alternative; boundary=001a113a519873024f050a857fac

--001a113a519873024f050a857fac
Content-Type: text/plain; charset=ISO-8859-1

I agree with Julien below, this should probably be put into the p2m layer.
The ARM definition of the function could then simply be an inline
definition that just returns 0.

Tamas

On Tue, Dec 2, 2014 at 9:54 AM, Julien Grall <julien.grall@linaro.org>
wrote:
>
> Hi,
>
> CC Tamas as he did some work on memaccess for ARM.
>
> On 01/12/14 09:24, Tiejun Chen wrote:
> > We can't expost those reserved device memory in case of mem_access
>
> s/expost/expose/
>
> > since any access may corrupt device usage.
> >
> > Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> > ---
> >  xen/common/mem_access.c | 41 +++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 41 insertions(+)
> >
> > diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
> > index 6c2724b..72a807a 100644
> > --- a/xen/common/mem_access.c
> > +++ b/xen/common/mem_access.c
> > @@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)
> >      }
> >  }
> >
> > +/* We can't expose reserved device memory. */
> > +static int mem_access_check_rdm(struct domain *d, uint64_aligned_t
> start,
> > +                                uint32_t nr)
> > +{
> > +    uint32_t i;
> > +    struct p2m_get_reserved_device_memory pgrdm;
>
> p2m_get_reserved_device_memory is only defined on x86. This will fail to
> compile on ARM when memaccess is enabled.
>
> > +    int rc = 0;
> > +
> > +    if ( !is_hardware_domain(d) && iommu_use_hap_pt(d) )
> > +    {
> > +        for ( i = 0; i < nr; i++ )
> > +        {
> > +            pgrdm.gfn = start + i;
> > +            pgrdm.domain = d;
> > +            rc =
> iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> > +                                                  &pgrdm);
>
> Same here.
>
> Overall, I'm not sure if it's worth to introduce this code in the common
> part has it doesn't seem useful for ARM.
>
> In any case, you have to at least stub those bits for ARM.
>
> Regards,
>
> --
> Julien Grall
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--001a113a519873024f050a857fac
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I agree with Julien below, this should probably be pu=
t into the p2m layer. The ARM definition of the function could then simply =
be an inline definition that just returns 0.<br><br>Tamas<br></div><div><di=
v><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tu=
e, Dec 2, 2014 at 9:54 AM, Julien Grall <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:julien.grall@linaro.org" target=3D"_blank">julien.grall@linaro.org</a>=
&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
CC Tamas as he did some work on memaccess for ARM.<br>
<span class=3D""><br>
On 01/12/14 09:24, Tiejun Chen wrote:<br>
&gt; We can&#39;t expost those reserved device memory in case of mem_access=
<br>
<br>
</span>s/expost/expose/<br>
<span class=3D""><br>
&gt; since any access may corrupt device usage.<br>
&gt;<br>
&gt; Signed-off-by: Tiejun Chen &lt;<a href=3D"mailto:tiejun.chen@intel.com=
">tiejun.chen@intel.com</a>&gt;<br>
&gt; ---<br>
&gt;=A0 xen/common/mem_access.c | 41 ++++++++++++++++++++++++++++++++++++++=
+++<br>
&gt;=A0 1 file changed, 41 insertions(+)<br>
&gt;<br>
&gt; diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c<br>
&gt; index 6c2724b..72a807a 100644<br>
&gt; --- a/xen/common/mem_access.c<br>
&gt; +++ b/xen/common/mem_access.c<br>
&gt; @@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)<br>
&gt;=A0 =A0 =A0 }<br>
&gt;=A0 }<br>
&gt;<br>
&gt; +/* We can&#39;t expose reserved device memory. */<br>
&gt; +static int mem_access_check_rdm(struct domain *d, uint64_aligned_t st=
art,<br>
&gt; +=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint3=
2_t nr)<br>
&gt; +{<br>
&gt; +=A0 =A0 uint32_t i;<br>
&gt; +=A0 =A0 struct p2m_get_reserved_device_memory pgrdm;<br>
<br>
</span>p2m_get_reserved_device_memory is only defined on x86. This will fai=
l to<br>
compile on ARM when memaccess is enabled.<br>
<span class=3D""><br>
&gt; +=A0 =A0 int rc =3D 0;<br>
&gt; +<br>
&gt; +=A0 =A0 if ( !is_hardware_domain(d) &amp;&amp; iommu_use_hap_pt(d) )<=
br>
&gt; +=A0 =A0 {<br>
&gt; +=A0 =A0 =A0 =A0 for ( i =3D 0; i &lt; nr; i++ )<br>
&gt; +=A0 =A0 =A0 =A0 {<br>
&gt; +=A0 =A0 =A0 =A0 =A0 =A0 pgrdm.gfn =3D start + i;<br>
&gt; +=A0 =A0 =A0 =A0 =A0 =A0 pgrdm.domain =3D d;<br>
&gt; +=A0 =A0 =A0 =A0 =A0 =A0 rc =3D iommu_get_reserved_device_memory(p2m_c=
heck_reserved_device_memory,<br>
&gt; +=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &amp;pgrdm);<br>
<br>
</span>Same here.<br>
<br>
Overall, I&#39;m not sure if it&#39;s worth to introduce this code in the c=
ommon<br>
part has it doesn&#39;t seem useful for ARM.<br>
<br>
In any case, you have to at least stub those bits for ARM.<br>
<br>
Regards,<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Julien Grall<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
</div></div></blockquote></div></div></div></div></div></div></div>

--001a113a519873024f050a857fac--


--===============3532232944225551516==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3532232944225551516==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 01:04:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 01:04:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1lyt-0003LF-41; Fri, 19 Dec 2014 01:03:47 +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 1Y1lyq-0003L8-Pn
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 01:03:44 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	39/C4-05632-F6973945; Fri, 19 Dec 2014 01:03:43 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418951022!14511452!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 19790 invoked from network); 19 Dec 2014 01:03:43 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-31.messagelabs.com with SMTP;
	19 Dec 2014 01:03:43 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 18 Dec 2014 17:01:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,604,1413270000"; d="scan'208";a="656781583"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.118])
	([10.238.128.118])
	by orsmga002.jf.intel.com with ESMTP; 18 Dec 2014 17:03:38 -0800
Message-ID: <54937969.6090805@intel.com>
Date: Fri, 19 Dec 2014 09:03:37 +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.3.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>, "Tian, Kevin" <kevin.tian@intel.com>
References: <548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
	<20141210111213.GB64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261167AC@SHSMSX101.ccr.corp.intel.com>
	<20141211130946.GD53811@deinos.phlegethon.org>
	<20141218161325.GA75015@deinos.phlegethon.org>
In-Reply-To: <20141218161325.GA75015@deinos.phlegethon.org>
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>,
	"ian.jackson@eu.citrix.com" <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] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/19 0:13, Tim Deegan wrote:
> Hi Kevin,
>
> At 14:09 +0100 on 11 Dec (1418303386), Tim Deegan wrote:
>> At 02:03 +0000 on 11 Dec (1418259797), Tian, Kevin wrote:
>>>> From: Tim Deegan [mailto:tim@xen.org]
>>>> Now since the code's not going to be in 4.5 anyway, it should be
>>>> possible to _develop_ it in this manner, possibly in a private branch,
>>>> even if the early stages aren't getting applied immediately.  We
>>>> should be able to set up an rmrr branch on the public servers if that
>>>> helps.  But again, that relies on having a design worked out in
>>>> advance that both developers and maintainers are (within reason)
>>>> committed to.
>>>
>>> that's a good suggestion. We'll send out a design review today, and then
>>> based on discussion we can see whether making sense to do such
>>> incremental way.
>>
>> Sounds good!
>
> I haven't seen this design doc yet -- if I missed it can someone point
> me to it?
>

No.

Its still reviewed/discussed internally but it will come soon.

Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 01:04:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 01:04:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1lyt-0003LF-41; Fri, 19 Dec 2014 01:03:47 +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 1Y1lyq-0003L8-Pn
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 01:03:44 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	39/C4-05632-F6973945; Fri, 19 Dec 2014 01:03:43 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1418951022!14511452!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 19790 invoked from network); 19 Dec 2014 01:03:43 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-31.messagelabs.com with SMTP;
	19 Dec 2014 01:03:43 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 18 Dec 2014 17:01:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,604,1413270000"; d="scan'208";a="656781583"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.128.118])
	([10.238.128.118])
	by orsmga002.jf.intel.com with ESMTP; 18 Dec 2014 17:03:38 -0800
Message-ID: <54937969.6090805@intel.com>
Date: Fri, 19 Dec 2014 09:03:37 +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.3.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>, "Tian, Kevin" <kevin.tian@intel.com>
References: <548090BA020000780004CCE6@mail.emea.novell.com>
	<54854F2D.6060204@intel.com>
	<54857491020000780004D9D6@mail.emea.novell.com>
	<5486A8FB.4080402@intel.com>
	<5486BE99020000780004DF8A@mail.emea.novell.com>
	<20141209101111.GA75319@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D126114F15@SHSMSX101.ccr.corp.intel.com>
	<20141210111213.GB64596@deinos.phlegethon.org>
	<AADFC41AFE54684AB9EE6CBC0274A5D1261167AC@SHSMSX101.ccr.corp.intel.com>
	<20141211130946.GD53811@deinos.phlegethon.org>
	<20141218161325.GA75015@deinos.phlegethon.org>
In-Reply-To: <20141218161325.GA75015@deinos.phlegethon.org>
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>,
	"ian.jackson@eu.citrix.com" <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] [v8][PATCH 04/17] update the existing hypercall to
 support XEN_DOMCTL_set_rdm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/19 0:13, Tim Deegan wrote:
> Hi Kevin,
>
> At 14:09 +0100 on 11 Dec (1418303386), Tim Deegan wrote:
>> At 02:03 +0000 on 11 Dec (1418259797), Tian, Kevin wrote:
>>>> From: Tim Deegan [mailto:tim@xen.org]
>>>> Now since the code's not going to be in 4.5 anyway, it should be
>>>> possible to _develop_ it in this manner, possibly in a private branch,
>>>> even if the early stages aren't getting applied immediately.  We
>>>> should be able to set up an rmrr branch on the public servers if that
>>>> helps.  But again, that relies on having a design worked out in
>>>> advance that both developers and maintainers are (within reason)
>>>> committed to.
>>>
>>> that's a good suggestion. We'll send out a design review today, and then
>>> based on discussion we can see whether making sense to do such
>>> incremental way.
>>
>> Sounds good!
>
> I haven't seen this design doc yet -- if I missed it can someone point
> me to it?
>

No.

Its still reviewed/discussed internally but it will come soon.

Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 01:23:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 01:23:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1mHl-0004Jg-11; Fri, 19 Dec 2014 01:23:17 +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 1Y1mHj-0004Jb-UN
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 01:23:16 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	AD/12-02707-30E73945; Fri, 19 Dec 2014 01:23:15 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418952192!14221369!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 17344 invoked from network); 19 Dec 2014 01:23:13 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-6.tower-206.messagelabs.com with SMTP;
	19 Dec 2014 01:23:13 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 18 Dec 2014 17:21:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,604,1413270000"; d="scan'208";a="626318172"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga001.jf.intel.com with ESMTP; 18 Dec 2014 17:23:09 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: JBeulich@suse.com, konrad.wilk@oracle.com, tim@xen.org,
	kevin.tian@intel.com, yang.z.zhang@intel.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	ian.jackson@eu.citrix.com, wei.liu2@citrix.com
Date: Fri, 19 Dec 2014 09:21:06 +0800
Message-Id: <1418952066-21064-1-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] RMRR Fix Design for Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

                    RMRR Fix Design for Xen

This design is a goal to fix RMRR for Xen. It includes four sectors as
follows:

    * Background
    * What is RMRR
    * Current RMRR Issues
    * Design Overview

We hope this can help us to understand current problem then figure out a
clean and better solution everyone can agree now to go forward.

Background
==========

We first identified this RMRR defect when trying to pass-through IGD device,
which can be simply fixed by adding an identity mapping in case of shared
EPT table. However along with the community discussion, it boiled down to
a more general RMRR problem, i.e. the identity mapping is brute-added
in hypervisor, w/o considering whether conflicting with an existing guest
PFN ranges. As a general solution we need invent a new mechanism so
reserved ranges allocated by hypervisor can be exported to the user space
toolstack and hvmloader, so conflict can be detected when constructing
guest PFN layout, with best-effort avoidance policies to further help.

What is RMRR
============

RMRR is a acronym for Reserved Memory Region Reporting.

BIOS may report each such reserved memory region through the RMRR structures,
along with the devices that requires access to the specified reserved memory
region. Reserved memory ranges that are either not DMA targets, or memory
ranges that may be target of BIOS initiated DMA only during pre-boot phase
(such as from a boot disk drive) must not be included in the reserved memory
region reporting. The base address of each RMRR region must be 4KB aligned and
the size must be an integer multiple of 4KB. BIOS must report the RMRR reported
memory addresses as reserved in the system memory map returned through methods
suchas INT15, EFI GetMemoryMap etc. The reserved memory region reporting
structures are optional. If there are no RMRR structures, the system software
concludes that the platform does not have any reserved memory ranges that are 
DMA targets.

The RMRR regions are expected to be used for legacy usages (such as USB, UMA
Graphics, etc.) requiring reserved memory. Platform designers shouldavoid or
limit use of reserved memory regions since these require system software to
create holes in the DMA virtual address range available to system software and
its drivers.

The following is grabbed from my BDW:

(XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ab80a000 end_address ab81dfff
(XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ad000000 end_address af7fffff

Here USB occupies 0xab80a000:0xab81dfff, IGD owns 0xad000000:0xaf7fffff.

Note there are zero or more Reserved Memory Region Reporting (RMRR) in one given
platform. And multiple devices may share one RMRR range. Additionally RMRR can
go anyplace.

Current RMRR Issues
===================

#1 RMRR may conflict RAM, mmio or other ranges in Guest physical level.

#2 Xen doesn't create RMRR mapping in case of shared ept, then the assigned
   device can't work well.

#3 Xen doesn't consider that case multiple devices may share one RMRR entry.
   This also is a damage between different VMs when we assign such devices to
   different VMs.

#4 Something like USB, is still restricted to current RMRR implementation. We
   should work out this case.

Design Overview
===============

First of all we need to make sure all resources don't overlap RMRR. And then
in case of shared ept, we can set these identity entries. And Certainly we will
group all devices associated to one same RMRR entry, then make sure all group
devices should be assigned to same VM.

1. Setup RMRR identity mapping

current status:
    * identity mapping only setup in non-shared ept case

proposal:

In non-shared ept case, IOMMU stuff always set those entries and RMRR is already
marked reserved in host so its fine enough. But in shared ept case, we need to
check any conflit, so we should follow up

  - gfn space unoccupied
        -> insert mapping: success.
            gfn:_mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct, p2m_access_rw
  - gfn space already occupied by 1:1 RMRR mapping
        -> do nothing; success.
  - gfn space already occupied by other mapping
        -> fail.

expectation:
    * only devices w/ non-conflicting RMRR can be assigned
    * fortunately this achieves the very initial intention to support IGD
      pass-through on BDW
    * provide last level protection in hypervisor to ensure a secure assignment

2. Check to reserve RMRR in guest physical level

current status:
    * Xen doesn't reserve RMRR in guest physical level

proposal:
    * Get RMRR info as necessary
    * Then check all potential points to reserve or skip RMRR

expectation:
    * Make sure all guest resources don't overlap RMRR range.

2.1 Expose RMRR to user space

current status:
    * Xen always record RMRR info into one list, acpi_rmrr_units, while parsing
      acpi. So we can retrieve these info by lookup that list.

proposal:
    * RMRR would be exposed by a new hypercall, which Jan already finished in
      current version but just expose all RMRR info unconditionally.
    * Furthermore we can expose RMRR on demand to diminish shrinking guest
      RAM/MMIO space.
    * So we will introduce a new parameter, 'rdm_forcecheck' and to collaborate
      with SBDFs to control which RMRR should be exposed:

        - We can set this parameter in .cfg file like,

            rdm_forcecheck = 1 => Of course this should be 0 by default.

        '1' means we should force check to reserve all ranges unconditionally.
        and 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.

        If 0, we just check those assigned pci devices. As you know we already
        have such an existing hypercall to assign PCI devices, looks we can work
        directly under this hypercall to get that necessary SBDF to sort which
        RMRR should be handled. But obviously, we need to get these info before
        we populate guest memory to make sure these RMRR ranges should be
        excluded from guest memory. But unfortunately the memory populating
        takes place before a device assignment, so we can't live on that
        directly.

        But as we discussed it just benefit that assigned case to reorder that
        order, but not good to hotplug case. So we have to introduce a new
        DOMCTL to pass that global parameter with SBDF at the same time.

        For example, if we own these two RMRR entries,

        [00:14.0]    RMRR region: base_addr ab80a000 end_address ab81dfff
        [00:02.0]    RMRR region: base_addr ad000000 end_address af7fffff

        If 'rdm_forcecheck = 1', any caller to that hypercall may get these two
        entries. But if 'rdm_forcecheck = 0', and in .cfg file,

        #1 'pci=[00:14.0, 00:02.0]' -> The caller still get these two entries.
        #2 'pci=[00:02.0]' -> The caller just get one entry, 0xad000000:0xaf7fffff
        #2 'pci=[00:14.0]' -> The caller just get one entry, 0xab80a000:0xab81dfff
        #4 'pci=[others]' or no any pci configuration -> The caller get nothing.

        And ultimately, if we expose any RMRR entry at gfn,

        in non-shared ept case, 

        p2m table:  valid non-identity mapping, gfn:mfn != 1:1
        VT-D table: no such a mapping until set identity mapping,
                    gfn:_mfn(gfn) == 1:1 when we have a associated device
                    assignment.
        
        in shared ept case,

        p2m table\VT-D table:  always INVALID until set identity mapping,
                               gfn:_mfn(gfn) == 1:1 when we have a associated
                               device assignment.

        But if we don't expose any RMRR entry,

        in non-shared ept case, 

        p2m table:  valid non-identity mapping, gfn:mfn != 1:1
        VT-D table: no such a mapping until set identity mapping,
                    gfn:_mfn(gfn) == 1:1 when we have a associated device
                    assignment.

        in shared ept case,

        p2m table\VT-D table:  If guest RAM already cover gfn, we have sunc a
                               valid non-identity mapping, gfn:mfn != 1:1, but
                               we can't set any identity mapping again then
                               that associated device can't be assigned
                               successfully. If not, we'll set identity mapping,
                               gfn:_mfn(gfn) == 1:1, to work well.

 
expectation:
    * Provice a way to get necessary RMRR info.

Note here that new DOMCTL is already finished but need to fix some code style
issues.

2.2 Detect and avoid RMRR conflictions with guest RAM/MMIO

current status:
    * Currently Xen doesn't detect anything to avoid any conflict.

proposal:
    * We need to cover all points to check any conflict. Below lists places
      where reserved region conflictions should be detected:

        1>. libxc:setup_guest():modules_init()

        There are some modules, like acpi_module and smbios_module. They may
        occupy some ranges so we need to check if they're conflicting with
        all ranges from that new hypercall above.

        2>. libxc:setup_guest():xc_domain_populate_physmap()

        There are two ways to exclude RMRR ranges here:
            
            #1 Before we populate guest RAM without any RMRR range from that
               new hypercall to skip RMRR ranges when populating guest RAM.
            #2 In Xen we can fliter RMRR range while calling
               XENMEM_populate_physmap, its no change to libxc, but skip
               setting p2m entry for RMRR ranges in Xen hypervisor

        But to compare #1, #2 is not better since Xen still allocate those
        range, and we have to sync somewhere else in Xen. And #1 is cleaner
        because #2 actually shrinks the available memory size to the guest.

        3>. hvmloader:pci_setup()

        Here we should populate guest MMIO excluding all ranges from that new
        hypercall to detect RMRR conflictions for allocating PCI MMIO BAR.

        4>. hvmloader:mem_hole_alloc()

        Here we should populate mem holw excluding all ranges from that new
        hypercall to detect RMRR conflictions for dynamic allocation in
        hvmloader, e.g. as used for IGD opregion

        5>. hvmloader:build_e820_table():

        Finally we need let VM know that RMRR regions are reserved through e820
        table

    Its a little bit tricky to handle this inside hvmloader since as you know,
    struct hvm_info_table is only a approach between libxc and hvmloader. But
    however, making up all above places will bring some duplicated logic.
    Especially between libxc and hvmloader, which skip same regions in guest
    physical layer(one in populating guest RAM, the other in constructing e820)
    But current design has some limitation to pass information between libxc and
    hvmloader,

struct hvm_info_table {
    ...
    /*
     *  0x0 to page_to_phys(low_mem_pgend)-1:
     *    RAM below 4GB (except for VGA hole 0xA0000-0xBFFFF)
     */
    uint32_t    low_mem_pgend;
    ...
    /*
     *  0x100000000 to page_to_phys(high_mem_pgend)-1:
     *    RAM above 4GB
     */
    uint32_t    high_mem_pgend;
    ...
}

    nothing valuable is passed to hvmloader so we have to figure out a way to
    handle those points in hvmloader. Currently,

            #1 Reconstruct hvm_info_table{}

            We can store all necessary RMRR info into hvm_info_table as well,
            then we can pick them conveniently but oftentimes these RMRR
            entries are scattered and the number is also undertimined, so its
            a little bit ugly to do.

            #2 Xenstore

            We may store all necessary RMRR info as Xenstore then pick them in
            hvmloader.

            #3 A hypercall

            We may have to call our new hypercall again to pick them, but
            obviously this may introduce some duplicated codes.

            #4 XENMEM_{set_,}memory_map pair of hypercalls
            
            As Jan commented it "could be used(and is readily available to be
            extended that way, since for HVM domains XENMEM_set_memory_map
            returns -EPERM at present). The only potentially problematic aspect
            I can see with using it might be its limiting of the entry count to
            E820MAX." So a preparation patch is required before RMRR, and
            hvmloader still needs to query RMRR information.

expectation:
    * Cover all points to make sure guest doesn't occupt any RMRR range.

3. Group multiple devices sharing same RMRR entry

current status:
    * Xen doesn't distinguish if multiple devices share same RMRR entry. This
      may lead a leak to corruption, e.g. Device A and device B share same entry
      and then device A is assigned to domain A, device B is assigned to domain
      B. So domain A can read something from that range, even rewrite
      maliciously that range to corrupt device B inside domain B.

proposal:
    * We will group all devices by means of one same RMRR entry. Theoretically,
      we should make sure all devices in one group are allowed to assign to one
      VM. But in Xen side the hardware domain owns all devices at first, we
      should unbound all group devies before assign one of group device. But its
      hard to do such thing in current VT-d stuff. And actually its rare to have
      the group device in real world so we just prevent assigning any group
      device simply.
    * We will introduce two field, gid, in struct, acpi_rmrr_unit:
        gid: indicate if this device belongs a group.
      Then when we add or attach device in iommu side, we will check this field
      if we're assigning a group device then determine if we assign that.


expectation:
    * Make all device associated to one RMRR to be assigned same VM.

4. Handle in case of force accessing to RMRR regions

proposal:
    * Although we already reserve these ranges in guest e820 table, its
      possible to access these ranges.
      In non-shared ept case it will issue such EPT violation since we have no
      p2m table actually. But its same to access other reserved range so just
      live on Xen's default behavior. In shared-ept case guest can read or
      write anything from this range, but such a leak or corruption just
      happens inside same domain so this behavior is also same as a native
      case, it should be fine.

expectation:
    * Don't broken normal RMRR usage.

5. Re-enable USB

current status:
    * Currently Xen doesn't allow USB passthrough.

proposal:
    * Cleanup some legacy codes related to RMRR to accommodate our RMRR
      support.

expectation:
    * Make USB wor well after we handle RMRR properly.

6. Hotplug case

current status:
    * only work well in non-shared ept case or in case of shared ept & all
      associated gfns are free.

proposal:
    * If user ensure there'll be a hotplug device in advace, 'rdm_forcecheck'
      can be set to reserve all RMRR range as we describe above. Then any
      device can be hotplugged successfully.
    * If not, there are still two scenarios here:
      in non-shared ept case it still work well as original;
      in shared ept case, its just going a case of "1. Setup RMRR identity
      mapping"
        - gfn space unoccupied -> insert mapping: success.
        - gfn space already occupied by 1:1 RMRR mapping -> do nothing; success.
        - gfn space already occupied by other mapping -> fail.

expectation:
    * provide a way to let hotplug work in case of shared ept totally

Open Issue
==========

When other stuffs like ballon mechanism, to populate memory accessing RMRR
range, or others like qemu, force map RMRR range, we may need to avoid such a
possibility but we're not 100% sure this so just open this to double check.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 01:23:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 01:23:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1mHl-0004Jg-11; Fri, 19 Dec 2014 01:23:17 +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 1Y1mHj-0004Jb-UN
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 01:23:16 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	AD/12-02707-30E73945; Fri, 19 Dec 2014 01:23:15 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418952192!14221369!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 17344 invoked from network); 19 Dec 2014 01:23:13 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-6.tower-206.messagelabs.com with SMTP;
	19 Dec 2014 01:23:13 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 18 Dec 2014 17:21:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,604,1413270000"; d="scan'208";a="626318172"
Received: from tchen0-linux.bj.intel.com ([10.238.135.72])
	by orsmga001.jf.intel.com with ESMTP; 18 Dec 2014 17:23:09 -0800
From: Tiejun Chen <tiejun.chen@intel.com>
To: JBeulich@suse.com, konrad.wilk@oracle.com, tim@xen.org,
	kevin.tian@intel.com, yang.z.zhang@intel.com,
	stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com,
	ian.jackson@eu.citrix.com, wei.liu2@citrix.com
Date: Fri, 19 Dec 2014 09:21:06 +0800
Message-Id: <1418952066-21064-1-git-send-email-tiejun.chen@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] RMRR Fix Design for Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

                    RMRR Fix Design for Xen

This design is a goal to fix RMRR for Xen. It includes four sectors as
follows:

    * Background
    * What is RMRR
    * Current RMRR Issues
    * Design Overview

We hope this can help us to understand current problem then figure out a
clean and better solution everyone can agree now to go forward.

Background
==========

We first identified this RMRR defect when trying to pass-through IGD device,
which can be simply fixed by adding an identity mapping in case of shared
EPT table. However along with the community discussion, it boiled down to
a more general RMRR problem, i.e. the identity mapping is brute-added
in hypervisor, w/o considering whether conflicting with an existing guest
PFN ranges. As a general solution we need invent a new mechanism so
reserved ranges allocated by hypervisor can be exported to the user space
toolstack and hvmloader, so conflict can be detected when constructing
guest PFN layout, with best-effort avoidance policies to further help.

What is RMRR
============

RMRR is a acronym for Reserved Memory Region Reporting.

BIOS may report each such reserved memory region through the RMRR structures,
along with the devices that requires access to the specified reserved memory
region. Reserved memory ranges that are either not DMA targets, or memory
ranges that may be target of BIOS initiated DMA only during pre-boot phase
(such as from a boot disk drive) must not be included in the reserved memory
region reporting. The base address of each RMRR region must be 4KB aligned and
the size must be an integer multiple of 4KB. BIOS must report the RMRR reported
memory addresses as reserved in the system memory map returned through methods
suchas INT15, EFI GetMemoryMap etc. The reserved memory region reporting
structures are optional. If there are no RMRR structures, the system software
concludes that the platform does not have any reserved memory ranges that are 
DMA targets.

The RMRR regions are expected to be used for legacy usages (such as USB, UMA
Graphics, etc.) requiring reserved memory. Platform designers shouldavoid or
limit use of reserved memory regions since these require system software to
create holes in the DMA virtual address range available to system software and
its drivers.

The following is grabbed from my BDW:

(XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ab80a000 end_address ab81dfff
(XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ad000000 end_address af7fffff

Here USB occupies 0xab80a000:0xab81dfff, IGD owns 0xad000000:0xaf7fffff.

Note there are zero or more Reserved Memory Region Reporting (RMRR) in one given
platform. And multiple devices may share one RMRR range. Additionally RMRR can
go anyplace.

Current RMRR Issues
===================

#1 RMRR may conflict RAM, mmio or other ranges in Guest physical level.

#2 Xen doesn't create RMRR mapping in case of shared ept, then the assigned
   device can't work well.

#3 Xen doesn't consider that case multiple devices may share one RMRR entry.
   This also is a damage between different VMs when we assign such devices to
   different VMs.

#4 Something like USB, is still restricted to current RMRR implementation. We
   should work out this case.

Design Overview
===============

First of all we need to make sure all resources don't overlap RMRR. And then
in case of shared ept, we can set these identity entries. And Certainly we will
group all devices associated to one same RMRR entry, then make sure all group
devices should be assigned to same VM.

1. Setup RMRR identity mapping

current status:
    * identity mapping only setup in non-shared ept case

proposal:

In non-shared ept case, IOMMU stuff always set those entries and RMRR is already
marked reserved in host so its fine enough. But in shared ept case, we need to
check any conflit, so we should follow up

  - gfn space unoccupied
        -> insert mapping: success.
            gfn:_mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct, p2m_access_rw
  - gfn space already occupied by 1:1 RMRR mapping
        -> do nothing; success.
  - gfn space already occupied by other mapping
        -> fail.

expectation:
    * only devices w/ non-conflicting RMRR can be assigned
    * fortunately this achieves the very initial intention to support IGD
      pass-through on BDW
    * provide last level protection in hypervisor to ensure a secure assignment

2. Check to reserve RMRR in guest physical level

current status:
    * Xen doesn't reserve RMRR in guest physical level

proposal:
    * Get RMRR info as necessary
    * Then check all potential points to reserve or skip RMRR

expectation:
    * Make sure all guest resources don't overlap RMRR range.

2.1 Expose RMRR to user space

current status:
    * Xen always record RMRR info into one list, acpi_rmrr_units, while parsing
      acpi. So we can retrieve these info by lookup that list.

proposal:
    * RMRR would be exposed by a new hypercall, which Jan already finished in
      current version but just expose all RMRR info unconditionally.
    * Furthermore we can expose RMRR on demand to diminish shrinking guest
      RAM/MMIO space.
    * So we will introduce a new parameter, 'rdm_forcecheck' and to collaborate
      with SBDFs to control which RMRR should be exposed:

        - We can set this parameter in .cfg file like,

            rdm_forcecheck = 1 => Of course this should be 0 by default.

        '1' means we should force check to reserve all ranges unconditionally.
        and 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.

        If 0, we just check those assigned pci devices. As you know we already
        have such an existing hypercall to assign PCI devices, looks we can work
        directly under this hypercall to get that necessary SBDF to sort which
        RMRR should be handled. But obviously, we need to get these info before
        we populate guest memory to make sure these RMRR ranges should be
        excluded from guest memory. But unfortunately the memory populating
        takes place before a device assignment, so we can't live on that
        directly.

        But as we discussed it just benefit that assigned case to reorder that
        order, but not good to hotplug case. So we have to introduce a new
        DOMCTL to pass that global parameter with SBDF at the same time.

        For example, if we own these two RMRR entries,

        [00:14.0]    RMRR region: base_addr ab80a000 end_address ab81dfff
        [00:02.0]    RMRR region: base_addr ad000000 end_address af7fffff

        If 'rdm_forcecheck = 1', any caller to that hypercall may get these two
        entries. But if 'rdm_forcecheck = 0', and in .cfg file,

        #1 'pci=[00:14.0, 00:02.0]' -> The caller still get these two entries.
        #2 'pci=[00:02.0]' -> The caller just get one entry, 0xad000000:0xaf7fffff
        #2 'pci=[00:14.0]' -> The caller just get one entry, 0xab80a000:0xab81dfff
        #4 'pci=[others]' or no any pci configuration -> The caller get nothing.

        And ultimately, if we expose any RMRR entry at gfn,

        in non-shared ept case, 

        p2m table:  valid non-identity mapping, gfn:mfn != 1:1
        VT-D table: no such a mapping until set identity mapping,
                    gfn:_mfn(gfn) == 1:1 when we have a associated device
                    assignment.
        
        in shared ept case,

        p2m table\VT-D table:  always INVALID until set identity mapping,
                               gfn:_mfn(gfn) == 1:1 when we have a associated
                               device assignment.

        But if we don't expose any RMRR entry,

        in non-shared ept case, 

        p2m table:  valid non-identity mapping, gfn:mfn != 1:1
        VT-D table: no such a mapping until set identity mapping,
                    gfn:_mfn(gfn) == 1:1 when we have a associated device
                    assignment.

        in shared ept case,

        p2m table\VT-D table:  If guest RAM already cover gfn, we have sunc a
                               valid non-identity mapping, gfn:mfn != 1:1, but
                               we can't set any identity mapping again then
                               that associated device can't be assigned
                               successfully. If not, we'll set identity mapping,
                               gfn:_mfn(gfn) == 1:1, to work well.

 
expectation:
    * Provice a way to get necessary RMRR info.

Note here that new DOMCTL is already finished but need to fix some code style
issues.

2.2 Detect and avoid RMRR conflictions with guest RAM/MMIO

current status:
    * Currently Xen doesn't detect anything to avoid any conflict.

proposal:
    * We need to cover all points to check any conflict. Below lists places
      where reserved region conflictions should be detected:

        1>. libxc:setup_guest():modules_init()

        There are some modules, like acpi_module and smbios_module. They may
        occupy some ranges so we need to check if they're conflicting with
        all ranges from that new hypercall above.

        2>. libxc:setup_guest():xc_domain_populate_physmap()

        There are two ways to exclude RMRR ranges here:
            
            #1 Before we populate guest RAM without any RMRR range from that
               new hypercall to skip RMRR ranges when populating guest RAM.
            #2 In Xen we can fliter RMRR range while calling
               XENMEM_populate_physmap, its no change to libxc, but skip
               setting p2m entry for RMRR ranges in Xen hypervisor

        But to compare #1, #2 is not better since Xen still allocate those
        range, and we have to sync somewhere else in Xen. And #1 is cleaner
        because #2 actually shrinks the available memory size to the guest.

        3>. hvmloader:pci_setup()

        Here we should populate guest MMIO excluding all ranges from that new
        hypercall to detect RMRR conflictions for allocating PCI MMIO BAR.

        4>. hvmloader:mem_hole_alloc()

        Here we should populate mem holw excluding all ranges from that new
        hypercall to detect RMRR conflictions for dynamic allocation in
        hvmloader, e.g. as used for IGD opregion

        5>. hvmloader:build_e820_table():

        Finally we need let VM know that RMRR regions are reserved through e820
        table

    Its a little bit tricky to handle this inside hvmloader since as you know,
    struct hvm_info_table is only a approach between libxc and hvmloader. But
    however, making up all above places will bring some duplicated logic.
    Especially between libxc and hvmloader, which skip same regions in guest
    physical layer(one in populating guest RAM, the other in constructing e820)
    But current design has some limitation to pass information between libxc and
    hvmloader,

struct hvm_info_table {
    ...
    /*
     *  0x0 to page_to_phys(low_mem_pgend)-1:
     *    RAM below 4GB (except for VGA hole 0xA0000-0xBFFFF)
     */
    uint32_t    low_mem_pgend;
    ...
    /*
     *  0x100000000 to page_to_phys(high_mem_pgend)-1:
     *    RAM above 4GB
     */
    uint32_t    high_mem_pgend;
    ...
}

    nothing valuable is passed to hvmloader so we have to figure out a way to
    handle those points in hvmloader. Currently,

            #1 Reconstruct hvm_info_table{}

            We can store all necessary RMRR info into hvm_info_table as well,
            then we can pick them conveniently but oftentimes these RMRR
            entries are scattered and the number is also undertimined, so its
            a little bit ugly to do.

            #2 Xenstore

            We may store all necessary RMRR info as Xenstore then pick them in
            hvmloader.

            #3 A hypercall

            We may have to call our new hypercall again to pick them, but
            obviously this may introduce some duplicated codes.

            #4 XENMEM_{set_,}memory_map pair of hypercalls
            
            As Jan commented it "could be used(and is readily available to be
            extended that way, since for HVM domains XENMEM_set_memory_map
            returns -EPERM at present). The only potentially problematic aspect
            I can see with using it might be its limiting of the entry count to
            E820MAX." So a preparation patch is required before RMRR, and
            hvmloader still needs to query RMRR information.

expectation:
    * Cover all points to make sure guest doesn't occupt any RMRR range.

3. Group multiple devices sharing same RMRR entry

current status:
    * Xen doesn't distinguish if multiple devices share same RMRR entry. This
      may lead a leak to corruption, e.g. Device A and device B share same entry
      and then device A is assigned to domain A, device B is assigned to domain
      B. So domain A can read something from that range, even rewrite
      maliciously that range to corrupt device B inside domain B.

proposal:
    * We will group all devices by means of one same RMRR entry. Theoretically,
      we should make sure all devices in one group are allowed to assign to one
      VM. But in Xen side the hardware domain owns all devices at first, we
      should unbound all group devies before assign one of group device. But its
      hard to do such thing in current VT-d stuff. And actually its rare to have
      the group device in real world so we just prevent assigning any group
      device simply.
    * We will introduce two field, gid, in struct, acpi_rmrr_unit:
        gid: indicate if this device belongs a group.
      Then when we add or attach device in iommu side, we will check this field
      if we're assigning a group device then determine if we assign that.


expectation:
    * Make all device associated to one RMRR to be assigned same VM.

4. Handle in case of force accessing to RMRR regions

proposal:
    * Although we already reserve these ranges in guest e820 table, its
      possible to access these ranges.
      In non-shared ept case it will issue such EPT violation since we have no
      p2m table actually. But its same to access other reserved range so just
      live on Xen's default behavior. In shared-ept case guest can read or
      write anything from this range, but such a leak or corruption just
      happens inside same domain so this behavior is also same as a native
      case, it should be fine.

expectation:
    * Don't broken normal RMRR usage.

5. Re-enable USB

current status:
    * Currently Xen doesn't allow USB passthrough.

proposal:
    * Cleanup some legacy codes related to RMRR to accommodate our RMRR
      support.

expectation:
    * Make USB wor well after we handle RMRR properly.

6. Hotplug case

current status:
    * only work well in non-shared ept case or in case of shared ept & all
      associated gfns are free.

proposal:
    * If user ensure there'll be a hotplug device in advace, 'rdm_forcecheck'
      can be set to reserve all RMRR range as we describe above. Then any
      device can be hotplugged successfully.
    * If not, there are still two scenarios here:
      in non-shared ept case it still work well as original;
      in shared ept case, its just going a case of "1. Setup RMRR identity
      mapping"
        - gfn space unoccupied -> insert mapping: success.
        - gfn space already occupied by 1:1 RMRR mapping -> do nothing; success.
        - gfn space already occupied by other mapping -> fail.

expectation:
    * provide a way to let hotplug work in case of shared ept totally

Open Issue
==========

When other stuffs like ballon mechanism, to populate memory accessing RMRR
range, or others like qemu, force map RMRR range, we may need to avoid such a
possibility but we're not 100% sure this so just open this to double check.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 02:08:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 02:08:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1mz9-00064I-Oz; Fri, 19 Dec 2014 02:08: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 1Y1mz8-00064A-Lz
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 02:08:06 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	55/E1-26858-58883945; Fri, 19 Dec 2014 02:08:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418954883!14468355!1
X-Originating-IP: [66.165.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 7809 invoked from network); 19 Dec 2014 02:08:04 -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;
	19 Dec 2014 02:08:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,604,1413244800"; d="scan'208";a="206081898"
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.210.2; Thu, 18 Dec 2014 21:08: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 1Y1mz3-0000am-Ls;
	Fri, 19 Dec 2014 02:08:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1mz3-0000i3-FZ;
	Fri, 19 Dec 2014 02:08:01 +0000
Date: Fri, 19 Dec 2014 02:08:01 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32441-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] 32441: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32441 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32441/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           5 kernel-build              fail REGR. vs. 32392

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail pass in 32424

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 12 guest-localmigrate       fail blocked in 32392
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail like 32487-bisect
 test-amd64-amd64-xl-sedf-pin  5 xen-boot              fail in 32424 like 32392

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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
 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                  7e88c23239591e2638bcc944151a660fcd53495b
baseline version:
 xen                  2676bc915157ab474ee478d929b0928cf696b385

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.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                                          fail    
 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-amd64-xl-pvh-amd                                  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                          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                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-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.

------------------------------------------------------------
commit 7e88c23239591e2638bcc944151a660fcd53495b
Author: George Dunlap <george.dunlap@eu.citrix.com>
Date:   Tue Dec 9 14:04:19 2014 +0000

    libxl: Tell qemu to use raw format when using a tapdisk
    
    At the moment libxl unconditinally passes the underlying file format
    to qemu in the device string.  However, when tapdisk is in use,
    tapdisk handles the underlying format and presents qemu with
    effectively a raw disk.  When qemu looks at the tapdisk block device
    and doesn't find the image format it was looking for, it will fail.
    
    This effectively means that tapdisk cannot be used with HVM domains at
    the moment except for raw files.
    
    Instead, if we're using a tapdisk backend, tell qemu to use a raw file
    format.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    [ ijc -- nuked extra blank line ]

commit 09b7ff1a118f5e920ef12f5592f3ce991218962a
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Dec 15 10:56:24 2014 +0000

    xl: print message to stdout when (!debug && dryrun)
    
    In commit d36a3734a ("xl: fix migration failure with xl migrate
    --debug"), message is printed to stderr for both debug mode
    and dryrun mode. That caused rdname() in xendomains fails to parse
    domain name since it's expecting input from xl's stdout.
    
    So this patch separates those two cases. If xl is running in debug mode,
    then message is printed to stderr; if xl is running in dryrun mode and
    debug is not enabled, message is printed to stdout. This will fix
    xendomains and other scripts that use "xl create --dryrun", as well as
    not re-introducing the old bug fixed in d36a3734a.
    
    Reported-by: Mark Pryor <tlviewer@yahoo.com>
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Cc: M A Young <m.a.young@durham.ac.uk>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Wilk <konrad.wilk@oracle.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit afa3fd8753c944f37c1cd182d5ad7c436c7614da
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Fri Dec 12 18:26:02 2014 +0000

    docs/commandline: Minor formatting fixes and clarifications
    
    `font` had a trailing single quote which was out of place.
    
    `gnttab_max_frames` was missing escapes for the underscores which caused the
    underscores to take their markdown meaning, causing 'max' in the middle to be
    italicised.  Escape the underscores, and make all command line parameters
    bold, to be consistent with the existing style.
    
    Clarify how the default for `nmi` changes between debug and non debug builds
    of Xen.
    
    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>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 3f727fb1a7d5f3be2513ab2e692b067075325fb3
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Tue Dec 9 16:43:22 2014 +0000

    python/xc: Fix multiple issues in pyflask_context_to_sid()
    
    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.
    
    Coverity also complains about passing a non-NUL terminated string to
    xc_flask_context_to_sid().  xc_flask_context_to_sid() doesn't actually take a
    NUL terminated string, but it does take a char* which, in context, used to be
    a string, which is why Coverity complains.
    
    One solution would be to use strdup(ctx) which is simpler than a
    strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated
    string being used with xc_flask_context_to_sid().
    
    However, ctx is strictly an input to the hypercall and is not mutated along
    the way.  Both these issues can be fixed, and the error logic simplified, by
    not duplicating ctx in the first place.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Coverity-IDs: 1055305 1055721
    Acked-by: 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>

commit dcd84861b0b01b8895716d4c803c9d24c31c8cab
Author: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date:   Mon Dec 8 15:51:47 2014 +0200

    xen/serial: setup UART idle mode for OMAP
    
    The UART is not able to receive bytes when idle mode is not configured
    properly, therefore setup the UART with autoidle and wakeup enabled.
    
    Older Linux kernels (for example 3.8) configure hwmods for all devices
    even if the device tree nodes for those devices is absent in device
    tree, thus UART idle mode is configured too.  With such kernels we can
    workaround the issue by adding a fake node in the UART containing this
    MMIO range, which is therefore mapped by Xen to dom0, which
    reconfigures the UART, causing things to work normally.
    
    Newer Linux Kernels (3.12 and beyond) do not configure idle mode for
    UART and so this hack no longer works.
    
    Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    [ ijc -- updated commit message as discussed ]

commit 6c9b27d3f363889718e7e046511383927f257095
Merge: 2676bc9 05fecc3
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Dec 15 17:40:12 2014 +0000

    Merge tag '4.5.0-rc4' into staging
    
    Xen 4.5.0 RC4

commit 05fecc382e129731c6595268a377f4bff879f694
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Dec 15 11:35:59 2014 -0500

    Xen-4.5.0-rc4: Update tag for qemu-xen.
    
    QEMU-traditional has nothing new, so stay at rc1 there.
    
    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 Dec 19 02:08:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 02:08:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1mz9-00064I-Oz; Fri, 19 Dec 2014 02:08: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 1Y1mz8-00064A-Lz
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 02:08:06 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	55/E1-26858-58883945; Fri, 19 Dec 2014 02:08:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418954883!14468355!1
X-Originating-IP: [66.165.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 7809 invoked from network); 19 Dec 2014 02:08:04 -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;
	19 Dec 2014 02:08:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,604,1413244800"; d="scan'208";a="206081898"
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.210.2; Thu, 18 Dec 2014 21:08: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 1Y1mz3-0000am-Ls;
	Fri, 19 Dec 2014 02:08:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1mz3-0000i3-FZ;
	Fri, 19 Dec 2014 02:08:01 +0000
Date: Fri, 19 Dec 2014 02:08:01 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32441-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] 32441: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32441 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32441/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           5 kernel-build              fail REGR. vs. 32392

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail pass in 32424

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 12 guest-localmigrate       fail blocked in 32392
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail like 32487-bisect
 test-amd64-amd64-xl-sedf-pin  5 xen-boot              fail in 32424 like 32392

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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
 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                  7e88c23239591e2638bcc944151a660fcd53495b
baseline version:
 xen                  2676bc915157ab474ee478d929b0928cf696b385

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.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                                          fail    
 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-amd64-xl-pvh-amd                                  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                          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                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-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.

------------------------------------------------------------
commit 7e88c23239591e2638bcc944151a660fcd53495b
Author: George Dunlap <george.dunlap@eu.citrix.com>
Date:   Tue Dec 9 14:04:19 2014 +0000

    libxl: Tell qemu to use raw format when using a tapdisk
    
    At the moment libxl unconditinally passes the underlying file format
    to qemu in the device string.  However, when tapdisk is in use,
    tapdisk handles the underlying format and presents qemu with
    effectively a raw disk.  When qemu looks at the tapdisk block device
    and doesn't find the image format it was looking for, it will fail.
    
    This effectively means that tapdisk cannot be used with HVM domains at
    the moment except for raw files.
    
    Instead, if we're using a tapdisk backend, tell qemu to use a raw file
    format.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    [ ijc -- nuked extra blank line ]

commit 09b7ff1a118f5e920ef12f5592f3ce991218962a
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Dec 15 10:56:24 2014 +0000

    xl: print message to stdout when (!debug && dryrun)
    
    In commit d36a3734a ("xl: fix migration failure with xl migrate
    --debug"), message is printed to stderr for both debug mode
    and dryrun mode. That caused rdname() in xendomains fails to parse
    domain name since it's expecting input from xl's stdout.
    
    So this patch separates those two cases. If xl is running in debug mode,
    then message is printed to stderr; if xl is running in dryrun mode and
    debug is not enabled, message is printed to stdout. This will fix
    xendomains and other scripts that use "xl create --dryrun", as well as
    not re-introducing the old bug fixed in d36a3734a.
    
    Reported-by: Mark Pryor <tlviewer@yahoo.com>
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Cc: M A Young <m.a.young@durham.ac.uk>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Wilk <konrad.wilk@oracle.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit afa3fd8753c944f37c1cd182d5ad7c436c7614da
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Fri Dec 12 18:26:02 2014 +0000

    docs/commandline: Minor formatting fixes and clarifications
    
    `font` had a trailing single quote which was out of place.
    
    `gnttab_max_frames` was missing escapes for the underscores which caused the
    underscores to take their markdown meaning, causing 'max' in the middle to be
    italicised.  Escape the underscores, and make all command line parameters
    bold, to be consistent with the existing style.
    
    Clarify how the default for `nmi` changes between debug and non debug builds
    of Xen.
    
    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>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 3f727fb1a7d5f3be2513ab2e692b067075325fb3
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Tue Dec 9 16:43:22 2014 +0000

    python/xc: Fix multiple issues in pyflask_context_to_sid()
    
    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.
    
    Coverity also complains about passing a non-NUL terminated string to
    xc_flask_context_to_sid().  xc_flask_context_to_sid() doesn't actually take a
    NUL terminated string, but it does take a char* which, in context, used to be
    a string, which is why Coverity complains.
    
    One solution would be to use strdup(ctx) which is simpler than a
    strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated
    string being used with xc_flask_context_to_sid().
    
    However, ctx is strictly an input to the hypercall and is not mutated along
    the way.  Both these issues can be fixed, and the error logic simplified, by
    not duplicating ctx in the first place.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Coverity-IDs: 1055305 1055721
    Acked-by: 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>

commit dcd84861b0b01b8895716d4c803c9d24c31c8cab
Author: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date:   Mon Dec 8 15:51:47 2014 +0200

    xen/serial: setup UART idle mode for OMAP
    
    The UART is not able to receive bytes when idle mode is not configured
    properly, therefore setup the UART with autoidle and wakeup enabled.
    
    Older Linux kernels (for example 3.8) configure hwmods for all devices
    even if the device tree nodes for those devices is absent in device
    tree, thus UART idle mode is configured too.  With such kernels we can
    workaround the issue by adding a fake node in the UART containing this
    MMIO range, which is therefore mapped by Xen to dom0, which
    reconfigures the UART, causing things to work normally.
    
    Newer Linux Kernels (3.12 and beyond) do not configure idle mode for
    UART and so this hack no longer works.
    
    Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    [ ijc -- updated commit message as discussed ]

commit 6c9b27d3f363889718e7e046511383927f257095
Merge: 2676bc9 05fecc3
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Dec 15 17:40:12 2014 +0000

    Merge tag '4.5.0-rc4' into staging
    
    Xen 4.5.0 RC4

commit 05fecc382e129731c6595268a377f4bff879f694
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Dec 15 11:35:59 2014 -0500

    Xen-4.5.0-rc4: Update tag for qemu-xen.
    
    QEMU-traditional has nothing new, so stay at rc1 there.
    
    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 Dec 19 02:10:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 02: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 1Y1n1k-0006AA-Fw; Fri, 19 Dec 2014 02:10:48 +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 1Y1n1j-0006A3-5Q
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 02:10:47 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	A8/4A-31453-62983945; Fri, 19 Dec 2014 02:10:46 +0000
X-Env-Sender: yanghy@cn.fujitsu.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418955043!14249037!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2474 invoked from network); 19 Dec 2014 02:10:45 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-4.tower-206.messagelabs.com with SMTP;
	19 Dec 2014 02:10:45 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="45475658"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 19 Dec 2014 10:07:22 +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 sBJ2AGUM026918;
	Fri, 19 Dec 2014 10:10:16 +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; Fri, 19 Dec 2014 10:10:42 +0800
Message-ID: <549388F6.9000108@cn.fujitsu.com>
Date: Fri, 19 Dec 2014 10:09:58 +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: Anthony Korzan <akorzan@gmail.com>, <xen-devel@lists.xen.org>
References: <788CC804-7FC8-40C4-B17B-E02CDB7F2683@gmail.com>
In-Reply-To: <788CC804-7FC8-40C4-B17B-E02CDB7F2683@gmail.com>
X-Originating-IP: [10.167.226.223]
Cc: rshriram@cs.ubc.ca
Subject: Re: [Xen-devel] [Xen 4.5-rc] remus-drbd incompatible with Linux
	3.6+ 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: 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

SGksCgrlnKggMTIvMTkvMjAxNCAwNTo0OCBBTSwgQW50aG9ueSBLb3J6YW4g5YaZ6YGTOgo+IEhl
bGxvIQo+Cj4gSSBoYXZlIG9ubHkgbWFuYWdlZCB0byBnZXQgWGVuIDQuNSdzIFJlbXVzICJ3b3Jr
aW5nIiBvbiBMaW51eCBLZXJuZWxzIGxlc3MgdGhhbgo+IDMuNS4gVGhlIHByb3ZpZGVkIHJlbXVz
LWRyYmQsIGFzIGRldGFpbGVkIGluIGRvY3MvUkVBRE1FLnJlbXVzIGFuZCBhdmFpbGFibGUKPiBm
cm9tIGh0dHBzOi8vZ2l0aHViLmNvbS9yc2hyaXJhbS9yZW11cy1kcmJkIHdpbGwgbm90IGNvbXBp
bGUgd2l0aCBMaW51eCBLZXJuZWxzCj4gMy42IGFuZCBhYm92ZS4KClRoZSBEUkJEIHlvdSBnZXQg
ZnJvbSBodHRwczovL2dpdGh1Yi5jb20vcnNocmlyYW0vcmVtdXMtZHJiZCBpcyBEUkJEIDguMy4x
MQphbmQgdGhpcyB2ZXJzaW9uIG9ubHkgY29tcGF0aWJsZSB3aXRoIExpbnV4IDMuMH4zLjQsIHNl
ZSB0aGUgdGFibGUgb24gdGhpcyBwYWdlOgpodHRwOi8vd3d3LmRyYmQub3JnL2Rvd25sb2FkL21h
aW5saW5lLwoKSSdtIGFmcmFpZCBEUkJEIDguMy4xMSBpcyB0aGUgb25seSB2ZXJzaW9uIHRoYXQg
eW91IGNhbiBnZXQgUmVtdXMgd29yayBvbgpjdXJyZW50bHkuIEluIHRoZSBwYXN0LCBSZW11cyBk
aXNrIHJlcGxpY2F0aW9uIGJhc2VkIG9uIGJsa3RhcDIsIGJ1dCBibGt0YXAyCmlzIGdldHRpbmcg
ZGVwcmVjYXRlZCBJIHRoaW5rLCB0aGVyZSdzIG5vIG1haW50YWluZXJzIG5vciBwYXRjaGVzIHJl
Y2VudCB5ZWFycy4KCklmIHlvdSBhcmUgaW50ZXJlc3QsIHRoZXJlJ3MgYSBuZXcgRlQgc29sdXRp
b24gYmFzZWQgb24gUmVtdXM6Cmh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9DT0xPXy1fQ29hcnNl
X0dyYWluX0xvY2tfU3RlcHBpbmcKClRoaXMgc29sdXRpb24gdXNlIGJsa3RhcDIgYXMgZGlzayBy
ZXBsaWNhdGlvbiwgYW5kIGl0IGhhcyBsb3RzIG9mIHBhdGNoZXMgdG8KZ2V0IGJsa3RhcDIgd29y
ayB3aXRoIHhsLgoKRnV0aGVybW9yZSwgd2UgYXJlIHdvcmtpbmcgb24gYSBiZXR0ZXIgc29sdXRp
b24gb24gZGlzayByZXBsaWNhdGlvbiBvbiBib3RoClJlbXVzL0NPTE8uIENPTE8gaXMgc3VwcG9z
ZWQgdG8gZ2V0IGludG8gWGVuIDQuNi4KCj4KPiBPbmUgb2YgdGhlc2UgZXJyb3JzIGlzIHRoYXQg
cmVtdXMtZHJiZCB1c2VzIGEgdHdvIGFyZ3VtZW50IHZlcnNpb24gb2YgdGhlIG1hY3JvCj4ga3Vu
bWFwX2F0b21pYyBmb3VuZCBpbiBpbmNsdWRlL2xpbnV4L2hpZ2htZW0uaAo+IFRoaXMgd2FzIGRl
cHJlY2F0ZWQgYW5kIGlzIG5vIGxvbmdlciBpbmNsdWRlZCBpbiBhbnkgS2VybmVscyBhYm92ZSAz
LjYuCj4KPiAiZXJyb3I6IG1hY3JvICJrdW5tYXBfYXRvbWljIiBwYXNzZWQgMiBhcmd1bWVudHMs
IGJ1dCB0YWtlcyBqdXN0IDEiCj4KPiBJcyB0aGVyZSBhIHBhdGNoIGF2YWlsYWJsZT8gIElmIG5v
dCwgd2hhdCBzZXQgdXAgZG8gdGhlIFJlbXVzIGRldnMgdXNlIHRvIHRlc3Q/Cj4gICBJIGp1c3Qg
bmVlZCBhICJzdGFibGUtaXNoIiBwbGF0Zm9ybSB0byBtb2RpZnkgcmVtdXMgb24uCj4KPgo+IE5v
dyBJIGRpZCBnZXQgUmVtdXMgIndvcmtpbmciIG9uIExpbnV4IDMuNCwgVWJ1bnR1IDE0LjA0LCBh
bmQgdGhlIGN1c3RvbQo+IHJlbXVzLWRyYmQuICBUaGUgaXNzdWUgSSBydW4gaW50byBpcyB0aGF0
IFJlbXVzIG9ubHkgcGx1Z3MgYW5kIHVucGx1Z3MgYSBmZXcKPiBodW5kcmVkIHRpbWVzIHVudGls
IHRoZXJlIGlzIGEgIkNvbm5lY3Rpb24gdGltZW91dCBlcnJvci4iICBJdCBjb3VsZCBiZSB0aGF0
IEkKPiBhbSB1c2luZyBhbiAib2xkIiBsaW51eCBrZXJuZWwgdmVyc2lvbiB3aXRob3V0IG11Y2gg
WGVuIGludGVncmF0aW9uLCBidXQgSSdtCj4gc3R1bXBlZCBhYm91dCB0aGlzIGVycm9yOgoKQ2Fu
IHlvdSB0cnkgdG8gdXNlIExpbnV4IDMuMCB0byBzZWUgaWYgdGhlIGVycm9yIHN0aWxsIGV4aXN0
cz8KSSB3aWxsIHRha2UgYSBsb29rIG9uIHRoaXMgcHJvYmxlbSB0byBzZWUgaWYgSSBjYW4gcmVw
cm9kdWNlIGl0LgoKPgo+ICMjIwo+IC4uLgo+IHhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9y
eSBwYWdlczogODk1MDE1LzY1NTM2ICAxMzY1JQo+IHhjOiBTYXZpbmcgbWVtb3J5OiBpdGVyIDE0
MTYgKGxhc3Qgc2VudCA1Njggc2tpcHBlZCAwKTogNjU1MzYvNjU1MzYgIDEwMCUKPiAuLi4KPiB4
YzogU2F2aW5nIG1lbW9yeTogaXRlciAxNDIwIChsYXN0IHNlbnQgNTY3IHNraXBwZWQgMCk6IDY1
NTM2LzY1NTM2ICAxMDAlCj4geGM6IGVycm9yOiByZGV4YWN0IGZhaWxlZCAoc2VsZWN0IHJldHVy
bmVkIDApOiBJbnRlcm5hbCBlcnJvcgo+IHhjOiBlcnJvcjogRXJyb3Igd2hlbiByZWFkaW5nIGJh
dGNoIHNpemUgKDExMCA9IENvbm5lY3Rpb24gdGltZWQgb3V0KTogSW50ZXJuYWwKPiBlcnJvcgo+
IHhjOiBlcnJvcjogZXJyb3Igd2hlbiBidWZmZXJpbmcgYmF0Y2gsIGZpbmlzaGluZyAoMTEwID0g
Q29ubmVjdGlvbiB0aW1lZCBvdXQpOgo+IEludGVybmFsIGVycm9yCj4gbWlncmF0aW9uIHRhcmdl
dDogUmVtdXMgRmFpbG92ZXIgZm9yIGRvbWFpbiA1Cj4gbGlieGw6IGVycm9yOiBsaWJ4bF91dGls
cy5jOjQzMDpsaWJ4bF9yZWFkX2V4YWN0bHk6IGZpbGUvc3RyZWFtIHRydW5jYXRlZAo+IHJlYWRp
bmcgaXBjIG1zZyBoZWFkZXIgZnJvbSBkb21haW4gNSBzYXZlL3Jlc3RvcmUgaGVscGVyIHN0ZG91
dCBwaXBlCj4gbGlieGw6IGVycm9yOiBsaWJ4bF9leGVjLmM6MTI5OmxpYnhsX3JlcG9ydF9jaGls
ZF9leGl0c3RhdHVzOiBkb21haW4gNQo+IHNhdmUvcmVzdG9yZSBoZWxwZXIgWy0xXSBkaWVkIGR1
ZSB0byBmYXRhbCBzaWduYWwgQnJva2VuIHBpcGUKPiBsaWJ4bDogd2FybmluZzogbGlieGxfZG9t
LmM6MjAxNTpkb21haW5fc3VzcGVuZF9kb25lOiBSZW11czogRG9tYWluIHN1c3BlbmQKPiB0ZXJt
aW5hdGVkIHdpdGggcmMgLTMsIHRlYXJkb3duIFJlbXVzIGRldmljZXMuLi4KPiBSZW11czogQmFj
a3VwIGZhaWxlZD8gcmVzdW1pbmcgZG9tYWluIGF0IHByaW1hcnkuCj4geGM6IGVycm9yOiBEb20g
NSBub3Qgc3VzcGVuZGVkOiAoc2h1dGRvd24gMCwgcmVhc29uIDI1NSk6IEludGVybmFsIGVycm9y
Cj4gbGlieGw6IGVycm9yOiBsaWJ4bC5jOjUwNTpsaWJ4bF9fZG9tYWluX3Jlc3VtZTogeGNfZG9t
YWluX3Jlc3VtZSBmYWlsZWQgZm9yCj4gZG9tYWluIDU6IEludmFsaWQgYXJndW1lbnQKPiAjIyMK
Pgo+IFNpbmNlcmVseSwKPiBBbnRob255CgotLSAKVGhhbmtzLApZYW5nLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Dec 19 02:10:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 02: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 1Y1n1k-0006AA-Fw; Fri, 19 Dec 2014 02:10:48 +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 1Y1n1j-0006A3-5Q
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 02:10:47 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	A8/4A-31453-62983945; Fri, 19 Dec 2014 02:10:46 +0000
X-Env-Sender: yanghy@cn.fujitsu.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1418955043!14249037!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2474 invoked from network); 19 Dec 2014 02:10:45 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-4.tower-206.messagelabs.com with SMTP;
	19 Dec 2014 02:10:45 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="45475658"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 19 Dec 2014 10:07:22 +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 sBJ2AGUM026918;
	Fri, 19 Dec 2014 10:10:16 +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; Fri, 19 Dec 2014 10:10:42 +0800
Message-ID: <549388F6.9000108@cn.fujitsu.com>
Date: Fri, 19 Dec 2014 10:09:58 +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: Anthony Korzan <akorzan@gmail.com>, <xen-devel@lists.xen.org>
References: <788CC804-7FC8-40C4-B17B-E02CDB7F2683@gmail.com>
In-Reply-To: <788CC804-7FC8-40C4-B17B-E02CDB7F2683@gmail.com>
X-Originating-IP: [10.167.226.223]
Cc: rshriram@cs.ubc.ca
Subject: Re: [Xen-devel] [Xen 4.5-rc] remus-drbd incompatible with Linux
	3.6+ 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: 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

SGksCgrlnKggMTIvMTkvMjAxNCAwNTo0OCBBTSwgQW50aG9ueSBLb3J6YW4g5YaZ6YGTOgo+IEhl
bGxvIQo+Cj4gSSBoYXZlIG9ubHkgbWFuYWdlZCB0byBnZXQgWGVuIDQuNSdzIFJlbXVzICJ3b3Jr
aW5nIiBvbiBMaW51eCBLZXJuZWxzIGxlc3MgdGhhbgo+IDMuNS4gVGhlIHByb3ZpZGVkIHJlbXVz
LWRyYmQsIGFzIGRldGFpbGVkIGluIGRvY3MvUkVBRE1FLnJlbXVzIGFuZCBhdmFpbGFibGUKPiBm
cm9tIGh0dHBzOi8vZ2l0aHViLmNvbS9yc2hyaXJhbS9yZW11cy1kcmJkIHdpbGwgbm90IGNvbXBp
bGUgd2l0aCBMaW51eCBLZXJuZWxzCj4gMy42IGFuZCBhYm92ZS4KClRoZSBEUkJEIHlvdSBnZXQg
ZnJvbSBodHRwczovL2dpdGh1Yi5jb20vcnNocmlyYW0vcmVtdXMtZHJiZCBpcyBEUkJEIDguMy4x
MQphbmQgdGhpcyB2ZXJzaW9uIG9ubHkgY29tcGF0aWJsZSB3aXRoIExpbnV4IDMuMH4zLjQsIHNl
ZSB0aGUgdGFibGUgb24gdGhpcyBwYWdlOgpodHRwOi8vd3d3LmRyYmQub3JnL2Rvd25sb2FkL21h
aW5saW5lLwoKSSdtIGFmcmFpZCBEUkJEIDguMy4xMSBpcyB0aGUgb25seSB2ZXJzaW9uIHRoYXQg
eW91IGNhbiBnZXQgUmVtdXMgd29yayBvbgpjdXJyZW50bHkuIEluIHRoZSBwYXN0LCBSZW11cyBk
aXNrIHJlcGxpY2F0aW9uIGJhc2VkIG9uIGJsa3RhcDIsIGJ1dCBibGt0YXAyCmlzIGdldHRpbmcg
ZGVwcmVjYXRlZCBJIHRoaW5rLCB0aGVyZSdzIG5vIG1haW50YWluZXJzIG5vciBwYXRjaGVzIHJl
Y2VudCB5ZWFycy4KCklmIHlvdSBhcmUgaW50ZXJlc3QsIHRoZXJlJ3MgYSBuZXcgRlQgc29sdXRp
b24gYmFzZWQgb24gUmVtdXM6Cmh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9DT0xPXy1fQ29hcnNl
X0dyYWluX0xvY2tfU3RlcHBpbmcKClRoaXMgc29sdXRpb24gdXNlIGJsa3RhcDIgYXMgZGlzayBy
ZXBsaWNhdGlvbiwgYW5kIGl0IGhhcyBsb3RzIG9mIHBhdGNoZXMgdG8KZ2V0IGJsa3RhcDIgd29y
ayB3aXRoIHhsLgoKRnV0aGVybW9yZSwgd2UgYXJlIHdvcmtpbmcgb24gYSBiZXR0ZXIgc29sdXRp
b24gb24gZGlzayByZXBsaWNhdGlvbiBvbiBib3RoClJlbXVzL0NPTE8uIENPTE8gaXMgc3VwcG9z
ZWQgdG8gZ2V0IGludG8gWGVuIDQuNi4KCj4KPiBPbmUgb2YgdGhlc2UgZXJyb3JzIGlzIHRoYXQg
cmVtdXMtZHJiZCB1c2VzIGEgdHdvIGFyZ3VtZW50IHZlcnNpb24gb2YgdGhlIG1hY3JvCj4ga3Vu
bWFwX2F0b21pYyBmb3VuZCBpbiBpbmNsdWRlL2xpbnV4L2hpZ2htZW0uaAo+IFRoaXMgd2FzIGRl
cHJlY2F0ZWQgYW5kIGlzIG5vIGxvbmdlciBpbmNsdWRlZCBpbiBhbnkgS2VybmVscyBhYm92ZSAz
LjYuCj4KPiAiZXJyb3I6IG1hY3JvICJrdW5tYXBfYXRvbWljIiBwYXNzZWQgMiBhcmd1bWVudHMs
IGJ1dCB0YWtlcyBqdXN0IDEiCj4KPiBJcyB0aGVyZSBhIHBhdGNoIGF2YWlsYWJsZT8gIElmIG5v
dCwgd2hhdCBzZXQgdXAgZG8gdGhlIFJlbXVzIGRldnMgdXNlIHRvIHRlc3Q/Cj4gICBJIGp1c3Qg
bmVlZCBhICJzdGFibGUtaXNoIiBwbGF0Zm9ybSB0byBtb2RpZnkgcmVtdXMgb24uCj4KPgo+IE5v
dyBJIGRpZCBnZXQgUmVtdXMgIndvcmtpbmciIG9uIExpbnV4IDMuNCwgVWJ1bnR1IDE0LjA0LCBh
bmQgdGhlIGN1c3RvbQo+IHJlbXVzLWRyYmQuICBUaGUgaXNzdWUgSSBydW4gaW50byBpcyB0aGF0
IFJlbXVzIG9ubHkgcGx1Z3MgYW5kIHVucGx1Z3MgYSBmZXcKPiBodW5kcmVkIHRpbWVzIHVudGls
IHRoZXJlIGlzIGEgIkNvbm5lY3Rpb24gdGltZW91dCBlcnJvci4iICBJdCBjb3VsZCBiZSB0aGF0
IEkKPiBhbSB1c2luZyBhbiAib2xkIiBsaW51eCBrZXJuZWwgdmVyc2lvbiB3aXRob3V0IG11Y2gg
WGVuIGludGVncmF0aW9uLCBidXQgSSdtCj4gc3R1bXBlZCBhYm91dCB0aGlzIGVycm9yOgoKQ2Fu
IHlvdSB0cnkgdG8gdXNlIExpbnV4IDMuMCB0byBzZWUgaWYgdGhlIGVycm9yIHN0aWxsIGV4aXN0
cz8KSSB3aWxsIHRha2UgYSBsb29rIG9uIHRoaXMgcHJvYmxlbSB0byBzZWUgaWYgSSBjYW4gcmVw
cm9kdWNlIGl0LgoKPgo+ICMjIwo+IC4uLgo+IHhjOiBwcm9ncmVzczogUmVsb2FkaW5nIG1lbW9y
eSBwYWdlczogODk1MDE1LzY1NTM2ICAxMzY1JQo+IHhjOiBTYXZpbmcgbWVtb3J5OiBpdGVyIDE0
MTYgKGxhc3Qgc2VudCA1Njggc2tpcHBlZCAwKTogNjU1MzYvNjU1MzYgIDEwMCUKPiAuLi4KPiB4
YzogU2F2aW5nIG1lbW9yeTogaXRlciAxNDIwIChsYXN0IHNlbnQgNTY3IHNraXBwZWQgMCk6IDY1
NTM2LzY1NTM2ICAxMDAlCj4geGM6IGVycm9yOiByZGV4YWN0IGZhaWxlZCAoc2VsZWN0IHJldHVy
bmVkIDApOiBJbnRlcm5hbCBlcnJvcgo+IHhjOiBlcnJvcjogRXJyb3Igd2hlbiByZWFkaW5nIGJh
dGNoIHNpemUgKDExMCA9IENvbm5lY3Rpb24gdGltZWQgb3V0KTogSW50ZXJuYWwKPiBlcnJvcgo+
IHhjOiBlcnJvcjogZXJyb3Igd2hlbiBidWZmZXJpbmcgYmF0Y2gsIGZpbmlzaGluZyAoMTEwID0g
Q29ubmVjdGlvbiB0aW1lZCBvdXQpOgo+IEludGVybmFsIGVycm9yCj4gbWlncmF0aW9uIHRhcmdl
dDogUmVtdXMgRmFpbG92ZXIgZm9yIGRvbWFpbiA1Cj4gbGlieGw6IGVycm9yOiBsaWJ4bF91dGls
cy5jOjQzMDpsaWJ4bF9yZWFkX2V4YWN0bHk6IGZpbGUvc3RyZWFtIHRydW5jYXRlZAo+IHJlYWRp
bmcgaXBjIG1zZyBoZWFkZXIgZnJvbSBkb21haW4gNSBzYXZlL3Jlc3RvcmUgaGVscGVyIHN0ZG91
dCBwaXBlCj4gbGlieGw6IGVycm9yOiBsaWJ4bF9leGVjLmM6MTI5OmxpYnhsX3JlcG9ydF9jaGls
ZF9leGl0c3RhdHVzOiBkb21haW4gNQo+IHNhdmUvcmVzdG9yZSBoZWxwZXIgWy0xXSBkaWVkIGR1
ZSB0byBmYXRhbCBzaWduYWwgQnJva2VuIHBpcGUKPiBsaWJ4bDogd2FybmluZzogbGlieGxfZG9t
LmM6MjAxNTpkb21haW5fc3VzcGVuZF9kb25lOiBSZW11czogRG9tYWluIHN1c3BlbmQKPiB0ZXJt
aW5hdGVkIHdpdGggcmMgLTMsIHRlYXJkb3duIFJlbXVzIGRldmljZXMuLi4KPiBSZW11czogQmFj
a3VwIGZhaWxlZD8gcmVzdW1pbmcgZG9tYWluIGF0IHByaW1hcnkuCj4geGM6IGVycm9yOiBEb20g
NSBub3Qgc3VzcGVuZGVkOiAoc2h1dGRvd24gMCwgcmVhc29uIDI1NSk6IEludGVybmFsIGVycm9y
Cj4gbGlieGw6IGVycm9yOiBsaWJ4bC5jOjUwNTpsaWJ4bF9fZG9tYWluX3Jlc3VtZTogeGNfZG9t
YWluX3Jlc3VtZSBmYWlsZWQgZm9yCj4gZG9tYWluIDU6IEludmFsaWQgYXJndW1lbnQKPiAjIyMK
Pgo+IFNpbmNlcmVseSwKPiBBbnRob255CgotLSAKVGhhbmtzLApZYW5nLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Dec 19 02:47:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 02:47:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1nak-0007Xd-MQ; Fri, 19 Dec 2014 02:46:58 +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 1Y1naj-0007XY-9h
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 02:46:57 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	48/F2-02707-0A193945; Fri, 19 Dec 2014 02:46:56 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418957214!8938022!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.5 required=7.0 tests=SUBJECT_DRUG_GAP_P
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14394 invoked from network); 19 Dec 2014 02:46:55 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2014 02:46:55 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 19:46:53 -0700
Message-Id: <5494021602000066000869A2@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 19:46:46 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-2-git-send-email-cyliu@suse.com>
	<1418915119.11882.79.camel@citrix.com>
In-Reply-To: <1418915119.11882.79.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 1/4] domain snapshot terms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/18/2014 at 11:05 PM, in message <1418915119.11882.79.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * add a document for domain snapshot related terms, they will be 
> >     referred in later documents. 
> >  
> > ===================================================================== 
> > Terms 
> >  
> > * Active domain: domain created and started 
> >  
> > * Inactive domain: domain created but not started 
>  
> As Wei says I think you mean "defined" here, since created and started 
> are (essentially) synonyms for some toolstacks. 
>  
> You'll probably want to define "defined" too for clarity. 

OK. I'll update.

>  
> >  
> > * 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. 
> >  
> >   Contents of disks (whether a subset or all disks associated with 
> >   the domain) are saved at a given point of time, and can be restored 
> >   back to that state. On a running guest, a disk-only snapshot is 
> >   likely to be only crash-consistent rather than clean (that is, it 
> >   represents the state of the disk on a sudden power outage); on an 
> >   inactive guest, a disk-only snapshot is clean if the disks were 
> >   clean when the guest was last shut down. 
>  
> There is the possibility of doing clean snapshots if a guest agent is 
> involved to quiesce the disks at the right moment (e.g. I believe qemu 
> has such a thing, or at least I've seen talks about it being developed 
> at conferences).

Right. Qemu has it. Libvirt qemu driver supports that. 

> Are you including this possibility or explicitly ruling 
> it out of scope? 

Just libxl has no mechanism to quiesce the disks even when domain
is paused, I didn't mention this scenario. I can add it.

Chunyan

> 
> > * Live Snapshot: 
> >  
> >   Like live migration, it will increase size of the memory dump file, 
> >   but reducess downtime of the guest. 
> >  
> > * Internal Disk Snapshot 
> >  
> >   File formats such as qcow2 track both the snapshot and changes 
> >   since the snapshot in a single file. 
> >  
> > * External Disk Snapshot 
> >  
> >   The snapshot is one file, and the changes since the snapshot 
> >   are in another file. 
>  
>  
>  
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 02:47:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 02:47:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1nak-0007Xd-MQ; Fri, 19 Dec 2014 02:46:58 +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 1Y1naj-0007XY-9h
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 02:46:57 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	48/F2-02707-0A193945; Fri, 19 Dec 2014 02:46:56 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418957214!8938022!1
X-Originating-IP: [137.65.250.214]
X-SpamReason: No, hits=0.5 required=7.0 tests=SUBJECT_DRUG_GAP_P
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14394 invoked from network); 19 Dec 2014 02:46:55 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2014 02:46:55 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 19:46:53 -0700
Message-Id: <5494021602000066000869A2@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 19:46:46 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-2-git-send-email-cyliu@suse.com>
	<1418915119.11882.79.camel@citrix.com>
In-Reply-To: <1418915119.11882.79.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 1/4] domain snapshot terms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/18/2014 at 11:05 PM, in message <1418915119.11882.79.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * add a document for domain snapshot related terms, they will be 
> >     referred in later documents. 
> >  
> > ===================================================================== 
> > Terms 
> >  
> > * Active domain: domain created and started 
> >  
> > * Inactive domain: domain created but not started 
>  
> As Wei says I think you mean "defined" here, since created and started 
> are (essentially) synonyms for some toolstacks. 
>  
> You'll probably want to define "defined" too for clarity. 

OK. I'll update.

>  
> >  
> > * 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. 
> >  
> >   Contents of disks (whether a subset or all disks associated with 
> >   the domain) are saved at a given point of time, and can be restored 
> >   back to that state. On a running guest, a disk-only snapshot is 
> >   likely to be only crash-consistent rather than clean (that is, it 
> >   represents the state of the disk on a sudden power outage); on an 
> >   inactive guest, a disk-only snapshot is clean if the disks were 
> >   clean when the guest was last shut down. 
>  
> There is the possibility of doing clean snapshots if a guest agent is 
> involved to quiesce the disks at the right moment (e.g. I believe qemu 
> has such a thing, or at least I've seen talks about it being developed 
> at conferences).

Right. Qemu has it. Libvirt qemu driver supports that. 

> Are you including this possibility or explicitly ruling 
> it out of scope? 

Just libxl has no mechanism to quiesce the disks even when domain
is paused, I didn't mention this scenario. I can add it.

Chunyan

> 
> > * Live Snapshot: 
> >  
> >   Like live migration, it will increase size of the memory dump file, 
> >   but reducess downtime of the guest. 
> >  
> > * Internal Disk Snapshot 
> >  
> >   File formats such as qcow2 track both the snapshot and changes 
> >   since the snapshot in a single file. 
> >  
> > * External Disk Snapshot 
> >  
> >   The snapshot is one file, and the changes since the snapshot 
> >   are in another file. 
>  
>  
>  
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 05:19:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 05:19:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1pxc-00046I-Ad; Fri, 19 Dec 2014 05:18:44 +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 1Y1pxa-00046B-CV
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 05:18:42 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	AD/4D-25727-135B3945; Fri, 19 Dec 2014 05:18:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418966319!14531899!1
X-Originating-IP: [66.165.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 24604 invoked from network); 19 Dec 2014 05:18: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;
	19 Dec 2014 05:18:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,604,1413244800"; d="scan'208";a="206603415"
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.210.2; Fri, 19 Dec 2014 00:18: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 1Y1pxV-0001VM-D1;
	Fri, 19 Dec 2014 05:18:37 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1pxV-0001Fq-4s;
	Fri, 19 Dec 2014 05:18:37 +0000
Date: Fri, 19 Dec 2014 05:18:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32445-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] 32445: 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 32445 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32445/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 26303
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 26303
 test-amd64-amd64-pair        4 host-install/dst_host(4) 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-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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-winxpsp3 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-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-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                        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?p=osstest.git;a=summary

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 34929 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 Dec 19 05:19:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 05:19:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1pxc-00046I-Ad; Fri, 19 Dec 2014 05:18:44 +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 1Y1pxa-00046B-CV
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 05:18:42 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	AD/4D-25727-135B3945; Fri, 19 Dec 2014 05:18:41 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418966319!14531899!1
X-Originating-IP: [66.165.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 24604 invoked from network); 19 Dec 2014 05:18: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;
	19 Dec 2014 05:18:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,604,1413244800"; d="scan'208";a="206603415"
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.210.2; Fri, 19 Dec 2014 00:18: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 1Y1pxV-0001VM-D1;
	Fri, 19 Dec 2014 05:18:37 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1pxV-0001Fq-4s;
	Fri, 19 Dec 2014 05:18:37 +0000
Date: Fri, 19 Dec 2014 05:18:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32445-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] 32445: 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 32445 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32445/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 26303
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 26303
 test-amd64-amd64-pair        4 host-install/dst_host(4) 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-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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-winxpsp3 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-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-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                        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?p=osstest.git;a=summary

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 34929 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 Dec 19 05:45:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 05:45:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1qNe-0005AB-3N; Fri, 19 Dec 2014 05:45:38 +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 1Y1qNc-0005A6-NP
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 05:45:36 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	16/92-11581-08BB3945; Fri, 19 Dec 2014 05:45:36 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418967933!8949465!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 21779 invoked from network); 19 Dec 2014 05:45:34 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2014 05:45:34 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 22:45:32 -0700
Message-Id: <54942BF20200006600086A4B@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 22:45:22 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
	<1418915443.11882.86.camel@citrix.com>
In-Reply-To: <1418915443.11882.86.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/18/2014 at 11:10 PM, in message <1418915443.11882.86.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * add an overview document, so that one can has a overall look 
> >     about the whole domain snapshot work, limits, requirements, 
> >     how to do, etc. 
> >  
> > ===================================================================== 
> > Domain snapshot overview 
>  
> I don't see a similar section for disk snapshots, are you not 
> considering those here except as a part of a domain snapshot or is this 
> an oversight? 
>  
> There are three main use cases (that I know of at least) for 
> snapshotting like behaviour. 
>  
> One is as you've mentioned below for "backup", i.e. to preserve the VM 
> at a certain point in time in order to be able to roll back to it. Is 
> this the only usecase you are considering? 

Yes. I didn't take disk snapshot thing into the scope.

>  
> A second use case is to support "gold image" type deployments, i.e. 
> where you create one baseline single disk image and then clone it 
> multiple times to deploy lots of guests. I think this is usually a "disk 
> snapshot" type thing, but maybe it can be implemented as restoring a 
> gold domain snapshot multiple times (e.g. for start of day performance 
> reasons). 

As we initially discussed about the thing, disk snapshot thing can be done
be existing tools directly like qemu-img, vhd-util.

>  
> The third case, (which is similar to the first), is taking a disk 
> snapshot in order to be able to run you usual backup software on the 
> snapshot (which is now unchanging, which is handy) and then deleting the 
> disk snapshot (this differs from the first case in which disk is active 
> after the snapshot, and due to the lack of the memory part). 

Sorry, I'm still not quite clear about what this user case wants to do.

>  
> Are you considering all three use cases here or are you explicitly 
> ruling out anything but the first? I think there might be some subtle 
> differences in the requirements, wrt which operations need to consider 
> the possibility of an active domain etc, depending on which cases are 
> considered. It would be good to be explicit about the use cases you are 
> not trying to address here so we are all on the same page. 
>  
> If you are ruling these other usecases out then I think it would be 
> useful to briefly describe them and then note that they are out of scope 
> for this design, so that we have an agreed understanding of what is in 
> or out of scope and/or can debate to what extent such use cases ought to 
> be considered in the design if not the implementation.

OK. I'll add this.

>  
> > 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 usually includes: 
> > a) create a domain snapshot 
> > b) roll back (or called "revert") to a domain snapshot 
> > c) delete a domain snapshot 
> > d) list all domain snapshots 
> >  
> > But following the existing xl idioms of managing storage and saved 
> > VM images via existing CLI command (qemu-img, lvcreate, ls, mv, 
> > cp etc), xl snapshot functionality would be kept as simple as 
> > possible: 
> > * xl will do a) and b), creating a snapshot and reverting a 
> >   domain to a snapshot. 
> > * xl will NOT do c) and d), xl won't manage snapshots, as xl 
> >   doesn't maintain saved images created by 'xl save'. So xl 
> >   will have no idea of the existence of domain snapshots and 
> >   the chain relationship between snapshots. It will depends on 
> >   user to take care of the snapshots, know the snapshot chain 
> >   info, and delete snapshots. 
>  
> This is a case where the usecases being considered might apply. If the 
> third case I outlined above is in scope then xl may need to somehow 
> support deleting a snapshot from under the feet of an active domain etc 
> (which need not necessarily imply knowledge of snapshot chains or 
> snapshot management, but might involve a notification to the backend for 
> example). 
>  
> > Domain Snapshot Support and Not Support: 
> > * support live snapshot 
> > * support internal disk snapshot and external disk snapshot 
> > * support different disk backend types. 
> >   (Basic goal is to support 'raw' and 'qcow2' only). 
> >  
> > * not support snapshot when domain is shutdowning or dying. 
> > * not support disk-only snapshot [1]. 
> >  
> >  [1] 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. 
> >  
> >  
> > 2. Requirements 
> >  
> > General Requirements: 
> > * ability to save/restore domain memory 
> > * ability to create/delete/apply disk snapshot [2] 
>  
> Is "apply" the same as "revert to"? Worth adding to the terminology 
> section and using consistently.

Yes. In qemu-img terms, it's 'apply'. In libvirt qemu driver domain snapshot
terms, it's 'revert'. I'll add to the terminology section.

>  
> > * ability to parse user config file 
> >  
> >   [2] Disk snapshot requirements: 
> >   - external tools: qemu-img, lvcreate, vhd-util, etc. 
> >   - for basic goal, we support 'raw' and 'qcow2' backend types 
> >     only. Then it requires: 
> >     libxl qmp command or "qemu-img" (when qemu process does not 
> >     exist) 
> >  
> >  
> > 3. Interaction with other operations: 
> >  
> > No. 
>  
> What about shutdown/dying as you noted above? What about migration or 
> regular save/restore? 

Since xl now has no idea of the existence of snapshot, so when writing this
document I turned to depends on users to delete snapshots before or after
deleting a domain (like shutdown, destroy, save, migrate away). User should
know where memory is saved, and disk snapshot related info.

Chunyan

>  
> >  
> > 4. General workflow 
> >  
> > Create a snapshot: 
> >   * parse user cfg file if passed in 
> >   * check snapshot operation is allowed or not 
> >   * save domain, saving memory status to file (refer to: save_domain) 
> >   * take disk snapshot (e.g. call qmp command) 
> >   * unpause domain 
> >  
> > Revert to snapshot: 
> >   * parse use cfg file (xl doesn't manage snapshots, so it has no 
> >     idea of snapshot existence. User MUST supply configuration file) 
> >   * destroy this domain 
> >   * create a new domain from snapshot info 
> >     - apply disk snapshot (e.g. call qemu-img) 
> >     - a process like restore domain 
>  
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 05:45:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 05:45:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1qNe-0005AB-3N; Fri, 19 Dec 2014 05:45:38 +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 1Y1qNc-0005A6-NP
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 05:45:36 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	16/92-11581-08BB3945; Fri, 19 Dec 2014 05:45:36 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1418967933!8949465!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 21779 invoked from network); 19 Dec 2014 05:45:34 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2014 05:45:34 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 22:45:32 -0700
Message-Id: <54942BF20200006600086A4B@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 22:45:22 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
	<1418915443.11882.86.camel@citrix.com>
In-Reply-To: <1418915443.11882.86.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/18/2014 at 11:10 PM, in message <1418915443.11882.86.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * add an overview document, so that one can has a overall look 
> >     about the whole domain snapshot work, limits, requirements, 
> >     how to do, etc. 
> >  
> > ===================================================================== 
> > Domain snapshot overview 
>  
> I don't see a similar section for disk snapshots, are you not 
> considering those here except as a part of a domain snapshot or is this 
> an oversight? 
>  
> There are three main use cases (that I know of at least) for 
> snapshotting like behaviour. 
>  
> One is as you've mentioned below for "backup", i.e. to preserve the VM 
> at a certain point in time in order to be able to roll back to it. Is 
> this the only usecase you are considering? 

Yes. I didn't take disk snapshot thing into the scope.

>  
> A second use case is to support "gold image" type deployments, i.e. 
> where you create one baseline single disk image and then clone it 
> multiple times to deploy lots of guests. I think this is usually a "disk 
> snapshot" type thing, but maybe it can be implemented as restoring a 
> gold domain snapshot multiple times (e.g. for start of day performance 
> reasons). 

As we initially discussed about the thing, disk snapshot thing can be done
be existing tools directly like qemu-img, vhd-util.

>  
> The third case, (which is similar to the first), is taking a disk 
> snapshot in order to be able to run you usual backup software on the 
> snapshot (which is now unchanging, which is handy) and then deleting the 
> disk snapshot (this differs from the first case in which disk is active 
> after the snapshot, and due to the lack of the memory part). 

Sorry, I'm still not quite clear about what this user case wants to do.

>  
> Are you considering all three use cases here or are you explicitly 
> ruling out anything but the first? I think there might be some subtle 
> differences in the requirements, wrt which operations need to consider 
> the possibility of an active domain etc, depending on which cases are 
> considered. It would be good to be explicit about the use cases you are 
> not trying to address here so we are all on the same page. 
>  
> If you are ruling these other usecases out then I think it would be 
> useful to briefly describe them and then note that they are out of scope 
> for this design, so that we have an agreed understanding of what is in 
> or out of scope and/or can debate to what extent such use cases ought to 
> be considered in the design if not the implementation.

OK. I'll add this.

>  
> > 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 usually includes: 
> > a) create a domain snapshot 
> > b) roll back (or called "revert") to a domain snapshot 
> > c) delete a domain snapshot 
> > d) list all domain snapshots 
> >  
> > But following the existing xl idioms of managing storage and saved 
> > VM images via existing CLI command (qemu-img, lvcreate, ls, mv, 
> > cp etc), xl snapshot functionality would be kept as simple as 
> > possible: 
> > * xl will do a) and b), creating a snapshot and reverting a 
> >   domain to a snapshot. 
> > * xl will NOT do c) and d), xl won't manage snapshots, as xl 
> >   doesn't maintain saved images created by 'xl save'. So xl 
> >   will have no idea of the existence of domain snapshots and 
> >   the chain relationship between snapshots. It will depends on 
> >   user to take care of the snapshots, know the snapshot chain 
> >   info, and delete snapshots. 
>  
> This is a case where the usecases being considered might apply. If the 
> third case I outlined above is in scope then xl may need to somehow 
> support deleting a snapshot from under the feet of an active domain etc 
> (which need not necessarily imply knowledge of snapshot chains or 
> snapshot management, but might involve a notification to the backend for 
> example). 
>  
> > Domain Snapshot Support and Not Support: 
> > * support live snapshot 
> > * support internal disk snapshot and external disk snapshot 
> > * support different disk backend types. 
> >   (Basic goal is to support 'raw' and 'qcow2' only). 
> >  
> > * not support snapshot when domain is shutdowning or dying. 
> > * not support disk-only snapshot [1]. 
> >  
> >  [1] 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. 
> >  
> >  
> > 2. Requirements 
> >  
> > General Requirements: 
> > * ability to save/restore domain memory 
> > * ability to create/delete/apply disk snapshot [2] 
>  
> Is "apply" the same as "revert to"? Worth adding to the terminology 
> section and using consistently.

Yes. In qemu-img terms, it's 'apply'. In libvirt qemu driver domain snapshot
terms, it's 'revert'. I'll add to the terminology section.

>  
> > * ability to parse user config file 
> >  
> >   [2] Disk snapshot requirements: 
> >   - external tools: qemu-img, lvcreate, vhd-util, etc. 
> >   - for basic goal, we support 'raw' and 'qcow2' backend types 
> >     only. Then it requires: 
> >     libxl qmp command or "qemu-img" (when qemu process does not 
> >     exist) 
> >  
> >  
> > 3. Interaction with other operations: 
> >  
> > No. 
>  
> What about shutdown/dying as you noted above? What about migration or 
> regular save/restore? 

Since xl now has no idea of the existence of snapshot, so when writing this
document I turned to depends on users to delete snapshots before or after
deleting a domain (like shutdown, destroy, save, migrate away). User should
know where memory is saved, and disk snapshot related info.

Chunyan

>  
> >  
> > 4. General workflow 
> >  
> > Create a snapshot: 
> >   * parse user cfg file if passed in 
> >   * check snapshot operation is allowed or not 
> >   * save domain, saving memory status to file (refer to: save_domain) 
> >   * take disk snapshot (e.g. call qmp command) 
> >   * unpause domain 
> >  
> > Revert to snapshot: 
> >   * parse use cfg file (xl doesn't manage snapshots, so it has no 
> >     idea of snapshot existence. User MUST supply configuration file) 
> >   * destroy this domain 
> >   * create a new domain from snapshot info 
> >     - apply disk snapshot (e.g. call qemu-img) 
> >     - a process like restore domain 
>  
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 06:10:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 06:10:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ql2-0005zr-Bg; Fri, 19 Dec 2014 06:09: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 1Y1ql0-0005zm-KY
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 06:09:46 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	43/B3-11581-921C3945; Fri, 19 Dec 2014 06:09:45 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418969384!14232683!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16613 invoked from network); 19 Dec 2014 06:09:45 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-2.tower-206.messagelabs.com with SMTP;
	19 Dec 2014 06:09:45 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 18 Dec 2014 22:07:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="501375006"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by orsmga003.jf.intel.com with ESMTP; 18 Dec 2014 22:05:18 -0800
Date: Fri, 19 Dec 2014 14:09:39 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20141219060939.GD3105@pengc-linux.bj.intel.com>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141218164028.GB75015@deinos.phlegethon.org>
MIME-Version: 1.0
Content-Length: 3944
Content-Disposition: inline
In-Reply-To: <20141218164028.GB75015@deinos.phlegethon.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	will.auld@intel.com, JBeulich@suse.com, wei.liu2@citrix.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
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

T24gVGh1LCBEZWMgMTgsIDIwMTQgYXQgMDU6NDA6MjhQTSArMDEwMCwgVGltIERlZWdhbiB3cm90
ZToKPiBIaSwgCj4gCj4gVGhhbmtzIGZvciBwb3N0aW5nIHRoaXMgLSBpdCdzIHZlcnkgdXNlZnVs
LiAgSSBoYXZlIGEgY291cGxlIG9mCj4gcXVlc3Rpb25zIGFib3V0IHRoZSBpbnRlcmZhY2UgZGVz
aWduLiAKVGhhbmtzIFRpbS4KPiAKPiBBdCAyMDoyNyArMDgwMCBvbiAxMiBEZWMgKDE0MTg0MTI0
NzcpLCBDaGFvIFBlbmcgd3JvdGU6Cj4gPiBEZXNpZ24gT3ZlcnZpZXcKPiA+IFdoZW4gZW5mb3Jj
aW5nIGNhY2hlIGFsbG9jYXRpb24gZm9yIFZNcywgdGhlIG1pbmltdW0gZ3JhbnVsYXJpdHkgaXMK
PiA+IGRlZmluZWQgYXMgdGhlIGRvbWFpbi4gQWxsIFZpcnR1YWwgQ1BVcyAoIlZDUFVzIikgb2Yg
YSBkb21haW4gaGF2ZSB0aGUKPiA+IHNhbWUgQ09TLCBhbmQgdGhlcmVmb3JlLCBjb3JyZXNwb25k
IHRvIHRoZSBzYW1lIENCTS4gQ09TIGlzIHVzZWQgb25seSBpbgo+ID4gaHlwZXJ2aXNvciBhbmQg
aXMgdHJhbnNwYXJlbnQgdG8gdG9vbCBzdGFjay91c2VyLiBTeXN0ZW0gYWRtaW5pc3RyYXRvcgo+
ID4gY2FuIHNwZWNpZnkgdGhlIGluaXRpYWwgQ0JNIGZvciBlYWNoIGRvbWFpbiBvciBjaGFuZ2Ug
aXQgYXQgcnVudGltZSB1c2luZyAKPiA+IHRvb2wgc3RhY2suIEh5cGVydmlzb3IgdGhlbiBjaG9z
ZXMgYSBmcmVlIENPUyB0byBhc3NvY2lhdGUgaXQgd2l0aCB0aGF0Cj4gPiBDQk0gb3IgZmluZCBh
IGV4aXN0ZWQgQ09TIHdoaWNoIGhhcyB0aGUgc2FtZSBDQk0uCj4gCj4gV2hhdCBoYXBwZW5zIGlm
IHRoZXJlIGlzIG5vIGV4aXN0aW5nIENPUyB0aGF0IG1hdGNoZXMsIGFuZCBhbGwgQ09TZXMKPiBh
cmUgaW4gdXNlPyAgRG9lcyBYZW4gcmV0dXJuIGFuIGVycm9yPyAgT3IgdHJ5IHRvIGNoYW5nZSBD
T1MtPkNNQgo+IG1hcHBpbmdzIGR1cmluZyBjb250ZXh0IHN3aXRjaGVzPwoKSW4gdGhlIGluaXRp
YWwgaW1wbGVtZW50YXRpb24sIGVycm9yIGlzIHJldHVybmVkLiBJdKGvcyBwb3NzaWJsZSBmb3IK
aHlwZXJ2aXNvciB0byBzaGFyZSBDT1MgZm9yIGRpZmZlcmVudCBDQk1lcyBhbmQgbm90IHRvIHJl
dHVybiBlcnJvcgpoZXJlLiBCdXQgdGhlIHByb2JsZW0gaXMgdGhhdCBDT1Mgc2hvcnRhZ2UgbWF5
IHN0aWxsIGhhcHBlbiBkdXJpbmcKY29udGV4dCBzd2l0Y2guIEF0IHRoYXQgdGltZSB3ZSB3aWxs
IGhhdmUgbm8gaWRlYSBmb3Igd2hhdCB0byBkby4gU28gSaGvZApwcmVmZXIgdG8gcmV0dXJuIGVy
cm9yIGRpcmVjdGx5IGhlcmUgYW5kIGxlYXZlIHRoZSBkZWNpc2lvbiB0byB1c2VyCnNwYWNlLCBl
LmcuIGlmIGVycm9yIGlzIHJldHVybmVkIHRoZW4gaXQgY2FuIGNsZWFyIENCTSBmb3Igc29tZSBk
b21haW4KYW5kIGdldCBmcmVlIENPUy4KPiAKPiA+IC0gVkNQVSBTY2hlZHVsZQo+ID4gV2hlbiBW
Q1BVIGlzIHNjaGVkdWxlZCBvbiB0aGUgcGh5c2ljYWwgQ1BVICgiUENQVSIpLCBpdHMgQ09TIHZh
bHVlIGlzCj4gPiB0aGVuIHdyaXR0ZW4gdG8gTVNSIChJQTMyX1BRUl9BU1NPQykgb2YgUENQVSB0
byBub3RpZnkgaGFyZHdhcmUgdG8gdXNlIAo+ID4gdGhlIG5ldyBDT1MuIFRoZSBjYWNoZSBhbGxv
Y2F0aW9uIGlzIHRoZW4gZW5mb3JjZWQgYnkgaGFyZHdhcmUuCj4gPiAKPiA+IC0gTXVsdGktU29j
a2V0Cj4gPiBJbiBtdWx0aS1zb2NrZXQgZW52aXJvbm1lbnQsIGVhY2ggVkNQVSBtYXkgYmUgc2No
ZWR1bGVkIG9uIGRpZmZlcmVudAo+ID4gc29ja2V0cy4gVGhlIGhhcmR3YXJlIENBVCBhYmlsaXR5
KHN1Y2ggYXMgbWF4aW11bSBzdXBwb3J0ZWQgQ09TIGFuZCBsZW5ndGgKPiA+IG9mIENCTSkgbWF5
YmUgZGlmZmVyZW50IGFtb25nIHNvY2tldHMuIEZvciBzdWNoIHN5c3RlbSwgcGVyLXNvY2tldCBD
T1MvQ0JNCj4gPiBjb25maWd1cmF0aW9uIG9mIGEgZG9tYWluIGlzIHNwZWNpZmllZC4gSHlwZXJ2
aXNvciB0aGVuIHVzZSB0aGlzIHBlci1zb2NrZXQKPiA+IENCTSBpbmZvcm1hdGlvbiBmb3IgVkNQ
VSBzY2hlZHVsZS4KPiAKPiBJcyBpdCBPSyB0byBhc3N1bWUgdGhhdCBpbiB0aGUgY29tbW9uIGNh
c2UgYWxsIENQVXMgaGF2ZSB0aGUgc2FtZSBDQVQKPiBjYXBhYmlsaXRpZXM/ICBUaGVuIFhlbiBj
YW4ganVzdCByZXBvcnQgdGhlIHNtYWxsZXN0IHNldCBvZgo+IGNhcGFiaWxpdGllcyBvZiBhbnkg
c29ja2V0IGluIHRoZSBzeXN0ZW0sIGFuZCB0aGUgdG9vbHN0YWNrIGRvZXNuJ3QKPiBoYXZlIHRv
IG1lc3MgYWJvdXQgd2l0aCBwZXItc29ja2V0IHNldHRpbmdzLgo+IAo+IEkgZ3Vlc3MgeW91IGNh
biBhZGQgdGhhdCBzeW50YWN0aWMgc3VnYXIgb24gdGhlIHRvb2xzIGlmIHlvdSB3YW50IGFuZAo+
IGxlYXZlIHRoZSBtb3JlIHBvd2VyZnVsIGh5cGVjYWxsIGludGVyZmFjZSBpbiBjYXNlIGl0J3Mg
dXNlZnVsLiA6KQoKQWdyZWVkLCB0aGlzIGlzIHdoYXQgSSB3YW50IHRvIGRvLiBCYXNpY2FsbHkg
dGhlIHNvY2tldElkIGlzIG9wdGlvbmFsCmZvciB0aGUgY2FsbGVyLiBJZiBtb3JlIHRoYW4gb25l
IHNvY2tldCBleGlzdHMsIG9taXR0aW5nIHNvY2tldElkIG1lYW5zCnRoZSBzcGVjaWZpZWQgQ0JN
IGFwcGxpZWQgdG8gYWxsIHNvY2tldHMuIFdoaWxlIHdlIHN0aWxsIG1haW50YWluCnBlci1zb2Nr
ZXQgQ0JNIGluIGh5cGVydmlzb3IgaW50ZXJuYWxseSBhbmQgcHJvdmlkZSBwZXItc29ja2V0IGh5
cGVyY2FsbAppbnRlcmZhY2UgaW4gY2FzZSBpdKGvcyBuZWVkZWQuIEluIHRoaXMgd2F5IHRoZSBp
bnRlcmZhY2Ugc2hvdWxkIGJlIHVzZXIKZnJpZW5kbHkgZm9yIG1vc3QgY2FzZXMuCgpDaGFvCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Dec 19 06:10:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 06:10:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ql2-0005zr-Bg; Fri, 19 Dec 2014 06:09: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 1Y1ql0-0005zm-KY
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 06:09:46 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	43/B3-11581-921C3945; Fri, 19 Dec 2014 06:09:45 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418969384!14232683!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16613 invoked from network); 19 Dec 2014 06:09:45 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-2.tower-206.messagelabs.com with SMTP;
	19 Dec 2014 06:09:45 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 18 Dec 2014 22:07:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="501375006"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by orsmga003.jf.intel.com with ESMTP; 18 Dec 2014 22:05:18 -0800
Date: Fri, 19 Dec 2014 14:09:39 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20141219060939.GD3105@pengc-linux.bj.intel.com>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141218164028.GB75015@deinos.phlegethon.org>
MIME-Version: 1.0
Content-Length: 3944
Content-Disposition: inline
In-Reply-To: <20141218164028.GB75015@deinos.phlegethon.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	will.auld@intel.com, JBeulich@suse.com, wei.liu2@citrix.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
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

T24gVGh1LCBEZWMgMTgsIDIwMTQgYXQgMDU6NDA6MjhQTSArMDEwMCwgVGltIERlZWdhbiB3cm90
ZToKPiBIaSwgCj4gCj4gVGhhbmtzIGZvciBwb3N0aW5nIHRoaXMgLSBpdCdzIHZlcnkgdXNlZnVs
LiAgSSBoYXZlIGEgY291cGxlIG9mCj4gcXVlc3Rpb25zIGFib3V0IHRoZSBpbnRlcmZhY2UgZGVz
aWduLiAKVGhhbmtzIFRpbS4KPiAKPiBBdCAyMDoyNyArMDgwMCBvbiAxMiBEZWMgKDE0MTg0MTI0
NzcpLCBDaGFvIFBlbmcgd3JvdGU6Cj4gPiBEZXNpZ24gT3ZlcnZpZXcKPiA+IFdoZW4gZW5mb3Jj
aW5nIGNhY2hlIGFsbG9jYXRpb24gZm9yIFZNcywgdGhlIG1pbmltdW0gZ3JhbnVsYXJpdHkgaXMK
PiA+IGRlZmluZWQgYXMgdGhlIGRvbWFpbi4gQWxsIFZpcnR1YWwgQ1BVcyAoIlZDUFVzIikgb2Yg
YSBkb21haW4gaGF2ZSB0aGUKPiA+IHNhbWUgQ09TLCBhbmQgdGhlcmVmb3JlLCBjb3JyZXNwb25k
IHRvIHRoZSBzYW1lIENCTS4gQ09TIGlzIHVzZWQgb25seSBpbgo+ID4gaHlwZXJ2aXNvciBhbmQg
aXMgdHJhbnNwYXJlbnQgdG8gdG9vbCBzdGFjay91c2VyLiBTeXN0ZW0gYWRtaW5pc3RyYXRvcgo+
ID4gY2FuIHNwZWNpZnkgdGhlIGluaXRpYWwgQ0JNIGZvciBlYWNoIGRvbWFpbiBvciBjaGFuZ2Ug
aXQgYXQgcnVudGltZSB1c2luZyAKPiA+IHRvb2wgc3RhY2suIEh5cGVydmlzb3IgdGhlbiBjaG9z
ZXMgYSBmcmVlIENPUyB0byBhc3NvY2lhdGUgaXQgd2l0aCB0aGF0Cj4gPiBDQk0gb3IgZmluZCBh
IGV4aXN0ZWQgQ09TIHdoaWNoIGhhcyB0aGUgc2FtZSBDQk0uCj4gCj4gV2hhdCBoYXBwZW5zIGlm
IHRoZXJlIGlzIG5vIGV4aXN0aW5nIENPUyB0aGF0IG1hdGNoZXMsIGFuZCBhbGwgQ09TZXMKPiBh
cmUgaW4gdXNlPyAgRG9lcyBYZW4gcmV0dXJuIGFuIGVycm9yPyAgT3IgdHJ5IHRvIGNoYW5nZSBD
T1MtPkNNQgo+IG1hcHBpbmdzIGR1cmluZyBjb250ZXh0IHN3aXRjaGVzPwoKSW4gdGhlIGluaXRp
YWwgaW1wbGVtZW50YXRpb24sIGVycm9yIGlzIHJldHVybmVkLiBJdKGvcyBwb3NzaWJsZSBmb3IK
aHlwZXJ2aXNvciB0byBzaGFyZSBDT1MgZm9yIGRpZmZlcmVudCBDQk1lcyBhbmQgbm90IHRvIHJl
dHVybiBlcnJvcgpoZXJlLiBCdXQgdGhlIHByb2JsZW0gaXMgdGhhdCBDT1Mgc2hvcnRhZ2UgbWF5
IHN0aWxsIGhhcHBlbiBkdXJpbmcKY29udGV4dCBzd2l0Y2guIEF0IHRoYXQgdGltZSB3ZSB3aWxs
IGhhdmUgbm8gaWRlYSBmb3Igd2hhdCB0byBkby4gU28gSaGvZApwcmVmZXIgdG8gcmV0dXJuIGVy
cm9yIGRpcmVjdGx5IGhlcmUgYW5kIGxlYXZlIHRoZSBkZWNpc2lvbiB0byB1c2VyCnNwYWNlLCBl
LmcuIGlmIGVycm9yIGlzIHJldHVybmVkIHRoZW4gaXQgY2FuIGNsZWFyIENCTSBmb3Igc29tZSBk
b21haW4KYW5kIGdldCBmcmVlIENPUy4KPiAKPiA+IC0gVkNQVSBTY2hlZHVsZQo+ID4gV2hlbiBW
Q1BVIGlzIHNjaGVkdWxlZCBvbiB0aGUgcGh5c2ljYWwgQ1BVICgiUENQVSIpLCBpdHMgQ09TIHZh
bHVlIGlzCj4gPiB0aGVuIHdyaXR0ZW4gdG8gTVNSIChJQTMyX1BRUl9BU1NPQykgb2YgUENQVSB0
byBub3RpZnkgaGFyZHdhcmUgdG8gdXNlIAo+ID4gdGhlIG5ldyBDT1MuIFRoZSBjYWNoZSBhbGxv
Y2F0aW9uIGlzIHRoZW4gZW5mb3JjZWQgYnkgaGFyZHdhcmUuCj4gPiAKPiA+IC0gTXVsdGktU29j
a2V0Cj4gPiBJbiBtdWx0aS1zb2NrZXQgZW52aXJvbm1lbnQsIGVhY2ggVkNQVSBtYXkgYmUgc2No
ZWR1bGVkIG9uIGRpZmZlcmVudAo+ID4gc29ja2V0cy4gVGhlIGhhcmR3YXJlIENBVCBhYmlsaXR5
KHN1Y2ggYXMgbWF4aW11bSBzdXBwb3J0ZWQgQ09TIGFuZCBsZW5ndGgKPiA+IG9mIENCTSkgbWF5
YmUgZGlmZmVyZW50IGFtb25nIHNvY2tldHMuIEZvciBzdWNoIHN5c3RlbSwgcGVyLXNvY2tldCBD
T1MvQ0JNCj4gPiBjb25maWd1cmF0aW9uIG9mIGEgZG9tYWluIGlzIHNwZWNpZmllZC4gSHlwZXJ2
aXNvciB0aGVuIHVzZSB0aGlzIHBlci1zb2NrZXQKPiA+IENCTSBpbmZvcm1hdGlvbiBmb3IgVkNQ
VSBzY2hlZHVsZS4KPiAKPiBJcyBpdCBPSyB0byBhc3N1bWUgdGhhdCBpbiB0aGUgY29tbW9uIGNh
c2UgYWxsIENQVXMgaGF2ZSB0aGUgc2FtZSBDQVQKPiBjYXBhYmlsaXRpZXM/ICBUaGVuIFhlbiBj
YW4ganVzdCByZXBvcnQgdGhlIHNtYWxsZXN0IHNldCBvZgo+IGNhcGFiaWxpdGllcyBvZiBhbnkg
c29ja2V0IGluIHRoZSBzeXN0ZW0sIGFuZCB0aGUgdG9vbHN0YWNrIGRvZXNuJ3QKPiBoYXZlIHRv
IG1lc3MgYWJvdXQgd2l0aCBwZXItc29ja2V0IHNldHRpbmdzLgo+IAo+IEkgZ3Vlc3MgeW91IGNh
biBhZGQgdGhhdCBzeW50YWN0aWMgc3VnYXIgb24gdGhlIHRvb2xzIGlmIHlvdSB3YW50IGFuZAo+
IGxlYXZlIHRoZSBtb3JlIHBvd2VyZnVsIGh5cGVjYWxsIGludGVyZmFjZSBpbiBjYXNlIGl0J3Mg
dXNlZnVsLiA6KQoKQWdyZWVkLCB0aGlzIGlzIHdoYXQgSSB3YW50IHRvIGRvLiBCYXNpY2FsbHkg
dGhlIHNvY2tldElkIGlzIG9wdGlvbmFsCmZvciB0aGUgY2FsbGVyLiBJZiBtb3JlIHRoYW4gb25l
IHNvY2tldCBleGlzdHMsIG9taXR0aW5nIHNvY2tldElkIG1lYW5zCnRoZSBzcGVjaWZpZWQgQ0JN
IGFwcGxpZWQgdG8gYWxsIHNvY2tldHMuIFdoaWxlIHdlIHN0aWxsIG1haW50YWluCnBlci1zb2Nr
ZXQgQ0JNIGluIGh5cGVydmlzb3IgaW50ZXJuYWxseSBhbmQgcHJvdmlkZSBwZXItc29ja2V0IGh5
cGVyY2FsbAppbnRlcmZhY2UgaW4gY2FzZSBpdKGvcyBuZWVkZWQuIEluIHRoaXMgd2F5IHRoZSBp
bnRlcmZhY2Ugc2hvdWxkIGJlIHVzZXIKZnJpZW5kbHkgZm9yIG1vc3QgY2FzZXMuCgpDaGFvCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Dec 19 06:19:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 06:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1quH-0006QV-EC; Fri, 19 Dec 2014 06:19: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 1Y1quG-0006QQ-78
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 06:19:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3D/13-15461-763C3945; Fri, 19 Dec 2014 06:19:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418969957!16665670!1
X-Originating-IP: [66.165.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 29649 invoked from network); 19 Dec 2014 06:19:18 -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 Dec 2014 06:19:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,605,1413244800"; d="scan'208";a="206127932"
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.210.2; Fri, 19 Dec 2014 01:18: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 1Y1qtu-0001n8-AV;
	Fri, 19 Dec 2014 06:18:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1qtu-0004wa-2i;
	Fri, 19 Dec 2014 06:18:58 +0000
Date: Fri, 19 Dec 2014 06:18:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32471-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8301
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32471: 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="===============7496315057466579584=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7496315057466579584==
Content-Type: text/plain
Content-Length: 8029
Content-Transfer-Encoding: quoted-printable

flight 32471 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32471/

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              531aef2e1b2c5ca97bc2936c108a6fa20b60de93
baseline version:
 libvirt              b1802714dab51bd5f0214a4d93a2c0b635bc5f14

------------------------------------------------------------
People who touched revisions under test:
  Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
  Eric Blake <eblake@redhat.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Luyao Huang <lhuang@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=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3D531aef2e1b2c5ca97bc2936c108a6fa20b60de93
+ . 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 531aef2e1b2c5ca97bc2936c108a6fa20b60de93
+ branch=3Dlibvirt
+ revision=3D531aef2e1b2c5ca97bc2936c108a6fa20b60de93
+ . 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 531aef2e1b2c5ca97bc2936c108a6fa20b60de93:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   b180271..531aef2  531aef2e1b2c5ca97bc2936c108a6fa20b60de93 -> xen-tested-master


--===============7496315057466579584==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7496315057466579584==--

From xen-devel-bounces@lists.xen.org Fri Dec 19 06:19:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 06:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1quH-0006QV-EC; Fri, 19 Dec 2014 06:19: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 1Y1quG-0006QQ-78
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 06:19:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3D/13-15461-763C3945; Fri, 19 Dec 2014 06:19:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418969957!16665670!1
X-Originating-IP: [66.165.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 29649 invoked from network); 19 Dec 2014 06:19:18 -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 Dec 2014 06:19:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,605,1413244800"; d="scan'208";a="206127932"
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.210.2; Fri, 19 Dec 2014 01:18: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 1Y1qtu-0001n8-AV;
	Fri, 19 Dec 2014 06:18:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1qtu-0004wa-2i;
	Fri, 19 Dec 2014 06:18:58 +0000
Date: Fri, 19 Dec 2014 06:18:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32471-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8301
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32471: 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="===============7496315057466579584=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7496315057466579584==
Content-Type: text/plain
Content-Length: 8029
Content-Transfer-Encoding: quoted-printable

flight 32471 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32471/

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              531aef2e1b2c5ca97bc2936c108a6fa20b60de93
baseline version:
 libvirt              b1802714dab51bd5f0214a4d93a2c0b635bc5f14

------------------------------------------------------------
People who touched revisions under test:
  Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
  Eric Blake <eblake@redhat.com>
  John Ferlan <jferlan@redhat.com>
  J=C3=A1n Tomko <jtomko@redhat.com>
  Luyao Huang <lhuang@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=3Fp=3Dosstest.git;a=3Dsummary


Pushing revision :

+ branch=3Dlibvirt
+ revision=3D531aef2e1b2c5ca97bc2936c108a6fa20b60de93
+ . 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 531aef2e1b2c5ca97bc2936c108a6fa20b60de93
+ branch=3Dlibvirt
+ revision=3D531aef2e1b2c5ca97bc2936c108a6fa20b60de93
+ . 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 531aef2e1b2c5ca97bc2936c108a6fa20b60de93:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   b180271..531aef2  531aef2e1b2c5ca97bc2936c108a6fa20b60de93 -> xen-tested-master


--===============7496315057466579584==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7496315057466579584==--

From xen-devel-bounces@lists.xen.org Fri Dec 19 06:23:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 06: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 1Y1qyT-0006qV-49; Fri, 19 Dec 2014 06:23: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 1Y1qyS-0006qQ-9K
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 06:23:40 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	22/21-03148-B64C3945; Fri, 19 Dec 2014 06:23:39 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418970217!16087539!1
X-Originating-IP: [66.165.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 4413 invoked from network); 19 Dec 2014 06:23:38 -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 Dec 2014 06:23:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,605,1413244800"; d="scan'208";a="206128645"
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.210.2; Fri, 19 Dec 2014 01:23:36 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y1qyN-0001of-QB;
	Fri, 19 Dec 2014 06:23:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1qyN-00078J-Ja;
	Fri, 19 Dec 2014 06:23:35 +0000
Date: Fri, 19 Dec 2014 06:23:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32448-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] 32448: 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 32448 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32448/

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 32149

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-qemuu-winxpsp3 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-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-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-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                83a926f7a4e39fb6be0576024e67fe161593defa
baseline version:
 linux                356a3e1fde11190febb8ace3cdab8694848ed220

------------------------------------------------------------
People who touched revisions under test:
  Aaro Koskinen <aaro.koskinen@iki.fi>
  Aaron Brown <aaron.f.brown@intel.com>
  Alex Deucher <alexander.deucher@amd.com>
  Alexander Kochetkov <al.kochet@gmail.com>
  Alexey Orishko <alexey.orishko@gmail.com>
  Andrew Morton <akpm@linux-foundation.org>
  Anton Blanchard <anton@samba.org>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Borislav Petkov <bp@suse.de>
  Chris Clayton <chris2553@googlemail.com>
  Clemens Ladisch <clemens@ladisch.de>
  Cong Wang <cwang@twopensource.com>
  Daniel Borkmann <dborkman@redhat.com>
  Daniel Forrest <dan.forrest@ssec.wisc.edu>
  Daniel Vetter <daniel.vetter@ffwll.ch>
  Daniel Vetter <daniel.vetter@intel.com>
  David S. Miller <davem@davemloft.net>
  Devin Ryles <devin.ryles@intel.com>
  Dmitry Torokhov <dtor@chromium.org>
  Eric Dumazet <edumazet@google.com>
  Felipe Balbi <balbi@ti.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Grygorii Strashko <grygorii.strashko@ti.com>
  Hugh Dickins <hughd@google.com>
  Ingo Molnar <mingo@kernel.org>
  Jack Morgenstein <jackm@dev.mellanox.co.il>
  Jani Nikula <jani.nikula@intel.com>
  Jeff Kirsher <jeffrey.t.kirsher@intel.com>
  Johannes Berg <johannes.berg@intel.com>
  Kan Liang <kan.liang@intel.com>
  Kees Cook <keescook@chromium.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  lu hua <huax.lu@intel.com>
  lucien <lucien.xin@gmail.com>
  Maggie Mae Roxas <maggie.mae.roxas@gmail.com>
  Marcelo Leitner <mleitner@redhat.com>
  Marcelo Ricardo Leitner <mleitner@redhat.com>
  Mathias Nyman <mathias.nyman@linux.intel.com>
  Mauro Carvalho Chehab <mchehab@osg.samsung.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Neil Horman <nhorman@tuxdriver.com>
  Nicolas Dichtel <nicolas.dichtel@6wind.com>
  Or Gerlitz <ogerlitz@mellanox.com>
  Peter Zijlstra <peterz@infradead.org>
  Petr Mladek <pmladek@suse.cz>
  Ronald Wahl <ronald.wahl@raritan.com>
  Sakari Ailus <sakari.ailus@iki.fi>
  Seth Forshee <seth.forshee@canonical.com>
  Takashi Iwai <tiwai@suse.de>
  Tejun Heo <tj@kernel.org>
  Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
  Thomas Gleixner <tglx@linutronix.de>
  Todd Fujinaka <todd.fujinaka@intel.com>
  Tom Herbert <therbert@google.com>
  Vlad Yasevich <vyasevich@gmail.com>
  Weijie Yang <weijie.yang@samsung.com>
  Willy Tarreau <w@1wt.eu>
  Wolfram Sang <wsa@the-dreams.de>
  Xin Long <lucien.xin@gmail.com>
  Yuri Chislov <yuri.chislov@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    
 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=83a926f7a4e39fb6be0576024e67fe161593defa
+ . 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 83a926f7a4e39fb6be0576024e67fe161593defa
+ branch=linux-3.14
+ revision=83a926f7a4e39fb6be0576024e67fe161593defa
+ . 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 83a926f7a4e39fb6be0576024e67fe161593defa:tested/linux-3.14
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   356a3e1..83a926f  83a926f7a4e39fb6be0576024e67fe161593defa -> 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 Fri Dec 19 06:23:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 06: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 1Y1qyT-0006qV-49; Fri, 19 Dec 2014 06:23: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 1Y1qyS-0006qQ-9K
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 06:23:40 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	22/21-03148-B64C3945; Fri, 19 Dec 2014 06:23:39 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1418970217!16087539!1
X-Originating-IP: [66.165.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 4413 invoked from network); 19 Dec 2014 06:23:38 -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 Dec 2014 06:23:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,605,1413244800"; d="scan'208";a="206128645"
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.210.2; Fri, 19 Dec 2014 01:23:36 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y1qyN-0001of-QB;
	Fri, 19 Dec 2014 06:23:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1qyN-00078J-Ja;
	Fri, 19 Dec 2014 06:23:35 +0000
Date: Fri, 19 Dec 2014 06:23:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32448-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] 32448: 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 32448 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32448/

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 32149

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-qemuu-winxpsp3 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-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-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-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                83a926f7a4e39fb6be0576024e67fe161593defa
baseline version:
 linux                356a3e1fde11190febb8ace3cdab8694848ed220

------------------------------------------------------------
People who touched revisions under test:
  Aaro Koskinen <aaro.koskinen@iki.fi>
  Aaron Brown <aaron.f.brown@intel.com>
  Alex Deucher <alexander.deucher@amd.com>
  Alexander Kochetkov <al.kochet@gmail.com>
  Alexey Orishko <alexey.orishko@gmail.com>
  Andrew Morton <akpm@linux-foundation.org>
  Anton Blanchard <anton@samba.org>
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Borislav Petkov <bp@suse.de>
  Chris Clayton <chris2553@googlemail.com>
  Clemens Ladisch <clemens@ladisch.de>
  Cong Wang <cwang@twopensource.com>
  Daniel Borkmann <dborkman@redhat.com>
  Daniel Forrest <dan.forrest@ssec.wisc.edu>
  Daniel Vetter <daniel.vetter@ffwll.ch>
  Daniel Vetter <daniel.vetter@intel.com>
  David S. Miller <davem@davemloft.net>
  Devin Ryles <devin.ryles@intel.com>
  Dmitry Torokhov <dtor@chromium.org>
  Eric Dumazet <edumazet@google.com>
  Felipe Balbi <balbi@ti.com>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Grygorii Strashko <grygorii.strashko@ti.com>
  Hugh Dickins <hughd@google.com>
  Ingo Molnar <mingo@kernel.org>
  Jack Morgenstein <jackm@dev.mellanox.co.il>
  Jani Nikula <jani.nikula@intel.com>
  Jeff Kirsher <jeffrey.t.kirsher@intel.com>
  Johannes Berg <johannes.berg@intel.com>
  Kan Liang <kan.liang@intel.com>
  Kees Cook <keescook@chromium.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  lu hua <huax.lu@intel.com>
  lucien <lucien.xin@gmail.com>
  Maggie Mae Roxas <maggie.mae.roxas@gmail.com>
  Marcelo Leitner <mleitner@redhat.com>
  Marcelo Ricardo Leitner <mleitner@redhat.com>
  Mathias Nyman <mathias.nyman@linux.intel.com>
  Mauro Carvalho Chehab <mchehab@osg.samsung.com>
  Michael Ellerman <mpe@ellerman.id.au>
  Neil Horman <nhorman@tuxdriver.com>
  Nicolas Dichtel <nicolas.dichtel@6wind.com>
  Or Gerlitz <ogerlitz@mellanox.com>
  Peter Zijlstra <peterz@infradead.org>
  Petr Mladek <pmladek@suse.cz>
  Ronald Wahl <ronald.wahl@raritan.com>
  Sakari Ailus <sakari.ailus@iki.fi>
  Seth Forshee <seth.forshee@canonical.com>
  Takashi Iwai <tiwai@suse.de>
  Tejun Heo <tj@kernel.org>
  Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
  Thomas Gleixner <tglx@linutronix.de>
  Todd Fujinaka <todd.fujinaka@intel.com>
  Tom Herbert <therbert@google.com>
  Vlad Yasevich <vyasevich@gmail.com>
  Weijie Yang <weijie.yang@samsung.com>
  Willy Tarreau <w@1wt.eu>
  Wolfram Sang <wsa@the-dreams.de>
  Xin Long <lucien.xin@gmail.com>
  Yuri Chislov <yuri.chislov@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    
 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=83a926f7a4e39fb6be0576024e67fe161593defa
+ . 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 83a926f7a4e39fb6be0576024e67fe161593defa
+ branch=linux-3.14
+ revision=83a926f7a4e39fb6be0576024e67fe161593defa
+ . 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 83a926f7a4e39fb6be0576024e67fe161593defa:tested/linux-3.14
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   356a3e1..83a926f  83a926f7a4e39fb6be0576024e67fe161593defa -> 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 Fri Dec 19 06:59:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 06: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 1Y1rWY-0007wt-Ae; Fri, 19 Dec 2014 06:58:54 +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 1Y1rWW-0007wo-Vi
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 06:58:53 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	36/DF-09284-CACC3945; Fri, 19 Dec 2014 06:58:52 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418972329!14395670!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 11939 invoked from network); 19 Dec 2014 06:58:51 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 06:58:51 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 23:58:48 -0700
Message-Id: <54943D220200006600086A64@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 23:58:42 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
	<1418916436.11882.101.camel@citrix.com>
In-Reply-To: <1418916436.11882.101.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/18/2014 at 11:27 PM, in message <1418916436.11882.101.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * remove libxl_domain_snapshot_create/delete/revert API 
> >   * export disk snapshot functionality for both xl and libvirt usage 
> >  
> > =========================================================================== 
> > Libxl/libxlu Design 
> >  
> > 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), 
>  
> Should this be a KeyedUnion over a new LIBXL_DISK_SNAPSHOT_KIND enum 
> (with values INTERNAL and EXTERNAL)?
The KeyedUnion seems to be unnecessary. Only EXTERNAL has data items,
INTERNAL doesn't, and no third types.

> This would automatically make the 
> binding between external==true and the fields which depend on that. 
>  
> external_format should be of type libxl_disk_format, unless it is 
> referring to something else? 

Yes. That's right. I'll update.

>  
> Is it possible for format to differ from the format of the underlying 
> disk? Perhaps taking a snapshot of a raw disk as a qcow?

This is related to implementation details. As I understand qemu's
implementation, taking an external disk snapshot is actually a way:
origin domain disk: a raw disk
external= true, external_format: qcow2, external_path: test
a), create a qcow2 file (test.qcow2) with  backing file (the raw disk)
b), replace domain disk, now domain uses test.qcow2 (the raw disk
     is actually to be the snapshot)

So, I think the external_format can only be those supporting backing file.

> In any case 
> passing in UNKNOWN and letting libxl choose (probably by picking the 
> same as the underlying disk) should be supported.

If external_format is not passed (NULL), by default, we will use qcow2.

>  
> > /*  This API might not be used by xl, since xl won't take care of deleting 
> >  *  snapshots. But for libvirt, since libvirt manages snapshots and will 
> >  *  delete snapshot, this API will be used. 
> >  */ 
> > int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid, 
> >                                libxl_disk_snapshot *snapshot, int nb); 
>  
> The three usecases I mentioned in the previous mail are important here, 
> because depending on which usecases you are considering there maybe a 
> many to one relationship between domains and a given snapshot (gold 
> image case). This interface cannot support that I think.

I'm not quite clear about the three usecases, especially the 3rd usercase,
so really not sure what's the requirement towards deleting disk snapshot.
 
>  
> When we discussed this in previous iterations I suggested a libxl 
> command to tell a VM that it needed to reexamine its disks to see if any 
> of the chains had changed. I'm sure that's not the only potential answer 
> though.
 
About delete disk snapshot in a snapshot chain, whether we need to do
extra work to avoid data break, it can be discussed:
a). For external snapshots, usually it's based on backing file chain, qemu
does this, vhd-util does this. In this case, to delete a domain snapshot,
one doesn't need to do anything to disk (no need to delete disk snapshot
at all). Downside is, there might be a long backing chain.
b). For internal snapshot, like qcow2, lvm too. For lvm, it doesn't support
snapshot of snapshot, so out of scope. For qcow2, delete any disk snapshot
won't affect others.

>  
> > int libxl_disk_to_snapshot(libxl_ctx *ctx, uint32_t domid, 
> >                            libxl_disk_snapshot **snapshot, int *num); 
> >  
> >     This is for domain snapshot create. If user doesn't specify disks, 
> >     then by default it will take internal disk snapshot to each domain 
> >     disk. This function will fill libxl_disk_snapshot according to domain 
> >     disks info. 
>  
> Is this just a helper to produce an array to pass to 
> libxl_disk_snapshot_create? Or does it actually do stuff? 
>  
> I think it's the former, but it could be clarified.

Yes, the former.

> I *think* this is 
> just a special case of libxl_device_disk_list which returns plausible 
> snapshot objects instead of the disks themselves. 

So we prefer adding codes to libxl_device_disk_list rather than adding
a new API, right?

> >  
> > For disk snapshot revert, no qmp command for that, it always calls 
> > external commands to finish the work, so put in libxlu (?): 
>  
> I think rather than "no qmp" the issue is that "revert" is (at least as 
> far as libxl knows) essentially, destroy, rollback disks, restore from 
> RAM snapshot. So there is no qemu to speak to during the rollback. Is 
> that right? 

Yes, that's right.

>  
> Ian. 
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 06:59:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 06: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 1Y1rWY-0007wt-Ae; Fri, 19 Dec 2014 06:58:54 +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 1Y1rWW-0007wo-Vi
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 06:58:53 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	36/DF-09284-CACC3945; Fri, 19 Dec 2014 06:58:52 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418972329!14395670!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 11939 invoked from network); 19 Dec 2014 06:58:51 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 06:58:51 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Thu, 18 Dec 2014 23:58:48 -0700
Message-Id: <54943D220200006600086A64@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Thu, 18 Dec 2014 23:58:42 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
	<1418916436.11882.101.camel@citrix.com>
In-Reply-To: <1418916436.11882.101.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/18/2014 at 11:27 PM, in message <1418916436.11882.101.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * remove libxl_domain_snapshot_create/delete/revert API 
> >   * export disk snapshot functionality for both xl and libvirt usage 
> >  
> > =========================================================================== 
> > Libxl/libxlu Design 
> >  
> > 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), 
>  
> Should this be a KeyedUnion over a new LIBXL_DISK_SNAPSHOT_KIND enum 
> (with values INTERNAL and EXTERNAL)?
The KeyedUnion seems to be unnecessary. Only EXTERNAL has data items,
INTERNAL doesn't, and no third types.

> This would automatically make the 
> binding between external==true and the fields which depend on that. 
>  
> external_format should be of type libxl_disk_format, unless it is 
> referring to something else? 

Yes. That's right. I'll update.

>  
> Is it possible for format to differ from the format of the underlying 
> disk? Perhaps taking a snapshot of a raw disk as a qcow?

This is related to implementation details. As I understand qemu's
implementation, taking an external disk snapshot is actually a way:
origin domain disk: a raw disk
external= true, external_format: qcow2, external_path: test
a), create a qcow2 file (test.qcow2) with  backing file (the raw disk)
b), replace domain disk, now domain uses test.qcow2 (the raw disk
     is actually to be the snapshot)

So, I think the external_format can only be those supporting backing file.

> In any case 
> passing in UNKNOWN and letting libxl choose (probably by picking the 
> same as the underlying disk) should be supported.

If external_format is not passed (NULL), by default, we will use qcow2.

>  
> > /*  This API might not be used by xl, since xl won't take care of deleting 
> >  *  snapshots. But for libvirt, since libvirt manages snapshots and will 
> >  *  delete snapshot, this API will be used. 
> >  */ 
> > int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid, 
> >                                libxl_disk_snapshot *snapshot, int nb); 
>  
> The three usecases I mentioned in the previous mail are important here, 
> because depending on which usecases you are considering there maybe a 
> many to one relationship between domains and a given snapshot (gold 
> image case). This interface cannot support that I think.

I'm not quite clear about the three usecases, especially the 3rd usercase,
so really not sure what's the requirement towards deleting disk snapshot.
 
>  
> When we discussed this in previous iterations I suggested a libxl 
> command to tell a VM that it needed to reexamine its disks to see if any 
> of the chains had changed. I'm sure that's not the only potential answer 
> though.
 
About delete disk snapshot in a snapshot chain, whether we need to do
extra work to avoid data break, it can be discussed:
a). For external snapshots, usually it's based on backing file chain, qemu
does this, vhd-util does this. In this case, to delete a domain snapshot,
one doesn't need to do anything to disk (no need to delete disk snapshot
at all). Downside is, there might be a long backing chain.
b). For internal snapshot, like qcow2, lvm too. For lvm, it doesn't support
snapshot of snapshot, so out of scope. For qcow2, delete any disk snapshot
won't affect others.

>  
> > int libxl_disk_to_snapshot(libxl_ctx *ctx, uint32_t domid, 
> >                            libxl_disk_snapshot **snapshot, int *num); 
> >  
> >     This is for domain snapshot create. If user doesn't specify disks, 
> >     then by default it will take internal disk snapshot to each domain 
> >     disk. This function will fill libxl_disk_snapshot according to domain 
> >     disks info. 
>  
> Is this just a helper to produce an array to pass to 
> libxl_disk_snapshot_create? Or does it actually do stuff? 
>  
> I think it's the former, but it could be clarified.

Yes, the former.

> I *think* this is 
> just a special case of libxl_device_disk_list which returns plausible 
> snapshot objects instead of the disks themselves. 

So we prefer adding codes to libxl_device_disk_list rather than adding
a new API, right?

> >  
> > For disk snapshot revert, no qmp command for that, it always calls 
> > external commands to finish the work, so put in libxlu (?): 
>  
> I think rather than "no qmp" the issue is that "revert" is (at least as 
> far as libxl knows) essentially, destroy, rollback disks, restore from 
> RAM snapshot. So there is no qemu to speak to during the rollback. Is 
> that right? 

Yes, that's right.

>  
> Ian. 
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 07:04:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 07:04:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1rbj-000073-LT; Fri, 19 Dec 2014 07:04:15 +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 1Y1rbh-00006y-Dy
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 07:04:13 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	50/1D-26652-CEDC3945; Fri, 19 Dec 2014 07:04:12 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418972650!14238244!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 32651 invoked from network); 19 Dec 2014 07:04:11 -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; 19 Dec 2014 07:04:11 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 00:04:06 -0700
Message-Id: <54943E5F0200006600086A70@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 00:03:59 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
	<1418915759.11882.91.camel@citrix.com>
In-Reply-To: <1418915759.11882.91.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 12/18/2014 at 11:15 PM, in message <1418915759.11882.91.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * xl won't manage snapshots, that means it won't maintain json files, 
> >     won't maintain snapshot chain relationship, and then as a result 
> >     won't take care of deleting snapshot and listing snapshots. 
> >   * remove snapshot-delete and snapshot-list interface 
> >   * update snapshot-revert interface 
> >   * update snapshot-create/revert implementaion 
> >  
> > =========================================================================== 
> >  
> > XL Design 
> >  
> > 1. User Interface 
> >  
> > 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, use cfgfile. (e.g. if --name specifies a name, 
> >     meanwhile there is name specified in cfgfile, name in cfgfile will 
> >     be used.) 
>  
> If you do not specify cfgfile then where do things go? Is --name perhaps 
> also serving as a basename for a path to save things to?

If user doesn't specify cfgfile, then by default, it will save memory to
a default path  and take internal disk snapshot to each disk with a default
disk snapshot name.

'--name' meant to give a meaningful name (like: newinstall. Used as the
memory snapshot name and disk snapshot name). About saving path,
we meant to have a default path, but now I think it's better to let user
specify a path as you suggests here.
 
>  
> I wonder if we can simplify this a bit and therefore avoid the need cfg 
> file in common case. e.g. 
>  
> ----8<------- 
>   xl snapshot-create [--live] [--internal|--external] <domain> <path> 
>  
> <path> is a path to a directory, which must not exist. This path will be 
> created and the memory snapshot stored in it using some well defined 
> name. 
>  
> If the snapshot is --external then the snapshot disks are created in 
> <path> with some well defined name based on the virtual device and 
> backend format in use. 
>  
> If the snapshot is --internal then the snapshot disks are internal. 

That's good. Then we need to add some description to tell users about
the auto-generated domain snapshot name, disk snapshot name,
memory state file and external disk snapshot files, etc.

>  
> The default is <TBD, based on backends in use?> 
>  
> --live is as you've already got it. 
> ----8<------- 
>  
> I'm not sure what name and description actually are here, so I've 
> omitted them. 
>  
> Any of that could be overridden with e.g. more specific disk 
> configuration stanzas etc via the cfg file, if necessary. 
>  
> This is just a suggestion, feel free to disagree.
>  
> NB xl create can accept a series of cfg file lines on the command line 
> too, and treats them as appended to the cfgfile (if any was given). I 
> think xl snapshot-create should include this functionality too. 
> > xl snapshot-revert: 
> >   Revert domain to status of a snapshot. 
> >  
> >   SYNOPSIS: 
> >       snapshot-revert <domain> <cfgfile> [--running] [--force] 
> >  
> >   OPTIONS: 
> >     --running        after reverting, change state to running 
> >     --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. 
> >  
> >  
> >  
> > 2. cfgfile syntax 
> >  
> > #snapshot name. If user doesn't provide a VM snapshot name, xl will  
> generate 
> > #a name automatically by the creation time. 
> > name="" 
>  
> What is name used for? (I guessed it might be output path above, but I'm 
> not sure). 

As above '--name':
It suggests as a meaningful snapshot name. But as you suggest, if we let
user to specify a path, then that <path> can take a meaning path name,
then everything in it can be auto-generated.

>  
> > #snapshot description. Default is NULL. 
> > description="" 
>  
> What is this used for? Is it embedded into e.g. qcow images or is it 
> just for the admin's own use (in which cases the existing support for 
> #comments ought to suffice). 

Oh, I forgot to delete it. It's originally used for manage snapshots, a
text description to the snapshot.

>  
> > #memory location. This field should be filled when memory=1. Default is  
> NULL. 
>  
> The memory option isn't defined anywhere, and I think you've rules 
> disk-only snapshots out of scope for xl, so I think this is just a left 
> over from a previous revision. 

Oh, yes, it's an old comment. I should delete the memory option part.
Sorry for that.

>  
> > #e.g. to specify exernal disk snapshot, like this: 
> > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', 
> >         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] 
> >  
> > #e.g. to specify internal disk snapshot, like this: 
> > disks=[',,hda',',,hdb',] 
>  
> Ideally one or the other of these behaviours would be possible without 
> needing to be quite so explicit.

OK, I'll delete one.

Chunyan

>  
> Ian. 
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 07:04:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 07:04:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1rbj-000073-LT; Fri, 19 Dec 2014 07:04:15 +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 1Y1rbh-00006y-Dy
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 07:04:13 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	50/1D-26652-CEDC3945; Fri, 19 Dec 2014 07:04:12 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1418972650!14238244!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 32651 invoked from network); 19 Dec 2014 07:04:11 -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; 19 Dec 2014 07:04:11 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 00:04:06 -0700
Message-Id: <54943E5F0200006600086A70@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 00:03:59 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
	<1418915759.11882.91.camel@citrix.com>
In-Reply-To: <1418915759.11882.91.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 12/18/2014 at 11:15 PM, in message <1418915759.11882.91.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * xl won't manage snapshots, that means it won't maintain json files, 
> >     won't maintain snapshot chain relationship, and then as a result 
> >     won't take care of deleting snapshot and listing snapshots. 
> >   * remove snapshot-delete and snapshot-list interface 
> >   * update snapshot-revert interface 
> >   * update snapshot-create/revert implementaion 
> >  
> > =========================================================================== 
> >  
> > XL Design 
> >  
> > 1. User Interface 
> >  
> > 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, use cfgfile. (e.g. if --name specifies a name, 
> >     meanwhile there is name specified in cfgfile, name in cfgfile will 
> >     be used.) 
>  
> If you do not specify cfgfile then where do things go? Is --name perhaps 
> also serving as a basename for a path to save things to?

If user doesn't specify cfgfile, then by default, it will save memory to
a default path  and take internal disk snapshot to each disk with a default
disk snapshot name.

'--name' meant to give a meaningful name (like: newinstall. Used as the
memory snapshot name and disk snapshot name). About saving path,
we meant to have a default path, but now I think it's better to let user
specify a path as you suggests here.
 
>  
> I wonder if we can simplify this a bit and therefore avoid the need cfg 
> file in common case. e.g. 
>  
> ----8<------- 
>   xl snapshot-create [--live] [--internal|--external] <domain> <path> 
>  
> <path> is a path to a directory, which must not exist. This path will be 
> created and the memory snapshot stored in it using some well defined 
> name. 
>  
> If the snapshot is --external then the snapshot disks are created in 
> <path> with some well defined name based on the virtual device and 
> backend format in use. 
>  
> If the snapshot is --internal then the snapshot disks are internal. 

That's good. Then we need to add some description to tell users about
the auto-generated domain snapshot name, disk snapshot name,
memory state file and external disk snapshot files, etc.

>  
> The default is <TBD, based on backends in use?> 
>  
> --live is as you've already got it. 
> ----8<------- 
>  
> I'm not sure what name and description actually are here, so I've 
> omitted them. 
>  
> Any of that could be overridden with e.g. more specific disk 
> configuration stanzas etc via the cfg file, if necessary. 
>  
> This is just a suggestion, feel free to disagree.
>  
> NB xl create can accept a series of cfg file lines on the command line 
> too, and treats them as appended to the cfgfile (if any was given). I 
> think xl snapshot-create should include this functionality too. 
> > xl snapshot-revert: 
> >   Revert domain to status of a snapshot. 
> >  
> >   SYNOPSIS: 
> >       snapshot-revert <domain> <cfgfile> [--running] [--force] 
> >  
> >   OPTIONS: 
> >     --running        after reverting, change state to running 
> >     --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. 
> >  
> >  
> >  
> > 2. cfgfile syntax 
> >  
> > #snapshot name. If user doesn't provide a VM snapshot name, xl will  
> generate 
> > #a name automatically by the creation time. 
> > name="" 
>  
> What is name used for? (I guessed it might be output path above, but I'm 
> not sure). 

As above '--name':
It suggests as a meaningful snapshot name. But as you suggest, if we let
user to specify a path, then that <path> can take a meaning path name,
then everything in it can be auto-generated.

>  
> > #snapshot description. Default is NULL. 
> > description="" 
>  
> What is this used for? Is it embedded into e.g. qcow images or is it 
> just for the admin's own use (in which cases the existing support for 
> #comments ought to suffice). 

Oh, I forgot to delete it. It's originally used for manage snapshots, a
text description to the snapshot.

>  
> > #memory location. This field should be filled when memory=1. Default is  
> NULL. 
>  
> The memory option isn't defined anywhere, and I think you've rules 
> disk-only snapshots out of scope for xl, so I think this is just a left 
> over from a previous revision. 

Oh, yes, it's an old comment. I should delete the memory option part.
Sorry for that.

>  
> > #e.g. to specify exernal disk snapshot, like this: 
> > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', 
> >         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] 
> >  
> > #e.g. to specify internal disk snapshot, like this: 
> > disks=[',,hda',',,hdb',] 
>  
> Ideally one or the other of these behaviours would be possible without 
> needing to be quite so explicit.

OK, I'll delete one.

Chunyan

>  
> Ian. 
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 08:05:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 08:05:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1sY7-0002YR-BR; Fri, 19 Dec 2014 08:04:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Y1sY5-0002YM-FV
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 08:04:33 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	0A/1B-14727-01CD3945; Fri, 19 Dec 2014 08:04:32 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418976270!6674760!1
X-Originating-IP: [66.165.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 13265 invoked from network); 19 Dec 2014 08:04:32 -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 Dec 2014 08:04:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,605,1413244800"; d="scan'208";a="206147177"
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.210.2;
	Fri, 19 Dec 2014 03:04:03 -0500
Message-ID: <5493DBF3.5040705@citrix.com>
Date: Fri, 19 Dec 2014 09:04:03 +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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, <xen-devel@lists.xenproject.org>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
	<5493224D.9050001@citrix.com>
In-Reply-To: <5493224D.9050001@citrix.com>
Content-Length:1265
X-DLP: MIA1
Cc: Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
	from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8sCgpFbCAxOC8xMi8xNCBhIGxlcyAxOS41MSwgQW5kcmV3IENvb3BlciBoYSBlc2NyaXQ6
Cj4gT24gMTgvMTIvMTQgMTg6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gUHJldmVudCBE
b20wIGZyb20gYWNjZXNzaW5nIEhQRVQgTU1JTyByZWdpb24gYnkgYWRkaW5nIGl0IHRvIHRoZSBs
aXN0IG9mCj4+IGRlbmllZCBtZW1vcnkgcmVnaW9ucy4KPj4KPj4gU2lnbmVkLW9mZi1ieTogUm9n
ZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4+IENjOiBKYW4gQmV1bGljaCA8
amJldWxpY2hAc3VzZS5jb20+Cj4+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0Bj
aXRyaXguY29tPgo+IAo+IEFwb2xvZ2llcyB0aGF0IHRoaXMgcmVwbHkgaXMgc3BsaXQgYmV0d2Vl
biBwYXRjaCAwIGFuZCAyIC0gSSByZXBsaWVkIHRvCj4geW91ciBjb3ZlciBsZXR0ZXIgYmVmb3Jl
IHJlYWRpbmcgdGhpcyBwYXRjaC4KPiAKPiBEZW55aW5nIGFjY2VzcyBpcyBvbmx5IHZhbGlkIGlm
IGFjcGlfdGFibGVfaHBldC5mbGFncyAmIAo+IEFDUElfSFBFVF9QQUdFX1BST1RFQ1Q0IGlzIHRy
dWUuCgpUaGFua3MsIGlmIEFDUElfSFBFVF9QQUdFX1BST1RFQ1Q0IGlzIHNldCB0aGVuIHdlIGNh
biBwcmV2ZW50IGFjY2VzcyB0bwp0aGUgZnVsbCBwYWdlIGFuZCBpZiBBQ1BJX0hQRVRfUEFHRV9Q
Uk9URUNUNjQgaXMgc2V0IHdlIGNhbiBwcmV2ZW50CmFjY2VzcyB0byB0aGlzIHBhZ2UgYW5kIHRo
ZSBhZGphY2VudCA2MEtCICgxNSBwYWdlcykuIFdpbGwgc2VuZCBhbgp1cGRhdGVkIHZlcnNpb24u
CgpSb2dlci4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Dec 19 08:05:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 08:05:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1sY7-0002YR-BR; Fri, 19 Dec 2014 08:04:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1Y1sY5-0002YM-FV
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 08:04:33 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	0A/1B-14727-01CD3945; Fri, 19 Dec 2014 08:04:32 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1418976270!6674760!1
X-Originating-IP: [66.165.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 13265 invoked from network); 19 Dec 2014 08:04:32 -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 Dec 2014 08:04:32 -0000
X-IronPort-AV: E=Sophos;i="5.07,605,1413244800"; d="scan'208";a="206147177"
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.210.2;
	Fri, 19 Dec 2014 03:04:03 -0500
Message-ID: <5493DBF3.5040705@citrix.com>
Date: Fri, 19 Dec 2014 09:04:03 +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.3.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>, <xen-devel@lists.xenproject.org>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
	<5493224D.9050001@citrix.com>
In-Reply-To: <5493224D.9050001@citrix.com>
Content-Length:1265
X-DLP: MIA1
Cc: Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
	from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8sCgpFbCAxOC8xMi8xNCBhIGxlcyAxOS41MSwgQW5kcmV3IENvb3BlciBoYSBlc2NyaXQ6
Cj4gT24gMTgvMTIvMTQgMTg6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gUHJldmVudCBE
b20wIGZyb20gYWNjZXNzaW5nIEhQRVQgTU1JTyByZWdpb24gYnkgYWRkaW5nIGl0IHRvIHRoZSBs
aXN0IG9mCj4+IGRlbmllZCBtZW1vcnkgcmVnaW9ucy4KPj4KPj4gU2lnbmVkLW9mZi1ieTogUm9n
ZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4+IENjOiBKYW4gQmV1bGljaCA8
amJldWxpY2hAc3VzZS5jb20+Cj4+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0Bj
aXRyaXguY29tPgo+IAo+IEFwb2xvZ2llcyB0aGF0IHRoaXMgcmVwbHkgaXMgc3BsaXQgYmV0d2Vl
biBwYXRjaCAwIGFuZCAyIC0gSSByZXBsaWVkIHRvCj4geW91ciBjb3ZlciBsZXR0ZXIgYmVmb3Jl
IHJlYWRpbmcgdGhpcyBwYXRjaC4KPiAKPiBEZW55aW5nIGFjY2VzcyBpcyBvbmx5IHZhbGlkIGlm
IGFjcGlfdGFibGVfaHBldC5mbGFncyAmIAo+IEFDUElfSFBFVF9QQUdFX1BST1RFQ1Q0IGlzIHRy
dWUuCgpUaGFua3MsIGlmIEFDUElfSFBFVF9QQUdFX1BST1RFQ1Q0IGlzIHNldCB0aGVuIHdlIGNh
biBwcmV2ZW50IGFjY2VzcyB0bwp0aGUgZnVsbCBwYWdlIGFuZCBpZiBBQ1BJX0hQRVRfUEFHRV9Q
Uk9URUNUNjQgaXMgc2V0IHdlIGNhbiBwcmV2ZW50CmFjY2VzcyB0byB0aGlzIHBhZ2UgYW5kIHRo
ZSBhZGphY2VudCA2MEtCICgxNSBwYWdlcykuIFdpbGwgc2VuZCBhbgp1cGRhdGVkIHZlcnNpb24u
CgpSb2dlci4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Dec 19 08:32:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 08: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 1Y1syY-0003Jp-O5; Fri, 19 Dec 2014 08:31:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1syW-0003Jk-V5
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 08:31:53 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	E1/57-02954-872E3945; Fri, 19 Dec 2014 08:31:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418977911!12785831!1
X-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 28344 invoked from network); 19 Dec 2014 08:31: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; 19 Dec 2014 08:31:51 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 08:31:50 +0000
Message-Id: <5493F0870200007800050E47@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 08:31:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The endless story continues.

1: make XSA-59 workaround fully cover XeonE5/E7 v2
2: extend XSA-59 workaround to XeonE5 v3 (Haswell)

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 08:32:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 08: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 1Y1syY-0003Jp-O5; Fri, 19 Dec 2014 08:31:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1syW-0003Jk-V5
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 08:31:53 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	E1/57-02954-872E3945; Fri, 19 Dec 2014 08:31:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1418977911!12785831!1
X-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 28344 invoked from network); 19 Dec 2014 08:31: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; 19 Dec 2014 08:31:51 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 08:31:50 +0000
Message-Id: <5493F0870200007800050E47@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 08:31:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The endless story continues.

1: make XSA-59 workaround fully cover XeonE5/E7 v2
2: extend XSA-59 workaround to XeonE5 v3 (Haswell)

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 08:41:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 08:41:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1t7J-0003ji-PH; Fri, 19 Dec 2014 08:40: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 1Y1t7J-0003jd-2i
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 08:40:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B3/94-15461-894E3945; Fri, 19 Dec 2014 08:40:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418978455!16338442!1
X-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 18633 invoked from network); 19 Dec 2014 08:40:56 -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; 19 Dec 2014 08:40:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 08:40:55 +0000
Message-Id: <5493F2A80200007800050E5C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 08:40:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <5493F0870200007800050E47@mail.emea.novell.com>
In-Reply-To: <5493F0870200007800050E47@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC3F60988.1__="
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: [Xen-devel] [PATCH 1/2] VT-d: make XSA-59 workaround fully cover
 XeonE5/E7 v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartC3F60988.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

So far only the VT-d UR masking was being done for them.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -440,6 +440,9 @@ void pci_vtd_quirk(const struct pci_dev=20
                seg, bus, dev, func);
         break;
=20
+    /* Xeon E5/E7 v2 */
+    case 0x0e00: /* host bridge */
+    case 0x0e01: case 0x0e04 ... 0x0e0b: /* root ports */
     /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */
     case 0x3400 ... 0x3407: /* host bridges */
     case 0x3408 ... 0x3411: case 0x3420 ... 0x3421: /* root ports */




--=__PartC3F60988.1__=
Content-Type: text/plain; name="xsa59-XeonEx-v2.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xsa59-XeonEx-v2.patch"

VT-d: make XSA-59 workaround fully cover XeonE5/E7 v2=0A=0ASo far only the =
VT-d UR masking was being done for them.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/vtd/quirks.c=0A+++ =
b/xen/drivers/passthrough/vtd/quirks.c=0A@@ -440,6 +440,9 @@ void =
pci_vtd_quirk(const struct pci_dev =0A                seg, bus, dev, =
func);=0A         break;=0A =0A+    /* Xeon E5/E7 v2 */=0A+    case =
0x0e00: /* host bridge */=0A+    case 0x0e01: case 0x0e04 ... 0x0e0b: /* =
root ports */=0A     /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, =
WSM-EP/EX) */=0A     case 0x3400 ... 0x3407: /* host bridges */=0A     =
case 0x3408 ... 0x3411: case 0x3420 ... 0x3421: /* root ports */=0A
--=__PartC3F60988.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

--=__PartC3F60988.1__=--


From xen-devel-bounces@lists.xen.org Fri Dec 19 08:41:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 08:41:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1t7J-0003ji-PH; Fri, 19 Dec 2014 08:40: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 1Y1t7J-0003jd-2i
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 08:40:57 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	B3/94-15461-894E3945; Fri, 19 Dec 2014 08:40:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1418978455!16338442!1
X-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 18633 invoked from network); 19 Dec 2014 08:40:56 -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; 19 Dec 2014 08:40:56 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 08:40:55 +0000
Message-Id: <5493F2A80200007800050E5C@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 08:40:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <5493F0870200007800050E47@mail.emea.novell.com>
In-Reply-To: <5493F0870200007800050E47@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC3F60988.1__="
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: [Xen-devel] [PATCH 1/2] VT-d: make XSA-59 workaround fully cover
 XeonE5/E7 v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartC3F60988.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

So far only the VT-d UR masking was being done for them.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -440,6 +440,9 @@ void pci_vtd_quirk(const struct pci_dev=20
                seg, bus, dev, func);
         break;
=20
+    /* Xeon E5/E7 v2 */
+    case 0x0e00: /* host bridge */
+    case 0x0e01: case 0x0e04 ... 0x0e0b: /* root ports */
     /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */
     case 0x3400 ... 0x3407: /* host bridges */
     case 0x3408 ... 0x3411: case 0x3420 ... 0x3421: /* root ports */




--=__PartC3F60988.1__=
Content-Type: text/plain; name="xsa59-XeonEx-v2.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xsa59-XeonEx-v2.patch"

VT-d: make XSA-59 workaround fully cover XeonE5/E7 v2=0A=0ASo far only the =
VT-d UR masking was being done for them.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/vtd/quirks.c=0A+++ =
b/xen/drivers/passthrough/vtd/quirks.c=0A@@ -440,6 +440,9 @@ void =
pci_vtd_quirk(const struct pci_dev =0A                seg, bus, dev, =
func);=0A         break;=0A =0A+    /* Xeon E5/E7 v2 */=0A+    case =
0x0e00: /* host bridge */=0A+    case 0x0e01: case 0x0e04 ... 0x0e0b: /* =
root ports */=0A     /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, =
WSM-EP/EX) */=0A     case 0x3400 ... 0x3407: /* host bridges */=0A     =
case 0x3408 ... 0x3411: case 0x3420 ... 0x3421: /* root ports */=0A
--=__PartC3F60988.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

--=__PartC3F60988.1__=--


From xen-devel-bounces@lists.xen.org Fri Dec 19 08:41:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 08: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 1Y1t7x-0003mr-73; Fri, 19 Dec 2014 08:41: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 1Y1t7v-0003ma-JG
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 08:41:35 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	27/E7-02696-EB4E3945; Fri, 19 Dec 2014 08:41:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418978494!16026797!1
X-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 11623 invoked from network); 19 Dec 2014 08:41:34 -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; 19 Dec 2014 08:41:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 08:41:33 +0000
Message-Id: <5493F2CE0200007800050E62@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 08:41:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <5493F0870200007800050E47@mail.emea.novell.com>
In-Reply-To: <5493F0870200007800050E47@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE5D02FAE.1__="
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: [Xen-devel] [PATCH 2/2] VT-d: extend XSA-59 workaround to XeonE5 v3
 (Haswell)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE5D02FAE.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Note that the datasheet lacks PCI IDs for Dev 1 Fn 0-1, so their IDs
are being added based on what https://pci-ids.ucw.cz/read/PC/8086 says.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -431,6 +431,7 @@ void pci_vtd_quirk(const struct pci_dev=20
      *   - Potential security issue if malicious guest trigger VT-d =
faults.
      */
     case 0x0e28: /* Xeon-E5v2 (IvyBridge) */
+    case 0x2f28: /* Xeon-E5v3 (Haswell) */
     case 0x342e: /* Tylersburg chipset (Nehalem / Westmere systems) */
     case 0x3728: /* Xeon C5500/C3500 (JasperForest) */
     case 0x3c28: /* Sandybridge */
@@ -443,6 +444,9 @@ void pci_vtd_quirk(const struct pci_dev=20
     /* Xeon E5/E7 v2 */
     case 0x0e00: /* host bridge */
     case 0x0e01: case 0x0e04 ... 0x0e0b: /* root ports */
+    /* Xeon E5 v3 */
+    case 0x2f00: /* host bridge */
+    case 0x2f01 ... 0x2f0b: /* root ports */
     /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */
     case 0x3400 ... 0x3407: /* host bridges */
     case 0x3408 ... 0x3411: case 0x3420 ... 0x3421: /* root ports */




--=__PartE5D02FAE.1__=
Content-Type: text/plain; name="xsa59-XeonE5-v3.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xsa59-XeonE5-v3.patch"

VT-d: extend XSA-59 workaround to XeonE5 v3 (Haswell)=0A=0ANote that the =
datasheet lacks PCI IDs for Dev 1 Fn 0-1, so their IDs=0Aare being added =
based on what https://pci-ids.ucw.cz/read/PC/8086 says.=0A=0ASigned-off-by:=
 Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/vtd/qui=
rks.c=0A+++ b/xen/drivers/passthrough/vtd/quirks.c=0A@@ -431,6 +431,7 @@ =
void pci_vtd_quirk(const struct pci_dev =0A      *   - Potential security =
issue if malicious guest trigger VT-d faults.=0A      */=0A     case =
0x0e28: /* Xeon-E5v2 (IvyBridge) */=0A+    case 0x2f28: /* Xeon-E5v3 =
(Haswell) */=0A     case 0x342e: /* Tylersburg chipset (Nehalem / Westmere =
systems) */=0A     case 0x3728: /* Xeon C5500/C3500 (JasperForest) */=0A   =
  case 0x3c28: /* Sandybridge */=0A@@ -443,6 +444,9 @@ void pci_vtd_quirk(c=
onst struct pci_dev =0A     /* Xeon E5/E7 v2 */=0A     case 0x0e00: /* =
host bridge */=0A     case 0x0e01: case 0x0e04 ... 0x0e0b: /* root ports =
*/=0A+    /* Xeon E5 v3 */=0A+    case 0x2f00: /* host bridge */=0A+    =
case 0x2f01 ... 0x2f0b: /* root ports */=0A     /* Tylersburg (EP)/Boxboro =
(MP) chipsets (NHM-EP/EX, WSM-EP/EX) */=0A     case 0x3400 ... 0x3407: /* =
host bridges */=0A     case 0x3408 ... 0x3411: case 0x3420 ... 0x3421: /* =
root ports */=0A
--=__PartE5D02FAE.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

--=__PartE5D02FAE.1__=--


From xen-devel-bounces@lists.xen.org Fri Dec 19 08:41:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 08: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 1Y1t7x-0003mr-73; Fri, 19 Dec 2014 08:41: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 1Y1t7v-0003ma-JG
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 08:41:35 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	27/E7-02696-EB4E3945; Fri, 19 Dec 2014 08:41:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418978494!16026797!1
X-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 11623 invoked from network); 19 Dec 2014 08:41:34 -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; 19 Dec 2014 08:41:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 08:41:33 +0000
Message-Id: <5493F2CE0200007800050E62@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 08:41:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
References: <5493F0870200007800050E47@mail.emea.novell.com>
In-Reply-To: <5493F0870200007800050E47@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE5D02FAE.1__="
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: [Xen-devel] [PATCH 2/2] VT-d: extend XSA-59 workaround to XeonE5 v3
 (Haswell)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE5D02FAE.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Note that the datasheet lacks PCI IDs for Dev 1 Fn 0-1, so their IDs
are being added based on what https://pci-ids.ucw.cz/read/PC/8086 says.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -431,6 +431,7 @@ void pci_vtd_quirk(const struct pci_dev=20
      *   - Potential security issue if malicious guest trigger VT-d =
faults.
      */
     case 0x0e28: /* Xeon-E5v2 (IvyBridge) */
+    case 0x2f28: /* Xeon-E5v3 (Haswell) */
     case 0x342e: /* Tylersburg chipset (Nehalem / Westmere systems) */
     case 0x3728: /* Xeon C5500/C3500 (JasperForest) */
     case 0x3c28: /* Sandybridge */
@@ -443,6 +444,9 @@ void pci_vtd_quirk(const struct pci_dev=20
     /* Xeon E5/E7 v2 */
     case 0x0e00: /* host bridge */
     case 0x0e01: case 0x0e04 ... 0x0e0b: /* root ports */
+    /* Xeon E5 v3 */
+    case 0x2f00: /* host bridge */
+    case 0x2f01 ... 0x2f0b: /* root ports */
     /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */
     case 0x3400 ... 0x3407: /* host bridges */
     case 0x3408 ... 0x3411: case 0x3420 ... 0x3421: /* root ports */




--=__PartE5D02FAE.1__=
Content-Type: text/plain; name="xsa59-XeonE5-v3.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xsa59-XeonE5-v3.patch"

VT-d: extend XSA-59 workaround to XeonE5 v3 (Haswell)=0A=0ANote that the =
datasheet lacks PCI IDs for Dev 1 Fn 0-1, so their IDs=0Aare being added =
based on what https://pci-ids.ucw.cz/read/PC/8086 says.=0A=0ASigned-off-by:=
 Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/vtd/qui=
rks.c=0A+++ b/xen/drivers/passthrough/vtd/quirks.c=0A@@ -431,6 +431,7 @@ =
void pci_vtd_quirk(const struct pci_dev =0A      *   - Potential security =
issue if malicious guest trigger VT-d faults.=0A      */=0A     case =
0x0e28: /* Xeon-E5v2 (IvyBridge) */=0A+    case 0x2f28: /* Xeon-E5v3 =
(Haswell) */=0A     case 0x342e: /* Tylersburg chipset (Nehalem / Westmere =
systems) */=0A     case 0x3728: /* Xeon C5500/C3500 (JasperForest) */=0A   =
  case 0x3c28: /* Sandybridge */=0A@@ -443,6 +444,9 @@ void pci_vtd_quirk(c=
onst struct pci_dev =0A     /* Xeon E5/E7 v2 */=0A     case 0x0e00: /* =
host bridge */=0A     case 0x0e01: case 0x0e04 ... 0x0e0b: /* root ports =
*/=0A+    /* Xeon E5 v3 */=0A+    case 0x2f00: /* host bridge */=0A+    =
case 0x2f01 ... 0x2f0b: /* root ports */=0A     /* Tylersburg (EP)/Boxboro =
(MP) chipsets (NHM-EP/EX, WSM-EP/EX) */=0A     case 0x3400 ... 0x3407: /* =
host bridges */=0A     case 0x3408 ... 0x3411: case 0x3420 ... 0x3421: /* =
root ports */=0A
--=__PartE5D02FAE.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

--=__PartE5D02FAE.1__=--


From xen-devel-bounces@lists.xen.org Fri Dec 19 09:01:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09:01:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1tRG-0004fg-6l; Fri, 19 Dec 2014 09:01: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 1Y1tRD-0004fb-V5
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 09:01:32 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	22/28-25727-B69E3945; Fri, 19 Dec 2014 09:01:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418979690!14528775!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28326 invoked from network); 19 Dec 2014 09:01: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; 19 Dec 2014 09:01:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 09:01:29 +0000
Message-Id: <5493F7790200007800050E7B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 09:01:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1418927225-60266-3-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
 from 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 18.12.14 at 19:27, <roger.pau@citrix.com> wrote:
> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_build.c
> @@ -36,6 +36,9 @@
>  #include <asm/bzimage.h> /* for bzimage_parse */
>  #include <asm/io_apic.h>
>  #include <asm/hap.h>
> +#ifdef CONFIG_HPET_TIMER
> +#include <asm/hpet.h> /* for hpet_address */
> +#endif

When you update the patch according to Andrew's comments, please
also drop these stray #ifdef-s - if anything we should delete eventual
other references to CONFIG_HPET_TIMER.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 09:01:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09:01:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1tRG-0004fg-6l; Fri, 19 Dec 2014 09:01: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 1Y1tRD-0004fb-V5
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 09:01:32 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	22/28-25727-B69E3945; Fri, 19 Dec 2014 09:01:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418979690!14528775!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28326 invoked from network); 19 Dec 2014 09:01: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; 19 Dec 2014 09:01:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 09:01:29 +0000
Message-Id: <5493F7790200007800050E7B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 09:01:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1418927225-60266-3-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
 from 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 18.12.14 at 19:27, <roger.pau@citrix.com> wrote:
> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_build.c
> @@ -36,6 +36,9 @@
>  #include <asm/bzimage.h> /* for bzimage_parse */
>  #include <asm/io_apic.h>
>  #include <asm/hap.h>
> +#ifdef CONFIG_HPET_TIMER
> +#include <asm/hpet.h> /* for hpet_address */
> +#endif

When you update the patch according to Andrew's comments, please
also drop these stray #ifdef-s - if anything we should delete eventual
other references to CONFIG_HPET_TIMER.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 09:02:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1tSS-0004lr-LQ; Fri, 19 Dec 2014 09:02:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1tSR-0004lf-K5
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 09:02:47 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	92/B4-22777-6B9E3945; Fri, 19 Dec 2014 09:02:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418979766!8866693!1
X-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 13806 invoked from network); 19 Dec 2014 09:02:46 -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; 19 Dec 2014 09:02:46 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 09:02:45 +0000
Message-Id: <5493F7C60200007800050E7E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 09:02:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
	<5493224D.9050001@citrix.com>
In-Reply-To: <5493224D.9050001@citrix.com>
Mime-Version: 1.0
Content-Length:1143
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
 from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDE4LjEyLjE0IGF0IDE5OjUxLCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4gT24gMTgvMTIvMTQgMTg6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gUHJldmVu
dCBEb20wIGZyb20gYWNjZXNzaW5nIEhQRVQgTU1JTyByZWdpb24gYnkgYWRkaW5nIGl0IHRvIHRo
ZSBsaXN0IG9mCj4+IGRlbmllZCBtZW1vcnkgcmVnaW9ucy4KPj4KPj4gU2lnbmVkLW9mZi1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4+IENjOiBKYW4gQmV1bGlj
aCA8amJldWxpY2hAc3VzZS5jb20+Cj4+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVy
M0BjaXRyaXguY29tPgo+IAo+IEFwb2xvZ2llcyB0aGF0IHRoaXMgcmVwbHkgaXMgc3BsaXQgYmV0
d2VlbiBwYXRjaCAwIGFuZCAyIC0gSSByZXBsaWVkIHRvCj4geW91ciBjb3ZlciBsZXR0ZXIgYmVm
b3JlIHJlYWRpbmcgdGhpcyBwYXRjaC4KPiAKPiBEZW55aW5nIGFjY2VzcyBpcyBvbmx5IHZhbGlk
IGlmIGFjcGlfdGFibGVfaHBldC5mbGFncyAmIAo+IEFDUElfSFBFVF9QQUdFX1BST1RFQ1Q0IGlz
IHRydWUuCgpTb21laG93IHRoZSBleGlzdGVuY2Ugb2YgdGhpcyBpbmRpY2F0aW9uIHNsaXBwZWQg
bXkgYXR0ZW50aW9uIHNvIGZhcjsKSSBoYWQgYWx3YXlzIHdhbnRlZCB0byBoaWRlIHRoZSBIUEVU
IHBhZ2UgZnJvbSBEb20wIGlmIHBvc3NpYmxlLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Dec 19 09:02:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1tSS-0004lr-LQ; Fri, 19 Dec 2014 09:02:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1tSR-0004lf-K5
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 09:02:47 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	92/B4-22777-6B9E3945; Fri, 19 Dec 2014 09:02:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418979766!8866693!1
X-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 13806 invoked from network); 19 Dec 2014 09:02:46 -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; 19 Dec 2014 09:02:46 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 09:02:45 +0000
Message-Id: <5493F7C60200007800050E7E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 09:02:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
	<5493224D.9050001@citrix.com>
In-Reply-To: <5493224D.9050001@citrix.com>
Mime-Version: 1.0
Content-Length:1143
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
 from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDE4LjEyLjE0IGF0IDE5OjUxLCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4gT24gMTgvMTIvMTQgMTg6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gUHJldmVu
dCBEb20wIGZyb20gYWNjZXNzaW5nIEhQRVQgTU1JTyByZWdpb24gYnkgYWRkaW5nIGl0IHRvIHRo
ZSBsaXN0IG9mCj4+IGRlbmllZCBtZW1vcnkgcmVnaW9ucy4KPj4KPj4gU2lnbmVkLW9mZi1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4+IENjOiBKYW4gQmV1bGlj
aCA8amJldWxpY2hAc3VzZS5jb20+Cj4+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVy
M0BjaXRyaXguY29tPgo+IAo+IEFwb2xvZ2llcyB0aGF0IHRoaXMgcmVwbHkgaXMgc3BsaXQgYmV0
d2VlbiBwYXRjaCAwIGFuZCAyIC0gSSByZXBsaWVkIHRvCj4geW91ciBjb3ZlciBsZXR0ZXIgYmVm
b3JlIHJlYWRpbmcgdGhpcyBwYXRjaC4KPiAKPiBEZW55aW5nIGFjY2VzcyBpcyBvbmx5IHZhbGlk
IGlmIGFjcGlfdGFibGVfaHBldC5mbGFncyAmIAo+IEFDUElfSFBFVF9QQUdFX1BST1RFQ1Q0IGlz
IHRydWUuCgpTb21laG93IHRoZSBleGlzdGVuY2Ugb2YgdGhpcyBpbmRpY2F0aW9uIHNsaXBwZWQg
bXkgYXR0ZW50aW9uIHNvIGZhcjsKSSBoYWQgYWx3YXlzIHdhbnRlZCB0byBoaWRlIHRoZSBIUEVU
IHBhZ2UgZnJvbSBEb20wIGlmIHBvc3NpYmxlLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Dec 19 09:06:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09:06:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1tW9-00050Z-Ay; Fri, 19 Dec 2014 09:06:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1tW8-00050T-16
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 09:06:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	00/5F-15461-B9AE3945; Fri, 19 Dec 2014 09:06:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418979994!16673448!1
X-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 5823 invoked from network); 19 Dec 2014 09:06:34 -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; 19 Dec 2014 09:06:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 09:06:34 +0000
Message-Id: <5493F8A90200007800050E8F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 09:06:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monne" <roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-2-git-send-email-roger.pau@citrix.com>
	<54932565.2020801@citrix.com>
In-Reply-To: <54932565.2020801@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 1/2] xen/pvh: check permissions
 when adding MMIO regions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 20:05, <andrew.cooper3@citrix.com> wrote:
> On 18/12/14 18:27, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/domain_build.c
>> +++ b/xen/arch/x86/domain_build.c
>> @@ -312,16 +312,47 @@ static __init void pvh_add_mem_mapping(struct domain *d, unsigned long gfn,
>>                                         unsigned long mfn, unsigned long nr_mfns)
>>  {
>>      unsigned long i;
>> +    xenmem_access_t def_access;
>> +    bool_t r_only = false;
>>      int rc;
>>  
>>      for ( i = 0; i < nr_mfns; i++ )
>>      {
>> +        if ( !iomem_access_permitted(d, mfn + i, mfn + i) )
>> +            goto next;
>> +
>> +        if ( rangeset_contains_singleton(mmio_ro_ranges, mfn + i) && !r_only )
>> +        {
>> +            rc = p2m_get_mem_access(d, ~0ul, &def_access);
>> +            BUG_ON(rc);
>> +            /* Set default access to read-only */
>> +            rc = p2m_set_mem_access(d, ~0ul, 0, 0, 0, XENMEM_access_r);
>> +            BUG_ON(rc);
>> +            r_only = true;
>> +        }
>> +        else if ( r_only )
>> +        {
>> +            /* Set the default back */
>> +            rc = p2m_set_mem_access(d, ~0ul, 0, 0, 0, def_access);
>> +            BUG_ON(rc);
>> +            r_only = false;
>> +        }
> 
> Am I missing something obvious, or would all this r_only juggling be far
> more easy if set_mmio_p2m_entry() had a ro/rw boolean parameter?
> 
> As these entries are done one at a time, it would seem to be far less
> error prone to explicitly choose a read-only or read-write mmio mapping,
> rather than playing with the entire default.

+1

>> +
>>          if ( (rc = set_mmio_p2m_entry(d, gfn + i, _mfn(mfn + i))) )
>>              panic("pvh_add_mem_mapping: gfn:%lx mfn:%lx i:%ld rc:%d\n",
>>                    gfn, mfn, i, rc);
>> +
>> + next:
>>          if ( !(i & 0xfffff) )
>>                  process_pending_softirqs();
> 
> You could remove the next label by moving this clause to the top and
> adding an i != 0 check.

Or really just make the respective goto a continue - we know we
don't hide overly large regions from Dom0.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 09:06:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09:06:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1tW9-00050Z-Ay; Fri, 19 Dec 2014 09:06:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1tW8-00050T-16
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 09:06:36 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	00/5F-15461-B9AE3945; Fri, 19 Dec 2014 09:06:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1418979994!16673448!1
X-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 5823 invoked from network); 19 Dec 2014 09:06:34 -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; 19 Dec 2014 09:06:34 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 09:06:34 +0000
Message-Id: <5493F8A90200007800050E8F@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 09:06:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monne" <roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-2-git-send-email-roger.pau@citrix.com>
	<54932565.2020801@citrix.com>
In-Reply-To: <54932565.2020801@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 1/2] xen/pvh: check permissions
 when adding MMIO regions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 20:05, <andrew.cooper3@citrix.com> wrote:
> On 18/12/14 18:27, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/domain_build.c
>> +++ b/xen/arch/x86/domain_build.c
>> @@ -312,16 +312,47 @@ static __init void pvh_add_mem_mapping(struct domain *d, unsigned long gfn,
>>                                         unsigned long mfn, unsigned long nr_mfns)
>>  {
>>      unsigned long i;
>> +    xenmem_access_t def_access;
>> +    bool_t r_only = false;
>>      int rc;
>>  
>>      for ( i = 0; i < nr_mfns; i++ )
>>      {
>> +        if ( !iomem_access_permitted(d, mfn + i, mfn + i) )
>> +            goto next;
>> +
>> +        if ( rangeset_contains_singleton(mmio_ro_ranges, mfn + i) && !r_only )
>> +        {
>> +            rc = p2m_get_mem_access(d, ~0ul, &def_access);
>> +            BUG_ON(rc);
>> +            /* Set default access to read-only */
>> +            rc = p2m_set_mem_access(d, ~0ul, 0, 0, 0, XENMEM_access_r);
>> +            BUG_ON(rc);
>> +            r_only = true;
>> +        }
>> +        else if ( r_only )
>> +        {
>> +            /* Set the default back */
>> +            rc = p2m_set_mem_access(d, ~0ul, 0, 0, 0, def_access);
>> +            BUG_ON(rc);
>> +            r_only = false;
>> +        }
> 
> Am I missing something obvious, or would all this r_only juggling be far
> more easy if set_mmio_p2m_entry() had a ro/rw boolean parameter?
> 
> As these entries are done one at a time, it would seem to be far less
> error prone to explicitly choose a read-only or read-write mmio mapping,
> rather than playing with the entire default.

+1

>> +
>>          if ( (rc = set_mmio_p2m_entry(d, gfn + i, _mfn(mfn + i))) )
>>              panic("pvh_add_mem_mapping: gfn:%lx mfn:%lx i:%ld rc:%d\n",
>>                    gfn, mfn, i, rc);
>> +
>> + next:
>>          if ( !(i & 0xfffff) )
>>                  process_pending_softirqs();
> 
> You could remove the next label by moving this clause to the top and
> adding an i != 0 check.

Or really just make the respective goto a continue - we know we
don't hide overly large regions from Dom0.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 09:11:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09:11:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1tbA-0005Nh-2S; Fri, 19 Dec 2014 09:11: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 1Y1tb8-0005Nc-R5
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 09:11:46 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	3D/D8-08051-1DBE3945; Fri, 19 Dec 2014 09:11:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418980305!11477938!1
X-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 29578 invoked from network); 19 Dec 2014 09:11:45 -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; 19 Dec 2014 09:11:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 09:11:44 +0000
Message-Id: <5493F9DF0200007800050E9D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 09:11:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monne" <roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
	<5493224D.9050001@citrix.com>
In-Reply-To: <5493224D.9050001@citrix.com>
Mime-Version: 1.0
Content-Length:1265
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
 from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDE4LjEyLjE0IGF0IDE5OjUxLCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4gT24gMTgvMTIvMTQgMTg6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gUHJldmVu
dCBEb20wIGZyb20gYWNjZXNzaW5nIEhQRVQgTU1JTyByZWdpb24gYnkgYWRkaW5nIGl0IHRvIHRo
ZSBsaXN0IG9mCj4+IGRlbmllZCBtZW1vcnkgcmVnaW9ucy4KPj4KPj4gU2lnbmVkLW9mZi1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4+IENjOiBKYW4gQmV1bGlj
aCA8amJldWxpY2hAc3VzZS5jb20+Cj4+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVy
M0BjaXRyaXguY29tPgo+IAo+IEFwb2xvZ2llcyB0aGF0IHRoaXMgcmVwbHkgaXMgc3BsaXQgYmV0
d2VlbiBwYXRjaCAwIGFuZCAyIC0gSSByZXBsaWVkIHRvCj4geW91ciBjb3ZlciBsZXR0ZXIgYmVm
b3JlIHJlYWRpbmcgdGhpcyBwYXRjaC4KPiAKPiBEZW55aW5nIGFjY2VzcyBpcyBvbmx5IHZhbGlk
IGlmIGFjcGlfdGFibGVfaHBldC5mbGFncyAmIAo+IEFDUElfSFBFVF9QQUdFX1BST1RFQ1Q0IGlz
IHRydWUuCgpIYXZpbmcganVzdCBjaGVja2VkIChhcyBhbiBleGFtcGxlKSB0aGUgbW9zdCBtb2Rl
cm4gSW50ZWwgYm94IEkKaGF2ZSBkaXJlY3QgYWNjZXNzIHRvLCBJIHdvbmRlciBob3cgbWFueSBz
eXN0ZW1zIGFjdHVhbGx5IHN1cHBseQpvdGhlciB0aGFuIDAgaGVyZS4gUGVyaGFwcyB3ZSBvdWdo
dCB0byBhdCBvbmNlIGFkZCBhIGNvbW1hbmQKbGluZSBvcHRpb24gdG8gdHJpZ2dlciB0aGUgZGVu
aWFsPwoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Dec 19 09:11:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09:11:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1tbA-0005Nh-2S; Fri, 19 Dec 2014 09:11: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 1Y1tb8-0005Nc-R5
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 09:11:46 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	3D/D8-08051-1DBE3945; Fri, 19 Dec 2014 09:11:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418980305!11477938!1
X-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 29578 invoked from network); 19 Dec 2014 09:11:45 -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; 19 Dec 2014 09:11:45 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 09:11:44 +0000
Message-Id: <5493F9DF0200007800050E9D@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 09:11:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monne" <roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
	<5493224D.9050001@citrix.com>
In-Reply-To: <5493224D.9050001@citrix.com>
Mime-Version: 1.0
Content-Length:1265
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
 from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDE4LjEyLjE0IGF0IDE5OjUxLCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4gT24gMTgvMTIvMTQgMTg6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gUHJldmVu
dCBEb20wIGZyb20gYWNjZXNzaW5nIEhQRVQgTU1JTyByZWdpb24gYnkgYWRkaW5nIGl0IHRvIHRo
ZSBsaXN0IG9mCj4+IGRlbmllZCBtZW1vcnkgcmVnaW9ucy4KPj4KPj4gU2lnbmVkLW9mZi1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4+IENjOiBKYW4gQmV1bGlj
aCA8amJldWxpY2hAc3VzZS5jb20+Cj4+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVy
M0BjaXRyaXguY29tPgo+IAo+IEFwb2xvZ2llcyB0aGF0IHRoaXMgcmVwbHkgaXMgc3BsaXQgYmV0
d2VlbiBwYXRjaCAwIGFuZCAyIC0gSSByZXBsaWVkIHRvCj4geW91ciBjb3ZlciBsZXR0ZXIgYmVm
b3JlIHJlYWRpbmcgdGhpcyBwYXRjaC4KPiAKPiBEZW55aW5nIGFjY2VzcyBpcyBvbmx5IHZhbGlk
IGlmIGFjcGlfdGFibGVfaHBldC5mbGFncyAmIAo+IEFDUElfSFBFVF9QQUdFX1BST1RFQ1Q0IGlz
IHRydWUuCgpIYXZpbmcganVzdCBjaGVja2VkIChhcyBhbiBleGFtcGxlKSB0aGUgbW9zdCBtb2Rl
cm4gSW50ZWwgYm94IEkKaGF2ZSBkaXJlY3QgYWNjZXNzIHRvLCBJIHdvbmRlciBob3cgbWFueSBz
eXN0ZW1zIGFjdHVhbGx5IHN1cHBseQpvdGhlciB0aGFuIDAgaGVyZS4gUGVyaGFwcyB3ZSBvdWdo
dCB0byBhdCBvbmNlIGFkZCBhIGNvbW1hbmQKbGluZSBvcHRpb24gdG8gdHJpZ2dlciB0aGUgZGVu
aWFsPwoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Dec 19 09:44:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09:44:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1u6V-0006kF-R5; Fri, 19 Dec 2014 09:44:11 +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 1Y1u6U-0006kA-0w
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 09:44:10 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	15/4A-24124-963F3945; Fri, 19 Dec 2014 09:44:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418982248!14260840!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 20645 invoked from network); 19 Dec 2014 09:44:08 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 09:44:08 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Y1u69-000E1P-Bl; Fri, 19 Dec 2014 09:43:49 +0000
Date: Fri, 19 Dec 2014 10:43:49 +0100
From: Tim Deegan <tim@xen.org>
To: Chao Peng <chao.p.peng@linux.intel.com>
Message-ID: <20141219094349.GA51707@deinos.phlegethon.org>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141218164028.GB75015@deinos.phlegethon.org>
	<20141219060939.GD3105@pengc-linux.bj.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141219060939.GD3105@pengc-linux.bj.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: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	will.auld@intel.com, JBeulich@suse.com, wei.liu2@citrix.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design 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

At 14:09 +0800 on 19 Dec (1418994579), Chao Peng wrote:
> On Thu, Dec 18, 2014 at 05:40:28PM +0100, Tim Deegan wrote:
> > Hi,
> >
> > Thanks for posting this - it's very useful.  I have a couple of
> > questions about the interface design.
> Thanks Tim.
> >
> > At 20:27 +0800 on 12 Dec (1418412477), Chao Peng wrote:
> > > Design Overview
> > > When enforcing cache allocation for VMs, the minimum granularity is
> > > defined as the domain. All Virtual CPUs ("VCPUs") of a domain have the
> > > same COS, and therefore, correspond to the same CBM. COS is used only in
> > > hypervisor and is transparent to tool stack/user. System administrator
> > > can specify the initial CBM for each domain or change it at runtime using
> > > tool stack. Hypervisor then choses a free COS to associate it with that
> > > CBM or find a existed COS which has the same CBM.
> >
> > What happens if there is no existing COS that matches, and all COSes
> > are in use?  Does Xen return an error?  Or try to change COS->CMB
> > mappings during context switches?
> 
> In the initial implementation, error is returned. It??s possible for
> hypervisor to share COS for different CBMes and not to return error
> here. But the problem is that COS shortage may still happen during
> context switch. At that time we will have no idea for what to do. So I??d
> prefer to return error directly here and leave the decision to user
> space, e.g. if error is returned then it can clear CBM for some domain
> and get free COS.

Righto, thanks. 

> > Is it OK to assume that in the common case all CPUs have the same CAT
> > capabilities?  Then Xen can just report the smallest set of
> > capabilities of any socket in the system, and the toolstack doesn't
> > have to mess about with per-socket settings.
> >
> > I guess you can add that syntactic sugar on the tools if you want and
> > leave the more powerful hypecall interface in case it's useful. :)
> 
> Agreed, this is what I want to do. Basically the socketId is optional
> for the caller. If more than one socket exists, omitting socketId means
> the specified CBM applied to all sockets. While we still maintain
> per-socket CBM in hypervisor internally and provide per-socket hypercall
> interface in case it??s needed. In this way the interface should be user
> friendly for most cases.

Sounds good.  Thanks for clarifying.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 09:44:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09:44:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1u6V-0006kF-R5; Fri, 19 Dec 2014 09:44:11 +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 1Y1u6U-0006kA-0w
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 09:44:10 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	15/4A-24124-963F3945; Fri, 19 Dec 2014 09:44:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1418982248!14260840!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 20645 invoked from network); 19 Dec 2014 09:44:08 -0000
Received: from deinos.phlegethon.org (HELO deinos.phlegethon.org) (5.39.92.215)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 09:44:08 -0000
Received: from tjd by deinos.phlegethon.org with local (Exim 4.82 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Y1u69-000E1P-Bl; Fri, 19 Dec 2014 09:43:49 +0000
Date: Fri, 19 Dec 2014 10:43:49 +0100
From: Tim Deegan <tim@xen.org>
To: Chao Peng <chao.p.peng@linux.intel.com>
Message-ID: <20141219094349.GA51707@deinos.phlegethon.org>
References: <1418387277-4613-1-git-send-email-chao.p.peng@linux.intel.com>
	<20141218164028.GB75015@deinos.phlegethon.org>
	<20141219060939.GD3105@pengc-linux.bj.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141219060939.GD3105@pengc-linux.bj.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: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	will.auld@intel.com, JBeulich@suse.com, wei.liu2@citrix.com,
	dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] Cache Allocation Technology(CAT) design 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

At 14:09 +0800 on 19 Dec (1418994579), Chao Peng wrote:
> On Thu, Dec 18, 2014 at 05:40:28PM +0100, Tim Deegan wrote:
> > Hi,
> >
> > Thanks for posting this - it's very useful.  I have a couple of
> > questions about the interface design.
> Thanks Tim.
> >
> > At 20:27 +0800 on 12 Dec (1418412477), Chao Peng wrote:
> > > Design Overview
> > > When enforcing cache allocation for VMs, the minimum granularity is
> > > defined as the domain. All Virtual CPUs ("VCPUs") of a domain have the
> > > same COS, and therefore, correspond to the same CBM. COS is used only in
> > > hypervisor and is transparent to tool stack/user. System administrator
> > > can specify the initial CBM for each domain or change it at runtime using
> > > tool stack. Hypervisor then choses a free COS to associate it with that
> > > CBM or find a existed COS which has the same CBM.
> >
> > What happens if there is no existing COS that matches, and all COSes
> > are in use?  Does Xen return an error?  Or try to change COS->CMB
> > mappings during context switches?
> 
> In the initial implementation, error is returned. It??s possible for
> hypervisor to share COS for different CBMes and not to return error
> here. But the problem is that COS shortage may still happen during
> context switch. At that time we will have no idea for what to do. So I??d
> prefer to return error directly here and leave the decision to user
> space, e.g. if error is returned then it can clear CBM for some domain
> and get free COS.

Righto, thanks. 

> > Is it OK to assume that in the common case all CPUs have the same CAT
> > capabilities?  Then Xen can just report the smallest set of
> > capabilities of any socket in the system, and the toolstack doesn't
> > have to mess about with per-socket settings.
> >
> > I guess you can add that syntactic sugar on the tools if you want and
> > leave the more powerful hypecall interface in case it's useful. :)
> 
> Agreed, this is what I want to do. Basically the socketId is optional
> for the caller. If more than one socket exists, omitting socketId means
> the specified CBM applied to all sockets. While we still maintain
> per-socket CBM in hypervisor internally and provide per-socket hypercall
> interface in case it??s needed. In this way the interface should be user
> friendly for most cases.

Sounds good.  Thanks for clarifying.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 09:48:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09: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 1Y1uB2-0006rY-NR; Fri, 19 Dec 2014 09:48: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 1Y1uB1-0006rS-2c
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 09:48:51 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	CB/FD-03148-284F3945; Fri, 19 Dec 2014 09:48:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418982528!16147724!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16341 invoked from network); 19 Dec 2014 09:48:49 -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;
	19 Dec 2014 09:48:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,605,1413244800"; d="scan'208";a="206170095"
Message-ID: <1418982526.20028.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri, 19 Dec 2014 09:48:46 +0000
In-Reply-To: <1418923754.10854.25.camel@Abyss.station>
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
	<5492EBFC.8010005@suse.com>
	<20141218150409.GA2870@zion.uk.xensource.com>
	<5492EE60.5090005@suse.com> <1418923754.10854.25.camel@Abyss.station>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>, George
	Dunlap <george.dunlap@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] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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, 2014-12-18 at 18:29 +0100, Dario Faggioli wrote:
> On Thu, 2014-12-18 at 16:10 +0100, Juergen Gross wrote:

> > So: Why can't you test cpupools on ARM?
> > 
> We certainly can. ARM testing via OSSTest is a still experimental,
> AFAIUI.

arm32 testing is production in osstest.

> I don't even know if we have the hardware, yet, as I think the "rack" of
> ARM dev board IanC was working on will be setup in the new testing COLO,
> rather than in current OSSTest pool of hardware (someone correct me if
> I'm wrong).

The new rack is to replace the existing h/w used in production, since
that can't be shipped to the colo for various reasons.

> However, that seems to be taken into account by the fact that, in
> make-flight, in test_matrix_do_one(), after only 2 jobs are created (the
> basic debian one and a libvirt one) we have this:
> 
>   # No further arm tests at the moment
>   if [ $dom0arch = armhf ]; then
>       return
>   fi
> 
> So, yes, I guess I can get rid of such filters in my new function, so
> that, when ARM maintainers  will disable the safety catch above, a job
> will actually be generated.

We should probably move some of the tests from below the cut to above
already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific,
so should be run on arm.

That's not your problem, but if you could add the new test above the cut
that would be great. I'll sort out the other ones at some point.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 09:48:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09: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 1Y1uB2-0006rY-NR; Fri, 19 Dec 2014 09:48: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 1Y1uB1-0006rS-2c
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 09:48:51 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	CB/FD-03148-284F3945; Fri, 19 Dec 2014 09:48:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418982528!16147724!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 16341 invoked from network); 19 Dec 2014 09:48:49 -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;
	19 Dec 2014 09:48:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,605,1413244800"; d="scan'208";a="206170095"
Message-ID: <1418982526.20028.2.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri, 19 Dec 2014 09:48:46 +0000
In-Reply-To: <1418923754.10854.25.camel@Abyss.station>
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
	<5492EBFC.8010005@suse.com>
	<20141218150409.GA2870@zion.uk.xensource.com>
	<5492EE60.5090005@suse.com> <1418923754.10854.25.camel@Abyss.station>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>, George
	Dunlap <george.dunlap@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] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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, 2014-12-18 at 18:29 +0100, Dario Faggioli wrote:
> On Thu, 2014-12-18 at 16:10 +0100, Juergen Gross wrote:

> > So: Why can't you test cpupools on ARM?
> > 
> We certainly can. ARM testing via OSSTest is a still experimental,
> AFAIUI.

arm32 testing is production in osstest.

> I don't even know if we have the hardware, yet, as I think the "rack" of
> ARM dev board IanC was working on will be setup in the new testing COLO,
> rather than in current OSSTest pool of hardware (someone correct me if
> I'm wrong).

The new rack is to replace the existing h/w used in production, since
that can't be shipped to the colo for various reasons.

> However, that seems to be taken into account by the fact that, in
> make-flight, in test_matrix_do_one(), after only 2 jobs are created (the
> basic debian one and a libvirt one) we have this:
> 
>   # No further arm tests at the moment
>   if [ $dom0arch = armhf ]; then
>       return
>   fi
> 
> So, yes, I guess I can get rid of such filters in my new function, so
> that, when ARM maintainers  will disable the safety catch above, a job
> will actually be generated.

We should probably move some of the tests from below the cut to above
already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific,
so should be run on arm.

That's not your problem, but if you could add the new test above the cut
that would be great. I'll sort out the other ones at some point.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 09:50:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09:50:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1uC2-0006wT-5X; Fri, 19 Dec 2014 09:49:54 +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 1Y1uC0-0006wE-6H
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 09:49:52 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	B4/E8-11608-FB4F3945; Fri, 19 Dec 2014 09:49:51 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418982589!14544758!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27124 invoked from network); 19 Dec 2014 09:49:50 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 09:49:50 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so4114931wib.3
	for <xen-devel@lists.xen.org>; Fri, 19 Dec 2014 01:49: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=ECMjA49RSk20UiUpGuut4QhvSckqRSuxJJRvgma7dRE=;
	b=T9XNv5IglTD4T//HbxScX7KGEVaWuwPtoItm+tDn39fe3fhNLw1B+PtEe8DUY4Qg+Q
	kp3K0kLJ2jm83LAax7aq0itso+55nOrzR4jZ4xjlUqfhsnAAuGSXHRtg516OA4sW8dJZ
	Ldz12gmq+/1WEi4/z2Osd7znKVWy0TKi6oGamMipKEW4MFTTEYnE5t7UOZeM90fHo5dH
	9qHxRL8+ACwA95ElLgQwg+EJwW83vpVmPUVKneppBbAPKGXcfzi7PsJqK81jYmVISAdG
	ofx1OdHeWBFyxvgjhjF2Nb/Zj3wiLVQ0tcZrex1wYzA3/RWkaFvdm5mBPHuuRDOAlGUN
	igcA==
X-Gm-Message-State: ALoCoQlUpNfkyXvyIU2H4APvk2cRypl89ZLW3lZXaD6EUzJBiYtM7rM+NxA4HJBt7Ykrs9mC0g89
X-Received: by 10.180.11.98 with SMTP id p2mr4201475wib.22.1418982589477;
	Fri, 19 Dec 2014 01:49:49 -0800 (PST)
Received: from [192.180.180.71]
	(static-business-42-20-205-109.rdsl.tecnologicawifi.net.
	[109.205.20.42])
	by mx.google.com with ESMTPSA id l9sm1685797wic.21.2014.12.19.01.49.47
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 19 Dec 2014 01:49:48 -0800 (PST)
Message-ID: <5493F4C7.6020503@m2r.biz>
Date: Fri, 19 Dec 2014 10:49:59 +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.3.0
MIME-Version: 1.0
To: Tiejun Chen <tiejun.chen@intel.com>, JBeulich@suse.com, 
	konrad.wilk@oracle.com, tim@xen.org, kevin.tian@intel.com, 
	yang.z.zhang@intel.com, stefano.stabellini@eu.citrix.com, 
	ian.campbell@citrix.com, ian.jackson@eu.citrix.com, wei.liu2@citrix.com
References: <1418952066-21064-1-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1418952066-21064-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RMRR Fix Design 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-Transfer-Encoding: 7bit
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/12/2014 02:21, Tiejun Chen ha scritto:
>                      RMRR Fix Design for Xen
>
> This design is a goal to fix RMRR for Xen. It includes four sectors as
> follows:
>
>      * Background
>      * What is RMRR
>      * Current RMRR Issues
>      * Design Overview
>
> We hope this can help us to understand current problem then figure out a
> clean and better solution everyone can agree now to go forward.
>
> Background
> ==========
>
> We first identified this RMRR defect when trying to pass-through IGD device,
> which can be simply fixed by adding an identity mapping in case of shared
> EPT table. However along with the community discussion, it boiled down to
> a more general RMRR problem, i.e. the identity mapping is brute-added
> in hypervisor, w/o considering whether conflicting with an existing guest
> PFN ranges. As a general solution we need invent a new mechanism so
> reserved ranges allocated by hypervisor can be exported to the user space
> toolstack and hvmloader, so conflict can be detected when constructing
> guest PFN layout, with best-effort avoidance policies to further help.
>
> What is RMRR
> ============
>
> RMRR is a acronym for Reserved Memory Region Reporting.
>
> BIOS may report each such reserved memory region through the RMRR structures,
> along with the devices that requires access to the specified reserved memory
> region. Reserved memory ranges that are either not DMA targets, or memory
> ranges that may be target of BIOS initiated DMA only during pre-boot phase
> (such as from a boot disk drive) must not be included in the reserved memory
> region reporting. The base address of each RMRR region must be 4KB aligned and
> the size must be an integer multiple of 4KB. BIOS must report the RMRR reported
> memory addresses as reserved in the system memory map returned through methods
> suchas INT15, EFI GetMemoryMap etc. The reserved memory region reporting
> structures are optional. If there are no RMRR structures, the system software
> concludes that the platform does not have any reserved memory ranges that are
> DMA targets.
>
> The RMRR regions are expected to be used for legacy usages (such as USB, UMA
> Graphics, etc.) requiring reserved memory. Platform designers shouldavoid or
> limit use of reserved memory regions since these require system software to
> create holes in the DMA virtual address range available to system software and
> its drivers.
>
> The following is grabbed from my BDW:
>
> (XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
> (XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ab80a000 end_address ab81dfff
> (XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
> (XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ad000000 end_address af7fffff
>
> Here USB occupies 0xab80a000:0xab81dfff, IGD owns 0xad000000:0xaf7fffff.
>
> Note there are zero or more Reserved Memory Region Reporting (RMRR) in one given
> platform. And multiple devices may share one RMRR range. Additionally RMRR can
> go anyplace.
>
> Current RMRR Issues
> ===================
>
> #1 RMRR may conflict RAM, mmio or other ranges in Guest physical level.

Sorry if my question is not inherent, I don't have good knowledge about 
it, xen domUs require that all memory regions is correctly defined in 
hvmloader or do them automatically and correct in any emulated devices 
assigned to domUs?
I'm unable to have qxl vga working in linux domUs and unable to found 
the problem for now, I saw a memory warning in system logs of domU with 
qxl which makes me think that perhaps the differences in memory regions 
of qxl are not considered properly in hvmloader.
The warning I found in one Fedora domU with qxl is:
> ioremap error for 0xfc001000-0xfc002000, requested 0x10, got 0x0 
Here a post about with logs compared also with stdvga tests and kvm 
(with qxl full working) test:
http://lists.xen.org/archives/html/xen-devel/2013-10/msg00016.html
Here the qxl support for libxl patch updated to latest xen if someone 
want fast try it:
https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe

Can someone tell me is can be a hvmloader memory problem or this is not 
related?

Thanks for any reply and sorry for my bad english.

>
> #2 Xen doesn't create RMRR mapping in case of shared ept, then the assigned
>     device can't work well.
>
> #3 Xen doesn't consider that case multiple devices may share one RMRR entry.
>     This also is a damage between different VMs when we assign such devices to
>     different VMs.
>
> #4 Something like USB, is still restricted to current RMRR implementation. We
>     should work out this case.
>
> Design Overview
> ===============
>
> First of all we need to make sure all resources don't overlap RMRR. And then
> in case of shared ept, we can set these identity entries. And Certainly we will
> group all devices associated to one same RMRR entry, then make sure all group
> devices should be assigned to same VM.
>
> 1. Setup RMRR identity mapping
>
> current status:
>      * identity mapping only setup in non-shared ept case
>
> proposal:
>
> In non-shared ept case, IOMMU stuff always set those entries and RMRR is already
> marked reserved in host so its fine enough. But in shared ept case, we need to
> check any conflit, so we should follow up
>
>    - gfn space unoccupied
>          -> insert mapping: success.
>              gfn:_mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct, p2m_access_rw
>    - gfn space already occupied by 1:1 RMRR mapping
>          -> do nothing; success.
>    - gfn space already occupied by other mapping
>          -> fail.
>
> expectation:
>      * only devices w/ non-conflicting RMRR can be assigned
>      * fortunately this achieves the very initial intention to support IGD
>        pass-through on BDW
>      * provide last level protection in hypervisor to ensure a secure assignment
>
> 2. Check to reserve RMRR in guest physical level
>
> current status:
>      * Xen doesn't reserve RMRR in guest physical level
>
> proposal:
>      * Get RMRR info as necessary
>      * Then check all potential points to reserve or skip RMRR
>
> expectation:
>      * Make sure all guest resources don't overlap RMRR range.
>
> 2.1 Expose RMRR to user space
>
> current status:
>      * Xen always record RMRR info into one list, acpi_rmrr_units, while parsing
>        acpi. So we can retrieve these info by lookup that list.
>
> proposal:
>      * RMRR would be exposed by a new hypercall, which Jan already finished in
>        current version but just expose all RMRR info unconditionally.
>      * Furthermore we can expose RMRR on demand to diminish shrinking guest
>        RAM/MMIO space.
>      * So we will introduce a new parameter, 'rdm_forcecheck' and to collaborate
>        with SBDFs to control which RMRR should be exposed:
>
>          - We can set this parameter in .cfg file like,
>
>              rdm_forcecheck = 1 => Of course this should be 0 by default.
>
>          '1' means we should force check to reserve all ranges unconditionally.
>          and 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.
>
>          If 0, we just check those assigned pci devices. As you know we already
>          have such an existing hypercall to assign PCI devices, looks we can work
>          directly under this hypercall to get that necessary SBDF to sort which
>          RMRR should be handled. But obviously, we need to get these info before
>          we populate guest memory to make sure these RMRR ranges should be
>          excluded from guest memory. But unfortunately the memory populating
>          takes place before a device assignment, so we can't live on that
>          directly.
>
>          But as we discussed it just benefit that assigned case to reorder that
>          order, but not good to hotplug case. So we have to introduce a new
>          DOMCTL to pass that global parameter with SBDF at the same time.
>
>          For example, if we own these two RMRR entries,
>
>          [00:14.0]    RMRR region: base_addr ab80a000 end_address ab81dfff
>          [00:02.0]    RMRR region: base_addr ad000000 end_address af7fffff
>
>          If 'rdm_forcecheck = 1', any caller to that hypercall may get these two
>          entries. But if 'rdm_forcecheck = 0', and in .cfg file,
>
>          #1 'pci=[00:14.0, 00:02.0]' -> The caller still get these two entries.
>          #2 'pci=[00:02.0]' -> The caller just get one entry, 0xad000000:0xaf7fffff
>          #2 'pci=[00:14.0]' -> The caller just get one entry, 0xab80a000:0xab81dfff
>          #4 'pci=[others]' or no any pci configuration -> The caller get nothing.
>
>          And ultimately, if we expose any RMRR entry at gfn,
>
>          in non-shared ept case,
>
>          p2m table:  valid non-identity mapping, gfn:mfn != 1:1
>          VT-D table: no such a mapping until set identity mapping,
>                      gfn:_mfn(gfn) == 1:1 when we have a associated device
>                      assignment.
>          
>          in shared ept case,
>
>          p2m table\VT-D table:  always INVALID until set identity mapping,
>                                 gfn:_mfn(gfn) == 1:1 when we have a associated
>                                 device assignment.
>
>          But if we don't expose any RMRR entry,
>
>          in non-shared ept case,
>
>          p2m table:  valid non-identity mapping, gfn:mfn != 1:1
>          VT-D table: no such a mapping until set identity mapping,
>                      gfn:_mfn(gfn) == 1:1 when we have a associated device
>                      assignment.
>
>          in shared ept case,
>
>          p2m table\VT-D table:  If guest RAM already cover gfn, we have sunc a
>                                 valid non-identity mapping, gfn:mfn != 1:1, but
>                                 we can't set any identity mapping again then
>                                 that associated device can't be assigned
>                                 successfully. If not, we'll set identity mapping,
>                                 gfn:_mfn(gfn) == 1:1, to work well.
>
>   
> expectation:
>      * Provice a way to get necessary RMRR info.
>
> Note here that new DOMCTL is already finished but need to fix some code style
> issues.
>
> 2.2 Detect and avoid RMRR conflictions with guest RAM/MMIO
>
> current status:
>      * Currently Xen doesn't detect anything to avoid any conflict.
>
> proposal:
>      * We need to cover all points to check any conflict. Below lists places
>        where reserved region conflictions should be detected:
>
>          1>. libxc:setup_guest():modules_init()
>
>          There are some modules, like acpi_module and smbios_module. They may
>          occupy some ranges so we need to check if they're conflicting with
>          all ranges from that new hypercall above.
>
>          2>. libxc:setup_guest():xc_domain_populate_physmap()
>
>          There are two ways to exclude RMRR ranges here:
>              
>              #1 Before we populate guest RAM without any RMRR range from that
>                 new hypercall to skip RMRR ranges when populating guest RAM.
>              #2 In Xen we can fliter RMRR range while calling
>                 XENMEM_populate_physmap, its no change to libxc, but skip
>                 setting p2m entry for RMRR ranges in Xen hypervisor
>
>          But to compare #1, #2 is not better since Xen still allocate those
>          range, and we have to sync somewhere else in Xen. And #1 is cleaner
>          because #2 actually shrinks the available memory size to the guest.
>
>          3>. hvmloader:pci_setup()
>
>          Here we should populate guest MMIO excluding all ranges from that new
>          hypercall to detect RMRR conflictions for allocating PCI MMIO BAR.
>
>          4>. hvmloader:mem_hole_alloc()
>
>          Here we should populate mem holw excluding all ranges from that new
>          hypercall to detect RMRR conflictions for dynamic allocation in
>          hvmloader, e.g. as used for IGD opregion
>
>          5>. hvmloader:build_e820_table():
>
>          Finally we need let VM know that RMRR regions are reserved through e820
>          table
>
>      Its a little bit tricky to handle this inside hvmloader since as you know,
>      struct hvm_info_table is only a approach between libxc and hvmloader. But
>      however, making up all above places will bring some duplicated logic.
>      Especially between libxc and hvmloader, which skip same regions in guest
>      physical layer(one in populating guest RAM, the other in constructing e820)
>      But current design has some limitation to pass information between libxc and
>      hvmloader,
>
> struct hvm_info_table {
>      ...
>      /*
>       *  0x0 to page_to_phys(low_mem_pgend)-1:
>       *    RAM below 4GB (except for VGA hole 0xA0000-0xBFFFF)
>       */
>      uint32_t    low_mem_pgend;
>      ...
>      /*
>       *  0x100000000 to page_to_phys(high_mem_pgend)-1:
>       *    RAM above 4GB
>       */
>      uint32_t    high_mem_pgend;
>      ...
> }
>
>      nothing valuable is passed to hvmloader so we have to figure out a way to
>      handle those points in hvmloader. Currently,
>
>              #1 Reconstruct hvm_info_table{}
>
>              We can store all necessary RMRR info into hvm_info_table as well,
>              then we can pick them conveniently but oftentimes these RMRR
>              entries are scattered and the number is also undertimined, so its
>              a little bit ugly to do.
>
>              #2 Xenstore
>
>              We may store all necessary RMRR info as Xenstore then pick them in
>              hvmloader.
>
>              #3 A hypercall
>
>              We may have to call our new hypercall again to pick them, but
>              obviously this may introduce some duplicated codes.
>
>              #4 XENMEM_{set_,}memory_map pair of hypercalls
>              
>              As Jan commented it "could be used(and is readily available to be
>              extended that way, since for HVM domains XENMEM_set_memory_map
>              returns -EPERM at present). The only potentially problematic aspect
>              I can see with using it might be its limiting of the entry count to
>              E820MAX." So a preparation patch is required before RMRR, and
>              hvmloader still needs to query RMRR information.
>
> expectation:
>      * Cover all points to make sure guest doesn't occupt any RMRR range.
>
> 3. Group multiple devices sharing same RMRR entry
>
> current status:
>      * Xen doesn't distinguish if multiple devices share same RMRR entry. This
>        may lead a leak to corruption, e.g. Device A and device B share same entry
>        and then device A is assigned to domain A, device B is assigned to domain
>        B. So domain A can read something from that range, even rewrite
>        maliciously that range to corrupt device B inside domain B.
>
> proposal:
>      * We will group all devices by means of one same RMRR entry. Theoretically,
>        we should make sure all devices in one group are allowed to assign to one
>        VM. But in Xen side the hardware domain owns all devices at first, we
>        should unbound all group devies before assign one of group device. But its
>        hard to do such thing in current VT-d stuff. And actually its rare to have
>        the group device in real world so we just prevent assigning any group
>        device simply.
>      * We will introduce two field, gid, in struct, acpi_rmrr_unit:
>          gid: indicate if this device belongs a group.
>        Then when we add or attach device in iommu side, we will check this field
>        if we're assigning a group device then determine if we assign that.
>
>
> expectation:
>      * Make all device associated to one RMRR to be assigned same VM.
>
> 4. Handle in case of force accessing to RMRR regions
>
> proposal:
>      * Although we already reserve these ranges in guest e820 table, its
>        possible to access these ranges.
>        In non-shared ept case it will issue such EPT violation since we have no
>        p2m table actually. But its same to access other reserved range so just
>        live on Xen's default behavior. In shared-ept case guest can read or
>        write anything from this range, but such a leak or corruption just
>        happens inside same domain so this behavior is also same as a native
>        case, it should be fine.
>
> expectation:
>      * Don't broken normal RMRR usage.
>
> 5. Re-enable USB
>
> current status:
>      * Currently Xen doesn't allow USB passthrough.
>
> proposal:
>      * Cleanup some legacy codes related to RMRR to accommodate our RMRR
>        support.
>
> expectation:
>      * Make USB wor well after we handle RMRR properly.
>
> 6. Hotplug case
>
> current status:
>      * only work well in non-shared ept case or in case of shared ept & all
>        associated gfns are free.
>
> proposal:
>      * If user ensure there'll be a hotplug device in advace, 'rdm_forcecheck'
>        can be set to reserve all RMRR range as we describe above. Then any
>        device can be hotplugged successfully.
>      * If not, there are still two scenarios here:
>        in non-shared ept case it still work well as original;
>        in shared ept case, its just going a case of "1. Setup RMRR identity
>        mapping"
>          - gfn space unoccupied -> insert mapping: success.
>          - gfn space already occupied by 1:1 RMRR mapping -> do nothing; success.
>          - gfn space already occupied by other mapping -> fail.
>
> expectation:
>      * provide a way to let hotplug work in case of shared ept totally
>
> Open Issue
> ==========
>
> When other stuffs like ballon mechanism, to populate memory accessing RMRR
> range, or others like qemu, force map RMRR range, we may need to avoid such a
> possibility but we're not 100% sure this so just open this to double check.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 19 09:50:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09:50:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1uC2-0006wT-5X; Fri, 19 Dec 2014 09:49:54 +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 1Y1uC0-0006wE-6H
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 09:49:52 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	B4/E8-11608-FB4F3945; Fri, 19 Dec 2014 09:49:51 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-10.tower-31.messagelabs.com!1418982589!14544758!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27124 invoked from network); 19 Dec 2014 09:49:50 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 09:49:50 -0000
Received: by mail-wi0-f170.google.com with SMTP id bs8so4114931wib.3
	for <xen-devel@lists.xen.org>; Fri, 19 Dec 2014 01:49: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=ECMjA49RSk20UiUpGuut4QhvSckqRSuxJJRvgma7dRE=;
	b=T9XNv5IglTD4T//HbxScX7KGEVaWuwPtoItm+tDn39fe3fhNLw1B+PtEe8DUY4Qg+Q
	kp3K0kLJ2jm83LAax7aq0itso+55nOrzR4jZ4xjlUqfhsnAAuGSXHRtg516OA4sW8dJZ
	Ldz12gmq+/1WEi4/z2Osd7znKVWy0TKi6oGamMipKEW4MFTTEYnE5t7UOZeM90fHo5dH
	9qHxRL8+ACwA95ElLgQwg+EJwW83vpVmPUVKneppBbAPKGXcfzi7PsJqK81jYmVISAdG
	ofx1OdHeWBFyxvgjhjF2Nb/Zj3wiLVQ0tcZrex1wYzA3/RWkaFvdm5mBPHuuRDOAlGUN
	igcA==
X-Gm-Message-State: ALoCoQlUpNfkyXvyIU2H4APvk2cRypl89ZLW3lZXaD6EUzJBiYtM7rM+NxA4HJBt7Ykrs9mC0g89
X-Received: by 10.180.11.98 with SMTP id p2mr4201475wib.22.1418982589477;
	Fri, 19 Dec 2014 01:49:49 -0800 (PST)
Received: from [192.180.180.71]
	(static-business-42-20-205-109.rdsl.tecnologicawifi.net.
	[109.205.20.42])
	by mx.google.com with ESMTPSA id l9sm1685797wic.21.2014.12.19.01.49.47
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 19 Dec 2014 01:49:48 -0800 (PST)
Message-ID: <5493F4C7.6020503@m2r.biz>
Date: Fri, 19 Dec 2014 10:49:59 +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.3.0
MIME-Version: 1.0
To: Tiejun Chen <tiejun.chen@intel.com>, JBeulich@suse.com, 
	konrad.wilk@oracle.com, tim@xen.org, kevin.tian@intel.com, 
	yang.z.zhang@intel.com, stefano.stabellini@eu.citrix.com, 
	ian.campbell@citrix.com, ian.jackson@eu.citrix.com, wei.liu2@citrix.com
References: <1418952066-21064-1-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1418952066-21064-1-git-send-email-tiejun.chen@intel.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] RMRR Fix Design 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-Transfer-Encoding: 7bit
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/12/2014 02:21, Tiejun Chen ha scritto:
>                      RMRR Fix Design for Xen
>
> This design is a goal to fix RMRR for Xen. It includes four sectors as
> follows:
>
>      * Background
>      * What is RMRR
>      * Current RMRR Issues
>      * Design Overview
>
> We hope this can help us to understand current problem then figure out a
> clean and better solution everyone can agree now to go forward.
>
> Background
> ==========
>
> We first identified this RMRR defect when trying to pass-through IGD device,
> which can be simply fixed by adding an identity mapping in case of shared
> EPT table. However along with the community discussion, it boiled down to
> a more general RMRR problem, i.e. the identity mapping is brute-added
> in hypervisor, w/o considering whether conflicting with an existing guest
> PFN ranges. As a general solution we need invent a new mechanism so
> reserved ranges allocated by hypervisor can be exported to the user space
> toolstack and hvmloader, so conflict can be detected when constructing
> guest PFN layout, with best-effort avoidance policies to further help.
>
> What is RMRR
> ============
>
> RMRR is a acronym for Reserved Memory Region Reporting.
>
> BIOS may report each such reserved memory region through the RMRR structures,
> along with the devices that requires access to the specified reserved memory
> region. Reserved memory ranges that are either not DMA targets, or memory
> ranges that may be target of BIOS initiated DMA only during pre-boot phase
> (such as from a boot disk drive) must not be included in the reserved memory
> region reporting. The base address of each RMRR region must be 4KB aligned and
> the size must be an integer multiple of 4KB. BIOS must report the RMRR reported
> memory addresses as reserved in the system memory map returned through methods
> suchas INT15, EFI GetMemoryMap etc. The reserved memory region reporting
> structures are optional. If there are no RMRR structures, the system software
> concludes that the platform does not have any reserved memory ranges that are
> DMA targets.
>
> The RMRR regions are expected to be used for legacy usages (such as USB, UMA
> Graphics, etc.) requiring reserved memory. Platform designers shouldavoid or
> limit use of reserved memory regions since these require system software to
> create holes in the DMA virtual address range available to system software and
> its drivers.
>
> The following is grabbed from my BDW:
>
> (XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
> (XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ab80a000 end_address ab81dfff
> (XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
> (XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ad000000 end_address af7fffff
>
> Here USB occupies 0xab80a000:0xab81dfff, IGD owns 0xad000000:0xaf7fffff.
>
> Note there are zero or more Reserved Memory Region Reporting (RMRR) in one given
> platform. And multiple devices may share one RMRR range. Additionally RMRR can
> go anyplace.
>
> Current RMRR Issues
> ===================
>
> #1 RMRR may conflict RAM, mmio or other ranges in Guest physical level.

Sorry if my question is not inherent, I don't have good knowledge about 
it, xen domUs require that all memory regions is correctly defined in 
hvmloader or do them automatically and correct in any emulated devices 
assigned to domUs?
I'm unable to have qxl vga working in linux domUs and unable to found 
the problem for now, I saw a memory warning in system logs of domU with 
qxl which makes me think that perhaps the differences in memory regions 
of qxl are not considered properly in hvmloader.
The warning I found in one Fedora domU with qxl is:
> ioremap error for 0xfc001000-0xfc002000, requested 0x10, got 0x0 
Here a post about with logs compared also with stdvga tests and kvm 
(with qxl full working) test:
http://lists.xen.org/archives/html/xen-devel/2013-10/msg00016.html
Here the qxl support for libxl patch updated to latest xen if someone 
want fast try it:
https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe

Can someone tell me is can be a hvmloader memory problem or this is not 
related?

Thanks for any reply and sorry for my bad english.

>
> #2 Xen doesn't create RMRR mapping in case of shared ept, then the assigned
>     device can't work well.
>
> #3 Xen doesn't consider that case multiple devices may share one RMRR entry.
>     This also is a damage between different VMs when we assign such devices to
>     different VMs.
>
> #4 Something like USB, is still restricted to current RMRR implementation. We
>     should work out this case.
>
> Design Overview
> ===============
>
> First of all we need to make sure all resources don't overlap RMRR. And then
> in case of shared ept, we can set these identity entries. And Certainly we will
> group all devices associated to one same RMRR entry, then make sure all group
> devices should be assigned to same VM.
>
> 1. Setup RMRR identity mapping
>
> current status:
>      * identity mapping only setup in non-shared ept case
>
> proposal:
>
> In non-shared ept case, IOMMU stuff always set those entries and RMRR is already
> marked reserved in host so its fine enough. But in shared ept case, we need to
> check any conflit, so we should follow up
>
>    - gfn space unoccupied
>          -> insert mapping: success.
>              gfn:_mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct, p2m_access_rw
>    - gfn space already occupied by 1:1 RMRR mapping
>          -> do nothing; success.
>    - gfn space already occupied by other mapping
>          -> fail.
>
> expectation:
>      * only devices w/ non-conflicting RMRR can be assigned
>      * fortunately this achieves the very initial intention to support IGD
>        pass-through on BDW
>      * provide last level protection in hypervisor to ensure a secure assignment
>
> 2. Check to reserve RMRR in guest physical level
>
> current status:
>      * Xen doesn't reserve RMRR in guest physical level
>
> proposal:
>      * Get RMRR info as necessary
>      * Then check all potential points to reserve or skip RMRR
>
> expectation:
>      * Make sure all guest resources don't overlap RMRR range.
>
> 2.1 Expose RMRR to user space
>
> current status:
>      * Xen always record RMRR info into one list, acpi_rmrr_units, while parsing
>        acpi. So we can retrieve these info by lookup that list.
>
> proposal:
>      * RMRR would be exposed by a new hypercall, which Jan already finished in
>        current version but just expose all RMRR info unconditionally.
>      * Furthermore we can expose RMRR on demand to diminish shrinking guest
>        RAM/MMIO space.
>      * So we will introduce a new parameter, 'rdm_forcecheck' and to collaborate
>        with SBDFs to control which RMRR should be exposed:
>
>          - We can set this parameter in .cfg file like,
>
>              rdm_forcecheck = 1 => Of course this should be 0 by default.
>
>          '1' means we should force check to reserve all ranges unconditionally.
>          and 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.
>
>          If 0, we just check those assigned pci devices. As you know we already
>          have such an existing hypercall to assign PCI devices, looks we can work
>          directly under this hypercall to get that necessary SBDF to sort which
>          RMRR should be handled. But obviously, we need to get these info before
>          we populate guest memory to make sure these RMRR ranges should be
>          excluded from guest memory. But unfortunately the memory populating
>          takes place before a device assignment, so we can't live on that
>          directly.
>
>          But as we discussed it just benefit that assigned case to reorder that
>          order, but not good to hotplug case. So we have to introduce a new
>          DOMCTL to pass that global parameter with SBDF at the same time.
>
>          For example, if we own these two RMRR entries,
>
>          [00:14.0]    RMRR region: base_addr ab80a000 end_address ab81dfff
>          [00:02.0]    RMRR region: base_addr ad000000 end_address af7fffff
>
>          If 'rdm_forcecheck = 1', any caller to that hypercall may get these two
>          entries. But if 'rdm_forcecheck = 0', and in .cfg file,
>
>          #1 'pci=[00:14.0, 00:02.0]' -> The caller still get these two entries.
>          #2 'pci=[00:02.0]' -> The caller just get one entry, 0xad000000:0xaf7fffff
>          #2 'pci=[00:14.0]' -> The caller just get one entry, 0xab80a000:0xab81dfff
>          #4 'pci=[others]' or no any pci configuration -> The caller get nothing.
>
>          And ultimately, if we expose any RMRR entry at gfn,
>
>          in non-shared ept case,
>
>          p2m table:  valid non-identity mapping, gfn:mfn != 1:1
>          VT-D table: no such a mapping until set identity mapping,
>                      gfn:_mfn(gfn) == 1:1 when we have a associated device
>                      assignment.
>          
>          in shared ept case,
>
>          p2m table\VT-D table:  always INVALID until set identity mapping,
>                                 gfn:_mfn(gfn) == 1:1 when we have a associated
>                                 device assignment.
>
>          But if we don't expose any RMRR entry,
>
>          in non-shared ept case,
>
>          p2m table:  valid non-identity mapping, gfn:mfn != 1:1
>          VT-D table: no such a mapping until set identity mapping,
>                      gfn:_mfn(gfn) == 1:1 when we have a associated device
>                      assignment.
>
>          in shared ept case,
>
>          p2m table\VT-D table:  If guest RAM already cover gfn, we have sunc a
>                                 valid non-identity mapping, gfn:mfn != 1:1, but
>                                 we can't set any identity mapping again then
>                                 that associated device can't be assigned
>                                 successfully. If not, we'll set identity mapping,
>                                 gfn:_mfn(gfn) == 1:1, to work well.
>
>   
> expectation:
>      * Provice a way to get necessary RMRR info.
>
> Note here that new DOMCTL is already finished but need to fix some code style
> issues.
>
> 2.2 Detect and avoid RMRR conflictions with guest RAM/MMIO
>
> current status:
>      * Currently Xen doesn't detect anything to avoid any conflict.
>
> proposal:
>      * We need to cover all points to check any conflict. Below lists places
>        where reserved region conflictions should be detected:
>
>          1>. libxc:setup_guest():modules_init()
>
>          There are some modules, like acpi_module and smbios_module. They may
>          occupy some ranges so we need to check if they're conflicting with
>          all ranges from that new hypercall above.
>
>          2>. libxc:setup_guest():xc_domain_populate_physmap()
>
>          There are two ways to exclude RMRR ranges here:
>              
>              #1 Before we populate guest RAM without any RMRR range from that
>                 new hypercall to skip RMRR ranges when populating guest RAM.
>              #2 In Xen we can fliter RMRR range while calling
>                 XENMEM_populate_physmap, its no change to libxc, but skip
>                 setting p2m entry for RMRR ranges in Xen hypervisor
>
>          But to compare #1, #2 is not better since Xen still allocate those
>          range, and we have to sync somewhere else in Xen. And #1 is cleaner
>          because #2 actually shrinks the available memory size to the guest.
>
>          3>. hvmloader:pci_setup()
>
>          Here we should populate guest MMIO excluding all ranges from that new
>          hypercall to detect RMRR conflictions for allocating PCI MMIO BAR.
>
>          4>. hvmloader:mem_hole_alloc()
>
>          Here we should populate mem holw excluding all ranges from that new
>          hypercall to detect RMRR conflictions for dynamic allocation in
>          hvmloader, e.g. as used for IGD opregion
>
>          5>. hvmloader:build_e820_table():
>
>          Finally we need let VM know that RMRR regions are reserved through e820
>          table
>
>      Its a little bit tricky to handle this inside hvmloader since as you know,
>      struct hvm_info_table is only a approach between libxc and hvmloader. But
>      however, making up all above places will bring some duplicated logic.
>      Especially between libxc and hvmloader, which skip same regions in guest
>      physical layer(one in populating guest RAM, the other in constructing e820)
>      But current design has some limitation to pass information between libxc and
>      hvmloader,
>
> struct hvm_info_table {
>      ...
>      /*
>       *  0x0 to page_to_phys(low_mem_pgend)-1:
>       *    RAM below 4GB (except for VGA hole 0xA0000-0xBFFFF)
>       */
>      uint32_t    low_mem_pgend;
>      ...
>      /*
>       *  0x100000000 to page_to_phys(high_mem_pgend)-1:
>       *    RAM above 4GB
>       */
>      uint32_t    high_mem_pgend;
>      ...
> }
>
>      nothing valuable is passed to hvmloader so we have to figure out a way to
>      handle those points in hvmloader. Currently,
>
>              #1 Reconstruct hvm_info_table{}
>
>              We can store all necessary RMRR info into hvm_info_table as well,
>              then we can pick them conveniently but oftentimes these RMRR
>              entries are scattered and the number is also undertimined, so its
>              a little bit ugly to do.
>
>              #2 Xenstore
>
>              We may store all necessary RMRR info as Xenstore then pick them in
>              hvmloader.
>
>              #3 A hypercall
>
>              We may have to call our new hypercall again to pick them, but
>              obviously this may introduce some duplicated codes.
>
>              #4 XENMEM_{set_,}memory_map pair of hypercalls
>              
>              As Jan commented it "could be used(and is readily available to be
>              extended that way, since for HVM domains XENMEM_set_memory_map
>              returns -EPERM at present). The only potentially problematic aspect
>              I can see with using it might be its limiting of the entry count to
>              E820MAX." So a preparation patch is required before RMRR, and
>              hvmloader still needs to query RMRR information.
>
> expectation:
>      * Cover all points to make sure guest doesn't occupt any RMRR range.
>
> 3. Group multiple devices sharing same RMRR entry
>
> current status:
>      * Xen doesn't distinguish if multiple devices share same RMRR entry. This
>        may lead a leak to corruption, e.g. Device A and device B share same entry
>        and then device A is assigned to domain A, device B is assigned to domain
>        B. So domain A can read something from that range, even rewrite
>        maliciously that range to corrupt device B inside domain B.
>
> proposal:
>      * We will group all devices by means of one same RMRR entry. Theoretically,
>        we should make sure all devices in one group are allowed to assign to one
>        VM. But in Xen side the hardware domain owns all devices at first, we
>        should unbound all group devies before assign one of group device. But its
>        hard to do such thing in current VT-d stuff. And actually its rare to have
>        the group device in real world so we just prevent assigning any group
>        device simply.
>      * We will introduce two field, gid, in struct, acpi_rmrr_unit:
>          gid: indicate if this device belongs a group.
>        Then when we add or attach device in iommu side, we will check this field
>        if we're assigning a group device then determine if we assign that.
>
>
> expectation:
>      * Make all device associated to one RMRR to be assigned same VM.
>
> 4. Handle in case of force accessing to RMRR regions
>
> proposal:
>      * Although we already reserve these ranges in guest e820 table, its
>        possible to access these ranges.
>        In non-shared ept case it will issue such EPT violation since we have no
>        p2m table actually. But its same to access other reserved range so just
>        live on Xen's default behavior. In shared-ept case guest can read or
>        write anything from this range, but such a leak or corruption just
>        happens inside same domain so this behavior is also same as a native
>        case, it should be fine.
>
> expectation:
>      * Don't broken normal RMRR usage.
>
> 5. Re-enable USB
>
> current status:
>      * Currently Xen doesn't allow USB passthrough.
>
> proposal:
>      * Cleanup some legacy codes related to RMRR to accommodate our RMRR
>        support.
>
> expectation:
>      * Make USB wor well after we handle RMRR properly.
>
> 6. Hotplug case
>
> current status:
>      * only work well in non-shared ept case or in case of shared ept & all
>        associated gfns are free.
>
> proposal:
>      * If user ensure there'll be a hotplug device in advace, 'rdm_forcecheck'
>        can be set to reserve all RMRR range as we describe above. Then any
>        device can be hotplugged successfully.
>      * If not, there are still two scenarios here:
>        in non-shared ept case it still work well as original;
>        in shared ept case, its just going a case of "1. Setup RMRR identity
>        mapping"
>          - gfn space unoccupied -> insert mapping: success.
>          - gfn space already occupied by 1:1 RMRR mapping -> do nothing; success.
>          - gfn space already occupied by other mapping -> fail.
>
> expectation:
>      * provide a way to let hotplug work in case of shared ept totally
>
> Open Issue
> ==========
>
> When other stuffs like ballon mechanism, to populate memory accessing RMRR
> range, or others like qemu, force map RMRR range, we may need to avoid such a
> possibility but we're not 100% sure this so just open this to double check.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 19 09:57:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09: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 1Y1uIk-0007TA-Gl; Fri, 19 Dec 2014 09:56:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <patel_mp@yahoo.co.in>) id 1Y1uIj-0007T5-NG
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 09:56:49 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	18/B4-31453-166F3945; Fri, 19 Dec 2014 09:56:49 +0000
X-Env-Sender: patel_mp@yahoo.co.in
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418983006!14305477!1
X-Originating-IP: [98.138.229.70]
X-SpamReason: No, hits=2.5 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	MISSING_SUBJECT
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11403 invoked from network); 19 Dec 2014 09:56:48 -0000
Received: from nm33-vm6.bullet.mail.ne1.yahoo.com (HELO
	nm33-vm6.bullet.mail.ne1.yahoo.com) (98.138.229.70)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 09:56:48 -0000
Received: from [127.0.0.1] by nm33.bullet.mail.ne1.yahoo.com with NNFMP;
	19 Dec 2014 09:56:46 -0000
Received: from [98.138.101.129] by nm33.bullet.mail.ne1.yahoo.com with NNFMP;
	19 Dec 2014 09:54:02 -0000
Received: from [106.10.166.119] by tm17.bullet.mail.ne1.yahoo.com with NNFMP;
	19 Dec 2014 09:53:56 -0000
Received: from [106.10.150.25] by tm8.bullet.mail.sg3.yahoo.com with NNFMP;
	19 Dec 2014 09:53:56 -0000
Received: from [127.0.0.1] by omp1026.mail.sg3.yahoo.com with NNFMP;
	19 Dec 2014 09:53:56 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 410629.52187.bm@omp1026.mail.sg3.yahoo.com
Received: (qmail 32861 invoked by uid 60001); 19 Dec 2014 09:53:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024;
	t=1418982836; bh=Kha3/V/IBIKuBcgl3OK5Lx2bTFjuU9A1vK6xZJpI/KI=;
	h=Message-ID:Date:From:Reply-To:To:MIME-Version:Content-Type;
	b=JPDi0hg52lx0LNK8GeripI+Iq8RhAqd7Yp1tYoPzkU3oWtZCZQNWqKpxxgBtQdBFVZXuky98CzX2m6O/5AqbE7NCWO+YA0bH52GigrEDwWsFpIk3oc22DYMYspqZt5ZCTmCVkvsc0BafwCUXlOzi0pHQeWnppfD4Nm7++aV1w5c=
X-YMail-OSG: 5wNcEVQVM1nunyeWOJzwr6qTKurDetRjPAgX6iLh2i2fIX0
	1.vfvU.Pmt.sVs0K2L2l0l1jmDlfnV_1T3JzELPU_.t5OdwVbTRPg.f2QD.C
	3_jxNULGzVPtsgDrub69PiPpPuVgWXgUYozLMUCLkgyjBJrcREp_ZC.l01zJ
	_jHxZTtnTRP9QcrQ4fDx3gz3L0IV8heurRL_phISXjKgi.70lSzxJeNurMfP
	QJXEPz9DNyneLRaxTCkVSGq53DNtDPP6.LkxNYrNsR3qkjdVp.XX5W2ArRvJ
	815Fu.RbsflRM46fiJ4OcyHbqyd6ONXUGMLwuOm1ji_0J9U4Z5u5DR8ByBTL
	yb_xyinBhgayXJhc8euIFpOj7v8ODvFUzSrwQR0328wuUvbugQpxbnwagVXB
	q.WGT.AWoM1a53JeWn3YS2B3bnG0GhIWJf5ZwdgRinrWQwRgqz8OXrLVD2Y2
	APoe77XzN119H4MtYidXpfx5PHIpeAX1hfqzLyabJfqFxX5tO0CH_UNrKUzC
	tUG2e5zazCx9NCsv4.NtHJiZbNbmB.WGV7nZ3.680TwQ7ahTKdJGu3b40o9R
	z5HpygU5f4ib3aBuWt_jKuw--
Received: from [202.129.240.131] by web190604.mail.sg3.yahoo.com via HTTP;
	Fri, 19 Dec 2014 17:53:56 SGT
X-Rocket-MIMEInfo: 002.001,
	aSBnb3QgZGFpbHkgcGF0Y2ggZW1haWxzIGZyb20geGVuLWRldmVsIGJ1dCBpIGRvbid0IG5lZWQgb24gdGhpcyBlbWFpbCBhZGRyZXNzIHNvIGhvdyB0byBkZWFjdGl2YXRlIGl0IHBsZWFzZSB0ZWxsIG1lATABAQEB
X-Mailer: YahooMailWebService/0.8.203.740
Message-ID: <1418982836.56254.YahooMailNeo@web190604.mail.sg3.yahoo.com>
Date: Fri, 19 Dec 2014 17:53:56 +0800
From: Minalkumar Patel <patel_mp@yahoo.co.in>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Minalkumar Patel <patel_mp@yahoo.co.in>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0671602667937206860=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0671602667937206860==
Content-Type: multipart/alternative; boundary="806834454-340994797-1418982836=:56254"

--806834454-340994797-1418982836=:56254
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

i got daily patch emails from xen-devel but i don't need on this email addr=
ess so how to deactivate it please tell me
--806834454-340994797-1418982836=:56254
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;fo=
nt-size:12px"><div><span>i got daily patch emails from xen-devel but i don'=
t need on this email address so how to deactivate it please tell me<br></sp=
an></div><div>&nbsp;</div><div><br></div></div></body></html>
--806834454-340994797-1418982836=:56254--


--===============0671602667937206860==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0671602667937206860==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 09:57:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 09: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 1Y1uIk-0007TA-Gl; Fri, 19 Dec 2014 09:56:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <patel_mp@yahoo.co.in>) id 1Y1uIj-0007T5-NG
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 09:56:49 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	18/B4-31453-166F3945; Fri, 19 Dec 2014 09:56:49 +0000
X-Env-Sender: patel_mp@yahoo.co.in
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418983006!14305477!1
X-Originating-IP: [98.138.229.70]
X-SpamReason: No, hits=2.5 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	MISSING_SUBJECT
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11403 invoked from network); 19 Dec 2014 09:56:48 -0000
Received: from nm33-vm6.bullet.mail.ne1.yahoo.com (HELO
	nm33-vm6.bullet.mail.ne1.yahoo.com) (98.138.229.70)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 09:56:48 -0000
Received: from [127.0.0.1] by nm33.bullet.mail.ne1.yahoo.com with NNFMP;
	19 Dec 2014 09:56:46 -0000
Received: from [98.138.101.129] by nm33.bullet.mail.ne1.yahoo.com with NNFMP;
	19 Dec 2014 09:54:02 -0000
Received: from [106.10.166.119] by tm17.bullet.mail.ne1.yahoo.com with NNFMP;
	19 Dec 2014 09:53:56 -0000
Received: from [106.10.150.25] by tm8.bullet.mail.sg3.yahoo.com with NNFMP;
	19 Dec 2014 09:53:56 -0000
Received: from [127.0.0.1] by omp1026.mail.sg3.yahoo.com with NNFMP;
	19 Dec 2014 09:53:56 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 410629.52187.bm@omp1026.mail.sg3.yahoo.com
Received: (qmail 32861 invoked by uid 60001); 19 Dec 2014 09:53:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024;
	t=1418982836; bh=Kha3/V/IBIKuBcgl3OK5Lx2bTFjuU9A1vK6xZJpI/KI=;
	h=Message-ID:Date:From:Reply-To:To:MIME-Version:Content-Type;
	b=JPDi0hg52lx0LNK8GeripI+Iq8RhAqd7Yp1tYoPzkU3oWtZCZQNWqKpxxgBtQdBFVZXuky98CzX2m6O/5AqbE7NCWO+YA0bH52GigrEDwWsFpIk3oc22DYMYspqZt5ZCTmCVkvsc0BafwCUXlOzi0pHQeWnppfD4Nm7++aV1w5c=
X-YMail-OSG: 5wNcEVQVM1nunyeWOJzwr6qTKurDetRjPAgX6iLh2i2fIX0
	1.vfvU.Pmt.sVs0K2L2l0l1jmDlfnV_1T3JzELPU_.t5OdwVbTRPg.f2QD.C
	3_jxNULGzVPtsgDrub69PiPpPuVgWXgUYozLMUCLkgyjBJrcREp_ZC.l01zJ
	_jHxZTtnTRP9QcrQ4fDx3gz3L0IV8heurRL_phISXjKgi.70lSzxJeNurMfP
	QJXEPz9DNyneLRaxTCkVSGq53DNtDPP6.LkxNYrNsR3qkjdVp.XX5W2ArRvJ
	815Fu.RbsflRM46fiJ4OcyHbqyd6ONXUGMLwuOm1ji_0J9U4Z5u5DR8ByBTL
	yb_xyinBhgayXJhc8euIFpOj7v8ODvFUzSrwQR0328wuUvbugQpxbnwagVXB
	q.WGT.AWoM1a53JeWn3YS2B3bnG0GhIWJf5ZwdgRinrWQwRgqz8OXrLVD2Y2
	APoe77XzN119H4MtYidXpfx5PHIpeAX1hfqzLyabJfqFxX5tO0CH_UNrKUzC
	tUG2e5zazCx9NCsv4.NtHJiZbNbmB.WGV7nZ3.680TwQ7ahTKdJGu3b40o9R
	z5HpygU5f4ib3aBuWt_jKuw--
Received: from [202.129.240.131] by web190604.mail.sg3.yahoo.com via HTTP;
	Fri, 19 Dec 2014 17:53:56 SGT
X-Rocket-MIMEInfo: 002.001,
	aSBnb3QgZGFpbHkgcGF0Y2ggZW1haWxzIGZyb20geGVuLWRldmVsIGJ1dCBpIGRvbid0IG5lZWQgb24gdGhpcyBlbWFpbCBhZGRyZXNzIHNvIGhvdyB0byBkZWFjdGl2YXRlIGl0IHBsZWFzZSB0ZWxsIG1lATABAQEB
X-Mailer: YahooMailWebService/0.8.203.740
Message-ID: <1418982836.56254.YahooMailNeo@web190604.mail.sg3.yahoo.com>
Date: Fri, 19 Dec 2014 17:53:56 +0800
From: Minalkumar Patel <patel_mp@yahoo.co.in>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Minalkumar Patel <patel_mp@yahoo.co.in>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0671602667937206860=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0671602667937206860==
Content-Type: multipart/alternative; boundary="806834454-340994797-1418982836=:56254"

--806834454-340994797-1418982836=:56254
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

i got daily patch emails from xen-devel but i don't need on this email addr=
ess so how to deactivate it please tell me
--806834454-340994797-1418982836=:56254
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;fo=
nt-size:12px"><div><span>i got daily patch emails from xen-devel but i don'=
t need on this email address so how to deactivate it please tell me<br></sp=
an></div><div>&nbsp;</div><div><br></div></div></body></html>
--806834454-340994797-1418982836=:56254--


--===============0671602667937206860==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0671602667937206860==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 10:00:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10: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 1Y1uLs-0007eA-4S; Fri, 19 Dec 2014 10:00:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1uLr-0007d2-0S
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:00:03 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	5E/7C-02696-227F3945; Fri, 19 Dec 2014 10:00:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418983200!16146723!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 1438 invoked from network); 19 Dec 2014 10:00:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 10:00:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206172506"
Message-ID: <1418983198.20028.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Minalkumar Patel <patel_mp@yahoo.co.in>
Date: Fri, 19 Dec 2014 09:59:58 +0000
In-Reply-To: <1418982836.56254.YahooMailNeo@web190604.mail.sg3.yahoo.com>
References: <1418982836.56254.YahooMailNeo@web190604.mail.sg3.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-19 at 17:53 +0800, Minalkumar Patel wrote:
> i got daily patch emails from xen-devel but i don't need on this email
> address so how to deactivate it please tell me

Please visit http://lists.xen.org/cgi-bin/mailman/options/xen-devel

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 10:00:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10: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 1Y1uLs-0007eA-4S; Fri, 19 Dec 2014 10:00:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1uLr-0007d2-0S
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:00:03 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	5E/7C-02696-227F3945; Fri, 19 Dec 2014 10:00:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1418983200!16146723!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 1438 invoked from network); 19 Dec 2014 10:00:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 10:00:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206172506"
Message-ID: <1418983198.20028.3.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Minalkumar Patel <patel_mp@yahoo.co.in>
Date: Fri, 19 Dec 2014 09:59:58 +0000
In-Reply-To: <1418982836.56254.YahooMailNeo@web190604.mail.sg3.yahoo.com>
References: <1418982836.56254.YahooMailNeo@web190604.mail.sg3.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-19 at 17:53 +0800, Minalkumar Patel wrote:
> i got daily patch emails from xen-devel but i don't need on this email
> address so how to deactivate it please tell me

Please visit http://lists.xen.org/cgi-bin/mailman/options/xen-devel

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 10:06:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10:06:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1uRR-00086o-1t; Fri, 19 Dec 2014 10:05: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 1Y1uRP-00086j-Os
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:05:47 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	A2/C7-11581-B78F3945; Fri, 19 Dec 2014 10:05:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418983544!14308377!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 27889 invoked from network); 19 Dec 2014 10:05:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 10:05:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206174025"
Message-ID: <1418983542.20028.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Peter Kay <syllopsium@syllopsium.co.uk>
Date: Fri, 19 Dec 2014 10:05:42 +0000
In-Reply-To: <CAN4Onoho_BKS48ECqXf=wF=MMLCah80yGZyEmm1O7G6fDEQtHA@mail.gmail.com>
References: <CAN4Onoho_BKS48ECqXf=wF=MMLCah80yGZyEmm1O7G6fDEQtHA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Parallel make 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 Thu, 2014-12-18 at 22:36 +0000, Peter Kay wrote:
> Is parallel make supported for xen? If I compile 4.5 rc4 (although the
> error exists with many other prior releases too) with make -j4 world
> it fails part way through with an error 2. This does not occur with a
> straight 'make world'

It is expected to work in general, I build with -j12 all the time. There
are some subdirs which enforce serialised build for various reasons,
perhaps there is one more we've not spotted or perhaps there is just a
bug in the Makefiles somewhere.

Please post your build logs showing the error.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 10:06:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10:06:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1uRR-00086o-1t; Fri, 19 Dec 2014 10:05: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 1Y1uRP-00086j-Os
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:05:47 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	A2/C7-11581-B78F3945; Fri, 19 Dec 2014 10:05:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1418983544!14308377!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 27889 invoked from network); 19 Dec 2014 10:05:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 10:05:46 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206174025"
Message-ID: <1418983542.20028.5.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Peter Kay <syllopsium@syllopsium.co.uk>
Date: Fri, 19 Dec 2014 10:05:42 +0000
In-Reply-To: <CAN4Onoho_BKS48ECqXf=wF=MMLCah80yGZyEmm1O7G6fDEQtHA@mail.gmail.com>
References: <CAN4Onoho_BKS48ECqXf=wF=MMLCah80yGZyEmm1O7G6fDEQtHA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Parallel make 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 Thu, 2014-12-18 at 22:36 +0000, Peter Kay wrote:
> Is parallel make supported for xen? If I compile 4.5 rc4 (although the
> error exists with many other prior releases too) with make -j4 world
> it fails part way through with an error 2. This does not occur with a
> straight 'make world'

It is expected to work in general, I build with -j12 all the time. There
are some subdirs which enforce serialised build for various reasons,
perhaps there is one more we've not spotted or perhaps there is just a
bug in the Makefiles somewhere.

Please post your build logs showing the error.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 10:16:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10:16:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ubF-0000JW-U2; Fri, 19 Dec 2014 10:15:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <akorzan@gmail.com>) id 1Y1ubD-0000JP-Ii
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:15:55 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	15/7A-24859-ADAF3945; Fri, 19 Dec 2014 10:15:54 +0000
X-Env-Sender: akorzan@gmail.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418984152!14593325!1
X-Originating-IP: [209.85.213.54]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28102 invoked from network); 19 Dec 2014 10:15:53 -0000
Received: from mail-yh0-f54.google.com (HELO mail-yh0-f54.google.com)
	(209.85.213.54)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 10:15:53 -0000
Received: by mail-yh0-f54.google.com with SMTP id 29so249831yhl.27
	for <xen-devel@lists.xen.org>; Fri, 19 Dec 2014 02:15:51 -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
	:message-id:references:to;
	bh=1Odg0ztA2T/ds+b8yaE3rhkWDsjtmIfKgvts7lBjAb8=;
	b=ELgcIHx0E4DrMzB0YKz/J6hT7EcUmRms0JVw5vRvxe6idDtZgm3NwNeZb2fXQtjj/G
	riCeKd0ReRR87TufMhGihDmkLCsx2oNZ4cmvlNB/20SHz+rlflcqXCGaT2eOzgLoOq17
	8h0chvZKnj4CXjSZdE4xdV9vUySkk3eo+twbUYB0kYcWnJ6KYFllOnKAd6QKBfpusQ5F
	oYgttBlVVra9/sjOAm5lRF5hh4pll/9mXhxzpZb9Y6Kj2EeiCxu/++a6Gb6zSQo7ccXc
	A4E7ufu6QtTFasW3h1AOaAoKznhnoCa6rvYvOW6cgGRwSwFIDHENwNOodmB1JhfV6N7M
	yqSQ==
X-Received: by 10.170.144.8 with SMTP id l8mr6452927ykc.56.1418984151652;
	Fri, 19 Dec 2014 02:15:51 -0800 (PST)
Received: from [192.168.1.12] (pool-72-83-187-210.washdc.fios.verizon.net.
	[72.83.187.210])
	by mx.google.com with ESMTPSA id 21sm5618652yhj.18.2014.12.19.02.15.50
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 19 Dec 2014 02:15:50 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Anthony Korzan <akorzan@gmail.com>
In-Reply-To: <549388F6.9000108@cn.fujitsu.com>
Date: Fri, 19 Dec 2014 05:15:48 -0500
Message-Id: <6EF2F911-C0B4-441D-A25A-BD154832350E@gmail.com>
References: <788CC804-7FC8-40C4-B17B-E02CDB7F2683@gmail.com>
	<549388F6.9000108@cn.fujitsu.com>
To: Hongyang Yang <yanghy@cn.fujitsu.com>
X-Mailer: Apple Mail (2.1878.6)
Cc: rshriram@cs.ubc.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen 4.5-rc] remus-drbd incompatible with Linux
	3.6+ 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: multipart/mixed; boundary="===============5247075782572141257=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5247075782572141257==
Content-Type: multipart/alternative; boundary="Apple-Mail=_91297C5E-24AC-40D8-987A-1848F67EA5CC"


--Apple-Mail=_91297C5E-24AC-40D8-987A-1848F67EA5CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thank you for your response,

I compiled Linux 3.0.101, sch_plug, and reinstalled remus-drbd.  I still =
receive the same error when starting remus:
> xc: error: rdexact failed (select returned 0): Internal error
> xc: error: Error when reading batch size (110 =3D Connection timed =
out): Internal error
> xc: error: error when buffering batch, finishing (110 =3D Connection =
timed out): Internal error


The error occurs at an earlier plug/unplug with faster intervals.

I detailed my installation steps on my crude blog I just made, hopefully =
it helps:
http://akorzan.com/dokuwiki/doku.php?id=3Dxen:installation

For Linux I used 3.4 or 3.0 and added the necessary options in make =
menuconfig.  For 3.0 I had to get a separate copy of sch_plug.

The only thing I had to differentiate from, is that for the DomU config, =
I had to use ["phy:/dev/drbd1,w,xvda"] instead of =
["drbd:ubuntu_vm_1,w,xvda"]


On a side note: Interestingly, after changing the Kernel from 3.4 to 3.0 =
and installing an external version of sch_plug, provided on the Xen =
Wiki, pings to the DomU don't display the delay the network buffering =
causes, but on longer intervals you can feel the extra time the pings =
take to respond.  Weird.

Many Thanks,
Anthony

On Dec 18, 2014, at 9:09 PM, Hongyang Yang <yanghy@cn.fujitsu.com> =
wrote:

> Hi,
>=20
> =E5=9C=A8 12/19/2014 05:48 AM, Anthony Korzan =E5=86=99=E9=81=93:
>> Hello!
>>=20
>> I have only managed to get Xen 4.5's Remus "working" on Linux Kernels =
less than
>> 3.5. The provided remus-drbd, as detailed in docs/README.remus and =
available
>> from https://github.com/rshriram/remus-drbd will not compile with =
Linux Kernels
>> 3.6 and above.
>=20
> The DRBD you get from https://github.com/rshriram/remus-drbd is DRBD =
8.3.11
> and this version only compatible with Linux 3.0~3.4, see the table on =
this page:
> http://www.drbd.org/download/mainline/
>=20
> I'm afraid DRBD 8.3.11 is the only version that you can get Remus work =
on
> currently. In the past, Remus disk replication based on blktap2, but =
blktap2
> is getting deprecated I think, there's no maintainers nor patches =
recent years.
>=20
> If you are interest, there's a new FT solution based on Remus:
> http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
>=20
> This solution use blktap2 as disk replication, and it has lots of =
patches to
> get blktap2 work with xl.
>=20
> Futhermore, we are working on a better solution on disk replication on =
both
> Remus/COLO. COLO is supposed to get into Xen 4.6.
>=20
>>=20
>> One of these errors is that remus-drbd uses a two argument version of =
the macro
>> kunmap_atomic found in include/linux/highmem.h
>> This was deprecated and is no longer included in any Kernels above =
3.6.
>>=20
>> "error: macro "kunmap_atomic" passed 2 arguments, but takes just 1"
>>=20
>> Is there a patch available?  If not, what set up do the Remus devs =
use to test?
>>  I just need a "stable-ish" platform to modify remus on.
>>=20
>>=20
>> Now I did get Remus "working" on Linux 3.4, Ubuntu 14.04, and the =
custom
>> remus-drbd.  The issue I run into is that Remus only plugs and =
unplugs a few
>> hundred times until there is a "Connection timeout error."  It could =
be that I
>> am using an "old" linux kernel version without much Xen integration, =
but I'm
>> stumped about this error:
>=20
> Can you try to use Linux 3.0 to see if the error still exists?
> I will take a look on this problem to see if I can reproduce it.
>=20
>>=20
>> ###
>> ...
>> xc: progress: Reloading memory pages: 895015/65536  1365%
>> xc: Saving memory: iter 1416 (last sent 568 skipped 0): 65536/65536  =
100%
>> ...
>> xc: Saving memory: iter 1420 (last sent 567 skipped 0): 65536/65536  =
100%
>> xc: error: rdexact failed (select returned 0): Internal error
>> xc: error: Error when reading batch size (110 =3D Connection timed =
out): Internal
>> error
>> xc: error: error when buffering batch, finishing (110 =3D Connection =
timed out):
>> Internal error
>> migration target: Remus Failover for domain 5
>> libxl: error: libxl_utils.c:430:libxl_read_exactly: file/stream =
truncated
>> reading ipc msg header from domain 5 save/restore helper stdout pipe
>> libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain =
5
>> save/restore helper [-1] died due to fatal signal Broken pipe
>> libxl: warning: libxl_dom.c:2015:domain_suspend_done: Remus: Domain =
suspend
>> terminated with rc -3, teardown Remus devices...
>> Remus: Backup failed? resuming domain at primary.
>> xc: error: Dom 5 not suspended: (shutdown 0, reason 255): Internal =
error
>> libxl: error: libxl.c:505:libxl__domain_resume: xc_domain_resume =
failed for
>> domain 5: Invalid argument
>> ###
>>=20
>> Sincerely,
>> Anthony
>=20
> --=20
> Thanks,
> Yang.


--Apple-Mail=_91297C5E-24AC-40D8-987A-1848F67EA5CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Thank =
you for your response,<div><br></div><div>I compiled Linux 3.0.101, =
sch_plug, and reinstalled remus-drbd. &nbsp;I still receive the same =
error when starting remus:</div><div><blockquote type=3D"cite">xc: =
error: rdexact failed (select returned 0): Internal error<br>xc: error: =
Error when reading batch size (110 =3D Connection timed out): =
Internal&nbsp;error<br>xc: error: error when buffering batch, finishing =
(110 =3D Connection timed out):&nbsp;Internal =
error</blockquote></div><div><br></div><div>The error occurs at an =
earlier plug/unplug with faster intervals.</div><div><br></div><div>I =
detailed my installation steps on my crude blog I just made, hopefully =
it helps:</div><div><a =
href=3D"http://akorzan.com/dokuwiki/doku.php?id=3Dxen:installation">http:/=
/akorzan.com/dokuwiki/doku.php?id=3Dxen:installation</a></div><div><br></d=
iv><div>For Linux I used 3.4 or 3.0 and added the necessary options in =
make menuconfig. &nbsp;For 3.0 I had to get a separate copy of =
sch_plug.</div><div><br></div><div>The only thing I had to differentiate =
from, is that for the DomU config, I had to use =
["phy:/dev/drbd1,w,xvda"] instead of =
["drbd:ubuntu_vm_1,w,xvda"]</div><div><br></div><div><br></div><div>On a =
side note: Interestingly, after changing the Kernel from 3.4 to 3.0 and =
installing an external version of sch_plug, provided on the Xen Wiki, =
pings to the DomU don't display the delay the network buffering causes, =
but on longer intervals you can feel the extra time the pings take to =
respond. &nbsp;Weird.</div><div><br></div><div>Many =
Thanks,</div><div>Anthony</div><div><br><div><div>On Dec 18, 2014, at =
9:09 PM, Hongyang Yang &lt;<a =
href=3D"mailto:yanghy@cn.fujitsu.com">yanghy@cn.fujitsu.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">Hi,<br><br>=E5=9C=A8 12/19/2014 05:48 AM, Anthony Korzan =
=E5=86=99=E9=81=93:<br><blockquote type=3D"cite">Hello!<br><br>I have =
only managed to get Xen 4.5's Remus "working" on Linux Kernels less =
than<br>3.5. The provided remus-drbd, as detailed in docs/README.remus =
and available<br>from <a =
href=3D"https://github.com/rshriram/remus-drbd">https://github.com/rshrira=
m/remus-drbd</a> will not compile with Linux Kernels<br>3.6 and =
above.<br></blockquote><br>The DRBD you get from <a =
href=3D"https://github.com/rshriram/remus-drbd">https://github.com/rshrira=
m/remus-drbd</a> is DRBD 8.3.11<br>and this version only compatible with =
Linux 3.0~3.4, see the table on this page:<br><a =
href=3D"http://www.drbd.org/download/mainline/">http://www.drbd.org/downlo=
ad/mainline/</a><br><br>I'm afraid DRBD 8.3.11 is the only version that =
you can get Remus work on<br>currently. In the past, Remus disk =
replication based on blktap2, but blktap2<br>is getting deprecated I =
think, there's no maintainers nor patches recent years.<br><br>If you =
are interest, there's a new FT solution based on =
Remus:<br>http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping<br><b=
r>This solution use blktap2 as disk replication, and it has lots of =
patches to<br>get blktap2 work with xl.<br><br>Futhermore, we are =
working on a better solution on disk replication on both<br>Remus/COLO. =
COLO is supposed to get into Xen 4.6.<br><br><blockquote =
type=3D"cite"><br>One of these errors is that remus-drbd uses a two =
argument version of the macro<br>kunmap_atomic found in =
include/linux/highmem.h<br>This was deprecated and is no longer included =
in any Kernels above 3.6.<br><br>"error: macro "kunmap_atomic" passed 2 =
arguments, but takes just 1"<br><br>Is there a patch available? &nbsp;If =
not, what set up do the Remus devs use to test?<br> &nbsp;I just need a =
"stable-ish" platform to modify remus on.<br><br><br>Now I did get Remus =
"working" on Linux 3.4, Ubuntu 14.04, and the custom<br>remus-drbd. =
&nbsp;The issue I run into is that Remus only plugs and unplugs a =
few<br>hundred times until there is a "Connection timeout error." =
&nbsp;It could be that I<br>am using an "old" linux kernel version =
without much Xen integration, but I'm<br>stumped about this =
error:<br></blockquote><br>Can you try to use Linux 3.0 to see if the =
error still exists?<br>I will take a look on this problem to see if I =
can reproduce it.<br><br><blockquote type=3D"cite"><br>###<br>...<br>xc: =
progress: Reloading memory pages: 895015/65536 &nbsp;1365%<br>xc: Saving =
memory: iter 1416 (last sent 568 skipped 0): 65536/65536 =
&nbsp;100%<br>...<br>xc: Saving memory: iter 1420 (last sent 567 skipped =
0): 65536/65536 &nbsp;100%<br>xc: error: rdexact failed (select returned =
0): Internal error<br>xc: error: Error when reading batch size (110 =3D =
Connection timed out): Internal<br>error<br>xc: error: error when =
buffering batch, finishing (110 =3D Connection timed out):<br>Internal =
error<br>migration target: Remus Failover for domain 5<br>libxl: error: =
libxl_utils.c:430:libxl_read_exactly: file/stream truncated<br>reading =
ipc msg header from domain 5 save/restore helper stdout pipe<br>libxl: =
error: libxl_exec.c:129:libxl_report_child_exitstatus: domain =
5<br>save/restore helper [-1] died due to fatal signal Broken =
pipe<br>libxl: warning: libxl_dom.c:2015:domain_suspend_done: Remus: =
Domain suspend<br>terminated with rc -3, teardown Remus =
devices...<br>Remus: Backup failed? resuming domain at primary.<br>xc: =
error: Dom 5 not suspended: (shutdown 0, reason 255): Internal =
error<br>libxl: error: libxl.c:505:libxl__domain_resume: =
xc_domain_resume failed for<br>domain 5: Invalid =
argument<br>###<br><br>Sincerely,<br>Anthony<br></blockquote><br>-- =
<br>Thanks,<br>Yang.<br></blockquote></div><br></div></body></html>=

--Apple-Mail=_91297C5E-24AC-40D8-987A-1848F67EA5CC--


--===============5247075782572141257==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5247075782572141257==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 10:16:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10:16:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ubF-0000JW-U2; Fri, 19 Dec 2014 10:15:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <akorzan@gmail.com>) id 1Y1ubD-0000JP-Ii
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:15:55 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	15/7A-24859-ADAF3945; Fri, 19 Dec 2014 10:15:54 +0000
X-Env-Sender: akorzan@gmail.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418984152!14593325!1
X-Originating-IP: [209.85.213.54]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28102 invoked from network); 19 Dec 2014 10:15:53 -0000
Received: from mail-yh0-f54.google.com (HELO mail-yh0-f54.google.com)
	(209.85.213.54)
	by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 10:15:53 -0000
Received: by mail-yh0-f54.google.com with SMTP id 29so249831yhl.27
	for <xen-devel@lists.xen.org>; Fri, 19 Dec 2014 02:15:51 -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
	:message-id:references:to;
	bh=1Odg0ztA2T/ds+b8yaE3rhkWDsjtmIfKgvts7lBjAb8=;
	b=ELgcIHx0E4DrMzB0YKz/J6hT7EcUmRms0JVw5vRvxe6idDtZgm3NwNeZb2fXQtjj/G
	riCeKd0ReRR87TufMhGihDmkLCsx2oNZ4cmvlNB/20SHz+rlflcqXCGaT2eOzgLoOq17
	8h0chvZKnj4CXjSZdE4xdV9vUySkk3eo+twbUYB0kYcWnJ6KYFllOnKAd6QKBfpusQ5F
	oYgttBlVVra9/sjOAm5lRF5hh4pll/9mXhxzpZb9Y6Kj2EeiCxu/++a6Gb6zSQo7ccXc
	A4E7ufu6QtTFasW3h1AOaAoKznhnoCa6rvYvOW6cgGRwSwFIDHENwNOodmB1JhfV6N7M
	yqSQ==
X-Received: by 10.170.144.8 with SMTP id l8mr6452927ykc.56.1418984151652;
	Fri, 19 Dec 2014 02:15:51 -0800 (PST)
Received: from [192.168.1.12] (pool-72-83-187-210.washdc.fios.verizon.net.
	[72.83.187.210])
	by mx.google.com with ESMTPSA id 21sm5618652yhj.18.2014.12.19.02.15.50
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 19 Dec 2014 02:15:50 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Anthony Korzan <akorzan@gmail.com>
In-Reply-To: <549388F6.9000108@cn.fujitsu.com>
Date: Fri, 19 Dec 2014 05:15:48 -0500
Message-Id: <6EF2F911-C0B4-441D-A25A-BD154832350E@gmail.com>
References: <788CC804-7FC8-40C4-B17B-E02CDB7F2683@gmail.com>
	<549388F6.9000108@cn.fujitsu.com>
To: Hongyang Yang <yanghy@cn.fujitsu.com>
X-Mailer: Apple Mail (2.1878.6)
Cc: rshriram@cs.ubc.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen 4.5-rc] remus-drbd incompatible with Linux
	3.6+ 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: multipart/mixed; boundary="===============5247075782572141257=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============5247075782572141257==
Content-Type: multipart/alternative; boundary="Apple-Mail=_91297C5E-24AC-40D8-987A-1848F67EA5CC"


--Apple-Mail=_91297C5E-24AC-40D8-987A-1848F67EA5CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thank you for your response,

I compiled Linux 3.0.101, sch_plug, and reinstalled remus-drbd.  I still =
receive the same error when starting remus:
> xc: error: rdexact failed (select returned 0): Internal error
> xc: error: Error when reading batch size (110 =3D Connection timed =
out): Internal error
> xc: error: error when buffering batch, finishing (110 =3D Connection =
timed out): Internal error


The error occurs at an earlier plug/unplug with faster intervals.

I detailed my installation steps on my crude blog I just made, hopefully =
it helps:
http://akorzan.com/dokuwiki/doku.php?id=3Dxen:installation

For Linux I used 3.4 or 3.0 and added the necessary options in make =
menuconfig.  For 3.0 I had to get a separate copy of sch_plug.

The only thing I had to differentiate from, is that for the DomU config, =
I had to use ["phy:/dev/drbd1,w,xvda"] instead of =
["drbd:ubuntu_vm_1,w,xvda"]


On a side note: Interestingly, after changing the Kernel from 3.4 to 3.0 =
and installing an external version of sch_plug, provided on the Xen =
Wiki, pings to the DomU don't display the delay the network buffering =
causes, but on longer intervals you can feel the extra time the pings =
take to respond.  Weird.

Many Thanks,
Anthony

On Dec 18, 2014, at 9:09 PM, Hongyang Yang <yanghy@cn.fujitsu.com> =
wrote:

> Hi,
>=20
> =E5=9C=A8 12/19/2014 05:48 AM, Anthony Korzan =E5=86=99=E9=81=93:
>> Hello!
>>=20
>> I have only managed to get Xen 4.5's Remus "working" on Linux Kernels =
less than
>> 3.5. The provided remus-drbd, as detailed in docs/README.remus and =
available
>> from https://github.com/rshriram/remus-drbd will not compile with =
Linux Kernels
>> 3.6 and above.
>=20
> The DRBD you get from https://github.com/rshriram/remus-drbd is DRBD =
8.3.11
> and this version only compatible with Linux 3.0~3.4, see the table on =
this page:
> http://www.drbd.org/download/mainline/
>=20
> I'm afraid DRBD 8.3.11 is the only version that you can get Remus work =
on
> currently. In the past, Remus disk replication based on blktap2, but =
blktap2
> is getting deprecated I think, there's no maintainers nor patches =
recent years.
>=20
> If you are interest, there's a new FT solution based on Remus:
> http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
>=20
> This solution use blktap2 as disk replication, and it has lots of =
patches to
> get blktap2 work with xl.
>=20
> Futhermore, we are working on a better solution on disk replication on =
both
> Remus/COLO. COLO is supposed to get into Xen 4.6.
>=20
>>=20
>> One of these errors is that remus-drbd uses a two argument version of =
the macro
>> kunmap_atomic found in include/linux/highmem.h
>> This was deprecated and is no longer included in any Kernels above =
3.6.
>>=20
>> "error: macro "kunmap_atomic" passed 2 arguments, but takes just 1"
>>=20
>> Is there a patch available?  If not, what set up do the Remus devs =
use to test?
>>  I just need a "stable-ish" platform to modify remus on.
>>=20
>>=20
>> Now I did get Remus "working" on Linux 3.4, Ubuntu 14.04, and the =
custom
>> remus-drbd.  The issue I run into is that Remus only plugs and =
unplugs a few
>> hundred times until there is a "Connection timeout error."  It could =
be that I
>> am using an "old" linux kernel version without much Xen integration, =
but I'm
>> stumped about this error:
>=20
> Can you try to use Linux 3.0 to see if the error still exists?
> I will take a look on this problem to see if I can reproduce it.
>=20
>>=20
>> ###
>> ...
>> xc: progress: Reloading memory pages: 895015/65536  1365%
>> xc: Saving memory: iter 1416 (last sent 568 skipped 0): 65536/65536  =
100%
>> ...
>> xc: Saving memory: iter 1420 (last sent 567 skipped 0): 65536/65536  =
100%
>> xc: error: rdexact failed (select returned 0): Internal error
>> xc: error: Error when reading batch size (110 =3D Connection timed =
out): Internal
>> error
>> xc: error: error when buffering batch, finishing (110 =3D Connection =
timed out):
>> Internal error
>> migration target: Remus Failover for domain 5
>> libxl: error: libxl_utils.c:430:libxl_read_exactly: file/stream =
truncated
>> reading ipc msg header from domain 5 save/restore helper stdout pipe
>> libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain =
5
>> save/restore helper [-1] died due to fatal signal Broken pipe
>> libxl: warning: libxl_dom.c:2015:domain_suspend_done: Remus: Domain =
suspend
>> terminated with rc -3, teardown Remus devices...
>> Remus: Backup failed? resuming domain at primary.
>> xc: error: Dom 5 not suspended: (shutdown 0, reason 255): Internal =
error
>> libxl: error: libxl.c:505:libxl__domain_resume: xc_domain_resume =
failed for
>> domain 5: Invalid argument
>> ###
>>=20
>> Sincerely,
>> Anthony
>=20
> --=20
> Thanks,
> Yang.


--Apple-Mail=_91297C5E-24AC-40D8-987A-1848F67EA5CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Thank =
you for your response,<div><br></div><div>I compiled Linux 3.0.101, =
sch_plug, and reinstalled remus-drbd. &nbsp;I still receive the same =
error when starting remus:</div><div><blockquote type=3D"cite">xc: =
error: rdexact failed (select returned 0): Internal error<br>xc: error: =
Error when reading batch size (110 =3D Connection timed out): =
Internal&nbsp;error<br>xc: error: error when buffering batch, finishing =
(110 =3D Connection timed out):&nbsp;Internal =
error</blockquote></div><div><br></div><div>The error occurs at an =
earlier plug/unplug with faster intervals.</div><div><br></div><div>I =
detailed my installation steps on my crude blog I just made, hopefully =
it helps:</div><div><a =
href=3D"http://akorzan.com/dokuwiki/doku.php?id=3Dxen:installation">http:/=
/akorzan.com/dokuwiki/doku.php?id=3Dxen:installation</a></div><div><br></d=
iv><div>For Linux I used 3.4 or 3.0 and added the necessary options in =
make menuconfig. &nbsp;For 3.0 I had to get a separate copy of =
sch_plug.</div><div><br></div><div>The only thing I had to differentiate =
from, is that for the DomU config, I had to use =
["phy:/dev/drbd1,w,xvda"] instead of =
["drbd:ubuntu_vm_1,w,xvda"]</div><div><br></div><div><br></div><div>On a =
side note: Interestingly, after changing the Kernel from 3.4 to 3.0 and =
installing an external version of sch_plug, provided on the Xen Wiki, =
pings to the DomU don't display the delay the network buffering causes, =
but on longer intervals you can feel the extra time the pings take to =
respond. &nbsp;Weird.</div><div><br></div><div>Many =
Thanks,</div><div>Anthony</div><div><br><div><div>On Dec 18, 2014, at =
9:09 PM, Hongyang Yang &lt;<a =
href=3D"mailto:yanghy@cn.fujitsu.com">yanghy@cn.fujitsu.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">Hi,<br><br>=E5=9C=A8 12/19/2014 05:48 AM, Anthony Korzan =
=E5=86=99=E9=81=93:<br><blockquote type=3D"cite">Hello!<br><br>I have =
only managed to get Xen 4.5's Remus "working" on Linux Kernels less =
than<br>3.5. The provided remus-drbd, as detailed in docs/README.remus =
and available<br>from <a =
href=3D"https://github.com/rshriram/remus-drbd">https://github.com/rshrira=
m/remus-drbd</a> will not compile with Linux Kernels<br>3.6 and =
above.<br></blockquote><br>The DRBD you get from <a =
href=3D"https://github.com/rshriram/remus-drbd">https://github.com/rshrira=
m/remus-drbd</a> is DRBD 8.3.11<br>and this version only compatible with =
Linux 3.0~3.4, see the table on this page:<br><a =
href=3D"http://www.drbd.org/download/mainline/">http://www.drbd.org/downlo=
ad/mainline/</a><br><br>I'm afraid DRBD 8.3.11 is the only version that =
you can get Remus work on<br>currently. In the past, Remus disk =
replication based on blktap2, but blktap2<br>is getting deprecated I =
think, there's no maintainers nor patches recent years.<br><br>If you =
are interest, there's a new FT solution based on =
Remus:<br>http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping<br><b=
r>This solution use blktap2 as disk replication, and it has lots of =
patches to<br>get blktap2 work with xl.<br><br>Futhermore, we are =
working on a better solution on disk replication on both<br>Remus/COLO. =
COLO is supposed to get into Xen 4.6.<br><br><blockquote =
type=3D"cite"><br>One of these errors is that remus-drbd uses a two =
argument version of the macro<br>kunmap_atomic found in =
include/linux/highmem.h<br>This was deprecated and is no longer included =
in any Kernels above 3.6.<br><br>"error: macro "kunmap_atomic" passed 2 =
arguments, but takes just 1"<br><br>Is there a patch available? &nbsp;If =
not, what set up do the Remus devs use to test?<br> &nbsp;I just need a =
"stable-ish" platform to modify remus on.<br><br><br>Now I did get Remus =
"working" on Linux 3.4, Ubuntu 14.04, and the custom<br>remus-drbd. =
&nbsp;The issue I run into is that Remus only plugs and unplugs a =
few<br>hundred times until there is a "Connection timeout error." =
&nbsp;It could be that I<br>am using an "old" linux kernel version =
without much Xen integration, but I'm<br>stumped about this =
error:<br></blockquote><br>Can you try to use Linux 3.0 to see if the =
error still exists?<br>I will take a look on this problem to see if I =
can reproduce it.<br><br><blockquote type=3D"cite"><br>###<br>...<br>xc: =
progress: Reloading memory pages: 895015/65536 &nbsp;1365%<br>xc: Saving =
memory: iter 1416 (last sent 568 skipped 0): 65536/65536 =
&nbsp;100%<br>...<br>xc: Saving memory: iter 1420 (last sent 567 skipped =
0): 65536/65536 &nbsp;100%<br>xc: error: rdexact failed (select returned =
0): Internal error<br>xc: error: Error when reading batch size (110 =3D =
Connection timed out): Internal<br>error<br>xc: error: error when =
buffering batch, finishing (110 =3D Connection timed out):<br>Internal =
error<br>migration target: Remus Failover for domain 5<br>libxl: error: =
libxl_utils.c:430:libxl_read_exactly: file/stream truncated<br>reading =
ipc msg header from domain 5 save/restore helper stdout pipe<br>libxl: =
error: libxl_exec.c:129:libxl_report_child_exitstatus: domain =
5<br>save/restore helper [-1] died due to fatal signal Broken =
pipe<br>libxl: warning: libxl_dom.c:2015:domain_suspend_done: Remus: =
Domain suspend<br>terminated with rc -3, teardown Remus =
devices...<br>Remus: Backup failed? resuming domain at primary.<br>xc: =
error: Dom 5 not suspended: (shutdown 0, reason 255): Internal =
error<br>libxl: error: libxl.c:505:libxl__domain_resume: =
xc_domain_resume failed for<br>domain 5: Invalid =
argument<br>###<br><br>Sincerely,<br>Anthony<br></blockquote><br>-- =
<br>Thanks,<br>Yang.<br></blockquote></div><br></div></body></html>=

--Apple-Mail=_91297C5E-24AC-40D8-987A-1848F67EA5CC--


--===============5247075782572141257==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5247075782572141257==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 10:25:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10:25:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ukR-0000pZ-Fa; Fri, 19 Dec 2014 10:25:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1ukP-0000pU-G6
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:25:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	48/42-25276-41DF3945; Fri, 19 Dec 2014 10:25:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418984722!16681401!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 4458 invoked from network); 19 Dec 2014 10:25: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;
	19 Dec 2014 10:25:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206669710"
Message-ID: <1418984720.20028.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Fri, 19 Dec 2014 10:25:20 +0000
In-Reply-To: <54942BF20200006600086A4B@soto.provo.novell.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
	<1418915443.11882.86.camel@citrix.com>
	<54942BF20200006600086A4B@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-18 at 22:45 -0700, Chun Yan Liu wrote:
> 
> >>> On 12/18/2014 at 11:10 PM, in message <1418915443.11882.86.camel@citrix.com>,
> Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > > Changes to V8: 
> > >   * add an overview document, so that one can has a overall look 
> > >     about the whole domain snapshot work, limits, requirements, 
> > >     how to do, etc. 
> > >  
> > > ===================================================================== 
> > > Domain snapshot overview 
> >  
> > I don't see a similar section for disk snapshots, are you not 
> > considering those here except as a part of a domain snapshot or is this 
> > an oversight? 
> >  
> > There are three main use cases (that I know of at least) for 
> > snapshotting like behaviour. 
> >  
> > One is as you've mentioned below for "backup", i.e. to preserve the VM 
> > at a certain point in time in order to be able to roll back to it. Is 
> > this the only usecase you are considering? 
> 
> Yes. I didn't take disk snapshot thing into the scope.
> 
> >  
> > A second use case is to support "gold image" type deployments, i.e. 
> > where you create one baseline single disk image and then clone it 
> > multiple times to deploy lots of guests. I think this is usually a "disk 
> > snapshot" type thing, but maybe it can be implemented as restoring a 
> > gold domain snapshot multiple times (e.g. for start of day performance 
> > reasons). 
> 
> As we initially discussed about the thing, disk snapshot thing can be done
> be existing tools directly like qemu-img, vhd-util.

I was reading this section as a more generic overview of snapshotting,
without reference to where/how things might ultimately be implemented.

>From a design point of view it would be useful to cover the various use
cases, even if the solution is that the user implements them using CLI
tools by hand (xl) or the toolstack does it for them internally
(libvirt).

This way we can more clearly see the full picture, which allows us to
validate that we are making the right choices about what goes where.

> > The third case, (which is similar to the first), is taking a disk 
> > snapshot in order to be able to run you usual backup software on the 
> > snapshot (which is now unchanging, which is handy) and then deleting the 
> > disk snapshot (this differs from the first case in which disk is active 
> > after the snapshot, and due to the lack of the memory part). 
> 
> Sorry, I'm still not quite clear about what this user case wants to do.

The user has an active domain which they want to backup, but backup
software often does not cope well if the data is changing under its
feet.

So the userswants to take a snapshot of the domains disks while leaving
the domain running, so they can backup that static version of the disk
out of band from the VM itself (e.g. by attaching it to a separate
backup VM).

This may require a guest agent to quiesce the disks.

> >  
> > > * ability to parse user config file 
> > >  
> > >   [2] Disk snapshot requirements: 
> > >   - external tools: qemu-img, lvcreate, vhd-util, etc. 
> > >   - for basic goal, we support 'raw' and 'qcow2' backend types 
> > >     only. Then it requires: 
> > >     libxl qmp command or "qemu-img" (when qemu process does not 
> > >     exist) 
> > >  
> > >  
> > > 3. Interaction with other operations: 
> > >  
> > > No. 
> >  
> > What about shutdown/dying as you noted above? What about migration or 
> > regular save/restore? 
> 
> Since xl now has no idea of the existence of snapshot,

what about libvirt? This section is an overview, so making toolstack
specific assumptions is confusing.

>  so when writing this
> document I turned to depends on users to delete snapshots before or after
> deleting a domain (like shutdown, destroy, save, migrate away). User should
> know where memory is saved, and disk snapshot related info.

What I meant was what happens if you try to snapshot a domain while it
is being shutdown or being migrated? There clearly has to be some sort
of interaction, even if it is "there is a global toolstack lock" or "the
user is advised not to do this".

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 10:25:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10:25:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1ukR-0000pZ-Fa; Fri, 19 Dec 2014 10:25:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1ukP-0000pU-G6
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:25:25 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	48/42-25276-41DF3945; Fri, 19 Dec 2014 10:25:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1418984722!16681401!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 4458 invoked from network); 19 Dec 2014 10:25: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;
	19 Dec 2014 10:25:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206669710"
Message-ID: <1418984720.20028.15.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Fri, 19 Dec 2014 10:25:20 +0000
In-Reply-To: <54942BF20200006600086A4B@soto.provo.novell.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
	<1418915443.11882.86.camel@citrix.com>
	<54942BF20200006600086A4B@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-18 at 22:45 -0700, Chun Yan Liu wrote:
> 
> >>> On 12/18/2014 at 11:10 PM, in message <1418915443.11882.86.camel@citrix.com>,
> Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > > Changes to V8: 
> > >   * add an overview document, so that one can has a overall look 
> > >     about the whole domain snapshot work, limits, requirements, 
> > >     how to do, etc. 
> > >  
> > > ===================================================================== 
> > > Domain snapshot overview 
> >  
> > I don't see a similar section for disk snapshots, are you not 
> > considering those here except as a part of a domain snapshot or is this 
> > an oversight? 
> >  
> > There are three main use cases (that I know of at least) for 
> > snapshotting like behaviour. 
> >  
> > One is as you've mentioned below for "backup", i.e. to preserve the VM 
> > at a certain point in time in order to be able to roll back to it. Is 
> > this the only usecase you are considering? 
> 
> Yes. I didn't take disk snapshot thing into the scope.
> 
> >  
> > A second use case is to support "gold image" type deployments, i.e. 
> > where you create one baseline single disk image and then clone it 
> > multiple times to deploy lots of guests. I think this is usually a "disk 
> > snapshot" type thing, but maybe it can be implemented as restoring a 
> > gold domain snapshot multiple times (e.g. for start of day performance 
> > reasons). 
> 
> As we initially discussed about the thing, disk snapshot thing can be done
> be existing tools directly like qemu-img, vhd-util.

I was reading this section as a more generic overview of snapshotting,
without reference to where/how things might ultimately be implemented.

>From a design point of view it would be useful to cover the various use
cases, even if the solution is that the user implements them using CLI
tools by hand (xl) or the toolstack does it for them internally
(libvirt).

This way we can more clearly see the full picture, which allows us to
validate that we are making the right choices about what goes where.

> > The third case, (which is similar to the first), is taking a disk 
> > snapshot in order to be able to run you usual backup software on the 
> > snapshot (which is now unchanging, which is handy) and then deleting the 
> > disk snapshot (this differs from the first case in which disk is active 
> > after the snapshot, and due to the lack of the memory part). 
> 
> Sorry, I'm still not quite clear about what this user case wants to do.

The user has an active domain which they want to backup, but backup
software often does not cope well if the data is changing under its
feet.

So the userswants to take a snapshot of the domains disks while leaving
the domain running, so they can backup that static version of the disk
out of band from the VM itself (e.g. by attaching it to a separate
backup VM).

This may require a guest agent to quiesce the disks.

> >  
> > > * ability to parse user config file 
> > >  
> > >   [2] Disk snapshot requirements: 
> > >   - external tools: qemu-img, lvcreate, vhd-util, etc. 
> > >   - for basic goal, we support 'raw' and 'qcow2' backend types 
> > >     only. Then it requires: 
> > >     libxl qmp command or "qemu-img" (when qemu process does not 
> > >     exist) 
> > >  
> > >  
> > > 3. Interaction with other operations: 
> > >  
> > > No. 
> >  
> > What about shutdown/dying as you noted above? What about migration or 
> > regular save/restore? 
> 
> Since xl now has no idea of the existence of snapshot,

what about libvirt? This section is an overview, so making toolstack
specific assumptions is confusing.

>  so when writing this
> document I turned to depends on users to delete snapshots before or after
> deleting a domain (like shutdown, destroy, save, migrate away). User should
> know where memory is saved, and disk snapshot related info.

What I meant was what happens if you try to snapshot a domain while it
is being shutdown or being migrated? There clearly has to be some sort
of interaction, even if it is "there is a global toolstack lock" or "the
user is advised not to do this".

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 10:27:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10: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 1Y1umc-00011W-VD; Fri, 19 Dec 2014 10:27:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1umb-00011Q-2w
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:27:41 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	D6/5F-05632-C9DF3945; Fri, 19 Dec 2014 10:27:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418984858!14532208!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 5418 invoked from network); 19 Dec 2014 10:27:39 -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;
	19 Dec 2014 10:27:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206179117"
Message-ID: <1418984856.20028.17.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Fri, 19 Dec 2014 10:27:36 +0000
In-Reply-To: <54943E5F0200006600086A70@soto.provo.novell.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
	<1418915759.11882.91.camel@citrix.com>
	<54943E5F0200006600086A70@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-19 at 00:03 -0700, Chun Yan Liu wrote:

> '--name' meant to give a meaningful name (like: newinstall. Used as the
> memory snapshot name and disk snapshot name).

Where is this name stored and when and where would it be presented to
the user?

> That's good. Then we need to add some description to tell users about
> the auto-generated domain snapshot name, disk snapshot name,
> memory state file and external disk snapshot files, etc.

We will need user docs and manpage updates, yes.

> > > #e.g. to specify exernal disk snapshot, like this: 
> > > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', 
> > >         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] 
> > >  
> > > #e.g. to specify internal disk snapshot, like this: 
> > > disks=[',,hda',',,hdb',] 
> >  
> > Ideally one or the other of these behaviours would be possible without 
> > needing to be quite so explicit.
> 
> OK, I'll delete one.

I don't object to having this more capable syntax as an option, so the
user can override things if they wish, all I was suggesting is that the
default ought to be something useful so the user doesn't need to say
anything if they just want the toolstack to "do something sensible".

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 10:27:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10: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 1Y1umc-00011W-VD; Fri, 19 Dec 2014 10:27:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1umb-00011Q-2w
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:27:41 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	D6/5F-05632-C9DF3945; Fri, 19 Dec 2014 10:27:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1418984858!14532208!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 5418 invoked from network); 19 Dec 2014 10:27:39 -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;
	19 Dec 2014 10:27:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206179117"
Message-ID: <1418984856.20028.17.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Fri, 19 Dec 2014 10:27:36 +0000
In-Reply-To: <54943E5F0200006600086A70@soto.provo.novell.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
	<1418915759.11882.91.camel@citrix.com>
	<54943E5F0200006600086A70@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2014-12-19 at 00:03 -0700, Chun Yan Liu wrote:

> '--name' meant to give a meaningful name (like: newinstall. Used as the
> memory snapshot name and disk snapshot name).

Where is this name stored and when and where would it be presented to
the user?

> That's good. Then we need to add some description to tell users about
> the auto-generated domain snapshot name, disk snapshot name,
> memory state file and external disk snapshot files, etc.

We will need user docs and manpage updates, yes.

> > > #e.g. to specify exernal disk snapshot, like this: 
> > > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', 
> > >         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] 
> > >  
> > > #e.g. to specify internal disk snapshot, like this: 
> > > disks=[',,hda',',,hdb',] 
> >  
> > Ideally one or the other of these behaviours would be possible without 
> > needing to be quite so explicit.
> 
> OK, I'll delete one.

I don't object to having this more capable syntax as an option, so the
user can override things if they wish, all I was suggesting is that the
default ought to be something useful so the user doesn't need to say
anything if they just want the toolstack to "do something sensible".

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 10:38:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1uwq-0001jv-Cb; Fri, 19 Dec 2014 10:38:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1uwp-0001jn-09
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:38:15 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	CE/EB-17958-61004945; Fri, 19 Dec 2014 10:38:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418985492!14600688!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22482 invoked from network); 19 Dec 2014 10:38:13 -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 Dec 2014 10:38:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206672960"
Message-ID: <1418985490.20028.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Fri, 19 Dec 2014 10:38:10 +0000
In-Reply-To: <54943D220200006600086A64@soto.provo.novell.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
	<1418916436.11882.101.camel@citrix.com>
	<54943D220200006600086A64@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-18 at 23:58 -0700, Chun Yan Liu wrote:
> 
> >>> On 12/18/2014 at 11:27 PM, in message <1418916436.11882.101.camel@citrix.com>,
> Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > > Changes to V8: 
> > >   * remove libxl_domain_snapshot_create/delete/revert API 
> > >   * export disk snapshot functionality for both xl and libvirt usage 
> > >  
> > > =========================================================================== 
> > > Libxl/libxlu Design 
> > >  
> > > 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), 
> >  
> > Should this be a KeyedUnion over a new LIBXL_DISK_SNAPSHOT_KIND enum 
> > (with values INTERNAL and EXTERNAL)?
> The KeyedUnion seems to be unnecessary. Only EXTERNAL has data items,
> INTERNAL doesn't, and no third types.
> 
> > This would automatically make the 
> > binding between external==true and the fields which depend on that. 
> >  
> > external_format should be of type libxl_disk_format, unless it is 
> > referring to something else? 
> 
> Yes. That's right. I'll update.
> 
> >  
> > Is it possible for format to differ from the format of the underlying 
> > disk? Perhaps taking a snapshot of a raw disk as a qcow?
> 
> This is related to implementation details. As I understand qemu's
> implementation, taking an external disk snapshot is actually a way:
> origin domain disk: a raw disk
> external= true, external_format: qcow2, external_path: test
> a), create a qcow2 file (test.qcow2) with  backing file (the raw disk)
> b), replace domain disk, now domain uses test.qcow2 (the raw disk
>      is actually to be the snapshot)
> 
> So, I think the external_format can only be those supporting backing file.

Not sure what you mean here.

What about a phy snapshot via lvm snapshotting?

> > In any case 
> > passing in UNKNOWN and letting libxl choose (probably by picking the 
> > same as the underlying disk) should be supported.
> 
> If external_format is not passed (NULL), by default, we will use qcow2.

I think you need to base this on the type of the original disk, if it is
e.g. vhd then making a qcow snapshot seems a bit odd.

> 
> >  
> > > /*  This API might not be used by xl, since xl won't take care of deleting 
> > >  *  snapshots. But for libvirt, since libvirt manages snapshots and will 
> > >  *  delete snapshot, this API will be used. 
> > >  */ 
> > > int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid, 
> > >                                libxl_disk_snapshot *snapshot, int nb); 
> >  
> > The three usecases I mentioned in the previous mail are important here, 
> > because depending on which usecases you are considering there maybe a 
> > many to one relationship between domains and a given snapshot (gold 
> > image case). This interface cannot support that I think.
> 
> I'm not quite clear about the three usecases, especially the 3rd usercase,
> so really not sure what's the requirement towards deleting disk snapshot.

I hope my reply to the previous mail helped clear this up a bit. The
reason deleting a disk is interesting is because that is what you would
do after the backup was finished.

> > When we discussed this in previous iterations I suggested a libxl 
> > command to tell a VM that it needed to reexamine its disks to see if any 
> > of the chains had changed. I'm sure that's not the only potential answer 
> > though.
>  
> About delete disk snapshot in a snapshot chain, whether we need to do
> extra work to avoid data break, it can be discussed:
> a). For external snapshots, usually it's based on backing file chain, qemu
> does this, vhd-util does this. In this case, to delete a domain snapshot,
> one doesn't need to do anything to disk (no need to delete disk snapshot
> at all). Downside is, there might be a long backing chain.

I'm not sure what you mean here I'm afraid. If you are deleting a domain
snapshot why do you not want to delete the disk snapshots associated
with it?

> b). For internal snapshot, like qcow2, lvm too. For lvm, it doesn't support
> snapshot of snapshot, so out of scope. For qcow2, delete any disk snapshot
> won't affect others.

For either internal or external if you are removing a snapshot from the
middle of a chain which ends in one or more active disks, then surely
the disk backend associated with those domains need to get some sort of
notification, otherwise they would need to be written *very* carefully
in order to be able to cope with disk metadata changing under their
feet.

Are you saying that the qemu/qcow implementation has indeed been written
with this in mind and can cope with arbitrary other processes modifying
the qcow metadata under their feet?

e.g. 
BASE---SNAPSHOT A---SNAPSHOT B --- domain 1
                 `--SNAPSHOT C --- domain 2

If SNAPSHOT B and C are in active use then I would expect the deletion
of SNAPSHOT A would need to notify the backends associated with domain 1
and domain 2 somehow, so they don't get very confused.

It's possible that this relates to a use case which you aren't intending
to address (e.g. the gold image use case), in which case it might be out
of scope here.
  
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 10:38:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1uwq-0001jv-Cb; Fri, 19 Dec 2014 10:38:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Y1uwp-0001jn-09
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:38:15 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	CE/EB-17958-61004945; Fri, 19 Dec 2014 10:38:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1418985492!14600688!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 22482 invoked from network); 19 Dec 2014 10:38:13 -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 Dec 2014 10:38:13 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206672960"
Message-ID: <1418985490.20028.27.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Date: Fri, 19 Dec 2014 10:38:10 +0000
In-Reply-To: <54943D220200006600086A64@soto.provo.novell.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
	<1418916436.11882.101.camel@citrix.com>
	<54943D220200006600086A64@soto.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-12-18 at 23:58 -0700, Chun Yan Liu wrote:
> 
> >>> On 12/18/2014 at 11:27 PM, in message <1418916436.11882.101.camel@citrix.com>,
> Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > > Changes to V8: 
> > >   * remove libxl_domain_snapshot_create/delete/revert API 
> > >   * export disk snapshot functionality for both xl and libvirt usage 
> > >  
> > > =========================================================================== 
> > > Libxl/libxlu Design 
> > >  
> > > 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), 
> >  
> > Should this be a KeyedUnion over a new LIBXL_DISK_SNAPSHOT_KIND enum 
> > (with values INTERNAL and EXTERNAL)?
> The KeyedUnion seems to be unnecessary. Only EXTERNAL has data items,
> INTERNAL doesn't, and no third types.
> 
> > This would automatically make the 
> > binding between external==true and the fields which depend on that. 
> >  
> > external_format should be of type libxl_disk_format, unless it is 
> > referring to something else? 
> 
> Yes. That's right. I'll update.
> 
> >  
> > Is it possible for format to differ from the format of the underlying 
> > disk? Perhaps taking a snapshot of a raw disk as a qcow?
> 
> This is related to implementation details. As I understand qemu's
> implementation, taking an external disk snapshot is actually a way:
> origin domain disk: a raw disk
> external= true, external_format: qcow2, external_path: test
> a), create a qcow2 file (test.qcow2) with  backing file (the raw disk)
> b), replace domain disk, now domain uses test.qcow2 (the raw disk
>      is actually to be the snapshot)
> 
> So, I think the external_format can only be those supporting backing file.

Not sure what you mean here.

What about a phy snapshot via lvm snapshotting?

> > In any case 
> > passing in UNKNOWN and letting libxl choose (probably by picking the 
> > same as the underlying disk) should be supported.
> 
> If external_format is not passed (NULL), by default, we will use qcow2.

I think you need to base this on the type of the original disk, if it is
e.g. vhd then making a qcow snapshot seems a bit odd.

> 
> >  
> > > /*  This API might not be used by xl, since xl won't take care of deleting 
> > >  *  snapshots. But for libvirt, since libvirt manages snapshots and will 
> > >  *  delete snapshot, this API will be used. 
> > >  */ 
> > > int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid, 
> > >                                libxl_disk_snapshot *snapshot, int nb); 
> >  
> > The three usecases I mentioned in the previous mail are important here, 
> > because depending on which usecases you are considering there maybe a 
> > many to one relationship between domains and a given snapshot (gold 
> > image case). This interface cannot support that I think.
> 
> I'm not quite clear about the three usecases, especially the 3rd usercase,
> so really not sure what's the requirement towards deleting disk snapshot.

I hope my reply to the previous mail helped clear this up a bit. The
reason deleting a disk is interesting is because that is what you would
do after the backup was finished.

> > When we discussed this in previous iterations I suggested a libxl 
> > command to tell a VM that it needed to reexamine its disks to see if any 
> > of the chains had changed. I'm sure that's not the only potential answer 
> > though.
>  
> About delete disk snapshot in a snapshot chain, whether we need to do
> extra work to avoid data break, it can be discussed:
> a). For external snapshots, usually it's based on backing file chain, qemu
> does this, vhd-util does this. In this case, to delete a domain snapshot,
> one doesn't need to do anything to disk (no need to delete disk snapshot
> at all). Downside is, there might be a long backing chain.

I'm not sure what you mean here I'm afraid. If you are deleting a domain
snapshot why do you not want to delete the disk snapshots associated
with it?

> b). For internal snapshot, like qcow2, lvm too. For lvm, it doesn't support
> snapshot of snapshot, so out of scope. For qcow2, delete any disk snapshot
> won't affect others.

For either internal or external if you are removing a snapshot from the
middle of a chain which ends in one or more active disks, then surely
the disk backend associated with those domains need to get some sort of
notification, otherwise they would need to be written *very* carefully
in order to be able to cope with disk metadata changing under their
feet.

Are you saying that the qemu/qcow implementation has indeed been written
with this in mind and can cope with arbitrary other processes modifying
the qcow metadata under their feet?

e.g. 
BASE---SNAPSHOT A---SNAPSHOT B --- domain 1
                 `--SNAPSHOT C --- domain 2

If SNAPSHOT B and C are in active use then I would expect the deletion
of SNAPSHOT A would need to notify the backends associated with domain 1
and domain 2 somehow, so they don't get very confused.

It's possible that this relates to a use case which you aren't intending
to address (e.g. the gold image use case), in which case it might be out
of scope here.
  
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 10:51:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10: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 1Y1v9F-0002Dj-NC; Fri, 19 Dec 2014 10:51:05 +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 1Y1v9E-0002De-GN
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:51:04 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	47/2A-03145-71304945; Fri, 19 Dec 2014 10:51:03 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418986260!16061897!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMTUxMzQ3MCAo
	YWJhbmRvbmVkOiBhYm91dC5tZS9kYXJpby5m\nYWdnaW9saSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6246 invoked from network); 19 Dec 2014 10:51:01 -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;
	19 Dec 2014 10:51:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; 
	d="asc'?scan'208";a="206184491"
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.210.2;
	Fri, 19 Dec 2014 05:50:58 -0500
Message-ID: <1418986256.10854.30.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 19 Dec 2014 11:50:56 +0100
In-Reply-To: <1418982526.20028.2.camel@citrix.com>
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
	<5492EBFC.8010005@suse.com>
	<20141218150409.GA2870@zion.uk.xensource.com>
	<5492EE60.5090005@suse.com> <1418923754.10854.25.camel@Abyss.station>
	<1418982526.20028.2.camel@citrix.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>, George
	Dunlap <george.dunlap@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] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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: multipart/mixed; boundary="===============5042800021688567042=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5042800021688567042==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-lm/z744rjxnO754J4EXa"

--=-lm/z744rjxnO754J4EXa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2014-12-19 at 09:48 +0000, Ian Campbell wrote:
> On Thu, 2014-12-18 at 18:29 +0100, Dario Faggioli wrote:
> > On Thu, 2014-12-18 at 16:10 +0100, Juergen Gross wrote:
>=20
> > > So: Why can't you test cpupools on ARM?
> > >=20
> > We certainly can. ARM testing via OSSTest is a still experimental,
> > AFAIUI.
>=20
> arm32 testing is production in osstest.
>=20
> > I don't even know if we have the hardware, yet, as I think the "rack" o=
f
> > ARM dev board IanC was working on will be setup in the new testing COLO=
,
> > rather than in current OSSTest pool of hardware (someone correct me if
> > I'm wrong).
>=20
> The new rack is to replace the existing h/w used in production, since
> that can't be shipped to the colo for various reasons.
>=20
Ok.

> > However, that seems to be taken into account by the fact that, in
> > make-flight, in test_matrix_do_one(), after only 2 jobs are created (th=
e
> > basic debian one and a libvirt one) we have this:
> >=20
> >   # No further arm tests at the moment
> >   if [ $dom0arch =3D armhf ]; then
> >       return
> >   fi
> >=20
> > So, yes, I guess I can get rid of such filters in my new function, so
> > that, when ARM maintainers  will disable the safety catch above, a job
> > will actually be generated.
>=20
> We should probably move some of the tests from below the cut to above
> already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific,
> so should be run on arm.
>=20
I see. Great. :-)

Scheduler testing being below the cutoff was exactly what made me
thinking that we only wanted basic ARM testing for now, given the
limited HW resources, and to keep the "noise" low.

I'll certainly move this one below it.

> That's not your problem, but if you could add the new test above the cut
> that would be great. I'll sort out the other ones at some point.
>=20
Sure I will.

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)


--=-lm/z744rjxnO754J4EXa
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

iEYEABECAAYFAlSUAxAACgkQk4XaBE3IOsTr9ACcDLSaKLiA22t935ovhQThJgNk
BX0An19n0UeK4hU0YAcw9WdnExEEpXY3
=4HAq
-----END PGP SIGNATURE-----

--=-lm/z744rjxnO754J4EXa--


--===============5042800021688567042==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5042800021688567042==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 10:51:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 10: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 1Y1v9F-0002Dj-NC; Fri, 19 Dec 2014 10:51:05 +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 1Y1v9E-0002De-GN
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 10:51:04 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	47/2A-03145-71304945; Fri, 19 Dec 2014 10:51:03 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1418986260!16061897!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMTUxMzQ3MCAo
	YWJhbmRvbmVkOiBhYm91dC5tZS9kYXJpby5m\nYWdnaW9saSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6246 invoked from network); 19 Dec 2014 10:51:01 -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;
	19 Dec 2014 10:51:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; 
	d="asc'?scan'208";a="206184491"
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.210.2;
	Fri, 19 Dec 2014 05:50:58 -0500
Message-ID: <1418986256.10854.30.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 19 Dec 2014 11:50:56 +0100
In-Reply-To: <1418982526.20028.2.camel@citrix.com>
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
	<5492EBFC.8010005@suse.com>
	<20141218150409.GA2870@zion.uk.xensource.com>
	<5492EE60.5090005@suse.com> <1418923754.10854.25.camel@Abyss.station>
	<1418982526.20028.2.camel@citrix.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>, George
	Dunlap <george.dunlap@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] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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: multipart/mixed; boundary="===============5042800021688567042=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5042800021688567042==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-lm/z744rjxnO754J4EXa"

--=-lm/z744rjxnO754J4EXa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2014-12-19 at 09:48 +0000, Ian Campbell wrote:
> On Thu, 2014-12-18 at 18:29 +0100, Dario Faggioli wrote:
> > On Thu, 2014-12-18 at 16:10 +0100, Juergen Gross wrote:
>=20
> > > So: Why can't you test cpupools on ARM?
> > >=20
> > We certainly can. ARM testing via OSSTest is a still experimental,
> > AFAIUI.
>=20
> arm32 testing is production in osstest.
>=20
> > I don't even know if we have the hardware, yet, as I think the "rack" o=
f
> > ARM dev board IanC was working on will be setup in the new testing COLO=
,
> > rather than in current OSSTest pool of hardware (someone correct me if
> > I'm wrong).
>=20
> The new rack is to replace the existing h/w used in production, since
> that can't be shipped to the colo for various reasons.
>=20
Ok.

> > However, that seems to be taken into account by the fact that, in
> > make-flight, in test_matrix_do_one(), after only 2 jobs are created (th=
e
> > basic debian one and a libvirt one) we have this:
> >=20
> >   # No further arm tests at the moment
> >   if [ $dom0arch =3D armhf ]; then
> >       return
> >   fi
> >=20
> > So, yes, I guess I can get rid of such filters in my new function, so
> > that, when ARM maintainers  will disable the safety catch above, a job
> > will actually be generated.
>=20
> We should probably move some of the tests from below the cut to above
> already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific,
> so should be run on arm.
>=20
I see. Great. :-)

Scheduler testing being below the cutoff was exactly what made me
thinking that we only wanted basic ARM testing for now, given the
limited HW resources, and to keep the "noise" low.

I'll certainly move this one below it.

> That's not your problem, but if you could add the new test above the cut
> that would be great. I'll sort out the other ones at some point.
>=20
Sure I will.

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)


--=-lm/z744rjxnO754J4EXa
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

iEYEABECAAYFAlSUAxAACgkQk4XaBE3IOsTr9ACcDLSaKLiA22t935ovhQThJgNk
BX0An19n0UeK4hU0YAcw9WdnExEEpXY3
=4HAq
-----END PGP SIGNATURE-----

--=-lm/z744rjxnO754J4EXa--


--===============5042800021688567042==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5042800021688567042==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 11:02:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11: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 1Y1vJy-0002bq-Vt; Fri, 19 Dec 2014 11:02: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 1Y1vJx-0002ac-6e
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:02:09 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	B6/D1-02699-0B504945; Fri, 19 Dec 2014 11:02:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418986926!16170167!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 5907 invoked from network); 19 Dec 2014 11:02:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 11:02:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206186891"
Message-ID: <1418986924.20028.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri, 19 Dec 2014 11:02:04 +0000
In-Reply-To: <1418986256.10854.30.camel@Abyss.station>
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
	<5492EBFC.8010005@suse.com>
	<20141218150409.GA2870@zion.uk.xensource.com>
	<5492EE60.5090005@suse.com> <1418923754.10854.25.camel@Abyss.station>
	<1418982526.20028.2.camel@citrix.com>
	<1418986256.10854.30.camel@Abyss.station>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>, George
	Dunlap <george.dunlap@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] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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 Fri, 2014-12-19 at 11:50 +0100, Dario Faggioli wrote:
> > > However, that seems to be taken into account by the fact that, in
> > > make-flight, in test_matrix_do_one(), after only 2 jobs are created (the
> > > basic debian one and a libvirt one) we have this:
> > > 
> > >   # No further arm tests at the moment
> > >   if [ $dom0arch = armhf ]; then
> > >       return
> > >   fi
> > > 
> > > So, yes, I guess I can get rid of such filters in my new function, so
> > > that, when ARM maintainers  will disable the safety catch above, a job
> > > will actually be generated.
> > 
> > We should probably move some of the tests from below the cut to above
> > already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific,
> > so should be run on arm.
> > 
> I see. Great. :-)
> 
> Scheduler testing being below the cutoff was exactly what made me
> thinking that we only wanted basic ARM testing for now, given the
> limited HW resources, and to keep the "noise" low

Actually if anything we are underutilising the ARM resources we have,
they usually finish way in advance of all the x86 stuff.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:02:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11: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 1Y1vJy-0002bq-Vt; Fri, 19 Dec 2014 11:02: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 1Y1vJx-0002ac-6e
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:02:09 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	B6/D1-02699-0B504945; Fri, 19 Dec 2014 11:02:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1418986926!16170167!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 5907 invoked from network); 19 Dec 2014 11:02:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 11:02:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206186891"
Message-ID: <1418986924.20028.34.camel@citrix.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri, 19 Dec 2014 11:02:04 +0000
In-Reply-To: <1418986256.10854.30.camel@Abyss.station>
References: <20141218130919.29909.13566.stgit@Abyss.station>
	<20141218133902.29909.99057.stgit@Abyss.station>
	<5492EBFC.8010005@suse.com>
	<20141218150409.GA2870@zion.uk.xensource.com>
	<5492EE60.5090005@suse.com> <1418923754.10854.25.camel@Abyss.station>
	<1418982526.20028.2.camel@citrix.com>
	<1418986256.10854.30.camel@Abyss.station>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.12.9-1 
MIME-Version: 1.0
X-DLP: MIA2
Cc: Juergen Gross <jgross@suse.com>, George
	Dunlap <george.dunlap@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] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it
 and job 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 Fri, 2014-12-19 at 11:50 +0100, Dario Faggioli wrote:
> > > However, that seems to be taken into account by the fact that, in
> > > make-flight, in test_matrix_do_one(), after only 2 jobs are created (the
> > > basic debian one and a libvirt one) we have this:
> > > 
> > >   # No further arm tests at the moment
> > >   if [ $dom0arch = armhf ]; then
> > >       return
> > >   fi
> > > 
> > > So, yes, I guess I can get rid of such filters in my new function, so
> > > that, when ARM maintainers  will disable the safety catch above, a job
> > > will actually be generated.
> > 
> > We should probably move some of the tests from below the cut to above
> > already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific,
> > so should be run on arm.
> > 
> I see. Great. :-)
> 
> Scheduler testing being below the cutoff was exactly what made me
> thinking that we only wanted basic ARM testing for now, given the
> limited HW resources, and to keep the "noise" low

Actually if anything we are underutilising the ARM resources we have,
they usually finish way in advance of all the x86 stuff.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:17:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vYR-0003TD-EY; Fri, 19 Dec 2014 11:17:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1vYQ-0003T8-4l
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 11:17:06 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	CA/70-02953-13904945; Fri, 19 Dec 2014 11:17:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418987824!11515493!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5075 invoked from network); 19 Dec 2014 11:17:04 -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; 19 Dec 2014 11:17:04 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 11:17:04 +0000
Message-Id: <5494173E0200007800050F59@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 11:17:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9FAA523E.1__="
Cc: roy.franz@linaro.org
Subject: [Xen-devel] [PATCH] EFI: suppress bogus loader warning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part9FAA523E.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This was accidentally lost in commit fbc3d9a220 ("EFI: add
efi_arch_handle_cmdline() for processing commandline"), leading to the
"Unknown command line option" warning being printed whenever options
get passed to the core hypervisor or the Dom0 kernel.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -311,6 +311,7 @@ static unsigned int __init get_argv(unsi
                 ++argc;
             else if ( prev && wstrcmp(prev, L"--") =3D=3D 0 )
             {
+                --argv;
                 if ( options )
                     *options =3D cmdline;
                 break;




--=__Part9FAA523E.1__=
Content-Type: text/plain; name="EFI-skip-double-dash.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="EFI-skip-double-dash.patch"

EFI: suppress bogus loader warning=0A=0AThis was accidentally lost in =
commit fbc3d9a220 ("EFI: add=0Aefi_arch_handle_cmdline() for processing =
commandline"), leading to the=0A"Unknown command line option" warning =
being printed whenever options=0Aget passed to the core hypervisor or the =
Dom0 kernel.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/common/efi/boot.c=0A+++ b/xen/common/efi/boot.c=0A@@ -311,6 +311,7 =
@@ static unsigned int __init get_argv(unsi=0A                 ++argc;=0A  =
           else if ( prev && wstrcmp(prev, L"--") =3D=3D 0 )=0A            =
 {=0A+                --argv;=0A                 if ( options )=0A         =
            *options =3D cmdline;=0A                 break;=0A
--=__Part9FAA523E.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

--=__Part9FAA523E.1__=--


From xen-devel-bounces@lists.xen.org Fri Dec 19 11:17:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vYR-0003TD-EY; Fri, 19 Dec 2014 11:17:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1vYQ-0003T8-4l
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 11:17:06 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	CA/70-02953-13904945; Fri, 19 Dec 2014 11:17:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1418987824!11515493!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5075 invoked from network); 19 Dec 2014 11:17:04 -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; 19 Dec 2014 11:17:04 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 11:17:04 +0000
Message-Id: <5494173E0200007800050F59@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 11:17:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9FAA523E.1__="
Cc: roy.franz@linaro.org
Subject: [Xen-devel] [PATCH] EFI: suppress bogus loader warning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part9FAA523E.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This was accidentally lost in commit fbc3d9a220 ("EFI: add
efi_arch_handle_cmdline() for processing commandline"), leading to the
"Unknown command line option" warning being printed whenever options
get passed to the core hypervisor or the Dom0 kernel.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -311,6 +311,7 @@ static unsigned int __init get_argv(unsi
                 ++argc;
             else if ( prev && wstrcmp(prev, L"--") =3D=3D 0 )
             {
+                --argv;
                 if ( options )
                     *options =3D cmdline;
                 break;




--=__Part9FAA523E.1__=
Content-Type: text/plain; name="EFI-skip-double-dash.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="EFI-skip-double-dash.patch"

EFI: suppress bogus loader warning=0A=0AThis was accidentally lost in =
commit fbc3d9a220 ("EFI: add=0Aefi_arch_handle_cmdline() for processing =
commandline"), leading to the=0A"Unknown command line option" warning =
being printed whenever options=0Aget passed to the core hypervisor or the =
Dom0 kernel.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/common/efi/boot.c=0A+++ b/xen/common/efi/boot.c=0A@@ -311,6 +311,7 =
@@ static unsigned int __init get_argv(unsi=0A                 ++argc;=0A  =
           else if ( prev && wstrcmp(prev, L"--") =3D=3D 0 )=0A            =
 {=0A+                --argv;=0A                 if ( options )=0A         =
            *options =3D cmdline;=0A                 break;=0A
--=__Part9FAA523E.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

--=__Part9FAA523E.1__=--


From xen-devel-bounces@lists.xen.org Fri Dec 19 11:25:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vgv-0003vF-0i; Fri, 19 Dec 2014 11:25:53 +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 1Y1vgt-0003v0-6H
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:25:51 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	6C/FF-02954-E3B04945; Fri, 19 Dec 2014 11:25:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418988349!16175547!1
X-Originating-IP: [81.169.146.163]
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 21294 invoked from network); 19 Dec 2014 11:25:50 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:25:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988349; l=1135;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=eLdzgddHD0li5ALrtoKxv+/YcWI=;
	b=vwEQjxvolmibCHFdDeJ3QpQcirGeoofEdzc65GUE8lwMnTmpztkw0ZdC1v0mAgaUyt+
	R+mIGiBnp7HJtZn+u+jIq9AdHZi+AWsvgv0vzEtThW/KuPrn7xq74yA/1QAjWrrsnWiml
	kGLT4x6kpMPgqk0W1stb+D7JiYdX6Sl5m5A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id d07330qBJBPkRZB
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:25:46 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id E4A5D50158; Fri, 19 Dec 2014 12:25:40 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:29 +0100
Message-Id: <1418988333-5404-4-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 3/7] tools/hotplug: xendomains.service depends
	on network
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Starting domains during boot will most likely require network for
the local bridge and it may need access to remote filesystems. Add
ordering tags to systemd service file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xendomains.service.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
index 9962671..66e2065 100644
--- a/tools/hotplug/Linux/systemd/xendomains.service.in
+++ b/tools/hotplug/Linux/systemd/xendomains.service.in
@@ -2,6 +2,8 @@
 Description=Xendomains - start and stop guests on boot and shutdown
 Requires=proc-xen.mount xenstored.service
 After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
+After=network-online.target
+After=remote-fs.target
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:25:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vgp-0003uZ-FO; Fri, 19 Dec 2014 11:25:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Y1vgo-0003uU-8J
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:25:46 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	BD/D0-26740-93B04945; Fri, 19 Dec 2014 11:25:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418988344!14516603!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30467 invoked from network); 19 Dec 2014 11:25:44 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:25:44 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988344; l=3181;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=6OHlm9ZefE8S95dGSLG1GEKK0t8=;
	b=W4VHqFcq8py2XLN5TVyI7/ZWW0egLfw63d/XbY3XrXlS7pnWEgypl7xAQzxNyJRVbbn
	KrK1WvjdB8s1kpvJZjTl75NE9SFDXlE0GtwZn0UrSyNyftns24U884teSmeYPH99IpWR/
	4ZKHod3TToba7Ibysah62AhyUqb8YYrXbp4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id Y01ca7qBJBPfms6
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:25:41 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id B40A75016E; Fri, 19 Dec 2014 12:25:40 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:26 +0100
Message-Id: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
Cc: Olaf Hering <olaf@aepfle.de>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a resend of these two series:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00858.html
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html

New in v3 is a wrapper to run xenstored. See its patch description
for details.

Patch 2-6 should be applied for 4.5.0.

The first and the last one still has issues with xenstored and
SELinux. See below.  Up to now no solution is known to me.


The first patch fixes Arch Linux and does not break anything.  As such
it should be safe to be applied for 4.5.0.  SELinux users (who build
from source) should put their special mount options into fstab. Distro
packages will most likely include a proper .service file.


The last patch addresses the XENSTORED_TRACE issue. But SELinux will
most likely still not work.

Possible ways to handle launching xenstored and SELinux:

- do nothing
  pro: - no Xen source changes required
  con: - possible unhappy users who build from source and still have
         SELinux enabled

- use newly added wrapper
  pro: - XENSTORED_TRACE boolean is handled
  con: - the wrapper may have the very same issue as the current
         launching with sh -c 'exec xenstored'. But maybe there is a
	 way to mark the new wrapper script as "this is the native
	 xenstored". Someone familiar with SELinux may be able to
	 answer this.

- Use ExecStart=@XENSTORED@
  pro: - socket passing will most likely work
  con: - All options have to be passed in XENSTORED_ARGS, a new variable
         which is not yet mentioned in the sysconfig file.
       - Switching xenstored requires a private copy of
	 xenstored.service in /etc/systemd instead of adjusting the
	 XENSTORED= variable in the sysconfig file.

- Use ExecStart=/usr/bin/env $XENSTORED
  pro: - $XENSTORED can be set in sysconfig file
  con: - may have the same socket issue as starting via shell
       - XENSTORED_TRACE boolean is not handled


I will be offline until 2015-01-07, so any further adjustments to this
series has to be done by someone else.


Good luck!

Olaf


Olaf Hering (7):
  tools/hotplug: remove SELinux options from var-lib-xenstored.mount
  tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service
  tools/hotplug: xendomains.service depends on network
  tools/hotplug: use xencommons as EnvironmentFile in
    xenconsoled.service
  tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service
  tools/hotplug: remove EnvironmentFile from
    xen-qemu-dom0-disk-backend.service
  tools/hotplug: add wrapper to start xenstored

 .gitignore                                                        | 1 +
 tools/configure                                                   | 3 ++-
 tools/configure.ac                                                | 1 +
 tools/hotplug/Linux/Makefile                                      | 2 ++
 tools/hotplug/Linux/init.d/xencommons.in                          | 6 ++++--
 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 4 +---
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
 tools/hotplug/Linux/systemd/xenconsoled.service.in                | 6 +++---
 tools/hotplug/Linux/systemd/xendomains.service.in                 | 2 ++
 tools/hotplug/Linux/systemd/xenstored.service.in                  | 6 ++----
 tools/hotplug/Linux/xenstored.sh.in                               | 6 ++++++
 11 files changed, 24 insertions(+), 14 deletions(-)
 create mode 100644 tools/hotplug/Linux/xenstored.sh.in


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:25:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vgw-0003vb-C6; Fri, 19 Dec 2014 11:25:54 +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 1Y1vgv-0003vO-LO
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 11:25:53 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	99/55-08051-14B04945; Fri, 19 Dec 2014 11:25:53 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418988351!16146334!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5866 invoked from network); 19 Dec 2014 11:25:52 -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 Dec 2014 11:25:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206684154"
Message-ID: <54940B3D.5080806@citrix.com>
Date: Fri, 19 Dec 2014 11:25:49 +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: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>,
	<xen-devel@lists.xenproject.org>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
	<5493224D.9050001@citrix.com> <5493DBF3.5040705@citrix.com>
In-Reply-To: <5493DBF3.5040705@citrix.com>
X-DLP: MIA2
Cc: Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
	from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTkvMTIvMTQgMDg6MDQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4gSGVsbG8sCj4KPiBF
bCAxOC8xMi8xNCBhIGxlcyAxOS41MSwgQW5kcmV3IENvb3BlciBoYSBlc2NyaXQ6Cj4+IE9uIDE4
LzEyLzE0IDE4OjI3LCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+PiBQcmV2ZW50IERvbTAgZnJv
bSBhY2Nlc3NpbmcgSFBFVCBNTUlPIHJlZ2lvbiBieSBhZGRpbmcgaXQgdG8gdGhlIGxpc3Qgb2YK
Pj4+IGRlbmllZCBtZW1vcnkgcmVnaW9ucy4KPj4+Cj4+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQ
YXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPj4+IENjOiBKYW4gQmV1bGljaCA8amJl
dWxpY2hAc3VzZS5jb20+Cj4+PiBDYzogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0
cml4LmNvbT4KPj4gQXBvbG9naWVzIHRoYXQgdGhpcyByZXBseSBpcyBzcGxpdCBiZXR3ZWVuIHBh
dGNoIDAgYW5kIDIgLSBJIHJlcGxpZWQgdG8KPj4geW91ciBjb3ZlciBsZXR0ZXIgYmVmb3JlIHJl
YWRpbmcgdGhpcyBwYXRjaC4KPj4KPj4gRGVueWluZyBhY2Nlc3MgaXMgb25seSB2YWxpZCBpZiBh
Y3BpX3RhYmxlX2hwZXQuZmxhZ3MgJiAKPj4gQUNQSV9IUEVUX1BBR0VfUFJPVEVDVDQgaXMgdHJ1
ZS4KPiBUaGFua3MsIGlmIEFDUElfSFBFVF9QQUdFX1BST1RFQ1Q0IGlzIHNldCB0aGVuIHdlIGNh
biBwcmV2ZW50IGFjY2VzcyB0bwo+IHRoZSBmdWxsIHBhZ2UgYW5kIGlmIEFDUElfSFBFVF9QQUdF
X1BST1RFQ1Q2NCBpcyBzZXQgd2UgY2FuIHByZXZlbnQKPiBhY2Nlc3MgdG8gdGhpcyBwYWdlIGFu
ZCB0aGUgYWRqYWNlbnQgNjBLQiAoMTUgcGFnZXMpLiBXaWxsIHNlbmQgYW4KPiB1cGRhdGVkIHZl
cnNpb24uCj4KPiBSb2dlci4KPgoKQUNQSV9IUEVUX1BBR0VfUFJPVEVDVDY0IHN0ZW1zIGZyb20g
aWE2NCBsYW5kLCB3aGVyZSBwYWdlcyBjYW4gYmUgNjRrLiAKSSBiZWxpZXZlIGl0IGNhbiBzYWZl
bHkgYmUgaWdub3JlZCBmb3IgeDg2LCBvciBwZXJoYXBzIHVzZWQgdG8gaW1wbHkKQUNQSV9IUEVU
X1BBR0VfUFJPVEVDVDQKCn5BbmRyZXcKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:25:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vgv-0003vF-0i; Fri, 19 Dec 2014 11:25:53 +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 1Y1vgt-0003v0-6H
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:25:51 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	6C/FF-02954-E3B04945; Fri, 19 Dec 2014 11:25:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-27.messagelabs.com!1418988349!16175547!1
X-Originating-IP: [81.169.146.163]
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 21294 invoked from network); 19 Dec 2014 11:25:50 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.163)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:25:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988349; l=1135;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=eLdzgddHD0li5ALrtoKxv+/YcWI=;
	b=vwEQjxvolmibCHFdDeJ3QpQcirGeoofEdzc65GUE8lwMnTmpztkw0ZdC1v0mAgaUyt+
	R+mIGiBnp7HJtZn+u+jIq9AdHZi+AWsvgv0vzEtThW/KuPrn7xq74yA/1QAjWrrsnWiml
	kGLT4x6kpMPgqk0W1stb+D7JiYdX6Sl5m5A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id d07330qBJBPkRZB
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:25:46 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id E4A5D50158; Fri, 19 Dec 2014 12:25:40 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:29 +0100
Message-Id: <1418988333-5404-4-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 3/7] tools/hotplug: xendomains.service depends
	on network
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Starting domains during boot will most likely require network for
the local bridge and it may need access to remote filesystems. Add
ordering tags to systemd service file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xendomains.service.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
index 9962671..66e2065 100644
--- a/tools/hotplug/Linux/systemd/xendomains.service.in
+++ b/tools/hotplug/Linux/systemd/xendomains.service.in
@@ -2,6 +2,8 @@
 Description=Xendomains - start and stop guests on boot and shutdown
 Requires=proc-xen.mount xenstored.service
 After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
+After=network-online.target
+After=remote-fs.target
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:25:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vgw-0003vb-C6; Fri, 19 Dec 2014 11:25:54 +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 1Y1vgv-0003vO-LO
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 11:25:53 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	99/55-08051-14B04945; Fri, 19 Dec 2014 11:25:53 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1418988351!16146334!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5866 invoked from network); 19 Dec 2014 11:25:52 -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 Dec 2014 11:25:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206684154"
Message-ID: <54940B3D.5080806@citrix.com>
Date: Fri, 19 Dec 2014 11:25:49 +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: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>,
	<xen-devel@lists.xenproject.org>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
	<5493224D.9050001@citrix.com> <5493DBF3.5040705@citrix.com>
In-Reply-To: <5493DBF3.5040705@citrix.com>
X-DLP: MIA2
Cc: Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
	from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTkvMTIvMTQgMDg6MDQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4gSGVsbG8sCj4KPiBF
bCAxOC8xMi8xNCBhIGxlcyAxOS41MSwgQW5kcmV3IENvb3BlciBoYSBlc2NyaXQ6Cj4+IE9uIDE4
LzEyLzE0IDE4OjI3LCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+PiBQcmV2ZW50IERvbTAgZnJv
bSBhY2Nlc3NpbmcgSFBFVCBNTUlPIHJlZ2lvbiBieSBhZGRpbmcgaXQgdG8gdGhlIGxpc3Qgb2YK
Pj4+IGRlbmllZCBtZW1vcnkgcmVnaW9ucy4KPj4+Cj4+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQ
YXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPj4+IENjOiBKYW4gQmV1bGljaCA8amJl
dWxpY2hAc3VzZS5jb20+Cj4+PiBDYzogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0
cml4LmNvbT4KPj4gQXBvbG9naWVzIHRoYXQgdGhpcyByZXBseSBpcyBzcGxpdCBiZXR3ZWVuIHBh
dGNoIDAgYW5kIDIgLSBJIHJlcGxpZWQgdG8KPj4geW91ciBjb3ZlciBsZXR0ZXIgYmVmb3JlIHJl
YWRpbmcgdGhpcyBwYXRjaC4KPj4KPj4gRGVueWluZyBhY2Nlc3MgaXMgb25seSB2YWxpZCBpZiBh
Y3BpX3RhYmxlX2hwZXQuZmxhZ3MgJiAKPj4gQUNQSV9IUEVUX1BBR0VfUFJPVEVDVDQgaXMgdHJ1
ZS4KPiBUaGFua3MsIGlmIEFDUElfSFBFVF9QQUdFX1BST1RFQ1Q0IGlzIHNldCB0aGVuIHdlIGNh
biBwcmV2ZW50IGFjY2VzcyB0bwo+IHRoZSBmdWxsIHBhZ2UgYW5kIGlmIEFDUElfSFBFVF9QQUdF
X1BST1RFQ1Q2NCBpcyBzZXQgd2UgY2FuIHByZXZlbnQKPiBhY2Nlc3MgdG8gdGhpcyBwYWdlIGFu
ZCB0aGUgYWRqYWNlbnQgNjBLQiAoMTUgcGFnZXMpLiBXaWxsIHNlbmQgYW4KPiB1cGRhdGVkIHZl
cnNpb24uCj4KPiBSb2dlci4KPgoKQUNQSV9IUEVUX1BBR0VfUFJPVEVDVDY0IHN0ZW1zIGZyb20g
aWE2NCBsYW5kLCB3aGVyZSBwYWdlcyBjYW4gYmUgNjRrLiAKSSBiZWxpZXZlIGl0IGNhbiBzYWZl
bHkgYmUgaWdub3JlZCBmb3IgeDg2LCBvciBwZXJoYXBzIHVzZWQgdG8gaW1wbHkKQUNQSV9IUEVU
X1BBR0VfUFJPVEVDVDQKCn5BbmRyZXcKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:25:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vgp-0003uZ-FO; Fri, 19 Dec 2014 11:25:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Y1vgo-0003uU-8J
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:25:46 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	BD/D0-26740-93B04945; Fri, 19 Dec 2014 11:25:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418988344!14516603!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30467 invoked from network); 19 Dec 2014 11:25:44 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:25:44 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988344; l=3181;
	s=domk; d=aepfle.de; h=Date:Subject:Cc:To:From;
	bh=6OHlm9ZefE8S95dGSLG1GEKK0t8=;
	b=W4VHqFcq8py2XLN5TVyI7/ZWW0egLfw63d/XbY3XrXlS7pnWEgypl7xAQzxNyJRVbbn
	KrK1WvjdB8s1kpvJZjTl75NE9SFDXlE0GtwZn0UrSyNyftns24U884teSmeYPH99IpWR/
	4ZKHod3TToba7Ibysah62AhyUqb8YYrXbp4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id Y01ca7qBJBPfms6
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:25:41 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id B40A75016E; Fri, 19 Dec 2014 12:25:40 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:26 +0100
Message-Id: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
Cc: Olaf Hering <olaf@aepfle.de>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a resend of these two series:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00858.html
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html

New in v3 is a wrapper to run xenstored. See its patch description
for details.

Patch 2-6 should be applied for 4.5.0.

The first and the last one still has issues with xenstored and
SELinux. See below.  Up to now no solution is known to me.


The first patch fixes Arch Linux and does not break anything.  As such
it should be safe to be applied for 4.5.0.  SELinux users (who build
from source) should put their special mount options into fstab. Distro
packages will most likely include a proper .service file.


The last patch addresses the XENSTORED_TRACE issue. But SELinux will
most likely still not work.

Possible ways to handle launching xenstored and SELinux:

- do nothing
  pro: - no Xen source changes required
  con: - possible unhappy users who build from source and still have
         SELinux enabled

- use newly added wrapper
  pro: - XENSTORED_TRACE boolean is handled
  con: - the wrapper may have the very same issue as the current
         launching with sh -c 'exec xenstored'. But maybe there is a
	 way to mark the new wrapper script as "this is the native
	 xenstored". Someone familiar with SELinux may be able to
	 answer this.

- Use ExecStart=@XENSTORED@
  pro: - socket passing will most likely work
  con: - All options have to be passed in XENSTORED_ARGS, a new variable
         which is not yet mentioned in the sysconfig file.
       - Switching xenstored requires a private copy of
	 xenstored.service in /etc/systemd instead of adjusting the
	 XENSTORED= variable in the sysconfig file.

- Use ExecStart=/usr/bin/env $XENSTORED
  pro: - $XENSTORED can be set in sysconfig file
  con: - may have the same socket issue as starting via shell
       - XENSTORED_TRACE boolean is not handled


I will be offline until 2015-01-07, so any further adjustments to this
series has to be done by someone else.


Good luck!

Olaf


Olaf Hering (7):
  tools/hotplug: remove SELinux options from var-lib-xenstored.mount
  tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service
  tools/hotplug: xendomains.service depends on network
  tools/hotplug: use xencommons as EnvironmentFile in
    xenconsoled.service
  tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service
  tools/hotplug: remove EnvironmentFile from
    xen-qemu-dom0-disk-backend.service
  tools/hotplug: add wrapper to start xenstored

 .gitignore                                                        | 1 +
 tools/configure                                                   | 3 ++-
 tools/configure.ac                                                | 1 +
 tools/hotplug/Linux/Makefile                                      | 2 ++
 tools/hotplug/Linux/init.d/xencommons.in                          | 6 ++++--
 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 4 +---
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
 tools/hotplug/Linux/systemd/xenconsoled.service.in                | 6 +++---
 tools/hotplug/Linux/systemd/xendomains.service.in                 | 2 ++
 tools/hotplug/Linux/systemd/xenstored.service.in                  | 6 ++----
 tools/hotplug/Linux/xenstored.sh.in                               | 6 ++++++
 11 files changed, 24 insertions(+), 14 deletions(-)
 create mode 100644 tools/hotplug/Linux/xenstored.sh.in


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:25:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:25:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vgz-0003xC-Oo; Fri, 19 Dec 2014 11:25:57 +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 1Y1vgy-0003w4-9h
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:25:56 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	FF/F1-09284-34B04945; Fri, 19 Dec 2014 11:25:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418988354!14587557!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1008 invoked from network); 19 Dec 2014 11:25:55 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:25:55 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988354; l=1136;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=eD0Zz+5TkteXfQAzF+liiVNQTYY=;
	b=i96qrOylfwbd3dCLIzE3PmjQNC+EyxaJFIu+4xUv6XKRRcOtZSCRdlq2kj9slVdCUmb
	0IPk4mT2vqwar3GDdk2bXrPZZcn76ILLRm2/E+lcBFXjNSSX69fuQCMrBMSw0fHK4gzbe
	8yXO3jEJkr6pYttp1a19OB27MsMrO6Bb01g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id 606ba9qBJBPqTAK
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:25:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 123735016D; Fri, 19 Dec 2014 12:25:40 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:28 +0100
Message-Id: <1418988333-5404-3-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 2/7] tools/hotplug: remove XENSTORED_ROOTDIR
	from xenstored.service
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There is no need to export XENSTORED_ROOTDIR. This variable can be
enabled in sysconfig/xencommons. If the variable is unset xenstored
will automatically use @XEN_LIB_STORED@.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenstored.service.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 780bdd6..0f0ac58 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -9,7 +9,6 @@ ConditionPathExists=/proc/xen/capabilities
 [Service]
 Type=notify
 Environment=XENSTORED_ARGS=
-Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
 Environment=XENSTORED=@XENSTORED@
 EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:25:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:25:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vgz-0003xC-Oo; Fri, 19 Dec 2014 11:25:57 +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 1Y1vgy-0003w4-9h
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:25:56 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	FF/F1-09284-34B04945; Fri, 19 Dec 2014 11:25:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-31.messagelabs.com!1418988354!14587557!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1008 invoked from network); 19 Dec 2014 11:25:55 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.220)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:25:55 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988354; l=1136;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=eD0Zz+5TkteXfQAzF+liiVNQTYY=;
	b=i96qrOylfwbd3dCLIzE3PmjQNC+EyxaJFIu+4xUv6XKRRcOtZSCRdlq2kj9slVdCUmb
	0IPk4mT2vqwar3GDdk2bXrPZZcn76ILLRm2/E+lcBFXjNSSX69fuQCMrBMSw0fHK4gzbe
	8yXO3jEJkr6pYttp1a19OB27MsMrO6Bb01g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id 606ba9qBJBPqTAK
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:25:52 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 123735016D; Fri, 19 Dec 2014 12:25:40 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:28 +0100
Message-Id: <1418988333-5404-3-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 2/7] tools/hotplug: remove XENSTORED_ROOTDIR
	from xenstored.service
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There is no need to export XENSTORED_ROOTDIR. This variable can be
enabled in sysconfig/xencommons. If the variable is unset xenstored
will automatically use @XEN_LIB_STORED@.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenstored.service.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 780bdd6..0f0ac58 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -9,7 +9,6 @@ ConditionPathExists=/proc/xen/capabilities
 [Service]
 Type=notify
 Environment=XENSTORED_ARGS=
-Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
 Environment=XENSTORED=@XENSTORED@
 EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:26:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11: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 1Y1vh5-0003zG-9S; Fri, 19 Dec 2014 11:26: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 1Y1vh3-0003yd-It
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:26:02 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	AE/70-03148-84B04945; Fri, 19 Dec 2014 11:26:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418988359!16184212!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16947 invoked from network); 19 Dec 2014 11:26:00 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:26:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988359; l=1185;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=p7PsHRpWQA7/nqk6A/yN4zfHNt4=;
	b=IrEUzZfgALjNDXaBH3Q2wrtkAwl3hbfR31HWWJUM1MmkXbyHjOn0uAEBgIkmC+qy2OI
	LAJpCEDVkg+bO8wwhK9uhboNSy3ctLQMUd3btLJMchZB8a3YC8FrG67eD0pm/HIt2D/TW
	gHqKg0X5Io8Tg++uzhB0ASSpwRXmKSsPBjc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id I0498fqBJBPvQ8c
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:25:57 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 3F68750162; Fri, 19 Dec 2014 12:25:40 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:30 +0100
Message-Id: <1418988333-5404-5-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 4/7] tools/hotplug: use xencommons as
	EnvironmentFile in xenconsoled.service
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The referenced sysconfig/xenconsoled does not exist. If anything
needs to be specified it has to go into the existing
sysconfig/xencommons file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenconsoled.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index cb44cd6..74d0428 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -9,7 +9,7 @@ Type=simple
 Environment=XENCONSOLED_ARGS=
 Environment=XENCONSOLED_LOG=none
 Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
+EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
 ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:26:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11: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 1Y1vh5-0003zG-9S; Fri, 19 Dec 2014 11:26: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 1Y1vh3-0003yd-It
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:26:02 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	AE/70-03148-84B04945; Fri, 19 Dec 2014 11:26:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1418988359!16184212!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16947 invoked from network); 19 Dec 2014 11:26:00 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.217)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:26:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988359; l=1185;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=p7PsHRpWQA7/nqk6A/yN4zfHNt4=;
	b=IrEUzZfgALjNDXaBH3Q2wrtkAwl3hbfR31HWWJUM1MmkXbyHjOn0uAEBgIkmC+qy2OI
	LAJpCEDVkg+bO8wwhK9uhboNSy3ctLQMUd3btLJMchZB8a3YC8FrG67eD0pm/HIt2D/TW
	gHqKg0X5Io8Tg++uzhB0ASSpwRXmKSsPBjc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id I0498fqBJBPvQ8c
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:25:57 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 3F68750162; Fri, 19 Dec 2014 12:25:40 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:30 +0100
Message-Id: <1418988333-5404-5-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 4/7] tools/hotplug: use xencommons as
	EnvironmentFile in xenconsoled.service
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The referenced sysconfig/xenconsoled does not exist. If anything
needs to be specified it has to go into the existing
sysconfig/xencommons file.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenconsoled.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index cb44cd6..74d0428 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -9,7 +9,7 @@ Type=simple
 Environment=XENCONSOLED_ARGS=
 Environment=XENCONSOLED_LOG=none
 Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
+EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
 ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:26:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:26:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vhC-00042Q-MQ; Fri, 19 Dec 2014 11:26:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Y1vhB-00041h-LP
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:26:09 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	82/8E-27623-05B04945; Fri, 19 Dec 2014 11:26:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418988365!10173293!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 604 invoked from network); 19 Dec 2014 11:26:05 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:26:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988365; l=1548;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=sUwmCgD3noXiT2J9dvyhh4nXeSk=;
	b=FV/xgbU9GsCeVbFdTGJZZDuTqGjp2rOYaLdKw4JmnzP1RV1ZiamfWCS1LE8aCqR18OX
	BGFLO2N2Ajzm9DN6uYNVmcu6nGTh9inJg7OI5wKJv/nJk86/jaPMxpfSg5+X59WCyAnU4
	T9sGn5ty5CuqazSClZ0QKJ6n/5YdwvdCKdk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id 6076c8qBJBQ2Rcf
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:26:02 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 57D935016F; Fri, 19 Dec 2014 12:25:40 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:31 +0100
Message-Id: <1418988333-5404-6-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 5/7] tools/hotplug: use XENCONSOLED_TRACE in
	xenconsoled.service
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 inventing a new XENCONSOLED_LOG= variable reuse the
existing XENCONSOLED_TRACE= variable in xenconsoled.service.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenconsoled.service.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index 74d0428..4788129 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -7,13 +7,13 @@ ConditionPathExists=/proc/xen/capabilities
 [Service]
 Type=simple
 Environment=XENCONSOLED_ARGS=
-Environment=XENCONSOLED_LOG=none
+Environment=XENCONSOLED_TRACE=none
 Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
 EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
 ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
-ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid --log=${XENCONSOLED_LOG} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
+ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid --log=${XENCONSOLED_TRACE} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
 
 [Install]
 WantedBy=multi-user.target

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:26:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:26:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vhC-00042Q-MQ; Fri, 19 Dec 2014 11:26:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Y1vhB-00041h-LP
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:26:09 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	82/8E-27623-05B04945; Fri, 19 Dec 2014 11:26:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-31.messagelabs.com!1418988365!10173293!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 604 invoked from network); 19 Dec 2014 11:26:05 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:26:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988365; l=1548;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=sUwmCgD3noXiT2J9dvyhh4nXeSk=;
	b=FV/xgbU9GsCeVbFdTGJZZDuTqGjp2rOYaLdKw4JmnzP1RV1ZiamfWCS1LE8aCqR18OX
	BGFLO2N2Ajzm9DN6uYNVmcu6nGTh9inJg7OI5wKJv/nJk86/jaPMxpfSg5+X59WCyAnU4
	T9sGn5ty5CuqazSClZ0QKJ6n/5YdwvdCKdk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id 6076c8qBJBQ2Rcf
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:26:02 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 57D935016F; Fri, 19 Dec 2014 12:25:40 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:31 +0100
Message-Id: <1418988333-5404-6-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 5/7] tools/hotplug: use XENCONSOLED_TRACE in
	xenconsoled.service
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 inventing a new XENCONSOLED_LOG= variable reuse the
existing XENCONSOLED_TRACE= variable in xenconsoled.service.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xenconsoled.service.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index 74d0428..4788129 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -7,13 +7,13 @@ ConditionPathExists=/proc/xen/capabilities
 [Service]
 Type=simple
 Environment=XENCONSOLED_ARGS=
-Environment=XENCONSOLED_LOG=none
+Environment=XENCONSOLED_TRACE=none
 Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
 EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
 PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
 ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
-ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid --log=${XENCONSOLED_LOG} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
+ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid --log=${XENCONSOLED_TRACE} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
 
 [Install]
 WantedBy=multi-user.target

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:26:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vhF-00043r-3Y; Fri, 19 Dec 2014 11:26:13 +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 1Y1vhE-00043E-6y
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:26:12 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	18/19-20609-35B04945; Fri, 19 Dec 2014 11:26:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418988370!16125537!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32361 invoked from network); 19 Dec 2014 11:26:10 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:26:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988370; l=2345;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=BwZHI5HGHYxs55haQsyC9neAAqc=;
	b=d3XRhXoI82TJ/DRUKuw7lpmHZkNXh01d4XoHaynkhhEAZxhHcM2yEveOKx64OSEChZo
	EjLEQlBN/At/A+vWEYndOJxbp7pHopF9bxmpxaloe/2lW9Fx0/YTWOhYQBBVvU6oIQRFT
	OLwji5G/viHoT4GT7RBlflFA+NzUZhDGlDM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id K039d6qBJBQ8Yaf
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:26:08 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 6547250172; Fri, 19 Dec 2014 12:25:40 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:27 +0100
Message-Id: <1418988333-5404-2-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk,
	Anthony PERARD <anthony.perard@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Subject: [Xen-devel] [PATCH 1/7] tools/hotplug: remove SELinux options from
	var-lib-xenstored.mount
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Using SELinux mount options per default breaks several systems.
Either the context= mount option is not known at all to the kernel,
as reported for ArchLinux. Or the default value "none" is unknown to
SELinux, as reported for Fedora. In both cases the unit will fail.

The proper place to specify mount options is /etc/fstab. Appearently
systemd is kind enough to use values from there even if Options= or
What= is specified in a .mount file.

Remove XENSTORED_MOUNT_CTX, the reference to a non-existant
EnvironmentFile and trim default Options= for the mount point.

The removed code was first mentioned in the patch referenced below,
with the following description:
...
 * Some systems define the selinux context in the systemd Option for
   the /var/lib/xenstored tmpfs:
     Options=mode=755,context="system_u:object_r:xenstored_var_lib_t:s0"
   For the upstream version we remove that and let systems specify
   the context on their system /etc/default/xenstored or
   /etc/sysconfig/xenstored $XENSTORED_MOUNT_CTX variable
...
It is nowhere stated (on xen-devel) what "Some systems" means, which
is unfortunately common practice in nearly all opensource projects.
http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg02462.html

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
index d5e04db..11a7d50 100644
--- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
+++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
@@ -6,9 +6,7 @@ ConditionPathExists=/proc/xen/capabilities
 RefuseManualStop=true
 
 [Mount]
-Environment=XENSTORED_MOUNT_CTX=none
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
 What=xenstore
 Where=@XEN_LIB_STORED@
 Type=tmpfs
-Options=mode=755,context="$XENSTORED_MOUNT_CTX"
+Options=mode=755

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:26:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vhF-00043r-3Y; Fri, 19 Dec 2014 11:26:13 +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 1Y1vhE-00043E-6y
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:26:12 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	18/19-20609-35B04945; Fri, 19 Dec 2014 11:26:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418988370!16125537!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODg3NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32361 invoked from network); 19 Dec 2014 11:26:10 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.162)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:26:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988370; l=2345;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=BwZHI5HGHYxs55haQsyC9neAAqc=;
	b=d3XRhXoI82TJ/DRUKuw7lpmHZkNXh01d4XoHaynkhhEAZxhHcM2yEveOKx64OSEChZo
	EjLEQlBN/At/A+vWEYndOJxbp7pHopF9bxmpxaloe/2lW9Fx0/YTWOhYQBBVvU6oIQRFT
	OLwji5G/viHoT4GT7RBlflFA+NzUZhDGlDM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id K039d6qBJBQ8Yaf
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:26:08 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 6547250172; Fri, 19 Dec 2014 12:25:40 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:27 +0100
Message-Id: <1418988333-5404-2-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk,
	Anthony PERARD <anthony.perard@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Subject: [Xen-devel] [PATCH 1/7] tools/hotplug: remove SELinux options from
	var-lib-xenstored.mount
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Using SELinux mount options per default breaks several systems.
Either the context= mount option is not known at all to the kernel,
as reported for ArchLinux. Or the default value "none" is unknown to
SELinux, as reported for Fedora. In both cases the unit will fail.

The proper place to specify mount options is /etc/fstab. Appearently
systemd is kind enough to use values from there even if Options= or
What= is specified in a .mount file.

Remove XENSTORED_MOUNT_CTX, the reference to a non-existant
EnvironmentFile and trim default Options= for the mount point.

The removed code was first mentioned in the patch referenced below,
with the following description:
...
 * Some systems define the selinux context in the systemd Option for
   the /var/lib/xenstored tmpfs:
     Options=mode=755,context="system_u:object_r:xenstored_var_lib_t:s0"
   For the upstream version we remove that and let systems specify
   the context on their system /etc/default/xenstored or
   /etc/sysconfig/xenstored $XENSTORED_MOUNT_CTX variable
...
It is nowhere stated (on xen-devel) what "Some systems" means, which
is unfortunately common practice in nearly all opensource projects.
http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg02462.html

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
index d5e04db..11a7d50 100644
--- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
+++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
@@ -6,9 +6,7 @@ ConditionPathExists=/proc/xen/capabilities
 RefuseManualStop=true
 
 [Mount]
-Environment=XENSTORED_MOUNT_CTX=none
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored
 What=xenstore
 Where=@XEN_LIB_STORED@
 Type=tmpfs
-Options=mode=755,context="$XENSTORED_MOUNT_CTX"
+Options=mode=755

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:26:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11: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 1Y1vhK-00047G-Jy; Fri, 19 Dec 2014 11:26:18 +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 1Y1vhJ-00046H-8n
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:26:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	80/AF-15461-85B04945; Fri, 19 Dec 2014 11:26:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418988375!8703477!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4295 invoked from network); 19 Dec 2014 11:26:16 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:26:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988375; l=1068;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=rpPOfsNAHj5jM5Z75DyDA1Ncrnk=;
	b=UYDh/twv/9QTvtacoqGTFM/FyUjUQa85MIbb56de/1tu0u46mhb4LY/9Yrl/I2AYqhL
	3tr9kscRsXrbtkReS/9CqMlJtailPexFQV/0KM6by07LWgPKxjWxeIbwsIeTsh6sN4e1O
	lI9zL+HnJYTOlzSwACTA0cHoTKCKTe27DOU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id 405436qBJBQDQCw
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:26:13 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 7594850161; Fri, 19 Dec 2014 12:25:41 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:32 +0100
Message-Id: <1418988333-5404-7-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 6/7] tools/hotplug: remove EnvironmentFile from
	xen-qemu-dom0-disk-backend.service
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The references Environment file does not exist, and the service file
does not make use of variables anyway.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
 1 file changed, 1 deletion(-)

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 0a5807a..274cec0 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,7 +8,6 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=simple
-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@

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:26:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11: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 1Y1vhK-00047G-Jy; Fri, 19 Dec 2014 11:26:18 +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 1Y1vhJ-00046H-8n
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:26:17 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	80/AF-15461-85B04945; Fri, 19 Dec 2014 11:26:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418988375!8703477!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4295 invoked from network); 19 Dec 2014 11:26:16 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:26:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988375; l=1068;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=rpPOfsNAHj5jM5Z75DyDA1Ncrnk=;
	b=UYDh/twv/9QTvtacoqGTFM/FyUjUQa85MIbb56de/1tu0u46mhb4LY/9Yrl/I2AYqhL
	3tr9kscRsXrbtkReS/9CqMlJtailPexFQV/0KM6by07LWgPKxjWxeIbwsIeTsh6sN4e1O
	lI9zL+HnJYTOlzSwACTA0cHoTKCKTe27DOU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id 405436qBJBQDQCw
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:26:13 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 7594850161; Fri, 19 Dec 2014 12:25:41 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:32 +0100
Message-Id: <1418988333-5404-7-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 6/7] tools/hotplug: remove EnvironmentFile from
	xen-qemu-dom0-disk-backend.service
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The references Environment file does not exist, and the service file
does not make use of variables anyway.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
 1 file changed, 1 deletion(-)

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 0a5807a..274cec0 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,7 +8,6 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=simple
-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@

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:26:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:26:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vhP-0004AB-1f; Fri, 19 Dec 2014 11:26:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1vhO-00049I-6Y
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 11:26:22 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	37/61-23865-D5B04945; Fri, 19 Dec 2014 11:26:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418988379!14622293!1
X-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 6421 invoked from network); 19 Dec 2014 11:26: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; 19 Dec 2014 11:26:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 11:26:19 +0000
Message-Id: <5494196B0200007800050F6B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 11:26:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE8DD254B.1__="
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>
Subject: [Xen-devel] [PATCH] VT-d: don't crash when PTE bits 52 and up are
	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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE8DD254B.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This can (and will) be legitimately the case when sharing page tables
with EPT (more of a problem before p2m_access_rwx became zero, but
still possible even now when other than that is the default for a
guest), leading to an unconditional crash (in print_vtd_entries())
when a DMA remapping fault occurs.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Regarding the release, if the changes to iommu.c are deemed too
extensive, then _I think_ they could be split off (that code ought to
come into play only when not sharing page tables between VT-d and EPT,
and VT-d code never sets the offending bits to non-zero values afaict).

--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -258,8 +258,7 @@ static u64 addr_to_dma_page_maddr(struct
     struct dma_pte *parent, *pte =3D NULL;
     int level =3D agaw_to_level(hd->arch.agaw);
     int offset;
-    u64 pte_maddr =3D 0, maddr;
-    u64 *vaddr =3D NULL;
+    u64 pte_maddr =3D 0;
=20
     addr &=3D (((u64)1) << addr_width) - 1;
     ASSERT(spin_is_locked(&hd->arch.mapping_lock));
@@ -281,19 +280,19 @@ static u64 addr_to_dma_page_maddr(struct
         offset =3D address_level_offset(addr, level);
         pte =3D &parent[offset];
=20
-        if ( dma_pte_addr(*pte) =3D=3D 0 )
+        pte_maddr =3D dma_pte_addr(*pte);
+        if ( !pte_maddr )
         {
             if ( !alloc )
                 break;
=20
             pdev =3D pci_get_pdev_by_domain(domain, -1, -1, -1);
             drhd =3D acpi_find_matched_drhd_unit(pdev);
-            maddr =3D alloc_pgtable_maddr(drhd, 1);
-            if ( !maddr )
+            pte_maddr =3D alloc_pgtable_maddr(drhd, 1);
+            if ( !pte_maddr )
                 break;
=20
-            dma_set_pte_addr(*pte, maddr);
-            vaddr =3D map_vtd_domain_page(maddr);
+            dma_set_pte_addr(*pte, pte_maddr);
=20
             /*
              * high level table always sets r/w, last level
@@ -303,21 +302,12 @@ static u64 addr_to_dma_page_maddr(struct
             dma_set_pte_writable(*pte);
             iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
         }
-        else
-        {
-            vaddr =3D map_vtd_domain_page(pte->val);
-        }
=20
         if ( level =3D=3D 2 )
-        {
-            pte_maddr =3D pte->val & PAGE_MASK_4K;
-            unmap_vtd_domain_page(vaddr);
             break;
-        }
=20
         unmap_vtd_domain_page(parent);
-        parent =3D (struct dma_pte *)vaddr;
-        vaddr =3D NULL;
+        parent =3D map_vtd_domain_page(pte_maddr);
         level--;
     }
=20
@@ -2449,7 +2439,7 @@ static void vtd_dump_p2m_table_level(pad
             printk("%*sgfn: %08lx mfn: %08lx\n",
                    indent, "",
                    (unsigned long)(address >> PAGE_SHIFT_4K),
-                   (unsigned long)(pte->val >> PAGE_SHIFT_4K));
+                   (unsigned long)(dma_pte_addr(*pte) >> PAGE_SHIFT_4K));
     }
=20
     unmap_vtd_domain_page(pt_vaddr);
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -276,7 +276,7 @@ struct dma_pte {
 #define dma_set_pte_snp(p)  do {(p).val |=3D DMA_PTE_SNP;} while(0)
 #define dma_set_pte_prot(p, prot) \
             do {(p).val =3D ((p).val & ~3) | ((prot) & 3); } while (0)
-#define dma_pte_addr(p) ((p).val & PAGE_MASK_4K)
+#define dma_pte_addr(p) ((p).val & PADDR_MASK & PAGE_MASK_4K)
 #define dma_set_pte_addr(p, addr) do {\
             (p).val |=3D ((addr) & PAGE_MASK_4K); } while (0)
 #define dma_pte_present(p) (((p).val & 3) !=3D 0)
--- a/xen/drivers/passthrough/vtd/utils.c
+++ b/xen/drivers/passthrough/vtd/utils.c
@@ -170,16 +170,16 @@ void print_vtd_entries(struct iommu *iom
         l_index =3D get_level_index(gmfn, level);
         printk("    l%d_index =3D %x\n", level, l_index);
=20
-        pte.val =3D val =3D l[l_index];
+        pte.val =3D l[l_index];
         unmap_vtd_domain_page(l);
-        printk("    l%d[%x] =3D %"PRIx64"\n", level, l_index, val);
+        printk("    l%d[%x] =3D %"PRIx64"\n", level, l_index, pte.val);
=20
-        pte.val =3D val;
         if ( !dma_pte_present(pte) )
         {
             printk("    l%d[%x] not present\n", level, l_index);
             break;
         }
+        val =3D dma_pte_addr(pte);
     } while ( --level );
 }
=20



--=__PartE8DD254B.1__=
Content-Type: text/plain; name="VT-d-mask-maddr.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="VT-d-mask-maddr.patch"

VT-d: don't crash when PTE bits 52 and up are non-zero=0A=0AThis can (and =
will) be legitimately the case when sharing page tables=0Awith EPT (more =
of a problem before p2m_access_rwx became zero, but=0Astill possible even =
now when other than that is the default for a=0Aguest), leading to an =
unconditional crash (in print_vtd_entries())=0Awhen a DMA remapping fault =
occurs.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0ARegardi=
ng the release, if the changes to iommu.c are deemed too=0Aextensive, then =
_I think_ they could be split off (that code ought to=0Acome into play =
only when not sharing page tables between VT-d and EPT,=0Aand VT-d code =
never sets the offending bits to non-zero values afaict).=0A=0A--- =
a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/i=
ommu.c=0A@@ -258,8 +258,7 @@ static u64 addr_to_dma_page_maddr(struct=0A   =
  struct dma_pte *parent, *pte =3D NULL;=0A     int level =3D agaw_to_level=
(hd->arch.agaw);=0A     int offset;=0A-    u64 pte_maddr =3D 0, maddr;=0A- =
   u64 *vaddr =3D NULL;=0A+    u64 pte_maddr =3D 0;=0A =0A     addr &=3D =
(((u64)1) << addr_width) - 1;=0A     ASSERT(spin_is_locked(&hd->arch.mappin=
g_lock));=0A@@ -281,19 +280,19 @@ static u64 addr_to_dma_page_maddr(struct=
=0A         offset =3D address_level_offset(addr, level);=0A         pte =
=3D &parent[offset];=0A =0A-        if ( dma_pte_addr(*pte) =3D=3D 0 )=0A+ =
       pte_maddr =3D dma_pte_addr(*pte);=0A+        if ( !pte_maddr )=0A   =
      {=0A             if ( !alloc )=0A                 break;=0A =0A      =
       pdev =3D pci_get_pdev_by_domain(domain, -1, -1, -1);=0A             =
drhd =3D acpi_find_matched_drhd_unit(pdev);=0A-            maddr =3D =
alloc_pgtable_maddr(drhd, 1);=0A-            if ( !maddr )=0A+            =
pte_maddr =3D alloc_pgtable_maddr(drhd, 1);=0A+            if ( !pte_maddr =
)=0A                 break;=0A =0A-            dma_set_pte_addr(*pte, =
maddr);=0A-            vaddr =3D map_vtd_domain_page(maddr);=0A+           =
 dma_set_pte_addr(*pte, pte_maddr);=0A =0A             /*=0A              =
* high level table always sets r/w, last level=0A@@ -303,21 +302,12 @@ =
static u64 addr_to_dma_page_maddr(struct=0A             dma_set_pte_writabl=
e(*pte);=0A             iommu_flush_cache_entry(pte, sizeof(struct =
dma_pte));=0A         }=0A-        else=0A-        {=0A-            vaddr =
=3D map_vtd_domain_page(pte->val);=0A-        }=0A =0A         if ( level =
=3D=3D 2 )=0A-        {=0A-            pte_maddr =3D pte->val & PAGE_MASK_4=
K;=0A-            unmap_vtd_domain_page(vaddr);=0A             break;=0A-  =
      }=0A =0A         unmap_vtd_domain_page(parent);=0A-        parent =
=3D (struct dma_pte *)vaddr;=0A-        vaddr =3D NULL;=0A+        parent =
=3D map_vtd_domain_page(pte_maddr);=0A         level--;=0A     }=0A =0A@@ =
-2449,7 +2439,7 @@ static void vtd_dump_p2m_table_level(pad=0A             =
printk("%*sgfn: %08lx mfn: %08lx\n",=0A                    indent, "",=0A  =
                  (unsigned long)(address >> PAGE_SHIFT_4K),=0A-           =
        (unsigned long)(pte->val >> PAGE_SHIFT_4K));=0A+                   =
(unsigned long)(dma_pte_addr(*pte) >> PAGE_SHIFT_4K));=0A     }=0A =0A     =
unmap_vtd_domain_page(pt_vaddr);=0A--- a/xen/drivers/passthrough/vtd/iommu.=
h=0A+++ b/xen/drivers/passthrough/vtd/iommu.h=0A@@ -276,7 +276,7 @@ struct =
dma_pte {=0A #define dma_set_pte_snp(p)  do {(p).val |=3D DMA_PTE_SNP;} =
while(0)=0A #define dma_set_pte_prot(p, prot) \=0A             do {(p).val =
=3D ((p).val & ~3) | ((prot) & 3); } while (0)=0A-#define dma_pte_addr(p) =
((p).val & PAGE_MASK_4K)=0A+#define dma_pte_addr(p) ((p).val & PADDR_MASK =
& PAGE_MASK_4K)=0A #define dma_set_pte_addr(p, addr) do {\=0A             =
(p).val |=3D ((addr) & PAGE_MASK_4K); } while (0)=0A #define dma_pte_presen=
t(p) (((p).val & 3) !=3D 0)=0A--- a/xen/drivers/passthrough/vtd/utils.c=0A+=
++ b/xen/drivers/passthrough/vtd/utils.c=0A@@ -170,16 +170,16 @@ void =
print_vtd_entries(struct iommu *iom=0A         l_index =3D get_level_index(=
gmfn, level);=0A         printk("    l%d_index =3D %x\n", level, =
l_index);=0A =0A-        pte.val =3D val =3D l[l_index];=0A+        =
pte.val =3D l[l_index];=0A         unmap_vtd_domain_page(l);=0A-        =
printk("    l%d[%x] =3D %"PRIx64"\n", level, l_index, val);=0A+        =
printk("    l%d[%x] =3D %"PRIx64"\n", level, l_index, pte.val);=0A =0A-    =
    pte.val =3D val;=0A         if ( !dma_pte_present(pte) )=0A         =
{=0A             printk("    l%d[%x] not present\n", level, l_index);=0A   =
          break;=0A         }=0A+        val =3D dma_pte_addr(pte);=0A     =
} while ( --level );=0A }=0A =0A
--=__PartE8DD254B.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

--=__PartE8DD254B.1__=--


From xen-devel-bounces@lists.xen.org Fri Dec 19 11:26:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:26:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vhP-0004AB-1f; Fri, 19 Dec 2014 11:26:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y1vhO-00049I-6Y
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 11:26:22 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	37/61-23865-D5B04945; Fri, 19 Dec 2014 11:26:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1418988379!14622293!1
X-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 6421 invoked from network); 19 Dec 2014 11:26: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; 19 Dec 2014 11:26:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 11:26:19 +0000
Message-Id: <5494196B0200007800050F6B@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 11:26:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE8DD254B.1__="
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>
Subject: [Xen-devel] [PATCH] VT-d: don't crash when PTE bits 52 and up are
	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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE8DD254B.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This can (and will) be legitimately the case when sharing page tables
with EPT (more of a problem before p2m_access_rwx became zero, but
still possible even now when other than that is the default for a
guest), leading to an unconditional crash (in print_vtd_entries())
when a DMA remapping fault occurs.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Regarding the release, if the changes to iommu.c are deemed too
extensive, then _I think_ they could be split off (that code ought to
come into play only when not sharing page tables between VT-d and EPT,
and VT-d code never sets the offending bits to non-zero values afaict).

--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -258,8 +258,7 @@ static u64 addr_to_dma_page_maddr(struct
     struct dma_pte *parent, *pte =3D NULL;
     int level =3D agaw_to_level(hd->arch.agaw);
     int offset;
-    u64 pte_maddr =3D 0, maddr;
-    u64 *vaddr =3D NULL;
+    u64 pte_maddr =3D 0;
=20
     addr &=3D (((u64)1) << addr_width) - 1;
     ASSERT(spin_is_locked(&hd->arch.mapping_lock));
@@ -281,19 +280,19 @@ static u64 addr_to_dma_page_maddr(struct
         offset =3D address_level_offset(addr, level);
         pte =3D &parent[offset];
=20
-        if ( dma_pte_addr(*pte) =3D=3D 0 )
+        pte_maddr =3D dma_pte_addr(*pte);
+        if ( !pte_maddr )
         {
             if ( !alloc )
                 break;
=20
             pdev =3D pci_get_pdev_by_domain(domain, -1, -1, -1);
             drhd =3D acpi_find_matched_drhd_unit(pdev);
-            maddr =3D alloc_pgtable_maddr(drhd, 1);
-            if ( !maddr )
+            pte_maddr =3D alloc_pgtable_maddr(drhd, 1);
+            if ( !pte_maddr )
                 break;
=20
-            dma_set_pte_addr(*pte, maddr);
-            vaddr =3D map_vtd_domain_page(maddr);
+            dma_set_pte_addr(*pte, pte_maddr);
=20
             /*
              * high level table always sets r/w, last level
@@ -303,21 +302,12 @@ static u64 addr_to_dma_page_maddr(struct
             dma_set_pte_writable(*pte);
             iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
         }
-        else
-        {
-            vaddr =3D map_vtd_domain_page(pte->val);
-        }
=20
         if ( level =3D=3D 2 )
-        {
-            pte_maddr =3D pte->val & PAGE_MASK_4K;
-            unmap_vtd_domain_page(vaddr);
             break;
-        }
=20
         unmap_vtd_domain_page(parent);
-        parent =3D (struct dma_pte *)vaddr;
-        vaddr =3D NULL;
+        parent =3D map_vtd_domain_page(pte_maddr);
         level--;
     }
=20
@@ -2449,7 +2439,7 @@ static void vtd_dump_p2m_table_level(pad
             printk("%*sgfn: %08lx mfn: %08lx\n",
                    indent, "",
                    (unsigned long)(address >> PAGE_SHIFT_4K),
-                   (unsigned long)(pte->val >> PAGE_SHIFT_4K));
+                   (unsigned long)(dma_pte_addr(*pte) >> PAGE_SHIFT_4K));
     }
=20
     unmap_vtd_domain_page(pt_vaddr);
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -276,7 +276,7 @@ struct dma_pte {
 #define dma_set_pte_snp(p)  do {(p).val |=3D DMA_PTE_SNP;} while(0)
 #define dma_set_pte_prot(p, prot) \
             do {(p).val =3D ((p).val & ~3) | ((prot) & 3); } while (0)
-#define dma_pte_addr(p) ((p).val & PAGE_MASK_4K)
+#define dma_pte_addr(p) ((p).val & PADDR_MASK & PAGE_MASK_4K)
 #define dma_set_pte_addr(p, addr) do {\
             (p).val |=3D ((addr) & PAGE_MASK_4K); } while (0)
 #define dma_pte_present(p) (((p).val & 3) !=3D 0)
--- a/xen/drivers/passthrough/vtd/utils.c
+++ b/xen/drivers/passthrough/vtd/utils.c
@@ -170,16 +170,16 @@ void print_vtd_entries(struct iommu *iom
         l_index =3D get_level_index(gmfn, level);
         printk("    l%d_index =3D %x\n", level, l_index);
=20
-        pte.val =3D val =3D l[l_index];
+        pte.val =3D l[l_index];
         unmap_vtd_domain_page(l);
-        printk("    l%d[%x] =3D %"PRIx64"\n", level, l_index, val);
+        printk("    l%d[%x] =3D %"PRIx64"\n", level, l_index, pte.val);
=20
-        pte.val =3D val;
         if ( !dma_pte_present(pte) )
         {
             printk("    l%d[%x] not present\n", level, l_index);
             break;
         }
+        val =3D dma_pte_addr(pte);
     } while ( --level );
 }
=20



--=__PartE8DD254B.1__=
Content-Type: text/plain; name="VT-d-mask-maddr.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="VT-d-mask-maddr.patch"

VT-d: don't crash when PTE bits 52 and up are non-zero=0A=0AThis can (and =
will) be legitimately the case when sharing page tables=0Awith EPT (more =
of a problem before p2m_access_rwx became zero, but=0Astill possible even =
now when other than that is the default for a=0Aguest), leading to an =
unconditional crash (in print_vtd_entries())=0Awhen a DMA remapping fault =
occurs.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0ARegardi=
ng the release, if the changes to iommu.c are deemed too=0Aextensive, then =
_I think_ they could be split off (that code ought to=0Acome into play =
only when not sharing page tables between VT-d and EPT,=0Aand VT-d code =
never sets the offending bits to non-zero values afaict).=0A=0A--- =
a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/i=
ommu.c=0A@@ -258,8 +258,7 @@ static u64 addr_to_dma_page_maddr(struct=0A   =
  struct dma_pte *parent, *pte =3D NULL;=0A     int level =3D agaw_to_level=
(hd->arch.agaw);=0A     int offset;=0A-    u64 pte_maddr =3D 0, maddr;=0A- =
   u64 *vaddr =3D NULL;=0A+    u64 pte_maddr =3D 0;=0A =0A     addr &=3D =
(((u64)1) << addr_width) - 1;=0A     ASSERT(spin_is_locked(&hd->arch.mappin=
g_lock));=0A@@ -281,19 +280,19 @@ static u64 addr_to_dma_page_maddr(struct=
=0A         offset =3D address_level_offset(addr, level);=0A         pte =
=3D &parent[offset];=0A =0A-        if ( dma_pte_addr(*pte) =3D=3D 0 )=0A+ =
       pte_maddr =3D dma_pte_addr(*pte);=0A+        if ( !pte_maddr )=0A   =
      {=0A             if ( !alloc )=0A                 break;=0A =0A      =
       pdev =3D pci_get_pdev_by_domain(domain, -1, -1, -1);=0A             =
drhd =3D acpi_find_matched_drhd_unit(pdev);=0A-            maddr =3D =
alloc_pgtable_maddr(drhd, 1);=0A-            if ( !maddr )=0A+            =
pte_maddr =3D alloc_pgtable_maddr(drhd, 1);=0A+            if ( !pte_maddr =
)=0A                 break;=0A =0A-            dma_set_pte_addr(*pte, =
maddr);=0A-            vaddr =3D map_vtd_domain_page(maddr);=0A+           =
 dma_set_pte_addr(*pte, pte_maddr);=0A =0A             /*=0A              =
* high level table always sets r/w, last level=0A@@ -303,21 +302,12 @@ =
static u64 addr_to_dma_page_maddr(struct=0A             dma_set_pte_writabl=
e(*pte);=0A             iommu_flush_cache_entry(pte, sizeof(struct =
dma_pte));=0A         }=0A-        else=0A-        {=0A-            vaddr =
=3D map_vtd_domain_page(pte->val);=0A-        }=0A =0A         if ( level =
=3D=3D 2 )=0A-        {=0A-            pte_maddr =3D pte->val & PAGE_MASK_4=
K;=0A-            unmap_vtd_domain_page(vaddr);=0A             break;=0A-  =
      }=0A =0A         unmap_vtd_domain_page(parent);=0A-        parent =
=3D (struct dma_pte *)vaddr;=0A-        vaddr =3D NULL;=0A+        parent =
=3D map_vtd_domain_page(pte_maddr);=0A         level--;=0A     }=0A =0A@@ =
-2449,7 +2439,7 @@ static void vtd_dump_p2m_table_level(pad=0A             =
printk("%*sgfn: %08lx mfn: %08lx\n",=0A                    indent, "",=0A  =
                  (unsigned long)(address >> PAGE_SHIFT_4K),=0A-           =
        (unsigned long)(pte->val >> PAGE_SHIFT_4K));=0A+                   =
(unsigned long)(dma_pte_addr(*pte) >> PAGE_SHIFT_4K));=0A     }=0A =0A     =
unmap_vtd_domain_page(pt_vaddr);=0A--- a/xen/drivers/passthrough/vtd/iommu.=
h=0A+++ b/xen/drivers/passthrough/vtd/iommu.h=0A@@ -276,7 +276,7 @@ struct =
dma_pte {=0A #define dma_set_pte_snp(p)  do {(p).val |=3D DMA_PTE_SNP;} =
while(0)=0A #define dma_set_pte_prot(p, prot) \=0A             do {(p).val =
=3D ((p).val & ~3) | ((prot) & 3); } while (0)=0A-#define dma_pte_addr(p) =
((p).val & PAGE_MASK_4K)=0A+#define dma_pte_addr(p) ((p).val & PADDR_MASK =
& PAGE_MASK_4K)=0A #define dma_set_pte_addr(p, addr) do {\=0A             =
(p).val |=3D ((addr) & PAGE_MASK_4K); } while (0)=0A #define dma_pte_presen=
t(p) (((p).val & 3) !=3D 0)=0A--- a/xen/drivers/passthrough/vtd/utils.c=0A+=
++ b/xen/drivers/passthrough/vtd/utils.c=0A@@ -170,16 +170,16 @@ void =
print_vtd_entries(struct iommu *iom=0A         l_index =3D get_level_index(=
gmfn, level);=0A         printk("    l%d_index =3D %x\n", level, =
l_index);=0A =0A-        pte.val =3D val =3D l[l_index];=0A+        =
pte.val =3D l[l_index];=0A         unmap_vtd_domain_page(l);=0A-        =
printk("    l%d[%x] =3D %"PRIx64"\n", level, l_index, val);=0A+        =
printk("    l%d[%x] =3D %"PRIx64"\n", level, l_index, pte.val);=0A =0A-    =
    pte.val =3D val;=0A         if ( !dma_pte_present(pte) )=0A         =
{=0A             printk("    l%d[%x] not present\n", level, l_index);=0A   =
          break;=0A         }=0A+        val =3D dma_pte_addr(pte);=0A     =
} while ( --level );=0A }=0A =0A
--=__PartE8DD254B.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

--=__PartE8DD254B.1__=--


From xen-devel-bounces@lists.xen.org Fri Dec 19 11:26:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:26:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vhQ-0004CM-P0; Fri, 19 Dec 2014 11:26:24 +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 1Y1vhP-0004AG-H8
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:26:23 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	AB/41-03148-E5B04945; Fri, 19 Dec 2014 11:26:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418988381!16159494!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16715 invoked from network); 19 Dec 2014 11:26:21 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:26:21 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988381; l=7657;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=jh5t+atVFM9H0FOciPnOEShcdA0=;
	b=Sgue15I+aYaJvQvmAuaKdGVEGYHFNnoR7N4eYJgWPwAWMKC8MATJw/zVbqdUeIfbwCe
	LudnTvq3MOAAz6LUfKwefzChoJdzy3KZI4dZhGEmrF6nG0iossXQym/gF7C/ub0MThaAl
	VzqZxMw4BFCTtJlNjUsrP+yLtQbwAeLgKF0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id n07f82qBJBQIW3y
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:26:18 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 90C1850173; Fri, 19 Dec 2014 12:25:41 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:33 +0100
Message-Id: <1418988333-5404-8-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 7/7] tools/hotplug: add wrapper to start
	xenstored
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The shell wrapper in xenstored.service does not handle XENSTORE_TRACE.

Create a separate wrapper script which is used in the sysv runlevel
script and in systemd xenstored.service. It preserves existing
behaviour by handling the XENSTORE_TRACE boolean. It also implements
the handling of XENSTORED_ARGS=. This variable has to be added to
sysconfig/xencommons.

The wrapper uses exec unconditionally. This works because the
systemd service file passes --no-fork, which has the desired effect
that the binary launched by systemd becomes the final daemon
process. The sysv script does not pass --no-fork, which causes
xenstored to fork internally to return to the caller of the wrapper
script.

The place of the wrapper is currently LIBEXEC_BIN, it has to be
decided what the final location is supposed to be. IanJ wants it in
"/etc".

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 .gitignore                                       | 1 +
 tools/configure                                  | 3 ++-
 tools/configure.ac                               | 1 +
 tools/hotplug/Linux/Makefile                     | 2 ++
 tools/hotplug/Linux/init.d/xencommons.in         | 6 ++++--
 tools/hotplug/Linux/systemd/xenstored.service.in | 5 ++---
 tools/hotplug/Linux/xenstored.sh.in              | 6 ++++++
 7 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/.gitignore b/.gitignore
index 8c8c06f..7e6884a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -153,6 +153,7 @@ tools/hotplug/Linux/vif-setup
 tools/hotplug/Linux/xen-backend.rules
 tools/hotplug/Linux/xen-hotplug-common.sh
 tools/hotplug/Linux/xendomains
+tools/hotplug/Linux/xenstored.sh
 tools/hotplug/NetBSD/rc.d/xencommons
 tools/include/xen/*
 tools/include/xen-foreign/*.(c|h|size)
diff --git a/tools/configure b/tools/configure
index b0aea0a..e72876c 100755
--- a/tools/configure
+++ b/tools/configure
@@ -2276,7 +2276,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 
 
-ac_config_files="$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket hotplug/Linux/vif-setup hotplug/Linux/xen-backend.rules hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons"
+ac_config_files="$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket hotplug/Linux/vif-setup hotplug/Linux/xen-backend.rules hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/Linux/xenstored.sh hotplug/NetBSD/rc.d/xencommons"
 
 ac_config_headers="$ac_config_headers config.h"
 
@@ -9585,6 +9585,7 @@ do
     "hotplug/Linux/xen-backend.rules") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xen-backend.rules" ;;
     "hotplug/Linux/xen-hotplug-common.sh") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xen-hotplug-common.sh" ;;
     "hotplug/Linux/xendomains") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xendomains" ;;
+    "hotplug/Linux/xenstored.sh") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xenstored.sh" ;;
     "hotplug/NetBSD/rc.d/xencommons") CONFIG_FILES="$CONFIG_FILES hotplug/NetBSD/rc.d/xencommons" ;;
     "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;;
 
diff --git a/tools/configure.ac b/tools/configure.ac
index 1ac63a3..8f198e8 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -26,6 +26,7 @@ hotplug/Linux/vif-setup
 hotplug/Linux/xen-backend.rules
 hotplug/Linux/xen-hotplug-common.sh
 hotplug/Linux/xendomains
+hotplug/Linux/xenstored.sh
 hotplug/NetBSD/rc.d/xencommons
 ])
 AC_CONFIG_HEADERS([config.h])
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 1706c05..e9a1ef0 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -2,6 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 # Init scripts.
+XENSTORED_LIBEXEC = xenstored.sh
 XENDOMAINS_INITD = init.d/xendomains
 XENDOMAINS_LIBEXEC = xendomains
 XENDOMAINS_SYSCONFIG = init.d/sysconfig.xendomains
@@ -51,6 +52,7 @@ install-initd:
 	[ -d $(DESTDIR)$(INITD_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(INITD_DIR)
 	[ -d $(DESTDIR)$(SYSCONFIG_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(SYSCONFIG_DIR)
 	[ -d $(DESTDIR)$(LIBEXEC_BIN) ] || $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
+	$(INSTALL_PROG) $(XENSTORED_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)
 	$(INSTALL_PROG) $(XENDOMAINS_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)
 	$(INSTALL_PROG) $(XENDOMAINS_INITD) $(DESTDIR)$(INITD_DIR)
 	$(INSTALL_DATA) $(XENDOMAINS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xendomains
diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
index a1095c2..f57bfd3 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -66,11 +66,13 @@ do_start () {
 	then
 		test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
 		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
-		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
 
 		if [ -n "$XENSTORED" ] ; then
 		    echo -n Starting $XENSTORED...
-		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		    XENSTORED=$XENSTORED \
+		    XENSTORED_TRACE=$XENSTORED_TRACE \
+		    XENSTORED_ARGS=$XENSTORED_ARGS \
+		    ${LIBEXEC_BIN}/xenstored.sh --pid-file /var/run/xenstored.pid
 		else
 		    echo "No xenstored found"
 		    exit 1
diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 0f0ac58..a048b21 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -8,13 +8,12 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=notify
-Environment=XENSTORED_ARGS=
 Environment=XENSTORED=@XENSTORED@
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/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@
-ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
+ExecStart=@LIBEXEC_BIN@/xenstored.sh --no-fork
 
 [Install]
 WantedBy=multi-user.target
diff --git a/tools/hotplug/Linux/xenstored.sh.in b/tools/hotplug/Linux/xenstored.sh.in
new file mode 100644
index 0000000..dc806ee
--- /dev/null
+++ b/tools/hotplug/Linux/xenstored.sh.in
@@ -0,0 +1,6 @@
+#!/bin/sh
+if test -n "$XENSTORED_TRACE"
+then
+	XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
+fi
+exec $XENSTORED $@ $XENSTORED_ARGS

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:26:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:26:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vhQ-0004CM-P0; Fri, 19 Dec 2014 11:26:24 +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 1Y1vhP-0004AG-H8
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 11:26:23 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	AB/41-03148-E5B04945; Fri, 19 Dec 2014 11:26:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1418988381!16159494!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16715 invoked from network); 19 Dec 2014 11:26:21 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.160)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 11:26:21 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1418988381; l=7657;
	s=domk; d=aepfle.de;
	h=References:In-Reply-To:Date:Subject:Cc:To:From;
	bh=jh5t+atVFM9H0FOciPnOEShcdA0=;
	b=Sgue15I+aYaJvQvmAuaKdGVEGYHFNnoR7N4eYJgWPwAWMKC8MATJw/zVbqdUeIfbwCe
	LudnTvq3MOAAz6LUfKwefzChoJdzy3KZI4dZhGEmrF6nG0iossXQym/gF7C/ub0MThaAl
	VzqZxMw4BFCTtJlNjUsrP+yLtQbwAeLgKF0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id n07f82qBJBQIW3y
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 12:26:18 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 90C1850173; Fri, 19 Dec 2014 12:25:41 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Date: Fri, 19 Dec 2014 12:25:33 +0100
Message-Id: <1418988333-5404-8-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 2.2.0
In-Reply-To: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
Cc: Olaf Hering <olaf@aepfle.de>, 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>, m.a.young@durham.ac.uk
Subject: [Xen-devel] [PATCH 7/7] tools/hotplug: add wrapper to start
	xenstored
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The shell wrapper in xenstored.service does not handle XENSTORE_TRACE.

Create a separate wrapper script which is used in the sysv runlevel
script and in systemd xenstored.service. It preserves existing
behaviour by handling the XENSTORE_TRACE boolean. It also implements
the handling of XENSTORED_ARGS=. This variable has to be added to
sysconfig/xencommons.

The wrapper uses exec unconditionally. This works because the
systemd service file passes --no-fork, which has the desired effect
that the binary launched by systemd becomes the final daemon
process. The sysv script does not pass --no-fork, which causes
xenstored to fork internally to return to the caller of the wrapper
script.

The place of the wrapper is currently LIBEXEC_BIN, it has to be
decided what the final location is supposed to be. IanJ wants it in
"/etc".

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 .gitignore                                       | 1 +
 tools/configure                                  | 3 ++-
 tools/configure.ac                               | 1 +
 tools/hotplug/Linux/Makefile                     | 2 ++
 tools/hotplug/Linux/init.d/xencommons.in         | 6 ++++--
 tools/hotplug/Linux/systemd/xenstored.service.in | 5 ++---
 tools/hotplug/Linux/xenstored.sh.in              | 6 ++++++
 7 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/.gitignore b/.gitignore
index 8c8c06f..7e6884a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -153,6 +153,7 @@ tools/hotplug/Linux/vif-setup
 tools/hotplug/Linux/xen-backend.rules
 tools/hotplug/Linux/xen-hotplug-common.sh
 tools/hotplug/Linux/xendomains
+tools/hotplug/Linux/xenstored.sh
 tools/hotplug/NetBSD/rc.d/xencommons
 tools/include/xen/*
 tools/include/xen-foreign/*.(c|h|size)
diff --git a/tools/configure b/tools/configure
index b0aea0a..e72876c 100755
--- a/tools/configure
+++ b/tools/configure
@@ -2276,7 +2276,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 
 
-ac_config_files="$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket hotplug/Linux/vif-setup hotplug/Linux/xen-backend.rules hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons"
+ac_config_files="$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket hotplug/Linux/vif-setup hotplug/Linux/xen-backend.rules hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/Linux/xenstored.sh hotplug/NetBSD/rc.d/xencommons"
 
 ac_config_headers="$ac_config_headers config.h"
 
@@ -9585,6 +9585,7 @@ do
     "hotplug/Linux/xen-backend.rules") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xen-backend.rules" ;;
     "hotplug/Linux/xen-hotplug-common.sh") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xen-hotplug-common.sh" ;;
     "hotplug/Linux/xendomains") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xendomains" ;;
+    "hotplug/Linux/xenstored.sh") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xenstored.sh" ;;
     "hotplug/NetBSD/rc.d/xencommons") CONFIG_FILES="$CONFIG_FILES hotplug/NetBSD/rc.d/xencommons" ;;
     "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;;
 
diff --git a/tools/configure.ac b/tools/configure.ac
index 1ac63a3..8f198e8 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -26,6 +26,7 @@ hotplug/Linux/vif-setup
 hotplug/Linux/xen-backend.rules
 hotplug/Linux/xen-hotplug-common.sh
 hotplug/Linux/xendomains
+hotplug/Linux/xenstored.sh
 hotplug/NetBSD/rc.d/xencommons
 ])
 AC_CONFIG_HEADERS([config.h])
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 1706c05..e9a1ef0 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -2,6 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 # Init scripts.
+XENSTORED_LIBEXEC = xenstored.sh
 XENDOMAINS_INITD = init.d/xendomains
 XENDOMAINS_LIBEXEC = xendomains
 XENDOMAINS_SYSCONFIG = init.d/sysconfig.xendomains
@@ -51,6 +52,7 @@ install-initd:
 	[ -d $(DESTDIR)$(INITD_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(INITD_DIR)
 	[ -d $(DESTDIR)$(SYSCONFIG_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(SYSCONFIG_DIR)
 	[ -d $(DESTDIR)$(LIBEXEC_BIN) ] || $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
+	$(INSTALL_PROG) $(XENSTORED_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)
 	$(INSTALL_PROG) $(XENDOMAINS_LIBEXEC) $(DESTDIR)$(LIBEXEC_BIN)
 	$(INSTALL_PROG) $(XENDOMAINS_INITD) $(DESTDIR)$(INITD_DIR)
 	$(INSTALL_DATA) $(XENDOMAINS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xendomains
diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in
index a1095c2..f57bfd3 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -66,11 +66,13 @@ do_start () {
 	then
 		test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
 		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
-		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
 
 		if [ -n "$XENSTORED" ] ; then
 		    echo -n Starting $XENSTORED...
-		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		    XENSTORED=$XENSTORED \
+		    XENSTORED_TRACE=$XENSTORED_TRACE \
+		    XENSTORED_ARGS=$XENSTORED_ARGS \
+		    ${LIBEXEC_BIN}/xenstored.sh --pid-file /var/run/xenstored.pid
 		else
 		    echo "No xenstored found"
 		    exit 1
diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
index 0f0ac58..a048b21 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -8,13 +8,12 @@ ConditionPathExists=/proc/xen/capabilities
 
 [Service]
 Type=notify
-Environment=XENSTORED_ARGS=
 Environment=XENSTORED=@XENSTORED@
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/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@
-ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
+ExecStart=@LIBEXEC_BIN@/xenstored.sh --no-fork
 
 [Install]
 WantedBy=multi-user.target
diff --git a/tools/hotplug/Linux/xenstored.sh.in b/tools/hotplug/Linux/xenstored.sh.in
new file mode 100644
index 0000000..dc806ee
--- /dev/null
+++ b/tools/hotplug/Linux/xenstored.sh.in
@@ -0,0 +1,6 @@
+#!/bin/sh
+if test -n "$XENSTORED_TRACE"
+then
+	XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
+fi
+exec $XENSTORED $@ $XENSTORED_ARGS

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:32:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:32:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vn1-0005NQ-Jv; Fri, 19 Dec 2014 11:32:11 +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 1Y1vmz-0005M9-Hg
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 11:32:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F9/E0-09842-8BC04945; Fri, 19 Dec 2014 11:32:08 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418988727!16742881!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 22342 invoked from network); 19 Dec 2014 11:32:08 -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 Dec 2014 11:32:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206193811"
Message-ID: <54940CB5.1020105@citrix.com>
Date: Fri, 19 Dec 2014 11:32: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: Jan Beulich <JBeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
	<5493224D.9050001@citrix.com>
	<5493F9DF0200007800050E9D@mail.emea.novell.com>
In-Reply-To: <5493F9DF0200007800050E9D@mail.emea.novell.com>
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
	from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTkvMTIvMTQgMDk6MTEsIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+IE9uIDE4LjEyLjE0IGF0
IDE5OjUxLCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3JvdGU6Cj4+IE9uIDE4LzEyLzE0
IDE4OjI3LCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+PiBQcmV2ZW50IERvbTAgZnJvbSBhY2Nl
c3NpbmcgSFBFVCBNTUlPIHJlZ2lvbiBieSBhZGRpbmcgaXQgdG8gdGhlIGxpc3Qgb2YKPj4+IGRl
bmllZCBtZW1vcnkgcmVnaW9ucy4KPj4+Cj4+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9u
bsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPj4+IENjOiBKYW4gQmV1bGljaCA8amJldWxpY2hA
c3VzZS5jb20+Cj4+PiBDYzogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KPj4gQXBvbG9naWVzIHRoYXQgdGhpcyByZXBseSBpcyBzcGxpdCBiZXR3ZWVuIHBhdGNoIDAg
YW5kIDIgLSBJIHJlcGxpZWQgdG8KPj4geW91ciBjb3ZlciBsZXR0ZXIgYmVmb3JlIHJlYWRpbmcg
dGhpcyBwYXRjaC4KPj4KPj4gRGVueWluZyBhY2Nlc3MgaXMgb25seSB2YWxpZCBpZiBhY3BpX3Rh
YmxlX2hwZXQuZmxhZ3MgJiAKPj4gQUNQSV9IUEVUX1BBR0VfUFJPVEVDVDQgaXMgdHJ1ZS4KPiBI
YXZpbmcganVzdCBjaGVja2VkIChhcyBhbiBleGFtcGxlKSB0aGUgbW9zdCBtb2Rlcm4gSW50ZWwg
Ym94IEkKPiBoYXZlIGRpcmVjdCBhY2Nlc3MgdG8sIEkgd29uZGVyIGhvdyBtYW55IHN5c3RlbXMg
YWN0dWFsbHkgc3VwcGx5Cj4gb3RoZXIgdGhhbiAwIGhlcmUuIFBlcmhhcHMgd2Ugb3VnaHQgdG8g
YXQgb25jZSBhZGQgYSBjb21tYW5kCj4gbGluZSBvcHRpb24gdG8gdHJpZ2dlciB0aGUgZGVuaWFs
PwoKSSBhbHNvIGNhbid0IGZpbmQgYSBzZXJ2ZXIgd2hpY2ggc2V0cyB0aGlzIGZsYWcuICBJIHdv
bmRlciBob3cgbWFueQpzeXN0ZW1zIGFjdHVhbGx5IGhhdmUgb3RoZXIgdGhpbmdzIHNpdHRpbmcg
aW4gdGhlIHJlbWFpbmRlciBvZiB0aGUgcGFnZS4KCn5BbmRyZXcKCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Dec 19 11:32:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 11:32:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1vn1-0005NQ-Jv; Fri, 19 Dec 2014 11:32:11 +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 1Y1vmz-0005M9-Hg
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 11:32:09 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	F9/E0-09842-8BC04945; Fri, 19 Dec 2014 11:32:08 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1418988727!16742881!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 22342 invoked from network); 19 Dec 2014 11:32:08 -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 Dec 2014 11:32:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206193811"
Message-ID: <54940CB5.1020105@citrix.com>
Date: Fri, 19 Dec 2014 11:32: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: Jan Beulich <JBeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
	<5493224D.9050001@citrix.com>
	<5493F9DF0200007800050E9D@mail.emea.novell.com>
In-Reply-To: <5493F9DF0200007800050E9D@mail.emea.novell.com>
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
	from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMTkvMTIvMTQgMDk6MTEsIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+IE9uIDE4LjEyLjE0IGF0
IDE5OjUxLCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3JvdGU6Cj4+IE9uIDE4LzEyLzE0
IDE4OjI3LCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+PiBQcmV2ZW50IERvbTAgZnJvbSBhY2Nl
c3NpbmcgSFBFVCBNTUlPIHJlZ2lvbiBieSBhZGRpbmcgaXQgdG8gdGhlIGxpc3Qgb2YKPj4+IGRl
bmllZCBtZW1vcnkgcmVnaW9ucy4KPj4+Cj4+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9u
bsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPj4+IENjOiBKYW4gQmV1bGljaCA8amJldWxpY2hA
c3VzZS5jb20+Cj4+PiBDYzogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KPj4gQXBvbG9naWVzIHRoYXQgdGhpcyByZXBseSBpcyBzcGxpdCBiZXR3ZWVuIHBhdGNoIDAg
YW5kIDIgLSBJIHJlcGxpZWQgdG8KPj4geW91ciBjb3ZlciBsZXR0ZXIgYmVmb3JlIHJlYWRpbmcg
dGhpcyBwYXRjaC4KPj4KPj4gRGVueWluZyBhY2Nlc3MgaXMgb25seSB2YWxpZCBpZiBhY3BpX3Rh
YmxlX2hwZXQuZmxhZ3MgJiAKPj4gQUNQSV9IUEVUX1BBR0VfUFJPVEVDVDQgaXMgdHJ1ZS4KPiBI
YXZpbmcganVzdCBjaGVja2VkIChhcyBhbiBleGFtcGxlKSB0aGUgbW9zdCBtb2Rlcm4gSW50ZWwg
Ym94IEkKPiBoYXZlIGRpcmVjdCBhY2Nlc3MgdG8sIEkgd29uZGVyIGhvdyBtYW55IHN5c3RlbXMg
YWN0dWFsbHkgc3VwcGx5Cj4gb3RoZXIgdGhhbiAwIGhlcmUuIFBlcmhhcHMgd2Ugb3VnaHQgdG8g
YXQgb25jZSBhZGQgYSBjb21tYW5kCj4gbGluZSBvcHRpb24gdG8gdHJpZ2dlciB0aGUgZGVuaWFs
PwoKSSBhbHNvIGNhbid0IGZpbmQgYSBzZXJ2ZXIgd2hpY2ggc2V0cyB0aGlzIGZsYWcuICBJIHdv
bmRlciBob3cgbWFueQpzeXN0ZW1zIGFjdHVhbGx5IGhhdmUgb3RoZXIgdGhpbmdzIHNpdHRpbmcg
aW4gdGhlIHJlbWFpbmRlciBvZiB0aGUgcGFnZS4KCn5BbmRyZXcKCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Dec 19 12:10:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 12:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1wNG-0006we-IV; Fri, 19 Dec 2014 12:09:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <upanshu.singhal@emc.com>) id 1Y1wIk-0006u7-S0
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 12:04:59 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	12/DD-15461-A6414945; Fri, 19 Dec 2014 12:04:58 +0000
X-Env-Sender: upanshu.singhal@emc.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418990696!16726462!1
X-Originating-IP: [128.221.224.79]
X-SpamReason: No, hits=1.5 required=7.0 tests=HOT_NASTY,HTML_60_70,
	HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6977 invoked from network); 19 Dec 2014 12:04:57 -0000
Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2014 12:04:57 -0000
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com
	[10.106.48.156])
	by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBJC4tKM006177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Fri, 19 Dec 2014 07:04:55 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com sBJC4tKM006177
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013;
	t=1418990695; bh=G7GHse6QnV/nPsRkkx3FFqdkIUU=;
	h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version;
	b=HTP06ilWhTVoLk8JEMZxk7NASEPieCx/gOtjlEV8BvMcMb3Rbvb1IvEEyMSnCoGpb
	LybuUkHfTcBzvdzQ/yZ8XRAMlHQdr6Pm7PvHZ+C8snreLg9i5JzMWjMNSQ/+GtN6Ou
	6EyIcwuRyA/8u0FC1CQ1QEFlnS8dRYbIDbNrBojI=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com sBJC4tKM006177
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com
	[10.106.48.18]) by maildlpprd52.lss.emc.com (RSA Interceptor)
	for <xen-devel@lists.xen.org>; Fri, 19 Dec 2014 07:04:44 -0500
Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172])
	by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBJC4YAL004725
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Fri, 19 Dec 2014 07:04:34 -0500
Received: from MXHUB104.corp.emc.com (10.253.58.16) by mxhub32.corp.emc.com
	(128.222.70.172) with Microsoft SMTP Server (TLS) id 8.3.327.1;
	Fri, 19 Dec 2014 07:04:33 -0500
Received: from MX101CL01.corp.emc.com ([169.254.1.90]) by
	MXHUB104.corp.emc.com ([::1]) with mapi id 14.03.0195.001;
	Fri, 19 Dec 2014 07:04:33 -0500
From: "Singhal, Upanshu" <upanshu.singhal@emc.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Help: VMXNET3 support with XEN 4.4.1
Thread-Index: AdAbg+gVpGg69F+/TKC4f+QiMDYySw==
Date: Fri, 19 Dec 2014 12:04:33 +0000
Message-ID: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.30.79.11]
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: DLP to NYP, public
X-Mailman-Approved-At: Fri, 19 Dec 2014 12:09:35 +0000
Subject: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4754181612258490231=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4754181612258490231==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_6A5D14D0DFEABC43BE832A0E492963F14EBB836CMX101CL01corpem_"

--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB836CMX101CL01corpem_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

In one of my experiment, I am building a Linux VM with Network interface mo=
del as "vmxnet3". I am able to create the VM successfully, but I see that t=
he driver loaded is "vif" and not "vmxnet3". I am using the following optio=
n for the network interface: vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:=
22, bridge=3Dxenbr0, model=3Dvmxnet3' ]

I tried with model as e1000 and it works fine. Lspci command also does not =
show vmxnet3. Though, qemu device help shows that "vmxnet3" is supported on=
 XEN 4.4.1 version I am using.

I tried searching on internet about the right configuration for vmxnet3 wit=
h XEN, but not able to find right information. Can someone please help me o=
n how to create a VM with vmxnet3?

This experiment I am doing to compare the difference between vmxnet3 bandwi=
dth on VMWARE ESXi vs. XEN Server. My sample VM configuration file is:

# This configures an HVM rather than PV guest
builder =3D "hvm"

# Guest name
name =3D "rhel-vmxnet3-xen-2.hvm"

# 128-bit UUID for the domain as a hexadecimal number.
# Use "uuidgen" to generate one if required.
# The default behavior is to generate a new UUID each time the guest is sta=
rted.
#uuid =3D "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

# Enable Microsoft Hyper-V compatibile paravirtualisation /
# enlightenment interfaces. Turning this on can improve Windows guest
# performance and is therefore recommended
#viridian =3D 1

# Initial memory allocation (MB)
memory =3D 8192

# Maximum memory (MB)
# If this is greater than `memory' then the slack will start ballooned
# (this assumes guest kernel support for ballooning)
#maxmem =3D 512

# Number of VCPUS
vcpus =3D 8

# Network devices
# A list of 'vifspec' entries as described in
# docs/misc/xl-network-configuration.markdown
vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dxenbr1, model=3D=
vmxnet3' ]

# Disk Devices
# A list of `diskspec' entries as described in
# docs/misc/xl-disk-configuration.txt
disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', 'file:/root=
/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r' ]
boot=3D'cd'

# Guest VGA console configuration, either SDL or VNC
# sdl =3D 1
vnc =3D 2

Thanks,
-Upanshu


Upanshu Singhal
EMC Data Storage Systems, Bangalore, India.
Phone: 91-80-67375604


--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB836CMX101CL01corpem_
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;}
/* 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">Hello,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">In one of my experiment, I am building a Linux VM wi=
th Network interface model as &#8220;vmxnet3&#8221;. I am able to create th=
e VM successfully, but I see that the driver loaded is &#8220;vif&#8221; an=
d not &#8220;vmxnet3&#8221;. I am using the following option for the networ=
k
 interface: <b>vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dx=
enbr0, model=3Dvmxnet3' ]<o:p></o:p></b></p>
<p class=3D"MsoNormal"><b><o:p>&nbsp;</o:p></b></p>
<p class=3D"MsoNormal">I tried with model as e1000 and it works fine. Lspci=
 command also does not show vmxnet3. Though, qemu device help shows that &#=
8220;vmxnet3&#8221; is supported on XEN 4.4.1 version I am using.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I tried searching on internet about the right config=
uration for vmxnet3 with XEN, but not able to find right information. Can s=
omeone please help me on how to create a VM with vmxnet3?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">This experiment I am doing to compare the difference=
 between vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM conf=
iguration file is:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># This configures an HVM rather than PV guest<o:p></=
o:p></p>
<p class=3D"MsoNormal">builder =3D &quot;hvm&quot;<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Guest name<o:p></o:p></p>
<p class=3D"MsoNormal"><b>name =3D &quot;rhel-vmxnet3-xen-2.hvm&quot;<o:p><=
/o:p></b></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># 128-bit UUID for the domain as a hexadecimal numbe=
r.<o:p></o:p></p>
<p class=3D"MsoNormal"># Use &quot;uuidgen&quot; to generate one if require=
d.<o:p></o:p></p>
<p class=3D"MsoNormal"># The default behavior is to generate a new UUID eac=
h time the guest is started.<o:p></o:p></p>
<p class=3D"MsoNormal">#uuid =3D &quot;XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=
&quot;<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Enable Microsoft Hyper-V compatibile paravirtualis=
ation /<o:p></o:p></p>
<p class=3D"MsoNormal"># enlightenment interfaces. Turning this on can impr=
ove Windows guest<o:p></o:p></p>
<p class=3D"MsoNormal"># performance and is therefore recommended<o:p></o:p=
></p>
<p class=3D"MsoNormal">#viridian =3D 1<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Initial memory allocation (MB)<o:p></o:p></p>
<p class=3D"MsoNormal"><b>memory =3D 8192<o:p></o:p></b></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Maximum memory (MB)<o:p></o:p></p>
<p class=3D"MsoNormal"># If this is greater than `memory' then the slack wi=
ll start ballooned<o:p></o:p></p>
<p class=3D"MsoNormal"># (this assumes guest kernel support for ballooning)=
<o:p></o:p></p>
<p class=3D"MsoNormal">#maxmem =3D 512<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Number of VCPUS<o:p></o:p></p>
<p class=3D"MsoNormal"><b>vcpus =3D 8<o:p></o:p></b></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Network devices<o:p></o:p></p>
<p class=3D"MsoNormal"># A list of 'vifspec' entries as described in<o:p></=
o:p></p>
<p class=3D"MsoNormal"># docs/misc/xl-network-configuration.markdown<o:p></=
o:p></p>
<p class=3D"MsoNormal">vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, br=
idge=3Dxenbr1, model=3Dvmxnet3' ]<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Disk Devices<o:p></o:p></p>
<p class=3D"MsoNormal"># A list of `diskspec' entries as described in<o:p><=
/o:p></p>
<p class=3D"MsoNormal"># docs/misc/xl-disk-configuration.txt<o:p></o:p></p>
<p class=3D"MsoNormal"><b>disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img=
,raw,xvda,rw', 'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r' ]<o:=
p></o:p></b></p>
<p class=3D"MsoNormal"><b>boot=3D'cd'</b><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Guest VGA console configuration, either SDL or VNC=
<o:p></o:p></p>
<p class=3D"MsoNormal"># sdl =3D 1<o:p></o:p></p>
<p class=3D"MsoNormal"><b>vnc =3D 2<o:p></o:p></b></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal">-Upanshu<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Upanshu Singhal<o:p></o:p></p>
<p class=3D"MsoNormal">EMC Data Storage Systems, Bangalore, India.<o:p></o:=
p></p>
<p class=3D"MsoNormal">Phone: 91-80-67375604<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB836CMX101CL01corpem_--


--===============4754181612258490231==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4754181612258490231==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 12:10:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 12:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1wNG-0006we-IV; Fri, 19 Dec 2014 12:09:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <upanshu.singhal@emc.com>) id 1Y1wIk-0006u7-S0
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 12:04:59 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	12/DD-15461-A6414945; Fri, 19 Dec 2014 12:04:58 +0000
X-Env-Sender: upanshu.singhal@emc.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1418990696!16726462!1
X-Originating-IP: [128.221.224.79]
X-SpamReason: No, hits=1.5 required=7.0 tests=HOT_NASTY,HTML_60_70,
	HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6977 invoked from network); 19 Dec 2014 12:04:57 -0000
Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Dec 2014 12:04:57 -0000
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com
	[10.106.48.156])
	by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBJC4tKM006177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Fri, 19 Dec 2014 07:04:55 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com sBJC4tKM006177
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013;
	t=1418990695; bh=G7GHse6QnV/nPsRkkx3FFqdkIUU=;
	h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version;
	b=HTP06ilWhTVoLk8JEMZxk7NASEPieCx/gOtjlEV8BvMcMb3Rbvb1IvEEyMSnCoGpb
	LybuUkHfTcBzvdzQ/yZ8XRAMlHQdr6Pm7PvHZ+C8snreLg9i5JzMWjMNSQ/+GtN6Ou
	6EyIcwuRyA/8u0FC1CQ1QEFlnS8dRYbIDbNrBojI=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com sBJC4tKM006177
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com
	[10.106.48.18]) by maildlpprd52.lss.emc.com (RSA Interceptor)
	for <xen-devel@lists.xen.org>; Fri, 19 Dec 2014 07:04:44 -0500
Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172])
	by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBJC4YAL004725
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Fri, 19 Dec 2014 07:04:34 -0500
Received: from MXHUB104.corp.emc.com (10.253.58.16) by mxhub32.corp.emc.com
	(128.222.70.172) with Microsoft SMTP Server (TLS) id 8.3.327.1;
	Fri, 19 Dec 2014 07:04:33 -0500
Received: from MX101CL01.corp.emc.com ([169.254.1.90]) by
	MXHUB104.corp.emc.com ([::1]) with mapi id 14.03.0195.001;
	Fri, 19 Dec 2014 07:04:33 -0500
From: "Singhal, Upanshu" <upanshu.singhal@emc.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Help: VMXNET3 support with XEN 4.4.1
Thread-Index: AdAbg+gVpGg69F+/TKC4f+QiMDYySw==
Date: Fri, 19 Dec 2014 12:04:33 +0000
Message-ID: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.30.79.11]
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: DLP to NYP, public
X-Mailman-Approved-At: Fri, 19 Dec 2014 12:09:35 +0000
Subject: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4754181612258490231=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4754181612258490231==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_6A5D14D0DFEABC43BE832A0E492963F14EBB836CMX101CL01corpem_"

--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB836CMX101CL01corpem_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

In one of my experiment, I am building a Linux VM with Network interface mo=
del as "vmxnet3". I am able to create the VM successfully, but I see that t=
he driver loaded is "vif" and not "vmxnet3". I am using the following optio=
n for the network interface: vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:=
22, bridge=3Dxenbr0, model=3Dvmxnet3' ]

I tried with model as e1000 and it works fine. Lspci command also does not =
show vmxnet3. Though, qemu device help shows that "vmxnet3" is supported on=
 XEN 4.4.1 version I am using.

I tried searching on internet about the right configuration for vmxnet3 wit=
h XEN, but not able to find right information. Can someone please help me o=
n how to create a VM with vmxnet3?

This experiment I am doing to compare the difference between vmxnet3 bandwi=
dth on VMWARE ESXi vs. XEN Server. My sample VM configuration file is:

# This configures an HVM rather than PV guest
builder =3D "hvm"

# Guest name
name =3D "rhel-vmxnet3-xen-2.hvm"

# 128-bit UUID for the domain as a hexadecimal number.
# Use "uuidgen" to generate one if required.
# The default behavior is to generate a new UUID each time the guest is sta=
rted.
#uuid =3D "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

# Enable Microsoft Hyper-V compatibile paravirtualisation /
# enlightenment interfaces. Turning this on can improve Windows guest
# performance and is therefore recommended
#viridian =3D 1

# Initial memory allocation (MB)
memory =3D 8192

# Maximum memory (MB)
# If this is greater than `memory' then the slack will start ballooned
# (this assumes guest kernel support for ballooning)
#maxmem =3D 512

# Number of VCPUS
vcpus =3D 8

# Network devices
# A list of 'vifspec' entries as described in
# docs/misc/xl-network-configuration.markdown
vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dxenbr1, model=3D=
vmxnet3' ]

# Disk Devices
# A list of `diskspec' entries as described in
# docs/misc/xl-disk-configuration.txt
disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', 'file:/root=
/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r' ]
boot=3D'cd'

# Guest VGA console configuration, either SDL or VNC
# sdl =3D 1
vnc =3D 2

Thanks,
-Upanshu


Upanshu Singhal
EMC Data Storage Systems, Bangalore, India.
Phone: 91-80-67375604


--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB836CMX101CL01corpem_
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;}
/* 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">Hello,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">In one of my experiment, I am building a Linux VM wi=
th Network interface model as &#8220;vmxnet3&#8221;. I am able to create th=
e VM successfully, but I see that the driver loaded is &#8220;vif&#8221; an=
d not &#8220;vmxnet3&#8221;. I am using the following option for the networ=
k
 interface: <b>vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dx=
enbr0, model=3Dvmxnet3' ]<o:p></o:p></b></p>
<p class=3D"MsoNormal"><b><o:p>&nbsp;</o:p></b></p>
<p class=3D"MsoNormal">I tried with model as e1000 and it works fine. Lspci=
 command also does not show vmxnet3. Though, qemu device help shows that &#=
8220;vmxnet3&#8221; is supported on XEN 4.4.1 version I am using.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I tried searching on internet about the right config=
uration for vmxnet3 with XEN, but not able to find right information. Can s=
omeone please help me on how to create a VM with vmxnet3?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">This experiment I am doing to compare the difference=
 between vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM conf=
iguration file is:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># This configures an HVM rather than PV guest<o:p></=
o:p></p>
<p class=3D"MsoNormal">builder =3D &quot;hvm&quot;<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Guest name<o:p></o:p></p>
<p class=3D"MsoNormal"><b>name =3D &quot;rhel-vmxnet3-xen-2.hvm&quot;<o:p><=
/o:p></b></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># 128-bit UUID for the domain as a hexadecimal numbe=
r.<o:p></o:p></p>
<p class=3D"MsoNormal"># Use &quot;uuidgen&quot; to generate one if require=
d.<o:p></o:p></p>
<p class=3D"MsoNormal"># The default behavior is to generate a new UUID eac=
h time the guest is started.<o:p></o:p></p>
<p class=3D"MsoNormal">#uuid =3D &quot;XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=
&quot;<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Enable Microsoft Hyper-V compatibile paravirtualis=
ation /<o:p></o:p></p>
<p class=3D"MsoNormal"># enlightenment interfaces. Turning this on can impr=
ove Windows guest<o:p></o:p></p>
<p class=3D"MsoNormal"># performance and is therefore recommended<o:p></o:p=
></p>
<p class=3D"MsoNormal">#viridian =3D 1<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Initial memory allocation (MB)<o:p></o:p></p>
<p class=3D"MsoNormal"><b>memory =3D 8192<o:p></o:p></b></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Maximum memory (MB)<o:p></o:p></p>
<p class=3D"MsoNormal"># If this is greater than `memory' then the slack wi=
ll start ballooned<o:p></o:p></p>
<p class=3D"MsoNormal"># (this assumes guest kernel support for ballooning)=
<o:p></o:p></p>
<p class=3D"MsoNormal">#maxmem =3D 512<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Number of VCPUS<o:p></o:p></p>
<p class=3D"MsoNormal"><b>vcpus =3D 8<o:p></o:p></b></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Network devices<o:p></o:p></p>
<p class=3D"MsoNormal"># A list of 'vifspec' entries as described in<o:p></=
o:p></p>
<p class=3D"MsoNormal"># docs/misc/xl-network-configuration.markdown<o:p></=
o:p></p>
<p class=3D"MsoNormal">vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, br=
idge=3Dxenbr1, model=3Dvmxnet3' ]<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Disk Devices<o:p></o:p></p>
<p class=3D"MsoNormal"># A list of `diskspec' entries as described in<o:p><=
/o:p></p>
<p class=3D"MsoNormal"># docs/misc/xl-disk-configuration.txt<o:p></o:p></p>
<p class=3D"MsoNormal"><b>disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img=
,raw,xvda,rw', 'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r' ]<o:=
p></o:p></b></p>
<p class=3D"MsoNormal"><b>boot=3D'cd'</b><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"># Guest VGA console configuration, either SDL or VNC=
<o:p></o:p></p>
<p class=3D"MsoNormal"># sdl =3D 1<o:p></o:p></p>
<p class=3D"MsoNormal"><b>vnc =3D 2<o:p></o:p></b></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal">-Upanshu<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Upanshu Singhal<o:p></o:p></p>
<p class=3D"MsoNormal">EMC Data Storage Systems, Bangalore, India.<o:p></o:=
p></p>
<p class=3D"MsoNormal">Phone: 91-80-67375604<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB836CMX101CL01corpem_--


--===============4754181612258490231==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4754181612258490231==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 12:37:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 12: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 1Y1wni-0007ui-Vf; Fri, 19 Dec 2014 12:36:58 +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 1Y1wnh-0007ud-3g
	for Xen-devel@lists.xen.org; Fri, 19 Dec 2014 12:36:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	83/78-09842-8EB14945; Fri, 19 Dec 2014 12:36:56 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418992615!16764832!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22264 invoked from network); 19 Dec 2014 12:36:55 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 12:36:55 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id 5C2761104AB2;
	Fri, 19 Dec 2014 13:36:55 +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 m2bcfIcj-NVN; Fri, 19 Dec 2014 13:36:55 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id E0FD91104AB1;
	Fri, 19 Dec 2014 13:36:54 +0100 (CET)
Message-ID: <54941BE4.5000208@univention.de>
Date: Fri, 19 Dec 2014 13:36:52 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Frediano Ziglio <freddy77@gmail.com>
References: <546461A2.2070908@univention.de>	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>	<1418407116.16425.53.camel@citrix.com>	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>	<1418655014.16425.138.camel@citrix.com>	<1418665524.16425.171.camel@citrix.com>	<548F60BF.4020901@univention.de>	<1418726712.16425.213.camel@citrix.com>	<1418727970.16425.217.camel@citrix.com>	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>	<1418732635.16425.221.camel@citrix.com>	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418897867.11882.11.camel@citrix.com>
In-Reply-To: <1418897867.11882.11.camel@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, 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

Hello Ian,

On 18.12.2014 11:17, Ian Campbell wrote:
> On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
>> Do we have a bug in Xen that affect SSE instructions (possibly already
>> fixed after Philipp version) ?
> 
> I've had a niggling feeling of Deja Vu over this which I'd been putting
> down to an old Xen on ARM bug in the area of FPU register switching.
> 
> But it seems at some point (possibly even still) there was a similar
> issue with pvops kernels on x86, see:
>         http://bugs.xenproject.org/xen/bug/40

That definitely looks interesting.

> Philipp, what kernel are you guys using?

The crash "2014-12-06 01:26:21 xenstored[4337]" happened on linux-3.10.46.

That kernel is missing v3.10.50-13-gd1cc001:
> commit d1cc001905146d58c17ac8452eb96f226767819d
> Author: Silesh C V <svellattu@mvista.com>
> Date:   Wed Jul 23 13:59:59 2014 -0700
>
>     coredump: fix the setting of PF_DUMPCORE
>     commit aed8adb7688d5744cb484226820163af31d2499a upstream.
which explains why the xmm* registers are not included in the core file.

> I also can't quite shake the feeling that there was another much older
> issue relating to FPU context switch on x86, but I think that was truly
> ancient history (2.6.18 era stuff)

Some of those host might still use 3.2, most use 3.10.x, but definitely
no 2.6 kernels.

Xen-Hypervisor is 4.1.3

If you need anything more, just ask. It might take me some time to
answer as I'm on vacation for the next 2 weeks.

Thanks again for your help.
Philipp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 12:37:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 12: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 1Y1wni-0007ui-Vf; Fri, 19 Dec 2014 12:36:58 +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 1Y1wnh-0007ud-3g
	for Xen-devel@lists.xen.org; Fri, 19 Dec 2014 12:36:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	83/78-09842-8EB14945; Fri, 19 Dec 2014 12:36:56 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1418992615!16764832!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22264 invoked from network); 19 Dec 2014 12:36:55 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 12:36:55 -0000
Received: from localhost (localhost [127.0.0.1])
	by solig.knut.univention.de (Postfix) with ESMTP id 5C2761104AB2;
	Fri, 19 Dec 2014 13:36:55 +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 m2bcfIcj-NVN; Fri, 19 Dec 2014 13:36:55 +0100 (CET)
Received: from [192.168.0.191] (mail.univention.de [82.198.197.8])
	by solig.knut.univention.de (Postfix) with ESMTPSA id E0FD91104AB1;
	Fri, 19 Dec 2014 13:36:54 +0100 (CET)
Message-ID: <54941BE4.5000208@univention.de>
Date: Fri, 19 Dec 2014 13:36:52 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Frediano Ziglio <freddy77@gmail.com>
References: <546461A2.2070908@univention.de>	<1415869951.31613.26.camel@citrix.com>
	<548B1472.5080302@univention.de>	<1418401932.16425.34.camel@citrix.com>
	<548B1BA8.3090504@univention.de>	<1418403387.16425.38.camel@citrix.com>
	<548B23FA.6070108@univention.de>	<1418407116.16425.53.camel@citrix.com>	<1418649458.16425.108.camel@citrix.com>
	<548EEDF5.20808@univention.de>	<1418655014.16425.138.camel@citrix.com>	<1418665524.16425.171.camel@citrix.com>	<548F60BF.4020901@univention.de>	<1418726712.16425.213.camel@citrix.com>	<1418727970.16425.217.camel@citrix.com>	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>	<1418732635.16425.221.camel@citrix.com>	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418897867.11882.11.camel@citrix.com>
In-Reply-To: <1418897867.11882.11.camel@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, 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

Hello Ian,

On 18.12.2014 11:17, Ian Campbell wrote:
> On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
>> Do we have a bug in Xen that affect SSE instructions (possibly already
>> fixed after Philipp version) ?
> 
> I've had a niggling feeling of Deja Vu over this which I'd been putting
> down to an old Xen on ARM bug in the area of FPU register switching.
> 
> But it seems at some point (possibly even still) there was a similar
> issue with pvops kernels on x86, see:
>         http://bugs.xenproject.org/xen/bug/40

That definitely looks interesting.

> Philipp, what kernel are you guys using?

The crash "2014-12-06 01:26:21 xenstored[4337]" happened on linux-3.10.46.

That kernel is missing v3.10.50-13-gd1cc001:
> commit d1cc001905146d58c17ac8452eb96f226767819d
> Author: Silesh C V <svellattu@mvista.com>
> Date:   Wed Jul 23 13:59:59 2014 -0700
>
>     coredump: fix the setting of PF_DUMPCORE
>     commit aed8adb7688d5744cb484226820163af31d2499a upstream.
which explains why the xmm* registers are not included in the core file.

> I also can't quite shake the feeling that there was another much older
> issue relating to FPU context switch on x86, but I think that was truly
> ancient history (2.6.18 era stuff)

Some of those host might still use 3.2, most use 3.10.x, but definitely
no 2.6 kernels.

Xen-Hypervisor is 4.1.3

If you need anything more, just ask. It might take me some time to
answer as I'm on vacation for the next 2 weeks.

Thanks again for your help.
Philipp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 12:40:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 12:40:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1wr3-00087D-KZ; Fri, 19 Dec 2014 12:40:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y1wr2-000876-KM
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 12:40:24 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	89/F2-22819-7BC14945; Fri, 19 Dec 2014 12:40:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418992821!14325812!1
X-Originating-IP: [66.165.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 26353 invoked from network); 19 Dec 2014 12:40:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 12:40:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206210870"
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.210.2; Fri, 19 Dec 2014 07:40:17 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y1wqv-0003fM-Ab;
	Fri, 19 Dec 2014 12:40:17 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1wqv-0007nJ-1p;
	Fri, 19 Dec 2014 12:40:17 +0000
Date: Fri, 19 Dec 2014 12:40:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32459-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] 32459: 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 32459 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32459/

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 32429

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-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-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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                86b182ac0e0b44726d85598cbefb468ed22517fc
baseline version:
 qemuu                d86fb03469e016af4e54f04efccbc20a8afa3e19

------------------------------------------------------------
People who touched revisions under test:
  Alexander Graf <agraf@suse.de>
  Antony Pavlov <antonynpavlov@gmail.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Nathan Froyd <froydnj@codesourcery.com>
  Peter Maydell <peter.maydell@linaro.org>
  Sandra Loosemore <sandra@codesourcery.com>
  Thomas Schwinge <thomas@codesourcery.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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=86b182ac0e0b44726d85598cbefb468ed22517fc
+ . 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 86b182ac0e0b44726d85598cbefb468ed22517fc
+ branch=qemu-mainline
+ revision=86b182ac0e0b44726d85598cbefb468ed22517fc
+ . 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 86b182ac0e0b44726d85598cbefb468ed22517fc:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   d86fb03..86b182a  86b182ac0e0b44726d85598cbefb468ed22517fc -> 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 Fri Dec 19 12:40:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 12:40:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1wr3-00087D-KZ; Fri, 19 Dec 2014 12:40:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y1wr2-000876-KM
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 12:40:24 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	89/F2-22819-7BC14945; Fri, 19 Dec 2014 12:40:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1418992821!14325812!1
X-Originating-IP: [66.165.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 26353 invoked from network); 19 Dec 2014 12:40:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 12:40:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="206210870"
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.210.2; Fri, 19 Dec 2014 07:40:17 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y1wqv-0003fM-Ab;
	Fri, 19 Dec 2014 12:40:17 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y1wqv-0007nJ-1p;
	Fri, 19 Dec 2014 12:40:17 +0000
Date: Fri, 19 Dec 2014 12:40:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32459-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] 32459: 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 32459 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32459/

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 32429

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-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-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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                86b182ac0e0b44726d85598cbefb468ed22517fc
baseline version:
 qemuu                d86fb03469e016af4e54f04efccbc20a8afa3e19

------------------------------------------------------------
People who touched revisions under test:
  Alexander Graf <agraf@suse.de>
  Antony Pavlov <antonynpavlov@gmail.com>
  Leon Alrae <leon.alrae@imgtec.com>
  Maciej W. Rozycki <macro@codesourcery.com>
  Max Filippov <jcmvbkbc@gmail.com>
  Nathan Froyd <froydnj@codesourcery.com>
  Peter Maydell <peter.maydell@linaro.org>
  Sandra Loosemore <sandra@codesourcery.com>
  Thomas Schwinge <thomas@codesourcery.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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=86b182ac0e0b44726d85598cbefb468ed22517fc
+ . 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 86b182ac0e0b44726d85598cbefb468ed22517fc
+ branch=qemu-mainline
+ revision=86b182ac0e0b44726d85598cbefb468ed22517fc
+ . 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 86b182ac0e0b44726d85598cbefb468ed22517fc:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   d86fb03..86b182a  86b182ac0e0b44726d85598cbefb468ed22517fc -> 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 Fri Dec 19 13:08:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 13: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 1Y1xIH-0000p9-BL; Fri, 19 Dec 2014 13:08: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 1Y1xIG-0000p4-6q
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 13:08:32 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	B8/D4-02696-E4324945; Fri, 19 Dec 2014 13:08:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418994509!16154511!1
X-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 5361 invoked from network); 19 Dec 2014 13:08:30 -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; 19 Dec 2014 13:08:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 13:08:26 +0000
Message-Id: <549431590200007800051016@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 13:08:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monne" <roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
	<5493224D.9050001@citrix.com>
	<5493F9DF0200007800050E9D@mail.emea.novell.com>
	<54940CB5.1020105@citrix.com>
In-Reply-To: <54940CB5.1020105@citrix.com>
Mime-Version: 1.0
Content-Length: 2015
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
 from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDE5LjEyLjE0IGF0IDEyOjMyLCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4gT24gMTkvMTIvMTQgMDk6MTEsIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+PiBPbiAxOC4x
Mi4xNCBhdCAxOTo1MSwgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+IHdyb3RlOgo+Pj4gT24g
MTgvMTIvMTQgMTg6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4+PiBQcmV2ZW50IERvbTAg
ZnJvbSBhY2Nlc3NpbmcgSFBFVCBNTUlPIHJlZ2lvbiBieSBhZGRpbmcgaXQgdG8gdGhlIGxpc3Qg
b2YKPj4+PiBkZW5pZWQgbWVtb3J5IHJlZ2lvbnMuCj4+Pj4KPj4+PiBTaWduZWQtb2ZmLWJ5OiBS
b2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPj4+PiBDYzogSmFuIEJldWxp
Y2ggPGpiZXVsaWNoQHN1c2UuY29tPgo+Pj4+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29v
cGVyM0BjaXRyaXguY29tPgo+Pj4gQXBvbG9naWVzIHRoYXQgdGhpcyByZXBseSBpcyBzcGxpdCBi
ZXR3ZWVuIHBhdGNoIDAgYW5kIDIgLSBJIHJlcGxpZWQgdG8KPj4+IHlvdXIgY292ZXIgbGV0dGVy
IGJlZm9yZSByZWFkaW5nIHRoaXMgcGF0Y2guCj4+Pgo+Pj4gRGVueWluZyBhY2Nlc3MgaXMgb25s
eSB2YWxpZCBpZiBhY3BpX3RhYmxlX2hwZXQuZmxhZ3MgJiAKPj4+IEFDUElfSFBFVF9QQUdFX1BS
T1RFQ1Q0IGlzIHRydWUuCj4+IEhhdmluZyBqdXN0IGNoZWNrZWQgKGFzIGFuIGV4YW1wbGUpIHRo
ZSBtb3N0IG1vZGVybiBJbnRlbCBib3ggSQo+PiBoYXZlIGRpcmVjdCBhY2Nlc3MgdG8sIEkgd29u
ZGVyIGhvdyBtYW55IHN5c3RlbXMgYWN0dWFsbHkgc3VwcGx5Cj4+IG90aGVyIHRoYW4gMCBoZXJl
LiBQZXJoYXBzIHdlIG91Z2h0IHRvIGF0IG9uY2UgYWRkIGEgY29tbWFuZAo+PiBsaW5lIG9wdGlv
biB0byB0cmlnZ2VyIHRoZSBkZW5pYWw/Cj4gCj4gSSBhbHNvIGNhbid0IGZpbmQgYSBzZXJ2ZXIg
d2hpY2ggc2V0cyB0aGlzIGZsYWcuICBJIHdvbmRlciBob3cgbWFueQo+IHN5c3RlbXMgYWN0dWFs
bHkgaGF2ZSBvdGhlciB0aGluZ3Mgc2l0dGluZyBpbiB0aGUgcmVtYWluZGVyIG9mIHRoZSBwYWdl
LgoKT25lIHdvdWxkIHRoaW5rIChvciBzaG91bGQgSSBzYXkgaG9wZSkgdGhhdCB0aGVyZSdzIGF0
IGxlYXN0IG5vdGhpbmcKd2l0aCByZWFkIHNpZGUgZWZmZWN0cyBhbnl3aGVyZSwgb3IgZWxzZSBM
aW51eCdlcyBleHBvc2luZyBvZiB0aGUKcGFnZSB0byB1c2VyIG1vZGUgd291bGQgYmUgYSBzZWN1
cml0eSBwcm9ibGVtLiBQZXJoYXBzIHdlIHNob3VsZAphbHNvIGxpbWl0IERvbTAgbWFwcGluZ3Mg
dG8gci9vIHdoZW4gd2UgY2FuJ3QgaGlkZSB0aGUgcGFnZQphbHRvZ2V0aGVyLgoKSmFuCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Dec 19 13:08:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 13: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 1Y1xIH-0000p9-BL; Fri, 19 Dec 2014 13:08: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 1Y1xIG-0000p4-6q
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 13:08:32 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	B8/D4-02696-E4324945; Fri, 19 Dec 2014 13:08:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1418994509!16154511!1
X-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 5361 invoked from network); 19 Dec 2014 13:08:30 -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; 19 Dec 2014 13:08:30 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 13:08:26 +0000
Message-Id: <549431590200007800051016@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 13:08:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monne" <roger.pau@citrix.com>
References: <1418927225-60266-1-git-send-email-roger.pau@citrix.com>
	<1418927225-60266-3-git-send-email-roger.pau@citrix.com>
	<5493224D.9050001@citrix.com>
	<5493F9DF0200007800050E9D@mail.emea.novell.com>
	<54940CB5.1020105@citrix.com>
In-Reply-To: <54940CB5.1020105@citrix.com>
Mime-Version: 1.0
Content-Length: 2015
Content-Disposition: inline
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET
 from Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDE5LjEyLjE0IGF0IDEyOjMyLCA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4gd3Jv
dGU6Cj4gT24gMTkvMTIvMTQgMDk6MTEsIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+PiBPbiAxOC4x
Mi4xNCBhdCAxOTo1MSwgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+IHdyb3RlOgo+Pj4gT24g
MTgvMTIvMTQgMTg6MjcsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4+PiBQcmV2ZW50IERvbTAg
ZnJvbSBhY2Nlc3NpbmcgSFBFVCBNTUlPIHJlZ2lvbiBieSBhZGRpbmcgaXQgdG8gdGhlIGxpc3Qg
b2YKPj4+PiBkZW5pZWQgbWVtb3J5IHJlZ2lvbnMuCj4+Pj4KPj4+PiBTaWduZWQtb2ZmLWJ5OiBS
b2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPj4+PiBDYzogSmFuIEJldWxp
Y2ggPGpiZXVsaWNoQHN1c2UuY29tPgo+Pj4+IENjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29v
cGVyM0BjaXRyaXguY29tPgo+Pj4gQXBvbG9naWVzIHRoYXQgdGhpcyByZXBseSBpcyBzcGxpdCBi
ZXR3ZWVuIHBhdGNoIDAgYW5kIDIgLSBJIHJlcGxpZWQgdG8KPj4+IHlvdXIgY292ZXIgbGV0dGVy
IGJlZm9yZSByZWFkaW5nIHRoaXMgcGF0Y2guCj4+Pgo+Pj4gRGVueWluZyBhY2Nlc3MgaXMgb25s
eSB2YWxpZCBpZiBhY3BpX3RhYmxlX2hwZXQuZmxhZ3MgJiAKPj4+IEFDUElfSFBFVF9QQUdFX1BS
T1RFQ1Q0IGlzIHRydWUuCj4+IEhhdmluZyBqdXN0IGNoZWNrZWQgKGFzIGFuIGV4YW1wbGUpIHRo
ZSBtb3N0IG1vZGVybiBJbnRlbCBib3ggSQo+PiBoYXZlIGRpcmVjdCBhY2Nlc3MgdG8sIEkgd29u
ZGVyIGhvdyBtYW55IHN5c3RlbXMgYWN0dWFsbHkgc3VwcGx5Cj4+IG90aGVyIHRoYW4gMCBoZXJl
LiBQZXJoYXBzIHdlIG91Z2h0IHRvIGF0IG9uY2UgYWRkIGEgY29tbWFuZAo+PiBsaW5lIG9wdGlv
biB0byB0cmlnZ2VyIHRoZSBkZW5pYWw/Cj4gCj4gSSBhbHNvIGNhbid0IGZpbmQgYSBzZXJ2ZXIg
d2hpY2ggc2V0cyB0aGlzIGZsYWcuICBJIHdvbmRlciBob3cgbWFueQo+IHN5c3RlbXMgYWN0dWFs
bHkgaGF2ZSBvdGhlciB0aGluZ3Mgc2l0dGluZyBpbiB0aGUgcmVtYWluZGVyIG9mIHRoZSBwYWdl
LgoKT25lIHdvdWxkIHRoaW5rIChvciBzaG91bGQgSSBzYXkgaG9wZSkgdGhhdCB0aGVyZSdzIGF0
IGxlYXN0IG5vdGhpbmcKd2l0aCByZWFkIHNpZGUgZWZmZWN0cyBhbnl3aGVyZSwgb3IgZWxzZSBM
aW51eCdlcyBleHBvc2luZyBvZiB0aGUKcGFnZSB0byB1c2VyIG1vZGUgd291bGQgYmUgYSBzZWN1
cml0eSBwcm9ibGVtLiBQZXJoYXBzIHdlIHNob3VsZAphbHNvIGxpbWl0IERvbTAgbWFwcGluZ3Mg
dG8gci9vIHdoZW4gd2UgY2FuJ3QgaGlkZSB0aGUgcGFnZQphbHRvZ2V0aGVyLgoKSmFuCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Dec 19 13:17:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 13:17:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1xQO-0001G3-AY; Fri, 19 Dec 2014 13:16:56 +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 1Y1xQK-0001Fy-Ln
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 13:16:54 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	8C/E9-26858-34524945; Fri, 19 Dec 2014 13:16:51 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418995010!14509482!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25947 invoked from network); 19 Dec 2014 13:16:50 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 19 Dec 2014 13:16:50 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:50936 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Y1xPF-0007kF-9A; Fri, 19 Dec 2014 14:15:45 +0100
Date: Fri, 19 Dec 2014 14:16:45 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1824124380.20141219141645@eikelenboom.it>
To: konrad.wilk@oracle.com, David Vrabel <david.vrabel@citrix.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, <jiang.liu@linux.intel.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------12A0390BB304161AE"
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: [Xen-devel] Bisected Linux regression: ACPI powerbutton events
	don't work under Xen since commit
	b81975eade8c6495f3c4d6746d22bdc95f617777
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------12A0390BB304161AE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

When running under Xen, ACPI powerbutton events don't work anymore, 
there is no reaction when pressing the powerbutton.

On baremetal everything works fine, acpid gets the event and the 
machine powers down perfectly. The machine is an Intel NUC.
 
Bisection has lead to:

b81975eade8c6495f3c4d6746d22bdc95f617777 is the first bad commit
commit b81975eade8c6495f3c4d6746d22bdc95f617777
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Mon Jun 9 16:20:11 2014 +0800

    x86, irq: Clean up irqdomain transition code

    Now we have completely switched to irqdomain, so clean up transition code
    in IOAPIC drivers.

    Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Grant Likely <grant.likely@linaro.org>
    Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Link: http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang.liu@linux.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Reverting this specific commit on linux-tip (3.19-mw) gets things working again under Xen.
Kernel .config is attached.

--
Sander
------------12A0390BB304161AE
Content-Type: application/octet-stream;
 name=dot-config
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename=dot-config

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4
L3g4Nl82NCAzLjE2LjAtcmMxLWNyZWFudWMtMjAxNDEyMTgtYmlzZWN0MTYgS2VybmVsIENv
bmZpZ3VyYXRpb24KIwpDT05GSUdfNjRCSVQ9eQpDT05GSUdfWDg2XzY0PXkKQ09ORklHX1g4
Nj15CkNPTkZJR19JTlNUUlVDVElPTl9ERUNPREVSPXkKQ09ORklHX09VVFBVVF9GT1JNQVQ9
ImVsZjY0LXg4Ni02NCIKQ09ORklHX0FSQ0hfREVGQ09ORklHPSJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCkNPTkZJR19MT0NLREVQX1NVUFBPUlQ9eQpDT05GSUdfU1RB
Q0tUUkFDRV9TVVBQT1JUPXkKQ09ORklHX0hBVkVfTEFURU5DWVRPUF9TVVBQT1JUPXkKQ09O
RklHX01NVT15CkNPTkZJR19ORUVEX0RNQV9NQVBfU1RBVEU9eQpDT05GSUdfTkVFRF9TR19E
TUFfTEVOR1RIPXkKQ09ORklHX0dFTkVSSUNfSVNBX0RNQT15CkNPTkZJR19HRU5FUklDX0JV
Rz15CkNPTkZJR19HRU5FUklDX0JVR19SRUxBVElWRV9QT0lOVEVSUz15CkNPTkZJR19HRU5F
UklDX0hXRUlHSFQ9eQpDT05GSUdfQVJDSF9NQVlfSEFWRV9QQ19GREM9eQpDT05GSUdfUldT
RU1fWENIR0FERF9BTEdPUklUSE09eQpDT05GSUdfR0VORVJJQ19DQUxJQlJBVEVfREVMQVk9
eQpDT05GSUdfQVJDSF9IQVNfQ1BVX1JFTEFYPXkKQ09ORklHX0FSQ0hfSEFTX0NBQ0hFX0xJ
TkVfU0laRT15CkNPTkZJR19IQVZFX1NFVFVQX1BFUl9DUFVfQVJFQT15CkNPTkZJR19ORUVE
X1BFUl9DUFVfRU1CRURfRklSU1RfQ0hVTks9eQpDT05GSUdfTkVFRF9QRVJfQ1BVX1BBR0Vf
RklSU1RfQ0hVTks9eQpDT05GSUdfQVJDSF9ISUJFUk5BVElPTl9QT1NTSUJMRT15CkNPTkZJ
R19BUkNIX1NVU1BFTkRfUE9TU0lCTEU9eQpDT05GSUdfQVJDSF9XQU5UX0hVR0VfUE1EX1NI
QVJFPXkKQ09ORklHX0FSQ0hfV0FOVF9HRU5FUkFMX0hVR0VUTEI9eQpDT05GSUdfWk9ORV9E
TUEzMj15CkNPTkZJR19BVURJVF9BUkNIPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfT1BUSU1J
WkVEX0lOTElOSU5HPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfREVCVUdfUEFHRUFMTE9DPXkK
Q09ORklHX0hBVkVfSU5URUxfVFhUPXkKQ09ORklHX1g4Nl82NF9TTVA9eQpDT05GSUdfWDg2
X0hUPXkKQ09ORklHX0FSQ0hfSFdFSUdIVF9DRkxBR1M9Ii1mY2FsbC1zYXZlZC1yZGkgLWZj
YWxsLXNhdmVkLXJzaSAtZmNhbGwtc2F2ZWQtcmR4IC1mY2FsbC1zYXZlZC1yY3ggLWZjYWxs
LXNhdmVkLXI4IC1mY2FsbC1zYXZlZC1yOSAtZmNhbGwtc2F2ZWQtcjEwIC1mY2FsbC1zYXZl
ZC1yMTEiCkNPTkZJR19BUkNIX1NVUFBPUlRTX1VQUk9CRVM9eQpDT05GSUdfRklYX0VBUkxZ
Q09OX01FTT15CkNPTkZJR19ERUZDT05GSUdfTElTVD0iL2xpYi9tb2R1bGVzLyRVTkFNRV9S
RUxFQVNFLy5jb25maWciCkNPTkZJR19JUlFfV09SSz15CkNPTkZJR19CVUlMRFRJTUVfRVhU
QUJMRV9TT1JUPXkKCiMKIyBHZW5lcmFsIHNldHVwCiMKQ09ORklHX0lOSVRfRU5WX0FSR19M
SU1JVD0zMgpDT05GSUdfQ1JPU1NfQ09NUElMRT0iIgojIENPTkZJR19DT01QSUxFX1RFU1Qg
aXMgbm90IHNldApDT05GSUdfTE9DQUxWRVJTSU9OPSIiCiMgQ09ORklHX0xPQ0FMVkVSU0lP
Tl9BVVRPIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfS0VSTkVMX0daSVA9eQpDT05GSUdfSEFW
RV9LRVJORUxfQlpJUDI9eQpDT05GSUdfSEFWRV9LRVJORUxfTFpNQT15CkNPTkZJR19IQVZF
X0tFUk5FTF9YWj15CkNPTkZJR19IQVZFX0tFUk5FTF9MWk89eQpDT05GSUdfSEFWRV9LRVJO
RUxfTFo0PXkKQ09ORklHX0tFUk5FTF9HWklQPXkKIyBDT05GSUdfS0VSTkVMX0JaSVAyIGlz
IG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX0xaTUEgaXMgbm90IHNldAojIENPTkZJR19LRVJO
RUxfWFogaXMgbm90IHNldAojIENPTkZJR19LRVJORUxfTFpPIGlzIG5vdCBzZXQKIyBDT05G
SUdfS0VSTkVMX0xaNCBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0hPU1ROQU1FPSIobm9u
ZSkiCkNPTkZJR19TV0FQPXkKQ09ORklHX1NZU1ZJUEM9eQpDT05GSUdfU1lTVklQQ19TWVND
VEw9eQpDT05GSUdfUE9TSVhfTVFVRVVFPXkKQ09ORklHX1BPU0lYX01RVUVVRV9TWVNDVEw9
eQpDT05GSUdfQ1JPU1NfTUVNT1JZX0FUVEFDSD15CkNPTkZJR19GSEFORExFPXkKQ09ORklH
X1VTRUxJQj15CkNPTkZJR19BVURJVD15CkNPTkZJR19IQVZFX0FSQ0hfQVVESVRTWVNDQUxM
PXkKQ09ORklHX0FVRElUU1lTQ0FMTD15CkNPTkZJR19BVURJVF9XQVRDSD15CkNPTkZJR19B
VURJVF9UUkVFPXkKCiMKIyBJUlEgc3Vic3lzdGVtCiMKQ09ORklHX0dFTkVSSUNfSVJRX1BS
T0JFPXkKQ09ORklHX0dFTkVSSUNfSVJRX1NIT1c9eQpDT05GSUdfR0VORVJJQ19JUlFfTEVH
QUNZX0FMTE9DX0hXSVJRPXkKQ09ORklHX0dFTkVSSUNfUEVORElOR19JUlE9eQpDT05GSUdf
R0VORVJJQ19JUlFfQ0hJUD15CkNPTkZJR19JUlFfRE9NQUlOPXkKQ09ORklHX0lSUV9GT1JD
RURfVEhSRUFESU5HPXkKQ09ORklHX1NQQVJTRV9JUlE9eQpDT05GSUdfQ0xPQ0tTT1VSQ0Vf
V0FUQ0hET0c9eQpDT05GSUdfQVJDSF9DTE9DS1NPVVJDRV9EQVRBPXkKQ09ORklHX0dFTkVS
SUNfVElNRV9WU1lTQ0FMTD15CkNPTkZJR19HRU5FUklDX0NMT0NLRVZFTlRTPXkKQ09ORklH
X0dFTkVSSUNfQ0xPQ0tFVkVOVFNfQlVJTEQ9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5U
U19CUk9BRENBU1Q9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5UU19NSU5fQURKVVNUPXkK
Q09ORklHX0dFTkVSSUNfQ01PU19VUERBVEU9eQoKIwojIFRpbWVycyBzdWJzeXN0ZW0KIwpD
T05GSUdfVElDS19PTkVTSE9UPXkKQ09ORklHX05PX0haX0NPTU1PTj15CiMgQ09ORklHX0ha
X1BFUklPRElDIGlzIG5vdCBzZXQKQ09ORklHX05PX0haX0lETEU9eQojIENPTkZJR19OT19I
Wl9GVUxMIGlzIG5vdCBzZXQKQ09ORklHX05PX0haPXkKQ09ORklHX0hJR0hfUkVTX1RJTUVS
Uz15CgojCiMgQ1BVL1Rhc2sgdGltZSBhbmQgc3RhdHMgYWNjb3VudGluZwojCkNPTkZJR19U
SUNLX0NQVV9BQ0NPVU5USU5HPXkKIyBDT05GSUdfVklSVF9DUFVfQUNDT1VOVElOR19HRU4g
aXMgbm90IHNldAojIENPTkZJR19JUlFfVElNRV9BQ0NPVU5USU5HIGlzIG5vdCBzZXQKQ09O
RklHX0JTRF9QUk9DRVNTX0FDQ1Q9eQpDT05GSUdfQlNEX1BST0NFU1NfQUNDVF9WMz15CkNP
TkZJR19UQVNLU1RBVFM9eQpDT05GSUdfVEFTS19ERUxBWV9BQ0NUPXkKQ09ORklHX1RBU0tf
WEFDQ1Q9eQpDT05GSUdfVEFTS19JT19BQ0NPVU5USU5HPXkKCiMKIyBSQ1UgU3Vic3lzdGVt
CiMKQ09ORklHX1RSRUVfUkNVPXkKIyBDT05GSUdfUFJFRU1QVF9SQ1UgaXMgbm90IHNldApD
T05GSUdfUkNVX1NUQUxMX0NPTU1PTj15CiMgQ09ORklHX1JDVV9VU0VSX1FTIGlzIG5vdCBz
ZXQKQ09ORklHX1JDVV9GQU5PVVQ9NjQKQ09ORklHX1JDVV9GQU5PVVRfTEVBRj0xNgojIENP
TkZJR19SQ1VfRkFOT1VUX0VYQUNUIGlzIG5vdCBzZXQKQ09ORklHX1JDVV9GQVNUX05PX0ha
PXkKIyBDT05GSUdfVFJFRV9SQ1VfVFJBQ0UgaXMgbm90IHNldAojIENPTkZJR19SQ1VfTk9D
Ql9DUFUgaXMgbm90IHNldAojIENPTkZJR19JS0NPTkZJRyBpcyBub3Qgc2V0CkNPTkZJR19M
T0dfQlVGX1NISUZUPTE3CkNPTkZJR19IQVZFX1VOU1RBQkxFX1NDSEVEX0NMT0NLPXkKQ09O
RklHX0FSQ0hfU1VQUE9SVFNfTlVNQV9CQUxBTkNJTkc9eQpDT05GSUdfQVJDSF9TVVBQT1JU
U19JTlQxMjg9eQpDT05GSUdfQVJDSF9XQU5UU19QUk9UX05VTUFfUFJPVF9OT05FPXkKQ09O
RklHX0NHUk9VUFM9eQojIENPTkZJR19DR1JPVVBfREVCVUcgaXMgbm90IHNldApDT05GSUdf
Q0dST1VQX0ZSRUVaRVI9eQpDT05GSUdfQ0dST1VQX0RFVklDRT15CkNPTkZJR19DUFVTRVRT
PXkKQ09ORklHX1BST0NfUElEX0NQVVNFVD15CkNPTkZJR19DR1JPVVBfQ1BVQUNDVD15CkNP
TkZJR19SRVNPVVJDRV9DT1VOVEVSUz15CiMgQ09ORklHX01FTUNHIGlzIG5vdCBzZXQKIyBD
T05GSUdfQ0dST1VQX0hVR0VUTEIgaXMgbm90IHNldApDT05GSUdfQ0dST1VQX1BFUkY9eQpD
T05GSUdfQ0dST1VQX1NDSEVEPXkKQ09ORklHX0ZBSVJfR1JPVVBfU0NIRUQ9eQojIENPTkZJ
R19DRlNfQkFORFdJRFRIIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRfR1JPVVBfU0NIRUQgaXMg
bm90IHNldApDT05GSUdfQkxLX0NHUk9VUD15CiMgQ09ORklHX0RFQlVHX0JMS19DR1JPVVAg
aXMgbm90IHNldAojIENPTkZJR19DSEVDS1BPSU5UX1JFU1RPUkUgaXMgbm90IHNldApDT05G
SUdfTkFNRVNQQUNFUz15CkNPTkZJR19VVFNfTlM9eQpDT05GSUdfSVBDX05TPXkKIyBDT05G
SUdfVVNFUl9OUyBpcyBub3Qgc2V0CkNPTkZJR19QSURfTlM9eQpDT05GSUdfTkVUX05TPXkK
Q09ORklHX1NDSEVEX0FVVE9HUk9VUD15CiMgQ09ORklHX1NZU0ZTX0RFUFJFQ0FURUQgaXMg
bm90IHNldApDT05GSUdfUkVMQVk9eQpDT05GSUdfQkxLX0RFVl9JTklUUkQ9eQpDT05GSUdf
SU5JVFJBTUZTX1NPVVJDRT0iIgpDT05GSUdfUkRfR1pJUD15CkNPTkZJR19SRF9CWklQMj15
CkNPTkZJR19SRF9MWk1BPXkKQ09ORklHX1JEX1haPXkKQ09ORklHX1JEX0xaTz15CkNPTkZJ
R19SRF9MWjQ9eQpDT05GSUdfQ0NfT1BUSU1JWkVfRk9SX1NJWkU9eQpDT05GSUdfU1lTQ1RM
PXkKQ09ORklHX0FOT05fSU5PREVTPXkKQ09ORklHX1NZU0NUTF9FWENFUFRJT05fVFJBQ0U9
eQpDT05GSUdfSEFWRV9QQ1NQS1JfUExBVEZPUk09eQojIENPTkZJR19FWFBFUlQgaXMgbm90
IHNldApDT05GSUdfU0dFVE1BU0tfU1lTQ0FMTD15CkNPTkZJR19TWVNGU19TWVNDQUxMPXkK
IyBDT05GSUdfU1lTQ1RMX1NZU0NBTEwgaXMgbm90IHNldApDT05GSUdfS0FMTFNZTVM9eQoj
IENPTkZJR19LQUxMU1lNU19BTEwgaXMgbm90IHNldApDT05GSUdfUFJJTlRLPXkKQ09ORklH
X0JVRz15CkNPTkZJR19FTEZfQ09SRT15CkNPTkZJR19QQ1NQS1JfUExBVEZPUk09eQpDT05G
SUdfQkFTRV9GVUxMPXkKQ09ORklHX0ZVVEVYPXkKQ09ORklHX0VQT0xMPXkKQ09ORklHX1NJ
R05BTEZEPXkKQ09ORklHX1RJTUVSRkQ9eQpDT05GSUdfRVZFTlRGRD15CkNPTkZJR19TSE1F
TT15CkNPTkZJR19BSU89eQpDT05GSUdfUENJX1FVSVJLUz15CiMgQ09ORklHX0VNQkVEREVE
IGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfUEVSRl9FVkVOVFM9eQoKIwojIEtlcm5lbCBQZXJm
b3JtYW5jZSBFdmVudHMgQW5kIENvdW50ZXJzCiMKQ09ORklHX1BFUkZfRVZFTlRTPXkKIyBD
T05GSUdfREVCVUdfUEVSRl9VU0VfVk1BTExPQyBpcyBub3Qgc2V0CkNPTkZJR19WTV9FVkVO
VF9DT1VOVEVSUz15CkNPTkZJR19TTFVCX0RFQlVHPXkKIyBDT05GSUdfQ09NUEFUX0JSSyBp
cyBub3Qgc2V0CiMgQ09ORklHX1NMQUIgaXMgbm90IHNldApDT05GSUdfU0xVQj15CkNPTkZJ
R19TTFVCX0NQVV9QQVJUSUFMPXkKIyBDT05GSUdfU1lTVEVNX1RSVVNURURfS0VZUklORyBp
cyBub3Qgc2V0CiMgQ09ORklHX1BST0ZJTElORyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX09Q
Uk9GSUxFPXkKQ09ORklHX09QUk9GSUxFX05NSV9USU1FUj15CiMgQ09ORklHX0tQUk9CRVMg
aXMgbm90IHNldAojIENPTkZJR19KVU1QX0xBQkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfVVBS
T0JFUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hBVkVfNjRCSVRfQUxJR05FRF9BQ0NFU1MgaXMg
bm90IHNldApDT05GSUdfSEFWRV9FRkZJQ0lFTlRfVU5BTElHTkVEX0FDQ0VTUz15CkNPTkZJ
R19BUkNIX1VTRV9CVUlMVElOX0JTV0FQPXkKQ09ORklHX0hBVkVfSU9SRU1BUF9QUk9UPXkK
Q09ORklHX0hBVkVfS1BST0JFUz15CkNPTkZJR19IQVZFX0tSRVRQUk9CRVM9eQpDT05GSUdf
SEFWRV9PUFRQUk9CRVM9eQpDT05GSUdfSEFWRV9LUFJPQkVTX09OX0ZUUkFDRT15CkNPTkZJ
R19IQVZFX0FSQ0hfVFJBQ0VIT09LPXkKQ09ORklHX0hBVkVfRE1BX0FUVFJTPXkKQ09ORklH
X0hBVkVfRE1BX0NPTlRJR1VPVVM9eQpDT05GSUdfR0VORVJJQ19TTVBfSURMRV9USFJFQUQ9
eQpDT05GSUdfSEFWRV9SRUdTX0FORF9TVEFDS19BQ0NFU1NfQVBJPXkKQ09ORklHX0hBVkVf
RE1BX0FQSV9ERUJVRz15CkNPTkZJR19IQVZFX0hXX0JSRUFLUE9JTlQ9eQpDT05GSUdfSEFW
RV9NSVhFRF9CUkVBS1BPSU5UU19SRUdTPXkKQ09ORklHX0hBVkVfVVNFUl9SRVRVUk5fTk9U
SUZJRVI9eQpDT05GSUdfSEFWRV9QRVJGX0VWRU5UU19OTUk9eQpDT05GSUdfSEFWRV9QRVJG
X1JFR1M9eQpDT05GSUdfSEFWRV9QRVJGX1VTRVJfU1RBQ0tfRFVNUD15CkNPTkZJR19IQVZF
X0FSQ0hfSlVNUF9MQUJFTD15CkNPTkZJR19BUkNIX0hBVkVfTk1JX1NBRkVfQ01QWENIRz15
CkNPTkZJR19IQVZFX0FMSUdORURfU1RSVUNUX1BBR0U9eQpDT05GSUdfSEFWRV9DTVBYQ0hH
X0xPQ0FMPXkKQ09ORklHX0hBVkVfQ01QWENIR19ET1VCTEU9eQpDT05GSUdfSEFWRV9BUkNI
X1NFQ0NPTVBfRklMVEVSPXkKQ09ORklHX1NFQ0NPTVBfRklMVEVSPXkKQ09ORklHX0hBVkVf
Q0NfU1RBQ0tQUk9URUNUT1I9eQojIENPTkZJR19DQ19TVEFDS1BST1RFQ1RPUiBpcyBub3Qg
c2V0CkNPTkZJR19DQ19TVEFDS1BST1RFQ1RPUl9OT05FPXkKIyBDT05GSUdfQ0NfU1RBQ0tQ
Uk9URUNUT1JfUkVHVUxBUiBpcyBub3Qgc2V0CiMgQ09ORklHX0NDX1NUQUNLUFJPVEVDVE9S
X1NUUk9ORyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0NPTlRFWFRfVFJBQ0tJTkc9eQpDT05G
SUdfSEFWRV9WSVJUX0NQVV9BQ0NPVU5USU5HX0dFTj15CkNPTkZJR19IQVZFX0lSUV9USU1F
X0FDQ09VTlRJTkc9eQpDT05GSUdfSEFWRV9BUkNIX1RSQU5TUEFSRU5UX0hVR0VQQUdFPXkK
Q09ORklHX0hBVkVfQVJDSF9TT0ZUX0RJUlRZPXkKQ09ORklHX01PRFVMRVNfVVNFX0VMRl9S
RUxBPXkKQ09ORklHX0hBVkVfSVJRX0VYSVRfT05fSVJRX1NUQUNLPXkKCiMKIyBHQ09WLWJh
c2VkIGtlcm5lbCBwcm9maWxpbmcKIwojIENPTkZJR19IQVZFX0dFTkVSSUNfRE1BX0NPSEVS
RU5UIGlzIG5vdCBzZXQKQ09ORklHX1NMQUJJTkZPPXkKQ09ORklHX1JUX01VVEVYRVM9eQpD
T05GSUdfQkFTRV9TTUFMTD0wCkNPTkZJR19NT0RVTEVTPXkKIyBDT05GSUdfTU9EVUxFX0ZP
UkNFX0xPQUQgaXMgbm90IHNldApDT05GSUdfTU9EVUxFX1VOTE9BRD15CiMgQ09ORklHX01P
RFVMRV9GT1JDRV9VTkxPQUQgaXMgbm90IHNldAojIENPTkZJR19NT0RWRVJTSU9OUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX01PRFVMRV9TUkNWRVJTSU9OX0FMTCBpcyBub3Qgc2V0CiMgQ09O
RklHX01PRFVMRV9TSUcgaXMgbm90IHNldApDT05GSUdfU1RPUF9NQUNISU5FPXkKQ09ORklH
X0JMT0NLPXkKQ09ORklHX0JMS19ERVZfQlNHPXkKQ09ORklHX0JMS19ERVZfQlNHTElCPXkK
Q09ORklHX0JMS19ERVZfSU5URUdSSVRZPXkKQ09ORklHX0JMS19ERVZfVEhST1RUTElORz15
CkNPTkZJR19CTEtfQ01ETElORV9QQVJTRVI9eQoKIwojIFBhcnRpdGlvbiBUeXBlcwojCiMg
Q09ORklHX1BBUlRJVElPTl9BRFZBTkNFRCBpcyBub3Qgc2V0CkNPTkZJR19NU0RPU19QQVJU
SVRJT049eQpDT05GSUdfRUZJX1BBUlRJVElPTj15CgojCiMgSU8gU2NoZWR1bGVycwojCkNP
TkZJR19JT1NDSEVEX05PT1A9eQpDT05GSUdfSU9TQ0hFRF9ERUFETElORT15CkNPTkZJR19J
T1NDSEVEX0NGUT15CkNPTkZJR19DRlFfR1JPVVBfSU9TQ0hFRD15CiMgQ09ORklHX0RFRkFV
TFRfREVBRExJTkUgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9DRlE9eQojIENPTkZJR19E
RUZBVUxUX05PT1AgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9JT1NDSEVEPSJjZnEiCkNP
TkZJR19QQURBVEE9eQpDT05GSUdfVU5JTkxJTkVfU1BJTl9VTkxPQ0s9eQpDT05GSUdfSU5M
SU5FX1NQSU5fVU5MT0NLX0lSUT15CkNPTkZJR19JTkxJTkVfUkVBRF9VTkxPQ0s9eQpDT05G
SUdfSU5MSU5FX1JFQURfVU5MT0NLX0lSUT15CkNPTkZJR19JTkxJTkVfV1JJVEVfVU5MT0NL
PXkKQ09ORklHX0lOTElORV9XUklURV9VTkxPQ0tfSVJRPXkKQ09ORklHX01VVEVYX1NQSU5f
T05fT1dORVI9eQpDT05GSUdfQVJDSF9VU0VfUVVFVUVfUldMT0NLPXkKQ09ORklHX1FVRVVF
X1JXTE9DSz15CkNPTkZJR19GUkVFWkVSPXkKCiMKIyBQcm9jZXNzb3IgdHlwZSBhbmQgZmVh
dHVyZXMKIwpDT05GSUdfWk9ORV9ETUE9eQpDT05GSUdfU01QPXkKQ09ORklHX1g4Nl9YMkFQ
SUM9eQpDT05GSUdfWDg2X01QUEFSU0U9eQojIENPTkZJR19YODZfRVhURU5ERURfUExBVEZP
Uk0gaXMgbm90IHNldAojIENPTkZJR19YODZfSU5URUxfTFBTUyBpcyBub3Qgc2V0CkNPTkZJ
R19YODZfU1VQUE9SVFNfTUVNT1JZX0ZBSUxVUkU9eQpDT05GSUdfU0NIRURfT01JVF9GUkFN
RV9QT0lOVEVSPXkKQ09ORklHX0hZUEVSVklTT1JfR1VFU1Q9eQpDT05GSUdfUEFSQVZJUlQ9
eQojIENPTkZJR19QQVJBVklSVF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19QQVJBVklSVF9T
UElOTE9DS1M9eQpDT05GSUdfWEVOPXkKQ09ORklHX1hFTl9ET00wPXkKQ09ORklHX1hFTl9Q
VkhWTT15CkNPTkZJR19YRU5fTUFYX0RPTUFJTl9NRU1PUlk9NTAwCkNPTkZJR19YRU5fU0FW
RV9SRVNUT1JFPXkKIyBDT05GSUdfWEVOX1BWSCBpcyBub3Qgc2V0CiMgQ09ORklHX0tWTV9H
VUVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBUkFWSVJUX1RJTUVfQUNDT1VOVElORyBpcyBu
b3Qgc2V0CkNPTkZJR19QQVJBVklSVF9DTE9DSz15CkNPTkZJR19OT19CT09UTUVNPXkKIyBD
T05GSUdfTUVNVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX01LOCBpcyBub3Qgc2V0CiMgQ09O
RklHX01QU0MgaXMgbm90IHNldAojIENPTkZJR19NQ09SRTIgaXMgbm90IHNldAojIENPTkZJ
R19NQVRPTSBpcyBub3Qgc2V0CkNPTkZJR19HRU5FUklDX0NQVT15CkNPTkZJR19YODZfSU5U
RVJOT0RFX0NBQ0hFX1NISUZUPTYKQ09ORklHX1g4Nl9MMV9DQUNIRV9TSElGVD02CkNPTkZJ
R19YODZfVFNDPXkKQ09ORklHX1g4Nl9DTVBYQ0hHNjQ9eQpDT05GSUdfWDg2X0NNT1Y9eQpD
T05GSUdfWDg2X01JTklNVU1fQ1BVX0ZBTUlMWT02NApDT05GSUdfWDg2X0RFQlVHQ1RMTVNS
PXkKQ09ORklHX0NQVV9TVVBfSU5URUw9eQpDT05GSUdfQ1BVX1NVUF9BTUQ9eQpDT05GSUdf
Q1BVX1NVUF9DRU5UQVVSPXkKQ09ORklHX0hQRVRfVElNRVI9eQpDT05GSUdfSFBFVF9FTVVM
QVRFX1JUQz15CkNPTkZJR19ETUk9eQpDT05GSUdfR0FSVF9JT01NVT15CiMgQ09ORklHX0NB
TEdBUllfSU9NTVUgaXMgbm90IHNldApDT05GSUdfU1dJT1RMQj15CkNPTkZJR19JT01NVV9I
RUxQRVI9eQojIENPTkZJR19NQVhTTVAgaXMgbm90IHNldApDT05GSUdfTlJfQ1BVUz0xNgpD
T05GSUdfU0NIRURfU01UPXkKQ09ORklHX1NDSEVEX01DPXkKIyBDT05GSUdfUFJFRU1QVF9O
T05FIGlzIG5vdCBzZXQKQ09ORklHX1BSRUVNUFRfVk9MVU5UQVJZPXkKIyBDT05GSUdfUFJF
RU1QVCBpcyBub3Qgc2V0CkNPTkZJR19YODZfTE9DQUxfQVBJQz15CkNPTkZJR19YODZfSU9f
QVBJQz15CkNPTkZJR19YODZfUkVST1VURV9GT1JfQlJPS0VOX0JPT1RfSVJRUz15CkNPTkZJ
R19YODZfTUNFPXkKQ09ORklHX1g4Nl9NQ0VfSU5URUw9eQpDT05GSUdfWDg2X01DRV9BTUQ9
eQpDT05GSUdfWDg2X01DRV9USFJFU0hPTEQ9eQojIENPTkZJR19YODZfTUNFX0lOSkVDVCBp
cyBub3Qgc2V0CkNPTkZJR19YODZfVEhFUk1BTF9WRUNUT1I9eQpDT05GSUdfWDg2XzE2QklU
PXkKQ09ORklHX1g4Nl9FU1BGSVg2ND15CiMgQ09ORklHX0k4SyBpcyBub3Qgc2V0CkNPTkZJ
R19NSUNST0NPREU9eQpDT05GSUdfTUlDUk9DT0RFX0lOVEVMPXkKQ09ORklHX01JQ1JPQ09E
RV9BTUQ9eQpDT05GSUdfTUlDUk9DT0RFX09MRF9JTlRFUkZBQ0U9eQpDT05GSUdfTUlDUk9D
T0RFX0lOVEVMX0VBUkxZPXkKQ09ORklHX01JQ1JPQ09ERV9BTURfRUFSTFk9eQpDT05GSUdf
TUlDUk9DT0RFX0VBUkxZPXkKQ09ORklHX1g4Nl9NU1I9eQpDT05GSUdfWDg2X0NQVUlEPXkK
Q09ORklHX0FSQ0hfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfQVJDSF9ETUFfQUREUl9U
XzY0QklUPXkKQ09ORklHX0RJUkVDVF9HQlBBR0VTPXkKIyBDT05GSUdfTlVNQSBpcyBub3Qg
c2V0CkNPTkZJR19BUkNIX1NQQVJTRU1FTV9FTkFCTEU9eQpDT05GSUdfQVJDSF9TUEFSU0VN
RU1fREVGQVVMVD15CkNPTkZJR19BUkNIX1NFTEVDVF9NRU1PUllfTU9ERUw9eQpDT05GSUdf
QVJDSF9QUk9DX0tDT1JFX1RFWFQ9eQpDT05GSUdfSUxMRUdBTF9QT0lOVEVSX1ZBTFVFPTB4
ZGVhZDAwMDAwMDAwMDAwMApDT05GSUdfU0VMRUNUX01FTU9SWV9NT0RFTD15CkNPTkZJR19T
UEFSU0VNRU1fTUFOVUFMPXkKQ09ORklHX1NQQVJTRU1FTT15CkNPTkZJR19IQVZFX01FTU9S
WV9QUkVTRU5UPXkKQ09ORklHX1NQQVJTRU1FTV9FWFRSRU1FPXkKQ09ORklHX1NQQVJTRU1F
TV9WTUVNTUFQX0VOQUJMRT15CkNPTkZJR19TUEFSU0VNRU1fQUxMT0NfTUVNX01BUF9UT0dF
VEhFUj15CkNPTkZJR19TUEFSU0VNRU1fVk1FTU1BUD15CkNPTkZJR19IQVZFX01FTUJMT0NL
PXkKQ09ORklHX0hBVkVfTUVNQkxPQ0tfTk9ERV9NQVA9eQpDT05GSUdfQVJDSF9ESVNDQVJE
X01FTUJMT0NLPXkKQ09ORklHX01FTU9SWV9JU09MQVRJT049eQojIENPTkZJR19IQVZFX0JP
T1RNRU1fSU5GT19OT0RFIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVNT1JZX0hPVFBMVUcgaXMg
bm90IHNldApDT05GSUdfUEFHRUZMQUdTX0VYVEVOREVEPXkKQ09ORklHX1NQTElUX1BUTE9D
S19DUFVTPTQKQ09ORklHX0FSQ0hfRU5BQkxFX1NQTElUX1BNRF9QVExPQ0s9eQpDT05GSUdf
QkFMTE9PTl9DT01QQUNUSU9OPXkKQ09ORklHX0NPTVBBQ1RJT049eQpDT05GSUdfTUlHUkFU
SU9OPXkKQ09ORklHX0FSQ0hfRU5BQkxFX0hVR0VQQUdFX01JR1JBVElPTj15CkNPTkZJR19Q
SFlTX0FERFJfVF82NEJJVD15CkNPTkZJR19aT05FX0RNQV9GTEFHPTEKQ09ORklHX0JPVU5D
RT15CkNPTkZJR19ORUVEX0JPVU5DRV9QT09MPXkKQ09ORklHX1ZJUlRfVE9fQlVTPXkKQ09O
RklHX01NVV9OT1RJRklFUj15CkNPTkZJR19LU009eQpDT05GSUdfREVGQVVMVF9NTUFQX01J
Tl9BRERSPTY1NTM2CkNPTkZJR19BUkNIX1NVUFBPUlRTX01FTU9SWV9GQUlMVVJFPXkKQ09O
RklHX01FTU9SWV9GQUlMVVJFPXkKIyBDT05GSUdfSFdQT0lTT05fSU5KRUNUIGlzIG5vdCBz
ZXQKQ09ORklHX1RSQU5TUEFSRU5UX0hVR0VQQUdFPXkKIyBDT05GSUdfVFJBTlNQQVJFTlRf
SFVHRVBBR0VfQUxXQVlTIGlzIG5vdCBzZXQKQ09ORklHX1RSQU5TUEFSRU5UX0hVR0VQQUdF
X01BRFZJU0U9eQojIENPTkZJR19DTEVBTkNBQ0hFIGlzIG5vdCBzZXQKIyBDT05GSUdfRlJP
TlRTV0FQIGlzIG5vdCBzZXQKIyBDT05GSUdfQ01BIGlzIG5vdCBzZXQKIyBDT05GSUdfWkJV
RCBpcyBub3Qgc2V0CiMgQ09ORklHX1pTTUFMTE9DIGlzIG5vdCBzZXQKQ09ORklHX0dFTkVS
SUNfRUFSTFlfSU9SRU1BUD15CiMgQ09ORklHX1g4Nl9DSEVDS19CSU9TX0NPUlJVUFRJT04g
aXMgbm90IHNldApDT05GSUdfWDg2X1JFU0VSVkVfTE9XPTY0CkNPTkZJR19NVFJSPXkKQ09O
RklHX01UUlJfU0FOSVRJWkVSPXkKQ09ORklHX01UUlJfU0FOSVRJWkVSX0VOQUJMRV9ERUZB
VUxUPTAKQ09ORklHX01UUlJfU0FOSVRJWkVSX1NQQVJFX1JFR19OUl9ERUZBVUxUPTEKQ09O
RklHX1g4Nl9QQVQ9eQpDT05GSUdfQVJDSF9VU0VTX1BHX1VOQ0FDSEVEPXkKQ09ORklHX0FS
Q0hfUkFORE9NPXkKQ09ORklHX1g4Nl9TTUFQPXkKQ09ORklHX0VGST15CkNPTkZJR19FRklf
U1RVQj15CiMgQ09ORklHX0VGSV9NSVhFRCBpcyBub3Qgc2V0CkNPTkZJR19TRUNDT01QPXkK
IyBDT05GSUdfSFpfMTAwIGlzIG5vdCBzZXQKQ09ORklHX0haXzI1MD15CiMgQ09ORklHX0ha
XzMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0haXzEwMDAgaXMgbm90IHNldApDT05GSUdfSFo9
MjUwCkNPTkZJR19TQ0hFRF9IUlRJQ0s9eQpDT05GSUdfS0VYRUM9eQpDT05GSUdfQ1JBU0hf
RFVNUD15CkNPTkZJR19QSFlTSUNBTF9TVEFSVD0weDEwMDAwMDAKQ09ORklHX1JFTE9DQVRB
QkxFPXkKIyBDT05GSUdfUkFORE9NSVpFX0JBU0UgaXMgbm90IHNldApDT05GSUdfUEhZU0lD
QUxfQUxJR049MHgxMDAwMDAwCkNPTkZJR19IT1RQTFVHX0NQVT15CiMgQ09ORklHX0JPT1RQ
QVJBTV9IT1RQTFVHX0NQVTAgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19IT1RQTFVHX0NQ
VTAgaXMgbm90IHNldAojIENPTkZJR19DTURMSU5FX0JPT0wgaXMgbm90IHNldApDT05GSUdf
QVJDSF9FTkFCTEVfTUVNT1JZX0hPVFBMVUc9eQoKIwojIFBvd2VyIG1hbmFnZW1lbnQgYW5k
IEFDUEkgb3B0aW9ucwojCiMgQ09ORklHX1NVU1BFTkQgaXMgbm90IHNldApDT05GSUdfSElC
RVJOQVRFX0NBTExCQUNLUz15CiMgQ09ORklHX0hJQkVSTkFUSU9OIGlzIG5vdCBzZXQKQ09O
RklHX1BNX1NMRUVQPXkKQ09ORklHX1BNX1NMRUVQX1NNUD15CiMgQ09ORklHX1BNX0FVVE9T
TEVFUCBpcyBub3Qgc2V0CiMgQ09ORklHX1BNX1dBS0VMT0NLUyBpcyBub3Qgc2V0CkNPTkZJ
R19QTV9SVU5USU1FPXkKQ09ORklHX1BNPXkKIyBDT05GSUdfUE1fREVCVUcgaXMgbm90IHNl
dAojIENPTkZJR19XUV9QT1dFUl9FRkZJQ0lFTlRfREVGQVVMVCBpcyBub3Qgc2V0CkNPTkZJ
R19BQ1BJPXkKIyBDT05GSUdfQUNQSV9QUk9DRlNfUE9XRVIgaXMgbm90IHNldAojIENPTkZJ
R19BQ1BJX0VDX0RFQlVHRlMgaXMgbm90IHNldApDT05GSUdfQUNQSV9BQz15CkNPTkZJR19B
Q1BJX0JBVFRFUlk9eQpDT05GSUdfQUNQSV9CVVRUT049eQpDT05GSUdfQUNQSV9WSURFTz15
CkNPTkZJR19BQ1BJX0ZBTj15CkNPTkZJR19BQ1BJX0RPQ0s9eQpDT05GSUdfQUNQSV9QUk9D
RVNTT1I9eQpDT05GSUdfQUNQSV9JUE1JPXkKQ09ORklHX0FDUElfSE9UUExVR19DUFU9eQpD
T05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUj15CkNPTkZJR19BQ1BJX1RIRVJNQUw9
eQpDT05GSUdfQUNQSV9DVVNUT01fRFNEVF9GSUxFPSIiCiMgQ09ORklHX0FDUElfQ1VTVE9N
X0RTRFQgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX0lOSVRSRF9UQUJMRV9PVkVSUklERSBp
cyBub3Qgc2V0CiMgQ09ORklHX0FDUElfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19BQ1BJ
X1BDSV9TTE9UIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9QTV9USU1FUj15CkNPTkZJR19BQ1BJ
X0NPTlRBSU5FUj15CiMgQ09ORklHX0FDUElfU0JTIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNQ
SV9IRUQgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX0JHUlQgaXMgbm90IHNldAojIENPTkZJ
R19BQ1BJX1JFRFVDRURfSEFSRFdBUkVfT05MWSBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElf
QVBFSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElfRVhUTE9HIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0ZJIGlzIG5vdCBzZXQKCiMKIyBDUFUgRnJlcXVlbmN5IHNjYWxpbmcKIwpDT05GSUdf
Q1BVX0ZSRVE9eQpDT05GSUdfQ1BVX0ZSRVFfR09WX0NPTU1PTj15CkNPTkZJR19DUFVfRlJF
UV9TVEFUPXkKIyBDT05GSUdfQ1BVX0ZSRVFfU1RBVF9ERVRBSUxTIGlzIG5vdCBzZXQKIyBD
T05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9HT1ZfUEVSRk9STUFOQ0UgaXMgbm90IHNldAojIENP
TkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9VU0VSU1BBQ0UgaXMgbm90IHNldApDT05GSUdf
Q1BVX0ZSRVFfREVGQVVMVF9HT1ZfT05ERU1BTkQ9eQojIENPTkZJR19DUFVfRlJFUV9ERUZB
VUxUX0dPVl9DT05TRVJWQVRJVkUgaXMgbm90IHNldApDT05GSUdfQ1BVX0ZSRVFfR09WX1BF
UkZPUk1BTkNFPXkKIyBDT05GSUdfQ1BVX0ZSRVFfR09WX1BPV0VSU0FWRSBpcyBub3Qgc2V0
CiMgQ09ORklHX0NQVV9GUkVRX0dPVl9VU0VSU1BBQ0UgaXMgbm90IHNldApDT05GSUdfQ1BV
X0ZSRVFfR09WX09OREVNQU5EPXkKIyBDT05GSUdfQ1BVX0ZSRVFfR09WX0NPTlNFUlZBVElW
RSBpcyBub3Qgc2V0CgojCiMgeDg2IENQVSBmcmVxdWVuY3kgc2NhbGluZyBkcml2ZXJzCiMK
Q09ORklHX1g4Nl9JTlRFTF9QU1RBVEU9eQpDT05GSUdfWDg2X1BDQ19DUFVGUkVRPW0KQ09O
RklHX1g4Nl9BQ1BJX0NQVUZSRVE9bQpDT05GSUdfWDg2X0FDUElfQ1BVRlJFUV9DUEI9eQpD
T05GSUdfWDg2X1BPV0VSTk9XX0s4PW0KIyBDT05GSUdfWDg2X0FNRF9GUkVRX1NFTlNJVElW
SVRZIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9TUEVFRFNURVBfQ0VOVFJJTk89bQpDT05GSUdf
WDg2X1A0X0NMT0NLTU9EPW0KCiMKIyBzaGFyZWQgb3B0aW9ucwojCkNPTkZJR19YODZfU1BF
RURTVEVQX0xJQj1tCgojCiMgQ1BVIElkbGUKIwpDT05GSUdfQ1BVX0lETEU9eQojIENPTkZJ
R19DUFVfSURMRV9NVUxUSVBMRV9EUklWRVJTIGlzIG5vdCBzZXQKQ09ORklHX0NQVV9JRExF
X0dPVl9MQURERVI9eQpDT05GSUdfQ1BVX0lETEVfR09WX01FTlU9eQojIENPTkZJR19BUkNI
X05FRURTX0NQVV9JRExFX0NPVVBMRUQgaXMgbm90IHNldApDT05GSUdfSU5URUxfSURMRT15
CgojCiMgTWVtb3J5IHBvd2VyIHNhdmluZ3MKIwpDT05GSUdfSTczMDBfSURMRV9JT0FUX0NI
QU5ORUw9eQpDT05GSUdfSTczMDBfSURMRT15CgojCiMgQnVzIG9wdGlvbnMgKFBDSSBldGMu
KQojCkNPTkZJR19QQ0k9eQpDT05GSUdfUENJX0RJUkVDVD15CkNPTkZJR19QQ0lfTU1DT05G
SUc9eQpDT05GSUdfUENJX1hFTj15CkNPTkZJR19QQ0lfRE9NQUlOUz15CkNPTkZJR19QQ0lF
UE9SVEJVUz15CkNPTkZJR19IT1RQTFVHX1BDSV9QQ0lFPXkKQ09ORklHX1BDSUVBRVI9eQoj
IENPTkZJR19QQ0lFX0VDUkMgaXMgbm90IHNldAojIENPTkZJR19QQ0lFQUVSX0lOSkVDVCBp
cyBub3Qgc2V0CkNPTkZJR19QQ0lFQVNQTT15CiMgQ09ORklHX1BDSUVBU1BNX0RFQlVHIGlz
IG5vdCBzZXQKQ09ORklHX1BDSUVBU1BNX0RFRkFVTFQ9eQojIENPTkZJR19QQ0lFQVNQTV9Q
T1dFUlNBVkUgaXMgbm90IHNldAojIENPTkZJR19QQ0lFQVNQTV9QRVJGT1JNQU5DRSBpcyBu
b3Qgc2V0CkNPTkZJR19QQ0lFX1BNRT15CkNPTkZJR19QQ0lfTVNJPXkKIyBDT05GSUdfUENJ
X0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfUENJX1JFQUxMT0NfRU5BQkxFX0FVVE8gaXMg
bm90IHNldApDT05GSUdfUENJX1NUVUI9eQpDT05GSUdfWEVOX1BDSURFVl9GUk9OVEVORD15
CkNPTkZJR19IVF9JUlE9eQpDT05GSUdfUENJX0FUUz15CkNPTkZJR19QQ0lfSU9WPXkKQ09O
RklHX1BDSV9QUkk9eQpDT05GSUdfUENJX1BBU0lEPXkKQ09ORklHX1BDSV9JT0FQSUM9eQpD
T05GSUdfUENJX0xBQkVMPXkKCiMKIyBQQ0kgaG9zdCBjb250cm9sbGVyIGRyaXZlcnMKIwpD
T05GSUdfSVNBX0RNQV9BUEk9eQpDT05GSUdfQU1EX05CPXkKIyBDT05GSUdfUENDQVJEIGlz
IG5vdCBzZXQKQ09ORklHX0hPVFBMVUdfUENJPXkKQ09ORklHX0hPVFBMVUdfUENJX0FDUEk9
eQpDT05GSUdfSE9UUExVR19QQ0lfQUNQSV9JQk09eQpDT05GSUdfSE9UUExVR19QQ0lfQ1BD
ST15CkNPTkZJR19IT1RQTFVHX1BDSV9DUENJX1pUNTU1MD15CkNPTkZJR19IT1RQTFVHX1BD
SV9DUENJX0dFTkVSSUM9eQpDT05GSUdfSE9UUExVR19QQ0lfU0hQQz15CiMgQ09ORklHX1JB
UElESU8gaXMgbm90IHNldAojIENPTkZJR19YODZfU1lTRkIgaXMgbm90IHNldAoKIwojIEV4
ZWN1dGFibGUgZmlsZSBmb3JtYXRzIC8gRW11bGF0aW9ucwojCkNPTkZJR19CSU5GTVRfRUxG
PXkKQ09ORklHX0FSQ0hfQklORk1UX0VMRl9SQU5ET01JWkVfUElFPXkKQ09ORklHX0NPUkVf
RFVNUF9ERUZBVUxUX0VMRl9IRUFERVJTPXkKQ09ORklHX0JJTkZNVF9TQ1JJUFQ9eQojIENP
TkZJR19IQVZFX0FPVVQgaXMgbm90IHNldApDT05GSUdfQklORk1UX01JU0M9eQpDT05GSUdf
Q09SRURVTVA9eQojIENPTkZJR19JQTMyX0VNVUxBVElPTiBpcyBub3Qgc2V0CkNPTkZJR19Y
ODZfREVWX0RNQV9PUFM9eQpDT05GSUdfSU9TRl9NQkk9bQpDT05GSUdfTkVUPXkKCiMKIyBO
ZXR3b3JraW5nIG9wdGlvbnMKIwpDT05GSUdfUEFDS0VUPXkKIyBDT05GSUdfUEFDS0VUX0RJ
QUcgaXMgbm90IHNldApDT05GSUdfVU5JWD15CiMgQ09ORklHX1VOSVhfRElBRyBpcyBub3Qg
c2V0CkNPTkZJR19YRlJNPXkKQ09ORklHX1hGUk1fQUxHTz15CkNPTkZJR19YRlJNX1VTRVI9
eQpDT05GSUdfWEZSTV9TVUJfUE9MSUNZPXkKQ09ORklHX1hGUk1fTUlHUkFURT15CiMgQ09O
RklHX1hGUk1fU1RBVElTVElDUyBpcyBub3Qgc2V0CkNPTkZJR19YRlJNX0lQQ09NUD15CkNP
TkZJR19ORVRfS0VZPXkKQ09ORklHX05FVF9LRVlfTUlHUkFURT15CkNPTkZJR19JTkVUPXkK
Q09ORklHX0lQX01VTFRJQ0FTVD15CkNPTkZJR19JUF9BRFZBTkNFRF9ST1VURVI9eQpDT05G
SUdfSVBfRklCX1RSSUVfU1RBVFM9eQpDT05GSUdfSVBfTVVMVElQTEVfVEFCTEVTPXkKQ09O
RklHX0lQX1JPVVRFX01VTFRJUEFUSD15CkNPTkZJR19JUF9ST1VURV9WRVJCT1NFPXkKQ09O
RklHX0lQX1JPVVRFX0NMQVNTSUQ9eQojIENPTkZJR19JUF9QTlAgaXMgbm90IHNldAojIENP
TkZJR19ORVRfSVBJUCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9JUEdSRV9ERU1VWCBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9JUF9UVU5ORUwgaXMgbm90IHNldAojIENPTkZJR19JUF9N
Uk9VVEUgaXMgbm90IHNldApDT05GSUdfU1lOX0NPT0tJRVM9eQojIENPTkZJR19ORVRfSVBW
VEkgaXMgbm90IHNldApDT05GSUdfSU5FVF9BSD15CkNPTkZJR19JTkVUX0VTUD15CkNPTkZJ
R19JTkVUX0lQQ09NUD15CkNPTkZJR19JTkVUX1hGUk1fVFVOTkVMPXkKQ09ORklHX0lORVRf
VFVOTkVMPXkKQ09ORklHX0lORVRfWEZSTV9NT0RFX1RSQU5TUE9SVD15CkNPTkZJR19JTkVU
X1hGUk1fTU9ERV9UVU5ORUw9eQpDT05GSUdfSU5FVF9YRlJNX01PREVfQkVFVD15CkNPTkZJ
R19JTkVUX0xSTz15CkNPTkZJR19JTkVUX0RJQUc9eQpDT05GSUdfSU5FVF9UQ1BfRElBRz15
CiMgQ09ORklHX0lORVRfVURQX0RJQUcgaXMgbm90IHNldAojIENPTkZJR19UQ1BfQ09OR19B
RFZBTkNFRCBpcyBub3Qgc2V0CkNPTkZJR19UQ1BfQ09OR19DVUJJQz15CkNPTkZJR19ERUZB
VUxUX1RDUF9DT05HPSJjdWJpYyIKQ09ORklHX1RDUF9NRDVTSUc9eQojIENPTkZJR19JUFY2
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUTEFCRUwgaXMgbm90IHNldApDT05GSUdfTkVUV09S
S19TRUNNQVJLPXkKQ09ORklHX05FVF9QVFBfQ0xBU1NJRlk9eQojIENPTkZJR19ORVRXT1JL
X1BIWV9USU1FU1RBTVBJTkcgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSPXkKIyBDT05G
SUdfTkVURklMVEVSX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9BRFZBTkNF
RD15CiMgQ09ORklHX0JSSURHRV9ORVRGSUxURVIgaXMgbm90IHNldAoKIwojIENvcmUgTmV0
ZmlsdGVyIENvbmZpZ3VyYXRpb24KIwpDT05GSUdfTkVURklMVEVSX05FVExJTks9eQpDT05G
SUdfTkVURklMVEVSX05FVExJTktfQUNDVD15CkNPTkZJR19ORVRGSUxURVJfTkVUTElOS19R
VUVVRT15CkNPTkZJR19ORVRGSUxURVJfTkVUTElOS19MT0c9eQpDT05GSUdfTkZfQ09OTlRS
QUNLPXkKQ09ORklHX05GX0NPTk5UUkFDS19NQVJLPXkKQ09ORklHX05GX0NPTk5UUkFDS19T
RUNNQVJLPXkKQ09ORklHX05GX0NPTk5UUkFDS19aT05FUz15CkNPTkZJR19ORl9DT05OVFJB
Q0tfUFJPQ0ZTPXkKQ09ORklHX05GX0NPTk5UUkFDS19FVkVOVFM9eQojIENPTkZJR19ORl9D
T05OVFJBQ0tfVElNRU9VVCBpcyBub3Qgc2V0CkNPTkZJR19ORl9DT05OVFJBQ0tfVElNRVNU
QU1QPXkKIyBDT05GSUdfTkZfQ1RfUFJPVE9fRENDUCBpcyBub3Qgc2V0CiMgQ09ORklHX05G
X0NUX1BST1RPX1NDVFAgaXMgbm90IHNldApDT05GSUdfTkZfQ1RfUFJPVE9fVURQTElURT15
CiMgQ09ORklHX05GX0NPTk5UUkFDS19BTUFOREEgaXMgbm90IHNldAojIENPTkZJR19ORl9D
T05OVFJBQ0tfRlRQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX0gzMjMgaXMg
bm90IHNldAojIENPTkZJR19ORl9DT05OVFJBQ0tfSVJDIGlzIG5vdCBzZXQKIyBDT05GSUdf
TkZfQ09OTlRSQUNLX05FVEJJT1NfTlMgaXMgbm90IHNldAojIENPTkZJR19ORl9DT05OVFJB
Q0tfU05NUCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0NPTk5UUkFDS19QUFRQIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1NBTkUgaXMgbm90IHNldAojIENPTkZJR19ORl9D
T05OVFJBQ0tfU0lQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1RGVFAgaXMg
bm90IHNldApDT05GSUdfTkZfQ1RfTkVUTElOSz15CiMgQ09ORklHX05GX0NUX05FVExJTktf
VElNRU9VVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9ORVRMSU5LX1FVRVVFX0NU
IGlzIG5vdCBzZXQKQ09ORklHX05GX05BVD15CkNPTkZJR19ORl9OQVRfTkVFREVEPXkKQ09O
RklHX05GX05BVF9QUk9UT19VRFBMSVRFPXkKIyBDT05GSUdfTkZfTkFUX0FNQU5EQSBpcyBu
b3Qgc2V0CiMgQ09ORklHX05GX05BVF9GVFAgaXMgbm90IHNldAojIENPTkZJR19ORl9OQVRf
SVJDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfTkFUX1NJUCBpcyBub3Qgc2V0CiMgQ09ORklH
X05GX05BVF9URlRQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfVEFCTEVTIGlzIG5vdCBzZXQK
Q09ORklHX05FVEZJTFRFUl9YVEFCTEVTPXkKCiMKIyBYdGFibGVzIGNvbWJpbmVkIG1vZHVs
ZXMKIwpDT05GSUdfTkVURklMVEVSX1hUX01BUks9eQpDT05GSUdfTkVURklMVEVSX1hUX0NP
Tk5NQVJLPXkKQ09ORklHX05FVEZJTFRFUl9YVF9TRVQ9eQoKIwojIFh0YWJsZXMgdGFyZ2V0
cwojCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0FVRElUPXkKQ09ORklHX05FVEZJTFRF
Ul9YVF9UQVJHRVRfQ0hFQ0tTVU09eQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9DTEFT
U0lGWT15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NPTk5NQVJLPXkKQ09ORklHX05F
VEZJTFRFUl9YVF9UQVJHRVRfQ09OTlNFQ01BUks9eQpDT05GSUdfTkVURklMVEVSX1hUX1RB
UkdFVF9DVD15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0RTQ1A9eQpDT05GSUdfTkVU
RklMVEVSX1hUX1RBUkdFVF9ITD15CiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfSE1B
UksgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9JRExFVElNRVI9eQpD
T05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9MRUQ9eQojIENPTkZJR19ORVRGSUxURVJfWFRf
VEFSR0VUX0xPRyBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX01BUks9
eQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9ORVRNQVA9eQpDT05GSUdfTkVURklMVEVS
X1hUX1RBUkdFVF9ORkxPRz15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX05GUVVFVUU9
eQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX05PVFJBQ0sgaXMgbm90IHNldApDT05G
SUdfTkVURklMVEVSX1hUX1RBUkdFVF9SQVRFRVNUPXkKQ09ORklHX05FVEZJTFRFUl9YVF9U
QVJHRVRfUkVESVJFQ1Q9eQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9URUU9eQpDT05G
SUdfTkVURklMVEVSX1hUX1RBUkdFVF9UUFJPWFk9eQpDT05GSUdfTkVURklMVEVSX1hUX1RB
UkdFVF9UUkFDRT15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1NFQ01BUks9eQpDT05G
SUdfTkVURklMVEVSX1hUX1RBUkdFVF9UQ1BNU1M9eQpDT05GSUdfTkVURklMVEVSX1hUX1RB
UkdFVF9UQ1BPUFRTVFJJUD15CgojCiMgWHRhYmxlcyBtYXRjaGVzCiMKQ09ORklHX05FVEZJ
TFRFUl9YVF9NQVRDSF9BRERSVFlQRT15CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9C
UEYgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ0dST1VQIGlzIG5v
dCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DTFVTVEVSPXkKQ09ORklHX05FVEZJ
TFRFUl9YVF9NQVRDSF9DT01NRU5UPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05O
QllURVM9eQojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ09OTkxBQkVMIGlzIG5vdCBz
ZXQKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OTElNSVQ9eQpDT05GSUdfTkVURklM
VEVSX1hUX01BVENIX0NPTk5NQVJLPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05O
VFJBQ0s9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0NQVT15CkNPTkZJR19ORVRGSUxU
RVJfWFRfTUFUQ0hfRENDUD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfREVWR1JPVVA9
eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0RTQ1A9eQpDT05GSUdfTkVURklMVEVSX1hU
X01BVENIX0VDTj15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfRVNQPXkKQ09ORklHX05F
VEZJTFRFUl9YVF9NQVRDSF9IQVNITElNSVQ9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENI
X0hFTFBFUj15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSEw9eQojIENPTkZJR19ORVRG
SUxURVJfWFRfTUFUQ0hfSVBDT01QIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9N
QVRDSF9JUFJBTkdFPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9JUFZTPXkKIyBDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX0wyVFAgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVS
X1hUX01BVENIX0xFTkdUSD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTElNSVQ9eQpD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX01BQz15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFU
Q0hfTUFSSz15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTVVMVElQT1JUPXkKIyBDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX05GQUNDVCBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxU
RVJfWFRfTUFUQ0hfT1NGPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9PV05FUj15CkNP
TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUE9MSUNZPXkKQ09ORklHX05FVEZJTFRFUl9YVF9N
QVRDSF9QS1RUWVBFPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9RVU9UQT15CkNPTkZJ
R19ORVRGSUxURVJfWFRfTUFUQ0hfUkFURUVTVD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFU
Q0hfUkVBTE09eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1JFQ0VOVD15CkNPTkZJR19O
RVRGSUxURVJfWFRfTUFUQ0hfU0NUUD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfU09D
S0VUPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TVEFURT15CkNPTkZJR19ORVRGSUxU
RVJfWFRfTUFUQ0hfU1RBVElTVElDPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TVFJJ
Tkc9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1RDUE1TUz15CkNPTkZJR19ORVRGSUxU
RVJfWFRfTUFUQ0hfVElNRT15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfVTMyPXkKQ09O
RklHX0lQX1NFVD15CkNPTkZJR19JUF9TRVRfTUFYPTI1NgpDT05GSUdfSVBfU0VUX0JJVE1B
UF9JUD15CkNPTkZJR19JUF9TRVRfQklUTUFQX0lQTUFDPXkKQ09ORklHX0lQX1NFVF9CSVRN
QVBfUE9SVD15CkNPTkZJR19JUF9TRVRfSEFTSF9JUD15CiMgQ09ORklHX0lQX1NFVF9IQVNI
X0lQTUFSSyBpcyBub3Qgc2V0CkNPTkZJR19JUF9TRVRfSEFTSF9JUFBPUlQ9eQpDT05GSUdf
SVBfU0VUX0hBU0hfSVBQT1JUSVA9eQpDT05GSUdfSVBfU0VUX0hBU0hfSVBQT1JUTkVUPXkK
IyBDT05GSUdfSVBfU0VUX0hBU0hfTkVUUE9SVE5FVCBpcyBub3Qgc2V0CkNPTkZJR19JUF9T
RVRfSEFTSF9ORVQ9eQojIENPTkZJR19JUF9TRVRfSEFTSF9ORVRORVQgaXMgbm90IHNldApD
T05GSUdfSVBfU0VUX0hBU0hfTkVUUE9SVD15CkNPTkZJR19JUF9TRVRfSEFTSF9ORVRJRkFD
RT15CkNPTkZJR19JUF9TRVRfTElTVF9TRVQ9eQpDT05GSUdfSVBfVlM9eQojIENPTkZJR19J
UF9WU19ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19JUF9WU19UQUJfQklUUz0xMgoKIwojIElQ
VlMgdHJhbnNwb3J0IHByb3RvY29sIGxvYWQgYmFsYW5jaW5nIHN1cHBvcnQKIwpDT05GSUdf
SVBfVlNfUFJPVE9fVENQPXkKQ09ORklHX0lQX1ZTX1BST1RPX1VEUD15CkNPTkZJR19JUF9W
U19QUk9UT19BSF9FU1A9eQpDT05GSUdfSVBfVlNfUFJPVE9fRVNQPXkKQ09ORklHX0lQX1ZT
X1BST1RPX0FIPXkKQ09ORklHX0lQX1ZTX1BST1RPX1NDVFA9eQoKIwojIElQVlMgc2NoZWR1
bGVyCiMKQ09ORklHX0lQX1ZTX1JSPXkKQ09ORklHX0lQX1ZTX1dSUj15CkNPTkZJR19JUF9W
U19MQz15CkNPTkZJR19JUF9WU19XTEM9eQpDT05GSUdfSVBfVlNfTEJMQz15CkNPTkZJR19J
UF9WU19MQkxDUj15CkNPTkZJR19JUF9WU19ESD15CkNPTkZJR19JUF9WU19TSD15CkNPTkZJ
R19JUF9WU19TRUQ9eQpDT05GSUdfSVBfVlNfTlE9eQoKIwojIElQVlMgU0ggc2NoZWR1bGVy
CiMKQ09ORklHX0lQX1ZTX1NIX1RBQl9CSVRTPTgKCiMKIyBJUFZTIGFwcGxpY2F0aW9uIGhl
bHBlcgojCkNPTkZJR19JUF9WU19ORkNUPXkKCiMKIyBJUDogTmV0ZmlsdGVyIENvbmZpZ3Vy
YXRpb24KIwpDT05GSUdfTkZfREVGUkFHX0lQVjQ9eQpDT05GSUdfTkZfQ09OTlRSQUNLX0lQ
VjQ9eQpDT05GSUdfTkZfQ09OTlRSQUNLX1BST0NfQ09NUEFUPXkKQ09ORklHX0lQX05GX0lQ
VEFCTEVTPXkKQ09ORklHX0lQX05GX01BVENIX0FIPXkKQ09ORklHX0lQX05GX01BVENIX0VD
Tj15CkNPTkZJR19JUF9ORl9NQVRDSF9SUEZJTFRFUj15CkNPTkZJR19JUF9ORl9NQVRDSF9U
VEw9eQpDT05GSUdfSVBfTkZfRklMVEVSPXkKQ09ORklHX0lQX05GX1RBUkdFVF9SRUpFQ1Q9
eQojIENPTkZJR19JUF9ORl9UQVJHRVRfU1lOUFJPWFkgaXMgbm90IHNldAojIENPTkZJR19J
UF9ORl9UQVJHRVRfVUxPRyBpcyBub3Qgc2V0CkNPTkZJR19ORl9OQVRfSVBWND15CiMgQ09O
RklHX0lQX05GX1RBUkdFVF9NQVNRVUVSQURFIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfTkZf
VEFSR0VUX05FVE1BUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX05GX1RBUkdFVF9SRURJUkVD
VCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX05BVF9QUFRQIGlzIG5vdCBzZXQKIyBDT05GSUdf
TkZfTkFUX0gzMjMgaXMgbm90IHNldApDT05GSUdfSVBfTkZfTUFOR0xFPXkKQ09ORklHX0lQ
X05GX1RBUkdFVF9DTFVTVEVSSVA9eQpDT05GSUdfSVBfTkZfVEFSR0VUX0VDTj15CkNPTkZJ
R19JUF9ORl9UQVJHRVRfVFRMPXkKQ09ORklHX0lQX05GX1JBVz15CkNPTkZJR19JUF9ORl9T
RUNVUklUWT15CkNPTkZJR19JUF9ORl9BUlBUQUJMRVM9eQpDT05GSUdfSVBfTkZfQVJQRklM
VEVSPXkKQ09ORklHX0lQX05GX0FSUF9NQU5HTEU9eQpDT05GSUdfQlJJREdFX05GX0VCVEFC
TEVTPXkKQ09ORklHX0JSSURHRV9FQlRfQlJPVVRFPXkKQ09ORklHX0JSSURHRV9FQlRfVF9G
SUxURVI9eQpDT05GSUdfQlJJREdFX0VCVF9UX05BVD15CkNPTkZJR19CUklER0VfRUJUXzgw
Ml8zPXkKQ09ORklHX0JSSURHRV9FQlRfQU1PTkc9eQpDT05GSUdfQlJJREdFX0VCVF9BUlA9
eQpDT05GSUdfQlJJREdFX0VCVF9JUD15CkNPTkZJR19CUklER0VfRUJUX0xJTUlUPXkKQ09O
RklHX0JSSURHRV9FQlRfTUFSSz15CkNPTkZJR19CUklER0VfRUJUX1BLVFRZUEU9eQpDT05G
SUdfQlJJREdFX0VCVF9TVFA9eQpDT05GSUdfQlJJREdFX0VCVF9WTEFOPXkKQ09ORklHX0JS
SURHRV9FQlRfQVJQUkVQTFk9eQpDT05GSUdfQlJJREdFX0VCVF9ETkFUPXkKQ09ORklHX0JS
SURHRV9FQlRfTUFSS19UPXkKQ09ORklHX0JSSURHRV9FQlRfUkVESVJFQ1Q9eQpDT05GSUdf
QlJJREdFX0VCVF9TTkFUPXkKQ09ORklHX0JSSURHRV9FQlRfTE9HPXkKIyBDT05GSUdfQlJJ
REdFX0VCVF9VTE9HIGlzIG5vdCBzZXQKQ09ORklHX0JSSURHRV9FQlRfTkZMT0c9eQojIENP
TkZJR19JUF9EQ0NQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfU0NUUCBpcyBub3Qgc2V0CiMg
Q09ORklHX1JEUyBpcyBub3Qgc2V0CiMgQ09ORklHX1RJUEMgaXMgbm90IHNldAojIENPTkZJ
R19BVE0gaXMgbm90IHNldAojIENPTkZJR19MMlRQIGlzIG5vdCBzZXQKQ09ORklHX1NUUD15
CkNPTkZJR19HQVJQPXkKQ09ORklHX0JSSURHRT15CkNPTkZJR19CUklER0VfSUdNUF9TTk9P
UElORz15CiMgQ09ORklHX0JSSURHRV9WTEFOX0ZJTFRFUklORyBpcyBub3Qgc2V0CkNPTkZJ
R19IQVZFX05FVF9EU0E9eQpDT05GSUdfVkxBTl84MDIxUT15CkNPTkZJR19WTEFOXzgwMjFR
X0dWUlA9eQojIENPTkZJR19WTEFOXzgwMjFRX01WUlAgaXMgbm90IHNldAojIENPTkZJR19E
RUNORVQgaXMgbm90IHNldApDT05GSUdfTExDPXkKIyBDT05GSUdfTExDMiBpcyBub3Qgc2V0
CiMgQ09ORklHX0lQWCBpcyBub3Qgc2V0CiMgQ09ORklHX0FUQUxLIGlzIG5vdCBzZXQKIyBD
T05GSUdfWDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfTEFQQiBpcyBub3Qgc2V0CiMgQ09ORklH
X1BIT05FVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lFRUU4MDIxNTQgaXMgbm90IHNldApDT05G
SUdfTkVUX1NDSEVEPXkKCiMKIyBRdWV1ZWluZy9TY2hlZHVsaW5nCiMKQ09ORklHX05FVF9T
Q0hfQ0JRPXkKQ09ORklHX05FVF9TQ0hfSFRCPXkKQ09ORklHX05FVF9TQ0hfSEZTQz15CkNP
TkZJR19ORVRfU0NIX1BSSU89eQpDT05GSUdfTkVUX1NDSF9NVUxUSVE9eQpDT05GSUdfTkVU
X1NDSF9SRUQ9eQpDT05GSUdfTkVUX1NDSF9TRkI9eQpDT05GSUdfTkVUX1NDSF9TRlE9eQpD
T05GSUdfTkVUX1NDSF9URVFMPXkKQ09ORklHX05FVF9TQ0hfVEJGPXkKQ09ORklHX05FVF9T
Q0hfR1JFRD15CkNPTkZJR19ORVRfU0NIX0RTTUFSSz15CkNPTkZJR19ORVRfU0NIX05FVEVN
PXkKQ09ORklHX05FVF9TQ0hfRFJSPXkKQ09ORklHX05FVF9TQ0hfTVFQUklPPXkKQ09ORklH
X05FVF9TQ0hfQ0hPS0U9eQpDT05GSUdfTkVUX1NDSF9RRlE9eQpDT05GSUdfTkVUX1NDSF9D
T0RFTD15CkNPTkZJR19ORVRfU0NIX0ZRX0NPREVMPXkKIyBDT05GSUdfTkVUX1NDSF9GUSBp
cyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfSEhGIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU
X1NDSF9QSUUgaXMgbm90IHNldApDT05GSUdfTkVUX1NDSF9JTkdSRVNTPXkKIyBDT05GSUdf
TkVUX1NDSF9QTFVHIGlzIG5vdCBzZXQKCiMKIyBDbGFzc2lmaWNhdGlvbgojCkNPTkZJR19O
RVRfQ0xTPXkKQ09ORklHX05FVF9DTFNfQkFTSUM9eQpDT05GSUdfTkVUX0NMU19UQ0lOREVY
PXkKQ09ORklHX05FVF9DTFNfUk9VVEU0PXkKQ09ORklHX05FVF9DTFNfRlc9eQpDT05GSUdf
TkVUX0NMU19VMzI9eQpDT05GSUdfQ0xTX1UzMl9QRVJGPXkKQ09ORklHX0NMU19VMzJfTUFS
Sz15CkNPTkZJR19ORVRfQ0xTX1JTVlA9eQpDT05GSUdfTkVUX0NMU19SU1ZQNj15CkNPTkZJ
R19ORVRfQ0xTX0ZMT1c9eQpDT05GSUdfTkVUX0NMU19DR1JPVVA9eQojIENPTkZJR19ORVRf
Q0xTX0JQRiBpcyBub3Qgc2V0CkNPTkZJR19ORVRfRU1BVENIPXkKQ09ORklHX05FVF9FTUFU
Q0hfU1RBQ0s9MzIKQ09ORklHX05FVF9FTUFUQ0hfQ01QPXkKQ09ORklHX05FVF9FTUFUQ0hf
TkJZVEU9eQpDT05GSUdfTkVUX0VNQVRDSF9VMzI9eQpDT05GSUdfTkVUX0VNQVRDSF9NRVRB
PXkKQ09ORklHX05FVF9FTUFUQ0hfVEVYVD15CiMgQ09ORklHX05FVF9FTUFUQ0hfSVBTRVQg
aXMgbm90IHNldApDT05GSUdfTkVUX0NMU19BQ1Q9eQpDT05GSUdfTkVUX0FDVF9QT0xJQ0U9
eQpDT05GSUdfTkVUX0FDVF9HQUNUPXkKQ09ORklHX0dBQ1RfUFJPQj15CkNPTkZJR19ORVRf
QUNUX01JUlJFRD15CkNPTkZJR19ORVRfQUNUX0lQVD1tCkNPTkZJR19ORVRfQUNUX05BVD15
CkNPTkZJR19ORVRfQUNUX1BFRElUPXkKQ09ORklHX05FVF9BQ1RfU0lNUD15CkNPTkZJR19O
RVRfQUNUX1NLQkVESVQ9eQpDT05GSUdfTkVUX0FDVF9DU1VNPXkKQ09ORklHX05FVF9DTFNf
SU5EPXkKQ09ORklHX05FVF9TQ0hfRklGTz15CkNPTkZJR19EQ0I9eQpDT05GSUdfRE5TX1JF
U09MVkVSPXkKIyBDT05GSUdfQkFUTUFOX0FEViBpcyBub3Qgc2V0CkNPTkZJR19PUEVOVlNX
SVRDSD15CiMgQ09ORklHX1ZTT0NLRVRTIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUTElOS19N
TUFQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUTElOS19ESUFHIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVUX01QTFNfR1NPIGlzIG5vdCBzZXQKIyBDT05GSUdfSFNSIGlzIG5vdCBzZXQKQ09O
RklHX1JQUz15CkNPTkZJR19SRlNfQUNDRUw9eQpDT05GSUdfWFBTPXkKIyBDT05GSUdfQ0dS
T1VQX05FVF9QUklPIGlzIG5vdCBzZXQKQ09ORklHX0NHUk9VUF9ORVRfQ0xBU1NJRD15CkNP
TkZJR19ORVRfUlhfQlVTWV9QT0xMPXkKQ09ORklHX0JRTD15CkNPTkZJR19CUEZfSklUPXkK
Q09ORklHX05FVF9GTE9XX0xJTUlUPXkKCiMKIyBOZXR3b3JrIHRlc3RpbmcKIwojIENPTkZJ
R19ORVRfUEtUR0VOIGlzIG5vdCBzZXQKIyBDT05GSUdfSEFNUkFESU8gaXMgbm90IHNldAoj
IENPTkZJR19DQU4gaXMgbm90IHNldAojIENPTkZJR19JUkRBIGlzIG5vdCBzZXQKIyBDT05G
SUdfQlQgaXMgbm90IHNldApDT05GSUdfQUZfUlhSUEM9eQojIENPTkZJR19BRl9SWFJQQ19E
RUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1JYS0FEIGlzIG5vdCBzZXQKQ09ORklHX0ZJQl9S
VUxFUz15CkNPTkZJR19XSVJFTEVTUz15CkNPTkZJR19XRVhUX0NPUkU9eQpDT05GSUdfV0VY
VF9QUk9DPXkKQ09ORklHX0NGRzgwMjExPXkKIyBDT05GSUdfTkw4MDIxMV9URVNUTU9ERSBp
cyBub3Qgc2V0CiMgQ09ORklHX0NGRzgwMjExX0RFVkVMT1BFUl9XQVJOSU5HUyBpcyBub3Qg
c2V0CiMgQ09ORklHX0NGRzgwMjExX1JFR19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0NG
RzgwMjExX0RFRkFVTFRfUFMgaXMgbm90IHNldAojIENPTkZJR19DRkc4MDIxMV9JTlRFUk5B
TF9SRUdEQiBpcyBub3Qgc2V0CkNPTkZJR19DRkc4MDIxMV9XRVhUPXkKIyBDT05GSUdfTElC
ODAyMTEgaXMgbm90IHNldApDT05GSUdfTUFDODAyMTE9eQpDT05GSUdfTUFDODAyMTFfSEFT
X1JDPXkKQ09ORklHX01BQzgwMjExX1JDX01JTlNUUkVMPXkKQ09ORklHX01BQzgwMjExX1JD
X01JTlNUUkVMX0hUPXkKQ09ORklHX01BQzgwMjExX1JDX0RFRkFVTFRfTUlOU1RSRUw9eQpD
T05GSUdfTUFDODAyMTFfUkNfREVGQVVMVD0ibWluc3RyZWxfaHQiCiMgQ09ORklHX01BQzgw
MjExX01FU0ggaXMgbm90IHNldApDT05GSUdfTUFDODAyMTFfTEVEUz15CiMgQ09ORklHX01B
QzgwMjExX01FU1NBR0VfVFJBQ0lORyBpcyBub3Qgc2V0CiMgQ09ORklHX01BQzgwMjExX0RF
QlVHX01FTlUgaXMgbm90IHNldAojIENPTkZJR19XSU1BWCBpcyBub3Qgc2V0CkNPTkZJR19S
RktJTEw9eQpDT05GSUdfUkZLSUxMX0xFRFM9eQpDT05GSUdfUkZLSUxMX0lOUFVUPXkKIyBD
T05GSUdfUkZLSUxMX0dQSU8gaXMgbm90IHNldAojIENPTkZJR19ORVRfOVAgaXMgbm90IHNl
dAojIENPTkZJR19DQUlGIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0VQSF9MSUIgaXMgbm90IHNl
dAojIENPTkZJR19ORkMgaXMgbm90IHNldApDT05GSUdfSEFWRV9CUEZfSklUPXkKCiMKIyBE
ZXZpY2UgRHJpdmVycwojCgojCiMgR2VuZXJpYyBEcml2ZXIgT3B0aW9ucwojCkNPTkZJR19V
RVZFTlRfSEVMUEVSPXkKQ09ORklHX1VFVkVOVF9IRUxQRVJfUEFUSD0iIgpDT05GSUdfREVW
VE1QRlM9eQpDT05GSUdfREVWVE1QRlNfTU9VTlQ9eQojIENPTkZJR19TVEFOREFMT05FIGlz
IG5vdCBzZXQKIyBDT05GSUdfUFJFVkVOVF9GSVJNV0FSRV9CVUlMRCBpcyBub3Qgc2V0CkNP
TkZJR19GV19MT0FERVI9eQpDT05GSUdfRklSTVdBUkVfSU5fS0VSTkVMPXkKQ09ORklHX0VY
VFJBX0ZJUk1XQVJFPSIiCkNPTkZJR19GV19MT0FERVJfVVNFUl9IRUxQRVI9eQojIENPTkZJ
R19ERUJVR19EUklWRVIgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19ERVZSRVMgaXMgbm90
IHNldApDT05GSUdfU1lTX0hZUEVSVklTT1I9eQojIENPTkZJR19HRU5FUklDX0NQVV9ERVZJ
Q0VTIGlzIG5vdCBzZXQKQ09ORklHX0dFTkVSSUNfQ1BVX0FVVE9QUk9CRT15CkNPTkZJR19S
RUdNQVA9eQpDT05GSUdfUkVHTUFQX0kyQz1tCkNPTkZJR19ETUFfU0hBUkVEX0JVRkZFUj15
CgojCiMgQnVzIGRldmljZXMKIwpDT05GSUdfQ09OTkVDVE9SPXkKQ09ORklHX1BST0NfRVZF
TlRTPXkKIyBDT05GSUdfTVREIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFSUE9SVCBpcyBub3Qg
c2V0CkNPTkZJR19BUkNIX01JR0hUX0hBVkVfUENfUEFSUE9SVD15CkNPTkZJR19QTlA9eQoj
IENPTkZJR19QTlBfREVCVUdfTUVTU0FHRVMgaXMgbm90IHNldAoKIwojIFByb3RvY29scwoj
CkNPTkZJR19QTlBBQ1BJPXkKQ09ORklHX0JMS19ERVY9eQojIENPTkZJR19CTEtfREVWX05V
TExfQkxLIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9GRCBpcyBub3Qgc2V0CiMgQ09O
RklHX0JMS19ERVZfUENJRVNTRF9NVElQMzJYWCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19D
UFFfQ0lTU19EQSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfREFDOTYwIGlzIG5vdCBz
ZXQKIyBDT05GSUdfQkxLX0RFVl9VTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9D
T1dfQ09NTU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfTE9PUD15CkNPTkZJR19CTEtf
REVWX0xPT1BfTUlOX0NPVU5UPTgKIyBDT05GSUdfQkxLX0RFVl9DUllQVE9MT09QIGlzIG5v
dCBzZXQKQ09ORklHX0JMS19ERVZfRFJCRD15CiMgQ09ORklHX0RSQkRfRkFVTFRfSU5KRUNU
SU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfTkJEPXkKIyBDT05GSUdfQkxLX0RFVl9O
Vk1FIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9TS0QgaXMgbm90IHNldAojIENPTkZJ
R19CTEtfREVWX1NYOCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX1JBTT15CkNPTkZJR19C
TEtfREVWX1JBTV9DT1VOVD0xNgpDT05GSUdfQkxLX0RFVl9SQU1fU0laRT02NTUzNgojIENP
TkZJR19CTEtfREVWX1hJUCBpcyBub3Qgc2V0CiMgQ09ORklHX0NEUk9NX1BLVENEVkQgaXMg
bm90IHNldAojIENPTkZJR19BVEFfT1ZFUl9FVEggaXMgbm90IHNldApDT05GSUdfWEVOX0JM
S0RFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fQkxLREVWX0JBQ0tFTkQ9eQpDT05GSUdfVklS
VElPX0JMSz1tCiMgQ09ORklHX0JMS19ERVZfSEQgaXMgbm90IHNldAojIENPTkZJR19CTEtf
REVWX1JCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfUlNYWCBpcyBub3Qgc2V0Cgoj
CiMgTWlzYyBkZXZpY2VzCiMKIyBDT05GSUdfU0VOU09SU19MSVMzTFYwMkQgaXMgbm90IHNl
dAojIENPTkZJR19BRDUyNVhfRFBPVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RVTU1ZX0lSUSBp
cyBub3Qgc2V0CiMgQ09ORklHX0lCTV9BU00gaXMgbm90IHNldAojIENPTkZJR19QSEFOVE9N
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0dJX0lPQzQgaXMgbm90IHNldAojIENPTkZJR19USUZN
X0NPUkUgaXMgbm90IHNldAojIENPTkZJR19JQ1M5MzJTNDAxIGlzIG5vdCBzZXQKIyBDT05G
SUdfRU5DTE9TVVJFX1NFUlZJQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfSFBfSUxPIGlzIG5v
dCBzZXQKIyBDT05GSUdfQVBEUzk4MDJBTFMgaXMgbm90IHNldAojIENPTkZJR19JU0wyOTAw
MyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTTDI5MDIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19UU0wyNTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19CSDE3ODAgaXMgbm90
IHNldAojIENPTkZJR19TRU5TT1JTX0JIMTc3MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNP
UlNfQVBEUzk5MFggaXMgbm90IHNldAojIENPTkZJR19ITUM2MzUyIGlzIG5vdCBzZXQKIyBD
T05GSUdfRFMxNjgyIGlzIG5vdCBzZXQKIyBDT05GSUdfVk1XQVJFX0JBTExPT04gaXMgbm90
IHNldAojIENPTkZJR19CTVAwODVfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NXSVRD
SF9GU0E5NDgwIGlzIG5vdCBzZXQKIyBDT05GSUdfU1JBTSBpcyBub3Qgc2V0CiMgQ09ORklH
X0MyUE9SVCBpcyBub3Qgc2V0CgojCiMgRUVQUk9NIHN1cHBvcnQKIwpDT05GSUdfRUVQUk9N
X0FUMjQ9bQpDT05GSUdfRUVQUk9NX0xFR0FDWT1tCkNPTkZJR19FRVBST01fTUFYNjg3NT1t
CkNPTkZJR19FRVBST01fOTNDWDY9bQojIENPTkZJR19DQjcxMF9DT1JFIGlzIG5vdCBzZXQK
CiMKIyBUZXhhcyBJbnN0cnVtZW50cyBzaGFyZWQgdHJhbnNwb3J0IGxpbmUgZGlzY2lwbGlu
ZQojCiMgQ09ORklHX1RJX1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MSVMzX0ky
QyBpcyBub3Qgc2V0CgojCiMgQWx0ZXJhIEZQR0EgZmlybXdhcmUgZG93bmxvYWQgbW9kdWxl
CiMKIyBDT05GSUdfQUxURVJBX1NUQVBMIGlzIG5vdCBzZXQKQ09ORklHX0lOVEVMX01FST15
CkNPTkZJR19JTlRFTF9NRUlfTUU9eQojIENPTkZJR19JTlRFTF9NRUlfVFhFIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVk1XQVJFX1ZNQ0kgaXMgbm90IHNldAoKIwojIEludGVsIE1JQyBIb3N0
IERyaXZlcgojCiMgQ09ORklHX0lOVEVMX01JQ19IT1NUIGlzIG5vdCBzZXQKCiMKIyBJbnRl
bCBNSUMgQ2FyZCBEcml2ZXIKIwojIENPTkZJR19JTlRFTF9NSUNfQ0FSRCBpcyBub3Qgc2V0
CiMgQ09ORklHX0dFTldRRSBpcyBub3Qgc2V0CiMgQ09ORklHX0VDSE8gaXMgbm90IHNldApD
T05GSUdfSEFWRV9JREU9eQojIENPTkZJR19JREUgaXMgbm90IHNldAoKIwojIFNDU0kgZGV2
aWNlIHN1cHBvcnQKIwpDT05GSUdfU0NTSV9NT0Q9eQojIENPTkZJR19SQUlEX0FUVFJTIGlz
IG5vdCBzZXQKQ09ORklHX1NDU0k9eQpDT05GSUdfU0NTSV9ETUE9eQojIENPTkZJR19TQ1NJ
X1RHVCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX05FVExJTks9eQojIENPTkZJR19TQ1NJX1BS
T0NfRlMgaXMgbm90IHNldAoKIwojIFNDU0kgc3VwcG9ydCB0eXBlIChkaXNrLCB0YXBlLCBD
RC1ST00pCiMKQ09ORklHX0JMS19ERVZfU0Q9eQojIENPTkZJR19DSFJfREVWX1NUIGlzIG5v
dCBzZXQKIyBDT05GSUdfQ0hSX0RFVl9PU1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RF
Vl9TUiBpcyBub3Qgc2V0CkNPTkZJR19DSFJfREVWX1NHPXkKIyBDT05GSUdfQ0hSX0RFVl9T
Q0ggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX01VTFRJX0xVTiBpcyBub3Qgc2V0CiMgQ09O
RklHX1NDU0lfQ09OU1RBTlRTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9MT0dHSU5HIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TQ0FOX0FTWU5DIGlzIG5vdCBzZXQKCiMKIyBTQ1NJ
IFRyYW5zcG9ydHMKIwpDT05GSUdfU0NTSV9TUElfQVRUUlM9eQpDT05GSUdfU0NTSV9GQ19B
VFRSUz15CkNPTkZJR19TQ1NJX0lTQ1NJX0FUVFJTPXkKQ09ORklHX1NDU0lfU0FTX0FUVFJT
PXkKQ09ORklHX1NDU0lfU0FTX0xJQlNBUz15CkNPTkZJR19TQ1NJX1NBU19BVEE9eQpDT05G
SUdfU0NTSV9TQVNfSE9TVF9TTVA9eQpDT05GSUdfU0NTSV9TUlBfQVRUUlM9eQpDT05GSUdf
U0NTSV9MT1dMRVZFTD15CiMgQ09ORklHX0lTQ1NJX1RDUCBpcyBub3Qgc2V0CiMgQ09ORklH
X0lTQ1NJX0JPT1RfU1lTRlMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0NYR0IzX0lTQ1NJ
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9DWEdCNF9JU0NTSSBpcyBub3Qgc2V0CiMgQ09O
RklHX1NDU0lfQk5YMl9JU0NTSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQk5YMlhfRkNP
RSBpcyBub3Qgc2V0CiMgQ09ORklHX0JFMklTQ1NJIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxL
X0RFVl8zV19YWFhYX1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0hQU0EgaXMgbm90
IHNldAojIENPTkZJR19TQ1NJXzNXXzlYWFggaXMgbm90IHNldAojIENPTkZJR19TQ1NJXzNX
X1NBUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQUNBUkQgaXMgbm90IHNldAojIENPTkZJ
R19TQ1NJX0FBQ1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FJQzdYWFggaXMgbm90
IHNldAojIENPTkZJR19TQ1NJX0FJQzc5WFggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FJ
Qzk0WFggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX01WU0FTIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0NTSV9NVlVNSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfRFBUX0kyTyBpcyBub3Qg
c2V0CiMgQ09ORklHX1NDU0lfQURWQU5TWVMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FS
Q01TUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfRVNBUzJSIGlzIG5vdCBzZXQKIyBDT05G
SUdfTUVHQVJBSURfTkVXR0VOIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVHQVJBSURfTEVHQUNZ
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUVHQVJBSURfU0FTIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0NTSV9NUFQyU0FTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9NUFQzU0FTIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0NTSV9VRlNIQ0QgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0hQVElP
UCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQlVTTE9HSUMgaXMgbm90IHNldAojIENPTkZJ
R19WTVdBUkVfUFZTQ1NJIGlzIG5vdCBzZXQKQ09ORklHX0hZUEVSVl9TVE9SQUdFPXkKIyBD
T05GSUdfTElCRkMgaXMgbm90IHNldAojIENPTkZJR19MSUJGQ09FIGlzIG5vdCBzZXQKIyBD
T05GSUdfRkNPRSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZDT0VfRk5JQyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NDU0lfRE1YMzE5MUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0VBVEEgaXMg
bm90IHNldAojIENPTkZJR19TQ1NJX0ZVVFVSRV9ET01BSU4gaXMgbm90IHNldAojIENPTkZJ
R19TQ1NJX0dEVEggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0lTQ0kgaXMgbm90IHNldAoj
IENPTkZJR19TQ1NJX0lQUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSU5JVElPIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0NTSV9JTklBMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9T
VEVYIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TWU01M0M4WFhfMiBpcyBub3Qgc2V0CiMg
Q09ORklHX1NDU0lfSVBSIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9RTE9HSUNfMTI4MCBp
cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUUxBX0ZDIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NT
SV9RTEFfSVNDU0kgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0xQRkMgaXMgbm90IHNldAoj
IENPTkZJR19TQ1NJX0RDMzk1eCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREMzOTBUIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0NTSV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lf
UE1DUkFJRCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUE04MDAxIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0NTSV9TUlAgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0JGQV9GQyBpcyBub3Qg
c2V0CiMgQ09ORklHX1NDU0lfVklSVElPIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9DSEVM
U0lPX0ZDT0UgaXMgbm90IHNldApDT05GSUdfU0NTSV9ESD15CiMgQ09ORklHX1NDU0lfREhf
UkRBQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREhfSFBfU1cgaXMgbm90IHNldAojIENP
TkZJR19TQ1NJX0RIX0VNQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREhfQUxVQSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NDU0lfT1NEX0lOSVRJQVRPUiBpcyBub3Qgc2V0CkNPTkZJR19B
VEE9eQojIENPTkZJR19BVEFfTk9OU1RBTkRBUkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZF
UkJPU0VfRVJST1I9eQpDT05GSUdfQVRBX0FDUEk9eQojIENPTkZJR19TQVRBX1pQT0REIGlz
IG5vdCBzZXQKQ09ORklHX1NBVEFfUE1QPXkKCiMKIyBDb250cm9sbGVycyB3aXRoIG5vbi1T
RkYgbmF0aXZlIGludGVyZmFjZQojCkNPTkZJR19TQVRBX0FIQ0k9eQpDT05GSUdfU0FUQV9B
SENJX1BMQVRGT1JNPXkKIyBDT05GSUdfU0FUQV9JTklDMTYyWCBpcyBub3Qgc2V0CiMgQ09O
RklHX1NBVEFfQUNBUkRfQUhDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfU0lMMjQgaXMg
bm90IHNldApDT05GSUdfQVRBX1NGRj15CgojCiMgU0ZGIGNvbnRyb2xsZXJzIHdpdGggY3Vz
dG9tIERNQSBpbnRlcmZhY2UKIwojIENPTkZJR19QRENfQURNQSBpcyBub3Qgc2V0CiMgQ09O
RklHX1NBVEFfUVNUT1IgaXMgbm90IHNldAojIENPTkZJR19TQVRBX1NYNCBpcyBub3Qgc2V0
CkNPTkZJR19BVEFfQk1ETUE9eQoKIwojIFNBVEEgU0ZGIGNvbnRyb2xsZXJzIHdpdGggQk1E
TUEKIwpDT05GSUdfQVRBX1BJSVg9eQojIENPTkZJR19TQVRBX01WIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0FUQV9OViBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfUFJPTUlTRSBpcyBub3Qg
c2V0CiMgQ09ORklHX1NBVEFfU0lMIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9TSVMgaXMg
bm90IHNldAojIENPTkZJR19TQVRBX1NWVyBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfVUxJ
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9WSUEgaXMgbm90IHNldAojIENPTkZJR19TQVRB
X1ZJVEVTU0UgaXMgbm90IHNldAoKIwojIFBBVEEgU0ZGIGNvbnRyb2xsZXJzIHdpdGggQk1E
TUEKIwojIENPTkZJR19QQVRBX0FMSSBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfQU1EIGlz
IG5vdCBzZXQKIyBDT05GSUdfUEFUQV9BUlRPUCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFf
QVRJSVhQIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9BVFA4NjdYIGlzIG5vdCBzZXQKIyBD
T05GSUdfUEFUQV9DTUQ2NFggaXMgbm90IHNldAojIENPTkZJR19QQVRBX0NZUFJFU1MgaXMg
bm90IHNldAojIENPTkZJR19QQVRBX0VGQVIgaXMgbm90IHNldAojIENPTkZJR19QQVRBX0hQ
VDM2NiBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfSFBUMzdYIGlzIG5vdCBzZXQKIyBDT05G
SUdfUEFUQV9IUFQzWDJOIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9IUFQzWDMgaXMgbm90
IHNldAojIENPTkZJR19QQVRBX0lUODIxMyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfSVQ4
MjFYIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9KTUlDUk9OIGlzIG5vdCBzZXQKIyBDT05G
SUdfUEFUQV9NQVJWRUxMIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9ORVRDRUxMIGlzIG5v
dCBzZXQKIyBDT05GSUdfUEFUQV9OSU5KQTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9O
Uzg3NDE1IGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9PTERQSUlYIGlzIG5vdCBzZXQKIyBD
T05GSUdfUEFUQV9PUFRJRE1BIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9QREMyMDI3WCBp
cyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfUERDX09MRCBpcyBub3Qgc2V0CiMgQ09ORklHX1BB
VEFfUkFESVNZUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfUkRDIGlzIG5vdCBzZXQKIyBD
T05GSUdfUEFUQV9TQ0ggaXMgbm90IHNldAojIENPTkZJR19QQVRBX1NFUlZFUldPUktTIGlz
IG5vdCBzZXQKIyBDT05GSUdfUEFUQV9TSUw2ODAgaXMgbm90IHNldAojIENPTkZJR19QQVRB
X1NJUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfVE9TSElCQSBpcyBub3Qgc2V0CiMgQ09O
RklHX1BBVEFfVFJJRkxFWCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfVklBIGlzIG5vdCBz
ZXQKIyBDT05GSUdfUEFUQV9XSU5CT05EIGlzIG5vdCBzZXQKCiMKIyBQSU8tb25seSBTRkYg
Y29udHJvbGxlcnMKIwojIENPTkZJR19QQVRBX0NNRDY0MF9QQ0kgaXMgbm90IHNldAojIENP
TkZJR19QQVRBX01QSUlYIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9OUzg3NDEwIGlzIG5v
dCBzZXQKIyBDT05GSUdfUEFUQV9PUFRJIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9SWjEw
MDAgaXMgbm90IHNldAoKIwojIEdlbmVyaWMgZmFsbGJhY2sgLyBsZWdhY3kgZHJpdmVycwoj
CiMgQ09ORklHX1BBVEFfQUNQSSBpcyBub3Qgc2V0CkNPTkZJR19BVEFfR0VORVJJQz15CiMg
Q09ORklHX1BBVEFfTEVHQUNZIGlzIG5vdCBzZXQKQ09ORklHX01EPXkKIyBDT05GSUdfQkxL
X0RFVl9NRCBpcyBub3Qgc2V0CiMgQ09ORklHX0JDQUNIRSBpcyBub3Qgc2V0CkNPTkZJR19C
TEtfREVWX0RNX0JVSUxUSU49eQpDT05GSUdfQkxLX0RFVl9ETT15CiMgQ09ORklHX0RNX0RF
QlVHIGlzIG5vdCBzZXQKQ09ORklHX0RNX0JVRklPPXkKQ09ORklHX0RNX0NSWVBUPXkKQ09O
RklHX0RNX1NOQVBTSE9UPXkKIyBDT05GSUdfRE1fVEhJTl9QUk9WSVNJT05JTkcgaXMgbm90
IHNldAojIENPTkZJR19ETV9DQUNIRSBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0VSQSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0RNX01JUlJPUiBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX1JBSUQg
aXMgbm90IHNldAojIENPTkZJR19ETV9aRVJPIGlzIG5vdCBzZXQKQ09ORklHX0RNX01VTFRJ
UEFUSD15CiMgQ09ORklHX0RNX01VTFRJUEFUSF9RTCBpcyBub3Qgc2V0CiMgQ09ORklHX0RN
X01VTFRJUEFUSF9TVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0RFTEFZIGlzIG5vdCBzZXQK
Q09ORklHX0RNX1VFVkVOVD15CiMgQ09ORklHX0RNX0ZMQUtFWSBpcyBub3Qgc2V0CiMgQ09O
RklHX0RNX1ZFUklUWSBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX1NXSVRDSCBpcyBub3Qgc2V0
CiMgQ09ORklHX1RBUkdFVF9DT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfRlVTSU9OIGlzIG5v
dCBzZXQKCiMKIyBJRUVFIDEzOTQgKEZpcmVXaXJlKSBzdXBwb3J0CiMKIyBDT05GSUdfRklS
RVdJUkUgaXMgbm90IHNldAojIENPTkZJR19GSVJFV0lSRV9OT1NZIGlzIG5vdCBzZXQKIyBD
T05GSUdfSTJPIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFDSU5UT1NIX0RSSVZFUlMgaXMgbm90
IHNldApDT05GSUdfTkVUREVWSUNFUz15CkNPTkZJR19NSUk9eQpDT05GSUdfTkVUX0NPUkU9
eQpDT05GSUdfQk9ORElORz15CkNPTkZJR19EVU1NWT15CkNPTkZJR19FUVVBTElaRVI9eQpD
T05GSUdfTkVUX0ZDPXkKQ09ORklHX0lGQj15CiMgQ09ORklHX05FVF9URUFNIGlzIG5vdCBz
ZXQKQ09ORklHX01BQ1ZMQU49eQpDT05GSUdfTUFDVlRBUD15CiMgQ09ORklHX1ZYTEFOIGlz
IG5vdCBzZXQKQ09ORklHX05FVENPTlNPTEU9eQpDT05GSUdfTkVUUE9MTD15CkNPTkZJR19O
RVRfUE9MTF9DT05UUk9MTEVSPXkKQ09ORklHX1RVTj15CkNPTkZJR19WRVRIPXkKIyBDT05G
SUdfVklSVElPX05FVCBpcyBub3Qgc2V0CiMgQ09ORklHX05MTU9OIGlzIG5vdCBzZXQKIyBD
T05GSUdfQVJDTkVUIGlzIG5vdCBzZXQKCiMKIyBDQUlGIHRyYW5zcG9ydCBkcml2ZXJzCiMK
CiMKIyBEaXN0cmlidXRlZCBTd2l0Y2ggQXJjaGl0ZWN0dXJlIGRyaXZlcnMKIwojIENPTkZJ
R19ORVRfRFNBX01WODhFNlhYWCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9EU0FfTVY4OEU2
MDYwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0RTQV9NVjg4RTZYWFhfTkVFRF9QUFUgaXMg
bm90IHNldAojIENPTkZJR19ORVRfRFNBX01WODhFNjEzMSBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9EU0FfTVY4OEU2MTIzXzYxXzY1IGlzIG5vdCBzZXQKQ09ORklHX0VUSEVSTkVUPXkK
Q09ORklHX01ESU89eQojIENPTkZJR19ORVRfVkVORE9SXzNDT00gaXMgbm90IHNldAojIENP
TkZJR19ORVRfVkVORE9SX0FEQVBURUMgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9S
X0FMVEVPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0FMVEVSQV9UU0UgaXMgbm90IHNldAojIENP
TkZJR19ORVRfVkVORE9SX0FNRCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfQVJD
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9BVEhFUk9TIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkVUX1ZFTkRPUl9CUk9BRENPTSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5E
T1JfQlJPQ0FERSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9DQUxYRURBX1hHTUFDIGlzIG5v
dCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9DSEVMU0lPIGlzIG5vdCBzZXQKIyBDT05GSUdf
TkVUX1ZFTkRPUl9DSVNDTyBpcyBub3Qgc2V0CiMgQ09ORklHX0NYX0VDQVQgaXMgbm90IHNl
dAojIENPTkZJR19ETkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9ERUMgaXMg
bm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX0RMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdf
TkVUX1ZFTkRPUl9FTVVMRVggaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX0VYQVIg
aXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX0hQIGlzIG5vdCBzZXQKQ09ORklHX05F
VF9WRU5ET1JfSU5URUw9eQpDT05GSUdfRTEwMD15CkNPTkZJR19FMTAwMD15CkNPTkZJR19F
MTAwMEU9eQpDT05GSUdfSUdCPXkKQ09ORklHX0lHQl9IV01PTj15CkNPTkZJR19JR0JfRENB
PXkKQ09ORklHX0lHQlZGPXkKQ09ORklHX0lYR0I9eQpDT05GSUdfSVhHQkU9eQpDT05GSUdf
SVhHQkVfSFdNT049eQpDT05GSUdfSVhHQkVfRENBPXkKQ09ORklHX0lYR0JFX0RDQj15CkNP
TkZJR19JWEdCRVZGPXkKIyBDT05GSUdfSTQwRSBpcyBub3Qgc2V0CiMgQ09ORklHX0k0MEVW
RiBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX0k4MjVYWD15CiMgQ09ORklHX0lQMTAw
MCBpcyBub3Qgc2V0CiMgQ09ORklHX0pNRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5E
T1JfTUFSVkVMTCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX01FTExBTk9YPXkKIyBD
T05GSUdfTUxYNF9FTiBpcyBub3Qgc2V0CiMgQ09ORklHX01MWDRfQ09SRSBpcyBub3Qgc2V0
CiMgQ09ORklHX01MWDVfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfTUlD
UkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9NWVJJIGlzIG5vdCBzZXQKIyBD
T05GSUdfRkVBTE5YIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9OQVRTRU1JIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9OVklESUEgaXMgbm90IHNldAojIENPTkZJ
R19ORVRfVkVORE9SX09LSSBpcyBub3Qgc2V0CiMgQ09ORklHX0VUSE9DIGlzIG5vdCBzZXQK
IyBDT05GSUdfTkVUX1BBQ0tFVF9FTkdJTkUgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVO
RE9SX1FMT0dJQyBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1JFQUxURUs9eQpDT05G
SUdfODEzOUNQPXkKQ09ORklHXzgxMzlUT089eQojIENPTkZJR184MTM5VE9PX1BJTyBpcyBu
b3Qgc2V0CkNPTkZJR184MTM5VE9PX1RVTkVfVFdJU1RFUj15CkNPTkZJR184MTM5VE9PXzgx
Mjk9eQojIENPTkZJR184MTM5X09MRF9SWF9SRVNFVCBpcyBub3Qgc2V0CkNPTkZJR19SODE2
OT15CiMgQ09ORklHX1NIX0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfUkRD
IGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfU0FNU1VORz15CiMgQ09ORklHX1NYR0JF
X0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfU0VFUSBpcyBub3Qgc2V0CiMg
Q09ORklHX05FVF9WRU5ET1JfU0lMQU4gaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9S
X1NJUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NGQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9W
RU5ET1JfU01TQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfU1RNSUNSTyBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfU1VOIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU
X1ZFTkRPUl9URUhVVEkgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX1RJIGlzIG5v
dCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9WSUEgaXMgbm90IHNldAojIENPTkZJR19ORVRf
VkVORE9SX1dJWk5FVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZEREkgaXMgbm90IHNldAojIENP
TkZJR19ISVBQSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQjEwMDAgaXMgbm90IHNldApD
T05GSUdfUEhZTElCPXkKCiMKIyBNSUkgUEhZIGRldmljZSBkcml2ZXJzCiMKQ09ORklHX0FU
ODAzWF9QSFk9eQpDT05GSUdfQU1EX1BIWT15CkNPTkZJR19NQVJWRUxMX1BIWT15CkNPTkZJ
R19EQVZJQ09NX1BIWT15CkNPTkZJR19RU0VNSV9QSFk9eQpDT05GSUdfTFhUX1BIWT15CkNP
TkZJR19DSUNBREFfUEhZPXkKQ09ORklHX1ZJVEVTU0VfUEhZPXkKQ09ORklHX1NNU0NfUEhZ
PXkKQ09ORklHX0JST0FEQ09NX1BIWT15CiMgQ09ORklHX0JDTTdYWFhfUEhZIGlzIG5vdCBz
ZXQKQ09ORklHX0JDTTg3WFhfUEhZPXkKQ09ORklHX0lDUExVU19QSFk9eQpDT05GSUdfUkVB
TFRFS19QSFk9eQpDT05GSUdfTkFUSU9OQUxfUEhZPXkKQ09ORklHX1NURTEwWFA9eQpDT05G
SUdfTFNJX0VUMTAxMUNfUEhZPXkKQ09ORklHX01JQ1JFTF9QSFk9eQpDT05GSUdfRklYRURf
UEhZPXkKQ09ORklHX01ESU9fQklUQkFORz15CkNPTkZJR19NRElPX0dQSU89eQojIENPTkZJ
R19QUFAgaXMgbm90IHNldAojIENPTkZJR19TTElQIGlzIG5vdCBzZXQKCiMKIyBVU0IgTmV0
d29yayBBZGFwdGVycwojCiMgQ09ORklHX1VTQl9DQVRDIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX0tBV0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QRUdBU1VTIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX1JUTDgxNTAgaXMgbm90IHNldAojIENPTkZJR19VU0JfUlRMODE1MiBp
cyBub3Qgc2V0CkNPTkZJR19VU0JfVVNCTkVUPXkKQ09ORklHX1VTQl9ORVRfQVg4ODE3WD15
CkNPTkZJR19VU0JfTkVUX0FYODgxNzlfMTc4QT15CiMgQ09ORklHX1VTQl9ORVRfQ0RDRVRI
RVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX0NEQ19FRU0gaXMgbm90IHNldAojIENP
TkZJR19VU0JfTkVUX0NEQ19OQ00gaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX0hVQVdF
SV9DRENfTkNNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9DRENfTUJJTSBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9ORVRfRE05NjAxIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05F
VF9TUjk3MDAgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX1NSOTgwMCBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9ORVRfU01TQzc1WFggaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVU
X1NNU0M5NVhYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9HTDYyMEEgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfTkVUX05FVDEwODAgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVU
X1BMVVNCIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9NQ1M3ODMwIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX05FVF9STkRJU19IT1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05F
VF9DRENfU1VCU0VUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9aQVVSVVMgaXMgbm90
IHNldAojIENPTkZJR19VU0JfTkVUX0NYODIzMTBfRVRIIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX05FVF9LQUxNSUEgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX1FNSV9XV0FOIGlz
IG5vdCBzZXQKIyBDT05GSUdfVVNCX0hTTyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ORVRf
SU5UNTFYMSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JUEhFVEggaXMgbm90IHNldAojIENP
TkZJR19VU0JfU0lFUlJBX05FVCBpcyBub3Qgc2V0CkNPTkZJR19XTEFOPXkKIyBDT05GSUdf
TElCRVJUQVNfVEhJTkZJUk0gaXMgbm90IHNldAojIENPTkZJR19BSVJPIGlzIG5vdCBzZXQK
IyBDT05GSUdfQVRNRUwgaXMgbm90IHNldAojIENPTkZJR19BVDc2QzUwWF9VU0IgaXMgbm90
IHNldAojIENPTkZJR19QUklTTTU0IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1pEMTIwMSBp
cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ORVRfUk5ESVNfV0xBTiBpcyBub3Qgc2V0CiMgQ09O
RklHX1JUTDgxODAgaXMgbm90IHNldAojIENPTkZJR19SVEw4MTg3IGlzIG5vdCBzZXQKIyBD
T05GSUdfQURNODIxMSBpcyBub3Qgc2V0CiMgQ09ORklHX01BQzgwMjExX0hXU0lNIGlzIG5v
dCBzZXQKIyBDT05GSUdfTVdMOEsgaXMgbm90IHNldApDT05GSUdfQVRIX0NPTU1PTj15CkNP
TkZJR19BVEhfQ0FSRFM9eQojIENPTkZJR19BVEhfREVCVUcgaXMgbm90IHNldApDT05GSUdf
QVRINUs9eQojIENPTkZJR19BVEg1S19ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19BVEg1S19Q
Q0k9eQpDT05GSUdfQVRIOUtfSFc9eQpDT05GSUdfQVRIOUtfQ09NTU9OPXkKIyBDT05GSUdf
QVRIOUtfQlRDT0VYX1NVUFBPUlQgaXMgbm90IHNldApDT05GSUdfQVRIOUs9eQpDT05GSUdf
QVRIOUtfUENJPXkKIyBDT05GSUdfQVRIOUtfQUhCIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRI
OUtfV09XIGlzIG5vdCBzZXQKQ09ORklHX0FUSDlLX1JGS0lMTD15CiMgQ09ORklHX0FUSDlL
X0hUQyBpcyBub3Qgc2V0CkNPTkZJR19DQVJMOTE3MD15CkNPTkZJR19DQVJMOTE3MF9MRURT
PXkKQ09ORklHX0NBUkw5MTcwX1dQQz15CiMgQ09ORklHX0NBUkw5MTcwX0hXUk5HIGlzIG5v
dCBzZXQKQ09ORklHX0FUSDZLTD15CiMgQ09ORklHX0FUSDZLTF9VU0IgaXMgbm90IHNldAoj
IENPTkZJR19BVEg2S0xfREVCVUcgaXMgbm90IHNldApDT05GSUdfQVI1NTIzPXkKIyBDT05G
SUdfV0lMNjIxMCBpcyBub3Qgc2V0CkNPTkZJR19BVEgxMEs9eQpDT05GSUdfQVRIMTBLX1BD
ST15CiMgQ09ORklHX0FUSDEwS19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0FUSDEwS19E
RUJVR0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfV0NOMzZYWCBpcyBub3Qgc2V0CiMgQ09ORklH
X0I0MyBpcyBub3Qgc2V0CiMgQ09ORklHX0I0M0xFR0FDWSBpcyBub3Qgc2V0CiMgQ09ORklH
X0JSQ01TTUFDIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJDTUZNQUMgaXMgbm90IHNldAojIENP
TkZJR19IT1NUQVAgaXMgbm90IHNldAojIENPTkZJR19JUFcyMTAwIGlzIG5vdCBzZXQKIyBD
T05GSUdfSVBXMjIwMCBpcyBub3Qgc2V0CkNPTkZJR19JV0xXSUZJPXkKQ09ORklHX0lXTFdJ
RklfTEVEUz15CkNPTkZJR19JV0xEVk09bQpDT05GSUdfSVdMTVZNPW0KQ09ORklHX0lXTFdJ
RklfT1BNT0RFX01PRFVMQVI9eQojIENPTkZJR19JV0xXSUZJX0JDQVNUX0ZJTFRFUklORyBp
cyBub3Qgc2V0CgojCiMgRGVidWdnaW5nIE9wdGlvbnMKIwojIENPTkZJR19JV0xXSUZJX0RF
QlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfSVdMNDk2NSBpcyBub3Qgc2V0CiMgQ09ORklHX0lX
TDM5NDUgaXMgbm90IHNldAojIENPTkZJR19MSUJFUlRBUyBpcyBub3Qgc2V0CiMgQ09ORklH
X0hFUk1FUyBpcyBub3Qgc2V0CiMgQ09ORklHX1A1NF9DT01NT04gaXMgbm90IHNldAojIENP
TkZJR19SVDJYMDAgaXMgbm90IHNldAojIENPTkZJR19SVExfQ0FSRFMgaXMgbm90IHNldAoj
IENPTkZJR19XTF9USSBpcyBub3Qgc2V0CiMgQ09ORklHX1pEMTIxMVJXIGlzIG5vdCBzZXQK
IyBDT05GSUdfTVdJRklFWCBpcyBub3Qgc2V0CiMgQ09ORklHX0NXMTIwMCBpcyBub3Qgc2V0
CiMgQ09ORklHX1JTSV85MVggaXMgbm90IHNldAoKIwojIEVuYWJsZSBXaU1BWCAoTmV0d29y
a2luZyBvcHRpb25zKSB0byBzZWUgdGhlIFdpTUFYIGRyaXZlcnMKIwojIENPTkZJR19XQU4g
aXMgbm90IHNldApDT05GSUdfWEVOX05FVERFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fTkVU
REVWX0JBQ0tFTkQ9eQojIENPTkZJR19WTVhORVQzIGlzIG5vdCBzZXQKIyBDT05GSUdfSFlQ
RVJWX05FVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lTRE4gaXMgbm90IHNldAoKIwojIElucHV0
IGRldmljZSBzdXBwb3J0CiMKQ09ORklHX0lOUFVUPXkKQ09ORklHX0lOUFVUX0ZGX01FTUxF
U1M9eQpDT05GSUdfSU5QVVRfUE9MTERFVj15CkNPTkZJR19JTlBVVF9TUEFSU0VLTUFQPXkK
IyBDT05GSUdfSU5QVVRfTUFUUklYS01BUCBpcyBub3Qgc2V0CgojCiMgVXNlcmxhbmQgaW50
ZXJmYWNlcwojCkNPTkZJR19JTlBVVF9NT1VTRURFVj15CkNPTkZJR19JTlBVVF9NT1VTRURF
Vl9QU0FVWD15CkNPTkZJR19JTlBVVF9NT1VTRURFVl9TQ1JFRU5fWD0xMDI0CkNPTkZJR19J
TlBVVF9NT1VTRURFVl9TQ1JFRU5fWT03NjgKIyBDT05GSUdfSU5QVVRfSk9ZREVWIGlzIG5v
dCBzZXQKQ09ORklHX0lOUFVUX0VWREVWPXkKIyBDT05GSUdfSU5QVVRfRVZCVUcgaXMgbm90
IHNldAoKIwojIElucHV0IERldmljZSBEcml2ZXJzCiMKQ09ORklHX0lOUFVUX0tFWUJPQVJE
PXkKQ09ORklHX0tFWUJPQVJEX0FEUDU1ODg9bQojIENPTkZJR19LRVlCT0FSRF9BRFA1NTg5
IGlzIG5vdCBzZXQKQ09ORklHX0tFWUJPQVJEX0FUS0JEPXkKIyBDT05GSUdfS0VZQk9BUkRf
UVQxMDcwIGlzIG5vdCBzZXQKQ09ORklHX0tFWUJPQVJEX1FUMjE2MD1tCkNPTkZJR19LRVlC
T0FSRF9MS0tCRD1tCiMgQ09ORklHX0tFWUJPQVJEX0dQSU8gaXMgbm90IHNldAojIENPTkZJ
R19LRVlCT0FSRF9HUElPX1BPTExFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1RD
QTY0MTYgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9UQ0E4NDE4IGlzIG5vdCBzZXQK
IyBDT05GSUdfS0VZQk9BUkRfTUFUUklYIGlzIG5vdCBzZXQKQ09ORklHX0tFWUJPQVJEX0xN
ODMyMz1tCiMgQ09ORklHX0tFWUJPQVJEX0xNODMzMyBpcyBub3Qgc2V0CkNPTkZJR19LRVlC
T0FSRF9NQVg3MzU5PW0KIyBDT05GSUdfS0VZQk9BUkRfTUNTIGlzIG5vdCBzZXQKIyBDT05G
SUdfS0VZQk9BUkRfTVBSMTIxIGlzIG5vdCBzZXQKQ09ORklHX0tFWUJPQVJEX05FV1RPTj1t
CkNPTkZJR19LRVlCT0FSRF9PUEVOQ09SRVM9bQpDT05GSUdfS0VZQk9BUkRfU1RPV0FXQVk9
bQpDT05GSUdfS0VZQk9BUkRfU1VOS0JEPW0KQ09ORklHX0tFWUJPQVJEX1hUS0JEPW0KIyBD
T05GSUdfSU5QVVRfTU9VU0UgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9KT1lTVElDSyBp
cyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX1RBQkxFVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
UFVUX1RPVUNIU0NSRUVOIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfTUlTQyBpcyBub3Qg
c2V0CgojCiMgSGFyZHdhcmUgSS9PIHBvcnRzCiMKQ09ORklHX1NFUklPPXkKQ09ORklHX0FS
Q0hfTUlHSFRfSEFWRV9QQ19TRVJJTz15CkNPTkZJR19TRVJJT19JODA0Mj15CkNPTkZJR19T
RVJJT19TRVJQT1JUPW0KQ09ORklHX1NFUklPX0NUODJDNzEwPW0KQ09ORklHX1NFUklPX1BD
SVBTMj1tCkNPTkZJR19TRVJJT19MSUJQUzI9eQpDT05GSUdfU0VSSU9fUkFXPW0KQ09ORklH
X1NFUklPX0FMVEVSQV9QUzI9bQojIENPTkZJR19TRVJJT19QUzJNVUxUIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VSSU9fQVJDX1BTMiBpcyBub3Qgc2V0CkNPTkZJR19IWVBFUlZfS0VZQk9B
UkQ9eQpDT05GSUdfR0FNRVBPUlQ9bQpDT05GSUdfR0FNRVBPUlRfTlM1NTg9bQpDT05GSUdf
R0FNRVBPUlRfTDQ9bQpDT05GSUdfR0FNRVBPUlRfRU1VMTBLMT1tCkNPTkZJR19HQU1FUE9S
VF9GTTgwMT1tCgojCiMgQ2hhcmFjdGVyIGRldmljZXMKIwpDT05GSUdfVFRZPXkKQ09ORklH
X1ZUPXkKQ09ORklHX0NPTlNPTEVfVFJBTlNMQVRJT05TPXkKQ09ORklHX1ZUX0NPTlNPTEU9
eQpDT05GSUdfVlRfQ09OU09MRV9TTEVFUD15CkNPTkZJR19IV19DT05TT0xFPXkKQ09ORklH
X1ZUX0hXX0NPTlNPTEVfQklORElORz15CkNPTkZJR19VTklYOThfUFRZUz15CkNPTkZJR19E
RVZQVFNfTVVMVElQTEVfSU5TVEFOQ0VTPXkKIyBDT05GSUdfTEVHQUNZX1BUWVMgaXMgbm90
IHNldApDT05GSUdfU0VSSUFMX05PTlNUQU5EQVJEPXkKIyBDT05GSUdfUk9DS0VUUE9SVCBp
cyBub3Qgc2V0CiMgQ09ORklHX0NZQ0xBREVTIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9YQV9J
TlRFTExJTyBpcyBub3Qgc2V0CiMgQ09ORklHX01PWEFfU01BUlRJTyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NZTkNMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfU1lOQ0xJTktNUCBpcyBub3Qg
c2V0CiMgQ09ORklHX1NZTkNMSU5LX0dUIGlzIG5vdCBzZXQKIyBDT05GSUdfTk9aT01JIGlz
IG5vdCBzZXQKIyBDT05GSUdfSVNJIGlzIG5vdCBzZXQKIyBDT05GSUdfTl9IRExDIGlzIG5v
dCBzZXQKIyBDT05GSUdfTl9HU00gaXMgbm90IHNldAojIENPTkZJR19UUkFDRV9TSU5LIGlz
IG5vdCBzZXQKIyBDT05GSUdfREVWS01FTSBpcyBub3Qgc2V0CgojCiMgU2VyaWFsIGRyaXZl
cnMKIwpDT05GSUdfU0VSSUFMX0VBUkxZQ09OPXkKQ09ORklHX1NFUklBTF84MjUwPXkKQ09O
RklHX1NFUklBTF84MjUwX0RFUFJFQ0FURURfT1BUSU9OUz15CkNPTkZJR19TRVJJQUxfODI1
MF9QTlA9eQpDT05GSUdfU0VSSUFMXzgyNTBfQ09OU09MRT15CkNPTkZJR19TRVJJQUxfODI1
MF9ETUE9eQpDT05GSUdfU0VSSUFMXzgyNTBfUENJPXkKQ09ORklHX1NFUklBTF84MjUwX05S
X1VBUlRTPTMyCkNPTkZJR19TRVJJQUxfODI1MF9SVU5USU1FX1VBUlRTPTQKQ09ORklHX1NF
UklBTF84MjUwX0VYVEVOREVEPXkKQ09ORklHX1NFUklBTF84MjUwX01BTllfUE9SVFM9eQpD
T05GSUdfU0VSSUFMXzgyNTBfU0hBUkVfSVJRPXkKIyBDT05GSUdfU0VSSUFMXzgyNTBfREVU
RUNUX0lSUSBpcyBub3Qgc2V0CkNPTkZJR19TRVJJQUxfODI1MF9SU0E9eQojIENPTkZJR19T
RVJJQUxfODI1MF9EVyBpcyBub3Qgc2V0CgojCiMgTm9uLTgyNTAgc2VyaWFsIHBvcnQgc3Vw
cG9ydAojCkNPTkZJR19TRVJJQUxfTUZEX0hTVT1tCkNPTkZJR19TRVJJQUxfQ09SRT15CkNP
TkZJR19TRVJJQUxfQ09SRV9DT05TT0xFPXkKQ09ORklHX1NFUklBTF9KU009bQojIENPTkZJ
R19TRVJJQUxfU0NDTlhQIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX1NDMTZJUzdYWCBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9BTFRFUkFfSlRBR1VBUlQgaXMgbm90IHNldAoj
IENPTkZJR19TRVJJQUxfQUxURVJBX1VBUlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxf
QVJDIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX1JQMiBpcyBub3Qgc2V0CiMgQ09ORklH
X1NFUklBTF9GU0xfTFBVQVJUIGlzIG5vdCBzZXQKQ09ORklHX0hWQ19EUklWRVI9eQpDT05G
SUdfSFZDX0lSUT15CkNPTkZJR19IVkNfWEVOPXkKQ09ORklHX0hWQ19YRU5fRlJPTlRFTkQ9
eQojIENPTkZJR19WSVJUSU9fQ09OU09MRSBpcyBub3Qgc2V0CkNPTkZJR19JUE1JX0hBTkRM
RVI9eQojIENPTkZJR19JUE1JX1BBTklDX0VWRU5UIGlzIG5vdCBzZXQKQ09ORklHX0lQTUlf
REVWSUNFX0lOVEVSRkFDRT15CkNPTkZJR19JUE1JX1NJPXkKIyBDT05GSUdfSVBNSV9TSV9Q
Uk9CRV9ERUZBVUxUUyBpcyBub3Qgc2V0CkNPTkZJR19JUE1JX1dBVENIRE9HPXkKQ09ORklH
X0lQTUlfUE9XRVJPRkY9eQpDT05GSUdfSFdfUkFORE9NPXkKQ09ORklHX0hXX1JBTkRPTV9U
SU1FUklPTUVNPXkKQ09ORklHX0hXX1JBTkRPTV9JTlRFTD15CkNPTkZJR19IV19SQU5ET01f
QU1EPXkKQ09ORklHX0hXX1JBTkRPTV9WSUE9eQojIENPTkZJR19IV19SQU5ET01fVklSVElP
IGlzIG5vdCBzZXQKQ09ORklHX0hXX1JBTkRPTV9UUE09eQpDT05GSUdfTlZSQU09eQojIENP
TkZJR19SMzk2NCBpcyBub3Qgc2V0CiMgQ09ORklHX0FQUExJQ09NIGlzIG5vdCBzZXQKIyBD
T05GSUdfTVdBVkUgaXMgbm90IHNldAojIENPTkZJR19SQVdfRFJJVkVSIGlzIG5vdCBzZXQK
Q09ORklHX0hQRVQ9eQpDT05GSUdfSFBFVF9NTUFQPXkKQ09ORklHX0hQRVRfTU1BUF9ERUZB
VUxUPXkKQ09ORklHX0hBTkdDSEVDS19USU1FUj15CkNPTkZJR19UQ0dfVFBNPXkKQ09ORklH
X1RDR19USVM9eQojIENPTkZJR19UQ0dfVElTX0kyQ19BVE1FTCBpcyBub3Qgc2V0CiMgQ09O
RklHX1RDR19USVNfSTJDX0lORklORU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfVENHX1RJU19J
MkNfTlVWT1RPTiBpcyBub3Qgc2V0CiMgQ09ORklHX1RDR19OU0MgaXMgbm90IHNldAojIENP
TkZJR19UQ0dfQVRNRUwgaXMgbm90IHNldAojIENPTkZJR19UQ0dfSU5GSU5FT04gaXMgbm90
IHNldAojIENPTkZJR19UQ0dfU1QzM19JMkMgaXMgbm90IHNldAojIENPTkZJR19UQ0dfWEVO
IGlzIG5vdCBzZXQKIyBDT05GSUdfVEVMQ0xPQ0sgaXMgbm90IHNldApDT05GSUdfREVWUE9S
VD15CkNPTkZJR19JMkM9eQpDT05GSUdfSTJDX0JPQVJESU5GTz15CkNPTkZJR19JMkNfQ09N
UEFUPXkKQ09ORklHX0kyQ19DSEFSREVWPXkKIyBDT05GSUdfSTJDX01VWCBpcyBub3Qgc2V0
CkNPTkZJR19JMkNfSEVMUEVSX0FVVE89eQpDT05GSUdfSTJDX0FMR09CSVQ9eQoKIwojIEky
QyBIYXJkd2FyZSBCdXMgc3VwcG9ydAojCgojCiMgUEMgU01CdXMgaG9zdCBjb250cm9sbGVy
IGRyaXZlcnMKIwpDT05GSUdfSTJDX0FMSTE1MzU9eQpDT05GSUdfSTJDX0FMSTE1NjM9eQpD
T05GSUdfSTJDX0FMSTE1WDM9eQpDT05GSUdfSTJDX0FNRDc1Nj15CkNPTkZJR19JMkNfQU1E
NzU2X1M0ODgyPXkKQ09ORklHX0kyQ19BTUQ4MTExPXkKQ09ORklHX0kyQ19JODAxPXkKQ09O
RklHX0kyQ19JU0NIPXkKQ09ORklHX0kyQ19JU01UPXkKQ09ORklHX0kyQ19QSUlYND15CkNP
TkZJR19JMkNfTkZPUkNFMj15CkNPTkZJR19JMkNfTkZPUkNFMl9TNDk4NT15CkNPTkZJR19J
MkNfU0lTNTU5NT15CkNPTkZJR19JMkNfU0lTNjMwPXkKQ09ORklHX0kyQ19TSVM5Nlg9eQpD
T05GSUdfSTJDX1ZJQT15CkNPTkZJR19JMkNfVklBUFJPPXkKCiMKIyBBQ1BJIGRyaXZlcnMK
IwpDT05GSUdfSTJDX1NDTUk9eQoKIwojIEkyQyBzeXN0ZW0gYnVzIGRyaXZlcnMgKG1vc3Rs
eSBlbWJlZGRlZCAvIHN5c3RlbS1vbi1jaGlwKQojCiMgQ09ORklHX0kyQ19DQlVTX0dQSU8g
aXMgbm90IHNldAojIENPTkZJR19JMkNfREVTSUdOV0FSRV9QTEFURk9STSBpcyBub3Qgc2V0
CiMgQ09ORklHX0kyQ19ERVNJR05XQVJFX1BDSSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19H
UElPIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX09DT1JFUyBpcyBub3Qgc2V0CiMgQ09ORklH
X0kyQ19QQ0FfUExBVEZPUk0gaXMgbm90IHNldAojIENPTkZJR19JMkNfUFhBX1BDSSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0kyQ19TSU1URUMgaXMgbm90IHNldAojIENPTkZJR19JMkNfWElM
SU5YIGlzIG5vdCBzZXQKCiMKIyBFeHRlcm5hbCBJMkMvU01CdXMgYWRhcHRlciBkcml2ZXJz
CiMKIyBDT05GSUdfSTJDX0RJT0xBTl9VMkMgaXMgbm90IHNldAojIENPTkZJR19JMkNfUEFS
UE9SVF9MSUdIVCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ST0JPVEZVWlpfT1NJRiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0kyQ19UQU9TX0VWTSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19U
SU5ZX1VTQiBpcyBub3Qgc2V0CgojCiMgT3RoZXIgSTJDL1NNQnVzIGJ1cyBkcml2ZXJzCiMK
IyBDT05GSUdfSTJDX1NUVUIgaXMgbm90IHNldAojIENPTkZJR19JMkNfREVCVUdfQ09SRSBp
cyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERUJVR19BTEdPIGlzIG5vdCBzZXQKIyBDT05GSUdf
STJDX0RFQlVHX0JVUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NQSSBpcyBub3Qgc2V0CiMgQ09O
RklHX1NQTUkgaXMgbm90IHNldAojIENPTkZJR19IU0kgaXMgbm90IHNldAoKIwojIFBQUyBz
dXBwb3J0CiMKQ09ORklHX1BQUz15CiMgQ09ORklHX1BQU19ERUJVRyBpcyBub3Qgc2V0Cgoj
CiMgUFBTIGNsaWVudHMgc3VwcG9ydAojCiMgQ09ORklHX1BQU19DTElFTlRfS1RJTUVSIGlz
IG5vdCBzZXQKQ09ORklHX1BQU19DTElFTlRfTERJU0M9eQojIENPTkZJR19QUFNfQ0xJRU5U
X0dQSU8gaXMgbm90IHNldAoKIwojIFBQUyBnZW5lcmF0b3JzIHN1cHBvcnQKIwoKIwojIFBU
UCBjbG9jayBzdXBwb3J0CiMKQ09ORklHX1BUUF8xNTg4X0NMT0NLPXkKCiMKIyBFbmFibGUg
UEhZTElCIGFuZCBORVRXT1JLX1BIWV9USU1FU1RBTVBJTkcgdG8gc2VlIHRoZSBhZGRpdGlv
bmFsIGNsb2Nrcy4KIwojIENPTkZJR19QVFBfMTU4OF9DTE9DS19QQ0ggaXMgbm90IHNldApD
T05GSUdfQVJDSF9XQU5UX09QVElPTkFMX0dQSU9MSUI9eQpDT05GSUdfR1BJT0xJQj15CkNP
TkZJR19HUElPX0RFVlJFUz15CkNPTkZJR19HUElPX0FDUEk9eQojIENPTkZJR19ERUJVR19H
UElPIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19TWVNGUyBpcyBub3Qgc2V0CgojCiMgTWVt
b3J5IG1hcHBlZCBHUElPIGRyaXZlcnM6CiMKIyBDT05GSUdfR1BJT19HRU5FUklDX1BMQVRG
T1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19JVDg3NjFFIGlzIG5vdCBzZXQKIyBDT05G
SUdfR1BJT19GNzE4OFggaXMgbm90IHNldAojIENPTkZJR19HUElPX1NDSDMxMVggaXMgbm90
IHNldAojIENPTkZJR19HUElPX1NDSCBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fSUNIIGlz
IG5vdCBzZXQKIyBDT05GSUdfR1BJT19WWDg1NSBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9f
TFlOWFBPSU5UIGlzIG5vdCBzZXQKCiMKIyBJMkMgR1BJTyBleHBhbmRlcnM6CiMKIyBDT05G
SUdfR1BJT19NQVg3MzAwIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19NQVg3MzJYIGlzIG5v
dCBzZXQKIyBDT05GSUdfR1BJT19QQ0E5NTNYIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19Q
Q0Y4NTdYIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19TWDE1MFggaXMgbm90IHNldAojIENP
TkZJR19HUElPX0FEUDU1ODggaXMgbm90IHNldAoKIwojIFBDSSBHUElPIGV4cGFuZGVyczoK
IwojIENPTkZJR19HUElPX0JUOFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19BTUQ4MTEx
IGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19JTlRFTF9NSUQgaXMgbm90IHNldApDT05GSUdf
R1BJT19NTF9JT0g9eQojIENPTkZJR19HUElPX1JEQzMyMVggaXMgbm90IHNldAoKIwojIFNQ
SSBHUElPIGV4cGFuZGVyczoKIwoKIwojIEFDOTcgR1BJTyBleHBhbmRlcnM6CiMKCiMKIyBM
UEMgR1BJTyBleHBhbmRlcnM6CiMKCiMKIyBNT0RVTGJ1cyBHUElPIGV4cGFuZGVyczoKIwoK
IwojIFVTQiBHUElPIGV4cGFuZGVyczoKIwojIENPTkZJR19XMSBpcyBub3Qgc2V0CkNPTkZJ
R19QT1dFUl9TVVBQTFk9eQojIENPTkZJR19QT1dFUl9TVVBQTFlfREVCVUcgaXMgbm90IHNl
dAojIENPTkZJR19QREFfUE9XRVIgaXMgbm90IHNldAojIENPTkZJR19HRU5FUklDX0FEQ19C
QVRURVJZIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9QT1dFUiBpcyBub3Qgc2V0CiMgQ09O
RklHX0JBVFRFUllfRFMyNzgwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3ODEg
aXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX0RTMjc4MiBpcyBub3Qgc2V0CiMgQ09ORklH
X0JBVFRFUllfU0JTIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9CUTI3eDAwIGlzIG5v
dCBzZXQKIyBDT05GSUdfQkFUVEVSWV9NQVgxNzA0MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JB
VFRFUllfTUFYMTcwNDIgaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX1BDRjUwNjMzIGlz
IG5vdCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9NQVg4OTAzIGlzIG5vdCBzZXQKIyBDT05GSUdf
Q0hBUkdFUl9MUDg3MjcgaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0dQSU8gaXMgbm90
IHNldAojIENPTkZJR19DSEFSR0VSX0JRMjQxNVggaXMgbm90IHNldAojIENPTkZJR19DSEFS
R0VSX0JRMjQxOTAgaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0JRMjQ3MzUgaXMgbm90
IHNldAojIENPTkZJR19DSEFSR0VSX1NNQjM0NyBpcyBub3Qgc2V0CiMgQ09ORklHX1BPV0VS
X1JFU0VUIGlzIG5vdCBzZXQKIyBDT05GSUdfUE9XRVJfQVZTIGlzIG5vdCBzZXQKQ09ORklH
X0hXTU9OPXkKQ09ORklHX0hXTU9OX1ZJRD15CiMgQ09ORklHX0hXTU9OX0RFQlVHX0NISVAg
aXMgbm90IHNldAoKIwojIE5hdGl2ZSBkcml2ZXJzCiMKIyBDT05GSUdfU0VOU09SU19BQklU
VUdVUlUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FCSVRVR1VSVTMgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0FENzQxNCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf
QUQ3NDE4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDIxIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19BRE0xMDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19B
RE0xMDI2IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDI5IGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19BRE0xMDMxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19B
RE05MjQwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDEwIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19BRFQ3NDExIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19B
RFQ3NDYyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDcwIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19BRFQ3NDc1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19B
U0M3NjIxIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfSzhURU1QPXkKQ09ORklHX1NFTlNP
UlNfSzEwVEVNUD15CkNPTkZJR19TRU5TT1JTX0ZBTTE1SF9QT1dFUj15CiMgQ09ORklHX1NF
TlNPUlNfQVBQTEVTTUMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FTQjEwMCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQVRYUDEgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX0RTNjIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19EUzE2MjEgaXMgbm90IHNl
dApDT05GSUdfU0VOU09SU19JNUtfQU1CPXkKQ09ORklHX1NFTlNPUlNfRjcxODA1Rj15CkNP
TkZJR19TRU5TT1JTX0Y3MTg4MkZHPXkKQ09ORklHX1NFTlNPUlNfRjc1Mzc1Uz15CiMgQ09O
RklHX1NFTlNPUlNfRlNDSE1EIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUxOFNN
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUyMFNNIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19HNzYwQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRzc2MiBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfR1BJT19GQU4gaXMgbm90IHNldAojIENPTkZJR19T
RU5TT1JTX0hJSDYxMzAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0lCTUFFTSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfSUJNUEVYIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19JSU9fSFdNT04gaXMgbm90IHNldApDT05GSUdfU0VOU09SU19DT1JFVEVNUD15CiMg
Q09ORklHX1NFTlNPUlNfSVQ4NyBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0pDNDI9eQoj
IENPTkZJR19TRU5TT1JTX0xJTkVBR0UgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xU
QzI5NDUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xUQzQxNTEgaXMgbm90IHNldAoj
IENPTkZJR19TRU5TT1JTX0xUQzQyMTUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xU
QzQyMjIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xUQzQyNDUgaXMgbm90IHNldAoj
IENPTkZJR19TRU5TT1JTX0xUQzQyNjAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xU
QzQyNjEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX01BWDE2MDY1IGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19NQVgxNjE5IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19N
QVgxNjY4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVgxOTcgaXMgbm90IHNldAoj
IENPTkZJR19TRU5TT1JTX01BWDY2MzkgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX01B
WDY2NDIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX01BWDY2NTAgaXMgbm90IHNldAoj
IENPTkZJR19TRU5TT1JTX01BWDY2OTcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0hU
VTIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQ1AzMDIxIGlzIG5vdCBzZXQKQ09O
RklHX1NFTlNPUlNfTE02Mz15CkNPTkZJR19TRU5TT1JTX0xNNzM9eQpDT05GSUdfU0VOU09S
U19MTTc1PXkKQ09ORklHX1NFTlNPUlNfTE03Nz15CkNPTkZJR19TRU5TT1JTX0xNNzg9eQpD
T05GSUdfU0VOU09SU19MTTgwPXkKQ09ORklHX1NFTlNPUlNfTE04Mz15CkNPTkZJR19TRU5T
T1JTX0xNODU9eQpDT05GSUdfU0VOU09SU19MTTg3PXkKQ09ORklHX1NFTlNPUlNfTE05MD15
CkNPTkZJR19TRU5TT1JTX0xNOTI9eQpDT05GSUdfU0VOU09SU19MTTkzPXkKIyBDT05GSUdf
U0VOU09SU19MTTk1MjM0IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjQxIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjQ1IGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19QQzg3MzYwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19QQzg3NDI3IGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19OVENfVEhFUk1JU1RPUiBpcyBub3Qgc2V0CiMg
Q09ORklHX1NFTlNPUlNfTkNUNjY4MyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTkNU
Njc3NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUENGODU5MSBpcyBub3Qgc2V0CkNP
TkZJR19QTUJVUz15CkNPTkZJR19TRU5TT1JTX1BNQlVTPXkKIyBDT05GSUdfU0VOU09SU19B
RE0xMjc1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTI1MDY2IGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19MVEMyOTc4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19N
QVgxNjA2NCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMzQ0NDAgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX01BWDg2ODggaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X1VDRDkwMDAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1VDRDkyMDAgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX1pMNjEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf
U0hUMTUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NIVDIxIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19TSFRDMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU0lTNTU5
NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRE1FMTczNyBpcyBub3Qgc2V0CiMgQ09O
RklHX1NFTlNPUlNfRU1DMTQwMyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRU1DMjEw
MyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRU1DNlcyMDEgaXMgbm90IHNldAojIENP
TkZJR19TRU5TT1JTX1NNU0M0N00xIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TTVND
NDdNMTkyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TTVNDNDdCMzk3IGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19TQ0g1NlhYX0NPTU1PTiBpcyBub3Qgc2V0CiMgQ09ORklH
X1NFTlNPUlNfU0NINTYyNyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU0NINTYzNiBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU01NNjY1IGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19BREMxMjhEODE4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFMxMDE1
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFM3ODI4IGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19BTUM2ODIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19JTkEyMDkg
aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0lOQTJYWCBpcyBub3Qgc2V0CiMgQ09ORklH
X1NFTlNPUlNfVEhNQzUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19UTVAxMDIgaXMg
bm90IHNldAojIENPTkZJR19TRU5TT1JTX1RNUDQwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NF
TlNPUlNfVE1QNDIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19WSUFfQ1BVVEVNUCBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVklBNjg2QSBpcyBub3Qgc2V0CiMgQ09ORklH
X1NFTlNPUlNfVlQxMjExIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19WVDgyMzEgaXMg
bm90IHNldApDT05GSUdfU0VOU09SU19XODM3ODFEPXkKQ09ORklHX1NFTlNPUlNfVzgzNzkx
RD15CkNPTkZJR19TRU5TT1JTX1c4Mzc5MkQ9eQpDT05GSUdfU0VOU09SU19XODM3OTM9eQpD
T05GSUdfU0VOU09SU19XODM3OTU9eQojIENPTkZJR19TRU5TT1JTX1c4Mzc5NV9GQU5DVFJM
IGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfVzgzTDc4NVRTPXkKQ09ORklHX1NFTlNPUlNf
VzgzTDc4Nk5HPXkKQ09ORklHX1NFTlNPUlNfVzgzNjI3SEY9eQpDT05GSUdfU0VOU09SU19X
ODM2MjdFSEY9eQoKIwojIEFDUEkgZHJpdmVycwojCkNPTkZJR19TRU5TT1JTX0FDUElfUE9X
RVI9eQojIENPTkZJR19TRU5TT1JTX0FUSzAxMTAgaXMgbm90IHNldApDT05GSUdfVEhFUk1B
TD15CkNPTkZJR19USEVSTUFMX0hXTU9OPXkKQ09ORklHX1RIRVJNQUxfREVGQVVMVF9HT1Zf
U1RFUF9XSVNFPXkKIyBDT05GSUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9GQUlSX1NIQVJFIGlz
IG5vdCBzZXQKIyBDT05GSUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9VU0VSX1NQQUNFIGlzIG5v
dCBzZXQKIyBDT05GSUdfVEhFUk1BTF9HT1ZfRkFJUl9TSEFSRSBpcyBub3Qgc2V0CkNPTkZJ
R19USEVSTUFMX0dPVl9TVEVQX1dJU0U9eQpDT05GSUdfVEhFUk1BTF9HT1ZfVVNFUl9TUEFD
RT15CiMgQ09ORklHX1RIRVJNQUxfRU1VTEFUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5U
RUxfUE9XRVJDTEFNUCBpcyBub3Qgc2V0CkNPTkZJR19YODZfUEtHX1RFTVBfVEhFUk1BTD15
CiMgQ09ORklHX0FDUElfSU5UMzQwM19USEVSTUFMIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5U
RUxfU09DX0RUU19USEVSTUFMIGlzIG5vdCBzZXQKCiMKIyBUZXhhcyBJbnN0cnVtZW50cyB0
aGVybWFsIGRyaXZlcnMKIwpDT05GSUdfV0FUQ0hET0c9eQpDT05GSUdfV0FUQ0hET0dfQ09S
RT15CiMgQ09ORklHX1dBVENIRE9HX05PV0FZT1VUIGlzIG5vdCBzZXQKCiMKIyBXYXRjaGRv
ZyBEZXZpY2UgRHJpdmVycwojCkNPTkZJR19TT0ZUX1dBVENIRE9HPXkKIyBDT05GSUdfWElM
SU5YX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfRFdfV0FUQ0hET0cgaXMgbm90IHNl
dAojIENPTkZJR19BQ1FVSVJFX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0FEVkFOVEVDSF9X
RFQgaXMgbm90IHNldAojIENPTkZJR19BTElNMTUzNV9XRFQgaXMgbm90IHNldAojIENPTkZJ
R19BTElNNzEwMV9XRFQgaXMgbm90IHNldApDT05GSUdfRjcxODA4RV9XRFQ9eQpDT05GSUdf
U1A1MTAwX1RDTz15CiMgQ09ORklHX1NCQ19GSVRQQzJfV0FUQ0hET0cgaXMgbm90IHNldAoj
IENPTkZJR19FVVJPVEVDSF9XRFQgaXMgbm90IHNldAojIENPTkZJR19JQjcwMF9XRFQgaXMg
bm90IHNldAojIENPTkZJR19JQk1BU1IgaXMgbm90IHNldAojIENPTkZJR19XQUZFUl9XRFQg
aXMgbm90IHNldApDT05GSUdfSTYzMDBFU0JfV0RUPXkKQ09ORklHX0lFNlhYX1dEVD15CkNP
TkZJR19JVENPX1dEVD15CkNPTkZJR19JVENPX1ZFTkRPUl9TVVBQT1JUPXkKIyBDT05GSUdf
SVQ4NzEyRl9XRFQgaXMgbm90IHNldAojIENPTkZJR19JVDg3X1dEVCBpcyBub3Qgc2V0CiMg
Q09ORklHX0hQX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfU0MxMjAwX1dEVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1BDODc0MTNfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfTlZfVENP
IGlzIG5vdCBzZXQKIyBDT05GSUdfNjBYWF9XRFQgaXMgbm90IHNldAojIENPTkZJR19DUFU1
X1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NNU0NfU0NIMzExWF9XRFQgaXMgbm90IHNldAoj
IENPTkZJR19TTVNDMzdCNzg3X1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJQV9XRFQgaXMg
bm90IHNldAojIENPTkZJR19XODM2MjdIRl9XRFQgaXMgbm90IHNldAojIENPTkZJR19XODM4
NzdGX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1c4Mzk3N0ZfV0RUIGlzIG5vdCBzZXQKIyBD
T05GSUdfTUFDSFpfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0JDX0VQWF9DM19XQVRDSERP
RyBpcyBub3Qgc2V0CiMgQ09ORklHX01FTl9BMjFfV0RUIGlzIG5vdCBzZXQKQ09ORklHX1hF
Tl9XRFQ9eQoKIwojIFBDSS1iYXNlZCBXYXRjaGRvZyBDYXJkcwojCiMgQ09ORklHX1BDSVBD
V0FUQ0hET0cgaXMgbm90IHNldAojIENPTkZJR19XRFRQQ0kgaXMgbm90IHNldAoKIwojIFVT
Qi1iYXNlZCBXYXRjaGRvZyBDYXJkcwojCiMgQ09ORklHX1VTQlBDV0FUQ0hET0cgaXMgbm90
IHNldApDT05GSUdfU1NCX1BPU1NJQkxFPXkKCiMKIyBTb25pY3MgU2lsaWNvbiBCYWNrcGxh
bmUKIwojIENPTkZJR19TU0IgaXMgbm90IHNldApDT05GSUdfQkNNQV9QT1NTSUJMRT15Cgoj
CiMgQnJvYWRjb20gc3BlY2lmaWMgQU1CQQojCiMgQ09ORklHX0JDTUEgaXMgbm90IHNldAoK
IwojIE11bHRpZnVuY3Rpb24gZGV2aWNlIGRyaXZlcnMKIwpDT05GSUdfTUZEX0NPUkU9eQoj
IENPTkZJR19NRkRfQ1M1NTM1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0FTMzcxMSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1BNSUNfQURQNTUyMCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9B
QVQyODcwX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19NRkRfQkNNNTkwWFggaXMgbm90IHNl
dAojIENPTkZJR19NRkRfQVhQMjBYIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0NST1NfRUMg
aXMgbm90IHNldAojIENPTkZJR19QTUlDX0RBOTAzWCBpcyBub3Qgc2V0CiMgQ09ORklHX01G
RF9EQTkwNTJfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0RBOTA1NSBpcyBub3Qgc2V0
CiMgQ09ORklHX01GRF9EQTkwNjMgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUMxM1hYWF9J
MkMgaXMgbm90IHNldApDT05GSUdfSFRDX1BBU0lDMz1tCiMgQ09ORklHX0hUQ19JMkNQTEQg
aXMgbm90IHNldApDT05GSUdfTFBDX0lDSD15CkNPTkZJR19MUENfU0NIPXkKIyBDT05GSUdf
TUZEX0pBTlpfQ01PRElPIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0tFTVBMRCBpcyBub3Qg
c2V0CiMgQ09ORklHX01GRF84OFBNODAwIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEXzg4UE04
MDUgaXMgbm90IHNldAojIENPTkZJR19NRkRfODhQTTg2MFggaXMgbm90IHNldAojIENPTkZJ
R19NRkRfTUFYMTQ1NzcgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYNzc2ODYgaXMgbm90
IHNldAojIENPTkZJR19NRkRfTUFYNzc2OTMgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUFY
ODkwNyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg4OTI1IGlzIG5vdCBzZXQKIyBDT05G
SUdfTUZEX01BWDg5OTcgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYODk5OCBpcyBub3Qg
c2V0CiMgQ09ORklHX01GRF9WSVBFUkJPQVJEIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1JF
VFUgaXMgbm90IHNldApDT05GSUdfTUZEX1BDRjUwNjMzPW0KQ09ORklHX1BDRjUwNjMzX0FE
Qz1tCkNPTkZJR19QQ0Y1MDYzM19HUElPPW0KIyBDT05GSUdfTUZEX1JEQzMyMVggaXMgbm90
IHNldAojIENPTkZJR19NRkRfUlRTWF9QQ0kgaXMgbm90IHNldAojIENPTkZJR19NRkRfUlRT
WF9VU0IgaXMgbm90IHNldAojIENPTkZJR19NRkRfUkM1VDU4MyBpcyBub3Qgc2V0CiMgQ09O
RklHX01GRF9TRUNfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9TSTQ3NlhfQ09SRSBp
cyBub3Qgc2V0CkNPTkZJR19NRkRfU001MDE9bQojIENPTkZJR19NRkRfU001MDFfR1BJTyBp
cyBub3Qgc2V0CiMgQ09ORklHX01GRF9TTVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfQUJYNTAw
X0NPUkUgaXMgbm90IHNldAojIENPTkZJR19NRkRfU1lTQ09OIGlzIG5vdCBzZXQKIyBDT05G
SUdfTUZEX1RJX0FNMzM1WF9UU0NBREMgaXMgbm90IHNldAojIENPTkZJR19NRkRfTFAzOTQz
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0xQODc4OCBpcyBub3Qgc2V0CiMgQ09ORklHX01G
RF9QQUxNQVMgaXMgbm90IHNldAojIENPTkZJR19UUFM2MTA1WCBpcyBub3Qgc2V0CkNPTkZJ
R19UUFM2NTAxMD1tCiMgQ09ORklHX1RQUzY1MDdYIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE
X1RQUzY1MDkwIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1MjE3IGlzIG5vdCBzZXQK
IyBDT05GSUdfTUZEX1RQUzY1MjE4IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1ODZY
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1OTEwIGlzIG5vdCBzZXQKIyBDT05GSUdf
TUZEX1RQUzY1OTEyIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1OTEyX0kyQyBpcyBu
b3Qgc2V0CiMgQ09ORklHX01GRF9UUFM4MDAzMSBpcyBub3Qgc2V0CiMgQ09ORklHX1RXTDQw
MzBfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RXTDYwNDBfQ09SRSBpcyBub3Qgc2V0CkNP
TkZJR19NRkRfV0wxMjczX0NPUkU9bQojIENPTkZJR19NRkRfTE0zNTMzIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUZEX1RJTUJFUkRBTEUgaXMgbm90IHNldAojIENPTkZJR19NRkRfVEMzNTg5
WCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9UTUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE
X1ZYODU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0FSSVpPTkFfSTJDIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUZEX1dNODQwMCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9XTTgzMVhfSTJD
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1dNODM1MF9JMkMgaXMgbm90IHNldAojIENPTkZJ
R19NRkRfV004OTk0IGlzIG5vdCBzZXQKIyBDT05GSUdfUkVHVUxBVE9SIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUVESUFfU1VQUE9SVCBpcyBub3Qgc2V0CgojCiMgR3JhcGhpY3Mgc3VwcG9y
dAojCkNPTkZJR19BR1A9eQpDT05GSUdfQUdQX0FNRDY0PXkKQ09ORklHX0FHUF9JTlRFTD15
CkNPTkZJR19BR1BfU0lTPXkKQ09ORklHX0FHUF9WSUE9eQpDT05GSUdfSU5URUxfR1RUPXkK
Q09ORklHX1ZHQV9BUkI9eQpDT05GSUdfVkdBX0FSQl9NQVhfR1BVUz0xNgpDT05GSUdfVkdB
X1NXSVRDSEVST089eQoKIwojIERpcmVjdCBSZW5kZXJpbmcgTWFuYWdlcgojCkNPTkZJR19E
Uk09eQpDT05GSUdfRFJNX0tNU19IRUxQRVI9eQpDT05GSUdfRFJNX0tNU19GQl9IRUxQRVI9
eQojIENPTkZJR19EUk1fTE9BRF9FRElEX0ZJUk1XQVJFIGlzIG5vdCBzZXQKQ09ORklHX0RS
TV9UVE09eQoKIwojIEkyQyBlbmNvZGVyIG9yIGhlbHBlciBjaGlwcwojCkNPTkZJR19EUk1f
STJDX0NINzAwNj1tCkNPTkZJR19EUk1fSTJDX1NJTDE2ND1tCiMgQ09ORklHX0RSTV9JMkNf
TlhQX1REQTk5OFggaXMgbm90IHNldAojIENPTkZJR19EUk1fUFROMzQ2MCBpcyBub3Qgc2V0
CiMgQ09ORklHX0RSTV9UREZYIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1IxMjggaXMgbm90
IHNldAojIENPTkZJR19EUk1fUkFERU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX05PVVZF
QVUgaXMgbm90IHNldApDT05GSUdfRFJNX0k4MTA9eQpDT05GSUdfRFJNX0k5MTU9eQpDT05G
SUdfRFJNX0k5MTVfS01TPXkKQ09ORklHX0RSTV9JOTE1X0ZCREVWPXkKIyBDT05GSUdfRFJN
X0k5MTVfUFJFTElNSU5BUllfSFdfU1VQUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9N
R0EgaXMgbm90IHNldAojIENPTkZJR19EUk1fU0lTIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJN
X1ZJQSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9TQVZBR0UgaXMgbm90IHNldAojIENPTkZJ
R19EUk1fVk1XR0ZYIGlzIG5vdCBzZXQKQ09ORklHX0RSTV9HTUE1MDA9eQpDT05GSUdfRFJN
X0dNQTYwMD15CkNPTkZJR19EUk1fR01BMzYwMD15CiMgQ09ORklHX0RSTV9VREwgaXMgbm90
IHNldAojIENPTkZJR19EUk1fQVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX01HQUcyMDAg
aXMgbm90IHNldApDT05GSUdfRFJNX0NJUlJVU19RRU1VPXkKIyBDT05GSUdfRFJNX1FYTCBp
cyBub3Qgc2V0CiMgQ09ORklHX0RSTV9CT0NIUyBpcyBub3Qgc2V0CgojCiMgRnJhbWUgYnVm
ZmVyIERldmljZXMKIwpDT05GSUdfRkI9eQpDT05GSUdfRklSTVdBUkVfRURJRD15CkNPTkZJ
R19GQl9EREM9eQpDT05GSUdfRkJfQk9PVF9WRVNBX1NVUFBPUlQ9eQpDT05GSUdfRkJfQ0ZC
X0ZJTExSRUNUPXkKQ09ORklHX0ZCX0NGQl9DT1BZQVJFQT15CkNPTkZJR19GQl9DRkJfSU1B
R0VCTElUPXkKIyBDT05GSUdfRkJfQ0ZCX1JFVl9QSVhFTFNfSU5fQllURSBpcyBub3Qgc2V0
CkNPTkZJR19GQl9TWVNfRklMTFJFQ1Q9eQpDT05GSUdfRkJfU1lTX0NPUFlBUkVBPXkKQ09O
RklHX0ZCX1NZU19JTUFHRUJMSVQ9eQojIENPTkZJR19GQl9GT1JFSUdOX0VORElBTiBpcyBu
b3Qgc2V0CkNPTkZJR19GQl9TWVNfRk9QUz15CkNPTkZJR19GQl9ERUZFUlJFRF9JTz15CiMg
Q09ORklHX0ZCX1NWR0FMSUIgaXMgbm90IHNldAojIENPTkZJR19GQl9NQUNNT0RFUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0ZCX0JBQ0tMSUdIVCBpcyBub3Qgc2V0CkNPTkZJR19GQl9NT0RF
X0hFTFBFUlM9eQpDT05GSUdfRkJfVElMRUJMSVRUSU5HPXkKCiMKIyBGcmFtZSBidWZmZXIg
aGFyZHdhcmUgZHJpdmVycwojCkNPTkZJR19GQl9DSVJSVVM9eQojIENPTkZJR19GQl9QTTIg
aXMgbm90IHNldAojIENPTkZJR19GQl9DWUJFUjIwMDAgaXMgbm90IHNldApDT05GSUdfRkJf
QVJDPW0KIyBDT05GSUdfRkJfQVNJTElBTlQgaXMgbm90IHNldAojIENPTkZJR19GQl9JTVNU
VCBpcyBub3Qgc2V0CkNPTkZJR19GQl9WR0ExNj15CkNPTkZJR19GQl9VVkVTQT15CkNPTkZJ
R19GQl9WRVNBPXkKQ09ORklHX0ZCX0VGST15CiMgQ09ORklHX0ZCX040MTEgaXMgbm90IHNl
dAojIENPTkZJR19GQl9IR0EgaXMgbm90IHNldAojIENPTkZJR19GQl9PUEVOQ09SRVMgaXMg
bm90IHNldAojIENPTkZJR19GQl9TMUQxM1hYWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX05W
SURJQSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1JJVkEgaXMgbm90IHNldApDT05GSUdfRkJf
STc0MD15CkNPTkZJR19GQl9MRTgwNTc4PXkKQ09ORklHX0ZCX0NBUklMTE9fUkFOQ0g9bQoj
IENPTkZJR19GQl9NQVRST1ggaXMgbm90IHNldAojIENPTkZJR19GQl9SQURFT04gaXMgbm90
IHNldAojIENPTkZJR19GQl9BVFkxMjggaXMgbm90IHNldAojIENPTkZJR19GQl9BVFkgaXMg
bm90IHNldAojIENPTkZJR19GQl9TMyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1NBVkFHRSBp
cyBub3Qgc2V0CiMgQ09ORklHX0ZCX1NJUyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1ZJQSBp
cyBub3Qgc2V0CiMgQ09ORklHX0ZCX05FT01BR0lDIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf
S1lSTyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCXzNERlggaXMgbm90IHNldAojIENPTkZJR19G
Ql9WT09ET08xIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfVlQ4NjIzIGlzIG5vdCBzZXQKIyBD
T05GSUdfRkJfVFJJREVOVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0FSSyBpcyBub3Qgc2V0
CiMgQ09ORklHX0ZCX1BNMyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0NBUk1JTkUgaXMgbm90
IHNldAojIENPTkZJR19GQl9TTTUwMSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1NNU0NVRlgg
aXMgbm90IHNldAojIENPTkZJR19GQl9VREwgaXMgbm90IHNldAojIENPTkZJR19GQl9WSVJU
VUFMIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9GQkRFVl9GUk9OVEVORD15CiMgQ09ORklHX0ZC
X01FVFJPTk9NRSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX01CODYyWFggaXMgbm90IHNldAoj
IENPTkZJR19GQl9CUk9BRFNIRUVUIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVVPX0sxOTBY
IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfSFlQRVJWIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf
U0lNUExFIGlzIG5vdCBzZXQKQ09ORklHX0JBQ0tMSUdIVF9MQ0RfU1VQUE9SVD15CiMgQ09O
RklHX0xDRF9DTEFTU19ERVZJQ0UgaXMgbm90IHNldApDT05GSUdfQkFDS0xJR0hUX0NMQVNT
X0RFVklDRT15CiMgQ09ORklHX0JBQ0tMSUdIVF9HRU5FUklDIGlzIG5vdCBzZXQKIyBDT05G
SUdfQkFDS0xJR0hUX0FQUExFIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX1NBSEFS
QSBpcyBub3Qgc2V0CiMgQ09ORklHX0JBQ0tMSUdIVF9BRFA4ODYwIGlzIG5vdCBzZXQKIyBD
T05GSUdfQkFDS0xJR0hUX0FEUDg4NzAgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRf
UENGNTA2MzMgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfTE0zNjM5IGlzIG5vdCBz
ZXQKIyBDT05GSUdfQkFDS0xJR0hUX0dQSU8gaXMgbm90IHNldAojIENPTkZJR19CQUNLTElH
SFRfTFY1MjA3TFAgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfQkQ2MTA3IGlzIG5v
dCBzZXQKQ09ORklHX1ZHQVNUQVRFPXkKQ09ORklHX0hETUk9eQoKIwojIENvbnNvbGUgZGlz
cGxheSBkcml2ZXIgc3VwcG9ydAojCkNPTkZJR19WR0FfQ09OU09MRT15CiMgQ09ORklHX1ZH
QUNPTl9TT0ZUX1NDUk9MTEJBQ0sgaXMgbm90IHNldApDT05GSUdfRFVNTVlfQ09OU09MRT15
CkNPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFPXkKQ09ORklHX0ZSQU1FQlVGRkVSX0NPTlNP
TEVfREVURUNUX1BSSU1BUlk9eQpDT05GSUdfRlJBTUVCVUZGRVJfQ09OU09MRV9ST1RBVElP
Tj15CiMgQ09ORklHX0xPR08gaXMgbm90IHNldApDT05GSUdfU09VTkQ9eQpDT05GSUdfU09V
TkRfT1NTX0NPUkU9eQpDT05GSUdfU09VTkRfT1NTX0NPUkVfUFJFQ0xBSU09eQpDT05GSUdf
U05EPXkKQ09ORklHX1NORF9USU1FUj15CkNPTkZJR19TTkRfUENNPXkKQ09ORklHX1NORF9I
V0RFUD15CkNPTkZJR19TTkRfUkFXTUlEST15CkNPTkZJR19TTkRfU0VRVUVOQ0VSPXkKIyBD
T05GSUdfU05EX1NFUV9EVU1NWSBpcyBub3Qgc2V0CkNPTkZJR19TTkRfT1NTRU1VTD15CkNP
TkZJR19TTkRfTUlYRVJfT1NTPXkKQ09ORklHX1NORF9QQ01fT1NTPXkKQ09ORklHX1NORF9Q
Q01fT1NTX1BMVUdJTlM9eQpDT05GSUdfU05EX1NFUVVFTkNFUl9PU1M9eQpDT05GSUdfU05E
X0hSVElNRVI9eQpDT05GSUdfU05EX1NFUV9IUlRJTUVSX0RFRkFVTFQ9eQojIENPTkZJR19T
TkRfRFlOQU1JQ19NSU5PUlMgaXMgbm90IHNldApDT05GSUdfU05EX1NVUFBPUlRfT0xEX0FQ
ST15CkNPTkZJR19TTkRfVkVSQk9TRV9QUk9DRlM9eQojIENPTkZJR19TTkRfVkVSQk9TRV9Q
UklOVEsgaXMgbm90IHNldAojIENPTkZJR19TTkRfREVCVUcgaXMgbm90IHNldApDT05GSUdf
U05EX1ZNQVNURVI9eQpDT05GSUdfU05EX0RNQV9TR0JVRj15CkNPTkZJR19TTkRfUkFXTUlE
SV9TRVE9eQojIENPTkZJR19TTkRfT1BMM19MSUJfU0VRIGlzIG5vdCBzZXQKIyBDT05GSUdf
U05EX09QTDRfTElCX1NFUSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TQkFXRV9TRVEgaXMg
bm90IHNldAojIENPTkZJR19TTkRfRU1VMTBLMV9TRVEgaXMgbm90IHNldApDT05GSUdfU05E
X0RSSVZFUlM9eQojIENPTkZJR19TTkRfUENTUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9E
VU1NWSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BTE9PUCBpcyBub3Qgc2V0CiMgQ09ORklH
X1NORF9WSVJNSURJIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01UUEFWIGlzIG5vdCBzZXQK
IyBDT05GSUdfU05EX1NFUklBTF9VMTY1NTAgaXMgbm90IHNldAojIENPTkZJR19TTkRfTVBV
NDAxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1BDSSBpcyBub3Qgc2V0CgojCiMgSEQtQXVk
aW8KIwpDT05GSUdfU05EX1VTQj15CkNPTkZJR19TTkRfVVNCX0FVRElPPXkKQ09ORklHX1NO
RF9VU0JfVUExMDE9eQpDT05GSUdfU05EX1VTQl9VU1gyWT15CkNPTkZJR19TTkRfVVNCX0NB
SUFRPXkKIyBDT05GSUdfU05EX1VTQl9DQUlBUV9JTlBVVCBpcyBub3Qgc2V0CkNPTkZJR19T
TkRfVVNCX1VTMTIyTD15CkNPTkZJR19TTkRfVVNCXzZGSVJFPXkKQ09ORklHX1NORF9VU0Jf
SElGQUNFPXkKIyBDT05GSUdfU05EX0JDRDIwMDAgaXMgbm90IHNldAojIENPTkZJR19TTkRf
U09DIGlzIG5vdCBzZXQKIyBDT05GSUdfU09VTkRfUFJJTUUgaXMgbm90IHNldAoKIwojIEhJ
RCBzdXBwb3J0CiMKQ09ORklHX0hJRD15CiMgQ09ORklHX0hJRF9CQVRURVJZX1NUUkVOR1RI
IGlzIG5vdCBzZXQKQ09ORklHX0hJRFJBVz15CiMgQ09ORklHX1VISUQgaXMgbm90IHNldApD
T05GSUdfSElEX0dFTkVSSUM9eQoKIwojIFNwZWNpYWwgSElEIGRyaXZlcnMKIwpDT05GSUdf
SElEX0E0VEVDSD15CiMgQ09ORklHX0hJRF9BQ1JVWCBpcyBub3Qgc2V0CkNPTkZJR19ISURf
QVBQTEU9eQojIENPTkZJR19ISURfQVBQTEVJUiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9B
VVJFQUwgaXMgbm90IHNldApDT05GSUdfSElEX0JFTEtJTj15CkNPTkZJR19ISURfQ0hFUlJZ
PXkKQ09ORklHX0hJRF9DSElDT05ZPXkKIyBDT05GSUdfSElEX1BST0RJS0VZUyBpcyBub3Qg
c2V0CiMgQ09ORklHX0hJRF9DUDIxMTIgaXMgbm90IHNldApDT05GSUdfSElEX0NZUFJFU1M9
eQojIENPTkZJR19ISURfRFJBR09OUklTRSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9FTVNf
RkYgaXMgbm90IHNldAojIENPTkZJR19ISURfRUxFQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdf
SElEX0VMTyBpcyBub3Qgc2V0CkNPTkZJR19ISURfRVpLRVk9eQojIENPTkZJR19ISURfSE9M
VEVLIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0hVSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdf
SElEX0tFWVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0tZRSBpcyBub3Qgc2V0CiMg
Q09ORklHX0hJRF9VQ0xPR0lDIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1dBTFRPUCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0hJRF9HWVJBVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9J
Q0FERSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9UV0lOSEFOIGlzIG5vdCBzZXQKQ09ORklH
X0hJRF9LRU5TSU5HVE9OPXkKIyBDT05GSUdfSElEX0xDUE9XRVIgaXMgbm90IHNldAojIENP
TkZJR19ISURfTEVOT1ZPX1RQS0JEIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9MT0dJVEVDSD15
CkNPTkZJR19ISURfTE9HSVRFQ0hfREo9eQpDT05GSUdfTE9HSVRFQ0hfRkY9eQpDT05GSUdf
TE9HSVJVTUJMRVBBRDJfRkY9eQpDT05GSUdfTE9HSUc5NDBfRkY9eQpDT05GSUdfTE9HSVdI
RUVMU19GRj15CiMgQ09ORklHX0hJRF9NQUdJQ01PVVNFIGlzIG5vdCBzZXQKQ09ORklHX0hJ
RF9NSUNST1NPRlQ9eQpDT05GSUdfSElEX01PTlRFUkVZPXkKIyBDT05GSUdfSElEX01VTFRJ
VE9VQ0ggaXMgbm90IHNldAojIENPTkZJR19ISURfTlRSSUcgaXMgbm90IHNldAojIENPTkZJ
R19ISURfT1JURUsgaXMgbm90IHNldAojIENPTkZJR19ISURfUEFOVEhFUkxPUkQgaXMgbm90
IHNldAojIENPTkZJR19ISURfUEVUQUxZTlggaXMgbm90IHNldAojIENPTkZJR19ISURfUElD
T0xDRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QUklNQVggaXMgbm90IHNldAojIENPTkZJ
R19ISURfUk9DQ0FUIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NBSVRFSyBpcyBub3Qgc2V0
CiMgQ09ORklHX0hJRF9TQU1TVU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NPTlkgaXMg
bm90IHNldAojIENPTkZJR19ISURfU1BFRURMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE
X1NURUVMU0VSSUVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NVTlBMVVMgaXMgbm90IHNl
dAojIENPTkZJR19ISURfUk1JIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0dSRUVOQVNJQSBp
cyBub3Qgc2V0CiMgQ09ORklHX0hJRF9IWVBFUlZfTU9VU0UgaXMgbm90IHNldAojIENPTkZJ
R19ISURfU01BUlRKT1lQTFVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1RJVk8gaXMgbm90
IHNldAojIENPTkZJR19ISURfVE9QU0VFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9USElO
R00gaXMgbm90IHNldAojIENPTkZJR19ISURfVEhSVVNUTUFTVEVSIGlzIG5vdCBzZXQKIyBD
T05GSUdfSElEX1dBQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1dJSU1PVEUgaXMgbm90
IHNldAojIENPTkZJR19ISURfWElOTU8gaXMgbm90IHNldAojIENPTkZJR19ISURfWkVST1BM
VVMgaXMgbm90IHNldAojIENPTkZJR19ISURfWllEQUNST04gaXMgbm90IHNldApDT05GSUdf
SElEX1NFTlNPUl9IVUI9eQoKIwojIFVTQiBISUQgc3VwcG9ydAojCkNPTkZJR19VU0JfSElE
PXkKQ09ORklHX0hJRF9QSUQ9eQpDT05GSUdfVVNCX0hJRERFVj15CgojCiMgSTJDIEhJRCBz
dXBwb3J0CiMKIyBDT05GSUdfSTJDX0hJRCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfT0hDSV9M
SVRUTEVfRU5ESUFOPXkKQ09ORklHX1VTQl9TVVBQT1JUPXkKQ09ORklHX1VTQl9DT01NT049
eQpDT05GSUdfVVNCX0FSQ0hfSEFTX0hDRD15CkNPTkZJR19VU0I9eQpDT05GSUdfVVNCX0FO
Tk9VTkNFX05FV19ERVZJQ0VTPXkKCiMKIyBNaXNjZWxsYW5lb3VzIFVTQiBvcHRpb25zCiMK
Q09ORklHX1VTQl9ERUZBVUxUX1BFUlNJU1Q9eQpDT05GSUdfVVNCX0RZTkFNSUNfTUlOT1JT
PXkKIyBDT05GSUdfVVNCX09URyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9PVEdfRlNNIGlz
IG5vdCBzZXQKQ09ORklHX1VTQl9NT049eQojIENPTkZJR19VU0JfV1VTQl9DQkFGIGlzIG5v
dCBzZXQKCiMKIyBVU0IgSG9zdCBDb250cm9sbGVyIERyaXZlcnMKIwojIENPTkZJR19VU0Jf
QzY3WDAwX0hDRCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfWEhDSV9IQ0Q9eQpDT05GSUdfVVNC
X0VIQ0lfSENEPXkKQ09ORklHX1VTQl9FSENJX1JPT1RfSFVCX1RUPXkKQ09ORklHX1VTQl9F
SENJX1RUX05FV1NDSEVEPXkKQ09ORklHX1VTQl9FSENJX1BDST15CiMgQ09ORklHX1VTQl9F
SENJX0hDRF9QTEFURk9STSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9PWFUyMTBIUF9IQ0Qg
aXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTE2WF9IQ0QgaXMgbm90IHNldAojIENPTkZJ
R19VU0JfSVNQMTc2MF9IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTM2Ml9IQ0Qg
aXMgbm90IHNldAojIENPTkZJR19VU0JfRlVTQkgyMDBfSENEIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX0ZPVEcyMTBfSENEIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9PSENJX0hDRD15CkNP
TkZJR19VU0JfT0hDSV9IQ0RfUENJPXkKQ09ORklHX1VTQl9PSENJX0hDRF9QTEFURk9STT15
CkNPTkZJR19VU0JfVUhDSV9IQ0Q9eQojIENPTkZJR19VU0JfU0w4MTFfSENEIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX1I4QTY2NTk3X0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9I
Q0RfVEVTVF9NT0RFIGlzIG5vdCBzZXQKCiMKIyBVU0IgRGV2aWNlIENsYXNzIGRyaXZlcnMK
IwojIENPTkZJR19VU0JfQUNNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1BSSU5URVIgaXMg
bm90IHNldAojIENPTkZJR19VU0JfV0RNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1RNQyBp
cyBub3Qgc2V0CgojCiMgTk9URTogVVNCX1NUT1JBR0UgZGVwZW5kcyBvbiBTQ1NJIGJ1dCBC
TEtfREVWX1NEIG1heQojCgojCiMgYWxzbyBiZSBuZWVkZWQ7IHNlZSBVU0JfU1RPUkFHRSBI
ZWxwIGZvciBtb3JlIGluZm8KIwpDT05GSUdfVVNCX1NUT1JBR0U9eQojIENPTkZJR19VU0Jf
U1RPUkFHRV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1JFQUxURUsg
aXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9EQVRBRkFCIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX1NUT1JBR0VfRlJFRUNPTSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9S
QUdFX0lTRDIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1VTQkFUIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfU0REUjA5IGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX1NUT1JBR0VfU0REUjU1IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfSlVN
UFNIT1QgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9BTEFVREEgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfU1RPUkFHRV9PTkVUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9TVE9SQUdFX0tBUk1BIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfQ1lQUkVT
U19BVEFDQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0VORV9VQjYyNTAgaXMg
bm90IHNldAojIENPTkZJR19VU0JfVUFTIGlzIG5vdCBzZXQKCiMKIyBVU0IgSW1hZ2luZyBk
ZXZpY2VzCiMKIyBDT05GSUdfVVNCX01EQzgwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9N
SUNST1RFSyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NVVNCX0hEUkMgaXMgbm90IHNldAoj
IENPTkZJR19VU0JfRFdDMyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9EV0MyIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX0NISVBJREVBIGlzIG5vdCBzZXQKCiMKIyBVU0IgcG9ydCBkcml2
ZXJzCiMKIyBDT05GSUdfVVNCX1NFUklBTCBpcyBub3Qgc2V0CgojCiMgVVNCIE1pc2NlbGxh
bmVvdXMgZHJpdmVycwojCiMgQ09ORklHX1VTQl9FTUk2MiBpcyBub3Qgc2V0CiMgQ09ORklH
X1VTQl9FTUkyNiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9BRFVUVVggaXMgbm90IHNldAoj
IENPTkZJR19VU0JfU0VWU0VHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9MRUdPVE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
TENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0xFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9DWVBSRVNTX0NZN0M2MyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVRIRVJNIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX0lETU9VU0UgaXMgbm90IHNldAojIENPTkZJR19VU0JfRlRE
SV9FTEFOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0FQUExFRElTUExBWSBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9TSVNVU0JWR0EgaXMgbm90IHNldAojIENPTkZJR19VU0JfTEQgaXMg
bm90IHNldAojIENPTkZJR19VU0JfVFJBTkNFVklCUkFUT1IgaXMgbm90IHNldAojIENPTkZJ
R19VU0JfSU9XQVJSSU9SIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1RFU1QgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfRUhTRVRfVEVTVF9GSVhUVVJFIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX0lTSUdIVEZXIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1lVUkVYIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX0VaVVNCX0ZYMiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9IU0lDX1VT
QjM1MDMgaXMgbm90IHNldAoKIwojIFVTQiBQaHlzaWNhbCBMYXllciBkcml2ZXJzCiMKIyBD
T05GSUdfVVNCX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX05PUF9VU0JfWENFSVYgaXMgbm90
IHNldAojIENPTkZJR19TQU1TVU5HX1VTQjJQSFkgaXMgbm90IHNldAojIENPTkZJR19TQU1T
VU5HX1VTQjNQSFkgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1BJT19WQlVTIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX0lTUDEzMDEgaXMgbm90IHNldAojIENPTkZJR19VU0JfR0FER0VU
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVdCIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DIGlzIG5v
dCBzZXQKIyBDT05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldApDT05GSUdfTkVXX0xFRFM9eQpD
T05GSUdfTEVEU19DTEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURTX0xN
MzUzMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNjQyIGlzIG5vdCBzZXQKQ09ORklH
X0xFRFNfUENBOTUzMj15CiMgQ09ORklHX0xFRFNfUENBOTUzMl9HUElPIGlzIG5vdCBzZXQK
IyBDT05GSUdfTEVEU19HUElPIGlzIG5vdCBzZXQKQ09ORklHX0xFRFNfTFAzOTQ0PXkKIyBD
T05GSUdfTEVEU19MUDU1MjEgaXMgbm90IHNldAojIENPTkZJR19MRURTX0xQNTUyMyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0xFRFNfTFA1NTYyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19M
UDg1MDEgaXMgbm90IHNldApDT05GSUdfTEVEU19DTEVWT19NQUlMPXkKQ09ORklHX0xFRFNf
UENBOTU1WD15CiMgQ09ORklHX0xFRFNfUENBOTYzWCBpcyBub3Qgc2V0CkNPTkZJR19MRURT
X0JEMjgwMj15CkNPTkZJR19MRURTX0lOVEVMX1NTNDIwMD15CkNPTkZJR19MRURTX0xUMzU5
Mz15CiMgQ09ORklHX0xFRFNfREVMTF9ORVRCT09LUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xF
RFNfVENBNjUwNyBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNTV4IGlzIG5vdCBzZXQK
CiMKIyBMRUQgZHJpdmVyIGZvciBibGluaygxKSBVU0IgUkdCIExFRCBpcyB1bmRlciBTcGVj
aWFsIEhJRCBkcml2ZXJzIChISURfVEhJTkdNKQojCiMgQ09ORklHX0xFRFNfQkxJTktNIGlz
IG5vdCBzZXQKCiMKIyBMRUQgVHJpZ2dlcnMKIwpDT05GSUdfTEVEU19UUklHR0VSUz15CkNP
TkZJR19MRURTX1RSSUdHRVJfVElNRVI9eQojIENPTkZJR19MRURTX1RSSUdHRVJfT05FU0hP
VCBpcyBub3Qgc2V0CkNPTkZJR19MRURTX1RSSUdHRVJfSEVBUlRCRUFUPXkKQ09ORklHX0xF
RFNfVFJJR0dFUl9CQUNLTElHSFQ9eQojIENPTkZJR19MRURTX1RSSUdHRVJfQ1BVIGlzIG5v
dCBzZXQKIyBDT05GSUdfTEVEU19UUklHR0VSX0dQSU8gaXMgbm90IHNldApDT05GSUdfTEVE
U19UUklHR0VSX0RFRkFVTFRfT049eQoKIwojIGlwdGFibGVzIHRyaWdnZXIgaXMgdW5kZXIg
TmV0ZmlsdGVyIGNvbmZpZyAoTEVEIHRhcmdldCkKIwojIENPTkZJR19MRURTX1RSSUdHRVJf
VFJBTlNJRU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19UUklHR0VSX0NBTUVSQSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0FDQ0VTU0lCSUxJVFkgaXMgbm90IHNldAojIENPTkZJR19JTkZJ
TklCQU5EIGlzIG5vdCBzZXQKIyBDT05GSUdfRURBQyBpcyBub3Qgc2V0CkNPTkZJR19SVENf
TElCPXkKQ09ORklHX1JUQ19DTEFTUz15CkNPTkZJR19SVENfSENUT1NZUz15CkNPTkZJR19S
VENfU1lTVE9IQz15CkNPTkZJR19SVENfSENUT1NZU19ERVZJQ0U9InJ0YzAiCiMgQ09ORklH
X1JUQ19ERUJVRyBpcyBub3Qgc2V0CgojCiMgUlRDIGludGVyZmFjZXMKIwpDT05GSUdfUlRD
X0lOVEZfU1lTRlM9eQpDT05GSUdfUlRDX0lOVEZfUFJPQz15CkNPTkZJR19SVENfSU5URl9E
RVY9eQojIENPTkZJR19SVENfSU5URl9ERVZfVUlFX0VNVUwgaXMgbm90IHNldAojIENPTkZJ
R19SVENfRFJWX1RFU1QgaXMgbm90IHNldAoKIwojIEkyQyBSVEMgZHJpdmVycwojCkNPTkZJ
R19SVENfRFJWX0RTMTMwNz15CkNPTkZJR19SVENfRFJWX0RTMTM3ND15CkNPTkZJR19SVENf
RFJWX0RTMTY3Mj15CiMgQ09ORklHX1JUQ19EUlZfRFMzMjMyIGlzIG5vdCBzZXQKQ09ORklH
X1JUQ19EUlZfTUFYNjkwMD15CkNPTkZJR19SVENfRFJWX1JTNUMzNzI9eQpDT05GSUdfUlRD
X0RSVl9JU0wxMjA4PXkKIyBDT05GSUdfUlRDX0RSVl9JU0wxMjAyMiBpcyBub3Qgc2V0CiMg
Q09ORklHX1JUQ19EUlZfSVNMMTIwNTcgaXMgbm90IHNldApDT05GSUdfUlRDX0RSVl9YMTIw
NT15CiMgQ09ORklHX1JUQ19EUlZfUENGMjEyNyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19E
UlZfUENGODUyMyBpcyBub3Qgc2V0CkNPTkZJR19SVENfRFJWX1BDRjg1NjM9eQpDT05GSUdf
UlRDX0RSVl9QQ0Y4NTgzPXkKQ09ORklHX1JUQ19EUlZfTTQxVDgwPXkKIyBDT05GSUdfUlRD
X0RSVl9NNDFUODBfV0RUIGlzIG5vdCBzZXQKQ09ORklHX1JUQ19EUlZfQlEzMks9eQpDT05G
SUdfUlRDX0RSVl9TMzUzOTBBPXkKQ09ORklHX1JUQ19EUlZfRk0zMTMwPXkKQ09ORklHX1JU
Q19EUlZfUlg4NTgxPXkKQ09ORklHX1JUQ19EUlZfUlg4MDI1PXkKIyBDT05GSUdfUlRDX0RS
Vl9FTTMwMjcgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1JWMzAyOUMyIGlzIG5vdCBz
ZXQKCiMKIyBTUEkgUlRDIGRyaXZlcnMKIwoKIwojIFBsYXRmb3JtIFJUQyBkcml2ZXJzCiMK
Q09ORklHX1JUQ19EUlZfQ01PUz15CkNPTkZJR19SVENfRFJWX0RTMTI4Nj15CkNPTkZJR19S
VENfRFJWX0RTMTUxMT15CkNPTkZJR19SVENfRFJWX0RTMTU1Mz15CkNPTkZJR19SVENfRFJW
X0RTMTc0Mj15CkNPTkZJR19SVENfRFJWX1NUSzE3VEE4PXkKQ09ORklHX1JUQ19EUlZfTTQ4
VDg2PXkKQ09ORklHX1JUQ19EUlZfTTQ4VDM1PXkKQ09ORklHX1JUQ19EUlZfTTQ4VDU5PXkK
Q09ORklHX1JUQ19EUlZfTVNNNjI0Mj15CkNPTkZJR19SVENfRFJWX0JRNDgwMj15CkNPTkZJ
R19SVENfRFJWX1JQNUMwMT15CkNPTkZJR19SVENfRFJWX1YzMDIwPXkKQ09ORklHX1JUQ19E
UlZfRFMyNDA0PXkKIyBDT05GSUdfUlRDX0RSVl9QQ0Y1MDYzMyBpcyBub3Qgc2V0CgojCiMg
b24tQ1BVIFJUQyBkcml2ZXJzCiMKIyBDT05GSUdfUlRDX0RSVl9NT1hBUlQgaXMgbm90IHNl
dAojIENPTkZJR19SVENfRFJWX1hHRU5FIGlzIG5vdCBzZXQKCiMKIyBISUQgU2Vuc29yIFJU
QyBkcml2ZXJzCiMKQ09ORklHX1JUQ19EUlZfSElEX1NFTlNPUl9USU1FPXkKQ09ORklHX0RN
QURFVklDRVM9eQojIENPTkZJR19ETUFERVZJQ0VTX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBE
TUEgRGV2aWNlcwojCiMgQ09ORklHX0lOVEVMX01JRF9ETUFDIGlzIG5vdCBzZXQKQ09ORklH
X0lOVEVMX0lPQVRETUE9eQojIENPTkZJR19EV19ETUFDX0NPUkUgaXMgbm90IHNldAojIENP
TkZJR19EV19ETUFDIGlzIG5vdCBzZXQKIyBDT05GSUdfRFdfRE1BQ19QQ0kgaXMgbm90IHNl
dApDT05GSUdfRE1BX0VOR0lORT15CkNPTkZJR19ETUFfQUNQST15CgojCiMgRE1BIENsaWVu
dHMKIwpDT05GSUdfQVNZTkNfVFhfRE1BPXkKIyBDT05GSUdfRE1BVEVTVCBpcyBub3Qgc2V0
CkNPTkZJR19ETUFfRU5HSU5FX1JBSUQ9eQpDT05GSUdfRENBPXkKIyBDT05GSUdfQVVYRElT
UExBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1VJTyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZGSU8g
aXMgbm90IHNldAojIENPTkZJR19WSVJUX0RSSVZFUlMgaXMgbm90IHNldApDT05GSUdfVklS
VElPPXkKCiMKIyBWaXJ0aW8gZHJpdmVycwojCkNPTkZJR19WSVJUSU9fUENJPXkKQ09ORklH
X1ZJUlRJT19CQUxMT09OPXkKIyBDT05GSUdfVklSVElPX01NSU8gaXMgbm90IHNldAoKIwoj
IE1pY3Jvc29mdCBIeXBlci1WIGd1ZXN0IHN1cHBvcnQKIwpDT05GSUdfSFlQRVJWPXkKQ09O
RklHX0hZUEVSVl9VVElMUz15CiMgQ09ORklHX0hZUEVSVl9CQUxMT09OIGlzIG5vdCBzZXQK
CiMKIyBYZW4gZHJpdmVyIHN1cHBvcnQKIwpDT05GSUdfWEVOX0JBTExPT049eQpDT05GSUdf
WEVOX1NDUlVCX1BBR0VTPXkKQ09ORklHX1hFTl9ERVZfRVZUQ0hOPXkKQ09ORklHX1hFTl9C
QUNLRU5EPXkKQ09ORklHX1hFTkZTPXkKQ09ORklHX1hFTl9DT01QQVRfWEVORlM9eQpDT05G
SUdfWEVOX1NZU19IWVBFUlZJU09SPXkKQ09ORklHX1hFTl9YRU5CVVNfRlJPTlRFTkQ9eQpD
T05GSUdfWEVOX0dOVERFVj15CkNPTkZJR19YRU5fR1JBTlRfREVWX0FMTE9DPXkKQ09ORklH
X1NXSU9UTEJfWEVOPXkKQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VORD15CkNPTkZJR19YRU5f
UFJJVkNNRD15CkNPTkZJR19YRU5fQUNQSV9QUk9DRVNTT1I9eQojIENPTkZJR19YRU5fTUNF
X0xPRyBpcyBub3Qgc2V0CkNPTkZJR19YRU5fSEFWRV9QVk1NVT15CiMgQ09ORklHX1NUQUdJ
TkcgaXMgbm90IHNldApDT05GSUdfWDg2X1BMQVRGT1JNX0RFVklDRVM9eQojIENPTkZJR19B
Q0VSX1dNSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FDRVJIREYgaXMgbm90IHNldAojIENPTkZJ
R19BTElFTldBUkVfV01JIGlzIG5vdCBzZXQKIyBDT05GSUdfQVNVU19MQVBUT1AgaXMgbm90
IHNldAojIENPTkZJR19ERUxMX1dNSSBpcyBub3Qgc2V0CiMgQ09ORklHX0RFTExfV01JX0FJ
TyBpcyBub3Qgc2V0CiMgQ09ORklHX0RFTExfU01PODgwMCBpcyBub3Qgc2V0CiMgQ09ORklH
X0ZVSklUU1VfTEFQVE9QIGlzIG5vdCBzZXQKIyBDT05GSUdfRlVKSVRTVV9UQUJMRVQgaXMg
bm90IHNldAojIENPTkZJR19BTUlMT19SRktJTEwgaXMgbm90IHNldAojIENPTkZJR19IUF9B
Q0NFTCBpcyBub3Qgc2V0CiMgQ09ORklHX0hQX1dJUkVMRVNTIGlzIG5vdCBzZXQKIyBDT05G
SUdfSFBfV01JIGlzIG5vdCBzZXQKIyBDT05GSUdfTVNJX0xBUFRPUCBpcyBub3Qgc2V0CiMg
Q09ORklHX1BBTkFTT05JQ19MQVBUT1AgaXMgbm90IHNldAojIENPTkZJR19DT01QQUxfTEFQ
VE9QIGlzIG5vdCBzZXQKIyBDT05GSUdfU09OWV9MQVBUT1AgaXMgbm90IHNldAojIENPTkZJ
R19JREVBUEFEX0xBUFRPUCBpcyBub3Qgc2V0CiMgQ09ORklHX1RISU5LUEFEX0FDUEkgaXMg
bm90IHNldAojIENPTkZJR19TRU5TT1JTX0hEQVBTIGlzIG5vdCBzZXQKQ09ORklHX0lOVEVM
X01FTkxPVz15CiMgQ09ORklHX0VFRVBDX0xBUFRPUCBpcyBub3Qgc2V0CiMgQ09ORklHX0FT
VVNfV01JIGlzIG5vdCBzZXQKQ09ORklHX0FDUElfV01JPXkKIyBDT05GSUdfTVNJX1dNSSBp
cyBub3Qgc2V0CiMgQ09ORklHX1RPUFNUQVJfTEFQVE9QIGlzIG5vdCBzZXQKIyBDT05GSUdf
QUNQSV9UT1NISUJBIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9TSElCQV9CVF9SRktJTEwgaXMg
bm90IHNldAojIENPTkZJR19BQ1BJX0NNUEMgaXMgbm90IHNldAojIENPTkZJR19JTlRFTF9J
UFMgaXMgbm90IHNldAojIENPTkZJR19JQk1fUlRMIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FN
U1VOR19MQVBUT1AgaXMgbm90IHNldApDT05GSUdfTVhNX1dNST15CiMgQ09ORklHX0lOVEVM
X09BS1RSQUlMIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FNU1VOR19RMTAgaXMgbm90IHNldAoj
IENPTkZJR19BUFBMRV9HTVVYIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5URUxfUlNUIGlzIG5v
dCBzZXQKIyBDT05GSUdfSU5URUxfU01BUlRDT05ORUNUIGlzIG5vdCBzZXQKIyBDT05GSUdf
UFZQQU5JQyBpcyBub3Qgc2V0CiMgQ09ORklHX0NIUk9NRV9QTEFURk9STVMgaXMgbm90IHNl
dAoKIwojIFNPQyAoU3lzdGVtIE9uIENoaXApIHNwZWNpZmljIERyaXZlcnMKIwoKIwojIEhh
cmR3YXJlIFNwaW5sb2NrIGRyaXZlcnMKIwpDT05GSUdfQ0xLRVZUX0k4MjUzPXkKQ09ORklH
X0k4MjUzX0xPQ0s9eQpDT05GSUdfQ0xLQkxEX0k4MjUzPXkKIyBDT05GSUdfU0hfVElNRVJf
Q01UIGlzIG5vdCBzZXQKIyBDT05GSUdfU0hfVElNRVJfTVRVMiBpcyBub3Qgc2V0CiMgQ09O
RklHX1NIX1RJTUVSX1RNVSBpcyBub3Qgc2V0CiMgQ09ORklHX0VNX1RJTUVSX1NUSSBpcyBu
b3Qgc2V0CiMgQ09ORklHX01BSUxCT1ggaXMgbm90IHNldApDT05GSUdfSU9NTVVfQVBJPXkK
Q09ORklHX0lPTU1VX1NVUFBPUlQ9eQpDT05GSUdfQU1EX0lPTU1VPXkKIyBDT05GSUdfQU1E
X0lPTU1VX1NUQVRTIGlzIG5vdCBzZXQKQ09ORklHX0RNQVJfVEFCTEU9eQpDT05GSUdfSU5U
RUxfSU9NTVU9eQojIENPTkZJR19JTlRFTF9JT01NVV9ERUZBVUxUX09OIGlzIG5vdCBzZXQK
Q09ORklHX0lOVEVMX0lPTU1VX0ZMT1BQWV9XQT15CkNPTkZJR19JUlFfUkVNQVA9eQoKIwoj
IFJlbW90ZXByb2MgZHJpdmVycwojCiMgQ09ORklHX1NURV9NT0RFTV9SUFJPQyBpcyBub3Qg
c2V0CgojCiMgUnBtc2cgZHJpdmVycwojCiMgQ09ORklHX1BNX0RFVkZSRVEgaXMgbm90IHNl
dAojIENPTkZJR19FWFRDT04gaXMgbm90IHNldAojIENPTkZJR19NRU1PUlkgaXMgbm90IHNl
dApDT05GSUdfSUlPPXkKIyBDT05GSUdfSUlPX0JVRkZFUiBpcyBub3Qgc2V0CiMgQ09ORklH
X0lJT19UUklHR0VSIGlzIG5vdCBzZXQKCiMKIyBBY2NlbGVyb21ldGVycwojCiMgQ09ORklH
X0JNQTE4MCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TRU5TT1JfQUNDRUxfM0QgaXMgbm90
IHNldAojIENPTkZJR19JSU9fU1RfQUNDRUxfM0FYSVMgaXMgbm90IHNldAojIENPTkZJR19N
TUE4NDUyIGlzIG5vdCBzZXQKCiMKIyBBbmFsb2cgdG8gZGlnaXRhbCBjb252ZXJ0ZXJzCiMK
IyBDT05GSUdfQUQ3OTlYIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFYMTM2MyBpcyBub3Qgc2V0
CiMgQ09ORklHX01DUDM0MjIgaXMgbm90IHNldAojIENPTkZJR19OQVU3ODAyIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVElfQURDMDgxQyBpcyBub3Qgc2V0CgojCiMgQW1wbGlmaWVycwojCgoj
CiMgSGlkIFNlbnNvciBJSU8gQ29tbW9uCiMKQ09ORklHX0hJRF9TRU5TT1JfSUlPX0NPTU1P
Tj15CiMgQ09ORklHX0hJRF9TRU5TT1JfSUlPX1RSSUdHRVIgaXMgbm90IHNldAoKIwojIERp
Z2l0YWwgdG8gYW5hbG9nIGNvbnZlcnRlcnMKIwojIENPTkZJR19BRDUwNjQgaXMgbm90IHNl
dAojIENPTkZJR19BRDUzODAgaXMgbm90IHNldAojIENPTkZJR19BRDU0NDYgaXMgbm90IHNl
dAojIENPTkZJR19NQVg1MTcgaXMgbm90IHNldAojIENPTkZJR19NQ1A0NzI1IGlzIG5vdCBz
ZXQKCiMKIyBGcmVxdWVuY3kgU3ludGhlc2l6ZXJzIEREUy9QTEwKIwoKIwojIENsb2NrIEdl
bmVyYXRvci9EaXN0cmlidXRpb24KIwoKIwojIFBoYXNlLUxvY2tlZCBMb29wIChQTEwpIGZy
ZXF1ZW5jeSBzeW50aGVzaXplcnMKIwoKIwojIERpZ2l0YWwgZ3lyb3Njb3BlIHNlbnNvcnMK
IwojIENPTkZJR19ISURfU0VOU09SX0dZUk9fM0QgaXMgbm90IHNldAojIENPTkZJR19JSU9f
U1RfR1lST18zQVhJUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lURzMyMDAgaXMgbm90IHNldAoK
IwojIEh1bWlkaXR5IHNlbnNvcnMKIwojIENPTkZJR19ESFQxMSBpcyBub3Qgc2V0CiMgQ09O
RklHX1NJNzAwNSBpcyBub3Qgc2V0CgojCiMgSW5lcnRpYWwgbWVhc3VyZW1lbnQgdW5pdHMK
IwojIENPTkZJR19JTlZfTVBVNjA1MF9JSU8gaXMgbm90IHNldAoKIwojIExpZ2h0IHNlbnNv
cnMKIwojIENPTkZJR19BREpEX1MzMTEgaXMgbm90IHNldAojIENPTkZJR19BUERTOTMwMCBp
cyBub3Qgc2V0CiMgQ09ORklHX0NNMzIxODEgaXMgbm90IHNldAojIENPTkZJR19DTTM2NjUx
IGlzIG5vdCBzZXQKIyBDT05GSUdfR1AyQVAwMjBBMDBGIGlzIG5vdCBzZXQKIyBDT05GSUdf
SElEX1NFTlNPUl9BTFMgaXMgbm90IHNldAojIENPTkZJR19ISURfU0VOU09SX1BST1ggaXMg
bm90IHNldAojIENPTkZJR19MVFI1MDEgaXMgbm90IHNldAojIENPTkZJR19UQ1MzNDcyIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19UU0wyNTYzIGlzIG5vdCBzZXQKIyBDT05GSUdf
VFNMNDUzMSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZDTkw0MDAwIGlzIG5vdCBzZXQKCiMKIyBN
YWduZXRvbWV0ZXIgc2Vuc29ycwojCiMgQ09ORklHX0FLODk3NSBpcyBub3Qgc2V0CiMgQ09O
RklHX01BRzMxMTAgaXMgbm90IHNldAojIENPTkZJR19ISURfU0VOU09SX01BR05FVE9NRVRF
Ul8zRCBpcyBub3Qgc2V0CiMgQ09ORklHX0lJT19TVF9NQUdOXzNBWElTIGlzIG5vdCBzZXQK
CiMKIyBJbmNsaW5vbWV0ZXIgc2Vuc29ycwojCiMgQ09ORklHX0hJRF9TRU5TT1JfSU5DTElO
T01FVEVSXzNEIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NFTlNPUl9ERVZJQ0VfUk9UQVRJ
T04gaXMgbm90IHNldAoKIwojIFByZXNzdXJlIHNlbnNvcnMKIwojIENPTkZJR19ISURfU0VO
U09SX1BSRVNTIGlzIG5vdCBzZXQKIyBDT05GSUdfTVBMMTE1IGlzIG5vdCBzZXQKIyBDT05G
SUdfTVBMMzExNSBpcyBub3Qgc2V0CiMgQ09ORklHX0lJT19TVF9QUkVTUyBpcyBub3Qgc2V0
CgojCiMgTGlnaHRuaW5nIHNlbnNvcnMKIwoKIwojIFRlbXBlcmF0dXJlIHNlbnNvcnMKIwoj
IENPTkZJR19NTFg5MDYxNCBpcyBub3Qgc2V0CiMgQ09ORklHX1RNUDAwNiBpcyBub3Qgc2V0
CiMgQ09ORklHX05UQiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZNRV9CVVMgaXMgbm90IHNldAoj
IENPTkZJR19QV00gaXMgbm90IHNldAojIENPTkZJR19JUEFDS19CVVMgaXMgbm90IHNldAoj
IENPTkZJR19SRVNFVF9DT05UUk9MTEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfRk1DIGlzIG5v
dCBzZXQKCiMKIyBQSFkgU3Vic3lzdGVtCiMKIyBDT05GSUdfR0VORVJJQ19QSFkgaXMgbm90
IHNldAojIENPTkZJR19CQ01fS09OQV9VU0IyX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX1BI
WV9TQU1TVU5HX1VTQjIgaXMgbm90IHNldAojIENPTkZJR19QT1dFUkNBUCBpcyBub3Qgc2V0
CiMgQ09ORklHX01DQiBpcyBub3Qgc2V0CgojCiMgRmlybXdhcmUgRHJpdmVycwojCiMgQ09O
RklHX0VERCBpcyBub3Qgc2V0CkNPTkZJR19GSVJNV0FSRV9NRU1NQVA9eQojIENPTkZJR19E
RUxMX1JCVSBpcyBub3Qgc2V0CiMgQ09ORklHX0RDREJBUyBpcyBub3Qgc2V0CiMgQ09ORklH
X0RNSUlEIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1JX1NZU0ZTIGlzIG5vdCBzZXQKQ09ORklH
X0RNSV9TQ0FOX01BQ0hJTkVfTk9OX0VGSV9GQUxMQkFDSz15CiMgQ09ORklHX0lTQ1NJX0lC
RlRfRklORCBpcyBub3Qgc2V0CiMgQ09ORklHX0dPT0dMRV9GSVJNV0FSRSBpcyBub3Qgc2V0
CgojCiMgRUZJIChFeHRlbnNpYmxlIEZpcm13YXJlIEludGVyZmFjZSkgU3VwcG9ydAojCiMg
Q09ORklHX0VGSV9WQVJTIGlzIG5vdCBzZXQKQ09ORklHX0VGSV9SVU5USU1FX01BUD15Cgoj
CiMgRmlsZSBzeXN0ZW1zCiMKQ09ORklHX0RDQUNIRV9XT1JEX0FDQ0VTUz15CkNPTkZJR19F
WFQyX0ZTPXkKQ09ORklHX0VYVDJfRlNfWEFUVFI9eQpDT05GSUdfRVhUMl9GU19QT1NJWF9B
Q0w9eQpDT05GSUdfRVhUMl9GU19TRUNVUklUWT15CiMgQ09ORklHX0VYVDJfRlNfWElQIGlz
IG5vdCBzZXQKQ09ORklHX0VYVDNfRlM9eQpDT05GSUdfRVhUM19ERUZBVUxUU19UT19PUkRF
UkVEPXkKQ09ORklHX0VYVDNfRlNfWEFUVFI9eQpDT05GSUdfRVhUM19GU19QT1NJWF9BQ0w9
eQpDT05GSUdfRVhUM19GU19TRUNVUklUWT15CkNPTkZJR19FWFQ0X0ZTPXkKQ09ORklHX0VY
VDRfRlNfUE9TSVhfQUNMPXkKQ09ORklHX0VYVDRfRlNfU0VDVVJJVFk9eQojIENPTkZJR19F
WFQ0X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0pCRD15CkNPTkZJR19KQkQyPXkKIyBDT05G
SUdfSkJEMl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19GU19NQkNBQ0hFPXkKIyBDT05GSUdf
UkVJU0VSRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19KRlNfRlMgaXMgbm90IHNldAojIENP
TkZJR19YRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19HRlMyX0ZTIGlzIG5vdCBzZXQKQ09O
RklHX0JUUkZTX0ZTPXkKQ09ORklHX0JUUkZTX0ZTX1BPU0lYX0FDTD15CiMgQ09ORklHX0JU
UkZTX0ZTX0NIRUNLX0lOVEVHUklUWSBpcyBub3Qgc2V0CiMgQ09ORklHX0JUUkZTX0ZTX1JV
Tl9TQU5JVFlfVEVTVFMgaXMgbm90IHNldAojIENPTkZJR19CVFJGU19ERUJVRyBpcyBub3Qg
c2V0CiMgQ09ORklHX0JUUkZTX0FTU0VSVCBpcyBub3Qgc2V0CiMgQ09ORklHX05JTEZTMl9G
UyBpcyBub3Qgc2V0CkNPTkZJR19GU19QT1NJWF9BQ0w9eQpDT05GSUdfRVhQT1JURlM9eQpD
T05GSUdfRklMRV9MT0NLSU5HPXkKQ09ORklHX0ZTTk9USUZZPXkKQ09ORklHX0ROT1RJRlk9
eQpDT05GSUdfSU5PVElGWV9VU0VSPXkKQ09ORklHX0ZBTk9USUZZPXkKIyBDT05GSUdfRkFO
T1RJRllfQUNDRVNTX1BFUk1JU1NJT05TIGlzIG5vdCBzZXQKQ09ORklHX1FVT1RBPXkKQ09O
RklHX1FVT1RBX05FVExJTktfSU5URVJGQUNFPXkKQ09ORklHX1BSSU5UX1FVT1RBX1dBUk5J
Tkc9eQojIENPTkZJR19RVU9UQV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1FGTVRfVjEg
aXMgbm90IHNldAojIENPTkZJR19RRk1UX1YyIGlzIG5vdCBzZXQKQ09ORklHX1FVT1RBQ1RM
PXkKQ09ORklHX0FVVE9GUzRfRlM9eQpDT05GSUdfRlVTRV9GUz15CiMgQ09ORklHX0NVU0Ug
aXMgbm90IHNldAoKIwojIENhY2hlcwojCkNPTkZJR19GU0NBQ0hFPXkKQ09ORklHX0ZTQ0FD
SEVfU1RBVFM9eQojIENPTkZJR19GU0NBQ0hFX0hJU1RPR1JBTSBpcyBub3Qgc2V0CiMgQ09O
RklHX0ZTQ0FDSEVfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19GU0NBQ0hFX09CSkVDVF9M
SVNUIGlzIG5vdCBzZXQKQ09ORklHX0NBQ0hFRklMRVM9eQojIENPTkZJR19DQUNIRUZJTEVT
X0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FDSEVGSUxFU19ISVNUT0dSQU0gaXMgbm90
IHNldAoKIwojIENELVJPTS9EVkQgRmlsZXN5c3RlbXMKIwojIENPTkZJR19JU085NjYwX0ZT
IGlzIG5vdCBzZXQKIyBDT05GSUdfVURGX0ZTIGlzIG5vdCBzZXQKCiMKIyBET1MvRkFUL05U
IEZpbGVzeXN0ZW1zCiMKQ09ORklHX0ZBVF9GUz15CkNPTkZJR19NU0RPU19GUz15CkNPTkZJ
R19WRkFUX0ZTPXkKQ09ORklHX0ZBVF9ERUZBVUxUX0NPREVQQUdFPTQzNwpDT05GSUdfRkFU
X0RFRkFVTFRfSU9DSEFSU0VUPSJ1dGY4IgpDT05GSUdfTlRGU19GUz15CiMgQ09ORklHX05U
RlNfREVCVUcgaXMgbm90IHNldApDT05GSUdfTlRGU19SVz15CgojCiMgUHNldWRvIGZpbGVz
eXN0ZW1zCiMKQ09ORklHX1BST0NfRlM9eQpDT05GSUdfUFJPQ19LQ09SRT15CkNPTkZJR19Q
Uk9DX1ZNQ09SRT15CkNPTkZJR19QUk9DX1NZU0NUTD15CkNPTkZJR19QUk9DX1BBR0VfTU9O
SVRPUj15CkNPTkZJR19LRVJORlM9eQpDT05GSUdfU1lTRlM9eQpDT05GSUdfVE1QRlM9eQpD
T05GSUdfVE1QRlNfUE9TSVhfQUNMPXkKQ09ORklHX1RNUEZTX1hBVFRSPXkKQ09ORklHX0hV
R0VUTEJGUz15CkNPTkZJR19IVUdFVExCX1BBR0U9eQojIENPTkZJR19DT05GSUdGU19GUyBp
cyBub3Qgc2V0CkNPTkZJR19NSVNDX0ZJTEVTWVNURU1TPXkKIyBDT05GSUdfQURGU19GUyBp
cyBub3Qgc2V0CiMgQ09ORklHX0FGRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19FQ1JZUFRf
RlMgaXMgbm90IHNldAojIENPTkZJR19IRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19IRlNQ
TFVTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQkVGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklH
X0JGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0VGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklH
X0xPR0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JBTUZTIGlzIG5vdCBzZXQKQ09ORklHX1NR
VUFTSEZTPXkKQ09ORklHX1NRVUFTSEZTX0ZJTEVfQ0FDSEU9eQojIENPTkZJR19TUVVBU0hG
U19GSUxFX0RJUkVDVCBpcyBub3Qgc2V0CkNPTkZJR19TUVVBU0hGU19ERUNPTVBfU0lOR0xF
PXkKIyBDT05GSUdfU1FVQVNIRlNfREVDT01QX01VTFRJIGlzIG5vdCBzZXQKIyBDT05GSUdf
U1FVQVNIRlNfREVDT01QX01VTFRJX1BFUkNQVSBpcyBub3Qgc2V0CiMgQ09ORklHX1NRVUFT
SEZTX1hBVFRSIGlzIG5vdCBzZXQKQ09ORklHX1NRVUFTSEZTX1pMSUI9eQpDT05GSUdfU1FV
QVNIRlNfTFpPPXkKQ09ORklHX1NRVUFTSEZTX1haPXkKIyBDT05GSUdfU1FVQVNIRlNfNEtf
REVWQkxLX1NJWkUgaXMgbm90IHNldAojIENPTkZJR19TUVVBU0hGU19FTUJFRERFRCBpcyBu
b3Qgc2V0CkNPTkZJR19TUVVBU0hGU19GUkFHTUVOVF9DQUNIRV9TSVpFPTMKIyBDT05GSUdf
VlhGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX01JTklYX0ZTIGlzIG5vdCBzZXQKIyBDT05G
SUdfT01GU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hQRlNfRlMgaXMgbm90IHNldAojIENP
TkZJR19RTlg0RlNfRlMgaXMgbm90IHNldAojIENPTkZJR19RTlg2RlNfRlMgaXMgbm90IHNl
dAojIENPTkZJR19ST01GU19GUyBpcyBub3Qgc2V0CkNPTkZJR19QU1RPUkU9eQojIENPTkZJ
R19QU1RPUkVfQ09OU09MRSBpcyBub3Qgc2V0CiMgQ09ORklHX1BTVE9SRV9SQU0gaXMgbm90
IHNldAojIENPTkZJR19TWVNWX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfVUZTX0ZTIGlzIG5v
dCBzZXQKIyBDT05GSUdfRjJGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0VGSVZBUl9GUyBp
cyBub3Qgc2V0CiMgQ09ORklHX05FVFdPUktfRklMRVNZU1RFTVMgaXMgbm90IHNldApDT05G
SUdfTkxTPXkKQ09ORklHX05MU19ERUZBVUxUPSJ1dGY4IgpDT05GSUdfTkxTX0NPREVQQUdF
XzQzNz15CiMgQ09ORklHX05MU19DT0RFUEFHRV83MzcgaXMgbm90IHNldAojIENPTkZJR19O
TFNfQ09ERVBBR0VfNzc1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1MCBp
cyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTIgaXMgbm90IHNldAojIENPTkZJ
R19OTFNfQ09ERVBBR0VfODU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1
NyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjAgaXMgbm90IHNldAojIENP
TkZJR19OTFNfQ09ERVBBR0VfODYxIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdF
Xzg2MiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjMgaXMgbm90IHNldAoj
IENPTkZJR19OTFNfQ09ERVBBR0VfODY0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQ
QUdFXzg2NSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjYgaXMgbm90IHNl
dAojIENPTkZJR19OTFNfQ09ERVBBR0VfODY5IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NP
REVQQUdFXzkzNiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV85NTAgaXMgbm90
IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfOTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxT
X0NPREVQQUdFXzk0OSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NzQgaXMg
bm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV84IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxT
X0NPREVQQUdFXzEyNTAgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfMTI1MSBp
cyBub3Qgc2V0CkNPTkZJR19OTFNfQVNDSUk9eQpDT05GSUdfTkxTX0lTTzg4NTlfMT15CiMg
Q09ORklHX05MU19JU084ODU5XzIgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8z
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfNCBpcyBub3Qgc2V0CiMgQ09ORklH
X05MU19JU084ODU5XzUgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV82IGlzIG5v
dCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfNyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19J
U084ODU5XzkgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8xMyBpcyBub3Qgc2V0
CiMgQ09ORklHX05MU19JU084ODU5XzE0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4
NTlfMTUgaXMgbm90IHNldAojIENPTkZJR19OTFNfS09JOF9SIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkxTX0tPSThfVSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfUk9NQU4gaXMgbm90
IHNldAojIENPTkZJR19OTFNfTUFDX0NFTFRJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19N
QUNfQ0VOVEVVUk8gaXMgbm90IHNldAojIENPTkZJR19OTFNfTUFDX0NST0FUSUFOIGlzIG5v
dCBzZXQKIyBDT05GSUdfTkxTX01BQ19DWVJJTExJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05M
U19NQUNfR0FFTElDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19HUkVFSyBpcyBub3Qg
c2V0CiMgQ09ORklHX05MU19NQUNfSUNFTEFORCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19N
QUNfSU5VSVQgaXMgbm90IHNldAojIENPTkZJR19OTFNfTUFDX1JPTUFOSUFOIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkxTX01BQ19UVVJLSVNIIGlzIG5vdCBzZXQKQ09ORklHX05MU19VVEY4
PXkKCiMKIyBLZXJuZWwgaGFja2luZwojCkNPTkZJR19UUkFDRV9JUlFGTEFHU19TVVBQT1JU
PXkKCiMKIyBwcmludGsgYW5kIGRtZXNnIG9wdGlvbnMKIwpDT05GSUdfUFJJTlRLX1RJTUU9
eQpDT05GSUdfREVGQVVMVF9NRVNTQUdFX0xPR0xFVkVMPTQKQ09ORklHX0JPT1RfUFJJTlRL
X0RFTEFZPXkKCiMKIyBDb21waWxlLXRpbWUgY2hlY2tzIGFuZCBjb21waWxlciBvcHRpb25z
CiMKQ09ORklHX0RFQlVHX0lORk89eQojIENPTkZJR19ERUJVR19JTkZPX1JFRFVDRUQgaXMg
bm90IHNldApDT05GSUdfRU5BQkxFX1dBUk5fREVQUkVDQVRFRD15CkNPTkZJR19FTkFCTEVf
TVVTVF9DSEVDSz15CkNPTkZJR19GUkFNRV9XQVJOPTIwNDgKQ09ORklHX1NUUklQX0FTTV9T
WU1TPXkKIyBDT05GSUdfUkVBREFCTEVfQVNNIGlzIG5vdCBzZXQKQ09ORklHX1VOVVNFRF9T
WU1CT0xTPXkKIyBDT05GSUdfREVCVUdfRlMgaXMgbm90IHNldAojIENPTkZJR19IRUFERVJT
X0NIRUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU0VDVElPTl9NSVNNQVRDSCBpcyBu
b3Qgc2V0CkNPTkZJR19BUkNIX1dBTlRfRlJBTUVfUE9JTlRFUlM9eQojIENPTkZJR19GUkFN
RV9QT0lOVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfRk9SQ0VfV0VBS19QRVJfQ1BV
IGlzIG5vdCBzZXQKQ09ORklHX01BR0lDX1NZU1JRPXkKQ09ORklHX01BR0lDX1NZU1JRX0RF
RkFVTFRfRU5BQkxFPTB4MQpDT05GSUdfREVCVUdfS0VSTkVMPXkKCiMKIyBNZW1vcnkgRGVi
dWdnaW5nCiMKIyBDT05GSUdfREVCVUdfUEFHRUFMTE9DIGlzIG5vdCBzZXQKIyBDT05GSUdf
REVCVUdfT0JKRUNUUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NMVUJfREVCVUdfT04gaXMgbm90
IHNldAojIENPTkZJR19TTFVCX1NUQVRTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfREVCVUdf
S01FTUxFQUs9eQojIENPTkZJR19ERUJVR19LTUVNTEVBSyBpcyBub3Qgc2V0CiMgQ09ORklH
X0RFQlVHX1NUQUNLX1VTQUdFIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVk0gaXMgbm90
IHNldAojIENPTkZJR19ERUJVR19WSVJUVUFMIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX01F
TU9SWV9JTklUPXkKIyBDT05GSUdfREVCVUdfUEVSX0NQVV9NQVBTIGlzIG5vdCBzZXQKQ09O
RklHX0hBVkVfREVCVUdfU1RBQ0tPVkVSRkxPVz15CiMgQ09ORklHX0RFQlVHX1NUQUNLT1ZF
UkZMT1cgaXMgbm90IHNldApDT05GSUdfSEFWRV9BUkNIX0tNRU1DSEVDSz15CiMgQ09ORklH
X0RFQlVHX1NISVJRIGlzIG5vdCBzZXQKCiMKIyBEZWJ1ZyBMb2NrdXBzIGFuZCBIYW5ncwoj
CkNPTkZJR19MT0NLVVBfREVURUNUT1I9eQpDT05GSUdfSEFSRExPQ0tVUF9ERVRFQ1RPUj15
CiMgQ09ORklHX0JPT1RQQVJBTV9IQVJETE9DS1VQX1BBTklDIGlzIG5vdCBzZXQKQ09ORklH
X0JPT1RQQVJBTV9IQVJETE9DS1VQX1BBTklDX1ZBTFVFPTAKIyBDT05GSUdfQk9PVFBBUkFN
X1NPRlRMT0NLVVBfUEFOSUMgaXMgbm90IHNldApDT05GSUdfQk9PVFBBUkFNX1NPRlRMT0NL
VVBfUEFOSUNfVkFMVUU9MApDT05GSUdfREVURUNUX0hVTkdfVEFTSz15CkNPTkZJR19ERUZB
VUxUX0hVTkdfVEFTS19USU1FT1VUPTEyMAojIENPTkZJR19CT09UUEFSQU1fSFVOR19UQVNL
X1BBTklDIGlzIG5vdCBzZXQKQ09ORklHX0JPT1RQQVJBTV9IVU5HX1RBU0tfUEFOSUNfVkFM
VUU9MAojIENPTkZJR19QQU5JQ19PTl9PT1BTIGlzIG5vdCBzZXQKQ09ORklHX1BBTklDX09O
X09PUFNfVkFMVUU9MApDT05GSUdfUEFOSUNfVElNRU9VVD0wCiMgQ09ORklHX1NDSEVEX0RF
QlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NIRURTVEFUUyBpcyBub3Qgc2V0CiMgQ09ORklH
X1RJTUVSX1NUQVRTIGlzIG5vdCBzZXQKCiMKIyBMb2NrIERlYnVnZ2luZyAoc3BpbmxvY2tz
LCBtdXRleGVzLCBldGMuLi4pCiMKIyBDT05GSUdfREVCVUdfUlRfTVVURVhFUyBpcyBub3Qg
c2V0CiMgQ09ORklHX1JUX01VVEVYX1RFU1RFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVH
X1NQSU5MT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTVVURVhFUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0RFQlVHX1dXX01VVEVYX1NMT1dQQVRIIGlzIG5vdCBzZXQKIyBDT05GSUdf
REVCVUdfTE9DS19BTExPQyBpcyBub3Qgc2V0CiMgQ09ORklHX1BST1ZFX0xPQ0tJTkcgaXMg
bm90IHNldAojIENPTkZJR19MT0NLX1NUQVQgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19B
VE9NSUNfU0xFRVAgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19MT0NLSU5HX0FQSV9TRUxG
VEVTVFMgaXMgbm90IHNldAojIENPTkZJR19MT0NLX1RPUlRVUkVfVEVTVCBpcyBub3Qgc2V0
CiMgQ09ORklHX0RFQlVHX0tPQkpFQ1QgaXMgbm90IHNldApDT05GSUdfREVCVUdfQlVHVkVS
Qk9TRT15CiMgQ09ORklHX0RFQlVHX0xJU1QgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19Q
SV9MSVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU0cgaXMgbm90IHNldAojIENPTkZJ
R19ERUJVR19OT1RJRklFUlMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19DUkVERU5USUFM
UyBpcyBub3Qgc2V0CgojCiMgUkNVIERlYnVnZ2luZwojCiMgQ09ORklHX1NQQVJTRV9SQ1Vf
UE9JTlRFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1RPUlRVUkVfVEVTVCBpcyBub3Qgc2V0CiMg
Q09ORklHX1JDVV9UT1JUVVJFX1RFU1QgaXMgbm90IHNldApDT05GSUdfUkNVX0NQVV9TVEFM
TF9USU1FT1VUPTYwCiMgQ09ORklHX1JDVV9DUFVfU1RBTExfSU5GTyBpcyBub3Qgc2V0CiMg
Q09ORklHX1JDVV9UUkFDRSBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0JMT0NLX0VYVF9E
RVZUIGlzIG5vdCBzZXQKIyBDT05GSUdfTk9USUZJRVJfRVJST1JfSU5KRUNUSU9OIGlzIG5v
dCBzZXQKIyBDT05GSUdfRkFVTFRfSU5KRUNUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfTEFU
RU5DWVRPUCBpcyBub3Qgc2V0CkNPTkZJR19BUkNIX0hBU19ERUJVR19TVFJJQ1RfVVNFUl9D
T1BZX0NIRUNLUz15CiMgQ09ORklHX0RFQlVHX1NUUklDVF9VU0VSX0NPUFlfQ0hFQ0tTIGlz
IG5vdCBzZXQKQ09ORklHX1VTRVJfU1RBQ0tUUkFDRV9TVVBQT1JUPXkKQ09ORklHX0hBVkVf
RlVOQ1RJT05fVFJBQ0VSPXkKQ09ORklHX0hBVkVfRlVOQ1RJT05fR1JBUEhfVFJBQ0VSPXkK
Q09ORklHX0hBVkVfRlVOQ1RJT05fR1JBUEhfRlBfVEVTVD15CkNPTkZJR19IQVZFX0ZVTkNU
SU9OX1RSQUNFX01DT1VOVF9URVNUPXkKQ09ORklHX0hBVkVfRFlOQU1JQ19GVFJBQ0U9eQpD
T05GSUdfSEFWRV9EWU5BTUlDX0ZUUkFDRV9XSVRIX1JFR1M9eQpDT05GSUdfSEFWRV9GVFJB
Q0VfTUNPVU5UX1JFQ09SRD15CkNPTkZJR19IQVZFX1NZU0NBTExfVFJBQ0VQT0lOVFM9eQpD
T05GSUdfSEFWRV9GRU5UUlk9eQpDT05GSUdfSEFWRV9DX1JFQ09SRE1DT1VOVD15CkNPTkZJ
R19UUkFDSU5HX1NVUFBPUlQ9eQojIENPTkZJR19GVFJBQ0UgaXMgbm90IHNldAoKIwojIFJ1
bnRpbWUgVGVzdGluZwojCiMgQ09ORklHX1RFU1RfTElTVF9TT1JUIGlzIG5vdCBzZXQKIyBD
T05GSUdfQkFDS1RSQUNFX1NFTEZfVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX1JCVFJFRV9U
RVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5URVJWQUxfVFJFRV9URVNUIGlzIG5vdCBzZXQK
IyBDT05GSUdfUEVSQ1BVX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19BVE9NSUM2NF9TRUxG
VEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX1RFU1RfU1RSSU5HX0hFTFBFUlMgaXMgbm90IHNl
dAojIENPTkZJR19URVNUX0tTVFJUT1ggaXMgbm90IHNldAojIENPTkZJR19QUk9WSURFX09I
Q0kxMzk0X0RNQV9JTklUIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1BX0FQSV9ERUJVRyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1RFU1RfTU9EVUxFIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9V
U0VSX0NPUFkgaXMgbm90IHNldAojIENPTkZJR19URVNUX0JQRiBpcyBub3Qgc2V0CiMgQ09O
RklHX1NBTVBMRVMgaXMgbm90IHNldApDT05GSUdfSEFWRV9BUkNIX0tHREI9eQojIENPTkZJ
R19LR0RCIGlzIG5vdCBzZXQKQ09ORklHX1NUUklDVF9ERVZNRU09eQpDT05GSUdfWDg2X1ZF
UkJPU0VfQk9PVFVQPXkKQ09ORklHX0VBUkxZX1BSSU5USz15CiMgQ09ORklHX0VBUkxZX1BS
SU5US19EQkdQIGlzIG5vdCBzZXQKIyBDT05GSUdfRUFSTFlfUFJJTlRLX0VGSSBpcyBub3Qg
c2V0CiMgQ09ORklHX1g4Nl9QVERVTVAgaXMgbm90IHNldApDT05GSUdfREVCVUdfUk9EQVRB
PXkKIyBDT05GSUdfREVCVUdfUk9EQVRBX1RFU1QgaXMgbm90IHNldApDT05GSUdfREVCVUdf
U0VUX01PRFVMRV9ST05YPXkKIyBDT05GSUdfREVCVUdfTlhfVEVTVCBpcyBub3Qgc2V0CkNP
TkZJR19ET1VCTEVGQVVMVD15CiMgQ09ORklHX0RFQlVHX1RMQkZMVVNIIGlzIG5vdCBzZXQK
IyBDT05GSUdfSU9NTVVfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19JT01NVV9TVFJFU1Mg
aXMgbm90IHNldApDT05GSUdfSEFWRV9NTUlPVFJBQ0VfU1VQUE9SVD15CkNPTkZJR19JT19E
RUxBWV9UWVBFXzBYODA9MApDT05GSUdfSU9fREVMQVlfVFlQRV8wWEVEPTEKQ09ORklHX0lP
X0RFTEFZX1RZUEVfVURFTEFZPTIKQ09ORklHX0lPX0RFTEFZX1RZUEVfTk9ORT0zCkNPTkZJ
R19JT19ERUxBWV8wWDgwPXkKIyBDT05GSUdfSU9fREVMQVlfMFhFRCBpcyBub3Qgc2V0CiMg
Q09ORklHX0lPX0RFTEFZX1VERUxBWSBpcyBub3Qgc2V0CiMgQ09ORklHX0lPX0RFTEFZX05P
TkUgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9JT19ERUxBWV9UWVBFPTAKIyBDT05GSUdf
Q1BBX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfT1BUSU1JWkVfSU5MSU5JTkcgaXMgbm90
IHNldAojIENPTkZJR19ERUJVR19OTUlfU0VMRlRFU1QgaXMgbm90IHNldAojIENPTkZJR19Y
ODZfREVCVUdfU1RBVElDX0NQVV9IQVMgaXMgbm90IHNldAoKIwojIFNlY3VyaXR5IG9wdGlv
bnMKIwpDT05GSUdfS0VZUz15CiMgQ09ORklHX1BFUlNJU1RFTlRfS0VZUklOR1MgaXMgbm90
IHNldAojIENPTkZJR19CSUdfS0VZUyBpcyBub3Qgc2V0CiMgQ09ORklHX1RSVVNURURfS0VZ
UyBpcyBub3Qgc2V0CiMgQ09ORklHX0VOQ1JZUFRFRF9LRVlTIGlzIG5vdCBzZXQKQ09ORklH
X0tFWVNfREVCVUdfUFJPQ19LRVlTPXkKIyBDT05GSUdfU0VDVVJJVFlfRE1FU0dfUkVTVFJJ
Q1QgaXMgbm90IHNldApDT05GSUdfU0VDVVJJVFk9eQpDT05GSUdfU0VDVVJJVFlGUz15CiMg
Q09ORklHX1NFQ1VSSVRZX05FVFdPUksgaXMgbm90IHNldAojIENPTkZJR19TRUNVUklUWV9Q
QVRIIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5URUxfVFhUIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VDVVJJVFlfU01BQ0sgaXMgbm90IHNldAojIENPTkZJR19TRUNVUklUWV9UT01PWU8gaXMg
bm90IHNldAojIENPTkZJR19TRUNVUklUWV9BUFBBUk1PUiBpcyBub3Qgc2V0CiMgQ09ORklH
X1NFQ1VSSVRZX1lBTUEgaXMgbm90IHNldAojIENPTkZJR19JTUEgaXMgbm90IHNldAojIENP
TkZJR19FVk0gaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9TRUNVUklUWV9EQUM9eQpDT05G
SUdfREVGQVVMVF9TRUNVUklUWT0iIgpDT05GSUdfWE9SX0JMT0NLUz15CkNPTkZJR19DUllQ
VE89eQoKIwojIENyeXB0byBjb3JlIG9yIGhlbHBlcgojCiMgQ09ORklHX0NSWVBUT19GSVBT
IGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19BTEdBUEk9eQpDT05GSUdfQ1JZUFRPX0FMR0FQ
STI9eQpDT05GSUdfQ1JZUFRPX0FFQUQ9eQpDT05GSUdfQ1JZUFRPX0FFQUQyPXkKQ09ORklH
X0NSWVBUT19CTEtDSVBIRVI9eQpDT05GSUdfQ1JZUFRPX0JMS0NJUEhFUjI9eQpDT05GSUdf
Q1JZUFRPX0hBU0g9eQpDT05GSUdfQ1JZUFRPX0hBU0gyPXkKQ09ORklHX0NSWVBUT19STkc9
eQpDT05GSUdfQ1JZUFRPX1JORzI9eQpDT05GSUdfQ1JZUFRPX1BDT01QPXkKQ09ORklHX0NS
WVBUT19QQ09NUDI9eQpDT05GSUdfQ1JZUFRPX01BTkFHRVI9eQpDT05GSUdfQ1JZUFRPX01B
TkFHRVIyPXkKIyBDT05GSUdfQ1JZUFRPX1VTRVIgaXMgbm90IHNldAojIENPTkZJR19DUllQ
VE9fTUFOQUdFUl9ESVNBQkxFX1RFU1RTIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19HRjEy
OE1VTD15CkNPTkZJR19DUllQVE9fTlVMTD15CkNPTkZJR19DUllQVE9fUENSWVBUPXkKQ09O
RklHX0NSWVBUT19XT1JLUVVFVUU9eQpDT05GSUdfQ1JZUFRPX0NSWVBURD15CkNPTkZJR19D
UllQVE9fQVVUSEVOQz15CiMgQ09ORklHX0NSWVBUT19URVNUIGlzIG5vdCBzZXQKQ09ORklH
X0NSWVBUT19BQkxLX0hFTFBFUj15CkNPTkZJR19DUllQVE9fR0xVRV9IRUxQRVJfWDg2PXkK
CiMKIyBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gd2l0aCBBc3NvY2lhdGVkIERhdGEKIwpD
T05GSUdfQ1JZUFRPX0NDTT15CkNPTkZJR19DUllQVE9fR0NNPXkKQ09ORklHX0NSWVBUT19T
RVFJVj15CgojCiMgQmxvY2sgbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0NCQz15CkNPTkZJR19D
UllQVE9fQ1RSPXkKQ09ORklHX0NSWVBUT19DVFM9bQpDT05GSUdfQ1JZUFRPX0VDQj15CkNP
TkZJR19DUllQVE9fTFJXPXkKQ09ORklHX0NSWVBUT19QQ0JDPXkKQ09ORklHX0NSWVBUT19Y
VFM9eQoKIwojIEhhc2ggbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0NNQUM9eQpDT05GSUdfQ1JZ
UFRPX0hNQUM9eQpDT05GSUdfQ1JZUFRPX1hDQkM9eQpDT05GSUdfQ1JZUFRPX1ZNQUM9eQoK
IwojIERpZ2VzdAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPXkKQ09ORklHX0NSWVBUT19DUkMz
MkNfSU5URUw9eQojIENPTkZJR19DUllQVE9fQ1JDMzIgaXMgbm90IHNldAojIENPTkZJR19D
UllQVE9fQ1JDMzJfUENMTVVMIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19DUkNUMTBESUY9
eQojIENPTkZJR19DUllQVE9fQ1JDVDEwRElGX1BDTE1VTCBpcyBub3Qgc2V0CkNPTkZJR19D
UllQVE9fR0hBU0g9eQpDT05GSUdfQ1JZUFRPX01END15CkNPTkZJR19DUllQVE9fTUQ1PXkK
Q09ORklHX0NSWVBUT19NSUNIQUVMX01JQz15CkNPTkZJR19DUllQVE9fUk1EMTI4PXkKQ09O
RklHX0NSWVBUT19STUQxNjA9eQpDT05GSUdfQ1JZUFRPX1JNRDI1Nj15CkNPTkZJR19DUllQ
VE9fUk1EMzIwPXkKQ09ORklHX0NSWVBUT19TSEExPXkKQ09ORklHX0NSWVBUT19TSEExX1NT
U0UzPXkKIyBDT05GSUdfQ1JZUFRPX1NIQTI1Nl9TU1NFMyBpcyBub3Qgc2V0CiMgQ09ORklH
X0NSWVBUT19TSEE1MTJfU1NTRTMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1NIQTI1Nj15
CkNPTkZJR19DUllQVE9fU0hBNTEyPXkKQ09ORklHX0NSWVBUT19UR1IxOTI9eQpDT05GSUdf
Q1JZUFRPX1dQNTEyPXkKQ09ORklHX0NSWVBUT19HSEFTSF9DTE1VTF9OSV9JTlRFTD15Cgoj
CiMgQ2lwaGVycwojCkNPTkZJR19DUllQVE9fQUVTPXkKQ09ORklHX0NSWVBUT19BRVNfWDg2
XzY0PXkKQ09ORklHX0NSWVBUT19BRVNfTklfSU5URUw9eQpDT05GSUdfQ1JZUFRPX0FOVUJJ
Uz15CkNPTkZJR19DUllQVE9fQVJDND15CkNPTkZJR19DUllQVE9fQkxPV0ZJU0g9eQpDT05G
SUdfQ1JZUFRPX0JMT1dGSVNIX0NPTU1PTj15CkNPTkZJR19DUllQVE9fQkxPV0ZJU0hfWDg2
XzY0PXkKQ09ORklHX0NSWVBUT19DQU1FTExJQT15CiMgQ09ORklHX0NSWVBUT19DQU1FTExJ
QV9YODZfNjQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQ0FNRUxMSUFfQUVTTklfQVZY
X1g4Nl82NCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19DQU1FTExJQV9BRVNOSV9BVlgy
X1g4Nl82NCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fQ0FTVF9DT01NT049eQpDT05GSUdf
Q1JZUFRPX0NBU1Q1PXkKIyBDT05GSUdfQ1JZUFRPX0NBU1Q1X0FWWF9YODZfNjQgaXMgbm90
IHNldApDT05GSUdfQ1JZUFRPX0NBU1Q2PXkKIyBDT05GSUdfQ1JZUFRPX0NBU1Q2X0FWWF9Y
ODZfNjQgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0RFUz15CkNPTkZJR19DUllQVE9fRkNS
WVBUPXkKQ09ORklHX0NSWVBUT19LSEFaQUQ9eQpDT05GSUdfQ1JZUFRPX1NBTFNBMjA9eQpD
T05GSUdfQ1JZUFRPX1NBTFNBMjBfWDg2XzY0PXkKQ09ORklHX0NSWVBUT19TRUVEPXkKQ09O
RklHX0NSWVBUT19TRVJQRU5UPXkKIyBDT05GSUdfQ1JZUFRPX1NFUlBFTlRfU1NFMl9YODZf
NjQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fU0VSUEVOVF9BVlhfWDg2XzY0IGlzIG5v
dCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NFUlBFTlRfQVZYMl9YODZfNjQgaXMgbm90IHNldApD
T05GSUdfQ1JZUFRPX1RFQT15CkNPTkZJR19DUllQVE9fVFdPRklTSD15CkNPTkZJR19DUllQ
VE9fVFdPRklTSF9DT01NT049eQpDT05GSUdfQ1JZUFRPX1RXT0ZJU0hfWDg2XzY0PXkKQ09O
RklHX0NSWVBUT19UV09GSVNIX1g4Nl82NF8zV0FZPXkKIyBDT05GSUdfQ1JZUFRPX1RXT0ZJ
U0hfQVZYX1g4Nl82NCBpcyBub3Qgc2V0CgojCiMgQ29tcHJlc3Npb24KIwpDT05GSUdfQ1JZ
UFRPX0RFRkxBVEU9eQpDT05GSUdfQ1JZUFRPX1pMSUI9eQpDT05GSUdfQ1JZUFRPX0xaTz15
CiMgQ09ORklHX0NSWVBUT19MWjQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fTFo0SEMg
aXMgbm90IHNldAoKIwojIFJhbmRvbSBOdW1iZXIgR2VuZXJhdGlvbgojCkNPTkZJR19DUllQ
VE9fQU5TSV9DUFJORz15CkNPTkZJR19DUllQVE9fVVNFUl9BUEk9eQpDT05GSUdfQ1JZUFRP
X1VTRVJfQVBJX0hBU0g9eQpDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX1NLQ0lQSEVSPXkKQ09O
RklHX0NSWVBUT19IVz15CiMgQ09ORklHX0NSWVBUT19ERVZfUEFETE9DSyBpcyBub3Qgc2V0
CiMgQ09ORklHX0NSWVBUT19ERVZfQ0NQIGlzIG5vdCBzZXQKIyBDT05GSUdfQVNZTU1FVFJJ
Q19LRVlfVFlQRSBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0tWTT15CiMgQ09ORklHX1ZJUlRV
QUxJWkFUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfQklOQVJZX1BSSU5URiBpcyBub3Qgc2V0
CgojCiMgTGlicmFyeSByb3V0aW5lcwojCkNPTkZJR19SQUlENl9QUT15CkNPTkZJR19CSVRS
RVZFUlNFPXkKQ09ORklHX0dFTkVSSUNfU1RSTkNQWV9GUk9NX1VTRVI9eQpDT05GSUdfR0VO
RVJJQ19TVFJOTEVOX1VTRVI9eQpDT05GSUdfR0VORVJJQ19ORVRfVVRJTFM9eQpDT05GSUdf
R0VORVJJQ19GSU5EX0ZJUlNUX0JJVD15CkNPTkZJR19HRU5FUklDX1BDSV9JT01BUD15CkNP
TkZJR19HRU5FUklDX0lPTUFQPXkKQ09ORklHX0dFTkVSSUNfSU89eQpDT05GSUdfQVJDSF9V
U0VfQ01QWENIR19MT0NLUkVGPXkKQ09ORklHX0NSQ19DQ0lUVD15CkNPTkZJR19DUkMxNj15
CkNPTkZJR19DUkNfVDEwRElGPXkKQ09ORklHX0NSQ19JVFVfVD15CkNPTkZJR19DUkMzMj15
CiMgQ09ORklHX0NSQzMyX1NFTEZURVNUIGlzIG5vdCBzZXQKQ09ORklHX0NSQzMyX1NMSUNF
Qlk4PXkKIyBDT05GSUdfQ1JDMzJfU0xJQ0VCWTQgaXMgbm90IHNldAojIENPTkZJR19DUkMz
Ml9TQVJXQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JDMzJfQklUIGlzIG5vdCBzZXQKQ09O
RklHX0NSQzc9eQpDT05GSUdfTElCQ1JDMzJDPXkKQ09ORklHX0NSQzg9eQojIENPTkZJR19B
VURJVF9BUkNIX0NPTVBBVF9HRU5FUklDIGlzIG5vdCBzZXQKIyBDT05GSUdfUkFORE9NMzJf
U0VMRlRFU1QgaXMgbm90IHNldApDT05GSUdfWkxJQl9JTkZMQVRFPXkKQ09ORklHX1pMSUJf
REVGTEFURT15CkNPTkZJR19MWk9fQ09NUFJFU1M9eQpDT05GSUdfTFpPX0RFQ09NUFJFU1M9
eQpDT05GSUdfTFo0X0RFQ09NUFJFU1M9eQpDT05GSUdfWFpfREVDPXkKQ09ORklHX1haX0RF
Q19YODY9eQpDT05GSUdfWFpfREVDX1BPV0VSUEM9eQpDT05GSUdfWFpfREVDX0lBNjQ9eQpD
T05GSUdfWFpfREVDX0FSTT15CkNPTkZJR19YWl9ERUNfQVJNVEhVTUI9eQpDT05GSUdfWFpf
REVDX1NQQVJDPXkKQ09ORklHX1haX0RFQ19CQ0o9eQojIENPTkZJR19YWl9ERUNfVEVTVCBp
cyBub3Qgc2V0CkNPTkZJR19ERUNPTVBSRVNTX0daSVA9eQpDT05GSUdfREVDT01QUkVTU19C
WklQMj15CkNPTkZJR19ERUNPTVBSRVNTX0xaTUE9eQpDT05GSUdfREVDT01QUkVTU19YWj15
CkNPTkZJR19ERUNPTVBSRVNTX0xaTz15CkNPTkZJR19ERUNPTVBSRVNTX0xaND15CkNPTkZJ
R19URVhUU0VBUkNIPXkKQ09ORklHX1RFWFRTRUFSQ0hfS01QPXkKQ09ORklHX1RFWFRTRUFS
Q0hfQk09eQpDT05GSUdfVEVYVFNFQVJDSF9GU009eQpDT05GSUdfSU5URVJWQUxfVFJFRT15
CkNPTkZJR19BU1NPQ0lBVElWRV9BUlJBWT15CkNPTkZJR19IQVNfSU9NRU09eQpDT05GSUdf
SEFTX0lPUE9SVF9NQVA9eQpDT05GSUdfSEFTX0RNQT15CkNPTkZJR19DSEVDS19TSUdOQVRV
UkU9eQpDT05GSUdfQ1BVX1JNQVA9eQpDT05GSUdfRFFMPXkKQ09ORklHX05MQVRUUj15CkNP
TkZJR19BUkNIX0hBU19BVE9NSUM2NF9ERUNfSUZfUE9TSVRJVkU9eQpDT05GSUdfTFJVX0NB
Q0hFPXkKQ09ORklHX0FWRVJBR0U9eQpDT05GSUdfQ09SRElDPXkKIyBDT05GSUdfRERSIGlz
IG5vdCBzZXQKQ09ORklHX1VDUzJfU1RSSU5HPXkKQ09ORklHX0ZPTlRfU1VQUE9SVD15CiMg
Q09ORklHX0ZPTlRTIGlzIG5vdCBzZXQKQ09ORklHX0ZPTlRfOHg4PXkKQ09ORklHX0ZPTlRf
OHgxNj15Cg==
------------12A0390BB304161AE
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------12A0390BB304161AE--



From xen-devel-bounces@lists.xen.org Fri Dec 19 13:17:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 13:17:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1xQO-0001G3-AY; Fri, 19 Dec 2014 13:16:56 +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 1Y1xQK-0001Fy-Ln
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 13:16:54 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	8C/E9-26858-34524945; Fri, 19 Dec 2014 13:16:51 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-31.messagelabs.com!1418995010!14509482!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25947 invoked from network); 19 Dec 2014 13:16:50 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-15.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 19 Dec 2014 13:16:50 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:50936 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Y1xPF-0007kF-9A; Fri, 19 Dec 2014 14:15:45 +0100
Date: Fri, 19 Dec 2014 14:16:45 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1824124380.20141219141645@eikelenboom.it>
To: konrad.wilk@oracle.com, David Vrabel <david.vrabel@citrix.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, <jiang.liu@linux.intel.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------12A0390BB304161AE"
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: [Xen-devel] Bisected Linux regression: ACPI powerbutton events
	don't work under Xen since commit
	b81975eade8c6495f3c4d6746d22bdc95f617777
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------12A0390BB304161AE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

When running under Xen, ACPI powerbutton events don't work anymore, 
there is no reaction when pressing the powerbutton.

On baremetal everything works fine, acpid gets the event and the 
machine powers down perfectly. The machine is an Intel NUC.
 
Bisection has lead to:

b81975eade8c6495f3c4d6746d22bdc95f617777 is the first bad commit
commit b81975eade8c6495f3c4d6746d22bdc95f617777
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Mon Jun 9 16:20:11 2014 +0800

    x86, irq: Clean up irqdomain transition code

    Now we have completely switched to irqdomain, so clean up transition code
    in IOAPIC drivers.

    Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Grant Likely <grant.likely@linaro.org>
    Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Link: http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang.liu@linux.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Reverting this specific commit on linux-tip (3.19-mw) gets things working again under Xen.
Kernel .config is attached.

--
Sander
------------12A0390BB304161AE
Content-Type: application/octet-stream;
 name=dot-config
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename=dot-config

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4
L3g4Nl82NCAzLjE2LjAtcmMxLWNyZWFudWMtMjAxNDEyMTgtYmlzZWN0MTYgS2VybmVsIENv
bmZpZ3VyYXRpb24KIwpDT05GSUdfNjRCSVQ9eQpDT05GSUdfWDg2XzY0PXkKQ09ORklHX1g4
Nj15CkNPTkZJR19JTlNUUlVDVElPTl9ERUNPREVSPXkKQ09ORklHX09VVFBVVF9GT1JNQVQ9
ImVsZjY0LXg4Ni02NCIKQ09ORklHX0FSQ0hfREVGQ09ORklHPSJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCkNPTkZJR19MT0NLREVQX1NVUFBPUlQ9eQpDT05GSUdfU1RB
Q0tUUkFDRV9TVVBQT1JUPXkKQ09ORklHX0hBVkVfTEFURU5DWVRPUF9TVVBQT1JUPXkKQ09O
RklHX01NVT15CkNPTkZJR19ORUVEX0RNQV9NQVBfU1RBVEU9eQpDT05GSUdfTkVFRF9TR19E
TUFfTEVOR1RIPXkKQ09ORklHX0dFTkVSSUNfSVNBX0RNQT15CkNPTkZJR19HRU5FUklDX0JV
Rz15CkNPTkZJR19HRU5FUklDX0JVR19SRUxBVElWRV9QT0lOVEVSUz15CkNPTkZJR19HRU5F
UklDX0hXRUlHSFQ9eQpDT05GSUdfQVJDSF9NQVlfSEFWRV9QQ19GREM9eQpDT05GSUdfUldT
RU1fWENIR0FERF9BTEdPUklUSE09eQpDT05GSUdfR0VORVJJQ19DQUxJQlJBVEVfREVMQVk9
eQpDT05GSUdfQVJDSF9IQVNfQ1BVX1JFTEFYPXkKQ09ORklHX0FSQ0hfSEFTX0NBQ0hFX0xJ
TkVfU0laRT15CkNPTkZJR19IQVZFX1NFVFVQX1BFUl9DUFVfQVJFQT15CkNPTkZJR19ORUVE
X1BFUl9DUFVfRU1CRURfRklSU1RfQ0hVTks9eQpDT05GSUdfTkVFRF9QRVJfQ1BVX1BBR0Vf
RklSU1RfQ0hVTks9eQpDT05GSUdfQVJDSF9ISUJFUk5BVElPTl9QT1NTSUJMRT15CkNPTkZJ
R19BUkNIX1NVU1BFTkRfUE9TU0lCTEU9eQpDT05GSUdfQVJDSF9XQU5UX0hVR0VfUE1EX1NI
QVJFPXkKQ09ORklHX0FSQ0hfV0FOVF9HRU5FUkFMX0hVR0VUTEI9eQpDT05GSUdfWk9ORV9E
TUEzMj15CkNPTkZJR19BVURJVF9BUkNIPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfT1BUSU1J
WkVEX0lOTElOSU5HPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfREVCVUdfUEFHRUFMTE9DPXkK
Q09ORklHX0hBVkVfSU5URUxfVFhUPXkKQ09ORklHX1g4Nl82NF9TTVA9eQpDT05GSUdfWDg2
X0hUPXkKQ09ORklHX0FSQ0hfSFdFSUdIVF9DRkxBR1M9Ii1mY2FsbC1zYXZlZC1yZGkgLWZj
YWxsLXNhdmVkLXJzaSAtZmNhbGwtc2F2ZWQtcmR4IC1mY2FsbC1zYXZlZC1yY3ggLWZjYWxs
LXNhdmVkLXI4IC1mY2FsbC1zYXZlZC1yOSAtZmNhbGwtc2F2ZWQtcjEwIC1mY2FsbC1zYXZl
ZC1yMTEiCkNPTkZJR19BUkNIX1NVUFBPUlRTX1VQUk9CRVM9eQpDT05GSUdfRklYX0VBUkxZ
Q09OX01FTT15CkNPTkZJR19ERUZDT05GSUdfTElTVD0iL2xpYi9tb2R1bGVzLyRVTkFNRV9S
RUxFQVNFLy5jb25maWciCkNPTkZJR19JUlFfV09SSz15CkNPTkZJR19CVUlMRFRJTUVfRVhU
QUJMRV9TT1JUPXkKCiMKIyBHZW5lcmFsIHNldHVwCiMKQ09ORklHX0lOSVRfRU5WX0FSR19M
SU1JVD0zMgpDT05GSUdfQ1JPU1NfQ09NUElMRT0iIgojIENPTkZJR19DT01QSUxFX1RFU1Qg
aXMgbm90IHNldApDT05GSUdfTE9DQUxWRVJTSU9OPSIiCiMgQ09ORklHX0xPQ0FMVkVSU0lP
Tl9BVVRPIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfS0VSTkVMX0daSVA9eQpDT05GSUdfSEFW
RV9LRVJORUxfQlpJUDI9eQpDT05GSUdfSEFWRV9LRVJORUxfTFpNQT15CkNPTkZJR19IQVZF
X0tFUk5FTF9YWj15CkNPTkZJR19IQVZFX0tFUk5FTF9MWk89eQpDT05GSUdfSEFWRV9LRVJO
RUxfTFo0PXkKQ09ORklHX0tFUk5FTF9HWklQPXkKIyBDT05GSUdfS0VSTkVMX0JaSVAyIGlz
IG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX0xaTUEgaXMgbm90IHNldAojIENPTkZJR19LRVJO
RUxfWFogaXMgbm90IHNldAojIENPTkZJR19LRVJORUxfTFpPIGlzIG5vdCBzZXQKIyBDT05G
SUdfS0VSTkVMX0xaNCBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0hPU1ROQU1FPSIobm9u
ZSkiCkNPTkZJR19TV0FQPXkKQ09ORklHX1NZU1ZJUEM9eQpDT05GSUdfU1lTVklQQ19TWVND
VEw9eQpDT05GSUdfUE9TSVhfTVFVRVVFPXkKQ09ORklHX1BPU0lYX01RVUVVRV9TWVNDVEw9
eQpDT05GSUdfQ1JPU1NfTUVNT1JZX0FUVEFDSD15CkNPTkZJR19GSEFORExFPXkKQ09ORklH
X1VTRUxJQj15CkNPTkZJR19BVURJVD15CkNPTkZJR19IQVZFX0FSQ0hfQVVESVRTWVNDQUxM
PXkKQ09ORklHX0FVRElUU1lTQ0FMTD15CkNPTkZJR19BVURJVF9XQVRDSD15CkNPTkZJR19B
VURJVF9UUkVFPXkKCiMKIyBJUlEgc3Vic3lzdGVtCiMKQ09ORklHX0dFTkVSSUNfSVJRX1BS
T0JFPXkKQ09ORklHX0dFTkVSSUNfSVJRX1NIT1c9eQpDT05GSUdfR0VORVJJQ19JUlFfTEVH
QUNZX0FMTE9DX0hXSVJRPXkKQ09ORklHX0dFTkVSSUNfUEVORElOR19JUlE9eQpDT05GSUdf
R0VORVJJQ19JUlFfQ0hJUD15CkNPTkZJR19JUlFfRE9NQUlOPXkKQ09ORklHX0lSUV9GT1JD
RURfVEhSRUFESU5HPXkKQ09ORklHX1NQQVJTRV9JUlE9eQpDT05GSUdfQ0xPQ0tTT1VSQ0Vf
V0FUQ0hET0c9eQpDT05GSUdfQVJDSF9DTE9DS1NPVVJDRV9EQVRBPXkKQ09ORklHX0dFTkVS
SUNfVElNRV9WU1lTQ0FMTD15CkNPTkZJR19HRU5FUklDX0NMT0NLRVZFTlRTPXkKQ09ORklH
X0dFTkVSSUNfQ0xPQ0tFVkVOVFNfQlVJTEQ9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5U
U19CUk9BRENBU1Q9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5UU19NSU5fQURKVVNUPXkK
Q09ORklHX0dFTkVSSUNfQ01PU19VUERBVEU9eQoKIwojIFRpbWVycyBzdWJzeXN0ZW0KIwpD
T05GSUdfVElDS19PTkVTSE9UPXkKQ09ORklHX05PX0haX0NPTU1PTj15CiMgQ09ORklHX0ha
X1BFUklPRElDIGlzIG5vdCBzZXQKQ09ORklHX05PX0haX0lETEU9eQojIENPTkZJR19OT19I
Wl9GVUxMIGlzIG5vdCBzZXQKQ09ORklHX05PX0haPXkKQ09ORklHX0hJR0hfUkVTX1RJTUVS
Uz15CgojCiMgQ1BVL1Rhc2sgdGltZSBhbmQgc3RhdHMgYWNjb3VudGluZwojCkNPTkZJR19U
SUNLX0NQVV9BQ0NPVU5USU5HPXkKIyBDT05GSUdfVklSVF9DUFVfQUNDT1VOVElOR19HRU4g
aXMgbm90IHNldAojIENPTkZJR19JUlFfVElNRV9BQ0NPVU5USU5HIGlzIG5vdCBzZXQKQ09O
RklHX0JTRF9QUk9DRVNTX0FDQ1Q9eQpDT05GSUdfQlNEX1BST0NFU1NfQUNDVF9WMz15CkNP
TkZJR19UQVNLU1RBVFM9eQpDT05GSUdfVEFTS19ERUxBWV9BQ0NUPXkKQ09ORklHX1RBU0tf
WEFDQ1Q9eQpDT05GSUdfVEFTS19JT19BQ0NPVU5USU5HPXkKCiMKIyBSQ1UgU3Vic3lzdGVt
CiMKQ09ORklHX1RSRUVfUkNVPXkKIyBDT05GSUdfUFJFRU1QVF9SQ1UgaXMgbm90IHNldApD
T05GSUdfUkNVX1NUQUxMX0NPTU1PTj15CiMgQ09ORklHX1JDVV9VU0VSX1FTIGlzIG5vdCBz
ZXQKQ09ORklHX1JDVV9GQU5PVVQ9NjQKQ09ORklHX1JDVV9GQU5PVVRfTEVBRj0xNgojIENP
TkZJR19SQ1VfRkFOT1VUX0VYQUNUIGlzIG5vdCBzZXQKQ09ORklHX1JDVV9GQVNUX05PX0ha
PXkKIyBDT05GSUdfVFJFRV9SQ1VfVFJBQ0UgaXMgbm90IHNldAojIENPTkZJR19SQ1VfTk9D
Ql9DUFUgaXMgbm90IHNldAojIENPTkZJR19JS0NPTkZJRyBpcyBub3Qgc2V0CkNPTkZJR19M
T0dfQlVGX1NISUZUPTE3CkNPTkZJR19IQVZFX1VOU1RBQkxFX1NDSEVEX0NMT0NLPXkKQ09O
RklHX0FSQ0hfU1VQUE9SVFNfTlVNQV9CQUxBTkNJTkc9eQpDT05GSUdfQVJDSF9TVVBQT1JU
U19JTlQxMjg9eQpDT05GSUdfQVJDSF9XQU5UU19QUk9UX05VTUFfUFJPVF9OT05FPXkKQ09O
RklHX0NHUk9VUFM9eQojIENPTkZJR19DR1JPVVBfREVCVUcgaXMgbm90IHNldApDT05GSUdf
Q0dST1VQX0ZSRUVaRVI9eQpDT05GSUdfQ0dST1VQX0RFVklDRT15CkNPTkZJR19DUFVTRVRT
PXkKQ09ORklHX1BST0NfUElEX0NQVVNFVD15CkNPTkZJR19DR1JPVVBfQ1BVQUNDVD15CkNP
TkZJR19SRVNPVVJDRV9DT1VOVEVSUz15CiMgQ09ORklHX01FTUNHIGlzIG5vdCBzZXQKIyBD
T05GSUdfQ0dST1VQX0hVR0VUTEIgaXMgbm90IHNldApDT05GSUdfQ0dST1VQX1BFUkY9eQpD
T05GSUdfQ0dST1VQX1NDSEVEPXkKQ09ORklHX0ZBSVJfR1JPVVBfU0NIRUQ9eQojIENPTkZJ
R19DRlNfQkFORFdJRFRIIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRfR1JPVVBfU0NIRUQgaXMg
bm90IHNldApDT05GSUdfQkxLX0NHUk9VUD15CiMgQ09ORklHX0RFQlVHX0JMS19DR1JPVVAg
aXMgbm90IHNldAojIENPTkZJR19DSEVDS1BPSU5UX1JFU1RPUkUgaXMgbm90IHNldApDT05G
SUdfTkFNRVNQQUNFUz15CkNPTkZJR19VVFNfTlM9eQpDT05GSUdfSVBDX05TPXkKIyBDT05G
SUdfVVNFUl9OUyBpcyBub3Qgc2V0CkNPTkZJR19QSURfTlM9eQpDT05GSUdfTkVUX05TPXkK
Q09ORklHX1NDSEVEX0FVVE9HUk9VUD15CiMgQ09ORklHX1NZU0ZTX0RFUFJFQ0FURUQgaXMg
bm90IHNldApDT05GSUdfUkVMQVk9eQpDT05GSUdfQkxLX0RFVl9JTklUUkQ9eQpDT05GSUdf
SU5JVFJBTUZTX1NPVVJDRT0iIgpDT05GSUdfUkRfR1pJUD15CkNPTkZJR19SRF9CWklQMj15
CkNPTkZJR19SRF9MWk1BPXkKQ09ORklHX1JEX1haPXkKQ09ORklHX1JEX0xaTz15CkNPTkZJ
R19SRF9MWjQ9eQpDT05GSUdfQ0NfT1BUSU1JWkVfRk9SX1NJWkU9eQpDT05GSUdfU1lTQ1RM
PXkKQ09ORklHX0FOT05fSU5PREVTPXkKQ09ORklHX1NZU0NUTF9FWENFUFRJT05fVFJBQ0U9
eQpDT05GSUdfSEFWRV9QQ1NQS1JfUExBVEZPUk09eQojIENPTkZJR19FWFBFUlQgaXMgbm90
IHNldApDT05GSUdfU0dFVE1BU0tfU1lTQ0FMTD15CkNPTkZJR19TWVNGU19TWVNDQUxMPXkK
IyBDT05GSUdfU1lTQ1RMX1NZU0NBTEwgaXMgbm90IHNldApDT05GSUdfS0FMTFNZTVM9eQoj
IENPTkZJR19LQUxMU1lNU19BTEwgaXMgbm90IHNldApDT05GSUdfUFJJTlRLPXkKQ09ORklH
X0JVRz15CkNPTkZJR19FTEZfQ09SRT15CkNPTkZJR19QQ1NQS1JfUExBVEZPUk09eQpDT05G
SUdfQkFTRV9GVUxMPXkKQ09ORklHX0ZVVEVYPXkKQ09ORklHX0VQT0xMPXkKQ09ORklHX1NJ
R05BTEZEPXkKQ09ORklHX1RJTUVSRkQ9eQpDT05GSUdfRVZFTlRGRD15CkNPTkZJR19TSE1F
TT15CkNPTkZJR19BSU89eQpDT05GSUdfUENJX1FVSVJLUz15CiMgQ09ORklHX0VNQkVEREVE
IGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfUEVSRl9FVkVOVFM9eQoKIwojIEtlcm5lbCBQZXJm
b3JtYW5jZSBFdmVudHMgQW5kIENvdW50ZXJzCiMKQ09ORklHX1BFUkZfRVZFTlRTPXkKIyBD
T05GSUdfREVCVUdfUEVSRl9VU0VfVk1BTExPQyBpcyBub3Qgc2V0CkNPTkZJR19WTV9FVkVO
VF9DT1VOVEVSUz15CkNPTkZJR19TTFVCX0RFQlVHPXkKIyBDT05GSUdfQ09NUEFUX0JSSyBp
cyBub3Qgc2V0CiMgQ09ORklHX1NMQUIgaXMgbm90IHNldApDT05GSUdfU0xVQj15CkNPTkZJ
R19TTFVCX0NQVV9QQVJUSUFMPXkKIyBDT05GSUdfU1lTVEVNX1RSVVNURURfS0VZUklORyBp
cyBub3Qgc2V0CiMgQ09ORklHX1BST0ZJTElORyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX09Q
Uk9GSUxFPXkKQ09ORklHX09QUk9GSUxFX05NSV9USU1FUj15CiMgQ09ORklHX0tQUk9CRVMg
aXMgbm90IHNldAojIENPTkZJR19KVU1QX0xBQkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfVVBS
T0JFUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hBVkVfNjRCSVRfQUxJR05FRF9BQ0NFU1MgaXMg
bm90IHNldApDT05GSUdfSEFWRV9FRkZJQ0lFTlRfVU5BTElHTkVEX0FDQ0VTUz15CkNPTkZJ
R19BUkNIX1VTRV9CVUlMVElOX0JTV0FQPXkKQ09ORklHX0hBVkVfSU9SRU1BUF9QUk9UPXkK
Q09ORklHX0hBVkVfS1BST0JFUz15CkNPTkZJR19IQVZFX0tSRVRQUk9CRVM9eQpDT05GSUdf
SEFWRV9PUFRQUk9CRVM9eQpDT05GSUdfSEFWRV9LUFJPQkVTX09OX0ZUUkFDRT15CkNPTkZJ
R19IQVZFX0FSQ0hfVFJBQ0VIT09LPXkKQ09ORklHX0hBVkVfRE1BX0FUVFJTPXkKQ09ORklH
X0hBVkVfRE1BX0NPTlRJR1VPVVM9eQpDT05GSUdfR0VORVJJQ19TTVBfSURMRV9USFJFQUQ9
eQpDT05GSUdfSEFWRV9SRUdTX0FORF9TVEFDS19BQ0NFU1NfQVBJPXkKQ09ORklHX0hBVkVf
RE1BX0FQSV9ERUJVRz15CkNPTkZJR19IQVZFX0hXX0JSRUFLUE9JTlQ9eQpDT05GSUdfSEFW
RV9NSVhFRF9CUkVBS1BPSU5UU19SRUdTPXkKQ09ORklHX0hBVkVfVVNFUl9SRVRVUk5fTk9U
SUZJRVI9eQpDT05GSUdfSEFWRV9QRVJGX0VWRU5UU19OTUk9eQpDT05GSUdfSEFWRV9QRVJG
X1JFR1M9eQpDT05GSUdfSEFWRV9QRVJGX1VTRVJfU1RBQ0tfRFVNUD15CkNPTkZJR19IQVZF
X0FSQ0hfSlVNUF9MQUJFTD15CkNPTkZJR19BUkNIX0hBVkVfTk1JX1NBRkVfQ01QWENIRz15
CkNPTkZJR19IQVZFX0FMSUdORURfU1RSVUNUX1BBR0U9eQpDT05GSUdfSEFWRV9DTVBYQ0hH
X0xPQ0FMPXkKQ09ORklHX0hBVkVfQ01QWENIR19ET1VCTEU9eQpDT05GSUdfSEFWRV9BUkNI
X1NFQ0NPTVBfRklMVEVSPXkKQ09ORklHX1NFQ0NPTVBfRklMVEVSPXkKQ09ORklHX0hBVkVf
Q0NfU1RBQ0tQUk9URUNUT1I9eQojIENPTkZJR19DQ19TVEFDS1BST1RFQ1RPUiBpcyBub3Qg
c2V0CkNPTkZJR19DQ19TVEFDS1BST1RFQ1RPUl9OT05FPXkKIyBDT05GSUdfQ0NfU1RBQ0tQ
Uk9URUNUT1JfUkVHVUxBUiBpcyBub3Qgc2V0CiMgQ09ORklHX0NDX1NUQUNLUFJPVEVDVE9S
X1NUUk9ORyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0NPTlRFWFRfVFJBQ0tJTkc9eQpDT05G
SUdfSEFWRV9WSVJUX0NQVV9BQ0NPVU5USU5HX0dFTj15CkNPTkZJR19IQVZFX0lSUV9USU1F
X0FDQ09VTlRJTkc9eQpDT05GSUdfSEFWRV9BUkNIX1RSQU5TUEFSRU5UX0hVR0VQQUdFPXkK
Q09ORklHX0hBVkVfQVJDSF9TT0ZUX0RJUlRZPXkKQ09ORklHX01PRFVMRVNfVVNFX0VMRl9S
RUxBPXkKQ09ORklHX0hBVkVfSVJRX0VYSVRfT05fSVJRX1NUQUNLPXkKCiMKIyBHQ09WLWJh
c2VkIGtlcm5lbCBwcm9maWxpbmcKIwojIENPTkZJR19IQVZFX0dFTkVSSUNfRE1BX0NPSEVS
RU5UIGlzIG5vdCBzZXQKQ09ORklHX1NMQUJJTkZPPXkKQ09ORklHX1JUX01VVEVYRVM9eQpD
T05GSUdfQkFTRV9TTUFMTD0wCkNPTkZJR19NT0RVTEVTPXkKIyBDT05GSUdfTU9EVUxFX0ZP
UkNFX0xPQUQgaXMgbm90IHNldApDT05GSUdfTU9EVUxFX1VOTE9BRD15CiMgQ09ORklHX01P
RFVMRV9GT1JDRV9VTkxPQUQgaXMgbm90IHNldAojIENPTkZJR19NT0RWRVJTSU9OUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX01PRFVMRV9TUkNWRVJTSU9OX0FMTCBpcyBub3Qgc2V0CiMgQ09O
RklHX01PRFVMRV9TSUcgaXMgbm90IHNldApDT05GSUdfU1RPUF9NQUNISU5FPXkKQ09ORklH
X0JMT0NLPXkKQ09ORklHX0JMS19ERVZfQlNHPXkKQ09ORklHX0JMS19ERVZfQlNHTElCPXkK
Q09ORklHX0JMS19ERVZfSU5URUdSSVRZPXkKQ09ORklHX0JMS19ERVZfVEhST1RUTElORz15
CkNPTkZJR19CTEtfQ01ETElORV9QQVJTRVI9eQoKIwojIFBhcnRpdGlvbiBUeXBlcwojCiMg
Q09ORklHX1BBUlRJVElPTl9BRFZBTkNFRCBpcyBub3Qgc2V0CkNPTkZJR19NU0RPU19QQVJU
SVRJT049eQpDT05GSUdfRUZJX1BBUlRJVElPTj15CgojCiMgSU8gU2NoZWR1bGVycwojCkNP
TkZJR19JT1NDSEVEX05PT1A9eQpDT05GSUdfSU9TQ0hFRF9ERUFETElORT15CkNPTkZJR19J
T1NDSEVEX0NGUT15CkNPTkZJR19DRlFfR1JPVVBfSU9TQ0hFRD15CiMgQ09ORklHX0RFRkFV
TFRfREVBRExJTkUgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9DRlE9eQojIENPTkZJR19E
RUZBVUxUX05PT1AgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9JT1NDSEVEPSJjZnEiCkNP
TkZJR19QQURBVEE9eQpDT05GSUdfVU5JTkxJTkVfU1BJTl9VTkxPQ0s9eQpDT05GSUdfSU5M
SU5FX1NQSU5fVU5MT0NLX0lSUT15CkNPTkZJR19JTkxJTkVfUkVBRF9VTkxPQ0s9eQpDT05G
SUdfSU5MSU5FX1JFQURfVU5MT0NLX0lSUT15CkNPTkZJR19JTkxJTkVfV1JJVEVfVU5MT0NL
PXkKQ09ORklHX0lOTElORV9XUklURV9VTkxPQ0tfSVJRPXkKQ09ORklHX01VVEVYX1NQSU5f
T05fT1dORVI9eQpDT05GSUdfQVJDSF9VU0VfUVVFVUVfUldMT0NLPXkKQ09ORklHX1FVRVVF
X1JXTE9DSz15CkNPTkZJR19GUkVFWkVSPXkKCiMKIyBQcm9jZXNzb3IgdHlwZSBhbmQgZmVh
dHVyZXMKIwpDT05GSUdfWk9ORV9ETUE9eQpDT05GSUdfU01QPXkKQ09ORklHX1g4Nl9YMkFQ
SUM9eQpDT05GSUdfWDg2X01QUEFSU0U9eQojIENPTkZJR19YODZfRVhURU5ERURfUExBVEZP
Uk0gaXMgbm90IHNldAojIENPTkZJR19YODZfSU5URUxfTFBTUyBpcyBub3Qgc2V0CkNPTkZJ
R19YODZfU1VQUE9SVFNfTUVNT1JZX0ZBSUxVUkU9eQpDT05GSUdfU0NIRURfT01JVF9GUkFN
RV9QT0lOVEVSPXkKQ09ORklHX0hZUEVSVklTT1JfR1VFU1Q9eQpDT05GSUdfUEFSQVZJUlQ9
eQojIENPTkZJR19QQVJBVklSVF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19QQVJBVklSVF9T
UElOTE9DS1M9eQpDT05GSUdfWEVOPXkKQ09ORklHX1hFTl9ET00wPXkKQ09ORklHX1hFTl9Q
VkhWTT15CkNPTkZJR19YRU5fTUFYX0RPTUFJTl9NRU1PUlk9NTAwCkNPTkZJR19YRU5fU0FW
RV9SRVNUT1JFPXkKIyBDT05GSUdfWEVOX1BWSCBpcyBub3Qgc2V0CiMgQ09ORklHX0tWTV9H
VUVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBUkFWSVJUX1RJTUVfQUNDT1VOVElORyBpcyBu
b3Qgc2V0CkNPTkZJR19QQVJBVklSVF9DTE9DSz15CkNPTkZJR19OT19CT09UTUVNPXkKIyBD
T05GSUdfTUVNVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX01LOCBpcyBub3Qgc2V0CiMgQ09O
RklHX01QU0MgaXMgbm90IHNldAojIENPTkZJR19NQ09SRTIgaXMgbm90IHNldAojIENPTkZJ
R19NQVRPTSBpcyBub3Qgc2V0CkNPTkZJR19HRU5FUklDX0NQVT15CkNPTkZJR19YODZfSU5U
RVJOT0RFX0NBQ0hFX1NISUZUPTYKQ09ORklHX1g4Nl9MMV9DQUNIRV9TSElGVD02CkNPTkZJ
R19YODZfVFNDPXkKQ09ORklHX1g4Nl9DTVBYQ0hHNjQ9eQpDT05GSUdfWDg2X0NNT1Y9eQpD
T05GSUdfWDg2X01JTklNVU1fQ1BVX0ZBTUlMWT02NApDT05GSUdfWDg2X0RFQlVHQ1RMTVNS
PXkKQ09ORklHX0NQVV9TVVBfSU5URUw9eQpDT05GSUdfQ1BVX1NVUF9BTUQ9eQpDT05GSUdf
Q1BVX1NVUF9DRU5UQVVSPXkKQ09ORklHX0hQRVRfVElNRVI9eQpDT05GSUdfSFBFVF9FTVVM
QVRFX1JUQz15CkNPTkZJR19ETUk9eQpDT05GSUdfR0FSVF9JT01NVT15CiMgQ09ORklHX0NB
TEdBUllfSU9NTVUgaXMgbm90IHNldApDT05GSUdfU1dJT1RMQj15CkNPTkZJR19JT01NVV9I
RUxQRVI9eQojIENPTkZJR19NQVhTTVAgaXMgbm90IHNldApDT05GSUdfTlJfQ1BVUz0xNgpD
T05GSUdfU0NIRURfU01UPXkKQ09ORklHX1NDSEVEX01DPXkKIyBDT05GSUdfUFJFRU1QVF9O
T05FIGlzIG5vdCBzZXQKQ09ORklHX1BSRUVNUFRfVk9MVU5UQVJZPXkKIyBDT05GSUdfUFJF
RU1QVCBpcyBub3Qgc2V0CkNPTkZJR19YODZfTE9DQUxfQVBJQz15CkNPTkZJR19YODZfSU9f
QVBJQz15CkNPTkZJR19YODZfUkVST1VURV9GT1JfQlJPS0VOX0JPT1RfSVJRUz15CkNPTkZJ
R19YODZfTUNFPXkKQ09ORklHX1g4Nl9NQ0VfSU5URUw9eQpDT05GSUdfWDg2X01DRV9BTUQ9
eQpDT05GSUdfWDg2X01DRV9USFJFU0hPTEQ9eQojIENPTkZJR19YODZfTUNFX0lOSkVDVCBp
cyBub3Qgc2V0CkNPTkZJR19YODZfVEhFUk1BTF9WRUNUT1I9eQpDT05GSUdfWDg2XzE2QklU
PXkKQ09ORklHX1g4Nl9FU1BGSVg2ND15CiMgQ09ORklHX0k4SyBpcyBub3Qgc2V0CkNPTkZJ
R19NSUNST0NPREU9eQpDT05GSUdfTUlDUk9DT0RFX0lOVEVMPXkKQ09ORklHX01JQ1JPQ09E
RV9BTUQ9eQpDT05GSUdfTUlDUk9DT0RFX09MRF9JTlRFUkZBQ0U9eQpDT05GSUdfTUlDUk9D
T0RFX0lOVEVMX0VBUkxZPXkKQ09ORklHX01JQ1JPQ09ERV9BTURfRUFSTFk9eQpDT05GSUdf
TUlDUk9DT0RFX0VBUkxZPXkKQ09ORklHX1g4Nl9NU1I9eQpDT05GSUdfWDg2X0NQVUlEPXkK
Q09ORklHX0FSQ0hfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfQVJDSF9ETUFfQUREUl9U
XzY0QklUPXkKQ09ORklHX0RJUkVDVF9HQlBBR0VTPXkKIyBDT05GSUdfTlVNQSBpcyBub3Qg
c2V0CkNPTkZJR19BUkNIX1NQQVJTRU1FTV9FTkFCTEU9eQpDT05GSUdfQVJDSF9TUEFSU0VN
RU1fREVGQVVMVD15CkNPTkZJR19BUkNIX1NFTEVDVF9NRU1PUllfTU9ERUw9eQpDT05GSUdf
QVJDSF9QUk9DX0tDT1JFX1RFWFQ9eQpDT05GSUdfSUxMRUdBTF9QT0lOVEVSX1ZBTFVFPTB4
ZGVhZDAwMDAwMDAwMDAwMApDT05GSUdfU0VMRUNUX01FTU9SWV9NT0RFTD15CkNPTkZJR19T
UEFSU0VNRU1fTUFOVUFMPXkKQ09ORklHX1NQQVJTRU1FTT15CkNPTkZJR19IQVZFX01FTU9S
WV9QUkVTRU5UPXkKQ09ORklHX1NQQVJTRU1FTV9FWFRSRU1FPXkKQ09ORklHX1NQQVJTRU1F
TV9WTUVNTUFQX0VOQUJMRT15CkNPTkZJR19TUEFSU0VNRU1fQUxMT0NfTUVNX01BUF9UT0dF
VEhFUj15CkNPTkZJR19TUEFSU0VNRU1fVk1FTU1BUD15CkNPTkZJR19IQVZFX01FTUJMT0NL
PXkKQ09ORklHX0hBVkVfTUVNQkxPQ0tfTk9ERV9NQVA9eQpDT05GSUdfQVJDSF9ESVNDQVJE
X01FTUJMT0NLPXkKQ09ORklHX01FTU9SWV9JU09MQVRJT049eQojIENPTkZJR19IQVZFX0JP
T1RNRU1fSU5GT19OT0RFIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVNT1JZX0hPVFBMVUcgaXMg
bm90IHNldApDT05GSUdfUEFHRUZMQUdTX0VYVEVOREVEPXkKQ09ORklHX1NQTElUX1BUTE9D
S19DUFVTPTQKQ09ORklHX0FSQ0hfRU5BQkxFX1NQTElUX1BNRF9QVExPQ0s9eQpDT05GSUdf
QkFMTE9PTl9DT01QQUNUSU9OPXkKQ09ORklHX0NPTVBBQ1RJT049eQpDT05GSUdfTUlHUkFU
SU9OPXkKQ09ORklHX0FSQ0hfRU5BQkxFX0hVR0VQQUdFX01JR1JBVElPTj15CkNPTkZJR19Q
SFlTX0FERFJfVF82NEJJVD15CkNPTkZJR19aT05FX0RNQV9GTEFHPTEKQ09ORklHX0JPVU5D
RT15CkNPTkZJR19ORUVEX0JPVU5DRV9QT09MPXkKQ09ORklHX1ZJUlRfVE9fQlVTPXkKQ09O
RklHX01NVV9OT1RJRklFUj15CkNPTkZJR19LU009eQpDT05GSUdfREVGQVVMVF9NTUFQX01J
Tl9BRERSPTY1NTM2CkNPTkZJR19BUkNIX1NVUFBPUlRTX01FTU9SWV9GQUlMVVJFPXkKQ09O
RklHX01FTU9SWV9GQUlMVVJFPXkKIyBDT05GSUdfSFdQT0lTT05fSU5KRUNUIGlzIG5vdCBz
ZXQKQ09ORklHX1RSQU5TUEFSRU5UX0hVR0VQQUdFPXkKIyBDT05GSUdfVFJBTlNQQVJFTlRf
SFVHRVBBR0VfQUxXQVlTIGlzIG5vdCBzZXQKQ09ORklHX1RSQU5TUEFSRU5UX0hVR0VQQUdF
X01BRFZJU0U9eQojIENPTkZJR19DTEVBTkNBQ0hFIGlzIG5vdCBzZXQKIyBDT05GSUdfRlJP
TlRTV0FQIGlzIG5vdCBzZXQKIyBDT05GSUdfQ01BIGlzIG5vdCBzZXQKIyBDT05GSUdfWkJV
RCBpcyBub3Qgc2V0CiMgQ09ORklHX1pTTUFMTE9DIGlzIG5vdCBzZXQKQ09ORklHX0dFTkVS
SUNfRUFSTFlfSU9SRU1BUD15CiMgQ09ORklHX1g4Nl9DSEVDS19CSU9TX0NPUlJVUFRJT04g
aXMgbm90IHNldApDT05GSUdfWDg2X1JFU0VSVkVfTE9XPTY0CkNPTkZJR19NVFJSPXkKQ09O
RklHX01UUlJfU0FOSVRJWkVSPXkKQ09ORklHX01UUlJfU0FOSVRJWkVSX0VOQUJMRV9ERUZB
VUxUPTAKQ09ORklHX01UUlJfU0FOSVRJWkVSX1NQQVJFX1JFR19OUl9ERUZBVUxUPTEKQ09O
RklHX1g4Nl9QQVQ9eQpDT05GSUdfQVJDSF9VU0VTX1BHX1VOQ0FDSEVEPXkKQ09ORklHX0FS
Q0hfUkFORE9NPXkKQ09ORklHX1g4Nl9TTUFQPXkKQ09ORklHX0VGST15CkNPTkZJR19FRklf
U1RVQj15CiMgQ09ORklHX0VGSV9NSVhFRCBpcyBub3Qgc2V0CkNPTkZJR19TRUNDT01QPXkK
IyBDT05GSUdfSFpfMTAwIGlzIG5vdCBzZXQKQ09ORklHX0haXzI1MD15CiMgQ09ORklHX0ha
XzMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0haXzEwMDAgaXMgbm90IHNldApDT05GSUdfSFo9
MjUwCkNPTkZJR19TQ0hFRF9IUlRJQ0s9eQpDT05GSUdfS0VYRUM9eQpDT05GSUdfQ1JBU0hf
RFVNUD15CkNPTkZJR19QSFlTSUNBTF9TVEFSVD0weDEwMDAwMDAKQ09ORklHX1JFTE9DQVRB
QkxFPXkKIyBDT05GSUdfUkFORE9NSVpFX0JBU0UgaXMgbm90IHNldApDT05GSUdfUEhZU0lD
QUxfQUxJR049MHgxMDAwMDAwCkNPTkZJR19IT1RQTFVHX0NQVT15CiMgQ09ORklHX0JPT1RQ
QVJBTV9IT1RQTFVHX0NQVTAgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19IT1RQTFVHX0NQ
VTAgaXMgbm90IHNldAojIENPTkZJR19DTURMSU5FX0JPT0wgaXMgbm90IHNldApDT05GSUdf
QVJDSF9FTkFCTEVfTUVNT1JZX0hPVFBMVUc9eQoKIwojIFBvd2VyIG1hbmFnZW1lbnQgYW5k
IEFDUEkgb3B0aW9ucwojCiMgQ09ORklHX1NVU1BFTkQgaXMgbm90IHNldApDT05GSUdfSElC
RVJOQVRFX0NBTExCQUNLUz15CiMgQ09ORklHX0hJQkVSTkFUSU9OIGlzIG5vdCBzZXQKQ09O
RklHX1BNX1NMRUVQPXkKQ09ORklHX1BNX1NMRUVQX1NNUD15CiMgQ09ORklHX1BNX0FVVE9T
TEVFUCBpcyBub3Qgc2V0CiMgQ09ORklHX1BNX1dBS0VMT0NLUyBpcyBub3Qgc2V0CkNPTkZJ
R19QTV9SVU5USU1FPXkKQ09ORklHX1BNPXkKIyBDT05GSUdfUE1fREVCVUcgaXMgbm90IHNl
dAojIENPTkZJR19XUV9QT1dFUl9FRkZJQ0lFTlRfREVGQVVMVCBpcyBub3Qgc2V0CkNPTkZJ
R19BQ1BJPXkKIyBDT05GSUdfQUNQSV9QUk9DRlNfUE9XRVIgaXMgbm90IHNldAojIENPTkZJ
R19BQ1BJX0VDX0RFQlVHRlMgaXMgbm90IHNldApDT05GSUdfQUNQSV9BQz15CkNPTkZJR19B
Q1BJX0JBVFRFUlk9eQpDT05GSUdfQUNQSV9CVVRUT049eQpDT05GSUdfQUNQSV9WSURFTz15
CkNPTkZJR19BQ1BJX0ZBTj15CkNPTkZJR19BQ1BJX0RPQ0s9eQpDT05GSUdfQUNQSV9QUk9D
RVNTT1I9eQpDT05GSUdfQUNQSV9JUE1JPXkKQ09ORklHX0FDUElfSE9UUExVR19DUFU9eQpD
T05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUj15CkNPTkZJR19BQ1BJX1RIRVJNQUw9
eQpDT05GSUdfQUNQSV9DVVNUT01fRFNEVF9GSUxFPSIiCiMgQ09ORklHX0FDUElfQ1VTVE9N
X0RTRFQgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX0lOSVRSRF9UQUJMRV9PVkVSUklERSBp
cyBub3Qgc2V0CiMgQ09ORklHX0FDUElfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19BQ1BJ
X1BDSV9TTE9UIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9QTV9USU1FUj15CkNPTkZJR19BQ1BJ
X0NPTlRBSU5FUj15CiMgQ09ORklHX0FDUElfU0JTIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNQ
SV9IRUQgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX0JHUlQgaXMgbm90IHNldAojIENPTkZJ
R19BQ1BJX1JFRFVDRURfSEFSRFdBUkVfT05MWSBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElf
QVBFSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElfRVhUTE9HIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0ZJIGlzIG5vdCBzZXQKCiMKIyBDUFUgRnJlcXVlbmN5IHNjYWxpbmcKIwpDT05GSUdf
Q1BVX0ZSRVE9eQpDT05GSUdfQ1BVX0ZSRVFfR09WX0NPTU1PTj15CkNPTkZJR19DUFVfRlJF
UV9TVEFUPXkKIyBDT05GSUdfQ1BVX0ZSRVFfU1RBVF9ERVRBSUxTIGlzIG5vdCBzZXQKIyBD
T05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9HT1ZfUEVSRk9STUFOQ0UgaXMgbm90IHNldAojIENP
TkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9VU0VSU1BBQ0UgaXMgbm90IHNldApDT05GSUdf
Q1BVX0ZSRVFfREVGQVVMVF9HT1ZfT05ERU1BTkQ9eQojIENPTkZJR19DUFVfRlJFUV9ERUZB
VUxUX0dPVl9DT05TRVJWQVRJVkUgaXMgbm90IHNldApDT05GSUdfQ1BVX0ZSRVFfR09WX1BF
UkZPUk1BTkNFPXkKIyBDT05GSUdfQ1BVX0ZSRVFfR09WX1BPV0VSU0FWRSBpcyBub3Qgc2V0
CiMgQ09ORklHX0NQVV9GUkVRX0dPVl9VU0VSU1BBQ0UgaXMgbm90IHNldApDT05GSUdfQ1BV
X0ZSRVFfR09WX09OREVNQU5EPXkKIyBDT05GSUdfQ1BVX0ZSRVFfR09WX0NPTlNFUlZBVElW
RSBpcyBub3Qgc2V0CgojCiMgeDg2IENQVSBmcmVxdWVuY3kgc2NhbGluZyBkcml2ZXJzCiMK
Q09ORklHX1g4Nl9JTlRFTF9QU1RBVEU9eQpDT05GSUdfWDg2X1BDQ19DUFVGUkVRPW0KQ09O
RklHX1g4Nl9BQ1BJX0NQVUZSRVE9bQpDT05GSUdfWDg2X0FDUElfQ1BVRlJFUV9DUEI9eQpD
T05GSUdfWDg2X1BPV0VSTk9XX0s4PW0KIyBDT05GSUdfWDg2X0FNRF9GUkVRX1NFTlNJVElW
SVRZIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9TUEVFRFNURVBfQ0VOVFJJTk89bQpDT05GSUdf
WDg2X1A0X0NMT0NLTU9EPW0KCiMKIyBzaGFyZWQgb3B0aW9ucwojCkNPTkZJR19YODZfU1BF
RURTVEVQX0xJQj1tCgojCiMgQ1BVIElkbGUKIwpDT05GSUdfQ1BVX0lETEU9eQojIENPTkZJ
R19DUFVfSURMRV9NVUxUSVBMRV9EUklWRVJTIGlzIG5vdCBzZXQKQ09ORklHX0NQVV9JRExF
X0dPVl9MQURERVI9eQpDT05GSUdfQ1BVX0lETEVfR09WX01FTlU9eQojIENPTkZJR19BUkNI
X05FRURTX0NQVV9JRExFX0NPVVBMRUQgaXMgbm90IHNldApDT05GSUdfSU5URUxfSURMRT15
CgojCiMgTWVtb3J5IHBvd2VyIHNhdmluZ3MKIwpDT05GSUdfSTczMDBfSURMRV9JT0FUX0NI
QU5ORUw9eQpDT05GSUdfSTczMDBfSURMRT15CgojCiMgQnVzIG9wdGlvbnMgKFBDSSBldGMu
KQojCkNPTkZJR19QQ0k9eQpDT05GSUdfUENJX0RJUkVDVD15CkNPTkZJR19QQ0lfTU1DT05G
SUc9eQpDT05GSUdfUENJX1hFTj15CkNPTkZJR19QQ0lfRE9NQUlOUz15CkNPTkZJR19QQ0lF
UE9SVEJVUz15CkNPTkZJR19IT1RQTFVHX1BDSV9QQ0lFPXkKQ09ORklHX1BDSUVBRVI9eQoj
IENPTkZJR19QQ0lFX0VDUkMgaXMgbm90IHNldAojIENPTkZJR19QQ0lFQUVSX0lOSkVDVCBp
cyBub3Qgc2V0CkNPTkZJR19QQ0lFQVNQTT15CiMgQ09ORklHX1BDSUVBU1BNX0RFQlVHIGlz
IG5vdCBzZXQKQ09ORklHX1BDSUVBU1BNX0RFRkFVTFQ9eQojIENPTkZJR19QQ0lFQVNQTV9Q
T1dFUlNBVkUgaXMgbm90IHNldAojIENPTkZJR19QQ0lFQVNQTV9QRVJGT1JNQU5DRSBpcyBu
b3Qgc2V0CkNPTkZJR19QQ0lFX1BNRT15CkNPTkZJR19QQ0lfTVNJPXkKIyBDT05GSUdfUENJ
X0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfUENJX1JFQUxMT0NfRU5BQkxFX0FVVE8gaXMg
bm90IHNldApDT05GSUdfUENJX1NUVUI9eQpDT05GSUdfWEVOX1BDSURFVl9GUk9OVEVORD15
CkNPTkZJR19IVF9JUlE9eQpDT05GSUdfUENJX0FUUz15CkNPTkZJR19QQ0lfSU9WPXkKQ09O
RklHX1BDSV9QUkk9eQpDT05GSUdfUENJX1BBU0lEPXkKQ09ORklHX1BDSV9JT0FQSUM9eQpD
T05GSUdfUENJX0xBQkVMPXkKCiMKIyBQQ0kgaG9zdCBjb250cm9sbGVyIGRyaXZlcnMKIwpD
T05GSUdfSVNBX0RNQV9BUEk9eQpDT05GSUdfQU1EX05CPXkKIyBDT05GSUdfUENDQVJEIGlz
IG5vdCBzZXQKQ09ORklHX0hPVFBMVUdfUENJPXkKQ09ORklHX0hPVFBMVUdfUENJX0FDUEk9
eQpDT05GSUdfSE9UUExVR19QQ0lfQUNQSV9JQk09eQpDT05GSUdfSE9UUExVR19QQ0lfQ1BD
ST15CkNPTkZJR19IT1RQTFVHX1BDSV9DUENJX1pUNTU1MD15CkNPTkZJR19IT1RQTFVHX1BD
SV9DUENJX0dFTkVSSUM9eQpDT05GSUdfSE9UUExVR19QQ0lfU0hQQz15CiMgQ09ORklHX1JB
UElESU8gaXMgbm90IHNldAojIENPTkZJR19YODZfU1lTRkIgaXMgbm90IHNldAoKIwojIEV4
ZWN1dGFibGUgZmlsZSBmb3JtYXRzIC8gRW11bGF0aW9ucwojCkNPTkZJR19CSU5GTVRfRUxG
PXkKQ09ORklHX0FSQ0hfQklORk1UX0VMRl9SQU5ET01JWkVfUElFPXkKQ09ORklHX0NPUkVf
RFVNUF9ERUZBVUxUX0VMRl9IRUFERVJTPXkKQ09ORklHX0JJTkZNVF9TQ1JJUFQ9eQojIENP
TkZJR19IQVZFX0FPVVQgaXMgbm90IHNldApDT05GSUdfQklORk1UX01JU0M9eQpDT05GSUdf
Q09SRURVTVA9eQojIENPTkZJR19JQTMyX0VNVUxBVElPTiBpcyBub3Qgc2V0CkNPTkZJR19Y
ODZfREVWX0RNQV9PUFM9eQpDT05GSUdfSU9TRl9NQkk9bQpDT05GSUdfTkVUPXkKCiMKIyBO
ZXR3b3JraW5nIG9wdGlvbnMKIwpDT05GSUdfUEFDS0VUPXkKIyBDT05GSUdfUEFDS0VUX0RJ
QUcgaXMgbm90IHNldApDT05GSUdfVU5JWD15CiMgQ09ORklHX1VOSVhfRElBRyBpcyBub3Qg
c2V0CkNPTkZJR19YRlJNPXkKQ09ORklHX1hGUk1fQUxHTz15CkNPTkZJR19YRlJNX1VTRVI9
eQpDT05GSUdfWEZSTV9TVUJfUE9MSUNZPXkKQ09ORklHX1hGUk1fTUlHUkFURT15CiMgQ09O
RklHX1hGUk1fU1RBVElTVElDUyBpcyBub3Qgc2V0CkNPTkZJR19YRlJNX0lQQ09NUD15CkNP
TkZJR19ORVRfS0VZPXkKQ09ORklHX05FVF9LRVlfTUlHUkFURT15CkNPTkZJR19JTkVUPXkK
Q09ORklHX0lQX01VTFRJQ0FTVD15CkNPTkZJR19JUF9BRFZBTkNFRF9ST1VURVI9eQpDT05G
SUdfSVBfRklCX1RSSUVfU1RBVFM9eQpDT05GSUdfSVBfTVVMVElQTEVfVEFCTEVTPXkKQ09O
RklHX0lQX1JPVVRFX01VTFRJUEFUSD15CkNPTkZJR19JUF9ST1VURV9WRVJCT1NFPXkKQ09O
RklHX0lQX1JPVVRFX0NMQVNTSUQ9eQojIENPTkZJR19JUF9QTlAgaXMgbm90IHNldAojIENP
TkZJR19ORVRfSVBJUCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9JUEdSRV9ERU1VWCBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9JUF9UVU5ORUwgaXMgbm90IHNldAojIENPTkZJR19JUF9N
Uk9VVEUgaXMgbm90IHNldApDT05GSUdfU1lOX0NPT0tJRVM9eQojIENPTkZJR19ORVRfSVBW
VEkgaXMgbm90IHNldApDT05GSUdfSU5FVF9BSD15CkNPTkZJR19JTkVUX0VTUD15CkNPTkZJ
R19JTkVUX0lQQ09NUD15CkNPTkZJR19JTkVUX1hGUk1fVFVOTkVMPXkKQ09ORklHX0lORVRf
VFVOTkVMPXkKQ09ORklHX0lORVRfWEZSTV9NT0RFX1RSQU5TUE9SVD15CkNPTkZJR19JTkVU
X1hGUk1fTU9ERV9UVU5ORUw9eQpDT05GSUdfSU5FVF9YRlJNX01PREVfQkVFVD15CkNPTkZJ
R19JTkVUX0xSTz15CkNPTkZJR19JTkVUX0RJQUc9eQpDT05GSUdfSU5FVF9UQ1BfRElBRz15
CiMgQ09ORklHX0lORVRfVURQX0RJQUcgaXMgbm90IHNldAojIENPTkZJR19UQ1BfQ09OR19B
RFZBTkNFRCBpcyBub3Qgc2V0CkNPTkZJR19UQ1BfQ09OR19DVUJJQz15CkNPTkZJR19ERUZB
VUxUX1RDUF9DT05HPSJjdWJpYyIKQ09ORklHX1RDUF9NRDVTSUc9eQojIENPTkZJR19JUFY2
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUTEFCRUwgaXMgbm90IHNldApDT05GSUdfTkVUV09S
S19TRUNNQVJLPXkKQ09ORklHX05FVF9QVFBfQ0xBU1NJRlk9eQojIENPTkZJR19ORVRXT1JL
X1BIWV9USU1FU1RBTVBJTkcgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSPXkKIyBDT05G
SUdfTkVURklMVEVSX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9BRFZBTkNF
RD15CiMgQ09ORklHX0JSSURHRV9ORVRGSUxURVIgaXMgbm90IHNldAoKIwojIENvcmUgTmV0
ZmlsdGVyIENvbmZpZ3VyYXRpb24KIwpDT05GSUdfTkVURklMVEVSX05FVExJTks9eQpDT05G
SUdfTkVURklMVEVSX05FVExJTktfQUNDVD15CkNPTkZJR19ORVRGSUxURVJfTkVUTElOS19R
VUVVRT15CkNPTkZJR19ORVRGSUxURVJfTkVUTElOS19MT0c9eQpDT05GSUdfTkZfQ09OTlRS
QUNLPXkKQ09ORklHX05GX0NPTk5UUkFDS19NQVJLPXkKQ09ORklHX05GX0NPTk5UUkFDS19T
RUNNQVJLPXkKQ09ORklHX05GX0NPTk5UUkFDS19aT05FUz15CkNPTkZJR19ORl9DT05OVFJB
Q0tfUFJPQ0ZTPXkKQ09ORklHX05GX0NPTk5UUkFDS19FVkVOVFM9eQojIENPTkZJR19ORl9D
T05OVFJBQ0tfVElNRU9VVCBpcyBub3Qgc2V0CkNPTkZJR19ORl9DT05OVFJBQ0tfVElNRVNU
QU1QPXkKIyBDT05GSUdfTkZfQ1RfUFJPVE9fRENDUCBpcyBub3Qgc2V0CiMgQ09ORklHX05G
X0NUX1BST1RPX1NDVFAgaXMgbm90IHNldApDT05GSUdfTkZfQ1RfUFJPVE9fVURQTElURT15
CiMgQ09ORklHX05GX0NPTk5UUkFDS19BTUFOREEgaXMgbm90IHNldAojIENPTkZJR19ORl9D
T05OVFJBQ0tfRlRQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX0gzMjMgaXMg
bm90IHNldAojIENPTkZJR19ORl9DT05OVFJBQ0tfSVJDIGlzIG5vdCBzZXQKIyBDT05GSUdf
TkZfQ09OTlRSQUNLX05FVEJJT1NfTlMgaXMgbm90IHNldAojIENPTkZJR19ORl9DT05OVFJB
Q0tfU05NUCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0NPTk5UUkFDS19QUFRQIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1NBTkUgaXMgbm90IHNldAojIENPTkZJR19ORl9D
T05OVFJBQ0tfU0lQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1RGVFAgaXMg
bm90IHNldApDT05GSUdfTkZfQ1RfTkVUTElOSz15CiMgQ09ORklHX05GX0NUX05FVExJTktf
VElNRU9VVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9ORVRMSU5LX1FVRVVFX0NU
IGlzIG5vdCBzZXQKQ09ORklHX05GX05BVD15CkNPTkZJR19ORl9OQVRfTkVFREVEPXkKQ09O
RklHX05GX05BVF9QUk9UT19VRFBMSVRFPXkKIyBDT05GSUdfTkZfTkFUX0FNQU5EQSBpcyBu
b3Qgc2V0CiMgQ09ORklHX05GX05BVF9GVFAgaXMgbm90IHNldAojIENPTkZJR19ORl9OQVRf
SVJDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfTkFUX1NJUCBpcyBub3Qgc2V0CiMgQ09ORklH
X05GX05BVF9URlRQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfVEFCTEVTIGlzIG5vdCBzZXQK
Q09ORklHX05FVEZJTFRFUl9YVEFCTEVTPXkKCiMKIyBYdGFibGVzIGNvbWJpbmVkIG1vZHVs
ZXMKIwpDT05GSUdfTkVURklMVEVSX1hUX01BUks9eQpDT05GSUdfTkVURklMVEVSX1hUX0NP
Tk5NQVJLPXkKQ09ORklHX05FVEZJTFRFUl9YVF9TRVQ9eQoKIwojIFh0YWJsZXMgdGFyZ2V0
cwojCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0FVRElUPXkKQ09ORklHX05FVEZJTFRF
Ul9YVF9UQVJHRVRfQ0hFQ0tTVU09eQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9DTEFT
U0lGWT15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NPTk5NQVJLPXkKQ09ORklHX05F
VEZJTFRFUl9YVF9UQVJHRVRfQ09OTlNFQ01BUks9eQpDT05GSUdfTkVURklMVEVSX1hUX1RB
UkdFVF9DVD15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0RTQ1A9eQpDT05GSUdfTkVU
RklMVEVSX1hUX1RBUkdFVF9ITD15CiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfSE1B
UksgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9JRExFVElNRVI9eQpD
T05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9MRUQ9eQojIENPTkZJR19ORVRGSUxURVJfWFRf
VEFSR0VUX0xPRyBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX01BUks9
eQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9ORVRNQVA9eQpDT05GSUdfTkVURklMVEVS
X1hUX1RBUkdFVF9ORkxPRz15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX05GUVVFVUU9
eQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX05PVFJBQ0sgaXMgbm90IHNldApDT05G
SUdfTkVURklMVEVSX1hUX1RBUkdFVF9SQVRFRVNUPXkKQ09ORklHX05FVEZJTFRFUl9YVF9U
QVJHRVRfUkVESVJFQ1Q9eQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9URUU9eQpDT05G
SUdfTkVURklMVEVSX1hUX1RBUkdFVF9UUFJPWFk9eQpDT05GSUdfTkVURklMVEVSX1hUX1RB
UkdFVF9UUkFDRT15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1NFQ01BUks9eQpDT05G
SUdfTkVURklMVEVSX1hUX1RBUkdFVF9UQ1BNU1M9eQpDT05GSUdfTkVURklMVEVSX1hUX1RB
UkdFVF9UQ1BPUFRTVFJJUD15CgojCiMgWHRhYmxlcyBtYXRjaGVzCiMKQ09ORklHX05FVEZJ
TFRFUl9YVF9NQVRDSF9BRERSVFlQRT15CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9C
UEYgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ0dST1VQIGlzIG5v
dCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DTFVTVEVSPXkKQ09ORklHX05FVEZJ
TFRFUl9YVF9NQVRDSF9DT01NRU5UPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05O
QllURVM9eQojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ09OTkxBQkVMIGlzIG5vdCBz
ZXQKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OTElNSVQ9eQpDT05GSUdfTkVURklM
VEVSX1hUX01BVENIX0NPTk5NQVJLPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05O
VFJBQ0s9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0NQVT15CkNPTkZJR19ORVRGSUxU
RVJfWFRfTUFUQ0hfRENDUD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfREVWR1JPVVA9
eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0RTQ1A9eQpDT05GSUdfTkVURklMVEVSX1hU
X01BVENIX0VDTj15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfRVNQPXkKQ09ORklHX05F
VEZJTFRFUl9YVF9NQVRDSF9IQVNITElNSVQ9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENI
X0hFTFBFUj15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSEw9eQojIENPTkZJR19ORVRG
SUxURVJfWFRfTUFUQ0hfSVBDT01QIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9N
QVRDSF9JUFJBTkdFPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9JUFZTPXkKIyBDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX0wyVFAgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVS
X1hUX01BVENIX0xFTkdUSD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTElNSVQ9eQpD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX01BQz15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFU
Q0hfTUFSSz15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTVVMVElQT1JUPXkKIyBDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX05GQUNDVCBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxU
RVJfWFRfTUFUQ0hfT1NGPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9PV05FUj15CkNP
TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUE9MSUNZPXkKQ09ORklHX05FVEZJTFRFUl9YVF9N
QVRDSF9QS1RUWVBFPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9RVU9UQT15CkNPTkZJ
R19ORVRGSUxURVJfWFRfTUFUQ0hfUkFURUVTVD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFU
Q0hfUkVBTE09eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1JFQ0VOVD15CkNPTkZJR19O
RVRGSUxURVJfWFRfTUFUQ0hfU0NUUD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfU09D
S0VUPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TVEFURT15CkNPTkZJR19ORVRGSUxU
RVJfWFRfTUFUQ0hfU1RBVElTVElDPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TVFJJ
Tkc9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1RDUE1TUz15CkNPTkZJR19ORVRGSUxU
RVJfWFRfTUFUQ0hfVElNRT15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfVTMyPXkKQ09O
RklHX0lQX1NFVD15CkNPTkZJR19JUF9TRVRfTUFYPTI1NgpDT05GSUdfSVBfU0VUX0JJVE1B
UF9JUD15CkNPTkZJR19JUF9TRVRfQklUTUFQX0lQTUFDPXkKQ09ORklHX0lQX1NFVF9CSVRN
QVBfUE9SVD15CkNPTkZJR19JUF9TRVRfSEFTSF9JUD15CiMgQ09ORklHX0lQX1NFVF9IQVNI
X0lQTUFSSyBpcyBub3Qgc2V0CkNPTkZJR19JUF9TRVRfSEFTSF9JUFBPUlQ9eQpDT05GSUdf
SVBfU0VUX0hBU0hfSVBQT1JUSVA9eQpDT05GSUdfSVBfU0VUX0hBU0hfSVBQT1JUTkVUPXkK
IyBDT05GSUdfSVBfU0VUX0hBU0hfTkVUUE9SVE5FVCBpcyBub3Qgc2V0CkNPTkZJR19JUF9T
RVRfSEFTSF9ORVQ9eQojIENPTkZJR19JUF9TRVRfSEFTSF9ORVRORVQgaXMgbm90IHNldApD
T05GSUdfSVBfU0VUX0hBU0hfTkVUUE9SVD15CkNPTkZJR19JUF9TRVRfSEFTSF9ORVRJRkFD
RT15CkNPTkZJR19JUF9TRVRfTElTVF9TRVQ9eQpDT05GSUdfSVBfVlM9eQojIENPTkZJR19J
UF9WU19ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19JUF9WU19UQUJfQklUUz0xMgoKIwojIElQ
VlMgdHJhbnNwb3J0IHByb3RvY29sIGxvYWQgYmFsYW5jaW5nIHN1cHBvcnQKIwpDT05GSUdf
SVBfVlNfUFJPVE9fVENQPXkKQ09ORklHX0lQX1ZTX1BST1RPX1VEUD15CkNPTkZJR19JUF9W
U19QUk9UT19BSF9FU1A9eQpDT05GSUdfSVBfVlNfUFJPVE9fRVNQPXkKQ09ORklHX0lQX1ZT
X1BST1RPX0FIPXkKQ09ORklHX0lQX1ZTX1BST1RPX1NDVFA9eQoKIwojIElQVlMgc2NoZWR1
bGVyCiMKQ09ORklHX0lQX1ZTX1JSPXkKQ09ORklHX0lQX1ZTX1dSUj15CkNPTkZJR19JUF9W
U19MQz15CkNPTkZJR19JUF9WU19XTEM9eQpDT05GSUdfSVBfVlNfTEJMQz15CkNPTkZJR19J
UF9WU19MQkxDUj15CkNPTkZJR19JUF9WU19ESD15CkNPTkZJR19JUF9WU19TSD15CkNPTkZJ
R19JUF9WU19TRUQ9eQpDT05GSUdfSVBfVlNfTlE9eQoKIwojIElQVlMgU0ggc2NoZWR1bGVy
CiMKQ09ORklHX0lQX1ZTX1NIX1RBQl9CSVRTPTgKCiMKIyBJUFZTIGFwcGxpY2F0aW9uIGhl
bHBlcgojCkNPTkZJR19JUF9WU19ORkNUPXkKCiMKIyBJUDogTmV0ZmlsdGVyIENvbmZpZ3Vy
YXRpb24KIwpDT05GSUdfTkZfREVGUkFHX0lQVjQ9eQpDT05GSUdfTkZfQ09OTlRSQUNLX0lQ
VjQ9eQpDT05GSUdfTkZfQ09OTlRSQUNLX1BST0NfQ09NUEFUPXkKQ09ORklHX0lQX05GX0lQ
VEFCTEVTPXkKQ09ORklHX0lQX05GX01BVENIX0FIPXkKQ09ORklHX0lQX05GX01BVENIX0VD
Tj15CkNPTkZJR19JUF9ORl9NQVRDSF9SUEZJTFRFUj15CkNPTkZJR19JUF9ORl9NQVRDSF9U
VEw9eQpDT05GSUdfSVBfTkZfRklMVEVSPXkKQ09ORklHX0lQX05GX1RBUkdFVF9SRUpFQ1Q9
eQojIENPTkZJR19JUF9ORl9UQVJHRVRfU1lOUFJPWFkgaXMgbm90IHNldAojIENPTkZJR19J
UF9ORl9UQVJHRVRfVUxPRyBpcyBub3Qgc2V0CkNPTkZJR19ORl9OQVRfSVBWND15CiMgQ09O
RklHX0lQX05GX1RBUkdFVF9NQVNRVUVSQURFIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfTkZf
VEFSR0VUX05FVE1BUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX05GX1RBUkdFVF9SRURJUkVD
VCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX05BVF9QUFRQIGlzIG5vdCBzZXQKIyBDT05GSUdf
TkZfTkFUX0gzMjMgaXMgbm90IHNldApDT05GSUdfSVBfTkZfTUFOR0xFPXkKQ09ORklHX0lQ
X05GX1RBUkdFVF9DTFVTVEVSSVA9eQpDT05GSUdfSVBfTkZfVEFSR0VUX0VDTj15CkNPTkZJ
R19JUF9ORl9UQVJHRVRfVFRMPXkKQ09ORklHX0lQX05GX1JBVz15CkNPTkZJR19JUF9ORl9T
RUNVUklUWT15CkNPTkZJR19JUF9ORl9BUlBUQUJMRVM9eQpDT05GSUdfSVBfTkZfQVJQRklM
VEVSPXkKQ09ORklHX0lQX05GX0FSUF9NQU5HTEU9eQpDT05GSUdfQlJJREdFX05GX0VCVEFC
TEVTPXkKQ09ORklHX0JSSURHRV9FQlRfQlJPVVRFPXkKQ09ORklHX0JSSURHRV9FQlRfVF9G
SUxURVI9eQpDT05GSUdfQlJJREdFX0VCVF9UX05BVD15CkNPTkZJR19CUklER0VfRUJUXzgw
Ml8zPXkKQ09ORklHX0JSSURHRV9FQlRfQU1PTkc9eQpDT05GSUdfQlJJREdFX0VCVF9BUlA9
eQpDT05GSUdfQlJJREdFX0VCVF9JUD15CkNPTkZJR19CUklER0VfRUJUX0xJTUlUPXkKQ09O
RklHX0JSSURHRV9FQlRfTUFSSz15CkNPTkZJR19CUklER0VfRUJUX1BLVFRZUEU9eQpDT05G
SUdfQlJJREdFX0VCVF9TVFA9eQpDT05GSUdfQlJJREdFX0VCVF9WTEFOPXkKQ09ORklHX0JS
SURHRV9FQlRfQVJQUkVQTFk9eQpDT05GSUdfQlJJREdFX0VCVF9ETkFUPXkKQ09ORklHX0JS
SURHRV9FQlRfTUFSS19UPXkKQ09ORklHX0JSSURHRV9FQlRfUkVESVJFQ1Q9eQpDT05GSUdf
QlJJREdFX0VCVF9TTkFUPXkKQ09ORklHX0JSSURHRV9FQlRfTE9HPXkKIyBDT05GSUdfQlJJ
REdFX0VCVF9VTE9HIGlzIG5vdCBzZXQKQ09ORklHX0JSSURHRV9FQlRfTkZMT0c9eQojIENP
TkZJR19JUF9EQ0NQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfU0NUUCBpcyBub3Qgc2V0CiMg
Q09ORklHX1JEUyBpcyBub3Qgc2V0CiMgQ09ORklHX1RJUEMgaXMgbm90IHNldAojIENPTkZJ
R19BVE0gaXMgbm90IHNldAojIENPTkZJR19MMlRQIGlzIG5vdCBzZXQKQ09ORklHX1NUUD15
CkNPTkZJR19HQVJQPXkKQ09ORklHX0JSSURHRT15CkNPTkZJR19CUklER0VfSUdNUF9TTk9P
UElORz15CiMgQ09ORklHX0JSSURHRV9WTEFOX0ZJTFRFUklORyBpcyBub3Qgc2V0CkNPTkZJ
R19IQVZFX05FVF9EU0E9eQpDT05GSUdfVkxBTl84MDIxUT15CkNPTkZJR19WTEFOXzgwMjFR
X0dWUlA9eQojIENPTkZJR19WTEFOXzgwMjFRX01WUlAgaXMgbm90IHNldAojIENPTkZJR19E
RUNORVQgaXMgbm90IHNldApDT05GSUdfTExDPXkKIyBDT05GSUdfTExDMiBpcyBub3Qgc2V0
CiMgQ09ORklHX0lQWCBpcyBub3Qgc2V0CiMgQ09ORklHX0FUQUxLIGlzIG5vdCBzZXQKIyBD
T05GSUdfWDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfTEFQQiBpcyBub3Qgc2V0CiMgQ09ORklH
X1BIT05FVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lFRUU4MDIxNTQgaXMgbm90IHNldApDT05G
SUdfTkVUX1NDSEVEPXkKCiMKIyBRdWV1ZWluZy9TY2hlZHVsaW5nCiMKQ09ORklHX05FVF9T
Q0hfQ0JRPXkKQ09ORklHX05FVF9TQ0hfSFRCPXkKQ09ORklHX05FVF9TQ0hfSEZTQz15CkNP
TkZJR19ORVRfU0NIX1BSSU89eQpDT05GSUdfTkVUX1NDSF9NVUxUSVE9eQpDT05GSUdfTkVU
X1NDSF9SRUQ9eQpDT05GSUdfTkVUX1NDSF9TRkI9eQpDT05GSUdfTkVUX1NDSF9TRlE9eQpD
T05GSUdfTkVUX1NDSF9URVFMPXkKQ09ORklHX05FVF9TQ0hfVEJGPXkKQ09ORklHX05FVF9T
Q0hfR1JFRD15CkNPTkZJR19ORVRfU0NIX0RTTUFSSz15CkNPTkZJR19ORVRfU0NIX05FVEVN
PXkKQ09ORklHX05FVF9TQ0hfRFJSPXkKQ09ORklHX05FVF9TQ0hfTVFQUklPPXkKQ09ORklH
X05FVF9TQ0hfQ0hPS0U9eQpDT05GSUdfTkVUX1NDSF9RRlE9eQpDT05GSUdfTkVUX1NDSF9D
T0RFTD15CkNPTkZJR19ORVRfU0NIX0ZRX0NPREVMPXkKIyBDT05GSUdfTkVUX1NDSF9GUSBp
cyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfSEhGIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU
X1NDSF9QSUUgaXMgbm90IHNldApDT05GSUdfTkVUX1NDSF9JTkdSRVNTPXkKIyBDT05GSUdf
TkVUX1NDSF9QTFVHIGlzIG5vdCBzZXQKCiMKIyBDbGFzc2lmaWNhdGlvbgojCkNPTkZJR19O
RVRfQ0xTPXkKQ09ORklHX05FVF9DTFNfQkFTSUM9eQpDT05GSUdfTkVUX0NMU19UQ0lOREVY
PXkKQ09ORklHX05FVF9DTFNfUk9VVEU0PXkKQ09ORklHX05FVF9DTFNfRlc9eQpDT05GSUdf
TkVUX0NMU19VMzI9eQpDT05GSUdfQ0xTX1UzMl9QRVJGPXkKQ09ORklHX0NMU19VMzJfTUFS
Sz15CkNPTkZJR19ORVRfQ0xTX1JTVlA9eQpDT05GSUdfTkVUX0NMU19SU1ZQNj15CkNPTkZJ
R19ORVRfQ0xTX0ZMT1c9eQpDT05GSUdfTkVUX0NMU19DR1JPVVA9eQojIENPTkZJR19ORVRf
Q0xTX0JQRiBpcyBub3Qgc2V0CkNPTkZJR19ORVRfRU1BVENIPXkKQ09ORklHX05FVF9FTUFU
Q0hfU1RBQ0s9MzIKQ09ORklHX05FVF9FTUFUQ0hfQ01QPXkKQ09ORklHX05FVF9FTUFUQ0hf
TkJZVEU9eQpDT05GSUdfTkVUX0VNQVRDSF9VMzI9eQpDT05GSUdfTkVUX0VNQVRDSF9NRVRB
PXkKQ09ORklHX05FVF9FTUFUQ0hfVEVYVD15CiMgQ09ORklHX05FVF9FTUFUQ0hfSVBTRVQg
aXMgbm90IHNldApDT05GSUdfTkVUX0NMU19BQ1Q9eQpDT05GSUdfTkVUX0FDVF9QT0xJQ0U9
eQpDT05GSUdfTkVUX0FDVF9HQUNUPXkKQ09ORklHX0dBQ1RfUFJPQj15CkNPTkZJR19ORVRf
QUNUX01JUlJFRD15CkNPTkZJR19ORVRfQUNUX0lQVD1tCkNPTkZJR19ORVRfQUNUX05BVD15
CkNPTkZJR19ORVRfQUNUX1BFRElUPXkKQ09ORklHX05FVF9BQ1RfU0lNUD15CkNPTkZJR19O
RVRfQUNUX1NLQkVESVQ9eQpDT05GSUdfTkVUX0FDVF9DU1VNPXkKQ09ORklHX05FVF9DTFNf
SU5EPXkKQ09ORklHX05FVF9TQ0hfRklGTz15CkNPTkZJR19EQ0I9eQpDT05GSUdfRE5TX1JF
U09MVkVSPXkKIyBDT05GSUdfQkFUTUFOX0FEViBpcyBub3Qgc2V0CkNPTkZJR19PUEVOVlNX
SVRDSD15CiMgQ09ORklHX1ZTT0NLRVRTIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUTElOS19N
TUFQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUTElOS19ESUFHIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVUX01QTFNfR1NPIGlzIG5vdCBzZXQKIyBDT05GSUdfSFNSIGlzIG5vdCBzZXQKQ09O
RklHX1JQUz15CkNPTkZJR19SRlNfQUNDRUw9eQpDT05GSUdfWFBTPXkKIyBDT05GSUdfQ0dS
T1VQX05FVF9QUklPIGlzIG5vdCBzZXQKQ09ORklHX0NHUk9VUF9ORVRfQ0xBU1NJRD15CkNP
TkZJR19ORVRfUlhfQlVTWV9QT0xMPXkKQ09ORklHX0JRTD15CkNPTkZJR19CUEZfSklUPXkK
Q09ORklHX05FVF9GTE9XX0xJTUlUPXkKCiMKIyBOZXR3b3JrIHRlc3RpbmcKIwojIENPTkZJ
R19ORVRfUEtUR0VOIGlzIG5vdCBzZXQKIyBDT05GSUdfSEFNUkFESU8gaXMgbm90IHNldAoj
IENPTkZJR19DQU4gaXMgbm90IHNldAojIENPTkZJR19JUkRBIGlzIG5vdCBzZXQKIyBDT05G
SUdfQlQgaXMgbm90IHNldApDT05GSUdfQUZfUlhSUEM9eQojIENPTkZJR19BRl9SWFJQQ19E
RUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1JYS0FEIGlzIG5vdCBzZXQKQ09ORklHX0ZJQl9S
VUxFUz15CkNPTkZJR19XSVJFTEVTUz15CkNPTkZJR19XRVhUX0NPUkU9eQpDT05GSUdfV0VY
VF9QUk9DPXkKQ09ORklHX0NGRzgwMjExPXkKIyBDT05GSUdfTkw4MDIxMV9URVNUTU9ERSBp
cyBub3Qgc2V0CiMgQ09ORklHX0NGRzgwMjExX0RFVkVMT1BFUl9XQVJOSU5HUyBpcyBub3Qg
c2V0CiMgQ09ORklHX0NGRzgwMjExX1JFR19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0NG
RzgwMjExX0RFRkFVTFRfUFMgaXMgbm90IHNldAojIENPTkZJR19DRkc4MDIxMV9JTlRFUk5B
TF9SRUdEQiBpcyBub3Qgc2V0CkNPTkZJR19DRkc4MDIxMV9XRVhUPXkKIyBDT05GSUdfTElC
ODAyMTEgaXMgbm90IHNldApDT05GSUdfTUFDODAyMTE9eQpDT05GSUdfTUFDODAyMTFfSEFT
X1JDPXkKQ09ORklHX01BQzgwMjExX1JDX01JTlNUUkVMPXkKQ09ORklHX01BQzgwMjExX1JD
X01JTlNUUkVMX0hUPXkKQ09ORklHX01BQzgwMjExX1JDX0RFRkFVTFRfTUlOU1RSRUw9eQpD
T05GSUdfTUFDODAyMTFfUkNfREVGQVVMVD0ibWluc3RyZWxfaHQiCiMgQ09ORklHX01BQzgw
MjExX01FU0ggaXMgbm90IHNldApDT05GSUdfTUFDODAyMTFfTEVEUz15CiMgQ09ORklHX01B
QzgwMjExX01FU1NBR0VfVFJBQ0lORyBpcyBub3Qgc2V0CiMgQ09ORklHX01BQzgwMjExX0RF
QlVHX01FTlUgaXMgbm90IHNldAojIENPTkZJR19XSU1BWCBpcyBub3Qgc2V0CkNPTkZJR19S
RktJTEw9eQpDT05GSUdfUkZLSUxMX0xFRFM9eQpDT05GSUdfUkZLSUxMX0lOUFVUPXkKIyBD
T05GSUdfUkZLSUxMX0dQSU8gaXMgbm90IHNldAojIENPTkZJR19ORVRfOVAgaXMgbm90IHNl
dAojIENPTkZJR19DQUlGIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0VQSF9MSUIgaXMgbm90IHNl
dAojIENPTkZJR19ORkMgaXMgbm90IHNldApDT05GSUdfSEFWRV9CUEZfSklUPXkKCiMKIyBE
ZXZpY2UgRHJpdmVycwojCgojCiMgR2VuZXJpYyBEcml2ZXIgT3B0aW9ucwojCkNPTkZJR19V
RVZFTlRfSEVMUEVSPXkKQ09ORklHX1VFVkVOVF9IRUxQRVJfUEFUSD0iIgpDT05GSUdfREVW
VE1QRlM9eQpDT05GSUdfREVWVE1QRlNfTU9VTlQ9eQojIENPTkZJR19TVEFOREFMT05FIGlz
IG5vdCBzZXQKIyBDT05GSUdfUFJFVkVOVF9GSVJNV0FSRV9CVUlMRCBpcyBub3Qgc2V0CkNP
TkZJR19GV19MT0FERVI9eQpDT05GSUdfRklSTVdBUkVfSU5fS0VSTkVMPXkKQ09ORklHX0VY
VFJBX0ZJUk1XQVJFPSIiCkNPTkZJR19GV19MT0FERVJfVVNFUl9IRUxQRVI9eQojIENPTkZJ
R19ERUJVR19EUklWRVIgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19ERVZSRVMgaXMgbm90
IHNldApDT05GSUdfU1lTX0hZUEVSVklTT1I9eQojIENPTkZJR19HRU5FUklDX0NQVV9ERVZJ
Q0VTIGlzIG5vdCBzZXQKQ09ORklHX0dFTkVSSUNfQ1BVX0FVVE9QUk9CRT15CkNPTkZJR19S
RUdNQVA9eQpDT05GSUdfUkVHTUFQX0kyQz1tCkNPTkZJR19ETUFfU0hBUkVEX0JVRkZFUj15
CgojCiMgQnVzIGRldmljZXMKIwpDT05GSUdfQ09OTkVDVE9SPXkKQ09ORklHX1BST0NfRVZF
TlRTPXkKIyBDT05GSUdfTVREIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFSUE9SVCBpcyBub3Qg
c2V0CkNPTkZJR19BUkNIX01JR0hUX0hBVkVfUENfUEFSUE9SVD15CkNPTkZJR19QTlA9eQoj
IENPTkZJR19QTlBfREVCVUdfTUVTU0FHRVMgaXMgbm90IHNldAoKIwojIFByb3RvY29scwoj
CkNPTkZJR19QTlBBQ1BJPXkKQ09ORklHX0JMS19ERVY9eQojIENPTkZJR19CTEtfREVWX05V
TExfQkxLIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9GRCBpcyBub3Qgc2V0CiMgQ09O
RklHX0JMS19ERVZfUENJRVNTRF9NVElQMzJYWCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19D
UFFfQ0lTU19EQSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfREFDOTYwIGlzIG5vdCBz
ZXQKIyBDT05GSUdfQkxLX0RFVl9VTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9D
T1dfQ09NTU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfTE9PUD15CkNPTkZJR19CTEtf
REVWX0xPT1BfTUlOX0NPVU5UPTgKIyBDT05GSUdfQkxLX0RFVl9DUllQVE9MT09QIGlzIG5v
dCBzZXQKQ09ORklHX0JMS19ERVZfRFJCRD15CiMgQ09ORklHX0RSQkRfRkFVTFRfSU5KRUNU
SU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfTkJEPXkKIyBDT05GSUdfQkxLX0RFVl9O
Vk1FIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9TS0QgaXMgbm90IHNldAojIENPTkZJ
R19CTEtfREVWX1NYOCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX1JBTT15CkNPTkZJR19C
TEtfREVWX1JBTV9DT1VOVD0xNgpDT05GSUdfQkxLX0RFVl9SQU1fU0laRT02NTUzNgojIENP
TkZJR19CTEtfREVWX1hJUCBpcyBub3Qgc2V0CiMgQ09ORklHX0NEUk9NX1BLVENEVkQgaXMg
bm90IHNldAojIENPTkZJR19BVEFfT1ZFUl9FVEggaXMgbm90IHNldApDT05GSUdfWEVOX0JM
S0RFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fQkxLREVWX0JBQ0tFTkQ9eQpDT05GSUdfVklS
VElPX0JMSz1tCiMgQ09ORklHX0JMS19ERVZfSEQgaXMgbm90IHNldAojIENPTkZJR19CTEtf
REVWX1JCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfUlNYWCBpcyBub3Qgc2V0Cgoj
CiMgTWlzYyBkZXZpY2VzCiMKIyBDT05GSUdfU0VOU09SU19MSVMzTFYwMkQgaXMgbm90IHNl
dAojIENPTkZJR19BRDUyNVhfRFBPVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RVTU1ZX0lSUSBp
cyBub3Qgc2V0CiMgQ09ORklHX0lCTV9BU00gaXMgbm90IHNldAojIENPTkZJR19QSEFOVE9N
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0dJX0lPQzQgaXMgbm90IHNldAojIENPTkZJR19USUZN
X0NPUkUgaXMgbm90IHNldAojIENPTkZJR19JQ1M5MzJTNDAxIGlzIG5vdCBzZXQKIyBDT05G
SUdfRU5DTE9TVVJFX1NFUlZJQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfSFBfSUxPIGlzIG5v
dCBzZXQKIyBDT05GSUdfQVBEUzk4MDJBTFMgaXMgbm90IHNldAojIENPTkZJR19JU0wyOTAw
MyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTTDI5MDIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19UU0wyNTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19CSDE3ODAgaXMgbm90
IHNldAojIENPTkZJR19TRU5TT1JTX0JIMTc3MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNP
UlNfQVBEUzk5MFggaXMgbm90IHNldAojIENPTkZJR19ITUM2MzUyIGlzIG5vdCBzZXQKIyBD
T05GSUdfRFMxNjgyIGlzIG5vdCBzZXQKIyBDT05GSUdfVk1XQVJFX0JBTExPT04gaXMgbm90
IHNldAojIENPTkZJR19CTVAwODVfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NXSVRD
SF9GU0E5NDgwIGlzIG5vdCBzZXQKIyBDT05GSUdfU1JBTSBpcyBub3Qgc2V0CiMgQ09ORklH
X0MyUE9SVCBpcyBub3Qgc2V0CgojCiMgRUVQUk9NIHN1cHBvcnQKIwpDT05GSUdfRUVQUk9N
X0FUMjQ9bQpDT05GSUdfRUVQUk9NX0xFR0FDWT1tCkNPTkZJR19FRVBST01fTUFYNjg3NT1t
CkNPTkZJR19FRVBST01fOTNDWDY9bQojIENPTkZJR19DQjcxMF9DT1JFIGlzIG5vdCBzZXQK
CiMKIyBUZXhhcyBJbnN0cnVtZW50cyBzaGFyZWQgdHJhbnNwb3J0IGxpbmUgZGlzY2lwbGlu
ZQojCiMgQ09ORklHX1RJX1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MSVMzX0ky
QyBpcyBub3Qgc2V0CgojCiMgQWx0ZXJhIEZQR0EgZmlybXdhcmUgZG93bmxvYWQgbW9kdWxl
CiMKIyBDT05GSUdfQUxURVJBX1NUQVBMIGlzIG5vdCBzZXQKQ09ORklHX0lOVEVMX01FST15
CkNPTkZJR19JTlRFTF9NRUlfTUU9eQojIENPTkZJR19JTlRFTF9NRUlfVFhFIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVk1XQVJFX1ZNQ0kgaXMgbm90IHNldAoKIwojIEludGVsIE1JQyBIb3N0
IERyaXZlcgojCiMgQ09ORklHX0lOVEVMX01JQ19IT1NUIGlzIG5vdCBzZXQKCiMKIyBJbnRl
bCBNSUMgQ2FyZCBEcml2ZXIKIwojIENPTkZJR19JTlRFTF9NSUNfQ0FSRCBpcyBub3Qgc2V0
CiMgQ09ORklHX0dFTldRRSBpcyBub3Qgc2V0CiMgQ09ORklHX0VDSE8gaXMgbm90IHNldApD
T05GSUdfSEFWRV9JREU9eQojIENPTkZJR19JREUgaXMgbm90IHNldAoKIwojIFNDU0kgZGV2
aWNlIHN1cHBvcnQKIwpDT05GSUdfU0NTSV9NT0Q9eQojIENPTkZJR19SQUlEX0FUVFJTIGlz
IG5vdCBzZXQKQ09ORklHX1NDU0k9eQpDT05GSUdfU0NTSV9ETUE9eQojIENPTkZJR19TQ1NJ
X1RHVCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX05FVExJTks9eQojIENPTkZJR19TQ1NJX1BS
T0NfRlMgaXMgbm90IHNldAoKIwojIFNDU0kgc3VwcG9ydCB0eXBlIChkaXNrLCB0YXBlLCBD
RC1ST00pCiMKQ09ORklHX0JMS19ERVZfU0Q9eQojIENPTkZJR19DSFJfREVWX1NUIGlzIG5v
dCBzZXQKIyBDT05GSUdfQ0hSX0RFVl9PU1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RF
Vl9TUiBpcyBub3Qgc2V0CkNPTkZJR19DSFJfREVWX1NHPXkKIyBDT05GSUdfQ0hSX0RFVl9T
Q0ggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX01VTFRJX0xVTiBpcyBub3Qgc2V0CiMgQ09O
RklHX1NDU0lfQ09OU1RBTlRTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9MT0dHSU5HIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TQ0FOX0FTWU5DIGlzIG5vdCBzZXQKCiMKIyBTQ1NJ
IFRyYW5zcG9ydHMKIwpDT05GSUdfU0NTSV9TUElfQVRUUlM9eQpDT05GSUdfU0NTSV9GQ19B
VFRSUz15CkNPTkZJR19TQ1NJX0lTQ1NJX0FUVFJTPXkKQ09ORklHX1NDU0lfU0FTX0FUVFJT
PXkKQ09ORklHX1NDU0lfU0FTX0xJQlNBUz15CkNPTkZJR19TQ1NJX1NBU19BVEE9eQpDT05G
SUdfU0NTSV9TQVNfSE9TVF9TTVA9eQpDT05GSUdfU0NTSV9TUlBfQVRUUlM9eQpDT05GSUdf
U0NTSV9MT1dMRVZFTD15CiMgQ09ORklHX0lTQ1NJX1RDUCBpcyBub3Qgc2V0CiMgQ09ORklH
X0lTQ1NJX0JPT1RfU1lTRlMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0NYR0IzX0lTQ1NJ
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9DWEdCNF9JU0NTSSBpcyBub3Qgc2V0CiMgQ09O
RklHX1NDU0lfQk5YMl9JU0NTSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQk5YMlhfRkNP
RSBpcyBub3Qgc2V0CiMgQ09ORklHX0JFMklTQ1NJIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxL
X0RFVl8zV19YWFhYX1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0hQU0EgaXMgbm90
IHNldAojIENPTkZJR19TQ1NJXzNXXzlYWFggaXMgbm90IHNldAojIENPTkZJR19TQ1NJXzNX
X1NBUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQUNBUkQgaXMgbm90IHNldAojIENPTkZJ
R19TQ1NJX0FBQ1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FJQzdYWFggaXMgbm90
IHNldAojIENPTkZJR19TQ1NJX0FJQzc5WFggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FJ
Qzk0WFggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX01WU0FTIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0NTSV9NVlVNSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfRFBUX0kyTyBpcyBub3Qg
c2V0CiMgQ09ORklHX1NDU0lfQURWQU5TWVMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FS
Q01TUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfRVNBUzJSIGlzIG5vdCBzZXQKIyBDT05G
SUdfTUVHQVJBSURfTkVXR0VOIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVHQVJBSURfTEVHQUNZ
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUVHQVJBSURfU0FTIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0NTSV9NUFQyU0FTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9NUFQzU0FTIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0NTSV9VRlNIQ0QgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0hQVElP
UCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQlVTTE9HSUMgaXMgbm90IHNldAojIENPTkZJ
R19WTVdBUkVfUFZTQ1NJIGlzIG5vdCBzZXQKQ09ORklHX0hZUEVSVl9TVE9SQUdFPXkKIyBD
T05GSUdfTElCRkMgaXMgbm90IHNldAojIENPTkZJR19MSUJGQ09FIGlzIG5vdCBzZXQKIyBD
T05GSUdfRkNPRSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZDT0VfRk5JQyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NDU0lfRE1YMzE5MUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0VBVEEgaXMg
bm90IHNldAojIENPTkZJR19TQ1NJX0ZVVFVSRV9ET01BSU4gaXMgbm90IHNldAojIENPTkZJ
R19TQ1NJX0dEVEggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0lTQ0kgaXMgbm90IHNldAoj
IENPTkZJR19TQ1NJX0lQUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSU5JVElPIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0NTSV9JTklBMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9T
VEVYIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TWU01M0M4WFhfMiBpcyBub3Qgc2V0CiMg
Q09ORklHX1NDU0lfSVBSIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9RTE9HSUNfMTI4MCBp
cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUUxBX0ZDIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NT
SV9RTEFfSVNDU0kgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0xQRkMgaXMgbm90IHNldAoj
IENPTkZJR19TQ1NJX0RDMzk1eCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREMzOTBUIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0NTSV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lf
UE1DUkFJRCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUE04MDAxIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0NTSV9TUlAgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0JGQV9GQyBpcyBub3Qg
c2V0CiMgQ09ORklHX1NDU0lfVklSVElPIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9DSEVM
U0lPX0ZDT0UgaXMgbm90IHNldApDT05GSUdfU0NTSV9ESD15CiMgQ09ORklHX1NDU0lfREhf
UkRBQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREhfSFBfU1cgaXMgbm90IHNldAojIENP
TkZJR19TQ1NJX0RIX0VNQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREhfQUxVQSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NDU0lfT1NEX0lOSVRJQVRPUiBpcyBub3Qgc2V0CkNPTkZJR19B
VEE9eQojIENPTkZJR19BVEFfTk9OU1RBTkRBUkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZF
UkJPU0VfRVJST1I9eQpDT05GSUdfQVRBX0FDUEk9eQojIENPTkZJR19TQVRBX1pQT0REIGlz
IG5vdCBzZXQKQ09ORklHX1NBVEFfUE1QPXkKCiMKIyBDb250cm9sbGVycyB3aXRoIG5vbi1T
RkYgbmF0aXZlIGludGVyZmFjZQojCkNPTkZJR19TQVRBX0FIQ0k9eQpDT05GSUdfU0FUQV9B
SENJX1BMQVRGT1JNPXkKIyBDT05GSUdfU0FUQV9JTklDMTYyWCBpcyBub3Qgc2V0CiMgQ09O
RklHX1NBVEFfQUNBUkRfQUhDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfU0lMMjQgaXMg
bm90IHNldApDT05GSUdfQVRBX1NGRj15CgojCiMgU0ZGIGNvbnRyb2xsZXJzIHdpdGggY3Vz
dG9tIERNQSBpbnRlcmZhY2UKIwojIENPTkZJR19QRENfQURNQSBpcyBub3Qgc2V0CiMgQ09O
RklHX1NBVEFfUVNUT1IgaXMgbm90IHNldAojIENPTkZJR19TQVRBX1NYNCBpcyBub3Qgc2V0
CkNPTkZJR19BVEFfQk1ETUE9eQoKIwojIFNBVEEgU0ZGIGNvbnRyb2xsZXJzIHdpdGggQk1E
TUEKIwpDT05GSUdfQVRBX1BJSVg9eQojIENPTkZJR19TQVRBX01WIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0FUQV9OViBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfUFJPTUlTRSBpcyBub3Qg
c2V0CiMgQ09ORklHX1NBVEFfU0lMIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9TSVMgaXMg
bm90IHNldAojIENPTkZJR19TQVRBX1NWVyBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfVUxJ
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9WSUEgaXMgbm90IHNldAojIENPTkZJR19TQVRB
X1ZJVEVTU0UgaXMgbm90IHNldAoKIwojIFBBVEEgU0ZGIGNvbnRyb2xsZXJzIHdpdGggQk1E
TUEKIwojIENPTkZJR19QQVRBX0FMSSBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfQU1EIGlz
IG5vdCBzZXQKIyBDT05GSUdfUEFUQV9BUlRPUCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFf
QVRJSVhQIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9BVFA4NjdYIGlzIG5vdCBzZXQKIyBD
T05GSUdfUEFUQV9DTUQ2NFggaXMgbm90IHNldAojIENPTkZJR19QQVRBX0NZUFJFU1MgaXMg
bm90IHNldAojIENPTkZJR19QQVRBX0VGQVIgaXMgbm90IHNldAojIENPTkZJR19QQVRBX0hQ
VDM2NiBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfSFBUMzdYIGlzIG5vdCBzZXQKIyBDT05G
SUdfUEFUQV9IUFQzWDJOIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9IUFQzWDMgaXMgbm90
IHNldAojIENPTkZJR19QQVRBX0lUODIxMyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfSVQ4
MjFYIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9KTUlDUk9OIGlzIG5vdCBzZXQKIyBDT05G
SUdfUEFUQV9NQVJWRUxMIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9ORVRDRUxMIGlzIG5v
dCBzZXQKIyBDT05GSUdfUEFUQV9OSU5KQTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9O
Uzg3NDE1IGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9PTERQSUlYIGlzIG5vdCBzZXQKIyBD
T05GSUdfUEFUQV9PUFRJRE1BIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9QREMyMDI3WCBp
cyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfUERDX09MRCBpcyBub3Qgc2V0CiMgQ09ORklHX1BB
VEFfUkFESVNZUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfUkRDIGlzIG5vdCBzZXQKIyBD
T05GSUdfUEFUQV9TQ0ggaXMgbm90IHNldAojIENPTkZJR19QQVRBX1NFUlZFUldPUktTIGlz
IG5vdCBzZXQKIyBDT05GSUdfUEFUQV9TSUw2ODAgaXMgbm90IHNldAojIENPTkZJR19QQVRB
X1NJUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfVE9TSElCQSBpcyBub3Qgc2V0CiMgQ09O
RklHX1BBVEFfVFJJRkxFWCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfVklBIGlzIG5vdCBz
ZXQKIyBDT05GSUdfUEFUQV9XSU5CT05EIGlzIG5vdCBzZXQKCiMKIyBQSU8tb25seSBTRkYg
Y29udHJvbGxlcnMKIwojIENPTkZJR19QQVRBX0NNRDY0MF9QQ0kgaXMgbm90IHNldAojIENP
TkZJR19QQVRBX01QSUlYIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9OUzg3NDEwIGlzIG5v
dCBzZXQKIyBDT05GSUdfUEFUQV9PUFRJIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9SWjEw
MDAgaXMgbm90IHNldAoKIwojIEdlbmVyaWMgZmFsbGJhY2sgLyBsZWdhY3kgZHJpdmVycwoj
CiMgQ09ORklHX1BBVEFfQUNQSSBpcyBub3Qgc2V0CkNPTkZJR19BVEFfR0VORVJJQz15CiMg
Q09ORklHX1BBVEFfTEVHQUNZIGlzIG5vdCBzZXQKQ09ORklHX01EPXkKIyBDT05GSUdfQkxL
X0RFVl9NRCBpcyBub3Qgc2V0CiMgQ09ORklHX0JDQUNIRSBpcyBub3Qgc2V0CkNPTkZJR19C
TEtfREVWX0RNX0JVSUxUSU49eQpDT05GSUdfQkxLX0RFVl9ETT15CiMgQ09ORklHX0RNX0RF
QlVHIGlzIG5vdCBzZXQKQ09ORklHX0RNX0JVRklPPXkKQ09ORklHX0RNX0NSWVBUPXkKQ09O
RklHX0RNX1NOQVBTSE9UPXkKIyBDT05GSUdfRE1fVEhJTl9QUk9WSVNJT05JTkcgaXMgbm90
IHNldAojIENPTkZJR19ETV9DQUNIRSBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0VSQSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0RNX01JUlJPUiBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX1JBSUQg
aXMgbm90IHNldAojIENPTkZJR19ETV9aRVJPIGlzIG5vdCBzZXQKQ09ORklHX0RNX01VTFRJ
UEFUSD15CiMgQ09ORklHX0RNX01VTFRJUEFUSF9RTCBpcyBub3Qgc2V0CiMgQ09ORklHX0RN
X01VTFRJUEFUSF9TVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0RFTEFZIGlzIG5vdCBzZXQK
Q09ORklHX0RNX1VFVkVOVD15CiMgQ09ORklHX0RNX0ZMQUtFWSBpcyBub3Qgc2V0CiMgQ09O
RklHX0RNX1ZFUklUWSBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX1NXSVRDSCBpcyBub3Qgc2V0
CiMgQ09ORklHX1RBUkdFVF9DT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfRlVTSU9OIGlzIG5v
dCBzZXQKCiMKIyBJRUVFIDEzOTQgKEZpcmVXaXJlKSBzdXBwb3J0CiMKIyBDT05GSUdfRklS
RVdJUkUgaXMgbm90IHNldAojIENPTkZJR19GSVJFV0lSRV9OT1NZIGlzIG5vdCBzZXQKIyBD
T05GSUdfSTJPIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFDSU5UT1NIX0RSSVZFUlMgaXMgbm90
IHNldApDT05GSUdfTkVUREVWSUNFUz15CkNPTkZJR19NSUk9eQpDT05GSUdfTkVUX0NPUkU9
eQpDT05GSUdfQk9ORElORz15CkNPTkZJR19EVU1NWT15CkNPTkZJR19FUVVBTElaRVI9eQpD
T05GSUdfTkVUX0ZDPXkKQ09ORklHX0lGQj15CiMgQ09ORklHX05FVF9URUFNIGlzIG5vdCBz
ZXQKQ09ORklHX01BQ1ZMQU49eQpDT05GSUdfTUFDVlRBUD15CiMgQ09ORklHX1ZYTEFOIGlz
IG5vdCBzZXQKQ09ORklHX05FVENPTlNPTEU9eQpDT05GSUdfTkVUUE9MTD15CkNPTkZJR19O
RVRfUE9MTF9DT05UUk9MTEVSPXkKQ09ORklHX1RVTj15CkNPTkZJR19WRVRIPXkKIyBDT05G
SUdfVklSVElPX05FVCBpcyBub3Qgc2V0CiMgQ09ORklHX05MTU9OIGlzIG5vdCBzZXQKIyBD
T05GSUdfQVJDTkVUIGlzIG5vdCBzZXQKCiMKIyBDQUlGIHRyYW5zcG9ydCBkcml2ZXJzCiMK
CiMKIyBEaXN0cmlidXRlZCBTd2l0Y2ggQXJjaGl0ZWN0dXJlIGRyaXZlcnMKIwojIENPTkZJ
R19ORVRfRFNBX01WODhFNlhYWCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9EU0FfTVY4OEU2
MDYwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0RTQV9NVjg4RTZYWFhfTkVFRF9QUFUgaXMg
bm90IHNldAojIENPTkZJR19ORVRfRFNBX01WODhFNjEzMSBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9EU0FfTVY4OEU2MTIzXzYxXzY1IGlzIG5vdCBzZXQKQ09ORklHX0VUSEVSTkVUPXkK
Q09ORklHX01ESU89eQojIENPTkZJR19ORVRfVkVORE9SXzNDT00gaXMgbm90IHNldAojIENP
TkZJR19ORVRfVkVORE9SX0FEQVBURUMgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9S
X0FMVEVPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0FMVEVSQV9UU0UgaXMgbm90IHNldAojIENP
TkZJR19ORVRfVkVORE9SX0FNRCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfQVJD
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9BVEhFUk9TIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkVUX1ZFTkRPUl9CUk9BRENPTSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5E
T1JfQlJPQ0FERSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9DQUxYRURBX1hHTUFDIGlzIG5v
dCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9DSEVMU0lPIGlzIG5vdCBzZXQKIyBDT05GSUdf
TkVUX1ZFTkRPUl9DSVNDTyBpcyBub3Qgc2V0CiMgQ09ORklHX0NYX0VDQVQgaXMgbm90IHNl
dAojIENPTkZJR19ETkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9ERUMgaXMg
bm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX0RMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdf
TkVUX1ZFTkRPUl9FTVVMRVggaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX0VYQVIg
aXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX0hQIGlzIG5vdCBzZXQKQ09ORklHX05F
VF9WRU5ET1JfSU5URUw9eQpDT05GSUdfRTEwMD15CkNPTkZJR19FMTAwMD15CkNPTkZJR19F
MTAwMEU9eQpDT05GSUdfSUdCPXkKQ09ORklHX0lHQl9IV01PTj15CkNPTkZJR19JR0JfRENB
PXkKQ09ORklHX0lHQlZGPXkKQ09ORklHX0lYR0I9eQpDT05GSUdfSVhHQkU9eQpDT05GSUdf
SVhHQkVfSFdNT049eQpDT05GSUdfSVhHQkVfRENBPXkKQ09ORklHX0lYR0JFX0RDQj15CkNP
TkZJR19JWEdCRVZGPXkKIyBDT05GSUdfSTQwRSBpcyBub3Qgc2V0CiMgQ09ORklHX0k0MEVW
RiBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX0k4MjVYWD15CiMgQ09ORklHX0lQMTAw
MCBpcyBub3Qgc2V0CiMgQ09ORklHX0pNRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5E
T1JfTUFSVkVMTCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX01FTExBTk9YPXkKIyBD
T05GSUdfTUxYNF9FTiBpcyBub3Qgc2V0CiMgQ09ORklHX01MWDRfQ09SRSBpcyBub3Qgc2V0
CiMgQ09ORklHX01MWDVfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfTUlD
UkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9NWVJJIGlzIG5vdCBzZXQKIyBD
T05GSUdfRkVBTE5YIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9OQVRTRU1JIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9OVklESUEgaXMgbm90IHNldAojIENPTkZJ
R19ORVRfVkVORE9SX09LSSBpcyBub3Qgc2V0CiMgQ09ORklHX0VUSE9DIGlzIG5vdCBzZXQK
IyBDT05GSUdfTkVUX1BBQ0tFVF9FTkdJTkUgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVO
RE9SX1FMT0dJQyBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1JFQUxURUs9eQpDT05G
SUdfODEzOUNQPXkKQ09ORklHXzgxMzlUT089eQojIENPTkZJR184MTM5VE9PX1BJTyBpcyBu
b3Qgc2V0CkNPTkZJR184MTM5VE9PX1RVTkVfVFdJU1RFUj15CkNPTkZJR184MTM5VE9PXzgx
Mjk9eQojIENPTkZJR184MTM5X09MRF9SWF9SRVNFVCBpcyBub3Qgc2V0CkNPTkZJR19SODE2
OT15CiMgQ09ORklHX1NIX0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfUkRD
IGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfU0FNU1VORz15CiMgQ09ORklHX1NYR0JF
X0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfU0VFUSBpcyBub3Qgc2V0CiMg
Q09ORklHX05FVF9WRU5ET1JfU0lMQU4gaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9S
X1NJUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NGQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9W
RU5ET1JfU01TQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfU1RNSUNSTyBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfU1VOIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU
X1ZFTkRPUl9URUhVVEkgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX1RJIGlzIG5v
dCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9WSUEgaXMgbm90IHNldAojIENPTkZJR19ORVRf
VkVORE9SX1dJWk5FVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZEREkgaXMgbm90IHNldAojIENP
TkZJR19ISVBQSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQjEwMDAgaXMgbm90IHNldApD
T05GSUdfUEhZTElCPXkKCiMKIyBNSUkgUEhZIGRldmljZSBkcml2ZXJzCiMKQ09ORklHX0FU
ODAzWF9QSFk9eQpDT05GSUdfQU1EX1BIWT15CkNPTkZJR19NQVJWRUxMX1BIWT15CkNPTkZJ
R19EQVZJQ09NX1BIWT15CkNPTkZJR19RU0VNSV9QSFk9eQpDT05GSUdfTFhUX1BIWT15CkNP
TkZJR19DSUNBREFfUEhZPXkKQ09ORklHX1ZJVEVTU0VfUEhZPXkKQ09ORklHX1NNU0NfUEhZ
PXkKQ09ORklHX0JST0FEQ09NX1BIWT15CiMgQ09ORklHX0JDTTdYWFhfUEhZIGlzIG5vdCBz
ZXQKQ09ORklHX0JDTTg3WFhfUEhZPXkKQ09ORklHX0lDUExVU19QSFk9eQpDT05GSUdfUkVB
TFRFS19QSFk9eQpDT05GSUdfTkFUSU9OQUxfUEhZPXkKQ09ORklHX1NURTEwWFA9eQpDT05G
SUdfTFNJX0VUMTAxMUNfUEhZPXkKQ09ORklHX01JQ1JFTF9QSFk9eQpDT05GSUdfRklYRURf
UEhZPXkKQ09ORklHX01ESU9fQklUQkFORz15CkNPTkZJR19NRElPX0dQSU89eQojIENPTkZJ
R19QUFAgaXMgbm90IHNldAojIENPTkZJR19TTElQIGlzIG5vdCBzZXQKCiMKIyBVU0IgTmV0
d29yayBBZGFwdGVycwojCiMgQ09ORklHX1VTQl9DQVRDIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX0tBV0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QRUdBU1VTIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX1JUTDgxNTAgaXMgbm90IHNldAojIENPTkZJR19VU0JfUlRMODE1MiBp
cyBub3Qgc2V0CkNPTkZJR19VU0JfVVNCTkVUPXkKQ09ORklHX1VTQl9ORVRfQVg4ODE3WD15
CkNPTkZJR19VU0JfTkVUX0FYODgxNzlfMTc4QT15CiMgQ09ORklHX1VTQl9ORVRfQ0RDRVRI
RVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX0NEQ19FRU0gaXMgbm90IHNldAojIENP
TkZJR19VU0JfTkVUX0NEQ19OQ00gaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX0hVQVdF
SV9DRENfTkNNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9DRENfTUJJTSBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9ORVRfRE05NjAxIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05F
VF9TUjk3MDAgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX1NSOTgwMCBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9ORVRfU01TQzc1WFggaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVU
X1NNU0M5NVhYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9HTDYyMEEgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfTkVUX05FVDEwODAgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVU
X1BMVVNCIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9NQ1M3ODMwIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX05FVF9STkRJU19IT1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05F
VF9DRENfU1VCU0VUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9aQVVSVVMgaXMgbm90
IHNldAojIENPTkZJR19VU0JfTkVUX0NYODIzMTBfRVRIIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX05FVF9LQUxNSUEgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX1FNSV9XV0FOIGlz
IG5vdCBzZXQKIyBDT05GSUdfVVNCX0hTTyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ORVRf
SU5UNTFYMSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JUEhFVEggaXMgbm90IHNldAojIENP
TkZJR19VU0JfU0lFUlJBX05FVCBpcyBub3Qgc2V0CkNPTkZJR19XTEFOPXkKIyBDT05GSUdf
TElCRVJUQVNfVEhJTkZJUk0gaXMgbm90IHNldAojIENPTkZJR19BSVJPIGlzIG5vdCBzZXQK
IyBDT05GSUdfQVRNRUwgaXMgbm90IHNldAojIENPTkZJR19BVDc2QzUwWF9VU0IgaXMgbm90
IHNldAojIENPTkZJR19QUklTTTU0IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1pEMTIwMSBp
cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ORVRfUk5ESVNfV0xBTiBpcyBub3Qgc2V0CiMgQ09O
RklHX1JUTDgxODAgaXMgbm90IHNldAojIENPTkZJR19SVEw4MTg3IGlzIG5vdCBzZXQKIyBD
T05GSUdfQURNODIxMSBpcyBub3Qgc2V0CiMgQ09ORklHX01BQzgwMjExX0hXU0lNIGlzIG5v
dCBzZXQKIyBDT05GSUdfTVdMOEsgaXMgbm90IHNldApDT05GSUdfQVRIX0NPTU1PTj15CkNP
TkZJR19BVEhfQ0FSRFM9eQojIENPTkZJR19BVEhfREVCVUcgaXMgbm90IHNldApDT05GSUdf
QVRINUs9eQojIENPTkZJR19BVEg1S19ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19BVEg1S19Q
Q0k9eQpDT05GSUdfQVRIOUtfSFc9eQpDT05GSUdfQVRIOUtfQ09NTU9OPXkKIyBDT05GSUdf
QVRIOUtfQlRDT0VYX1NVUFBPUlQgaXMgbm90IHNldApDT05GSUdfQVRIOUs9eQpDT05GSUdf
QVRIOUtfUENJPXkKIyBDT05GSUdfQVRIOUtfQUhCIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRI
OUtfV09XIGlzIG5vdCBzZXQKQ09ORklHX0FUSDlLX1JGS0lMTD15CiMgQ09ORklHX0FUSDlL
X0hUQyBpcyBub3Qgc2V0CkNPTkZJR19DQVJMOTE3MD15CkNPTkZJR19DQVJMOTE3MF9MRURT
PXkKQ09ORklHX0NBUkw5MTcwX1dQQz15CiMgQ09ORklHX0NBUkw5MTcwX0hXUk5HIGlzIG5v
dCBzZXQKQ09ORklHX0FUSDZLTD15CiMgQ09ORklHX0FUSDZLTF9VU0IgaXMgbm90IHNldAoj
IENPTkZJR19BVEg2S0xfREVCVUcgaXMgbm90IHNldApDT05GSUdfQVI1NTIzPXkKIyBDT05G
SUdfV0lMNjIxMCBpcyBub3Qgc2V0CkNPTkZJR19BVEgxMEs9eQpDT05GSUdfQVRIMTBLX1BD
ST15CiMgQ09ORklHX0FUSDEwS19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0FUSDEwS19E
RUJVR0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfV0NOMzZYWCBpcyBub3Qgc2V0CiMgQ09ORklH
X0I0MyBpcyBub3Qgc2V0CiMgQ09ORklHX0I0M0xFR0FDWSBpcyBub3Qgc2V0CiMgQ09ORklH
X0JSQ01TTUFDIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJDTUZNQUMgaXMgbm90IHNldAojIENP
TkZJR19IT1NUQVAgaXMgbm90IHNldAojIENPTkZJR19JUFcyMTAwIGlzIG5vdCBzZXQKIyBD
T05GSUdfSVBXMjIwMCBpcyBub3Qgc2V0CkNPTkZJR19JV0xXSUZJPXkKQ09ORklHX0lXTFdJ
RklfTEVEUz15CkNPTkZJR19JV0xEVk09bQpDT05GSUdfSVdMTVZNPW0KQ09ORklHX0lXTFdJ
RklfT1BNT0RFX01PRFVMQVI9eQojIENPTkZJR19JV0xXSUZJX0JDQVNUX0ZJTFRFUklORyBp
cyBub3Qgc2V0CgojCiMgRGVidWdnaW5nIE9wdGlvbnMKIwojIENPTkZJR19JV0xXSUZJX0RF
QlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfSVdMNDk2NSBpcyBub3Qgc2V0CiMgQ09ORklHX0lX
TDM5NDUgaXMgbm90IHNldAojIENPTkZJR19MSUJFUlRBUyBpcyBub3Qgc2V0CiMgQ09ORklH
X0hFUk1FUyBpcyBub3Qgc2V0CiMgQ09ORklHX1A1NF9DT01NT04gaXMgbm90IHNldAojIENP
TkZJR19SVDJYMDAgaXMgbm90IHNldAojIENPTkZJR19SVExfQ0FSRFMgaXMgbm90IHNldAoj
IENPTkZJR19XTF9USSBpcyBub3Qgc2V0CiMgQ09ORklHX1pEMTIxMVJXIGlzIG5vdCBzZXQK
IyBDT05GSUdfTVdJRklFWCBpcyBub3Qgc2V0CiMgQ09ORklHX0NXMTIwMCBpcyBub3Qgc2V0
CiMgQ09ORklHX1JTSV85MVggaXMgbm90IHNldAoKIwojIEVuYWJsZSBXaU1BWCAoTmV0d29y
a2luZyBvcHRpb25zKSB0byBzZWUgdGhlIFdpTUFYIGRyaXZlcnMKIwojIENPTkZJR19XQU4g
aXMgbm90IHNldApDT05GSUdfWEVOX05FVERFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fTkVU
REVWX0JBQ0tFTkQ9eQojIENPTkZJR19WTVhORVQzIGlzIG5vdCBzZXQKIyBDT05GSUdfSFlQ
RVJWX05FVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lTRE4gaXMgbm90IHNldAoKIwojIElucHV0
IGRldmljZSBzdXBwb3J0CiMKQ09ORklHX0lOUFVUPXkKQ09ORklHX0lOUFVUX0ZGX01FTUxF
U1M9eQpDT05GSUdfSU5QVVRfUE9MTERFVj15CkNPTkZJR19JTlBVVF9TUEFSU0VLTUFQPXkK
IyBDT05GSUdfSU5QVVRfTUFUUklYS01BUCBpcyBub3Qgc2V0CgojCiMgVXNlcmxhbmQgaW50
ZXJmYWNlcwojCkNPTkZJR19JTlBVVF9NT1VTRURFVj15CkNPTkZJR19JTlBVVF9NT1VTRURF
Vl9QU0FVWD15CkNPTkZJR19JTlBVVF9NT1VTRURFVl9TQ1JFRU5fWD0xMDI0CkNPTkZJR19J
TlBVVF9NT1VTRURFVl9TQ1JFRU5fWT03NjgKIyBDT05GSUdfSU5QVVRfSk9ZREVWIGlzIG5v
dCBzZXQKQ09ORklHX0lOUFVUX0VWREVWPXkKIyBDT05GSUdfSU5QVVRfRVZCVUcgaXMgbm90
IHNldAoKIwojIElucHV0IERldmljZSBEcml2ZXJzCiMKQ09ORklHX0lOUFVUX0tFWUJPQVJE
PXkKQ09ORklHX0tFWUJPQVJEX0FEUDU1ODg9bQojIENPTkZJR19LRVlCT0FSRF9BRFA1NTg5
IGlzIG5vdCBzZXQKQ09ORklHX0tFWUJPQVJEX0FUS0JEPXkKIyBDT05GSUdfS0VZQk9BUkRf
UVQxMDcwIGlzIG5vdCBzZXQKQ09ORklHX0tFWUJPQVJEX1FUMjE2MD1tCkNPTkZJR19LRVlC
T0FSRF9MS0tCRD1tCiMgQ09ORklHX0tFWUJPQVJEX0dQSU8gaXMgbm90IHNldAojIENPTkZJ
R19LRVlCT0FSRF9HUElPX1BPTExFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1RD
QTY0MTYgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9UQ0E4NDE4IGlzIG5vdCBzZXQK
IyBDT05GSUdfS0VZQk9BUkRfTUFUUklYIGlzIG5vdCBzZXQKQ09ORklHX0tFWUJPQVJEX0xN
ODMyMz1tCiMgQ09ORklHX0tFWUJPQVJEX0xNODMzMyBpcyBub3Qgc2V0CkNPTkZJR19LRVlC
T0FSRF9NQVg3MzU5PW0KIyBDT05GSUdfS0VZQk9BUkRfTUNTIGlzIG5vdCBzZXQKIyBDT05G
SUdfS0VZQk9BUkRfTVBSMTIxIGlzIG5vdCBzZXQKQ09ORklHX0tFWUJPQVJEX05FV1RPTj1t
CkNPTkZJR19LRVlCT0FSRF9PUEVOQ09SRVM9bQpDT05GSUdfS0VZQk9BUkRfU1RPV0FXQVk9
bQpDT05GSUdfS0VZQk9BUkRfU1VOS0JEPW0KQ09ORklHX0tFWUJPQVJEX1hUS0JEPW0KIyBD
T05GSUdfSU5QVVRfTU9VU0UgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9KT1lTVElDSyBp
cyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX1RBQkxFVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
UFVUX1RPVUNIU0NSRUVOIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfTUlTQyBpcyBub3Qg
c2V0CgojCiMgSGFyZHdhcmUgSS9PIHBvcnRzCiMKQ09ORklHX1NFUklPPXkKQ09ORklHX0FS
Q0hfTUlHSFRfSEFWRV9QQ19TRVJJTz15CkNPTkZJR19TRVJJT19JODA0Mj15CkNPTkZJR19T
RVJJT19TRVJQT1JUPW0KQ09ORklHX1NFUklPX0NUODJDNzEwPW0KQ09ORklHX1NFUklPX1BD
SVBTMj1tCkNPTkZJR19TRVJJT19MSUJQUzI9eQpDT05GSUdfU0VSSU9fUkFXPW0KQ09ORklH
X1NFUklPX0FMVEVSQV9QUzI9bQojIENPTkZJR19TRVJJT19QUzJNVUxUIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VSSU9fQVJDX1BTMiBpcyBub3Qgc2V0CkNPTkZJR19IWVBFUlZfS0VZQk9B
UkQ9eQpDT05GSUdfR0FNRVBPUlQ9bQpDT05GSUdfR0FNRVBPUlRfTlM1NTg9bQpDT05GSUdf
R0FNRVBPUlRfTDQ9bQpDT05GSUdfR0FNRVBPUlRfRU1VMTBLMT1tCkNPTkZJR19HQU1FUE9S
VF9GTTgwMT1tCgojCiMgQ2hhcmFjdGVyIGRldmljZXMKIwpDT05GSUdfVFRZPXkKQ09ORklH
X1ZUPXkKQ09ORklHX0NPTlNPTEVfVFJBTlNMQVRJT05TPXkKQ09ORklHX1ZUX0NPTlNPTEU9
eQpDT05GSUdfVlRfQ09OU09MRV9TTEVFUD15CkNPTkZJR19IV19DT05TT0xFPXkKQ09ORklH
X1ZUX0hXX0NPTlNPTEVfQklORElORz15CkNPTkZJR19VTklYOThfUFRZUz15CkNPTkZJR19E
RVZQVFNfTVVMVElQTEVfSU5TVEFOQ0VTPXkKIyBDT05GSUdfTEVHQUNZX1BUWVMgaXMgbm90
IHNldApDT05GSUdfU0VSSUFMX05PTlNUQU5EQVJEPXkKIyBDT05GSUdfUk9DS0VUUE9SVCBp
cyBub3Qgc2V0CiMgQ09ORklHX0NZQ0xBREVTIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9YQV9J
TlRFTExJTyBpcyBub3Qgc2V0CiMgQ09ORklHX01PWEFfU01BUlRJTyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NZTkNMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfU1lOQ0xJTktNUCBpcyBub3Qg
c2V0CiMgQ09ORklHX1NZTkNMSU5LX0dUIGlzIG5vdCBzZXQKIyBDT05GSUdfTk9aT01JIGlz
IG5vdCBzZXQKIyBDT05GSUdfSVNJIGlzIG5vdCBzZXQKIyBDT05GSUdfTl9IRExDIGlzIG5v
dCBzZXQKIyBDT05GSUdfTl9HU00gaXMgbm90IHNldAojIENPTkZJR19UUkFDRV9TSU5LIGlz
IG5vdCBzZXQKIyBDT05GSUdfREVWS01FTSBpcyBub3Qgc2V0CgojCiMgU2VyaWFsIGRyaXZl
cnMKIwpDT05GSUdfU0VSSUFMX0VBUkxZQ09OPXkKQ09ORklHX1NFUklBTF84MjUwPXkKQ09O
RklHX1NFUklBTF84MjUwX0RFUFJFQ0FURURfT1BUSU9OUz15CkNPTkZJR19TRVJJQUxfODI1
MF9QTlA9eQpDT05GSUdfU0VSSUFMXzgyNTBfQ09OU09MRT15CkNPTkZJR19TRVJJQUxfODI1
MF9ETUE9eQpDT05GSUdfU0VSSUFMXzgyNTBfUENJPXkKQ09ORklHX1NFUklBTF84MjUwX05S
X1VBUlRTPTMyCkNPTkZJR19TRVJJQUxfODI1MF9SVU5USU1FX1VBUlRTPTQKQ09ORklHX1NF
UklBTF84MjUwX0VYVEVOREVEPXkKQ09ORklHX1NFUklBTF84MjUwX01BTllfUE9SVFM9eQpD
T05GSUdfU0VSSUFMXzgyNTBfU0hBUkVfSVJRPXkKIyBDT05GSUdfU0VSSUFMXzgyNTBfREVU
RUNUX0lSUSBpcyBub3Qgc2V0CkNPTkZJR19TRVJJQUxfODI1MF9SU0E9eQojIENPTkZJR19T
RVJJQUxfODI1MF9EVyBpcyBub3Qgc2V0CgojCiMgTm9uLTgyNTAgc2VyaWFsIHBvcnQgc3Vw
cG9ydAojCkNPTkZJR19TRVJJQUxfTUZEX0hTVT1tCkNPTkZJR19TRVJJQUxfQ09SRT15CkNP
TkZJR19TRVJJQUxfQ09SRV9DT05TT0xFPXkKQ09ORklHX1NFUklBTF9KU009bQojIENPTkZJ
R19TRVJJQUxfU0NDTlhQIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX1NDMTZJUzdYWCBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9BTFRFUkFfSlRBR1VBUlQgaXMgbm90IHNldAoj
IENPTkZJR19TRVJJQUxfQUxURVJBX1VBUlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxf
QVJDIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX1JQMiBpcyBub3Qgc2V0CiMgQ09ORklH
X1NFUklBTF9GU0xfTFBVQVJUIGlzIG5vdCBzZXQKQ09ORklHX0hWQ19EUklWRVI9eQpDT05G
SUdfSFZDX0lSUT15CkNPTkZJR19IVkNfWEVOPXkKQ09ORklHX0hWQ19YRU5fRlJPTlRFTkQ9
eQojIENPTkZJR19WSVJUSU9fQ09OU09MRSBpcyBub3Qgc2V0CkNPTkZJR19JUE1JX0hBTkRM
RVI9eQojIENPTkZJR19JUE1JX1BBTklDX0VWRU5UIGlzIG5vdCBzZXQKQ09ORklHX0lQTUlf
REVWSUNFX0lOVEVSRkFDRT15CkNPTkZJR19JUE1JX1NJPXkKIyBDT05GSUdfSVBNSV9TSV9Q
Uk9CRV9ERUZBVUxUUyBpcyBub3Qgc2V0CkNPTkZJR19JUE1JX1dBVENIRE9HPXkKQ09ORklH
X0lQTUlfUE9XRVJPRkY9eQpDT05GSUdfSFdfUkFORE9NPXkKQ09ORklHX0hXX1JBTkRPTV9U
SU1FUklPTUVNPXkKQ09ORklHX0hXX1JBTkRPTV9JTlRFTD15CkNPTkZJR19IV19SQU5ET01f
QU1EPXkKQ09ORklHX0hXX1JBTkRPTV9WSUE9eQojIENPTkZJR19IV19SQU5ET01fVklSVElP
IGlzIG5vdCBzZXQKQ09ORklHX0hXX1JBTkRPTV9UUE09eQpDT05GSUdfTlZSQU09eQojIENP
TkZJR19SMzk2NCBpcyBub3Qgc2V0CiMgQ09ORklHX0FQUExJQ09NIGlzIG5vdCBzZXQKIyBD
T05GSUdfTVdBVkUgaXMgbm90IHNldAojIENPTkZJR19SQVdfRFJJVkVSIGlzIG5vdCBzZXQK
Q09ORklHX0hQRVQ9eQpDT05GSUdfSFBFVF9NTUFQPXkKQ09ORklHX0hQRVRfTU1BUF9ERUZB
VUxUPXkKQ09ORklHX0hBTkdDSEVDS19USU1FUj15CkNPTkZJR19UQ0dfVFBNPXkKQ09ORklH
X1RDR19USVM9eQojIENPTkZJR19UQ0dfVElTX0kyQ19BVE1FTCBpcyBub3Qgc2V0CiMgQ09O
RklHX1RDR19USVNfSTJDX0lORklORU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfVENHX1RJU19J
MkNfTlVWT1RPTiBpcyBub3Qgc2V0CiMgQ09ORklHX1RDR19OU0MgaXMgbm90IHNldAojIENP
TkZJR19UQ0dfQVRNRUwgaXMgbm90IHNldAojIENPTkZJR19UQ0dfSU5GSU5FT04gaXMgbm90
IHNldAojIENPTkZJR19UQ0dfU1QzM19JMkMgaXMgbm90IHNldAojIENPTkZJR19UQ0dfWEVO
IGlzIG5vdCBzZXQKIyBDT05GSUdfVEVMQ0xPQ0sgaXMgbm90IHNldApDT05GSUdfREVWUE9S
VD15CkNPTkZJR19JMkM9eQpDT05GSUdfSTJDX0JPQVJESU5GTz15CkNPTkZJR19JMkNfQ09N
UEFUPXkKQ09ORklHX0kyQ19DSEFSREVWPXkKIyBDT05GSUdfSTJDX01VWCBpcyBub3Qgc2V0
CkNPTkZJR19JMkNfSEVMUEVSX0FVVE89eQpDT05GSUdfSTJDX0FMR09CSVQ9eQoKIwojIEky
QyBIYXJkd2FyZSBCdXMgc3VwcG9ydAojCgojCiMgUEMgU01CdXMgaG9zdCBjb250cm9sbGVy
IGRyaXZlcnMKIwpDT05GSUdfSTJDX0FMSTE1MzU9eQpDT05GSUdfSTJDX0FMSTE1NjM9eQpD
T05GSUdfSTJDX0FMSTE1WDM9eQpDT05GSUdfSTJDX0FNRDc1Nj15CkNPTkZJR19JMkNfQU1E
NzU2X1M0ODgyPXkKQ09ORklHX0kyQ19BTUQ4MTExPXkKQ09ORklHX0kyQ19JODAxPXkKQ09O
RklHX0kyQ19JU0NIPXkKQ09ORklHX0kyQ19JU01UPXkKQ09ORklHX0kyQ19QSUlYND15CkNP
TkZJR19JMkNfTkZPUkNFMj15CkNPTkZJR19JMkNfTkZPUkNFMl9TNDk4NT15CkNPTkZJR19J
MkNfU0lTNTU5NT15CkNPTkZJR19JMkNfU0lTNjMwPXkKQ09ORklHX0kyQ19TSVM5Nlg9eQpD
T05GSUdfSTJDX1ZJQT15CkNPTkZJR19JMkNfVklBUFJPPXkKCiMKIyBBQ1BJIGRyaXZlcnMK
IwpDT05GSUdfSTJDX1NDTUk9eQoKIwojIEkyQyBzeXN0ZW0gYnVzIGRyaXZlcnMgKG1vc3Rs
eSBlbWJlZGRlZCAvIHN5c3RlbS1vbi1jaGlwKQojCiMgQ09ORklHX0kyQ19DQlVTX0dQSU8g
aXMgbm90IHNldAojIENPTkZJR19JMkNfREVTSUdOV0FSRV9QTEFURk9STSBpcyBub3Qgc2V0
CiMgQ09ORklHX0kyQ19ERVNJR05XQVJFX1BDSSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19H
UElPIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX09DT1JFUyBpcyBub3Qgc2V0CiMgQ09ORklH
X0kyQ19QQ0FfUExBVEZPUk0gaXMgbm90IHNldAojIENPTkZJR19JMkNfUFhBX1BDSSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0kyQ19TSU1URUMgaXMgbm90IHNldAojIENPTkZJR19JMkNfWElM
SU5YIGlzIG5vdCBzZXQKCiMKIyBFeHRlcm5hbCBJMkMvU01CdXMgYWRhcHRlciBkcml2ZXJz
CiMKIyBDT05GSUdfSTJDX0RJT0xBTl9VMkMgaXMgbm90IHNldAojIENPTkZJR19JMkNfUEFS
UE9SVF9MSUdIVCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ST0JPVEZVWlpfT1NJRiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0kyQ19UQU9TX0VWTSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19U
SU5ZX1VTQiBpcyBub3Qgc2V0CgojCiMgT3RoZXIgSTJDL1NNQnVzIGJ1cyBkcml2ZXJzCiMK
IyBDT05GSUdfSTJDX1NUVUIgaXMgbm90IHNldAojIENPTkZJR19JMkNfREVCVUdfQ09SRSBp
cyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERUJVR19BTEdPIGlzIG5vdCBzZXQKIyBDT05GSUdf
STJDX0RFQlVHX0JVUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NQSSBpcyBub3Qgc2V0CiMgQ09O
RklHX1NQTUkgaXMgbm90IHNldAojIENPTkZJR19IU0kgaXMgbm90IHNldAoKIwojIFBQUyBz
dXBwb3J0CiMKQ09ORklHX1BQUz15CiMgQ09ORklHX1BQU19ERUJVRyBpcyBub3Qgc2V0Cgoj
CiMgUFBTIGNsaWVudHMgc3VwcG9ydAojCiMgQ09ORklHX1BQU19DTElFTlRfS1RJTUVSIGlz
IG5vdCBzZXQKQ09ORklHX1BQU19DTElFTlRfTERJU0M9eQojIENPTkZJR19QUFNfQ0xJRU5U
X0dQSU8gaXMgbm90IHNldAoKIwojIFBQUyBnZW5lcmF0b3JzIHN1cHBvcnQKIwoKIwojIFBU
UCBjbG9jayBzdXBwb3J0CiMKQ09ORklHX1BUUF8xNTg4X0NMT0NLPXkKCiMKIyBFbmFibGUg
UEhZTElCIGFuZCBORVRXT1JLX1BIWV9USU1FU1RBTVBJTkcgdG8gc2VlIHRoZSBhZGRpdGlv
bmFsIGNsb2Nrcy4KIwojIENPTkZJR19QVFBfMTU4OF9DTE9DS19QQ0ggaXMgbm90IHNldApD
T05GSUdfQVJDSF9XQU5UX09QVElPTkFMX0dQSU9MSUI9eQpDT05GSUdfR1BJT0xJQj15CkNP
TkZJR19HUElPX0RFVlJFUz15CkNPTkZJR19HUElPX0FDUEk9eQojIENPTkZJR19ERUJVR19H
UElPIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19TWVNGUyBpcyBub3Qgc2V0CgojCiMgTWVt
b3J5IG1hcHBlZCBHUElPIGRyaXZlcnM6CiMKIyBDT05GSUdfR1BJT19HRU5FUklDX1BMQVRG
T1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19JVDg3NjFFIGlzIG5vdCBzZXQKIyBDT05G
SUdfR1BJT19GNzE4OFggaXMgbm90IHNldAojIENPTkZJR19HUElPX1NDSDMxMVggaXMgbm90
IHNldAojIENPTkZJR19HUElPX1NDSCBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fSUNIIGlz
IG5vdCBzZXQKIyBDT05GSUdfR1BJT19WWDg1NSBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9f
TFlOWFBPSU5UIGlzIG5vdCBzZXQKCiMKIyBJMkMgR1BJTyBleHBhbmRlcnM6CiMKIyBDT05G
SUdfR1BJT19NQVg3MzAwIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19NQVg3MzJYIGlzIG5v
dCBzZXQKIyBDT05GSUdfR1BJT19QQ0E5NTNYIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19Q
Q0Y4NTdYIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19TWDE1MFggaXMgbm90IHNldAojIENP
TkZJR19HUElPX0FEUDU1ODggaXMgbm90IHNldAoKIwojIFBDSSBHUElPIGV4cGFuZGVyczoK
IwojIENPTkZJR19HUElPX0JUOFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19BTUQ4MTEx
IGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19JTlRFTF9NSUQgaXMgbm90IHNldApDT05GSUdf
R1BJT19NTF9JT0g9eQojIENPTkZJR19HUElPX1JEQzMyMVggaXMgbm90IHNldAoKIwojIFNQ
SSBHUElPIGV4cGFuZGVyczoKIwoKIwojIEFDOTcgR1BJTyBleHBhbmRlcnM6CiMKCiMKIyBM
UEMgR1BJTyBleHBhbmRlcnM6CiMKCiMKIyBNT0RVTGJ1cyBHUElPIGV4cGFuZGVyczoKIwoK
IwojIFVTQiBHUElPIGV4cGFuZGVyczoKIwojIENPTkZJR19XMSBpcyBub3Qgc2V0CkNPTkZJ
R19QT1dFUl9TVVBQTFk9eQojIENPTkZJR19QT1dFUl9TVVBQTFlfREVCVUcgaXMgbm90IHNl
dAojIENPTkZJR19QREFfUE9XRVIgaXMgbm90IHNldAojIENPTkZJR19HRU5FUklDX0FEQ19C
QVRURVJZIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9QT1dFUiBpcyBub3Qgc2V0CiMgQ09O
RklHX0JBVFRFUllfRFMyNzgwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3ODEg
aXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX0RTMjc4MiBpcyBub3Qgc2V0CiMgQ09ORklH
X0JBVFRFUllfU0JTIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9CUTI3eDAwIGlzIG5v
dCBzZXQKIyBDT05GSUdfQkFUVEVSWV9NQVgxNzA0MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JB
VFRFUllfTUFYMTcwNDIgaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX1BDRjUwNjMzIGlz
IG5vdCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9NQVg4OTAzIGlzIG5vdCBzZXQKIyBDT05GSUdf
Q0hBUkdFUl9MUDg3MjcgaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0dQSU8gaXMgbm90
IHNldAojIENPTkZJR19DSEFSR0VSX0JRMjQxNVggaXMgbm90IHNldAojIENPTkZJR19DSEFS
R0VSX0JRMjQxOTAgaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0JRMjQ3MzUgaXMgbm90
IHNldAojIENPTkZJR19DSEFSR0VSX1NNQjM0NyBpcyBub3Qgc2V0CiMgQ09ORklHX1BPV0VS
X1JFU0VUIGlzIG5vdCBzZXQKIyBDT05GSUdfUE9XRVJfQVZTIGlzIG5vdCBzZXQKQ09ORklH
X0hXTU9OPXkKQ09ORklHX0hXTU9OX1ZJRD15CiMgQ09ORklHX0hXTU9OX0RFQlVHX0NISVAg
aXMgbm90IHNldAoKIwojIE5hdGl2ZSBkcml2ZXJzCiMKIyBDT05GSUdfU0VOU09SU19BQklU
VUdVUlUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FCSVRVR1VSVTMgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0FENzQxNCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf
QUQ3NDE4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDIxIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19BRE0xMDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19B
RE0xMDI2IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDI5IGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19BRE0xMDMxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19B
RE05MjQwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDEwIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19BRFQ3NDExIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19B
RFQ3NDYyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDcwIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19BRFQ3NDc1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19B
U0M3NjIxIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfSzhURU1QPXkKQ09ORklHX1NFTlNP
UlNfSzEwVEVNUD15CkNPTkZJR19TRU5TT1JTX0ZBTTE1SF9QT1dFUj15CiMgQ09ORklHX1NF
TlNPUlNfQVBQTEVTTUMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FTQjEwMCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQVRYUDEgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX0RTNjIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19EUzE2MjEgaXMgbm90IHNl
dApDT05GSUdfU0VOU09SU19JNUtfQU1CPXkKQ09ORklHX1NFTlNPUlNfRjcxODA1Rj15CkNP
TkZJR19TRU5TT1JTX0Y3MTg4MkZHPXkKQ09ORklHX1NFTlNPUlNfRjc1Mzc1Uz15CiMgQ09O
RklHX1NFTlNPUlNfRlNDSE1EIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUxOFNN
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUyMFNNIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19HNzYwQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRzc2MiBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfR1BJT19GQU4gaXMgbm90IHNldAojIENPTkZJR19T
RU5TT1JTX0hJSDYxMzAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0lCTUFFTSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfSUJNUEVYIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19JSU9fSFdNT04gaXMgbm90IHNldApDT05GSUdfU0VOU09SU19DT1JFVEVNUD15CiMg
Q09ORklHX1NFTlNPUlNfSVQ4NyBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0pDNDI9eQoj
IENPTkZJR19TRU5TT1JTX0xJTkVBR0UgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xU
QzI5NDUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xUQzQxNTEgaXMgbm90IHNldAoj
IENPTkZJR19TRU5TT1JTX0xUQzQyMTUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xU
QzQyMjIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xUQzQyNDUgaXMgbm90IHNldAoj
IENPTkZJR19TRU5TT1JTX0xUQzQyNjAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xU
QzQyNjEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX01BWDE2MDY1IGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19NQVgxNjE5IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19N
QVgxNjY4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVgxOTcgaXMgbm90IHNldAoj
IENPTkZJR19TRU5TT1JTX01BWDY2MzkgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX01B
WDY2NDIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX01BWDY2NTAgaXMgbm90IHNldAoj
IENPTkZJR19TRU5TT1JTX01BWDY2OTcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0hU
VTIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQ1AzMDIxIGlzIG5vdCBzZXQKQ09O
RklHX1NFTlNPUlNfTE02Mz15CkNPTkZJR19TRU5TT1JTX0xNNzM9eQpDT05GSUdfU0VOU09S
U19MTTc1PXkKQ09ORklHX1NFTlNPUlNfTE03Nz15CkNPTkZJR19TRU5TT1JTX0xNNzg9eQpD
T05GSUdfU0VOU09SU19MTTgwPXkKQ09ORklHX1NFTlNPUlNfTE04Mz15CkNPTkZJR19TRU5T
T1JTX0xNODU9eQpDT05GSUdfU0VOU09SU19MTTg3PXkKQ09ORklHX1NFTlNPUlNfTE05MD15
CkNPTkZJR19TRU5TT1JTX0xNOTI9eQpDT05GSUdfU0VOU09SU19MTTkzPXkKIyBDT05GSUdf
U0VOU09SU19MTTk1MjM0IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjQxIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjQ1IGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19QQzg3MzYwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19QQzg3NDI3IGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19OVENfVEhFUk1JU1RPUiBpcyBub3Qgc2V0CiMg
Q09ORklHX1NFTlNPUlNfTkNUNjY4MyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTkNU
Njc3NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUENGODU5MSBpcyBub3Qgc2V0CkNP
TkZJR19QTUJVUz15CkNPTkZJR19TRU5TT1JTX1BNQlVTPXkKIyBDT05GSUdfU0VOU09SU19B
RE0xMjc1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTI1MDY2IGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19MVEMyOTc4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19N
QVgxNjA2NCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMzQ0NDAgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX01BWDg2ODggaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X1VDRDkwMDAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1VDRDkyMDAgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX1pMNjEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf
U0hUMTUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NIVDIxIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19TSFRDMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU0lTNTU5
NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRE1FMTczNyBpcyBub3Qgc2V0CiMgQ09O
RklHX1NFTlNPUlNfRU1DMTQwMyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRU1DMjEw
MyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRU1DNlcyMDEgaXMgbm90IHNldAojIENP
TkZJR19TRU5TT1JTX1NNU0M0N00xIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TTVND
NDdNMTkyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TTVNDNDdCMzk3IGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19TQ0g1NlhYX0NPTU1PTiBpcyBub3Qgc2V0CiMgQ09ORklH
X1NFTlNPUlNfU0NINTYyNyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU0NINTYzNiBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU01NNjY1IGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19BREMxMjhEODE4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFMxMDE1
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFM3ODI4IGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19BTUM2ODIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19JTkEyMDkg
aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0lOQTJYWCBpcyBub3Qgc2V0CiMgQ09ORklH
X1NFTlNPUlNfVEhNQzUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19UTVAxMDIgaXMg
bm90IHNldAojIENPTkZJR19TRU5TT1JTX1RNUDQwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NF
TlNPUlNfVE1QNDIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19WSUFfQ1BVVEVNUCBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVklBNjg2QSBpcyBub3Qgc2V0CiMgQ09ORklH
X1NFTlNPUlNfVlQxMjExIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19WVDgyMzEgaXMg
bm90IHNldApDT05GSUdfU0VOU09SU19XODM3ODFEPXkKQ09ORklHX1NFTlNPUlNfVzgzNzkx
RD15CkNPTkZJR19TRU5TT1JTX1c4Mzc5MkQ9eQpDT05GSUdfU0VOU09SU19XODM3OTM9eQpD
T05GSUdfU0VOU09SU19XODM3OTU9eQojIENPTkZJR19TRU5TT1JTX1c4Mzc5NV9GQU5DVFJM
IGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfVzgzTDc4NVRTPXkKQ09ORklHX1NFTlNPUlNf
VzgzTDc4Nk5HPXkKQ09ORklHX1NFTlNPUlNfVzgzNjI3SEY9eQpDT05GSUdfU0VOU09SU19X
ODM2MjdFSEY9eQoKIwojIEFDUEkgZHJpdmVycwojCkNPTkZJR19TRU5TT1JTX0FDUElfUE9X
RVI9eQojIENPTkZJR19TRU5TT1JTX0FUSzAxMTAgaXMgbm90IHNldApDT05GSUdfVEhFUk1B
TD15CkNPTkZJR19USEVSTUFMX0hXTU9OPXkKQ09ORklHX1RIRVJNQUxfREVGQVVMVF9HT1Zf
U1RFUF9XSVNFPXkKIyBDT05GSUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9GQUlSX1NIQVJFIGlz
IG5vdCBzZXQKIyBDT05GSUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9VU0VSX1NQQUNFIGlzIG5v
dCBzZXQKIyBDT05GSUdfVEhFUk1BTF9HT1ZfRkFJUl9TSEFSRSBpcyBub3Qgc2V0CkNPTkZJ
R19USEVSTUFMX0dPVl9TVEVQX1dJU0U9eQpDT05GSUdfVEhFUk1BTF9HT1ZfVVNFUl9TUEFD
RT15CiMgQ09ORklHX1RIRVJNQUxfRU1VTEFUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5U
RUxfUE9XRVJDTEFNUCBpcyBub3Qgc2V0CkNPTkZJR19YODZfUEtHX1RFTVBfVEhFUk1BTD15
CiMgQ09ORklHX0FDUElfSU5UMzQwM19USEVSTUFMIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5U
RUxfU09DX0RUU19USEVSTUFMIGlzIG5vdCBzZXQKCiMKIyBUZXhhcyBJbnN0cnVtZW50cyB0
aGVybWFsIGRyaXZlcnMKIwpDT05GSUdfV0FUQ0hET0c9eQpDT05GSUdfV0FUQ0hET0dfQ09S
RT15CiMgQ09ORklHX1dBVENIRE9HX05PV0FZT1VUIGlzIG5vdCBzZXQKCiMKIyBXYXRjaGRv
ZyBEZXZpY2UgRHJpdmVycwojCkNPTkZJR19TT0ZUX1dBVENIRE9HPXkKIyBDT05GSUdfWElM
SU5YX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfRFdfV0FUQ0hET0cgaXMgbm90IHNl
dAojIENPTkZJR19BQ1FVSVJFX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0FEVkFOVEVDSF9X
RFQgaXMgbm90IHNldAojIENPTkZJR19BTElNMTUzNV9XRFQgaXMgbm90IHNldAojIENPTkZJ
R19BTElNNzEwMV9XRFQgaXMgbm90IHNldApDT05GSUdfRjcxODA4RV9XRFQ9eQpDT05GSUdf
U1A1MTAwX1RDTz15CiMgQ09ORklHX1NCQ19GSVRQQzJfV0FUQ0hET0cgaXMgbm90IHNldAoj
IENPTkZJR19FVVJPVEVDSF9XRFQgaXMgbm90IHNldAojIENPTkZJR19JQjcwMF9XRFQgaXMg
bm90IHNldAojIENPTkZJR19JQk1BU1IgaXMgbm90IHNldAojIENPTkZJR19XQUZFUl9XRFQg
aXMgbm90IHNldApDT05GSUdfSTYzMDBFU0JfV0RUPXkKQ09ORklHX0lFNlhYX1dEVD15CkNP
TkZJR19JVENPX1dEVD15CkNPTkZJR19JVENPX1ZFTkRPUl9TVVBQT1JUPXkKIyBDT05GSUdf
SVQ4NzEyRl9XRFQgaXMgbm90IHNldAojIENPTkZJR19JVDg3X1dEVCBpcyBub3Qgc2V0CiMg
Q09ORklHX0hQX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfU0MxMjAwX1dEVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1BDODc0MTNfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfTlZfVENP
IGlzIG5vdCBzZXQKIyBDT05GSUdfNjBYWF9XRFQgaXMgbm90IHNldAojIENPTkZJR19DUFU1
X1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NNU0NfU0NIMzExWF9XRFQgaXMgbm90IHNldAoj
IENPTkZJR19TTVNDMzdCNzg3X1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJQV9XRFQgaXMg
bm90IHNldAojIENPTkZJR19XODM2MjdIRl9XRFQgaXMgbm90IHNldAojIENPTkZJR19XODM4
NzdGX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1c4Mzk3N0ZfV0RUIGlzIG5vdCBzZXQKIyBD
T05GSUdfTUFDSFpfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0JDX0VQWF9DM19XQVRDSERP
RyBpcyBub3Qgc2V0CiMgQ09ORklHX01FTl9BMjFfV0RUIGlzIG5vdCBzZXQKQ09ORklHX1hF
Tl9XRFQ9eQoKIwojIFBDSS1iYXNlZCBXYXRjaGRvZyBDYXJkcwojCiMgQ09ORklHX1BDSVBD
V0FUQ0hET0cgaXMgbm90IHNldAojIENPTkZJR19XRFRQQ0kgaXMgbm90IHNldAoKIwojIFVT
Qi1iYXNlZCBXYXRjaGRvZyBDYXJkcwojCiMgQ09ORklHX1VTQlBDV0FUQ0hET0cgaXMgbm90
IHNldApDT05GSUdfU1NCX1BPU1NJQkxFPXkKCiMKIyBTb25pY3MgU2lsaWNvbiBCYWNrcGxh
bmUKIwojIENPTkZJR19TU0IgaXMgbm90IHNldApDT05GSUdfQkNNQV9QT1NTSUJMRT15Cgoj
CiMgQnJvYWRjb20gc3BlY2lmaWMgQU1CQQojCiMgQ09ORklHX0JDTUEgaXMgbm90IHNldAoK
IwojIE11bHRpZnVuY3Rpb24gZGV2aWNlIGRyaXZlcnMKIwpDT05GSUdfTUZEX0NPUkU9eQoj
IENPTkZJR19NRkRfQ1M1NTM1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0FTMzcxMSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1BNSUNfQURQNTUyMCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9B
QVQyODcwX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19NRkRfQkNNNTkwWFggaXMgbm90IHNl
dAojIENPTkZJR19NRkRfQVhQMjBYIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0NST1NfRUMg
aXMgbm90IHNldAojIENPTkZJR19QTUlDX0RBOTAzWCBpcyBub3Qgc2V0CiMgQ09ORklHX01G
RF9EQTkwNTJfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0RBOTA1NSBpcyBub3Qgc2V0
CiMgQ09ORklHX01GRF9EQTkwNjMgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUMxM1hYWF9J
MkMgaXMgbm90IHNldApDT05GSUdfSFRDX1BBU0lDMz1tCiMgQ09ORklHX0hUQ19JMkNQTEQg
aXMgbm90IHNldApDT05GSUdfTFBDX0lDSD15CkNPTkZJR19MUENfU0NIPXkKIyBDT05GSUdf
TUZEX0pBTlpfQ01PRElPIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0tFTVBMRCBpcyBub3Qg
c2V0CiMgQ09ORklHX01GRF84OFBNODAwIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEXzg4UE04
MDUgaXMgbm90IHNldAojIENPTkZJR19NRkRfODhQTTg2MFggaXMgbm90IHNldAojIENPTkZJ
R19NRkRfTUFYMTQ1NzcgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYNzc2ODYgaXMgbm90
IHNldAojIENPTkZJR19NRkRfTUFYNzc2OTMgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUFY
ODkwNyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg4OTI1IGlzIG5vdCBzZXQKIyBDT05G
SUdfTUZEX01BWDg5OTcgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYODk5OCBpcyBub3Qg
c2V0CiMgQ09ORklHX01GRF9WSVBFUkJPQVJEIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1JF
VFUgaXMgbm90IHNldApDT05GSUdfTUZEX1BDRjUwNjMzPW0KQ09ORklHX1BDRjUwNjMzX0FE
Qz1tCkNPTkZJR19QQ0Y1MDYzM19HUElPPW0KIyBDT05GSUdfTUZEX1JEQzMyMVggaXMgbm90
IHNldAojIENPTkZJR19NRkRfUlRTWF9QQ0kgaXMgbm90IHNldAojIENPTkZJR19NRkRfUlRT
WF9VU0IgaXMgbm90IHNldAojIENPTkZJR19NRkRfUkM1VDU4MyBpcyBub3Qgc2V0CiMgQ09O
RklHX01GRF9TRUNfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9TSTQ3NlhfQ09SRSBp
cyBub3Qgc2V0CkNPTkZJR19NRkRfU001MDE9bQojIENPTkZJR19NRkRfU001MDFfR1BJTyBp
cyBub3Qgc2V0CiMgQ09ORklHX01GRF9TTVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfQUJYNTAw
X0NPUkUgaXMgbm90IHNldAojIENPTkZJR19NRkRfU1lTQ09OIGlzIG5vdCBzZXQKIyBDT05G
SUdfTUZEX1RJX0FNMzM1WF9UU0NBREMgaXMgbm90IHNldAojIENPTkZJR19NRkRfTFAzOTQz
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0xQODc4OCBpcyBub3Qgc2V0CiMgQ09ORklHX01G
RF9QQUxNQVMgaXMgbm90IHNldAojIENPTkZJR19UUFM2MTA1WCBpcyBub3Qgc2V0CkNPTkZJ
R19UUFM2NTAxMD1tCiMgQ09ORklHX1RQUzY1MDdYIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE
X1RQUzY1MDkwIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1MjE3IGlzIG5vdCBzZXQK
IyBDT05GSUdfTUZEX1RQUzY1MjE4IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1ODZY
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1OTEwIGlzIG5vdCBzZXQKIyBDT05GSUdf
TUZEX1RQUzY1OTEyIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1OTEyX0kyQyBpcyBu
b3Qgc2V0CiMgQ09ORklHX01GRF9UUFM4MDAzMSBpcyBub3Qgc2V0CiMgQ09ORklHX1RXTDQw
MzBfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RXTDYwNDBfQ09SRSBpcyBub3Qgc2V0CkNP
TkZJR19NRkRfV0wxMjczX0NPUkU9bQojIENPTkZJR19NRkRfTE0zNTMzIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUZEX1RJTUJFUkRBTEUgaXMgbm90IHNldAojIENPTkZJR19NRkRfVEMzNTg5
WCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9UTUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE
X1ZYODU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0FSSVpPTkFfSTJDIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUZEX1dNODQwMCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9XTTgzMVhfSTJD
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1dNODM1MF9JMkMgaXMgbm90IHNldAojIENPTkZJ
R19NRkRfV004OTk0IGlzIG5vdCBzZXQKIyBDT05GSUdfUkVHVUxBVE9SIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUVESUFfU1VQUE9SVCBpcyBub3Qgc2V0CgojCiMgR3JhcGhpY3Mgc3VwcG9y
dAojCkNPTkZJR19BR1A9eQpDT05GSUdfQUdQX0FNRDY0PXkKQ09ORklHX0FHUF9JTlRFTD15
CkNPTkZJR19BR1BfU0lTPXkKQ09ORklHX0FHUF9WSUE9eQpDT05GSUdfSU5URUxfR1RUPXkK
Q09ORklHX1ZHQV9BUkI9eQpDT05GSUdfVkdBX0FSQl9NQVhfR1BVUz0xNgpDT05GSUdfVkdB
X1NXSVRDSEVST089eQoKIwojIERpcmVjdCBSZW5kZXJpbmcgTWFuYWdlcgojCkNPTkZJR19E
Uk09eQpDT05GSUdfRFJNX0tNU19IRUxQRVI9eQpDT05GSUdfRFJNX0tNU19GQl9IRUxQRVI9
eQojIENPTkZJR19EUk1fTE9BRF9FRElEX0ZJUk1XQVJFIGlzIG5vdCBzZXQKQ09ORklHX0RS
TV9UVE09eQoKIwojIEkyQyBlbmNvZGVyIG9yIGhlbHBlciBjaGlwcwojCkNPTkZJR19EUk1f
STJDX0NINzAwNj1tCkNPTkZJR19EUk1fSTJDX1NJTDE2ND1tCiMgQ09ORklHX0RSTV9JMkNf
TlhQX1REQTk5OFggaXMgbm90IHNldAojIENPTkZJR19EUk1fUFROMzQ2MCBpcyBub3Qgc2V0
CiMgQ09ORklHX0RSTV9UREZYIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1IxMjggaXMgbm90
IHNldAojIENPTkZJR19EUk1fUkFERU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX05PVVZF
QVUgaXMgbm90IHNldApDT05GSUdfRFJNX0k4MTA9eQpDT05GSUdfRFJNX0k5MTU9eQpDT05G
SUdfRFJNX0k5MTVfS01TPXkKQ09ORklHX0RSTV9JOTE1X0ZCREVWPXkKIyBDT05GSUdfRFJN
X0k5MTVfUFJFTElNSU5BUllfSFdfU1VQUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9N
R0EgaXMgbm90IHNldAojIENPTkZJR19EUk1fU0lTIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJN
X1ZJQSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9TQVZBR0UgaXMgbm90IHNldAojIENPTkZJ
R19EUk1fVk1XR0ZYIGlzIG5vdCBzZXQKQ09ORklHX0RSTV9HTUE1MDA9eQpDT05GSUdfRFJN
X0dNQTYwMD15CkNPTkZJR19EUk1fR01BMzYwMD15CiMgQ09ORklHX0RSTV9VREwgaXMgbm90
IHNldAojIENPTkZJR19EUk1fQVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX01HQUcyMDAg
aXMgbm90IHNldApDT05GSUdfRFJNX0NJUlJVU19RRU1VPXkKIyBDT05GSUdfRFJNX1FYTCBp
cyBub3Qgc2V0CiMgQ09ORklHX0RSTV9CT0NIUyBpcyBub3Qgc2V0CgojCiMgRnJhbWUgYnVm
ZmVyIERldmljZXMKIwpDT05GSUdfRkI9eQpDT05GSUdfRklSTVdBUkVfRURJRD15CkNPTkZJ
R19GQl9EREM9eQpDT05GSUdfRkJfQk9PVF9WRVNBX1NVUFBPUlQ9eQpDT05GSUdfRkJfQ0ZC
X0ZJTExSRUNUPXkKQ09ORklHX0ZCX0NGQl9DT1BZQVJFQT15CkNPTkZJR19GQl9DRkJfSU1B
R0VCTElUPXkKIyBDT05GSUdfRkJfQ0ZCX1JFVl9QSVhFTFNfSU5fQllURSBpcyBub3Qgc2V0
CkNPTkZJR19GQl9TWVNfRklMTFJFQ1Q9eQpDT05GSUdfRkJfU1lTX0NPUFlBUkVBPXkKQ09O
RklHX0ZCX1NZU19JTUFHRUJMSVQ9eQojIENPTkZJR19GQl9GT1JFSUdOX0VORElBTiBpcyBu
b3Qgc2V0CkNPTkZJR19GQl9TWVNfRk9QUz15CkNPTkZJR19GQl9ERUZFUlJFRF9JTz15CiMg
Q09ORklHX0ZCX1NWR0FMSUIgaXMgbm90IHNldAojIENPTkZJR19GQl9NQUNNT0RFUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0ZCX0JBQ0tMSUdIVCBpcyBub3Qgc2V0CkNPTkZJR19GQl9NT0RF
X0hFTFBFUlM9eQpDT05GSUdfRkJfVElMRUJMSVRUSU5HPXkKCiMKIyBGcmFtZSBidWZmZXIg
aGFyZHdhcmUgZHJpdmVycwojCkNPTkZJR19GQl9DSVJSVVM9eQojIENPTkZJR19GQl9QTTIg
aXMgbm90IHNldAojIENPTkZJR19GQl9DWUJFUjIwMDAgaXMgbm90IHNldApDT05GSUdfRkJf
QVJDPW0KIyBDT05GSUdfRkJfQVNJTElBTlQgaXMgbm90IHNldAojIENPTkZJR19GQl9JTVNU
VCBpcyBub3Qgc2V0CkNPTkZJR19GQl9WR0ExNj15CkNPTkZJR19GQl9VVkVTQT15CkNPTkZJ
R19GQl9WRVNBPXkKQ09ORklHX0ZCX0VGST15CiMgQ09ORklHX0ZCX040MTEgaXMgbm90IHNl
dAojIENPTkZJR19GQl9IR0EgaXMgbm90IHNldAojIENPTkZJR19GQl9PUEVOQ09SRVMgaXMg
bm90IHNldAojIENPTkZJR19GQl9TMUQxM1hYWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX05W
SURJQSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1JJVkEgaXMgbm90IHNldApDT05GSUdfRkJf
STc0MD15CkNPTkZJR19GQl9MRTgwNTc4PXkKQ09ORklHX0ZCX0NBUklMTE9fUkFOQ0g9bQoj
IENPTkZJR19GQl9NQVRST1ggaXMgbm90IHNldAojIENPTkZJR19GQl9SQURFT04gaXMgbm90
IHNldAojIENPTkZJR19GQl9BVFkxMjggaXMgbm90IHNldAojIENPTkZJR19GQl9BVFkgaXMg
bm90IHNldAojIENPTkZJR19GQl9TMyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1NBVkFHRSBp
cyBub3Qgc2V0CiMgQ09ORklHX0ZCX1NJUyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1ZJQSBp
cyBub3Qgc2V0CiMgQ09ORklHX0ZCX05FT01BR0lDIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf
S1lSTyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCXzNERlggaXMgbm90IHNldAojIENPTkZJR19G
Ql9WT09ET08xIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfVlQ4NjIzIGlzIG5vdCBzZXQKIyBD
T05GSUdfRkJfVFJJREVOVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0FSSyBpcyBub3Qgc2V0
CiMgQ09ORklHX0ZCX1BNMyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0NBUk1JTkUgaXMgbm90
IHNldAojIENPTkZJR19GQl9TTTUwMSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1NNU0NVRlgg
aXMgbm90IHNldAojIENPTkZJR19GQl9VREwgaXMgbm90IHNldAojIENPTkZJR19GQl9WSVJU
VUFMIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9GQkRFVl9GUk9OVEVORD15CiMgQ09ORklHX0ZC
X01FVFJPTk9NRSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX01CODYyWFggaXMgbm90IHNldAoj
IENPTkZJR19GQl9CUk9BRFNIRUVUIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVVPX0sxOTBY
IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfSFlQRVJWIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf
U0lNUExFIGlzIG5vdCBzZXQKQ09ORklHX0JBQ0tMSUdIVF9MQ0RfU1VQUE9SVD15CiMgQ09O
RklHX0xDRF9DTEFTU19ERVZJQ0UgaXMgbm90IHNldApDT05GSUdfQkFDS0xJR0hUX0NMQVNT
X0RFVklDRT15CiMgQ09ORklHX0JBQ0tMSUdIVF9HRU5FUklDIGlzIG5vdCBzZXQKIyBDT05G
SUdfQkFDS0xJR0hUX0FQUExFIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX1NBSEFS
QSBpcyBub3Qgc2V0CiMgQ09ORklHX0JBQ0tMSUdIVF9BRFA4ODYwIGlzIG5vdCBzZXQKIyBD
T05GSUdfQkFDS0xJR0hUX0FEUDg4NzAgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRf
UENGNTA2MzMgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfTE0zNjM5IGlzIG5vdCBz
ZXQKIyBDT05GSUdfQkFDS0xJR0hUX0dQSU8gaXMgbm90IHNldAojIENPTkZJR19CQUNLTElH
SFRfTFY1MjA3TFAgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfQkQ2MTA3IGlzIG5v
dCBzZXQKQ09ORklHX1ZHQVNUQVRFPXkKQ09ORklHX0hETUk9eQoKIwojIENvbnNvbGUgZGlz
cGxheSBkcml2ZXIgc3VwcG9ydAojCkNPTkZJR19WR0FfQ09OU09MRT15CiMgQ09ORklHX1ZH
QUNPTl9TT0ZUX1NDUk9MTEJBQ0sgaXMgbm90IHNldApDT05GSUdfRFVNTVlfQ09OU09MRT15
CkNPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFPXkKQ09ORklHX0ZSQU1FQlVGRkVSX0NPTlNP
TEVfREVURUNUX1BSSU1BUlk9eQpDT05GSUdfRlJBTUVCVUZGRVJfQ09OU09MRV9ST1RBVElP
Tj15CiMgQ09ORklHX0xPR08gaXMgbm90IHNldApDT05GSUdfU09VTkQ9eQpDT05GSUdfU09V
TkRfT1NTX0NPUkU9eQpDT05GSUdfU09VTkRfT1NTX0NPUkVfUFJFQ0xBSU09eQpDT05GSUdf
U05EPXkKQ09ORklHX1NORF9USU1FUj15CkNPTkZJR19TTkRfUENNPXkKQ09ORklHX1NORF9I
V0RFUD15CkNPTkZJR19TTkRfUkFXTUlEST15CkNPTkZJR19TTkRfU0VRVUVOQ0VSPXkKIyBD
T05GSUdfU05EX1NFUV9EVU1NWSBpcyBub3Qgc2V0CkNPTkZJR19TTkRfT1NTRU1VTD15CkNP
TkZJR19TTkRfTUlYRVJfT1NTPXkKQ09ORklHX1NORF9QQ01fT1NTPXkKQ09ORklHX1NORF9Q
Q01fT1NTX1BMVUdJTlM9eQpDT05GSUdfU05EX1NFUVVFTkNFUl9PU1M9eQpDT05GSUdfU05E
X0hSVElNRVI9eQpDT05GSUdfU05EX1NFUV9IUlRJTUVSX0RFRkFVTFQ9eQojIENPTkZJR19T
TkRfRFlOQU1JQ19NSU5PUlMgaXMgbm90IHNldApDT05GSUdfU05EX1NVUFBPUlRfT0xEX0FQ
ST15CkNPTkZJR19TTkRfVkVSQk9TRV9QUk9DRlM9eQojIENPTkZJR19TTkRfVkVSQk9TRV9Q
UklOVEsgaXMgbm90IHNldAojIENPTkZJR19TTkRfREVCVUcgaXMgbm90IHNldApDT05GSUdf
U05EX1ZNQVNURVI9eQpDT05GSUdfU05EX0RNQV9TR0JVRj15CkNPTkZJR19TTkRfUkFXTUlE
SV9TRVE9eQojIENPTkZJR19TTkRfT1BMM19MSUJfU0VRIGlzIG5vdCBzZXQKIyBDT05GSUdf
U05EX09QTDRfTElCX1NFUSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TQkFXRV9TRVEgaXMg
bm90IHNldAojIENPTkZJR19TTkRfRU1VMTBLMV9TRVEgaXMgbm90IHNldApDT05GSUdfU05E
X0RSSVZFUlM9eQojIENPTkZJR19TTkRfUENTUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9E
VU1NWSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BTE9PUCBpcyBub3Qgc2V0CiMgQ09ORklH
X1NORF9WSVJNSURJIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01UUEFWIGlzIG5vdCBzZXQK
IyBDT05GSUdfU05EX1NFUklBTF9VMTY1NTAgaXMgbm90IHNldAojIENPTkZJR19TTkRfTVBV
NDAxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1BDSSBpcyBub3Qgc2V0CgojCiMgSEQtQXVk
aW8KIwpDT05GSUdfU05EX1VTQj15CkNPTkZJR19TTkRfVVNCX0FVRElPPXkKQ09ORklHX1NO
RF9VU0JfVUExMDE9eQpDT05GSUdfU05EX1VTQl9VU1gyWT15CkNPTkZJR19TTkRfVVNCX0NB
SUFRPXkKIyBDT05GSUdfU05EX1VTQl9DQUlBUV9JTlBVVCBpcyBub3Qgc2V0CkNPTkZJR19T
TkRfVVNCX1VTMTIyTD15CkNPTkZJR19TTkRfVVNCXzZGSVJFPXkKQ09ORklHX1NORF9VU0Jf
SElGQUNFPXkKIyBDT05GSUdfU05EX0JDRDIwMDAgaXMgbm90IHNldAojIENPTkZJR19TTkRf
U09DIGlzIG5vdCBzZXQKIyBDT05GSUdfU09VTkRfUFJJTUUgaXMgbm90IHNldAoKIwojIEhJ
RCBzdXBwb3J0CiMKQ09ORklHX0hJRD15CiMgQ09ORklHX0hJRF9CQVRURVJZX1NUUkVOR1RI
IGlzIG5vdCBzZXQKQ09ORklHX0hJRFJBVz15CiMgQ09ORklHX1VISUQgaXMgbm90IHNldApD
T05GSUdfSElEX0dFTkVSSUM9eQoKIwojIFNwZWNpYWwgSElEIGRyaXZlcnMKIwpDT05GSUdf
SElEX0E0VEVDSD15CiMgQ09ORklHX0hJRF9BQ1JVWCBpcyBub3Qgc2V0CkNPTkZJR19ISURf
QVBQTEU9eQojIENPTkZJR19ISURfQVBQTEVJUiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9B
VVJFQUwgaXMgbm90IHNldApDT05GSUdfSElEX0JFTEtJTj15CkNPTkZJR19ISURfQ0hFUlJZ
PXkKQ09ORklHX0hJRF9DSElDT05ZPXkKIyBDT05GSUdfSElEX1BST0RJS0VZUyBpcyBub3Qg
c2V0CiMgQ09ORklHX0hJRF9DUDIxMTIgaXMgbm90IHNldApDT05GSUdfSElEX0NZUFJFU1M9
eQojIENPTkZJR19ISURfRFJBR09OUklTRSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9FTVNf
RkYgaXMgbm90IHNldAojIENPTkZJR19ISURfRUxFQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdf
SElEX0VMTyBpcyBub3Qgc2V0CkNPTkZJR19ISURfRVpLRVk9eQojIENPTkZJR19ISURfSE9M
VEVLIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0hVSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdf
SElEX0tFWVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0tZRSBpcyBub3Qgc2V0CiMg
Q09ORklHX0hJRF9VQ0xPR0lDIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1dBTFRPUCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0hJRF9HWVJBVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9J
Q0FERSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9UV0lOSEFOIGlzIG5vdCBzZXQKQ09ORklH
X0hJRF9LRU5TSU5HVE9OPXkKIyBDT05GSUdfSElEX0xDUE9XRVIgaXMgbm90IHNldAojIENP
TkZJR19ISURfTEVOT1ZPX1RQS0JEIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9MT0dJVEVDSD15
CkNPTkZJR19ISURfTE9HSVRFQ0hfREo9eQpDT05GSUdfTE9HSVRFQ0hfRkY9eQpDT05GSUdf
TE9HSVJVTUJMRVBBRDJfRkY9eQpDT05GSUdfTE9HSUc5NDBfRkY9eQpDT05GSUdfTE9HSVdI
RUVMU19GRj15CiMgQ09ORklHX0hJRF9NQUdJQ01PVVNFIGlzIG5vdCBzZXQKQ09ORklHX0hJ
RF9NSUNST1NPRlQ9eQpDT05GSUdfSElEX01PTlRFUkVZPXkKIyBDT05GSUdfSElEX01VTFRJ
VE9VQ0ggaXMgbm90IHNldAojIENPTkZJR19ISURfTlRSSUcgaXMgbm90IHNldAojIENPTkZJ
R19ISURfT1JURUsgaXMgbm90IHNldAojIENPTkZJR19ISURfUEFOVEhFUkxPUkQgaXMgbm90
IHNldAojIENPTkZJR19ISURfUEVUQUxZTlggaXMgbm90IHNldAojIENPTkZJR19ISURfUElD
T0xDRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QUklNQVggaXMgbm90IHNldAojIENPTkZJ
R19ISURfUk9DQ0FUIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NBSVRFSyBpcyBub3Qgc2V0
CiMgQ09ORklHX0hJRF9TQU1TVU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NPTlkgaXMg
bm90IHNldAojIENPTkZJR19ISURfU1BFRURMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE
X1NURUVMU0VSSUVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NVTlBMVVMgaXMgbm90IHNl
dAojIENPTkZJR19ISURfUk1JIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0dSRUVOQVNJQSBp
cyBub3Qgc2V0CiMgQ09ORklHX0hJRF9IWVBFUlZfTU9VU0UgaXMgbm90IHNldAojIENPTkZJ
R19ISURfU01BUlRKT1lQTFVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1RJVk8gaXMgbm90
IHNldAojIENPTkZJR19ISURfVE9QU0VFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9USElO
R00gaXMgbm90IHNldAojIENPTkZJR19ISURfVEhSVVNUTUFTVEVSIGlzIG5vdCBzZXQKIyBD
T05GSUdfSElEX1dBQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1dJSU1PVEUgaXMgbm90
IHNldAojIENPTkZJR19ISURfWElOTU8gaXMgbm90IHNldAojIENPTkZJR19ISURfWkVST1BM
VVMgaXMgbm90IHNldAojIENPTkZJR19ISURfWllEQUNST04gaXMgbm90IHNldApDT05GSUdf
SElEX1NFTlNPUl9IVUI9eQoKIwojIFVTQiBISUQgc3VwcG9ydAojCkNPTkZJR19VU0JfSElE
PXkKQ09ORklHX0hJRF9QSUQ9eQpDT05GSUdfVVNCX0hJRERFVj15CgojCiMgSTJDIEhJRCBz
dXBwb3J0CiMKIyBDT05GSUdfSTJDX0hJRCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfT0hDSV9M
SVRUTEVfRU5ESUFOPXkKQ09ORklHX1VTQl9TVVBQT1JUPXkKQ09ORklHX1VTQl9DT01NT049
eQpDT05GSUdfVVNCX0FSQ0hfSEFTX0hDRD15CkNPTkZJR19VU0I9eQpDT05GSUdfVVNCX0FO
Tk9VTkNFX05FV19ERVZJQ0VTPXkKCiMKIyBNaXNjZWxsYW5lb3VzIFVTQiBvcHRpb25zCiMK
Q09ORklHX1VTQl9ERUZBVUxUX1BFUlNJU1Q9eQpDT05GSUdfVVNCX0RZTkFNSUNfTUlOT1JT
PXkKIyBDT05GSUdfVVNCX09URyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9PVEdfRlNNIGlz
IG5vdCBzZXQKQ09ORklHX1VTQl9NT049eQojIENPTkZJR19VU0JfV1VTQl9DQkFGIGlzIG5v
dCBzZXQKCiMKIyBVU0IgSG9zdCBDb250cm9sbGVyIERyaXZlcnMKIwojIENPTkZJR19VU0Jf
QzY3WDAwX0hDRCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfWEhDSV9IQ0Q9eQpDT05GSUdfVVNC
X0VIQ0lfSENEPXkKQ09ORklHX1VTQl9FSENJX1JPT1RfSFVCX1RUPXkKQ09ORklHX1VTQl9F
SENJX1RUX05FV1NDSEVEPXkKQ09ORklHX1VTQl9FSENJX1BDST15CiMgQ09ORklHX1VTQl9F
SENJX0hDRF9QTEFURk9STSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9PWFUyMTBIUF9IQ0Qg
aXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTE2WF9IQ0QgaXMgbm90IHNldAojIENPTkZJ
R19VU0JfSVNQMTc2MF9IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTM2Ml9IQ0Qg
aXMgbm90IHNldAojIENPTkZJR19VU0JfRlVTQkgyMDBfSENEIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX0ZPVEcyMTBfSENEIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9PSENJX0hDRD15CkNP
TkZJR19VU0JfT0hDSV9IQ0RfUENJPXkKQ09ORklHX1VTQl9PSENJX0hDRF9QTEFURk9STT15
CkNPTkZJR19VU0JfVUhDSV9IQ0Q9eQojIENPTkZJR19VU0JfU0w4MTFfSENEIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX1I4QTY2NTk3X0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9I
Q0RfVEVTVF9NT0RFIGlzIG5vdCBzZXQKCiMKIyBVU0IgRGV2aWNlIENsYXNzIGRyaXZlcnMK
IwojIENPTkZJR19VU0JfQUNNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1BSSU5URVIgaXMg
bm90IHNldAojIENPTkZJR19VU0JfV0RNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1RNQyBp
cyBub3Qgc2V0CgojCiMgTk9URTogVVNCX1NUT1JBR0UgZGVwZW5kcyBvbiBTQ1NJIGJ1dCBC
TEtfREVWX1NEIG1heQojCgojCiMgYWxzbyBiZSBuZWVkZWQ7IHNlZSBVU0JfU1RPUkFHRSBI
ZWxwIGZvciBtb3JlIGluZm8KIwpDT05GSUdfVVNCX1NUT1JBR0U9eQojIENPTkZJR19VU0Jf
U1RPUkFHRV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1JFQUxURUsg
aXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9EQVRBRkFCIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX1NUT1JBR0VfRlJFRUNPTSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9S
QUdFX0lTRDIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1VTQkFUIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfU0REUjA5IGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX1NUT1JBR0VfU0REUjU1IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfSlVN
UFNIT1QgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9BTEFVREEgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfU1RPUkFHRV9PTkVUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9TVE9SQUdFX0tBUk1BIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfQ1lQUkVT
U19BVEFDQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0VORV9VQjYyNTAgaXMg
bm90IHNldAojIENPTkZJR19VU0JfVUFTIGlzIG5vdCBzZXQKCiMKIyBVU0IgSW1hZ2luZyBk
ZXZpY2VzCiMKIyBDT05GSUdfVVNCX01EQzgwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9N
SUNST1RFSyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NVVNCX0hEUkMgaXMgbm90IHNldAoj
IENPTkZJR19VU0JfRFdDMyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9EV0MyIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX0NISVBJREVBIGlzIG5vdCBzZXQKCiMKIyBVU0IgcG9ydCBkcml2
ZXJzCiMKIyBDT05GSUdfVVNCX1NFUklBTCBpcyBub3Qgc2V0CgojCiMgVVNCIE1pc2NlbGxh
bmVvdXMgZHJpdmVycwojCiMgQ09ORklHX1VTQl9FTUk2MiBpcyBub3Qgc2V0CiMgQ09ORklH
X1VTQl9FTUkyNiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9BRFVUVVggaXMgbm90IHNldAoj
IENPTkZJR19VU0JfU0VWU0VHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9MRUdPVE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
TENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0xFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9DWVBSRVNTX0NZN0M2MyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVRIRVJNIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX0lETU9VU0UgaXMgbm90IHNldAojIENPTkZJR19VU0JfRlRE
SV9FTEFOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0FQUExFRElTUExBWSBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9TSVNVU0JWR0EgaXMgbm90IHNldAojIENPTkZJR19VU0JfTEQgaXMg
bm90IHNldAojIENPTkZJR19VU0JfVFJBTkNFVklCUkFUT1IgaXMgbm90IHNldAojIENPTkZJ
R19VU0JfSU9XQVJSSU9SIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1RFU1QgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfRUhTRVRfVEVTVF9GSVhUVVJFIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX0lTSUdIVEZXIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1lVUkVYIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX0VaVVNCX0ZYMiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9IU0lDX1VT
QjM1MDMgaXMgbm90IHNldAoKIwojIFVTQiBQaHlzaWNhbCBMYXllciBkcml2ZXJzCiMKIyBD
T05GSUdfVVNCX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX05PUF9VU0JfWENFSVYgaXMgbm90
IHNldAojIENPTkZJR19TQU1TVU5HX1VTQjJQSFkgaXMgbm90IHNldAojIENPTkZJR19TQU1T
VU5HX1VTQjNQSFkgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1BJT19WQlVTIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX0lTUDEzMDEgaXMgbm90IHNldAojIENPTkZJR19VU0JfR0FER0VU
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVdCIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DIGlzIG5v
dCBzZXQKIyBDT05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldApDT05GSUdfTkVXX0xFRFM9eQpD
T05GSUdfTEVEU19DTEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURTX0xN
MzUzMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNjQyIGlzIG5vdCBzZXQKQ09ORklH
X0xFRFNfUENBOTUzMj15CiMgQ09ORklHX0xFRFNfUENBOTUzMl9HUElPIGlzIG5vdCBzZXQK
IyBDT05GSUdfTEVEU19HUElPIGlzIG5vdCBzZXQKQ09ORklHX0xFRFNfTFAzOTQ0PXkKIyBD
T05GSUdfTEVEU19MUDU1MjEgaXMgbm90IHNldAojIENPTkZJR19MRURTX0xQNTUyMyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0xFRFNfTFA1NTYyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19M
UDg1MDEgaXMgbm90IHNldApDT05GSUdfTEVEU19DTEVWT19NQUlMPXkKQ09ORklHX0xFRFNf
UENBOTU1WD15CiMgQ09ORklHX0xFRFNfUENBOTYzWCBpcyBub3Qgc2V0CkNPTkZJR19MRURT
X0JEMjgwMj15CkNPTkZJR19MRURTX0lOVEVMX1NTNDIwMD15CkNPTkZJR19MRURTX0xUMzU5
Mz15CiMgQ09ORklHX0xFRFNfREVMTF9ORVRCT09LUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xF
RFNfVENBNjUwNyBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNTV4IGlzIG5vdCBzZXQK
CiMKIyBMRUQgZHJpdmVyIGZvciBibGluaygxKSBVU0IgUkdCIExFRCBpcyB1bmRlciBTcGVj
aWFsIEhJRCBkcml2ZXJzIChISURfVEhJTkdNKQojCiMgQ09ORklHX0xFRFNfQkxJTktNIGlz
IG5vdCBzZXQKCiMKIyBMRUQgVHJpZ2dlcnMKIwpDT05GSUdfTEVEU19UUklHR0VSUz15CkNP
TkZJR19MRURTX1RSSUdHRVJfVElNRVI9eQojIENPTkZJR19MRURTX1RSSUdHRVJfT05FU0hP
VCBpcyBub3Qgc2V0CkNPTkZJR19MRURTX1RSSUdHRVJfSEVBUlRCRUFUPXkKQ09ORklHX0xF
RFNfVFJJR0dFUl9CQUNLTElHSFQ9eQojIENPTkZJR19MRURTX1RSSUdHRVJfQ1BVIGlzIG5v
dCBzZXQKIyBDT05GSUdfTEVEU19UUklHR0VSX0dQSU8gaXMgbm90IHNldApDT05GSUdfTEVE
U19UUklHR0VSX0RFRkFVTFRfT049eQoKIwojIGlwdGFibGVzIHRyaWdnZXIgaXMgdW5kZXIg
TmV0ZmlsdGVyIGNvbmZpZyAoTEVEIHRhcmdldCkKIwojIENPTkZJR19MRURTX1RSSUdHRVJf
VFJBTlNJRU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19UUklHR0VSX0NBTUVSQSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0FDQ0VTU0lCSUxJVFkgaXMgbm90IHNldAojIENPTkZJR19JTkZJ
TklCQU5EIGlzIG5vdCBzZXQKIyBDT05GSUdfRURBQyBpcyBub3Qgc2V0CkNPTkZJR19SVENf
TElCPXkKQ09ORklHX1JUQ19DTEFTUz15CkNPTkZJR19SVENfSENUT1NZUz15CkNPTkZJR19S
VENfU1lTVE9IQz15CkNPTkZJR19SVENfSENUT1NZU19ERVZJQ0U9InJ0YzAiCiMgQ09ORklH
X1JUQ19ERUJVRyBpcyBub3Qgc2V0CgojCiMgUlRDIGludGVyZmFjZXMKIwpDT05GSUdfUlRD
X0lOVEZfU1lTRlM9eQpDT05GSUdfUlRDX0lOVEZfUFJPQz15CkNPTkZJR19SVENfSU5URl9E
RVY9eQojIENPTkZJR19SVENfSU5URl9ERVZfVUlFX0VNVUwgaXMgbm90IHNldAojIENPTkZJ
R19SVENfRFJWX1RFU1QgaXMgbm90IHNldAoKIwojIEkyQyBSVEMgZHJpdmVycwojCkNPTkZJ
R19SVENfRFJWX0RTMTMwNz15CkNPTkZJR19SVENfRFJWX0RTMTM3ND15CkNPTkZJR19SVENf
RFJWX0RTMTY3Mj15CiMgQ09ORklHX1JUQ19EUlZfRFMzMjMyIGlzIG5vdCBzZXQKQ09ORklH
X1JUQ19EUlZfTUFYNjkwMD15CkNPTkZJR19SVENfRFJWX1JTNUMzNzI9eQpDT05GSUdfUlRD
X0RSVl9JU0wxMjA4PXkKIyBDT05GSUdfUlRDX0RSVl9JU0wxMjAyMiBpcyBub3Qgc2V0CiMg
Q09ORklHX1JUQ19EUlZfSVNMMTIwNTcgaXMgbm90IHNldApDT05GSUdfUlRDX0RSVl9YMTIw
NT15CiMgQ09ORklHX1JUQ19EUlZfUENGMjEyNyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19E
UlZfUENGODUyMyBpcyBub3Qgc2V0CkNPTkZJR19SVENfRFJWX1BDRjg1NjM9eQpDT05GSUdf
UlRDX0RSVl9QQ0Y4NTgzPXkKQ09ORklHX1JUQ19EUlZfTTQxVDgwPXkKIyBDT05GSUdfUlRD
X0RSVl9NNDFUODBfV0RUIGlzIG5vdCBzZXQKQ09ORklHX1JUQ19EUlZfQlEzMks9eQpDT05G
SUdfUlRDX0RSVl9TMzUzOTBBPXkKQ09ORklHX1JUQ19EUlZfRk0zMTMwPXkKQ09ORklHX1JU
Q19EUlZfUlg4NTgxPXkKQ09ORklHX1JUQ19EUlZfUlg4MDI1PXkKIyBDT05GSUdfUlRDX0RS
Vl9FTTMwMjcgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1JWMzAyOUMyIGlzIG5vdCBz
ZXQKCiMKIyBTUEkgUlRDIGRyaXZlcnMKIwoKIwojIFBsYXRmb3JtIFJUQyBkcml2ZXJzCiMK
Q09ORklHX1JUQ19EUlZfQ01PUz15CkNPTkZJR19SVENfRFJWX0RTMTI4Nj15CkNPTkZJR19S
VENfRFJWX0RTMTUxMT15CkNPTkZJR19SVENfRFJWX0RTMTU1Mz15CkNPTkZJR19SVENfRFJW
X0RTMTc0Mj15CkNPTkZJR19SVENfRFJWX1NUSzE3VEE4PXkKQ09ORklHX1JUQ19EUlZfTTQ4
VDg2PXkKQ09ORklHX1JUQ19EUlZfTTQ4VDM1PXkKQ09ORklHX1JUQ19EUlZfTTQ4VDU5PXkK
Q09ORklHX1JUQ19EUlZfTVNNNjI0Mj15CkNPTkZJR19SVENfRFJWX0JRNDgwMj15CkNPTkZJ
R19SVENfRFJWX1JQNUMwMT15CkNPTkZJR19SVENfRFJWX1YzMDIwPXkKQ09ORklHX1JUQ19E
UlZfRFMyNDA0PXkKIyBDT05GSUdfUlRDX0RSVl9QQ0Y1MDYzMyBpcyBub3Qgc2V0CgojCiMg
b24tQ1BVIFJUQyBkcml2ZXJzCiMKIyBDT05GSUdfUlRDX0RSVl9NT1hBUlQgaXMgbm90IHNl
dAojIENPTkZJR19SVENfRFJWX1hHRU5FIGlzIG5vdCBzZXQKCiMKIyBISUQgU2Vuc29yIFJU
QyBkcml2ZXJzCiMKQ09ORklHX1JUQ19EUlZfSElEX1NFTlNPUl9USU1FPXkKQ09ORklHX0RN
QURFVklDRVM9eQojIENPTkZJR19ETUFERVZJQ0VTX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBE
TUEgRGV2aWNlcwojCiMgQ09ORklHX0lOVEVMX01JRF9ETUFDIGlzIG5vdCBzZXQKQ09ORklH
X0lOVEVMX0lPQVRETUE9eQojIENPTkZJR19EV19ETUFDX0NPUkUgaXMgbm90IHNldAojIENP
TkZJR19EV19ETUFDIGlzIG5vdCBzZXQKIyBDT05GSUdfRFdfRE1BQ19QQ0kgaXMgbm90IHNl
dApDT05GSUdfRE1BX0VOR0lORT15CkNPTkZJR19ETUFfQUNQST15CgojCiMgRE1BIENsaWVu
dHMKIwpDT05GSUdfQVNZTkNfVFhfRE1BPXkKIyBDT05GSUdfRE1BVEVTVCBpcyBub3Qgc2V0
CkNPTkZJR19ETUFfRU5HSU5FX1JBSUQ9eQpDT05GSUdfRENBPXkKIyBDT05GSUdfQVVYRElT
UExBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1VJTyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZGSU8g
aXMgbm90IHNldAojIENPTkZJR19WSVJUX0RSSVZFUlMgaXMgbm90IHNldApDT05GSUdfVklS
VElPPXkKCiMKIyBWaXJ0aW8gZHJpdmVycwojCkNPTkZJR19WSVJUSU9fUENJPXkKQ09ORklH
X1ZJUlRJT19CQUxMT09OPXkKIyBDT05GSUdfVklSVElPX01NSU8gaXMgbm90IHNldAoKIwoj
IE1pY3Jvc29mdCBIeXBlci1WIGd1ZXN0IHN1cHBvcnQKIwpDT05GSUdfSFlQRVJWPXkKQ09O
RklHX0hZUEVSVl9VVElMUz15CiMgQ09ORklHX0hZUEVSVl9CQUxMT09OIGlzIG5vdCBzZXQK
CiMKIyBYZW4gZHJpdmVyIHN1cHBvcnQKIwpDT05GSUdfWEVOX0JBTExPT049eQpDT05GSUdf
WEVOX1NDUlVCX1BBR0VTPXkKQ09ORklHX1hFTl9ERVZfRVZUQ0hOPXkKQ09ORklHX1hFTl9C
QUNLRU5EPXkKQ09ORklHX1hFTkZTPXkKQ09ORklHX1hFTl9DT01QQVRfWEVORlM9eQpDT05G
SUdfWEVOX1NZU19IWVBFUlZJU09SPXkKQ09ORklHX1hFTl9YRU5CVVNfRlJPTlRFTkQ9eQpD
T05GSUdfWEVOX0dOVERFVj15CkNPTkZJR19YRU5fR1JBTlRfREVWX0FMTE9DPXkKQ09ORklH
X1NXSU9UTEJfWEVOPXkKQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VORD15CkNPTkZJR19YRU5f
UFJJVkNNRD15CkNPTkZJR19YRU5fQUNQSV9QUk9DRVNTT1I9eQojIENPTkZJR19YRU5fTUNF
X0xPRyBpcyBub3Qgc2V0CkNPTkZJR19YRU5fSEFWRV9QVk1NVT15CiMgQ09ORklHX1NUQUdJ
TkcgaXMgbm90IHNldApDT05GSUdfWDg2X1BMQVRGT1JNX0RFVklDRVM9eQojIENPTkZJR19B
Q0VSX1dNSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FDRVJIREYgaXMgbm90IHNldAojIENPTkZJ
R19BTElFTldBUkVfV01JIGlzIG5vdCBzZXQKIyBDT05GSUdfQVNVU19MQVBUT1AgaXMgbm90
IHNldAojIENPTkZJR19ERUxMX1dNSSBpcyBub3Qgc2V0CiMgQ09ORklHX0RFTExfV01JX0FJ
TyBpcyBub3Qgc2V0CiMgQ09ORklHX0RFTExfU01PODgwMCBpcyBub3Qgc2V0CiMgQ09ORklH
X0ZVSklUU1VfTEFQVE9QIGlzIG5vdCBzZXQKIyBDT05GSUdfRlVKSVRTVV9UQUJMRVQgaXMg
bm90IHNldAojIENPTkZJR19BTUlMT19SRktJTEwgaXMgbm90IHNldAojIENPTkZJR19IUF9B
Q0NFTCBpcyBub3Qgc2V0CiMgQ09ORklHX0hQX1dJUkVMRVNTIGlzIG5vdCBzZXQKIyBDT05G
SUdfSFBfV01JIGlzIG5vdCBzZXQKIyBDT05GSUdfTVNJX0xBUFRPUCBpcyBub3Qgc2V0CiMg
Q09ORklHX1BBTkFTT05JQ19MQVBUT1AgaXMgbm90IHNldAojIENPTkZJR19DT01QQUxfTEFQ
VE9QIGlzIG5vdCBzZXQKIyBDT05GSUdfU09OWV9MQVBUT1AgaXMgbm90IHNldAojIENPTkZJ
R19JREVBUEFEX0xBUFRPUCBpcyBub3Qgc2V0CiMgQ09ORklHX1RISU5LUEFEX0FDUEkgaXMg
bm90IHNldAojIENPTkZJR19TRU5TT1JTX0hEQVBTIGlzIG5vdCBzZXQKQ09ORklHX0lOVEVM
X01FTkxPVz15CiMgQ09ORklHX0VFRVBDX0xBUFRPUCBpcyBub3Qgc2V0CiMgQ09ORklHX0FT
VVNfV01JIGlzIG5vdCBzZXQKQ09ORklHX0FDUElfV01JPXkKIyBDT05GSUdfTVNJX1dNSSBp
cyBub3Qgc2V0CiMgQ09ORklHX1RPUFNUQVJfTEFQVE9QIGlzIG5vdCBzZXQKIyBDT05GSUdf
QUNQSV9UT1NISUJBIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9TSElCQV9CVF9SRktJTEwgaXMg
bm90IHNldAojIENPTkZJR19BQ1BJX0NNUEMgaXMgbm90IHNldAojIENPTkZJR19JTlRFTF9J
UFMgaXMgbm90IHNldAojIENPTkZJR19JQk1fUlRMIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FN
U1VOR19MQVBUT1AgaXMgbm90IHNldApDT05GSUdfTVhNX1dNST15CiMgQ09ORklHX0lOVEVM
X09BS1RSQUlMIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FNU1VOR19RMTAgaXMgbm90IHNldAoj
IENPTkZJR19BUFBMRV9HTVVYIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5URUxfUlNUIGlzIG5v
dCBzZXQKIyBDT05GSUdfSU5URUxfU01BUlRDT05ORUNUIGlzIG5vdCBzZXQKIyBDT05GSUdf
UFZQQU5JQyBpcyBub3Qgc2V0CiMgQ09ORklHX0NIUk9NRV9QTEFURk9STVMgaXMgbm90IHNl
dAoKIwojIFNPQyAoU3lzdGVtIE9uIENoaXApIHNwZWNpZmljIERyaXZlcnMKIwoKIwojIEhh
cmR3YXJlIFNwaW5sb2NrIGRyaXZlcnMKIwpDT05GSUdfQ0xLRVZUX0k4MjUzPXkKQ09ORklH
X0k4MjUzX0xPQ0s9eQpDT05GSUdfQ0xLQkxEX0k4MjUzPXkKIyBDT05GSUdfU0hfVElNRVJf
Q01UIGlzIG5vdCBzZXQKIyBDT05GSUdfU0hfVElNRVJfTVRVMiBpcyBub3Qgc2V0CiMgQ09O
RklHX1NIX1RJTUVSX1RNVSBpcyBub3Qgc2V0CiMgQ09ORklHX0VNX1RJTUVSX1NUSSBpcyBu
b3Qgc2V0CiMgQ09ORklHX01BSUxCT1ggaXMgbm90IHNldApDT05GSUdfSU9NTVVfQVBJPXkK
Q09ORklHX0lPTU1VX1NVUFBPUlQ9eQpDT05GSUdfQU1EX0lPTU1VPXkKIyBDT05GSUdfQU1E
X0lPTU1VX1NUQVRTIGlzIG5vdCBzZXQKQ09ORklHX0RNQVJfVEFCTEU9eQpDT05GSUdfSU5U
RUxfSU9NTVU9eQojIENPTkZJR19JTlRFTF9JT01NVV9ERUZBVUxUX09OIGlzIG5vdCBzZXQK
Q09ORklHX0lOVEVMX0lPTU1VX0ZMT1BQWV9XQT15CkNPTkZJR19JUlFfUkVNQVA9eQoKIwoj
IFJlbW90ZXByb2MgZHJpdmVycwojCiMgQ09ORklHX1NURV9NT0RFTV9SUFJPQyBpcyBub3Qg
c2V0CgojCiMgUnBtc2cgZHJpdmVycwojCiMgQ09ORklHX1BNX0RFVkZSRVEgaXMgbm90IHNl
dAojIENPTkZJR19FWFRDT04gaXMgbm90IHNldAojIENPTkZJR19NRU1PUlkgaXMgbm90IHNl
dApDT05GSUdfSUlPPXkKIyBDT05GSUdfSUlPX0JVRkZFUiBpcyBub3Qgc2V0CiMgQ09ORklH
X0lJT19UUklHR0VSIGlzIG5vdCBzZXQKCiMKIyBBY2NlbGVyb21ldGVycwojCiMgQ09ORklH
X0JNQTE4MCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TRU5TT1JfQUNDRUxfM0QgaXMgbm90
IHNldAojIENPTkZJR19JSU9fU1RfQUNDRUxfM0FYSVMgaXMgbm90IHNldAojIENPTkZJR19N
TUE4NDUyIGlzIG5vdCBzZXQKCiMKIyBBbmFsb2cgdG8gZGlnaXRhbCBjb252ZXJ0ZXJzCiMK
IyBDT05GSUdfQUQ3OTlYIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFYMTM2MyBpcyBub3Qgc2V0
CiMgQ09ORklHX01DUDM0MjIgaXMgbm90IHNldAojIENPTkZJR19OQVU3ODAyIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVElfQURDMDgxQyBpcyBub3Qgc2V0CgojCiMgQW1wbGlmaWVycwojCgoj
CiMgSGlkIFNlbnNvciBJSU8gQ29tbW9uCiMKQ09ORklHX0hJRF9TRU5TT1JfSUlPX0NPTU1P
Tj15CiMgQ09ORklHX0hJRF9TRU5TT1JfSUlPX1RSSUdHRVIgaXMgbm90IHNldAoKIwojIERp
Z2l0YWwgdG8gYW5hbG9nIGNvbnZlcnRlcnMKIwojIENPTkZJR19BRDUwNjQgaXMgbm90IHNl
dAojIENPTkZJR19BRDUzODAgaXMgbm90IHNldAojIENPTkZJR19BRDU0NDYgaXMgbm90IHNl
dAojIENPTkZJR19NQVg1MTcgaXMgbm90IHNldAojIENPTkZJR19NQ1A0NzI1IGlzIG5vdCBz
ZXQKCiMKIyBGcmVxdWVuY3kgU3ludGhlc2l6ZXJzIEREUy9QTEwKIwoKIwojIENsb2NrIEdl
bmVyYXRvci9EaXN0cmlidXRpb24KIwoKIwojIFBoYXNlLUxvY2tlZCBMb29wIChQTEwpIGZy
ZXF1ZW5jeSBzeW50aGVzaXplcnMKIwoKIwojIERpZ2l0YWwgZ3lyb3Njb3BlIHNlbnNvcnMK
IwojIENPTkZJR19ISURfU0VOU09SX0dZUk9fM0QgaXMgbm90IHNldAojIENPTkZJR19JSU9f
U1RfR1lST18zQVhJUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lURzMyMDAgaXMgbm90IHNldAoK
IwojIEh1bWlkaXR5IHNlbnNvcnMKIwojIENPTkZJR19ESFQxMSBpcyBub3Qgc2V0CiMgQ09O
RklHX1NJNzAwNSBpcyBub3Qgc2V0CgojCiMgSW5lcnRpYWwgbWVhc3VyZW1lbnQgdW5pdHMK
IwojIENPTkZJR19JTlZfTVBVNjA1MF9JSU8gaXMgbm90IHNldAoKIwojIExpZ2h0IHNlbnNv
cnMKIwojIENPTkZJR19BREpEX1MzMTEgaXMgbm90IHNldAojIENPTkZJR19BUERTOTMwMCBp
cyBub3Qgc2V0CiMgQ09ORklHX0NNMzIxODEgaXMgbm90IHNldAojIENPTkZJR19DTTM2NjUx
IGlzIG5vdCBzZXQKIyBDT05GSUdfR1AyQVAwMjBBMDBGIGlzIG5vdCBzZXQKIyBDT05GSUdf
SElEX1NFTlNPUl9BTFMgaXMgbm90IHNldAojIENPTkZJR19ISURfU0VOU09SX1BST1ggaXMg
bm90IHNldAojIENPTkZJR19MVFI1MDEgaXMgbm90IHNldAojIENPTkZJR19UQ1MzNDcyIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19UU0wyNTYzIGlzIG5vdCBzZXQKIyBDT05GSUdf
VFNMNDUzMSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZDTkw0MDAwIGlzIG5vdCBzZXQKCiMKIyBN
YWduZXRvbWV0ZXIgc2Vuc29ycwojCiMgQ09ORklHX0FLODk3NSBpcyBub3Qgc2V0CiMgQ09O
RklHX01BRzMxMTAgaXMgbm90IHNldAojIENPTkZJR19ISURfU0VOU09SX01BR05FVE9NRVRF
Ul8zRCBpcyBub3Qgc2V0CiMgQ09ORklHX0lJT19TVF9NQUdOXzNBWElTIGlzIG5vdCBzZXQK
CiMKIyBJbmNsaW5vbWV0ZXIgc2Vuc29ycwojCiMgQ09ORklHX0hJRF9TRU5TT1JfSU5DTElO
T01FVEVSXzNEIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NFTlNPUl9ERVZJQ0VfUk9UQVRJ
T04gaXMgbm90IHNldAoKIwojIFByZXNzdXJlIHNlbnNvcnMKIwojIENPTkZJR19ISURfU0VO
U09SX1BSRVNTIGlzIG5vdCBzZXQKIyBDT05GSUdfTVBMMTE1IGlzIG5vdCBzZXQKIyBDT05G
SUdfTVBMMzExNSBpcyBub3Qgc2V0CiMgQ09ORklHX0lJT19TVF9QUkVTUyBpcyBub3Qgc2V0
CgojCiMgTGlnaHRuaW5nIHNlbnNvcnMKIwoKIwojIFRlbXBlcmF0dXJlIHNlbnNvcnMKIwoj
IENPTkZJR19NTFg5MDYxNCBpcyBub3Qgc2V0CiMgQ09ORklHX1RNUDAwNiBpcyBub3Qgc2V0
CiMgQ09ORklHX05UQiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZNRV9CVVMgaXMgbm90IHNldAoj
IENPTkZJR19QV00gaXMgbm90IHNldAojIENPTkZJR19JUEFDS19CVVMgaXMgbm90IHNldAoj
IENPTkZJR19SRVNFVF9DT05UUk9MTEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfRk1DIGlzIG5v
dCBzZXQKCiMKIyBQSFkgU3Vic3lzdGVtCiMKIyBDT05GSUdfR0VORVJJQ19QSFkgaXMgbm90
IHNldAojIENPTkZJR19CQ01fS09OQV9VU0IyX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX1BI
WV9TQU1TVU5HX1VTQjIgaXMgbm90IHNldAojIENPTkZJR19QT1dFUkNBUCBpcyBub3Qgc2V0
CiMgQ09ORklHX01DQiBpcyBub3Qgc2V0CgojCiMgRmlybXdhcmUgRHJpdmVycwojCiMgQ09O
RklHX0VERCBpcyBub3Qgc2V0CkNPTkZJR19GSVJNV0FSRV9NRU1NQVA9eQojIENPTkZJR19E
RUxMX1JCVSBpcyBub3Qgc2V0CiMgQ09ORklHX0RDREJBUyBpcyBub3Qgc2V0CiMgQ09ORklH
X0RNSUlEIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1JX1NZU0ZTIGlzIG5vdCBzZXQKQ09ORklH
X0RNSV9TQ0FOX01BQ0hJTkVfTk9OX0VGSV9GQUxMQkFDSz15CiMgQ09ORklHX0lTQ1NJX0lC
RlRfRklORCBpcyBub3Qgc2V0CiMgQ09ORklHX0dPT0dMRV9GSVJNV0FSRSBpcyBub3Qgc2V0
CgojCiMgRUZJIChFeHRlbnNpYmxlIEZpcm13YXJlIEludGVyZmFjZSkgU3VwcG9ydAojCiMg
Q09ORklHX0VGSV9WQVJTIGlzIG5vdCBzZXQKQ09ORklHX0VGSV9SVU5USU1FX01BUD15Cgoj
CiMgRmlsZSBzeXN0ZW1zCiMKQ09ORklHX0RDQUNIRV9XT1JEX0FDQ0VTUz15CkNPTkZJR19F
WFQyX0ZTPXkKQ09ORklHX0VYVDJfRlNfWEFUVFI9eQpDT05GSUdfRVhUMl9GU19QT1NJWF9B
Q0w9eQpDT05GSUdfRVhUMl9GU19TRUNVUklUWT15CiMgQ09ORklHX0VYVDJfRlNfWElQIGlz
IG5vdCBzZXQKQ09ORklHX0VYVDNfRlM9eQpDT05GSUdfRVhUM19ERUZBVUxUU19UT19PUkRF
UkVEPXkKQ09ORklHX0VYVDNfRlNfWEFUVFI9eQpDT05GSUdfRVhUM19GU19QT1NJWF9BQ0w9
eQpDT05GSUdfRVhUM19GU19TRUNVUklUWT15CkNPTkZJR19FWFQ0X0ZTPXkKQ09ORklHX0VY
VDRfRlNfUE9TSVhfQUNMPXkKQ09ORklHX0VYVDRfRlNfU0VDVVJJVFk9eQojIENPTkZJR19F
WFQ0X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0pCRD15CkNPTkZJR19KQkQyPXkKIyBDT05G
SUdfSkJEMl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19GU19NQkNBQ0hFPXkKIyBDT05GSUdf
UkVJU0VSRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19KRlNfRlMgaXMgbm90IHNldAojIENP
TkZJR19YRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19HRlMyX0ZTIGlzIG5vdCBzZXQKQ09O
RklHX0JUUkZTX0ZTPXkKQ09ORklHX0JUUkZTX0ZTX1BPU0lYX0FDTD15CiMgQ09ORklHX0JU
UkZTX0ZTX0NIRUNLX0lOVEVHUklUWSBpcyBub3Qgc2V0CiMgQ09ORklHX0JUUkZTX0ZTX1JV
Tl9TQU5JVFlfVEVTVFMgaXMgbm90IHNldAojIENPTkZJR19CVFJGU19ERUJVRyBpcyBub3Qg
c2V0CiMgQ09ORklHX0JUUkZTX0FTU0VSVCBpcyBub3Qgc2V0CiMgQ09ORklHX05JTEZTMl9G
UyBpcyBub3Qgc2V0CkNPTkZJR19GU19QT1NJWF9BQ0w9eQpDT05GSUdfRVhQT1JURlM9eQpD
T05GSUdfRklMRV9MT0NLSU5HPXkKQ09ORklHX0ZTTk9USUZZPXkKQ09ORklHX0ROT1RJRlk9
eQpDT05GSUdfSU5PVElGWV9VU0VSPXkKQ09ORklHX0ZBTk9USUZZPXkKIyBDT05GSUdfRkFO
T1RJRllfQUNDRVNTX1BFUk1JU1NJT05TIGlzIG5vdCBzZXQKQ09ORklHX1FVT1RBPXkKQ09O
RklHX1FVT1RBX05FVExJTktfSU5URVJGQUNFPXkKQ09ORklHX1BSSU5UX1FVT1RBX1dBUk5J
Tkc9eQojIENPTkZJR19RVU9UQV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1FGTVRfVjEg
aXMgbm90IHNldAojIENPTkZJR19RRk1UX1YyIGlzIG5vdCBzZXQKQ09ORklHX1FVT1RBQ1RM
PXkKQ09ORklHX0FVVE9GUzRfRlM9eQpDT05GSUdfRlVTRV9GUz15CiMgQ09ORklHX0NVU0Ug
aXMgbm90IHNldAoKIwojIENhY2hlcwojCkNPTkZJR19GU0NBQ0hFPXkKQ09ORklHX0ZTQ0FD
SEVfU1RBVFM9eQojIENPTkZJR19GU0NBQ0hFX0hJU1RPR1JBTSBpcyBub3Qgc2V0CiMgQ09O
RklHX0ZTQ0FDSEVfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19GU0NBQ0hFX09CSkVDVF9M
SVNUIGlzIG5vdCBzZXQKQ09ORklHX0NBQ0hFRklMRVM9eQojIENPTkZJR19DQUNIRUZJTEVT
X0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FDSEVGSUxFU19ISVNUT0dSQU0gaXMgbm90
IHNldAoKIwojIENELVJPTS9EVkQgRmlsZXN5c3RlbXMKIwojIENPTkZJR19JU085NjYwX0ZT
IGlzIG5vdCBzZXQKIyBDT05GSUdfVURGX0ZTIGlzIG5vdCBzZXQKCiMKIyBET1MvRkFUL05U
IEZpbGVzeXN0ZW1zCiMKQ09ORklHX0ZBVF9GUz15CkNPTkZJR19NU0RPU19GUz15CkNPTkZJ
R19WRkFUX0ZTPXkKQ09ORklHX0ZBVF9ERUZBVUxUX0NPREVQQUdFPTQzNwpDT05GSUdfRkFU
X0RFRkFVTFRfSU9DSEFSU0VUPSJ1dGY4IgpDT05GSUdfTlRGU19GUz15CiMgQ09ORklHX05U
RlNfREVCVUcgaXMgbm90IHNldApDT05GSUdfTlRGU19SVz15CgojCiMgUHNldWRvIGZpbGVz
eXN0ZW1zCiMKQ09ORklHX1BST0NfRlM9eQpDT05GSUdfUFJPQ19LQ09SRT15CkNPTkZJR19Q
Uk9DX1ZNQ09SRT15CkNPTkZJR19QUk9DX1NZU0NUTD15CkNPTkZJR19QUk9DX1BBR0VfTU9O
SVRPUj15CkNPTkZJR19LRVJORlM9eQpDT05GSUdfU1lTRlM9eQpDT05GSUdfVE1QRlM9eQpD
T05GSUdfVE1QRlNfUE9TSVhfQUNMPXkKQ09ORklHX1RNUEZTX1hBVFRSPXkKQ09ORklHX0hV
R0VUTEJGUz15CkNPTkZJR19IVUdFVExCX1BBR0U9eQojIENPTkZJR19DT05GSUdGU19GUyBp
cyBub3Qgc2V0CkNPTkZJR19NSVNDX0ZJTEVTWVNURU1TPXkKIyBDT05GSUdfQURGU19GUyBp
cyBub3Qgc2V0CiMgQ09ORklHX0FGRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19FQ1JZUFRf
RlMgaXMgbm90IHNldAojIENPTkZJR19IRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19IRlNQ
TFVTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQkVGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklH
X0JGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0VGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklH
X0xPR0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JBTUZTIGlzIG5vdCBzZXQKQ09ORklHX1NR
VUFTSEZTPXkKQ09ORklHX1NRVUFTSEZTX0ZJTEVfQ0FDSEU9eQojIENPTkZJR19TUVVBU0hG
U19GSUxFX0RJUkVDVCBpcyBub3Qgc2V0CkNPTkZJR19TUVVBU0hGU19ERUNPTVBfU0lOR0xF
PXkKIyBDT05GSUdfU1FVQVNIRlNfREVDT01QX01VTFRJIGlzIG5vdCBzZXQKIyBDT05GSUdf
U1FVQVNIRlNfREVDT01QX01VTFRJX1BFUkNQVSBpcyBub3Qgc2V0CiMgQ09ORklHX1NRVUFT
SEZTX1hBVFRSIGlzIG5vdCBzZXQKQ09ORklHX1NRVUFTSEZTX1pMSUI9eQpDT05GSUdfU1FV
QVNIRlNfTFpPPXkKQ09ORklHX1NRVUFTSEZTX1haPXkKIyBDT05GSUdfU1FVQVNIRlNfNEtf
REVWQkxLX1NJWkUgaXMgbm90IHNldAojIENPTkZJR19TUVVBU0hGU19FTUJFRERFRCBpcyBu
b3Qgc2V0CkNPTkZJR19TUVVBU0hGU19GUkFHTUVOVF9DQUNIRV9TSVpFPTMKIyBDT05GSUdf
VlhGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX01JTklYX0ZTIGlzIG5vdCBzZXQKIyBDT05G
SUdfT01GU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hQRlNfRlMgaXMgbm90IHNldAojIENP
TkZJR19RTlg0RlNfRlMgaXMgbm90IHNldAojIENPTkZJR19RTlg2RlNfRlMgaXMgbm90IHNl
dAojIENPTkZJR19ST01GU19GUyBpcyBub3Qgc2V0CkNPTkZJR19QU1RPUkU9eQojIENPTkZJ
R19QU1RPUkVfQ09OU09MRSBpcyBub3Qgc2V0CiMgQ09ORklHX1BTVE9SRV9SQU0gaXMgbm90
IHNldAojIENPTkZJR19TWVNWX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfVUZTX0ZTIGlzIG5v
dCBzZXQKIyBDT05GSUdfRjJGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0VGSVZBUl9GUyBp
cyBub3Qgc2V0CiMgQ09ORklHX05FVFdPUktfRklMRVNZU1RFTVMgaXMgbm90IHNldApDT05G
SUdfTkxTPXkKQ09ORklHX05MU19ERUZBVUxUPSJ1dGY4IgpDT05GSUdfTkxTX0NPREVQQUdF
XzQzNz15CiMgQ09ORklHX05MU19DT0RFUEFHRV83MzcgaXMgbm90IHNldAojIENPTkZJR19O
TFNfQ09ERVBBR0VfNzc1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1MCBp
cyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTIgaXMgbm90IHNldAojIENPTkZJ
R19OTFNfQ09ERVBBR0VfODU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1
NyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjAgaXMgbm90IHNldAojIENP
TkZJR19OTFNfQ09ERVBBR0VfODYxIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdF
Xzg2MiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjMgaXMgbm90IHNldAoj
IENPTkZJR19OTFNfQ09ERVBBR0VfODY0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQ
QUdFXzg2NSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjYgaXMgbm90IHNl
dAojIENPTkZJR19OTFNfQ09ERVBBR0VfODY5IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NP
REVQQUdFXzkzNiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV85NTAgaXMgbm90
IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfOTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxT
X0NPREVQQUdFXzk0OSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NzQgaXMg
bm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV84IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxT
X0NPREVQQUdFXzEyNTAgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfMTI1MSBp
cyBub3Qgc2V0CkNPTkZJR19OTFNfQVNDSUk9eQpDT05GSUdfTkxTX0lTTzg4NTlfMT15CiMg
Q09ORklHX05MU19JU084ODU5XzIgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8z
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfNCBpcyBub3Qgc2V0CiMgQ09ORklH
X05MU19JU084ODU5XzUgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV82IGlzIG5v
dCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfNyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19J
U084ODU5XzkgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8xMyBpcyBub3Qgc2V0
CiMgQ09ORklHX05MU19JU084ODU5XzE0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4
NTlfMTUgaXMgbm90IHNldAojIENPTkZJR19OTFNfS09JOF9SIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkxTX0tPSThfVSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfUk9NQU4gaXMgbm90
IHNldAojIENPTkZJR19OTFNfTUFDX0NFTFRJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19N
QUNfQ0VOVEVVUk8gaXMgbm90IHNldAojIENPTkZJR19OTFNfTUFDX0NST0FUSUFOIGlzIG5v
dCBzZXQKIyBDT05GSUdfTkxTX01BQ19DWVJJTExJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05M
U19NQUNfR0FFTElDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19HUkVFSyBpcyBub3Qg
c2V0CiMgQ09ORklHX05MU19NQUNfSUNFTEFORCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19N
QUNfSU5VSVQgaXMgbm90IHNldAojIENPTkZJR19OTFNfTUFDX1JPTUFOSUFOIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkxTX01BQ19UVVJLSVNIIGlzIG5vdCBzZXQKQ09ORklHX05MU19VVEY4
PXkKCiMKIyBLZXJuZWwgaGFja2luZwojCkNPTkZJR19UUkFDRV9JUlFGTEFHU19TVVBQT1JU
PXkKCiMKIyBwcmludGsgYW5kIGRtZXNnIG9wdGlvbnMKIwpDT05GSUdfUFJJTlRLX1RJTUU9
eQpDT05GSUdfREVGQVVMVF9NRVNTQUdFX0xPR0xFVkVMPTQKQ09ORklHX0JPT1RfUFJJTlRL
X0RFTEFZPXkKCiMKIyBDb21waWxlLXRpbWUgY2hlY2tzIGFuZCBjb21waWxlciBvcHRpb25z
CiMKQ09ORklHX0RFQlVHX0lORk89eQojIENPTkZJR19ERUJVR19JTkZPX1JFRFVDRUQgaXMg
bm90IHNldApDT05GSUdfRU5BQkxFX1dBUk5fREVQUkVDQVRFRD15CkNPTkZJR19FTkFCTEVf
TVVTVF9DSEVDSz15CkNPTkZJR19GUkFNRV9XQVJOPTIwNDgKQ09ORklHX1NUUklQX0FTTV9T
WU1TPXkKIyBDT05GSUdfUkVBREFCTEVfQVNNIGlzIG5vdCBzZXQKQ09ORklHX1VOVVNFRF9T
WU1CT0xTPXkKIyBDT05GSUdfREVCVUdfRlMgaXMgbm90IHNldAojIENPTkZJR19IRUFERVJT
X0NIRUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU0VDVElPTl9NSVNNQVRDSCBpcyBu
b3Qgc2V0CkNPTkZJR19BUkNIX1dBTlRfRlJBTUVfUE9JTlRFUlM9eQojIENPTkZJR19GUkFN
RV9QT0lOVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfRk9SQ0VfV0VBS19QRVJfQ1BV
IGlzIG5vdCBzZXQKQ09ORklHX01BR0lDX1NZU1JRPXkKQ09ORklHX01BR0lDX1NZU1JRX0RF
RkFVTFRfRU5BQkxFPTB4MQpDT05GSUdfREVCVUdfS0VSTkVMPXkKCiMKIyBNZW1vcnkgRGVi
dWdnaW5nCiMKIyBDT05GSUdfREVCVUdfUEFHRUFMTE9DIGlzIG5vdCBzZXQKIyBDT05GSUdf
REVCVUdfT0JKRUNUUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NMVUJfREVCVUdfT04gaXMgbm90
IHNldAojIENPTkZJR19TTFVCX1NUQVRTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfREVCVUdf
S01FTUxFQUs9eQojIENPTkZJR19ERUJVR19LTUVNTEVBSyBpcyBub3Qgc2V0CiMgQ09ORklH
X0RFQlVHX1NUQUNLX1VTQUdFIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVk0gaXMgbm90
IHNldAojIENPTkZJR19ERUJVR19WSVJUVUFMIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX01F
TU9SWV9JTklUPXkKIyBDT05GSUdfREVCVUdfUEVSX0NQVV9NQVBTIGlzIG5vdCBzZXQKQ09O
RklHX0hBVkVfREVCVUdfU1RBQ0tPVkVSRkxPVz15CiMgQ09ORklHX0RFQlVHX1NUQUNLT1ZF
UkZMT1cgaXMgbm90IHNldApDT05GSUdfSEFWRV9BUkNIX0tNRU1DSEVDSz15CiMgQ09ORklH
X0RFQlVHX1NISVJRIGlzIG5vdCBzZXQKCiMKIyBEZWJ1ZyBMb2NrdXBzIGFuZCBIYW5ncwoj
CkNPTkZJR19MT0NLVVBfREVURUNUT1I9eQpDT05GSUdfSEFSRExPQ0tVUF9ERVRFQ1RPUj15
CiMgQ09ORklHX0JPT1RQQVJBTV9IQVJETE9DS1VQX1BBTklDIGlzIG5vdCBzZXQKQ09ORklH
X0JPT1RQQVJBTV9IQVJETE9DS1VQX1BBTklDX1ZBTFVFPTAKIyBDT05GSUdfQk9PVFBBUkFN
X1NPRlRMT0NLVVBfUEFOSUMgaXMgbm90IHNldApDT05GSUdfQk9PVFBBUkFNX1NPRlRMT0NL
VVBfUEFOSUNfVkFMVUU9MApDT05GSUdfREVURUNUX0hVTkdfVEFTSz15CkNPTkZJR19ERUZB
VUxUX0hVTkdfVEFTS19USU1FT1VUPTEyMAojIENPTkZJR19CT09UUEFSQU1fSFVOR19UQVNL
X1BBTklDIGlzIG5vdCBzZXQKQ09ORklHX0JPT1RQQVJBTV9IVU5HX1RBU0tfUEFOSUNfVkFM
VUU9MAojIENPTkZJR19QQU5JQ19PTl9PT1BTIGlzIG5vdCBzZXQKQ09ORklHX1BBTklDX09O
X09PUFNfVkFMVUU9MApDT05GSUdfUEFOSUNfVElNRU9VVD0wCiMgQ09ORklHX1NDSEVEX0RF
QlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NIRURTVEFUUyBpcyBub3Qgc2V0CiMgQ09ORklH
X1RJTUVSX1NUQVRTIGlzIG5vdCBzZXQKCiMKIyBMb2NrIERlYnVnZ2luZyAoc3BpbmxvY2tz
LCBtdXRleGVzLCBldGMuLi4pCiMKIyBDT05GSUdfREVCVUdfUlRfTVVURVhFUyBpcyBub3Qg
c2V0CiMgQ09ORklHX1JUX01VVEVYX1RFU1RFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVH
X1NQSU5MT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTVVURVhFUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0RFQlVHX1dXX01VVEVYX1NMT1dQQVRIIGlzIG5vdCBzZXQKIyBDT05GSUdf
REVCVUdfTE9DS19BTExPQyBpcyBub3Qgc2V0CiMgQ09ORklHX1BST1ZFX0xPQ0tJTkcgaXMg
bm90IHNldAojIENPTkZJR19MT0NLX1NUQVQgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19B
VE9NSUNfU0xFRVAgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19MT0NLSU5HX0FQSV9TRUxG
VEVTVFMgaXMgbm90IHNldAojIENPTkZJR19MT0NLX1RPUlRVUkVfVEVTVCBpcyBub3Qgc2V0
CiMgQ09ORklHX0RFQlVHX0tPQkpFQ1QgaXMgbm90IHNldApDT05GSUdfREVCVUdfQlVHVkVS
Qk9TRT15CiMgQ09ORklHX0RFQlVHX0xJU1QgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19Q
SV9MSVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU0cgaXMgbm90IHNldAojIENPTkZJ
R19ERUJVR19OT1RJRklFUlMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19DUkVERU5USUFM
UyBpcyBub3Qgc2V0CgojCiMgUkNVIERlYnVnZ2luZwojCiMgQ09ORklHX1NQQVJTRV9SQ1Vf
UE9JTlRFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1RPUlRVUkVfVEVTVCBpcyBub3Qgc2V0CiMg
Q09ORklHX1JDVV9UT1JUVVJFX1RFU1QgaXMgbm90IHNldApDT05GSUdfUkNVX0NQVV9TVEFM
TF9USU1FT1VUPTYwCiMgQ09ORklHX1JDVV9DUFVfU1RBTExfSU5GTyBpcyBub3Qgc2V0CiMg
Q09ORklHX1JDVV9UUkFDRSBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0JMT0NLX0VYVF9E
RVZUIGlzIG5vdCBzZXQKIyBDT05GSUdfTk9USUZJRVJfRVJST1JfSU5KRUNUSU9OIGlzIG5v
dCBzZXQKIyBDT05GSUdfRkFVTFRfSU5KRUNUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfTEFU
RU5DWVRPUCBpcyBub3Qgc2V0CkNPTkZJR19BUkNIX0hBU19ERUJVR19TVFJJQ1RfVVNFUl9D
T1BZX0NIRUNLUz15CiMgQ09ORklHX0RFQlVHX1NUUklDVF9VU0VSX0NPUFlfQ0hFQ0tTIGlz
IG5vdCBzZXQKQ09ORklHX1VTRVJfU1RBQ0tUUkFDRV9TVVBQT1JUPXkKQ09ORklHX0hBVkVf
RlVOQ1RJT05fVFJBQ0VSPXkKQ09ORklHX0hBVkVfRlVOQ1RJT05fR1JBUEhfVFJBQ0VSPXkK
Q09ORklHX0hBVkVfRlVOQ1RJT05fR1JBUEhfRlBfVEVTVD15CkNPTkZJR19IQVZFX0ZVTkNU
SU9OX1RSQUNFX01DT1VOVF9URVNUPXkKQ09ORklHX0hBVkVfRFlOQU1JQ19GVFJBQ0U9eQpD
T05GSUdfSEFWRV9EWU5BTUlDX0ZUUkFDRV9XSVRIX1JFR1M9eQpDT05GSUdfSEFWRV9GVFJB
Q0VfTUNPVU5UX1JFQ09SRD15CkNPTkZJR19IQVZFX1NZU0NBTExfVFJBQ0VQT0lOVFM9eQpD
T05GSUdfSEFWRV9GRU5UUlk9eQpDT05GSUdfSEFWRV9DX1JFQ09SRE1DT1VOVD15CkNPTkZJ
R19UUkFDSU5HX1NVUFBPUlQ9eQojIENPTkZJR19GVFJBQ0UgaXMgbm90IHNldAoKIwojIFJ1
bnRpbWUgVGVzdGluZwojCiMgQ09ORklHX1RFU1RfTElTVF9TT1JUIGlzIG5vdCBzZXQKIyBD
T05GSUdfQkFDS1RSQUNFX1NFTEZfVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX1JCVFJFRV9U
RVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5URVJWQUxfVFJFRV9URVNUIGlzIG5vdCBzZXQK
IyBDT05GSUdfUEVSQ1BVX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19BVE9NSUM2NF9TRUxG
VEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX1RFU1RfU1RSSU5HX0hFTFBFUlMgaXMgbm90IHNl
dAojIENPTkZJR19URVNUX0tTVFJUT1ggaXMgbm90IHNldAojIENPTkZJR19QUk9WSURFX09I
Q0kxMzk0X0RNQV9JTklUIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1BX0FQSV9ERUJVRyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1RFU1RfTU9EVUxFIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9V
U0VSX0NPUFkgaXMgbm90IHNldAojIENPTkZJR19URVNUX0JQRiBpcyBub3Qgc2V0CiMgQ09O
RklHX1NBTVBMRVMgaXMgbm90IHNldApDT05GSUdfSEFWRV9BUkNIX0tHREI9eQojIENPTkZJ
R19LR0RCIGlzIG5vdCBzZXQKQ09ORklHX1NUUklDVF9ERVZNRU09eQpDT05GSUdfWDg2X1ZF
UkJPU0VfQk9PVFVQPXkKQ09ORklHX0VBUkxZX1BSSU5USz15CiMgQ09ORklHX0VBUkxZX1BS
SU5US19EQkdQIGlzIG5vdCBzZXQKIyBDT05GSUdfRUFSTFlfUFJJTlRLX0VGSSBpcyBub3Qg
c2V0CiMgQ09ORklHX1g4Nl9QVERVTVAgaXMgbm90IHNldApDT05GSUdfREVCVUdfUk9EQVRB
PXkKIyBDT05GSUdfREVCVUdfUk9EQVRBX1RFU1QgaXMgbm90IHNldApDT05GSUdfREVCVUdf
U0VUX01PRFVMRV9ST05YPXkKIyBDT05GSUdfREVCVUdfTlhfVEVTVCBpcyBub3Qgc2V0CkNP
TkZJR19ET1VCTEVGQVVMVD15CiMgQ09ORklHX0RFQlVHX1RMQkZMVVNIIGlzIG5vdCBzZXQK
IyBDT05GSUdfSU9NTVVfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19JT01NVV9TVFJFU1Mg
aXMgbm90IHNldApDT05GSUdfSEFWRV9NTUlPVFJBQ0VfU1VQUE9SVD15CkNPTkZJR19JT19E
RUxBWV9UWVBFXzBYODA9MApDT05GSUdfSU9fREVMQVlfVFlQRV8wWEVEPTEKQ09ORklHX0lP
X0RFTEFZX1RZUEVfVURFTEFZPTIKQ09ORklHX0lPX0RFTEFZX1RZUEVfTk9ORT0zCkNPTkZJ
R19JT19ERUxBWV8wWDgwPXkKIyBDT05GSUdfSU9fREVMQVlfMFhFRCBpcyBub3Qgc2V0CiMg
Q09ORklHX0lPX0RFTEFZX1VERUxBWSBpcyBub3Qgc2V0CiMgQ09ORklHX0lPX0RFTEFZX05P
TkUgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9JT19ERUxBWV9UWVBFPTAKIyBDT05GSUdf
Q1BBX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfT1BUSU1JWkVfSU5MSU5JTkcgaXMgbm90
IHNldAojIENPTkZJR19ERUJVR19OTUlfU0VMRlRFU1QgaXMgbm90IHNldAojIENPTkZJR19Y
ODZfREVCVUdfU1RBVElDX0NQVV9IQVMgaXMgbm90IHNldAoKIwojIFNlY3VyaXR5IG9wdGlv
bnMKIwpDT05GSUdfS0VZUz15CiMgQ09ORklHX1BFUlNJU1RFTlRfS0VZUklOR1MgaXMgbm90
IHNldAojIENPTkZJR19CSUdfS0VZUyBpcyBub3Qgc2V0CiMgQ09ORklHX1RSVVNURURfS0VZ
UyBpcyBub3Qgc2V0CiMgQ09ORklHX0VOQ1JZUFRFRF9LRVlTIGlzIG5vdCBzZXQKQ09ORklH
X0tFWVNfREVCVUdfUFJPQ19LRVlTPXkKIyBDT05GSUdfU0VDVVJJVFlfRE1FU0dfUkVTVFJJ
Q1QgaXMgbm90IHNldApDT05GSUdfU0VDVVJJVFk9eQpDT05GSUdfU0VDVVJJVFlGUz15CiMg
Q09ORklHX1NFQ1VSSVRZX05FVFdPUksgaXMgbm90IHNldAojIENPTkZJR19TRUNVUklUWV9Q
QVRIIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5URUxfVFhUIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VDVVJJVFlfU01BQ0sgaXMgbm90IHNldAojIENPTkZJR19TRUNVUklUWV9UT01PWU8gaXMg
bm90IHNldAojIENPTkZJR19TRUNVUklUWV9BUFBBUk1PUiBpcyBub3Qgc2V0CiMgQ09ORklH
X1NFQ1VSSVRZX1lBTUEgaXMgbm90IHNldAojIENPTkZJR19JTUEgaXMgbm90IHNldAojIENP
TkZJR19FVk0gaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9TRUNVUklUWV9EQUM9eQpDT05G
SUdfREVGQVVMVF9TRUNVUklUWT0iIgpDT05GSUdfWE9SX0JMT0NLUz15CkNPTkZJR19DUllQ
VE89eQoKIwojIENyeXB0byBjb3JlIG9yIGhlbHBlcgojCiMgQ09ORklHX0NSWVBUT19GSVBT
IGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19BTEdBUEk9eQpDT05GSUdfQ1JZUFRPX0FMR0FQ
STI9eQpDT05GSUdfQ1JZUFRPX0FFQUQ9eQpDT05GSUdfQ1JZUFRPX0FFQUQyPXkKQ09ORklH
X0NSWVBUT19CTEtDSVBIRVI9eQpDT05GSUdfQ1JZUFRPX0JMS0NJUEhFUjI9eQpDT05GSUdf
Q1JZUFRPX0hBU0g9eQpDT05GSUdfQ1JZUFRPX0hBU0gyPXkKQ09ORklHX0NSWVBUT19STkc9
eQpDT05GSUdfQ1JZUFRPX1JORzI9eQpDT05GSUdfQ1JZUFRPX1BDT01QPXkKQ09ORklHX0NS
WVBUT19QQ09NUDI9eQpDT05GSUdfQ1JZUFRPX01BTkFHRVI9eQpDT05GSUdfQ1JZUFRPX01B
TkFHRVIyPXkKIyBDT05GSUdfQ1JZUFRPX1VTRVIgaXMgbm90IHNldAojIENPTkZJR19DUllQ
VE9fTUFOQUdFUl9ESVNBQkxFX1RFU1RTIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19HRjEy
OE1VTD15CkNPTkZJR19DUllQVE9fTlVMTD15CkNPTkZJR19DUllQVE9fUENSWVBUPXkKQ09O
RklHX0NSWVBUT19XT1JLUVVFVUU9eQpDT05GSUdfQ1JZUFRPX0NSWVBURD15CkNPTkZJR19D
UllQVE9fQVVUSEVOQz15CiMgQ09ORklHX0NSWVBUT19URVNUIGlzIG5vdCBzZXQKQ09ORklH
X0NSWVBUT19BQkxLX0hFTFBFUj15CkNPTkZJR19DUllQVE9fR0xVRV9IRUxQRVJfWDg2PXkK
CiMKIyBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gd2l0aCBBc3NvY2lhdGVkIERhdGEKIwpD
T05GSUdfQ1JZUFRPX0NDTT15CkNPTkZJR19DUllQVE9fR0NNPXkKQ09ORklHX0NSWVBUT19T
RVFJVj15CgojCiMgQmxvY2sgbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0NCQz15CkNPTkZJR19D
UllQVE9fQ1RSPXkKQ09ORklHX0NSWVBUT19DVFM9bQpDT05GSUdfQ1JZUFRPX0VDQj15CkNP
TkZJR19DUllQVE9fTFJXPXkKQ09ORklHX0NSWVBUT19QQ0JDPXkKQ09ORklHX0NSWVBUT19Y
VFM9eQoKIwojIEhhc2ggbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0NNQUM9eQpDT05GSUdfQ1JZ
UFRPX0hNQUM9eQpDT05GSUdfQ1JZUFRPX1hDQkM9eQpDT05GSUdfQ1JZUFRPX1ZNQUM9eQoK
IwojIERpZ2VzdAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPXkKQ09ORklHX0NSWVBUT19DUkMz
MkNfSU5URUw9eQojIENPTkZJR19DUllQVE9fQ1JDMzIgaXMgbm90IHNldAojIENPTkZJR19D
UllQVE9fQ1JDMzJfUENMTVVMIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19DUkNUMTBESUY9
eQojIENPTkZJR19DUllQVE9fQ1JDVDEwRElGX1BDTE1VTCBpcyBub3Qgc2V0CkNPTkZJR19D
UllQVE9fR0hBU0g9eQpDT05GSUdfQ1JZUFRPX01END15CkNPTkZJR19DUllQVE9fTUQ1PXkK
Q09ORklHX0NSWVBUT19NSUNIQUVMX01JQz15CkNPTkZJR19DUllQVE9fUk1EMTI4PXkKQ09O
RklHX0NSWVBUT19STUQxNjA9eQpDT05GSUdfQ1JZUFRPX1JNRDI1Nj15CkNPTkZJR19DUllQ
VE9fUk1EMzIwPXkKQ09ORklHX0NSWVBUT19TSEExPXkKQ09ORklHX0NSWVBUT19TSEExX1NT
U0UzPXkKIyBDT05GSUdfQ1JZUFRPX1NIQTI1Nl9TU1NFMyBpcyBub3Qgc2V0CiMgQ09ORklH
X0NSWVBUT19TSEE1MTJfU1NTRTMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1NIQTI1Nj15
CkNPTkZJR19DUllQVE9fU0hBNTEyPXkKQ09ORklHX0NSWVBUT19UR1IxOTI9eQpDT05GSUdf
Q1JZUFRPX1dQNTEyPXkKQ09ORklHX0NSWVBUT19HSEFTSF9DTE1VTF9OSV9JTlRFTD15Cgoj
CiMgQ2lwaGVycwojCkNPTkZJR19DUllQVE9fQUVTPXkKQ09ORklHX0NSWVBUT19BRVNfWDg2
XzY0PXkKQ09ORklHX0NSWVBUT19BRVNfTklfSU5URUw9eQpDT05GSUdfQ1JZUFRPX0FOVUJJ
Uz15CkNPTkZJR19DUllQVE9fQVJDND15CkNPTkZJR19DUllQVE9fQkxPV0ZJU0g9eQpDT05G
SUdfQ1JZUFRPX0JMT1dGSVNIX0NPTU1PTj15CkNPTkZJR19DUllQVE9fQkxPV0ZJU0hfWDg2
XzY0PXkKQ09ORklHX0NSWVBUT19DQU1FTExJQT15CiMgQ09ORklHX0NSWVBUT19DQU1FTExJ
QV9YODZfNjQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQ0FNRUxMSUFfQUVTTklfQVZY
X1g4Nl82NCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19DQU1FTExJQV9BRVNOSV9BVlgy
X1g4Nl82NCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fQ0FTVF9DT01NT049eQpDT05GSUdf
Q1JZUFRPX0NBU1Q1PXkKIyBDT05GSUdfQ1JZUFRPX0NBU1Q1X0FWWF9YODZfNjQgaXMgbm90
IHNldApDT05GSUdfQ1JZUFRPX0NBU1Q2PXkKIyBDT05GSUdfQ1JZUFRPX0NBU1Q2X0FWWF9Y
ODZfNjQgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0RFUz15CkNPTkZJR19DUllQVE9fRkNS
WVBUPXkKQ09ORklHX0NSWVBUT19LSEFaQUQ9eQpDT05GSUdfQ1JZUFRPX1NBTFNBMjA9eQpD
T05GSUdfQ1JZUFRPX1NBTFNBMjBfWDg2XzY0PXkKQ09ORklHX0NSWVBUT19TRUVEPXkKQ09O
RklHX0NSWVBUT19TRVJQRU5UPXkKIyBDT05GSUdfQ1JZUFRPX1NFUlBFTlRfU1NFMl9YODZf
NjQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fU0VSUEVOVF9BVlhfWDg2XzY0IGlzIG5v
dCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NFUlBFTlRfQVZYMl9YODZfNjQgaXMgbm90IHNldApD
T05GSUdfQ1JZUFRPX1RFQT15CkNPTkZJR19DUllQVE9fVFdPRklTSD15CkNPTkZJR19DUllQ
VE9fVFdPRklTSF9DT01NT049eQpDT05GSUdfQ1JZUFRPX1RXT0ZJU0hfWDg2XzY0PXkKQ09O
RklHX0NSWVBUT19UV09GSVNIX1g4Nl82NF8zV0FZPXkKIyBDT05GSUdfQ1JZUFRPX1RXT0ZJ
U0hfQVZYX1g4Nl82NCBpcyBub3Qgc2V0CgojCiMgQ29tcHJlc3Npb24KIwpDT05GSUdfQ1JZ
UFRPX0RFRkxBVEU9eQpDT05GSUdfQ1JZUFRPX1pMSUI9eQpDT05GSUdfQ1JZUFRPX0xaTz15
CiMgQ09ORklHX0NSWVBUT19MWjQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fTFo0SEMg
aXMgbm90IHNldAoKIwojIFJhbmRvbSBOdW1iZXIgR2VuZXJhdGlvbgojCkNPTkZJR19DUllQ
VE9fQU5TSV9DUFJORz15CkNPTkZJR19DUllQVE9fVVNFUl9BUEk9eQpDT05GSUdfQ1JZUFRP
X1VTRVJfQVBJX0hBU0g9eQpDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX1NLQ0lQSEVSPXkKQ09O
RklHX0NSWVBUT19IVz15CiMgQ09ORklHX0NSWVBUT19ERVZfUEFETE9DSyBpcyBub3Qgc2V0
CiMgQ09ORklHX0NSWVBUT19ERVZfQ0NQIGlzIG5vdCBzZXQKIyBDT05GSUdfQVNZTU1FVFJJ
Q19LRVlfVFlQRSBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0tWTT15CiMgQ09ORklHX1ZJUlRV
QUxJWkFUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfQklOQVJZX1BSSU5URiBpcyBub3Qgc2V0
CgojCiMgTGlicmFyeSByb3V0aW5lcwojCkNPTkZJR19SQUlENl9QUT15CkNPTkZJR19CSVRS
RVZFUlNFPXkKQ09ORklHX0dFTkVSSUNfU1RSTkNQWV9GUk9NX1VTRVI9eQpDT05GSUdfR0VO
RVJJQ19TVFJOTEVOX1VTRVI9eQpDT05GSUdfR0VORVJJQ19ORVRfVVRJTFM9eQpDT05GSUdf
R0VORVJJQ19GSU5EX0ZJUlNUX0JJVD15CkNPTkZJR19HRU5FUklDX1BDSV9JT01BUD15CkNP
TkZJR19HRU5FUklDX0lPTUFQPXkKQ09ORklHX0dFTkVSSUNfSU89eQpDT05GSUdfQVJDSF9V
U0VfQ01QWENIR19MT0NLUkVGPXkKQ09ORklHX0NSQ19DQ0lUVD15CkNPTkZJR19DUkMxNj15
CkNPTkZJR19DUkNfVDEwRElGPXkKQ09ORklHX0NSQ19JVFVfVD15CkNPTkZJR19DUkMzMj15
CiMgQ09ORklHX0NSQzMyX1NFTEZURVNUIGlzIG5vdCBzZXQKQ09ORklHX0NSQzMyX1NMSUNF
Qlk4PXkKIyBDT05GSUdfQ1JDMzJfU0xJQ0VCWTQgaXMgbm90IHNldAojIENPTkZJR19DUkMz
Ml9TQVJXQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JDMzJfQklUIGlzIG5vdCBzZXQKQ09O
RklHX0NSQzc9eQpDT05GSUdfTElCQ1JDMzJDPXkKQ09ORklHX0NSQzg9eQojIENPTkZJR19B
VURJVF9BUkNIX0NPTVBBVF9HRU5FUklDIGlzIG5vdCBzZXQKIyBDT05GSUdfUkFORE9NMzJf
U0VMRlRFU1QgaXMgbm90IHNldApDT05GSUdfWkxJQl9JTkZMQVRFPXkKQ09ORklHX1pMSUJf
REVGTEFURT15CkNPTkZJR19MWk9fQ09NUFJFU1M9eQpDT05GSUdfTFpPX0RFQ09NUFJFU1M9
eQpDT05GSUdfTFo0X0RFQ09NUFJFU1M9eQpDT05GSUdfWFpfREVDPXkKQ09ORklHX1haX0RF
Q19YODY9eQpDT05GSUdfWFpfREVDX1BPV0VSUEM9eQpDT05GSUdfWFpfREVDX0lBNjQ9eQpD
T05GSUdfWFpfREVDX0FSTT15CkNPTkZJR19YWl9ERUNfQVJNVEhVTUI9eQpDT05GSUdfWFpf
REVDX1NQQVJDPXkKQ09ORklHX1haX0RFQ19CQ0o9eQojIENPTkZJR19YWl9ERUNfVEVTVCBp
cyBub3Qgc2V0CkNPTkZJR19ERUNPTVBSRVNTX0daSVA9eQpDT05GSUdfREVDT01QUkVTU19C
WklQMj15CkNPTkZJR19ERUNPTVBSRVNTX0xaTUE9eQpDT05GSUdfREVDT01QUkVTU19YWj15
CkNPTkZJR19ERUNPTVBSRVNTX0xaTz15CkNPTkZJR19ERUNPTVBSRVNTX0xaND15CkNPTkZJ
R19URVhUU0VBUkNIPXkKQ09ORklHX1RFWFRTRUFSQ0hfS01QPXkKQ09ORklHX1RFWFRTRUFS
Q0hfQk09eQpDT05GSUdfVEVYVFNFQVJDSF9GU009eQpDT05GSUdfSU5URVJWQUxfVFJFRT15
CkNPTkZJR19BU1NPQ0lBVElWRV9BUlJBWT15CkNPTkZJR19IQVNfSU9NRU09eQpDT05GSUdf
SEFTX0lPUE9SVF9NQVA9eQpDT05GSUdfSEFTX0RNQT15CkNPTkZJR19DSEVDS19TSUdOQVRV
UkU9eQpDT05GSUdfQ1BVX1JNQVA9eQpDT05GSUdfRFFMPXkKQ09ORklHX05MQVRUUj15CkNP
TkZJR19BUkNIX0hBU19BVE9NSUM2NF9ERUNfSUZfUE9TSVRJVkU9eQpDT05GSUdfTFJVX0NB
Q0hFPXkKQ09ORklHX0FWRVJBR0U9eQpDT05GSUdfQ09SRElDPXkKIyBDT05GSUdfRERSIGlz
IG5vdCBzZXQKQ09ORklHX1VDUzJfU1RSSU5HPXkKQ09ORklHX0ZPTlRfU1VQUE9SVD15CiMg
Q09ORklHX0ZPTlRTIGlzIG5vdCBzZXQKQ09ORklHX0ZPTlRfOHg4PXkKQ09ORklHX0ZPTlRf
OHgxNj15Cg==
------------12A0390BB304161AE
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------12A0390BB304161AE--



From xen-devel-bounces@lists.xen.org Fri Dec 19 13:22:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 13: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 1Y1xVq-0001is-EC; Fri, 19 Dec 2014 13:22:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiang.liu@linux.intel.com>) id 1Y1xVp-0001in-3w
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 13:22:33 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	E8/50-22819-89624945; Fri, 19 Dec 2014 13:22:32 +0000
X-Env-Sender: jiang.liu@linux.intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418995351!8935187!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31043 invoked from network); 19 Dec 2014 13:22:31 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-206.messagelabs.com with SMTP;
	19 Dec 2014 13:22:31 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga101.jf.intel.com with ESMTP; 19 Dec 2014 05:22:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="501517093"
Received: from dunliu-mobl1.ccr.corp.intel.com (HELO [10.255.29.90])
	([10.255.29.90])
	by orsmga003.jf.intel.com with ESMTP; 19 Dec 2014 05:18:04 -0800
Message-ID: <54942693.6080007@linux.intel.com>
Date: Fri, 19 Dec 2014 21:22:27 +0800
From: Jiang Liu <jiang.liu@linux.intel.com>
Organization: Intel
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>, konrad.wilk@oracle.com, 
	David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1824124380.20141219141645@eikelenboom.it>
In-Reply-To: <1824124380.20141219141645@eikelenboom.it>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events
 don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Sander,
	Sorry for the trouble, I will investigate on next Monday.
Regards!
Gerry

On 2014/12/19 21:16, Sander Eikelenboom wrote:
> Hi,
> 
> When running under Xen, ACPI powerbutton events don't work anymore, 
> there is no reaction when pressing the powerbutton.
> 
> On baremetal everything works fine, acpid gets the event and the 
> machine powers down perfectly. The machine is an Intel NUC.
>  
> Bisection has lead to:
> 
> b81975eade8c6495f3c4d6746d22bdc95f617777 is the first bad commit
> commit b81975eade8c6495f3c4d6746d22bdc95f617777
> Author: Jiang Liu <jiang.liu@linux.intel.com>
> Date:   Mon Jun 9 16:20:11 2014 +0800
> 
>     x86, irq: Clean up irqdomain transition code
> 
>     Now we have completely switched to irqdomain, so clean up transition code
>     in IOAPIC drivers.
> 
>     Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>     Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>     Cc: Tony Luck <tony.luck@intel.com>
>     Cc: Joerg Roedel <joro@8bytes.org>
>     Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
>     Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>     Cc: Grant Likely <grant.likely@linaro.org>
>     Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>     Cc: Bjorn Helgaas <bhelgaas@google.com>
>     Cc: Randy Dunlap <rdunlap@infradead.org>
>     Cc: Yinghai Lu <yinghai@kernel.org>
>     Link: http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang.liu@linux.intel.com
>     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Reverting this specific commit on linux-tip (3.19-mw) gets things working again under Xen.
> Kernel .config is attached.
> 
> --
> Sander
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 13:22:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 13: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 1Y1xVq-0001is-EC; Fri, 19 Dec 2014 13:22:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiang.liu@linux.intel.com>) id 1Y1xVp-0001in-3w
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 13:22:33 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	E8/50-22819-89624945; Fri, 19 Dec 2014 13:22:32 +0000
X-Env-Sender: jiang.liu@linux.intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1418995351!8935187!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31043 invoked from network); 19 Dec 2014 13:22:31 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-206.messagelabs.com with SMTP;
	19 Dec 2014 13:22:31 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga101.jf.intel.com with ESMTP; 19 Dec 2014 05:22:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="501517093"
Received: from dunliu-mobl1.ccr.corp.intel.com (HELO [10.255.29.90])
	([10.255.29.90])
	by orsmga003.jf.intel.com with ESMTP; 19 Dec 2014 05:18:04 -0800
Message-ID: <54942693.6080007@linux.intel.com>
Date: Fri, 19 Dec 2014 21:22:27 +0800
From: Jiang Liu <jiang.liu@linux.intel.com>
Organization: Intel
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>, konrad.wilk@oracle.com, 
	David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1824124380.20141219141645@eikelenboom.it>
In-Reply-To: <1824124380.20141219141645@eikelenboom.it>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events
 don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Sander,
	Sorry for the trouble, I will investigate on next Monday.
Regards!
Gerry

On 2014/12/19 21:16, Sander Eikelenboom wrote:
> Hi,
> 
> When running under Xen, ACPI powerbutton events don't work anymore, 
> there is no reaction when pressing the powerbutton.
> 
> On baremetal everything works fine, acpid gets the event and the 
> machine powers down perfectly. The machine is an Intel NUC.
>  
> Bisection has lead to:
> 
> b81975eade8c6495f3c4d6746d22bdc95f617777 is the first bad commit
> commit b81975eade8c6495f3c4d6746d22bdc95f617777
> Author: Jiang Liu <jiang.liu@linux.intel.com>
> Date:   Mon Jun 9 16:20:11 2014 +0800
> 
>     x86, irq: Clean up irqdomain transition code
> 
>     Now we have completely switched to irqdomain, so clean up transition code
>     in IOAPIC drivers.
> 
>     Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>     Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>     Cc: Tony Luck <tony.luck@intel.com>
>     Cc: Joerg Roedel <joro@8bytes.org>
>     Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
>     Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>     Cc: Grant Likely <grant.likely@linaro.org>
>     Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>     Cc: Bjorn Helgaas <bhelgaas@google.com>
>     Cc: Randy Dunlap <rdunlap@infradead.org>
>     Cc: Yinghai Lu <yinghai@kernel.org>
>     Link: http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang.liu@linux.intel.com
>     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Reverting this specific commit on linux-tip (3.19-mw) gets things working again under Xen.
> Kernel .config is attached.
> 
> --
> Sander
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 13:41:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 13: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 1Y1xo2-0002BA-89; Fri, 19 Dec 2014 13:41: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 1Y1xo0-0002B4-8C
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 13:41:20 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	1F/E7-27623-FFA24945; Fri, 19 Dec 2014 13:41:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418996478!14557081!1
X-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 22875 invoked from network); 19 Dec 2014 13:41:18 -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; 19 Dec 2014 13:41:18 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 13:41:17 +0000
Message-Id: <5494390D020000780005104E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 13:41:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418926000-5953-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418926000-5953-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 v4 for 4.5] x86/VPMU: Clear last_vcpu when
 destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 19:06, <boris.ostrovsky@oracle.com> wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try to dereference it in
> the future, when VCPU is gone.
> 
> We have to do this via IPI since otherwise there is a (somewheat
> theoretical) chance that between test and subsequent clearing
> of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
> both vpmu_load() and then vpmu_save() for another VCPU. The former
> will clear last_vcpu and the latter will set it to something else.
> 
> Performing this operation via IPI will guarantee that nothing can
> happen on the remote processor between testing and clearing of
> last_vcpu.
> 
> We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
> avoid unnecessary percpu tests and arch-specific destroy ops. Thus
> checks in AMD and Intel routines are no longer needed.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.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 Dec 19 13:41:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 13: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 1Y1xo2-0002BA-89; Fri, 19 Dec 2014 13:41: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 1Y1xo0-0002B4-8C
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 13:41:20 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	1F/E7-27623-FFA24945; Fri, 19 Dec 2014 13:41:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1418996478!14557081!1
X-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 22875 invoked from network); 19 Dec 2014 13:41:18 -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; 19 Dec 2014 13:41:18 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 13:41:17 +0000
Message-Id: <5494390D020000780005104E@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 13:41:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <1418926000-5953-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1418926000-5953-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 v4 for 4.5] x86/VPMU: Clear last_vcpu when
 destroying VPMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.12.14 at 19:06, <boris.ostrovsky@oracle.com> wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try to dereference it in
> the future, when VCPU is gone.
> 
> We have to do this via IPI since otherwise there is a (somewheat
> theoretical) chance that between test and subsequent clearing
> of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
> both vpmu_load() and then vpmu_save() for another VCPU. The former
> will clear last_vcpu and the latter will set it to something else.
> 
> Performing this operation via IPI will guarantee that nothing can
> happen on the remote processor between testing and clearing of
> last_vcpu.
> 
> We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to
> avoid unnecessary percpu tests and arch-specific destroy ops. Thus
> checks in AMD and Intel routines are no longer needed.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.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 Dec 19 13:44:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 13:44:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1xqv-0002a6-Qb; Fri, 19 Dec 2014 13:44:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiang.liu@linux.intel.com>) id 1Y1xqu-0002Zw-NT
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 13:44:20 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	27/21-09842-4BB24945; Fri, 19 Dec 2014 13:44:20 +0000
X-Env-Sender: jiang.liu@linux.intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418996658!8742717!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 2667 invoked from network); 19 Dec 2014 13:44:19 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-21.messagelabs.com with SMTP;
	19 Dec 2014 13:44:19 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 19 Dec 2014 05:42:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,606,1413270000"; d="scan'208";a="657097477"
Received: from dunliu-mobl1.ccr.corp.intel.com (HELO [10.255.29.90])
	([10.255.29.90])
	by orsmga002.jf.intel.com with ESMTP; 19 Dec 2014 05:43:55 -0800
Message-ID: <54942B9A.6090608@linux.intel.com>
Date: Fri, 19 Dec 2014 21:43:54 +0800
From: Jiang Liu <jiang.liu@linux.intel.com>
Organization: Intel
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>, konrad.wilk@oracle.com, 
	David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1824124380.20141219141645@eikelenboom.it>
In-Reply-To: <1824124380.20141219141645@eikelenboom.it>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events
 don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Sander,
	Found the root cause now, but still need some time to find
a solution for this issue.
xen_smp_prepare_cpus() doesn't call:
	smpboot_setup_io_apic()->setup_IO_APIC()
So no irqdomain structure for IOAPIC created,  then mp_map_pin_to_irq()
fails at the very beginning.

The most simple solution is to revert following change, but it doesn't
seem the best solution. I will try to find a hook point to create
irqdomain for IOAPIC from xen_smp_prepare_cpus().
Regards!
Gerry

@@ -1034,13 +1035,8 @@ static int mp_map_pin_to_irq(u32 gsi, int idx,
int ioapic, int pin,
        struct irq_domain *domain = mp_ioapic_irqdomain(ioapic);
        struct mp_pin_info *info = mp_pin_info(ioapic, pin);

-       if (!domain) {
-               /*
-                * Provide an identity mapping of gsi == irq except on truly
-                * weird platforms that have non isa irqs in the first
16 gsis.
-                */
-               return gsi >= nr_legacy_irqs() ? gsi : gsi_top + gsi;
-       }
+       if (!domain)
+               return -1;

        mutex_lock(&ioapic_mutex);



On 2014/12/19 21:16, Sander Eikelenboom wrote:
> Hi,
> 
> When running under Xen, ACPI powerbutton events don't work anymore, 
> there is no reaction when pressing the powerbutton.
> 
> On baremetal everything works fine, acpid gets the event and the 
> machine powers down perfectly. The machine is an Intel NUC.
>  
> Bisection has lead to:
> 
> b81975eade8c6495f3c4d6746d22bdc95f617777 is the first bad commit
> commit b81975eade8c6495f3c4d6746d22bdc95f617777
> Author: Jiang Liu <jiang.liu@linux.intel.com>
> Date:   Mon Jun 9 16:20:11 2014 +0800
> 
>     x86, irq: Clean up irqdomain transition code
> 
>     Now we have completely switched to irqdomain, so clean up transition code
>     in IOAPIC drivers.
> 
>     Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>     Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>     Cc: Tony Luck <tony.luck@intel.com>
>     Cc: Joerg Roedel <joro@8bytes.org>
>     Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
>     Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>     Cc: Grant Likely <grant.likely@linaro.org>
>     Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>     Cc: Bjorn Helgaas <bhelgaas@google.com>
>     Cc: Randy Dunlap <rdunlap@infradead.org>
>     Cc: Yinghai Lu <yinghai@kernel.org>
>     Link: http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang.liu@linux.intel.com
>     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Reverting this specific commit on linux-tip (3.19-mw) gets things working again under Xen.
> Kernel .config is attached.
> 
> --
> Sander
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 13:44:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 13:44:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1xqv-0002a6-Qb; Fri, 19 Dec 2014 13:44:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiang.liu@linux.intel.com>) id 1Y1xqu-0002Zw-NT
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 13:44:20 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	27/21-09842-4BB24945; Fri, 19 Dec 2014 13:44:20 +0000
X-Env-Sender: jiang.liu@linux.intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1418996658!8742717!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 2667 invoked from network); 19 Dec 2014 13:44:19 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-21.messagelabs.com with SMTP;
	19 Dec 2014 13:44:19 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 19 Dec 2014 05:42:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,606,1413270000"; d="scan'208";a="657097477"
Received: from dunliu-mobl1.ccr.corp.intel.com (HELO [10.255.29.90])
	([10.255.29.90])
	by orsmga002.jf.intel.com with ESMTP; 19 Dec 2014 05:43:55 -0800
Message-ID: <54942B9A.6090608@linux.intel.com>
Date: Fri, 19 Dec 2014 21:43:54 +0800
From: Jiang Liu <jiang.liu@linux.intel.com>
Organization: Intel
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>, konrad.wilk@oracle.com, 
	David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1824124380.20141219141645@eikelenboom.it>
In-Reply-To: <1824124380.20141219141645@eikelenboom.it>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events
 don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Sander,
	Found the root cause now, but still need some time to find
a solution for this issue.
xen_smp_prepare_cpus() doesn't call:
	smpboot_setup_io_apic()->setup_IO_APIC()
So no irqdomain structure for IOAPIC created,  then mp_map_pin_to_irq()
fails at the very beginning.

The most simple solution is to revert following change, but it doesn't
seem the best solution. I will try to find a hook point to create
irqdomain for IOAPIC from xen_smp_prepare_cpus().
Regards!
Gerry

@@ -1034,13 +1035,8 @@ static int mp_map_pin_to_irq(u32 gsi, int idx,
int ioapic, int pin,
        struct irq_domain *domain = mp_ioapic_irqdomain(ioapic);
        struct mp_pin_info *info = mp_pin_info(ioapic, pin);

-       if (!domain) {
-               /*
-                * Provide an identity mapping of gsi == irq except on truly
-                * weird platforms that have non isa irqs in the first
16 gsis.
-                */
-               return gsi >= nr_legacy_irqs() ? gsi : gsi_top + gsi;
-       }
+       if (!domain)
+               return -1;

        mutex_lock(&ioapic_mutex);



On 2014/12/19 21:16, Sander Eikelenboom wrote:
> Hi,
> 
> When running under Xen, ACPI powerbutton events don't work anymore, 
> there is no reaction when pressing the powerbutton.
> 
> On baremetal everything works fine, acpid gets the event and the 
> machine powers down perfectly. The machine is an Intel NUC.
>  
> Bisection has lead to:
> 
> b81975eade8c6495f3c4d6746d22bdc95f617777 is the first bad commit
> commit b81975eade8c6495f3c4d6746d22bdc95f617777
> Author: Jiang Liu <jiang.liu@linux.intel.com>
> Date:   Mon Jun 9 16:20:11 2014 +0800
> 
>     x86, irq: Clean up irqdomain transition code
> 
>     Now we have completely switched to irqdomain, so clean up transition code
>     in IOAPIC drivers.
> 
>     Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>     Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>     Cc: Tony Luck <tony.luck@intel.com>
>     Cc: Joerg Roedel <joro@8bytes.org>
>     Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
>     Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>     Cc: Grant Likely <grant.likely@linaro.org>
>     Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>     Cc: Bjorn Helgaas <bhelgaas@google.com>
>     Cc: Randy Dunlap <rdunlap@infradead.org>
>     Cc: Yinghai Lu <yinghai@kernel.org>
>     Link: http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang.liu@linux.intel.com
>     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Reverting this specific commit on linux-tip (3.19-mw) gets things working again under Xen.
> Kernel .config is attached.
> 
> --
> Sander
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 13:48:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 13:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1xuo-0002kI-FS; Fri, 19 Dec 2014 13:48: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 1Y1xun-0002k8-H5
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 13:48:21 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	96/D9-15461-4AC24945; Fri, 19 Dec 2014 13:48:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418996900!16797642!1
X-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 9593 invoked from network); 19 Dec 2014 13:48:20 -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; 19 Dec 2014 13:48:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 13:48:19 +0000
Message-Id: <54943AB20200007800051059@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 13:48:18 +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>
Subject: [Xen-devel] patch ping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

any word on
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01253.html
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01370.html
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01485.html
sent several days ago (there were more earlier today) for 4.5?

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 Dec 19 13:48:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 13:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1xuo-0002kI-FS; Fri, 19 Dec 2014 13:48: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 1Y1xun-0002k8-H5
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 13:48:21 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	96/D9-15461-4AC24945; Fri, 19 Dec 2014 13:48:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1418996900!16797642!1
X-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 9593 invoked from network); 19 Dec 2014 13:48:20 -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; 19 Dec 2014 13:48:20 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 13:48:19 +0000
Message-Id: <54943AB20200007800051059@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 13:48:18 +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>
Subject: [Xen-devel] patch ping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

any word on
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01253.html
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01370.html
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01485.html
sent several days ago (there were more earlier today) for 4.5?

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 Dec 19 14:52:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 14:52:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1yu3-0004va-QV; Fri, 19 Dec 2014 14:51:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Y1yu3-0004vV-AK
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 14:51:39 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	CD/73-29352-A7B34945; Fri, 19 Dec 2014 14:51:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1419000696!14340550!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 1224 invoked from network); 19 Dec 2014 14:51:37 -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 Dec 2014 14:51:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,607,1413244800"; d="scan'208";a="206743611"
Message-ID: <54943B75.4090703@citrix.com>
Date: Fri, 19 Dec 2014 14:51: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>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>
References: <549436A8.1020303@citrix.com>
In-Reply-To: <549436A8.1020303@citrix.com>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: [Xen-devel] libxl memory leaks when Xen is compiled with XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Correctly CC'ing xen-devel as well this time

~Andrew

On 19/12/14 14:31, Andrew Cooper wrote:
> Hello,
>
> Coverity has identified a large number of memory leaks in libxl, because
> of the use of libxl_domain_info() without an init/dispose for the
> libxl_dominfo object.
>
> If XSM is active, this leaks the ssid_label string, and in almost all
> cases, from the successful completion of the library function in question.
>
> Most of the issues can be fixed with the correct use of
> init()/dispose(), but libxl_wait_for_memory_target() is a little more
> interesting.
>
> Strictly speaking, I think I would need to fix it with a
> dispose();init() pair immediately before the call to
> libxl_domain_info().  However, this feels like overkill.  As only the
> memory information is needed, would it be appropriate to downgrade to an
> xc_domain_getinfo() instead, forgoing the memory allocation and
> extraneous hypercalls?
>
> ~Andrew
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 14:52:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 14:52:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1yu3-0004va-QV; Fri, 19 Dec 2014 14:51:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Y1yu3-0004vV-AK
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 14:51:39 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	CD/73-29352-A7B34945; Fri, 19 Dec 2014 14:51:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1419000696!14340550!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 1224 invoked from network); 19 Dec 2014 14:51:37 -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 Dec 2014 14:51:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,607,1413244800"; d="scan'208";a="206743611"
Message-ID: <54943B75.4090703@citrix.com>
Date: Fri, 19 Dec 2014 14:51: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>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>
References: <549436A8.1020303@citrix.com>
In-Reply-To: <549436A8.1020303@citrix.com>
X-DLP: MIA1
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: [Xen-devel] libxl memory leaks when Xen is compiled with XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Correctly CC'ing xen-devel as well this time

~Andrew

On 19/12/14 14:31, Andrew Cooper wrote:
> Hello,
>
> Coverity has identified a large number of memory leaks in libxl, because
> of the use of libxl_domain_info() without an init/dispose for the
> libxl_dominfo object.
>
> If XSM is active, this leaks the ssid_label string, and in almost all
> cases, from the successful completion of the library function in question.
>
> Most of the issues can be fixed with the correct use of
> init()/dispose(), but libxl_wait_for_memory_target() is a little more
> interesting.
>
> Strictly speaking, I think I would need to fix it with a
> dispose();init() pair immediately before the call to
> libxl_domain_info().  However, this feels like overkill.  As only the
> memory information is needed, would it be appropriate to downgrade to an
> xc_domain_getinfo() instead, forgoing the memory allocation and
> extraneous hypercalls?
>
> ~Andrew
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 14:52:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 14:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1yul-0005HO-9k; Fri, 19 Dec 2014 14:52:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1Y1yuj-0005HD-Qk
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 14:52:22 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AA/2A-15461-5AB34945; Fri, 19 Dec 2014 14:52:21 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1419000739!9488555!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_DONG,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7513 invoked from network); 19 Dec 2014 14:52:19 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 14:52:19 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so2174134wiw.1
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 06:52: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=CThKS4kKw34caIaDbMTL0s2XahlrBWQbhyfKfwm/LI8=;
	b=UnEDKXkNPmm8JZdB4KuMxpHa0K9r5m/kXvqp0ssAmsCUGUg0yF5v0znqx1gRIlnlhK
	0YCdLxUEGB+EeD+QHCw1+aIjWf/lAbkWXxnuS7dRgDcBteR/bIQVpXOo5ELLgcx+QaPS
	ZvdmQ3uMZs6oq/T/UCY1P7nGGUjVWYI2X+RkP72U3hFETri7nxF8JOC6ekFDy/8r1GT+
	Fqu1Jll8Tp2/wqVDk+ZlXprxNp2E9bfpT1q2Rr0rCqThAWJUhSQMl1TGhZ/Z/L0eio6c
	58XQAdaRiHDKxH9re0U8nLWHLOUlst74nv4Qa5Zx4I5QfrVwOuLWta0M1TQhEQgofeCq
	qUKQ==
X-Received: by 10.194.216.170 with SMTP id or10mr15568654wjc.96.1419000739110; 
	Fri, 19 Dec 2014 06:52:19 -0800 (PST)
Received: from [192.168.0.25] (97e5a0c2.skybroadband.com. [151.229.160.194])
	by mx.google.com with ESMTPSA id jp3sm2610382wid.9.2014.12.19.06.52.14
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 19 Dec 2014 06:52:17 -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: <20141216161352.504FA124EF2@laptop.dumpdata.com>
Date: Fri, 19 Dec 2014 14:52:12 +0000
Message-Id: <322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Russ Pavlicek <russell.pavlicek@xenproject.org>,
	Sarah Conway <sconway@linuxfoundation.org>
X-Mailer: Apple Mail (2.1878.6)
Cc: artem Mygaiev <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,
	Arianna Avanzini <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, olaf@aepfle.de, 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,
	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 Development Update (RC4) - Documentation
	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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

in preparation for the release we need to update some wiki pages, as well a=
s in-tree docs

First of all, any new features for which any of you have written new wiki p=
ages should be marked with [[Category:Xen 4.5]]. Either do this, or reply w=
ith URLs to pages and I will do so =


Otherwise, I created boilerplate pages for various pages and tracked the st=
atus on http://wiki.xenproject.org/wiki/Category:Xen_4.5

@Russell: you may want to update the XM to XL pages or create a new one and=
 add your video

=3D=3D The following pages need to be reviewed and updated =3D=3D
* {{NotDone}} [[Linux PVH]]: =

** Add PVH Dom0 information =

** Review/correct the '''Things that are broken''' section
** Review/correct the '''Items that have not been tested extensively or at =
all'''

* {{NotDone}} [[Xen ARM with Virtualization Extensions]] =

** supported platforms need to be updated and =

** all platforms that are supported in 4.5 tagged appropriately with [[Cate=
gory:Xen 4.5]]

=3D=3D Lars will fix =3D=3D
* {{NotDone}} [[Xen Project 4.5 Acknowledgements]] =

** Lars will do this.  =


* {{NotDone}} [[Xen Project 4.5 Feature List]] =

** Lars will copy from the blog announcement when ready (Sarah is currently=
 making some final changes)

=3D=3D For Konrad and others =3D=3D
* {{NotDone}} [[Xen Project Release Features]] - main 4.5 features need to =
be added. =


Please reply to the thread and I will add that page.
** The key changes normally are changes to scalability/memory/etc. limits -=
 maybe Jan(x86) and Ian(ARM) can look let me know of changes
** Also new platforms, changes to experimental features, etc. =

** Probably the new scheduler should be added - is there a wiki page?
** Any other major new features that are worth highlighting? I can go throu=
gh the press release and the release note

* {{NotDone}} [[Xen Project 4.5 Release Notes]] - needs to be created =

** http://wiki.xenproject.org/wiki/Xen_Project_4.4_Release_Notes were prett=
y lightweight =

** I think we should keep it that way. We should probably mainly focus on k=
nown issues
@Konrad: what's your view?

=3D=3D Missing pages =3D=3D
* {{NotDone}} [[Xen Project 4.5 Man Pages]] =

** need to clone [[Xen Project 4.4 Man Pages]] and point to the correct bra=
nch when the 4.5 branch has been created
** if there are new documented features in in-tree docs then add them
** if there are irrelevant features such as XM, remove links to docs (proba=
bly the docs should be removed from the git tree also)

Cheers
Lars

On 16 Dec 2014, at 16:13, konrad.wilk@oracle.com wrote:

> Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
> we have the General Release on Jan 7th!
> =

> Details for the test-day are at
> =

> http://wiki.xen.org/wiki/Xen_4.5_RC4_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>' ar=
e not owned by pciback or pcistub will still launch.
> #28 support PCI hole resize in qemu-xen
> =

> [ 'mmio_hole' fix it, but the ultimate way is to fix it in QEMU]
> =

> #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_susp=
end?"
> #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
> #46 qemu-upstream: limitation on 4 emulated NICs prevents guest from star=
ting unless PV override is used.
> =

> =3D Timeline =3D
> =

> We wer planning on a 9-month release cycle - but it is more like an
> 10 month.  Based on that, below are the estimated dates:
> =

> =

> * Feature Freeze: 24th September 2014
> * First RC: 24th October [Friday!]
> * RC2: Nov 11th
> * RC2 Test-day: Nov 13th
> * RC3: Dec 3rd.
> * RC3 Test-day: Dec 4th
> * RC4: Dec 15th
> =

> <=3D=3D=3D=3D WE ARE HERE =3D=3D=3D>
> =

> * RC4 Test-day: Dec 17th
> =

> Release Date: Jan 7th.
> =

> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.
> =

> 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 Bug Fixes =3D
> =

> 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.
> =

> 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
> =

> =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
> =

> =3D=3D FreeBSD =3D=3D
> =

> *  PVH FreeBSD dom0 (ok)
>   FreeBSD 11 goal. Toolstack side done in Xen 4.5
>  -  Roger Pau Monn=E9
> =

> =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
> =

> *  xc_reserved_device_memory_map in hvmloader to avoid conflicting MMIO/R=
AM (good)
>   v7 posted.
>   Treating pieces as bug-fixes only.
>   Low likehood of making it in Xen 4.5. Deferred
>  -  Tiejun Chen
> =

> *  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
> =

> *  HT enabled with credit has 7.9 per perf drop. (none)
>   kernbench demonstrated it
>   http://www.gossamer-threads.com/lists/xen/devel/339409
>   This has existed since credit1 introduction.
>  -  Dario Faggioli
> =

> =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 -> va=
r/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-leve=
lling-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.h=
tml
>  -  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 spl=
it 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=E9
> =

> *  PVH - Migration of guests from a PVH dom0  (none)
>   Depends on migration2 code
>  -  Roger Pau Monn=E9
> =

> *  ucode=3Dscan also scan compressed initramfs (none)
>  -  Konrad Rzeszutek Wilk
> =

> *  adjust log buffer based on memmap size (none)
>  -  Konrad Rzeszutek Wilk
> =

> =3D=3D Deferred to Linux's after Xen 4.6 =3D=3D
> =

> *  Linux ARM - Device assigment usage in Linux code (arch/arm) non-PCI (n=
one)
>   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 de=
fault in xl.conf.  For example, if we could have a default "backend" parame=
ter for vifs, then it would be easy to switch back and forth between a back=
end 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. (n=
one)
> =

> =3D=3D Completed =3D=3D
> =

> =3D=3D Hypervisor =3D=3D
> =

> *  Regression in PCI passthrough of INTx legacy devices can trigger list =
corruption (good)
>   Sander reported it. Two different types of patches available.
>  -  Konrad Rzeszutek Wilk
> =

> *  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 e=
xcept 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 m=
aster)
> =

> *  fix vmce_amd* functions, unify mce_amd mcheck initialization (fixes/cl=
eanups)
> =

> *  multiple AMD container files appended together in initrd (early initra=
mfs)
>  -  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
> =

> *  pygrub does not handle certain configurations. (done)
>   went in after RC3
>  -  Andrew Cooper and Boris Ostrovsky
> =

> *  regression libxl bitmap handling during a restore.
>  -  Boris Ostrovsky and Wei Liu
>  -  done
> =

> *  Systemd integration (done)
>   Affects CentOS7, SLES12, Fedora Core 21 and Debian Jessie. Xen source c=
ontains systemd files that can be used to configure the various run-time se=
rvices. 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 b=
eing 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 (do=
ne)
>  -  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
> =

> *  vAPIC in PVHVM guests (Linux side) (done)
>   Going in for 3.19
>  -  Boris Ostrovsky
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 19 14:52:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 14:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1yul-0005HO-9k; Fri, 19 Dec 2014 14:52:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1Y1yuj-0005HD-Qk
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 14:52:22 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AA/2A-15461-5AB34945; Fri, 19 Dec 2014 14:52:21 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1419000739!9488555!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_DONG,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7513 invoked from network); 19 Dec 2014 14:52:19 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 14:52:19 -0000
Received: by mail-wi0-f174.google.com with SMTP id h11so2174134wiw.1
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 06:52: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=CThKS4kKw34caIaDbMTL0s2XahlrBWQbhyfKfwm/LI8=;
	b=UnEDKXkNPmm8JZdB4KuMxpHa0K9r5m/kXvqp0ssAmsCUGUg0yF5v0znqx1gRIlnlhK
	0YCdLxUEGB+EeD+QHCw1+aIjWf/lAbkWXxnuS7dRgDcBteR/bIQVpXOo5ELLgcx+QaPS
	ZvdmQ3uMZs6oq/T/UCY1P7nGGUjVWYI2X+RkP72U3hFETri7nxF8JOC6ekFDy/8r1GT+
	Fqu1Jll8Tp2/wqVDk+ZlXprxNp2E9bfpT1q2Rr0rCqThAWJUhSQMl1TGhZ/Z/L0eio6c
	58XQAdaRiHDKxH9re0U8nLWHLOUlst74nv4Qa5Zx4I5QfrVwOuLWta0M1TQhEQgofeCq
	qUKQ==
X-Received: by 10.194.216.170 with SMTP id or10mr15568654wjc.96.1419000739110; 
	Fri, 19 Dec 2014 06:52:19 -0800 (PST)
Received: from [192.168.0.25] (97e5a0c2.skybroadband.com. [151.229.160.194])
	by mx.google.com with ESMTPSA id jp3sm2610382wid.9.2014.12.19.06.52.14
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 19 Dec 2014 06:52:17 -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: <20141216161352.504FA124EF2@laptop.dumpdata.com>
Date: Fri, 19 Dec 2014 14:52:12 +0000
Message-Id: <322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Russ Pavlicek <russell.pavlicek@xenproject.org>,
	Sarah Conway <sconway@linuxfoundation.org>
X-Mailer: Apple Mail (2.1878.6)
Cc: artem Mygaiev <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,
	Arianna Avanzini <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, olaf@aepfle.de, 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,
	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 Development Update (RC4) - Documentation
	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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

in preparation for the release we need to update some wiki pages, as well a=
s in-tree docs

First of all, any new features for which any of you have written new wiki p=
ages should be marked with [[Category:Xen 4.5]]. Either do this, or reply w=
ith URLs to pages and I will do so =


Otherwise, I created boilerplate pages for various pages and tracked the st=
atus on http://wiki.xenproject.org/wiki/Category:Xen_4.5

@Russell: you may want to update the XM to XL pages or create a new one and=
 add your video

=3D=3D The following pages need to be reviewed and updated =3D=3D
* {{NotDone}} [[Linux PVH]]: =

** Add PVH Dom0 information =

** Review/correct the '''Things that are broken''' section
** Review/correct the '''Items that have not been tested extensively or at =
all'''

* {{NotDone}} [[Xen ARM with Virtualization Extensions]] =

** supported platforms need to be updated and =

** all platforms that are supported in 4.5 tagged appropriately with [[Cate=
gory:Xen 4.5]]

=3D=3D Lars will fix =3D=3D
* {{NotDone}} [[Xen Project 4.5 Acknowledgements]] =

** Lars will do this.  =


* {{NotDone}} [[Xen Project 4.5 Feature List]] =

** Lars will copy from the blog announcement when ready (Sarah is currently=
 making some final changes)

=3D=3D For Konrad and others =3D=3D
* {{NotDone}} [[Xen Project Release Features]] - main 4.5 features need to =
be added. =


Please reply to the thread and I will add that page.
** The key changes normally are changes to scalability/memory/etc. limits -=
 maybe Jan(x86) and Ian(ARM) can look let me know of changes
** Also new platforms, changes to experimental features, etc. =

** Probably the new scheduler should be added - is there a wiki page?
** Any other major new features that are worth highlighting? I can go throu=
gh the press release and the release note

* {{NotDone}} [[Xen Project 4.5 Release Notes]] - needs to be created =

** http://wiki.xenproject.org/wiki/Xen_Project_4.4_Release_Notes were prett=
y lightweight =

** I think we should keep it that way. We should probably mainly focus on k=
nown issues
@Konrad: what's your view?

=3D=3D Missing pages =3D=3D
* {{NotDone}} [[Xen Project 4.5 Man Pages]] =

** need to clone [[Xen Project 4.4 Man Pages]] and point to the correct bra=
nch when the 4.5 branch has been created
** if there are new documented features in in-tree docs then add them
** if there are irrelevant features such as XM, remove links to docs (proba=
bly the docs should be removed from the git tree also)

Cheers
Lars

On 16 Dec 2014, at 16:13, konrad.wilk@oracle.com wrote:

> Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
> we have the General Release on Jan 7th!
> =

> Details for the test-day are at
> =

> http://wiki.xen.org/wiki/Xen_4.5_RC4_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>' ar=
e not owned by pciback or pcistub will still launch.
> #28 support PCI hole resize in qemu-xen
> =

> [ 'mmio_hole' fix it, but the ultimate way is to fix it in QEMU]
> =

> #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_susp=
end?"
> #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
> #46 qemu-upstream: limitation on 4 emulated NICs prevents guest from star=
ting unless PV override is used.
> =

> =3D Timeline =3D
> =

> We wer planning on a 9-month release cycle - but it is more like an
> 10 month.  Based on that, below are the estimated dates:
> =

> =

> * Feature Freeze: 24th September 2014
> * First RC: 24th October [Friday!]
> * RC2: Nov 11th
> * RC2 Test-day: Nov 13th
> * RC3: Dec 3rd.
> * RC3 Test-day: Dec 4th
> * RC4: Dec 15th
> =

> <=3D=3D=3D=3D WE ARE HERE =3D=3D=3D>
> =

> * RC4 Test-day: Dec 17th
> =

> Release Date: Jan 7th.
> =

> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.
> =

> 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 Bug Fixes =3D
> =

> 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.
> =

> 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
> =

> =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
> =

> =3D=3D FreeBSD =3D=3D
> =

> *  PVH FreeBSD dom0 (ok)
>   FreeBSD 11 goal. Toolstack side done in Xen 4.5
>  -  Roger Pau Monn=E9
> =

> =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
> =

> *  xc_reserved_device_memory_map in hvmloader to avoid conflicting MMIO/R=
AM (good)
>   v7 posted.
>   Treating pieces as bug-fixes only.
>   Low likehood of making it in Xen 4.5. Deferred
>  -  Tiejun Chen
> =

> *  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
> =

> *  HT enabled with credit has 7.9 per perf drop. (none)
>   kernbench demonstrated it
>   http://www.gossamer-threads.com/lists/xen/devel/339409
>   This has existed since credit1 introduction.
>  -  Dario Faggioli
> =

> =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 -> va=
r/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-leve=
lling-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.h=
tml
>  -  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 spl=
it 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=E9
> =

> *  PVH - Migration of guests from a PVH dom0  (none)
>   Depends on migration2 code
>  -  Roger Pau Monn=E9
> =

> *  ucode=3Dscan also scan compressed initramfs (none)
>  -  Konrad Rzeszutek Wilk
> =

> *  adjust log buffer based on memmap size (none)
>  -  Konrad Rzeszutek Wilk
> =

> =3D=3D Deferred to Linux's after Xen 4.6 =3D=3D
> =

> *  Linux ARM - Device assigment usage in Linux code (arch/arm) non-PCI (n=
one)
>   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 de=
fault in xl.conf.  For example, if we could have a default "backend" parame=
ter for vifs, then it would be easy to switch back and forth between a back=
end 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. (n=
one)
> =

> =3D=3D Completed =3D=3D
> =

> =3D=3D Hypervisor =3D=3D
> =

> *  Regression in PCI passthrough of INTx legacy devices can trigger list =
corruption (good)
>   Sander reported it. Two different types of patches available.
>  -  Konrad Rzeszutek Wilk
> =

> *  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 e=
xcept 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 m=
aster)
> =

> *  fix vmce_amd* functions, unify mce_amd mcheck initialization (fixes/cl=
eanups)
> =

> *  multiple AMD container files appended together in initrd (early initra=
mfs)
>  -  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
> =

> *  pygrub does not handle certain configurations. (done)
>   went in after RC3
>  -  Andrew Cooper and Boris Ostrovsky
> =

> *  regression libxl bitmap handling during a restore.
>  -  Boris Ostrovsky and Wei Liu
>  -  done
> =

> *  Systemd integration (done)
>   Affects CentOS7, SLES12, Fedora Core 21 and Debian Jessie. Xen source c=
ontains systemd files that can be used to configure the various run-time se=
rvices. 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 b=
eing 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 (do=
ne)
>  -  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
> =

> *  vAPIC in PVHVM guests (Linux side) (done)
>   Going in for 3.19
>  -  Boris Ostrovsky
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 19 14:55:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 14: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 1Y1yyD-0005VP-7P; Fri, 19 Dec 2014 14:55:57 +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 1Y1yyB-0005VI-Qr
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 14:55:56 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	6F/84-02702-B7C34945; Fri, 19 Dec 2014 14:55:55 +0000
X-Env-Sender: jiang.liu@linux.intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1419000947!16183137!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12354 invoked from network); 19 Dec 2014 14:55:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-9.tower-27.messagelabs.com with SMTP;
	19 Dec 2014 14:55:48 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 19 Dec 2014 06:52:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,607,1413270000"; 
	d="scan'208,223";a="626595180"
Received: from dunliu-mobl1.ccr.corp.intel.com (HELO [10.255.29.90])
	([10.255.29.90])
	by orsmga001.jf.intel.com with ESMTP; 19 Dec 2014 06:55:01 -0800
Message-ID: <54943C44.5080503@linux.intel.com>
Date: Fri, 19 Dec 2014 22:55:00 +0800
From: Jiang Liu <jiang.liu@linux.intel.com>
Organization: Intel
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>, konrad.wilk@oracle.com, 
	David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Thomas Gleixner <tglx@linutronix.de>
References: <1824124380.20141219141645@eikelenboom.it>
In-Reply-To: <1824124380.20141219141645@eikelenboom.it>
Content-Type: multipart/mixed; boundary="------------070406090201060806040107"
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events
 don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-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.
--------------070406090201060806040107
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Hi Sander,
	Could you please help to test attached patch? It works
on native but I have no Xen environment at hand.
Thanks!
Gerry

On 2014/12/19 21:16, Sander Eikelenboom wrote:
> Hi,
> 
> When running under Xen, ACPI powerbutton events don't work anymore, 
> there is no reaction when pressing the powerbutton.
> 
> On baremetal everything works fine, acpid gets the event and the 
> machine powers down perfectly. The machine is an Intel NUC.
>  
> Bisection has lead to:
> 
> b81975eade8c6495f3c4d6746d22bdc95f617777 is the first bad commit
> commit b81975eade8c6495f3c4d6746d22bdc95f617777
> Author: Jiang Liu <jiang.liu@linux.intel.com>
> Date:   Mon Jun 9 16:20:11 2014 +0800
> 
>     x86, irq: Clean up irqdomain transition code
> 
>     Now we have completely switched to irqdomain, so clean up transition code
>     in IOAPIC drivers.
> 
>     Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>     Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>     Cc: Tony Luck <tony.luck@intel.com>
>     Cc: Joerg Roedel <joro@8bytes.org>
>     Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
>     Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>     Cc: Grant Likely <grant.likely@linaro.org>
>     Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>     Cc: Bjorn Helgaas <bhelgaas@google.com>
>     Cc: Randy Dunlap <rdunlap@infradead.org>
>     Cc: Yinghai Lu <yinghai@kernel.org>
>     Link: http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang.liu@linux.intel.com
>     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Reverting this specific commit on linux-tip (3.19-mw) gets things working again under Xen.
> Kernel .config is attached.
> 
> --
> Sander
> 

--------------070406090201060806040107
Content-Type: text/x-patch;
 name="0001-x86-apic-Fix-xen-failure-caused-by-commit-b81975eade.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0001-x86-apic-Fix-xen-failure-caused-by-commit-b81975eade.pa";
 filename*1="tch"

>From a6928b3c93a5119c79b8a7aec953579c87d2a4cc Mon Sep 17 00:00:00 2001
From: Jiang Liu <jiang.liu@linux.intel.com>
Date: Fri, 19 Dec 2014 22:33:56 +0800
Subject: [PATCH] x86/apic: Fix xen failure caused by commit b81975eade8c

Commit b81975eade8c "x86, irq: Clean up irqdomain transition code"
breaks Xen because xen_smp_prepare_cpus() doesn't call setup_IO_APIC()
so mp_map_pin_to_irq() fails at the very beginning.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 arch/x86/include/asm/hw_irq.h        |    2 +-
 arch/x86/include/asm/smpboot_hooks.h |    6 +++---
 arch/x86/kernel/apic/apic.c          |    6 +++---
 arch/x86/kernel/apic/io_apic.c       |   32 +++++++++++++++-----------------
 arch/x86/xen/smp.c                   |    3 +++
 5 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 4615906d83df..0c6530dfd817 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -98,7 +98,7 @@ extern void trace_call_function_single_interrupt(void);
 #define IO_APIC_IRQ(x) (((x) >= NR_IRQS_LEGACY) || ((1<<(x)) & io_apic_irqs))
 extern unsigned long io_apic_irqs;
 
-extern void setup_IO_APIC(void);
+extern void setup_IO_APIC(bool xen_smp);
 extern void disable_IO_APIC(void);
 
 struct io_apic_irq_attr {
diff --git a/arch/x86/include/asm/smpboot_hooks.h b/arch/x86/include/asm/smpboot_hooks.h
index 0da7409f0bec..76e5731b03cb 100644
--- a/arch/x86/include/asm/smpboot_hooks.h
+++ b/arch/x86/include/asm/smpboot_hooks.h
@@ -52,9 +52,9 @@ static inline void __init smpboot_setup_io_apic(void)
 	 * Here we can be sure that there is an IO-APIC in the system. Let's
 	 * go and set it up:
 	 */
-	if (!skip_ioapic_setup && nr_ioapics)
-		setup_IO_APIC();
-	else {
+	if (!skip_ioapic_setup && nr_ioapics) {
+		setup_IO_APIC(false);
+	} else {
 		nr_ioapics = 0;
 	}
 #endif
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index ba6cc041edb1..33ba1f97abea 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1912,9 +1912,9 @@ int __init APIC_init_uniprocessor(void)
 	bsp_end_local_APIC_setup();
 
 #ifdef CONFIG_X86_IO_APIC
-	if (smp_found_config && !skip_ioapic_setup && nr_ioapics)
-		setup_IO_APIC();
-	else {
+	if (smp_found_config && !skip_ioapic_setup && nr_ioapics) {
+		setup_IO_APIC(false);
+	} else {
 		nr_ioapics = 0;
 	}
 #endif
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index a6745e756729..5879ac58c3b6 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2965,31 +2965,29 @@ static int mp_irqdomain_create(int ioapic)
 	return 0;
 }
 
-void __init setup_IO_APIC(void)
+void __init setup_IO_APIC(bool xen_smp)
 {
 	int ioapic;
 
-	/*
-	 * calling enable_IO_APIC() is moved to setup_local_APIC for BP
-	 */
-	io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
+	if (!xen_smp) {
+		apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
+		io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
+
+		/* Set up IO-APIC IRQ routing. */
+		x86_init.mpparse.setup_ioapic_ids();
+		sync_Arb_IDs();
+	}
 
-	apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
 	for_each_ioapic(ioapic)
 		BUG_ON(mp_irqdomain_create(ioapic));
-
-	/*
-         * Set up IO-APIC IRQ routing.
-         */
-	x86_init.mpparse.setup_ioapic_ids();
-
-	sync_Arb_IDs();
 	setup_IO_APIC_irqs();
-	init_IO_APIC_traps();
-	if (nr_legacy_irqs())
-		check_timer();
-
 	ioapic_initialized = 1;
+
+	if (!xen_smp) {
+		init_IO_APIC_traps();
+		if (nr_legacy_irqs())
+			check_timer();
+	}
 }
 
 /*
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 4c071aeb8417..7eb0283901fa 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -326,7 +326,10 @@ static void __init xen_smp_prepare_cpus(unsigned int max_cpus)
 
 		xen_raw_printk(m);
 		panic(m);
+	} else {
+		setup_IO_APIC(true);
 	}
+
 	xen_init_lock_cpu(0);
 
 	smp_store_boot_cpu_info();
-- 
1.7.10.4


--------------070406090201060806040107
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------070406090201060806040107--


From xen-devel-bounces@lists.xen.org Fri Dec 19 14:55:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 14: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 1Y1yyD-0005VP-7P; Fri, 19 Dec 2014 14:55:57 +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 1Y1yyB-0005VI-Qr
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 14:55:56 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	6F/84-02702-B7C34945; Fri, 19 Dec 2014 14:55:55 +0000
X-Env-Sender: jiang.liu@linux.intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1419000947!16183137!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12354 invoked from network); 19 Dec 2014 14:55:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-9.tower-27.messagelabs.com with SMTP;
	19 Dec 2014 14:55:48 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 19 Dec 2014 06:52:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,607,1413270000"; 
	d="scan'208,223";a="626595180"
Received: from dunliu-mobl1.ccr.corp.intel.com (HELO [10.255.29.90])
	([10.255.29.90])
	by orsmga001.jf.intel.com with ESMTP; 19 Dec 2014 06:55:01 -0800
Message-ID: <54943C44.5080503@linux.intel.com>
Date: Fri, 19 Dec 2014 22:55:00 +0800
From: Jiang Liu <jiang.liu@linux.intel.com>
Organization: Intel
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>, konrad.wilk@oracle.com, 
	David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
	Thomas Gleixner <tglx@linutronix.de>
References: <1824124380.20141219141645@eikelenboom.it>
In-Reply-To: <1824124380.20141219141645@eikelenboom.it>
Content-Type: multipart/mixed; boundary="------------070406090201060806040107"
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events
 don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-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.
--------------070406090201060806040107
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Hi Sander,
	Could you please help to test attached patch? It works
on native but I have no Xen environment at hand.
Thanks!
Gerry

On 2014/12/19 21:16, Sander Eikelenboom wrote:
> Hi,
> 
> When running under Xen, ACPI powerbutton events don't work anymore, 
> there is no reaction when pressing the powerbutton.
> 
> On baremetal everything works fine, acpid gets the event and the 
> machine powers down perfectly. The machine is an Intel NUC.
>  
> Bisection has lead to:
> 
> b81975eade8c6495f3c4d6746d22bdc95f617777 is the first bad commit
> commit b81975eade8c6495f3c4d6746d22bdc95f617777
> Author: Jiang Liu <jiang.liu@linux.intel.com>
> Date:   Mon Jun 9 16:20:11 2014 +0800
> 
>     x86, irq: Clean up irqdomain transition code
> 
>     Now we have completely switched to irqdomain, so clean up transition code
>     in IOAPIC drivers.
> 
>     Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>     Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>     Cc: Tony Luck <tony.luck@intel.com>
>     Cc: Joerg Roedel <joro@8bytes.org>
>     Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
>     Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>     Cc: Grant Likely <grant.likely@linaro.org>
>     Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>     Cc: Bjorn Helgaas <bhelgaas@google.com>
>     Cc: Randy Dunlap <rdunlap@infradead.org>
>     Cc: Yinghai Lu <yinghai@kernel.org>
>     Link: http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang.liu@linux.intel.com
>     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Reverting this specific commit on linux-tip (3.19-mw) gets things working again under Xen.
> Kernel .config is attached.
> 
> --
> Sander
> 

--------------070406090201060806040107
Content-Type: text/x-patch;
 name="0001-x86-apic-Fix-xen-failure-caused-by-commit-b81975eade.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0001-x86-apic-Fix-xen-failure-caused-by-commit-b81975eade.pa";
 filename*1="tch"

>From a6928b3c93a5119c79b8a7aec953579c87d2a4cc Mon Sep 17 00:00:00 2001
From: Jiang Liu <jiang.liu@linux.intel.com>
Date: Fri, 19 Dec 2014 22:33:56 +0800
Subject: [PATCH] x86/apic: Fix xen failure caused by commit b81975eade8c

Commit b81975eade8c "x86, irq: Clean up irqdomain transition code"
breaks Xen because xen_smp_prepare_cpus() doesn't call setup_IO_APIC()
so mp_map_pin_to_irq() fails at the very beginning.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 arch/x86/include/asm/hw_irq.h        |    2 +-
 arch/x86/include/asm/smpboot_hooks.h |    6 +++---
 arch/x86/kernel/apic/apic.c          |    6 +++---
 arch/x86/kernel/apic/io_apic.c       |   32 +++++++++++++++-----------------
 arch/x86/xen/smp.c                   |    3 +++
 5 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 4615906d83df..0c6530dfd817 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -98,7 +98,7 @@ extern void trace_call_function_single_interrupt(void);
 #define IO_APIC_IRQ(x) (((x) >= NR_IRQS_LEGACY) || ((1<<(x)) & io_apic_irqs))
 extern unsigned long io_apic_irqs;
 
-extern void setup_IO_APIC(void);
+extern void setup_IO_APIC(bool xen_smp);
 extern void disable_IO_APIC(void);
 
 struct io_apic_irq_attr {
diff --git a/arch/x86/include/asm/smpboot_hooks.h b/arch/x86/include/asm/smpboot_hooks.h
index 0da7409f0bec..76e5731b03cb 100644
--- a/arch/x86/include/asm/smpboot_hooks.h
+++ b/arch/x86/include/asm/smpboot_hooks.h
@@ -52,9 +52,9 @@ static inline void __init smpboot_setup_io_apic(void)
 	 * Here we can be sure that there is an IO-APIC in the system. Let's
 	 * go and set it up:
 	 */
-	if (!skip_ioapic_setup && nr_ioapics)
-		setup_IO_APIC();
-	else {
+	if (!skip_ioapic_setup && nr_ioapics) {
+		setup_IO_APIC(false);
+	} else {
 		nr_ioapics = 0;
 	}
 #endif
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index ba6cc041edb1..33ba1f97abea 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1912,9 +1912,9 @@ int __init APIC_init_uniprocessor(void)
 	bsp_end_local_APIC_setup();
 
 #ifdef CONFIG_X86_IO_APIC
-	if (smp_found_config && !skip_ioapic_setup && nr_ioapics)
-		setup_IO_APIC();
-	else {
+	if (smp_found_config && !skip_ioapic_setup && nr_ioapics) {
+		setup_IO_APIC(false);
+	} else {
 		nr_ioapics = 0;
 	}
 #endif
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index a6745e756729..5879ac58c3b6 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2965,31 +2965,29 @@ static int mp_irqdomain_create(int ioapic)
 	return 0;
 }
 
-void __init setup_IO_APIC(void)
+void __init setup_IO_APIC(bool xen_smp)
 {
 	int ioapic;
 
-	/*
-	 * calling enable_IO_APIC() is moved to setup_local_APIC for BP
-	 */
-	io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
+	if (!xen_smp) {
+		apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
+		io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
+
+		/* Set up IO-APIC IRQ routing. */
+		x86_init.mpparse.setup_ioapic_ids();
+		sync_Arb_IDs();
+	}
 
-	apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
 	for_each_ioapic(ioapic)
 		BUG_ON(mp_irqdomain_create(ioapic));
-
-	/*
-         * Set up IO-APIC IRQ routing.
-         */
-	x86_init.mpparse.setup_ioapic_ids();
-
-	sync_Arb_IDs();
 	setup_IO_APIC_irqs();
-	init_IO_APIC_traps();
-	if (nr_legacy_irqs())
-		check_timer();
-
 	ioapic_initialized = 1;
+
+	if (!xen_smp) {
+		init_IO_APIC_traps();
+		if (nr_legacy_irqs())
+			check_timer();
+	}
 }
 
 /*
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 4c071aeb8417..7eb0283901fa 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -326,7 +326,10 @@ static void __init xen_smp_prepare_cpus(unsigned int max_cpus)
 
 		xen_raw_printk(m);
 		panic(m);
+	} else {
+		setup_IO_APIC(true);
 	}
+
 	xen_init_lock_cpu(0);
 
 	smp_store_boot_cpu_info();
-- 
1.7.10.4


--------------070406090201060806040107
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------070406090201060806040107--


From xen-devel-bounces@lists.xen.org Fri Dec 19 15:14:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15: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 1Y1zFW-000650-UC; Fri, 19 Dec 2014 15:13: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 1Y1zFW-00064v-2y
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 15:13:50 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	B8/F3-29352-DA044945; Fri, 19 Dec 2014 15:13:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1419002028!8961974!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26201 invoked from network); 19 Dec 2014 15:13:48 -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; 19 Dec 2014 15:13:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 15:13:47 +0000
Message-Id: <54944EBA02000078000510BF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 15:13:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1418952066-21064-1-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1418952066-21064-1-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] RMRR Fix Design for Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.12.14 at 02:21, <tiejun.chen@intel.com> wrote:
> #4 Something like USB, is still restricted to current RMRR implementation. We
>    should work out this case.

This can mean all or nothing. My understanding is that right now code
assumes that USB devices won't use their RMRR-specified memory
regions post-boot (kind of contrary to your earlier statement that in
such a case the regions shouldn't be listed in RMRRs in the first place).

> Design Overview
> ===============
> 
> First of all we need to make sure all resources don't overlap RMRR. And then
> in case of shared ept, we can set these identity entries. And Certainly we 
> will
> group all devices associated to one same RMRR entry, then make sure all 
> group
> devices should be assigned to same VM.
> 
> 1. Setup RMRR identity mapping
> 
> current status:
>     * identity mapping only setup in non-shared ept case
> 
> proposal:
> 
> In non-shared ept case, IOMMU stuff always set those entries and RMRR is 
> already marked reserved in host so its fine enough.

Is it? Where? Or am I misunderstanding the whole statement, likely
due to me silently replacing "host" by "guest" (since reservation in
host address spaces is of no interest here afaict)?

> But in shared ept case, we need to
> check any conflit, so we should follow up
> 
>   - gfn space unoccupied
>         -> insert mapping: success.
>             gfn:_mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct, p2m_access_rw
>   - gfn space already occupied by 1:1 RMRR mapping
>         -> do nothing; success.
>   - gfn space already occupied by other mapping
>         -> fail.
> 
> expectation:
>     * only devices w/ non-conflicting RMRR can be assigned
>     * fortunately this achieves the very initial intention to support IGD
>       pass-through on BDW

Are you trying to say here that doing the above is all you need for
your specific machine? If so, that's clearly not something to go into
a design document.

Also there's clearly an alternative proposal: Drop support for sharing
page tables. Your colleagues will surely have told you that we've
been considering this for quite some time, and had actually hoped
for them to do the necessary VT-d side work to allow for this without
causing performance regressions.

> 2.1 Expose RMRR to user space
> 
> current status:
>     * Xen always record RMRR info into one list, acpi_rmrr_units, while 
> parsing
>       acpi. So we can retrieve these info by lookup that list.
> 
> proposal:
>     * RMRR would be exposed by a new hypercall, which Jan already finished 
> in
>       current version but just expose all RMRR info unconditionally.
>     * Furthermore we can expose RMRR on demand to diminish shrinking guest
>       RAM/MMIO space.
>     * So we will introduce a new parameter, 'rdm_forcecheck' and to 
> collaborate
>       with SBDFs to control which RMRR should be exposed:
> 
>         - We can set this parameter in .cfg file like,
> 
>             rdm_forcecheck = 1 => Of course this should be 0 by default.
> 
>         '1' means we should force check to reserve all ranges 
> unconditionally.
>         and 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.
> 
>         If 0, we just check those assigned pci devices. As you know we already

assigned? Wasn't the plan to have a separate potentially-to-be-
assigned list? And I can only re-iterate that the name
"rdm_forcecheck" doesn't really express what you mean. Since
your intention is to check all devices (rather than do a check that
otherwise wouldn't be done), "rdm_all" or "rdm_check_all" would
seem closer to the intended behavior.

>         have such an existing hypercall to assign PCI devices, looks we can 
> work
>         directly under this hypercall to get that necessary SBDF to sort 
> which
>         RMRR should be handled. But obviously, we need to get these info 
> before
>         we populate guest memory to make sure these RMRR ranges should be
>         excluded from guest memory. But unfortunately the memory populating
>         takes place before a device assignment, so we can't live on that
>         directly.
> 
>         But as we discussed it just benefit that assigned case to reorder 
> that
>         order, but not good to hotplug case. So we have to introduce a new
>         DOMCTL to pass that global parameter with SBDF at the same time.
> 
>         For example, if we own these two RMRR entries,

"own" is confusing here, I assume you mean if there are such entries.

>         [00:14.0]    RMRR region: base_addr ab80a000 end_address ab81dfff
>         [00:02.0]    RMRR region: base_addr ad000000 end_address af7fffff
> 
>         If 'rdm_forcecheck = 1', any caller to that hypercall may get these two

s/may/will/ I suppose.

>         entries. But if 'rdm_forcecheck = 0', and in .cfg file,
> 
>         #1 'pci=[00:14.0, 00:02.0]' -> The caller still get these two entries.
>         #2 'pci=[00:02.0]' -> The caller just get one entry, 
> 0xad000000:0xaf7fffff
>         #2 'pci=[00:14.0]' -> The caller just get one entry, 
> 0xab80a000:0xab81dfff
>         #4 'pci=[others]' or no any pci configuration -> The caller get 
> nothing.

Oh, interesting, you dropped the idea of a separate list of possibly-
to-be-assigned devices. Why that?

>         And ultimately, if we expose any RMRR entry at gfn,
> 
>         in non-shared ept case, 
> 
>         p2m table:  valid non-identity mapping, gfn:mfn != 1:1

This would mean ...

>         VT-D table: no such a mapping until set identity mapping,
>                     gfn:_mfn(gfn) == 1:1 when we have a associated device
>                     assignment.

... the two mappings to go out of sync when such a 1:1 mapping gets
established. I think we should avoid such a situation if at all possible.

>         in shared ept case,
> 
>         p2m table\VT-D table:  always INVALID until set identity mapping,
>                                gfn:_mfn(gfn) == 1:1 when we have a 
> associated
>                                device assignment.
> 
>         But if we don't expose any RMRR entry,
> 
>         in non-shared ept case, 
> 
>         p2m table:  valid non-identity mapping, gfn:mfn != 1:1
>         VT-D table: no such a mapping until set identity mapping,
>                     gfn:_mfn(gfn) == 1:1 when we have a associated device
>                     assignment.
> 
>         in shared ept case,
> 
>         p2m table\VT-D table:  If guest RAM already cover gfn, we have sunc a
>                                valid non-identity mapping, gfn:mfn != 1:1, 
> but
>                                we can't set any identity mapping again then
>                                that associated device can't be assigned
>                                successfully. If not, we'll set identity 
> mapping,
>                                gfn:_mfn(gfn) == 1:1, to work well.

So in the end we'd still have various cases of different behavior,
when really it would be much better (if not a requirement) if guest
observable behavior wouldn't depend on implementation details
like (non-)shared page tables.

> 2.2 Detect and avoid RMRR conflictions with guest RAM/MMIO
> 
> current status:
>     * Currently Xen doesn't detect anything to avoid any conflict.
> 
> proposal:
>     * We need to cover all points to check any conflict. Below lists places
>       where reserved region conflictions should be detected:
> 
>         1>. libxc:setup_guest():modules_init()
> 
>         There are some modules, like acpi_module and smbios_module. They may
>         occupy some ranges so we need to check if they're conflicting with
>         all ranges from that new hypercall above.

I'm missing of what conflict resolution you expect to do here.
Following earlier discussion in the context of patch review made
pretty clear that this isn't really straightforward, having the
potential to prevent a guest from booting (e.g. when the virtual
BIOS conflicts with an RMRR).

>         2>. libxc:setup_guest():xc_domain_populate_physmap()
> 
>         There are two ways to exclude RMRR ranges here:
>             
>             #1 Before we populate guest RAM without any RMRR range from that
>                new hypercall to skip RMRR ranges when populating guest RAM.
>             #2 In Xen we can fliter RMRR range while calling
>                XENMEM_populate_physmap, its no change to libxc, but skip
>                setting p2m entry for RMRR ranges in Xen hypervisor
> 
>         But to compare #1, #2 is not better since Xen still allocate those
>         range, and we have to sync somewhere else in Xen. And #1 is cleaner
>         because #2 actually shrinks the available memory size to the guest.
> 
>         3>. hvmloader:pci_setup()
> 
>         Here we should populate guest MMIO excluding all ranges from that 
> new
>         hypercall to detect RMRR conflictions for allocating PCI MMIO BAR.
> 
>         4>. hvmloader:mem_hole_alloc()
> 
>         Here we should populate mem holw excluding all ranges from that new
>         hypercall to detect RMRR conflictions for dynamic allocation in
>         hvmloader, e.g. as used for IGD opregion
> 
>         5>. hvmloader:build_e820_table():
> 
>         Finally we need let VM know that RMRR regions are reserved through 
> e820
>         table
> 
>     Its a little bit tricky to handle this inside hvmloader since as you 
> know,
>     struct hvm_info_table is only a approach between libxc and hvmloader. 
> But
>     however, making up all above places will bring some duplicated logic.
>     Especially between libxc and hvmloader, which skip same regions in guest
>     physical layer(one in populating guest RAM, the other in constructing 
> e820)
>     But current design has some limitation to pass information between libxc 
> and
>     hvmloader,
> 
> struct hvm_info_table {
>     ...
>     /*
>      *  0x0 to page_to_phys(low_mem_pgend)-1:
>      *    RAM below 4GB (except for VGA hole 0xA0000-0xBFFFF)
>      */
>     uint32_t    low_mem_pgend;
>     ...
>     /*
>      *  0x100000000 to page_to_phys(high_mem_pgend)-1:
>      *    RAM above 4GB
>      */
>     uint32_t    high_mem_pgend;
>     ...
> }
> 
>     nothing valuable is passed to hvmloader so we have to figure out a way 
> to
>     handle those points in hvmloader. Currently,
> 
>             #1 Reconstruct hvm_info_table{}
> 
>             We can store all necessary RMRR info into hvm_info_table as 
> well,
>             then we can pick them conveniently but oftentimes these RMRR
>             entries are scattered and the number is also undertimined, so 
> its
>             a little bit ugly to do.
> 
>             #2 Xenstore
> 
>             We may store all necessary RMRR info as Xenstore then pick them 
> in
>             hvmloader.
> 
>             #3 A hypercall
> 
>             We may have to call our new hypercall again to pick them, but
>             obviously this may introduce some duplicated codes.
> 
>             #4 XENMEM_{set_,}memory_map pair of hypercalls
>             
>             As Jan commented it "could be used(and is readily available to 
> be
>             extended that way, since for HVM domains XENMEM_set_memory_map
>             returns -EPERM at present). The only potentially problematic 
> aspect
>             I can see with using it might be its limiting of the entry count 
> to
>             E820MAX." So a preparation patch is required before RMRR, and
>             hvmloader still needs to query RMRR information.

Somewhere above I'm missing the mentioning of the option to reorder
operations of hvmloader, to e.g. base PCI BAR assignment on the
previously set up E820 table, rather than assuming a (mostly) fixed
size window where to put these.

> 3. Group multiple devices sharing same RMRR entry
> 
> current status:
>     * Xen doesn't distinguish if multiple devices share same RMRR entry. 
> This
>       may lead a leak to corruption, e.g. Device A and device B share same 
> entry
>       and then device A is assigned to domain A, device B is assigned to 
> domain
>       B. So domain A can read something from that range, even rewrite
>       maliciously that range to corrupt device B inside domain B.
> 
> proposal:
>     * We will group all devices by means of one same RMRR entry. 
> Theoretically,
>       we should make sure all devices in one group are allowed to assign to 
> one
>       VM. But in Xen side the hardware domain owns all devices at first, we
>       should unbound all group devies before assign one of group device. But 
> its
>       hard to do such thing in current VT-d stuff. And actually its rare to 
> have
>       the group device in real world so we just prevent assigning any group
>       device simply.
>     * We will introduce two field, gid, in struct, acpi_rmrr_unit:
>         gid: indicate if this device belongs a group.
>       Then when we add or attach device in iommu side, we will check this 
> field
>       if we're assigning a group device then determine if we assign that.
> 
> 
> expectation:
>     * Make all device associated to one RMRR to be assigned same VM.

A few lines up you say you're intending to refuse such assignments
rather than making them happen in a consistent way - what's the
plan in the end?

> 4. Handle in case of force accessing to RMRR regions
> 
> proposal:
>     * Although we already reserve these ranges in guest e820 table, its
>       possible to access these ranges.
>       In non-shared ept case it will issue such EPT violation since we have 
> no
>       p2m table actually. But its same to access other reserved range so 
> just
>       live on Xen's default behavior. In shared-ept case guest can read or
>       write anything from this range, but such a leak or corruption just
>       happens inside same domain so this behavior is also same as a native
>       case, it should be fine.
> 
> expectation:
>     * Don't broken normal RMRR usage.

I'm not getting the purpose of this whole section.

> 5. Re-enable USB
> 
> current status:
>     * Currently Xen doesn't allow USB passthrough.

???

> 6. Hotplug case
> 
> current status:
>     * only work well in non-shared ept case or in case of shared ept & all
>       associated gfns are free.
> 
> proposal:
>     * If user ensure there'll be a hotplug device in advace, 
> 'rdm_forcecheck'
>       can be set to reserve all RMRR range as we describe above. Then any
>       device can be hotplugged successfully.
>     * If not, there are still two scenarios here:
>       in non-shared ept case it still work well as original;

So you continue to assume that the two tables going out of sync is
acceptable.

>       in shared ept case, its just going a case of "1. Setup RMRR identity
>       mapping"
>         - gfn space unoccupied -> insert mapping: success.
>         - gfn space already occupied by 1:1 RMRR mapping -> do nothing; 
> success.
>         - gfn space already occupied by other mapping -> fail.
> 
> expectation:
>     * provide a way to let hotplug work in case of shared ept totally
> 
> Open Issue
> ==========
> 
> When other stuffs like ballon mechanism, to populate memory accessing RMRR
> range, or others like qemu, force map RMRR range, we may need to avoid such 
> a
> possibility but we're not 100% sure this so just open this to double check.

I think a HVM guest can be expected to play by what E820 table
says is reserved. That includes not using such ranges for ballooning.
If it still does, it'll get what it deserves.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 15:14:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15: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 1Y1zFW-000650-UC; Fri, 19 Dec 2014 15:13: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 1Y1zFW-00064v-2y
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 15:13:50 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	B8/F3-29352-DA044945; Fri, 19 Dec 2014 15:13:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1419002028!8961974!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26201 invoked from network); 19 Dec 2014 15:13:48 -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; 19 Dec 2014 15:13:48 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 15:13:47 +0000
Message-Id: <54944EBA02000078000510BF@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 15:13:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tiejun Chen" <tiejun.chen@intel.com>
References: <1418952066-21064-1-git-send-email-tiejun.chen@intel.com>
In-Reply-To: <1418952066-21064-1-git-send-email-tiejun.chen@intel.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, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] RMRR Fix Design for Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.12.14 at 02:21, <tiejun.chen@intel.com> wrote:
> #4 Something like USB, is still restricted to current RMRR implementation. We
>    should work out this case.

This can mean all or nothing. My understanding is that right now code
assumes that USB devices won't use their RMRR-specified memory
regions post-boot (kind of contrary to your earlier statement that in
such a case the regions shouldn't be listed in RMRRs in the first place).

> Design Overview
> ===============
> 
> First of all we need to make sure all resources don't overlap RMRR. And then
> in case of shared ept, we can set these identity entries. And Certainly we 
> will
> group all devices associated to one same RMRR entry, then make sure all 
> group
> devices should be assigned to same VM.
> 
> 1. Setup RMRR identity mapping
> 
> current status:
>     * identity mapping only setup in non-shared ept case
> 
> proposal:
> 
> In non-shared ept case, IOMMU stuff always set those entries and RMRR is 
> already marked reserved in host so its fine enough.

Is it? Where? Or am I misunderstanding the whole statement, likely
due to me silently replacing "host" by "guest" (since reservation in
host address spaces is of no interest here afaict)?

> But in shared ept case, we need to
> check any conflit, so we should follow up
> 
>   - gfn space unoccupied
>         -> insert mapping: success.
>             gfn:_mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct, p2m_access_rw
>   - gfn space already occupied by 1:1 RMRR mapping
>         -> do nothing; success.
>   - gfn space already occupied by other mapping
>         -> fail.
> 
> expectation:
>     * only devices w/ non-conflicting RMRR can be assigned
>     * fortunately this achieves the very initial intention to support IGD
>       pass-through on BDW

Are you trying to say here that doing the above is all you need for
your specific machine? If so, that's clearly not something to go into
a design document.

Also there's clearly an alternative proposal: Drop support for sharing
page tables. Your colleagues will surely have told you that we've
been considering this for quite some time, and had actually hoped
for them to do the necessary VT-d side work to allow for this without
causing performance regressions.

> 2.1 Expose RMRR to user space
> 
> current status:
>     * Xen always record RMRR info into one list, acpi_rmrr_units, while 
> parsing
>       acpi. So we can retrieve these info by lookup that list.
> 
> proposal:
>     * RMRR would be exposed by a new hypercall, which Jan already finished 
> in
>       current version but just expose all RMRR info unconditionally.
>     * Furthermore we can expose RMRR on demand to diminish shrinking guest
>       RAM/MMIO space.
>     * So we will introduce a new parameter, 'rdm_forcecheck' and to 
> collaborate
>       with SBDFs to control which RMRR should be exposed:
> 
>         - We can set this parameter in .cfg file like,
> 
>             rdm_forcecheck = 1 => Of course this should be 0 by default.
> 
>         '1' means we should force check to reserve all ranges 
> unconditionally.
>         and 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.
> 
>         If 0, we just check those assigned pci devices. As you know we already

assigned? Wasn't the plan to have a separate potentially-to-be-
assigned list? And I can only re-iterate that the name
"rdm_forcecheck" doesn't really express what you mean. Since
your intention is to check all devices (rather than do a check that
otherwise wouldn't be done), "rdm_all" or "rdm_check_all" would
seem closer to the intended behavior.

>         have such an existing hypercall to assign PCI devices, looks we can 
> work
>         directly under this hypercall to get that necessary SBDF to sort 
> which
>         RMRR should be handled. But obviously, we need to get these info 
> before
>         we populate guest memory to make sure these RMRR ranges should be
>         excluded from guest memory. But unfortunately the memory populating
>         takes place before a device assignment, so we can't live on that
>         directly.
> 
>         But as we discussed it just benefit that assigned case to reorder 
> that
>         order, but not good to hotplug case. So we have to introduce a new
>         DOMCTL to pass that global parameter with SBDF at the same time.
> 
>         For example, if we own these two RMRR entries,

"own" is confusing here, I assume you mean if there are such entries.

>         [00:14.0]    RMRR region: base_addr ab80a000 end_address ab81dfff
>         [00:02.0]    RMRR region: base_addr ad000000 end_address af7fffff
> 
>         If 'rdm_forcecheck = 1', any caller to that hypercall may get these two

s/may/will/ I suppose.

>         entries. But if 'rdm_forcecheck = 0', and in .cfg file,
> 
>         #1 'pci=[00:14.0, 00:02.0]' -> The caller still get these two entries.
>         #2 'pci=[00:02.0]' -> The caller just get one entry, 
> 0xad000000:0xaf7fffff
>         #2 'pci=[00:14.0]' -> The caller just get one entry, 
> 0xab80a000:0xab81dfff
>         #4 'pci=[others]' or no any pci configuration -> The caller get 
> nothing.

Oh, interesting, you dropped the idea of a separate list of possibly-
to-be-assigned devices. Why that?

>         And ultimately, if we expose any RMRR entry at gfn,
> 
>         in non-shared ept case, 
> 
>         p2m table:  valid non-identity mapping, gfn:mfn != 1:1

This would mean ...

>         VT-D table: no such a mapping until set identity mapping,
>                     gfn:_mfn(gfn) == 1:1 when we have a associated device
>                     assignment.

... the two mappings to go out of sync when such a 1:1 mapping gets
established. I think we should avoid such a situation if at all possible.

>         in shared ept case,
> 
>         p2m table\VT-D table:  always INVALID until set identity mapping,
>                                gfn:_mfn(gfn) == 1:1 when we have a 
> associated
>                                device assignment.
> 
>         But if we don't expose any RMRR entry,
> 
>         in non-shared ept case, 
> 
>         p2m table:  valid non-identity mapping, gfn:mfn != 1:1
>         VT-D table: no such a mapping until set identity mapping,
>                     gfn:_mfn(gfn) == 1:1 when we have a associated device
>                     assignment.
> 
>         in shared ept case,
> 
>         p2m table\VT-D table:  If guest RAM already cover gfn, we have sunc a
>                                valid non-identity mapping, gfn:mfn != 1:1, 
> but
>                                we can't set any identity mapping again then
>                                that associated device can't be assigned
>                                successfully. If not, we'll set identity 
> mapping,
>                                gfn:_mfn(gfn) == 1:1, to work well.

So in the end we'd still have various cases of different behavior,
when really it would be much better (if not a requirement) if guest
observable behavior wouldn't depend on implementation details
like (non-)shared page tables.

> 2.2 Detect and avoid RMRR conflictions with guest RAM/MMIO
> 
> current status:
>     * Currently Xen doesn't detect anything to avoid any conflict.
> 
> proposal:
>     * We need to cover all points to check any conflict. Below lists places
>       where reserved region conflictions should be detected:
> 
>         1>. libxc:setup_guest():modules_init()
> 
>         There are some modules, like acpi_module and smbios_module. They may
>         occupy some ranges so we need to check if they're conflicting with
>         all ranges from that new hypercall above.

I'm missing of what conflict resolution you expect to do here.
Following earlier discussion in the context of patch review made
pretty clear that this isn't really straightforward, having the
potential to prevent a guest from booting (e.g. when the virtual
BIOS conflicts with an RMRR).

>         2>. libxc:setup_guest():xc_domain_populate_physmap()
> 
>         There are two ways to exclude RMRR ranges here:
>             
>             #1 Before we populate guest RAM without any RMRR range from that
>                new hypercall to skip RMRR ranges when populating guest RAM.
>             #2 In Xen we can fliter RMRR range while calling
>                XENMEM_populate_physmap, its no change to libxc, but skip
>                setting p2m entry for RMRR ranges in Xen hypervisor
> 
>         But to compare #1, #2 is not better since Xen still allocate those
>         range, and we have to sync somewhere else in Xen. And #1 is cleaner
>         because #2 actually shrinks the available memory size to the guest.
> 
>         3>. hvmloader:pci_setup()
> 
>         Here we should populate guest MMIO excluding all ranges from that 
> new
>         hypercall to detect RMRR conflictions for allocating PCI MMIO BAR.
> 
>         4>. hvmloader:mem_hole_alloc()
> 
>         Here we should populate mem holw excluding all ranges from that new
>         hypercall to detect RMRR conflictions for dynamic allocation in
>         hvmloader, e.g. as used for IGD opregion
> 
>         5>. hvmloader:build_e820_table():
> 
>         Finally we need let VM know that RMRR regions are reserved through 
> e820
>         table
> 
>     Its a little bit tricky to handle this inside hvmloader since as you 
> know,
>     struct hvm_info_table is only a approach between libxc and hvmloader. 
> But
>     however, making up all above places will bring some duplicated logic.
>     Especially between libxc and hvmloader, which skip same regions in guest
>     physical layer(one in populating guest RAM, the other in constructing 
> e820)
>     But current design has some limitation to pass information between libxc 
> and
>     hvmloader,
> 
> struct hvm_info_table {
>     ...
>     /*
>      *  0x0 to page_to_phys(low_mem_pgend)-1:
>      *    RAM below 4GB (except for VGA hole 0xA0000-0xBFFFF)
>      */
>     uint32_t    low_mem_pgend;
>     ...
>     /*
>      *  0x100000000 to page_to_phys(high_mem_pgend)-1:
>      *    RAM above 4GB
>      */
>     uint32_t    high_mem_pgend;
>     ...
> }
> 
>     nothing valuable is passed to hvmloader so we have to figure out a way 
> to
>     handle those points in hvmloader. Currently,
> 
>             #1 Reconstruct hvm_info_table{}
> 
>             We can store all necessary RMRR info into hvm_info_table as 
> well,
>             then we can pick them conveniently but oftentimes these RMRR
>             entries are scattered and the number is also undertimined, so 
> its
>             a little bit ugly to do.
> 
>             #2 Xenstore
> 
>             We may store all necessary RMRR info as Xenstore then pick them 
> in
>             hvmloader.
> 
>             #3 A hypercall
> 
>             We may have to call our new hypercall again to pick them, but
>             obviously this may introduce some duplicated codes.
> 
>             #4 XENMEM_{set_,}memory_map pair of hypercalls
>             
>             As Jan commented it "could be used(and is readily available to 
> be
>             extended that way, since for HVM domains XENMEM_set_memory_map
>             returns -EPERM at present). The only potentially problematic 
> aspect
>             I can see with using it might be its limiting of the entry count 
> to
>             E820MAX." So a preparation patch is required before RMRR, and
>             hvmloader still needs to query RMRR information.

Somewhere above I'm missing the mentioning of the option to reorder
operations of hvmloader, to e.g. base PCI BAR assignment on the
previously set up E820 table, rather than assuming a (mostly) fixed
size window where to put these.

> 3. Group multiple devices sharing same RMRR entry
> 
> current status:
>     * Xen doesn't distinguish if multiple devices share same RMRR entry. 
> This
>       may lead a leak to corruption, e.g. Device A and device B share same 
> entry
>       and then device A is assigned to domain A, device B is assigned to 
> domain
>       B. So domain A can read something from that range, even rewrite
>       maliciously that range to corrupt device B inside domain B.
> 
> proposal:
>     * We will group all devices by means of one same RMRR entry. 
> Theoretically,
>       we should make sure all devices in one group are allowed to assign to 
> one
>       VM. But in Xen side the hardware domain owns all devices at first, we
>       should unbound all group devies before assign one of group device. But 
> its
>       hard to do such thing in current VT-d stuff. And actually its rare to 
> have
>       the group device in real world so we just prevent assigning any group
>       device simply.
>     * We will introduce two field, gid, in struct, acpi_rmrr_unit:
>         gid: indicate if this device belongs a group.
>       Then when we add or attach device in iommu side, we will check this 
> field
>       if we're assigning a group device then determine if we assign that.
> 
> 
> expectation:
>     * Make all device associated to one RMRR to be assigned same VM.

A few lines up you say you're intending to refuse such assignments
rather than making them happen in a consistent way - what's the
plan in the end?

> 4. Handle in case of force accessing to RMRR regions
> 
> proposal:
>     * Although we already reserve these ranges in guest e820 table, its
>       possible to access these ranges.
>       In non-shared ept case it will issue such EPT violation since we have 
> no
>       p2m table actually. But its same to access other reserved range so 
> just
>       live on Xen's default behavior. In shared-ept case guest can read or
>       write anything from this range, but such a leak or corruption just
>       happens inside same domain so this behavior is also same as a native
>       case, it should be fine.
> 
> expectation:
>     * Don't broken normal RMRR usage.

I'm not getting the purpose of this whole section.

> 5. Re-enable USB
> 
> current status:
>     * Currently Xen doesn't allow USB passthrough.

???

> 6. Hotplug case
> 
> current status:
>     * only work well in non-shared ept case or in case of shared ept & all
>       associated gfns are free.
> 
> proposal:
>     * If user ensure there'll be a hotplug device in advace, 
> 'rdm_forcecheck'
>       can be set to reserve all RMRR range as we describe above. Then any
>       device can be hotplugged successfully.
>     * If not, there are still two scenarios here:
>       in non-shared ept case it still work well as original;

So you continue to assume that the two tables going out of sync is
acceptable.

>       in shared ept case, its just going a case of "1. Setup RMRR identity
>       mapping"
>         - gfn space unoccupied -> insert mapping: success.
>         - gfn space already occupied by 1:1 RMRR mapping -> do nothing; 
> success.
>         - gfn space already occupied by other mapping -> fail.
> 
> expectation:
>     * provide a way to let hotplug work in case of shared ept totally
> 
> Open Issue
> ==========
> 
> When other stuffs like ballon mechanism, to populate memory accessing RMRR
> range, or others like qemu, force map RMRR range, we may need to avoid such 
> a
> possibility but we're not 100% sure this so just open this to double check.

I think a HVM guest can be expected to play by what E820 table
says is reserved. That includes not using such ranges for ballooning.
If it still does, it'll get what it deserves.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 15:20:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15:20:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1zLg-0006SI-Oj; Fri, 19 Dec 2014 15:20: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 1Y1zLf-0006SD-5R
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 15:20:11 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	46/9E-11608-A2244945; Fri, 19 Dec 2014 15:20:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1419002407!14690358!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11987 invoked from network); 19 Dec 2014 15:20:09 -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 Dec 2014 15:20:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,607,1413244800"; d="scan'208";a="206755391"
Message-ID: <54944210.6050402@citrix.com>
Date: Fri, 19 Dec 2014 15:19: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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
	<20141216204900.GB11551@konrad-lan.dumpdata.com>
In-Reply-To: <20141216204900.GB11551@konrad-lan.dumpdata.com>
X-DLP: MIA2
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/12/14 20:49, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 16, 2014 at 05:43:08PM +0000, Andrew Cooper wrote:
>> On 16/12/14 16:13, konrad.wilk@oracle.com wrote:
>>> Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
>>> we have the General Release on Jan 7th!
>>>
>>> Details for the test-day are at
>>>
>>> http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions
>>>
>>> In terms of bugs, we have:
>> From the XenServer testing.
> Thank you for doing this testing!
>> * Fail to reliably boot on IBM Flex x222 blades, apparent regression
>> from 4.4
>>
>> I have declared this a latent BIOS bug, and not a regression from 4.4. 
>> Across regular reboots, the exact positions of the ACPI tables, and the
>> e820 layout is unstable.  The first consistent difference between 4.4
>> and 4.5 is that 4.4 reports 1 MBR signature while 4.5 reports 0.  This
>> is because the int $0x13, ah=2 call is returning differently.  I can get
>> the call to return differently (and correctly for 4.5) by simply making
>> the boot trampoline larger (with my debugging routines but not being
>> called).
> This sounds very familiar, but I can't place where I saw mention of
> a similar issue.
>> * VM fail to resume on upgrade from Xen < 4.5
>>
>> This is the issue I am currently looking into.  Currently, all the
>> "upgrade from older XenServer" tests are failing due to VMs crashing on
>> resume.  I have not yet identified whether this is a XenServer issue or
> Ugh.

I have got to the bottom of this, and it it turns out to be a legacy ->
migration v2 conversion bug which only surfaced now because Xen-4.5 is
more strict than Xen-4.4.

HVM_PARAM_PAE_ENABLED is sent out-of-band in legacy, but passed to
xc_domain_restore(), which does a set_param(), unconnected with any
contents of the stream.  Migration v2 saves and restores it properly,
but the legacy -> v2 conversion neglected to combine the out-of-band
information.  No VMs blew up because all versions of Xen at that point
were not correctly auditing updates to cr4 against the domain cpuid
policy.  Xen-4.5 now does, causing #GP faults on cr4 writes for guests
which had PAE enabled before migrate.

I shall be fixing this in the migration v2 series, and also looking for
any other obvious out-of-band information which needs injecting into a
converted stream.


With this fixed(^W hacked around for now), I have identified and solved
all discrepancies XenServer testing has noticed between Xen-4.4 and
Xen-4.5 so far.

There will be another full nightly test happening tonight (based on c/s
7e88c23 "libxl: Tell qemu to use raw format when using a tapdisk"), and
some stress and scale tests if time allows.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 15:20:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15:20:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1zLg-0006SI-Oj; Fri, 19 Dec 2014 15:20: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 1Y1zLf-0006SD-5R
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 15:20:11 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	46/9E-11608-A2244945; Fri, 19 Dec 2014 15:20:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1419002407!14690358!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 11987 invoked from network); 19 Dec 2014 15:20:09 -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 Dec 2014 15:20:09 -0000
X-IronPort-AV: E=Sophos;i="5.07,607,1413244800"; d="scan'208";a="206755391"
Message-ID: <54944210.6050402@citrix.com>
Date: Fri, 19 Dec 2014 15:19: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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
	<20141216204900.GB11551@konrad-lan.dumpdata.com>
In-Reply-To: <20141216204900.GB11551@konrad-lan.dumpdata.com>
X-DLP: MIA2
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/12/14 20:49, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 16, 2014 at 05:43:08PM +0000, Andrew Cooper wrote:
>> On 16/12/14 16:13, konrad.wilk@oracle.com wrote:
>>> Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
>>> we have the General Release on Jan 7th!
>>>
>>> Details for the test-day are at
>>>
>>> http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions
>>>
>>> In terms of bugs, we have:
>> From the XenServer testing.
> Thank you for doing this testing!
>> * Fail to reliably boot on IBM Flex x222 blades, apparent regression
>> from 4.4
>>
>> I have declared this a latent BIOS bug, and not a regression from 4.4. 
>> Across regular reboots, the exact positions of the ACPI tables, and the
>> e820 layout is unstable.  The first consistent difference between 4.4
>> and 4.5 is that 4.4 reports 1 MBR signature while 4.5 reports 0.  This
>> is because the int $0x13, ah=2 call is returning differently.  I can get
>> the call to return differently (and correctly for 4.5) by simply making
>> the boot trampoline larger (with my debugging routines but not being
>> called).
> This sounds very familiar, but I can't place where I saw mention of
> a similar issue.
>> * VM fail to resume on upgrade from Xen < 4.5
>>
>> This is the issue I am currently looking into.  Currently, all the
>> "upgrade from older XenServer" tests are failing due to VMs crashing on
>> resume.  I have not yet identified whether this is a XenServer issue or
> Ugh.

I have got to the bottom of this, and it it turns out to be a legacy ->
migration v2 conversion bug which only surfaced now because Xen-4.5 is
more strict than Xen-4.4.

HVM_PARAM_PAE_ENABLED is sent out-of-band in legacy, but passed to
xc_domain_restore(), which does a set_param(), unconnected with any
contents of the stream.  Migration v2 saves and restores it properly,
but the legacy -> v2 conversion neglected to combine the out-of-band
information.  No VMs blew up because all versions of Xen at that point
were not correctly auditing updates to cr4 against the domain cpuid
policy.  Xen-4.5 now does, causing #GP faults on cr4 writes for guests
which had PAE enabled before migrate.

I shall be fixing this in the migration v2 series, and also looking for
any other obvious out-of-band information which needs injecting into a
converted stream.


With this fixed(^W hacked around for now), I have identified and solved
all discrepancies XenServer testing has noticed between Xen-4.4 and
Xen-4.5 so far.

There will be another full nightly test happening tonight (based on c/s
7e88c23 "libxl: Tell qemu to use raw format when using a tapdisk"), and
some stress and scale tests if time allows.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 15:23:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15: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 1Y1zOj-0006mm-Gv; Fri, 19 Dec 2014 15:23: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 1Y1zOh-0006mf-EH
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 15:23:19 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	4F/1C-28296-6E244945; Fri, 19 Dec 2014 15:23:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419002596!14661178!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 379 invoked from network); 19 Dec 2014 15:23:17 -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; 19 Dec 2014 15:23:17 -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 sBJFNDcM020349
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 15:23: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
	sBJFN8ev027967
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 15:23:09 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
	sBJFN8RF013170; Fri, 19 Dec 2014 15:23:08 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 07:23:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 374D5125E33; Fri, 19 Dec 2014 09:23:16 -0500 (EST)
Date: Fri, 19 Dec 2014 09:23:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141219142316.GB2690@laptop.dumpdata.com>
References: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>
	<1418896057.11882.0.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418896057.11882.0.camel@citrix.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, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for 4.5] xen/arm: Initialize the domain vgic
	lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 18, 2014 at 09:47:37AM +0000, Ian Campbell wrote:
> On Wed, 2014-12-17 at 15:40 +0000, Julien Grall wrote:
> > The domain vgic lock is used uninitialized.
> > 
> > Signed-off-by: Julien Grall <julien.grall@linaro.org>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
> > ---
> >     This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
> >     unitialized. Luckily we only use the field "raw" which is reset to 0
> >     during the domain allocation.
> > 
> >     There is no harm to apply for Xen 4.5 because it will correctly set
> >     the spin_lock structure for a later usage.
> 
> By your above reasoning there is also no point, is there? That said, I
> think we should take this since as you say it is harmless and good
> practice to initialise spinlocks even if not strictly necessary.
> 
> > ---
> >  xen/arch/arm/vgic.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 97061ce..b8bd38b 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -90,6 +90,8 @@ int domain_vgic_init(struct domain *d)
> >          return -ENODEV;
> >      }
> >  
> > +    spin_lock_init(&d->arch.vgic.lock);
> > +
> >      d->arch.vgic.shared_irqs =
> >          xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
> >      if ( d->arch.vgic.shared_irqs == NULL )
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 15:23:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15: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 1Y1zOj-0006mm-Gv; Fri, 19 Dec 2014 15:23: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 1Y1zOh-0006mf-EH
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 15:23:19 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	4F/1C-28296-6E244945; Fri, 19 Dec 2014 15:23:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419002596!14661178!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 379 invoked from network); 19 Dec 2014 15:23:17 -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; 19 Dec 2014 15:23:17 -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 sBJFNDcM020349
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 15:23: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
	sBJFN8ev027967
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 15:23:09 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
	sBJFN8RF013170; Fri, 19 Dec 2014 15:23:08 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 07:23:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 374D5125E33; Fri, 19 Dec 2014 09:23:16 -0500 (EST)
Date: Fri, 19 Dec 2014 09:23:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20141219142316.GB2690@laptop.dumpdata.com>
References: <1418830815-4720-1-git-send-email-julien.grall@linaro.org>
	<1418896057.11882.0.camel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418896057.11882.0.camel@citrix.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, Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, stefano.stabellini@citrix.com
Subject: Re: [Xen-devel] [PATCH for 4.5] xen/arm: Initialize the domain vgic
	lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 18, 2014 at 09:47:37AM +0000, Ian Campbell wrote:
> On Wed, 2014-12-17 at 15:40 +0000, Julien Grall wrote:
> > The domain vgic lock is used uninitialized.
> > 
> > Signed-off-by: Julien Grall <julien.grall@linaro.org>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
> > ---
> >     This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
> >     unitialized. Luckily we only use the field "raw" which is reset to 0
> >     during the domain allocation.
> > 
> >     There is no harm to apply for Xen 4.5 because it will correctly set
> >     the spin_lock structure for a later usage.
> 
> By your above reasoning there is also no point, is there? That said, I
> think we should take this since as you say it is harmless and good
> practice to initialise spinlocks even if not strictly necessary.
> 
> > ---
> >  xen/arch/arm/vgic.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 97061ce..b8bd38b 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -90,6 +90,8 @@ int domain_vgic_init(struct domain *d)
> >          return -ENODEV;
> >      }
> >  
> > +    spin_lock_init(&d->arch.vgic.lock);
> > +
> >      d->arch.vgic.shared_irqs =
> >          xzalloc_array(struct vgic_irq_rank, DOMAIN_NR_RANKS(d));
> >      if ( d->arch.vgic.shared_irqs == NULL )
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 15:23:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15:23:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1zOp-0006ns-TR; Fri, 19 Dec 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 <konrad.wilk@oracle.com>) id 1Y1zOo-0006nb-V4
	for Xen-devel@lists.xen.org; Fri, 19 Dec 2014 15:23:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	23/E3-25276-EE244945; Fri, 19 Dec 2014 15:23:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1419002604!16799330!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12413 invoked from network); 19 Dec 2014 15:23:25 -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; 19 Dec 2014 15:23: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 sBJFNEti020408
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 15:23:15 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
	sBJFNCYx009033
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 15:23:13 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
	sBJFNCsu021942; Fri, 19 Dec 2014 15:23:12 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 07:23:12 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 203E9125E36; Fri, 19 Dec 2014 09:30:52 -0500 (EST)
Date: Fri, 19 Dec 2014 09:30:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141219143052.GC2690@laptop.dumpdata.com>
References: <1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418897867.11882.11.camel@citrix.com> <5492AB8B.90201@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5492AB8B.90201@citrix.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>, Philipp Hahn <hahn@univention.de>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Xen-devel@lists.xen.org,
	Frediano Ziglio <freddy77@gmail.com>, Jan Beulich <JBeulich@suse.com>
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, Dec 18, 2014 at 10:25:15AM +0000, David Vrabel wrote:
> On 18/12/14 10:17, Ian Campbell wrote:
> > On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
> >> Do we have a bug in Xen that affect SSE instructions (possibly already
> >> fixed after Philipp version) ?
> > 
> > I've had a niggling feeling of Deja Vu over this which I'd been putting
> > down to an old Xen on ARM bug in the area of FPU register switching.
> > 
> > But it seems at some point (possibly even still) there was a similar
> > issue with pvops kernels on x86, see:
> >         http://bugs.xenproject.org/xen/bug/40
> > 
> > Philipp, what kernel are you guys using?
> > 
> > CCing Jan and the x86 kernel guys (and George since he registered the
> > bug). I'm not seeing anything in the kernel logs which looks like a fix
> > (there's some PVH related cr0 frobbing, but I don't think that's it).
> > 
> > I also can't quite shake the feeling that there was another much older
> > issue relating to FPU context switch on x86, but I think that was truly
> > ancient history (2.6.18 era stuff)
> 
> http://marc.info/?l=linux-kernel&m=139132566024357

More up-to-date: http://lkml.iu.edu/hypermail/linux/kernel/1409.0/01057.html

And boy did that mess up Oracle DB! There had been an P0 bug affecting
databases and this patch solved it.

> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 15:23:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15:23:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1zOp-0006ns-TR; Fri, 19 Dec 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 <konrad.wilk@oracle.com>) id 1Y1zOo-0006nb-V4
	for Xen-devel@lists.xen.org; Fri, 19 Dec 2014 15:23:27 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	23/E3-25276-EE244945; Fri, 19 Dec 2014 15:23:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1419002604!16799330!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12413 invoked from network); 19 Dec 2014 15:23:25 -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; 19 Dec 2014 15:23: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 sBJFNEti020408
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 15:23:15 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
	sBJFNCYx009033
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 15:23:13 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
	sBJFNCsu021942; Fri, 19 Dec 2014 15:23:12 GMT
Received: from laptop.dumpdata.com (/10.137.179.135)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 07:23:12 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 203E9125E36; Fri, 19 Dec 2014 09:30:52 -0500 (EST)
Date: Fri, 19 Dec 2014 09:30:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141219143052.GC2690@laptop.dumpdata.com>
References: <1418655014.16425.138.camel@citrix.com>
	<1418665524.16425.171.camel@citrix.com>
	<548F60BF.4020901@univention.de>
	<1418726712.16425.213.camel@citrix.com>
	<1418727970.16425.217.camel@citrix.com>
	<CAHt6W4cfQ+JzhS1zBL4iCWJ3Mg9R25zhG1Wjr=1ukwW0qykNTQ@mail.gmail.com>
	<1418732635.16425.221.camel@citrix.com>
	<CAHt6W4eLJ-FNwdLmDHuZFKpEcc+eQn0AmnFdtvBW7g3KUu96QQ@mail.gmail.com>
	<1418897867.11882.11.camel@citrix.com> <5492AB8B.90201@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5492AB8B.90201@citrix.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>, Philipp Hahn <hahn@univention.de>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Xen-devel@lists.xen.org,
	Frediano Ziglio <freddy77@gmail.com>, Jan Beulich <JBeulich@suse.com>
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, Dec 18, 2014 at 10:25:15AM +0000, David Vrabel wrote:
> On 18/12/14 10:17, Ian Campbell wrote:
> > On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
> >> Do we have a bug in Xen that affect SSE instructions (possibly already
> >> fixed after Philipp version) ?
> > 
> > I've had a niggling feeling of Deja Vu over this which I'd been putting
> > down to an old Xen on ARM bug in the area of FPU register switching.
> > 
> > But it seems at some point (possibly even still) there was a similar
> > issue with pvops kernels on x86, see:
> >         http://bugs.xenproject.org/xen/bug/40
> > 
> > Philipp, what kernel are you guys using?
> > 
> > CCing Jan and the x86 kernel guys (and George since he registered the
> > bug). I'm not seeing anything in the kernel logs which looks like a fix
> > (there's some PVH related cr0 frobbing, but I don't think that's it).
> > 
> > I also can't quite shake the feeling that there was another much older
> > issue relating to FPU context switch on x86, but I think that was truly
> > ancient history (2.6.18 era stuff)
> 
> http://marc.info/?l=linux-kernel&m=139132566024357

More up-to-date: http://lkml.iu.edu/hypermail/linux/kernel/1409.0/01057.html

And boy did that mess up Oracle DB! There had been an P0 bug affecting
databases and this patch solved it.

> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 15:30:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15: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 1Y1zVe-0007Bf-QC; Fri, 19 Dec 2014 15:30: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 1Y1zVd-0007Ba-EE
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 15:30:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	9F/E2-09842-49444945; Fri, 19 Dec 2014 15:30:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419003028!16811215!1
X-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 21955 invoked from network); 19 Dec 2014 15:30:28 -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; 19 Dec 2014 15:30:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 15:30:25 +0000
Message-Id: <5494529F02000078000510F0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 15:30:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Lars Kurth" <lars.kurth.xen@gmail.com>,
	"Sarah Conway" <sconway@linuxfoundation.org>,
	"Russ Pavlicek" <russell.pavlicek@xenproject.org>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
In-Reply-To: <322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>, ian.jackson@eu.citrix.com,
	mengxu@cis.upenn.edu, m.a.young@durham.ac.uk, feng.wu@intel.com,
	zhigang.x.wang@oracle.com, parth.dixit@linaro.org,
	manishjaggi.oss@gmail.com, chao.p.peng@linux.intel.com,
	Paul.Skentzos@dornerworks.com, vijay.kilari@gmail.com,
	rcojocaru@bitdefender.com, guijianfeng@cn.fujitsu.com,
	Vijaya.Kumar@caviumnetworks.com, josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	anthony.perard@citrix.com, xen-devel@lists.xenproject.org,
	serge.broslavsky@linaro.org, yjhyun.yoo@samsung.com,
	olaf@aepfle.de, suriyan.r@gmail.com, ian.campbell@citrix.com,
	wency@cn.fujitsu.com, stefano.stabellini@eu.citrix.com,
	Luis Rodriguez <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, ufimtseva@gmail.com,
	boris.ostrovsky@oracle.com, andrii.tseglytskyi@globallogic.com,
	Juergen Gross <JGross@suse.com>, dave.scott@citrix.com,
	caobosimon@gmail.com, Wei.Liu2@citrix.com, eddie.dong@intel.com,
	george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	dario.faggioli@citrix.com, Steve.VanderLeest@dornerworks.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,
	yanghy@cn.fujitsu.com, daniel.kiper@oracle.com,
	christoffer.dall@linaro.org, roger.pau@citrix.com
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
 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 19.12.14 at 15:52, <lars.kurth.xen@gmail.com> wrote:
> ** The key changes normally are changes to scalability/memory/etc. limits - 
> maybe Jan(x86) and Ian(ARM) can look let me know of changes

Iirc scalability changes on the x86 side were mostly (if not exclusively)
in terms of performance improvements (in some cases getting bigger
guests out of not booting at all state).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 15:30:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15: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 1Y1zVe-0007Bf-QC; Fri, 19 Dec 2014 15:30: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 1Y1zVd-0007Ba-EE
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 15:30:29 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	9F/E2-09842-49444945; Fri, 19 Dec 2014 15:30:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419003028!16811215!1
X-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 21955 invoked from network); 19 Dec 2014 15:30:28 -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; 19 Dec 2014 15:30:28 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 15:30:25 +0000
Message-Id: <5494529F02000078000510F0@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 15:30:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Lars Kurth" <lars.kurth.xen@gmail.com>,
	"Sarah Conway" <sconway@linuxfoundation.org>,
	"Russ Pavlicek" <russell.pavlicek@xenproject.org>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
In-Reply-To: <322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>, ian.jackson@eu.citrix.com,
	mengxu@cis.upenn.edu, m.a.young@durham.ac.uk, feng.wu@intel.com,
	zhigang.x.wang@oracle.com, parth.dixit@linaro.org,
	manishjaggi.oss@gmail.com, chao.p.peng@linux.intel.com,
	Paul.Skentzos@dornerworks.com, vijay.kilari@gmail.com,
	rcojocaru@bitdefender.com, guijianfeng@cn.fujitsu.com,
	Vijaya.Kumar@caviumnetworks.com, josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	anthony.perard@citrix.com, xen-devel@lists.xenproject.org,
	serge.broslavsky@linaro.org, yjhyun.yoo@samsung.com,
	olaf@aepfle.de, suriyan.r@gmail.com, ian.campbell@citrix.com,
	wency@cn.fujitsu.com, stefano.stabellini@eu.citrix.com,
	Luis Rodriguez <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, ufimtseva@gmail.com,
	boris.ostrovsky@oracle.com, andrii.tseglytskyi@globallogic.com,
	Juergen Gross <JGross@suse.com>, dave.scott@citrix.com,
	caobosimon@gmail.com, Wei.Liu2@citrix.com, eddie.dong@intel.com,
	george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	dario.faggioli@citrix.com, Steve.VanderLeest@dornerworks.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,
	yanghy@cn.fujitsu.com, daniel.kiper@oracle.com,
	christoffer.dall@linaro.org, roger.pau@citrix.com
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
 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 19.12.14 at 15:52, <lars.kurth.xen@gmail.com> wrote:
> ** The key changes normally are changes to scalability/memory/etc. limits - 
> maybe Jan(x86) and Ian(ARM) can look let me know of changes

Iirc scalability changes on the x86 side were mostly (if not exclusively)
in terms of performance improvements (in some cases getting bigger
guests out of not booting at all state).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 15:31:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15: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 1Y1zWo-0007Fl-8h; Fri, 19 Dec 2014 15:31:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1Y1zWm-0007Fg-Fb
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 15:31:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	49/81-25276-BD444945; Fri, 19 Dec 2014 15:31:39 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-21.messagelabs.com!1419003099!16812021!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29035 invoked from network); 19 Dec 2014 15:31:39 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 19 Dec 2014 15:31:39 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:51894 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Y1zVi-0001Qv-GB; Fri, 19 Dec 2014 16:30:34 +0100
Date: Fri, 19 Dec 2014 16:31:35 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1931187914.20141219163135@eikelenboom.it>
To: Jiang Liu <jiang.liu@linux.intel.com>
In-Reply-To: <54943C44.5080503@linux.intel.com>
References: <1824124380.20141219141645@eikelenboom.it>
	<54943C44.5080503@linux.intel.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events
	don't work under Xen since commit
	b81975eade8c6495f3c4d6746d22bdc95f617777
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 19, 2014, 3:55:00 PM, you wrote:

> Hi Sander,
>         Could you please help to test attached patch? It works
> on native but I have no Xen environment at hand.
> Thanks!
> Gerry

Hi Gerry,

First of all thanks for the swift response !

Just tested this patch and i can report that it fixes my issue.

(i don't know if the xen-folks / Thomas have any comment on the way it is fixed.
But when this is final, it should probably be CC'd for -stable since it's broken
in both 3.17 and 3.18 afaik)

Thanks again,
--
Sander

> On 2014/12/19 21:16, Sander Eikelenboom wrote:
>> Hi,
>> 
>> When running under Xen, ACPI powerbutton events don't work anymore, 
>> there is no reaction when pressing the powerbutton.
>> 
>> On baremetal everything works fine, acpid gets the event and the 
>> machine powers down perfectly. The machine is an Intel NUC.
>>  
>> Bisection has lead to:
>> 
>> b81975eade8c6495f3c4d6746d22bdc95f617777 is the first bad commit
>> commit b81975eade8c6495f3c4d6746d22bdc95f617777
>> Author: Jiang Liu <jiang.liu@linux.intel.com>
>> Date:   Mon Jun 9 16:20:11 2014 +0800
>> 
>>     x86, irq: Clean up irqdomain transition code
>> 
>>     Now we have completely switched to irqdomain, so clean up transition code
>>     in IOAPIC drivers.
>> 
>>     Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>>     Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>     Cc: Tony Luck <tony.luck@intel.com>
>>     Cc: Joerg Roedel <joro@8bytes.org>
>>     Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
>>     Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>     Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>     Cc: Grant Likely <grant.likely@linaro.org>
>>     Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>>     Cc: Bjorn Helgaas <bhelgaas@google.com>
>>     Cc: Randy Dunlap <rdunlap@infradead.org>
>>     Cc: Yinghai Lu <yinghai@kernel.org>
>>     Link: http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang.liu@linux.intel.com
>>     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>> 
>> Reverting this specific commit on linux-tip (3.19-mw) gets things working again under Xen.
>> Kernel .config is attached.
>> 
>> --
>> Sander
>> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 15:31:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15: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 1Y1zWo-0007Fl-8h; Fri, 19 Dec 2014 15:31:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1Y1zWm-0007Fg-Fb
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 15:31:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	49/81-25276-BD444945; Fri, 19 Dec 2014 15:31:39 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-21.messagelabs.com!1419003099!16812021!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29035 invoked from network); 19 Dec 2014 15:31:39 -0000
Received: from vserver.eikelenboom.it (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES128-SHA encrypted
	SMTP; 19 Dec 2014 15:31:39 -0000
Received: from 76-71-ftth.on.nl ([88.159.71.76]:51894 helo=w510-wirelesss)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Y1zVi-0001Qv-GB; Fri, 19 Dec 2014 16:30:34 +0100
Date: Fri, 19 Dec 2014 16:31:35 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1931187914.20141219163135@eikelenboom.it>
To: Jiang Liu <jiang.liu@linux.intel.com>
In-Reply-To: <54943C44.5080503@linux.intel.com>
References: <1824124380.20141219141645@eikelenboom.it>
	<54943C44.5080503@linux.intel.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events
	don't work under Xen since commit
	b81975eade8c6495f3c4d6746d22bdc95f617777
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, December 19, 2014, 3:55:00 PM, you wrote:

> Hi Sander,
>         Could you please help to test attached patch? It works
> on native but I have no Xen environment at hand.
> Thanks!
> Gerry

Hi Gerry,

First of all thanks for the swift response !

Just tested this patch and i can report that it fixes my issue.

(i don't know if the xen-folks / Thomas have any comment on the way it is fixed.
But when this is final, it should probably be CC'd for -stable since it's broken
in both 3.17 and 3.18 afaik)

Thanks again,
--
Sander

> On 2014/12/19 21:16, Sander Eikelenboom wrote:
>> Hi,
>> 
>> When running under Xen, ACPI powerbutton events don't work anymore, 
>> there is no reaction when pressing the powerbutton.
>> 
>> On baremetal everything works fine, acpid gets the event and the 
>> machine powers down perfectly. The machine is an Intel NUC.
>>  
>> Bisection has lead to:
>> 
>> b81975eade8c6495f3c4d6746d22bdc95f617777 is the first bad commit
>> commit b81975eade8c6495f3c4d6746d22bdc95f617777
>> Author: Jiang Liu <jiang.liu@linux.intel.com>
>> Date:   Mon Jun 9 16:20:11 2014 +0800
>> 
>>     x86, irq: Clean up irqdomain transition code
>> 
>>     Now we have completely switched to irqdomain, so clean up transition code
>>     in IOAPIC drivers.
>> 
>>     Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>>     Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>     Cc: Tony Luck <tony.luck@intel.com>
>>     Cc: Joerg Roedel <joro@8bytes.org>
>>     Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
>>     Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>     Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>     Cc: Grant Likely <grant.likely@linaro.org>
>>     Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>>     Cc: Bjorn Helgaas <bhelgaas@google.com>
>>     Cc: Randy Dunlap <rdunlap@infradead.org>
>>     Cc: Yinghai Lu <yinghai@kernel.org>
>>     Link: http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang.liu@linux.intel.com
>>     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>> 
>> Reverting this specific commit on linux-tip (3.19-mw) gets things working again under Xen.
>> Kernel .config is attached.
>> 
>> --
>> Sander
>> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 15:56:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1zuT-00008b-3a; Fri, 19 Dec 2014 15:56:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xumengpanda@gmail.com>) id 1Y1zuN-00008O-Pd
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 15:56:07 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	ED/C8-24859-29A44945; Fri, 19 Dec 2014 15:56:02 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419004560!14670627!1
X-Originating-IP: [209.85.218.54]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31530 invoked from network); 19 Dec 2014 15:56:01 -0000
Received: from mail-oi0-f54.google.com (HELO mail-oi0-f54.google.com)
	(209.85.218.54)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 15:56:01 -0000
Received: by mail-oi0-f54.google.com with SMTP id u20so2103905oif.13
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 07:56:00 -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=En8iO3gKFH3ame7RnKmxbDbrHMq9L9yHSrCQZJvxhYw=;
	b=x/UvX20jwJqca5MnDR1xut4OwKFfFNCMlXvZE45B6cXoi8LhVSYSPgo2dWU6FNig9h
	4qNxDhTq5eHptcyqdZF9bn6GidkT5f04mfBcg73N7R6iPibiSrk2ghoHgTm7SvD7/un/
	7+t7Izbr3Xjk+tjzbdlu4cPv4dZeS/3xj/CYox/9P2JR1Q+bCA0zBZ+8In5dcqBTIDZH
	ObHFEoPSbbB+/hU7G5n8xrGC8PW/Illk9sZD4bPJifWMXlpEVGgeOuy3XOXecmi6RfOe
	rHkxgfCqAdCl48sKn7gpruxdE7TUxnJtlci2aadDWfabj4YSTx4cswoGROa7r9kUiXgd
	4lnQ==
MIME-Version: 1.0
X-Received: by 10.202.92.10 with SMTP id q10mr4944604oib.20.1419004559957;
	Fri, 19 Dec 2014 07:55:59 -0800 (PST)
Received: by 10.76.128.18 with HTTP; Fri, 19 Dec 2014 07:55:59 -0800 (PST)
In-Reply-To: <322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
Date: Fri, 19 Dec 2014 10:55:59 -0500
Message-ID: <CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"Steve.VanderLeest@dornerworks.com" <Steve.VanderLeest@dornerworks.com>,
	"mengxu@cis.upenn.edu" <mengxu@cis.upenn.edu>,
	m.a.young@durham.ac.uk, chao.p.peng@linux.intel.com,
	"zhigang.x.wang@oracle.com" <zhigang.x.wang@oracle.com>,
	Parth Dixit <parth.dixit@linaro.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, manishjaggi.oss@gmail.com,
	"Paul.Skentzos@dornerworks.com" <Paul.Skentzos@dornerworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"guijianfeng@cn.fujitsu.com" <guijianfeng@cn.fujitsu.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sarah Conway <sconway@linuxfoundation.org>,
	Joshua Whitehead <josh.whitehead@dornerworks.com>,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	"feng.wu@intel.com" <feng.wu@intel.com>,
	"yjhyun.yoo@samsung.com" <yjhyun.yoo@samsung.com>,
	"olaf@aepfle.de" <olaf@aepfle.de>, Suriyan Ramasami <suriyan.r@gmail.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"wency@cn.fujitsu.com" <wency@cn.fujitsu.com>,
	"mcgrof@suse.com" <mcgrof@suse.com>,
	Julien Grall <julien.grall@linaro.org>, Thomas Leonard <talex5@gmail.com>,
	Robert VanVossen <robert.vanvossen@dornerworks.com>,
	Roy Franz <roy.franz@linaro.org>,
	"yang.z.zhang@intel.com" <yang.z.zhang@intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Russ Pavlicek <russell.pavlicek@xenproject.org>,
	Elena Ufimtseva <ufimtseva@gmail.com>, "andrii.tseglytskyi@globallogic.com"
	<andrii.tseglytskyi@globallogic.com>, "jgross@suse.com" <jgross@suse.com>,
	"dave.scott@citrix.com" <dave.scott@citrix.com>,
	"yanghy@cn.fujitsu.com" <yanghy@cn.fujitsu.com>,
	Wei Liu <Wei.Liu2@citrix.com>,
	"Vijaya.Kumar@caviumnetworks.com" <Vijaya.Kumar@caviumnetworks.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	"dslutz@verizon.com" <dslutz@verizon.com>,
	"ross.lagerwall@citrix.com" <ross.lagerwall@citrix.com>,
	"Aravind.Gopalakrishnan@amd.com" <Aravind.Gopalakrishnan@amd.com>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"aravindp@cisco.com" <aravindp@cisco.com>,
	"tiejun.chen@intel.com" <tiejun.chen@intel.com>,
	"malcolm.crossley@citrix.com" <malcolm.crossley@citrix.com>,
	caobosimon@gmail.com, tklengyel@sec.in.tum.de,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
	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="===============4661373140225265491=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4661373140225265491==
Content-Type: multipart/alternative; boundary=001a113d55f8bb27db050a93be7d

--001a113d55f8bb27db050a93be7d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Lars,

2014-12-19 9:52 GMT-05:00 Lars Kurth <lars.kurth.xen@gmail.com>:

> Hi all,
>
>
Please reply to the thread and I will add that page.
> ** The key changes normally are changes to scalability/memory/etc. limits
> - maybe Jan(x86) and Ian(ARM) can look let me know of changes
> ** Also new platforms, changes to experimental features, etc.
> ** Probably the new scheduler should be added - is there a wiki page?
>

=E2=80=8BThe new scheduler (rtds) does not have a wiki page right now, but =
it has
an outside page to explain how it is designed and how it works at
https://sites.google.com/site/realtimexen/getting-started.
=E2=80=8BI can add a wiki page very quickly today based on the pages on =E2=
=80=8B
https://sites.google.com/site/realtimexen/ .

Is that ok?

Thanks,

Meng


--=20


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--001a113d55f8bb27db050a93be7d
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">Hi =
Lars,</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-1=
2-19 9:52 GMT-05:00 Lars Kurth <span dir=3D"ltr">&lt;<a href=3D"mailto:lars=
.kurth.xen@gmail.com" target=3D"_blank">lars.kurth.xen@gmail.com</a>&gt;</s=
pan>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">Hi all,<br>=C2=A0<br></blockquote><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=
">
Please reply to the thread and I will add that page.<br>
** The key changes normally are changes to scalability/memory/etc. limits -=
 maybe Jan(x86) and Ian(ARM) can look let me know of changes<br>
** Also new platforms, changes to experimental features, etc.<br>
** Probably the new scheduler should be added - is there a wiki page?<br></=
blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"font-s=
ize:small">=E2=80=8BThe new scheduler (rtds) does not have a wiki page righ=
t now, but it has an outside page to explain how it is designed and how it =
works at=C2=A0<a href=3D"https://sites.google.com/site/realtimexen/getting-=
started">https://sites.google.com/site/realtimexen/getting-started</a>.=C2=
=A0</div></div></div><div class=3D"gmail_default" style=3D"font-size:small"=
>=E2=80=8BI can add a wiki page very quickly today based on the pages on =
=E2=80=8B<a href=3D"https://sites.google.com/site/realtimexen/">https://sit=
es.google.com/site/realtimexen/</a> .</div><div class=3D"gmail_default" sty=
le=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font=
-size:small">Is that ok?</div><div class=3D"gmail_default" style=3D"font-si=
ze:small"><br></div><div class=3D"gmail_default" style=3D"font-size:small">=
Thanks,</div><div class=3D"gmail_default" style=3D"font-size:small"><br>Men=
g</div><br clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signatur=
e"><div dir=3D"ltr"><br><br>-----------<br>Meng Xu<br>PhD Student in Comput=
er and Information Science<br>University of Pennsylvania</div></div>
</div></div>

--001a113d55f8bb27db050a93be7d--


--===============4661373140225265491==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4661373140225265491==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 15:56:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 15:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y1zuT-00008b-3a; Fri, 19 Dec 2014 15:56:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xumengpanda@gmail.com>) id 1Y1zuN-00008O-Pd
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 15:56:07 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	ED/C8-24859-29A44945; Fri, 19 Dec 2014 15:56:02 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419004560!14670627!1
X-Originating-IP: [209.85.218.54]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31530 invoked from network); 19 Dec 2014 15:56:01 -0000
Received: from mail-oi0-f54.google.com (HELO mail-oi0-f54.google.com)
	(209.85.218.54)
	by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 15:56:01 -0000
Received: by mail-oi0-f54.google.com with SMTP id u20so2103905oif.13
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 07:56:00 -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=En8iO3gKFH3ame7RnKmxbDbrHMq9L9yHSrCQZJvxhYw=;
	b=x/UvX20jwJqca5MnDR1xut4OwKFfFNCMlXvZE45B6cXoi8LhVSYSPgo2dWU6FNig9h
	4qNxDhTq5eHptcyqdZF9bn6GidkT5f04mfBcg73N7R6iPibiSrk2ghoHgTm7SvD7/un/
	7+t7Izbr3Xjk+tjzbdlu4cPv4dZeS/3xj/CYox/9P2JR1Q+bCA0zBZ+8In5dcqBTIDZH
	ObHFEoPSbbB+/hU7G5n8xrGC8PW/Illk9sZD4bPJifWMXlpEVGgeOuy3XOXecmi6RfOe
	rHkxgfCqAdCl48sKn7gpruxdE7TUxnJtlci2aadDWfabj4YSTx4cswoGROa7r9kUiXgd
	4lnQ==
MIME-Version: 1.0
X-Received: by 10.202.92.10 with SMTP id q10mr4944604oib.20.1419004559957;
	Fri, 19 Dec 2014 07:55:59 -0800 (PST)
Received: by 10.76.128.18 with HTTP; Fri, 19 Dec 2014 07:55:59 -0800 (PST)
In-Reply-To: <322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
Date: Fri, 19 Dec 2014 10:55:59 -0500
Message-ID: <CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"Steve.VanderLeest@dornerworks.com" <Steve.VanderLeest@dornerworks.com>,
	"mengxu@cis.upenn.edu" <mengxu@cis.upenn.edu>,
	m.a.young@durham.ac.uk, chao.p.peng@linux.intel.com,
	"zhigang.x.wang@oracle.com" <zhigang.x.wang@oracle.com>,
	Parth Dixit <parth.dixit@linaro.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, manishjaggi.oss@gmail.com,
	"Paul.Skentzos@dornerworks.com" <Paul.Skentzos@dornerworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"guijianfeng@cn.fujitsu.com" <guijianfeng@cn.fujitsu.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sarah Conway <sconway@linuxfoundation.org>,
	Joshua Whitehead <josh.whitehead@dornerworks.com>,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	"feng.wu@intel.com" <feng.wu@intel.com>,
	"yjhyun.yoo@samsung.com" <yjhyun.yoo@samsung.com>,
	"olaf@aepfle.de" <olaf@aepfle.de>, Suriyan Ramasami <suriyan.r@gmail.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"wency@cn.fujitsu.com" <wency@cn.fujitsu.com>,
	"mcgrof@suse.com" <mcgrof@suse.com>,
	Julien Grall <julien.grall@linaro.org>, Thomas Leonard <talex5@gmail.com>,
	Robert VanVossen <robert.vanvossen@dornerworks.com>,
	Roy Franz <roy.franz@linaro.org>,
	"yang.z.zhang@intel.com" <yang.z.zhang@intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Russ Pavlicek <russell.pavlicek@xenproject.org>,
	Elena Ufimtseva <ufimtseva@gmail.com>, "andrii.tseglytskyi@globallogic.com"
	<andrii.tseglytskyi@globallogic.com>, "jgross@suse.com" <jgross@suse.com>,
	"dave.scott@citrix.com" <dave.scott@citrix.com>,
	"yanghy@cn.fujitsu.com" <yanghy@cn.fujitsu.com>,
	Wei Liu <Wei.Liu2@citrix.com>,
	"Vijaya.Kumar@caviumnetworks.com" <Vijaya.Kumar@caviumnetworks.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	"dslutz@verizon.com" <dslutz@verizon.com>,
	"ross.lagerwall@citrix.com" <ross.lagerwall@citrix.com>,
	"Aravind.Gopalakrishnan@amd.com" <Aravind.Gopalakrishnan@amd.com>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"aravindp@cisco.com" <aravindp@cisco.com>,
	"tiejun.chen@intel.com" <tiejun.chen@intel.com>,
	"malcolm.crossley@citrix.com" <malcolm.crossley@citrix.com>,
	caobosimon@gmail.com, tklengyel@sec.in.tum.de,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
	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="===============4661373140225265491=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4661373140225265491==
Content-Type: multipart/alternative; boundary=001a113d55f8bb27db050a93be7d

--001a113d55f8bb27db050a93be7d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Lars,

2014-12-19 9:52 GMT-05:00 Lars Kurth <lars.kurth.xen@gmail.com>:

> Hi all,
>
>
Please reply to the thread and I will add that page.
> ** The key changes normally are changes to scalability/memory/etc. limits
> - maybe Jan(x86) and Ian(ARM) can look let me know of changes
> ** Also new platforms, changes to experimental features, etc.
> ** Probably the new scheduler should be added - is there a wiki page?
>

=E2=80=8BThe new scheduler (rtds) does not have a wiki page right now, but =
it has
an outside page to explain how it is designed and how it works at
https://sites.google.com/site/realtimexen/getting-started.
=E2=80=8BI can add a wiki page very quickly today based on the pages on =E2=
=80=8B
https://sites.google.com/site/realtimexen/ .

Is that ok?

Thanks,

Meng


--=20


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--001a113d55f8bb27db050a93be7d
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">Hi =
Lars,</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-1=
2-19 9:52 GMT-05:00 Lars Kurth <span dir=3D"ltr">&lt;<a href=3D"mailto:lars=
.kurth.xen@gmail.com" target=3D"_blank">lars.kurth.xen@gmail.com</a>&gt;</s=
pan>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">Hi all,<br>=C2=A0<br></blockquote><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=
">
Please reply to the thread and I will add that page.<br>
** The key changes normally are changes to scalability/memory/etc. limits -=
 maybe Jan(x86) and Ian(ARM) can look let me know of changes<br>
** Also new platforms, changes to experimental features, etc.<br>
** Probably the new scheduler should be added - is there a wiki page?<br></=
blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"font-s=
ize:small">=E2=80=8BThe new scheduler (rtds) does not have a wiki page righ=
t now, but it has an outside page to explain how it is designed and how it =
works at=C2=A0<a href=3D"https://sites.google.com/site/realtimexen/getting-=
started">https://sites.google.com/site/realtimexen/getting-started</a>.=C2=
=A0</div></div></div><div class=3D"gmail_default" style=3D"font-size:small"=
>=E2=80=8BI can add a wiki page very quickly today based on the pages on =
=E2=80=8B<a href=3D"https://sites.google.com/site/realtimexen/">https://sit=
es.google.com/site/realtimexen/</a> .</div><div class=3D"gmail_default" sty=
le=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font=
-size:small">Is that ok?</div><div class=3D"gmail_default" style=3D"font-si=
ze:small"><br></div><div class=3D"gmail_default" style=3D"font-size:small">=
Thanks,</div><div class=3D"gmail_default" style=3D"font-size:small"><br>Men=
g</div><br clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signatur=
e"><div dir=3D"ltr"><br><br>-----------<br>Meng Xu<br>PhD Student in Comput=
er and Information Science<br>University of Pennsylvania</div></div>
</div></div>

--001a113d55f8bb27db050a93be7d--


--===============4661373140225265491==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4661373140225265491==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 16:01:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 16: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 1Y1zzM-0000c0-TN; Fri, 19 Dec 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 1Y1zzK-0000bv-BI
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:01:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	91/65-09842-5CB44945; Fri, 19 Dec 2014 16:01:09 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1419004868!16775877!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32270 invoked from network); 19 Dec 2014 16:01:08 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 16:01:08 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so1720317wgg.0
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 08:01:08 -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
	:message-id:references:to;
	bh=InTdGpeJ+EAv9Bz92zyyMVr8sC3DQyun9eVia6woZMQ=;
	b=Oji3HewQLnnKNSZRu3JiHVdBerW1LU+fOM2E9/IXfXiRemxtIe3aURJH5Pu1KcruP+
	niN0rEeXJWJ+nssnnG6tv+Uya0AGKtzVjGisg6lu3EKQMLWtFIkcgVtbz/jGyjmc3mSl
	GWQA3C/f0wDVDyGfU9jD9CiK9Ws1WoEAP2FzSSZ+fVkCT0ERUJbVSkoQaVakMDo6haw4
	PZZE3qKl41BVGqHNdNHAjY50VdgD1sJa396YiVoM0TqtfouX6ZsyPcKmUmF86GxWhOca
	mp68s8UxINN0qEgVAFWi3MuM2XrZA9L09iRLpJK++JUOzJ2Fw8zCHZJ14QAC83lU+G8r
	S7+Q==
X-Received: by 10.180.76.144 with SMTP id k16mr7036182wiw.3.1419004868270;
	Fri, 19 Dec 2014 08:01:08 -0800 (PST)
Received: from [192.168.0.25] (97e5a0c2.skybroadband.com. [151.229.160.194])
	by mx.google.com with ESMTPSA id o2sm2816497wiy.11.2014.12.19.08.01.03
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 19 Dec 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: <CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
Date: Fri, 19 Dec 2014 16:01:02 +0000
Message-Id: <976A391C-B062-4346-ABB0-AD0C78C5FB3F@gmail.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
	<CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
To: Meng Xu <xumengpanda@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"Steve.VanderLeest@dornerworks.com" <Steve.VanderLeest@dornerworks.com>,
	"mengxu@cis.upenn.edu" <mengxu@cis.upenn.edu>,
	m.a.young@durham.ac.uk, chao.p.peng@linux.intel.com,
	"zhigang.x.wang@oracle.com" <zhigang.x.wang@oracle.com>,
	Parth Dixit <parth.dixit@linaro.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, manishjaggi.oss@gmail.com,
	"Paul.Skentzos@dornerworks.com" <Paul.Skentzos@dornerworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"guijianfeng@cn.fujitsu.com" <guijianfeng@cn.fujitsu.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sarah Conway <sconway@linuxfoundation.org>,
	Joshua Whitehead <josh.whitehead@dornerworks.com>,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	"feng.wu@intel.com" <feng.wu@intel.com>,
	"yjhyun.yoo@samsung.com" <yjhyun.yoo@samsung.com>,
	"olaf@aepfle.de" <olaf@aepfle.de>, Suriyan Ramasami <suriyan.r@gmail.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"wency@cn.fujitsu.com" <wency@cn.fujitsu.com>,
	"mcgrof@suse.com" <mcgrof@suse.com>,
	Julien Grall <julien.grall@linaro.org>, Thomas Leonard <talex5@gmail.com>,
	Robert VanVossen <robert.vanvossen@dornerworks.com>,
	Roy Franz <roy.franz@linaro.org>,
	"yang.z.zhang@intel.com" <yang.z.zhang@intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Russ Pavlicek <russell.pavlicek@xenproject.org>,
	Elena Ufimtseva <ufimtseva@gmail.com>, "andrii.tseglytskyi@globallogic.com"
	<andrii.tseglytskyi@globallogic.com>, "jgross@suse.com" <jgross@suse.com>,
	"dave.scott@citrix.com" <dave.scott@citrix.com>,
	"yanghy@cn.fujitsu.com" <yanghy@cn.fujitsu.com>,
	Wei Liu <Wei.Liu2@citrix.com>,
	"Vijaya.Kumar@caviumnetworks.com" <Vijaya.Kumar@caviumnetworks.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	"dslutz@verizon.com" <dslutz@verizon.com>,
	"ross.lagerwall@citrix.com" <ross.lagerwall@citrix.com>,
	"Aravind.Gopalakrishnan@amd.com" <Aravind.Gopalakrishnan@amd.com>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"aravindp@cisco.com" <aravindp@cisco.com>,
	"tiejun.chen@intel.com" <tiejun.chen@intel.com>,
	"malcolm.crossley@citrix.com" <malcolm.crossley@citrix.com>,
	caobosimon@gmail.com, tklengyel@sec.in.tum.de,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
	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="===============2881982793702568087=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2881982793702568087==
Content-Type: multipart/alternative; boundary="Apple-Mail=_FBF9E988-E050-41DD-B63D-26F010622C9E"


--Apple-Mail=_FBF9E988-E050-41DD-B63D-26F010622C9E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


On 19 Dec 2014, at 15:55, Meng Xu <xumengpanda@gmail.com> wrote:

> Hi Lars,
>=20
> 2014-12-19 9:52 GMT-05:00 Lars Kurth <lars.kurth.xen@gmail.com>:
> Hi all,
> =20
> Please reply to the thread and I will add that page.
> ** The key changes normally are changes to scalability/memory/etc. =
limits - maybe Jan(x86) and Ian(ARM) can look let me know of changes
> ** Also new platforms, changes to experimental features, etc.
> ** Probably the new scheduler should be added - is there a wiki page?
>=20
> =E2=80=8BThe new scheduler (rtds) does not have a wiki page right now, =
but it has an outside page to explain how it is designed and how it =
works at https://sites.google.com/site/realtimexen/getting-started.=20
> =E2=80=8BI can add a wiki page very quickly today based on the pages =
on =E2=80=8Bhttps://sites.google.com/site/realtimexen/ .
>=20
> Is that ok?

That would be perfect.
Lars=

--Apple-Mail=_FBF9E988-E050-41DD-B63D-26F010622C9E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On 19 Dec 2014, at 15:55, Meng Xu =
&lt;<a href=3D"mailto:xumengpanda@gmail.com">xumengpanda@gmail.com</a>&gt;=
 wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_default" =
style=3D"font-size:small">Hi Lars,</div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-12-19 9:52 =
GMT-05:00 Lars Kurth <span dir=3D"ltr">&lt;<a =
href=3D"mailto:lars.kurth.xen@gmail.com" =
target=3D"_blank">lars.kurth.xen@gmail.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">Hi =
all,<br>&nbsp;<br></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; position: static; z-index: auto;">
Please reply to the thread and I will add that page.<br>
** The key changes normally are changes to scalability/memory/etc. =
limits - maybe Jan(x86) and Ian(ARM) can look let me know of changes<br>
** Also new platforms, changes to experimental features, etc.<br>
** Probably the new scheduler should be added - is there a wiki =
page?<br></blockquote><div><br></div><div><div class=3D"gmail_default" =
style=3D"font-size:small">=E2=80=8BThe new scheduler (rtds) does not =
have a wiki page right now, but it has an outside page to explain how it =
is designed and how it works at&nbsp;<a =
href=3D"https://sites.google.com/site/realtimexen/getting-started">https:/=
/sites.google.com/site/realtimexen/getting-started</a>.&nbsp;</div></div><=
/div><div class=3D"gmail_default" style=3D"font-size:small">=E2=80=8BI =
can add a wiki page very quickly today based on the pages on =E2=80=8B<a =
href=3D"https://sites.google.com/site/realtimexen/">https://sites.google.c=
om/site/realtimexen/</a> .</div><div class=3D"gmail_default" =
style=3D"font-size:small"><br></div><div class=3D"gmail_default" =
style=3D"font-size:small">Is that =
ok?</div></div></div></blockquote><div><br></div>That would be =
perfect.</div><div>Lars</div></body></html>=

--Apple-Mail=_FBF9E988-E050-41DD-B63D-26F010622C9E--


--===============2881982793702568087==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2881982793702568087==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 16:01:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 16: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 1Y1zzM-0000c0-TN; Fri, 19 Dec 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 1Y1zzK-0000bv-BI
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:01:10 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	91/65-09842-5CB44945; Fri, 19 Dec 2014 16:01:09 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1419004868!16775877!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32270 invoked from network); 19 Dec 2014 16:01:08 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 16:01:08 -0000
Received: by mail-wg0-f41.google.com with SMTP id y19so1720317wgg.0
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 08:01:08 -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
	:message-id:references:to;
	bh=InTdGpeJ+EAv9Bz92zyyMVr8sC3DQyun9eVia6woZMQ=;
	b=Oji3HewQLnnKNSZRu3JiHVdBerW1LU+fOM2E9/IXfXiRemxtIe3aURJH5Pu1KcruP+
	niN0rEeXJWJ+nssnnG6tv+Uya0AGKtzVjGisg6lu3EKQMLWtFIkcgVtbz/jGyjmc3mSl
	GWQA3C/f0wDVDyGfU9jD9CiK9Ws1WoEAP2FzSSZ+fVkCT0ERUJbVSkoQaVakMDo6haw4
	PZZE3qKl41BVGqHNdNHAjY50VdgD1sJa396YiVoM0TqtfouX6ZsyPcKmUmF86GxWhOca
	mp68s8UxINN0qEgVAFWi3MuM2XrZA9L09iRLpJK++JUOzJ2Fw8zCHZJ14QAC83lU+G8r
	S7+Q==
X-Received: by 10.180.76.144 with SMTP id k16mr7036182wiw.3.1419004868270;
	Fri, 19 Dec 2014 08:01:08 -0800 (PST)
Received: from [192.168.0.25] (97e5a0c2.skybroadband.com. [151.229.160.194])
	by mx.google.com with ESMTPSA id o2sm2816497wiy.11.2014.12.19.08.01.03
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 19 Dec 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: <CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
Date: Fri, 19 Dec 2014 16:01:02 +0000
Message-Id: <976A391C-B062-4346-ABB0-AD0C78C5FB3F@gmail.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
	<CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
To: Meng Xu <xumengpanda@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"Steve.VanderLeest@dornerworks.com" <Steve.VanderLeest@dornerworks.com>,
	"mengxu@cis.upenn.edu" <mengxu@cis.upenn.edu>,
	m.a.young@durham.ac.uk, chao.p.peng@linux.intel.com,
	"zhigang.x.wang@oracle.com" <zhigang.x.wang@oracle.com>,
	Parth Dixit <parth.dixit@linaro.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, manishjaggi.oss@gmail.com,
	"Paul.Skentzos@dornerworks.com" <Paul.Skentzos@dornerworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"guijianfeng@cn.fujitsu.com" <guijianfeng@cn.fujitsu.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sarah Conway <sconway@linuxfoundation.org>,
	Joshua Whitehead <josh.whitehead@dornerworks.com>,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	"feng.wu@intel.com" <feng.wu@intel.com>,
	"yjhyun.yoo@samsung.com" <yjhyun.yoo@samsung.com>,
	"olaf@aepfle.de" <olaf@aepfle.de>, Suriyan Ramasami <suriyan.r@gmail.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"wency@cn.fujitsu.com" <wency@cn.fujitsu.com>,
	"mcgrof@suse.com" <mcgrof@suse.com>,
	Julien Grall <julien.grall@linaro.org>, Thomas Leonard <talex5@gmail.com>,
	Robert VanVossen <robert.vanvossen@dornerworks.com>,
	Roy Franz <roy.franz@linaro.org>,
	"yang.z.zhang@intel.com" <yang.z.zhang@intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Russ Pavlicek <russell.pavlicek@xenproject.org>,
	Elena Ufimtseva <ufimtseva@gmail.com>, "andrii.tseglytskyi@globallogic.com"
	<andrii.tseglytskyi@globallogic.com>, "jgross@suse.com" <jgross@suse.com>,
	"dave.scott@citrix.com" <dave.scott@citrix.com>,
	"yanghy@cn.fujitsu.com" <yanghy@cn.fujitsu.com>,
	Wei Liu <Wei.Liu2@citrix.com>,
	"Vijaya.Kumar@caviumnetworks.com" <Vijaya.Kumar@caviumnetworks.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	"dslutz@verizon.com" <dslutz@verizon.com>,
	"ross.lagerwall@citrix.com" <ross.lagerwall@citrix.com>,
	"Aravind.Gopalakrishnan@amd.com" <Aravind.Gopalakrishnan@amd.com>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"aravindp@cisco.com" <aravindp@cisco.com>,
	"tiejun.chen@intel.com" <tiejun.chen@intel.com>,
	"malcolm.crossley@citrix.com" <malcolm.crossley@citrix.com>,
	caobosimon@gmail.com, tklengyel@sec.in.tum.de,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
	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="===============2881982793702568087=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2881982793702568087==
Content-Type: multipart/alternative; boundary="Apple-Mail=_FBF9E988-E050-41DD-B63D-26F010622C9E"


--Apple-Mail=_FBF9E988-E050-41DD-B63D-26F010622C9E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


On 19 Dec 2014, at 15:55, Meng Xu <xumengpanda@gmail.com> wrote:

> Hi Lars,
>=20
> 2014-12-19 9:52 GMT-05:00 Lars Kurth <lars.kurth.xen@gmail.com>:
> Hi all,
> =20
> Please reply to the thread and I will add that page.
> ** The key changes normally are changes to scalability/memory/etc. =
limits - maybe Jan(x86) and Ian(ARM) can look let me know of changes
> ** Also new platforms, changes to experimental features, etc.
> ** Probably the new scheduler should be added - is there a wiki page?
>=20
> =E2=80=8BThe new scheduler (rtds) does not have a wiki page right now, =
but it has an outside page to explain how it is designed and how it =
works at https://sites.google.com/site/realtimexen/getting-started.=20
> =E2=80=8BI can add a wiki page very quickly today based on the pages =
on =E2=80=8Bhttps://sites.google.com/site/realtimexen/ .
>=20
> Is that ok?

That would be perfect.
Lars=

--Apple-Mail=_FBF9E988-E050-41DD-B63D-26F010622C9E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On 19 Dec 2014, at 15:55, Meng Xu =
&lt;<a href=3D"mailto:xumengpanda@gmail.com">xumengpanda@gmail.com</a>&gt;=
 wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_default" =
style=3D"font-size:small">Hi Lars,</div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-12-19 9:52 =
GMT-05:00 Lars Kurth <span dir=3D"ltr">&lt;<a =
href=3D"mailto:lars.kurth.xen@gmail.com" =
target=3D"_blank">lars.kurth.xen@gmail.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">Hi =
all,<br>&nbsp;<br></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; position: static; z-index: auto;">
Please reply to the thread and I will add that page.<br>
** The key changes normally are changes to scalability/memory/etc. =
limits - maybe Jan(x86) and Ian(ARM) can look let me know of changes<br>
** Also new platforms, changes to experimental features, etc.<br>
** Probably the new scheduler should be added - is there a wiki =
page?<br></blockquote><div><br></div><div><div class=3D"gmail_default" =
style=3D"font-size:small">=E2=80=8BThe new scheduler (rtds) does not =
have a wiki page right now, but it has an outside page to explain how it =
is designed and how it works at&nbsp;<a =
href=3D"https://sites.google.com/site/realtimexen/getting-started">https:/=
/sites.google.com/site/realtimexen/getting-started</a>.&nbsp;</div></div><=
/div><div class=3D"gmail_default" style=3D"font-size:small">=E2=80=8BI =
can add a wiki page very quickly today based on the pages on =E2=80=8B<a =
href=3D"https://sites.google.com/site/realtimexen/">https://sites.google.c=
om/site/realtimexen/</a> .</div><div class=3D"gmail_default" =
style=3D"font-size:small"><br></div><div class=3D"gmail_default" =
style=3D"font-size:small">Is that =
ok?</div></div></div></blockquote><div><br></div>That would be =
perfect.</div><div>Lars</div></body></html>=

--Apple-Mail=_FBF9E988-E050-41DD-B63D-26F010622C9E--


--===============2881982793702568087==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2881982793702568087==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 16:16:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 16:16:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y20Dk-0001Zg-Ux; Fri, 19 Dec 2014 16:16:04 +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 1Y20Dj-0001Zb-4A
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:16:03 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	AE/81-08051-24F44945; Fri, 19 Dec 2014 16:16:02 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1419005760!16223569!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24107 invoked from network); 19 Dec 2014 16:16:01 -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 Dec 2014 16:16:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,607,1413244800"; 
	d="asc'?scan'208";a="206288286"
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.210.2;
	Fri, 19 Dec 2014 11:15:32 -0500
Message-ID: <1419005719.7060.21.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Meng Xu <xumengpanda@gmail.com>
Date: Fri, 19 Dec 2014 17:15:19 +0100
In-Reply-To: <CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
	<CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA1
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"Steve.VanderLeest@dornerworks.com" <Steve.VanderLeest@dornerworks.com>,
	"mengxu@cis.upenn.edu" <mengxu@cis.upenn.edu>,
	m.a.young@durham.ac.uk, chao.p.peng@linux.intel.com,
	"zhigang.x.wang@oracle.com" <zhigang.x.wang@oracle.com>,
	Parth Dixit <parth.dixit@linaro.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, manishjaggi.oss@gmail.com,
	"Paul.Skentzos@dornerworks.com" <Paul.Skentzos@dornerworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"guijianfeng@cn.fujitsu.com" <guijianfeng@cn.fujitsu.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sarah Conway <sconway@linuxfoundation.org>,
	Joshua Whitehead <josh.whitehead@dornerworks.com>,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	"feng.wu@intel.com" <feng.wu@intel.com>,
	"yjhyun.yoo@samsung.com" <yjhyun.yoo@samsung.com>,
	"olaf@aepfle.de" <olaf@aepfle.de>, Suriyan
	Ramasami <suriyan.r@gmail.com>, Ian Campbell <ian.campbell@citrix.com>,
	"wency@cn.fujitsu.com" <wency@cn.fujitsu.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>, "mcgrof@suse.com" <mcgrof@suse.com>,
	Julien Grall <julien.grall@linaro.org>, Thomas Leonard <talex5@gmail.com>,
	Robert VanVossen <robert.vanvossen@dornerworks.com>,
	Roy Franz <roy.franz@linaro.org>,
	"yang.z.zhang@intel.com" <yang.z.zhang@intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Russ Pavlicek <russell.pavlicek@xenproject.org>,
	Elena Ufimtseva <ufimtseva@gmail.com>, "andrii.tseglytskyi@globallogic.com"
	<andrii.tseglytskyi@globallogic.com>, "jgross@suse.com" <jgross@suse.com>,
	"dave.scott@citrix.com" <dave.scott@citrix.com>,
	"yanghy@cn.fujitsu.com" <yanghy@cn.fujitsu.com>,
	Wei Liu <Wei.Liu2@citrix.com>,
	"Vijaya.Kumar@caviumnetworks.com" <Vijaya.Kumar@caviumnetworks.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	"dslutz@verizon.com" <dslutz@verizon.com>,
	"ross.lagerwall@citrix.com" <ross.lagerwall@citrix.com>,
	"Aravind.Gopalakrishnan@amd.com" <Aravind.Gopalakrishnan@amd.com>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"aravindp@cisco.com" <aravindp@cisco.com>,
	"tiejun.chen@intel.com" <tiejun.chen@intel.com>,
	"malcolm.crossley@citrix.com" <malcolm.crossley@citrix.com>,
	caobosimon@gmail.com, tklengyel@sec.in.tum.de,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
 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="===============6896137051970326906=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6896137051970326906==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-iaGDs00QCF1cTp1Df5Id"

--=-iaGDs00QCF1cTp1Df5Id
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2014-12-19 at 10:55 -0500, Meng Xu wrote:

> 2014-12-19 9:52 GMT-05:00 Lars Kurth <lars.kurth.xen@gmail.com>:
>         Hi all,
>         =20
>         Please reply to the thread and I will add that page.
>         ** The key changes normally are changes to
>         scalability/memory/etc. limits - maybe Jan(x86) and Ian(ARM)
>         can look let me know of changes
>         ** Also new platforms, changes to experimental features, etc.
>         ** Probably the new scheduler should be added - is there a
>         wiki page?
>=20
>=20
> =E2=80=8BThe new scheduler (rtds) does not have a wiki page right now, bu=
t it
> has an outside page to explain how it is designed and how it works
> at https://sites.google.com/site/realtimexen/getting-started.=20
> =E2=80=8BI can add a wiki page very quickly today based on the pages on =
=E2=80=8B
> https://sites.google.com/site/realtimexen/ .
>
That would be great! :-)

> Is that ok?
>=20
I think it is ok. Just make sure, when you do that, that you properly
adapt the information and make them match what actually have been
upstreamed (so command option names, limits of the implementation, etc.)

Also, you should put in the wiki page a WARN about the fact that the
scheduler has been included as an experimental and in-development
feature.

Share here a link when you're done, so we can go having a look. :-)

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)


--=-iaGDs00QCF1cTp1Df5Id
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

iEYEABECAAYFAlSUTxcACgkQk4XaBE3IOsTfjwCeJv+NG7f/flg1U83iP8hQm9jh
a9UAnimr8aN6Y6WaXi2ZMolzAlwqkg6C
=pVZp
-----END PGP SIGNATURE-----

--=-iaGDs00QCF1cTp1Df5Id--


--===============6896137051970326906==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6896137051970326906==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 16:16:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 16:16:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y20Dk-0001Zg-Ux; Fri, 19 Dec 2014 16:16:04 +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 1Y20Dj-0001Zb-4A
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:16:03 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	AE/81-08051-24F44945; Fri, 19 Dec 2014 16:16:02 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1419005760!16223569!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: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24107 invoked from network); 19 Dec 2014 16:16:01 -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 Dec 2014 16:16:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,607,1413244800"; 
	d="asc'?scan'208";a="206288286"
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.210.2;
	Fri, 19 Dec 2014 11:15:32 -0500
Message-ID: <1419005719.7060.21.camel@Abyss.station>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Meng Xu <xumengpanda@gmail.com>
Date: Fri, 19 Dec 2014 17:15:19 +0100
In-Reply-To: <CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
	<CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
Organization: Citrix
X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) 
MIME-Version: 1.0
X-DLP: MIA1
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"Steve.VanderLeest@dornerworks.com" <Steve.VanderLeest@dornerworks.com>,
	"mengxu@cis.upenn.edu" <mengxu@cis.upenn.edu>,
	m.a.young@durham.ac.uk, chao.p.peng@linux.intel.com,
	"zhigang.x.wang@oracle.com" <zhigang.x.wang@oracle.com>,
	Parth Dixit <parth.dixit@linaro.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, manishjaggi.oss@gmail.com,
	"Paul.Skentzos@dornerworks.com" <Paul.Skentzos@dornerworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"guijianfeng@cn.fujitsu.com" <guijianfeng@cn.fujitsu.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sarah Conway <sconway@linuxfoundation.org>,
	Joshua Whitehead <josh.whitehead@dornerworks.com>,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	"feng.wu@intel.com" <feng.wu@intel.com>,
	"yjhyun.yoo@samsung.com" <yjhyun.yoo@samsung.com>,
	"olaf@aepfle.de" <olaf@aepfle.de>, Suriyan
	Ramasami <suriyan.r@gmail.com>, Ian Campbell <ian.campbell@citrix.com>,
	"wency@cn.fujitsu.com" <wency@cn.fujitsu.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>, "mcgrof@suse.com" <mcgrof@suse.com>,
	Julien Grall <julien.grall@linaro.org>, Thomas Leonard <talex5@gmail.com>,
	Robert VanVossen <robert.vanvossen@dornerworks.com>,
	Roy Franz <roy.franz@linaro.org>,
	"yang.z.zhang@intel.com" <yang.z.zhang@intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Russ Pavlicek <russell.pavlicek@xenproject.org>,
	Elena Ufimtseva <ufimtseva@gmail.com>, "andrii.tseglytskyi@globallogic.com"
	<andrii.tseglytskyi@globallogic.com>, "jgross@suse.com" <jgross@suse.com>,
	"dave.scott@citrix.com" <dave.scott@citrix.com>,
	"yanghy@cn.fujitsu.com" <yanghy@cn.fujitsu.com>,
	Wei Liu <Wei.Liu2@citrix.com>,
	"Vijaya.Kumar@caviumnetworks.com" <Vijaya.Kumar@caviumnetworks.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	"dslutz@verizon.com" <dslutz@verizon.com>,
	"ross.lagerwall@citrix.com" <ross.lagerwall@citrix.com>,
	"Aravind.Gopalakrishnan@amd.com" <Aravind.Gopalakrishnan@amd.com>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"aravindp@cisco.com" <aravindp@cisco.com>,
	"tiejun.chen@intel.com" <tiejun.chen@intel.com>,
	"malcolm.crossley@citrix.com" <malcolm.crossley@citrix.com>,
	caobosimon@gmail.com, tklengyel@sec.in.tum.de,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
 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="===============6896137051970326906=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6896137051970326906==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-iaGDs00QCF1cTp1Df5Id"

--=-iaGDs00QCF1cTp1Df5Id
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2014-12-19 at 10:55 -0500, Meng Xu wrote:

> 2014-12-19 9:52 GMT-05:00 Lars Kurth <lars.kurth.xen@gmail.com>:
>         Hi all,
>         =20
>         Please reply to the thread and I will add that page.
>         ** The key changes normally are changes to
>         scalability/memory/etc. limits - maybe Jan(x86) and Ian(ARM)
>         can look let me know of changes
>         ** Also new platforms, changes to experimental features, etc.
>         ** Probably the new scheduler should be added - is there a
>         wiki page?
>=20
>=20
> =E2=80=8BThe new scheduler (rtds) does not have a wiki page right now, bu=
t it
> has an outside page to explain how it is designed and how it works
> at https://sites.google.com/site/realtimexen/getting-started.=20
> =E2=80=8BI can add a wiki page very quickly today based on the pages on =
=E2=80=8B
> https://sites.google.com/site/realtimexen/ .
>
That would be great! :-)

> Is that ok?
>=20
I think it is ok. Just make sure, when you do that, that you properly
adapt the information and make them match what actually have been
upstreamed (so command option names, limits of the implementation, etc.)

Also, you should put in the wiki page a WARN about the fact that the
scheduler has been included as an experimental and in-development
feature.

Share here a link when you're done, so we can go having a look. :-)

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)


--=-iaGDs00QCF1cTp1Df5Id
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

iEYEABECAAYFAlSUTxcACgkQk4XaBE3IOsTfjwCeJv+NG7f/flg1U83iP8hQm9jh
a9UAnimr8aN6Y6WaXi2ZMolzAlwqkg6C
=pVZp
-----END PGP SIGNATURE-----

--=-iaGDs00QCF1cTp1Df5Id--


--===============6896137051970326906==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6896137051970326906==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 16:16:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 16:16:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y20EK-0001bo-DJ; Fri, 19 Dec 2014 16:16: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 1Y20EJ-0001bf-Pg
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:16:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	85/B9-25276-76F44945; Fri, 19 Dec 2014 16:16:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419005798!8782479!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8344 invoked from network); 19 Dec 2014 16:16:38 -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; 19 Dec 2014 16:16:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 16:16:38 +0000
Message-Id: <54945D760200007800051157@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 16:16:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"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] xen/x86: properly retrieve NMI reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Using the native code here can't work properly, as the hypervisor would
normally have cleared the two reason bits by the time Dom0 gets to see
the NMI (if passed to it at all). There's a shared info field for this,
and there's an existing hook to use - just fit the two together. Note
that the hook can (and should) be used irrespective of whether being in
Dom0, as accessing port 0x61 in a DomU would be even worse, while the
shared info field would just hold zero all the time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
 arch/x86/xen/enlighten.c    |   22 +++++++++++++++++-
 include/xen/interface/nmi.h |   52 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 73 insertions(+), 1 deletion(-)

--- 3.18/arch/x86/xen/enlighten.c
+++ 3.18-xen-x86-NMI-reason/arch/x86/xen/enlighten.c
@@ -40,6 +40,7 @@
 #include <xen/interface/physdev.h>
 #include <xen/interface/vcpu.h>
 #include <xen/interface/memory.h>
+#include <xen/interface/nmi.h>
 #include <xen/interface/xen-mca.h>
 #include <xen/features.h>
 #include <xen/page.h>
@@ -66,6 +67,7 @@
 #include <asm/reboot.h>
 #include <asm/stackprotector.h>
 #include <asm/hypervisor.h>
+#include <asm/mach_traps.h>
 #include <asm/mwait.h>
 #include <asm/pci_x86.h>
 #include <asm/pat.h>
@@ -1357,6 +1359,21 @@ static const struct machine_ops xen_mach
 	.emergency_restart = xen_emergency_restart,
 };
 
+static unsigned char xen_get_nmi_reason(void)
+{
+	unsigned char reason = 0;
+
+	/* Construct a value which looks like it came from port 0x61. */
+	if (test_bit(_XEN_NMIREASON_io_error,
+		     &HYPERVISOR_shared_info->arch.nmi_reason))
+		reason |= NMI_REASON_IOCHK;
+	if (test_bit(_XEN_NMIREASON_pci_serr,
+		     &HYPERVISOR_shared_info->arch.nmi_reason))
+		reason |= NMI_REASON_SERR;
+
+	return reason;
+}
+
 static void __init xen_boot_params_init_edd(void)
 {
 #if IS_ENABLED(CONFIG_EDD)
@@ -1541,9 +1558,12 @@ asmlinkage __visible void __init xen_sta
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
 	pv_apic_ops = xen_apic_ops;
-	if (!xen_pvh_domain())
+	if (!xen_pvh_domain()) {
 		pv_cpu_ops = xen_cpu_ops;
 
+		x86_platform.get_nmi_reason = xen_get_nmi_reason;
+	}
+
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		x86_init.resources.memory_setup = xen_auto_xlated_memory_setup;
 	else
--- /usr/local/src/linux-3.18/include/xen/interface/nmi.h	1970-01-01 01:00:00.000000000 +0100
+++ 3.18-xen-x86-NMI-reason/include/xen/interface/nmi.h
@@ -0,0 +1,52 @@
+/******************************************************************************
+ * nmi.h
+ * 
+ * NMI callback registration and reason codes.
+ * 
+ * Copyright (c) 2005, Keir Fraser <keir@xensource.com>
+ */
+
+#ifndef __XEN_PUBLIC_NMI_H__
+#define __XEN_PUBLIC_NMI_H__
+
+#include <xen/interface/xen.h>
+
+/*
+ * NMI reason codes:
+ * Currently these are x86-specific, stored in arch_shared_info.nmi_reason.
+ */
+ /* I/O-check error reported via ISA port 0x61, bit 6. */
+#define _XEN_NMIREASON_io_error     0
+#define XEN_NMIREASON_io_error      (1UL << _XEN_NMIREASON_io_error)
+ /* PCI SERR reported via ISA port 0x61, bit 7. */
+#define _XEN_NMIREASON_pci_serr     1
+#define XEN_NMIREASON_pci_serr      (1UL << _XEN_NMIREASON_pci_serr)
+ /* Unknown hardware-generated NMI. */
+#define _XEN_NMIREASON_unknown      2
+#define XEN_NMIREASON_unknown       (1UL << _XEN_NMIREASON_unknown)
+
+/*
+ * long nmi_op(unsigned int cmd, void *arg)
+ * NB. All ops return zero on success, else a negative error code.
+ */
+
+/*
+ * Register NMI callback for this (calling) VCPU. Currently this only makes
+ * sense for domain 0, vcpu 0. All other callers will be returned EINVAL.
+ * arg == pointer to xennmi_callback structure.
+ */
+#define XENNMI_register_callback   0
+struct xennmi_callback {
+    unsigned long handler_address;
+    unsigned long pad;
+};
+typedef struct xennmi_callback xennmi_callback_t;
+DEFINE_XEN_GUEST_HANDLE(xennmi_callback_t);
+
+/*
+ * Deregister NMI callback for this (calling) VCPU.
+ * arg == NULL.
+ */
+#define XENNMI_unregister_callback 1
+
+#endif /* __XEN_PUBLIC_NMI_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 16:16:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 16:16:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y20EK-0001bo-DJ; Fri, 19 Dec 2014 16:16: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 1Y20EJ-0001bf-Pg
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:16:39 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	85/B9-25276-76F44945; Fri, 19 Dec 2014 16:16:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419005798!8782479!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8344 invoked from network); 19 Dec 2014 16:16:38 -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; 19 Dec 2014 16:16:38 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Fri, 19 Dec 2014 16:16:38 +0000
Message-Id: <54945D760200007800051157@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Fri, 19 Dec 2014 16:16:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"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] xen/x86: properly retrieve NMI reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Using the native code here can't work properly, as the hypervisor would
normally have cleared the two reason bits by the time Dom0 gets to see
the NMI (if passed to it at all). There's a shared info field for this,
and there's an existing hook to use - just fit the two together. Note
that the hook can (and should) be used irrespective of whether being in
Dom0, as accessing port 0x61 in a DomU would be even worse, while the
shared info field would just hold zero all the time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
 arch/x86/xen/enlighten.c    |   22 +++++++++++++++++-
 include/xen/interface/nmi.h |   52 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 73 insertions(+), 1 deletion(-)

--- 3.18/arch/x86/xen/enlighten.c
+++ 3.18-xen-x86-NMI-reason/arch/x86/xen/enlighten.c
@@ -40,6 +40,7 @@
 #include <xen/interface/physdev.h>
 #include <xen/interface/vcpu.h>
 #include <xen/interface/memory.h>
+#include <xen/interface/nmi.h>
 #include <xen/interface/xen-mca.h>
 #include <xen/features.h>
 #include <xen/page.h>
@@ -66,6 +67,7 @@
 #include <asm/reboot.h>
 #include <asm/stackprotector.h>
 #include <asm/hypervisor.h>
+#include <asm/mach_traps.h>
 #include <asm/mwait.h>
 #include <asm/pci_x86.h>
 #include <asm/pat.h>
@@ -1357,6 +1359,21 @@ static const struct machine_ops xen_mach
 	.emergency_restart = xen_emergency_restart,
 };
 
+static unsigned char xen_get_nmi_reason(void)
+{
+	unsigned char reason = 0;
+
+	/* Construct a value which looks like it came from port 0x61. */
+	if (test_bit(_XEN_NMIREASON_io_error,
+		     &HYPERVISOR_shared_info->arch.nmi_reason))
+		reason |= NMI_REASON_IOCHK;
+	if (test_bit(_XEN_NMIREASON_pci_serr,
+		     &HYPERVISOR_shared_info->arch.nmi_reason))
+		reason |= NMI_REASON_SERR;
+
+	return reason;
+}
+
 static void __init xen_boot_params_init_edd(void)
 {
 #if IS_ENABLED(CONFIG_EDD)
@@ -1541,9 +1558,12 @@ asmlinkage __visible void __init xen_sta
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
 	pv_apic_ops = xen_apic_ops;
-	if (!xen_pvh_domain())
+	if (!xen_pvh_domain()) {
 		pv_cpu_ops = xen_cpu_ops;
 
+		x86_platform.get_nmi_reason = xen_get_nmi_reason;
+	}
+
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		x86_init.resources.memory_setup = xen_auto_xlated_memory_setup;
 	else
--- /usr/local/src/linux-3.18/include/xen/interface/nmi.h	1970-01-01 01:00:00.000000000 +0100
+++ 3.18-xen-x86-NMI-reason/include/xen/interface/nmi.h
@@ -0,0 +1,52 @@
+/******************************************************************************
+ * nmi.h
+ * 
+ * NMI callback registration and reason codes.
+ * 
+ * Copyright (c) 2005, Keir Fraser <keir@xensource.com>
+ */
+
+#ifndef __XEN_PUBLIC_NMI_H__
+#define __XEN_PUBLIC_NMI_H__
+
+#include <xen/interface/xen.h>
+
+/*
+ * NMI reason codes:
+ * Currently these are x86-specific, stored in arch_shared_info.nmi_reason.
+ */
+ /* I/O-check error reported via ISA port 0x61, bit 6. */
+#define _XEN_NMIREASON_io_error     0
+#define XEN_NMIREASON_io_error      (1UL << _XEN_NMIREASON_io_error)
+ /* PCI SERR reported via ISA port 0x61, bit 7. */
+#define _XEN_NMIREASON_pci_serr     1
+#define XEN_NMIREASON_pci_serr      (1UL << _XEN_NMIREASON_pci_serr)
+ /* Unknown hardware-generated NMI. */
+#define _XEN_NMIREASON_unknown      2
+#define XEN_NMIREASON_unknown       (1UL << _XEN_NMIREASON_unknown)
+
+/*
+ * long nmi_op(unsigned int cmd, void *arg)
+ * NB. All ops return zero on success, else a negative error code.
+ */
+
+/*
+ * Register NMI callback for this (calling) VCPU. Currently this only makes
+ * sense for domain 0, vcpu 0. All other callers will be returned EINVAL.
+ * arg == pointer to xennmi_callback structure.
+ */
+#define XENNMI_register_callback   0
+struct xennmi_callback {
+    unsigned long handler_address;
+    unsigned long pad;
+};
+typedef struct xennmi_callback xennmi_callback_t;
+DEFINE_XEN_GUEST_HANDLE(xennmi_callback_t);
+
+/*
+ * Deregister NMI callback for this (calling) VCPU.
+ * arg == NULL.
+ */
+#define XENNMI_unregister_callback 1
+
+#endif /* __XEN_PUBLIC_NMI_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 16:43:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 16:43:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y20eT-0002pk-32; Fri, 19 Dec 2014 16:43:41 +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 1Y20eR-0002pf-P2
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:43:39 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	10/E1-23865-BB554945; Fri, 19 Dec 2014 16:43:39 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1419007416!14610168!1
X-Originating-IP: [156.151.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 12615 invoked from network); 19 Dec 2014 16:43:38 -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; 19 Dec 2014 16:43:38 -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 sBJGhXHb032153
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 16:43:34 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
	sBJGhWEY015725
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 16:43:32 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
	sBJGhWoX007586; Fri, 19 Dec 2014 16:43:32 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, 19 Dec 2014 08:43:31 -0800
Message-ID: <54945631.4040303@oracle.com>
Date: Fri, 19 Dec 2014 11:45:37 -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>, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <54945D760200007800051157@mail.emea.novell.com>
In-Reply-To: <54945D760200007800051157@mail.emea.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] xen/x86: properly retrieve NMI reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/19/2014 11:16 AM, Jan Beulich wrote:
> Using the native code here can't work properly, as the hypervisor would
> normally have cleared the two reason bits by the time Dom0 gets to see
> the NMI (if passed to it at all). There's a shared info field for this,
> and there's an existing hook to use - just fit the two together. Note
> that the hook can (and should) be used irrespective of whether being in
> Dom0, as accessing port 0x61 in a DomU would be even worse, while the
> shared info field would just hold zero all the time.

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
>   arch/x86/xen/enlighten.c    |   22 +++++++++++++++++-
>   include/xen/interface/nmi.h |   52 ++++++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 73 insertions(+), 1 deletion(-)
>
> --- 3.18/arch/x86/xen/enlighten.c
> +++ 3.18-xen-x86-NMI-reason/arch/x86/xen/enlighten.c
> @@ -40,6 +40,7 @@
>   #include <xen/interface/physdev.h>
>   #include <xen/interface/vcpu.h>
>   #include <xen/interface/memory.h>
> +#include <xen/interface/nmi.h>
>   #include <xen/interface/xen-mca.h>
>   #include <xen/features.h>
>   #include <xen/page.h>
> @@ -66,6 +67,7 @@
>   #include <asm/reboot.h>
>   #include <asm/stackprotector.h>
>   #include <asm/hypervisor.h>
> +#include <asm/mach_traps.h>
>   #include <asm/mwait.h>
>   #include <asm/pci_x86.h>
>   #include <asm/pat.h>
> @@ -1357,6 +1359,21 @@ static const struct machine_ops xen_mach
>   	.emergency_restart = xen_emergency_restart,
>   };
>   
> +static unsigned char xen_get_nmi_reason(void)
> +{
> +	unsigned char reason = 0;
> +
> +	/* Construct a value which looks like it came from port 0x61. */
> +	if (test_bit(_XEN_NMIREASON_io_error,
> +		     &HYPERVISOR_shared_info->arch.nmi_reason))
> +		reason |= NMI_REASON_IOCHK;
> +	if (test_bit(_XEN_NMIREASON_pci_serr,
> +		     &HYPERVISOR_shared_info->arch.nmi_reason))
> +		reason |= NMI_REASON_SERR;
> +
> +	return reason;
> +}
> +
>   static void __init xen_boot_params_init_edd(void)
>   {
>   #if IS_ENABLED(CONFIG_EDD)
> @@ -1541,9 +1558,12 @@ asmlinkage __visible void __init xen_sta
>   	pv_info = xen_info;
>   	pv_init_ops = xen_init_ops;
>   	pv_apic_ops = xen_apic_ops;
> -	if (!xen_pvh_domain())
> +	if (!xen_pvh_domain()) {
>   		pv_cpu_ops = xen_cpu_ops;
>   
> +		x86_platform.get_nmi_reason = xen_get_nmi_reason;
> +	}
> +
>   	if (xen_feature(XENFEAT_auto_translated_physmap))
>   		x86_init.resources.memory_setup = xen_auto_xlated_memory_setup;
>   	else
> --- /usr/local/src/linux-3.18/include/xen/interface/nmi.h	1970-01-01 01:00:00.000000000 +0100
> +++ 3.18-xen-x86-NMI-reason/include/xen/interface/nmi.h
> @@ -0,0 +1,52 @@
> +/******************************************************************************
> + * nmi.h
> + *
> + * NMI callback registration and reason codes.
> + *
> + * Copyright (c) 2005, Keir Fraser <keir@xensource.com>
> + */
> +
> +#ifndef __XEN_PUBLIC_NMI_H__
> +#define __XEN_PUBLIC_NMI_H__
> +
> +#include <xen/interface/xen.h>
> +
> +/*
> + * NMI reason codes:
> + * Currently these are x86-specific, stored in arch_shared_info.nmi_reason.
> + */
> + /* I/O-check error reported via ISA port 0x61, bit 6. */
> +#define _XEN_NMIREASON_io_error     0
> +#define XEN_NMIREASON_io_error      (1UL << _XEN_NMIREASON_io_error)
> + /* PCI SERR reported via ISA port 0x61, bit 7. */
> +#define _XEN_NMIREASON_pci_serr     1
> +#define XEN_NMIREASON_pci_serr      (1UL << _XEN_NMIREASON_pci_serr)
> + /* Unknown hardware-generated NMI. */
> +#define _XEN_NMIREASON_unknown      2
> +#define XEN_NMIREASON_unknown       (1UL << _XEN_NMIREASON_unknown)
> +
> +/*
> + * long nmi_op(unsigned int cmd, void *arg)
> + * NB. All ops return zero on success, else a negative error code.
> + */
> +
> +/*
> + * Register NMI callback for this (calling) VCPU. Currently this only makes
> + * sense for domain 0, vcpu 0. All other callers will be returned EINVAL.
> + * arg == pointer to xennmi_callback structure.
> + */
> +#define XENNMI_register_callback   0
> +struct xennmi_callback {
> +    unsigned long handler_address;
> +    unsigned long pad;
> +};
> +typedef struct xennmi_callback xennmi_callback_t;
> +DEFINE_XEN_GUEST_HANDLE(xennmi_callback_t);
> +
> +/*
> + * Deregister NMI callback for this (calling) VCPU.
> + * arg == NULL.
> + */
> +#define XENNMI_unregister_callback 1
> +
> +#endif /* __XEN_PUBLIC_NMI_H__ */
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 16:43:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 16:43:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y20eT-0002pk-32; Fri, 19 Dec 2014 16:43:41 +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 1Y20eR-0002pf-P2
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:43:39 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	10/E1-23865-BB554945; Fri, 19 Dec 2014 16:43:39 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1419007416!14610168!1
X-Originating-IP: [156.151.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 12615 invoked from network); 19 Dec 2014 16:43:38 -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; 19 Dec 2014 16:43:38 -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 sBJGhXHb032153
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 16:43:34 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
	sBJGhWEY015725
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 16:43:32 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
	sBJGhWoX007586; Fri, 19 Dec 2014 16:43:32 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, 19 Dec 2014 08:43:31 -0800
Message-ID: <54945631.4040303@oracle.com>
Date: Fri, 19 Dec 2014 11:45:37 -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>, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <54945D760200007800051157@mail.emea.novell.com>
In-Reply-To: <54945D760200007800051157@mail.emea.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] xen/x86: properly retrieve NMI reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/19/2014 11:16 AM, Jan Beulich wrote:
> Using the native code here can't work properly, as the hypervisor would
> normally have cleared the two reason bits by the time Dom0 gets to see
> the NMI (if passed to it at all). There's a shared info field for this,
> and there's an existing hook to use - just fit the two together. Note
> that the hook can (and should) be used irrespective of whether being in
> Dom0, as accessing port 0x61 in a DomU would be even worse, while the
> shared info field would just hold zero all the time.

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
>   arch/x86/xen/enlighten.c    |   22 +++++++++++++++++-
>   include/xen/interface/nmi.h |   52 ++++++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 73 insertions(+), 1 deletion(-)
>
> --- 3.18/arch/x86/xen/enlighten.c
> +++ 3.18-xen-x86-NMI-reason/arch/x86/xen/enlighten.c
> @@ -40,6 +40,7 @@
>   #include <xen/interface/physdev.h>
>   #include <xen/interface/vcpu.h>
>   #include <xen/interface/memory.h>
> +#include <xen/interface/nmi.h>
>   #include <xen/interface/xen-mca.h>
>   #include <xen/features.h>
>   #include <xen/page.h>
> @@ -66,6 +67,7 @@
>   #include <asm/reboot.h>
>   #include <asm/stackprotector.h>
>   #include <asm/hypervisor.h>
> +#include <asm/mach_traps.h>
>   #include <asm/mwait.h>
>   #include <asm/pci_x86.h>
>   #include <asm/pat.h>
> @@ -1357,6 +1359,21 @@ static const struct machine_ops xen_mach
>   	.emergency_restart = xen_emergency_restart,
>   };
>   
> +static unsigned char xen_get_nmi_reason(void)
> +{
> +	unsigned char reason = 0;
> +
> +	/* Construct a value which looks like it came from port 0x61. */
> +	if (test_bit(_XEN_NMIREASON_io_error,
> +		     &HYPERVISOR_shared_info->arch.nmi_reason))
> +		reason |= NMI_REASON_IOCHK;
> +	if (test_bit(_XEN_NMIREASON_pci_serr,
> +		     &HYPERVISOR_shared_info->arch.nmi_reason))
> +		reason |= NMI_REASON_SERR;
> +
> +	return reason;
> +}
> +
>   static void __init xen_boot_params_init_edd(void)
>   {
>   #if IS_ENABLED(CONFIG_EDD)
> @@ -1541,9 +1558,12 @@ asmlinkage __visible void __init xen_sta
>   	pv_info = xen_info;
>   	pv_init_ops = xen_init_ops;
>   	pv_apic_ops = xen_apic_ops;
> -	if (!xen_pvh_domain())
> +	if (!xen_pvh_domain()) {
>   		pv_cpu_ops = xen_cpu_ops;
>   
> +		x86_platform.get_nmi_reason = xen_get_nmi_reason;
> +	}
> +
>   	if (xen_feature(XENFEAT_auto_translated_physmap))
>   		x86_init.resources.memory_setup = xen_auto_xlated_memory_setup;
>   	else
> --- /usr/local/src/linux-3.18/include/xen/interface/nmi.h	1970-01-01 01:00:00.000000000 +0100
> +++ 3.18-xen-x86-NMI-reason/include/xen/interface/nmi.h
> @@ -0,0 +1,52 @@
> +/******************************************************************************
> + * nmi.h
> + *
> + * NMI callback registration and reason codes.
> + *
> + * Copyright (c) 2005, Keir Fraser <keir@xensource.com>
> + */
> +
> +#ifndef __XEN_PUBLIC_NMI_H__
> +#define __XEN_PUBLIC_NMI_H__
> +
> +#include <xen/interface/xen.h>
> +
> +/*
> + * NMI reason codes:
> + * Currently these are x86-specific, stored in arch_shared_info.nmi_reason.
> + */
> + /* I/O-check error reported via ISA port 0x61, bit 6. */
> +#define _XEN_NMIREASON_io_error     0
> +#define XEN_NMIREASON_io_error      (1UL << _XEN_NMIREASON_io_error)
> + /* PCI SERR reported via ISA port 0x61, bit 7. */
> +#define _XEN_NMIREASON_pci_serr     1
> +#define XEN_NMIREASON_pci_serr      (1UL << _XEN_NMIREASON_pci_serr)
> + /* Unknown hardware-generated NMI. */
> +#define _XEN_NMIREASON_unknown      2
> +#define XEN_NMIREASON_unknown       (1UL << _XEN_NMIREASON_unknown)
> +
> +/*
> + * long nmi_op(unsigned int cmd, void *arg)
> + * NB. All ops return zero on success, else a negative error code.
> + */
> +
> +/*
> + * Register NMI callback for this (calling) VCPU. Currently this only makes
> + * sense for domain 0, vcpu 0. All other callers will be returned EINVAL.
> + * arg == pointer to xennmi_callback structure.
> + */
> +#define XENNMI_register_callback   0
> +struct xennmi_callback {
> +    unsigned long handler_address;
> +    unsigned long pad;
> +};
> +typedef struct xennmi_callback xennmi_callback_t;
> +DEFINE_XEN_GUEST_HANDLE(xennmi_callback_t);
> +
> +/*
> + * Deregister NMI callback for this (calling) VCPU.
> + * arg == NULL.
> + */
> +#define XENNMI_unregister_callback 1
> +
> +#endif /* __XEN_PUBLIC_NMI_H__ */
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 17:10:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 17: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 1Y214J-0003f9-KF; Fri, 19 Dec 2014 17:10:23 +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 1Y214I-0003f4-IW
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 17:10:22 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	92/74-25276-DFB54945; Fri, 19 Dec 2014 17:10:21 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1419009017!16477849!1
X-Originating-IP: [209.85.218.51]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5353 invoked from network); 19 Dec 2014 17:10:18 -0000
Received: from mail-oi0-f51.google.com (HELO mail-oi0-f51.google.com)
	(209.85.218.51)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 17:10:18 -0000
Received: by mail-oi0-f51.google.com with SMTP id e131so2424387oig.10
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 09:10:17 -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=otaj3x3rfQy5XeAF0okr4pfLJ1Qtyo6cJ6WYHju0w5w=;
	b=GyP0YhDK2LEvOVt0NjyUuPFlgHl0gfjkYF0bqagvIEEJoNCxACvshiUw0kxRHGXYbQ
	hBwxlq9kkFttE9TcLbx/NBZSfOJ75Or6IfZ1TcEyQjUnvAKp3QkWTNLyHQO8M/X20ztU
	DHJY1y9FEmNMi7etXJBG2xTtR91yZarWCV0Iihg4t0z0zEgzVcGLUs/9bC06adFjenrw
	baVsX9eqztIqI80e8yf3VWU2X5repJGbI1CwnR8PS/wVM+WGiN85fuDOjhfKJw+Pi7L0
	BVvb6pwHtE+bmFDt7qVWEuS149y2eV5ctqRLRM895C66qU191x6S7MuAgK+E2o29ZT7Y
	58ug==
MIME-Version: 1.0
X-Received: by 10.60.161.47 with SMTP id xp15mr5493779oeb.16.1419009017421;
	Fri, 19 Dec 2014 09:10:17 -0800 (PST)
Received: by 10.76.128.18 with HTTP; Fri, 19 Dec 2014 09:10:17 -0800 (PST)
In-Reply-To: <1419005719.7060.21.camel@Abyss.station>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
	<CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
	<1419005719.7060.21.camel@Abyss.station>
Date: Fri, 19 Dec 2014 12:10:17 -0500
Message-ID: <CAENZ-+=CN8H7Yr3ki0CJC4D_a5v=uBAcx9C-XV6d=xgwNi-Vaw@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"Steve.VanderLeest@dornerworks.com" <Steve.VanderLeest@dornerworks.com>,
	"mengxu@cis.upenn.edu" <mengxu@cis.upenn.edu>,
	m.a.young@durham.ac.uk, chao.p.peng@linux.intel.com,
	"zhigang.x.wang@oracle.com" <zhigang.x.wang@oracle.com>,
	Parth Dixit <parth.dixit@linaro.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	manish jaggi <manishjaggi.oss@gmail.com>,
	"Paul.Skentzos@dornerworks.com" <Paul.Skentzos@dornerworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"guijianfeng@cn.fujitsu.com" <guijianfeng@cn.fujitsu.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sarah Conway <sconway@linuxfoundation.org>,
	Joshua Whitehead <josh.whitehead@dornerworks.com>,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	"feng.wu@intel.com" <feng.wu@intel.com>,
	"yjhyun.yoo@samsung.com" <yjhyun.yoo@samsung.com>,
	"olaf@aepfle.de" <olaf@aepfle.de>, Suriyan Ramasami <suriyan.r@gmail.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"wency@cn.fujitsu.com" <wency@cn.fujitsu.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>, "mcgrof@suse.com" <mcgrof@suse.com>,
	Julien Grall <julien.grall@linaro.org>, Thomas Leonard <talex5@gmail.com>,
	Robert VanVossen <robert.vanvossen@dornerworks.com>,
	Roy Franz <roy.franz@linaro.org>,
	"yang.z.zhang@intel.com" <yang.z.zhang@intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Russ Pavlicek <russell.pavlicek@xenproject.org>,
	Elena Ufimtseva <ufimtseva@gmail.com>, "andrii.tseglytskyi@globallogic.com"
	<andrii.tseglytskyi@globallogic.com>, "jgross@suse.com" <jgross@suse.com>,
	"dave.scott@citrix.com" <dave.scott@citrix.com>,
	"yanghy@cn.fujitsu.com" <yanghy@cn.fujitsu.com>,
	Wei Liu <Wei.Liu2@citrix.com>,
	"Vijaya.Kumar@caviumnetworks.com" <Vijaya.Kumar@caviumnetworks.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	"dslutz@verizon.com" <dslutz@verizon.com>,
	"ross.lagerwall@citrix.com" <ross.lagerwall@citrix.com>,
	"Aravind.Gopalakrishnan@amd.com" <Aravind.Gopalakrishnan@amd.com>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"aravindp@cisco.com" <aravindp@cisco.com>,
	"tiejun.chen@intel.com" <tiejun.chen@intel.com>,
	"malcolm.crossley@citrix.com" <malcolm.crossley@citrix.com>,
	Simon Cao <caobosimon@gmail.com>, tklengyel@sec.in.tum.de,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
	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="===============2722196543566601380=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2722196543566601380==
Content-Type: multipart/alternative; boundary=089e01183a266aa9a0050a94c800

--089e01183a266aa9a0050a94c800
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Lars and Dario,

2014-12-19 11:15 GMT-05:00 Dario Faggioli <dario.faggioli@citrix.com>:

> On Fri, 2014-12-19 at 10:55 -0500, Meng Xu wrote:
>
> > 2014-12-19 9:52 GMT-05:00 Lars Kurth <lars.kurth.xen@gmail.com>:
> >         Hi all,
> >
> >         Please reply to the thread and I will add that page.
> >         ** The key changes normally are changes to
> >         scalability/memory/etc. limits - maybe Jan(x86) and Ian(ARM)
> >         can look let me know of changes
> >         ** Also new platforms, changes to experimental features, etc.
> >         ** Probably the new scheduler should be added - is there a
> >         wiki page?
> >
> >
> > =E2=80=8BThe new scheduler (rtds) does not have a wiki page right now, =
but it
> > has an outside page to explain how it is designed and how it works
> > at https://sites.google.com/site/realtimexen/getting-started.
> > =E2=80=8BI can add a wiki page very quickly today based on the pages on=
 =E2=80=8B
> > https://sites.google.com/site/realtimexen/ .
> >
> That would be great! :-)
>
> > Is that ok?
> >
> I think it is ok. Just make sure, when you do that, that you properly
> adapt the information and make them match what actually have been
> upstreamed (so command option names, limits of the implementation, etc.)
>
> Also, you should put in the wiki page a WARN about the fact that the
> scheduler has been included as an experimental and in-development
> feature.
>
> Share here a link when you're done, so we can go having a look. :-)
>


=E2=80=8BI have finished the wiki page. Here is the link:
http://wiki.xenproject.org/wiki/User:Pennpanda =E2=80=8B
I followed the Credit scheduler's wiki page to complete the RTDS'.
=E2=80=8B(I'm not sure how to add a title for that page as Credit scheduler=
 does.
:-( )=E2=80=8B

=E2=80=8BPlease let me know if you have any question. =E2=80=8B


=E2=80=8BThank you very much! :-)

Best,

Meng



--=20


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--089e01183a266aa9a0050a94c800
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">Hi =
Lars and Dario,</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2014-12-19 11:15 GMT-05:00 Dario Faggioli <span dir=3D"ltr">&lt;<a href=
=3D"mailto:dario.faggioli@citrix.com" target=3D"_blank">dario.faggioli@citr=
ix.com</a>&gt;</span>:<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 Fri, 2014-12=
-19 at 10:55 -0500, Meng Xu wrote:<br>
<br>
&gt; 2014-12-19 9:52 GMT-05:00 Lars Kurth &lt;<a href=3D"mailto:lars.kurth.=
xen@gmail.com">lars.kurth.xen@gmail.com</a>&gt;:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi all,<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please reply to the thread and I will=
 add that page.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0** The key changes normally are chang=
es to<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scalability/memory/etc. limits - mayb=
e Jan(x86) and Ian(ARM)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can look let me know of changes<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0** Also new platforms, changes to exp=
erimental features, etc.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0** Probably the new scheduler should =
be added - is there a<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wiki page?<br>
&gt;<br>
&gt;<br>
&gt; =E2=80=8BThe new scheduler (rtds) does not have a wiki page right now,=
 but it<br>
&gt; has an outside page to explain how it is designed and how it works<br>
&gt; at <a href=3D"https://sites.google.com/site/realtimexen/getting-starte=
d" target=3D"_blank">https://sites.google.com/site/realtimexen/getting-star=
ted</a>.<br>
&gt; =E2=80=8BI can add a wiki page very quickly today based on the pages o=
n =E2=80=8B<br>
&gt; <a href=3D"https://sites.google.com/site/realtimexen/" target=3D"_blan=
k">https://sites.google.com/site/realtimexen/</a> .<br>
&gt;<br>
</span>That would be great! :-)<br>
<br>
&gt; Is that ok?<br>
&gt;<br>
I think it is ok. Just make sure, when you do that, that you properly<br>
adapt the information and make them match what actually have been<br>
upstreamed (so command option names, limits of the implementation, etc.)<br=
>
<br>
Also, you should put in the wiki page a WARN about the fact that the<br>
scheduler has been included as an experimental and in-development<br>
feature.<br>
<br>
Share here a link when you&#39;re done, so we can go having a look. :-)<br>=
</blockquote><div><br></div><div><br></div><div><div class=3D"gmail_default=
" style=3D"font-size:small">=E2=80=8BI have finished the wiki page. Here is=
 the link: <a href=3D"http://wiki.xenproject.org/wiki/User:Pennpanda">http:=
//wiki.xenproject.org/wiki/User:Pennpanda</a> =E2=80=8B</div><div class=3D"=
gmail_default" style=3D"font-size:small">I followed the Credit scheduler&#3=
9;s wiki page to complete the RTDS&#39;.</div><div class=3D"gmail_default" =
style=3D"font-size:small">=E2=80=8B(I&#39;m not sure how to add a title for=
 that page as Credit scheduler does. :-( )=E2=80=8B</div><br></div><div><di=
v class=3D"gmail_default" style=3D"font-size:small">=E2=80=8BPlease let me =
know if you have any question. =E2=80=8B</div><br></div><div><br></div><div=
 class=3D"gmail_default" style=3D"font-size:small">=E2=80=8BThank you very =
much! :-)</div><div class=3D"gmail_default" style=3D"font-size:small"><br><=
/div><div class=3D"gmail_default" style=3D"font-size:small">Best,</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><br clear=3D"a=
ll"><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 Sc=
ience<br>University of Pennsylvania</div></div>
</div></div>

--089e01183a266aa9a0050a94c800--


--===============2722196543566601380==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2722196543566601380==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 17:10:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 17: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 1Y214J-0003f9-KF; Fri, 19 Dec 2014 17:10:23 +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 1Y214I-0003f4-IW
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 17:10:22 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	92/74-25276-DFB54945; Fri, 19 Dec 2014 17:10:21 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1419009017!16477849!1
X-Originating-IP: [209.85.218.51]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5353 invoked from network); 19 Dec 2014 17:10:18 -0000
Received: from mail-oi0-f51.google.com (HELO mail-oi0-f51.google.com)
	(209.85.218.51)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 17:10:18 -0000
Received: by mail-oi0-f51.google.com with SMTP id e131so2424387oig.10
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 09:10:17 -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=otaj3x3rfQy5XeAF0okr4pfLJ1Qtyo6cJ6WYHju0w5w=;
	b=GyP0YhDK2LEvOVt0NjyUuPFlgHl0gfjkYF0bqagvIEEJoNCxACvshiUw0kxRHGXYbQ
	hBwxlq9kkFttE9TcLbx/NBZSfOJ75Or6IfZ1TcEyQjUnvAKp3QkWTNLyHQO8M/X20ztU
	DHJY1y9FEmNMi7etXJBG2xTtR91yZarWCV0Iihg4t0z0zEgzVcGLUs/9bC06adFjenrw
	baVsX9eqztIqI80e8yf3VWU2X5repJGbI1CwnR8PS/wVM+WGiN85fuDOjhfKJw+Pi7L0
	BVvb6pwHtE+bmFDt7qVWEuS149y2eV5ctqRLRM895C66qU191x6S7MuAgK+E2o29ZT7Y
	58ug==
MIME-Version: 1.0
X-Received: by 10.60.161.47 with SMTP id xp15mr5493779oeb.16.1419009017421;
	Fri, 19 Dec 2014 09:10:17 -0800 (PST)
Received: by 10.76.128.18 with HTTP; Fri, 19 Dec 2014 09:10:17 -0800 (PST)
In-Reply-To: <1419005719.7060.21.camel@Abyss.station>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
	<CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
	<1419005719.7060.21.camel@Abyss.station>
Date: Fri, 19 Dec 2014 12:10:17 -0500
Message-ID: <CAENZ-+=CN8H7Yr3ki0CJC4D_a5v=uBAcx9C-XV6d=xgwNi-Vaw@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"Steve.VanderLeest@dornerworks.com" <Steve.VanderLeest@dornerworks.com>,
	"mengxu@cis.upenn.edu" <mengxu@cis.upenn.edu>,
	m.a.young@durham.ac.uk, chao.p.peng@linux.intel.com,
	"zhigang.x.wang@oracle.com" <zhigang.x.wang@oracle.com>,
	Parth Dixit <parth.dixit@linaro.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	manish jaggi <manishjaggi.oss@gmail.com>,
	"Paul.Skentzos@dornerworks.com" <Paul.Skentzos@dornerworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"guijianfeng@cn.fujitsu.com" <guijianfeng@cn.fujitsu.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sarah Conway <sconway@linuxfoundation.org>,
	Joshua Whitehead <josh.whitehead@dornerworks.com>,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	"feng.wu@intel.com" <feng.wu@intel.com>,
	"yjhyun.yoo@samsung.com" <yjhyun.yoo@samsung.com>,
	"olaf@aepfle.de" <olaf@aepfle.de>, Suriyan Ramasami <suriyan.r@gmail.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"wency@cn.fujitsu.com" <wency@cn.fujitsu.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>, "mcgrof@suse.com" <mcgrof@suse.com>,
	Julien Grall <julien.grall@linaro.org>, Thomas Leonard <talex5@gmail.com>,
	Robert VanVossen <robert.vanvossen@dornerworks.com>,
	Roy Franz <roy.franz@linaro.org>,
	"yang.z.zhang@intel.com" <yang.z.zhang@intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Russ Pavlicek <russell.pavlicek@xenproject.org>,
	Elena Ufimtseva <ufimtseva@gmail.com>, "andrii.tseglytskyi@globallogic.com"
	<andrii.tseglytskyi@globallogic.com>, "jgross@suse.com" <jgross@suse.com>,
	"dave.scott@citrix.com" <dave.scott@citrix.com>,
	"yanghy@cn.fujitsu.com" <yanghy@cn.fujitsu.com>,
	Wei Liu <Wei.Liu2@citrix.com>,
	"Vijaya.Kumar@caviumnetworks.com" <Vijaya.Kumar@caviumnetworks.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	"dslutz@verizon.com" <dslutz@verizon.com>,
	"ross.lagerwall@citrix.com" <ross.lagerwall@citrix.com>,
	"Aravind.Gopalakrishnan@amd.com" <Aravind.Gopalakrishnan@amd.com>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"aravindp@cisco.com" <aravindp@cisco.com>,
	"tiejun.chen@intel.com" <tiejun.chen@intel.com>,
	"malcolm.crossley@citrix.com" <malcolm.crossley@citrix.com>,
	Simon Cao <caobosimon@gmail.com>, tklengyel@sec.in.tum.de,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
	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="===============2722196543566601380=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2722196543566601380==
Content-Type: multipart/alternative; boundary=089e01183a266aa9a0050a94c800

--089e01183a266aa9a0050a94c800
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Lars and Dario,

2014-12-19 11:15 GMT-05:00 Dario Faggioli <dario.faggioli@citrix.com>:

> On Fri, 2014-12-19 at 10:55 -0500, Meng Xu wrote:
>
> > 2014-12-19 9:52 GMT-05:00 Lars Kurth <lars.kurth.xen@gmail.com>:
> >         Hi all,
> >
> >         Please reply to the thread and I will add that page.
> >         ** The key changes normally are changes to
> >         scalability/memory/etc. limits - maybe Jan(x86) and Ian(ARM)
> >         can look let me know of changes
> >         ** Also new platforms, changes to experimental features, etc.
> >         ** Probably the new scheduler should be added - is there a
> >         wiki page?
> >
> >
> > =E2=80=8BThe new scheduler (rtds) does not have a wiki page right now, =
but it
> > has an outside page to explain how it is designed and how it works
> > at https://sites.google.com/site/realtimexen/getting-started.
> > =E2=80=8BI can add a wiki page very quickly today based on the pages on=
 =E2=80=8B
> > https://sites.google.com/site/realtimexen/ .
> >
> That would be great! :-)
>
> > Is that ok?
> >
> I think it is ok. Just make sure, when you do that, that you properly
> adapt the information and make them match what actually have been
> upstreamed (so command option names, limits of the implementation, etc.)
>
> Also, you should put in the wiki page a WARN about the fact that the
> scheduler has been included as an experimental and in-development
> feature.
>
> Share here a link when you're done, so we can go having a look. :-)
>


=E2=80=8BI have finished the wiki page. Here is the link:
http://wiki.xenproject.org/wiki/User:Pennpanda =E2=80=8B
I followed the Credit scheduler's wiki page to complete the RTDS'.
=E2=80=8B(I'm not sure how to add a title for that page as Credit scheduler=
 does.
:-( )=E2=80=8B

=E2=80=8BPlease let me know if you have any question. =E2=80=8B


=E2=80=8BThank you very much! :-)

Best,

Meng



--=20


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--089e01183a266aa9a0050a94c800
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">Hi =
Lars and Dario,</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2014-12-19 11:15 GMT-05:00 Dario Faggioli <span dir=3D"ltr">&lt;<a href=
=3D"mailto:dario.faggioli@citrix.com" target=3D"_blank">dario.faggioli@citr=
ix.com</a>&gt;</span>:<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 Fri, 2014-12=
-19 at 10:55 -0500, Meng Xu wrote:<br>
<br>
&gt; 2014-12-19 9:52 GMT-05:00 Lars Kurth &lt;<a href=3D"mailto:lars.kurth.=
xen@gmail.com">lars.kurth.xen@gmail.com</a>&gt;:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi all,<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please reply to the thread and I will=
 add that page.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0** The key changes normally are chang=
es to<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scalability/memory/etc. limits - mayb=
e Jan(x86) and Ian(ARM)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can look let me know of changes<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0** Also new platforms, changes to exp=
erimental features, etc.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0** Probably the new scheduler should =
be added - is there a<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wiki page?<br>
&gt;<br>
&gt;<br>
&gt; =E2=80=8BThe new scheduler (rtds) does not have a wiki page right now,=
 but it<br>
&gt; has an outside page to explain how it is designed and how it works<br>
&gt; at <a href=3D"https://sites.google.com/site/realtimexen/getting-starte=
d" target=3D"_blank">https://sites.google.com/site/realtimexen/getting-star=
ted</a>.<br>
&gt; =E2=80=8BI can add a wiki page very quickly today based on the pages o=
n =E2=80=8B<br>
&gt; <a href=3D"https://sites.google.com/site/realtimexen/" target=3D"_blan=
k">https://sites.google.com/site/realtimexen/</a> .<br>
&gt;<br>
</span>That would be great! :-)<br>
<br>
&gt; Is that ok?<br>
&gt;<br>
I think it is ok. Just make sure, when you do that, that you properly<br>
adapt the information and make them match what actually have been<br>
upstreamed (so command option names, limits of the implementation, etc.)<br=
>
<br>
Also, you should put in the wiki page a WARN about the fact that the<br>
scheduler has been included as an experimental and in-development<br>
feature.<br>
<br>
Share here a link when you&#39;re done, so we can go having a look. :-)<br>=
</blockquote><div><br></div><div><br></div><div><div class=3D"gmail_default=
" style=3D"font-size:small">=E2=80=8BI have finished the wiki page. Here is=
 the link: <a href=3D"http://wiki.xenproject.org/wiki/User:Pennpanda">http:=
//wiki.xenproject.org/wiki/User:Pennpanda</a> =E2=80=8B</div><div class=3D"=
gmail_default" style=3D"font-size:small">I followed the Credit scheduler&#3=
9;s wiki page to complete the RTDS&#39;.</div><div class=3D"gmail_default" =
style=3D"font-size:small">=E2=80=8B(I&#39;m not sure how to add a title for=
 that page as Credit scheduler does. :-( )=E2=80=8B</div><br></div><div><di=
v class=3D"gmail_default" style=3D"font-size:small">=E2=80=8BPlease let me =
know if you have any question. =E2=80=8B</div><br></div><div><br></div><div=
 class=3D"gmail_default" style=3D"font-size:small">=E2=80=8BThank you very =
much! :-)</div><div class=3D"gmail_default" style=3D"font-size:small"><br><=
/div><div class=3D"gmail_default" style=3D"font-size:small">Best,</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><br clear=3D"a=
ll"><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 Sc=
ience<br>University of Pennsylvania</div></div>
</div></div>

--089e01183a266aa9a0050a94c800--


--===============2722196543566601380==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2722196543566601380==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 17:23:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 17: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 1Y21GG-0004S3-4D; Fri, 19 Dec 2014 17:22: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 1Y21GE-0004Ry-EQ
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 17:22:42 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	9E/50-27785-1EE54945; Fri, 19 Dec 2014 17:22:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419009760!16163730!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11052 invoked from network); 19 Dec 2014 17:22:40 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 17:22:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1419009760; l=2521;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=ls3s03lDQh5q2G+us7R2wRtRgHY=;
	b=SziJpw+Ig2oPwPGefHu7JsdD9lECnKAL8rkPYsUFMOIj9oalXVzQg/UX20D6Am58MwH
	GQXgoVuQDqlQO5iYYozkAInd37USRyeVPH0odthZRtVhekgbEYmaK+3zqdVMQRl6xsV2s
	vnwRIvq7p1LfIkYopRjFNzAtXMbjsGiAT2U=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id j05339qBJHMaXxk
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 18:22:36 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 781AC50161; Fri, 19 Dec 2014 18:22:35 +0100 (CET)
Date: Fri, 19 Dec 2014 18:22:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141219172234.GA14608@aepfle.de>
References: <1400589455-3964-1-git-send-email-mcgrof@do-not-panic.com>
	<1400678869.4856.88.camel@kazak.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1400678869.4856.88.camel@kazak.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xenproject.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Subject: Re: [Xen-devel] [PATCH] libxc: check return values on mmap() and
 madvise() on xc_alloc_hypercall_buffer()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please backport this patch to 4.4. 
Other branches may need the mmap() check as well. The callers expect
either NULL or a valid pointer.

It is upstream commit e86539a388314cd3dca88f5e69d7873343197cd8

Thanks,

Olaf

On Wed, May 21, Ian Campbell wrote:

> On Tue, 2014-05-20 at 05:37 -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > On a Thinkpad T4440p with OpenSUSE tumbleweed with v3.15-rc4
> > and today's latest xen tip from the git tree strace -f reveals
> > we end up on a never ending wait shortly after
> > 
> > write(20, "backend/console/5\0", 18 <unfinished ...>
> > 
> > This is right before we just wait on the qemu process which we
> > had mmap'd for. Without this you'll end up getting stuck on a
> > loop if mmap() worked but madvise() did not. While at it I noticed
> > even the mmap() error fail was not being checked, fix that too.
> > 
> > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com> and applied.
> 
> OOI why was madvise failing? (should be quite unusual I think?)
> 
> > ---
> >  tools/libxc/xc_linux_osdep.c | 20 +++++++++++++++++++-
> >  1 file changed, 19 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
> > index 73860a2..86bff3e 100644
> > --- a/tools/libxc/xc_linux_osdep.c
> > +++ b/tools/libxc/xc_linux_osdep.c
> > @@ -92,14 +92,32 @@ static void *linux_privcmd_alloc_hypercall_buffer(xc_interface *xch, xc_osdep_ha
> >  {
> >      size_t size = npages * XC_PAGE_SIZE;
> >      void *p;
> > +    int rc, saved_errno;
> >  
> >      /* Address returned by mmap is page aligned. */
> >      p = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED, -1, 0);
> > +    if ( p == MAP_FAILED )
> > +    {
> > +        PERROR("xc_alloc_hypercall_buffer: mmap failed");
> > +        return NULL;
> > +    }
> >  
> >      /* Do not copy the VMA to child process on fork. Avoid the page being COW
> >          on hypercall. */
> > -    madvise(p, npages * XC_PAGE_SIZE, MADV_DONTFORK);
> > +    rc = madvise(p, npages * XC_PAGE_SIZE, MADV_DONTFORK);
> > +    if ( rc < 0 )
> > +    {
> > +        PERROR("xc_alloc_hypercall_buffer: madvise failed");
> > +        goto out;
> > +    }
> > +
> >      return p;
> > +
> > +out:
> > +    saved_errno = errno;
> > +    (void)munmap(p, size);
> > +    errno = saved_errno;
> > +    return NULL;
> >  }
> >  
> >  static void linux_privcmd_free_hypercall_buffer(xc_interface *xch, xc_osdep_handle h, void *ptr, int npages)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 17:23:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 17: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 1Y21GG-0004S3-4D; Fri, 19 Dec 2014 17:22: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 1Y21GE-0004Ry-EQ
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 17:22:42 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	9E/50-27785-1EE54945; Fri, 19 Dec 2014 17:22:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419009760!16163730!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11052 invoked from network); 19 Dec 2014 17:22:40 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.216)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 17:22:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1419009760; l=2521;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=ls3s03lDQh5q2G+us7R2wRtRgHY=;
	b=SziJpw+Ig2oPwPGefHu7JsdD9lECnKAL8rkPYsUFMOIj9oalXVzQg/UX20D6Am58MwH
	GQXgoVuQDqlQO5iYYozkAInd37USRyeVPH0odthZRtVhekgbEYmaK+3zqdVMQRl6xsV2s
	vnwRIvq7p1LfIkYopRjFNzAtXMbjsGiAT2U=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id j05339qBJHMaXxk
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Fri, 19 Dec 2014 18:22:36 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 781AC50161; Fri, 19 Dec 2014 18:22:35 +0100 (CET)
Date: Fri, 19 Dec 2014 18:22:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20141219172234.GA14608@aepfle.de>
References: <1400589455-3964-1-git-send-email-mcgrof@do-not-panic.com>
	<1400678869.4856.88.camel@kazak.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1400678869.4856.88.camel@kazak.uk.xensource.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: xen-devel@lists.xenproject.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Subject: Re: [Xen-devel] [PATCH] libxc: check return values on mmap() and
 madvise() on xc_alloc_hypercall_buffer()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please backport this patch to 4.4. 
Other branches may need the mmap() check as well. The callers expect
either NULL or a valid pointer.

It is upstream commit e86539a388314cd3dca88f5e69d7873343197cd8

Thanks,

Olaf

On Wed, May 21, Ian Campbell wrote:

> On Tue, 2014-05-20 at 05:37 -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > On a Thinkpad T4440p with OpenSUSE tumbleweed with v3.15-rc4
> > and today's latest xen tip from the git tree strace -f reveals
> > we end up on a never ending wait shortly after
> > 
> > write(20, "backend/console/5\0", 18 <unfinished ...>
> > 
> > This is right before we just wait on the qemu process which we
> > had mmap'd for. Without this you'll end up getting stuck on a
> > loop if mmap() worked but madvise() did not. While at it I noticed
> > even the mmap() error fail was not being checked, fix that too.
> > 
> > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com> and applied.
> 
> OOI why was madvise failing? (should be quite unusual I think?)
> 
> > ---
> >  tools/libxc/xc_linux_osdep.c | 20 +++++++++++++++++++-
> >  1 file changed, 19 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
> > index 73860a2..86bff3e 100644
> > --- a/tools/libxc/xc_linux_osdep.c
> > +++ b/tools/libxc/xc_linux_osdep.c
> > @@ -92,14 +92,32 @@ static void *linux_privcmd_alloc_hypercall_buffer(xc_interface *xch, xc_osdep_ha
> >  {
> >      size_t size = npages * XC_PAGE_SIZE;
> >      void *p;
> > +    int rc, saved_errno;
> >  
> >      /* Address returned by mmap is page aligned. */
> >      p = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED, -1, 0);
> > +    if ( p == MAP_FAILED )
> > +    {
> > +        PERROR("xc_alloc_hypercall_buffer: mmap failed");
> > +        return NULL;
> > +    }
> >  
> >      /* Do not copy the VMA to child process on fork. Avoid the page being COW
> >          on hypercall. */
> > -    madvise(p, npages * XC_PAGE_SIZE, MADV_DONTFORK);
> > +    rc = madvise(p, npages * XC_PAGE_SIZE, MADV_DONTFORK);
> > +    if ( rc < 0 )
> > +    {
> > +        PERROR("xc_alloc_hypercall_buffer: madvise failed");
> > +        goto out;
> > +    }
> > +
> >      return p;
> > +
> > +out:
> > +    saved_errno = errno;
> > +    (void)munmap(p, size);
> > +    errno = saved_errno;
> > +    return NULL;
> >  }
> >  
> >  static void linux_privcmd_free_hypercall_buffer(xc_interface *xch, xc_osdep_handle h, void *ptr, int npages)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 18:03:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 18:03:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y21t4-00062N-QJ; Fri, 19 Dec 2014 18:02:50 +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 1Y21t3-00062I-UI
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 18:02:50 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	56/ED-02696-94864945; Fri, 19 Dec 2014 18:02:49 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1419012168!16253855!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27955 invoked from network); 19 Dec 2014 18:02:48 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 18:02:48 -0000
Received: by mail-wg0-f42.google.com with SMTP id k14so2021199wgh.1
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 10:02:47 -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
	:message-id:references:to;
	bh=DfeJkBOEz0DIZ4OZerBbhxI9qP+gtrkNJc7bOp4wilw=;
	b=ETfdHbweLFFp4giE3lATmPuuvyrQ4AS9H6XQkHu92MEIlP5D/udixZSQrNXAivODle
	fKEfmap5TapaSRGi+lvBX+SHFrTDyBWmR9V0Bnt6R5IbMIS4EBnsb914YL7eEFJNVM+a
	apWwD1VNYSGklEQHAVE6CKsRcY8LKaOhCmEJq9ketZwuENq6VGzAH2WCV8aq8B1l7npa
	ZReoXMYP83dWivwg/JLgLKvLizdyiJvhIcveigd0wSjUiN06avilCOWL9SiThF/unsA4
	6n4jtJm4dsm/1RLWLxbP+Q2Lc/fSZn7cLKD4kKGCa0ZgYioREQmmqExeAh1S4BywJyZI
	5l1w==
X-Received: by 10.180.108.167 with SMTP id hl7mr7995405wib.68.1419012167759;
	Fri, 19 Dec 2014 10:02:47 -0800 (PST)
Received: from [192.168.0.25] (97e5a0c2.skybroadband.com. [151.229.160.194])
	by mx.google.com with ESMTPSA id dp8sm3157876wib.20.2014.12.19.10.02.44
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 19 Dec 2014 10:02:46 -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: <CAENZ-+=CN8H7Yr3ki0CJC4D_a5v=uBAcx9C-XV6d=xgwNi-Vaw@mail.gmail.com>
Date: Fri, 19 Dec 2014 18:02:42 +0000
Message-Id: <B4141B76-112E-4188-89F2-2E03E383D2D3@gmail.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
	<CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
	<1419005719.7060.21.camel@Abyss.station>
	<CAENZ-+=CN8H7Yr3ki0CJC4D_a5v=uBAcx9C-XV6d=xgwNi-Vaw@mail.gmail.com>
To: Meng Xu <xumengpanda@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"Steve.VanderLeest@dornerworks.com" <Steve.VanderLeest@dornerworks.com>,
	"mengxu@cis.upenn.edu" <mengxu@cis.upenn.edu>,
	m.a.young@durham.ac.uk, chao.p.peng@linux.intel.com,
	"zhigang.x.wang@oracle.com" <zhigang.x.wang@oracle.com>,
	Parth Dixit <parth.dixit@linaro.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	manish jaggi <manishjaggi.oss@gmail.com>,
	"Paul.Skentzos@dornerworks.com" <Paul.Skentzos@dornerworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"guijianfeng@cn.fujitsu.com" <guijianfeng@cn.fujitsu.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sarah Conway <sconway@linuxfoundation.org>,
	Joshua Whitehead <josh.whitehead@dornerworks.com>,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	"feng.wu@intel.com" <feng.wu@intel.com>,
	"yjhyun.yoo@samsung.com" <yjhyun.yoo@samsung.com>,
	"olaf@aepfle.de" <olaf@aepfle.de>, Suriyan Ramasami <suriyan.r@gmail.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"wency@cn.fujitsu.com" <wency@cn.fujitsu.com>,
	"mcgrof@suse.com" <mcgrof@suse.com>,
	Julien Grall <julien.grall@linaro.org>, Thomas Leonard <talex5@gmail.com>,
	Robert VanVossen <robert.vanvossen@dornerworks.com>,
	Roy Franz <roy.franz@linaro.org>,
	"yang.z.zhang@intel.com" <yang.z.zhang@intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Russ Pavlicek <russell.pavlicek@xenproject.org>,
	Elena Ufimtseva <ufimtseva@gmail.com>, "andrii.tseglytskyi@globallogic.com"
	<andrii.tseglytskyi@globallogic.com>, "jgross@suse.com" <jgross@suse.com>,
	"dave.scott@citrix.com" <dave.scott@citrix.com>,
	"yanghy@cn.fujitsu.com" <yanghy@cn.fujitsu.com>,
	Wei Liu <Wei.Liu2@citrix.com>,
	"Vijaya.Kumar@caviumnetworks.com" <Vijaya.Kumar@caviumnetworks.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	"dslutz@verizon.com" <dslutz@verizon.com>,
	"ross.lagerwall@citrix.com" <ross.lagerwall@citrix.com>,
	"Aravind.Gopalakrishnan@amd.com" <Aravind.Gopalakrishnan@amd.com>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"aravindp@cisco.com" <aravindp@cisco.com>,
	"tiejun.chen@intel.com" <tiejun.chen@intel.com>,
	"malcolm.crossley@citrix.com" <malcolm.crossley@citrix.com>,
	Simon Cao <caobosimon@gmail.com>, tklengyel@sec.in.tum.de,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
	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="===============2951058960740850880=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2951058960740850880==
Content-Type: multipart/alternative; boundary="Apple-Mail=_425774D7-C13F-4E3F-8C2C-085454BC287B"


--Apple-Mail=_425774D7-C13F-4E3F-8C2C-085454BC287B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


On 19 Dec 2014, at 17:10, Meng Xu <xumengpanda@gmail.com> wrote:
>=20
> =E2=80=8BI have finished the wiki page. Here is the link: =
http://wiki.xenproject.org/wiki/User:Pennpanda =E2=80=8B
> I followed the Credit scheduler's wiki page to complete the RTDS'.
> =E2=80=8B(I'm not sure how to add a title for that page as Credit =
scheduler does. :-( )=E2=80=8B
>=20
> =E2=80=8BPlease let me know if you have any question. =E2=80=8B
>=20
Thank you Meng: I will move the content to a page called =
RTDS-Based-Scheduler of there are no objections

Lars=

--Apple-Mail=_425774D7-C13F-4E3F-8C2C-085454BC287B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On 19 Dec 2014, at 17:10, Meng Xu =
&lt;<a href=3D"mailto:xumengpanda@gmail.com">xumengpanda@gmail.com</a>&gt;=
 wrote:</div><blockquote type=3D"cite"><div style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div><div =
class=3D"gmail_default" style=3D"font-size: small;">=E2=80=8BI have =
finished the wiki page. Here is the link:<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"http://wiki.xenproject.org/wiki/User:Pennpanda">http://wiki.xenpro=
ject.org/wiki/User:Pennpanda</a><span =
class=3D"Apple-converted-space">&nbsp;</span>=E2=80=8B</div><div =
class=3D"gmail_default" style=3D"font-size: small;">I followed the =
Credit scheduler's wiki page to complete the RTDS'.</div><div =
class=3D"gmail_default" style=3D"font-size: small;">=E2=80=8B(I'm not =
sure how to add a title for that page as Credit scheduler does. :-( =
)=E2=80=8B</div><br></div><div><div class=3D"gmail_default" =
style=3D"font-size: small;">=E2=80=8BPlease let me know if you have any =
question. =E2=80=8B</div><br></div></div></div></div></div></blockquote>Th=
ank you Meng: I will move the content to a page called =
RTDS-Based-Scheduler of there are no =
objections</div><br><div>Lars</div></body></html>=

--Apple-Mail=_425774D7-C13F-4E3F-8C2C-085454BC287B--


--===============2951058960740850880==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2951058960740850880==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 18:03:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 18:03:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y21t4-00062N-QJ; Fri, 19 Dec 2014 18:02:50 +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 1Y21t3-00062I-UI
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 18:02:50 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	56/ED-02696-94864945; Fri, 19 Dec 2014 18:02:49 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1419012168!16253855!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27955 invoked from network); 19 Dec 2014 18:02:48 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 18:02:48 -0000
Received: by mail-wg0-f42.google.com with SMTP id k14so2021199wgh.1
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 10:02:47 -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
	:message-id:references:to;
	bh=DfeJkBOEz0DIZ4OZerBbhxI9qP+gtrkNJc7bOp4wilw=;
	b=ETfdHbweLFFp4giE3lATmPuuvyrQ4AS9H6XQkHu92MEIlP5D/udixZSQrNXAivODle
	fKEfmap5TapaSRGi+lvBX+SHFrTDyBWmR9V0Bnt6R5IbMIS4EBnsb914YL7eEFJNVM+a
	apWwD1VNYSGklEQHAVE6CKsRcY8LKaOhCmEJq9ketZwuENq6VGzAH2WCV8aq8B1l7npa
	ZReoXMYP83dWivwg/JLgLKvLizdyiJvhIcveigd0wSjUiN06avilCOWL9SiThF/unsA4
	6n4jtJm4dsm/1RLWLxbP+Q2Lc/fSZn7cLKD4kKGCa0ZgYioREQmmqExeAh1S4BywJyZI
	5l1w==
X-Received: by 10.180.108.167 with SMTP id hl7mr7995405wib.68.1419012167759;
	Fri, 19 Dec 2014 10:02:47 -0800 (PST)
Received: from [192.168.0.25] (97e5a0c2.skybroadband.com. [151.229.160.194])
	by mx.google.com with ESMTPSA id dp8sm3157876wib.20.2014.12.19.10.02.44
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 19 Dec 2014 10:02:46 -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: <CAENZ-+=CN8H7Yr3ki0CJC4D_a5v=uBAcx9C-XV6d=xgwNi-Vaw@mail.gmail.com>
Date: Fri, 19 Dec 2014 18:02:42 +0000
Message-Id: <B4141B76-112E-4188-89F2-2E03E383D2D3@gmail.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
	<CAENZ-+nhy=UXx8zHBBLzXBiLmz6dHcQWeOsJUPZ0G9JjXf83sQ@mail.gmail.com>
	<1419005719.7060.21.camel@Abyss.station>
	<CAENZ-+=CN8H7Yr3ki0CJC4D_a5v=uBAcx9C-XV6d=xgwNi-Vaw@mail.gmail.com>
To: Meng Xu <xumengpanda@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"Steve.VanderLeest@dornerworks.com" <Steve.VanderLeest@dornerworks.com>,
	"mengxu@cis.upenn.edu" <mengxu@cis.upenn.edu>,
	m.a.young@durham.ac.uk, chao.p.peng@linux.intel.com,
	"zhigang.x.wang@oracle.com" <zhigang.x.wang@oracle.com>,
	Parth Dixit <parth.dixit@linaro.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	manish jaggi <manishjaggi.oss@gmail.com>,
	"Paul.Skentzos@dornerworks.com" <Paul.Skentzos@dornerworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"guijianfeng@cn.fujitsu.com" <guijianfeng@cn.fujitsu.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sarah Conway <sconway@linuxfoundation.org>,
	Joshua Whitehead <josh.whitehead@dornerworks.com>,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Serge Broslavsky <serge.broslavsky@linaro.org>,
	"feng.wu@intel.com" <feng.wu@intel.com>,
	"yjhyun.yoo@samsung.com" <yjhyun.yoo@samsung.com>,
	"olaf@aepfle.de" <olaf@aepfle.de>, Suriyan Ramasami <suriyan.r@gmail.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"wency@cn.fujitsu.com" <wency@cn.fujitsu.com>,
	"mcgrof@suse.com" <mcgrof@suse.com>,
	Julien Grall <julien.grall@linaro.org>, Thomas Leonard <talex5@gmail.com>,
	Robert VanVossen <robert.vanvossen@dornerworks.com>,
	Roy Franz <roy.franz@linaro.org>,
	"yang.z.zhang@intel.com" <yang.z.zhang@intel.com>,
	"Paul.Durrant@citrix.com" <Paul.Durrant@citrix.com>,
	Russ Pavlicek <russell.pavlicek@xenproject.org>,
	Elena Ufimtseva <ufimtseva@gmail.com>, "andrii.tseglytskyi@globallogic.com"
	<andrii.tseglytskyi@globallogic.com>, "jgross@suse.com" <jgross@suse.com>,
	"dave.scott@citrix.com" <dave.scott@citrix.com>,
	"yanghy@cn.fujitsu.com" <yanghy@cn.fujitsu.com>,
	Wei Liu <Wei.Liu2@citrix.com>,
	"Vijaya.Kumar@caviumnetworks.com" <Vijaya.Kumar@caviumnetworks.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	Kelly Zytaruk <Kelly.Zytaruk@amd.com>,
	"dslutz@verizon.com" <dslutz@verizon.com>,
	"ross.lagerwall@citrix.com" <ross.lagerwall@citrix.com>,
	"Aravind.Gopalakrishnan@amd.com" <Aravind.Gopalakrishnan@amd.com>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"aravindp@cisco.com" <aravindp@cisco.com>,
	"tiejun.chen@intel.com" <tiejun.chen@intel.com>,
	"malcolm.crossley@citrix.com" <malcolm.crossley@citrix.com>,
	Simon Cao <caobosimon@gmail.com>, tklengyel@sec.in.tum.de,
	Christoffer Dall <christoffer.dall@linaro.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
	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="===============2951058960740850880=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2951058960740850880==
Content-Type: multipart/alternative; boundary="Apple-Mail=_425774D7-C13F-4E3F-8C2C-085454BC287B"


--Apple-Mail=_425774D7-C13F-4E3F-8C2C-085454BC287B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


On 19 Dec 2014, at 17:10, Meng Xu <xumengpanda@gmail.com> wrote:
>=20
> =E2=80=8BI have finished the wiki page. Here is the link: =
http://wiki.xenproject.org/wiki/User:Pennpanda =E2=80=8B
> I followed the Credit scheduler's wiki page to complete the RTDS'.
> =E2=80=8B(I'm not sure how to add a title for that page as Credit =
scheduler does. :-( )=E2=80=8B
>=20
> =E2=80=8BPlease let me know if you have any question. =E2=80=8B
>=20
Thank you Meng: I will move the content to a page called =
RTDS-Based-Scheduler of there are no objections

Lars=

--Apple-Mail=_425774D7-C13F-4E3F-8C2C-085454BC287B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On 19 Dec 2014, at 17:10, Meng Xu =
&lt;<a href=3D"mailto:xumengpanda@gmail.com">xumengpanda@gmail.com</a>&gt;=
 wrote:</div><blockquote type=3D"cite"><div style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div><div =
class=3D"gmail_default" style=3D"font-size: small;">=E2=80=8BI have =
finished the wiki page. Here is the link:<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"http://wiki.xenproject.org/wiki/User:Pennpanda">http://wiki.xenpro=
ject.org/wiki/User:Pennpanda</a><span =
class=3D"Apple-converted-space">&nbsp;</span>=E2=80=8B</div><div =
class=3D"gmail_default" style=3D"font-size: small;">I followed the =
Credit scheduler's wiki page to complete the RTDS'.</div><div =
class=3D"gmail_default" style=3D"font-size: small;">=E2=80=8B(I'm not =
sure how to add a title for that page as Credit scheduler does. :-( =
)=E2=80=8B</div><br></div><div><div class=3D"gmail_default" =
style=3D"font-size: small;">=E2=80=8BPlease let me know if you have any =
question. =E2=80=8B</div><br></div></div></div></div></div></blockquote>Th=
ank you Meng: I will move the content to a page called =
RTDS-Based-Scheduler of there are no =
objections</div><br><div>Lars</div></body></html>=

--Apple-Mail=_425774D7-C13F-4E3F-8C2C-085454BC287B--


--===============2951058960740850880==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2951058960740850880==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 19:08:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 19:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y22th-00088n-7j; Fri, 19 Dec 2014 19:07: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 1Y22tf-00088i-4e
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 19:07:31 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	8C/4E-16982-27774945; Fri, 19 Dec 2014 19:07:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1419016048!14634411!1
X-Originating-IP: [156.151.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 15719 invoked from network); 19 Dec 2014 19:07:29 -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; 19 Dec 2014 19:07: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 sBJJ7QBF009433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 19:07:27 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
	sBJJ7PE6000233
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 19:07:26 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
	sBJJ7Pbl000214; Fri, 19 Dec 2014 19:07:25 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 11:07:25 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6BD8D126068; Fri, 19 Dec 2014 13:13:41 -0500 (EST)
Date: Fri, 19 Dec 2014 13:13:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141219181341.GA7162@laptop.dumpdata.com>
References: <54943AB20200007800051059@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54943AB20200007800051059@mail.emea.novell.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>
Subject: Re: [Xen-devel] patch ping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 19, 2014 at 01:48:18PM +0000, Jan Beulich wrote:
> Konrad,
> 
> any word on
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01253.html

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01370.html

Shouldn't that have Reported-by: Sander..?
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01485.html

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> sent several days ago (there were more earlier today) for 4.5?
> 
> 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 Dec 19 19:08:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 19:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y22tv-00089G-Kq; Fri, 19 Dec 2014 19:07: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 1Y22tv-000898-5W
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 19:07:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B6/55-25276-28774945; Fri, 19 Dec 2014 19:07:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1419016052!16851020!1
X-Originating-IP: [156.151.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 19090 invoked from network); 19 Dec 2014 19:07:33 -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 Dec 2014 19:07: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 sBJJ7QSm009429
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 19:07:27 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
	sBJJ7PA0027486
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 19:07:26 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
	sBJJ7PF6008079; Fri, 19 Dec 2014 19:07:25 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 11:07:25 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3323412606B; Fri, 19 Dec 2014 13:14:47 -0500 (EST)
Date: Fri, 19 Dec 2014 13:14:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141219181447.GB7162@laptop.dumpdata.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
	<20141216204900.GB11551@konrad-lan.dumpdata.com>
	<54944210.6050402@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54944210.6050402@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 19, 2014 at 03:19:44PM +0000, Andrew Cooper wrote:
> On 16/12/14 20:49, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 16, 2014 at 05:43:08PM +0000, Andrew Cooper wrote:
> >> On 16/12/14 16:13, konrad.wilk@oracle.com wrote:
> >>> Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
> >>> we have the General Release on Jan 7th!
> >>>
> >>> Details for the test-day are at
> >>>
> >>> http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions
> >>>
> >>> In terms of bugs, we have:
> >> From the XenServer testing.
> > Thank you for doing this testing!
> >> * Fail to reliably boot on IBM Flex x222 blades, apparent regression
> >> from 4.4
> >>
> >> I have declared this a latent BIOS bug, and not a regression from 4.4. 
> >> Across regular reboots, the exact positions of the ACPI tables, and the
> >> e820 layout is unstable.  The first consistent difference between 4.4
> >> and 4.5 is that 4.4 reports 1 MBR signature while 4.5 reports 0.  This
> >> is because the int $0x13, ah=2 call is returning differently.  I can get
> >> the call to return differently (and correctly for 4.5) by simply making
> >> the boot trampoline larger (with my debugging routines but not being
> >> called).
> > This sounds very familiar, but I can't place where I saw mention of
> > a similar issue.
> >> * VM fail to resume on upgrade from Xen < 4.5
> >>
> >> This is the issue I am currently looking into.  Currently, all the
> >> "upgrade from older XenServer" tests are failing due to VMs crashing on
> >> resume.  I have not yet identified whether this is a XenServer issue or
> > Ugh.
> 
> I have got to the bottom of this, and it it turns out to be a legacy ->
> migration v2 conversion bug which only surfaced now because Xen-4.5 is
> more strict than Xen-4.4.
> 
> HVM_PARAM_PAE_ENABLED is sent out-of-band in legacy, but passed to
> xc_domain_restore(), which does a set_param(), unconnected with any
> contents of the stream.  Migration v2 saves and restores it properly,
> but the legacy -> v2 conversion neglected to combine the out-of-band
> information.  No VMs blew up because all versions of Xen at that point
> were not correctly auditing updates to cr4 against the domain cpuid
> policy.  Xen-4.5 now does, causing #GP faults on cr4 writes for guests
> which had PAE enabled before migrate.
> 
> I shall be fixing this in the migration v2 series, and also looking for
> any other obvious out-of-band information which needs injecting into a
> converted stream.
> 
> 
> With this fixed(^W hacked around for now), I have identified and solved
> all discrepancies XenServer testing has noticed between Xen-4.4 and
> Xen-4.5 so far.
> 
> There will be another full nightly test happening tonight (based on c/s
> 7e88c23 "libxl: Tell qemu to use raw format when using a tapdisk"), and
> some stress and scale tests if time allows.

Yeey! thank you for getting to this!
> 
> ~Andrew
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 19:08:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 19:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y22th-00088n-7j; Fri, 19 Dec 2014 19:07: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 1Y22tf-00088i-4e
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 19:07:31 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	8C/4E-16982-27774945; Fri, 19 Dec 2014 19:07:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1419016048!14634411!1
X-Originating-IP: [156.151.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 15719 invoked from network); 19 Dec 2014 19:07:29 -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; 19 Dec 2014 19:07: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 sBJJ7QBF009433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 19:07:27 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
	sBJJ7PE6000233
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 19:07:26 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
	sBJJ7Pbl000214; Fri, 19 Dec 2014 19:07:25 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 11:07:25 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 6BD8D126068; Fri, 19 Dec 2014 13:13:41 -0500 (EST)
Date: Fri, 19 Dec 2014 13:13:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141219181341.GA7162@laptop.dumpdata.com>
References: <54943AB20200007800051059@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54943AB20200007800051059@mail.emea.novell.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>
Subject: Re: [Xen-devel] patch ping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 19, 2014 at 01:48:18PM +0000, Jan Beulich wrote:
> Konrad,
> 
> any word on
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01253.html

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01370.html

Shouldn't that have Reported-by: Sander..?
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01485.html

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> sent several days ago (there were more earlier today) for 4.5?
> 
> 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 Dec 19 19:08:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 19:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y22tv-00089G-Kq; Fri, 19 Dec 2014 19:07: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 1Y22tv-000898-5W
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 19:07:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B6/55-25276-28774945; Fri, 19 Dec 2014 19:07:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1419016052!16851020!1
X-Originating-IP: [156.151.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 19090 invoked from network); 19 Dec 2014 19:07:33 -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 Dec 2014 19:07: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 sBJJ7QSm009429
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 19:07:27 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
	sBJJ7PA0027486
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 19:07:26 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
	sBJJ7PF6008079; Fri, 19 Dec 2014 19:07:25 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 11:07:25 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 3323412606B; Fri, 19 Dec 2014 13:14:47 -0500 (EST)
Date: Fri, 19 Dec 2014 13:14:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141219181447.GB7162@laptop.dumpdata.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
	<20141216204900.GB11551@konrad-lan.dumpdata.com>
	<54944210.6050402@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54944210.6050402@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 19, 2014 at 03:19:44PM +0000, Andrew Cooper wrote:
> On 16/12/14 20:49, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 16, 2014 at 05:43:08PM +0000, Andrew Cooper wrote:
> >> On 16/12/14 16:13, konrad.wilk@oracle.com wrote:
> >>> Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
> >>> we have the General Release on Jan 7th!
> >>>
> >>> Details for the test-day are at
> >>>
> >>> http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions
> >>>
> >>> In terms of bugs, we have:
> >> From the XenServer testing.
> > Thank you for doing this testing!
> >> * Fail to reliably boot on IBM Flex x222 blades, apparent regression
> >> from 4.4
> >>
> >> I have declared this a latent BIOS bug, and not a regression from 4.4. 
> >> Across regular reboots, the exact positions of the ACPI tables, and the
> >> e820 layout is unstable.  The first consistent difference between 4.4
> >> and 4.5 is that 4.4 reports 1 MBR signature while 4.5 reports 0.  This
> >> is because the int $0x13, ah=2 call is returning differently.  I can get
> >> the call to return differently (and correctly for 4.5) by simply making
> >> the boot trampoline larger (with my debugging routines but not being
> >> called).
> > This sounds very familiar, but I can't place where I saw mention of
> > a similar issue.
> >> * VM fail to resume on upgrade from Xen < 4.5
> >>
> >> This is the issue I am currently looking into.  Currently, all the
> >> "upgrade from older XenServer" tests are failing due to VMs crashing on
> >> resume.  I have not yet identified whether this is a XenServer issue or
> > Ugh.
> 
> I have got to the bottom of this, and it it turns out to be a legacy ->
> migration v2 conversion bug which only surfaced now because Xen-4.5 is
> more strict than Xen-4.4.
> 
> HVM_PARAM_PAE_ENABLED is sent out-of-band in legacy, but passed to
> xc_domain_restore(), which does a set_param(), unconnected with any
> contents of the stream.  Migration v2 saves and restores it properly,
> but the legacy -> v2 conversion neglected to combine the out-of-band
> information.  No VMs blew up because all versions of Xen at that point
> were not correctly auditing updates to cr4 against the domain cpuid
> policy.  Xen-4.5 now does, causing #GP faults on cr4 writes for guests
> which had PAE enabled before migrate.
> 
> I shall be fixing this in the migration v2 series, and also looking for
> any other obvious out-of-band information which needs injecting into a
> converted stream.
> 
> 
> With this fixed(^W hacked around for now), I have identified and solved
> all discrepancies XenServer testing has noticed between Xen-4.4 and
> Xen-4.5 so far.
> 
> There will be another full nightly test happening tonight (based on c/s
> 7e88c23 "libxl: Tell qemu to use raw format when using a tapdisk"), and
> some stress and scale tests if time allows.

Yeey! thank you for getting to this!
> 
> ~Andrew
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 19:08:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 19:08:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y22ud-0008Ev-FG; Fri, 19 Dec 2014 19:08:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y22uc-0008Eg-2c
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 19:08:30 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	56/40-07724-DA774945; Fri, 19 Dec 2014 19:08:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1419016107!14594082!1
X-Originating-IP: [156.151.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 24747 invoked from network); 19 Dec 2014 19:08:28 -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; 19 Dec 2014 19:08: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 sBJJ8PH9010557
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 19:08:25 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
	sBJJ8OYR009477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 19:08:25 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
	sBJJ8OOG010801; Fri, 19 Dec 2014 19:08:24 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 11:08:24 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 94EF8126096; Fri, 19 Dec 2014 14:08:23 -0500 (EST)
Date: Fri, 19 Dec 2014 14:08:23 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141219190823.GA9213@laptop.dumpdata.com>
References: <5494173E0200007800050F59@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5494173E0200007800050F59@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] EFI: suppress bogus loader warning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 19, 2014 at 11:17:02AM +0000, Jan Beulich wrote:
> This was accidentally lost in commit fbc3d9a220 ("EFI: add
> efi_arch_handle_cmdline() for processing commandline"), leading to the
> "Unknown command line option" warning being printed whenever options
> get passed to the core hypervisor or the Dom0 kernel.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -311,6 +311,7 @@ static unsigned int __init get_argv(unsi
>                  ++argc;
>              else if ( prev && wstrcmp(prev, L"--") == 0 )
>              {
> +                --argv;
>                  if ( options )
>                      *options = cmdline;
>                  break;
> 
> 
> 

> EFI: suppress bogus loader warning
> 
> This was accidentally lost in commit fbc3d9a220 ("EFI: add
> efi_arch_handle_cmdline() for processing commandline"), leading to the
> "Unknown command line option" warning being printed whenever options
> get passed to the core hypervisor or the Dom0 kernel.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -311,6 +311,7 @@ static unsigned int __init get_argv(unsi
>                  ++argc;
>              else if ( prev && wstrcmp(prev, L"--") == 0 )
>              {
> +                --argv;
>                  if ( options )
>                      *options = cmdline;
>                  break;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 19:08:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 19:08:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y22ud-0008Ev-FG; Fri, 19 Dec 2014 19:08:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y22uc-0008Eg-2c
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 19:08:30 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	56/40-07724-DA774945; Fri, 19 Dec 2014 19:08:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1419016107!14594082!1
X-Originating-IP: [156.151.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 24747 invoked from network); 19 Dec 2014 19:08:28 -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; 19 Dec 2014 19:08: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 sBJJ8PH9010557
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 19:08:25 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
	sBJJ8OYR009477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 19:08:25 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
	sBJJ8OOG010801; Fri, 19 Dec 2014 19:08:24 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 11:08:24 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 94EF8126096; Fri, 19 Dec 2014 14:08:23 -0500 (EST)
Date: Fri, 19 Dec 2014 14:08:23 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141219190823.GA9213@laptop.dumpdata.com>
References: <5494173E0200007800050F59@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5494173E0200007800050F59@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] EFI: suppress bogus loader warning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 19, 2014 at 11:17:02AM +0000, Jan Beulich wrote:
> This was accidentally lost in commit fbc3d9a220 ("EFI: add
> efi_arch_handle_cmdline() for processing commandline"), leading to the
> "Unknown command line option" warning being printed whenever options
> get passed to the core hypervisor or the Dom0 kernel.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -311,6 +311,7 @@ static unsigned int __init get_argv(unsi
>                  ++argc;
>              else if ( prev && wstrcmp(prev, L"--") == 0 )
>              {
> +                --argv;
>                  if ( options )
>                      *options = cmdline;
>                  break;
> 
> 
> 

> EFI: suppress bogus loader warning
> 
> This was accidentally lost in commit fbc3d9a220 ("EFI: add
> efi_arch_handle_cmdline() for processing commandline"), leading to the
> "Unknown command line option" warning being printed whenever options
> get passed to the core hypervisor or the Dom0 kernel.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -311,6 +311,7 @@ static unsigned int __init get_argv(unsi
>                  ++argc;
>              else if ( prev && wstrcmp(prev, L"--") == 0 )
>              {
> +                --argv;
>                  if ( options )
>                      *options = cmdline;
>                  break;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 19:11:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 19:11:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y22x1-0008T6-1B; Fri, 19 Dec 2014 19:10: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 1Y22x0-0008St-FA
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 19:10:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A8/67-25276-14874945; Fri, 19 Dec 2014 19:10:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1419016255!9538787!1
X-Originating-IP: [156.151.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 28329 invoked from network); 19 Dec 2014 19:10:57 -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; 19 Dec 2014 19:10:57 -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 sBJJAYGk012900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 19:10:35 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
	sBJJAXZQ017320
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 19:10:34 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
	sBJJAXgq017305; Fri, 19 Dec 2014 19:10:33 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 11:10:33 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8907812609C; Fri, 19 Dec 2014 14:10:32 -0500 (EST)
Date: Fri, 19 Dec 2014 14:10:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141219191032.GB9213@laptop.dumpdata.com>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418988333-5404-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: m.a.young@durham.ac.uk, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes 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 Fri, Dec 19, 2014 at 12:25:26PM +0100, Olaf Hering wrote:
> This is a resend of these two series:
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00858.html
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
> 
> New in v3 is a wrapper to run xenstored. See its patch description
> for details.
> 
> Patch 2-6 should be applied for 4.5.0.
> 
> The first and the last one still has issues with xenstored and
> SELinux. See below.  Up to now no solution is known to me.
> 
> 
> The first patch fixes Arch Linux and does not break anything.  As such
> it should be safe to be applied for 4.5.0.  SELinux users (who build
> from source) should put their special mount options into fstab. Distro

Could you elaborate what that is? As in what is that 'special mount options'?

> packages will most likely include a proper .service file.
> 
> 
> The last patch addresses the XENSTORED_TRACE issue. But SELinux will
> most likely still not work.
> 
> Possible ways to handle launching xenstored and SELinux:
> 
> - do nothing
>   pro: - no Xen source changes required
>   con: - possible unhappy users who build from source and still have
>          SELinux enabled

At this stage I prefer this and just have in the release notes the
work-around documented.
> 
> - use newly added wrapper
>   pro: - XENSTORED_TRACE boolean is handled
>   con: - the wrapper may have the very same issue as the current
>          launching with sh -c 'exec xenstored'. But maybe there is a
> 	 way to mark the new wrapper script as "this is the native
> 	 xenstored". Someone familiar with SELinux may be able to
> 	 answer this.
> 
> - Use ExecStart=@XENSTORED@
>   pro: - socket passing will most likely work
>   con: - All options have to be passed in XENSTORED_ARGS, a new variable
>          which is not yet mentioned in the sysconfig file.
>        - Switching xenstored requires a private copy of
> 	 xenstored.service in /etc/systemd instead of adjusting the
> 	 XENSTORED= variable in the sysconfig file.
> 
> - Use ExecStart=/usr/bin/env $XENSTORED
>   pro: - $XENSTORED can be set in sysconfig file
>   con: - may have the same socket issue as starting via shell
>        - XENSTORED_TRACE boolean is not handled
> 
> 
> I will be offline until 2015-01-07, so any further adjustments to this
> series has to be done by someone else.
> 
> 
> Good luck!
> 
> Olaf
> 
> 
> Olaf Hering (7):
>   tools/hotplug: remove SELinux options from var-lib-xenstored.mount
>   tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service
>   tools/hotplug: xendomains.service depends on network
>   tools/hotplug: use xencommons as EnvironmentFile in
>     xenconsoled.service
>   tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service
>   tools/hotplug: remove EnvironmentFile from
>     xen-qemu-dom0-disk-backend.service
>   tools/hotplug: add wrapper to start xenstored
> 
>  .gitignore                                                        | 1 +
>  tools/configure                                                   | 3 ++-
>  tools/configure.ac                                                | 1 +
>  tools/hotplug/Linux/Makefile                                      | 2 ++
>  tools/hotplug/Linux/init.d/xencommons.in                          | 6 ++++--
>  tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 4 +---
>  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
>  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 6 +++---
>  tools/hotplug/Linux/systemd/xendomains.service.in                 | 2 ++
>  tools/hotplug/Linux/systemd/xenstored.service.in                  | 6 ++----
>  tools/hotplug/Linux/xenstored.sh.in                               | 6 ++++++
>  11 files changed, 24 insertions(+), 14 deletions(-)
>  create mode 100644 tools/hotplug/Linux/xenstored.sh.in
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 19:11:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 19:11:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y22x1-0008T6-1B; Fri, 19 Dec 2014 19:10: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 1Y22x0-0008St-FA
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 19:10:58 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	A8/67-25276-14874945; Fri, 19 Dec 2014 19:10:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1419016255!9538787!1
X-Originating-IP: [156.151.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 28329 invoked from network); 19 Dec 2014 19:10:57 -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; 19 Dec 2014 19:10:57 -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 sBJJAYGk012900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 19:10:35 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
	sBJJAXZQ017320
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 19:10:34 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
	sBJJAXgq017305; Fri, 19 Dec 2014 19:10:33 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 11:10:33 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id 8907812609C; Fri, 19 Dec 2014 14:10:32 -0500 (EST)
Date: Fri, 19 Dec 2014 14:10:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141219191032.GB9213@laptop.dumpdata.com>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418988333-5404-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: m.a.young@durham.ac.uk, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes 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 Fri, Dec 19, 2014 at 12:25:26PM +0100, Olaf Hering wrote:
> This is a resend of these two series:
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00858.html
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
> 
> New in v3 is a wrapper to run xenstored. See its patch description
> for details.
> 
> Patch 2-6 should be applied for 4.5.0.
> 
> The first and the last one still has issues with xenstored and
> SELinux. See below.  Up to now no solution is known to me.
> 
> 
> The first patch fixes Arch Linux and does not break anything.  As such
> it should be safe to be applied for 4.5.0.  SELinux users (who build
> from source) should put their special mount options into fstab. Distro

Could you elaborate what that is? As in what is that 'special mount options'?

> packages will most likely include a proper .service file.
> 
> 
> The last patch addresses the XENSTORED_TRACE issue. But SELinux will
> most likely still not work.
> 
> Possible ways to handle launching xenstored and SELinux:
> 
> - do nothing
>   pro: - no Xen source changes required
>   con: - possible unhappy users who build from source and still have
>          SELinux enabled

At this stage I prefer this and just have in the release notes the
work-around documented.
> 
> - use newly added wrapper
>   pro: - XENSTORED_TRACE boolean is handled
>   con: - the wrapper may have the very same issue as the current
>          launching with sh -c 'exec xenstored'. But maybe there is a
> 	 way to mark the new wrapper script as "this is the native
> 	 xenstored". Someone familiar with SELinux may be able to
> 	 answer this.
> 
> - Use ExecStart=@XENSTORED@
>   pro: - socket passing will most likely work
>   con: - All options have to be passed in XENSTORED_ARGS, a new variable
>          which is not yet mentioned in the sysconfig file.
>        - Switching xenstored requires a private copy of
> 	 xenstored.service in /etc/systemd instead of adjusting the
> 	 XENSTORED= variable in the sysconfig file.
> 
> - Use ExecStart=/usr/bin/env $XENSTORED
>   pro: - $XENSTORED can be set in sysconfig file
>   con: - may have the same socket issue as starting via shell
>        - XENSTORED_TRACE boolean is not handled
> 
> 
> I will be offline until 2015-01-07, so any further adjustments to this
> series has to be done by someone else.
> 
> 
> Good luck!
> 
> Olaf
> 
> 
> Olaf Hering (7):
>   tools/hotplug: remove SELinux options from var-lib-xenstored.mount
>   tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service
>   tools/hotplug: xendomains.service depends on network
>   tools/hotplug: use xencommons as EnvironmentFile in
>     xenconsoled.service
>   tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service
>   tools/hotplug: remove EnvironmentFile from
>     xen-qemu-dom0-disk-backend.service
>   tools/hotplug: add wrapper to start xenstored
> 
>  .gitignore                                                        | 1 +
>  tools/configure                                                   | 3 ++-
>  tools/configure.ac                                                | 1 +
>  tools/hotplug/Linux/Makefile                                      | 2 ++
>  tools/hotplug/Linux/init.d/xencommons.in                          | 6 ++++--
>  tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in            | 4 +---
>  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
>  tools/hotplug/Linux/systemd/xenconsoled.service.in                | 6 +++---
>  tools/hotplug/Linux/systemd/xendomains.service.in                 | 2 ++
>  tools/hotplug/Linux/systemd/xenstored.service.in                  | 6 ++----
>  tools/hotplug/Linux/xenstored.sh.in                               | 6 ++++++
>  11 files changed, 24 insertions(+), 14 deletions(-)
>  create mode 100644 tools/hotplug/Linux/xenstored.sh.in
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 19:20:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 19:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y235a-0000Yn-8L; Fri, 19 Dec 2014 19:19:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y235Y-0000Yi-Dt
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 19:19:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	49/7D-25276-35A74945; Fri, 19 Dec 2014 19:19:47 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419016785!16852752!1
X-Originating-IP: [66.165.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 27188 invoked from network); 19 Dec 2014 19:19:47 -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 Dec 2014 19:19:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,608,1413244800"; d="scan'208";a="206361267"
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.210.2; Fri, 19 Dec 2014 14:19: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 1Y235T-0005Zg-Rr;
	Fri, 19 Dec 2014 19:19:43 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y235T-0003rZ-6q;
	Fri, 19 Dec 2014 19:19:43 +0000
Date: Fri, 19 Dec 2014 19:19:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32485-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] 32485: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32485 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32485/

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           9 guest-start               fail REGR. vs. 31241
 test-amd64-i386-xl-credit2   11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl            9 guest-start               fail REGR. vs. 31241
 test-amd64-i386-xl-multivcpu  9 guest-start               fail REGR. vs. 31241
 test-amd64-amd64-pair        16 guest-start/debian        fail REGR. vs. 31241
 test-amd64-i386-pair         16 guest-start/debian        fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate.2      fail REGR. vs. 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-armhf-armhf-xl          11 guest-stop               fail blocked in 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-xl          10 migrate-support-check        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-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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                44e8967d591686463e84a88b46b03beba3ab49fb
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1894 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                                           fail    
 test-amd64-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


Not pushing.

(No revision log; it would be 225938 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 Dec 19 19:20:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 19:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y235a-0000Yn-8L; Fri, 19 Dec 2014 19:19:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y235Y-0000Yi-Dt
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 19:19:48 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	49/7D-25276-35A74945; Fri, 19 Dec 2014 19:19:47 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419016785!16852752!1
X-Originating-IP: [66.165.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 27188 invoked from network); 19 Dec 2014 19:19:47 -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 Dec 2014 19:19:47 -0000
X-IronPort-AV: E=Sophos;i="5.07,608,1413244800"; d="scan'208";a="206361267"
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.210.2; Fri, 19 Dec 2014 14:19: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 1Y235T-0005Zg-Rr;
	Fri, 19 Dec 2014 19:19:43 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y235T-0003rZ-6q;
	Fri, 19 Dec 2014 19:19:43 +0000
Date: Fri, 19 Dec 2014 19:19:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32485-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] 32485: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32485 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32485/

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           9 guest-start               fail REGR. vs. 31241
 test-amd64-i386-xl-credit2   11 guest-saverestore         fail REGR. vs. 31241
 test-amd64-i386-xl            9 guest-start               fail REGR. vs. 31241
 test-amd64-i386-xl-multivcpu  9 guest-start               fail REGR. vs. 31241
 test-amd64-amd64-pair        16 guest-start/debian        fail REGR. vs. 31241
 test-amd64-i386-pair         16 guest-start/debian        fail REGR. vs. 31241

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate.2      fail REGR. vs. 31241
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 31241
 test-armhf-armhf-xl          11 guest-stop               fail blocked in 31241
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 31241
 test-amd64-amd64-xl-sedf      9 guest-start               fail REGR. vs. 31241
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 31241

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-xl          10 migrate-support-check        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-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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                44e8967d591686463e84a88b46b03beba3ab49fb
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1894 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                                           fail    
 test-amd64-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


Not pushing.

(No revision log; it would be 225938 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 Dec 19 19:55:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 19:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y23dr-0001tr-CE; Fri, 19 Dec 2014 19:55:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1Y23dp-0001tm-8q
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 19:55:13 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	6B/D5-17936-0A284945; Fri, 19 Dec 2014 19:55:12 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419018910!10834977!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26275 invoked from network); 19 Dec 2014 19:55:11 -0000
Received: from emh03.mail.saunalahti.fi (HELO emh03.mail.saunalahti.fi)
	(62.142.5.109)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 19:55:11 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 8487D18878A;
	Fri, 19 Dec 2014 21:55:08 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 29B9936C05C; Fri, 19 Dec 2014 21:55:08 +0200 (EET)
Date: Fri, 19 Dec 2014 21:55:08 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141219195507.GJ19091@reaktio.net>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
	<5494529F02000078000510F0@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5494529F02000078000510F0@mail.emea.novell.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>, eddie.dong@intel.com,
	christoffer.dall@linaro.org, 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, manishjaggi.oss@gmail.com,
	Paul.Skentzos@dornerworks.com, wency@cn.fujitsu.com,
	rcojocaru@bitdefender.com, guijianfeng@cn.fujitsu.com,
	Vijaya.Kumar@caviumnetworks.com,
	Sarah Conway <sconway@linuxfoundation.org>, josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	anthony.perard@citrix.com, xen-devel@lists.xenproject.org,
	serge.broslavsky@linaro.org, yjhyun.yoo@samsung.com,
	olaf@aepfle.de, daniel.kiper@oracle.com, ian.campbell@citrix.com,
	vijay.kilari@gmail.com, stefano.stabellini@eu.citrix.com,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Luis Rodriguez <Mcgrof@Suse.com>, julien.grall@linaro.org,
	dave.scott@citrix.com, Russ Pavlicek <russell.pavlicek@xenproject.org>,
	roy.franz@linaro.org, yang.z.zhang@intel.com,
	Paul.Durrant@citrix.com, robert.vanvossen@dornerworks.com,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com,
	andrii.tseglytskyi@globallogic.com,
	Juergen Gross <JGross@suse.com>, talex5@gmail.com,
	yanghy@cn.fujitsu.com, Wei.Liu2@citrix.com, aravindp@cisco.com,
	george.dunlap@eu.citrix.com, suriyan.r@gmail.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	Kelly.Zytaruk@amd.com, dslutz@verizon.com,
	ross.lagerwall@citrix.com, Aravind.Gopalakrishnan@amd.com,
	david.vrabel@citrix.com, Suravee.Suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tiejun.chen@intel.com,
	malcolm.crossley@citrix.com, caobosimon@gmail.com,
	tklengyel@sec.in.tum.de, feng.wu@intel.com, roger.pau@citrix.com
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
 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, Dec 19, 2014 at 03:30:23PM +0000, Jan Beulich wrote:
> >>> On 19.12.14 at 15:52, <lars.kurth.xen@gmail.com> wrote:
> > ** The key changes normally are changes to scalability/memory/etc. limits - 
> > maybe Jan(x86) and Ian(ARM) can look let me know of changes
> 
> Iirc scalability changes on the x86 side were mostly (if not exclusively)
> in terms of performance improvements (in some cases getting bigger
> guests out of not booting at all state).
> 

Hmm, wasn't there improvements to allow more VMs per host aswell.. ? which would be worth mentioning..
xenstored related stuff iirc.

-- Pasi

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 19:55:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 19:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y23dr-0001tr-CE; Fri, 19 Dec 2014 19:55:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1Y23dp-0001tm-8q
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 19:55:13 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	6B/D5-17936-0A284945; Fri, 19 Dec 2014 19:55:12 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419018910!10834977!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26275 invoked from network); 19 Dec 2014 19:55:11 -0000
Received: from emh03.mail.saunalahti.fi (HELO emh03.mail.saunalahti.fi)
	(62.142.5.109)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 19:55:11 -0000
Received: from ydin.reaktio.net (reaktio.net [85.76.255.15])
	by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 8487D18878A;
	Fri, 19 Dec 2014 21:55:08 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 29B9936C05C; Fri, 19 Dec 2014 21:55:08 +0200 (EET)
Date: Fri, 19 Dec 2014 21:55:08 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20141219195507.GJ19091@reaktio.net>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
	<5494529F02000078000510F0@mail.emea.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5494529F02000078000510F0@mail.emea.novell.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>, eddie.dong@intel.com,
	christoffer.dall@linaro.org, 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, manishjaggi.oss@gmail.com,
	Paul.Skentzos@dornerworks.com, wency@cn.fujitsu.com,
	rcojocaru@bitdefender.com, guijianfeng@cn.fujitsu.com,
	Vijaya.Kumar@caviumnetworks.com,
	Sarah Conway <sconway@linuxfoundation.org>, josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	anthony.perard@citrix.com, xen-devel@lists.xenproject.org,
	serge.broslavsky@linaro.org, yjhyun.yoo@samsung.com,
	olaf@aepfle.de, daniel.kiper@oracle.com, ian.campbell@citrix.com,
	vijay.kilari@gmail.com, stefano.stabellini@eu.citrix.com,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Luis Rodriguez <Mcgrof@Suse.com>, julien.grall@linaro.org,
	dave.scott@citrix.com, Russ Pavlicek <russell.pavlicek@xenproject.org>,
	roy.franz@linaro.org, yang.z.zhang@intel.com,
	Paul.Durrant@citrix.com, robert.vanvossen@dornerworks.com,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com,
	andrii.tseglytskyi@globallogic.com,
	Juergen Gross <JGross@suse.com>, talex5@gmail.com,
	yanghy@cn.fujitsu.com, Wei.Liu2@citrix.com, aravindp@cisco.com,
	george.dunlap@eu.citrix.com, suriyan.r@gmail.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	Kelly.Zytaruk@amd.com, dslutz@verizon.com,
	ross.lagerwall@citrix.com, Aravind.Gopalakrishnan@amd.com,
	david.vrabel@citrix.com, Suravee.Suthikulpanit@amd.com,
	andrew.cooper3@citrix.com, tiejun.chen@intel.com,
	malcolm.crossley@citrix.com, caobosimon@gmail.com,
	tklengyel@sec.in.tum.de, feng.wu@intel.com, roger.pau@citrix.com
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
 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, Dec 19, 2014 at 03:30:23PM +0000, Jan Beulich wrote:
> >>> On 19.12.14 at 15:52, <lars.kurth.xen@gmail.com> wrote:
> > ** The key changes normally are changes to scalability/memory/etc. limits - 
> > maybe Jan(x86) and Ian(ARM) can look let me know of changes
> 
> Iirc scalability changes on the x86 side were mostly (if not exclusively)
> in terms of performance improvements (in some cases getting bigger
> guests out of not booting at all state).
> 

Hmm, wasn't there improvements to allow more VMs per host aswell.. ? which would be worth mentioning..
xenstored related stuff iirc.

-- Pasi

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 20:05:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 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 1Y23nf-0002bH-2E; Fri, 19 Dec 2014 20:05:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek.xen@gmail.com>) id 1Y23nd-0002b9-7f
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 20:05:21 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	F5/5B-27785-00584945; Fri, 19 Dec 2014 20:05:20 +0000
X-Env-Sender: russell.pavlicek.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1419019519!16283649!1
X-Originating-IP: [209.85.215.53]
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 11803 invoked from network); 19 Dec 2014 20:05:19 -0000
Received: from mail-la0-f53.google.com (HELO mail-la0-f53.google.com)
	(209.85.215.53)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 20:05:19 -0000
Received: by mail-la0-f53.google.com with SMTP id gm9so1398253lab.40
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 12:05:19 -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:content-transfer-encoding;
	bh=AEZK2LGjJPSMQP9rA+k09dLVum5npIFbOKBv6dbcQlU=;
	b=bQlTdqe7Bbxxmxev3+ycMLnyZSSuKo/EcLXpCUxM43Qb9Q3DE2tLxPEmZXLjAlVRfA
	DaU17fgaf+9J270iDb79MPLt647ncYi7D5ILJFkGZ+AeJfhCxK4XpFCVaeIPPsBFP18i
	VW53gyOzspquK5ZD/2kgtoJIXUzfT+88/JkqLQ63zEfxzfGhoWaD0TbJxY3TzMvREncN
	bRv9V3ARU/misNEAuDeXXEmcsN6q/l7L5A3QkXdK5SRdwsHrXoZ2XwCgIz2bx6MlMq+h
	IppyBdBUrrT6cIGwsWrQWbuXo4pN2I25HMXtK2THUgNZHLlD5dcrb7LI1MCfcODBQm1K
	UA8Q==
MIME-Version: 1.0
X-Received: by 10.112.130.132 with SMTP id oe4mr9490119lbb.82.1419019518889;
	Fri, 19 Dec 2014 12:05:18 -0800 (PST)
Received: by 10.112.0.104 with HTTP; Fri, 19 Dec 2014 12:05:18 -0800 (PST)
In-Reply-To: <20141219195507.GJ19091@reaktio.net>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
	<5494529F02000078000510F0@mail.emea.novell.com>
	<20141219195507.GJ19091@reaktio.net>
Date: Fri, 19 Dec 2014 15:05:18 -0500
X-Google-Sender-Auth: 79oQGEDGrZMkT69vAicMfFx1PpE
Message-ID: <CAHehzX1=tTLzrh7RpN9caQ6V5unu3O=cs_BrxgaLMvOQZLiLQA@mail.gmail.com>
From: Russ Pavlicek <russell.pavlicek@xenproject.org>
To: =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>, eddie.dong@intel.com,
	christoffer.dall@linaro.org, Steve.VanderLeest@dornerworks.com,
	mengxu@cis.upenn.edu, Jan Beulich <JBeulich@suse.com>,
	M A Young <m.a.young@durham.ac.uk>, chao.p.peng@linux.intel.com,
	zhigang.x.wang@oracle.com, parth.dixit@linaro.org,
	manishjaggi.oss@gmail.com, Paul.Skentzos@dornerworks.com,
	wency@cn.fujitsu.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, Vijaya.Kumar@caviumnetworks.com,
	Sarah Conway <sconway@linuxfoundation.org>, josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	anthony.perard@citrix.com, xen-devel@lists.xenproject.org,
	serge.broslavsky@linaro.org, yjhyun.yoo@samsung.com,
	olaf@aepfle.de, daniel.kiper@oracle.com,
	Ian Campbell <ian.campbell@citrix.com>, vijay.kilari@gmail.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Luis Rodriguez <Mcgrof@suse.com>, julien.grall@linaro.org,
	dave.scott@citrix.com, Russ Pavlicek <russell.pavlicek@xenproject.org>,
	roy.franz@linaro.org, yang.z.zhang@intel.com,
	Paul.Durrant@citrix.com, robert.vanvossen@dornerworks.com,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com,
	andrii.tseglytskyi@globallogic.com,
	Juergen Gross <JGross@suse.com>, talex5@gmail.com,
	yanghy@cn.fujitsu.com, Wei.Liu2@citrix.com, aravindp@cisco.com,
	George Dunlap <george.dunlap@eu.citrix.com>, suriyan.r@gmail.com,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Kelly.Zytaruk@amd.com,
	dslutz@verizon.com, ross.lagerwall@citrix.com,
	Aravind.Gopalakrishnan@amd.com, david.vrabel@citrix.com,
	Suravee.Suthikulpanit@amd.com,
	Andrew Cooper <andrew.cooper3@citrix.com>, tiejun.chen@intel.com,
	malcolm.crossley@citrix.com, caobosimon@gmail.com,
	tklengyel@sec.in.tum.de, feng.wu@intel.com,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TGFycywKCj5AUnVzc2VsbDogeW91IG1heSB3YW50IHRvIHVwZGF0ZSB0aGUgWE0gdG8gWEwgcGFn
ZXMgb3IgY3JlYXRlIGEgbmV3Cj5vbmUgYW5kIGFkZCB5b3VyIHZpZGVvCgpJJ3ZlIHVwZGF0ZWQg
dGhlIGV4aXN0aW5nIFdpa2kgcGFnZXMuIEkndmUgYWxzbyBjcmVhdGVkIGFuIHVucHVibGlzaGVk
CmVudHJ5IGluIHRoZSBWaWRlbyBzZWN0aW9uIG9mIHRoZSBYZW5Qcm9qZWN0Lm9yZyB3ZWJzaXRl
LiAgU2hvdWxkIHdlCnB1Ymxpc2ggdGhhdCBub3csIG9yIHdhaXQgdW50aWwgcmVsZWFzZT8KClJ1
c3MKCk9uIEZyaSwgRGVjIDE5LCAyMDE0IGF0IDI6NTUgUE0sIFBhc2kgS8Okcmtrw6RpbmVuIDxw
YXNpa0Bpa2kuZmk+IHdyb3RlOgo+IE9uIEZyaSwgRGVjIDE5LCAyMDE0IGF0IDAzOjMwOjIzUE0g
KzAwMDAsIEphbiBCZXVsaWNoIHdyb3RlOgo+PiA+Pj4gT24gMTkuMTIuMTQgYXQgMTU6NTIsIDxs
YXJzLmt1cnRoLnhlbkBnbWFpbC5jb20+IHdyb3RlOgo+PiA+ICoqIFRoZSBrZXkgY2hhbmdlcyBu
b3JtYWxseSBhcmUgY2hhbmdlcyB0byBzY2FsYWJpbGl0eS9tZW1vcnkvZXRjLiBsaW1pdHMgLQo+
PiA+IG1heWJlIEphbih4ODYpIGFuZCBJYW4oQVJNKSBjYW4gbG9vayBsZXQgbWUga25vdyBvZiBj
aGFuZ2VzCj4+Cj4+IElpcmMgc2NhbGFiaWxpdHkgY2hhbmdlcyBvbiB0aGUgeDg2IHNpZGUgd2Vy
ZSBtb3N0bHkgKGlmIG5vdCBleGNsdXNpdmVseSkKPj4gaW4gdGVybXMgb2YgcGVyZm9ybWFuY2Ug
aW1wcm92ZW1lbnRzIChpbiBzb21lIGNhc2VzIGdldHRpbmcgYmlnZ2VyCj4+IGd1ZXN0cyBvdXQg
b2Ygbm90IGJvb3RpbmcgYXQgYWxsIHN0YXRlKS4KPj4KPgo+IEhtbSwgd2Fzbid0IHRoZXJlIGlt
cHJvdmVtZW50cyB0byBhbGxvdyBtb3JlIFZNcyBwZXIgaG9zdCBhc3dlbGwuLiA/IHdoaWNoIHdv
dWxkIGJlIHdvcnRoIG1lbnRpb25pbmcuLgo+IHhlbnN0b3JlZCByZWxhdGVkIHN0dWZmIGlpcmMu
Cj4KPiAtLSBQYXNpCj4KPj4gSmFuCj4+Cj4KPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Dec 19 20:05:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 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 1Y23nf-0002bH-2E; Fri, 19 Dec 2014 20:05:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <russell.pavlicek.xen@gmail.com>) id 1Y23nd-0002b9-7f
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 20:05:21 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	F5/5B-27785-00584945; Fri, 19 Dec 2014 20:05:20 +0000
X-Env-Sender: russell.pavlicek.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1419019519!16283649!1
X-Originating-IP: [209.85.215.53]
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 11803 invoked from network); 19 Dec 2014 20:05:19 -0000
Received: from mail-la0-f53.google.com (HELO mail-la0-f53.google.com)
	(209.85.215.53)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 20:05:19 -0000
Received: by mail-la0-f53.google.com with SMTP id gm9so1398253lab.40
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 12:05:19 -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:content-transfer-encoding;
	bh=AEZK2LGjJPSMQP9rA+k09dLVum5npIFbOKBv6dbcQlU=;
	b=bQlTdqe7Bbxxmxev3+ycMLnyZSSuKo/EcLXpCUxM43Qb9Q3DE2tLxPEmZXLjAlVRfA
	DaU17fgaf+9J270iDb79MPLt647ncYi7D5ILJFkGZ+AeJfhCxK4XpFCVaeIPPsBFP18i
	VW53gyOzspquK5ZD/2kgtoJIXUzfT+88/JkqLQ63zEfxzfGhoWaD0TbJxY3TzMvREncN
	bRv9V3ARU/misNEAuDeXXEmcsN6q/l7L5A3QkXdK5SRdwsHrXoZ2XwCgIz2bx6MlMq+h
	IppyBdBUrrT6cIGwsWrQWbuXo4pN2I25HMXtK2THUgNZHLlD5dcrb7LI1MCfcODBQm1K
	UA8Q==
MIME-Version: 1.0
X-Received: by 10.112.130.132 with SMTP id oe4mr9490119lbb.82.1419019518889;
	Fri, 19 Dec 2014 12:05:18 -0800 (PST)
Received: by 10.112.0.104 with HTTP; Fri, 19 Dec 2014 12:05:18 -0800 (PST)
In-Reply-To: <20141219195507.GJ19091@reaktio.net>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<322B9C36-32DC-451C-AB9D-B4C6A6223674@gmail.com>
	<5494529F02000078000510F0@mail.emea.novell.com>
	<20141219195507.GJ19091@reaktio.net>
Date: Fri, 19 Dec 2014 15:05:18 -0500
X-Google-Sender-Auth: 79oQGEDGrZMkT69vAicMfFx1PpE
Message-ID: <CAHehzX1=tTLzrh7RpN9caQ6V5unu3O=cs_BrxgaLMvOQZLiLQA@mail.gmail.com>
From: Russ Pavlicek <russell.pavlicek@xenproject.org>
To: =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>
Cc: artem Mygaiev <artem.mygaiev@globallogic.com>, eddie.dong@intel.com,
	christoffer.dall@linaro.org, Steve.VanderLeest@dornerworks.com,
	mengxu@cis.upenn.edu, Jan Beulich <JBeulich@suse.com>,
	M A Young <m.a.young@durham.ac.uk>, chao.p.peng@linux.intel.com,
	zhigang.x.wang@oracle.com, parth.dixit@linaro.org,
	manishjaggi.oss@gmail.com, Paul.Skentzos@dornerworks.com,
	wency@cn.fujitsu.com, rcojocaru@bitdefender.com,
	guijianfeng@cn.fujitsu.com, Vijaya.Kumar@caviumnetworks.com,
	Sarah Conway <sconway@linuxfoundation.org>, josh.whitehead@dornerworks.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	anthony.perard@citrix.com, xen-devel@lists.xenproject.org,
	serge.broslavsky@linaro.org, yjhyun.yoo@samsung.com,
	olaf@aepfle.de, daniel.kiper@oracle.com,
	Ian Campbell <ian.campbell@citrix.com>, vijay.kilari@gmail.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Luis Rodriguez <Mcgrof@suse.com>, julien.grall@linaro.org,
	dave.scott@citrix.com, Russ Pavlicek <russell.pavlicek@xenproject.org>,
	roy.franz@linaro.org, yang.z.zhang@intel.com,
	Paul.Durrant@citrix.com, robert.vanvossen@dornerworks.com,
	ufimtseva@gmail.com, boris.ostrovsky@oracle.com,
	andrii.tseglytskyi@globallogic.com,
	Juergen Gross <JGross@suse.com>, talex5@gmail.com,
	yanghy@cn.fujitsu.com, Wei.Liu2@citrix.com, aravindp@cisco.com,
	George Dunlap <george.dunlap@eu.citrix.com>, suriyan.r@gmail.com,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Kelly.Zytaruk@amd.com,
	dslutz@verizon.com, ross.lagerwall@citrix.com,
	Aravind.Gopalakrishnan@amd.com, david.vrabel@citrix.com,
	Suravee.Suthikulpanit@amd.com,
	Andrew Cooper <andrew.cooper3@citrix.com>, tiejun.chen@intel.com,
	malcolm.crossley@citrix.com, caobosimon@gmail.com,
	tklengyel@sec.in.tum.de, feng.wu@intel.com,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TGFycywKCj5AUnVzc2VsbDogeW91IG1heSB3YW50IHRvIHVwZGF0ZSB0aGUgWE0gdG8gWEwgcGFn
ZXMgb3IgY3JlYXRlIGEgbmV3Cj5vbmUgYW5kIGFkZCB5b3VyIHZpZGVvCgpJJ3ZlIHVwZGF0ZWQg
dGhlIGV4aXN0aW5nIFdpa2kgcGFnZXMuIEkndmUgYWxzbyBjcmVhdGVkIGFuIHVucHVibGlzaGVk
CmVudHJ5IGluIHRoZSBWaWRlbyBzZWN0aW9uIG9mIHRoZSBYZW5Qcm9qZWN0Lm9yZyB3ZWJzaXRl
LiAgU2hvdWxkIHdlCnB1Ymxpc2ggdGhhdCBub3csIG9yIHdhaXQgdW50aWwgcmVsZWFzZT8KClJ1
c3MKCk9uIEZyaSwgRGVjIDE5LCAyMDE0IGF0IDI6NTUgUE0sIFBhc2kgS8Okcmtrw6RpbmVuIDxw
YXNpa0Bpa2kuZmk+IHdyb3RlOgo+IE9uIEZyaSwgRGVjIDE5LCAyMDE0IGF0IDAzOjMwOjIzUE0g
KzAwMDAsIEphbiBCZXVsaWNoIHdyb3RlOgo+PiA+Pj4gT24gMTkuMTIuMTQgYXQgMTU6NTIsIDxs
YXJzLmt1cnRoLnhlbkBnbWFpbC5jb20+IHdyb3RlOgo+PiA+ICoqIFRoZSBrZXkgY2hhbmdlcyBu
b3JtYWxseSBhcmUgY2hhbmdlcyB0byBzY2FsYWJpbGl0eS9tZW1vcnkvZXRjLiBsaW1pdHMgLQo+
PiA+IG1heWJlIEphbih4ODYpIGFuZCBJYW4oQVJNKSBjYW4gbG9vayBsZXQgbWUga25vdyBvZiBj
aGFuZ2VzCj4+Cj4+IElpcmMgc2NhbGFiaWxpdHkgY2hhbmdlcyBvbiB0aGUgeDg2IHNpZGUgd2Vy
ZSBtb3N0bHkgKGlmIG5vdCBleGNsdXNpdmVseSkKPj4gaW4gdGVybXMgb2YgcGVyZm9ybWFuY2Ug
aW1wcm92ZW1lbnRzIChpbiBzb21lIGNhc2VzIGdldHRpbmcgYmlnZ2VyCj4+IGd1ZXN0cyBvdXQg
b2Ygbm90IGJvb3RpbmcgYXQgYWxsIHN0YXRlKS4KPj4KPgo+IEhtbSwgd2Fzbid0IHRoZXJlIGlt
cHJvdmVtZW50cyB0byBhbGxvdyBtb3JlIFZNcyBwZXIgaG9zdCBhc3dlbGwuLiA/IHdoaWNoIHdv
dWxkIGJlIHdvcnRoIG1lbnRpb25pbmcuLgo+IHhlbnN0b3JlZCByZWxhdGVkIHN0dWZmIGlpcmMu
Cj4KPiAtLSBQYXNpCj4KPj4gSmFuCj4+Cj4KPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Dec 19 20:15:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 20: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 1Y23wr-00038k-44; Fri, 19 Dec 2014 20:14:53 +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 1Y23wp-00038f-Jp
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 20:14:51 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	90/DE-24124-A3784945; Fri, 19 Dec 2014 20:14:50 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1419020080!11056293!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28487 invoked from network); 19 Dec 2014 20:14:50 -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; 19 Dec 2014 20:14:50 -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 sBJKET4K021860
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 20:14:29 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
	sBJKERVx028907
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 20:14:28 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
	sBJKERr3027703; Fri, 19 Dec 2014 20:14:27 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 12:14:26 -0800
Date: Fri, 19 Dec 2014 21:14:19 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: grub-devel@gnu.org, xen-devel@lists.xenproject.org
Message-ID: <20141219201419.GB30166@olila.local.net-space.pl>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: jgross@suse.com, keir@xen.org, ian.campbell@citrix.com,
	andrew.cooper3@citrix.com, stefano.stabellini@eu.citrix.com,
	ross.philipson@citrix.com, roy.franz@linaro.org,
	ning.sun@intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	phcoder@gmail.com, qiaowei.ren@intel.com,
	richard.l.maliszewski@intel.com, gang.wei@intel.com, fu.wei@linaro.org
Subject: [Xen-devel] EFI + GRUB2 + Xen - WIP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 was going to send EFI + GRUB2 + Xen upstream patches based on my
internal work for Xen 4.3.1 last week. Sadly, I was killing various
bugs surfacing on various machines in unexpected places in this almost
fully featured solution. This means I was not able to do that as I
planned. Additionally, I am on holiday until Christmas. So, I hope
that I will be able to release first version of EFI + GRUB2 + Xen
upstream patch series at the beginning of next year. However, if you
wish to take a look at our internal version, which have most ideas set
in stone (e.g. I am going to post GRUB2 patches almost without any
changes), please drop me a line.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 20:15:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 20: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 1Y23wr-00038k-44; Fri, 19 Dec 2014 20:14:53 +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 1Y23wp-00038f-Jp
	for xen-devel@lists.xenproject.org; Fri, 19 Dec 2014 20:14:51 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	90/DE-24124-A3784945; Fri, 19 Dec 2014 20:14:50 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1419020080!11056293!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28487 invoked from network); 19 Dec 2014 20:14:50 -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; 19 Dec 2014 20:14:50 -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 sBJKET4K021860
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 20:14:29 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
	sBJKERVx028907
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 19 Dec 2014 20:14:28 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
	sBJKERr3027703; Fri, 19 Dec 2014 20:14:27 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 12:14:26 -0800
Date: Fri, 19 Dec 2014 21:14:19 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: grub-devel@gnu.org, xen-devel@lists.xenproject.org
Message-ID: <20141219201419.GB30166@olila.local.net-space.pl>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: jgross@suse.com, keir@xen.org, ian.campbell@citrix.com,
	andrew.cooper3@citrix.com, stefano.stabellini@eu.citrix.com,
	ross.philipson@citrix.com, roy.franz@linaro.org,
	ning.sun@intel.com, david.vrabel@citrix.com, jbeulich@suse.com,
	phcoder@gmail.com, qiaowei.ren@intel.com,
	richard.l.maliszewski@intel.com, gang.wei@intel.com, fu.wei@linaro.org
Subject: [Xen-devel] EFI + GRUB2 + Xen - WIP
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 was going to send EFI + GRUB2 + Xen upstream patches based on my
internal work for Xen 4.3.1 last week. Sadly, I was killing various
bugs surfacing on various machines in unexpected places in this almost
fully featured solution. This means I was not able to do that as I
planned. Additionally, I am on holiday until Christmas. So, I hope
that I will be able to release first version of EFI + GRUB2 + Xen
upstream patch series at the beginning of next year. However, if you
wish to take a look at our internal version, which have most ideas set
in stone (e.g. I am going to post GRUB2 patches almost without any
changes), please drop me a line.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 19 20:22:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 20:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2440-0003Vp-1Q; Fri, 19 Dec 2014 20:22:16 +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 1Y243y-0003UR-Sl
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 20:22:14 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A7/76-09842-6F884945; Fri, 19 Dec 2014 20:22:14 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1419020532!16792206!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15282 invoked from network); 19 Dec 2014 20:22:13 -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; 19 Dec 2014 20:22:13 -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 sBJKLaAr029074
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 20:21:36 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
	sBJKLXqj009576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Dec 2014 20:21:34 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
	sBJKLWrS015417; Fri, 19 Dec 2014 20:21:33 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 12:21:32 -0800
Date: Fri, 19 Dec 2014 21:21:26 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Petr Tesarik <ptesarik@suse.cz>
Message-ID: <20141219202126.GC30166@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.

[...]

Due to delays in EFI + GRUB2 + Xen project I must postpone
work on this a bit longer than I expected. I will check
what is going on immediately after releasing first version
of patches for above mentioned project. It looks that 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 Fri Dec 19 20:22:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 20:22:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2440-0003Vp-1Q; Fri, 19 Dec 2014 20:22:16 +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 1Y243y-0003UR-Sl
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 20:22:14 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	A7/76-09842-6F884945; Fri, 19 Dec 2014 20:22:14 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1419020532!16792206!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15282 invoked from network); 19 Dec 2014 20:22:13 -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; 19 Dec 2014 20:22:13 -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 sBJKLaAr029074
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Dec 2014 20:21:36 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
	sBJKLXqj009576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Dec 2014 20:21:34 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
	sBJKLWrS015417; Fri, 19 Dec 2014 20:21:33 GMT
Received: from olila.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Dec 2014 12:21:32 -0800
Date: Fri, 19 Dec 2014 21:21:26 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Petr Tesarik <ptesarik@suse.cz>
Message-ID: <20141219202126.GC30166@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.

[...]

Due to delays in EFI + GRUB2 + Xen project I must postpone
work on this a bit longer than I expected. I will check
what is going on immediately after releasing first version
of patches for above mentioned project. It looks that 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 Fri Dec 19 21:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 21:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y24nj-00055n-21; Fri, 19 Dec 2014 21:09: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 1Y24nh-00055i-8U
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 21:09:29 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	0A/1C-20609-80494945; Fri, 19 Dec 2014 21:09:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419023365!10842856!1
X-Originating-IP: [66.165.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 31500 invoked from network); 19 Dec 2014 21:09:27 -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;
	19 Dec 2014 21:09:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,608,1413244800"; d="scan'208";a="206394994"
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.210.2; Fri, 19 Dec 2014 16:09: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 1Y24nb-000669-Hr;
	Fri, 19 Dec 2014 21:09:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y24nb-0001C0-Ca;
	Fri, 19 Dec 2014 21:09:23 +0000
Date: Fri, 19 Dec 2014 21:09:23 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32506-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] 32506: 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 32506 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32506/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          3f853f8ea1bc6859320a52cec7c53fef04c3dfde
baseline version:
 rumpuserxen          0a0e61c12101ca4fe48da63f09971bccd331819c

------------------------------------------------------------
People who touched revisions under test:
  Antti Kantee <pooka@iki.fi>
  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=3f853f8ea1bc6859320a52cec7c53fef04c3dfde
+ . 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 3f853f8ea1bc6859320a52cec7c53fef04c3dfde
+ branch=rumpuserxen
+ revision=3f853f8ea1bc6859320a52cec7c53fef04c3dfde
+ . 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 3f853f8ea1bc6859320a52cec7c53fef04c3dfde:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   0a0e61c..3f853f8  3f853f8ea1bc6859320a52cec7c53fef04c3dfde -> 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 Dec 19 21:09:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 21:09:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y24nj-00055n-21; Fri, 19 Dec 2014 21:09: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 1Y24nh-00055i-8U
	for xen-devel@lists.xensource.com; Fri, 19 Dec 2014 21:09:29 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	0A/1C-20609-80494945; Fri, 19 Dec 2014 21:09:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419023365!10842856!1
X-Originating-IP: [66.165.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 31500 invoked from network); 19 Dec 2014 21:09:27 -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;
	19 Dec 2014 21:09:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,608,1413244800"; d="scan'208";a="206394994"
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.210.2; Fri, 19 Dec 2014 16:09: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 1Y24nb-000669-Hr;
	Fri, 19 Dec 2014 21:09:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y24nb-0001C0-Ca;
	Fri, 19 Dec 2014 21:09:23 +0000
Date: Fri, 19 Dec 2014 21:09:23 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32506-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] 32506: 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 32506 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32506/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          3f853f8ea1bc6859320a52cec7c53fef04c3dfde
baseline version:
 rumpuserxen          0a0e61c12101ca4fe48da63f09971bccd331819c

------------------------------------------------------------
People who touched revisions under test:
  Antti Kantee <pooka@iki.fi>
  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=3f853f8ea1bc6859320a52cec7c53fef04c3dfde
+ . 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 3f853f8ea1bc6859320a52cec7c53fef04c3dfde
+ branch=rumpuserxen
+ revision=3f853f8ea1bc6859320a52cec7c53fef04c3dfde
+ . 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 3f853f8ea1bc6859320a52cec7c53fef04c3dfde:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   0a0e61c..3f853f8  3f853f8ea1bc6859320a52cec7c53fef04c3dfde -> 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 Dec 19 22:10:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 22:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y25jt-0007bd-VI; Fri, 19 Dec 2014 22:09:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <syllopsium@syllopsium.co.uk>) id 1Y25jr-0007bY-TP
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 22:09:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C4/A7-09842-F12A4945; Fri, 19 Dec 2014 22:09:35 +0000
X-Env-Sender: syllopsium@syllopsium.co.uk
X-Msg-Ref: server-4.tower-21.messagelabs.com!1419026972!16828262!1
X-Originating-IP: [209.85.218.46]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11236 invoked from network); 19 Dec 2014 22:09:33 -0000
Received: from mail-oi0-f46.google.com (HELO mail-oi0-f46.google.com)
	(209.85.218.46)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 22:09:33 -0000
Received: by mail-oi0-f46.google.com with SMTP id h136so3485865oig.5
	for <xen-devel@lists.xen.org>; Fri, 19 Dec 2014 14:09:32 -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=dR6Wr2mXTaXdVwTNDqHML6AZkoiejhpEykLn9s2yydg=;
	b=cPWlMbDML+wxlCzAyqBYHxfJu1NxOgAoTajQgoPRPSEPQ8e9oGgpbLXxKBrVqUPwPF
	cup0mpr/i1u6SIgWtd/VWAopB3oVQBhfuQgbJjym5e6Uph5QXYWeLUaYdFhNQKVDbPbi
	sw7JrHRcGl3p0N9HoCaqi+YInRKfkWBhjYNoPf0DnxfU8B07Cm9MVPe/aYodxceYE6oM
	8wP5H7s9TCu5X3ZTf/3PppRPSs2Br746BpyV2A8sPx5ShJn8igYdkgalu4wJw+udIB8n
	0Ogo2VMi+NB3jSRIJ8E/0UMoq4dT+xQfX5ec+aQa/r30LbMd76VLfNTdhS5bkWY2OweN
	weKA==
X-Gm-Message-State: ALoCoQls55pO+sHAzLai1lAZxlbV4Tb8bqyPZ5qtBDwbxeGC8MsCvKoNO2IS0MQ2OgMHKOyvG3z/
MIME-Version: 1.0
X-Received: by 10.202.55.215 with SMTP id e206mr5882888oia.120.1419026972082; 
	Fri, 19 Dec 2014 14:09:32 -0800 (PST)
Received: by 10.60.158.169 with HTTP; Fri, 19 Dec 2014 14:09:31 -0800 (PST)
X-Originating-IP: [87.81.134.115]
In-Reply-To: <1418983542.20028.5.camel@citrix.com>
References: <CAN4Onoho_BKS48ECqXf=wF=MMLCah80yGZyEmm1O7G6fDEQtHA@mail.gmail.com>
	<1418983542.20028.5.camel@citrix.com>
Date: Fri, 19 Dec 2014 22:09:31 +0000
Message-ID: <CAN4Onog81C3QPssC7Cm3UDqX98fgcQC8XuqO09WrKrP2GH6oQg@mail.gmail.com>
From: Peter Kay <syllopsium@syllopsium.co.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=001a113cf1269938ad050a98f62f
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Parallel make 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--001a113cf1269938ad050a98f62f
Content-Type: multipart/alternative; boundary=001a113cf1269938a9050a98f62d

--001a113cf1269938a9050a98f62d
Content-Type: text/plain; charset=UTF-8

Thanks, see attached :

This is on Salix 14.1 running the 3.17.4 kernel. That's not particularly
relevant though, as I had exactly the same error on Debian using other
kernel versions.

On 19 December 2014 at 10:05, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Thu, 2014-12-18 at 22:36 +0000, Peter Kay wrote:
> > Is parallel make supported for xen? If I compile 4.5 rc4 (although the
> > error exists with many other prior releases too) with make -j4 world
> > it fails part way through with an error 2. This does not occur with a
> > straight 'make world'
>
> It is expected to work in general, I build with -j12 all the time. There
> are some subdirs which enforce serialised build for various reasons,
> perhaps there is one more we've not spotted or perhaps there is just a
> bug in the Makefiles somewhere.
>
> Please post your build logs showing the error.
>
> Ian.
>
>
>

--001a113cf1269938a9050a98f62d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thanks, see attached :<br><br></div>This is on Salix =
14.1 running the 3.17.4 kernel. That&#39;s not particularly relevant though=
, as I had exactly the same error on Debian using other kernel versions.<br=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 19 Dece=
mber 2014 at 10:05, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ia=
n.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</s=
pan> 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"><div cl=
ass=3D"h5">On Thu, 2014-12-18 at 22:36 +0000, Peter Kay wrote:<br>
&gt; Is parallel make supported for xen? If I compile 4.5 rc4 (although the=
<br>
&gt; error exists with many other prior releases too) with make -j4 world<b=
r>
&gt; it fails part way through with an error 2. This does not occur with a<=
br>
&gt; straight &#39;make world&#39;<br>
<br>
</div></div>It is expected to work in general, I build with -j12 all the ti=
me. There<br>
are some subdirs which enforce serialised build for various reasons,<br>
perhaps there is one more we&#39;ve not spotted or perhaps there is just a<=
br>
bug in the Makefiles somewhere.<br>
<br>
Please post your build logs showing the error.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--001a113cf1269938a9050a98f62d--
--001a113cf1269938ad050a98f62f
Content-Type: application/x-gzip; name="build.log.gz"
Content-Disposition: attachment; filename="build.log.gz"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i3w3yxl50

H4sICMmglFQAA2J1aWxkLmxvZwDsPWtz5DZyn8+/gtly1SaTIkcarXXrbPmDz7flc+pip2xXKqm1
a4whMSQskuASnNFIcfa3pxsvApwZSSuCulHV6oMG3QC6gX7gDbAiVzRKS0rqzyoIvjv/9d+it3VH
W1bnUcZamna8vYl+mxe8ovOGQsz8r/y6LjnJxHxH6/hV8kVyFrfpq5eSQhR/EwHapbl4PE2EDN11
9OOmpCKprqKlQ/0iDPVvoo7zUrjlfjWO8lwSfPlZW2HZZwmPxE21AlRP/e+UbMcRN6J5aDYrQqgw
q9Nyk9GQVdYkVaXbdZTyqiFdVFCS0VYkaXHliGP2AeJbGiWzJAsiE8t9jFSgyBWvQwpFURxdKhRk
X6rHEiq2VQAqJVvRch2AUJ7yrSvrL4LIeq7K9/JOY/tinLENOIUsPQrlzrKPUNs66yaQN1jVUwhb
CSZkwZVfPUXZpYgC0jMlD+w2YB9P5Db3chrZG4RodrOWbaHjCtkbaJIju4OCtAFa37TZrFv6PgCl
JmUhqBAhuqLlm7wI2Uhpkc91de+37xDMnLqM0/W2y4bCGOEVe7IYUzSSNmwKRYE1TdoIeXxG6YZl
lE9iquDgTyICxWiUEVR79hlCAmhb4wrWkRUAbtkuw/v2HNxzXDF3ry+nLiOo6G5jugzkT0OeAeUS
yq6kyz6Ja2lOo3yrdWdr7/48jf3OQdR3S+TP4e3jQXxDOQM2JnPVHjy5I4xuIDYdK1nH9puyAAX1
BDPKUhvKpm7GnsxcvHasvWdqO4HJyIpO1jDfV6FQg6vhADisN6PBPWHjYZ3wSYzBqWFwsg+sSSAr
UMO4Caf5QebTO1GFnOMDuXHlWZdEXIUc/UCJ5pKo0YVeK1fIpLBwCrBYdnwpOuTlxLAarIaUS8Gy
g/Fku2xoW90Vx4RgvBYQgaYwejlTBB3cWxHNxbRO/nBGI31wT+mTOOBoY0/bm6bjQXdcJMVpVxc1
i3Gj+1T29SGrbmiayhNRxXy9FrQTiQBRlJmIVpx3c5SKCnxQv1I+MlRd0XJ9sQi5NDRihTLELhOt
ScNSTUkJ5qF0EkSJm0ok787iL3+dKRFJO/p4QgldM0MHglIJ+IvkNAL+y1DGBA7LFbq6amnJU81R
lkAikp9coKyvXHDFQm4Vju6CjGXOtTYmbfr2mY2RRDWNIMC4R5YrLWgadJxgyzZ++W1/cyFc6exm
2qOHDr5tjx07uCqdK61MOzfx9PSwjY2Ro5aDVRxlvF3bBlzReIREQrUx432FNy1fs5JO4izVWF8p
SMavJ3EX8OO5uO/sQCjDsMxG7fhUu+kaDvCIJ/The7kFs0Bj3k/UJlagZ2mzT+P+fe1GbncsL19N
0SA64hg1HCRNwH3o/UFQ2FYF/PTpWpV7mYUSln+IKIiwlN0FPp0Y1JfB8J5GlQ/hFUqTplMOJyml
yAedaAslsI9gGUpuxlwnXNoZLqHYRUxRSYYPXhij9cekTfLbj0qOCwUfkV6uYRhh7dcsns3dpaJC
p0hWpK5pq+R6MUqu2t4XAYgcPK4/5pqBc5p+1IUC71R+8BP2kvreGXtIYxli+jXol+V1qKmEx3Tu
MDDugYcULhZJIQOXrzCATqpQyl2tOclpI23Nb5JaP25uUu3No9uLO0o8tnkYaGCsV0xkdiVb7dKw
RidJWpObJW1TSTa0Tru2TIgLCO5DCRDbxyRnGpdvqOgsBQVZEgZ0aLgoIKKpLrnIaLN8+/0PP/3P
T5gfWjq5qvrLZ5Hzt4SOqsANKB+9S5fYLIL96dASDFdDzaYBESgg4xVhtQrTbZcWOpzXXUdWKlwx
kaqQ2luTwaa4gfJtNdCyLek0N0GzteYkwC0yN7xQAAG9pZdfXCio7dRvt9rojE1li7oseNeUm1wn
pWJTaT5dRXUyCEDhad31YENy3LCzMElTKoSFRdGqcJGSslxaxtqvMAnYk8Jd0R2V9e9KK1MIljzP
absUXca4LRzftKkuXiM0CygKtbIsWb3ZOUGl5V5NCcdlfU9nBmHUpmGjOQ0a5WnQ6E+DSoUa0FrU
kFWkgY0uNazUaQqhNeqBCwv3etUIVK0OKu0aJpVbr17HJptWs8kqNW2q0ivbwRh9Oyij8h4lta5B
R/FGLAPda7RWv4SsBRjIN4K+9NoOTG1Fz9dag4a1QbiQsQnEDbw6H7jaRjS0zlxXRu6d9XyNE2Sr
ETAcAh5UFsNYXdVAHtzHTri+BxXLNrIHsRmlbQ8DWVavueXhtDUI4ZZND0EGm98kuGUVFGCIzqgp
zLK8feUkZ/UwqRqhu+6EWLeNY1kPwiwTVM1Ki8r3zdyI0nOvXpo+WglU43yZWv91xIo4X7IOxlTN
QVn59lz91qGXsoNwBO0m82XtxAzF7WbqJe4VwRW6EzFop4zojav50j9g1od6PH4EDdkDjXr0EOBE
xzwQKU0v7LDHUO3nm0SNUpVeZjDQmFnWGXgJX9F+8mQjop1YtqQG3WNIdGhEGEpbIorKzMYA0WWr
ZbapGps1TnndtbyM8PRNbLHKrwZs+kx0x0QnergEsIdaSjIHqhxmRcWdqOuWdQ7V0qF4TaD/NHPE
EBPvobxP1MxwZBDWxJCiu5wBaRqqpnWNVE2M/blUYdyQVtAo71qS0i2j1zooOiLVW/L0CteiMSwV
lPFcqhMv2SKlDMqTyqQxtDJpt7NBNEQJlPwa2MlccbWujTHGRYPFNaPqQOpWdT9RVdMdqZrBBZLx
6jZUnbno97wrkF7HoxWNMl7TCAZX0W+S78skkKwHjE9P3npUG1bcmmiARfMD9A4/FzBmQddjYm+w
qsbhhUbjDDYRxYvRS7mHmYVZfZlc7n/HUdU0Ypekxx+8Pk40sHRHNw0+udNrGSBS9nPBx3aSqj+2
E1wP8FrV+yrGJrDExXF2S9Vgexd46KOLc6paSPHmQODuUBN1B0A4PK15Bx1vKdQyzQTjTMP2RGW9
Zm11TULPZgzVYK1yTxD8Iorpm4itI9AchLNIULJiXMRAeZ68ibqC1jCR/ZOpohOtavkGYtcsVGNu
ijZ3+MDMpwLDCtW0389idEM/ocaMHlpeYeHDdqVWNJq6Lv+Y+6t3EcZ6XCxWzDuC8Do4s7nkoevy
5aTk5Q5nmg81c342Ede5ZuZs8XBTALrr3Ns6qhBhPOdIGayAJ+Di1VBiMA5X+bukcGr5eir21hOC
Ure7sWr0IocyxrfxJkC01MBsaXddIyJeX+K5gKTbdVGZOYBJYTJJpAUgVbQRJKcRwmJTCZP+L9/9
8FO84mkh4pnBBTl3cme78hza2W1OJmxnNXVrBUYv0XZF1fXuOIf+10L6Ct5M3wl6femtMXe0ahJy
fZXMTLEhccvyaKnB5cwG44yuNjkg5CEcmxxNzgJoPL8111n0B3T7WfRCxMlsHscvfpPJIDEx7wL+
17dfSxMq86aMwSVhLDGzF1kC2o+V17OxHwoDqBY3MSayIEvfNpCs2VH5L8mhZ519iJYS6EiLR5Wc
cGjlOEV5NuoptpXaAppIPZZ++KHUgPShh50CjqUsN+dqeNvvrETGvuwNO4gUIuuWM2izMgjMkhSN
ETJUJfwv6C6qrpYYI6MhHRFl6D58WOrAnbijAtUOQv8mElanNpDU9Fqqxe4u9RZnQ0lXNf7V6oBe
ObTA0F45elI/oHd6s/qU14KXgSf1mujdq1g6UeaEI+cKa1oyWqsrwRmh+D4jBANpxZbvRJUCkQHf
+7Vrec7CvVm6shBEw4hHaUMGQNhupF1qrPAVCP0bTCGmcKerD7mfGX4fP8hrqQfomSOX+wUf3/9r
ovOevrEq0aYOFrx+gBA8OUvODmH3cRJjQA+yR4bM9ADG4hnURszFNcvnzU1XQGuxdEgdTGDim5th
PG3L+fHcbiy0ZHczT+/KnYbsEw9pJUyfOLmhYvPCm2mMVNF+2R9LQU7qJ+yYZMhwCtmHOctiyZ1e
Q6tOeAY+zCJp7g3qA58a0UxOVK6r8qojzSKsYDXRYO2CR+/IVZXxDYPmMrgwMdr9D5Md7f+Ty7gM
9+iEL4jSXKHXy9rmeKK+AhFY7GWIl+yfSOTbIptG5EA42ErMHk09ogy7AuNwwYHLoJHGg6wHTAcS
Qnp1OwcDMH48x3FloPWVvTKFWVfxBOr6ha4V4GM8AKACTUY6GthHevM4fR858JGDcH5in2fUapDy
17qAfNHPX3/7UwQpMyauFlGn9aIRsVqYsCCenCaVBTO2XkcRnnpVuViVL96n/DrCf3EKaTsqw4uW
XAdWsPfs5DNQsjlHPomSNXEz8gdcnHZlzBq8CGYgPMHsgKQExamrOQa1bqkLKgU6iIyCAfAbByMa
cl27RLuOpIWXZYDgDXUzpCUXLouGbDx4Uw8xFfmdty4FvMraw06MrD42pr4EXEwvBBer5OBijChc
nJWGi9QC8Xhomfh593FKMh5XJRwXpaXhoqyIXKSWkkdNCQpRshHQeOxZlB2h9IgP2u5GGdYg7lBa
swz6IbC/WxMP7O+DTthZtrW9FTaRgaZOfjNzenMn/CyQkBewgl9f1nSDtbBDklMdBu/5DM6Da6zy
KA0s8RyvueZqcHm7WXkYtDNnRbrnoH2qh9Cj9jFm+DfauQ7ULYx7PZG+N+vAoyZHIEC71/SNWAJ8
WInBVSE5Pys9tJQJ2k6oDMPA04hBPpFa+jI8K90wwb+8vDybTDWavqcZjXsixdgSPCu9rENvVTkS
WffbVFIfa9I9kS7W4bZinkgPtxM2W7d9iwXBZXn7ux4IICQKsvjisofXJe1gjN5aTS1v+7YNlHj7
ZC3d7bNr5HYTKnE36HZ2T6aH3bPTA911i7WIB2unQdXRszBa6TFPpBe3CBOpJ8RrET7Fk5xsbtOC
BD77Y6g6p3/2XozA2b5MFNc8o+dOeBFyo7Qvyolp4MBtsfe02uD7FnHXkox1jNekPHZ17Fha7x7Z
V199Ff3nN9/535QlDVnh149uooKIaEWBLq3VZxYgfSgTOFY+YxIpr9csT4CbCRYRb2J28fpShlIT
zIGGGxGTttIpVEgnkIBzhVIvshMlqXqVYWkUwKpcAmrhPRUpb2iCFtnwTB6rnc8+mBNGJWsbeShQ
hSRVsskYl0gVcj7i841UpukIHy3/8T3DUVuS5bMnJT+oS06AUxLmm86BWrr2392RUfo9w5LnHoyJ
37ebOuWVi8en088DNdH3VQqfjMgiVkdY+jir3kQZntoyqvlc74NGf/wBHRbrovPojVM/fHXiUSo7
RTVrCXiPxOL66gflAlkV1dfrhkorXjcbedi1v2IMLqDWp9O8PwY7nfpsYcO0+cfbnmfUB9zX7g/b
+tDtttNWz5KOVfjCTtX4zRzeVgz7xqpXfcvjUEGmb8DkO5lRQcuSS2qRPAcaS03hP3B1fEUK2zcV
b/n2oXjdtFS3h1VFmigCBrHDNbRrHZBbu9bakrtP8fuMpZ2PwUfgBihWDxDqe3Y+Tr6p5WF+F7w2
toGVfF81Maik2XTxlgkG1RrGsvreSGRti2zjcLWc1Jlw8aqQx2nq+OMl4k0nDuFTDs16x2rqInW6
WIDBk5LdEmxq3ASMb12QMO6C7ZqtOe7cu0jsP7qupAMcGFqMb3m66GLFOjQpBwU2FcvX9Dzk6rb1
CepXLBxMtSmhq3aLXnfni9cuBrjxxsv0PqPbOC/5CprXpu0jtS3wCqnQdo2vh7hiq/BMqEEZ99U2
zLgCBMiFdkuRVkvwwIa2vinjLaDeE3FTD9JjcVwc56DQNqOti6XnZ2dnHoJC2c8HuDpj+Oi3EC52
naUeeL1M17mLKbI4p9zFsFevztY7D/N68frsfHV+7iEz6oENTztSLi4WLrami0HR623l5WvSmnYe
YtuQmnmllkqreC0t18WDuhyw7VIfLF+fX3zpokRDmjZuipWL7Krm/OwLD9OkbOEXe8ta8JT4y+YA
coXHAXh9KKa8OoDVV2sOxAxEobFtnR/AilSwQ2jp2F5EtQO6FxK1P5MJNoGRrgBtkfxSaEbX0MHX
WZREv/xzFNekotHLWVK+4+TXl1HMe5TgPpyVpY+oBgne8Qxp/PIvUdzdNDSCqTq+XRtBKf73/6J/
dUsDMyg7e9IBGDniO8BSWmuBTcDuJlbeGm1Fqg8uybSrlmU5NZESlZMHzL8UAxljT0/BlF7gABV/
3RLitC6tsv7tSXmHCL9+R1tob7JYwq2IMxlI1M/sYYmLmafuuOAC30rwoNiOTvYUuIdw0zqdGZD0
QTcdwTYP1CRTOcAwjeyXTBoNOGmGNZVPIyPNYxF35NVSOpDZxri5nb7DrcwR/B05TRWP4I/k9AV9
NCYejjIxuiItjPTKJPWhw/pJPeCwflIPuF8/6dGIB+hnP7ONGdQWPEyWy6a02JzMBzH+fFvwdVdV
mwgaNvnWh7L2lptpuDPL+TzTM5vjU/M30Zrh1EZp4PNsPvSgvan7FFMQt2Ivgd23b78HdoVnLhbt
WlHMy8xZjxpaVHEtSc9nBd25t1b19FzciI5Wss/QsSbf8bZCcYzybCW6zSreVWCdU8wufJFMIfQ9
A7pj/ifXNXChryXX8B87J/XwRrCPaNxXtMBrFqe4TuFcnGuqLPi1VKDp7BRoJurHuzMX4jqa5HWi
4sWrlGXwnZhd6QhXviChX73RmzA7NalkWakKEONL9WakhjTls9sZr84GV7iX8hUK+dUa/UmRmXx8
AV+fgG4COgd13rXPofkk6iUHC0UqA78Kt+ezK09Wy2iE8tMT4f1Ikh18F0yu49pbBj3zgC6l2Z6o
vOXbTDmkx55xF1boPm176zdfwiwWXCvfmQBG2+VeO2za5ZBEjo6G46A3QYc0fjHnu35hEA3DFhcC
+tM+7oNlozvQA9ynqVe+s/Wykvdfggldl3wXqv8fWtKpO9NVFngc4FI2jgRBUB/8x5GR2dMFMLTM
JcsTlbicpYYVtSQZzAkdavJKfaoX44IePlJzdUPbkQ7GuqzG30T1WRl1eB+niCGW1b8Huql5mGGY
E1OH5Da+FZzWgGDiKwrSDkZIwWyoJ+9qVT8FgSn9pxpCqcBl+wy0gLuTMCUtCW6ETaAGl763Tbn0
OLsft12V/HrNRAEzGBvEmX6fIdQN5kNFfA46gyTqE3aTaMxS9/zGYTqF37hcw6tg9BDCJXZ6Ywf1
OlTYwYOi+XJvR+oFrgS842n264t+i+nF7IMLLWfJuyKFBLjhlNES2BnXl197m4f/yoEp7slqCG8m
htYQ0nzpSTZSr2KqLww3N9w9EEbkoZmgMlcFCCnzEZ/MHogcV8fxK3Rpy4UI9O1sTVM3jG1UsZrF
XOgzPjHj0I8ciUuP4UlVHolC6R6J2umPxx2J3nZNdUdUlauvnEd/ffvTz3/97sevUF4fUf95kuDB
/JbgZ80kddeyx7iNT9UoM7ZUvjIfrI9++Mu/L7HoH0/VfvR+bytqvGce4WR60hEk5GqnOsBGRtER
tNvgG3VjaOD2zFgSLWnESBqMt9cjSei91XFEzMesR9aFVmSsYqpqJAFtYuMfYD3qCXJVlLW4LvoI
Onjd6RHZIHK1EY/JqQ8e6b3tP5ltatbiiTbcm5YLuAqtH2mby8dPisf7vJ4NPaq0MIF6RD79m9Dy
UQU22XFz9vHZx3DOb81I9eOJ6ENRZfRHtCNtLiKpuMerr7xmDTTS9oUgoNi/azJinHSwc3S7cBxL
hOqJTVePNPc/CZxWO/mfja6Uz2e/SsHrM6hMuAo4L/HBGCt0uZGmKTqG8Vod/nD5s0zlHjoGV+WV
QTZpK0y4IjXJaQvNUqgKqxK5dYZx5RTVBrJuzQHUlcdQX/9lQeqslJ+Cx61sPG/cVK0gKoCfqOe5
SY5vquEL8PCzVJEyyLgJpe1N01kIz2WbsPxSNABVXnVLsoFpJyBuAhqSX+U2wmmAuUWgP4+qk9rP
o76L/imKqdzXT3XS+X9AcdaspNGvOMLdcyw3rVaapJJFchZzJJeK85KbqciRHDZaZdJ1kpOyuMWT
227N2qim11CyAfK2R0VNyuSp9kESrzqqlMM5Ul41g0wNL0krRDlA8wZy7mHRbMwyoa+O6iouKH4t
Ylgojo3aAKfHCKNnu3Yq+t9vv1/+/PWP3779efn1j9/87Stkd7GI/lHT4IvF8WkwxB2cBiP+yDQY
oo5NgyHqrmkwRB+bBuuoT9Pg5zsNvlh8mgZ/mgZPOg0GE/s0Df40Df40Df40Df40Df40Df40DT6R
afDF4sHT4IvFw6fBF4t/6DSYXZo7QN4k2FTWmQRDQb1JcJ/k/9v71vamkWzdz51fUZPNM2kYbCch
MDQMnE1Dms5zaOAh9Ez3aXo8siTbmliXlmTjMMx/P3VXlVS6OJYDFGv27qBadbFqab1v3VdplWke
BBeZtEFwIVYHwYW0MgiWH6M0CFYKkoPgQtb7IFjuW41dbRC2zSiXlKX4kAxmvQ3vSMkjUqDmnyeJ
ZluDp1QyOUb7Pk69sRsvo5xw/ZI0WN4qIKenJuRO0cmCnKSaLUhzFnhr8iqFo+6ARhIHGvg5Isev
8thllxgjdgjEFbaF089z3O6S+48TbypkmG/vKs9HW3/y4qv8dnTlUvhnxUSWF0Vd8Wtq+7KwZWe5
s1iUNq6WpdRMhZD/S0hkEB7+9e5dNEg69bfI64+2t3McEnWYojdLcmN2eIHGldcLD++dnJB3G46e
vnr969nL553f0ljIm9Mnz346vVIZXEnDEZdh9u9eztYKK+9X6YFgCDRG68XwiD9x1i6HB4usInLn
Yewx6V1chJssiQORoTudDe8KYTkUR9PhXbPhERDjvnXm7r1ZRhGpVeikFx6uArZlJM4EI5JilKzm
Qwr64XCI9kbLLB1NgmgkM8hEUvK4KF/mpjxChpDfBFPclro4NMjq0lXF4oTxip6b7Z7LX2Q+4qdt
jbnIyeTtdeTGKxya+e2KkimN2tLKaVNZNXFNXI3yNshvVGMlfz+6lDbPjiG2arSU3qhXQ5lt2q3L
0piiRtNXLMuo9ZqyetO9OII+WARRB3uu5KjTf7XcDl+gJlNLmvqvcNXy6r6EuTz6LfreXCruM2zs
UGz0rRfEqw7uOF4MmOOTZUp9XnX45nU5zd++6XdabaA1c8e0dTbRX/lmG2krvx/cUocDy4RdJzae
x+/zeLzM/DFxn9L2NRvyGr9ny2+1fdEu2TunrvmqPf+G8ct2+I1+vq0/Ddo/Iklk/Foid9tn0dJV
xTWKbs1lVJ2aq6d26/49skycrAbETxxhUzL718pjplxmDqsrv5W/GjN2SFfHW9uXa+arpnJ7+laY
EpehM0gWjuuHftSBoqpZaluaasldmpiaXG2JGhqVK5dY24yYS+zyTXqZyjow/wqd7pGfLYm9YyxB
g0HqL3wn8x+JQrCIHBt69C/fncfKSPgjynwPHWSjfxLZcDQ6+Eg+FRcOj7DgX+R7HaGBi/Z/8aN9
kpnkTcSAmJW0fS3pFEm7/c5X4YCfUPTIXYGL5azdgk2ZjDZcV3qbFTfma09WY8lbl2q05qZSi77z
9mentOu0xZnKKR47BbNIn7trQpAT6fZNv/VgEERkweGRZowD4oyWikVWapqycntPnSiKc0RXb/fZ
jM0+2RyAs5Ph3APkKgmyZZATH+Mo9SXuEUl2WyRL/SxerMhaSHTR1zFUsa6v6Opgj589DC/Y7P8w
uUROGt45Zn+H3eblassnW6zY/2OhTJAsJ4vApZspuG/N3f0IFonFwm3MjpSsDtuyy3BCrKvy2fFQ
oLfvvkubsqRsZbq0t5+o0nAZ7QaxgWY75arQaDkXpU0zSu+dsL+2oHQ7qhZz7vWELWflC9ruvedT
zPxftf+j16NUqskS+IIx3/O2c1ug++twhmv+veuwPyPwq1ZTG1lDAhuVYCSEaglFb2qbjoHSrM1c
bM//oFj4h5+mcYr/ZR79icfoPKZOctHg1TF+szgM8sE0xbY/SGLqPB4Lo5jfADBwFoGTkbcZ/MPz
3YXDJsYGzhQnHFCn8pSBB7FoRsW/Q7eFA3YFV7YwtyViSSEG0NKyu7JXUUYDgdESCw6roQTcOvDT
oNdKCdf4e5+aEvTv0BTfTAyblNNED3o5eseBuvhkxiEe3aKnz22FtyL3Tlpg+Em4gr928fqdMcWW
2NthxZfid987kIv+2zKOWjPjL2ztjKc08NlmL315DNVxWzLJJre1KCgm97An+EO2orT8WVuStGB1
49IaEVsujYJ2OBK2/pg4hBlmwQd/23kMdV8JsZe75ikNbftJAQQvmE7RYInHSVM/9SPXp+9UvByu
nnzux/2TcbKiDo9398ILchgDh4hhLIKJv5heCaPVLTgaRO9WIHpXQPRueRqzqnFT+XsL/F5ZNyTo
mqltucTuLhy1g9JX+PWv1PDWlphdZm6+6LfMC3I/Sr9FEtfa4zjJ+i01CoN+C5y58arfEreaAWjq
X5EtFr0XGuMeyLTfUunpujG5njbye7bTlZ9mdNNAn4WGfjim79x7sZjEd2BbW8wkNHff+yxw6jv5
MvV7hj87c9l3zcnmpcTp+fO7uOWdOO5Fz3SVOhhbdHq234KT+SW5lGpH5nrFUW792y6cHHdzeqbD
HEO2Zypc4LFb3vOn4ld39dxYsz7FbjpBwg520cz2WeZ81WtxQbdT2V2JKgvVz8MSkTuVRi/IDa60
K49DfX6+YnTQk7mRZ1xalqdLl17OVvzCiL24qBcfxNAEYqU6j5cuyzLEw5e9q74Qk7HDaNudRuG5
6chpEWPG1yoqrP6LeVFi/1/Gy2LcfzEvSrVas0hqnj9oTlG3dHq1sswLquay6GzL5652QRYtE0Cf
eS2+BCQGcYf9QC0TaOWZs8+9zqSBrZ9W+9zfHnchrjzNt+38XnVij8/o9ao0eeCSVHfTc5vN2tvh
i97q2L36pC8pewn9ve2Oukjm18aUuotX75+qq6/PexG9v77onezu9cXScY9vLhv4mn1n9f2fDp2o
rrlr9qHtur+k6bZni6Dd1Pqm7crNBj19vU27QQooNRzsRPfuVBvEfWqWdJR29qpkAqDHdyUdnN29
LO6A9PmypD+z7YZ1xbxqeqjU2Iouaj+3ifBq9H+Fy1aORlrOz1Q/qjiUQ5wklQ52Etco2sEdc5or
/maSBlF+QaaJQifPSj9Wjbzir6xyr1Q0l1xVU2JnYkk5iri15LpmTzfTurj6hq9r/rqmT8+vH8fS
tYBJfzqmSznLhZ+OqWu7H1/94+2rkloa013xC4hlSf2XFGnncjc0pCQciFWLsrlWI3s5gXFQ9zJO
6A2Wbuz5BI25E0R+WnqjmhRX1XnqZHNvUtZ5Id2NzumF2WO+DKv/djmqrgjSBqXxOHSSBH+DUiHV
yN3UgzsjLauvkNZy5Go+IE7swnJePWJHFj/xBnT/4pSsVpUMvhxXy5dZOJgunOyiTJiqfDfvT+BE
N2sOqIfB6uc3J2giAAPsd/r+bM9canx1Pa6hEHYPerWAQr4FJRJfjlWlcOmWekF4EIEEIda9BF1P
H9D19DIrl6PqiqB7p8bYBMYX3jJMSqUYYresV9/+VKgbxao3Fb2SeeaGuDkoVU6R1jIorvSAuM3j
vbEyhxqi2xSg+N8bzS8TPyVbLUZkSaiHLbcHe78Rp5pilOFkIXNxyVdVcZguZCvxtezrBgPPXwUu
hpmf+emKdnkrXdX6VA160KttVgj3QVmMgPwUF9XNVTN1rEhE3MklGrwy/DAZwA/eogO5FD+gmGPr
1YhnPaCpfkHK1iWkBu+d8ARreUgKKSEZLfcQ4GDnKrDFZPm1+Jtpq9FpGsXDOfvqhYP4aYA/+5//
jIjfcuLiGxEvEEMXpcuIusF3Ed8z5CLqxOMhfisvplYSscV59v9kz14ckfJGN6Za+SPiXDzyScY8
XTZtWK580itvBy+8J+3MLPgXVC1DfNQ246AWVGcZPFI3ix3ZQk+n7imxcp7Fz1lfB9N5uWwINube
z9iYC9Gpt/3/8bCBRT46//7s5bOzN+jdvjKBkuGv/m5/Hz1+3JjXlLVbzhdn35/+cvpUz4pfmlSm
e/YxfgFjEd3fovL+uIQOOc9/fPLmtKq2uZP6HXL/cvryh7M3P/3DVIasASaTbkWNn77CxT0f86L8
3O2oRZL3/Ombs9dvS3lHmZsGSZ51LOPFq6f/V5SwcmhFLjpmffPzSzUnps4N3v31k+dnL59rv8yV
J/ueppI0pyBqlAxoEyA1KZQpDr34aUAPc2HeO2LHskzHtcjxsMGs5thWlnuPZtHyu+/kiTDDSbDm
s13/wOUuo2Xme4PJMh9kfj7A+gnokX01ktocveUA6zVD+K2fjcf0/qRXr16cj8do8NNPz/CfH9Bw
7Y5JJ2wYDz2S6gW5YOmHsxen4/NXP795eqrJ7p1IKdVAghvE4IM/yIIJGQQNSDOQkRzPX/4sUqLB
WbEZjLeJbNuXciQO94eIjjRNnA3Jf2K2FD9vSJPazLQsJcnnZPiLBkKyTalsRnM4R2TlYhAjqUv5
5KJ+PGoUc8bi+A7rhOzNUh8b/AodPMNf6OUp/cjPfz49fzv+8cnLZy9Ov13E0ezmAapuTSaLMPzQ
40Zn0kbslwf0Gu5BFi9TPJBPLtFjJi9+wh1G/nurQTPG/REATn/AYfrUQgRAlK+N1lWVbguQYtv2
rvAhfsFyePBthICOftAh1KkGMDZsNR8vDp0gAuvpx3qENpXnMq9qrFQRbs2qpXOBO+NW7XcYw+rV
rCaoidq2ysopuF3VVv6EoaJ6XFW6bfX002i7qqH6K3a3l/4qd+dAeD0RntCm8uyihsnyRj8ulaS7
nEDlM5/qBCqx500nUPk8rHEClcXtaALVVnzOohzTEOCzH3wKbSrPFndmyWofWE4/lsN0KZ9IN3a7
jozwf7KrLgwr39BDq/RtjBHbVk+6othV/fgP2N07YxuOAMK9QJgrs3gsj0UVyJRE26KB+RDaFRRI
6QagS7Em2LYqhdeOXVVH/ILd0Ba1BHD3Am6pTjVgcd8uSYOVk8PyaV/mI9SpBsrtg9rlKMu2ptXC
vdDOeFX8hKGt0Di3Ity2csKH1q5qxsq3u70gJ1MA7f2gnelSPlncTLgMGmA3/ayGcm0qz+U2QqGi
kmhbEuWu4nbFobR4U8ugtRpV6dbV4q7ldlYvWr7dbQOzxWOAeZ8wPx5qgTLQC7zokm3xwL037woO
tHgDzBWYlETWogaXELn37t4B2PQDm0KfWsji3lWag+30YztEk/zfMtEWjKVLqkRrqZXlkyWM/Hqy
M6ZL+US4acPmWbqD31kLzX/B7i5rEoJJ9zR1GQ7FvxXqVE2pIty2p7r2dwkDUrrdEMCt2Hge5/QK
ZsBCX9vVC5WWBTZ3RP1sGcJiUF+dUa5N5dli26HTFmA5/XQvqS7lk8VWU9xgBKbTzwbDQqF60HIj
4k6dwIp6syKh0VKYHwlH+Tpv8Y9ZJDG4vJRxwlFlUZ7qaVJKmz0vymSqk0TlJyouDGVcnUfBokTF
BaAUVhz0yRiD372iKMUdXqEb3dVd8dIVL3SFhjTfcqriTH7fNDWYVV14WlOjFP9pWhnC9ZkUVlyR
yRiThzEZqXrmKvRn8rpVKKvBM5Wq0bLe8WDVmZW1KCrP/GRUVElQjt98gBVZzrkYRH7+Pk4bjf4P
P1wOlgk2B98J8ejhfR6PMbmNg1KdiBcmvfj79wZE/asB8bZCkFy2SfICy9AhNu1SZtWj56twgH8c
Gzym0mVERy0yAfN5eqQLimvnTWJ23bQxRlxrqxevX8JS+mmzkPlgJb7DbG6lHNf1swxaqf5aKaHR
Utju3k42T8GGerMhqk3l2WLbmZMvPoaFoN7MR1GoHizPoct5aE3Qw9w5v1t5h/Pn9BfsnkPnN7OI
Hj2Ao5+TUiWtGmTCwdg2XoEbLoAQXeIKFgubrgj33NbLIdrHvuy+ja3BLe443yG62U/YDW92/A5Q
3QuquTKLR4xh1XdlN3B0SKb5u+yxVMVHZrdS9RtBjPzi1l/u0jALRlnCqDtz2qZ4s7auUo5JP+Zy
NlBMZZqPC+pVoCSoCM2Vbc5hqpaSw2IXqfkCfKT2RoBSmcUjIcBOIDBPbavSejiUU5ljajizY14j
M5bydsB8N2V0nNFvTEbV5RouSCrmfgthvW5bf6NjUrP2+yvd9H1aS2cfzFTtkm6MEeYqdctpet1S
TrtZdxHPZvib4BcMYmDfnthXV2pVZJh5UcY4VWnbyFEfxBUX/7r1F6Qp/YtyHCWhDQeC8sJeorTQ
dXY4IKz8FBsYtvC9uftmqnpTfF2nbvNyzF09UzmUf9yW2+VkGTUJ6huWhgyticzq2K5Ek2IaSuyt
rTcuoivCeg2WEhkjatqoTjmNbZSeU7OR+pX/ckx9nUwp62PNtdu0DFM9TWVsMKRr2upQjatXhzlt
U7xZJVcpx6QWczkbKMa4z0MRNli7nsgYUWPtnXIarV3P2aGetU3iFu3aNbVplk90pj6vPnQ2+9rC
zfWphXAX0zXfVCpRpcsbJvoq6eriaib4NshvnNir5N9kUq9+j1olqmGiz5S0Ibqmn7hxKcZeoqmU
DTRStzVPFTfM8ZST1UTVzPJ0zm2c5ynn7lBrW2k0yWB/TV/HCjO+uYY8KLzZtlnVHN84PVqTvi1N
7ZTplcurmUatKW+jRZTyDl4haVpGKVJUpfVj7qY8deNrrUraJEy1D2aO2UnfkruNv65pE/5rXWZO
anVUzL3Ux1aWFczbuPWo9gUGLWlDdPNSQ/dSmhYdtFKYVW23p0K5YeAazKGrGbjGS8tVbRTixg+o
J6uJqv1wHXPXfDA999fce3BmPly20F8PQqhTDSg9CeORFEXY3DQqiYwR9Q1ke866ZlLJ2WW2xdRG
SGYxRlRa0eF6oXLlP3/77cFk4UQXD37//db/HCASO1xkOSZEbO5oEPnoILv9v6TM/73NCr09O0B4
oEjkSua/4K/6bjhXi7tx+3ZyIJmQ/jBt2nHxlAnFZ6s/NFSOqf+AppT1seZPuWkZpo9qKqOy7Fqn
EWOE9q4b5lTesC6nqSnlqaodrv6sxdBN6mA9ps6VsKb6DlQTSLQEG052Xq+WNlRPBWWNB/AMkWx5
0tKGGbeoyzU0y/00y1yZxWNpG2hXCHdKWE+H25dcR5cNJTdzuwmQzSm6Va9rWV0qVFuTNnJoTGBu
Ya9WkqmdrSmpS2t2BZLfeQuIR/GbNn9k4C84fgevp10i2uHd9EtHy42P8YC3Iqx07DrVuz1VR7bY
sMxOPKGUWQ+tkgqMEWYodctpgk4pZzODGT9rS5J6pV+ttDp1G0vrMIzCfQg0WD9E1HnF4CnOMMuK
rQyNXgdMsaYDPpw2/qL/xg5gqlyx1gGk6oVsAqLmjRg19WxOUbMZ44plGTdk1JTVbMSGajcmqDfg
zUuqM15DSVfYb8HMTK5Ad/KJUZ9I35HYn5HSxrqDebJDRI2G2fL2nRLWLJ/3UrJxYb255C5b6+os
W9NYTVS9NXfLXWfBWm5tZxxxuxI66YWHxxba/oKvY1w5jjPPT2B02ePoUqi0LKg7cKjYWkVYu3um
IUfNfpn2Yccu6JRt0+zAp3w/p4lQG9LVxdXzSNf8dUyi599oeyV351RlG9XTU9MuSz2VOaZun2W3
vOadlnre6zUgfg1bBwsSF7ZJE7paM1Uqpjay3sS6l1BnZKUStAZrrTsAq1rTuuIhrMPquZa2Kb5l
/XyDchpX0LVyrtni+GmLLiYnLoLqZnPqLiLNT5vxI1ZcuTVvIzKlbk5Rv4XoKmXVbR8yldU8BCpr
tT62AYMblFGLwlIZXcY8fXgFGZEB+MHeaJmlo0kQkeAxZgM0eIESXKJw4jdJAw+zMo5Fj0uyhOxo
UM6Y1rr+Mxheg5fABgNsydUtZa3rhF7KrnGg0Fj29TIPPQ/bgXbYnXqtXSUtWU1UPYK65a7DjpZ7
g15Sg/vJqq02+6psmOsy2nB7aV3Tmu24z/JNttxePju23L/dEnffHcyWegXfsnemlmGOqbfoLnnr
7FnNq3XHiB/UqmVy76ibmqCSrSI0G1VzDpOZKDl2Zg/k7rwuBkHv2GvlMS1ZTVTDV++Uu/a7q7k3
OVFh8oZraG1rnOY2tLQNOdpT1bSwW5ZpbFkbylTcJzx7ffbUxsk15mwlCVyYWNtmYm1KzUNecCOU
KgPEa8J19c7IxXsdSI3ez7fheLDiGNvcL684z27ukBuTtySp74JfrbS6TrextOZhoapYc0x9I9Al
b10ToOa93vGA8PbRba8qcwyymeWZfK5Xba/GM3vzRojyG9XHNu4a7VxGw/5RrYz6DQ4N1WxNZMbN
diWasNNQYkvvxImKGYUk9o5zf50j7sc+Id7wRTLpaJ9+3yluSQIURKUbmnmIravJoBeHh+M4yQpJ
FAZFYObGqyK0ll6Aq55DuUTfNTGvXkPJBcV9MaqIzNPP9fv6eGDqO/ky9ZX3ZONVNfWAWVEhI83w
xHEvlPoo6+JSKOZuC4GYRpqXLrMXlVzgVj9XShCXwvNgEI/W2fh9kOqyi4kXTDUJbeZd3IJqUnoW
SRUIzwmqbJqVysqTsCSZTkoCrKPJUv+tyM9LiSaLi5JkmZULStygJCF9Aj9akQ+vyVeZm2lpMRxG
ycpLA2ISuti/f3yoS/B/Y6xJ0kOMZlk1Lk50WYB7GH9UkwXRNC5/dPoeuIsZ4mIfIi9GpHc7cKIs
KLpExM8TtVDRVS16auekgzPCVjOKliRqjVx0I0AfPyJ/HeToCHOBO4+xiJSN24/Hc5/0p7OhO78w
7z8owbgirPJVe44yH5VyKMcnzdORBnH7JCfu6LulOU4qElOcVyE84RuwRHvadSLK0r/NY5Qx7oDA
OGUH4xSpWE1g2gNgNL2aKDNsu+c2QbiS+8odCeXiHTO05JU8bGJM5woV1lVpo960cutjG7XXuYwG
HWplMD4UC0IvfGe13XqQ5WTEL18CLuqZixS9quE677+djDLI8hHPTamAfupRNndSn/IDHl4O3hBO
OOqnvEYykj92t58fayE3dndYDb8pF4tRiivK8lP8+u/RYNDtJQnsZ1g0z8MFNhDPX2M7QWcvn53+
goiM/in2dpVEcstOSV7aXlGN1Vfry/F1i6WldA0LUaWUZC2i/COmeWPDi+gTSKUEplGykkR0XEui
oiE0RzB2r4kTX778M/qlcpWXqBOzi+Wq9a652kOxhqor/yJSuLOvWkRJ3OzlWjE0xXm1+jMV37JF
ZJ27UqVQxe1mIa24sCyiDC4dVSwUbg010KgO0JR3rzgHU5SlucnSgWPwCqQrpEbxhfcTLU5xqKEX
I3wGFNLKkfQiynSOtohVDzopyjQdKlEU17Bvn6aa4zYzJc3vyEnxGJpQl2LHRSyb+WxJcO9ESbD3
jzTIsVYelFPWJiFoqo8k1amNVSLs7nh5cYhBCP2unvtdilqVYMv4r9x/aEzQPJrZrKSmMU2ppKtP
M6tNIek/3VWmkSp3r34F8y/+KnfngLy+kaeoVQnWIc9seU3xNVOnVyjHOKFqLGeLtR0T2r4qmM2i
nDpiApj1CjNFrUpQ3kJrqzWRXiPYUs+2JJUqA7V0XcuvrQTdKad5jas3LibD+ioZy1vkzft5TKnM
MbU175S3pu5a3t4mtWuuPt16Bg+XTZLv/YaViEumA8vfyUoqmyak4d5+hCrieFtF2E2YbMIEGLNf
xiy0WoSsb3vF1howpn6NSdWrGrbfoNJghX8CDKpvg1L0qobZJXelzUtq2HJ7I8sqYGw9G5tUqgxw
3hqcfpE21E355Atv9rmUHCMnC6nzt9Bx54OZH/m4atsWg1/eWS5wvcMsnmJl48y5UK7jXlDF0c4x
E/pr10/o2hFRhp+RpVo8VPJTInj245O/n46fPzkf//2nX9Tg6eu3avCH8+fn3z85xx86xEWmuIgP
ZH8kDWV4NDOYErugv+dkl5E7T+MoXmZY8++DyOOLZrjA50+fjn8kv3Z2fvb92Yuzt7+On7x9++bs
+5/fcvwRp/l5ELEAg5aCKfzLy8gj63DEIjL2ebmhDfA3z+cYDUHiU3vjDIG5IYrpplC3BeJ/P33z
/StSyWfkHZ88fX3GH58/+/78F/78+sn5+dsf37z6+fmPXPLT6U848dPT83NF8PrJ87OXzxXB+Y9P
3hSS109F2WevXr9681Zkff3sl3ogPXv66uUPZ8/HP7x58tPp+PWrs5dvT9801+lLxKWAm2mP+CC8
c0z4iB89kHvFg4rEBW4CbgJuAm76VNwkzpsEZQEwEzATMBMw06djJu24X2AWu5bPEbjsKCLMEvS8
D75QqxKEmQJo86DNgzbv07V58ih6UJFAfxy4CbgJuOmTcZPq3yIwCYGhgKGAoYChPhlDMf9DgR78
OmYIjmGKYCdTBMelOYJjmCSAZg6aOWjmPmEzx0+9B6UwdL+Bl4CXgJc+GS8R756BGgBGAkYCRgJG
+mSMJI6uBGUBMBMwEzATMNOnYybhBjyoSICbgJuAm4CbPhk3sc1wgR4EVgJWAlYCVvpkrESvSQm0
EHAScBJwEnDSp+MkejdToAdt33CCS4jce3fvwI6TnnecaIrVBLDnBFo6aOmgpft0LR296DHQQtD7
Bk4CTgJO+nScxC9+DcoCYCZgJmAmYKZPxkw4rmAlEgBGAkYCRgJG+pSMRGxEYyUqAGYCZgJmAmb6
lMwU4xeaatTEJMBNwE3ATcBNn4ybnBQDgiCDJApdp+CoSoztq75pDuu9Pa/3cpXyR+uvV8knS7ju
om8bkkqVAdgrAL0m6DVBr+nz6DWZe0zW95aSEFq6vm8RC4sLxEJo5aCVg1YOWrnPpJUj/47vHNdM
D/BImM0ExgLGAsb65IxlZCrGUPhn0cB/iALv0fjGt747r95hN0cfUZ6ig98eLOL3fvrg98FoeECC
yyQhwfF4fHDzIXq3R3Pv/08wjfCbohuBt48eVwojV74qiXHKAEOFJW5NLer+N94PprV+vFFOrrYi
YafsSerMQgclOO7bk5uNOWapn6DBCh3883/Qb4eD734/MNwK+BEnTC7zOYZvV7YTvWVSFOUBb8Bu
zh0ml7i8ZRT8sWFFmuvBM/iRF0zR6Bb5ROjWqDaL5eM7N1mO53GeLJYzGOj17Xi3pNuyzPqJ8tTP
liFcQ977ckuhViXILiEfTKvtHL2NvCJtaCLFzYl9tJCyrC4NZF3i1vaxNSNvHmW6LplrG8dKhvq2
sbiVctdNY5daNFaitWHUcujGpkVVhE2mpl2C14vB6SV2MrvGLO3G1y27MEE9dfeC6s3RnK3BKEsX
Eu7cNDvXq0O12s20ms/ydpb6EIFWtucFaaFUGbC+v4YrOaboAWPq2Zh0zeqScsfNwF81UQ3tqrxt
r48mtSisS2tam7q1IW3PydvQImGn7LUtZzVHfaOp3Gi46/ayU0Wa69HaSupZvgJiS5wZfklgth0w
m6LakqjMbbrVVaUNjKZe0NcHqWnldeG1pgyt1NYpM2c3LW3XQmo5zpipnub0yxF3zXRda9RaoVa+
q+TSDbMSbYxoME92R1sfhslL6mKS5qStxtiSjZshT9Wesdb0SsnrjU7cd7drc2t//4bXbzUxJX2D
ofBLjvqwFFFUF1OpSdtqK235uLGIZB2y1ppLOX29vciLo3ZtMB2q0FSDVpNRM3wFfTDHdf0sgz7Y
DvpgimpLonIfTKGpkqiBtcgtSH1QFi2nC1+ZEraSVWMmzlQ0TVumWo7SEtcTFLtBatfs1PbmtS/e
yksytf2klM1TIKT+CUmoVQmWiUht/MqyBioSVx/1QUeyrC6UVJe4lZZaM3Jqkum6ZK6lqEqGepoq
rpXaNVV1qUVjJVopS8uhG5pkM03QZGLiCptebEwW1snI6lK3W1lrTmFmMmGn7PWGVsnRYGnFNUE7
N7UuFWmuR7uxaVksbyTnpF0bw6HX/ttJXbO6pNxaavxWETaQGbv2pg8m4yV1oTFz0lYOa8nGCYyn
as9YS12l5PW8Ja4Q2jVptb9/w+u30pWSvmRUGo9VpZYzG66kH8yiMe91Ar31S28G9RrEZaJTjLUk
aiA5ukGjD45jBXWhOGPKVoZrzsUJjiVqzVZLb3rqenbjVxHtmtxaX77+3VuprUhuOVexOTqgqH4p
qtBqESoTUmFiuqSJjugFOr3wESupEyEZk7YzUnM2QUksVXvGelLSkzewEr+MaOe01Pr+Da/fTkxF
equZKV+MXdygAzP1ykyqVotQhZkKGyuJGriJ3nnSBzWxgrowkzFlKzE15+K8xBK1ZqtlJT11PSnx
e2N2zUmtL1//7q2MVCS3nZAW8Wzmp2Ny/DsGYuqbmCrarUqt3yqf+lm8TF1o9nZwuLFQrCaw3qaS
DFaie3e2lRXL0OS53IMq2kRd0tR/4pcz9dKFEmV16kXVJG7vSLVlFH0pka5L5voeVTlDQ6dKXny1
835Vh1o0VqK9d6XmKBmZGlUR2s5qzszPnQkwW9/MpuhVDWOGq+cu4rKyD96i5XThLFPCVr5qzFT4
B2rPVMtRWuJ6fmJ+P3fNTW1vXvvirZwkU+t8JMWaoNlsCKz6Mh1WVkfzMSbuYkLNGQszYum6ZG4y
Jz1Do0m57P6iazCr1lo0VqKLeRU5LG/GcOOzXEMj1nMjVmi1CFk/zqPVHMeZ5ydgULswKEW3ZVl5
/KdRWEXIDdE2E5yNkzRY4Z8YxmB729geszpFnWqgrSPOrgbrqUvFC+vYpzKn7tKpaslZ9Kp4wk7Z
m/pVpRyNHStx/do19KzaK9Jcjy59KyVLhbSUuKq0we4q1z31YX/VQrvYYWuuVnusL6GDbdVnrrcx
wzVau7a1Vi3V2VxrxnrbM2e1tDF0x9kyS7AyoDHsozFU1KkGyv0us4nVx3aktN7pbHMq247Grkxh
m9LXNVPXlWjripRlOV15cegEEVkXzekOIWCtPlirrFWDrInD6vmre3eMO6/vvUcmyt24U1aTcbN+
WbmQTbtm5fwde2fyeoBr7aDVaKxTH60mb8dumprbdurLnBXwXr+8x1RaFjT22lSLa0zQgf/65r2N
+W4rnrsqv23Ia9fLZ1fhsavxl/28FU+nmG98ukYPxNUPcek6rUjqqKuWshhV+eskTnP0+te3P756
+YjhjBjz+3mALYBW6P3cyVGErfIh8mIc9c1oEkSjbL4hHGfYtKaBv/CyIc67f4MUu89fanyDlF/a
tPER+esgRzf+D3kfj1zE9TeeYLhe8GSLLJdcWEjtBhepLu6i081UgK1esKWptCyQ67OWmRL7ngOq
lK/OkNQb9bJgFu3GtHQVoxpNjLRklpsbUSfuiIG97dDehI7bDI6ns9zi8AAviKYxmNwuTU4quc3m
REJbjY7NKPDDrF+Zxe1uyobrUwtZbkGTOM7BgvqzIKZPLWS5BeGv+ZX2tnZoRopSqyLLDWryIQid
mQ9Gtb1R8Vvnv/9/L86+R4PF5MOxEL34fz89wZLFh9ApRK+OfqGy+LjMavonMYstN0v8s3y6Zrz4
cAJ22R/ZlTVbI7fcviZBBJTXe3esUGpVZLlB8UUPfhgIbKq/QaKqV6PUcsta378HBtWfQVF1qgGL
zcdNloEHBtTjomKhUD1osRHNV7gZJxtuwJD6M6SSUqsiy08QK+cN4fRwj6eHdb2WjnLabFDKmR0w
qF6Po6t6LR2HstugyscpwK56tSuDes0HVr4KK2Ob18HEdmFiUreGswF2G5e+wRisq1frqijXtIHb
bvvSNtmCefVqXmXd1u5httK49G22X59p7Xynn2JsFV1vuKvZZgMUC1pggddggYqyN93nbLMNyo24
YITXYISqtjfe+WylGWr7db8+G9z1EFW9Jcm0F9pmm2I7eMGmercpqVjz7mibbUrZzguG1bth6dpt
2C9ts4mVtuiCmX2yjdMG5qt8m5Yd1DYbanm3L1hq74RoUHHbnmqbLU7ZBAzG1n+3TtNuwy5rm01M
3xMMVraDAWlJwc37rm22Nbo9D0ysdxMTejXuxLbVoJTtw2BS/S6Wapqt2Zttq1mVNhODafVqWlXt
fnW7tf3IzdMFu35ofPry1fmv52BmvZpZnYbNMdjcnBSlLlmy4gmGDtsfIlyqkCftoEqCf171jsue
/VXuzvnzLMrpZZzkGWvXZU/ThZNdsMdkfonfYsUDxX1B7hgb1JT/UubOfU99PmYBbIORe+/uHRZK
ud+OfLLkGZNQvup4HufJYjkbitu0lyH/nTz0eTL8gF8eW3wRTJwZNogi7LguHnnLcDbn51LnxObG
8oenWFPBLCJJ4vSSyS78tU/rny+kTiu3xutXfcubmrWLTZUL4ipXezHKQOpq5+L2IIup30zyrHzd
LB5i28IEMXdS3+OrlXrk8LCwALldSBhB0SgyO9A2Q8qgsAYeFAbBg8wmeICbhbi4VViGCGuHEIR9
iJfgJqIFj2W4MBRxe3qxkMHMRfxIqNarMJri0nVqNyIrNR1RlcJ6FIkwIEUkbKgQUTMSjUBhSUIt
JWPiYm5PNCRNSoR0qypfGa/e/F2+J1e/dNB0VxyVDRbeAumUMVv6WU44Y1YCsnrxScN9AoWv7aoP
W93zZslfYtmdXcXXmLYmanb0Y/DXUuMzo87ZgeGkuvmgseGon6lT8Fn63K25mKHNB68pW9Unb73j
/s9dFZvqoKXyvNaLCJPz1MjKFVltYl0i2wdjs8AQXNcuqLGkYSifC6se62k+jqFtoTdufK5sV63u
KjTs8jLtuanbFVFZ0jYvRdav/zTM1JvnVWvnwcwDTfPYgFHwlZe4BosPW3U4mUQzLISkaRV2Y+xo
Zk1d077fSodFyYKrwvrkJdFe6Fz4v939/QF64TsrMs7ygtR3sZlfon9tWImDva06/2mcZXgYgYdr
ZHCH9R4e/vUuhm/SSZlekOUjnnu0zNIRHcOR3/kM34oPlvp8M/laJpb9fBQYHt47OSm9prPt+zW0
L9uVPNqgeerzl3aicW50I/Ez87KE9Yo1MSkRd8GH3Xofn8zaS3z42Zq7GFn0ae+91n20UVPS62/t
2ubZ7/RiyNrFI3W93qb4z34cIK4O3mg8RPK0DIaKy2Zpv+Okp34HLezOloUdtH1X4/UyDck+y69M
Z3bG7tyJIn/R5RPrGarft1Rg8XHJ9zgl8/pbfBBcDho8Jf1sOvJCHJOF9Wz1AyNR7oGlDop49cbu
IqDzeb2tSRRrDXRZYXONa+x95YUJY2msdeitOFnQM6JkPEQdn7999eb02aP9d/sj/IVoUyZyeu/2
91sUJ9Y09C9TkVi+atbzuVWwxyva4+DZz+en49dvf3xz+uRZad1NTO3bfpp1nY2xzsAgPwuDLJmg
/DLi2VpngpL/4yhPyTIk2OKnt8VSYy0+TVVkrVn2eVUeGOKWhkg3bNh7ZZ6gezC4z8bg2AexvvHN
xrk3GXvLMAHr+5ysr/gqWshWO1zmQa9304IFbmeB/Hvwf221OgwrsLnPxubo16B/y1fcly58N4g/
yxWHWepE+TgnFtplvUFNXl1t0Aqz99p7ssgRu4DKzweV/IOIB1vbAqmXvm/0BQPsZxLKk7u/dYH9
Bvneyd05WORnaJH8y1Qk9tukOCMERvnZGWVxkq8sst8sc9xLzhw3p+cNwDY/O9vUvk+N3FYrnTvZ
nI3fwDI/F8tUvonybJ5/MOz3a0zwWc5JsDOnHWYjWMLqPAQvwN4ZiIKUkjgL+ry2F8DaVzPCv0xF
YmvTEUS4GqKyA+h7fy6G+bnWjgPGbDZmsSuPf7a5nmBHgbN4eGd4WD1jrMYO7yh7KYsNbcLrQKZl
ccQuD5aQvo2+ECoWpfhCgZiYpK+sLZOyqjRMHFXH7YZBU6mvKnYEyN/VX0ftSVSJivyvF1MpHdlV
WZHVuuab6x9nV+/TY5HidNS2ZUphSQM18KBKfIAoHT4oae0BehmjbOnO0ZR04DBfyrMXWq7dvHHT
r8tTIbdu3UK/mer1OzqlDH/U0/kjUbxyBIn+drac4PLEgTT5FuLnj3s7sUSKOdZ/VZ6DK/3acT+/
dlTol1WORpZ+SyT6hxPk5PemOGoZTfEnyeYYov+OJ9kQ/++zHBtw9zQdBgc8ZXV0IIpgh6GqYyhl
9GCM+Cz1IvwYdVCMSFrVjCykTjXm44JtaT5PheF3xYYfdtKYSGtQmSymTmeaUmuiPksNMWdXHdTD
ElZ1wwuoU4wSbYz4LJVCnXF10AlNV1UJy16nEZWZzDGfp05Sx+20e4QlNGiFFVCnFiXaGPFZKmXl
JssuOqHpqiph2es0Utlo0xD9WWoH54mTNJ520ZBMW9VSUUydpvQUdXFGq5NQNclNOYpvZpIb2wat
9aiL23Px16nuJ+twyL3JzUFbq904b9xgb8Y+k5nNalrDOj0YWwnTxzGyhOmb1NmDNDMiNxlXIdcl
e2momPjQ1ae0g7I3B/KR3LJQ/YIykqtMhlntZZBWx1V/Wv4WVUkRosqQwanv5MvUzwoJmTSaOO5F
UZr+6QPlR4iH22ql9J/3F9Mozv2aahJLk0lXfkqdsEmB/PSBrkdXq5sMRWGg5OXWZHw9od7KW1ay
6xouqdGtqLFGaVKsIqWiSaOKGhTnlhVXSarVUWqzbFQyBTOqQNWnW7EL9bUZXNyKJDDV1916WE9a
Gj59KNxPTDs3UW+WC/yBwgvisoLoZ4T1g5wsHMTTaebnuMna3nEF+R1RNnNb8SXO8neb4lU+xuY5
RkTxxJZDB1vqzI+wut1ti8Ev7ywXuN5hFk+xsnHmXCgXWy5VHP2aTOivXT8hiiN6jPwsx5rw1/iX
iYD5M3z+5Hz8959+UYOnr9+qwR/On59//+T8FP8oLjLFRXwgPRgayjJioNSJIvk9J7uM3HkaR/Ey
w5p/H0TegCKD/Nzzp0/HP5JfOzs/+/7sxdnbX8dP3r59c/b9z2/5ugjxy5gHEQu41Le44lQc//Iy
8jDYBsQiMvZ5xf2z+JvnczRIgsSn9sbXcMabOQZX9b6m/s3FLWhRTFwAR26LM4O/n775/hVR1TNS
0ydPX5/xx+fPvj//hT+/fnJ+/vbHN69+fv4jl/x0+hNO/PT0/FwRvH7y/Ozlc0Vw/uOTN4Xk9VNR
9tmr16/evBVZXz/7pR6Oz56+evnD2fPxD2+e/HQ6fv3q7OXb0zfKCpdGFmRh65zM0GpSREj33slI
FfbDewWtXJn4yqBRX3LeC/kd9FHVnqi9a2b8X9/Ev837b/prI+JcFlFyGJNVlOv9cX8aXPdvc+q7
5l/10oD0sso/S52z9mE09DMWlkOd8OLOG37J1CdLeefozemLV0/Hz05fnz/av2ozKSn7Knwf4rY1
oK6M5/v9VJ59yi+3o4Su0FWCvhL0lb6CvtIkyEOHn9d3EQ/RDR8iph8K4by8XZuLh+np7pgdt5FA
cUBxQHGWUVyWL/nR/Gk2j9N88J7yCKY7GkPJjqXZW3h0A1joL6ZjNkLEoZSyoWQdkXZbn/9V7rmO
/vE6C1UGBboDugO6s4ru6JVsiZNe0JvGWL9Ok1HC01MxMrvX7xi5nVvuHOM/JNej4N79e58jz3TE
JbdvDQAqvOkeaooxNktAPwF7jPfiyb/pRuPBXIjQR5SRfdAROhj9djj47vfRf7Lbh4e3bh/enj1M
Hv73AH18t/eNsi8g8NZ0WwDKPiByv5LYHvCN62B079Ml/X2E34rIhp6TOx/p3+Gtj8M0ZmH2L5FM
soz+Gd66STN8k+Mi0Q1c9p8eoUOyEYA4bAyipf+QxfvuPEb7p2zHaoTV74dJfonozz5Ah2ucdR89
/vOxSE63EXzrr5MU3SCv/hd0dPMhi/Qzx6VPZIMBNE/QPEHzZFnzlCxlq0T3QpDGiMhI55v1vIM7
pDF4iQZvc2xKmHEkWS6iC5U23Ti5xPyAJkHk4IaqnAaL976NcakrNMjRupBifs3xq2boAP/fR+S8
v0AHL9+gx+gI/SfBrV+Osv+i/2SPbhwSqsVsRNj4IBuh0e3D9Wh2wPkZS3D4xmikCP5J+frW7REa
LmJMQqODm+gxnxouWtk+hgxKI4tNEX/w05++f/Frf/Z4ZdqFVXAgWiDaT060c9wxFExLn+kqOJN2
m+jgaXud6NCXz65j7ROmO4DmgOaspTl54bzsU9Kg6FeyuH7mN/ga1ohMH8NKEXAJcIltXIJNJRY+
lcisKQvyCVMe18+q8zoLgUKAQoBCLKMQjGvF6S/xOhIK17LUr4iI7TYCU9L3MQqjpHMtez/TyySP
YeQFVAdUZy3VeXHo5nLgxUOU5kQMoB5QD6i3C/VRdnTv7t1DAXsRpLiXcf3uzIWBEvAI8IhlPOKQ
i6I5idBnyiBMCngHvAPe7cK7P3eDgTeZybNGhYAiX4nv6dAinYOAvgNwCXCJZVySBv/GKvbl3IMM
s33VMhawD9gH7NuFffXCAjrryBzOs1lHB9YaAPWAevtQv8JWJjBPnynimRTwDngHvNuF90mQx0mm
uCUhIeGWhMYA6gH1gHq7UM+c0RbbL2mI775kMd22TRUzANBFALIAsrCSLDJspI6cAuQh5syHx/Sy
Z1JbRniNBlhhP7MDynDqFk7dAisBK+n7v/1oSO5V8fh1iiQg/h2eU0cCA584CsCyd0T4bhg/kIEH
xLnA35RCHhfPyuUWulAJbuddMVlOU/8P2LUNBAUEZS1Bef5kKf2CsQBbPWHybgMseRiu2PKpbuAo
9cC29HiiH7vdhuESNwB2A3YDdrOY3RbOZcFuJMDZjcoB8gB5gLxdkGc3uB3LmSAZZttKZSxgH7AP
2LcL+3AEFVAPqP/aUK/f2ao1+8VFrrLtl+l6dgLGZkvhfAkQDBCMZQTDsa34FKRB4VOQxfVLJ4kL
l08BlQCV2EYlGNeCRsgjpRAqA7AD2AHsdoGd9w3GceT5oRN5pQ5EIVd7EkrqbouvjD76XFmlnY+t
FladLMux5S5nc1hgBYoDirOW4uD4LaAeUP+1oZ7NpE6DaaxPt1KJMtfKUgADAAMAA9jFAGKwEgaZ
O57FeNgQxWlWHuCUYrVhTjknsASwBLCEXSyxzINFkMsNmCJIeUDGAfAB+AB8u4A/S7F+x/STCfCr
IkoAWpqeV0+L+UdYRQV6AXqxjF4CrHR5bTgLUErhcoA8QB4gbxvkC7wLsHc+nir2aBnWWGvnI5QB
Sq+nVsU+0W3WVx03gZOrwHfAd/byHVs+HSfOzNdXV5lIWWLlaYAEgASABOwiAdgtCmAHsH8lYPfv
H8trFOkz20hBpYB3wDvg3TK8r7X1ERFkqF+r6yJXnSZY5Z46S9DrEguZgoC1FaAloCXLaClaho68
zZk8U0JiUsA74B3wbhfep4tlNs8XE4F5Gaa4L2IB+4B9wL5d2I8z6S+HPFLEUxmAHcAOYLcL7EEq
PdiQR7aHgsgA7AB2ALtdYL/AplE4w+MhCnkRA6gH1APq7UJ9EhJ4yS0DLMR2DfAYQD2gHlBvGeoX
Tj6N03A8x2BJSa0kA1RjGBsYcgAzADMAM9jFDBf+5dyJvIWfFiMBKeGjgSIFMAAwADCAXQwwf5/6
M+mXhYco8kUM2xb01/5PXo9WuQc7hIBTgFMs4xQ4fQ2QB8h/XZC/c/+vEvHkmQGeSgHvgHfAu114
T/1JHMuFBB6imBcxgHpAPaDeLtRf+GvfLWYKSYBPElL5VmeRuCGA0xIgECAQWwkkuH989zs5TqAB
NlBgcoA8QB4gbxnk47GDv2YxHciCfEKQxwHwAfgAfLuAfxGEim8yHmLDBR7T78oicTgwYhYCq4rA
J8AnlvFJPiEOV+VWBRGkjCLjAPgAfAC+XcD3QkduT6TPzLcplQLeAe+Ad7vwnk+mjsfXFp+dvTx7
Oz4/ffr27NXL8/Grly9+ZY0/TcLbfpYcqACoAKjALipYBNLtEHmkeKcyADuAHcBuF9hDP4xTeRck
D1HIixhAPaAeUG8X6vNJEGFLWrT093ki3uMXWYAQgBCAEGwjhPXUcf0WPmBpOB3wDMAGwAbABnax
gbbmp6z4wXofQB4gbyXkSXueytNFDT2AVB46KrLsxZN/e8swQYO5XBlAHxFGINYfOhj9djj47vfR
f7Lbh4e3bh/enj1MHv73ACd4Pw8wYFPf8VDgrVGE3xhlH7Agyx8iL0bv9r5xHWxo+zdI1D7CFoJF
w1tDiuub6OFDGs6xZX+kf4e3Pg49J3fYXxKaZNlNkuibHBeKbuDS//QIHaKPHxH+xNjklj4t4xvf
ncdo/5RY3AOU4S+M4qmsywP6+yjI0OEaF7GPHv/5mGdbB7jUb/11kqIbpA5/QUc32Wv5meOSBw9j
hijIjZNLNMAwImVhynIJPNEwjcmrPhoGUZDzQG2qISbKo+GRlpjLWvIcG/Ict+Q5MeQ5aclz35Dn
viEPjU39BfuSPJMubMqVxuaMQl5YIX+gyUp2KsazdliqqA3Y6pdnq9IS5aPJXvmAyw5z5ZUBa/3y
rFXYoXgy2yrrGdhirKw2YK1forVyS5SP3F5hEAuDWBjEWjWIDTN5Mzd5ZMvYRLa38BABTugvpmNs
jmMMbTRISXxx9r3Y0K6PGsq9slLDVyEWecDmhe+s+jxfs81Jf1KzIA/gsD9QIFCgxRT4RxCtHOlq
nIcoEYoYQD2gHlBvF+pDbFyBesdAIWCdoCIe4A/wB/jbBX+cLPVDJ5H+PkSYOfyQsYB9wD5g3y7s
R3EeTIPiLhEZptgvYgH7gH3Avl3YT5yZP8Z1iaWnL0XC7hRTUgADAAMAA9jFAEGcxGk+9vEAH6Os
8PenSbnbPz3lDvyAyTUGcAUGVANUYxnVLPPZIp4UawsyzI8GiFjAPmAfsG8b9sMgcxvPBvAknAxY
cqACoAKgAruoIEj/kMMM/MjGFkQGYAewA9jtAvsfyyC9kCeBeYjtJuIx6rZ/0ezbsOlf1AW2/H9p
W/6lFfIHviu30w7gYhRbyt37nl5lrmybbb1O4gfqjt5tysJaKRfV7/wgeVmYGoRuAnQTLOsmYITL
a0npM+0iMCngHfAOeLcL70nq+2EiIS+CbMeBiAPgA/AB+HYBP3UiLw7lDeQsRGEvYtiw4X5Pw4bE
ybIcG8xyNh+tcm+EDR0GEMArwCuW8QrGtiAV8kgZhcoA7AB2ALtdYMddhZmPcaR0I1hYdCR4LGAf
sA/Ytwv7YeCmsRt7/tgJZZOvC9mBZT0dUAFQAVCBXVQw94tFA/pMgc+kgHfAO+DdLrw7udxIRB4p
2qkMwA5gB7BbBvbEDwYTJ5NHEgsBA34RD/AH+AP87YJ/5s59b+xiVQeyj6/JKAnoqYAHgAeAB+zi
AdrMB7HWCcDBogtA4gD4AHwAvl3AL+bvSYZFdaafiUtz/Txtt7MadH8An0GQm456OJ5h3HPU6Y0C
bGlL/K8XOulQ3pYoHS8rjhjl8Sly6GJkOnTRf0W2PGgSeurhkE76YBvA+ZSuOuRTuL/3gzVwyASa
FGhSLGxS2Mdqvp+SJWG3U/LkQAVABUAFdlGB7DFW+pWlHmXpWjpOCTacTxd1gfPpX9r5dGmF/GGT
8+nRMnTwP3FGhhNJSBoZ0sF+n/ozUmLqT/hdd7TokXaynZ83V4Wkr6yG9TeiXfN7/XXNtxuArALP
j+HyKmjXoV23t12XR8tCfqyMSADpgHRAul1IV5d+j00rxMfVJeLjvp3SqBOkTujBrCEQDRCNZURD
12TGbEQjnONLCXeMX6Qoxjx98AsdsgCrAKsAq1jGKquZI8+r40d2Xp3IAOwAdgC7XWCfxlE+vr8+
OhGQLwQU+Eo8wB/gD/C3E/73yvC/p8P/HsAf4A/wtxT+90vov6+B/z5gH7AP2LcN+2xqkO7YVucO
iUCZOqTxAH+AP8DfLvgvphMBfPJIIU9lAHYAO4DdLrCznQYYM1N9OwKVKHsRWApgAGAAYAC7GGDl
Z8WqHnlmy3pU2vFIKlkCVNcD1MlBZa6A9SJE0X3us4YtB8BOwE42shPrfWBlRu69u3f0PoqUKv2U
IiWwAbABsIFdbJC4AfGMPeYuJ/g9XJqQ3calpwMqACoAKrCLClhzn5b87KWaj70U/OsB9gH7dmJ/
ufA17JNwgX0aC9gH7AP27cK+OLeUp+WTTViinWwiKYABgAGAAexigGy+zD2sHNn6izBr/WUsYB+w
D9i3DPvYqoL0Dwl9HmTIF3EAfAA+AN8u4LNOvRt6eq+fCJROP40H+AP8Af52wT+LlZn+WM7yxzDD
D3gHvFuI91AePiKPDO0hHDgCsAPYrQM767vPlsrN2KpI6d/zNEACQAJAAnaRQJYEWDHuhWz2RZi1
/TIWsA/YB+xbhv08TsbE0oKo2NOjyhgHaKmAB4AHgAfs4gHWyfd8YkSNN55pCZXxgcgK5ADkAORg
FzkQCEazontAQ7xjwGIA9YB6QL1lqL8MJ/Eik7DnQYZ7EQfAB+AD8O0CfpgkTpoVV53yIAW+jAPg
A/AB+HYBP7vM3HxRNPg0xNt7FgOoB9QD6u1Cfe5kFwtfrv+LIMW9jAPgA/AB+HYBn03ck4vSO8z4
02TKfD/LBrQAtAC0YBct4GrJsT99Zj0BKgW8A94B7/bhPVUBnxaIBz8eAHmAvHWQj8JAAJ48UrhT
GYAdwA5gtwzsy1DeMkCfGdypdC+e/NtbhgkazEv7+NBHhGGGlYQORr8dDr77ffSf7Pbh4a3bh7dn
D5OH/z3ACd7PA4zK1Hc8FHhrFOHXQtkHLMjyh8iL0bu9b1wHW9P+DRK1j7AZYNHw1pCC9yZ6+JCG
c2y+H+nf4a2PQ8/JHfaXhCZZdpMk+ibHhaIbuPQ/PUKH6ONHhL8jtqulT8v4xnfnMdo/JWb1AGX4
M6J4WqrRA/oWKMjQ4RoXtI8e//mYZ14HuOxv/XWSohukJn9BRzfZy/mZ45IHD8ODKMuNk0s0wIgh
ZWF2cgkS0TCNyQs/GgZRkPNAbSqynepoeKQl5rKWPMeGPMcteU4MeU5a8tw35LlvyENjU3/BvifP
pAubcqWxOaOQly1SC9IsBvtl81L2WC+rD9jul2m73BqVALfbTre7CHeKQWH99OrHspN1ze+i6o9F
P7tpApDh1ejtMH/t53aYxMmyHHcelrP5CL/wAS0cN2WdW+43S9zRGIYXaPAUYT0p2oGuKnRVoatq
V1cV85pytYS8UALADmAHsNsG9jx13GKhiQbYvDOTA+QB8gB5uyCf+KmbFLdHsRBr5XkMoB5QD6i3
DPXzy8zzVxL2PMhwL+IA+AB8AL5lwM/kvhLyyACfwZ4SADuA3TqwYwgtC8+xNMCOjjE5QB4gD5C3
DPJwHRRgH7D/VWKfLO9jcxHQF0GKfBlX7CU4JaX2uJkA2/kB0ArQCtCKXbTi5NLhFHmkdEJlAHYA
O4DdLrCv6G5G3oEgz6z3QKWAd8A74N0uvPPtyso9M4pHCYA8QB4gbxvkV1mCh/35VDbzIsyaehkL
2AfsA/btwv57J5Be5egzxTyTdjsARUf+snuwq4NJdC6x+4Es+u+QH0xAq9wbqW8cakGCNTiyBCQH
JGcrya1DXJHYHeeLTHZyNBklPT0VY7J7vTNZRxZz506qkpSbLKep/4cqwtymBRW2VMnOTbRkq8Dz
Y+A74DvgO2v5LnWXiYfxJbhOhinPFbGM4+72wnHbHRvvmoebE7/aZOAtw/ASOAw4DDjMNg7LwmKj
aii2qYaw6ARgB7BbB/Y89EN5ypw8s0PmVAp4B7wD3u3D+xjXXMU8DUvcs1jAPmAfsG8X9nEnfhLH
udK5p0HRwWdxAHwAPgDfMuBjqEnUk2cGeSotZiK3OYTCPiucOQHyAPKwjTz0GX/tunMudJVLz+XK
QB8rHBqtvEYDrMWfgzv37+G3Pv3hjH5SrLjTn75/8Wt/3/XK9HXNnLU5YwFhAWHZT1j+NBguvIwQ
VYx4AJFJDSI836Oe7310kI1w3DsifDeMH8jAg9HsAP1NKeRx8TyM/Pd74YostepCJci4CogJiAmI
CYhJ3xziY6CUOlKYN0aa/Jyzli7l0zIcyOKjGQD96hi/n+nlzMTQCP+ZeJXwgr6M+jx0YawHDAUM
ZRdDEQhGMznIYyE2uuMxgHpAPaDeMtRfZm6+KKZ2aIjP6bAYQD2gHlBvF+rbL7K/3tFGjMgCNB5f
+IvpnWMtAIMNICAgIOsICG44AsgD5L8myKeOF6wHeeoXB+QKCTsip6QABgAGAAawiwFw455kSqOf
ZLLRT8CPKUAeIG8d5DFcUjdO5JKnDFPgF7GAfcA+YN8u7KcTrbM/UTr6E+jkA+oB9TaifvEhFpAn
jxTvVAZgB7AD2O0CO3Gk54fLheL1ShUxB39qGiABIAEgAbtIgBhZEPnjC3/tu4IGdCElglI6oAKg
AqACu6gg8dbyWnP8SGFPZQB2ADuA3S6wE39Rjuv6mVzTUySsxVdSAAMAAwAD2McA/gqDSyUAJpD4
5/EAf4A/wN8u+ONKx9iGiss9RJjN+8nYrXzU4y+bYLNVrs7YprT5KkRwCweQEpCSraTkpk42F4zE
ApSOuBwgD5AHyNsF+Vz1bJsXfm25vLhTbHsvlyPWHQFnl0AjQCOW0YgXh04gnePzECUSEQOoB9QD
6u1C/QU2DV86QOEhinoRA6gH1APq7UL9HOtHYJ4+U8Qzaa/jhfkqhMECEAgQiGUEkjkrueWZPjOf
aVQKeAe8A97twnvoh7j5V/Y5kJDY5EBj9hYeIggK/cV0TA49YIyjQUqdm8kVR2AIYAhgCCsZYk3R
JfdCsBDbCcFjioHF1tfisHHFNjshFsEEExVshgBOAk6ylpNCbFwBqYzsuEgB67sU8VuRieMmAVAJ
UAlQibVUsl4U94jSZ9a1oVLAO+Ad8G4X3nNyeAPXXO6rEmG2tUrG9rpawgYlsGACfAJ8YhmfMGgP
8jhe8POiqpKzYBZRl1FqKuY7SsvXbZJV7NeSWzjkJK064uGdF5XLgHeAd4B3bOQdohs/bSUenkxl
HpGzz9lb2EUOfAN8YyXfYM1icKfSK8azs5dnb8fnp0/fnr16eT5+9fLFr3R7eZGMbTFXsgEtAC0A
LdhFC5Nl9CFIjhs5QaRx2XCGZ+hngsVJ3fmIWDtZqoGOBzAMMIxlDIOHK9LxNn4UQxjoTgDYAey2
gT2J34vZDBexAHO2yeQAeYA8QN4uyPPpSA/njaZx60ymSKdOZcq8wA/AD8APdvHDMlp/aJxeoAko
HbCkDWupYtHVD5NheQm2vC5SJZd48m9yqx8aYIuLSB0ybNfYktEwxxb8aBhEQU4fDSk8J3d4CvJo
fJOuy8AydY8rN7BDBQgUCNRSAl18CJ0WCqVJOImy5EAFQAVABfZRQdzKBHFBBDCmAh4AHrCOB7Jl
lviRJx198CDz9SHitnNvniz78m2OMeUQ04NzeEBJQEm2UhImjHHgLaSjARlmXs5lLGAfsA/Ytwv7
ZKRx0josOSmGJSfAA8ADwAO28YDvpItLNwmapyiKVJQPlExkhcZbhgkazLWN5+gjwkDEakQHo98O
B9/9PvpPdvvw8Nbtw9uzh8nD/x7gBO/nAcZt6jseCrw1Iqs3KPuABVn+EHkxerf3jetge9u/QaL2
ETYULBreGlJ430QPH9IwWf75SP8Ob32kSz3sLwlNsuwmSfRNjgtFN3Dpf3qEDtHHjwh/aWx5S5+W
8Y3vzmO0f0oM7wHK8IdG8VSrzwP6DijI0OEaF7OPHv/5mGddB7jkb/11kqIbpB5/QUc32av5meOS
Bw/Dp2EpK42VpSoWqE01xJx5NDzSEnNZS55jQ57jljwnhjwnLXnuG/Lcr1meG6b+gn1NZaGuEDbl
SmNzRiHXrVEJ0OSa3cr90TYYrawMWOyXZrGFHYqnqq2y9XYbDJXVBKz0S7NSboH0H5N9sqVMOyyU
1QVs9MuzUW6F/MFsp7E9ZhqDlX6ZVhoPxaqv2UZP7LHRE7DRL9NGT4ZiCrBqo8pUgA12qlQHbPVL
s1XVFotnbrOdtvlOgjx0yO5gN079ceKkF0E0G9K1MPY3ieMF8wrl5gvVPZS/8qN8fLyQj+7ciZjD
KBaeBmRDM5qlDg7QKVIcCtI/VNdSF/4lzuUt6F7oC3/tu+TfIHRm/pCfwDS7n4riPJgGNFuCE4+x
NCZ5k9T3w4R4psI/i9+VPcz8jFxOhDJ37ntjN/W9oBw8lmEM6akMOGkQuffu3pGCVGZc0gpl82Xu
xe/p9QTxNGf1y2KWjO67zpIgwi93QR7zOBmTWe4gonnzlGk7uwwnbH94dpkxPedOdrGgL50Hoc//
IdXNU8cl4ZWfZthcyBP7gqsswcXl5N3fO7R+65CqZZwvMiJN3WXiUWfq1G2X5r0La8kL1oMcq48E
JvyBNdeJt2bfYey4LpteIgH6mYfqZfX8wvmRYmDzVTiqbCtXJZWJqtJcgDru0nu3WjdC4+sqGPr1
A4BxAbvYYW0I1oYsWxtyQrldjTzSpR8qA7AD2AHsdoEdN+Jkt9cY42upbAgrZGJTmJKK9SPu9nEa
brsbaHC3qrz1tb/uDd8MC10cYD1gPctYbxLM6LCU8R0PMadpPGbbLfnT1P8D9tEDiQCJWEsi62PS
P5A32rAQu9OGxwDqAfWAertQ72JcOUvpOU0E2TBJxAHwAfgAfMuAT5Uucc9CDPY8BlAPqAfU24V6
bl8C9iLIb1zgcQB8AD4A3y7gk2Ty0msWoKDncoA8QB4gbxfkPX8RrHyyy0409jzMW3sR2/NC43wV
wiIj0AnQiWV0grFZbKQiz2wnFZUC3gHvgHe78E5HBmMXm5pf3K/Axw6KuBhFqGmBEIAQgBDsIgRs
PxPpZY8F2BVLTM6GEX/t81rGEd95BOMJoBOgE8vohGNb2aVNg2KDNosD4APwAfh2Ad8Plwt6YpUB
XwSZTz4RB8AH4APw7QJ+SI6wD1Rf3YqEwl9N0dXXATvgIDcpF9sYlCUOfYyy5cVn1SNV2xyuCEM4
VwGsB6xnLevRG6ij+L12OTUJF/dT09jtWMSd++6FyiSd2FOOs8rvQedx+uBImMYBegN6s5jeJnGc
N3pdpwnYYVSaFEgASABIwC4SmCe+3FNOnynembTn7WUh7C4DBgEGsY1BEmdG3SbyMRILsRESj2Go
x+rFlTj96fsXv/an4ytTyTXzx+bsAeQB5GE/ebzHPYxlMiZmJBhEFZ0TGtHSaPfm0FGJDW6fWU3A
4/OX5vGZWyD9ZxM/z8yVMp25GyrXLyt3npY83Yn5PtVVr/KrJYz0ulZC5gG3Wyih7ogJAMsu8nrb
coa1M2ITqTDEgF4C9BIs6yU4oTeOcKUx/y4Uj8CFTLgGVlIBDwAPAA/YxQPzVSjnKvEjm6okMgA7
gB3AbhfYQ9cfKzcAiCDbbSbiAPgAfAC+XcBPjmUrTx7ZUsIxtPIAdgC7dWAPXYfOuhbNPA/zdl7E
9rwXQUxJwnQhcApwimWcspY3IHKP+CLMfOLLWMA+YB+wbxf2J06a0oto+Y06PMh2MYs4AD4AH4Bv
F/CjMBgHkdxFJIIU+DIOgA/AB+DbBfzQzf2FHxYTCCzI5w94HAAfgA/Atwv4cTIOY89fjJMTAX5V
RAlASwMkACQAJGAXCYSur+wQkLsDAOwAdgC7bWBPjsNBkiubA0hI7A+gMYB6QD2g3i7UF314bEnV
nj4Rlvr6NB1QAVABUIGlVODk80Wxaags1ulApAVCAEIAQrCLEPBQf+AkfqDMAbCwmAjgsYB9wD5g
3y7skzG/r08H+Op8gA8TAgB8AL59wA/uH9+VS34sQEHP5QB5gDxA3i7IT7AR5alTLPYVAr61V8YD
/AH+AH+74E/O+9ObalVvAEwg/QHw+G4O2IpDQMXmYH2zUHk5oTqfqJFOry7XitOJ27hd45WHO2qA
GYEZbWVGmsxVpkEKgSvu9+bxAH+AP8DfLvjTfU+xp22Jij1lTxSJA+AD8AH4dgE/wjDT/KEWAnbk
sYgH+AP8Af52wT+QGyEDvvsxgC2PgHRAunVIX+aBbOPpM0U7kwLeAe+Ad7vwvlJONK7kkcYVnGkE
vAPeLcR7kP4hu/L4kfXliQzADmAHsNsF9tkSG8n4vbO4GB/zq9ef/3x6/pa/zPjF6d9PX5w/OiZs
UKRlpKDn7bbNQb8Sqbg2QXGsXHhFLLwlMQ8KyvEJdYOFOrXIxyGieyIvdetjE4R6p9s22yDCPE0r
N8/15kiaqR7cSANZA1lbRtZh4VNOuJMDT3KAdEC6fUjHXQSJdfLM0E6lgHfAO+DdLrwrQ6k7DcOw
Oy3DsDvADsAOwA4Ws8NJAzuctLDDyW5uucedEphtANYB1rGNdZiZimGICDJWEXEAfAA+AN8u4DMb
Ua62LwRsJ3cRD/AH+AP87YJ/6IfjxJnhKskZyELC5iGVFMAAwADAAJYxgBMU11+TZ4Z6Ku22zUOO
D0QuYAlgCWAJq1giT50kEzTBApQnuBwgD5AHyNsF+STEFSvushZB5txBxO1g0yVdYui6vxT/dTH+
nSXZQcrMZMjczizEv2MXo8UPoilxoxW+d7AmAm/BdpiS/Z0jpUTy4yPTbs2eagdrJ0CUQJSWEaWz
IMaB4bbiR+eenb08ezs+P3369uzVy/Pxq5cvfiUMqqajLKplBGYAZgBmsIsZyNxpNnfS0vSqEMn5
VZkGSABIAEjALhKYfAhCZ9bcNRBpmDdxkQHYANgA2MAuNvhjGaQXciaVhyjsRQygHlAPqLcL9cTI
gsgfX/hr3y1WW1UhX3bV0gEVABUAFdhFBWkuCYA8UthTGYAdwA5gtwvsiSvvBiaPbO3UhRuBAewA
duvA7rhJMA5Ddyon+xUJW/BTUjAGwKrGFTr96fsXv/an7yvTyjVzyeZMAkQCRGI/kbgL30nJoQvp
ileRnBMiUVMAkQCRAJEAkZiIJE4udR6RAkYjRTwMSAD+AH+74I9HGrjKg6kTHh3OC2+SqpA7ltTS
ARUAFQAV2EUFXhiMM9eJGnchyUSUFYosQAhACEAIdhFC5qzkqIA+U8wzKeAd8A54twvvrI8fzMb3
TvSRABMp4wCeBkgASABIwC4S8GLioWVMPoTXPBJQE7LRgJZ1qytxsrnjxe/VS3GAaoBqgGqsohpc
ydXMkSMMFmJjDB4DqAfUA+rtQr0YQQzIiWbfK480hFgbbci0QAhACEAIdhECVnri5MX2Axpy2d4D
FgOoB9QD6u1C/SqInaS4TUIEKe5lXM/X04ThiE0sgI81YBRgFMsYRbh2lP0IEhL9CBoDqAfUA+rt
Qj1bdBCo5yFlOQJQD6gH1NuG+lWQBl7gRMXwgYf5+EHEbrUIOXcSWIEEGgEasZZGkvll5vkr6X+B
B5kPBhEHwAfgA/DtAv5qoU0+LpS5Rx4DqAfUA+rtQn2ycPJpnIbjOQZLSmolW/5qDOsEGHL0vyiB
BxqwIgF8A3xjGd9gXAuCIY+UUagMwA5gB7DbBfZVmElHjvSZDSeoFPAOeAe824V3N1mO2SWRfMOB
CLMtBzIWsA/YB+zbhf3ZEhvJ+L2zuBgfL/yVz+cRnj3/+fT8LX+j8YvTv5++OH90TMihyMDowVAA
8ATwBPCEXTyxUhcZiiUGWGAAvAPeLcQ77vVPU/8PZUhAg2JEwOIA+AB8AL5dwFf683faBgR3WgYE
d2BAADwBPGExTxy3TReE2AYDlRiOgQ6ADoAObKODVZIX0wO5mB3Itzy3wNwmwNEFoA6gDmupQxkw
nLSNOE5aRhwnMOIAngCesJInmI2Mla2IioQSgZoCGAAYABjALgZYJeGyGGXgZz7MIFLAO+Ad8G4X
3nl77hdzC4pEbfH9rWcaslWoTjP0ezAK/ze+dzJisxkHcIUtXGELhAeEZyA8jKn0UnAdC5wTmuPy
vYWHSH8h9BfTMSMVHEpJioK7ZGLJYS98ZwUUBhQGFAYU9skpDJgDmAOYA5jDsA6UpOPsfZC78vZu
RUI5RE3RrS9Ep4JNZ1RM29RMC0nanLI+3AQmAyYDJgMmqzLZhb/23XHqY7gIKlNFlMu0NP2O1YQf
nm3mw1bhWp0P60S2YYj/5KmTZCSAgRZE/pjWE4cTN8B/HTcJxmHoTmdDcSfSYOqER4fzYelG1uqN
SfISFekPufBsaHRvpBxdLs4s8FJG1QGz1ryYvs+9XsfSB3vx5N/eMkzQYI6cBaETzM7kRmr0EWGy
xWhBB6PfDgff/T76T3b78PDW7cPbs4fJw/8e4ATv5wHm5tR3PBR4axRh+0TZByzI8odYP+jd3jeu
g2ll/waJ2keYD7BoeGtIKfwmeviQhnPMYx/p3+Gtj0PPyR32l4QmWXaTJPomx4WiG7j0Pz1Ch+jj
R6zCCBPM0qdlfOO78xjtnxJ+eYAyjGcUT/UKPaAvgYIMHa5xOfvo8Z+Ped51gIv+1l8nKbpBKvIX
dHSTvZufOS558DBNElW5cXKJBpg5SVm4iXIJI6NhGpP3fTQMoiDngdpUQ9wwHg2PtMRc1pLn2JDn
uCXPiSHPSUue+4Y89w15aCw2TvY5eSZd2JQrjc0Zhbxkj2qIZohV2518CEJnZondysqAzX5pNlvY
oXiq2qoXBuPMJf60bTDWojZgrV+atSqWKB8N9qpdRG2FzWo1Arv94uxWt0gtyO0XduLAjAbMaFg1
o8FmRu+0nQWunPa70/temvkqHGWrELwMA8sAy1jGMhibnpgwpc+USZgU8A54B7zbhXcf9xcwvORu
ER6kqJdxO+g/rMI19B+AT4BPLOMTnCwVZEKfKZMwKeAd8A54B7wD3gHvgPcvE++p7yzC2JMDBhmm
uC9iAfuAfcC+Xdhn6wknbb6BKisQJ0AHQAdAB7bRAbORbBXqngGIQHEMQOMB/gB/gL9d8F+FblZc
UYif+RWFRAp4B7wD3u3Cu9LQyyYeGncAO4DdQrCvwnXRtq9F074GsAPYAezWgT0Jl2M3Tv1j1bMn
l0j/niIFMAAwADCAXQyA+/GeP1nOlA4+C4tePo8F7AP2Aft2YX8VuhNlHm8i5/EmgHfAO+DdOryr
Y/ticK+M7sGhGjhUA9oA2tjcqSz0FADyAHlbIN9+1w/0FKCnALQBtNH/DRrsyw2VK8sLdybKtuK+
nbZmc8eL3x90e8fEmeGfJA/HIfs7IF6p6YMvn5LYK/m/Lrm+Lnm9Jn5X/XAsCycB4n+VhdgLjnT/
2kqwXzepYdhRFcxBRHFinJ8AU/eAIvmXTybzOSbeoOzmzhTpqqZTLfhLF6dY+HY2tvStrYLxAfPu
3poekL+a7uf4p8g/VN/B/eO7J6xufuoyswxi8iclrnjDPC2+E8uRhJiYfCL9YxmkF6T+aU78B2cO
dUWKSWw1c4gKgtjBtE2f0sALqCe91ULIwiygSmMh+sP8U+MvolowrurOLHje+ePz154EeUy9Jxeu
jrm5ev7CuWT+1tx8ofpA5h7YEub60r9/fEj+WdNWCz9NF8tsni8mdT6Sgzv3/8q/1Hf064z5uzAN
BnESp/lYwRb7coGbxi4207ETelqYfOqFKhGOocMkcdKMBKOQlBwtQ0f6hSbvkyx1j84ZsQLcH1om
lHqWOeYeUuEsTNjfSRwTFWUp1RTpeTGWusyYioglMY/Urq94psbdqZS4DMSP5HsUVSu7rHZTJyOu
oHP+Q9y017T3xp1Zq6aEa6AGcY+JqFKjS932Qi0U477PNFj4qoxfu6RaSsUXb8ndKXIXvpMKeyAV
Fc8lP5NG333U/u/2Y/9Ntp+kPu53XOC32BhV5GuoGtm4AH8aXCU/6xVcJaeX4q+VZlfJus7Crep6
lXqml0keq6T4ALV+yAFW6nV+zK/2YyBqvYSQOIpJOF1GnOxISDQe7LsNQkzx9xI/QYNBtpxgdsRD
z0dHhzhIaWMwcTL/0eF6iv93/9g7vH/I/keSkyHZo8Pb5HnuOwl/JEybDGjLRELMhygZCs8iMqbF
ZR2LEgiflWKwNHT+Haf818m3wNnJ6T38plFFflemjzMpPJaJFWFRsqymIUM1Dud7S/Q2XHh4BPSy
ZNFUveQWgGzgLcPwcnMbzS7DSbwosg+6lzDEf4bkPaqfZ3iI/vxnhK70iV34xJ/zJ3a1T/wAw5i8
YXhB37En2+nn9R5vXkw6PMcVikLixbqfqnzEIOhaUh7jzyQ+11VeP6Ovf+WbVa6ir6vYUgbs3ws1
XOP36qtdOIJ24av7+K728XfRYhz19HqbU+5R3y3G0bW2GEfX3WIcXckIj6DF6Ic03u2h0v+u8Qtu
QiM8314wxWiYOovMf4jyuR+hNNzEUHkxDxG97ePg9IczlC0TMmmIvCAjk5DewUOEf8cUs7fZb8m6
0stPbpmnl94ikkr/NvK7XG+/foDzZ8PDvc25i+fETHUNPMV/DPPUtbCU+DllsrEPz75wKT3sCoBd
AbArwLQrQKMdtjfgSgR5xQbgetZVemn4tLe+WnWPrtzeHV1ne3d0ve3dEbR30N5Bewft3fW2d0dX
b++OrtreHX2R7d3RxsNnmu8KQ1j2e3wMO2RL4OEFrtud441/fpMM6HB9xCZa3u39i7bR6ea/9xHN
yd2iuH0/EteR+uggG/3z3be//RP9fuvdzeGt0eH63dHo4F/MCk76soLZhyAhuh58h/62Ub0fbzSb
MfswjPz3e+HqCrk2zLL3Gxp4nfJ4QZZjTsPNw2JBLQb9Ti5c5RJSyiA8/Ovdu5g7r1beniwqPLx3
ctK1nKIuV/tZLZ5oZBHRT5yhUsSWxe+q5J2US0rd6nN0pwZzvUh2mYjMEP5GdvtsOCWIBg67qniZ
paNFMLl3QnZeHaDf+Tzju71vrmb+Wnl94kArmF41vB0oyOtt9xI6PMRbEYvLpqgc19dvXcvP7P5H
5E8w+yWWSA2cGiG3Tc0aP8XXFm9E/zN/bdyxIRXY37TsffQI7esCtbLFfD2PpkMzFEeLS5Q4aR5g
0SUid2yjb3Gq8d9PXz579QZFuOnBw7ObB/Kqbvaa04C19ne2au0PWCHHfRRydOVCWAEP0K1bt9Bv
7+N04f2O6DXm6Hjv/wMv7cKBg9oIAA==
--001a113cf1269938ad050a98f62f
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--001a113cf1269938ad050a98f62f--


From xen-devel-bounces@lists.xen.org Fri Dec 19 22:10:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 22:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y25jt-0007bd-VI; Fri, 19 Dec 2014 22:09:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <syllopsium@syllopsium.co.uk>) id 1Y25jr-0007bY-TP
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 22:09:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C4/A7-09842-F12A4945; Fri, 19 Dec 2014 22:09:35 +0000
X-Env-Sender: syllopsium@syllopsium.co.uk
X-Msg-Ref: server-4.tower-21.messagelabs.com!1419026972!16828262!1
X-Originating-IP: [209.85.218.46]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11236 invoked from network); 19 Dec 2014 22:09:33 -0000
Received: from mail-oi0-f46.google.com (HELO mail-oi0-f46.google.com)
	(209.85.218.46)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Dec 2014 22:09:33 -0000
Received: by mail-oi0-f46.google.com with SMTP id h136so3485865oig.5
	for <xen-devel@lists.xen.org>; Fri, 19 Dec 2014 14:09:32 -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=dR6Wr2mXTaXdVwTNDqHML6AZkoiejhpEykLn9s2yydg=;
	b=cPWlMbDML+wxlCzAyqBYHxfJu1NxOgAoTajQgoPRPSEPQ8e9oGgpbLXxKBrVqUPwPF
	cup0mpr/i1u6SIgWtd/VWAopB3oVQBhfuQgbJjym5e6Uph5QXYWeLUaYdFhNQKVDbPbi
	sw7JrHRcGl3p0N9HoCaqi+YInRKfkWBhjYNoPf0DnxfU8B07Cm9MVPe/aYodxceYE6oM
	8wP5H7s9TCu5X3ZTf/3PppRPSs2Br746BpyV2A8sPx5ShJn8igYdkgalu4wJw+udIB8n
	0Ogo2VMi+NB3jSRIJ8E/0UMoq4dT+xQfX5ec+aQa/r30LbMd76VLfNTdhS5bkWY2OweN
	weKA==
X-Gm-Message-State: ALoCoQls55pO+sHAzLai1lAZxlbV4Tb8bqyPZ5qtBDwbxeGC8MsCvKoNO2IS0MQ2OgMHKOyvG3z/
MIME-Version: 1.0
X-Received: by 10.202.55.215 with SMTP id e206mr5882888oia.120.1419026972082; 
	Fri, 19 Dec 2014 14:09:32 -0800 (PST)
Received: by 10.60.158.169 with HTTP; Fri, 19 Dec 2014 14:09:31 -0800 (PST)
X-Originating-IP: [87.81.134.115]
In-Reply-To: <1418983542.20028.5.camel@citrix.com>
References: <CAN4Onoho_BKS48ECqXf=wF=MMLCah80yGZyEmm1O7G6fDEQtHA@mail.gmail.com>
	<1418983542.20028.5.camel@citrix.com>
Date: Fri, 19 Dec 2014 22:09:31 +0000
Message-ID: <CAN4Onog81C3QPssC7Cm3UDqX98fgcQC8XuqO09WrKrP2GH6oQg@mail.gmail.com>
From: Peter Kay <syllopsium@syllopsium.co.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Content-Type: multipart/mixed; boundary=001a113cf1269938ad050a98f62f
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Parallel make 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--001a113cf1269938ad050a98f62f
Content-Type: multipart/alternative; boundary=001a113cf1269938a9050a98f62d

--001a113cf1269938a9050a98f62d
Content-Type: text/plain; charset=UTF-8

Thanks, see attached :

This is on Salix 14.1 running the 3.17.4 kernel. That's not particularly
relevant though, as I had exactly the same error on Debian using other
kernel versions.

On 19 December 2014 at 10:05, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Thu, 2014-12-18 at 22:36 +0000, Peter Kay wrote:
> > Is parallel make supported for xen? If I compile 4.5 rc4 (although the
> > error exists with many other prior releases too) with make -j4 world
> > it fails part way through with an error 2. This does not occur with a
> > straight 'make world'
>
> It is expected to work in general, I build with -j12 all the time. There
> are some subdirs which enforce serialised build for various reasons,
> perhaps there is one more we've not spotted or perhaps there is just a
> bug in the Makefiles somewhere.
>
> Please post your build logs showing the error.
>
> Ian.
>
>
>

--001a113cf1269938a9050a98f62d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thanks, see attached :<br><br></div>This is on Salix =
14.1 running the 3.17.4 kernel. That&#39;s not particularly relevant though=
, as I had exactly the same error on Debian using other kernel versions.<br=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 19 Dece=
mber 2014 at 10:05, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ia=
n.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</s=
pan> 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"><div cl=
ass=3D"h5">On Thu, 2014-12-18 at 22:36 +0000, Peter Kay wrote:<br>
&gt; Is parallel make supported for xen? If I compile 4.5 rc4 (although the=
<br>
&gt; error exists with many other prior releases too) with make -j4 world<b=
r>
&gt; it fails part way through with an error 2. This does not occur with a<=
br>
&gt; straight &#39;make world&#39;<br>
<br>
</div></div>It is expected to work in general, I build with -j12 all the ti=
me. There<br>
are some subdirs which enforce serialised build for various reasons,<br>
perhaps there is one more we&#39;ve not spotted or perhaps there is just a<=
br>
bug in the Makefiles somewhere.<br>
<br>
Please post your build logs showing the error.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--001a113cf1269938a9050a98f62d--
--001a113cf1269938ad050a98f62f
Content-Type: application/x-gzip; name="build.log.gz"
Content-Disposition: attachment; filename="build.log.gz"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i3w3yxl50

H4sICMmglFQAA2J1aWxkLmxvZwDsPWtz5DZyn8+/gtly1SaTIkcarXXrbPmDz7flc+pip2xXKqm1
a4whMSQskuASnNFIcfa3pxsvApwZSSuCulHV6oMG3QC6gX7gDbAiVzRKS0rqzyoIvjv/9d+it3VH
W1bnUcZamna8vYl+mxe8ovOGQsz8r/y6LjnJxHxH6/hV8kVyFrfpq5eSQhR/EwHapbl4PE2EDN11
9OOmpCKprqKlQ/0iDPVvoo7zUrjlfjWO8lwSfPlZW2HZZwmPxE21AlRP/e+UbMcRN6J5aDYrQqgw
q9Nyk9GQVdYkVaXbdZTyqiFdVFCS0VYkaXHliGP2AeJbGiWzJAsiE8t9jFSgyBWvQwpFURxdKhRk
X6rHEiq2VQAqJVvRch2AUJ7yrSvrL4LIeq7K9/JOY/tinLENOIUsPQrlzrKPUNs66yaQN1jVUwhb
CSZkwZVfPUXZpYgC0jMlD+w2YB9P5Db3chrZG4RodrOWbaHjCtkbaJIju4OCtAFa37TZrFv6PgCl
JmUhqBAhuqLlm7wI2Uhpkc91de+37xDMnLqM0/W2y4bCGOEVe7IYUzSSNmwKRYE1TdoIeXxG6YZl
lE9iquDgTyICxWiUEVR79hlCAmhb4wrWkRUAbtkuw/v2HNxzXDF3ry+nLiOo6G5jugzkT0OeAeUS
yq6kyz6Ja2lOo3yrdWdr7/48jf3OQdR3S+TP4e3jQXxDOQM2JnPVHjy5I4xuIDYdK1nH9puyAAX1
BDPKUhvKpm7GnsxcvHasvWdqO4HJyIpO1jDfV6FQg6vhADisN6PBPWHjYZ3wSYzBqWFwsg+sSSAr
UMO4Caf5QebTO1GFnOMDuXHlWZdEXIUc/UCJ5pKo0YVeK1fIpLBwCrBYdnwpOuTlxLAarIaUS8Gy
g/Fku2xoW90Vx4RgvBYQgaYwejlTBB3cWxHNxbRO/nBGI31wT+mTOOBoY0/bm6bjQXdcJMVpVxc1
i3Gj+1T29SGrbmiayhNRxXy9FrQTiQBRlJmIVpx3c5SKCnxQv1I+MlRd0XJ9sQi5NDRihTLELhOt
ScNSTUkJ5qF0EkSJm0ok787iL3+dKRFJO/p4QgldM0MHglIJ+IvkNAL+y1DGBA7LFbq6amnJU81R
lkAikp9coKyvXHDFQm4Vju6CjGXOtTYmbfr2mY2RRDWNIMC4R5YrLWgadJxgyzZ++W1/cyFc6exm
2qOHDr5tjx07uCqdK61MOzfx9PSwjY2Ro5aDVRxlvF3bBlzReIREQrUx432FNy1fs5JO4izVWF8p
SMavJ3EX8OO5uO/sQCjDsMxG7fhUu+kaDvCIJ/The7kFs0Bj3k/UJlagZ2mzT+P+fe1GbncsL19N
0SA64hg1HCRNwH3o/UFQ2FYF/PTpWpV7mYUSln+IKIiwlN0FPp0Y1JfB8J5GlQ/hFUqTplMOJyml
yAedaAslsI9gGUpuxlwnXNoZLqHYRUxRSYYPXhij9cekTfLbj0qOCwUfkV6uYRhh7dcsns3dpaJC
p0hWpK5pq+R6MUqu2t4XAYgcPK4/5pqBc5p+1IUC71R+8BP2kvreGXtIYxli+jXol+V1qKmEx3Tu
MDDugYcULhZJIQOXrzCATqpQyl2tOclpI23Nb5JaP25uUu3No9uLO0o8tnkYaGCsV0xkdiVb7dKw
RidJWpObJW1TSTa0Tru2TIgLCO5DCRDbxyRnGpdvqOgsBQVZEgZ0aLgoIKKpLrnIaLN8+/0PP/3P
T5gfWjq5qvrLZ5Hzt4SOqsANKB+9S5fYLIL96dASDFdDzaYBESgg4xVhtQrTbZcWOpzXXUdWKlwx
kaqQ2luTwaa4gfJtNdCyLek0N0GzteYkwC0yN7xQAAG9pZdfXCio7dRvt9rojE1li7oseNeUm1wn
pWJTaT5dRXUyCEDhad31YENy3LCzMElTKoSFRdGqcJGSslxaxtqvMAnYk8Jd0R2V9e9KK1MIljzP
absUXca4LRzftKkuXiM0CygKtbIsWb3ZOUGl5V5NCcdlfU9nBmHUpmGjOQ0a5WnQ6E+DSoUa0FrU
kFWkgY0uNazUaQqhNeqBCwv3etUIVK0OKu0aJpVbr17HJptWs8kqNW2q0ivbwRh9Oyij8h4lta5B
R/FGLAPda7RWv4SsBRjIN4K+9NoOTG1Fz9dag4a1QbiQsQnEDbw6H7jaRjS0zlxXRu6d9XyNE2Sr
ETAcAh5UFsNYXdVAHtzHTri+BxXLNrIHsRmlbQ8DWVavueXhtDUI4ZZND0EGm98kuGUVFGCIzqgp
zLK8feUkZ/UwqRqhu+6EWLeNY1kPwiwTVM1Ki8r3zdyI0nOvXpo+WglU43yZWv91xIo4X7IOxlTN
QVn59lz91qGXsoNwBO0m82XtxAzF7WbqJe4VwRW6EzFop4zojav50j9g1od6PH4EDdkDjXr0EOBE
xzwQKU0v7LDHUO3nm0SNUpVeZjDQmFnWGXgJX9F+8mQjop1YtqQG3WNIdGhEGEpbIorKzMYA0WWr
ZbapGps1TnndtbyM8PRNbLHKrwZs+kx0x0QnergEsIdaSjIHqhxmRcWdqOuWdQ7V0qF4TaD/NHPE
EBPvobxP1MxwZBDWxJCiu5wBaRqqpnWNVE2M/blUYdyQVtAo71qS0i2j1zooOiLVW/L0CteiMSwV
lPFcqhMv2SKlDMqTyqQxtDJpt7NBNEQJlPwa2MlccbWujTHGRYPFNaPqQOpWdT9RVdMdqZrBBZLx
6jZUnbno97wrkF7HoxWNMl7TCAZX0W+S78skkKwHjE9P3npUG1bcmmiARfMD9A4/FzBmQddjYm+w
qsbhhUbjDDYRxYvRS7mHmYVZfZlc7n/HUdU0Ypekxx+8Pk40sHRHNw0+udNrGSBS9nPBx3aSqj+2
E1wP8FrV+yrGJrDExXF2S9Vgexd46KOLc6paSPHmQODuUBN1B0A4PK15Bx1vKdQyzQTjTMP2RGW9
Zm11TULPZgzVYK1yTxD8Iorpm4itI9AchLNIULJiXMRAeZ68ibqC1jCR/ZOpohOtavkGYtcsVGNu
ijZ3+MDMpwLDCtW0389idEM/ocaMHlpeYeHDdqVWNJq6Lv+Y+6t3EcZ6XCxWzDuC8Do4s7nkoevy
5aTk5Q5nmg81c342Ede5ZuZs8XBTALrr3Ns6qhBhPOdIGayAJ+Di1VBiMA5X+bukcGr5eir21hOC
Ure7sWr0IocyxrfxJkC01MBsaXddIyJeX+K5gKTbdVGZOYBJYTJJpAUgVbQRJKcRwmJTCZP+L9/9
8FO84mkh4pnBBTl3cme78hza2W1OJmxnNXVrBUYv0XZF1fXuOIf+10L6Ct5M3wl6femtMXe0ahJy
fZXMTLEhccvyaKnB5cwG44yuNjkg5CEcmxxNzgJoPL8111n0B3T7WfRCxMlsHscvfpPJIDEx7wL+
17dfSxMq86aMwSVhLDGzF1kC2o+V17OxHwoDqBY3MSayIEvfNpCs2VH5L8mhZ519iJYS6EiLR5Wc
cGjlOEV5NuoptpXaAppIPZZ++KHUgPShh50CjqUsN+dqeNvvrETGvuwNO4gUIuuWM2izMgjMkhSN
ETJUJfwv6C6qrpYYI6MhHRFl6D58WOrAnbijAtUOQv8mElanNpDU9Fqqxe4u9RZnQ0lXNf7V6oBe
ObTA0F45elI/oHd6s/qU14KXgSf1mujdq1g6UeaEI+cKa1oyWqsrwRmh+D4jBANpxZbvRJUCkQHf
+7Vrec7CvVm6shBEw4hHaUMGQNhupF1qrPAVCP0bTCGmcKerD7mfGX4fP8hrqQfomSOX+wUf3/9r
ovOevrEq0aYOFrx+gBA8OUvODmH3cRJjQA+yR4bM9ADG4hnURszFNcvnzU1XQGuxdEgdTGDim5th
PG3L+fHcbiy0ZHczT+/KnYbsEw9pJUyfOLmhYvPCm2mMVNF+2R9LQU7qJ+yYZMhwCtmHOctiyZ1e
Q6tOeAY+zCJp7g3qA58a0UxOVK6r8qojzSKsYDXRYO2CR+/IVZXxDYPmMrgwMdr9D5Md7f+Ty7gM
9+iEL4jSXKHXy9rmeKK+AhFY7GWIl+yfSOTbIptG5EA42ErMHk09ogy7AuNwwYHLoJHGg6wHTAcS
Qnp1OwcDMH48x3FloPWVvTKFWVfxBOr6ha4V4GM8AKACTUY6GthHevM4fR858JGDcH5in2fUapDy
17qAfNHPX3/7UwQpMyauFlGn9aIRsVqYsCCenCaVBTO2XkcRnnpVuViVL96n/DrCf3EKaTsqw4uW
XAdWsPfs5DNQsjlHPomSNXEz8gdcnHZlzBq8CGYgPMHsgKQExamrOQa1bqkLKgU6iIyCAfAbByMa
cl27RLuOpIWXZYDgDXUzpCUXLouGbDx4Uw8xFfmdty4FvMraw06MrD42pr4EXEwvBBer5OBijChc
nJWGi9QC8Xhomfh593FKMh5XJRwXpaXhoqyIXKSWkkdNCQpRshHQeOxZlB2h9IgP2u5GGdYg7lBa
swz6IbC/WxMP7O+DTthZtrW9FTaRgaZOfjNzenMn/CyQkBewgl9f1nSDtbBDklMdBu/5DM6Da6zy
KA0s8RyvueZqcHm7WXkYtDNnRbrnoH2qh9Cj9jFm+DfauQ7ULYx7PZG+N+vAoyZHIEC71/SNWAJ8
WInBVSE5Pys9tJQJ2k6oDMPA04hBPpFa+jI8K90wwb+8vDybTDWavqcZjXsixdgSPCu9rENvVTkS
WffbVFIfa9I9kS7W4bZinkgPtxM2W7d9iwXBZXn7ux4IICQKsvjisofXJe1gjN5aTS1v+7YNlHj7
ZC3d7bNr5HYTKnE36HZ2T6aH3bPTA911i7WIB2unQdXRszBa6TFPpBe3CBOpJ8RrET7Fk5xsbtOC
BD77Y6g6p3/2XozA2b5MFNc8o+dOeBFyo7Qvyolp4MBtsfe02uD7FnHXkox1jNekPHZ17Fha7x7Z
V199Ff3nN9/535QlDVnh149uooKIaEWBLq3VZxYgfSgTOFY+YxIpr9csT4CbCRYRb2J28fpShlIT
zIGGGxGTttIpVEgnkIBzhVIvshMlqXqVYWkUwKpcAmrhPRUpb2iCFtnwTB6rnc8+mBNGJWsbeShQ
hSRVsskYl0gVcj7i841UpukIHy3/8T3DUVuS5bMnJT+oS06AUxLmm86BWrr2392RUfo9w5LnHoyJ
37ebOuWVi8en088DNdH3VQqfjMgiVkdY+jir3kQZntoyqvlc74NGf/wBHRbrovPojVM/fHXiUSo7
RTVrCXiPxOL66gflAlkV1dfrhkorXjcbedi1v2IMLqDWp9O8PwY7nfpsYcO0+cfbnmfUB9zX7g/b
+tDtttNWz5KOVfjCTtX4zRzeVgz7xqpXfcvjUEGmb8DkO5lRQcuSS2qRPAcaS03hP3B1fEUK2zcV
b/n2oXjdtFS3h1VFmigCBrHDNbRrHZBbu9bakrtP8fuMpZ2PwUfgBihWDxDqe3Y+Tr6p5WF+F7w2
toGVfF81Maik2XTxlgkG1RrGsvreSGRti2zjcLWc1Jlw8aqQx2nq+OMl4k0nDuFTDs16x2rqInW6
WIDBk5LdEmxq3ASMb12QMO6C7ZqtOe7cu0jsP7qupAMcGFqMb3m66GLFOjQpBwU2FcvX9Dzk6rb1
CepXLBxMtSmhq3aLXnfni9cuBrjxxsv0PqPbOC/5CprXpu0jtS3wCqnQdo2vh7hiq/BMqEEZ99U2
zLgCBMiFdkuRVkvwwIa2vinjLaDeE3FTD9JjcVwc56DQNqOti6XnZ2dnHoJC2c8HuDpj+Oi3EC52
naUeeL1M17mLKbI4p9zFsFevztY7D/N68frsfHV+7iEz6oENTztSLi4WLrami0HR623l5WvSmnYe
YtuQmnmllkqreC0t18WDuhyw7VIfLF+fX3zpokRDmjZuipWL7Krm/OwLD9OkbOEXe8ta8JT4y+YA
coXHAXh9KKa8OoDVV2sOxAxEobFtnR/AilSwQ2jp2F5EtQO6FxK1P5MJNoGRrgBtkfxSaEbX0MHX
WZREv/xzFNekotHLWVK+4+TXl1HMe5TgPpyVpY+oBgne8Qxp/PIvUdzdNDSCqTq+XRtBKf73/6J/
dUsDMyg7e9IBGDniO8BSWmuBTcDuJlbeGm1Fqg8uybSrlmU5NZESlZMHzL8UAxljT0/BlF7gABV/
3RLitC6tsv7tSXmHCL9+R1tob7JYwq2IMxlI1M/sYYmLmafuuOAC30rwoNiOTvYUuIdw0zqdGZD0
QTcdwTYP1CRTOcAwjeyXTBoNOGmGNZVPIyPNYxF35NVSOpDZxri5nb7DrcwR/B05TRWP4I/k9AV9
NCYejjIxuiItjPTKJPWhw/pJPeCwflIPuF8/6dGIB+hnP7ONGdQWPEyWy6a02JzMBzH+fFvwdVdV
mwgaNvnWh7L2lptpuDPL+TzTM5vjU/M30Zrh1EZp4PNsPvSgvan7FFMQt2Ivgd23b78HdoVnLhbt
WlHMy8xZjxpaVHEtSc9nBd25t1b19FzciI5Wss/QsSbf8bZCcYzybCW6zSreVWCdU8wufJFMIfQ9
A7pj/ifXNXChryXX8B87J/XwRrCPaNxXtMBrFqe4TuFcnGuqLPi1VKDp7BRoJurHuzMX4jqa5HWi
4sWrlGXwnZhd6QhXviChX73RmzA7NalkWakKEONL9WakhjTls9sZr84GV7iX8hUK+dUa/UmRmXx8
AV+fgG4COgd13rXPofkk6iUHC0UqA78Kt+ezK09Wy2iE8tMT4f1Ikh18F0yu49pbBj3zgC6l2Z6o
vOXbTDmkx55xF1boPm176zdfwiwWXCvfmQBG2+VeO2za5ZBEjo6G46A3QYc0fjHnu35hEA3DFhcC
+tM+7oNlozvQA9ynqVe+s/Wykvdfggldl3wXqv8fWtKpO9NVFngc4FI2jgRBUB/8x5GR2dMFMLTM
JcsTlbicpYYVtSQZzAkdavJKfaoX44IePlJzdUPbkQ7GuqzG30T1WRl1eB+niCGW1b8Huql5mGGY
E1OH5Da+FZzWgGDiKwrSDkZIwWyoJ+9qVT8FgSn9pxpCqcBl+wy0gLuTMCUtCW6ETaAGl763Tbn0
OLsft12V/HrNRAEzGBvEmX6fIdQN5kNFfA46gyTqE3aTaMxS9/zGYTqF37hcw6tg9BDCJXZ6Ywf1
OlTYwYOi+XJvR+oFrgS842n264t+i+nF7IMLLWfJuyKFBLjhlNES2BnXl197m4f/yoEp7slqCG8m
htYQ0nzpSTZSr2KqLww3N9w9EEbkoZmgMlcFCCnzEZ/MHogcV8fxK3Rpy4UI9O1sTVM3jG1UsZrF
XOgzPjHj0I8ciUuP4UlVHolC6R6J2umPxx2J3nZNdUdUlauvnEd/ffvTz3/97sevUF4fUf95kuDB
/JbgZ80kddeyx7iNT9UoM7ZUvjIfrI9++Mu/L7HoH0/VfvR+bytqvGce4WR60hEk5GqnOsBGRtER
tNvgG3VjaOD2zFgSLWnESBqMt9cjSei91XFEzMesR9aFVmSsYqpqJAFtYuMfYD3qCXJVlLW4LvoI
Onjd6RHZIHK1EY/JqQ8e6b3tP5ltatbiiTbcm5YLuAqtH2mby8dPisf7vJ4NPaq0MIF6RD79m9Dy
UQU22XFz9vHZx3DOb81I9eOJ6ENRZfRHtCNtLiKpuMerr7xmDTTS9oUgoNi/azJinHSwc3S7cBxL
hOqJTVePNPc/CZxWO/mfja6Uz2e/SsHrM6hMuAo4L/HBGCt0uZGmKTqG8Vod/nD5s0zlHjoGV+WV
QTZpK0y4IjXJaQvNUqgKqxK5dYZx5RTVBrJuzQHUlcdQX/9lQeqslJ+Cx61sPG/cVK0gKoCfqOe5
SY5vquEL8PCzVJEyyLgJpe1N01kIz2WbsPxSNABVXnVLsoFpJyBuAhqSX+U2wmmAuUWgP4+qk9rP
o76L/imKqdzXT3XS+X9AcdaspNGvOMLdcyw3rVaapJJFchZzJJeK85KbqciRHDZaZdJ1kpOyuMWT
227N2qim11CyAfK2R0VNyuSp9kESrzqqlMM5Ul41g0wNL0krRDlA8wZy7mHRbMwyoa+O6iouKH4t
Ylgojo3aAKfHCKNnu3Yq+t9vv1/+/PWP3779efn1j9/87Stkd7GI/lHT4IvF8WkwxB2cBiP+yDQY
oo5NgyHqrmkwRB+bBuuoT9Pg5zsNvlh8mgZ/mgZPOg0GE/s0Df40Df40Df40Df40Df40Df40DT6R
afDF4sHT4IvFw6fBF4t/6DSYXZo7QN4k2FTWmQRDQb1JcJ/k/9v71vamkWzdz51fUZPNM2kYbCch
MDQMnE1Dms5zaOAh9Ez3aXo8siTbmliXlmTjMMx/P3VXlVS6OJYDFGv27qBadbFqab1v3VdplWke
BBeZtEFwIVYHwYW0MgiWH6M0CFYKkoPgQtb7IFjuW41dbRC2zSiXlKX4kAxmvQ3vSMkjUqDmnyeJ
ZluDp1QyOUb7Pk69sRsvo5xw/ZI0WN4qIKenJuRO0cmCnKSaLUhzFnhr8iqFo+6ARhIHGvg5Isev
8thllxgjdgjEFbaF089z3O6S+48TbypkmG/vKs9HW3/y4qv8dnTlUvhnxUSWF0Vd8Wtq+7KwZWe5
s1iUNq6WpdRMhZD/S0hkEB7+9e5dNEg69bfI64+2t3McEnWYojdLcmN2eIHGldcLD++dnJB3G46e
vnr969nL553f0ljIm9Mnz346vVIZXEnDEZdh9u9eztYKK+9X6YFgCDRG68XwiD9x1i6HB4usInLn
Yewx6V1chJssiQORoTudDe8KYTkUR9PhXbPhERDjvnXm7r1ZRhGpVeikFx6uArZlJM4EI5JilKzm
Qwr64XCI9kbLLB1NgmgkM8hEUvK4KF/mpjxChpDfBFPclro4NMjq0lXF4oTxip6b7Z7LX2Q+4qdt
jbnIyeTtdeTGKxya+e2KkimN2tLKaVNZNXFNXI3yNshvVGMlfz+6lDbPjiG2arSU3qhXQ5lt2q3L
0piiRtNXLMuo9ZqyetO9OII+WARRB3uu5KjTf7XcDl+gJlNLmvqvcNXy6r6EuTz6LfreXCruM2zs
UGz0rRfEqw7uOF4MmOOTZUp9XnX45nU5zd++6XdabaA1c8e0dTbRX/lmG2krvx/cUocDy4RdJzae
x+/zeLzM/DFxn9L2NRvyGr9ny2+1fdEu2TunrvmqPf+G8ct2+I1+vq0/Ddo/Iklk/Foid9tn0dJV
xTWKbs1lVJ2aq6d26/49skycrAbETxxhUzL718pjplxmDqsrv5W/GjN2SFfHW9uXa+arpnJ7+laY
EpehM0gWjuuHftSBoqpZaluaasldmpiaXG2JGhqVK5dY24yYS+zyTXqZyjow/wqd7pGfLYm9YyxB
g0HqL3wn8x+JQrCIHBt69C/fncfKSPgjynwPHWSjfxLZcDQ6+Eg+FRcOj7DgX+R7HaGBi/Z/8aN9
kpnkTcSAmJW0fS3pFEm7/c5X4YCfUPTIXYGL5azdgk2ZjDZcV3qbFTfma09WY8lbl2q05qZSi77z
9mentOu0xZnKKR47BbNIn7trQpAT6fZNv/VgEERkweGRZowD4oyWikVWapqycntPnSiKc0RXb/fZ
jM0+2RyAs5Ph3APkKgmyZZATH+Mo9SXuEUl2WyRL/SxerMhaSHTR1zFUsa6v6Opgj589DC/Y7P8w
uUROGt45Zn+H3eblassnW6zY/2OhTJAsJ4vApZspuG/N3f0IFonFwm3MjpSsDtuyy3BCrKvy2fFQ
oLfvvkubsqRsZbq0t5+o0nAZ7QaxgWY75arQaDkXpU0zSu+dsL+2oHQ7qhZz7vWELWflC9ruvedT
zPxftf+j16NUqskS+IIx3/O2c1ug++twhmv+veuwPyPwq1ZTG1lDAhuVYCSEaglFb2qbjoHSrM1c
bM//oFj4h5+mcYr/ZR79icfoPKZOctHg1TF+szgM8sE0xbY/SGLqPB4Lo5jfADBwFoGTkbcZ/MPz
3YXDJsYGzhQnHFCn8pSBB7FoRsW/Q7eFA3YFV7YwtyViSSEG0NKyu7JXUUYDgdESCw6roQTcOvDT
oNdKCdf4e5+aEvTv0BTfTAyblNNED3o5eseBuvhkxiEe3aKnz22FtyL3Tlpg+Em4gr928fqdMcWW
2NthxZfid987kIv+2zKOWjPjL2ztjKc08NlmL315DNVxWzLJJre1KCgm97An+EO2orT8WVuStGB1
49IaEVsujYJ2OBK2/pg4hBlmwQd/23kMdV8JsZe75ikNbftJAQQvmE7RYInHSVM/9SPXp+9UvByu
nnzux/2TcbKiDo9398ILchgDh4hhLIKJv5heCaPVLTgaRO9WIHpXQPRueRqzqnFT+XsL/F5ZNyTo
mqltucTuLhy1g9JX+PWv1PDWlphdZm6+6LfMC3I/Sr9FEtfa4zjJ+i01CoN+C5y58arfEreaAWjq
X5EtFr0XGuMeyLTfUunpujG5njbye7bTlZ9mdNNAn4WGfjim79x7sZjEd2BbW8wkNHff+yxw6jv5
MvV7hj87c9l3zcnmpcTp+fO7uOWdOO5Fz3SVOhhbdHq234KT+SW5lGpH5nrFUW792y6cHHdzeqbD
HEO2Zypc4LFb3vOn4ld39dxYsz7FbjpBwg520cz2WeZ81WtxQbdT2V2JKgvVz8MSkTuVRi/IDa60
K49DfX6+YnTQk7mRZ1xalqdLl17OVvzCiL24qBcfxNAEYqU6j5cuyzLEw5e9q74Qk7HDaNudRuG5
6chpEWPG1yoqrP6LeVFi/1/Gy2LcfzEvSrVas0hqnj9oTlG3dHq1sswLquay6GzL5652QRYtE0Cf
eS2+BCQGcYf9QC0TaOWZs8+9zqSBrZ9W+9zfHnchrjzNt+38XnVij8/o9ao0eeCSVHfTc5vN2tvh
i97q2L36pC8pewn9ve2Oukjm18aUuotX75+qq6/PexG9v77onezu9cXScY9vLhv4mn1n9f2fDp2o
rrlr9qHtur+k6bZni6Dd1Pqm7crNBj19vU27QQooNRzsRPfuVBvEfWqWdJR29qpkAqDHdyUdnN29
LO6A9PmypD+z7YZ1xbxqeqjU2Iouaj+3ifBq9H+Fy1aORlrOz1Q/qjiUQ5wklQ52Etco2sEdc5or
/maSBlF+QaaJQifPSj9Wjbzir6xyr1Q0l1xVU2JnYkk5iri15LpmTzfTurj6hq9r/rqmT8+vH8fS
tYBJfzqmSznLhZ+OqWu7H1/94+2rkloa013xC4hlSf2XFGnncjc0pCQciFWLsrlWI3s5gXFQ9zJO
6A2Wbuz5BI25E0R+WnqjmhRX1XnqZHNvUtZ5Id2NzumF2WO+DKv/djmqrgjSBqXxOHSSBH+DUiHV
yN3UgzsjLauvkNZy5Go+IE7swnJePWJHFj/xBnT/4pSsVpUMvhxXy5dZOJgunOyiTJiqfDfvT+BE
N2sOqIfB6uc3J2giAAPsd/r+bM9canx1Pa6hEHYPerWAQr4FJRJfjlWlcOmWekF4EIEEIda9BF1P
H9D19DIrl6PqiqB7p8bYBMYX3jJMSqUYYresV9/+VKgbxao3Fb2SeeaGuDkoVU6R1jIorvSAuM3j
vbEyhxqi2xSg+N8bzS8TPyVbLUZkSaiHLbcHe78Rp5pilOFkIXNxyVdVcZguZCvxtezrBgPPXwUu
hpmf+emKdnkrXdX6VA160KttVgj3QVmMgPwUF9XNVTN1rEhE3MklGrwy/DAZwA/eogO5FD+gmGPr
1YhnPaCpfkHK1iWkBu+d8ARreUgKKSEZLfcQ4GDnKrDFZPm1+Jtpq9FpGsXDOfvqhYP4aYA/+5//
jIjfcuLiGxEvEEMXpcuIusF3Ed8z5CLqxOMhfisvplYSscV59v9kz14ckfJGN6Za+SPiXDzyScY8
XTZtWK580itvBy+8J+3MLPgXVC1DfNQ246AWVGcZPFI3ix3ZQk+n7imxcp7Fz1lfB9N5uWwINube
z9iYC9Gpt/3/8bCBRT46//7s5bOzN+jdvjKBkuGv/m5/Hz1+3JjXlLVbzhdn35/+cvpUz4pfmlSm
e/YxfgFjEd3fovL+uIQOOc9/fPLmtKq2uZP6HXL/cvryh7M3P/3DVIasASaTbkWNn77CxT0f86L8
3O2oRZL3/Ombs9dvS3lHmZsGSZ51LOPFq6f/V5SwcmhFLjpmffPzSzUnps4N3v31k+dnL59rv8yV
J/ueppI0pyBqlAxoEyA1KZQpDr34aUAPc2HeO2LHskzHtcjxsMGs5thWlnuPZtHyu+/kiTDDSbDm
s13/wOUuo2Xme4PJMh9kfj7A+gnokX01ktocveUA6zVD+K2fjcf0/qRXr16cj8do8NNPz/CfH9Bw
7Y5JJ2wYDz2S6gW5YOmHsxen4/NXP795eqrJ7p1IKdVAghvE4IM/yIIJGQQNSDOQkRzPX/4sUqLB
WbEZjLeJbNuXciQO94eIjjRNnA3Jf2K2FD9vSJPazLQsJcnnZPiLBkKyTalsRnM4R2TlYhAjqUv5
5KJ+PGoUc8bi+A7rhOzNUh8b/AodPMNf6OUp/cjPfz49fzv+8cnLZy9Ov13E0ezmAapuTSaLMPzQ
40Zn0kbslwf0Gu5BFi9TPJBPLtFjJi9+wh1G/nurQTPG/REATn/AYfrUQgRAlK+N1lWVbguQYtv2
rvAhfsFyePBthICOftAh1KkGMDZsNR8vDp0gAuvpx3qENpXnMq9qrFQRbs2qpXOBO+NW7XcYw+rV
rCaoidq2ysopuF3VVv6EoaJ6XFW6bfX002i7qqH6K3a3l/4qd+dAeD0RntCm8uyihsnyRj8ulaS7
nEDlM5/qBCqx500nUPk8rHEClcXtaALVVnzOohzTEOCzH3wKbSrPFndmyWofWE4/lsN0KZ9IN3a7
jozwf7KrLgwr39BDq/RtjBHbVk+6othV/fgP2N07YxuOAMK9QJgrs3gsj0UVyJRE26KB+RDaFRRI
6QagS7Em2LYqhdeOXVVH/ILd0Ba1BHD3Am6pTjVgcd8uSYOVk8PyaV/mI9SpBsrtg9rlKMu2ptXC
vdDOeFX8hKGt0Di3Ity2csKH1q5qxsq3u70gJ1MA7f2gnelSPlncTLgMGmA3/ayGcm0qz+U2QqGi
kmhbEuWu4nbFobR4U8ugtRpV6dbV4q7ldlYvWr7dbQOzxWOAeZ8wPx5qgTLQC7zokm3xwL037woO
tHgDzBWYlETWogaXELn37t4B2PQDm0KfWsji3lWag+30YztEk/zfMtEWjKVLqkRrqZXlkyWM/Hqy
M6ZL+US4acPmWbqD31kLzX/B7i5rEoJJ9zR1GQ7FvxXqVE2pIty2p7r2dwkDUrrdEMCt2Hge5/QK
ZsBCX9vVC5WWBTZ3RP1sGcJiUF+dUa5N5dli26HTFmA5/XQvqS7lk8VWU9xgBKbTzwbDQqF60HIj
4k6dwIp6syKh0VKYHwlH+Tpv8Y9ZJDG4vJRxwlFlUZ7qaVJKmz0vymSqk0TlJyouDGVcnUfBokTF
BaAUVhz0yRiD372iKMUdXqEb3dVd8dIVL3SFhjTfcqriTH7fNDWYVV14WlOjFP9pWhnC9ZkUVlyR
yRiThzEZqXrmKvRn8rpVKKvBM5Wq0bLe8WDVmZW1KCrP/GRUVElQjt98gBVZzrkYRH7+Pk4bjf4P
P1wOlgk2B98J8ejhfR6PMbmNg1KdiBcmvfj79wZE/asB8bZCkFy2SfICy9AhNu1SZtWj56twgH8c
Gzym0mVERy0yAfN5eqQLimvnTWJ23bQxRlxrqxevX8JS+mmzkPlgJb7DbG6lHNf1swxaqf5aKaHR
Utju3k42T8GGerMhqk3l2WLbmZMvPoaFoN7MR1GoHizPoct5aE3Qw9w5v1t5h/Pn9BfsnkPnN7OI
Hj2Ao5+TUiWtGmTCwdg2XoEbLoAQXeIKFgubrgj33NbLIdrHvuy+ja3BLe443yG62U/YDW92/A5Q
3QuquTKLR4xh1XdlN3B0SKb5u+yxVMVHZrdS9RtBjPzi1l/u0jALRlnCqDtz2qZ4s7auUo5JP+Zy
NlBMZZqPC+pVoCSoCM2Vbc5hqpaSw2IXqfkCfKT2RoBSmcUjIcBOIDBPbavSejiUU5ljajizY14j
M5bydsB8N2V0nNFvTEbV5RouSCrmfgthvW5bf6NjUrP2+yvd9H1aS2cfzFTtkm6MEeYqdctpet1S
TrtZdxHPZvib4BcMYmDfnthXV2pVZJh5UcY4VWnbyFEfxBUX/7r1F6Qp/YtyHCWhDQeC8sJeorTQ
dXY4IKz8FBsYtvC9uftmqnpTfF2nbvNyzF09UzmUf9yW2+VkGTUJ6huWhgyticzq2K5Ek2IaSuyt
rTcuoivCeg2WEhkjatqoTjmNbZSeU7OR+pX/ckx9nUwp62PNtdu0DFM9TWVsMKRr2upQjatXhzlt
U7xZJVcpx6QWczkbKMa4z0MRNli7nsgYUWPtnXIarV3P2aGetU3iFu3aNbVplk90pj6vPnQ2+9rC
zfWphXAX0zXfVCpRpcsbJvoq6eriaib4NshvnNir5N9kUq9+j1olqmGiz5S0Ibqmn7hxKcZeoqmU
DTRStzVPFTfM8ZST1UTVzPJ0zm2c5ynn7lBrW2k0yWB/TV/HCjO+uYY8KLzZtlnVHN84PVqTvi1N
7ZTplcurmUatKW+jRZTyDl4haVpGKVJUpfVj7qY8deNrrUraJEy1D2aO2UnfkruNv65pE/5rXWZO
anVUzL3Ux1aWFczbuPWo9gUGLWlDdPNSQ/dSmhYdtFKYVW23p0K5YeAazKGrGbjGS8tVbRTixg+o
J6uJqv1wHXPXfDA999fce3BmPly20F8PQqhTDSg9CeORFEXY3DQqiYwR9Q1ke866ZlLJ2WW2xdRG
SGYxRlRa0eF6oXLlP3/77cFk4UQXD37//db/HCASO1xkOSZEbO5oEPnoILv9v6TM/73NCr09O0B4
oEjkSua/4K/6bjhXi7tx+3ZyIJmQ/jBt2nHxlAnFZ6s/NFSOqf+AppT1seZPuWkZpo9qKqOy7Fqn
EWOE9q4b5lTesC6nqSnlqaodrv6sxdBN6mA9ps6VsKb6DlQTSLQEG052Xq+WNlRPBWWNB/AMkWx5
0tKGGbeoyzU0y/00y1yZxWNpG2hXCHdKWE+H25dcR5cNJTdzuwmQzSm6Va9rWV0qVFuTNnJoTGBu
Ya9WkqmdrSmpS2t2BZLfeQuIR/GbNn9k4C84fgevp10i2uHd9EtHy42P8YC3Iqx07DrVuz1VR7bY
sMxOPKGUWQ+tkgqMEWYodctpgk4pZzODGT9rS5J6pV+ttDp1G0vrMIzCfQg0WD9E1HnF4CnOMMuK
rQyNXgdMsaYDPpw2/qL/xg5gqlyx1gGk6oVsAqLmjRg19WxOUbMZ44plGTdk1JTVbMSGajcmqDfg
zUuqM15DSVfYb8HMTK5Ad/KJUZ9I35HYn5HSxrqDebJDRI2G2fL2nRLWLJ/3UrJxYb255C5b6+os
W9NYTVS9NXfLXWfBWm5tZxxxuxI66YWHxxba/oKvY1w5jjPPT2B02ePoUqi0LKg7cKjYWkVYu3um
IUfNfpn2Yccu6JRt0+zAp3w/p4lQG9LVxdXzSNf8dUyi599oeyV351RlG9XTU9MuSz2VOaZun2W3
vOadlnre6zUgfg1bBwsSF7ZJE7paM1Uqpjay3sS6l1BnZKUStAZrrTsAq1rTuuIhrMPquZa2Kb5l
/XyDchpX0LVyrtni+GmLLiYnLoLqZnPqLiLNT5vxI1ZcuTVvIzKlbk5Rv4XoKmXVbR8yldU8BCpr
tT62AYMblFGLwlIZXcY8fXgFGZEB+MHeaJmlo0kQkeAxZgM0eIESXKJw4jdJAw+zMo5Fj0uyhOxo
UM6Y1rr+Mxheg5fABgNsydUtZa3rhF7KrnGg0Fj29TIPPQ/bgXbYnXqtXSUtWU1UPYK65a7DjpZ7
g15Sg/vJqq02+6psmOsy2nB7aV3Tmu24z/JNttxePju23L/dEnffHcyWegXfsnemlmGOqbfoLnnr
7FnNq3XHiB/UqmVy76ibmqCSrSI0G1VzDpOZKDl2Zg/k7rwuBkHv2GvlMS1ZTVTDV++Uu/a7q7k3
OVFh8oZraG1rnOY2tLQNOdpT1bSwW5ZpbFkbylTcJzx7ffbUxsk15mwlCVyYWNtmYm1KzUNecCOU
KgPEa8J19c7IxXsdSI3ez7fheLDiGNvcL684z27ukBuTtySp74JfrbS6TrextOZhoapYc0x9I9Al
b10ToOa93vGA8PbRba8qcwyymeWZfK5Xba/GM3vzRojyG9XHNu4a7VxGw/5RrYz6DQ4N1WxNZMbN
diWasNNQYkvvxImKGYUk9o5zf50j7sc+Id7wRTLpaJ9+3yluSQIURKUbmnmIravJoBeHh+M4yQpJ
FAZFYObGqyK0ll6Aq55DuUTfNTGvXkPJBcV9MaqIzNPP9fv6eGDqO/ky9ZX3ZONVNfWAWVEhI83w
xHEvlPoo6+JSKOZuC4GYRpqXLrMXlVzgVj9XShCXwvNgEI/W2fh9kOqyi4kXTDUJbeZd3IJqUnoW
SRUIzwmqbJqVysqTsCSZTkoCrKPJUv+tyM9LiSaLi5JkmZULStygJCF9Aj9akQ+vyVeZm2lpMRxG
ycpLA2ISuti/f3yoS/B/Y6xJ0kOMZlk1Lk50WYB7GH9UkwXRNC5/dPoeuIsZ4mIfIi9GpHc7cKIs
KLpExM8TtVDRVS16auekgzPCVjOKliRqjVx0I0AfPyJ/HeToCHOBO4+xiJSN24/Hc5/0p7OhO78w
7z8owbgirPJVe44yH5VyKMcnzdORBnH7JCfu6LulOU4qElOcVyE84RuwRHvadSLK0r/NY5Qx7oDA
OGUH4xSpWE1g2gNgNL2aKDNsu+c2QbiS+8odCeXiHTO05JU8bGJM5woV1lVpo960cutjG7XXuYwG
HWplMD4UC0IvfGe13XqQ5WTEL18CLuqZixS9quE677+djDLI8hHPTamAfupRNndSn/IDHl4O3hBO
OOqnvEYykj92t58fayE3dndYDb8pF4tRiivK8lP8+u/RYNDtJQnsZ1g0z8MFNhDPX2M7QWcvn53+
goiM/in2dpVEcstOSV7aXlGN1Vfry/F1i6WldA0LUaWUZC2i/COmeWPDi+gTSKUEplGykkR0XEui
oiE0RzB2r4kTX778M/qlcpWXqBOzi+Wq9a652kOxhqor/yJSuLOvWkRJ3OzlWjE0xXm1+jMV37JF
ZJ27UqVQxe1mIa24sCyiDC4dVSwUbg010KgO0JR3rzgHU5SlucnSgWPwCqQrpEbxhfcTLU5xqKEX
I3wGFNLKkfQiynSOtohVDzopyjQdKlEU17Bvn6aa4zYzJc3vyEnxGJpQl2LHRSyb+WxJcO9ESbD3
jzTIsVYelFPWJiFoqo8k1amNVSLs7nh5cYhBCP2unvtdilqVYMv4r9x/aEzQPJrZrKSmMU2ppKtP
M6tNIek/3VWmkSp3r34F8y/+KnfngLy+kaeoVQnWIc9seU3xNVOnVyjHOKFqLGeLtR0T2r4qmM2i
nDpiApj1CjNFrUpQ3kJrqzWRXiPYUs+2JJUqA7V0XcuvrQTdKad5jas3LibD+ioZy1vkzft5TKnM
MbU175S3pu5a3t4mtWuuPt16Bg+XTZLv/YaViEumA8vfyUoqmyak4d5+hCrieFtF2E2YbMIEGLNf
xiy0WoSsb3vF1howpn6NSdWrGrbfoNJghX8CDKpvg1L0qobZJXelzUtq2HJ7I8sqYGw9G5tUqgxw
3hqcfpE21E355Atv9rmUHCMnC6nzt9Bx54OZH/m4atsWg1/eWS5wvcMsnmJl48y5UK7jXlDF0c4x
E/pr10/o2hFRhp+RpVo8VPJTInj245O/n46fPzkf//2nX9Tg6eu3avCH8+fn3z85xx86xEWmuIgP
ZH8kDWV4NDOYErugv+dkl5E7T+MoXmZY8++DyOOLZrjA50+fjn8kv3Z2fvb92Yuzt7+On7x9++bs
+5/fcvwRp/l5ELEAg5aCKfzLy8gj63DEIjL2ebmhDfA3z+cYDUHiU3vjDIG5IYrpplC3BeJ/P33z
/StSyWfkHZ88fX3GH58/+/78F/78+sn5+dsf37z6+fmPXPLT6U848dPT83NF8PrJ87OXzxXB+Y9P
3hSS109F2WevXr9681Zkff3sl3ogPXv66uUPZ8/HP7x58tPp+PWrs5dvT9801+lLxKWAm2mP+CC8
c0z4iB89kHvFg4rEBW4CbgJuAm76VNwkzpsEZQEwEzATMBMw06djJu24X2AWu5bPEbjsKCLMEvS8
D75QqxKEmQJo86DNgzbv07V58ih6UJFAfxy4CbgJuOmTcZPq3yIwCYGhgKGAoYChPhlDMf9DgR78
OmYIjmGKYCdTBMelOYJjmCSAZg6aOWjmPmEzx0+9B6UwdL+Bl4CXgJc+GS8R756BGgBGAkYCRgJG
+mSMJI6uBGUBMBMwEzATMNOnYybhBjyoSICbgJuAm4CbPhk3sc1wgR4EVgJWAlYCVvpkrESvSQm0
EHAScBJwEnDSp+MkejdToAdt33CCS4jce3fvwI6TnnecaIrVBLDnBFo6aOmgpft0LR296DHQQtD7
Bk4CTgJO+nScxC9+DcoCYCZgJmAmYKZPxkw4rmAlEgBGAkYCRgJG+pSMRGxEYyUqAGYCZgJmAmb6
lMwU4xeaatTEJMBNwE3ATcBNn4ybnBQDgiCDJApdp+CoSoztq75pDuu9Pa/3cpXyR+uvV8knS7ju
om8bkkqVAdgrAL0m6DVBr+nz6DWZe0zW95aSEFq6vm8RC4sLxEJo5aCVg1YOWrnPpJUj/47vHNdM
D/BImM0ExgLGAsb65IxlZCrGUPhn0cB/iALv0fjGt747r95hN0cfUZ6ig98eLOL3fvrg98FoeECC
yyQhwfF4fHDzIXq3R3Pv/08wjfCbohuBt48eVwojV74qiXHKAEOFJW5NLer+N94PprV+vFFOrrYi
YafsSerMQgclOO7bk5uNOWapn6DBCh3883/Qb4eD734/MNwK+BEnTC7zOYZvV7YTvWVSFOUBb8Bu
zh0ml7i8ZRT8sWFFmuvBM/iRF0zR6Bb5ROjWqDaL5eM7N1mO53GeLJYzGOj17Xi3pNuyzPqJ8tTP
liFcQ977ckuhViXILiEfTKvtHL2NvCJtaCLFzYl9tJCyrC4NZF3i1vaxNSNvHmW6LplrG8dKhvq2
sbiVctdNY5daNFaitWHUcujGpkVVhE2mpl2C14vB6SV2MrvGLO3G1y27MEE9dfeC6s3RnK3BKEsX
Eu7cNDvXq0O12s20ms/ydpb6EIFWtucFaaFUGbC+v4YrOaboAWPq2Zh0zeqScsfNwF81UQ3tqrxt
r48mtSisS2tam7q1IW3PydvQImGn7LUtZzVHfaOp3Gi46/ayU0Wa69HaSupZvgJiS5wZfklgth0w
m6LakqjMbbrVVaUNjKZe0NcHqWnldeG1pgyt1NYpM2c3LW3XQmo5zpipnub0yxF3zXRda9RaoVa+
q+TSDbMSbYxoME92R1sfhslL6mKS5qStxtiSjZshT9Wesdb0SsnrjU7cd7drc2t//4bXbzUxJX2D
ofBLjvqwFFFUF1OpSdtqK235uLGIZB2y1ppLOX29vciLo3ZtMB2q0FSDVpNRM3wFfTDHdf0sgz7Y
DvpgimpLonIfTKGpkqiBtcgtSH1QFi2nC1+ZEraSVWMmzlQ0TVumWo7SEtcTFLtBatfs1PbmtS/e
yksytf2klM1TIKT+CUmoVQmWiUht/MqyBioSVx/1QUeyrC6UVJe4lZZaM3Jqkum6ZK6lqEqGepoq
rpXaNVV1qUVjJVopS8uhG5pkM03QZGLiCptebEwW1snI6lK3W1lrTmFmMmGn7PWGVsnRYGnFNUE7
N7UuFWmuR7uxaVksbyTnpF0bw6HX/ttJXbO6pNxaavxWETaQGbv2pg8m4yV1oTFz0lYOa8nGCYyn
as9YS12l5PW8Ja4Q2jVptb9/w+u30pWSvmRUGo9VpZYzG66kH8yiMe91Ar31S28G9RrEZaJTjLUk
aiA5ukGjD45jBXWhOGPKVoZrzsUJjiVqzVZLb3rqenbjVxHtmtxaX77+3VuprUhuOVexOTqgqH4p
qtBqESoTUmFiuqSJjugFOr3wESupEyEZk7YzUnM2QUksVXvGelLSkzewEr+MaOe01Pr+Da/fTkxF
equZKV+MXdygAzP1ykyqVotQhZkKGyuJGriJ3nnSBzWxgrowkzFlKzE15+K8xBK1ZqtlJT11PSnx
e2N2zUmtL1//7q2MVCS3nZAW8Wzmp2Ny/DsGYuqbmCrarUqt3yqf+lm8TF1o9nZwuLFQrCaw3qaS
DFaie3e2lRXL0OS53IMq2kRd0tR/4pcz9dKFEmV16kXVJG7vSLVlFH0pka5L5voeVTlDQ6dKXny1
835Vh1o0VqK9d6XmKBmZGlUR2s5qzszPnQkwW9/MpuhVDWOGq+cu4rKyD96i5XThLFPCVr5qzFT4
B2rPVMtRWuJ6fmJ+P3fNTW1vXvvirZwkU+t8JMWaoNlsCKz6Mh1WVkfzMSbuYkLNGQszYum6ZG4y
Jz1Do0m57P6iazCr1lo0VqKLeRU5LG/GcOOzXEMj1nMjVmi1CFk/zqPVHMeZ5ydgULswKEW3ZVl5
/KdRWEXIDdE2E5yNkzRY4Z8YxmB729geszpFnWqgrSPOrgbrqUvFC+vYpzKn7tKpaslZ9Kp4wk7Z
m/pVpRyNHStx/do19KzaK9Jcjy59KyVLhbSUuKq0we4q1z31YX/VQrvYYWuuVnusL6GDbdVnrrcx
wzVau7a1Vi3V2VxrxnrbM2e1tDF0x9kyS7AyoDHsozFU1KkGyv0us4nVx3aktN7pbHMq247Grkxh
m9LXNVPXlWjripRlOV15cegEEVkXzekOIWCtPlirrFWDrInD6vmre3eMO6/vvUcmyt24U1aTcbN+
WbmQTbtm5fwde2fyeoBr7aDVaKxTH60mb8dumprbdurLnBXwXr+8x1RaFjT22lSLa0zQgf/65r2N
+W4rnrsqv23Ia9fLZ1fhsavxl/28FU+nmG98ukYPxNUPcek6rUjqqKuWshhV+eskTnP0+te3P756
+YjhjBjz+3mALYBW6P3cyVGErfIh8mIc9c1oEkSjbL4hHGfYtKaBv/CyIc67f4MUu89fanyDlF/a
tPER+esgRzf+D3kfj1zE9TeeYLhe8GSLLJdcWEjtBhepLu6i081UgK1esKWptCyQ67OWmRL7ngOq
lK/OkNQb9bJgFu3GtHQVoxpNjLRklpsbUSfuiIG97dDehI7bDI6ns9zi8AAviKYxmNwuTU4quc3m
REJbjY7NKPDDrF+Zxe1uyobrUwtZbkGTOM7BgvqzIKZPLWS5BeGv+ZX2tnZoRopSqyLLDWryIQid
mQ9Gtb1R8Vvnv/9/L86+R4PF5MOxEL34fz89wZLFh9ApRK+OfqGy+LjMavonMYstN0v8s3y6Zrz4
cAJ22R/ZlTVbI7fcviZBBJTXe3esUGpVZLlB8UUPfhgIbKq/QaKqV6PUcsta378HBtWfQVF1qgGL
zcdNloEHBtTjomKhUD1osRHNV7gZJxtuwJD6M6SSUqsiy08QK+cN4fRwj6eHdb2WjnLabFDKmR0w
qF6Po6t6LR2HstugyscpwK56tSuDes0HVr4KK2Ob18HEdmFiUreGswF2G5e+wRisq1frqijXtIHb
bvvSNtmCefVqXmXd1u5httK49G22X59p7Xynn2JsFV1vuKvZZgMUC1pggddggYqyN93nbLMNyo24
YITXYISqtjfe+WylGWr7db8+G9z1EFW9Jcm0F9pmm2I7eMGmercpqVjz7mibbUrZzguG1bth6dpt
2C9ts4mVtuiCmX2yjdMG5qt8m5Yd1DYbanm3L1hq74RoUHHbnmqbLU7ZBAzG1n+3TtNuwy5rm01M
3xMMVraDAWlJwc37rm22Nbo9D0ysdxMTejXuxLbVoJTtw2BS/S6Wapqt2Zttq1mVNhODafVqWlXt
fnW7tf3IzdMFu35ofPry1fmv52BmvZpZnYbNMdjcnBSlLlmy4gmGDtsfIlyqkCftoEqCf171jsue
/VXuzvnzLMrpZZzkGWvXZU/ThZNdsMdkfonfYsUDxX1B7hgb1JT/UubOfU99PmYBbIORe+/uHRZK
ud+OfLLkGZNQvup4HufJYjkbitu0lyH/nTz0eTL8gF8eW3wRTJwZNogi7LguHnnLcDbn51LnxObG
8oenWFPBLCJJ4vSSyS78tU/rny+kTiu3xutXfcubmrWLTZUL4ipXezHKQOpq5+L2IIup30zyrHzd
LB5i28IEMXdS3+OrlXrk8LCwALldSBhB0SgyO9A2Q8qgsAYeFAbBg8wmeICbhbi4VViGCGuHEIR9
iJfgJqIFj2W4MBRxe3qxkMHMRfxIqNarMJri0nVqNyIrNR1RlcJ6FIkwIEUkbKgQUTMSjUBhSUIt
JWPiYm5PNCRNSoR0qypfGa/e/F2+J1e/dNB0VxyVDRbeAumUMVv6WU44Y1YCsnrxScN9AoWv7aoP
W93zZslfYtmdXcXXmLYmanb0Y/DXUuMzo87ZgeGkuvmgseGon6lT8Fn63K25mKHNB68pW9Unb73j
/s9dFZvqoKXyvNaLCJPz1MjKFVltYl0i2wdjs8AQXNcuqLGkYSifC6se62k+jqFtoTdufK5sV63u
KjTs8jLtuanbFVFZ0jYvRdav/zTM1JvnVWvnwcwDTfPYgFHwlZe4BosPW3U4mUQzLISkaRV2Y+xo
Zk1d077fSodFyYKrwvrkJdFe6Fz4v939/QF64TsrMs7ygtR3sZlfon9tWImDva06/2mcZXgYgYdr
ZHCH9R4e/vUuhm/SSZlekOUjnnu0zNIRHcOR3/kM34oPlvp8M/laJpb9fBQYHt47OSm9prPt+zW0
L9uVPNqgeerzl3aicW50I/Ez87KE9Yo1MSkRd8GH3Xofn8zaS3z42Zq7GFn0ae+91n20UVPS62/t
2ubZ7/RiyNrFI3W93qb4z34cIK4O3mg8RPK0DIaKy2Zpv+Okp34HLezOloUdtH1X4/UyDck+y69M
Z3bG7tyJIn/R5RPrGarft1Rg8XHJ9zgl8/pbfBBcDho8Jf1sOvJCHJOF9Wz1AyNR7oGlDop49cbu
IqDzeb2tSRRrDXRZYXONa+x95YUJY2msdeitOFnQM6JkPEQdn7999eb02aP9d/sj/IVoUyZyeu/2
91sUJ9Y09C9TkVi+atbzuVWwxyva4+DZz+en49dvf3xz+uRZad1NTO3bfpp1nY2xzsAgPwuDLJmg
/DLi2VpngpL/4yhPyTIk2OKnt8VSYy0+TVVkrVn2eVUeGOKWhkg3bNh7ZZ6gezC4z8bg2AexvvHN
xrk3GXvLMAHr+5ysr/gqWshWO1zmQa9304IFbmeB/Hvwf221OgwrsLnPxubo16B/y1fcly58N4g/
yxWHWepE+TgnFtplvUFNXl1t0Aqz99p7ssgRu4DKzweV/IOIB1vbAqmXvm/0BQPsZxLKk7u/dYH9
Bvneyd05WORnaJH8y1Qk9tukOCMERvnZGWVxkq8sst8sc9xLzhw3p+cNwDY/O9vUvk+N3FYrnTvZ
nI3fwDI/F8tUvonybJ5/MOz3a0zwWc5JsDOnHWYjWMLqPAQvwN4ZiIKUkjgL+ry2F8DaVzPCv0xF
YmvTEUS4GqKyA+h7fy6G+bnWjgPGbDZmsSuPf7a5nmBHgbN4eGd4WD1jrMYO7yh7KYsNbcLrQKZl
ccQuD5aQvo2+ECoWpfhCgZiYpK+sLZOyqjRMHFXH7YZBU6mvKnYEyN/VX0ftSVSJivyvF1MpHdlV
WZHVuuab6x9nV+/TY5HidNS2ZUphSQM18KBKfIAoHT4oae0BehmjbOnO0ZR04DBfyrMXWq7dvHHT
r8tTIbdu3UK/mer1OzqlDH/U0/kjUbxyBIn+drac4PLEgTT5FuLnj3s7sUSKOdZ/VZ6DK/3acT+/
dlTol1WORpZ+SyT6hxPk5PemOGoZTfEnyeYYov+OJ9kQ/++zHBtw9zQdBgc8ZXV0IIpgh6GqYyhl
9GCM+Cz1IvwYdVCMSFrVjCykTjXm44JtaT5PheF3xYYfdtKYSGtQmSymTmeaUmuiPksNMWdXHdTD
ElZ1wwuoU4wSbYz4LJVCnXF10AlNV1UJy16nEZWZzDGfp05Sx+20e4QlNGiFFVCnFiXaGPFZKmXl
JssuOqHpqiph2es0Utlo0xD9WWoH54mTNJ520ZBMW9VSUUydpvQUdXFGq5NQNclNOYpvZpIb2wat
9aiL23Px16nuJ+twyL3JzUFbq904b9xgb8Y+k5nNalrDOj0YWwnTxzGyhOmb1NmDNDMiNxlXIdcl
e2momPjQ1ae0g7I3B/KR3LJQ/YIykqtMhlntZZBWx1V/Wv4WVUkRosqQwanv5MvUzwoJmTSaOO5F
UZr+6QPlR4iH22ql9J/3F9Mozv2aahJLk0lXfkqdsEmB/PSBrkdXq5sMRWGg5OXWZHw9od7KW1ay
6xouqdGtqLFGaVKsIqWiSaOKGhTnlhVXSarVUWqzbFQyBTOqQNWnW7EL9bUZXNyKJDDV1916WE9a
Gj59KNxPTDs3UW+WC/yBwgvisoLoZ4T1g5wsHMTTaebnuMna3nEF+R1RNnNb8SXO8neb4lU+xuY5
RkTxxJZDB1vqzI+wut1ti8Ev7ywXuN5hFk+xsnHmXCgXWy5VHP2aTOivXT8hiiN6jPwsx5rw1/iX
iYD5M3z+5Hz8959+UYOnr9+qwR/On59//+T8FP8oLjLFRXwgPRgayjJioNSJIvk9J7uM3HkaR/Ey
w5p/H0TegCKD/Nzzp0/HP5JfOzs/+/7sxdnbX8dP3r59c/b9z2/5ugjxy5gHEQu41Le44lQc//Iy
8jDYBsQiMvZ5xf2z+JvnczRIgsSn9sbXcMabOQZX9b6m/s3FLWhRTFwAR26LM4O/n775/hVR1TNS
0ydPX5/xx+fPvj//hT+/fnJ+/vbHN69+fv4jl/x0+hNO/PT0/FwRvH7y/Ozlc0Vw/uOTN4Xk9VNR
9tmr16/evBVZXz/7pR6Oz56+evnD2fPxD2+e/HQ6fv3q7OXb0zfKCpdGFmRh65zM0GpSREj33slI
FfbDewWtXJn4yqBRX3LeC/kd9FHVnqi9a2b8X9/Ev837b/prI+JcFlFyGJNVlOv9cX8aXPdvc+q7
5l/10oD0sso/S52z9mE09DMWlkOd8OLOG37J1CdLeefozemLV0/Hz05fnz/av2ozKSn7Knwf4rY1
oK6M5/v9VJ59yi+3o4Su0FWCvhL0lb6CvtIkyEOHn9d3EQ/RDR8iph8K4by8XZuLh+np7pgdt5FA
cUBxQHGWUVyWL/nR/Gk2j9N88J7yCKY7GkPJjqXZW3h0A1joL6ZjNkLEoZSyoWQdkXZbn/9V7rmO
/vE6C1UGBboDugO6s4ru6JVsiZNe0JvGWL9Ok1HC01MxMrvX7xi5nVvuHOM/JNej4N79e58jz3TE
JbdvDQAqvOkeaooxNktAPwF7jPfiyb/pRuPBXIjQR5SRfdAROhj9djj47vfRf7Lbh4e3bh/enj1M
Hv73AH18t/eNsi8g8NZ0WwDKPiByv5LYHvCN62B079Ml/X2E34rIhp6TOx/p3+Gtj8M0ZmH2L5FM
soz+Gd66STN8k+Mi0Q1c9p8eoUOyEYA4bAyipf+QxfvuPEb7p2zHaoTV74dJfonozz5Ah2ucdR89
/vOxSE63EXzrr5MU3SCv/hd0dPMhi/Qzx6VPZIMBNE/QPEHzZFnzlCxlq0T3QpDGiMhI55v1vIM7
pDF4iQZvc2xKmHEkWS6iC5U23Ti5xPyAJkHk4IaqnAaL976NcakrNMjRupBifs3xq2boAP/fR+S8
v0AHL9+gx+gI/SfBrV+Osv+i/2SPbhwSqsVsRNj4IBuh0e3D9Wh2wPkZS3D4xmikCP5J+frW7REa
LmJMQqODm+gxnxouWtk+hgxKI4tNEX/w05++f/Frf/Z4ZdqFVXAgWiDaT060c9wxFExLn+kqOJN2
m+jgaXud6NCXz65j7ROmO4DmgOaspTl54bzsU9Kg6FeyuH7mN/ga1ohMH8NKEXAJcIltXIJNJRY+
lcisKQvyCVMe18+q8zoLgUKAQoBCLKMQjGvF6S/xOhIK17LUr4iI7TYCU9L3MQqjpHMtez/TyySP
YeQFVAdUZy3VeXHo5nLgxUOU5kQMoB5QD6i3C/VRdnTv7t1DAXsRpLiXcf3uzIWBEvAI8IhlPOKQ
i6I5idBnyiBMCngHvAPe7cK7P3eDgTeZybNGhYAiX4nv6dAinYOAvgNwCXCJZVySBv/GKvbl3IMM
s33VMhawD9gH7NuFffXCAjrryBzOs1lHB9YaAPWAevtQv8JWJjBPnynimRTwDngHvNuF90mQx0mm
uCUhIeGWhMYA6gH1gHq7UM+c0RbbL2mI775kMd22TRUzANBFALIAsrCSLDJspI6cAuQh5syHx/Sy
Z1JbRniNBlhhP7MDynDqFk7dAisBK+n7v/1oSO5V8fh1iiQg/h2eU0cCA584CsCyd0T4bhg/kIEH
xLnA35RCHhfPyuUWulAJbuddMVlOU/8P2LUNBAUEZS1Bef5kKf2CsQBbPWHybgMseRiu2PKpbuAo
9cC29HiiH7vdhuESNwB2A3YDdrOY3RbOZcFuJMDZjcoB8gB5gLxdkGc3uB3LmSAZZttKZSxgH7AP
2LcL+3AEFVAPqP/aUK/f2ao1+8VFrrLtl+l6dgLGZkvhfAkQDBCMZQTDsa34FKRB4VOQxfVLJ4kL
l08BlQCV2EYlGNeCRsgjpRAqA7AD2AHsdoGd9w3GceT5oRN5pQ5EIVd7EkrqbouvjD76XFmlnY+t
FladLMux5S5nc1hgBYoDirOW4uD4LaAeUP+1oZ7NpE6DaaxPt1KJMtfKUgADAAMAA9jFAGKwEgaZ
O57FeNgQxWlWHuCUYrVhTjknsASwBLCEXSyxzINFkMsNmCJIeUDGAfAB+AB8u4A/S7F+x/STCfCr
IkoAWpqeV0+L+UdYRQV6AXqxjF4CrHR5bTgLUErhcoA8QB4gbxvkC7wLsHc+nir2aBnWWGvnI5QB
Sq+nVsU+0W3WVx03gZOrwHfAd/byHVs+HSfOzNdXV5lIWWLlaYAEgASABOwiAdgtCmAHsH8lYPfv
H8trFOkz20hBpYB3wDvg3TK8r7X1ERFkqF+r6yJXnSZY5Z46S9DrEguZgoC1FaAloCXLaClaho68
zZk8U0JiUsA74B3wbhfep4tlNs8XE4F5Gaa4L2IB+4B9wL5d2I8z6S+HPFLEUxmAHcAOYLcL7EEq
PdiQR7aHgsgA7AB2ALtdYL/AplE4w+MhCnkRA6gH1APq7UJ9EhJ4yS0DLMR2DfAYQD2gHlBvGeoX
Tj6N03A8x2BJSa0kA1RjGBsYcgAzADMAM9jFDBf+5dyJvIWfFiMBKeGjgSIFMAAwADCAXQwwf5/6
M+mXhYco8kUM2xb01/5PXo9WuQc7hIBTgFMs4xQ4fQ2QB8h/XZC/c/+vEvHkmQGeSgHvgHfAu114
T/1JHMuFBB6imBcxgHpAPaDeLtRf+GvfLWYKSYBPElL5VmeRuCGA0xIgECAQWwkkuH989zs5TqAB
NlBgcoA8QB4gbxnk47GDv2YxHciCfEKQxwHwAfgAfLuAfxGEim8yHmLDBR7T78oicTgwYhYCq4rA
J8AnlvFJPiEOV+VWBRGkjCLjAPgAfAC+XcD3QkduT6TPzLcplQLeAe+Ad7vwnk+mjsfXFp+dvTx7
Oz4/ffr27NXL8/Grly9+ZY0/TcLbfpYcqACoAKjALipYBNLtEHmkeKcyADuAHcBuF9hDP4xTeRck
D1HIixhAPaAeUG8X6vNJEGFLWrT093ki3uMXWYAQgBCAEGwjhPXUcf0WPmBpOB3wDMAGwAbABnax
gbbmp6z4wXofQB4gbyXkSXueytNFDT2AVB46KrLsxZN/e8swQYO5XBlAHxFGINYfOhj9djj47vfR
f7Lbh4e3bh/enj1MHv73ACd4Pw8wYFPf8VDgrVGE3xhlH7Agyx8iL0bv9r5xHWxo+zdI1D7CFoJF
w1tDiuub6OFDGs6xZX+kf4e3Pg49J3fYXxKaZNlNkuibHBeKbuDS//QIHaKPHxH+xNjklj4t4xvf
ncdo/5RY3AOU4S+M4qmsywP6+yjI0OEaF7GPHv/5mGdbB7jUb/11kqIbpA5/QUc32Wv5meOSBw9j
hijIjZNLNMAwImVhynIJPNEwjcmrPhoGUZDzQG2qISbKo+GRlpjLWvIcG/Ict+Q5MeQ5aclz35Dn
viEPjU39BfuSPJMubMqVxuaMQl5YIX+gyUp2KsazdliqqA3Y6pdnq9IS5aPJXvmAyw5z5ZUBa/3y
rFXYoXgy2yrrGdhirKw2YK1forVyS5SP3F5hEAuDWBjEWjWIDTN5Mzd5ZMvYRLa38BABTugvpmNs
jmMMbTRISXxx9r3Y0K6PGsq9slLDVyEWecDmhe+s+jxfs81Jf1KzIA/gsD9QIFCgxRT4RxCtHOlq
nIcoEYoYQD2gHlBvF+pDbFyBesdAIWCdoCIe4A/wB/jbBX+cLPVDJ5H+PkSYOfyQsYB9wD5g3y7s
R3EeTIPiLhEZptgvYgH7gH3Avl3YT5yZP8Z1iaWnL0XC7hRTUgADAAMAA9jFAEGcxGk+9vEAH6Os
8PenSbnbPz3lDvyAyTUGcAUGVANUYxnVLPPZIp4UawsyzI8GiFjAPmAfsG8b9sMgcxvPBvAknAxY
cqACoAKgAruoIEj/kMMM/MjGFkQGYAewA9jtAvsfyyC9kCeBeYjtJuIx6rZ/0ezbsOlf1AW2/H9p
W/6lFfIHviu30w7gYhRbyt37nl5lrmybbb1O4gfqjt5tysJaKRfV7/wgeVmYGoRuAnQTLOsmYITL
a0npM+0iMCngHfAOeLcL70nq+2EiIS+CbMeBiAPgA/AB+HYBP3UiLw7lDeQsRGEvYtiw4X5Pw4bE
ybIcG8xyNh+tcm+EDR0GEMArwCuW8QrGtiAV8kgZhcoA7AB2ALtdYMddhZmPcaR0I1hYdCR4LGAf
sA/Ytwv7YeCmsRt7/tgJZZOvC9mBZT0dUAFQAVCBXVQw94tFA/pMgc+kgHfAO+DdLrw7udxIRB4p
2qkMwA5gB7BbBvbEDwYTJ5NHEgsBA34RD/AH+AP87YJ/5s59b+xiVQeyj6/JKAnoqYAHgAeAB+zi
AdrMB7HWCcDBogtA4gD4AHwAvl3AL+bvSYZFdaafiUtz/Txtt7MadH8An0GQm456OJ5h3HPU6Y0C
bGlL/K8XOulQ3pYoHS8rjhjl8Sly6GJkOnTRf0W2PGgSeurhkE76YBvA+ZSuOuRTuL/3gzVwyASa
FGhSLGxS2Mdqvp+SJWG3U/LkQAVABUAFdlGB7DFW+pWlHmXpWjpOCTacTxd1gfPpX9r5dGmF/GGT
8+nRMnTwP3FGhhNJSBoZ0sF+n/ozUmLqT/hdd7TokXaynZ83V4Wkr6yG9TeiXfN7/XXNtxuArALP
j+HyKmjXoV23t12XR8tCfqyMSADpgHRAul1IV5d+j00rxMfVJeLjvp3SqBOkTujBrCEQDRCNZURD
12TGbEQjnONLCXeMX6Qoxjx98AsdsgCrAKsAq1jGKquZI8+r40d2Xp3IAOwAdgC7XWCfxlE+vr8+
OhGQLwQU+Eo8wB/gD/C3E/73yvC/p8P/HsAf4A/wtxT+90vov6+B/z5gH7AP2LcN+2xqkO7YVucO
iUCZOqTxAH+AP8DfLvgvphMBfPJIIU9lAHYAO4DdLrCznQYYM1N9OwKVKHsRWApgAGAAYAC7GGDl
Z8WqHnlmy3pU2vFIKlkCVNcD1MlBZa6A9SJE0X3us4YtB8BOwE42shPrfWBlRu69u3f0PoqUKv2U
IiWwAbABsIFdbJC4AfGMPeYuJ/g9XJqQ3calpwMqACoAKrCLClhzn5b87KWaj70U/OsB9gH7dmJ/
ufA17JNwgX0aC9gH7AP27cK+OLeUp+WTTViinWwiKYABgAGAAexigGy+zD2sHNn6izBr/WUsYB+w
D9i3DPvYqoL0Dwl9HmTIF3EAfAA+AN8u4LNOvRt6eq+fCJROP40H+AP8Af52wT+LlZn+WM7yxzDD
D3gHvFuI91AePiKPDO0hHDgCsAPYrQM767vPlsrN2KpI6d/zNEACQAJAAnaRQJYEWDHuhWz2RZi1
/TIWsA/YB+xbhv08TsbE0oKo2NOjyhgHaKmAB4AHgAfs4gHWyfd8YkSNN55pCZXxgcgK5ADkAORg
FzkQCEazontAQ7xjwGIA9YB6QL1lqL8MJ/Eik7DnQYZ7EQfAB+AD8O0CfpgkTpoVV53yIAW+jAPg
A/AB+HYBP7vM3HxRNPg0xNt7FgOoB9QD6u1Cfe5kFwtfrv+LIMW9jAPgA/AB+HYBn03ck4vSO8z4
02TKfD/LBrQAtAC0YBct4GrJsT99Zj0BKgW8A94B7/bhPVUBnxaIBz8eAHmAvHWQj8JAAJ48UrhT
GYAdwA5gtwzsy1DeMkCfGdypdC+e/NtbhgkazEv7+NBHhGGGlYQORr8dDr77ffSf7Pbh4a3bh7dn
D5OH/z3ACd7PA4zK1Hc8FHhrFOHXQtkHLMjyh8iL0bu9b1wHW9P+DRK1j7AZYNHw1pCC9yZ6+JCG
c2y+H+nf4a2PQ8/JHfaXhCZZdpMk+ibHhaIbuPQ/PUKH6ONHhL8jtqulT8v4xnfnMdo/JWb1AGX4
M6J4WqrRA/oWKMjQ4RoXtI8e//mYZ14HuOxv/XWSohukJn9BRzfZy/mZ45IHD8ODKMuNk0s0wIgh
ZWF2cgkS0TCNyQs/GgZRkPNAbSqynepoeKQl5rKWPMeGPMcteU4MeU5a8tw35LlvyENjU3/BvifP
pAubcqWxOaOQly1SC9IsBvtl81L2WC+rD9jul2m73BqVALfbTre7CHeKQWH99OrHspN1ze+i6o9F
P7tpApDh1ejtMH/t53aYxMmyHHcelrP5CL/wAS0cN2WdW+43S9zRGIYXaPAUYT0p2oGuKnRVoatq
V1cV85pytYS8UALADmAHsNsG9jx13GKhiQbYvDOTA+QB8gB5uyCf+KmbFLdHsRBr5XkMoB5QD6i3
DPXzy8zzVxL2PMhwL+IA+AB8AL5lwM/kvhLyyACfwZ4SADuA3TqwYwgtC8+xNMCOjjE5QB4gD5C3
DPJwHRRgH7D/VWKfLO9jcxHQF0GKfBlX7CU4JaX2uJkA2/kB0ArQCtCKXbTi5NLhFHmkdEJlAHYA
O4DdLrCv6G5G3oEgz6z3QKWAd8A74N0uvPPtyso9M4pHCYA8QB4gbxvkV1mCh/35VDbzIsyaehkL
2AfsA/btwv57J5Be5egzxTyTdjsARUf+snuwq4NJdC6x+4Es+u+QH0xAq9wbqW8cakGCNTiyBCQH
JGcrya1DXJHYHeeLTHZyNBklPT0VY7J7vTNZRxZz506qkpSbLKep/4cqwtymBRW2VMnOTbRkq8Dz
Y+A74DvgO2v5LnWXiYfxJbhOhinPFbGM4+72wnHbHRvvmoebE7/aZOAtw/ASOAw4DDjMNg7LwmKj
aii2qYaw6ARgB7BbB/Y89EN5ypw8s0PmVAp4B7wD3u3D+xjXXMU8DUvcs1jAPmAfsG8X9nEnfhLH
udK5p0HRwWdxAHwAPgDfMuBjqEnUk2cGeSotZiK3OYTCPiucOQHyAPKwjTz0GX/tunMudJVLz+XK
QB8rHBqtvEYDrMWfgzv37+G3Pv3hjH5SrLjTn75/8Wt/3/XK9HXNnLU5YwFhAWHZT1j+NBguvIwQ
VYx4AJFJDSI836Oe7310kI1w3DsifDeMH8jAg9HsAP1NKeRx8TyM/Pd74YostepCJci4CogJiAmI
CYhJ3xziY6CUOlKYN0aa/Jyzli7l0zIcyOKjGQD96hi/n+nlzMTQCP+ZeJXwgr6M+jx0YawHDAUM
ZRdDEQhGMznIYyE2uuMxgHpAPaDeMtRfZm6+KKZ2aIjP6bAYQD2gHlBvF+rbL7K/3tFGjMgCNB5f
+IvpnWMtAIMNICAgIOsICG44AsgD5L8myKeOF6wHeeoXB+QKCTsip6QABgAGAAawiwFw455kSqOf
ZLLRT8CPKUAeIG8d5DFcUjdO5JKnDFPgF7GAfcA+YN8u7KcTrbM/UTr6E+jkA+oB9TaifvEhFpAn
jxTvVAZgB7AD2O0CO3Gk54fLheL1ShUxB39qGiABIAEgAbtIgBhZEPnjC3/tu4IGdCElglI6oAKg
AqACu6gg8dbyWnP8SGFPZQB2ADuA3S6wE39Rjuv6mVzTUySsxVdSAAMAAwAD2McA/gqDSyUAJpD4
5/EAf4A/wN8u+ONKx9iGiss9RJjN+8nYrXzU4y+bYLNVrs7YprT5KkRwCweQEpCSraTkpk42F4zE
ApSOuBwgD5AHyNsF+Vz1bJsXfm25vLhTbHsvlyPWHQFnl0AjQCOW0YgXh04gnePzECUSEQOoB9QD
6u1C/QU2DV86QOEhinoRA6gH1APq7UL9HOtHYJ4+U8Qzaa/jhfkqhMECEAgQiGUEkjkrueWZPjOf
aVQKeAe8A97twnvoh7j5V/Y5kJDY5EBj9hYeIggK/cV0TA49YIyjQUqdm8kVR2AIYAhgCCsZYk3R
JfdCsBDbCcFjioHF1tfisHHFNjshFsEEExVshgBOAk6ylpNCbFwBqYzsuEgB67sU8VuRieMmAVAJ
UAlQibVUsl4U94jSZ9a1oVLAO+Ad8G4X3nNyeAPXXO6rEmG2tUrG9rpawgYlsGACfAJ8YhmfMGgP
8jhe8POiqpKzYBZRl1FqKuY7SsvXbZJV7NeSWzjkJK064uGdF5XLgHeAd4B3bOQdohs/bSUenkxl
HpGzz9lb2EUOfAN8YyXfYM1icKfSK8azs5dnb8fnp0/fnr16eT5+9fLFr3R7eZGMbTFXsgEtAC0A
LdhFC5Nl9CFIjhs5QaRx2XCGZ+hngsVJ3fmIWDtZqoGOBzAMMIxlDIOHK9LxNn4UQxjoTgDYAey2
gT2J34vZDBexAHO2yeQAeYA8QN4uyPPpSA/njaZx60ymSKdOZcq8wA/AD8APdvHDMlp/aJxeoAko
HbCkDWupYtHVD5NheQm2vC5SJZd48m9yqx8aYIuLSB0ybNfYktEwxxb8aBhEQU4fDSk8J3d4CvJo
fJOuy8AydY8rN7BDBQgUCNRSAl18CJ0WCqVJOImy5EAFQAVABfZRQdzKBHFBBDCmAh4AHrCOB7Jl
lviRJx198CDz9SHitnNvniz78m2OMeUQ04NzeEBJQEm2UhImjHHgLaSjARlmXs5lLGAfsA/Ytwv7
ZKRx0josOSmGJSfAA8ADwAO28YDvpItLNwmapyiKVJQPlExkhcZbhgkazLWN5+gjwkDEakQHo98O
B9/9PvpPdvvw8Nbtw9uzh8nD/x7gBO/nAcZt6jseCrw1Iqs3KPuABVn+EHkxerf3jetge9u/QaL2
ETYULBreGlJ430QPH9IwWf75SP8Ob32kSz3sLwlNsuwmSfRNjgtFN3Dpf3qEDtHHjwh/aWx5S5+W
8Y3vzmO0f0oM7wHK8IdG8VSrzwP6DijI0OEaF7OPHv/5mGddB7jkb/11kqIbpB5/QUc32av5meOS
Bw/Dp2EpK42VpSoWqE01xJx5NDzSEnNZS55jQ57jljwnhjwnLXnuG/Lcr1meG6b+gn1NZaGuEDbl
SmNzRiHXrVEJ0OSa3cr90TYYrawMWOyXZrGFHYqnqq2y9XYbDJXVBKz0S7NSboH0H5N9sqVMOyyU
1QVs9MuzUW6F/MFsp7E9ZhqDlX6ZVhoPxaqv2UZP7LHRE7DRL9NGT4ZiCrBqo8pUgA12qlQHbPVL
s1XVFotnbrOdtvlOgjx0yO5gN079ceKkF0E0G9K1MPY3ieMF8wrl5gvVPZS/8qN8fLyQj+7ciZjD
KBaeBmRDM5qlDg7QKVIcCtI/VNdSF/4lzuUt6F7oC3/tu+TfIHRm/pCfwDS7n4riPJgGNFuCE4+x
NCZ5k9T3w4R4psI/i9+VPcz8jFxOhDJ37ntjN/W9oBw8lmEM6akMOGkQuffu3pGCVGZc0gpl82Xu
xe/p9QTxNGf1y2KWjO67zpIgwi93QR7zOBmTWe4gonnzlGk7uwwnbH94dpkxPedOdrGgL50Hoc//
IdXNU8cl4ZWfZthcyBP7gqsswcXl5N3fO7R+65CqZZwvMiJN3WXiUWfq1G2X5r0La8kL1oMcq48E
JvyBNdeJt2bfYey4LpteIgH6mYfqZfX8wvmRYmDzVTiqbCtXJZWJqtJcgDru0nu3WjdC4+sqGPr1
A4BxAbvYYW0I1oYsWxtyQrldjTzSpR8qA7AD2AHsdoEdN+Jkt9cY42upbAgrZGJTmJKK9SPu9nEa
brsbaHC3qrz1tb/uDd8MC10cYD1gPctYbxLM6LCU8R0PMadpPGbbLfnT1P8D9tEDiQCJWEsi62PS
P5A32rAQu9OGxwDqAfWAertQ72JcOUvpOU0E2TBJxAHwAfgAfMuAT5Uucc9CDPY8BlAPqAfU24V6
bl8C9iLIb1zgcQB8AD4A3y7gk2Ty0msWoKDncoA8QB4gbxfkPX8RrHyyy0409jzMW3sR2/NC43wV
wiIj0AnQiWV0grFZbKQiz2wnFZUC3gHvgHe78E5HBmMXm5pf3K/Axw6KuBhFqGmBEIAQgBDsIgRs
PxPpZY8F2BVLTM6GEX/t81rGEd95BOMJoBOgE8vohGNb2aVNg2KDNosD4APwAfh2Ad8Plwt6YpUB
XwSZTz4RB8AH4APw7QJ+SI6wD1Rf3YqEwl9N0dXXATvgIDcpF9sYlCUOfYyy5cVn1SNV2xyuCEM4
VwGsB6xnLevRG6ij+L12OTUJF/dT09jtWMSd++6FyiSd2FOOs8rvQedx+uBImMYBegN6s5jeJnGc
N3pdpwnYYVSaFEgASABIwC4SmCe+3FNOnynembTn7WUh7C4DBgEGsY1BEmdG3SbyMRILsRESj2Go
x+rFlTj96fsXv/an4ytTyTXzx+bsAeQB5GE/ebzHPYxlMiZmJBhEFZ0TGtHSaPfm0FGJDW6fWU3A
4/OX5vGZWyD9ZxM/z8yVMp25GyrXLyt3npY83Yn5PtVVr/KrJYz0ulZC5gG3Wyih7ogJAMsu8nrb
coa1M2ITqTDEgF4C9BIs6yU4oTeOcKUx/y4Uj8CFTLgGVlIBDwAPAA/YxQPzVSjnKvEjm6okMgA7
gB3AbhfYQ9cfKzcAiCDbbSbiAPgAfAC+XcBPjmUrTx7ZUsIxtPIAdgC7dWAPXYfOuhbNPA/zdl7E
9rwXQUxJwnQhcApwimWcspY3IHKP+CLMfOLLWMA+YB+wbxf2J06a0oto+Y06PMh2MYs4AD4AH4Bv
F/CjMBgHkdxFJIIU+DIOgA/AB+DbBfzQzf2FHxYTCCzI5w94HAAfgA/Atwv4cTIOY89fjJMTAX5V
RAlASwMkACQAJGAXCYSur+wQkLsDAOwAdgC7bWBPjsNBkiubA0hI7A+gMYB6QD2g3i7UF314bEnV
nj4Rlvr6NB1QAVABUIGlVODk80Wxaags1ulApAVCAEIAQrCLEPBQf+AkfqDMAbCwmAjgsYB9wD5g
3y7skzG/r08H+Op8gA8TAgB8AL59wA/uH9+VS34sQEHP5QB5gDxA3i7IT7AR5alTLPYVAr61V8YD
/AH+AH+74E/O+9ObalVvAEwg/QHw+G4O2IpDQMXmYH2zUHk5oTqfqJFOry7XitOJ27hd45WHO2qA
GYEZbWVGmsxVpkEKgSvu9+bxAH+AP8DfLvjTfU+xp22Jij1lTxSJA+AD8AH4dgE/wjDT/KEWAnbk
sYgH+AP8Af52wT+QGyEDvvsxgC2PgHRAunVIX+aBbOPpM0U7kwLeAe+Ad7vwvlJONK7kkcYVnGkE
vAPeLcR7kP4hu/L4kfXliQzADmAHsNsF9tkSG8n4vbO4GB/zq9ef/3x6/pa/zPjF6d9PX5w/OiZs
UKRlpKDn7bbNQb8Sqbg2QXGsXHhFLLwlMQ8KyvEJdYOFOrXIxyGieyIvdetjE4R6p9s22yDCPE0r
N8/15kiaqR7cSANZA1lbRtZh4VNOuJMDT3KAdEC6fUjHXQSJdfLM0E6lgHfAO+DdLrwrQ6k7DcOw
Oy3DsDvADsAOwA4Ws8NJAzuctLDDyW5uucedEphtANYB1rGNdZiZimGICDJWEXEAfAA+AN8u4DMb
Ua62LwRsJ3cRD/AH+AP87YJ/6IfjxJnhKskZyELC5iGVFMAAwADAAJYxgBMU11+TZ4Z6Ku22zUOO
D0QuYAlgCWAJq1giT50kEzTBApQnuBwgD5AHyNsF+STEFSvushZB5txBxO1g0yVdYui6vxT/dTH+
nSXZQcrMZMjczizEv2MXo8UPoilxoxW+d7AmAm/BdpiS/Z0jpUTy4yPTbs2eagdrJ0CUQJSWEaWz
IMaB4bbiR+eenb08ezs+P3369uzVy/Pxq5cvfiUMqqajLKplBGYAZgBmsIsZyNxpNnfS0vSqEMn5
VZkGSABIAEjALhKYfAhCZ9bcNRBpmDdxkQHYANgA2MAuNvhjGaQXciaVhyjsRQygHlAPqLcL9cTI
gsgfX/hr3y1WW1UhX3bV0gEVABUAFdhFBWkuCYA8UthTGYAdwA5gtwvsiSvvBiaPbO3UhRuBAewA
duvA7rhJMA5Ddyon+xUJW/BTUjAGwKrGFTr96fsXv/an7yvTyjVzyeZMAkQCRGI/kbgL30nJoQvp
ileRnBMiUVMAkQCRAJEAkZiIJE4udR6RAkYjRTwMSAD+AH+74I9HGrjKg6kTHh3OC2+SqpA7ltTS
ARUAFQAV2EUFXhiMM9eJGnchyUSUFYosQAhACEAIdhFC5qzkqIA+U8wzKeAd8A54twvvrI8fzMb3
TvSRABMp4wCeBkgASABIwC4S8GLioWVMPoTXPBJQE7LRgJZ1qytxsrnjxe/VS3GAaoBqgGqsohpc
ydXMkSMMFmJjDB4DqAfUA+rtQr0YQQzIiWbfK480hFgbbci0QAhACEAIdhECVnri5MX2Axpy2d4D
FgOoB9QD6u1C/SqInaS4TUIEKe5lXM/X04ThiE0sgI81YBRgFMsYRbh2lP0IEhL9CBoDqAfUA+rt
Qj1bdBCo5yFlOQJQD6gH1NuG+lWQBl7gRMXwgYf5+EHEbrUIOXcSWIEEGgEasZZGkvll5vkr6X+B
B5kPBhEHwAfgA/DtAv5qoU0+LpS5Rx4DqAfUA+rtQn2ycPJpnIbjOQZLSmolW/5qDOsEGHL0vyiB
BxqwIgF8A3xjGd9gXAuCIY+UUagMwA5gB7DbBfZVmElHjvSZDSeoFPAOeAe824V3N1mO2SWRfMOB
CLMtBzIWsA/YB+zbhf3ZEhvJ+L2zuBgfL/yVz+cRnj3/+fT8LX+j8YvTv5++OH90TMihyMDowVAA
8ATwBPCEXTyxUhcZiiUGWGAAvAPeLcQ77vVPU/8PZUhAg2JEwOIA+AB8AL5dwFf683faBgR3WgYE
d2BAADwBPGExTxy3TReE2AYDlRiOgQ6ADoAObKODVZIX0wO5mB3Itzy3wNwmwNEFoA6gDmupQxkw
nLSNOE5aRhwnMOIAngCesJInmI2Mla2IioQSgZoCGAAYABjALgZYJeGyGGXgZz7MIFLAO+Ad8G4X
3nl77hdzC4pEbfH9rWcaslWoTjP0ezAK/ze+dzJisxkHcIUtXGELhAeEZyA8jKn0UnAdC5wTmuPy
vYWHSH8h9BfTMSMVHEpJioK7ZGLJYS98ZwUUBhQGFAYU9skpDJgDmAOYA5jDsA6UpOPsfZC78vZu
RUI5RE3RrS9Ep4JNZ1RM29RMC0nanLI+3AQmAyYDJgMmqzLZhb/23XHqY7gIKlNFlMu0NP2O1YQf
nm3mw1bhWp0P60S2YYj/5KmTZCSAgRZE/pjWE4cTN8B/HTcJxmHoTmdDcSfSYOqER4fzYelG1uqN
SfISFekPufBsaHRvpBxdLs4s8FJG1QGz1ryYvs+9XsfSB3vx5N/eMkzQYI6cBaETzM7kRmr0EWGy
xWhBB6PfDgff/T76T3b78PDW7cPbs4fJw/8e4ATv5wHm5tR3PBR4axRh+0TZByzI8odYP+jd3jeu
g2ll/waJ2keYD7BoeGtIKfwmeviQhnPMYx/p3+Gtj0PPyR32l4QmWXaTJPomx4WiG7j0Pz1Ch+jj
R6zCCBPM0qdlfOO78xjtnxJ+eYAyjGcUT/UKPaAvgYIMHa5xOfvo8Z+Ped51gIv+1l8nKbpBKvIX
dHSTvZufOS558DBNElW5cXKJBpg5SVm4iXIJI6NhGpP3fTQMoiDngdpUQ9wwHg2PtMRc1pLn2JDn
uCXPiSHPSUue+4Y89w15aCw2TvY5eSZd2JQrjc0Zhbxkj2qIZohV2518CEJnZondysqAzX5pNlvY
oXiq2qoXBuPMJf60bTDWojZgrV+atSqWKB8N9qpdRG2FzWo1Arv94uxWt0gtyO0XduLAjAbMaFg1
o8FmRu+0nQWunPa70/temvkqHGWrELwMA8sAy1jGMhibnpgwpc+USZgU8A54B7zbhXcf9xcwvORu
ER6kqJdxO+g/rMI19B+AT4BPLOMTnCwVZEKfKZMwKeAd8A54B7wD3gHvgPcvE++p7yzC2JMDBhmm
uC9iAfuAfcC+Xdhn6wknbb6BKisQJ0AHQAdAB7bRAbORbBXqngGIQHEMQOMB/gB/gL9d8F+FblZc
UYif+RWFRAp4B7wD3u3Cu9LQyyYeGncAO4DdQrCvwnXRtq9F074GsAPYAezWgT0Jl2M3Tv1j1bMn
l0j/niIFMAAwADCAXQyA+/GeP1nOlA4+C4tePo8F7AP2Aft2YX8VuhNlHm8i5/EmgHfAO+DdOryr
Y/ticK+M7sGhGjhUA9oA2tjcqSz0FADyAHlbIN9+1w/0FKCnALQBtNH/DRrsyw2VK8sLdybKtuK+
nbZmc8eL3x90e8fEmeGfJA/HIfs7IF6p6YMvn5LYK/m/Lrm+Lnm9Jn5X/XAsCycB4n+VhdgLjnT/
2kqwXzepYdhRFcxBRHFinJ8AU/eAIvmXTybzOSbeoOzmzhTpqqZTLfhLF6dY+HY2tvStrYLxAfPu
3poekL+a7uf4p8g/VN/B/eO7J6xufuoyswxi8iclrnjDPC2+E8uRhJiYfCL9YxmkF6T+aU78B2cO
dUWKSWw1c4gKgtjBtE2f0sALqCe91ULIwiygSmMh+sP8U+MvolowrurOLHje+ePz154EeUy9Jxeu
jrm5ev7CuWT+1tx8ofpA5h7YEub60r9/fEj+WdNWCz9NF8tsni8mdT6Sgzv3/8q/1Hf064z5uzAN
BnESp/lYwRb7coGbxi4207ETelqYfOqFKhGOocMkcdKMBKOQlBwtQ0f6hSbvkyx1j84ZsQLcH1om
lHqWOeYeUuEsTNjfSRwTFWUp1RTpeTGWusyYioglMY/Urq94psbdqZS4DMSP5HsUVSu7rHZTJyOu
oHP+Q9y017T3xp1Zq6aEa6AGcY+JqFKjS932Qi0U477PNFj4qoxfu6RaSsUXb8ndKXIXvpMKeyAV
Fc8lP5NG333U/u/2Y/9Ntp+kPu53XOC32BhV5GuoGtm4AH8aXCU/6xVcJaeX4q+VZlfJus7Crep6
lXqml0keq6T4ALV+yAFW6nV+zK/2YyBqvYSQOIpJOF1GnOxISDQe7LsNQkzx9xI/QYNBtpxgdsRD
z0dHhzhIaWMwcTL/0eF6iv93/9g7vH/I/keSkyHZo8Pb5HnuOwl/JEybDGjLRELMhygZCs8iMqbF
ZR2LEgiflWKwNHT+Haf818m3wNnJ6T38plFFflemjzMpPJaJFWFRsqymIUM1Dud7S/Q2XHh4BPSy
ZNFUveQWgGzgLcPwcnMbzS7DSbwosg+6lzDEf4bkPaqfZ3iI/vxnhK70iV34xJ/zJ3a1T/wAw5i8
YXhB37En2+nn9R5vXkw6PMcVikLixbqfqnzEIOhaUh7jzyQ+11VeP6Ovf+WbVa6ir6vYUgbs3ws1
XOP36qtdOIJ24av7+K728XfRYhz19HqbU+5R3y3G0bW2GEfX3WIcXckIj6DF6Ic03u2h0v+u8Qtu
QiM8314wxWiYOovMf4jyuR+hNNzEUHkxDxG97ePg9IczlC0TMmmIvCAjk5DewUOEf8cUs7fZb8m6
0stPbpmnl94ikkr/NvK7XG+/foDzZ8PDvc25i+fETHUNPMV/DPPUtbCU+DllsrEPz75wKT3sCoBd
AbArwLQrQKMdtjfgSgR5xQbgetZVemn4tLe+WnWPrtzeHV1ne3d0ve3dEbR30N5Bewft3fW2d0dX
b++OrtreHX2R7d3RxsNnmu8KQ1j2e3wMO2RL4OEFrtud441/fpMM6HB9xCZa3u39i7bR6ea/9xHN
yd2iuH0/EteR+uggG/3z3be//RP9fuvdzeGt0eH63dHo4F/MCk76soLZhyAhuh58h/62Ub0fbzSb
MfswjPz3e+HqCrk2zLL3Gxp4nfJ4QZZjTsPNw2JBLQb9Ti5c5RJSyiA8/Ovdu5g7r1beniwqPLx3
ctK1nKIuV/tZLZ5oZBHRT5yhUsSWxe+q5J2US0rd6nN0pwZzvUh2mYjMEP5GdvtsOCWIBg67qniZ
paNFMLl3QnZeHaDf+Tzju71vrmb+Wnl94kArmF41vB0oyOtt9xI6PMRbEYvLpqgc19dvXcvP7P5H
5E8w+yWWSA2cGiG3Tc0aP8XXFm9E/zN/bdyxIRXY37TsffQI7esCtbLFfD2PpkMzFEeLS5Q4aR5g
0SUid2yjb3Gq8d9PXz579QZFuOnBw7ObB/Kqbvaa04C19ne2au0PWCHHfRRydOVCWAEP0K1bt9Bv
7+N04f2O6DXm6Hjv/wMv7cKBg9oIAA==
--001a113cf1269938ad050a98f62f
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--001a113cf1269938ad050a98f62f--


From xen-devel-bounces@lists.xen.org Fri Dec 19 22:29:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 22:29:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2631-0008Qz-9b; Fri, 19 Dec 2014 22:29:23 +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 1Y262z-0008Qu-Qc
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 22:29:22 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	F6/98-03145-1C6A4945; Fri, 19 Dec 2014 22:29:21 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419028158!10850144!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13063 invoked from network); 19 Dec 2014 22:29:19 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 22:29: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=1419028159; x=1450564159;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to;
	bh=SNSNKhmPc3qyV1nGVoKm0frUCFenjPycQtyKdu8J8js=;
	b=TjMhSs9TghUxvKzUEEjVAVilbJXhhX3Vg6PuzKUN4LXgdBctwgxq3tnw
	yf/uTco0uDic2uKFCzO2u2/aF8e4K2SxrayEcM/7g1Js+1kKJ/GfUdjpH
	bU2pES46pZgIy/zPeG0ZuKL8QDDyVCDM54yVCGcRKbWKEbj5x800taDia 4=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 19 Dec 2014 22:29:04 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,609,1413244800"; 
	d="scan'208,217";a="898335911"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.111.238])
	by fldsmtpi03.verizon.com with ESMTP; 19 Dec 2014 22:29:03 +0000
Message-ID: <5494A6AF.1030802@terremark.com>
Date: Fri, 19 Dec 2014 17:29:03 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Singhal, Upanshu" <upanshu.singhal@emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
In-Reply-To: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1841490096756511426=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============1841490096756511426==
Content-Type: multipart/alternative;
 boundary="------------060500040305090505010900"

This is a multi-part message in MIME format.
--------------060500040305090505010900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

xen_emul_unplug=unnecessary (kernel arg) may help you here.

Also udev likes to rename your devices.

Here is a lspci from a guest:


[root@C63-min-tools ~]# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device 
(rev 01)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet 
Controller (rev 03)
00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet 
Controller (rev 03)

And to help:

[root@C63-min-tools ~]# ls -l /sys/class/net/*/device
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> 
../../../vif-0
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> 
../../../vif-1
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> 
../../../vif-2
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> 
../../../vif-3
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> 
../../../vif-4
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> 
../../../vif-5
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> 
../../../vif-6
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> 
../../../vif-7
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> 
../../../vif-8
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> 
../../../vif-9
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device -> 
../../../0000:00:04.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device -> 
../../../0000:00:05.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device -> 
../../../0000:00:06.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device -> 
../../../0000:00:07.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device -> 
../../../0000:00:08.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device -> 
../../../0000:00:09.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device -> 
../../../0000:00:0a.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device -> 
../../../0000:00:0b.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device -> 
../../../0000:00:0c.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device -> 
../../../0000:00:0d.0


    -Don Slutz


On 12/19/14 07:04, Singhal, Upanshu wrote:
>
> Hello,
>
> In one of my experiment, I am building a Linux VM with Network 
> interface model as "vmxnet3". I am able to create the VM successfully, 
> but I see that the driver loaded is "vif" and not "vmxnet3". I am 
> using the following option for the network interface: *vif = [ 
> 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0, model=vmxnet3' ]*
>
> **
>
> I tried with model as e1000 and it works fine. Lspci command also does 
> not show vmxnet3. Though, qemu device help shows that "vmxnet3" is 
> supported on XEN 4.4.1 version I am using.
>
> I tried searching on internet about the right configuration for 
> vmxnet3 with XEN, but not able to find right information. Can someone 
> please help me on how to create a VM with vmxnet3?
>
> This experiment I am doing to compare the difference between vmxnet3 
> bandwidth on VMWARE ESXi vs. XEN Server. My sample VM configuration 
> file is:
>
> # This configures an HVM rather than PV guest
>
> builder = "hvm"
>
> # Guest name
>
> *name = "rhel-vmxnet3-xen-2.hvm"*
>
> # 128-bit UUID for the domain as a hexadecimal number.
>
> # Use "uuidgen" to generate one if required.
>
> # The default behavior is to generate a new UUID each time the guest 
> is started.
>
> #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
>
> # Enable Microsoft Hyper-V compatibile paravirtualisation /
>
> # enlightenment interfaces. Turning this on can improve Windows guest
>
> # performance and is therefore recommended
>
> #viridian = 1
>
> # Initial memory allocation (MB)
>
> *memory = 8192*
>
> # Maximum memory (MB)
>
> # If this is greater than `memory' then the slack will start ballooned
>
> # (this assumes guest kernel support for ballooning)
>
> #maxmem = 512
>
> # Number of VCPUS
>
> *vcpus = 8*
>
> # Network devices
>
> # A list of 'vifspec' entries as described in
>
> # docs/misc/xl-network-configuration.markdown
>
> vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr1, 
> model=vmxnet3' ]
>
> # Disk Devices
>
> # A list of `diskspec' entries as described in
>
> # docs/misc/xl-disk-configuration.txt
>
> *disk = [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', 
> 'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r' ]*
>
> *boot='cd'*
>
> # Guest VGA console configuration, either SDL or VNC
>
> # sdl = 1
>
> *vnc = 2*
>
> Thanks,
>
> -Upanshu
>
> Upanshu Singhal
>
> EMC Data Storage Systems, Bangalore, India.
>
> Phone: 91-80-67375604
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------060500040305090505010900
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">
    xen_emul_unplug=unnecessary (kernel arg) may help you here.<br>
    <br>
    Also udev likes to rename your devices.<br>
    <br>
    Here is a lspci from a guest:<br>
    <br>
    <br>
    [root@C63-min-tools ~]# lspci<br>
    00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma]
    (rev 02)<br>
    00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA
    [Natoma/Triton II]<br>
    00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
    [Natoma/Triton II]<br>
    00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)<br>
    00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device
    (rev 01)<br>
    00:03.0 VGA compatible controller: Cirrus Logic GD 5446<br>
    00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit
    Ethernet Controller (rev 03)<br>
    00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit
    Ethernet Controller (rev 03)<br>
    <br>
    And to help:<br>
    <br>
    [root@C63-min-tools ~]# ls -l /sys/class/net/*/device<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device
    -&gt; ../../../vif-0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device
    -&gt; ../../../vif-1<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device
    -&gt; ../../../vif-2<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device
    -&gt; ../../../vif-3<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device
    -&gt; ../../../vif-4<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device
    -&gt; ../../../vif-5<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device
    -&gt; ../../../vif-6<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device
    -&gt; ../../../vif-7<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device
    -&gt; ../../../vif-8<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device
    -&gt; ../../../vif-9<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic0/device -&gt; ../../../0000:00:04.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic1/device -&gt; ../../../0000:00:05.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic2/device -&gt; ../../../0000:00:06.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic3/device -&gt; ../../../0000:00:07.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic4/device -&gt; ../../../0000:00:08.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic5/device -&gt; ../../../0000:00:09.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic6/device -&gt; ../../../0000:00:0a.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic7/device -&gt; ../../../0000:00:0b.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic8/device -&gt; ../../../0000:00:0c.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic9/device -&gt; ../../../0000:00:0d.0<br>
    <br>
    <br>
    &nbsp;&nbsp; -Don Slutz<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 12/19/14 07:04, Singhal, Upanshu
      wrote:<br>
    </div>
    <blockquote
cite="mid:6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="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;}
/* 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="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Hello,<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">In one of my experiment, I am building a
          Linux VM with Network interface model as &#8220;vmxnet3&#8221;. I am able
          to create the VM successfully, but I see that the driver
          loaded is &#8220;vif&#8221; and not &#8220;vmxnet3&#8221;. I am using the following
          option for the network interface: <b>vif = [ 'type=ioemu,
            mac=00:16:3e:00:00:22, bridge=xenbr0, model=vmxnet3' ]<o:p></o:p></b></p>
        <p class="MsoNormal"><b><o:p>&nbsp;</o:p></b></p>
        <p class="MsoNormal">I tried with model as e1000 and it works
          fine. Lspci command also does not show vmxnet3. Though, qemu
          device help shows that &#8220;vmxnet3&#8221; is supported on XEN 4.4.1
          version I am using.
          <o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">I tried searching on internet about the
          right configuration for vmxnet3 with XEN, but not able to find
          right information. Can someone please help me on how to create
          a VM with vmxnet3?<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">This experiment I am doing to compare the
          difference between vmxnet3 bandwidth on VMWARE ESXi vs. XEN
          Server. My sample VM configuration file is:<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># This configures an HVM rather than PV
          guest<o:p></o:p></p>
        <p class="MsoNormal">builder = "hvm"<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Guest name<o:p></o:p></p>
        <p class="MsoNormal"><b>name = "rhel-vmxnet3-xen-2.hvm"<o:p></o:p></b></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># 128-bit UUID for the domain as a
          hexadecimal number.<o:p></o:p></p>
        <p class="MsoNormal"># Use "uuidgen" to generate one if
          required.<o:p></o:p></p>
        <p class="MsoNormal"># The default behavior is to generate a new
          UUID each time the guest is started.<o:p></o:p></p>
        <p class="MsoNormal">#uuid =
          "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Enable Microsoft Hyper-V compatibile
          paravirtualisation /<o:p></o:p></p>
        <p class="MsoNormal"># enlightenment interfaces. Turning this on
          can improve Windows guest<o:p></o:p></p>
        <p class="MsoNormal"># performance and is therefore recommended<o:p></o:p></p>
        <p class="MsoNormal">#viridian = 1<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Initial memory allocation (MB)<o:p></o:p></p>
        <p class="MsoNormal"><b>memory = 8192<o:p></o:p></b></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Maximum memory (MB)<o:p></o:p></p>
        <p class="MsoNormal"># If this is greater than `memory' then the
          slack will start ballooned<o:p></o:p></p>
        <p class="MsoNormal"># (this assumes guest kernel support for
          ballooning)<o:p></o:p></p>
        <p class="MsoNormal">#maxmem = 512<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Number of VCPUS<o:p></o:p></p>
        <p class="MsoNormal"><b>vcpus = 8<o:p></o:p></b></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Network devices<o:p></o:p></p>
        <p class="MsoNormal"># A list of 'vifspec' entries as described
          in<o:p></o:p></p>
        <p class="MsoNormal">#
          docs/misc/xl-network-configuration.markdown<o:p></o:p></p>
        <p class="MsoNormal">vif = [ 'type=ioemu, mac=00:16:3e:00:00:22,
          bridge=xenbr1, model=vmxnet3' ]<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Disk Devices<o:p></o:p></p>
        <p class="MsoNormal"># A list of `diskspec' entries as described
          in<o:p></o:p></p>
        <p class="MsoNormal"># docs/misc/xl-disk-configuration.txt<o:p></o:p></p>
        <p class="MsoNormal"><b>disk = [
            '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw',
            '<a class="moz-txt-link-freetext" href="file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r">file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r</a>' ]<o:p></o:p></b></p>
        <p class="MsoNormal"><b>boot='cd'</b><o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Guest VGA console configuration, either
          SDL or VNC<o:p></o:p></p>
        <p class="MsoNormal"># sdl = 1<o:p></o:p></p>
        <p class="MsoNormal"><b>vnc = 2<o:p></o:p></b></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">Thanks,<o:p></o:p></p>
        <p class="MsoNormal">-Upanshu<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">Upanshu Singhal<o:p></o:p></p>
        <p class="MsoNormal">EMC Data Storage Systems, Bangalore, India.<o:p></o:p></p>
        <p class="MsoNormal">Phone: 91-80-67375604<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
      </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>

--------------060500040305090505010900--


--===============1841490096756511426==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1841490096756511426==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 22:29:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 22:29:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2631-0008Qz-9b; Fri, 19 Dec 2014 22:29:23 +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 1Y262z-0008Qu-Qc
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 22:29:22 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	F6/98-03145-1C6A4945; Fri, 19 Dec 2014 22:29:21 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419028158!10850144!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13063 invoked from network); 19 Dec 2014 22:29:19 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 22:29: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=1419028159; x=1450564159;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to;
	bh=SNSNKhmPc3qyV1nGVoKm0frUCFenjPycQtyKdu8J8js=;
	b=TjMhSs9TghUxvKzUEEjVAVilbJXhhX3Vg6PuzKUN4LXgdBctwgxq3tnw
	yf/uTco0uDic2uKFCzO2u2/aF8e4K2SxrayEcM/7g1Js+1kKJ/GfUdjpH
	bU2pES46pZgIy/zPeG0ZuKL8QDDyVCDM54yVCGcRKbWKEbj5x800taDia 4=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 19 Dec 2014 22:29:04 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,609,1413244800"; 
	d="scan'208,217";a="898335911"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.111.238])
	by fldsmtpi03.verizon.com with ESMTP; 19 Dec 2014 22:29:03 +0000
Message-ID: <5494A6AF.1030802@terremark.com>
Date: Fri, 19 Dec 2014 17:29:03 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Singhal, Upanshu" <upanshu.singhal@emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
In-Reply-To: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1841490096756511426=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============1841490096756511426==
Content-Type: multipart/alternative;
 boundary="------------060500040305090505010900"

This is a multi-part message in MIME format.
--------------060500040305090505010900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

xen_emul_unplug=unnecessary (kernel arg) may help you here.

Also udev likes to rename your devices.

Here is a lspci from a guest:


[root@C63-min-tools ~]# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device 
(rev 01)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet 
Controller (rev 03)
00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet 
Controller (rev 03)

And to help:

[root@C63-min-tools ~]# ls -l /sys/class/net/*/device
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> 
../../../vif-0
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> 
../../../vif-1
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> 
../../../vif-2
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> 
../../../vif-3
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> 
../../../vif-4
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> 
../../../vif-5
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> 
../../../vif-6
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> 
../../../vif-7
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> 
../../../vif-8
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> 
../../../vif-9
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device -> 
../../../0000:00:04.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device -> 
../../../0000:00:05.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device -> 
../../../0000:00:06.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device -> 
../../../0000:00:07.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device -> 
../../../0000:00:08.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device -> 
../../../0000:00:09.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device -> 
../../../0000:00:0a.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device -> 
../../../0000:00:0b.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device -> 
../../../0000:00:0c.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device -> 
../../../0000:00:0d.0


    -Don Slutz


On 12/19/14 07:04, Singhal, Upanshu wrote:
>
> Hello,
>
> In one of my experiment, I am building a Linux VM with Network 
> interface model as "vmxnet3". I am able to create the VM successfully, 
> but I see that the driver loaded is "vif" and not "vmxnet3". I am 
> using the following option for the network interface: *vif = [ 
> 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0, model=vmxnet3' ]*
>
> **
>
> I tried with model as e1000 and it works fine. Lspci command also does 
> not show vmxnet3. Though, qemu device help shows that "vmxnet3" is 
> supported on XEN 4.4.1 version I am using.
>
> I tried searching on internet about the right configuration for 
> vmxnet3 with XEN, but not able to find right information. Can someone 
> please help me on how to create a VM with vmxnet3?
>
> This experiment I am doing to compare the difference between vmxnet3 
> bandwidth on VMWARE ESXi vs. XEN Server. My sample VM configuration 
> file is:
>
> # This configures an HVM rather than PV guest
>
> builder = "hvm"
>
> # Guest name
>
> *name = "rhel-vmxnet3-xen-2.hvm"*
>
> # 128-bit UUID for the domain as a hexadecimal number.
>
> # Use "uuidgen" to generate one if required.
>
> # The default behavior is to generate a new UUID each time the guest 
> is started.
>
> #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
>
> # Enable Microsoft Hyper-V compatibile paravirtualisation /
>
> # enlightenment interfaces. Turning this on can improve Windows guest
>
> # performance and is therefore recommended
>
> #viridian = 1
>
> # Initial memory allocation (MB)
>
> *memory = 8192*
>
> # Maximum memory (MB)
>
> # If this is greater than `memory' then the slack will start ballooned
>
> # (this assumes guest kernel support for ballooning)
>
> #maxmem = 512
>
> # Number of VCPUS
>
> *vcpus = 8*
>
> # Network devices
>
> # A list of 'vifspec' entries as described in
>
> # docs/misc/xl-network-configuration.markdown
>
> vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr1, 
> model=vmxnet3' ]
>
> # Disk Devices
>
> # A list of `diskspec' entries as described in
>
> # docs/misc/xl-disk-configuration.txt
>
> *disk = [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', 
> 'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r' ]*
>
> *boot='cd'*
>
> # Guest VGA console configuration, either SDL or VNC
>
> # sdl = 1
>
> *vnc = 2*
>
> Thanks,
>
> -Upanshu
>
> Upanshu Singhal
>
> EMC Data Storage Systems, Bangalore, India.
>
> Phone: 91-80-67375604
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------060500040305090505010900
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">
    xen_emul_unplug=unnecessary (kernel arg) may help you here.<br>
    <br>
    Also udev likes to rename your devices.<br>
    <br>
    Here is a lspci from a guest:<br>
    <br>
    <br>
    [root@C63-min-tools ~]# lspci<br>
    00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma]
    (rev 02)<br>
    00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA
    [Natoma/Triton II]<br>
    00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
    [Natoma/Triton II]<br>
    00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)<br>
    00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device
    (rev 01)<br>
    00:03.0 VGA compatible controller: Cirrus Logic GD 5446<br>
    00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit
    Ethernet Controller (rev 03)<br>
    00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev
    01)<br>
    00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit
    Ethernet Controller (rev 03)<br>
    <br>
    And to help:<br>
    <br>
    [root@C63-min-tools ~]# ls -l /sys/class/net/*/device<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device
    -&gt; ../../../vif-0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device
    -&gt; ../../../vif-1<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device
    -&gt; ../../../vif-2<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device
    -&gt; ../../../vif-3<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device
    -&gt; ../../../vif-4<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device
    -&gt; ../../../vif-5<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device
    -&gt; ../../../vif-6<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device
    -&gt; ../../../vif-7<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device
    -&gt; ../../../vif-8<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device
    -&gt; ../../../vif-9<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic0/device -&gt; ../../../0000:00:04.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic1/device -&gt; ../../../0000:00:05.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic2/device -&gt; ../../../0000:00:06.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic3/device -&gt; ../../../0000:00:07.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic4/device -&gt; ../../../0000:00:08.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic5/device -&gt; ../../../0000:00:09.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic6/device -&gt; ../../../0000:00:0a.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic7/device -&gt; ../../../0000:00:0b.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic8/device -&gt; ../../../0000:00:0c.0<br>
    lrwxrwxrwx. 1 root root 0 Dec 19 17:21
    /sys/class/net/pci-nic9/device -&gt; ../../../0000:00:0d.0<br>
    <br>
    <br>
    &nbsp;&nbsp; -Don Slutz<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 12/19/14 07:04, Singhal, Upanshu
      wrote:<br>
    </div>
    <blockquote
cite="mid:6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="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;}
/* 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="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Hello,<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">In one of my experiment, I am building a
          Linux VM with Network interface model as &#8220;vmxnet3&#8221;. I am able
          to create the VM successfully, but I see that the driver
          loaded is &#8220;vif&#8221; and not &#8220;vmxnet3&#8221;. I am using the following
          option for the network interface: <b>vif = [ 'type=ioemu,
            mac=00:16:3e:00:00:22, bridge=xenbr0, model=vmxnet3' ]<o:p></o:p></b></p>
        <p class="MsoNormal"><b><o:p>&nbsp;</o:p></b></p>
        <p class="MsoNormal">I tried with model as e1000 and it works
          fine. Lspci command also does not show vmxnet3. Though, qemu
          device help shows that &#8220;vmxnet3&#8221; is supported on XEN 4.4.1
          version I am using.
          <o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">I tried searching on internet about the
          right configuration for vmxnet3 with XEN, but not able to find
          right information. Can someone please help me on how to create
          a VM with vmxnet3?<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">This experiment I am doing to compare the
          difference between vmxnet3 bandwidth on VMWARE ESXi vs. XEN
          Server. My sample VM configuration file is:<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># This configures an HVM rather than PV
          guest<o:p></o:p></p>
        <p class="MsoNormal">builder = "hvm"<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Guest name<o:p></o:p></p>
        <p class="MsoNormal"><b>name = "rhel-vmxnet3-xen-2.hvm"<o:p></o:p></b></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># 128-bit UUID for the domain as a
          hexadecimal number.<o:p></o:p></p>
        <p class="MsoNormal"># Use "uuidgen" to generate one if
          required.<o:p></o:p></p>
        <p class="MsoNormal"># The default behavior is to generate a new
          UUID each time the guest is started.<o:p></o:p></p>
        <p class="MsoNormal">#uuid =
          "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Enable Microsoft Hyper-V compatibile
          paravirtualisation /<o:p></o:p></p>
        <p class="MsoNormal"># enlightenment interfaces. Turning this on
          can improve Windows guest<o:p></o:p></p>
        <p class="MsoNormal"># performance and is therefore recommended<o:p></o:p></p>
        <p class="MsoNormal">#viridian = 1<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Initial memory allocation (MB)<o:p></o:p></p>
        <p class="MsoNormal"><b>memory = 8192<o:p></o:p></b></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Maximum memory (MB)<o:p></o:p></p>
        <p class="MsoNormal"># If this is greater than `memory' then the
          slack will start ballooned<o:p></o:p></p>
        <p class="MsoNormal"># (this assumes guest kernel support for
          ballooning)<o:p></o:p></p>
        <p class="MsoNormal">#maxmem = 512<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Number of VCPUS<o:p></o:p></p>
        <p class="MsoNormal"><b>vcpus = 8<o:p></o:p></b></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Network devices<o:p></o:p></p>
        <p class="MsoNormal"># A list of 'vifspec' entries as described
          in<o:p></o:p></p>
        <p class="MsoNormal">#
          docs/misc/xl-network-configuration.markdown<o:p></o:p></p>
        <p class="MsoNormal">vif = [ 'type=ioemu, mac=00:16:3e:00:00:22,
          bridge=xenbr1, model=vmxnet3' ]<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Disk Devices<o:p></o:p></p>
        <p class="MsoNormal"># A list of `diskspec' entries as described
          in<o:p></o:p></p>
        <p class="MsoNormal"># docs/misc/xl-disk-configuration.txt<o:p></o:p></p>
        <p class="MsoNormal"><b>disk = [
            '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw',
            '<a class="moz-txt-link-freetext" href="file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r">file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r</a>' ]<o:p></o:p></b></p>
        <p class="MsoNormal"><b>boot='cd'</b><o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"># Guest VGA console configuration, either
          SDL or VNC<o:p></o:p></p>
        <p class="MsoNormal"># sdl = 1<o:p></o:p></p>
        <p class="MsoNormal"><b>vnc = 2<o:p></o:p></b></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">Thanks,<o:p></o:p></p>
        <p class="MsoNormal">-Upanshu<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">Upanshu Singhal<o:p></o:p></p>
        <p class="MsoNormal">EMC Data Storage Systems, Bangalore, India.<o:p></o:p></p>
        <p class="MsoNormal">Phone: 91-80-67375604<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
      </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>

--------------060500040305090505010900--


--===============1841490096756511426==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1841490096756511426==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 22:31:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 22:31:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y265L-0008W2-R3; Fri, 19 Dec 2014 22:31:47 +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 1Y265J-0008Vs-Sn
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 22:31:46 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	8D/D4-02743-157A4945; Fri, 19 Dec 2014 22:31:45 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1419028302!16282220!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13382 invoked from network); 19 Dec 2014 22:31:43 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 22:31:43 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1419028303; x=1450564303;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to;
	bh=vsH4MNb6Jk/5OQqLGCCn6DRz/V8zyMSVpCISAFhGmJE=;
	b=Om1y3c35/efvik7tTlgKbKQG8H1rKYAsssRYRv01xOjp35I9tDp/nBTA
	sppPIsKrBeKbhu7/w8Es0bgH2/hmOp+Jd/AcWPR7H7d/6HwXhaw7DHsVU
	n9nQDfBSmvkqEPxugqgBBKl8VwLI3ryHNuo72bZcE5fgXCZ1hG23s8j6Z U=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 19 Dec 2014 22:31:42 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,609,1413244800"; 
	d="scan'208,217";a="898337447"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.111.238])
	by fldsmtpi03.verizon.com with ESMTP; 19 Dec 2014 22:31:42 +0000
Message-ID: <5494A74D.4080606@terremark.com>
Date: Fri, 19 Dec 2014 17:31:41 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Singhal, Upanshu" <upanshu.singhal@emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
	<5494A6AF.1030802@terremark.com>
In-Reply-To: <5494A6AF.1030802@terremark.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2439906420866236090=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2439906420866236090==
Content-Type: multipart/alternative;
 boundary="------------010507060502040903040604"

This is a multi-part message in MIME format.
--------------010507060502040903040604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

P.S. here is the vif line I used:

vif = [
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:a0",
  "model=e1000,bridge=xenbr0,mac=00:0c:29:86:44:aa",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:b4",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:be",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:c8",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:d2",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:dc",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:e6",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:f0",
  "model=e1000,bridge=xenbr0,mac=00:0c:29:86:44:fa",
]

    -Don Slutz

On 12/19/14 17:29, Don Slutz wrote:
> xen_emul_unplug=unnecessary (kernel arg) may help you here.
>
> Also udev likes to rename your devices.
>
> Here is a lspci from a guest:
>
>
> [root@C63-min-tools ~]# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device 
> (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
> Ethernet Controller (rev 03)
> 00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
> Ethernet Controller (rev 03)
>
> And to help:
>
> [root@C63-min-tools ~]# ls -l /sys/class/net/*/device
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> 
> ../../../vif-0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> 
> ../../../vif-1
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> 
> ../../../vif-2
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> 
> ../../../vif-3
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> 
> ../../../vif-4
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> 
> ../../../vif-5
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> 
> ../../../vif-6
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> 
> ../../../vif-7
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> 
> ../../../vif-8
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> 
> ../../../vif-9
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device 
> -> ../../../0000:00:04.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device 
> -> ../../../0000:00:05.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device 
> -> ../../../0000:00:06.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device 
> -> ../../../0000:00:07.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device 
> -> ../../../0000:00:08.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device 
> -> ../../../0000:00:09.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device 
> -> ../../../0000:00:0a.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device 
> -> ../../../0000:00:0b.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device 
> -> ../../../0000:00:0c.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device 
> -> ../../../0000:00:0d.0
>
>
>    -Don Slutz
>
>
> On 12/19/14 07:04, Singhal, Upanshu wrote:
>>
>> Hello,
>>
>> In one of my experiment, I am building a Linux VM with Network 
>> interface model as "vmxnet3". I am able to create the VM 
>> successfully, but I see that the driver loaded is "vif" and not 
>> "vmxnet3". I am using the following option for the network interface: 
>> *vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0, 
>> model=vmxnet3' ]*
>>
>> **
>>
>> I tried with model as e1000 and it works fine. Lspci command also 
>> does not show vmxnet3. Though, qemu device help shows that "vmxnet3" 
>> is supported on XEN 4.4.1 version I am using.
>>
>> I tried searching on internet about the right configuration for 
>> vmxnet3 with XEN, but not able to find right information. Can someone 
>> please help me on how to create a VM with vmxnet3?
>>
>> This experiment I am doing to compare the difference between vmxnet3 
>> bandwidth on VMWARE ESXi vs. XEN Server. My sample VM configuration 
>> file is:
>>
>> # This configures an HVM rather than PV guest
>>
>> builder = "hvm"
>>
>> # Guest name
>>
>> *name = "rhel-vmxnet3-xen-2.hvm"*
>>
>> # 128-bit UUID for the domain as a hexadecimal number.
>>
>> # Use "uuidgen" to generate one if required.
>>
>> # The default behavior is to generate a new UUID each time the guest 
>> is started.
>>
>> #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
>>
>> # Enable Microsoft Hyper-V compatibile paravirtualisation /
>>
>> # enlightenment interfaces. Turning this on can improve Windows guest
>>
>> # performance and is therefore recommended
>>
>> #viridian = 1
>>
>> # Initial memory allocation (MB)
>>
>> *memory = 8192*
>>
>> # Maximum memory (MB)
>>
>> # If this is greater than `memory' then the slack will start ballooned
>>
>> # (this assumes guest kernel support for ballooning)
>>
>> #maxmem = 512
>>
>> # Number of VCPUS
>>
>> *vcpus = 8*
>>
>> # Network devices
>>
>> # A list of 'vifspec' entries as described in
>>
>> # docs/misc/xl-network-configuration.markdown
>>
>> vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr1, 
>> model=vmxnet3' ]
>>
>> # Disk Devices
>>
>> # A list of `diskspec' entries as described in
>>
>> # docs/misc/xl-disk-configuration.txt
>>
>> *disk = [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', 
>> 'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r' ]*
>>
>> *boot='cd'*
>>
>> # Guest VGA console configuration, either SDL or VNC
>>
>> # sdl = 1
>>
>> *vnc = 2*
>>
>> Thanks,
>>
>> -Upanshu
>>
>> Upanshu Singhal
>>
>> EMC Data Storage Systems, Bangalore, India.
>>
>> Phone: 91-80-67375604
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>


--------------010507060502040903040604
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">
    P.S. here is the vif line I used:<br>
    <br>
    vif = [<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:a0",<br>
    &nbsp;"model=e1000,bridge=xenbr0,mac=00:0c:29:86:44:aa",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:b4",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:be",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:c8",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:d2",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:dc",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:e6",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:f0",<br>
    &nbsp;"model=e1000,bridge=xenbr0,mac=00:0c:29:86:44:fa",<br>
    ]<br>
    <br>
    &nbsp;&nbsp; -Don Slutz<br>
    <br>
    <div class="moz-cite-prefix">On 12/19/14 17:29, Don Slutz wrote:<br>
    </div>
    <blockquote cite="mid:5494A6AF.1030802@terremark.com" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      xen_emul_unplug=unnecessary (kernel arg) may help you here.<br>
      <br>
      Also udev likes to rename your devices.<br>
      <br>
      Here is a lspci from a guest:<br>
      <br>
      <br>
      [root@C63-min-tools ~]# lspci<br>
      00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC
      [Natoma] (rev 02)<br>
      00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA
      [Natoma/Triton II]<br>
      00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
      [Natoma/Triton II]<br>
      00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev
      03)<br>
      00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform
      Device (rev 01)<br>
      00:03.0 VGA compatible controller: Cirrus Logic GD 5446<br>
      00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit
      Ethernet Controller (rev 03)<br>
      00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit
      Ethernet Controller (rev 03)<br>
      <br>
      And to help:<br>
      <br>
      [root@C63-min-tools ~]# ls -l /sys/class/net/*/device<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device
      -&gt; ../../../vif-0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device
      -&gt; ../../../vif-1<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device
      -&gt; ../../../vif-2<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device
      -&gt; ../../../vif-3<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device
      -&gt; ../../../vif-4<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device
      -&gt; ../../../vif-5<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device
      -&gt; ../../../vif-6<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device
      -&gt; ../../../vif-7<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device
      -&gt; ../../../vif-8<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device
      -&gt; ../../../vif-9<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic0/device -&gt; ../../../0000:00:04.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic1/device -&gt; ../../../0000:00:05.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic2/device -&gt; ../../../0000:00:06.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic3/device -&gt; ../../../0000:00:07.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic4/device -&gt; ../../../0000:00:08.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic5/device -&gt; ../../../0000:00:09.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic6/device -&gt; ../../../0000:00:0a.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic7/device -&gt; ../../../0000:00:0b.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic8/device -&gt; ../../../0000:00:0c.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic9/device -&gt; ../../../0000:00:0d.0<br>
      <br>
      <br>
      &nbsp;&nbsp; -Don Slutz<br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 12/19/14 07:04, Singhal, Upanshu
        wrote:<br>
      </div>
      <blockquote
cite="mid:6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com"
        type="cite">
        <meta name="Generator" content="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;}
/* 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="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
        <div class="WordSection1">
          <p class="MsoNormal">Hello,<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">In one of my experiment, I am building a
            Linux VM with Network interface model as &#8220;vmxnet3&#8221;. I am
            able to create the VM successfully, but I see that the
            driver loaded is &#8220;vif&#8221; and not &#8220;vmxnet3&#8221;. I am using the
            following option for the network interface: <b>vif = [
              'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0,
              model=vmxnet3' ]<o:p></o:p></b></p>
          <p class="MsoNormal"><b><o:p>&nbsp;</o:p></b></p>
          <p class="MsoNormal">I tried with model as e1000 and it works
            fine. Lspci command also does not show vmxnet3. Though, qemu
            device help shows that &#8220;vmxnet3&#8221; is supported on XEN 4.4.1
            version I am using. <o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">I tried searching on internet about the
            right configuration for vmxnet3 with XEN, but not able to
            find right information. Can someone please help me on how to
            create a VM with vmxnet3?<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">This experiment I am doing to compare the
            difference between vmxnet3 bandwidth on VMWARE ESXi vs. XEN
            Server. My sample VM configuration file is:<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># This configures an HVM rather than PV
            guest<o:p></o:p></p>
          <p class="MsoNormal">builder = "hvm"<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Guest name<o:p></o:p></p>
          <p class="MsoNormal"><b>name = "rhel-vmxnet3-xen-2.hvm"<o:p></o:p></b></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># 128-bit UUID for the domain as a
            hexadecimal number.<o:p></o:p></p>
          <p class="MsoNormal"># Use "uuidgen" to generate one if
            required.<o:p></o:p></p>
          <p class="MsoNormal"># The default behavior is to generate a
            new UUID each time the guest is started.<o:p></o:p></p>
          <p class="MsoNormal">#uuid =
            "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Enable Microsoft Hyper-V compatibile
            paravirtualisation /<o:p></o:p></p>
          <p class="MsoNormal"># enlightenment interfaces. Turning this
            on can improve Windows guest<o:p></o:p></p>
          <p class="MsoNormal"># performance and is therefore
            recommended<o:p></o:p></p>
          <p class="MsoNormal">#viridian = 1<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Initial memory allocation (MB)<o:p></o:p></p>
          <p class="MsoNormal"><b>memory = 8192<o:p></o:p></b></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Maximum memory (MB)<o:p></o:p></p>
          <p class="MsoNormal"># If this is greater than `memory' then
            the slack will start ballooned<o:p></o:p></p>
          <p class="MsoNormal"># (this assumes guest kernel support for
            ballooning)<o:p></o:p></p>
          <p class="MsoNormal">#maxmem = 512<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Number of VCPUS<o:p></o:p></p>
          <p class="MsoNormal"><b>vcpus = 8<o:p></o:p></b></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Network devices<o:p></o:p></p>
          <p class="MsoNormal"># A list of 'vifspec' entries as
            described in<o:p></o:p></p>
          <p class="MsoNormal">#
            docs/misc/xl-network-configuration.markdown<o:p></o:p></p>
          <p class="MsoNormal">vif = [ 'type=ioemu,
            mac=00:16:3e:00:00:22, bridge=xenbr1, model=vmxnet3' ]<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Disk Devices<o:p></o:p></p>
          <p class="MsoNormal"># A list of `diskspec' entries as
            described in<o:p></o:p></p>
          <p class="MsoNormal"># docs/misc/xl-disk-configuration.txt<o:p></o:p></p>
          <p class="MsoNormal"><b>disk = [
              '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', '<a
                moz-do-not-send="true" class="moz-txt-link-freetext"
                href="file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r">file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r</a>'
              ]<o:p></o:p></b></p>
          <p class="MsoNormal"><b>boot='cd'</b><o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Guest VGA console configuration, either
            SDL or VNC<o:p></o:p></p>
          <p class="MsoNormal"># sdl = 1<o:p></o:p></p>
          <p class="MsoNormal"><b>vnc = 2<o:p></o:p></b></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">Thanks,<o:p></o:p></p>
          <p class="MsoNormal">-Upanshu<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">Upanshu Singhal<o:p></o:p></p>
          <p class="MsoNormal">EMC Data Storage Systems, Bangalore,
            India.<o:p></o:p></p>
          <p class="MsoNormal">Phone: 91-80-67375604<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Xen-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------010507060502040903040604--


--===============2439906420866236090==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2439906420866236090==--


From xen-devel-bounces@lists.xen.org Fri Dec 19 22:31:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Dec 2014 22:31:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y265L-0008W2-R3; Fri, 19 Dec 2014 22:31:47 +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 1Y265J-0008Vs-Sn
	for xen-devel@lists.xen.org; Fri, 19 Dec 2014 22:31:46 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	8D/D4-02743-157A4945; Fri, 19 Dec 2014 22:31:45 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1419028302!16282220!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13382 invoked from network); 19 Dec 2014 22:31:43 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Dec 2014 22:31:43 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1419028303; x=1450564303;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to;
	bh=vsH4MNb6Jk/5OQqLGCCn6DRz/V8zyMSVpCISAFhGmJE=;
	b=Om1y3c35/efvik7tTlgKbKQG8H1rKYAsssRYRv01xOjp35I9tDp/nBTA
	sppPIsKrBeKbhu7/w8Es0bgH2/hmOp+Jd/AcWPR7H7d/6HwXhaw7DHsVU
	n9nQDfBSmvkqEPxugqgBBKl8VwLI3ryHNuo72bZcE5fgXCZ1hG23s8j6Z U=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 19 Dec 2014 22:31:42 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,609,1413244800"; 
	d="scan'208,217";a="898337447"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.111.238])
	by fldsmtpi03.verizon.com with ESMTP; 19 Dec 2014 22:31:42 +0000
Message-ID: <5494A74D.4080606@terremark.com>
Date: Fri, 19 Dec 2014 17:31:41 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Singhal, Upanshu" <upanshu.singhal@emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
	<5494A6AF.1030802@terremark.com>
In-Reply-To: <5494A6AF.1030802@terremark.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2439906420866236090=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2439906420866236090==
Content-Type: multipart/alternative;
 boundary="------------010507060502040903040604"

This is a multi-part message in MIME format.
--------------010507060502040903040604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

P.S. here is the vif line I used:

vif = [
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:a0",
  "model=e1000,bridge=xenbr0,mac=00:0c:29:86:44:aa",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:b4",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:be",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:c8",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:d2",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:dc",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:e6",
  "model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:f0",
  "model=e1000,bridge=xenbr0,mac=00:0c:29:86:44:fa",
]

    -Don Slutz

On 12/19/14 17:29, Don Slutz wrote:
> xen_emul_unplug=unnecessary (kernel arg) may help you here.
>
> Also udev likes to rename your devices.
>
> Here is a lspci from a guest:
>
>
> [root@C63-min-tools ~]# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device 
> (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
> Ethernet Controller (rev 03)
> 00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
> Ethernet Controller (rev 03)
>
> And to help:
>
> [root@C63-min-tools ~]# ls -l /sys/class/net/*/device
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> 
> ../../../vif-0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> 
> ../../../vif-1
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> 
> ../../../vif-2
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> 
> ../../../vif-3
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> 
> ../../../vif-4
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> 
> ../../../vif-5
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> 
> ../../../vif-6
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> 
> ../../../vif-7
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> 
> ../../../vif-8
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> 
> ../../../vif-9
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device 
> -> ../../../0000:00:04.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device 
> -> ../../../0000:00:05.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device 
> -> ../../../0000:00:06.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device 
> -> ../../../0000:00:07.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device 
> -> ../../../0000:00:08.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device 
> -> ../../../0000:00:09.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device 
> -> ../../../0000:00:0a.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device 
> -> ../../../0000:00:0b.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device 
> -> ../../../0000:00:0c.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device 
> -> ../../../0000:00:0d.0
>
>
>    -Don Slutz
>
>
> On 12/19/14 07:04, Singhal, Upanshu wrote:
>>
>> Hello,
>>
>> In one of my experiment, I am building a Linux VM with Network 
>> interface model as "vmxnet3". I am able to create the VM 
>> successfully, but I see that the driver loaded is "vif" and not 
>> "vmxnet3". I am using the following option for the network interface: 
>> *vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0, 
>> model=vmxnet3' ]*
>>
>> **
>>
>> I tried with model as e1000 and it works fine. Lspci command also 
>> does not show vmxnet3. Though, qemu device help shows that "vmxnet3" 
>> is supported on XEN 4.4.1 version I am using.
>>
>> I tried searching on internet about the right configuration for 
>> vmxnet3 with XEN, but not able to find right information. Can someone 
>> please help me on how to create a VM with vmxnet3?
>>
>> This experiment I am doing to compare the difference between vmxnet3 
>> bandwidth on VMWARE ESXi vs. XEN Server. My sample VM configuration 
>> file is:
>>
>> # This configures an HVM rather than PV guest
>>
>> builder = "hvm"
>>
>> # Guest name
>>
>> *name = "rhel-vmxnet3-xen-2.hvm"*
>>
>> # 128-bit UUID for the domain as a hexadecimal number.
>>
>> # Use "uuidgen" to generate one if required.
>>
>> # The default behavior is to generate a new UUID each time the guest 
>> is started.
>>
>> #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
>>
>> # Enable Microsoft Hyper-V compatibile paravirtualisation /
>>
>> # enlightenment interfaces. Turning this on can improve Windows guest
>>
>> # performance and is therefore recommended
>>
>> #viridian = 1
>>
>> # Initial memory allocation (MB)
>>
>> *memory = 8192*
>>
>> # Maximum memory (MB)
>>
>> # If this is greater than `memory' then the slack will start ballooned
>>
>> # (this assumes guest kernel support for ballooning)
>>
>> #maxmem = 512
>>
>> # Number of VCPUS
>>
>> *vcpus = 8*
>>
>> # Network devices
>>
>> # A list of 'vifspec' entries as described in
>>
>> # docs/misc/xl-network-configuration.markdown
>>
>> vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr1, 
>> model=vmxnet3' ]
>>
>> # Disk Devices
>>
>> # A list of `diskspec' entries as described in
>>
>> # docs/misc/xl-disk-configuration.txt
>>
>> *disk = [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', 
>> 'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r' ]*
>>
>> *boot='cd'*
>>
>> # Guest VGA console configuration, either SDL or VNC
>>
>> # sdl = 1
>>
>> *vnc = 2*
>>
>> Thanks,
>>
>> -Upanshu
>>
>> Upanshu Singhal
>>
>> EMC Data Storage Systems, Bangalore, India.
>>
>> Phone: 91-80-67375604
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>


--------------010507060502040903040604
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">
    P.S. here is the vif line I used:<br>
    <br>
    vif = [<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:a0",<br>
    &nbsp;"model=e1000,bridge=xenbr0,mac=00:0c:29:86:44:aa",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:b4",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:be",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:c8",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:d2",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:dc",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:e6",<br>
    &nbsp;"model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:f0",<br>
    &nbsp;"model=e1000,bridge=xenbr0,mac=00:0c:29:86:44:fa",<br>
    ]<br>
    <br>
    &nbsp;&nbsp; -Don Slutz<br>
    <br>
    <div class="moz-cite-prefix">On 12/19/14 17:29, Don Slutz wrote:<br>
    </div>
    <blockquote cite="mid:5494A6AF.1030802@terremark.com" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      xen_emul_unplug=unnecessary (kernel arg) may help you here.<br>
      <br>
      Also udev likes to rename your devices.<br>
      <br>
      Here is a lspci from a guest:<br>
      <br>
      <br>
      [root@C63-min-tools ~]# lspci<br>
      00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC
      [Natoma] (rev 02)<br>
      00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA
      [Natoma/Triton II]<br>
      00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
      [Natoma/Triton II]<br>
      00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev
      03)<br>
      00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform
      Device (rev 01)<br>
      00:03.0 VGA compatible controller: Cirrus Logic GD 5446<br>
      00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit
      Ethernet Controller (rev 03)<br>
      00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller
      (rev 01)<br>
      00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit
      Ethernet Controller (rev 03)<br>
      <br>
      And to help:<br>
      <br>
      [root@C63-min-tools ~]# ls -l /sys/class/net/*/device<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device
      -&gt; ../../../vif-0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device
      -&gt; ../../../vif-1<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device
      -&gt; ../../../vif-2<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device
      -&gt; ../../../vif-3<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device
      -&gt; ../../../vif-4<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device
      -&gt; ../../../vif-5<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device
      -&gt; ../../../vif-6<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device
      -&gt; ../../../vif-7<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device
      -&gt; ../../../vif-8<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device
      -&gt; ../../../vif-9<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic0/device -&gt; ../../../0000:00:04.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic1/device -&gt; ../../../0000:00:05.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic2/device -&gt; ../../../0000:00:06.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic3/device -&gt; ../../../0000:00:07.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic4/device -&gt; ../../../0000:00:08.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic5/device -&gt; ../../../0000:00:09.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic6/device -&gt; ../../../0000:00:0a.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic7/device -&gt; ../../../0000:00:0b.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic8/device -&gt; ../../../0000:00:0c.0<br>
      lrwxrwxrwx. 1 root root 0 Dec 19 17:21
      /sys/class/net/pci-nic9/device -&gt; ../../../0000:00:0d.0<br>
      <br>
      <br>
      &nbsp;&nbsp; -Don Slutz<br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 12/19/14 07:04, Singhal, Upanshu
        wrote:<br>
      </div>
      <blockquote
cite="mid:6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com"
        type="cite">
        <meta name="Generator" content="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;}
/* 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="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
        <div class="WordSection1">
          <p class="MsoNormal">Hello,<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">In one of my experiment, I am building a
            Linux VM with Network interface model as &#8220;vmxnet3&#8221;. I am
            able to create the VM successfully, but I see that the
            driver loaded is &#8220;vif&#8221; and not &#8220;vmxnet3&#8221;. I am using the
            following option for the network interface: <b>vif = [
              'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0,
              model=vmxnet3' ]<o:p></o:p></b></p>
          <p class="MsoNormal"><b><o:p>&nbsp;</o:p></b></p>
          <p class="MsoNormal">I tried with model as e1000 and it works
            fine. Lspci command also does not show vmxnet3. Though, qemu
            device help shows that &#8220;vmxnet3&#8221; is supported on XEN 4.4.1
            version I am using. <o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">I tried searching on internet about the
            right configuration for vmxnet3 with XEN, but not able to
            find right information. Can someone please help me on how to
            create a VM with vmxnet3?<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">This experiment I am doing to compare the
            difference between vmxnet3 bandwidth on VMWARE ESXi vs. XEN
            Server. My sample VM configuration file is:<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># This configures an HVM rather than PV
            guest<o:p></o:p></p>
          <p class="MsoNormal">builder = "hvm"<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Guest name<o:p></o:p></p>
          <p class="MsoNormal"><b>name = "rhel-vmxnet3-xen-2.hvm"<o:p></o:p></b></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># 128-bit UUID for the domain as a
            hexadecimal number.<o:p></o:p></p>
          <p class="MsoNormal"># Use "uuidgen" to generate one if
            required.<o:p></o:p></p>
          <p class="MsoNormal"># The default behavior is to generate a
            new UUID each time the guest is started.<o:p></o:p></p>
          <p class="MsoNormal">#uuid =
            "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Enable Microsoft Hyper-V compatibile
            paravirtualisation /<o:p></o:p></p>
          <p class="MsoNormal"># enlightenment interfaces. Turning this
            on can improve Windows guest<o:p></o:p></p>
          <p class="MsoNormal"># performance and is therefore
            recommended<o:p></o:p></p>
          <p class="MsoNormal">#viridian = 1<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Initial memory allocation (MB)<o:p></o:p></p>
          <p class="MsoNormal"><b>memory = 8192<o:p></o:p></b></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Maximum memory (MB)<o:p></o:p></p>
          <p class="MsoNormal"># If this is greater than `memory' then
            the slack will start ballooned<o:p></o:p></p>
          <p class="MsoNormal"># (this assumes guest kernel support for
            ballooning)<o:p></o:p></p>
          <p class="MsoNormal">#maxmem = 512<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Number of VCPUS<o:p></o:p></p>
          <p class="MsoNormal"><b>vcpus = 8<o:p></o:p></b></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Network devices<o:p></o:p></p>
          <p class="MsoNormal"># A list of 'vifspec' entries as
            described in<o:p></o:p></p>
          <p class="MsoNormal">#
            docs/misc/xl-network-configuration.markdown<o:p></o:p></p>
          <p class="MsoNormal">vif = [ 'type=ioemu,
            mac=00:16:3e:00:00:22, bridge=xenbr1, model=vmxnet3' ]<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Disk Devices<o:p></o:p></p>
          <p class="MsoNormal"># A list of `diskspec' entries as
            described in<o:p></o:p></p>
          <p class="MsoNormal"># docs/misc/xl-disk-configuration.txt<o:p></o:p></p>
          <p class="MsoNormal"><b>disk = [
              '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', '<a
                moz-do-not-send="true" class="moz-txt-link-freetext"
                href="file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r">file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r</a>'
              ]<o:p></o:p></b></p>
          <p class="MsoNormal"><b>boot='cd'</b><o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"># Guest VGA console configuration, either
            SDL or VNC<o:p></o:p></p>
          <p class="MsoNormal"># sdl = 1<o:p></o:p></p>
          <p class="MsoNormal"><b>vnc = 2<o:p></o:p></b></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">Thanks,<o:p></o:p></p>
          <p class="MsoNormal">-Upanshu<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">Upanshu Singhal<o:p></o:p></p>
          <p class="MsoNormal">EMC Data Storage Systems, Bangalore,
            India.<o:p></o:p></p>
          <p class="MsoNormal">Phone: 91-80-67375604<o:p></o:p></p>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Xen-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
</pre>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------010507060502040903040604--


--===============2439906420866236090==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2439906420866236090==--


From xen-devel-bounces@lists.xen.org Sat Dec 20 00:24:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 00: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 1Y27q2-0004f9-W3; Sat, 20 Dec 2014 00:24:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y27pz-0004f4-BK
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 00:24:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D9/41-15461-2A1C4945; Sat, 20 Dec 2014 00:24:02 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-5.tower-21.messagelabs.com!1419035039!16854513!1
X-Originating-IP: [209.40.204.226]
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 28932 invoked from network); 20 Dec 2014 00:24:01 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 00:24:01 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y27pr-0002S4-68; Sat, 20 Dec 2014 11:23:55 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y27pZ-0008MR-Ji; Sat, 20 Dec 2014 11:23:37 +1100
Date: Sat, 20 Dec 2014 11:23:27 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141220002327.GA31975@gondor.apana.org.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418756386-6940-1-git-send-email-david.vrabel@citrix.com>
Organization: Core
X-Newsgroups: apana.lists.os.linux.netdev
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netdev@vger.kernel.org, edumazet@google.com, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	"David S. Miller" <davem@davemloft.net>
Subject: [Xen-devel] virtio_net: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

David Vrabel <david.vrabel@citrix.com> wrote:
> After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
> masking in NAPI) the napi instance is removed from the per-cpu list
> prior to calling the n->poll(), and is only requeued if all of the
> budget was used.  This inadvertently broke netfront because netfront
> does not use NAPI correctly.

A similar bug exists in virtio_net.

-- >8 --
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) breaks virtio_net in an insidious way.

It is now required that if the entire budget is consumed when poll
returns, the napi poll_list must remain empty.  However, like some
other drivers virtio_net tries to do a last-ditch check and if
there is more work it will call napi_schedule and then immediately
process some of this new work.  Should the entire budget be consumed
while processing such new work then we will violate the new caller
contract.

This patch fixes this by not touching any work when we reschedule
in virtio_net.

The worst part of this bug is that the list corruption causes other
napi users to be moved off-list.  In my case I was chasing a stall
in IPsec (IPsec uses netif_rx) and I only belatedly realised that it
was virtio_net which caused the stall even though the virtio_net
poll was still functioning perfectly after IPsec stalled.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b8bd719..5ca9771 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -760,7 +760,6 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
 		container_of(napi, struct receive_queue, napi);
 	unsigned int r, received = 0;
 
-again:
 	received += virtnet_receive(rq, budget - received);
 
 	/* Out of packets? */
@@ -771,7 +770,6 @@ again:
 		    napi_schedule_prep(napi)) {
 			virtqueue_disable_cb(rq->vq);
 			__napi_schedule(napi);
-			goto again;
 		}
 	}

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 00:24:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 00: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 1Y27q2-0004f9-W3; Sat, 20 Dec 2014 00:24:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y27pz-0004f4-BK
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 00:24:03 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D9/41-15461-2A1C4945; Sat, 20 Dec 2014 00:24:02 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-5.tower-21.messagelabs.com!1419035039!16854513!1
X-Originating-IP: [209.40.204.226]
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 28932 invoked from network); 20 Dec 2014 00:24:01 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 00:24:01 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y27pr-0002S4-68; Sat, 20 Dec 2014 11:23:55 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y27pZ-0008MR-Ji; Sat, 20 Dec 2014 11:23:37 +1100
Date: Sat, 20 Dec 2014 11:23:27 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141220002327.GA31975@gondor.apana.org.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1418756386-6940-1-git-send-email-david.vrabel@citrix.com>
Organization: Core
X-Newsgroups: apana.lists.os.linux.netdev
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netdev@vger.kernel.org, edumazet@google.com, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	"David S. Miller" <davem@davemloft.net>
Subject: [Xen-devel] virtio_net: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

David Vrabel <david.vrabel@citrix.com> wrote:
> After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
> masking in NAPI) the napi instance is removed from the per-cpu list
> prior to calling the n->poll(), and is only requeued if all of the
> budget was used.  This inadvertently broke netfront because netfront
> does not use NAPI correctly.

A similar bug exists in virtio_net.

-- >8 --
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) breaks virtio_net in an insidious way.

It is now required that if the entire budget is consumed when poll
returns, the napi poll_list must remain empty.  However, like some
other drivers virtio_net tries to do a last-ditch check and if
there is more work it will call napi_schedule and then immediately
process some of this new work.  Should the entire budget be consumed
while processing such new work then we will violate the new caller
contract.

This patch fixes this by not touching any work when we reschedule
in virtio_net.

The worst part of this bug is that the list corruption causes other
napi users to be moved off-list.  In my case I was chasing a stall
in IPsec (IPsec uses netif_rx) and I only belatedly realised that it
was virtio_net which caused the stall even though the virtio_net
poll was still functioning perfectly after IPsec stalled.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b8bd719..5ca9771 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -760,7 +760,6 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
 		container_of(napi, struct receive_queue, napi);
 	unsigned int r, received = 0;
 
-again:
 	received += virtnet_receive(rq, budget - received);
 
 	/* Out of packets? */
@@ -771,7 +770,6 @@ again:
 		    napi_schedule_prep(napi)) {
 			virtqueue_disable_cb(rq->vq);
 			__napi_schedule(napi);
-			goto again;
 		}
 	}

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 00:37:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 00:37:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y282L-00057d-6J; Sat, 20 Dec 2014 00:36:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y282K-00057Y-1Z
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 00:36:48 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	69/DE-02954-F94C4945; Sat, 20 Dec 2014 00:36:47 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-11.tower-27.messagelabs.com!1419035803!12971709!1
X-Originating-IP: [209.40.204.226]
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 29508 invoked from network); 20 Dec 2014 00:36:46 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 00:36:46 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y282C-0002cz-2k; Sat, 20 Dec 2014 11:36:40 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2828-0008Qb-Oa; Sat, 20 Dec 2014 11:36:36 +1100
Date: Sat, 20 Dec 2014 11:36:36 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141220003636.GA32187@gondor.apana.org.au>
References: <1418756386-6940-1-git-send-email-david.vrabel@citrix.com>
	<20141220002327.GA31975@gondor.apana.org.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141220002327.GA31975@gondor.apana.org.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netdev@vger.kernel.org, edumazet@google.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, "David S. Miller" <davem@davemloft.net>
Subject: [Xen-devel] net: Detect drivers that reschedule NAPI and exhaust
	budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Dec 20, 2014 at 11:23:27AM +1100, Herbert Xu wrote:
>
> A similar bug exists in virtio_net.

In order to detect other drivers doing this we should add something
like this.

-- >8 --
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) required drivers to leave poll_list
empty if the entire budget is consumed.

We have already had two broken drivers so let's add a check for
this.
 
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/net/core/dev.c b/net/core/dev.c
index f411c28..88f9725 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4620,7 +4620,11 @@ static void net_rx_action(struct softirq_action *h)
 					 */
 					napi_gro_flush(n, HZ >= 1000);
 				}
-				list_add_tail(&n->poll_list, &repoll);
+				/* Some drivers may have called napi_schedule
+				 * prior to exhausting their budget.
+				 */
+				if (!WARN_ON_ONCE(!list_empty(&n->poll_list)))
+					list_add_tail(&n->poll_list, &repoll);
 			}
 		}
 
Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 00:37:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 00:37:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y282L-00057d-6J; Sat, 20 Dec 2014 00:36:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y282K-00057Y-1Z
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 00:36:48 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	69/DE-02954-F94C4945; Sat, 20 Dec 2014 00:36:47 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-11.tower-27.messagelabs.com!1419035803!12971709!1
X-Originating-IP: [209.40.204.226]
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 29508 invoked from network); 20 Dec 2014 00:36:46 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 00:36:46 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y282C-0002cz-2k; Sat, 20 Dec 2014 11:36:40 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2828-0008Qb-Oa; Sat, 20 Dec 2014 11:36:36 +1100
Date: Sat, 20 Dec 2014 11:36:36 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20141220003636.GA32187@gondor.apana.org.au>
References: <1418756386-6940-1-git-send-email-david.vrabel@citrix.com>
	<20141220002327.GA31975@gondor.apana.org.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141220002327.GA31975@gondor.apana.org.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netdev@vger.kernel.org, edumazet@google.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, "David S. Miller" <davem@davemloft.net>
Subject: [Xen-devel] net: Detect drivers that reschedule NAPI and exhaust
	budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Dec 20, 2014 at 11:23:27AM +1100, Herbert Xu wrote:
>
> A similar bug exists in virtio_net.

In order to detect other drivers doing this we should add something
like this.

-- >8 --
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) required drivers to leave poll_list
empty if the entire budget is consumed.

We have already had two broken drivers so let's add a check for
this.
 
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/net/core/dev.c b/net/core/dev.c
index f411c28..88f9725 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4620,7 +4620,11 @@ static void net_rx_action(struct softirq_action *h)
 					 */
 					napi_gro_flush(n, HZ >= 1000);
 				}
-				list_add_tail(&n->poll_list, &repoll);
+				/* Some drivers may have called napi_schedule
+				 * prior to exhausting their budget.
+				 */
+				if (!WARN_ON_ONCE(!list_empty(&n->poll_list)))
+					list_add_tail(&n->poll_list, &repoll);
 			}
 		}
 
Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 00:51:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 00: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 1Y28G7-0005be-J4; Sat, 20 Dec 2014 00:51:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y28G6-0005bZ-1i
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 00:51:02 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	53/9E-31453-5F7C4945; Sat, 20 Dec 2014 00:51:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1419036659!14427256!1
X-Originating-IP: [66.165.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 13517 invoked from network); 20 Dec 2014 00:51: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;
	20 Dec 2014 00:51:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,610,1413244800"; d="scan'208";a="206946358"
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.210.2; Fri, 19 Dec 2014 19: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 1Y28G1-0007Ah-KF;
	Sat, 20 Dec 2014 00:50:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y28G1-00050T-8x;
	Sat, 20 Dec 2014 00:50:57 +0000
Date: Sat, 20 Dec 2014 00:50:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32491-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] 32491: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32491 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32491/

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. 32431

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start              fail like 32431
 test-amd64-i386-rumpuserxen-i386  8 guest-start                fail like 32431
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32431
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10       fail   like 32431
 test-armhf-armhf-xl           9 guest-start                  fail   like 32431
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32431
 test-amd64-i386-pair  17 guest-migrate/src_host/dst_host fail blocked in 32431
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32431

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-vcpus1 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-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-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-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                cfaa3a95dd2b402599b1d8122dc3107478db8717
baseline version:
 linux                603ba7e41bf5d405aba22294af5d075d8898176d

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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 20 00:51:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 00: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 1Y28G7-0005be-J4; Sat, 20 Dec 2014 00:51:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y28G6-0005bZ-1i
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 00:51:02 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	53/9E-31453-5F7C4945; Sat, 20 Dec 2014 00:51:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1419036659!14427256!1
X-Originating-IP: [66.165.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 13517 invoked from network); 20 Dec 2014 00:51: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;
	20 Dec 2014 00:51:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,610,1413244800"; d="scan'208";a="206946358"
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.210.2; Fri, 19 Dec 2014 19: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 1Y28G1-0007Ah-KF;
	Sat, 20 Dec 2014 00:50:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y28G1-00050T-8x;
	Sat, 20 Dec 2014 00:50:57 +0000
Date: Sat, 20 Dec 2014 00:50:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32491-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] 32491: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32491 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32491/

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. 32431

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start              fail like 32431
 test-amd64-i386-rumpuserxen-i386  8 guest-start                fail like 32431
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32431
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10       fail   like 32431
 test-armhf-armhf-xl           9 guest-start                  fail   like 32431
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32431
 test-amd64-i386-pair  17 guest-migrate/src_host/dst_host fail blocked in 32431
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32431

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-vcpus1 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-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-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-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                cfaa3a95dd2b402599b1d8122dc3107478db8717
baseline version:
 linux                603ba7e41bf5d405aba22294af5d075d8898176d

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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 20 01:35:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 01:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y28wX-0002wb-CC; Sat, 20 Dec 2014 01:34:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Y28wW-0002wW-LC
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 01:34:52 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	FF/79-25714-B32D4945; Sat, 20 Dec 2014 01:34:51 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1419039290!10310574!1
X-Originating-IP: [209.85.213.171]
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 31358 invoked from network); 20 Dec 2014 01:34:51 -0000
Received: from mail-ig0-f171.google.com (HELO mail-ig0-f171.google.com)
	(209.85.213.171)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2014 01:34:51 -0000
Received: by mail-ig0-f171.google.com with SMTP id z20so1581657igj.16
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 17:34:50 -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=gSP71MX5VxOuY630GQPd6wqFYZ6cuk2EWGG2yjoLK7M=;
	b=jzCk4EUKzMoS4SKtpqsGmti4QtqQDlBfVekQfcr0c/7+ZXnNwjw2A2dUx3sFsP/tRB
	/MHq05fmEKnlx3KjLwb2PDS1I+kC+jR6uNKkcNtDl98GGSLAYy97qVKSkI1Y4nZYS4iv
	f4qWjAJJOp5+tJsr3BqCF5m+oRdh9ndJJNimzRoUgepK2n1Q/DObmrFK+ujGw7EPmHqf
	4qmPUE8btDFsVfIvoHobfCO/EHDq2n2iKRDEio1mpQpSYsUr1BEPcXcL/BShcZF2j792
	c9Uyhr5Yk/+8xa2oMIHbS3HIJfQHlbkSM+mBt5vHWjdSik4NuYG4Ox8vD7/n5tv017QM
	feXg==
X-Received: by 10.107.30.204 with SMTP id e195mr10437112ioe.28.1419039290242; 
	Fri, 19 Dec 2014 17:34:50 -0800 (PST)
Received: from [172.26.51.187] ([172.26.51.187])
	by mx.google.com with ESMTPSA id sd6sm1684993igb.4.2014.12.19.17.34.48
	(version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128);
	Fri, 19 Dec 2014 17:34:49 -0800 (PST)
Message-ID: <1419039288.11185.4.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 19 Dec 2014 17:34:48 -0800
In-Reply-To: <20141220003636.GA32187@gondor.apana.org.au>
References: <1418756386-6940-1-git-send-email-david.vrabel@citrix.com>
	<20141220002327.GA31975@gondor.apana.org.au>
	<20141220003636.GA32187@gondor.apana.org.au>
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, edumazet@google.com,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] net: Detect drivers that reschedule NAPI and
	exhaust budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-20 at 11:36 +1100, Herbert Xu wrote:
> On Sat, Dec 20, 2014 at 11:23:27AM +1100, Herbert Xu wrote:
> >
> > A similar bug exists in virtio_net.
> 
> In order to detect other drivers doing this we should add something
> like this.
> 
> -- >8 --
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) required drivers to leave poll_list
> empty if the entire budget is consumed.
> 
> We have already had two broken drivers so let's add a check for
> this.
>  
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index f411c28..88f9725 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4620,7 +4620,11 @@ static void net_rx_action(struct softirq_action *h)
>  					 */
>  					napi_gro_flush(n, HZ >= 1000);
>  				}
> -				list_add_tail(&n->poll_list, &repoll);
> +				/* Some drivers may have called napi_schedule
> +				 * prior to exhausting their budget.
> +				 */
> +				if (!WARN_ON_ONCE(!list_empty(&n->poll_list)))
> +					list_add_tail(&n->poll_list, &repoll);
>  			}
>  		}
>  

I do not think stack trace will point to the buggy driver ?

IMO it would be better to print a single line with the netdev name ?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 01:35:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 01:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y28wX-0002wb-CC; Sat, 20 Dec 2014 01:34:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Y28wW-0002wW-LC
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 01:34:52 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	FF/79-25714-B32D4945; Sat, 20 Dec 2014 01:34:51 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1419039290!10310574!1
X-Originating-IP: [209.85.213.171]
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 31358 invoked from network); 20 Dec 2014 01:34:51 -0000
Received: from mail-ig0-f171.google.com (HELO mail-ig0-f171.google.com)
	(209.85.213.171)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2014 01:34:51 -0000
Received: by mail-ig0-f171.google.com with SMTP id z20so1581657igj.16
	for <xen-devel@lists.xenproject.org>;
	Fri, 19 Dec 2014 17:34:50 -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=gSP71MX5VxOuY630GQPd6wqFYZ6cuk2EWGG2yjoLK7M=;
	b=jzCk4EUKzMoS4SKtpqsGmti4QtqQDlBfVekQfcr0c/7+ZXnNwjw2A2dUx3sFsP/tRB
	/MHq05fmEKnlx3KjLwb2PDS1I+kC+jR6uNKkcNtDl98GGSLAYy97qVKSkI1Y4nZYS4iv
	f4qWjAJJOp5+tJsr3BqCF5m+oRdh9ndJJNimzRoUgepK2n1Q/DObmrFK+ujGw7EPmHqf
	4qmPUE8btDFsVfIvoHobfCO/EHDq2n2iKRDEio1mpQpSYsUr1BEPcXcL/BShcZF2j792
	c9Uyhr5Yk/+8xa2oMIHbS3HIJfQHlbkSM+mBt5vHWjdSik4NuYG4Ox8vD7/n5tv017QM
	feXg==
X-Received: by 10.107.30.204 with SMTP id e195mr10437112ioe.28.1419039290242; 
	Fri, 19 Dec 2014 17:34:50 -0800 (PST)
Received: from [172.26.51.187] ([172.26.51.187])
	by mx.google.com with ESMTPSA id sd6sm1684993igb.4.2014.12.19.17.34.48
	(version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128);
	Fri, 19 Dec 2014 17:34:49 -0800 (PST)
Message-ID: <1419039288.11185.4.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 19 Dec 2014 17:34:48 -0800
In-Reply-To: <20141220003636.GA32187@gondor.apana.org.au>
References: <1418756386-6940-1-git-send-email-david.vrabel@citrix.com>
	<20141220002327.GA31975@gondor.apana.org.au>
	<20141220003636.GA32187@gondor.apana.org.au>
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, edumazet@google.com,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] net: Detect drivers that reschedule NAPI and
	exhaust budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-20 at 11:36 +1100, Herbert Xu wrote:
> On Sat, Dec 20, 2014 at 11:23:27AM +1100, Herbert Xu wrote:
> >
> > A similar bug exists in virtio_net.
> 
> In order to detect other drivers doing this we should add something
> like this.
> 
> -- >8 --
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) required drivers to leave poll_list
> empty if the entire budget is consumed.
> 
> We have already had two broken drivers so let's add a check for
> this.
>  
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index f411c28..88f9725 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4620,7 +4620,11 @@ static void net_rx_action(struct softirq_action *h)
>  					 */
>  					napi_gro_flush(n, HZ >= 1000);
>  				}
> -				list_add_tail(&n->poll_list, &repoll);
> +				/* Some drivers may have called napi_schedule
> +				 * prior to exhausting their budget.
> +				 */
> +				if (!WARN_ON_ONCE(!list_empty(&n->poll_list)))
> +					list_add_tail(&n->poll_list, &repoll);
>  			}
>  		}
>  

I do not think stack trace will point to the buggy driver ?

IMO it would be better to print a single line with the netdev name ?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 02:40:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 02:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y29xl-0005SR-4f; Sat, 20 Dec 2014 02:40:13 +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 1Y29xi-0005SM-WB
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 02:40:11 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	99/44-03145-A81E4945; Sat, 20 Dec 2014 02:40:10 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-10.tower-27.messagelabs.com!1419043206!16319466!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21820 invoked from network); 20 Dec 2014 02:40:07 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-10.tower-27.messagelabs.com with SMTP;
	20 Dec 2014 02:40:07 -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 F3D31581E2C;
	Fri, 19 Dec 2014 18:40:04 -0800 (PST)
Date: Fri, 19 Dec 2014 21:40:00 -0500 (EST)
Message-Id: <20141219.214000.819506179607476836.davem@davemloft.net>
To: eric.dumazet@gmail.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1419039288.11185.4.camel@edumazet-glaptop2.roam.corp.google.com>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<20141220003636.GA32187@gondor.apana.org.au>
	<1419039288.11185.4.camel@edumazet-glaptop2.roam.corp.google.com>
X-Mailer: Mew version 6.6 on Emacs 24.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]);
	Fri, 19 Dec 2014 18:40:05 -0800 (PST)
Cc: herbert@gondor.apana.org.au, netdev@vger.kernel.org, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] net: Detect drivers that reschedule NAPI and
	exhaust budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Dec 2014 17:34:48 -0800

>> @@ -4620,7 +4620,11 @@ static void net_rx_action(struct softirq_action *h)
>>  					 */
>>  					napi_gro_flush(n, HZ >= 1000);
>>  				}
>> -				list_add_tail(&n->poll_list, &repoll);
>> +				/* Some drivers may have called napi_schedule
>> +				 * prior to exhausting their budget.
>> +				 */
>> +				if (!WARN_ON_ONCE(!list_empty(&n->poll_list)))
>> +					list_add_tail(&n->poll_list, &repoll);
>>  			}
>>  		}
>>  
> 
> I do not think stack trace will point to the buggy driver ?
> 
> IMO it would be better to print a single line with the netdev name ?

Right, we are already back from the poll routine and will just end
up seeing the call trace leading to the software interrupt.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 02:40:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 02:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y29xl-0005SR-4f; Sat, 20 Dec 2014 02:40:13 +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 1Y29xi-0005SM-WB
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 02:40:11 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	99/44-03145-A81E4945; Sat, 20 Dec 2014 02:40:10 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-10.tower-27.messagelabs.com!1419043206!16319466!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21820 invoked from network); 20 Dec 2014 02:40:07 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-10.tower-27.messagelabs.com with SMTP;
	20 Dec 2014 02:40:07 -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 F3D31581E2C;
	Fri, 19 Dec 2014 18:40:04 -0800 (PST)
Date: Fri, 19 Dec 2014 21:40:00 -0500 (EST)
Message-Id: <20141219.214000.819506179607476836.davem@davemloft.net>
To: eric.dumazet@gmail.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1419039288.11185.4.camel@edumazet-glaptop2.roam.corp.google.com>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<20141220003636.GA32187@gondor.apana.org.au>
	<1419039288.11185.4.camel@edumazet-glaptop2.roam.corp.google.com>
X-Mailer: Mew version 6.6 on Emacs 24.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]);
	Fri, 19 Dec 2014 18:40:05 -0800 (PST)
Cc: herbert@gondor.apana.org.au, netdev@vger.kernel.org, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] net: Detect drivers that reschedule NAPI and
	exhaust budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Dec 2014 17:34:48 -0800

>> @@ -4620,7 +4620,11 @@ static void net_rx_action(struct softirq_action *h)
>>  					 */
>>  					napi_gro_flush(n, HZ >= 1000);
>>  				}
>> -				list_add_tail(&n->poll_list, &repoll);
>> +				/* Some drivers may have called napi_schedule
>> +				 * prior to exhausting their budget.
>> +				 */
>> +				if (!WARN_ON_ONCE(!list_empty(&n->poll_list)))
>> +					list_add_tail(&n->poll_list, &repoll);
>>  			}
>>  		}
>>  
> 
> I do not think stack trace will point to the buggy driver ?
> 
> IMO it would be better to print a single line with the netdev name ?

Right, we are already back from the poll routine and will just end
up seeing the call trace leading to the software interrupt.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 02:48:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 02:48:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2A5A-0005ub-8s; Sat, 20 Dec 2014 02:47: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 1Y2A58-0005uW-P5
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 02:47:50 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	D5/0B-20609-653E4945; Sat, 20 Dec 2014 02:47:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1419043668!16292292!1
X-Originating-IP: [66.165.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 31274 invoked from network); 20 Dec 2014 02:47:49 -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;
	20 Dec 2014 02:47:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,610,1413244800"; d="scan'208";a="206964231"
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.210.2; Fri, 19 Dec 2014 21:47: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 1Y2A54-0008Cn-3g;
	Sat, 20 Dec 2014 02:47:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2A53-0006Jn-Og;
	Sat, 20 Dec 2014 02:47:45 +0000
Date: Sat, 20 Dec 2014 02:47:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32499-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] 32499: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32499 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32499/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 32285

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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              64b76149765341168b4c073211f7b17a0f54f444
baseline version:
 seabios              ed675ad4193bc7f929e5b39074d50672970aefa3

------------------------------------------------------------
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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-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-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 64b76149765341168b4c073211f7b17a0f54f444
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Mon Dec 15 21:44:13 2014 -0500

    Simplify README files - point to online documentation instead
    
    The README file and README.CSM file have gotten a bit out of date.
    Instead of maintaining technical information in the README file, point
    new users to the SeaBIOS wiki.
    
    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

commit 73fe49aef4a4328bf0edd4302f5f6dd99e61ba49
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Fri Dec 12 14:16:43 2014 -0500

    usb: Update USB hub code to support super speed hubs
    
    Super speed hubs (usb3 spec) have specific initialization
    requirements.  Add the code necessary to detect and initialize these
    hubs.
    
    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 Sat Dec 20 02:48:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 02:48:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2A5A-0005ub-8s; Sat, 20 Dec 2014 02:47: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 1Y2A58-0005uW-P5
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 02:47:50 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	D5/0B-20609-653E4945; Sat, 20 Dec 2014 02:47:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1419043668!16292292!1
X-Originating-IP: [66.165.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 31274 invoked from network); 20 Dec 2014 02:47:49 -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;
	20 Dec 2014 02:47:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,610,1413244800"; d="scan'208";a="206964231"
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.210.2; Fri, 19 Dec 2014 21:47: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 1Y2A54-0008Cn-3g;
	Sat, 20 Dec 2014 02:47:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2A53-0006Jn-Og;
	Sat, 20 Dec 2014 02:47:45 +0000
Date: Sat, 20 Dec 2014 02:47:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32499-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] 32499: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32499 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32499/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 32285

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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              64b76149765341168b4c073211f7b17a0f54f444
baseline version:
 seabios              ed675ad4193bc7f929e5b39074d50672970aefa3

------------------------------------------------------------
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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-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-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 64b76149765341168b4c073211f7b17a0f54f444
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Mon Dec 15 21:44:13 2014 -0500

    Simplify README files - point to online documentation instead
    
    The README file and README.CSM file have gotten a bit out of date.
    Instead of maintaining technical information in the README file, point
    new users to the SeaBIOS wiki.
    
    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

commit 73fe49aef4a4328bf0edd4302f5f6dd99e61ba49
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Fri Dec 12 14:16:43 2014 -0500

    usb: Update USB hub code to support super speed hubs
    
    Super speed hubs (usb3 spec) have specific initialization
    requirements.  Add the code necessary to detect and initialize these
    hubs.
    
    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 Sat Dec 20 05:12:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 05:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2CKl-0002vu-Cq; Sat, 20 Dec 2014 05:12: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 1Y2CKk-0002vp-J0
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 05:12:06 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	44/92-26858-52505945; Sat, 20 Dec 2014 05:12:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1419052323!14788281!1
X-Originating-IP: [66.165.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 32400 invoked from network); 20 Dec 2014 05:12:04 -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 Dec 2014 05:12:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,611,1413244800"; d="scan'208";a="206984811"
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.210.2; Sat, 20 Dec 2014 00:12: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 1Y2CKg-0000SW-22;
	Sat, 20 Dec 2014 05:12:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2CKe-0004Xu-Jp;
	Sat, 20 Dec 2014 05:12:01 +0000
Date: Sat, 20 Dec 2014 05:12:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32503-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] 32503: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32503 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32503/

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. 32392

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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
 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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  2676bc915157ab474ee478d929b0928cf696b385

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  M A Young <m.a.young@durham.ac.uk>
  Michael Young <m.a.young@durham.ac.uk>
  Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.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                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Author: M A Young <m.a.young@durham.ac.uk>
Date:   Thu Dec 18 10:02:16 2014 +0000

    tools/xl: fix segfault in xl migrate --debug
    
    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>

commit 7e88c23239591e2638bcc944151a660fcd53495b
Author: George Dunlap <george.dunlap@eu.citrix.com>
Date:   Tue Dec 9 14:04:19 2014 +0000

    libxl: Tell qemu to use raw format when using a tapdisk
    
    At the moment libxl unconditinally passes the underlying file format
    to qemu in the device string.  However, when tapdisk is in use,
    tapdisk handles the underlying format and presents qemu with
    effectively a raw disk.  When qemu looks at the tapdisk block device
    and doesn't find the image format it was looking for, it will fail.
    
    This effectively means that tapdisk cannot be used with HVM domains at
    the moment except for raw files.
    
    Instead, if we're using a tapdisk backend, tell qemu to use a raw file
    format.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    [ ijc -- nuked extra blank line ]

commit 09b7ff1a118f5e920ef12f5592f3ce991218962a
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Dec 15 10:56:24 2014 +0000

    xl: print message to stdout when (!debug && dryrun)
    
    In commit d36a3734a ("xl: fix migration failure with xl migrate
    --debug"), message is printed to stderr for both debug mode
    and dryrun mode. That caused rdname() in xendomains fails to parse
    domain name since it's expecting input from xl's stdout.
    
    So this patch separates those two cases. If xl is running in debug mode,
    then message is printed to stderr; if xl is running in dryrun mode and
    debug is not enabled, message is printed to stdout. This will fix
    xendomains and other scripts that use "xl create --dryrun", as well as
    not re-introducing the old bug fixed in d36a3734a.
    
    Reported-by: Mark Pryor <tlviewer@yahoo.com>
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Cc: M A Young <m.a.young@durham.ac.uk>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Wilk <konrad.wilk@oracle.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit afa3fd8753c944f37c1cd182d5ad7c436c7614da
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Fri Dec 12 18:26:02 2014 +0000

    docs/commandline: Minor formatting fixes and clarifications
    
    `font` had a trailing single quote which was out of place.
    
    `gnttab_max_frames` was missing escapes for the underscores which caused the
    underscores to take their markdown meaning, causing 'max' in the middle to be
    italicised.  Escape the underscores, and make all command line parameters
    bold, to be consistent with the existing style.
    
    Clarify how the default for `nmi` changes between debug and non debug builds
    of Xen.
    
    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>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 3f727fb1a7d5f3be2513ab2e692b067075325fb3
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Tue Dec 9 16:43:22 2014 +0000

    python/xc: Fix multiple issues in pyflask_context_to_sid()
    
    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.
    
    Coverity also complains about passing a non-NUL terminated string to
    xc_flask_context_to_sid().  xc_flask_context_to_sid() doesn't actually take a
    NUL terminated string, but it does take a char* which, in context, used to be
    a string, which is why Coverity complains.
    
    One solution would be to use strdup(ctx) which is simpler than a
    strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated
    string being used with xc_flask_context_to_sid().
    
    However, ctx is strictly an input to the hypercall and is not mutated along
    the way.  Both these issues can be fixed, and the error logic simplified, by
    not duplicating ctx in the first place.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Coverity-IDs: 1055305 1055721
    Acked-by: 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>

commit dcd84861b0b01b8895716d4c803c9d24c31c8cab
Author: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date:   Mon Dec 8 15:51:47 2014 +0200

    xen/serial: setup UART idle mode for OMAP
    
    The UART is not able to receive bytes when idle mode is not configured
    properly, therefore setup the UART with autoidle and wakeup enabled.
    
    Older Linux kernels (for example 3.8) configure hwmods for all devices
    even if the device tree nodes for those devices is absent in device
    tree, thus UART idle mode is configured too.  With such kernels we can
    workaround the issue by adding a fake node in the UART containing this
    MMIO range, which is therefore mapped by Xen to dom0, which
    reconfigures the UART, causing things to work normally.
    
    Newer Linux Kernels (3.12 and beyond) do not configure idle mode for
    UART and so this hack no longer works.
    
    Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    [ ijc -- updated commit message as discussed ]

commit 6c9b27d3f363889718e7e046511383927f257095
Merge: 2676bc9 05fecc3
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Dec 15 17:40:12 2014 +0000

    Merge tag '4.5.0-rc4' into staging
    
    Xen 4.5.0 RC4

commit 05fecc382e129731c6595268a377f4bff879f694
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Dec 15 11:35:59 2014 -0500

    Xen-4.5.0-rc4: Update tag for qemu-xen.
    
    QEMU-traditional has nothing new, so stay at rc1 there.
    
    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 Sat Dec 20 05:12:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 05:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2CKl-0002vu-Cq; Sat, 20 Dec 2014 05:12: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 1Y2CKk-0002vp-J0
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 05:12:06 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	44/92-26858-52505945; Sat, 20 Dec 2014 05:12:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1419052323!14788281!1
X-Originating-IP: [66.165.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 32400 invoked from network); 20 Dec 2014 05:12:04 -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 Dec 2014 05:12:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,611,1413244800"; d="scan'208";a="206984811"
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.210.2; Sat, 20 Dec 2014 00:12: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 1Y2CKg-0000SW-22;
	Sat, 20 Dec 2014 05:12:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2CKe-0004Xu-Jp;
	Sat, 20 Dec 2014 05:12:01 +0000
Date: Sat, 20 Dec 2014 05:12:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32503-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] 32503: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32503 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32503/

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. 32392

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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
 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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  2676bc915157ab474ee478d929b0928cf696b385

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  M A Young <m.a.young@durham.ac.uk>
  Michael Young <m.a.young@durham.ac.uk>
  Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.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                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Author: M A Young <m.a.young@durham.ac.uk>
Date:   Thu Dec 18 10:02:16 2014 +0000

    tools/xl: fix segfault in xl migrate --debug
    
    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>

commit 7e88c23239591e2638bcc944151a660fcd53495b
Author: George Dunlap <george.dunlap@eu.citrix.com>
Date:   Tue Dec 9 14:04:19 2014 +0000

    libxl: Tell qemu to use raw format when using a tapdisk
    
    At the moment libxl unconditinally passes the underlying file format
    to qemu in the device string.  However, when tapdisk is in use,
    tapdisk handles the underlying format and presents qemu with
    effectively a raw disk.  When qemu looks at the tapdisk block device
    and doesn't find the image format it was looking for, it will fail.
    
    This effectively means that tapdisk cannot be used with HVM domains at
    the moment except for raw files.
    
    Instead, if we're using a tapdisk backend, tell qemu to use a raw file
    format.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    [ ijc -- nuked extra blank line ]

commit 09b7ff1a118f5e920ef12f5592f3ce991218962a
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Dec 15 10:56:24 2014 +0000

    xl: print message to stdout when (!debug && dryrun)
    
    In commit d36a3734a ("xl: fix migration failure with xl migrate
    --debug"), message is printed to stderr for both debug mode
    and dryrun mode. That caused rdname() in xendomains fails to parse
    domain name since it's expecting input from xl's stdout.
    
    So this patch separates those two cases. If xl is running in debug mode,
    then message is printed to stderr; if xl is running in dryrun mode and
    debug is not enabled, message is printed to stdout. This will fix
    xendomains and other scripts that use "xl create --dryrun", as well as
    not re-introducing the old bug fixed in d36a3734a.
    
    Reported-by: Mark Pryor <tlviewer@yahoo.com>
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Cc: M A Young <m.a.young@durham.ac.uk>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Release-Acked-by: Konrad Wilk <konrad.wilk@oracle.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit afa3fd8753c944f37c1cd182d5ad7c436c7614da
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Fri Dec 12 18:26:02 2014 +0000

    docs/commandline: Minor formatting fixes and clarifications
    
    `font` had a trailing single quote which was out of place.
    
    `gnttab_max_frames` was missing escapes for the underscores which caused the
    underscores to take their markdown meaning, causing 'max' in the middle to be
    italicised.  Escape the underscores, and make all command line parameters
    bold, to be consistent with the existing style.
    
    Clarify how the default for `nmi` changes between debug and non debug builds
    of Xen.
    
    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>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 3f727fb1a7d5f3be2513ab2e692b067075325fb3
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Tue Dec 9 16:43:22 2014 +0000

    python/xc: Fix multiple issues in pyflask_context_to_sid()
    
    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.
    
    Coverity also complains about passing a non-NUL terminated string to
    xc_flask_context_to_sid().  xc_flask_context_to_sid() doesn't actually take a
    NUL terminated string, but it does take a char* which, in context, used to be
    a string, which is why Coverity complains.
    
    One solution would be to use strdup(ctx) which is simpler than a
    strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated
    string being used with xc_flask_context_to_sid().
    
    However, ctx is strictly an input to the hypercall and is not mutated along
    the way.  Both these issues can be fixed, and the error logic simplified, by
    not duplicating ctx in the first place.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Coverity-IDs: 1055305 1055721
    Acked-by: 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>

commit dcd84861b0b01b8895716d4c803c9d24c31c8cab
Author: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Date:   Mon Dec 8 15:51:47 2014 +0200

    xen/serial: setup UART idle mode for OMAP
    
    The UART is not able to receive bytes when idle mode is not configured
    properly, therefore setup the UART with autoidle and wakeup enabled.
    
    Older Linux kernels (for example 3.8) configure hwmods for all devices
    even if the device tree nodes for those devices is absent in device
    tree, thus UART idle mode is configured too.  With such kernels we can
    workaround the issue by adding a fake node in the UART containing this
    MMIO range, which is therefore mapped by Xen to dom0, which
    reconfigures the UART, causing things to work normally.
    
    Newer Linux Kernels (3.12 and beyond) do not configure idle mode for
    UART and so this hack no longer works.
    
    Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    [ ijc -- updated commit message as discussed ]

commit 6c9b27d3f363889718e7e046511383927f257095
Merge: 2676bc9 05fecc3
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Dec 15 17:40:12 2014 +0000

    Merge tag '4.5.0-rc4' into staging
    
    Xen 4.5.0 RC4

commit 05fecc382e129731c6595268a377f4bff879f694
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Dec 15 11:35:59 2014 -0500

    Xen-4.5.0-rc4: Update tag for qemu-xen.
    
    QEMU-traditional has nothing new, so stay at rc1 there.
    
    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 Sat Dec 20 05:15:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 05:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2CO0-00031s-8L; Sat, 20 Dec 2014 05:15: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 1Y2CNy-00031j-I8
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 05:15:26 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	E4/7C-02696-DE505945; Sat, 20 Dec 2014 05:15:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1419052522!16311177!1
X-Originating-IP: [66.165.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 8337 invoked from network); 20 Dec 2014 05:15:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2014 05:15:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,611,1413244800"; d="scan'208";a="206985215"
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.210.2; Sat, 20 Dec 2014 00:15: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 1Y2CNt-0000Tb-Ae;
	Sat, 20 Dec 2014 05:15:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2CNs-0004yo-Us;
	Sat, 20 Dec 2014 05:15:21 +0000
Date: Sat, 20 Dec 2014 05:15:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32508-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8111
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32508: 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="===============8825895224484197508=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8825895224484197508==
Content-Type: text/plain
Content-Length: 7834
Content-Transfer-Encoding: quoted-printable

flight 32508 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32508/

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              1adda68a1b60a1f1a42bab5801e1529059d34ce4
baseline version:
 libvirt              531aef2e1b2c5ca97bc2936c108a6fa20b60de93

------------------------------------------------------------
People who touched revisions under test:
  J=C3=A1n Tomko <jtomko@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=3D1adda68a1b60a1f1a42bab5801e1529059d34ce4
+ . 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 1adda68a1b60a1f1a42bab5801e1529059d34ce4
+ branch=3Dlibvirt
+ revision=3D1adda68a1b60a1f1a42bab5801e1529059d34ce4
+ . 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 1adda68a1b60a1f1a42bab5801e1529059d34ce4:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   531aef2..1adda68  1adda68a1b60a1f1a42bab5801e1529059d34ce4 -> xen-tested-master


--===============8825895224484197508==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8825895224484197508==--

From xen-devel-bounces@lists.xen.org Sat Dec 20 05:15:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 05:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2CO0-00031s-8L; Sat, 20 Dec 2014 05:15: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 1Y2CNy-00031j-I8
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 05:15:26 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	E4/7C-02696-DE505945; Sat, 20 Dec 2014 05:15:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1419052522!16311177!1
X-Originating-IP: [66.165.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 8337 invoked from network); 20 Dec 2014 05:15:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2014 05:15:23 -0000
X-IronPort-AV: E=Sophos;i="5.07,611,1413244800"; d="scan'208";a="206985215"
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.210.2; Sat, 20 Dec 2014 00:15: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 1Y2CNt-0000Tb-Ae;
	Sat, 20 Dec 2014 05:15:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2CNs-0004yo-Us;
	Sat, 20 Dec 2014 05:15:21 +0000
Date: Sat, 20 Dec 2014 05:15:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32508-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 8111
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [libvirt test] 32508: 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="===============8825895224484197508=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8825895224484197508==
Content-Type: text/plain
Content-Length: 7834
Content-Transfer-Encoding: quoted-printable

flight 32508 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32508/

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              1adda68a1b60a1f1a42bab5801e1529059d34ce4
baseline version:
 libvirt              531aef2e1b2c5ca97bc2936c108a6fa20b60de93

------------------------------------------------------------
People who touched revisions under test:
  J=C3=A1n Tomko <jtomko@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=3D1adda68a1b60a1f1a42bab5801e1529059d34ce4
+ . 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 1adda68a1b60a1f1a42bab5801e1529059d34ce4
+ branch=3Dlibvirt
+ revision=3D1adda68a1b60a1f1a42bab5801e1529059d34ce4
+ . 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 1adda68a1b60a1f1a42bab5801e1529059d34ce4:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   531aef2..1adda68  1adda68a1b60a1f1a42bab5801e1529059d34ce4 -> xen-tested-master


--===============8825895224484197508==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8825895224484197508==--

From xen-devel-bounces@lists.xen.org Sat Dec 20 06:56:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 06: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 1Y2Dx6-0006Xm-CH; Sat, 20 Dec 2014 06:55:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2Dx5-0006Xh-Cj
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 06:55:47 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	33/90-25714-27D15945; Sat, 20 Dec 2014 06:55:46 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-11.tower-206.messagelabs.com!1419058542!10325123!1
X-Originating-IP: [209.40.204.226]
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 10798 invoked from network); 20 Dec 2014 06:55:45 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 06:55:45 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2Dwv-0005F3-56; Sat, 20 Dec 2014 17:55:37 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2Dwo-0000YE-CZ; Sat, 20 Dec 2014 17:55:30 +1100
Date: Sat, 20 Dec 2014 17:55:29 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
To: David Miller <davem@davemloft.net>
Message-ID: <20141220065529.GA2033@gondor.apana.org.au>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<20141220003636.GA32187@gondor.apana.org.au>
	<1419039288.11185.4.camel@edumazet-glaptop2.roam.corp.google.com>
	<20141219.214000.819506179607476836.davem@davemloft.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141219.214000.819506179607476836.davem@davemloft.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] net: Detect drivers that reschedule NAPI and
	exhaust budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 19, 2014 at 09:40:00PM -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 19 Dec 2014 17:34:48 -0800
> 
> >> @@ -4620,7 +4620,11 @@ static void net_rx_action(struct softirq_action *h)
> >>  					 */
> >>  					napi_gro_flush(n, HZ >= 1000);
> >>  				}
> >> -				list_add_tail(&n->poll_list, &repoll);
> >> +				/* Some drivers may have called napi_schedule
> >> +				 * prior to exhausting their budget.
> >> +				 */
> >> +				if (!WARN_ON_ONCE(!list_empty(&n->poll_list)))
> >> +					list_add_tail(&n->poll_list, &repoll);
> >>  			}
> >>  		}
> >>  
> > 
> > I do not think stack trace will point to the buggy driver ?
> > 
> > IMO it would be better to print a single line with the netdev name ?
> 
> Right, we are already back from the poll routine and will just end
> up seeing the call trace leading to the software interrupt.

Good point Eric.

-- >8 --
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) required drivers to leave poll_list
empty if the entire budget is consumed.

We have already had two broken drivers so let's add a check for
this.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/net/core/dev.c b/net/core/dev.c
index f411c28..47fdc5c 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4620,7 +4620,13 @@ static void net_rx_action(struct softirq_action *h)
 					 */
 					napi_gro_flush(n, HZ >= 1000);
 				}
-				list_add_tail(&n->poll_list, &repoll);
+				/* Some drivers may have called napi_schedule
+				 * prior to exhausting their budget.
+				 */
+				if (unlikely(!list_empty(&n->poll_list)))
+					pr_warn("%s: Budget exhausted after napi rescheduled\n", n->dev ? n->dev->name : "backlog");
+				else
+					list_add_tail(&n->poll_list, &repoll);
 			}
 		}
 
Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 06:56:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 06: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 1Y2Dx6-0006Xm-CH; Sat, 20 Dec 2014 06:55:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2Dx5-0006Xh-Cj
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 06:55:47 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	33/90-25714-27D15945; Sat, 20 Dec 2014 06:55:46 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-11.tower-206.messagelabs.com!1419058542!10325123!1
X-Originating-IP: [209.40.204.226]
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 10798 invoked from network); 20 Dec 2014 06:55:45 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 06:55:45 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2Dwv-0005F3-56; Sat, 20 Dec 2014 17:55:37 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2Dwo-0000YE-CZ; Sat, 20 Dec 2014 17:55:30 +1100
Date: Sat, 20 Dec 2014 17:55:29 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
To: David Miller <davem@davemloft.net>
Message-ID: <20141220065529.GA2033@gondor.apana.org.au>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<20141220003636.GA32187@gondor.apana.org.au>
	<1419039288.11185.4.camel@edumazet-glaptop2.roam.corp.google.com>
	<20141219.214000.819506179607476836.davem@davemloft.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141219.214000.819506179607476836.davem@davemloft.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] net: Detect drivers that reschedule NAPI and
	exhaust budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 19, 2014 at 09:40:00PM -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 19 Dec 2014 17:34:48 -0800
> 
> >> @@ -4620,7 +4620,11 @@ static void net_rx_action(struct softirq_action *h)
> >>  					 */
> >>  					napi_gro_flush(n, HZ >= 1000);
> >>  				}
> >> -				list_add_tail(&n->poll_list, &repoll);
> >> +				/* Some drivers may have called napi_schedule
> >> +				 * prior to exhausting their budget.
> >> +				 */
> >> +				if (!WARN_ON_ONCE(!list_empty(&n->poll_list)))
> >> +					list_add_tail(&n->poll_list, &repoll);
> >>  			}
> >>  		}
> >>  
> > 
> > I do not think stack trace will point to the buggy driver ?
> > 
> > IMO it would be better to print a single line with the netdev name ?
> 
> Right, we are already back from the poll routine and will just end
> up seeing the call trace leading to the software interrupt.

Good point Eric.

-- >8 --
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) required drivers to leave poll_list
empty if the entire budget is consumed.

We have already had two broken drivers so let's add a check for
this.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/net/core/dev.c b/net/core/dev.c
index f411c28..47fdc5c 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4620,7 +4620,13 @@ static void net_rx_action(struct softirq_action *h)
 					 */
 					napi_gro_flush(n, HZ >= 1000);
 				}
-				list_add_tail(&n->poll_list, &repoll);
+				/* Some drivers may have called napi_schedule
+				 * prior to exhausting their budget.
+				 */
+				if (unlikely(!list_empty(&n->poll_list)))
+					pr_warn("%s: Budget exhausted after napi rescheduled\n", n->dev ? n->dev->name : "backlog");
+				else
+					list_add_tail(&n->poll_list, &repoll);
 			}
 		}
 
Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 07:28:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 07: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 1Y2ESM-0007rF-PM; Sat, 20 Dec 2014 07: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 1Y2ESK-0007rA-VK
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 07:28:05 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	B9/48-02696-40525945; Sat, 20 Dec 2014 07:28:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419060480!16347702!1
X-Originating-IP: [66.165.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 26322 invoked from network); 20 Dec 2014 07:28:01 -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 Dec 2014 07:28:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,612,1413244800"; d="scan'208";a="206509385"
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.210.2; Sat, 20 Dec 2014 02:27: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 1Y2ESF-000198-Ah;
	Sat, 20 Dec 2014 07:27:59 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2ESE-0006sV-Rl;
	Sat, 20 Dec 2014 07:27:58 +0000
Date: Sat, 20 Dec 2014 07:27:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32507-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] 32507: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32507 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32507/

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           9 guest-start                 fail pass in 32445
 test-amd64-i386-xl-multivcpu  5 xen-boot           fail in 32445 pass in 32507
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 32445 pass in 32507
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 32445 pass in 32507

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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-winxpsp3 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-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-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 20 07:28:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 07: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 1Y2ESM-0007rF-PM; Sat, 20 Dec 2014 07: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 1Y2ESK-0007rA-VK
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 07:28:05 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	B9/48-02696-40525945; Sat, 20 Dec 2014 07:28:04 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419060480!16347702!1
X-Originating-IP: [66.165.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 26322 invoked from network); 20 Dec 2014 07:28:01 -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 Dec 2014 07:28:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,612,1413244800"; d="scan'208";a="206509385"
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.210.2; Sat, 20 Dec 2014 02:27: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 1Y2ESF-000198-Ah;
	Sat, 20 Dec 2014 07:27:59 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2ESE-0006sV-Rl;
	Sat, 20 Dec 2014 07:27:58 +0000
Date: Sat, 20 Dec 2014 07:27:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32507-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] 32507: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32507 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32507/

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           9 guest-start                 fail pass in 32445
 test-amd64-i386-xl-multivcpu  5 xen-boot           fail in 32445 pass in 32507
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 32445 pass in 32507
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 32445 pass in 32507

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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-winxpsp3 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-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-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 20 08:37:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 08: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 1Y2FWp-0002Gj-4d; Sat, 20 Dec 2014 08:36:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiaoding1@huawei.com>) id 1Y2FWo-0002Ge-2X
	for xen-devel@lists.xen.org; Sat, 20 Dec 2014 08:36:46 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	FC/A2-22737-D1535945; Sat, 20 Dec 2014 08:36:45 +0000
X-Env-Sender: xiaoding1@huawei.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1419064599!14451681!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25232 invoked from network); 20 Dec 2014 08:36:43 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2014 08:36:43 -0000
Received: from 172.24.2.119 (EHLO SZXEMA412-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AYY19195; Sat, 20 Dec 2014 16:36:37 +0800 (CST)
Received: from SZXEMA505-MBS.china.huawei.com ([169.254.2.197]) by
	SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id
	14.03.0158.001; Sat, 20 Dec 2014 16:36:27 +0800
From: "Xiaoding (B)" <xiaoding1@huawei.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: How to optimize the UDP speed when the package is greater than
	the MTU 
Thread-Index: AdAcMAl/fABgQ/3OTF6w5C83pooelg==
Date: Sat, 20 Dec 2014 08:36:25 +0000
Message-ID: <89E0966AE9A1C3499DBCD33F337DA29B2791CC01@szxema505-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.146.123.164]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020204.54953516.0106, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.197,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4d92ee41d79d4bb0beecff021ef3b394
Cc: "Zhangleiqiang \(Trump\)" <zhangleiqiang@huawei.com>,
	"ssdxiao@163.com" <ssdxiao@163.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: [Xen-devel] How to optimize the UDP speed when the package is
 greater than the MTU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7425202735152254754=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7425202735152254754==
Content-Language: zh-CN
Content-Type: multipart/alternative;
	boundary="_000_89E0966AE9A1C3499DBCD33F337DA29B2791CC01szxema505mbschi_"

--_000_89E0966AE9A1C3499DBCD33F337DA29B2791CC01szxema505mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgQWxso6wNCkkgdHJ5IHRvIHRlc3QgdGhlIHBlcmZvcm1hbmNlIG9mIG5ldGZyb250IG5ldGJh
Y2sNCkkgdXNlIHhlbjQuNCBhbmQga2VybmVsIDMuMTctNA0KDQpXaGVuIEkgdGVzdCB0aGUgVURQ
IHNwZWVkDQpJIGZvdW5kIHRoYXQgaWYgc2VuZCBwYWNrYWdlIGlzIGxhcmdlciB0aGFuIHRoZSBN
VFUsIHhlbi1iYWNrIHdpbGwgb25seSBvbmUgcXVldWUgYXQgd29yay4NCkFuZCB0aGUgc3BlZWQg
aXMgc2xvdw0KDQpJcyB0aGVyZSBhbnkgd2F5IHRvIG1ha2VzIG11bHRpIHF1ZXVlIHdvcmtpbmcg
d2l0aCBwYWNrYWdlIGxhcmdlciB0aGFuIHRoZSBNVFUgb3IgY2FuIGFjY2VsZXJhdGUgc3BlZWQN
Cg0KWGlhb2RpbmcNClJlZ2FyZHMNCg0K

--_000_89E0966AE9A1C3499DBCD33F337DA29B2791CC01szxema505mbschi_
Content-Type: text/html; charset="gb2312"
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=3Dgb2312">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
/* Page Definitions */
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple" style=3D"text-justify-t=
rim:punctuation">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US">Hi All</span><span style=3D"fon=
t-family:=CB=CE=CC=E5">=A3=AC</span><span lang=3D"EN-US"><o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I try to test the performance o=
f netfront netback<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I use xen4.4 and kernel 3.17-4 =
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">When I test the UDP speed <o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I found that if send package is=
 larger than the MTU, xen-back will only one queue at work.<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">And the speed is slow <o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Is there any way to makes multi=
 queue working with package larger than the MTU or can accelerate speed<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Xiaoding<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Regards<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_89E0966AE9A1C3499DBCD33F337DA29B2791CC01szxema505mbschi_--



--===============7425202735152254754==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7425202735152254754==--



From xen-devel-bounces@lists.xen.org Sat Dec 20 08:37:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 08: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 1Y2FWp-0002Gj-4d; Sat, 20 Dec 2014 08:36:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiaoding1@huawei.com>) id 1Y2FWo-0002Ge-2X
	for xen-devel@lists.xen.org; Sat, 20 Dec 2014 08:36:46 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	FC/A2-22737-D1535945; Sat, 20 Dec 2014 08:36:45 +0000
X-Env-Sender: xiaoding1@huawei.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1419064599!14451681!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25232 invoked from network); 20 Dec 2014 08:36:43 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2014 08:36:43 -0000
Received: from 172.24.2.119 (EHLO SZXEMA412-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AYY19195; Sat, 20 Dec 2014 16:36:37 +0800 (CST)
Received: from SZXEMA505-MBS.china.huawei.com ([169.254.2.197]) by
	SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id
	14.03.0158.001; Sat, 20 Dec 2014 16:36:27 +0800
From: "Xiaoding (B)" <xiaoding1@huawei.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: How to optimize the UDP speed when the package is greater than
	the MTU 
Thread-Index: AdAcMAl/fABgQ/3OTF6w5C83pooelg==
Date: Sat, 20 Dec 2014 08:36:25 +0000
Message-ID: <89E0966AE9A1C3499DBCD33F337DA29B2791CC01@szxema505-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.146.123.164]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020204.54953516.0106, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.197,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4d92ee41d79d4bb0beecff021ef3b394
Cc: "Zhangleiqiang \(Trump\)" <zhangleiqiang@huawei.com>,
	"ssdxiao@163.com" <ssdxiao@163.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: [Xen-devel] How to optimize the UDP speed when the package is
 greater than the MTU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7425202735152254754=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7425202735152254754==
Content-Language: zh-CN
Content-Type: multipart/alternative;
	boundary="_000_89E0966AE9A1C3499DBCD33F337DA29B2791CC01szxema505mbschi_"

--_000_89E0966AE9A1C3499DBCD33F337DA29B2791CC01szxema505mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgQWxso6wNCkkgdHJ5IHRvIHRlc3QgdGhlIHBlcmZvcm1hbmNlIG9mIG5ldGZyb250IG5ldGJh
Y2sNCkkgdXNlIHhlbjQuNCBhbmQga2VybmVsIDMuMTctNA0KDQpXaGVuIEkgdGVzdCB0aGUgVURQ
IHNwZWVkDQpJIGZvdW5kIHRoYXQgaWYgc2VuZCBwYWNrYWdlIGlzIGxhcmdlciB0aGFuIHRoZSBN
VFUsIHhlbi1iYWNrIHdpbGwgb25seSBvbmUgcXVldWUgYXQgd29yay4NCkFuZCB0aGUgc3BlZWQg
aXMgc2xvdw0KDQpJcyB0aGVyZSBhbnkgd2F5IHRvIG1ha2VzIG11bHRpIHF1ZXVlIHdvcmtpbmcg
d2l0aCBwYWNrYWdlIGxhcmdlciB0aGFuIHRoZSBNVFUgb3IgY2FuIGFjY2VsZXJhdGUgc3BlZWQN
Cg0KWGlhb2RpbmcNClJlZ2FyZHMNCg0K

--_000_89E0966AE9A1C3499DBCD33F337DA29B2791CC01szxema505mbschi_
Content-Type: text/html; charset="gb2312"
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=3Dgb2312">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
/* Page Definitions */
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple" style=3D"text-justify-t=
rim:punctuation">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US">Hi All</span><span style=3D"fon=
t-family:=CB=CE=CC=E5">=A3=AC</span><span lang=3D"EN-US"><o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I try to test the performance o=
f netfront netback<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I use xen4.4 and kernel 3.17-4 =
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">When I test the UDP speed <o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I found that if send package is=
 larger than the MTU, xen-back will only one queue at work.<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">And the speed is slow <o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Is there any way to makes multi=
 queue working with package larger than the MTU or can accelerate speed<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Xiaoding<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Regards<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_89E0966AE9A1C3499DBCD33F337DA29B2791CC01szxema505mbschi_--



--===============7425202735152254754==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7425202735152254754==--



From xen-devel-bounces@lists.xen.org Sat Dec 20 11:02:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 11:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2Hmm-00073A-0r; Sat, 20 Dec 2014 11:01: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 1Y2Hml-000735-9i
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 11:01:23 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	EB/31-17936-20755945; Sat, 20 Dec 2014 11:01:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1419073280!16356223!1
X-Originating-IP: [66.165.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 25480 invoked from network); 20 Dec 2014 11:01:21 -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 Dec 2014 11:01:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,612,1413244800"; d="scan'208";a="207037065"
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.210.2; Sat, 20 Dec 2014 06:01: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 1Y2Hmg-0002AF-Oz;
	Sat, 20 Dec 2014 11:01:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2Hmg-0002og-FU;
	Sat, 20 Dec 2014 11:01:18 +0000
Date: Sat, 20 Dec 2014 11:01:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32517-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] 32517: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32517 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32517/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel  5 xen-boot                 fail REGR. vs. 32459

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32459

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-pvh-amd   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
 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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                b574f602680d41c4cf4a9c106e3e2244bed01cdd
baseline version:
 qemuu                86b182ac0e0b44726d85598cbefb468ed22517fc

------------------------------------------------------------
People who touched revisions under test:
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 b574f602680d41c4cf4a9c106e3e2244bed01cdd
Merge: 86b182a 46817e8
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Wed Dec 17 19:22:41 2014 +0000

    Merge remote-tracking branch 'remotes/kraxel/tags/pull-vga-20141216-1' into staging
    
    cirrus hwcursor fixes.
    set secondary-vga category.
    
    # gpg: Signature made Tue 16 Dec 2014 14:44:09 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-vga-20141216-1:
      vga: set catagory bit for secondary vga device
      move hw cursor pos from cirrus to vga
      cirrus: Force use of shadow pixmap when HW cursor is enabled
      vga: Add mechanism to force the use of a shadow surface
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 46817e86fc1d97af0a7d9e4060730f7b00183083
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Fri Dec 5 11:33:37 2014 +0800

    vga: set catagory bit for secondary vga device
    
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

commit 22382bb96c8bd88370c1ff0cb28c3ee6bee79ed3
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Thu Oct 16 10:22:23 2014 +0200

    move hw cursor pos from cirrus to vga

commit b9fd11b86779b1fe7fe2881c6e312a028e20e67c
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Mon Jul 7 10:28:39 2014 +1000

    cirrus: Force use of shadow pixmap when HW cursor is enabled
    
    The HW cursor cannot be painted on a shared surface. This fixes HW
    cursor display in Windows NT 4.0 and Windows 98.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

commit 5508099397c480f1c3b4f14b0e64593ebe284b26
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Mon Jul 7 10:17:44 2014 +1000

    vga: Add mechanism to force the use of a shadow surface
    
    This prevents surface sharing which will be necessary to
    fix cirrus HW cursor support.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    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 Sat Dec 20 11:02:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 11:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2Hmm-00073A-0r; Sat, 20 Dec 2014 11:01: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 1Y2Hml-000735-9i
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 11:01:23 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	EB/31-17936-20755945; Sat, 20 Dec 2014 11:01:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1419073280!16356223!1
X-Originating-IP: [66.165.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 25480 invoked from network); 20 Dec 2014 11:01:21 -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 Dec 2014 11:01:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,612,1413244800"; d="scan'208";a="207037065"
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.210.2; Sat, 20 Dec 2014 06:01: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 1Y2Hmg-0002AF-Oz;
	Sat, 20 Dec 2014 11:01:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2Hmg-0002og-FU;
	Sat, 20 Dec 2014 11:01:18 +0000
Date: Sat, 20 Dec 2014 11:01:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32517-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] 32517: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32517 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32517/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel  5 xen-boot                 fail REGR. vs. 32459

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32459

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-pvh-amd   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
 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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                b574f602680d41c4cf4a9c106e3e2244bed01cdd
baseline version:
 qemuu                86b182ac0e0b44726d85598cbefb468ed22517fc

------------------------------------------------------------
People who touched revisions under test:
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 b574f602680d41c4cf4a9c106e3e2244bed01cdd
Merge: 86b182a 46817e8
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Wed Dec 17 19:22:41 2014 +0000

    Merge remote-tracking branch 'remotes/kraxel/tags/pull-vga-20141216-1' into staging
    
    cirrus hwcursor fixes.
    set secondary-vga category.
    
    # gpg: Signature made Tue 16 Dec 2014 14:44:09 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-vga-20141216-1:
      vga: set catagory bit for secondary vga device
      move hw cursor pos from cirrus to vga
      cirrus: Force use of shadow pixmap when HW cursor is enabled
      vga: Add mechanism to force the use of a shadow surface
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit 46817e86fc1d97af0a7d9e4060730f7b00183083
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Fri Dec 5 11:33:37 2014 +0800

    vga: set catagory bit for secondary vga device
    
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

commit 22382bb96c8bd88370c1ff0cb28c3ee6bee79ed3
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Thu Oct 16 10:22:23 2014 +0200

    move hw cursor pos from cirrus to vga

commit b9fd11b86779b1fe7fe2881c6e312a028e20e67c
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Mon Jul 7 10:28:39 2014 +1000

    cirrus: Force use of shadow pixmap when HW cursor is enabled
    
    The HW cursor cannot be painted on a shared surface. This fixes HW
    cursor display in Windows NT 4.0 and Windows 98.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

commit 5508099397c480f1c3b4f14b0e64593ebe284b26
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Mon Jul 7 10:17:44 2014 +1000

    vga: Add mechanism to force the use of a shadow surface
    
    This prevents surface sharing which will be necessary to
    fix cirrus HW cursor support.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    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 Sat Dec 20 14:17:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 14: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 1Y2KqH-0005G3-Om; Sat, 20 Dec 2014 14:17:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rjw@rjwysocki.net>) id 1Y2KqF-0005Fy-Ta
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 14:17:12 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	B9/A9-17735-7E485945; Sat, 20 Dec 2014 14:17:11 +0000
X-Env-Sender: rjw@rjwysocki.net
X-Msg-Ref: server-14.tower-31.messagelabs.com!1419085028!12379246!1
X-Originating-IP: [79.96.170.134]
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 14978 invoked from network); 20 Dec 2014 14:17:08 -0000
Received: from v094114.home.net.pl (HELO v094114.home.net.pl) (79.96.170.134)
	by server-14.tower-31.messagelabs.com with SMTP;
	20 Dec 2014 14:17:08 -0000
Received: from afpu122.neoplus.adsl.tpnet.pl (178.42.150.122) (HELO
	vostro.rjw.lan)
	by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer
	v0.80) id da3272dbd0bc974d; Sat, 20 Dec 2014 15:17:07 +0100
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Joe Perches <joe@perches.com>
Date: Sat, 20 Dec 2014 15:38:58 +0100
Message-ID: <3128229.dCxxVbIcej@vostro.rjw.lan>
User-Agent: KMail/4.11.5 (Linux/3.16.0-rc5+; KDE/4.11.5; x86_64; ; )
In-Reply-To: <1418254133.18092.22.camel@perches.com>
References: <1418254133.18092.22.camel@perches.com>
MIME-Version: 1.0
Cc: linux-pm <linux-pm@vger.kernel.org>, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-tegra@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>, linux-omap@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH] treewide: Convert clockevents_notify to use
	int 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 Wednesday, December 10, 2014 03:28:53 PM Joe Perches wrote:
> As far as I can tell, there's no value indirecting
> the cpu passed to this function via a void *.
> 
> Update all the callers and called functions from within
> clockevents_notify.
> 
> Miscellanea:
> 
> Add pr_fmt and convert one printk(KERN_ERR to pr_err

That is fine by me, so

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

for the cpuidle and ACPI changes.

> Signed-off-by: Joe Perches <joe@perches.com>
> ---
>  arch/arm/mach-omap2/cpuidle44xx.c      |  7 +++----
>  arch/arm/mach-tegra/cpuidle-tegra114.c |  4 ++--
>  arch/arm/mach-tegra/cpuidle-tegra20.c  |  8 ++++----
>  arch/arm/mach-tegra/cpuidle-tegra30.c  |  8 ++++----
>  arch/x86/kernel/process.c              |  6 +++---
>  arch/x86/xen/suspend.c                 |  2 +-
>  drivers/acpi/acpi_pad.c                |  9 +++++----
>  drivers/acpi/processor_idle.c          |  4 ++--
>  drivers/cpuidle/driver.c               |  3 +--
>  drivers/idle/intel_idle.c              |  7 +++----
>  include/linux/clockchips.h             |  6 +++---
>  kernel/sched/idle.c                    |  4 ++--
>  kernel/time/clockevents.c              | 15 +++++++--------
>  kernel/time/hrtimer.c                  |  6 ++----
>  kernel/time/tick-broadcast.c           | 16 ++++++++--------
>  kernel/time/tick-common.c              | 16 ++++++++--------
>  kernel/time/tick-internal.h            | 18 +++++++++---------
>  kernel/time/timekeeping.c              |  4 ++--
>  18 files changed, 69 insertions(+), 74 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 01e398a..5d50aa1 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -112,7 +112,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
>  	mpuss_can_lose_context = (cx->mpu_state == PWRDM_POWER_RET) &&
>  				 (cx->mpu_logic_state == PWRDM_POWER_OFF);
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
>  
>  	/*
>  	 * Call idle CPU PM enter notifier chain so that
> @@ -169,7 +169,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
>  	if (dev->cpu == 0 && mpuss_can_lose_context)
>  		cpu_cluster_pm_exit();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
>  
>  fail:
>  	cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
> @@ -184,8 +184,7 @@ fail:
>   */
>  static void omap_setup_broadcast_timer(void *arg)
>  {
> -	int cpu = smp_processor_id();
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, smp_processor_id());
>  }
>  
>  static struct cpuidle_driver omap4_idle_driver = {
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
> index f2b586d..3b2fc3f 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra114.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
> @@ -44,7 +44,7 @@ static int tegra114_idle_power_down(struct cpuidle_device *dev,
>  	tegra_set_cpu_in_lp2();
>  	cpu_pm_enter();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
>  
>  	call_firmware_op(prepare_idle);
>  
> @@ -52,7 +52,7 @@ static int tegra114_idle_power_down(struct cpuidle_device *dev,
>  	if (call_firmware_op(do_idle, 0) == -ENOSYS)
>  		cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
>  
>  	cpu_pm_exit();
>  	tegra_clear_cpu_in_lp2();
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
> index 4f25a7c..ab30758 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra20.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
> @@ -136,11 +136,11 @@ static bool tegra20_cpu_cluster_power_down(struct cpuidle_device *dev,
>  	if (tegra20_reset_cpu_1() || !tegra_cpu_rail_off_ready())
>  		return false;
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
>  
>  	tegra_idle_lp2_last();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
>  
>  	if (cpu_online(1))
>  		tegra20_wake_cpu1_from_reset();
> @@ -153,13 +153,13 @@ static bool tegra20_idle_enter_lp2_cpu_1(struct cpuidle_device *dev,
>  					 struct cpuidle_driver *drv,
>  					 int index)
>  {
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
>  
>  	cpu_suspend(0, tegra20_sleep_cpu_secondary_finish);
>  
>  	tegra20_cpu_clear_resettable();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
>  
>  	return true;
>  }
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
> index f8815ed..67d0492 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra30.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
> @@ -76,11 +76,11 @@ static bool tegra30_cpu_cluster_power_down(struct cpuidle_device *dev,
>  		return false;
>  	}
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
>  
>  	tegra_idle_lp2_last();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
>  
>  	return true;
>  }
> @@ -90,13 +90,13 @@ static bool tegra30_cpu_core_power_down(struct cpuidle_device *dev,
>  					struct cpuidle_driver *drv,
>  					int index)
>  {
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
>  
>  	smp_wmb();
>  
>  	cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
>  
>  	return true;
>  }
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index e127dda..09290b0 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -380,10 +380,10 @@ static void amd_e400_idle(void)
>  			 * Force broadcast so ACPI can not interfere.
>  			 */
>  			clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_FORCE,
> -					   &cpu);
> +					   cpu);
>  			pr_info("Switch to broadcast mode on CPU%d\n", cpu);
>  		}
> -		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
>  
>  		default_idle();
>  
> @@ -392,7 +392,7 @@ static void amd_e400_idle(void)
>  		 * called with interrupts disabled.
>  		 */
>  		local_irq_disable();
> -		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
>  		local_irq_enable();
>  	} else
>  		default_idle();
> diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
> index c4df9db..61bab6a 100644
> --- a/arch/x86/xen/suspend.c
> +++ b/arch/x86/xen/suspend.c
> @@ -87,7 +87,7 @@ static void xen_vcpu_notify_restore(void *data)
>  	if ( smp_processor_id() == 0)
>  		return;
>  
> -	clockevents_notify(reason, NULL);
> +	clockevents_notify(reason, -1);
>  }
>  
>  void xen_arch_resume(void)
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index c7b105c..63138e4 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -180,17 +180,18 @@ static int power_saving_thread(void *data)
>  			if (lapic_detected_unstable && !lapic_marked_unstable) {
>  				int i;
>  				/* LAPIC could halt in idle, so notify users */
> -				for_each_online_cpu(i)
> +				for_each_online_cpu(i) {
>  					clockevents_notify(
>  						CLOCK_EVT_NOTIFY_BROADCAST_ON,
> -						&i);
> +						i);
> +				}
>  				lapic_marked_unstable = 1;
>  			}
>  			local_irq_disable();
>  			cpu = smp_processor_id();
>  			if (lapic_marked_unstable)
>  				clockevents_notify(
> -					CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
> +					CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
>  			stop_critical_timings();
>  
>  			mwait_idle_with_hints(power_saving_mwait_eax, 1);
> @@ -198,7 +199,7 @@ static int power_saving_thread(void *data)
>  			start_critical_timings();
>  			if (lapic_marked_unstable)
>  				clockevents_notify(
> -					CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
> +					CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
>  			local_irq_enable();
>  
>  			if (time_before(expire_time, jiffies)) {
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index 4995365..2eaa450 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -162,7 +162,7 @@ static void __lapic_timer_propagate_broadcast(void *arg)
>  	reason = pr->power.timer_broadcast_on_state < INT_MAX ?
>  		CLOCK_EVT_NOTIFY_BROADCAST_ON : CLOCK_EVT_NOTIFY_BROADCAST_OFF;
>  
> -	clockevents_notify(reason, &pr->id);
> +	clockevents_notify(reason, pr->id);
>  }
>  
>  static void lapic_timer_propagate_broadcast(struct acpi_processor *pr)
> @@ -183,7 +183,7 @@ static void lapic_timer_state_broadcast(struct acpi_processor *pr,
>  
>  		reason = broadcast ?  CLOCK_EVT_NOTIFY_BROADCAST_ENTER :
>  			CLOCK_EVT_NOTIFY_BROADCAST_EXIT;
> -		clockevents_notify(reason, &pr->id);
> +		clockevents_notify(reason, pr->id);
>  	}
>  }
>  
> diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> index 2697e87..2fcc20b 100644
> --- a/drivers/cpuidle/driver.c
> +++ b/drivers/cpuidle/driver.c
> @@ -143,8 +143,7 @@ static inline void __cpuidle_unset_driver(struct cpuidle_driver *drv)
>   */
>  static void cpuidle_setup_broadcast_timer(void *arg)
>  {
> -	int cpu = smp_processor_id();
> -	clockevents_notify((long)(arg), &cpu);
> +	clockevents_notify((long)arg, smp_processor_id());
>  }
>  
>  /**
> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> index 9cceacb..945b1f3 100644
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@ -582,12 +582,12 @@ static int intel_idle(struct cpuidle_device *dev,
>  		leave_mm(cpu);
>  
>  	if (!(lapic_timer_reliable_states & (1 << (cstate))))
> -		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
>  
>  	mwait_idle_with_hints(eax, ecx);
>  
>  	if (!(lapic_timer_reliable_states & (1 << (cstate))))
> -		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
>  
>  	return index;
>  }
> @@ -595,12 +595,11 @@ static int intel_idle(struct cpuidle_device *dev,
>  static void __setup_broadcast_timer(void *arg)
>  {
>  	unsigned long reason = (unsigned long)arg;
> -	int cpu = smp_processor_id();
>  
>  	reason = reason ?
>  		CLOCK_EVT_NOTIFY_BROADCAST_ON : CLOCK_EVT_NOTIFY_BROADCAST_OFF;
>  
> -	clockevents_notify(reason, &cpu);
> +	clockevents_notify(reason, smp_processor_id());
>  }
>  
>  static int cpu_hotplug_notify(struct notifier_block *n,
> diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
> index 2e4cb67..4e03069 100644
> --- a/include/linux/clockchips.h
> +++ b/include/linux/clockchips.h
> @@ -195,9 +195,9 @@ static inline void tick_setup_hrtimer_broadcast(void) {};
>  #endif
>  
>  #ifdef CONFIG_GENERIC_CLOCKEVENTS
> -extern int clockevents_notify(unsigned long reason, void *arg);
> +extern int clockevents_notify(unsigned long reason, int cpu);
>  #else
> -static inline int clockevents_notify(unsigned long reason, void *arg) { return 0; }
> +static inline int clockevents_notify(unsigned long reason, int cpu) { return 0; }
>  #endif
>  
>  #else /* CONFIG_GENERIC_CLOCKEVENTS_BUILD */
> @@ -205,7 +205,7 @@ static inline int clockevents_notify(unsigned long reason, void *arg) { return 0
>  static inline void clockevents_suspend(void) {}
>  static inline void clockevents_resume(void) {}
>  
> -static inline int clockevents_notify(unsigned long reason, void *arg) { return 0; }
> +static inline int clockevents_notify(unsigned long reason, int cpu) { return 0; }
>  static inline int tick_check_broadcast_expired(void) { return 0; }
>  static inline void tick_setup_hrtimer_broadcast(void) {};
>  
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index c47fce7..e68faee 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -144,7 +144,7 @@ use_default:
>  	 * fail if it is not available
>  	 */
>  	if (broadcast &&
> -	    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu))
> +	    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu))
>  		goto use_default;
>  
>  	/* Take note of the planned idle state. */
> @@ -161,7 +161,7 @@ use_default:
>  	idle_set_state(this_rq(), NULL);
>  
>  	if (broadcast)
> -		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
>  
>  	/*
>  	 * Give the governor an opportunity to reflect on the outcome
> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
> index 5544990..69973be 100644
> --- a/kernel/time/clockevents.c
> +++ b/kernel/time/clockevents.c
> @@ -546,11 +546,11 @@ void clockevents_resume(void)
>   * clockevents_notify - notification about relevant events
>   * Returns 0 on success, any other value on error
>   */
> -int clockevents_notify(unsigned long reason, void *arg)
> +int clockevents_notify(unsigned long reason, int cpu)
>  {
>  	struct clock_event_device *dev, *tmp;
>  	unsigned long flags;
> -	int cpu, ret = 0;
> +	int ret = 0;
>  
>  	raw_spin_lock_irqsave(&clockevents_lock, flags);
>  
> @@ -558,7 +558,7 @@ int clockevents_notify(unsigned long reason, void *arg)
>  	case CLOCK_EVT_NOTIFY_BROADCAST_ON:
>  	case CLOCK_EVT_NOTIFY_BROADCAST_OFF:
>  	case CLOCK_EVT_NOTIFY_BROADCAST_FORCE:
> -		tick_broadcast_on_off(reason, arg);
> +		tick_broadcast_on_off(reason, cpu);
>  		break;
>  
>  	case CLOCK_EVT_NOTIFY_BROADCAST_ENTER:
> @@ -567,7 +567,7 @@ int clockevents_notify(unsigned long reason, void *arg)
>  		break;
>  
>  	case CLOCK_EVT_NOTIFY_CPU_DYING:
> -		tick_handover_do_timer(arg);
> +		tick_handover_do_timer(cpu);
>  		break;
>  
>  	case CLOCK_EVT_NOTIFY_SUSPEND:
> @@ -580,9 +580,9 @@ int clockevents_notify(unsigned long reason, void *arg)
>  		break;
>  
>  	case CLOCK_EVT_NOTIFY_CPU_DEAD:
> -		tick_shutdown_broadcast_oneshot(arg);
> -		tick_shutdown_broadcast(arg);
> -		tick_shutdown(arg);
> +		tick_shutdown_broadcast_oneshot(cpu);
> +		tick_shutdown_broadcast(cpu);
> +		tick_shutdown(cpu);
>  		/*
>  		 * Unregister the clock event devices which were
>  		 * released from the users in the notify chain.
> @@ -592,7 +592,6 @@ int clockevents_notify(unsigned long reason, void *arg)
>  		/*
>  		 * Now check whether the CPU has left unused per cpu devices
>  		 */
> -		cpu = *((int *)arg);
>  		list_for_each_entry_safe(dev, tmp, &clockevent_devices, list) {
>  			if (cpumask_test_cpu(cpu, dev->cpumask) &&
>  			    cpumask_weight(dev->cpumask) == 1 &&
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index 37e50aa..e8c903f 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -1717,15 +1717,13 @@ static int hrtimer_cpu_notify(struct notifier_block *self,
>  #ifdef CONFIG_HOTPLUG_CPU
>  	case CPU_DYING:
>  	case CPU_DYING_FROZEN:
> -		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DYING, &scpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DYING, scpu);
>  		break;
>  	case CPU_DEAD:
>  	case CPU_DEAD_FROZEN:
> -	{
> -		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, &scpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, scpu);
>  		migrate_hrtimers(scpu);
>  		break;
> -	}
>  #endif
>  
>  	default:
> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
> index 066f0ec..4ede817 100644
> --- a/kernel/time/tick-broadcast.c
> +++ b/kernel/time/tick-broadcast.c
> @@ -11,6 +11,9 @@
>   * This code is licenced under the GPL version 2. For details see
>   * kernel-base/COPYING.
>   */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
>  #include <linux/cpu.h>
>  #include <linux/err.h>
>  #include <linux/hrtimer.h>
> @@ -396,11 +399,10 @@ out:
>   * Powerstate information: The system enters/leaves a state, where
>   * affected devices might stop.
>   */
> -void tick_broadcast_on_off(unsigned long reason, int *oncpu)
> +void tick_broadcast_on_off(unsigned long reason, int oncpu)
>  {
> -	if (!cpumask_test_cpu(*oncpu, cpu_online_mask))
> -		printk(KERN_ERR "tick-broadcast: ignoring broadcast for "
> -		       "offline CPU #%d\n", *oncpu);
> +	if (!cpumask_test_cpu(oncpu, cpu_online_mask))
> +		pr_err("ignoring broadcast for offline CPU #%d\n", oncpu);
>  	else
>  		tick_do_broadcast_on_off(&reason);
>  }
> @@ -419,11 +421,10 @@ void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast)
>  /*
>   * Remove a CPU from broadcasting
>   */
> -void tick_shutdown_broadcast(unsigned int *cpup)
> +void tick_shutdown_broadcast(int cpu)
>  {
>  	struct clock_event_device *bc;
>  	unsigned long flags;
> -	unsigned int cpu = *cpup;
>  
>  	raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
>  
> @@ -898,10 +899,9 @@ void tick_broadcast_switch_to_oneshot(void)
>  /*
>   * Remove a dead CPU from broadcasting
>   */
> -void tick_shutdown_broadcast_oneshot(unsigned int *cpup)
> +void tick_shutdown_broadcast_oneshot(int cpu)
>  {
>  	unsigned long flags;
> -	unsigned int cpu = *cpup;
>  
>  	raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
>  
> diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
> index 7efeedf..ae4b200 100644
> --- a/kernel/time/tick-common.c
> +++ b/kernel/time/tick-common.c
> @@ -337,14 +337,14 @@ out_bc:
>   *
>   * Called with interrupts disabled.
>   */
> -void tick_handover_do_timer(int *cpup)
> +void tick_handover_do_timer(int cpu)
>  {
> -	if (*cpup == tick_do_timer_cpu) {
> -		int cpu = cpumask_first(cpu_online_mask);
> +	if (cpu != tick_do_timer_cpu)
> +		return;
>  
> -		tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu :
> -			TICK_DO_TIMER_NONE;
> -	}
> +	cpu = cpumask_first(cpu_online_mask);
> +
> +	tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu : TICK_DO_TIMER_NONE;
>  }
>  
>  /*
> @@ -354,9 +354,9 @@ void tick_handover_do_timer(int *cpup)
>   * access the hardware device itself.
>   * We just set the mode and remove it from the lists.
>   */
> -void tick_shutdown(unsigned int *cpup)
> +void tick_shutdown(int cpu)
>  {
> -	struct tick_device *td = &per_cpu(tick_cpu_device, *cpup);
> +	struct tick_device *td = &per_cpu(tick_cpu_device, cpu);
>  	struct clock_event_device *dev = td->evtdev;
>  
>  	td->mode = TICKDEV_MODE_PERIODIC;
> diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
> index 366aeb4..57ab722 100644
> --- a/kernel/time/tick-internal.h
> +++ b/kernel/time/tick-internal.h
> @@ -23,8 +23,8 @@ extern int tick_do_timer_cpu __read_mostly;
>  extern void tick_setup_periodic(struct clock_event_device *dev, int broadcast);
>  extern void tick_handle_periodic(struct clock_event_device *dev);
>  extern void tick_check_new_device(struct clock_event_device *dev);
> -extern void tick_handover_do_timer(int *cpup);
> -extern void tick_shutdown(unsigned int *cpup);
> +extern void tick_handover_do_timer(int cpu);
> +extern void tick_shutdown(int cpu);
>  extern void tick_suspend(void);
>  extern void tick_resume(void);
>  extern bool tick_check_replacement(struct clock_event_device *curdev,
> @@ -50,7 +50,7 @@ extern void tick_resume_oneshot(void);
>  extern void tick_broadcast_setup_oneshot(struct clock_event_device *bc);
>  extern int tick_broadcast_oneshot_control(unsigned long reason);
>  extern void tick_broadcast_switch_to_oneshot(void);
> -extern void tick_shutdown_broadcast_oneshot(unsigned int *cpup);
> +extern void tick_shutdown_broadcast_oneshot(int cpu);
>  extern int tick_resume_broadcast_oneshot(struct clock_event_device *bc);
>  extern int tick_broadcast_oneshot_active(void);
>  extern void tick_check_oneshot_broadcast_this_cpu(void);
> @@ -62,7 +62,7 @@ static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
>  }
>  static inline int tick_broadcast_oneshot_control(unsigned long reason) { return 0; }
>  static inline void tick_broadcast_switch_to_oneshot(void) { }
> -static inline void tick_shutdown_broadcast_oneshot(unsigned int *cpup) { }
> +static inline void tick_shutdown_broadcast_oneshot(int cpu) { }
>  static inline int tick_broadcast_oneshot_active(void) { return 0; }
>  static inline void tick_check_oneshot_broadcast_this_cpu(void) { }
>  static inline bool tick_broadcast_oneshot_available(void) { return true; }
> @@ -90,7 +90,7 @@ static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
>  	BUG();
>  }
>  static inline int tick_broadcast_oneshot_control(unsigned long reason) { return 0; }
> -static inline void tick_shutdown_broadcast_oneshot(unsigned int *cpup) { }
> +static inline void tick_shutdown_broadcast_oneshot(int cpu) { }
>  static inline int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
>  {
>  	return 0;
> @@ -113,8 +113,8 @@ static inline void tick_nohz_init(void) { }
>  extern int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu);
>  extern void tick_install_broadcast_device(struct clock_event_device *dev);
>  extern int tick_is_broadcast_device(struct clock_event_device *dev);
> -extern void tick_broadcast_on_off(unsigned long reason, int *oncpu);
> -extern void tick_shutdown_broadcast(unsigned int *cpup);
> +extern void tick_broadcast_on_off(unsigned long reason, int oncpu);
> +extern void tick_shutdown_broadcast(int cpu);
>  extern void tick_suspend_broadcast(void);
>  extern int tick_resume_broadcast(void);
>  extern void tick_broadcast_init(void);
> @@ -138,8 +138,8 @@ static inline int tick_device_uses_broadcast(struct clock_event_device *dev,
>  	return 0;
>  }
>  static inline void tick_do_periodic_broadcast(struct clock_event_device *d) { }
> -static inline void tick_broadcast_on_off(unsigned long reason, int *oncpu) { }
> -static inline void tick_shutdown_broadcast(unsigned int *cpup) { }
> +static inline void tick_broadcast_on_off(unsigned long reason, int oncpu) { }
> +static inline void tick_shutdown_broadcast(int cpu) { }
>  static inline void tick_suspend_broadcast(void) { }
>  static inline int tick_resume_broadcast(void) { return 0; }
>  static inline void tick_broadcast_init(void) { }
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 6a93185..dc84f52 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -1245,7 +1245,7 @@ static void timekeeping_resume(void)
>  
>  	touch_softlockup_watchdog();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, NULL);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, -1);
>  
>  	/* Resume hrtimers */
>  	hrtimers_resume();
> @@ -1299,7 +1299,7 @@ static int timekeeping_suspend(void)
>  	write_seqcount_end(&tk_core.seq);
>  	raw_spin_unlock_irqrestore(&timekeeper_lock, flags);
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, NULL);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, -1);
>  	clocksource_suspend();
>  	clockevents_suspend();
>  
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 14:17:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 14: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 1Y2KqH-0005G3-Om; Sat, 20 Dec 2014 14:17:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rjw@rjwysocki.net>) id 1Y2KqF-0005Fy-Ta
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 14:17:12 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	B9/A9-17735-7E485945; Sat, 20 Dec 2014 14:17:11 +0000
X-Env-Sender: rjw@rjwysocki.net
X-Msg-Ref: server-14.tower-31.messagelabs.com!1419085028!12379246!1
X-Originating-IP: [79.96.170.134]
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 14978 invoked from network); 20 Dec 2014 14:17:08 -0000
Received: from v094114.home.net.pl (HELO v094114.home.net.pl) (79.96.170.134)
	by server-14.tower-31.messagelabs.com with SMTP;
	20 Dec 2014 14:17:08 -0000
Received: from afpu122.neoplus.adsl.tpnet.pl (178.42.150.122) (HELO
	vostro.rjw.lan)
	by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer
	v0.80) id da3272dbd0bc974d; Sat, 20 Dec 2014 15:17:07 +0100
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Joe Perches <joe@perches.com>
Date: Sat, 20 Dec 2014 15:38:58 +0100
Message-ID: <3128229.dCxxVbIcej@vostro.rjw.lan>
User-Agent: KMail/4.11.5 (Linux/3.16.0-rc5+; KDE/4.11.5; x86_64; ; )
In-Reply-To: <1418254133.18092.22.camel@perches.com>
References: <1418254133.18092.22.camel@perches.com>
MIME-Version: 1.0
Cc: linux-pm <linux-pm@vger.kernel.org>, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-tegra@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Thomas Gleixner <tglx@linutronix.de>, linux-omap@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH] treewide: Convert clockevents_notify to use
	int 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 Wednesday, December 10, 2014 03:28:53 PM Joe Perches wrote:
> As far as I can tell, there's no value indirecting
> the cpu passed to this function via a void *.
> 
> Update all the callers and called functions from within
> clockevents_notify.
> 
> Miscellanea:
> 
> Add pr_fmt and convert one printk(KERN_ERR to pr_err

That is fine by me, so

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

for the cpuidle and ACPI changes.

> Signed-off-by: Joe Perches <joe@perches.com>
> ---
>  arch/arm/mach-omap2/cpuidle44xx.c      |  7 +++----
>  arch/arm/mach-tegra/cpuidle-tegra114.c |  4 ++--
>  arch/arm/mach-tegra/cpuidle-tegra20.c  |  8 ++++----
>  arch/arm/mach-tegra/cpuidle-tegra30.c  |  8 ++++----
>  arch/x86/kernel/process.c              |  6 +++---
>  arch/x86/xen/suspend.c                 |  2 +-
>  drivers/acpi/acpi_pad.c                |  9 +++++----
>  drivers/acpi/processor_idle.c          |  4 ++--
>  drivers/cpuidle/driver.c               |  3 +--
>  drivers/idle/intel_idle.c              |  7 +++----
>  include/linux/clockchips.h             |  6 +++---
>  kernel/sched/idle.c                    |  4 ++--
>  kernel/time/clockevents.c              | 15 +++++++--------
>  kernel/time/hrtimer.c                  |  6 ++----
>  kernel/time/tick-broadcast.c           | 16 ++++++++--------
>  kernel/time/tick-common.c              | 16 ++++++++--------
>  kernel/time/tick-internal.h            | 18 +++++++++---------
>  kernel/time/timekeeping.c              |  4 ++--
>  18 files changed, 69 insertions(+), 74 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 01e398a..5d50aa1 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -112,7 +112,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
>  	mpuss_can_lose_context = (cx->mpu_state == PWRDM_POWER_RET) &&
>  				 (cx->mpu_logic_state == PWRDM_POWER_OFF);
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
>  
>  	/*
>  	 * Call idle CPU PM enter notifier chain so that
> @@ -169,7 +169,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
>  	if (dev->cpu == 0 && mpuss_can_lose_context)
>  		cpu_cluster_pm_exit();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
>  
>  fail:
>  	cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
> @@ -184,8 +184,7 @@ fail:
>   */
>  static void omap_setup_broadcast_timer(void *arg)
>  {
> -	int cpu = smp_processor_id();
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, smp_processor_id());
>  }
>  
>  static struct cpuidle_driver omap4_idle_driver = {
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
> index f2b586d..3b2fc3f 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra114.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
> @@ -44,7 +44,7 @@ static int tegra114_idle_power_down(struct cpuidle_device *dev,
>  	tegra_set_cpu_in_lp2();
>  	cpu_pm_enter();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
>  
>  	call_firmware_op(prepare_idle);
>  
> @@ -52,7 +52,7 @@ static int tegra114_idle_power_down(struct cpuidle_device *dev,
>  	if (call_firmware_op(do_idle, 0) == -ENOSYS)
>  		cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
>  
>  	cpu_pm_exit();
>  	tegra_clear_cpu_in_lp2();
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c
> index 4f25a7c..ab30758 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra20.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
> @@ -136,11 +136,11 @@ static bool tegra20_cpu_cluster_power_down(struct cpuidle_device *dev,
>  	if (tegra20_reset_cpu_1() || !tegra_cpu_rail_off_ready())
>  		return false;
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
>  
>  	tegra_idle_lp2_last();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
>  
>  	if (cpu_online(1))
>  		tegra20_wake_cpu1_from_reset();
> @@ -153,13 +153,13 @@ static bool tegra20_idle_enter_lp2_cpu_1(struct cpuidle_device *dev,
>  					 struct cpuidle_driver *drv,
>  					 int index)
>  {
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
>  
>  	cpu_suspend(0, tegra20_sleep_cpu_secondary_finish);
>  
>  	tegra20_cpu_clear_resettable();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
>  
>  	return true;
>  }
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
> index f8815ed..67d0492 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra30.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
> @@ -76,11 +76,11 @@ static bool tegra30_cpu_cluster_power_down(struct cpuidle_device *dev,
>  		return false;
>  	}
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
>  
>  	tegra_idle_lp2_last();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
>  
>  	return true;
>  }
> @@ -90,13 +90,13 @@ static bool tegra30_cpu_core_power_down(struct cpuidle_device *dev,
>  					struct cpuidle_driver *drv,
>  					int index)
>  {
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
>  
>  	smp_wmb();
>  
>  	cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
>  
>  	return true;
>  }
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index e127dda..09290b0 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -380,10 +380,10 @@ static void amd_e400_idle(void)
>  			 * Force broadcast so ACPI can not interfere.
>  			 */
>  			clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_FORCE,
> -					   &cpu);
> +					   cpu);
>  			pr_info("Switch to broadcast mode on CPU%d\n", cpu);
>  		}
> -		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
>  
>  		default_idle();
>  
> @@ -392,7 +392,7 @@ static void amd_e400_idle(void)
>  		 * called with interrupts disabled.
>  		 */
>  		local_irq_disable();
> -		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
>  		local_irq_enable();
>  	} else
>  		default_idle();
> diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
> index c4df9db..61bab6a 100644
> --- a/arch/x86/xen/suspend.c
> +++ b/arch/x86/xen/suspend.c
> @@ -87,7 +87,7 @@ static void xen_vcpu_notify_restore(void *data)
>  	if ( smp_processor_id() == 0)
>  		return;
>  
> -	clockevents_notify(reason, NULL);
> +	clockevents_notify(reason, -1);
>  }
>  
>  void xen_arch_resume(void)
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index c7b105c..63138e4 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -180,17 +180,18 @@ static int power_saving_thread(void *data)
>  			if (lapic_detected_unstable && !lapic_marked_unstable) {
>  				int i;
>  				/* LAPIC could halt in idle, so notify users */
> -				for_each_online_cpu(i)
> +				for_each_online_cpu(i) {
>  					clockevents_notify(
>  						CLOCK_EVT_NOTIFY_BROADCAST_ON,
> -						&i);
> +						i);
> +				}
>  				lapic_marked_unstable = 1;
>  			}
>  			local_irq_disable();
>  			cpu = smp_processor_id();
>  			if (lapic_marked_unstable)
>  				clockevents_notify(
> -					CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
> +					CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
>  			stop_critical_timings();
>  
>  			mwait_idle_with_hints(power_saving_mwait_eax, 1);
> @@ -198,7 +199,7 @@ static int power_saving_thread(void *data)
>  			start_critical_timings();
>  			if (lapic_marked_unstable)
>  				clockevents_notify(
> -					CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
> +					CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
>  			local_irq_enable();
>  
>  			if (time_before(expire_time, jiffies)) {
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index 4995365..2eaa450 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -162,7 +162,7 @@ static void __lapic_timer_propagate_broadcast(void *arg)
>  	reason = pr->power.timer_broadcast_on_state < INT_MAX ?
>  		CLOCK_EVT_NOTIFY_BROADCAST_ON : CLOCK_EVT_NOTIFY_BROADCAST_OFF;
>  
> -	clockevents_notify(reason, &pr->id);
> +	clockevents_notify(reason, pr->id);
>  }
>  
>  static void lapic_timer_propagate_broadcast(struct acpi_processor *pr)
> @@ -183,7 +183,7 @@ static void lapic_timer_state_broadcast(struct acpi_processor *pr,
>  
>  		reason = broadcast ?  CLOCK_EVT_NOTIFY_BROADCAST_ENTER :
>  			CLOCK_EVT_NOTIFY_BROADCAST_EXIT;
> -		clockevents_notify(reason, &pr->id);
> +		clockevents_notify(reason, pr->id);
>  	}
>  }
>  
> diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> index 2697e87..2fcc20b 100644
> --- a/drivers/cpuidle/driver.c
> +++ b/drivers/cpuidle/driver.c
> @@ -143,8 +143,7 @@ static inline void __cpuidle_unset_driver(struct cpuidle_driver *drv)
>   */
>  static void cpuidle_setup_broadcast_timer(void *arg)
>  {
> -	int cpu = smp_processor_id();
> -	clockevents_notify((long)(arg), &cpu);
> +	clockevents_notify((long)arg, smp_processor_id());
>  }
>  
>  /**
> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> index 9cceacb..945b1f3 100644
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@ -582,12 +582,12 @@ static int intel_idle(struct cpuidle_device *dev,
>  		leave_mm(cpu);
>  
>  	if (!(lapic_timer_reliable_states & (1 << (cstate))))
> -		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu);
>  
>  	mwait_idle_with_hints(eax, ecx);
>  
>  	if (!(lapic_timer_reliable_states & (1 << (cstate))))
> -		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu);
>  
>  	return index;
>  }
> @@ -595,12 +595,11 @@ static int intel_idle(struct cpuidle_device *dev,
>  static void __setup_broadcast_timer(void *arg)
>  {
>  	unsigned long reason = (unsigned long)arg;
> -	int cpu = smp_processor_id();
>  
>  	reason = reason ?
>  		CLOCK_EVT_NOTIFY_BROADCAST_ON : CLOCK_EVT_NOTIFY_BROADCAST_OFF;
>  
> -	clockevents_notify(reason, &cpu);
> +	clockevents_notify(reason, smp_processor_id());
>  }
>  
>  static int cpu_hotplug_notify(struct notifier_block *n,
> diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
> index 2e4cb67..4e03069 100644
> --- a/include/linux/clockchips.h
> +++ b/include/linux/clockchips.h
> @@ -195,9 +195,9 @@ static inline void tick_setup_hrtimer_broadcast(void) {};
>  #endif
>  
>  #ifdef CONFIG_GENERIC_CLOCKEVENTS
> -extern int clockevents_notify(unsigned long reason, void *arg);
> +extern int clockevents_notify(unsigned long reason, int cpu);
>  #else
> -static inline int clockevents_notify(unsigned long reason, void *arg) { return 0; }
> +static inline int clockevents_notify(unsigned long reason, int cpu) { return 0; }
>  #endif
>  
>  #else /* CONFIG_GENERIC_CLOCKEVENTS_BUILD */
> @@ -205,7 +205,7 @@ static inline int clockevents_notify(unsigned long reason, void *arg) { return 0
>  static inline void clockevents_suspend(void) {}
>  static inline void clockevents_resume(void) {}
>  
> -static inline int clockevents_notify(unsigned long reason, void *arg) { return 0; }
> +static inline int clockevents_notify(unsigned long reason, int cpu) { return 0; }
>  static inline int tick_check_broadcast_expired(void) { return 0; }
>  static inline void tick_setup_hrtimer_broadcast(void) {};
>  
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index c47fce7..e68faee 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -144,7 +144,7 @@ use_default:
>  	 * fail if it is not available
>  	 */
>  	if (broadcast &&
> -	    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu))
> +	    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu))
>  		goto use_default;
>  
>  	/* Take note of the planned idle state. */
> @@ -161,7 +161,7 @@ use_default:
>  	idle_set_state(this_rq(), NULL);
>  
>  	if (broadcast)
> -		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
>  
>  	/*
>  	 * Give the governor an opportunity to reflect on the outcome
> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
> index 5544990..69973be 100644
> --- a/kernel/time/clockevents.c
> +++ b/kernel/time/clockevents.c
> @@ -546,11 +546,11 @@ void clockevents_resume(void)
>   * clockevents_notify - notification about relevant events
>   * Returns 0 on success, any other value on error
>   */
> -int clockevents_notify(unsigned long reason, void *arg)
> +int clockevents_notify(unsigned long reason, int cpu)
>  {
>  	struct clock_event_device *dev, *tmp;
>  	unsigned long flags;
> -	int cpu, ret = 0;
> +	int ret = 0;
>  
>  	raw_spin_lock_irqsave(&clockevents_lock, flags);
>  
> @@ -558,7 +558,7 @@ int clockevents_notify(unsigned long reason, void *arg)
>  	case CLOCK_EVT_NOTIFY_BROADCAST_ON:
>  	case CLOCK_EVT_NOTIFY_BROADCAST_OFF:
>  	case CLOCK_EVT_NOTIFY_BROADCAST_FORCE:
> -		tick_broadcast_on_off(reason, arg);
> +		tick_broadcast_on_off(reason, cpu);
>  		break;
>  
>  	case CLOCK_EVT_NOTIFY_BROADCAST_ENTER:
> @@ -567,7 +567,7 @@ int clockevents_notify(unsigned long reason, void *arg)
>  		break;
>  
>  	case CLOCK_EVT_NOTIFY_CPU_DYING:
> -		tick_handover_do_timer(arg);
> +		tick_handover_do_timer(cpu);
>  		break;
>  
>  	case CLOCK_EVT_NOTIFY_SUSPEND:
> @@ -580,9 +580,9 @@ int clockevents_notify(unsigned long reason, void *arg)
>  		break;
>  
>  	case CLOCK_EVT_NOTIFY_CPU_DEAD:
> -		tick_shutdown_broadcast_oneshot(arg);
> -		tick_shutdown_broadcast(arg);
> -		tick_shutdown(arg);
> +		tick_shutdown_broadcast_oneshot(cpu);
> +		tick_shutdown_broadcast(cpu);
> +		tick_shutdown(cpu);
>  		/*
>  		 * Unregister the clock event devices which were
>  		 * released from the users in the notify chain.
> @@ -592,7 +592,6 @@ int clockevents_notify(unsigned long reason, void *arg)
>  		/*
>  		 * Now check whether the CPU has left unused per cpu devices
>  		 */
> -		cpu = *((int *)arg);
>  		list_for_each_entry_safe(dev, tmp, &clockevent_devices, list) {
>  			if (cpumask_test_cpu(cpu, dev->cpumask) &&
>  			    cpumask_weight(dev->cpumask) == 1 &&
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index 37e50aa..e8c903f 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -1717,15 +1717,13 @@ static int hrtimer_cpu_notify(struct notifier_block *self,
>  #ifdef CONFIG_HOTPLUG_CPU
>  	case CPU_DYING:
>  	case CPU_DYING_FROZEN:
> -		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DYING, &scpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DYING, scpu);
>  		break;
>  	case CPU_DEAD:
>  	case CPU_DEAD_FROZEN:
> -	{
> -		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, &scpu);
> +		clockevents_notify(CLOCK_EVT_NOTIFY_CPU_DEAD, scpu);
>  		migrate_hrtimers(scpu);
>  		break;
> -	}
>  #endif
>  
>  	default:
> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
> index 066f0ec..4ede817 100644
> --- a/kernel/time/tick-broadcast.c
> +++ b/kernel/time/tick-broadcast.c
> @@ -11,6 +11,9 @@
>   * This code is licenced under the GPL version 2. For details see
>   * kernel-base/COPYING.
>   */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
>  #include <linux/cpu.h>
>  #include <linux/err.h>
>  #include <linux/hrtimer.h>
> @@ -396,11 +399,10 @@ out:
>   * Powerstate information: The system enters/leaves a state, where
>   * affected devices might stop.
>   */
> -void tick_broadcast_on_off(unsigned long reason, int *oncpu)
> +void tick_broadcast_on_off(unsigned long reason, int oncpu)
>  {
> -	if (!cpumask_test_cpu(*oncpu, cpu_online_mask))
> -		printk(KERN_ERR "tick-broadcast: ignoring broadcast for "
> -		       "offline CPU #%d\n", *oncpu);
> +	if (!cpumask_test_cpu(oncpu, cpu_online_mask))
> +		pr_err("ignoring broadcast for offline CPU #%d\n", oncpu);
>  	else
>  		tick_do_broadcast_on_off(&reason);
>  }
> @@ -419,11 +421,10 @@ void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast)
>  /*
>   * Remove a CPU from broadcasting
>   */
> -void tick_shutdown_broadcast(unsigned int *cpup)
> +void tick_shutdown_broadcast(int cpu)
>  {
>  	struct clock_event_device *bc;
>  	unsigned long flags;
> -	unsigned int cpu = *cpup;
>  
>  	raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
>  
> @@ -898,10 +899,9 @@ void tick_broadcast_switch_to_oneshot(void)
>  /*
>   * Remove a dead CPU from broadcasting
>   */
> -void tick_shutdown_broadcast_oneshot(unsigned int *cpup)
> +void tick_shutdown_broadcast_oneshot(int cpu)
>  {
>  	unsigned long flags;
> -	unsigned int cpu = *cpup;
>  
>  	raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
>  
> diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
> index 7efeedf..ae4b200 100644
> --- a/kernel/time/tick-common.c
> +++ b/kernel/time/tick-common.c
> @@ -337,14 +337,14 @@ out_bc:
>   *
>   * Called with interrupts disabled.
>   */
> -void tick_handover_do_timer(int *cpup)
> +void tick_handover_do_timer(int cpu)
>  {
> -	if (*cpup == tick_do_timer_cpu) {
> -		int cpu = cpumask_first(cpu_online_mask);
> +	if (cpu != tick_do_timer_cpu)
> +		return;
>  
> -		tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu :
> -			TICK_DO_TIMER_NONE;
> -	}
> +	cpu = cpumask_first(cpu_online_mask);
> +
> +	tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu : TICK_DO_TIMER_NONE;
>  }
>  
>  /*
> @@ -354,9 +354,9 @@ void tick_handover_do_timer(int *cpup)
>   * access the hardware device itself.
>   * We just set the mode and remove it from the lists.
>   */
> -void tick_shutdown(unsigned int *cpup)
> +void tick_shutdown(int cpu)
>  {
> -	struct tick_device *td = &per_cpu(tick_cpu_device, *cpup);
> +	struct tick_device *td = &per_cpu(tick_cpu_device, cpu);
>  	struct clock_event_device *dev = td->evtdev;
>  
>  	td->mode = TICKDEV_MODE_PERIODIC;
> diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
> index 366aeb4..57ab722 100644
> --- a/kernel/time/tick-internal.h
> +++ b/kernel/time/tick-internal.h
> @@ -23,8 +23,8 @@ extern int tick_do_timer_cpu __read_mostly;
>  extern void tick_setup_periodic(struct clock_event_device *dev, int broadcast);
>  extern void tick_handle_periodic(struct clock_event_device *dev);
>  extern void tick_check_new_device(struct clock_event_device *dev);
> -extern void tick_handover_do_timer(int *cpup);
> -extern void tick_shutdown(unsigned int *cpup);
> +extern void tick_handover_do_timer(int cpu);
> +extern void tick_shutdown(int cpu);
>  extern void tick_suspend(void);
>  extern void tick_resume(void);
>  extern bool tick_check_replacement(struct clock_event_device *curdev,
> @@ -50,7 +50,7 @@ extern void tick_resume_oneshot(void);
>  extern void tick_broadcast_setup_oneshot(struct clock_event_device *bc);
>  extern int tick_broadcast_oneshot_control(unsigned long reason);
>  extern void tick_broadcast_switch_to_oneshot(void);
> -extern void tick_shutdown_broadcast_oneshot(unsigned int *cpup);
> +extern void tick_shutdown_broadcast_oneshot(int cpu);
>  extern int tick_resume_broadcast_oneshot(struct clock_event_device *bc);
>  extern int tick_broadcast_oneshot_active(void);
>  extern void tick_check_oneshot_broadcast_this_cpu(void);
> @@ -62,7 +62,7 @@ static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
>  }
>  static inline int tick_broadcast_oneshot_control(unsigned long reason) { return 0; }
>  static inline void tick_broadcast_switch_to_oneshot(void) { }
> -static inline void tick_shutdown_broadcast_oneshot(unsigned int *cpup) { }
> +static inline void tick_shutdown_broadcast_oneshot(int cpu) { }
>  static inline int tick_broadcast_oneshot_active(void) { return 0; }
>  static inline void tick_check_oneshot_broadcast_this_cpu(void) { }
>  static inline bool tick_broadcast_oneshot_available(void) { return true; }
> @@ -90,7 +90,7 @@ static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
>  	BUG();
>  }
>  static inline int tick_broadcast_oneshot_control(unsigned long reason) { return 0; }
> -static inline void tick_shutdown_broadcast_oneshot(unsigned int *cpup) { }
> +static inline void tick_shutdown_broadcast_oneshot(int cpu) { }
>  static inline int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
>  {
>  	return 0;
> @@ -113,8 +113,8 @@ static inline void tick_nohz_init(void) { }
>  extern int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu);
>  extern void tick_install_broadcast_device(struct clock_event_device *dev);
>  extern int tick_is_broadcast_device(struct clock_event_device *dev);
> -extern void tick_broadcast_on_off(unsigned long reason, int *oncpu);
> -extern void tick_shutdown_broadcast(unsigned int *cpup);
> +extern void tick_broadcast_on_off(unsigned long reason, int oncpu);
> +extern void tick_shutdown_broadcast(int cpu);
>  extern void tick_suspend_broadcast(void);
>  extern int tick_resume_broadcast(void);
>  extern void tick_broadcast_init(void);
> @@ -138,8 +138,8 @@ static inline int tick_device_uses_broadcast(struct clock_event_device *dev,
>  	return 0;
>  }
>  static inline void tick_do_periodic_broadcast(struct clock_event_device *d) { }
> -static inline void tick_broadcast_on_off(unsigned long reason, int *oncpu) { }
> -static inline void tick_shutdown_broadcast(unsigned int *cpup) { }
> +static inline void tick_broadcast_on_off(unsigned long reason, int oncpu) { }
> +static inline void tick_shutdown_broadcast(int cpu) { }
>  static inline void tick_suspend_broadcast(void) { }
>  static inline int tick_resume_broadcast(void) { return 0; }
>  static inline void tick_broadcast_init(void) { }
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 6a93185..dc84f52 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -1245,7 +1245,7 @@ static void timekeeping_resume(void)
>  
>  	touch_softlockup_watchdog();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, NULL);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, -1);
>  
>  	/* Resume hrtimers */
>  	hrtimers_resume();
> @@ -1299,7 +1299,7 @@ static int timekeeping_suspend(void)
>  	write_seqcount_end(&tk_core.seq);
>  	raw_spin_unlock_irqrestore(&timekeeper_lock, flags);
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, NULL);
> +	clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, -1);
>  	clocksource_suspend();
>  	clockevents_suspend();
>  
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 15:40:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 15:40:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2M8C-0007to-41; Sat, 20 Dec 2014 15:39: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 1Y2M8A-0007tj-Eg
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 15:39:46 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	B4/55-28296-14895945; Sat, 20 Dec 2014 15:39:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419089983!14858125!1
X-Originating-IP: [66.165.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 986 invoked from network); 20 Dec 2014 15:39:44 -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;
	20 Dec 2014 15:39:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,613,1413244800"; d="scan'208";a="206584242"
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.210.2; Sat, 20 Dec 2014 10:39: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 1Y2M85-0003Un-B3;
	Sat, 20 Dec 2014 15:39:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2M85-0002a8-5F;
	Sat, 20 Dec 2014 15:39:41 +0000
Date: Sat, 20 Dec 2014 15:39:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32524-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] 32524: 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 32524 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32524/

Failures :-/ but no regressions.

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-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-xl          10 migrate-support-check        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-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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                d790be3863b28fd22e0781c1a3ddefcbfd5f7086
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1963 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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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-linus
+ revision=d790be3863b28fd22e0781c1a3ddefcbfd5f7086
+ . 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-linus d790be3863b28fd22e0781c1a3ddefcbfd5f7086
+ branch=linux-linus
+ revision=d790be3863b28fd22e0781c1a3ddefcbfd5f7086
+ . 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-linus
+ '[' 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/torvalds/linux-2.6.git = x ']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git = x ']'
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-linus
++ : 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-linus
+ 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-linus
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ : master
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ : tested/linux-linus
+ : tested/linux-linus
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git d790be3863b28fd22e0781c1a3ddefcbfd5f7086:tested/linux-linus
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   9f76628..d790be3  d790be3863b28fd22e0781c1a3ddefcbfd5f7086 -> tested/linux-linus
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 15:40:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 15:40:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2M8C-0007to-41; Sat, 20 Dec 2014 15:39: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 1Y2M8A-0007tj-Eg
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 15:39:46 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	B4/55-28296-14895945; Sat, 20 Dec 2014 15:39:45 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419089983!14858125!1
X-Originating-IP: [66.165.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 986 invoked from network); 20 Dec 2014 15:39:44 -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;
	20 Dec 2014 15:39:44 -0000
X-IronPort-AV: E=Sophos;i="5.07,613,1413244800"; d="scan'208";a="206584242"
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.210.2; Sat, 20 Dec 2014 10:39: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 1Y2M85-0003Un-B3;
	Sat, 20 Dec 2014 15:39:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2M85-0002a8-5F;
	Sat, 20 Dec 2014 15:39:41 +0000
Date: Sat, 20 Dec 2014 15:39:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32524-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] 32524: 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 32524 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32524/

Failures :-/ but no regressions.

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-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-xl          10 migrate-support-check        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-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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                d790be3863b28fd22e0781c1a3ddefcbfd5f7086
baseline version:
 linux                9f76628da20f96a179ca62b504886f99ecc29223

------------------------------------------------------------
1963 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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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-linus
+ revision=d790be3863b28fd22e0781c1a3ddefcbfd5f7086
+ . 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-linus d790be3863b28fd22e0781c1a3ddefcbfd5f7086
+ branch=linux-linus
+ revision=d790be3863b28fd22e0781c1a3ddefcbfd5f7086
+ . 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-linus
+ '[' 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/torvalds/linux-2.6.git = x ']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git = x ']'
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-linus
++ : 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-linus
+ 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-linus
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ : master
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ : tested/linux-linus
+ : tested/linux-linus
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git d790be3863b28fd22e0781c1a3ddefcbfd5f7086:tested/linux-linus
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   9f76628..d790be3  d790be3863b28fd22e0781c1a3ddefcbfd5f7086 -> tested/linux-linus
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 18:00:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 18:00:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2OKB-0004Tf-GH; Sat, 20 Dec 2014 18:00:19 +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 1Y2OK9-0004Ta-PK
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 18:00:17 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	AA/0E-08051-039B5945; Sat, 20 Dec 2014 18:00:16 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1419098414!16374800!1
X-Originating-IP: [209.85.220.46]
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 13673 invoked from network); 20 Dec 2014 18:00:15 -0000
Received: from mail-pa0-f46.google.com (HELO mail-pa0-f46.google.com)
	(209.85.220.46)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2014 18:00:15 -0000
Received: by mail-pa0-f46.google.com with SMTP id lf10so3229181pab.19
	for <xen-devel@lists.xenproject.org>;
	Sat, 20 Dec 2014 10:00:13 -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=SCvdYImUPqUdO147ba2K2R2fl5fdt2QUBIQ01osAJCc=;
	b=WRE4m82Bg0TyigGeirCD/MF/lWevgnwAdhvbkglMWcv5p7pJorXn0DkgxmuhUNYUrq
	KggvDwRolxjgVqPWdZWuun8SYuFRkovwt3cFD0DYCb3gjWtjB9sChNqFRfJh3gacofzQ
	+svmQHUjC5sk9OPSNudvJtF/FbbpDmLAlrdjrzPOVtxvmAL6n5QpQT6Rlb5eOkiFAZKB
	ECAzKz0MGLunRBFyYZn+1aEgPJhOkeM0ySzm9zPPSqhDsGgYag2o5aSrzczVdYLdCVQ+
	brpG9R17GKkkW7z8Ib5xJCWHkkiLysj55XJl/092AN4tetrw9tT6Eq/ebqfBbDLlsl5o
	gPew==
X-Received: by 10.66.178.198 with SMTP id da6mr22151034pac.126.1419098413880; 
	Sat, 20 Dec 2014 10:00:13 -0800 (PST)
Received: from ?IPv6:2601:9:8181:3c00:ddec:b554:4137:da53?
	([2601:9:8181:3c00:ddec:b554:4137:da53])
	by mx.google.com with ESMTPSA id
	pb6sm13035019pbb.13.2014.12.20.10.00.12
	(version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128);
	Sat, 20 Dec 2014 10:00:13 -0800 (PST)
Message-ID: <1419098412.11185.8.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 20 Dec 2014 10:00:12 -0800
In-Reply-To: <20141220065529.GA2033@gondor.apana.org.au>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<20141220003636.GA32187@gondor.apana.org.au>
	<1419039288.11185.4.camel@edumazet-glaptop2.roam.corp.google.com>
	<20141219.214000.819506179607476836.davem@davemloft.net>
	<20141220065529.GA2033@gondor.apana.org.au>
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, edumazet@google.com, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] net: Detect drivers that reschedule NAPI and
	exhaust budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-20 at 17:55 +1100, Herbert Xu wrote:

> -- >8 --
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) required drivers to leave poll_list
> empty if the entire budget is consumed.
> 
> We have already had two broken drivers so let's add a check for
> this.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index f411c28..47fdc5c 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4620,7 +4620,13 @@ static void net_rx_action(struct softirq_action *h)
>  					 */
>  					napi_gro_flush(n, HZ >= 1000);
>  				}
> -				list_add_tail(&n->poll_list, &repoll);
> +				/* Some drivers may have called napi_schedule
> +				 * prior to exhausting their budget.
> +				 */
> +				if (unlikely(!list_empty(&n->poll_list)))
> +					pr_warn("%s: Budget exhausted after napi rescheduled\n", n->dev ? n->dev->name : "backlog");
> +				else
> +					list_add_tail(&n->poll_list, &repoll);
>  			}
>  		}
>  
> Thanks,

OK, but could you :
1) use pr_warn_once()
2) split the too long line
	pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
		     n->dev ? n->dev->name : "backlog");

Thanks Herbert !



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 18:00:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 18:00:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2OKB-0004Tf-GH; Sat, 20 Dec 2014 18:00:19 +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 1Y2OK9-0004Ta-PK
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 18:00:17 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	AA/0E-08051-039B5945; Sat, 20 Dec 2014 18:00:16 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1419098414!16374800!1
X-Originating-IP: [209.85.220.46]
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 13673 invoked from network); 20 Dec 2014 18:00:15 -0000
Received: from mail-pa0-f46.google.com (HELO mail-pa0-f46.google.com)
	(209.85.220.46)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2014 18:00:15 -0000
Received: by mail-pa0-f46.google.com with SMTP id lf10so3229181pab.19
	for <xen-devel@lists.xenproject.org>;
	Sat, 20 Dec 2014 10:00:13 -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=SCvdYImUPqUdO147ba2K2R2fl5fdt2QUBIQ01osAJCc=;
	b=WRE4m82Bg0TyigGeirCD/MF/lWevgnwAdhvbkglMWcv5p7pJorXn0DkgxmuhUNYUrq
	KggvDwRolxjgVqPWdZWuun8SYuFRkovwt3cFD0DYCb3gjWtjB9sChNqFRfJh3gacofzQ
	+svmQHUjC5sk9OPSNudvJtF/FbbpDmLAlrdjrzPOVtxvmAL6n5QpQT6Rlb5eOkiFAZKB
	ECAzKz0MGLunRBFyYZn+1aEgPJhOkeM0ySzm9zPPSqhDsGgYag2o5aSrzczVdYLdCVQ+
	brpG9R17GKkkW7z8Ib5xJCWHkkiLysj55XJl/092AN4tetrw9tT6Eq/ebqfBbDLlsl5o
	gPew==
X-Received: by 10.66.178.198 with SMTP id da6mr22151034pac.126.1419098413880; 
	Sat, 20 Dec 2014 10:00:13 -0800 (PST)
Received: from ?IPv6:2601:9:8181:3c00:ddec:b554:4137:da53?
	([2601:9:8181:3c00:ddec:b554:4137:da53])
	by mx.google.com with ESMTPSA id
	pb6sm13035019pbb.13.2014.12.20.10.00.12
	(version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128);
	Sat, 20 Dec 2014 10:00:13 -0800 (PST)
Message-ID: <1419098412.11185.8.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 20 Dec 2014 10:00:12 -0800
In-Reply-To: <20141220065529.GA2033@gondor.apana.org.au>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<20141220003636.GA32187@gondor.apana.org.au>
	<1419039288.11185.4.camel@edumazet-glaptop2.roam.corp.google.com>
	<20141219.214000.819506179607476836.davem@davemloft.net>
	<20141220065529.GA2033@gondor.apana.org.au>
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, edumazet@google.com, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] net: Detect drivers that reschedule NAPI and
	exhaust budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-12-20 at 17:55 +1100, Herbert Xu wrote:

> -- >8 --
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) required drivers to leave poll_list
> empty if the entire budget is consumed.
> 
> We have already had two broken drivers so let's add a check for
> this.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index f411c28..47fdc5c 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4620,7 +4620,13 @@ static void net_rx_action(struct softirq_action *h)
>  					 */
>  					napi_gro_flush(n, HZ >= 1000);
>  				}
> -				list_add_tail(&n->poll_list, &repoll);
> +				/* Some drivers may have called napi_schedule
> +				 * prior to exhausting their budget.
> +				 */
> +				if (unlikely(!list_empty(&n->poll_list)))
> +					pr_warn("%s: Budget exhausted after napi rescheduled\n", n->dev ? n->dev->name : "backlog");
> +				else
> +					list_add_tail(&n->poll_list, &repoll);
>  			}
>  		}
>  
> Thanks,

OK, but could you :
1) use pr_warn_once()
2) split the too long line
	pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
		     n->dev ? n->dev->name : "backlog");

Thanks Herbert !



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 19:48:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 19:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2Q0W-0007xe-9B; Sat, 20 Dec 2014 19:48:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.kilari@gmail.com>) id 1Y2Q0V-0007xW-IP
	for xen-devel@lists.xen.org; Sat, 20 Dec 2014 19:48:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	05/31-15461-672D5945; Sat, 20 Dec 2014 19:48:06 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1419104885!16968929!1
X-Originating-IP: [209.85.223.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15322 invoked from network); 20 Dec 2014 19:48:06 -0000
Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com)
	(209.85.223.177)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2014 19:48:06 -0000
Received: by mail-ie0-f177.google.com with SMTP id rd18so2495921iec.22
	for <xen-devel@lists.xen.org>; Sat, 20 Dec 2014 11:48:05 -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:cc:content-type;
	bh=aOMSKG/JnU4tawWFditFKJ34Uvb5yJOfq0+fXStQ/9c=;
	b=G2r+orKYAWkSdtsp9r6Nlm5Vd6KYRIHiz89b9WqPbOg2vaFil+bRklJwG8pYOScA00
	GUQvB39E3oZBzp+NG7bX0NOunixeP+aSsX4bIAmIb3mTn16visiTP4pwZ3HPShIh8o7k
	W88UTCmnvawln1fNQsTItDyPX/dvrAyW0cq3rqOaxN6labogDU7chI0q9QKx5MfvthCh
	yjBR6lBD3fOzvObXBhTN65D6fxSws7UM76kYiZ7IpND6Sw8E/x5iAMMM5+d2KUIGQH77
	UQWsisGtMnf6fFub3toQIrkeRJSSTL7rMxSwKHxCEG4Y/pvJxrfqwdAd37FNnOZkgKxT
	W2xQ==
MIME-Version: 1.0
X-Received: by 10.50.234.194 with SMTP id ug2mr9279388igc.39.1419104885130;
	Sat, 20 Dec 2014 11:48:05 -0800 (PST)
Received: by 10.64.84.4 with HTTP; Sat, 20 Dec 2014 11:48:05 -0800 (PST)
Date: Sun, 21 Dec 2014 01:18:05 +0530
Message-ID: <CALicx6tEQ+MXu51UN55KtVwDRPECNgqnvMaAM_MivubB7AsO+g@mail.gmail.com>
From: Vijay Kilari <vijay.kilari@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] xen/arm: VCPU scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

   I want to know what is the criteria followed in Xen for scheduling VCPUs.

Assume below scenario:

 - Run 2 VPCUs on 1 Physical CPU
 - VCPUs does not trap on WFE or WFE ( either by WFI/WFE trap is
disabled in HCR OR no WFE/WFI in EL1 is executed).

In such scenario, does Xen assumes that VCPU0 is always running because it has
NOT trapped on WFI and WFE (not yielded voluntary) and does not
schedule VCPU1? or is it time shared?

Regards
Vijay

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 19:48:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 19:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2Q0W-0007xe-9B; Sat, 20 Dec 2014 19:48:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.kilari@gmail.com>) id 1Y2Q0V-0007xW-IP
	for xen-devel@lists.xen.org; Sat, 20 Dec 2014 19:48:07 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	05/31-15461-672D5945; Sat, 20 Dec 2014 19:48:06 +0000
X-Env-Sender: vijay.kilari@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1419104885!16968929!1
X-Originating-IP: [209.85.223.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15322 invoked from network); 20 Dec 2014 19:48:06 -0000
Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com)
	(209.85.223.177)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Dec 2014 19:48:06 -0000
Received: by mail-ie0-f177.google.com with SMTP id rd18so2495921iec.22
	for <xen-devel@lists.xen.org>; Sat, 20 Dec 2014 11:48:05 -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:cc:content-type;
	bh=aOMSKG/JnU4tawWFditFKJ34Uvb5yJOfq0+fXStQ/9c=;
	b=G2r+orKYAWkSdtsp9r6Nlm5Vd6KYRIHiz89b9WqPbOg2vaFil+bRklJwG8pYOScA00
	GUQvB39E3oZBzp+NG7bX0NOunixeP+aSsX4bIAmIb3mTn16visiTP4pwZ3HPShIh8o7k
	W88UTCmnvawln1fNQsTItDyPX/dvrAyW0cq3rqOaxN6labogDU7chI0q9QKx5MfvthCh
	yjBR6lBD3fOzvObXBhTN65D6fxSws7UM76kYiZ7IpND6Sw8E/x5iAMMM5+d2KUIGQH77
	UQWsisGtMnf6fFub3toQIrkeRJSSTL7rMxSwKHxCEG4Y/pvJxrfqwdAd37FNnOZkgKxT
	W2xQ==
MIME-Version: 1.0
X-Received: by 10.50.234.194 with SMTP id ug2mr9279388igc.39.1419104885130;
	Sat, 20 Dec 2014 11:48:05 -0800 (PST)
Received: by 10.64.84.4 with HTTP; Sat, 20 Dec 2014 11:48:05 -0800 (PST)
Date: Sun, 21 Dec 2014 01:18:05 +0530
Message-ID: <CALicx6tEQ+MXu51UN55KtVwDRPECNgqnvMaAM_MivubB7AsO+g@mail.gmail.com>
From: Vijay Kilari <vijay.kilari@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Julien Grall <julien.grall@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] xen/arm: VCPU scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

   I want to know what is the criteria followed in Xen for scheduling VCPUs.

Assume below scenario:

 - Run 2 VPCUs on 1 Physical CPU
 - VCPUs does not trap on WFE or WFE ( either by WFI/WFE trap is
disabled in HCR OR no WFE/WFI in EL1 is executed).

In such scenario, does Xen assumes that VCPU0 is always running because it has
NOT trapped on WFI and WFE (not yielded voluntary) and does not
schedule VCPU1? or is it time shared?

Regards
Vijay

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 20:09:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20: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 1Y2QKP-0000Dw-5c; Sat, 20 Dec 2014 20:08:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y2QKO-0000Dr-50
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 20:08:40 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	BB/9F-23865-747D5945; Sat, 20 Dec 2014 20:08:39 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1419106116!11127720!1
X-Originating-IP: [66.165.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 22573 invoked from network); 20 Dec 2014 20:08:38 -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 Dec 2014 20:08:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,614,1413244800"; d="scan'208";a="207118608"
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.210.2; Sat, 20 Dec 2014 15:08: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 1Y2QKJ-0004lr-4d;
	Sat, 20 Dec 2014 20:08:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2QKI-0005XL-VF;
	Sat, 20 Dec 2014 20:08:34 +0000
Date: Sat, 20 Dec 2014 20:08:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32534-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] 32534: 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 32534 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32534/

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              738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd
baseline version:
 libvirt              1adda68a1b60a1f1a42bab5801e1529059d34ce4

------------------------------------------------------------
People who touched revisions under test:
  Claudio Bley <claudio.bley@gmail.com>
  Daniel P. Berrange <berrange@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=738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd
+ . 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 738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd
+ branch=libvirt
+ revision=738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd
+ . 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 738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   1adda68..738a2ae  738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd -> 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 Dec 20 20:09:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20: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 1Y2QKP-0000Dw-5c; Sat, 20 Dec 2014 20:08:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y2QKO-0000Dr-50
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 20:08:40 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	BB/9F-23865-747D5945; Sat, 20 Dec 2014 20:08:39 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1419106116!11127720!1
X-Originating-IP: [66.165.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 22573 invoked from network); 20 Dec 2014 20:08:38 -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 Dec 2014 20:08:38 -0000
X-IronPort-AV: E=Sophos;i="5.07,614,1413244800"; d="scan'208";a="207118608"
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.210.2; Sat, 20 Dec 2014 15:08: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 1Y2QKJ-0004lr-4d;
	Sat, 20 Dec 2014 20:08:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2QKI-0005XL-VF;
	Sat, 20 Dec 2014 20:08:34 +0000
Date: Sat, 20 Dec 2014 20:08:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32534-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] 32534: 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 32534 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32534/

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              738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd
baseline version:
 libvirt              1adda68a1b60a1f1a42bab5801e1529059d34ce4

------------------------------------------------------------
People who touched revisions under test:
  Claudio Bley <claudio.bley@gmail.com>
  Daniel P. Berrange <berrange@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=738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd
+ . 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 738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd
+ branch=libvirt
+ revision=738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd
+ . 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 738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   1adda68..738a2ae  738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd -> 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 Dec 20 20:15:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20: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 1Y2QQi-0000Z3-0t; Sat, 20 Dec 2014 20:15:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2QQg-0000Yy-0M
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 20:15:10 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	94/35-22819-DC8D5945; Sat, 20 Dec 2014 20:15:09 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-16.tower-206.messagelabs.com!1419106505!11618728!1
X-Originating-IP: [209.40.204.226]
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 4309 invoked from network); 20 Dec 2014 20:15:08 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 20:15:08 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2QQW-0003at-TA; Sun, 21 Dec 2014 07:15:01 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2QQP-0001o6-U3; Sun, 21 Dec 2014 07:14:54 +1100
Date: Sun, 21 Dec 2014 07:14:53 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Eric Dumazet <eric.dumazet@gmail.com>
Message-ID: <20141220201453.GA6924@gondor.apana.org.au>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<20141220003636.GA32187@gondor.apana.org.au>
	<1419039288.11185.4.camel@edumazet-glaptop2.roam.corp.google.com>
	<20141219.214000.819506179607476836.davem@davemloft.net>
	<20141220065529.GA2033@gondor.apana.org.au>
	<1419098412.11185.8.camel@edumazet-glaptop2.roam.corp.google.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1419098412.11185.8.camel@edumazet-glaptop2.roam.corp.google.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netdev@vger.kernel.org, edumazet@google.com, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [0/4] net: net_rx_action fixes and clean-ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Dec 20, 2014 at 10:00:12AM -0800, Eric Dumazet wrote:
> 
> OK, but could you :
> 1) use pr_warn_once()
> 2) split the too long line
> 	pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
> 		     n->dev ? n->dev->name : "backlog");

Sure, I'll clean it up a bit too.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 20:15:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20: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 1Y2QQi-0000Z3-0t; Sat, 20 Dec 2014 20:15:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2QQg-0000Yy-0M
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 20:15:10 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	94/35-22819-DC8D5945; Sat, 20 Dec 2014 20:15:09 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-16.tower-206.messagelabs.com!1419106505!11618728!1
X-Originating-IP: [209.40.204.226]
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 4309 invoked from network); 20 Dec 2014 20:15:08 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 20:15:08 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2QQW-0003at-TA; Sun, 21 Dec 2014 07:15:01 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2QQP-0001o6-U3; Sun, 21 Dec 2014 07:14:54 +1100
Date: Sun, 21 Dec 2014 07:14:53 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Eric Dumazet <eric.dumazet@gmail.com>
Message-ID: <20141220201453.GA6924@gondor.apana.org.au>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<20141220003636.GA32187@gondor.apana.org.au>
	<1419039288.11185.4.camel@edumazet-glaptop2.roam.corp.google.com>
	<20141219.214000.819506179607476836.davem@davemloft.net>
	<20141220065529.GA2033@gondor.apana.org.au>
	<1419098412.11185.8.camel@edumazet-glaptop2.roam.corp.google.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1419098412.11185.8.camel@edumazet-glaptop2.roam.corp.google.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netdev@vger.kernel.org, edumazet@google.com, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	David Miller <davem@davemloft.net>
Subject: [Xen-devel] [0/4] net: net_rx_action fixes and clean-ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Dec 20, 2014 at 10:00:12AM -0800, Eric Dumazet wrote:
> 
> OK, but could you :
> 1) use pr_warn_once()
> 2) split the too long line
> 	pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
> 		     n->dev ? n->dev->name : "backlog");

Sure, I'll clean it up a bit too.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 20:16:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20: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 1Y2QS6-0000e1-Gd; Sat, 20 Dec 2014 20:16:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2QS4-0000dm-Cd
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 20:16:36 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	FE/60-26652-329D5945; Sat, 20 Dec 2014 20:16:35 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-12.tower-206.messagelabs.com!1419106591!14499759!1
X-Originating-IP: [209.40.204.226]
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 7884 invoked from network); 20 Dec 2014 20:16:34 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 20:16:34 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2QRr-0003c3-Fd; Sun, 21 Dec 2014 07:16:23 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2QRq-0001pW-Tn; Sun, 21 Dec 2014 07:16:22 +1100
References: <20141220201453.GA6924@gondor.apana.org.au>
To: Eric Dumazet <eric.dumazet@gmail.com>, David Miller <davem@davemloft.net>,
	david.vrabel@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xenproject.org, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com, edumazet@google.com
Message-Id: <E1Y2QRq-0001pW-Tn@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:22 +1100
Subject: [Xen-devel] [PATCH 2/4] net: Detect drivers that reschedule NAPI
	and exhaust budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) required drivers to leave poll_list
empty if the entire budget is consumed.

We have already had two broken drivers so let's add a check for
this.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---

 net/core/dev.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index f7c4f4e..4a9c424 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4602,6 +4602,15 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)
 		napi_gro_flush(n, HZ >= 1000);
 	}
 
+	/* Some drivers may have called napi_schedule
+	 * prior to exhausting their budget.
+	 */
+	if (unlikely(!list_empty(&n->poll_list))) {
+		pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
+			     n->dev ? n->dev->name : "backlog");
+		goto out_unlock;
+	}
+
 	list_add_tail(&n->poll_list, repoll);
 
 out_unlock:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 20:16:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20: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 1Y2QS6-0000e1-Gd; Sat, 20 Dec 2014 20:16:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2QS4-0000dm-Cd
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 20:16:36 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	FE/60-26652-329D5945; Sat, 20 Dec 2014 20:16:35 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-12.tower-206.messagelabs.com!1419106591!14499759!1
X-Originating-IP: [209.40.204.226]
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 7884 invoked from network); 20 Dec 2014 20:16:34 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 20:16:34 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2QRr-0003c3-Fd; Sun, 21 Dec 2014 07:16:23 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2QRq-0001pW-Tn; Sun, 21 Dec 2014 07:16:22 +1100
References: <20141220201453.GA6924@gondor.apana.org.au>
To: Eric Dumazet <eric.dumazet@gmail.com>, David Miller <davem@davemloft.net>,
	david.vrabel@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xenproject.org, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com, edumazet@google.com
Message-Id: <E1Y2QRq-0001pW-Tn@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:22 +1100
Subject: [Xen-devel] [PATCH 2/4] net: Detect drivers that reschedule NAPI
	and exhaust budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) required drivers to leave poll_list
empty if the entire budget is consumed.

We have already had two broken drivers so let's add a check for
this.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---

 net/core/dev.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index f7c4f4e..4a9c424 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4602,6 +4602,15 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)
 		napi_gro_flush(n, HZ >= 1000);
 	}
 
+	/* Some drivers may have called napi_schedule
+	 * prior to exhausting their budget.
+	 */
+	if (unlikely(!list_empty(&n->poll_list))) {
+		pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
+			     n->dev ? n->dev->name : "backlog");
+		goto out_unlock;
+	}
+
 	list_add_tail(&n->poll_list, repoll);
 
 out_unlock:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 20:16:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20: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 1Y2QS6-0000e8-Ri; Sat, 20 Dec 2014 20:16:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2QS4-0000do-Ma
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 20:16:36 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	91/85-25547-329D5945; Sat, 20 Dec 2014 20:16:35 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-12.tower-31.messagelabs.com!1419106592!14772493!1
X-Originating-IP: [209.40.204.226]
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 28247 invoked from network); 20 Dec 2014 20:16:34 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 20:16:34 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2QRr-0003bw-70; Sun, 21 Dec 2014 07:16:23 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2QRp-0001pD-J7; Sun, 21 Dec 2014 07:16:21 +1100
References: <20141220201453.GA6924@gondor.apana.org.au>
To: Eric Dumazet <eric.dumazet@gmail.com>, David Miller <davem@davemloft.net>,
	david.vrabel@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xenproject.org, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com, edumazet@google.com
Message-Id: <E1Y2QRp-0001pD-J7@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:21 +1100
Subject: [Xen-devel] [PATCH 1/4] net: Move napi polling code out of
	net_rx_action
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 creates a new function napi_poll and moves the napi
polling code from net_rx_action into it.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---

 net/core/dev.c |   98 +++++++++++++++++++++++++++++++--------------------------
 1 file changed, 54 insertions(+), 44 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index f411c28..f7c4f4e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4557,6 +4557,59 @@ void netif_napi_del(struct napi_struct *napi)
 }
 EXPORT_SYMBOL(netif_napi_del);
 
+static int napi_poll(struct napi_struct *n, struct list_head *repoll)
+{
+	void *have;
+	int work, weight;
+
+	list_del_init(&n->poll_list);
+
+	have = netpoll_poll_lock(n);
+
+	weight = n->weight;
+
+	/* This NAPI_STATE_SCHED test is for avoiding a race
+	 * with netpoll's poll_napi().  Only the entity which
+	 * obtains the lock and sees NAPI_STATE_SCHED set will
+	 * actually make the ->poll() call.  Therefore we avoid
+	 * accidentally calling ->poll() when NAPI is not scheduled.
+	 */
+	work = 0;
+	if (test_bit(NAPI_STATE_SCHED, &n->state)) {
+		work = n->poll(n, weight);
+		trace_napi_poll(n);
+	}
+
+	WARN_ON_ONCE(work > weight);
+
+	if (likely(work < weight))
+		goto out_unlock;
+
+	/* Drivers must not modify the NAPI state if they
+	 * consume the entire weight.  In such cases this code
+	 * still "owns" the NAPI instance and therefore can
+	 * move the instance around on the list at-will.
+	 */
+	if (unlikely(napi_disable_pending(n))) {
+		napi_complete(n);
+		goto out_unlock;
+	}
+
+	if (n->gro_list) {
+		/* flush too old packets
+		 * If HZ < 1000, flush all packets.
+		 */
+		napi_gro_flush(n, HZ >= 1000);
+	}
+
+	list_add_tail(&n->poll_list, repoll);
+
+out_unlock:
+	netpoll_poll_unlock(have);
+
+	return work;
+}
+
 static void net_rx_action(struct softirq_action *h)
 {
 	struct softnet_data *sd = this_cpu_ptr(&softnet_data);
@@ -4564,7 +4617,6 @@ static void net_rx_action(struct softirq_action *h)
 	int budget = netdev_budget;
 	LIST_HEAD(list);
 	LIST_HEAD(repoll);
-	void *have;
 
 	local_irq_disable();
 	list_splice_init(&sd->poll_list, &list);
@@ -4572,7 +4624,6 @@ static void net_rx_action(struct softirq_action *h)
 
 	while (!list_empty(&list)) {
 		struct napi_struct *n;
-		int work, weight;
 
 		/* If softirq window is exhausted then punt.
 		 * Allow this to run for 2 jiffies since which will allow
@@ -4583,48 +4634,7 @@ static void net_rx_action(struct softirq_action *h)
 
 
 		n = list_first_entry(&list, struct napi_struct, poll_list);
-		list_del_init(&n->poll_list);
-
-		have = netpoll_poll_lock(n);
-
-		weight = n->weight;
-
-		/* This NAPI_STATE_SCHED test is for avoiding a race
-		 * with netpoll's poll_napi().  Only the entity which
-		 * obtains the lock and sees NAPI_STATE_SCHED set will
-		 * actually make the ->poll() call.  Therefore we avoid
-		 * accidentally calling ->poll() when NAPI is not scheduled.
-		 */
-		work = 0;
-		if (test_bit(NAPI_STATE_SCHED, &n->state)) {
-			work = n->poll(n, weight);
-			trace_napi_poll(n);
-		}
-
-		WARN_ON_ONCE(work > weight);
-
-		budget -= work;
-
-		/* Drivers must not modify the NAPI state if they
-		 * consume the entire weight.  In such cases this code
-		 * still "owns" the NAPI instance and therefore can
-		 * move the instance around on the list at-will.
-		 */
-		if (unlikely(work == weight)) {
-			if (unlikely(napi_disable_pending(n))) {
-				napi_complete(n);
-			} else {
-				if (n->gro_list) {
-					/* flush too old packets
-					 * If HZ < 1000, flush all packets.
-					 */
-					napi_gro_flush(n, HZ >= 1000);
-				}
-				list_add_tail(&n->poll_list, &repoll);
-			}
-		}
-
-		netpoll_poll_unlock(have);
+		budget -= napi_poll(n, &repoll);
 	}
 
 	if (!sd_has_rps_ipi_waiting(sd) &&

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 20:16:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20: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 1Y2QS6-0000e8-Ri; Sat, 20 Dec 2014 20:16:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2QS4-0000do-Ma
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 20:16:36 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	91/85-25547-329D5945; Sat, 20 Dec 2014 20:16:35 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-12.tower-31.messagelabs.com!1419106592!14772493!1
X-Originating-IP: [209.40.204.226]
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 28247 invoked from network); 20 Dec 2014 20:16:34 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 20:16:34 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2QRr-0003bw-70; Sun, 21 Dec 2014 07:16:23 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2QRp-0001pD-J7; Sun, 21 Dec 2014 07:16:21 +1100
References: <20141220201453.GA6924@gondor.apana.org.au>
To: Eric Dumazet <eric.dumazet@gmail.com>, David Miller <davem@davemloft.net>,
	david.vrabel@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xenproject.org, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com, edumazet@google.com
Message-Id: <E1Y2QRp-0001pD-J7@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:21 +1100
Subject: [Xen-devel] [PATCH 1/4] net: Move napi polling code out of
	net_rx_action
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 creates a new function napi_poll and moves the napi
polling code from net_rx_action into it.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---

 net/core/dev.c |   98 +++++++++++++++++++++++++++++++--------------------------
 1 file changed, 54 insertions(+), 44 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index f411c28..f7c4f4e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4557,6 +4557,59 @@ void netif_napi_del(struct napi_struct *napi)
 }
 EXPORT_SYMBOL(netif_napi_del);
 
+static int napi_poll(struct napi_struct *n, struct list_head *repoll)
+{
+	void *have;
+	int work, weight;
+
+	list_del_init(&n->poll_list);
+
+	have = netpoll_poll_lock(n);
+
+	weight = n->weight;
+
+	/* This NAPI_STATE_SCHED test is for avoiding a race
+	 * with netpoll's poll_napi().  Only the entity which
+	 * obtains the lock and sees NAPI_STATE_SCHED set will
+	 * actually make the ->poll() call.  Therefore we avoid
+	 * accidentally calling ->poll() when NAPI is not scheduled.
+	 */
+	work = 0;
+	if (test_bit(NAPI_STATE_SCHED, &n->state)) {
+		work = n->poll(n, weight);
+		trace_napi_poll(n);
+	}
+
+	WARN_ON_ONCE(work > weight);
+
+	if (likely(work < weight))
+		goto out_unlock;
+
+	/* Drivers must not modify the NAPI state if they
+	 * consume the entire weight.  In such cases this code
+	 * still "owns" the NAPI instance and therefore can
+	 * move the instance around on the list at-will.
+	 */
+	if (unlikely(napi_disable_pending(n))) {
+		napi_complete(n);
+		goto out_unlock;
+	}
+
+	if (n->gro_list) {
+		/* flush too old packets
+		 * If HZ < 1000, flush all packets.
+		 */
+		napi_gro_flush(n, HZ >= 1000);
+	}
+
+	list_add_tail(&n->poll_list, repoll);
+
+out_unlock:
+	netpoll_poll_unlock(have);
+
+	return work;
+}
+
 static void net_rx_action(struct softirq_action *h)
 {
 	struct softnet_data *sd = this_cpu_ptr(&softnet_data);
@@ -4564,7 +4617,6 @@ static void net_rx_action(struct softirq_action *h)
 	int budget = netdev_budget;
 	LIST_HEAD(list);
 	LIST_HEAD(repoll);
-	void *have;
 
 	local_irq_disable();
 	list_splice_init(&sd->poll_list, &list);
@@ -4572,7 +4624,6 @@ static void net_rx_action(struct softirq_action *h)
 
 	while (!list_empty(&list)) {
 		struct napi_struct *n;
-		int work, weight;
 
 		/* If softirq window is exhausted then punt.
 		 * Allow this to run for 2 jiffies since which will allow
@@ -4583,48 +4634,7 @@ static void net_rx_action(struct softirq_action *h)
 
 
 		n = list_first_entry(&list, struct napi_struct, poll_list);
-		list_del_init(&n->poll_list);
-
-		have = netpoll_poll_lock(n);
-
-		weight = n->weight;
-
-		/* This NAPI_STATE_SCHED test is for avoiding a race
-		 * with netpoll's poll_napi().  Only the entity which
-		 * obtains the lock and sees NAPI_STATE_SCHED set will
-		 * actually make the ->poll() call.  Therefore we avoid
-		 * accidentally calling ->poll() when NAPI is not scheduled.
-		 */
-		work = 0;
-		if (test_bit(NAPI_STATE_SCHED, &n->state)) {
-			work = n->poll(n, weight);
-			trace_napi_poll(n);
-		}
-
-		WARN_ON_ONCE(work > weight);
-
-		budget -= work;
-
-		/* Drivers must not modify the NAPI state if they
-		 * consume the entire weight.  In such cases this code
-		 * still "owns" the NAPI instance and therefore can
-		 * move the instance around on the list at-will.
-		 */
-		if (unlikely(work == weight)) {
-			if (unlikely(napi_disable_pending(n))) {
-				napi_complete(n);
-			} else {
-				if (n->gro_list) {
-					/* flush too old packets
-					 * If HZ < 1000, flush all packets.
-					 */
-					napi_gro_flush(n, HZ >= 1000);
-				}
-				list_add_tail(&n->poll_list, &repoll);
-			}
-		}
-
-		netpoll_poll_unlock(have);
+		budget -= napi_poll(n, &repoll);
 	}
 
 	if (!sd_has_rps_ipi_waiting(sd) &&

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 20:16:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20:16:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2QS9-0000fN-10; Sat, 20 Dec 2014 20:16:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2QS7-0000e0-00
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 20:16:39 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	85/AB-18267-629D5945; Sat, 20 Dec 2014 20:16:38 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-14.tower-31.messagelabs.com!1419106594!12408618!1
X-Originating-IP: [209.40.204.226]
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 1839 invoked from network); 20 Dec 2014 20:16:37 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 20:16:37 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2QRt-0003cI-Ub; Sun, 21 Dec 2014 07:16:26 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2QRs-0001q5-6u; Sun, 21 Dec 2014 07:16:24 +1100
References: <20141220201453.GA6924@gondor.apana.org.au>
To: Eric Dumazet <eric.dumazet@gmail.com>, David Miller <davem@davemloft.net>,
	david.vrabel@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xenproject.org, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com, edumazet@google.com
Message-Id: <E1Y2QRs-0001q5-6u@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:24 +1100
Subject: [Xen-devel] [PATCH 3/4] net: Always poll at least one device in
	net_rx_action
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 only perform the softnet_break check after we have polled
at least one device in net_rx_action.  Otherwise a zero or negative
setting of netdev_budget can lock up the whole system.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---

 net/core/dev.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 4a9c424..22b0fb2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4634,16 +4634,15 @@ static void net_rx_action(struct softirq_action *h)
 	while (!list_empty(&list)) {
 		struct napi_struct *n;
 
+		n = list_first_entry(&list, struct napi_struct, poll_list);
+		budget -= napi_poll(n, &repoll);
+
 		/* If softirq window is exhausted then punt.
 		 * Allow this to run for 2 jiffies since which will allow
 		 * an average latency of 1.5/HZ.
 		 */
 		if (unlikely(budget <= 0 || time_after_eq(jiffies, time_limit)))
 			goto softnet_break;
-
-
-		n = list_first_entry(&list, struct napi_struct, poll_list);
-		budget -= napi_poll(n, &repoll);
 	}
 
 	if (!sd_has_rps_ipi_waiting(sd) &&

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 20:16:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20:16:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2QS9-0000fN-10; Sat, 20 Dec 2014 20:16:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2QS7-0000e0-00
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 20:16:39 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	85/AB-18267-629D5945; Sat, 20 Dec 2014 20:16:38 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-14.tower-31.messagelabs.com!1419106594!12408618!1
X-Originating-IP: [209.40.204.226]
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 1839 invoked from network); 20 Dec 2014 20:16:37 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-14.tower-31.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 20:16:37 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2QRt-0003cI-Ub; Sun, 21 Dec 2014 07:16:26 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2QRs-0001q5-6u; Sun, 21 Dec 2014 07:16:24 +1100
References: <20141220201453.GA6924@gondor.apana.org.au>
To: Eric Dumazet <eric.dumazet@gmail.com>, David Miller <davem@davemloft.net>,
	david.vrabel@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xenproject.org, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com, edumazet@google.com
Message-Id: <E1Y2QRs-0001q5-6u@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:24 +1100
Subject: [Xen-devel] [PATCH 3/4] net: Always poll at least one device in
	net_rx_action
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 only perform the softnet_break check after we have polled
at least one device in net_rx_action.  Otherwise a zero or negative
setting of netdev_budget can lock up the whole system.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---

 net/core/dev.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 4a9c424..22b0fb2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4634,16 +4634,15 @@ static void net_rx_action(struct softirq_action *h)
 	while (!list_empty(&list)) {
 		struct napi_struct *n;
 
+		n = list_first_entry(&list, struct napi_struct, poll_list);
+		budget -= napi_poll(n, &repoll);
+
 		/* If softirq window is exhausted then punt.
 		 * Allow this to run for 2 jiffies since which will allow
 		 * an average latency of 1.5/HZ.
 		 */
 		if (unlikely(budget <= 0 || time_after_eq(jiffies, time_limit)))
 			goto softnet_break;
-
-
-		n = list_first_entry(&list, struct napi_struct, poll_list);
-		budget -= napi_poll(n, &repoll);
 	}
 
 	if (!sd_has_rps_ipi_waiting(sd) &&

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 20:16:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20:16:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2QS9-0000g9-Kz; Sat, 20 Dec 2014 20:16:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2QS7-0000eC-C5
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 20:16:39 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	72/0B-20609-629D5945; Sat, 20 Dec 2014 20:16:38 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-11.tower-27.messagelabs.com!1419106594!13058313!1
X-Originating-IP: [209.40.204.226]
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 24241 invoked from network); 20 Dec 2014 20:16:37 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 20:16:37 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2QRu-0003cN-9o; Sun, 21 Dec 2014 07:16:26 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2QRt-0001qq-Lp; Sun, 21 Dec 2014 07:16:25 +1100
References: <20141220201453.GA6924@gondor.apana.org.au>
To: Eric Dumazet <eric.dumazet@gmail.com>, David Miller <davem@davemloft.net>,
	david.vrabel@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xenproject.org, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com, edumazet@google.com
Message-Id: <E1Y2QRt-0001qq-Lp@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:25 +1100
Subject: [Xen-devel] [PATCH 4/4] net: Rearrange loop in net_rx_action
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 rearranges the loop in net_rx_action to reduce the
amount of jumping back and forth when reading the code.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---

 net/core/dev.c |   26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 22b0fb2..dd565a5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4631,9 +4631,15 @@ static void net_rx_action(struct softirq_action *h)
 	list_splice_init(&sd->poll_list, &list);
 	local_irq_enable();
 
-	while (!list_empty(&list)) {
+	for (;;) {
 		struct napi_struct *n;
 
+		if (list_empty(&list)) {
+			if (!sd_has_rps_ipi_waiting(sd) && list_empty(&repoll))
+				return;
+			break;
+		}
+
 		n = list_first_entry(&list, struct napi_struct, poll_list);
 		budget -= napi_poll(n, &repoll);
 
@@ -4641,15 +4647,13 @@ static void net_rx_action(struct softirq_action *h)
 		 * Allow this to run for 2 jiffies since which will allow
 		 * an average latency of 1.5/HZ.
 		 */
-		if (unlikely(budget <= 0 || time_after_eq(jiffies, time_limit)))
-			goto softnet_break;
+		if (unlikely(budget <= 0 ||
+			     time_after_eq(jiffies, time_limit))) {
+			sd->time_squeeze++;
+			break;
+		}
 	}
 
-	if (!sd_has_rps_ipi_waiting(sd) &&
-	    list_empty(&list) &&
-	    list_empty(&repoll))
-		return;
-out:
 	local_irq_disable();
 
 	list_splice_tail_init(&sd->poll_list, &list);
@@ -4659,12 +4663,6 @@ out:
 		__raise_softirq_irqoff(NET_RX_SOFTIRQ);
 
 	net_rps_action_and_irq_enable(sd);
-
-	return;
-
-softnet_break:
-	sd->time_squeeze++;
-	goto out;
 }
 
 struct netdev_adjacent {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 20:16:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20:16:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2QS9-0000g9-Kz; Sat, 20 Dec 2014 20:16:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2QS7-0000eC-C5
	for xen-devel@lists.xenproject.org; Sat, 20 Dec 2014 20:16:39 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	72/0B-20609-629D5945; Sat, 20 Dec 2014 20:16:38 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-11.tower-27.messagelabs.com!1419106594!13058313!1
X-Originating-IP: [209.40.204.226]
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 24241 invoked from network); 20 Dec 2014 20:16:37 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 20 Dec 2014 20:16:37 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2QRu-0003cN-9o; Sun, 21 Dec 2014 07:16:26 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2QRt-0001qq-Lp; Sun, 21 Dec 2014 07:16:25 +1100
References: <20141220201453.GA6924@gondor.apana.org.au>
To: Eric Dumazet <eric.dumazet@gmail.com>, David Miller <davem@davemloft.net>,
	david.vrabel@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xenproject.org, konrad.wilk@oracle.com,
	boris.ostrovsky@oracle.com, edumazet@google.com
Message-Id: <E1Y2QRt-0001qq-Lp@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:25 +1100
Subject: [Xen-devel] [PATCH 4/4] net: Rearrange loop in net_rx_action
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 rearranges the loop in net_rx_action to reduce the
amount of jumping back and forth when reading the code.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---

 net/core/dev.c |   26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 22b0fb2..dd565a5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4631,9 +4631,15 @@ static void net_rx_action(struct softirq_action *h)
 	list_splice_init(&sd->poll_list, &list);
 	local_irq_enable();
 
-	while (!list_empty(&list)) {
+	for (;;) {
 		struct napi_struct *n;
 
+		if (list_empty(&list)) {
+			if (!sd_has_rps_ipi_waiting(sd) && list_empty(&repoll))
+				return;
+			break;
+		}
+
 		n = list_first_entry(&list, struct napi_struct, poll_list);
 		budget -= napi_poll(n, &repoll);
 
@@ -4641,15 +4647,13 @@ static void net_rx_action(struct softirq_action *h)
 		 * Allow this to run for 2 jiffies since which will allow
 		 * an average latency of 1.5/HZ.
 		 */
-		if (unlikely(budget <= 0 || time_after_eq(jiffies, time_limit)))
-			goto softnet_break;
+		if (unlikely(budget <= 0 ||
+			     time_after_eq(jiffies, time_limit))) {
+			sd->time_squeeze++;
+			break;
+		}
 	}
 
-	if (!sd_has_rps_ipi_waiting(sd) &&
-	    list_empty(&list) &&
-	    list_empty(&repoll))
-		return;
-out:
 	local_irq_disable();
 
 	list_splice_tail_init(&sd->poll_list, &list);
@@ -4659,12 +4663,6 @@ out:
 		__raise_softirq_irqoff(NET_RX_SOFTIRQ);
 
 	net_rps_action_and_irq_enable(sd);
-
-	return;
-
-softnet_break:
-	sd->time_squeeze++;
-	goto out;
 }
 
 struct netdev_adjacent {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 20 20:44:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20: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 1Y2Qsd-00029y-4s; Sat, 20 Dec 2014 20:44:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y2Qsc-00029t-99
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 20:44:02 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	2A/AB-28865-19FD5945; Sat, 20 Dec 2014 20:44:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1419108239!10375881!1
X-Originating-IP: [66.165.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 22928 invoked from network); 20 Dec 2014 20:44:00 -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;
	20 Dec 2014 20:44:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,614,1413244800"; d="scan'208";a="207123338"
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.210.2; Sat, 20 Dec 2014 15:43: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 1Y2QsY-0004wG-4i;
	Sat, 20 Dec 2014 20:43:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2QsX-0007tQ-Vs;
	Sat, 20 Dec 2014 20:43:57 +0000
Date: Sat, 20 Dec 2014 20:43:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32528-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] 32528: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32528 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32528/

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. 32485

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32485
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32485
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail like 32541-bisect
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32485

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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  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-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                52245990c55f25d913eb103350a8acf42713fc4e
baseline version:
 linux                44e8967d591686463e84a88b46b03beba3ab49fb

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 20 20:44:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 20: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 1Y2Qsd-00029y-4s; Sat, 20 Dec 2014 20:44:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y2Qsc-00029t-99
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 20:44:02 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	2A/AB-28865-19FD5945; Sat, 20 Dec 2014 20:44:01 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1419108239!10375881!1
X-Originating-IP: [66.165.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 22928 invoked from network); 20 Dec 2014 20:44:00 -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;
	20 Dec 2014 20:44:00 -0000
X-IronPort-AV: E=Sophos;i="5.07,614,1413244800"; d="scan'208";a="207123338"
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.210.2; Sat, 20 Dec 2014 15:43: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 1Y2QsY-0004wG-4i;
	Sat, 20 Dec 2014 20:43:58 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2QsX-0007tQ-Vs;
	Sat, 20 Dec 2014 20:43:57 +0000
Date: Sat, 20 Dec 2014 20:43:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32528-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] 32528: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32528 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32528/

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. 32485

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32485
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32485
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail like 32541-bisect
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32485

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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  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-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                52245990c55f25d913eb103350a8acf42713fc4e
baseline version:
 linux                44e8967d591686463e84a88b46b03beba3ab49fb

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 20 22:47:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 22:47:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2Sni-0005tc-Fi; Sat, 20 Dec 2014 22:47: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 1Y2Sng-0005tX-Qr
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 22:47:05 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	8D/29-09284-76CF5945; Sat, 20 Dec 2014 22:47:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419115621!14894355!1
X-Originating-IP: [66.165.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 2231 invoked from network); 20 Dec 2014 22:47:02 -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 Dec 2014 22:47:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,615,1413244800"; d="scan'208";a="207139080"
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.210.2; Sat, 20 Dec 2014 17:46: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 1Y2Snb-0005Wi-Do;
	Sat, 20 Dec 2014 22:46:59 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2Snb-0004in-7J;
	Sat, 20 Dec 2014 22:46:59 +0000
Date: Sat, 20 Dec 2014 22:46:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32529-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] 32529: 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 32529 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32529/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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              64b76149765341168b4c073211f7b17a0f54f444
baseline version:
 seabios              ed675ad4193bc7f929e5b39074d50672970aefa3

------------------------------------------------------------
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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=64b76149765341168b4c073211f7b17a0f54f444
+ . 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 64b76149765341168b4c073211f7b17a0f54f444
+ branch=seabios
+ revision=64b76149765341168b4c073211f7b17a0f54f444
+ . 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 64b76149765341168b4c073211f7b17a0f54f444:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   ed675ad..64b7614  64b76149765341168b4c073211f7b17a0f54f444 -> 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 Dec 20 22:47:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Dec 2014 22:47:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2Sni-0005tc-Fi; Sat, 20 Dec 2014 22:47: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 1Y2Sng-0005tX-Qr
	for xen-devel@lists.xensource.com; Sat, 20 Dec 2014 22:47:05 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	8D/29-09284-76CF5945; Sat, 20 Dec 2014 22:47:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419115621!14894355!1
X-Originating-IP: [66.165.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 2231 invoked from network); 20 Dec 2014 22:47:02 -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 Dec 2014 22:47:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,615,1413244800"; d="scan'208";a="207139080"
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.210.2; Sat, 20 Dec 2014 17:46: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 1Y2Snb-0005Wi-Do;
	Sat, 20 Dec 2014 22:46:59 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2Snb-0004in-7J;
	Sat, 20 Dec 2014 22:46:59 +0000
Date: Sat, 20 Dec 2014 22:46:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32529-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] 32529: 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 32529 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32529/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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              64b76149765341168b4c073211f7b17a0f54f444
baseline version:
 seabios              ed675ad4193bc7f929e5b39074d50672970aefa3

------------------------------------------------------------
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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=64b76149765341168b4c073211f7b17a0f54f444
+ . 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 64b76149765341168b4c073211f7b17a0f54f444
+ branch=seabios
+ revision=64b76149765341168b4c073211f7b17a0f54f444
+ . 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 64b76149765341168b4c073211f7b17a0f54f444:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   ed675ad..64b7614  64b76149765341168b4c073211f7b17a0f54f444 -> 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 Dec 21 03:22:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 2014 03:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2X5u-000232-OD; Sun, 21 Dec 2014 03:22:10 +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 1Y2X5t-00022s-7X
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 03:22:09 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	E6/0F-08051-0EC36945; Sun, 21 Dec 2014 03:22:08 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419132126!10976388!1
X-Originating-IP: [66.165.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 31933 invoked from network); 21 Dec 2014 03:22:07 -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 Dec 2014 03:22:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,616,1413244800"; d="scan'208";a="207172219"
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.210.2; Sat, 20 Dec 2014 22:22: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 1Y2X5o-0006r1-Sq;
	Sun, 21 Dec 2014 03:22:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2X5o-00043B-Mt;
	Sun, 21 Dec 2014 03:22:04 +0000
Date: Sun, 21 Dec 2014 03:22:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32535-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] 32535: 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 32535 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32535/

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 32487-bisect

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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
 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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  2676bc915157ab474ee478d929b0928cf696b385

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  M A Young <m.a.young@durham.ac.uk>
  Michael Young <m.a.young@durham.ac.uk>
  Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.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                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ . 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 36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ branch=xen-unstable
+ revision=36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ . 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 36174af3fbeb1b662c0eadbfa193e77f68cc955b:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   2676bc9..36174af  36174af3fbeb1b662c0eadbfa193e77f68cc955b -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 21 03:22:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 2014 03:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2X5u-000232-OD; Sun, 21 Dec 2014 03:22:10 +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 1Y2X5t-00022s-7X
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 03:22:09 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	E6/0F-08051-0EC36945; Sun, 21 Dec 2014 03:22:08 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419132126!10976388!1
X-Originating-IP: [66.165.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 31933 invoked from network); 21 Dec 2014 03:22:07 -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 Dec 2014 03:22:07 -0000
X-IronPort-AV: E=Sophos;i="5.07,616,1413244800"; d="scan'208";a="207172219"
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.210.2; Sat, 20 Dec 2014 22:22: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 1Y2X5o-0006r1-Sq;
	Sun, 21 Dec 2014 03:22:04 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2X5o-00043B-Mt;
	Sun, 21 Dec 2014 03:22:04 +0000
Date: Sun, 21 Dec 2014 03:22:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32535-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] 32535: 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 32535 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32535/

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 32487-bisect

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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
 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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  2676bc915157ab474ee478d929b0928cf696b385

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  M A Young <m.a.young@durham.ac.uk>
  Michael Young <m.a.young@durham.ac.uk>
  Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.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                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ . 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 36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ branch=xen-unstable
+ revision=36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ . 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 36174af3fbeb1b662c0eadbfa193e77f68cc955b:master
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   2676bc9..36174af  36174af3fbeb1b662c0eadbfa193e77f68cc955b -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 21 05:56:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 2014 05:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2ZV2-0007Po-El; Sun, 21 Dec 2014 05:56: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 1Y2ZV0-0007Pj-K5
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 05:56:14 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	CB/23-22777-DF066945; Sun, 21 Dec 2014 05:56:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1419141371!14516694!1
X-Originating-IP: [66.165.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 947 invoked from network); 21 Dec 2014 05:56:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2014 05:56:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,616,1413244800"; d="scan'208";a="207190444"
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.210.2; Sun, 21 Dec 2014 00:56: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 1Y2ZUv-0007as-9u;
	Sun, 21 Dec 2014 05:56:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2ZUv-0000kp-3y;
	Sun, 21 Dec 2014 05:56:09 +0000
Date: Sun, 21 Dec 2014 05:56:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32537-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] 32537: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32537 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32537/

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-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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-winxpsp3 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-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-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                              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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 21 05:56:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 2014 05:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2ZV2-0007Po-El; Sun, 21 Dec 2014 05:56: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 1Y2ZV0-0007Pj-K5
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 05:56:14 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	CB/23-22777-DF066945; Sun, 21 Dec 2014 05:56:13 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1419141371!14516694!1
X-Originating-IP: [66.165.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 947 invoked from network); 21 Dec 2014 05:56:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2014 05:56:12 -0000
X-IronPort-AV: E=Sophos;i="5.07,616,1413244800"; d="scan'208";a="207190444"
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.210.2; Sun, 21 Dec 2014 00:56: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 1Y2ZUv-0007as-9u;
	Sun, 21 Dec 2014 05:56:09 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2ZUv-0000kp-3y;
	Sun, 21 Dec 2014 05:56:09 +0000
Date: Sun, 21 Dec 2014 05:56:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32537-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] 32537: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32537 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32537/

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-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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-winxpsp3 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-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-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                              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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 21 11:03:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 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 1Y2eHW-0000VY-1e; Sun, 21 Dec 2014 11:02: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 1Y2eHU-0000VT-91
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 11:02:36 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	48/64-17735-BC8A6945; Sun, 21 Dec 2014 11:02:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419159752!14950634!1
X-Originating-IP: [66.165.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 5416 invoked from network); 21 Dec 2014 11:02:33 -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;
	21 Dec 2014 11:02:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,617,1413244800"; d="scan'208";a="206720227"
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.210.2; Sun, 21 Dec 2014 06:02: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 1Y2eHO-0000fA-DG;
	Sun, 21 Dec 2014 11:02:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2eHO-0002P6-8N;
	Sun, 21 Dec 2014 11:02:30 +0000
Date: Sun, 21 Dec 2014 11:02:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32542-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] 32542: 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 32542 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32542/

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 32459

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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
 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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                b574f602680d41c4cf4a9c106e3e2244bed01cdd
baseline version:
 qemuu                86b182ac0e0b44726d85598cbefb468ed22517fc

------------------------------------------------------------
People who touched revisions under test:
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=b574f602680d41c4cf4a9c106e3e2244bed01cdd
+ . 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 b574f602680d41c4cf4a9c106e3e2244bed01cdd
+ branch=qemu-mainline
+ revision=b574f602680d41c4cf4a9c106e3e2244bed01cdd
+ . 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 b574f602680d41c4cf4a9c106e3e2244bed01cdd:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   86b182a..b574f60  b574f602680d41c4cf4a9c106e3e2244bed01cdd -> 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 Sun Dec 21 11:03:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 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 1Y2eHW-0000VY-1e; Sun, 21 Dec 2014 11:02: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 1Y2eHU-0000VT-91
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 11:02:36 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	48/64-17735-BC8A6945; Sun, 21 Dec 2014 11:02:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419159752!14950634!1
X-Originating-IP: [66.165.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 5416 invoked from network); 21 Dec 2014 11:02:33 -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;
	21 Dec 2014 11:02:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,617,1413244800"; d="scan'208";a="206720227"
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.210.2; Sun, 21 Dec 2014 06:02: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 1Y2eHO-0000fA-DG;
	Sun, 21 Dec 2014 11:02:30 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2eHO-0002P6-8N;
	Sun, 21 Dec 2014 11:02:30 +0000
Date: Sun, 21 Dec 2014 11:02:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32542-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] 32542: 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 32542 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32542/

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 32459

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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
 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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                b574f602680d41c4cf4a9c106e3e2244bed01cdd
baseline version:
 qemuu                86b182ac0e0b44726d85598cbefb468ed22517fc

------------------------------------------------------------
People who touched revisions under test:
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Gerd Hoffmann <kraxel@redhat.com>
  Gonglei <arei.gonglei@huawei.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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=b574f602680d41c4cf4a9c106e3e2244bed01cdd
+ . 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 b574f602680d41c4cf4a9c106e3e2244bed01cdd
+ branch=qemu-mainline
+ revision=b574f602680d41c4cf4a9c106e3e2244bed01cdd
+ . 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 b574f602680d41c4cf4a9c106e3e2244bed01cdd:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   86b182a..b574f60  b574f602680d41c4cf4a9c106e3e2244bed01cdd -> 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 Sun Dec 21 11:19:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 2014 11: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 1Y2eXP-0000ww-Vt; Sun, 21 Dec 2014 11:19:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1Y2eXO-0000wr-In
	for xen-devel@lists.xen.org; Sun, 21 Dec 2014 11:19:02 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	8C/2F-02953-5ACA6945; Sun, 21 Dec 2014 11:19:01 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-6.tower-27.messagelabs.com!1419160741!16435142!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19685 invoked from network); 21 Dec 2014 11:19:01 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Dec 2014 11:19:01 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginm.net ([86.6.25.227]
	helo=celaeno.hellion.org.uk) by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1Y2eXK-00057B-4f; Sun, 21 Dec 2014 11:18:58 +0000
Received: from dagon.hellion.org.uk ([192.168.1.7])
	by celaeno.hellion.org.uk with smtp (Exim 4.80)
	(envelope-from <ijc@hellion.org.uk>)
	id 1Y2eXF-0001FH-PP; Sun, 21 Dec 2014 11:18:54 +0000
Received: by dagon.hellion.org.uk (sSMTP sendmail emulation);
	Sun, 21 Dec 2014 11:18:53 +0000
From: Ian Campbell <ijc@hellion.org.uk>
To: xen-devel@lists.xen.org
Date: Sun, 21 Dec 2014 11:18:53 +0000
Message-Id: <1419160733-31534-1-git-send-email-ijc@hellion.org.uk>
X-Mailer: git-send-email 2.1.3
Cc: Ian Campbell <ijc@hellion.org.uk>, julien.grall@linaro.org, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] xen: arm: correct off-by-one error in
	consider_modules
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 iterating up to <= mi->nr_mods we are running off the end of the boot
modules, but more importantly it causes us to then skip the first FDT reserved
region, meaning we might clobber it.

Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
---
For 4.5: I think this bug fix should go in, it fixes a real issue and is low
risk.

I'll also add to my list of things to consider for backport to 4.4.
---
 xen/arch/arm/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 3991d64..f49569d 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -286,7 +286,7 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e,
         return 0;
 
     /* First check the boot modules */
-    for ( i = first_mod; i <= mi->nr_mods; i++ )
+    for ( i = first_mod; i < mi->nr_mods; i++ )
     {
         paddr_t mod_s = mi->module[i].start;
         paddr_t mod_e = mod_s + mi->module[i].size;
-- 
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 Sun Dec 21 11:19:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 2014 11: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 1Y2eXP-0000ww-Vt; Sun, 21 Dec 2014 11:19:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1Y2eXO-0000wr-In
	for xen-devel@lists.xen.org; Sun, 21 Dec 2014 11:19:02 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	8C/2F-02953-5ACA6945; Sun, 21 Dec 2014 11:19:01 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-6.tower-27.messagelabs.com!1419160741!16435142!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19685 invoked from network); 21 Dec 2014 11:19:01 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Dec 2014 11:19:01 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginm.net ([86.6.25.227]
	helo=celaeno.hellion.org.uk) by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1Y2eXK-00057B-4f; Sun, 21 Dec 2014 11:18:58 +0000
Received: from dagon.hellion.org.uk ([192.168.1.7])
	by celaeno.hellion.org.uk with smtp (Exim 4.80)
	(envelope-from <ijc@hellion.org.uk>)
	id 1Y2eXF-0001FH-PP; Sun, 21 Dec 2014 11:18:54 +0000
Received: by dagon.hellion.org.uk (sSMTP sendmail emulation);
	Sun, 21 Dec 2014 11:18:53 +0000
From: Ian Campbell <ijc@hellion.org.uk>
To: xen-devel@lists.xen.org
Date: Sun, 21 Dec 2014 11:18:53 +0000
Message-Id: <1419160733-31534-1-git-send-email-ijc@hellion.org.uk>
X-Mailer: git-send-email 2.1.3
Cc: Ian Campbell <ijc@hellion.org.uk>, julien.grall@linaro.org, tim@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] xen: arm: correct off-by-one error in
	consider_modules
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 iterating up to <= mi->nr_mods we are running off the end of the boot
modules, but more importantly it causes us to then skip the first FDT reserved
region, meaning we might clobber it.

Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
---
For 4.5: I think this bug fix should go in, it fixes a real issue and is low
risk.

I'll also add to my list of things to consider for backport to 4.4.
---
 xen/arch/arm/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 3991d64..f49569d 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -286,7 +286,7 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e,
         return 0;
 
     /* First check the boot modules */
-    for ( i = first_mod; i <= mi->nr_mods; i++ )
+    for ( i = first_mod; i < mi->nr_mods; i++ )
     {
         paddr_t mod_s = mi->module[i].start;
         paddr_t mod_e = mod_s + mi->module[i].size;
-- 
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 Sun Dec 21 16:08:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 2014 16: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 1Y2j2n-0001Ew-2e; Sun, 21 Dec 2014 16:07:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y2j2l-0001Ep-Jg
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 16:07:43 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	41/E9-02954-E40F6945; Sun, 21 Dec 2014 16:07:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1419178060!16467492!1
X-Originating-IP: [66.165.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 2214 invoked from network); 21 Dec 2014 16:07: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;
	21 Dec 2014 16:07:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,617,1413244800"; d="scan'208";a="206761110"
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.210.2; Sun, 21 Dec 2014 11:07: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 1Y2j2d-00026w-7Q;
	Sun, 21 Dec 2014 16:07:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2j2d-0006Oo-27;
	Sun, 21 Dec 2014 16:07:35 +0000
Date: Sun, 21 Dec 2014 16:07:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32555-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] 32555: 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 32555 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32555/

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              f5070e3ad0478206d2fc1d52d5efeade5abd9c7b
baseline version:
 libvirt              738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd

------------------------------------------------------------
People who touched revisions under test:
  Claudio Bley <claudio.bley@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?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=f5070e3ad0478206d2fc1d52d5efeade5abd9c7b
+ . 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 f5070e3ad0478206d2fc1d52d5efeade5abd9c7b
+ branch=libvirt
+ revision=f5070e3ad0478206d2fc1d52d5efeade5abd9c7b
+ . 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 f5070e3ad0478206d2fc1d52d5efeade5abd9c7b:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   738a2ae..f5070e3  f5070e3ad0478206d2fc1d52d5efeade5abd9c7b -> 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 Dec 21 16:08:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 2014 16: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 1Y2j2n-0001Ew-2e; Sun, 21 Dec 2014 16:07:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y2j2l-0001Ep-Jg
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 16:07:43 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	41/E9-02954-E40F6945; Sun, 21 Dec 2014 16:07:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1419178060!16467492!1
X-Originating-IP: [66.165.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 2214 invoked from network); 21 Dec 2014 16:07: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;
	21 Dec 2014 16:07:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,617,1413244800"; d="scan'208";a="206761110"
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.210.2; Sun, 21 Dec 2014 11:07: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 1Y2j2d-00026w-7Q;
	Sun, 21 Dec 2014 16:07:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2j2d-0006Oo-27;
	Sun, 21 Dec 2014 16:07:35 +0000
Date: Sun, 21 Dec 2014 16:07:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32555-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] 32555: 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 32555 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32555/

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              f5070e3ad0478206d2fc1d52d5efeade5abd9c7b
baseline version:
 libvirt              738a2aec1e6ba255d7b828e5e2e74eab47c7ddbd

------------------------------------------------------------
People who touched revisions under test:
  Claudio Bley <claudio.bley@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?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=f5070e3ad0478206d2fc1d52d5efeade5abd9c7b
+ . 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 f5070e3ad0478206d2fc1d52d5efeade5abd9c7b
+ branch=libvirt
+ revision=f5070e3ad0478206d2fc1d52d5efeade5abd9c7b
+ . 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 f5070e3ad0478206d2fc1d52d5efeade5abd9c7b:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   738a2ae..f5070e3  f5070e3ad0478206d2fc1d52d5efeade5abd9c7b -> 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 Dec 21 20:11:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 2014 20: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 1Y2mpu-0007TE-Rl; Sun, 21 Dec 2014 20:10: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 1Y2mpt-0007T9-E6
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 20:10:41 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	6E/CD-02953-04927945; Sun, 21 Dec 2014 20:10:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1419192638!16498208!1
X-Originating-IP: [66.165.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 7875 invoked from network); 21 Dec 2014 20:10:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2014 20:10:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,618,1413244800"; d="scan'208";a="207305805"
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.210.2; Sun, 21 Dec 2014 15:10: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 1Y2mpc-0003GV-EX;
	Sun, 21 Dec 2014 20:10:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2mpc-0003CZ-6q;
	Sun, 21 Dec 2014 20:10:24 +0000
Date: Sun, 21 Dec 2014 20:10:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32554-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] 32554: 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 32554 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32554/

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 32535

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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 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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 Sun Dec 21 20:11:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 2014 20: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 1Y2mpu-0007TE-Rl; Sun, 21 Dec 2014 20:10: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 1Y2mpt-0007T9-E6
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 20:10:41 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	6E/CD-02953-04927945; Sun, 21 Dec 2014 20:10:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1419192638!16498208!1
X-Originating-IP: [66.165.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 7875 invoked from network); 21 Dec 2014 20:10:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2014 20:10:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,618,1413244800"; d="scan'208";a="207305805"
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.210.2; Sun, 21 Dec 2014 15:10: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 1Y2mpc-0003GV-EX;
	Sun, 21 Dec 2014 20:10:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2mpc-0003CZ-6q;
	Sun, 21 Dec 2014 20:10:24 +0000
Date: Sun, 21 Dec 2014 20:10:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32554-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] 32554: 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 32554 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32554/

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 32535

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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 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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 Sun Dec 21 21:21:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 2014 21: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 1Y2nw1-0000mV-Es; Sun, 21 Dec 2014 21:21: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 1Y2nw0-0000mQ-AH
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 21:21:04 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	20/47-25547-FB937945; Sun, 21 Dec 2014 21:21:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1419196861!14950544!1
X-Originating-IP: [66.165.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 15015 invoked from network); 21 Dec 2014 21:21:02 -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 Dec 2014 21:21:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,618,1413244800"; d="scan'208";a="207314758"
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.210.2; Sun, 21 Dec 2014 16:20: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 1Y2nvt-0003bL-Ny;
	Sun, 21 Dec 2014 21:20:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2nvt-0008ET-Gz;
	Sun, 21 Dec 2014 21:20:57 +0000
Date: Sun, 21 Dec 2014 21:20:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32557-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] 32557: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32557 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32557/

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-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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     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-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-winxpsp3 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-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-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                    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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 21 21:21:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Dec 2014 21: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 1Y2nw1-0000mV-Es; Sun, 21 Dec 2014 21:21: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 1Y2nw0-0000mQ-AH
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 21:21:04 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	20/47-25547-FB937945; Sun, 21 Dec 2014 21:21:03 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1419196861!14950544!1
X-Originating-IP: [66.165.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 15015 invoked from network); 21 Dec 2014 21:21:02 -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 Dec 2014 21:21:02 -0000
X-IronPort-AV: E=Sophos;i="5.07,618,1413244800"; d="scan'208";a="207314758"
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.210.2; Sun, 21 Dec 2014 16:20: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 1Y2nvt-0003bL-Ny;
	Sun, 21 Dec 2014 21:20:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2nvt-0008ET-Gz;
	Sun, 21 Dec 2014 21:20:57 +0000
Date: Sun, 21 Dec 2014 21:20:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32557-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] 32557: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32557 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32557/

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-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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     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-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-winxpsp3 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-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-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                    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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 22 00:01:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 00:01:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2qQx-0005Jc-Nm; Mon, 22 Dec 2014 00:01:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y2qQv-0005JU-04
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 00:01:09 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	9B/B4-26858-44F57945; Mon, 22 Dec 2014 00:01:08 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1419206465!12543683!1
X-Originating-IP: [66.165.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 21481 invoked from network); 22 Dec 2014 00:01: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;
	22 Dec 2014 00:01:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,619,1413244800"; d="scan'208";a="207334052"
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.210.2; Sun, 21 Dec 2014 19:00: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 1Y2qQT-0004MU-AH;
	Mon, 22 Dec 2014 00:00:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2qQT-0003q4-5J;
	Mon, 22 Dec 2014 00:00:41 +0000
Date: Mon, 22 Dec 2014 00:00:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32561-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 22602
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32561: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1964569280020250360=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1964569280020250360==
Content-Type: text/plain
Content-Length: 22541
Content-Transfer-Encoding: quoted-printable

flight 32561 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32561/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 leak-check/check   fail REGR. vs. 32542

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32542

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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
 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-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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                c4e7c17a8ecb41cdbb81374a128161c614ba1f1e
baseline version:
 qemuu                b574f602680d41c4cf4a9c106e3e2244bed01cdd

------------------------------------------------------------
People who touched revisions under test:
  Eduardo Habkost <ehabkost@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Laurent Desnogues <laurent.desnogues@gmail.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-amd64-xl-pvh-amd                                  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                          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-amd64-xl-pvh-intel                                fail    
 test-amd64-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.

------------------------------------------------------------
commit c4e7c17a8ecb41cdbb81374a128161c614ba1f1e
Merge: adee642 c246cee
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Sat Dec 20 21:28:53 2014 +0000

    Merge remote-tracking branch 'remotes/kraxel/tags/pull-roms-20141217-1' into staging
    
    update ipxe from 69313ed to 35c5379
    
    # gpg: Signature made Wed 17 Dec 2014 14:45:04 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-roms-20141217-1:
      update ipxe from 69313ed to 35c5379
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit adee64249ee37e822d578e65a765750e7f2081f6
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Fri Dec 19 12:53:14 2014 +0100

    exec: change default exception_index value for migration to -1
    
    In QEMU 2.2 the exception_index value was added to the migration stream
    through a subsection.  The default was set to 0, which is wrong and
    should have been -1.
    
    However, 2.2 does not have commit e511b4d (cpu-exec: reset exception_index
    correctly, 2014-11-26), hence in 2.2 the exception_index is never used
    and is set to -1 on the next call to cpu_exec.  So we can change the
    migration stream to make the default -1.  The effects are:
    
    - 2.2.1 -> 2.2.0: cpu->exception_index set incorrectly to 0 if it
    were -1 on the source; then reset to -1 in cpu_exec.  This is TCG
    only; KVM does not use exception_index.
    
    - 2.2.0 -> 2.2.1: cpu->exception_index set incorrectly to -1 if it
    were 0 on the source; but it would be reset to -1 in cpu_exec anyway.
    This is TCG only; KVM does not use exception_index.
    
    - 2.2.1 -> 2.1: two bugs fixed: 1) can migrate backwards if
    cpu->exception_index is set to -1; 2) should not migrate backwards
    (but 2.2.0 allows it) if cpu->exception_index is set to 0
    
    - 2.2.0 -> 2.3.0: 2.2.0 will send the subsection unnecessarily if
    exception_index is -1, but that is not a problem.  2.3.0 will set
    cpu->exception_index to -1 if it is 0 on the source, but this would
    be anyway a problem for 2.2.0 -> 2.2.x migration (due to lack of
    commit e511b4d in 2.2.x) so we can ignore it
    
    - 2.2.1 -> 2.3.0: everything works.
    
    In addition, play it safe and never send the subsection unless TCG
    is in use.  KVM does not use exception_index (PPC KVM stores values
    in it for use in the subsequent call to ppc_cpu_do_interrupt, but
    does not need it as soon as kvm_handle_debug returns).  Xen and
    qtest do not run any code for the CPU at all.
    
    Reported-by: Igor Mammedov <imammedo@redhat.com>
    Tested-by: Laurent Desnogues <laurent.desnogues@gmail.com>
    Tested-by: Eduardo Habkost <ehabkost@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Message-id: 1418989994-17244-3-git-send-email-pbonzini@redhat.com
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit f9d8f6673591f30028e281e8ff6d5790adc2de83
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Fri Dec 19 12:53:13 2014 +0100

    cpu: initialize cpu->exception_index on reset
    
    This unbreaks linux-user (broken by e511b4d, cpu-exec: reset exception_index
    correctly, 2014-11-26).
    
    Reported-by: Eduardo Habkost <ehabkost@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Tested-by: Laurent Desnogues <laurent.desnogues@gmail.com>
    Tested-by: Eduardo Habkost <ehabkost@redhat.com>
    Message-id: 1418989994-17244-2-git-send-email-pbonzini@redhat.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit c246cee4eedb17ae3932d699e009a8b63240235f
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Wed Dec 17 13:56:50 2014 +0100

    update ipxe from 69313ed to 35c5379
    
    Anton D. Kachalov (1):
          [intel] Add 8086:1557 card (Intel 82599 10G ethernet mezz)
    
    Christian Hesse (1):
          [build] Merge util/geniso and util/genliso
    
    Curtis Larsen (3):
          [efi] Use EFI_CONSOLE_CONTROL_PROTOCOL to set text mode if available
          [efi] Report errors from attempting to disconnect existing drivers
          [efi] Try various possible SNP receive filters
    
    Dale Hamel (1):
          [smbios] Expose board serial number as ${board-serial}
    
    Florian Schmaus (1):
          [build] Set GITVERSION only if there is a git repository
    
    Hannes Reinecke (3):
          [ethernet] Provide eth_random_addr() to generate random Ethernet addresses
          [igbvf] Assign random MAC address if none is set
          [igbvf] Allow changing of MAC address
    
    Jan Kiszka (1):
          [intel] Add I217-LM PCI ID
    
    Marin Hannache (4):
          [nfs] Fix an invalid free() when loading a symlink
          [nfs] Fix an invalid free() when loading a regular (non-symlink) file
          [nfs] Rewrite NFS URI handling
          [readline] Add CTRL-W shortcut to remove a word
    
    Michael Brown (144):
          [profile] Allow interrupts to be excluded from profiling results
          [intel] Exclude time spent in hypervisor from profiling
          [build] Fix version.o dependency upon git index
          [tcp] Defer sending ACKs until all received packets have been processed
          [lkrnprefix] Function as a bzImage kernel
          [build] Avoid errors when build directory is mounted via NFS
          [undi] Apply quota only to number of complete received packets
          [lkrnprefix] Make real-mode setup code relocatable
          [intel] Increase receive ring fill level
          [syslog] Strip invalid characters from hostname
          [test] Add self-tests for strdup()
          [libc] Prevent strndup() from reading beyond the end of the string
          [efi] Allow for optional protocols
          [efi] Make EFI_DEVICE_PATH_TO_TEXT_PROTOCOL optional
          [efi] Make EFI_HII_DATABASE_PROTOCOL optional
          [efi] Do not try to fetch loaded image device path protocol
          [ipv6] Fix definition of IN6_IS_ADDR_LINKLOCAL()
          [dhcpv6] Do not set sin6_scope_id on the unspecified client socket address
          [ipv6] Do not set sin6_scope_id on source address
          [ipv6] Include network device when transcribing multicast addresses
          [ipv6] Avoid potentially copying from a NULL pointer in ipv6_tx()
          [librm] Allow for the PIC interrupt vector offset to be changed
          [ifmgmt] Do not sleep CPU while configuring network devices
          [scsi] Improve sense code parsing
          [iscsi] Read IPv4 settings only from the relevant network device
          [iscsi] Include IP address origin in iBFT
          [debug] Allow debug message colours to be customised via DBGCOL=3D...
          [build] Expose build timestamp, build name, and product names
          [efi] Allow device paths to be easily included in debug messages
          [efi] Provide a meaningful EFI SNP device name
          [efi] Restructure EFI driver model
          [build] Fix erroneous object name in version object
          [build] Add yet another potential location for isolinux.bin
          [efi] Allow network devices to be created on top of arbitrary SNP devices
          [autoboot] Allow autoboot device to be identified by link-layer address
          [efi] Identify autoboot device by MAC address when chainloading
          [efi] Attempt to start only drivers claiming support for a device
          [efi] Rewrite SNP NIC driver
          [efi] Include SNP NIC driver within the all-drivers target
          [crypto] Add support for iPAddress subject alternative names
          [crypto] Fix debug message
          [netdevice] Reset network device index when last device is unregistered
          [efi] Update EDK2 headers
          [efi] Install our own disk I/O protocol and claim exclusive use of it
          [efi] Allow for interception of boot services calls by loaded image
          [efi] Print well-known GUIDs by name in debug messages
          [efi] Include EFI_CONSOLE_CONTROL_PROTOCOL header
          [ioapi] Fail ioremap() when attempting to map a zero bus address
          [intel] Check for ioremap() failures
          [realtek] Check for ioremap() failures
          [vmxnet3] Check for ioremap() failures
          [skel] Check for ioremap() failures
          [myson] Check for ioremap() failures
          [natsemi] Check for ioremap() failures
          [i386] Add functions to read and write model-specific registers
          [x86_64] Add functions to read and write model-specific registers
          [efi] Show more diagnostic information when building with DEBUG=3Defi_wrap
          [ioapi] Centralise notion of PAGE_SIZE
          [lotest] Discard packets arriving on the incorrect network device
          [xen] Import selected public headers
          [xen] Add basic support for PV-HVM domains
          [xen] Add support for Xen netfront virtual NICs
          [efi] Default to releasing network devices for use via SNP
          [efi] Unload started images only on failure
          [efi] Fill in loaded image's DeviceHandle if firmware fails to do so
          [efi] Fix incorrect debug message level when device has no device path
          [efi] Report exact failure when unable to open the device path
          [netdevice] Avoid registering duplicate network devices
          [efi] Ignore failures when attempting to install SNP HII protocol
          [efi] Expand the range of well-known EFI GUIDs in debug messages
          [efi] Provide efi_handle_name() for debugging
          [efi] Add ability to dump all openers of a given protocol on a handle
          [efi] Use efi_handle_name() instead of efi_handle_devpath_text()
          [efi] Use efi_handle_name() instead of efi_devpath_text() where applicable
          [efi] Allow compiler to perform type checks on EFI_HANDLE
          [efi] Avoid unnecessarily passing pointers to EFI_HANDLEs
          [efi] Dump existing openers when we are unable to open a protocol
          [efi] Dump handle information around connect/disconnect attempts
          [efi] Improve debugging of the debugging facilities
          [efi] Add excessive sanity checks into efi_debug functions
          [efi] Also try original ComponentName protocol for retrieving driver names
          [efi] Print raw device path when we have no DevicePathToTextProtocol
          [efi] Add ability to dump SNP device mode information
          [efi] Reset multicast filter list when setting SNP receive filters
          [efi] Provide centralised definitions of commonly-used GUIDs
          [efi] Open device path protocol only at point of use
          [efi] Move abstract device path and handle functions to efi_utils.c
          [efi] Generalise snpnet_pci_info() to efi_locate_device()
          [bios] Support displaying and hiding cursor
          [efi] Support displaying and hiding cursor
          [readline] Ensure cursor is visible when prompting for input
          [xen] Accept alternative Xen platform PCI device ID 5853:0002
          [xen] Use version 1 grant tables by default
          [xen] Cope with unexpected initial backend states
          [smc9000] Avoid using CONFIG as a preprocessor macro
          [build] Allow for named configurations at build time
          [intel] Display PBS value when applying ICH errata workaround
          [intel] Display before and after values for both PBS and PBA
          [intel] Apply PBS/PBA errata workaround only to ICH8 PCI device IDs
          [efi] Add definitions of GUIDs observed during Windows boot
          [efi] Dump details of any calls to our dummy block and disk I/O protocols
          [romprefix] Do not preserve unused register %di
          [build] Remove obsolete references to .zrom build targets
          [build] Allow ISA ROMs to be built
          [build] Avoid deleting config header files if build is interrupted
          [prefix] Halt system without burning CPU if we cannot access the payload
          [prefix] Report both %esi and %ecx when opening payload fails
          [util] Use PCI length field to obtain length of individual images
          [mromprefix] Use PCI length field to obtain length of individual images
          [mromprefix] Allow for .mrom images larger than 128kB
          [efi] Show details of intercepted LoadImage() calls
          [efi] Make our virtual file system case insensitive
          [efi] Wrap any images loaded by our wrapped image
          [efi] Use the SNP protocol instance to match the SNP chainloading device
          [efi] Avoid returning uninitialised data from PCI configuration space reads
          [efi] Make EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL optional
          [efi] Allow for non-PCI snpnet devices
          [build] Clean up all binary directories on "make [very]clean"
          [efi] Add efifatbin utility
          [efi] Provide dummy device path in efi_image_probe()
          [dhcp] Check for matching chaddr in received DHCP packets
          [dhcp] Remove obsolete dhcp_chaddr() function
          [build] Use -malign-double to build 32-bit UEFI binaries
          [efi] Centralise definitions of more protocol GUIDs
          [efi] Add definitions of GUIDs observed when chainloading from Intel driver
          [efi] Free transmit ring entry before calling netdev_tx_complete()
          [efi] Generalise snpnet_dev_info() to efi_device_info()
          [efi] Update to current EDK2 headers
          [efi] Add NII / UNDI driver
          [efi] Check for presence of UNDI in NII protocol
          [efi] Include NII driver within "snp" and "snponly" build targets
          [ping] Report timed-out pings via the callback function
          [ping] Allow termination after a specified number of packets
          [ping] Allow "ping" command output to be inhibited
          [intel] Use autoloaded MAC address instead of EEPROM MAC address
          [crypto] Fix parsing of OCSP responder ID key hash
          [vmxnet3] Add profiling code to exclude time spent in the hypervisor
          [netdevice] Fix erroneous use of free(iobuf) instead of free_iob(iobuf)
          [libc] Add ASSERTED macro to test if any assertion has triggered
          [list] Add sanity checks after list-adding functions
          [malloc] Tidy up debug output
          [malloc] Sanity check parameters to alloc_memblock() and free_memblock()
          [malloc] Check integrity of free list
          [malloc] Report caller address as soon as memory corruption is detected
    
    Peter Lemenkov (1):
          [build] Check if git index actually exists
    
    Robin Smidsr=C3=B8d (2):
          [build] Add named configuration for VirtualBox
          [build] Avoid using embedded script in VirtualBox named configuration
    
    Sven Ulland (1):
          [lacp] Set "aggregatable" flag in response LACPDU
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>


--===============1964569280020250360==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1964569280020250360==--

From xen-devel-bounces@lists.xen.org Mon Dec 22 00:01:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 00:01:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2qQx-0005Jc-Nm; Mon, 22 Dec 2014 00:01:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y2qQv-0005JU-04
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 00:01:09 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	9B/B4-26858-44F57945; Mon, 22 Dec 2014 00:01:08 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1419206465!12543683!1
X-Originating-IP: [66.165.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 21481 invoked from network); 22 Dec 2014 00:01: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;
	22 Dec 2014 00:01:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,619,1413244800"; d="scan'208";a="207334052"
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.210.2; Sun, 21 Dec 2014 19:00: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 1Y2qQT-0004MU-AH;
	Mon, 22 Dec 2014 00:00:41 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2qQT-0003q4-5J;
	Mon, 22 Dec 2014 00:00:41 +0000
Date: Mon, 22 Dec 2014 00:00:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32561-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 22602
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-mainline test] 32561: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1964569280020250360=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1964569280020250360==
Content-Type: text/plain
Content-Length: 22541
Content-Transfer-Encoding: quoted-printable

flight 32561 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32561/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 leak-check/check   fail REGR. vs. 32542

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32542

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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
 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-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-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                c4e7c17a8ecb41cdbb81374a128161c614ba1f1e
baseline version:
 qemuu                b574f602680d41c4cf4a9c106e3e2244bed01cdd

------------------------------------------------------------
People who touched revisions under test:
  Eduardo Habkost <ehabkost@redhat.com>
  Gerd Hoffmann <kraxel@redhat.com>
  Laurent Desnogues <laurent.desnogues@gmail.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-amd64-xl-pvh-amd                                  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                          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-amd64-xl-pvh-intel                                fail    
 test-amd64-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.

------------------------------------------------------------
commit c4e7c17a8ecb41cdbb81374a128161c614ba1f1e
Merge: adee642 c246cee
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Sat Dec 20 21:28:53 2014 +0000

    Merge remote-tracking branch 'remotes/kraxel/tags/pull-roms-20141217-1' into staging
    
    update ipxe from 69313ed to 35c5379
    
    # gpg: Signature made Wed 17 Dec 2014 14:45:04 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-roms-20141217-1:
      update ipxe from 69313ed to 35c5379
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit adee64249ee37e822d578e65a765750e7f2081f6
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Fri Dec 19 12:53:14 2014 +0100

    exec: change default exception_index value for migration to -1
    
    In QEMU 2.2 the exception_index value was added to the migration stream
    through a subsection.  The default was set to 0, which is wrong and
    should have been -1.
    
    However, 2.2 does not have commit e511b4d (cpu-exec: reset exception_index
    correctly, 2014-11-26), hence in 2.2 the exception_index is never used
    and is set to -1 on the next call to cpu_exec.  So we can change the
    migration stream to make the default -1.  The effects are:
    
    - 2.2.1 -> 2.2.0: cpu->exception_index set incorrectly to 0 if it
    were -1 on the source; then reset to -1 in cpu_exec.  This is TCG
    only; KVM does not use exception_index.
    
    - 2.2.0 -> 2.2.1: cpu->exception_index set incorrectly to -1 if it
    were 0 on the source; but it would be reset to -1 in cpu_exec anyway.
    This is TCG only; KVM does not use exception_index.
    
    - 2.2.1 -> 2.1: two bugs fixed: 1) can migrate backwards if
    cpu->exception_index is set to -1; 2) should not migrate backwards
    (but 2.2.0 allows it) if cpu->exception_index is set to 0
    
    - 2.2.0 -> 2.3.0: 2.2.0 will send the subsection unnecessarily if
    exception_index is -1, but that is not a problem.  2.3.0 will set
    cpu->exception_index to -1 if it is 0 on the source, but this would
    be anyway a problem for 2.2.0 -> 2.2.x migration (due to lack of
    commit e511b4d in 2.2.x) so we can ignore it
    
    - 2.2.1 -> 2.3.0: everything works.
    
    In addition, play it safe and never send the subsection unless TCG
    is in use.  KVM does not use exception_index (PPC KVM stores values
    in it for use in the subsequent call to ppc_cpu_do_interrupt, but
    does not need it as soon as kvm_handle_debug returns).  Xen and
    qtest do not run any code for the CPU at all.
    
    Reported-by: Igor Mammedov <imammedo@redhat.com>
    Tested-by: Laurent Desnogues <laurent.desnogues@gmail.com>
    Tested-by: Eduardo Habkost <ehabkost@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Message-id: 1418989994-17244-3-git-send-email-pbonzini@redhat.com
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit f9d8f6673591f30028e281e8ff6d5790adc2de83
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Fri Dec 19 12:53:13 2014 +0100

    cpu: initialize cpu->exception_index on reset
    
    This unbreaks linux-user (broken by e511b4d, cpu-exec: reset exception_index
    correctly, 2014-11-26).
    
    Reported-by: Eduardo Habkost <ehabkost@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Tested-by: Laurent Desnogues <laurent.desnogues@gmail.com>
    Tested-by: Eduardo Habkost <ehabkost@redhat.com>
    Message-id: 1418989994-17244-2-git-send-email-pbonzini@redhat.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

commit c246cee4eedb17ae3932d699e009a8b63240235f
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Wed Dec 17 13:56:50 2014 +0100

    update ipxe from 69313ed to 35c5379
    
    Anton D. Kachalov (1):
          [intel] Add 8086:1557 card (Intel 82599 10G ethernet mezz)
    
    Christian Hesse (1):
          [build] Merge util/geniso and util/genliso
    
    Curtis Larsen (3):
          [efi] Use EFI_CONSOLE_CONTROL_PROTOCOL to set text mode if available
          [efi] Report errors from attempting to disconnect existing drivers
          [efi] Try various possible SNP receive filters
    
    Dale Hamel (1):
          [smbios] Expose board serial number as ${board-serial}
    
    Florian Schmaus (1):
          [build] Set GITVERSION only if there is a git repository
    
    Hannes Reinecke (3):
          [ethernet] Provide eth_random_addr() to generate random Ethernet addresses
          [igbvf] Assign random MAC address if none is set
          [igbvf] Allow changing of MAC address
    
    Jan Kiszka (1):
          [intel] Add I217-LM PCI ID
    
    Marin Hannache (4):
          [nfs] Fix an invalid free() when loading a symlink
          [nfs] Fix an invalid free() when loading a regular (non-symlink) file
          [nfs] Rewrite NFS URI handling
          [readline] Add CTRL-W shortcut to remove a word
    
    Michael Brown (144):
          [profile] Allow interrupts to be excluded from profiling results
          [intel] Exclude time spent in hypervisor from profiling
          [build] Fix version.o dependency upon git index
          [tcp] Defer sending ACKs until all received packets have been processed
          [lkrnprefix] Function as a bzImage kernel
          [build] Avoid errors when build directory is mounted via NFS
          [undi] Apply quota only to number of complete received packets
          [lkrnprefix] Make real-mode setup code relocatable
          [intel] Increase receive ring fill level
          [syslog] Strip invalid characters from hostname
          [test] Add self-tests for strdup()
          [libc] Prevent strndup() from reading beyond the end of the string
          [efi] Allow for optional protocols
          [efi] Make EFI_DEVICE_PATH_TO_TEXT_PROTOCOL optional
          [efi] Make EFI_HII_DATABASE_PROTOCOL optional
          [efi] Do not try to fetch loaded image device path protocol
          [ipv6] Fix definition of IN6_IS_ADDR_LINKLOCAL()
          [dhcpv6] Do not set sin6_scope_id on the unspecified client socket address
          [ipv6] Do not set sin6_scope_id on source address
          [ipv6] Include network device when transcribing multicast addresses
          [ipv6] Avoid potentially copying from a NULL pointer in ipv6_tx()
          [librm] Allow for the PIC interrupt vector offset to be changed
          [ifmgmt] Do not sleep CPU while configuring network devices
          [scsi] Improve sense code parsing
          [iscsi] Read IPv4 settings only from the relevant network device
          [iscsi] Include IP address origin in iBFT
          [debug] Allow debug message colours to be customised via DBGCOL=3D...
          [build] Expose build timestamp, build name, and product names
          [efi] Allow device paths to be easily included in debug messages
          [efi] Provide a meaningful EFI SNP device name
          [efi] Restructure EFI driver model
          [build] Fix erroneous object name in version object
          [build] Add yet another potential location for isolinux.bin
          [efi] Allow network devices to be created on top of arbitrary SNP devices
          [autoboot] Allow autoboot device to be identified by link-layer address
          [efi] Identify autoboot device by MAC address when chainloading
          [efi] Attempt to start only drivers claiming support for a device
          [efi] Rewrite SNP NIC driver
          [efi] Include SNP NIC driver within the all-drivers target
          [crypto] Add support for iPAddress subject alternative names
          [crypto] Fix debug message
          [netdevice] Reset network device index when last device is unregistered
          [efi] Update EDK2 headers
          [efi] Install our own disk I/O protocol and claim exclusive use of it
          [efi] Allow for interception of boot services calls by loaded image
          [efi] Print well-known GUIDs by name in debug messages
          [efi] Include EFI_CONSOLE_CONTROL_PROTOCOL header
          [ioapi] Fail ioremap() when attempting to map a zero bus address
          [intel] Check for ioremap() failures
          [realtek] Check for ioremap() failures
          [vmxnet3] Check for ioremap() failures
          [skel] Check for ioremap() failures
          [myson] Check for ioremap() failures
          [natsemi] Check for ioremap() failures
          [i386] Add functions to read and write model-specific registers
          [x86_64] Add functions to read and write model-specific registers
          [efi] Show more diagnostic information when building with DEBUG=3Defi_wrap
          [ioapi] Centralise notion of PAGE_SIZE
          [lotest] Discard packets arriving on the incorrect network device
          [xen] Import selected public headers
          [xen] Add basic support for PV-HVM domains
          [xen] Add support for Xen netfront virtual NICs
          [efi] Default to releasing network devices for use via SNP
          [efi] Unload started images only on failure
          [efi] Fill in loaded image's DeviceHandle if firmware fails to do so
          [efi] Fix incorrect debug message level when device has no device path
          [efi] Report exact failure when unable to open the device path
          [netdevice] Avoid registering duplicate network devices
          [efi] Ignore failures when attempting to install SNP HII protocol
          [efi] Expand the range of well-known EFI GUIDs in debug messages
          [efi] Provide efi_handle_name() for debugging
          [efi] Add ability to dump all openers of a given protocol on a handle
          [efi] Use efi_handle_name() instead of efi_handle_devpath_text()
          [efi] Use efi_handle_name() instead of efi_devpath_text() where applicable
          [efi] Allow compiler to perform type checks on EFI_HANDLE
          [efi] Avoid unnecessarily passing pointers to EFI_HANDLEs
          [efi] Dump existing openers when we are unable to open a protocol
          [efi] Dump handle information around connect/disconnect attempts
          [efi] Improve debugging of the debugging facilities
          [efi] Add excessive sanity checks into efi_debug functions
          [efi] Also try original ComponentName protocol for retrieving driver names
          [efi] Print raw device path when we have no DevicePathToTextProtocol
          [efi] Add ability to dump SNP device mode information
          [efi] Reset multicast filter list when setting SNP receive filters
          [efi] Provide centralised definitions of commonly-used GUIDs
          [efi] Open device path protocol only at point of use
          [efi] Move abstract device path and handle functions to efi_utils.c
          [efi] Generalise snpnet_pci_info() to efi_locate_device()
          [bios] Support displaying and hiding cursor
          [efi] Support displaying and hiding cursor
          [readline] Ensure cursor is visible when prompting for input
          [xen] Accept alternative Xen platform PCI device ID 5853:0002
          [xen] Use version 1 grant tables by default
          [xen] Cope with unexpected initial backend states
          [smc9000] Avoid using CONFIG as a preprocessor macro
          [build] Allow for named configurations at build time
          [intel] Display PBS value when applying ICH errata workaround
          [intel] Display before and after values for both PBS and PBA
          [intel] Apply PBS/PBA errata workaround only to ICH8 PCI device IDs
          [efi] Add definitions of GUIDs observed during Windows boot
          [efi] Dump details of any calls to our dummy block and disk I/O protocols
          [romprefix] Do not preserve unused register %di
          [build] Remove obsolete references to .zrom build targets
          [build] Allow ISA ROMs to be built
          [build] Avoid deleting config header files if build is interrupted
          [prefix] Halt system without burning CPU if we cannot access the payload
          [prefix] Report both %esi and %ecx when opening payload fails
          [util] Use PCI length field to obtain length of individual images
          [mromprefix] Use PCI length field to obtain length of individual images
          [mromprefix] Allow for .mrom images larger than 128kB
          [efi] Show details of intercepted LoadImage() calls
          [efi] Make our virtual file system case insensitive
          [efi] Wrap any images loaded by our wrapped image
          [efi] Use the SNP protocol instance to match the SNP chainloading device
          [efi] Avoid returning uninitialised data from PCI configuration space reads
          [efi] Make EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL optional
          [efi] Allow for non-PCI snpnet devices
          [build] Clean up all binary directories on "make [very]clean"
          [efi] Add efifatbin utility
          [efi] Provide dummy device path in efi_image_probe()
          [dhcp] Check for matching chaddr in received DHCP packets
          [dhcp] Remove obsolete dhcp_chaddr() function
          [build] Use -malign-double to build 32-bit UEFI binaries
          [efi] Centralise definitions of more protocol GUIDs
          [efi] Add definitions of GUIDs observed when chainloading from Intel driver
          [efi] Free transmit ring entry before calling netdev_tx_complete()
          [efi] Generalise snpnet_dev_info() to efi_device_info()
          [efi] Update to current EDK2 headers
          [efi] Add NII / UNDI driver
          [efi] Check for presence of UNDI in NII protocol
          [efi] Include NII driver within "snp" and "snponly" build targets
          [ping] Report timed-out pings via the callback function
          [ping] Allow termination after a specified number of packets
          [ping] Allow "ping" command output to be inhibited
          [intel] Use autoloaded MAC address instead of EEPROM MAC address
          [crypto] Fix parsing of OCSP responder ID key hash
          [vmxnet3] Add profiling code to exclude time spent in the hypervisor
          [netdevice] Fix erroneous use of free(iobuf) instead of free_iob(iobuf)
          [libc] Add ASSERTED macro to test if any assertion has triggered
          [list] Add sanity checks after list-adding functions
          [malloc] Tidy up debug output
          [malloc] Sanity check parameters to alloc_memblock() and free_memblock()
          [malloc] Check integrity of free list
          [malloc] Report caller address as soon as memory corruption is detected
    
    Peter Lemenkov (1):
          [build] Check if git index actually exists
    
    Robin Smidsr=C3=B8d (2):
          [build] Add named configuration for VirtualBox
          [build] Avoid using embedded script in VirtualBox named configuration
    
    Sven Ulland (1):
          [lacp] Set "aggregatable" flag in response LACPDU
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>


--===============1964569280020250360==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1964569280020250360==--

From xen-devel-bounces@lists.xen.org Mon Dec 22 02:12:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 02:12:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2sTR-0004eN-US; Mon, 22 Dec 2014 02:11:53 +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 1Y2sTQ-0004ZL-AY
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 02:11:52 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	8F/36-11608-7ED77945; Mon, 22 Dec 2014 02:11:51 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419214308!15025875!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31395 invoked from network); 22 Dec 2014 02:11:48 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-5.tower-31.messagelabs.com with SMTP;
	22 Dec 2014 02:11:48 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by fmsmga103.fm.intel.com with ESMTP; 21 Dec 2014 18:08:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,620,1413270000"; d="scan'208";a="627486052"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.73])
	([10.238.130.73])
	by orsmga001.jf.intel.com with ESMTP; 21 Dec 2014 18:11:44 -0800
Message-ID: <54977DDF.4080404@intel.com>
Date: Mon, 22 Dec 2014 10:11: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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1418952066-21064-1-git-send-email-tiejun.chen@intel.com>
	<54944EBA02000078000510BF@mail.emea.novell.com>
In-Reply-To: <54944EBA02000078000510BF@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] RMRR Fix Design 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan,

Thanks for your time but I'm not going to address your comments here. 
Because I heard this design is totally not satisfied your expectation. 
But this really was reviewed with several revisions by Kevin and Yang 
before sending in public...

Anyway, I guess the only thing what I can do is that, Kevin and Yang, or 
other appropriate guys should finish this design as you expect. So now 
I'd better not say anything to avoid bringing any inconvenience.

Tiejun

On 2014/12/19 23:13, Jan Beulich wrote:
>>>> On 19.12.14 at 02:21, <tiejun.chen@intel.com> wrote:
>> #4 Something like USB, is still restricted to current RMRR implementation. We
>>     should work out this case.
>
> This can mean all or nothing. My understanding is that right now code
> assumes that USB devices won't use their RMRR-specified memory
> regions post-boot (kind of contrary to your earlier statement that in
> such a case the regions shouldn't be listed in RMRRs in the first place).
>
>> Design Overview
>> ===============
>>
>> First of all we need to make sure all resources don't overlap RMRR. And then
>> in case of shared ept, we can set these identity entries. And Certainly we
>> will
>> group all devices associated to one same RMRR entry, then make sure all
>> group
>> devices should be assigned to same VM.
>>
>> 1. Setup RMRR identity mapping
>>
>> current status:
>>      * identity mapping only setup in non-shared ept case
>>
>> proposal:
>>
>> In non-shared ept case, IOMMU stuff always set those entries and RMRR is
>> already marked reserved in host so its fine enough.
>
> Is it? Where? Or am I misunderstanding the whole statement, likely
> due to me silently replacing "host" by "guest" (since reservation in
> host address spaces is of no interest here afaict)?
>
>> But in shared ept case, we need to
>> check any conflit, so we should follow up
>>
>>    - gfn space unoccupied
>>          -> insert mapping: success.
>>              gfn:_mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct, p2m_access_rw
>>    - gfn space already occupied by 1:1 RMRR mapping
>>          -> do nothing; success.
>>    - gfn space already occupied by other mapping
>>          -> fail.
>>
>> expectation:
>>      * only devices w/ non-conflicting RMRR can be assigned
>>      * fortunately this achieves the very initial intention to support IGD
>>        pass-through on BDW
>
> Are you trying to say here that doing the above is all you need for
> your specific machine? If so, that's clearly not something to go into
> a design document.
>
> Also there's clearly an alternative proposal: Drop support for sharing
> page tables. Your colleagues will surely have told you that we've
> been considering this for quite some time, and had actually hoped
> for them to do the necessary VT-d side work to allow for this without
> causing performance regressions.
>
>> 2.1 Expose RMRR to user space
>>
>> current status:
>>      * Xen always record RMRR info into one list, acpi_rmrr_units, while
>> parsing
>>        acpi. So we can retrieve these info by lookup that list.
>>
>> proposal:
>>      * RMRR would be exposed by a new hypercall, which Jan already finished
>> in
>>        current version but just expose all RMRR info unconditionally.
>>      * Furthermore we can expose RMRR on demand to diminish shrinking guest
>>        RAM/MMIO space.
>>      * So we will introduce a new parameter, 'rdm_forcecheck' and to
>> collaborate
>>        with SBDFs to control which RMRR should be exposed:
>>
>>          - We can set this parameter in .cfg file like,
>>
>>              rdm_forcecheck = 1 => Of course this should be 0 by default.
>>
>>          '1' means we should force check to reserve all ranges
>> unconditionally.
>>          and 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.
>>
>>          If 0, we just check those assigned pci devices. As you know we already
>
> assigned? Wasn't the plan to have a separate potentially-to-be-
> assigned list? And I can only re-iterate that the name
> "rdm_forcecheck" doesn't really express what you mean. Since
> your intention is to check all devices (rather than do a check that
> otherwise wouldn't be done), "rdm_all" or "rdm_check_all" would
> seem closer to the intended behavior.
>
>>          have such an existing hypercall to assign PCI devices, looks we can
>> work
>>          directly under this hypercall to get that necessary SBDF to sort
>> which
>>          RMRR should be handled. But obviously, we need to get these info
>> before
>>          we populate guest memory to make sure these RMRR ranges should be
>>          excluded from guest memory. But unfortunately the memory populating
>>          takes place before a device assignment, so we can't live on that
>>          directly.
>>
>>          But as we discussed it just benefit that assigned case to reorder
>> that
>>          order, but not good to hotplug case. So we have to introduce a new
>>          DOMCTL to pass that global parameter with SBDF at the same time.
>>
>>          For example, if we own these two RMRR entries,
>
> "own" is confusing here, I assume you mean if there are such entries.
>
>>          [00:14.0]    RMRR region: base_addr ab80a000 end_address ab81dfff
>>          [00:02.0]    RMRR region: base_addr ad000000 end_address af7fffff
>>
>>          If 'rdm_forcecheck = 1', any caller to that hypercall may get these two
>
> s/may/will/ I suppose.
>
>>          entries. But if 'rdm_forcecheck = 0', and in .cfg file,
>>
>>          #1 'pci=[00:14.0, 00:02.0]' -> The caller still get these two entries.
>>          #2 'pci=[00:02.0]' -> The caller just get one entry,
>> 0xad000000:0xaf7fffff
>>          #2 'pci=[00:14.0]' -> The caller just get one entry,
>> 0xab80a000:0xab81dfff
>>          #4 'pci=[others]' or no any pci configuration -> The caller get
>> nothing.
>
> Oh, interesting, you dropped the idea of a separate list of possibly-
> to-be-assigned devices. Why that?
>
>>          And ultimately, if we expose any RMRR entry at gfn,
>>
>>          in non-shared ept case,
>>
>>          p2m table:  valid non-identity mapping, gfn:mfn != 1:1
>
> This would mean ...
>
>>          VT-D table: no such a mapping until set identity mapping,
>>                      gfn:_mfn(gfn) == 1:1 when we have a associated device
>>                      assignment.
>
> ... the two mappings to go out of sync when such a 1:1 mapping gets
> established. I think we should avoid such a situation if at all possible.
>
>>          in shared ept case,
>>
>>          p2m table\VT-D table:  always INVALID until set identity mapping,
>>                                 gfn:_mfn(gfn) == 1:1 when we have a
>> associated
>>                                 device assignment.
>>
>>          But if we don't expose any RMRR entry,
>>
>>          in non-shared ept case,
>>
>>          p2m table:  valid non-identity mapping, gfn:mfn != 1:1
>>          VT-D table: no such a mapping until set identity mapping,
>>                      gfn:_mfn(gfn) == 1:1 when we have a associated device
>>                      assignment.
>>
>>          in shared ept case,
>>
>>          p2m table\VT-D table:  If guest RAM already cover gfn, we have sunc a
>>                                 valid non-identity mapping, gfn:mfn != 1:1,
>> but
>>                                 we can't set any identity mapping again then
>>                                 that associated device can't be assigned
>>                                 successfully. If not, we'll set identity
>> mapping,
>>                                 gfn:_mfn(gfn) == 1:1, to work well.
>
> So in the end we'd still have various cases of different behavior,
> when really it would be much better (if not a requirement) if guest
> observable behavior wouldn't depend on implementation details
> like (non-)shared page tables.
>
>> 2.2 Detect and avoid RMRR conflictions with guest RAM/MMIO
>>
>> current status:
>>      * Currently Xen doesn't detect anything to avoid any conflict.
>>
>> proposal:
>>      * We need to cover all points to check any conflict. Below lists places
>>        where reserved region conflictions should be detected:
>>
>>          1>. libxc:setup_guest():modules_init()
>>
>>          There are some modules, like acpi_module and smbios_module. They may
>>          occupy some ranges so we need to check if they're conflicting with
>>          all ranges from that new hypercall above.
>
> I'm missing of what conflict resolution you expect to do here.
> Following earlier discussion in the context of patch review made
> pretty clear that this isn't really straightforward, having the
> potential to prevent a guest from booting (e.g. when the virtual
> BIOS conflicts with an RMRR).
>
>>          2>. libxc:setup_guest():xc_domain_populate_physmap()
>>
>>          There are two ways to exclude RMRR ranges here:
>>
>>              #1 Before we populate guest RAM without any RMRR range from that
>>                 new hypercall to skip RMRR ranges when populating guest RAM.
>>              #2 In Xen we can fliter RMRR range while calling
>>                 XENMEM_populate_physmap, its no change to libxc, but skip
>>                 setting p2m entry for RMRR ranges in Xen hypervisor
>>
>>          But to compare #1, #2 is not better since Xen still allocate those
>>          range, and we have to sync somewhere else in Xen. And #1 is cleaner
>>          because #2 actually shrinks the available memory size to the guest.
>>
>>          3>. hvmloader:pci_setup()
>>
>>          Here we should populate guest MMIO excluding all ranges from that
>> new
>>          hypercall to detect RMRR conflictions for allocating PCI MMIO BAR.
>>
>>          4>. hvmloader:mem_hole_alloc()
>>
>>          Here we should populate mem holw excluding all ranges from that new
>>          hypercall to detect RMRR conflictions for dynamic allocation in
>>          hvmloader, e.g. as used for IGD opregion
>>
>>          5>. hvmloader:build_e820_table():
>>
>>          Finally we need let VM know that RMRR regions are reserved through
>> e820
>>          table
>>
>>      Its a little bit tricky to handle this inside hvmloader since as you
>> know,
>>      struct hvm_info_table is only a approach between libxc and hvmloader.
>> But
>>      however, making up all above places will bring some duplicated logic.
>>      Especially between libxc and hvmloader, which skip same regions in guest
>>      physical layer(one in populating guest RAM, the other in constructing
>> e820)
>>      But current design has some limitation to pass information between libxc
>> and
>>      hvmloader,
>>
>> struct hvm_info_table {
>>      ...
>>      /*
>>       *  0x0 to page_to_phys(low_mem_pgend)-1:
>>       *    RAM below 4GB (except for VGA hole 0xA0000-0xBFFFF)
>>       */
>>      uint32_t    low_mem_pgend;
>>      ...
>>      /*
>>       *  0x100000000 to page_to_phys(high_mem_pgend)-1:
>>       *    RAM above 4GB
>>       */
>>      uint32_t    high_mem_pgend;
>>      ...
>> }
>>
>>      nothing valuable is passed to hvmloader so we have to figure out a way
>> to
>>      handle those points in hvmloader. Currently,
>>
>>              #1 Reconstruct hvm_info_table{}
>>
>>              We can store all necessary RMRR info into hvm_info_table as
>> well,
>>              then we can pick them conveniently but oftentimes these RMRR
>>              entries are scattered and the number is also undertimined, so
>> its
>>              a little bit ugly to do.
>>
>>              #2 Xenstore
>>
>>              We may store all necessary RMRR info as Xenstore then pick them
>> in
>>              hvmloader.
>>
>>              #3 A hypercall
>>
>>              We may have to call our new hypercall again to pick them, but
>>              obviously this may introduce some duplicated codes.
>>
>>              #4 XENMEM_{set_,}memory_map pair of hypercalls
>>
>>              As Jan commented it "could be used(and is readily available to
>> be
>>              extended that way, since for HVM domains XENMEM_set_memory_map
>>              returns -EPERM at present). The only potentially problematic
>> aspect
>>              I can see with using it might be its limiting of the entry count
>> to
>>              E820MAX." So a preparation patch is required before RMRR, and
>>              hvmloader still needs to query RMRR information.
>
> Somewhere above I'm missing the mentioning of the option to reorder
> operations of hvmloader, to e.g. base PCI BAR assignment on the
> previously set up E820 table, rather than assuming a (mostly) fixed
> size window where to put these.
>
>> 3. Group multiple devices sharing same RMRR entry
>>
>> current status:
>>      * Xen doesn't distinguish if multiple devices share same RMRR entry.
>> This
>>        may lead a leak to corruption, e.g. Device A and device B share same
>> entry
>>        and then device A is assigned to domain A, device B is assigned to
>> domain
>>        B. So domain A can read something from that range, even rewrite
>>        maliciously that range to corrupt device B inside domain B.
>>
>> proposal:
>>      * We will group all devices by means of one same RMRR entry.
>> Theoretically,
>>        we should make sure all devices in one group are allowed to assign to
>> one
>>        VM. But in Xen side the hardware domain owns all devices at first, we
>>        should unbound all group devies before assign one of group device. But
>> its
>>        hard to do such thing in current VT-d stuff. And actually its rare to
>> have
>>        the group device in real world so we just prevent assigning any group
>>        device simply.
>>      * We will introduce two field, gid, in struct, acpi_rmrr_unit:
>>          gid: indicate if this device belongs a group.
>>        Then when we add or attach device in iommu side, we will check this
>> field
>>        if we're assigning a group device then determine if we assign that.
>>
>>
>> expectation:
>>      * Make all device associated to one RMRR to be assigned same VM.
>
> A few lines up you say you're intending to refuse such assignments
> rather than making them happen in a consistent way - what's the
> plan in the end?
>
>> 4. Handle in case of force accessing to RMRR regions
>>
>> proposal:
>>      * Although we already reserve these ranges in guest e820 table, its
>>        possible to access these ranges.
>>        In non-shared ept case it will issue such EPT violation since we have
>> no
>>        p2m table actually. But its same to access other reserved range so
>> just
>>        live on Xen's default behavior. In shared-ept case guest can read or
>>        write anything from this range, but such a leak or corruption just
>>        happens inside same domain so this behavior is also same as a native
>>        case, it should be fine.
>>
>> expectation:
>>      * Don't broken normal RMRR usage.
>
> I'm not getting the purpose of this whole section.
>
>> 5. Re-enable USB
>>
>> current status:
>>      * Currently Xen doesn't allow USB passthrough.
>
> ???
>
>> 6. Hotplug case
>>
>> current status:
>>      * only work well in non-shared ept case or in case of shared ept & all
>>        associated gfns are free.
>>
>> proposal:
>>      * If user ensure there'll be a hotplug device in advace,
>> 'rdm_forcecheck'
>>        can be set to reserve all RMRR range as we describe above. Then any
>>        device can be hotplugged successfully.
>>      * If not, there are still two scenarios here:
>>        in non-shared ept case it still work well as original;
>
> So you continue to assume that the two tables going out of sync is
> acceptable.
>
>>        in shared ept case, its just going a case of "1. Setup RMRR identity
>>        mapping"
>>          - gfn space unoccupied -> insert mapping: success.
>>          - gfn space already occupied by 1:1 RMRR mapping -> do nothing;
>> success.
>>          - gfn space already occupied by other mapping -> fail.
>>
>> expectation:
>>      * provide a way to let hotplug work in case of shared ept totally
>>
>> Open Issue
>> ==========
>>
>> When other stuffs like ballon mechanism, to populate memory accessing RMRR
>> range, or others like qemu, force map RMRR range, we may need to avoid such
>> a
>> possibility but we're not 100% sure this so just open this to double check.
>
> I think a HVM guest can be expected to play by what E820 table
> says is reserved. That includes not using such ranges for ballooning.
> If it still does, it'll get what it deserves.
>
> Jan
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 02:12:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 02:12:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2sTR-0004eN-US; Mon, 22 Dec 2014 02:11:53 +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 1Y2sTQ-0004ZL-AY
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 02:11:52 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	8F/36-11608-7ED77945; Mon, 22 Dec 2014 02:11:51 +0000
X-Env-Sender: tiejun.chen@intel.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419214308!15025875!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31395 invoked from network); 22 Dec 2014 02:11:48 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-5.tower-31.messagelabs.com with SMTP;
	22 Dec 2014 02:11:48 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by fmsmga103.fm.intel.com with ESMTP; 21 Dec 2014 18:08:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,620,1413270000"; d="scan'208";a="627486052"
Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.73])
	([10.238.130.73])
	by orsmga001.jf.intel.com with ESMTP; 21 Dec 2014 18:11:44 -0800
Message-ID: <54977DDF.4080404@intel.com>
Date: Mon, 22 Dec 2014 10:11: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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1418952066-21064-1-git-send-email-tiejun.chen@intel.com>
	<54944EBA02000078000510BF@mail.emea.novell.com>
In-Reply-To: <54944EBA02000078000510BF@mail.emea.novell.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com
Subject: Re: [Xen-devel] RMRR Fix Design 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan,

Thanks for your time but I'm not going to address your comments here. 
Because I heard this design is totally not satisfied your expectation. 
But this really was reviewed with several revisions by Kevin and Yang 
before sending in public...

Anyway, I guess the only thing what I can do is that, Kevin and Yang, or 
other appropriate guys should finish this design as you expect. So now 
I'd better not say anything to avoid bringing any inconvenience.

Tiejun

On 2014/12/19 23:13, Jan Beulich wrote:
>>>> On 19.12.14 at 02:21, <tiejun.chen@intel.com> wrote:
>> #4 Something like USB, is still restricted to current RMRR implementation. We
>>     should work out this case.
>
> This can mean all or nothing. My understanding is that right now code
> assumes that USB devices won't use their RMRR-specified memory
> regions post-boot (kind of contrary to your earlier statement that in
> such a case the regions shouldn't be listed in RMRRs in the first place).
>
>> Design Overview
>> ===============
>>
>> First of all we need to make sure all resources don't overlap RMRR. And then
>> in case of shared ept, we can set these identity entries. And Certainly we
>> will
>> group all devices associated to one same RMRR entry, then make sure all
>> group
>> devices should be assigned to same VM.
>>
>> 1. Setup RMRR identity mapping
>>
>> current status:
>>      * identity mapping only setup in non-shared ept case
>>
>> proposal:
>>
>> In non-shared ept case, IOMMU stuff always set those entries and RMRR is
>> already marked reserved in host so its fine enough.
>
> Is it? Where? Or am I misunderstanding the whole statement, likely
> due to me silently replacing "host" by "guest" (since reservation in
> host address spaces is of no interest here afaict)?
>
>> But in shared ept case, we need to
>> check any conflit, so we should follow up
>>
>>    - gfn space unoccupied
>>          -> insert mapping: success.
>>              gfn:_mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct, p2m_access_rw
>>    - gfn space already occupied by 1:1 RMRR mapping
>>          -> do nothing; success.
>>    - gfn space already occupied by other mapping
>>          -> fail.
>>
>> expectation:
>>      * only devices w/ non-conflicting RMRR can be assigned
>>      * fortunately this achieves the very initial intention to support IGD
>>        pass-through on BDW
>
> Are you trying to say here that doing the above is all you need for
> your specific machine? If so, that's clearly not something to go into
> a design document.
>
> Also there's clearly an alternative proposal: Drop support for sharing
> page tables. Your colleagues will surely have told you that we've
> been considering this for quite some time, and had actually hoped
> for them to do the necessary VT-d side work to allow for this without
> causing performance regressions.
>
>> 2.1 Expose RMRR to user space
>>
>> current status:
>>      * Xen always record RMRR info into one list, acpi_rmrr_units, while
>> parsing
>>        acpi. So we can retrieve these info by lookup that list.
>>
>> proposal:
>>      * RMRR would be exposed by a new hypercall, which Jan already finished
>> in
>>        current version but just expose all RMRR info unconditionally.
>>      * Furthermore we can expose RMRR on demand to diminish shrinking guest
>>        RAM/MMIO space.
>>      * So we will introduce a new parameter, 'rdm_forcecheck' and to
>> collaborate
>>        with SBDFs to control which RMRR should be exposed:
>>
>>          - We can set this parameter in .cfg file like,
>>
>>              rdm_forcecheck = 1 => Of course this should be 0 by default.
>>
>>          '1' means we should force check to reserve all ranges
>> unconditionally.
>>          and 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.
>>
>>          If 0, we just check those assigned pci devices. As you know we already
>
> assigned? Wasn't the plan to have a separate potentially-to-be-
> assigned list? And I can only re-iterate that the name
> "rdm_forcecheck" doesn't really express what you mean. Since
> your intention is to check all devices (rather than do a check that
> otherwise wouldn't be done), "rdm_all" or "rdm_check_all" would
> seem closer to the intended behavior.
>
>>          have such an existing hypercall to assign PCI devices, looks we can
>> work
>>          directly under this hypercall to get that necessary SBDF to sort
>> which
>>          RMRR should be handled. But obviously, we need to get these info
>> before
>>          we populate guest memory to make sure these RMRR ranges should be
>>          excluded from guest memory. But unfortunately the memory populating
>>          takes place before a device assignment, so we can't live on that
>>          directly.
>>
>>          But as we discussed it just benefit that assigned case to reorder
>> that
>>          order, but not good to hotplug case. So we have to introduce a new
>>          DOMCTL to pass that global parameter with SBDF at the same time.
>>
>>          For example, if we own these two RMRR entries,
>
> "own" is confusing here, I assume you mean if there are such entries.
>
>>          [00:14.0]    RMRR region: base_addr ab80a000 end_address ab81dfff
>>          [00:02.0]    RMRR region: base_addr ad000000 end_address af7fffff
>>
>>          If 'rdm_forcecheck = 1', any caller to that hypercall may get these two
>
> s/may/will/ I suppose.
>
>>          entries. But if 'rdm_forcecheck = 0', and in .cfg file,
>>
>>          #1 'pci=[00:14.0, 00:02.0]' -> The caller still get these two entries.
>>          #2 'pci=[00:02.0]' -> The caller just get one entry,
>> 0xad000000:0xaf7fffff
>>          #2 'pci=[00:14.0]' -> The caller just get one entry,
>> 0xab80a000:0xab81dfff
>>          #4 'pci=[others]' or no any pci configuration -> The caller get
>> nothing.
>
> Oh, interesting, you dropped the idea of a separate list of possibly-
> to-be-assigned devices. Why that?
>
>>          And ultimately, if we expose any RMRR entry at gfn,
>>
>>          in non-shared ept case,
>>
>>          p2m table:  valid non-identity mapping, gfn:mfn != 1:1
>
> This would mean ...
>
>>          VT-D table: no such a mapping until set identity mapping,
>>                      gfn:_mfn(gfn) == 1:1 when we have a associated device
>>                      assignment.
>
> ... the two mappings to go out of sync when such a 1:1 mapping gets
> established. I think we should avoid such a situation if at all possible.
>
>>          in shared ept case,
>>
>>          p2m table\VT-D table:  always INVALID until set identity mapping,
>>                                 gfn:_mfn(gfn) == 1:1 when we have a
>> associated
>>                                 device assignment.
>>
>>          But if we don't expose any RMRR entry,
>>
>>          in non-shared ept case,
>>
>>          p2m table:  valid non-identity mapping, gfn:mfn != 1:1
>>          VT-D table: no such a mapping until set identity mapping,
>>                      gfn:_mfn(gfn) == 1:1 when we have a associated device
>>                      assignment.
>>
>>          in shared ept case,
>>
>>          p2m table\VT-D table:  If guest RAM already cover gfn, we have sunc a
>>                                 valid non-identity mapping, gfn:mfn != 1:1,
>> but
>>                                 we can't set any identity mapping again then
>>                                 that associated device can't be assigned
>>                                 successfully. If not, we'll set identity
>> mapping,
>>                                 gfn:_mfn(gfn) == 1:1, to work well.
>
> So in the end we'd still have various cases of different behavior,
> when really it would be much better (if not a requirement) if guest
> observable behavior wouldn't depend on implementation details
> like (non-)shared page tables.
>
>> 2.2 Detect and avoid RMRR conflictions with guest RAM/MMIO
>>
>> current status:
>>      * Currently Xen doesn't detect anything to avoid any conflict.
>>
>> proposal:
>>      * We need to cover all points to check any conflict. Below lists places
>>        where reserved region conflictions should be detected:
>>
>>          1>. libxc:setup_guest():modules_init()
>>
>>          There are some modules, like acpi_module and smbios_module. They may
>>          occupy some ranges so we need to check if they're conflicting with
>>          all ranges from that new hypercall above.
>
> I'm missing of what conflict resolution you expect to do here.
> Following earlier discussion in the context of patch review made
> pretty clear that this isn't really straightforward, having the
> potential to prevent a guest from booting (e.g. when the virtual
> BIOS conflicts with an RMRR).
>
>>          2>. libxc:setup_guest():xc_domain_populate_physmap()
>>
>>          There are two ways to exclude RMRR ranges here:
>>
>>              #1 Before we populate guest RAM without any RMRR range from that
>>                 new hypercall to skip RMRR ranges when populating guest RAM.
>>              #2 In Xen we can fliter RMRR range while calling
>>                 XENMEM_populate_physmap, its no change to libxc, but skip
>>                 setting p2m entry for RMRR ranges in Xen hypervisor
>>
>>          But to compare #1, #2 is not better since Xen still allocate those
>>          range, and we have to sync somewhere else in Xen. And #1 is cleaner
>>          because #2 actually shrinks the available memory size to the guest.
>>
>>          3>. hvmloader:pci_setup()
>>
>>          Here we should populate guest MMIO excluding all ranges from that
>> new
>>          hypercall to detect RMRR conflictions for allocating PCI MMIO BAR.
>>
>>          4>. hvmloader:mem_hole_alloc()
>>
>>          Here we should populate mem holw excluding all ranges from that new
>>          hypercall to detect RMRR conflictions for dynamic allocation in
>>          hvmloader, e.g. as used for IGD opregion
>>
>>          5>. hvmloader:build_e820_table():
>>
>>          Finally we need let VM know that RMRR regions are reserved through
>> e820
>>          table
>>
>>      Its a little bit tricky to handle this inside hvmloader since as you
>> know,
>>      struct hvm_info_table is only a approach between libxc and hvmloader.
>> But
>>      however, making up all above places will bring some duplicated logic.
>>      Especially between libxc and hvmloader, which skip same regions in guest
>>      physical layer(one in populating guest RAM, the other in constructing
>> e820)
>>      But current design has some limitation to pass information between libxc
>> and
>>      hvmloader,
>>
>> struct hvm_info_table {
>>      ...
>>      /*
>>       *  0x0 to page_to_phys(low_mem_pgend)-1:
>>       *    RAM below 4GB (except for VGA hole 0xA0000-0xBFFFF)
>>       */
>>      uint32_t    low_mem_pgend;
>>      ...
>>      /*
>>       *  0x100000000 to page_to_phys(high_mem_pgend)-1:
>>       *    RAM above 4GB
>>       */
>>      uint32_t    high_mem_pgend;
>>      ...
>> }
>>
>>      nothing valuable is passed to hvmloader so we have to figure out a way
>> to
>>      handle those points in hvmloader. Currently,
>>
>>              #1 Reconstruct hvm_info_table{}
>>
>>              We can store all necessary RMRR info into hvm_info_table as
>> well,
>>              then we can pick them conveniently but oftentimes these RMRR
>>              entries are scattered and the number is also undertimined, so
>> its
>>              a little bit ugly to do.
>>
>>              #2 Xenstore
>>
>>              We may store all necessary RMRR info as Xenstore then pick them
>> in
>>              hvmloader.
>>
>>              #3 A hypercall
>>
>>              We may have to call our new hypercall again to pick them, but
>>              obviously this may introduce some duplicated codes.
>>
>>              #4 XENMEM_{set_,}memory_map pair of hypercalls
>>
>>              As Jan commented it "could be used(and is readily available to
>> be
>>              extended that way, since for HVM domains XENMEM_set_memory_map
>>              returns -EPERM at present). The only potentially problematic
>> aspect
>>              I can see with using it might be its limiting of the entry count
>> to
>>              E820MAX." So a preparation patch is required before RMRR, and
>>              hvmloader still needs to query RMRR information.
>
> Somewhere above I'm missing the mentioning of the option to reorder
> operations of hvmloader, to e.g. base PCI BAR assignment on the
> previously set up E820 table, rather than assuming a (mostly) fixed
> size window where to put these.
>
>> 3. Group multiple devices sharing same RMRR entry
>>
>> current status:
>>      * Xen doesn't distinguish if multiple devices share same RMRR entry.
>> This
>>        may lead a leak to corruption, e.g. Device A and device B share same
>> entry
>>        and then device A is assigned to domain A, device B is assigned to
>> domain
>>        B. So domain A can read something from that range, even rewrite
>>        maliciously that range to corrupt device B inside domain B.
>>
>> proposal:
>>      * We will group all devices by means of one same RMRR entry.
>> Theoretically,
>>        we should make sure all devices in one group are allowed to assign to
>> one
>>        VM. But in Xen side the hardware domain owns all devices at first, we
>>        should unbound all group devies before assign one of group device. But
>> its
>>        hard to do such thing in current VT-d stuff. And actually its rare to
>> have
>>        the group device in real world so we just prevent assigning any group
>>        device simply.
>>      * We will introduce two field, gid, in struct, acpi_rmrr_unit:
>>          gid: indicate if this device belongs a group.
>>        Then when we add or attach device in iommu side, we will check this
>> field
>>        if we're assigning a group device then determine if we assign that.
>>
>>
>> expectation:
>>      * Make all device associated to one RMRR to be assigned same VM.
>
> A few lines up you say you're intending to refuse such assignments
> rather than making them happen in a consistent way - what's the
> plan in the end?
>
>> 4. Handle in case of force accessing to RMRR regions
>>
>> proposal:
>>      * Although we already reserve these ranges in guest e820 table, its
>>        possible to access these ranges.
>>        In non-shared ept case it will issue such EPT violation since we have
>> no
>>        p2m table actually. But its same to access other reserved range so
>> just
>>        live on Xen's default behavior. In shared-ept case guest can read or
>>        write anything from this range, but such a leak or corruption just
>>        happens inside same domain so this behavior is also same as a native
>>        case, it should be fine.
>>
>> expectation:
>>      * Don't broken normal RMRR usage.
>
> I'm not getting the purpose of this whole section.
>
>> 5. Re-enable USB
>>
>> current status:
>>      * Currently Xen doesn't allow USB passthrough.
>
> ???
>
>> 6. Hotplug case
>>
>> current status:
>>      * only work well in non-shared ept case or in case of shared ept & all
>>        associated gfns are free.
>>
>> proposal:
>>      * If user ensure there'll be a hotplug device in advace,
>> 'rdm_forcecheck'
>>        can be set to reserve all RMRR range as we describe above. Then any
>>        device can be hotplugged successfully.
>>      * If not, there are still two scenarios here:
>>        in non-shared ept case it still work well as original;
>
> So you continue to assume that the two tables going out of sync is
> acceptable.
>
>>        in shared ept case, its just going a case of "1. Setup RMRR identity
>>        mapping"
>>          - gfn space unoccupied -> insert mapping: success.
>>          - gfn space already occupied by 1:1 RMRR mapping -> do nothing;
>> success.
>>          - gfn space already occupied by other mapping -> fail.
>>
>> expectation:
>>      * provide a way to let hotplug work in case of shared ept totally
>>
>> Open Issue
>> ==========
>>
>> When other stuffs like ballon mechanism, to populate memory accessing RMRR
>> range, or others like qemu, force map RMRR range, we may need to avoid such
>> a
>> possibility but we're not 100% sure this so just open this to double check.
>
> I think a HVM guest can be expected to play by what E820 table
> says is reserved. That includes not using such ranges for ballooning.
> If it still does, it'll get what it deserves.
>
> Jan
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 04:31:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 04:31:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2ueD-0008Vb-6Z; Mon, 22 Dec 2014 04:31: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 1Y2ueC-0008VW-7R
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 04:31:08 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	40/C8-02696-B8E97945; Mon, 22 Dec 2014 04:31:07 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1419222663!16533144!1
X-Originating-IP: [66.165.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 6494 invoked from network); 22 Dec 2014 04:31:04 -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;
	22 Dec 2014 04:31:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,621,1413244800"; d="scan'208";a="206853437"
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.210.2; Sun, 21 Dec 2014 23:31: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 1Y2ue5-0005eb-1X;
	Mon, 22 Dec 2014 04:31:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2ue2-0003UK-PT;
	Mon, 22 Dec 2014 04:30:58 +0000
Date: Mon, 22 Dec 2014 04:30:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32564-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 16995
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 32564: 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="===============3148460369198165485=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3148460369198165485==
Content-Type: text/plain
Content-Length: 16875
Content-Transfer-Encoding: quoted-printable

flight 32564 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32564/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32546
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32546
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32546
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32546

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-xl          10 migrate-support-check        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-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-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-vcpus1 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-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672
baseline version:
 linux                ecb5ec044ab99be1f35e93962fa43e4bb3120d9e

------------------------------------------------------------
People who touched revisions under test:
  Abhilash Kesavan <a.kesavan@samsung.com>
  Alexandru M Stan <amstan@chromium.org>
  Andrzej Hajda <a.hajda@samsung.com>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bintian Wang <bintian.wang@huawei.com>
  Boaz Harrosh <boaz@plexistor.com>
  Boris Bodemann <bobo.barbarossa@gmail.com>
  Bradley Grove <bgrove@attotech.com>
  Brian King <brking@linux.vnet.ibm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Chanwoo Choi <cw00.choi@samsung.com>
  Chao Xie <chao.xie@marvell.com>
  Chen-Yu Tsai <wens@csie.org>
  Chris Zhong <zyw@rock-chips.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@infradead.org>
  Christoph Hellwig <hch@lst.de>
  Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
  Dmitry Torokhov <dtor@chromium.org>
  Doug Anderson <dianders@chromium.org>
  Douglas Gilbert <dgilbert@interlog.com>
  Emilio L=C3=B3pez <emilio@elopez.com.ar>
  Ewan D. Milne <emilne@redhat.com>
  Fengguang Wu <fengguang.wu@intel.com>
  Geert Uytterhoeven <geert+renesas@glider.be>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Hans de Goede <hdegoede@redhat.com>
  Haojian Zhuang <haojian.zhuang@gmail.com>
  Haojian Zhuang <haojian.zhuang@linaro.org>
  Heiko Stuebner <heiko@sntech.de>
  Heiko St=C3=BCbner <heiko@sntech.de>
  James Bottomley <JBottomley@Parallels.com>
  Javier Martinez Canillas <javier.martinez@collabora.co.uk>
  Jeff Chen <cym@rock-chips.com>
  Jianqun <jay.xu@rock-chips.com>
  Julia Lawall <julia.lawall@lip6.fr>
  Julien CHAUVEAU <julien.chauveau@neo-technologies.fr>
  J=C3=A9r=C3=B4me Glisse <jglisse@redhat.com>
  kbuild test robot <fengguang.wu@intel.com>
  Kever Yang <kever.yang@rock-chips.com>
  Kevin Hilman <khilman@linaro.org>
  Konstantin Khlebnikov <k.khlebnikov@samsung.com>
  Krzysztof Kozlowski <k.kozlowski@samsung.com>
  Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
  Kyungmin Park <kyungmin.park@samsung.com>
  Laurence Oberman <loberman@redhat.com>
  Laurent Pinchart <laurent.pinchart@ideasonboard.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Long Li <longli@microsoft.com>
  Mark Brown <broonie@kernel.org>
  Martin K. Petersen <martin.petersen@oracle.com>
  Masahiro Yamada <yamada.m@jp.panasonic.com>
  Mauro Carvalho Chehab <mchehab@osg.samsung.com>
  Maxime Ripard <maxime.ripard@free-electrons.com>
  Michael Turquette <mturquette@linaro.org>
  Michal Marek <mmarek@suse.cz>
  Mike Christie <michaelc@cs.wisc.edu>
  Naveen Krishna Ch <naveenkrishna.ch@gmail.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paul E. McKenney <paulmck@linux.vnet.ibm.com>
  Paul Walmsley <paul@pwsan.com>
  Peter K=C3=BCmmel <syntheticpp@gmx.net>
  Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  Robert Jarzmik <robert.jarzmik@free.fr>
  Seung-Woo Kim <sw0312.kim@samsung.com>
  Simon Horman <horms+renesas@verge.net.au>
  Sonny Rao <sonnyrao@chromium.org>
  Sreekanth Reddy <Sreekanth.Reddy@avagotech.com>
  Stephen Boyd <sboyd@codeaurora.org>
  Sylwester Nawrocki <s.nawrocki@samsung.com>
  Tero Kristo <t-kristo@ti.com>
  Thomas Abraham <thomas.ab@samsung.com>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomasz Figa <tomasz.figa@gmail.com>
  Tomeu Vizoso <tomeu.vizoso@collabora.com>
  Tony Battersby <tonyb@cybernetics.com>
  Tony Lindgren <tony@atomide.com>
  Tony Xie <xxx@rock-chips.com>
  Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
  Wei Yongjun <yongjun_wei@trendmicro.com.cn>
  Wolfram Sang <wsa+renesas@sang-engineering.com>
  Wolfram Sang <wsa@the-dreams.de>
  Zhen Lei <thunder.leizhen@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    
 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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


Pushing revision :

+ branch=3Dlinux-linus
+ revision=3D97bf6af1f928216fd6c5a66e8a57bfa95a659672
+ . 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 linux-linus 97bf6af1f928216fd6c5a66e8a57bfa95a659672
+ branch=3Dlinux-linus
+ revision=3D97bf6af1f928216fd6c5a66e8a57bfa95a659672
+ . 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=3Dlinux
+ xenbranch=3Dxen-unstable
+ '[' xlinux =3D xlinux ']'
+ linuxbranch=3Dlinux-linus
+ '[' 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git =3D x ']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git =3D x ']'
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-linus
++ : 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-linus
+ 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 linux-linus
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ : master
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ : tested/linux-linus
+ : tested/linux-linus
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git 97bf6af1f928216fd6c5a66e8a57bfa95a659672:tested/linux-linus
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   ecb5ec0..97bf6af  97bf6af1f928216fd6c5a66e8a57bfa95a659672 -> tested/linux-linus
+ exit 0


--===============3148460369198165485==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3148460369198165485==--

From xen-devel-bounces@lists.xen.org Mon Dec 22 04:31:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 04:31:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2ueD-0008Vb-6Z; Mon, 22 Dec 2014 04:31: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 1Y2ueC-0008VW-7R
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 04:31:08 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	40/C8-02696-B8E97945; Mon, 22 Dec 2014 04:31:07 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1419222663!16533144!1
X-Originating-IP: [66.165.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 6494 invoked from network); 22 Dec 2014 04:31:04 -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;
	22 Dec 2014 04:31:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,621,1413244800"; d="scan'208";a="206853437"
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.210.2; Sun, 21 Dec 2014 23:31: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 1Y2ue5-0005eb-1X;
	Mon, 22 Dec 2014 04:31:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y2ue2-0003UK-PT;
	Mon, 22 Dec 2014 04:30:58 +0000
Date: Mon, 22 Dec 2014 04:30:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32564-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 16995
X-DLP: MIA2
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 32564: 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="===============3148460369198165485=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3148460369198165485==
Content-Type: text/plain
Content-Length: 16875
Content-Transfer-Encoding: quoted-printable

flight 32564 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32564/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32546
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32546
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32546
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32546

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-xl          10 migrate-support-check        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-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-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-vcpus1 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-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672
baseline version:
 linux                ecb5ec044ab99be1f35e93962fa43e4bb3120d9e

------------------------------------------------------------
People who touched revisions under test:
  Abhilash Kesavan <a.kesavan@samsung.com>
  Alexandru M Stan <amstan@chromium.org>
  Andrzej Hajda <a.hajda@samsung.com>
  Benjamin Herrenschmidt <benh@kernel.crashing.org>
  Bintian Wang <bintian.wang@huawei.com>
  Boaz Harrosh <boaz@plexistor.com>
  Boris Bodemann <bobo.barbarossa@gmail.com>
  Bradley Grove <bgrove@attotech.com>
  Brian King <brking@linux.vnet.ibm.com>
  Chad Dupuis <chad.dupuis@qlogic.com>
  Chanwoo Choi <cw00.choi@samsung.com>
  Chao Xie <chao.xie@marvell.com>
  Chen-Yu Tsai <wens@csie.org>
  Chris Zhong <zyw@rock-chips.com>
  Christian Borntraeger <borntraeger@de.ibm.com>
  Christoph Hellwig <hch@infradead.org>
  Christoph Hellwig <hch@lst.de>
  Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
  Dmitry Torokhov <dtor@chromium.org>
  Doug Anderson <dianders@chromium.org>
  Douglas Gilbert <dgilbert@interlog.com>
  Emilio L=C3=B3pez <emilio@elopez.com.ar>
  Ewan D. Milne <emilne@redhat.com>
  Fengguang Wu <fengguang.wu@intel.com>
  Geert Uytterhoeven <geert+renesas@glider.be>
  Geert Uytterhoeven <geert@linux-m68k.org>
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  Hans de Goede <hdegoede@redhat.com>
  Haojian Zhuang <haojian.zhuang@gmail.com>
  Haojian Zhuang <haojian.zhuang@linaro.org>
  Heiko Stuebner <heiko@sntech.de>
  Heiko St=C3=BCbner <heiko@sntech.de>
  James Bottomley <JBottomley@Parallels.com>
  Javier Martinez Canillas <javier.martinez@collabora.co.uk>
  Jeff Chen <cym@rock-chips.com>
  Jianqun <jay.xu@rock-chips.com>
  Julia Lawall <julia.lawall@lip6.fr>
  Julien CHAUVEAU <julien.chauveau@neo-technologies.fr>
  J=C3=A9r=C3=B4me Glisse <jglisse@redhat.com>
  kbuild test robot <fengguang.wu@intel.com>
  Kever Yang <kever.yang@rock-chips.com>
  Kevin Hilman <khilman@linaro.org>
  Konstantin Khlebnikov <k.khlebnikov@samsung.com>
  Krzysztof Kozlowski <k.kozlowski@samsung.com>
  Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
  Kyungmin Park <kyungmin.park@samsung.com>
  Laurence Oberman <loberman@redhat.com>
  Laurent Pinchart <laurent.pinchart@ideasonboard.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Long Li <longli@microsoft.com>
  Mark Brown <broonie@kernel.org>
  Martin K. Petersen <martin.petersen@oracle.com>
  Masahiro Yamada <yamada.m@jp.panasonic.com>
  Mauro Carvalho Chehab <mchehab@osg.samsung.com>
  Maxime Ripard <maxime.ripard@free-electrons.com>
  Michael Turquette <mturquette@linaro.org>
  Michal Marek <mmarek@suse.cz>
  Mike Christie <michaelc@cs.wisc.edu>
  Naveen Krishna Ch <naveenkrishna.ch@gmail.com>
  Pankaj Dubey <pankaj.dubey@samsung.com>
  Paul E. McKenney <paulmck@linux.vnet.ibm.com>
  Paul Walmsley <paul@pwsan.com>
  Peter K=C3=BCmmel <syntheticpp@gmx.net>
  Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  Robert Jarzmik <robert.jarzmik@free.fr>
  Seung-Woo Kim <sw0312.kim@samsung.com>
  Simon Horman <horms+renesas@verge.net.au>
  Sonny Rao <sonnyrao@chromium.org>
  Sreekanth Reddy <Sreekanth.Reddy@avagotech.com>
  Stephen Boyd <sboyd@codeaurora.org>
  Sylwester Nawrocki <s.nawrocki@samsung.com>
  Tero Kristo <t-kristo@ti.com>
  Thomas Abraham <thomas.ab@samsung.com>
  Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Tomasz Figa <tomasz.figa@gmail.com>
  Tomeu Vizoso <tomeu.vizoso@collabora.com>
  Tony Battersby <tonyb@cybernetics.com>
  Tony Lindgren <tony@atomide.com>
  Tony Xie <xxx@rock-chips.com>
  Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
  Wei Yongjun <yongjun_wei@trendmicro.com.cn>
  Wolfram Sang <wsa+renesas@sang-engineering.com>
  Wolfram Sang <wsa@the-dreams.de>
  Zhen Lei <thunder.leizhen@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    
 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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


Pushing revision :

+ branch=3Dlinux-linus
+ revision=3D97bf6af1f928216fd6c5a66e8a57bfa95a659672
+ . 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 linux-linus 97bf6af1f928216fd6c5a66e8a57bfa95a659672
+ branch=3Dlinux-linus
+ revision=3D97bf6af1f928216fd6c5a66e8a57bfa95a659672
+ . 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=3Dlinux
+ xenbranch=3Dxen-unstable
+ '[' xlinux =3D xlinux ']'
+ linuxbranch=3Dlinux-linus
+ '[' 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git =3D x ']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git =3D x ']'
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-linus
++ : 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-linus
+ 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 linux-linus
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ : master
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ : tested/linux-linus
+ : tested/linux-linus
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git 97bf6af1f928216fd6c5a66e8a57bfa95a659672:tested/linux-linus
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   ecb5ec0..97bf6af  97bf6af1f928216fd6c5a66e8a57bfa95a659672 -> tested/linux-linus
+ exit 0


--===============3148460369198165485==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3148460369198165485==--

From xen-devel-bounces@lists.xen.org Mon Dec 22 04:49:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 04: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 1Y2uvO-0001wu-A0; Mon, 22 Dec 2014 04:48:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Y2uvM-0001wp-Fl
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 04:48:52 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	64/48-02699-3B2A7945; Mon, 22 Dec 2014 04:48:51 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419223727!11084409!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22542 invoked from network); 22 Dec 2014 04:48:47 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-16.tower-27.messagelabs.com with SMTP;
	22 Dec 2014 04:48:47 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by orsmga103.jf.intel.com with ESMTP; 21 Dec 2014 20:46:15 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,621,1413270000"; d="scan'208";a="641202711"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
	by fmsmga001.fm.intel.com with ESMTP; 21 Dec 2014 20:48:43 -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; Mon, 22 Dec 2014 12:48:42 +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; Mon, 22 Dec 2014 12:48:41 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: RMRR Fix Design for Xen
Thread-Index: AQHQHYyhhGRPy0ef10uaWOU7Tk4OtJybB/SA
Date: Mon, 22 Dec 2014 04:48:40 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126121FC4@SHSMSX101.ccr.corp.intel.com>
References: <1418952066-21064-1-git-send-email-tiejun.chen@intel.com>
	<54944EBA02000078000510BF@mail.emea.novell.com>
	<54977DDF.4080404@intel.com>
In-Reply-To: <54977DDF.4080404@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] RMRR Fix Design 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

I'll work out a new design proposal based on below content and previous
discussions. Thanks Tiejun for your hard-working and Jan for your careful
reviews so far.

For below comment:
> > Also there's clearly an alternative proposal: Drop support for sharing
> > page tables. Your colleagues will surely have told you that we've
> > been considering this for quite some time, and had actually hoped
> > for them to do the necessary VT-d side work to allow for this without
> > causing performance regressions.

let's separate it from RMRR discussion, because RMRR issues are about
general p2m and thus orthogonal to the implementation difference between
shared or not-shared fact (though it did lead to different behaviors w/ current
bogus logic).

Thanks
Kevin

> From: Chen, Tiejun
> Sent: Monday, December 22, 2014 10:12 AM
> 
> Jan,
> 
> Thanks for your time but I'm not going to address your comments here.
> Because I heard this design is totally not satisfied your expectation.
> But this really was reviewed with several revisions by Kevin and Yang
> before sending in public...
> 
> Anyway, I guess the only thing what I can do is that, Kevin and Yang, or
> other appropriate guys should finish this design as you expect. So now
> I'd better not say anything to avoid bringing any inconvenience.
> 
> Tiejun
> 
> On 2014/12/19 23:13, Jan Beulich wrote:
> >>>> On 19.12.14 at 02:21, <tiejun.chen@intel.com> wrote:
> >> #4 Something like USB, is still restricted to current RMRR implementation.
> We
> >>     should work out this case.
> >
> > This can mean all or nothing. My understanding is that right now code
> > assumes that USB devices won't use their RMRR-specified memory
> > regions post-boot (kind of contrary to your earlier statement that in
> > such a case the regions shouldn't be listed in RMRRs in the first place).
> >
> >> Design Overview
> >> ===============
> >>
> >> First of all we need to make sure all resources don't overlap RMRR. And
> then
> >> in case of shared ept, we can set these identity entries. And Certainly we
> >> will
> >> group all devices associated to one same RMRR entry, then make sure all
> >> group
> >> devices should be assigned to same VM.
> >>
> >> 1. Setup RMRR identity mapping
> >>
> >> current status:
> >>      * identity mapping only setup in non-shared ept case
> >>
> >> proposal:
> >>
> >> In non-shared ept case, IOMMU stuff always set those entries and RMRR is
> >> already marked reserved in host so its fine enough.
> >
> > Is it? Where? Or am I misunderstanding the whole statement, likely
> > due to me silently replacing "host" by "guest" (since reservation in
> > host address spaces is of no interest here afaict)?
> >
> >> But in shared ept case, we need to
> >> check any conflit, so we should follow up
> >>
> >>    - gfn space unoccupied
> >>          -> insert mapping: success.
> >>              gfn:_mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct,
> p2m_access_rw
> >>    - gfn space already occupied by 1:1 RMRR mapping
> >>          -> do nothing; success.
> >>    - gfn space already occupied by other mapping
> >>          -> fail.
> >>
> >> expectation:
> >>      * only devices w/ non-conflicting RMRR can be assigned
> >>      * fortunately this achieves the very initial intention to support IGD
> >>        pass-through on BDW
> >
> > Are you trying to say here that doing the above is all you need for
> > your specific machine? If so, that's clearly not something to go into
> > a design document.
> >
> > Also there's clearly an alternative proposal: Drop support for sharing
> > page tables. Your colleagues will surely have told you that we've
> > been considering this for quite some time, and had actually hoped
> > for them to do the necessary VT-d side work to allow for this without
> > causing performance regressions.
> >
> >> 2.1 Expose RMRR to user space
> >>
> >> current status:
> >>      * Xen always record RMRR info into one list, acpi_rmrr_units, while
> >> parsing
> >>        acpi. So we can retrieve these info by lookup that list.
> >>
> >> proposal:
> >>      * RMRR would be exposed by a new hypercall, which Jan already
> finished
> >> in
> >>        current version but just expose all RMRR info unconditionally.
> >>      * Furthermore we can expose RMRR on demand to diminish
> shrinking guest
> >>        RAM/MMIO space.
> >>      * So we will introduce a new parameter, 'rdm_forcecheck' and to
> >> collaborate
> >>        with SBDFs to control which RMRR should be exposed:
> >>
> >>          - We can set this parameter in .cfg file like,
> >>
> >>              rdm_forcecheck = 1 => Of course this should be 0 by
> default.
> >>
> >>          '1' means we should force check to reserve all ranges
> >> unconditionally.
> >>          and 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.
> >>
> >>          If 0, we just check those assigned pci devices. As you know we
> already
> >
> > assigned? Wasn't the plan to have a separate potentially-to-be-
> > assigned list? And I can only re-iterate that the name
> > "rdm_forcecheck" doesn't really express what you mean. Since
> > your intention is to check all devices (rather than do a check that
> > otherwise wouldn't be done), "rdm_all" or "rdm_check_all" would
> > seem closer to the intended behavior.
> >
> >>          have such an existing hypercall to assign PCI devices, looks we
> can
> >> work
> >>          directly under this hypercall to get that necessary SBDF to sort
> >> which
> >>          RMRR should be handled. But obviously, we need to get these
> info
> >> before
> >>          we populate guest memory to make sure these RMRR ranges
> should be
> >>          excluded from guest memory. But unfortunately the memory
> populating
> >>          takes place before a device assignment, so we can't live on that
> >>          directly.
> >>
> >>          But as we discussed it just benefit that assigned case to reorder
> >> that
> >>          order, but not good to hotplug case. So we have to introduce a
> new
> >>          DOMCTL to pass that global parameter with SBDF at the same
> time.
> >>
> >>          For example, if we own these two RMRR entries,
> >
> > "own" is confusing here, I assume you mean if there are such entries.
> >
> >>          [00:14.0]    RMRR region: base_addr ab80a000 end_address
> ab81dfff
> >>          [00:02.0]    RMRR region: base_addr ad000000 end_address
> af7fffff
> >>
> >>          If 'rdm_forcecheck = 1', any caller to that hypercall may get
> these two
> >
> > s/may/will/ I suppose.
> >
> >>          entries. But if 'rdm_forcecheck = 0', and in .cfg file,
> >>
> >>          #1 'pci=[00:14.0, 00:02.0]' -> The caller still get these two
> entries.
> >>          #2 'pci=[00:02.0]' -> The caller just get one entry,
> >> 0xad000000:0xaf7fffff
> >>          #2 'pci=[00:14.0]' -> The caller just get one entry,
> >> 0xab80a000:0xab81dfff
> >>          #4 'pci=[others]' or no any pci configuration -> The caller get
> >> nothing.
> >
> > Oh, interesting, you dropped the idea of a separate list of possibly-
> > to-be-assigned devices. Why that?
> >
> >>          And ultimately, if we expose any RMRR entry at gfn,
> >>
> >>          in non-shared ept case,
> >>
> >>          p2m table:  valid non-identity mapping, gfn:mfn != 1:1
> >
> > This would mean ...
> >
> >>          VT-D table: no such a mapping until set identity mapping,
> >>                      gfn:_mfn(gfn) == 1:1 when we have a associated
> device
> >>                      assignment.
> >
> > ... the two mappings to go out of sync when such a 1:1 mapping gets
> > established. I think we should avoid such a situation if at all possible.
> >
> >>          in shared ept case,
> >>
> >>          p2m table\VT-D table:  always INVALID until set identity
> mapping,
> >>                                 gfn:_mfn(gfn) == 1:1 when we have
> a
> >> associated
> >>                                 device assignment.
> >>
> >>          But if we don't expose any RMRR entry,
> >>
> >>          in non-shared ept case,
> >>
> >>          p2m table:  valid non-identity mapping, gfn:mfn != 1:1
> >>          VT-D table: no such a mapping until set identity mapping,
> >>                      gfn:_mfn(gfn) == 1:1 when we have a associated
> device
> >>                      assignment.
> >>
> >>          in shared ept case,
> >>
> >>          p2m table\VT-D table:  If guest RAM already cover gfn, we
> have sunc a
> >>                                 valid non-identity mapping,
> gfn:mfn != 1:1,
> >> but
> >>                                 we can't set any identity mapping
> again then
> >>                                 that associated device can't be
> assigned
> >>                                 successfully. If not, we'll set identity
> >> mapping,
> >>                                 gfn:_mfn(gfn) == 1:1, to work well.
> >
> > So in the end we'd still have various cases of different behavior,
> > when really it would be much better (if not a requirement) if guest
> > observable behavior wouldn't depend on implementation details
> > like (non-)shared page tables.
> >
> >> 2.2 Detect and avoid RMRR conflictions with guest RAM/MMIO
> >>
> >> current status:
> >>      * Currently Xen doesn't detect anything to avoid any conflict.
> >>
> >> proposal:
> >>      * We need to cover all points to check any conflict. Below lists places
> >>        where reserved region conflictions should be detected:
> >>
> >>          1>. libxc:setup_guest():modules_init()
> >>
> >>          There are some modules, like acpi_module and smbios_module.
> They may
> >>          occupy some ranges so we need to check if they're conflicting
> with
> >>          all ranges from that new hypercall above.
> >
> > I'm missing of what conflict resolution you expect to do here.
> > Following earlier discussion in the context of patch review made
> > pretty clear that this isn't really straightforward, having the
> > potential to prevent a guest from booting (e.g. when the virtual
> > BIOS conflicts with an RMRR).
> >
> >>          2>. libxc:setup_guest():xc_domain_populate_physmap()
> >>
> >>          There are two ways to exclude RMRR ranges here:
> >>
> >>              #1 Before we populate guest RAM without any RMRR
> range from that
> >>                 new hypercall to skip RMRR ranges when populating
> guest RAM.
> >>              #2 In Xen we can fliter RMRR range while calling
> >>                 XENMEM_populate_physmap, its no change to libxc,
> but skip
> >>                 setting p2m entry for RMRR ranges in Xen hypervisor
> >>
> >>          But to compare #1, #2 is not better since Xen still allocate those
> >>          range, and we have to sync somewhere else in Xen. And #1 is
> cleaner
> >>          because #2 actually shrinks the available memory size to the
> guest.
> >>
> >>          3>. hvmloader:pci_setup()
> >>
> >>          Here we should populate guest MMIO excluding all ranges
> from that
> >> new
> >>          hypercall to detect RMRR conflictions for allocating PCI MMIO
> BAR.
> >>
> >>          4>. hvmloader:mem_hole_alloc()
> >>
> >>          Here we should populate mem holw excluding all ranges from
> that new
> >>          hypercall to detect RMRR conflictions for dynamic allocation in
> >>          hvmloader, e.g. as used for IGD opregion
> >>
> >>          5>. hvmloader:build_e820_table():
> >>
> >>          Finally we need let VM know that RMRR regions are reserved
> through
> >> e820
> >>          table
> >>
> >>      Its a little bit tricky to handle this inside hvmloader since as you
> >> know,
> >>      struct hvm_info_table is only a approach between libxc and
> hvmloader.
> >> But
> >>      however, making up all above places will bring some duplicated
> logic.
> >>      Especially between libxc and hvmloader, which skip same regions in
> guest
> >>      physical layer(one in populating guest RAM, the other in
> constructing
> >> e820)
> >>      But current design has some limitation to pass information between
> libxc
> >> and
> >>      hvmloader,
> >>
> >> struct hvm_info_table {
> >>      ...
> >>      /*
> >>       *  0x0 to page_to_phys(low_mem_pgend)-1:
> >>       *    RAM below 4GB (except for VGA hole 0xA0000-0xBFFFF)
> >>       */
> >>      uint32_t    low_mem_pgend;
> >>      ...
> >>      /*
> >>       *  0x100000000 to page_to_phys(high_mem_pgend)-1:
> >>       *    RAM above 4GB
> >>       */
> >>      uint32_t    high_mem_pgend;
> >>      ...
> >> }
> >>
> >>      nothing valuable is passed to hvmloader so we have to figure out a
> way
> >> to
> >>      handle those points in hvmloader. Currently,
> >>
> >>              #1 Reconstruct hvm_info_table{}
> >>
> >>              We can store all necessary RMRR info into hvm_info_table
> as
> >> well,
> >>              then we can pick them conveniently but oftentimes these
> RMRR
> >>              entries are scattered and the number is also undertimined,
> so
> >> its
> >>              a little bit ugly to do.
> >>
> >>              #2 Xenstore
> >>
> >>              We may store all necessary RMRR info as Xenstore then
> pick them
> >> in
> >>              hvmloader.
> >>
> >>              #3 A hypercall
> >>
> >>              We may have to call our new hypercall again to pick them,
> but
> >>              obviously this may introduce some duplicated codes.
> >>
> >>              #4 XENMEM_{set_,}memory_map pair of hypercalls
> >>
> >>              As Jan commented it "could be used(and is readily
> available to
> >> be
> >>              extended that way, since for HVM domains
> XENMEM_set_memory_map
> >>              returns -EPERM at present). The only potentially
> problematic
> >> aspect
> >>              I can see with using it might be its limiting of the entry
> count
> >> to
> >>              E820MAX." So a preparation patch is required before
> RMRR, and
> >>              hvmloader still needs to query RMRR information.
> >
> > Somewhere above I'm missing the mentioning of the option to reorder
> > operations of hvmloader, to e.g. base PCI BAR assignment on the
> > previously set up E820 table, rather than assuming a (mostly) fixed
> > size window where to put these.
> >
> >> 3. Group multiple devices sharing same RMRR entry
> >>
> >> current status:
> >>      * Xen doesn't distinguish if multiple devices share same RMRR entry.
> >> This
> >>        may lead a leak to corruption, e.g. Device A and device B share
> same
> >> entry
> >>        and then device A is assigned to domain A, device B is assigned to
> >> domain
> >>        B. So domain A can read something from that range, even rewrite
> >>        maliciously that range to corrupt device B inside domain B.
> >>
> >> proposal:
> >>      * We will group all devices by means of one same RMRR entry.
> >> Theoretically,
> >>        we should make sure all devices in one group are allowed to
> assign to
> >> one
> >>        VM. But in Xen side the hardware domain owns all devices at first,
> we
> >>        should unbound all group devies before assign one of group device.
> But
> >> its
> >>        hard to do such thing in current VT-d stuff. And actually its rare to
> >> have
> >>        the group device in real world so we just prevent assigning any
> group
> >>        device simply.
> >>      * We will introduce two field, gid, in struct, acpi_rmrr_unit:
> >>          gid: indicate if this device belongs a group.
> >>        Then when we add or attach device in iommu side, we will check
> this
> >> field
> >>        if we're assigning a group device then determine if we assign that.
> >>
> >>
> >> expectation:
> >>      * Make all device associated to one RMRR to be assigned same VM.
> >
> > A few lines up you say you're intending to refuse such assignments
> > rather than making them happen in a consistent way - what's the
> > plan in the end?
> >
> >> 4. Handle in case of force accessing to RMRR regions
> >>
> >> proposal:
> >>      * Although we already reserve these ranges in guest e820 table, its
> >>        possible to access these ranges.
> >>        In non-shared ept case it will issue such EPT violation since we
> have
> >> no
> >>        p2m table actually. But its same to access other reserved range so
> >> just
> >>        live on Xen's default behavior. In shared-ept case guest can read
> or
> >>        write anything from this range, but such a leak or corruption just
> >>        happens inside same domain so this behavior is also same as a
> native
> >>        case, it should be fine.
> >>
> >> expectation:
> >>      * Don't broken normal RMRR usage.
> >
> > I'm not getting the purpose of this whole section.
> >
> >> 5. Re-enable USB
> >>
> >> current status:
> >>      * Currently Xen doesn't allow USB passthrough.
> >
> > ???
> >
> >> 6. Hotplug case
> >>
> >> current status:
> >>      * only work well in non-shared ept case or in case of shared ept & all
> >>        associated gfns are free.
> >>
> >> proposal:
> >>      * If user ensure there'll be a hotplug device in advace,
> >> 'rdm_forcecheck'
> >>        can be set to reserve all RMRR range as we describe above. Then
> any
> >>        device can be hotplugged successfully.
> >>      * If not, there are still two scenarios here:
> >>        in non-shared ept case it still work well as original;
> >
> > So you continue to assume that the two tables going out of sync is
> > acceptable.
> >
> >>        in shared ept case, its just going a case of "1. Setup RMRR identity
> >>        mapping"
> >>          - gfn space unoccupied -> insert mapping: success.
> >>          - gfn space already occupied by 1:1 RMRR mapping -> do
> nothing;
> >> success.
> >>          - gfn space already occupied by other mapping -> fail.
> >>
> >> expectation:
> >>      * provide a way to let hotplug work in case of shared ept totally
> >>
> >> Open Issue
> >> ==========
> >>
> >> When other stuffs like ballon mechanism, to populate memory accessing
> RMRR
> >> range, or others like qemu, force map RMRR range, we may need to avoid
> such
> >> a
> >> possibility but we're not 100% sure this so just open this to double check.
> >
> > I think a HVM guest can be expected to play by what E820 table
> > says is reserved. That includes not using such ranges for ballooning.
> > If it still does, it'll get what it deserves.
> >
> > Jan
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 04:49:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 04: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 1Y2uvO-0001wu-A0; Mon, 22 Dec 2014 04:48:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Y2uvM-0001wp-Fl
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 04:48:52 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	64/48-02699-3B2A7945; Mon, 22 Dec 2014 04:48:51 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419223727!11084409!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22542 invoked from network); 22 Dec 2014 04:48:47 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-16.tower-27.messagelabs.com with SMTP;
	22 Dec 2014 04:48:47 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by orsmga103.jf.intel.com with ESMTP; 21 Dec 2014 20:46:15 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,621,1413270000"; d="scan'208";a="641202711"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
	by fmsmga001.fm.intel.com with ESMTP; 21 Dec 2014 20:48:43 -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; Mon, 22 Dec 2014 12:48:42 +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; Mon, 22 Dec 2014 12:48:41 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: RMRR Fix Design for Xen
Thread-Index: AQHQHYyhhGRPy0ef10uaWOU7Tk4OtJybB/SA
Date: Mon, 22 Dec 2014 04:48:40 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126121FC4@SHSMSX101.ccr.corp.intel.com>
References: <1418952066-21064-1-git-send-email-tiejun.chen@intel.com>
	<54944EBA02000078000510BF@mail.emea.novell.com>
	<54977DDF.4080404@intel.com>
In-Reply-To: <54977DDF.4080404@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] RMRR Fix Design 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

I'll work out a new design proposal based on below content and previous
discussions. Thanks Tiejun for your hard-working and Jan for your careful
reviews so far.

For below comment:
> > Also there's clearly an alternative proposal: Drop support for sharing
> > page tables. Your colleagues will surely have told you that we've
> > been considering this for quite some time, and had actually hoped
> > for them to do the necessary VT-d side work to allow for this without
> > causing performance regressions.

let's separate it from RMRR discussion, because RMRR issues are about
general p2m and thus orthogonal to the implementation difference between
shared or not-shared fact (though it did lead to different behaviors w/ current
bogus logic).

Thanks
Kevin

> From: Chen, Tiejun
> Sent: Monday, December 22, 2014 10:12 AM
> 
> Jan,
> 
> Thanks for your time but I'm not going to address your comments here.
> Because I heard this design is totally not satisfied your expectation.
> But this really was reviewed with several revisions by Kevin and Yang
> before sending in public...
> 
> Anyway, I guess the only thing what I can do is that, Kevin and Yang, or
> other appropriate guys should finish this design as you expect. So now
> I'd better not say anything to avoid bringing any inconvenience.
> 
> Tiejun
> 
> On 2014/12/19 23:13, Jan Beulich wrote:
> >>>> On 19.12.14 at 02:21, <tiejun.chen@intel.com> wrote:
> >> #4 Something like USB, is still restricted to current RMRR implementation.
> We
> >>     should work out this case.
> >
> > This can mean all or nothing. My understanding is that right now code
> > assumes that USB devices won't use their RMRR-specified memory
> > regions post-boot (kind of contrary to your earlier statement that in
> > such a case the regions shouldn't be listed in RMRRs in the first place).
> >
> >> Design Overview
> >> ===============
> >>
> >> First of all we need to make sure all resources don't overlap RMRR. And
> then
> >> in case of shared ept, we can set these identity entries. And Certainly we
> >> will
> >> group all devices associated to one same RMRR entry, then make sure all
> >> group
> >> devices should be assigned to same VM.
> >>
> >> 1. Setup RMRR identity mapping
> >>
> >> current status:
> >>      * identity mapping only setup in non-shared ept case
> >>
> >> proposal:
> >>
> >> In non-shared ept case, IOMMU stuff always set those entries and RMRR is
> >> already marked reserved in host so its fine enough.
> >
> > Is it? Where? Or am I misunderstanding the whole statement, likely
> > due to me silently replacing "host" by "guest" (since reservation in
> > host address spaces is of no interest here afaict)?
> >
> >> But in shared ept case, we need to
> >> check any conflit, so we should follow up
> >>
> >>    - gfn space unoccupied
> >>          -> insert mapping: success.
> >>              gfn:_mfn(gfn), PAGE_ORDER_4K, p2m_mmio_direct,
> p2m_access_rw
> >>    - gfn space already occupied by 1:1 RMRR mapping
> >>          -> do nothing; success.
> >>    - gfn space already occupied by other mapping
> >>          -> fail.
> >>
> >> expectation:
> >>      * only devices w/ non-conflicting RMRR can be assigned
> >>      * fortunately this achieves the very initial intention to support IGD
> >>        pass-through on BDW
> >
> > Are you trying to say here that doing the above is all you need for
> > your specific machine? If so, that's clearly not something to go into
> > a design document.
> >
> > Also there's clearly an alternative proposal: Drop support for sharing
> > page tables. Your colleagues will surely have told you that we've
> > been considering this for quite some time, and had actually hoped
> > for them to do the necessary VT-d side work to allow for this without
> > causing performance regressions.
> >
> >> 2.1 Expose RMRR to user space
> >>
> >> current status:
> >>      * Xen always record RMRR info into one list, acpi_rmrr_units, while
> >> parsing
> >>        acpi. So we can retrieve these info by lookup that list.
> >>
> >> proposal:
> >>      * RMRR would be exposed by a new hypercall, which Jan already
> finished
> >> in
> >>        current version but just expose all RMRR info unconditionally.
> >>      * Furthermore we can expose RMRR on demand to diminish
> shrinking guest
> >>        RAM/MMIO space.
> >>      * So we will introduce a new parameter, 'rdm_forcecheck' and to
> >> collaborate
> >>        with SBDFs to control which RMRR should be exposed:
> >>
> >>          - We can set this parameter in .cfg file like,
> >>
> >>              rdm_forcecheck = 1 => Of course this should be 0 by
> default.
> >>
> >>          '1' means we should force check to reserve all ranges
> >> unconditionally.
> >>          and 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.
> >>
> >>          If 0, we just check those assigned pci devices. As you know we
> already
> >
> > assigned? Wasn't the plan to have a separate potentially-to-be-
> > assigned list? And I can only re-iterate that the name
> > "rdm_forcecheck" doesn't really express what you mean. Since
> > your intention is to check all devices (rather than do a check that
> > otherwise wouldn't be done), "rdm_all" or "rdm_check_all" would
> > seem closer to the intended behavior.
> >
> >>          have such an existing hypercall to assign PCI devices, looks we
> can
> >> work
> >>          directly under this hypercall to get that necessary SBDF to sort
> >> which
> >>          RMRR should be handled. But obviously, we need to get these
> info
> >> before
> >>          we populate guest memory to make sure these RMRR ranges
> should be
> >>          excluded from guest memory. But unfortunately the memory
> populating
> >>          takes place before a device assignment, so we can't live on that
> >>          directly.
> >>
> >>          But as we discussed it just benefit that assigned case to reorder
> >> that
> >>          order, but not good to hotplug case. So we have to introduce a
> new
> >>          DOMCTL to pass that global parameter with SBDF at the same
> time.
> >>
> >>          For example, if we own these two RMRR entries,
> >
> > "own" is confusing here, I assume you mean if there are such entries.
> >
> >>          [00:14.0]    RMRR region: base_addr ab80a000 end_address
> ab81dfff
> >>          [00:02.0]    RMRR region: base_addr ad000000 end_address
> af7fffff
> >>
> >>          If 'rdm_forcecheck = 1', any caller to that hypercall may get
> these two
> >
> > s/may/will/ I suppose.
> >
> >>          entries. But if 'rdm_forcecheck = 0', and in .cfg file,
> >>
> >>          #1 'pci=[00:14.0, 00:02.0]' -> The caller still get these two
> entries.
> >>          #2 'pci=[00:02.0]' -> The caller just get one entry,
> >> 0xad000000:0xaf7fffff
> >>          #2 'pci=[00:14.0]' -> The caller just get one entry,
> >> 0xab80a000:0xab81dfff
> >>          #4 'pci=[others]' or no any pci configuration -> The caller get
> >> nothing.
> >
> > Oh, interesting, you dropped the idea of a separate list of possibly-
> > to-be-assigned devices. Why that?
> >
> >>          And ultimately, if we expose any RMRR entry at gfn,
> >>
> >>          in non-shared ept case,
> >>
> >>          p2m table:  valid non-identity mapping, gfn:mfn != 1:1
> >
> > This would mean ...
> >
> >>          VT-D table: no such a mapping until set identity mapping,
> >>                      gfn:_mfn(gfn) == 1:1 when we have a associated
> device
> >>                      assignment.
> >
> > ... the two mappings to go out of sync when such a 1:1 mapping gets
> > established. I think we should avoid such a situation if at all possible.
> >
> >>          in shared ept case,
> >>
> >>          p2m table\VT-D table:  always INVALID until set identity
> mapping,
> >>                                 gfn:_mfn(gfn) == 1:1 when we have
> a
> >> associated
> >>                                 device assignment.
> >>
> >>          But if we don't expose any RMRR entry,
> >>
> >>          in non-shared ept case,
> >>
> >>          p2m table:  valid non-identity mapping, gfn:mfn != 1:1
> >>          VT-D table: no such a mapping until set identity mapping,
> >>                      gfn:_mfn(gfn) == 1:1 when we have a associated
> device
> >>                      assignment.
> >>
> >>          in shared ept case,
> >>
> >>          p2m table\VT-D table:  If guest RAM already cover gfn, we
> have sunc a
> >>                                 valid non-identity mapping,
> gfn:mfn != 1:1,
> >> but
> >>                                 we can't set any identity mapping
> again then
> >>                                 that associated device can't be
> assigned
> >>                                 successfully. If not, we'll set identity
> >> mapping,
> >>                                 gfn:_mfn(gfn) == 1:1, to work well.
> >
> > So in the end we'd still have various cases of different behavior,
> > when really it would be much better (if not a requirement) if guest
> > observable behavior wouldn't depend on implementation details
> > like (non-)shared page tables.
> >
> >> 2.2 Detect and avoid RMRR conflictions with guest RAM/MMIO
> >>
> >> current status:
> >>      * Currently Xen doesn't detect anything to avoid any conflict.
> >>
> >> proposal:
> >>      * We need to cover all points to check any conflict. Below lists places
> >>        where reserved region conflictions should be detected:
> >>
> >>          1>. libxc:setup_guest():modules_init()
> >>
> >>          There are some modules, like acpi_module and smbios_module.
> They may
> >>          occupy some ranges so we need to check if they're conflicting
> with
> >>          all ranges from that new hypercall above.
> >
> > I'm missing of what conflict resolution you expect to do here.
> > Following earlier discussion in the context of patch review made
> > pretty clear that this isn't really straightforward, having the
> > potential to prevent a guest from booting (e.g. when the virtual
> > BIOS conflicts with an RMRR).
> >
> >>          2>. libxc:setup_guest():xc_domain_populate_physmap()
> >>
> >>          There are two ways to exclude RMRR ranges here:
> >>
> >>              #1 Before we populate guest RAM without any RMRR
> range from that
> >>                 new hypercall to skip RMRR ranges when populating
> guest RAM.
> >>              #2 In Xen we can fliter RMRR range while calling
> >>                 XENMEM_populate_physmap, its no change to libxc,
> but skip
> >>                 setting p2m entry for RMRR ranges in Xen hypervisor
> >>
> >>          But to compare #1, #2 is not better since Xen still allocate those
> >>          range, and we have to sync somewhere else in Xen. And #1 is
> cleaner
> >>          because #2 actually shrinks the available memory size to the
> guest.
> >>
> >>          3>. hvmloader:pci_setup()
> >>
> >>          Here we should populate guest MMIO excluding all ranges
> from that
> >> new
> >>          hypercall to detect RMRR conflictions for allocating PCI MMIO
> BAR.
> >>
> >>          4>. hvmloader:mem_hole_alloc()
> >>
> >>          Here we should populate mem holw excluding all ranges from
> that new
> >>          hypercall to detect RMRR conflictions for dynamic allocation in
> >>          hvmloader, e.g. as used for IGD opregion
> >>
> >>          5>. hvmloader:build_e820_table():
> >>
> >>          Finally we need let VM know that RMRR regions are reserved
> through
> >> e820
> >>          table
> >>
> >>      Its a little bit tricky to handle this inside hvmloader since as you
> >> know,
> >>      struct hvm_info_table is only a approach between libxc and
> hvmloader.
> >> But
> >>      however, making up all above places will bring some duplicated
> logic.
> >>      Especially between libxc and hvmloader, which skip same regions in
> guest
> >>      physical layer(one in populating guest RAM, the other in
> constructing
> >> e820)
> >>      But current design has some limitation to pass information between
> libxc
> >> and
> >>      hvmloader,
> >>
> >> struct hvm_info_table {
> >>      ...
> >>      /*
> >>       *  0x0 to page_to_phys(low_mem_pgend)-1:
> >>       *    RAM below 4GB (except for VGA hole 0xA0000-0xBFFFF)
> >>       */
> >>      uint32_t    low_mem_pgend;
> >>      ...
> >>      /*
> >>       *  0x100000000 to page_to_phys(high_mem_pgend)-1:
> >>       *    RAM above 4GB
> >>       */
> >>      uint32_t    high_mem_pgend;
> >>      ...
> >> }
> >>
> >>      nothing valuable is passed to hvmloader so we have to figure out a
> way
> >> to
> >>      handle those points in hvmloader. Currently,
> >>
> >>              #1 Reconstruct hvm_info_table{}
> >>
> >>              We can store all necessary RMRR info into hvm_info_table
> as
> >> well,
> >>              then we can pick them conveniently but oftentimes these
> RMRR
> >>              entries are scattered and the number is also undertimined,
> so
> >> its
> >>              a little bit ugly to do.
> >>
> >>              #2 Xenstore
> >>
> >>              We may store all necessary RMRR info as Xenstore then
> pick them
> >> in
> >>              hvmloader.
> >>
> >>              #3 A hypercall
> >>
> >>              We may have to call our new hypercall again to pick them,
> but
> >>              obviously this may introduce some duplicated codes.
> >>
> >>              #4 XENMEM_{set_,}memory_map pair of hypercalls
> >>
> >>              As Jan commented it "could be used(and is readily
> available to
> >> be
> >>              extended that way, since for HVM domains
> XENMEM_set_memory_map
> >>              returns -EPERM at present). The only potentially
> problematic
> >> aspect
> >>              I can see with using it might be its limiting of the entry
> count
> >> to
> >>              E820MAX." So a preparation patch is required before
> RMRR, and
> >>              hvmloader still needs to query RMRR information.
> >
> > Somewhere above I'm missing the mentioning of the option to reorder
> > operations of hvmloader, to e.g. base PCI BAR assignment on the
> > previously set up E820 table, rather than assuming a (mostly) fixed
> > size window where to put these.
> >
> >> 3. Group multiple devices sharing same RMRR entry
> >>
> >> current status:
> >>      * Xen doesn't distinguish if multiple devices share same RMRR entry.
> >> This
> >>        may lead a leak to corruption, e.g. Device A and device B share
> same
> >> entry
> >>        and then device A is assigned to domain A, device B is assigned to
> >> domain
> >>        B. So domain A can read something from that range, even rewrite
> >>        maliciously that range to corrupt device B inside domain B.
> >>
> >> proposal:
> >>      * We will group all devices by means of one same RMRR entry.
> >> Theoretically,
> >>        we should make sure all devices in one group are allowed to
> assign to
> >> one
> >>        VM. But in Xen side the hardware domain owns all devices at first,
> we
> >>        should unbound all group devies before assign one of group device.
> But
> >> its
> >>        hard to do such thing in current VT-d stuff. And actually its rare to
> >> have
> >>        the group device in real world so we just prevent assigning any
> group
> >>        device simply.
> >>      * We will introduce two field, gid, in struct, acpi_rmrr_unit:
> >>          gid: indicate if this device belongs a group.
> >>        Then when we add or attach device in iommu side, we will check
> this
> >> field
> >>        if we're assigning a group device then determine if we assign that.
> >>
> >>
> >> expectation:
> >>      * Make all device associated to one RMRR to be assigned same VM.
> >
> > A few lines up you say you're intending to refuse such assignments
> > rather than making them happen in a consistent way - what's the
> > plan in the end?
> >
> >> 4. Handle in case of force accessing to RMRR regions
> >>
> >> proposal:
> >>      * Although we already reserve these ranges in guest e820 table, its
> >>        possible to access these ranges.
> >>        In non-shared ept case it will issue such EPT violation since we
> have
> >> no
> >>        p2m table actually. But its same to access other reserved range so
> >> just
> >>        live on Xen's default behavior. In shared-ept case guest can read
> or
> >>        write anything from this range, but such a leak or corruption just
> >>        happens inside same domain so this behavior is also same as a
> native
> >>        case, it should be fine.
> >>
> >> expectation:
> >>      * Don't broken normal RMRR usage.
> >
> > I'm not getting the purpose of this whole section.
> >
> >> 5. Re-enable USB
> >>
> >> current status:
> >>      * Currently Xen doesn't allow USB passthrough.
> >
> > ???
> >
> >> 6. Hotplug case
> >>
> >> current status:
> >>      * only work well in non-shared ept case or in case of shared ept & all
> >>        associated gfns are free.
> >>
> >> proposal:
> >>      * If user ensure there'll be a hotplug device in advace,
> >> 'rdm_forcecheck'
> >>        can be set to reserve all RMRR range as we describe above. Then
> any
> >>        device can be hotplugged successfully.
> >>      * If not, there are still two scenarios here:
> >>        in non-shared ept case it still work well as original;
> >
> > So you continue to assume that the two tables going out of sync is
> > acceptable.
> >
> >>        in shared ept case, its just going a case of "1. Setup RMRR identity
> >>        mapping"
> >>          - gfn space unoccupied -> insert mapping: success.
> >>          - gfn space already occupied by 1:1 RMRR mapping -> do
> nothing;
> >> success.
> >>          - gfn space already occupied by other mapping -> fail.
> >>
> >> expectation:
> >>      * provide a way to let hotplug work in case of shared ept totally
> >>
> >> Open Issue
> >> ==========
> >>
> >> When other stuffs like ballon mechanism, to populate memory accessing
> RMRR
> >> range, or others like qemu, force map RMRR range, we may need to avoid
> such
> >> a
> >> possibility but we're not 100% sure this so just open this to double check.
> >
> > I think a HVM guest can be expected to play by what E820 table
> > says is reserved. That includes not using such ranges for ballooning.
> > If it still does, it'll get what it deserves.
> >
> > Jan
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 07:05:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 07: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 1Y2x3H-0005o7-HK; Mon, 22 Dec 2014 07:05:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <upanshu.singhal@emc.com>) id 1Y2x3F-0005o2-Ng
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 07:05:10 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	76/EE-02957-4A2C7945; Mon, 22 Dec 2014 07:05:08 +0000
X-Env-Sender: upanshu.singhal@emc.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1419231906!16528721!1
X-Originating-IP: [128.221.224.79]
X-SpamReason: No, hits=1.8 required=7.0 tests=BODY_RANDOM_LONG,HOT_NASTY,
	HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9403 invoked from network); 22 Dec 2014 07:05:07 -0000
Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2014 07:05:07 -0000
Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com
	[10.106.48.155])
	by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBM755dm018080
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Dec 2014 02:05:05 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sBM755dm018080
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013;
	t=1419231905; bh=IttnuKwFQcd696F6gpgmp51ut1Y=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	Content-Type:MIME-Version;
	b=lqWtJKjF1Eddvw2tqhGnhiWC6WRyXnkl2V0YYrEtX0OgqOEwLNnv7IMv8eu52Ycw8
	pe9MTnq0ccHAm/ciC9daU40O9JOvs4jjqtixhPccaxReX9y10ksQqBTx5KeLedNg36
	ldG8tkvEJLgzQvydaLZHZDpWA6FDBirm0eVWgK7k=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sBM755dm018080
Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com
	[10.253.24.21]) by maildlpprd51.lss.emc.com (RSA Interceptor);
	Mon, 22 Dec 2014 02:04:49 -0500
Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104])
	by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBM74tM3013852
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 22 Dec 2014 02:04:55 -0500
Received: from MXHUB202.corp.emc.com (10.253.68.28) by mxhub02.corp.emc.com
	(10.254.141.104) with Microsoft SMTP Server (TLS) id 8.3.327.1;
	Mon, 22 Dec 2014 02:04:54 -0500
Received: from MX101CL01.corp.emc.com ([169.254.1.90]) by
	MXHUB202.corp.emc.com ([10.253.68.28]) with mapi id 14.03.0195.001;
	Mon, 22 Dec 2014 02:04:54 -0500
From: "Singhal, Upanshu" <upanshu.singhal@emc.com>
To: Don Slutz <dslutz@verizon.com>
Thread-Topic: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
Thread-Index: AdAbg+gVpGg69F+/TKC4f+QiMDYySwAgTHmAAGwE/hA=
Date: Mon, 22 Dec 2014 07:04:53 +0000
Message-ID: <6A5D14D0DFEABC43BE832A0E492963F14EBB922A@MX101CL01.corp.emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
	<5494A6AF.1030802@terremark.com>
In-Reply-To: <5494A6AF.1030802@terremark.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.30.79.65]
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com
X-RSA-Classifications: DLP to NYP, public
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1968152956517758201=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1968152956517758201==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_6A5D14D0DFEABC43BE832A0E492963F14EBB922AMX101CL01corpem_"

--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB922AMX101CL01corpem_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Don,

xen_emul_unplug=3Dunnecessary  does the trick, I am able to see the vmxnet3=
 driver using lspci and ethtool -I eth0. Thanks a lot for your help, much a=
ppreciated.

Performance between vmxnet3 running on XEN is about 1/3 of vmxnet3 running =
on ESXi. Similar performance number I get between vmxnet3 on ESXi and vif o=
n XEN. Do you know what could be the reason for this?

Thanks,
-Upanshu

From: Don Slutz [mailto:dslutz@verizon.com]
Sent: Saturday, December 20, 2014 3:59 AM
To: Singhal, Upanshu
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

xen_emul_unplug=3Dunnecessary (kernel arg) may help you here.

Also udev likes to rename your devices.

Here is a lspci from a guest:


[root@C63-min-tools ~]# 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 I=
I]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 0=
1)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)
00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)

And to help:

[root@C63-min-tools ~]# ls -l /sys/class/net/*/device
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> ../../=
../vif-0
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> ../../=
../vif-1
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> ../../=
../vif-2
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> ../../=
../vif-3
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> ../../=
../vif-4
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> ../../=
../vif-5
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> ../../=
../vif-6
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> ../../=
../vif-7
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> ../../=
../vif-8
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> ../../=
../vif-9
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device -> ..=
/../../0000:00:04.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device -> ..=
/../../0000:00:05.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device -> ..=
/../../0000:00:06.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device -> ..=
/../../0000:00:07.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device -> ..=
/../../0000:00:08.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device -> ..=
/../../0000:00:09.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device -> ..=
/../../0000:00:0a.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device -> ..=
/../../0000:00:0b.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device -> ..=
/../../0000:00:0c.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device -> ..=
/../../0000:00:0d.0


   -Don Slutz

On 12/19/14 07:04, Singhal, Upanshu wrote:
Hello,

In one of my experiment, I am building a Linux VM with Network interface mo=
del as "vmxnet3". I am able to create the VM successfully, but I see that t=
he driver loaded is "vif" and not "vmxnet3". I am using the following optio=
n for the network interface: vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:=
22, bridge=3Dxenbr0, model=3Dvmxnet3' ]

I tried with model as e1000 and it works fine. Lspci command also does not =
show vmxnet3. Though, qemu device help shows that "vmxnet3" is supported on=
 XEN 4.4.1 version I am using.

I tried searching on internet about the right configuration for vmxnet3 wit=
h XEN, but not able to find right information. Can someone please help me o=
n how to create a VM with vmxnet3?

This experiment I am doing to compare the difference between vmxnet3 bandwi=
dth on VMWARE ESXi vs. XEN Server. My sample VM configuration file is:

# This configures an HVM rather than PV guest
builder =3D "hvm"

# Guest name
name =3D "rhel-vmxnet3-xen-2.hvm"

# 128-bit UUID for the domain as a hexadecimal number.
# Use "uuidgen" to generate one if required.
# The default behavior is to generate a new UUID each time the guest is sta=
rted.
#uuid =3D "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

# Enable Microsoft Hyper-V compatibile paravirtualisation /
# enlightenment interfaces. Turning this on can improve Windows guest
# performance and is therefore recommended
#viridian =3D 1

# Initial memory allocation (MB)
memory =3D 8192

# Maximum memory (MB)
# If this is greater than `memory' then the slack will start ballooned
# (this assumes guest kernel support for ballooning)
#maxmem =3D 512

# Number of VCPUS
vcpus =3D 8

# Network devices
# A list of 'vifspec' entries as described in
# docs/misc/xl-network-configuration.markdown
vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dxenbr1, model=3D=
vmxnet3' ]

# Disk Devices
# A list of `diskspec' entries as described in
# docs/misc/xl-disk-configuration.txt
disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', 'file:/root=
/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r<file:///\\root\rhel-server-6.4-=
x86_64-dvd.iso,hdc:cdrom,r>' ]
boot=3D'cd'

# Guest VGA console configuration, either SDL or VNC
# sdl =3D 1
vnc =3D 2

Thanks,
-Upanshu


Upanshu Singhal
EMC Data Storage Systems, Bangalore, India.
Phone: 91-80-67375604





_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xen.org<mailto:Xen-devel@lists.xen.org>

http://lists.xen.org/xen-devel


--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB922AMX101CL01corpem_
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:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.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 bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hello Don,<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal">xen_emul_unplug=3Dunnecessary<span style=3D"color:#1=
F497D"> &nbsp;does the trick, I am able to see the vmxnet3 driver using lsp=
ci and ethtool &#8211;I eth0. Thanks a lot for your help, much appreciated.=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Performance between vm=
xnet3 running on XEN is about 1/3 of vmxnet3 running on ESXi. Similar perfo=
rmance number I get between vmxnet3 on ESXi and vif on XEN. Do you know wha=
t could be the reason for this?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">-Upanshu<o:p></o:p></s=
pan></p>
</div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext"> Don Slutz [mailto:dslutz@verizon.com]
<br>
<b>Sent:</b> Saturday, December 20, 2014 3:59 AM<br>
<b>To:</b> Singhal, Upanshu<br>
<b>Cc:</b> xen-devel@lists.xen.org<br>
<b>Subject:</b> Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1<o:p></=
o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">xen_emul_unplug=3Dunn=
ecessary (kernel arg) may help you here.<br>
<br>
Also udev likes to rename your devices.<br>
<br>
Here is a lspci from a guest:<br>
<br>
<br>
[root@C63-min-tools ~]# lspci<br>
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02=
)<br>
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]<=
br>
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton I=
I]<br>
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)<br>
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 0=
1)<br>
00:03.0 VGA compatible controller: Cirrus Logic GD 5446<br>
00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)<br>
00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)<br>
<br>
And to help:<br>
<br>
[root@C63-min-tools ~]# ls -l /sys/class/net/*/device<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -&gt; ../=
../../vif-0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -&gt; ../=
../../vif-1<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -&gt; ../=
../../vif-2<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -&gt; ../=
../../vif-3<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -&gt; ../=
../../vif-4<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -&gt; ../=
../../vif-5<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -&gt; ../=
../../vif-6<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -&gt; ../=
../../vif-7<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -&gt; ../=
../../vif-8<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -&gt; ../=
../../vif-9<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device -&gt;=
 ../../../0000:00:04.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device -&gt;=
 ../../../0000:00:05.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device -&gt;=
 ../../../0000:00:06.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device -&gt;=
 ../../../0000:00:07.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device -&gt;=
 ../../../0000:00:08.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device -&gt;=
 ../../../0000:00:09.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device -&gt;=
 ../../../0000:00:0a.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device -&gt;=
 ../../../0000:00:0b.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device -&gt;=
 ../../../0000:00:0c.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device -&gt;=
 ../../../0000:00:0d.0<br>
<br>
<br>
&nbsp;&nbsp; -Don Slutz<br>
<br>
<o:p></o:p></p>
<div>
<p class=3D"MsoNormal">On 12/19/14 07:04, Singhal, Upanshu wrote:<o:p></o:p=
></p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">Hello,<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">In one of my experiment, I am building a Linux VM wi=
th Network interface model as &#8220;vmxnet3&#8221;. I am able to create th=
e VM successfully, but I see that the driver loaded is &#8220;vif&#8221; an=
d not &#8220;vmxnet3&#8221;. I am using the following option for the networ=
k
 interface: <b>vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dx=
enbr0, model=3Dvmxnet3' ]</b><o:p></o:p></p>
<p class=3D"MsoNormal"><b>&nbsp;</b><o:p></o:p></p>
<p class=3D"MsoNormal">I tried with model as e1000 and it works fine. Lspci=
 command also does not show vmxnet3. Though, qemu device help shows that &#=
8220;vmxnet3&#8221; is supported on XEN 4.4.1 version I am using.
<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">I tried searching on internet about the right config=
uration for vmxnet3 with XEN, but not able to find right information. Can s=
omeone please help me on how to create a VM with vmxnet3?<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">This experiment I am doing to compare the difference=
 between vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM conf=
iguration file is:<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># This configures an HVM rather than PV guest<o:p></=
o:p></p>
<p class=3D"MsoNormal">builder =3D &quot;hvm&quot;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Guest name<o:p></o:p></p>
<p class=3D"MsoNormal"><b>name =3D &quot;rhel-vmxnet3-xen-2.hvm&quot;</b><o=
:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># 128-bit UUID for the domain as a hexadecimal numbe=
r.<o:p></o:p></p>
<p class=3D"MsoNormal"># Use &quot;uuidgen&quot; to generate one if require=
d.<o:p></o:p></p>
<p class=3D"MsoNormal"># The default behavior is to generate a new UUID eac=
h time the guest is started.<o:p></o:p></p>
<p class=3D"MsoNormal">#uuid =3D &quot;XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=
&quot;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Enable Microsoft Hyper-V compatibile paravirtualis=
ation /<o:p></o:p></p>
<p class=3D"MsoNormal"># enlightenment interfaces. Turning this on can impr=
ove Windows guest<o:p></o:p></p>
<p class=3D"MsoNormal"># performance and is therefore recommended<o:p></o:p=
></p>
<p class=3D"MsoNormal">#viridian =3D 1<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Initial memory allocation (MB)<o:p></o:p></p>
<p class=3D"MsoNormal"><b>memory =3D 8192</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Maximum memory (MB)<o:p></o:p></p>
<p class=3D"MsoNormal"># If this is greater than `memory' then the slack wi=
ll start ballooned<o:p></o:p></p>
<p class=3D"MsoNormal"># (this assumes guest kernel support for ballooning)=
<o:p></o:p></p>
<p class=3D"MsoNormal">#maxmem =3D 512<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Number of VCPUS<o:p></o:p></p>
<p class=3D"MsoNormal"><b>vcpus =3D 8</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Network devices<o:p></o:p></p>
<p class=3D"MsoNormal"># A list of 'vifspec' entries as described in<o:p></=
o:p></p>
<p class=3D"MsoNormal"># docs/misc/xl-network-configuration.markdown<o:p></=
o:p></p>
<p class=3D"MsoNormal">vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, br=
idge=3Dxenbr1, model=3Dvmxnet3' ]<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Disk Devices<o:p></o:p></p>
<p class=3D"MsoNormal"># A list of `diskspec' entries as described in<o:p><=
/o:p></p>
<p class=3D"MsoNormal"># docs/misc/xl-disk-configuration.txt<o:p></o:p></p>
<p class=3D"MsoNormal"><b>disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img=
,raw,xvda,rw', '<a href=3D"file:///\\root\rhel-server-6.4-x86_64-dvd.iso,hd=
c:cdrom,r">file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r</a>' ]</b>=
<o:p></o:p></p>
<p class=3D"MsoNormal"><b>boot=3D'cd'</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Guest VGA console configuration, either SDL or VNC=
<o:p></o:p></p>
<p class=3D"MsoNormal"># sdl =3D 1<o:p></o:p></p>
<p class=3D"MsoNormal"><b>vnc =3D 2</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal">-Upanshu<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">Upanshu Singhal<o:p></o:p></p>
<p class=3D"MsoNormal">EMC Data Storage Systems, Bangalore, India.<o:p></o:=
p></p>
<p class=3D"MsoNormal">Phone: 91-80-67375604<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><br>
<br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Xen-devel mailing list<o:p></o:p></pre>
<pre><a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<o:p></o:p></pre>
<pre><a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-de=
vel</a><o:p></o:p></pre>
</blockquote>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB922AMX101CL01corpem_--


--===============1968152956517758201==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1968152956517758201==--


From xen-devel-bounces@lists.xen.org Mon Dec 22 07:05:48 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 07: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 1Y2x3H-0005o7-HK; Mon, 22 Dec 2014 07:05:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <upanshu.singhal@emc.com>) id 1Y2x3F-0005o2-Ng
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 07:05:10 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	76/EE-02957-4A2C7945; Mon, 22 Dec 2014 07:05:08 +0000
X-Env-Sender: upanshu.singhal@emc.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1419231906!16528721!1
X-Originating-IP: [128.221.224.79]
X-SpamReason: No, hits=1.8 required=7.0 tests=BODY_RANDOM_LONG,HOT_NASTY,
	HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9403 invoked from network); 22 Dec 2014 07:05:07 -0000
Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Dec 2014 07:05:07 -0000
Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com
	[10.106.48.155])
	by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBM755dm018080
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Dec 2014 02:05:05 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sBM755dm018080
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013;
	t=1419231905; bh=IttnuKwFQcd696F6gpgmp51ut1Y=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	Content-Type:MIME-Version;
	b=lqWtJKjF1Eddvw2tqhGnhiWC6WRyXnkl2V0YYrEtX0OgqOEwLNnv7IMv8eu52Ycw8
	pe9MTnq0ccHAm/ciC9daU40O9JOvs4jjqtixhPccaxReX9y10ksQqBTx5KeLedNg36
	ldG8tkvEJLgzQvydaLZHZDpWA6FDBirm0eVWgK7k=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sBM755dm018080
Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com
	[10.253.24.21]) by maildlpprd51.lss.emc.com (RSA Interceptor);
	Mon, 22 Dec 2014 02:04:49 -0500
Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104])
	by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBM74tM3013852
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 22 Dec 2014 02:04:55 -0500
Received: from MXHUB202.corp.emc.com (10.253.68.28) by mxhub02.corp.emc.com
	(10.254.141.104) with Microsoft SMTP Server (TLS) id 8.3.327.1;
	Mon, 22 Dec 2014 02:04:54 -0500
Received: from MX101CL01.corp.emc.com ([169.254.1.90]) by
	MXHUB202.corp.emc.com ([10.253.68.28]) with mapi id 14.03.0195.001;
	Mon, 22 Dec 2014 02:04:54 -0500
From: "Singhal, Upanshu" <upanshu.singhal@emc.com>
To: Don Slutz <dslutz@verizon.com>
Thread-Topic: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
Thread-Index: AdAbg+gVpGg69F+/TKC4f+QiMDYySwAgTHmAAGwE/hA=
Date: Mon, 22 Dec 2014 07:04:53 +0000
Message-ID: <6A5D14D0DFEABC43BE832A0E492963F14EBB922A@MX101CL01.corp.emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
	<5494A6AF.1030802@terremark.com>
In-Reply-To: <5494A6AF.1030802@terremark.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.30.79.65]
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com
X-RSA-Classifications: DLP to NYP, public
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1968152956517758201=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1968152956517758201==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_6A5D14D0DFEABC43BE832A0E492963F14EBB922AMX101CL01corpem_"

--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB922AMX101CL01corpem_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Don,

xen_emul_unplug=3Dunnecessary  does the trick, I am able to see the vmxnet3=
 driver using lspci and ethtool -I eth0. Thanks a lot for your help, much a=
ppreciated.

Performance between vmxnet3 running on XEN is about 1/3 of vmxnet3 running =
on ESXi. Similar performance number I get between vmxnet3 on ESXi and vif o=
n XEN. Do you know what could be the reason for this?

Thanks,
-Upanshu

From: Don Slutz [mailto:dslutz@verizon.com]
Sent: Saturday, December 20, 2014 3:59 AM
To: Singhal, Upanshu
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

xen_emul_unplug=3Dunnecessary (kernel arg) may help you here.

Also udev likes to rename your devices.

Here is a lspci from a guest:


[root@C63-min-tools ~]# 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 I=
I]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 0=
1)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)
00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)

And to help:

[root@C63-min-tools ~]# ls -l /sys/class/net/*/device
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> ../../=
../vif-0
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> ../../=
../vif-1
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> ../../=
../vif-2
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> ../../=
../vif-3
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> ../../=
../vif-4
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> ../../=
../vif-5
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> ../../=
../vif-6
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> ../../=
../vif-7
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> ../../=
../vif-8
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> ../../=
../vif-9
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device -> ..=
/../../0000:00:04.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device -> ..=
/../../0000:00:05.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device -> ..=
/../../0000:00:06.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device -> ..=
/../../0000:00:07.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device -> ..=
/../../0000:00:08.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device -> ..=
/../../0000:00:09.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device -> ..=
/../../0000:00:0a.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device -> ..=
/../../0000:00:0b.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device -> ..=
/../../0000:00:0c.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device -> ..=
/../../0000:00:0d.0


   -Don Slutz

On 12/19/14 07:04, Singhal, Upanshu wrote:
Hello,

In one of my experiment, I am building a Linux VM with Network interface mo=
del as "vmxnet3". I am able to create the VM successfully, but I see that t=
he driver loaded is "vif" and not "vmxnet3". I am using the following optio=
n for the network interface: vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:=
22, bridge=3Dxenbr0, model=3Dvmxnet3' ]

I tried with model as e1000 and it works fine. Lspci command also does not =
show vmxnet3. Though, qemu device help shows that "vmxnet3" is supported on=
 XEN 4.4.1 version I am using.

I tried searching on internet about the right configuration for vmxnet3 wit=
h XEN, but not able to find right information. Can someone please help me o=
n how to create a VM with vmxnet3?

This experiment I am doing to compare the difference between vmxnet3 bandwi=
dth on VMWARE ESXi vs. XEN Server. My sample VM configuration file is:

# This configures an HVM rather than PV guest
builder =3D "hvm"

# Guest name
name =3D "rhel-vmxnet3-xen-2.hvm"

# 128-bit UUID for the domain as a hexadecimal number.
# Use "uuidgen" to generate one if required.
# The default behavior is to generate a new UUID each time the guest is sta=
rted.
#uuid =3D "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

# Enable Microsoft Hyper-V compatibile paravirtualisation /
# enlightenment interfaces. Turning this on can improve Windows guest
# performance and is therefore recommended
#viridian =3D 1

# Initial memory allocation (MB)
memory =3D 8192

# Maximum memory (MB)
# If this is greater than `memory' then the slack will start ballooned
# (this assumes guest kernel support for ballooning)
#maxmem =3D 512

# Number of VCPUS
vcpus =3D 8

# Network devices
# A list of 'vifspec' entries as described in
# docs/misc/xl-network-configuration.markdown
vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dxenbr1, model=3D=
vmxnet3' ]

# Disk Devices
# A list of `diskspec' entries as described in
# docs/misc/xl-disk-configuration.txt
disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', 'file:/root=
/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r<file:///\\root\rhel-server-6.4-=
x86_64-dvd.iso,hdc:cdrom,r>' ]
boot=3D'cd'

# Guest VGA console configuration, either SDL or VNC
# sdl =3D 1
vnc =3D 2

Thanks,
-Upanshu


Upanshu Singhal
EMC Data Storage Systems, Bangalore, India.
Phone: 91-80-67375604





_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xen.org<mailto:Xen-devel@lists.xen.org>

http://lists.xen.org/xen-devel


--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB922AMX101CL01corpem_
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:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.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 bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hello Don,<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal">xen_emul_unplug=3Dunnecessary<span style=3D"color:#1=
F497D"> &nbsp;does the trick, I am able to see the vmxnet3 driver using lsp=
ci and ethtool &#8211;I eth0. Thanks a lot for your help, much appreciated.=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Performance between vm=
xnet3 running on XEN is about 1/3 of vmxnet3 running on ESXi. Similar perfo=
rmance number I get between vmxnet3 on ESXi and vif on XEN. Do you know wha=
t could be the reason for this?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">-Upanshu<o:p></o:p></s=
pan></p>
</div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext"> Don Slutz [mailto:dslutz@verizon.com]
<br>
<b>Sent:</b> Saturday, December 20, 2014 3:59 AM<br>
<b>To:</b> Singhal, Upanshu<br>
<b>Cc:</b> xen-devel@lists.xen.org<br>
<b>Subject:</b> Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1<o:p></=
o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">xen_emul_unplug=3Dunn=
ecessary (kernel arg) may help you here.<br>
<br>
Also udev likes to rename your devices.<br>
<br>
Here is a lspci from a guest:<br>
<br>
<br>
[root@C63-min-tools ~]# lspci<br>
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02=
)<br>
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]<=
br>
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton I=
I]<br>
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)<br>
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 0=
1)<br>
00:03.0 VGA compatible controller: Cirrus Logic GD 5446<br>
00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)<br>
00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)<br>
<br>
And to help:<br>
<br>
[root@C63-min-tools ~]# ls -l /sys/class/net/*/device<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -&gt; ../=
../../vif-0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -&gt; ../=
../../vif-1<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -&gt; ../=
../../vif-2<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -&gt; ../=
../../vif-3<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -&gt; ../=
../../vif-4<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -&gt; ../=
../../vif-5<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -&gt; ../=
../../vif-6<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -&gt; ../=
../../vif-7<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -&gt; ../=
../../vif-8<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -&gt; ../=
../../vif-9<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device -&gt;=
 ../../../0000:00:04.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device -&gt;=
 ../../../0000:00:05.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device -&gt;=
 ../../../0000:00:06.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device -&gt;=
 ../../../0000:00:07.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device -&gt;=
 ../../../0000:00:08.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device -&gt;=
 ../../../0000:00:09.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device -&gt;=
 ../../../0000:00:0a.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device -&gt;=
 ../../../0000:00:0b.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device -&gt;=
 ../../../0000:00:0c.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device -&gt;=
 ../../../0000:00:0d.0<br>
<br>
<br>
&nbsp;&nbsp; -Don Slutz<br>
<br>
<o:p></o:p></p>
<div>
<p class=3D"MsoNormal">On 12/19/14 07:04, Singhal, Upanshu wrote:<o:p></o:p=
></p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">Hello,<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">In one of my experiment, I am building a Linux VM wi=
th Network interface model as &#8220;vmxnet3&#8221;. I am able to create th=
e VM successfully, but I see that the driver loaded is &#8220;vif&#8221; an=
d not &#8220;vmxnet3&#8221;. I am using the following option for the networ=
k
 interface: <b>vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dx=
enbr0, model=3Dvmxnet3' ]</b><o:p></o:p></p>
<p class=3D"MsoNormal"><b>&nbsp;</b><o:p></o:p></p>
<p class=3D"MsoNormal">I tried with model as e1000 and it works fine. Lspci=
 command also does not show vmxnet3. Though, qemu device help shows that &#=
8220;vmxnet3&#8221; is supported on XEN 4.4.1 version I am using.
<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">I tried searching on internet about the right config=
uration for vmxnet3 with XEN, but not able to find right information. Can s=
omeone please help me on how to create a VM with vmxnet3?<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">This experiment I am doing to compare the difference=
 between vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM conf=
iguration file is:<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># This configures an HVM rather than PV guest<o:p></=
o:p></p>
<p class=3D"MsoNormal">builder =3D &quot;hvm&quot;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Guest name<o:p></o:p></p>
<p class=3D"MsoNormal"><b>name =3D &quot;rhel-vmxnet3-xen-2.hvm&quot;</b><o=
:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># 128-bit UUID for the domain as a hexadecimal numbe=
r.<o:p></o:p></p>
<p class=3D"MsoNormal"># Use &quot;uuidgen&quot; to generate one if require=
d.<o:p></o:p></p>
<p class=3D"MsoNormal"># The default behavior is to generate a new UUID eac=
h time the guest is started.<o:p></o:p></p>
<p class=3D"MsoNormal">#uuid =3D &quot;XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=
&quot;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Enable Microsoft Hyper-V compatibile paravirtualis=
ation /<o:p></o:p></p>
<p class=3D"MsoNormal"># enlightenment interfaces. Turning this on can impr=
ove Windows guest<o:p></o:p></p>
<p class=3D"MsoNormal"># performance and is therefore recommended<o:p></o:p=
></p>
<p class=3D"MsoNormal">#viridian =3D 1<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Initial memory allocation (MB)<o:p></o:p></p>
<p class=3D"MsoNormal"><b>memory =3D 8192</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Maximum memory (MB)<o:p></o:p></p>
<p class=3D"MsoNormal"># If this is greater than `memory' then the slack wi=
ll start ballooned<o:p></o:p></p>
<p class=3D"MsoNormal"># (this assumes guest kernel support for ballooning)=
<o:p></o:p></p>
<p class=3D"MsoNormal">#maxmem =3D 512<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Number of VCPUS<o:p></o:p></p>
<p class=3D"MsoNormal"><b>vcpus =3D 8</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Network devices<o:p></o:p></p>
<p class=3D"MsoNormal"># A list of 'vifspec' entries as described in<o:p></=
o:p></p>
<p class=3D"MsoNormal"># docs/misc/xl-network-configuration.markdown<o:p></=
o:p></p>
<p class=3D"MsoNormal">vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, br=
idge=3Dxenbr1, model=3Dvmxnet3' ]<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Disk Devices<o:p></o:p></p>
<p class=3D"MsoNormal"># A list of `diskspec' entries as described in<o:p><=
/o:p></p>
<p class=3D"MsoNormal"># docs/misc/xl-disk-configuration.txt<o:p></o:p></p>
<p class=3D"MsoNormal"><b>disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img=
,raw,xvda,rw', '<a href=3D"file:///\\root\rhel-server-6.4-x86_64-dvd.iso,hd=
c:cdrom,r">file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r</a>' ]</b>=
<o:p></o:p></p>
<p class=3D"MsoNormal"><b>boot=3D'cd'</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Guest VGA console configuration, either SDL or VNC=
<o:p></o:p></p>
<p class=3D"MsoNormal"># sdl =3D 1<o:p></o:p></p>
<p class=3D"MsoNormal"><b>vnc =3D 2</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal">-Upanshu<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">Upanshu Singhal<o:p></o:p></p>
<p class=3D"MsoNormal">EMC Data Storage Systems, Bangalore, India.<o:p></o:=
p></p>
<p class=3D"MsoNormal">Phone: 91-80-67375604<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><br>
<br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Xen-devel mailing list<o:p></o:p></pre>
<pre><a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<o:p></o:p></pre>
<pre><a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-de=
vel</a><o:p></o:p></pre>
</blockquote>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB922AMX101CL01corpem_--


--===============1968152956517758201==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1968152956517758201==--


From xen-devel-bounces@lists.xen.org Mon Dec 22 07:34:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 07:34:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2xVb-0006fs-A2; Mon, 22 Dec 2014 07:34:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yanghy@cn.fujitsu.com>) id 1Y2xVa-0006fn-Dc
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 07:34:26 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	37/F2-28296-189C7945; Mon, 22 Dec 2014 07:34:25 +0000
X-Env-Sender: yanghy@cn.fujitsu.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419233661!15022672!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17109 invoked from network); 22 Dec 2014 07:34:23 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-2.tower-31.messagelabs.com with SMTP;
	22 Dec 2014 07:34:23 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="45600285"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 22 Dec 2014 15:30:59 +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 sBM7XrZ2025351;
	Mon, 22 Dec 2014 15:33:53 +0800
Received: from localhost (10.167.226.223) by G08CNEXCHPEKD01.g08.fujitsu.local
	(10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.181.6;
	Mon, 22 Dec 2014 15:34:23 +0800
From: Yang Hongyang <yanghy@cn.fujitsu.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 22 Dec 2014 15:33:24 +0800
Message-ID: <1419233604-859-1-git-send-email-yanghy@cn.fujitsu.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] xl/libxl: fix migrate/Remus regression (core
	dumped)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 excuting xl migrate/Remus, the following error occurd:
[root@master xen]# xl migrate 5 slaver
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x1/0x0/1225)
Loading new save file <incoming migration stream> (new xl fmt info 0x1/0x0/1225)
 Savefile contains xl domain config in JSON format
Parsing config from <saved>
Segmentation fault (core dumped)

This is because CTX->xce is used without been initialized.
The bug was introduced by commit 2ffeb5d7f5d8
    libxl: events: Deregister evtchn fd when not needed
which remove the initialization of xce from libxl__ctx_alloc.

This patch initialze the CTX->xce before use it.

Signed-off-by: Yang Hongyang <yanghy@cn.fujitsu.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/libxl_dom.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..8910b79 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1824,6 +1824,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     port = xs_suspend_evtchn_port(dss->domid);
 
     if (port >= 0) {
+        libxl__ctx_evtchn_init(gc);
         dss->guest_evtchn.port =
             xc_suspend_evtchn_init_exclusive(CTX->xch, CTX->xce,
                                   dss->domid, port, &dss->guest_evtchn_lockfd);
-- 
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 Dec 22 07:34:52 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 07:34:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2xVb-0006fs-A2; Mon, 22 Dec 2014 07:34:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yanghy@cn.fujitsu.com>) id 1Y2xVa-0006fn-Dc
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 07:34:26 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	37/F2-28296-189C7945; Mon, 22 Dec 2014 07:34:25 +0000
X-Env-Sender: yanghy@cn.fujitsu.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419233661!15022672!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17109 invoked from network); 22 Dec 2014 07:34:23 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-2.tower-31.messagelabs.com with SMTP;
	22 Dec 2014 07:34:23 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="45600285"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 22 Dec 2014 15:30:59 +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 sBM7XrZ2025351;
	Mon, 22 Dec 2014 15:33:53 +0800
Received: from localhost (10.167.226.223) by G08CNEXCHPEKD01.g08.fujitsu.local
	(10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.181.6;
	Mon, 22 Dec 2014 15:34:23 +0800
From: Yang Hongyang <yanghy@cn.fujitsu.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 22 Dec 2014 15:33:24 +0800
Message-ID: <1419233604-859-1-git-send-email-yanghy@cn.fujitsu.com>
X-Mailer: git-send-email 1.9.1
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Yang Hongyang <yanghy@cn.fujitsu.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] xl/libxl: fix migrate/Remus regression (core
	dumped)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 excuting xl migrate/Remus, the following error occurd:
[root@master xen]# xl migrate 5 slaver
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x1/0x0/1225)
Loading new save file <incoming migration stream> (new xl fmt info 0x1/0x0/1225)
 Savefile contains xl domain config in JSON format
Parsing config from <saved>
Segmentation fault (core dumped)

This is because CTX->xce is used without been initialized.
The bug was introduced by commit 2ffeb5d7f5d8
    libxl: events: Deregister evtchn fd when not needed
which remove the initialization of xce from libxl__ctx_alloc.

This patch initialze the CTX->xce before use it.

Signed-off-by: Yang Hongyang <yanghy@cn.fujitsu.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/libxl_dom.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..8910b79 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1824,6 +1824,7 @@ void libxl__domain_suspend(libxl__egc *egc, libxl__domain_suspend_state *dss)
     port = xs_suspend_evtchn_port(dss->domid);
 
     if (port >= 0) {
+        libxl__ctx_evtchn_init(gc);
         dss->guest_evtchn.port =
             xc_suspend_evtchn_init_exclusive(CTX->xch, CTX->xce,
                                   dss->domid, port, &dss->guest_evtchn_lockfd);
-- 
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 Dec 22 08:07:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 08: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 1Y2y0u-0007wE-JQ; Mon, 22 Dec 2014 08:06:48 +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 1Y2y0t-0007w9-B7
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 08:06:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	50/95-25276-611D7945; Mon, 22 Dec 2014 08:06:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419235604!9120215!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10691 invoked from network); 22 Dec 2014 08:06:44 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Dec 2014 08:06:44 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1419235604; l=1563;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=5fP4xMGGqhuyV0g30sRZKykiiTg=;
	b=ePvoE1O2WbRf8uOuzwIGV/G3uDqx/YVsN81b3wRtA/zXjIxF8uUqpc6DRDytilwzdIR
	1Us+RTpNE4Df8oZEszSgLNBHdOcOE6TSoIT69ZFAegVu7EyN6XQpmEUQfi0DYyad9hovY
	vYELtHxovz8AsOcOAnU64eTdQ1QGceC7BdM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id Q05825qBM86eoYX
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 22 Dec 2014 09:06:40 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 38BE250161; Mon, 22 Dec 2014 09:06:40 +0100 (CET)
Date: Mon, 22 Dec 2014 09:06:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141222080639.GA6139@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
	<20141219191032.GB9213@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141219191032.GB9213@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: m.a.young@durham.ac.uk, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes 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 Fri, Dec 19, Konrad Rzeszutek Wilk wrote:

> On Fri, Dec 19, 2014 at 12:25:26PM +0100, Olaf Hering wrote:
> > This is a resend of these two series:
> > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00858.html
> > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
> > 
> > New in v3 is a wrapper to run xenstored. See its patch description
> > for details.
> > 
> > Patch 2-6 should be applied for 4.5.0.
> > 
> > The first and the last one still has issues with xenstored and
> > SELinux. See below.  Up to now no solution is known to me.
> > 
> > 
> > The first patch fixes Arch Linux and does not break anything.  As such
> > it should be safe to be applied for 4.5.0.  SELinux users (who build
> > from source) should put their special mount options into fstab. Distro
> 
> Could you elaborate what that is? As in what is that 'special mount options'?

The context= mount option, about which we argue since a few weeks?
See patch #1.

> > packages will most likely include a proper .service file.
> > 
> > 
> > The last patch addresses the XENSTORED_TRACE issue. But SELinux will
> > most likely still not work.
> > 
> > Possible ways to handle launching xenstored and SELinux:
> > 
> > - do nothing
> >   pro: - no Xen source changes required
> >   con: - possible unhappy users who build from source and still have
> >          SELinux enabled
> 
> At this stage I prefer this and just have in the release notes the
> work-around documented.

Which workaround is that? No SELinux on Fedora?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 08:07:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 08: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 1Y2y0u-0007wE-JQ; Mon, 22 Dec 2014 08:06:48 +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 1Y2y0t-0007w9-B7
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 08:06:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	50/95-25276-611D7945; Mon, 22 Dec 2014 08:06:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419235604!9120215!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10691 invoked from network); 22 Dec 2014 08:06:44 -0000
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de)
	(81.169.146.221)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Dec 2014 08:06:44 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1419235604; l=1563;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date;
	bh=5fP4xMGGqhuyV0g30sRZKykiiTg=;
	b=ePvoE1O2WbRf8uOuzwIGV/G3uDqx/YVsN81b3wRtA/zXjIxF8uUqpc6DRDytilwzdIR
	1Us+RTpNE4Df8oZEszSgLNBHdOcOE6TSoIT69ZFAegVu7EyN6XQpmEUQfi0DYyad9hovY
	vYELtHxovz8AsOcOAnU64eTdQ1QGceC7BdM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssBIlSFJGl/Fu9NxVucSV5oeoyECM2XmlrMeaL3A==
X-RZG-CLASS-ID: mo00
Received: from probook.fritz.box ([2001:a60:1007:bc01:1ec1:deff:feb9:bb48])
	by smtp.strato.de (RZmta 36.3 AUTH) with ESMTPSA id Q05825qBM86eoYX
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate);
	Mon, 22 Dec 2014 09:06:40 +0100 (CET)
Received: by probook.fritz.box (Postfix, from userid 1000)
	id 38BE250161; Mon, 22 Dec 2014 09:06:40 +0100 (CET)
Date: Mon, 22 Dec 2014 09:06:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20141222080639.GA6139@aepfle.de>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
	<20141219191032.GB9213@laptop.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141219191032.GB9213@laptop.dumpdata.com>
User-Agent: Mutt/1.5.22.rev6346 (2013-10-29)
Cc: m.a.young@durham.ac.uk, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes 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 Fri, Dec 19, Konrad Rzeszutek Wilk wrote:

> On Fri, Dec 19, 2014 at 12:25:26PM +0100, Olaf Hering wrote:
> > This is a resend of these two series:
> > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00858.html
> > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
> > 
> > New in v3 is a wrapper to run xenstored. See its patch description
> > for details.
> > 
> > Patch 2-6 should be applied for 4.5.0.
> > 
> > The first and the last one still has issues with xenstored and
> > SELinux. See below.  Up to now no solution is known to me.
> > 
> > 
> > The first patch fixes Arch Linux and does not break anything.  As such
> > it should be safe to be applied for 4.5.0.  SELinux users (who build
> > from source) should put their special mount options into fstab. Distro
> 
> Could you elaborate what that is? As in what is that 'special mount options'?

The context= mount option, about which we argue since a few weeks?
See patch #1.

> > packages will most likely include a proper .service file.
> > 
> > 
> > The last patch addresses the XENSTORED_TRACE issue. But SELinux will
> > most likely still not work.
> > 
> > Possible ways to handle launching xenstored and SELinux:
> > 
> > - do nothing
> >   pro: - no Xen source changes required
> >   con: - possible unhappy users who build from source and still have
> >          SELinux enabled
> 
> At this stage I prefer this and just have in the release notes the
> work-around documented.

Which workaround is that? No SELinux on Fedora?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 08:08:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 08: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 1Y2y2Q-00083K-2G; Mon, 22 Dec 2014 08:08:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Chuck.Tuffli@Emulex.Com>) id 1Y2n8p-00081I-Nz
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 20:30:15 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	A4/9F-24124-7DD27945; Sun, 21 Dec 2014 20:30:15 +0000
X-Env-Sender: Chuck.Tuffli@Emulex.Com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1419193813!11694840!1
X-Originating-IP: [138.239.224.100]
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 9041 invoked from network); 21 Dec 2014 20:30:14 -0000
Received: from cmexedge2.emulex.com (HELO CMEXEDGE2.ext.emulex.com)
	(138.239.224.100)
	by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Dec 2014 20:30:14 -0000
Received: from CMEXHTCAS1.ad.emulex.com (138.239.115.217) by
	CMEXEDGE2.ext.emulex.com (138.239.224.100) with Microsoft SMTP Server
	(TLS) id 14.3.174.1; Sun, 21 Dec 2014 12:29:41 -0800
Received: from rvctuffli.lab.rv.emulex.com (10.192.16.7) by smtp.emulex.com
	(138.239.115.207) with Microsoft SMTP Server id 14.3.174.1;
	Sun, 21 Dec 2014 12:29:40 -0800
From: Chuck Tuffli <chuck.tuffli@emulex.com>
To: <xen-devel@lists.xensource.com>
Date: Sun, 21 Dec 2014 12:30:58 -0800
X-Mailer: git-send-email 2.1.2
MIME-Version: 1.0
Message-ID: <d7204be5-f199-456c-9587-c87e1d8d4dd5@CMEXHTCAS1.ad.emulex.com>
X-Mailman-Approved-At: Mon, 22 Dec 2014 08:08:20 +0000
Cc: linux-arm-kernel@lists.infradead.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] arm64: Relax licensing of arm64 Xen DMA
	operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

With Xen configured into the arm64 kernel, any driver allocating
DMA'able memory for PCI operations, must be GPL compatible, regardless
of its interaction with Xen. This patch relaxes the GPL requirement of
xen_dma_ops and its dependencies to allow open source drivers to be
compiled for the arm64 architecture.

Signed-off-by: Chuck Tuffli <chuck.tuffli@emulex.com>
---
 arch/arm/xen/enlighten.c | 4 ++--
 arch/arm/xen/mm.c        | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c7ca936..263a204 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -29,10 +29,10 @@
 
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
-EXPORT_SYMBOL_GPL(xen_start_info);
+EXPORT_SYMBOL(xen_start_info);
 
 enum xen_domain_type xen_domain_type = XEN_NATIVE;
-EXPORT_SYMBOL_GPL(xen_domain_type);
+EXPORT_SYMBOL(xen_domain_type);
 
 struct shared_info xen_dummy_shared_info;
 struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 351b24a..793551d 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -149,7 +149,7 @@ void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order)
 EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
 
 struct dma_map_ops *xen_dma_ops;
-EXPORT_SYMBOL_GPL(xen_dma_ops);
+EXPORT_SYMBOL(xen_dma_ops);
 
 static struct dma_map_ops xen_swiotlb_dma_ops = {
 	.mapping_error = xen_swiotlb_dma_mapping_error,
-- 
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 Dec 22 08:08:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 08: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 1Y2y2Q-00083K-2G; Mon, 22 Dec 2014 08:08:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Chuck.Tuffli@Emulex.Com>) id 1Y2n8p-00081I-Nz
	for xen-devel@lists.xensource.com; Sun, 21 Dec 2014 20:30:15 +0000
Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id
	A4/9F-24124-7DD27945; Sun, 21 Dec 2014 20:30:15 +0000
X-Env-Sender: Chuck.Tuffli@Emulex.Com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1419193813!11694840!1
X-Originating-IP: [138.239.224.100]
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 9041 invoked from network); 21 Dec 2014 20:30:14 -0000
Received: from cmexedge2.emulex.com (HELO CMEXEDGE2.ext.emulex.com)
	(138.239.224.100)
	by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Dec 2014 20:30:14 -0000
Received: from CMEXHTCAS1.ad.emulex.com (138.239.115.217) by
	CMEXEDGE2.ext.emulex.com (138.239.224.100) with Microsoft SMTP Server
	(TLS) id 14.3.174.1; Sun, 21 Dec 2014 12:29:41 -0800
Received: from rvctuffli.lab.rv.emulex.com (10.192.16.7) by smtp.emulex.com
	(138.239.115.207) with Microsoft SMTP Server id 14.3.174.1;
	Sun, 21 Dec 2014 12:29:40 -0800
From: Chuck Tuffli <chuck.tuffli@emulex.com>
To: <xen-devel@lists.xensource.com>
Date: Sun, 21 Dec 2014 12:30:58 -0800
X-Mailer: git-send-email 2.1.2
MIME-Version: 1.0
Message-ID: <d7204be5-f199-456c-9587-c87e1d8d4dd5@CMEXHTCAS1.ad.emulex.com>
X-Mailman-Approved-At: Mon, 22 Dec 2014 08:08:20 +0000
Cc: linux-arm-kernel@lists.infradead.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] arm64: Relax licensing of arm64 Xen DMA
	operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

With Xen configured into the arm64 kernel, any driver allocating
DMA'able memory for PCI operations, must be GPL compatible, regardless
of its interaction with Xen. This patch relaxes the GPL requirement of
xen_dma_ops and its dependencies to allow open source drivers to be
compiled for the arm64 architecture.

Signed-off-by: Chuck Tuffli <chuck.tuffli@emulex.com>
---
 arch/arm/xen/enlighten.c | 4 ++--
 arch/arm/xen/mm.c        | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c7ca936..263a204 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -29,10 +29,10 @@
 
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
-EXPORT_SYMBOL_GPL(xen_start_info);
+EXPORT_SYMBOL(xen_start_info);
 
 enum xen_domain_type xen_domain_type = XEN_NATIVE;
-EXPORT_SYMBOL_GPL(xen_domain_type);
+EXPORT_SYMBOL(xen_domain_type);
 
 struct shared_info xen_dummy_shared_info;
 struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 351b24a..793551d 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -149,7 +149,7 @@ void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order)
 EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
 
 struct dma_map_ops *xen_dma_ops;
-EXPORT_SYMBOL_GPL(xen_dma_ops);
+EXPORT_SYMBOL(xen_dma_ops);
 
 static struct dma_map_ops xen_swiotlb_dma_ops = {
 	.mapping_error = xen_swiotlb_dma_mapping_error,
-- 
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 Dec 22 08:19:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 08:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2yCd-0008UW-Cp; Mon, 22 Dec 2014 08:18:55 +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 1Y2yCc-0008UR-2H
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 08:18:54 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	29/BE-17735-DE3D7945; Mon, 22 Dec 2014 08:18:53 +0000
X-Env-Sender: jasowang@redhat.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1419236328!14965213!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5887 invoked from network); 22 Dec 2014 08:18:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Dec 2014 08:18:50 -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 sBM8IcTn025655
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 22 Dec 2014 03:18:39 -0500
Received: from [10.66.71.84] (dhcp-66-71-84.eng.nay.redhat.com [10.66.71.84]
	(may be forged))
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBM8IWtI028051; Mon, 22 Dec 2014 03:18:33 -0500
Message-ID: <5497D3D9.2070509@redhat.com>
Date: Mon, 22 Dec 2014 16:18:33 +0800
From: Jason Wang <jasowang@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Herbert Xu <herbert@gondor.apana.org.au>,
	David Vrabel <david.vrabel@citrix.com>
References: <20141220002327.GA31975@gondor.apana.org.au>
In-Reply-To: <20141220002327.GA31975@gondor.apana.org.au>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: netdev@vger.kernel.org, edumazet@google.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, "David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] virtio_net: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/20/2014 08:23 AM, Herbert Xu wrote:
> David Vrabel <david.vrabel@citrix.com> wrote:
>> After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
>> masking in NAPI) the napi instance is removed from the per-cpu list
>> prior to calling the n->poll(), and is only requeued if all of the
>> budget was used.  This inadvertently broke netfront because netfront
>> does not use NAPI correctly.
> A similar bug exists in virtio_net.
>
> -- >8 --
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) breaks virtio_net in an insidious way.
>
> It is now required that if the entire budget is consumed when poll
> returns, the napi poll_list must remain empty.  However, like some
> other drivers virtio_net tries to do a last-ditch check and if
> there is more work it will call napi_schedule and then immediately
> process some of this new work.  Should the entire budget be consumed
> while processing such new work then we will violate the new caller
> contract.
>
> This patch fixes this by not touching any work when we reschedule
> in virtio_net.
>
> The worst part of this bug is that the list corruption causes other
> napi users to be moved off-list.  In my case I was chasing a stall
> in IPsec (IPsec uses netif_rx) and I only belatedly realised that it
> was virtio_net which caused the stall even though the virtio_net
> poll was still functioning perfectly after IPsec stalled.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index b8bd719..5ca9771 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -760,7 +760,6 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
>  		container_of(napi, struct receive_queue, napi);
>  	unsigned int r, received = 0;
>  
> -again:
>  	received += virtnet_receive(rq, budget - received);
>  
>  	/* Out of packets? */
> @@ -771,7 +770,6 @@ again:
>  		    napi_schedule_prep(napi)) {
>  			virtqueue_disable_cb(rq->vq);
>  			__napi_schedule(napi);
> -			goto again;
>  		}
>  	}
>
> Cheers,

Acked-by: Jason Wang <jasowang@redhat.com>

btw, looks like at least caif_virtio has the same issue.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 08:19:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 08:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2yCd-0008UW-Cp; Mon, 22 Dec 2014 08:18:55 +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 1Y2yCc-0008UR-2H
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 08:18:54 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	29/BE-17735-DE3D7945; Mon, 22 Dec 2014 08:18:53 +0000
X-Env-Sender: jasowang@redhat.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1419236328!14965213!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5887 invoked from network); 22 Dec 2014 08:18:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Dec 2014 08:18:50 -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 sBM8IcTn025655
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 22 Dec 2014 03:18:39 -0500
Received: from [10.66.71.84] (dhcp-66-71-84.eng.nay.redhat.com [10.66.71.84]
	(may be forged))
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBM8IWtI028051; Mon, 22 Dec 2014 03:18:33 -0500
Message-ID: <5497D3D9.2070509@redhat.com>
Date: Mon, 22 Dec 2014 16:18:33 +0800
From: Jason Wang <jasowang@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Herbert Xu <herbert@gondor.apana.org.au>,
	David Vrabel <david.vrabel@citrix.com>
References: <20141220002327.GA31975@gondor.apana.org.au>
In-Reply-To: <20141220002327.GA31975@gondor.apana.org.au>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: netdev@vger.kernel.org, edumazet@google.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, "David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] virtio_net: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/20/2014 08:23 AM, Herbert Xu wrote:
> David Vrabel <david.vrabel@citrix.com> wrote:
>> After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
>> masking in NAPI) the napi instance is removed from the per-cpu list
>> prior to calling the n->poll(), and is only requeued if all of the
>> budget was used.  This inadvertently broke netfront because netfront
>> does not use NAPI correctly.
> A similar bug exists in virtio_net.
>
> -- >8 --
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) breaks virtio_net in an insidious way.
>
> It is now required that if the entire budget is consumed when poll
> returns, the napi poll_list must remain empty.  However, like some
> other drivers virtio_net tries to do a last-ditch check and if
> there is more work it will call napi_schedule and then immediately
> process some of this new work.  Should the entire budget be consumed
> while processing such new work then we will violate the new caller
> contract.
>
> This patch fixes this by not touching any work when we reschedule
> in virtio_net.
>
> The worst part of this bug is that the list corruption causes other
> napi users to be moved off-list.  In my case I was chasing a stall
> in IPsec (IPsec uses netif_rx) and I only belatedly realised that it
> was virtio_net which caused the stall even though the virtio_net
> poll was still functioning perfectly after IPsec stalled.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index b8bd719..5ca9771 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -760,7 +760,6 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
>  		container_of(napi, struct receive_queue, napi);
>  	unsigned int r, received = 0;
>  
> -again:
>  	received += virtnet_receive(rq, budget - received);
>  
>  	/* Out of packets? */
> @@ -771,7 +770,6 @@ again:
>  		    napi_schedule_prep(napi)) {
>  			virtqueue_disable_cb(rq->vq);
>  			__napi_schedule(napi);
> -			goto again;
>  		}
>  	}
>
> Cheers,

Acked-by: Jason Wang <jasowang@redhat.com>

btw, looks like at least caif_virtio has the same issue.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 08:52:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 08: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 1Y2yix-00016V-A3; Mon, 22 Dec 2014 08:52:19 +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 1Y2yiw-00016Q-BR
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 08:52:18 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	02/4D-05632-1CBD7945; Mon, 22 Dec 2014 08:52:17 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1419238335!14973541!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 19167 invoked from network); 22 Dec 2014 08:52:16 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Dec 2014 08:52:16 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 22 Dec 2014 01:52:14 -0700
Message-Id: <54984C360200006600087396@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 22 Dec 2014 01:52:06 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
	<1418915759.11882.91.camel@citrix.com>
	<54943E5F0200006600086A70@soto.provo.novell.com>
	<1418984856.20028.17.camel@citrix.com>
In-Reply-To: <1418984856.20028.17.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 12/19/2014 at 06:27 PM, in message <1418984856.20028.17.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Fri, 2014-12-19 at 00:03 -0700, Chun Yan Liu wrote: 
>  
> > '--name' meant to give a meaningful name (like: newinstall. Used as the 
> > memory snapshot name and disk snapshot name). 
>  
> Where is this name stored and when and where would it be presented to 
> the user?
e.g. For qcow2 internal disk snapshot, this name is stored within the disk.
When user wants to delete internal disk snapshot, it will be:
#qemu-img snapshot -d name disk

>  
> > That's good. Then we need to add some description to tell users about 
> > the auto-generated domain snapshot name, disk snapshot name, 
> > memory state file and external disk snapshot files, etc. 
>  
> We will need user docs and manpage updates, yes. 
>  
> > > > #e.g. to specify exernal disk snapshot, like this:  
> > > > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda',  
> > > >         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',]  
> > > >   
> > > > #e.g. to specify internal disk snapshot, like this:  
> > > > disks=[',,hda',',,hdb',]  
> > >   
> > > Ideally one or the other of these behaviours would be possible without  
> > > needing to be quite so explicit. 
> >  
> > OK, I'll delete one. 
>  
> I don't object to having this more capable syntax as an option, so the 
> user can override things if they wish, all I was suggesting is that the 
> default ought to be something useful so the user doesn't need to say 
> anything if they just want the toolstack to "do something sensible". 

I see. By default user doesn't need to specify 'disks' at all, then xl
will do internal disk snapshot to each domain disk.

>  
> Ian. 
>  
>  
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 08:52:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 08: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 1Y2yix-00016V-A3; Mon, 22 Dec 2014 08:52:19 +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 1Y2yiw-00016Q-BR
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 08:52:18 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	02/4D-05632-1CBD7945; Mon, 22 Dec 2014 08:52:17 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1419238335!14973541!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 19167 invoked from network); 22 Dec 2014 08:52:16 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Dec 2014 08:52:16 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 22 Dec 2014 01:52:14 -0700
Message-Id: <54984C360200006600087396@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 22 Dec 2014 01:52:06 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-4-git-send-email-cyliu@suse.com>
	<1418915759.11882.91.camel@citrix.com>
	<54943E5F0200006600086A70@soto.provo.novell.com>
	<1418984856.20028.17.camel@citrix.com>
In-Reply-To: <1418984856.20028.17.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



>>> On 12/19/2014 at 06:27 PM, in message <1418984856.20028.17.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Fri, 2014-12-19 at 00:03 -0700, Chun Yan Liu wrote: 
>  
> > '--name' meant to give a meaningful name (like: newinstall. Used as the 
> > memory snapshot name and disk snapshot name). 
>  
> Where is this name stored and when and where would it be presented to 
> the user?
e.g. For qcow2 internal disk snapshot, this name is stored within the disk.
When user wants to delete internal disk snapshot, it will be:
#qemu-img snapshot -d name disk

>  
> > That's good. Then we need to add some description to tell users about 
> > the auto-generated domain snapshot name, disk snapshot name, 
> > memory state file and external disk snapshot files, etc. 
>  
> We will need user docs and manpage updates, yes. 
>  
> > > > #e.g. to specify exernal disk snapshot, like this:  
> > > > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda',  
> > > >         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',]  
> > > >   
> > > > #e.g. to specify internal disk snapshot, like this:  
> > > > disks=[',,hda',',,hdb',]  
> > >   
> > > Ideally one or the other of these behaviours would be possible without  
> > > needing to be quite so explicit. 
> >  
> > OK, I'll delete one. 
>  
> I don't object to having this more capable syntax as an option, so the 
> user can override things if they wish, all I was suggesting is that the 
> default ought to be something useful so the user doesn't need to say 
> anything if they just want the toolstack to "do something sensible". 

I see. By default user doesn't need to specify 'disks' at all, then xl
will do internal disk snapshot to each domain disk.

>  
> Ian. 
>  
>  
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 09:36:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 09:36:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2zP1-0002Fx-Uj; Mon, 22 Dec 2014 09:35:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2zP0-0002Fk-7x
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 09:35:46 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	22/4C-02954-1F5E7945; Mon, 22 Dec 2014 09:35:45 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-10.tower-27.messagelabs.com!1419240941!16582442!1
X-Originating-IP: [209.40.204.226]
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 6650 invoked from network); 22 Dec 2014 09:35:44 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 22 Dec 2014 09:35:44 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2zOp-0006SN-7v; Mon, 22 Dec 2014 20:35:35 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2zOf-0004rd-Ut; Mon, 22 Dec 2014 20:35:26 +1100
Date: Mon, 22 Dec 2014 20:35:25 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Jason Wang <jasowang@redhat.com>
Message-ID: <20141222093525.GA18616@gondor.apana.org.au>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<5497D3D9.2070509@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5497D3D9.2070509@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netdev@vger.kernel.org, edumazet@google.com,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	"David S. Miller" <davem@davemloft.net>
Subject: [Xen-devel] caif: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 22, 2014 at 04:18:33PM +0800, Jason Wang wrote:
>
> btw, looks like at least caif_virtio has the same issue.

Good catch.

-- >8 --
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) breaks caif.

It is now required that if the entire budget is consumed when poll
returns, the napi poll_list must remain empty.  However, like some
other drivers caif tries to do a last-ditch check and if there is
more work it will call napi_schedule and then immediately process
some of this new work.  Should the entire budget be consumed while
processing such new work then we will violate the new caller
contract.

This patch fixes this by not touching any work when we reschedule
in caif.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/drivers/net/caif/caif_virtio.c b/drivers/net/caif/caif_virtio.c
index a5fefb9..b306210 100644
--- a/drivers/net/caif/caif_virtio.c
+++ b/drivers/net/caif/caif_virtio.c
@@ -257,7 +257,6 @@ static int cfv_rx_poll(struct napi_struct *napi, int quota)
 	struct vringh_kiov *riov = &cfv->ctx.riov;
 	unsigned int skb_len;
 
-again:
 	do {
 		skb = NULL;
 
@@ -322,7 +321,6 @@ exit:
 		    napi_schedule_prep(napi)) {
 			vringh_notify_disable_kern(cfv->vr_rx);
 			__napi_schedule(napi);
-			goto again;
 		}
 		break;

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 09:36:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 09:36:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2zP1-0002Fx-Uj; Mon, 22 Dec 2014 09:35:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herbert@gondor.apana.org.au>) id 1Y2zP0-0002Fk-7x
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 09:35:46 +0000
Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id
	22/4C-02954-1F5E7945; Mon, 22 Dec 2014 09:35:45 +0000
X-Env-Sender: herbert@gondor.apana.org.au
X-Msg-Ref: server-10.tower-27.messagelabs.com!1419240941!16582442!1
X-Originating-IP: [209.40.204.226]
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 6650 invoked from network); 22 Dec 2014 09:35:44 -0000
Received: from helcar.apana.org.au (HELO helcar.apana.org.au) (209.40.204.226)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES128-SHA
	encrypted SMTP; 22 Dec 2014 09:35:44 -0000
Received: from gondolin.me.apana.org.au ([192.168.0.6])
	by fornost.hengli.com.au with esmtp (Exim 4.80 #3 (Debian))
	id 1Y2zOp-0006SN-7v; Mon, 22 Dec 2014 20:35:35 +1100
Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.80)
	(envelope-from <herbert@gondor.apana.org.au>)
	id 1Y2zOf-0004rd-Ut; Mon, 22 Dec 2014 20:35:26 +1100
Date: Mon, 22 Dec 2014 20:35:25 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Jason Wang <jasowang@redhat.com>
Message-ID: <20141222093525.GA18616@gondor.apana.org.au>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<5497D3D9.2070509@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5497D3D9.2070509@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netdev@vger.kernel.org, edumazet@google.com,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	"David S. Miller" <davem@davemloft.net>
Subject: [Xen-devel] caif: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 22, 2014 at 04:18:33PM +0800, Jason Wang wrote:
>
> btw, looks like at least caif_virtio has the same issue.

Good catch.

-- >8 --
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) breaks caif.

It is now required that if the entire budget is consumed when poll
returns, the napi poll_list must remain empty.  However, like some
other drivers caif tries to do a last-ditch check and if there is
more work it will call napi_schedule and then immediately process
some of this new work.  Should the entire budget be consumed while
processing such new work then we will violate the new caller
contract.

This patch fixes this by not touching any work when we reschedule
in caif.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/drivers/net/caif/caif_virtio.c b/drivers/net/caif/caif_virtio.c
index a5fefb9..b306210 100644
--- a/drivers/net/caif/caif_virtio.c
+++ b/drivers/net/caif/caif_virtio.c
@@ -257,7 +257,6 @@ static int cfv_rx_poll(struct napi_struct *napi, int quota)
 	struct vringh_kiov *riov = &cfv->ctx.riov;
 	unsigned int skb_len;
 
-again:
 	do {
 		skb = NULL;
 
@@ -322,7 +321,6 @@ exit:
 		    napi_schedule_prep(napi)) {
 			vringh_notify_disable_kern(cfv->vr_rx);
 			__napi_schedule(napi);
-			goto again;
 		}
 		break;

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 09:36:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 09:36:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2zPl-0002Jz-BT; Mon, 22 Dec 2014 09:36:33 +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 1Y2zPj-0002Jo-BN
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 09:36:31 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	D9/44-20609-E16E7945; Mon, 22 Dec 2014 09:36:30 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419240987!16590617!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 25541 invoked from network); 22 Dec 2014 09:36:29 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Dec 2014 09:36:29 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 22 Dec 2014 02:36:27 -0700
Message-Id: <549856940200006600087406@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 22 Dec 2014 02:36:20 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
	<1418916436.11882.101.camel@citrix.com>
	<54943D220200006600086A64@soto.provo.novell.com>
	<1418985490.20028.27.camel@citrix.com>
In-Reply-To: <1418985490.20028.27.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kwolf@redhat.com, wei.liu2@citrix.com, ian.jackson@eu.citrix.com,
	qemu-devel@nongnu.org, xen-devel@lists.xen.org,
	Jim Fehlig <JFEHLIG@suse.com>, stefanha@redhat.com
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/19/2014 at 06:38 PM, in message <1418985490.20028.27.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Thu, 2014-12-18 at 23:58 -0700, Chun Yan Liu wrote: 
> >  
> > >>> On 12/18/2014 at 11:27 PM, in message  
> <1418916436.11882.101.camel@citrix.com>, 
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:  
> > > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:  
> > > > Changes to V8:  
> > > >   * remove libxl_domain_snapshot_create/delete/revert API  
> > > >   * export disk snapshot functionality for both xl and libvirt usage  
> > > >   
> > > >  
> ===========================================================================  
> > > > Libxl/libxlu Design  
> > > >   
> > > > 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),  
> > >   
> > > Should this be a KeyedUnion over a new LIBXL_DISK_SNAPSHOT_KIND enum  
> > > (with values INTERNAL and EXTERNAL)? 
> > The KeyedUnion seems to be unnecessary. Only EXTERNAL has data items, 
> > INTERNAL doesn't, and no third types. 
> >  
> > > This would automatically make the  
> > > binding between external==true and the fields which depend on that.  
> > >   
> > > external_format should be of type libxl_disk_format, unless it is  
> > > referring to something else?  
> >  
> > Yes. That's right. I'll update. 
> >  
> > >   
> > > Is it possible for format to differ from the format of the underlying  
> > > disk? Perhaps taking a snapshot of a raw disk as a qcow? 
> >  
> > This is related to implementation details. As I understand qemu's 
> > implementation, taking an external disk snapshot is actually a way: 
> > origin domain disk: a raw disk 
> > external= true, external_format: qcow2, external_path: test 
> > a), create a qcow2 file (test.qcow2) with  backing file (the raw disk) 
> > b), replace domain disk, now domain uses test.qcow2 (the raw disk 
> >      is actually to be the snapshot) 
> >  
> > So, I think the external_format can only be those supporting backing file. 
>  
> Not sure what you mean here. 
>  
> What about a phy snapshot via lvm snapshotting? 
>  
> > > In any case  
> > > passing in UNKNOWN and letting libxl choose (probably by picking the  
> > > same as the underlying disk) should be supported. 
> >  
> > If external_format is not passed (NULL), by default, we will use qcow2. 
>  
> I think you need to base this on the type of the original disk, if it is 
> e.g. vhd then making a qcow snapshot seems a bit odd. 
>  
> >  
> > >   
> > > > /*  This API might not be used by xl, since xl won't take care of  
> deleting  
> > > >  *  snapshots. But for libvirt, since libvirt manages snapshots and will  
> > > >  *  delete snapshot, this API will be used.  
> > > >  */  
> > > > int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid,  
> > > >                                libxl_disk_snapshot *snapshot, int nb);  
> > >   
> > > The three usecases I mentioned in the previous mail are important here,  
> > > because depending on which usecases you are considering there maybe a  
> > > many to one relationship between domains and a given snapshot (gold  
> > > image case). This interface cannot support that I think. 
> >  
> > I'm not quite clear about the three usecases, especially the 3rd usercase, 
> > so really not sure what's the requirement towards deleting disk snapshot. 
>  
> I hope my reply to the previous mail helped clear this up a bit. The 
> reason deleting a disk is interesting is because that is what you would 
> do after the backup was finished. 
>  
> > > When we discussed this in previous iterations I suggested a libxl  
> > > command to tell a VM that it needed to reexamine its disks to see if any  
> > > of the chains had changed. I'm sure that's not the only potential answer  
> > > though. 
> >   
> > About delete disk snapshot in a snapshot chain, whether we need to do 
> > extra work to avoid data break, it can be discussed: 
> > a). For external snapshots, usually it's based on backing file chain, qemu 
> > does this, vhd-util does this. In this case, to delete a domain snapshot, 
> > one doesn't need to do anything to disk (no need to delete disk snapshot 
> > at all). Downside is, there might be a long backing chain. 
>  
> I'm not sure what you mean here I'm afraid. If you are deleting a domain 
> snapshot why do you not want to delete the disk snapshots associated 
> with it? 
>  
> > b). For internal snapshot, like qcow2, lvm too. For lvm, it doesn't support 
> > snapshot of snapshot, so out of scope. For qcow2, delete any disk snapshot 
> > won't affect others. 
>  
> For either internal or external if you are removing a snapshot from the 
> middle of a chain which ends in one or more active disks, then surely 
> the disk backend associated with those domains need to get some sort of 
> notification, otherwise they would need to be written *very* carefully 
> in order to be able to cope with disk metadata changing under their 
> feet. 
>  
> Are you saying that the qemu/qcow implementation has indeed been written 
> with this in mind and can cope with arbitrary other processes modifying 
> the qcow metadata under their feet? 

Yes.

I add qemu-devel Kevin and Stefan in this thread in case my understanding
has somewhere wrong.

Kevin & Stefan,

About the qcow2 snapshot implementation,  in following snapshot chain case,
if we delete SNAPSHOT A, will it affect domain 1 and domain 2 which uses
SNAPSHOT B and SNAPSHOT C?

>From my understanding, creating a snapshot will increases refcount of original data,
deleting a snapshot only descreases the refcount (won't delete data until the refcount
becomes 0), so I think it won't affect domain 1 and domain 2.
Is that right?

Thanks,
Chunyan

>  
> e.g.  
> BASE---SNAPSHOT A---SNAPSHOT B --- domain 1 
>                  `--SNAPSHOT C --- domain 2 
>  
> If SNAPSHOT B and C are in active use then I would expect the deletion 
> of SNAPSHOT A would need to notify the backends associated with domain 1 
> and domain 2 somehow, so they don't get very confused. 
>  
> It's possible that this relates to a use case which you aren't intending 
> to address (e.g. the gold image use case), in which case it might be out 
> of scope here. 
>    
> Ian. 
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 09:36:33 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 09:36:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y2zPl-0002Jz-BT; Mon, 22 Dec 2014 09:36:33 +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 1Y2zPj-0002Jo-BN
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 09:36:31 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	D9/44-20609-E16E7945; Mon, 22 Dec 2014 09:36:30 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419240987!16590617!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 25541 invoked from network); 22 Dec 2014 09:36:29 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Dec 2014 09:36:29 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 22 Dec 2014 02:36:27 -0700
Message-Id: <549856940200006600087406@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 22 Dec 2014 02:36:20 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
	<1418916436.11882.101.camel@citrix.com>
	<54943D220200006600086A64@soto.provo.novell.com>
	<1418985490.20028.27.camel@citrix.com>
In-Reply-To: <1418985490.20028.27.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kwolf@redhat.com, wei.liu2@citrix.com, ian.jackson@eu.citrix.com,
	qemu-devel@nongnu.org, xen-devel@lists.xen.org,
	Jim Fehlig <JFEHLIG@suse.com>, stefanha@redhat.com
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/19/2014 at 06:38 PM, in message <1418985490.20028.27.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Thu, 2014-12-18 at 23:58 -0700, Chun Yan Liu wrote: 
> >  
> > >>> On 12/18/2014 at 11:27 PM, in message  
> <1418916436.11882.101.camel@citrix.com>, 
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:  
> > > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:  
> > > > Changes to V8:  
> > > >   * remove libxl_domain_snapshot_create/delete/revert API  
> > > >   * export disk snapshot functionality for both xl and libvirt usage  
> > > >   
> > > >  
> ===========================================================================  
> > > > Libxl/libxlu Design  
> > > >   
> > > > 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),  
> > >   
> > > Should this be a KeyedUnion over a new LIBXL_DISK_SNAPSHOT_KIND enum  
> > > (with values INTERNAL and EXTERNAL)? 
> > The KeyedUnion seems to be unnecessary. Only EXTERNAL has data items, 
> > INTERNAL doesn't, and no third types. 
> >  
> > > This would automatically make the  
> > > binding between external==true and the fields which depend on that.  
> > >   
> > > external_format should be of type libxl_disk_format, unless it is  
> > > referring to something else?  
> >  
> > Yes. That's right. I'll update. 
> >  
> > >   
> > > Is it possible for format to differ from the format of the underlying  
> > > disk? Perhaps taking a snapshot of a raw disk as a qcow? 
> >  
> > This is related to implementation details. As I understand qemu's 
> > implementation, taking an external disk snapshot is actually a way: 
> > origin domain disk: a raw disk 
> > external= true, external_format: qcow2, external_path: test 
> > a), create a qcow2 file (test.qcow2) with  backing file (the raw disk) 
> > b), replace domain disk, now domain uses test.qcow2 (the raw disk 
> >      is actually to be the snapshot) 
> >  
> > So, I think the external_format can only be those supporting backing file. 
>  
> Not sure what you mean here. 
>  
> What about a phy snapshot via lvm snapshotting? 
>  
> > > In any case  
> > > passing in UNKNOWN and letting libxl choose (probably by picking the  
> > > same as the underlying disk) should be supported. 
> >  
> > If external_format is not passed (NULL), by default, we will use qcow2. 
>  
> I think you need to base this on the type of the original disk, if it is 
> e.g. vhd then making a qcow snapshot seems a bit odd. 
>  
> >  
> > >   
> > > > /*  This API might not be used by xl, since xl won't take care of  
> deleting  
> > > >  *  snapshots. But for libvirt, since libvirt manages snapshots and will  
> > > >  *  delete snapshot, this API will be used.  
> > > >  */  
> > > > int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid,  
> > > >                                libxl_disk_snapshot *snapshot, int nb);  
> > >   
> > > The three usecases I mentioned in the previous mail are important here,  
> > > because depending on which usecases you are considering there maybe a  
> > > many to one relationship between domains and a given snapshot (gold  
> > > image case). This interface cannot support that I think. 
> >  
> > I'm not quite clear about the three usecases, especially the 3rd usercase, 
> > so really not sure what's the requirement towards deleting disk snapshot. 
>  
> I hope my reply to the previous mail helped clear this up a bit. The 
> reason deleting a disk is interesting is because that is what you would 
> do after the backup was finished. 
>  
> > > When we discussed this in previous iterations I suggested a libxl  
> > > command to tell a VM that it needed to reexamine its disks to see if any  
> > > of the chains had changed. I'm sure that's not the only potential answer  
> > > though. 
> >   
> > About delete disk snapshot in a snapshot chain, whether we need to do 
> > extra work to avoid data break, it can be discussed: 
> > a). For external snapshots, usually it's based on backing file chain, qemu 
> > does this, vhd-util does this. In this case, to delete a domain snapshot, 
> > one doesn't need to do anything to disk (no need to delete disk snapshot 
> > at all). Downside is, there might be a long backing chain. 
>  
> I'm not sure what you mean here I'm afraid. If you are deleting a domain 
> snapshot why do you not want to delete the disk snapshots associated 
> with it? 
>  
> > b). For internal snapshot, like qcow2, lvm too. For lvm, it doesn't support 
> > snapshot of snapshot, so out of scope. For qcow2, delete any disk snapshot 
> > won't affect others. 
>  
> For either internal or external if you are removing a snapshot from the 
> middle of a chain which ends in one or more active disks, then surely 
> the disk backend associated with those domains need to get some sort of 
> notification, otherwise they would need to be written *very* carefully 
> in order to be able to cope with disk metadata changing under their 
> feet. 
>  
> Are you saying that the qemu/qcow implementation has indeed been written 
> with this in mind and can cope with arbitrary other processes modifying 
> the qcow metadata under their feet? 

Yes.

I add qemu-devel Kevin and Stefan in this thread in case my understanding
has somewhere wrong.

Kevin & Stefan,

About the qcow2 snapshot implementation,  in following snapshot chain case,
if we delete SNAPSHOT A, will it affect domain 1 and domain 2 which uses
SNAPSHOT B and SNAPSHOT C?

>From my understanding, creating a snapshot will increases refcount of original data,
deleting a snapshot only descreases the refcount (won't delete data until the refcount
becomes 0), so I think it won't affect domain 1 and domain 2.
Is that right?

Thanks,
Chunyan

>  
> e.g.  
> BASE---SNAPSHOT A---SNAPSHOT B --- domain 1 
>                  `--SNAPSHOT C --- domain 2 
>  
> If SNAPSHOT B and C are in active use then I would expect the deletion 
> of SNAPSHOT A would need to notify the backends associated with domain 1 
> and domain 2 somehow, so they don't get very confused. 
>  
> It's possible that this relates to a use case which you aren't intending 
> to address (e.g. the gold image use case), in which case it might be out 
> of scope here. 
>    
> Ian. 
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 09:53:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 09: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 1Y2zg3-00031U-5L; Mon, 22 Dec 2014 09:53:23 +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 1Y2zg2-00031N-0r
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 09:53:22 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	CF/39-27785-11AE7945; Mon, 22 Dec 2014 09:53:21 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1419241998!16566986!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 29458 invoked from network); 22 Dec 2014 09:53:20 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Dec 2014 09:53:20 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 22 Dec 2014 02:53:17 -0700
Message-Id: <54985A86020000660008743C@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 22 Dec 2014 02:53:10 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
	<1418916436.11882.101.camel@citrix.com>
	<54943D220200006600086A64@soto.provo.novell.com>
	<1418985490.20028.27.camel@citrix.com>
In-Reply-To: <1418985490.20028.27.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/19/2014 at 06:38 PM, in message <1418985490.20028.27.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Thu, 2014-12-18 at 23:58 -0700, Chun Yan Liu wrote: 
> >  
> > >>> On 12/18/2014 at 11:27 PM, in message  
> <1418916436.11882.101.camel@citrix.com>, 
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:  
> > > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:  
> > > > Changes to V8:  
> > > >   * remove libxl_domain_snapshot_create/delete/revert API  
> > > >   * export disk snapshot functionality for both xl and libvirt usage  
> > > >   
> > > >  
> ===========================================================================  
> > > > Libxl/libxlu Design  
> > > >   
> > > > 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),  
> > >   
> > > Should this be a KeyedUnion over a new LIBXL_DISK_SNAPSHOT_KIND enum  
> > > (with values INTERNAL and EXTERNAL)? 
> > The KeyedUnion seems to be unnecessary. Only EXTERNAL has data items, 
> > INTERNAL doesn't, and no third types. 
> >  
> > > This would automatically make the  
> > > binding between external==true and the fields which depend on that.  
> > >   
> > > external_format should be of type libxl_disk_format, unless it is  
> > > referring to something else?  
> >  
> > Yes. That's right. I'll update. 
> >  
> > >   
> > > Is it possible for format to differ from the format of the underlying  
> > > disk? Perhaps taking a snapshot of a raw disk as a qcow? 
> >  
> > This is related to implementation details. As I understand qemu's 
> > implementation, taking an external disk snapshot is actually a way: 
> > origin domain disk: a raw disk 
> > external= true, external_format: qcow2, external_path: test 
> > a), create a qcow2 file (test.qcow2) with  backing file (the raw disk) 
> > b), replace domain disk, now domain uses test.qcow2 (the raw disk 
> >      is actually to be the snapshot) 
> >  
> > So, I think the external_format can only be those supporting backing file.

Well, yeah, I should correct. This is only valid for creating external snapshot by
'qemu-img' tool, not fit for lvm and vhd, which have  their own snapshot
functionality tools.

For lvm, the snapshot can be done by 'lvcreate snapshot', snapshot file is also
'lvm' format;

For vhd, the snapshot can be done by 'vht-util snapshot' , then snapshot file
is still vhd format; snapshot also can be done by 'qemu-img snapshot', then the
external format should be a format supported by qemu-img and supporting
backing file.

>  
> Not sure what you mean here. 
>  
> What about a phy snapshot via lvm snapshotting? 
>  
> > > In any case  
> > > passing in UNKNOWN and letting libxl choose (probably by picking the  
> > > same as the underlying disk) should be supported. 
> >  
> > If external_format is not passed (NULL), by default, we will use qcow2. 
>  
> I think you need to base this on the type of the original disk, if it is 
> e.g. vhd then making a qcow snapshot seems a bit odd. 

Agree. For vhd and lvm which have tools other than 'qemu-img', should be
treated differently. For those creating snapshot by 'qemu-img', I think using
'qcow2' by default is reasonable according to qemu's implementation.

- Chunyan

>  
> > >   
> > > > /*  This API might not be used by xl, since xl won't take care of  
> deleting  
> > > >  *  snapshots. But for libvirt, since libvirt manages snapshots and will  
> > > >  *  delete snapshot, this API will be used.  
> > > >  */  
> > > > int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid,  
> > > >                                libxl_disk_snapshot *snapshot, int nb);  
> > >   
> > > The three usecases I mentioned in the previous mail are important here,  
> > > because depending on which usecases you are considering there maybe a  
> > > many to one relationship between domains and a given snapshot (gold  
> > > image case). This interface cannot support that I think. 
> >  
> > I'm not quite clear about the three usecases, especially the 3rd usercase, 
> > so really not sure what's the requirement towards deleting disk snapshot. 
>  
> I hope my reply to the previous mail helped clear this up a bit. The 
> reason deleting a disk is interesting is because that is what you would 
> do after the backup was finished. 
>  
> > > When we discussed this in previous iterations I suggested a libxl  
> > > command to tell a VM that it needed to reexamine its disks to see if any  
> > > of the chains had changed. I'm sure that's not the only potential answer  
> > > though. 
> >   
> > About delete disk snapshot in a snapshot chain, whether we need to do 
> > extra work to avoid data break, it can be discussed: 
> > a). For external snapshots, usually it's based on backing file chain, qemu 
> > does this, vhd-util does this. In this case, to delete a domain snapshot, 
> > one doesn't need to do anything to disk (no need to delete disk snapshot 
> > at all). Downside is, there might be a long backing chain. 
>  
> I'm not sure what you mean here I'm afraid. If you are deleting a domain 
> snapshot why do you not want to delete the disk snapshots associated 
> with it? 
>  
> > b). For internal snapshot, like qcow2, lvm too. For lvm, it doesn't support 
> > snapshot of snapshot, so out of scope. For qcow2, delete any disk snapshot 
> > won't affect others. 
>  
> For either internal or external if you are removing a snapshot from the 
> middle of a chain which ends in one or more active disks, then surely 
> the disk backend associated with those domains need to get some sort of 
> notification, otherwise they would need to be written *very* carefully 
> in order to be able to cope with disk metadata changing under their 
> feet. 
>  
> Are you saying that the qemu/qcow implementation has indeed been written 
> with this in mind and can cope with arbitrary other processes modifying 
> the qcow metadata under their feet? 
>  
> e.g.  
> BASE---SNAPSHOT A---SNAPSHOT B --- domain 1 
>                  `--SNAPSHOT C --- domain 2 
>  
> If SNAPSHOT B and C are in active use then I would expect the deletion 
> of SNAPSHOT A would need to notify the backends associated with domain 1 
> and domain 2 somehow, so they don't get very confused. 
>  
> It's possible that this relates to a use case which you aren't intending 
> to address (e.g. the gold image use case), in which case it might be out 
> of scope here. 
>    
> Ian. 
> >  
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 09:53:45 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 09: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 1Y2zg3-00031U-5L; Mon, 22 Dec 2014 09:53:23 +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 1Y2zg2-00031N-0r
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 09:53:22 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	CF/39-27785-11AE7945; Mon, 22 Dec 2014 09:53:21 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1419241998!16566986!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 29458 invoked from network); 22 Dec 2014 09:53:20 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Dec 2014 09:53:20 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 22 Dec 2014 02:53:17 -0700
Message-Id: <54985A86020000660008743C@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 22 Dec 2014 02:53:10 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-5-git-send-email-cyliu@suse.com>
	<1418916436.11882.101.camel@citrix.com>
	<54943D220200006600086A64@soto.provo.novell.com>
	<1418985490.20028.27.camel@citrix.com>
In-Reply-To: <1418985490.20028.27.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/19/2014 at 06:38 PM, in message <1418985490.20028.27.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Thu, 2014-12-18 at 23:58 -0700, Chun Yan Liu wrote: 
> >  
> > >>> On 12/18/2014 at 11:27 PM, in message  
> <1418916436.11882.101.camel@citrix.com>, 
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:  
> > > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:  
> > > > Changes to V8:  
> > > >   * remove libxl_domain_snapshot_create/delete/revert API  
> > > >   * export disk snapshot functionality for both xl and libvirt usage  
> > > >   
> > > >  
> ===========================================================================  
> > > > Libxl/libxlu Design  
> > > >   
> > > > 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),  
> > >   
> > > Should this be a KeyedUnion over a new LIBXL_DISK_SNAPSHOT_KIND enum  
> > > (with values INTERNAL and EXTERNAL)? 
> > The KeyedUnion seems to be unnecessary. Only EXTERNAL has data items, 
> > INTERNAL doesn't, and no third types. 
> >  
> > > This would automatically make the  
> > > binding between external==true and the fields which depend on that.  
> > >   
> > > external_format should be of type libxl_disk_format, unless it is  
> > > referring to something else?  
> >  
> > Yes. That's right. I'll update. 
> >  
> > >   
> > > Is it possible for format to differ from the format of the underlying  
> > > disk? Perhaps taking a snapshot of a raw disk as a qcow? 
> >  
> > This is related to implementation details. As I understand qemu's 
> > implementation, taking an external disk snapshot is actually a way: 
> > origin domain disk: a raw disk 
> > external= true, external_format: qcow2, external_path: test 
> > a), create a qcow2 file (test.qcow2) with  backing file (the raw disk) 
> > b), replace domain disk, now domain uses test.qcow2 (the raw disk 
> >      is actually to be the snapshot) 
> >  
> > So, I think the external_format can only be those supporting backing file.

Well, yeah, I should correct. This is only valid for creating external snapshot by
'qemu-img' tool, not fit for lvm and vhd, which have  their own snapshot
functionality tools.

For lvm, the snapshot can be done by 'lvcreate snapshot', snapshot file is also
'lvm' format;

For vhd, the snapshot can be done by 'vht-util snapshot' , then snapshot file
is still vhd format; snapshot also can be done by 'qemu-img snapshot', then the
external format should be a format supported by qemu-img and supporting
backing file.

>  
> Not sure what you mean here. 
>  
> What about a phy snapshot via lvm snapshotting? 
>  
> > > In any case  
> > > passing in UNKNOWN and letting libxl choose (probably by picking the  
> > > same as the underlying disk) should be supported. 
> >  
> > If external_format is not passed (NULL), by default, we will use qcow2. 
>  
> I think you need to base this on the type of the original disk, if it is 
> e.g. vhd then making a qcow snapshot seems a bit odd. 

Agree. For vhd and lvm which have tools other than 'qemu-img', should be
treated differently. For those creating snapshot by 'qemu-img', I think using
'qcow2' by default is reasonable according to qemu's implementation.

- Chunyan

>  
> > >   
> > > > /*  This API might not be used by xl, since xl won't take care of  
> deleting  
> > > >  *  snapshots. But for libvirt, since libvirt manages snapshots and will  
> > > >  *  delete snapshot, this API will be used.  
> > > >  */  
> > > > int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid,  
> > > >                                libxl_disk_snapshot *snapshot, int nb);  
> > >   
> > > The three usecases I mentioned in the previous mail are important here,  
> > > because depending on which usecases you are considering there maybe a  
> > > many to one relationship between domains and a given snapshot (gold  
> > > image case). This interface cannot support that I think. 
> >  
> > I'm not quite clear about the three usecases, especially the 3rd usercase, 
> > so really not sure what's the requirement towards deleting disk snapshot. 
>  
> I hope my reply to the previous mail helped clear this up a bit. The 
> reason deleting a disk is interesting is because that is what you would 
> do after the backup was finished. 
>  
> > > When we discussed this in previous iterations I suggested a libxl  
> > > command to tell a VM that it needed to reexamine its disks to see if any  
> > > of the chains had changed. I'm sure that's not the only potential answer  
> > > though. 
> >   
> > About delete disk snapshot in a snapshot chain, whether we need to do 
> > extra work to avoid data break, it can be discussed: 
> > a). For external snapshots, usually it's based on backing file chain, qemu 
> > does this, vhd-util does this. In this case, to delete a domain snapshot, 
> > one doesn't need to do anything to disk (no need to delete disk snapshot 
> > at all). Downside is, there might be a long backing chain. 
>  
> I'm not sure what you mean here I'm afraid. If you are deleting a domain 
> snapshot why do you not want to delete the disk snapshots associated 
> with it? 
>  
> > b). For internal snapshot, like qcow2, lvm too. For lvm, it doesn't support 
> > snapshot of snapshot, so out of scope. For qcow2, delete any disk snapshot 
> > won't affect others. 
>  
> For either internal or external if you are removing a snapshot from the 
> middle of a chain which ends in one or more active disks, then surely 
> the disk backend associated with those domains need to get some sort of 
> notification, otherwise they would need to be written *very* carefully 
> in order to be able to cope with disk metadata changing under their 
> feet. 
>  
> Are you saying that the qemu/qcow implementation has indeed been written 
> with this in mind and can cope with arbitrary other processes modifying 
> the qcow metadata under their feet? 
>  
> e.g.  
> BASE---SNAPSHOT A---SNAPSHOT B --- domain 1 
>                  `--SNAPSHOT C --- domain 2 
>  
> If SNAPSHOT B and C are in active use then I would expect the deletion 
> of SNAPSHOT A would need to notify the backends associated with domain 1 
> and domain 2 somehow, so they don't get very confused. 
>  
> It's possible that this relates to a use case which you aren't intending 
> to address (e.g. the gold image use case), in which case it might be out 
> of scope here. 
>    
> Ian. 
> >  
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 10:37:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 10:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y30M1-0004ET-3I; Mon, 22 Dec 2014 10:36:45 +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 1Y30M0-0004EH-5F
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 10:36:44 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	9D/2A-17936-B34F7945; Mon, 22 Dec 2014 10:36:43 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1419244602!16612408!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2758 invoked from network); 22 Dec 2014 10:36:42 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2014 10:36:42 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so7491220wiw.10
	for <xen-devel@lists.xen.org>; Mon, 22 Dec 2014 02:36: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=FxlZHvcWmevMsSZAyziT6z+AkOVvAEJyNvTa6uKqYFE=;
	b=P3d8zIXvgla87GgoSreQLtxYnIoGXaWG/FTHtCkVb6x6C44ItCl0RiWVkeb7vDCrW1
	6spMBIhMrFNWmWYJ36+LZ/mRYfMUteaOQ2KrurWlhc3LaOClQhY5avOg9IDtqlJRacOz
	WPiZBZAGSfP5T2z8TpVw4W0+pDFu5eoLY48JdiybsS5veDNe9PAFqoR7P8XvIleDBh1v
	szE9KqNwonJ7iZn8mc/FYhIB2KW7F/QoiI3whTLGa9o5LsnEq+ToETbTAQBN9lE1AFx5
	tgQGQT7kW4VbCAXO9GBO7qWIrKguJEkfp5JpZQ5sTNBo6adJRJtZaGpk1MMOxVCTjkrz
	jjMw==
X-Gm-Message-State: ALoCoQktKvwezeAM1RBgwHgOyEnVjOMbai4cvKt0OqhAuX2jAiNflF5MpFVeeT/duoZxXXOXyq1g
X-Received: by 10.181.13.42 with SMTP id ev10mr29411403wid.78.1419244602589;
	Mon, 22 Dec 2014 02:36:42 -0800 (PST)
Received: from Juliens-MacBook-Pro.local (158.93.192.77.rev.sfr.net.
	[77.192.93.158]) by mx.google.com with ESMTPSA id
	kn5sm23157717wjb.48.2014.12.22.02.36.40
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 22 Dec 2014 02:36:41 -0800 (PST)
Message-ID: <5497F44A.7030201@linaro.org>
Date: Mon, 22 Dec 2014 11:36:58 +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.3.0
MIME-Version: 1.0
To: Vijay Kilari <vijay.kilari@gmail.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CALicx6tEQ+MXu51UN55KtVwDRPECNgqnvMaAM_MivubB7AsO+g@mail.gmail.com>
In-Reply-To: <CALicx6tEQ+MXu51UN55KtVwDRPECNgqnvMaAM_MivubB7AsO+g@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: VCPU scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/12/2014 20:48, Vijay Kilari wrote:
> Hi,

Hi Vijay,

>
>     I want to know what is the criteria followed in Xen for scheduling VCPUs.
> Assume below scenario:
>
>   - Run 2 VPCUs on 1 Physical CPU
>   - VCPUs does not trap on WFE or WFE ( either by WFI/WFE trap is
> disabled in HCR OR no WFE/WFI in EL1 is executed).
>
> In such scenario, does Xen assumes that VCPU0 is always running because it has
> NOT trapped on WFI and WFE (not yielded voluntary) and does not
> schedule VCPU1? or is it time shared?

The scheduler allocates time slice to each VCPU. Once the slice is 
ending, another VCPU may be scheduled.

Xen is also trapping WFE/WFI to allow better performance. Why would you 
want to disable WFE/WFI traps?

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 Dec 22 10:37:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 10:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y30M1-0004ET-3I; Mon, 22 Dec 2014 10:36:45 +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 1Y30M0-0004EH-5F
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 10:36:44 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	9D/2A-17936-B34F7945; Mon, 22 Dec 2014 10:36:43 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1419244602!16612408!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2758 invoked from network); 22 Dec 2014 10:36:42 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2014 10:36:42 -0000
Received: by mail-wi0-f177.google.com with SMTP id l15so7491220wiw.10
	for <xen-devel@lists.xen.org>; Mon, 22 Dec 2014 02:36: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=FxlZHvcWmevMsSZAyziT6z+AkOVvAEJyNvTa6uKqYFE=;
	b=P3d8zIXvgla87GgoSreQLtxYnIoGXaWG/FTHtCkVb6x6C44ItCl0RiWVkeb7vDCrW1
	6spMBIhMrFNWmWYJ36+LZ/mRYfMUteaOQ2KrurWlhc3LaOClQhY5avOg9IDtqlJRacOz
	WPiZBZAGSfP5T2z8TpVw4W0+pDFu5eoLY48JdiybsS5veDNe9PAFqoR7P8XvIleDBh1v
	szE9KqNwonJ7iZn8mc/FYhIB2KW7F/QoiI3whTLGa9o5LsnEq+ToETbTAQBN9lE1AFx5
	tgQGQT7kW4VbCAXO9GBO7qWIrKguJEkfp5JpZQ5sTNBo6adJRJtZaGpk1MMOxVCTjkrz
	jjMw==
X-Gm-Message-State: ALoCoQktKvwezeAM1RBgwHgOyEnVjOMbai4cvKt0OqhAuX2jAiNflF5MpFVeeT/duoZxXXOXyq1g
X-Received: by 10.181.13.42 with SMTP id ev10mr29411403wid.78.1419244602589;
	Mon, 22 Dec 2014 02:36:42 -0800 (PST)
Received: from Juliens-MacBook-Pro.local (158.93.192.77.rev.sfr.net.
	[77.192.93.158]) by mx.google.com with ESMTPSA id
	kn5sm23157717wjb.48.2014.12.22.02.36.40
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 22 Dec 2014 02:36:41 -0800 (PST)
Message-ID: <5497F44A.7030201@linaro.org>
Date: Mon, 22 Dec 2014 11:36:58 +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.3.0
MIME-Version: 1.0
To: Vijay Kilari <vijay.kilari@gmail.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CALicx6tEQ+MXu51UN55KtVwDRPECNgqnvMaAM_MivubB7AsO+g@mail.gmail.com>
In-Reply-To: <CALicx6tEQ+MXu51UN55KtVwDRPECNgqnvMaAM_MivubB7AsO+g@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen/arm: VCPU scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/12/2014 20:48, Vijay Kilari wrote:
> Hi,

Hi Vijay,

>
>     I want to know what is the criteria followed in Xen for scheduling VCPUs.
> Assume below scenario:
>
>   - Run 2 VPCUs on 1 Physical CPU
>   - VCPUs does not trap on WFE or WFE ( either by WFI/WFE trap is
> disabled in HCR OR no WFE/WFI in EL1 is executed).
>
> In such scenario, does Xen assumes that VCPU0 is always running because it has
> NOT trapped on WFI and WFE (not yielded voluntary) and does not
> schedule VCPU1? or is it time shared?

The scheduler allocates time slice to each VCPU. Once the slice is 
ending, another VCPU may be scheduled.

Xen is also trapping WFE/WFI to allow better performance. Why would you 
want to disable WFE/WFI traps?

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 Dec 22 10:54:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 10:54:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y30cW-00056Y-Hn; Mon, 22 Dec 2014 10:53:48 +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 1Y30cV-00056S-68
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 10:53:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9D/FA-25276-A38F7945; Mon, 22 Dec 2014 10:53:46 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419245625!9164844!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24179 invoked from network); 22 Dec 2014 10:53:46 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2014 10:53:46 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so7622445wib.16
	for <xen-devel@lists.xen.org>; Mon, 22 Dec 2014 02:53:45 -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=4RSBgYBGWws0crc2HcZg0jDyDtdxmx1xUqYwty6GnIQ=;
	b=DsTAAiLXO8cxdOMjzzR/oqSQT067rWXz0i1hWr3nR+Achh0Lou1jpH57m6FJa2AYlK
	EaQBzBB3tVH7osmbFwLlVjY5LVilZbgolLgtARm4zFyeV8CHYaxdSQegnAn71cbp+Xlz
	4O9xx7UZXEkFpt9sFJXiyAVeoN+JCy39eZ5V8XYbb0hNmFojX6IQ0IpcwvxIemDsfWBR
	tRamKj9k8TLNVMMwT3qDeaNL3pCqbFQyR2EaTcxBZoNSJiT5w42kofFamf0qb+JHvJXk
	R/SRhU4g7mVgl0Mijcfl7b5ibn+yEPAxsD6Cq2eTPkdD0F+dwZtLtqEAUHhBavI6jrPb
	6qNA==
X-Gm-Message-State: ALoCoQkY7KSmrXaJw+HRVqv4bF/7oSllj76FSspFx5oWRyJr7A0rS3IZy/1ZyS4oa4gtW/2J2Wnw
X-Received: by 10.180.228.72 with SMTP id sg8mr30355166wic.48.1419245625721;
	Mon, 22 Dec 2014 02:53:45 -0800 (PST)
Received: from Juliens-MacBook-Pro.local (158.93.192.77.rev.sfr.net.
	[77.192.93.158]) by mx.google.com with ESMTPSA id
	u18sm23218749wjq.42.2014.12.22.02.53.43
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 22 Dec 2014 02:53:44 -0800 (PST)
Message-ID: <5497F849.3050806@linaro.org>
Date: Mon, 22 Dec 2014 11:54:01 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <ijc@hellion.org.uk>, xen-devel@lists.xen.org
References: <1419160733-31534-1-git-send-email-ijc@hellion.org.uk>
In-Reply-To: <1419160733-31534-1-git-send-email-ijc@hellion.org.uk>
Cc: tim@xen.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] xen: arm: correct off-by-one error in
	consider_modules
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 21/12/2014 12:18, Ian Campbell wrote:
> By iterating up to <= mi->nr_mods we are running off the end of the boot
> modules, but more importantly it causes us to then skip the first FDT reserved
> region, meaning we might clobber it.

Oops. Good catch!

OOI, how did you find it?

> Signed-off-by: Ian Campbell <ijc@hellion.org.uk>

Reviewed-by: Julien Grall <julien.grall@linaro.org>

> ---
> For 4.5: I think this bug fix should go in, it fixes a real issue and is low
> risk.

Agreed.

> I'll also add to my list of things to consider for backport to 4.4.

Ditto.

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 Dec 22 10:54:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 10:54:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y30cW-00056Y-Hn; Mon, 22 Dec 2014 10:53:48 +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 1Y30cV-00056S-68
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 10:53:47 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	9D/FA-25276-A38F7945; Mon, 22 Dec 2014 10:53:46 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419245625!9164844!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24179 invoked from network); 22 Dec 2014 10:53:46 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Dec 2014 10:53:46 -0000
Received: by mail-wi0-f171.google.com with SMTP id bs8so7622445wib.16
	for <xen-devel@lists.xen.org>; Mon, 22 Dec 2014 02:53:45 -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=4RSBgYBGWws0crc2HcZg0jDyDtdxmx1xUqYwty6GnIQ=;
	b=DsTAAiLXO8cxdOMjzzR/oqSQT067rWXz0i1hWr3nR+Achh0Lou1jpH57m6FJa2AYlK
	EaQBzBB3tVH7osmbFwLlVjY5LVilZbgolLgtARm4zFyeV8CHYaxdSQegnAn71cbp+Xlz
	4O9xx7UZXEkFpt9sFJXiyAVeoN+JCy39eZ5V8XYbb0hNmFojX6IQ0IpcwvxIemDsfWBR
	tRamKj9k8TLNVMMwT3qDeaNL3pCqbFQyR2EaTcxBZoNSJiT5w42kofFamf0qb+JHvJXk
	R/SRhU4g7mVgl0Mijcfl7b5ibn+yEPAxsD6Cq2eTPkdD0F+dwZtLtqEAUHhBavI6jrPb
	6qNA==
X-Gm-Message-State: ALoCoQkY7KSmrXaJw+HRVqv4bF/7oSllj76FSspFx5oWRyJr7A0rS3IZy/1ZyS4oa4gtW/2J2Wnw
X-Received: by 10.180.228.72 with SMTP id sg8mr30355166wic.48.1419245625721;
	Mon, 22 Dec 2014 02:53:45 -0800 (PST)
Received: from Juliens-MacBook-Pro.local (158.93.192.77.rev.sfr.net.
	[77.192.93.158]) by mx.google.com with ESMTPSA id
	u18sm23218749wjq.42.2014.12.22.02.53.43
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 22 Dec 2014 02:53:44 -0800 (PST)
Message-ID: <5497F849.3050806@linaro.org>
Date: Mon, 22 Dec 2014 11:54:01 +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.3.0
MIME-Version: 1.0
To: Ian Campbell <ijc@hellion.org.uk>, xen-devel@lists.xen.org
References: <1419160733-31534-1-git-send-email-ijc@hellion.org.uk>
In-Reply-To: <1419160733-31534-1-git-send-email-ijc@hellion.org.uk>
Cc: tim@xen.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] xen: arm: correct off-by-one error in
	consider_modules
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 21/12/2014 12:18, Ian Campbell wrote:
> By iterating up to <= mi->nr_mods we are running off the end of the boot
> modules, but more importantly it causes us to then skip the first FDT reserved
> region, meaning we might clobber it.

Oops. Good catch!

OOI, how did you find it?

> Signed-off-by: Ian Campbell <ijc@hellion.org.uk>

Reviewed-by: Julien Grall <julien.grall@linaro.org>

> ---
> For 4.5: I think this bug fix should go in, it fixes a real issue and is low
> risk.

Agreed.

> I'll also add to my list of things to consider for backport to 4.4.

Ditto.

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 Dec 22 11:40:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 11: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 1Y31Kg-0006Jf-Ji; Mon, 22 Dec 2014 11:39:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1Y31Kf-0006Ja-Ff
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 11:39:25 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	9D/FD-27584-CE208945; Mon, 22 Dec 2014 11:39:24 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-10.tower-206.messagelabs.com!1419248364!9383739!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19645 invoked from network); 22 Dec 2014 11:39:24 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-10.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	22 Dec 2014 11:39:24 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginm.net ([86.6.25.227]
	helo=dagon.hellion.org.uk) by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1Y31Kc-00043g-7m; Mon, 22 Dec 2014 11:39:22 +0000
Message-ID: <1419248361.26985.156.camel@hellion.org.uk>
From: Ian Campbell <ijc@hellion.org.uk>
To: Julien Grall <julien.grall@linaro.org>
Date: Mon, 22 Dec 2014 11:39:21 +0000
In-Reply-To: <5497F849.3050806@linaro.org>
References: <1419160733-31534-1-git-send-email-ijc@hellion.org.uk>
	<5497F849.3050806@linaro.org>
X-Mailer: Evolution 3.12.9-1 
Mime-Version: 1.0
Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: arm: correct off-by-one error in
	consider_modules
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-22 at 11:54 +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 21/12/2014 12:18, Ian Campbell wrote:
> > By iterating up to <= mi->nr_mods we are running off the end of the boot
> > modules, but more importantly it causes us to then skip the first FDT reserved
> > region, meaning we might clobber it.
> 
> Oops. Good catch!
> 
> OOI, how did you find it?

U-boot on Jetson was locating the PSCI handling code at the top of RAM
and reserving it in the DT, but Xen was still relocating itself over it,
causing secondary CPU bringup to hang the board.

(This is an experimental u-boot, so it doesn't actually enforce the
security of the PSCI region yet, if it did I'd have expected a fault on
relocation instead of a hang on CPU up).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 11:40:05 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 11: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 1Y31Kg-0006Jf-Ji; Mon, 22 Dec 2014 11:39:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1Y31Kf-0006Ja-Ff
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 11:39:25 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	9D/FD-27584-CE208945; Mon, 22 Dec 2014 11:39:24 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-10.tower-206.messagelabs.com!1419248364!9383739!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19645 invoked from network); 22 Dec 2014 11:39:24 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-10.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	22 Dec 2014 11:39:24 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginm.net ([86.6.25.227]
	helo=dagon.hellion.org.uk) by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1Y31Kc-00043g-7m; Mon, 22 Dec 2014 11:39:22 +0000
Message-ID: <1419248361.26985.156.camel@hellion.org.uk>
From: Ian Campbell <ijc@hellion.org.uk>
To: Julien Grall <julien.grall@linaro.org>
Date: Mon, 22 Dec 2014 11:39:21 +0000
In-Reply-To: <5497F849.3050806@linaro.org>
References: <1419160733-31534-1-git-send-email-ijc@hellion.org.uk>
	<5497F849.3050806@linaro.org>
X-Mailer: Evolution 3.12.9-1 
Mime-Version: 1.0
Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: arm: correct off-by-one error in
	consider_modules
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2014-12-22 at 11:54 +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 21/12/2014 12:18, Ian Campbell wrote:
> > By iterating up to <= mi->nr_mods we are running off the end of the boot
> > modules, but more importantly it causes us to then skip the first FDT reserved
> > region, meaning we might clobber it.
> 
> Oops. Good catch!
> 
> OOI, how did you find it?

U-boot on Jetson was locating the PSCI handling code at the top of RAM
and reserving it in the DT, but Xen was still relocating itself over it,
causing secondary CPU bringup to hang the board.

(This is an experimental u-boot, so it doesn't actually enforce the
security of the PSCI region yet, if it did I'd have expected a fault on
relocation instead of a hang on CPU up).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 13:14:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 13:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y32oY-0000Wg-Sa; Mon, 22 Dec 2014 13:14:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y32oX-0000Wb-Tg
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 13:14:22 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	70/74-28296-D2918945; Mon, 22 Dec 2014 13:14:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419254058!15170927!1
X-Originating-IP: [66.165.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 30568 invoked from network); 22 Dec 2014 13:14:20 -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 Dec 2014 13:14:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,623,1413244800"; d="scan'208";a="206959710"
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.210.2; Mon, 22 Dec 2014 08:14:17 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y32oT-0008BJ-5P;
	Mon, 22 Dec 2014 13:14:17 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y32oS-00033w-VF;
	Mon, 22 Dec 2014 13:14:16 +0000
Date: Mon, 22 Dec 2014 13:14:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32568-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] 32568: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32568 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32568/

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-pair         7 xen-boot/src_host           fail pass in 32557

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot     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-qemut-rhel6hvm-amd 7 redhat-install fail in 32557 like 28935-bisect
 test-amd64-i386-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail in 32557 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     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-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-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-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-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                     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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 34929 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 Dec 22 13:14:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 13:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y32oY-0000Wg-Sa; Mon, 22 Dec 2014 13:14:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y32oX-0000Wb-Tg
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 13:14:22 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	70/74-28296-D2918945; Mon, 22 Dec 2014 13:14:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419254058!15170927!1
X-Originating-IP: [66.165.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 30568 invoked from network); 22 Dec 2014 13:14:20 -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 Dec 2014 13:14:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,623,1413244800"; d="scan'208";a="206959710"
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.210.2; Mon, 22 Dec 2014 08:14:17 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y32oT-0008BJ-5P;
	Mon, 22 Dec 2014 13:14:17 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y32oS-00033w-VF;
	Mon, 22 Dec 2014 13:14:16 +0000
Date: Mon, 22 Dec 2014 13:14:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32568-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] 32568: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32568 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32568/

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-pair         7 xen-boot/src_host           fail pass in 32557

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64  5 xen-boot     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-qemut-rhel6hvm-amd 7 redhat-install fail in 32557 like 28935-bisect
 test-amd64-i386-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail in 32557 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     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-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-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-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-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                     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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 34929 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 Dec 22 13:28:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 13: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 1Y331r-0000sn-8J; Mon, 22 Dec 2014 13:28: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 1Y331p-0000si-Qw
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 13:28:06 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	92/A4-02953-56C18945; Mon, 22 Dec 2014 13:28:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1419254883!13310102!1
X-Originating-IP: [66.165.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 19658 invoked from network); 22 Dec 2014 13:28:04 -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;
	22 Dec 2014 13:28:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="206963990"
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.210.2; Mon, 22 Dec 2014 08:28: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 1Y331l-0008FW-71;
	Mon, 22 Dec 2014 13:28:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y331l-0006xp-1p;
	Mon, 22 Dec 2014 13:28:01 +0000
Date: Mon, 22 Dec 2014 13:28:01 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32577-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] 32577: 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 32577 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32577/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          5f4031a1d23e08f1f470e0af788c0296223ae6b5
baseline version:
 rumpuserxen          0383102b09fd3724f14c200cd8ea5f157d216d95

------------------------------------------------------------
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=5f4031a1d23e08f1f470e0af788c0296223ae6b5
+ . 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 5f4031a1d23e08f1f470e0af788c0296223ae6b5
+ branch=rumpuserxen
+ revision=5f4031a1d23e08f1f470e0af788c0296223ae6b5
+ . 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 5f4031a1d23e08f1f470e0af788c0296223ae6b5:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   0383102..5f4031a  5f4031a1d23e08f1f470e0af788c0296223ae6b5 -> 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 Dec 22 13:28:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 13: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 1Y331r-0000sn-8J; Mon, 22 Dec 2014 13:28: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 1Y331p-0000si-Qw
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 13:28:06 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	92/A4-02953-56C18945; Mon, 22 Dec 2014 13:28:05 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1419254883!13310102!1
X-Originating-IP: [66.165.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 19658 invoked from network); 22 Dec 2014 13:28:04 -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;
	22 Dec 2014 13:28:04 -0000
X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="206963990"
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.210.2; Mon, 22 Dec 2014 08:28: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 1Y331l-0008FW-71;
	Mon, 22 Dec 2014 13:28:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y331l-0006xp-1p;
	Mon, 22 Dec 2014 13:28:01 +0000
Date: Mon, 22 Dec 2014 13:28:01 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32577-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] 32577: 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 32577 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32577/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          5f4031a1d23e08f1f470e0af788c0296223ae6b5
baseline version:
 rumpuserxen          0383102b09fd3724f14c200cd8ea5f157d216d95

------------------------------------------------------------
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=5f4031a1d23e08f1f470e0af788c0296223ae6b5
+ . 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 5f4031a1d23e08f1f470e0af788c0296223ae6b5
+ branch=rumpuserxen
+ revision=5f4031a1d23e08f1f470e0af788c0296223ae6b5
+ . 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 5f4031a1d23e08f1f470e0af788c0296223ae6b5:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   0383102..5f4031a  5f4031a1d23e08f1f470e0af788c0296223ae6b5 -> 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 Dec 22 14:43:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 14: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 1Y34Bs-0003B0-Sv; Mon, 22 Dec 2014 14:42:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <elena.ufimtseva@oracle.com>) id 1Y33oT-0002V3-Nq
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 14:18:22 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BE/BE-09842-C2828945; Mon, 22 Dec 2014 14:18:20 +0000
X-Env-Sender: elena.ufimtseva@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419257898!17268492!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8496 invoked from network); 22 Dec 2014 14:18:19 -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; 22 Dec 2014 14:18:19 -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 sBMEIHXN012158
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Mon, 22 Dec 2014 14:18:18 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
	sBMEIG7v022594
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xen.org>; Mon, 22 Dec 2014 14:18:17 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
	sBMEIGu7022562
	for <xen-devel@lists.xen.org>; Mon, 22 Dec 2014 14:18:16 GMT
MIME-Version: 1.0
Message-ID: <42e7aeac-499b-4f8b-b932-35636f340d50@default>
Date: Mon, 22 Dec 2014 06:18:15 -0800 (PST)
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
To: <xen-devel@lists.xen.org>
X-Mailer: Zimbra on Oracle Beehive
Content-Type: multipart/mixed;
	boundary="__141925789570321276abhmp0016.oracle.com"
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-Mailman-Approved-At: Mon, 22 Dec 2014 14:42:31 +0000
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] dom0 as pvh boot problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--__141925789570321276abhmp0016.oracle.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi

There is a problem with booting dom0 as pvh (xen-4.5rc3, kernel 3.18.0+).
After digging a bit into this it seems that the booting gets stuck upon ena=
bling second IOMMU by writing to DMAR_GCMD_REG (See the attaches debug log)=
.
The boot process passes this stage if second iommu was not enabled.
I tried multiple iommu options on boot, but it did not help.
There is no problem booting baremetal linux with IOMMU enabled.
The difference I have noticed its the version of microcode that is shown in=
 baremetal and Xen.
Baremetal linux shows microcode version as 0x710, Xen as 0x70d, not sure if=
 its relevant.

Any advise on how to address this is appreciated.

baremetal cpuinfo:

processor    : 7
vendor_id    : GenuineIntel
cpu family    : 6
model        : 45
model name    : Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz
stepping    : 7
microcode    : 0x710
cpu MHz        : 1200.000
cache size    : 10240 KB
physical id    : 1
siblings    : 4
core id        : 3
cpu cores    : 4
apicid        : 38
initial apicid    : 38
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmo=
v pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe=
1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology no=
nstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx e=
st tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadli=
ne_timer aes xsave avx lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow =
vnmi flexpriority ept vpid
bogomips    : 4789.44
clflush size    : 64
cache_alignment    : 64
address sizes    : 46 bits physical, 48 bits virtual
power management

--=20
Elena
--__141925789570321276abhmp0016.oracle.com
Content-Type: application/octet-stream; name="dom0pvh_xeon_e5"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="dom0pvh_xeon_e5"

IFhlbiA0LjUuMC1yYw0KKFhFTikgWGVuIHZlcnNpb24gNC41LjAtcmMgKHhlbmRldkApIChnY2Mg
KERlYmlhbiA0LjcuMi01KSA0LjcuMikgZGVidWc9eSBUdWUgRGVjICA5IDIyOjAzOjUxIEVTVCAy
MDE0DQooWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiBXZWQgRGVjIDMgMTA6MzE6MjIgMjAxNCAtMDUw
MCBnaXQ6M2E4MDk4NS1kaXJ0eQ0KKFhFTikgQ29uc29sZSBvdXRwdXQgaXMgc3luY2hyb25vdXMu
DQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEuOTktMjcrZGViN3UxDQooWEVOKSBDb21tYW5kIGxp
bmU6IGVhcmx5cHJpbnRrPXhlbiBkb20wcHZoPTEgZG9tMF9tZW09NDA5Nk0gbG9nbHZsPWRlYnVn
IGNvbTE9MTE1MjAwLDhuMSBjb25zb2xlPWNvbTEgaW9tbXU9ZGVidWcsdmVyYm9zZSBzeW5jX2Nv
bnNvbGUgZG9tMF9tYXhfdmNwdXM9MiBkb20wX3ZjcHVzX3Bpbg0KKFhFTikgVmlkZW8gaW5mb3Jt
YXRpb246DQooWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9udCA4eDE2DQooWEVOKSAg
VkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0aW1lOiAxIHNlY29uZHMNCihYRU4p
IERpc2MgaW5mb3JtYXRpb246DQooWEVOKSAgRm91bmQgMSBNQlIgc2lnbmF0dXJlcw0KKFhFTikg
IEZvdW5kIDEgRUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMNCihYRU4pIFhlbi1lODIwIFJBTSBt
YXA6DQooWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOGRjMDAgKHVzYWJsZSkN
CihYRU4pICAwMDAwMDAwMDAwMDhkYzAwIC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpDQoo
WEVOKSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQ0KKFhF
TikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMGFjMjI1MDAwICh1c2FibGUpDQooWEVOKSAg
MDAwMDAwMDBhYzIyNTAwMCAtIDAwMDAwMDAwYWMyNjkwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAw
MDAwMDAwYWMyNjkwMDAgLSAwMDAwMDAwMGFjNTgwMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAw
MDBhYzU4MDAwMCAtIDAwMDAwMDAwYWM1YTEwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAw
YWM1YTEwMDAgLSAwMDAwMDAwMGFjNWJjMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhYzVi
YzAwMCAtIDAwMDAwMDAwYWM1YmUwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwYWM1YmUw
MDAgLSAwMDAwMDAwMGFjNWJmMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhYzViZjAwMCAt
IDAwMDAwMDAwYWM1Y2IwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwYWM1Y2IwMDAgLSAw
MDAwMDAwMGFjNWRhMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhYzVkYTAwMCAtIDAwMDAw
MDAwYWM1ZmIwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwYWM1ZmIwMDAgLSAwMDAwMDAw
MGFjNmI2MDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhYzZiNjAwMCAtIDAwMDAwMDAwYWM3
ZmIwMDAgKEFDUEkgTlZTKQ0KKFhFTikgIDAwMDAwMDAwYWM3ZmIwMDAgLSAwMDAwMDAwMGFjODBm
MDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhYzgwZjAwMCAtIDAwMDAwMDAwYWM4MTAwMDAg
KEFDUEkgZGF0YSkNCihYRU4pICAwMDAwMDAwMGFjODEwMDAwIC0gMDAwMDAwMDBhYzgxMTAwMCAo
dXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwYWM4MTEwMDAgLSAwMDAwMDAwMGFjODEzMDAwIChBQ1BJ
IGRhdGEpDQooWEVOKSAgMDAwMDAwMDBhYzgxMzAwMCAtIDAwMDAwMDAwYWQ4MDAwMDAgKHVzYWJs
ZSkNCihYRU4pICAwMDAwMDAwMGIwMDAwMDAwIC0gMDAwMDAwMDBiNDAwMDAwMCAocmVzZXJ2ZWQp
DQooWEVOKSAgMDAwMDAwMDBmZWQyMDAwMCAtIDAwMDAwMDAwZmVkNDAwMDAgKHJlc2VydmVkKQ0K
KFhFTikgIDAwMDAwMDAwZmVkNTAwMDAgLSAwMDAwMDAwMGZlZDkwMDAwIChyZXNlcnZlZCkNCihY
RU4pICAwMDAwMDAwMGZmYTAwMDAwIC0gMDAwMDAwMDBmZmE0MDAwMCAocmVzZXJ2ZWQpDQooWEVO
KSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDA4NTAwMDAwMDAgKHVzYWJsZSkNCihYRU4pIEFD
UEk6IFJTRFAgMDAwRkUzMDAsIDAwMjQgKHIyIERFTEwgICkNCihYRU4pIEFDUEk6IFhTRFQgQUM4
MTFFMTgsIDAwODQgKHIxIERFTEwgICAgQ0JYMyAgICAgNjIyMjAwNCBNU0ZUICAgIDEwMDEzKQ0K
KFhFTikgQUNQSTogRkFDUCBBQzdFQkMxOCwgMDBGNCAocjQgREVMTCAgICBDQlgzICAgICA2MjIy
MDA0IE1TRlQgICAgMTAwMTMpDQooWEVOKSBBQ1BJOiBEU0RUIEFDN0E1MDE4LCA2MzczIChyMSBE
RUxMICAgIENCWDMgICAgICAgICAgIDAgSU5UTCAyMDA5MTExMikNCihYRU4pIEFDUEk6IEZBQ1Mg
QUM3RUNGNDAsIDAwNDANCihYRU4pIEFDUEk6IEFQSUMgQUM4MEZFMTgsIDAxNjQgKHIyIERFTEwg
ICAgQ0JYMyAgICAgNjIyMjAwNCBNU0ZUICAgIDEwMDEzKQ0KKFhFTikgQUNQSTogTUNGRyBBQzdG
OUQxOCwgMDAzQyAocjEgQSBNIEkgIE9FTU1DRkcuICA2MjIyMDA0IE1TRlQgICAgICAgOTcpDQoo
WEVOKSBBQ1BJOiBUQ1BBIEFDN0Y5Qzk4LCAwMDMyIChyMiAgICAgICAgICAgICAgICAgICAgICAg
IDAgICAgICAgICAgICAgMCkNCihYRU4pIEFDUEk6IFNTRFQgQUM3RUFBOTgsIDAzMDYgKHIxIERF
TExUUCAgICAgIFRQTSAgICAgMzAwMCBJTlRMIDIwMDkxMTEyKQ0KKFhFTikgQUNQSTogU1JBVCBB
QzdFQTcxOCwgMDMzMCAocjEgQSBNIEkgIEFNSSBTUkFUICAgICAgICAwIEFNSS4gICAgICAgIDAp
DQooWEVOKSBBQ1BJOiBTTElUIEFDN0Y5QzE4LCAwMDMwIChyMSBBIE0gSSAgQU1JIFNMSVQgICAg
ICAgIDAgQU1JLiAgICAgICAgMCkNCihYRU4pIEFDUEk6IEhQRVQgQUM3RjlCOTgsIDAwMzggKHIx
IEEgTSBJICAgUENISFBFVCAgNjIyMjAwNCBBTUkuICAgICAgICAzKQ0KKFhFTikgQUNQSTogQk9P
VCBBQzdGOUIxOCwgMDAyOCAocjEgREVMTCAgIENCWDMgICAgICA2MjIyMDA0IEFNSSAgICAgMTAw
MTMpDQooWEVOKSBBQ1BJOiBTU0RUIEFDN0FDMDE4LCAzNjlDRSAocjIgIElOVEVMICAgIENwdVBt
ICAgICA0MDAwIElOVEwgMjAwOTExMTIpDQooWEVOKSBBQ1BJOiBTTElDIEFDN0U5QzE4LCAwMTc2
IChyMyBERUxMICAgIENCWDMgICAgIDYyMjIwMDQgTVNGVCAgICAxMDAxMykNCihYRU4pIEFDUEk6
IERNQVIgQUM3RUJGMTgsIDAwRDggKHIxIEEgTSBJICAgT0VNRE1BUiAgICAgICAgMSBJTlRMICAg
ICAgICAxKQ0KKFhFTikgU3lzdGVtIFJBTTogMzI3MjVNQiAoMzM1MTExMDhrQikNCihYRU4pIFNS
QVQ6IFBYTSAwIC0+IEFQSUMgMCAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMg
MiAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNCAtPiBOb2RlIDANCihYRU4p
IFNSQVQ6IFBYTSAwIC0+IEFQSUMgNiAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAxIC0+IEFQ
SUMgMzIgLT4gTm9kZSAxDQooWEVOKSBTUkFUOiBQWE0gMSAtPiBBUElDIDM0IC0+IE5vZGUgMQ0K
KFhFTikgU1JBVDogUFhNIDEgLT4gQVBJQyAzNiAtPiBOb2RlIDENCihYRU4pIFNSQVQ6IFBYTSAx
IC0+IEFQSUMgMzggLT4gTm9kZSAxDQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMC1iMDAwMDAw
MA0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMDAwMC00NTAwMDAwMDANCihYRU4pIFNS
QVQ6IE5vZGUgMSBQWE0gMSA0NTAwMDAwMDAtODUwMDAwMDAwDQooWEVOKSBOVU1BOiBBbGxvY2F0
ZWQgbWVtbm9kZW1hcCBmcm9tIDg0ZDYyZDAwMCAtIDg0ZDYyZTAwMA0KKFhFTikgTlVNQTogVXNp
bmcgMTYgZm9yIHRoZSBoYXNoIHNoaWZ0Lg0KKFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQg
RE1BIHdpZHRoIDMyIGJpdHMNCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAwMDBmMTllMA0K
KFhFTikgRE1JIDIuNiBwcmVzZW50Lg0KKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdA0K
KFhFTikgQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg0MDgNCihYRU4pIEFDUEk6IFNMRUVQIElO
Rk86IHBtMXhfY250WzE6NDA0LDE6MF0sIHBtMXhfZXZ0WzE6NDAwLDE6MF0NCihYRU4pIEFDUEk6
IDMyLzY0WCBGQUNTIGFkZHJlc3MgbWlzbWF0Y2ggaW4gRkFEVCAtIGFjN2Y4ZjQwLzAwMDAwMDAw
YWM3ZWNmNDAsIHVzaW5nIDMyDQooWEVOKSBBQ1BJOiAgICAgICAgICAgICB3YWtldXBfdmVjW2Fj
N2Y4ZjRjXSwgdmVjX3NpemVbMjBdDQooWEVOKSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhm
ZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0g
ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMCA2OjEzIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikg
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNCihYRU4p
IFByb2Nlc3NvciAjMiA2OjEzIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNCA2
OjEzIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFw
aWNfaWRbMHgwNl0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNiA2OjEzIEFQSUMgdmVyc2lv
biAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgyMF0gZW5h
YmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMzIgNjoxMyBBUElDIHZlcnNpb24gMjENCihYRU4pIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MjJdIGVuYWJsZWQpDQooWEVOKSBQ
cm9jZXNzb3IgIzM0IDY6MTMgQVBJQyB2ZXJzaW9uIDIxDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDA3XSBsYXBpY19pZFsweDI0XSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMzNiA2
OjEzIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOF0gbGFw
aWNfaWRbMHgyNl0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMzggNjoxMyBBUElDIHZlcnNp
b24gMjENCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDldIGxhcGljX2lkWzB4MDhdIGRp
c2FibGVkKQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwYV0gbGFwaWNfaWRbMHgwOV0g
ZGlzYWJsZWQpDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBiXSBsYXBpY19pZFsweDBh
XSBkaXNhYmxlZCkNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MGNdIGxhcGljX2lkWzB4
MGJdIGRpc2FibGVkKQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwZF0gbGFwaWNfaWRb
MHgwY10gZGlzYWJsZWQpDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBlXSBsYXBpY19p
ZFsweDBkXSBkaXNhYmxlZCkNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MGZdIGxhcGlj
X2lkWzB4MGVdIGRpc2FibGVkKQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxMF0gbGFw
aWNfaWRbMHgwZl0gZGlzYWJsZWQpDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDExXSBs
YXBpY19pZFsweDEwXSBkaXNhYmxlZCkNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MTJd
IGxhcGljX2lkWzB4MTFdIGRpc2FibGVkKQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgx
M10gbGFwaWNfaWRbMHgxMl0gZGlzYWJsZWQpDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDE0XSBsYXBpY19pZFsweDEzXSBkaXNhYmxlZCkNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MTVdIGxhcGljX2lkWzB4MTRdIGRpc2FibGVkKQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHgxNl0gbGFwaWNfaWRbMHgxNV0gZGlzYWJsZWQpDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDE3XSBsYXBpY19pZFsweDE2XSBkaXNhYmxlZCkNCihYRU4pIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4MThdIGxhcGljX2lkWzB4MTddIGRpc2FibGVkKQ0KKFhFTikgQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgxOV0gbGFwaWNfaWRbMHgxOF0gZGlzYWJsZWQpDQooWEVOKSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDFhXSBsYXBpY19pZFsweDE5XSBkaXNhYmxlZCkNCihYRU4pIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MWJdIGxhcGljX2lkWzB4MWFdIGRpc2FibGVkKQ0KKFhFTikgQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgxY10gbGFwaWNfaWRbMHgxYl0gZGlzYWJsZWQpDQooWEVOKSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDFkXSBsYXBpY19pZFsweDFjXSBkaXNhYmxlZCkNCihYRU4pIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MWVdIGxhcGljX2lkWzB4MWRdIGRpc2FibGVkKQ0KKFhFTikg
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxZl0gbGFwaWNfaWRbMHgxZV0gZGlzYWJsZWQpDQooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDIwXSBsYXBpY19pZFsweDFmXSBkaXNhYmxlZCkNCihY
RU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwMF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVsw
XSkNCihYRU4pIElPQVBJQ1swXTogYXBpY19pZCAwLCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4ZmVj
MDAwMDAsIEdTSSAwLTIzDQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDJdIGFkZHJlc3NbMHhm
ZWMzZjAwMF0gZ3NpX2Jhc2VbMjRdKQ0KKFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDIsIHZlcnNp
b24gMzIsIGFkZHJlc3MgMHhmZWMzZjAwMCwgR1NJIDI0LTQ3DQooWEVOKSBBQ1BJOiBJT0FQSUMg
KGlkWzB4MDNdIGFkZHJlc3NbMHhmZWM3ZjAwMF0gZ3NpX2Jhc2VbNDhdKQ0KKFhFTikgSU9BUElD
WzJdOiBhcGljX2lkIDMsIHZlcnNpb24gMzIsIGFkZHJlc3MgMHhmZWM3ZjAwMCwgR1NJIDQ4LTcx
DQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBk
ZmwgZGZsKQ0KKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxf
aXJxIDkgaGlnaCBsZXZlbCkNCihYRU4pIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NCihY
RU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElSUTkgdXNlZCBi
eSBvdmVycmlkZS4NCihYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2luZyAzIEkv
TyBBUElDcw0KKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MDg2YTcwMSBiYXNlOiAweGZlZDAwMDAw
DQooWEVOKSBbVlQtRF1kbWFyLmM6Nzg4OiBIb3N0IGFkZHJlc3Mgd2lkdGggNDYNCihYRU4pIFtW
VC1EXWRtYXIuYzo4MDI6IGZvdW5kIEFDUElfRE1BUl9EUkhEOg0KKFhFTikgW1ZULURdZG1hci5j
OjQ3MjogICBkbWFydS0+YWRkcmVzcyA9IGZiZmZlMDAwDQooWEVOKSBbVlQtRF1pb21tdS5jOjEx
NjI6IGRyaGQtPmFkZHJlc3MgPSBmYmZmZTAwMCBpb21tdS0+cmVnID0gZmZmZjgyYzAwMDIwMTAw
MA0KKFhFTikgW1ZULURdaW9tbXUuYzoxMTY0OiBjYXAgPSBkMjA3OGMxMDZmMDQ2MiBlY2FwID0g
ZjAyMGZhDQooWEVOKSBbVlQtRF1kbWFyLmM6Mzk3OiAgSU9BUElDOiAwMDAwOjIwOjA1LjQNCihY
RU4pIFtWVC1EXWRtYXIuYzozNTM6ICBicmlkZ2U6IDAwMDA6MjA6MDAuMCBzdGFydD0yMCBzZWM9
MjEgc3ViPTIxDQooWEVOKSBbVlQtRF1kbWFyLmM6MzUzOiAgYnJpZGdlOiAwMDAwOjIwOjAyLjAg
c3RhcnQ9MjAgc2VjPTIyIHN1Yj0yMg0KKFhFTikgW1ZULURdZG1hci5jOjM1MzogIGJyaWRnZTog
MDAwMDoyMDowMy4wIHN0YXJ0PTIwIHNlYz0yMyBzdWI9MjMNCihYRU4pIFtWVC1EXWRtYXIuYzo4
MDI6IGZvdW5kIEFDUElfRE1BUl9EUkhEOg0KKFhFTikgW1ZULURdZG1hci5jOjQ3MjogICBkbWFy
dS0+YWRkcmVzcyA9IGY3ZmZlMDAwDQooWEVOKSBbVlQtRF1pb21tdS5jOjExNjI6IGRyaGQtPmFk
ZHJlc3MgPSBmN2ZmZTAwMCBpb21tdS0+cmVnID0gZmZmZjgyYzAwMDIwMzAwMA0KKFhFTikgW1ZU
LURdaW9tbXUuYzoxMTY0OiBjYXAgPSBkMjA3OGMxMDZmMDQ2MiBlY2FwID0gZjAyMGZhDQooWEVO
KSBbVlQtRF1kbWFyLmM6Mzk3OiAgSU9BUElDOiAwMDAwOjAwOjFmLjcNCihYRU4pIFtWVC1EXWRt
YXIuYzozOTc6ICBJT0FQSUM6IDAwMDA6MDA6MDUuNA0KKFhFTikgW1ZULURdZG1hci5jOjM2MTog
IE1TSSBIUEVUOiAwMDAwOmYwOjBmLjANCihYRU4pIFtWVC1EXWRtYXIuYzo0ODY6ICAgZmxhZ3M6
IElOQ0xVREVfQUxMDQooWEVOKSBbVlQtRF1kbWFyLmM6ODA3OiBmb3VuZCBBQ1BJX0RNQVJfUk1S
UjoNCihYRU4pIFtWVC1EXWRtYXIuYzozODM6ICBlbmRwb2ludDogMDAwMDowMDoxZC4wDQooWEVO
KSBbVlQtRF1kbWFyLmM6MzgzOiAgZW5kcG9pbnQ6IDAwMDA6MDA6MWEuMA0KKFhFTikgW1ZULURd
ZG1hci5jOjY3NjogICBSTVJSIHJlZ2lvbjogYmFzZV9hZGRyIGFjNWRkMDAwIGVuZF9hZGRyZXNz
IGFjNWVjZmZmDQooWEVOKSBbVlQtRF1kbWFyLmM6ODE3OiBmb3VuZCBBQ1BJX0RNQVJfUkhTQToN
CihYRU4pIFtWVC1EXWRtYXIuYzo3NTc6ICAgcmhzYXUtPmFkZHJlc3M6IGZiZmZlMDAwIHJoc2F1
LT5wcm94aW1pdHlfZG9tYWluOiAwDQooWEVOKSBbVlQtRF1kbWFyLmM6ODE3OiBmb3VuZCBBQ1BJ
X0RNQVJfUkhTQToNCihYRU4pIFtWVC1EXWRtYXIuYzo3NTc6ICAgcmhzYXUtPmFkZHJlc3M6IGY3
ZmZlMDAwIHJoc2F1LT5wcm94aW1pdHlfZG9tYWluOiAwDQooWEVOKSBFUlNUIHRhYmxlIHdhcyBu
b3QgZm91bmQNCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBp
bmZvcm1hdGlvbg0KKFhFTikgU01QOiBBbGxvd2luZyAzMiBDUFVzICgyNCBob3RwbHVnIENQVXMp
DQooWEVOKSBJUlEgbGltaXRzOiA3MiBHU0ksIDE0ODAgTVNJL01TSS1YDQooWEVOKSBTd2l0Y2hl
ZCB0byBBUElDIGRyaXZlciB4MmFwaWNfY2x1c3Rlci4NCihYRU4pIFVzaW5nIHNjaGVkdWxlcjog
U01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkNCihYRU4pIERldGVjdGVkIDIzOTQuMzI0IE1I
eiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLg0KKFhFTikgeHN0YXRl
X2luaXQ6IHVzaW5nIGNudHh0X3NpemU6IDB4MzQwIGFuZCBzdGF0ZXM6IDB4Nw0KKFhFTikgbWNl
X2ludGVsLmM6NzE5OiBNQ0EgQ2FwYWJpbGl0eTogQkNBU1QgMSBTRVIgMSBDTUNJIDEgZmlyc3Ri
YW5rIDAgZXh0ZW5kZWQgTUNFIE1TUiAwDQooWEVOKSBJbnRlbCBtYWNoaW5lIGNoZWNrIHJlcG9y
dGluZyBlbmFibGVkDQooWEVOKSBhbHQgdGFibGUgZmZmZjgyZDA4MDJkYWY1MCAtPiBmZmZmODJk
MDgwMmRiZjcwDQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGIwMDAwMDAw
IHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIDNmDQooWEVOKSBQQ0k6IE1DRkcgYXJlYSBhdCBiMDAw
MDAwMCByZXNlcnZlZCBpbiBFODIwDQooWEVOKSBQQ0k6IFVzaW5nIE1DRkcgZm9yIHNlZ21lbnQg
MDAwMCBidXMgMDAtM2YNCihYRU4pIEludGVsIFZULWQgaW9tbXUgMCBzdXBwb3J0ZWQgcGFnZSBz
aXplczogNGtCLCAyTUIsIDFHQi4NCihYRU4pIEludGVsIFZULWQgaW9tbXUgMSBzdXBwb3J0ZWQg
cGFnZSBzaXplczogNGtCLCAyTUIsIDFHQi4NCihYRU4pIEludGVsIFZULWQgU25vb3AgQ29udHJv
bCBlbmFibGVkLg0KKFhFTikgSW50ZWwgVlQtZCBEb20wIERNQSBQYXNzdGhyb3VnaCBub3QgZW5h
YmxlZC4NCihYRU4pIEludGVsIFZULWQgUXVldWVkIEludmFsaWRhdGlvbiBlbmFibGVkLg0KKFhF
TikgSW50ZWwgVlQtZCBJbnRlcnJ1cHQgUmVtYXBwaW5nIGVuYWJsZWQuDQooWEVOKSBJbnRlbCBW
VC1kIFNoYXJlZCBFUFQgdGFibGVzIGVuYWJsZWQuDQooWEVOKSBJL08gdmlydHVhbGlzYXRpb24g
ZW5hYmxlZA0KKFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVOKSBJbnRlcnJ1cHQgcmVt
YXBwaW5nIGVuYWJsZWQNCihYRU4pIEVuYWJsZWQgZGlyZWN0ZWQgRU9JIHdpdGggaW9hcGljX2Fj
a19vbGQgb24hDQooWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2luZyBv
bGQgQUNLIG1ldGhvZA0KKFhFTikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIg
YXBpYzI9LTEgcGluMj0tMQ0KKFhFTikgVFNDIGRlYWRsaW5lIHRpbWVyIGVuYWJsZWQNCihYRU4p
IFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1IeiBIUEVUDQooWEVOKSBBbGxvY2F0ZWQgY29uc29s
ZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIG13YWl0LWlkbGU6IE1XQUlUIHN1YnN0YXRlczogMHgy
MTEyMA0KKFhFTikgbXdhaXQtaWRsZTogdjAuNCBtb2RlbCAweDJkDQooWEVOKSBtd2FpdC1pZGxl
OiBsYXBpY190aW1lcl9yZWxpYWJsZV9zdGF0ZXMgMHhmZmZmZmZmZg0KKFhFTikgVk1YOiBTdXBw
b3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSAgLSBBUElDIE1NSU8gYWNjZXNzIHZpcnR1
YWxpc2F0aW9uDQooWEVOKSAgLSBBUElDIFRQUiBzaGFkb3cNCihYRU4pICAtIEV4dGVuZGVkIFBh
Z2UgVGFibGVzIChFUFQpDQooWEVOKSAgLSBWaXJ0dWFsLVByb2Nlc3NvciBJZGVudGlmaWVycyAo
VlBJRCkNCihYRU4pICAtIFZpcnR1YWwgTk1JDQooWEVOKSAgLSBNU1IgZGlyZWN0LWFjY2VzcyBi
aXRtYXANCihYRU4pICAtIFVucmVzdHJpY3RlZCBHdWVzdA0KKFhFTikgSFZNOiBBU0lEcyBlbmFi
bGVkLg0KKFhFTikgSFZNOiBWTVggZW5hYmxlZA0KKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3Rl
ZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIEhWTTogSEFQIHBhZ2Ugc2l6ZXM6IDRrQiwg
Mk1CLCAxR0INCihYRU4pIEJyb3VnaHQgdXAgOCBDUFVzDQooWEVOKSBBQ1BJIHNsZWVwIG1vZGVz
OiBTMw0KKFhFTikgbWNoZWNrX3BvbGw6IE1hY2hpbmUgY2hlY2sgcG9sbGluZyB0aW1lciBzdGFy
dGVkLg0KKFhFTikgRG9tMCBoYXMgbWF4aW11bSA0NTYgUElSUXMNCihYRU4pICoqKiBMT0FESU5H
IERPTUFJTiAwICoqKg0KKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAw
MDAwIG1lbXN6PTB4N2NjMDAwDQooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0w
eDE4MDAwMDAgbWVtc3o9MHhjNjAwMA0KKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFk
ZHI9MHgxOGM2MDAwIG1lbXN6PTB4MTUwMDANCihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6
IHBhZGRyPTB4MThkYjAwMCBtZW1zej0weDJkMzAwMA0KKFhFTikgZWxmX3BhcnNlX2JpbmFyeTog
bWVtb3J5OiAweDEwMDAwMDAgLT4gMHgxYmFlMDAwDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6
IEdVRVNUX09TID0gImxpbnV4Ig0KKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJT
SU9OID0gIjIuNiINCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVOX1ZFUlNJT04gPSAieGVu
LTMuMCINCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgw
MDAwMDAwDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgxOGRi
MWYwDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZm
ZjgxMDAxMDAwDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJs
ZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdifHdyaXRhYmxlX2Rlc2NyaXB0b3JfdGFi
bGVzfGF1dG9fdHJhbnNsYXRlZF9waHlzbWFwfHN1cGVydmlzb3JfbW9kZV9rZXJuZWwiDQooWEVO
KSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVUFBPUlRFRF9GRUFUVVJFUyA9IDB4OTBkDQooWEVOKSBl
bGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyINCihYRU4pIGVsZl94ZW5fcGFyc2Vf
bm90ZTogTE9BREVSID0gImdlbmVyaWMiDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IHVua25v
d24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRf
Q0FOQ0VMID0gMHgxDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IE1PRF9TVEFSVF9QRk4gPSAw
eDENCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRfTE9XID0gMHhmZmZmODAwMDAw
MDAwMDAwDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MA0KKFhF
TikgZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6IGFkZHJlc3NlczoNCihYRU4pICAgICB2aXJ0X2Jh
c2UgICAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSAgICAgZWxmX3BhZGRyX29mZnNl
dCA9IDB4MA0KKFhFTikgICAgIHZpcnRfb2Zmc2V0ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAN
CihYRU4pICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwDQooWEVOKSAg
ICAgdmlydF9rZW5kICAgICAgICA9IDB4ZmZmZmZmZmY4MWJhZTAwMA0KKFhFTikgICAgIHZpcnRf
ZW50cnkgICAgICAgPSAweGZmZmZmZmZmODE4ZGIxZjANCihYRU4pICAgICBwMm1fYmFzZSAgICAg
ICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmDQooWEVOKSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNi
LCBjb21wYXQzMg0KKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAw
eDEwMDAwMDAgLT4gMHgxYmFlMDAwDQooWEVOKSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6
DQooWEVOKSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDQ0ODAwMDAwMC0+MDAwMDAwMDQ0YzAwMDAw
MCAoMTAyNjAxMSBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpDQooWEVOKSAgSW5pdC4gcmFtZGlzazog
MDAwMDAwMDg0ZTdkYjAwMC0+MDAwMDAwMDg0ZmZmZmMwMA0KKFhFTikgVklSVFVBTCBNRU1PUlkg
QVJSQU5HRU1FTlQ6DQooWEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZm
ZmZmZmY4MWJhZTAwMA0KKFhFTikgIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAwMDAwMDAwMDAtPjAw
MDAwMDAwMDAwMDAwMDANCihYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgxYmFlMDAwLT5m
ZmZmZmZmZjgyM2FlMDAwDQooWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4MjNhZTAwMC0+
ZmZmZmZmZmY4MjNhZjRiNA0KKFhFTikgIFBhZ2UgdGFibGVzOiAgIGZmZmZmZmZmODIzYjAwMDAt
PmZmZmZmZmZmODIzYzcwMDANCihYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgyM2M3MDAw
LT5mZmZmZmZmZjgyM2M4MDAwDQooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAw
MC0+ZmZmZmZmZmY4MjgwMDAwMA0KKFhFTikgIEVOVFJZIEFERFJFU1M6IGZmZmZmZmZmODE4ZGIx
ZjANCihYRU4pIERvbTAgaGFzIG1heGltdW0gMiBWQ1BVcw0KKFhFTikgZWxmX2xvYWRfYmluYXJ5
OiBwaGRyIDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MTdjYzAwMA0KKFhF
TikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDEgYXQgMHhmZmZmZmZmZjgxODAwMDAwIC0+IDB4ZmZm
ZmZmZmY4MThjNjAwMA0KKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZm
ZjgxOGM2MDAwIC0+IDB4ZmZmZmZmZmY4MThkYjAwMA0KKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBw
aGRyIDMgYXQgMHhmZmZmZmZmZjgxOGRiMDAwIC0+IDB4ZmZmZmZmZmY4MWEzMjAwMA0KKFhFTikg
W1ZULURdaW9tbXUuYzoxNDU2OiBkMDpIb3N0YnJpZGdlOiBza2lwIDAwMDA6MDA6MDAuMCBtYXAN
CihYRU4pIE1hc2tlZCBVUiBzaWduYWxpbmcgb24gMDAwMDowMDowMC4wDQooWEVOKSBNYXNrZWQg
VVIgc2lnbmFsaW5nIG9uIDAwMDA6MDA6MDEuMA0KKFhFTikgTWFza2VkIFVSIHNpZ25hbGluZyBv
biAwMDAwOjAwOjAxLjENCihYRU4pIE1hc2tlZCBVUiBzaWduYWxpbmcgb24gMDAwMDowMDowMi4w
DQooWEVOKSBNYXNrZWQgVVIgc2lnbmFsaW5nIG9uIDAwMDA6MDA6MDMuMA0KKFhFTikgW1ZULURd
aW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDowMDowNS4wDQooWEVOKSBNYXNrZWQgVlQt
ZCBlcnJvciBzaWduYWxpbmcgb24gMDAwMDowMDowNS4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0
NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjAwOjA1LjINCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4Mjog
ZDA6UENJOiBtYXAgMDAwMDowMDowNS40DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBD
STogbWFwIDAwMDA6MDA6MTYuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1h
cCAwMDAwOjAwOjE5LjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAw
MDowMDoxYS4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjAw
OjFiLjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDowMDoxZC4w
DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6MDA6MWYuMA0KKFhF
TikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjAwOjFmLjINCihYRU4pIFtW
VC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDowMDoxZi4zDQooWEVOKSBbVlQtRF1p
b21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjAzOjAwLjANCihYRU4pIFtWVC1EXWlvbW11
LmM6MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6MDM6MDAuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzox
NDcwOiBkMDpQQ0llOiBtYXAgMDAwMDowNTowMC4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6
IGQwOlBDSWU6IG1hcCAwMDAwOjA1OjAwLjMNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6
UENJZTogbWFwIDAwMDA6MDc6MDAuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6
IG1hcCAwMDAwOjFmOjA4LjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6UENJZTogbWFw
IDAwMDA6MWY6MDguMw0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAw
MDoxZjowOC40DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6MWY6
MDkuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDoxZjowOS4z
DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjFmOjA5LjQNCihY
RU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDoxZjowYS4wDQooWEVOKSBb
VlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6MWY6MGEuMQ0KKFhFTikgW1ZULURd
aW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjFmOjBhLjINCihYRU4pIFtWVC1EXWlvbW11
LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDoxZjowYS4zDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0
ODI6IGQwOlBDSTogbWFwIDAwMDA6MWY6MGIuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBk
MDpQQ0k6IG1hcCAwMDAwOjFmOjBiLjMNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJ
OiBtYXAgMDAwMDoxZjowYy4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFw
IDAwMDA6MWY6MGMuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAw
OjFmOjBjLjYNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDoxZjow
Yy43DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6MWY6MGQuMA0K
KFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjFmOjBkLjENCihYRU4p
IFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDoxZjowZC42DQooWEVOKSBbVlQt
RF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6MWY6MGUuMA0KKFhFTikgW1ZULURdaW9t
bXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjFmOjBlLjENCihYRU4pIFtWVC1EXWlvbW11LmM6
MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6MWY6MGYuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcw
OiBkMDpQQ0llOiBtYXAgMDAwMDoxZjowZi4xDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQw
OlBDSWU6IG1hcCAwMDAwOjFmOjBmLjINCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6UENJ
ZTogbWFwIDAwMDA6MWY6MGYuMw0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBt
YXAgMDAwMDoxZjowZi40DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAw
MDAwOjFmOjBmLjUNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDox
ZjowZi42DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjFmOjEw
LjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6MWY6MTAuMQ0K
KFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDoxZjoxMC4yDQooWEVO
KSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjFmOjEwLjMNCihYRU4pIFtW
VC1EXWlvbW11LmM6MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6MWY6MTAuNA0KKFhFTikgW1ZULURd
aW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDoxZjoxMC41DQooWEVOKSBbVlQtRF1pb21t
dS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjFmOjEwLjYNCihYRU4pIFtWVC1EXWlvbW11LmM6
MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6MWY6MTAuNw0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgy
OiBkMDpQQ0k6IG1hcCAwMDAwOjFmOjExLjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6
UENJOiBtYXAgMDAwMDoxZjoxMy4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTog
bWFwIDAwMDA6MWY6MTMuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAw
MDAwOjFmOjEzLjQNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDox
ZjoxMy41DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6MWY6MTMu
Ng0KKFhFTikgTWFza2VkIFVSIHNpZ25hbGluZyBvbiAwMDAwOjIwOjAwLjANCihYRU4pIE1hc2tl
ZCBVUiBzaWduYWxpbmcgb24gMDAwMDoyMDowMi4wDQooWEVOKSBNYXNrZWQgVVIgc2lnbmFsaW5n
IG9uIDAwMDA6MjA6MDMuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAg
MDAwMDoyMDowNS4wDQooWEVOKSBNYXNrZWQgVlQtZCBlcnJvciBzaWduYWxpbmcgb24gMDAwMDoy
MDowNS4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjIwOjA1
LjINCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDoyMDowNS40DQoo
WEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6M2Y6MDguMA0KKFhFTikg
W1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDozZjowOC4zDQooWEVOKSBbVlQt
RF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjNmOjA4LjQNCihYRU4pIFtWVC1EXWlv
bW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDozZjowOS4wDQooWEVOKSBbVlQtRF1pb21tdS5j
OjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjNmOjA5LjMNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3
MDogZDA6UENJZTogbWFwIDAwMDA6M2Y6MDkuNA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBk
MDpQQ0k6IG1hcCAwMDAwOjNmOjBhLjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJ
OiBtYXAgMDAwMDozZjowYS4xDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFw
IDAwMDA6M2Y6MGEuMg0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAw
OjNmOjBhLjMNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDozZjow
Yi4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6M2Y6MGIuMw0K
KFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjNmOjBjLjANCihYRU4p
IFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDozZjowYy4xDQooWEVOKSBbVlQt
RF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6M2Y6MGMuNg0KKFhFTikgW1ZULURdaW9t
bXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjNmOjBjLjcNCihYRU4pIFtWVC1EXWlvbW11LmM6
MTQ4MjogZDA6UENJOiBtYXAgMDAwMDozZjowZC4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6
IGQwOlBDSTogbWFwIDAwMDA6M2Y6MGQuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQ
Q0k6IG1hcCAwMDAwOjNmOjBkLjYNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBt
YXAgMDAwMDozZjowZS4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAw
MDA6M2Y6MGUuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDoz
ZjowZi4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjNmOjBm
LjENCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6M2Y6MGYuMg0K
KFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDozZjowZi4zDQooWEVO
KSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjNmOjBmLjQNCihYRU4pIFtW
VC1EXWlvbW11LmM6MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6M2Y6MGYuNQ0KKFhFTikgW1ZULURd
aW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjNmOjBmLjYNCihYRU4pIFtWVC1EXWlvbW11
LmM6MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6M2Y6MTAuMA0KKFhFTikgW1ZULURdaW9tbXUuYzox
NDcwOiBkMDpQQ0llOiBtYXAgMDAwMDozZjoxMC4xDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6
IGQwOlBDSWU6IG1hcCAwMDAwOjNmOjEwLjINCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6
UENJZTogbWFwIDAwMDA6M2Y6MTAuMw0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0ll
OiBtYXAgMDAwMDozZjoxMC40DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1h
cCAwMDAwOjNmOjEwLjUNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6UENJZTogbWFwIDAw
MDA6M2Y6MTAuNg0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDoz
ZjoxMC43DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6M2Y6MTEu
MA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjNmOjEzLjANCihY
RU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDozZjoxMy4xDQooWEVOKSBb
VlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6M2Y6MTMuNA0KKFhFTikgW1ZULURd
aW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjNmOjEzLjUNCihYRU4pIFtWVC1EXWlvbW11
LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDozZjoxMy42DQooWEVOKSBbVlQtRF1pb21tdS5jOjcz
OTogaW9tbXVfZW5hYmxlX3RyYW5zbGF0aW9uOiBpb21tdS0+cmVnID0gZmZmZjgyYzAwMDIwMTAw
MA0KKFhFTikgW1ZULURdaW9tbXUuYzo3NDI6IFJlYWQgZG1hciByZWdpb24gZmZmZjgyYzAwMDIw
MTAwMA0KKFhFTikgW1ZULURdaW9tbXUuYzo3NTU6IFdyb3RlIGRtYXIgcmVnaW9uDQooWEVOKSBC
RUdJTiAtLS0tLS0tLS0tLS0tLS0tLSBkZWJ1ZyArPT09PT09PT09PT09PT09PT09PQ0KKFhFTikg
LS0tLSBwcmludF9pb21tdV9yZWdzIC0tLS0NCihYRU4pICBkcmhkLT5hZGRyZXNzID0gZmJmZmUw
MDANCihYRU4pICBWRVIgPSAxMA0KKFhFTikgIENBUCA9IGQyMDc4YzEwNmYwNDYyDQooWEVOKSAg
bl9mYXVsdF9yZWcgPSA4DQooWEVOKSAgZmF1bHRfcmVjb3JkaW5nX29mZnNldCA9IDEwMA0KKFhF
TikgIGZhdWx0X3JlY29yZGluZ19yZWdfbCA9IDANCihYRU4pICBmYXVsdF9yZWNvcmRpbmdfcmVn
X2ggPSAwDQooWEVOKSAgRUNBUCA9IGYwMjBmYQ0KKFhFTikgIEdDTUQgPSA4NjAwMDAwMA0KKFhF
TikgIEdTVFMgPSBjNzAwMDAwMA0KKFhFTikgIFJUQUREUiA9IDQ0ZmZmNDAwMA0KKFhFTikgIEND
TUQgPSAwDQooWEVOKSAgRlNUUyA9IDANCihYRU4pICBGRUNUTCA9IDANCihYRU4pICBGRURBVEEg
PSA0MTI4DQooWEVOKSAgRkVBRERSID0gZmVlMDEwMGMNCihYRU4pICBGRVVBRERSID0gMA0KKFhF
TikgRU5EIC0tLS0tLS0tLS0tLS0tLS0tIGRlYnVnICs9PT09PT09PT09PT09PT09PT09DQooWEVO
KSBbVlQtRF1pb21tdS5jOjczOTogaW9tbXVfZW5hYmxlX3RyYW5zbGF0aW9uOiBpb21tdS0+cmVn
ID0gZmZmZjgyYzAwMDIwMzAwMA0KKFhFTikgW1ZULURdaW9tbXUuYzo3NDI6IFJlYWQgZG1hciBy
ZWdpb24gZmZmZjgyYzAwMDIwMzAwMA0K
--__141925789570321276abhmp0016.oracle.com
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--__141925789570321276abhmp0016.oracle.com--


From xen-devel-bounces@lists.xen.org Mon Dec 22 14:43:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 14: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 1Y34Bs-0003B0-Sv; Mon, 22 Dec 2014 14:42:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <elena.ufimtseva@oracle.com>) id 1Y33oT-0002V3-Nq
	for xen-devel@lists.xen.org; Mon, 22 Dec 2014 14:18:22 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	BE/BE-09842-C2828945; Mon, 22 Dec 2014 14:18:20 +0000
X-Env-Sender: elena.ufimtseva@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419257898!17268492!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8496 invoked from network); 22 Dec 2014 14:18:19 -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; 22 Dec 2014 14:18:19 -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 sBMEIHXN012158
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Mon, 22 Dec 2014 14:18:18 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
	sBMEIG7v022594
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <xen-devel@lists.xen.org>; Mon, 22 Dec 2014 14:18:17 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
	sBMEIGu7022562
	for <xen-devel@lists.xen.org>; Mon, 22 Dec 2014 14:18:16 GMT
MIME-Version: 1.0
Message-ID: <42e7aeac-499b-4f8b-b932-35636f340d50@default>
Date: Mon, 22 Dec 2014 06:18:15 -0800 (PST)
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
To: <xen-devel@lists.xen.org>
X-Mailer: Zimbra on Oracle Beehive
Content-Type: multipart/mixed;
	boundary="__141925789570321276abhmp0016.oracle.com"
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-Mailman-Approved-At: Mon, 22 Dec 2014 14:42:31 +0000
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: [Xen-devel] dom0 as pvh boot problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--__141925789570321276abhmp0016.oracle.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi

There is a problem with booting dom0 as pvh (xen-4.5rc3, kernel 3.18.0+).
After digging a bit into this it seems that the booting gets stuck upon ena=
bling second IOMMU by writing to DMAR_GCMD_REG (See the attaches debug log)=
.
The boot process passes this stage if second iommu was not enabled.
I tried multiple iommu options on boot, but it did not help.
There is no problem booting baremetal linux with IOMMU enabled.
The difference I have noticed its the version of microcode that is shown in=
 baremetal and Xen.
Baremetal linux shows microcode version as 0x710, Xen as 0x70d, not sure if=
 its relevant.

Any advise on how to address this is appreciated.

baremetal cpuinfo:

processor    : 7
vendor_id    : GenuineIntel
cpu family    : 6
model        : 45
model name    : Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz
stepping    : 7
microcode    : 0x710
cpu MHz        : 1200.000
cache size    : 10240 KB
physical id    : 1
siblings    : 4
core id        : 3
cpu cores    : 4
apicid        : 38
initial apicid    : 38
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmo=
v pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe=
1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology no=
nstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx e=
st tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadli=
ne_timer aes xsave avx lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow =
vnmi flexpriority ept vpid
bogomips    : 4789.44
clflush size    : 64
cache_alignment    : 64
address sizes    : 46 bits physical, 48 bits virtual
power management

--=20
Elena
--__141925789570321276abhmp0016.oracle.com
Content-Type: application/octet-stream; name="dom0pvh_xeon_e5"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="dom0pvh_xeon_e5"

IFhlbiA0LjUuMC1yYw0KKFhFTikgWGVuIHZlcnNpb24gNC41LjAtcmMgKHhlbmRldkApIChnY2Mg
KERlYmlhbiA0LjcuMi01KSA0LjcuMikgZGVidWc9eSBUdWUgRGVjICA5IDIyOjAzOjUxIEVTVCAy
MDE0DQooWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiBXZWQgRGVjIDMgMTA6MzE6MjIgMjAxNCAtMDUw
MCBnaXQ6M2E4MDk4NS1kaXJ0eQ0KKFhFTikgQ29uc29sZSBvdXRwdXQgaXMgc3luY2hyb25vdXMu
DQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEuOTktMjcrZGViN3UxDQooWEVOKSBDb21tYW5kIGxp
bmU6IGVhcmx5cHJpbnRrPXhlbiBkb20wcHZoPTEgZG9tMF9tZW09NDA5Nk0gbG9nbHZsPWRlYnVn
IGNvbTE9MTE1MjAwLDhuMSBjb25zb2xlPWNvbTEgaW9tbXU9ZGVidWcsdmVyYm9zZSBzeW5jX2Nv
bnNvbGUgZG9tMF9tYXhfdmNwdXM9MiBkb20wX3ZjcHVzX3Bpbg0KKFhFTikgVmlkZW8gaW5mb3Jt
YXRpb246DQooWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9udCA4eDE2DQooWEVOKSAg
VkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0aW1lOiAxIHNlY29uZHMNCihYRU4p
IERpc2MgaW5mb3JtYXRpb246DQooWEVOKSAgRm91bmQgMSBNQlIgc2lnbmF0dXJlcw0KKFhFTikg
IEZvdW5kIDEgRUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMNCihYRU4pIFhlbi1lODIwIFJBTSBt
YXA6DQooWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOGRjMDAgKHVzYWJsZSkN
CihYRU4pICAwMDAwMDAwMDAwMDhkYzAwIC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpDQoo
WEVOKSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQ0KKFhF
TikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMGFjMjI1MDAwICh1c2FibGUpDQooWEVOKSAg
MDAwMDAwMDBhYzIyNTAwMCAtIDAwMDAwMDAwYWMyNjkwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAw
MDAwMDAwYWMyNjkwMDAgLSAwMDAwMDAwMGFjNTgwMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAw
MDBhYzU4MDAwMCAtIDAwMDAwMDAwYWM1YTEwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAw
YWM1YTEwMDAgLSAwMDAwMDAwMGFjNWJjMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhYzVi
YzAwMCAtIDAwMDAwMDAwYWM1YmUwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwYWM1YmUw
MDAgLSAwMDAwMDAwMGFjNWJmMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhYzViZjAwMCAt
IDAwMDAwMDAwYWM1Y2IwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwYWM1Y2IwMDAgLSAw
MDAwMDAwMGFjNWRhMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhYzVkYTAwMCAtIDAwMDAw
MDAwYWM1ZmIwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwYWM1ZmIwMDAgLSAwMDAwMDAw
MGFjNmI2MDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhYzZiNjAwMCAtIDAwMDAwMDAwYWM3
ZmIwMDAgKEFDUEkgTlZTKQ0KKFhFTikgIDAwMDAwMDAwYWM3ZmIwMDAgLSAwMDAwMDAwMGFjODBm
MDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhYzgwZjAwMCAtIDAwMDAwMDAwYWM4MTAwMDAg
KEFDUEkgZGF0YSkNCihYRU4pICAwMDAwMDAwMGFjODEwMDAwIC0gMDAwMDAwMDBhYzgxMTAwMCAo
dXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwYWM4MTEwMDAgLSAwMDAwMDAwMGFjODEzMDAwIChBQ1BJ
IGRhdGEpDQooWEVOKSAgMDAwMDAwMDBhYzgxMzAwMCAtIDAwMDAwMDAwYWQ4MDAwMDAgKHVzYWJs
ZSkNCihYRU4pICAwMDAwMDAwMGIwMDAwMDAwIC0gMDAwMDAwMDBiNDAwMDAwMCAocmVzZXJ2ZWQp
DQooWEVOKSAgMDAwMDAwMDBmZWQyMDAwMCAtIDAwMDAwMDAwZmVkNDAwMDAgKHJlc2VydmVkKQ0K
KFhFTikgIDAwMDAwMDAwZmVkNTAwMDAgLSAwMDAwMDAwMGZlZDkwMDAwIChyZXNlcnZlZCkNCihY
RU4pICAwMDAwMDAwMGZmYTAwMDAwIC0gMDAwMDAwMDBmZmE0MDAwMCAocmVzZXJ2ZWQpDQooWEVO
KSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDA4NTAwMDAwMDAgKHVzYWJsZSkNCihYRU4pIEFD
UEk6IFJTRFAgMDAwRkUzMDAsIDAwMjQgKHIyIERFTEwgICkNCihYRU4pIEFDUEk6IFhTRFQgQUM4
MTFFMTgsIDAwODQgKHIxIERFTEwgICAgQ0JYMyAgICAgNjIyMjAwNCBNU0ZUICAgIDEwMDEzKQ0K
KFhFTikgQUNQSTogRkFDUCBBQzdFQkMxOCwgMDBGNCAocjQgREVMTCAgICBDQlgzICAgICA2MjIy
MDA0IE1TRlQgICAgMTAwMTMpDQooWEVOKSBBQ1BJOiBEU0RUIEFDN0E1MDE4LCA2MzczIChyMSBE
RUxMICAgIENCWDMgICAgICAgICAgIDAgSU5UTCAyMDA5MTExMikNCihYRU4pIEFDUEk6IEZBQ1Mg
QUM3RUNGNDAsIDAwNDANCihYRU4pIEFDUEk6IEFQSUMgQUM4MEZFMTgsIDAxNjQgKHIyIERFTEwg
ICAgQ0JYMyAgICAgNjIyMjAwNCBNU0ZUICAgIDEwMDEzKQ0KKFhFTikgQUNQSTogTUNGRyBBQzdG
OUQxOCwgMDAzQyAocjEgQSBNIEkgIE9FTU1DRkcuICA2MjIyMDA0IE1TRlQgICAgICAgOTcpDQoo
WEVOKSBBQ1BJOiBUQ1BBIEFDN0Y5Qzk4LCAwMDMyIChyMiAgICAgICAgICAgICAgICAgICAgICAg
IDAgICAgICAgICAgICAgMCkNCihYRU4pIEFDUEk6IFNTRFQgQUM3RUFBOTgsIDAzMDYgKHIxIERF
TExUUCAgICAgIFRQTSAgICAgMzAwMCBJTlRMIDIwMDkxMTEyKQ0KKFhFTikgQUNQSTogU1JBVCBB
QzdFQTcxOCwgMDMzMCAocjEgQSBNIEkgIEFNSSBTUkFUICAgICAgICAwIEFNSS4gICAgICAgIDAp
DQooWEVOKSBBQ1BJOiBTTElUIEFDN0Y5QzE4LCAwMDMwIChyMSBBIE0gSSAgQU1JIFNMSVQgICAg
ICAgIDAgQU1JLiAgICAgICAgMCkNCihYRU4pIEFDUEk6IEhQRVQgQUM3RjlCOTgsIDAwMzggKHIx
IEEgTSBJICAgUENISFBFVCAgNjIyMjAwNCBBTUkuICAgICAgICAzKQ0KKFhFTikgQUNQSTogQk9P
VCBBQzdGOUIxOCwgMDAyOCAocjEgREVMTCAgIENCWDMgICAgICA2MjIyMDA0IEFNSSAgICAgMTAw
MTMpDQooWEVOKSBBQ1BJOiBTU0RUIEFDN0FDMDE4LCAzNjlDRSAocjIgIElOVEVMICAgIENwdVBt
ICAgICA0MDAwIElOVEwgMjAwOTExMTIpDQooWEVOKSBBQ1BJOiBTTElDIEFDN0U5QzE4LCAwMTc2
IChyMyBERUxMICAgIENCWDMgICAgIDYyMjIwMDQgTVNGVCAgICAxMDAxMykNCihYRU4pIEFDUEk6
IERNQVIgQUM3RUJGMTgsIDAwRDggKHIxIEEgTSBJICAgT0VNRE1BUiAgICAgICAgMSBJTlRMICAg
ICAgICAxKQ0KKFhFTikgU3lzdGVtIFJBTTogMzI3MjVNQiAoMzM1MTExMDhrQikNCihYRU4pIFNS
QVQ6IFBYTSAwIC0+IEFQSUMgMCAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMg
MiAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNCAtPiBOb2RlIDANCihYRU4p
IFNSQVQ6IFBYTSAwIC0+IEFQSUMgNiAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAxIC0+IEFQ
SUMgMzIgLT4gTm9kZSAxDQooWEVOKSBTUkFUOiBQWE0gMSAtPiBBUElDIDM0IC0+IE5vZGUgMQ0K
KFhFTikgU1JBVDogUFhNIDEgLT4gQVBJQyAzNiAtPiBOb2RlIDENCihYRU4pIFNSQVQ6IFBYTSAx
IC0+IEFQSUMgMzggLT4gTm9kZSAxDQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMC1iMDAwMDAw
MA0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMDAwMC00NTAwMDAwMDANCihYRU4pIFNS
QVQ6IE5vZGUgMSBQWE0gMSA0NTAwMDAwMDAtODUwMDAwMDAwDQooWEVOKSBOVU1BOiBBbGxvY2F0
ZWQgbWVtbm9kZW1hcCBmcm9tIDg0ZDYyZDAwMCAtIDg0ZDYyZTAwMA0KKFhFTikgTlVNQTogVXNp
bmcgMTYgZm9yIHRoZSBoYXNoIHNoaWZ0Lg0KKFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQg
RE1BIHdpZHRoIDMyIGJpdHMNCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAwMDBmMTllMA0K
KFhFTikgRE1JIDIuNiBwcmVzZW50Lg0KKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdA0K
KFhFTikgQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg0MDgNCihYRU4pIEFDUEk6IFNMRUVQIElO
Rk86IHBtMXhfY250WzE6NDA0LDE6MF0sIHBtMXhfZXZ0WzE6NDAwLDE6MF0NCihYRU4pIEFDUEk6
IDMyLzY0WCBGQUNTIGFkZHJlc3MgbWlzbWF0Y2ggaW4gRkFEVCAtIGFjN2Y4ZjQwLzAwMDAwMDAw
YWM3ZWNmNDAsIHVzaW5nIDMyDQooWEVOKSBBQ1BJOiAgICAgICAgICAgICB3YWtldXBfdmVjW2Fj
N2Y4ZjRjXSwgdmVjX3NpemVbMjBdDQooWEVOKSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhm
ZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0g
ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMCA2OjEzIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikg
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNCihYRU4p
IFByb2Nlc3NvciAjMiA2OjEzIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNCA2
OjEzIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFw
aWNfaWRbMHgwNl0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNiA2OjEzIEFQSUMgdmVyc2lv
biAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgyMF0gZW5h
YmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMzIgNjoxMyBBUElDIHZlcnNpb24gMjENCihYRU4pIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MjJdIGVuYWJsZWQpDQooWEVOKSBQ
cm9jZXNzb3IgIzM0IDY6MTMgQVBJQyB2ZXJzaW9uIDIxDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDA3XSBsYXBpY19pZFsweDI0XSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMzNiA2
OjEzIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOF0gbGFw
aWNfaWRbMHgyNl0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMzggNjoxMyBBUElDIHZlcnNp
b24gMjENCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDldIGxhcGljX2lkWzB4MDhdIGRp
c2FibGVkKQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwYV0gbGFwaWNfaWRbMHgwOV0g
ZGlzYWJsZWQpDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBiXSBsYXBpY19pZFsweDBh
XSBkaXNhYmxlZCkNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MGNdIGxhcGljX2lkWzB4
MGJdIGRpc2FibGVkKQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwZF0gbGFwaWNfaWRb
MHgwY10gZGlzYWJsZWQpDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBlXSBsYXBpY19p
ZFsweDBkXSBkaXNhYmxlZCkNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MGZdIGxhcGlj
X2lkWzB4MGVdIGRpc2FibGVkKQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxMF0gbGFw
aWNfaWRbMHgwZl0gZGlzYWJsZWQpDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDExXSBs
YXBpY19pZFsweDEwXSBkaXNhYmxlZCkNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MTJd
IGxhcGljX2lkWzB4MTFdIGRpc2FibGVkKQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgx
M10gbGFwaWNfaWRbMHgxMl0gZGlzYWJsZWQpDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw
eDE0XSBsYXBpY19pZFsweDEzXSBkaXNhYmxlZCkNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MTVdIGxhcGljX2lkWzB4MTRdIGRpc2FibGVkKQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHgxNl0gbGFwaWNfaWRbMHgxNV0gZGlzYWJsZWQpDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDE3XSBsYXBpY19pZFsweDE2XSBkaXNhYmxlZCkNCihYRU4pIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4MThdIGxhcGljX2lkWzB4MTddIGRpc2FibGVkKQ0KKFhFTikgQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgxOV0gbGFwaWNfaWRbMHgxOF0gZGlzYWJsZWQpDQooWEVOKSBBQ1BJOiBMQVBJ
QyAoYWNwaV9pZFsweDFhXSBsYXBpY19pZFsweDE5XSBkaXNhYmxlZCkNCihYRU4pIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MWJdIGxhcGljX2lkWzB4MWFdIGRpc2FibGVkKQ0KKFhFTikgQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgxY10gbGFwaWNfaWRbMHgxYl0gZGlzYWJsZWQpDQooWEVOKSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDFkXSBsYXBpY19pZFsweDFjXSBkaXNhYmxlZCkNCihYRU4pIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MWVdIGxhcGljX2lkWzB4MWRdIGRpc2FibGVkKQ0KKFhFTikg
QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgxZl0gbGFwaWNfaWRbMHgxZV0gZGlzYWJsZWQpDQooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDIwXSBsYXBpY19pZFsweDFmXSBkaXNhYmxlZCkNCihY
RU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwMF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVsw
XSkNCihYRU4pIElPQVBJQ1swXTogYXBpY19pZCAwLCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4ZmVj
MDAwMDAsIEdTSSAwLTIzDQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDJdIGFkZHJlc3NbMHhm
ZWMzZjAwMF0gZ3NpX2Jhc2VbMjRdKQ0KKFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDIsIHZlcnNp
b24gMzIsIGFkZHJlc3MgMHhmZWMzZjAwMCwgR1NJIDI0LTQ3DQooWEVOKSBBQ1BJOiBJT0FQSUMg
KGlkWzB4MDNdIGFkZHJlc3NbMHhmZWM3ZjAwMF0gZ3NpX2Jhc2VbNDhdKQ0KKFhFTikgSU9BUElD
WzJdOiBhcGljX2lkIDMsIHZlcnNpb24gMzIsIGFkZHJlc3MgMHhmZWM3ZjAwMCwgR1NJIDQ4LTcx
DQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBk
ZmwgZGZsKQ0KKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxf
aXJxIDkgaGlnaCBsZXZlbCkNCihYRU4pIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NCihY
RU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElSUTkgdXNlZCBi
eSBvdmVycmlkZS4NCihYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2luZyAzIEkv
TyBBUElDcw0KKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MDg2YTcwMSBiYXNlOiAweGZlZDAwMDAw
DQooWEVOKSBbVlQtRF1kbWFyLmM6Nzg4OiBIb3N0IGFkZHJlc3Mgd2lkdGggNDYNCihYRU4pIFtW
VC1EXWRtYXIuYzo4MDI6IGZvdW5kIEFDUElfRE1BUl9EUkhEOg0KKFhFTikgW1ZULURdZG1hci5j
OjQ3MjogICBkbWFydS0+YWRkcmVzcyA9IGZiZmZlMDAwDQooWEVOKSBbVlQtRF1pb21tdS5jOjEx
NjI6IGRyaGQtPmFkZHJlc3MgPSBmYmZmZTAwMCBpb21tdS0+cmVnID0gZmZmZjgyYzAwMDIwMTAw
MA0KKFhFTikgW1ZULURdaW9tbXUuYzoxMTY0OiBjYXAgPSBkMjA3OGMxMDZmMDQ2MiBlY2FwID0g
ZjAyMGZhDQooWEVOKSBbVlQtRF1kbWFyLmM6Mzk3OiAgSU9BUElDOiAwMDAwOjIwOjA1LjQNCihY
RU4pIFtWVC1EXWRtYXIuYzozNTM6ICBicmlkZ2U6IDAwMDA6MjA6MDAuMCBzdGFydD0yMCBzZWM9
MjEgc3ViPTIxDQooWEVOKSBbVlQtRF1kbWFyLmM6MzUzOiAgYnJpZGdlOiAwMDAwOjIwOjAyLjAg
c3RhcnQ9MjAgc2VjPTIyIHN1Yj0yMg0KKFhFTikgW1ZULURdZG1hci5jOjM1MzogIGJyaWRnZTog
MDAwMDoyMDowMy4wIHN0YXJ0PTIwIHNlYz0yMyBzdWI9MjMNCihYRU4pIFtWVC1EXWRtYXIuYzo4
MDI6IGZvdW5kIEFDUElfRE1BUl9EUkhEOg0KKFhFTikgW1ZULURdZG1hci5jOjQ3MjogICBkbWFy
dS0+YWRkcmVzcyA9IGY3ZmZlMDAwDQooWEVOKSBbVlQtRF1pb21tdS5jOjExNjI6IGRyaGQtPmFk
ZHJlc3MgPSBmN2ZmZTAwMCBpb21tdS0+cmVnID0gZmZmZjgyYzAwMDIwMzAwMA0KKFhFTikgW1ZU
LURdaW9tbXUuYzoxMTY0OiBjYXAgPSBkMjA3OGMxMDZmMDQ2MiBlY2FwID0gZjAyMGZhDQooWEVO
KSBbVlQtRF1kbWFyLmM6Mzk3OiAgSU9BUElDOiAwMDAwOjAwOjFmLjcNCihYRU4pIFtWVC1EXWRt
YXIuYzozOTc6ICBJT0FQSUM6IDAwMDA6MDA6MDUuNA0KKFhFTikgW1ZULURdZG1hci5jOjM2MTog
IE1TSSBIUEVUOiAwMDAwOmYwOjBmLjANCihYRU4pIFtWVC1EXWRtYXIuYzo0ODY6ICAgZmxhZ3M6
IElOQ0xVREVfQUxMDQooWEVOKSBbVlQtRF1kbWFyLmM6ODA3OiBmb3VuZCBBQ1BJX0RNQVJfUk1S
UjoNCihYRU4pIFtWVC1EXWRtYXIuYzozODM6ICBlbmRwb2ludDogMDAwMDowMDoxZC4wDQooWEVO
KSBbVlQtRF1kbWFyLmM6MzgzOiAgZW5kcG9pbnQ6IDAwMDA6MDA6MWEuMA0KKFhFTikgW1ZULURd
ZG1hci5jOjY3NjogICBSTVJSIHJlZ2lvbjogYmFzZV9hZGRyIGFjNWRkMDAwIGVuZF9hZGRyZXNz
IGFjNWVjZmZmDQooWEVOKSBbVlQtRF1kbWFyLmM6ODE3OiBmb3VuZCBBQ1BJX0RNQVJfUkhTQToN
CihYRU4pIFtWVC1EXWRtYXIuYzo3NTc6ICAgcmhzYXUtPmFkZHJlc3M6IGZiZmZlMDAwIHJoc2F1
LT5wcm94aW1pdHlfZG9tYWluOiAwDQooWEVOKSBbVlQtRF1kbWFyLmM6ODE3OiBmb3VuZCBBQ1BJ
X0RNQVJfUkhTQToNCihYRU4pIFtWVC1EXWRtYXIuYzo3NTc6ICAgcmhzYXUtPmFkZHJlc3M6IGY3
ZmZlMDAwIHJoc2F1LT5wcm94aW1pdHlfZG9tYWluOiAwDQooWEVOKSBFUlNUIHRhYmxlIHdhcyBu
b3QgZm91bmQNCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBp
bmZvcm1hdGlvbg0KKFhFTikgU01QOiBBbGxvd2luZyAzMiBDUFVzICgyNCBob3RwbHVnIENQVXMp
DQooWEVOKSBJUlEgbGltaXRzOiA3MiBHU0ksIDE0ODAgTVNJL01TSS1YDQooWEVOKSBTd2l0Y2hl
ZCB0byBBUElDIGRyaXZlciB4MmFwaWNfY2x1c3Rlci4NCihYRU4pIFVzaW5nIHNjaGVkdWxlcjog
U01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkNCihYRU4pIERldGVjdGVkIDIzOTQuMzI0IE1I
eiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLg0KKFhFTikgeHN0YXRl
X2luaXQ6IHVzaW5nIGNudHh0X3NpemU6IDB4MzQwIGFuZCBzdGF0ZXM6IDB4Nw0KKFhFTikgbWNl
X2ludGVsLmM6NzE5OiBNQ0EgQ2FwYWJpbGl0eTogQkNBU1QgMSBTRVIgMSBDTUNJIDEgZmlyc3Ri
YW5rIDAgZXh0ZW5kZWQgTUNFIE1TUiAwDQooWEVOKSBJbnRlbCBtYWNoaW5lIGNoZWNrIHJlcG9y
dGluZyBlbmFibGVkDQooWEVOKSBhbHQgdGFibGUgZmZmZjgyZDA4MDJkYWY1MCAtPiBmZmZmODJk
MDgwMmRiZjcwDQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGIwMDAwMDAw
IHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIDNmDQooWEVOKSBQQ0k6IE1DRkcgYXJlYSBhdCBiMDAw
MDAwMCByZXNlcnZlZCBpbiBFODIwDQooWEVOKSBQQ0k6IFVzaW5nIE1DRkcgZm9yIHNlZ21lbnQg
MDAwMCBidXMgMDAtM2YNCihYRU4pIEludGVsIFZULWQgaW9tbXUgMCBzdXBwb3J0ZWQgcGFnZSBz
aXplczogNGtCLCAyTUIsIDFHQi4NCihYRU4pIEludGVsIFZULWQgaW9tbXUgMSBzdXBwb3J0ZWQg
cGFnZSBzaXplczogNGtCLCAyTUIsIDFHQi4NCihYRU4pIEludGVsIFZULWQgU25vb3AgQ29udHJv
bCBlbmFibGVkLg0KKFhFTikgSW50ZWwgVlQtZCBEb20wIERNQSBQYXNzdGhyb3VnaCBub3QgZW5h
YmxlZC4NCihYRU4pIEludGVsIFZULWQgUXVldWVkIEludmFsaWRhdGlvbiBlbmFibGVkLg0KKFhF
TikgSW50ZWwgVlQtZCBJbnRlcnJ1cHQgUmVtYXBwaW5nIGVuYWJsZWQuDQooWEVOKSBJbnRlbCBW
VC1kIFNoYXJlZCBFUFQgdGFibGVzIGVuYWJsZWQuDQooWEVOKSBJL08gdmlydHVhbGlzYXRpb24g
ZW5hYmxlZA0KKFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVOKSBJbnRlcnJ1cHQgcmVt
YXBwaW5nIGVuYWJsZWQNCihYRU4pIEVuYWJsZWQgZGlyZWN0ZWQgRU9JIHdpdGggaW9hcGljX2Fj
a19vbGQgb24hDQooWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2luZyBv
bGQgQUNLIG1ldGhvZA0KKFhFTikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIg
YXBpYzI9LTEgcGluMj0tMQ0KKFhFTikgVFNDIGRlYWRsaW5lIHRpbWVyIGVuYWJsZWQNCihYRU4p
IFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1IeiBIUEVUDQooWEVOKSBBbGxvY2F0ZWQgY29uc29s
ZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIG13YWl0LWlkbGU6IE1XQUlUIHN1YnN0YXRlczogMHgy
MTEyMA0KKFhFTikgbXdhaXQtaWRsZTogdjAuNCBtb2RlbCAweDJkDQooWEVOKSBtd2FpdC1pZGxl
OiBsYXBpY190aW1lcl9yZWxpYWJsZV9zdGF0ZXMgMHhmZmZmZmZmZg0KKFhFTikgVk1YOiBTdXBw
b3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSAgLSBBUElDIE1NSU8gYWNjZXNzIHZpcnR1
YWxpc2F0aW9uDQooWEVOKSAgLSBBUElDIFRQUiBzaGFkb3cNCihYRU4pICAtIEV4dGVuZGVkIFBh
Z2UgVGFibGVzIChFUFQpDQooWEVOKSAgLSBWaXJ0dWFsLVByb2Nlc3NvciBJZGVudGlmaWVycyAo
VlBJRCkNCihYRU4pICAtIFZpcnR1YWwgTk1JDQooWEVOKSAgLSBNU1IgZGlyZWN0LWFjY2VzcyBi
aXRtYXANCihYRU4pICAtIFVucmVzdHJpY3RlZCBHdWVzdA0KKFhFTikgSFZNOiBBU0lEcyBlbmFi
bGVkLg0KKFhFTikgSFZNOiBWTVggZW5hYmxlZA0KKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3Rl
ZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIEhWTTogSEFQIHBhZ2Ugc2l6ZXM6IDRrQiwg
Mk1CLCAxR0INCihYRU4pIEJyb3VnaHQgdXAgOCBDUFVzDQooWEVOKSBBQ1BJIHNsZWVwIG1vZGVz
OiBTMw0KKFhFTikgbWNoZWNrX3BvbGw6IE1hY2hpbmUgY2hlY2sgcG9sbGluZyB0aW1lciBzdGFy
dGVkLg0KKFhFTikgRG9tMCBoYXMgbWF4aW11bSA0NTYgUElSUXMNCihYRU4pICoqKiBMT0FESU5H
IERPTUFJTiAwICoqKg0KKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAw
MDAwIG1lbXN6PTB4N2NjMDAwDQooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0w
eDE4MDAwMDAgbWVtc3o9MHhjNjAwMA0KKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFk
ZHI9MHgxOGM2MDAwIG1lbXN6PTB4MTUwMDANCihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6
IHBhZGRyPTB4MThkYjAwMCBtZW1zej0weDJkMzAwMA0KKFhFTikgZWxmX3BhcnNlX2JpbmFyeTog
bWVtb3J5OiAweDEwMDAwMDAgLT4gMHgxYmFlMDAwDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6
IEdVRVNUX09TID0gImxpbnV4Ig0KKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJT
SU9OID0gIjIuNiINCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVOX1ZFUlNJT04gPSAieGVu
LTMuMCINCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgw
MDAwMDAwDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgxOGRi
MWYwDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZm
ZjgxMDAxMDAwDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJs
ZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdifHdyaXRhYmxlX2Rlc2NyaXB0b3JfdGFi
bGVzfGF1dG9fdHJhbnNsYXRlZF9waHlzbWFwfHN1cGVydmlzb3JfbW9kZV9rZXJuZWwiDQooWEVO
KSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVUFBPUlRFRF9GRUFUVVJFUyA9IDB4OTBkDQooWEVOKSBl
bGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyINCihYRU4pIGVsZl94ZW5fcGFyc2Vf
bm90ZTogTE9BREVSID0gImdlbmVyaWMiDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IHVua25v
d24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRf
Q0FOQ0VMID0gMHgxDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IE1PRF9TVEFSVF9QRk4gPSAw
eDENCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRfTE9XID0gMHhmZmZmODAwMDAw
MDAwMDAwDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MA0KKFhF
TikgZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6IGFkZHJlc3NlczoNCihYRU4pICAgICB2aXJ0X2Jh
c2UgICAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSAgICAgZWxmX3BhZGRyX29mZnNl
dCA9IDB4MA0KKFhFTikgICAgIHZpcnRfb2Zmc2V0ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAN
CihYRU4pICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwDQooWEVOKSAg
ICAgdmlydF9rZW5kICAgICAgICA9IDB4ZmZmZmZmZmY4MWJhZTAwMA0KKFhFTikgICAgIHZpcnRf
ZW50cnkgICAgICAgPSAweGZmZmZmZmZmODE4ZGIxZjANCihYRU4pICAgICBwMm1fYmFzZSAgICAg
ICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmDQooWEVOKSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNi
LCBjb21wYXQzMg0KKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAw
eDEwMDAwMDAgLT4gMHgxYmFlMDAwDQooWEVOKSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6
DQooWEVOKSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDQ0ODAwMDAwMC0+MDAwMDAwMDQ0YzAwMDAw
MCAoMTAyNjAxMSBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpDQooWEVOKSAgSW5pdC4gcmFtZGlzazog
MDAwMDAwMDg0ZTdkYjAwMC0+MDAwMDAwMDg0ZmZmZmMwMA0KKFhFTikgVklSVFVBTCBNRU1PUlkg
QVJSQU5HRU1FTlQ6DQooWEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZm
ZmZmZmY4MWJhZTAwMA0KKFhFTikgIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAwMDAwMDAwMDAtPjAw
MDAwMDAwMDAwMDAwMDANCihYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgxYmFlMDAwLT5m
ZmZmZmZmZjgyM2FlMDAwDQooWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4MjNhZTAwMC0+
ZmZmZmZmZmY4MjNhZjRiNA0KKFhFTikgIFBhZ2UgdGFibGVzOiAgIGZmZmZmZmZmODIzYjAwMDAt
PmZmZmZmZmZmODIzYzcwMDANCihYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgyM2M3MDAw
LT5mZmZmZmZmZjgyM2M4MDAwDQooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAw
MC0+ZmZmZmZmZmY4MjgwMDAwMA0KKFhFTikgIEVOVFJZIEFERFJFU1M6IGZmZmZmZmZmODE4ZGIx
ZjANCihYRU4pIERvbTAgaGFzIG1heGltdW0gMiBWQ1BVcw0KKFhFTikgZWxmX2xvYWRfYmluYXJ5
OiBwaGRyIDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MTdjYzAwMA0KKFhF
TikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDEgYXQgMHhmZmZmZmZmZjgxODAwMDAwIC0+IDB4ZmZm
ZmZmZmY4MThjNjAwMA0KKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZm
ZjgxOGM2MDAwIC0+IDB4ZmZmZmZmZmY4MThkYjAwMA0KKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBw
aGRyIDMgYXQgMHhmZmZmZmZmZjgxOGRiMDAwIC0+IDB4ZmZmZmZmZmY4MWEzMjAwMA0KKFhFTikg
W1ZULURdaW9tbXUuYzoxNDU2OiBkMDpIb3N0YnJpZGdlOiBza2lwIDAwMDA6MDA6MDAuMCBtYXAN
CihYRU4pIE1hc2tlZCBVUiBzaWduYWxpbmcgb24gMDAwMDowMDowMC4wDQooWEVOKSBNYXNrZWQg
VVIgc2lnbmFsaW5nIG9uIDAwMDA6MDA6MDEuMA0KKFhFTikgTWFza2VkIFVSIHNpZ25hbGluZyBv
biAwMDAwOjAwOjAxLjENCihYRU4pIE1hc2tlZCBVUiBzaWduYWxpbmcgb24gMDAwMDowMDowMi4w
DQooWEVOKSBNYXNrZWQgVVIgc2lnbmFsaW5nIG9uIDAwMDA6MDA6MDMuMA0KKFhFTikgW1ZULURd
aW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDowMDowNS4wDQooWEVOKSBNYXNrZWQgVlQt
ZCBlcnJvciBzaWduYWxpbmcgb24gMDAwMDowMDowNS4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0
NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjAwOjA1LjINCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4Mjog
ZDA6UENJOiBtYXAgMDAwMDowMDowNS40DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBD
STogbWFwIDAwMDA6MDA6MTYuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1h
cCAwMDAwOjAwOjE5LjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAw
MDowMDoxYS4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjAw
OjFiLjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDowMDoxZC4w
DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6MDA6MWYuMA0KKFhF
TikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjAwOjFmLjINCihYRU4pIFtW
VC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDowMDoxZi4zDQooWEVOKSBbVlQtRF1p
b21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjAzOjAwLjANCihYRU4pIFtWVC1EXWlvbW11
LmM6MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6MDM6MDAuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzox
NDcwOiBkMDpQQ0llOiBtYXAgMDAwMDowNTowMC4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6
IGQwOlBDSWU6IG1hcCAwMDAwOjA1OjAwLjMNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6
UENJZTogbWFwIDAwMDA6MDc6MDAuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6
IG1hcCAwMDAwOjFmOjA4LjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6UENJZTogbWFw
IDAwMDA6MWY6MDguMw0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAw
MDoxZjowOC40DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6MWY6
MDkuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDoxZjowOS4z
DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjFmOjA5LjQNCihY
RU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDoxZjowYS4wDQooWEVOKSBb
VlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6MWY6MGEuMQ0KKFhFTikgW1ZULURd
aW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjFmOjBhLjINCihYRU4pIFtWVC1EXWlvbW11
LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDoxZjowYS4zDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0
ODI6IGQwOlBDSTogbWFwIDAwMDA6MWY6MGIuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBk
MDpQQ0k6IG1hcCAwMDAwOjFmOjBiLjMNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJ
OiBtYXAgMDAwMDoxZjowYy4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFw
IDAwMDA6MWY6MGMuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAw
OjFmOjBjLjYNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDoxZjow
Yy43DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6MWY6MGQuMA0K
KFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjFmOjBkLjENCihYRU4p
IFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDoxZjowZC42DQooWEVOKSBbVlQt
RF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6MWY6MGUuMA0KKFhFTikgW1ZULURdaW9t
bXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjFmOjBlLjENCihYRU4pIFtWVC1EXWlvbW11LmM6
MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6MWY6MGYuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcw
OiBkMDpQQ0llOiBtYXAgMDAwMDoxZjowZi4xDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQw
OlBDSWU6IG1hcCAwMDAwOjFmOjBmLjINCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6UENJ
ZTogbWFwIDAwMDA6MWY6MGYuMw0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBt
YXAgMDAwMDoxZjowZi40DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAw
MDAwOjFmOjBmLjUNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDox
ZjowZi42DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjFmOjEw
LjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6MWY6MTAuMQ0K
KFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDoxZjoxMC4yDQooWEVO
KSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjFmOjEwLjMNCihYRU4pIFtW
VC1EXWlvbW11LmM6MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6MWY6MTAuNA0KKFhFTikgW1ZULURd
aW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDoxZjoxMC41DQooWEVOKSBbVlQtRF1pb21t
dS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjFmOjEwLjYNCihYRU4pIFtWVC1EXWlvbW11LmM6
MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6MWY6MTAuNw0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgy
OiBkMDpQQ0k6IG1hcCAwMDAwOjFmOjExLjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6
UENJOiBtYXAgMDAwMDoxZjoxMy4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTog
bWFwIDAwMDA6MWY6MTMuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAw
MDAwOjFmOjEzLjQNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDox
ZjoxMy41DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6MWY6MTMu
Ng0KKFhFTikgTWFza2VkIFVSIHNpZ25hbGluZyBvbiAwMDAwOjIwOjAwLjANCihYRU4pIE1hc2tl
ZCBVUiBzaWduYWxpbmcgb24gMDAwMDoyMDowMi4wDQooWEVOKSBNYXNrZWQgVVIgc2lnbmFsaW5n
IG9uIDAwMDA6MjA6MDMuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAg
MDAwMDoyMDowNS4wDQooWEVOKSBNYXNrZWQgVlQtZCBlcnJvciBzaWduYWxpbmcgb24gMDAwMDoy
MDowNS4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjIwOjA1
LjINCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDoyMDowNS40DQoo
WEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6M2Y6MDguMA0KKFhFTikg
W1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDozZjowOC4zDQooWEVOKSBbVlQt
RF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjNmOjA4LjQNCihYRU4pIFtWVC1EXWlv
bW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDozZjowOS4wDQooWEVOKSBbVlQtRF1pb21tdS5j
OjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjNmOjA5LjMNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3
MDogZDA6UENJZTogbWFwIDAwMDA6M2Y6MDkuNA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBk
MDpQQ0k6IG1hcCAwMDAwOjNmOjBhLjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJ
OiBtYXAgMDAwMDozZjowYS4xDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFw
IDAwMDA6M2Y6MGEuMg0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAw
OjNmOjBhLjMNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDozZjow
Yi4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6M2Y6MGIuMw0K
KFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjNmOjBjLjANCihYRU4p
IFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDozZjowYy4xDQooWEVOKSBbVlQt
RF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6M2Y6MGMuNg0KKFhFTikgW1ZULURdaW9t
bXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjNmOjBjLjcNCihYRU4pIFtWVC1EXWlvbW11LmM6
MTQ4MjogZDA6UENJOiBtYXAgMDAwMDozZjowZC4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6
IGQwOlBDSTogbWFwIDAwMDA6M2Y6MGQuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQ
Q0k6IG1hcCAwMDAwOjNmOjBkLjYNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBt
YXAgMDAwMDozZjowZS4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAw
MDA6M2Y6MGUuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDoz
ZjowZi4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjNmOjBm
LjENCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6M2Y6MGYuMg0K
KFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDozZjowZi4zDQooWEVO
KSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1hcCAwMDAwOjNmOjBmLjQNCihYRU4pIFtW
VC1EXWlvbW11LmM6MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6M2Y6MGYuNQ0KKFhFTikgW1ZULURd
aW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjNmOjBmLjYNCihYRU4pIFtWVC1EXWlvbW11
LmM6MTQ3MDogZDA6UENJZTogbWFwIDAwMDA6M2Y6MTAuMA0KKFhFTikgW1ZULURdaW9tbXUuYzox
NDcwOiBkMDpQQ0llOiBtYXAgMDAwMDozZjoxMC4xDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6
IGQwOlBDSWU6IG1hcCAwMDAwOjNmOjEwLjINCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6
UENJZTogbWFwIDAwMDA6M2Y6MTAuMw0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0ll
OiBtYXAgMDAwMDozZjoxMC40DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NzA6IGQwOlBDSWU6IG1h
cCAwMDAwOjNmOjEwLjUNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ3MDogZDA6UENJZTogbWFwIDAw
MDA6M2Y6MTAuNg0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDcwOiBkMDpQQ0llOiBtYXAgMDAwMDoz
ZjoxMC43DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6M2Y6MTEu
MA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjNmOjEzLjANCihY
RU4pIFtWVC1EXWlvbW11LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDozZjoxMy4xDQooWEVOKSBb
VlQtRF1pb21tdS5jOjE0ODI6IGQwOlBDSTogbWFwIDAwMDA6M2Y6MTMuNA0KKFhFTikgW1ZULURd
aW9tbXUuYzoxNDgyOiBkMDpQQ0k6IG1hcCAwMDAwOjNmOjEzLjUNCihYRU4pIFtWVC1EXWlvbW11
LmM6MTQ4MjogZDA6UENJOiBtYXAgMDAwMDozZjoxMy42DQooWEVOKSBbVlQtRF1pb21tdS5jOjcz
OTogaW9tbXVfZW5hYmxlX3RyYW5zbGF0aW9uOiBpb21tdS0+cmVnID0gZmZmZjgyYzAwMDIwMTAw
MA0KKFhFTikgW1ZULURdaW9tbXUuYzo3NDI6IFJlYWQgZG1hciByZWdpb24gZmZmZjgyYzAwMDIw
MTAwMA0KKFhFTikgW1ZULURdaW9tbXUuYzo3NTU6IFdyb3RlIGRtYXIgcmVnaW9uDQooWEVOKSBC
RUdJTiAtLS0tLS0tLS0tLS0tLS0tLSBkZWJ1ZyArPT09PT09PT09PT09PT09PT09PQ0KKFhFTikg
LS0tLSBwcmludF9pb21tdV9yZWdzIC0tLS0NCihYRU4pICBkcmhkLT5hZGRyZXNzID0gZmJmZmUw
MDANCihYRU4pICBWRVIgPSAxMA0KKFhFTikgIENBUCA9IGQyMDc4YzEwNmYwNDYyDQooWEVOKSAg
bl9mYXVsdF9yZWcgPSA4DQooWEVOKSAgZmF1bHRfcmVjb3JkaW5nX29mZnNldCA9IDEwMA0KKFhF
TikgIGZhdWx0X3JlY29yZGluZ19yZWdfbCA9IDANCihYRU4pICBmYXVsdF9yZWNvcmRpbmdfcmVn
X2ggPSAwDQooWEVOKSAgRUNBUCA9IGYwMjBmYQ0KKFhFTikgIEdDTUQgPSA4NjAwMDAwMA0KKFhF
TikgIEdTVFMgPSBjNzAwMDAwMA0KKFhFTikgIFJUQUREUiA9IDQ0ZmZmNDAwMA0KKFhFTikgIEND
TUQgPSAwDQooWEVOKSAgRlNUUyA9IDANCihYRU4pICBGRUNUTCA9IDANCihYRU4pICBGRURBVEEg
PSA0MTI4DQooWEVOKSAgRkVBRERSID0gZmVlMDEwMGMNCihYRU4pICBGRVVBRERSID0gMA0KKFhF
TikgRU5EIC0tLS0tLS0tLS0tLS0tLS0tIGRlYnVnICs9PT09PT09PT09PT09PT09PT09DQooWEVO
KSBbVlQtRF1pb21tdS5jOjczOTogaW9tbXVfZW5hYmxlX3RyYW5zbGF0aW9uOiBpb21tdS0+cmVn
ID0gZmZmZjgyYzAwMDIwMzAwMA0KKFhFTikgW1ZULURdaW9tbXUuYzo3NDI6IFJlYWQgZG1hciBy
ZWdpb24gZmZmZjgyYzAwMDIwMzAwMA0K
--__141925789570321276abhmp0016.oracle.com
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--__141925789570321276abhmp0016.oracle.com--


From xen-devel-bounces@lists.xen.org Mon Dec 22 14:51:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 14:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y34Jx-0003LS-4A; Mon, 22 Dec 2014 14:50: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 1Y34Jv-0003LN-5H
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 14:50:51 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	A4/79-25547-ACF28945; Mon, 22 Dec 2014 14:50:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1419259847!15202714!1
X-Originating-IP: [66.165.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 25842 invoked from network); 22 Dec 2014 14:50:49 -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;
	22 Dec 2014 14:50:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="206996277"
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.210.2; Mon, 22 Dec 2014 09:50: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 1Y34JR-0000CC-4H;
	Mon, 22 Dec 2014 14:50:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y34JQ-0003WE-UU;
	Mon, 22 Dec 2014 14:50:20 +0000
Date: Mon, 22 Dec 2014 14:50:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32571-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] 32571: 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 32571 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32571/

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 32542

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-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-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-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-qemuu-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-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                328b3b6c44c17d94df115ed1851f54a0bd59a471
baseline version:
 qemuu                b574f602680d41c4cf4a9c106e3e2244bed01cdd

------------------------------------------------------------
People who touched revisions under test:
  Eduardo Habkost <ehabkost@redhat.com>
  Gabriel Somlo <somlo@cmu.edu>
  Gerd Hoffmann <kraxel@redhat.com>
  Jason Wang <jasowang@redhat.com>
  Laurent Desnogues <laurent.desnogues@gmail.com>
  Markus Armbruster <armbru@redhat.com>
  Michael S. Tsirkin <mst@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefan Hajnoczi <stefanha@redhat.com>
  Wangkai (Kevin,C) <wangkai86@huawei.com>
  Wangkai <wangkai86@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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=328b3b6c44c17d94df115ed1851f54a0bd59a471
+ . 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 328b3b6c44c17d94df115ed1851f54a0bd59a471
+ branch=qemu-mainline
+ revision=328b3b6c44c17d94df115ed1851f54a0bd59a471
+ . 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 328b3b6c44c17d94df115ed1851f54a0bd59a471:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   b574f60..328b3b6  328b3b6c44c17d94df115ed1851f54a0bd59a471 -> 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 Dec 22 14:51:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 14:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y34Jx-0003LS-4A; Mon, 22 Dec 2014 14:50: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 1Y34Jv-0003LN-5H
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 14:50:51 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	A4/79-25547-ACF28945; Mon, 22 Dec 2014 14:50:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1419259847!15202714!1
X-Originating-IP: [66.165.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 25842 invoked from network); 22 Dec 2014 14:50:49 -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;
	22 Dec 2014 14:50:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="206996277"
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.210.2; Mon, 22 Dec 2014 09:50: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 1Y34JR-0000CC-4H;
	Mon, 22 Dec 2014 14:50:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y34JQ-0003WE-UU;
	Mon, 22 Dec 2014 14:50:20 +0000
Date: Mon, 22 Dec 2014 14:50:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32571-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] 32571: 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 32571 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32571/

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 32542

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-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-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-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-qemuu-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-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                328b3b6c44c17d94df115ed1851f54a0bd59a471
baseline version:
 qemuu                b574f602680d41c4cf4a9c106e3e2244bed01cdd

------------------------------------------------------------
People who touched revisions under test:
  Eduardo Habkost <ehabkost@redhat.com>
  Gabriel Somlo <somlo@cmu.edu>
  Gerd Hoffmann <kraxel@redhat.com>
  Jason Wang <jasowang@redhat.com>
  Laurent Desnogues <laurent.desnogues@gmail.com>
  Markus Armbruster <armbru@redhat.com>
  Michael S. Tsirkin <mst@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
  Stefan Hajnoczi <stefanha@redhat.com>
  Wangkai (Kevin,C) <wangkai86@huawei.com>
  Wangkai <wangkai86@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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=328b3b6c44c17d94df115ed1851f54a0bd59a471
+ . 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 328b3b6c44c17d94df115ed1851f54a0bd59a471
+ branch=qemu-mainline
+ revision=328b3b6c44c17d94df115ed1851f54a0bd59a471
+ . 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 328b3b6c44c17d94df115ed1851f54a0bd59a471:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   b574f60..328b3b6  328b3b6c44c17d94df115ed1851f54a0bd59a471 -> 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 Dec 22 15:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 15: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 1Y35CU-0004qM-Lt; Mon, 22 Dec 2014 15:47:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1Y35CT-0004qH-Rd
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 15:47:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3C/D4-15461-10D38945; Mon, 22 Dec 2014 15:47:13 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1419263232!17261094!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24907 invoked from network); 22 Dec 2014 15:47:12 -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;
	22 Dec 2014 15:47:12 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so8332895wiv.8
	for <xen-devel@lists.xenproject.org>;
	Mon, 22 Dec 2014 07:47:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:cc:to:mime-version;
	bh=BnwpUr8XyykfJEIwwwziHe7BhCUUZ1UvPuVKGo2KTS0=;
	b=ZCCXM/AT98kie69q94DlzfJ+61rPBcOKbpEOLyJq1yJ2torvm9RaXRjLcE7WvTG8gI
	UBF7qyGhsnwqbe3pJgJBpI+mtNeuOFHB/dmwwRn7uyVlTdhSDkcKrqrEXtuQKbVZamIc
	uZTet4GmuMoDpPXEJZazRiCzu1/V05SdU2ySDZBbPqCpb6PaSGWYmOSZ64N8CCD3UsmQ
	Mb5tca161x43jSbcB2FJn0HUZToRGPfiCaIpd0MzUR1BtAXsaKbXb2H3wQXU6N8/eWl0
	oaFyfh4CFpQsLbuBCK5pMHO2To1cIoyvVK6gigJ8pNwbIvCsHAMcrapMn6rwuDzX4Aks
	6SzA==
X-Received: by 10.194.189.138 with SMTP id gi10mr44414888wjc.86.1419263232259; 
	Mon, 22 Dec 2014 07:47:12 -0800 (PST)
Received: from [192.168.0.25] (97e5a0c2.skybroadband.com. [151.229.160.194])
	by mx.google.com with ESMTPSA id vm8sm24160594wjc.6.2014.12.22.07.47.10
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 22 Dec 2014 07:47:11 -0800 (PST)
From: Lars Kurth <lars.kurth.xen@gmail.com>
Date: Mon, 22 Dec 2014 15:47:09 +0000
Message-Id: <40FC0F01-9703-4502-8F44-6D348823DDBA@gmail.com>
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)
Cc: Russ Pavlicek <russell.pavlicek@xenproject.org>
Subject: [Xen-devel] Verifying XM - XL discrepancies
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

High all,

I am in the process of cleaning up the 4.5 documentation. One of the pages that needs verification is
* http://wiki.xenproject.org/wiki/XL_vs_Xend_Feature_Comparison

As we are removing XM, I would assume that the only discrepancies between XM and XL should be those that were intended. However looking at http://wiki.xenproject.org/wiki/XL_vs_Xend_Feature_Comparison, it is not clear which discrepancies are intended and which are not. If they are not intended, we should list workarounds with bugs tracking the issue, such that it does get resolved.

Here is functionality that is in XM, but not in XL. Please pete me know whether this is intended, maybe give an explanation. If not intended, we ought to address the discrepancy, as we would leave existing users that use such a feature out in the cold.

* Sharing storage across DomU's via w! in virtual machines configuration files - assuming this is by design?
* SCSI LUN/Host passthrough (PVSCSI)
* USB 1.1 device passthrough via hotplug (using qemu xen traditional)
* USB 1.1 device passthrough via hotplug (using upstream qemu)
* USB 2.0 device passthrough (PVUSB)

Regards
Lars
 

 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 15:47:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 15: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 1Y35CU-0004qM-Lt; Mon, 22 Dec 2014 15:47:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1Y35CT-0004qH-Rd
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 15:47:13 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	3C/D4-15461-10D38945; Mon, 22 Dec 2014 15:47:13 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1419263232!17261094!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24907 invoked from network); 22 Dec 2014 15:47:12 -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;
	22 Dec 2014 15:47:12 -0000
Received: by mail-wi0-f181.google.com with SMTP id r20so8332895wiv.8
	for <xen-devel@lists.xenproject.org>;
	Mon, 22 Dec 2014 07:47:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:cc:to:mime-version;
	bh=BnwpUr8XyykfJEIwwwziHe7BhCUUZ1UvPuVKGo2KTS0=;
	b=ZCCXM/AT98kie69q94DlzfJ+61rPBcOKbpEOLyJq1yJ2torvm9RaXRjLcE7WvTG8gI
	UBF7qyGhsnwqbe3pJgJBpI+mtNeuOFHB/dmwwRn7uyVlTdhSDkcKrqrEXtuQKbVZamIc
	uZTet4GmuMoDpPXEJZazRiCzu1/V05SdU2ySDZBbPqCpb6PaSGWYmOSZ64N8CCD3UsmQ
	Mb5tca161x43jSbcB2FJn0HUZToRGPfiCaIpd0MzUR1BtAXsaKbXb2H3wQXU6N8/eWl0
	oaFyfh4CFpQsLbuBCK5pMHO2To1cIoyvVK6gigJ8pNwbIvCsHAMcrapMn6rwuDzX4Aks
	6SzA==
X-Received: by 10.194.189.138 with SMTP id gi10mr44414888wjc.86.1419263232259; 
	Mon, 22 Dec 2014 07:47:12 -0800 (PST)
Received: from [192.168.0.25] (97e5a0c2.skybroadband.com. [151.229.160.194])
	by mx.google.com with ESMTPSA id vm8sm24160594wjc.6.2014.12.22.07.47.10
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 22 Dec 2014 07:47:11 -0800 (PST)
From: Lars Kurth <lars.kurth.xen@gmail.com>
Date: Mon, 22 Dec 2014 15:47:09 +0000
Message-Id: <40FC0F01-9703-4502-8F44-6D348823DDBA@gmail.com>
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)
Cc: Russ Pavlicek <russell.pavlicek@xenproject.org>
Subject: [Xen-devel] Verifying XM - XL discrepancies
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

High all,

I am in the process of cleaning up the 4.5 documentation. One of the pages that needs verification is
* http://wiki.xenproject.org/wiki/XL_vs_Xend_Feature_Comparison

As we are removing XM, I would assume that the only discrepancies between XM and XL should be those that were intended. However looking at http://wiki.xenproject.org/wiki/XL_vs_Xend_Feature_Comparison, it is not clear which discrepancies are intended and which are not. If they are not intended, we should list workarounds with bugs tracking the issue, such that it does get resolved.

Here is functionality that is in XM, but not in XL. Please pete me know whether this is intended, maybe give an explanation. If not intended, we ought to address the discrepancy, as we would leave existing users that use such a feature out in the cold.

* Sharing storage across DomU's via w! in virtual machines configuration files - assuming this is by design?
* SCSI LUN/Host passthrough (PVSCSI)
* USB 1.1 device passthrough via hotplug (using qemu xen traditional)
* USB 1.1 device passthrough via hotplug (using upstream qemu)
* USB 2.0 device passthrough (PVUSB)

Regards
Lars
 

 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 15:52:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 15: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 1Y35HA-0004zd-Ck; Mon, 22 Dec 2014 15:52:04 +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 1Y35H8-0004zV-EN
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 15:52:03 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	17/E9-03145-12E38945; Mon, 22 Dec 2014 15:52:01 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419263519!16696752!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30206 invoked from network); 22 Dec 2014 15:52:01 -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; 22 Dec 2014 15:52: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 sBMFpixl008979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Dec 2014 15:51: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
	sBMFpi2c010329
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 22 Dec 2014 15:51: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
	sBMFpi8S010320; Mon, 22 Dec 2014 15:51:44 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, 22 Dec 2014 07:51:43 -0800
Message-ID: <54983E8F.5060500@oracle.com>
Date: Mon, 22 Dec 2014 10:53:51 -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: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] Testing preemptibility test in
	xen_setup_cpu_clockevents()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

With 250a1ac685f (x86, smpboot: Remove pointless preempt_disable() in 
native_smp_prepare_cpus()) HVM guests no longer boot since we are 
hitting BUG_ON(preemptible()) in xen_setup_cpu_clockevents().

I don't think we need this test (PV or HVM), do we?


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 15:52:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 15: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 1Y35HA-0004zd-Ck; Mon, 22 Dec 2014 15:52:04 +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 1Y35H8-0004zV-EN
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 15:52:03 +0000
Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id
	17/E9-03145-12E38945; Mon, 22 Dec 2014 15:52:01 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419263519!16696752!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30206 invoked from network); 22 Dec 2014 15:52:01 -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; 22 Dec 2014 15:52: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 sBMFpixl008979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Dec 2014 15:51: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
	sBMFpi2c010329
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 22 Dec 2014 15:51: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
	sBMFpi8S010320; Mon, 22 Dec 2014 15:51:44 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, 22 Dec 2014 07:51:43 -0800
Message-ID: <54983E8F.5060500@oracle.com>
Date: Mon, 22 Dec 2014 10:53:51 -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: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] Testing preemptibility test in
	xen_setup_cpu_clockevents()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

With 250a1ac685f (x86, smpboot: Remove pointless preempt_disable() in 
native_smp_prepare_cpus()) HVM guests no longer boot since we are 
hitting BUG_ON(preemptible()) in xen_setup_cpu_clockevents().

I don't think we need this test (PV or HVM), do we?


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 16:10:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 16:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y35Yk-0005yJ-FH; Mon, 22 Dec 2014 16:10:14 +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 1Y35Yi-0005yE-J2
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 16:10:12 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	72/26-02957-36248945; Mon, 22 Dec 2014 16:10:11 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1419264609!12035232!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5463 invoked from network); 22 Dec 2014 16:10:11 -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;
	22 Dec 2014 16:10:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="207546450"
Message-ID: <54984255.8030702@citrix.com>
Date: Mon, 22 Dec 2014 16:09:57 +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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel
	<xen-devel@lists.xenproject.org>
References: <54983E8F.5060500@oracle.com>
In-Reply-To: <54983E8F.5060500@oracle.com>
X-DLP: MIA2
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] Testing preemptibility test in
	xen_setup_cpu_clockevents()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/12/14 15:53, Boris Ostrovsky wrote:
> With 250a1ac685f (x86, smpboot: Remove pointless preempt_disable() in
> native_smp_prepare_cpus()) HVM guests no longer boot since we are
> hitting BUG_ON(preemptible()) in xen_setup_cpu_clockevents().
> 
> I don't think we need this test (PV or HVM), do we?

It looks safe to remove the BUG_ON().

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 16:10:40 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 16:10:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y35Yk-0005yJ-FH; Mon, 22 Dec 2014 16:10:14 +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 1Y35Yi-0005yE-J2
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 16:10:12 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	72/26-02957-36248945; Mon, 22 Dec 2014 16:10:11 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1419264609!12035232!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, 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 5463 invoked from network); 22 Dec 2014 16:10:11 -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;
	22 Dec 2014 16:10:11 -0000
X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="207546450"
Message-ID: <54984255.8030702@citrix.com>
Date: Mon, 22 Dec 2014 16:09:57 +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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel
	<xen-devel@lists.xenproject.org>
References: <54983E8F.5060500@oracle.com>
In-Reply-To: <54983E8F.5060500@oracle.com>
X-DLP: MIA2
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] Testing preemptibility test in
	xen_setup_cpu_clockevents()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/12/14 15:53, Boris Ostrovsky wrote:
> With 250a1ac685f (x86, smpboot: Remove pointless preempt_disable() in
> native_smp_prepare_cpus()) HVM guests no longer boot since we are
> hitting BUG_ON(preemptible()) in xen_setup_cpu_clockevents().
> 
> I don't think we need this test (PV or HVM), do we?

It looks safe to remove the BUG_ON().

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 16:39:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 16: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 1Y3619-0006lo-1n; Mon, 22 Dec 2014 16:39: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 1Y3617-0006lj-Ke
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 16:39:33 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	B4/0D-01660-44948945; Mon, 22 Dec 2014 16:39:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1419266369!14767579!1
X-Originating-IP: [66.165.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 15463 invoked from network); 22 Dec 2014 16:39:31 -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;
	22 Dec 2014 16:39:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="207559574"
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.210.2; Mon, 22 Dec 2014 11:38: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 1Y360M-0000k0-T4;
	Mon, 22 Dec 2014 16: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 1Y360M-0001r9-HF;
	Mon, 22 Dec 2014 16:38:46 +0000
Date: Mon, 22 Dec 2014 16:38:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32576-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] 32576: 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 32576 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32576/

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              540c339a2535ec30d79e5ef84d8f50a17bc60723
baseline version:
 libvirt              f5070e3ad0478206d2fc1d52d5efeade5abd9c7b

------------------------------------------------------------
People who touched revisions under test:
  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=540c339a2535ec30d79e5ef84d8f50a17bc60723
+ . 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 540c339a2535ec30d79e5ef84d8f50a17bc60723
+ branch=libvirt
+ revision=540c339a2535ec30d79e5ef84d8f50a17bc60723
+ . 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 540c339a2535ec30d79e5ef84d8f50a17bc60723:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   f5070e3..540c339  540c339a2535ec30d79e5ef84d8f50a17bc60723 -> 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 Dec 22 16:39:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 16: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 1Y3619-0006lo-1n; Mon, 22 Dec 2014 16:39: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 1Y3617-0006lj-Ke
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 16:39:33 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	B4/0D-01660-44948945; Mon, 22 Dec 2014 16:39:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1419266369!14767579!1
X-Originating-IP: [66.165.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 15463 invoked from network); 22 Dec 2014 16:39:31 -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;
	22 Dec 2014 16:39:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="207559574"
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.210.2; Mon, 22 Dec 2014 11:38: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 1Y360M-0000k0-T4;
	Mon, 22 Dec 2014 16: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 1Y360M-0001r9-HF;
	Mon, 22 Dec 2014 16:38:46 +0000
Date: Mon, 22 Dec 2014 16:38:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32576-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] 32576: 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 32576 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32576/

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              540c339a2535ec30d79e5ef84d8f50a17bc60723
baseline version:
 libvirt              f5070e3ad0478206d2fc1d52d5efeade5abd9c7b

------------------------------------------------------------
People who touched revisions under test:
  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=540c339a2535ec30d79e5ef84d8f50a17bc60723
+ . 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 540c339a2535ec30d79e5ef84d8f50a17bc60723
+ branch=libvirt
+ revision=540c339a2535ec30d79e5ef84d8f50a17bc60723
+ . 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 540c339a2535ec30d79e5ef84d8f50a17bc60723:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   f5070e3..540c339  540c339a2535ec30d79e5ef84d8f50a17bc60723 -> 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 Dec 22 18:31:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 18:31:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y37lE-0001Ew-E0; Mon, 22 Dec 2014 18:31:16 +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 1Y37lD-0001Er-Jy
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 18:31:15 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	C1/9F-03148-27368945; Mon, 22 Dec 2014 18:31:14 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1419273072!16715268!1
X-Originating-IP: [156.151.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 14452 invoked from network); 22 Dec 2014 18:31:14 -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; 22 Dec 2014 18:31: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 sBMIVAgR006135
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Dec 2014 18:31:10 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
	sBMIV97L024558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 22 Dec 2014 18:31:09 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
	sBMIV8VR002471; Mon, 22 Dec 2014 18:31:08 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Dec 2014 10:31:08 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com
Date: Mon, 22 Dec 2014 13:33:10 -0500
Message-Id: <1419273190-18821-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen/time: Remove unnecessary
	BUG_ON(preemptible()) in xen_setup_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

There is no reason for having it and, with commit 250a1ac685f1 ("x86,
smpboot: Remove pointless preempt_disable() in
native_smp_prepare_cpus()"), it prevents HVM guests from booting.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/xen/time.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index f473d26..23019b4 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -458,8 +458,6 @@ void xen_setup_timer(int cpu)
 
 void xen_setup_cpu_clockevents(void)
 {
-	BUG_ON(preemptible());
-
 	clockevents_register_device(this_cpu_ptr(&xen_clock_events.evt));
 }
 
-- 
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 Dec 22 18:31:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 18:31:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y37lE-0001Ew-E0; Mon, 22 Dec 2014 18:31:16 +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 1Y37lD-0001Er-Jy
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 18:31:15 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	C1/9F-03148-27368945; Mon, 22 Dec 2014 18:31:14 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1419273072!16715268!1
X-Originating-IP: [156.151.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 14452 invoked from network); 22 Dec 2014 18:31:14 -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; 22 Dec 2014 18:31: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 sBMIVAgR006135
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Dec 2014 18:31:10 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
	sBMIV97L024558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 22 Dec 2014 18:31:09 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
	sBMIV8VR002471; Mon, 22 Dec 2014 18:31:08 GMT
Received: from ovs102.us.oracle.com (/10.149.76.202)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Dec 2014 10:31:08 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: david.vrabel@citrix.com, konrad.wilk@oracle.com
Date: Mon, 22 Dec 2014 13:33:10 -0500
Message-Id: <1419273190-18821-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.9.3
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen/time: Remove unnecessary
	BUG_ON(preemptible()) in xen_setup_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

There is no reason for having it and, with commit 250a1ac685f1 ("x86,
smpboot: Remove pointless preempt_disable() in
native_smp_prepare_cpus()"), it prevents HVM guests from booting.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/xen/time.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index f473d26..23019b4 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -458,8 +458,6 @@ void xen_setup_timer(int cpu)
 
 void xen_setup_cpu_clockevents(void)
 {
-	BUG_ON(preemptible());
-
 	clockevents_register_device(this_cpu_ptr(&xen_clock_events.evt));
 }
 
-- 
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 Dec 22 18:44:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 18: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 1Y37xz-0001nm-OR; Mon, 22 Dec 2014 18:44:27 +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 1Y37xy-0001nh-OV
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 18:44:26 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B7/01-27584-A8668945; Mon, 22 Dec 2014 18:44:26 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1419273863!14784593!1
X-Originating-IP: [66.165.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 10166 invoked from network); 22 Dec 2014 18:44:25 -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;
	22 Dec 2014 18:44:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,625,1413244800"; d="scan'208";a="207629421"
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.210.2;
	Mon, 22 Dec 2014 13:43:45 -0500
Message-ID: <54986660.5080703@citrix.com>
Date: Mon, 22 Dec 2014 19:43:44 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <54906D3D.2060807@citrix.com> <549072FE.40500@citrix.com>
	<54917C62.709@citrix.com>
	<5492BD4C0200007800050873@mail.emea.novell.com>
In-Reply-To: <5492BD4C0200007800050873@mail.emea.novell.com>
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] IO-APIC interrupts getting stuck
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 18/12/14 a les 11.41, Jan Beulich ha escrit:
>>>> On 17.12.14 at 13:51, <roger.pau@citrix.com> wrote:
>> I've also added the following patch to Xen, and it reliably triggers on 
>> FreeBSD, while it seems to work fine on Linux:
>>
>> --- a/xen/arch/x86/io_apic.c
>> +++ b/xen/arch/x86/io_apic.c
>> @@ -1729,6 +1729,8 @@ static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 vector)
>>   * The idea is from Manfred Spraul.  --macro
>>   */
>>      unsigned int v, i = desc->arch.vector;
>> +    struct IO_APIC_route_entry rte;
>> +    struct irq_pin_list *entry = irq_2_pin + desc->irq;
>>  
>>      /* Manually EOI the old vector if we are moving to the new */
>>      if ( vector && i != vector )
>> @@ -1751,6 +1753,9 @@ static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 vector)
>>              __unmask_IO_APIC_irq(desc->irq);
>>          spin_unlock(&ioapic_lock);
>>      }
>> +
>> +    rte = ioapic_read_entry(entry->apic, entry->pin, 0);
>> +    ASSERT(rte.irr == 0 || rte.mask != 0);
> 
> Could you arrange for you to be able to determine which code
> paths were taken in the routine when the ASSERT() triggers? I.e.
> minimally make sure vector, i, and v can be determined from the
> printed registers and stack contents. Plus maybe also read the
> applicable APIC_I[RS]R bits.

OK, this was misleading. The ASSERT I've added triggers on Linux also
but it doesn't lead to the irr=1 mask=0 blocked state, so I think
returning from end_level_ioapic_irq_new with irr=1 and mask=0 is a valid
state, is this right?

I've also tested with the following patch applied:

http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01816.html

To make sure FreeBSD was not playing tricks behind Xen's back, and
AFAICT FreeBSD is not touching the IO APIC at all. Also Xen doesn't show
any pending EOI timers ('a' debug key).

> And you're also apparently not seeing this on a system where
> Linux'es IO-APIC re-route workaround might come into play (see
> drivers/pci/quirks.c:quirk_reroute_to_boot_interrupts_intel()),
> which then I would have suspected FreeBSD to not have such a
> workaround...

No, the same box I have with Linux doesn't use the IO-APIC re-route
quirk. I've also tested this on different hardware and when using
FreeBSD with the new IO APIC Ack method I always end up in this stuck
state, so I don't think it's a hardware errata/issue.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 18:44:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 18: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 1Y37xz-0001nm-OR; Mon, 22 Dec 2014 18:44:27 +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 1Y37xy-0001nh-OV
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 18:44:26 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	B7/01-27584-A8668945; Mon, 22 Dec 2014 18:44:26 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1419273863!14784593!1
X-Originating-IP: [66.165.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 10166 invoked from network); 22 Dec 2014 18:44:25 -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;
	22 Dec 2014 18:44:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,625,1413244800"; d="scan'208";a="207629421"
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.210.2;
	Mon, 22 Dec 2014 13:43:45 -0500
Message-ID: <54986660.5080703@citrix.com>
Date: Mon, 22 Dec 2014 19:43:44 +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.3.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <54906D3D.2060807@citrix.com> <549072FE.40500@citrix.com>
	<54917C62.709@citrix.com>
	<5492BD4C0200007800050873@mail.emea.novell.com>
In-Reply-To: <5492BD4C0200007800050873@mail.emea.novell.com>
X-DLP: MIA2
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] IO-APIC interrupts getting stuck
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 18/12/14 a les 11.41, Jan Beulich ha escrit:
>>>> On 17.12.14 at 13:51, <roger.pau@citrix.com> wrote:
>> I've also added the following patch to Xen, and it reliably triggers on 
>> FreeBSD, while it seems to work fine on Linux:
>>
>> --- a/xen/arch/x86/io_apic.c
>> +++ b/xen/arch/x86/io_apic.c
>> @@ -1729,6 +1729,8 @@ static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 vector)
>>   * The idea is from Manfred Spraul.  --macro
>>   */
>>      unsigned int v, i = desc->arch.vector;
>> +    struct IO_APIC_route_entry rte;
>> +    struct irq_pin_list *entry = irq_2_pin + desc->irq;
>>  
>>      /* Manually EOI the old vector if we are moving to the new */
>>      if ( vector && i != vector )
>> @@ -1751,6 +1753,9 @@ static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 vector)
>>              __unmask_IO_APIC_irq(desc->irq);
>>          spin_unlock(&ioapic_lock);
>>      }
>> +
>> +    rte = ioapic_read_entry(entry->apic, entry->pin, 0);
>> +    ASSERT(rte.irr == 0 || rte.mask != 0);
> 
> Could you arrange for you to be able to determine which code
> paths were taken in the routine when the ASSERT() triggers? I.e.
> minimally make sure vector, i, and v can be determined from the
> printed registers and stack contents. Plus maybe also read the
> applicable APIC_I[RS]R bits.

OK, this was misleading. The ASSERT I've added triggers on Linux also
but it doesn't lead to the irr=1 mask=0 blocked state, so I think
returning from end_level_ioapic_irq_new with irr=1 and mask=0 is a valid
state, is this right?

I've also tested with the following patch applied:

http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01816.html

To make sure FreeBSD was not playing tricks behind Xen's back, and
AFAICT FreeBSD is not touching the IO APIC at all. Also Xen doesn't show
any pending EOI timers ('a' debug key).

> And you're also apparently not seeing this on a system where
> Linux'es IO-APIC re-route workaround might come into play (see
> drivers/pci/quirks.c:quirk_reroute_to_boot_interrupts_intel()),
> which then I would have suspected FreeBSD to not have such a
> workaround...

No, the same box I have with Linux doesn't use the IO-APIC re-route
quirk. I've also tested this on different hardware and when using
FreeBSD with the new IO APIC Ack method I always end up in this stuck
state, so I don't think it's a hardware errata/issue.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 20:15:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 20: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 1Y39NY-0003t0-1o; Mon, 22 Dec 2014 20:14:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y39NW-0003sv-M0
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 20:14:54 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	0D/3A-27584-CBB78945; Mon, 22 Dec 2014 20:14:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1419279290!14758153!1
X-Originating-IP: [66.165.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 14400 invoked from network); 22 Dec 2014 20:14:51 -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;
	22 Dec 2014 20:14:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,626,1413244800"; d="scan'208";a="207662139"
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.210.2; Mon, 22 Dec 2014 15:14: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 1Y39NQ-0001lk-1a;
	Mon, 22 Dec 2014 20:14:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y39NP-0001Hf-Rv;
	Mon, 22 Dec 2014 20:14:47 +0000
Date: Mon, 22 Dec 2014 20:14:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32574-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] 32574: 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 32574 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32574/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 32554

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32554

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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-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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 20:15:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 20: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 1Y39NY-0003t0-1o; Mon, 22 Dec 2014 20:14:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y39NW-0003sv-M0
	for xen-devel@lists.xensource.com; Mon, 22 Dec 2014 20:14:54 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	0D/3A-27584-CBB78945; Mon, 22 Dec 2014 20:14:52 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1419279290!14758153!1
X-Originating-IP: [66.165.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 14400 invoked from network); 22 Dec 2014 20:14:51 -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;
	22 Dec 2014 20:14:51 -0000
X-IronPort-AV: E=Sophos;i="5.07,626,1413244800"; d="scan'208";a="207662139"
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.210.2; Mon, 22 Dec 2014 15:14: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 1Y39NQ-0001lk-1a;
	Mon, 22 Dec 2014 20:14:48 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y39NP-0001Hf-Rv;
	Mon, 22 Dec 2014 20:14:47 +0000
Date: Mon, 22 Dec 2014 20:14:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32574-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] 32574: 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 32574 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32574/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 32554

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32554

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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-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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 21:11:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 21:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3AFk-00052P-Gd; Mon, 22 Dec 2014 21:10:56 +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 1Y3AFi-00052K-EH
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 21:10:54 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	30/C0-31453-DD888945; Mon, 22 Dec 2014 21:10:53 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-15.tower-206.messagelabs.com!1419282652!11423934!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 5981 invoked from network); 22 Dec 2014 21:10:53 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-15.tower-206.messagelabs.com with SMTP;
	22 Dec 2014 21:10:53 -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 526D0589672;
	Mon, 22 Dec 2014 13:10:51 -0800 (PST)
Date: Mon, 22 Dec 2014 16:10:49 -0500 (EST)
Message-Id: <20141222.161049.278043772767314122.davem@davemloft.net>
To: herbert@gondor.apana.org.au
From: David Miller <davem@davemloft.net>
In-Reply-To: <20141220002327.GA31975@gondor.apana.org.au>
References: <1418756386-6940-1-git-send-email-david.vrabel@citrix.com>
	<20141220002327.GA31975@gondor.apana.org.au>
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, 22 Dec 2014 13:10:52 -0800 (PST)
Cc: netdev@vger.kernel.org, edumazet@google.com, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] virtio_net: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 20 Dec 2014 11:23:27 +1100

> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) breaks virtio_net in an insidious way.
> 
> It is now required that if the entire budget is consumed when poll
> returns, the napi poll_list must remain empty.  However, like some
> other drivers virtio_net tries to do a last-ditch check and if
> there is more work it will call napi_schedule and then immediately
> process some of this new work.  Should the entire budget be consumed
> while processing such new work then we will violate the new caller
> contract.
> 
> This patch fixes this by not touching any work when we reschedule
> in virtio_net.
> 
> The worst part of this bug is that the list corruption causes other
> napi users to be moved off-list.  In my case I was chasing a stall
> in IPsec (IPsec uses netif_rx) and I only belatedly realised that it
> was virtio_net which caused the stall even though the virtio_net
> poll was still functioning perfectly after IPsec stalled.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied, thanks Herbert.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 21:11:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 21:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3AFk-00052P-Gd; Mon, 22 Dec 2014 21:10:56 +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 1Y3AFi-00052K-EH
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 21:10:54 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	30/C0-31453-DD888945; Mon, 22 Dec 2014 21:10:53 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-15.tower-206.messagelabs.com!1419282652!11423934!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 5981 invoked from network); 22 Dec 2014 21:10:53 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-15.tower-206.messagelabs.com with SMTP;
	22 Dec 2014 21:10:53 -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 526D0589672;
	Mon, 22 Dec 2014 13:10:51 -0800 (PST)
Date: Mon, 22 Dec 2014 16:10:49 -0500 (EST)
Message-Id: <20141222.161049.278043772767314122.davem@davemloft.net>
To: herbert@gondor.apana.org.au
From: David Miller <davem@davemloft.net>
In-Reply-To: <20141220002327.GA31975@gondor.apana.org.au>
References: <1418756386-6940-1-git-send-email-david.vrabel@citrix.com>
	<20141220002327.GA31975@gondor.apana.org.au>
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, 22 Dec 2014 13:10:52 -0800 (PST)
Cc: netdev@vger.kernel.org, edumazet@google.com, david.vrabel@citrix.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] virtio_net: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 20 Dec 2014 11:23:27 +1100

> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) breaks virtio_net in an insidious way.
> 
> It is now required that if the entire budget is consumed when poll
> returns, the napi poll_list must remain empty.  However, like some
> other drivers virtio_net tries to do a last-ditch check and if
> there is more work it will call napi_schedule and then immediately
> process some of this new work.  Should the entire budget be consumed
> while processing such new work then we will violate the new caller
> contract.
> 
> This patch fixes this by not touching any work when we reschedule
> in virtio_net.
> 
> The worst part of this bug is that the list corruption causes other
> napi users to be moved off-list.  In my case I was chasing a stall
> in IPsec (IPsec uses netif_rx) and I only belatedly realised that it
> was virtio_net which caused the stall even though the virtio_net
> poll was still functioning perfectly after IPsec stalled.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied, thanks Herbert.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 22 21:35:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 21:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Ad8-00061c-5h; Mon, 22 Dec 2014 21:35:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Y3Ad6-00061X-RV
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 21:35:04 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	C2/73-17735-88E88945; Mon, 22 Dec 2014 21:35:04 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-4.tower-31.messagelabs.com!1419284103!15203645!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1338 invoked from network); 22 Dec 2014 21:35:03 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-4.tower-31.messagelabs.com with SMTP;
	22 Dec 2014 21:35:03 -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 7D2BE589545;
	Mon, 22 Dec 2014 13:35:01 -0800 (PST)
Date: Mon, 22 Dec 2014 16:35:00 -0500 (EST)
Message-Id: <20141222.163500.2179428727234717734.davem@davemloft.net>
To: herbert@gondor.apana.org.au
From: David Miller <davem@davemloft.net>
In-Reply-To: <20141222093525.GA18616@gondor.apana.org.au>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<5497D3D9.2070509@redhat.com>
	<20141222093525.GA18616@gondor.apana.org.au>
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, 22 Dec 2014 13:35:02 -0800 (PST)
Cc: netdev@vger.kernel.org, jasowang@redhat.com, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] caif: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 22 Dec 2014 20:35:25 +1100

> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) breaks caif.
> 
> It is now required that if the entire budget is consumed when poll
> returns, the napi poll_list must remain empty.  However, like some
> other drivers caif tries to do a last-ditch check and if there is
> more work it will call napi_schedule and then immediately process
> some of this new work.  Should the entire budget be consumed while
> processing such new work then we will violate the new caller
> contract.
> 
> This patch fixes this by not touching any work when we reschedule
> in caif.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

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 Dec 22 21:35:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Dec 2014 21:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Ad8-00061c-5h; Mon, 22 Dec 2014 21:35:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Y3Ad6-00061X-RV
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 21:35:04 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	C2/73-17735-88E88945; Mon, 22 Dec 2014 21:35:04 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-4.tower-31.messagelabs.com!1419284103!15203645!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1338 invoked from network); 22 Dec 2014 21:35:03 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-4.tower-31.messagelabs.com with SMTP;
	22 Dec 2014 21:35:03 -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 7D2BE589545;
	Mon, 22 Dec 2014 13:35:01 -0800 (PST)
Date: Mon, 22 Dec 2014 16:35:00 -0500 (EST)
Message-Id: <20141222.163500.2179428727234717734.davem@davemloft.net>
To: herbert@gondor.apana.org.au
From: David Miller <davem@davemloft.net>
In-Reply-To: <20141222093525.GA18616@gondor.apana.org.au>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<5497D3D9.2070509@redhat.com>
	<20141222093525.GA18616@gondor.apana.org.au>
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, 22 Dec 2014 13:35:02 -0800 (PST)
Cc: netdev@vger.kernel.org, jasowang@redhat.com, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] caif: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 22 Dec 2014 20:35:25 +1100

> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) breaks caif.
> 
> It is now required that if the entire budget is consumed when poll
> returns, the napi poll_list must remain empty.  However, like some
> other drivers caif tries to do a last-ditch check and if there is
> more work it will call napi_schedule and then immediately process
> some of this new work.  Should the entire budget be consumed while
> processing such new work then we will violate the new caller
> contract.
> 
> This patch fixes this by not touching any work when we reschedule
> in caif.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

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 Dec 23 00:40:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 00:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3DWP-0002G3-0F; Tue, 23 Dec 2014 00:40:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1Y3DWO-0002Fr-3G
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 00:40:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AD/83-15461-3F9B8945; Tue, 23 Dec 2014 00:40:19 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1419295216!17354955!1
X-Originating-IP: [209.85.218.44]
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 20093 invoked from network); 23 Dec 2014 00:40:17 -0000
Received: from mail-oi0-f44.google.com (HELO mail-oi0-f44.google.com)
	(209.85.218.44)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 00:40:17 -0000
Received: by mail-oi0-f44.google.com with SMTP id e131so11995766oig.3
	for <xen-devel@lists.xenproject.org>;
	Mon, 22 Dec 2014 16:40: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:in-reply-to:references;
	bh=A/jSnSXjF+hGfGY1Kj4GRV5FCvfrSpNXuZY8zdCLl6k=;
	b=PEj4StlGu2xNgaA3lUCkGewGX1c/LtmOsjLo7Y00JNg6iafRysfNlLRv83FE5w0x5H
	tJJ5yBWouyi5otH0j+ZiScr+BmsKjUJo05WxzOtOGpANEGlKJ8JworNtp9Nrw07KeKIU
	NjAyVPOi4LHNonSY4f6FKhfPWozBwR1m3EXCmBsRAbyKCx2dt6oj0TKwRJJ/Y+bq8pss
	u17uZBjdhdGwOtnojQR/lLXJ3RV7RKhC2gLY9A2fYdiGn8WA0T1ZvuuQHoZ/EdCZeD3j
	VxqyxrbCowph8k+TLo7IEixvrGpJ/2IshCALRjM+rdRt1Ovr56a7dSuZKZwmxsdQVwPt
	cWSw==
X-Gm-Message-State: ALoCoQnzyOLKn5pUxQnIfEJ/WDFA1N0NyPKe5RCm3l4ZZwC9N/fqfz5pIS+IU7+FuGoMooh53r0z
X-Received: by 10.182.50.225 with SMTP id f1mr14603877obo.45.1419295216034;
	Mon, 22 Dec 2014 16:40:16 -0800 (PST)
Received: from localhost (23-125-129-128.lightspeed.sntcca.sbcglobal.net.
	[23.125.129.128]) by mx.google.com with ESMTPSA id
	e129sm8464346oih.28.2014.12.22.16.40.13
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 22 Dec 2014 16:40:14 -0800 (PST)
From: Andy Lutomirski <luto@amacapital.net>
To: Paolo Bonzini <pbonzini@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>
Date: Mon, 22 Dec 2014 16:39:57 -0800
Message-Id: <8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <cover.1419295081.git.luto@amacapital.net>
References: <cover.1419295081.git.luto@amacapital.net>
In-Reply-To: <cover.1419295081.git.luto@amacapital.net>
References: <cover.1419295081.git.luto@amacapital.net>
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>, Andy Lutomirski <luto@amacapital.net>
Subject: [Xen-devel] [RFC 2/2] x86, vdso,
	pvclock: Simplify and speed up the vdso pvclock reader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The pvclock vdso code was too abstracted to understand easily and
excessively paranoid.  Simplify it for a huge speedup.

This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.

Before, vclock_gettime using kvm-clock took about 64ns on my machine.
With this change, it takes 19ns, which is almost as fast as the pure TSC
implementation.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 arch/x86/vdso/vclock_gettime.c | 82 ++++++++++++++++++++++++------------------
 1 file changed, 47 insertions(+), 35 deletions(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 9793322751e0..f2e0396d5629 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
 
 static notrace cycle_t vread_pvclock(int *mode)
 {
-	const struct pvclock_vsyscall_time_info *pvti;
+	const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
 	cycle_t ret;
-	u64 last;
-	u32 version;
-	u8 flags;
-	unsigned cpu, cpu1;
-
+	u64 tsc, pvti_tsc;
+	u64 last, delta, pvti_system_time;
+	u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
 
 	/*
-	 * Note: hypervisor must guarantee that:
-	 * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
-	 * 2. that per-CPU pvclock time info is updated if the
-	 *    underlying CPU changes.
-	 * 3. that version is increased whenever underlying CPU
-	 *    changes.
+	 * Note: The kernel and hypervisor must guarantee that cpu ID
+	 * number maps 1:1 to per-CPU pvclock time info.
+	 *
+	 * Because the hypervisor is entirely unaware of guest userspace
+	 * preemption, it cannot guarantee that per-CPU pvclock time
+	 * info is updated if the underlying CPU changes or that that
+	 * version is increased whenever underlying CPU changes.
+	 *
+	 * On KVM, we are guaranteed that pvti updates for any vCPU are
+	 * atomic as seen by *all* vCPUs.  This is an even stronger
+	 * guarantee than we get with a normal seqlock.
 	 *
+	 * On Xen, we don't appear to have that guarantee, but Xen still
+	 * supplies a valid seqlock using the version field.
+
+	 * We only do pvclock vdso timing at all if
+	 * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
+	 * mean that all vCPUs have matching pvti and that the TSC is
+	 * synced, so we can just look at vCPU 0's pvti.
 	 */
-	do {
-		cpu = __getcpu() & VGETCPU_CPU_MASK;
-		/* TODO: We can put vcpu id into higher bits of pvti.version.
-		 * This will save a couple of cycles by getting rid of
-		 * __getcpu() calls (Gleb).
-		 */
-
-		pvti = get_pvti(cpu);
-
-		version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
-
-		/*
-		 * Test we're still on the cpu as well as the version.
-		 * We could have been migrated just after the first
-		 * vgetcpu but before fetching the version, so we
-		 * wouldn't notice a version change.
-		 */
-		cpu1 = __getcpu() & VGETCPU_CPU_MASK;
-	} while (unlikely(cpu != cpu1 ||
-			  (pvti->pvti.version & 1) ||
-			  pvti->pvti.version != version));
-
-	if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
+
+	if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
 		*mode = VCLOCK_NONE;
+		return 0;
+	}
+
+	do {
+		version = pvti->version;
+
+		/* This is also a read barrier, so we'll read version first. */
+		rdtsc_barrier();
+		tsc = __native_read_tsc();
+
+		pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
+		pvti_tsc_shift = pvti->tsc_shift;
+		pvti_system_time = pvti->system_time;
+		pvti_tsc = pvti->tsc_timestamp;
+
+		/* Make sure that the version double-check is last. */
+		smp_rmb();
+	} while (unlikely((version & 1) || version != pvti->version));
+
+	delta = tsc - pvti_tsc;
+	ret = pvti_system_time +
+		pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
+				    pvti_tsc_shift);
 
 	/* refer to tsc.c read_tsc() comment for rationale */
 	last = gtod->cycle_last;
-- 
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 Dec 23 00:40:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 00:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3DWH-0002FJ-7z; Tue, 23 Dec 2014 00:40:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1Y3DWF-0002FE-KR
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 00:40:11 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4B/D5-25276-BE9B8945; Tue, 23 Dec 2014 00:40:11 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1419295209!17354943!1
X-Originating-IP: [209.85.214.172]
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 19359 invoked from network); 23 Dec 2014 00:40:10 -0000
Received: from mail-ob0-f172.google.com (HELO mail-ob0-f172.google.com)
	(209.85.214.172)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 00:40:10 -0000
Received: by mail-ob0-f172.google.com with SMTP id va8so23494015obc.3
	for <xen-devel@lists.xenproject.org>;
	Mon, 22 Dec 2014 16:40: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:from:to:cc:subject:date:message-id;
	bh=+9qnKtwDN1keXllS19Az3f1H0ILmC8nUHShGlcASAa4=;
	b=B7Yfd+b5g2gRMD22J4BIIu4m66zBXaf0gs0m8GoNpI5+71NoN25s4NqeeeZNAqZMGO
	AcbelsM2CO9M2E21+jTw4rha8SD10zbkdVMltfTN6N5Ic+1EZoB6kz9YdbU3tBZd8oas
	L+hxo3e/rBWDtCJlhKYr0jmQtVT9eP955KyvZXjJbgW387WqmFAAsV7WgGNHjWRAA07m
	n9tE7u8h8NFHblV9jCDyEC/DkpE9lvwMxvA/7EFxb4s+rcQIeo59R7HZ3lSJ+MNdr5F8
	ngwZuqyimb/LMma89N40pZ5Pqb3qWdXZqOYCDI5gx+GZxTBkBN/iFd926JDqagQGFusK
	kQvg==
X-Gm-Message-State: ALoCoQlE0F7pvxOWFdYbJ0YmMm+TosT4qVD/cCrT+Y5dUZduhs7DuXFPWSQgB3TOHdET1q0XjFlW
X-Received: by 10.202.189.2 with SMTP id n2mr3834135oif.4.1419295208128;
	Mon, 22 Dec 2014 16:40:08 -0800 (PST)
Received: from localhost (23-125-129-128.lightspeed.sntcca.sbcglobal.net.
	[23.125.129.128])
	by mx.google.com with ESMTPSA id k9sm9450047oev.8.2014.12.22.16.40.06
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 22 Dec 2014 16:40:07 -0800 (PST)
From: Andy Lutomirski <luto@amacapital.net>
To: Paolo Bonzini <pbonzini@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>
Date: Mon, 22 Dec 2014 16:39:55 -0800
Message-Id: <cover.1419295081.git.luto@amacapital.net>
X-Mailer: git-send-email 2.1.0
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>, Andy Lutomirski <luto@amacapital.net>
Subject: [Xen-devel] [RFC 0/2] x86, vdso, pvclock: Cleanups and speedups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a dramatic simplification and speedup of the vdso pvclock read
code.  Is it correct?

Andy Lutomirski (2):
  x86, vdso: Use asm volatile in __getcpu
  x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

 arch/x86/include/asm/vgtod.h   |  6 ++--
 arch/x86/vdso/vclock_gettime.c | 82 ++++++++++++++++++++++++------------------
 2 files changed, 51 insertions(+), 37 deletions(-)

-- 
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 Dec 23 00:40:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 00:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3DWH-0002FJ-7z; Tue, 23 Dec 2014 00:40:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1Y3DWF-0002FE-KR
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 00:40:11 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4B/D5-25276-BE9B8945; Tue, 23 Dec 2014 00:40:11 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1419295209!17354943!1
X-Originating-IP: [209.85.214.172]
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 19359 invoked from network); 23 Dec 2014 00:40:10 -0000
Received: from mail-ob0-f172.google.com (HELO mail-ob0-f172.google.com)
	(209.85.214.172)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 00:40:10 -0000
Received: by mail-ob0-f172.google.com with SMTP id va8so23494015obc.3
	for <xen-devel@lists.xenproject.org>;
	Mon, 22 Dec 2014 16:40: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:from:to:cc:subject:date:message-id;
	bh=+9qnKtwDN1keXllS19Az3f1H0ILmC8nUHShGlcASAa4=;
	b=B7Yfd+b5g2gRMD22J4BIIu4m66zBXaf0gs0m8GoNpI5+71NoN25s4NqeeeZNAqZMGO
	AcbelsM2CO9M2E21+jTw4rha8SD10zbkdVMltfTN6N5Ic+1EZoB6kz9YdbU3tBZd8oas
	L+hxo3e/rBWDtCJlhKYr0jmQtVT9eP955KyvZXjJbgW387WqmFAAsV7WgGNHjWRAA07m
	n9tE7u8h8NFHblV9jCDyEC/DkpE9lvwMxvA/7EFxb4s+rcQIeo59R7HZ3lSJ+MNdr5F8
	ngwZuqyimb/LMma89N40pZ5Pqb3qWdXZqOYCDI5gx+GZxTBkBN/iFd926JDqagQGFusK
	kQvg==
X-Gm-Message-State: ALoCoQlE0F7pvxOWFdYbJ0YmMm+TosT4qVD/cCrT+Y5dUZduhs7DuXFPWSQgB3TOHdET1q0XjFlW
X-Received: by 10.202.189.2 with SMTP id n2mr3834135oif.4.1419295208128;
	Mon, 22 Dec 2014 16:40:08 -0800 (PST)
Received: from localhost (23-125-129-128.lightspeed.sntcca.sbcglobal.net.
	[23.125.129.128])
	by mx.google.com with ESMTPSA id k9sm9450047oev.8.2014.12.22.16.40.06
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 22 Dec 2014 16:40:07 -0800 (PST)
From: Andy Lutomirski <luto@amacapital.net>
To: Paolo Bonzini <pbonzini@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>
Date: Mon, 22 Dec 2014 16:39:55 -0800
Message-Id: <cover.1419295081.git.luto@amacapital.net>
X-Mailer: git-send-email 2.1.0
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>, Andy Lutomirski <luto@amacapital.net>
Subject: [Xen-devel] [RFC 0/2] x86, vdso, pvclock: Cleanups and speedups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a dramatic simplification and speedup of the vdso pvclock read
code.  Is it correct?

Andy Lutomirski (2):
  x86, vdso: Use asm volatile in __getcpu
  x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

 arch/x86/include/asm/vgtod.h   |  6 ++--
 arch/x86/vdso/vclock_gettime.c | 82 ++++++++++++++++++++++++------------------
 2 files changed, 51 insertions(+), 37 deletions(-)

-- 
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 Dec 23 00:40:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 00:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3DWK-0002FV-K2; Tue, 23 Dec 2014 00:40:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1Y3DWI-0002FQ-Tg
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 00:40:15 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EF/D5-25276-EE9B8945; Tue, 23 Dec 2014 00:40:14 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1419295212!17354946!1
X-Originating-IP: [209.85.218.48]
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 19793 invoked from network); 23 Dec 2014 00:40:12 -0000
Received: from mail-oi0-f48.google.com (HELO mail-oi0-f48.google.com)
	(209.85.218.48)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 00:40:12 -0000
Received: by mail-oi0-f48.google.com with SMTP id u20so12002598oif.7
	for <xen-devel@lists.xenproject.org>;
	Mon, 22 Dec 2014 16:40: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:in-reply-to:references;
	bh=kWtbL6Krj7V8h3McAWzFPFyuzZK2qlezTyoYKZwGT8s=;
	b=EnTbY9Y0p2YGpXiASyb08gy4YVQX+JPw7X2dz5GrtktwXX2556T8qnRR7F9o93lY9y
	TXHzCmCrjVnXEbdm07uWffwzG+iEBVzhUTR1Crys+Gm6rWt45Ld3Ch+vNeCXjScRBc5N
	E7vgZpyJZofgJLw9ixBfg4yCFxXC7IoQj4dtznb2OVZsxspuih0ZkGoGXm+DlkCqaYjt
	VrkC3Ty2t1Po3KGmKBZtkATqdZJvwfigaXU08tA2gpLuWXSte9mmbIDx6ufWGa9Jbcsw
	5fIIxTu6JknFfonjlHfD/cvXbvLWWDzeylqDZBxlXITsrrCsbTHlzW76meYO/2KBcZU0
	l6OA==
X-Gm-Message-State: ALoCoQkHSspalYI38vkemTNfYxh6jGikrUfaUM/vmCdL69uXxmz/5c5nldiecc5srR2W3i9Y1PFM
X-Received: by 10.182.213.72 with SMTP id nq8mr14448449obc.11.1419295211898;
	Mon, 22 Dec 2014 16:40:11 -0800 (PST)
Received: from localhost (23-125-129-128.lightspeed.sntcca.sbcglobal.net.
	[23.125.129.128])
	by mx.google.com with ESMTPSA id o93sm9533190oik.21.2014.12.22.16.40.10
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 22 Dec 2014 16:40:10 -0800 (PST)
From: Andy Lutomirski <luto@amacapital.net>
To: Paolo Bonzini <pbonzini@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>
Date: Mon, 22 Dec 2014 16:39:56 -0800
Message-Id: <6a3798f5f28095773dd71cf98fcee2b8edb77f2d.1419295081.git.luto@amacapital.net>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <cover.1419295081.git.luto@amacapital.net>
References: <cover.1419295081.git.luto@amacapital.net>
In-Reply-To: <cover.1419295081.git.luto@amacapital.net>
References: <cover.1419295081.git.luto@amacapital.net>
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>, Andy Lutomirski <luto@amacapital.net>
Subject: [Xen-devel] [RFC 1/2] x86, vdso: Use asm volatile in __getcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 Linux 3.18 and below, GCC hoists the lsl instructions in the
pvclock code all the way to the beginning of __vdso_clock_gettime,
slowing the non-paravirt case significantly.  For unknown reasons,
presumably related to the removal of a branch, the performance issue
is gone as of

e76b027e6408 x86,vdso: Use LSL unconditionally for vgetcpu

but I don't trust GCC enough to expect the problem to stay fixed.

There should be no correctness issue, because the __getcpu calls in
__vdso_vlock_gettime were never necessary in the first place.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 arch/x86/include/asm/vgtod.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index e7e9682a33e9..f556c4843aa1 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -80,9 +80,11 @@ static inline unsigned int __getcpu(void)
 
 	/*
 	 * Load per CPU data from GDT.  LSL is faster than RDTSCP and
-	 * works on all CPUs.
+	 * works on all CPUs.  This is volatile so that it orders
+	 * correctly wrt barrier() and to keep gcc from cleverly
+	 * hoisting it out of the calling function.
 	 */
-	asm("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
+	asm volatile ("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
 
 	return p;
 }
-- 
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 Dec 23 00:40:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 00:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3DWP-0002G3-0F; Tue, 23 Dec 2014 00:40:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1Y3DWO-0002Fr-3G
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 00:40:20 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AD/83-15461-3F9B8945; Tue, 23 Dec 2014 00:40:19 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1419295216!17354955!1
X-Originating-IP: [209.85.218.44]
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 20093 invoked from network); 23 Dec 2014 00:40:17 -0000
Received: from mail-oi0-f44.google.com (HELO mail-oi0-f44.google.com)
	(209.85.218.44)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 00:40:17 -0000
Received: by mail-oi0-f44.google.com with SMTP id e131so11995766oig.3
	for <xen-devel@lists.xenproject.org>;
	Mon, 22 Dec 2014 16:40: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:in-reply-to:references;
	bh=A/jSnSXjF+hGfGY1Kj4GRV5FCvfrSpNXuZY8zdCLl6k=;
	b=PEj4StlGu2xNgaA3lUCkGewGX1c/LtmOsjLo7Y00JNg6iafRysfNlLRv83FE5w0x5H
	tJJ5yBWouyi5otH0j+ZiScr+BmsKjUJo05WxzOtOGpANEGlKJ8JworNtp9Nrw07KeKIU
	NjAyVPOi4LHNonSY4f6FKhfPWozBwR1m3EXCmBsRAbyKCx2dt6oj0TKwRJJ/Y+bq8pss
	u17uZBjdhdGwOtnojQR/lLXJ3RV7RKhC2gLY9A2fYdiGn8WA0T1ZvuuQHoZ/EdCZeD3j
	VxqyxrbCowph8k+TLo7IEixvrGpJ/2IshCALRjM+rdRt1Ovr56a7dSuZKZwmxsdQVwPt
	cWSw==
X-Gm-Message-State: ALoCoQnzyOLKn5pUxQnIfEJ/WDFA1N0NyPKe5RCm3l4ZZwC9N/fqfz5pIS+IU7+FuGoMooh53r0z
X-Received: by 10.182.50.225 with SMTP id f1mr14603877obo.45.1419295216034;
	Mon, 22 Dec 2014 16:40:16 -0800 (PST)
Received: from localhost (23-125-129-128.lightspeed.sntcca.sbcglobal.net.
	[23.125.129.128]) by mx.google.com with ESMTPSA id
	e129sm8464346oih.28.2014.12.22.16.40.13
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 22 Dec 2014 16:40:14 -0800 (PST)
From: Andy Lutomirski <luto@amacapital.net>
To: Paolo Bonzini <pbonzini@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>
Date: Mon, 22 Dec 2014 16:39:57 -0800
Message-Id: <8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <cover.1419295081.git.luto@amacapital.net>
References: <cover.1419295081.git.luto@amacapital.net>
In-Reply-To: <cover.1419295081.git.luto@amacapital.net>
References: <cover.1419295081.git.luto@amacapital.net>
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>, Andy Lutomirski <luto@amacapital.net>
Subject: [Xen-devel] [RFC 2/2] x86, vdso,
	pvclock: Simplify and speed up the vdso pvclock reader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The pvclock vdso code was too abstracted to understand easily and
excessively paranoid.  Simplify it for a huge speedup.

This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.

Before, vclock_gettime using kvm-clock took about 64ns on my machine.
With this change, it takes 19ns, which is almost as fast as the pure TSC
implementation.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 arch/x86/vdso/vclock_gettime.c | 82 ++++++++++++++++++++++++------------------
 1 file changed, 47 insertions(+), 35 deletions(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 9793322751e0..f2e0396d5629 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
 
 static notrace cycle_t vread_pvclock(int *mode)
 {
-	const struct pvclock_vsyscall_time_info *pvti;
+	const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
 	cycle_t ret;
-	u64 last;
-	u32 version;
-	u8 flags;
-	unsigned cpu, cpu1;
-
+	u64 tsc, pvti_tsc;
+	u64 last, delta, pvti_system_time;
+	u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
 
 	/*
-	 * Note: hypervisor must guarantee that:
-	 * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
-	 * 2. that per-CPU pvclock time info is updated if the
-	 *    underlying CPU changes.
-	 * 3. that version is increased whenever underlying CPU
-	 *    changes.
+	 * Note: The kernel and hypervisor must guarantee that cpu ID
+	 * number maps 1:1 to per-CPU pvclock time info.
+	 *
+	 * Because the hypervisor is entirely unaware of guest userspace
+	 * preemption, it cannot guarantee that per-CPU pvclock time
+	 * info is updated if the underlying CPU changes or that that
+	 * version is increased whenever underlying CPU changes.
+	 *
+	 * On KVM, we are guaranteed that pvti updates for any vCPU are
+	 * atomic as seen by *all* vCPUs.  This is an even stronger
+	 * guarantee than we get with a normal seqlock.
 	 *
+	 * On Xen, we don't appear to have that guarantee, but Xen still
+	 * supplies a valid seqlock using the version field.
+
+	 * We only do pvclock vdso timing at all if
+	 * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
+	 * mean that all vCPUs have matching pvti and that the TSC is
+	 * synced, so we can just look at vCPU 0's pvti.
 	 */
-	do {
-		cpu = __getcpu() & VGETCPU_CPU_MASK;
-		/* TODO: We can put vcpu id into higher bits of pvti.version.
-		 * This will save a couple of cycles by getting rid of
-		 * __getcpu() calls (Gleb).
-		 */
-
-		pvti = get_pvti(cpu);
-
-		version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
-
-		/*
-		 * Test we're still on the cpu as well as the version.
-		 * We could have been migrated just after the first
-		 * vgetcpu but before fetching the version, so we
-		 * wouldn't notice a version change.
-		 */
-		cpu1 = __getcpu() & VGETCPU_CPU_MASK;
-	} while (unlikely(cpu != cpu1 ||
-			  (pvti->pvti.version & 1) ||
-			  pvti->pvti.version != version));
-
-	if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
+
+	if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
 		*mode = VCLOCK_NONE;
+		return 0;
+	}
+
+	do {
+		version = pvti->version;
+
+		/* This is also a read barrier, so we'll read version first. */
+		rdtsc_barrier();
+		tsc = __native_read_tsc();
+
+		pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
+		pvti_tsc_shift = pvti->tsc_shift;
+		pvti_system_time = pvti->system_time;
+		pvti_tsc = pvti->tsc_timestamp;
+
+		/* Make sure that the version double-check is last. */
+		smp_rmb();
+	} while (unlikely((version & 1) || version != pvti->version));
+
+	delta = tsc - pvti_tsc;
+	ret = pvti_system_time +
+		pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
+				    pvti_tsc_shift);
 
 	/* refer to tsc.c read_tsc() comment for rationale */
 	last = gtod->cycle_last;
-- 
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 Dec 23 00:40:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 00:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3DWK-0002FV-K2; Tue, 23 Dec 2014 00:40:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1Y3DWI-0002FQ-Tg
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 00:40:15 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	EF/D5-25276-EE9B8945; Tue, 23 Dec 2014 00:40:14 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1419295212!17354946!1
X-Originating-IP: [209.85.218.48]
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 19793 invoked from network); 23 Dec 2014 00:40:12 -0000
Received: from mail-oi0-f48.google.com (HELO mail-oi0-f48.google.com)
	(209.85.218.48)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 00:40:12 -0000
Received: by mail-oi0-f48.google.com with SMTP id u20so12002598oif.7
	for <xen-devel@lists.xenproject.org>;
	Mon, 22 Dec 2014 16:40: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:in-reply-to:references;
	bh=kWtbL6Krj7V8h3McAWzFPFyuzZK2qlezTyoYKZwGT8s=;
	b=EnTbY9Y0p2YGpXiASyb08gy4YVQX+JPw7X2dz5GrtktwXX2556T8qnRR7F9o93lY9y
	TXHzCmCrjVnXEbdm07uWffwzG+iEBVzhUTR1Crys+Gm6rWt45Ld3Ch+vNeCXjScRBc5N
	E7vgZpyJZofgJLw9ixBfg4yCFxXC7IoQj4dtznb2OVZsxspuih0ZkGoGXm+DlkCqaYjt
	VrkC3Ty2t1Po3KGmKBZtkATqdZJvwfigaXU08tA2gpLuWXSte9mmbIDx6ufWGa9Jbcsw
	5fIIxTu6JknFfonjlHfD/cvXbvLWWDzeylqDZBxlXITsrrCsbTHlzW76meYO/2KBcZU0
	l6OA==
X-Gm-Message-State: ALoCoQkHSspalYI38vkemTNfYxh6jGikrUfaUM/vmCdL69uXxmz/5c5nldiecc5srR2W3i9Y1PFM
X-Received: by 10.182.213.72 with SMTP id nq8mr14448449obc.11.1419295211898;
	Mon, 22 Dec 2014 16:40:11 -0800 (PST)
Received: from localhost (23-125-129-128.lightspeed.sntcca.sbcglobal.net.
	[23.125.129.128])
	by mx.google.com with ESMTPSA id o93sm9533190oik.21.2014.12.22.16.40.10
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 22 Dec 2014 16:40:10 -0800 (PST)
From: Andy Lutomirski <luto@amacapital.net>
To: Paolo Bonzini <pbonzini@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>
Date: Mon, 22 Dec 2014 16:39:56 -0800
Message-Id: <6a3798f5f28095773dd71cf98fcee2b8edb77f2d.1419295081.git.luto@amacapital.net>
X-Mailer: git-send-email 2.1.0
In-Reply-To: <cover.1419295081.git.luto@amacapital.net>
References: <cover.1419295081.git.luto@amacapital.net>
In-Reply-To: <cover.1419295081.git.luto@amacapital.net>
References: <cover.1419295081.git.luto@amacapital.net>
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>, Andy Lutomirski <luto@amacapital.net>
Subject: [Xen-devel] [RFC 1/2] x86, vdso: Use asm volatile in __getcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 Linux 3.18 and below, GCC hoists the lsl instructions in the
pvclock code all the way to the beginning of __vdso_clock_gettime,
slowing the non-paravirt case significantly.  For unknown reasons,
presumably related to the removal of a branch, the performance issue
is gone as of

e76b027e6408 x86,vdso: Use LSL unconditionally for vgetcpu

but I don't trust GCC enough to expect the problem to stay fixed.

There should be no correctness issue, because the __getcpu calls in
__vdso_vlock_gettime were never necessary in the first place.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 arch/x86/include/asm/vgtod.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index e7e9682a33e9..f556c4843aa1 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -80,9 +80,11 @@ static inline unsigned int __getcpu(void)
 
 	/*
 	 * Load per CPU data from GDT.  LSL is faster than RDTSCP and
-	 * works on all CPUs.
+	 * works on all CPUs.  This is volatile so that it orders
+	 * correctly wrt barrier() and to keep gcc from cleverly
+	 * hoisting it out of the calling function.
 	 */
-	asm("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
+	asm volatile ("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
 
 	return p;
 }
-- 
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 Dec 23 02:26:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 02:26:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3FAy-0000wy-FN; Tue, 23 Dec 2014 02:26:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1Y3FAw-0000wt-Ss
	for Xen-devel@lists.xensource.com; Tue, 23 Dec 2014 02:26:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6D/78-15461-AC2D8945; Tue, 23 Dec 2014 02:26:18 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-6.tower-21.messagelabs.com!1419301574!17299047!1
X-Originating-IP: [103.22.144.67]
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 12845 invoked from network); 23 Dec 2014 02:26:17 -0000
Received: from ozlabs.org (HELO ozlabs.org) (103.22.144.67)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 02:26:17 -0000
Received: from authenticated.ozlabs.org (localhost [127.0.0.1])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by ozlabs.org (Postfix) with ESMTPSA id 2D71D14009B;
	Tue, 23 Dec 2014 13:26:12 +1100 (AEDT)
Date: Tue, 23 Dec 2014 13:26:05 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Linus <torvalds@linux-foundation.org>
Message-ID: <20141223132605.02d81e01@canb.auug.org.au>
In-Reply-To: <20141208103328.GE27367@arm.com>
References: <20141208184908.27bfd605@canb.auug.org.au>
	<20141208103328.GE27367@arm.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; i586-pc-linux-gnu)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <Xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Olof Johansson <olof@lixom.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: [Xen-devel] linux-next: missing merge fix patch for the merge of
 the xen-tip tree with the arm-soc tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6954697514048040809=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6954697514048040809==
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/QYtZIu3XwRWMpWpEXCkyZOj"; protocol="application/pgp-signature"

--Sig_/QYtZIu3XwRWMpWpEXCkyZOj
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi Linus,

I have been carrying this merge fix patch for some time that is now
needed in your tree:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 8 Dec 2014 18:46:59 +1100
Subject: [PATCH] arm: introduce is_device_dma_coherent merge fix

The merge of the (linux-next) xen-tip tree got a conflict in
arch/arm/include/asm/dma-mapping.h between commits a3a60f81ee6f
("dma-mapping: replace set_arch_dma_coherent_ops with
arch_setup_dma_ops") and 4bb25789ed28 ("arm: dma-mapping: plumb our
iommu mapping ops into arch_setup_dma_ops") from the arm-soc tree and
commit 3d5391ac6f5e ("arm: introduce is_device_dma_coherent") from the
xen-tip tree.  It was fixed up, but also required this additional fix.

"Looks good to me"-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/mm/dma-mapping.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 09645f00bd17..43064cbe58f9 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2058,6 +2058,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_b=
ase, u64 size,
 	else
 		dma_ops =3D arm_get_dma_map_ops(coherent);
=20
+	dev->archdata.dma_coherent =3D coherent;
 	set_dma_ops(dev, dma_ops);
 }
=20
--=20
2.1.3

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

--Sig_/QYtZIu3XwRWMpWpEXCkyZOj
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUmNLDAAoJEMDTa8Ir7ZwVBMkP/jNMLxNBOEL1OZAPi0U3azhT
SQS4SMTBhGIsW2FqDLGn4Wj1mDXvMB5rG0OQDZi++wE3x8mIQrbKTsmTym3GnNFU
273G3jM9/V7YFMo2b+iTGDA0xZxMtGBI7EqhXd+GH54qzQiT/U803/ejsgIWDzBK
ZwoBDEtoi9zU7M81h8mrpYS9XDJByH6gjiiB7kDDFwJxhPtIsi6TpUagtf6lY/Fj
GrY2neIWlIDClx+Fx0gpmiy3XIA1PL2xxcXgw70fc6oZSO6upDAR+9La0IdItiKY
QyLBJHhTT+WM8OqBbnz7oyrw2SWC1Y4HXdrr26EqmUuNhsGotbFG/XG9nwuTfUpl
0yU86iQCm7ov79xpQQjVmV3u1eN0620cXbSC4xEFQHeSnhuO1QLmWVsVgMHkJ53q
yD/r35sJy4r/VAH6a/B5cnEW14FJ+n7mec14dSohxRbDwkNbXn//h9NTuhybESQF
60l4dj0kRhY64LR4Klv0zj8omDe24mMrbbg8p8Gp1/PLQhidHS1ICXgeDZpGXcup
N2Mzzc/CORQa4GPQxNiO49KfEWoLO76YPNv/Vf4waIT618HNkpCCUlrU+7cen3JB
GcVhdo6iC4OV94Vp6boOdQRUGYbQUQL2ftb7PzgXI7nWAzPMCIYIYOOnPmIuCVTC
idW5VOEzpw6T+eM4DjYz
=+uGw
-----END PGP SIGNATURE-----

--Sig_/QYtZIu3XwRWMpWpEXCkyZOj--


--===============6954697514048040809==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6954697514048040809==--


From xen-devel-bounces@lists.xen.org Tue Dec 23 02:26:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 02:26:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3FAy-0000wy-FN; Tue, 23 Dec 2014 02:26:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1Y3FAw-0000wt-Ss
	for Xen-devel@lists.xensource.com; Tue, 23 Dec 2014 02:26:18 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	6D/78-15461-AC2D8945; Tue, 23 Dec 2014 02:26:18 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-6.tower-21.messagelabs.com!1419301574!17299047!1
X-Originating-IP: [103.22.144.67]
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 12845 invoked from network); 23 Dec 2014 02:26:17 -0000
Received: from ozlabs.org (HELO ozlabs.org) (103.22.144.67)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 02:26:17 -0000
Received: from authenticated.ozlabs.org (localhost [127.0.0.1])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by ozlabs.org (Postfix) with ESMTPSA id 2D71D14009B;
	Tue, 23 Dec 2014 13:26:12 +1100 (AEDT)
Date: Tue, 23 Dec 2014 13:26:05 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Linus <torvalds@linux-foundation.org>
Message-ID: <20141223132605.02d81e01@canb.auug.org.au>
In-Reply-To: <20141208103328.GE27367@arm.com>
References: <20141208184908.27bfd605@canb.auug.org.au>
	<20141208103328.GE27367@arm.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; i586-pc-linux-gnu)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <Xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Olof Johansson <olof@lixom.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: [Xen-devel] linux-next: missing merge fix patch for the merge of
 the xen-tip tree with the arm-soc tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6954697514048040809=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6954697514048040809==
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/QYtZIu3XwRWMpWpEXCkyZOj"; protocol="application/pgp-signature"

--Sig_/QYtZIu3XwRWMpWpEXCkyZOj
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi Linus,

I have been carrying this merge fix patch for some time that is now
needed in your tree:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 8 Dec 2014 18:46:59 +1100
Subject: [PATCH] arm: introduce is_device_dma_coherent merge fix

The merge of the (linux-next) xen-tip tree got a conflict in
arch/arm/include/asm/dma-mapping.h between commits a3a60f81ee6f
("dma-mapping: replace set_arch_dma_coherent_ops with
arch_setup_dma_ops") and 4bb25789ed28 ("arm: dma-mapping: plumb our
iommu mapping ops into arch_setup_dma_ops") from the arm-soc tree and
commit 3d5391ac6f5e ("arm: introduce is_device_dma_coherent") from the
xen-tip tree.  It was fixed up, but also required this additional fix.

"Looks good to me"-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/mm/dma-mapping.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 09645f00bd17..43064cbe58f9 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2058,6 +2058,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_b=
ase, u64 size,
 	else
 		dma_ops =3D arm_get_dma_map_ops(coherent);
=20
+	dev->archdata.dma_coherent =3D coherent;
 	set_dma_ops(dev, dma_ops);
 }
=20
--=20
2.1.3

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

--Sig_/QYtZIu3XwRWMpWpEXCkyZOj
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUmNLDAAoJEMDTa8Ir7ZwVBMkP/jNMLxNBOEL1OZAPi0U3azhT
SQS4SMTBhGIsW2FqDLGn4Wj1mDXvMB5rG0OQDZi++wE3x8mIQrbKTsmTym3GnNFU
273G3jM9/V7YFMo2b+iTGDA0xZxMtGBI7EqhXd+GH54qzQiT/U803/ejsgIWDzBK
ZwoBDEtoi9zU7M81h8mrpYS9XDJByH6gjiiB7kDDFwJxhPtIsi6TpUagtf6lY/Fj
GrY2neIWlIDClx+Fx0gpmiy3XIA1PL2xxcXgw70fc6oZSO6upDAR+9La0IdItiKY
QyLBJHhTT+WM8OqBbnz7oyrw2SWC1Y4HXdrr26EqmUuNhsGotbFG/XG9nwuTfUpl
0yU86iQCm7ov79xpQQjVmV3u1eN0620cXbSC4xEFQHeSnhuO1QLmWVsVgMHkJ53q
yD/r35sJy4r/VAH6a/B5cnEW14FJ+n7mec14dSohxRbDwkNbXn//h9NTuhybESQF
60l4dj0kRhY64LR4Klv0zj8omDe24mMrbbg8p8Gp1/PLQhidHS1ICXgeDZpGXcup
N2Mzzc/CORQa4GPQxNiO49KfEWoLO76YPNv/Vf4waIT618HNkpCCUlrU+7cen3JB
GcVhdo6iC4OV94Vp6boOdQRUGYbQUQL2ftb7PzgXI7nWAzPMCIYIYOOnPmIuCVTC
idW5VOEzpw6T+eM4DjYz
=+uGw
-----END PGP SIGNATURE-----

--Sig_/QYtZIu3XwRWMpWpEXCkyZOj--


--===============6954697514048040809==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6954697514048040809==--


From xen-devel-bounces@lists.xen.org Tue Dec 23 02:29:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 02:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3FDi-000137-8S; Tue, 23 Dec 2014 02:29:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yanghy@cn.fujitsu.com>) id 1Y3FDg-00012y-6F
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 02:29:08 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	FB/D0-17958-373D8945; Tue, 23 Dec 2014 02:29:07 +0000
X-Env-Sender: yanghy@cn.fujitsu.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1419301742!15288852!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1250 invoked from network); 23 Dec 2014 02:29:04 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-7.tower-31.messagelabs.com with SMTP;
	23 Dec 2014 02:29:04 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="45641321"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 23 Dec 2014 10:25:39 +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 sBN2SX1b003915;
	Tue, 23 Dec 2014 10:28:34 +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; Tue, 23 Dec 2014 10:29:06 +0800
Message-ID: <5498D339.4090705@cn.fujitsu.com>
Date: Tue, 23 Dec 2014 10:28:09 +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: Anthony Korzan <akorzan@gmail.com>
References: <788CC804-7FC8-40C4-B17B-E02CDB7F2683@gmail.com>
	<549388F6.9000108@cn.fujitsu.com>
	<6EF2F911-C0B4-441D-A25A-BD154832350E@gmail.com>
In-Reply-To: <6EF2F911-C0B4-441D-A25A-BD154832350E@gmail.com>
X-Originating-IP: [10.167.226.223]
Cc: rshriram@cs.ubc.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen 4.5-rc] remus-drbd incompatible with Linux
	3.6+ 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: 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

SGVsbG8sCgrlnKggMTIvMTkvMjAxNCAwNjoxNSBQTSwgQW50aG9ueSBLb3J6YW4g5YaZ6YGTOgo+
IFRoYW5rIHlvdSBmb3IgeW91ciByZXNwb25zZSwKPgo+IEkgY29tcGlsZWQgTGludXggMy4wLjEw
MSwgc2NoX3BsdWcsIGFuZCByZWluc3RhbGxlZCByZW11cy1kcmJkLiAgSSBzdGlsbCByZWNlaXZl
Cj4gdGhlIHNhbWUgZXJyb3Igd2hlbiBzdGFydGluZyByZW11czoKPj4geGM6IGVycm9yOiByZGV4
YWN0IGZhaWxlZCAoc2VsZWN0IHJldHVybmVkIDApOiBJbnRlcm5hbCBlcnJvcgo+PiB4YzogZXJy
b3I6IEVycm9yIHdoZW4gcmVhZGluZyBiYXRjaCBzaXplICgxMTAgPSBDb25uZWN0aW9uIHRpbWVk
IG91dCk6Cj4+IEludGVybmFsIGVycm9yCj4+IHhjOiBlcnJvcjogZXJyb3Igd2hlbiBidWZmZXJp
bmcgYmF0Y2gsIGZpbmlzaGluZyAoMTEwID0gQ29ubmVjdGlvbiB0aW1lZAo+PiBvdXQpOiBJbnRl
cm5hbCBlcnJvcgo+Cj4gVGhlIGVycm9yIG9jY3VycyBhdCBhbiBlYXJsaWVyIHBsdWcvdW5wbHVn
IHdpdGggZmFzdGVyIGludGVydmFscy4KCkkgdHJpZWQgdG8gcmVwcm9kdWNlIHRoZSBwcm9ibGVt
LCBidXQgbm8gbHVjaywgbXkgdGVzdCBlbnYgc2VlbXMgcHJldHR5IHN0YWJsZQp1bnRpbCBJIHVu
cGx1ZyB0aGUgcHJpbWFyeSdzIHBvd2VyLgp4YzogU2F2aW5nIG1lbW9yeTogaXRlciAyNjYzIChs
YXN0IHNlbnQgMjMxIHNraXBwZWQgMCk6IDEzMTA3Mi8xMzEwNzIgIDEwMCUKeGM6IFNhdmluZyBt
ZW1vcnk6IGl0ZXIgMjY2NCAobGFzdCBzZW50IDIyOCBza2lwcGVkIDApOiAxMzEwNzIvMTMxMDcy
ICAxMDAlCldyaXRlIGZhaWxlZDogQnJva2VuIHBpcGUKCkkgd2lsbCBzZW5kIHlvdSB0aGUgZGV0
YWlsZWQgY29uZmlndXJhdGlvbiBvZiBteSB0ZXN0IGVudmlyb25tZW50LgoKPgo+IEkgZGV0YWls
ZWQgbXkgaW5zdGFsbGF0aW9uIHN0ZXBzIG9uIG15IGNydWRlIGJsb2cgSSBqdXN0IG1hZGUsIGhv
cGVmdWxseSBpdCBoZWxwczoKPiBodHRwOi8vYWtvcnphbi5jb20vZG9rdXdpa2kvZG9rdS5waHA/
aWQ9eGVuOmluc3RhbGxhdGlvbgo+Cj4gRm9yIExpbnV4IEkgdXNlZCAzLjQgb3IgMy4wIGFuZCBh
ZGRlZCB0aGUgbmVjZXNzYXJ5IG9wdGlvbnMgaW4gbWFrZSBtZW51Y29uZmlnLgo+ICAgRm9yIDMu
MCBJIGhhZCB0byBnZXQgYSBzZXBhcmF0ZSBjb3B5IG9mIHNjaF9wbHVnLgo+Cj4gVGhlIG9ubHkg
dGhpbmcgSSBoYWQgdG8gZGlmZmVyZW50aWF0ZSBmcm9tLCBpcyB0aGF0IGZvciB0aGUgRG9tVSBj
b25maWcsIEkgaGFkCj4gdG8gdXNlIFsicGh5Oi9kZXYvZHJiZDEsdyx4dmRhIl0gaW5zdGVhZCBv
ZiBbImRyYmQ6dWJ1bnR1X3ZtXzEsdyx4dmRhIl0KPgo+Cj4gT24gYSBzaWRlIG5vdGU6IEludGVy
ZXN0aW5nbHksIGFmdGVyIGNoYW5naW5nIHRoZSBLZXJuZWwgZnJvbSAzLjQgdG8gMy4wIGFuZAo+
IGluc3RhbGxpbmcgYW4gZXh0ZXJuYWwgdmVyc2lvbiBvZiBzY2hfcGx1ZywgcHJvdmlkZWQgb24g
dGhlIFhlbiBXaWtpLCBwaW5ncyB0bwo+IHRoZSBEb21VIGRvbid0IGRpc3BsYXkgdGhlIGRlbGF5
IHRoZSBuZXR3b3JrIGJ1ZmZlcmluZyBjYXVzZXMsIGJ1dCBvbiBsb25nZXIKPiBpbnRlcnZhbHMg
eW91IGNhbiBmZWVsIHRoZSBleHRyYSB0aW1lIHRoZSBwaW5ncyB0YWtlIHRvIHJlc3BvbmQuICBX
ZWlyZC4KPgo+IE1hbnkgVGhhbmtzLAo+IEFudGhvbnkKPgo+IE9uIERlYyAxOCwgMjAxNCwgYXQg
OTowOSBQTSwgSG9uZ3lhbmcgWWFuZyA8eWFuZ2h5QGNuLmZ1aml0c3UuY29tCj4gPG1haWx0bzp5
YW5naHlAY24uZnVqaXRzdS5jb20+PiB3cm90ZToKPgo+PiBIaSwKPj4KPj4g5ZyoIDEyLzE5LzIw
MTQgMDU6NDggQU0sIEFudGhvbnkgS29yemFuIOWGmemBkzoKPj4+IEhlbGxvIQo+Pj4KPj4+IEkg
aGF2ZSBvbmx5IG1hbmFnZWQgdG8gZ2V0IFhlbiA0LjUncyBSZW11cyAid29ya2luZyIgb24gTGlu
dXggS2VybmVscyBsZXNzIHRoYW4KPj4+IDMuNS4gVGhlIHByb3ZpZGVkIHJlbXVzLWRyYmQsIGFz
IGRldGFpbGVkIGluIGRvY3MvUkVBRE1FLnJlbXVzIGFuZCBhdmFpbGFibGUKPj4+IGZyb20gaHR0
cHM6Ly9naXRodWIuY29tL3JzaHJpcmFtL3JlbXVzLWRyYmQgd2lsbCBub3QgY29tcGlsZSB3aXRo
IExpbnV4IEtlcm5lbHMKPj4+IDMuNiBhbmQgYWJvdmUuCj4+Cj4+IFRoZSBEUkJEIHlvdSBnZXQg
ZnJvbSBodHRwczovL2dpdGh1Yi5jb20vcnNocmlyYW0vcmVtdXMtZHJiZCBpcyBEUkJEIDguMy4x
MQo+PiBhbmQgdGhpcyB2ZXJzaW9uIG9ubHkgY29tcGF0aWJsZSB3aXRoIExpbnV4IDMuMH4zLjQs
IHNlZSB0aGUgdGFibGUgb24gdGhpcyBwYWdlOgo+PiBodHRwOi8vd3d3LmRyYmQub3JnL2Rvd25s
b2FkL21haW5saW5lLwo+Pgo+PiBJJ20gYWZyYWlkIERSQkQgOC4zLjExIGlzIHRoZSBvbmx5IHZl
cnNpb24gdGhhdCB5b3UgY2FuIGdldCBSZW11cyB3b3JrIG9uCj4+IGN1cnJlbnRseS4gSW4gdGhl
IHBhc3QsIFJlbXVzIGRpc2sgcmVwbGljYXRpb24gYmFzZWQgb24gYmxrdGFwMiwgYnV0IGJsa3Rh
cDIKPj4gaXMgZ2V0dGluZyBkZXByZWNhdGVkIEkgdGhpbmssIHRoZXJlJ3Mgbm8gbWFpbnRhaW5l
cnMgbm9yIHBhdGNoZXMgcmVjZW50IHllYXJzLgo+Pgo+PiBJZiB5b3UgYXJlIGludGVyZXN0LCB0
aGVyZSdzIGEgbmV3IEZUIHNvbHV0aW9uIGJhc2VkIG9uIFJlbXVzOgo+PiBodHRwOi8vd2lraS54
ZW4ub3JnL3dpa2kvQ09MT18tX0NvYXJzZV9HcmFpbl9Mb2NrX1N0ZXBwaW5nCj4+Cj4+IFRoaXMg
c29sdXRpb24gdXNlIGJsa3RhcDIgYXMgZGlzayByZXBsaWNhdGlvbiwgYW5kIGl0IGhhcyBsb3Rz
IG9mIHBhdGNoZXMgdG8KPj4gZ2V0IGJsa3RhcDIgd29yayB3aXRoIHhsLgo+Pgo+PiBGdXRoZXJt
b3JlLCB3ZSBhcmUgd29ya2luZyBvbiBhIGJldHRlciBzb2x1dGlvbiBvbiBkaXNrIHJlcGxpY2F0
aW9uIG9uIGJvdGgKPj4gUmVtdXMvQ09MTy4gQ09MTyBpcyBzdXBwb3NlZCB0byBnZXQgaW50byBY
ZW4gNC42Lgo+Pgo+Pj4KPj4+IE9uZSBvZiB0aGVzZSBlcnJvcnMgaXMgdGhhdCByZW11cy1kcmJk
IHVzZXMgYSB0d28gYXJndW1lbnQgdmVyc2lvbiBvZiB0aGUgbWFjcm8KPj4+IGt1bm1hcF9hdG9t
aWMgZm91bmQgaW4gaW5jbHVkZS9saW51eC9oaWdobWVtLmgKPj4+IFRoaXMgd2FzIGRlcHJlY2F0
ZWQgYW5kIGlzIG5vIGxvbmdlciBpbmNsdWRlZCBpbiBhbnkgS2VybmVscyBhYm92ZSAzLjYuCj4+
Pgo+Pj4gImVycm9yOiBtYWNybyAia3VubWFwX2F0b21pYyIgcGFzc2VkIDIgYXJndW1lbnRzLCBi
dXQgdGFrZXMganVzdCAxIgo+Pj4KPj4+IElzIHRoZXJlIGEgcGF0Y2ggYXZhaWxhYmxlPyAgSWYg
bm90LCB3aGF0IHNldCB1cCBkbyB0aGUgUmVtdXMgZGV2cyB1c2UgdG8gdGVzdD8KPj4+ICBJIGp1
c3QgbmVlZCBhICJzdGFibGUtaXNoIiBwbGF0Zm9ybSB0byBtb2RpZnkgcmVtdXMgb24uCj4+Pgo+
Pj4KPj4+IE5vdyBJIGRpZCBnZXQgUmVtdXMgIndvcmtpbmciIG9uIExpbnV4IDMuNCwgVWJ1bnR1
IDE0LjA0LCBhbmQgdGhlIGN1c3RvbQo+Pj4gcmVtdXMtZHJiZC4gIFRoZSBpc3N1ZSBJIHJ1biBp
bnRvIGlzIHRoYXQgUmVtdXMgb25seSBwbHVncyBhbmQgdW5wbHVncyBhIGZldwo+Pj4gaHVuZHJl
ZCB0aW1lcyB1bnRpbCB0aGVyZSBpcyBhICJDb25uZWN0aW9uIHRpbWVvdXQgZXJyb3IuIiAgSXQg
Y291bGQgYmUgdGhhdCBJCj4+PiBhbSB1c2luZyBhbiAib2xkIiBsaW51eCBrZXJuZWwgdmVyc2lv
biB3aXRob3V0IG11Y2ggWGVuIGludGVncmF0aW9uLCBidXQgSSdtCj4+PiBzdHVtcGVkIGFib3V0
IHRoaXMgZXJyb3I6Cj4+Cj4+IENhbiB5b3UgdHJ5IHRvIHVzZSBMaW51eCAzLjAgdG8gc2VlIGlm
IHRoZSBlcnJvciBzdGlsbCBleGlzdHM/Cj4+IEkgd2lsbCB0YWtlIGEgbG9vayBvbiB0aGlzIHBy
b2JsZW0gdG8gc2VlIGlmIEkgY2FuIHJlcHJvZHVjZSBpdC4KPj4KPj4+Cj4+PiAjIyMKPj4+IC4u
Lgo+Pj4geGM6IHByb2dyZXNzOiBSZWxvYWRpbmcgbWVtb3J5IHBhZ2VzOiA4OTUwMTUvNjU1MzYg
IDEzNjUlCj4+PiB4YzogU2F2aW5nIG1lbW9yeTogaXRlciAxNDE2IChsYXN0IHNlbnQgNTY4IHNr
aXBwZWQgMCk6IDY1NTM2LzY1NTM2ICAxMDAlCj4+PiAuLi4KPj4+IHhjOiBTYXZpbmcgbWVtb3J5
OiBpdGVyIDE0MjAgKGxhc3Qgc2VudCA1Njcgc2tpcHBlZCAwKTogNjU1MzYvNjU1MzYgIDEwMCUK
Pj4+IHhjOiBlcnJvcjogcmRleGFjdCBmYWlsZWQgKHNlbGVjdCByZXR1cm5lZCAwKTogSW50ZXJu
YWwgZXJyb3IKPj4+IHhjOiBlcnJvcjogRXJyb3Igd2hlbiByZWFkaW5nIGJhdGNoIHNpemUgKDEx
MCA9IENvbm5lY3Rpb24gdGltZWQgb3V0KTogSW50ZXJuYWwKPj4+IGVycm9yCj4+PiB4YzogZXJy
b3I6IGVycm9yIHdoZW4gYnVmZmVyaW5nIGJhdGNoLCBmaW5pc2hpbmcgKDExMCA9IENvbm5lY3Rp
b24gdGltZWQgb3V0KToKPj4+IEludGVybmFsIGVycm9yCj4+PiBtaWdyYXRpb24gdGFyZ2V0OiBS
ZW11cyBGYWlsb3ZlciBmb3IgZG9tYWluIDUKPj4+IGxpYnhsOiBlcnJvcjogbGlieGxfdXRpbHMu
Yzo0MzA6bGlieGxfcmVhZF9leGFjdGx5OiBmaWxlL3N0cmVhbSB0cnVuY2F0ZWQKPj4+IHJlYWRp
bmcgaXBjIG1zZyBoZWFkZXIgZnJvbSBkb21haW4gNSBzYXZlL3Jlc3RvcmUgaGVscGVyIHN0ZG91
dCBwaXBlCj4+PiBsaWJ4bDogZXJyb3I6IGxpYnhsX2V4ZWMuYzoxMjk6bGlieGxfcmVwb3J0X2No
aWxkX2V4aXRzdGF0dXM6IGRvbWFpbiA1Cj4+PiBzYXZlL3Jlc3RvcmUgaGVscGVyIFstMV0gZGll
ZCBkdWUgdG8gZmF0YWwgc2lnbmFsIEJyb2tlbiBwaXBlCj4+PiBsaWJ4bDogd2FybmluZzogbGli
eGxfZG9tLmM6MjAxNTpkb21haW5fc3VzcGVuZF9kb25lOiBSZW11czogRG9tYWluIHN1c3BlbmQK
Pj4+IHRlcm1pbmF0ZWQgd2l0aCByYyAtMywgdGVhcmRvd24gUmVtdXMgZGV2aWNlcy4uLgo+Pj4g
UmVtdXM6IEJhY2t1cCBmYWlsZWQ/IHJlc3VtaW5nIGRvbWFpbiBhdCBwcmltYXJ5Lgo+Pj4geGM6
IGVycm9yOiBEb20gNSBub3Qgc3VzcGVuZGVkOiAoc2h1dGRvd24gMCwgcmVhc29uIDI1NSk6IElu
dGVybmFsIGVycm9yCj4+PiBsaWJ4bDogZXJyb3I6IGxpYnhsLmM6NTA1OmxpYnhsX19kb21haW5f
cmVzdW1lOiB4Y19kb21haW5fcmVzdW1lIGZhaWxlZCBmb3IKPj4+IGRvbWFpbiA1OiBJbnZhbGlk
IGFyZ3VtZW50Cj4+PiAjIyMKPj4+Cj4+PiBTaW5jZXJlbHksCj4+PiBBbnRob255Cj4+Cj4+IC0t
Cj4+IFRoYW5rcywKPj4gWWFuZy4KPgoKLS0gClRoYW5rcywKWWFuZy4KCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Dec 23 02:29:13 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 02:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3FDi-000137-8S; Tue, 23 Dec 2014 02:29:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yanghy@cn.fujitsu.com>) id 1Y3FDg-00012y-6F
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 02:29:08 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	FB/D0-17958-373D8945; Tue, 23 Dec 2014 02:29:07 +0000
X-Env-Sender: yanghy@cn.fujitsu.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1419301742!15288852!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1250 invoked from network); 23 Dec 2014 02:29:04 -0000
Received: from cn.fujitsu.com (HELO heian.cn.fujitsu.com) (59.151.112.132)
	by server-7.tower-31.messagelabs.com with SMTP;
	23 Dec 2014 02:29:04 -0000
X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="45641321"
Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5])
	by heian.cn.fujitsu.com with ESMTP; 23 Dec 2014 10:25:39 +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 sBN2SX1b003915;
	Tue, 23 Dec 2014 10:28:34 +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; Tue, 23 Dec 2014 10:29:06 +0800
Message-ID: <5498D339.4090705@cn.fujitsu.com>
Date: Tue, 23 Dec 2014 10:28:09 +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: Anthony Korzan <akorzan@gmail.com>
References: <788CC804-7FC8-40C4-B17B-E02CDB7F2683@gmail.com>
	<549388F6.9000108@cn.fujitsu.com>
	<6EF2F911-C0B4-441D-A25A-BD154832350E@gmail.com>
In-Reply-To: <6EF2F911-C0B4-441D-A25A-BD154832350E@gmail.com>
X-Originating-IP: [10.167.226.223]
Cc: rshriram@cs.ubc.ca, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen 4.5-rc] remus-drbd incompatible with Linux
	3.6+ 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: 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

SGVsbG8sCgrlnKggMTIvMTkvMjAxNCAwNjoxNSBQTSwgQW50aG9ueSBLb3J6YW4g5YaZ6YGTOgo+
IFRoYW5rIHlvdSBmb3IgeW91ciByZXNwb25zZSwKPgo+IEkgY29tcGlsZWQgTGludXggMy4wLjEw
MSwgc2NoX3BsdWcsIGFuZCByZWluc3RhbGxlZCByZW11cy1kcmJkLiAgSSBzdGlsbCByZWNlaXZl
Cj4gdGhlIHNhbWUgZXJyb3Igd2hlbiBzdGFydGluZyByZW11czoKPj4geGM6IGVycm9yOiByZGV4
YWN0IGZhaWxlZCAoc2VsZWN0IHJldHVybmVkIDApOiBJbnRlcm5hbCBlcnJvcgo+PiB4YzogZXJy
b3I6IEVycm9yIHdoZW4gcmVhZGluZyBiYXRjaCBzaXplICgxMTAgPSBDb25uZWN0aW9uIHRpbWVk
IG91dCk6Cj4+IEludGVybmFsIGVycm9yCj4+IHhjOiBlcnJvcjogZXJyb3Igd2hlbiBidWZmZXJp
bmcgYmF0Y2gsIGZpbmlzaGluZyAoMTEwID0gQ29ubmVjdGlvbiB0aW1lZAo+PiBvdXQpOiBJbnRl
cm5hbCBlcnJvcgo+Cj4gVGhlIGVycm9yIG9jY3VycyBhdCBhbiBlYXJsaWVyIHBsdWcvdW5wbHVn
IHdpdGggZmFzdGVyIGludGVydmFscy4KCkkgdHJpZWQgdG8gcmVwcm9kdWNlIHRoZSBwcm9ibGVt
LCBidXQgbm8gbHVjaywgbXkgdGVzdCBlbnYgc2VlbXMgcHJldHR5IHN0YWJsZQp1bnRpbCBJIHVu
cGx1ZyB0aGUgcHJpbWFyeSdzIHBvd2VyLgp4YzogU2F2aW5nIG1lbW9yeTogaXRlciAyNjYzIChs
YXN0IHNlbnQgMjMxIHNraXBwZWQgMCk6IDEzMTA3Mi8xMzEwNzIgIDEwMCUKeGM6IFNhdmluZyBt
ZW1vcnk6IGl0ZXIgMjY2NCAobGFzdCBzZW50IDIyOCBza2lwcGVkIDApOiAxMzEwNzIvMTMxMDcy
ICAxMDAlCldyaXRlIGZhaWxlZDogQnJva2VuIHBpcGUKCkkgd2lsbCBzZW5kIHlvdSB0aGUgZGV0
YWlsZWQgY29uZmlndXJhdGlvbiBvZiBteSB0ZXN0IGVudmlyb25tZW50LgoKPgo+IEkgZGV0YWls
ZWQgbXkgaW5zdGFsbGF0aW9uIHN0ZXBzIG9uIG15IGNydWRlIGJsb2cgSSBqdXN0IG1hZGUsIGhv
cGVmdWxseSBpdCBoZWxwczoKPiBodHRwOi8vYWtvcnphbi5jb20vZG9rdXdpa2kvZG9rdS5waHA/
aWQ9eGVuOmluc3RhbGxhdGlvbgo+Cj4gRm9yIExpbnV4IEkgdXNlZCAzLjQgb3IgMy4wIGFuZCBh
ZGRlZCB0aGUgbmVjZXNzYXJ5IG9wdGlvbnMgaW4gbWFrZSBtZW51Y29uZmlnLgo+ICAgRm9yIDMu
MCBJIGhhZCB0byBnZXQgYSBzZXBhcmF0ZSBjb3B5IG9mIHNjaF9wbHVnLgo+Cj4gVGhlIG9ubHkg
dGhpbmcgSSBoYWQgdG8gZGlmZmVyZW50aWF0ZSBmcm9tLCBpcyB0aGF0IGZvciB0aGUgRG9tVSBj
b25maWcsIEkgaGFkCj4gdG8gdXNlIFsicGh5Oi9kZXYvZHJiZDEsdyx4dmRhIl0gaW5zdGVhZCBv
ZiBbImRyYmQ6dWJ1bnR1X3ZtXzEsdyx4dmRhIl0KPgo+Cj4gT24gYSBzaWRlIG5vdGU6IEludGVy
ZXN0aW5nbHksIGFmdGVyIGNoYW5naW5nIHRoZSBLZXJuZWwgZnJvbSAzLjQgdG8gMy4wIGFuZAo+
IGluc3RhbGxpbmcgYW4gZXh0ZXJuYWwgdmVyc2lvbiBvZiBzY2hfcGx1ZywgcHJvdmlkZWQgb24g
dGhlIFhlbiBXaWtpLCBwaW5ncyB0bwo+IHRoZSBEb21VIGRvbid0IGRpc3BsYXkgdGhlIGRlbGF5
IHRoZSBuZXR3b3JrIGJ1ZmZlcmluZyBjYXVzZXMsIGJ1dCBvbiBsb25nZXIKPiBpbnRlcnZhbHMg
eW91IGNhbiBmZWVsIHRoZSBleHRyYSB0aW1lIHRoZSBwaW5ncyB0YWtlIHRvIHJlc3BvbmQuICBX
ZWlyZC4KPgo+IE1hbnkgVGhhbmtzLAo+IEFudGhvbnkKPgo+IE9uIERlYyAxOCwgMjAxNCwgYXQg
OTowOSBQTSwgSG9uZ3lhbmcgWWFuZyA8eWFuZ2h5QGNuLmZ1aml0c3UuY29tCj4gPG1haWx0bzp5
YW5naHlAY24uZnVqaXRzdS5jb20+PiB3cm90ZToKPgo+PiBIaSwKPj4KPj4g5ZyoIDEyLzE5LzIw
MTQgMDU6NDggQU0sIEFudGhvbnkgS29yemFuIOWGmemBkzoKPj4+IEhlbGxvIQo+Pj4KPj4+IEkg
aGF2ZSBvbmx5IG1hbmFnZWQgdG8gZ2V0IFhlbiA0LjUncyBSZW11cyAid29ya2luZyIgb24gTGlu
dXggS2VybmVscyBsZXNzIHRoYW4KPj4+IDMuNS4gVGhlIHByb3ZpZGVkIHJlbXVzLWRyYmQsIGFz
IGRldGFpbGVkIGluIGRvY3MvUkVBRE1FLnJlbXVzIGFuZCBhdmFpbGFibGUKPj4+IGZyb20gaHR0
cHM6Ly9naXRodWIuY29tL3JzaHJpcmFtL3JlbXVzLWRyYmQgd2lsbCBub3QgY29tcGlsZSB3aXRo
IExpbnV4IEtlcm5lbHMKPj4+IDMuNiBhbmQgYWJvdmUuCj4+Cj4+IFRoZSBEUkJEIHlvdSBnZXQg
ZnJvbSBodHRwczovL2dpdGh1Yi5jb20vcnNocmlyYW0vcmVtdXMtZHJiZCBpcyBEUkJEIDguMy4x
MQo+PiBhbmQgdGhpcyB2ZXJzaW9uIG9ubHkgY29tcGF0aWJsZSB3aXRoIExpbnV4IDMuMH4zLjQs
IHNlZSB0aGUgdGFibGUgb24gdGhpcyBwYWdlOgo+PiBodHRwOi8vd3d3LmRyYmQub3JnL2Rvd25s
b2FkL21haW5saW5lLwo+Pgo+PiBJJ20gYWZyYWlkIERSQkQgOC4zLjExIGlzIHRoZSBvbmx5IHZl
cnNpb24gdGhhdCB5b3UgY2FuIGdldCBSZW11cyB3b3JrIG9uCj4+IGN1cnJlbnRseS4gSW4gdGhl
IHBhc3QsIFJlbXVzIGRpc2sgcmVwbGljYXRpb24gYmFzZWQgb24gYmxrdGFwMiwgYnV0IGJsa3Rh
cDIKPj4gaXMgZ2V0dGluZyBkZXByZWNhdGVkIEkgdGhpbmssIHRoZXJlJ3Mgbm8gbWFpbnRhaW5l
cnMgbm9yIHBhdGNoZXMgcmVjZW50IHllYXJzLgo+Pgo+PiBJZiB5b3UgYXJlIGludGVyZXN0LCB0
aGVyZSdzIGEgbmV3IEZUIHNvbHV0aW9uIGJhc2VkIG9uIFJlbXVzOgo+PiBodHRwOi8vd2lraS54
ZW4ub3JnL3dpa2kvQ09MT18tX0NvYXJzZV9HcmFpbl9Mb2NrX1N0ZXBwaW5nCj4+Cj4+IFRoaXMg
c29sdXRpb24gdXNlIGJsa3RhcDIgYXMgZGlzayByZXBsaWNhdGlvbiwgYW5kIGl0IGhhcyBsb3Rz
IG9mIHBhdGNoZXMgdG8KPj4gZ2V0IGJsa3RhcDIgd29yayB3aXRoIHhsLgo+Pgo+PiBGdXRoZXJt
b3JlLCB3ZSBhcmUgd29ya2luZyBvbiBhIGJldHRlciBzb2x1dGlvbiBvbiBkaXNrIHJlcGxpY2F0
aW9uIG9uIGJvdGgKPj4gUmVtdXMvQ09MTy4gQ09MTyBpcyBzdXBwb3NlZCB0byBnZXQgaW50byBY
ZW4gNC42Lgo+Pgo+Pj4KPj4+IE9uZSBvZiB0aGVzZSBlcnJvcnMgaXMgdGhhdCByZW11cy1kcmJk
IHVzZXMgYSB0d28gYXJndW1lbnQgdmVyc2lvbiBvZiB0aGUgbWFjcm8KPj4+IGt1bm1hcF9hdG9t
aWMgZm91bmQgaW4gaW5jbHVkZS9saW51eC9oaWdobWVtLmgKPj4+IFRoaXMgd2FzIGRlcHJlY2F0
ZWQgYW5kIGlzIG5vIGxvbmdlciBpbmNsdWRlZCBpbiBhbnkgS2VybmVscyBhYm92ZSAzLjYuCj4+
Pgo+Pj4gImVycm9yOiBtYWNybyAia3VubWFwX2F0b21pYyIgcGFzc2VkIDIgYXJndW1lbnRzLCBi
dXQgdGFrZXMganVzdCAxIgo+Pj4KPj4+IElzIHRoZXJlIGEgcGF0Y2ggYXZhaWxhYmxlPyAgSWYg
bm90LCB3aGF0IHNldCB1cCBkbyB0aGUgUmVtdXMgZGV2cyB1c2UgdG8gdGVzdD8KPj4+ICBJIGp1
c3QgbmVlZCBhICJzdGFibGUtaXNoIiBwbGF0Zm9ybSB0byBtb2RpZnkgcmVtdXMgb24uCj4+Pgo+
Pj4KPj4+IE5vdyBJIGRpZCBnZXQgUmVtdXMgIndvcmtpbmciIG9uIExpbnV4IDMuNCwgVWJ1bnR1
IDE0LjA0LCBhbmQgdGhlIGN1c3RvbQo+Pj4gcmVtdXMtZHJiZC4gIFRoZSBpc3N1ZSBJIHJ1biBp
bnRvIGlzIHRoYXQgUmVtdXMgb25seSBwbHVncyBhbmQgdW5wbHVncyBhIGZldwo+Pj4gaHVuZHJl
ZCB0aW1lcyB1bnRpbCB0aGVyZSBpcyBhICJDb25uZWN0aW9uIHRpbWVvdXQgZXJyb3IuIiAgSXQg
Y291bGQgYmUgdGhhdCBJCj4+PiBhbSB1c2luZyBhbiAib2xkIiBsaW51eCBrZXJuZWwgdmVyc2lv
biB3aXRob3V0IG11Y2ggWGVuIGludGVncmF0aW9uLCBidXQgSSdtCj4+PiBzdHVtcGVkIGFib3V0
IHRoaXMgZXJyb3I6Cj4+Cj4+IENhbiB5b3UgdHJ5IHRvIHVzZSBMaW51eCAzLjAgdG8gc2VlIGlm
IHRoZSBlcnJvciBzdGlsbCBleGlzdHM/Cj4+IEkgd2lsbCB0YWtlIGEgbG9vayBvbiB0aGlzIHBy
b2JsZW0gdG8gc2VlIGlmIEkgY2FuIHJlcHJvZHVjZSBpdC4KPj4KPj4+Cj4+PiAjIyMKPj4+IC4u
Lgo+Pj4geGM6IHByb2dyZXNzOiBSZWxvYWRpbmcgbWVtb3J5IHBhZ2VzOiA4OTUwMTUvNjU1MzYg
IDEzNjUlCj4+PiB4YzogU2F2aW5nIG1lbW9yeTogaXRlciAxNDE2IChsYXN0IHNlbnQgNTY4IHNr
aXBwZWQgMCk6IDY1NTM2LzY1NTM2ICAxMDAlCj4+PiAuLi4KPj4+IHhjOiBTYXZpbmcgbWVtb3J5
OiBpdGVyIDE0MjAgKGxhc3Qgc2VudCA1Njcgc2tpcHBlZCAwKTogNjU1MzYvNjU1MzYgIDEwMCUK
Pj4+IHhjOiBlcnJvcjogcmRleGFjdCBmYWlsZWQgKHNlbGVjdCByZXR1cm5lZCAwKTogSW50ZXJu
YWwgZXJyb3IKPj4+IHhjOiBlcnJvcjogRXJyb3Igd2hlbiByZWFkaW5nIGJhdGNoIHNpemUgKDEx
MCA9IENvbm5lY3Rpb24gdGltZWQgb3V0KTogSW50ZXJuYWwKPj4+IGVycm9yCj4+PiB4YzogZXJy
b3I6IGVycm9yIHdoZW4gYnVmZmVyaW5nIGJhdGNoLCBmaW5pc2hpbmcgKDExMCA9IENvbm5lY3Rp
b24gdGltZWQgb3V0KToKPj4+IEludGVybmFsIGVycm9yCj4+PiBtaWdyYXRpb24gdGFyZ2V0OiBS
ZW11cyBGYWlsb3ZlciBmb3IgZG9tYWluIDUKPj4+IGxpYnhsOiBlcnJvcjogbGlieGxfdXRpbHMu
Yzo0MzA6bGlieGxfcmVhZF9leGFjdGx5OiBmaWxlL3N0cmVhbSB0cnVuY2F0ZWQKPj4+IHJlYWRp
bmcgaXBjIG1zZyBoZWFkZXIgZnJvbSBkb21haW4gNSBzYXZlL3Jlc3RvcmUgaGVscGVyIHN0ZG91
dCBwaXBlCj4+PiBsaWJ4bDogZXJyb3I6IGxpYnhsX2V4ZWMuYzoxMjk6bGlieGxfcmVwb3J0X2No
aWxkX2V4aXRzdGF0dXM6IGRvbWFpbiA1Cj4+PiBzYXZlL3Jlc3RvcmUgaGVscGVyIFstMV0gZGll
ZCBkdWUgdG8gZmF0YWwgc2lnbmFsIEJyb2tlbiBwaXBlCj4+PiBsaWJ4bDogd2FybmluZzogbGli
eGxfZG9tLmM6MjAxNTpkb21haW5fc3VzcGVuZF9kb25lOiBSZW11czogRG9tYWluIHN1c3BlbmQK
Pj4+IHRlcm1pbmF0ZWQgd2l0aCByYyAtMywgdGVhcmRvd24gUmVtdXMgZGV2aWNlcy4uLgo+Pj4g
UmVtdXM6IEJhY2t1cCBmYWlsZWQ/IHJlc3VtaW5nIGRvbWFpbiBhdCBwcmltYXJ5Lgo+Pj4geGM6
IGVycm9yOiBEb20gNSBub3Qgc3VzcGVuZGVkOiAoc2h1dGRvd24gMCwgcmVhc29uIDI1NSk6IElu
dGVybmFsIGVycm9yCj4+PiBsaWJ4bDogZXJyb3I6IGxpYnhsLmM6NTA1OmxpYnhsX19kb21haW5f
cmVzdW1lOiB4Y19kb21haW5fcmVzdW1lIGZhaWxlZCBmb3IKPj4+IGRvbWFpbiA1OiBJbnZhbGlk
IGFyZ3VtZW50Cj4+PiAjIyMKPj4+Cj4+PiBTaW5jZXJlbHksCj4+PiBBbnRob255Cj4+Cj4+IC0t
Cj4+IFRoYW5rcywKPj4gWWFuZy4KPgoKLS0gClRoYW5rcywKWWFuZy4KCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Dec 23 03:00:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 03: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 1Y3Fhr-0001ry-2X; Tue, 23 Dec 2014 03:00:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3Fhp-0001rt-IX
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 03:00:17 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	81/18-23865-0CAD8945; Tue, 23 Dec 2014 03:00:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1419303614!11548918!1
X-Originating-IP: [66.165.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 28199 invoked from network); 23 Dec 2014 03:00:15 -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;
	23 Dec 2014 03:00:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,628,1413244800"; d="scan'208";a="207245623"
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.210.2; Mon, 22 Dec 2014 22:00: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 1Y3Fhk-0003y9-Rx;
	Tue, 23 Dec 2014 03:00:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3Fhk-0008RA-6T;
	Tue, 23 Dec 2014 03:00:12 +0000
Date: Tue, 23 Dec 2014 03:00:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32581-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] 32581: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32581 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32581/

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. 32564
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 32564

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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  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-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                f9f7b9d7aeedb0f6150bc9df08542c3a0b67a4ef
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

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-amd64-xl-pvh-amd                                  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                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 23 03:00:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 03: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 1Y3Fhr-0001ry-2X; Tue, 23 Dec 2014 03:00:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3Fhp-0001rt-IX
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 03:00:17 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	81/18-23865-0CAD8945; Tue, 23 Dec 2014 03:00:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1419303614!11548918!1
X-Originating-IP: [66.165.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 28199 invoked from network); 23 Dec 2014 03:00:15 -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;
	23 Dec 2014 03:00:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,628,1413244800"; d="scan'208";a="207245623"
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.210.2; Mon, 22 Dec 2014 22:00: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 1Y3Fhk-0003y9-Rx;
	Tue, 23 Dec 2014 03:00:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3Fhk-0008RA-6T;
	Tue, 23 Dec 2014 03:00:12 +0000
Date: Tue, 23 Dec 2014 03:00:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32581-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] 32581: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32581 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32581/

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. 32564
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 32564

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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  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-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                f9f7b9d7aeedb0f6150bc9df08542c3a0b67a4ef
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

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-amd64-xl-pvh-amd                                  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                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 23 03:43:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 03:43:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3GND-00031C-SZ; Tue, 23 Dec 2014 03:43:03 +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 1Y3GNC-000317-G6
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 03:43:02 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	95/33-17936-5C4E8945; Tue, 23 Dec 2014 03:43:01 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1419306179!16767285!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 25320 invoked from network); 23 Dec 2014 03:43:00 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 03:43:00 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 22 Dec 2014 20:42:58 -0700
Message-Id: <5499553C0200006600087821@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 22 Dec 2014 20:42:52 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
	<1418915443.11882.86.camel@citrix.com>
	<54942BF20200006600086A4B@soto.provo.novell.com>
	<1418984720.20028.15.camel@citrix.com>
In-Reply-To: <1418984720.20028.15.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/19/2014 at 06:25 PM, in message <1418984720.20028.15.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Thu, 2014-12-18 at 22:45 -0700, Chun Yan Liu wrote: 
> >  
> > >>> On 12/18/2014 at 11:10 PM, in message  
> <1418915443.11882.86.camel@citrix.com>, 
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:  
> > > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:  
> > > > Changes to V8:  
> > > >   * add an overview document, so that one can has a overall look  
> > > >     about the whole domain snapshot work, limits, requirements,  
> > > >     how to do, etc.  
> > > >   
> > > > =====================================================================  
> > > > Domain snapshot overview  
> > >   
> > > I don't see a similar section for disk snapshots, are you not  
> > > considering those here except as a part of a domain snapshot or is this  
> > > an oversight?  
> > >   
> > > There are three main use cases (that I know of at least) for  
> > > snapshotting like behaviour.  
> > >   
> > > One is as you've mentioned below for "backup", i.e. to preserve the VM  
> > > at a certain point in time in order to be able to roll back to it. Is  
> > > this the only usecase you are considering?  
> >  
> > Yes. I didn't take disk snapshot thing into the scope. 
> >  
> > >   
> > > A second use case is to support "gold image" type deployments, i.e.  
> > > where you create one baseline single disk image and then clone it  
> > > multiple times to deploy lots of guests. I think this is usually a "disk  
> > > snapshot" type thing, but maybe it can be implemented as restoring a  
> > > gold domain snapshot multiple times (e.g. for start of day performance  
> > > reasons).  
> >  
> > As we initially discussed about the thing, disk snapshot thing can be done 
> > be existing tools directly like qemu-img, vhd-util. 
>  
> I was reading this section as a more generic overview of snapshotting, 
> without reference to where/how things might ultimately be implemented. 
>  
> From a design point of view it would be useful to cover the various use 
> cases, even if the solution is that the user implements them using CLI 
> tools by hand (xl) or the toolstack does it for them internally 
> (libvirt). 
>  
> This way we can more clearly see the full picture, which allows us to 
> validate that we are making the right choices about what goes where. 

OK. I see. I think this user case is more like how to use the snapshot, rather
than how to implement snapshot. Right?
'Gold image' or 'Gold domain', the needed work is more like cloning disks.

>  
> > > The third case, (which is similar to the first), is taking a disk  
> > > snapshot in order to be able to run you usual backup software on the  
> > > snapshot (which is now unchanging, which is handy) and then deleting the  
> > > disk snapshot (this differs from the first case in which disk is active  
> > > after the snapshot, and due to the lack of the memory part).  
> >  
> > Sorry, I'm still not quite clear about what this user case wants to do. 
>  
> The user has an active domain which they want to backup, but backup 
> software often does not cope well if the data is changing under its 
> feet. 
>  
> So the users wants to take a snapshot of the domains disks while leaving 
> the domain running, so they can backup that static version of the disk 
> out of band from the VM itself (e.g. by attaching it to a separate 
> backup VM). 

Got it. So that's simply disk-only snapshot when domian is active. As you
mentioned below, that needs guest agent to quiesce the disks. But currently
xen hypervisor can't support that, right?

>  
> This may require a guest agent to quiesce the disks. 
>  
> > >   
> > > > * ability to parse user config file  
> > > >   
> > > >   [2] Disk snapshot requirements:  
> > > >   - external tools: qemu-img, lvcreate, vhd-util, etc.  
> > > >   - for basic goal, we support 'raw' and 'qcow2' backend types  
> > > >     only. Then it requires:  
> > > >     libxl qmp command or "qemu-img" (when qemu process does not  
> > > >     exist)  
> > > >   
> > > >   
> > > > 3. Interaction with other operations:  
> > > >   
> > > > No.  
> > >   
> > > What about shutdown/dying as you noted above? What about migration or  
> > > regular save/restore?  
> >  
> > Since xl now has no idea of the existence of snapshot, 
>  
> what about libvirt? This section is an overview, so making toolstack 
> specific assumptions is confusing.

Understand. I think most questions here are about a general overview vs a xl
specific view. Which I provided is xl specific, which you suggested is a
general overview. I'll update.
 
>  
> >  so when writing this 
> > document I turned to depends on users to delete snapshots before or after 
> > deleting a domain (like shutdown, destroy, save, migrate away). User should 
> > know where memory is saved, and disk snapshot related info. 
>  
> What I meant was what happens if you try to snapshot a domain while it 
> is being shutdown or being migrated?

Ah, see. I should add words here. As described above, snapshot is not supported
when domain is being shutdown or dying.

Thanks very much for your precious time before holiday.
Merry Christmas! 

-Chunyan

> There clearly has to be some sort 
> of interaction, even if it is "there is a global toolstack lock" or "the 
> user is advised not to do 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 Tue Dec 23 03:43:34 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 03:43:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3GND-00031C-SZ; Tue, 23 Dec 2014 03:43:03 +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 1Y3GNC-000317-G6
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 03:43:02 +0000
Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id
	95/33-17936-5C4E8945; Tue, 23 Dec 2014 03:43:01 +0000
X-Env-Sender: cyliu@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1419306179!16767285!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 25320 invoked from network); 23 Dec 2014 03:43:00 -0000
Received: from soto.provo.novell.com (HELO soto.provo.novell.com)
	(137.65.250.214)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 03:43:00 -0000
Received: from INET-RELAY2-MTA by soto.provo.novell.com
	with Novell_GroupWise; Mon, 22 Dec 2014 20:42:58 -0700
Message-Id: <5499553C0200006600087821@soto.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Mon, 22 Dec 2014 20:42:52 -0700
From: "Chun Yan Liu" <cyliu@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1418711577-15449-1-git-send-email-cyliu@suse.com>
	<1418711577-15449-3-git-send-email-cyliu@suse.com>
	<1418915443.11882.86.camel@citrix.com>
	<54942BF20200006600086A4B@soto.provo.novell.com>
	<1418984720.20028.15.camel@citrix.com>
In-Reply-To: <1418984720.20028.15.camel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com, Jim Fehlig <JFEHLIG@suse.com>,
	wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/19/2014 at 06:25 PM, in message <1418984720.20028.15.camel@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Thu, 2014-12-18 at 22:45 -0700, Chun Yan Liu wrote: 
> >  
> > >>> On 12/18/2014 at 11:10 PM, in message  
> <1418915443.11882.86.camel@citrix.com>, 
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:  
> > > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:  
> > > > Changes to V8:  
> > > >   * add an overview document, so that one can has a overall look  
> > > >     about the whole domain snapshot work, limits, requirements,  
> > > >     how to do, etc.  
> > > >   
> > > > =====================================================================  
> > > > Domain snapshot overview  
> > >   
> > > I don't see a similar section for disk snapshots, are you not  
> > > considering those here except as a part of a domain snapshot or is this  
> > > an oversight?  
> > >   
> > > There are three main use cases (that I know of at least) for  
> > > snapshotting like behaviour.  
> > >   
> > > One is as you've mentioned below for "backup", i.e. to preserve the VM  
> > > at a certain point in time in order to be able to roll back to it. Is  
> > > this the only usecase you are considering?  
> >  
> > Yes. I didn't take disk snapshot thing into the scope. 
> >  
> > >   
> > > A second use case is to support "gold image" type deployments, i.e.  
> > > where you create one baseline single disk image and then clone it  
> > > multiple times to deploy lots of guests. I think this is usually a "disk  
> > > snapshot" type thing, but maybe it can be implemented as restoring a  
> > > gold domain snapshot multiple times (e.g. for start of day performance  
> > > reasons).  
> >  
> > As we initially discussed about the thing, disk snapshot thing can be done 
> > be existing tools directly like qemu-img, vhd-util. 
>  
> I was reading this section as a more generic overview of snapshotting, 
> without reference to where/how things might ultimately be implemented. 
>  
> From a design point of view it would be useful to cover the various use 
> cases, even if the solution is that the user implements them using CLI 
> tools by hand (xl) or the toolstack does it for them internally 
> (libvirt). 
>  
> This way we can more clearly see the full picture, which allows us to 
> validate that we are making the right choices about what goes where. 

OK. I see. I think this user case is more like how to use the snapshot, rather
than how to implement snapshot. Right?
'Gold image' or 'Gold domain', the needed work is more like cloning disks.

>  
> > > The third case, (which is similar to the first), is taking a disk  
> > > snapshot in order to be able to run you usual backup software on the  
> > > snapshot (which is now unchanging, which is handy) and then deleting the  
> > > disk snapshot (this differs from the first case in which disk is active  
> > > after the snapshot, and due to the lack of the memory part).  
> >  
> > Sorry, I'm still not quite clear about what this user case wants to do. 
>  
> The user has an active domain which they want to backup, but backup 
> software often does not cope well if the data is changing under its 
> feet. 
>  
> So the users wants to take a snapshot of the domains disks while leaving 
> the domain running, so they can backup that static version of the disk 
> out of band from the VM itself (e.g. by attaching it to a separate 
> backup VM). 

Got it. So that's simply disk-only snapshot when domian is active. As you
mentioned below, that needs guest agent to quiesce the disks. But currently
xen hypervisor can't support that, right?

>  
> This may require a guest agent to quiesce the disks. 
>  
> > >   
> > > > * ability to parse user config file  
> > > >   
> > > >   [2] Disk snapshot requirements:  
> > > >   - external tools: qemu-img, lvcreate, vhd-util, etc.  
> > > >   - for basic goal, we support 'raw' and 'qcow2' backend types  
> > > >     only. Then it requires:  
> > > >     libxl qmp command or "qemu-img" (when qemu process does not  
> > > >     exist)  
> > > >   
> > > >   
> > > > 3. Interaction with other operations:  
> > > >   
> > > > No.  
> > >   
> > > What about shutdown/dying as you noted above? What about migration or  
> > > regular save/restore?  
> >  
> > Since xl now has no idea of the existence of snapshot, 
>  
> what about libvirt? This section is an overview, so making toolstack 
> specific assumptions is confusing.

Understand. I think most questions here are about a general overview vs a xl
specific view. Which I provided is xl specific, which you suggested is a
general overview. I'll update.
 
>  
> >  so when writing this 
> > document I turned to depends on users to delete snapshots before or after 
> > deleting a domain (like shutdown, destroy, save, migrate away). User should 
> > know where memory is saved, and disk snapshot related info. 
>  
> What I meant was what happens if you try to snapshot a domain while it 
> is being shutdown or being migrated?

Ah, see. I should add words here. As described above, snapshot is not supported
when domain is being shutdown or dying.

Thanks very much for your precious time before holiday.
Merry Christmas! 

-Chunyan

> There clearly has to be some sort 
> of interaction, even if it is "there is a global toolstack lock" or "the 
> user is advised not to do 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 Tue Dec 23 03:43:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 03:43:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3GNp-00035A-GD; Tue, 23 Dec 2014 03:43:41 +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 1Y3GNo-00034y-Fq
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 03:43:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	56/90-25276-BE4E8945; Tue, 23 Dec 2014 03:43:39 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1419306218!17392854!1
X-Originating-IP: [209.85.216.182]
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 16483 invoked from network); 23 Dec 2014 03:43:39 -0000
Received: from mail-qc0-f182.google.com (HELO mail-qc0-f182.google.com)
	(209.85.216.182)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 03:43:39 -0000
Received: by mail-qc0-f182.google.com with SMTP id r5so4271903qcx.27
	for <xen-devel@lists.xen.org>; Mon, 22 Dec 2014 19:43:38 -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=VmKWIM4eQO6CD5VIs0+Je3Di1t3/JoQb0ngGXCSPqog=;
	b=hA5mXUK4LpbzL12gCw81PbANxoT/RX9ijc0tuza4+5vjWNQW8RFbT1+cSHkmxAzdQv
	loKomjcMLN57OCOoObULEr9GddC++11071gyZRo6tJVkc9oxXdGjsK2eO28OixKRKsIv
	9UjLeJYiuI3/lwoUM3wHz1OQBSq6b4BE6Q2x1Pvy3pao+2K2xNb2WIhilEkYO6MQkzNe
	z662SYvUDpdhyCCNn+/GlkO5s8Tyir5A0CN4NLNSiC/oB1wf3rwocEcsY0G9UwGuSVbW
	Ni6BqQ+QeVvz7xv++tepqiokDi/jteVMCPdcnSe1BXGw9Cl/vhH0C6qB/ELG/qOX49qV
	3uag==
MIME-Version: 1.0
X-Received: by 10.229.114.137 with SMTP id e9mr42341069qcq.0.1419306218275;
	Mon, 22 Dec 2014 19:43:38 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Mon, 22 Dec 2014 19:43:38 -0800 (PST)
Date: Mon, 22 Dec 2014 19:43:38 -0800
Message-ID: <CAAiw7JnT_s=eS5dR8xvUKChxox8BcQpzuFpsPtJo5YRegFAKBg@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	manish.jaggi@caviumnetworks.com, Vijaya.Kumar@caviumnetworks.com
Subject: [Xen-devel] [query] gic_update_one_lr r/w from ICH_LR rather than
	vcpu context lr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

In gic.c, gic_update_one_lr, gic_hw_ops is called to read and write to an LR.
why is read/write not done on the LRs stored in the vcpu context ?

Could you please elaborate why it is done this way.


-Regards
manish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 03:43:42 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 03:43:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3GNp-00035A-GD; Tue, 23 Dec 2014 03:43:41 +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 1Y3GNo-00034y-Fq
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 03:43:40 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	56/90-25276-BE4E8945; Tue, 23 Dec 2014 03:43:39 +0000
X-Env-Sender: manishjaggi.oss@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1419306218!17392854!1
X-Originating-IP: [209.85.216.182]
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 16483 invoked from network); 23 Dec 2014 03:43:39 -0000
Received: from mail-qc0-f182.google.com (HELO mail-qc0-f182.google.com)
	(209.85.216.182)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 03:43:39 -0000
Received: by mail-qc0-f182.google.com with SMTP id r5so4271903qcx.27
	for <xen-devel@lists.xen.org>; Mon, 22 Dec 2014 19:43:38 -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=VmKWIM4eQO6CD5VIs0+Je3Di1t3/JoQb0ngGXCSPqog=;
	b=hA5mXUK4LpbzL12gCw81PbANxoT/RX9ijc0tuza4+5vjWNQW8RFbT1+cSHkmxAzdQv
	loKomjcMLN57OCOoObULEr9GddC++11071gyZRo6tJVkc9oxXdGjsK2eO28OixKRKsIv
	9UjLeJYiuI3/lwoUM3wHz1OQBSq6b4BE6Q2x1Pvy3pao+2K2xNb2WIhilEkYO6MQkzNe
	z662SYvUDpdhyCCNn+/GlkO5s8Tyir5A0CN4NLNSiC/oB1wf3rwocEcsY0G9UwGuSVbW
	Ni6BqQ+QeVvz7xv++tepqiokDi/jteVMCPdcnSe1BXGw9Cl/vhH0C6qB/ELG/qOX49qV
	3uag==
MIME-Version: 1.0
X-Received: by 10.229.114.137 with SMTP id e9mr42341069qcq.0.1419306218275;
	Mon, 22 Dec 2014 19:43:38 -0800 (PST)
Received: by 10.229.133.144 with HTTP; Mon, 22 Dec 2014 19:43:38 -0800 (PST)
Date: Mon, 22 Dec 2014 19:43:38 -0800
Message-ID: <CAAiw7JnT_s=eS5dR8xvUKChxox8BcQpzuFpsPtJo5YRegFAKBg@mail.gmail.com>
From: manish jaggi <manishjaggi.oss@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	manish.jaggi@caviumnetworks.com, Vijaya.Kumar@caviumnetworks.com
Subject: [Xen-devel] [query] gic_update_one_lr r/w from ICH_LR rather than
	vcpu context lr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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,

In gic.c, gic_update_one_lr, gic_hw_ops is called to read and write to an LR.
why is read/write not done on the LRs stored in the vcpu context ?

Could you please elaborate why it is done this way.


-Regards
manish

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 04:10:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 04: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 1Y3GnC-0003rs-Rd; Tue, 23 Dec 2014 04:09:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linus971@gmail.com>) id 1Y3GnA-0003rn-Pp
	for Xen-devel@lists.xensource.com; Tue, 23 Dec 2014 04:09:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	68/69-25276-01BE8945; Tue, 23 Dec 2014 04:09:52 +0000
X-Env-Sender: linus971@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1419307790!13931588!1
X-Originating-IP: [209.85.216.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 8168 invoked from network); 23 Dec 2014 04:09:51 -0000
Received: from mail-qc0-f174.google.com (HELO mail-qc0-f174.google.com)
	(209.85.216.174)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 04:09:51 -0000
Received: by mail-qc0-f174.google.com with SMTP id c9so4189554qcz.33
	for <Xen-devel@lists.xensource.com>;
	Mon, 22 Dec 2014 20:09:50 -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=CTvRz3Py5bqWuWHi3+eDBtFrRoWrceyRjD57p1cARBA=;
	b=0UZPdwoXkK0siWGRUaR3ZNuwOAC8UxjncSCLVtI6GtyFnvRZ/QestbwcHRSBnTdULa
	ZNbS2KWH1AGP/zgmaRHlOH9+qKYQjV7E0iFwBkRB/VjmecHDBDfHfkZAMgzhAf1eebpY
	WWJNQikgKf/SlGNHC6CSpQhhxJzAil3EqaU+Z59+iESvNeK1neGRkjazFK3BphlgaTq4
	Ud7srIaZUeiJX/ppeKP0G9vUiFxF7ggpfpdmL1DUonhtqiywlvc4MM5K67O+P+Vj8Qov
	fV1XcUpKgfdfHZYjFGKXdggbjKeQhP+IYJg67ekh7p2g469t9mTPFD4HjRPpYoDNKYx5
	xsgg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linux-foundation.org; s=google;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=CTvRz3Py5bqWuWHi3+eDBtFrRoWrceyRjD57p1cARBA=;
	b=N6O4I5Iq2WBE4i6tTH4mFMg6sV5QwbRdCB+rsDevcbM8M1T1gHLBpU44yQk6SEcSQo
	v/zGJGjunv7jUHrT2bTKtUvlH4Wq5vXB27pIgjggncdZPMsRANYAt09RnICGO7JDfiS0
	u3tIlNzzjxAtEetPm1HxYlm0AQSsgQyHmYLls=
MIME-Version: 1.0
X-Received: by 10.224.89.70 with SMTP id d6mr42605845qam.76.1419307790608;
	Mon, 22 Dec 2014 20:09:50 -0800 (PST)
Received: by 10.140.22.41 with HTTP; Mon, 22 Dec 2014 20:09:50 -0800 (PST)
In-Reply-To: <20141223132605.02d81e01@canb.auug.org.au>
References: <20141208184908.27bfd605@canb.auug.org.au>
	<20141208103328.GE27367@arm.com>
	<20141223132605.02d81e01@canb.auug.org.au>
Date: Mon, 22 Dec 2014 20:09:50 -0800
X-Google-Sender-Auth: jtkXOgF_Wn19U5T8friXKFUPDjA
Message-ID: <CA+55aFwQKe0PvSuYqOeQMM8kouB3mkyQQ=gFMX=bkPx3GxanvA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <Xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Olof Johansson <olof@lixom.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] linux-next: missing merge fix patch for the merge
 of the xen-tip tree with the arm-soc tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 22, 2014 at 6:26 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Linus,
>
> I have been carrying this merge fix patch for some time that is now
> needed in your tree:

No, it's not. Look more closely.

My merge put the

        dev->archdata.dma_coherent = coherent;

line at the top of the function, like the way it was in the original commit.

                            Linus

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 04:10:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 04: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 1Y3GnC-0003rs-Rd; Tue, 23 Dec 2014 04:09:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linus971@gmail.com>) id 1Y3GnA-0003rn-Pp
	for Xen-devel@lists.xensource.com; Tue, 23 Dec 2014 04:09:52 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	68/69-25276-01BE8945; Tue, 23 Dec 2014 04:09:52 +0000
X-Env-Sender: linus971@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1419307790!13931588!1
X-Originating-IP: [209.85.216.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 8168 invoked from network); 23 Dec 2014 04:09:51 -0000
Received: from mail-qc0-f174.google.com (HELO mail-qc0-f174.google.com)
	(209.85.216.174)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 04:09:51 -0000
Received: by mail-qc0-f174.google.com with SMTP id c9so4189554qcz.33
	for <Xen-devel@lists.xensource.com>;
	Mon, 22 Dec 2014 20:09:50 -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=CTvRz3Py5bqWuWHi3+eDBtFrRoWrceyRjD57p1cARBA=;
	b=0UZPdwoXkK0siWGRUaR3ZNuwOAC8UxjncSCLVtI6GtyFnvRZ/QestbwcHRSBnTdULa
	ZNbS2KWH1AGP/zgmaRHlOH9+qKYQjV7E0iFwBkRB/VjmecHDBDfHfkZAMgzhAf1eebpY
	WWJNQikgKf/SlGNHC6CSpQhhxJzAil3EqaU+Z59+iESvNeK1neGRkjazFK3BphlgaTq4
	Ud7srIaZUeiJX/ppeKP0G9vUiFxF7ggpfpdmL1DUonhtqiywlvc4MM5K67O+P+Vj8Qov
	fV1XcUpKgfdfHZYjFGKXdggbjKeQhP+IYJg67ekh7p2g469t9mTPFD4HjRPpYoDNKYx5
	xsgg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linux-foundation.org; s=google;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=CTvRz3Py5bqWuWHi3+eDBtFrRoWrceyRjD57p1cARBA=;
	b=N6O4I5Iq2WBE4i6tTH4mFMg6sV5QwbRdCB+rsDevcbM8M1T1gHLBpU44yQk6SEcSQo
	v/zGJGjunv7jUHrT2bTKtUvlH4Wq5vXB27pIgjggncdZPMsRANYAt09RnICGO7JDfiS0
	u3tIlNzzjxAtEetPm1HxYlm0AQSsgQyHmYLls=
MIME-Version: 1.0
X-Received: by 10.224.89.70 with SMTP id d6mr42605845qam.76.1419307790608;
	Mon, 22 Dec 2014 20:09:50 -0800 (PST)
Received: by 10.140.22.41 with HTTP; Mon, 22 Dec 2014 20:09:50 -0800 (PST)
In-Reply-To: <20141223132605.02d81e01@canb.auug.org.au>
References: <20141208184908.27bfd605@canb.auug.org.au>
	<20141208103328.GE27367@arm.com>
	<20141223132605.02d81e01@canb.auug.org.au>
Date: Mon, 22 Dec 2014 20:09:50 -0800
X-Google-Sender-Auth: jtkXOgF_Wn19U5T8friXKFUPDjA
Message-ID: <CA+55aFwQKe0PvSuYqOeQMM8kouB3mkyQQ=gFMX=bkPx3GxanvA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <Xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Olof Johansson <olof@lixom.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] linux-next: missing merge fix patch for the merge
 of the xen-tip tree with the arm-soc tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 22, 2014 at 6:26 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Linus,
>
> I have been carrying this merge fix patch for some time that is now
> needed in your tree:

No, it's not. Look more closely.

My merge put the

        dev->archdata.dma_coherent = coherent;

line at the top of the function, like the way it was in the original commit.

                            Linus

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 06:33:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 06: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 1Y3J1W-0007Sv-5O; Tue, 23 Dec 2014 06:32:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1Y3J1U-0007Sq-6M
	for Xen-devel@lists.xensource.com; Tue, 23 Dec 2014 06:32:48 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	AC/B7-26652-F8C09945; Tue, 23 Dec 2014 06:32:47 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-8.tower-206.messagelabs.com!1419316364!10895442!1
X-Originating-IP: [103.22.144.67]
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 4655 invoked from network); 23 Dec 2014 06:32:46 -0000
Received: from ozlabs.org (HELO ozlabs.org) (103.22.144.67)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 06:32:46 -0000
Received: from authenticated.ozlabs.org (localhost [127.0.0.1])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by ozlabs.org (Postfix) with ESMTPSA id BEDD814009B;
	Tue, 23 Dec 2014 17:32:40 +1100 (AEDT)
Date: Tue, 23 Dec 2014 17:32:34 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <20141223173234.7c4c45f5@canb.auug.org.au>
In-Reply-To: <CA+55aFwQKe0PvSuYqOeQMM8kouB3mkyQQ=gFMX=bkPx3GxanvA@mail.gmail.com>
References: <20141208184908.27bfd605@canb.auug.org.au>
	<20141208103328.GE27367@arm.com>
	<20141223132605.02d81e01@canb.auug.org.au>
	<CA+55aFwQKe0PvSuYqOeQMM8kouB3mkyQQ=gFMX=bkPx3GxanvA@mail.gmail.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; i586-pc-linux-gnu)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <Xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Olof Johansson <olof@lixom.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] linux-next: missing merge fix patch for the merge
 of the xen-tip tree with the arm-soc tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1098775196370907238=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1098775196370907238==
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/74vVFQ3VyjweQBk_D1gmmF/"; protocol="application/pgp-signature"

--Sig_/74vVFQ3VyjweQBk_D1gmmF/
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi Linus,

On Mon, 22 Dec 2014 20:09:50 -0800 Linus Torvalds <torvalds@linux-foundatio=
n.org> wrote:
>
> On Mon, Dec 22, 2014 at 6:26 PM, Stephen Rothwell <sfr@canb.auug.org.au> =
wrote:
> > Hi Linus,
> >
> > I have been carrying this merge fix patch for some time that is now
> > needed in your tree:
>=20
> No, it's not. Look more closely.
>=20
> My merge put the
>=20
>         dev->archdata.dma_coherent =3D coherent;
>=20
> line at the top of the function, like the way it was in the original comm=
it.

Oops, sorry about that.

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

--Sig_/74vVFQ3VyjweQBk_D1gmmF/
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUmQyHAAoJEMDTa8Ir7ZwVJK4QAI6Sto8zHENd4L6S86wn7F9B
Jj3CSvO2A503KTA/Muneq4//PRplt0RZZUP/nDaPSc8ZKjCd+SNxp2vBPZRSUoWh
OtevOroAGAlDvWz2AgF49TVw1ud73AiVgInFSFGmdhPzk47akTe+V4S8q2Yflo+I
b1CC/PvVC1sW36dA3kKZ11EldNzF5AXAu7gHdFNSKB3FAIkar4jaq8tj9x6OBcDZ
9Eo+fWduvEBI4QKBsb9dB1O5Wweon+/29rsEj3J989loYS4aD3Y5hpr+/EVtEPs7
P6mvYmoI4KEhtHWzlFLF7t5/AeCzA/pKmTBiOrlAR5Mnru485jCJb1v+jN8LmwmK
afwcBcEunVQihmETSMX5lBlq4IefrsYYVEoTO0wz04zP3Hd4kyGZVsoiGl48O6Rc
Bnnw7Ke4xyy+4h6PYhTUS0EDloxBlVUfCvm5e87/yJ14sjLnt4CUUXm9gcpwFLp6
o+nS/nfgScKiKXnVk5etNQ9z4Wd96XUJdlAvhX3FcV1/ZaAMzk1HiE0P9XUl76mo
/eB01BmTjH+6hgl3ZnTOH33+s5cZVA0JixX3lvjyeaBvTNHjPhaUwMybkPFeWXzH
HTWyO58H6RKTCVNFsD+vuDHOlgGgU3z28Nlxgmh7/wO15/tOX2f4HbPn6jX1dIN2
7gm/dC6cGmJkf09fzWPo
=phOW
-----END PGP SIGNATURE-----

--Sig_/74vVFQ3VyjweQBk_D1gmmF/--


--===============1098775196370907238==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1098775196370907238==--


From xen-devel-bounces@lists.xen.org Tue Dec 23 06:33:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 06: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 1Y3J1W-0007Sv-5O; Tue, 23 Dec 2014 06:32:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1Y3J1U-0007Sq-6M
	for Xen-devel@lists.xensource.com; Tue, 23 Dec 2014 06:32:48 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	AC/B7-26652-F8C09945; Tue, 23 Dec 2014 06:32:47 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-8.tower-206.messagelabs.com!1419316364!10895442!1
X-Originating-IP: [103.22.144.67]
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 4655 invoked from network); 23 Dec 2014 06:32:46 -0000
Received: from ozlabs.org (HELO ozlabs.org) (103.22.144.67)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 06:32:46 -0000
Received: from authenticated.ozlabs.org (localhost [127.0.0.1])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by ozlabs.org (Postfix) with ESMTPSA id BEDD814009B;
	Tue, 23 Dec 2014 17:32:40 +1100 (AEDT)
Date: Tue, 23 Dec 2014 17:32:34 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <20141223173234.7c4c45f5@canb.auug.org.au>
In-Reply-To: <CA+55aFwQKe0PvSuYqOeQMM8kouB3mkyQQ=gFMX=bkPx3GxanvA@mail.gmail.com>
References: <20141208184908.27bfd605@canb.auug.org.au>
	<20141208103328.GE27367@arm.com>
	<20141223132605.02d81e01@canb.auug.org.au>
	<CA+55aFwQKe0PvSuYqOeQMM8kouB3mkyQQ=gFMX=bkPx3GxanvA@mail.gmail.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; i586-pc-linux-gnu)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <Xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>, Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Olof Johansson <olof@lixom.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] linux-next: missing merge fix patch for the merge
 of the xen-tip tree with the arm-soc tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1098775196370907238=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1098775196370907238==
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/74vVFQ3VyjweQBk_D1gmmF/"; protocol="application/pgp-signature"

--Sig_/74vVFQ3VyjweQBk_D1gmmF/
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi Linus,

On Mon, 22 Dec 2014 20:09:50 -0800 Linus Torvalds <torvalds@linux-foundatio=
n.org> wrote:
>
> On Mon, Dec 22, 2014 at 6:26 PM, Stephen Rothwell <sfr@canb.auug.org.au> =
wrote:
> > Hi Linus,
> >
> > I have been carrying this merge fix patch for some time that is now
> > needed in your tree:
>=20
> No, it's not. Look more closely.
>=20
> My merge put the
>=20
>         dev->archdata.dma_coherent =3D coherent;
>=20
> line at the top of the function, like the way it was in the original comm=
it.

Oops, sorry about that.

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

--Sig_/74vVFQ3VyjweQBk_D1gmmF/
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUmQyHAAoJEMDTa8Ir7ZwVJK4QAI6Sto8zHENd4L6S86wn7F9B
Jj3CSvO2A503KTA/Muneq4//PRplt0RZZUP/nDaPSc8ZKjCd+SNxp2vBPZRSUoWh
OtevOroAGAlDvWz2AgF49TVw1ud73AiVgInFSFGmdhPzk47akTe+V4S8q2Yflo+I
b1CC/PvVC1sW36dA3kKZ11EldNzF5AXAu7gHdFNSKB3FAIkar4jaq8tj9x6OBcDZ
9Eo+fWduvEBI4QKBsb9dB1O5Wweon+/29rsEj3J989loYS4aD3Y5hpr+/EVtEPs7
P6mvYmoI4KEhtHWzlFLF7t5/AeCzA/pKmTBiOrlAR5Mnru485jCJb1v+jN8LmwmK
afwcBcEunVQihmETSMX5lBlq4IefrsYYVEoTO0wz04zP3Hd4kyGZVsoiGl48O6Rc
Bnnw7Ke4xyy+4h6PYhTUS0EDloxBlVUfCvm5e87/yJ14sjLnt4CUUXm9gcpwFLp6
o+nS/nfgScKiKXnVk5etNQ9z4Wd96XUJdlAvhX3FcV1/ZaAMzk1HiE0P9XUl76mo
/eB01BmTjH+6hgl3ZnTOH33+s5cZVA0JixX3lvjyeaBvTNHjPhaUwMybkPFeWXzH
HTWyO58H6RKTCVNFsD+vuDHOlgGgU3z28Nlxgmh7/wO15/tOX2f4HbPn6jX1dIN2
7gm/dC6cGmJkf09fzWPo
=phOW
-----END PGP SIGNATURE-----

--Sig_/74vVFQ3VyjweQBk_D1gmmF/--


--===============1098775196370907238==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1098775196370907238==--


From xen-devel-bounces@lists.xen.org Tue Dec 23 06:53:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 06: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 1Y3JLI-000806-FS; Tue, 23 Dec 2014 06:53:16 +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 1Y3JLG-000801-L0
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 06:53:14 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	55/41-01660-95119945; Tue, 23 Dec 2014 06:53:13 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1419317592!14839894!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 27998 invoked from network); 23 Dec 2014 06:53:12 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-4.tower-206.messagelabs.com with SMTP;
	23 Dec 2014 06:53:12 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by fmsmga103.fm.intel.com with ESMTP; 22 Dec 2014 22:49:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,629,1413270000"; d="scan'208";a="628068375"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2014 22:53:09 -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; Tue, 23 Dec 2014 14:52:16 +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, 23 Dec 2014 14:52:15 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
Thread-Topic: [PATCH] VT-d: don't crash when PTE bits 52 and up are non-zero
Thread-Index: AQHQG36pw80e8IN0Eke5kWNKFh6X6Jycwptw
Date: Tue, 23 Dec 2014 06:52:14 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126123D2B@SHSMSX101.ccr.corp.intel.com>
References: <5494196B0200007800050F6B@mail.emea.novell.com>
In-Reply-To: <5494196B0200007800050F6B@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>
Subject: Re: [Xen-devel] [PATCH] VT-d: don't crash when PTE bits 52 and up
	are 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

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, December 19, 2014 7:26 PM
> 
> This can (and will) be legitimately the case when sharing page tables
> with EPT (more of a problem before p2m_access_rwx became zero, but
> still possible even now when other than that is the default for a
> guest), leading to an unconditional crash (in print_vtd_entries())
> when a DMA remapping fault occurs.

could you elaborate the scenarios when bits 52+ are non-zero?

> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

but the changes looks reasonable to me.

Signed-off-by: Kevin Tian <kevin.tian@intel.com>

> ---
> Regarding the release, if the changes to iommu.c are deemed too
> extensive, then _I think_ they could be split off (that code ought to
> come into play only when not sharing page tables between VT-d and EPT,
> and VT-d code never sets the offending bits to non-zero values afaict).
> 
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -258,8 +258,7 @@ static u64 addr_to_dma_page_maddr(struct
>      struct dma_pte *parent, *pte = NULL;
>      int level = agaw_to_level(hd->arch.agaw);
>      int offset;
> -    u64 pte_maddr = 0, maddr;
> -    u64 *vaddr = NULL;
> +    u64 pte_maddr = 0;
> 
>      addr &= (((u64)1) << addr_width) - 1;
>      ASSERT(spin_is_locked(&hd->arch.mapping_lock));
> @@ -281,19 +280,19 @@ static u64 addr_to_dma_page_maddr(struct
>          offset = address_level_offset(addr, level);
>          pte = &parent[offset];
> 
> -        if ( dma_pte_addr(*pte) == 0 )
> +        pte_maddr = dma_pte_addr(*pte);
> +        if ( !pte_maddr )
>          {
>              if ( !alloc )
>                  break;
> 
>              pdev = pci_get_pdev_by_domain(domain, -1, -1, -1);
>              drhd = acpi_find_matched_drhd_unit(pdev);
> -            maddr = alloc_pgtable_maddr(drhd, 1);
> -            if ( !maddr )
> +            pte_maddr = alloc_pgtable_maddr(drhd, 1);
> +            if ( !pte_maddr )
>                  break;
> 
> -            dma_set_pte_addr(*pte, maddr);
> -            vaddr = map_vtd_domain_page(maddr);
> +            dma_set_pte_addr(*pte, pte_maddr);
> 
>              /*
>               * high level table always sets r/w, last level
> @@ -303,21 +302,12 @@ static u64 addr_to_dma_page_maddr(struct
>              dma_set_pte_writable(*pte);
>              iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
>          }
> -        else
> -        {
> -            vaddr = map_vtd_domain_page(pte->val);
> -        }
> 
>          if ( level == 2 )
> -        {
> -            pte_maddr = pte->val & PAGE_MASK_4K;
> -            unmap_vtd_domain_page(vaddr);
>              break;
> -        }
> 
>          unmap_vtd_domain_page(parent);
> -        parent = (struct dma_pte *)vaddr;
> -        vaddr = NULL;
> +        parent = map_vtd_domain_page(pte_maddr);
>          level--;
>      }
> 
> @@ -2449,7 +2439,7 @@ static void vtd_dump_p2m_table_level(pad
>              printk("%*sgfn: %08lx mfn: %08lx\n",
>                     indent, "",
>                     (unsigned long)(address >> PAGE_SHIFT_4K),
> -                   (unsigned long)(pte->val >> PAGE_SHIFT_4K));
> +                   (unsigned long)(dma_pte_addr(*pte) >>
> PAGE_SHIFT_4K));
>      }
> 
>      unmap_vtd_domain_page(pt_vaddr);
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -276,7 +276,7 @@ struct dma_pte {
>  #define dma_set_pte_snp(p)  do {(p).val |= DMA_PTE_SNP;} while(0)
>  #define dma_set_pte_prot(p, prot) \
>              do {(p).val = ((p).val & ~3) | ((prot) & 3); } while (0)
> -#define dma_pte_addr(p) ((p).val & PAGE_MASK_4K)
> +#define dma_pte_addr(p) ((p).val & PADDR_MASK & PAGE_MASK_4K)
>  #define dma_set_pte_addr(p, addr) do {\
>              (p).val |= ((addr) & PAGE_MASK_4K); } while (0)
>  #define dma_pte_present(p) (((p).val & 3) != 0)
> --- a/xen/drivers/passthrough/vtd/utils.c
> +++ b/xen/drivers/passthrough/vtd/utils.c
> @@ -170,16 +170,16 @@ void print_vtd_entries(struct iommu *iom
>          l_index = get_level_index(gmfn, level);
>          printk("    l%d_index = %x\n", level, l_index);
> 
> -        pte.val = val = l[l_index];
> +        pte.val = l[l_index];
>          unmap_vtd_domain_page(l);
> -        printk("    l%d[%x] = %"PRIx64"\n", level, l_index, val);
> +        printk("    l%d[%x] = %"PRIx64"\n", level, l_index, pte.val);
> 
> -        pte.val = val;
>          if ( !dma_pte_present(pte) )
>          {
>              printk("    l%d[%x] not present\n", level, l_index);
>              break;
>          }
> +        val = dma_pte_addr(pte);
>      } while ( --level );
>  }
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 06:53:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 06: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 1Y3JLI-000806-FS; Tue, 23 Dec 2014 06:53:16 +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 1Y3JLG-000801-L0
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 06:53:14 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	55/41-01660-95119945; Tue, 23 Dec 2014 06:53:13 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1419317592!14839894!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 27998 invoked from network); 23 Dec 2014 06:53:12 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-4.tower-206.messagelabs.com with SMTP;
	23 Dec 2014 06:53:12 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by fmsmga103.fm.intel.com with ESMTP; 22 Dec 2014 22:49:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,629,1413270000"; d="scan'208";a="628068375"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
	by orsmga001.jf.intel.com with ESMTP; 22 Dec 2014 22:53:09 -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; Tue, 23 Dec 2014 14:52:16 +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, 23 Dec 2014 14:52:15 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
Thread-Topic: [PATCH] VT-d: don't crash when PTE bits 52 and up are non-zero
Thread-Index: AQHQG36pw80e8IN0Eke5kWNKFh6X6Jycwptw
Date: Tue, 23 Dec 2014 06:52:14 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126123D2B@SHSMSX101.ccr.corp.intel.com>
References: <5494196B0200007800050F6B@mail.emea.novell.com>
In-Reply-To: <5494196B0200007800050F6B@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>
Subject: Re: [Xen-devel] [PATCH] VT-d: don't crash when PTE bits 52 and up
	are 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

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, December 19, 2014 7:26 PM
> 
> This can (and will) be legitimately the case when sharing page tables
> with EPT (more of a problem before p2m_access_rwx became zero, but
> still possible even now when other than that is the default for a
> guest), leading to an unconditional crash (in print_vtd_entries())
> when a DMA remapping fault occurs.

could you elaborate the scenarios when bits 52+ are non-zero?

> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

but the changes looks reasonable to me.

Signed-off-by: Kevin Tian <kevin.tian@intel.com>

> ---
> Regarding the release, if the changes to iommu.c are deemed too
> extensive, then _I think_ they could be split off (that code ought to
> come into play only when not sharing page tables between VT-d and EPT,
> and VT-d code never sets the offending bits to non-zero values afaict).
> 
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -258,8 +258,7 @@ static u64 addr_to_dma_page_maddr(struct
>      struct dma_pte *parent, *pte = NULL;
>      int level = agaw_to_level(hd->arch.agaw);
>      int offset;
> -    u64 pte_maddr = 0, maddr;
> -    u64 *vaddr = NULL;
> +    u64 pte_maddr = 0;
> 
>      addr &= (((u64)1) << addr_width) - 1;
>      ASSERT(spin_is_locked(&hd->arch.mapping_lock));
> @@ -281,19 +280,19 @@ static u64 addr_to_dma_page_maddr(struct
>          offset = address_level_offset(addr, level);
>          pte = &parent[offset];
> 
> -        if ( dma_pte_addr(*pte) == 0 )
> +        pte_maddr = dma_pte_addr(*pte);
> +        if ( !pte_maddr )
>          {
>              if ( !alloc )
>                  break;
> 
>              pdev = pci_get_pdev_by_domain(domain, -1, -1, -1);
>              drhd = acpi_find_matched_drhd_unit(pdev);
> -            maddr = alloc_pgtable_maddr(drhd, 1);
> -            if ( !maddr )
> +            pte_maddr = alloc_pgtable_maddr(drhd, 1);
> +            if ( !pte_maddr )
>                  break;
> 
> -            dma_set_pte_addr(*pte, maddr);
> -            vaddr = map_vtd_domain_page(maddr);
> +            dma_set_pte_addr(*pte, pte_maddr);
> 
>              /*
>               * high level table always sets r/w, last level
> @@ -303,21 +302,12 @@ static u64 addr_to_dma_page_maddr(struct
>              dma_set_pte_writable(*pte);
>              iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
>          }
> -        else
> -        {
> -            vaddr = map_vtd_domain_page(pte->val);
> -        }
> 
>          if ( level == 2 )
> -        {
> -            pte_maddr = pte->val & PAGE_MASK_4K;
> -            unmap_vtd_domain_page(vaddr);
>              break;
> -        }
> 
>          unmap_vtd_domain_page(parent);
> -        parent = (struct dma_pte *)vaddr;
> -        vaddr = NULL;
> +        parent = map_vtd_domain_page(pte_maddr);
>          level--;
>      }
> 
> @@ -2449,7 +2439,7 @@ static void vtd_dump_p2m_table_level(pad
>              printk("%*sgfn: %08lx mfn: %08lx\n",
>                     indent, "",
>                     (unsigned long)(address >> PAGE_SHIFT_4K),
> -                   (unsigned long)(pte->val >> PAGE_SHIFT_4K));
> +                   (unsigned long)(dma_pte_addr(*pte) >>
> PAGE_SHIFT_4K));
>      }
> 
>      unmap_vtd_domain_page(pt_vaddr);
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -276,7 +276,7 @@ struct dma_pte {
>  #define dma_set_pte_snp(p)  do {(p).val |= DMA_PTE_SNP;} while(0)
>  #define dma_set_pte_prot(p, prot) \
>              do {(p).val = ((p).val & ~3) | ((prot) & 3); } while (0)
> -#define dma_pte_addr(p) ((p).val & PAGE_MASK_4K)
> +#define dma_pte_addr(p) ((p).val & PADDR_MASK & PAGE_MASK_4K)
>  #define dma_set_pte_addr(p, addr) do {\
>              (p).val |= ((addr) & PAGE_MASK_4K); } while (0)
>  #define dma_pte_present(p) (((p).val & 3) != 0)
> --- a/xen/drivers/passthrough/vtd/utils.c
> +++ b/xen/drivers/passthrough/vtd/utils.c
> @@ -170,16 +170,16 @@ void print_vtd_entries(struct iommu *iom
>          l_index = get_level_index(gmfn, level);
>          printk("    l%d_index = %x\n", level, l_index);
> 
> -        pte.val = val = l[l_index];
> +        pte.val = l[l_index];
>          unmap_vtd_domain_page(l);
> -        printk("    l%d[%x] = %"PRIx64"\n", level, l_index, val);
> +        printk("    l%d[%x] = %"PRIx64"\n", level, l_index, pte.val);
> 
> -        pte.val = val;
>          if ( !dma_pte_present(pte) )
>          {
>              printk("    l%d[%x] not present\n", level, l_index);
>              break;
>          }
> +        val = dma_pte_addr(pte);
>      } while ( --level );
>  }
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 07:12:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 07: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 1Y3JdC-00006F-AG; Tue, 23 Dec 2014 07:11:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3JdA-00006A-Is
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 07:11:44 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	46/B0-09284-FA519945; Tue, 23 Dec 2014 07:11:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419318701!15287970!1
X-Originating-IP: [66.165.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 27438 invoked from network); 23 Dec 2014 07:11: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;
	23 Dec 2014 07:11:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,630,1413244800"; d="scan'208";a="207802813"
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.210.2; Tue, 23 Dec 2014 02:11: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 1Y3Jd6-0005CU-Bn;
	Tue, 23 Dec 2014 07:11:40 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3Jd6-0003cu-41;
	Tue, 23 Dec 2014 07:11:40 +0000
Date: Tue, 23 Dec 2014 07:11:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32584-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] 32584: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32584 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32584/

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-sedf-pin  7 debian-install              fail pass in 32568
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install  fail pass in 32568
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install      fail pass in 32568
 test-amd64-amd64-pair         7 xen-boot/src_host  fail in 32568 pass in 32584

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-xl-qemuu-debianhvm-amd64 5 xen-boot fail in 32568 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop     fail in 32568 never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                         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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 23 07:12:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 07: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 1Y3JdC-00006F-AG; Tue, 23 Dec 2014 07:11:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3JdA-00006A-Is
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 07:11:44 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	46/B0-09284-FA519945; Tue, 23 Dec 2014 07:11:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419318701!15287970!1
X-Originating-IP: [66.165.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 27438 invoked from network); 23 Dec 2014 07:11: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;
	23 Dec 2014 07:11:43 -0000
X-IronPort-AV: E=Sophos;i="5.07,630,1413244800"; d="scan'208";a="207802813"
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.210.2; Tue, 23 Dec 2014 02:11: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 1Y3Jd6-0005CU-Bn;
	Tue, 23 Dec 2014 07:11:40 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3Jd6-0003cu-41;
	Tue, 23 Dec 2014 07:11:40 +0000
Date: Tue, 23 Dec 2014 07:11:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32584-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] 32584: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32584 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32584/

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-sedf-pin  7 debian-install              fail pass in 32568
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install  fail pass in 32568
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install      fail pass in 32568
 test-amd64-amd64-pair         7 xen-boot/src_host  fail in 32568 pass in 32584

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-xl-qemuu-debianhvm-amd64 5 xen-boot fail in 32568 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop     fail in 32568 never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                         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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 23 07:21:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 07: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 1Y3Jmf-0000TF-7e; Tue, 23 Dec 2014 07:21:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Y3Jmd-0000TA-Mj
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 07:21:31 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	71/9F-28296-BF719945; Tue, 23 Dec 2014 07:21:31 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1419319290!15222491!1
X-Originating-IP: [209.85.212.178]
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 30683 invoked from network); 23 Dec 2014 07:21:30 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 07:21:30 -0000
Received: by mail-wi0-f178.google.com with SMTP id em10so9914155wid.5
	for <xen-devel@lists.xenproject.org>;
	Mon, 22 Dec 2014 23:21:30 -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:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=1ClNK+PqygJn/pfg0ZW4D/6koP0mgZRPuUz+VCgrVPs=;
	b=xGBwD4jqiKn9CsJGmPrMPoRhUUFcvGA7+OENYls6N8AluS/BdYLXLMvnVvEqhLnUuZ
	dpHB3urYtQLPAzZbKBtrs1wFEGP91oI6WyBth2Ahj8CzBiWs92IMdVXP+sbWdYp/VBZD
	ExBIUHwHCAttalt9xUwRzWGP/FzEm1P41b0poqJFSB3lnUUWx5tLXEsmrg9DxkCbKGWO
	Dq6i0Z2uSmvNAepJdoM5qnRz5KyZYpy1UR6wjz6Z3HQh6fyclJkZzg6qlypbe0Xq1bkW
	b27hNPy7sYNA5o3SVK9XYZQ2NExOEpnnJguMax77HLgDn2laP1gSu7n9QHHVPlWfisfk
	sPvA==
X-Received: by 10.180.83.129 with SMTP id q1mr37869291wiy.8.1419319290343;
	Mon, 22 Dec 2014 23:21:30 -0800 (PST)
Received: from [192.168.10.150] (net-2-35-193-40.cust.vodafonedsl.it.
	[2.35.193.40]) by mx.google.com with ESMTPSA id
	qg11sm16108126wic.17.2014.12.22.23.21.27
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 22 Dec 2014 23:21:29 -0800 (PST)
Message-ID: <549917F6.1080504@redhat.com>
Date: Tue, 23 Dec 2014 08:21:26 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Andy Lutomirski <luto@amacapital.net>, 
	Marcelo Tosatti <mtosatti@redhat.com>
References: <cover.1419295081.git.luto@amacapital.net>
In-Reply-To: <cover.1419295081.git.luto@amacapital.net>
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>, glommer@gmail.com
Subject: Re: [Xen-devel] [RFC 0/2] x86, vdso, pvclock: Cleanups and speedups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/2014 01:39, Andy Lutomirski wrote:
> This is a dramatic simplification and speedup of the vdso pvclock read
> code.  Is it correct?
> 
> Andy Lutomirski (2):
>   x86, vdso: Use asm volatile in __getcpu
>   x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

Patch 1 is ok,

Acked-by: Paolo Bonzini <pbonzini@redhat.com>

For patch 2 I will defer to Marcelo and Glauber (and the Xen folks).

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 07:21:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 07: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 1Y3Jmf-0000TF-7e; Tue, 23 Dec 2014 07:21:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Y3Jmd-0000TA-Mj
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 07:21:31 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	71/9F-28296-BF719945; Tue, 23 Dec 2014 07:21:31 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1419319290!15222491!1
X-Originating-IP: [209.85.212.178]
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 30683 invoked from network); 23 Dec 2014 07:21:30 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 07:21:30 -0000
Received: by mail-wi0-f178.google.com with SMTP id em10so9914155wid.5
	for <xen-devel@lists.xenproject.org>;
	Mon, 22 Dec 2014 23:21:30 -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:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=1ClNK+PqygJn/pfg0ZW4D/6koP0mgZRPuUz+VCgrVPs=;
	b=xGBwD4jqiKn9CsJGmPrMPoRhUUFcvGA7+OENYls6N8AluS/BdYLXLMvnVvEqhLnUuZ
	dpHB3urYtQLPAzZbKBtrs1wFEGP91oI6WyBth2Ahj8CzBiWs92IMdVXP+sbWdYp/VBZD
	ExBIUHwHCAttalt9xUwRzWGP/FzEm1P41b0poqJFSB3lnUUWx5tLXEsmrg9DxkCbKGWO
	Dq6i0Z2uSmvNAepJdoM5qnRz5KyZYpy1UR6wjz6Z3HQh6fyclJkZzg6qlypbe0Xq1bkW
	b27hNPy7sYNA5o3SVK9XYZQ2NExOEpnnJguMax77HLgDn2laP1gSu7n9QHHVPlWfisfk
	sPvA==
X-Received: by 10.180.83.129 with SMTP id q1mr37869291wiy.8.1419319290343;
	Mon, 22 Dec 2014 23:21:30 -0800 (PST)
Received: from [192.168.10.150] (net-2-35-193-40.cust.vodafonedsl.it.
	[2.35.193.40]) by mx.google.com with ESMTPSA id
	qg11sm16108126wic.17.2014.12.22.23.21.27
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 22 Dec 2014 23:21:29 -0800 (PST)
Message-ID: <549917F6.1080504@redhat.com>
Date: Tue, 23 Dec 2014 08:21:26 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Andy Lutomirski <luto@amacapital.net>, 
	Marcelo Tosatti <mtosatti@redhat.com>
References: <cover.1419295081.git.luto@amacapital.net>
In-Reply-To: <cover.1419295081.git.luto@amacapital.net>
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>, glommer@gmail.com
Subject: Re: [Xen-devel] [RFC 0/2] x86, vdso, pvclock: Cleanups and speedups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/2014 01:39, Andy Lutomirski wrote:
> This is a dramatic simplification and speedup of the vdso pvclock read
> code.  Is it correct?
> 
> Andy Lutomirski (2):
>   x86, vdso: Use asm volatile in __getcpu
>   x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

Patch 1 is ok,

Acked-by: Paolo Bonzini <pbonzini@redhat.com>

For patch 2 I will defer to Marcelo and Glauber (and the Xen folks).

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 08:17:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Kee-0002K4-JG; Tue, 23 Dec 2014 08:17:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1Y3Kec-0002Jz-E3
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 08:17:18 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	92/91-02697-C0529945; Tue, 23 Dec 2014 08:17:16 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-7.tower-206.messagelabs.com!1419322636!14874531!1
X-Originating-IP: [209.85.217.173]
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 8884 invoked from network); 23 Dec 2014 08:17:16 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 08:17:16 -0000
Received: by mail-lb0-f173.google.com with SMTP id z12so4987065lbi.18
	for <xen-devel@lists.xenproject.org>;
	Tue, 23 Dec 2014 00:17: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:from:date
	:message-id:subject:to:cc:content-type;
	bh=hfCEaehy+iwtE0QQ+iSP4cAqpim24OX8QGxMk8LGZBs=;
	b=DyN2sd5TbCzVzsf2/l2OCOM5k6L0yWFn6hX/vhivj5pim/2t40pH4BWa/ZcLxSkKMP
	pvlnn4UOwv0y58bXKRPxsaVs7rbOgC7RM1P4cKeb20NF34Gq8ZJY6C1T4yGycK07Jn23
	w71GGtXGSl9lM8AZpOZR3Jo5o5JNcIVjv5cjzP1rNxYehdQDupKjRoncw4uNMqbXMr9m
	xNZItjCv0/HIMf1mp9oM4cfvNAPPbf7hzj1ms3eY0HZOe4SNK4b+3X+wHAr8ogqInC+p
	z3npcaM7rvDsPrNMMEnU4JVLVvCFdonBypDB1LQpgEeT39RaBfPyHfNeEjmG/LGSaHFh
	v9zA==
X-Gm-Message-State: ALoCoQnOrKVtPP14xsk3gS0Qv/FBfsOwOwT2A7wF8fHArTeHMdHhz3J5X6HX/GAykly/VhMA6nBu
X-Received: by 10.112.136.69 with SMTP id py5mr25427585lbb.56.1419322635640;
	Tue, 23 Dec 2014 00:17:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.7.132 with HTTP; Tue, 23 Dec 2014 00:16:55 -0800 (PST)
In-Reply-To: <549917F6.1080504@redhat.com>
References: <cover.1419295081.git.luto@amacapital.net>
	<549917F6.1080504@redhat.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 23 Dec 2014 00:16:55 -0800
Message-ID: <CALCETrUtf=a9wRYwftJxNB6Smrf0pXS43qPd37XO0_mxrGJ-Cg@mail.gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm list <kvm@vger.kernel.org>, Gleb Natapov <gleb@kernel.org>,
	glommer@gmail.com, Marcelo Tosatti <mtosatti@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [RFC 0/2] x86, vdso, pvclock: Cleanups and speedups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 22, 2014 at 11:21 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 23/12/2014 01:39, Andy Lutomirski wrote:
>> This is a dramatic simplification and speedup of the vdso pvclock read
>> code.  Is it correct?
>>
>> Andy Lutomirski (2):
>>   x86, vdso: Use asm volatile in __getcpu
>>   x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
>
> Patch 1 is ok,
>
> Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Any thoughts as to whether it should be tagged for stable?  I haven't
looked closely enough at the old pvclock code or the generated code to
have much of an opinion there.  It'll be a big speedup for non-pvclock
users at least.

--Andy

>
> For patch 2 I will defer to Marcelo and Glauber (and the Xen folks).
>
> Paolo



-- 
Andy Lutomirski
AMA Capital Management, LLC

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 08:17:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Kee-0002K4-JG; Tue, 23 Dec 2014 08:17:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1Y3Kec-0002Jz-E3
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 08:17:18 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	92/91-02697-C0529945; Tue, 23 Dec 2014 08:17:16 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-7.tower-206.messagelabs.com!1419322636!14874531!1
X-Originating-IP: [209.85.217.173]
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 8884 invoked from network); 23 Dec 2014 08:17:16 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 08:17:16 -0000
Received: by mail-lb0-f173.google.com with SMTP id z12so4987065lbi.18
	for <xen-devel@lists.xenproject.org>;
	Tue, 23 Dec 2014 00:17: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:from:date
	:message-id:subject:to:cc:content-type;
	bh=hfCEaehy+iwtE0QQ+iSP4cAqpim24OX8QGxMk8LGZBs=;
	b=DyN2sd5TbCzVzsf2/l2OCOM5k6L0yWFn6hX/vhivj5pim/2t40pH4BWa/ZcLxSkKMP
	pvlnn4UOwv0y58bXKRPxsaVs7rbOgC7RM1P4cKeb20NF34Gq8ZJY6C1T4yGycK07Jn23
	w71GGtXGSl9lM8AZpOZR3Jo5o5JNcIVjv5cjzP1rNxYehdQDupKjRoncw4uNMqbXMr9m
	xNZItjCv0/HIMf1mp9oM4cfvNAPPbf7hzj1ms3eY0HZOe4SNK4b+3X+wHAr8ogqInC+p
	z3npcaM7rvDsPrNMMEnU4JVLVvCFdonBypDB1LQpgEeT39RaBfPyHfNeEjmG/LGSaHFh
	v9zA==
X-Gm-Message-State: ALoCoQnOrKVtPP14xsk3gS0Qv/FBfsOwOwT2A7wF8fHArTeHMdHhz3J5X6HX/GAykly/VhMA6nBu
X-Received: by 10.112.136.69 with SMTP id py5mr25427585lbb.56.1419322635640;
	Tue, 23 Dec 2014 00:17:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.7.132 with HTTP; Tue, 23 Dec 2014 00:16:55 -0800 (PST)
In-Reply-To: <549917F6.1080504@redhat.com>
References: <cover.1419295081.git.luto@amacapital.net>
	<549917F6.1080504@redhat.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 23 Dec 2014 00:16:55 -0800
Message-ID: <CALCETrUtf=a9wRYwftJxNB6Smrf0pXS43qPd37XO0_mxrGJ-Cg@mail.gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm list <kvm@vger.kernel.org>, Gleb Natapov <gleb@kernel.org>,
	glommer@gmail.com, Marcelo Tosatti <mtosatti@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [RFC 0/2] x86, vdso, pvclock: Cleanups and speedups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Dec 22, 2014 at 11:21 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 23/12/2014 01:39, Andy Lutomirski wrote:
>> This is a dramatic simplification and speedup of the vdso pvclock read
>> code.  Is it correct?
>>
>> Andy Lutomirski (2):
>>   x86, vdso: Use asm volatile in __getcpu
>>   x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
>
> Patch 1 is ok,
>
> Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Any thoughts as to whether it should be tagged for stable?  I haven't
looked closely enough at the old pvclock code or the generated code to
have much of an opinion there.  It'll be a big speedup for non-pvclock
users at least.

--Andy

>
> For patch 2 I will defer to Marcelo and Glauber (and the Xen folks).
>
> Paolo



-- 
Andy Lutomirski
AMA Capital Management, LLC

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 08:22:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08:22:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Kjd-0002dz-AQ; Tue, 23 Dec 2014 08:22: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 1Y3Kjc-0002du-3y
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 08:22:28 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	B8/28-17958-34629945; Tue, 23 Dec 2014 08:22:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419322945!15344357!1
X-Originating-IP: [66.165.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 12750 invoked from network); 23 Dec 2014 08:22:26 -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;
	23 Dec 2014 08:22:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,630,1413244800"; d="scan'208";a="207815192"
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.210.2; Tue, 23 Dec 2014 03:22: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 1Y3KjX-0005XN-1U;
	Tue, 23 Dec 2014 08:22:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3KjW-0000yt-RC;
	Tue, 23 Dec 2014 08:22:22 +0000
Date: Tue, 23 Dec 2014 08:22:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32585-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] 32585: 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 32585 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32585/

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 32571

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-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-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-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-qemuu-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-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                c95f3901b4ead79f3fe2c641fda7d2c70fc84c72
baseline version:
 qemuu                328b3b6c44c17d94df115ed1851f54a0bd59a471

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Max Reitz <mreitz@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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=c95f3901b4ead79f3fe2c641fda7d2c70fc84c72
+ . 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 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72
+ branch=qemu-mainline
+ revision=c95f3901b4ead79f3fe2c641fda7d2c70fc84c72
+ . 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 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   328b3b6..c95f390  c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 -> 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 Tue Dec 23 08:22:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08:22:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Kjd-0002dz-AQ; Tue, 23 Dec 2014 08:22: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 1Y3Kjc-0002du-3y
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 08:22:28 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	B8/28-17958-34629945; Tue, 23 Dec 2014 08:22:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419322945!15344357!1
X-Originating-IP: [66.165.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 12750 invoked from network); 23 Dec 2014 08:22:26 -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;
	23 Dec 2014 08:22:26 -0000
X-IronPort-AV: E=Sophos;i="5.07,630,1413244800"; d="scan'208";a="207815192"
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.210.2; Tue, 23 Dec 2014 03:22: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 1Y3KjX-0005XN-1U;
	Tue, 23 Dec 2014 08:22:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3KjW-0000yt-RC;
	Tue, 23 Dec 2014 08:22:22 +0000
Date: Tue, 23 Dec 2014 08:22:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32585-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] 32585: 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 32585 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32585/

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 32571

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-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-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-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-qemuu-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-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                c95f3901b4ead79f3fe2c641fda7d2c70fc84c72
baseline version:
 qemuu                328b3b6c44c17d94df115ed1851f54a0bd59a471

------------------------------------------------------------
People who touched revisions under test:
  Gerd Hoffmann <kraxel@redhat.com>
  Max Reitz <mreitz@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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=c95f3901b4ead79f3fe2c641fda7d2c70fc84c72
+ . 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 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72
+ branch=qemu-mainline
+ revision=c95f3901b4ead79f3fe2c641fda7d2c70fc84c72
+ . 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 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   328b3b6..c95f390  c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 -> 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 Tue Dec 23 08:30:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Kr6-0002md-8F; Tue, 23 Dec 2014 08:30:12 +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 1Y3Kr4-0002mY-QG
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 08:30:10 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1B/09-15461-21829945; Tue, 23 Dec 2014 08:30:10 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1419323409!17367485!1
X-Originating-IP: [74.125.82.45]
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 19184 invoked from network); 23 Dec 2014 08:30:09 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 08:30:09 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so8419017wgh.32
	for <xen-devel@lists.xenproject.org>;
	Tue, 23 Dec 2014 00:30:09 -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=q25pXiiehsTRcEASy/LOVISwN26buWuCJ3cDrzgFTt4=;
	b=hiEVkhOGIUcuWLRitmTeLcAnRAUAD+EooXUA3VBg3qs6g0ztee5cN8tq/5s3fBfa8z
	eTtMd1ahuo8oYLLyQQ5lE4RTbVJ3J+YAV3RolqkByTSL2Xcll0YN97gvZFpLfSDeLaVK
	404PAWavtI9wK/PC+5EKxc2IAaWDU/C0zaZ4CFq2Fz9/G7Cmfjj1AJH98ZNW2fDvPpCG
	ABgGPpGSbpGXifSKeOHiWXGRV0YvFTulGiJ1nii6lHPjoah2Wh6Cybf1giIETWhmELnF
	HL84/2CL2GEoYISD3Z2lRKdnSZiWCSqrtYgvwZKo4HZCb7FWYG/Px85z40qgbBJol+ws
	qNKg==
X-Received: by 10.180.107.136 with SMTP id hc8mr39175329wib.32.1419323409478; 
	Tue, 23 Dec 2014 00:30:09 -0800 (PST)
Received: from [192.168.10.150] (net-2-35-193-40.cust.vodafonedsl.it.
	[2.35.193.40]) by mx.google.com with ESMTPSA id
	u18sm26717747wjq.42.2014.12.23.00.30.05
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 23 Dec 2014 00:30:07 -0800 (PST)
Message-ID: <54992809.7040605@redhat.com>
Date: Tue, 23 Dec 2014 09:30:01 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
Newsgroups: gmane.linux.kernel,gmane.comp.emulators.kvm.devel
To: Andy Lutomirski <luto@amacapital.net>
References: <cover.1419295081.git.luto@amacapital.net>
	<549917F6.1080504@redhat.com>
	<CALCETrUtf=a9wRYwftJxNB6Smrf0pXS43qPd37XO0_mxrGJ-Cg@mail.gmail.com>
In-Reply-To: <CALCETrUtf=a9wRYwftJxNB6Smrf0pXS43qPd37XO0_mxrGJ-Cg@mail.gmail.com>
Cc: kvm list <kvm@vger.kernel.org>, Gleb Natapov <gleb@kernel.org>,
	glommer@gmail.com, Marcelo Tosatti <mtosatti@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [RFC 0/2] x86, vdso, pvclock: Cleanups and speedups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/2014 09:16, Andy Lutomirski wrote:
> Any thoughts as to whether it should be tagged for stable?  I haven't
> looked closely enough at the old pvclock code or the generated code to
> have much of an opinion there.  It'll be a big speedup for non-pvclock
> users at least.

Yes, please.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 08:30:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Kr6-0002md-8F; Tue, 23 Dec 2014 08:30:12 +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 1Y3Kr4-0002mY-QG
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 08:30:10 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	1B/09-15461-21829945; Tue, 23 Dec 2014 08:30:10 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1419323409!17367485!1
X-Originating-IP: [74.125.82.45]
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 19184 invoked from network); 23 Dec 2014 08:30:09 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 08:30:09 -0000
Received: by mail-wg0-f45.google.com with SMTP id b13so8419017wgh.32
	for <xen-devel@lists.xenproject.org>;
	Tue, 23 Dec 2014 00:30:09 -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=q25pXiiehsTRcEASy/LOVISwN26buWuCJ3cDrzgFTt4=;
	b=hiEVkhOGIUcuWLRitmTeLcAnRAUAD+EooXUA3VBg3qs6g0ztee5cN8tq/5s3fBfa8z
	eTtMd1ahuo8oYLLyQQ5lE4RTbVJ3J+YAV3RolqkByTSL2Xcll0YN97gvZFpLfSDeLaVK
	404PAWavtI9wK/PC+5EKxc2IAaWDU/C0zaZ4CFq2Fz9/G7Cmfjj1AJH98ZNW2fDvPpCG
	ABgGPpGSbpGXifSKeOHiWXGRV0YvFTulGiJ1nii6lHPjoah2Wh6Cybf1giIETWhmELnF
	HL84/2CL2GEoYISD3Z2lRKdnSZiWCSqrtYgvwZKo4HZCb7FWYG/Px85z40qgbBJol+ws
	qNKg==
X-Received: by 10.180.107.136 with SMTP id hc8mr39175329wib.32.1419323409478; 
	Tue, 23 Dec 2014 00:30:09 -0800 (PST)
Received: from [192.168.10.150] (net-2-35-193-40.cust.vodafonedsl.it.
	[2.35.193.40]) by mx.google.com with ESMTPSA id
	u18sm26717747wjq.42.2014.12.23.00.30.05
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 23 Dec 2014 00:30:07 -0800 (PST)
Message-ID: <54992809.7040605@redhat.com>
Date: Tue, 23 Dec 2014 09:30:01 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
Newsgroups: gmane.linux.kernel,gmane.comp.emulators.kvm.devel
To: Andy Lutomirski <luto@amacapital.net>
References: <cover.1419295081.git.luto@amacapital.net>
	<549917F6.1080504@redhat.com>
	<CALCETrUtf=a9wRYwftJxNB6Smrf0pXS43qPd37XO0_mxrGJ-Cg@mail.gmail.com>
In-Reply-To: <CALCETrUtf=a9wRYwftJxNB6Smrf0pXS43qPd37XO0_mxrGJ-Cg@mail.gmail.com>
Cc: kvm list <kvm@vger.kernel.org>, Gleb Natapov <gleb@kernel.org>,
	glommer@gmail.com, Marcelo Tosatti <mtosatti@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [RFC 0/2] x86, vdso, pvclock: Cleanups and speedups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/2014 09:16, Andy Lutomirski wrote:
> Any thoughts as to whether it should be tagged for stable?  I haven't
> looked closely enough at the old pvclock code or the generated code to
> have much of an opinion there.  It'll be a big speedup for non-pvclock
> users at least.

Yes, please.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 08:55:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08: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 1Y3LEu-0003nR-Ax; Tue, 23 Dec 2014 08:54:48 +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 1Y3LEt-0003nF-7V
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 08:54:47 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	C8/2E-08051-6DD29945; Tue, 23 Dec 2014 08:54:46 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419324884!12091991!2
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 11987 invoked from network); 23 Dec 2014 08:54:45 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-27.messagelabs.com with SMTP;
	23 Dec 2014 08:54:45 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2014 00:54:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="503030864"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by orsmga003.jf.intel.com with ESMTP; 23 Dec 2014 00:50:03 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 23 Dec 2014 16:54:36 +0800
Message-Id: <1419324880-13212-2-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	JBeulich@suse.com, keir@xen.org
Subject: [Xen-devel] [PATCH 1/4] x86: expose CMT L3 event mask to user space
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

L3 event mask indicates the event types supported in host, including
cache occupancy event as well as local/total memory bandwidth events
for Memory Bandwidth Monitoring(MBM). Expose it so all these events
can be monitored in user space.

Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
---
 xen/arch/x86/sysctl.c       |    5 +++++
 xen/include/public/sysctl.h |    1 +
 2 files changed, 6 insertions(+)

diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 57ad992..0f08038 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -157,6 +157,11 @@ long arch_do_sysctl(
             sysctl->u.psr_cmt_op.u.data = (ret ? 0 : info.size);
             break;
         }
+        case XEN_SYSCTL_PSR_CMT_get_l3_event_mask:
+        {
+            sysctl->u.psr_cmt_op.u.data = psr_cmt->l3.features;
+            break;
+        }
         default:
             sysctl->u.psr_cmt_op.u.data = 0;
             ret = -ENOSYS;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index b3713b3..8552dc6 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -641,6 +641,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
 /* The L3 cache size is returned in KB unit */
 #define XEN_SYSCTL_PSR_CMT_get_l3_cache_size         2
 #define XEN_SYSCTL_PSR_CMT_enabled                   3
+#define XEN_SYSCTL_PSR_CMT_get_l3_event_mask         4
 struct xen_sysctl_psr_cmt_op {
     uint32_t cmd;       /* IN: XEN_SYSCTL_PSR_CMT_* */
     uint32_t flags;     /* padding variable, may be extended for future use */
-- 
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 Dec 23 08:55:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08: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 1Y3LEs-0003nG-Vg; Tue, 23 Dec 2014 08:54:46 +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 1Y3LEs-0003nA-2I
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 08:54:46 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A1/2E-08051-5DD29945; Tue, 23 Dec 2014 08:54:45 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419324884!12091991!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 11873 invoked from network); 23 Dec 2014 08:54:44 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-27.messagelabs.com with SMTP;
	23 Dec 2014 08:54:44 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2014 00:54:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="503030860"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by orsmga003.jf.intel.com with ESMTP; 23 Dec 2014 00:50:01 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 23 Dec 2014 16:54:35 +0800
Message-Id: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	JBeulich@suse.com, keir@xen.org
Subject: [Xen-devel] [PATCH 0/4] enable Memory Bandwidth Monitoring (MBM)
	for VMs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Intel Memory Bandwidth Monitoring(MBM) is a new hardware feature
which builds on the CMT infrastructure to allow monitoring of system
memory bandwidth. Event codes are provided to monitor both "total"
and "local" bandwidth, meaning bandwidth over QPI and other external
links can be monitored.

For XEN, MBM is used to monitor memory bandwidth for VMs. Due to its
dependency on CMT, the software also makes use of most of CMT codes.
Actually, besides introducing two additional events and some cpuid
feature bits, there are no extra changes compared to cache occupancy
monitoring in CMT. Due to this, CMT should be enabled first to use
this feature.

For interface changes, the patch serial only introduces a new command
"XEN_SYSCTL_PSR_CMT_get_l3_event_mask" which exposes MBM feature
capability to user space and introduces two additional options for
"xl psr-cmt-show":
total_mem_bandwidth:     Show total memory bandwidth
local_mem_bandwidth:     Show local memory bandwidth

The usage flow keeps the same with CMT.

Chao Peng (4):
  x86: expose CMT L3 event mask to user space
  tools: libxc: add routine to get CMT L3 event mask
  tools: libxl: code preparation for MBM
  tools: add total/local memory bandwith monitoring

 docs/man/xl.pod.1             |    2 +
 tools/libxc/include/xenctrl.h |    3 ++
 tools/libxc/xc_psr.c          |   40 +++++++++++++++++
 tools/libxl/libxl.h           |    4 ++
 tools/libxl/libxl_psr.c       |  100 ++++++++++++++++++++++++++++++++++-------
 tools/libxl/libxl_types.idl   |    2 +
 tools/libxl/xl_cmdimpl.c      |   63 +++++++++++++++++---------
 tools/libxl/xl_cmdtable.c     |    4 +-
 xen/arch/x86/sysctl.c         |    5 +++
 xen/include/public/sysctl.h   |    1 +
 10 files changed, 186 insertions(+), 38 deletions(-)

-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 08:55:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08: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 1Y3LEx-0003nw-SR; Tue, 23 Dec 2014 08:54:51 +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 1Y3LEv-0003nk-Vx
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 08:54:50 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	56/04-03148-9DD29945; Tue, 23 Dec 2014 08:54:49 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419324884!12091991!3
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 12242 invoked from network); 23 Dec 2014 08:54:48 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-27.messagelabs.com with SMTP;
	23 Dec 2014 08:54:48 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2014 00:54:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="503030874"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by orsmga003.jf.intel.com with ESMTP; 23 Dec 2014 00:50:06 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 23 Dec 2014 16:54:37 +0800
Message-Id: <1419324880-13212-3-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	JBeulich@suse.com, keir@xen.org
Subject: [Xen-devel] [PATCH 2/4] tools: libxc: add routine to get CMT L3
	event 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is the xc side wrapper for XEN_SYSCTL_PSR_CMT_get_l3_event_mask
of XEN_SYSCTL_psr_cmt_op. Additional check for event id against value
got from this routine is also added.

Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
---
 tools/libxc/include/xenctrl.h |    1 +
 tools/libxc/xc_psr.c          |   32 ++++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..96b357c 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2697,6 +2697,7 @@ int xc_psr_cmt_get_domain_rmid(xc_interface *xch, uint32_t domid,
 int xc_psr_cmt_get_total_rmid(xc_interface *xch, uint32_t *total_rmid);
 int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
     uint32_t *upscaling_factor);
+int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask);
 int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
     uint32_t *l3_cache_size);
 int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index 872e6dc..94c8698 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -112,6 +112,30 @@ int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
     return rc;
 }
 
+int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask)
+{
+    static int val = 0;
+    int rc;
+    DECLARE_SYSCTL;
+
+    if ( val )
+    {
+        *event_mask = val;
+        return 0;
+    }
+
+    sysctl.cmd = XEN_SYSCTL_psr_cmt_op;
+    sysctl.u.psr_cmt_op.cmd =
+        XEN_SYSCTL_PSR_CMT_get_l3_event_mask;
+    sysctl.u.psr_cmt_op.flags = 0;
+
+    rc = xc_sysctl(xch, &sysctl);
+    if ( !rc )
+        val = *event_mask = sysctl.u.psr_cmt_op.u.data;
+
+    return rc;
+}
+
 int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
                                       uint32_t *l3_cache_size)
 {
@@ -144,6 +168,7 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
     xc_resource_op_t op;
     xc_resource_entry_t entries[2];
     uint32_t evtid;
+    uint32_t event_mask;
     int rc;
 
     switch ( type )
@@ -155,6 +180,13 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
         return -1;
     }
 
+    rc = xc_psr_cmt_get_l3_event_mask(xch, &event_mask);
+    if ( rc < 0 )
+        return rc;
+
+    if ( !(event_mask & (1 << (evtid - 1))) )
+        return -1;
+
     entries[0].u.cmd = XEN_RESOURCE_OP_MSR_WRITE;
     entries[0].idx = MSR_IA32_CMT_EVTSEL;
     entries[0].val = (uint64_t)rmid << 32 | evtid;
-- 
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 Dec 23 08:55:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08: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 1Y3LEu-0003nR-Ax; Tue, 23 Dec 2014 08:54:48 +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 1Y3LEt-0003nF-7V
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 08:54:47 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	C8/2E-08051-6DD29945; Tue, 23 Dec 2014 08:54:46 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419324884!12091991!2
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 11987 invoked from network); 23 Dec 2014 08:54:45 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-27.messagelabs.com with SMTP;
	23 Dec 2014 08:54:45 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2014 00:54:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="503030864"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by orsmga003.jf.intel.com with ESMTP; 23 Dec 2014 00:50:03 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 23 Dec 2014 16:54:36 +0800
Message-Id: <1419324880-13212-2-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	JBeulich@suse.com, keir@xen.org
Subject: [Xen-devel] [PATCH 1/4] x86: expose CMT L3 event mask to user space
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

L3 event mask indicates the event types supported in host, including
cache occupancy event as well as local/total memory bandwidth events
for Memory Bandwidth Monitoring(MBM). Expose it so all these events
can be monitored in user space.

Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
---
 xen/arch/x86/sysctl.c       |    5 +++++
 xen/include/public/sysctl.h |    1 +
 2 files changed, 6 insertions(+)

diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 57ad992..0f08038 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -157,6 +157,11 @@ long arch_do_sysctl(
             sysctl->u.psr_cmt_op.u.data = (ret ? 0 : info.size);
             break;
         }
+        case XEN_SYSCTL_PSR_CMT_get_l3_event_mask:
+        {
+            sysctl->u.psr_cmt_op.u.data = psr_cmt->l3.features;
+            break;
+        }
         default:
             sysctl->u.psr_cmt_op.u.data = 0;
             ret = -ENOSYS;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index b3713b3..8552dc6 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -641,6 +641,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
 /* The L3 cache size is returned in KB unit */
 #define XEN_SYSCTL_PSR_CMT_get_l3_cache_size         2
 #define XEN_SYSCTL_PSR_CMT_enabled                   3
+#define XEN_SYSCTL_PSR_CMT_get_l3_event_mask         4
 struct xen_sysctl_psr_cmt_op {
     uint32_t cmd;       /* IN: XEN_SYSCTL_PSR_CMT_* */
     uint32_t flags;     /* padding variable, may be extended for future use */
-- 
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 Dec 23 08:55:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08: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 1Y3LEs-0003nG-Vg; Tue, 23 Dec 2014 08:54:46 +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 1Y3LEs-0003nA-2I
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 08:54:46 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	A1/2E-08051-5DD29945; Tue, 23 Dec 2014 08:54:45 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419324884!12091991!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 11873 invoked from network); 23 Dec 2014 08:54:44 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-27.messagelabs.com with SMTP;
	23 Dec 2014 08:54:44 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2014 00:54:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="503030860"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by orsmga003.jf.intel.com with ESMTP; 23 Dec 2014 00:50:01 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 23 Dec 2014 16:54:35 +0800
Message-Id: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	JBeulich@suse.com, keir@xen.org
Subject: [Xen-devel] [PATCH 0/4] enable Memory Bandwidth Monitoring (MBM)
	for VMs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Intel Memory Bandwidth Monitoring(MBM) is a new hardware feature
which builds on the CMT infrastructure to allow monitoring of system
memory bandwidth. Event codes are provided to monitor both "total"
and "local" bandwidth, meaning bandwidth over QPI and other external
links can be monitored.

For XEN, MBM is used to monitor memory bandwidth for VMs. Due to its
dependency on CMT, the software also makes use of most of CMT codes.
Actually, besides introducing two additional events and some cpuid
feature bits, there are no extra changes compared to cache occupancy
monitoring in CMT. Due to this, CMT should be enabled first to use
this feature.

For interface changes, the patch serial only introduces a new command
"XEN_SYSCTL_PSR_CMT_get_l3_event_mask" which exposes MBM feature
capability to user space and introduces two additional options for
"xl psr-cmt-show":
total_mem_bandwidth:     Show total memory bandwidth
local_mem_bandwidth:     Show local memory bandwidth

The usage flow keeps the same with CMT.

Chao Peng (4):
  x86: expose CMT L3 event mask to user space
  tools: libxc: add routine to get CMT L3 event mask
  tools: libxl: code preparation for MBM
  tools: add total/local memory bandwith monitoring

 docs/man/xl.pod.1             |    2 +
 tools/libxc/include/xenctrl.h |    3 ++
 tools/libxc/xc_psr.c          |   40 +++++++++++++++++
 tools/libxl/libxl.h           |    4 ++
 tools/libxl/libxl_psr.c       |  100 ++++++++++++++++++++++++++++++++++-------
 tools/libxl/libxl_types.idl   |    2 +
 tools/libxl/xl_cmdimpl.c      |   63 +++++++++++++++++---------
 tools/libxl/xl_cmdtable.c     |    4 +-
 xen/arch/x86/sysctl.c         |    5 +++
 xen/include/public/sysctl.h   |    1 +
 10 files changed, 186 insertions(+), 38 deletions(-)

-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 08:55:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08: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 1Y3LEz-0003oI-8P; Tue, 23 Dec 2014 08:54:53 +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 1Y3LEx-0003nv-St
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 08:54:52 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	0C/3E-08051-BDD29945; Tue, 23 Dec 2014 08:54:51 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419324884!12091991!4
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 13016 invoked from network); 23 Dec 2014 08:54:50 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-27.messagelabs.com with SMTP;
	23 Dec 2014 08:54:50 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2014 00:54:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="503030879"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by orsmga003.jf.intel.com with ESMTP; 23 Dec 2014 00:50:08 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 23 Dec 2014 16:54:38 +0800
Message-Id: <1419324880-13212-4-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	JBeulich@suse.com, keir@xen.org
Subject: [Xen-devel] [PATCH 3/4] tools: libxl: code preparation for MBM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Make some internal routines common so that total/local memory bandwidth
monitoring in the next patch can make use of them.

Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
---
 tools/libxl/libxl_psr.c  |   42 ++++++++++++++++++++++----------------
 tools/libxl/xl_cmdimpl.c |   51 ++++++++++++++++++++++++++++------------------
 2 files changed, 56 insertions(+), 37 deletions(-)

diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index 0437465..21ad819 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -160,40 +160,48 @@ out:
     return rc;
 }
 
-int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx, uint32_t domid,
-    uint32_t socketid, uint32_t *l3_cache_occupancy)
+static int libxl__psr_cmt_get_l3_monitoring_data(libxl__gc *gc, uint32_t domid,
+    xc_psr_cmt_type type, uint32_t socketid, uint64_t *data)
 {
-    GC_INIT(ctx);
 
     unsigned int rmid;
-    uint32_t upscaling_factor;
-    uint64_t monitor_data;
     int cpu, rc;
-    xc_psr_cmt_type type;
 
-    rc = xc_psr_cmt_get_domain_rmid(ctx->xch, domid, &rmid);
+    rc = xc_psr_cmt_get_domain_rmid(CTX->xch, domid, &rmid);
     if (rc < 0 || rmid == 0) {
         LOGE(ERROR, "fail to get the domain rmid, "
             "or domain is not attached with platform QoS monitoring service");
-        rc = ERROR_FAIL;
-        goto out;
+        return ERROR_FAIL;
     }
 
     cpu = libxl__pick_socket_cpu(gc, socketid);
     if (cpu < 0) {
         LOGE(ERROR, "failed to get socket cpu");
-        rc = ERROR_FAIL;
-        goto out;
+        return ERROR_FAIL;
     }
 
-    type = XC_PSR_CMT_L3_OCCUPANCY;
-    rc = xc_psr_cmt_get_data(ctx->xch, rmid, cpu, type, &monitor_data);
+    rc = xc_psr_cmt_get_data(CTX->xch, rmid, cpu, type, data);
     if (rc < 0) {
         LOGE(ERROR, "failed to get monitoring data");
-        rc = ERROR_FAIL;
-        goto out;
+        return ERROR_FAIL;
     }
 
+    return rc;
+}
+
+int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx, uint32_t domid,
+    uint32_t socketid, uint32_t *l3_cache_occupancy)
+{
+    GC_INIT(ctx);
+    uint64_t data;
+    uint32_t upscaling_factor;
+    int rc;
+
+    rc= libxl__psr_cmt_get_l3_monitoring_data(gc, domid,
+                    XC_PSR_CMT_L3_OCCUPANCY, socketid, &data);
+    if (rc < 0)
+            goto out;
+
     rc = xc_psr_cmt_get_l3_upscaling_factor(ctx->xch, &upscaling_factor);
     if (rc < 0) {
         LOGE(ERROR, "failed to get L3 upscaling factor");
@@ -201,8 +209,8 @@ int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx, uint32_t domid,
         goto out;
     }
 
-    *l3_cache_occupancy = upscaling_factor * monitor_data / 1024;
-    rc = 0;
+    *l3_cache_occupancy = upscaling_factor * data / 1024;
+
 out:
     GC_FREE;
     return rc;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3737c7e..f4534ec 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7845,12 +7845,13 @@ out:
 }
 
 #ifdef LIBXL_HAVE_PSR_CMT
-static void psr_cmt_print_domain_cache_occupancy(libxl_dominfo *dominfo,
+static void psr_cmt_print_domain_l3_info(libxl_dominfo *dominfo,
+                                                    libxl_psr_cmt_type type,
                                                     uint32_t nr_sockets)
 {
     char *domain_name;
     uint32_t socketid;
-    uint32_t l3_cache_occupancy;
+    uint32_t data;
 
     if (!libxl_psr_cmt_domain_attached(ctx, dominfo->domid))
         return;
@@ -7860,15 +7861,21 @@ static void psr_cmt_print_domain_cache_occupancy(libxl_dominfo *dominfo,
     free(domain_name);
 
     for (socketid = 0; socketid < nr_sockets; socketid++) {
-        if ( !libxl_psr_cmt_get_cache_occupancy(ctx, dominfo->domid,
-                 socketid, &l3_cache_occupancy) )
-            printf("%13u KB", l3_cache_occupancy);
+        switch (type) {
+        case LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY:
+            if ( !libxl_psr_cmt_get_cache_occupancy(ctx, dominfo->domid,
+                 socketid, &data) )
+                printf("%13u KB", data);
+            break;
+        default:
+            return;
+        }
     }
 
     printf("\n");
 }
 
-static int psr_cmt_show_cache_occupancy(uint32_t domid)
+static int psr_cmt_show_l3_info(libxl_psr_cmt_type type, uint32_t domid)
 {
     uint32_t i, socketid, nr_sockets, total_rmid;
     uint32_t l3_cache_size;
@@ -7904,18 +7911,22 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
         printf("%14s %d", "Socket", socketid);
     printf("\n");
 
-    /* Total L3 cache size */
-    printf("%-46s", "Total L3 Cache Size");
-    for (socketid = 0; socketid < nr_sockets; socketid++) {
-        rc = libxl_psr_cmt_get_l3_cache_size(ctx, socketid, &l3_cache_size);
-        if (rc < 0) {
-            fprintf(stderr, "Failed to get system l3 cache size for socket:%d\n",
-                            socketid);
-            return -1;
-        }
-        printf("%13u KB", l3_cache_size);
+    if ( type == LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY ) {
+            /* Total L3 cache size */
+            printf("%-46s", "Total L3 Cache Size");
+            for (socketid = 0; socketid < nr_sockets; socketid++) {
+                rc = libxl_psr_cmt_get_l3_cache_size(ctx, socketid,
+                                &l3_cache_size);
+                if (rc < 0) {
+                    fprintf(stderr,
+                        "Failed to get system l3 cache size for socket:%d\n",
+                         socketid);
+                    return -1;
+                }
+                printf("%13u KB", l3_cache_size);
+            }
+            printf("\n");
     }
-    printf("\n");
 
     /* Each domain */
     if (domid != INVALID_DOMID) {
@@ -7924,7 +7935,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
             fprintf(stderr, "Failed to get domain info for %d\n", domid);
             return -1;
         }
-        psr_cmt_print_domain_cache_occupancy(&dominfo, nr_sockets);
+        psr_cmt_print_domain_l3_info(&dominfo, type, nr_sockets);
     }
     else
     {
@@ -7934,7 +7945,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
             return -1;
         }
         for (i = 0; i < nr_domains; i++)
-            psr_cmt_print_domain_cache_occupancy(list + i, nr_sockets);
+            psr_cmt_print_domain_l3_info(list + i, type, nr_sockets);
         libxl_dominfo_list_free(list, nr_domains);
     }
     return 0;
@@ -7993,7 +8004,7 @@ int main_psr_cmt_show(int argc, char **argv)
 
     switch (type) {
     case LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY:
-        ret = psr_cmt_show_cache_occupancy(domid);
+        ret = psr_cmt_show_l3_info(type, domid);
         break;
     default:
         help("psr-cmt-show");
-- 
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 Dec 23 08:55:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08: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 1Y3LEx-0003nw-SR; Tue, 23 Dec 2014 08:54:51 +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 1Y3LEv-0003nk-Vx
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 08:54:50 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	56/04-03148-9DD29945; Tue, 23 Dec 2014 08:54:49 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419324884!12091991!3
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 12242 invoked from network); 23 Dec 2014 08:54:48 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-27.messagelabs.com with SMTP;
	23 Dec 2014 08:54:48 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2014 00:54:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="503030874"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by orsmga003.jf.intel.com with ESMTP; 23 Dec 2014 00:50:06 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 23 Dec 2014 16:54:37 +0800
Message-Id: <1419324880-13212-3-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	JBeulich@suse.com, keir@xen.org
Subject: [Xen-devel] [PATCH 2/4] tools: libxc: add routine to get CMT L3
	event 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is the xc side wrapper for XEN_SYSCTL_PSR_CMT_get_l3_event_mask
of XEN_SYSCTL_psr_cmt_op. Additional check for event id against value
got from this routine is also added.

Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
---
 tools/libxc/include/xenctrl.h |    1 +
 tools/libxc/xc_psr.c          |   32 ++++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..96b357c 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2697,6 +2697,7 @@ int xc_psr_cmt_get_domain_rmid(xc_interface *xch, uint32_t domid,
 int xc_psr_cmt_get_total_rmid(xc_interface *xch, uint32_t *total_rmid);
 int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
     uint32_t *upscaling_factor);
+int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask);
 int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
     uint32_t *l3_cache_size);
 int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index 872e6dc..94c8698 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -112,6 +112,30 @@ int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
     return rc;
 }
 
+int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask)
+{
+    static int val = 0;
+    int rc;
+    DECLARE_SYSCTL;
+
+    if ( val )
+    {
+        *event_mask = val;
+        return 0;
+    }
+
+    sysctl.cmd = XEN_SYSCTL_psr_cmt_op;
+    sysctl.u.psr_cmt_op.cmd =
+        XEN_SYSCTL_PSR_CMT_get_l3_event_mask;
+    sysctl.u.psr_cmt_op.flags = 0;
+
+    rc = xc_sysctl(xch, &sysctl);
+    if ( !rc )
+        val = *event_mask = sysctl.u.psr_cmt_op.u.data;
+
+    return rc;
+}
+
 int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
                                       uint32_t *l3_cache_size)
 {
@@ -144,6 +168,7 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
     xc_resource_op_t op;
     xc_resource_entry_t entries[2];
     uint32_t evtid;
+    uint32_t event_mask;
     int rc;
 
     switch ( type )
@@ -155,6 +180,13 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
         return -1;
     }
 
+    rc = xc_psr_cmt_get_l3_event_mask(xch, &event_mask);
+    if ( rc < 0 )
+        return rc;
+
+    if ( !(event_mask & (1 << (evtid - 1))) )
+        return -1;
+
     entries[0].u.cmd = XEN_RESOURCE_OP_MSR_WRITE;
     entries[0].idx = MSR_IA32_CMT_EVTSEL;
     entries[0].val = (uint64_t)rmid << 32 | evtid;
-- 
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 Dec 23 08:55:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08: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 1Y3LF8-0003q2-Oa; Tue, 23 Dec 2014 08:55:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1Y3LF6-0003pg-LD
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 08:55:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5B/4B-15461-3ED29945; Tue, 23 Dec 2014 08:54:59 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1419324897!17372859!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 545 invoked from network); 23 Dec 2014 08:54:58 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-11.tower-21.messagelabs.com with SMTP;
	23 Dec 2014 08:54:58 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 23 Dec 2014 00:52:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="503030885"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by orsmga003.jf.intel.com with ESMTP; 23 Dec 2014 00:50:10 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 23 Dec 2014 16:54:39 +0800
Message-Id: <1419324880-13212-5-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	JBeulich@suse.com, keir@xen.org
Subject: [Xen-devel] [PATCH 4/4] tools: add total/local memory bandwith
	monitoring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 Memory Bandwidth Monitoring(MBM) for VMs. Two types of monitoring
are supported: total and local memory bandwidth monitoring. To use it,
CMT should be enabled in hypervisor.

Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
---
 docs/man/xl.pod.1             |    2 ++
 tools/libxc/include/xenctrl.h |    2 ++
 tools/libxc/xc_psr.c          |    8 ++++++
 tools/libxl/libxl.h           |    4 +++
 tools/libxl/libxl_psr.c       |   58 +++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_types.idl   |    2 ++
 tools/libxl/xl_cmdimpl.c      |   12 +++++++++
 tools/libxl/xl_cmdtable.c     |    4 ++-
 8 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 6b89ba8..28d5006 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1476,6 +1476,8 @@ detach: Detach the platform shared resource monitoring service from a domain.
 Show monitoring data for a certain domain or all domains. Current supported
 monitor types are:
  - "cache-occupancy": showing the L3 cache occupancy.
+ - "total-mem-bandwidth": showing the total memory bandwidth.
+ - "local-mem-bandwidth": showing the local memory bandwidth.
 
 =back
 
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 96b357c..2b07e4e 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2688,6 +2688,8 @@ int xc_resource_op(xc_interface *xch, uint32_t nr_ops, xc_resource_op_t *ops);
 #if defined(__i386__) || defined(__x86_64__)
 enum xc_psr_cmt_type {
     XC_PSR_CMT_L3_OCCUPANCY,
+    XC_PSR_CMT_TOTAL_MEM_BANDWIDTH,
+    XC_PSR_CMT_LOCAL_MEM_BANDWIDTH,
 };
 typedef enum xc_psr_cmt_type xc_psr_cmt_type;
 int xc_psr_cmt_attach(xc_interface *xch, uint32_t domid);
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index 94c8698..e286184 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -23,6 +23,8 @@
 #define IA32_CMT_CTR_ERROR_MASK         (0x3ull << 62)
 
 #define EVTID_L3_OCCUPANCY             0x1
+#define EVTID_TOTAL_MEM_BANDWIDTH      0x2
+#define EVTID_LOCAL_MEM_BANDWIDTH      0x3
 
 int xc_psr_cmt_attach(xc_interface *xch, uint32_t domid)
 {
@@ -176,6 +178,12 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
     case XC_PSR_CMT_L3_OCCUPANCY:
         evtid = EVTID_L3_OCCUPANCY;
         break;
+    case XC_PSR_CMT_TOTAL_MEM_BANDWIDTH:
+        evtid = EVTID_TOTAL_MEM_BANDWIDTH;
+        break;
+    case XC_PSR_CMT_LOCAL_MEM_BANDWIDTH:
+        evtid = EVTID_LOCAL_MEM_BANDWIDTH;
+        break;
     default:
         return -1;
     }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0a123f1..bc6cc92 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1458,6 +1458,10 @@ int libxl_psr_cmt_get_l3_cache_size(libxl_ctx *ctx, uint32_t socketid,
     uint32_t *l3_cache_size);
 int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx, uint32_t domid,
     uint32_t socketid, uint32_t *l3_cache_occupancy);
+int libxl_psr_cmt_get_total_mem_bandwidth(libxl_ctx *ctx, uint32_t domid,
+    uint32_t socketid, uint32_t *bandwidth);
+int libxl_psr_cmt_get_local_mem_bandwidth(libxl_ctx *ctx, uint32_t domid,
+    uint32_t socketid, uint32_t *bandwidth);
 #endif
 
 /* misc */
diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index 21ad819..0f5e38f 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -216,6 +216,64 @@ out:
     return rc;
 }
 
+static int libxl__psr_cmt_get_mem_bandwidth(libxl__gc *gc, uint32_t domid,
+    xc_psr_cmt_type type, uint32_t socketid, uint32_t *bandwidth)
+{
+    uint64_t sample1, sample2;
+    uint32_t upscaling_factor;
+    int rc;
+
+    rc = libxl__psr_cmt_get_l3_monitoring_data(gc, domid,
+                    type, socketid, &sample1);
+    if (rc < 0)
+        return ERROR_FAIL;
+
+    usleep(10000);
+
+    rc = libxl__psr_cmt_get_l3_monitoring_data(gc, domid,
+                    type, socketid, &sample2);
+    if (rc < 0)
+       return ERROR_FAIL;
+
+    if (sample2 < sample1) {
+         LOGE(ERROR, "event counter overflowed between two samplings");
+         return ERROR_FAIL;
+    }
+
+    rc = xc_psr_cmt_get_l3_upscaling_factor(CTX->xch, &upscaling_factor);
+    if (rc < 0) {
+        LOGE(ERROR, "failed to get L3 upscaling factor");
+        return ERROR_FAIL;
+    }
+
+    *bandwidth = (sample2 - sample1) * 100 *  upscaling_factor / 1024;
+    return rc;
+}
+
+int libxl_psr_cmt_get_total_mem_bandwidth(libxl_ctx *ctx, uint32_t domid,
+    uint32_t socketid, uint32_t *bandwidth)
+{
+    GC_INIT(ctx);
+    int rc;
+
+    rc = libxl__psr_cmt_get_mem_bandwidth(gc, domid,
+                    XC_PSR_CMT_TOTAL_MEM_BANDWIDTH, socketid, bandwidth);
+    GC_FREE;
+    return rc;
+}
+
+int libxl_psr_cmt_get_local_mem_bandwidth(libxl_ctx *ctx, uint32_t domid,
+    uint32_t socketid, uint32_t *bandwidth)
+{
+    GC_INIT(ctx);
+    int rc;
+
+    rc = libxl__psr_cmt_get_mem_bandwidth(gc, domid,
+                    XC_PSR_CMT_LOCAL_MEM_BANDWIDTH, socketid, bandwidth);
+    GC_FREE;
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..8029a39 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -693,4 +693,6 @@ libxl_event = Struct("event",[
 
 libxl_psr_cmt_type = Enumeration("psr_cmt_type", [
     (1, "CACHE_OCCUPANCY"),
+    (2, "TOTAL_MEM_BANDWIDTH"),
+    (3, "LOCAL_MEM_BANDWIDTH"),
     ])
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f4534ec..e0435dd 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7867,6 +7867,16 @@ static void psr_cmt_print_domain_l3_info(libxl_dominfo *dominfo,
                  socketid, &data) )
                 printf("%13u KB", data);
             break;
+        case LIBXL_PSR_CMT_TYPE_TOTAL_MEM_BANDWIDTH:
+            if ( !libxl_psr_cmt_get_total_mem_bandwidth(ctx, dominfo->domid,
+                 socketid, &data) )
+                printf("%11u KB/s", data);
+            break;
+        case LIBXL_PSR_CMT_TYPE_LOCAL_MEM_BANDWIDTH:
+            if ( !libxl_psr_cmt_get_local_mem_bandwidth(ctx, dominfo->domid,
+                 socketid, &data) )
+                printf("%11u KB/s", data);
+            break;
         default:
             return;
         }
@@ -8004,6 +8014,8 @@ int main_psr_cmt_show(int argc, char **argv)
 
     switch (type) {
     case LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY:
+    case LIBXL_PSR_CMT_TYPE_TOTAL_MEM_BANDWIDTH:
+    case LIBXL_PSR_CMT_TYPE_LOCAL_MEM_BANDWIDTH:
         ret = psr_cmt_show_l3_info(type, domid);
         break;
     default:
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 4b30d3d..2d8f272 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -538,7 +538,9 @@ struct cmd_spec cmd_table[] = {
       "Show Cache Monitoring Technology information",
       "<PSR-CMT-Type> <Domain>",
       "Available monitor types:\n"
-      "\"cache_occupancy\":         Show L3 cache occupancy\n",
+      "\"cache_occupancy\":         Show L3 cache occupancy\n"
+      "\"total_mem_bandwidth\":     Show total memory bandwidth\n"
+      "\"local_mem_bandwidth\":     Show local memory bandwidth\n",
     },
 #endif
 };
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 08:55:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08: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 1Y3LF8-0003q2-Oa; Tue, 23 Dec 2014 08:55:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1Y3LF6-0003pg-LD
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 08:55:00 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	5B/4B-15461-3ED29945; Tue, 23 Dec 2014 08:54:59 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1419324897!17372859!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 545 invoked from network); 23 Dec 2014 08:54:58 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-11.tower-21.messagelabs.com with SMTP;
	23 Dec 2014 08:54:58 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 23 Dec 2014 00:52:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="503030885"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by orsmga003.jf.intel.com with ESMTP; 23 Dec 2014 00:50:10 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 23 Dec 2014 16:54:39 +0800
Message-Id: <1419324880-13212-5-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	JBeulich@suse.com, keir@xen.org
Subject: [Xen-devel] [PATCH 4/4] tools: add total/local memory bandwith
	monitoring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 Memory Bandwidth Monitoring(MBM) for VMs. Two types of monitoring
are supported: total and local memory bandwidth monitoring. To use it,
CMT should be enabled in hypervisor.

Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
---
 docs/man/xl.pod.1             |    2 ++
 tools/libxc/include/xenctrl.h |    2 ++
 tools/libxc/xc_psr.c          |    8 ++++++
 tools/libxl/libxl.h           |    4 +++
 tools/libxl/libxl_psr.c       |   58 +++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_types.idl   |    2 ++
 tools/libxl/xl_cmdimpl.c      |   12 +++++++++
 tools/libxl/xl_cmdtable.c     |    4 ++-
 8 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 6b89ba8..28d5006 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1476,6 +1476,8 @@ detach: Detach the platform shared resource monitoring service from a domain.
 Show monitoring data for a certain domain or all domains. Current supported
 monitor types are:
  - "cache-occupancy": showing the L3 cache occupancy.
+ - "total-mem-bandwidth": showing the total memory bandwidth.
+ - "local-mem-bandwidth": showing the local memory bandwidth.
 
 =back
 
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 96b357c..2b07e4e 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2688,6 +2688,8 @@ int xc_resource_op(xc_interface *xch, uint32_t nr_ops, xc_resource_op_t *ops);
 #if defined(__i386__) || defined(__x86_64__)
 enum xc_psr_cmt_type {
     XC_PSR_CMT_L3_OCCUPANCY,
+    XC_PSR_CMT_TOTAL_MEM_BANDWIDTH,
+    XC_PSR_CMT_LOCAL_MEM_BANDWIDTH,
 };
 typedef enum xc_psr_cmt_type xc_psr_cmt_type;
 int xc_psr_cmt_attach(xc_interface *xch, uint32_t domid);
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index 94c8698..e286184 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -23,6 +23,8 @@
 #define IA32_CMT_CTR_ERROR_MASK         (0x3ull << 62)
 
 #define EVTID_L3_OCCUPANCY             0x1
+#define EVTID_TOTAL_MEM_BANDWIDTH      0x2
+#define EVTID_LOCAL_MEM_BANDWIDTH      0x3
 
 int xc_psr_cmt_attach(xc_interface *xch, uint32_t domid)
 {
@@ -176,6 +178,12 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
     case XC_PSR_CMT_L3_OCCUPANCY:
         evtid = EVTID_L3_OCCUPANCY;
         break;
+    case XC_PSR_CMT_TOTAL_MEM_BANDWIDTH:
+        evtid = EVTID_TOTAL_MEM_BANDWIDTH;
+        break;
+    case XC_PSR_CMT_LOCAL_MEM_BANDWIDTH:
+        evtid = EVTID_LOCAL_MEM_BANDWIDTH;
+        break;
     default:
         return -1;
     }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0a123f1..bc6cc92 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1458,6 +1458,10 @@ int libxl_psr_cmt_get_l3_cache_size(libxl_ctx *ctx, uint32_t socketid,
     uint32_t *l3_cache_size);
 int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx, uint32_t domid,
     uint32_t socketid, uint32_t *l3_cache_occupancy);
+int libxl_psr_cmt_get_total_mem_bandwidth(libxl_ctx *ctx, uint32_t domid,
+    uint32_t socketid, uint32_t *bandwidth);
+int libxl_psr_cmt_get_local_mem_bandwidth(libxl_ctx *ctx, uint32_t domid,
+    uint32_t socketid, uint32_t *bandwidth);
 #endif
 
 /* misc */
diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index 21ad819..0f5e38f 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -216,6 +216,64 @@ out:
     return rc;
 }
 
+static int libxl__psr_cmt_get_mem_bandwidth(libxl__gc *gc, uint32_t domid,
+    xc_psr_cmt_type type, uint32_t socketid, uint32_t *bandwidth)
+{
+    uint64_t sample1, sample2;
+    uint32_t upscaling_factor;
+    int rc;
+
+    rc = libxl__psr_cmt_get_l3_monitoring_data(gc, domid,
+                    type, socketid, &sample1);
+    if (rc < 0)
+        return ERROR_FAIL;
+
+    usleep(10000);
+
+    rc = libxl__psr_cmt_get_l3_monitoring_data(gc, domid,
+                    type, socketid, &sample2);
+    if (rc < 0)
+       return ERROR_FAIL;
+
+    if (sample2 < sample1) {
+         LOGE(ERROR, "event counter overflowed between two samplings");
+         return ERROR_FAIL;
+    }
+
+    rc = xc_psr_cmt_get_l3_upscaling_factor(CTX->xch, &upscaling_factor);
+    if (rc < 0) {
+        LOGE(ERROR, "failed to get L3 upscaling factor");
+        return ERROR_FAIL;
+    }
+
+    *bandwidth = (sample2 - sample1) * 100 *  upscaling_factor / 1024;
+    return rc;
+}
+
+int libxl_psr_cmt_get_total_mem_bandwidth(libxl_ctx *ctx, uint32_t domid,
+    uint32_t socketid, uint32_t *bandwidth)
+{
+    GC_INIT(ctx);
+    int rc;
+
+    rc = libxl__psr_cmt_get_mem_bandwidth(gc, domid,
+                    XC_PSR_CMT_TOTAL_MEM_BANDWIDTH, socketid, bandwidth);
+    GC_FREE;
+    return rc;
+}
+
+int libxl_psr_cmt_get_local_mem_bandwidth(libxl_ctx *ctx, uint32_t domid,
+    uint32_t socketid, uint32_t *bandwidth)
+{
+    GC_INIT(ctx);
+    int rc;
+
+    rc = libxl__psr_cmt_get_mem_bandwidth(gc, domid,
+                    XC_PSR_CMT_LOCAL_MEM_BANDWIDTH, socketid, bandwidth);
+    GC_FREE;
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..8029a39 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -693,4 +693,6 @@ libxl_event = Struct("event",[
 
 libxl_psr_cmt_type = Enumeration("psr_cmt_type", [
     (1, "CACHE_OCCUPANCY"),
+    (2, "TOTAL_MEM_BANDWIDTH"),
+    (3, "LOCAL_MEM_BANDWIDTH"),
     ])
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f4534ec..e0435dd 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7867,6 +7867,16 @@ static void psr_cmt_print_domain_l3_info(libxl_dominfo *dominfo,
                  socketid, &data) )
                 printf("%13u KB", data);
             break;
+        case LIBXL_PSR_CMT_TYPE_TOTAL_MEM_BANDWIDTH:
+            if ( !libxl_psr_cmt_get_total_mem_bandwidth(ctx, dominfo->domid,
+                 socketid, &data) )
+                printf("%11u KB/s", data);
+            break;
+        case LIBXL_PSR_CMT_TYPE_LOCAL_MEM_BANDWIDTH:
+            if ( !libxl_psr_cmt_get_local_mem_bandwidth(ctx, dominfo->domid,
+                 socketid, &data) )
+                printf("%11u KB/s", data);
+            break;
         default:
             return;
         }
@@ -8004,6 +8014,8 @@ int main_psr_cmt_show(int argc, char **argv)
 
     switch (type) {
     case LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY:
+    case LIBXL_PSR_CMT_TYPE_TOTAL_MEM_BANDWIDTH:
+    case LIBXL_PSR_CMT_TYPE_LOCAL_MEM_BANDWIDTH:
         ret = psr_cmt_show_l3_info(type, domid);
         break;
     default:
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 4b30d3d..2d8f272 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -538,7 +538,9 @@ struct cmd_spec cmd_table[] = {
       "Show Cache Monitoring Technology information",
       "<PSR-CMT-Type> <Domain>",
       "Available monitor types:\n"
-      "\"cache_occupancy\":         Show L3 cache occupancy\n",
+      "\"cache_occupancy\":         Show L3 cache occupancy\n"
+      "\"total_mem_bandwidth\":     Show total memory bandwidth\n"
+      "\"local_mem_bandwidth\":     Show local memory bandwidth\n",
     },
 #endif
 };
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 08:55:17 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08: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 1Y3LEz-0003oI-8P; Tue, 23 Dec 2014 08:54:53 +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 1Y3LEx-0003nv-St
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 08:54:52 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	0C/3E-08051-BDD29945; Tue, 23 Dec 2014 08:54:51 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419324884!12091991!4
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 13016 invoked from network); 23 Dec 2014 08:54:50 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-27.messagelabs.com with SMTP;
	23 Dec 2014 08:54:50 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by fmsmga101.fm.intel.com with ESMTP; 23 Dec 2014 00:54:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="503030879"
Received: from pengc-linux.bj.intel.com ([10.238.145.52])
	by orsmga003.jf.intel.com with ESMTP; 23 Dec 2014 00:50:08 -0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 23 Dec 2014 16:54:38 +0800
Message-Id: <1419324880-13212-4-git-send-email-chao.p.peng@linux.intel.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	JBeulich@suse.com, keir@xen.org
Subject: [Xen-devel] [PATCH 3/4] tools: libxl: code preparation for MBM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Make some internal routines common so that total/local memory bandwidth
monitoring in the next patch can make use of them.

Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
---
 tools/libxl/libxl_psr.c  |   42 ++++++++++++++++++++++----------------
 tools/libxl/xl_cmdimpl.c |   51 ++++++++++++++++++++++++++++------------------
 2 files changed, 56 insertions(+), 37 deletions(-)

diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index 0437465..21ad819 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -160,40 +160,48 @@ out:
     return rc;
 }
 
-int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx, uint32_t domid,
-    uint32_t socketid, uint32_t *l3_cache_occupancy)
+static int libxl__psr_cmt_get_l3_monitoring_data(libxl__gc *gc, uint32_t domid,
+    xc_psr_cmt_type type, uint32_t socketid, uint64_t *data)
 {
-    GC_INIT(ctx);
 
     unsigned int rmid;
-    uint32_t upscaling_factor;
-    uint64_t monitor_data;
     int cpu, rc;
-    xc_psr_cmt_type type;
 
-    rc = xc_psr_cmt_get_domain_rmid(ctx->xch, domid, &rmid);
+    rc = xc_psr_cmt_get_domain_rmid(CTX->xch, domid, &rmid);
     if (rc < 0 || rmid == 0) {
         LOGE(ERROR, "fail to get the domain rmid, "
             "or domain is not attached with platform QoS monitoring service");
-        rc = ERROR_FAIL;
-        goto out;
+        return ERROR_FAIL;
     }
 
     cpu = libxl__pick_socket_cpu(gc, socketid);
     if (cpu < 0) {
         LOGE(ERROR, "failed to get socket cpu");
-        rc = ERROR_FAIL;
-        goto out;
+        return ERROR_FAIL;
     }
 
-    type = XC_PSR_CMT_L3_OCCUPANCY;
-    rc = xc_psr_cmt_get_data(ctx->xch, rmid, cpu, type, &monitor_data);
+    rc = xc_psr_cmt_get_data(CTX->xch, rmid, cpu, type, data);
     if (rc < 0) {
         LOGE(ERROR, "failed to get monitoring data");
-        rc = ERROR_FAIL;
-        goto out;
+        return ERROR_FAIL;
     }
 
+    return rc;
+}
+
+int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx, uint32_t domid,
+    uint32_t socketid, uint32_t *l3_cache_occupancy)
+{
+    GC_INIT(ctx);
+    uint64_t data;
+    uint32_t upscaling_factor;
+    int rc;
+
+    rc= libxl__psr_cmt_get_l3_monitoring_data(gc, domid,
+                    XC_PSR_CMT_L3_OCCUPANCY, socketid, &data);
+    if (rc < 0)
+            goto out;
+
     rc = xc_psr_cmt_get_l3_upscaling_factor(ctx->xch, &upscaling_factor);
     if (rc < 0) {
         LOGE(ERROR, "failed to get L3 upscaling factor");
@@ -201,8 +209,8 @@ int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx, uint32_t domid,
         goto out;
     }
 
-    *l3_cache_occupancy = upscaling_factor * monitor_data / 1024;
-    rc = 0;
+    *l3_cache_occupancy = upscaling_factor * data / 1024;
+
 out:
     GC_FREE;
     return rc;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3737c7e..f4534ec 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7845,12 +7845,13 @@ out:
 }
 
 #ifdef LIBXL_HAVE_PSR_CMT
-static void psr_cmt_print_domain_cache_occupancy(libxl_dominfo *dominfo,
+static void psr_cmt_print_domain_l3_info(libxl_dominfo *dominfo,
+                                                    libxl_psr_cmt_type type,
                                                     uint32_t nr_sockets)
 {
     char *domain_name;
     uint32_t socketid;
-    uint32_t l3_cache_occupancy;
+    uint32_t data;
 
     if (!libxl_psr_cmt_domain_attached(ctx, dominfo->domid))
         return;
@@ -7860,15 +7861,21 @@ static void psr_cmt_print_domain_cache_occupancy(libxl_dominfo *dominfo,
     free(domain_name);
 
     for (socketid = 0; socketid < nr_sockets; socketid++) {
-        if ( !libxl_psr_cmt_get_cache_occupancy(ctx, dominfo->domid,
-                 socketid, &l3_cache_occupancy) )
-            printf("%13u KB", l3_cache_occupancy);
+        switch (type) {
+        case LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY:
+            if ( !libxl_psr_cmt_get_cache_occupancy(ctx, dominfo->domid,
+                 socketid, &data) )
+                printf("%13u KB", data);
+            break;
+        default:
+            return;
+        }
     }
 
     printf("\n");
 }
 
-static int psr_cmt_show_cache_occupancy(uint32_t domid)
+static int psr_cmt_show_l3_info(libxl_psr_cmt_type type, uint32_t domid)
 {
     uint32_t i, socketid, nr_sockets, total_rmid;
     uint32_t l3_cache_size;
@@ -7904,18 +7911,22 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
         printf("%14s %d", "Socket", socketid);
     printf("\n");
 
-    /* Total L3 cache size */
-    printf("%-46s", "Total L3 Cache Size");
-    for (socketid = 0; socketid < nr_sockets; socketid++) {
-        rc = libxl_psr_cmt_get_l3_cache_size(ctx, socketid, &l3_cache_size);
-        if (rc < 0) {
-            fprintf(stderr, "Failed to get system l3 cache size for socket:%d\n",
-                            socketid);
-            return -1;
-        }
-        printf("%13u KB", l3_cache_size);
+    if ( type == LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY ) {
+            /* Total L3 cache size */
+            printf("%-46s", "Total L3 Cache Size");
+            for (socketid = 0; socketid < nr_sockets; socketid++) {
+                rc = libxl_psr_cmt_get_l3_cache_size(ctx, socketid,
+                                &l3_cache_size);
+                if (rc < 0) {
+                    fprintf(stderr,
+                        "Failed to get system l3 cache size for socket:%d\n",
+                         socketid);
+                    return -1;
+                }
+                printf("%13u KB", l3_cache_size);
+            }
+            printf("\n");
     }
-    printf("\n");
 
     /* Each domain */
     if (domid != INVALID_DOMID) {
@@ -7924,7 +7935,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
             fprintf(stderr, "Failed to get domain info for %d\n", domid);
             return -1;
         }
-        psr_cmt_print_domain_cache_occupancy(&dominfo, nr_sockets);
+        psr_cmt_print_domain_l3_info(&dominfo, type, nr_sockets);
     }
     else
     {
@@ -7934,7 +7945,7 @@ static int psr_cmt_show_cache_occupancy(uint32_t domid)
             return -1;
         }
         for (i = 0; i < nr_domains; i++)
-            psr_cmt_print_domain_cache_occupancy(list + i, nr_sockets);
+            psr_cmt_print_domain_l3_info(list + i, type, nr_sockets);
         libxl_dominfo_list_free(list, nr_domains);
     }
     return 0;
@@ -7993,7 +8004,7 @@ int main_psr_cmt_show(int argc, char **argv)
 
     switch (type) {
     case LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY:
-        ret = psr_cmt_show_cache_occupancy(domid);
+        ret = psr_cmt_show_l3_info(type, domid);
         break;
     default:
         help("psr-cmt-show");
-- 
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 Dec 23 08:56:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08: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 1Y3LGE-0004A7-92; Tue, 23 Dec 2014 08:56:10 +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 1Y3LGC-00049i-Aj
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 08:56:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	1C/86-09842-72E29945; Tue, 23 Dec 2014 08:56:07 +0000
X-Env-Sender: jasowang@redhat.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1419324965!10101174!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.1 required=7.0 tests=ratty_date: unknown 
	timezone in: Mon, 22 Dec 2014 10:10:01 +0008,ratty_date: unknown 
	timezone in: Mon, 22 Dec 2014 10:10:01 +0008,sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25491 invoked from network); 23 Dec 2014 08:56:07 -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; 23 Dec 2014 08:56:07 -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 sBN8tutR016761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 23 Dec 2014 03:55:56 -0500
Received: from [10.66.71.84] (dhcp-66-71-84.eng.nay.redhat.com [10.66.71.84]
	(may be forged))
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBN8tj3h028187; Tue, 23 Dec 2014 03:55:48 -0500
Date: Mon, 22 Dec 2014 10:10:01 +0008
From: Jason Wang <jasowang@redhat.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Message-Id: <1419242521.4592.0@smtp.corp.redhat.com>
In-Reply-To: <20141222093525.GA18616@gondor.apana.org.au>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<5497D3D9.2070509@redhat.com>
	<20141222093525.GA18616@gondor.apana.org.au>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: netdev@vger.kernel.org, edumazet@google.com,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] caif: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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, Dec 22, 2014 at 5:35 PM, Herbert Xu 
<herbert@gondor.apana.org.au> wrote:
> On Mon, Dec 22, 2014 at 04:18:33PM +0800, Jason Wang wrote:
>> 
>>  btw, looks like at least caif_virtio has the same issue.
> 
> Good catch.
> 
> -- >8 --
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) breaks caif.
> 
> It is now required that if the entire budget is consumed when poll
> returns, the napi poll_list must remain empty.  However, like some
> other drivers caif tries to do a last-ditch check and if there is
> more work it will call napi_schedule and then immediately process
> some of this new work.  Should the entire budget be consumed while
> processing such new work then we will violate the new caller
> contract.
> 
> This patch fixes this by not touching any work when we reschedule
> in caif.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Acked-by: Jason Wang <jasowang@redhat.com>

Thanks.
> 
> 
> diff --git a/drivers/net/caif/caif_virtio.c 
> b/drivers/net/caif/caif_virtio.c
> index a5fefb9..b306210 100644
> --- a/drivers/net/caif/caif_virtio.c
> +++ b/drivers/net/caif/caif_virtio.c
> @@ -257,7 +257,6 @@ static int cfv_rx_poll(struct napi_struct *napi, 
> int quota)
>  	struct vringh_kiov *riov = &cfv->ctx.riov;
>  	unsigned int skb_len;
>  
> -again:
>  	do {
>  		skb = NULL;
>  
> @@ -322,7 +321,6 @@ exit:
>  		    napi_schedule_prep(napi)) {
>  			vringh_notify_disable_kern(cfv->vr_rx);
>  			__napi_schedule(napi);
> -			goto again;
>  		}
>  		break;
> 
> Thanks,
> -- 
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 08:56:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 08: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 1Y3LGE-0004A7-92; Tue, 23 Dec 2014 08:56:10 +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 1Y3LGC-00049i-Aj
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 08:56:08 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	1C/86-09842-72E29945; Tue, 23 Dec 2014 08:56:07 +0000
X-Env-Sender: jasowang@redhat.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1419324965!10101174!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.1 required=7.0 tests=ratty_date: unknown 
	timezone in: Mon, 22 Dec 2014 10:10:01 +0008,ratty_date: unknown 
	timezone in: Mon, 22 Dec 2014 10:10:01 +0008,sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25491 invoked from network); 23 Dec 2014 08:56:07 -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; 23 Dec 2014 08:56:07 -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 sBN8tutR016761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 23 Dec 2014 03:55:56 -0500
Received: from [10.66.71.84] (dhcp-66-71-84.eng.nay.redhat.com [10.66.71.84]
	(may be forged))
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBN8tj3h028187; Tue, 23 Dec 2014 03:55:48 -0500
Date: Mon, 22 Dec 2014 10:10:01 +0008
From: Jason Wang <jasowang@redhat.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Message-Id: <1419242521.4592.0@smtp.corp.redhat.com>
In-Reply-To: <20141222093525.GA18616@gondor.apana.org.au>
References: <20141220002327.GA31975@gondor.apana.org.au>
	<5497D3D9.2070509@redhat.com>
	<20141222093525.GA18616@gondor.apana.org.au>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: netdev@vger.kernel.org, edumazet@google.com,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] caif: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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, Dec 22, 2014 at 5:35 PM, Herbert Xu 
<herbert@gondor.apana.org.au> wrote:
> On Mon, Dec 22, 2014 at 04:18:33PM +0800, Jason Wang wrote:
>> 
>>  btw, looks like at least caif_virtio has the same issue.
> 
> Good catch.
> 
> -- >8 --
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) breaks caif.
> 
> It is now required that if the entire budget is consumed when poll
> returns, the napi poll_list must remain empty.  However, like some
> other drivers caif tries to do a last-ditch check and if there is
> more work it will call napi_schedule and then immediately process
> some of this new work.  Should the entire budget be consumed while
> processing such new work then we will violate the new caller
> contract.
> 
> This patch fixes this by not touching any work when we reschedule
> in caif.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Acked-by: Jason Wang <jasowang@redhat.com>

Thanks.
> 
> 
> diff --git a/drivers/net/caif/caif_virtio.c 
> b/drivers/net/caif/caif_virtio.c
> index a5fefb9..b306210 100644
> --- a/drivers/net/caif/caif_virtio.c
> +++ b/drivers/net/caif/caif_virtio.c
> @@ -257,7 +257,6 @@ static int cfv_rx_poll(struct napi_struct *napi, 
> int quota)
>  	struct vringh_kiov *riov = &cfv->ctx.riov;
>  	unsigned int skb_len;
>  
> -again:
>  	do {
>  		skb = NULL;
>  
> @@ -322,7 +321,6 @@ exit:
>  		    napi_schedule_prep(napi)) {
>  			vringh_notify_disable_kern(cfv->vr_rx);
>  			__napi_schedule(napi);
> -			goto again;
>  		}
>  		break;
> 
> Thanks,
> -- 
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 10:29:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 10:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Mhx-0006vq-Ib; Tue, 23 Dec 2014 10:28:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Y3Mhw-0006vl-T8
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 10:28:53 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	0D/B8-08051-4E349945; Tue, 23 Dec 2014 10:28:52 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1419330529!16784943!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 7218 invoked from network); 23 Dec 2014 10:28:50 -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 Dec 2014 10:28:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,631,1413244800"; d="scan'208";a="207327168"
Message-ID: <549943CA.3010108@citrix.com>
Date: Tue, 23 Dec 2014 10:28:26 +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: Andy Lutomirski <luto@amacapital.net>, Paolo Bonzini
	<pbonzini@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>
References: <cover.1419295081.git.luto@amacapital.net>
	<8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
In-Reply-To: <8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
X-DLP: MIA2
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>
Subject: Re: [Xen-devel] [RFC 2/2] x86, vdso,
 pvclock: Simplify and speed up the vdso pvclock reader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 00:39, Andy Lutomirski wrote:
> The pvclock vdso code was too abstracted to understand easily and
> excessively paranoid.  Simplify it for a huge speedup.
> 
> This opens the door for additional simplifications, as the vdso no
> longer accesses the pvti for any vcpu other than vcpu 0.
> 
> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
> With this change, it takes 19ns, which is almost as fast as the pure TSC
> implementation.

This sounds plausible but I'm not going to be able to give it a detailed
look until the new year.

David

> --- a/arch/x86/vdso/vclock_gettime.c
> +++ b/arch/x86/vdso/vclock_gettime.c
> @@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
>  
>  static notrace cycle_t vread_pvclock(int *mode)
>  {
> -	const struct pvclock_vsyscall_time_info *pvti;
> +	const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>  	cycle_t ret;
> -	u64 last;
> -	u32 version;
> -	u8 flags;
> -	unsigned cpu, cpu1;
> -
> +	u64 tsc, pvti_tsc;
> +	u64 last, delta, pvti_system_time;
> +	u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>  
>  	/*
> -	 * Note: hypervisor must guarantee that:
> -	 * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
> -	 * 2. that per-CPU pvclock time info is updated if the
> -	 *    underlying CPU changes.
> -	 * 3. that version is increased whenever underlying CPU
> -	 *    changes.
> +	 * Note: The kernel and hypervisor must guarantee that cpu ID
> +	 * number maps 1:1 to per-CPU pvclock time info.
> +	 *
> +	 * Because the hypervisor is entirely unaware of guest userspace
> +	 * preemption, it cannot guarantee that per-CPU pvclock time
> +	 * info is updated if the underlying CPU changes or that that
> +	 * version is increased whenever underlying CPU changes.
> +	 *
> +	 * On KVM, we are guaranteed that pvti updates for any vCPU are
> +	 * atomic as seen by *all* vCPUs.  This is an even stronger
> +	 * guarantee than we get with a normal seqlock.
>  	 *
> +	 * On Xen, we don't appear to have that guarantee, but Xen still
> +	 * supplies a valid seqlock using the version field.
> +
> +	 * We only do pvclock vdso timing at all if
> +	 * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
> +	 * mean that all vCPUs have matching pvti and that the TSC is
> +	 * synced, so we can just look at vCPU 0's pvti.
>  	 */
> -	do {
> -		cpu = __getcpu() & VGETCPU_CPU_MASK;
> -		/* TODO: We can put vcpu id into higher bits of pvti.version.
> -		 * This will save a couple of cycles by getting rid of
> -		 * __getcpu() calls (Gleb).
> -		 */
> -
> -		pvti = get_pvti(cpu);
> -
> -		version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
> -
> -		/*
> -		 * Test we're still on the cpu as well as the version.
> -		 * We could have been migrated just after the first
> -		 * vgetcpu but before fetching the version, so we
> -		 * wouldn't notice a version change.
> -		 */
> -		cpu1 = __getcpu() & VGETCPU_CPU_MASK;
> -	} while (unlikely(cpu != cpu1 ||
> -			  (pvti->pvti.version & 1) ||
> -			  pvti->pvti.version != version));
> -
> -	if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
> +
> +	if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>  		*mode = VCLOCK_NONE;
> +		return 0;
> +	}
> +
> +	do {
> +		version = pvti->version;
> +
> +		/* This is also a read barrier, so we'll read version first. */
> +		rdtsc_barrier();
> +		tsc = __native_read_tsc();
> +
> +		pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
> +		pvti_tsc_shift = pvti->tsc_shift;
> +		pvti_system_time = pvti->system_time;
> +		pvti_tsc = pvti->tsc_timestamp;
> +
> +		/* Make sure that the version double-check is last. */
> +		smp_rmb();
> +	} while (unlikely((version & 1) || version != pvti->version));
> +
> +	delta = tsc - pvti_tsc;
> +	ret = pvti_system_time +
> +		pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
> +				    pvti_tsc_shift);
>  
>  	/* refer to tsc.c read_tsc() comment for rationale */
>  	last = gtod->cycle_last;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 10:29:14 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 10:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Mhx-0006vq-Ib; Tue, 23 Dec 2014 10:28:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Y3Mhw-0006vl-T8
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 10:28:53 +0000
Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id
	0D/B8-08051-4E349945; Tue, 23 Dec 2014 10:28:52 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1419330529!16784943!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 7218 invoked from network); 23 Dec 2014 10:28:50 -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 Dec 2014 10:28:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,631,1413244800"; d="scan'208";a="207327168"
Message-ID: <549943CA.3010108@citrix.com>
Date: Tue, 23 Dec 2014 10:28:26 +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: Andy Lutomirski <luto@amacapital.net>, Paolo Bonzini
	<pbonzini@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>
References: <cover.1419295081.git.luto@amacapital.net>
	<8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
In-Reply-To: <8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
X-DLP: MIA2
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>
Subject: Re: [Xen-devel] [RFC 2/2] x86, vdso,
 pvclock: Simplify and speed up the vdso pvclock reader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 00:39, Andy Lutomirski wrote:
> The pvclock vdso code was too abstracted to understand easily and
> excessively paranoid.  Simplify it for a huge speedup.
> 
> This opens the door for additional simplifications, as the vdso no
> longer accesses the pvti for any vcpu other than vcpu 0.
> 
> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
> With this change, it takes 19ns, which is almost as fast as the pure TSC
> implementation.

This sounds plausible but I'm not going to be able to give it a detailed
look until the new year.

David

> --- a/arch/x86/vdso/vclock_gettime.c
> +++ b/arch/x86/vdso/vclock_gettime.c
> @@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
>  
>  static notrace cycle_t vread_pvclock(int *mode)
>  {
> -	const struct pvclock_vsyscall_time_info *pvti;
> +	const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>  	cycle_t ret;
> -	u64 last;
> -	u32 version;
> -	u8 flags;
> -	unsigned cpu, cpu1;
> -
> +	u64 tsc, pvti_tsc;
> +	u64 last, delta, pvti_system_time;
> +	u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>  
>  	/*
> -	 * Note: hypervisor must guarantee that:
> -	 * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
> -	 * 2. that per-CPU pvclock time info is updated if the
> -	 *    underlying CPU changes.
> -	 * 3. that version is increased whenever underlying CPU
> -	 *    changes.
> +	 * Note: The kernel and hypervisor must guarantee that cpu ID
> +	 * number maps 1:1 to per-CPU pvclock time info.
> +	 *
> +	 * Because the hypervisor is entirely unaware of guest userspace
> +	 * preemption, it cannot guarantee that per-CPU pvclock time
> +	 * info is updated if the underlying CPU changes or that that
> +	 * version is increased whenever underlying CPU changes.
> +	 *
> +	 * On KVM, we are guaranteed that pvti updates for any vCPU are
> +	 * atomic as seen by *all* vCPUs.  This is an even stronger
> +	 * guarantee than we get with a normal seqlock.
>  	 *
> +	 * On Xen, we don't appear to have that guarantee, but Xen still
> +	 * supplies a valid seqlock using the version field.
> +
> +	 * We only do pvclock vdso timing at all if
> +	 * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
> +	 * mean that all vCPUs have matching pvti and that the TSC is
> +	 * synced, so we can just look at vCPU 0's pvti.
>  	 */
> -	do {
> -		cpu = __getcpu() & VGETCPU_CPU_MASK;
> -		/* TODO: We can put vcpu id into higher bits of pvti.version.
> -		 * This will save a couple of cycles by getting rid of
> -		 * __getcpu() calls (Gleb).
> -		 */
> -
> -		pvti = get_pvti(cpu);
> -
> -		version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
> -
> -		/*
> -		 * Test we're still on the cpu as well as the version.
> -		 * We could have been migrated just after the first
> -		 * vgetcpu but before fetching the version, so we
> -		 * wouldn't notice a version change.
> -		 */
> -		cpu1 = __getcpu() & VGETCPU_CPU_MASK;
> -	} while (unlikely(cpu != cpu1 ||
> -			  (pvti->pvti.version & 1) ||
> -			  pvti->pvti.version != version));
> -
> -	if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
> +
> +	if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>  		*mode = VCLOCK_NONE;
> +		return 0;
> +	}
> +
> +	do {
> +		version = pvti->version;
> +
> +		/* This is also a read barrier, so we'll read version first. */
> +		rdtsc_barrier();
> +		tsc = __native_read_tsc();
> +
> +		pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
> +		pvti_tsc_shift = pvti->tsc_shift;
> +		pvti_system_time = pvti->system_time;
> +		pvti_tsc = pvti->tsc_timestamp;
> +
> +		/* Make sure that the version double-check is last. */
> +		smp_rmb();
> +	} while (unlikely((version & 1) || version != pvti->version));
> +
> +	delta = tsc - pvti_tsc;
> +	ret = pvti_system_time +
> +		pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
> +				    pvti_tsc_shift);
>  
>  	/* refer to tsc.c read_tsc() comment for rationale */
>  	last = gtod->cycle_last;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 10:35:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 10:35:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Mnz-0007J4-Jd; Tue, 23 Dec 2014 10:35:07 +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 1Y3Mny-0007Iz-2P
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 10:35:06 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	0F/B3-14214-95549945; Tue, 23 Dec 2014 10:35:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1419330901!14858896!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9059 invoked from network); 23 Dec 2014 10:35:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 10:35:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,631,1413244800"; d="scan'208";a="207328384"
Message-ID: <54994553.6070401@citrix.com>
Date: Tue, 23 Dec 2014 10:34:59 +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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, <david.vrabel@citrix.com>,
	<konrad.wilk@oracle.com>
References: <1419273190-18821-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1419273190-18821-1-git-send-email-boris.ostrovsky@oracle.com>
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/time: Remove unnecessary
 BUG_ON(preemptible()) in xen_setup_timer()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/12/14 18:33, Boris Ostrovsky wrote:
> There is no reason for having it and, with commit 250a1ac685f1 ("x86,
> smpboot: Remove pointless preempt_disable() in
> native_smp_prepare_cpus()"), it prevents HVM guests from booting.

Applied to stable/for-linus-3.19, thanks.

For arch-specific fixes I prefer the arch in the subject. e.g., "x86/xen:".

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 10:35:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 10:35:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Mnz-0007J4-Jd; Tue, 23 Dec 2014 10:35:07 +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 1Y3Mny-0007Iz-2P
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 10:35:06 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	0F/B3-14214-95549945; Tue, 23 Dec 2014 10:35:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1419330901!14858896!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 9059 invoked from network); 23 Dec 2014 10:35:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 10:35:03 -0000
X-IronPort-AV: E=Sophos;i="5.07,631,1413244800"; d="scan'208";a="207328384"
Message-ID: <54994553.6070401@citrix.com>
Date: Tue, 23 Dec 2014 10:34:59 +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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, <david.vrabel@citrix.com>,
	<konrad.wilk@oracle.com>
References: <1419273190-18821-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1419273190-18821-1-git-send-email-boris.ostrovsky@oracle.com>
X-DLP: MIA1
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/time: Remove unnecessary
 BUG_ON(preemptible()) in xen_setup_timer()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/12/14 18:33, Boris Ostrovsky wrote:
> There is no reason for having it and, with commit 250a1ac685f1 ("x86,
> smpboot: Remove pointless preempt_disable() in
> native_smp_prepare_cpus()"), it prevents HVM guests from booting.

Applied to stable/for-linus-3.19, thanks.

For arch-specific fixes I prefer the arch in the subject. e.g., "x86/xen:".

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 10:52:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 10: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 1Y3N41-0007eI-6x; Tue, 23 Dec 2014 10:51:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <upanshu.singhal@emc.com>) id 1Y3N3y-0007eD-L7
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 10:51:39 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	30/24-27785-A3949945; Tue, 23 Dec 2014 10:51:38 +0000
X-Env-Sender: upanshu.singhal@emc.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1419331895!12182817!1
X-Originating-IP: [128.221.224.79]
X-SpamReason: No, hits=1.8 required=7.0 tests=BODY_RANDOM_LONG,HOT_NASTY,
	HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17963 invoked from network); 23 Dec 2014 10:51:36 -0000
Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2014 10:51:36 -0000
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com
	[10.106.48.156])
	by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBNApXmm019168
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Dec 2014 05:51:34 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sBNApXmm019168
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013;
	t=1419331894; bh=AknpYgqOc8Se7UsqpZ6S22z7jFY=;
	h=From:To:CC:Subject:Date:Message-ID:References:Content-Type:
	MIME-Version;
	b=J6s+KsmWuPHHMDhnf/t1ISk+DQLRIYSPvK+e/L8RdKdXsmcExeNaqas83xpiwKODP
	dvWS0xalMeR/LgqjIdL6n+r2lnlshru5nh8jJCwvzI3Ufk1iS6kn8ODB/pYgi7ZZYn
	OfgkRBKxcJUJNzkMtSr4DsWqXcmakUVNJbQO0yL8=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sBNApXmm019168
Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com
	[10.106.48.19]) by maildlpprd52.lss.emc.com (RSA Interceptor);
	Tue, 23 Dec 2014 05:51:25 -0500
Received: from mxhub37.corp.emc.com (mxhub37.corp.emc.com [128.222.70.104])
	by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBNApEAX019243
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 23 Dec 2014 05:51:14 -0500
Received: from MXHUB202.corp.emc.com (10.253.68.28) by mxhub37.corp.emc.com
	(128.222.70.104) with Microsoft SMTP Server (TLS) id 8.3.327.1;
	Tue, 23 Dec 2014 05:51:14 -0500
Received: from MX101CL01.corp.emc.com ([169.254.1.90]) by
	MXHUB202.corp.emc.com ([10.253.68.28]) with mapi id 14.03.0195.001;
	Tue, 23 Dec 2014 05:51:13 -0500
From: "Singhal, Upanshu" <upanshu.singhal@emc.com>
To: Don Slutz <dslutz@verizon.com>
Thread-Topic: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
Thread-Index: AdAbg+gVpGg69F+/TKC4f+QiMDYySwAgTHmAAGwE/hAAOkKz8A==
Date: Tue, 23 Dec 2014 10:51:12 +0000
Message-ID: <6A5D14D0DFEABC43BE832A0E492963F14EBB9C30@MX101CL01.corp.emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
	<5494A6AF.1030802@terremark.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.30.79.65]
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com
X-RSA-Classifications: DLP to NYP, DLM_1, public
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2260311917361954933=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2260311917361954933==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_6A5D14D0DFEABC43BE832A0E492963F14EBB9C30MX101CL01corpem_"

--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB9C30MX101CL01corpem_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Don,

I am not trying to configure VMW PVSCSI type of device but not able to do s=
o. Though, PVSCSI is available on the distribution I am using. Any inputs o=
n how to configure PVSCSI type disk device?

Thanks,
-Upanshu

From: Singhal, Upanshu
Sent: Monday, December 22, 2014 12:35 PM
To: 'Don Slutz'
Cc: 'xen-devel@lists.xen.org'
Subject: RE: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

Hello Don,

xen_emul_unplug=3Dunnecessary  does the trick, I am able to see the vmxnet3=
 driver using lspci and ethtool -I eth0. Thanks a lot for your help, much a=
ppreciated.

Performance between vmxnet3 running on XEN is about 1/3 of vmxnet3 running =
on ESXi. Similar performance number I get between vmxnet3 on ESXi and vif o=
n XEN. Do you know what could be the reason for this?

Thanks,
-Upanshu

From: Don Slutz [mailto:dslutz@verizon.com]
Sent: Saturday, December 20, 2014 3:59 AM
To: Singhal, Upanshu
Cc: xen-devel@lists.xen.org<mailto:xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

xen_emul_unplug=3Dunnecessary (kernel arg) may help you here.

Also udev likes to rename your devices.

Here is a lspci from a guest:


[root@C63-min-tools ~]# 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 I=
I]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 0=
1)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)
00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)

And to help:

[root@C63-min-tools ~]# ls -l /sys/class/net/*/device
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> ../../=
../vif-0
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> ../../=
../vif-1
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> ../../=
../vif-2
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> ../../=
../vif-3
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> ../../=
../vif-4
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> ../../=
../vif-5
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> ../../=
../vif-6
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> ../../=
../vif-7
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> ../../=
../vif-8
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> ../../=
../vif-9
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device -> ..=
/../../0000:00:04.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device -> ..=
/../../0000:00:05.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device -> ..=
/../../0000:00:06.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device -> ..=
/../../0000:00:07.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device -> ..=
/../../0000:00:08.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device -> ..=
/../../0000:00:09.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device -> ..=
/../../0000:00:0a.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device -> ..=
/../../0000:00:0b.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device -> ..=
/../../0000:00:0c.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device -> ..=
/../../0000:00:0d.0


   -Don Slutz
On 12/19/14 07:04, Singhal, Upanshu wrote:
Hello,

In one of my experiment, I am building a Linux VM with Network interface mo=
del as "vmxnet3". I am able to create the VM successfully, but I see that t=
he driver loaded is "vif" and not "vmxnet3". I am using the following optio=
n for the network interface: vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:=
22, bridge=3Dxenbr0, model=3Dvmxnet3' ]

I tried with model as e1000 and it works fine. Lspci command also does not =
show vmxnet3. Though, qemu device help shows that "vmxnet3" is supported on=
 XEN 4.4.1 version I am using.

I tried searching on internet about the right configuration for vmxnet3 wit=
h XEN, but not able to find right information. Can someone please help me o=
n how to create a VM with vmxnet3?

This experiment I am doing to compare the difference between vmxnet3 bandwi=
dth on VMWARE ESXi vs. XEN Server. My sample VM configuration file is:

# This configures an HVM rather than PV guest
builder =3D "hvm"

# Guest name
name =3D "rhel-vmxnet3-xen-2.hvm"

# 128-bit UUID for the domain as a hexadecimal number.
# Use "uuidgen" to generate one if required.
# The default behavior is to generate a new UUID each time the guest is sta=
rted.
#uuid =3D "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

# Enable Microsoft Hyper-V compatibile paravirtualisation /
# enlightenment interfaces. Turning this on can improve Windows guest
# performance and is therefore recommended
#viridian =3D 1

# Initial memory allocation (MB)
memory =3D 8192

# Maximum memory (MB)
# If this is greater than `memory' then the slack will start ballooned
# (this assumes guest kernel support for ballooning)
#maxmem =3D 512

# Number of VCPUS
vcpus =3D 8

# Network devices
# A list of 'vifspec' entries as described in
# docs/misc/xl-network-configuration.markdown
vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dxenbr1, model=3D=
vmxnet3' ]

# Disk Devices
# A list of `diskspec' entries as described in
# docs/misc/xl-disk-configuration.txt
disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', 'file:/root=
/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r<file:///\\root\rhel-server-6.4-=
x86_64-dvd.iso,hdc:cdrom,r>' ]
boot=3D'cd'

# Guest VGA console configuration, either SDL or VNC
# sdl =3D 1
vnc =3D 2

Thanks,
-Upanshu


Upanshu Singhal
EMC Data Storage Systems, Bangalore, India.
Phone: 91-80-67375604




_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xen.org<mailto:Xen-devel@lists.xen.org>

http://lists.xen.org/xen-devel


--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB9C30MX101CL01corpem_
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:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";
	color:black;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@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 bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hello Don,<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I am not trying to con=
figure VMW PVSCSI type of device but not able to do so. Though, PVSCSI is a=
vailable on the distribution I am using. Any inputs on how to configure PVS=
CSI type disk device?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">-Upanshu<o:p></o:p></s=
pan></p>
</div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext"> Singhal, Upanshu
<br>
<b>Sent:</b> Monday, December 22, 2014 12:35 PM<br>
<b>To:</b> 'Don Slutz'<br>
<b>Cc:</b> 'xen-devel@lists.xen.org'<br>
<b>Subject:</b> RE: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1<o:p></=
o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hello Don,<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal">xen_emul_unplug=3Dunnecessary<span style=3D"color:#1=
F497D"> &nbsp;does the trick, I am able to see the vmxnet3 driver using lsp=
ci and ethtool &#8211;I eth0. Thanks a lot for your help, much appreciated.=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Performance between vm=
xnet3 running on XEN is about 1/3 of vmxnet3 running on ESXi. Similar perfo=
rmance number I get between vmxnet3 on ESXi and vif on XEN. Do you know wha=
t could be the reason for this?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">-Upanshu<o:p></o:p></s=
pan></p>
</div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext"> Don Slutz [<a href=3D"mailto:dslutz@verizon.com">=
mailto:dslutz@verizon.com</a>]
<br>
<b>Sent:</b> Saturday, December 20, 2014 3:59 AM<br>
<b>To:</b> Singhal, Upanshu<br>
<b>Cc:</b> <a href=3D"mailto:xen-devel@lists.xen.org">xen-devel@lists.xen.o=
rg</a><br>
<b>Subject:</b> Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1<o:p></=
o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">xen_emul_unplug=3Dunn=
ecessary (kernel arg) may help you here.<br>
<br>
Also udev likes to rename your devices.<br>
<br>
Here is a lspci from a guest:<br>
<br>
<br>
[root@C63-min-tools ~]# lspci<br>
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02=
)<br>
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]<=
br>
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton I=
I]<br>
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)<br>
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 0=
1)<br>
00:03.0 VGA compatible controller: Cirrus Logic GD 5446<br>
00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)<br>
00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)<br>
<br>
And to help:<br>
<br>
[root@C63-min-tools ~]# ls -l /sys/class/net/*/device<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -&gt; ../=
../../vif-0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -&gt; ../=
../../vif-1<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -&gt; ../=
../../vif-2<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -&gt; ../=
../../vif-3<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -&gt; ../=
../../vif-4<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -&gt; ../=
../../vif-5<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -&gt; ../=
../../vif-6<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -&gt; ../=
../../vif-7<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -&gt; ../=
../../vif-8<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -&gt; ../=
../../vif-9<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device -&gt;=
 ../../../0000:00:04.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device -&gt;=
 ../../../0000:00:05.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device -&gt;=
 ../../../0000:00:06.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device -&gt;=
 ../../../0000:00:07.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device -&gt;=
 ../../../0000:00:08.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device -&gt;=
 ../../../0000:00:09.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device -&gt;=
 ../../../0000:00:0a.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device -&gt;=
 ../../../0000:00:0b.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device -&gt;=
 ../../../0000:00:0c.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device -&gt;=
 ../../../0000:00:0d.0<br>
<br>
<br>
&nbsp;&nbsp; -Don Slutz<o:p></o:p></p>
<div>
<p class=3D"MsoNormal">On 12/19/14 07:04, Singhal, Upanshu wrote:<o:p></o:p=
></p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">Hello,<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">In one of my experiment, I am building a Linux VM wi=
th Network interface model as &#8220;vmxnet3&#8221;. I am able to create th=
e VM successfully, but I see that the driver loaded is &#8220;vif&#8221; an=
d not &#8220;vmxnet3&#8221;. I am using the following option for the networ=
k
 interface: <b>vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dx=
enbr0, model=3Dvmxnet3' ]</b><o:p></o:p></p>
<p class=3D"MsoNormal"><b>&nbsp;</b><o:p></o:p></p>
<p class=3D"MsoNormal">I tried with model as e1000 and it works fine. Lspci=
 command also does not show vmxnet3. Though, qemu device help shows that &#=
8220;vmxnet3&#8221; is supported on XEN 4.4.1 version I am using.
<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">I tried searching on internet about the right config=
uration for vmxnet3 with XEN, but not able to find right information. Can s=
omeone please help me on how to create a VM with vmxnet3?<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">This experiment I am doing to compare the difference=
 between vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM conf=
iguration file is:<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># This configures an HVM rather than PV guest<o:p></=
o:p></p>
<p class=3D"MsoNormal">builder =3D &quot;hvm&quot;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Guest name<o:p></o:p></p>
<p class=3D"MsoNormal"><b>name =3D &quot;rhel-vmxnet3-xen-2.hvm&quot;</b><o=
:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># 128-bit UUID for the domain as a hexadecimal numbe=
r.<o:p></o:p></p>
<p class=3D"MsoNormal"># Use &quot;uuidgen&quot; to generate one if require=
d.<o:p></o:p></p>
<p class=3D"MsoNormal"># The default behavior is to generate a new UUID eac=
h time the guest is started.<o:p></o:p></p>
<p class=3D"MsoNormal">#uuid =3D &quot;XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=
&quot;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Enable Microsoft Hyper-V compatibile paravirtualis=
ation /<o:p></o:p></p>
<p class=3D"MsoNormal"># enlightenment interfaces. Turning this on can impr=
ove Windows guest<o:p></o:p></p>
<p class=3D"MsoNormal"># performance and is therefore recommended<o:p></o:p=
></p>
<p class=3D"MsoNormal">#viridian =3D 1<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Initial memory allocation (MB)<o:p></o:p></p>
<p class=3D"MsoNormal"><b>memory =3D 8192</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Maximum memory (MB)<o:p></o:p></p>
<p class=3D"MsoNormal"># If this is greater than `memory' then the slack wi=
ll start ballooned<o:p></o:p></p>
<p class=3D"MsoNormal"># (this assumes guest kernel support for ballooning)=
<o:p></o:p></p>
<p class=3D"MsoNormal">#maxmem =3D 512<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Number of VCPUS<o:p></o:p></p>
<p class=3D"MsoNormal"><b>vcpus =3D 8</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Network devices<o:p></o:p></p>
<p class=3D"MsoNormal"># A list of 'vifspec' entries as described in<o:p></=
o:p></p>
<p class=3D"MsoNormal"># docs/misc/xl-network-configuration.markdown<o:p></=
o:p></p>
<p class=3D"MsoNormal">vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, br=
idge=3Dxenbr1, model=3Dvmxnet3' ]<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Disk Devices<o:p></o:p></p>
<p class=3D"MsoNormal"># A list of `diskspec' entries as described in<o:p><=
/o:p></p>
<p class=3D"MsoNormal"># docs/misc/xl-disk-configuration.txt<o:p></o:p></p>
<p class=3D"MsoNormal"><b>disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img=
,raw,xvda,rw', '<a href=3D"file:///\\root\rhel-server-6.4-x86_64-dvd.iso,hd=
c:cdrom,r">file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r</a>' ]</b>=
<o:p></o:p></p>
<p class=3D"MsoNormal"><b>boot=3D'cd'</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Guest VGA console configuration, either SDL or VNC=
<o:p></o:p></p>
<p class=3D"MsoNormal"># sdl =3D 1<o:p></o:p></p>
<p class=3D"MsoNormal"><b>vnc =3D 2</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal">-Upanshu<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">Upanshu Singhal<o:p></o:p></p>
<p class=3D"MsoNormal">EMC Data Storage Systems, Bangalore, India.<o:p></o:=
p></p>
<p class=3D"MsoNormal">Phone: 91-80-67375604<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=
ize:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;"><br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Xen-devel mailing list<o:p></o:p></pre>
<pre><a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<o:p></o:p></pre>
<pre><a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-de=
vel</a><o:p></o:p></pre>
</blockquote>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB9C30MX101CL01corpem_--


--===============2260311917361954933==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2260311917361954933==--


From xen-devel-bounces@lists.xen.org Tue Dec 23 10:52:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 10: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 1Y3N41-0007eI-6x; Tue, 23 Dec 2014 10:51:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <upanshu.singhal@emc.com>) id 1Y3N3y-0007eD-L7
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 10:51:39 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	30/24-27785-A3949945; Tue, 23 Dec 2014 10:51:38 +0000
X-Env-Sender: upanshu.singhal@emc.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1419331895!12182817!1
X-Originating-IP: [128.221.224.79]
X-SpamReason: No, hits=1.8 required=7.0 tests=BODY_RANDOM_LONG,HOT_NASTY,
	HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17963 invoked from network); 23 Dec 2014 10:51:36 -0000
Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Dec 2014 10:51:36 -0000
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com
	[10.106.48.156])
	by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBNApXmm019168
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Dec 2014 05:51:34 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sBNApXmm019168
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013;
	t=1419331894; bh=AknpYgqOc8Se7UsqpZ6S22z7jFY=;
	h=From:To:CC:Subject:Date:Message-ID:References:Content-Type:
	MIME-Version;
	b=J6s+KsmWuPHHMDhnf/t1ISk+DQLRIYSPvK+e/L8RdKdXsmcExeNaqas83xpiwKODP
	dvWS0xalMeR/LgqjIdL6n+r2lnlshru5nh8jJCwvzI3Ufk1iS6kn8ODB/pYgi7ZZYn
	OfgkRBKxcJUJNzkMtSr4DsWqXcmakUVNJbQO0yL8=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sBNApXmm019168
Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com
	[10.106.48.19]) by maildlpprd52.lss.emc.com (RSA Interceptor);
	Tue, 23 Dec 2014 05:51:25 -0500
Received: from mxhub37.corp.emc.com (mxhub37.corp.emc.com [128.222.70.104])
	by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBNApEAX019243
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 23 Dec 2014 05:51:14 -0500
Received: from MXHUB202.corp.emc.com (10.253.68.28) by mxhub37.corp.emc.com
	(128.222.70.104) with Microsoft SMTP Server (TLS) id 8.3.327.1;
	Tue, 23 Dec 2014 05:51:14 -0500
Received: from MX101CL01.corp.emc.com ([169.254.1.90]) by
	MXHUB202.corp.emc.com ([10.253.68.28]) with mapi id 14.03.0195.001;
	Tue, 23 Dec 2014 05:51:13 -0500
From: "Singhal, Upanshu" <upanshu.singhal@emc.com>
To: Don Slutz <dslutz@verizon.com>
Thread-Topic: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
Thread-Index: AdAbg+gVpGg69F+/TKC4f+QiMDYySwAgTHmAAGwE/hAAOkKz8A==
Date: Tue, 23 Dec 2014 10:51:12 +0000
Message-ID: <6A5D14D0DFEABC43BE832A0E492963F14EBB9C30@MX101CL01.corp.emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
	<5494A6AF.1030802@terremark.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.30.79.65]
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com
X-RSA-Classifications: DLP to NYP, DLM_1, public
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2260311917361954933=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2260311917361954933==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_6A5D14D0DFEABC43BE832A0E492963F14EBB9C30MX101CL01corpem_"

--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB9C30MX101CL01corpem_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Don,

I am not trying to configure VMW PVSCSI type of device but not able to do s=
o. Though, PVSCSI is available on the distribution I am using. Any inputs o=
n how to configure PVSCSI type disk device?

Thanks,
-Upanshu

From: Singhal, Upanshu
Sent: Monday, December 22, 2014 12:35 PM
To: 'Don Slutz'
Cc: 'xen-devel@lists.xen.org'
Subject: RE: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

Hello Don,

xen_emul_unplug=3Dunnecessary  does the trick, I am able to see the vmxnet3=
 driver using lspci and ethtool -I eth0. Thanks a lot for your help, much a=
ppreciated.

Performance between vmxnet3 running on XEN is about 1/3 of vmxnet3 running =
on ESXi. Similar performance number I get between vmxnet3 on ESXi and vif o=
n XEN. Do you know what could be the reason for this?

Thanks,
-Upanshu

From: Don Slutz [mailto:dslutz@verizon.com]
Sent: Saturday, December 20, 2014 3:59 AM
To: Singhal, Upanshu
Cc: xen-devel@lists.xen.org<mailto:xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

xen_emul_unplug=3Dunnecessary (kernel arg) may help you here.

Also udev likes to rename your devices.

Here is a lspci from a guest:


[root@C63-min-tools ~]# 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 I=
I]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 0=
1)
00:03.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)
00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)

And to help:

[root@C63-min-tools ~]# ls -l /sys/class/net/*/device
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> ../../=
../vif-0
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> ../../=
../vif-1
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> ../../=
../vif-2
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> ../../=
../vif-3
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> ../../=
../vif-4
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> ../../=
../vif-5
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> ../../=
../vif-6
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> ../../=
../vif-7
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> ../../=
../vif-8
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> ../../=
../vif-9
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device -> ..=
/../../0000:00:04.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device -> ..=
/../../0000:00:05.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device -> ..=
/../../0000:00:06.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device -> ..=
/../../0000:00:07.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device -> ..=
/../../0000:00:08.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device -> ..=
/../../0000:00:09.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device -> ..=
/../../0000:00:0a.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device -> ..=
/../../0000:00:0b.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device -> ..=
/../../0000:00:0c.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device -> ..=
/../../0000:00:0d.0


   -Don Slutz
On 12/19/14 07:04, Singhal, Upanshu wrote:
Hello,

In one of my experiment, I am building a Linux VM with Network interface mo=
del as "vmxnet3". I am able to create the VM successfully, but I see that t=
he driver loaded is "vif" and not "vmxnet3". I am using the following optio=
n for the network interface: vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:=
22, bridge=3Dxenbr0, model=3Dvmxnet3' ]

I tried with model as e1000 and it works fine. Lspci command also does not =
show vmxnet3. Though, qemu device help shows that "vmxnet3" is supported on=
 XEN 4.4.1 version I am using.

I tried searching on internet about the right configuration for vmxnet3 wit=
h XEN, but not able to find right information. Can someone please help me o=
n how to create a VM with vmxnet3?

This experiment I am doing to compare the difference between vmxnet3 bandwi=
dth on VMWARE ESXi vs. XEN Server. My sample VM configuration file is:

# This configures an HVM rather than PV guest
builder =3D "hvm"

# Guest name
name =3D "rhel-vmxnet3-xen-2.hvm"

# 128-bit UUID for the domain as a hexadecimal number.
# Use "uuidgen" to generate one if required.
# The default behavior is to generate a new UUID each time the guest is sta=
rted.
#uuid =3D "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

# Enable Microsoft Hyper-V compatibile paravirtualisation /
# enlightenment interfaces. Turning this on can improve Windows guest
# performance and is therefore recommended
#viridian =3D 1

# Initial memory allocation (MB)
memory =3D 8192

# Maximum memory (MB)
# If this is greater than `memory' then the slack will start ballooned
# (this assumes guest kernel support for ballooning)
#maxmem =3D 512

# Number of VCPUS
vcpus =3D 8

# Network devices
# A list of 'vifspec' entries as described in
# docs/misc/xl-network-configuration.markdown
vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dxenbr1, model=3D=
vmxnet3' ]

# Disk Devices
# A list of `diskspec' entries as described in
# docs/misc/xl-disk-configuration.txt
disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', 'file:/root=
/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r<file:///\\root\rhel-server-6.4-=
x86_64-dvd.iso,hdc:cdrom,r>' ]
boot=3D'cd'

# Guest VGA console configuration, either SDL or VNC
# sdl =3D 1
vnc =3D 2

Thanks,
-Upanshu


Upanshu Singhal
EMC Data Storage Systems, Bangalore, India.
Phone: 91-80-67375604




_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xen.org<mailto:Xen-devel@lists.xen.org>

http://lists.xen.org/xen-devel


--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB9C30MX101CL01corpem_
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:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";
	color:black;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@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 bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hello Don,<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I am not trying to con=
figure VMW PVSCSI type of device but not able to do so. Though, PVSCSI is a=
vailable on the distribution I am using. Any inputs on how to configure PVS=
CSI type disk device?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">-Upanshu<o:p></o:p></s=
pan></p>
</div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext"> Singhal, Upanshu
<br>
<b>Sent:</b> Monday, December 22, 2014 12:35 PM<br>
<b>To:</b> 'Don Slutz'<br>
<b>Cc:</b> 'xen-devel@lists.xen.org'<br>
<b>Subject:</b> RE: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1<o:p></=
o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hello Don,<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal">xen_emul_unplug=3Dunnecessary<span style=3D"color:#1=
F497D"> &nbsp;does the trick, I am able to see the vmxnet3 driver using lsp=
ci and ethtool &#8211;I eth0. Thanks a lot for your help, much appreciated.=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Performance between vm=
xnet3 running on XEN is about 1/3 of vmxnet3 running on ESXi. Similar perfo=
rmance number I get between vmxnet3 on ESXi and vif on XEN. Do you know wha=
t could be the reason for this?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">-Upanshu<o:p></o:p></s=
pan></p>
</div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext"> Don Slutz [<a href=3D"mailto:dslutz@verizon.com">=
mailto:dslutz@verizon.com</a>]
<br>
<b>Sent:</b> Saturday, December 20, 2014 3:59 AM<br>
<b>To:</b> Singhal, Upanshu<br>
<b>Cc:</b> <a href=3D"mailto:xen-devel@lists.xen.org">xen-devel@lists.xen.o=
rg</a><br>
<b>Subject:</b> Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1<o:p></=
o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">xen_emul_unplug=3Dunn=
ecessary (kernel arg) may help you here.<br>
<br>
Also udev likes to rename your devices.<br>
<br>
Here is a lspci from a guest:<br>
<br>
<br>
[root@C63-min-tools ~]# lspci<br>
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02=
)<br>
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]<=
br>
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton I=
I]<br>
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)<br>
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 0=
1)<br>
00:03.0 VGA compatible controller: Cirrus Logic GD 5446<br>
00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)<br>
00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)<br=
>
00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Con=
troller (rev 03)<br>
<br>
And to help:<br>
<br>
[root@C63-min-tools ~]# ls -l /sys/class/net/*/device<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -&gt; ../=
../../vif-0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -&gt; ../=
../../vif-1<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -&gt; ../=
../../vif-2<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -&gt; ../=
../../vif-3<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -&gt; ../=
../../vif-4<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -&gt; ../=
../../vif-5<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -&gt; ../=
../../vif-6<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -&gt; ../=
../../vif-7<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -&gt; ../=
../../vif-8<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -&gt; ../=
../../vif-9<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device -&gt;=
 ../../../0000:00:04.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device -&gt;=
 ../../../0000:00:05.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device -&gt;=
 ../../../0000:00:06.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device -&gt;=
 ../../../0000:00:07.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device -&gt;=
 ../../../0000:00:08.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device -&gt;=
 ../../../0000:00:09.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device -&gt;=
 ../../../0000:00:0a.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device -&gt;=
 ../../../0000:00:0b.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device -&gt;=
 ../../../0000:00:0c.0<br>
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device -&gt;=
 ../../../0000:00:0d.0<br>
<br>
<br>
&nbsp;&nbsp; -Don Slutz<o:p></o:p></p>
<div>
<p class=3D"MsoNormal">On 12/19/14 07:04, Singhal, Upanshu wrote:<o:p></o:p=
></p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">Hello,<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">In one of my experiment, I am building a Linux VM wi=
th Network interface model as &#8220;vmxnet3&#8221;. I am able to create th=
e VM successfully, but I see that the driver loaded is &#8220;vif&#8221; an=
d not &#8220;vmxnet3&#8221;. I am using the following option for the networ=
k
 interface: <b>vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dx=
enbr0, model=3Dvmxnet3' ]</b><o:p></o:p></p>
<p class=3D"MsoNormal"><b>&nbsp;</b><o:p></o:p></p>
<p class=3D"MsoNormal">I tried with model as e1000 and it works fine. Lspci=
 command also does not show vmxnet3. Though, qemu device help shows that &#=
8220;vmxnet3&#8221; is supported on XEN 4.4.1 version I am using.
<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">I tried searching on internet about the right config=
uration for vmxnet3 with XEN, but not able to find right information. Can s=
omeone please help me on how to create a VM with vmxnet3?<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">This experiment I am doing to compare the difference=
 between vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM conf=
iguration file is:<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># This configures an HVM rather than PV guest<o:p></=
o:p></p>
<p class=3D"MsoNormal">builder =3D &quot;hvm&quot;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Guest name<o:p></o:p></p>
<p class=3D"MsoNormal"><b>name =3D &quot;rhel-vmxnet3-xen-2.hvm&quot;</b><o=
:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># 128-bit UUID for the domain as a hexadecimal numbe=
r.<o:p></o:p></p>
<p class=3D"MsoNormal"># Use &quot;uuidgen&quot; to generate one if require=
d.<o:p></o:p></p>
<p class=3D"MsoNormal"># The default behavior is to generate a new UUID eac=
h time the guest is started.<o:p></o:p></p>
<p class=3D"MsoNormal">#uuid =3D &quot;XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=
&quot;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Enable Microsoft Hyper-V compatibile paravirtualis=
ation /<o:p></o:p></p>
<p class=3D"MsoNormal"># enlightenment interfaces. Turning this on can impr=
ove Windows guest<o:p></o:p></p>
<p class=3D"MsoNormal"># performance and is therefore recommended<o:p></o:p=
></p>
<p class=3D"MsoNormal">#viridian =3D 1<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Initial memory allocation (MB)<o:p></o:p></p>
<p class=3D"MsoNormal"><b>memory =3D 8192</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Maximum memory (MB)<o:p></o:p></p>
<p class=3D"MsoNormal"># If this is greater than `memory' then the slack wi=
ll start ballooned<o:p></o:p></p>
<p class=3D"MsoNormal"># (this assumes guest kernel support for ballooning)=
<o:p></o:p></p>
<p class=3D"MsoNormal">#maxmem =3D 512<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Number of VCPUS<o:p></o:p></p>
<p class=3D"MsoNormal"><b>vcpus =3D 8</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Network devices<o:p></o:p></p>
<p class=3D"MsoNormal"># A list of 'vifspec' entries as described in<o:p></=
o:p></p>
<p class=3D"MsoNormal"># docs/misc/xl-network-configuration.markdown<o:p></=
o:p></p>
<p class=3D"MsoNormal">vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, br=
idge=3Dxenbr1, model=3Dvmxnet3' ]<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Disk Devices<o:p></o:p></p>
<p class=3D"MsoNormal"># A list of `diskspec' entries as described in<o:p><=
/o:p></p>
<p class=3D"MsoNormal"># docs/misc/xl-disk-configuration.txt<o:p></o:p></p>
<p class=3D"MsoNormal"><b>disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img=
,raw,xvda,rw', '<a href=3D"file:///\\root\rhel-server-6.4-x86_64-dvd.iso,hd=
c:cdrom,r">file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r</a>' ]</b>=
<o:p></o:p></p>
<p class=3D"MsoNormal"><b>boot=3D'cd'</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"># Guest VGA console configuration, either SDL or VNC=
<o:p></o:p></p>
<p class=3D"MsoNormal"># sdl =3D 1<o:p></o:p></p>
<p class=3D"MsoNormal"><b>vnc =3D 2</b><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal">-Upanshu<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">Upanshu Singhal<o:p></o:p></p>
<p class=3D"MsoNormal">EMC Data Storage Systems, Bangalore, India.<o:p></o:=
p></p>
<p class=3D"MsoNormal">Phone: 91-80-67375604<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=
ize:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;"><br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Xen-devel mailing list<o:p></o:p></pre>
<pre><a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<o:p></o:p></pre>
<pre><a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-de=
vel</a><o:p></o:p></pre>
</blockquote>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_6A5D14D0DFEABC43BE832A0E492963F14EBB9C30MX101CL01corpem_--


--===============2260311917361954933==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2260311917361954933==--


From xen-devel-bounces@lists.xen.org Tue Dec 23 11:01:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 11: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 1Y3NDN-00080q-Bi; Tue, 23 Dec 2014 11:01: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 1Y3NDM-00080l-FY
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 11:01:20 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	71/7E-16982-F7B49945; Tue, 23 Dec 2014 11:01:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1419332477!15394675!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 15934 invoked from network); 23 Dec 2014 11:01:18 -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;
	23 Dec 2014 11:01:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,631,1413244800"; d="scan'208";a="207333193"
Message-ID: <54994B7B.20309@citrix.com>
Date: Tue, 23 Dec 2014 11:01:15 +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>, David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
References: <54945D760200007800051157@mail.emea.novell.com>
In-Reply-To: <54945D760200007800051157@mail.emea.novell.com>
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] xen/x86: properly retrieve NMI reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 16:16, Jan Beulich wrote:
> Using the native code here can't work properly, as the hypervisor would
> normally have cleared the two reason bits by the time Dom0 gets to see
> the NMI (if passed to it at all). There's a shared info field for this,
> and there's an existing hook to use - just fit the two together. Note
> that the hook can (and should) be used irrespective of whether being in
> Dom0, as accessing port 0x61 in a DomU would be even worse, while the
> shared info field would just hold zero all the time.

What's the user visible impact of this fix?

David

> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
>  arch/x86/xen/enlighten.c    |   22 +++++++++++++++++-
>  include/xen/interface/nmi.h |   52 ++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 73 insertions(+), 1 deletion(-)
> 
> --- 3.18/arch/x86/xen/enlighten.c
> +++ 3.18-xen-x86-NMI-reason/arch/x86/xen/enlighten.c
> @@ -40,6 +40,7 @@
>  #include <xen/interface/physdev.h>
>  #include <xen/interface/vcpu.h>
>  #include <xen/interface/memory.h>
> +#include <xen/interface/nmi.h>
>  #include <xen/interface/xen-mca.h>
>  #include <xen/features.h>
>  #include <xen/page.h>
> @@ -66,6 +67,7 @@
>  #include <asm/reboot.h>
>  #include <asm/stackprotector.h>
>  #include <asm/hypervisor.h>
> +#include <asm/mach_traps.h>
>  #include <asm/mwait.h>
>  #include <asm/pci_x86.h>
>  #include <asm/pat.h>
> @@ -1357,6 +1359,21 @@ static const struct machine_ops xen_mach
>  	.emergency_restart = xen_emergency_restart,
>  };
>  
> +static unsigned char xen_get_nmi_reason(void)
> +{
> +	unsigned char reason = 0;
> +
> +	/* Construct a value which looks like it came from port 0x61. */
> +	if (test_bit(_XEN_NMIREASON_io_error,
> +		     &HYPERVISOR_shared_info->arch.nmi_reason))
> +		reason |= NMI_REASON_IOCHK;
> +	if (test_bit(_XEN_NMIREASON_pci_serr,
> +		     &HYPERVISOR_shared_info->arch.nmi_reason))
> +		reason |= NMI_REASON_SERR;
> +
> +	return reason;
> +}
> +
>  static void __init xen_boot_params_init_edd(void)
>  {
>  #if IS_ENABLED(CONFIG_EDD)
> @@ -1541,9 +1558,12 @@ asmlinkage __visible void __init xen_sta
>  	pv_info = xen_info;
>  	pv_init_ops = xen_init_ops;
>  	pv_apic_ops = xen_apic_ops;
> -	if (!xen_pvh_domain())
> +	if (!xen_pvh_domain()) {
>  		pv_cpu_ops = xen_cpu_ops;
>  
> +		x86_platform.get_nmi_reason = xen_get_nmi_reason;
> +	}
> +
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		x86_init.resources.memory_setup = xen_auto_xlated_memory_setup;
>  	else
> --- /usr/local/src/linux-3.18/include/xen/interface/nmi.h	1970-01-01 01:00:00.000000000 +0100
> +++ 3.18-xen-x86-NMI-reason/include/xen/interface/nmi.h
> @@ -0,0 +1,52 @@
> +/******************************************************************************
> + * nmi.h
> + * 
> + * NMI callback registration and reason codes.
> + * 
> + * Copyright (c) 2005, Keir Fraser <keir@xensource.com>
> + */
> +
> +#ifndef __XEN_PUBLIC_NMI_H__
> +#define __XEN_PUBLIC_NMI_H__
> +
> +#include <xen/interface/xen.h>
> +
> +/*
> + * NMI reason codes:
> + * Currently these are x86-specific, stored in arch_shared_info.nmi_reason.
> + */
> + /* I/O-check error reported via ISA port 0x61, bit 6. */
> +#define _XEN_NMIREASON_io_error     0
> +#define XEN_NMIREASON_io_error      (1UL << _XEN_NMIREASON_io_error)
> + /* PCI SERR reported via ISA port 0x61, bit 7. */
> +#define _XEN_NMIREASON_pci_serr     1
> +#define XEN_NMIREASON_pci_serr      (1UL << _XEN_NMIREASON_pci_serr)
> + /* Unknown hardware-generated NMI. */
> +#define _XEN_NMIREASON_unknown      2
> +#define XEN_NMIREASON_unknown       (1UL << _XEN_NMIREASON_unknown)
> +
> +/*
> + * long nmi_op(unsigned int cmd, void *arg)
> + * NB. All ops return zero on success, else a negative error code.
> + */
> +
> +/*
> + * Register NMI callback for this (calling) VCPU. Currently this only makes
> + * sense for domain 0, vcpu 0. All other callers will be returned EINVAL.
> + * arg == pointer to xennmi_callback structure.
> + */
> +#define XENNMI_register_callback   0
> +struct xennmi_callback {
> +    unsigned long handler_address;
> +    unsigned long pad;
> +};
> +typedef struct xennmi_callback xennmi_callback_t;
> +DEFINE_XEN_GUEST_HANDLE(xennmi_callback_t);
> +
> +/*
> + * Deregister NMI callback for this (calling) VCPU.
> + * arg == NULL.
> + */
> +#define XENNMI_unregister_callback 1
> +
> +#endif /* __XEN_PUBLIC_NMI_H__ */
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 11:01:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 11: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 1Y3NDN-00080q-Bi; Tue, 23 Dec 2014 11:01: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 1Y3NDM-00080l-FY
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 11:01:20 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	71/7E-16982-F7B49945; Tue, 23 Dec 2014 11:01:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1419332477!15394675!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, 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 15934 invoked from network); 23 Dec 2014 11:01:18 -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;
	23 Dec 2014 11:01:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,631,1413244800"; d="scan'208";a="207333193"
Message-ID: <54994B7B.20309@citrix.com>
Date: Tue, 23 Dec 2014 11:01:15 +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>, David Vrabel <david.vrabel@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
References: <54945D760200007800051157@mail.emea.novell.com>
In-Reply-To: <54945D760200007800051157@mail.emea.novell.com>
X-DLP: MIA2
Cc: xen-devel <xen-devel@lists.xenproject.org>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] xen/x86: properly retrieve NMI reason
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/14 16:16, Jan Beulich wrote:
> Using the native code here can't work properly, as the hypervisor would
> normally have cleared the two reason bits by the time Dom0 gets to see
> the NMI (if passed to it at all). There's a shared info field for this,
> and there's an existing hook to use - just fit the two together. Note
> that the hook can (and should) be used irrespective of whether being in
> Dom0, as accessing port 0x61 in a DomU would be even worse, while the
> shared info field would just hold zero all the time.

What's the user visible impact of this fix?

David

> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
>  arch/x86/xen/enlighten.c    |   22 +++++++++++++++++-
>  include/xen/interface/nmi.h |   52 ++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 73 insertions(+), 1 deletion(-)
> 
> --- 3.18/arch/x86/xen/enlighten.c
> +++ 3.18-xen-x86-NMI-reason/arch/x86/xen/enlighten.c
> @@ -40,6 +40,7 @@
>  #include <xen/interface/physdev.h>
>  #include <xen/interface/vcpu.h>
>  #include <xen/interface/memory.h>
> +#include <xen/interface/nmi.h>
>  #include <xen/interface/xen-mca.h>
>  #include <xen/features.h>
>  #include <xen/page.h>
> @@ -66,6 +67,7 @@
>  #include <asm/reboot.h>
>  #include <asm/stackprotector.h>
>  #include <asm/hypervisor.h>
> +#include <asm/mach_traps.h>
>  #include <asm/mwait.h>
>  #include <asm/pci_x86.h>
>  #include <asm/pat.h>
> @@ -1357,6 +1359,21 @@ static const struct machine_ops xen_mach
>  	.emergency_restart = xen_emergency_restart,
>  };
>  
> +static unsigned char xen_get_nmi_reason(void)
> +{
> +	unsigned char reason = 0;
> +
> +	/* Construct a value which looks like it came from port 0x61. */
> +	if (test_bit(_XEN_NMIREASON_io_error,
> +		     &HYPERVISOR_shared_info->arch.nmi_reason))
> +		reason |= NMI_REASON_IOCHK;
> +	if (test_bit(_XEN_NMIREASON_pci_serr,
> +		     &HYPERVISOR_shared_info->arch.nmi_reason))
> +		reason |= NMI_REASON_SERR;
> +
> +	return reason;
> +}
> +
>  static void __init xen_boot_params_init_edd(void)
>  {
>  #if IS_ENABLED(CONFIG_EDD)
> @@ -1541,9 +1558,12 @@ asmlinkage __visible void __init xen_sta
>  	pv_info = xen_info;
>  	pv_init_ops = xen_init_ops;
>  	pv_apic_ops = xen_apic_ops;
> -	if (!xen_pvh_domain())
> +	if (!xen_pvh_domain()) {
>  		pv_cpu_ops = xen_cpu_ops;
>  
> +		x86_platform.get_nmi_reason = xen_get_nmi_reason;
> +	}
> +
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		x86_init.resources.memory_setup = xen_auto_xlated_memory_setup;
>  	else
> --- /usr/local/src/linux-3.18/include/xen/interface/nmi.h	1970-01-01 01:00:00.000000000 +0100
> +++ 3.18-xen-x86-NMI-reason/include/xen/interface/nmi.h
> @@ -0,0 +1,52 @@
> +/******************************************************************************
> + * nmi.h
> + * 
> + * NMI callback registration and reason codes.
> + * 
> + * Copyright (c) 2005, Keir Fraser <keir@xensource.com>
> + */
> +
> +#ifndef __XEN_PUBLIC_NMI_H__
> +#define __XEN_PUBLIC_NMI_H__
> +
> +#include <xen/interface/xen.h>
> +
> +/*
> + * NMI reason codes:
> + * Currently these are x86-specific, stored in arch_shared_info.nmi_reason.
> + */
> + /* I/O-check error reported via ISA port 0x61, bit 6. */
> +#define _XEN_NMIREASON_io_error     0
> +#define XEN_NMIREASON_io_error      (1UL << _XEN_NMIREASON_io_error)
> + /* PCI SERR reported via ISA port 0x61, bit 7. */
> +#define _XEN_NMIREASON_pci_serr     1
> +#define XEN_NMIREASON_pci_serr      (1UL << _XEN_NMIREASON_pci_serr)
> + /* Unknown hardware-generated NMI. */
> +#define _XEN_NMIREASON_unknown      2
> +#define XEN_NMIREASON_unknown       (1UL << _XEN_NMIREASON_unknown)
> +
> +/*
> + * long nmi_op(unsigned int cmd, void *arg)
> + * NB. All ops return zero on success, else a negative error code.
> + */
> +
> +/*
> + * Register NMI callback for this (calling) VCPU. Currently this only makes
> + * sense for domain 0, vcpu 0. All other callers will be returned EINVAL.
> + * arg == pointer to xennmi_callback structure.
> + */
> +#define XENNMI_register_callback   0
> +struct xennmi_callback {
> +    unsigned long handler_address;
> +    unsigned long pad;
> +};
> +typedef struct xennmi_callback xennmi_callback_t;
> +DEFINE_XEN_GUEST_HANDLE(xennmi_callback_t);
> +
> +/*
> + * Deregister NMI callback for this (calling) VCPU.
> + * arg == NULL.
> + */
> +#define XENNMI_unregister_callback 1
> +
> +#endif /* __XEN_PUBLIC_NMI_H__ */
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 13:51:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 13:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Pr1-0003KG-2R; Tue, 23 Dec 2014 13:50: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 1Y3Pqz-0003KB-82
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 13:50:25 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	27/77-17694-02379945; Tue, 23 Dec 2014 13:50:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1419342620!15292058!1
X-Originating-IP: [66.165.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 30512 invoked from network); 23 Dec 2014 13:50:21 -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;
	23 Dec 2014 13:50:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,632,1413244800"; d="scan'208";a="207891472"
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.210.2; Tue, 23 Dec 2014 08:50:17 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y3Pqr-00076A-D7;
	Tue, 23 Dec 2014 13:50:17 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3Pqr-000317-7K;
	Tue, 23 Dec 2014 13:50:17 +0000
Date: Tue, 23 Dec 2014 13:50:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32596-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] 32596: 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 32596 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32596/

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              3865941be1fa5466d7892b24f1a2d7ee14f86712
baseline version:
 libvirt              540c339a2535ec30d79e5ef84d8f50a17bc60723

------------------------------------------------------------
People who touched revisions under test:
  Stefan Berger <stefanb@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=3865941be1fa5466d7892b24f1a2d7ee14f86712
+ . 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 3865941be1fa5466d7892b24f1a2d7ee14f86712
+ branch=libvirt
+ revision=3865941be1fa5466d7892b24f1a2d7ee14f86712
+ . 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 3865941be1fa5466d7892b24f1a2d7ee14f86712:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   540c339..3865941  3865941be1fa5466d7892b24f1a2d7ee14f86712 -> 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 Dec 23 13:51:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 13:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3Pr1-0003KG-2R; Tue, 23 Dec 2014 13:50: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 1Y3Pqz-0003KB-82
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 13:50:25 +0000
Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id
	27/77-17694-02379945; Tue, 23 Dec 2014 13:50:24 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-31.messagelabs.com!1419342620!15292058!1
X-Originating-IP: [66.165.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 30512 invoked from network); 23 Dec 2014 13:50:21 -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;
	23 Dec 2014 13:50:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,632,1413244800"; d="scan'208";a="207891472"
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.210.2; Tue, 23 Dec 2014 08:50:17 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y3Pqr-00076A-D7;
	Tue, 23 Dec 2014 13:50:17 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3Pqr-000317-7K;
	Tue, 23 Dec 2014 13:50:17 +0000
Date: Tue, 23 Dec 2014 13:50:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32596-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] 32596: 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 32596 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32596/

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              3865941be1fa5466d7892b24f1a2d7ee14f86712
baseline version:
 libvirt              540c339a2535ec30d79e5ef84d8f50a17bc60723

------------------------------------------------------------
People who touched revisions under test:
  Stefan Berger <stefanb@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=3865941be1fa5466d7892b24f1a2d7ee14f86712
+ . 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 3865941be1fa5466d7892b24f1a2d7ee14f86712
+ branch=libvirt
+ revision=3865941be1fa5466d7892b24f1a2d7ee14f86712
+ . 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 3865941be1fa5466d7892b24f1a2d7ee14f86712:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   540c339..3865941  3865941be1fa5466d7892b24f1a2d7ee14f86712 -> 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 Dec 23 13:54:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 13: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 1Y3Pv1-0003cJ-O2; Tue, 23 Dec 2014 13:54:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Y3Pv0-0003cB-9G
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 13:54:34 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	67/03-25714-91479945; Tue, 23 Dec 2014 13:54:33 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1419342873!10993181!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27426 invoked from network); 23 Dec 2014 13:54:33 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 13:54:33 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so9164110wgh.31
	for <xen-devel@lists.xen.org>; Tue, 23 Dec 2014 05:54: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
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=wzwFw4o7382vFeK/wMFikwHne1M+KFMIOP4uJZjgxsA=;
	b=Dup9/j4DLYsQQv/5n4xsOpI5nczsN5T/GtzLv8P89TpxtrbaVfXAQY6DUKP4xVtYyU
	KVlowzcwBZ3hqDxWSe02nsji48zCU/PPY3eCZepkhSuaJwn1BOvmtaU4iQzygdLiF8Ki
	efvxGpxIb4+YLqyDE8GtM0a+81xRL9HfMJUOk9EtCOHGUiUR8IaZEf3Dx8FvGdVpJjnG
	qQ/VoxjkqKLBSlWSPpsOQvuNd0bcV48gp8zYYPf9m5wMs1GlMjdyFFvjkZdfIGqXM4Zg
	cKRlJQ/NeMouSV7vY+QhHa4GwSOP5YaTxSFFlKe0Z+NyX4njWPnDDQXLYYa3sQY2if19
	TRuA==
X-Gm-Message-State: ALoCoQmOjfzsbK+Xp1sR/YgVxPEX0qBY750KvCJmI4Rm1EUjpDr/cXgTnvzLoYCUOHhUW2tLb4eH
X-Received: by 10.180.83.228 with SMTP id t4mr42205796wiy.28.1419342871919;
	Tue, 23 Dec 2014 05:54:31 -0800 (PST)
Received: from Juliens-MacBook-Pro.local (158.93.192.77.rev.sfr.net.
	[77.192.93.158])
	by mx.google.com with ESMTPSA id hn2sm27789924wjc.5.2014.12.23.05.54.29
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 23 Dec 2014 05:54:31 -0800 (PST)
Message-ID: <54997429.2090603@linaro.org>
Date: Tue, 23 Dec 2014 14:54:49 +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.3.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>, 
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	manish.jaggi@caviumnetworks.com, Vijaya.Kumar@caviumnetworks.com
References: <CAAiw7JnT_s=eS5dR8xvUKChxox8BcQpzuFpsPtJo5YRegFAKBg@mail.gmail.com>
In-Reply-To: <CAAiw7JnT_s=eS5dR8xvUKChxox8BcQpzuFpsPtJo5YRegFAKBg@mail.gmail.com>
Subject: Re: [Xen-devel] [query] gic_update_one_lr r/w from ICH_LR rather
 than vcpu context lr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 23/12/2014 04:43, manish jaggi wrote:
> In gic.c, gic_update_one_lr, gic_hw_ops is called to read and write to an LR.

The function gic_update_one_lr is only used to update the LRs of the 
current vCPU.

> why is read/write not done on the LRs stored in the vcpu context ?

The LR array in the vCPU context is only used when to save/restore the
state of the vGIC vCPU.

When the vCPU is not sync, the state of this LRs is invalid. Think about 
the vCPU running on another pCPU.

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 Dec 23 13:54:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 13: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 1Y3Pv1-0003cJ-O2; Tue, 23 Dec 2014 13:54:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1Y3Pv0-0003cB-9G
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 13:54:34 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	67/03-25714-91479945; Tue, 23 Dec 2014 13:54:33 +0000
X-Env-Sender: julien.grall@linaro.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1419342873!10993181!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27426 invoked from network); 23 Dec 2014 13:54:33 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Dec 2014 13:54:33 -0000
Received: by mail-wg0-f44.google.com with SMTP id b13so9164110wgh.31
	for <xen-devel@lists.xen.org>; Tue, 23 Dec 2014 05:54: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
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=wzwFw4o7382vFeK/wMFikwHne1M+KFMIOP4uJZjgxsA=;
	b=Dup9/j4DLYsQQv/5n4xsOpI5nczsN5T/GtzLv8P89TpxtrbaVfXAQY6DUKP4xVtYyU
	KVlowzcwBZ3hqDxWSe02nsji48zCU/PPY3eCZepkhSuaJwn1BOvmtaU4iQzygdLiF8Ki
	efvxGpxIb4+YLqyDE8GtM0a+81xRL9HfMJUOk9EtCOHGUiUR8IaZEf3Dx8FvGdVpJjnG
	qQ/VoxjkqKLBSlWSPpsOQvuNd0bcV48gp8zYYPf9m5wMs1GlMjdyFFvjkZdfIGqXM4Zg
	cKRlJQ/NeMouSV7vY+QhHa4GwSOP5YaTxSFFlKe0Z+NyX4njWPnDDQXLYYa3sQY2if19
	TRuA==
X-Gm-Message-State: ALoCoQmOjfzsbK+Xp1sR/YgVxPEX0qBY750KvCJmI4Rm1EUjpDr/cXgTnvzLoYCUOHhUW2tLb4eH
X-Received: by 10.180.83.228 with SMTP id t4mr42205796wiy.28.1419342871919;
	Tue, 23 Dec 2014 05:54:31 -0800 (PST)
Received: from Juliens-MacBook-Pro.local (158.93.192.77.rev.sfr.net.
	[77.192.93.158])
	by mx.google.com with ESMTPSA id hn2sm27789924wjc.5.2014.12.23.05.54.29
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 23 Dec 2014 05:54:31 -0800 (PST)
Message-ID: <54997429.2090603@linaro.org>
Date: Tue, 23 Dec 2014 14:54:49 +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.3.0
MIME-Version: 1.0
To: manish jaggi <manishjaggi.oss@gmail.com>, 
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	manish.jaggi@caviumnetworks.com, Vijaya.Kumar@caviumnetworks.com
References: <CAAiw7JnT_s=eS5dR8xvUKChxox8BcQpzuFpsPtJo5YRegFAKBg@mail.gmail.com>
In-Reply-To: <CAAiw7JnT_s=eS5dR8xvUKChxox8BcQpzuFpsPtJo5YRegFAKBg@mail.gmail.com>
Subject: Re: [Xen-devel] [query] gic_update_one_lr r/w from ICH_LR rather
 than vcpu context lr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 23/12/2014 04:43, manish jaggi wrote:
> In gic.c, gic_update_one_lr, gic_hw_ops is called to read and write to an LR.

The function gic_update_one_lr is only used to update the LRs of the 
current vCPU.

> why is read/write not done on the LRs stored in the vcpu context ?

The LR array in the vCPU context is only used when to save/restore the
state of the vGIC vCPU.

When the vCPU is not sync, the state of this LRs is invalid. Think about 
the vCPU running on another pCPU.

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 Dec 23 14:28:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 14: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 1Y3QRL-0004RQ-4F; Tue, 23 Dec 2014 14:27:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y3QRJ-0004RL-RM
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 14:27:57 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	69/0E-25727-DEB79945; Tue, 23 Dec 2014 14:27:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419344874!15415724!1
X-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 27135 invoked from network); 23 Dec 2014 14:27:54 -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; 23 Dec 2014 14:27:54 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 23 Dec 2014 14:27:54 +0000
Message-Id: <549989F70200007800051821@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 23 Dec 2014 14:27:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <5494196B0200007800050F6B@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126123D2B@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126123D2B@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] VT-d: don't crash when PTE bits 52 and up
 are 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 23.12.14 at 07:52, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Friday, December 19, 2014 7:26 PM
>> 
>> This can (and will) be legitimately the case when sharing page tables
>> with EPT (more of a problem before p2m_access_rwx became zero, but
>> still possible even now when other than that is the default for a
>> guest), leading to an unconditional crash (in print_vtd_entries())
>> when a DMA remapping fault occurs.
> 
> could you elaborate the scenarios when bits 52+ are non-zero?

This happens with shared page tables and a non-zero access 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 Dec 23 14:28:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 14: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 1Y3QRL-0004RQ-4F; Tue, 23 Dec 2014 14:27:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Y3QRJ-0004RL-RM
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 14:27:57 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	69/0E-25727-DEB79945; Tue, 23 Dec 2014 14:27:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419344874!15415724!1
X-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 27135 invoked from network); 23 Dec 2014 14:27:54 -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; 23 Dec 2014 14:27:54 -0000
Received: from EMEA1-MTA by mail.emea.novell.com
	with Novell_GroupWise; Tue, 23 Dec 2014 14:27:54 +0000
Message-Id: <549989F70200007800051821@mail.emea.novell.com>
X-Mailer: Novell GroupWise Internet Agent 14.0.1 
Date: Tue, 23 Dec 2014 14:27:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kevin Tian" <kevin.tian@intel.com>
References: <5494196B0200007800050F6B@mail.emea.novell.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126123D2B@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126123D2B@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] VT-d: don't crash when PTE bits 52 and up
 are 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 23.12.14 at 07:52, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Friday, December 19, 2014 7:26 PM
>> 
>> This can (and will) be legitimately the case when sharing page tables
>> with EPT (more of a problem before p2m_access_rwx became zero, but
>> still possible even now when other than that is the default for a
>> guest), leading to an unconditional crash (in print_vtd_entries())
>> when a DMA remapping fault occurs.
> 
> could you elaborate the scenarios when bits 52+ are non-zero?

This happens with shared page tables and a non-zero access 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 Dec 23 14:35:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 14: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 1Y3QYU-0004l8-1b; Tue, 23 Dec 2014 14:35: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 1Y3QYS-0004l3-4G
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 14:35:20 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	25/9E-05632-7AD79945; Tue, 23 Dec 2014 14:35:19 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1419345317!15455358!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15953 invoked from network); 23 Dec 2014 14:35:18 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 14:35:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1419345318; x=1450881318;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=Ll1mme6abxjtoUsBCJC6fusClcp6q/tHswSoT9UNUjw=;
	b=S7BhJJYeWpHVd+sOf+v3AeYcN6JYEHE/IeLYzhiNKCEVtE3PAPBxl9/A
	zsTw/283bY4Y6a1On3sxuLDB7CDxYHhl7GAd+gIUCqMNdjrWDNpj/0A2U
	My0Re4O3JeuvUgxuUXoMIABOjd+E+/yGDKuENPy4tXjcyEzztr8eDCLNh E=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 23 Dec 2014 14:35:16 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,632,1413244800"; d="scan'208";a="900332789"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.106.51])
	by fldsmtpi03.verizon.com with ESMTP; 23 Dec 2014 14:35:15 +0000
Message-ID: <54997DA2.6000408@terremark.com>
Date: Tue, 23 Dec 2014 09:35:14 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Don Slutz <dslutz@verizon.com>
References: <1417612519-6931-1-git-send-email-dslutz@verizon.com>
In-Reply-To: <1417612519-6931-1-git-send-email-dslutz@verizon.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for 2.3 v2 1/1] xen-hvm: 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

Ping.

On 12/03/14 08:15, Don Slutz wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> 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>
> Signed-off-by: Don Slutz <dslutz@verizon.com>
> ---
> v2: Changes by Don Slutz
>    Switch from xc_domain_getinfo to xc_domain_getinfolist
>    Fix error check for xc_domain_getinfolist
>    Limit increase of maxmem to only do when needed:
>      Add QEMU_SPARE_PAGES (How many pages to leave free)
>      Add free_pages calculation
>
>   xen-hvm.c | 19 +++++++++++++++++++
>   1 file changed, 19 insertions(+)
>
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 7548794..d30e77e 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -90,6 +90,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
>   #endif
>   
>   #define BUFFER_IO_MAX_DELAY  100
> +#define QEMU_SPARE_PAGES 16
>   
>   typedef struct XenPhysmap {
>       hwaddr start_addr;
> @@ -244,6 +245,8 @@ 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_domaininfo_t info;
> +    unsigned long free_pages;
>   
>       if (runstate_check(RUN_STATE_INMIGRATE)) {
>           /* RAM already populated in Xen */
> @@ -266,6 +269,22 @@ 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_getinfolist(xen_xc, xen_domid, 1, &info) != 1) ||
> +        (info.domain != xen_domid)) {
> +        hw_error("xc_domain_getinfolist failed");
> +    }
> +    free_pages = info.max_pages - info.tot_pages;
> +    if (free_pages > QEMU_SPARE_PAGES) {
> +        free_pages -= QEMU_SPARE_PAGES;
> +    } else {
> +        free_pages = 0;
> +    }
> +    if ((free_pages < nr_pfn) &&
> +        (xc_domain_setmaxmem(xen_xc, xen_domid,
> +                             ((info.max_pages + nr_pfn - free_pages)
> +                              << (XC_PAGE_SHIFT - 10))) < 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 Dec 23 14:35:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 14: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 1Y3QYU-0004l8-1b; Tue, 23 Dec 2014 14:35: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 1Y3QYS-0004l3-4G
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 14:35:20 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	25/9E-05632-7AD79945; Tue, 23 Dec 2014 14:35:19 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1419345317!15455358!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15953 invoked from network); 23 Dec 2014 14:35:18 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 14:35:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1419345318; x=1450881318;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=Ll1mme6abxjtoUsBCJC6fusClcp6q/tHswSoT9UNUjw=;
	b=S7BhJJYeWpHVd+sOf+v3AeYcN6JYEHE/IeLYzhiNKCEVtE3PAPBxl9/A
	zsTw/283bY4Y6a1On3sxuLDB7CDxYHhl7GAd+gIUCqMNdjrWDNpj/0A2U
	My0Re4O3JeuvUgxuUXoMIABOjd+E+/yGDKuENPy4tXjcyEzztr8eDCLNh E=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145])
	by fldsmtpe04.verizon.com with ESMTP; 23 Dec 2014 14:35:16 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,632,1413244800"; d="scan'208";a="900332789"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.106.51])
	by fldsmtpi03.verizon.com with ESMTP; 23 Dec 2014 14:35:15 +0000
Message-ID: <54997DA2.6000408@terremark.com>
Date: Tue, 23 Dec 2014 09:35:14 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Don Slutz <dslutz@verizon.com>
References: <1417612519-6931-1-git-send-email-dslutz@verizon.com>
In-Reply-To: <1417612519-6931-1-git-send-email-dslutz@verizon.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH for 2.3 v2 1/1] xen-hvm: 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

Ping.

On 12/03/14 08:15, Don Slutz wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> 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>
> Signed-off-by: Don Slutz <dslutz@verizon.com>
> ---
> v2: Changes by Don Slutz
>    Switch from xc_domain_getinfo to xc_domain_getinfolist
>    Fix error check for xc_domain_getinfolist
>    Limit increase of maxmem to only do when needed:
>      Add QEMU_SPARE_PAGES (How many pages to leave free)
>      Add free_pages calculation
>
>   xen-hvm.c | 19 +++++++++++++++++++
>   1 file changed, 19 insertions(+)
>
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 7548794..d30e77e 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -90,6 +90,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
>   #endif
>   
>   #define BUFFER_IO_MAX_DELAY  100
> +#define QEMU_SPARE_PAGES 16
>   
>   typedef struct XenPhysmap {
>       hwaddr start_addr;
> @@ -244,6 +245,8 @@ 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_domaininfo_t info;
> +    unsigned long free_pages;
>   
>       if (runstate_check(RUN_STATE_INMIGRATE)) {
>           /* RAM already populated in Xen */
> @@ -266,6 +269,22 @@ 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_getinfolist(xen_xc, xen_domid, 1, &info) != 1) ||
> +        (info.domain != xen_domid)) {
> +        hw_error("xc_domain_getinfolist failed");
> +    }
> +    free_pages = info.max_pages - info.tot_pages;
> +    if (free_pages > QEMU_SPARE_PAGES) {
> +        free_pages -= QEMU_SPARE_PAGES;
> +    } else {
> +        free_pages = 0;
> +    }
> +    if ((free_pages < nr_pfn) &&
> +        (xc_domain_setmaxmem(xen_xc, xen_domid,
> +                             ((info.max_pages + nr_pfn - free_pages)
> +                              << (XC_PAGE_SHIFT - 10))) < 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 Dec 23 15:08:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3R3w-0005Wd-Rs; Tue, 23 Dec 2014 15:07:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3R3v-0005WY-FG
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 15:07:51 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	24/5B-11581-64589945; Tue, 23 Dec 2014 15:07:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1419347268!10807760!1
X-Originating-IP: [66.165.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 27365 invoked from network); 23 Dec 2014 15:07:49 -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;
	23 Dec 2014 15:07:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,632,1413244800"; d="scan'208";a="207923574"
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.210.2; Tue, 23 Dec 2014 10:07: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 1Y3R36-0007Sw-VK;
	Tue, 23 Dec 2014 15:07:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3R36-0007JX-Om;
	Tue, 23 Dec 2014 15:07:00 +0000
Date: Tue, 23 Dec 2014 15:07:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32594-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] 32594: 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 32594 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32594/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot             fail pass in 32574

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install               fail   like 32574
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32574

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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-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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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                          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                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 23 15:08:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3R3w-0005Wd-Rs; Tue, 23 Dec 2014 15:07:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3R3v-0005WY-FG
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 15:07:51 +0000
Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id
	24/5B-11581-64589945; Tue, 23 Dec 2014 15:07:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1419347268!10807760!1
X-Originating-IP: [66.165.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 27365 invoked from network); 23 Dec 2014 15:07:49 -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;
	23 Dec 2014 15:07:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,632,1413244800"; d="scan'208";a="207923574"
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.210.2; Tue, 23 Dec 2014 10:07: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 1Y3R36-0007Sw-VK;
	Tue, 23 Dec 2014 15:07:01 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3R36-0007JX-Om;
	Tue, 23 Dec 2014 15:07:00 +0000
Date: Tue, 23 Dec 2014 15:07:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32594-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] 32594: 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 32594 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32594/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot             fail pass in 32574

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install               fail   like 32574
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32574

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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-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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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                          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                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 23 15:11:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15:11:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3R7t-0005rH-NC; Tue, 23 Dec 2014 15:11:57 +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 1Y3R7s-0005qU-BW
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 15:11:56 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	C4/2F-17735-B3689945; Tue, 23 Dec 2014 15:11:55 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1419347513!11007106!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19668 invoked from network); 23 Dec 2014 15:11:54 -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; 23 Dec 2014 15:11:54 -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 sBNFBnhT014898
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Dec 2014 15:11:50 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
	sBNFBmXF005499
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Dec 2014 15:11:49 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
	sBNFBlGr012085; Tue, 23 Dec 2014 15:11:47 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, 23 Dec 2014 07:11:47 -0800
Message-ID: <549986B8.3030606@oracle.com>
Date: Tue, 23 Dec 2014 10:14:00 -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: Andy Lutomirski <luto@amacapital.net>, Paolo Bonzini <pbonzini@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>
References: <cover.1419295081.git.luto@amacapital.net>
	<8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
In-Reply-To: <8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>
Subject: Re: [Xen-devel] [RFC 2/2] x86, vdso,
 pvclock: Simplify and speed up the vdso pvclock reader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/22/2014 07:39 PM, Andy Lutomirski wrote:
> The pvclock vdso code was too abstracted to understand easily and
> excessively paranoid.  Simplify it for a huge speedup.
>
> This opens the door for additional simplifications, as the vdso no
> longer accesses the pvti for any vcpu other than vcpu 0.
>
> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
> With this change, it takes 19ns, which is almost as fast as the pure TSC
> implementation.
>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>   arch/x86/vdso/vclock_gettime.c | 82 ++++++++++++++++++++++++------------------
>   1 file changed, 47 insertions(+), 35 deletions(-)
>
> diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
> index 9793322751e0..f2e0396d5629 100644
> --- a/arch/x86/vdso/vclock_gettime.c
> +++ b/arch/x86/vdso/vclock_gettime.c
> @@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
>   
>   static notrace cycle_t vread_pvclock(int *mode)
>   {
> -	const struct pvclock_vsyscall_time_info *pvti;
> +	const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>   	cycle_t ret;
> -	u64 last;
> -	u32 version;
> -	u8 flags;
> -	unsigned cpu, cpu1;
> -
> +	u64 tsc, pvti_tsc;
> +	u64 last, delta, pvti_system_time;
> +	u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>   
>   	/*
> -	 * Note: hypervisor must guarantee that:
> -	 * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
> -	 * 2. that per-CPU pvclock time info is updated if the
> -	 *    underlying CPU changes.
> -	 * 3. that version is increased whenever underlying CPU
> -	 *    changes.
> +	 * Note: The kernel and hypervisor must guarantee that cpu ID
> +	 * number maps 1:1 to per-CPU pvclock time info.
> +	 *
> +	 * Because the hypervisor is entirely unaware of guest userspace
> +	 * preemption, it cannot guarantee that per-CPU pvclock time
> +	 * info is updated if the underlying CPU changes or that that
> +	 * version is increased whenever underlying CPU changes.
> +	 *
> +	 * On KVM, we are guaranteed that pvti updates for any vCPU are
> +	 * atomic as seen by *all* vCPUs.  This is an even stronger
> +	 * guarantee than we get with a normal seqlock.
>   	 *
> +	 * On Xen, we don't appear to have that guarantee, but Xen still
> +	 * supplies a valid seqlock using the version field.
> +
> +	 * We only do pvclock vdso timing at all if
> +	 * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
> +	 * mean that all vCPUs have matching pvti and that the TSC is
> +	 * synced, so we can just look at vCPU 0's pvti.
>   	 */
> -	do {
> -		cpu = __getcpu() & VGETCPU_CPU_MASK;
> -		/* TODO: We can put vcpu id into higher bits of pvti.version.
> -		 * This will save a couple of cycles by getting rid of
> -		 * __getcpu() calls (Gleb).
> -		 */
> -
> -		pvti = get_pvti(cpu);
> -
> -		version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
> -
> -		/*
> -		 * Test we're still on the cpu as well as the version.
> -		 * We could have been migrated just after the first
> -		 * vgetcpu but before fetching the version, so we
> -		 * wouldn't notice a version change.
> -		 */
> -		cpu1 = __getcpu() & VGETCPU_CPU_MASK;
> -	} while (unlikely(cpu != cpu1 ||
> -			  (pvti->pvti.version & 1) ||
> -			  pvti->pvti.version != version));
> -
> -	if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
> +
> +	if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>   		*mode = VCLOCK_NONE;
> +		return 0;
> +	}
> +
> +	do {
> +		version = pvti->version;
> +
> +		/* This is also a read barrier, so we'll read version first. */
> +		rdtsc_barrier();
> +		tsc = __native_read_tsc();


This will cause VMEXIT on Xen with TSC_MODE_ALWAYS_EMULATE which is 
used, for example, after guest migrated (unless HW is capable of scaling 
TSC rate).

-boris


> +
> +		pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
> +		pvti_tsc_shift = pvti->tsc_shift;
> +		pvti_system_time = pvti->system_time;
> +		pvti_tsc = pvti->tsc_timestamp;
> +
> +		/* Make sure that the version double-check is last. */
> +		smp_rmb();
> +	} while (unlikely((version & 1) || version != pvti->version));
> +
> +	delta = tsc - pvti_tsc;
> +	ret = pvti_system_time +
> +		pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
> +				    pvti_tsc_shift);
>   
>   	/* refer to tsc.c read_tsc() comment for rationale */
>   	last = gtod->cycle_last;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:11:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15:11:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3R7t-0005rH-NC; Tue, 23 Dec 2014 15:11:57 +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 1Y3R7s-0005qU-BW
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 15:11:56 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	C4/2F-17735-B3689945; Tue, 23 Dec 2014 15:11:55 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1419347513!11007106!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19668 invoked from network); 23 Dec 2014 15:11:54 -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; 23 Dec 2014 15:11:54 -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 sBNFBnhT014898
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Dec 2014 15:11:50 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
	sBNFBmXF005499
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Dec 2014 15:11:49 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
	sBNFBlGr012085; Tue, 23 Dec 2014 15:11:47 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, 23 Dec 2014 07:11:47 -0800
Message-ID: <549986B8.3030606@oracle.com>
Date: Tue, 23 Dec 2014 10:14:00 -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: Andy Lutomirski <luto@amacapital.net>, Paolo Bonzini <pbonzini@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>
References: <cover.1419295081.git.luto@amacapital.net>
	<8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
In-Reply-To: <8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>
Subject: Re: [Xen-devel] [RFC 2/2] x86, vdso,
 pvclock: Simplify and speed up the vdso pvclock reader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/22/2014 07:39 PM, Andy Lutomirski wrote:
> The pvclock vdso code was too abstracted to understand easily and
> excessively paranoid.  Simplify it for a huge speedup.
>
> This opens the door for additional simplifications, as the vdso no
> longer accesses the pvti for any vcpu other than vcpu 0.
>
> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
> With this change, it takes 19ns, which is almost as fast as the pure TSC
> implementation.
>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>   arch/x86/vdso/vclock_gettime.c | 82 ++++++++++++++++++++++++------------------
>   1 file changed, 47 insertions(+), 35 deletions(-)
>
> diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
> index 9793322751e0..f2e0396d5629 100644
> --- a/arch/x86/vdso/vclock_gettime.c
> +++ b/arch/x86/vdso/vclock_gettime.c
> @@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
>   
>   static notrace cycle_t vread_pvclock(int *mode)
>   {
> -	const struct pvclock_vsyscall_time_info *pvti;
> +	const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>   	cycle_t ret;
> -	u64 last;
> -	u32 version;
> -	u8 flags;
> -	unsigned cpu, cpu1;
> -
> +	u64 tsc, pvti_tsc;
> +	u64 last, delta, pvti_system_time;
> +	u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>   
>   	/*
> -	 * Note: hypervisor must guarantee that:
> -	 * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
> -	 * 2. that per-CPU pvclock time info is updated if the
> -	 *    underlying CPU changes.
> -	 * 3. that version is increased whenever underlying CPU
> -	 *    changes.
> +	 * Note: The kernel and hypervisor must guarantee that cpu ID
> +	 * number maps 1:1 to per-CPU pvclock time info.
> +	 *
> +	 * Because the hypervisor is entirely unaware of guest userspace
> +	 * preemption, it cannot guarantee that per-CPU pvclock time
> +	 * info is updated if the underlying CPU changes or that that
> +	 * version is increased whenever underlying CPU changes.
> +	 *
> +	 * On KVM, we are guaranteed that pvti updates for any vCPU are
> +	 * atomic as seen by *all* vCPUs.  This is an even stronger
> +	 * guarantee than we get with a normal seqlock.
>   	 *
> +	 * On Xen, we don't appear to have that guarantee, but Xen still
> +	 * supplies a valid seqlock using the version field.
> +
> +	 * We only do pvclock vdso timing at all if
> +	 * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
> +	 * mean that all vCPUs have matching pvti and that the TSC is
> +	 * synced, so we can just look at vCPU 0's pvti.
>   	 */
> -	do {
> -		cpu = __getcpu() & VGETCPU_CPU_MASK;
> -		/* TODO: We can put vcpu id into higher bits of pvti.version.
> -		 * This will save a couple of cycles by getting rid of
> -		 * __getcpu() calls (Gleb).
> -		 */
> -
> -		pvti = get_pvti(cpu);
> -
> -		version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
> -
> -		/*
> -		 * Test we're still on the cpu as well as the version.
> -		 * We could have been migrated just after the first
> -		 * vgetcpu but before fetching the version, so we
> -		 * wouldn't notice a version change.
> -		 */
> -		cpu1 = __getcpu() & VGETCPU_CPU_MASK;
> -	} while (unlikely(cpu != cpu1 ||
> -			  (pvti->pvti.version & 1) ||
> -			  pvti->pvti.version != version));
> -
> -	if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
> +
> +	if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>   		*mode = VCLOCK_NONE;
> +		return 0;
> +	}
> +
> +	do {
> +		version = pvti->version;
> +
> +		/* This is also a read barrier, so we'll read version first. */
> +		rdtsc_barrier();
> +		tsc = __native_read_tsc();


This will cause VMEXIT on Xen with TSC_MODE_ALWAYS_EMULATE which is 
used, for example, after guest migrated (unless HW is capable of scaling 
TSC rate).

-boris


> +
> +		pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
> +		pvti_tsc_shift = pvti->tsc_shift;
> +		pvti_system_time = pvti->system_time;
> +		pvti_tsc = pvti->tsc_timestamp;
> +
> +		/* Make sure that the version double-check is last. */
> +		smp_rmb();
> +	} while (unlikely((version & 1) || version != pvti->version));
> +
> +	delta = tsc - pvti_tsc;
> +	ret = pvti_system_time +
> +		pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
> +				    pvti_tsc_shift);
>   
>   	/* refer to tsc.c read_tsc() comment for rationale */
>   	last = gtod->cycle_last;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:14:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3RAH-0005yH-83; Tue, 23 Dec 2014 15:14:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1Y3RAG-0005yB-0U
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 15:14:24 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	D9/02-02699-FC689945; Tue, 23 Dec 2014 15:14:23 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1419347661!16924130!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9316 invoked from network); 23 Dec 2014 15:14:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 15:14: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 sBNFEHDm017294
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 23 Dec 2014 10:14:17 -0500
Received: from [10.36.112.28] (ovpn-112-28.ams2.redhat.com [10.36.112.28])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBNFEBAd020287
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Tue, 23 Dec 2014 10:14:14 -0500
Message-ID: <549986C3.4060807@redhat.com>
Date: Tue, 23 Dec 2014 16:14:11 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Marcelo Tosatti <mtosatti@redhat.com>
References: <cover.1419295081.git.luto@amacapital.net>
	<8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
	<549986B8.3030606@oracle.com>
In-Reply-To: <549986B8.3030606@oracle.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>
Subject: Re: [Xen-devel] [RFC 2/2] x86, vdso,
 pvclock: Simplify and speed up the vdso pvclock reader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/2014 16:14, Boris Ostrovsky wrote:
>> +    do {
>> +        version = pvti->version;
>> +
>> +        /* This is also a read barrier, so we'll read version first. */
>> +        rdtsc_barrier();
>> +        tsc = __native_read_tsc();
> 
> 
> This will cause VMEXIT on Xen with TSC_MODE_ALWAYS_EMULATE which is
> used, for example, after guest migrated (unless HW is capable of scaling
> TSC rate).

So does the __pvclock_read_cycles this is replacing (via
pvclock_get_nsec_offset).

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:14:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3RAH-0005yH-83; Tue, 23 Dec 2014 15:14:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1Y3RAG-0005yB-0U
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 15:14:24 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	D9/02-02699-FC689945; Tue, 23 Dec 2014 15:14:23 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1419347661!16924130!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9316 invoked from network); 23 Dec 2014 15:14:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 15:14: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 sBNFEHDm017294
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Tue, 23 Dec 2014 10:14:17 -0500
Received: from [10.36.112.28] (ovpn-112-28.ams2.redhat.com [10.36.112.28])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBNFEBAd020287
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Tue, 23 Dec 2014 10:14:14 -0500
Message-ID: <549986C3.4060807@redhat.com>
Date: Tue, 23 Dec 2014 16:14:11 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Marcelo Tosatti <mtosatti@redhat.com>
References: <cover.1419295081.git.luto@amacapital.net>
	<8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
	<549986B8.3030606@oracle.com>
In-Reply-To: <549986B8.3030606@oracle.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>
Subject: Re: [Xen-devel] [RFC 2/2] x86, vdso,
 pvclock: Simplify and speed up the vdso pvclock reader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/12/2014 16:14, Boris Ostrovsky wrote:
>> +    do {
>> +        version = pvti->version;
>> +
>> +        /* This is also a read barrier, so we'll read version first. */
>> +        rdtsc_barrier();
>> +        tsc = __native_read_tsc();
> 
> 
> This will cause VMEXIT on Xen with TSC_MODE_ALWAYS_EMULATE which is
> used, for example, after guest migrated (unless HW is capable of scaling
> TSC rate).

So does the __pvclock_read_cycles this is replacing (via
pvclock_get_nsec_offset).

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:24:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15: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 1Y3RJK-0006KK-9t; Tue, 23 Dec 2014 15:23:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Y3RJJ-0006KF-I2
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 15:23:45 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	B5/22-02696-00989945; Tue, 23 Dec 2014 15:23:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1419348223!16904436!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31641 invoked from network); 23 Dec 2014 15:23:44 -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; 23 Dec 2014 15:23:44 -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 sBNFNcH5029872
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Dec 2014 15:23:39 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
	sBNFNakR018012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 23 Dec 2014 15:23:37 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
	sBNFNax6010062; Tue, 23 Dec 2014 15:23: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, 23 Dec 2014 07:23:36 -0800
Message-ID: <5499897D.3000904@oracle.com>
Date: Tue, 23 Dec 2014 10:25: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: Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@amacapital.net>,
	Marcelo Tosatti <mtosatti@redhat.com>
References: <cover.1419295081.git.luto@amacapital.net>
	<8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
	<549986B8.3030606@oracle.com> <549986C3.4060807@redhat.com>
In-Reply-To: <549986C3.4060807@redhat.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>
Subject: Re: [Xen-devel] [RFC 2/2] x86, vdso,
 pvclock: Simplify and speed up the vdso pvclock reader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/23/2014 10:14 AM, Paolo Bonzini wrote:
>
> On 23/12/2014 16:14, Boris Ostrovsky wrote:
>>> +    do {
>>> +        version = pvti->version;
>>> +
>>> +        /* This is also a read barrier, so we'll read version first. */
>>> +        rdtsc_barrier();
>>> +        tsc = __native_read_tsc();
>>
>> This will cause VMEXIT on Xen with TSC_MODE_ALWAYS_EMULATE which is
>> used, for example, after guest migrated (unless HW is capable of scaling
>> TSC rate).
> So does the __pvclock_read_cycles this is replacing (via
> pvclock_get_nsec_offset).

Right, I didn't notice that.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:24:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15: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 1Y3RJK-0006KK-9t; Tue, 23 Dec 2014 15:23:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1Y3RJJ-0006KF-I2
	for xen-devel@lists.xenproject.org; Tue, 23 Dec 2014 15:23:45 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	B5/22-02696-00989945; Tue, 23 Dec 2014 15:23:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1419348223!16904436!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31641 invoked from network); 23 Dec 2014 15:23:44 -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; 23 Dec 2014 15:23:44 -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 sBNFNcH5029872
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Dec 2014 15:23:39 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
	sBNFNakR018012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 23 Dec 2014 15:23:37 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
	sBNFNax6010062; Tue, 23 Dec 2014 15:23: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, 23 Dec 2014 07:23:36 -0800
Message-ID: <5499897D.3000904@oracle.com>
Date: Tue, 23 Dec 2014 10:25: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: Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@amacapital.net>,
	Marcelo Tosatti <mtosatti@redhat.com>
References: <cover.1419295081.git.luto@amacapital.net>
	<8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
	<549986B8.3030606@oracle.com> <549986C3.4060807@redhat.com>
In-Reply-To: <549986C3.4060807@redhat.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Gleb Natapov <gleb@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>
Subject: Re: [Xen-devel] [RFC 2/2] x86, vdso,
 pvclock: Simplify and speed up the vdso pvclock reader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/23/2014 10:14 AM, Paolo Bonzini wrote:
>
> On 23/12/2014 16:14, Boris Ostrovsky wrote:
>>> +    do {
>>> +        version = pvti->version;
>>> +
>>> +        /* This is also a read barrier, so we'll read version first. */
>>> +        rdtsc_barrier();
>>> +        tsc = __native_read_tsc();
>>
>> This will cause VMEXIT on Xen with TSC_MODE_ALWAYS_EMULATE which is
>> used, for example, after guest migrated (unless HW is capable of scaling
>> TSC rate).
> So does the __pvclock_read_cycles this is replacing (via
> pvclock_get_nsec_offset).

Right, I didn't notice that.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:48:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15: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 1Y3Rgt-0006rq-Ii; Tue, 23 Dec 2014 15:48:07 +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 1Y3Rgq-0006rl-2b
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 15:48:06 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	27/32-25276-3BE89945; Tue, 23 Dec 2014 15:48:03 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-14.tower-21.messagelabs.com!1419349683!17544789!1
X-Originating-IP: [131.111.8.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9814 invoked from network); 23 Dec 2014 15:48:03 -0000
Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk)
	(131.111.8.151)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 15:48:03 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from host86-133-74-101.range86-133.btcentralplus.com
	([86.133.74.101]:50844 helo=[192.168.1.98])
	by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1.2:DHE-RSA-AES128-SHA:128)
	id 1Y3Rgo-0000xV-Yh (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 23 Dec 2014 15:48:02 +0000
Message-ID: <549985D4.1040509@citrix.com>
Date: Tue, 23 Dec 2014 15:10:12 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
	<20141216204900.GB11551@konrad-lan.dumpdata.com>
	<54944210.6050402@citrix.com>
	<20141219181447.GB7162@laptop.dumpdata.com>
In-Reply-To: <20141219181447.GB7162@laptop.dumpdata.com>
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/2014 18:14, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 19, 2014 at 03:19:44PM +0000, Andrew Cooper wrote:
>>
>> There will be another full nightly test happening tonight (based on c/s
>> 7e88c23 "libxl: Tell qemu to use raw format when using a tapdisk"), and
>> some stress and scale tests if time allows.
> Yeey! thank you for getting to this!

Results are in from the latest nighties, and looking good.  No 
identifiable differences between Xen 4.4 and 4.5

There are also no identified differences in the scale and performance tests.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:48:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15: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 1Y3Rh1-0006sr-MW; Tue, 23 Dec 2014 15:48:15 +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 1Y3Rh0-0006sc-A6
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 15:48:14 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C6/AF-02957-DBE89945; Tue, 23 Dec 2014 15:48:13 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419349693!11463004!1
X-Originating-IP: [131.111.8.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19451 invoked from network); 23 Dec 2014 15:48:13 -0000
Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk)
	(131.111.8.151)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 15:48:13 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from host86-133-74-101.range86-133.btcentralplus.com
	([86.133.74.101]:50853 helo=[192.168.1.98])
	by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1.2:DHE-RSA-AES128-SHA:128)
	id 1Y3Rgy-00016j-Z4 (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 23 Dec 2014 15:48:13 +0000
Message-ID: <54998E9D.7030805@citrix.com>
Date: Tue, 23 Dec 2014 15:47:41 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Chao Peng <chao.p.peng@linux.intel.com>, xen-devel@lists.xen.org
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
	<1419324880-13212-2-git-send-email-chao.p.peng@linux.intel.com>
In-Reply-To: <1419324880-13212-2-git-send-email-chao.p.peng@linux.intel.com>
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Jackson@eu.citrix.com, JBeulich@suse.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] x86: expose CMT L3 event mask to user
 space
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/12/2014 08:54, Chao Peng wrote:
> L3 event mask indicates the event types supported in host, including
> cache occupancy event as well as local/total memory bandwidth events
> for Memory Bandwidth Monitoring(MBM). Expose it so all these events
> can be monitored in user space.
>
> Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>   xen/arch/x86/sysctl.c       |    5 +++++
>   xen/include/public/sysctl.h |    1 +
>   2 files changed, 6 insertions(+)
>
> diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
> index 57ad992..0f08038 100644
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -157,6 +157,11 @@ long arch_do_sysctl(
>               sysctl->u.psr_cmt_op.u.data = (ret ? 0 : info.size);
>               break;
>           }
> +        case XEN_SYSCTL_PSR_CMT_get_l3_event_mask:
> +        {
> +            sysctl->u.psr_cmt_op.u.data = psr_cmt->l3.features;
> +            break;
> +        }
>           default:
>               sysctl->u.psr_cmt_op.u.data = 0;
>               ret = -ENOSYS;
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index b3713b3..8552dc6 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -641,6 +641,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
>   /* The L3 cache size is returned in KB unit */
>   #define XEN_SYSCTL_PSR_CMT_get_l3_cache_size         2
>   #define XEN_SYSCTL_PSR_CMT_enabled                   3
> +#define XEN_SYSCTL_PSR_CMT_get_l3_event_mask         4
>   struct xen_sysctl_psr_cmt_op {
>       uint32_t cmd;       /* IN: XEN_SYSCTL_PSR_CMT_* */
>       uint32_t flags;     /* padding variable, may be extended for future use */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:48:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15: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 1Y3Rgz-0006sQ-AL; Tue, 23 Dec 2014 15:48:13 +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 1Y3Rgy-0006s5-29
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 15:48:12 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	91/1F-02743-BBE89945; Tue, 23 Dec 2014 15:48:11 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-2.tower-27.messagelabs.com!1419349690!16901859!1
X-Originating-IP: [131.111.8.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28882 invoked from network); 23 Dec 2014 15:48:10 -0000
Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk)
	(131.111.8.151)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 15:48:10 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from host86-133-74-101.range86-133.btcentralplus.com
	([86.133.74.101]:50852 helo=[192.168.1.98])
	by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1.2:DHE-RSA-AES128-SHA:128)
	id 1Y3Rgw-00015Q-Y2 (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 23 Dec 2014 15:48:10 +0000
Message-ID: <54998E97.5070608@citrix.com>
Date: Tue, 23 Dec 2014 15:47:35 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Chao Peng <chao.p.peng@linux.intel.com>, xen-devel@lists.xen.org
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
In-Reply-To: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Jackson@eu.citrix.com, JBeulich@suse.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH 0/4] enable Memory Bandwidth Monitoring
 (MBM) for VMs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/12/2014 08:54, Chao Peng wrote:
> Intel Memory Bandwidth Monitoring(MBM) is a new hardware feature
> which builds on the CMT infrastructure to allow monitoring of system
> memory bandwidth. Event codes are provided to monitor both "total"
> and "local" bandwidth, meaning bandwidth over QPI and other external
> links can be monitored.
>
> For XEN, MBM is used to monitor memory bandwidth for VMs. Due to its
> dependency on CMT, the software also makes use of most of CMT codes.
> Actually, besides introducing two additional events and some cpuid
> feature bits, there are no extra changes compared to cache occupancy
> monitoring in CMT. Due to this, CMT should be enabled first to use
> this feature.
>
> For interface changes, the patch serial only introduces a new command
> "XEN_SYSCTL_PSR_CMT_get_l3_event_mask" which exposes MBM feature
> capability to user space and introduces two additional options for
> "xl psr-cmt-show":
> total_mem_bandwidth:     Show total memory bandwidth
> local_mem_bandwidth:     Show local memory bandwidth
>
> The usage flow keeps the same with CMT.
>
> Chao Peng (4):
>    x86: expose CMT L3 event mask to user space
>    tools: libxc: add routine to get CMT L3 event mask
>    tools: libxl: code preparation for MBM
>    tools: add total/local memory bandwith monitoring

Please can you add a note about MBM in the command line documentation, 
beside the CMT information.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:48:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15: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 1Y3Rgt-0006rq-Ii; Tue, 23 Dec 2014 15:48:07 +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 1Y3Rgq-0006rl-2b
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 15:48:06 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	27/32-25276-3BE89945; Tue, 23 Dec 2014 15:48:03 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-14.tower-21.messagelabs.com!1419349683!17544789!1
X-Originating-IP: [131.111.8.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9814 invoked from network); 23 Dec 2014 15:48:03 -0000
Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk)
	(131.111.8.151)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 15:48:03 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from host86-133-74-101.range86-133.btcentralplus.com
	([86.133.74.101]:50844 helo=[192.168.1.98])
	by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1.2:DHE-RSA-AES128-SHA:128)
	id 1Y3Rgo-0000xV-Yh (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 23 Dec 2014 15:48:02 +0000
Message-ID: <549985D4.1040509@citrix.com>
Date: Tue, 23 Dec 2014 15:10:12 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
	<20141216204900.GB11551@konrad-lan.dumpdata.com>
	<54944210.6050402@citrix.com>
	<20141219181447.GB7162@laptop.dumpdata.com>
In-Reply-To: <20141219181447.GB7162@laptop.dumpdata.com>
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/2014 18:14, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 19, 2014 at 03:19:44PM +0000, Andrew Cooper wrote:
>>
>> There will be another full nightly test happening tonight (based on c/s
>> 7e88c23 "libxl: Tell qemu to use raw format when using a tapdisk"), and
>> some stress and scale tests if time allows.
> Yeey! thank you for getting to this!

Results are in from the latest nighties, and looking good.  No 
identifiable differences between Xen 4.4 and 4.5

There are also no identified differences in the scale and performance tests.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:48:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15: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 1Y3Rgy-0006sD-Ur; Tue, 23 Dec 2014 15:48:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1Y3Rgx-0006s0-Bu
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 15:48:11 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	B9/53-07724-ABE89945; Tue, 23 Dec 2014 15:48:10 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-11.tower-31.messagelabs.com!1419349689!15452503!1
X-Originating-IP: [131.111.8.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19471 invoked from network); 23 Dec 2014 15:48:09 -0000
Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk)
	(131.111.8.151)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 15:48:09 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from host86-133-74-101.range86-133.btcentralplus.com
	([86.133.74.101]:50851 helo=[192.168.1.98])
	by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1.2:DHE-RSA-AES128-SHA:128)
	id 1Y3Rgt-0000zq-Z6 (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 23 Dec 2014 15:48:08 +0000
Message-ID: <54998E61.8020103@citrix.com>
Date: Tue, 23 Dec 2014 15:46:41 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Chao Peng <chao.p.peng@linux.intel.com>, xen-devel@lists.xen.org
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
	<1419324880-13212-3-git-send-email-chao.p.peng@linux.intel.com>
In-Reply-To: <1419324880-13212-3-git-send-email-chao.p.peng@linux.intel.com>
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Jackson@eu.citrix.com, JBeulich@suse.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH 2/4] tools: libxc: add routine to get CMT L3
 event 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 23/12/2014 08:54, Chao Peng wrote:
> This is the xc side wrapper for XEN_SYSCTL_PSR_CMT_get_l3_event_mask
> of XEN_SYSCTL_psr_cmt_op. Additional check for event id against value
> got from this routine is also added.
>
> Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> ---
>   tools/libxc/include/xenctrl.h |    1 +
>   tools/libxc/xc_psr.c          |   32 ++++++++++++++++++++++++++++++++
>   2 files changed, 33 insertions(+)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 0ad8b8d..96b357c 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2697,6 +2697,7 @@ int xc_psr_cmt_get_domain_rmid(xc_interface *xch, uint32_t domid,
>   int xc_psr_cmt_get_total_rmid(xc_interface *xch, uint32_t *total_rmid);
>   int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
>       uint32_t *upscaling_factor);
> +int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask);
>   int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
>       uint32_t *l3_cache_size);
>   int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
> diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
> index 872e6dc..94c8698 100644
> --- a/tools/libxc/xc_psr.c
> +++ b/tools/libxc/xc_psr.c
> @@ -112,6 +112,30 @@ int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
>       return rc;
>   }
>   
> +int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask)
> +{
> +    static int val = 0;
> +    int rc;
> +    DECLARE_SYSCTL;
> +
> +    if ( val )
> +    {
> +        *event_mask = val;
> +        return 0;
> +    }
> +
> +    sysctl.cmd = XEN_SYSCTL_psr_cmt_op;
> +    sysctl.u.psr_cmt_op.cmd =
> +        XEN_SYSCTL_PSR_CMT_get_l3_event_mask;
> +    sysctl.u.psr_cmt_op.flags = 0;
> +
> +    rc = xc_sysctl(xch, &sysctl);
> +    if ( !rc )
> +        val = *event_mask = sysctl.u.psr_cmt_op.u.data;
> +
> +    return rc;
> +}
> +
>   int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
>                                         uint32_t *l3_cache_size)
>   {
> @@ -144,6 +168,7 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
>       xc_resource_op_t op;
>       xc_resource_entry_t entries[2];
>       uint32_t evtid;
> +    uint32_t event_mask;
>       int rc;
>   
>       switch ( type )
> @@ -155,6 +180,13 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
>           return -1;
>       }
>   
> +    rc = xc_psr_cmt_get_l3_event_mask(xch, &event_mask);
> +    if ( rc < 0 )
> +        return rc;
> +
> +    if ( !(event_mask & (1 << (evtid - 1))) )
> +        return -1;
> +

This adds an extra hypercall on a common path to return a constant. As 
libxc is mostly a set of basic hypercall wrappers, I don't it should be 
validating its parameters like this.

The caller of xc_psr_cmt_get_data() must be aware of all the details, 
and whether certain events are supported or not.  I woud simply let the 
xc_resourse_op() fail (faulting on the wrmsr) if the caller passes a bad 
event id.

~Andrew

>       entries[0].u.cmd = XEN_RESOURCE_OP_MSR_WRITE;
>       entries[0].idx = MSR_IA32_CMT_EVTSEL;
>       entries[0].val = (uint64_t)rmid << 32 | evtid;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:48:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15: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 1Y3Rh1-0006sr-MW; Tue, 23 Dec 2014 15:48:15 +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 1Y3Rh0-0006sc-A6
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 15:48:14 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	C6/AF-02957-DBE89945; Tue, 23 Dec 2014 15:48:13 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419349693!11463004!1
X-Originating-IP: [131.111.8.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19451 invoked from network); 23 Dec 2014 15:48:13 -0000
Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk)
	(131.111.8.151)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 15:48:13 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from host86-133-74-101.range86-133.btcentralplus.com
	([86.133.74.101]:50853 helo=[192.168.1.98])
	by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1.2:DHE-RSA-AES128-SHA:128)
	id 1Y3Rgy-00016j-Z4 (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 23 Dec 2014 15:48:13 +0000
Message-ID: <54998E9D.7030805@citrix.com>
Date: Tue, 23 Dec 2014 15:47:41 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Chao Peng <chao.p.peng@linux.intel.com>, xen-devel@lists.xen.org
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
	<1419324880-13212-2-git-send-email-chao.p.peng@linux.intel.com>
In-Reply-To: <1419324880-13212-2-git-send-email-chao.p.peng@linux.intel.com>
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Jackson@eu.citrix.com, JBeulich@suse.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] x86: expose CMT L3 event mask to user
 space
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/12/2014 08:54, Chao Peng wrote:
> L3 event mask indicates the event types supported in host, including
> cache occupancy event as well as local/total memory bandwidth events
> for Memory Bandwidth Monitoring(MBM). Expose it so all these events
> can be monitored in user space.
>
> Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>   xen/arch/x86/sysctl.c       |    5 +++++
>   xen/include/public/sysctl.h |    1 +
>   2 files changed, 6 insertions(+)
>
> diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
> index 57ad992..0f08038 100644
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -157,6 +157,11 @@ long arch_do_sysctl(
>               sysctl->u.psr_cmt_op.u.data = (ret ? 0 : info.size);
>               break;
>           }
> +        case XEN_SYSCTL_PSR_CMT_get_l3_event_mask:
> +        {
> +            sysctl->u.psr_cmt_op.u.data = psr_cmt->l3.features;
> +            break;
> +        }
>           default:
>               sysctl->u.psr_cmt_op.u.data = 0;
>               ret = -ENOSYS;
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index b3713b3..8552dc6 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -641,6 +641,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
>   /* The L3 cache size is returned in KB unit */
>   #define XEN_SYSCTL_PSR_CMT_get_l3_cache_size         2
>   #define XEN_SYSCTL_PSR_CMT_enabled                   3
> +#define XEN_SYSCTL_PSR_CMT_get_l3_event_mask         4
>   struct xen_sysctl_psr_cmt_op {
>       uint32_t cmd;       /* IN: XEN_SYSCTL_PSR_CMT_* */
>       uint32_t flags;     /* padding variable, may be extended for future use */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:48:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15: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 1Y3Rgy-0006sD-Ur; Tue, 23 Dec 2014 15:48:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1Y3Rgx-0006s0-Bu
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 15:48:11 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	B9/53-07724-ABE89945; Tue, 23 Dec 2014 15:48:10 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-11.tower-31.messagelabs.com!1419349689!15452503!1
X-Originating-IP: [131.111.8.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19471 invoked from network); 23 Dec 2014 15:48:09 -0000
Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk)
	(131.111.8.151)
	by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 15:48:09 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from host86-133-74-101.range86-133.btcentralplus.com
	([86.133.74.101]:50851 helo=[192.168.1.98])
	by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1.2:DHE-RSA-AES128-SHA:128)
	id 1Y3Rgt-0000zq-Z6 (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 23 Dec 2014 15:48:08 +0000
Message-ID: <54998E61.8020103@citrix.com>
Date: Tue, 23 Dec 2014 15:46:41 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Chao Peng <chao.p.peng@linux.intel.com>, xen-devel@lists.xen.org
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
	<1419324880-13212-3-git-send-email-chao.p.peng@linux.intel.com>
In-Reply-To: <1419324880-13212-3-git-send-email-chao.p.peng@linux.intel.com>
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Jackson@eu.citrix.com, JBeulich@suse.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH 2/4] tools: libxc: add routine to get CMT L3
 event 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 23/12/2014 08:54, Chao Peng wrote:
> This is the xc side wrapper for XEN_SYSCTL_PSR_CMT_get_l3_event_mask
> of XEN_SYSCTL_psr_cmt_op. Additional check for event id against value
> got from this routine is also added.
>
> Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> ---
>   tools/libxc/include/xenctrl.h |    1 +
>   tools/libxc/xc_psr.c          |   32 ++++++++++++++++++++++++++++++++
>   2 files changed, 33 insertions(+)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 0ad8b8d..96b357c 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2697,6 +2697,7 @@ int xc_psr_cmt_get_domain_rmid(xc_interface *xch, uint32_t domid,
>   int xc_psr_cmt_get_total_rmid(xc_interface *xch, uint32_t *total_rmid);
>   int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
>       uint32_t *upscaling_factor);
> +int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask);
>   int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
>       uint32_t *l3_cache_size);
>   int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
> diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
> index 872e6dc..94c8698 100644
> --- a/tools/libxc/xc_psr.c
> +++ b/tools/libxc/xc_psr.c
> @@ -112,6 +112,30 @@ int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
>       return rc;
>   }
>   
> +int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask)
> +{
> +    static int val = 0;
> +    int rc;
> +    DECLARE_SYSCTL;
> +
> +    if ( val )
> +    {
> +        *event_mask = val;
> +        return 0;
> +    }
> +
> +    sysctl.cmd = XEN_SYSCTL_psr_cmt_op;
> +    sysctl.u.psr_cmt_op.cmd =
> +        XEN_SYSCTL_PSR_CMT_get_l3_event_mask;
> +    sysctl.u.psr_cmt_op.flags = 0;
> +
> +    rc = xc_sysctl(xch, &sysctl);
> +    if ( !rc )
> +        val = *event_mask = sysctl.u.psr_cmt_op.u.data;
> +
> +    return rc;
> +}
> +
>   int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
>                                         uint32_t *l3_cache_size)
>   {
> @@ -144,6 +168,7 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
>       xc_resource_op_t op;
>       xc_resource_entry_t entries[2];
>       uint32_t evtid;
> +    uint32_t event_mask;
>       int rc;
>   
>       switch ( type )
> @@ -155,6 +180,13 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
>           return -1;
>       }
>   
> +    rc = xc_psr_cmt_get_l3_event_mask(xch, &event_mask);
> +    if ( rc < 0 )
> +        return rc;
> +
> +    if ( !(event_mask & (1 << (evtid - 1))) )
> +        return -1;
> +

This adds an extra hypercall on a common path to return a constant. As 
libxc is mostly a set of basic hypercall wrappers, I don't it should be 
validating its parameters like this.

The caller of xc_psr_cmt_get_data() must be aware of all the details, 
and whether certain events are supported or not.  I woud simply let the 
xc_resourse_op() fail (faulting on the wrmsr) if the caller passes a bad 
event id.

~Andrew

>       entries[0].u.cmd = XEN_RESOURCE_OP_MSR_WRITE;
>       entries[0].idx = MSR_IA32_CMT_EVTSEL;
>       entries[0].val = (uint64_t)rmid << 32 | evtid;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 15:48:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 15: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 1Y3Rgz-0006sQ-AL; Tue, 23 Dec 2014 15:48:13 +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 1Y3Rgy-0006s5-29
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 15:48:12 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	91/1F-02743-BBE89945; Tue, 23 Dec 2014 15:48:11 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-2.tower-27.messagelabs.com!1419349690!16901859!1
X-Originating-IP: [131.111.8.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28882 invoked from network); 23 Dec 2014 15:48:10 -0000
Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk)
	(131.111.8.151)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2014 15:48:10 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from host86-133-74-101.range86-133.btcentralplus.com
	([86.133.74.101]:50852 helo=[192.168.1.98])
	by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1.2:DHE-RSA-AES128-SHA:128)
	id 1Y3Rgw-00015Q-Y2 (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Tue, 23 Dec 2014 15:48:10 +0000
Message-ID: <54998E97.5070608@citrix.com>
Date: Tue, 23 Dec 2014 15:47:35 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Chao Peng <chao.p.peng@linux.intel.com>, xen-devel@lists.xen.org
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
In-Reply-To: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Jackson@eu.citrix.com, JBeulich@suse.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH 0/4] enable Memory Bandwidth Monitoring
 (MBM) for VMs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/12/2014 08:54, Chao Peng wrote:
> Intel Memory Bandwidth Monitoring(MBM) is a new hardware feature
> which builds on the CMT infrastructure to allow monitoring of system
> memory bandwidth. Event codes are provided to monitor both "total"
> and "local" bandwidth, meaning bandwidth over QPI and other external
> links can be monitored.
>
> For XEN, MBM is used to monitor memory bandwidth for VMs. Due to its
> dependency on CMT, the software also makes use of most of CMT codes.
> Actually, besides introducing two additional events and some cpuid
> feature bits, there are no extra changes compared to cache occupancy
> monitoring in CMT. Due to this, CMT should be enabled first to use
> this feature.
>
> For interface changes, the patch serial only introduces a new command
> "XEN_SYSCTL_PSR_CMT_get_l3_event_mask" which exposes MBM feature
> capability to user space and introduces two additional options for
> "xl psr-cmt-show":
> total_mem_bandwidth:     Show total memory bandwidth
> local_mem_bandwidth:     Show local memory bandwidth
>
> The usage flow keeps the same with CMT.
>
> Chao Peng (4):
>    x86: expose CMT L3 event mask to user space
>    tools: libxc: add routine to get CMT L3 event mask
>    tools: libxl: code preparation for MBM
>    tools: add total/local memory bandwith monitoring

Please can you add a note about MBM in the command line documentation, 
beside the CMT information.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 18:57:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 18: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 1Y3UdQ-00034q-AU; Tue, 23 Dec 2014 18:56: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 1Y3UdO-00034j-Qi
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 18:56:43 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	3A/F4-02702-AEAB9945; Tue, 23 Dec 2014 18:56:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1419360999!16892647!1
X-Originating-IP: [66.165.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 22983 invoked from network); 23 Dec 2014 18:56:40 -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;
	23 Dec 2014 18:56:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,633,1413244800"; d="scan'208";a="208009722"
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.210.2; Tue, 23 Dec 2014 13:56: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 1Y3UdK-00006w-0z;
	Tue, 23 Dec 2014 18:56:38 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3UdJ-0001xH-RZ;
	Tue, 23 Dec 2014 18:56:37 +0000
Date: Tue, 23 Dec 2014 18:56:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32595-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] 32595: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32595 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32595/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32564
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 32564

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-xl          10 migrate-support-check        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-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-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-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

version targeted for testing:
 linux                aa39477b5692611b91ac9455ae588738852b3f60
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

------------------------------------------------------------
People who touched revisions under test:
  Alex Chen <alex.chen@huawei.com>
  Davidlohr Bueso <dave@stgolabs.net>
  Joe Thornber <ejt@redhat.com>
  Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Marc Dionne <marc.c.dionne@gmail.com>
  Marc Dionne <marc.dionne@your-file-system.com>
  Mike Snitzer <snitzer@redhat.com>
  zhendong chen <alex.chen@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    
 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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 aa39477b5692611b91ac9455ae588738852b3f60
Merge: 48ec833 5164bec
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Dec 22 14:47:17 2014 -0800

    Merge tag 'dm-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
    
    Pull device mapper fixes from Mike Snitzer:
     "Thre stable fixes and one fix for a regression introduced during 3.19
      merge:
    
       - Fix inability to discard used space when the thin-pool target is in
         out-of-data-space mode and also transition the thin-pool back to
         write mode once free space is made available.
    
       - Fix DM core bio-based end_io bug that prevented proper
         post-processing of the error code returned from the block layer.
    
       - Fix crash in DM thin-pool due to thin device being added to the
         pool's active_thins list before properly initializing the thin
         device's refcount"
    
    * tag 'dm-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
      dm: fix missed error code if .end_io isn't implemented by target_type
      dm thin: fix crash by initializing thin device's refcount and completion earlier
      dm thin: fix missing out-of-data-space to write mode transition if blocks are released
      dm thin: fix inability to discard blocks when in out-of-data-space mode

commit 48ec833b7851438f02164ea846852ce4696f09ad
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Mon Dec 22 21:01:54 2014 +0200

    Revert "mm/memory.c: share the i_mmap_rwsem"
    
    This reverts commit c8475d144abb1e62958cc5ec281d2a9e161c1946.
    
    There are several[1][2] of bug reports which points to this commit as potential
    cause[3].
    
    Let's revert it until we figure out what's going on.
    
    [1] https://lkml.org/lkml/2014/11/14/342
    [2] https://lkml.org/lkml/2014/12/22/213
    [3] https://lkml.org/lkml/2014/12/9/741
    
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Acked-by: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 5164bece1673cdf04782f8ed3fba70743700f5da
Author: zhendong chen <alex.chen@huawei.com>
Date:   Wed Dec 17 14:37:04 2014 +0800

    dm: fix missed error code if .end_io isn't implemented by target_type
    
    In bio-based DM's clone_endio(), when target_type doesn't implement
    .end_io (e.g. linear) r will be always be initialized 0.  So if a
    WRITE SAME bio fails WRITE SAME will not be disabled as intended.
    
    Fix this by initializing r to error, rather than 0, in clone_endio().
    
    Signed-off-by: Alex Chen <alex.chen@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Fixes: 7eee4ae2db ("dm: disable WRITE SAME if it fails")
    Cc: stable@vger.kernel.org

commit 2b94e8960cc3f225dec058f27570505351f4bc13
Author: Marc Dionne <marc.c.dionne@gmail.com>
Date:   Wed Dec 17 07:59:59 2014 -0500

    dm thin: fix crash by initializing thin device's refcount and completion earlier
    
    Commit 80e96c5484be ("dm thin: do not allow thin device activation
    while pool is suspended") delayed the initialization of a new thin
    device's refcount and completion until after this new thin was added
    to the pool's active_thins list and the pool lock is released.  This
    opens a race with a worker thread that walks the list and calls
    thin_get/put, noticing that the refcount goes to 0 and calling
    complete, freezing up the system and giving the oops below:
    
     kernel: BUG: unable to handle kernel NULL pointer dereference at           (null)
     kernel: IP: [<ffffffff810d360b>] __wake_up_common+0x2b/0x90
    
     kernel: Call Trace:
     kernel: [<ffffffff810d3683>] __wake_up_locked+0x13/0x20
     kernel: [<ffffffff810d3dc7>] complete+0x37/0x50
     kernel: [<ffffffffa0595c50>] thin_put+0x20/0x30 [dm_thin_pool]
     kernel: [<ffffffffa059aab7>] do_worker+0x667/0x870 [dm_thin_pool]
     kernel: [<ffffffff816a8a4c>] ? __schedule+0x3ac/0x9a0
     kernel: [<ffffffff810b1aef>] process_one_work+0x14f/0x400
     kernel: [<ffffffff810b206b>] worker_thread+0x6b/0x490
     kernel: [<ffffffff810b2000>] ? rescuer_thread+0x260/0x260
     kernel: [<ffffffff810b6a7b>] kthread+0xdb/0x100
     kernel: [<ffffffff810b69a0>] ? kthread_create_on_node+0x170/0x170
     kernel: [<ffffffff816ad7ec>] ret_from_fork+0x7c/0xb0
     kernel: [<ffffffff810b69a0>] ? kthread_create_on_node+0x170/0x170
    
    Set the thin device's initial refcount and initialize the completion
    before adding it to the pool's active_thins list in thin_ctr().
    
    Signed-off-by: Marc Dionne <marc.dionne@your-file-system.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 2c43fd26e46734430122b8d2ad3024bb532df3ef
Author: Joe Thornber <ejt@redhat.com>
Date:   Thu Dec 11 11:12:19 2014 +0000

    dm thin: fix missing out-of-data-space to write mode transition if blocks are released
    
    Discard bios and thin device deletion have the potential to release data
    blocks.  If the thin-pool is in out-of-data-space mode, and blocks were
    released, transition the thin-pool back to full write mode.
    
    The correct time to do this is just after the thin-pool metadata commit.
    It cannot be done before the commit because the space maps will not
    allow immediate reuse of the data blocks in case there's a rollback
    following power failure.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org

commit 45ec9bd0fd7abf8705e7cf12205ff69fe9d51181
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Dec 10 17:06:57 2014 +0000

    dm thin: fix inability to discard blocks when in out-of-data-space mode
    
    When the pool was in PM_OUT_OF_SPACE mode its process_prepared_discard
    function pointer was incorrectly being set to
    process_prepared_discard_passdown rather than process_prepared_discard.
    
    This incorrect function pointer meant the discard was being passed down,
    but not effecting the mapping.  As such any discard that was issued, in
    an attempt to reclaim blocks, would not successfully free data space.
    
    Reported-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 18:57:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 18: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 1Y3UdQ-00034q-AU; Tue, 23 Dec 2014 18:56: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 1Y3UdO-00034j-Qi
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 18:56:43 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	3A/F4-02702-AEAB9945; Tue, 23 Dec 2014 18:56:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1419360999!16892647!1
X-Originating-IP: [66.165.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 22983 invoked from network); 23 Dec 2014 18:56:40 -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;
	23 Dec 2014 18:56:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,633,1413244800"; d="scan'208";a="208009722"
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.210.2; Tue, 23 Dec 2014 13:56: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 1Y3UdK-00006w-0z;
	Tue, 23 Dec 2014 18:56:38 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3UdJ-0001xH-RZ;
	Tue, 23 Dec 2014 18:56:37 +0000
Date: Tue, 23 Dec 2014 18:56:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32595-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] 32595: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32595 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32595/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 32564
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 32564

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-xl          10 migrate-support-check        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-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-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-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

version targeted for testing:
 linux                aa39477b5692611b91ac9455ae588738852b3f60
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

------------------------------------------------------------
People who touched revisions under test:
  Alex Chen <alex.chen@huawei.com>
  Davidlohr Bueso <dave@stgolabs.net>
  Joe Thornber <ejt@redhat.com>
  Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Marc Dionne <marc.c.dionne@gmail.com>
  Marc Dionne <marc.dionne@your-file-system.com>
  Mike Snitzer <snitzer@redhat.com>
  zhendong chen <alex.chen@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    
 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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 aa39477b5692611b91ac9455ae588738852b3f60
Merge: 48ec833 5164bec
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Dec 22 14:47:17 2014 -0800

    Merge tag 'dm-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
    
    Pull device mapper fixes from Mike Snitzer:
     "Thre stable fixes and one fix for a regression introduced during 3.19
      merge:
    
       - Fix inability to discard used space when the thin-pool target is in
         out-of-data-space mode and also transition the thin-pool back to
         write mode once free space is made available.
    
       - Fix DM core bio-based end_io bug that prevented proper
         post-processing of the error code returned from the block layer.
    
       - Fix crash in DM thin-pool due to thin device being added to the
         pool's active_thins list before properly initializing the thin
         device's refcount"
    
    * tag 'dm-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
      dm: fix missed error code if .end_io isn't implemented by target_type
      dm thin: fix crash by initializing thin device's refcount and completion earlier
      dm thin: fix missing out-of-data-space to write mode transition if blocks are released
      dm thin: fix inability to discard blocks when in out-of-data-space mode

commit 48ec833b7851438f02164ea846852ce4696f09ad
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Mon Dec 22 21:01:54 2014 +0200

    Revert "mm/memory.c: share the i_mmap_rwsem"
    
    This reverts commit c8475d144abb1e62958cc5ec281d2a9e161c1946.
    
    There are several[1][2] of bug reports which points to this commit as potential
    cause[3].
    
    Let's revert it until we figure out what's going on.
    
    [1] https://lkml.org/lkml/2014/11/14/342
    [2] https://lkml.org/lkml/2014/12/22/213
    [3] https://lkml.org/lkml/2014/12/9/741
    
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Acked-by: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 5164bece1673cdf04782f8ed3fba70743700f5da
Author: zhendong chen <alex.chen@huawei.com>
Date:   Wed Dec 17 14:37:04 2014 +0800

    dm: fix missed error code if .end_io isn't implemented by target_type
    
    In bio-based DM's clone_endio(), when target_type doesn't implement
    .end_io (e.g. linear) r will be always be initialized 0.  So if a
    WRITE SAME bio fails WRITE SAME will not be disabled as intended.
    
    Fix this by initializing r to error, rather than 0, in clone_endio().
    
    Signed-off-by: Alex Chen <alex.chen@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Fixes: 7eee4ae2db ("dm: disable WRITE SAME if it fails")
    Cc: stable@vger.kernel.org

commit 2b94e8960cc3f225dec058f27570505351f4bc13
Author: Marc Dionne <marc.c.dionne@gmail.com>
Date:   Wed Dec 17 07:59:59 2014 -0500

    dm thin: fix crash by initializing thin device's refcount and completion earlier
    
    Commit 80e96c5484be ("dm thin: do not allow thin device activation
    while pool is suspended") delayed the initialization of a new thin
    device's refcount and completion until after this new thin was added
    to the pool's active_thins list and the pool lock is released.  This
    opens a race with a worker thread that walks the list and calls
    thin_get/put, noticing that the refcount goes to 0 and calling
    complete, freezing up the system and giving the oops below:
    
     kernel: BUG: unable to handle kernel NULL pointer dereference at           (null)
     kernel: IP: [<ffffffff810d360b>] __wake_up_common+0x2b/0x90
    
     kernel: Call Trace:
     kernel: [<ffffffff810d3683>] __wake_up_locked+0x13/0x20
     kernel: [<ffffffff810d3dc7>] complete+0x37/0x50
     kernel: [<ffffffffa0595c50>] thin_put+0x20/0x30 [dm_thin_pool]
     kernel: [<ffffffffa059aab7>] do_worker+0x667/0x870 [dm_thin_pool]
     kernel: [<ffffffff816a8a4c>] ? __schedule+0x3ac/0x9a0
     kernel: [<ffffffff810b1aef>] process_one_work+0x14f/0x400
     kernel: [<ffffffff810b206b>] worker_thread+0x6b/0x490
     kernel: [<ffffffff810b2000>] ? rescuer_thread+0x260/0x260
     kernel: [<ffffffff810b6a7b>] kthread+0xdb/0x100
     kernel: [<ffffffff810b69a0>] ? kthread_create_on_node+0x170/0x170
     kernel: [<ffffffff816ad7ec>] ret_from_fork+0x7c/0xb0
     kernel: [<ffffffff810b69a0>] ? kthread_create_on_node+0x170/0x170
    
    Set the thin device's initial refcount and initialize the completion
    before adding it to the pool's active_thins list in thin_ctr().
    
    Signed-off-by: Marc Dionne <marc.dionne@your-file-system.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 2c43fd26e46734430122b8d2ad3024bb532df3ef
Author: Joe Thornber <ejt@redhat.com>
Date:   Thu Dec 11 11:12:19 2014 +0000

    dm thin: fix missing out-of-data-space to write mode transition if blocks are released
    
    Discard bios and thin device deletion have the potential to release data
    blocks.  If the thin-pool is in out-of-data-space mode, and blocks were
    released, transition the thin-pool back to full write mode.
    
    The correct time to do this is just after the thin-pool metadata commit.
    It cannot be done before the commit because the space maps will not
    allow immediate reuse of the data blocks in case there's a rollback
    following power failure.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org

commit 45ec9bd0fd7abf8705e7cf12205ff69fe9d51181
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Dec 10 17:06:57 2014 +0000

    dm thin: fix inability to discard blocks when in out-of-data-space mode
    
    When the pool was in PM_OUT_OF_SPACE mode its process_prepared_discard
    function pointer was incorrectly being set to
    process_prepared_discard_passdown rather than process_prepared_discard.
    
    This incorrect function pointer meant the discard was being passed down,
    but not effecting the mapping.  As such any discard that was issued, in
    an attempt to reclaim blocks, would not successfully free data space.
    
    Reported-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 23 22:12:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 22:12:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3XgI-0006lx-8O; Tue, 23 Dec 2014 22:11:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3XgG-0006go-ON
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 22:11:52 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	60/EB-29352-7A8E9945; Tue, 23 Dec 2014 22:11:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1419372709!14966775!1
X-Originating-IP: [66.165.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 16874 invoked from network); 23 Dec 2014 22:11:50 -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;
	23 Dec 2014 22:11:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,634,1413244800"; d="scan'208";a="207569530"
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.210.2; Tue, 23 Dec 2014 17:11: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 1Y3XgB-00013D-Da;
	Tue, 23 Dec 2014 22:11:47 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3XgA-0005ss-Jx;
	Tue, 23 Dec 2014 22:11:47 +0000
Date: Tue, 23 Dec 2014 22:11:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32597-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] 32597: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32597 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32597/

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 32584
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 32584
 test-amd64-amd64-xl-sedf-pin  7 debian-install     fail in 32584 pass in 32597
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail in 32584 pass in 32597
 test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail in 32584 pass in 32597

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels 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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-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 34929 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 Dec 23 22:12:29 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Dec 2014 22:12:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3XgI-0006lx-8O; Tue, 23 Dec 2014 22:11:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3XgG-0006go-ON
	for xen-devel@lists.xensource.com; Tue, 23 Dec 2014 22:11:52 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	60/EB-29352-7A8E9945; Tue, 23 Dec 2014 22:11:51 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1419372709!14966775!1
X-Originating-IP: [66.165.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 16874 invoked from network); 23 Dec 2014 22:11:50 -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;
	23 Dec 2014 22:11:50 -0000
X-IronPort-AV: E=Sophos;i="5.07,634,1413244800"; d="scan'208";a="207569530"
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.210.2; Tue, 23 Dec 2014 17:11: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 1Y3XgB-00013D-Da;
	Tue, 23 Dec 2014 22:11:47 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3XgA-0005ss-Jx;
	Tue, 23 Dec 2014 22:11:47 +0000
Date: Tue, 23 Dec 2014 22:11:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32597-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] 32597: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32597 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32597/

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 32584
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 32584
 test-amd64-amd64-xl-sedf-pin  7 debian-install     fail in 32584 pass in 32597
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail in 32584 pass in 32597
 test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail in 32584 pass in 32597

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels 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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-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 34929 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 Dec 24 00:04:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 00:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3ZQG-0000z5-Uj; Wed, 24 Dec 2014 00:03:28 +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 1Y3ZQE-0000z0-Hj
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 00:03:26 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DA/39-09842-DC20A945; Wed, 24 Dec 2014 00:03:25 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419379404!17587167!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17435 invoked from network); 24 Dec 2014 00:03:24 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-7.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Dec 2014 00:03:24 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1Y3ZQB-0005Fl-DE
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 01:03:23 +0100
Received: from c-75-65-216-69.hsd1.la.comcast.net ([75.65.216.69])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Wed, 24 Dec 2014 01:03:23 +0100
Received: from kantras by c-75-65-216-69.hsd1.la.comcast.net with local
	(Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Wed, 24 Dec 2014 01:03:23 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: David Sutton <kantras@gmail.com>
Date: Wed, 24 Dec 2014 00:03:11 +0000 (UTC)
Lines: 88
Message-ID: <loom.20141224T005230-410@post.gmane.org>
References: <CAKGZkHvCai_PwNyTpH10-2o4wT+-2+HNCwW-yH_kEeVHXXsjHA@mail.gmail.com>
Mime-Version: 1.0
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 75.65.216.69 (Mozilla/5.0 (Windows NT 6.1;
	WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95
	Safari/537.36)
Subject: Re: [Xen-devel] [Testday] Arch Linux Test report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julian Sivertsen <julian.sivertsen+xen <at> gmail.com> writes:

> 
> == Hardware ==
> HP DL380 G5 (2x Intel Xeon 5130)
> 
> == Dom0 ==
> Arch Linux 64-bit
> 
> == Functionality tested ==
> Building xen 4.5 RC4 from the tarball, installing it and booting it up
> with Arch Linux as the Dom0.
> 
> == Comments ==
> Xen support on Arch Linux needs a bit of love. Nummerous problems
> getting the build to work properly. These issues mainly concerrns
> building and installing the xen-4.5-RC4 tarball on Arch Linux. They
> would all be solved by the package maintainer of xen, but still 
presents
> a challange for anyone who would want to build xen outside of the
> Arch Linux package system. More test reports may follow once I get
> guests to run on the system.
> 
> == Issues ===
> Brief: Invalid FETCHER by ./configure
> Importance: nuisance
> Location: xen
> Workaround: Install wget and reconfigure
> The m4/fetcher.m4 script checks for the precence of wget before 
falling
> back to "ftp -o". On Arch Linux curl is shipped and ftp does not 
support
> the -o option. Resulting in the build failing when downloading zlib.
>
The xen package under AUR already works around this issue by downloading 
all the necessary supporting tar files itself - I preferred this method 
as it allows me to make use of file checkAsums to ensure that the 
downloads all completed correctly. If a different file were to become 
added that it wasn't aware of, the package has 'wget' listed as a build 
dependency.

As was already mentioned by Olaf, that would be a documentation issue as 
it should list it as an explicit dependency.
>
> Brief: Grub script does not generate any entries for xen
> Importance: low
> Location: grub
> Workaround: `echo CONFIG_XEN_DOM0=y > /boot/config-linux`
> The 20_linux_xen grub configuration helper script shipped in the grub
> package in Arch Linux does not generate any entries for xen after it 
is
> installed as it expects a kernel config file to be present. It checks
> for CONFIG_XEN_DOM0=y in this kernel config file to dertermine whether
> or not the kernel in question supports being runned as a DOM0 under 
xen.
> Additionally the variable ${alt_version} is used before it is defined.
> Both of these issues are present in upstream grub.
>
As we discussed on the xentest irc channel that day, there is already an 
updated configuration file included in the xen AUR package that gets 
installed and will work for grub2. 
>
> Brief: error: context option is invalid
> Importance: medium
> location: unknown
> Workaround: Edit out ",context=${...}" in var-lib-xenstored.mount
> The context option is not understood somewhere between mount and the
> kernel. Possibly SELinux specific, since the default Arch Linux kernel
> does not ship with it.
> 
> Brief: libxenctrl.so.4.5 not found
> Importance: low
> Location: probably Arch Linux
> Workaround: `echo /usr/local/lib > /etc/ld.so.conf.d/xen.cnf; 
ldconfig`
> Something about the library path is messed up, as oxenstored fails 
when
> launched by systemd. It needs the shared library libxenctrl.so.4.5 
which
> is located in the /usr/local/lib folder, but doesn't find it.
> 
> Julian Sivertsen
> 

Regards,

  David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 00:04:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 00:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3ZQG-0000z5-Uj; Wed, 24 Dec 2014 00:03:28 +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 1Y3ZQE-0000z0-Hj
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 00:03:26 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DA/39-09842-DC20A945; Wed, 24 Dec 2014 00:03:25 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419379404!17587167!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17435 invoked from network); 24 Dec 2014 00:03:24 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-7.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Dec 2014 00:03:24 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1Y3ZQB-0005Fl-DE
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 01:03:23 +0100
Received: from c-75-65-216-69.hsd1.la.comcast.net ([75.65.216.69])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Wed, 24 Dec 2014 01:03:23 +0100
Received: from kantras by c-75-65-216-69.hsd1.la.comcast.net with local
	(Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Wed, 24 Dec 2014 01:03:23 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: David Sutton <kantras@gmail.com>
Date: Wed, 24 Dec 2014 00:03:11 +0000 (UTC)
Lines: 88
Message-ID: <loom.20141224T005230-410@post.gmane.org>
References: <CAKGZkHvCai_PwNyTpH10-2o4wT+-2+HNCwW-yH_kEeVHXXsjHA@mail.gmail.com>
Mime-Version: 1.0
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 75.65.216.69 (Mozilla/5.0 (Windows NT 6.1;
	WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95
	Safari/537.36)
Subject: Re: [Xen-devel] [Testday] Arch Linux Test report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julian Sivertsen <julian.sivertsen+xen <at> gmail.com> writes:

> 
> == Hardware ==
> HP DL380 G5 (2x Intel Xeon 5130)
> 
> == Dom0 ==
> Arch Linux 64-bit
> 
> == Functionality tested ==
> Building xen 4.5 RC4 from the tarball, installing it and booting it up
> with Arch Linux as the Dom0.
> 
> == Comments ==
> Xen support on Arch Linux needs a bit of love. Nummerous problems
> getting the build to work properly. These issues mainly concerrns
> building and installing the xen-4.5-RC4 tarball on Arch Linux. They
> would all be solved by the package maintainer of xen, but still 
presents
> a challange for anyone who would want to build xen outside of the
> Arch Linux package system. More test reports may follow once I get
> guests to run on the system.
> 
> == Issues ===
> Brief: Invalid FETCHER by ./configure
> Importance: nuisance
> Location: xen
> Workaround: Install wget and reconfigure
> The m4/fetcher.m4 script checks for the precence of wget before 
falling
> back to "ftp -o". On Arch Linux curl is shipped and ftp does not 
support
> the -o option. Resulting in the build failing when downloading zlib.
>
The xen package under AUR already works around this issue by downloading 
all the necessary supporting tar files itself - I preferred this method 
as it allows me to make use of file checkAsums to ensure that the 
downloads all completed correctly. If a different file were to become 
added that it wasn't aware of, the package has 'wget' listed as a build 
dependency.

As was already mentioned by Olaf, that would be a documentation issue as 
it should list it as an explicit dependency.
>
> Brief: Grub script does not generate any entries for xen
> Importance: low
> Location: grub
> Workaround: `echo CONFIG_XEN_DOM0=y > /boot/config-linux`
> The 20_linux_xen grub configuration helper script shipped in the grub
> package in Arch Linux does not generate any entries for xen after it 
is
> installed as it expects a kernel config file to be present. It checks
> for CONFIG_XEN_DOM0=y in this kernel config file to dertermine whether
> or not the kernel in question supports being runned as a DOM0 under 
xen.
> Additionally the variable ${alt_version} is used before it is defined.
> Both of these issues are present in upstream grub.
>
As we discussed on the xentest irc channel that day, there is already an 
updated configuration file included in the xen AUR package that gets 
installed and will work for grub2. 
>
> Brief: error: context option is invalid
> Importance: medium
> location: unknown
> Workaround: Edit out ",context=${...}" in var-lib-xenstored.mount
> The context option is not understood somewhere between mount and the
> kernel. Possibly SELinux specific, since the default Arch Linux kernel
> does not ship with it.
> 
> Brief: libxenctrl.so.4.5 not found
> Importance: low
> Location: probably Arch Linux
> Workaround: `echo /usr/local/lib > /etc/ld.so.conf.d/xen.cnf; 
ldconfig`
> Something about the library path is messed up, as oxenstored fails 
when
> launched by systemd. It needs the shared library libxenctrl.so.4.5 
which
> is located in the /usr/local/lib folder, but doesn't find it.
> 
> Julian Sivertsen
> 

Regards,

  David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 01:07:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 01: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 1Y3aP6-0006FL-FX; Wed, 24 Dec 2014 01:06: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 1Y3aP4-0006FG-U2
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 01:06:19 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	42/D8-18267-A811A945; Wed, 24 Dec 2014 01:06:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419383175!15539504!1
X-Originating-IP: [66.165.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 10702 invoked from network); 24 Dec 2014 01:06:17 -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 Dec 2014 01:06:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,635,1413244800"; d="scan'208";a="208113181"
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.210.2; Tue, 23 Dec 2014 20:06: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 1Y3aP0-0001tr-3Y;
	Wed, 24 Dec 2014 01:06:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3aOz-00033x-DC;
	Wed, 24 Dec 2014 01:06:13 +0000
Date: Wed, 24 Dec 2014 01:06:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32598-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] 32598: 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 32598 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32598/

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 32585

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-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-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-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-qemut-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-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714
baseline version:
 qemuu                c95f3901b4ead79f3fe2c641fda7d2c70fc84c72

------------------------------------------------------------
People who touched revisions under test:
  Alex Zuepke <alexander.zuepke@hs-rm.de>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Gonglei <arei.gonglei@huawei.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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=7e58e2ac7778cca3234c33387e49577bb7732714
+ . 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 7e58e2ac7778cca3234c33387e49577bb7732714
+ branch=qemu-mainline
+ revision=7e58e2ac7778cca3234c33387e49577bb7732714
+ . 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 7e58e2ac7778cca3234c33387e49577bb7732714:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   c95f390..7e58e2a  7e58e2ac7778cca3234c33387e49577bb7732714 -> 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 Dec 24 01:07:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 01: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 1Y3aP6-0006FL-FX; Wed, 24 Dec 2014 01:06: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 1Y3aP4-0006FG-U2
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 01:06:19 +0000
Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id
	42/D8-18267-A811A945; Wed, 24 Dec 2014 01:06:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419383175!15539504!1
X-Originating-IP: [66.165.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 10702 invoked from network); 24 Dec 2014 01:06:17 -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 Dec 2014 01:06:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,635,1413244800"; d="scan'208";a="208113181"
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.210.2; Tue, 23 Dec 2014 20:06: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 1Y3aP0-0001tr-3Y;
	Wed, 24 Dec 2014 01:06:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3aOz-00033x-DC;
	Wed, 24 Dec 2014 01:06:13 +0000
Date: Wed, 24 Dec 2014 01:06:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32598-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] 32598: 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 32598 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32598/

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 32585

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-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-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-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-qemut-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-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714
baseline version:
 qemuu                c95f3901b4ead79f3fe2c641fda7d2c70fc84c72

------------------------------------------------------------
People who touched revisions under test:
  Alex Zuepke <alexander.zuepke@hs-rm.de>
  Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
  Gonglei <arei.gonglei@huawei.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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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=7e58e2ac7778cca3234c33387e49577bb7732714
+ . 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 7e58e2ac7778cca3234c33387e49577bb7732714
+ branch=qemu-mainline
+ revision=7e58e2ac7778cca3234c33387e49577bb7732714
+ . 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 7e58e2ac7778cca3234c33387e49577bb7732714:refs/heads/mainline/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
   c95f390..7e58e2a  7e58e2ac7778cca3234c33387e49577bb7732714 -> 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 Dec 24 04:21:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 04: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 1Y3dRH-0002Gt-BG; Wed, 24 Dec 2014 04:20:47 +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 1Y3dRG-0002Gh-4s
	for xen-devel@lists.xenproject.org; Wed, 24 Dec 2014 04:20:46 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3E/99-25276-D1F3A945; Wed, 24 Dec 2014 04:20:45 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419394844!9569308!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23751 invoked from network); 24 Dec 2014 04:20:45 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-2.tower-21.messagelabs.com with SMTP;
	24 Dec 2014 04:20:45 -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 7FAB759330C;
	Tue, 23 Dec 2014 20:20:43 -0800 (PST)
Date: Tue, 23 Dec 2014 23:20:42 -0500 (EST)
Message-Id: <20141223.232042.1356795429868323688.davem@davemloft.net>
To: herbert@gondor.apana.org.au
From: David Miller <davem@davemloft.net>
In-Reply-To: <E1Y2QRq-0001pW-Tn@gondolin.me.apana.org.au>
References: <20141220201453.GA6924@gondor.apana.org.au>
	<E1Y2QRq-0001pW-Tn@gondolin.me.apana.org.au>
X-Mailer: Mew version 6.6 on Emacs 24.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]);
	Tue, 23 Dec 2014 20:20:44 -0800 (PST)
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH 2/4] net: Detect drivers that reschedule
 NAPI and exhaust budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:22 +1100

> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) required drivers to leave poll_list
> empty if the entire budget is consumed.
> 
> We have already had two broken drivers so let's add a check for
> this.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 04:21:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 04: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 1Y3dRG-0002Gm-MH; Wed, 24 Dec 2014 04:20:46 +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 1Y3dRC-0002Ga-R9
	for xen-devel@lists.xenproject.org; Wed, 24 Dec 2014 04:20:45 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D9/99-25276-91F3A945; Wed, 24 Dec 2014 04:20:41 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1419394840!17606674!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23252 invoked from network); 24 Dec 2014 04:20:40 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-10.tower-21.messagelabs.com with SMTP;
	24 Dec 2014 04:20:40 -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 07D765932D1;
	Tue, 23 Dec 2014 20:20:38 -0800 (PST)
Date: Tue, 23 Dec 2014 23:20:37 -0500 (EST)
Message-Id: <20141223.232037.581371270569620964.davem@davemloft.net>
To: herbert@gondor.apana.org.au
From: David Miller <davem@davemloft.net>
In-Reply-To: <E1Y2QRp-0001pD-J7@gondolin.me.apana.org.au>
References: <20141220201453.GA6924@gondor.apana.org.au>
	<E1Y2QRp-0001pD-J7@gondolin.me.apana.org.au>
X-Mailer: Mew version 6.6 on Emacs 24.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]);
	Tue, 23 Dec 2014 20:20:39 -0800 (PST)
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/4] net: Move napi polling code out of
	net_rx_action
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:21 +1100

> This patch creates a new function napi_poll and moves the napi
> polling code from net_rx_action into it.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 04:21:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 04: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 1Y3dRG-0002Gm-MH; Wed, 24 Dec 2014 04:20:46 +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 1Y3dRC-0002Ga-R9
	for xen-devel@lists.xenproject.org; Wed, 24 Dec 2014 04:20:45 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	D9/99-25276-91F3A945; Wed, 24 Dec 2014 04:20:41 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1419394840!17606674!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23252 invoked from network); 24 Dec 2014 04:20:40 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-10.tower-21.messagelabs.com with SMTP;
	24 Dec 2014 04:20:40 -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 07D765932D1;
	Tue, 23 Dec 2014 20:20:38 -0800 (PST)
Date: Tue, 23 Dec 2014 23:20:37 -0500 (EST)
Message-Id: <20141223.232037.581371270569620964.davem@davemloft.net>
To: herbert@gondor.apana.org.au
From: David Miller <davem@davemloft.net>
In-Reply-To: <E1Y2QRp-0001pD-J7@gondolin.me.apana.org.au>
References: <20141220201453.GA6924@gondor.apana.org.au>
	<E1Y2QRp-0001pD-J7@gondolin.me.apana.org.au>
X-Mailer: Mew version 6.6 on Emacs 24.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]);
	Tue, 23 Dec 2014 20:20:39 -0800 (PST)
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/4] net: Move napi polling code out of
	net_rx_action
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:21 +1100

> This patch creates a new function napi_poll and moves the napi
> polling code from net_rx_action into it.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 04:21:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 04: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 1Y3dRS-0002Hg-9n; Wed, 24 Dec 2014 04:20:58 +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 1Y3dRR-0002HZ-3s
	for xen-devel@lists.xenproject.org; Wed, 24 Dec 2014 04:20:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AB/DF-09842-82F3A945; Wed, 24 Dec 2014 04:20:56 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419394855!9569318!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23990 invoked from network); 24 Dec 2014 04:20:55 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-2.tower-21.messagelabs.com with SMTP;
	24 Dec 2014 04:20:55 -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 7202C593314;
	Tue, 23 Dec 2014 20:20:54 -0800 (PST)
Date: Tue, 23 Dec 2014 23:20:53 -0500 (EST)
Message-Id: <20141223.232053.31234928008201022.davem@davemloft.net>
To: herbert@gondor.apana.org.au
From: David Miller <davem@davemloft.net>
In-Reply-To: <E1Y2QRt-0001qq-Lp@gondolin.me.apana.org.au>
References: <20141220201453.GA6924@gondor.apana.org.au>
	<E1Y2QRt-0001qq-Lp@gondolin.me.apana.org.au>
X-Mailer: Mew version 6.6 on Emacs 24.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]);
	Tue, 23 Dec 2014 20:20:55 -0800 (PST)
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH 4/4] net: Rearrange loop in net_rx_action
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:25 +1100

> This patch rearranges the loop in net_rx_action to reduce the
> amount of jumping back and forth when reading the code.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 04:21:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 04: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 1Y3dRN-0002H5-Qt; Wed, 24 Dec 2014 04:20:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Y3dRM-0002H0-EA
	for xen-devel@lists.xenproject.org; Wed, 24 Dec 2014 04:20:52 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	4E/86-27623-32F3A945; Wed, 24 Dec 2014 04:20:51 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419394850!15525961!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26429 invoked from network); 24 Dec 2014 04:20:50 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-2.tower-31.messagelabs.com with SMTP;
	24 Dec 2014 04:20:50 -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 3EC77593314;
	Tue, 23 Dec 2014 20:20:49 -0800 (PST)
Date: Tue, 23 Dec 2014 23:20:48 -0500 (EST)
Message-Id: <20141223.232048.1089366511326338002.davem@davemloft.net>
To: herbert@gondor.apana.org.au
From: David Miller <davem@davemloft.net>
In-Reply-To: <E1Y2QRs-0001q5-6u@gondolin.me.apana.org.au>
References: <20141220201453.GA6924@gondor.apana.org.au>
	<E1Y2QRs-0001q5-6u@gondolin.me.apana.org.au>
X-Mailer: Mew version 6.6 on Emacs 24.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]);
	Tue, 23 Dec 2014 20:20:50 -0800 (PST)
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/4] net: Always poll at least one device in
 net_rx_action
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:24 +1100

> We should only perform the softnet_break check after we have polled
> at least one device in net_rx_action.  Otherwise a zero or negative
> setting of netdev_budget can lock up the whole system.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 04:21:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 04: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 1Y3dRH-0002Gt-BG; Wed, 24 Dec 2014 04:20:47 +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 1Y3dRG-0002Gh-4s
	for xen-devel@lists.xenproject.org; Wed, 24 Dec 2014 04:20:46 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	3E/99-25276-D1F3A945; Wed, 24 Dec 2014 04:20:45 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419394844!9569308!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23751 invoked from network); 24 Dec 2014 04:20:45 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-2.tower-21.messagelabs.com with SMTP;
	24 Dec 2014 04:20:45 -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 7FAB759330C;
	Tue, 23 Dec 2014 20:20:43 -0800 (PST)
Date: Tue, 23 Dec 2014 23:20:42 -0500 (EST)
Message-Id: <20141223.232042.1356795429868323688.davem@davemloft.net>
To: herbert@gondor.apana.org.au
From: David Miller <davem@davemloft.net>
In-Reply-To: <E1Y2QRq-0001pW-Tn@gondolin.me.apana.org.au>
References: <20141220201453.GA6924@gondor.apana.org.au>
	<E1Y2QRq-0001pW-Tn@gondolin.me.apana.org.au>
X-Mailer: Mew version 6.6 on Emacs 24.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]);
	Tue, 23 Dec 2014 20:20:44 -0800 (PST)
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH 2/4] net: Detect drivers that reschedule
 NAPI and exhaust budget
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:22 +1100

> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) required drivers to leave poll_list
> empty if the entire budget is consumed.
> 
> We have already had two broken drivers so let's add a check for
> this.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 04:21:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 04: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 1Y3dRS-0002Hg-9n; Wed, 24 Dec 2014 04:20:58 +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 1Y3dRR-0002HZ-3s
	for xen-devel@lists.xenproject.org; Wed, 24 Dec 2014 04:20:57 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	AB/DF-09842-82F3A945; Wed, 24 Dec 2014 04:20:56 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419394855!9569318!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23990 invoked from network); 24 Dec 2014 04:20:55 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-2.tower-21.messagelabs.com with SMTP;
	24 Dec 2014 04:20:55 -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 7202C593314;
	Tue, 23 Dec 2014 20:20:54 -0800 (PST)
Date: Tue, 23 Dec 2014 23:20:53 -0500 (EST)
Message-Id: <20141223.232053.31234928008201022.davem@davemloft.net>
To: herbert@gondor.apana.org.au
From: David Miller <davem@davemloft.net>
In-Reply-To: <E1Y2QRt-0001qq-Lp@gondolin.me.apana.org.au>
References: <20141220201453.GA6924@gondor.apana.org.au>
	<E1Y2QRt-0001qq-Lp@gondolin.me.apana.org.au>
X-Mailer: Mew version 6.6 on Emacs 24.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]);
	Tue, 23 Dec 2014 20:20:55 -0800 (PST)
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH 4/4] net: Rearrange loop in net_rx_action
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:25 +1100

> This patch rearranges the loop in net_rx_action to reduce the
> amount of jumping back and forth when reading the code.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 04:21:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 04: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 1Y3dRN-0002H5-Qt; Wed, 24 Dec 2014 04:20:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Y3dRM-0002H0-EA
	for xen-devel@lists.xenproject.org; Wed, 24 Dec 2014 04:20:52 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	4E/86-27623-32F3A945; Wed, 24 Dec 2014 04:20:51 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419394850!15525961!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26429 invoked from network); 24 Dec 2014 04:20:50 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-2.tower-31.messagelabs.com with SMTP;
	24 Dec 2014 04:20:50 -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 3EC77593314;
	Tue, 23 Dec 2014 20:20:49 -0800 (PST)
Date: Tue, 23 Dec 2014 23:20:48 -0500 (EST)
Message-Id: <20141223.232048.1089366511326338002.davem@davemloft.net>
To: herbert@gondor.apana.org.au
From: David Miller <davem@davemloft.net>
In-Reply-To: <E1Y2QRs-0001q5-6u@gondolin.me.apana.org.au>
References: <20141220201453.GA6924@gondor.apana.org.au>
	<E1Y2QRs-0001q5-6u@gondolin.me.apana.org.au>
X-Mailer: Mew version 6.6 on Emacs 24.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]);
	Tue, 23 Dec 2014 20:20:50 -0800 (PST)
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org, edumazet@google.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/4] net: Always poll at least one device in
 net_rx_action
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 21 Dec 2014 07:16:24 +1100

> We should only perform the softnet_break check after we have polled
> at least one device in net_rx_action.  Otherwise a zero or negative
> setting of netdev_budget can lock up the whole system.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 04:52:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 04:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3dvX-0003VI-0g; Wed, 24 Dec 2014 04:52:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3dvV-0003VD-BM
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 04:52:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	46/62-25276-0764A945; Wed, 24 Dec 2014 04:52:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1419396718!17568909!1
X-Originating-IP: [66.165.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 18494 invoked from network); 24 Dec 2014 04:51:59 -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 Dec 2014 04:51:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,636,1413244800"; d="scan'208";a="208147397"
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.210.2; Tue, 23 Dec 2014 23:51: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 1Y3dvQ-0003Tr-Nr;
	Wed, 24 Dec 2014 04:51:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3dvQ-0004S6-Hm;
	Wed, 24 Dec 2014 04:51:56 +0000
Date: Wed, 24 Dec 2014 04:51:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32600-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] 32600: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32600 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32600/

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. 32564

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl           5 xen-boot                    fail pass in 32581
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start  fail in 32581 pass in 32600

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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  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-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                f9f7b9d7aeedb0f6150bc9df08542c3a0b67a4ef
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

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                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 24 04:52:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 04:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3dvX-0003VI-0g; Wed, 24 Dec 2014 04:52:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3dvV-0003VD-BM
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 04:52:01 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	46/62-25276-0764A945; Wed, 24 Dec 2014 04:52:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1419396718!17568909!1
X-Originating-IP: [66.165.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 18494 invoked from network); 24 Dec 2014 04:51:59 -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 Dec 2014 04:51:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,636,1413244800"; d="scan'208";a="208147397"
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.210.2; Tue, 23 Dec 2014 23:51: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 1Y3dvQ-0003Tr-Nr;
	Wed, 24 Dec 2014 04:51:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3dvQ-0004S6-Hm;
	Wed, 24 Dec 2014 04:51:56 +0000
Date: Wed, 24 Dec 2014 04:51:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32600-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] 32600: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32600 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32600/

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. 32564

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl           5 xen-boot                    fail pass in 32581
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start  fail in 32581 pass in 32600

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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  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-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                f9f7b9d7aeedb0f6150bc9df08542c3a0b67a4ef
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

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                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 24 08:35:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 08:35:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3hOe-0000BJ-0a; Wed, 24 Dec 2014 08:34:20 +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 1Y3hOc-0000BE-Nh
	for xen-devel@lists.xen.org; Wed, 24 Dec 2014 08:34:18 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	3B/FA-02957-98A7A945; Wed, 24 Dec 2014 08:34:17 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419410056!17026290!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29591 invoked from network); 24 Dec 2014 08:34:17 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-8.tower-27.messagelabs.com with SMTP;
	24 Dec 2014 08:34:17 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by orsmga103.jf.intel.com with ESMTP; 24 Dec 2014 00:31:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,637,1413270000"; d="scan'208";a="642306982"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by fmsmga001.fm.intel.com with ESMTP; 24 Dec 2014 00:33:49 -0800
Date: Wed, 24 Dec 2014 16:33:48 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141224083348.GA10595@pengc-linux.bj.intel.com>
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
	<1419324880-13212-3-git-send-email-chao.p.peng@linux.intel.com>
	<54998E61.8020103@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54998E61.8020103@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	JBeulich@suse.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH 2/4] tools: libxc: add routine to get CMT L3
 event mask
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 Tue, Dec 23, 2014 at 03:46:41PM +0000, Andrew Cooper wrote:
> 
> On 23/12/2014 08:54, Chao Peng wrote:
> >This is the xc side wrapper for XEN_SYSCTL_PSR_CMT_get_l3_event_mask
> >of XEN_SYSCTL_psr_cmt_op. Additional check for event id against value
> >got from this routine is also added.
> >
> >Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> >---
> >  tools/libxc/include/xenctrl.h |    1 +
> >  tools/libxc/xc_psr.c          |   32 ++++++++++++++++++++++++++++++++
> >  2 files changed, 33 insertions(+)
> >
> >diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> >index 0ad8b8d..96b357c 100644
> >--- a/tools/libxc/include/xenctrl.h
> >+++ b/tools/libxc/include/xenctrl.h
> >@@ -2697,6 +2697,7 @@ int xc_psr_cmt_get_domain_rmid(xc_interface *xch, uint32_t domid,
> >  int xc_psr_cmt_get_total_rmid(xc_interface *xch, uint32_t *total_rmid);
> >  int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
> >      uint32_t *upscaling_factor);
> >+int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask);
> >  int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
> >      uint32_t *l3_cache_size);
> >  int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
> >diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
> >index 872e6dc..94c8698 100644
> >--- a/tools/libxc/xc_psr.c
> >+++ b/tools/libxc/xc_psr.c
> >@@ -112,6 +112,30 @@ int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
> >      return rc;
> >  }
> >+int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask)
> >+{
> >+    static int val = 0;
> >+    int rc;
> >+    DECLARE_SYSCTL;
> >+
> >+    if ( val )
> >+    {
> >+        *event_mask = val;
> >+        return 0;
> >+    }
> >+
> >+    sysctl.cmd = XEN_SYSCTL_psr_cmt_op;
> >+    sysctl.u.psr_cmt_op.cmd =
> >+        XEN_SYSCTL_PSR_CMT_get_l3_event_mask;
> >+    sysctl.u.psr_cmt_op.flags = 0;
> >+
> >+    rc = xc_sysctl(xch, &sysctl);
> >+    if ( !rc )
> >+        val = *event_mask = sysctl.u.psr_cmt_op.u.data;
> >+
> >+    return rc;
> >+}
> >+
> >  int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
> >                                        uint32_t *l3_cache_size)
> >  {
> >@@ -144,6 +168,7 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
> >      xc_resource_op_t op;
> >      xc_resource_entry_t entries[2];
> >      uint32_t evtid;
> >+    uint32_t event_mask;
> >      int rc;
> >      switch ( type )
> >@@ -155,6 +180,13 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
> >          return -1;
> >      }
> >+    rc = xc_psr_cmt_get_l3_event_mask(xch, &event_mask);
> >+    if ( rc < 0 )
> >+        return rc;
> >+
> >+    if ( !(event_mask & (1 << (evtid - 1))) )
> >+        return -1;
> >+
> 
> This adds an extra hypercall on a common path to return a constant. As libxc
> is mostly a set of basic hypercall wrappers, I don't it should be validating
> its parameters like this.
> 
> The caller of xc_psr_cmt_get_data() must be aware of all the details, and
> whether certain events are supported or not.  I woud simply let the
> xc_resourse_op() fail (faulting on the wrmsr) if the caller passes a bad
> event id.
> 
Sounds reasonable. I'd move the validation to the caller, that's, the xl side.
Thanks Andrew.
> 
> >      entries[0].u.cmd = XEN_RESOURCE_OP_MSR_WRITE;
> >      entries[0].idx = MSR_IA32_CMT_EVTSEL;
> >      entries[0].val = (uint64_t)rmid << 32 | evtid;
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 24 08:35:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 08:35:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3hOe-0000BJ-0a; Wed, 24 Dec 2014 08:34:20 +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 1Y3hOc-0000BE-Nh
	for xen-devel@lists.xen.org; Wed, 24 Dec 2014 08:34:18 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	3B/FA-02957-98A7A945; Wed, 24 Dec 2014 08:34:17 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419410056!17026290!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29591 invoked from network); 24 Dec 2014 08:34:17 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-8.tower-27.messagelabs.com with SMTP;
	24 Dec 2014 08:34:17 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by orsmga103.jf.intel.com with ESMTP; 24 Dec 2014 00:31:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,637,1413270000"; d="scan'208";a="642306982"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by fmsmga001.fm.intel.com with ESMTP; 24 Dec 2014 00:33:49 -0800
Date: Wed, 24 Dec 2014 16:33:48 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141224083348.GA10595@pengc-linux.bj.intel.com>
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
	<1419324880-13212-3-git-send-email-chao.p.peng@linux.intel.com>
	<54998E61.8020103@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54998E61.8020103@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	JBeulich@suse.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH 2/4] tools: libxc: add routine to get CMT L3
 event mask
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 Tue, Dec 23, 2014 at 03:46:41PM +0000, Andrew Cooper wrote:
> 
> On 23/12/2014 08:54, Chao Peng wrote:
> >This is the xc side wrapper for XEN_SYSCTL_PSR_CMT_get_l3_event_mask
> >of XEN_SYSCTL_psr_cmt_op. Additional check for event id against value
> >got from this routine is also added.
> >
> >Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> >---
> >  tools/libxc/include/xenctrl.h |    1 +
> >  tools/libxc/xc_psr.c          |   32 ++++++++++++++++++++++++++++++++
> >  2 files changed, 33 insertions(+)
> >
> >diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> >index 0ad8b8d..96b357c 100644
> >--- a/tools/libxc/include/xenctrl.h
> >+++ b/tools/libxc/include/xenctrl.h
> >@@ -2697,6 +2697,7 @@ int xc_psr_cmt_get_domain_rmid(xc_interface *xch, uint32_t domid,
> >  int xc_psr_cmt_get_total_rmid(xc_interface *xch, uint32_t *total_rmid);
> >  int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
> >      uint32_t *upscaling_factor);
> >+int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask);
> >  int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
> >      uint32_t *l3_cache_size);
> >  int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
> >diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
> >index 872e6dc..94c8698 100644
> >--- a/tools/libxc/xc_psr.c
> >+++ b/tools/libxc/xc_psr.c
> >@@ -112,6 +112,30 @@ int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
> >      return rc;
> >  }
> >+int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask)
> >+{
> >+    static int val = 0;
> >+    int rc;
> >+    DECLARE_SYSCTL;
> >+
> >+    if ( val )
> >+    {
> >+        *event_mask = val;
> >+        return 0;
> >+    }
> >+
> >+    sysctl.cmd = XEN_SYSCTL_psr_cmt_op;
> >+    sysctl.u.psr_cmt_op.cmd =
> >+        XEN_SYSCTL_PSR_CMT_get_l3_event_mask;
> >+    sysctl.u.psr_cmt_op.flags = 0;
> >+
> >+    rc = xc_sysctl(xch, &sysctl);
> >+    if ( !rc )
> >+        val = *event_mask = sysctl.u.psr_cmt_op.u.data;
> >+
> >+    return rc;
> >+}
> >+
> >  int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
> >                                        uint32_t *l3_cache_size)
> >  {
> >@@ -144,6 +168,7 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
> >      xc_resource_op_t op;
> >      xc_resource_entry_t entries[2];
> >      uint32_t evtid;
> >+    uint32_t event_mask;
> >      int rc;
> >      switch ( type )
> >@@ -155,6 +180,13 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
> >          return -1;
> >      }
> >+    rc = xc_psr_cmt_get_l3_event_mask(xch, &event_mask);
> >+    if ( rc < 0 )
> >+        return rc;
> >+
> >+    if ( !(event_mask & (1 << (evtid - 1))) )
> >+        return -1;
> >+
> 
> This adds an extra hypercall on a common path to return a constant. As libxc
> is mostly a set of basic hypercall wrappers, I don't it should be validating
> its parameters like this.
> 
> The caller of xc_psr_cmt_get_data() must be aware of all the details, and
> whether certain events are supported or not.  I woud simply let the
> xc_resourse_op() fail (faulting on the wrmsr) if the caller passes a bad
> event id.
> 
Sounds reasonable. I'd move the validation to the caller, that's, the xl side.
Thanks Andrew.
> 
> >      entries[0].u.cmd = XEN_RESOURCE_OP_MSR_WRITE;
> >      entries[0].idx = MSR_IA32_CMT_EVTSEL;
> >      entries[0].val = (uint64_t)rmid << 32 | evtid;
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Dec 24 08:35:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 08:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3hPw-0000FJ-LQ; Wed, 24 Dec 2014 08:35:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1Y3hPv-0000FB-Dn
	for xen-devel@lists.xen.org; Wed, 24 Dec 2014 08:35:39 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	F0/83-23865-ADA7A945; Wed, 24 Dec 2014 08:35:38 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419410137!15586835!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 9312 invoked from network); 24 Dec 2014 08:35:38 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-31.messagelabs.com with SMTP;
	24 Dec 2014 08:35:38 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by orsmga102.jf.intel.com with ESMTP; 24 Dec 2014 00:33:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,637,1413270000"; d="scan'208";a="642307515"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by fmsmga001.fm.intel.com with ESMTP; 24 Dec 2014 00:35:34 -0800
Date: Wed, 24 Dec 2014 16:35:33 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141224083532.GB10595@pengc-linux.bj.intel.com>
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
	<54998E97.5070608@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54998E97.5070608@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	JBeulich@suse.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH 0/4] enable Memory Bandwidth Monitoring
 (MBM) for VMs
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 Tue, Dec 23, 2014 at 03:47:35PM +0000, Andrew Cooper wrote:
> On 23/12/2014 08:54, Chao Peng wrote:
> >Intel Memory Bandwidth Monitoring(MBM) is a new hardware feature
> >which builds on the CMT infrastructure to allow monitoring of system
> >memory bandwidth. Event codes are provided to monitor both "total"
> >and "local" bandwidth, meaning bandwidth over QPI and other external
> >links can be monitored.
> >
> >For XEN, MBM is used to monitor memory bandwidth for VMs. Due to its
> >dependency on CMT, the software also makes use of most of CMT codes.
> >Actually, besides introducing two additional events and some cpuid
> >feature bits, there are no extra changes compared to cache occupancy
> >monitoring in CMT. Due to this, CMT should be enabled first to use
> >this feature.
> >
> >For interface changes, the patch serial only introduces a new command
> >"XEN_SYSCTL_PSR_CMT_get_l3_event_mask" which exposes MBM feature
> >capability to user space and introduces two additional options for
> >"xl psr-cmt-show":
> >total_mem_bandwidth:     Show total memory bandwidth
> >local_mem_bandwidth:     Show local memory bandwidth
> >
> >The usage flow keeps the same with CMT.
> >
> >Chao Peng (4):
> >   x86: expose CMT L3 event mask to user space
> >   tools: libxc: add routine to get CMT L3 event mask
> >   tools: libxl: code preparation for MBM
> >   tools: add total/local memory bandwith monitoring
> 
> Please can you add a note about MBM in the command line documentation,
> beside the CMT information.
Sure.
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 Wed Dec 24 08:35:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 08:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3hPw-0000FJ-LQ; Wed, 24 Dec 2014 08:35:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <chao.p.peng@linux.intel.com>) id 1Y3hPv-0000FB-Dn
	for xen-devel@lists.xen.org; Wed, 24 Dec 2014 08:35:39 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	F0/83-23865-ADA7A945; Wed, 24 Dec 2014 08:35:38 +0000
X-Env-Sender: chao.p.peng@linux.intel.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419410137!15586835!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 9312 invoked from network); 24 Dec 2014 08:35:38 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-31.messagelabs.com with SMTP;
	24 Dec 2014 08:35:38 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by orsmga102.jf.intel.com with ESMTP; 24 Dec 2014 00:33:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,637,1413270000"; d="scan'208";a="642307515"
Received: from pengc-linux.bj.intel.com (HELO localhost) ([10.238.145.52])
	by fmsmga001.fm.intel.com with ESMTP; 24 Dec 2014 00:35:34 -0800
Date: Wed, 24 Dec 2014 16:35:33 +0800
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141224083532.GB10595@pengc-linux.bj.intel.com>
References: <1419324880-13212-1-git-send-email-chao.p.peng@linux.intel.com>
	<54998E97.5070608@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54998E97.5070608@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	JBeulich@suse.com, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH 0/4] enable Memory Bandwidth Monitoring
 (MBM) for VMs
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 Tue, Dec 23, 2014 at 03:47:35PM +0000, Andrew Cooper wrote:
> On 23/12/2014 08:54, Chao Peng wrote:
> >Intel Memory Bandwidth Monitoring(MBM) is a new hardware feature
> >which builds on the CMT infrastructure to allow monitoring of system
> >memory bandwidth. Event codes are provided to monitor both "total"
> >and "local" bandwidth, meaning bandwidth over QPI and other external
> >links can be monitored.
> >
> >For XEN, MBM is used to monitor memory bandwidth for VMs. Due to its
> >dependency on CMT, the software also makes use of most of CMT codes.
> >Actually, besides introducing two additional events and some cpuid
> >feature bits, there are no extra changes compared to cache occupancy
> >monitoring in CMT. Due to this, CMT should be enabled first to use
> >this feature.
> >
> >For interface changes, the patch serial only introduces a new command
> >"XEN_SYSCTL_PSR_CMT_get_l3_event_mask" which exposes MBM feature
> >capability to user space and introduces two additional options for
> >"xl psr-cmt-show":
> >total_mem_bandwidth:     Show total memory bandwidth
> >local_mem_bandwidth:     Show local memory bandwidth
> >
> >The usage flow keeps the same with CMT.
> >
> >Chao Peng (4):
> >   x86: expose CMT L3 event mask to user space
> >   tools: libxc: add routine to get CMT L3 event mask
> >   tools: libxl: code preparation for MBM
> >   tools: add total/local memory bandwith monitoring
> 
> Please can you add a note about MBM in the command line documentation,
> beside the CMT information.
Sure.
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 Wed Dec 24 09:05:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 09: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 1Y3hs5-00013j-W4; Wed, 24 Dec 2014 09:04:45 +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 1Y3hs4-00013e-TO
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 09:04:45 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	56/AC-27584-CA18A945; Wed, 24 Dec 2014 09:04:44 +0000
X-Env-Sender: liangx.z.li@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1419411882!15046072!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24987 invoked from network); 24 Dec 2014 09:04:43 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-206.messagelabs.com with SMTP;
	24 Dec 2014 09:04:43 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 24 Dec 2014 01:04:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,637,1413270000"; d="scan'208";a="642317690"
Received: from lil.sh.intel.com (HELO localhost) ([10.239.159.161])
	by fmsmga001.fm.intel.com with ESMTP; 24 Dec 2014 01:04:18 -0800
From: Liang Li <liang.z.li@intel.com>
To: qemu-devel@nongnu.org,
	xen-devel@lists.xensource.com
Date: Wed, 24 Dec 2014 16:56:57 +0800
Message-Id: <1419411417-23354-1-git-send-email-liang.z.li@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: Liang Li <liang.z.li@intel.com>, stefano.stabellini@eu.citrix.com,
	mtosatti@redhat.com, mst@redhat.com, aliguori@amazon.com,
	robert.hu@intel.com, yang.z.zhang@intel.com, pbonzini@redhat.com,
	rth@twiddle.net
Subject: [Xen-devel] [PATCH] xen-pt: Fix PCI devices re-attach 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

Use the 'xl pci-attach $DomU $BDF' command to attach more then
one PCI devices to the guest, then detach the devices with
'xl pci-detach $DomU $BDF', after that, re-attach these PCI
devices again, an error message will be reported like following:

libxl: error: libxl_qmp.c:287:qmp_handle_error_response: receive
an error message from QMP server: Duplicate ID 'pci-pt-03_10.1'
for device.

The count of calling xen_pt_region_add and xen_pt_region_del are
not the same will cause the XenPCIPassthroughState and it's related
QemuOpts object not be released properly.

Signed-off-by: Liang Li <liang.z.li@intel.com>
Reported-by: Longtao Pang <longtaox.pang@intel.com>
---
 hw/xen/xen_pt.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index c1bf357..523b8a2 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -588,7 +588,6 @@ static void xen_pt_region_add(MemoryListener *l, MemoryRegionSection *sec)
     XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
                                              memory_listener);
 
-    memory_region_ref(sec->mr);
     xen_pt_region_update(s, sec, true);
 }
 
@@ -598,7 +597,6 @@ static void xen_pt_region_del(MemoryListener *l, MemoryRegionSection *sec)
                                              memory_listener);
 
     xen_pt_region_update(s, sec, false);
-    memory_region_unref(sec->mr);
 }
 
 static void xen_pt_io_region_add(MemoryListener *l, MemoryRegionSection *sec)
@@ -606,7 +604,6 @@ static void xen_pt_io_region_add(MemoryListener *l, MemoryRegionSection *sec)
     XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
                                              io_listener);
 
-    memory_region_ref(sec->mr);
     xen_pt_region_update(s, sec, true);
 }
 
@@ -616,7 +613,6 @@ static void xen_pt_io_region_del(MemoryListener *l, MemoryRegionSection *sec)
                                              io_listener);
 
     xen_pt_region_update(s, sec, false);
-    memory_region_unref(sec->mr);
 }
 
 static const MemoryListener xen_pt_memory_listener = {
-- 
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 Dec 24 09:05:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 09: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 1Y3hs5-00013j-W4; Wed, 24 Dec 2014 09:04:45 +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 1Y3hs4-00013e-TO
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 09:04:45 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	56/AC-27584-CA18A945; Wed, 24 Dec 2014 09:04:44 +0000
X-Env-Sender: liangx.z.li@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1419411882!15046072!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24987 invoked from network); 24 Dec 2014 09:04:43 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-206.messagelabs.com with SMTP;
	24 Dec 2014 09:04:43 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 24 Dec 2014 01:04:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,637,1413270000"; d="scan'208";a="642317690"
Received: from lil.sh.intel.com (HELO localhost) ([10.239.159.161])
	by fmsmga001.fm.intel.com with ESMTP; 24 Dec 2014 01:04:18 -0800
From: Liang Li <liang.z.li@intel.com>
To: qemu-devel@nongnu.org,
	xen-devel@lists.xensource.com
Date: Wed, 24 Dec 2014 16:56:57 +0800
Message-Id: <1419411417-23354-1-git-send-email-liang.z.li@intel.com>
X-Mailer: git-send-email 1.9.1
Cc: Liang Li <liang.z.li@intel.com>, stefano.stabellini@eu.citrix.com,
	mtosatti@redhat.com, mst@redhat.com, aliguori@amazon.com,
	robert.hu@intel.com, yang.z.zhang@intel.com, pbonzini@redhat.com,
	rth@twiddle.net
Subject: [Xen-devel] [PATCH] xen-pt: Fix PCI devices re-attach 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

Use the 'xl pci-attach $DomU $BDF' command to attach more then
one PCI devices to the guest, then detach the devices with
'xl pci-detach $DomU $BDF', after that, re-attach these PCI
devices again, an error message will be reported like following:

libxl: error: libxl_qmp.c:287:qmp_handle_error_response: receive
an error message from QMP server: Duplicate ID 'pci-pt-03_10.1'
for device.

The count of calling xen_pt_region_add and xen_pt_region_del are
not the same will cause the XenPCIPassthroughState and it's related
QemuOpts object not be released properly.

Signed-off-by: Liang Li <liang.z.li@intel.com>
Reported-by: Longtao Pang <longtaox.pang@intel.com>
---
 hw/xen/xen_pt.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index c1bf357..523b8a2 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -588,7 +588,6 @@ static void xen_pt_region_add(MemoryListener *l, MemoryRegionSection *sec)
     XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
                                              memory_listener);
 
-    memory_region_ref(sec->mr);
     xen_pt_region_update(s, sec, true);
 }
 
@@ -598,7 +597,6 @@ static void xen_pt_region_del(MemoryListener *l, MemoryRegionSection *sec)
                                              memory_listener);
 
     xen_pt_region_update(s, sec, false);
-    memory_region_unref(sec->mr);
 }
 
 static void xen_pt_io_region_add(MemoryListener *l, MemoryRegionSection *sec)
@@ -606,7 +604,6 @@ static void xen_pt_io_region_add(MemoryListener *l, MemoryRegionSection *sec)
     XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
                                              io_listener);
 
-    memory_region_ref(sec->mr);
     xen_pt_region_update(s, sec, true);
 }
 
@@ -616,7 +613,6 @@ static void xen_pt_io_region_del(MemoryListener *l, MemoryRegionSection *sec)
                                              io_listener);
 
     xen_pt_region_update(s, sec, false);
-    memory_region_unref(sec->mr);
 }
 
 static const MemoryListener xen_pt_memory_listener = {
-- 
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 Dec 24 11:33:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 11: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 1Y3kB7-00040a-73; Wed, 24 Dec 2014 11:32: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 1Y3kB5-00040V-3O
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 11:32:31 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A8/1A-17735-E44AA945; Wed, 24 Dec 2014 11:32:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1419420748!15615211!1
X-Originating-IP: [66.165.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 3093 invoked from network); 24 Dec 2014 11:32:29 -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 Dec 2014 11:32:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,638,1413244800"; d="scan'208";a="208218869"
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.210.2; Wed, 24 Dec 2014 06:32: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 1Y3kB0-0005QS-2p;
	Wed, 24 Dec 2014 11:32:26 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3kAz-0006OJ-Tr;
	Wed, 24 Dec 2014 11:32:25 +0000
Date: Wed, 24 Dec 2014 11:32:25 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32607-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] 32607: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32607 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32607/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           5 libvirt-build             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 32597
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 32597 pass in 32607
 test-amd64-i386-xl-credit2    5 xen-boot           fail in 32597 pass in 32607

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-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail in 32597 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 32597 never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 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-amd64-xl-pvh-amd                                  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                          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                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 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-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 34929 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 Dec 24 11:33:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 11: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 1Y3kB7-00040a-73; Wed, 24 Dec 2014 11:32: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 1Y3kB5-00040V-3O
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 11:32:31 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A8/1A-17735-E44AA945; Wed, 24 Dec 2014 11:32:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1419420748!15615211!1
X-Originating-IP: [66.165.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 3093 invoked from network); 24 Dec 2014 11:32:29 -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 Dec 2014 11:32:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,638,1413244800"; d="scan'208";a="208218869"
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.210.2; Wed, 24 Dec 2014 06:32: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 1Y3kB0-0005QS-2p;
	Wed, 24 Dec 2014 11:32:26 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3kAz-0006OJ-Tr;
	Wed, 24 Dec 2014 11:32:25 +0000
Date: Wed, 24 Dec 2014 11:32:25 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32607-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] 32607: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32607 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32607/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           5 libvirt-build             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 32597
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 32597 pass in 32607
 test-amd64-i386-xl-credit2    5 xen-boot           fail in 32597 pass in 32607

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-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail in 32597 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 32597 never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 people touched revisions under test,
not listing them all
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 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-amd64-xl-pvh-amd                                  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                          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                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 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-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 34929 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 Dec 24 13:39:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 13:39:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3m9m-0006zP-Qn; Wed, 24 Dec 2014 13:39:18 +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 1Y3m9l-0006zK-Di
	for xen-devel@lists.xen.org; Wed, 24 Dec 2014 13:39:17 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	D6/E1-11608-402CA945; Wed, 24 Dec 2014 13:39:16 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419428354!15625109!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19156 invoked from network); 24 Dec 2014 13:39:15 -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; 24 Dec 2014 13:39: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=1419428355; x=1450964355;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=8k+gPeb+RcPiRO3V7OOaf3A1ogWKh49rLTvYqqLyafU=;
	b=o5bFBnZEJUlRgQYAT+0JKmRUIfobzmM25LcUq8wTv+F+VLN/LoHiJZtM
	gr6moY2I0BhjkJLtpG625SxS59/lj6XkRK0FBZdtspRCbF/opYgmHO6HV
	mYu6+xoVIU5BVJNbSodpbdTJ9t3ND5rbe5UEnqvlS/n6+Y4mpVz3fsEfs c=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by fldsmtpe04.verizon.com with ESMTP; 24 Dec 2014 13:39:13 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,638,1413244800"; d="scan'208";a="899515728"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.107.144])
	by fldsmtpi02.verizon.com with ESMTP; 24 Dec 2014 13:39:13 +0000
Message-ID: <549AC200.6020509@terremark.com>
Date: Wed, 24 Dec 2014 08:39:12 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Singhal, Upanshu" <upanshu.singhal@emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
	<5494A6AF.1030802@terremark.com>
	<6A5D14D0DFEABC43BE832A0E492963F14EBB9C30@MX101CL01.corp.emc.com>
In-Reply-To: <6A5D14D0DFEABC43BE832A0E492963F14EBB9C30@MX101CL01.corp.emc.com>
Content-Length: 7986
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-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 12/23/14 05:51, Singhal, Upanshu wrote:
>
> Hello Don,
>
> I am not trying to configure VMW PVSCSI type of device but not able to =

> do so. Though, PVSCSI is available on the distribution I am using. Any =

> inputs on how to configure PVSCSI type disk device?
>

device_model_args_hvm =3D [
"-device",
"pvscsi,id=3Dscsi1",
"-drive",
"if=3Dnone,id=3Ddisk1,file=3D/home/don/qemu-img/C63-min-disk1.raw",
"-device",
"scsi-disk,bus=3Dscsi1.0,scsi-id=3D0,drive=3Ddisk1",
]

-Don Slutz

> Thanks,
>
> -Upanshu
>
> *From:*Singhal, Upanshu
> *Sent:* Monday, December 22, 2014 12:35 PM
> *To:* 'Don Slutz'
> *Cc:* 'xen-devel@lists.xen.org'
> *Subject:* RE: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
>
> Hello Don,
>
> xen_emul_unplug=3Dunnecessarydoes the trick, I am able to see the =

> vmxnet3 driver using lspci and ethtool =96I eth0. Thanks a lot for your =

> help, much appreciated.
>
> Performance between vmxnet3 running on XEN is about 1/3 of vmxnet3 =

> running on ESXi. Similar performance number I get between vmxnet3 on =

> ESXi and vif on XEN. Do you know what could be the reason for this?
>
> Thanks,
>
> -Upanshu
>
> *From:*Don Slutz [mailto:dslutz@verizon.com]
> *Sent:* Saturday, December 20, 2014 3:59 AM
> *To:* Singhal, Upanshu
> *Cc:* xen-devel@lists.xen.org <mailto:xen-devel@lists.xen.org>
> *Subject:* Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
>
> xen_emul_unplug=3Dunnecessary (kernel arg) may help you here.
>
> Also udev likes to rename your devices.
>
> Here is a lspci from a guest:
>
>
> [root@C63-min-tools ~]# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device =

> (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit =

> Ethernet Controller (rev 03)
> 00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit =

> Ethernet Controller (rev 03)
>
> And to help:
>
> [root@C63-min-tools ~]# ls -l /sys/class/net/*/device
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> =

> ../../../vif-0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> =

> ../../../vif-1
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> =

> ../../../vif-2
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> =

> ../../../vif-3
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> =

> ../../../vif-4
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> =

> ../../../vif-5
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> =

> ../../../vif-6
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> =

> ../../../vif-7
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> =

> ../../../vif-8
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> =

> ../../../vif-9
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device =

> -> ../../../0000:00:04.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device =

> -> ../../../0000:00:05.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device =

> -> ../../../0000:00:06.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device =

> -> ../../../0000:00:07.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device =

> -> ../../../0000:00:08.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device =

> -> ../../../0000:00:09.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device =

> -> ../../../0000:00:0a.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device =

> -> ../../../0000:00:0b.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device =

> -> ../../../0000:00:0c.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device =

> -> ../../../0000:00:0d.0
>
>
> -Don Slutz
>
> On 12/19/14 07:04, Singhal, Upanshu wrote:
>
>     Hello,
>
>     In one of my experiment, I am building a Linux VM with Network
>     interface model as =93vmxnet3=94. I am able to create the VM
>     successfully, but I see that the driver loaded is =93vif=94 and not
>     =93vmxnet3=94. I am using the following option for the network
>     interface: *vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22,
>     bridge=3Dxenbr0, model=3Dvmxnet3' ]*
>
>     **
>
>     I tried with model as e1000 and it works fine. Lspci command also
>     does not show vmxnet3. Though, qemu device help shows that
>     =93vmxnet3=94 is supported on XEN 4.4.1 version I am using.
>
>     I tried searching on internet about the right configuration for
>     vmxnet3 with XEN, but not able to find right information. Can
>     someone please help me on how to create a VM with vmxnet3?
>
>     This experiment I am doing to compare the difference between
>     vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM
>     configuration file is:
>
>     # This configures an HVM rather than PV guest
>
>     builder =3D "hvm"
>
>     # Guest name
>
>     *name =3D "rhel-vmxnet3-xen-2.hvm"*
>
>     # 128-bit UUID for the domain as a hexadecimal number.
>
>     # Use "uuidgen" to generate one if required.
>
>     # The default behavior is to generate a new UUID each time the
>     guest is started.
>
>     #uuid =3D "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
>
>     # Enable Microsoft Hyper-V compatibile paravirtualisation /
>
>     # enlightenment interfaces. Turning this on can improve Windows guest
>
>     # performance and is therefore recommended
>
>     #viridian =3D 1
>
>     # Initial memory allocation (MB)
>
>     *memory =3D 8192*
>
>     # Maximum memory (MB)
>
>     # If this is greater than `memory' then the slack will start ballooned
>
>     # (this assumes guest kernel support for ballooning)
>
>     #maxmem =3D 512
>
>     # Number of VCPUS
>
>     *vcpus =3D 8*
>
>     # Network devices
>
>     # A list of 'vifspec' entries as described in
>
>     # docs/misc/xl-network-configuration.markdown
>
>     vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dxenbr1,
>     model=3Dvmxnet3' ]
>
>     # Disk Devices
>
>     # A list of `diskspec' entries as described in
>
>     # docs/misc/xl-disk-configuration.txt
>
>     *disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw',
>     'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r
>     <file:///%5C%5Croot%5Crhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r>' ]*
>
>     *boot=3D'cd'*
>
>     # Guest VGA console configuration, either SDL or VNC
>
>     # sdl =3D 1
>
>     *vnc =3D 2*
>
>     Thanks,
>
>     -Upanshu
>
>     Upanshu Singhal
>
>     EMC Data Storage Systems, Bangalore, India.
>
>     Phone: 91-80-67375604
>
>
>
>     _______________________________________________
>
>     Xen-devel mailing list
>
>     Xen-devel@lists.xen.org  <mailto:Xen-devel@lists.xen.org>
>
>     http://lists.xen.org/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 Dec 24 13:39:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 13:39:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3m9m-0006zP-Qn; Wed, 24 Dec 2014 13:39:18 +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 1Y3m9l-0006zK-Di
	for xen-devel@lists.xen.org; Wed, 24 Dec 2014 13:39:17 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	D6/E1-11608-402CA945; Wed, 24 Dec 2014 13:39:16 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419428354!15625109!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19156 invoked from network); 24 Dec 2014 13:39:15 -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; 24 Dec 2014 13:39: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=1419428355; x=1450964355;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=8k+gPeb+RcPiRO3V7OOaf3A1ogWKh49rLTvYqqLyafU=;
	b=o5bFBnZEJUlRgQYAT+0JKmRUIfobzmM25LcUq8wTv+F+VLN/LoHiJZtM
	gr6moY2I0BhjkJLtpG625SxS59/lj6XkRK0FBZdtspRCbF/opYgmHO6HV
	mYu6+xoVIU5BVJNbSodpbdTJ9t3ND5rbe5UEnqvlS/n6+Y4mpVz3fsEfs c=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144])
	by fldsmtpe04.verizon.com with ESMTP; 24 Dec 2014 13:39:13 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,638,1413244800"; d="scan'208";a="899515728"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.107.144])
	by fldsmtpi02.verizon.com with ESMTP; 24 Dec 2014 13:39:13 +0000
Message-ID: <549AC200.6020509@terremark.com>
Date: Wed, 24 Dec 2014 08:39:12 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Singhal, Upanshu" <upanshu.singhal@emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
	<5494A6AF.1030802@terremark.com>
	<6A5D14D0DFEABC43BE832A0E492963F14EBB9C30@MX101CL01.corp.emc.com>
In-Reply-To: <6A5D14D0DFEABC43BE832A0E492963F14EBB9C30@MX101CL01.corp.emc.com>
Content-Length: 7986
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-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 12/23/14 05:51, Singhal, Upanshu wrote:
>
> Hello Don,
>
> I am not trying to configure VMW PVSCSI type of device but not able to =

> do so. Though, PVSCSI is available on the distribution I am using. Any =

> inputs on how to configure PVSCSI type disk device?
>

device_model_args_hvm =3D [
"-device",
"pvscsi,id=3Dscsi1",
"-drive",
"if=3Dnone,id=3Ddisk1,file=3D/home/don/qemu-img/C63-min-disk1.raw",
"-device",
"scsi-disk,bus=3Dscsi1.0,scsi-id=3D0,drive=3Ddisk1",
]

-Don Slutz

> Thanks,
>
> -Upanshu
>
> *From:*Singhal, Upanshu
> *Sent:* Monday, December 22, 2014 12:35 PM
> *To:* 'Don Slutz'
> *Cc:* 'xen-devel@lists.xen.org'
> *Subject:* RE: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
>
> Hello Don,
>
> xen_emul_unplug=3Dunnecessarydoes the trick, I am able to see the =

> vmxnet3 driver using lspci and ethtool =96I eth0. Thanks a lot for your =

> help, much appreciated.
>
> Performance between vmxnet3 running on XEN is about 1/3 of vmxnet3 =

> running on ESXi. Similar performance number I get between vmxnet3 on =

> ESXi and vif on XEN. Do you know what could be the reason for this?
>
> Thanks,
>
> -Upanshu
>
> *From:*Don Slutz [mailto:dslutz@verizon.com]
> *Sent:* Saturday, December 20, 2014 3:59 AM
> *To:* Singhal, Upanshu
> *Cc:* xen-devel@lists.xen.org <mailto:xen-devel@lists.xen.org>
> *Subject:* Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
>
> xen_emul_unplug=3Dunnecessary (kernel arg) may help you here.
>
> Also udev likes to rename your devices.
>
> Here is a lspci from a guest:
>
>
> [root@C63-min-tools ~]# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device =

> (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit =

> Ethernet Controller (rev 03)
> 00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit =

> Ethernet Controller (rev 03)
>
> And to help:
>
> [root@C63-min-tools ~]# ls -l /sys/class/net/*/device
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> =

> ../../../vif-0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> =

> ../../../vif-1
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> =

> ../../../vif-2
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> =

> ../../../vif-3
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> =

> ../../../vif-4
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> =

> ../../../vif-5
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> =

> ../../../vif-6
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> =

> ../../../vif-7
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> =

> ../../../vif-8
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> =

> ../../../vif-9
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device =

> -> ../../../0000:00:04.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device =

> -> ../../../0000:00:05.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device =

> -> ../../../0000:00:06.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device =

> -> ../../../0000:00:07.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device =

> -> ../../../0000:00:08.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device =

> -> ../../../0000:00:09.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device =

> -> ../../../0000:00:0a.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device =

> -> ../../../0000:00:0b.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device =

> -> ../../../0000:00:0c.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device =

> -> ../../../0000:00:0d.0
>
>
> -Don Slutz
>
> On 12/19/14 07:04, Singhal, Upanshu wrote:
>
>     Hello,
>
>     In one of my experiment, I am building a Linux VM with Network
>     interface model as =93vmxnet3=94. I am able to create the VM
>     successfully, but I see that the driver loaded is =93vif=94 and not
>     =93vmxnet3=94. I am using the following option for the network
>     interface: *vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22,
>     bridge=3Dxenbr0, model=3Dvmxnet3' ]*
>
>     **
>
>     I tried with model as e1000 and it works fine. Lspci command also
>     does not show vmxnet3. Though, qemu device help shows that
>     =93vmxnet3=94 is supported on XEN 4.4.1 version I am using.
>
>     I tried searching on internet about the right configuration for
>     vmxnet3 with XEN, but not able to find right information. Can
>     someone please help me on how to create a VM with vmxnet3?
>
>     This experiment I am doing to compare the difference between
>     vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM
>     configuration file is:
>
>     # This configures an HVM rather than PV guest
>
>     builder =3D "hvm"
>
>     # Guest name
>
>     *name =3D "rhel-vmxnet3-xen-2.hvm"*
>
>     # 128-bit UUID for the domain as a hexadecimal number.
>
>     # Use "uuidgen" to generate one if required.
>
>     # The default behavior is to generate a new UUID each time the
>     guest is started.
>
>     #uuid =3D "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
>
>     # Enable Microsoft Hyper-V compatibile paravirtualisation /
>
>     # enlightenment interfaces. Turning this on can improve Windows guest
>
>     # performance and is therefore recommended
>
>     #viridian =3D 1
>
>     # Initial memory allocation (MB)
>
>     *memory =3D 8192*
>
>     # Maximum memory (MB)
>
>     # If this is greater than `memory' then the slack will start ballooned
>
>     # (this assumes guest kernel support for ballooning)
>
>     #maxmem =3D 512
>
>     # Number of VCPUS
>
>     *vcpus =3D 8*
>
>     # Network devices
>
>     # A list of 'vifspec' entries as described in
>
>     # docs/misc/xl-network-configuration.markdown
>
>     vif =3D [ 'type=3Dioemu, mac=3D00:16:3e:00:00:22, bridge=3Dxenbr1,
>     model=3Dvmxnet3' ]
>
>     # Disk Devices
>
>     # A list of `diskspec' entries as described in
>
>     # docs/misc/xl-disk-configuration.txt
>
>     *disk =3D [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw',
>     'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r
>     <file:///%5C%5Croot%5Crhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r>' ]*
>
>     *boot=3D'cd'*
>
>     # Guest VGA console configuration, either SDL or VNC
>
>     # sdl =3D 1
>
>     *vnc =3D 2*
>
>     Thanks,
>
>     -Upanshu
>
>     Upanshu Singhal
>
>     EMC Data Storage Systems, Bangalore, India.
>
>     Phone: 91-80-67375604
>
>
>
>     _______________________________________________
>
>     Xen-devel mailing list
>
>     Xen-devel@lists.xen.org  <mailto:Xen-devel@lists.xen.org>
>
>     http://lists.xen.org/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 Dec 24 13:43:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 13:43:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3mDW-0007HA-GD; Wed, 24 Dec 2014 13:43:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3mDU-0007H4-6N
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 13:43:08 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	4E/07-22819-BE2CA945; Wed, 24 Dec 2014 13:43:07 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1419428585!15065271!1
X-Originating-IP: [66.165.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 17114 invoked from network); 24 Dec 2014 13:43:06 -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;
	24 Dec 2014 13:43:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,638,1413244800"; d="scan'208";a="207738682"
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.210.2; Wed, 24 Dec 2014 08:42: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 1Y3mDJ-00064J-Mi;
	Wed, 24 Dec 2014 13:42:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3mDJ-0005cU-EF;
	Wed, 24 Dec 2014 13:42:57 +0000
Date: Wed, 24 Dec 2014 13:42:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32611-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] 32611: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32611 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32611/

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. 32598
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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                                          fail    
 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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 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


Not pushing.

(No revision log; it would be 912 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 Dec 24 13:43:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 13:43:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3mDW-0007HA-GD; Wed, 24 Dec 2014 13:43:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3mDU-0007H4-6N
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 13:43:08 +0000
Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id
	4E/07-22819-BE2CA945; Wed, 24 Dec 2014 13:43:07 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1419428585!15065271!1
X-Originating-IP: [66.165.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 17114 invoked from network); 24 Dec 2014 13:43:06 -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;
	24 Dec 2014 13:43:06 -0000
X-IronPort-AV: E=Sophos;i="5.07,638,1413244800"; d="scan'208";a="207738682"
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.210.2; Wed, 24 Dec 2014 08:42: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 1Y3mDJ-00064J-Mi;
	Wed, 24 Dec 2014 13:42:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3mDJ-0005cU-EF;
	Wed, 24 Dec 2014 13:42:57 +0000
Date: Wed, 24 Dec 2014 13:42:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32611-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] 32611: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32611 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32611/

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. 32598
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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                                          fail    
 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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 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


Not pushing.

(No revision log; it would be 912 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 Dec 24 13:47:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 13: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 1Y3mHJ-0007QR-Dl; Wed, 24 Dec 2014 13:47:05 +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 1Y3mHH-0007QK-RM
	for xen-devel@lists.xen.org; Wed, 24 Dec 2014 13:47:04 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	DB/58-09284-7D3CA945; Wed, 24 Dec 2014 13:47:03 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1419428820!15643940!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29297 invoked from network); 24 Dec 2014 13:47:01 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Dec 2014 13:47:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1419428821; x=1450964821;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to;
	bh=CeStau8PcxrFTI9bWZ6IRcdPG08MM64CmKTQ5lnOBCw=;
	b=ZALNDbhETw3IKEzjArkx+Z5e+gzN6OZOyAcDD91Yt89jbhGo65OBh01n
	mQvvqY5OrZ7TwCiAUeepJsEDG/lipvtydHf+BCoz1jf8FViTTXIZLaC5S
	o0GiCaJ8E27ILvlGaNLq9HWnHgnJUrbvPMDyZkrf0r9mqDJqMlifmpna4 g=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by fldsmtpe04.verizon.com with ESMTP; 24 Dec 2014 13:46:59 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,638,1413244800"; 
	d="scan'208,217";a="938095070"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.107.144])
	by fldsmtpi01.verizon.com with ESMTP; 24 Dec 2014 13:46:58 +0000
Message-ID: <549AC3D1.5080105@terremark.com>
Date: Wed, 24 Dec 2014 08:46:57 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Singhal, Upanshu" <upanshu.singhal@emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
	<5494A6AF.1030802@terremark.com>
	<6A5D14D0DFEABC43BE832A0E492963F14EBB922A@MX101CL01.corp.emc.com>
In-Reply-To: <6A5D14D0DFEABC43BE832A0E492963F14EBB922A@MX101CL01.corp.emc.com>
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8099027545900942025=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8099027545900942025==
Content-Type: multipart/alternative;
 boundary="------------040707050204030006060308"

This is a multi-part message in MIME format.
--------------040707050204030006060308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 12/22/14 02:04, Singhal, Upanshu wrote:
>
> Hello Don,
>
> xen_emul_unplug=unnecessary does the trick, I am able to see the 
> vmxnet3 driver using lspci and ethtool --I eth0. Thanks a lot for your 
> help, much appreciated.
>
> Performance between vmxnet3 running on XEN is about 1/3 of vmxnet3 
> running on ESXi. Similar performance number I get between vmxnet3 on 
> ESXi and vif on XEN. Do you know what could be the reason for this?
>

Not sure, but mtu does have a factor here.

And the full network layout, other uses of network, etc. all have impacts.

Have you checked out:

http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide

I have not been investigating network bandwidth.

    -Don Slutz

> Thanks,
>
> -Upanshu
>
> *From:*Don Slutz [mailto:dslutz@verizon.com]
> *Sent:* Saturday, December 20, 2014 3:59 AM
> *To:* Singhal, Upanshu
> *Cc:* xen-devel@lists.xen.org
> *Subject:* Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
>
> xen_emul_unplug=unnecessary (kernel arg) may help you here.
>
> Also udev likes to rename your devices.
>
> Here is a lspci from a guest:
>
>
> [root@C63-min-tools ~]# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device 
> (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
> Ethernet Controller (rev 03)
> 00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
> Ethernet Controller (rev 03)
>
> And to help:
>
> [root@C63-min-tools ~]# ls -l /sys/class/net/*/device
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> 
> ../../../vif-0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> 
> ../../../vif-1
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> 
> ../../../vif-2
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> 
> ../../../vif-3
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> 
> ../../../vif-4
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> 
> ../../../vif-5
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> 
> ../../../vif-6
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> 
> ../../../vif-7
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> 
> ../../../vif-8
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> 
> ../../../vif-9
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device 
> -> ../../../0000:00:04.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device 
> -> ../../../0000:00:05.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device 
> -> ../../../0000:00:06.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device 
> -> ../../../0000:00:07.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device 
> -> ../../../0000:00:08.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device 
> -> ../../../0000:00:09.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device 
> -> ../../../0000:00:0a.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device 
> -> ../../../0000:00:0b.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device 
> -> ../../../0000:00:0c.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device 
> -> ../../../0000:00:0d.0
>
>
>    -Don Slutz
>
> On 12/19/14 07:04, Singhal, Upanshu wrote:
>
>     Hello,
>
>     In one of my experiment, I am building a Linux VM with Network
>     interface model as "vmxnet3". I am able to create the VM
>     successfully, but I see that the driver loaded is "vif" and not
>     "vmxnet3". I am using the following option for the network
>     interface: *vif = [ 'type=ioemu, mac=00:16:3e:00:00:22,
>     bridge=xenbr0, model=vmxnet3' ]*
>
>     **
>
>     I tried with model as e1000 and it works fine. Lspci command also
>     does not show vmxnet3. Though, qemu device help shows that
>     "vmxnet3" is supported on XEN 4.4.1 version I am using.
>
>     I tried searching on internet about the right configuration for
>     vmxnet3 with XEN, but not able to find right information. Can
>     someone please help me on how to create a VM with vmxnet3?
>
>     This experiment I am doing to compare the difference between
>     vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM
>     configuration file is:
>
>     # This configures an HVM rather than PV guest
>
>     builder = "hvm"
>
>     # Guest name
>
>     *name = "rhel-vmxnet3-xen-2.hvm"*
>
>     # 128-bit UUID for the domain as a hexadecimal number.
>
>     # Use "uuidgen" to generate one if required.
>
>     # The default behavior is to generate a new UUID each time the
>     guest is started.
>
>     #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
>
>     # Enable Microsoft Hyper-V compatibile paravirtualisation /
>
>     # enlightenment interfaces. Turning this on can improve Windows guest
>
>     # performance and is therefore recommended
>
>     #viridian = 1
>
>     # Initial memory allocation (MB)
>
>     *memory = 8192*
>
>     # Maximum memory (MB)
>
>     # If this is greater than `memory' then the slack will start ballooned
>
>     # (this assumes guest kernel support for ballooning)
>
>     #maxmem = 512
>
>     # Number of VCPUS
>
>     *vcpus = 8*
>
>     # Network devices
>
>     # A list of 'vifspec' entries as described in
>
>     # docs/misc/xl-network-configuration.markdown
>
>     vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr1,
>     model=vmxnet3' ]
>
>     # Disk Devices
>
>     # A list of `diskspec' entries as described in
>
>     # docs/misc/xl-disk-configuration.txt
>
>     *disk = [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw',
>     'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r
>     <file:///%5C%5Croot%5Crhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r>' ]*
>
>     *boot='cd'*
>
>     # Guest VGA console configuration, either SDL or VNC
>
>     # sdl = 1
>
>     *vnc = 2*
>
>     Thanks,
>
>     -Upanshu
>
>     Upanshu Singhal
>
>     EMC Data Storage Systems, Bangalore, India.
>
>     Phone: 91-80-67375604
>
>
>
>
>     _______________________________________________
>
>     Xen-devel mailing list
>
>     Xen-devel@lists.xen.org  <mailto:Xen-devel@lists.xen.org>
>
>     http://lists.xen.org/xen-devel
>


--------------040707050204030006060308
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">
    On 12/22/14 02:04, Singhal, Upanshu wrote:<br>
    <blockquote
cite="mid:6A5D14D0DFEABC43BE832A0E492963F14EBB922A@MX101CL01.corp.emc.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="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:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#1F497D">Hello Don,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal">xen_emul_unplug=unnecessary<span
            style="color:#1F497D"> &nbsp;does the trick, I am able to see the
            vmxnet3 driver using lspci and ethtool &#8211;I eth0. Thanks a lot
            for your help, much appreciated.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Performance
            between vmxnet3 running on XEN is about 1/3 of vmxnet3
            running on ESXi. Similar performance number I get between
            vmxnet3 on ESXi and vif on XEN. Do you know what could be
            the reason for this?<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
      </div>
    </blockquote>
    <br>
    Not sure, but mtu does have a factor here.<br>
    <br>
    And the full network layout, other uses of network, etc. all have
    impacts.<br>
    <br>
    Have you checked out:<br>
    <br>
    <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide">http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide</a><br>
    <br>
    I have not been investigating network bandwidth.<br>
    <br>
    &nbsp;&nbsp; -Don Slutz<br>
    <br>
    <blockquote
cite="mid:6A5D14D0DFEABC43BE832A0E492963F14EBB922A@MX101CL01.corp.emc.com"
      type="cite">
      <div class="WordSection1">
        <div>
          <p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
          <p class="MsoNormal"><span style="color:#1F497D">-Upanshu<o:p></o:p></span></p>
        </div>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">
                Don Slutz [<a class="moz-txt-link-freetext" href="mailto:dslutz@verizon.com">mailto:dslutz@verizon.com</a>]
                <br>
                <b>Sent:</b> Saturday, December 20, 2014 3:59 AM<br>
                <b>To:</b> Singhal, Upanshu<br>
                <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:xen-devel@lists.xen.org">xen-devel@lists.xen.org</a><br>
                <b>Subject:</b> Re: [Xen-devel] Help: VMXNET3 support
                with XEN 4.4.1<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal" style="margin-bottom:12.0pt">xen_emul_unplug=unnecessary
          (kernel arg) may help you here.<br>
          <br>
          Also udev likes to rename your devices.<br>
          <br>
          Here is a lspci from a guest:<br>
          <br>
          <br>
          [root@C63-min-tools ~]# lspci<br>
          00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC
          [Natoma] (rev 02)<br>
          00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA
          [Natoma/Triton II]<br>
          00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
          [Natoma/Triton II]<br>
          00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI
          (rev 03)<br>
          00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform
          Device (rev 01)<br>
          00:03.0 VGA compatible controller: Cirrus Logic GD 5446<br>
          00:04.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit
          Ethernet Controller (rev 03)<br>
          00:06.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:07.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:08.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:09.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit
          Ethernet Controller (rev 03)<br>
          <br>
          And to help:<br>
          <br>
          [root@C63-min-tools ~]# ls -l /sys/class/net/*/device<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth0/device -&gt; ../../../vif-0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth1/device -&gt; ../../../vif-1<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth2/device -&gt; ../../../vif-2<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth3/device -&gt; ../../../vif-3<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth4/device -&gt; ../../../vif-4<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth5/device -&gt; ../../../vif-5<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth6/device -&gt; ../../../vif-6<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth7/device -&gt; ../../../vif-7<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth8/device -&gt; ../../../vif-8<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth9/device -&gt; ../../../vif-9<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic0/device -&gt; ../../../0000:00:04.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic1/device -&gt; ../../../0000:00:05.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic2/device -&gt; ../../../0000:00:06.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic3/device -&gt; ../../../0000:00:07.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic4/device -&gt; ../../../0000:00:08.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic5/device -&gt; ../../../0000:00:09.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic6/device -&gt; ../../../0000:00:0a.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic7/device -&gt; ../../../0000:00:0b.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic8/device -&gt; ../../../0000:00:0c.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic9/device -&gt; ../../../0000:00:0d.0<br>
          <br>
          <br>
          &nbsp;&nbsp; -Don Slutz<br>
          <br>
          <o:p></o:p></p>
        <div>
          <p class="MsoNormal">On 12/19/14 07:04, Singhal, Upanshu
            wrote:<o:p></o:p></p>
        </div>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal">Hello,<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">In one of my experiment, I am building a
            Linux VM with Network interface model as &#8220;vmxnet3&#8221;. I am
            able to create the VM successfully, but I see that the
            driver loaded is &#8220;vif&#8221; and not &#8220;vmxnet3&#8221;. I am using the
            following option for the network interface: <b>vif = [
              'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0,
              model=vmxnet3' ]</b><o:p></o:p></p>
          <p class="MsoNormal"><b>&nbsp;</b><o:p></o:p></p>
          <p class="MsoNormal">I tried with model as e1000 and it works
            fine. Lspci command also does not show vmxnet3. Though, qemu
            device help shows that &#8220;vmxnet3&#8221; is supported on XEN 4.4.1
            version I am using.
            <o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">I tried searching on internet about the
            right configuration for vmxnet3 with XEN, but not able to
            find right information. Can someone please help me on how to
            create a VM with vmxnet3?<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">This experiment I am doing to compare the
            difference between vmxnet3 bandwidth on VMWARE ESXi vs. XEN
            Server. My sample VM configuration file is:<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># This configures an HVM rather than PV
            guest<o:p></o:p></p>
          <p class="MsoNormal">builder = "hvm"<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Guest name<o:p></o:p></p>
          <p class="MsoNormal"><b>name = "rhel-vmxnet3-xen-2.hvm"</b><o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># 128-bit UUID for the domain as a
            hexadecimal number.<o:p></o:p></p>
          <p class="MsoNormal"># Use "uuidgen" to generate one if
            required.<o:p></o:p></p>
          <p class="MsoNormal"># The default behavior is to generate a
            new UUID each time the guest is started.<o:p></o:p></p>
          <p class="MsoNormal">#uuid =
            "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Enable Microsoft Hyper-V compatibile
            paravirtualisation /<o:p></o:p></p>
          <p class="MsoNormal"># enlightenment interfaces. Turning this
            on can improve Windows guest<o:p></o:p></p>
          <p class="MsoNormal"># performance and is therefore
            recommended<o:p></o:p></p>
          <p class="MsoNormal">#viridian = 1<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Initial memory allocation (MB)<o:p></o:p></p>
          <p class="MsoNormal"><b>memory = 8192</b><o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Maximum memory (MB)<o:p></o:p></p>
          <p class="MsoNormal"># If this is greater than `memory' then
            the slack will start ballooned<o:p></o:p></p>
          <p class="MsoNormal"># (this assumes guest kernel support for
            ballooning)<o:p></o:p></p>
          <p class="MsoNormal">#maxmem = 512<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Number of VCPUS<o:p></o:p></p>
          <p class="MsoNormal"><b>vcpus = 8</b><o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Network devices<o:p></o:p></p>
          <p class="MsoNormal"># A list of 'vifspec' entries as
            described in<o:p></o:p></p>
          <p class="MsoNormal">#
            docs/misc/xl-network-configuration.markdown<o:p></o:p></p>
          <p class="MsoNormal">vif = [ 'type=ioemu,
            mac=00:16:3e:00:00:22, bridge=xenbr1, model=vmxnet3' ]<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Disk Devices<o:p></o:p></p>
          <p class="MsoNormal"># A list of `diskspec' entries as
            described in<o:p></o:p></p>
          <p class="MsoNormal"># docs/misc/xl-disk-configuration.txt<o:p></o:p></p>
          <p class="MsoNormal"><b>disk = [
              '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', '<a
                moz-do-not-send="true"
                href="file:///%5C%5Croot%5Crhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r">file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r</a>'
              ]</b><o:p></o:p></p>
          <p class="MsoNormal"><b>boot='cd'</b><o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Guest VGA console configuration, either
            SDL or VNC<o:p></o:p></p>
          <p class="MsoNormal"># sdl = 1<o:p></o:p></p>
          <p class="MsoNormal"><b>vnc = 2</b><o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">Thanks,<o:p></o:p></p>
          <p class="MsoNormal">-Upanshu<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">Upanshu Singhal<o:p></o:p></p>
          <p class="MsoNormal">EMC Data Storage Systems, Bangalore,
            India.<o:p></o:p></p>
          <p class="MsoNormal">Phone: 91-80-67375604<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:12.0pt;font-family:&quot;Times New
              Roman&quot;,&quot;serif&quot;"><br>
              <br>
              <br>
              <o:p></o:p></span></p>
          <pre>_______________________________________________<o:p></o:p></pre>
          <pre>Xen-devel mailing list<o:p></o:p></pre>
          <pre><a moz-do-not-send="true" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><o:p></o:p></pre>
          <pre><a moz-do-not-send="true" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a><o:p></o:p></pre>
        </blockquote>
        <p class="MsoNormal"><span
            style="font-size:12.0pt;font-family:&quot;Times New
            Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------040707050204030006060308--


--===============8099027545900942025==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8099027545900942025==--


From xen-devel-bounces@lists.xen.org Wed Dec 24 13:47:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 13: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 1Y3mHJ-0007QR-Dl; Wed, 24 Dec 2014 13:47:05 +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 1Y3mHH-0007QK-RM
	for xen-devel@lists.xen.org; Wed, 24 Dec 2014 13:47:04 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	DB/58-09284-7D3CA945; Wed, 24 Dec 2014 13:47:03 +0000
X-Env-Sender: dslutz@verizon.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1419428820!15643940!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29297 invoked from network); 24 Dec 2014 13:47:01 -0000
Received: from fldsmtpe04.verizon.com (HELO fldsmtpe04.verizon.com)
	(140.108.26.143)
	by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Dec 2014 13:47:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=verizon.com; i=dslutz@verizon.com; q=dns/txt; s=corp;
	t=1419428821; x=1450964821;
	h=from:message-id:date:mime-version:to:cc:subject:
	references:in-reply-to;
	bh=CeStau8PcxrFTI9bWZ6IRcdPG08MM64CmKTQ5lnOBCw=;
	b=ZALNDbhETw3IKEzjArkx+Z5e+gzN6OZOyAcDD91Yt89jbhGo65OBh01n
	mQvvqY5OrZ7TwCiAUeepJsEDG/lipvtydHf+BCoz1jf8FViTTXIZLaC5S
	o0GiCaJ8E27ILvlGaNLq9HWnHgnJUrbvPMDyZkrf0r9mqDJqMlifmpna4 g=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143])
	by fldsmtpe04.verizon.com with ESMTP; 24 Dec 2014 13:46:59 +0000
From: Don Slutz <dslutz@verizon.com>
X-VzAPP: 1
X-IronPort-AV: E=Sophos;i="5.07,638,1413244800"; 
	d="scan'208,217";a="938095070"
Received: from unknown (HELO don-lt.don.CloudSwitch.com) ([70.105.107.144])
	by fldsmtpi01.verizon.com with ESMTP; 24 Dec 2014 13:46:58 +0000
Message-ID: <549AC3D1.5080105@terremark.com>
Date: Wed, 24 Dec 2014 08:46:57 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Singhal, Upanshu" <upanshu.singhal@emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
	<5494A6AF.1030802@terremark.com>
	<6A5D14D0DFEABC43BE832A0E492963F14EBB922A@MX101CL01.corp.emc.com>
In-Reply-To: <6A5D14D0DFEABC43BE832A0E492963F14EBB922A@MX101CL01.corp.emc.com>
Cc: Don Slutz <dslutz@verizon.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8099027545900942025=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8099027545900942025==
Content-Type: multipart/alternative;
 boundary="------------040707050204030006060308"

This is a multi-part message in MIME format.
--------------040707050204030006060308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 12/22/14 02:04, Singhal, Upanshu wrote:
>
> Hello Don,
>
> xen_emul_unplug=unnecessary does the trick, I am able to see the 
> vmxnet3 driver using lspci and ethtool --I eth0. Thanks a lot for your 
> help, much appreciated.
>
> Performance between vmxnet3 running on XEN is about 1/3 of vmxnet3 
> running on ESXi. Similar performance number I get between vmxnet3 on 
> ESXi and vif on XEN. Do you know what could be the reason for this?
>

Not sure, but mtu does have a factor here.

And the full network layout, other uses of network, etc. all have impacts.

Have you checked out:

http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide

I have not been investigating network bandwidth.

    -Don Slutz

> Thanks,
>
> -Upanshu
>
> *From:*Don Slutz [mailto:dslutz@verizon.com]
> *Sent:* Saturday, December 20, 2014 3:59 AM
> *To:* Singhal, Upanshu
> *Cc:* xen-devel@lists.xen.org
> *Subject:* Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
>
> xen_emul_unplug=unnecessary (kernel arg) may help you here.
>
> Also udev likes to rename your devices.
>
> Here is a lspci from a guest:
>
>
> [root@C63-min-tools ~]# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device 
> (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
> Ethernet Controller (rev 03)
> 00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
> 00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
> Ethernet Controller (rev 03)
>
> And to help:
>
> [root@C63-min-tools ~]# ls -l /sys/class/net/*/device
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> 
> ../../../vif-0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> 
> ../../../vif-1
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> 
> ../../../vif-2
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> 
> ../../../vif-3
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> 
> ../../../vif-4
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> 
> ../../../vif-5
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> 
> ../../../vif-6
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> 
> ../../../vif-7
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> 
> ../../../vif-8
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> 
> ../../../vif-9
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device 
> -> ../../../0000:00:04.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device 
> -> ../../../0000:00:05.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device 
> -> ../../../0000:00:06.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device 
> -> ../../../0000:00:07.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device 
> -> ../../../0000:00:08.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device 
> -> ../../../0000:00:09.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device 
> -> ../../../0000:00:0a.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device 
> -> ../../../0000:00:0b.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device 
> -> ../../../0000:00:0c.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device 
> -> ../../../0000:00:0d.0
>
>
>    -Don Slutz
>
> On 12/19/14 07:04, Singhal, Upanshu wrote:
>
>     Hello,
>
>     In one of my experiment, I am building a Linux VM with Network
>     interface model as "vmxnet3". I am able to create the VM
>     successfully, but I see that the driver loaded is "vif" and not
>     "vmxnet3". I am using the following option for the network
>     interface: *vif = [ 'type=ioemu, mac=00:16:3e:00:00:22,
>     bridge=xenbr0, model=vmxnet3' ]*
>
>     **
>
>     I tried with model as e1000 and it works fine. Lspci command also
>     does not show vmxnet3. Though, qemu device help shows that
>     "vmxnet3" is supported on XEN 4.4.1 version I am using.
>
>     I tried searching on internet about the right configuration for
>     vmxnet3 with XEN, but not able to find right information. Can
>     someone please help me on how to create a VM with vmxnet3?
>
>     This experiment I am doing to compare the difference between
>     vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM
>     configuration file is:
>
>     # This configures an HVM rather than PV guest
>
>     builder = "hvm"
>
>     # Guest name
>
>     *name = "rhel-vmxnet3-xen-2.hvm"*
>
>     # 128-bit UUID for the domain as a hexadecimal number.
>
>     # Use "uuidgen" to generate one if required.
>
>     # The default behavior is to generate a new UUID each time the
>     guest is started.
>
>     #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
>
>     # Enable Microsoft Hyper-V compatibile paravirtualisation /
>
>     # enlightenment interfaces. Turning this on can improve Windows guest
>
>     # performance and is therefore recommended
>
>     #viridian = 1
>
>     # Initial memory allocation (MB)
>
>     *memory = 8192*
>
>     # Maximum memory (MB)
>
>     # If this is greater than `memory' then the slack will start ballooned
>
>     # (this assumes guest kernel support for ballooning)
>
>     #maxmem = 512
>
>     # Number of VCPUS
>
>     *vcpus = 8*
>
>     # Network devices
>
>     # A list of 'vifspec' entries as described in
>
>     # docs/misc/xl-network-configuration.markdown
>
>     vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr1,
>     model=vmxnet3' ]
>
>     # Disk Devices
>
>     # A list of `diskspec' entries as described in
>
>     # docs/misc/xl-disk-configuration.txt
>
>     *disk = [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw',
>     'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r
>     <file:///%5C%5Croot%5Crhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r>' ]*
>
>     *boot='cd'*
>
>     # Guest VGA console configuration, either SDL or VNC
>
>     # sdl = 1
>
>     *vnc = 2*
>
>     Thanks,
>
>     -Upanshu
>
>     Upanshu Singhal
>
>     EMC Data Storage Systems, Bangalore, India.
>
>     Phone: 91-80-67375604
>
>
>
>
>     _______________________________________________
>
>     Xen-devel mailing list
>
>     Xen-devel@lists.xen.org  <mailto:Xen-devel@lists.xen.org>
>
>     http://lists.xen.org/xen-devel
>


--------------040707050204030006060308
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">
    On 12/22/14 02:04, Singhal, Upanshu wrote:<br>
    <blockquote
cite="mid:6A5D14D0DFEABC43BE832A0E492963F14EBB922A@MX101CL01.corp.emc.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="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:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#1F497D">Hello Don,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal">xen_emul_unplug=unnecessary<span
            style="color:#1F497D"> &nbsp;does the trick, I am able to see the
            vmxnet3 driver using lspci and ethtool &#8211;I eth0. Thanks a lot
            for your help, much appreciated.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Performance
            between vmxnet3 running on XEN is about 1/3 of vmxnet3
            running on ESXi. Similar performance number I get between
            vmxnet3 on ESXi and vif on XEN. Do you know what could be
            the reason for this?<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
      </div>
    </blockquote>
    <br>
    Not sure, but mtu does have a factor here.<br>
    <br>
    And the full network layout, other uses of network, etc. all have
    impacts.<br>
    <br>
    Have you checked out:<br>
    <br>
    <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide">http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide</a><br>
    <br>
    I have not been investigating network bandwidth.<br>
    <br>
    &nbsp;&nbsp; -Don Slutz<br>
    <br>
    <blockquote
cite="mid:6A5D14D0DFEABC43BE832A0E492963F14EBB922A@MX101CL01.corp.emc.com"
      type="cite">
      <div class="WordSection1">
        <div>
          <p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
          <p class="MsoNormal"><span style="color:#1F497D">-Upanshu<o:p></o:p></span></p>
        </div>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">
                Don Slutz [<a class="moz-txt-link-freetext" href="mailto:dslutz@verizon.com">mailto:dslutz@verizon.com</a>]
                <br>
                <b>Sent:</b> Saturday, December 20, 2014 3:59 AM<br>
                <b>To:</b> Singhal, Upanshu<br>
                <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:xen-devel@lists.xen.org">xen-devel@lists.xen.org</a><br>
                <b>Subject:</b> Re: [Xen-devel] Help: VMXNET3 support
                with XEN 4.4.1<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal" style="margin-bottom:12.0pt">xen_emul_unplug=unnecessary
          (kernel arg) may help you here.<br>
          <br>
          Also udev likes to rename your devices.<br>
          <br>
          Here is a lspci from a guest:<br>
          <br>
          <br>
          [root@C63-min-tools ~]# lspci<br>
          00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC
          [Natoma] (rev 02)<br>
          00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA
          [Natoma/Triton II]<br>
          00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
          [Natoma/Triton II]<br>
          00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI
          (rev 03)<br>
          00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform
          Device (rev 01)<br>
          00:03.0 VGA compatible controller: Cirrus Logic GD 5446<br>
          00:04.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit
          Ethernet Controller (rev 03)<br>
          00:06.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:07.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:08.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:09.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet
          Controller (rev 01)<br>
          00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit
          Ethernet Controller (rev 03)<br>
          <br>
          And to help:<br>
          <br>
          [root@C63-min-tools ~]# ls -l /sys/class/net/*/device<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth0/device -&gt; ../../../vif-0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth1/device -&gt; ../../../vif-1<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth2/device -&gt; ../../../vif-2<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth3/device -&gt; ../../../vif-3<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth4/device -&gt; ../../../vif-4<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth5/device -&gt; ../../../vif-5<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth6/device -&gt; ../../../vif-6<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth7/device -&gt; ../../../vif-7<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth8/device -&gt; ../../../vif-8<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:23
          /sys/class/net/eth9/device -&gt; ../../../vif-9<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic0/device -&gt; ../../../0000:00:04.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic1/device -&gt; ../../../0000:00:05.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic2/device -&gt; ../../../0000:00:06.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic3/device -&gt; ../../../0000:00:07.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic4/device -&gt; ../../../0000:00:08.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic5/device -&gt; ../../../0000:00:09.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic6/device -&gt; ../../../0000:00:0a.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic7/device -&gt; ../../../0000:00:0b.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic8/device -&gt; ../../../0000:00:0c.0<br>
          lrwxrwxrwx. 1 root root 0 Dec 19 17:21
          /sys/class/net/pci-nic9/device -&gt; ../../../0000:00:0d.0<br>
          <br>
          <br>
          &nbsp;&nbsp; -Don Slutz<br>
          <br>
          <o:p></o:p></p>
        <div>
          <p class="MsoNormal">On 12/19/14 07:04, Singhal, Upanshu
            wrote:<o:p></o:p></p>
        </div>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal">Hello,<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">In one of my experiment, I am building a
            Linux VM with Network interface model as &#8220;vmxnet3&#8221;. I am
            able to create the VM successfully, but I see that the
            driver loaded is &#8220;vif&#8221; and not &#8220;vmxnet3&#8221;. I am using the
            following option for the network interface: <b>vif = [
              'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0,
              model=vmxnet3' ]</b><o:p></o:p></p>
          <p class="MsoNormal"><b>&nbsp;</b><o:p></o:p></p>
          <p class="MsoNormal">I tried with model as e1000 and it works
            fine. Lspci command also does not show vmxnet3. Though, qemu
            device help shows that &#8220;vmxnet3&#8221; is supported on XEN 4.4.1
            version I am using.
            <o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">I tried searching on internet about the
            right configuration for vmxnet3 with XEN, but not able to
            find right information. Can someone please help me on how to
            create a VM with vmxnet3?<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">This experiment I am doing to compare the
            difference between vmxnet3 bandwidth on VMWARE ESXi vs. XEN
            Server. My sample VM configuration file is:<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># This configures an HVM rather than PV
            guest<o:p></o:p></p>
          <p class="MsoNormal">builder = "hvm"<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Guest name<o:p></o:p></p>
          <p class="MsoNormal"><b>name = "rhel-vmxnet3-xen-2.hvm"</b><o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># 128-bit UUID for the domain as a
            hexadecimal number.<o:p></o:p></p>
          <p class="MsoNormal"># Use "uuidgen" to generate one if
            required.<o:p></o:p></p>
          <p class="MsoNormal"># The default behavior is to generate a
            new UUID each time the guest is started.<o:p></o:p></p>
          <p class="MsoNormal">#uuid =
            "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Enable Microsoft Hyper-V compatibile
            paravirtualisation /<o:p></o:p></p>
          <p class="MsoNormal"># enlightenment interfaces. Turning this
            on can improve Windows guest<o:p></o:p></p>
          <p class="MsoNormal"># performance and is therefore
            recommended<o:p></o:p></p>
          <p class="MsoNormal">#viridian = 1<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Initial memory allocation (MB)<o:p></o:p></p>
          <p class="MsoNormal"><b>memory = 8192</b><o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Maximum memory (MB)<o:p></o:p></p>
          <p class="MsoNormal"># If this is greater than `memory' then
            the slack will start ballooned<o:p></o:p></p>
          <p class="MsoNormal"># (this assumes guest kernel support for
            ballooning)<o:p></o:p></p>
          <p class="MsoNormal">#maxmem = 512<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Number of VCPUS<o:p></o:p></p>
          <p class="MsoNormal"><b>vcpus = 8</b><o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Network devices<o:p></o:p></p>
          <p class="MsoNormal"># A list of 'vifspec' entries as
            described in<o:p></o:p></p>
          <p class="MsoNormal">#
            docs/misc/xl-network-configuration.markdown<o:p></o:p></p>
          <p class="MsoNormal">vif = [ 'type=ioemu,
            mac=00:16:3e:00:00:22, bridge=xenbr1, model=vmxnet3' ]<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Disk Devices<o:p></o:p></p>
          <p class="MsoNormal"># A list of `diskspec' entries as
            described in<o:p></o:p></p>
          <p class="MsoNormal"># docs/misc/xl-disk-configuration.txt<o:p></o:p></p>
          <p class="MsoNormal"><b>disk = [
              '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', '<a
                moz-do-not-send="true"
                href="file:///%5C%5Croot%5Crhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r">file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r</a>'
              ]</b><o:p></o:p></p>
          <p class="MsoNormal"><b>boot='cd'</b><o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"># Guest VGA console configuration, either
            SDL or VNC<o:p></o:p></p>
          <p class="MsoNormal"># sdl = 1<o:p></o:p></p>
          <p class="MsoNormal"><b>vnc = 2</b><o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">Thanks,<o:p></o:p></p>
          <p class="MsoNormal">-Upanshu<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">Upanshu Singhal<o:p></o:p></p>
          <p class="MsoNormal">EMC Data Storage Systems, Bangalore,
            India.<o:p></o:p></p>
          <p class="MsoNormal">Phone: 91-80-67375604<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:12.0pt;font-family:&quot;Times New
              Roman&quot;,&quot;serif&quot;"><br>
              <br>
              <br>
              <o:p></o:p></span></p>
          <pre>_______________________________________________<o:p></o:p></pre>
          <pre>Xen-devel mailing list<o:p></o:p></pre>
          <pre><a moz-do-not-send="true" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><o:p></o:p></pre>
          <pre><a moz-do-not-send="true" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a><o:p></o:p></pre>
        </blockquote>
        <p class="MsoNormal"><span
            style="font-size:12.0pt;font-family:&quot;Times New
            Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------040707050204030006060308--


--===============8099027545900942025==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8099027545900942025==--


From xen-devel-bounces@lists.xen.org Wed Dec 24 14:37:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 14: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 1Y3n3A-00007W-Oq; Wed, 24 Dec 2014 14:36:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mleitner@redhat.com>) id 1Y35hg-0006KS-Lx
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 16:19:28 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	68/0E-09284-F8448945; Mon, 22 Dec 2014 16:19:27 +0000
X-Env-Sender: mleitner@redhat.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419265165!15182635!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2308 invoked from network); 22 Dec 2014 16:19:26 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Dec 2014 16:19:26 -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 sBMGJF0n024397
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 22 Dec 2014 11:19:16 -0500
Received: from localhost.localdomain (ovpn-113-187.phx2.redhat.com
	[10.3.113.187])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBMGJC89007192; Mon, 22 Dec 2014 11:19:13 -0500
Message-ID: <54984480.1070206@redhat.com>
Date: Mon, 22 Dec 2014 14:19:12 -0200
From: Marcelo Ricardo Leitner <mleitner@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Herbert Xu <herbert@gondor.apana.org.au>,
	David Vrabel <david.vrabel@citrix.com>
References: <20141220002327.GA31975@gondor.apana.org.au>
In-Reply-To: <20141220002327.GA31975@gondor.apana.org.au>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 24 Dec 2014 14:36:31 +0000
Cc: netdev@vger.kernel.org, edumazet@google.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, "David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] virtio_net: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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-12-2014 22:23, Herbert Xu wrote:
> David Vrabel <david.vrabel@citrix.com> wrote:
>> After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
>> masking in NAPI) the napi instance is removed from the per-cpu list
>> prior to calling the n->poll(), and is only requeued if all of the
>> budget was used.  This inadvertently broke netfront because netfront
>> does not use NAPI correctly.
>
> A similar bug exists in virtio_net.
>
> -- >8 --
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) breaks virtio_net in an insidious way.
>
> It is now required that if the entire budget is consumed when poll
> returns, the napi poll_list must remain empty.  However, like some
> other drivers virtio_net tries to do a last-ditch check and if
> there is more work it will call napi_schedule and then immediately
> process some of this new work.  Should the entire budget be consumed
> while processing such new work then we will violate the new caller
> contract.
>
> This patch fixes this by not touching any work when we reschedule
> in virtio_net.
>
> The worst part of this bug is that the list corruption causes other
> napi users to be moved off-list.  In my case I was chasing a stall
> in IPsec (IPsec uses netif_rx) and I only belatedly realised that it
> was virtio_net which caused the stall even though the virtio_net
> poll was still functioning perfectly after IPsec stalled.

Thanks for finding/fixing this, Herbert. I was debugging this one too. In my 
case, vxlan interface was getting stuck.

   Marcelo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 14:37:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 14: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 1Y3n3B-00007d-3d; Wed, 24 Dec 2014 14:36:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cathy.avery@oracle.com>) id 1Y3UlU-0003Q8-Qe
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 19:05:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AC/B0-15461-0ECB9945; Tue, 23 Dec 2014 19:05:04 +0000
X-Env-Sender: cathy.avery@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1419361502!10243149!1
X-Originating-IP: [156.151.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 12789 invoked from network); 23 Dec 2014 19:05:03 -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; 23 Dec 2014 19:05: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 sBNJ4tf5012911
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Dec 2014 19:04:56 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
	sBNJ4s34023550
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 23 Dec 2014 19:04:54 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
	sBNJ4sQH023543; Tue, 23 Dec 2014 19:04:54 GMT
Received: from cavery-ThinkPad-X230.us.oracle.com (/10.149.239.10)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Dec 2014 11:04:54 -0800
From: Cathy Avery <cathy.avery@oracle.com>
To: ian.campbell@citrix.com, ian.jackson@eu.citrix.com, jbeulich@suse.com,
	keir@xen.org, tim@xen.org, xen-devel@lists.xen.org
Date: Tue, 23 Dec 2014 14:04:28 -0500
Message-Id: <1419361468-5921-1-git-send-email-cathy.avery@oracle.com>
X-Mailer: git-send-email 1.9.1
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Mailman-Approved-At: Wed, 24 Dec 2014 14:36:31 +0000
Cc: Cathy Avery <cathy.avery@oracle.com>
Subject: [Xen-devel] [PATCH] xc Python ext lib: Xen 4.6 Unable to start a 2T
	guest without OverflowError
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Starting a vm with memory over 2T resulted in an overflow error.

memory = 2097152 defined as number of megabytes returns the error
"OverflowError: signed integer is greater than maximum"

The error is the result of the python extension argument translator
defining max_memkb as a signed int instead of an unsigned int.
So PyArg_ParseTuple(args, "ii", &dom, &maxmem_kb) overflowed by one with
2147483648 kb.

The other issue is that max_memkb is defined as uint64_t in the subsequent
domctl target api so the xc lib and its python C extension should use uint64_t as well.

/* XEN_DOMCTL_max_mem */
struct xen_domctl_max_mem {
    /* IN variables. */
    uint64_aligned_t max_memkb;
};

Signed-off-by: Cathy Avery <cathy.avery@oracle.com>
---
 tools/libxc/include/xenctrl.h     |    2 +-
 tools/libxc/xc_domain.c           |    2 +-
 tools/python/xen/lowlevel/xc/xc.c |    4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..1b5c622 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1253,7 +1253,7 @@ int xc_getcpuinfo(xc_interface *xch, int max_cpus,
 
 int xc_domain_setmaxmem(xc_interface *xch,
                         uint32_t domid,
-                        unsigned int max_memkb);
+                        uint64_t max_memkb);
 
 int xc_domain_set_memmap_limit(xc_interface *xch,
                                uint32_t domid,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index b864872..2c0fc9f 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -630,7 +630,7 @@ int xc_shadow_control(xc_interface *xch,
 
 int xc_domain_setmaxmem(xc_interface *xch,
                         uint32_t domid,
-                        unsigned int max_memkb)
+                        uint64_t max_memkb)
 {
     DECLARE_DOMCTL;
     domctl.cmd = XEN_DOMCTL_max_mem;
diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
index f83e33d..7a5d36e 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1658,9 +1658,9 @@ static PyObject *pyxc_sched_credit2_domain_get(XcObject *self, PyObject *args)
 static PyObject *pyxc_domain_setmaxmem(XcObject *self, PyObject *args)
 {
     uint32_t dom;
-    unsigned int maxmem_kb;
+    uint64_t maxmem_kb;
 
-    if (!PyArg_ParseTuple(args, "ii", &dom, &maxmem_kb))
+    if (!PyArg_ParseTuple(args, "ik", &dom, &maxmem_kb))
         return NULL;
 
     if (xc_domain_setmaxmem(self->xc_handle, dom, maxmem_kb) != 0)
-- 
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 Wed Dec 24 14:37:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 14: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 1Y3n3A-00007W-Oq; Wed, 24 Dec 2014 14:36:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mleitner@redhat.com>) id 1Y35hg-0006KS-Lx
	for xen-devel@lists.xenproject.org; Mon, 22 Dec 2014 16:19:28 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	68/0E-09284-F8448945; Mon, 22 Dec 2014 16:19:27 +0000
X-Env-Sender: mleitner@redhat.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419265165!15182635!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2308 invoked from network); 22 Dec 2014 16:19:26 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Dec 2014 16:19:26 -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 sBMGJF0n024397
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL); Mon, 22 Dec 2014 11:19:16 -0500
Received: from localhost.localdomain (ovpn-113-187.phx2.redhat.com
	[10.3.113.187])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id sBMGJC89007192; Mon, 22 Dec 2014 11:19:13 -0500
Message-ID: <54984480.1070206@redhat.com>
Date: Mon, 22 Dec 2014 14:19:12 -0200
From: Marcelo Ricardo Leitner <mleitner@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Herbert Xu <herbert@gondor.apana.org.au>,
	David Vrabel <david.vrabel@citrix.com>
References: <20141220002327.GA31975@gondor.apana.org.au>
In-Reply-To: <20141220002327.GA31975@gondor.apana.org.au>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 24 Dec 2014 14:36:31 +0000
Cc: netdev@vger.kernel.org, edumazet@google.com, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, "David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] virtio_net: Fix napi poll list corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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-12-2014 22:23, Herbert Xu wrote:
> David Vrabel <david.vrabel@citrix.com> wrote:
>> After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
>> masking in NAPI) the napi instance is removed from the per-cpu list
>> prior to calling the n->poll(), and is only requeued if all of the
>> budget was used.  This inadvertently broke netfront because netfront
>> does not use NAPI correctly.
>
> A similar bug exists in virtio_net.
>
> -- >8 --
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) breaks virtio_net in an insidious way.
>
> It is now required that if the entire budget is consumed when poll
> returns, the napi poll_list must remain empty.  However, like some
> other drivers virtio_net tries to do a last-ditch check and if
> there is more work it will call napi_schedule and then immediately
> process some of this new work.  Should the entire budget be consumed
> while processing such new work then we will violate the new caller
> contract.
>
> This patch fixes this by not touching any work when we reschedule
> in virtio_net.
>
> The worst part of this bug is that the list corruption causes other
> napi users to be moved off-list.  In my case I was chasing a stall
> in IPsec (IPsec uses netif_rx) and I only belatedly realised that it
> was virtio_net which caused the stall even though the virtio_net
> poll was still functioning perfectly after IPsec stalled.

Thanks for finding/fixing this, Herbert. I was debugging this one too. In my 
case, vxlan interface was getting stuck.

   Marcelo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 14:37:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 14: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 1Y3n3B-00007d-3d; Wed, 24 Dec 2014 14:36:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cathy.avery@oracle.com>) id 1Y3UlU-0003Q8-Qe
	for xen-devel@lists.xen.org; Tue, 23 Dec 2014 19:05:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	AC/B0-15461-0ECB9945; Tue, 23 Dec 2014 19:05:04 +0000
X-Env-Sender: cathy.avery@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1419361502!10243149!1
X-Originating-IP: [156.151.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 12789 invoked from network); 23 Dec 2014 19:05:03 -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; 23 Dec 2014 19:05: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 sBNJ4tf5012911
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Dec 2014 19:04:56 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
	sBNJ4s34023550
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 23 Dec 2014 19:04:54 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
	sBNJ4sQH023543; Tue, 23 Dec 2014 19:04:54 GMT
Received: from cavery-ThinkPad-X230.us.oracle.com (/10.149.239.10)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Dec 2014 11:04:54 -0800
From: Cathy Avery <cathy.avery@oracle.com>
To: ian.campbell@citrix.com, ian.jackson@eu.citrix.com, jbeulich@suse.com,
	keir@xen.org, tim@xen.org, xen-devel@lists.xen.org
Date: Tue, 23 Dec 2014 14:04:28 -0500
Message-Id: <1419361468-5921-1-git-send-email-cathy.avery@oracle.com>
X-Mailer: git-send-email 1.9.1
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Mailman-Approved-At: Wed, 24 Dec 2014 14:36:31 +0000
Cc: Cathy Avery <cathy.avery@oracle.com>
Subject: [Xen-devel] [PATCH] xc Python ext lib: Xen 4.6 Unable to start a 2T
	guest without OverflowError
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Starting a vm with memory over 2T resulted in an overflow error.

memory = 2097152 defined as number of megabytes returns the error
"OverflowError: signed integer is greater than maximum"

The error is the result of the python extension argument translator
defining max_memkb as a signed int instead of an unsigned int.
So PyArg_ParseTuple(args, "ii", &dom, &maxmem_kb) overflowed by one with
2147483648 kb.

The other issue is that max_memkb is defined as uint64_t in the subsequent
domctl target api so the xc lib and its python C extension should use uint64_t as well.

/* XEN_DOMCTL_max_mem */
struct xen_domctl_max_mem {
    /* IN variables. */
    uint64_aligned_t max_memkb;
};

Signed-off-by: Cathy Avery <cathy.avery@oracle.com>
---
 tools/libxc/include/xenctrl.h     |    2 +-
 tools/libxc/xc_domain.c           |    2 +-
 tools/python/xen/lowlevel/xc/xc.c |    4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..1b5c622 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1253,7 +1253,7 @@ int xc_getcpuinfo(xc_interface *xch, int max_cpus,
 
 int xc_domain_setmaxmem(xc_interface *xch,
                         uint32_t domid,
-                        unsigned int max_memkb);
+                        uint64_t max_memkb);
 
 int xc_domain_set_memmap_limit(xc_interface *xch,
                                uint32_t domid,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index b864872..2c0fc9f 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -630,7 +630,7 @@ int xc_shadow_control(xc_interface *xch,
 
 int xc_domain_setmaxmem(xc_interface *xch,
                         uint32_t domid,
-                        unsigned int max_memkb)
+                        uint64_t max_memkb)
 {
     DECLARE_DOMCTL;
     domctl.cmd = XEN_DOMCTL_max_mem;
diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
index f83e33d..7a5d36e 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1658,9 +1658,9 @@ static PyObject *pyxc_sched_credit2_domain_get(XcObject *self, PyObject *args)
 static PyObject *pyxc_domain_setmaxmem(XcObject *self, PyObject *args)
 {
     uint32_t dom;
-    unsigned int maxmem_kb;
+    uint64_t maxmem_kb;
 
-    if (!PyArg_ParseTuple(args, "ii", &dom, &maxmem_kb))
+    if (!PyArg_ParseTuple(args, "ik", &dom, &maxmem_kb))
         return NULL;
 
     if (xc_domain_setmaxmem(self->xc_handle, dom, maxmem_kb) != 0)
-- 
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 Wed Dec 24 17:04:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 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 1Y3pLv-0003fZ-MD; Wed, 24 Dec 2014 17:04: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 1Y3pLu-0003fS-QG
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 17:04:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	06/FB-25276-202FA945; Wed, 24 Dec 2014 17:04:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419440640!17723127!1
X-Originating-IP: [66.165.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 9108 invoked from network); 24 Dec 2014 17:04:01 -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;
	24 Dec 2014 17:04:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,638,1413244800"; d="scan'208";a="208325868"
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.210.2; Wed, 24 Dec 2014 12:03: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 1Y3pLp-00072A-Qn;
	Wed, 24 Dec 2014 17:03:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3pLp-0006eW-KI;
	Wed, 24 Dec 2014 17:03:57 +0000
Date: Wed, 24 Dec 2014 17:03:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32612-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] 32612: 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 32612 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32612/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-amd64 13 guest-localmigrate/x10 fail pass in 32594
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot    fail in 32594 pass in 32612

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32594
 test-amd64-amd64-xl-sedf      7 debian-install        fail in 32594 like 32574

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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                     fail    
 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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 Dec 24 17:04:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 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 1Y3pLv-0003fZ-MD; Wed, 24 Dec 2014 17:04: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 1Y3pLu-0003fS-QG
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 17:04:03 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	06/FB-25276-202FA945; Wed, 24 Dec 2014 17:04:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419440640!17723127!1
X-Originating-IP: [66.165.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 9108 invoked from network); 24 Dec 2014 17:04:01 -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;
	24 Dec 2014 17:04:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,638,1413244800"; d="scan'208";a="208325868"
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.210.2; Wed, 24 Dec 2014 12:03: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 1Y3pLp-00072A-Qn;
	Wed, 24 Dec 2014 17:03:57 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3pLp-0006eW-KI;
	Wed, 24 Dec 2014 17:03:57 +0000
Date: Wed, 24 Dec 2014 17:03:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32612-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] 32612: 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 32612 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32612/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-amd64 13 guest-localmigrate/x10 fail pass in 32594
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-boot    fail in 32594 pass in 32612

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32594
 test-amd64-amd64-xl-sedf      7 debian-install        fail in 32594 like 32574

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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                     fail    
 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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 Dec 24 17:29:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 17:29:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3pk0-0004DI-6p; Wed, 24 Dec 2014 17:28: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 1Y3pjz-0004DD-2h
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 17:28:55 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	7A/71-25727-6D7FA945; Wed, 24 Dec 2014 17:28:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419442132!15687231!1
X-Originating-IP: [66.165.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 3196 invoked from network); 24 Dec 2014 17:28:53 -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;
	24 Dec 2014 17:28:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,639,1413244800"; d="scan'208";a="207819570"
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.210.2; Wed, 24 Dec 2014 12:28: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 1Y3pju-00079V-82;
	Wed, 24 Dec 2014 17:28:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3pjt-0000PD-H9;
	Wed, 24 Dec 2014 17:28:49 +0000
Date: Wed, 24 Dec 2014 17:28:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32617-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] 32617: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32617 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32617/

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. 32596

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-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              7c6dbf35183aa636ae31290beef14af937a3b248
baseline version:
 libvirt              3865941be1fa5466d7892b24f1a2d7ee14f86712

------------------------------------------------------------
People who touched revisions under test:
  Dmitry Guryanov <dguryanov@parallels.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                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 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


Not pushing.

------------------------------------------------------------
commit 7c6dbf35183aa636ae31290beef14af937a3b248
Author: Dmitry Guryanov <dguryanov@parallels.com>
Date:   Tue Dec 23 16:23:34 2014 +0300

    parallels: report, that cdrom image is raw
    
    VIR_STORAGE_FILE_AUTO should be used only in xml provided to
    libvirt by user, if I understood correctly. Driver should
    set storage source format to specific disk format in
    *DomainGetXMLDesc.
    
    CDROMs in PCS use raw image format.
    
    Signed-off-by: Dmitry Guryanov <dguryanov@parallels.com>

commit 42dc7a471d18c01a8e2fbff28c3b6c801ace37cd
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Tue Dec 23 06:10:55 2014 +0100

    tests: Set up two more overrides for root builders
    
    There are two more places after commit 3865941b that need to be adapted
    in order to get rid of some test failures when building as root.
    
    Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

commit 31354b5b3246eb435adab78c513986748ddda727
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Tue Dec 23 05:32:45 2014 +0100

    qemu: Fix coverity issues after refcount refactoring
    
    Signed-off-by: Martin Kletzander <mkletzan@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 Dec 24 17:29:22 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 17:29:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3pk0-0004DI-6p; Wed, 24 Dec 2014 17:28: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 1Y3pjz-0004DD-2h
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 17:28:55 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	7A/71-25727-6D7FA945; Wed, 24 Dec 2014 17:28:54 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419442132!15687231!1
X-Originating-IP: [66.165.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 3196 invoked from network); 24 Dec 2014 17:28:53 -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;
	24 Dec 2014 17:28:53 -0000
X-IronPort-AV: E=Sophos;i="5.07,639,1413244800"; d="scan'208";a="207819570"
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.210.2; Wed, 24 Dec 2014 12:28: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 1Y3pju-00079V-82;
	Wed, 24 Dec 2014 17:28:50 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3pjt-0000PD-H9;
	Wed, 24 Dec 2014 17:28:49 +0000
Date: Wed, 24 Dec 2014 17:28:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32617-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] 32617: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32617 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32617/

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. 32596

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-armhf-armhf-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              7c6dbf35183aa636ae31290beef14af937a3b248
baseline version:
 libvirt              3865941be1fa5466d7892b24f1a2d7ee14f86712

------------------------------------------------------------
People who touched revisions under test:
  Dmitry Guryanov <dguryanov@parallels.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                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 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


Not pushing.

------------------------------------------------------------
commit 7c6dbf35183aa636ae31290beef14af937a3b248
Author: Dmitry Guryanov <dguryanov@parallels.com>
Date:   Tue Dec 23 16:23:34 2014 +0300

    parallels: report, that cdrom image is raw
    
    VIR_STORAGE_FILE_AUTO should be used only in xml provided to
    libvirt by user, if I understood correctly. Driver should
    set storage source format to specific disk format in
    *DomainGetXMLDesc.
    
    CDROMs in PCS use raw image format.
    
    Signed-off-by: Dmitry Guryanov <dguryanov@parallels.com>

commit 42dc7a471d18c01a8e2fbff28c3b6c801ace37cd
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Tue Dec 23 06:10:55 2014 +0100

    tests: Set up two more overrides for root builders
    
    There are two more places after commit 3865941b that need to be adapted
    in order to get rid of some test failures when building as root.
    
    Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

commit 31354b5b3246eb435adab78c513986748ddda727
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Tue Dec 23 05:32:45 2014 +0100

    qemu: Fix coverity issues after refcount refactoring
    
    Signed-off-by: Martin Kletzander <mkletzan@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 Dec 24 21:44:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 21: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 1Y3til-0000ku-Gk; Wed, 24 Dec 2014 21:43:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1Y3tij-0000kp-Em
	for xen-devel@lists.xenproject.org; Wed, 24 Dec 2014 21:43:53 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	B1/B6-22777-8933B945; Wed, 24 Dec 2014 21:43:52 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-7.tower-206.messagelabs.com!1419457431!15151954!1
X-Originating-IP: [209.85.215.41]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14256 invoked from network); 24 Dec 2014 21:43:52 -0000
Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com)
	(209.85.215.41)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Dec 2014 21:43:52 -0000
Received: by mail-la0-f41.google.com with SMTP id hv19so7401500lab.0
	for <xen-devel@lists.xenproject.org>;
	Wed, 24 Dec 2014 13:43: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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=fyaF1agTOvVR3mQlW5Wao/XtYSxLDH33AtuG7wBDuOs=;
	b=d3BhjQJj0wyUaOeI6QJRgUCGnDWb/RAvIR/m6d07no8DDGU2RiLIKirvf3Q1Igj1xh
	CC9lBHrFJEB2Fg9FfyxVcJI0oIsm/3jDLnoMMVPSYYJQkrzZao/hCTRp0PXG5v+N5moW
	d6ixKkUFUDcSV5cWsPPRAPKC4TazGheKQ16p1NUTaMo9FjH/p4JyMBl3N8b/5ZypZmOv
	mdGGGSkOBlKUxTVyWNLxN2D9HRJY0YH9GlJqfnpG04Bt9wIktStQtr3QqLmNd1yJ00tR
	iPehdti7ZCyxUzagJVegzZLif8rANuaXONQWVX2uAZuWWIDB0kXWwbR1aHIE0oAI1pHD
	DIJQ==
X-Gm-Message-State: ALoCoQkEc7hAXQADTUI9b2+0k+o5BuBt3H3wHNoJsnozOOuh9E2P0VohD9PuHYwrMwfKbynM+r5l
X-Received: by 10.152.37.7 with SMTP id u7mr36293063laj.74.1419457431409; Wed,
	24 Dec 2014 13:43:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.7.132 with HTTP; Wed, 24 Dec 2014 13:43:30 -0800 (PST)
In-Reply-To: <CALzav=fuOieDmkWviyzLFyTuyray0=oZWTaOUCBUHRAmiKynmg@mail.gmail.com>
References: <cover.1419295081.git.luto@amacapital.net>
	<8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
	<CALzav=fuOieDmkWviyzLFyTuyray0=oZWTaOUCBUHRAmiKynmg@mail.gmail.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Wed, 24 Dec 2014 13:43:30 -0800
Message-ID: <CALCETrX1zvwPOaeuUM6wbir0ajRy4a7UuXdqgXsJJ3AZFRWRow@mail.gmail.com>
To: David Matlack <dmatlack@google.com>
Cc: kvm list <kvm@vger.kernel.org>, Gleb Natapov <gleb@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [RFC 2/2] x86, vdso,
 pvclock: Simplify and speed up the vdso pvclock reader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 24, 2014 at 1:30 PM, David Matlack <dmatlack@google.com> wrote:
> On Mon, Dec 22, 2014 at 4:39 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> The pvclock vdso code was too abstracted to understand easily and
>> excessively paranoid.  Simplify it for a huge speedup.
>>
>> This opens the door for additional simplifications, as the vdso no
>> longer accesses the pvti for any vcpu other than vcpu 0.
>>
>> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
>> With this change, it takes 19ns, which is almost as fast as the pure TSC
>> implementation.
>>
>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>> ---
>>  arch/x86/vdso/vclock_gettime.c | 82 ++++++++++++++++++++++++------------------
>>  1 file changed, 47 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
>> index 9793322751e0..f2e0396d5629 100644
>> --- a/arch/x86/vdso/vclock_gettime.c
>> +++ b/arch/x86/vdso/vclock_gettime.c
>> @@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
>>
>>  static notrace cycle_t vread_pvclock(int *mode)
>>  {
>> -       const struct pvclock_vsyscall_time_info *pvti;
>> +       const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>>         cycle_t ret;
>> -       u64 last;
>> -       u32 version;
>> -       u8 flags;
>> -       unsigned cpu, cpu1;
>> -
>> +       u64 tsc, pvti_tsc;
>> +       u64 last, delta, pvti_system_time;
>> +       u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>>
>>         /*
>> -        * Note: hypervisor must guarantee that:
>> -        * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
>> -        * 2. that per-CPU pvclock time info is updated if the
>> -        *    underlying CPU changes.
>> -        * 3. that version is increased whenever underlying CPU
>> -        *    changes.
>> +        * Note: The kernel and hypervisor must guarantee that cpu ID
>> +        * number maps 1:1 to per-CPU pvclock time info.
>> +        *
>> +        * Because the hypervisor is entirely unaware of guest userspace
>> +        * preemption, it cannot guarantee that per-CPU pvclock time
>> +        * info is updated if the underlying CPU changes or that that
>> +        * version is increased whenever underlying CPU changes.
>> +        *
>> +        * On KVM, we are guaranteed that pvti updates for any vCPU are
>> +        * atomic as seen by *all* vCPUs.  This is an even stronger
>> +        * guarantee than we get with a normal seqlock.
>>          *
>> +        * On Xen, we don't appear to have that guarantee, but Xen still
>> +        * supplies a valid seqlock using the version field.
>> +
>
> Forgotten * here?
>
>> +        * We only do pvclock vdso timing at all if
>> +        * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
>> +        * mean that all vCPUs have matching pvti and that the TSC is
>> +        * synced, so we can just look at vCPU 0's pvti.
>>          */
>> -       do {
>> -               cpu = __getcpu() & VGETCPU_CPU_MASK;
>> -               /* TODO: We can put vcpu id into higher bits of pvti.version.
>> -                * This will save a couple of cycles by getting rid of
>> -                * __getcpu() calls (Gleb).
>> -                */
>> -
>> -               pvti = get_pvti(cpu);
>> -
>> -               version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
>> -
>> -               /*
>> -                * Test we're still on the cpu as well as the version.
>> -                * We could have been migrated just after the first
>> -                * vgetcpu but before fetching the version, so we
>> -                * wouldn't notice a version change.
>> -                */
>> -               cpu1 = __getcpu() & VGETCPU_CPU_MASK;
>> -       } while (unlikely(cpu != cpu1 ||
>> -                         (pvti->pvti.version & 1) ||
>> -                         pvti->pvti.version != version));
>> -
>> -       if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
>> +
>> +       if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>>                 *mode = VCLOCK_NONE;
>> +               return 0;
>> +       }
>> +
>> +       do {
>> +               version = pvti->version;
>> +
>> +               /* This is also a read barrier, so we'll read version first. */
>> +               rdtsc_barrier();
>> +               tsc = __native_read_tsc();
>
> Is there a reason why you read the tsc inside the loop rather than once
> after the loop?

I want to make sure that the tsc value used is consistent with the
scale and offset.  Otherwise it would be possible to read the pvti
data, then get preempted and sleep for a long time before rdtsc.  The
result could be a time value larger than an immediate subsequent call
would return.

--Andy

>
>> +
>> +               pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
>> +               pvti_tsc_shift = pvti->tsc_shift;
>> +               pvti_system_time = pvti->system_time;
>> +               pvti_tsc = pvti->tsc_timestamp;
>> +
>> +               /* Make sure that the version double-check is last. */
>> +               smp_rmb();
>> +       } while (unlikely((version & 1) || version != pvti->version));
>> +
>> +       delta = tsc - pvti_tsc;
>> +       ret = pvti_system_time +
>> +               pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
>> +                                   pvti_tsc_shift);
>>
>>         /* refer to tsc.c read_tsc() comment for rationale */
>>         last = gtod->cycle_last;
>> --
>> 2.1.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Andy Lutomirski
AMA Capital Management, LLC

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 21:44:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 21: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 1Y3til-0000ku-Gk; Wed, 24 Dec 2014 21:43:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luto@amacapital.net>) id 1Y3tij-0000kp-Em
	for xen-devel@lists.xenproject.org; Wed, 24 Dec 2014 21:43:53 +0000
Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id
	B1/B6-22777-8933B945; Wed, 24 Dec 2014 21:43:52 +0000
X-Env-Sender: luto@amacapital.net
X-Msg-Ref: server-7.tower-206.messagelabs.com!1419457431!15151954!1
X-Originating-IP: [209.85.215.41]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14256 invoked from network); 24 Dec 2014 21:43:52 -0000
Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com)
	(209.85.215.41)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Dec 2014 21:43:52 -0000
Received: by mail-la0-f41.google.com with SMTP id hv19so7401500lab.0
	for <xen-devel@lists.xenproject.org>;
	Wed, 24 Dec 2014 13:43: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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=fyaF1agTOvVR3mQlW5Wao/XtYSxLDH33AtuG7wBDuOs=;
	b=d3BhjQJj0wyUaOeI6QJRgUCGnDWb/RAvIR/m6d07no8DDGU2RiLIKirvf3Q1Igj1xh
	CC9lBHrFJEB2Fg9FfyxVcJI0oIsm/3jDLnoMMVPSYYJQkrzZao/hCTRp0PXG5v+N5moW
	d6ixKkUFUDcSV5cWsPPRAPKC4TazGheKQ16p1NUTaMo9FjH/p4JyMBl3N8b/5ZypZmOv
	mdGGGSkOBlKUxTVyWNLxN2D9HRJY0YH9GlJqfnpG04Bt9wIktStQtr3QqLmNd1yJ00tR
	iPehdti7ZCyxUzagJVegzZLif8rANuaXONQWVX2uAZuWWIDB0kXWwbR1aHIE0oAI1pHD
	DIJQ==
X-Gm-Message-State: ALoCoQkEc7hAXQADTUI9b2+0k+o5BuBt3H3wHNoJsnozOOuh9E2P0VohD9PuHYwrMwfKbynM+r5l
X-Received: by 10.152.37.7 with SMTP id u7mr36293063laj.74.1419457431409; Wed,
	24 Dec 2014 13:43:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.7.132 with HTTP; Wed, 24 Dec 2014 13:43:30 -0800 (PST)
In-Reply-To: <CALzav=fuOieDmkWviyzLFyTuyray0=oZWTaOUCBUHRAmiKynmg@mail.gmail.com>
References: <cover.1419295081.git.luto@amacapital.net>
	<8d09c16eb39cbe264417cc66c4aca730af10b70b.1419295081.git.luto@amacapital.net>
	<CALzav=fuOieDmkWviyzLFyTuyray0=oZWTaOUCBUHRAmiKynmg@mail.gmail.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Wed, 24 Dec 2014 13:43:30 -0800
Message-ID: <CALCETrX1zvwPOaeuUM6wbir0ajRy4a7UuXdqgXsJJ3AZFRWRow@mail.gmail.com>
To: David Matlack <dmatlack@google.com>
Cc: kvm list <kvm@vger.kernel.org>, Gleb Natapov <gleb@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [RFC 2/2] x86, vdso,
 pvclock: Simplify and speed up the vdso pvclock reader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Dec 24, 2014 at 1:30 PM, David Matlack <dmatlack@google.com> wrote:
> On Mon, Dec 22, 2014 at 4:39 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> The pvclock vdso code was too abstracted to understand easily and
>> excessively paranoid.  Simplify it for a huge speedup.
>>
>> This opens the door for additional simplifications, as the vdso no
>> longer accesses the pvti for any vcpu other than vcpu 0.
>>
>> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
>> With this change, it takes 19ns, which is almost as fast as the pure TSC
>> implementation.
>>
>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>> ---
>>  arch/x86/vdso/vclock_gettime.c | 82 ++++++++++++++++++++++++------------------
>>  1 file changed, 47 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
>> index 9793322751e0..f2e0396d5629 100644
>> --- a/arch/x86/vdso/vclock_gettime.c
>> +++ b/arch/x86/vdso/vclock_gettime.c
>> @@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
>>
>>  static notrace cycle_t vread_pvclock(int *mode)
>>  {
>> -       const struct pvclock_vsyscall_time_info *pvti;
>> +       const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>>         cycle_t ret;
>> -       u64 last;
>> -       u32 version;
>> -       u8 flags;
>> -       unsigned cpu, cpu1;
>> -
>> +       u64 tsc, pvti_tsc;
>> +       u64 last, delta, pvti_system_time;
>> +       u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>>
>>         /*
>> -        * Note: hypervisor must guarantee that:
>> -        * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
>> -        * 2. that per-CPU pvclock time info is updated if the
>> -        *    underlying CPU changes.
>> -        * 3. that version is increased whenever underlying CPU
>> -        *    changes.
>> +        * Note: The kernel and hypervisor must guarantee that cpu ID
>> +        * number maps 1:1 to per-CPU pvclock time info.
>> +        *
>> +        * Because the hypervisor is entirely unaware of guest userspace
>> +        * preemption, it cannot guarantee that per-CPU pvclock time
>> +        * info is updated if the underlying CPU changes or that that
>> +        * version is increased whenever underlying CPU changes.
>> +        *
>> +        * On KVM, we are guaranteed that pvti updates for any vCPU are
>> +        * atomic as seen by *all* vCPUs.  This is an even stronger
>> +        * guarantee than we get with a normal seqlock.
>>          *
>> +        * On Xen, we don't appear to have that guarantee, but Xen still
>> +        * supplies a valid seqlock using the version field.
>> +
>
> Forgotten * here?
>
>> +        * We only do pvclock vdso timing at all if
>> +        * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
>> +        * mean that all vCPUs have matching pvti and that the TSC is
>> +        * synced, so we can just look at vCPU 0's pvti.
>>          */
>> -       do {
>> -               cpu = __getcpu() & VGETCPU_CPU_MASK;
>> -               /* TODO: We can put vcpu id into higher bits of pvti.version.
>> -                * This will save a couple of cycles by getting rid of
>> -                * __getcpu() calls (Gleb).
>> -                */
>> -
>> -               pvti = get_pvti(cpu);
>> -
>> -               version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
>> -
>> -               /*
>> -                * Test we're still on the cpu as well as the version.
>> -                * We could have been migrated just after the first
>> -                * vgetcpu but before fetching the version, so we
>> -                * wouldn't notice a version change.
>> -                */
>> -               cpu1 = __getcpu() & VGETCPU_CPU_MASK;
>> -       } while (unlikely(cpu != cpu1 ||
>> -                         (pvti->pvti.version & 1) ||
>> -                         pvti->pvti.version != version));
>> -
>> -       if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
>> +
>> +       if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>>                 *mode = VCLOCK_NONE;
>> +               return 0;
>> +       }
>> +
>> +       do {
>> +               version = pvti->version;
>> +
>> +               /* This is also a read barrier, so we'll read version first. */
>> +               rdtsc_barrier();
>> +               tsc = __native_read_tsc();
>
> Is there a reason why you read the tsc inside the loop rather than once
> after the loop?

I want to make sure that the tsc value used is consistent with the
scale and offset.  Otherwise it would be possible to read the pvti
data, then get preempted and sleep for a long time before rdtsc.  The
result could be a time value larger than an immediate subsequent call
would return.

--Andy

>
>> +
>> +               pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
>> +               pvti_tsc_shift = pvti->tsc_shift;
>> +               pvti_system_time = pvti->system_time;
>> +               pvti_tsc = pvti->tsc_timestamp;
>> +
>> +               /* Make sure that the version double-check is last. */
>> +               smp_rmb();
>> +       } while (unlikely((version & 1) || version != pvti->version));
>> +
>> +       delta = tsc - pvti_tsc;
>> +       ret = pvti_system_time +
>> +               pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
>> +                                   pvti_tsc_shift);
>>
>>         /* refer to tsc.c read_tsc() comment for rationale */
>>         last = gtod->cycle_last;
>> --
>> 2.1.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Andy Lutomirski
AMA Capital Management, LLC

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 22:08:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 22:08:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3u5v-0001JK-VI; Wed, 24 Dec 2014 22:07:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3u5u-0001JF-S7
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 22:07:51 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	9D/8F-27623-6393B945; Wed, 24 Dec 2014 22:07:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1419458867!13233481!1
X-Originating-IP: [66.165.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 2859 invoked from network); 24 Dec 2014 22:07: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;
	24 Dec 2014 22:07:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,639,1413244800"; d="scan'208";a="207871099"
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.210.2; Wed, 24 Dec 2014 17:07: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 1Y3u5p-0008U7-Kw;
	Wed, 24 Dec 2014 22:07:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3u5h-0006bk-Fa;
	Wed, 24 Dec 2014 22:07:45 +0000
Date: Wed, 24 Dec 2014 22:07:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32616-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] 32616: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32616 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32616/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32564

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-xl          10 migrate-support-check        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-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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                53262d12d1658669029ab39a63e3d314108abe66
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

------------------------------------------------------------
People who touched revisions under test:
  Alex Chen <alex.chen@huawei.com>
  Catalin Marinas <catalin.marinas@arm.com>
  Davidlohr Bueso <dave@stgolabs.net>
  Joe Thornber <ejt@redhat.com>
  Jungseok Lee <jungseoklee85@gmail.com>
  Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
  Marc Dionne <marc.c.dionne@gmail.com>
  Marc Dionne <marc.dionne@your-file-system.com>
  Mike Snitzer <snitzer@redhat.com>
  Will Deacon <will.deacon@arm.com>
  zhendong chen <alex.chen@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    
 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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 53262d12d1658669029ab39a63e3d314108abe66
Merge: aa39477 5d96e0c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Dec 23 11:03:28 2014 -0800

    Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
    
    Pull arm64 fixes from Catalin Marinas:
     - __cpu_suspend mm switching fix after warm boot
     - arch_setup_dma_ops implementation
     - pgd_page compilation error fix
     - defconfig updates
    
    * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
      arm64: mm: Add pgd_page to support RCU fast_gup
      arm64: defconfig: defconfig update for 3.19
      arm64: kernel: fix __cpu_suspend mm switch on warm-boot
      arm64: Replace set_arch_dma_coherent_ops with arch_setup_dma_ops

commit 5d96e0cba26323c3daeb9f7cdfd4efe70985e2c6
Author: Jungseok Lee <jungseoklee85@gmail.com>
Date:   Sat Dec 20 00:49:40 2014 +0000

    arm64: mm: Add pgd_page to support RCU fast_gup
    
    This patch adds pgd_page definition in order to keep supporting
    HAVE_GENERIC_RCU_GUP configuration. In addition, it changes pud_page
    expression to align with pmd_page for readability.
    
    An introduction of pgd_page resolves the following build breakage
    under 4KB + 4Level memory management combo.
    
    mm/gup.c: In function 'gup_huge_pgd':
    mm/gup.c:889:2: error: implicit declaration of function 'pgd_page' [-Werror=implicit-function-declaration]
      head = pgd_page(orig);
      ^
    mm/gup.c:889:7: warning: assignment makes pointer from integer without a cast
      head = pgd_page(orig);
    
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    Signed-off-by: Jungseok Lee <jungseoklee85@gmail.com>
    [catalin.marinas@arm.com: remove duplicate pmd_page definition]
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

commit f7bf130ecd01f6c9d95c02c7a83d5d9dc263b0c9
Author: Will Deacon <will.deacon@arm.com>
Date:   Sun Dec 21 11:13:12 2014 +0000

    arm64: defconfig: defconfig update for 3.19
    
    The usual defconfig tweaks, this time:
    
      - FHANDLE and AUTOFS4_FS to keep systemd happy
      - PID_NS, QUOTA and KEYS to keep LTP happy
      - Disable DEBUG_PREEMPT, as this *really* hurts performance
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

commit f43c27188a49111b58e9611afa2f0365b0b55625
Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Date:   Fri Dec 19 17:03:47 2014 +0000

    arm64: kernel: fix __cpu_suspend mm switch on warm-boot
    
    On arm64 the TTBR0_EL1 register is set to either the reserved TTBR0
    page tables on boot or to the active_mm mappings belonging to user space
    processes, it must never be set to swapper_pg_dir page tables mappings.
    
    When a CPU is booted its active_mm is set to init_mm even though its
    TTBR0_EL1 points at the reserved TTBR0 page mappings. This implies
    that when __cpu_suspend is triggered the active_mm can point at
    init_mm even if the current TTBR0_EL1 register contains the reserved
    TTBR0_EL1 mappings.
    
    Therefore, the mm save and restore executed in __cpu_suspend might
    turn out to be erroneous in that, if the current->active_mm corresponds
    to init_mm, on resume from low power it ends up restoring in the
    TTBR0_EL1 the init_mm mappings that are global and can cause speculation
    of TLB entries which end up being propagated to user space.
    
    This patch fixes the issue by checking the active_mm pointer before
    restoring the TTBR0 mappings. If the current active_mm == &init_mm,
    the code sets the TTBR0_EL1 to the reserved TTBR0 mapping instead of
    switching back to the active_mm, which is the expected behaviour
    corresponding to the TTBR0_EL1 settings when __cpu_suspend was entered.
    
    Fixes: 95322526ef62 ("arm64: kernel: cpu_{suspend/resume} implementation")
    Cc: <stable@vger.kernel.org> # 3.14+: 18ab7db
    Cc: <stable@vger.kernel.org> # 3.14+: 714f599
    Cc: <stable@vger.kernel.org> # 3.14+: c3684fb
    Cc: <stable@vger.kernel.org> # 3.14+
    Cc: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

commit aa39477b5692611b91ac9455ae588738852b3f60
Merge: 48ec833 5164bec
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Dec 22 14:47:17 2014 -0800

    Merge tag 'dm-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
    
    Pull device mapper fixes from Mike Snitzer:
     "Thre stable fixes and one fix for a regression introduced during 3.19
      merge:
    
       - Fix inability to discard used space when the thin-pool target is in
         out-of-data-space mode and also transition the thin-pool back to
         write mode once free space is made available.
    
       - Fix DM core bio-based end_io bug that prevented proper
         post-processing of the error code returned from the block layer.
    
       - Fix crash in DM thin-pool due to thin device being added to the
         pool's active_thins list before properly initializing the thin
         device's refcount"
    
    * tag 'dm-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
      dm: fix missed error code if .end_io isn't implemented by target_type
      dm thin: fix crash by initializing thin device's refcount and completion earlier
      dm thin: fix missing out-of-data-space to write mode transition if blocks are released
      dm thin: fix inability to discard blocks when in out-of-data-space mode

commit 48ec833b7851438f02164ea846852ce4696f09ad
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Mon Dec 22 21:01:54 2014 +0200

    Revert "mm/memory.c: share the i_mmap_rwsem"
    
    This reverts commit c8475d144abb1e62958cc5ec281d2a9e161c1946.
    
    There are several[1][2] of bug reports which points to this commit as potential
    cause[3].
    
    Let's revert it until we figure out what's going on.
    
    [1] https://lkml.org/lkml/2014/11/14/342
    [2] https://lkml.org/lkml/2014/12/22/213
    [3] https://lkml.org/lkml/2014/12/9/741
    
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Acked-by: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 31dde116cb084bc0042cafe48975ffb7d1a4ae5d
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Thu Dec 18 17:13:49 2014 +0000

    arm64: Replace set_arch_dma_coherent_ops with arch_setup_dma_ops
    
    Commit a3a60f81ee6f (dma-mapping: replace set_arch_dma_coherent_ops with
    arch_setup_dma_ops) changes the of_dma_configure() arch dma_ops callback
    to arch_setup_dma_ops but only the arch/arm code is updated. Subsequent
    commit 97890ba9289c (dma-mapping: detect and configure IOMMU in
    of_dma_configure) changes the arch_setup_dma_ops() prototype further to
    handle iommu. The patch makes the corresponding arm64 changes.
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Reported-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Will Deacon <will.deacon@arm.com>

commit 5164bece1673cdf04782f8ed3fba70743700f5da
Author: zhendong chen <alex.chen@huawei.com>
Date:   Wed Dec 17 14:37:04 2014 +0800

    dm: fix missed error code if .end_io isn't implemented by target_type
    
    In bio-based DM's clone_endio(), when target_type doesn't implement
    .end_io (e.g. linear) r will be always be initialized 0.  So if a
    WRITE SAME bio fails WRITE SAME will not be disabled as intended.
    
    Fix this by initializing r to error, rather than 0, in clone_endio().
    
    Signed-off-by: Alex Chen <alex.chen@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Fixes: 7eee4ae2db ("dm: disable WRITE SAME if it fails")
    Cc: stable@vger.kernel.org

commit 2b94e8960cc3f225dec058f27570505351f4bc13
Author: Marc Dionne <marc.c.dionne@gmail.com>
Date:   Wed Dec 17 07:59:59 2014 -0500

    dm thin: fix crash by initializing thin device's refcount and completion earlier
    
    Commit 80e96c5484be ("dm thin: do not allow thin device activation
    while pool is suspended") delayed the initialization of a new thin
    device's refcount and completion until after this new thin was added
    to the pool's active_thins list and the pool lock is released.  This
    opens a race with a worker thread that walks the list and calls
    thin_get/put, noticing that the refcount goes to 0 and calling
    complete, freezing up the system and giving the oops below:
    
     kernel: BUG: unable to handle kernel NULL pointer dereference at           (null)
     kernel: IP: [<ffffffff810d360b>] __wake_up_common+0x2b/0x90
    
     kernel: Call Trace:
     kernel: [<ffffffff810d3683>] __wake_up_locked+0x13/0x20
     kernel: [<ffffffff810d3dc7>] complete+0x37/0x50
     kernel: [<ffffffffa0595c50>] thin_put+0x20/0x30 [dm_thin_pool]
     kernel: [<ffffffffa059aab7>] do_worker+0x667/0x870 [dm_thin_pool]
     kernel: [<ffffffff816a8a4c>] ? __schedule+0x3ac/0x9a0
     kernel: [<ffffffff810b1aef>] process_one_work+0x14f/0x400
     kernel: [<ffffffff810b206b>] worker_thread+0x6b/0x490
     kernel: [<ffffffff810b2000>] ? rescuer_thread+0x260/0x260
     kernel: [<ffffffff810b6a7b>] kthread+0xdb/0x100
     kernel: [<ffffffff810b69a0>] ? kthread_create_on_node+0x170/0x170
     kernel: [<ffffffff816ad7ec>] ret_from_fork+0x7c/0xb0
     kernel: [<ffffffff810b69a0>] ? kthread_create_on_node+0x170/0x170
    
    Set the thin device's initial refcount and initialize the completion
    before adding it to the pool's active_thins list in thin_ctr().
    
    Signed-off-by: Marc Dionne <marc.dionne@your-file-system.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 2c43fd26e46734430122b8d2ad3024bb532df3ef
Author: Joe Thornber <ejt@redhat.com>
Date:   Thu Dec 11 11:12:19 2014 +0000

    dm thin: fix missing out-of-data-space to write mode transition if blocks are released
    
    Discard bios and thin device deletion have the potential to release data
    blocks.  If the thin-pool is in out-of-data-space mode, and blocks were
    released, transition the thin-pool back to full write mode.
    
    The correct time to do this is just after the thin-pool metadata commit.
    It cannot be done before the commit because the space maps will not
    allow immediate reuse of the data blocks in case there's a rollback
    following power failure.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org

commit 45ec9bd0fd7abf8705e7cf12205ff69fe9d51181
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Dec 10 17:06:57 2014 +0000

    dm thin: fix inability to discard blocks when in out-of-data-space mode
    
    When the pool was in PM_OUT_OF_SPACE mode its process_prepared_discard
    function pointer was incorrectly being set to
    process_prepared_discard_passdown rather than process_prepared_discard.
    
    This incorrect function pointer meant the discard was being passed down,
    but not effecting the mapping.  As such any discard that was issued, in
    an attempt to reclaim blocks, would not successfully free data space.
    
    Reported-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 24 22:08:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Dec 2014 22:08:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y3u5v-0001JK-VI; Wed, 24 Dec 2014 22:07:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3u5u-0001JF-S7
	for xen-devel@lists.xensource.com; Wed, 24 Dec 2014 22:07:51 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	9D/8F-27623-6393B945; Wed, 24 Dec 2014 22:07:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1419458867!13233481!1
X-Originating-IP: [66.165.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 2859 invoked from network); 24 Dec 2014 22:07: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;
	24 Dec 2014 22:07:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,639,1413244800"; d="scan'208";a="207871099"
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.210.2; Wed, 24 Dec 2014 17:07: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 1Y3u5p-0008U7-Kw;
	Wed, 24 Dec 2014 22:07:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3u5h-0006bk-Fa;
	Wed, 24 Dec 2014 22:07:45 +0000
Date: Wed, 24 Dec 2014 22:07:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32616-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] 32616: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32616 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32616/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32564

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-xl          10 migrate-support-check        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-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-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-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-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 linux                53262d12d1658669029ab39a63e3d314108abe66
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

------------------------------------------------------------
People who touched revisions under test:
  Alex Chen <alex.chen@huawei.com>
  Catalin Marinas <catalin.marinas@arm.com>
  Davidlohr Bueso <dave@stgolabs.net>
  Joe Thornber <ejt@redhat.com>
  Jungseok Lee <jungseoklee85@gmail.com>
  Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
  Marc Dionne <marc.c.dionne@gmail.com>
  Marc Dionne <marc.dionne@your-file-system.com>
  Mike Snitzer <snitzer@redhat.com>
  Will Deacon <will.deacon@arm.com>
  zhendong chen <alex.chen@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    
 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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 53262d12d1658669029ab39a63e3d314108abe66
Merge: aa39477 5d96e0c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Dec 23 11:03:28 2014 -0800

    Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
    
    Pull arm64 fixes from Catalin Marinas:
     - __cpu_suspend mm switching fix after warm boot
     - arch_setup_dma_ops implementation
     - pgd_page compilation error fix
     - defconfig updates
    
    * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
      arm64: mm: Add pgd_page to support RCU fast_gup
      arm64: defconfig: defconfig update for 3.19
      arm64: kernel: fix __cpu_suspend mm switch on warm-boot
      arm64: Replace set_arch_dma_coherent_ops with arch_setup_dma_ops

commit 5d96e0cba26323c3daeb9f7cdfd4efe70985e2c6
Author: Jungseok Lee <jungseoklee85@gmail.com>
Date:   Sat Dec 20 00:49:40 2014 +0000

    arm64: mm: Add pgd_page to support RCU fast_gup
    
    This patch adds pgd_page definition in order to keep supporting
    HAVE_GENERIC_RCU_GUP configuration. In addition, it changes pud_page
    expression to align with pmd_page for readability.
    
    An introduction of pgd_page resolves the following build breakage
    under 4KB + 4Level memory management combo.
    
    mm/gup.c: In function 'gup_huge_pgd':
    mm/gup.c:889:2: error: implicit declaration of function 'pgd_page' [-Werror=implicit-function-declaration]
      head = pgd_page(orig);
      ^
    mm/gup.c:889:7: warning: assignment makes pointer from integer without a cast
      head = pgd_page(orig);
    
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    Signed-off-by: Jungseok Lee <jungseoklee85@gmail.com>
    [catalin.marinas@arm.com: remove duplicate pmd_page definition]
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

commit f7bf130ecd01f6c9d95c02c7a83d5d9dc263b0c9
Author: Will Deacon <will.deacon@arm.com>
Date:   Sun Dec 21 11:13:12 2014 +0000

    arm64: defconfig: defconfig update for 3.19
    
    The usual defconfig tweaks, this time:
    
      - FHANDLE and AUTOFS4_FS to keep systemd happy
      - PID_NS, QUOTA and KEYS to keep LTP happy
      - Disable DEBUG_PREEMPT, as this *really* hurts performance
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

commit f43c27188a49111b58e9611afa2f0365b0b55625
Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Date:   Fri Dec 19 17:03:47 2014 +0000

    arm64: kernel: fix __cpu_suspend mm switch on warm-boot
    
    On arm64 the TTBR0_EL1 register is set to either the reserved TTBR0
    page tables on boot or to the active_mm mappings belonging to user space
    processes, it must never be set to swapper_pg_dir page tables mappings.
    
    When a CPU is booted its active_mm is set to init_mm even though its
    TTBR0_EL1 points at the reserved TTBR0 page mappings. This implies
    that when __cpu_suspend is triggered the active_mm can point at
    init_mm even if the current TTBR0_EL1 register contains the reserved
    TTBR0_EL1 mappings.
    
    Therefore, the mm save and restore executed in __cpu_suspend might
    turn out to be erroneous in that, if the current->active_mm corresponds
    to init_mm, on resume from low power it ends up restoring in the
    TTBR0_EL1 the init_mm mappings that are global and can cause speculation
    of TLB entries which end up being propagated to user space.
    
    This patch fixes the issue by checking the active_mm pointer before
    restoring the TTBR0 mappings. If the current active_mm == &init_mm,
    the code sets the TTBR0_EL1 to the reserved TTBR0 mapping instead of
    switching back to the active_mm, which is the expected behaviour
    corresponding to the TTBR0_EL1 settings when __cpu_suspend was entered.
    
    Fixes: 95322526ef62 ("arm64: kernel: cpu_{suspend/resume} implementation")
    Cc: <stable@vger.kernel.org> # 3.14+: 18ab7db
    Cc: <stable@vger.kernel.org> # 3.14+: 714f599
    Cc: <stable@vger.kernel.org> # 3.14+: c3684fb
    Cc: <stable@vger.kernel.org> # 3.14+
    Cc: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

commit aa39477b5692611b91ac9455ae588738852b3f60
Merge: 48ec833 5164bec
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Dec 22 14:47:17 2014 -0800

    Merge tag 'dm-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
    
    Pull device mapper fixes from Mike Snitzer:
     "Thre stable fixes and one fix for a regression introduced during 3.19
      merge:
    
       - Fix inability to discard used space when the thin-pool target is in
         out-of-data-space mode and also transition the thin-pool back to
         write mode once free space is made available.
    
       - Fix DM core bio-based end_io bug that prevented proper
         post-processing of the error code returned from the block layer.
    
       - Fix crash in DM thin-pool due to thin device being added to the
         pool's active_thins list before properly initializing the thin
         device's refcount"
    
    * tag 'dm-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
      dm: fix missed error code if .end_io isn't implemented by target_type
      dm thin: fix crash by initializing thin device's refcount and completion earlier
      dm thin: fix missing out-of-data-space to write mode transition if blocks are released
      dm thin: fix inability to discard blocks when in out-of-data-space mode

commit 48ec833b7851438f02164ea846852ce4696f09ad
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Mon Dec 22 21:01:54 2014 +0200

    Revert "mm/memory.c: share the i_mmap_rwsem"
    
    This reverts commit c8475d144abb1e62958cc5ec281d2a9e161c1946.
    
    There are several[1][2] of bug reports which points to this commit as potential
    cause[3].
    
    Let's revert it until we figure out what's going on.
    
    [1] https://lkml.org/lkml/2014/11/14/342
    [2] https://lkml.org/lkml/2014/12/22/213
    [3] https://lkml.org/lkml/2014/12/9/741
    
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Acked-by: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 31dde116cb084bc0042cafe48975ffb7d1a4ae5d
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Thu Dec 18 17:13:49 2014 +0000

    arm64: Replace set_arch_dma_coherent_ops with arch_setup_dma_ops
    
    Commit a3a60f81ee6f (dma-mapping: replace set_arch_dma_coherent_ops with
    arch_setup_dma_ops) changes the of_dma_configure() arch dma_ops callback
    to arch_setup_dma_ops but only the arch/arm code is updated. Subsequent
    commit 97890ba9289c (dma-mapping: detect and configure IOMMU in
    of_dma_configure) changes the arch_setup_dma_ops() prototype further to
    handle iommu. The patch makes the corresponding arm64 changes.
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Reported-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Will Deacon <will.deacon@arm.com>

commit 5164bece1673cdf04782f8ed3fba70743700f5da
Author: zhendong chen <alex.chen@huawei.com>
Date:   Wed Dec 17 14:37:04 2014 +0800

    dm: fix missed error code if .end_io isn't implemented by target_type
    
    In bio-based DM's clone_endio(), when target_type doesn't implement
    .end_io (e.g. linear) r will be always be initialized 0.  So if a
    WRITE SAME bio fails WRITE SAME will not be disabled as intended.
    
    Fix this by initializing r to error, rather than 0, in clone_endio().
    
    Signed-off-by: Alex Chen <alex.chen@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Fixes: 7eee4ae2db ("dm: disable WRITE SAME if it fails")
    Cc: stable@vger.kernel.org

commit 2b94e8960cc3f225dec058f27570505351f4bc13
Author: Marc Dionne <marc.c.dionne@gmail.com>
Date:   Wed Dec 17 07:59:59 2014 -0500

    dm thin: fix crash by initializing thin device's refcount and completion earlier
    
    Commit 80e96c5484be ("dm thin: do not allow thin device activation
    while pool is suspended") delayed the initialization of a new thin
    device's refcount and completion until after this new thin was added
    to the pool's active_thins list and the pool lock is released.  This
    opens a race with a worker thread that walks the list and calls
    thin_get/put, noticing that the refcount goes to 0 and calling
    complete, freezing up the system and giving the oops below:
    
     kernel: BUG: unable to handle kernel NULL pointer dereference at           (null)
     kernel: IP: [<ffffffff810d360b>] __wake_up_common+0x2b/0x90
    
     kernel: Call Trace:
     kernel: [<ffffffff810d3683>] __wake_up_locked+0x13/0x20
     kernel: [<ffffffff810d3dc7>] complete+0x37/0x50
     kernel: [<ffffffffa0595c50>] thin_put+0x20/0x30 [dm_thin_pool]
     kernel: [<ffffffffa059aab7>] do_worker+0x667/0x870 [dm_thin_pool]
     kernel: [<ffffffff816a8a4c>] ? __schedule+0x3ac/0x9a0
     kernel: [<ffffffff810b1aef>] process_one_work+0x14f/0x400
     kernel: [<ffffffff810b206b>] worker_thread+0x6b/0x490
     kernel: [<ffffffff810b2000>] ? rescuer_thread+0x260/0x260
     kernel: [<ffffffff810b6a7b>] kthread+0xdb/0x100
     kernel: [<ffffffff810b69a0>] ? kthread_create_on_node+0x170/0x170
     kernel: [<ffffffff816ad7ec>] ret_from_fork+0x7c/0xb0
     kernel: [<ffffffff810b69a0>] ? kthread_create_on_node+0x170/0x170
    
    Set the thin device's initial refcount and initialize the completion
    before adding it to the pool's active_thins list in thin_ctr().
    
    Signed-off-by: Marc Dionne <marc.dionne@your-file-system.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 2c43fd26e46734430122b8d2ad3024bb532df3ef
Author: Joe Thornber <ejt@redhat.com>
Date:   Thu Dec 11 11:12:19 2014 +0000

    dm thin: fix missing out-of-data-space to write mode transition if blocks are released
    
    Discard bios and thin device deletion have the potential to release data
    blocks.  If the thin-pool is in out-of-data-space mode, and blocks were
    released, transition the thin-pool back to full write mode.
    
    The correct time to do this is just after the thin-pool metadata commit.
    It cannot be done before the commit because the space maps will not
    allow immediate reuse of the data blocks in case there's a rollback
    following power failure.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org

commit 45ec9bd0fd7abf8705e7cf12205ff69fe9d51181
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Dec 10 17:06:57 2014 +0000

    dm thin: fix inability to discard blocks when in out-of-data-space mode
    
    When the pool was in PM_OUT_OF_SPACE mode its process_prepared_discard
    function pointer was incorrectly being set to
    process_prepared_discard_passdown rather than process_prepared_discard.
    
    This incorrect function pointer meant the discard was being passed down,
    but not effecting the mapping.  As such any discard that was issued, in
    an attempt to reclaim blocks, would not successfully free data space.
    
    Reported-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 25 02:58:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 02: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 1Y3ycw-0003N6-RP; Thu, 25 Dec 2014 02:58:14 +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 1Y3ycv-0003N1-2U
	for xen-devel@lists.xen.org; Thu, 25 Dec 2014 02:58:13 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	DA/02-28865-44D7B945; Thu, 25 Dec 2014 02:58:12 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1419476290!15143291!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 6761 invoked from network); 25 Dec 2014 02:58:11 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-13.tower-206.messagelabs.com with SMTP;
	25 Dec 2014 02:58:11 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by fmsmga101.fm.intel.com with ESMTP; 24 Dec 2014 18:58:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,640,1413270000"; d="scan'208";a="628907804"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga001.jf.intel.com with ESMTP; 24 Dec 2014 18:58:09 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 25 Dec 2014 10:58:08 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.67]) with mapi id
	14.03.0195.001; Thu, 25 Dec 2014 10:58:07 +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 RC4
Thread-Index: AdAf5Vbp5eO7feAATfuoMLUd/TLZQA==
Date: Thu, 25 Dec 2014 02:58:06 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31AAABA8@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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, "Wang,
	Wei W" <wei.w.wang@intel.com>, "Li, Liang Z" <liang.z.li@intel.com>, "Wang,
	Yong Y" <yong.y.wang@intel.com>
Subject: [Xen-devel] [Testday]Xen 4.5 RC4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi

This is test report on Xen 4.5 RC4, from Intel OTC VMM Team.

Platform: Grantley-EP, Ivytown-EP

We found these issue blow. Hoping corresponding patches can be committed in Xen 4.5 release.

Issue 1 -- detach a vt-d assigned device from guest, then reattach it to guest, will fail.
http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html

Issue 2 -- attach/detach vt-d devices (both physical and virtual fucntions) to domain, more than 1 time, will fail with errors
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg02016.html
Note: this depends on issue 1. need to apply issue 1's patch to get it.

Issue 3 -- 1GB hugepage support on X86_64 with HVM guest requires hacks in the guest config
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02624.html


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 Dec 25 02:58:53 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 02: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 1Y3ycw-0003N6-RP; Thu, 25 Dec 2014 02:58:14 +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 1Y3ycv-0003N1-2U
	for xen-devel@lists.xen.org; Thu, 25 Dec 2014 02:58:13 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	DA/02-28865-44D7B945; Thu, 25 Dec 2014 02:58:12 +0000
X-Env-Sender: robert.hu@intel.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1419476290!15143291!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 6761 invoked from network); 25 Dec 2014 02:58:11 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-13.tower-206.messagelabs.com with SMTP;
	25 Dec 2014 02:58:11 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by fmsmga101.fm.intel.com with ESMTP; 24 Dec 2014 18:58:10 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,640,1413270000"; d="scan'208";a="628907804"
Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88])
	by orsmga001.jf.intel.com with ESMTP; 24 Dec 2014 18:58:09 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server
	(TLS) id 14.3.195.1; Thu, 25 Dec 2014 10:58:08 +0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.240]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.67]) with mapi id
	14.03.0195.001; Thu, 25 Dec 2014 10:58:07 +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 RC4
Thread-Index: AdAf5Vbp5eO7feAATfuoMLUd/TLZQA==
Date: Thu, 25 Dec 2014 02:58:06 +0000
Message-ID: <9E79D1C9A97CFD4097BCE431828FDD31AAABA8@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: Boris Ostrovsky <boris.ostrovsky@oracle.com>, "Wang,
	Wei W" <wei.w.wang@intel.com>, "Li, Liang Z" <liang.z.li@intel.com>, "Wang,
	Yong Y" <yong.y.wang@intel.com>
Subject: [Xen-devel] [Testday]Xen 4.5 RC4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi

This is test report on Xen 4.5 RC4, from Intel OTC VMM Team.

Platform: Grantley-EP, Ivytown-EP

We found these issue blow. Hoping corresponding patches can be committed in Xen 4.5 release.

Issue 1 -- detach a vt-d assigned device from guest, then reattach it to guest, will fail.
http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html

Issue 2 -- attach/detach vt-d devices (both physical and virtual fucntions) to domain, more than 1 time, will fail with errors
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg02016.html
Note: this depends on issue 1. need to apply issue 1's patch to get it.

Issue 3 -- 1GB hugepage support on X86_64 with HVM guest requires hacks in the guest config
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02624.html


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 Dec 25 03:51:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 03: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 1Y3zSU-0004Sj-B4; Thu, 25 Dec 2014 03:51:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3zSS-0004Se-LL
	for xen-devel@lists.xensource.com; Thu, 25 Dec 2014 03:51:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4A/B2-25276-FB98B945; Thu, 25 Dec 2014 03:51:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1419479485!17790751!1
X-Originating-IP: [66.165.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 17937 invoked from network); 25 Dec 2014 03:51:27 -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;
	25 Dec 2014 03:51:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,641,1413244800"; d="scan'208";a="208438864"
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.210.2; Wed, 24 Dec 2014 22:51: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 1Y3zSO-0001iC-GM;
	Thu, 25 Dec 2014 03:51:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3zSO-0005RH-9u;
	Thu, 25 Dec 2014 03:51:24 +0000
Date: Thu, 25 Dec 2014 03:51:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32623-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] 32623: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32623 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32623/

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. 32564

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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  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-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                f9f7b9d7aeedb0f6150bc9df08542c3a0b67a4ef
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 25 03:51:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 03: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 1Y3zSU-0004Sj-B4; Thu, 25 Dec 2014 03:51:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y3zSS-0004Se-LL
	for xen-devel@lists.xensource.com; Thu, 25 Dec 2014 03:51:28 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	4A/B2-25276-FB98B945; Thu, 25 Dec 2014 03:51:27 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1419479485!17790751!1
X-Originating-IP: [66.165.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 17937 invoked from network); 25 Dec 2014 03:51:27 -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;
	25 Dec 2014 03:51:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,641,1413244800"; d="scan'208";a="208438864"
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.210.2; Wed, 24 Dec 2014 22:51: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 1Y3zSO-0001iC-GM;
	Thu, 25 Dec 2014 03:51:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y3zSO-0005RH-9u;
	Thu, 25 Dec 2014 03:51:24 +0000
Date: Thu, 25 Dec 2014 03:51:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32623-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] 32623: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32623 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32623/

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. 32564

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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  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-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                f9f7b9d7aeedb0f6150bc9df08542c3a0b67a4ef
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 25 06:53:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 06:53:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y42I1-0008Sg-88; Thu, 25 Dec 2014 06:52: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 1Y42Hz-0008Sb-Qg
	for xen-devel@lists.xensource.com; Thu, 25 Dec 2014 06:52:52 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	14/73-25727-244BB945; Thu, 25 Dec 2014 06:52:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419490368!15712215!1
X-Originating-IP: [66.165.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 12018 invoked from network); 25 Dec 2014 06:52:49 -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;
	25 Dec 2014 06:52:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,642,1413244800"; d="scan'208";a="208466304"
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.210.2; Thu, 25 Dec 2014 01:52: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 1Y42Hu-0002c5-TF;
	Thu, 25 Dec 2014 06:52:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y42Hu-00026p-Mf;
	Thu, 25 Dec 2014 06:52:46 +0000
Date: Thu, 25 Dec 2014 06:52:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32624-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] 32624: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32624 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32624/

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-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 25 06:53:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 06:53:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y42I1-0008Sg-88; Thu, 25 Dec 2014 06:52: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 1Y42Hz-0008Sb-Qg
	for xen-devel@lists.xensource.com; Thu, 25 Dec 2014 06:52:52 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	14/73-25727-244BB945; Thu, 25 Dec 2014 06:52:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419490368!15712215!1
X-Originating-IP: [66.165.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 12018 invoked from network); 25 Dec 2014 06:52:49 -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;
	25 Dec 2014 06:52:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,642,1413244800"; d="scan'208";a="208466304"
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.210.2; Thu, 25 Dec 2014 01:52: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 1Y42Hu-0002c5-TF;
	Thu, 25 Dec 2014 06:52:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y42Hu-00026p-Mf;
	Thu, 25 Dec 2014 06:52:46 +0000
Date: Thu, 25 Dec 2014 06:52:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32624-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] 32624: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32624 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32624/

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-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 25 10:47:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 10: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 1Y45vw-00055G-6d; Thu, 25 Dec 2014 10:46:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y45vv-00055B-7H
	for xen-devel@lists.xensource.com; Thu, 25 Dec 2014 10:46:19 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	49/D9-09842-AFAEB945; Thu, 25 Dec 2014 10:46:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1419504376!10493692!1
X-Originating-IP: [66.165.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 516 invoked from network); 25 Dec 2014 10:46:17 -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 Dec 2014 10:46:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,642,1413244800"; d="scan'208";a="207984459"
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.210.2; Thu, 25 Dec 2014 05:46: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 1Y45vq-0003jT-Tx;
	Thu, 25 Dec 2014 10:46:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y45vq-0005Eu-AV;
	Thu, 25 Dec 2014 10:46:14 +0000
Date: Thu, 25 Dec 2014 10:46:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32626-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] 32626: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32626 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32626/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598
 build-armhf-libvirt           5 libvirt-build    fail in 32611 REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 32611

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      1 build-check(1)            blocked in 32611 n/a

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 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                                     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 912 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 Dec 25 10:47:01 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 10: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 1Y45vw-00055G-6d; Thu, 25 Dec 2014 10:46:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y45vv-00055B-7H
	for xen-devel@lists.xensource.com; Thu, 25 Dec 2014 10:46:19 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	49/D9-09842-AFAEB945; Thu, 25 Dec 2014 10:46:18 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1419504376!10493692!1
X-Originating-IP: [66.165.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 516 invoked from network); 25 Dec 2014 10:46:17 -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 Dec 2014 10:46:17 -0000
X-IronPort-AV: E=Sophos;i="5.07,642,1413244800"; d="scan'208";a="207984459"
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.210.2; Thu, 25 Dec 2014 05:46: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 1Y45vq-0003jT-Tx;
	Thu, 25 Dec 2014 10:46:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y45vq-0005Eu-AV;
	Thu, 25 Dec 2014 10:46:14 +0000
Date: Thu, 25 Dec 2014 10:46:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32626-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] 32626: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32626 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32626/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598
 build-armhf-libvirt           5 libvirt-build    fail in 32611 REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 32611

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass
 test-armhf-armhf-libvirt      1 build-check(1)            blocked in 32611 n/a

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 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                                     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 912 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 Dec 25 15:51:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 15: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 1Y4Ah4-0002nU-4r; Thu, 25 Dec 2014 15:51:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y4Ah3-0002nP-2K
	for xen-devel@lists.xensource.com; Thu, 25 Dec 2014 15:51:17 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	25/8D-03148-4723C945; Thu, 25 Dec 2014 15:51:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1419522674!17198974!1
X-Originating-IP: [66.165.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 25520 invoked from network); 25 Dec 2014 15:51:15 -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 Dec 2014 15:51:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,643,1413244800"; d="scan'208";a="208561400"
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.210.2; Thu, 25 Dec 2014 10: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 1Y4Agx-0005Bn-HU;
	Thu, 25 Dec 2014 15: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 1Y4Agx-0005io-CD;
	Thu, 25 Dec 2014 15:51:11 +0000
Date: Thu, 25 Dec 2014 15:51:11 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32648-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] 32648: 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 32648 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32648/

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              2360fe5d24175835d3f5fd1c7e8e6e13addab629
baseline version:
 libvirt              3865941be1fa5466d7892b24f1a2d7ee14f86712

------------------------------------------------------------
People who touched revisions under test:
  Dmitry Guryanov <dguryanov@parallels.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=2360fe5d24175835d3f5fd1c7e8e6e13addab629
+ . 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 2360fe5d24175835d3f5fd1c7e8e6e13addab629
+ branch=libvirt
+ revision=2360fe5d24175835d3f5fd1c7e8e6e13addab629
+ . 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 2360fe5d24175835d3f5fd1c7e8e6e13addab629:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   3865941..2360fe5  2360fe5d24175835d3f5fd1c7e8e6e13addab629 -> 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 Thu Dec 25 15:51:46 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 15: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 1Y4Ah4-0002nU-4r; Thu, 25 Dec 2014 15:51:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y4Ah3-0002nP-2K
	for xen-devel@lists.xensource.com; Thu, 25 Dec 2014 15:51:17 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	25/8D-03148-4723C945; Thu, 25 Dec 2014 15:51:16 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1419522674!17198974!1
X-Originating-IP: [66.165.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 25520 invoked from network); 25 Dec 2014 15:51:15 -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 Dec 2014 15:51:15 -0000
X-IronPort-AV: E=Sophos;i="5.07,643,1413244800"; d="scan'208";a="208561400"
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.210.2; Thu, 25 Dec 2014 10: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 1Y4Agx-0005Bn-HU;
	Thu, 25 Dec 2014 15: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 1Y4Agx-0005io-CD;
	Thu, 25 Dec 2014 15:51:11 +0000
Date: Thu, 25 Dec 2014 15:51:11 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32648-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] 32648: 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 32648 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32648/

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              2360fe5d24175835d3f5fd1c7e8e6e13addab629
baseline version:
 libvirt              3865941be1fa5466d7892b24f1a2d7ee14f86712

------------------------------------------------------------
People who touched revisions under test:
  Dmitry Guryanov <dguryanov@parallels.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=2360fe5d24175835d3f5fd1c7e8e6e13addab629
+ . 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 2360fe5d24175835d3f5fd1c7e8e6e13addab629
+ branch=libvirt
+ revision=2360fe5d24175835d3f5fd1c7e8e6e13addab629
+ . 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 2360fe5d24175835d3f5fd1c7e8e6e13addab629:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/libvirt.git
   3865941..2360fe5  2360fe5d24175835d3f5fd1c7e8e6e13addab629 -> 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 Thu Dec 25 17:26:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 17:26:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4CAZ-00053M-HK; Thu, 25 Dec 2014 17:25: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 1Y4CAY-00053H-6V
	for xen-devel@lists.xensource.com; Thu, 25 Dec 2014 17:25:50 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	5F/00-25714-D984C945; Thu, 25 Dec 2014 17:25:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1419528347!9768043!1
X-Originating-IP: [66.165.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 10010 invoked from network); 25 Dec 2014 17:25: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;
	25 Dec 2014 17:25:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,644,1413244800"; d="scan'208";a="208054923"
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.210.2; Thu, 25 Dec 2014 12:25: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 1Y4CAT-0005dj-2T;
	Thu, 25 Dec 2014 17:25:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4CAS-0007Jn-U0;
	Thu, 25 Dec 2014 17:25:44 +0000
Date: Thu, 25 Dec 2014 17:25:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32646-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] 32646: 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 32646 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32646/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                 fail pass in 32612
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 32612
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10      fail pass in 32612
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 32612
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)         broken pass in 32612
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install     fail pass in 32612
 test-amd64-i386-xl-qemut-debianhvm-amd64 13 guest-localmigrate/x10 fail in 32612 pass in 32646

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32612

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-qemut-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-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 32612 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 32612 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 32612 never pass

version targeted for testing:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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-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                               broken  
 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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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-amd64-xl-win7-amd64 host-install(3)

Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 25 17:26:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 17:26:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4CAZ-00053M-HK; Thu, 25 Dec 2014 17:25: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 1Y4CAY-00053H-6V
	for xen-devel@lists.xensource.com; Thu, 25 Dec 2014 17:25:50 +0000
Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id
	5F/00-25714-D984C945; Thu, 25 Dec 2014 17:25:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1419528347!9768043!1
X-Originating-IP: [66.165.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 10010 invoked from network); 25 Dec 2014 17:25: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;
	25 Dec 2014 17:25:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,644,1413244800"; d="scan'208";a="208054923"
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.210.2; Thu, 25 Dec 2014 12:25: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 1Y4CAT-0005dj-2T;
	Thu, 25 Dec 2014 17:25:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4CAS-0007Jn-U0;
	Thu, 25 Dec 2014 17:25:44 +0000
Date: Thu, 25 Dec 2014 17:25:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32646-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] 32646: 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 32646 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32646/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                 fail pass in 32612
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 32612
 test-amd64-amd64-xl-sedf     15 guest-localmigrate/x10      fail pass in 32612
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 32612
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)         broken pass in 32612
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install     fail pass in 32612
 test-amd64-i386-xl-qemut-debianhvm-amd64 13 guest-localmigrate/x10 fail in 32612 pass in 32646

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32612

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-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-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-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-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-qemut-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-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 32612 never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop          fail in 32612 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop    fail in 32612 never pass

version targeted for testing:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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-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                               broken  
 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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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-amd64-xl-win7-amd64 host-install(3)

Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 25 21:42:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 21: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 1Y4GAl-00016N-Lb; Thu, 25 Dec 2014 21:42:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y4GAk-00016I-7D
	for xen-devel@lists.xensource.com; Thu, 25 Dec 2014 21:42:18 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	59/36-03148-9B48C945; Thu, 25 Dec 2014 21:42:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419543735!17224608!1
X-Originating-IP: [66.165.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 31871 invoked from network); 25 Dec 2014 21:42:16 -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;
	25 Dec 2014 21:42:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,645,1413244800"; d="scan'208";a="208621914"
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.210.2; Thu, 25 Dec 2014 16:42: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 1Y4GAe-0006r9-Q5;
	Thu, 25 Dec 2014 21:42:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4GAe-0002vj-68;
	Thu, 25 Dec 2014 21:42:12 +0000
Date: Thu, 25 Dec 2014 21:42:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32647-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] 32647: tolerable trouble:
	broken/fail/pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32647 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32647/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt      3 host-install(3)           broken pass in 32616
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 32616 pass in 32647

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  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-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-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-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-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-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 in 32616 never pass

version targeted for testing:
 linux                53262d12d1658669029ab39a63e3d314108abe66
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

------------------------------------------------------------
People who touched revisions under test:
  Alex Chen <alex.chen@huawei.com>
  Catalin Marinas <catalin.marinas@arm.com>
  Davidlohr Bueso <dave@stgolabs.net>
  Joe Thornber <ejt@redhat.com>
  Jungseok Lee <jungseoklee85@gmail.com>
  Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
  Marc Dionne <marc.c.dionne@gmail.com>
  Marc Dionne <marc.dionne@your-file-system.com>
  Mike Snitzer <snitzer@redhat.com>
  Will Deacon <will.deacon@arm.com>
  zhendong chen <alex.chen@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    
 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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 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                                 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-libvirt host-install(3)

Pushing revision :

+ branch=linux-linus
+ revision=53262d12d1658669029ab39a63e3d314108abe66
+ . 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-linus 53262d12d1658669029ab39a63e3d314108abe66
+ branch=linux-linus
+ revision=53262d12d1658669029ab39a63e3d314108abe66
+ . 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-linus
+ '[' 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/torvalds/linux-2.6.git = x ']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git = x ']'
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-linus
++ : 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-linus
+ 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-linus
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ : master
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ : tested/linux-linus
+ : tested/linux-linus
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git 53262d12d1658669029ab39a63e3d314108abe66:tested/linux-linus
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   97bf6af..53262d1  53262d12d1658669029ab39a63e3d314108abe66 -> tested/linux-linus
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Dec 25 21:42:55 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Dec 2014 21: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 1Y4GAl-00016N-Lb; Thu, 25 Dec 2014 21:42:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y4GAk-00016I-7D
	for xen-devel@lists.xensource.com; Thu, 25 Dec 2014 21:42:18 +0000
Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id
	59/36-03148-9B48C945; Thu, 25 Dec 2014 21:42:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419543735!17224608!1
X-Originating-IP: [66.165.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 31871 invoked from network); 25 Dec 2014 21:42:16 -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;
	25 Dec 2014 21:42:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,645,1413244800"; d="scan'208";a="208621914"
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.210.2; Thu, 25 Dec 2014 16:42: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 1Y4GAe-0006r9-Q5;
	Thu, 25 Dec 2014 21:42:12 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4GAe-0002vj-68;
	Thu, 25 Dec 2014 21:42:12 +0000
Date: Thu, 25 Dec 2014 21:42:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32647-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] 32647: tolerable trouble:
	broken/fail/pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32647 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32647/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt      3 host-install(3)           broken pass in 32616
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 32616 pass in 32647

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  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-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-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-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-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-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 in 32616 never pass

version targeted for testing:
 linux                53262d12d1658669029ab39a63e3d314108abe66
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

------------------------------------------------------------
People who touched revisions under test:
  Alex Chen <alex.chen@huawei.com>
  Catalin Marinas <catalin.marinas@arm.com>
  Davidlohr Bueso <dave@stgolabs.net>
  Joe Thornber <ejt@redhat.com>
  Jungseok Lee <jungseoklee85@gmail.com>
  Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
  Marc Dionne <marc.c.dionne@gmail.com>
  Marc Dionne <marc.dionne@your-file-system.com>
  Mike Snitzer <snitzer@redhat.com>
  Will Deacon <will.deacon@arm.com>
  zhendong chen <alex.chen@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    
 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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 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                                 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-libvirt host-install(3)

Pushing revision :

+ branch=linux-linus
+ revision=53262d12d1658669029ab39a63e3d314108abe66
+ . 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-linus 53262d12d1658669029ab39a63e3d314108abe66
+ branch=linux-linus
+ revision=53262d12d1658669029ab39a63e3d314108abe66
+ . 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-linus
+ '[' 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/torvalds/linux-2.6.git = x ']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git = x ']'
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-linus
++ : 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-linus
+ 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-linus
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ : master
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ : tested/linux-linus
+ : tested/linux-linus
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git 53262d12d1658669029ab39a63e3d314108abe66:tested/linux-linus
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   97bf6af..53262d1  53262d12d1658669029ab39a63e3d314108abe66 -> tested/linux-linus
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 26 01:41:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 01: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 1Y4Jt9-00014r-St; Fri, 26 Dec 2014 01:40: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 1Y4Jt8-00014m-Hs
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 01:40:22 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	09/43-28865-58CBC945; Fri, 26 Dec 2014 01:40:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1419558019!15212607!1
X-Originating-IP: [66.165.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 11023 invoked from network); 26 Dec 2014 01:40:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2014 01:40:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,645,1413244800"; d="scan'208";a="208666924"
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.210.2; Thu, 25 Dec 2014 20:40: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 1Y4Jt3-00080J-O4;
	Fri, 26 Dec 2014 01:40:17 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4Jt3-0001Ik-It;
	Fri, 26 Dec 2014 01:40:17 +0000
Date: Fri, 26 Dec 2014 01:40:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32651-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] 32651: 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 32651 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32651/

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-pair          4 host-install/dst_host(4)  broken pass in 32624

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 32624 like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                         broken  
 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-pair host-install/dst_host(4)

Not pushing.

(No revision log; it would be 34929 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 Dec 26 01:41:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 01: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 1Y4Jt9-00014r-St; Fri, 26 Dec 2014 01:40: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 1Y4Jt8-00014m-Hs
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 01:40:22 +0000
Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id
	09/43-28865-58CBC945; Fri, 26 Dec 2014 01:40:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1419558019!15212607!1
X-Originating-IP: [66.165.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 11023 invoked from network); 26 Dec 2014 01:40:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2014 01:40:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,645,1413244800"; d="scan'208";a="208666924"
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.210.2; Thu, 25 Dec 2014 20:40: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 1Y4Jt3-00080J-O4;
	Fri, 26 Dec 2014 01:40:17 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4Jt3-0001Ik-It;
	Fri, 26 Dec 2014 01:40:17 +0000
Date: Fri, 26 Dec 2014 01:40:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32651-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] 32651: 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 32651 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32651/

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-pair          4 host-install/dst_host(4)  broken pass in 32624

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   like 26303
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 32624 like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                         broken  
 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-pair host-install/dst_host(4)

Not pushing.

(No revision log; it would be 34929 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 Dec 26 04:58:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 04:58:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4Mxs-0004Rb-Uu; Fri, 26 Dec 2014 04:57: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 1Y4Mxq-0004RW-IU
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 04:57:26 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	A9/6E-02696-5BAEC945; Fri, 26 Dec 2014 04:57:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1419569843!17238113!1
X-Originating-IP: [66.165.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 535 invoked from network); 26 Dec 2014 04:57:24 -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;
	26 Dec 2014 04:57:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,646,1413244800"; d="scan'208";a="208168000"
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.210.2; Thu, 25 Dec 2014 23:57: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 1Y4Mxj-0000WC-Ft;
	Fri, 26 Dec 2014 04:57:19 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4Mxj-00039j-65;
	Fri, 26 Dec 2014 04:57:19 +0000
Date: Fri, 26 Dec 2014 04:57:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32655-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] 32655: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32655 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32655/

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. 32564

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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  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-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                f9f7b9d7aeedb0f6150bc9df08542c3a0b67a4ef
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 26 04:58:02 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 04:58:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4Mxs-0004Rb-Uu; Fri, 26 Dec 2014 04:57: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 1Y4Mxq-0004RW-IU
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 04:57:26 +0000
Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id
	A9/6E-02696-5BAEC945; Fri, 26 Dec 2014 04:57:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1419569843!17238113!1
X-Originating-IP: [66.165.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 535 invoked from network); 26 Dec 2014 04:57:24 -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;
	26 Dec 2014 04:57:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,646,1413244800"; d="scan'208";a="208168000"
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.210.2; Thu, 25 Dec 2014 23:57: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 1Y4Mxj-0000WC-Ft;
	Fri, 26 Dec 2014 04:57:19 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4Mxj-00039j-65;
	Fri, 26 Dec 2014 04:57:19 +0000
Date: Fri, 26 Dec 2014 04:57:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32655-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] 32655: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32655 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32655/

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. 32564

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32564
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32564
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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  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-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                f9f7b9d7aeedb0f6150bc9df08542c3a0b67a4ef
baseline version:
 linux                97bf6af1f928216fd6c5a66e8a57bfa95a659672

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 26 05:14:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 05:14:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4NDd-000527-MW; Fri, 26 Dec 2014 05:13:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@vmm.sh.intel.com>) id 1Y4NDc-000522-LF
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 05:13:44 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	28/E9-01660-78EEC945; Fri, 26 Dec 2014 05:13:43 +0000
X-Env-Sender: robert.hu@vmm.sh.intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1419570821!12324978!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 31518 invoked from network); 26 Dec 2014 05:13:42 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-16.tower-206.messagelabs.com with SMTP;
	26 Dec 2014 05:13:42 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by orsmga102.jf.intel.com with ESMTP; 25 Dec 2014 21:11:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="433538491"
Received: from unknown (HELO [10.239.13.113]) ([10.239.13.113])
	by FMSMGA003.fm.intel.com with ESMTP; 25 Dec 2014 21:01:58 -0800
Message-ID: <1419570818.28100.2.camel@localhost>
From: Robert Hu <robert.hu@vmm.sh.intel.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 26 Dec 2014 13:13:38 +0800
In-Reply-To: <20141211110632.GC21659@zion.uk.xensource.com>
References: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
	<1418198860-29802-2-git-send-email-longtaox.pang@intel.com>
	<20141211110632.GC21659@zion.uk.xensource.com>
Organization: Intel OTC
X-Mailer: Evolution 3.8.5 (3.8.5-21.el7) 
Mime-Version: 1.0
Cc: Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	robert.hu@intel.com, "longtao.pang" <longtaox.pang@intel.com>,
	di.zheng@intel.com
Subject: Re: [Xen-devel] [OSSTEST PATCH 1/4] Add nested testcase of
 preparing and installing L1 guest VM
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 Thu, 2014-12-11 at 11:06 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 04:07:37PM +0800, longtao.pang wrote:
> > 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      |   27 ++++++++++++++++++---------
> >  Osstest/TestSupport.pm |   31 ++++++++++++++++++++++++++-----
> >  sg-run-job             |    5 +++++
> >  ts-debian-hvm-install  |   34 ++++++++++++++++++++++++----------
> >  4 files changed, 73 insertions(+), 24 deletions(-)
> > 
> > diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> > index c8db601..a671d20 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
> > @@ -34,6 +35,7 @@ BEGIN {
> >      @EXPORT      = qw(debian_boot_setup
> >                        %preseed_cmds
> >                        preseed_base
> > +                      setupboot_grub2
> 
> Why do you want to export this helper? I think debian_setup_boot will
> just choose the right one amongst uboot, grub1 and grub2.
> 
> >                        preseed_create
> >                        preseed_hook_command preseed_hook_installscript
> >                        di_installcmdline_core
> > @@ -286,15 +288,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));
> 
> Please don't make non-functional change like this.
> 
> >  		if (@missing) {
> >  		    logm("(skipping entry at $entry->{StartLine};".
> >  			 " no @missing)");
> > @@ -317,21 +322,25 @@ 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\S+)/) {
> > +#	    if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
> 
> And if this line is redundant, remove it. What's the reason of changing
> this regex? Are you using non-debian based distro?
> 
> >                  die unless $entry;
> >                  $entry->{Hv}= $1;
> >              }
> > -            if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
> > +	    if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
> 
> And this?
> 
> >                  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;
> >              }
> >          }
> 
> As I said before, this hunk should be in its own patch.
> 
> Just FYI, there are multiple people (Dario, you and I) touching this
> piece of code. You might want to keep an eye on main OSSTest git tree
> and rebase before reposting (and so do Dario and I).
> 
> > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > index a3b6936..1e47039 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
> 
> Please don't just change white spaces. This makes patches hard to
> review.
> 
> >                        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
> 
> Indentation. I think we mostly use space instead of hard tab. Ian?
So what's the convention in Xen code writing? use space instead of tab?
And how many space to substitute 1 tab? I used to use 4. 
> 
> >                        );
> >      %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 @_;
> > @@ -717,6 +727,7 @@ sub power_cycle_time ($) {
> >  sub power_cycle ($) {
> >      my ($ho) = @_;
> >      $mjobdb->host_check_allocated($ho);
> > +    $mjobdb->xen_check_installed($ho);
> 
> And this is? I don't see implementation in this patch set.
> 
> Also this routine is called by ts-host-install, which doesn't necessary
> require Xen to be installed.
> 
> >      die "refusing to set power state for host $ho->{Name}".
> >  	" possibly shared with other jobs\n"
> >  	if $ho->{SharedMaybeOthers};
> > @@ -937,7 +948,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 {
> 
> This should go into its own patch as well. I think it's probably nested
> virt is slower than real hardware so you need some more time?
> 
> >          my $output;
> >          if (!eval {
> >              $output= target_cmd_output($ho, <<END, 40);
> > @@ -1465,7 +1476,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}' ]
> 
> What is this needed? If it's necessary, please use a single commit and
> state the reason in commit log.
> 
> >  #
> >  on_poweroff = 'destroy'
> >  on_reboot   = '$onreboot'
> > @@ -2063,4 +2074,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/;
> 
> This pattern is different than the one used to match. This should also
> go into its own commit -- "Introduce guest_editconfig_cd".
> 
> > +        }
> > +        s/^on_reboot.*/on_reboot='restart'/;
> > +    });
> > +}
> > +
> >  1;
> > diff --git a/sg-run-job b/sg-run-job
> > index 2cf810a..8dcf7af 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-debian-hvm-install + host + nested + nested_L1
> > +}
> > +
> >  proc test-guest-migr {g} {
> >      if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
> >  
> 
> This hunk should go into its own commit.
> 
> > diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
> > index 37eade2..6dcec3c 100755
> > --- a/ts-debian-hvm-install
> > +++ b/ts-debian-hvm-install
> 
> The modification of debian-hvm-install should also go into a single
> commit.
> 
> > @@ -28,22 +28,24 @@ 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;
> > +our ($whhost,$gn,$nested_L1,$guesthost) = @ARGV;
> >  $whhost ||= 'host';
> > -$gn ||= 'debianhvm';
> > -
> > +$nested_L1 ||= '';
> > +if ($nested_L1 eq 'nested_L1') {
> > +    $gn ||= 'nested';
> > +    $guesthost ||= "$gn.l1.osstest";
> > +} else {
> > +    $gn ||= 'debianhvm';
> > +    $guesthost= "$gn.guest.osstest";
> > +}
> >  our $ho= selecthost($whhost);
> > -
> > +our $disk_mb= 50000;
> >  # guest memory size will be set based on host free memory, see below
> >  our $ram_mb;
> > -our $disk_mb= 10000;
> > -
> > -our $guesthost= "$gn.guest.osstest";
> >  our $gho;
> >  
> >  our $toolstack= toolstack()->{Command};
> >  
> > -
> 
> Stray blank line change. Please avoid this kind of changes.
> 
> >  sub preseed () {
> >  
> >      my $preseed_file = preseed_base('wheezy','',());
> > @@ -63,7 +65,7 @@ d-i partman-auto/expert_recipe string \\
> >                          use_filesystem{ } filesystem{ vfat } \\
> >                          mountpoint{ /boot/efi } \\
> >                  . \\
> > -                5000 50 5000 ext4 \\
> > +                25000 50 25000 ext4 \\
> >                          method{ format } format{ } \\
> >                          use_filesystem{ } filesystem{ ext4 } \\
> >                          mountpoint{ / } \\
> > @@ -155,6 +157,8 @@ sub prep () {
> >      more_prepareguest_hvm($ho,$gho, $ram_mb, $disk_mb,
> >                            OnReboot => 'preserve',
> >                            Bios => $r{bios},
> > +                          DefVcpus => 4,
> 
> And where is this handled?
> 
> Wei.
> 
> > +                          ExtraConfig => '#nestedhvm=1',
> >                            PostImageHook => sub {
> >          my $cmds = iso_copy_content_from_image($gho, $newiso);
> >          $cmds .= prepare_initrd($initrddir,$newiso,$preseed_file_path);
> > @@ -176,6 +180,8 @@ my $ram_minslop = 100;
> >  my $ram_lots = 5000;
> >  if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
> >      $ram_mb = $ram_lots;
> > +} elsif ($nested_L1 eq 'nested_L1') {
> > +    $ram_mb = 2048;
> >  } else {
> >      $ram_mb = 768;
> >  }
> > @@ -192,7 +198,15 @@ if ($stage<2) {
> >      guest_destroy($ho,$gho);
> >  }
> >  
> > -guest_editconfig_nocd($gho,$emptyiso);
> > +if ($nested_L1 eq 'nested_L1') {
> > +    guest_editconfig_cd($gho);
> > +} else {
> > +    guest_editconfig_nocd($gho,$emptyiso);
> > +}
> >  guest_create($gho,$toolstack);
> >  guest_await_dhcp_tcp($gho,300);
> >  guest_check_up($gho);
> > +if ($nested_L1 eq 'nested_L1') {
> > +    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 Dec 26 05:14:08 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 05:14:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4NDd-000527-MW; Fri, 26 Dec 2014 05:13:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.hu@vmm.sh.intel.com>) id 1Y4NDc-000522-LF
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 05:13:44 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	28/E9-01660-78EEC945; Fri, 26 Dec 2014 05:13:43 +0000
X-Env-Sender: robert.hu@vmm.sh.intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1419570821!12324978!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 31518 invoked from network); 26 Dec 2014 05:13:42 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-16.tower-206.messagelabs.com with SMTP;
	26 Dec 2014 05:13:42 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by orsmga102.jf.intel.com with ESMTP; 25 Dec 2014 21:11:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="433538491"
Received: from unknown (HELO [10.239.13.113]) ([10.239.13.113])
	by FMSMGA003.fm.intel.com with ESMTP; 25 Dec 2014 21:01:58 -0800
Message-ID: <1419570818.28100.2.camel@localhost>
From: Robert Hu <robert.hu@vmm.sh.intel.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 26 Dec 2014 13:13:38 +0800
In-Reply-To: <20141211110632.GC21659@zion.uk.xensource.com>
References: <1418198860-29802-1-git-send-email-longtaox.pang@intel.com>
	<1418198860-29802-2-git-send-email-longtaox.pang@intel.com>
	<20141211110632.GC21659@zion.uk.xensource.com>
Organization: Intel OTC
X-Mailer: Evolution 3.8.5 (3.8.5-21.el7) 
Mime-Version: 1.0
Cc: Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	robert.hu@intel.com, "longtao.pang" <longtaox.pang@intel.com>,
	di.zheng@intel.com
Subject: Re: [Xen-devel] [OSSTEST PATCH 1/4] Add nested testcase of
 preparing and installing L1 guest VM
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 Thu, 2014-12-11 at 11:06 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 04:07:37PM +0800, longtao.pang wrote:
> > 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      |   27 ++++++++++++++++++---------
> >  Osstest/TestSupport.pm |   31 ++++++++++++++++++++++++++-----
> >  sg-run-job             |    5 +++++
> >  ts-debian-hvm-install  |   34 ++++++++++++++++++++++++----------
> >  4 files changed, 73 insertions(+), 24 deletions(-)
> > 
> > diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> > index c8db601..a671d20 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
> > @@ -34,6 +35,7 @@ BEGIN {
> >      @EXPORT      = qw(debian_boot_setup
> >                        %preseed_cmds
> >                        preseed_base
> > +                      setupboot_grub2
> 
> Why do you want to export this helper? I think debian_setup_boot will
> just choose the right one amongst uboot, grub1 and grub2.
> 
> >                        preseed_create
> >                        preseed_hook_command preseed_hook_installscript
> >                        di_installcmdline_core
> > @@ -286,15 +288,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));
> 
> Please don't make non-functional change like this.
> 
> >  		if (@missing) {
> >  		    logm("(skipping entry at $entry->{StartLine};".
> >  			 " no @missing)");
> > @@ -317,21 +322,25 @@ 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\S+)/) {
> > +#	    if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
> 
> And if this line is redundant, remove it. What's the reason of changing
> this regex? Are you using non-debian based distro?
> 
> >                  die unless $entry;
> >                  $entry->{Hv}= $1;
> >              }
> > -            if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
> > +	    if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
> 
> And this?
> 
> >                  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;
> >              }
> >          }
> 
> As I said before, this hunk should be in its own patch.
> 
> Just FYI, there are multiple people (Dario, you and I) touching this
> piece of code. You might want to keep an eye on main OSSTest git tree
> and rebase before reposting (and so do Dario and I).
> 
> > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > index a3b6936..1e47039 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
> 
> Please don't just change white spaces. This makes patches hard to
> review.
> 
> >                        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
> 
> Indentation. I think we mostly use space instead of hard tab. Ian?
So what's the convention in Xen code writing? use space instead of tab?
And how many space to substitute 1 tab? I used to use 4. 
> 
> >                        );
> >      %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 @_;
> > @@ -717,6 +727,7 @@ sub power_cycle_time ($) {
> >  sub power_cycle ($) {
> >      my ($ho) = @_;
> >      $mjobdb->host_check_allocated($ho);
> > +    $mjobdb->xen_check_installed($ho);
> 
> And this is? I don't see implementation in this patch set.
> 
> Also this routine is called by ts-host-install, which doesn't necessary
> require Xen to be installed.
> 
> >      die "refusing to set power state for host $ho->{Name}".
> >  	" possibly shared with other jobs\n"
> >  	if $ho->{SharedMaybeOthers};
> > @@ -937,7 +948,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 {
> 
> This should go into its own patch as well. I think it's probably nested
> virt is slower than real hardware so you need some more time?
> 
> >          my $output;
> >          if (!eval {
> >              $output= target_cmd_output($ho, <<END, 40);
> > @@ -1465,7 +1476,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}' ]
> 
> What is this needed? If it's necessary, please use a single commit and
> state the reason in commit log.
> 
> >  #
> >  on_poweroff = 'destroy'
> >  on_reboot   = '$onreboot'
> > @@ -2063,4 +2074,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/;
> 
> This pattern is different than the one used to match. This should also
> go into its own commit -- "Introduce guest_editconfig_cd".
> 
> > +        }
> > +        s/^on_reboot.*/on_reboot='restart'/;
> > +    });
> > +}
> > +
> >  1;
> > diff --git a/sg-run-job b/sg-run-job
> > index 2cf810a..8dcf7af 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-debian-hvm-install + host + nested + nested_L1
> > +}
> > +
> >  proc test-guest-migr {g} {
> >      if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
> >  
> 
> This hunk should go into its own commit.
> 
> > diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
> > index 37eade2..6dcec3c 100755
> > --- a/ts-debian-hvm-install
> > +++ b/ts-debian-hvm-install
> 
> The modification of debian-hvm-install should also go into a single
> commit.
> 
> > @@ -28,22 +28,24 @@ 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;
> > +our ($whhost,$gn,$nested_L1,$guesthost) = @ARGV;
> >  $whhost ||= 'host';
> > -$gn ||= 'debianhvm';
> > -
> > +$nested_L1 ||= '';
> > +if ($nested_L1 eq 'nested_L1') {
> > +    $gn ||= 'nested';
> > +    $guesthost ||= "$gn.l1.osstest";
> > +} else {
> > +    $gn ||= 'debianhvm';
> > +    $guesthost= "$gn.guest.osstest";
> > +}
> >  our $ho= selecthost($whhost);
> > -
> > +our $disk_mb= 50000;
> >  # guest memory size will be set based on host free memory, see below
> >  our $ram_mb;
> > -our $disk_mb= 10000;
> > -
> > -our $guesthost= "$gn.guest.osstest";
> >  our $gho;
> >  
> >  our $toolstack= toolstack()->{Command};
> >  
> > -
> 
> Stray blank line change. Please avoid this kind of changes.
> 
> >  sub preseed () {
> >  
> >      my $preseed_file = preseed_base('wheezy','',());
> > @@ -63,7 +65,7 @@ d-i partman-auto/expert_recipe string \\
> >                          use_filesystem{ } filesystem{ vfat } \\
> >                          mountpoint{ /boot/efi } \\
> >                  . \\
> > -                5000 50 5000 ext4 \\
> > +                25000 50 25000 ext4 \\
> >                          method{ format } format{ } \\
> >                          use_filesystem{ } filesystem{ ext4 } \\
> >                          mountpoint{ / } \\
> > @@ -155,6 +157,8 @@ sub prep () {
> >      more_prepareguest_hvm($ho,$gho, $ram_mb, $disk_mb,
> >                            OnReboot => 'preserve',
> >                            Bios => $r{bios},
> > +                          DefVcpus => 4,
> 
> And where is this handled?
> 
> Wei.
> 
> > +                          ExtraConfig => '#nestedhvm=1',
> >                            PostImageHook => sub {
> >          my $cmds = iso_copy_content_from_image($gho, $newiso);
> >          $cmds .= prepare_initrd($initrddir,$newiso,$preseed_file_path);
> > @@ -176,6 +180,8 @@ my $ram_minslop = 100;
> >  my $ram_lots = 5000;
> >  if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
> >      $ram_mb = $ram_lots;
> > +} elsif ($nested_L1 eq 'nested_L1') {
> > +    $ram_mb = 2048;
> >  } else {
> >      $ram_mb = 768;
> >  }
> > @@ -192,7 +198,15 @@ if ($stage<2) {
> >      guest_destroy($ho,$gho);
> >  }
> >  
> > -guest_editconfig_nocd($gho,$emptyiso);
> > +if ($nested_L1 eq 'nested_L1') {
> > +    guest_editconfig_cd($gho);
> > +} else {
> > +    guest_editconfig_nocd($gho,$emptyiso);
> > +}
> >  guest_create($gho,$toolstack);
> >  guest_await_dhcp_tcp($gho,300);
> >  guest_check_up($gho);
> > +if ($nested_L1 eq 'nested_L1') {
> > +    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 Dec 26 07:41:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 07:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4PVc-0007Oe-O8; Fri, 26 Dec 2014 07:40: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 1Y4PVa-0007OZ-Sr
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 07:40:27 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	B6/79-17735-9E01D945; Fri, 26 Dec 2014 07:40:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1419579623!11405727!1
X-Originating-IP: [66.165.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 22939 invoked from network); 26 Dec 2014 07:40:24 -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;
	26 Dec 2014 07:40:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,646,1413244800"; d="scan'208";a="208192694"
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.210.2; Fri, 26 Dec 2014 02:40: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 1Y4PVV-0001LA-QH;
	Fri, 26 Dec 2014 07:40:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4PVV-0001vx-FB;
	Fri, 26 Dec 2014 07:40:21 +0000
Date: Fri, 26 Dec 2014 07:40:21 +0000
Message-ID: <E1Y4PVV-0001vx-FB@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] [qemu-mainline bisection] complete
	test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-amd
test redhat-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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-i386-qemuu-rhel6hvm-amd.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32626 fail [host=potato-beetle] / 32598 [host=leaf-beetle] 32585 ok.
Failure / basis pass flights: 32626 / 32585
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#83a926f7a4e39fb6be0576024e67fe161593defa-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#c95f3901b4ead79f3fe2c641fda7d2c70fc84c72-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 1005 nodes in revision graph
Searching for test results:
 32571 [host=lace-bug]
 32585 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32598 [host=leaf-beetle]
 32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32632 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32678 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32650 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32680 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32653 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c8e829b7bf6e1c84af8b4b13ee7fce2959c63e0e 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32682 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32658 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7eb1dc7f0b65a324323541440baf2ea544adcefb 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32661 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32666 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32667 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32675 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 32585 (pass), for basis pass
 Result found: flight 32611 (fail), for basis failure
 Repro found: flight 32632 (pass), for basis pass
 Repro found: flight 32650 (fail), for basis failure
 0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32661 (pass), for last pass
 Result found: flight 32667 (fail), for first failure
 Repro found: flight 32675 (pass), for last pass
 Repro found: flight 32678 (fail), for first failure
 Repro found: flight 32680 (pass), for last pass
 Repro found: flight 32682 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-i386-qemuu-rhel6hvm-amd.redhat-install.{dot,ps,png,html}.
----------------------------------------
32682: tolerable ALL FAIL

flight 32682 qemu-mainline real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32682/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install    fail baseline untested


jobs:
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Dec 26 07:41:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 07:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4PVc-0007Oe-O8; Fri, 26 Dec 2014 07:40: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 1Y4PVa-0007OZ-Sr
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 07:40:27 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	B6/79-17735-9E01D945; Fri, 26 Dec 2014 07:40:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1419579623!11405727!1
X-Originating-IP: [66.165.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 22939 invoked from network); 26 Dec 2014 07:40:24 -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;
	26 Dec 2014 07:40:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,646,1413244800"; d="scan'208";a="208192694"
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.210.2; Fri, 26 Dec 2014 02:40: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 1Y4PVV-0001LA-QH;
	Fri, 26 Dec 2014 07:40:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4PVV-0001vx-FB;
	Fri, 26 Dec 2014 07:40:21 +0000
Date: Fri, 26 Dec 2014 07:40:21 +0000
Message-ID: <E1Y4PVV-0001vx-FB@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] [qemu-mainline bisection] complete
	test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-amd
test redhat-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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-i386-qemuu-rhel6hvm-amd.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32626 fail [host=potato-beetle] / 32598 [host=leaf-beetle] 32585 ok.
Failure / basis pass flights: 32626 / 32585
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#83a926f7a4e39fb6be0576024e67fe161593defa-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#c95f3901b4ead79f3fe2c641fda7d2c70fc84c72-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 1005 nodes in revision graph
Searching for test results:
 32571 [host=lace-bug]
 32585 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32598 [host=leaf-beetle]
 32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32632 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32678 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32650 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32680 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32653 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c8e829b7bf6e1c84af8b4b13ee7fce2959c63e0e 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32682 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32658 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7eb1dc7f0b65a324323541440baf2ea544adcefb 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32661 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32666 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32667 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32675 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 32585 (pass), for basis pass
 Result found: flight 32611 (fail), for basis failure
 Repro found: flight 32632 (pass), for basis pass
 Repro found: flight 32650 (fail), for basis failure
 0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32661 (pass), for last pass
 Result found: flight 32667 (fail), for first failure
 Repro found: flight 32675 (pass), for last pass
 Repro found: flight 32678 (fail), for first failure
 Repro found: flight 32680 (pass), for last pass
 Repro found: flight 32682 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-i386-qemuu-rhel6hvm-amd.redhat-install.{dot,ps,png,html}.
----------------------------------------
32682: tolerable ALL FAIL

flight 32682 qemu-mainline real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32682/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install    fail baseline untested


jobs:
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Dec 26 10:00:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 10:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4RgW-0001aP-R4; Fri, 26 Dec 2014 09:59: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 1Y4RgV-0001aK-0E
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 09:59:51 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	9A/F7-24859-6913D945; Fri, 26 Dec 2014 09:59:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419587988!15847979!1
X-Originating-IP: [66.165.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 2100 invoked from network); 26 Dec 2014 09:59:49 -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 Dec 2014 09:59:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,646,1413244800"; d="scan'208";a="208745198"
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.210.2; Fri, 26 Dec 2014 04:59: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 1Y4RgP-00020M-Lm;
	Fri, 26 Dec 2014 09:59:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4RgP-0005vr-Gf;
	Fri, 26 Dec 2014 09:59:45 +0000
Date: Fri, 26 Dec 2014 09:59:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32659-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] 32659: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32659 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32659/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 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 912 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 Dec 26 10:00:27 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 10:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4RgW-0001aP-R4; Fri, 26 Dec 2014 09:59: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 1Y4RgV-0001aK-0E
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 09:59:51 +0000
Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id
	9A/F7-24859-6913D945; Fri, 26 Dec 2014 09:59:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419587988!15847979!1
X-Originating-IP: [66.165.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 2100 invoked from network); 26 Dec 2014 09:59:49 -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 Dec 2014 09:59:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,646,1413244800"; d="scan'208";a="208745198"
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.210.2; Fri, 26 Dec 2014 04:59: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 1Y4RgP-00020M-Lm;
	Fri, 26 Dec 2014 09:59:45 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4RgP-0005vr-Gf;
	Fri, 26 Dec 2014 09:59:45 +0000
Date: Fri, 26 Dec 2014 09:59:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32659-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] 32659: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32659 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32659/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 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 912 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 Dec 26 10:58:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 10:58:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4Sat-0002fd-I3; Fri, 26 Dec 2014 10:58:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <upanshu.singhal@emc.com>) id 1Y4Sar-0002fY-Ty
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 10:58:06 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	CB/98-26858-D3F3D945; Fri, 26 Dec 2014 10:58:05 +0000
X-Env-Sender: upanshu.singhal@emc.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1419591483!11429095!1
X-Originating-IP: [168.159.213.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTY4LjE1OS4yMTMuMTQxID0+IDcwMzQ2OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15972 invoked from network); 26 Dec 2014 10:58:04 -0000
Received: from mailuogwhop.emc.com (HELO mailuogwhop.emc.com) (168.159.213.141)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Dec 2014 10:58:04 -0000
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com
	[10.253.24.38])
	by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBQAw2Od011235
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Dec 2014 05:58:02 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com sBQAw2Od011235
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013;
	t=1419591482; bh=6sg+2RH2l2zMZIwjCCsqlI4E8mM=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	Content-Type:Content-Transfer-Encoding:MIME-Version;
	b=EEDHT4mT9JOWv+d2d0RZze7sqCdk6RdvV4/0TFOQJIm9l1t++NdDrUjU+RAZ9dEip
	G/R1E0PJ27LP2dUzerXInDPqXrr9WRwqI+ry5JTfzRfmQpRq66hhnpCTd5V1dhn97j
	iWWvC/IEDDMqQBTlljG+SlC831cFwbl6b6JMJvck=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com sBQAw2Od011235
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com
	[10.106.48.18]) by maildlpprd06.lss.emc.com (RSA Interceptor);
	Fri, 26 Dec 2014 05:57:36 -0500
Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135])
	by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBQAvnfT018205
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 26 Dec 2014 05:57:50 -0500
Received: from MXHUB102.corp.emc.com (10.253.58.15) by mxhub23.corp.emc.com
	(128.222.70.135) with Microsoft SMTP Server (TLS) id 8.3.327.1;
	Fri, 26 Dec 2014 05:57:49 -0500
Received: from MX101CL01.corp.emc.com ([169.254.1.90]) by
	MXHUB102.corp.emc.com ([::1]) with mapi id 14.03.0195.001;
	Fri, 26 Dec 2014 05:57:48 -0500
From: "Singhal, Upanshu" <upanshu.singhal@emc.com>
To: Don Slutz <dslutz@verizon.com>
Thread-Topic: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
Thread-Index: AdAbg+gVpGg69F+/TKC4f+QiMDYySwAgTHmAAGwE/hAAOkKz8ABCrBkAAFRrjoA=
Date: Fri, 26 Dec 2014 10:57:48 +0000
Message-ID: <6A5D14D0DFEABC43BE832A0E492963F14EBBB4A1@MX101CL01.corp.emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
	<5494A6AF.1030802@terremark.com>
	<6A5D14D0DFEABC43BE832A0E492963F14EBB9C30@MX101CL01.corp.emc.com>
	<549AC200.6020509@terremark.com>
In-Reply-To: <549AC200.6020509@terremark.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.30.79.65]
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: DLP to NYP, DLM_1, public
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Don,

Thanks a lot for your help. I am able to create the PVSCSI type disks on my XEN VM, below method is perfect.

Appreciate your response, wish you a very happy holidays.

Thanks,
-Upanshu

-----Original Message-----
From: Don Slutz [mailto:dslutz@verizon.com] 
Sent: Wednesday, December 24, 2014 7:09 PM
To: Singhal, Upanshu
Cc: Don Slutz; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

On 12/23/14 05:51, Singhal, Upanshu wrote:
>
> Hello Don,
>
> I am not trying to configure VMW PVSCSI type of device but not able to 
> do so. Though, PVSCSI is available on the distribution I am using. Any 
> inputs on how to configure PVSCSI type disk device?
>

device_model_args_hvm = [
"-device",
"pvscsi,id=scsi1",
"-drive",
"if=none,id=disk1,file=/home/don/qemu-img/C63-min-disk1.raw",
"-device",
"scsi-disk,bus=scsi1.0,scsi-id=0,drive=disk1",
]

-Don Slutz

> Thanks,
>
> -Upanshu
>
> *From:*Singhal, Upanshu
> *Sent:* Monday, December 22, 2014 12:35 PM
> *To:* 'Don Slutz'
> *Cc:* 'xen-devel@lists.xen.org'
> *Subject:* RE: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
>
> Hello Don,
>
> xen_emul_unplug=unnecessarydoes the trick, I am able to see the
> vmxnet3 driver using lspci and ethtool -I eth0. Thanks a lot for your 
> help, much appreciated.
>
> Performance between vmxnet3 running on XEN is about 1/3 of vmxnet3 
> running on ESXi. Similar performance number I get between vmxnet3 on 
> ESXi and vif on XEN. Do you know what could be the reason for this?
>
> Thanks,
>
> -Upanshu
>
> *From:*Don Slutz [mailto:dslutz@verizon.com]
> *Sent:* Saturday, December 20, 2014 3:59 AM
> *To:* Singhal, Upanshu
> *Cc:* xen-devel@lists.xen.org <mailto:xen-devel@lists.xen.org>
> *Subject:* Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
>
> xen_emul_unplug=unnecessary (kernel arg) may help you here.
>
> Also udev likes to rename your devices.
>
> Here is a lspci from a guest:
>
>
> [root@C63-min-tools ~]# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device 
> (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
> Ethernet Controller (rev 03)
> 00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
> Ethernet Controller (rev 03)
>
> And to help:
>
> [root@C63-min-tools ~]# ls -l /sys/class/net/*/device lrwxrwxrwx. 1 
> root root 0 Dec 19 17:23 /sys/class/net/eth0/device ->
> ../../../vif-0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device ->
> ../../../vif-1
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device ->
> ../../../vif-2
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device ->
> ../../../vif-3
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device ->
> ../../../vif-4
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device ->
> ../../../vif-5
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device ->
> ../../../vif-6
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device ->
> ../../../vif-7
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device ->
> ../../../vif-8
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device ->
> ../../../vif-9
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device
> -> ../../../0000:00:04.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device
> -> ../../../0000:00:05.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device
> -> ../../../0000:00:06.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device
> -> ../../../0000:00:07.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device
> -> ../../../0000:00:08.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device
> -> ../../../0000:00:09.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device
> -> ../../../0000:00:0a.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device
> -> ../../../0000:00:0b.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device
> -> ../../../0000:00:0c.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device
> -> ../../../0000:00:0d.0
>
>
> -Don Slutz
>
> On 12/19/14 07:04, Singhal, Upanshu wrote:
>
>     Hello,
>
>     In one of my experiment, I am building a Linux VM with Network
>     interface model as "vmxnet3". I am able to create the VM
>     successfully, but I see that the driver loaded is "vif" and not
>     "vmxnet3". I am using the following option for the network
>     interface: *vif = [ 'type=ioemu, mac=00:16:3e:00:00:22,
>     bridge=xenbr0, model=vmxnet3' ]*
>
>     **
>
>     I tried with model as e1000 and it works fine. Lspci command also
>     does not show vmxnet3. Though, qemu device help shows that
>     "vmxnet3" is supported on XEN 4.4.1 version I am using.
>
>     I tried searching on internet about the right configuration for
>     vmxnet3 with XEN, but not able to find right information. Can
>     someone please help me on how to create a VM with vmxnet3?
>
>     This experiment I am doing to compare the difference between
>     vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM
>     configuration file is:
>
>     # This configures an HVM rather than PV guest
>
>     builder = "hvm"
>
>     # Guest name
>
>     *name = "rhel-vmxnet3-xen-2.hvm"*
>
>     # 128-bit UUID for the domain as a hexadecimal number.
>
>     # Use "uuidgen" to generate one if required.
>
>     # The default behavior is to generate a new UUID each time the
>     guest is started.
>
>     #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
>
>     # Enable Microsoft Hyper-V compatibile paravirtualisation /
>
>     # enlightenment interfaces. Turning this on can improve Windows 
> guest
>
>     # performance and is therefore recommended
>
>     #viridian = 1
>
>     # Initial memory allocation (MB)
>
>     *memory = 8192*
>
>     # Maximum memory (MB)
>
>     # If this is greater than `memory' then the slack will start 
> ballooned
>
>     # (this assumes guest kernel support for ballooning)
>
>     #maxmem = 512
>
>     # Number of VCPUS
>
>     *vcpus = 8*
>
>     # Network devices
>
>     # A list of 'vifspec' entries as described in
>
>     # docs/misc/xl-network-configuration.markdown
>
>     vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr1,
>     model=vmxnet3' ]
>
>     # Disk Devices
>
>     # A list of `diskspec' entries as described in
>
>     # docs/misc/xl-disk-configuration.txt
>
>     *disk = [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw',
>     'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r
>     <file:///%5C%5Croot%5Crhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r>' 
> ]*
>
>     *boot='cd'*
>
>     # Guest VGA console configuration, either SDL or VNC
>
>     # sdl = 1
>
>     *vnc = 2*
>
>     Thanks,
>
>     -Upanshu
>
>     Upanshu Singhal
>
>     EMC Data Storage Systems, Bangalore, India.
>
>     Phone: 91-80-67375604
>
>
>
>     _______________________________________________
>
>     Xen-devel mailing list
>
>     Xen-devel@lists.xen.org  <mailto:Xen-devel@lists.xen.org>
>
>     http://lists.xen.org/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 Dec 26 10:58:37 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 10:58:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4Sat-0002fd-I3; Fri, 26 Dec 2014 10:58:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <upanshu.singhal@emc.com>) id 1Y4Sar-0002fY-Ty
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 10:58:06 +0000
Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id
	CB/98-26858-D3F3D945; Fri, 26 Dec 2014 10:58:05 +0000
X-Env-Sender: upanshu.singhal@emc.com
X-Msg-Ref: server-6.tower-31.messagelabs.com!1419591483!11429095!1
X-Originating-IP: [168.159.213.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTY4LjE1OS4yMTMuMTQxID0+IDcwMzQ2OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15972 invoked from network); 26 Dec 2014 10:58:04 -0000
Received: from mailuogwhop.emc.com (HELO mailuogwhop.emc.com) (168.159.213.141)
	by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Dec 2014 10:58:04 -0000
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com
	[10.253.24.38])
	by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBQAw2Od011235
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Dec 2014 05:58:02 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com sBQAw2Od011235
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013;
	t=1419591482; bh=6sg+2RH2l2zMZIwjCCsqlI4E8mM=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	Content-Type:Content-Transfer-Encoding:MIME-Version;
	b=EEDHT4mT9JOWv+d2d0RZze7sqCdk6RdvV4/0TFOQJIm9l1t++NdDrUjU+RAZ9dEip
	G/R1E0PJ27LP2dUzerXInDPqXrr9WRwqI+ry5JTfzRfmQpRq66hhnpCTd5V1dhn97j
	iWWvC/IEDDMqQBTlljG+SlC831cFwbl6b6JMJvck=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com sBQAw2Od011235
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com
	[10.106.48.18]) by maildlpprd06.lss.emc.com (RSA Interceptor);
	Fri, 26 Dec 2014 05:57:36 -0500
Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135])
	by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0)
	with ESMTP id sBQAvnfT018205
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 26 Dec 2014 05:57:50 -0500
Received: from MXHUB102.corp.emc.com (10.253.58.15) by mxhub23.corp.emc.com
	(128.222.70.135) with Microsoft SMTP Server (TLS) id 8.3.327.1;
	Fri, 26 Dec 2014 05:57:49 -0500
Received: from MX101CL01.corp.emc.com ([169.254.1.90]) by
	MXHUB102.corp.emc.com ([::1]) with mapi id 14.03.0195.001;
	Fri, 26 Dec 2014 05:57:48 -0500
From: "Singhal, Upanshu" <upanshu.singhal@emc.com>
To: Don Slutz <dslutz@verizon.com>
Thread-Topic: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
Thread-Index: AdAbg+gVpGg69F+/TKC4f+QiMDYySwAgTHmAAGwE/hAAOkKz8ABCrBkAAFRrjoA=
Date: Fri, 26 Dec 2014 10:57:48 +0000
Message-ID: <6A5D14D0DFEABC43BE832A0E492963F14EBBB4A1@MX101CL01.corp.emc.com>
References: <6A5D14D0DFEABC43BE832A0E492963F14EBB836C@MX101CL01.corp.emc.com>
	<5494A6AF.1030802@terremark.com>
	<6A5D14D0DFEABC43BE832A0E492963F14EBB9C30@MX101CL01.corp.emc.com>
	<549AC200.6020509@terremark.com>
In-Reply-To: <549AC200.6020509@terremark.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.30.79.65]
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: DLP to NYP, DLM_1, public
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Don,

Thanks a lot for your help. I am able to create the PVSCSI type disks on my XEN VM, below method is perfect.

Appreciate your response, wish you a very happy holidays.

Thanks,
-Upanshu

-----Original Message-----
From: Don Slutz [mailto:dslutz@verizon.com] 
Sent: Wednesday, December 24, 2014 7:09 PM
To: Singhal, Upanshu
Cc: Don Slutz; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

On 12/23/14 05:51, Singhal, Upanshu wrote:
>
> Hello Don,
>
> I am not trying to configure VMW PVSCSI type of device but not able to 
> do so. Though, PVSCSI is available on the distribution I am using. Any 
> inputs on how to configure PVSCSI type disk device?
>

device_model_args_hvm = [
"-device",
"pvscsi,id=scsi1",
"-drive",
"if=none,id=disk1,file=/home/don/qemu-img/C63-min-disk1.raw",
"-device",
"scsi-disk,bus=scsi1.0,scsi-id=0,drive=disk1",
]

-Don Slutz

> Thanks,
>
> -Upanshu
>
> *From:*Singhal, Upanshu
> *Sent:* Monday, December 22, 2014 12:35 PM
> *To:* 'Don Slutz'
> *Cc:* 'xen-devel@lists.xen.org'
> *Subject:* RE: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
>
> Hello Don,
>
> xen_emul_unplug=unnecessarydoes the trick, I am able to see the
> vmxnet3 driver using lspci and ethtool -I eth0. Thanks a lot for your 
> help, much appreciated.
>
> Performance between vmxnet3 running on XEN is about 1/3 of vmxnet3 
> running on ESXi. Similar performance number I get between vmxnet3 on 
> ESXi and vif on XEN. Do you know what could be the reason for this?
>
> Thanks,
>
> -Upanshu
>
> *From:*Don Slutz [mailto:dslutz@verizon.com]
> *Sent:* Saturday, December 20, 2014 3:59 AM
> *To:* Singhal, Upanshu
> *Cc:* xen-devel@lists.xen.org <mailto:xen-devel@lists.xen.org>
> *Subject:* Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
>
> xen_emul_unplug=unnecessary (kernel arg) may help you here.
>
> Also udev likes to rename your devices.
>
> Here is a lspci from a guest:
>
>
> [root@C63-min-tools ~]# 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.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device 
> (rev 01)
> 00:03.0 VGA compatible controller: Cirrus Logic GD 5446
> 00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
> Ethernet Controller (rev 03)
> 00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 
> 01)
> 00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
> Ethernet Controller (rev 03)
>
> And to help:
>
> [root@C63-min-tools ~]# ls -l /sys/class/net/*/device lrwxrwxrwx. 1 
> root root 0 Dec 19 17:23 /sys/class/net/eth0/device ->
> ../../../vif-0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device ->
> ../../../vif-1
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device ->
> ../../../vif-2
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device ->
> ../../../vif-3
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device ->
> ../../../vif-4
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device ->
> ../../../vif-5
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device ->
> ../../../vif-6
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device ->
> ../../../vif-7
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device ->
> ../../../vif-8
> lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device ->
> ../../../vif-9
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device
> -> ../../../0000:00:04.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device
> -> ../../../0000:00:05.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device
> -> ../../../0000:00:06.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device
> -> ../../../0000:00:07.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device
> -> ../../../0000:00:08.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device
> -> ../../../0000:00:09.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device
> -> ../../../0000:00:0a.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device
> -> ../../../0000:00:0b.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device
> -> ../../../0000:00:0c.0
> lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device
> -> ../../../0000:00:0d.0
>
>
> -Don Slutz
>
> On 12/19/14 07:04, Singhal, Upanshu wrote:
>
>     Hello,
>
>     In one of my experiment, I am building a Linux VM with Network
>     interface model as "vmxnet3". I am able to create the VM
>     successfully, but I see that the driver loaded is "vif" and not
>     "vmxnet3". I am using the following option for the network
>     interface: *vif = [ 'type=ioemu, mac=00:16:3e:00:00:22,
>     bridge=xenbr0, model=vmxnet3' ]*
>
>     **
>
>     I tried with model as e1000 and it works fine. Lspci command also
>     does not show vmxnet3. Though, qemu device help shows that
>     "vmxnet3" is supported on XEN 4.4.1 version I am using.
>
>     I tried searching on internet about the right configuration for
>     vmxnet3 with XEN, but not able to find right information. Can
>     someone please help me on how to create a VM with vmxnet3?
>
>     This experiment I am doing to compare the difference between
>     vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM
>     configuration file is:
>
>     # This configures an HVM rather than PV guest
>
>     builder = "hvm"
>
>     # Guest name
>
>     *name = "rhel-vmxnet3-xen-2.hvm"*
>
>     # 128-bit UUID for the domain as a hexadecimal number.
>
>     # Use "uuidgen" to generate one if required.
>
>     # The default behavior is to generate a new UUID each time the
>     guest is started.
>
>     #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
>
>     # Enable Microsoft Hyper-V compatibile paravirtualisation /
>
>     # enlightenment interfaces. Turning this on can improve Windows 
> guest
>
>     # performance and is therefore recommended
>
>     #viridian = 1
>
>     # Initial memory allocation (MB)
>
>     *memory = 8192*
>
>     # Maximum memory (MB)
>
>     # If this is greater than `memory' then the slack will start 
> ballooned
>
>     # (this assumes guest kernel support for ballooning)
>
>     #maxmem = 512
>
>     # Number of VCPUS
>
>     *vcpus = 8*
>
>     # Network devices
>
>     # A list of 'vifspec' entries as described in
>
>     # docs/misc/xl-network-configuration.markdown
>
>     vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr1,
>     model=vmxnet3' ]
>
>     # Disk Devices
>
>     # A list of `diskspec' entries as described in
>
>     # docs/misc/xl-disk-configuration.txt
>
>     *disk = [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw',
>     'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r
>     <file:///%5C%5Croot%5Crhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r>' 
> ]*
>
>     *boot='cd'*
>
>     # Guest VGA console configuration, either SDL or VNC
>
>     # sdl = 1
>
>     *vnc = 2*
>
>     Thanks,
>
>     -Upanshu
>
>     Upanshu Singhal
>
>     EMC Data Storage Systems, Bangalore, India.
>
>     Phone: 91-80-67375604
>
>
>
>     _______________________________________________
>
>     Xen-devel mailing list
>
>     Xen-devel@lists.xen.org  <mailto:Xen-devel@lists.xen.org>
>
>     http://lists.xen.org/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 Dec 26 11:23:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 11:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4SzC-0003HA-1E; Fri, 26 Dec 2014 11:23:14 +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 1Y4SzA-0003H5-CJ
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 11:23:12 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DB/CF-09842-F154D945; Fri, 26 Dec 2014 11:23:11 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1419592989!10610670!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32152 invoked from network); 26 Dec 2014 11:23:09 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-13.tower-21.messagelabs.com with SMTP;
	26 Dec 2014 11:23:09 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 26 Dec 2014 03:19:09 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="433631362"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by FMSMGA003.fm.intel.com with ESMTP; 26 Dec 2014 03:11:24 -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; Fri, 26 Dec 2014 19:23:04 +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; Fri, 26 Dec 2014 19:23:02 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "ian.jackson@eu.citrix.com"
	<ian.jackson@eu.citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad.wilk@oracle.com"
	<konrad.wilk@oracle.com>, "tim@xen.org" <tim@xen.org>
Thread-Topic: (v2) Design proposal for RMRR fix
Thread-Index: AdAg/SjfP/+i9nFZSZuB9vPJZrXwHA==
Date: Fri, 26 Dec 2014 11:23:02 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126126D66@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] (v2) Design proposal for RMRR fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(please note some proposal is different from last sent version after more
discussions. But I tried to summarize previous discussions and explained why
we choose a different way. Sorry if I may miss some opens/conclusions
discussed in past months. Please help point it out which is very appreciated. :-)

----
TOC:
	1. What's RMRR
	2. RMRR status in Xen
	3. High Level Design
		3.1 Guidelines
		3.2 Confliction detection
		3.3 Policies
		3.4 Xen: setup RMRR identity mapping
		3.5 New interface: expose reserved region information
		3.6 Libxc/hvmloader: detect and avoid conflictions
		3.7 Hvmloader: reserve 'reserved regions' in guest E820
		3.8 Xen: Handle devices sharing reserved regions
	4. Plan
		4.1 Stage-1: hypervisor hardening
		4.2 Stage-2: libxc/hvmloader hardening
		
1. What's RMRR?
=====================================================================

RMRR is an acronym for Reserved Memory Region Reporting, expected to 
be used for legacy usages (such as USB, UMA Graphics, etc.) requiring
reserved memory.

(From vt-d spec)
----
Reserved system memory regions are typically allocated by BIOS at boot
time and reported to OS as reserved address ranges in the system memory
map. Requests to these reserved regions may either occur as a result of
operations performed by the system software driver (for example in the
case of DMA from unified memory access (UMA) graphics controllers to
graphics reserved memory) or may be initiated by non system software
(for example in case of DMA performed by a USB controller under BIOS
SMM control for legacy keyboard emulation). 

For proper functioning of these legacy reserved memory usages, when 
system software enables DMA remapping, the translation structures for 
the respective devices are expected to be set up to provide identity 
mapping for the specified reserved memory regions with read and write 
permissions. The system software is also responsible for ensuring 
that any input addresses used for device accesses to OS-visible memory 
do not overlap with the reserved system memory address ranges.

BIOS may report each such reserved memory region through the RMRR
structures, along with the devices that requires access to the 
specified reserved memory region. Reserved memory ranges that are
either not DMA targets, or memory ranges that may be target of BIOS
initiated DMA only during pre-boot phase (such as from a boot disk
drive) must not be included in the reserved memory region reporting.
The base address of each RMRR region must be 4KB aligned and the size
must be an integer multiple of 4KB. If there are no RMRR structures,
the system software concludes that the platform does not have any 
reserved memory ranges that are DMA targets.

Platform designers should avoid or limit use of reserved memory regions
since these require system software to create holes in the DMA virtual
address range available to system software and its drivers.
----

Below is one example from a BDW machine:
(XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ab80a000 end_address 
ab81dfff
(XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ad000000 end_address 
af7fffff

Here the 1st reserved region is for USB controller, with the 2nd one
belonging to IGD.



2. RMRR status in Xen
=====================================================================

There are two main design goals according to VT-d spec:

a) Setup identity mapping for reserved regions in IOMMU page table
b) Ensure reserved regions not conflicting with OS-visible memory
(OS-visible memory in a VM means guest physical memory, and more
strictly it also means no confliction with other types of allocations
in guest physical address space, such as PCI MMIO, ACPI, etc.)

However current RMRR implementation in Xen only partially achieves a)
and completely misses b), which cause some issues:

--
[Issue-1] Identity mapping is not setup in shared ept case, so a device
with RMRR may not function correctly if assigned to a VM. 

This was the original problem we found when assigning IGD on BDW 
platform, which triggered the whole long discussion in past months

--
[Issue-2] Being lacking of goal-b), existing device assignment with 
RMRR works only when reserved regions happen to not conflicting with
other valid allocations in the guest physical address space. This could
lead to unpredicted failures in various deployments, due to non-detected
conflictions caused by platform difference and VM configuration 
difference.

One example is about USB controller assignment. It's already identified
as a problem on some platforms, that USB reserved regions conflict with
guest BIOS region. However, being the fact that host BIOS only touches 
those reserved regions for legacy keyboard emulation at early Dom0 boot 
phase, a trick is added in Xen to bypass RMRR handling for usb 
controllers. 

--
[Issue-3] devices may share same reserved regions, however
there is no logic to handle this in Xen. Assigning such devices to 
different VMs could lead to secure concern



3. High Level Design
=====================================================================

To achieve aforementioned two goals, major enhancements are required 
cross Xen hypervisor, libxc, and hvmloader, to address the gap in
goal-b), i.e. handling possible conflictions in gfn space. Fixing
goal-a) is straightforward. 

>>>3.1 Guidelines
----
There are several guidelines considered in the design:

--
[Guideline-1] No regression in a VM w/o statically-assigned devices

  If a VM isn't configured with assigned devices at creation, new 
confliction detection logic shouldn't block the VM boot progress 
(either skipped, or just throw warning)

--
[Guideline-2] No regression on devices which do not have RMRR reported

  If a VM is assigned with a device which doesn't have RMRR reported,
either statically-assigned or dynamically-assigned, new confliction
detection logic shouldn't fail the assignment request for this device.

--
[Guideline-3] New interface should be kept as common as possible

  New interface will be introduced to expose reserved regions to the
user space. Though RMRR is a VT-d specific terminology, the interface
design should be generic enough, i.e. to support a function which 
allows hypervisor to force reserving one or more gfn ranges. 

--
[Guideline-4] Keep changes simple

  RMRR reserved regions should be avoided or limited by platform 
designers, per VT-d specification. Per our observations, there are
only a few reported examples (USB, IGD) on real platforms. So we need
to balance the code complexity and usage limitation. If one limitation
is only in niche scenarios, we'd like to vote no-support to simplify
changes for now.

>>>3.2 Confliction detection
----
Confliction must be detected in several places as far as gfn is 
concerned (how to handle confliction is discussed in 3.3)

1) libxc domain builder
  Here coarse-grained gfn layout is created, including two contiguous
guest RAM trunks (lowmem and/or highmem) and mmio holes (VGA, PCI),
which are passed to hvmloader for later fine-grained manipulation. Guest 
RAM trunks are populated with valid translation setup in underlying p2m 
layer. Device reserved regions must be detected in that layout.

2) Xen hypervisor device assignment
  Device assignment can happen either at VM creation time (after domain 
builder), or anytime thru hotplug after VM is booted. Regardless of 
how userspace handles confliction, Xen hypervisor will always do the 
last-conservative detection when setting up identity mapping:
	* gfn space unoccupied:
		-> insert identity mapping; no confliction
	* gfn space already occupied with identity mapping:
		-> do nothing; no confliction
	* gfn space already occupied with other mapping:
		-> confliction detected

3) hvmloader
  Hvmloader allocates other resources (ACPI, PCI MMIO, etc.) and 
internal data structures in gfn space, and it creates the final guest 
e820. So hvmloader also needs to detect conflictions when conducting 
those operations. If there's no confliction, hvmloader will reserve 
those regions in guest e820 to let guest OS aware.

>>>3.3 Policies
----
An intuitive thought is to fail immediately upon a confliction, however 
it is not flexible regarding to different requirments:

a) it's not appropriate to fail libxc domain builder just because such
confliction. We still want the guest to boot even w/o assigned device;

b) whether to fail in hvmloader has several dependencies. If it's
to check for hotplug preparation, warning is also an acceptable option
since assignment may not happen at all. Or if it's a USB controller 
but user doesn't care about legacy keyboard emulation, it's also OK to 
move forward upon a confliction;

c) in Xen hypervisor it is reasonable to fail upon confliction, where
device is actually assigned. But due to the same requirement on USB
controller, sometimes we might want it succeed just w/ warnings.

Regarding to the complexity of addressing all above flexibilities (user
preferences, per-device), which requires inventing quite some parameters
passed among different components, and regarding to the fact that 
failures would be rare (except some USB) with proactive avoidance  
in userspace, we'd like to propose below simplified policy following 
[Guideline-4]:

- 'warn' conflictions in user space (libxc and hvmloader)
- a boot option to specify 'fail' or 'warn' confliction in Xen device
assignment path, default to 'fail' (user can set to 'warn' for USB case)

Such policy provides a relaxed user space policy w/ hypervisor to do 
final judge. It has a unique merit to simplify later interface design 
and hotplug support, w/o breaking [Guideline-1/2] even when all possible 
reserved regions are exposed.

    ******agreement is first required on above policy******

>>>3.4 Xen: setup RMRR identity mapping
----
Regardless of whether userspace has detected confliction, Xen hypervisor
always needs to detect confliction itself when setting up identify 
mapping for reserved gfn regions, following above defined policy. 

Identity mapping should be really handled from the general p2m layer, 
so the same r/w permissions apply equally to CPU/DMA access paths,
regardless of the underlying fact whether EPT is shared with IOMMU.

This is to match the behavior on bare metal, where although reserved
regions are marked as E820_RESERVED, it's just a hint to the system 
software which can still read data back because physically those bits
do exist. So in the virtualization case we don't need to specially
treat CPU accesses to RMRR reserved regions (similar to other reserved
regions like ACPI NVS)

>>>3.5 New interface: expose reserved region information
----
As explained in [Guideline-3], we'd like to keep this interface general 
enough, as a common interface for hypervisor to force reserving gfn 
ranges, due to various reasons (RMRR is a client of this feature).

One design open was discussed back-and-forth accordingly, regarding to
whether the interface should return regions reported for all devices
in the platform (report-all), or selectively return regions only 
belonging to assigned devices (report-sel). report-sel can be built on
top of report-all, with extra work to help hypervisor generate filtered 
regions (e.g. introduce new interface or make device assignment happened 
before domain builder)

We propose report-all as the simple solution (different from last sent
version which used report-sel), regarding to the below facts:

  - 'warn' policy in user space makes report-all not harmful
  - 'report-all' still means only a few entries in reality:
    * RMRR reserved regions should be avoided or limited by platform
designers, per VT-d specification;
    * RMRR reserved regions are only a few on real platforms, per our
current observations;
  - anyway OS needs to handle all the reserved regions on bare metal;
  - hotplug friendly;
  - report-all can be extended to report-sel if really required

In this way, there are two situations libxc domain builder may request 
to query reserved region information w/ same interface:

a) if any statically-assigned devices, and/or
b) if a new parameter is specified, asking for hotplug preparation
	('rdm_check' or 'prepare_hotplug'?)

the 1st invocation of this interface will save all reported reserved
regions under domain structure, and later invocation (e.g. from 
hvmloader) gets saved content.

If a VM is configured w/o assigned devices, this interface is not 
invoked so there's no impact and [Guideline-1] is enforced;

If a VM is configured w/ assigned devices which don't have reserved
regions, this interface is invoked. In some cases warning may be 
thrown out due to confliction caused by other non-assigned devices, 
but it's just informational and there is no impact on assigned devices
so [Guideline-2] is enforced;

>>>3.6 Libxc/hvmloader: detect and avoid conflictions
----
libxc needs to detect reserved region conflictions with:
	- guest RAM
	- monolithic PCI MMIO hole

hvmloader needs to detect reserved region confliction with:
	- guest RAM
	- PCI MMIO allocation
	- memory allocation
	- some e820 entries like ACPI Opregion, etc.

When there's a confliction detected, libxc/hvmloader first try to
relocate conflicting gfn resources to avoid confliction. warning
will be thrown out when such relocation fails. The relocation policy 
is straightforward for most resources, however there remains a major 
design tradeoff for guest RAM, regarding to handoff between libxc 
and hvmloader...

In current implementation, guest RAM is contiguous in gfn space, w/
at most two trunks: lowmem (<4G) and highmem(>4G), which are passed
to hvmloader through hvm_info. Now by relocating guest RAM to avoid
confliction with reserved regions, sparse memory trunks are created
and it's not thought as an extensible way to introduce such sparse
structure into hvm_info.

There are several other options discussed so far:

a) Duplicate same relocation algorithm within libxc domain builder 
(when populating physmap) and hvmloader (when creating e820)
  - Pros:
	* no interface/structure change
	* anyway hvmloader still needs to handle reserved regions
  - Cons:
	* duplication is not good

b) pass sparse information through Xenstore
  (no much idea. need input from toolstack maintainers)

c) utilize XENMEM_{set,}_memory_map pair of hypercalls, with libxc to
set and hvmloader to get. Extension required to allow hvm invoke.
  - Pros:
	* centralized ownership in libxc. flexible for extension
  - Cons:
	* limiting entry to E820MAX (should be fine)
	* hvmloader e820 construction may become more complex, given
two predefined tables (reserved_regions, memory_map)

********Inputs are required to find a good option here*********

>>>3.7 hvmloader: reserve 'reserved regions' in guest E820
----
If there is no confliction detected, hvmloader needs to mark those
reserved regions as E820_RESERVED in guest E820 table, so the guest OS
is aware of those reserved regions (thus not does problematic actions
e.g. when re-allocating PCI MMIO)

>>>3.8 Xen: Handle devices sharing reserved regions
----
Per VT-d spec, it's possible to have two devices sharing same reserved
region. Though we didn't see such example in reality, hypervisor needs
to detect and handle such scenario, otherwise vulnerability may exist
if two devices are assigned to different VMs (so a malicious VM may
program its assigned device to clobber the shared region to malform 
another VM's device)

Ideally all devices sharing reserved regions should be assigned to a
single VM. However achieving this goal can't be done sole in hypervisor
w/o reworking current device assignment interface. Assignment is managed
by toolstack, which requires exposing group sharing information to 
userspace and then extends toolstack to manage assignment in bundle.

Given the problem only in ideal space, we propose to not support such
scenario, i.e. having hypervisor to fail the assignment, if the target
device happens to share some reserved regions with another device,
following [Guideline-4] to keep things simple.



4. Plan
=====================================================================
We're seeking an incremental way to split above tasks into 2 stages, 
and in each stage we move forward a step w/o causing regression. Doing
so can benefit people who want to use device assignment early, and 
also benefit newbie developer to rampup, toward a final sane solution.

4.1 Stage-1: hypervisor hardening
----
  [Tasks]
	1) Setup RMRR identity mapping in p2m layer with confliction 
detection
	2) add a boot option for fail/warn policy
	3) remove USB hack
	4) Detect and fail device assignment w/ shared reserve regions 

  [Enhancements]
	* fix [Issue-1] and [Issue-3]
	* partially fix [Issue-2] with limitations:
		- w/o userspace relocation there's larger chance to 
see conflictions. 
		- w/o reserve in guest e820, guest OS may allocate 
reserved pfn when re-enumerating PCI resource

  [Regressions]
	* devices which can be assigned successfully before may be
failed now due to confliction detection. However it's not a regression
per se. and user can change policy to 'warn' if required.  

4.2 Stage-2: libxc/hvmloader hardening
----
  [Tasks]
	5) Introduce new interface to expose reserve region information
	6) Detect and avoid reserved region conflictions in libxc
	7) Pass libxc guest RAM layout to hvmloader
	8) Detect and avoid reserved region conflictions in hvmloader
	9) Reserve 'reserved regions' in guest E820 in hvmloader

  [Enhancements]
	* completely fix [Issue-2]

  [Regression]
	* n/a

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 Dec 26 11:23:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 11:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4SzC-0003HA-1E; Fri, 26 Dec 2014 11:23:14 +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 1Y4SzA-0003H5-CJ
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 11:23:12 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	DB/CF-09842-F154D945; Fri, 26 Dec 2014 11:23:11 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1419592989!10610670!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32152 invoked from network); 26 Dec 2014 11:23:09 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-13.tower-21.messagelabs.com with SMTP;
	26 Dec 2014 11:23:09 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 26 Dec 2014 03:19:09 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="433631362"
Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96])
	by FMSMGA003.fm.intel.com with ESMTP; 26 Dec 2014 03:11:24 -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; Fri, 26 Dec 2014 19:23:04 +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; Fri, 26 Dec 2014 19:23:02 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Chen, Tiejun" <tiejun.chen@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>, "wei.liu2@citrix.com"
	<wei.liu2@citrix.com>, "ian.jackson@eu.citrix.com"
	<ian.jackson@eu.citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad.wilk@oracle.com"
	<konrad.wilk@oracle.com>, "tim@xen.org" <tim@xen.org>
Thread-Topic: (v2) Design proposal for RMRR fix
Thread-Index: AdAg/SjfP/+i9nFZSZuB9vPJZrXwHA==
Date: Fri, 26 Dec 2014 11:23:02 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D126126D66@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] (v2) Design proposal for RMRR fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(please note some proposal is different from last sent version after more
discussions. But I tried to summarize previous discussions and explained why
we choose a different way. Sorry if I may miss some opens/conclusions
discussed in past months. Please help point it out which is very appreciated. :-)

----
TOC:
	1. What's RMRR
	2. RMRR status in Xen
	3. High Level Design
		3.1 Guidelines
		3.2 Confliction detection
		3.3 Policies
		3.4 Xen: setup RMRR identity mapping
		3.5 New interface: expose reserved region information
		3.6 Libxc/hvmloader: detect and avoid conflictions
		3.7 Hvmloader: reserve 'reserved regions' in guest E820
		3.8 Xen: Handle devices sharing reserved regions
	4. Plan
		4.1 Stage-1: hypervisor hardening
		4.2 Stage-2: libxc/hvmloader hardening
		
1. What's RMRR?
=====================================================================

RMRR is an acronym for Reserved Memory Region Reporting, expected to 
be used for legacy usages (such as USB, UMA Graphics, etc.) requiring
reserved memory.

(From vt-d spec)
----
Reserved system memory regions are typically allocated by BIOS at boot
time and reported to OS as reserved address ranges in the system memory
map. Requests to these reserved regions may either occur as a result of
operations performed by the system software driver (for example in the
case of DMA from unified memory access (UMA) graphics controllers to
graphics reserved memory) or may be initiated by non system software
(for example in case of DMA performed by a USB controller under BIOS
SMM control for legacy keyboard emulation). 

For proper functioning of these legacy reserved memory usages, when 
system software enables DMA remapping, the translation structures for 
the respective devices are expected to be set up to provide identity 
mapping for the specified reserved memory regions with read and write 
permissions. The system software is also responsible for ensuring 
that any input addresses used for device accesses to OS-visible memory 
do not overlap with the reserved system memory address ranges.

BIOS may report each such reserved memory region through the RMRR
structures, along with the devices that requires access to the 
specified reserved memory region. Reserved memory ranges that are
either not DMA targets, or memory ranges that may be target of BIOS
initiated DMA only during pre-boot phase (such as from a boot disk
drive) must not be included in the reserved memory region reporting.
The base address of each RMRR region must be 4KB aligned and the size
must be an integer multiple of 4KB. If there are no RMRR structures,
the system software concludes that the platform does not have any 
reserved memory ranges that are DMA targets.

Platform designers should avoid or limit use of reserved memory regions
since these require system software to create holes in the DMA virtual
address range available to system software and its drivers.
----

Below is one example from a BDW machine:
(XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ab80a000 end_address 
ab81dfff
(XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:679:   RMRR region: base_addr ad000000 end_address 
af7fffff

Here the 1st reserved region is for USB controller, with the 2nd one
belonging to IGD.



2. RMRR status in Xen
=====================================================================

There are two main design goals according to VT-d spec:

a) Setup identity mapping for reserved regions in IOMMU page table
b) Ensure reserved regions not conflicting with OS-visible memory
(OS-visible memory in a VM means guest physical memory, and more
strictly it also means no confliction with other types of allocations
in guest physical address space, such as PCI MMIO, ACPI, etc.)

However current RMRR implementation in Xen only partially achieves a)
and completely misses b), which cause some issues:

--
[Issue-1] Identity mapping is not setup in shared ept case, so a device
with RMRR may not function correctly if assigned to a VM. 

This was the original problem we found when assigning IGD on BDW 
platform, which triggered the whole long discussion in past months

--
[Issue-2] Being lacking of goal-b), existing device assignment with 
RMRR works only when reserved regions happen to not conflicting with
other valid allocations in the guest physical address space. This could
lead to unpredicted failures in various deployments, due to non-detected
conflictions caused by platform difference and VM configuration 
difference.

One example is about USB controller assignment. It's already identified
as a problem on some platforms, that USB reserved regions conflict with
guest BIOS region. However, being the fact that host BIOS only touches 
those reserved regions for legacy keyboard emulation at early Dom0 boot 
phase, a trick is added in Xen to bypass RMRR handling for usb 
controllers. 

--
[Issue-3] devices may share same reserved regions, however
there is no logic to handle this in Xen. Assigning such devices to 
different VMs could lead to secure concern



3. High Level Design
=====================================================================

To achieve aforementioned two goals, major enhancements are required 
cross Xen hypervisor, libxc, and hvmloader, to address the gap in
goal-b), i.e. handling possible conflictions in gfn space. Fixing
goal-a) is straightforward. 

>>>3.1 Guidelines
----
There are several guidelines considered in the design:

--
[Guideline-1] No regression in a VM w/o statically-assigned devices

  If a VM isn't configured with assigned devices at creation, new 
confliction detection logic shouldn't block the VM boot progress 
(either skipped, or just throw warning)

--
[Guideline-2] No regression on devices which do not have RMRR reported

  If a VM is assigned with a device which doesn't have RMRR reported,
either statically-assigned or dynamically-assigned, new confliction
detection logic shouldn't fail the assignment request for this device.

--
[Guideline-3] New interface should be kept as common as possible

  New interface will be introduced to expose reserved regions to the
user space. Though RMRR is a VT-d specific terminology, the interface
design should be generic enough, i.e. to support a function which 
allows hypervisor to force reserving one or more gfn ranges. 

--
[Guideline-4] Keep changes simple

  RMRR reserved regions should be avoided or limited by platform 
designers, per VT-d specification. Per our observations, there are
only a few reported examples (USB, IGD) on real platforms. So we need
to balance the code complexity and usage limitation. If one limitation
is only in niche scenarios, we'd like to vote no-support to simplify
changes for now.

>>>3.2 Confliction detection
----
Confliction must be detected in several places as far as gfn is 
concerned (how to handle confliction is discussed in 3.3)

1) libxc domain builder
  Here coarse-grained gfn layout is created, including two contiguous
guest RAM trunks (lowmem and/or highmem) and mmio holes (VGA, PCI),
which are passed to hvmloader for later fine-grained manipulation. Guest 
RAM trunks are populated with valid translation setup in underlying p2m 
layer. Device reserved regions must be detected in that layout.

2) Xen hypervisor device assignment
  Device assignment can happen either at VM creation time (after domain 
builder), or anytime thru hotplug after VM is booted. Regardless of 
how userspace handles confliction, Xen hypervisor will always do the 
last-conservative detection when setting up identity mapping:
	* gfn space unoccupied:
		-> insert identity mapping; no confliction
	* gfn space already occupied with identity mapping:
		-> do nothing; no confliction
	* gfn space already occupied with other mapping:
		-> confliction detected

3) hvmloader
  Hvmloader allocates other resources (ACPI, PCI MMIO, etc.) and 
internal data structures in gfn space, and it creates the final guest 
e820. So hvmloader also needs to detect conflictions when conducting 
those operations. If there's no confliction, hvmloader will reserve 
those regions in guest e820 to let guest OS aware.

>>>3.3 Policies
----
An intuitive thought is to fail immediately upon a confliction, however 
it is not flexible regarding to different requirments:

a) it's not appropriate to fail libxc domain builder just because such
confliction. We still want the guest to boot even w/o assigned device;

b) whether to fail in hvmloader has several dependencies. If it's
to check for hotplug preparation, warning is also an acceptable option
since assignment may not happen at all. Or if it's a USB controller 
but user doesn't care about legacy keyboard emulation, it's also OK to 
move forward upon a confliction;

c) in Xen hypervisor it is reasonable to fail upon confliction, where
device is actually assigned. But due to the same requirement on USB
controller, sometimes we might want it succeed just w/ warnings.

Regarding to the complexity of addressing all above flexibilities (user
preferences, per-device), which requires inventing quite some parameters
passed among different components, and regarding to the fact that 
failures would be rare (except some USB) with proactive avoidance  
in userspace, we'd like to propose below simplified policy following 
[Guideline-4]:

- 'warn' conflictions in user space (libxc and hvmloader)
- a boot option to specify 'fail' or 'warn' confliction in Xen device
assignment path, default to 'fail' (user can set to 'warn' for USB case)

Such policy provides a relaxed user space policy w/ hypervisor to do 
final judge. It has a unique merit to simplify later interface design 
and hotplug support, w/o breaking [Guideline-1/2] even when all possible 
reserved regions are exposed.

    ******agreement is first required on above policy******

>>>3.4 Xen: setup RMRR identity mapping
----
Regardless of whether userspace has detected confliction, Xen hypervisor
always needs to detect confliction itself when setting up identify 
mapping for reserved gfn regions, following above defined policy. 

Identity mapping should be really handled from the general p2m layer, 
so the same r/w permissions apply equally to CPU/DMA access paths,
regardless of the underlying fact whether EPT is shared with IOMMU.

This is to match the behavior on bare metal, where although reserved
regions are marked as E820_RESERVED, it's just a hint to the system 
software which can still read data back because physically those bits
do exist. So in the virtualization case we don't need to specially
treat CPU accesses to RMRR reserved regions (similar to other reserved
regions like ACPI NVS)

>>>3.5 New interface: expose reserved region information
----
As explained in [Guideline-3], we'd like to keep this interface general 
enough, as a common interface for hypervisor to force reserving gfn 
ranges, due to various reasons (RMRR is a client of this feature).

One design open was discussed back-and-forth accordingly, regarding to
whether the interface should return regions reported for all devices
in the platform (report-all), or selectively return regions only 
belonging to assigned devices (report-sel). report-sel can be built on
top of report-all, with extra work to help hypervisor generate filtered 
regions (e.g. introduce new interface or make device assignment happened 
before domain builder)

We propose report-all as the simple solution (different from last sent
version which used report-sel), regarding to the below facts:

  - 'warn' policy in user space makes report-all not harmful
  - 'report-all' still means only a few entries in reality:
    * RMRR reserved regions should be avoided or limited by platform
designers, per VT-d specification;
    * RMRR reserved regions are only a few on real platforms, per our
current observations;
  - anyway OS needs to handle all the reserved regions on bare metal;
  - hotplug friendly;
  - report-all can be extended to report-sel if really required

In this way, there are two situations libxc domain builder may request 
to query reserved region information w/ same interface:

a) if any statically-assigned devices, and/or
b) if a new parameter is specified, asking for hotplug preparation
	('rdm_check' or 'prepare_hotplug'?)

the 1st invocation of this interface will save all reported reserved
regions under domain structure, and later invocation (e.g. from 
hvmloader) gets saved content.

If a VM is configured w/o assigned devices, this interface is not 
invoked so there's no impact and [Guideline-1] is enforced;

If a VM is configured w/ assigned devices which don't have reserved
regions, this interface is invoked. In some cases warning may be 
thrown out due to confliction caused by other non-assigned devices, 
but it's just informational and there is no impact on assigned devices
so [Guideline-2] is enforced;

>>>3.6 Libxc/hvmloader: detect and avoid conflictions
----
libxc needs to detect reserved region conflictions with:
	- guest RAM
	- monolithic PCI MMIO hole

hvmloader needs to detect reserved region confliction with:
	- guest RAM
	- PCI MMIO allocation
	- memory allocation
	- some e820 entries like ACPI Opregion, etc.

When there's a confliction detected, libxc/hvmloader first try to
relocate conflicting gfn resources to avoid confliction. warning
will be thrown out when such relocation fails. The relocation policy 
is straightforward for most resources, however there remains a major 
design tradeoff for guest RAM, regarding to handoff between libxc 
and hvmloader...

In current implementation, guest RAM is contiguous in gfn space, w/
at most two trunks: lowmem (<4G) and highmem(>4G), which are passed
to hvmloader through hvm_info. Now by relocating guest RAM to avoid
confliction with reserved regions, sparse memory trunks are created
and it's not thought as an extensible way to introduce such sparse
structure into hvm_info.

There are several other options discussed so far:

a) Duplicate same relocation algorithm within libxc domain builder 
(when populating physmap) and hvmloader (when creating e820)
  - Pros:
	* no interface/structure change
	* anyway hvmloader still needs to handle reserved regions
  - Cons:
	* duplication is not good

b) pass sparse information through Xenstore
  (no much idea. need input from toolstack maintainers)

c) utilize XENMEM_{set,}_memory_map pair of hypercalls, with libxc to
set and hvmloader to get. Extension required to allow hvm invoke.
  - Pros:
	* centralized ownership in libxc. flexible for extension
  - Cons:
	* limiting entry to E820MAX (should be fine)
	* hvmloader e820 construction may become more complex, given
two predefined tables (reserved_regions, memory_map)

********Inputs are required to find a good option here*********

>>>3.7 hvmloader: reserve 'reserved regions' in guest E820
----
If there is no confliction detected, hvmloader needs to mark those
reserved regions as E820_RESERVED in guest E820 table, so the guest OS
is aware of those reserved regions (thus not does problematic actions
e.g. when re-allocating PCI MMIO)

>>>3.8 Xen: Handle devices sharing reserved regions
----
Per VT-d spec, it's possible to have two devices sharing same reserved
region. Though we didn't see such example in reality, hypervisor needs
to detect and handle such scenario, otherwise vulnerability may exist
if two devices are assigned to different VMs (so a malicious VM may
program its assigned device to clobber the shared region to malform 
another VM's device)

Ideally all devices sharing reserved regions should be assigned to a
single VM. However achieving this goal can't be done sole in hypervisor
w/o reworking current device assignment interface. Assignment is managed
by toolstack, which requires exposing group sharing information to 
userspace and then extends toolstack to manage assignment in bundle.

Given the problem only in ideal space, we propose to not support such
scenario, i.e. having hypervisor to fail the assignment, if the target
device happens to share some reserved regions with another device,
following [Guideline-4] to keep things simple.



4. Plan
=====================================================================
We're seeking an incremental way to split above tasks into 2 stages, 
and in each stage we move forward a step w/o causing regression. Doing
so can benefit people who want to use device assignment early, and 
also benefit newbie developer to rampup, toward a final sane solution.

4.1 Stage-1: hypervisor hardening
----
  [Tasks]
	1) Setup RMRR identity mapping in p2m layer with confliction 
detection
	2) add a boot option for fail/warn policy
	3) remove USB hack
	4) Detect and fail device assignment w/ shared reserve regions 

  [Enhancements]
	* fix [Issue-1] and [Issue-3]
	* partially fix [Issue-2] with limitations:
		- w/o userspace relocation there's larger chance to 
see conflictions. 
		- w/o reserve in guest e820, guest OS may allocate 
reserved pfn when re-enumerating PCI resource

  [Regressions]
	* devices which can be assigned successfully before may be
failed now due to confliction detection. However it's not a regression
per se. and user can change policy to 'warn' if required.  

4.2 Stage-2: libxc/hvmloader hardening
----
  [Tasks]
	5) Introduce new interface to expose reserve region information
	6) Detect and avoid reserved region conflictions in libxc
	7) Pass libxc guest RAM layout to hvmloader
	8) Detect and avoid reserved region conflictions in hvmloader
	9) Reserve 'reserved regions' in guest E820 in hvmloader

  [Enhancements]
	* completely fix [Issue-2]

  [Regression]
	* n/a

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 Dec 26 12:20:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 12:20:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4Tsi-0004Ha-DG; Fri, 26 Dec 2014 12:20: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 1Y4Tsg-0004HV-MA
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 12:20:34 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	57/B8-02696-1925D945; Fri, 26 Dec 2014 12:20:33 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1419596432!17300008!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16315 invoked from network); 26 Dec 2014 12:20:32 -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; 26 Dec 2014 12:20:32 -0000
Received: from 195-240-154-44.ip.telfort.nl ([195.240.154.44]:49584
	helo=w510-eikit.fritz.box)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Y4TsG-0004EV-Oe; Fri, 26 Dec 2014 13:20:09 +0100
Date: Fri, 26 Dec 2014 13:20:26 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1796025636.20141226132026@eikelenboom.it>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <549985D4.1040509@citrix.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
	<20141216204900.GB11551@konrad-lan.dumpdata.com>
	<54944210.6050402@citrix.com>
	<20141219181447.GB7162@laptop.dumpdata.com>
	<549985D4.1040509@citrix.com>
MIME-Version: 1.0
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, December 23, 2014, 4:10:12 PM, you wrote:


> On 19/12/2014 18:14, Konrad Rzeszutek Wilk wrote:
>> On Fri, Dec 19, 2014 at 03:19:44PM +0000, Andrew Cooper wrote:
>>>
>>> There will be another full nightly test happening tonight (based on c/s
>>> 7e88c23 "libxl: Tell qemu to use raw format when using a tapdisk"), and
>>> some stress and scale tests if time allows.
>> Yeey! thank you for getting to this!

> Results are in from the latest nighties, and looking good.  No 
> identifiable differences between Xen 4.4 and 4.5

> There are also no identified differences in the scale and performance tests.

> ~Andrew

Hi Andrew,

Was this from a debug=y or debug=n build for both versions ?

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 26 12:20:59 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 12:20:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4Tsi-0004Ha-DG; Fri, 26 Dec 2014 12:20: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 1Y4Tsg-0004HV-MA
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 12:20:34 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	57/B8-02696-1925D945; Fri, 26 Dec 2014 12:20:33 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1419596432!17300008!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16315 invoked from network); 26 Dec 2014 12:20:32 -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; 26 Dec 2014 12:20:32 -0000
Received: from 195-240-154-44.ip.telfort.nl ([195.240.154.44]:49584
	helo=w510-eikit.fritz.box)
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128)
	(Exim 4.80) (envelope-from <linux@eikelenboom.it>)
	id 1Y4TsG-0004EV-Oe; Fri, 26 Dec 2014 13:20:09 +0100
Date: Fri, 26 Dec 2014 13:20:26 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1796025636.20141226132026@eikelenboom.it>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <549985D4.1040509@citrix.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
	<20141216204900.GB11551@konrad-lan.dumpdata.com>
	<54944210.6050402@citrix.com>
	<20141219181447.GB7162@laptop.dumpdata.com>
	<549985D4.1040509@citrix.com>
MIME-Version: 1.0
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, December 23, 2014, 4:10:12 PM, you wrote:


> On 19/12/2014 18:14, Konrad Rzeszutek Wilk wrote:
>> On Fri, Dec 19, 2014 at 03:19:44PM +0000, Andrew Cooper wrote:
>>>
>>> There will be another full nightly test happening tonight (based on c/s
>>> 7e88c23 "libxl: Tell qemu to use raw format when using a tapdisk"), and
>>> some stress and scale tests if time allows.
>> Yeey! thank you for getting to this!

> Results are in from the latest nighties, and looking good.  No 
> identifiable differences between Xen 4.4 and 4.5

> There are also no identified differences in the scale and performance tests.

> ~Andrew

Hi Andrew,

Was this from a debug=y or debug=n build for both versions ?

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 26 13:35:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 13:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4V2V-0005bY-9p; Fri, 26 Dec 2014 13:34:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1Y4V2U-0005bT-C9
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 13:34:46 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	00/75-23865-5F36D945; Fri, 26 Dec 2014 13:34:45 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419600884!15873679!1
X-Originating-IP: [131.111.8.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16984 invoked from network); 26 Dec 2014 13:34:45 -0000
Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk)
	(131.111.8.151)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Dec 2014 13:34:45 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from host86-133-76-85.range86-133.btcentralplus.com
	([86.133.76.85]:49536 helo=[192.168.1.98])
	by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1.2:DHE-RSA-AES128-SHA:128)
	id 1Y4V2Q-0001aD-ZQ (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Fri, 26 Dec 2014 13:34:44 +0000
Message-ID: <549D63CF.3000202@citrix.com>
Date: Fri, 26 Dec 2014 13:34:07 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
	<20141216204900.GB11551@konrad-lan.dumpdata.com>
	<54944210.6050402@citrix.com>
	<20141219181447.GB7162@laptop.dumpdata.com>
	<549985D4.1040509@citrix.com>
	<1796025636.20141226132026@eikelenboom.it>
In-Reply-To: <1796025636.20141226132026@eikelenboom.it>
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/2014 12:20, Sander Eikelenboom wrote:
> Tuesday, December 23, 2014, 4:10:12 PM, you wrote:
>
>
>> On 19/12/2014 18:14, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Dec 19, 2014 at 03:19:44PM +0000, Andrew Cooper wrote:
>>>> There will be another full nightly test happening tonight (based on c/s
>>>> 7e88c23 "libxl: Tell qemu to use raw format when using a tapdisk"), and
>>>> some stress and scale tests if time allows.
>>> Yeey! thank you for getting to this!
>> Results are in from the latest nighties, and looking good.  No
>> identifiable differences between Xen 4.4 and 4.5
>> There are also no identified differences in the scale and performance tests.
>> ~Andrew
> Hi Andrew,
>
> Was this from a debug=y or debug=n build for both versions ?

Both for both sets of tests.  XenServer, as of 6.5, contains both a 
debug and non-debug hypervisor, built from identical source.

In trunk, the debug hypervisor is used by default.  Tests such as 
performance tests explicitly switch to the non-debug hypervisor as part 
of their setup.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 26 13:35:19 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 13:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4V2V-0005bY-9p; Fri, 26 Dec 2014 13:34:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amc96@hermes.cam.ac.uk>) id 1Y4V2U-0005bT-C9
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 13:34:46 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	00/75-23865-5F36D945; Fri, 26 Dec 2014 13:34:45 +0000
X-Env-Sender: amc96@hermes.cam.ac.uk
X-Msg-Ref: server-2.tower-31.messagelabs.com!1419600884!15873679!1
X-Originating-IP: [131.111.8.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16984 invoked from network); 26 Dec 2014 13:34:45 -0000
Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk)
	(131.111.8.151)
	by server-2.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Dec 2014 13:34:45 -0000
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from host86-133-76-85.range86-133.btcentralplus.com
	([86.133.76.85]:49536 helo=[192.168.1.98])
	by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587)
	with esmtpsa (PLAIN:amc96) (TLSv1.2:DHE-RSA-AES128-SHA:128)
	id 1Y4V2Q-0001aD-ZQ (Exim 4.82_3-c0e5623)
	(return-path <amc96@hermes.cam.ac.uk>); Fri, 26 Dec 2014 13:34:44 +0000
Message-ID: <549D63CF.3000202@citrix.com>
Date: Fri, 26 Dec 2014 13:34:07 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
	<20141216204900.GB11551@konrad-lan.dumpdata.com>
	<54944210.6050402@citrix.com>
	<20141219181447.GB7162@laptop.dumpdata.com>
	<549985D4.1040509@citrix.com>
	<1796025636.20141226132026@eikelenboom.it>
In-Reply-To: <1796025636.20141226132026@eikelenboom.it>
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/12/2014 12:20, Sander Eikelenboom wrote:
> Tuesday, December 23, 2014, 4:10:12 PM, you wrote:
>
>
>> On 19/12/2014 18:14, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Dec 19, 2014 at 03:19:44PM +0000, Andrew Cooper wrote:
>>>> There will be another full nightly test happening tonight (based on c/s
>>>> 7e88c23 "libxl: Tell qemu to use raw format when using a tapdisk"), and
>>>> some stress and scale tests if time allows.
>>> Yeey! thank you for getting to this!
>> Results are in from the latest nighties, and looking good.  No
>> identifiable differences between Xen 4.4 and 4.5
>> There are also no identified differences in the scale and performance tests.
>> ~Andrew
> Hi Andrew,
>
> Was this from a debug=y or debug=n build for both versions ?

Both for both sets of tests.  XenServer, as of 6.5, contains both a 
debug and non-debug hypervisor, built from identical source.

In trunk, the debug hypervisor is used by default.  Tests such as 
performance tests explicitly switch to the non-debug hypervisor as part 
of their setup.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 26 17:07:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 17: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 1Y4YLH-0001CG-UY; Fri, 26 Dec 2014 17:06: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 1Y4YLG-0001CB-7C
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 17:06:22 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	EB/E6-02957-D859D945; Fri, 26 Dec 2014 17:06:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419613579!12597522!1
X-Originating-IP: [66.165.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 1979 invoked from network); 26 Dec 2014 17:06:20 -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;
	26 Dec 2014 17:06:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,648,1413244800"; d="scan'208";a="208821671"
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.210.2; Fri, 26 Dec 2014 12:06:17 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y4YLA-0004jY-N6;
	Fri, 26 Dec 2014 17:06:16 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4YLA-0006xt-G0;
	Fri, 26 Dec 2014 17:06:16 +0000
Date: Fri, 26 Dec 2014 17:06:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32669-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] 32669: 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 32669 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32669/

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 32646

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-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-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-winxpsp3 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-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 Fri Dec 26 17:07:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 17: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 1Y4YLH-0001CG-UY; Fri, 26 Dec 2014 17:06: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 1Y4YLG-0001CB-7C
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 17:06:22 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	EB/E6-02957-D859D945; Fri, 26 Dec 2014 17:06:21 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419613579!12597522!1
X-Originating-IP: [66.165.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 1979 invoked from network); 26 Dec 2014 17:06:20 -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;
	26 Dec 2014 17:06:20 -0000
X-IronPort-AV: E=Sophos;i="5.07,648,1413244800"; d="scan'208";a="208821671"
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.210.2; Fri, 26 Dec 2014 12:06:17 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y4YLA-0004jY-N6;
	Fri, 26 Dec 2014 17:06:16 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4YLA-0006xt-G0;
	Fri, 26 Dec 2014 17:06:16 +0000
Date: Fri, 26 Dec 2014 17:06:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32669-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] 32669: 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 32669 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32669/

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 32646

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-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-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-winxpsp3 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-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 Fri Dec 26 17:38:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 17:38:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4Ypa-0001m7-Lz; Fri, 26 Dec 2014 17:37: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 1Y4YpZ-0001m2-7N
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 17:37:41 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	83/F3-11608-4EC9D945; Fri, 26 Dec 2014 17:37:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1419615458!15872353!1
X-Originating-IP: [66.165.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 26693 invoked from network); 26 Dec 2014 17:37:39 -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 Dec 2014 17:37:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,648,1413244800"; d="scan'208";a="208827351"
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.210.2; Fri, 26 Dec 2014 12:37:36 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y4YpU-0004sp-KH;
	Fri, 26 Dec 2014 17:37:36 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4YpU-0001dj-FL;
	Fri, 26 Dec 2014 17:37:36 +0000
Date: Fri, 26 Dec 2014 17:37:36 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32670-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] 32670: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32670 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32670/

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-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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                              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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 26 17:38:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 17:38:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4Ypa-0001m7-Lz; Fri, 26 Dec 2014 17:37: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 1Y4YpZ-0001m2-7N
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 17:37:41 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	83/F3-11608-4EC9D945; Fri, 26 Dec 2014 17:37:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1419615458!15872353!1
X-Originating-IP: [66.165.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 26693 invoked from network); 26 Dec 2014 17:37:39 -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 Dec 2014 17:37:39 -0000
X-IronPort-AV: E=Sophos;i="5.07,648,1413244800"; d="scan'208";a="208827351"
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.210.2; Fri, 26 Dec 2014 12:37:36 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y4YpU-0004sp-KH;
	Fri, 26 Dec 2014 17:37:36 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4YpU-0001dj-FL;
	Fri, 26 Dec 2014 17:37:36 +0000
Date: Fri, 26 Dec 2014 17:37:36 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32670-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] 32670: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32670 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32670/

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-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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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 14 guest-stop                fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                              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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 26 19:02:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 19: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 1Y4a9T-0003Kn-8c; Fri, 26 Dec 2014 19:02: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 1Y4a9R-0003Ki-Vn
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 19:02:18 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	11/68-02696-9B0BD945; Fri, 26 Dec 2014 19:02:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419620534!11864578!1
X-Originating-IP: [156.151.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 27382 invoked from network); 26 Dec 2014 19:02:16 -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; 26 Dec 2014 19:02:16 -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 sBQJ2CHV018706
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Dec 2014 19:02:12 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
	sBQJ2BIW008373
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 26 Dec 2014 19:02:11 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
	sBQJ2AiW007018; Fri, 26 Dec 2014 19:02:10 GMT
Received: from konrad-lan.dumpdata.com (/71.241.132.99)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 26 Dec 2014 11:02:10 -0800
Date: Fri, 26 Dec 2014 14:02:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141226190204.GA19679@konrad-lan.dumpdata.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31AAABA8@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31AAABA8@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>, "Wang,
	Wei W" <wei.w.wang@intel.com>, "Li, Liang Z" <liang.z.li@intel.com>, "Wang,
	Yong Y" <yong.y.wang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Testday]Xen 4.5 RC4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 25, 2014 at 02:58:06AM +0000, Hu, Robert wrote:
> Hi
> 
> This is test report on Xen 4.5 RC4, from Intel OTC VMM Team.

Thank you!
> 
> Platform: Grantley-EP, Ivytown-EP
> 
> We found these issue blow. Hoping corresponding patches can be committed in Xen 4.5 release.

Are they regressions?
> 
> Issue 1 -- detach a vt-d assigned device from guest, then reattach it to guest, will fail.
> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html
> 
> Issue 2 -- attach/detach vt-d devices (both physical and virtual fucntions) to domain, more than 1 time, will fail with errors
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg02016.html
> Note: this depends on issue 1. need to apply issue 1's patch to get it.
> 
> Issue 3 -- 1GB hugepage support on X86_64 with HVM guest requires hacks in the guest config
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02624.html

This one has been in existence for quite a while so it can go in Xen 4.6
> 
> 
> 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 Fri Dec 26 19:02:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 19: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 1Y4a9T-0003Kn-8c; Fri, 26 Dec 2014 19:02: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 1Y4a9R-0003Ki-Vn
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 19:02:18 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	11/68-02696-9B0BD945; Fri, 26 Dec 2014 19:02:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419620534!11864578!1
X-Originating-IP: [156.151.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 27382 invoked from network); 26 Dec 2014 19:02:16 -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; 26 Dec 2014 19:02:16 -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 sBQJ2CHV018706
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Dec 2014 19:02:12 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
	sBQJ2BIW008373
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 26 Dec 2014 19:02:11 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
	sBQJ2AiW007018; Fri, 26 Dec 2014 19:02:10 GMT
Received: from konrad-lan.dumpdata.com (/71.241.132.99)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 26 Dec 2014 11:02:10 -0800
Date: Fri, 26 Dec 2014 14:02:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Hu, Robert" <robert.hu@intel.com>
Message-ID: <20141226190204.GA19679@konrad-lan.dumpdata.com>
References: <9E79D1C9A97CFD4097BCE431828FDD31AAABA8@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9E79D1C9A97CFD4097BCE431828FDD31AAABA8@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>, "Wang,
	Wei W" <wei.w.wang@intel.com>, "Li, Liang Z" <liang.z.li@intel.com>, "Wang,
	Yong Y" <yong.y.wang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Testday]Xen 4.5 RC4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Dec 25, 2014 at 02:58:06AM +0000, Hu, Robert wrote:
> Hi
> 
> This is test report on Xen 4.5 RC4, from Intel OTC VMM Team.

Thank you!
> 
> Platform: Grantley-EP, Ivytown-EP
> 
> We found these issue blow. Hoping corresponding patches can be committed in Xen 4.5 release.

Are they regressions?
> 
> Issue 1 -- detach a vt-d assigned device from guest, then reattach it to guest, will fail.
> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html
> 
> Issue 2 -- attach/detach vt-d devices (both physical and virtual fucntions) to domain, more than 1 time, will fail with errors
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg02016.html
> Note: this depends on issue 1. need to apply issue 1's patch to get it.
> 
> Issue 3 -- 1GB hugepage support on X86_64 with HVM guest requires hacks in the guest config
> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02624.html

This one has been in existence for quite a while so it can go in Xen 4.6
> 
> 
> 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 Fri Dec 26 19:07:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 19:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4aEW-0003Sw-1E; Fri, 26 Dec 2014 19:07:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y4aEU-0003Sq-MQ
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 19:07:30 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	8B/E4-23865-1F1BD945; Fri, 26 Dec 2014 19:07:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419620847!15932462!1
X-Originating-IP: [156.151.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 9308 invoked from network); 26 Dec 2014 19:07:29 -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; 26 Dec 2014 19:07: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 sBQJ7OJo022533
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Dec 2014 19:07: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
	sBQJ7NAU015524
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 26 Dec 2014 19:07:24 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
	sBQJ7Njr015514; Fri, 26 Dec 2014 19:07:23 GMT
Received: from konrad-lan.dumpdata.com (/71.241.132.99)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 26 Dec 2014 11:07:23 -0800
Date: Fri, 26 Dec 2014 14:07:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141226190720.GC19679@konrad-lan.dumpdata.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
	<20141216204900.GB11551@konrad-lan.dumpdata.com>
	<54944210.6050402@citrix.com>
	<20141219181447.GB7162@laptop.dumpdata.com>
	<549985D4.1040509@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <549985D4.1040509@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] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 23, 2014 at 03:10:12PM +0000, Andrew Cooper wrote:
> 
> On 19/12/2014 18:14, Konrad Rzeszutek Wilk wrote:
> >On Fri, Dec 19, 2014 at 03:19:44PM +0000, Andrew Cooper wrote:
> >>
> >>There will be another full nightly test happening tonight (based on c/s
> >>7e88c23 "libxl: Tell qemu to use raw format when using a tapdisk"), and
> >>some stress and scale tests if time allows.
> >Yeey! thank you for getting to this!
> 
> Results are in from the latest nighties, and looking good.  No identifiable
> differences between Xen 4.4 and 4.5

Yeey! Thank you for testing that.
> 
> There are also no identified differences in the scale and performance tests.

That is good and also .. a bit surprising. We did have features to take
advantage of huge boxes. Are these tests mostly the normal set of 'guest
workload'?
> 
> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 26 19:07:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 19:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4aEW-0003Sw-1E; Fri, 26 Dec 2014 19:07:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y4aEU-0003Sq-MQ
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 19:07:30 +0000
Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id
	8B/E4-23865-1F1BD945; Fri, 26 Dec 2014 19:07:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419620847!15932462!1
X-Originating-IP: [156.151.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 9308 invoked from network); 26 Dec 2014 19:07:29 -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; 26 Dec 2014 19:07: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 sBQJ7OJo022533
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Dec 2014 19:07: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
	sBQJ7NAU015524
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 26 Dec 2014 19:07:24 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
	sBQJ7Njr015514; Fri, 26 Dec 2014 19:07:23 GMT
Received: from konrad-lan.dumpdata.com (/71.241.132.99)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 26 Dec 2014 11:07:23 -0800
Date: Fri, 26 Dec 2014 14:07:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141226190720.GC19679@konrad-lan.dumpdata.com>
References: <20141216161352.504FA124EF2@laptop.dumpdata.com>
	<54906F2C.8030800@citrix.com>
	<20141216204900.GB11551@konrad-lan.dumpdata.com>
	<54944210.6050402@citrix.com>
	<20141219181447.GB7162@laptop.dumpdata.com>
	<549985D4.1040509@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <549985D4.1040509@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] Xen 4.5 Development Update (RC4)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Dec 23, 2014 at 03:10:12PM +0000, Andrew Cooper wrote:
> 
> On 19/12/2014 18:14, Konrad Rzeszutek Wilk wrote:
> >On Fri, Dec 19, 2014 at 03:19:44PM +0000, Andrew Cooper wrote:
> >>
> >>There will be another full nightly test happening tonight (based on c/s
> >>7e88c23 "libxl: Tell qemu to use raw format when using a tapdisk"), and
> >>some stress and scale tests if time allows.
> >Yeey! thank you for getting to this!
> 
> Results are in from the latest nighties, and looking good.  No identifiable
> differences between Xen 4.4 and 4.5

Yeey! Thank you for testing that.
> 
> There are also no identified differences in the scale and performance tests.

That is good and also .. a bit surprising. We did have features to take
advantage of huge boxes. Are these tests mostly the normal set of 'guest
workload'?
> 
> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Dec 26 20:12:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 20: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 1Y4bEf-0004aF-El; Fri, 26 Dec 2014 20:11: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 1Y4bEe-0004a8-NB
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 20:11:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F4/B7-15461-FF0CD945; Fri, 26 Dec 2014 20:11:43 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1419624701!17991809!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13768 invoked from network); 26 Dec 2014 20:11:43 -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; 26 Dec 2014 20:11: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 sBQKBcUV018928
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Dec 2014 20:11:39 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
	sBQKBbYp014250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 26 Dec 2014 20:11:38 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
	sBQKBbtT014242; Fri, 26 Dec 2014 20:11: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, 26 Dec 2014 12:11:37 -0800
Message-ID: <549DC184.80602@oracle.com>
Date: Fri, 26 Dec 2014 15:13:56 -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>
References: <9E79D1C9A97CFD4097BCE431828FDD31AAABA8@SHSMSX103.ccr.corp.intel.com>
	<20141226190204.GA19679@konrad-lan.dumpdata.com>
In-Reply-To: <20141226190204.GA19679@konrad-lan.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Wang, Wei W" <wei.w.wang@intel.com>, "Li, Liang Z" <liang.z.li@intel.com>,
	"Wang, Yong Y" <yong.y.wang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Testday]Xen 4.5 RC4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/26/2014 02:02 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 25, 2014 at 02:58:06AM +0000, Hu, Robert wrote:
>> Hi
>>
>> This is test report on Xen 4.5 RC4, from Intel OTC VMM Team.
> Thank you!
>> Platform: Grantley-EP, Ivytown-EP
>>
>> We found these issue blow. Hoping corresponding patches can be committed in Xen 4.5 release.
> Are they regressions?
>> Issue 1 -- detach a vt-d assigned device from guest, then reattach it to guest, will fail.
>> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html


This is regression introduced by abfb006f.


-boris


>>
>> Issue 2 -- attach/detach vt-d devices (both physical and virtual fucntions) to domain, more than 1 time, will fail with errors
>> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg02016.html
>> Note: this depends on issue 1. need to apply issue 1's patch to get it.
>>
>> Issue 3 -- 1GB hugepage support on X86_64 with HVM guest requires hacks in the guest config
>> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02624.html
> This one has been in existence for quite a while so it can go in Xen 4.6
>>
>> 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 Fri Dec 26 20:12:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 20: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 1Y4bEf-0004aF-El; Fri, 26 Dec 2014 20:11: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 1Y4bEe-0004a8-NB
	for xen-devel@lists.xen.org; Fri, 26 Dec 2014 20:11:44 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	F4/B7-15461-FF0CD945; Fri, 26 Dec 2014 20:11:43 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1419624701!17991809!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13768 invoked from network); 26 Dec 2014 20:11:43 -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; 26 Dec 2014 20:11: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 sBQKBcUV018928
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Dec 2014 20:11:39 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
	sBQKBbYp014250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 26 Dec 2014 20:11:38 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
	sBQKBbtT014242; Fri, 26 Dec 2014 20:11: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, 26 Dec 2014 12:11:37 -0800
Message-ID: <549DC184.80602@oracle.com>
Date: Fri, 26 Dec 2014 15:13:56 -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>
References: <9E79D1C9A97CFD4097BCE431828FDD31AAABA8@SHSMSX103.ccr.corp.intel.com>
	<20141226190204.GA19679@konrad-lan.dumpdata.com>
In-Reply-To: <20141226190204.GA19679@konrad-lan.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Wang, Wei W" <wei.w.wang@intel.com>, "Li, Liang Z" <liang.z.li@intel.com>,
	"Wang, Yong Y" <yong.y.wang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Testday]Xen 4.5 RC4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/26/2014 02:02 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 25, 2014 at 02:58:06AM +0000, Hu, Robert wrote:
>> Hi
>>
>> This is test report on Xen 4.5 RC4, from Intel OTC VMM Team.
> Thank you!
>> Platform: Grantley-EP, Ivytown-EP
>>
>> We found these issue blow. Hoping corresponding patches can be committed in Xen 4.5 release.
> Are they regressions?
>> Issue 1 -- detach a vt-d assigned device from guest, then reattach it to guest, will fail.
>> http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html


This is regression introduced by abfb006f.


-boris


>>
>> Issue 2 -- attach/detach vt-d devices (both physical and virtual fucntions) to domain, more than 1 time, will fail with errors
>> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg02016.html
>> Note: this depends on issue 1. need to apply issue 1's patch to get it.
>>
>> Issue 3 -- 1GB hugepage support on X86_64 with HVM guest requires hacks in the guest config
>> http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02624.html
> This one has been in existence for quite a while so it can go in Xen 4.6
>>
>> 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 Fri Dec 26 21:51:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 21: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 1Y4cmn-0006Ft-56; Fri, 26 Dec 2014 21:51:05 +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 1Y4cml-0006Fn-F6
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 21:51:03 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	0D/21-02702-648DD945; Fri, 26 Dec 2014 21:51:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1419630660!17311035!1
X-Originating-IP: [66.165.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 17762 invoked from network); 26 Dec 2014 21:51:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2014 21:51:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,649,1413244800"; d="scan'208";a="208339074"
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.210.2; Fri, 26 Dec 2014 16:50: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 1Y4cmH-00065S-WD;
	Fri, 26 Dec 2014 21:50:34 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4cmH-0008Aa-Qr;
	Fri, 26 Dec 2014 21:50:33 +0000
Date: Fri, 26 Dec 2014 21:50:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32674-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 14301
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 32674: 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="===============2529871812314100914=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2529871812314100914==
Content-Type: text/plain
Content-Length: 14119
Content-Transfer-Encoding: quoted-printable

flight 32674 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32674/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32647
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32647
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32647
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32647

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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-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                08b022a9655bf925e6683422590306429b752ccd
baseline version:
 linux                53262d12d1658669029ab39a63e3d314108abe66

------------------------------------------------------------
People who touched revisions under test:
  Alexei Starovoitov <ast@plumgrid.com>
  Alexey Skidanov <Alexey.Skidanov@amd.com>
  Chris Wilson <chris@chris-wilson.co.uk>
  Corey Minyard <cminyard@mvista.com>
  Daniel Vetter <daniel.vetter@ffwll.ch>
  Dave Airlie <airlied@redhat.com>
  Dave Jones <davej@redhat.com>
  Eric Paris <eparis@redhat.com>
  Imre Deak <imre.deak@intel.com>
  Jani Nikula <jani.nikula@intel.com>
  Jilai Wang <jilaiw@codeaurora.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Markus Elfring <elfring@users.sourceforge.net>
  Oded Gabbay <oded.gabbay@amd.com>
  Paul Moore <pmoore@redhat.com>
  Peter Fr=C3=BChberger <fritsch@xbmc.org>
  Richard Guy Briggs <rgb@redhat.com>
  Rob Clark <robdclark@gmail.com>
  Sean Paul <seanpaul@chromium.org>
  Thierry Reding <treding@nvidia.com>
  Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
------------------------------------------------------------

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


Pushing revision :

+ branch=3Dlinux-linus
+ revision=3D08b022a9655bf925e6683422590306429b752ccd
+ . 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 linux-linus 08b022a9655bf925e6683422590306429b752ccd
+ branch=3Dlinux-linus
+ revision=3D08b022a9655bf925e6683422590306429b752ccd
+ . 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=3Dlinux
+ xenbranch=3Dxen-unstable
+ '[' xlinux =3D xlinux ']'
+ linuxbranch=3Dlinux-linus
+ '[' 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git =3D x ']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git =3D x ']'
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-linus
++ : 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-linus
+ 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 linux-linus
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ : master
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ : tested/linux-linus
+ : tested/linux-linus
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git 08b022a9655bf925e6683422590306429b752ccd:tested/linux-linus
Auto packing the repository for optimum performance.
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   53262d1..08b022a  08b022a9655bf925e6683422590306429b752ccd -> tested/linux-linus
+ exit 0


--===============2529871812314100914==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2529871812314100914==--

From xen-devel-bounces@lists.xen.org Fri Dec 26 21:51:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Dec 2014 21: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 1Y4cmn-0006Ft-56; Fri, 26 Dec 2014 21:51:05 +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 1Y4cml-0006Fn-F6
	for xen-devel@lists.xensource.com; Fri, 26 Dec 2014 21:51:03 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	0D/21-02702-648DD945; Fri, 26 Dec 2014 21:51:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1419630660!17311035!1
X-Originating-IP: [66.165.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 17762 invoked from network); 26 Dec 2014 21:51:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Dec 2014 21:51:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,649,1413244800"; d="scan'208";a="208339074"
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.210.2; Fri, 26 Dec 2014 16:50: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 1Y4cmH-00065S-WD;
	Fri, 26 Dec 2014 21:50:34 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4cmH-0008Aa-Qr;
	Fri, 26 Dec 2014 21:50:33 +0000
Date: Fri, 26 Dec 2014 21:50:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32674-mainreport@xen.org>
From: xen.org <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Length: 14301
X-DLP: MIA1
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 32674: 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="===============2529871812314100914=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2529871812314100914==
Content-Type: text/plain
Content-Length: 14119
Content-Transfer-Encoding: quoted-printable

flight 32674 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32674/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32647
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32647
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32647
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32647

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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-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                08b022a9655bf925e6683422590306429b752ccd
baseline version:
 linux                53262d12d1658669029ab39a63e3d314108abe66

------------------------------------------------------------
People who touched revisions under test:
  Alexei Starovoitov <ast@plumgrid.com>
  Alexey Skidanov <Alexey.Skidanov@amd.com>
  Chris Wilson <chris@chris-wilson.co.uk>
  Corey Minyard <cminyard@mvista.com>
  Daniel Vetter <daniel.vetter@ffwll.ch>
  Dave Airlie <airlied@redhat.com>
  Dave Jones <davej@redhat.com>
  Eric Paris <eparis@redhat.com>
  Imre Deak <imre.deak@intel.com>
  Jani Nikula <jani.nikula@intel.com>
  Jilai Wang <jilaiw@codeaurora.org>
  Linus Torvalds <torvalds@linux-foundation.org>
  Markus Elfring <elfring@users.sourceforge.net>
  Oded Gabbay <oded.gabbay@amd.com>
  Paul Moore <pmoore@redhat.com>
  Peter Fr=C3=BChberger <fritsch@xbmc.org>
  Richard Guy Briggs <rgb@redhat.com>
  Rob Clark <robdclark@gmail.com>
  Sean Paul <seanpaul@chromium.org>
  Thierry Reding <treding@nvidia.com>
  Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
------------------------------------------------------------

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


Pushing revision :

+ branch=3Dlinux-linus
+ revision=3D08b022a9655bf925e6683422590306429b752ccd
+ . 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 linux-linus 08b022a9655bf925e6683422590306429b752ccd
+ branch=3Dlinux-linus
+ revision=3D08b022a9655bf925e6683422590306429b752ccd
+ . 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=3Dlinux
+ xenbranch=3Dxen-unstable
+ '[' xlinux =3D xlinux ']'
+ linuxbranch=3Dlinux-linus
+ '[' 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git =3D x ']'
++ '[' xgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git =3D x ']'
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : daily-cron.linux-linus
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-linus
++ : 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-linus
+ 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 linux-linus
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ : master
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ : tested/linux-linus
+ : tested/linux-linus
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git 08b022a9655bf925e6683422590306429b752ccd:tested/linux-linus
Auto packing the repository for optimum performance.
To osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
   53262d1..08b022a  08b022a9655bf925e6683422590306429b752ccd -> tested/linux-linus
+ exit 0


--===============2529871812314100914==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2529871812314100914==--

From xen-devel-bounces@lists.xen.org Sat Dec 27 00:08:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 00:08:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4euv-00014l-HE; Sat, 27 Dec 2014 00:07:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y4euu-00014g-90
	for xen-devel@lists.xensource.com; Sat, 27 Dec 2014 00:07:36 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F7/EA-25276-748FD945; Sat, 27 Dec 2014 00:07:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419638853!17989179!1
X-Originating-IP: [66.165.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 29055 invoked from network); 27 Dec 2014 00:07:34 -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;
	27 Dec 2014 00:07:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,649,1413244800"; d="scan'208";a="208890156"
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.210.2; Fri, 26 Dec 2014 19:07: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 1Y4eup-0006kB-Ot;
	Sat, 27 Dec 2014 00:07:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4eup-0007hh-JZ;
	Sat, 27 Dec 2014 00:07:31 +0000
Date: Sat, 27 Dec 2014 00:07:31 +0000
Message-ID: <E1Y4eup-0007hh-JZ@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] [qemu-mainline bisection] complete
	test-amd64-i386-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-amd
test redhat-install

Tree: linux git://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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-i386-rhel6hvm-amd.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32659 fail [host=potato-beetle] / 32598 [host=lace-bug] 32585 ok.
Failure / basis pass flights: 32659 / 32585
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#83a926f7a4e39fb6be0576024e67fe161593defa-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#c95f3901b4ead79f3fe2c641fda7d2c70fc84c72-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 1005 nodes in revision graph
Searching for test results:
 32571 pass irrelevant
 32585 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32598 [host=lace-bug]
 32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32698 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32699 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32700 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32684 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32685 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32702 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32688 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c8e829b7bf6e1c84af8b4b13ee7fce2959c63e0e 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32703 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32690 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7eb1dc7f0b65a324323541440baf2ea544adcefb 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32696 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32697 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 32585 (pass), for basis pass
 Result found: flight 32611 (fail), for basis failure
 Repro found: flight 32684 (pass), for basis pass
 Repro found: flight 32685 (fail), for basis failure
 0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32696 (pass), for last pass
 Result found: flight 32698 (fail), for first failure
 Repro found: flight 32699 (pass), for last pass
 Repro found: flight 32700 (fail), for first failure
 Repro found: flight 32702 (pass), for last pass
 Repro found: flight 32703 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-i386-rhel6hvm-amd.redhat-install.{dot,ps,png,html}.
----------------------------------------
32703: tolerable ALL FAIL

flight 32703 qemu-mainline real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32703/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install          fail baseline untested


jobs:
 test-amd64-i386-rhel6hvm-amd                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Dec 27 00:08:21 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 00:08:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4euv-00014l-HE; Sat, 27 Dec 2014 00:07:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y4euu-00014g-90
	for xen-devel@lists.xensource.com; Sat, 27 Dec 2014 00:07:36 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	F7/EA-25276-748FD945; Sat, 27 Dec 2014 00:07:35 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419638853!17989179!1
X-Originating-IP: [66.165.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 29055 invoked from network); 27 Dec 2014 00:07:34 -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;
	27 Dec 2014 00:07:34 -0000
X-IronPort-AV: E=Sophos;i="5.07,649,1413244800"; d="scan'208";a="208890156"
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.210.2; Fri, 26 Dec 2014 19:07: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 1Y4eup-0006kB-Ot;
	Sat, 27 Dec 2014 00:07:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4eup-0007hh-JZ;
	Sat, 27 Dec 2014 00:07:31 +0000
Date: Sat, 27 Dec 2014 00:07:31 +0000
Message-ID: <E1Y4eup-0007hh-JZ@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] [qemu-mainline bisection] complete
	test-amd64-i386-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-amd
test redhat-install

Tree: linux git://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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-i386-rhel6hvm-amd.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32659 fail [host=potato-beetle] / 32598 [host=lace-bug] 32585 ok.
Failure / basis pass flights: 32659 / 32585
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#83a926f7a4e39fb6be0576024e67fe161593defa-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#c95f3901b4ead79f3fe2c641fda7d2c70fc84c72-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 1005 nodes in revision graph
Searching for test results:
 32571 pass irrelevant
 32585 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32598 [host=lace-bug]
 32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32698 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32699 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32700 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32684 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32685 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32702 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32688 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c8e829b7bf6e1c84af8b4b13ee7fce2959c63e0e 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32703 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32690 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7eb1dc7f0b65a324323541440baf2ea544adcefb 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32696 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32697 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 32585 (pass), for basis pass
 Result found: flight 32611 (fail), for basis failure
 Repro found: flight 32684 (pass), for basis pass
 Repro found: flight 32685 (fail), for basis failure
 0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32696 (pass), for last pass
 Result found: flight 32698 (fail), for first failure
 Repro found: flight 32699 (pass), for last pass
 Repro found: flight 32700 (fail), for first failure
 Repro found: flight 32702 (pass), for last pass
 Repro found: flight 32703 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-i386-rhel6hvm-amd.redhat-install.{dot,ps,png,html}.
----------------------------------------
32703: tolerable ALL FAIL

flight 32703 qemu-mainline real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32703/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install          fail baseline untested


jobs:
 test-amd64-i386-rhel6hvm-amd                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Dec 27 01:16:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 01:16:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4fyp-0006JT-FZ; Sat, 27 Dec 2014 01:15:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y4fyn-0006JO-UW
	for xen-devel@lists.xen.org; Sat, 27 Dec 2014 01:15:42 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	D1/19-20609-D380E945; Sat, 27 Dec 2014 01:15:41 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1419642939!17323556!1
X-Originating-IP: [209.85.218.46]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8104 invoked from network); 27 Dec 2014 01:15:40 -0000
Received: from mail-oi0-f46.google.com (HELO mail-oi0-f46.google.com)
	(209.85.218.46)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2014 01:15:40 -0000
Received: by mail-oi0-f46.google.com with SMTP id h136so23754557oig.5
	for <xen-devel@lists.xen.org>; Fri, 26 Dec 2014 17:15:38 -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=E1mLOLh94jjK75IUDZ9ixJEn7U/ouILT15FE75/2K54=;
	b=h5DHRuJfuIV6PRhgwgYIuikxSy7U2BpnEBTvVlExzY53+c8Bed5NVvAmlenAwuqrWd
	8b/x8pnoqjlRH5pce4fL+95eYn7cWY20RXs1geyOM9LyUz2O213H2Alz7m48pSfIAI+1
	jNWi2AuxrSG5ynvOADt3ZVMaUGzg8t+n8r/GPcS/FtIlLhwzM3rrhAu8vwkYiuVDETDg
	ntvuMm4DIvJLyhM6shfhoY5r1XptU/vIn90TaRuBXkEGeJDarVjkzzCysCHLgyt74MBI
	cSRF43ltXguxQHy5m6E4kcUachk4cbJjIhz4B3g03tzVkwhNhEmCQmCcQpri1V9ua0kQ
	arlw==
MIME-Version: 1.0
X-Received: by 10.60.173.211 with SMTP id bm19mr26476288oec.66.1419642938675; 
	Fri, 26 Dec 2014 17:15:38 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Fri, 26 Dec 2014 17:15:38 -0800 (PST)
Date: Sat, 27 Dec 2014 02:15:38 +0100
Message-ID: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL drivers
	don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2127949952557868437=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2127949952557868437==
Content-Type: multipart/alternative; boundary=089e011764eb115781050b286109

--089e011764eb115781050b286109
Content-Type: text/plain; charset=UTF-8

I tried to install Qxl drivers under win7/win 2k8/win8.1         all
x64 versions, without any luck.


admin message is as follow:
Driver Management concluded the process to install driver
FileRepository\qxl.inf_amd64_
neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
following status: 0xe000022d.




Does
http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html

can it be installed on my xen stack?

Also, can  I get invited at xendevel irc ?
regards

Greg

--089e011764eb115781050b286109
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>I tried to install Qxl drivers under win7/w=
in 2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 all=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64 versions, without any luck.<br><br><br>admi=
n message is as follow:<br>Driver Management concluded the process to insta=
ll driver FileRepository\qxl.inf_amd64_<div dir=3D"ltr">neutral_f0c429882d5=
c81ed\qxl.inf for Device Instance ID PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_1=
1001AF4&amp;REV_00\3&amp;267A616A&amp;1&amp;28 with the following status: 0=
xe000022d.</div><br><br><br><br></div>Does <br><a href=3D"http://lists.xen.=
org/archives/html/xen-devel/2014-05/msg03214.html">http://lists.xen.org/arc=
hives/html/xen-devel/2014-05/msg03214.html</a><br><br></div>can it be insta=
lled on my xen stack? <br><br>Also, can=C2=A0 I get invited at xendevel irc=
 ?<br>regards<br><br></div>Greg <br></div>

--089e011764eb115781050b286109--


--===============2127949952557868437==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2127949952557868437==--


From xen-devel-bounces@lists.xen.org Sat Dec 27 01:16:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 01:16:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4fyp-0006JT-FZ; Sat, 27 Dec 2014 01:15:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y4fyn-0006JO-UW
	for xen-devel@lists.xen.org; Sat, 27 Dec 2014 01:15:42 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	D1/19-20609-D380E945; Sat, 27 Dec 2014 01:15:41 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1419642939!17323556!1
X-Originating-IP: [209.85.218.46]
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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8104 invoked from network); 27 Dec 2014 01:15:40 -0000
Received: from mail-oi0-f46.google.com (HELO mail-oi0-f46.google.com)
	(209.85.218.46)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2014 01:15:40 -0000
Received: by mail-oi0-f46.google.com with SMTP id h136so23754557oig.5
	for <xen-devel@lists.xen.org>; Fri, 26 Dec 2014 17:15:38 -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=E1mLOLh94jjK75IUDZ9ixJEn7U/ouILT15FE75/2K54=;
	b=h5DHRuJfuIV6PRhgwgYIuikxSy7U2BpnEBTvVlExzY53+c8Bed5NVvAmlenAwuqrWd
	8b/x8pnoqjlRH5pce4fL+95eYn7cWY20RXs1geyOM9LyUz2O213H2Alz7m48pSfIAI+1
	jNWi2AuxrSG5ynvOADt3ZVMaUGzg8t+n8r/GPcS/FtIlLhwzM3rrhAu8vwkYiuVDETDg
	ntvuMm4DIvJLyhM6shfhoY5r1XptU/vIn90TaRuBXkEGeJDarVjkzzCysCHLgyt74MBI
	cSRF43ltXguxQHy5m6E4kcUachk4cbJjIhz4B3g03tzVkwhNhEmCQmCcQpri1V9ua0kQ
	arlw==
MIME-Version: 1.0
X-Received: by 10.60.173.211 with SMTP id bm19mr26476288oec.66.1419642938675; 
	Fri, 26 Dec 2014 17:15:38 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Fri, 26 Dec 2014 17:15:38 -0800 (PST)
Date: Sat, 27 Dec 2014 02:15:38 +0100
Message-ID: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL drivers
	don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2127949952557868437=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2127949952557868437==
Content-Type: multipart/alternative; boundary=089e011764eb115781050b286109

--089e011764eb115781050b286109
Content-Type: text/plain; charset=UTF-8

I tried to install Qxl drivers under win7/win 2k8/win8.1         all
x64 versions, without any luck.


admin message is as follow:
Driver Management concluded the process to install driver
FileRepository\qxl.inf_amd64_
neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
following status: 0xe000022d.




Does
http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html

can it be installed on my xen stack?

Also, can  I get invited at xendevel irc ?
regards

Greg

--089e011764eb115781050b286109
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>I tried to install Qxl drivers under win7/w=
in 2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 all=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64 versions, without any luck.<br><br><br>admi=
n message is as follow:<br>Driver Management concluded the process to insta=
ll driver FileRepository\qxl.inf_amd64_<div dir=3D"ltr">neutral_f0c429882d5=
c81ed\qxl.inf for Device Instance ID PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_1=
1001AF4&amp;REV_00\3&amp;267A616A&amp;1&amp;28 with the following status: 0=
xe000022d.</div><br><br><br><br></div>Does <br><a href=3D"http://lists.xen.=
org/archives/html/xen-devel/2014-05/msg03214.html">http://lists.xen.org/arc=
hives/html/xen-devel/2014-05/msg03214.html</a><br><br></div>can it be insta=
lled on my xen stack? <br><br>Also, can=C2=A0 I get invited at xendevel irc=
 ?<br>regards<br><br></div>Greg <br></div>

--089e011764eb115781050b286109--


--===============2127949952557868437==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2127949952557868437==--


From xen-devel-bounces@lists.xen.org Sat Dec 27 03:42:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 03:42:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4iG6-0001cC-NE; Sat, 27 Dec 2014 03:41:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y4iG5-0001c3-2G
	for xen-devel@lists.xensource.com; Sat, 27 Dec 2014 03:41:41 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	81/D7-14214-47A2E945; Sat, 27 Dec 2014 03:41:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1419651696!11360827!1
X-Originating-IP: [66.165.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 9124 invoked from network); 27 Dec 2014 03:41:37 -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;
	27 Dec 2014 03:41:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,650,1413244800"; d="scan'208";a="208916458"
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.210.2; Fri, 26 Dec 2014 22:41: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 1Y4iFy-0007ln-W3;
	Sat, 27 Dec 2014 03:41:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4iFy-0003lz-Qu;
	Sat, 27 Dec 2014 03:41:34 +0000
Date: Sat, 27 Dec 2014 03:41:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32686-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] 32686: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32686 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32686/

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. 32647

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32647
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32647
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32647
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32647

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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                2fb8bdb2ca2808ce901fdfc1eda31bcb488156d0
baseline version:
 linux                53262d12d1658669029ab39a63e3d314108abe66

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 27 03:42:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 03:42:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4iG6-0001cC-NE; Sat, 27 Dec 2014 03:41:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y4iG5-0001c3-2G
	for xen-devel@lists.xensource.com; Sat, 27 Dec 2014 03:41:41 +0000
Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id
	81/D7-14214-47A2E945; Sat, 27 Dec 2014 03:41:40 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1419651696!11360827!1
X-Originating-IP: [66.165.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 9124 invoked from network); 27 Dec 2014 03:41:37 -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;
	27 Dec 2014 03:41:37 -0000
X-IronPort-AV: E=Sophos;i="5.07,650,1413244800"; d="scan'208";a="208916458"
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.210.2; Fri, 26 Dec 2014 22:41: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 1Y4iFy-0007ln-W3;
	Sat, 27 Dec 2014 03:41:35 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4iFy-0003lz-Qu;
	Sat, 27 Dec 2014 03:41:34 +0000
Date: Sat, 27 Dec 2014 03:41:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32686-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] 32686: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32686 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32686/

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. 32647

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32647
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32647
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32647
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32647

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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                2fb8bdb2ca2808ce901fdfc1eda31bcb488156d0
baseline version:
 linux                53262d12d1658669029ab39a63e3d314108abe66

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 27 04:43:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 04: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 1Y4jDU-0003G3-Dx; Sat, 27 Dec 2014 04:43: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 1Y4jDT-0003Fy-Fk
	for xen-devel@lists.xensource.com; Sat, 27 Dec 2014 04:43:03 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	D5/EE-02707-6D83E945; Sat, 27 Dec 2014 04:43:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1419655380!15273812!1
X-Originating-IP: [66.165.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 18788 invoked from network); 27 Dec 2014 04:43:01 -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;
	27 Dec 2014 04:43:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,650,1413244800"; d="scan'208";a="208390470"
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.210.2; Fri, 26 Dec 2014 23:42: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 1Y4jDI-000848-5q;
	Sat, 27 Dec 2014 04:42:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4jDG-0007Xe-OD;
	Sat, 27 Dec 2014 04:42:51 +0000
Date: Sat, 27 Dec 2014 04:42:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32689-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] 32689: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32689 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32689/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 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 912 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 Dec 27 04:43:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 04: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 1Y4jDU-0003G3-Dx; Sat, 27 Dec 2014 04:43: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 1Y4jDT-0003Fy-Fk
	for xen-devel@lists.xensource.com; Sat, 27 Dec 2014 04:43:03 +0000
Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id
	D5/EE-02707-6D83E945; Sat, 27 Dec 2014 04:43:02 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1419655380!15273812!1
X-Originating-IP: [66.165.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 18788 invoked from network); 27 Dec 2014 04:43:01 -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;
	27 Dec 2014 04:43:01 -0000
X-IronPort-AV: E=Sophos;i="5.07,650,1413244800"; d="scan'208";a="208390470"
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.210.2; Fri, 26 Dec 2014 23:42: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 1Y4jDI-000848-5q;
	Sat, 27 Dec 2014 04:42:52 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4jDG-0007Xe-OD;
	Sat, 27 Dec 2014 04:42:51 +0000
Date: Sat, 27 Dec 2014 04:42:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32689-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] 32689: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32689 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32689/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 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 912 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 Dec 27 09:27:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 09:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4neJ-0000SA-0f; Sat, 27 Dec 2014 09:27:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y4neH-0000S5-Jm
	for xen-devel@lists.xensource.com; Sat, 27 Dec 2014 09:27:01 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	01/93-26740-46B7E945; Sat, 27 Dec 2014 09:27:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1419672418!15973804!1
X-Originating-IP: [66.165.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 23697 invoked from network); 27 Dec 2014 09:26: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;
	27 Dec 2014 09:26:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,650,1413244800"; d="scan'208";a="208426103"
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.210.2; Sat, 27 Dec 2014 04:26: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 1Y4neC-00011o-LE;
	Sat, 27 Dec 2014 09:26:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4neC-00080F-EZ;
	Sat, 27 Dec 2014 09:26:56 +0000
Date: Sat, 27 Dec 2014 09:26:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32695-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] 32695: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32695 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32695/

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-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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-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 14 guest-stop                fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                     fail    
 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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 27 09:27:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 09:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4neJ-0000SA-0f; Sat, 27 Dec 2014 09:27:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y4neH-0000S5-Jm
	for xen-devel@lists.xensource.com; Sat, 27 Dec 2014 09:27:01 +0000
Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id
	01/93-26740-46B7E945; Sat, 27 Dec 2014 09:27:00 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1419672418!15973804!1
X-Originating-IP: [66.165.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 23697 invoked from network); 27 Dec 2014 09:26: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;
	27 Dec 2014 09:26:59 -0000
X-IronPort-AV: E=Sophos;i="5.07,650,1413244800"; d="scan'208";a="208426103"
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.210.2; Sat, 27 Dec 2014 04:26: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 1Y4neC-00011o-LE;
	Sat, 27 Dec 2014 09:26:56 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4neC-00080F-EZ;
	Sat, 27 Dec 2014 09:26:56 +0000
Date: Sat, 27 Dec 2014 09:26:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32695-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] 32695: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32695 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32695/

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-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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-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 14 guest-stop                fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                     fail    
 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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 27 14:11:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 14:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4s4a-0005Iz-8a; Sat, 27 Dec 2014 14:10:28 +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 1Y4s4Y-0005Iu-DL
	for xen-devel@lists.xen.org; Sat, 27 Dec 2014 14:10:26 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	83/E8-19763-1DDBE945; Sat, 27 Dec 2014 14:10:25 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-16.tower-206.messagelabs.com!1419689423!12438060!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31259 invoked from network); 27 Dec 2014 14:10:23 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2014 14:10:23 -0000
Received: by mail-wi0-f173.google.com with SMTP id r20so18714677wiv.6
	for <xen-devel@lists.xen.org>; Sat, 27 Dec 2014 06:10: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
	:subject:references:in-reply-to:content-type;
	bh=jyArYJfYP0I3NyPkODNG7ZNnimb3XauDvjn7m1Kjxt4=;
	b=i3UVeiu71yk4ZKHnAeAPJrcUQnn2xtIQPpBqGdNXY2xQ64/J/HdIdqauA6BVr2ZeAa
	SgqpAH5Me4rkfE7p+BQQ3xtCt7LOdXCqMEvLY09PpbRvrf2FrDyZaOVma5FHMKnlx/DJ
	MXkTjx54tz89IgJkDgoi5qhY4RItAbOcy2hQvD9m7QDoyfRjwsEL8vX49xoywXVOxOdw
	vK+LmIbf735xvyhNS6zvewxE42YGRo4X88I1wfCJrDrnGEPUTKozUPIqOnZZFmgyM8Yr
	seRKjlgpofWuOT/Z7mseNvieZKYmZhbeI4Du+wAEOEsa+MJ8HYIguo6zDC7GuoiVVbq3
	BZvg==
X-Gm-Message-State: ALoCoQlT3UrVhou0qJJzsMNr1YOrK5XKosot2nTblC+mcawTikMtbG0jS9T1xZ3R/lz7CIYkP1nB
X-Received: by 10.180.108.205 with SMTP id hm13mr79894219wib.5.1419689423459; 
	Sat, 27 Dec 2014 06:10:23 -0800 (PST)
Received: from [192.168.178.37]
	(host46-14-dynamic.52-82-r.retail.telecomitalia.it. [82.52.14.46])
	by mx.google.com with ESMTPSA id
	wz5sm42372008wjc.29.2014.12.27.06.10.21
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 27 Dec 2014 06:10:22 -0800 (PST)
Message-ID: <549EBDCC.3090102@m2r.biz>
Date: Sat, 27 Dec 2014 15:10:20 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Goonie Windy <monsieur.goonie@gmail.com>, xen-devel@lists.xen.org
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
In-Reply-To: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6557443337033257903=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6557443337033257903==
Content-Type: multipart/alternative;
 boundary="------------050001070006040308000402"

This is a multi-part message in MIME format.
--------------050001070006040308000402
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit


Il 27/12/2014 02:15, Goonie Windy ha scritto:
> I tried to install Qxl drivers under win7/win 2k8/win8.1         
> all       x64 versions, without any luck.
>
>
> admin message is as follow:
> Driver Management concluded the process to install driver 
> FileRepository\qxl.inf_amd64_
> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID 
> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the 
> following status: 0xe000022d.
>
>
>
>
> Does
> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>
> can it be installed on my xen stack?

Yes but probably require a small refresh, I always posted the patch 
based on updated xen-unstable.

Here qxl patch refreshed for xen 4.5 if needed:
https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe

Here the latest spice guest tools for windows with qxl driver included:
http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe

Windows >=8 and similar require a new qxl drivers, there are a beta 
build but latest tried some months ago have serious bug and I not found 
recent build full working on windows 8.

On xen windows 7 domUs qxl works good except a problem after 
save/restore and on linux domUs is not working, for now I not found 
exactly cause and solution.
On mailing list up to 2 years ago you can find many my mails about.
Any help to test it is appreciated.

Sorry for my bad english.

>
> Also, can  I get invited at xendevel irc ?
> regards
>
> Greg
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------050001070006040308000402
Content-Type: text/html; charset=iso-8859-15
Content-Length: 3650
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Diso-8859-15"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div class=3D"moz-cite-prefix">Il 27/12/2014 02:15, Goonie Windy ha
      scritto:<br>
    </div>
    <blockquote
cite=3D"mid:CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>I tried to install Qxl drivers under win7/win
              2k8/win8.1=A0=A0=A0=A0=A0=A0=A0=A0 all=A0=A0=A0=A0=A0=A0 x64 versions, without any
              luck.<br>
              <br>
              <br>
              admin message is as follow:<br>
              Driver Management concluded the process to install driver
              FileRepository\qxl.inf_amd64_
              <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf for Device
                Instance ID
                PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&amp;267A616A&amp;1&amp;28
                with the following status: 0xe000022d.</div>
              <br>
              <br>
              <br>
              <br>
            </div>
            Does <br>
            <a moz-do-not-send=3D"true"
href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html">http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html</a><br>
            <br>
          </div>
          can it be installed on my xen stack=3F <br>
        </div>
      </div>
    </blockquote>
    <br>
    Yes but probably require a small refresh, I always posted the patch
    based on updated xen-unstable. <br>
    <br>
    Here qxl patch refreshed for xen 4.5 if needed:<br>
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
    <br>
    Here the latest spice guest tools for windows with qxl driver
    included:<br>
<a class=3D"moz-txt-link-freetext" href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe">http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
    <br>
    Windows &gt;=3D8 and similar require a new qxl drivers, there are a
    beta build but latest tried some months ago have serious bug and I
    not found recent build full working on windows 8.<br>
    <br>
    On xen windows 7 domUs qxl works good except a problem after
    save/restore and on linux domUs is not working, for now I not found
    exactly cause and solution.<br>
    On mailing list up to 2 years ago you can find many my mails about.<br>
    Any help to test it is appreciated.<br>
    <br>
    Sorry for my bad english.<br>
    <br>
    <blockquote
cite=3D"mid:CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          Also, can=A0 I get invited at xendevel irc =3F<br>
          regards<br>
          <br>
        </div>
        Greg <br>
      </div>
      <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>

--------------050001070006040308000402--


--===============6557443337033257903==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6557443337033257903==--


From xen-devel-bounces@lists.xen.org Sat Dec 27 14:11:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 14:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4s4a-0005Iz-8a; Sat, 27 Dec 2014 14:10:28 +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 1Y4s4Y-0005Iu-DL
	for xen-devel@lists.xen.org; Sat, 27 Dec 2014 14:10:26 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	83/E8-19763-1DDBE945; Sat, 27 Dec 2014 14:10:25 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-16.tower-206.messagelabs.com!1419689423!12438060!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31259 invoked from network); 27 Dec 2014 14:10:23 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2014 14:10:23 -0000
Received: by mail-wi0-f173.google.com with SMTP id r20so18714677wiv.6
	for <xen-devel@lists.xen.org>; Sat, 27 Dec 2014 06:10: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
	:subject:references:in-reply-to:content-type;
	bh=jyArYJfYP0I3NyPkODNG7ZNnimb3XauDvjn7m1Kjxt4=;
	b=i3UVeiu71yk4ZKHnAeAPJrcUQnn2xtIQPpBqGdNXY2xQ64/J/HdIdqauA6BVr2ZeAa
	SgqpAH5Me4rkfE7p+BQQ3xtCt7LOdXCqMEvLY09PpbRvrf2FrDyZaOVma5FHMKnlx/DJ
	MXkTjx54tz89IgJkDgoi5qhY4RItAbOcy2hQvD9m7QDoyfRjwsEL8vX49xoywXVOxOdw
	vK+LmIbf735xvyhNS6zvewxE42YGRo4X88I1wfCJrDrnGEPUTKozUPIqOnZZFmgyM8Yr
	seRKjlgpofWuOT/Z7mseNvieZKYmZhbeI4Du+wAEOEsa+MJ8HYIguo6zDC7GuoiVVbq3
	BZvg==
X-Gm-Message-State: ALoCoQlT3UrVhou0qJJzsMNr1YOrK5XKosot2nTblC+mcawTikMtbG0jS9T1xZ3R/lz7CIYkP1nB
X-Received: by 10.180.108.205 with SMTP id hm13mr79894219wib.5.1419689423459; 
	Sat, 27 Dec 2014 06:10:23 -0800 (PST)
Received: from [192.168.178.37]
	(host46-14-dynamic.52-82-r.retail.telecomitalia.it. [82.52.14.46])
	by mx.google.com with ESMTPSA id
	wz5sm42372008wjc.29.2014.12.27.06.10.21
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 27 Dec 2014 06:10:22 -0800 (PST)
Message-ID: <549EBDCC.3090102@m2r.biz>
Date: Sat, 27 Dec 2014 15:10:20 +0100
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Goonie Windy <monsieur.goonie@gmail.com>, xen-devel@lists.xen.org
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
In-Reply-To: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6557443337033257903=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6557443337033257903==
Content-Type: multipart/alternative;
 boundary="------------050001070006040308000402"

This is a multi-part message in MIME format.
--------------050001070006040308000402
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit


Il 27/12/2014 02:15, Goonie Windy ha scritto:
> I tried to install Qxl drivers under win7/win 2k8/win8.1         
> all       x64 versions, without any luck.
>
>
> admin message is as follow:
> Driver Management concluded the process to install driver 
> FileRepository\qxl.inf_amd64_
> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID 
> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the 
> following status: 0xe000022d.
>
>
>
>
> Does
> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>
> can it be installed on my xen stack?

Yes but probably require a small refresh, I always posted the patch 
based on updated xen-unstable.

Here qxl patch refreshed for xen 4.5 if needed:
https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe

Here the latest spice guest tools for windows with qxl driver included:
http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe

Windows >=8 and similar require a new qxl drivers, there are a beta 
build but latest tried some months ago have serious bug and I not found 
recent build full working on windows 8.

On xen windows 7 domUs qxl works good except a problem after 
save/restore and on linux domUs is not working, for now I not found 
exactly cause and solution.
On mailing list up to 2 years ago you can find many my mails about.
Any help to test it is appreciated.

Sorry for my bad english.

>
> Also, can  I get invited at xendevel irc ?
> regards
>
> Greg
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------050001070006040308000402
Content-Type: text/html; charset=iso-8859-15
Content-Length: 3650
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Diso-8859-15"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div class=3D"moz-cite-prefix">Il 27/12/2014 02:15, Goonie Windy ha
      scritto:<br>
    </div>
    <blockquote
cite=3D"mid:CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>I tried to install Qxl drivers under win7/win
              2k8/win8.1=A0=A0=A0=A0=A0=A0=A0=A0 all=A0=A0=A0=A0=A0=A0 x64 versions, without any
              luck.<br>
              <br>
              <br>
              admin message is as follow:<br>
              Driver Management concluded the process to install driver
              FileRepository\qxl.inf_amd64_
              <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf for Device
                Instance ID
                PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&amp;267A616A&amp;1&amp;28
                with the following status: 0xe000022d.</div>
              <br>
              <br>
              <br>
              <br>
            </div>
            Does <br>
            <a moz-do-not-send=3D"true"
href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html">http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html</a><br>
            <br>
          </div>
          can it be installed on my xen stack=3F <br>
        </div>
      </div>
    </blockquote>
    <br>
    Yes but probably require a small refresh, I always posted the patch
    based on updated xen-unstable. <br>
    <br>
    Here qxl patch refreshed for xen 4.5 if needed:<br>
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
    <br>
    Here the latest spice guest tools for windows with qxl driver
    included:<br>
<a class=3D"moz-txt-link-freetext" href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe">http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
    <br>
    Windows &gt;=3D8 and similar require a new qxl drivers, there are a
    beta build but latest tried some months ago have serious bug and I
    not found recent build full working on windows 8.<br>
    <br>
    On xen windows 7 domUs qxl works good except a problem after
    save/restore and on linux domUs is not working, for now I not found
    exactly cause and solution.<br>
    On mailing list up to 2 years ago you can find many my mails about.<br>
    Any help to test it is appreciated.<br>
    <br>
    Sorry for my bad english.<br>
    <br>
    <blockquote
cite=3D"mid:CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          Also, can=A0 I get invited at xendevel irc =3F<br>
          regards<br>
          <br>
        </div>
        Greg <br>
      </div>
      <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>

--------------050001070006040308000402--


--===============6557443337033257903==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6557443337033257903==--


From xen-devel-bounces@lists.xen.org Sat Dec 27 16:36:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 16: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 1Y4uL7-0008BJ-Hr; Sat, 27 Dec 2014 16:35:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y4uL5-0008BE-UH
	for xen-devel@lists.xen.org; Sat, 27 Dec 2014 16:35:40 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	49/3C-09842-BDFDE945; Sat, 27 Dec 2014 16:35:39 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1419698136!18059220!1
X-Originating-IP: [209.85.214.178]
X-SpamReason: No, hits=2.1 required=7.0 tests=BIZ_TLD,HTML_50_60,
	HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14686 invoked from network); 27 Dec 2014 16:35:37 -0000
Received: from mail-ob0-f178.google.com (HELO mail-ob0-f178.google.com)
	(209.85.214.178)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2014 16:35:37 -0000
Received: by mail-ob0-f178.google.com with SMTP id gq1so37038580obb.9
	for <xen-devel@lists.xen.org>; Sat, 27 Dec 2014 08:35:36 -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=EmEO2/DTYnNugJYETBotSQ9VZuFm+lIEpP7ODTmCqZc=;
	b=sjuwrIDUAZ1U3b0ORK11nsan4vTSMyQEHhmkrHBN+o3MOtPniRypotrlPVa1yUH9f5
	q4zOg8zYsuTZ+X9zH5VjzM5IODU/Wgoh2tffX1mDb2Mf5RJanC1FXV/aH7tRnrGisLGT
	4+Yu5ZgnthgWB6znMUPIia5DbiY+IbYy+4wreA0Hod1qJ95lBhd8/hcvl8mJws9GBq6Z
	XM6NrYvVcgAEwlm1APaidlmjqrN+EmWtsCm3Opluld4AshVvu+0MDmxy1hXpQi6BPWsU
	6FC9OpVAQ1MvAj4d+jSk8gcey2nxdeejVOupKrx10MjkjS0qfW/2xmwUEJIdm/xcidbl
	FV1g==
MIME-Version: 1.0
X-Received: by 10.182.50.225 with SMTP id f1mr27809399obo.45.1419698135926;
	Sat, 27 Dec 2014 08:35:35 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Sat, 27 Dec 2014 08:35:35 -0800 (PST)
In-Reply-To: <549EBDCC.3090102@m2r.biz>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
	<549EBDCC.3090102@m2r.biz>
Date: Sat, 27 Dec 2014 17:35:35 +0100
Message-ID: <CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0419830538055126398=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0419830538055126398==
Content-Type: multipart/alternative; boundary=089e0160b594148ddb050b353b42

--089e0160b594148ddb050b353b42
Content-Type: text/plain; charset=UTF-8

Hello Fabio,

Sure thing I will help debug the win7 and the win8 versions.
Where to start?

I'll try to see if I can patch with patch from
https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
and if not will post result.


best regards,


greg Bahde

2014-12-27 15:10 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:

>
> Il 27/12/2014 02:15, Goonie Windy ha scritto:
>
>   I tried to install Qxl drivers under win7/win 2k8/win8.1
> all       x64 versions, without any luck.
>
>
> admin message is as follow:
> Driver Management concluded the process to install driver
> FileRepository\qxl.inf_amd64_
> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
> following status: 0xe000022d.
>
>
>
>
>  Does
> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>
>  can it be installed on my xen stack?
>
>
> Yes but probably require a small refresh, I always posted the patch based
> on updated xen-unstable.
>
> Here qxl patch refreshed for xen 4.5 if needed:
>
> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>
> Here the latest spice guest tools for windows with qxl driver included:
>
> http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>
> Windows >=8 and similar require a new qxl drivers, there are a beta build
> but latest tried some months ago have serious bug and I not found recent
> build full working on windows 8.
>
> On xen windows 7 domUs qxl works good except a problem after save/restore
> and on linux domUs is not working, for now I not found exactly cause and
> solution.
> On mailing list up to 2 years ago you can find many my mails about.
> Any help to test it is appreciated.
>
> Sorry for my bad english.
>
>
> Also, can  I get invited at xendevel irc ?
> regards
>
>  Greg
>
>
> _______________________________________________
> Xen-devel mailing listXen-devel@lists.xen.orghttp://lists.xen.org/xen-devel
>
>
>

--089e0160b594148ddb050b353b42
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hello Fabio,<br><br>Sure thing I will help =
debug the win7 and the win8 versions.<br></div>Where to start?<br><br></div=
>I&#39;ll try to see if I can patch with patch from <a href=3D"https://gith=
ub.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe" target=3D=
"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa1=
1879e8b8fe</a> and if not will post result.<br><br><br>best regards,<br><br=
><br></div>greg Bahde<br></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">2014-12-27 15:10 GMT+01:00 Fabio Fantoni <span dir=3D"ltr">&l=
t;<a href=3D"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">fabio.fantoni@=
m2r.biz</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div>Il 27/12/2014 02:15, Goonie Windy ha
      scritto:<br>
    </div><span class=3D"">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>I tried to install Qxl drivers under win7/win
              2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 al=
l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64 versions, without any
              luck.<br>
              <br>
              <br>
              admin message is as follow:<br>
              Driver Management concluded the process to install driver
              FileRepository\qxl.inf_amd64_
              <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf for Device
                Instance ID
                PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&=
amp;267A616A&amp;1&amp;28
                with the following status: 0xe000022d.</div>
              <br>
              <br>
              <br>
              <br>
            </div>
            Does <br>
            <a href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05=
/msg03214.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-de=
vel/2014-05/msg03214.html</a><br>
            <br>
          </div>
          can it be installed on my xen stack? <br>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes but probably require a small refresh, I always posted the patch
    based on updated xen-unstable. <br>
    <br>
    Here qxl patch refreshed for xen 4.5 if needed:<br>
<a href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67a=
a11879e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8=
d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
    <br>
    Here the latest spice guest tools for windows with qxl driver
    included:<br>
<a href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/s=
pice-guest-tools-0.74.exe" target=3D"_blank">http://www.spice-space.org/dow=
nload/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
    <br>
    Windows &gt;=3D8 and similar require a new qxl drivers, there are a
    beta build but latest tried some months ago have serious bug and I
    not found recent build full working on windows 8.<br>
    <br>
    On xen windows 7 domUs qxl works good except a problem after
    save/restore and on linux domUs is not working, for now I not found
    exactly cause and solution.<br>
    On mailing list up to 2 years ago you can find many my mails about.<br>
    Any help to test it is appreciated.<br>
    <br>
    Sorry for my bad english.<br>
    <br>
    <blockquote type=3D"cite"><span class=3D"">
      <div dir=3D"ltr">
        <div><br>
          Also, can=C2=A0 I get invited at xendevel irc ?<br>
          regards<br>
          <br>
        </div>
        Greg <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><pre>_______________________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>

--089e0160b594148ddb050b353b42--


--===============0419830538055126398==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0419830538055126398==--


From xen-devel-bounces@lists.xen.org Sat Dec 27 16:36:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 16: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 1Y4uL7-0008BJ-Hr; Sat, 27 Dec 2014 16:35:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y4uL5-0008BE-UH
	for xen-devel@lists.xen.org; Sat, 27 Dec 2014 16:35:40 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	49/3C-09842-BDFDE945; Sat, 27 Dec 2014 16:35:39 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1419698136!18059220!1
X-Originating-IP: [209.85.214.178]
X-SpamReason: No, hits=2.1 required=7.0 tests=BIZ_TLD,HTML_50_60,
	HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14686 invoked from network); 27 Dec 2014 16:35:37 -0000
Received: from mail-ob0-f178.google.com (HELO mail-ob0-f178.google.com)
	(209.85.214.178)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2014 16:35:37 -0000
Received: by mail-ob0-f178.google.com with SMTP id gq1so37038580obb.9
	for <xen-devel@lists.xen.org>; Sat, 27 Dec 2014 08:35:36 -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=EmEO2/DTYnNugJYETBotSQ9VZuFm+lIEpP7ODTmCqZc=;
	b=sjuwrIDUAZ1U3b0ORK11nsan4vTSMyQEHhmkrHBN+o3MOtPniRypotrlPVa1yUH9f5
	q4zOg8zYsuTZ+X9zH5VjzM5IODU/Wgoh2tffX1mDb2Mf5RJanC1FXV/aH7tRnrGisLGT
	4+Yu5ZgnthgWB6znMUPIia5DbiY+IbYy+4wreA0Hod1qJ95lBhd8/hcvl8mJws9GBq6Z
	XM6NrYvVcgAEwlm1APaidlmjqrN+EmWtsCm3Opluld4AshVvu+0MDmxy1hXpQi6BPWsU
	6FC9OpVAQ1MvAj4d+jSk8gcey2nxdeejVOupKrx10MjkjS0qfW/2xmwUEJIdm/xcidbl
	FV1g==
MIME-Version: 1.0
X-Received: by 10.182.50.225 with SMTP id f1mr27809399obo.45.1419698135926;
	Sat, 27 Dec 2014 08:35:35 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Sat, 27 Dec 2014 08:35:35 -0800 (PST)
In-Reply-To: <549EBDCC.3090102@m2r.biz>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
	<549EBDCC.3090102@m2r.biz>
Date: Sat, 27 Dec 2014 17:35:35 +0100
Message-ID: <CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0419830538055126398=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0419830538055126398==
Content-Type: multipart/alternative; boundary=089e0160b594148ddb050b353b42

--089e0160b594148ddb050b353b42
Content-Type: text/plain; charset=UTF-8

Hello Fabio,

Sure thing I will help debug the win7 and the win8 versions.
Where to start?

I'll try to see if I can patch with patch from
https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
and if not will post result.


best regards,


greg Bahde

2014-12-27 15:10 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:

>
> Il 27/12/2014 02:15, Goonie Windy ha scritto:
>
>   I tried to install Qxl drivers under win7/win 2k8/win8.1
> all       x64 versions, without any luck.
>
>
> admin message is as follow:
> Driver Management concluded the process to install driver
> FileRepository\qxl.inf_amd64_
> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
> following status: 0xe000022d.
>
>
>
>
>  Does
> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>
>  can it be installed on my xen stack?
>
>
> Yes but probably require a small refresh, I always posted the patch based
> on updated xen-unstable.
>
> Here qxl patch refreshed for xen 4.5 if needed:
>
> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>
> Here the latest spice guest tools for windows with qxl driver included:
>
> http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>
> Windows >=8 and similar require a new qxl drivers, there are a beta build
> but latest tried some months ago have serious bug and I not found recent
> build full working on windows 8.
>
> On xen windows 7 domUs qxl works good except a problem after save/restore
> and on linux domUs is not working, for now I not found exactly cause and
> solution.
> On mailing list up to 2 years ago you can find many my mails about.
> Any help to test it is appreciated.
>
> Sorry for my bad english.
>
>
> Also, can  I get invited at xendevel irc ?
> regards
>
>  Greg
>
>
> _______________________________________________
> Xen-devel mailing listXen-devel@lists.xen.orghttp://lists.xen.org/xen-devel
>
>
>

--089e0160b594148ddb050b353b42
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hello Fabio,<br><br>Sure thing I will help =
debug the win7 and the win8 versions.<br></div>Where to start?<br><br></div=
>I&#39;ll try to see if I can patch with patch from <a href=3D"https://gith=
ub.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe" target=3D=
"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa1=
1879e8b8fe</a> and if not will post result.<br><br><br>best regards,<br><br=
><br></div>greg Bahde<br></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">2014-12-27 15:10 GMT+01:00 Fabio Fantoni <span dir=3D"ltr">&l=
t;<a href=3D"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">fabio.fantoni@=
m2r.biz</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div>Il 27/12/2014 02:15, Goonie Windy ha
      scritto:<br>
    </div><span class=3D"">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>I tried to install Qxl drivers under win7/win
              2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 al=
l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64 versions, without any
              luck.<br>
              <br>
              <br>
              admin message is as follow:<br>
              Driver Management concluded the process to install driver
              FileRepository\qxl.inf_amd64_
              <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf for Device
                Instance ID
                PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&=
amp;267A616A&amp;1&amp;28
                with the following status: 0xe000022d.</div>
              <br>
              <br>
              <br>
              <br>
            </div>
            Does <br>
            <a href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05=
/msg03214.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-de=
vel/2014-05/msg03214.html</a><br>
            <br>
          </div>
          can it be installed on my xen stack? <br>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes but probably require a small refresh, I always posted the patch
    based on updated xen-unstable. <br>
    <br>
    Here qxl patch refreshed for xen 4.5 if needed:<br>
<a href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67a=
a11879e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8=
d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
    <br>
    Here the latest spice guest tools for windows with qxl driver
    included:<br>
<a href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/s=
pice-guest-tools-0.74.exe" target=3D"_blank">http://www.spice-space.org/dow=
nload/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
    <br>
    Windows &gt;=3D8 and similar require a new qxl drivers, there are a
    beta build but latest tried some months ago have serious bug and I
    not found recent build full working on windows 8.<br>
    <br>
    On xen windows 7 domUs qxl works good except a problem after
    save/restore and on linux domUs is not working, for now I not found
    exactly cause and solution.<br>
    On mailing list up to 2 years ago you can find many my mails about.<br>
    Any help to test it is appreciated.<br>
    <br>
    Sorry for my bad english.<br>
    <br>
    <blockquote type=3D"cite"><span class=3D"">
      <div dir=3D"ltr">
        <div><br>
          Also, can=C2=A0 I get invited at xendevel irc ?<br>
          regards<br>
          <br>
        </div>
        Greg <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><pre>_______________________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>

--089e0160b594148ddb050b353b42--


--===============0419830538055126398==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0419830538055126398==--


From xen-devel-bounces@lists.xen.org Sat Dec 27 16:42:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 16:42:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4uRc-0008SN-Gf; Sat, 27 Dec 2014 16:42: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 1Y4uRb-0008SI-3P
	for xen-devel@lists.xensource.com; Sat, 27 Dec 2014 16:42:23 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	3A/F2-02696-E61EE945; Sat, 27 Dec 2014 16:42:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1419698540!17352730!1
X-Originating-IP: [66.165.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 30638 invoked from network); 27 Dec 2014 16:42:21 -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;
	27 Dec 2014 16:42:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,651,1413244800"; d="scan'208";a="209026512"
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.210.2; Sat, 27 Dec 2014 11:42: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 1Y4uRX-00038Y-1X;
	Sat, 27 Dec 2014 16:42:19 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4uRW-00032T-Rf;
	Sat, 27 Dec 2014 16:42:18 +0000
Date: Sat, 27 Dec 2014 16:42:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32707-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] 32707: 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 32707 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32707/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)          broken pass in 32669
 test-armhf-armhf-libvirt     10 capture-logs(10)          broken pass in 32669

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32669

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-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-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-winxpsp3 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-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

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 Dec 27 16:42:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 16:42:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4uRc-0008SN-Gf; Sat, 27 Dec 2014 16:42: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 1Y4uRb-0008SI-3P
	for xen-devel@lists.xensource.com; Sat, 27 Dec 2014 16:42:23 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	3A/F2-02696-E61EE945; Sat, 27 Dec 2014 16:42:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1419698540!17352730!1
X-Originating-IP: [66.165.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 30638 invoked from network); 27 Dec 2014 16:42:21 -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;
	27 Dec 2014 16:42:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,651,1413244800"; d="scan'208";a="209026512"
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.210.2; Sat, 27 Dec 2014 11:42: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 1Y4uRX-00038Y-1X;
	Sat, 27 Dec 2014 16:42:19 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4uRW-00032T-Rf;
	Sat, 27 Dec 2014 16:42:18 +0000
Date: Sat, 27 Dec 2014 16:42:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32707-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] 32707: 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 32707 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32707/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)          broken pass in 32669
 test-armhf-armhf-libvirt     10 capture-logs(10)          broken pass in 32669

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32669

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        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-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-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-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-winxpsp3 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-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

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 Dec 27 21:18:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 21:18:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4ykI-0004cH-Ke; Sat, 27 Dec 2014 21:17:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y4ykG-0004cC-EW
	for xen-devel@lists.xensource.com; Sat, 27 Dec 2014 21:17:56 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	D3/E3-07724-3022F945; Sat, 27 Dec 2014 21:17:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1419715073!15992691!1
X-Originating-IP: [66.165.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 2328 invoked from network); 27 Dec 2014 21:17:54 -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;
	27 Dec 2014 21:17:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,652,1413244800"; d="scan'208";a="208521041"
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.210.2; Sat, 27 Dec 2014 16:17: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 1Y4ykB-0004S0-Dm;
	Sat, 27 Dec 2014 21:17:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4ykB-0001K0-8F;
	Sat, 27 Dec 2014 21:17:51 +0000
Date: Sat, 27 Dec 2014 21:17:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32713-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] 32713: 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 32713 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32713/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt     10 capture-logs(10)        broken REGR. vs. 32674
 test-armhf-armhf-xl          15 capture-logs(15)        broken REGR. vs. 32674

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32674
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32674
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32674
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32674

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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-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                58628a7831edac5f7a13baa9d9320c758c5204c8
baseline version:
 linux                08b022a9655bf925e6683422590306429b752ccd

------------------------------------------------------------
People who touched revisions under test:
  Helge Deller <deller@gmx.de>
  John David Anglin <dave.anglin@bell.net>
  Linus Torvalds <torvalds@linux-foundation.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                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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-libvirt capture-logs(10)
broken-step test-armhf-armhf-xl capture-logs(15)

Not pushing.

------------------------------------------------------------
commit 58628a7831edac5f7a13baa9d9320c758c5204c8
Merge: 08b022a 45db073
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Dec 26 13:41:05 2014 -0800

    Merge branch 'parisc-3.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
    
    Pull parisc build fix from Helge Deller:
     "This unbreaks the kernel compilation on parisc with gcc-4.9"
    
    * 'parisc-3.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
      parisc: fix out-of-register compiler error in ldcw inline assembler function

commit 45db07382a5c78b0c43b3b0002b63757fb60e873
Author: John David Anglin <dave.anglin@bell.net>
Date:   Sun Dec 14 10:49:11 2014 -0500

    parisc: fix out-of-register compiler error in ldcw inline assembler function
    
    The __ldcw macro has a problem when its argument needs to be reloaded from
    memory. The output memory operand and the input register operand both need to
    be reloaded using a register in class R1_REGS when generating 64-bit code.
    This fails because there's only a single register in the class. Instead, use a
    memory clobber. This also makes the __ldcw macro a compiler memory barrier.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Cc: <stable@vger.kernel.org>        [3.13+]
    Signed-off-by: Helge Deller <deller@gmx.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Dec 27 21:18:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Dec 2014 21:18:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y4ykI-0004cH-Ke; Sat, 27 Dec 2014 21:17:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y4ykG-0004cC-EW
	for xen-devel@lists.xensource.com; Sat, 27 Dec 2014 21:17:56 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	D3/E3-07724-3022F945; Sat, 27 Dec 2014 21:17:55 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1419715073!15992691!1
X-Originating-IP: [66.165.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 2328 invoked from network); 27 Dec 2014 21:17:54 -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;
	27 Dec 2014 21:17:54 -0000
X-IronPort-AV: E=Sophos;i="5.07,652,1413244800"; d="scan'208";a="208521041"
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.210.2; Sat, 27 Dec 2014 16:17: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 1Y4ykB-0004S0-Dm;
	Sat, 27 Dec 2014 21:17:51 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y4ykB-0001K0-8F;
	Sat, 27 Dec 2014 21:17:51 +0000
Date: Sat, 27 Dec 2014 21:17:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32713-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] 32713: 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 32713 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32713/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt     10 capture-logs(10)        broken REGR. vs. 32674
 test-armhf-armhf-xl          15 capture-logs(15)        broken REGR. vs. 32674

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32674
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32674
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32674
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32674

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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-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                58628a7831edac5f7a13baa9d9320c758c5204c8
baseline version:
 linux                08b022a9655bf925e6683422590306429b752ccd

------------------------------------------------------------
People who touched revisions under test:
  Helge Deller <deller@gmx.de>
  John David Anglin <dave.anglin@bell.net>
  Linus Torvalds <torvalds@linux-foundation.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                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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-libvirt capture-logs(10)
broken-step test-armhf-armhf-xl capture-logs(15)

Not pushing.

------------------------------------------------------------
commit 58628a7831edac5f7a13baa9d9320c758c5204c8
Merge: 08b022a 45db073
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Dec 26 13:41:05 2014 -0800

    Merge branch 'parisc-3.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
    
    Pull parisc build fix from Helge Deller:
     "This unbreaks the kernel compilation on parisc with gcc-4.9"
    
    * 'parisc-3.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
      parisc: fix out-of-register compiler error in ldcw inline assembler function

commit 45db07382a5c78b0c43b3b0002b63757fb60e873
Author: John David Anglin <dave.anglin@bell.net>
Date:   Sun Dec 14 10:49:11 2014 -0500

    parisc: fix out-of-register compiler error in ldcw inline assembler function
    
    The __ldcw macro has a problem when its argument needs to be reloaded from
    memory. The output memory operand and the input register operand both need to
    be reloaded using a register in class R1_REGS when generating 64-bit code.
    This fails because there's only a single register in the class. Instead, use a
    memory clobber. This also makes the __ldcw macro a compiler memory barrier.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Cc: <stable@vger.kernel.org>        [3.13+]
    Signed-off-by: Helge Deller <deller@gmx.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 28 01:04:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 01:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y52Gh-0004OU-6I; Sun, 28 Dec 2014 01:03:39 +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 1Y52Gf-0004OP-4A
	for xen-devel@lists.xensource.com; Sun, 28 Dec 2014 01:03:37 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	9E/1C-11608-4E65F945; Sun, 28 Dec 2014 01:03:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419728609!16067676!1
X-Originating-IP: [66.165.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 10905 invoked from network); 28 Dec 2014 01:03:31 -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 Dec 2014 01:03:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,653,1413244800"; d="scan'208";a="208547808"
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.210.2; Sat, 27 Dec 2014 20: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 1Y52GW-0005XK-5E;
	Sun, 28 Dec 2014 01:03:28 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y52GW-00071k-0S;
	Sun, 28 Dec 2014 01:03:28 +0000
Date: Sun, 28 Dec 2014 01:03:28 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32714-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] 32714: 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 32714 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32714/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)          broken pass in 32689
 test-armhf-armhf-libvirt     10 capture-logs(10)          broken pass in 32689

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Not pushing.

(No revision log; it would be 912 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 Dec 28 01:04:18 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 01:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y52Gh-0004OU-6I; Sun, 28 Dec 2014 01:03:39 +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 1Y52Gf-0004OP-4A
	for xen-devel@lists.xensource.com; Sun, 28 Dec 2014 01:03:37 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	9E/1C-11608-4E65F945; Sun, 28 Dec 2014 01:03:32 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419728609!16067676!1
X-Originating-IP: [66.165.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 10905 invoked from network); 28 Dec 2014 01:03:31 -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 Dec 2014 01:03:31 -0000
X-IronPort-AV: E=Sophos;i="5.07,653,1413244800"; d="scan'208";a="208547808"
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.210.2; Sat, 27 Dec 2014 20: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 1Y52GW-0005XK-5E;
	Sun, 28 Dec 2014 01:03:28 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y52GW-00071k-0S;
	Sun, 28 Dec 2014 01:03:28 +0000
Date: Sun, 28 Dec 2014 01:03:28 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32714-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] 32714: 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 32714 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32714/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)          broken pass in 32689
 test-armhf-armhf-libvirt     10 capture-logs(10)          broken pass in 32689

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Not pushing.

(No revision log; it would be 912 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 Dec 28 03:48:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 03: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 1Y54pB-0007MR-W7; Sun, 28 Dec 2014 03:47:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y54pA-0007MM-Ei
	for xen-devel@lists.xensource.com; Sun, 28 Dec 2014 03:47:24 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	FF/02-01660-A4D7F945; Sun, 28 Dec 2014 03:47:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1419738440!15374924!1
X-Originating-IP: [66.165.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 15404 invoked from network); 28 Dec 2014 03:47:21 -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;
	28 Dec 2014 03:47:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,654,1413244800"; d="scan'208";a="208566222"
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.210.2; Sat, 27 Dec 2014 22:47: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 1Y54p4-0006K2-0p;
	Sun, 28 Dec 2014 03:47:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y54p3-0004IC-S7;
	Sun, 28 Dec 2014 03:47:17 +0000
Date: Sun, 28 Dec 2014 03:47:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32719-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] 32719: 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 32719 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32719/

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           6 capture-logs(6)           broken pass in 32695
 test-armhf-armhf-libvirt      6 capture-logs(6)           broken pass in 32695

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-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail in 32695 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-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 14 guest-stop                fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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 capture-logs(6)
broken-step test-armhf-armhf-libvirt capture-logs(6)

Not pushing.

(No revision log; it would be 34929 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 Dec 28 03:48:16 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 03: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 1Y54pB-0007MR-W7; Sun, 28 Dec 2014 03:47:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y54pA-0007MM-Ei
	for xen-devel@lists.xensource.com; Sun, 28 Dec 2014 03:47:24 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	FF/02-01660-A4D7F945; Sun, 28 Dec 2014 03:47:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1419738440!15374924!1
X-Originating-IP: [66.165.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 15404 invoked from network); 28 Dec 2014 03:47:21 -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;
	28 Dec 2014 03:47:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,654,1413244800"; d="scan'208";a="208566222"
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.210.2; Sat, 27 Dec 2014 22:47: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 1Y54p4-0006K2-0p;
	Sun, 28 Dec 2014 03:47:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y54p3-0004IC-S7;
	Sun, 28 Dec 2014 03:47:17 +0000
Date: Sun, 28 Dec 2014 03:47:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32719-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] 32719: 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 32719 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32719/

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           6 capture-logs(6)           broken pass in 32695
 test-armhf-armhf-libvirt      6 capture-logs(6)           broken pass in 32695

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-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail in 32695 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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-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-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 14 guest-stop                fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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 capture-logs(6)
broken-step test-armhf-armhf-libvirt capture-logs(6)

Not pushing.

(No revision log; it would be 34929 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 Dec 28 07:51:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 07:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y58cp-0003Lz-Rb; Sun, 28 Dec 2014 07:50:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y58cn-0003Lt-NA
	for xen-devel@lists.xensource.com; Sun, 28 Dec 2014 07:50:53 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	3D/8C-02743-D56BF945; Sun, 28 Dec 2014 07:50:53 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1419753050!17442248!1
X-Originating-IP: [66.165.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 26994 invoked from network); 28 Dec 2014 07:50:52 -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 Dec 2014 07:50:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,654,1413244800"; d="scan'208";a="209142908"
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.210.2; Sun, 28 Dec 2014 02:50: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 1Y58cj-0007Xm-8u;
	Sun, 28 Dec 2014 07:50:49 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y58cj-0002Qz-3v;
	Sun, 28 Dec 2014 07:50:49 +0000
Date: Sun, 28 Dec 2014 07:50:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32754-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] 32754: 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 32754 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32754/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)          broken pass in 32689
 test-armhf-armhf-libvirt     10 capture-logs(10)          broken pass in 32689

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Not pushing.

(No revision log; it would be 912 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 Dec 28 07:51:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 07:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y58cp-0003Lz-Rb; Sun, 28 Dec 2014 07:50:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y58cn-0003Lt-NA
	for xen-devel@lists.xensource.com; Sun, 28 Dec 2014 07:50:53 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	3D/8C-02743-D56BF945; Sun, 28 Dec 2014 07:50:53 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1419753050!17442248!1
X-Originating-IP: [66.165.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 26994 invoked from network); 28 Dec 2014 07:50:52 -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 Dec 2014 07:50:52 -0000
X-IronPort-AV: E=Sophos;i="5.07,654,1413244800"; d="scan'208";a="209142908"
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.210.2; Sun, 28 Dec 2014 02:50: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 1Y58cj-0007Xm-8u;
	Sun, 28 Dec 2014 07:50:49 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y58cj-0002Qz-3v;
	Sun, 28 Dec 2014 07:50:49 +0000
Date: Sun, 28 Dec 2014 07:50:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32754-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] 32754: 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 32754 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32754/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)          broken pass in 32689
 test-armhf-armhf-libvirt     10 capture-logs(10)          broken pass in 32689

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Not pushing.

(No revision log; it would be 912 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 Dec 28 19:46:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 19:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5JmJ-00077U-FK; Sun, 28 Dec 2014 19:45: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 1Y5JmI-00077P-1C
	for xen-devel@lists.xensource.com; Sun, 28 Dec 2014 19:45:26 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	AD/92-02702-5DD50A45; Sun, 28 Dec 2014 19:45:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1419795923!17462917!1
X-Originating-IP: [66.165.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 16218 invoked from network); 28 Dec 2014 19:45:24 -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 Dec 2014 19:45:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,656,1413244800"; d="scan'208";a="208690801"
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.210.2; Sun, 28 Dec 2014 14:45: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 1Y5JmD-00036A-9X;
	Sun, 28 Dec 2014 19:45:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5JmD-000124-3B;
	Sun, 28 Dec 2014 19:45:21 +0000
Date: Sun, 28 Dec 2014 19:45:21 +0000
Message-ID: <E1Y5JmD-000124-3B@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] [qemu-mainline bisection] complete
	test-amd64-i386-qemuu-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-intel
test redhat-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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-i386-qemuu-rhel6hvm-intel.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32689 fail [host=rice-weevil] / 32598 [host=scape-moth] 32585 [host=bush-cricket] 32571 [host=grain-weevil] 32561 [host=scape-moth] 32542 [host=field-cricket] 32517 [host=bush-cricket] 32459 [host=scape-moth] 32429 [host=grain-weevil] 32418 [host=itch-mite] 32294 [host=field-cricket] 32232 [host=grain-weevil] 32194 [host=gall-mite] 32117 [host=bush-cricket] 32096 [host=worm-moth] 32029 [host=itch-mite] 31983 ok.
Failure / basis pass flights: 32689 / 31983
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 2dc2565902d3c24108c4b7101e91957fd068a242 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b19ca188022d720e6cdf87c43c27cb68bac32f6a 188336bb86d0992a2a034ece5f39eccc5d10f337
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#2dc2565902d3c24108c4b7101e91957fd068a242-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#b19ca188022d720e6cdf87c43c27cb68bac32f6a-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#188336bb86d0992a2a034ece5f39eccc5d10f337-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-pvops
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.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-pvops
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.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 10820 nodes in revision graph
Searching for test results:
 32029 [host=itch-mite]
 31983 pass 2dc2565902d3c24108c4b7101e91957fd068a242 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b19ca188022d720e6cdf87c43c27cb68bac32f6a 188336bb86d0992a2a034ece5f39eccc5d10f337
 32096 [host=worm-moth]
 32117 [host=bush-cricket]
 32194 [host=gall-mite]
 32232 [host=grain-weevil]
 32294 [host=field-cricket]
 32377 []
 32418 [host=itch-mite]
 32429 [host=grain-weevil]
 32517 [host=bush-cricket]
 32459 [host=scape-moth]
 32542 [host=field-cricket]
 32571 [host=grain-weevil]
 32561 [host=scape-moth]
 32585 [host=bush-cricket]
 32598 [host=scape-moth]
 32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32689 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32712 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ddcd55316fb2851e144e719171621ad2816487dc 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32705 pass 2dc2565902d3c24108c4b7101e91957fd068a242 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b19ca188022d720e6cdf87c43c27cb68bac32f6a 188336bb86d0992a2a034ece5f39eccc5d10f337
 32723 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 dcbfc5cefb22e9219f8253dba87de33104ca73fe 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32706 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32716 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 adee64249ee37e822d578e65a765750e7f2081f6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32709 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32726 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 dfa9c2a0f4d0a0c8b2c1449ecdbb1297427e1560 2676bc915157ab474ee478d929b0928cf696b385
 32720 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 84afc4dd56648ac302c7b5a917e95ca7b1239695 7e88c23239591e2638bcc944151a660fcd53495b
 32721 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 4db753b1ac4aedc6cd67fb13d50e5015ce8052a5 7e88c23239591e2638bcc944151a660fcd53495b
 32722 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 86b182ac0e0b44726d85598cbefb468ed22517fc 7e88c23239591e2638bcc944151a660fcd53495b
 32747 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7c3843332db39c2f27405b882a505144d62b3664 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
 32728 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 82595da8dedde128d8004ec47441aeb720c08704 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
 32733 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c4d4525c38cd93cc5d1a743976eb25ac571d435f 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
 32749 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 67a5eebca1ac15442f06096977381a70a403bc5b 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
 32753 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b141290478f847ecaa25561f3b31fbf1ddde95e6 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
 32759 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 24588100ab39afead7b9a0e9c61182a02320a1b9 d8582553aaa074c7981f84cd326f95e38625a22c
 32764 pass 3e06c8fdf30ebd0060dff15d4e50122d5d637620 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 dfa9c2a0f4d0a0c8b2c1449ecdbb1297427e1560 7e88c23239591e2638bcc944151a660fcd53495b
 32795 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32767 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32768 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 45820fccaf731a2fec5d0cb5416f944104e89373 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32772 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b5fd8fa34594da327e2965a8c3b5dddf21f862ff 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32778 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7db96d6cf877d4bb8132462ec7dd19055ff968eb 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32783 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b28fb27b5edf77f6fd0ac550a156fb20f2218db3 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32787 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32789 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32790 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32791 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32794 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 31983 (pass), for basis pass
 Result found: flight 32611 (fail), for basis failure
 Repro found: flight 32705 (pass), for basis pass
 Repro found: flight 32706 (fail), for basis failure
 0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32787 (pass), for last pass
 Result found: flight 32789 (fail), for first failure
 Repro found: flight 32790 (pass), for last pass
 Repro found: flight 32791 (fail), for first failure
 Repro found: flight 32794 (pass), for last pass
 Repro found: flight 32795 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-i386-qemuu-rhel6hvm-intel.redhat-install.{dot,ps,png,html}.
----------------------------------------
32795: tolerable ALL FAIL

flight 32795 qemu-mainline real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32795/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install  fail baseline untested


jobs:
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Dec 28 19:46:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 19:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5JmJ-00077U-FK; Sun, 28 Dec 2014 19:45: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 1Y5JmI-00077P-1C
	for xen-devel@lists.xensource.com; Sun, 28 Dec 2014 19:45:26 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	AD/92-02702-5DD50A45; Sun, 28 Dec 2014 19:45:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1419795923!17462917!1
X-Originating-IP: [66.165.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 16218 invoked from network); 28 Dec 2014 19:45:24 -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 Dec 2014 19:45:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,656,1413244800"; d="scan'208";a="208690801"
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.210.2; Sun, 28 Dec 2014 14:45: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 1Y5JmD-00036A-9X;
	Sun, 28 Dec 2014 19:45:21 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5JmD-000124-3B;
	Sun, 28 Dec 2014 19:45:21 +0000
Date: Sun, 28 Dec 2014 19:45:21 +0000
Message-ID: <E1Y5JmD-000124-3B@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] [qemu-mainline bisection] complete
	test-amd64-i386-qemuu-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-intel
test redhat-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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-i386-qemuu-rhel6hvm-intel.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32689 fail [host=rice-weevil] / 32598 [host=scape-moth] 32585 [host=bush-cricket] 32571 [host=grain-weevil] 32561 [host=scape-moth] 32542 [host=field-cricket] 32517 [host=bush-cricket] 32459 [host=scape-moth] 32429 [host=grain-weevil] 32418 [host=itch-mite] 32294 [host=field-cricket] 32232 [host=grain-weevil] 32194 [host=gall-mite] 32117 [host=bush-cricket] 32096 [host=worm-moth] 32029 [host=itch-mite] 31983 ok.
Failure / basis pass flights: 32689 / 31983
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 2dc2565902d3c24108c4b7101e91957fd068a242 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b19ca188022d720e6cdf87c43c27cb68bac32f6a 188336bb86d0992a2a034ece5f39eccc5d10f337
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#2dc2565902d3c24108c4b7101e91957fd068a242-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#b19ca188022d720e6cdf87c43c27cb68bac32f6a-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#188336bb86d0992a2a034ece5f39eccc5d10f337-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-pvops
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.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-pvops
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.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 10820 nodes in revision graph
Searching for test results:
 32029 [host=itch-mite]
 31983 pass 2dc2565902d3c24108c4b7101e91957fd068a242 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b19ca188022d720e6cdf87c43c27cb68bac32f6a 188336bb86d0992a2a034ece5f39eccc5d10f337
 32096 [host=worm-moth]
 32117 [host=bush-cricket]
 32194 [host=gall-mite]
 32232 [host=grain-weevil]
 32294 [host=field-cricket]
 32377 []
 32418 [host=itch-mite]
 32429 [host=grain-weevil]
 32517 [host=bush-cricket]
 32459 [host=scape-moth]
 32542 [host=field-cricket]
 32571 [host=grain-weevil]
 32561 [host=scape-moth]
 32585 [host=bush-cricket]
 32598 [host=scape-moth]
 32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32689 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32712 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ddcd55316fb2851e144e719171621ad2816487dc 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32705 pass 2dc2565902d3c24108c4b7101e91957fd068a242 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b19ca188022d720e6cdf87c43c27cb68bac32f6a 188336bb86d0992a2a034ece5f39eccc5d10f337
 32723 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 dcbfc5cefb22e9219f8253dba87de33104ca73fe 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32706 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32716 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 adee64249ee37e822d578e65a765750e7f2081f6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32709 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c95f3901b4ead79f3fe2c641fda7d2c70fc84c72 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32726 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 dfa9c2a0f4d0a0c8b2c1449ecdbb1297427e1560 2676bc915157ab474ee478d929b0928cf696b385
 32720 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 84afc4dd56648ac302c7b5a917e95ca7b1239695 7e88c23239591e2638bcc944151a660fcd53495b
 32721 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 4db753b1ac4aedc6cd67fb13d50e5015ce8052a5 7e88c23239591e2638bcc944151a660fcd53495b
 32722 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 86b182ac0e0b44726d85598cbefb468ed22517fc 7e88c23239591e2638bcc944151a660fcd53495b
 32747 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7c3843332db39c2f27405b882a505144d62b3664 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
 32728 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 82595da8dedde128d8004ec47441aeb720c08704 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
 32733 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 c4d4525c38cd93cc5d1a743976eb25ac571d435f 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
 32749 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 67a5eebca1ac15442f06096977381a70a403bc5b 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
 32753 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b141290478f847ecaa25561f3b31fbf1ddde95e6 60ce518a1b1caf2c1e4c1b203e87fb0b179ba687
 32759 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 24588100ab39afead7b9a0e9c61182a02320a1b9 d8582553aaa074c7981f84cd326f95e38625a22c
 32764 pass 3e06c8fdf30ebd0060dff15d4e50122d5d637620 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 dfa9c2a0f4d0a0c8b2c1449ecdbb1297427e1560 7e88c23239591e2638bcc944151a660fcd53495b
 32795 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32767 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32768 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 45820fccaf731a2fec5d0cb5416f944104e89373 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32772 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b5fd8fa34594da327e2965a8c3b5dddf21f862ff 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32778 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7db96d6cf877d4bb8132462ec7dd19055ff968eb 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32783 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b28fb27b5edf77f6fd0ac550a156fb20f2218db3 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32787 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32789 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32790 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32791 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32794 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 31983 (pass), for basis pass
 Result found: flight 32611 (fail), for basis failure
 Repro found: flight 32705 (pass), for basis pass
 Repro found: flight 32706 (fail), for basis failure
 0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32787 (pass), for last pass
 Result found: flight 32789 (fail), for first failure
 Repro found: flight 32790 (pass), for last pass
 Repro found: flight 32791 (fail), for first failure
 Repro found: flight 32794 (pass), for last pass
 Repro found: flight 32795 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-i386-qemuu-rhel6hvm-intel.redhat-install.{dot,ps,png,html}.
----------------------------------------
32795: tolerable ALL FAIL

flight 32795 qemu-mainline real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32795/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install  fail baseline untested


jobs:
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Dec 28 19:53:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 19:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5JtN-0007OI-GI; Sun, 28 Dec 2014 19:52: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 1Y5JtL-0007OA-AJ
	for xen-devel@lists.xensource.com; Sun, 28 Dec 2014 19:52:43 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	D0/16-05632-A8F50A45; Sun, 28 Dec 2014 19:52:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419796360!16153742!1
X-Originating-IP: [66.165.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 16458 invoked from network); 28 Dec 2014 19:52:41 -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 Dec 2014 19:52:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,656,1413244800"; d="scan'208";a="208691793"
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.210.2; Sun, 28 Dec 2014 14:52: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 1Y5JtH-00038N-BZ;
	Sun, 28 Dec 2014 19:52:39 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5JtH-0002nX-6d;
	Sun, 28 Dec 2014 19:52:39 +0000
Date: Sun, 28 Dec 2014 19:52:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32758-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] 32758: 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 32758 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32758/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)             broken like 32707
 test-armhf-armhf-libvirt     10 capture-logs(10)             broken like 32707
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32707

Tests which did not succeed, but are not blocking:
 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-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-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-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-winxpsp3 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-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 28 19:53:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 19:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5JtN-0007OI-GI; Sun, 28 Dec 2014 19:52: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 1Y5JtL-0007OA-AJ
	for xen-devel@lists.xensource.com; Sun, 28 Dec 2014 19:52:43 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	D0/16-05632-A8F50A45; Sun, 28 Dec 2014 19:52:42 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419796360!16153742!1
X-Originating-IP: [66.165.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 16458 invoked from network); 28 Dec 2014 19:52:41 -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 Dec 2014 19:52:41 -0000
X-IronPort-AV: E=Sophos;i="5.07,656,1413244800"; d="scan'208";a="208691793"
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.210.2; Sun, 28 Dec 2014 14:52: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 1Y5JtH-00038N-BZ;
	Sun, 28 Dec 2014 19:52:39 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5JtH-0002nX-6d;
	Sun, 28 Dec 2014 19:52:39 +0000
Date: Sun, 28 Dec 2014 19:52:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32758-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] 32758: 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 32758 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32758/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)             broken like 32707
 test-armhf-armhf-libvirt     10 capture-logs(10)             broken like 32707
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32707

Tests which did not succeed, but are not blocking:
 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-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-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-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-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-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-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-winxpsp3 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-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Dec 28 20:20:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 20:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5KJa-0007tz-TN; Sun, 28 Dec 2014 20:19:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y5KJZ-0007tu-JD
	for xen-devel@lists.xen.org; Sun, 28 Dec 2014 20:19:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	23/2F-09842-4E560A45; Sun, 28 Dec 2014 20:19:48 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419797985!18188763!1
X-Originating-IP: [209.85.214.174]
X-SpamReason: No, hits=2.6 required=7.0 tests=BIZ_TLD,HTML_40_50,
	HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15831 invoked from network); 28 Dec 2014 20:19:46 -0000
Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com)
	(209.85.214.174)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2014 20:19:46 -0000
Received: by mail-ob0-f174.google.com with SMTP id nt9so43387315obb.5
	for <xen-devel@lists.xen.org>; Sun, 28 Dec 2014 12:19:45 -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=sxmYgdrYlQa0a2NALRJRukaPIr18GOqajL9TpzxSxn8=;
	b=N9d0BB5rvYUAWDcTtZXknWVPDNtnxNWBezC+sXEuPwk9oCsOA30ZGsn050QrEFXSS6
	mf3bgM96ETPEBF3KpCucB8KZ8Er5YvtY9iK0taOdNth2O1plApSM+R7WskyP6ibpAA1z
	HaIQ2szfkeiyoYVl8DbFZ4BpEPQymeqAYAOXU+gR9H8zMLAr6hxPvvymU79VeyfbWmXp
	MC/z2PrxCO0PO5WsXH2R0qEMzeLoKVn8a29WSxvZ4GA7Z7z0F1OaeXLWiGqVykAAnwpY
	NUpU+XwZbVkHGZ7F0/Exp4HpR4VyOOYYrL88TmcgFYGIpSKBFYp9R8jyBSWmsvdM8qns
	NwUg==
MIME-Version: 1.0
X-Received: by 10.60.120.36 with SMTP id kz4mr15729053oeb.80.1419797985497;
	Sun, 28 Dec 2014 12:19:45 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Sun, 28 Dec 2014 12:19:45 -0800 (PST)
In-Reply-To: <CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
	<549EBDCC.3090102@m2r.biz>
	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
Date: Sun, 28 Dec 2014 21:19:45 +0100
Message-ID: <CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7815088092279102118=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7815088092279102118==
Content-Type: multipart/alternative; boundary=047d7b3393419418f4050b4c7ae3

--047d7b3393419418f4050b4c7ae3
Content-Type: text/plain; charset=UTF-8

Trying to compile xen 4.5RC4 in order to test your patch I end up with
these errors compiling the Seabios directories,

any idea?

  Compiling to assembler out/src/asm-offsets.s
  Generating offset file out/asm-offsets.h
  Compiling (16bit) out/romlayout.o
  Building ld scripts
Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
Traceback (most recent call last):
  File "./scripts/layoutrom.py", line 709, in <module>
    main()
  File "./scripts/layoutrom.py", line 671, in main
    info16 = parseObjDump(infile16, '16')
  File "./scripts/layoutrom.py", line 586, in parseObjDump
    relocsection = sectionmap[sectionname]
KeyError:
'.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
Makefile:155: recipe for target 'out/romlayout16.lds' failed
make[6]: *** [out/romlayout16.lds] Error 1
make[6]: Leaving directory
'/home/goon/xen/tools/firmware/seabios-dir-remote'
/home/goon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for target
'subdir-all-seabios-dir' failed



2014-12-27 17:35 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:

> Hello Fabio,
>
> Sure thing I will help debug the win7 and the win8 versions.
> Where to start?
>
> I'll try to see if I can patch with patch from
> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
> and if not will post result.
>
>
> best regards,
>
>
> greg Bahde
>
> 2014-12-27 15:10 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:
>
>>
>> Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>
>>   I tried to install Qxl drivers under win7/win 2k8/win8.1
>> all       x64 versions, without any luck.
>>
>>
>> admin message is as follow:
>> Driver Management concluded the process to install driver
>> FileRepository\qxl.inf_amd64_
>> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
>> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
>> following status: 0xe000022d.
>>
>>
>>
>>
>>  Does
>> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>
>>  can it be installed on my xen stack?
>>
>>
>> Yes but probably require a small refresh, I always posted the patch based
>> on updated xen-unstable.
>>
>> Here qxl patch refreshed for xen 4.5 if needed:
>>
>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>
>> Here the latest spice guest tools for windows with qxl driver included:
>>
>> http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>>
>> Windows >=8 and similar require a new qxl drivers, there are a beta build
>> but latest tried some months ago have serious bug and I not found recent
>> build full working on windows 8.
>>
>> On xen windows 7 domUs qxl works good except a problem after save/restore
>> and on linux domUs is not working, for now I not found exactly cause and
>> solution.
>> On mailing list up to 2 years ago you can find many my mails about.
>> Any help to test it is appreciated.
>>
>> Sorry for my bad english.
>>
>>
>> Also, can  I get invited at xendevel irc ?
>> regards
>>
>>  Greg
>>
>>
>> _______________________________________________
>> Xen-devel mailing listXen-devel@lists.xen.orghttp://lists.xen.org/xen-devel
>>
>>
>>
>

--047d7b3393419418f4050b4c7ae3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Trying to compile xen 4.5RC4 in order to test your pa=
tch I end up with=C2=A0 these errors compiling the Seabios directories,<br>=
<br></div>any idea?<br><br>=C2=A0 Compiling to assembler out/src/asm-offset=
s.s<br>=C2=A0 Generating offset file out/asm-offsets.h<br>=C2=A0 Compiling =
(16bit) out/romlayout.o<br>=C2=A0 Building ld scripts<br>Version: rel-1.7.5=
-0-ge51488c-20141228_210340-E766<br>Traceback (most recent call last):<br>=
=C2=A0 File &quot;./scripts/layoutrom.py&quot;, line 709, in &lt;module&gt;=
<br>=C2=A0=C2=A0=C2=A0 main()<br>=C2=A0 File &quot;./scripts/layoutrom.py&q=
uot;, line 671, in main<br>=C2=A0=C2=A0=C2=A0 info16 =3D parseObjDump(infil=
e16, &#39;16&#39;)<br>=C2=A0 File &quot;./scripts/layoutrom.py&quot;, line =
586, in parseObjDump<br>=C2=A0=C2=A0=C2=A0 relocsection =3D sectionmap[sect=
ionname]<br>KeyError: &#39;.text.asm./home/goon/xen/tools/firmware/seabios-=
dir-remote/src/fw/smp.c.79&#39;<br>Makefile:155: recipe for target &#39;out=
/romlayout16.lds&#39; failed<br>make[6]: *** [out/romlayout16.lds] Error 1<=
br>make[6]: Leaving directory &#39;/home/goon/xen/tools/firmware/seabios-di=
r-remote&#39;<br>/home/goon/xen/tools/firmware/../../tools/Rules.mk:116: re=
cipe for target &#39;subdir-all-seabios-dir&#39; failed<br><br><br></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-12-27 17:35 GM=
T+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.gooni=
e@gmail.com" target=3D"_blank">monsieur.goonie@gmail.com</a>&gt;</span>:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>Hello Fabio=
,<br><br>Sure thing I will help debug the win7 and the win8 versions.<br></=
div>Where to start?<br><br></div>I&#39;ll try to see if I can patch with pa=
tch from <a href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e42=
1fafba67aa11879e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commi=
t/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a> and if not will post result.=
<br><br><br>best regards,<br><br><br></div>greg Bahde<br></div><div class=
=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">2014-12-27 15:10 GMT+01:00 Fabio Fantoni <span dir=3D"ltr">&lt=
;<a href=3D"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">fabio.fantoni@m=
2r.biz</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">
    <br>
    <div>Il 27/12/2014 02:15, Goonie Windy ha
      scritto:<br>
    </div><span>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>I tried to install Qxl drivers under win7/win
              2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 al=
l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64 versions, without any
              luck.<br>
              <br>
              <br>
              admin message is as follow:<br>
              Driver Management concluded the process to install driver
              FileRepository\qxl.inf_amd64_
              <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf for Device
                Instance ID
                PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&=
amp;267A616A&amp;1&amp;28
                with the following status: 0xe000022d.</div>
              <br>
              <br>
              <br>
              <br>
            </div>
            Does <br>
            <a href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05=
/msg03214.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-de=
vel/2014-05/msg03214.html</a><br>
            <br>
          </div>
          can it be installed on my xen stack? <br>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes but probably require a small refresh, I always posted the patch
    based on updated xen-unstable. <br>
    <br>
    Here qxl patch refreshed for xen 4.5 if needed:<br>
<a href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67a=
a11879e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8=
d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
    <br>
    Here the latest spice guest tools for windows with qxl driver
    included:<br>
<a href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/s=
pice-guest-tools-0.74.exe" target=3D"_blank">http://www.spice-space.org/dow=
nload/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
    <br>
    Windows &gt;=3D8 and similar require a new qxl drivers, there are a
    beta build but latest tried some months ago have serious bug and I
    not found recent build full working on windows 8.<br>
    <br>
    On xen windows 7 domUs qxl works good except a problem after
    save/restore and on linux domUs is not working, for now I not found
    exactly cause and solution.<br>
    On mailing list up to 2 years ago you can find many my mails about.<br>
    Any help to test it is appreciated.<br>
    <br>
    Sorry for my bad english.<br>
    <br>
    <blockquote type=3D"cite"><span>
      <div dir=3D"ltr">
        <div><br>
          Also, can=C2=A0 I get invited at xendevel irc ?<br>
          regards<br>
          <br>
        </div>
        Greg <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><pre>_______________________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--047d7b3393419418f4050b4c7ae3--


--===============7815088092279102118==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7815088092279102118==--


From xen-devel-bounces@lists.xen.org Sun Dec 28 20:20:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 20:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5KJa-0007tz-TN; Sun, 28 Dec 2014 20:19:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y5KJZ-0007tu-JD
	for xen-devel@lists.xen.org; Sun, 28 Dec 2014 20:19:49 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	23/2F-09842-4E560A45; Sun, 28 Dec 2014 20:19:48 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1419797985!18188763!1
X-Originating-IP: [209.85.214.174]
X-SpamReason: No, hits=2.6 required=7.0 tests=BIZ_TLD,HTML_40_50,
	HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15831 invoked from network); 28 Dec 2014 20:19:46 -0000
Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com)
	(209.85.214.174)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Dec 2014 20:19:46 -0000
Received: by mail-ob0-f174.google.com with SMTP id nt9so43387315obb.5
	for <xen-devel@lists.xen.org>; Sun, 28 Dec 2014 12:19:45 -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=sxmYgdrYlQa0a2NALRJRukaPIr18GOqajL9TpzxSxn8=;
	b=N9d0BB5rvYUAWDcTtZXknWVPDNtnxNWBezC+sXEuPwk9oCsOA30ZGsn050QrEFXSS6
	mf3bgM96ETPEBF3KpCucB8KZ8Er5YvtY9iK0taOdNth2O1plApSM+R7WskyP6ibpAA1z
	HaIQ2szfkeiyoYVl8DbFZ4BpEPQymeqAYAOXU+gR9H8zMLAr6hxPvvymU79VeyfbWmXp
	MC/z2PrxCO0PO5WsXH2R0qEMzeLoKVn8a29WSxvZ4GA7Z7z0F1OaeXLWiGqVykAAnwpY
	NUpU+XwZbVkHGZ7F0/Exp4HpR4VyOOYYrL88TmcgFYGIpSKBFYp9R8jyBSWmsvdM8qns
	NwUg==
MIME-Version: 1.0
X-Received: by 10.60.120.36 with SMTP id kz4mr15729053oeb.80.1419797985497;
	Sun, 28 Dec 2014 12:19:45 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Sun, 28 Dec 2014 12:19:45 -0800 (PST)
In-Reply-To: <CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
	<549EBDCC.3090102@m2r.biz>
	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
Date: Sun, 28 Dec 2014 21:19:45 +0100
Message-ID: <CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7815088092279102118=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7815088092279102118==
Content-Type: multipart/alternative; boundary=047d7b3393419418f4050b4c7ae3

--047d7b3393419418f4050b4c7ae3
Content-Type: text/plain; charset=UTF-8

Trying to compile xen 4.5RC4 in order to test your patch I end up with
these errors compiling the Seabios directories,

any idea?

  Compiling to assembler out/src/asm-offsets.s
  Generating offset file out/asm-offsets.h
  Compiling (16bit) out/romlayout.o
  Building ld scripts
Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
Traceback (most recent call last):
  File "./scripts/layoutrom.py", line 709, in <module>
    main()
  File "./scripts/layoutrom.py", line 671, in main
    info16 = parseObjDump(infile16, '16')
  File "./scripts/layoutrom.py", line 586, in parseObjDump
    relocsection = sectionmap[sectionname]
KeyError:
'.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
Makefile:155: recipe for target 'out/romlayout16.lds' failed
make[6]: *** [out/romlayout16.lds] Error 1
make[6]: Leaving directory
'/home/goon/xen/tools/firmware/seabios-dir-remote'
/home/goon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for target
'subdir-all-seabios-dir' failed



2014-12-27 17:35 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:

> Hello Fabio,
>
> Sure thing I will help debug the win7 and the win8 versions.
> Where to start?
>
> I'll try to see if I can patch with patch from
> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
> and if not will post result.
>
>
> best regards,
>
>
> greg Bahde
>
> 2014-12-27 15:10 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:
>
>>
>> Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>
>>   I tried to install Qxl drivers under win7/win 2k8/win8.1
>> all       x64 versions, without any luck.
>>
>>
>> admin message is as follow:
>> Driver Management concluded the process to install driver
>> FileRepository\qxl.inf_amd64_
>> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
>> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
>> following status: 0xe000022d.
>>
>>
>>
>>
>>  Does
>> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>
>>  can it be installed on my xen stack?
>>
>>
>> Yes but probably require a small refresh, I always posted the patch based
>> on updated xen-unstable.
>>
>> Here qxl patch refreshed for xen 4.5 if needed:
>>
>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>
>> Here the latest spice guest tools for windows with qxl driver included:
>>
>> http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>>
>> Windows >=8 and similar require a new qxl drivers, there are a beta build
>> but latest tried some months ago have serious bug and I not found recent
>> build full working on windows 8.
>>
>> On xen windows 7 domUs qxl works good except a problem after save/restore
>> and on linux domUs is not working, for now I not found exactly cause and
>> solution.
>> On mailing list up to 2 years ago you can find many my mails about.
>> Any help to test it is appreciated.
>>
>> Sorry for my bad english.
>>
>>
>> Also, can  I get invited at xendevel irc ?
>> regards
>>
>>  Greg
>>
>>
>> _______________________________________________
>> Xen-devel mailing listXen-devel@lists.xen.orghttp://lists.xen.org/xen-devel
>>
>>
>>
>

--047d7b3393419418f4050b4c7ae3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Trying to compile xen 4.5RC4 in order to test your pa=
tch I end up with=C2=A0 these errors compiling the Seabios directories,<br>=
<br></div>any idea?<br><br>=C2=A0 Compiling to assembler out/src/asm-offset=
s.s<br>=C2=A0 Generating offset file out/asm-offsets.h<br>=C2=A0 Compiling =
(16bit) out/romlayout.o<br>=C2=A0 Building ld scripts<br>Version: rel-1.7.5=
-0-ge51488c-20141228_210340-E766<br>Traceback (most recent call last):<br>=
=C2=A0 File &quot;./scripts/layoutrom.py&quot;, line 709, in &lt;module&gt;=
<br>=C2=A0=C2=A0=C2=A0 main()<br>=C2=A0 File &quot;./scripts/layoutrom.py&q=
uot;, line 671, in main<br>=C2=A0=C2=A0=C2=A0 info16 =3D parseObjDump(infil=
e16, &#39;16&#39;)<br>=C2=A0 File &quot;./scripts/layoutrom.py&quot;, line =
586, in parseObjDump<br>=C2=A0=C2=A0=C2=A0 relocsection =3D sectionmap[sect=
ionname]<br>KeyError: &#39;.text.asm./home/goon/xen/tools/firmware/seabios-=
dir-remote/src/fw/smp.c.79&#39;<br>Makefile:155: recipe for target &#39;out=
/romlayout16.lds&#39; failed<br>make[6]: *** [out/romlayout16.lds] Error 1<=
br>make[6]: Leaving directory &#39;/home/goon/xen/tools/firmware/seabios-di=
r-remote&#39;<br>/home/goon/xen/tools/firmware/../../tools/Rules.mk:116: re=
cipe for target &#39;subdir-all-seabios-dir&#39; failed<br><br><br></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-12-27 17:35 GM=
T+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.gooni=
e@gmail.com" target=3D"_blank">monsieur.goonie@gmail.com</a>&gt;</span>:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>Hello Fabio=
,<br><br>Sure thing I will help debug the win7 and the win8 versions.<br></=
div>Where to start?<br><br></div>I&#39;ll try to see if I can patch with pa=
tch from <a href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e42=
1fafba67aa11879e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commi=
t/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a> and if not will post result.=
<br><br><br>best regards,<br><br><br></div>greg Bahde<br></div><div class=
=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">2014-12-27 15:10 GMT+01:00 Fabio Fantoni <span dir=3D"ltr">&lt=
;<a href=3D"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">fabio.fantoni@m=
2r.biz</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">
    <br>
    <div>Il 27/12/2014 02:15, Goonie Windy ha
      scritto:<br>
    </div><span>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>I tried to install Qxl drivers under win7/win
              2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 al=
l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64 versions, without any
              luck.<br>
              <br>
              <br>
              admin message is as follow:<br>
              Driver Management concluded the process to install driver
              FileRepository\qxl.inf_amd64_
              <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf for Device
                Instance ID
                PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&=
amp;267A616A&amp;1&amp;28
                with the following status: 0xe000022d.</div>
              <br>
              <br>
              <br>
              <br>
            </div>
            Does <br>
            <a href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05=
/msg03214.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-de=
vel/2014-05/msg03214.html</a><br>
            <br>
          </div>
          can it be installed on my xen stack? <br>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes but probably require a small refresh, I always posted the patch
    based on updated xen-unstable. <br>
    <br>
    Here qxl patch refreshed for xen 4.5 if needed:<br>
<a href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67a=
a11879e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8=
d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
    <br>
    Here the latest spice guest tools for windows with qxl driver
    included:<br>
<a href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/s=
pice-guest-tools-0.74.exe" target=3D"_blank">http://www.spice-space.org/dow=
nload/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
    <br>
    Windows &gt;=3D8 and similar require a new qxl drivers, there are a
    beta build but latest tried some months ago have serious bug and I
    not found recent build full working on windows 8.<br>
    <br>
    On xen windows 7 domUs qxl works good except a problem after
    save/restore and on linux domUs is not working, for now I not found
    exactly cause and solution.<br>
    On mailing list up to 2 years ago you can find many my mails about.<br>
    Any help to test it is appreciated.<br>
    <br>
    Sorry for my bad english.<br>
    <br>
    <blockquote type=3D"cite"><span>
      <div dir=3D"ltr">
        <div><br>
          Also, can=C2=A0 I get invited at xendevel irc ?<br>
          regards<br>
          <br>
        </div>
        Greg <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><pre>_______________________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--047d7b3393419418f4050b4c7ae3--


--===============7815088092279102118==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7815088092279102118==--


From xen-devel-bounces@lists.xen.org Sun Dec 28 22:04:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 22:04:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5LwF-0001LG-8r; Sun, 28 Dec 2014 22:03: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 1Y5LwD-0001LB-Vz
	for xen-devel@lists.xensource.com; Sun, 28 Dec 2014 22:03:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	29/33-09842-54E70A45; Sun, 28 Dec 2014 22:03:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1419804227!18213930!1
X-Originating-IP: [66.165.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 8150 invoked from network); 28 Dec 2014 22:03:48 -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 Dec 2014 22:03:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,657,1413244800"; d="scan'208";a="209260586"
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.210.2; Sun, 28 Dec 2014 17: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 1Y5LwA-0003lB-1o;
	Sun, 28 Dec 2014 22:03:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5Lw9-00030X-Sk;
	Sun, 28 Dec 2014 22:03:45 +0000
Date: Sun, 28 Dec 2014 22:03:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32761-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] 32761: 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 32761 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32761/

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 32719
 test-armhf-armhf-libvirt      6 capture-logs(6)           broken pass in 32695
 test-armhf-armhf-xl           6 capture-logs(6)  broken in 32719 pass in 32695

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           4 capture-logs(4)        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-i386-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail in 32695 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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 14 guest-stop                fail never pass
 test-armhf-armhf-xl           5 xen-boot              fail in 32719 never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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)
broken-step test-armhf-armhf-xl capture-logs(4)
broken-step test-armhf-armhf-libvirt capture-logs(6)

Not pushing.

(No revision log; it would be 34929 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 Dec 28 22:04:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Dec 2014 22:04:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5LwF-0001LG-8r; Sun, 28 Dec 2014 22:03: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 1Y5LwD-0001LB-Vz
	for xen-devel@lists.xensource.com; Sun, 28 Dec 2014 22:03:50 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	29/33-09842-54E70A45; Sun, 28 Dec 2014 22:03:49 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1419804227!18213930!1
X-Originating-IP: [66.165.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 8150 invoked from network); 28 Dec 2014 22:03:48 -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 Dec 2014 22:03:48 -0000
X-IronPort-AV: E=Sophos;i="5.07,657,1413244800"; d="scan'208";a="209260586"
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.210.2; Sun, 28 Dec 2014 17: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 1Y5LwA-0003lB-1o;
	Sun, 28 Dec 2014 22:03:46 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5Lw9-00030X-Sk;
	Sun, 28 Dec 2014 22:03:45 +0000
Date: Sun, 28 Dec 2014 22:03:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32761-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] 32761: 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 32761 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32761/

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 32719
 test-armhf-armhf-libvirt      6 capture-logs(6)           broken pass in 32695
 test-armhf-armhf-xl           6 capture-logs(6)  broken in 32719 pass in 32695

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl           4 capture-logs(4)        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-i386-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail in 32695 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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 14 guest-stop                fail never pass
 test-armhf-armhf-xl           5 xen-boot              fail in 32719 never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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)
broken-step test-armhf-armhf-xl capture-logs(4)
broken-step test-armhf-armhf-libvirt capture-logs(6)

Not pushing.

(No revision log; it would be 34929 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 Dec 29 00:21:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 00: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 1Y5O4Z-0003wG-TF; Mon, 29 Dec 2014 00:20:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y5O4Y-0003wB-Gv
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 00:20:34 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	03/C9-15461-15E90A45; Mon, 29 Dec 2014 00:20:33 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1419812430!18138215!1
X-Originating-IP: [209.85.214.177]
X-SpamReason: No, hits=2.6 required=7.0 tests=BIZ_TLD,HTML_40_50,
	HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9231 invoked from network); 29 Dec 2014 00:20:31 -0000
Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com)
	(209.85.214.177)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2014 00:20:31 -0000
Received: by mail-ob0-f177.google.com with SMTP id va2so38831887obc.8
	for <xen-devel@lists.xen.org>; Sun, 28 Dec 2014 16:20: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=cDaBPANNLB7jEFLHqcQGHXxfTZGwbGedPHlQkfQg1dY=;
	b=WunYnWfvrI/pTJxqe7/D7cDL9Xa+sNkMCQoCSaVrJ2axjxS8JhNuUDeeqJaUvdq2kc
	bdwSeAI3XSjbOR4e2tdmXpMM71MmozLUSHg8xHqanxpxghvffyQDSVaJz1Hg7z/vnV7Q
	PdZwC8WBnStIL2S7lNru+A9dgeWJQq/hCizlMXWa43vO7VVwJGwawu/gJzcTq50shMZV
	eW/T7pdSATQAMFvnZt6Rt90Zwxf/sE3abgL9RkE9bPiTEk77rloHv5hR/OI27hk0I0I6
	n+Rlm/vMkCOGl5rkHXy6RWIJsJT/bX6GBLsc+nNmAJJwVgnIRAf1EOReIMLsxxrPMTBc
	iOIA==
MIME-Version: 1.0
X-Received: by 10.202.53.139 with SMTP id c133mr5961982oia.109.1419812429887; 
	Sun, 28 Dec 2014 16:20:29 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Sun, 28 Dec 2014 16:20:29 -0800 (PST)
In-Reply-To: <CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
	<549EBDCC.3090102@m2r.biz>
	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
	<CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>
Date: Mon, 29 Dec 2014 01:20:29 +0100
Message-ID: <CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5309979415804865274=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5309979415804865274==
Content-Type: multipart/alternative; boundary=001a113cf3e0880040050b4fd7ed

--001a113cf3e0880040050b4fd7ed
Content-Type: text/plain; charset=UTF-8

well figured out it is because you have to "enforce" locale:  export
LC_ALL=en_US.utf-8 if keyboard mapping is else

2014-12-28 21:19 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:

> Trying to compile xen 4.5RC4 in order to test your patch I end up with
> these errors compiling the Seabios directories,
>
> any idea?
>
>   Compiling to assembler out/src/asm-offsets.s
>   Generating offset file out/asm-offsets.h
>   Compiling (16bit) out/romlayout.o
>   Building ld scripts
> Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
> Traceback (most recent call last):
>   File "./scripts/layoutrom.py", line 709, in <module>
>     main()
>   File "./scripts/layoutrom.py", line 671, in main
>     info16 = parseObjDump(infile16, '16')
>   File "./scripts/layoutrom.py", line 586, in parseObjDump
>     relocsection = sectionmap[sectionname]
> KeyError:
> '.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
> Makefile:155: recipe for target 'out/romlayout16.lds' failed
> make[6]: *** [out/romlayout16.lds] Error 1
> make[6]: Leaving directory
> '/home/goon/xen/tools/firmware/seabios-dir-remote'
> /home/goon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for target
> 'subdir-all-seabios-dir' failed
>
>
>
> 2014-12-27 17:35 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>
>> Hello Fabio,
>>
>> Sure thing I will help debug the win7 and the win8 versions.
>> Where to start?
>>
>> I'll try to see if I can patch with patch from
>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>> and if not will post result.
>>
>>
>> best regards,
>>
>>
>> greg Bahde
>>
>> 2014-12-27 15:10 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:
>>
>>>
>>> Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>>
>>>   I tried to install Qxl drivers under win7/win 2k8/win8.1
>>> all       x64 versions, without any luck.
>>>
>>>
>>> admin message is as follow:
>>> Driver Management concluded the process to install driver
>>> FileRepository\qxl.inf_amd64_
>>> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
>>> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
>>> following status: 0xe000022d.
>>>
>>>
>>>
>>>
>>>  Does
>>> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>>
>>>  can it be installed on my xen stack?
>>>
>>>
>>> Yes but probably require a small refresh, I always posted the patch
>>> based on updated xen-unstable.
>>>
>>> Here qxl patch refreshed for xen 4.5 if needed:
>>>
>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>>
>>> Here the latest spice guest tools for windows with qxl driver included:
>>>
>>> http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>>>
>>> Windows >=8 and similar require a new qxl drivers, there are a beta
>>> build but latest tried some months ago have serious bug and I not found
>>> recent build full working on windows 8.
>>>
>>> On xen windows 7 domUs qxl works good except a problem after
>>> save/restore and on linux domUs is not working, for now I not found exactly
>>> cause and solution.
>>> On mailing list up to 2 years ago you can find many my mails about.
>>> Any help to test it is appreciated.
>>>
>>> Sorry for my bad english.
>>>
>>>
>>> Also, can  I get invited at xendevel irc ?
>>> regards
>>>
>>>  Greg
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing listXen-devel@lists.xen.orghttp://lists.xen.org/xen-devel
>>>
>>>
>>>
>>
>

--001a113cf3e0880040050b4fd7ed
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>well figured out it is because you have to &quot;enfo=
rce&quot; locale:=C2=A0 export LC_ALL=3Den_US.utf-8 if keyboard mapping is =
else<br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">2014-12-28 21:19 GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=3D=
"mailto:monsieur.goonie@gmail.com" target=3D"_blank">monsieur.goonie@gmail.=
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 dir=3D"ltr"><div=
>Trying to compile xen 4.5RC4 in order to test your patch I end up with=C2=
=A0 these errors compiling the Seabios directories,<br><br></div>any idea?<=
br><br>=C2=A0 Compiling to assembler out/src/asm-offsets.s<br>=C2=A0 Genera=
ting offset file out/asm-offsets.h<br>=C2=A0 Compiling (16bit) out/romlayou=
t.o<br>=C2=A0 Building ld scripts<br>Version: rel-1.7.5-0-ge51488c-20141228=
_210340-E766<br>Traceback (most recent call last):<br>=C2=A0 File &quot;./s=
cripts/layoutrom.py&quot;, line 709, in &lt;module&gt;<br>=C2=A0=C2=A0=C2=
=A0 main()<br>=C2=A0 File &quot;./scripts/layoutrom.py&quot;, line 671, in =
main<br>=C2=A0=C2=A0=C2=A0 info16 =3D parseObjDump(infile16, &#39;16&#39;)<=
br>=C2=A0 File &quot;./scripts/layoutrom.py&quot;, line 586, in parseObjDum=
p<br>=C2=A0=C2=A0=C2=A0 relocsection =3D sectionmap[sectionname]<br>KeyErro=
r: &#39;.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/s=
mp.c.79&#39;<br>Makefile:155: recipe for target &#39;out/romlayout16.lds&#3=
9; failed<br>make[6]: *** [out/romlayout16.lds] Error 1<br>make[6]: Leaving=
 directory &#39;/home/goon/xen/tools/firmware/seabios-dir-remote&#39;<br>/h=
ome/goon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for target &#3=
9;subdir-all-seabios-dir&#39; failed<br><br><br></div><div class=3D"HOEnZb"=
><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">2014-12-27 17:35 GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=3D"=
mailto:monsieur.goonie@gmail.com" target=3D"_blank">monsieur.goonie@gmail.c=
om</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 dir=3D"ltr"><div>=
<div><div>Hello Fabio,<br><br>Sure thing I will help debug the win7 and the=
 win8 versions.<br></div>Where to start?<br><br></div>I&#39;ll try to see i=
f I can patch with patch from <a href=3D"https://github.com/Fantu/Xen/commi=
t/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe" target=3D"_blank">https://githu=
b.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a> and if =
not will post result.<br><br><br>best regards,<br><br><br></div>greg Bahde<=
br></div><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">2014-12-27 15:10 GMT+01:00 Fabio Fantoni <span dir=3D"ltr">&lt;<a href=3D=
"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">fabio.fantoni@m2r.biz</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">
    <br>
    <div>Il 27/12/2014 02:15, Goonie Windy ha
      scritto:<br>
    </div><span>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>I tried to install Qxl drivers under win7/win
              2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 al=
l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64 versions, without any
              luck.<br>
              <br>
              <br>
              admin message is as follow:<br>
              Driver Management concluded the process to install driver
              FileRepository\qxl.inf_amd64_
              <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf for Device
                Instance ID
                PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&=
amp;267A616A&amp;1&amp;28
                with the following status: 0xe000022d.</div>
              <br>
              <br>
              <br>
              <br>
            </div>
            Does <br>
            <a href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05=
/msg03214.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-de=
vel/2014-05/msg03214.html</a><br>
            <br>
          </div>
          can it be installed on my xen stack? <br>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes but probably require a small refresh, I always posted the patch
    based on updated xen-unstable. <br>
    <br>
    Here qxl patch refreshed for xen 4.5 if needed:<br>
<a href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67a=
a11879e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8=
d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
    <br>
    Here the latest spice guest tools for windows with qxl driver
    included:<br>
<a href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/s=
pice-guest-tools-0.74.exe" target=3D"_blank">http://www.spice-space.org/dow=
nload/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
    <br>
    Windows &gt;=3D8 and similar require a new qxl drivers, there are a
    beta build but latest tried some months ago have serious bug and I
    not found recent build full working on windows 8.<br>
    <br>
    On xen windows 7 domUs qxl works good except a problem after
    save/restore and on linux domUs is not working, for now I not found
    exactly cause and solution.<br>
    On mailing list up to 2 years ago you can find many my mails about.<br>
    Any help to test it is appreciated.<br>
    <br>
    Sorry for my bad english.<br>
    <br>
    <blockquote type=3D"cite"><span>
      <div dir=3D"ltr">
        <div><br>
          Also, can=C2=A0 I get invited at xendevel irc ?<br>
          regards<br>
          <br>
        </div>
        Greg <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><pre>_______________________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a113cf3e0880040050b4fd7ed--


--===============5309979415804865274==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5309979415804865274==--


From xen-devel-bounces@lists.xen.org Mon Dec 29 00:21:10 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 00: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 1Y5O4Z-0003wG-TF; Mon, 29 Dec 2014 00:20:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y5O4Y-0003wB-Gv
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 00:20:34 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	03/C9-15461-15E90A45; Mon, 29 Dec 2014 00:20:33 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1419812430!18138215!1
X-Originating-IP: [209.85.214.177]
X-SpamReason: No, hits=2.6 required=7.0 tests=BIZ_TLD,HTML_40_50,
	HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9231 invoked from network); 29 Dec 2014 00:20:31 -0000
Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com)
	(209.85.214.177)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2014 00:20:31 -0000
Received: by mail-ob0-f177.google.com with SMTP id va2so38831887obc.8
	for <xen-devel@lists.xen.org>; Sun, 28 Dec 2014 16:20: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=cDaBPANNLB7jEFLHqcQGHXxfTZGwbGedPHlQkfQg1dY=;
	b=WunYnWfvrI/pTJxqe7/D7cDL9Xa+sNkMCQoCSaVrJ2axjxS8JhNuUDeeqJaUvdq2kc
	bdwSeAI3XSjbOR4e2tdmXpMM71MmozLUSHg8xHqanxpxghvffyQDSVaJz1Hg7z/vnV7Q
	PdZwC8WBnStIL2S7lNru+A9dgeWJQq/hCizlMXWa43vO7VVwJGwawu/gJzcTq50shMZV
	eW/T7pdSATQAMFvnZt6Rt90Zwxf/sE3abgL9RkE9bPiTEk77rloHv5hR/OI27hk0I0I6
	n+Rlm/vMkCOGl5rkHXy6RWIJsJT/bX6GBLsc+nNmAJJwVgnIRAf1EOReIMLsxxrPMTBc
	iOIA==
MIME-Version: 1.0
X-Received: by 10.202.53.139 with SMTP id c133mr5961982oia.109.1419812429887; 
	Sun, 28 Dec 2014 16:20:29 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Sun, 28 Dec 2014 16:20:29 -0800 (PST)
In-Reply-To: <CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
	<549EBDCC.3090102@m2r.biz>
	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
	<CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>
Date: Mon, 29 Dec 2014 01:20:29 +0100
Message-ID: <CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5309979415804865274=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5309979415804865274==
Content-Type: multipart/alternative; boundary=001a113cf3e0880040050b4fd7ed

--001a113cf3e0880040050b4fd7ed
Content-Type: text/plain; charset=UTF-8

well figured out it is because you have to "enforce" locale:  export
LC_ALL=en_US.utf-8 if keyboard mapping is else

2014-12-28 21:19 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:

> Trying to compile xen 4.5RC4 in order to test your patch I end up with
> these errors compiling the Seabios directories,
>
> any idea?
>
>   Compiling to assembler out/src/asm-offsets.s
>   Generating offset file out/asm-offsets.h
>   Compiling (16bit) out/romlayout.o
>   Building ld scripts
> Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
> Traceback (most recent call last):
>   File "./scripts/layoutrom.py", line 709, in <module>
>     main()
>   File "./scripts/layoutrom.py", line 671, in main
>     info16 = parseObjDump(infile16, '16')
>   File "./scripts/layoutrom.py", line 586, in parseObjDump
>     relocsection = sectionmap[sectionname]
> KeyError:
> '.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
> Makefile:155: recipe for target 'out/romlayout16.lds' failed
> make[6]: *** [out/romlayout16.lds] Error 1
> make[6]: Leaving directory
> '/home/goon/xen/tools/firmware/seabios-dir-remote'
> /home/goon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for target
> 'subdir-all-seabios-dir' failed
>
>
>
> 2014-12-27 17:35 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>
>> Hello Fabio,
>>
>> Sure thing I will help debug the win7 and the win8 versions.
>> Where to start?
>>
>> I'll try to see if I can patch with patch from
>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>> and if not will post result.
>>
>>
>> best regards,
>>
>>
>> greg Bahde
>>
>> 2014-12-27 15:10 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:
>>
>>>
>>> Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>>
>>>   I tried to install Qxl drivers under win7/win 2k8/win8.1
>>> all       x64 versions, without any luck.
>>>
>>>
>>> admin message is as follow:
>>> Driver Management concluded the process to install driver
>>> FileRepository\qxl.inf_amd64_
>>> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
>>> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
>>> following status: 0xe000022d.
>>>
>>>
>>>
>>>
>>>  Does
>>> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>>
>>>  can it be installed on my xen stack?
>>>
>>>
>>> Yes but probably require a small refresh, I always posted the patch
>>> based on updated xen-unstable.
>>>
>>> Here qxl patch refreshed for xen 4.5 if needed:
>>>
>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>>
>>> Here the latest spice guest tools for windows with qxl driver included:
>>>
>>> http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>>>
>>> Windows >=8 and similar require a new qxl drivers, there are a beta
>>> build but latest tried some months ago have serious bug and I not found
>>> recent build full working on windows 8.
>>>
>>> On xen windows 7 domUs qxl works good except a problem after
>>> save/restore and on linux domUs is not working, for now I not found exactly
>>> cause and solution.
>>> On mailing list up to 2 years ago you can find many my mails about.
>>> Any help to test it is appreciated.
>>>
>>> Sorry for my bad english.
>>>
>>>
>>> Also, can  I get invited at xendevel irc ?
>>> regards
>>>
>>>  Greg
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing listXen-devel@lists.xen.orghttp://lists.xen.org/xen-devel
>>>
>>>
>>>
>>
>

--001a113cf3e0880040050b4fd7ed
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>well figured out it is because you have to &quot;enfo=
rce&quot; locale:=C2=A0 export LC_ALL=3Den_US.utf-8 if keyboard mapping is =
else<br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">2014-12-28 21:19 GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=3D=
"mailto:monsieur.goonie@gmail.com" target=3D"_blank">monsieur.goonie@gmail.=
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 dir=3D"ltr"><div=
>Trying to compile xen 4.5RC4 in order to test your patch I end up with=C2=
=A0 these errors compiling the Seabios directories,<br><br></div>any idea?<=
br><br>=C2=A0 Compiling to assembler out/src/asm-offsets.s<br>=C2=A0 Genera=
ting offset file out/asm-offsets.h<br>=C2=A0 Compiling (16bit) out/romlayou=
t.o<br>=C2=A0 Building ld scripts<br>Version: rel-1.7.5-0-ge51488c-20141228=
_210340-E766<br>Traceback (most recent call last):<br>=C2=A0 File &quot;./s=
cripts/layoutrom.py&quot;, line 709, in &lt;module&gt;<br>=C2=A0=C2=A0=C2=
=A0 main()<br>=C2=A0 File &quot;./scripts/layoutrom.py&quot;, line 671, in =
main<br>=C2=A0=C2=A0=C2=A0 info16 =3D parseObjDump(infile16, &#39;16&#39;)<=
br>=C2=A0 File &quot;./scripts/layoutrom.py&quot;, line 586, in parseObjDum=
p<br>=C2=A0=C2=A0=C2=A0 relocsection =3D sectionmap[sectionname]<br>KeyErro=
r: &#39;.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/s=
mp.c.79&#39;<br>Makefile:155: recipe for target &#39;out/romlayout16.lds&#3=
9; failed<br>make[6]: *** [out/romlayout16.lds] Error 1<br>make[6]: Leaving=
 directory &#39;/home/goon/xen/tools/firmware/seabios-dir-remote&#39;<br>/h=
ome/goon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for target &#3=
9;subdir-all-seabios-dir&#39; failed<br><br><br></div><div class=3D"HOEnZb"=
><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">2014-12-27 17:35 GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=3D"=
mailto:monsieur.goonie@gmail.com" target=3D"_blank">monsieur.goonie@gmail.c=
om</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 dir=3D"ltr"><div>=
<div><div>Hello Fabio,<br><br>Sure thing I will help debug the win7 and the=
 win8 versions.<br></div>Where to start?<br><br></div>I&#39;ll try to see i=
f I can patch with patch from <a href=3D"https://github.com/Fantu/Xen/commi=
t/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe" target=3D"_blank">https://githu=
b.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a> and if =
not will post result.<br><br><br>best regards,<br><br><br></div>greg Bahde<=
br></div><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">2014-12-27 15:10 GMT+01:00 Fabio Fantoni <span dir=3D"ltr">&lt;<a href=3D=
"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">fabio.fantoni@m2r.biz</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">
    <br>
    <div>Il 27/12/2014 02:15, Goonie Windy ha
      scritto:<br>
    </div><span>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>I tried to install Qxl drivers under win7/win
              2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 al=
l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64 versions, without any
              luck.<br>
              <br>
              <br>
              admin message is as follow:<br>
              Driver Management concluded the process to install driver
              FileRepository\qxl.inf_amd64_
              <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf for Device
                Instance ID
                PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&=
amp;267A616A&amp;1&amp;28
                with the following status: 0xe000022d.</div>
              <br>
              <br>
              <br>
              <br>
            </div>
            Does <br>
            <a href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05=
/msg03214.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-de=
vel/2014-05/msg03214.html</a><br>
            <br>
          </div>
          can it be installed on my xen stack? <br>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes but probably require a small refresh, I always posted the patch
    based on updated xen-unstable. <br>
    <br>
    Here qxl patch refreshed for xen 4.5 if needed:<br>
<a href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67a=
a11879e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8=
d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
    <br>
    Here the latest spice guest tools for windows with qxl driver
    included:<br>
<a href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/s=
pice-guest-tools-0.74.exe" target=3D"_blank">http://www.spice-space.org/dow=
nload/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
    <br>
    Windows &gt;=3D8 and similar require a new qxl drivers, there are a
    beta build but latest tried some months ago have serious bug and I
    not found recent build full working on windows 8.<br>
    <br>
    On xen windows 7 domUs qxl works good except a problem after
    save/restore and on linux domUs is not working, for now I not found
    exactly cause and solution.<br>
    On mailing list up to 2 years ago you can find many my mails about.<br>
    Any help to test it is appreciated.<br>
    <br>
    Sorry for my bad english.<br>
    <br>
    <blockquote type=3D"cite"><span>
      <div dir=3D"ltr">
        <div><br>
          Also, can=C2=A0 I get invited at xendevel irc ?<br>
          regards<br>
          <br>
        </div>
        Greg <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><pre>_______________________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a113cf3e0880040050b4fd7ed--


--===============5309979415804865274==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5309979415804865274==--


From xen-devel-bounces@lists.xen.org Mon Dec 29 01:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 01: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 1Y5PSY-0001Ef-CG; Mon, 29 Dec 2014 01:49: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 1Y5PSW-0001EY-AH
	for xen-devel@lists.xensource.com; Mon, 29 Dec 2014 01:49:24 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	8B/DC-17958-323B0A45; Mon, 29 Dec 2014 01:49:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419817761!16170440!1
X-Originating-IP: [66.165.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 3338 invoked from network); 29 Dec 2014 01:49:22 -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;
	29 Dec 2014 01:49:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,658,1413244800"; d="scan'208";a="208737631"
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.210.2; Sun, 28 Dec 2014 20:49:20 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y5PSR-0004q2-Uh;
	Mon, 29 Dec 2014 01:49:19 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5PSR-0002DU-PF;
	Mon, 29 Dec 2014 01:49:19 +0000
Date: Mon, 29 Dec 2014 01:49:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32763-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] 32763: 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 32763 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32763/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl          15 capture-logs(15)        broken REGR. vs. 32674
 test-armhf-armhf-libvirt     10 capture-logs(10)        broken REGR. vs. 32674

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 32674
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32674
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32674
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32674
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32674

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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                29169f823067b07bc2967f64ec4b6c9cd1a714a4
baseline version:
 linux                08b022a9655bf925e6683422590306429b752ccd

------------------------------------------------------------
People who touched revisions under test:
  Helge Deller <deller@gmx.de>
  Jayachandran B <jayachandran.b@intel.com>
  John David Anglin <dave.anglin@bell.net>
  Libin Yang <libin.yang@intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Rafal Redzimski <rafal.f.redzimski@intel.com>
  Takashi Iwai <tiwai@suse.de>
------------------------------------------------------------

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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-armhf-armhf-xl capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Not pushing.

------------------------------------------------------------
commit 29169f823067b07bc2967f64ec4b6c9cd1a714a4
Merge: 58628a7 d679582
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Dec 27 13:12:00 2014 -0800

    Merge tag 'sound-3.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
    
    Pull sound fixes from Takashi Iwai:
     "Just a couple of fixes for the new Intel Skylake HD-audio support"
    
    * tag 'sound-3.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
      ALSA: hda_intel: apply the Seperate stream_tag for Skylake
      ALSA: hda_controller: Separate stream_tag for input and output streams.

commit 58628a7831edac5f7a13baa9d9320c758c5204c8
Merge: 08b022a 45db073
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Dec 26 13:41:05 2014 -0800

    Merge branch 'parisc-3.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
    
    Pull parisc build fix from Helge Deller:
     "This unbreaks the kernel compilation on parisc with gcc-4.9"
    
    * 'parisc-3.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
      parisc: fix out-of-register compiler error in ldcw inline assembler function

commit 45db07382a5c78b0c43b3b0002b63757fb60e873
Author: John David Anglin <dave.anglin@bell.net>
Date:   Sun Dec 14 10:49:11 2014 -0500

    parisc: fix out-of-register compiler error in ldcw inline assembler function
    
    The __ldcw macro has a problem when its argument needs to be reloaded from
    memory. The output memory operand and the input register operand both need to
    be reloaded using a register in class R1_REGS when generating 64-bit code.
    This fails because there's only a single register in the class. Instead, use a
    memory clobber. This also makes the __ldcw macro a compiler memory barrier.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Cc: <stable@vger.kernel.org>        [3.13+]
    Signed-off-by: Helge Deller <deller@gmx.de>

commit d6795827bd79b28fef1abdaf7e525fcca506b831
Author: Libin Yang <libin.yang@intel.com>
Date:   Fri Dec 19 08:44:31 2014 +0800

    ALSA: hda_intel: apply the Seperate stream_tag for Skylake
    
    The total stream number of Skylake's input and output stream
    exceeds 15, which will cause some streams do not work because
    of the overflow on SDxCTL.STRM field if using the legacy
    stream tag allocation method.
    
    This patch uses the new stream tag allocation method by add
    the flag AZX_DCAPS_SEPARATE_STREAM_TAG for Skylake platform.
    
    Signed-off-by: Libin Yang <libin.yang@intel.com>
    Reviewed-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 93e3423e6ba4b0ddaf056ecbdf5bc46f18f41deb
Author: Rafal Redzimski <rafal.f.redzimski@intel.com>
Date:   Fri Dec 19 08:44:30 2014 +0800

    ALSA: hda_controller: Separate stream_tag for input and output streams.
    
    Implemented separate stream_tag assignment for input and output streams.
    According to hda specification stream tag must be unique throughout the
    input streams group, however an output stream might use a stream tag
    which is already in use by an input stream. This change is necessary
    to support HW which provides a total of more than 15 stream DMA engines
    which with legacy implementation causes an overflow on SDxCTL.STRM
    field (and the whole SDxCTL register) and as a result usage of
    Reserved value 0 in the SDxCTL.STRM field which confuses HDA controller.
    
    Signed-off-by: Rafal Redzimski <rafal.f.redzimski@intel.com>
    Signed-off-by: Jayachandran B <jayachandran.b@intel.com>
    Signed-off-by: Libin Yang <libin.yang@intel.com>
    Reviewed-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 29 01:49:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 01: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 1Y5PSY-0001Ef-CG; Mon, 29 Dec 2014 01:49: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 1Y5PSW-0001EY-AH
	for xen-devel@lists.xensource.com; Mon, 29 Dec 2014 01:49:24 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	8B/DC-17958-323B0A45; Mon, 29 Dec 2014 01:49:23 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419817761!16170440!1
X-Originating-IP: [66.165.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 3338 invoked from network); 29 Dec 2014 01:49:22 -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;
	29 Dec 2014 01:49:22 -0000
X-IronPort-AV: E=Sophos;i="5.07,658,1413244800"; d="scan'208";a="208737631"
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.210.2; Sun, 28 Dec 2014 20:49:20 -0500
Received: from osstest.cam.xci-test.com ([10.80.249.189])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<Ian.Jackson@eu.citrix.com>)	id 1Y5PSR-0004q2-Uh;
	Mon, 29 Dec 2014 01:49:19 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5PSR-0002DU-PF;
	Mon, 29 Dec 2014 01:49:19 +0000
Date: Mon, 29 Dec 2014 01:49:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32763-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] 32763: 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 32763 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32763/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl          15 capture-logs(15)        broken REGR. vs. 32674
 test-armhf-armhf-libvirt     10 capture-logs(10)        broken REGR. vs. 32674

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 32674
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32674
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32674
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32674
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32674

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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                29169f823067b07bc2967f64ec4b6c9cd1a714a4
baseline version:
 linux                08b022a9655bf925e6683422590306429b752ccd

------------------------------------------------------------
People who touched revisions under test:
  Helge Deller <deller@gmx.de>
  Jayachandran B <jayachandran.b@intel.com>
  John David Anglin <dave.anglin@bell.net>
  Libin Yang <libin.yang@intel.com>
  Linus Torvalds <torvalds@linux-foundation.org>
  Rafal Redzimski <rafal.f.redzimski@intel.com>
  Takashi Iwai <tiwai@suse.de>
------------------------------------------------------------

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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-armhf-armhf-xl capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Not pushing.

------------------------------------------------------------
commit 29169f823067b07bc2967f64ec4b6c9cd1a714a4
Merge: 58628a7 d679582
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Dec 27 13:12:00 2014 -0800

    Merge tag 'sound-3.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
    
    Pull sound fixes from Takashi Iwai:
     "Just a couple of fixes for the new Intel Skylake HD-audio support"
    
    * tag 'sound-3.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
      ALSA: hda_intel: apply the Seperate stream_tag for Skylake
      ALSA: hda_controller: Separate stream_tag for input and output streams.

commit 58628a7831edac5f7a13baa9d9320c758c5204c8
Merge: 08b022a 45db073
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Dec 26 13:41:05 2014 -0800

    Merge branch 'parisc-3.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
    
    Pull parisc build fix from Helge Deller:
     "This unbreaks the kernel compilation on parisc with gcc-4.9"
    
    * 'parisc-3.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
      parisc: fix out-of-register compiler error in ldcw inline assembler function

commit 45db07382a5c78b0c43b3b0002b63757fb60e873
Author: John David Anglin <dave.anglin@bell.net>
Date:   Sun Dec 14 10:49:11 2014 -0500

    parisc: fix out-of-register compiler error in ldcw inline assembler function
    
    The __ldcw macro has a problem when its argument needs to be reloaded from
    memory. The output memory operand and the input register operand both need to
    be reloaded using a register in class R1_REGS when generating 64-bit code.
    This fails because there's only a single register in the class. Instead, use a
    memory clobber. This also makes the __ldcw macro a compiler memory barrier.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Cc: <stable@vger.kernel.org>        [3.13+]
    Signed-off-by: Helge Deller <deller@gmx.de>

commit d6795827bd79b28fef1abdaf7e525fcca506b831
Author: Libin Yang <libin.yang@intel.com>
Date:   Fri Dec 19 08:44:31 2014 +0800

    ALSA: hda_intel: apply the Seperate stream_tag for Skylake
    
    The total stream number of Skylake's input and output stream
    exceeds 15, which will cause some streams do not work because
    of the overflow on SDxCTL.STRM field if using the legacy
    stream tag allocation method.
    
    This patch uses the new stream tag allocation method by add
    the flag AZX_DCAPS_SEPARATE_STREAM_TAG for Skylake platform.
    
    Signed-off-by: Libin Yang <libin.yang@intel.com>
    Reviewed-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 93e3423e6ba4b0ddaf056ecbdf5bc46f18f41deb
Author: Rafal Redzimski <rafal.f.redzimski@intel.com>
Date:   Fri Dec 19 08:44:30 2014 +0800

    ALSA: hda_controller: Separate stream_tag for input and output streams.
    
    Implemented separate stream_tag assignment for input and output streams.
    According to hda specification stream tag must be unique throughout the
    input streams group, however an output stream might use a stream tag
    which is already in use by an input stream. This change is necessary
    to support HW which provides a total of more than 15 stream DMA engines
    which with legacy implementation causes an overflow on SDxCTL.STRM
    field (and the whole SDxCTL register) and as a result usage of
    Reserved value 0 in the SDxCTL.STRM field which confuses HDA controller.
    
    Signed-off-by: Rafal Redzimski <rafal.f.redzimski@intel.com>
    Signed-off-by: Jayachandran B <jayachandran.b@intel.com>
    Signed-off-by: Libin Yang <libin.yang@intel.com>
    Reviewed-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 29 05:45:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 05: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 1Y5T8Y-0006Ga-N0; Mon, 29 Dec 2014 05:45:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y5T8W-0006GV-Aw
	for xen-devel@lists.xensource.com; Mon, 29 Dec 2014 05:45:00 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	0F/05-16982-B5AE0A45; Mon, 29 Dec 2014 05:44:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1419831897!16172501!1
X-Originating-IP: [66.165.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 6292 invoked from network); 29 Dec 2014 05:44:58 -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;
	29 Dec 2014 05:44:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,658,1413244800"; d="scan'208";a="208771967"
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.210.2; Mon, 29 Dec 2014 00:44: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 1Y5T8R-0005xZ-ME;
	Mon, 29 Dec 2014 05:44:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5T8R-0003fz-CJ;
	Mon, 29 Dec 2014 05:44:55 +0000
Date: Mon, 29 Dec 2014 05:44:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32770-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] 32770: 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 32770 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32770/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)          broken pass in 32689
 test-armhf-armhf-libvirt     10 capture-logs(10)          broken pass in 32689
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot            fail pass in 32754
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot        fail pass in 32754

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-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                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Not pushing.

(No revision log; it would be 912 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 Dec 29 05:45:38 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 05: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 1Y5T8Y-0006Ga-N0; Mon, 29 Dec 2014 05:45:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y5T8W-0006GV-Aw
	for xen-devel@lists.xensource.com; Mon, 29 Dec 2014 05:45:00 +0000
Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id
	0F/05-16982-B5AE0A45; Mon, 29 Dec 2014 05:44:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-11.tower-31.messagelabs.com!1419831897!16172501!1
X-Originating-IP: [66.165.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 6292 invoked from network); 29 Dec 2014 05:44:58 -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;
	29 Dec 2014 05:44:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,658,1413244800"; d="scan'208";a="208771967"
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.210.2; Mon, 29 Dec 2014 00:44: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 1Y5T8R-0005xZ-ME;
	Mon, 29 Dec 2014 05:44:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5T8R-0003fz-CJ;
	Mon, 29 Dec 2014 05:44:55 +0000
Date: Mon, 29 Dec 2014 05:44:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32770-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] 32770: 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 32770 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32770/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)          broken pass in 32689
 test-armhf-armhf-libvirt     10 capture-logs(10)          broken pass in 32689
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot            fail pass in 32754
 test-amd64-i386-xl-qemut-debianhvm-amd64  5 xen-boot        fail pass in 32754

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-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                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Not pushing.

(No revision log; it would be 912 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 Dec 29 12:47:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 12: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 1Y5Ziv-0004dT-C3; Mon, 29 Dec 2014 12:47:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y5Zit-0004dO-VB
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 12:47:00 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	5E/EE-14727-34D41A45; Mon, 29 Dec 2014 12:46:59 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1419857216!15541634!1
X-Originating-IP: [209.85.218.51]
X-SpamReason: No, hits=2.6 required=7.0 tests=BIZ_TLD,HTML_40_50,
	HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31462 invoked from network); 29 Dec 2014 12:46:57 -0000
Received: from mail-oi0-f51.google.com (HELO mail-oi0-f51.google.com)
	(209.85.218.51)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2014 12:46:57 -0000
Received: by mail-oi0-f51.google.com with SMTP id e131so28829780oig.10
	for <xen-devel@lists.xen.org>; Mon, 29 Dec 2014 04:46:56 -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=pMPy8d741rxJsiRZFwf0YZfqpbgtLAGdZ7kjnjAIBsU=;
	b=fEerRy2Iv+MepunJ1J1OLTeIT3stNinTTl5JiK7/R8TNZA1v905KzKPKJWPG3bmRNF
	/JB9X9k0/dMJBvLNtRxCXk0ezo65i0aw1UFzEO99sx2usYNAebHGHEgbP4D008lh6lb8
	O0zuRNBREb2zKa/RHNJL7FdKjLmjnW+IQWkroVW8y4PVEEKa/7sXq3RbXf+iJRU0s4IM
	Kc17mkw5X8lIVwVyQ0C41eHHpd6Nx7SOo1l25wDvhxq6VqhY9WxhlbDx36WYTru5m7WI
	EptDRgjI0Yn3PCQ8sOMkrV7e0KPPUUomn4fLYFklNhO7cIi6VXk8xzBQvUM8veFaTgOd
	NMGA==
MIME-Version: 1.0
X-Received: by 10.202.58.87 with SMTP id h84mr31214893oia.118.1419857216190;
	Mon, 29 Dec 2014 04:46:56 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Mon, 29 Dec 2014 04:46:56 -0800 (PST)
In-Reply-To: <CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
	<549EBDCC.3090102@m2r.biz>
	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
	<CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>
	<CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>
Date: Mon, 29 Dec 2014 13:46:56 +0100
Message-ID: <CAE5x5YU8R9PibP-_xj+uYNc_rqOL0rnuHvVF5Ymz32RngDEgFw@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7956247548971038468=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7956247548971038468==
Content-Type: multipart/alternative; boundary=001a113cd57c00bd82050b5a4509

--001a113cd57c00bd82050b5a4509
Content-Type: text/plain; charset=UTF-8

There is an error in pageqs describing how to compile from sources as in
4.5

cat .config
PYTHON_PREFIX_ARG=--install-layout=deb

is in fact in .INSTALL



2014-12-29 1:20 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:

> well figured out it is because you have to "enforce" locale:  export
> LC_ALL=en_US.utf-8 if keyboard mapping is else
>
> 2014-12-28 21:19 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>
>> Trying to compile xen 4.5RC4 in order to test your patch I end up with
>> these errors compiling the Seabios directories,
>>
>> any idea?
>>
>>   Compiling to assembler out/src/asm-offsets.s
>>   Generating offset file out/asm-offsets.h
>>   Compiling (16bit) out/romlayout.o
>>   Building ld scripts
>> Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
>> Traceback (most recent call last):
>>   File "./scripts/layoutrom.py", line 709, in <module>
>>     main()
>>   File "./scripts/layoutrom.py", line 671, in main
>>     info16 = parseObjDump(infile16, '16')
>>   File "./scripts/layoutrom.py", line 586, in parseObjDump
>>     relocsection = sectionmap[sectionname]
>> KeyError:
>> '.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
>> Makefile:155: recipe for target 'out/romlayout16.lds' failed
>> make[6]: *** [out/romlayout16.lds] Error 1
>> make[6]: Leaving directory
>> '/home/goon/xen/tools/firmware/seabios-dir-remote'
>> /home/goon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for target
>> 'subdir-all-seabios-dir' failed
>>
>>
>>
>> 2014-12-27 17:35 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>>
>>> Hello Fabio,
>>>
>>> Sure thing I will help debug the win7 and the win8 versions.
>>> Where to start?
>>>
>>> I'll try to see if I can patch with patch from
>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>> and if not will post result.
>>>
>>>
>>> best regards,
>>>
>>>
>>> greg Bahde
>>>
>>> 2014-12-27 15:10 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:
>>>
>>>>
>>>> Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>>>
>>>>   I tried to install Qxl drivers under win7/win 2k8/win8.1
>>>> all       x64 versions, without any luck.
>>>>
>>>>
>>>> admin message is as follow:
>>>> Driver Management concluded the process to install driver
>>>> FileRepository\qxl.inf_amd64_
>>>> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
>>>> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
>>>> following status: 0xe000022d.
>>>>
>>>>
>>>>
>>>>
>>>>  Does
>>>> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>>>
>>>>  can it be installed on my xen stack?
>>>>
>>>>
>>>> Yes but probably require a small refresh, I always posted the patch
>>>> based on updated xen-unstable.
>>>>
>>>> Here qxl patch refreshed for xen 4.5 if needed:
>>>>
>>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>>>
>>>> Here the latest spice guest tools for windows with qxl driver included:
>>>>
>>>> http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>>>>
>>>> Windows >=8 and similar require a new qxl drivers, there are a beta
>>>> build but latest tried some months ago have serious bug and I not found
>>>> recent build full working on windows 8.
>>>>
>>>> On xen windows 7 domUs qxl works good except a problem after
>>>> save/restore and on linux domUs is not working, for now I not found exactly
>>>> cause and solution.
>>>> On mailing list up to 2 years ago you can find many my mails about.
>>>> Any help to test it is appreciated.
>>>>
>>>> Sorry for my bad english.
>>>>
>>>>
>>>> Also, can  I get invited at xendevel irc ?
>>>> regards
>>>>
>>>>  Greg
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing listXen-devel@lists.xen.orghttp://lists.xen.org/xen-devel
>>>>
>>>>
>>>>
>>>
>>
>

--001a113cd57c00bd82050b5a4509
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There is an error in pageqs describing how to compile from=
 sources as in 4.5 <br><pre>cat .config
PYTHON_PREFIX_ARG=3D--install-layout=3Ddeb
<br></pre><pre>is in fact in .INSTALL<br></pre><br></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">2014-12-29 1:20 GMT+01:00 Goonie Wi=
ndy <span dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.goonie@gmail.com" targ=
et=3D"_blank">monsieur.goonie@gmail.com</a>&gt;</span>:<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>well figured out it is because you hav=
e to &quot;enforce&quot; locale:=C2=A0 export LC_ALL=3Den_US.utf-8 if keybo=
ard mapping is else<br></div></div><div class=3D"HOEnZb"><div class=3D"h5">=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-12-28 21:19 =
GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.goo=
nie@gmail.com" target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr"><div>Trying to compile x=
en 4.5RC4 in order to test your patch I end up with=C2=A0 these errors comp=
iling the Seabios directories,<br><br></div>any idea?<br><br>=C2=A0 Compili=
ng to assembler out/src/asm-offsets.s<br>=C2=A0 Generating offset file out/=
asm-offsets.h<br>=C2=A0 Compiling (16bit) out/romlayout.o<br>=C2=A0 Buildin=
g ld scripts<br>Version: rel-1.7.5-0-ge51488c-20141228_210340-E766<br>Trace=
back (most recent call last):<br>=C2=A0 File &quot;./scripts/layoutrom.py&q=
uot;, line 709, in &lt;module&gt;<br>=C2=A0=C2=A0=C2=A0 main()<br>=C2=A0 Fi=
le &quot;./scripts/layoutrom.py&quot;, line 671, in main<br>=C2=A0=C2=A0=C2=
=A0 info16 =3D parseObjDump(infile16, &#39;16&#39;)<br>=C2=A0 File &quot;./=
scripts/layoutrom.py&quot;, line 586, in parseObjDump<br>=C2=A0=C2=A0=C2=A0=
 relocsection =3D sectionmap[sectionname]<br>KeyError: &#39;.text.asm./home=
/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79&#39;<br>Makefil=
e:155: recipe for target &#39;out/romlayout16.lds&#39; failed<br>make[6]: *=
** [out/romlayout16.lds] Error 1<br>make[6]: Leaving directory &#39;/home/g=
oon/xen/tools/firmware/seabios-dir-remote&#39;<br>/home/goon/xen/tools/firm=
ware/../../tools/Rules.mk:116: recipe for target &#39;subdir-all-seabios-di=
r&#39; failed<br><br><br></div><div><div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">2014-12-27 17:35 GMT+01:00 Goonie Windy <span dir=
=3D"ltr">&lt;<a href=3D"mailto:monsieur.goonie@gmail.com" target=3D"_blank"=
>monsieur.goonie@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div><div><div>Hello Fabio,<br><br>Sure thing I will hel=
p debug the win7 and the win8 versions.<br></div>Where to start?<br><br></d=
iv>I&#39;ll try to see if I can patch with patch from <a href=3D"https://gi=
thub.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe" target=
=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67=
aa11879e8b8fe</a> and if not will post result.<br><br><br>best regards,<br>=
<br><br></div>greg Bahde<br></div><div><div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">2014-12-27 15:10 GMT+01:00 Fabio Fantoni <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">f=
abio.fantoni@m2r.biz</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div>Il 27/12/2014 02:15, Goonie Windy ha
      scritto:<br>
    </div><span>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>I tried to install Qxl drivers under win7/win
              2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 al=
l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64 versions, without any
              luck.<br>
              <br>
              <br>
              admin message is as follow:<br>
              Driver Management concluded the process to install driver
              FileRepository\qxl.inf_amd64_
              <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf for Device
                Instance ID
                PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&=
amp;267A616A&amp;1&amp;28
                with the following status: 0xe000022d.</div>
              <br>
              <br>
              <br>
              <br>
            </div>
            Does <br>
            <a href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05=
/msg03214.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-de=
vel/2014-05/msg03214.html</a><br>
            <br>
          </div>
          can it be installed on my xen stack? <br>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes but probably require a small refresh, I always posted the patch
    based on updated xen-unstable. <br>
    <br>
    Here qxl patch refreshed for xen 4.5 if needed:<br>
<a href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67a=
a11879e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8=
d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
    <br>
    Here the latest spice guest tools for windows with qxl driver
    included:<br>
<a href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/s=
pice-guest-tools-0.74.exe" target=3D"_blank">http://www.spice-space.org/dow=
nload/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
    <br>
    Windows &gt;=3D8 and similar require a new qxl drivers, there are a
    beta build but latest tried some months ago have serious bug and I
    not found recent build full working on windows 8.<br>
    <br>
    On xen windows 7 domUs qxl works good except a problem after
    save/restore and on linux domUs is not working, for now I not found
    exactly cause and solution.<br>
    On mailing list up to 2 years ago you can find many my mails about.<br>
    Any help to test it is appreciated.<br>
    <br>
    Sorry for my bad english.<br>
    <br>
    <blockquote type=3D"cite"><span>
      <div dir=3D"ltr">
        <div><br>
          Also, can=C2=A0 I get invited at xendevel irc ?<br>
          regards<br>
          <br>
        </div>
        Greg <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><pre>_______________________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a113cd57c00bd82050b5a4509--


--===============7956247548971038468==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7956247548971038468==--


From xen-devel-bounces@lists.xen.org Mon Dec 29 12:47:41 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 12: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 1Y5Ziv-0004dT-C3; Mon, 29 Dec 2014 12:47:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y5Zit-0004dO-VB
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 12:47:00 +0000
Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id
	5E/EE-14727-34D41A45; Mon, 29 Dec 2014 12:46:59 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1419857216!15541634!1
X-Originating-IP: [209.85.218.51]
X-SpamReason: No, hits=2.6 required=7.0 tests=BIZ_TLD,HTML_40_50,
	HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31462 invoked from network); 29 Dec 2014 12:46:57 -0000
Received: from mail-oi0-f51.google.com (HELO mail-oi0-f51.google.com)
	(209.85.218.51)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2014 12:46:57 -0000
Received: by mail-oi0-f51.google.com with SMTP id e131so28829780oig.10
	for <xen-devel@lists.xen.org>; Mon, 29 Dec 2014 04:46:56 -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=pMPy8d741rxJsiRZFwf0YZfqpbgtLAGdZ7kjnjAIBsU=;
	b=fEerRy2Iv+MepunJ1J1OLTeIT3stNinTTl5JiK7/R8TNZA1v905KzKPKJWPG3bmRNF
	/JB9X9k0/dMJBvLNtRxCXk0ezo65i0aw1UFzEO99sx2usYNAebHGHEgbP4D008lh6lb8
	O0zuRNBREb2zKa/RHNJL7FdKjLmjnW+IQWkroVW8y4PVEEKa/7sXq3RbXf+iJRU0s4IM
	Kc17mkw5X8lIVwVyQ0C41eHHpd6Nx7SOo1l25wDvhxq6VqhY9WxhlbDx36WYTru5m7WI
	EptDRgjI0Yn3PCQ8sOMkrV7e0KPPUUomn4fLYFklNhO7cIi6VXk8xzBQvUM8veFaTgOd
	NMGA==
MIME-Version: 1.0
X-Received: by 10.202.58.87 with SMTP id h84mr31214893oia.118.1419857216190;
	Mon, 29 Dec 2014 04:46:56 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Mon, 29 Dec 2014 04:46:56 -0800 (PST)
In-Reply-To: <CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
	<549EBDCC.3090102@m2r.biz>
	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
	<CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>
	<CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>
Date: Mon, 29 Dec 2014 13:46:56 +0100
Message-ID: <CAE5x5YU8R9PibP-_xj+uYNc_rqOL0rnuHvVF5Ymz32RngDEgFw@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7956247548971038468=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7956247548971038468==
Content-Type: multipart/alternative; boundary=001a113cd57c00bd82050b5a4509

--001a113cd57c00bd82050b5a4509
Content-Type: text/plain; charset=UTF-8

There is an error in pageqs describing how to compile from sources as in
4.5

cat .config
PYTHON_PREFIX_ARG=--install-layout=deb

is in fact in .INSTALL



2014-12-29 1:20 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:

> well figured out it is because you have to "enforce" locale:  export
> LC_ALL=en_US.utf-8 if keyboard mapping is else
>
> 2014-12-28 21:19 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>
>> Trying to compile xen 4.5RC4 in order to test your patch I end up with
>> these errors compiling the Seabios directories,
>>
>> any idea?
>>
>>   Compiling to assembler out/src/asm-offsets.s
>>   Generating offset file out/asm-offsets.h
>>   Compiling (16bit) out/romlayout.o
>>   Building ld scripts
>> Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
>> Traceback (most recent call last):
>>   File "./scripts/layoutrom.py", line 709, in <module>
>>     main()
>>   File "./scripts/layoutrom.py", line 671, in main
>>     info16 = parseObjDump(infile16, '16')
>>   File "./scripts/layoutrom.py", line 586, in parseObjDump
>>     relocsection = sectionmap[sectionname]
>> KeyError:
>> '.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
>> Makefile:155: recipe for target 'out/romlayout16.lds' failed
>> make[6]: *** [out/romlayout16.lds] Error 1
>> make[6]: Leaving directory
>> '/home/goon/xen/tools/firmware/seabios-dir-remote'
>> /home/goon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for target
>> 'subdir-all-seabios-dir' failed
>>
>>
>>
>> 2014-12-27 17:35 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>>
>>> Hello Fabio,
>>>
>>> Sure thing I will help debug the win7 and the win8 versions.
>>> Where to start?
>>>
>>> I'll try to see if I can patch with patch from
>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>> and if not will post result.
>>>
>>>
>>> best regards,
>>>
>>>
>>> greg Bahde
>>>
>>> 2014-12-27 15:10 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:
>>>
>>>>
>>>> Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>>>
>>>>   I tried to install Qxl drivers under win7/win 2k8/win8.1
>>>> all       x64 versions, without any luck.
>>>>
>>>>
>>>> admin message is as follow:
>>>> Driver Management concluded the process to install driver
>>>> FileRepository\qxl.inf_amd64_
>>>> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
>>>> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
>>>> following status: 0xe000022d.
>>>>
>>>>
>>>>
>>>>
>>>>  Does
>>>> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>>>
>>>>  can it be installed on my xen stack?
>>>>
>>>>
>>>> Yes but probably require a small refresh, I always posted the patch
>>>> based on updated xen-unstable.
>>>>
>>>> Here qxl patch refreshed for xen 4.5 if needed:
>>>>
>>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>>>
>>>> Here the latest spice guest tools for windows with qxl driver included:
>>>>
>>>> http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>>>>
>>>> Windows >=8 and similar require a new qxl drivers, there are a beta
>>>> build but latest tried some months ago have serious bug and I not found
>>>> recent build full working on windows 8.
>>>>
>>>> On xen windows 7 domUs qxl works good except a problem after
>>>> save/restore and on linux domUs is not working, for now I not found exactly
>>>> cause and solution.
>>>> On mailing list up to 2 years ago you can find many my mails about.
>>>> Any help to test it is appreciated.
>>>>
>>>> Sorry for my bad english.
>>>>
>>>>
>>>> Also, can  I get invited at xendevel irc ?
>>>> regards
>>>>
>>>>  Greg
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing listXen-devel@lists.xen.orghttp://lists.xen.org/xen-devel
>>>>
>>>>
>>>>
>>>
>>
>

--001a113cd57c00bd82050b5a4509
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There is an error in pageqs describing how to compile from=
 sources as in 4.5 <br><pre>cat .config
PYTHON_PREFIX_ARG=3D--install-layout=3Ddeb
<br></pre><pre>is in fact in .INSTALL<br></pre><br></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">2014-12-29 1:20 GMT+01:00 Goonie Wi=
ndy <span dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.goonie@gmail.com" targ=
et=3D"_blank">monsieur.goonie@gmail.com</a>&gt;</span>:<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>well figured out it is because you hav=
e to &quot;enforce&quot; locale:=C2=A0 export LC_ALL=3Den_US.utf-8 if keybo=
ard mapping is else<br></div></div><div class=3D"HOEnZb"><div class=3D"h5">=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-12-28 21:19 =
GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.goo=
nie@gmail.com" target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr"><div>Trying to compile x=
en 4.5RC4 in order to test your patch I end up with=C2=A0 these errors comp=
iling the Seabios directories,<br><br></div>any idea?<br><br>=C2=A0 Compili=
ng to assembler out/src/asm-offsets.s<br>=C2=A0 Generating offset file out/=
asm-offsets.h<br>=C2=A0 Compiling (16bit) out/romlayout.o<br>=C2=A0 Buildin=
g ld scripts<br>Version: rel-1.7.5-0-ge51488c-20141228_210340-E766<br>Trace=
back (most recent call last):<br>=C2=A0 File &quot;./scripts/layoutrom.py&q=
uot;, line 709, in &lt;module&gt;<br>=C2=A0=C2=A0=C2=A0 main()<br>=C2=A0 Fi=
le &quot;./scripts/layoutrom.py&quot;, line 671, in main<br>=C2=A0=C2=A0=C2=
=A0 info16 =3D parseObjDump(infile16, &#39;16&#39;)<br>=C2=A0 File &quot;./=
scripts/layoutrom.py&quot;, line 586, in parseObjDump<br>=C2=A0=C2=A0=C2=A0=
 relocsection =3D sectionmap[sectionname]<br>KeyError: &#39;.text.asm./home=
/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79&#39;<br>Makefil=
e:155: recipe for target &#39;out/romlayout16.lds&#39; failed<br>make[6]: *=
** [out/romlayout16.lds] Error 1<br>make[6]: Leaving directory &#39;/home/g=
oon/xen/tools/firmware/seabios-dir-remote&#39;<br>/home/goon/xen/tools/firm=
ware/../../tools/Rules.mk:116: recipe for target &#39;subdir-all-seabios-di=
r&#39; failed<br><br><br></div><div><div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">2014-12-27 17:35 GMT+01:00 Goonie Windy <span dir=
=3D"ltr">&lt;<a href=3D"mailto:monsieur.goonie@gmail.com" target=3D"_blank"=
>monsieur.goonie@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div><div><div>Hello Fabio,<br><br>Sure thing I will hel=
p debug the win7 and the win8 versions.<br></div>Where to start?<br><br></d=
iv>I&#39;ll try to see if I can patch with patch from <a href=3D"https://gi=
thub.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe" target=
=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67=
aa11879e8b8fe</a> and if not will post result.<br><br><br>best regards,<br>=
<br><br></div>greg Bahde<br></div><div><div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">2014-12-27 15:10 GMT+01:00 Fabio Fantoni <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">f=
abio.fantoni@m2r.biz</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div>Il 27/12/2014 02:15, Goonie Windy ha
      scritto:<br>
    </div><span>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>I tried to install Qxl drivers under win7/win
              2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 al=
l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64 versions, without any
              luck.<br>
              <br>
              <br>
              admin message is as follow:<br>
              Driver Management concluded the process to install driver
              FileRepository\qxl.inf_amd64_
              <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf for Device
                Instance ID
                PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&=
amp;267A616A&amp;1&amp;28
                with the following status: 0xe000022d.</div>
              <br>
              <br>
              <br>
              <br>
            </div>
            Does <br>
            <a href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05=
/msg03214.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-de=
vel/2014-05/msg03214.html</a><br>
            <br>
          </div>
          can it be installed on my xen stack? <br>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes but probably require a small refresh, I always posted the patch
    based on updated xen-unstable. <br>
    <br>
    Here qxl patch refreshed for xen 4.5 if needed:<br>
<a href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67a=
a11879e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8=
d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
    <br>
    Here the latest spice guest tools for windows with qxl driver
    included:<br>
<a href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/s=
pice-guest-tools-0.74.exe" target=3D"_blank">http://www.spice-space.org/dow=
nload/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
    <br>
    Windows &gt;=3D8 and similar require a new qxl drivers, there are a
    beta build but latest tried some months ago have serious bug and I
    not found recent build full working on windows 8.<br>
    <br>
    On xen windows 7 domUs qxl works good except a problem after
    save/restore and on linux domUs is not working, for now I not found
    exactly cause and solution.<br>
    On mailing list up to 2 years ago you can find many my mails about.<br>
    Any help to test it is appreciated.<br>
    <br>
    Sorry for my bad english.<br>
    <br>
    <blockquote type=3D"cite"><span>
      <div dir=3D"ltr">
        <div><br>
          Also, can=C2=A0 I get invited at xendevel irc ?<br>
          regards<br>
          <br>
        </div>
        Greg <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><pre>_______________________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a113cd57c00bd82050b5a4509--


--===============7956247548971038468==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7956247548971038468==--


From xen-devel-bounces@lists.xen.org Mon Dec 29 12:47:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 12: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 1Y5Zjq-0004g1-1W; Mon, 29 Dec 2014 12:47: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 1Y5Zjo-0004fr-UR
	for xen-devel@lists.xensource.com; Mon, 29 Dec 2014 12:47:57 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	28/DB-02699-C7D41A45; Mon, 29 Dec 2014 12:47:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419857274!12169978!1
X-Originating-IP: [66.165.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 27649 invoked from network); 29 Dec 2014 12:47:55 -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;
	29 Dec 2014 12:47:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="208852206"
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.210.2; Mon, 29 Dec 2014 07: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 1Y5Zjk-00081R-Bg;
	Mon, 29 Dec 2014 12: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 1Y5Zjk-0003vF-6T;
	Mon, 29 Dec 2014 12:47:52 +0000
Date: Mon, 29 Dec 2014 12:47:52 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32811-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] 32811: 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 32811 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32811/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          a0056d0a8334e65d68eb888e9241fd3f5c04b4fc
baseline version:
 rumpuserxen          5f4031a1d23e08f1f470e0af788c0296223ae6b5

------------------------------------------------------------
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=a0056d0a8334e65d68eb888e9241fd3f5c04b4fc
+ . 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 a0056d0a8334e65d68eb888e9241fd3f5c04b4fc
+ branch=rumpuserxen
+ revision=a0056d0a8334e65d68eb888e9241fd3f5c04b4fc
+ . 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 a0056d0a8334e65d68eb888e9241fd3f5c04b4fc:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   5f4031a..a0056d0  a0056d0a8334e65d68eb888e9241fd3f5c04b4fc -> 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 Dec 29 12:47:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 12: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 1Y5Zjq-0004g1-1W; Mon, 29 Dec 2014 12:47: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 1Y5Zjo-0004fr-UR
	for xen-devel@lists.xensource.com; Mon, 29 Dec 2014 12:47:57 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	28/DB-02699-C7D41A45; Mon, 29 Dec 2014 12:47:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419857274!12169978!1
X-Originating-IP: [66.165.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 27649 invoked from network); 29 Dec 2014 12:47:55 -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;
	29 Dec 2014 12:47:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="208852206"
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.210.2; Mon, 29 Dec 2014 07: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 1Y5Zjk-00081R-Bg;
	Mon, 29 Dec 2014 12: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 1Y5Zjk-0003vF-6T;
	Mon, 29 Dec 2014 12:47:52 +0000
Date: Mon, 29 Dec 2014 12:47:52 +0000
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@lists.sourceforge.net>
Message-ID: <osstest-32811-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] 32811: 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 32811 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32811/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 rumpuserxen          a0056d0a8334e65d68eb888e9241fd3f5c04b4fc
baseline version:
 rumpuserxen          5f4031a1d23e08f1f470e0af788c0296223ae6b5

------------------------------------------------------------
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=a0056d0a8334e65d68eb888e9241fd3f5c04b4fc
+ . 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 a0056d0a8334e65d68eb888e9241fd3f5c04b4fc
+ branch=rumpuserxen
+ revision=a0056d0a8334e65d68eb888e9241fd3f5c04b4fc
+ . 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 a0056d0a8334e65d68eb888e9241fd3f5c04b4fc:xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
   5f4031a..a0056d0  a0056d0a8334e65d68eb888e9241fd3f5c04b4fc -> 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 Dec 29 12:48:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 12: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 1Y5ZkM-0004kF-FY; Mon, 29 Dec 2014 12:48:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiaoding1@huawei.com>) id 1Y5ZkL-0004k1-A3
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 12:48:29 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	28/C1-02696-C9D41A45; Mon, 29 Dec 2014 12:48:28 +0000
X-Env-Sender: xiaoding1@huawei.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1419857304!17611090!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22101 invoked from network); 29 Dec 2014 12:48:27 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2014 12:48:27 -0000
Received: from 172.24.2.119 (EHLO szxema411-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AZI06181; Mon, 29 Dec 2014 20:48:19 +0800 (CST)
Received: from SZXEMA505-MBS.china.huawei.com ([169.254.2.197]) by
	szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id
	14.03.0158.001; Mon, 29 Dec 2014 20:48:09 +0800
From: "Xiaoding (B)" <xiaoding1@huawei.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: How can I get the real load of my program ?
Thread-Index: AdAjZbILVW2bpL9gTiONPMPlh1hlIQ==
Date: Mon, 29 Dec 2014 12:48:08 +0000
Message-ID: <89E0966AE9A1C3499DBCD33F337DA29B27922CFE@szxema505-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.146.123.164]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020201.54A14DC2.00F1, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.197,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 00b2610a8a02166ac5b4c6c1ce0a634b
Cc: "Zhangleiqiang \(Trump\)" <zhangleiqiang@huawei.com>,
	"ssdxiao@163.com" <ssdxiao@163.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: [Xen-devel] How can I get the real load of my program ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2704129287439142338=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2704129287439142338==
Content-Language: zh-CN
Content-Type: multipart/alternative;
	boundary="_000_89E0966AE9A1C3499DBCD33F337DA29B27922CFEszxema505mbschi_"

--_000_89E0966AE9A1C3499DBCD33F337DA29B27922CFEszxema505mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGmjrEFsbA0KDQpXaGVuIG15IHByb2dyYW0gcnVuIG1lbWNweSBpbiBEb21Vo6wgSSB1c2UgdG9w
IG1vbml0b3IgdGhlIGNwdSBvbmx5IHVzaW5nIDMwJQ0KQnV0IHdoZW4gSSB1c2UgeGVudG9wo6xJ
IGZpbmQgRG9tVSB1c2UgY3B1IDEwMCUNCg0KSG93IGNhbiBJIGdldCB0aGUgcmVhbCBsb2FkIG9m
IG15IHByb2dyYW0gPw0KDQoNCg0KWGlhb2RpbmcNClJlZ2FyZHMNCg0KDQoNCg0K

--_000_89E0966AE9A1C3499DBCD33F337DA29B27922CFEszxema505mbschi_
Content-Type: text/html; charset="gb2312"
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:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:m=3D"http://schema=
s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html=
40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML =D4=A4=C9=E8=B8=F1=CA=BD Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLChar
	{mso-style-name:"HTML =D4=A4=C9=E8=B8=F1=CA=BD Char";
	mso-style-priority:99;
	mso-style-link:"HTML =D4=A4=C9=E8=B8=F1=CA=BD";
	font-family:=CB=CE=CC=E5;}
.MsoChpDefault
	{mso-style-type:export-only;}
/* Page Definitions */
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple" style=3D"text-justify-t=
rim:punctuation">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt">Hi</=
span><span style=3D"font-size:12.0pt;font-family:=CB=CE=CC=E5">=A3=AC</span=
><span lang=3D"EN-US" style=3D"font-size:12.0pt">All<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt;color=
:#343434;background:#FBFCFE"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt">When=
 my program run memcpy in DomU</span><span style=3D"font-size:12.0pt;font-f=
amily:=CB=CE=CC=E5">=A3=AC</span><span lang=3D"EN-US" style=3D"font-size:12=
.0pt"> I use top monitor the cpu only using 30%<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt">But =
when I use xentop</span><span style=3D"font-size:12.0pt;font-family:=CB=CE=
=CC=E5">=A3=AC</span><span lang=3D"EN-US" style=3D"font-size:12.0pt">I find=
 DomU use cpu 100%<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt">How =
can I get the real load of my program ?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Xiaoding<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Regards<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:&quot;Aria=
l&quot;,&quot;sans-serif&quot;;color:#343434;background:#FBFCFE"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:&quot;Aria=
l&quot;,&quot;sans-serif&quot;;color:#343434;background:#FBFCFE"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:&quot;Aria=
l&quot;,&quot;sans-serif&quot;;color:#343434;background:#FBFCFE"><o:p>&nbsp=
;</o:p></span></p>
</div>
</body>
</html>

--_000_89E0966AE9A1C3499DBCD33F337DA29B27922CFEszxema505mbschi_--



--===============2704129287439142338==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2704129287439142338==--



From xen-devel-bounces@lists.xen.org Mon Dec 29 12:48:31 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 12: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 1Y5ZkM-0004kF-FY; Mon, 29 Dec 2014 12:48:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiaoding1@huawei.com>) id 1Y5ZkL-0004k1-A3
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 12:48:29 +0000
Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id
	28/C1-02696-C9D41A45; Mon, 29 Dec 2014 12:48:28 +0000
X-Env-Sender: xiaoding1@huawei.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1419857304!17611090!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22101 invoked from network); 29 Dec 2014 12:48:27 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2014 12:48:27 -0000
Received: from 172.24.2.119 (EHLO szxema411-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AZI06181; Mon, 29 Dec 2014 20:48:19 +0800 (CST)
Received: from SZXEMA505-MBS.china.huawei.com ([169.254.2.197]) by
	szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id
	14.03.0158.001; Mon, 29 Dec 2014 20:48:09 +0800
From: "Xiaoding (B)" <xiaoding1@huawei.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: How can I get the real load of my program ?
Thread-Index: AdAjZbILVW2bpL9gTiONPMPlh1hlIQ==
Date: Mon, 29 Dec 2014 12:48:08 +0000
Message-ID: <89E0966AE9A1C3499DBCD33F337DA29B27922CFE@szxema505-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.146.123.164]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020201.54A14DC2.00F1, ss=1, re=0.000, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.197,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 00b2610a8a02166ac5b4c6c1ce0a634b
Cc: "Zhangleiqiang \(Trump\)" <zhangleiqiang@huawei.com>,
	"ssdxiao@163.com" <ssdxiao@163.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: [Xen-devel] How can I get the real load of my program ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2704129287439142338=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2704129287439142338==
Content-Language: zh-CN
Content-Type: multipart/alternative;
	boundary="_000_89E0966AE9A1C3499DBCD33F337DA29B27922CFEszxema505mbschi_"

--_000_89E0966AE9A1C3499DBCD33F337DA29B27922CFEszxema505mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGmjrEFsbA0KDQpXaGVuIG15IHByb2dyYW0gcnVuIG1lbWNweSBpbiBEb21Vo6wgSSB1c2UgdG9w
IG1vbml0b3IgdGhlIGNwdSBvbmx5IHVzaW5nIDMwJQ0KQnV0IHdoZW4gSSB1c2UgeGVudG9wo6xJ
IGZpbmQgRG9tVSB1c2UgY3B1IDEwMCUNCg0KSG93IGNhbiBJIGdldCB0aGUgcmVhbCBsb2FkIG9m
IG15IHByb2dyYW0gPw0KDQoNCg0KWGlhb2RpbmcNClJlZ2FyZHMNCg0KDQoNCg0K

--_000_89E0966AE9A1C3499DBCD33F337DA29B27922CFEszxema505mbschi_
Content-Type: text/html; charset="gb2312"
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:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:m=3D"http://schema=
s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html=
40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML =D4=A4=C9=E8=B8=F1=CA=BD Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLChar
	{mso-style-name:"HTML =D4=A4=C9=E8=B8=F1=CA=BD Char";
	mso-style-priority:99;
	mso-style-link:"HTML =D4=A4=C9=E8=B8=F1=CA=BD";
	font-family:=CB=CE=CC=E5;}
.MsoChpDefault
	{mso-style-type:export-only;}
/* Page Definitions */
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple" style=3D"text-justify-t=
rim:punctuation">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt">Hi</=
span><span style=3D"font-size:12.0pt;font-family:=CB=CE=CC=E5">=A3=AC</span=
><span lang=3D"EN-US" style=3D"font-size:12.0pt">All<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt;color=
:#343434;background:#FBFCFE"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt">When=
 my program run memcpy in DomU</span><span style=3D"font-size:12.0pt;font-f=
amily:=CB=CE=CC=E5">=A3=AC</span><span lang=3D"EN-US" style=3D"font-size:12=
.0pt"> I use top monitor the cpu only using 30%<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt">But =
when I use xentop</span><span style=3D"font-size:12.0pt;font-family:=CB=CE=
=CC=E5">=A3=AC</span><span lang=3D"EN-US" style=3D"font-size:12.0pt">I find=
 DomU use cpu 100%<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt">How =
can I get the real load of my program ?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Xiaoding<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Regards<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:12.0pt"><o:p=
>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:&quot;Aria=
l&quot;,&quot;sans-serif&quot;;color:#343434;background:#FBFCFE"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:&quot;Aria=
l&quot;,&quot;sans-serif&quot;;color:#343434;background:#FBFCFE"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:&quot;Aria=
l&quot;,&quot;sans-serif&quot;;color:#343434;background:#FBFCFE"><o:p>&nbsp=
;</o:p></span></p>
</div>
</body>
</html>

--_000_89E0966AE9A1C3499DBCD33F337DA29B27922CFEszxema505mbschi_--



--===============2704129287439142338==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2704129287439142338==--



From xen-devel-bounces@lists.xen.org Mon Dec 29 13:02:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 13:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5ZxA-0005Dh-1V; Mon, 29 Dec 2014 13:01:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Y5Zx7-0005Dc-Vc
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 13:01:42 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	55/69-26652-5B051A45; Mon, 29 Dec 2014 13:01:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1419858099!15496277!1
X-Originating-IP: [66.165.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 9950 invoked from network); 29 Dec 2014 13:01:40 -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;
	29 Dec 2014 13:01:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="208855259"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 29 Dec 2014 08:01:37 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Y5Zx3-0007RO-9b;
	Mon, 29 Dec 2014 13:01:37 +0000
Date: Mon, 29 Dec 2014 13:01:37 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Peter Kay <syllopsium@syllopsium.co.uk>
Message-ID: <20141229130136.GA12240@zion.uk.xensource.com>
References: <CAN4Onoho_BKS48ECqXf=wF=MMLCah80yGZyEmm1O7G6fDEQtHA@mail.gmail.com>
	<1418983542.20028.5.camel@citrix.com>
	<CAN4Onog81C3QPssC7Cm3UDqX98fgcQC8XuqO09WrKrP2GH6oQg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN4Onog81C3QPssC7Cm3UDqX98fgcQC8XuqO09WrKrP2GH6oQg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Parallel make 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

Please don't top post.

On Fri, Dec 19, 2014 at 10:09:31PM +0000, Peter Kay wrote:
> Thanks, see attached :
> 
> This is on Salix 14.1 running the 3.17.4 kernel. That's not particularly
> relevant though, as I had exactly the same error on Debian using other
> kernel versions.
> 

Looking at your build log

gcc     -pthread -Wl,-soname -Wl,libxenstore.so.3.0 -shared -o libxenstore.so.3.0.3 xs.opic xs_lib.opic
ar rcs libxenstore.a xs.o xs_lib.o
gcc xs_tdb_dump.o utils.o tdb.o talloc.o     -o xs_tdb_dump
gcc xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o xenstored_posix.o     /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenctrl.so  -o xenstored
gcc init-xenstore-domain.o libxenstore.so     /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenctrl.so /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenguest.so /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/xenstore/libxenstore.so -o init-xenstore-domain
gcc: error: libxenstore.so: No such file or directory
gcc: error: /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/xenstore/libxenstore.so: No such file or directory
make[4]: *** [init-xenstore-domain] Error 1
make[4]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore'
make[3]: *** [subdir-install-xenstore] Error 2
make[3]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools'
make[2]: *** [subdirs-install] Error 2
make[2]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools'
make[1]: *** [install-tools] Error 2
make[1]: *** Waiting for unfinished jobs....

libxenstore.so is missing. However Makefile dependency ensures the
compilation of init-xenstore-domain does not proceed unless
libxenstore.so exists.

Two "ln -sf" are missing in your log.

ln -sf libxenstore.so.3.0.3 libxenstore.so.3.0
ln -sf libxenstore.so.3.0 libxenstore.so

?

Wei.

> On 19 December 2014 at 10:05, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2014-12-18 at 22:36 +0000, Peter Kay wrote:
> > > Is parallel make supported for xen? If I compile 4.5 rc4 (although the
> > > error exists with many other prior releases too) with make -j4 world
> > > it fails part way through with an error 2. This does not occur with a
> > > straight 'make world'
> >
> > It is expected to work in general, I build with -j12 all the time. There
> > are some subdirs which enforce serialised build for various reasons,
> > perhaps there is one more we've not spotted or perhaps there is just a
> > bug in the Makefiles somewhere.
> >
> > Please post your build logs showing the error.
> >
> > Ian.
> >
> >
> >


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 29 13:02:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 13:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5ZxA-0005Dh-1V; Mon, 29 Dec 2014 13:01:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Y5Zx7-0005Dc-Vc
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 13:01:42 +0000
Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id
	55/69-26652-5B051A45; Mon, 29 Dec 2014 13:01:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1419858099!15496277!1
X-Originating-IP: [66.165.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 9950 invoked from network); 29 Dec 2014 13:01:40 -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;
	29 Dec 2014 13:01:40 -0000
X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="208855259"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 29 Dec 2014 08:01:37 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1Y5Zx3-0007RO-9b;
	Mon, 29 Dec 2014 13:01:37 +0000
Date: Mon, 29 Dec 2014 13:01:37 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Peter Kay <syllopsium@syllopsium.co.uk>
Message-ID: <20141229130136.GA12240@zion.uk.xensource.com>
References: <CAN4Onoho_BKS48ECqXf=wF=MMLCah80yGZyEmm1O7G6fDEQtHA@mail.gmail.com>
	<1418983542.20028.5.camel@citrix.com>
	<CAN4Onog81C3QPssC7Cm3UDqX98fgcQC8XuqO09WrKrP2GH6oQg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN4Onog81C3QPssC7Cm3UDqX98fgcQC8XuqO09WrKrP2GH6oQg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Parallel make 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

Please don't top post.

On Fri, Dec 19, 2014 at 10:09:31PM +0000, Peter Kay wrote:
> Thanks, see attached :
> 
> This is on Salix 14.1 running the 3.17.4 kernel. That's not particularly
> relevant though, as I had exactly the same error on Debian using other
> kernel versions.
> 

Looking at your build log

gcc     -pthread -Wl,-soname -Wl,libxenstore.so.3.0 -shared -o libxenstore.so.3.0.3 xs.opic xs_lib.opic
ar rcs libxenstore.a xs.o xs_lib.o
gcc xs_tdb_dump.o utils.o tdb.o talloc.o     -o xs_tdb_dump
gcc xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o xenstored_posix.o     /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenctrl.so  -o xenstored
gcc init-xenstore-domain.o libxenstore.so     /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenctrl.so /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenguest.so /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/xenstore/libxenstore.so -o init-xenstore-domain
gcc: error: libxenstore.so: No such file or directory
gcc: error: /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/xenstore/libxenstore.so: No such file or directory
make[4]: *** [init-xenstore-domain] Error 1
make[4]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore'
make[3]: *** [subdir-install-xenstore] Error 2
make[3]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools'
make[2]: *** [subdirs-install] Error 2
make[2]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools'
make[1]: *** [install-tools] Error 2
make[1]: *** Waiting for unfinished jobs....

libxenstore.so is missing. However Makefile dependency ensures the
compilation of init-xenstore-domain does not proceed unless
libxenstore.so exists.

Two "ln -sf" are missing in your log.

ln -sf libxenstore.so.3.0.3 libxenstore.so.3.0
ln -sf libxenstore.so.3.0 libxenstore.so

?

Wei.

> On 19 December 2014 at 10:05, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2014-12-18 at 22:36 +0000, Peter Kay wrote:
> > > Is parallel make supported for xen? If I compile 4.5 rc4 (although the
> > > error exists with many other prior releases too) with make -j4 world
> > > it fails part way through with an error 2. This does not occur with a
> > > straight 'make world'
> >
> > It is expected to work in general, I build with -j12 all the time. There
> > are some subdirs which enforce serialised build for various reasons,
> > perhaps there is one more we've not spotted or perhaps there is just a
> > bug in the Makefiles somewhere.
> >
> > Please post your build logs showing the error.
> >
> > Ian.
> >
> >
> >


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 29 13:14:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 13: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 1Y5a8l-0005bK-9Q; Mon, 29 Dec 2014 13:13:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y5a8k-0005bF-As
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 13:13:42 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	20/58-02957-58351A45; Mon, 29 Dec 2014 13:13:41 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1419858818!17599786!1
X-Originating-IP: [209.85.218.53]
X-SpamReason: No, hits=2.6 required=7.0 tests=BIZ_TLD,HTML_40_50,
	HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20442 invoked from network); 29 Dec 2014 13:13:39 -0000
Received: from mail-oi0-f53.google.com (HELO mail-oi0-f53.google.com)
	(209.85.218.53)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2014 13:13:39 -0000
Received: by mail-oi0-f53.google.com with SMTP id g201so28946200oib.12
	for <xen-devel@lists.xen.org>; Mon, 29 Dec 2014 05:13: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
	:cc:content-type;
	bh=AbwdgWPD1RPPuKoDTk4SMM73t0LS6+wwJN598ozvV00=;
	b=Jn6trlKDDPmMgLl21QZru4ltxYyqrT70/uv3b/Nffc8wCXqXoIR6krSDgvWykke2EC
	rXvEo/Wn/6W4St8TKaeK5i4xVslXI8Ywyfpl+UnTteKxKIgQDfH+zGAQO+V9/C4McdZ8
	k43sykw1yfQsO09WwOtOZiW8Nv26fILS7dfK68PCRoHelewajqI/FPLPeYZ7zRBtmva4
	39w3WKjDMbxreb0cNYPSuz+1ieY7rsGOsI0PuPlxiSyKpDvoCiES2AUeJ4/EvQMO+8gr
	XHxTGLlUD4Y9XTkeFETTS2YZV/KNTLq1/sWpCde7WbYHOA7gUzoNUWJ4ikeTKvEQI/pT
	SCRw==
MIME-Version: 1.0
X-Received: by 10.202.58.87 with SMTP id h84mr31297573oia.118.1419858818148;
	Mon, 29 Dec 2014 05:13:38 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Mon, 29 Dec 2014 05:13:38 -0800 (PST)
In-Reply-To: <CAE5x5YU8R9PibP-_xj+uYNc_rqOL0rnuHvVF5Ymz32RngDEgFw@mail.gmail.com>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
	<549EBDCC.3090102@m2r.biz>
	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
	<CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>
	<CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>
	<CAE5x5YU8R9PibP-_xj+uYNc_rqOL0rnuHvVF5Ymz32RngDEgFw@mail.gmail.com>
Date: Mon, 29 Dec 2014 14:13:38 +0100
Message-ID: <CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3963515054951027305=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3963515054951027305==
Content-Type: multipart/alternative; boundary=001a113cd57c7caef3050b5aa449

--001a113cd57c7caef3050b5aa449
Content-Type: text/plain; charset=UTF-8

ok, I'm trying to patch the files with yours,


I need to do it manually right?

git apply is not working here.


regards

greg

2014-12-29 13:46 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:

> There is an error in pageqs describing how to compile from sources as in
> 4.5
>
> cat .config
> PYTHON_PREFIX_ARG=--install-layout=deb
>
> is in fact in .INSTALL
>
>
>
> 2014-12-29 1:20 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>
>> well figured out it is because you have to "enforce" locale:  export
>> LC_ALL=en_US.utf-8 if keyboard mapping is else
>>
>> 2014-12-28 21:19 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>>
>>> Trying to compile xen 4.5RC4 in order to test your patch I end up with
>>> these errors compiling the Seabios directories,
>>>
>>> any idea?
>>>
>>>   Compiling to assembler out/src/asm-offsets.s
>>>   Generating offset file out/asm-offsets.h
>>>   Compiling (16bit) out/romlayout.o
>>>   Building ld scripts
>>> Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
>>> Traceback (most recent call last):
>>>   File "./scripts/layoutrom.py", line 709, in <module>
>>>     main()
>>>   File "./scripts/layoutrom.py", line 671, in main
>>>     info16 = parseObjDump(infile16, '16')
>>>   File "./scripts/layoutrom.py", line 586, in parseObjDump
>>>     relocsection = sectionmap[sectionname]
>>> KeyError:
>>> '.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
>>> Makefile:155: recipe for target 'out/romlayout16.lds' failed
>>> make[6]: *** [out/romlayout16.lds] Error 1
>>> make[6]: Leaving directory
>>> '/home/goon/xen/tools/firmware/seabios-dir-remote'
>>> /home/goon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for
>>> target 'subdir-all-seabios-dir' failed
>>>
>>>
>>>
>>> 2014-12-27 17:35 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>>>
>>>> Hello Fabio,
>>>>
>>>> Sure thing I will help debug the win7 and the win8 versions.
>>>> Where to start?
>>>>
>>>> I'll try to see if I can patch with patch from
>>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>>> and if not will post result.
>>>>
>>>>
>>>> best regards,
>>>>
>>>>
>>>> greg Bahde
>>>>
>>>> 2014-12-27 15:10 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:
>>>>
>>>>>
>>>>> Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>>>>
>>>>>   I tried to install Qxl drivers under win7/win 2k8/win8.1
>>>>> all       x64 versions, without any luck.
>>>>>
>>>>>
>>>>> admin message is as follow:
>>>>> Driver Management concluded the process to install driver
>>>>> FileRepository\qxl.inf_amd64_
>>>>> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
>>>>> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
>>>>> following status: 0xe000022d.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  Does
>>>>> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>>>>
>>>>>  can it be installed on my xen stack?
>>>>>
>>>>>
>>>>> Yes but probably require a small refresh, I always posted the patch
>>>>> based on updated xen-unstable.
>>>>>
>>>>> Here qxl patch refreshed for xen 4.5 if needed:
>>>>>
>>>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>>>>
>>>>> Here the latest spice guest tools for windows with qxl driver included:
>>>>>
>>>>> http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>>>>>
>>>>> Windows >=8 and similar require a new qxl drivers, there are a beta
>>>>> build but latest tried some months ago have serious bug and I not found
>>>>> recent build full working on windows 8.
>>>>>
>>>>> On xen windows 7 domUs qxl works good except a problem after
>>>>> save/restore and on linux domUs is not working, for now I not found exactly
>>>>> cause and solution.
>>>>> On mailing list up to 2 years ago you can find many my mails about.
>>>>> Any help to test it is appreciated.
>>>>>
>>>>> Sorry for my bad english.
>>>>>
>>>>>
>>>>> Also, can  I get invited at xendevel irc ?
>>>>> regards
>>>>>
>>>>>  Greg
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing listXen-devel@lists.xen.orghttp://lists.xen.org/xen-devel
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

--001a113cd57c7caef3050b5aa449
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>ok, I&#39;m trying to patch the files with =
yours,<br><br><br></div>I need to do it manually right? <br><br>git apply i=
s not working here. <br><br><br></div>regards<br><br></div>greg<br></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-12-29 13:46 GM=
T+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.gooni=
e@gmail.com" target=3D"_blank">monsieur.goonie@gmail.com</a>&gt;</span>:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">There is an error in pageq=
s describing how to compile from sources as in 4.5 <br><pre>cat .config
PYTHON_PREFIX_ARG=3D--install-layout=3Ddeb
<br></pre><pre>is in fact in .INSTALL<br></pre><br></div><div class=3D"HOEn=
Zb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">2014-12-29 1:20 GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=
=3D"mailto:monsieur.goonie@gmail.com" target=3D"_blank">monsieur.goonie@gma=
il.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 dir=3D"ltr"><=
div>well figured out it is because you have to &quot;enforce&quot; locale:=
=C2=A0 export LC_ALL=3Den_US.utf-8 if keyboard mapping is else<br></div></d=
iv><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014=
-12-28 21:19 GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=3D"mailto=
:monsieur.goonie@gmail.com" target=3D"_blank">monsieur.goonie@gmail.com</a>=
&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Trying=
 to compile xen 4.5RC4 in order to test your patch I end up with=C2=A0 thes=
e errors compiling the Seabios directories,<br><br></div>any idea?<br><br>=
=C2=A0 Compiling to assembler out/src/asm-offsets.s<br>=C2=A0 Generating of=
fset file out/asm-offsets.h<br>=C2=A0 Compiling (16bit) out/romlayout.o<br>=
=C2=A0 Building ld scripts<br>Version: rel-1.7.5-0-ge51488c-20141228_210340=
-E766<br>Traceback (most recent call last):<br>=C2=A0 File &quot;./scripts/=
layoutrom.py&quot;, line 709, in &lt;module&gt;<br>=C2=A0=C2=A0=C2=A0 main(=
)<br>=C2=A0 File &quot;./scripts/layoutrom.py&quot;, line 671, in main<br>=
=C2=A0=C2=A0=C2=A0 info16 =3D parseObjDump(infile16, &#39;16&#39;)<br>=C2=
=A0 File &quot;./scripts/layoutrom.py&quot;, line 586, in parseObjDump<br>=
=C2=A0=C2=A0=C2=A0 relocsection =3D sectionmap[sectionname]<br>KeyError: &#=
39;.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.=
79&#39;<br>Makefile:155: recipe for target &#39;out/romlayout16.lds&#39; fa=
iled<br>make[6]: *** [out/romlayout16.lds] Error 1<br>make[6]: Leaving dire=
ctory &#39;/home/goon/xen/tools/firmware/seabios-dir-remote&#39;<br>/home/g=
oon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for target &#39;sub=
dir-all-seabios-dir&#39; failed<br><br><br></div><div><div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">2014-12-27 17:35 GMT+01:00 Goonie=
 Windy <span dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.goonie@gmail.com" t=
arget=3D"_blank">monsieur.goonie@gmail.com</a>&gt;</span>:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div><div>Hello Fabio,<br><br>Sure =
thing I will help debug the win7 and the win8 versions.<br></div>Where to s=
tart?<br><br></div>I&#39;ll try to see if I can patch with patch from <a hr=
ef=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa1187=
9e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0=
e8c7e421fafba67aa11879e8b8fe</a> and if not will post result.<br><br><br>be=
st regards,<br><br><br></div>greg Bahde<br></div><div><div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">2014-12-27 15:10 GMT+01:00 Fabio =
Fantoni <span dir=3D"ltr">&lt;<a href=3D"mailto:fabio.fantoni@m2r.biz" targ=
et=3D"_blank">fabio.fantoni@m2r.biz</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">
    <br>
    <div>Il 27/12/2014 02:15, Goonie Windy ha
      scritto:<br>
    </div><span>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>I tried to install Qxl drivers under win7/win
              2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 al=
l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64 versions, without any
              luck.<br>
              <br>
              <br>
              admin message is as follow:<br>
              Driver Management concluded the process to install driver
              FileRepository\qxl.inf_amd64_
              <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf for Device
                Instance ID
                PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&=
amp;267A616A&amp;1&amp;28
                with the following status: 0xe000022d.</div>
              <br>
              <br>
              <br>
              <br>
            </div>
            Does <br>
            <a href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05=
/msg03214.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-de=
vel/2014-05/msg03214.html</a><br>
            <br>
          </div>
          can it be installed on my xen stack? <br>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes but probably require a small refresh, I always posted the patch
    based on updated xen-unstable. <br>
    <br>
    Here qxl patch refreshed for xen 4.5 if needed:<br>
<a href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67a=
a11879e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8=
d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
    <br>
    Here the latest spice guest tools for windows with qxl driver
    included:<br>
<a href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/s=
pice-guest-tools-0.74.exe" target=3D"_blank">http://www.spice-space.org/dow=
nload/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
    <br>
    Windows &gt;=3D8 and similar require a new qxl drivers, there are a
    beta build but latest tried some months ago have serious bug and I
    not found recent build full working on windows 8.<br>
    <br>
    On xen windows 7 domUs qxl works good except a problem after
    save/restore and on linux domUs is not working, for now I not found
    exactly cause and solution.<br>
    On mailing list up to 2 years ago you can find many my mails about.<br>
    Any help to test it is appreciated.<br>
    <br>
    Sorry for my bad english.<br>
    <br>
    <blockquote type=3D"cite"><span>
      <div dir=3D"ltr">
        <div><br>
          Also, can=C2=A0 I get invited at xendevel irc ?<br>
          regards<br>
          <br>
        </div>
        Greg <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><pre>_______________________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a113cd57c7caef3050b5aa449--


--===============3963515054951027305==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3963515054951027305==--


From xen-devel-bounces@lists.xen.org Mon Dec 29 13:14:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 13: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 1Y5a8l-0005bK-9Q; Mon, 29 Dec 2014 13:13:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y5a8k-0005bF-As
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 13:13:42 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	20/58-02957-58351A45; Mon, 29 Dec 2014 13:13:41 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1419858818!17599786!1
X-Originating-IP: [209.85.218.53]
X-SpamReason: No, hits=2.6 required=7.0 tests=BIZ_TLD,HTML_40_50,
	HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20442 invoked from network); 29 Dec 2014 13:13:39 -0000
Received: from mail-oi0-f53.google.com (HELO mail-oi0-f53.google.com)
	(209.85.218.53)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2014 13:13:39 -0000
Received: by mail-oi0-f53.google.com with SMTP id g201so28946200oib.12
	for <xen-devel@lists.xen.org>; Mon, 29 Dec 2014 05:13: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
	:cc:content-type;
	bh=AbwdgWPD1RPPuKoDTk4SMM73t0LS6+wwJN598ozvV00=;
	b=Jn6trlKDDPmMgLl21QZru4ltxYyqrT70/uv3b/Nffc8wCXqXoIR6krSDgvWykke2EC
	rXvEo/Wn/6W4St8TKaeK5i4xVslXI8Ywyfpl+UnTteKxKIgQDfH+zGAQO+V9/C4McdZ8
	k43sykw1yfQsO09WwOtOZiW8Nv26fILS7dfK68PCRoHelewajqI/FPLPeYZ7zRBtmva4
	39w3WKjDMbxreb0cNYPSuz+1ieY7rsGOsI0PuPlxiSyKpDvoCiES2AUeJ4/EvQMO+8gr
	XHxTGLlUD4Y9XTkeFETTS2YZV/KNTLq1/sWpCde7WbYHOA7gUzoNUWJ4ikeTKvEQI/pT
	SCRw==
MIME-Version: 1.0
X-Received: by 10.202.58.87 with SMTP id h84mr31297573oia.118.1419858818148;
	Mon, 29 Dec 2014 05:13:38 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Mon, 29 Dec 2014 05:13:38 -0800 (PST)
In-Reply-To: <CAE5x5YU8R9PibP-_xj+uYNc_rqOL0rnuHvVF5Ymz32RngDEgFw@mail.gmail.com>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
	<549EBDCC.3090102@m2r.biz>
	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
	<CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>
	<CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>
	<CAE5x5YU8R9PibP-_xj+uYNc_rqOL0rnuHvVF5Ymz32RngDEgFw@mail.gmail.com>
Date: Mon, 29 Dec 2014 14:13:38 +0100
Message-ID: <CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3963515054951027305=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3963515054951027305==
Content-Type: multipart/alternative; boundary=001a113cd57c7caef3050b5aa449

--001a113cd57c7caef3050b5aa449
Content-Type: text/plain; charset=UTF-8

ok, I'm trying to patch the files with yours,


I need to do it manually right?

git apply is not working here.


regards

greg

2014-12-29 13:46 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:

> There is an error in pageqs describing how to compile from sources as in
> 4.5
>
> cat .config
> PYTHON_PREFIX_ARG=--install-layout=deb
>
> is in fact in .INSTALL
>
>
>
> 2014-12-29 1:20 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>
>> well figured out it is because you have to "enforce" locale:  export
>> LC_ALL=en_US.utf-8 if keyboard mapping is else
>>
>> 2014-12-28 21:19 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>>
>>> Trying to compile xen 4.5RC4 in order to test your patch I end up with
>>> these errors compiling the Seabios directories,
>>>
>>> any idea?
>>>
>>>   Compiling to assembler out/src/asm-offsets.s
>>>   Generating offset file out/asm-offsets.h
>>>   Compiling (16bit) out/romlayout.o
>>>   Building ld scripts
>>> Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
>>> Traceback (most recent call last):
>>>   File "./scripts/layoutrom.py", line 709, in <module>
>>>     main()
>>>   File "./scripts/layoutrom.py", line 671, in main
>>>     info16 = parseObjDump(infile16, '16')
>>>   File "./scripts/layoutrom.py", line 586, in parseObjDump
>>>     relocsection = sectionmap[sectionname]
>>> KeyError:
>>> '.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
>>> Makefile:155: recipe for target 'out/romlayout16.lds' failed
>>> make[6]: *** [out/romlayout16.lds] Error 1
>>> make[6]: Leaving directory
>>> '/home/goon/xen/tools/firmware/seabios-dir-remote'
>>> /home/goon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for
>>> target 'subdir-all-seabios-dir' failed
>>>
>>>
>>>
>>> 2014-12-27 17:35 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>>>
>>>> Hello Fabio,
>>>>
>>>> Sure thing I will help debug the win7 and the win8 versions.
>>>> Where to start?
>>>>
>>>> I'll try to see if I can patch with patch from
>>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>>> and if not will post result.
>>>>
>>>>
>>>> best regards,
>>>>
>>>>
>>>> greg Bahde
>>>>
>>>> 2014-12-27 15:10 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:
>>>>
>>>>>
>>>>> Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>>>>
>>>>>   I tried to install Qxl drivers under win7/win 2k8/win8.1
>>>>> all       x64 versions, without any luck.
>>>>>
>>>>>
>>>>> admin message is as follow:
>>>>> Driver Management concluded the process to install driver
>>>>> FileRepository\qxl.inf_amd64_
>>>>> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
>>>>> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
>>>>> following status: 0xe000022d.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  Does
>>>>> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>>>>
>>>>>  can it be installed on my xen stack?
>>>>>
>>>>>
>>>>> Yes but probably require a small refresh, I always posted the patch
>>>>> based on updated xen-unstable.
>>>>>
>>>>> Here qxl patch refreshed for xen 4.5 if needed:
>>>>>
>>>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>>>>
>>>>> Here the latest spice guest tools for windows with qxl driver included:
>>>>>
>>>>> http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>>>>>
>>>>> Windows >=8 and similar require a new qxl drivers, there are a beta
>>>>> build but latest tried some months ago have serious bug and I not found
>>>>> recent build full working on windows 8.
>>>>>
>>>>> On xen windows 7 domUs qxl works good except a problem after
>>>>> save/restore and on linux domUs is not working, for now I not found exactly
>>>>> cause and solution.
>>>>> On mailing list up to 2 years ago you can find many my mails about.
>>>>> Any help to test it is appreciated.
>>>>>
>>>>> Sorry for my bad english.
>>>>>
>>>>>
>>>>> Also, can  I get invited at xendevel irc ?
>>>>> regards
>>>>>
>>>>>  Greg
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing listXen-devel@lists.xen.orghttp://lists.xen.org/xen-devel
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

--001a113cd57c7caef3050b5aa449
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>ok, I&#39;m trying to patch the files with =
yours,<br><br><br></div>I need to do it manually right? <br><br>git apply i=
s not working here. <br><br><br></div>regards<br><br></div>greg<br></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-12-29 13:46 GM=
T+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.gooni=
e@gmail.com" target=3D"_blank">monsieur.goonie@gmail.com</a>&gt;</span>:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">There is an error in pageq=
s describing how to compile from sources as in 4.5 <br><pre>cat .config
PYTHON_PREFIX_ARG=3D--install-layout=3Ddeb
<br></pre><pre>is in fact in .INSTALL<br></pre><br></div><div class=3D"HOEn=
Zb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">2014-12-29 1:20 GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=
=3D"mailto:monsieur.goonie@gmail.com" target=3D"_blank">monsieur.goonie@gma=
il.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 dir=3D"ltr"><=
div>well figured out it is because you have to &quot;enforce&quot; locale:=
=C2=A0 export LC_ALL=3Den_US.utf-8 if keyboard mapping is else<br></div></d=
iv><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014=
-12-28 21:19 GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a href=3D"mailto=
:monsieur.goonie@gmail.com" target=3D"_blank">monsieur.goonie@gmail.com</a>=
&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Trying=
 to compile xen 4.5RC4 in order to test your patch I end up with=C2=A0 thes=
e errors compiling the Seabios directories,<br><br></div>any idea?<br><br>=
=C2=A0 Compiling to assembler out/src/asm-offsets.s<br>=C2=A0 Generating of=
fset file out/asm-offsets.h<br>=C2=A0 Compiling (16bit) out/romlayout.o<br>=
=C2=A0 Building ld scripts<br>Version: rel-1.7.5-0-ge51488c-20141228_210340=
-E766<br>Traceback (most recent call last):<br>=C2=A0 File &quot;./scripts/=
layoutrom.py&quot;, line 709, in &lt;module&gt;<br>=C2=A0=C2=A0=C2=A0 main(=
)<br>=C2=A0 File &quot;./scripts/layoutrom.py&quot;, line 671, in main<br>=
=C2=A0=C2=A0=C2=A0 info16 =3D parseObjDump(infile16, &#39;16&#39;)<br>=C2=
=A0 File &quot;./scripts/layoutrom.py&quot;, line 586, in parseObjDump<br>=
=C2=A0=C2=A0=C2=A0 relocsection =3D sectionmap[sectionname]<br>KeyError: &#=
39;.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.=
79&#39;<br>Makefile:155: recipe for target &#39;out/romlayout16.lds&#39; fa=
iled<br>make[6]: *** [out/romlayout16.lds] Error 1<br>make[6]: Leaving dire=
ctory &#39;/home/goon/xen/tools/firmware/seabios-dir-remote&#39;<br>/home/g=
oon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for target &#39;sub=
dir-all-seabios-dir&#39; failed<br><br><br></div><div><div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">2014-12-27 17:35 GMT+01:00 Goonie=
 Windy <span dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.goonie@gmail.com" t=
arget=3D"_blank">monsieur.goonie@gmail.com</a>&gt;</span>:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div><div>Hello Fabio,<br><br>Sure =
thing I will help debug the win7 and the win8 versions.<br></div>Where to s=
tart?<br><br></div>I&#39;ll try to see if I can patch with patch from <a hr=
ef=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa1187=
9e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0=
e8c7e421fafba67aa11879e8b8fe</a> and if not will post result.<br><br><br>be=
st regards,<br><br><br></div>greg Bahde<br></div><div><div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">2014-12-27 15:10 GMT+01:00 Fabio =
Fantoni <span dir=3D"ltr">&lt;<a href=3D"mailto:fabio.fantoni@m2r.biz" targ=
et=3D"_blank">fabio.fantoni@m2r.biz</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">
    <br>
    <div>Il 27/12/2014 02:15, Goonie Windy ha
      scritto:<br>
    </div><span>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>I tried to install Qxl drivers under win7/win
              2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 al=
l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64 versions, without any
              luck.<br>
              <br>
              <br>
              admin message is as follow:<br>
              Driver Management concluded the process to install driver
              FileRepository\qxl.inf_amd64_
              <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf for Device
                Instance ID
                PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&=
amp;267A616A&amp;1&amp;28
                with the following status: 0xe000022d.</div>
              <br>
              <br>
              <br>
              <br>
            </div>
            Does <br>
            <a href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05=
/msg03214.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-de=
vel/2014-05/msg03214.html</a><br>
            <br>
          </div>
          can it be installed on my xen stack? <br>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes but probably require a small refresh, I always posted the patch
    based on updated xen-unstable. <br>
    <br>
    Here qxl patch refreshed for xen 4.5 if needed:<br>
<a href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67a=
a11879e8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8=
d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
    <br>
    Here the latest spice guest tools for windows with qxl driver
    included:<br>
<a href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/s=
pice-guest-tools-0.74.exe" target=3D"_blank">http://www.spice-space.org/dow=
nload/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
    <br>
    Windows &gt;=3D8 and similar require a new qxl drivers, there are a
    beta build but latest tried some months ago have serious bug and I
    not found recent build full working on windows 8.<br>
    <br>
    On xen windows 7 domUs qxl works good except a problem after
    save/restore and on linux domUs is not working, for now I not found
    exactly cause and solution.<br>
    On mailing list up to 2 years ago you can find many my mails about.<br>
    Any help to test it is appreciated.<br>
    <br>
    Sorry for my bad english.<br>
    <br>
    <blockquote type=3D"cite"><span>
      <div dir=3D"ltr">
        <div><br>
          Also, can=C2=A0 I get invited at xendevel irc ?<br>
          regards<br>
          <br>
        </div>
        Greg <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><pre>_______________________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a113cd57c7caef3050b5aa449--


--===============3963515054951027305==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3963515054951027305==--


From xen-devel-bounces@lists.xen.org Mon Dec 29 13:28:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 13:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5aN0-0005s4-Oq; Mon, 29 Dec 2014 13:28:26 +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 1Y5aMz-0005rz-Vo
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 13:28:26 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	34/F6-20609-9F651A45; Mon, 29 Dec 2014 13:28:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419859703!17636703!1
X-Originating-IP: [66.165.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 3410 invoked from network); 29 Dec 2014 13:28:24 -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;
	29 Dec 2014 13:28:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="208862145"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 29 Dec 2014 08:28: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 1Y5aMv-0007q5-V1;
	Mon, 29 Dec 2014 13:28:21 +0000
Date: Mon, 29 Dec 2014 13:28:21 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141229132821.GB12240@zion.uk.xensource.com>
References: <549436A8.1020303@citrix.com>
 <54943B75.4090703@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54943B75.4090703@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] libxl memory leaks when Xen is compiled with XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 19, 2014 at 02:51:33PM +0000, Andrew Cooper wrote:
> Correctly CC'ing xen-devel as well this time
> 
> ~Andrew
> 
> On 19/12/14 14:31, Andrew Cooper wrote:
> > Hello,
> >
> > Coverity has identified a large number of memory leaks in libxl, because
> > of the use of libxl_domain_info() without an init/dispose for the
> > libxl_dominfo object.
> >
> > If XSM is active, this leaks the ssid_label string, and in almost all
> > cases, from the successful completion of the library function in question.
> >
> > Most of the issues can be fixed with the correct use of
> > init()/dispose(), but libxl_wait_for_memory_target() is a little more
> > interesting.
> >
> > Strictly speaking, I think I would need to fix it with a
> > dispose();init() pair immediately before the call to
> > libxl_domain_info().  However, this feels like overkill.  As only the
> > memory information is needed, would it be appropriate to downgrade to an
> > xc_domain_getinfo() instead, forgoing the memory allocation and
> > extraneous hypercalls?
> >

As long as caller visible behaviour is not changed I think it's OK to do
so.

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 Dec 29 13:28:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 13:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5aN0-0005s4-Oq; Mon, 29 Dec 2014 13:28:26 +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 1Y5aMz-0005rz-Vo
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 13:28:26 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	34/F6-20609-9F651A45; Mon, 29 Dec 2014 13:28:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419859703!17636703!1
X-Originating-IP: [66.165.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 3410 invoked from network); 29 Dec 2014 13:28:24 -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;
	29 Dec 2014 13:28:24 -0000
X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="208862145"
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.3.210.2;
	Mon, 29 Dec 2014 08:28: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 1Y5aMv-0007q5-V1;
	Mon, 29 Dec 2014 13:28:21 +0000
Date: Mon, 29 Dec 2014 13:28:21 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20141229132821.GB12240@zion.uk.xensource.com>
References: <549436A8.1020303@citrix.com>
 <54943B75.4090703@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54943B75.4090703@citrix.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-DLP: MIA2
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] libxl memory leaks when Xen is compiled with XSM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Dec 19, 2014 at 02:51:33PM +0000, Andrew Cooper wrote:
> Correctly CC'ing xen-devel as well this time
> 
> ~Andrew
> 
> On 19/12/14 14:31, Andrew Cooper wrote:
> > Hello,
> >
> > Coverity has identified a large number of memory leaks in libxl, because
> > of the use of libxl_domain_info() without an init/dispose for the
> > libxl_dominfo object.
> >
> > If XSM is active, this leaks the ssid_label string, and in almost all
> > cases, from the successful completion of the library function in question.
> >
> > Most of the issues can be fixed with the correct use of
> > init()/dispose(), but libxl_wait_for_memory_target() is a little more
> > interesting.
> >
> > Strictly speaking, I think I would need to fix it with a
> > dispose();init() pair immediately before the call to
> > libxl_domain_info().  However, this feels like overkill.  As only the
> > memory information is needed, would it be appropriate to downgrade to an
> > xc_domain_getinfo() instead, forgoing the memory allocation and
> > extraneous hypercalls?
> >

As long as caller visible behaviour is not changed I think it's OK to do
so.

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 Dec 29 13:50:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 13: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 1Y5ahl-0006GI-Ka; Mon, 29 Dec 2014 13:49:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1Y5ahk-0006GD-It
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 13:49:52 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	38/4E-02712-FFB51A45; Mon, 29 Dec 2014 13:49:51 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-2.tower-27.messagelabs.com!1419860990!17622252!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=1.7 required=7.0 tests=BIZ_TLD,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20295 invoked from network); 29 Dec 2014 13:49:50 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2014 13:49:50 -0000
Received: by mail-wg0-f43.google.com with SMTP id k14so1148305wgh.2
	for <xen-devel@lists.xen.org>; Mon, 29 Dec 2014 05:49: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;
	bh=zZIMm01N0nAmP831OVlO4kcTGYJPRDUrYbDM/uWLSK0=;
	b=JoKYWFYJqk9y7SZesl/+PvP1uNV051NkilnRI2RpL/1tfDZmiuWmHOXwuBkaK4+Q+K
	eMmhqbdcnfo3yp6x9PyeY0bG4OO06yavxzl5SIG+EXby14fzDRSqGQ0awfTOBV3ho53d
	U+V4kuh1QpkmvEWSxZRT3JG5bIcKKeFfYE8QfHacqcQEkbcfTJXyx3KSqRfLAM8pI81q
	NRDafx7r6Ix9tvCGaCqgVk/8wimx8S6EB4FyJ35cOrKBv0yVToEtnIk+kL16Xrb4W2Lf
	wOQUVs2C4f+SZ9CjAQ6x4IwmXh8iwJfeh64emKA9nH7xP8OMjq4D1V0gGTXO+eg1RGaY
	tuCw==
X-Gm-Message-State: ALoCoQn30RSxFrPro0IbVCdCOPaFvTpDFU0VkX6xnilqnSd+n6y6fjVk7y6bwYiYpV8MNKmNvpI2
X-Received: by 10.180.11.98 with SMTP id p2mr97299195wib.22.1419860989881;
	Mon, 29 Dec 2014 05:49:49 -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 p14sm39602683wie.1.2014.12.29.05.49.47
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 29 Dec 2014 05:49:49 -0800 (PST)
Message-ID: <54A15BFA.4050001@m2r.biz>
Date: Mon, 29 Dec 2014 14:49:46 +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.3.0
MIME-Version: 1.0
To: Goonie Windy <monsieur.goonie@gmail.com>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>	<549EBDCC.3090102@m2r.biz>	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>	<CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>	<CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>	<CAE5x5YU8R9PibP-_xj+uYNc_rqOL0rnuHvVF5Ymz32RngDEgFw@mail.gmail.com>
	<CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com>
In-Reply-To: <CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2238628033026621566=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2238628033026621566==
Content-Type: multipart/alternative;
 boundary="------------030608090703000808060505"

This is a multi-part message in MIME format.
--------------030608090703000808060505
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Il 29/12/2014 14:13, Goonie Windy ha scritto:
> ok, I'm trying to patch the files with yours,
>
>
> I need to do it manually right?
>
> git apply is not working here.

If the patch need a "refresh" the conflict should be solved manually.
Taking the patch updated from here probably it can be applied to latest 
4.5-rc:
https://github.com/Fantu/Xen/commits/rebase/m2r-staging

>
>
> regards
>
> greg
>
> 2014-12-29 13:46 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com 
> <mailto:monsieur.goonie@gmail.com>>:
>
>     There is an error in pageqs describing how to compile from sources
>     as in 4.5
>
>     cat .config
>     PYTHON_PREFIX_ARG=--install-layout=deb
>
>     is in fact in .INSTALL
>

If also you use debian you can use make debball that is better for 
install/remove easy and fast test build.

And for example I use this configure options with xen 4.5:
./configure --prefix=/usr --disable-blktap1 --disable-qemu-traditional 
--disable-rombios --with-system-seabios=/usr/share/seabios/bios-256k.bin 
--with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir" 
--disable-blktap2
I use wheezy building updated packages from sid: seabios 1.7.5-1, spice 
0.12.5-1, spice-protocol 0.12.7-1 and usbredir 0.7-1.
If you use jessie instead you have all packages updated.

About python I'm using this workaround (before execute configure) even 
if probably is not the best:
Config.mk
-PYTHON_PREFIX_ARG ?=--prefix="$(PREFIX)"
+PYTHON_PREFIX_ARG ?=

>
>
>     2014-12-29 1:20 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com
>     <mailto:monsieur.goonie@gmail.com>>:
>
>         well figured out it is because you have to "enforce" locale: 
>         export LC_ALL=en_US.utf-8 if keyboard mapping is else
>
>         2014-12-28 21:19 GMT+01:00 Goonie Windy
>         <monsieur.goonie@gmail.com <mailto:monsieur.goonie@gmail.com>>:
>
>             Trying to compile xen 4.5RC4 in order to test your patch I
>             end up with  these errors compiling the Seabios directories,
>
>             any idea?
>
>               Compiling to assembler out/src/asm-offsets.s
>               Generating offset file out/asm-offsets.h
>               Compiling (16bit) out/romlayout.o
>               Building ld scripts
>             Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
>             Traceback (most recent call last):
>               File "./scripts/layoutrom.py", line 709, in <module>
>                 main()
>               File "./scripts/layoutrom.py", line 671, in main
>                 info16 = parseObjDump(infile16, '16')
>               File "./scripts/layoutrom.py", line 586, in parseObjDump
>                 relocsection = sectionmap[sectionname]
>             KeyError:
>             '.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
>             Makefile:155: recipe for target 'out/romlayout16.lds' failed
>             make[6]: *** [out/romlayout16.lds] Error 1
>             make[6]: Leaving directory
>             '/home/goon/xen/tools/firmware/seabios-dir-remote'
>             /home/goon/xen/tools/firmware/../../tools/Rules.mk:116:
>             recipe for target 'subdir-all-seabios-dir' failed
>
>
>
>             2014-12-27 17:35 GMT+01:00 Goonie Windy
>             <monsieur.goonie@gmail.com
>             <mailto:monsieur.goonie@gmail.com>>:
>
>                 Hello Fabio,
>
>                 Sure thing I will help debug the win7 and the win8
>                 versions.
>                 Where to start?
>
>                 I'll try to see if I can patch with patch from
>                 https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>                 and if not will post result.
>
>
>                 best regards,
>
>
>                 greg Bahde
>
>                 2014-12-27 15:10 GMT+01:00 Fabio Fantoni
>                 <fabio.fantoni@m2r.biz <mailto:fabio.fantoni@m2r.biz>>:
>
>
>                     Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>                     I tried to install Qxl drivers under win7/win
>>                     2k8/win8.1 all       x64 versions, without any luck.
>>
>>
>>                     admin message is as follow:
>>                     Driver Management concluded the process to
>>                     install driver FileRepository\qxl.inf_amd64_
>>                     neutral_f0c429882d5c81ed\qxl.inf for Device
>>                     Instance ID
>>                     PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28
>>                     with the following status: 0xe000022d.
>>
>>
>>
>>
>>                     Does
>>                     http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>
>>                     can it be installed on my xen stack?
>
>                     Yes but probably require a small refresh, I always
>                     posted the patch based on updated xen-unstable.
>
>                     Here qxl patch refreshed for xen 4.5 if needed:
>                     https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>
>                     Here the latest spice guest tools for windows with
>                     qxl driver included:
>                     http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>
>                     Windows >=8 and similar require a new qxl drivers,
>                     there are a beta build but latest tried some
>                     months ago have serious bug and I not found recent
>                     build full working on windows 8.
>
>                     On xen windows 7 domUs qxl works good except a
>                     problem after save/restore and on linux domUs is
>                     not working, for now I not found exactly cause and
>                     solution.
>                     On mailing list up to 2 years ago you can find
>                     many my mails about.
>                     Any help to test it is appreciated.
>
>                     Sorry for my bad english.
>
>>
>>                     Also, can  I get invited at xendevel irc ?
>>                     regards
>>
>>                     Greg
>>
>>
>>                     _______________________________________________
>>                     Xen-devel mailing list
>>                     Xen-devel@lists.xen.org  <mailto:Xen-devel@lists.xen.org>
>>                     http://lists.xen.org/xen-devel
>
>
>
>
>
>


--------------030608090703000808060505
Content-Type: text/html; charset=utf-8
Content-Length: 23476
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">Il 29/12/2014 14:13, Goonie Windy ha
      scritto:<br>
    </div>
    <blockquote
cite=3D"mid:CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>ok, I'm trying to patch the files with yours,<br>
              <br>
              <br>
            </div>
            I need to do it manually right=3F <br>
            <br>
            git apply is not working here. <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    If the patch need a "refresh" the conflict should be solved
    manually.<br>
    Taking the patch updated from here probably it can be applied to
    latest 4.5-rc:<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>
    <blockquote
cite=3D"mid:CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div><br>
            <br>
          </div>
          regards<br>
          <br>
        </div>
        greg<br>
      </div>
      <div class=3D"gmail_extra"><br>
        <div class=3D"gmail_quote">2014-12-29 13:46 GMT+01:00 Goonie Windy
          <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
              href=3D"mailto:monsieur.goonie@gmail.com" target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">There is an error in pageqs describing how to
              compile from sources as in 4.5 <br>
              <pre>cat .config
PYTHON_PREFIX_ARG=3D--install-layout=3Ddeb

</pre>
              <pre>is in fact in .INSTALL
</pre>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
    If also you use debian you can use make debball that is better for
    install/remove easy and fast test build.<br>
    <br>
    And for example I use this configure options with xen 4.5:<br>
    ./configure --prefix=3D/usr --disable-blktap1
    --disable-qemu-traditional --disable-rombios
    --with-system-seabios=3D/usr/share/seabios/bios-256k.bin
    --with-extra-qemuu-configure-args=3D"--enable-spice
    --enable-usb-redir" --disable-blktap2<br>
    I use wheezy building updated packages from sid: seabios 1.7.5-1,
    spice 0.12.5-1, spice-protocol 0.12.7-1 and usbredir 0.7-1.<br>
    If you use jessie instead you have all packages updated.<br>
    <br>
    About python I'm using this workaround (before execute configure)
    even if probably is not the best:<br>
    <span class=3D"js-selectable-text" title=3D"Config.mk">Config.mk</span><br>
    -<span class=3D"pl-vo">PYTHON_PREFIX_ARG</span> =3F=3D<span class=3D"x
      x-first"> --prefix=3D"</span><span class=3D"pl-s1"><span class=3D"x">$(</span><span
        class=3D"pl-vo x">PREFIX</span><span class=3D"x">)</span></span><span
      class=3D"x x-last">"</span><br>
    +<span class=3D"pl-vo">PYTHON_PREFIX_ARG</span> =3F=3D<br>
    <br>
    <blockquote
cite=3D"mid:CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com"
      type=3D"cite">
      <div class=3D"gmail_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">
            <div dir=3D"ltr"><br>
            </div>
            <div class=3D"HOEnZb">
              <div class=3D"h5">
                <div class=3D"gmail_extra"><br>
                  <div class=3D"gmail_quote">2014-12-29 1:20 GMT+01:00
                    Goonie Windy <span dir=3D"ltr">&lt;<a
                        moz-do-not-send=3D"true"
                        href=3D"mailto:monsieur.goonie@gmail.com"
                        target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                        <div>well figured out it is because you have to
                          "enforce" locale:=C2=A0 export LC_ALL=3Den_US.utf-8
                          if keyboard mapping is else<br>
                        </div>
                      </div>
                      <div>
                        <div>
                          <div class=3D"gmail_extra"><br>
                            <div class=3D"gmail_quote">2014-12-28 21:19
                              GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a
                                  moz-do-not-send=3D"true"
                                  href=3D"mailto:monsieur.goonie@gmail.com"
                                  target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                                  <div>Trying to compile xen 4.5RC4 in
                                    order to test your patch I end up
                                    with=C2=A0 these errors compiling the
                                    Seabios directories,<br>
                                    <br>
                                  </div>
                                  any idea=3F<br>
                                  <br>
                                  =C2=A0 Compiling to assembler
                                  out/src/asm-offsets.s<br>
                                  =C2=A0 Generating offset file
                                  out/asm-offsets.h<br>
                                  =C2=A0 Compiling (16bit) out/romlayout.o<br>
                                  =C2=A0 Building ld scripts<br>
                                  Version:
                                  rel-1.7.5-0-ge51488c-20141228_210340-E766<br>
                                  Traceback (most recent call last):<br>
                                  =C2=A0 File "./scripts/layoutrom.py", line
                                  709, in &lt;module&gt;<br>
                                  =C2=A0=C2=A0=C2=A0 main()<br>
                                  =C2=A0 File "./scripts/layoutrom.py", line
                                  671, in main<br>
                                  =C2=A0=C2=A0=C2=A0 info16 =3D parseObjDump(infile16,
                                  '16')<br>
                                  =C2=A0 File "./scripts/layoutrom.py", line
                                  586, in parseObjDump<br>
                                  =C2=A0=C2=A0=C2=A0 relocsection =3D
                                  sectionmap[sectionname]<br>
                                  KeyError:
'.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'<br>
                                  Makefile:155: recipe for target
                                  'out/romlayout16.lds' failed<br>
                                  make[6]: *** [out/romlayout16.lds]
                                  Error 1<br>
                                  make[6]: Leaving directory
                                  '/home/goon/xen/tools/firmware/seabios-dir-remote'<br>
                                  /home/goon/xen/tools/firmware/../../tools/Rules.mk:116:
                                  recipe for target
                                  'subdir-all-seabios-dir' failed<br>
                                  <br>
                                  <br>
                                </div>
                                <div>
                                  <div>
                                    <div class=3D"gmail_extra"><br>
                                      <div class=3D"gmail_quote">2014-12-27
                                        17:35 GMT+01:00 Goonie Windy <span
                                          dir=3D"ltr">&lt;<a
                                            moz-do-not-send=3D"true"
                                            href=3D"mailto:monsieur.goonie@gmail.com"
                                            target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                                            <div>
                                              <div>
                                                <div>Hello Fabio,<br>
                                                  <br>
                                                  Sure thing I will help
                                                  debug the win7 and the
                                                  win8 versions.<br>
                                                </div>
                                                Where to start=3F<br>
                                                <br>
                                              </div>
                                              I'll try to see if I can
                                              patch with patch from <a
                                                moz-do-not-send=3D"true"
href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe"
                                                target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a>
                                              and if not will post
                                              result.<br>
                                              <br>
                                              <br>
                                              best regards,<br>
                                              <br>
                                              <br>
                                            </div>
                                            greg Bahde<br>
                                          </div>
                                          <div>
                                            <div>
                                              <div class=3D"gmail_extra"><br>
                                                <div class=3D"gmail_quote">2014-12-27
                                                  15:10 GMT+01:00 Fabio
                                                  Fantoni <span
                                                    dir=3D"ltr">&lt;<a
                                                      moz-do-not-send=3D"true"
href=3D"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">fabio.fantoni@m2r.biz</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"> <br>
                                                      <div>Il 27/12/2014
                                                        02:15, Goonie
                                                        Windy ha
                                                        scritto:<br>
                                                      </div>
                                                      <span>
                                                        <blockquote
                                                          type=3D"cite">
                                                          <div dir=3D"ltr">
                                                          <div>
                                                          <div>
                                                          <div>I tried
                                                          to install Qxl
                                                          drivers under
                                                          win7/win
                                                          2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          all=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64
                                                          versions,
                                                          without any
                                                          luck.<br>
                                                          <br>
                                                          <br>
                                                          admin message
                                                          is as follow:<br>
                                                          Driver
                                                          Management
                                                          concluded the
                                                          process to
                                                          install driver
                                                          FileRepository\qxl.inf_amd64_

                                                          <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf
                                                          for Device
                                                          Instance ID
                                                          PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&amp;267A616A&amp;1&amp;28

                                                          with the
                                                          following
                                                          status:
                                                          0xe000022d.</div>
                                                          <br>
                                                          <br>
                                                          <br>
                                                          <br>
                                                          </div>
                                                          Does <br>
                                                          <a
                                                          moz-do-not-send=3D"true"
href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html"
target=3D"_blank">http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html</a><br>
                                                          <br>
                                                          </div>
                                                          can it be
                                                          installed on
                                                          my xen stack=3F
                                                          <br>
                                                          </div>
                                                          </div>
                                                        </blockquote>
                                                        <br>
                                                      </span> Yes but
                                                      probably require a
                                                      small refresh, I
                                                      always posted the
                                                      patch based on
                                                      updated
                                                      xen-unstable. <br>
                                                      <br>
                                                      Here qxl patch
                                                      refreshed for xen
                                                      4.5 if needed:<br>
                                                      <a
                                                        moz-do-not-send=3D"true"
href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe"
                                                        target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
                                                      <br>
                                                      Here the latest
                                                      spice guest tools
                                                      for windows with
                                                      qxl driver
                                                      included:<br>
                                                      <a
                                                        moz-do-not-send=3D"true"
href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe"
                                                        target=3D"_blank">http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
                                                      <br>
                                                      Windows &gt;=3D8 and
                                                      similar require a
                                                      new qxl drivers,
                                                      there are a beta
                                                      build but latest
                                                      tried some months
                                                      ago have serious
                                                      bug and I not
                                                      found recent build
                                                      full working on
                                                      windows 8.<br>
                                                      <br>
                                                      On xen windows 7
                                                      domUs qxl works
                                                      good except a
                                                      problem after
                                                      save/restore and
                                                      on linux domUs is
                                                      not working, for
                                                      now I not found
                                                      exactly cause and
                                                      solution.<br>
                                                      On mailing list up
                                                      to 2 years ago you
                                                      can find many my
                                                      mails about.<br>
                                                      Any help to test
                                                      it is appreciated.<br>
                                                      <br>
                                                      Sorry for my bad
                                                      english.<br>
                                                      <br>
                                                      <blockquote
                                                        type=3D"cite"><span>
                                                          <div dir=3D"ltr">
                                                          <div><br>
                                                          Also, can=C2=A0 I
                                                          get invited at
                                                          xendevel irc =3F<br>
                                                          regards<br>
                                                          <br>
                                                          </div>
                                                          Greg <br>
                                                          </div>
                                                          <br>
                                                          <fieldset></fieldset>
                                                          <br>
                                                        </span>
                                                        <pre>_______________________________________________
Xen-devel mailing list
<a moz-do-not-send=3D"true" href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@lists.xen.org</a>
<a moz-do-not-send=3D"true" href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.xen.org/xen-devel</a>
</pre>
                                                      </blockquote>
                                                      <br>
                                                    </div>
                                                  </blockquote>
                                                </div>
                                                <br>
                                              </div>
                                            </div>
                                          </div>
                                        </blockquote>
                                      </div>
                                      <br>
                                    </div>
                                  </div>
                                </div>
                              </blockquote>
                            </div>
                            <br>
                          </div>
                        </div>
                      </div>
                    </blockquote>
                  </div>
                  <br>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------030608090703000808060505--


--===============2238628033026621566==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2238628033026621566==--


From xen-devel-bounces@lists.xen.org Mon Dec 29 13:50:20 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 13: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 1Y5ahl-0006GI-Ka; Mon, 29 Dec 2014 13:49:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@m2r.biz>) id 1Y5ahk-0006GD-It
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 13:49:52 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	38/4E-02712-FFB51A45; Mon, 29 Dec 2014 13:49:51 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-2.tower-27.messagelabs.com!1419860990!17622252!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=1.7 required=7.0 tests=BIZ_TLD,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20295 invoked from network); 29 Dec 2014 13:49:50 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2014 13:49:50 -0000
Received: by mail-wg0-f43.google.com with SMTP id k14so1148305wgh.2
	for <xen-devel@lists.xen.org>; Mon, 29 Dec 2014 05:49: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;
	bh=zZIMm01N0nAmP831OVlO4kcTGYJPRDUrYbDM/uWLSK0=;
	b=JoKYWFYJqk9y7SZesl/+PvP1uNV051NkilnRI2RpL/1tfDZmiuWmHOXwuBkaK4+Q+K
	eMmhqbdcnfo3yp6x9PyeY0bG4OO06yavxzl5SIG+EXby14fzDRSqGQ0awfTOBV3ho53d
	U+V4kuh1QpkmvEWSxZRT3JG5bIcKKeFfYE8QfHacqcQEkbcfTJXyx3KSqRfLAM8pI81q
	NRDafx7r6Ix9tvCGaCqgVk/8wimx8S6EB4FyJ35cOrKBv0yVToEtnIk+kL16Xrb4W2Lf
	wOQUVs2C4f+SZ9CjAQ6x4IwmXh8iwJfeh64emKA9nH7xP8OMjq4D1V0gGTXO+eg1RGaY
	tuCw==
X-Gm-Message-State: ALoCoQn30RSxFrPro0IbVCdCOPaFvTpDFU0VkX6xnilqnSd+n6y6fjVk7y6bwYiYpV8MNKmNvpI2
X-Received: by 10.180.11.98 with SMTP id p2mr97299195wib.22.1419860989881;
	Mon, 29 Dec 2014 05:49:49 -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 p14sm39602683wie.1.2014.12.29.05.49.47
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 29 Dec 2014 05:49:49 -0800 (PST)
Message-ID: <54A15BFA.4050001@m2r.biz>
Date: Mon, 29 Dec 2014 14:49:46 +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.3.0
MIME-Version: 1.0
To: Goonie Windy <monsieur.goonie@gmail.com>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>	<549EBDCC.3090102@m2r.biz>	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>	<CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>	<CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>	<CAE5x5YU8R9PibP-_xj+uYNc_rqOL0rnuHvVF5Ymz32RngDEgFw@mail.gmail.com>
	<CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com>
In-Reply-To: <CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2238628033026621566=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2238628033026621566==
Content-Type: multipart/alternative;
 boundary="------------030608090703000808060505"

This is a multi-part message in MIME format.
--------------030608090703000808060505
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Il 29/12/2014 14:13, Goonie Windy ha scritto:
> ok, I'm trying to patch the files with yours,
>
>
> I need to do it manually right?
>
> git apply is not working here.

If the patch need a "refresh" the conflict should be solved manually.
Taking the patch updated from here probably it can be applied to latest 
4.5-rc:
https://github.com/Fantu/Xen/commits/rebase/m2r-staging

>
>
> regards
>
> greg
>
> 2014-12-29 13:46 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com 
> <mailto:monsieur.goonie@gmail.com>>:
>
>     There is an error in pageqs describing how to compile from sources
>     as in 4.5
>
>     cat .config
>     PYTHON_PREFIX_ARG=--install-layout=deb
>
>     is in fact in .INSTALL
>

If also you use debian you can use make debball that is better for 
install/remove easy and fast test build.

And for example I use this configure options with xen 4.5:
./configure --prefix=/usr --disable-blktap1 --disable-qemu-traditional 
--disable-rombios --with-system-seabios=/usr/share/seabios/bios-256k.bin 
--with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir" 
--disable-blktap2
I use wheezy building updated packages from sid: seabios 1.7.5-1, spice 
0.12.5-1, spice-protocol 0.12.7-1 and usbredir 0.7-1.
If you use jessie instead you have all packages updated.

About python I'm using this workaround (before execute configure) even 
if probably is not the best:
Config.mk
-PYTHON_PREFIX_ARG ?=--prefix="$(PREFIX)"
+PYTHON_PREFIX_ARG ?=

>
>
>     2014-12-29 1:20 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com
>     <mailto:monsieur.goonie@gmail.com>>:
>
>         well figured out it is because you have to "enforce" locale: 
>         export LC_ALL=en_US.utf-8 if keyboard mapping is else
>
>         2014-12-28 21:19 GMT+01:00 Goonie Windy
>         <monsieur.goonie@gmail.com <mailto:monsieur.goonie@gmail.com>>:
>
>             Trying to compile xen 4.5RC4 in order to test your patch I
>             end up with  these errors compiling the Seabios directories,
>
>             any idea?
>
>               Compiling to assembler out/src/asm-offsets.s
>               Generating offset file out/asm-offsets.h
>               Compiling (16bit) out/romlayout.o
>               Building ld scripts
>             Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
>             Traceback (most recent call last):
>               File "./scripts/layoutrom.py", line 709, in <module>
>                 main()
>               File "./scripts/layoutrom.py", line 671, in main
>                 info16 = parseObjDump(infile16, '16')
>               File "./scripts/layoutrom.py", line 586, in parseObjDump
>                 relocsection = sectionmap[sectionname]
>             KeyError:
>             '.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
>             Makefile:155: recipe for target 'out/romlayout16.lds' failed
>             make[6]: *** [out/romlayout16.lds] Error 1
>             make[6]: Leaving directory
>             '/home/goon/xen/tools/firmware/seabios-dir-remote'
>             /home/goon/xen/tools/firmware/../../tools/Rules.mk:116:
>             recipe for target 'subdir-all-seabios-dir' failed
>
>
>
>             2014-12-27 17:35 GMT+01:00 Goonie Windy
>             <monsieur.goonie@gmail.com
>             <mailto:monsieur.goonie@gmail.com>>:
>
>                 Hello Fabio,
>
>                 Sure thing I will help debug the win7 and the win8
>                 versions.
>                 Where to start?
>
>                 I'll try to see if I can patch with patch from
>                 https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>                 and if not will post result.
>
>
>                 best regards,
>
>
>                 greg Bahde
>
>                 2014-12-27 15:10 GMT+01:00 Fabio Fantoni
>                 <fabio.fantoni@m2r.biz <mailto:fabio.fantoni@m2r.biz>>:
>
>
>                     Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>                     I tried to install Qxl drivers under win7/win
>>                     2k8/win8.1 all       x64 versions, without any luck.
>>
>>
>>                     admin message is as follow:
>>                     Driver Management concluded the process to
>>                     install driver FileRepository\qxl.inf_amd64_
>>                     neutral_f0c429882d5c81ed\qxl.inf for Device
>>                     Instance ID
>>                     PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28
>>                     with the following status: 0xe000022d.
>>
>>
>>
>>
>>                     Does
>>                     http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>
>>                     can it be installed on my xen stack?
>
>                     Yes but probably require a small refresh, I always
>                     posted the patch based on updated xen-unstable.
>
>                     Here qxl patch refreshed for xen 4.5 if needed:
>                     https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>
>                     Here the latest spice guest tools for windows with
>                     qxl driver included:
>                     http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>
>                     Windows >=8 and similar require a new qxl drivers,
>                     there are a beta build but latest tried some
>                     months ago have serious bug and I not found recent
>                     build full working on windows 8.
>
>                     On xen windows 7 domUs qxl works good except a
>                     problem after save/restore and on linux domUs is
>                     not working, for now I not found exactly cause and
>                     solution.
>                     On mailing list up to 2 years ago you can find
>                     many my mails about.
>                     Any help to test it is appreciated.
>
>                     Sorry for my bad english.
>
>>
>>                     Also, can  I get invited at xendevel irc ?
>>                     regards
>>
>>                     Greg
>>
>>
>>                     _______________________________________________
>>                     Xen-devel mailing list
>>                     Xen-devel@lists.xen.org  <mailto:Xen-devel@lists.xen.org>
>>                     http://lists.xen.org/xen-devel
>
>
>
>
>
>


--------------030608090703000808060505
Content-Type: text/html; charset=utf-8
Content-Length: 23476
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">Il 29/12/2014 14:13, Goonie Windy ha
      scritto:<br>
    </div>
    <blockquote
cite=3D"mid:CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>ok, I'm trying to patch the files with yours,<br>
              <br>
              <br>
            </div>
            I need to do it manually right=3F <br>
            <br>
            git apply is not working here. <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    If the patch need a "refresh" the conflict should be solved
    manually.<br>
    Taking the patch updated from here probably it can be applied to
    latest 4.5-rc:<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>
    <blockquote
cite=3D"mid:CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div><br>
            <br>
          </div>
          regards<br>
          <br>
        </div>
        greg<br>
      </div>
      <div class=3D"gmail_extra"><br>
        <div class=3D"gmail_quote">2014-12-29 13:46 GMT+01:00 Goonie Windy
          <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
              href=3D"mailto:monsieur.goonie@gmail.com" target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">There is an error in pageqs describing how to
              compile from sources as in 4.5 <br>
              <pre>cat .config
PYTHON_PREFIX_ARG=3D--install-layout=3Ddeb

</pre>
              <pre>is in fact in .INSTALL
</pre>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
    If also you use debian you can use make debball that is better for
    install/remove easy and fast test build.<br>
    <br>
    And for example I use this configure options with xen 4.5:<br>
    ./configure --prefix=3D/usr --disable-blktap1
    --disable-qemu-traditional --disable-rombios
    --with-system-seabios=3D/usr/share/seabios/bios-256k.bin
    --with-extra-qemuu-configure-args=3D"--enable-spice
    --enable-usb-redir" --disable-blktap2<br>
    I use wheezy building updated packages from sid: seabios 1.7.5-1,
    spice 0.12.5-1, spice-protocol 0.12.7-1 and usbredir 0.7-1.<br>
    If you use jessie instead you have all packages updated.<br>
    <br>
    About python I'm using this workaround (before execute configure)
    even if probably is not the best:<br>
    <span class=3D"js-selectable-text" title=3D"Config.mk">Config.mk</span><br>
    -<span class=3D"pl-vo">PYTHON_PREFIX_ARG</span> =3F=3D<span class=3D"x
      x-first"> --prefix=3D"</span><span class=3D"pl-s1"><span class=3D"x">$(</span><span
        class=3D"pl-vo x">PREFIX</span><span class=3D"x">)</span></span><span
      class=3D"x x-last">"</span><br>
    +<span class=3D"pl-vo">PYTHON_PREFIX_ARG</span> =3F=3D<br>
    <br>
    <blockquote
cite=3D"mid:CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com"
      type=3D"cite">
      <div class=3D"gmail_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">
            <div dir=3D"ltr"><br>
            </div>
            <div class=3D"HOEnZb">
              <div class=3D"h5">
                <div class=3D"gmail_extra"><br>
                  <div class=3D"gmail_quote">2014-12-29 1:20 GMT+01:00
                    Goonie Windy <span dir=3D"ltr">&lt;<a
                        moz-do-not-send=3D"true"
                        href=3D"mailto:monsieur.goonie@gmail.com"
                        target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                        <div>well figured out it is because you have to
                          "enforce" locale:=C2=A0 export LC_ALL=3Den_US.utf-8
                          if keyboard mapping is else<br>
                        </div>
                      </div>
                      <div>
                        <div>
                          <div class=3D"gmail_extra"><br>
                            <div class=3D"gmail_quote">2014-12-28 21:19
                              GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;<a
                                  moz-do-not-send=3D"true"
                                  href=3D"mailto:monsieur.goonie@gmail.com"
                                  target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                                  <div>Trying to compile xen 4.5RC4 in
                                    order to test your patch I end up
                                    with=C2=A0 these errors compiling the
                                    Seabios directories,<br>
                                    <br>
                                  </div>
                                  any idea=3F<br>
                                  <br>
                                  =C2=A0 Compiling to assembler
                                  out/src/asm-offsets.s<br>
                                  =C2=A0 Generating offset file
                                  out/asm-offsets.h<br>
                                  =C2=A0 Compiling (16bit) out/romlayout.o<br>
                                  =C2=A0 Building ld scripts<br>
                                  Version:
                                  rel-1.7.5-0-ge51488c-20141228_210340-E766<br>
                                  Traceback (most recent call last):<br>
                                  =C2=A0 File "./scripts/layoutrom.py", line
                                  709, in &lt;module&gt;<br>
                                  =C2=A0=C2=A0=C2=A0 main()<br>
                                  =C2=A0 File "./scripts/layoutrom.py", line
                                  671, in main<br>
                                  =C2=A0=C2=A0=C2=A0 info16 =3D parseObjDump(infile16,
                                  '16')<br>
                                  =C2=A0 File "./scripts/layoutrom.py", line
                                  586, in parseObjDump<br>
                                  =C2=A0=C2=A0=C2=A0 relocsection =3D
                                  sectionmap[sectionname]<br>
                                  KeyError:
'.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'<br>
                                  Makefile:155: recipe for target
                                  'out/romlayout16.lds' failed<br>
                                  make[6]: *** [out/romlayout16.lds]
                                  Error 1<br>
                                  make[6]: Leaving directory
                                  '/home/goon/xen/tools/firmware/seabios-dir-remote'<br>
                                  /home/goon/xen/tools/firmware/../../tools/Rules.mk:116:
                                  recipe for target
                                  'subdir-all-seabios-dir' failed<br>
                                  <br>
                                  <br>
                                </div>
                                <div>
                                  <div>
                                    <div class=3D"gmail_extra"><br>
                                      <div class=3D"gmail_quote">2014-12-27
                                        17:35 GMT+01:00 Goonie Windy <span
                                          dir=3D"ltr">&lt;<a
                                            moz-do-not-send=3D"true"
                                            href=3D"mailto:monsieur.goonie@gmail.com"
                                            target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                                            <div>
                                              <div>
                                                <div>Hello Fabio,<br>
                                                  <br>
                                                  Sure thing I will help
                                                  debug the win7 and the
                                                  win8 versions.<br>
                                                </div>
                                                Where to start=3F<br>
                                                <br>
                                              </div>
                                              I'll try to see if I can
                                              patch with patch from <a
                                                moz-do-not-send=3D"true"
href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe"
                                                target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a>
                                              and if not will post
                                              result.<br>
                                              <br>
                                              <br>
                                              best regards,<br>
                                              <br>
                                              <br>
                                            </div>
                                            greg Bahde<br>
                                          </div>
                                          <div>
                                            <div>
                                              <div class=3D"gmail_extra"><br>
                                                <div class=3D"gmail_quote">2014-12-27
                                                  15:10 GMT+01:00 Fabio
                                                  Fantoni <span
                                                    dir=3D"ltr">&lt;<a
                                                      moz-do-not-send=3D"true"
href=3D"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">fabio.fantoni@m2r.biz</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"> <br>
                                                      <div>Il 27/12/2014
                                                        02:15, Goonie
                                                        Windy ha
                                                        scritto:<br>
                                                      </div>
                                                      <span>
                                                        <blockquote
                                                          type=3D"cite">
                                                          <div dir=3D"ltr">
                                                          <div>
                                                          <div>
                                                          <div>I tried
                                                          to install Qxl
                                                          drivers under
                                                          win7/win
                                                          2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          all=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64
                                                          versions,
                                                          without any
                                                          luck.<br>
                                                          <br>
                                                          <br>
                                                          admin message
                                                          is as follow:<br>
                                                          Driver
                                                          Management
                                                          concluded the
                                                          process to
                                                          install driver
                                                          FileRepository\qxl.inf_amd64_

                                                          <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf
                                                          for Device
                                                          Instance ID
                                                          PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&amp;267A616A&amp;1&amp;28

                                                          with the
                                                          following
                                                          status:
                                                          0xe000022d.</div>
                                                          <br>
                                                          <br>
                                                          <br>
                                                          <br>
                                                          </div>
                                                          Does <br>
                                                          <a
                                                          moz-do-not-send=3D"true"
href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html"
target=3D"_blank">http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html</a><br>
                                                          <br>
                                                          </div>
                                                          can it be
                                                          installed on
                                                          my xen stack=3F
                                                          <br>
                                                          </div>
                                                          </div>
                                                        </blockquote>
                                                        <br>
                                                      </span> Yes but
                                                      probably require a
                                                      small refresh, I
                                                      always posted the
                                                      patch based on
                                                      updated
                                                      xen-unstable. <br>
                                                      <br>
                                                      Here qxl patch
                                                      refreshed for xen
                                                      4.5 if needed:<br>
                                                      <a
                                                        moz-do-not-send=3D"true"
href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe"
                                                        target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
                                                      <br>
                                                      Here the latest
                                                      spice guest tools
                                                      for windows with
                                                      qxl driver
                                                      included:<br>
                                                      <a
                                                        moz-do-not-send=3D"true"
href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe"
                                                        target=3D"_blank">http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
                                                      <br>
                                                      Windows &gt;=3D8 and
                                                      similar require a
                                                      new qxl drivers,
                                                      there are a beta
                                                      build but latest
                                                      tried some months
                                                      ago have serious
                                                      bug and I not
                                                      found recent build
                                                      full working on
                                                      windows 8.<br>
                                                      <br>
                                                      On xen windows 7
                                                      domUs qxl works
                                                      good except a
                                                      problem after
                                                      save/restore and
                                                      on linux domUs is
                                                      not working, for
                                                      now I not found
                                                      exactly cause and
                                                      solution.<br>
                                                      On mailing list up
                                                      to 2 years ago you
                                                      can find many my
                                                      mails about.<br>
                                                      Any help to test
                                                      it is appreciated.<br>
                                                      <br>
                                                      Sorry for my bad
                                                      english.<br>
                                                      <br>
                                                      <blockquote
                                                        type=3D"cite"><span>
                                                          <div dir=3D"ltr">
                                                          <div><br>
                                                          Also, can=C2=A0 I
                                                          get invited at
                                                          xendevel irc =3F<br>
                                                          regards<br>
                                                          <br>
                                                          </div>
                                                          Greg <br>
                                                          </div>
                                                          <br>
                                                          <fieldset></fieldset>
                                                          <br>
                                                        </span>
                                                        <pre>_______________________________________________
Xen-devel mailing list
<a moz-do-not-send=3D"true" href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@lists.xen.org</a>
<a moz-do-not-send=3D"true" href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.xen.org/xen-devel</a>
</pre>
                                                      </blockquote>
                                                      <br>
                                                    </div>
                                                  </blockquote>
                                                </div>
                                                <br>
                                              </div>
                                            </div>
                                          </div>
                                        </blockquote>
                                      </div>
                                      <br>
                                    </div>
                                  </div>
                                </div>
                              </blockquote>
                            </div>
                            <br>
                          </div>
                        </div>
                      </div>
                    </blockquote>
                  </div>
                  <br>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------030608090703000808060505--


--===============2238628033026621566==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2238628033026621566==--


From xen-devel-bounces@lists.xen.org Mon Dec 29 16:26:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 16:26:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5d8i-0000Xc-EB; Mon, 29 Dec 2014 16:25: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 1Y5d8h-0000XX-5G
	for xen-devel@lists.xensource.com; Mon, 29 Dec 2014 16:25:51 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	E7/FD-28296-E8081A45; Mon, 29 Dec 2014 16:25:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419870347!16318356!1
X-Originating-IP: [66.165.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 28646 invoked from network); 29 Dec 2014 16:25: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;
	29 Dec 2014 16:25:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="208925165"
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.210.2; Mon, 29 Dec 2014 11:25: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 1Y5d8a-0000d3-7F;
	Mon, 29 Dec 2014 16:25:44 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5d8a-00006n-16;
	Mon, 29 Dec 2014 16:25:44 +0000
Date: Mon, 29 Dec 2014 16:25:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32806-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] 32806: 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 32806 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32806/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail pass in 32758

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)             broken like 32758
 test-armhf-armhf-libvirt     10 capture-logs(10)             broken like 32758
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32758

Tests which did not succeed, but are not blocking:
 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-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       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-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-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-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-winxpsp3 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-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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                    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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 29 16:26:26 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 16:26:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5d8i-0000Xc-EB; Mon, 29 Dec 2014 16:25: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 1Y5d8h-0000XX-5G
	for xen-devel@lists.xensource.com; Mon, 29 Dec 2014 16:25:51 +0000
Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id
	E7/FD-28296-E8081A45; Mon, 29 Dec 2014 16:25:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419870347!16318356!1
X-Originating-IP: [66.165.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 28646 invoked from network); 29 Dec 2014 16:25: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;
	29 Dec 2014 16:25:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="208925165"
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.210.2; Mon, 29 Dec 2014 11:25: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 1Y5d8a-0000d3-7F;
	Mon, 29 Dec 2014 16:25:44 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5d8a-00006n-16;
	Mon, 29 Dec 2014 16:25:44 +0000
Date: Mon, 29 Dec 2014 16:25:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32806-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] 32806: 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 32806 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32806/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail pass in 32758

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)             broken like 32758
 test-armhf-armhf-libvirt     10 capture-logs(10)             broken like 32758
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32758

Tests which did not succeed, but are not blocking:
 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-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       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-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-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-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-winxpsp3 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-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  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                    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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Dec 29 17:35:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 17:35:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5eDk-0001bh-UN; Mon, 29 Dec 2014 17:35: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 1Y5eDj-0001bZ-7t
	for xen-devel@lists.xensource.com; Mon, 29 Dec 2014 17:35:07 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	B1/9C-01660-AC091A45; Mon, 29 Dec 2014 17:35:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1419874504!10245946!1
X-Originating-IP: [66.165.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 8963 invoked from network); 29 Dec 2014 17:35:05 -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 Dec 2014 17:35:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="208955653"
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.210.2; Mon, 29 Dec 2014 12:35: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 1Y5eDe-0000xc-UJ;
	Mon, 29 Dec 2014 17:35:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5eDe-0000H0-Nr;
	Mon, 29 Dec 2014 17:35:02 +0000
Date: Mon, 29 Dec 2014 17:35:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32799-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] 32799: 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 32799 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32799/

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           6 capture-logs(6)           broken pass in 32695
 test-armhf-armhf-libvirt      6 capture-logs(6)           broken pass in 32695

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 13 leak-check/check   fail blocked in 26303
 test-amd64-i386-rhel6hvm-amd  7 redhat-install          fail like 28888-bisect
 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-qemut-debianhvm-amd64 7 debian-hvm-install fail in 32695 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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 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-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 14 guest-stop                fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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 capture-logs(6)
broken-step test-armhf-armhf-libvirt capture-logs(6)

Not pushing.

(No revision log; it would be 34929 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 Dec 29 17:35:32 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 17:35:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5eDk-0001bh-UN; Mon, 29 Dec 2014 17:35: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 1Y5eDj-0001bZ-7t
	for xen-devel@lists.xensource.com; Mon, 29 Dec 2014 17:35:07 +0000
Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id
	B1/9C-01660-AC091A45; Mon, 29 Dec 2014 17:35:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1419874504!10245946!1
X-Originating-IP: [66.165.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 8963 invoked from network); 29 Dec 2014 17:35:05 -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 Dec 2014 17:35:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="208955653"
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.210.2; Mon, 29 Dec 2014 12:35: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 1Y5eDe-0000xc-UJ;
	Mon, 29 Dec 2014 17:35:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5eDe-0000H0-Nr;
	Mon, 29 Dec 2014 17:35:02 +0000
Date: Mon, 29 Dec 2014 17:35:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32799-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] 32799: 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 32799 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32799/

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           6 capture-logs(6)           broken pass in 32695
 test-armhf-armhf-libvirt      6 capture-logs(6)           broken pass in 32695

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 13 leak-check/check   fail blocked in 26303
 test-amd64-i386-rhel6hvm-amd  7 redhat-install          fail like 28888-bisect
 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-qemut-debianhvm-amd64 7 debian-hvm-install fail in 32695 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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 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-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 14 guest-stop                fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 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 capture-logs(6)
broken-step test-armhf-armhf-libvirt capture-logs(6)

Not pushing.

(No revision log; it would be 34929 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 Dec 29 17:52:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 17: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 1Y5eTp-0001sR-FX; Mon, 29 Dec 2014 17:51:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y5eTn-0001sK-Oi
	for xen-devel@lists.xensource.com; Mon, 29 Dec 2014 17:51:43 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	E2/9E-02702-FA491A45; Mon, 29 Dec 2014 17:51:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419875500!17675546!1
X-Originating-IP: [66.165.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 22036 invoked from network); 29 Dec 2014 17:51:42 -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;
	29 Dec 2014 17:51:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="208963207"
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.210.2; Mon, 29 Dec 2014 12:51: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 1Y5eTT-00012M-5z;
	Mon, 29 Dec 2014 17:51:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5eTS-0006wo-Ue;
	Mon, 29 Dec 2014 17:51:23 +0000
Date: Mon, 29 Dec 2014 17:51:22 +0000
Message-ID: <E1Y5eTS-0006wo-Ue@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] [qemu-mainline bisection] complete
	test-amd64-i386-freebsd10-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-freebsd10-amd64
test guest-start

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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-i386-freebsd10-amd64.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32689 fail [host=bush-cricket] / 32598 [host=scape-moth] 32585 [host=leaf-beetle] 32571 [host=field-cricket] 32561 [host=lace-bug] 32542 [host=rice-weevil] 32517 [host=potato-beetle] 32459 ok.
Failure / basis pass flights: 32689 / 32459
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 86b182ac0e0b44726d85598cbefb468ed22517fc 2676bc915157ab474ee478d929b0928cf696b385
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#356a3e1fde11190febb8ace3cdab8694848ed220-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#86b182ac0e0b44726d85598cbefb468ed22517fc-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#2676bc915157ab474ee478d929b0928cf696b385-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-pvops
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.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-pvops
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.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 14348 nodes in revision graph
Searching for test results:
 32517 [host=potato-beetle]
 32459 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 86b182ac0e0b44726d85598cbefb468ed22517fc 2676bc915157ab474ee478d929b0928cf696b385
 32542 [host=rice-weevil]
 32571 [host=field-cricket]
 32561 [host=lace-bug]
 32585 [host=leaf-beetle]
 32598 [host=scape-moth]
 32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32689 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32814 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 e364bab69bd70825e7583e0bbc812fb67b63b366 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32831 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32796 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 86b182ac0e0b44726d85598cbefb468ed22517fc 2676bc915157ab474ee478d929b0928cf696b385
 32817 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ddcd55316fb2851e144e719171621ad2816487dc 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32798 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32832 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32800 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7db96d6cf877d4bb8132462ec7dd19055ff968eb 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32802 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 20302e71a5b654d7b4d0d61c7384e9dd8d112971 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32819 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32805 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 e2c7d025ada047a3f0225f89ff36626d1bd46e47 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32833 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32823 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b28fb27b5edf77f6fd0ac550a156fb20f2218db3 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32808 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b574f602680d41c4cf4a9c106e3e2244bed01cdd 7e88c23239591e2638bcc944151a660fcd53495b
 32825 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32827 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32829 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 32459 (pass), for basis pass
 Result found: flight 32611 (fail), for basis failure
 Repro found: flight 32796 (pass), for basis pass
 Repro found: flight 32798 (fail), for basis failure
 0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32825 (pass), for last pass
 Result found: flight 32827 (fail), for first failure
 Repro found: flight 32829 (pass), for last pass
 Repro found: flight 32831 (fail), for first failure
 Repro found: flight 32832 (pass), for last pass
 Repro found: flight 32833 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-i386-freebsd10-amd64.guest-start.{dot,ps,png,html}.
----------------------------------------
32833: tolerable ALL FAIL

flight 32833 qemu-mainline real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32833/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64  8 guest-start          fail baseline untested


jobs:
 test-amd64-i386-freebsd10-amd64                              fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Dec 29 17:52:09 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 17: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 1Y5eTp-0001sR-FX; Mon, 29 Dec 2014 17:51:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y5eTn-0001sK-Oi
	for xen-devel@lists.xensource.com; Mon, 29 Dec 2014 17:51:43 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	E2/9E-02702-FA491A45; Mon, 29 Dec 2014 17:51:43 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419875500!17675546!1
X-Originating-IP: [66.165.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 22036 invoked from network); 29 Dec 2014 17:51:42 -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;
	29 Dec 2014 17:51:42 -0000
X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="208963207"
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.210.2; Mon, 29 Dec 2014 12:51: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 1Y5eTT-00012M-5z;
	Mon, 29 Dec 2014 17:51:23 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5eTS-0006wo-Ue;
	Mon, 29 Dec 2014 17:51:23 +0000
Date: Mon, 29 Dec 2014 17:51:22 +0000
Message-ID: <E1Y5eTS-0006wo-Ue@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] [qemu-mainline bisection] complete
	test-amd64-i386-freebsd10-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-freebsd10-amd64
test guest-start

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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-i386-freebsd10-amd64.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32689 fail [host=bush-cricket] / 32598 [host=scape-moth] 32585 [host=leaf-beetle] 32571 [host=field-cricket] 32561 [host=lace-bug] 32542 [host=rice-weevil] 32517 [host=potato-beetle] 32459 ok.
Failure / basis pass flights: 32689 / 32459
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 86b182ac0e0b44726d85598cbefb468ed22517fc 2676bc915157ab474ee478d929b0928cf696b385
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#356a3e1fde11190febb8ace3cdab8694848ed220-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#86b182ac0e0b44726d85598cbefb468ed22517fc-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#2676bc915157ab474ee478d929b0928cf696b385-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-pvops
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.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-pvops
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.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 14348 nodes in revision graph
Searching for test results:
 32517 [host=potato-beetle]
 32459 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 86b182ac0e0b44726d85598cbefb468ed22517fc 2676bc915157ab474ee478d929b0928cf696b385
 32542 [host=rice-weevil]
 32571 [host=field-cricket]
 32561 [host=lace-bug]
 32585 [host=leaf-beetle]
 32598 [host=scape-moth]
 32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32689 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32814 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 e364bab69bd70825e7583e0bbc812fb67b63b366 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32831 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32796 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 86b182ac0e0b44726d85598cbefb468ed22517fc 2676bc915157ab474ee478d929b0928cf696b385
 32817 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ddcd55316fb2851e144e719171621ad2816487dc 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32798 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32832 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32800 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7db96d6cf877d4bb8132462ec7dd19055ff968eb 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32802 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 20302e71a5b654d7b4d0d61c7384e9dd8d112971 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32819 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32805 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 e2c7d025ada047a3f0225f89ff36626d1bd46e47 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32833 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32823 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b28fb27b5edf77f6fd0ac550a156fb20f2218db3 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32808 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b574f602680d41c4cf4a9c106e3e2244bed01cdd 7e88c23239591e2638bcc944151a660fcd53495b
 32825 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32827 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32829 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 32459 (pass), for basis pass
 Result found: flight 32611 (fail), for basis failure
 Repro found: flight 32796 (pass), for basis pass
 Repro found: flight 32798 (fail), for basis failure
 0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32825 (pass), for last pass
 Result found: flight 32827 (fail), for first failure
 Repro found: flight 32829 (pass), for last pass
 Repro found: flight 32831 (fail), for first failure
 Repro found: flight 32832 (pass), for last pass
 Repro found: flight 32833 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-i386-freebsd10-amd64.guest-start.{dot,ps,png,html}.
----------------------------------------
32833: tolerable ALL FAIL

flight 32833 qemu-mainline real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32833/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64  8 guest-start          fail baseline untested


jobs:
 test-amd64-i386-freebsd10-amd64                              fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Dec 29 23:41:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 23: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 1Y5jvy-0006is-Su; Mon, 29 Dec 2014 23:41:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xumengpanda@gmail.com>) id 1Y5jvx-0006in-3g
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 23:41:09 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	00/F6-27584-496E1A45; Mon, 29 Dec 2014 23:41:08 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1419896465!15559585!1
X-Originating-IP: [209.85.218.41]
X-SpamReason: No, hits=1.9 required=7.0 tests=HTML_30_40,
	HTML_LINK_OPT_OUT,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27287 invoked from network); 29 Dec 2014 23:41:06 -0000
Received: from mail-oi0-f41.google.com (HELO mail-oi0-f41.google.com)
	(209.85.218.41)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2014 23:41:06 -0000
Received: by mail-oi0-f41.google.com with SMTP id i138so26259587oig.0
	for <xen-devel@lists.xen.org>; Mon, 29 Dec 2014 15:41:05 -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=IXzIDBJJx/G3z5+h2MBdFPZD9AfyBqkaeMvKdaOAljk=;
	b=h000duGyhfIsW6Gj66M/GCTbW28NI+tPi2FDkJynM45OJ0NtBedt9YyJsUJhbk7enU
	rrjdjGAw5LKFMhbk8Ajy+8YaQyQBVcA19VYgNYxDfMvY4ekvUyG5M2X/8Y5H38uoiNU0
	710CLSjzXZFGh/oOKZI8frG0kKP9p47ngG/WkdwjvtIf3MJHPTDHNi93xFOQFzuLPchG
	BPQs2KW+2HEhM81Pfen0imX9if7M3QbEZEYXihUmgjsD1ZanJW+INuoycH20hK3XUfeP
	nOvqCLE/dSSH5SuQX70FLJEG7TK2rGa1gN9ZExr4fuoF1Tq+r8GhFKqGsZjO0bGBzcxo
	5Vbg==
MIME-Version: 1.0
X-Received: by 10.202.92.10 with SMTP id q10mr32370290oib.20.1419896465356;
	Mon, 29 Dec 2014 15:41:05 -0800 (PST)
Received: by 10.76.128.18 with HTTP; Mon, 29 Dec 2014 15:41:05 -0800 (PST)
In-Reply-To: <CADUQMejBN9Uz+=gMNVeGGdGYHSMfs6vwV5zjQLnhxmVvsrqvtg@mail.gmail.com>
References: <CADUQMegeBg2dVXptjo7w+dU5CkTs5gUrM=6HbCuj3NftD05oDA@mail.gmail.com>
	<CADUQMehGUdNXjsvLAKXXwRDDfJMLdbQw6xHk2rMYAFzyUTtaGQ@mail.gmail.com>
	<CADUQMejvxaQkBr=FzoyN8yG12CTmpDKzuF4bX+0pYr9hK9_RUg@mail.gmail.com>
	<CADUQMejBN9Uz+=gMNVeGGdGYHSMfs6vwV5zjQLnhxmVvsrqvtg@mail.gmail.com>
Date: Mon, 29 Dec 2014 18:41:05 -0500
Message-ID: <CAENZ-+mXZ72_uCX=kocA_Vv6NHGiDVMf5YPXDKkKTkZX7_=4ow@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: Jie Shen <jshen25@hawk.iit.edu>
Cc: Xiayu Hua <xiayuhuahxy@gmail.com>,
	"rtxen-devel@googlegroups.com" <rtxen-devel@googlegroups.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [rtxen-devel] Re: rt-xen::make Done::xl :: sched-rm
 not shown:: how to add a command line in xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2225224713506877001=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2225224713506877001==
Content-Type: multipart/alternative; boundary=001a113d55f86f7d73050b636836

--001a113d55f86f7d73050b636836
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Great! :-)

sorry for the so late response. I just came back from vacation. :-)

Best,

Meng

2014-12-15 2:45 GMT-05:00 Jie Shen <jshen25@hawk.iit.edu>:

>
> resolved !!!!
> thanks any way!
>
> info                Get information about Xen host
>  sharing             Get information about page sharing
>  sched-credit        Get/set credit scheduler parameters
>  sched-credit2       Get/set credit2 scheduler parameters
>  sched-rtglobal      Get/set rtglobal scheduler parameters
>  sched-rtpartition   Get/set rtpartition scheduler parameters
>  sched-rm            Get/set rm scheduler parameters
>    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> showing.....
>  sched-sedf          Get/set sedf scheduler parameters
>  domid               Convert a domain name to domain id
>  domname             Convert a domain id to domain name
>  rename              Rename a domain
>
>
>
>
>
>
>
>
>  Best regards
> Jie Shen
>
>
> Graduate Student in Computer Science
> Illinois Institute of Technology
> Stuart Building  Chicago, IL 60616
> +1  312 404 0122
>
>
> On Mon, Dec 15, 2014 at 1:40 AM, Jie Shen <jshen25@hawk.iit.edu> wrote:
>>
>> Hello Gurus,
>> should be the two files :
>>
>> xl_cmdimpl.c
>> xl_cmdtable.c?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  Best regards
>> Jie Shen
>>
>>
>> Graduate Student in Computer Science
>> Illinois Institute of Technology
>> Stuart Building  Chicago, IL 60616
>> +1  312 404 0122
>>
>>
>> On Mon, Dec 15, 2014 at 12:56 AM, Jie Shen <jshen25@hawk.iit.edu> wrote:
>>>
>>>
>>> Hello Gurus ,
>>> Sorry to bother your again.
>>>
>>> Now Make is Done.
>>>
>>> Many errors are resolved ( such as some programming errors on xenbus.c
>>> ,fbfront.c)
>>>
>>>
>>> now I can use xl ,unfortunately, xl no option sched-rm.
>>>
>>> I changed the source of :
>>>
>>> libxl.c   =3D=3D>  output from grep:
>>>
>>> libxl.c:static int sched_rm_domain_get(libxl__gc *gc, uint32_t domid,
>>> libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
>>> libxl.c:static int sched_rm_domain_set(libxl__gc *gc, uint32_t domid,
>>> libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
>>> libxl.c:    rc =3D xc_sched_rm_domain_set(CTX->xch, domid, &sdom);
>>> libxl.c:        ret=3Dsched_rm_domain_set(gc, domid, scinfo);
>>> libxl.c: ret=3Dsched_rm_domain_get(gc,domid,scinfo);
>>>
>>>
>>> and :
>>> xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_set(XcObject
>>> *self,
>>> xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
>>> xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_set(self->xc_handle,
>>> domid, &sdom) !=3D 0 )
>>> xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_get(XcObject
>>> *self, PyObject *args)
>>> xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
>>> xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_get(self->xc_handle,
>>> domid, &sdom) !=3D 0 )
>>> xen/lowlevel/xc/xc.c:   { "sched_rm_domain_set",
>>> xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_set,
>>> xen/lowlevel/xc/xc.c:     { "sched_rm_domain_get",
>>> xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_get,
>>>
>>>
>>> also created :
>>> libxc/xc_rm.c  =3D=3D=3D> just like libxc/xc_rtpartition.c
>>>
>>>
>>>
>>> not changing main.py:
>>>
>>> since I see it is commtented::
>>>
>>>
>>> main.py:    'sched-rtpartition': ('[-d <Domain>
>>> [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=3DEXTRA]]',
>>> main.py:                     'Get/set rtpartition scheduler
>>> parameters.'),
>>> main.py:    'sched-rtpartition': (
>>> main.py:    "sched-rtpartition",
>>> main.py:# # rtpartition
>>> main.py:# def xm_sched_rtpartition(args):
>>> main.py:#     """Get/Set options for rtpartition Scheduler."""
>>> main.py:#     check_sched_type('rtpartition')
>>> main.py:#         usage('sched-rtpartition')
>>> main.py:#             usage('sched-rtpartition')
>>> main.py:#                     info =3D
>>> server.xend.domain.sched_rtpartition_get(d['name'])
>>> main.py:#                 # domain does not support sched-rtpartition?
>>> main.py:#             usage('sched-rtpartition')
>>> main.py:#             result =3D
>>> server.xend.domain.sched_rtpartition_set(domid, period, budget, vcpu, e=
xtra)
>>> main.py:    # "sched-rtpartition": xm_sched_rtpartition,
>>> grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=95
>>>
>>>
>>>
>>>
>>>
>>> my question is how to make xl can changed "sched-rm"  parameters?
>>>
>>>
>>>
>>>
>>> jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl
>>> Usage xl [-vfN] <subcommand> [args]
>>>
>>> xl full list of subcommands:
>>>
>>>  create              Create a domain from config file <filename>
>>>  config-update       Update a running domain's saved configuration, use=
d
>>> when rebuilding the domain after reboot
>>>  list                List information about all/some domains
>>>  destroy             Terminate a domain immediately
>>>  shutdown            Issue a shutdown signal to a domain
>>>  reboot              Issue a reboot signal to a domain
>>>  pci-attach          Insert a new pass-through pci device
>>>  pci-detach          Remove a domain's pass-through pci device
>>>  pci-list            List pass-through pci devices for a domain
>>>  pci-assignable-add  Make a device assignable for pci-passthru
>>>  pci-assignable-remove
>>>                      Remove a device from being assignable
>>>  pci-assignable-list List all the assignable pci devices
>>>  pause               Pause execution of a domain
>>>  unpause             Unpause a paused domain
>>>  console             Attach to domain's console
>>>  vncviewer           Attach to domain's VNC server.
>>>  save                Save a domain state to restore later
>>>  migrate             Migrate a domain to another host
>>>  dump-core           Core dump a domain
>>>  restore             Restore a domain from a saved state
>>>  migrate-receive     Restore a domain from a saved state
>>>  cd-insert           Insert a cdrom into a guest's cd drive
>>>  cd-eject            Eject a cdrom from a guest's cd drive
>>>  mem-max             Set the maximum amount reservation for a domain
>>>  mem-set             Set the current memory usage for a domain
>>>  button-press        Indicate an ACPI button press to the domain
>>>  vcpu-list           List the VCPUs for all/some domains
>>>  vcpu-pin            Set which CPUs a VCPU can use
>>>  vcpu-set            Set the number of active VCPUs allowed for the
>>> domain
>>>  vm-list             List guest domains, excluding dom0, stubdoms, etc.
>>>  info                Get information about Xen host
>>>  sharing             Get information about page sharing
>>>  sched-credit        Get/set credit scheduler parameters
>>>  sched-credit2       Get/set credit2 scheduler parameters
>>>  sched-rtglobal      Get/set rtglobal scheduler parameters
>>>  sched-rtpartition   Get/set rtpartition scheduler parameters
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<><><>  >>> here should be "sched-r=
m"  but not show.  >>>>
>>> it the my question.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  Best regards
>>> Jie Shen
>>>
>>>
>>> Graduate Student in Computer Science
>>> Illinois Institute of Technology
>>> Stuart Building  Chicago, IL 60616
>>> +1  312 404 0122
>>>
>>>    --
> You received this message because you are subscribed to the Google Groups
> "rtxen-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rtxen-devel+unsubscribe@googlegroups.com.
> To post to this group, send email to rtxen-devel@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



--=20


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--001a113d55f86f7d73050b636836
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">Gre=
at! :-)</div><div class=3D"gmail_default" style=3D"font-size:small"><br></d=
iv><div class=3D"gmail_default" style=3D"font-size:small">sorry for the so =
late response. I just came back from vacation. :-)</div><div class=3D"gmail=
_default" style=3D"font-size:small"><br></div><div class=3D"gmail_default" =
style=3D"font-size:small">Best,</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><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">2014-12-15 2:45 GMT-05:00 Jie Shen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jshen25@hawk.iit.edu" target=3D"_blank">jshen25@hawk.iit.edu</a>&gt;<=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>r=
esolved !!!!<div>thanks any way!<br><div><br></div><div><span class=3D""><d=
iv>info =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get informat=
ion about Xen host</div><div>=C2=A0sharing =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Get information about page sharing</div><div>=C2=A0sched-credit =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Get/set credit scheduler parameters</div><div>=
=C2=A0sched-credit2 =C2=A0 =C2=A0 =C2=A0 Get/set credit2 scheduler paramete=
rs</div><div>=C2=A0sched-rtglobal =C2=A0 =C2=A0 =C2=A0Get/set rtglobal sche=
duler parameters</div><div>=C2=A0sched-rtpartition =C2=A0 Get/set rtpartiti=
on scheduler parameters</div></span><div>=C2=A0sched-rm =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Get/set rm scheduler parameters =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=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&gt; showing.....</div><div>=C2=A0sched-sedf =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get/set sedf scheduler parameters</div><d=
iv>=C2=A0domid =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Convert a d=
omain name to domain id</div><div>=C2=A0domname =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 Convert a domain id to domain name</div><div>=C2=A0rename =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rename a domain</div></div>=
<div><br></div></div></div><div class=3D"gmail_extra"><span class=3D""><br =
clear=3D"all"><div><div><div dir=3D"ltr"><div><div><br><br><br><br><br><br>=
=C2=A0Best regards<br>Jie Shen <br><br><br></div>Graduate Student in Comput=
er Science<br></div>Illinois Institute of Technology=C2=A0=C2=A0=C2=A0 <br>=
Stuart Building=C2=A0 Chicago, IL 60616<br><a href=3D"tel:%2B1%C2%A0%20312%=
20404%200122" value=3D"+13124040122" target=3D"_blank">+1=C2=A0 312 404 012=
2</a><br><div><br></div></div></div></div>
<br></span><div><div class=3D"h5"><div class=3D"gmail_quote">On Mon, Dec 15=
, 2014 at 1:40 AM, Jie Shen <span dir=3D"ltr">&lt;<a href=3D"mailto:jshen25=
@hawk.iit.edu" target=3D"_blank">jshen25@hawk.iit.edu</a>&gt;</span> wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello Gurus,<div>should be =
the two files :</div><div><br></div><div>xl_cmdimpl.c</div><div>xl_cmdtable=
.c?</div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><sp=
an><br clear=3D"all"><div><div><div dir=3D"ltr"><div><div><br><br><br><br><=
br><br>=C2=A0Best regards<br>Jie Shen <br><br><br></div>Graduate Student in=
 Computer Science<br></div>Illinois Institute of Technology=C2=A0=C2=A0=C2=
=A0 <br>Stuart Building=C2=A0 Chicago, IL 60616<br><a href=3D"tel:%2B1%C2%A=
0%20312%20404%200122" value=3D"+13124040122" target=3D"_blank">+1=C2=A0 312=
 404 0122</a><br><div><br></div></div></div></div>
<br></span><div><div><div class=3D"gmail_quote">On Mon, Dec 15, 2014 at 12:=
56 AM, Jie Shen <span dir=3D"ltr">&lt;<a href=3D"mailto:jshen25@hawk.iit.ed=
u" target=3D"_blank">jshen25@hawk.iit.edu</a>&gt;</span> wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><br><div dir=
=3D"ltr"><div>Hello Gurus ,</div><div><div><div>Sorry to bother your again.=
<br></div><div><br></div><div>Now Make is Done.</div><div><br></div><div>Ma=
ny errors are resolved ( such as some programming errors on xenbus.c ,fbfro=
nt.c)</div><div><br></div><div><br></div><div>now I can use xl ,unfortunate=
ly, xl no option sched-rm.</div><div><br></div><div>I changed the source of=
 :</div><div><br></div><div>libxl.c =C2=A0 =3D=3D&gt; =C2=A0output from gre=
p:</div><div><br></div><div><div>libxl.c:static int sched_rm_domain_get(lib=
xl__gc *gc, uint32_t domid,</div><div>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched=
_rm_domain_get(CTX-&gt;xch, domid, &amp;sdom);</div><div>libxl.c:static int=
 sched_rm_domain_set(libxl__gc *gc, uint32_t domid,</div><div>libxl.c: =C2=
=A0 =C2=A0rc =3D xc_sched_rm_domain_get(CTX-&gt;xch, domid, &amp;sdom);</di=
v><div>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_domain_set(CTX-&gt;xch, dom=
id, &amp;sdom);</div><div>libxl.c: =C2=A0 =C2=A0 =C2=A0 =C2=A0ret=3Dsched_r=
m_domain_set(gc, domid, scinfo);</div><div>libxl.c:<span style=3D"white-spa=
ce:pre-wrap">		</span>ret=3Dsched_rm_domain_get(gc,domid,scinfo);</div></di=
v><div><br></div><div><br></div><div>and :</div><div><div>xen/lowlevel/xc/x=
c.c:static PyObject *pyxc_sched_rm_domain_set(XcObject *self,</div><div>xen=
/lowlevel/xc/xc.c: =C2=A0 =C2=A0struct xen_domctl_sched_rm sdom;</div><div>=
xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_set(self-&gt;xc_=
handle, domid, &amp;sdom) !=3D 0 )</div><div>xen/lowlevel/xc/xc.c:static Py=
Object *pyxc_sched_rm_domain_get(XcObject *self, PyObject *args)</div><div>=
xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0struct xen_domctl_sched_rm sdom;</div><d=
iv>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_get(self-&gt;=
xc_handle, domid, &amp;sdom) !=3D 0 )</div><div>xen/lowlevel/xc/xc.c: =C2=
=A0 { &quot;sched_rm_domain_set&quot;,</div><div>xen/lowlevel/xc/xc.c: =C2=
=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_set,</div><div>xen/lowle=
vel/xc/xc.c: =C2=A0 =C2=A0 { &quot;sched_rm_domain_get&quot;,</div><div>xen=
/lowlevel/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_ge=
t,</div></div><div><br></div><div><br></div><div>also created :</div><div>l=
ibxc/xc_rm.c =C2=A0=3D=3D=3D&gt; just like=C2=A0libxc/xc_rtpartition.c<br><=
/div><div><br></div><div><br></div><div><br></div><div>not changing main.py=
:</div><div><br></div><div>since I see it is commtented::</div><div><br></d=
iv><div><br></div><div><div>main.py: =C2=A0 =C2=A0&#39;sched-rtpartition&#3=
9;: (&#39;[-d &lt;Domain&gt; [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=
=3DEXTRA]]&#39;,</div><div>main.py: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &#39;Get/set rtpartition scheduler paramete=
rs.&#39;),</div><div>main.py: =C2=A0 =C2=A0&#39;sched-rtpartition&#39;: (</=
div><div>main.py: =C2=A0 =C2=A0&quot;sched-rtpartition&quot;,</div><div>mai=
n.py:# # rtpartition</div><div>main.py:# def xm_sched_rtpartition(args):</d=
iv><div>main.py:# =C2=A0 =C2=A0 &quot;&quot;&quot;Get/Set options for rtpar=
tition Scheduler.&quot;&quot;&quot;</div><div>main.py:# =C2=A0 =C2=A0 check=
_sched_type(&#39;rtpartition&#39;)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div><div>main.py:# =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div><di=
v>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 info =3D server.xend.domain.sched_rtpartition_get(d[&#39;name&#39;])=
</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 # domain does not support sched-rtpartition?</div><div>main.py:# =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div=
><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 result =3D server=
.xend.domain.sched_rtpartition_set(domid, period, budget, vcpu, extra)</div=
><div>main.py: =C2=A0 =C2=A0# &quot;sched-rtpartition&quot;: xm_sched_rtpar=
tition,</div><div>grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=
=95</div></div><div><br></div><div><br></div><div><br></div><div><br></div>=
<div><br></div><div>my question is how to make xl can changed &quot;sched-r=
m&quot; =C2=A0parameters?</div><div><br><br></div><div><br></div><div><br><=
/div><div>jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl<=
/div><div>Usage xl [-vfN] &lt;subcommand&gt; [args]</div><div><br></div><di=
v>xl full list of subcommands:</div><div><br></div><div>=C2=A0create =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Create a domain from config file =
&lt;filename&gt;</div><div>=C2=A0config-update =C2=A0 =C2=A0 =C2=A0 Update =
a running domain&#39;s saved configuration, used when rebuilding the domain=
 after reboot</div><div>=C2=A0list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0List information about all/some domains</div><div>=C2=A0de=
stroy =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Terminate a domain immediat=
ely</div><div>=C2=A0shutdown =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Issue=
 a shutdown signal to a domain</div><div>=C2=A0reboot =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Issue a reboot signal to a domain</div><div>=C2=
=A0pci-attach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Insert a new pass-through p=
ci device</div><div>=C2=A0pci-detach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Remo=
ve a domain&#39;s pass-through pci device</div><div>=C2=A0pci-list =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0List pass-through pci devices for a domai=
n</div><div>=C2=A0pci-assignable-add =C2=A0Make a device assignable for pci=
-passthru</div><div>=C2=A0pci-assignable-remove=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=A0Remove a =
device from being assignable</div><div>=C2=A0pci-assignable-list List all t=
he assignable pci devices</div><div>=C2=A0pause =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 Pause execution of a domain</div><div>=C2=A0unpause =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unpause a paused domain</div><div=
>=C2=A0console =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Attach to domain&#=
39;s console</div><div>=C2=A0vncviewer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A=
ttach to domain&#39;s VNC server.</div><div>=C2=A0save =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Save a domain state to restore later</di=
v><div>=C2=A0migrate =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Migrate a do=
main to another host</div><div>=C2=A0dump-core =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 Core dump a domain</div><div>=C2=A0restore =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Restore a domain from a saved state</div><div>=C2=A0migra=
te-receive =C2=A0 =C2=A0 Restore a domain from a saved state</div><div>=C2=
=A0cd-insert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Insert a cdrom into a guest=
&#39;s cd drive</div><div>=C2=A0cd-eject =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0Eject a cdrom from a guest&#39;s cd drive</div><div>=C2=A0mem-max =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Set the maximum amount reservatio=
n for a domain</div><div>=C2=A0mem-set =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 Set the current memory usage for a domain</div><div>=C2=A0button-pre=
ss =C2=A0 =C2=A0 =C2=A0 =C2=A0Indicate an ACPI button press to the domain</=
div><div>=C2=A0vcpu-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 List the VCPUs =
for all/some domains</div><div>=C2=A0vcpu-pin =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Set which CPUs a VCPU can use</div><div>=C2=A0vcpu-set =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Set the number of active VCPUs allowed fo=
r the domain</div><div>=C2=A0vm-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 List guest domains, excluding dom0, stubdoms, etc.</div><div>=C2=A0info=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get information abo=
ut Xen host</div><div>=C2=A0sharing =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 Get information about page sharing</div><div>=C2=A0sched-credit =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Get/set credit scheduler parameters</div><div>=C2=A0sch=
ed-credit2 =C2=A0 =C2=A0 =C2=A0 Get/set credit2 scheduler parameters</div><=
div>=C2=A0sched-rtglobal =C2=A0 =C2=A0 =C2=A0Get/set rtglobal scheduler par=
ameters</div><div>=C2=A0sched-rtpartition =C2=A0 Get/set rtpartition schedu=
ler parameters</div></div></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&l=
t;&gt;&lt;&gt;&lt;&gt; =C2=A0&gt;&gt;&gt; here should be &quot;sched-rm&quo=
t; =C2=A0but not show. =C2=A0&gt;&gt;&gt;&gt; it the my question.</div><spa=
n><div><br></div><div><br></div><div><div><div dir=3D"ltr"><div><div><br><b=
r><br><br><br><br>=C2=A0Best regards<br>Jie Shen <br><br><br></div>Graduate=
 Student in Computer Science<br></div>Illinois Institute of Technology=C2=
=A0=C2=A0=C2=A0 <br>Stuart Building=C2=A0 Chicago, IL 60616<br><a href=3D"t=
el:%2B1%C2%A0%20312%20404%200122" value=3D"+13124040122" target=3D"_blank">=
+1=C2=A0 312 404 0122</a><br><div><br></div></div></div></div>
</span></div>
</div></div>
</blockquote></div></div></div></div>
</blockquote></div></div></div></div><div class=3D"HOEnZb"><div class=3D"h5=
">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;rtxen-devel&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:rtxen-devel+unsubscribe@googlegroups.com" target=
=3D"_blank">rtxen-devel+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to <a href=3D"mailto:rtxen-devel@googlegr=
oups.com" target=3D"_blank">rtxen-devel@googlegroups.com</a>.<br>
For more options, visit <a href=3D"https://groups.google.com/d/optout" targ=
et=3D"_blank">https://groups.google.com/d/optout</a>.<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>

--001a113d55f86f7d73050b636836--


--===============2225224713506877001==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2225224713506877001==--


From xen-devel-bounces@lists.xen.org Mon Dec 29 23:41:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Dec 2014 23: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 1Y5jvy-0006is-Su; Mon, 29 Dec 2014 23:41:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xumengpanda@gmail.com>) id 1Y5jvx-0006in-3g
	for xen-devel@lists.xen.org; Mon, 29 Dec 2014 23:41:09 +0000
Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id
	00/F6-27584-496E1A45; Mon, 29 Dec 2014 23:41:08 +0000
X-Env-Sender: xumengpanda@gmail.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1419896465!15559585!1
X-Originating-IP: [209.85.218.41]
X-SpamReason: No, hits=1.9 required=7.0 tests=HTML_30_40,
	HTML_LINK_OPT_OUT,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27287 invoked from network); 29 Dec 2014 23:41:06 -0000
Received: from mail-oi0-f41.google.com (HELO mail-oi0-f41.google.com)
	(209.85.218.41)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Dec 2014 23:41:06 -0000
Received: by mail-oi0-f41.google.com with SMTP id i138so26259587oig.0
	for <xen-devel@lists.xen.org>; Mon, 29 Dec 2014 15:41:05 -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=IXzIDBJJx/G3z5+h2MBdFPZD9AfyBqkaeMvKdaOAljk=;
	b=h000duGyhfIsW6Gj66M/GCTbW28NI+tPi2FDkJynM45OJ0NtBedt9YyJsUJhbk7enU
	rrjdjGAw5LKFMhbk8Ajy+8YaQyQBVcA19VYgNYxDfMvY4ekvUyG5M2X/8Y5H38uoiNU0
	710CLSjzXZFGh/oOKZI8frG0kKP9p47ngG/WkdwjvtIf3MJHPTDHNi93xFOQFzuLPchG
	BPQs2KW+2HEhM81Pfen0imX9if7M3QbEZEYXihUmgjsD1ZanJW+INuoycH20hK3XUfeP
	nOvqCLE/dSSH5SuQX70FLJEG7TK2rGa1gN9ZExr4fuoF1Tq+r8GhFKqGsZjO0bGBzcxo
	5Vbg==
MIME-Version: 1.0
X-Received: by 10.202.92.10 with SMTP id q10mr32370290oib.20.1419896465356;
	Mon, 29 Dec 2014 15:41:05 -0800 (PST)
Received: by 10.76.128.18 with HTTP; Mon, 29 Dec 2014 15:41:05 -0800 (PST)
In-Reply-To: <CADUQMejBN9Uz+=gMNVeGGdGYHSMfs6vwV5zjQLnhxmVvsrqvtg@mail.gmail.com>
References: <CADUQMegeBg2dVXptjo7w+dU5CkTs5gUrM=6HbCuj3NftD05oDA@mail.gmail.com>
	<CADUQMehGUdNXjsvLAKXXwRDDfJMLdbQw6xHk2rMYAFzyUTtaGQ@mail.gmail.com>
	<CADUQMejvxaQkBr=FzoyN8yG12CTmpDKzuF4bX+0pYr9hK9_RUg@mail.gmail.com>
	<CADUQMejBN9Uz+=gMNVeGGdGYHSMfs6vwV5zjQLnhxmVvsrqvtg@mail.gmail.com>
Date: Mon, 29 Dec 2014 18:41:05 -0500
Message-ID: <CAENZ-+mXZ72_uCX=kocA_Vv6NHGiDVMf5YPXDKkKTkZX7_=4ow@mail.gmail.com>
From: Meng Xu <xumengpanda@gmail.com>
To: Jie Shen <jshen25@hawk.iit.edu>
Cc: Xiayu Hua <xiayuhuahxy@gmail.com>,
	"rtxen-devel@googlegroups.com" <rtxen-devel@googlegroups.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [rtxen-devel] Re: rt-xen::make Done::xl :: sched-rm
 not shown:: how to add a command line in xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2225224713506877001=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2225224713506877001==
Content-Type: multipart/alternative; boundary=001a113d55f86f7d73050b636836

--001a113d55f86f7d73050b636836
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Great! :-)

sorry for the so late response. I just came back from vacation. :-)

Best,

Meng

2014-12-15 2:45 GMT-05:00 Jie Shen <jshen25@hawk.iit.edu>:

>
> resolved !!!!
> thanks any way!
>
> info                Get information about Xen host
>  sharing             Get information about page sharing
>  sched-credit        Get/set credit scheduler parameters
>  sched-credit2       Get/set credit2 scheduler parameters
>  sched-rtglobal      Get/set rtglobal scheduler parameters
>  sched-rtpartition   Get/set rtpartition scheduler parameters
>  sched-rm            Get/set rm scheduler parameters
>    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> showing.....
>  sched-sedf          Get/set sedf scheduler parameters
>  domid               Convert a domain name to domain id
>  domname             Convert a domain id to domain name
>  rename              Rename a domain
>
>
>
>
>
>
>
>
>  Best regards
> Jie Shen
>
>
> Graduate Student in Computer Science
> Illinois Institute of Technology
> Stuart Building  Chicago, IL 60616
> +1  312 404 0122
>
>
> On Mon, Dec 15, 2014 at 1:40 AM, Jie Shen <jshen25@hawk.iit.edu> wrote:
>>
>> Hello Gurus,
>> should be the two files :
>>
>> xl_cmdimpl.c
>> xl_cmdtable.c?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  Best regards
>> Jie Shen
>>
>>
>> Graduate Student in Computer Science
>> Illinois Institute of Technology
>> Stuart Building  Chicago, IL 60616
>> +1  312 404 0122
>>
>>
>> On Mon, Dec 15, 2014 at 12:56 AM, Jie Shen <jshen25@hawk.iit.edu> wrote:
>>>
>>>
>>> Hello Gurus ,
>>> Sorry to bother your again.
>>>
>>> Now Make is Done.
>>>
>>> Many errors are resolved ( such as some programming errors on xenbus.c
>>> ,fbfront.c)
>>>
>>>
>>> now I can use xl ,unfortunately, xl no option sched-rm.
>>>
>>> I changed the source of :
>>>
>>> libxl.c   =3D=3D>  output from grep:
>>>
>>> libxl.c:static int sched_rm_domain_get(libxl__gc *gc, uint32_t domid,
>>> libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
>>> libxl.c:static int sched_rm_domain_set(libxl__gc *gc, uint32_t domid,
>>> libxl.c:    rc =3D xc_sched_rm_domain_get(CTX->xch, domid, &sdom);
>>> libxl.c:    rc =3D xc_sched_rm_domain_set(CTX->xch, domid, &sdom);
>>> libxl.c:        ret=3Dsched_rm_domain_set(gc, domid, scinfo);
>>> libxl.c: ret=3Dsched_rm_domain_get(gc,domid,scinfo);
>>>
>>>
>>> and :
>>> xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_set(XcObject
>>> *self,
>>> xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
>>> xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_set(self->xc_handle,
>>> domid, &sdom) !=3D 0 )
>>> xen/lowlevel/xc/xc.c:static PyObject *pyxc_sched_rm_domain_get(XcObject
>>> *self, PyObject *args)
>>> xen/lowlevel/xc/xc.c:    struct xen_domctl_sched_rm sdom;
>>> xen/lowlevel/xc/xc.c:    if ( xc_sched_rm_domain_get(self->xc_handle,
>>> domid, &sdom) !=3D 0 )
>>> xen/lowlevel/xc/xc.c:   { "sched_rm_domain_set",
>>> xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_set,
>>> xen/lowlevel/xc/xc.c:     { "sched_rm_domain_get",
>>> xen/lowlevel/xc/xc.c:      (PyCFunction)pyxc_sched_rm_domain_get,
>>>
>>>
>>> also created :
>>> libxc/xc_rm.c  =3D=3D=3D> just like libxc/xc_rtpartition.c
>>>
>>>
>>>
>>> not changing main.py:
>>>
>>> since I see it is commtented::
>>>
>>>
>>> main.py:    'sched-rtpartition': ('[-d <Domain>
>>> [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=3DEXTRA]]',
>>> main.py:                     'Get/set rtpartition scheduler
>>> parameters.'),
>>> main.py:    'sched-rtpartition': (
>>> main.py:    "sched-rtpartition",
>>> main.py:# # rtpartition
>>> main.py:# def xm_sched_rtpartition(args):
>>> main.py:#     """Get/Set options for rtpartition Scheduler."""
>>> main.py:#     check_sched_type('rtpartition')
>>> main.py:#         usage('sched-rtpartition')
>>> main.py:#             usage('sched-rtpartition')
>>> main.py:#                     info =3D
>>> server.xend.domain.sched_rtpartition_get(d['name'])
>>> main.py:#                 # domain does not support sched-rtpartition?
>>> main.py:#             usage('sched-rtpartition')
>>> main.py:#             result =3D
>>> server.xend.domain.sched_rtpartition_set(domid, period, budget, vcpu, e=
xtra)
>>> main.py:    # "sched-rtpartition": xm_sched_rtpartition,
>>> grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=95
>>>
>>>
>>>
>>>
>>>
>>> my question is how to make xl can changed "sched-rm"  parameters?
>>>
>>>
>>>
>>>
>>> jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl
>>> Usage xl [-vfN] <subcommand> [args]
>>>
>>> xl full list of subcommands:
>>>
>>>  create              Create a domain from config file <filename>
>>>  config-update       Update a running domain's saved configuration, use=
d
>>> when rebuilding the domain after reboot
>>>  list                List information about all/some domains
>>>  destroy             Terminate a domain immediately
>>>  shutdown            Issue a shutdown signal to a domain
>>>  reboot              Issue a reboot signal to a domain
>>>  pci-attach          Insert a new pass-through pci device
>>>  pci-detach          Remove a domain's pass-through pci device
>>>  pci-list            List pass-through pci devices for a domain
>>>  pci-assignable-add  Make a device assignable for pci-passthru
>>>  pci-assignable-remove
>>>                      Remove a device from being assignable
>>>  pci-assignable-list List all the assignable pci devices
>>>  pause               Pause execution of a domain
>>>  unpause             Unpause a paused domain
>>>  console             Attach to domain's console
>>>  vncviewer           Attach to domain's VNC server.
>>>  save                Save a domain state to restore later
>>>  migrate             Migrate a domain to another host
>>>  dump-core           Core dump a domain
>>>  restore             Restore a domain from a saved state
>>>  migrate-receive     Restore a domain from a saved state
>>>  cd-insert           Insert a cdrom into a guest's cd drive
>>>  cd-eject            Eject a cdrom from a guest's cd drive
>>>  mem-max             Set the maximum amount reservation for a domain
>>>  mem-set             Set the current memory usage for a domain
>>>  button-press        Indicate an ACPI button press to the domain
>>>  vcpu-list           List the VCPUs for all/some domains
>>>  vcpu-pin            Set which CPUs a VCPU can use
>>>  vcpu-set            Set the number of active VCPUs allowed for the
>>> domain
>>>  vm-list             List guest domains, excluding dom0, stubdoms, etc.
>>>  info                Get information about Xen host
>>>  sharing             Get information about page sharing
>>>  sched-credit        Get/set credit scheduler parameters
>>>  sched-credit2       Get/set credit2 scheduler parameters
>>>  sched-rtglobal      Get/set rtglobal scheduler parameters
>>>  sched-rtpartition   Get/set rtpartition scheduler parameters
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<><><>  >>> here should be "sched-r=
m"  but not show.  >>>>
>>> it the my question.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  Best regards
>>> Jie Shen
>>>
>>>
>>> Graduate Student in Computer Science
>>> Illinois Institute of Technology
>>> Stuart Building  Chicago, IL 60616
>>> +1  312 404 0122
>>>
>>>    --
> You received this message because you are subscribed to the Google Groups
> "rtxen-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rtxen-devel+unsubscribe@googlegroups.com.
> To post to this group, send email to rtxen-devel@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



--=20


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

--001a113d55f86f7d73050b636836
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">Gre=
at! :-)</div><div class=3D"gmail_default" style=3D"font-size:small"><br></d=
iv><div class=3D"gmail_default" style=3D"font-size:small">sorry for the so =
late response. I just came back from vacation. :-)</div><div class=3D"gmail=
_default" style=3D"font-size:small"><br></div><div class=3D"gmail_default" =
style=3D"font-size:small">Best,</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><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">2014-12-15 2:45 GMT-05:00 Jie Shen <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jshen25@hawk.iit.edu" target=3D"_blank">jshen25@hawk.iit.edu</a>&gt;<=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>r=
esolved !!!!<div>thanks any way!<br><div><br></div><div><span class=3D""><d=
iv>info =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get informat=
ion about Xen host</div><div>=C2=A0sharing =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Get information about page sharing</div><div>=C2=A0sched-credit =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Get/set credit scheduler parameters</div><div>=
=C2=A0sched-credit2 =C2=A0 =C2=A0 =C2=A0 Get/set credit2 scheduler paramete=
rs</div><div>=C2=A0sched-rtglobal =C2=A0 =C2=A0 =C2=A0Get/set rtglobal sche=
duler parameters</div><div>=C2=A0sched-rtpartition =C2=A0 Get/set rtpartiti=
on scheduler parameters</div></span><div>=C2=A0sched-rm =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Get/set rm scheduler parameters =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=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&gt; showing.....</div><div>=C2=A0sched-sedf =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get/set sedf scheduler parameters</div><d=
iv>=C2=A0domid =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Convert a d=
omain name to domain id</div><div>=C2=A0domname =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 Convert a domain id to domain name</div><div>=C2=A0rename =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rename a domain</div></div>=
<div><br></div></div></div><div class=3D"gmail_extra"><span class=3D""><br =
clear=3D"all"><div><div><div dir=3D"ltr"><div><div><br><br><br><br><br><br>=
=C2=A0Best regards<br>Jie Shen <br><br><br></div>Graduate Student in Comput=
er Science<br></div>Illinois Institute of Technology=C2=A0=C2=A0=C2=A0 <br>=
Stuart Building=C2=A0 Chicago, IL 60616<br><a href=3D"tel:%2B1%C2%A0%20312%=
20404%200122" value=3D"+13124040122" target=3D"_blank">+1=C2=A0 312 404 012=
2</a><br><div><br></div></div></div></div>
<br></span><div><div class=3D"h5"><div class=3D"gmail_quote">On Mon, Dec 15=
, 2014 at 1:40 AM, Jie Shen <span dir=3D"ltr">&lt;<a href=3D"mailto:jshen25=
@hawk.iit.edu" target=3D"_blank">jshen25@hawk.iit.edu</a>&gt;</span> wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello Gurus,<div>should be =
the two files :</div><div><br></div><div>xl_cmdimpl.c</div><div>xl_cmdtable=
.c?</div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><sp=
an><br clear=3D"all"><div><div><div dir=3D"ltr"><div><div><br><br><br><br><=
br><br>=C2=A0Best regards<br>Jie Shen <br><br><br></div>Graduate Student in=
 Computer Science<br></div>Illinois Institute of Technology=C2=A0=C2=A0=C2=
=A0 <br>Stuart Building=C2=A0 Chicago, IL 60616<br><a href=3D"tel:%2B1%C2%A=
0%20312%20404%200122" value=3D"+13124040122" target=3D"_blank">+1=C2=A0 312=
 404 0122</a><br><div><br></div></div></div></div>
<br></span><div><div><div class=3D"gmail_quote">On Mon, Dec 15, 2014 at 12:=
56 AM, Jie Shen <span dir=3D"ltr">&lt;<a href=3D"mailto:jshen25@hawk.iit.ed=
u" target=3D"_blank">jshen25@hawk.iit.edu</a>&gt;</span> wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><br><div dir=
=3D"ltr"><div>Hello Gurus ,</div><div><div><div>Sorry to bother your again.=
<br></div><div><br></div><div>Now Make is Done.</div><div><br></div><div>Ma=
ny errors are resolved ( such as some programming errors on xenbus.c ,fbfro=
nt.c)</div><div><br></div><div><br></div><div>now I can use xl ,unfortunate=
ly, xl no option sched-rm.</div><div><br></div><div>I changed the source of=
 :</div><div><br></div><div>libxl.c =C2=A0 =3D=3D&gt; =C2=A0output from gre=
p:</div><div><br></div><div><div>libxl.c:static int sched_rm_domain_get(lib=
xl__gc *gc, uint32_t domid,</div><div>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched=
_rm_domain_get(CTX-&gt;xch, domid, &amp;sdom);</div><div>libxl.c:static int=
 sched_rm_domain_set(libxl__gc *gc, uint32_t domid,</div><div>libxl.c: =C2=
=A0 =C2=A0rc =3D xc_sched_rm_domain_get(CTX-&gt;xch, domid, &amp;sdom);</di=
v><div>libxl.c: =C2=A0 =C2=A0rc =3D xc_sched_rm_domain_set(CTX-&gt;xch, dom=
id, &amp;sdom);</div><div>libxl.c: =C2=A0 =C2=A0 =C2=A0 =C2=A0ret=3Dsched_r=
m_domain_set(gc, domid, scinfo);</div><div>libxl.c:<span style=3D"white-spa=
ce:pre-wrap">		</span>ret=3Dsched_rm_domain_get(gc,domid,scinfo);</div></di=
v><div><br></div><div><br></div><div>and :</div><div><div>xen/lowlevel/xc/x=
c.c:static PyObject *pyxc_sched_rm_domain_set(XcObject *self,</div><div>xen=
/lowlevel/xc/xc.c: =C2=A0 =C2=A0struct xen_domctl_sched_rm sdom;</div><div>=
xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_set(self-&gt;xc_=
handle, domid, &amp;sdom) !=3D 0 )</div><div>xen/lowlevel/xc/xc.c:static Py=
Object *pyxc_sched_rm_domain_get(XcObject *self, PyObject *args)</div><div>=
xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0struct xen_domctl_sched_rm sdom;</div><d=
iv>xen/lowlevel/xc/xc.c: =C2=A0 =C2=A0if ( xc_sched_rm_domain_get(self-&gt;=
xc_handle, domid, &amp;sdom) !=3D 0 )</div><div>xen/lowlevel/xc/xc.c: =C2=
=A0 { &quot;sched_rm_domain_set&quot;,</div><div>xen/lowlevel/xc/xc.c: =C2=
=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_set,</div><div>xen/lowle=
vel/xc/xc.c: =C2=A0 =C2=A0 { &quot;sched_rm_domain_get&quot;,</div><div>xen=
/lowlevel/xc/xc.c: =C2=A0 =C2=A0 =C2=A0(PyCFunction)pyxc_sched_rm_domain_ge=
t,</div></div><div><br></div><div><br></div><div>also created :</div><div>l=
ibxc/xc_rm.c =C2=A0=3D=3D=3D&gt; just like=C2=A0libxc/xc_rtpartition.c<br><=
/div><div><br></div><div><br></div><div><br></div><div>not changing main.py=
:</div><div><br></div><div>since I see it is commtented::</div><div><br></d=
iv><div><br></div><div><div>main.py: =C2=A0 =C2=A0&#39;sched-rtpartition&#3=
9;: (&#39;[-d &lt;Domain&gt; [-p[=3DPERIOD]|-b[=3DBUDGET]|-v[=3DVCPU]|-e[=
=3DEXTRA]]&#39;,</div><div>main.py: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &#39;Get/set rtpartition scheduler paramete=
rs.&#39;),</div><div>main.py: =C2=A0 =C2=A0&#39;sched-rtpartition&#39;: (</=
div><div>main.py: =C2=A0 =C2=A0&quot;sched-rtpartition&quot;,</div><div>mai=
n.py:# # rtpartition</div><div>main.py:# def xm_sched_rtpartition(args):</d=
iv><div>main.py:# =C2=A0 =C2=A0 &quot;&quot;&quot;Get/Set options for rtpar=
tition Scheduler.&quot;&quot;&quot;</div><div>main.py:# =C2=A0 =C2=A0 check=
_sched_type(&#39;rtpartition&#39;)</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div><div>main.py:# =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div><di=
v>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 info =3D server.xend.domain.sched_rtpartition_get(d[&#39;name&#39;])=
</div><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 # domain does not support sched-rtpartition?</div><div>main.py:# =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usage(&#39;sched-rtpartition&#39;)</div=
><div>main.py:# =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 result =3D server=
.xend.domain.sched_rtpartition_set(domid, period, budget, vcpu, extra)</div=
><div>main.py: =C2=A0 =C2=A0# &quot;sched-rtpartition&quot;: xm_sched_rtpar=
tition,</div><div>grep: tests: =E6=98=AF=E4=B8=80=E4=B8=AA=E7=9B=AE=E5=BD=
=95</div></div><div><br></div><div><br></div><div><br></div><div><br></div>=
<div><br></div><div>my question is how to make xl can changed &quot;sched-r=
m&quot; =C2=A0parameters?</div><div><br><br></div><div><br></div><div><br><=
/div><div>jackyshen@jackyshen-ThinkPad-T410:~/RT-XEN/RT-Xen-rt-xen_2.0$ xl<=
/div><div>Usage xl [-vfN] &lt;subcommand&gt; [args]</div><div><br></div><di=
v>xl full list of subcommands:</div><div><br></div><div>=C2=A0create =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Create a domain from config file =
&lt;filename&gt;</div><div>=C2=A0config-update =C2=A0 =C2=A0 =C2=A0 Update =
a running domain&#39;s saved configuration, used when rebuilding the domain=
 after reboot</div><div>=C2=A0list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0List information about all/some domains</div><div>=C2=A0de=
stroy =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Terminate a domain immediat=
ely</div><div>=C2=A0shutdown =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Issue=
 a shutdown signal to a domain</div><div>=C2=A0reboot =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Issue a reboot signal to a domain</div><div>=C2=
=A0pci-attach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Insert a new pass-through p=
ci device</div><div>=C2=A0pci-detach =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Remo=
ve a domain&#39;s pass-through pci device</div><div>=C2=A0pci-list =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0List pass-through pci devices for a domai=
n</div><div>=C2=A0pci-assignable-add =C2=A0Make a device assignable for pci=
-passthru</div><div>=C2=A0pci-assignable-remove=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=A0Remove a =
device from being assignable</div><div>=C2=A0pci-assignable-list List all t=
he assignable pci devices</div><div>=C2=A0pause =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 Pause execution of a domain</div><div>=C2=A0unpause =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unpause a paused domain</div><div=
>=C2=A0console =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Attach to domain&#=
39;s console</div><div>=C2=A0vncviewer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A=
ttach to domain&#39;s VNC server.</div><div>=C2=A0save =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Save a domain state to restore later</di=
v><div>=C2=A0migrate =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Migrate a do=
main to another host</div><div>=C2=A0dump-core =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 Core dump a domain</div><div>=C2=A0restore =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Restore a domain from a saved state</div><div>=C2=A0migra=
te-receive =C2=A0 =C2=A0 Restore a domain from a saved state</div><div>=C2=
=A0cd-insert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Insert a cdrom into a guest=
&#39;s cd drive</div><div>=C2=A0cd-eject =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0Eject a cdrom from a guest&#39;s cd drive</div><div>=C2=A0mem-max =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Set the maximum amount reservatio=
n for a domain</div><div>=C2=A0mem-set =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 Set the current memory usage for a domain</div><div>=C2=A0button-pre=
ss =C2=A0 =C2=A0 =C2=A0 =C2=A0Indicate an ACPI button press to the domain</=
div><div>=C2=A0vcpu-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 List the VCPUs =
for all/some domains</div><div>=C2=A0vcpu-pin =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Set which CPUs a VCPU can use</div><div>=C2=A0vcpu-set =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Set the number of active VCPUs allowed fo=
r the domain</div><div>=C2=A0vm-list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 List guest domains, excluding dom0, stubdoms, etc.</div><div>=C2=A0info=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Get information abo=
ut Xen host</div><div>=C2=A0sharing =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 Get information about page sharing</div><div>=C2=A0sched-credit =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Get/set credit scheduler parameters</div><div>=C2=A0sch=
ed-credit2 =C2=A0 =C2=A0 =C2=A0 Get/set credit2 scheduler parameters</div><=
div>=C2=A0sched-rtglobal =C2=A0 =C2=A0 =C2=A0Get/set rtglobal scheduler par=
ameters</div><div>=C2=A0sched-rtpartition =C2=A0 Get/set rtpartition schedu=
ler parameters</div></div></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&l=
t;&gt;&lt;&gt;&lt;&gt; =C2=A0&gt;&gt;&gt; here should be &quot;sched-rm&quo=
t; =C2=A0but not show. =C2=A0&gt;&gt;&gt;&gt; it the my question.</div><spa=
n><div><br></div><div><br></div><div><div><div dir=3D"ltr"><div><div><br><b=
r><br><br><br><br>=C2=A0Best regards<br>Jie Shen <br><br><br></div>Graduate=
 Student in Computer Science<br></div>Illinois Institute of Technology=C2=
=A0=C2=A0=C2=A0 <br>Stuart Building=C2=A0 Chicago, IL 60616<br><a href=3D"t=
el:%2B1%C2%A0%20312%20404%200122" value=3D"+13124040122" target=3D"_blank">=
+1=C2=A0 312 404 0122</a><br><div><br></div></div></div></div>
</span></div>
</div></div>
</blockquote></div></div></div></div>
</blockquote></div></div></div></div><div class=3D"HOEnZb"><div class=3D"h5=
">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;rtxen-devel&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:rtxen-devel+unsubscribe@googlegroups.com" target=
=3D"_blank">rtxen-devel+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to <a href=3D"mailto:rtxen-devel@googlegr=
oups.com" target=3D"_blank">rtxen-devel@googlegroups.com</a>.<br>
For more options, visit <a href=3D"https://groups.google.com/d/optout" targ=
et=3D"_blank">https://groups.google.com/d/optout</a>.<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>

--001a113d55f86f7d73050b636836--


--===============2225224713506877001==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2225224713506877001==--


From xen-devel-bounces@lists.xen.org Tue Dec 30 01:22:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 01:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5lVg-0004HF-2e; Tue, 30 Dec 2014 01:22:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y5lVf-0004H7-24
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 01:22:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E5/18-25276-E3EF1A45; Tue, 30 Dec 2014 01:22:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1419902524!18349543!1
X-Originating-IP: [66.165.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 7101 invoked from network); 30 Dec 2014 01:22:05 -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;
	30 Dec 2014 01:22:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,662,1413244800"; d="scan'208";a="209110731"
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.210.2; Mon, 29 Dec 2014 20:22: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 1Y5lVa-0003BO-Oz;
	Tue, 30 Dec 2014 01:22:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5lVa-0002C0-HV;
	Tue, 30 Dec 2014 01:22:02 +0000
Date: Tue, 30 Dec 2014 01:22:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32813-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] 32813: 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 32813 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32813/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)          broken pass in 32689
 test-armhf-armhf-libvirt     10 capture-logs(10)          broken pass in 32689
 test-amd64-amd64-libvirt      5 xen-boot                    fail pass in 32770
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot   fail in 32770 pass in 32813
 test-amd64-i386-xl-qemut-debianhvm-amd64 5 xen-boot fail in 32770 pass in 32813

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-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-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 32689 never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Not pushing.

(No revision log; it would be 912 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 Dec 30 01:22:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 01:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5lVg-0004HF-2e; Tue, 30 Dec 2014 01:22:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y5lVf-0004H7-24
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 01:22:07 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	E5/18-25276-E3EF1A45; Tue, 30 Dec 2014 01:22:06 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1419902524!18349543!1
X-Originating-IP: [66.165.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 7101 invoked from network); 30 Dec 2014 01:22:05 -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;
	30 Dec 2014 01:22:05 -0000
X-IronPort-AV: E=Sophos;i="5.07,662,1413244800"; d="scan'208";a="209110731"
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.210.2; Mon, 29 Dec 2014 20:22: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 1Y5lVa-0003BO-Oz;
	Tue, 30 Dec 2014 01:22:02 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5lVa-0002C0-HV;
	Tue, 30 Dec 2014 01:22:02 +0000
Date: Tue, 30 Dec 2014 01:22:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32813-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] 32813: 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 32813 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32813/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl          15 capture-logs(15)          broken pass in 32689
 test-armhf-armhf-libvirt     10 capture-logs(10)          broken pass in 32689
 test-amd64-amd64-libvirt      5 xen-boot                    fail pass in 32770
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot   fail in 32770 pass in 32813
 test-amd64-i386-xl-qemut-debianhvm-amd64 5 xen-boot fail in 32770 pass in 32813

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-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-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-libvirt      9 guest-start           fail in 32689 never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     broken  
 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 capture-logs(15)
broken-step test-armhf-armhf-libvirt capture-logs(10)

Not pushing.

(No revision log; it would be 912 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 Dec 30 03:34:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 03:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5nZK-0006SM-Kx; Tue, 30 Dec 2014 03:34:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y5nZI-0006SH-Kc
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 03:34:00 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	1C/9D-11608-72D12A45; Tue, 30 Dec 2014 03:33:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419910437!16384209!1
X-Originating-IP: [66.165.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 25492 invoked from network); 30 Dec 2014 03:33: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;
	30 Dec 2014 03:33:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,662,1413244800"; d="scan'208";a="209693146"
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.210.2; Mon, 29 Dec 2014 22:33: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 1Y5nZD-0003oZ-E4;
	Tue, 30 Dec 2014 03:33:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5nZD-0005ov-7S;
	Tue, 30 Dec 2014 03:33:55 +0000
Date: Tue, 30 Dec 2014 03:33:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32820-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] 32820: 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 32820 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32820/

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. 32674

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt     10 capture-logs(10)          broken pass in 32686
 test-armhf-armhf-xl          15 capture-logs(15)          broken pass in 32686
 test-amd64-i386-pair          4 host-install/dst_host(4)  broken pass in 32686

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32674
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32674
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32674
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 32686 like 32674

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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                2fb8bdb2ca2808ce901fdfc1eda31bcb488156d0
baseline version:
 linux                08b022a9655bf925e6683422590306429b752ccd

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 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 Tue Dec 30 03:34:43 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 03:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5nZK-0006SM-Kx; Tue, 30 Dec 2014 03:34:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y5nZI-0006SH-Kc
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 03:34:00 +0000
Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id
	1C/9D-11608-72D12A45; Tue, 30 Dec 2014 03:33:59 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1419910437!16384209!1
X-Originating-IP: [66.165.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 25492 invoked from network); 30 Dec 2014 03:33: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;
	30 Dec 2014 03:33:58 -0000
X-IronPort-AV: E=Sophos;i="5.07,662,1413244800"; d="scan'208";a="209693146"
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.210.2; Mon, 29 Dec 2014 22:33: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 1Y5nZD-0003oZ-E4;
	Tue, 30 Dec 2014 03:33:55 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5nZD-0005ov-7S;
	Tue, 30 Dec 2014 03:33:55 +0000
Date: Tue, 30 Dec 2014 03:33:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32820-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] 32820: 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 32820 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32820/

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. 32674

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt     10 capture-logs(10)          broken pass in 32686
 test-armhf-armhf-xl          15 capture-logs(15)          broken pass in 32686
 test-amd64-i386-pair          4 host-install/dst_host(4)  broken pass in 32686

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32674
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32674
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32674
 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail in 32686 like 32674

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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-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-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                2fb8bdb2ca2808ce901fdfc1eda31bcb488156d0
baseline version:
 linux                08b022a9655bf925e6683422590306429b752ccd

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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                                     broken  
 test-amd64-i386-libvirt                                      fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 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 Tue Dec 30 06:49:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 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 1Y5qbO-00011m-NT; Tue, 30 Dec 2014 06:48: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 1Y5qbN-00011h-Gi
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 06:48:21 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	BF/3B-09284-4BA42A45; Tue, 30 Dec 2014 06:48:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1419922098!16336223!1
X-Originating-IP: [66.165.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); 30 Dec 2014 06:48:19 -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;
	30 Dec 2014 06:48:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,664,1413244800"; d="scan'208";a="209736127"
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.210.2; Tue, 30 Dec 2014 01:48: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 1Y5qbG-0004mX-AS;
	Tue, 30 Dec 2014 06:48:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5qbG-00060e-4p;
	Tue, 30 Dec 2014 06:48:14 +0000
Date: Tue, 30 Dec 2014 06:48:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32843-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] 32843: 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 32843 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32843/

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. 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)               blocked  n/a
 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-pvh-amd   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
 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-amd64-xl           1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  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-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-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-freebsd10-i386  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-winxpsp3  1 build-check(1)               blocked  n/a
 build-amd64-libvirt           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-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-qemut-winxpsp3-vcpus1  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-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-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  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-winxpsp3  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-i386-xl-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-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-pair          1 build-check(1)               blocked  n/a

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-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

broken-step build-amd64 host-install(3)

Not pushing.

(No revision log; it would be 912 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 Dec 30 06:49:00 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 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 1Y5qbO-00011m-NT; Tue, 30 Dec 2014 06:48: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 1Y5qbN-00011h-Gi
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 06:48:21 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	BF/3B-09284-4BA42A45; Tue, 30 Dec 2014 06:48:20 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-10.tower-31.messagelabs.com!1419922098!16336223!1
X-Originating-IP: [66.165.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); 30 Dec 2014 06:48:19 -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;
	30 Dec 2014 06:48:19 -0000
X-IronPort-AV: E=Sophos;i="5.07,664,1413244800"; d="scan'208";a="209736127"
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.210.2; Tue, 30 Dec 2014 01:48: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 1Y5qbG-0004mX-AS;
	Tue, 30 Dec 2014 06:48:14 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5qbG-00060e-4p;
	Tue, 30 Dec 2014 06:48:14 +0000
Date: Tue, 30 Dec 2014 06:48:14 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32843-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] 32843: 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 32843 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32843/

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. 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)               blocked  n/a
 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-pvh-amd   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
 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-amd64-xl           1 build-check(1)               blocked  n/a
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)             blocked n/a
 test-amd64-i386-xl            1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-multivcpu  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-amd64-xl-sedf-pin  1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)              blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-sedf      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-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-freebsd10-i386  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-winxpsp3  1 build-check(1)               blocked  n/a
 build-amd64-libvirt           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-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-qemut-winxpsp3-vcpus1  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-i386-rhel6hvm-intel  1 build-check(1)               blocked  n/a
 test-amd64-amd64-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  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-winxpsp3  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-i386-xl-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-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-pair          1 build-check(1)               blocked  n/a

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Peter Maydell <peter.maydell@linaro.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-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

broken-step build-amd64 host-install(3)

Not pushing.

(No revision log; it would be 912 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 Dec 30 07:53:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 07:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5rbV-0002DB-2q; Tue, 30 Dec 2014 07:52: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 1Y5rbT-0002D6-L9
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 07:52:31 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	EF/08-02743-EB952A45; Tue, 30 Dec 2014 07:52:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419925948!17746677!1
X-Originating-IP: [66.165.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 30415 invoked from network); 30 Dec 2014 07:52:29 -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;
	30 Dec 2014 07:52:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,664,1413244800"; d="scan'208";a="209753706"
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.210.2; Tue, 30 Dec 2014 02:52: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 1Y5rbP-00055V-6Q;
	Tue, 30 Dec 2014 07:52:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5rbP-00039G-16;
	Tue, 30 Dec 2014 07:52:27 +0000
Date: Tue, 30 Dec 2014 07:52:27 +0000
Message-ID: <E1Y5rbP-00039G-16@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] [qemu-mainline bisection] complete
	test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl-win7-amd64
test windows-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-amd64-xl-win7-amd64.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32689 fail [host=rice-weevil] / 32598 ok.
Failure / basis pass flights: 32689 / 32598
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#83a926f7a4e39fb6be0576024e67fe161593defa-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#7e58e2ac7778cca3234c33387e49577bb7732714-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 1005 nodes in revision graph
Searching for test results:
 32585 pass irrelevant
 32598 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32689 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32855 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32835 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32836 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32847 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32841 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32837 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 12d027f132246826c4358f3734d738a3385bf75f 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32838 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 af7c9f34b1bacd329a479e79bd608580d0511596 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32846 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32852 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32839 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32853 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 32598 (pass), for basis pass
 Result found: flight 32611 (fail), for basis failure
 Repro found: flight 32835 (pass), for basis pass
 Repro found: flight 32836 (fail), for basis failure
 0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32841 (pass), for last pass
 Result found: flight 32846 (fail), for first failure
 Repro found: flight 32847 (pass), for last pass
 Repro found: flight 32852 (fail), for first failure
 Repro found: flight 32853 (pass), for last pass
 Repro found: flight 32855 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-amd64-xl-win7-amd64.windows-install.{dot,ps,png,html}.
----------------------------------------
32855: tolerable ALL FAIL

flight 32855 qemu-mainline real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32855/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested


jobs:
 test-amd64-amd64-xl-win7-amd64                               fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 30 07:53:07 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 07:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5rbV-0002DB-2q; Tue, 30 Dec 2014 07:52: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 1Y5rbT-0002D6-L9
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 07:52:31 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	EF/08-02743-EB952A45; Tue, 30 Dec 2014 07:52:30 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1419925948!17746677!1
X-Originating-IP: [66.165.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 30415 invoked from network); 30 Dec 2014 07:52:29 -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;
	30 Dec 2014 07:52:29 -0000
X-IronPort-AV: E=Sophos;i="5.07,664,1413244800"; d="scan'208";a="209753706"
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.210.2; Tue, 30 Dec 2014 02:52: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 1Y5rbP-00055V-6Q;
	Tue, 30 Dec 2014 07:52:27 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5rbP-00039G-16;
	Tue, 30 Dec 2014 07:52:27 +0000
Date: Tue, 30 Dec 2014 07:52:27 +0000
Message-ID: <E1Y5rbP-00039G-16@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] [qemu-mainline bisection] complete
	test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl-win7-amd64
test windows-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-amd64-xl-win7-amd64.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32689 fail [host=rice-weevil] / 32598 ok.
Failure / basis pass flights: 32689 / 32598
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#83a926f7a4e39fb6be0576024e67fe161593defa-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#7e58e2ac7778cca3234c33387e49577bb7732714-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 1005 nodes in revision graph
Searching for test results:
 32585 pass irrelevant
 32598 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32689 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32855 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32835 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32836 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32847 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32841 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32837 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 12d027f132246826c4358f3734d738a3385bf75f 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32838 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 af7c9f34b1bacd329a479e79bd608580d0511596 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32846 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32852 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32839 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32853 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 32598 (pass), for basis pass
 Result found: flight 32611 (fail), for basis failure
 Repro found: flight 32835 (pass), for basis pass
 Repro found: flight 32836 (fail), for basis failure
 0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32841 (pass), for last pass
 Result found: flight 32846 (fail), for first failure
 Repro found: flight 32847 (pass), for last pass
 Repro found: flight 32852 (fail), for first failure
 Repro found: flight 32853 (pass), for last pass
 Repro found: flight 32855 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-amd64-xl-win7-amd64.windows-install.{dot,ps,png,html}.
----------------------------------------
32855: tolerable ALL FAIL

flight 32855 qemu-mainline real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32855/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested


jobs:
 test-amd64-amd64-xl-win7-amd64                               fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 30 09:06:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 09: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 1Y5skp-0003mT-2R; Tue, 30 Dec 2014 09:06:15 +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 1Y5skm-0003mO-Qd
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 09:06:13 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	85/7C-09842-40B62A45; Tue, 30 Dec 2014 09:06:12 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-8.tower-21.messagelabs.com!1419930371!18442792!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6402 invoked from network); 30 Dec 2014 09:06:11 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Dec 2014 09:06:11 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so20502009wgg.33
	for <xen-devel@lists.xensource.com>;
	Tue, 30 Dec 2014 01:06: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=PNelvZTf8wd0PDTGD1/xiOuoDAiAS8jCASPorC07OfM=;
	b=GkIwe0SML68pWJ9tZftuqSxB8BjkiZz5c1O3m9NUXugKTyNgepu8Zv7fqTtmjCXy7i
	l1AATPPspYG8BfkEeyAFUilhhNlTNDYBvzvTBAmr72aSnfIIFA701cTiraySPM7B7ue5
	rP7ZL4ij0Xl5AoiQkpIf/s1wa9Agcm/nC6/CVurTw3UxayLOkapgSdWWAr8VAFCdOi+o
	O6Omz3+qA58uZKwugnodTTaKhcS2NJBMBv1Tax25j7nn/ZTlhf+Onuus4++W0702CFsO
	3/roJFo0HnR8rFW/m5o1QV2V8grSczw0A+nYB886Sv4mkJrQUz+/TGA4+LTsN0ZtOfo/
	khYA==
X-Gm-Message-State: ALoCoQkwzFcdJYz4u2/rqX0KmQPXXTClb+fe78s6CDWzNJRbMOjh0y/ay/AW5yaHmwFDYJDK6069
X-Received: by 10.180.95.136 with SMTP id dk8mr85120169wib.64.1419930370736;
	Tue, 30 Dec 2014 01:06: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 b10sm6591676wjr.32.2014.12.30.01.06.08
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 30 Dec 2014 01:06:10 -0800 (PST)
Message-ID: <54A26B01.3000302@m2r.biz>
Date: Tue, 30 Dec 2014 10:06:09 +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.3.0
MIME-Version: 1.0
To: "xen.org" <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com
References: <E1Y5rbP-00039G-16@osstest.cam.xci-test.com>
In-Reply-To: <E1Y5rbP-00039G-16@osstest.cam.xci-test.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, keir@xen.org, marcel.a@redhat.com,
	stefano.stabellini@eu.citrix.com,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [qemu-mainline bisection] complete
	test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 30/12/2014 08:52, xen.org ha scritto:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-xl-win7-amd64
> test windows-install
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://git.qemu.org/qemu.git
> Tree: xen git://xenbits.xen.org/xen.git
>
> *** Found and reproduced problem changeset ***
>
>    Bug is in tree:  qemuu git://git.qemu.org/qemu.git
>    Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
>    Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a
>
>
>    commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
>    Author: Marcel Apfelbaum <marcel.a@redhat.com>
>    Date:   Tue Dec 16 16:58:05 2014 +0000
>    
>        machine: remove qemu_machine_opts global list
>        
>        QEMU has support for options per machine, keeping
>        a global list of options is no longer necessary.
>        
>        Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
>        Reviewed-by: Alexander Graf <agraf@suse.de>
>        Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
>        Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
>        Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

In the automatic test the qemu log contain:
> qemu-system-i386: util/qemu-option.c:387: qemu_opt_get_bool_helper: Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed.
Is there unexpected case in the qemu patch spotted by bisection or qemu 
parameters in libxl need improvements (probably machinearg cases in 
libxl_dm.c)?

Thanks for any reply and sorry for my bad english.

>
>
> For bisection revision-tuple graph see:
>     http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-amd64-xl-win7-amd64.windows-install.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
>
> ----------------------------------------
> Searching for failure / basis pass:
>   32689 fail [host=rice-weevil] / 32598 ok.
> Failure / basis pass flights: 32689 / 32598
> (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://git.qemu.org/qemu.git
> Tree: xen git://xenbits.xen.org/xen.git
> Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
> Basis pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
> Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#83a926f7a4e39fb6be0576024e67fe161593defa-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#7e58e2ac7778cca3234c33387e49577bb7732714-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-36174af3fbeb1b662c0eadbfa193e77f68cc955b
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/qemu
> + git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/qemu
> + git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> Loaded 1005 nodes in revision graph
> Searching for test results:
>   32585 pass irrelevant
>   32598 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32689 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32855 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32835 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32836 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32847 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32841 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32837 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 12d027f132246826c4358f3734d738a3385bf75f 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32838 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 af7c9f34b1bacd329a479e79bd608580d0511596 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32846 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32852 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32839 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32853 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
> Searching for interesting versions
>   Result found: flight 32598 (pass), for basis pass
>   Result found: flight 32611 (fail), for basis failure
>   Repro found: flight 32835 (pass), for basis pass
>   Repro found: flight 32836 (fail), for basis failure
>   0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
> No revisions left to test, checking graph state.
>   Result found: flight 32841 (pass), for last pass
>   Result found: flight 32846 (fail), for first failure
>   Repro found: flight 32847 (pass), for last pass
>   Repro found: flight 32852 (fail), for first failure
>   Repro found: flight 32853 (pass), for last pass
>   Repro found: flight 32855 (fail), for first failure
>
> *** Found and reproduced problem changeset ***
>
>    Bug is in tree:  qemuu git://git.qemu.org/qemu.git
>    Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
>    Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a
>
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/qemu
> + git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
>
>    commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
>    Author: Marcel Apfelbaum <marcel.a@redhat.com>
>    Date:   Tue Dec 16 16:58:05 2014 +0000
>    
>        machine: remove qemu_machine_opts global list
>        
>        QEMU has support for options per machine, keeping
>        a global list of options is no longer necessary.
>        
>        Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
>        Reviewed-by: Alexander Graf <agraf@suse.de>
>        Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
>        Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
>        Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>
> Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-amd64-xl-win7-amd64.windows-install.{dot,ps,png,html}.
> ----------------------------------------
> 32855: tolerable ALL FAIL
>
> flight 32855 qemu-mainline real-bisect [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32855/
>
> Failures :-/ but no regressions.
>
> Tests which did not succeed,
> including tests which could not be run:
>   test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested
>
>
> jobs:
>   test-amd64-amd64-xl-win7-amd64                               fail
>
>
> ------------------------------------------------------------
> sg-report-flight on osstest.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
>
> Logs, config files, etc. are available at
>      http://www.chiark.greenend.org.uk/~xensrcts/logs
>
> Test harness code can be found at
>      http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 30 09:06:51 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 09: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 1Y5skp-0003mT-2R; Tue, 30 Dec 2014 09:06:15 +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 1Y5skm-0003mO-Qd
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 09:06:13 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	85/7C-09842-40B62A45; Tue, 30 Dec 2014 09:06:12 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-8.tower-21.messagelabs.com!1419930371!18442792!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6402 invoked from network); 30 Dec 2014 09:06:11 -0000
Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com)
	(74.125.82.46)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Dec 2014 09:06:11 -0000
Received: by mail-wg0-f46.google.com with SMTP id x13so20502009wgg.33
	for <xen-devel@lists.xensource.com>;
	Tue, 30 Dec 2014 01:06: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=PNelvZTf8wd0PDTGD1/xiOuoDAiAS8jCASPorC07OfM=;
	b=GkIwe0SML68pWJ9tZftuqSxB8BjkiZz5c1O3m9NUXugKTyNgepu8Zv7fqTtmjCXy7i
	l1AATPPspYG8BfkEeyAFUilhhNlTNDYBvzvTBAmr72aSnfIIFA701cTiraySPM7B7ue5
	rP7ZL4ij0Xl5AoiQkpIf/s1wa9Agcm/nC6/CVurTw3UxayLOkapgSdWWAr8VAFCdOi+o
	O6Omz3+qA58uZKwugnodTTaKhcS2NJBMBv1Tax25j7nn/ZTlhf+Onuus4++W0702CFsO
	3/roJFo0HnR8rFW/m5o1QV2V8grSczw0A+nYB886Sv4mkJrQUz+/TGA4+LTsN0ZtOfo/
	khYA==
X-Gm-Message-State: ALoCoQkwzFcdJYz4u2/rqX0KmQPXXTClb+fe78s6CDWzNJRbMOjh0y/ay/AW5yaHmwFDYJDK6069
X-Received: by 10.180.95.136 with SMTP id dk8mr85120169wib.64.1419930370736;
	Tue, 30 Dec 2014 01:06: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 b10sm6591676wjr.32.2014.12.30.01.06.08
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 30 Dec 2014 01:06:10 -0800 (PST)
Message-ID: <54A26B01.3000302@m2r.biz>
Date: Tue, 30 Dec 2014 10:06:09 +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.3.0
MIME-Version: 1.0
To: "xen.org" <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com
References: <E1Y5rbP-00039G-16@osstest.cam.xci-test.com>
In-Reply-To: <E1Y5rbP-00039G-16@osstest.cam.xci-test.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, keir@xen.org, marcel.a@redhat.com,
	stefano.stabellini@eu.citrix.com,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [qemu-mainline bisection] complete
	test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 30/12/2014 08:52, xen.org ha scritto:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-xl-win7-amd64
> test windows-install
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://git.qemu.org/qemu.git
> Tree: xen git://xenbits.xen.org/xen.git
>
> *** Found and reproduced problem changeset ***
>
>    Bug is in tree:  qemuu git://git.qemu.org/qemu.git
>    Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
>    Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a
>
>
>    commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
>    Author: Marcel Apfelbaum <marcel.a@redhat.com>
>    Date:   Tue Dec 16 16:58:05 2014 +0000
>    
>        machine: remove qemu_machine_opts global list
>        
>        QEMU has support for options per machine, keeping
>        a global list of options is no longer necessary.
>        
>        Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
>        Reviewed-by: Alexander Graf <agraf@suse.de>
>        Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
>        Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
>        Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

In the automatic test the qemu log contain:
> qemu-system-i386: util/qemu-option.c:387: qemu_opt_get_bool_helper: Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed.
Is there unexpected case in the qemu patch spotted by bisection or qemu 
parameters in libxl need improvements (probably machinearg cases in 
libxl_dm.c)?

Thanks for any reply and sorry for my bad english.

>
>
> For bisection revision-tuple graph see:
>     http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-amd64-xl-win7-amd64.windows-install.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
>
> ----------------------------------------
> Searching for failure / basis pass:
>   32689 fail [host=rice-weevil] / 32598 ok.
> Failure / basis pass flights: 32689 / 32598
> (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://git.qemu.org/qemu.git
> Tree: xen git://xenbits.xen.org/xen.git
> Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
> Basis pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
> Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#83a926f7a4e39fb6be0576024e67fe161593defa-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#7e58e2ac7778cca3234c33387e49577bb7732714-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-36174af3fbeb1b662c0eadbfa193e77f68cc955b
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/qemu
> + git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/qemu
> + git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> Loaded 1005 nodes in revision graph
> Searching for test results:
>   32585 pass irrelevant
>   32598 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32689 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32855 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32835 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32836 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32847 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32841 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32837 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 12d027f132246826c4358f3734d738a3385bf75f 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32838 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 af7c9f34b1bacd329a479e79bd608580d0511596 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32846 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32852 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32839 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
>   32853 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
> Searching for interesting versions
>   Result found: flight 32598 (pass), for basis pass
>   Result found: flight 32611 (fail), for basis failure
>   Repro found: flight 32835 (pass), for basis pass
>   Repro found: flight 32836 (fail), for basis failure
>   0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
> No revisions left to test, checking graph state.
>   Result found: flight 32841 (pass), for last pass
>   Result found: flight 32846 (fail), for first failure
>   Repro found: flight 32847 (pass), for last pass
>   Repro found: flight 32852 (fail), for first failure
>   Repro found: flight 32853 (pass), for last pass
>   Repro found: flight 32855 (fail), for first failure
>
> *** Found and reproduced problem changeset ***
>
>    Bug is in tree:  qemuu git://git.qemu.org/qemu.git
>    Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
>    Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a
>
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/qemu
> + git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
>
>    commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
>    Author: Marcel Apfelbaum <marcel.a@redhat.com>
>    Date:   Tue Dec 16 16:58:05 2014 +0000
>    
>        machine: remove qemu_machine_opts global list
>        
>        QEMU has support for options per machine, keeping
>        a global list of options is no longer necessary.
>        
>        Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
>        Reviewed-by: Alexander Graf <agraf@suse.de>
>        Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
>        Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
>        Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>
> Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-amd64-xl-win7-amd64.windows-install.{dot,ps,png,html}.
> ----------------------------------------
> 32855: tolerable ALL FAIL
>
> flight 32855 qemu-mainline real-bisect [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/32855/
>
> Failures :-/ but no regressions.
>
> Tests which did not succeed,
> including tests which could not be run:
>   test-amd64-amd64-xl-win7-amd64  7 windows-install       fail baseline untested
>
>
> jobs:
>   test-amd64-amd64-xl-win7-amd64                               fail
>
>
> ------------------------------------------------------------
> sg-report-flight on osstest.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
>
> Logs, config files, etc. are available at
>      http://www.chiark.greenend.org.uk/~xensrcts/logs
>
> Test harness code can be found at
>      http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 30 09:40:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 09:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5tHz-0004Ih-4w; Tue, 30 Dec 2014 09:40:31 +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 1Y5tHy-0004Ic-2N
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 09:40:30 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	37/65-02957-D0372A45; Tue, 30 Dec 2014 09:40:29 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1419932428!17770355!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=BIZ_TLD,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7483 invoked from network); 30 Dec 2014 09:40:28 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Dec 2014 09:40:28 -0000
Received: by mail-lb0-f173.google.com with SMTP id z12so11863642lbi.4
	for <xen-devel@lists.xensource.com>;
	Tue, 30 Dec 2014 01:40: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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=cGMfdx4HC+GHftJIkdH3x0KLdx8TVlNXJVIeHClH+gY=;
	b=gJQb2BDXX7FDhw55YrjwmVBBdqanh8mKuGgFG77fvCWa4s8tcxh/oyRl+d3Es/FGh2
	w59RvkeNaS/c27qB5O3jrXMglqvL6vcwv4X+mi9iE7s5+gKhA0aMXjXA5G24p1RPBBu4
	zKlIIPxwjLYeSe90Mu6qj86xouKCyH7Y7I8iSd7mEv5DNKehR6WHvioFG0wbJ5VCeLCR
	JRO/I9iPekYWq2EqHgajswd3qEiP+UiXdo3woq1lQUnNyYMtYSKuanVgYwzhYUTLbMTj
	ZLb7lg9w2yaMKopto+ZD2w5pvC40pySDlCipI2DV/BNCsSf++Wx5OEi/pxWrBa5UEbrE
	p3qQ==
X-Gm-Message-State: ALoCoQm/5POw26p63bdMPvpW2nHUcycD0fXcb01vtJn72Zx9Jy7Lify/4g6qjvvs3D1s8E032qyb
X-Received: by 10.152.6.67 with SMTP id y3mr60821345lay.90.1419932428122; Tue,
	30 Dec 2014 01:40:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.52.38 with HTTP; Tue, 30 Dec 2014 01:40:07 -0800 (PST)
In-Reply-To: <54A26B01.3000302@m2r.biz>
References: <E1Y5rbP-00039G-16@osstest.cam.xci-test.com>
	<54A26B01.3000302@m2r.biz>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Tue, 30 Dec 2014 09:40:07 +0000
Message-ID: <CAFEAcA9XMO-yRr6koV4ny3e9CjvHFk-QTFOOmdVhUxy5nzQN8g@mail.gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Cc: "xen-devel@lists.xensource.com Devel" <xen-devel@lists.xensource.com>,
	keir@xen.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Marcel Apfelbaum <marcel.a@redhat.com>,
	"xen.org" <Ian.Jackson@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [qemu-mainline bisection] complete
	test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30 December 2014 at 09:06, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
> In the automatic test the qemu log contain:
>>
>> qemu-system-i386: util/qemu-option.c:387: qemu_opt_get_bool_helper:
>> Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed.
>
> Is there unexpected case in the qemu patch spotted by bisection or qemu
> parameters in libxl need improvements (probably machinearg cases in
> libxl_dm.c)?

Known issue (though we don't have a fix yet). See the qemu-devel thread
"'-usb' regressed by 49d2e648 ("machine: remove qemu_machine_opts
global list")".

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 Dec 30 09:40:54 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 09:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5tHz-0004Ih-4w; Tue, 30 Dec 2014 09:40:31 +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 1Y5tHy-0004Ic-2N
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 09:40:30 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	37/65-02957-D0372A45; Tue, 30 Dec 2014 09:40:29 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1419932428!17770355!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=BIZ_TLD,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7483 invoked from network); 30 Dec 2014 09:40:28 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Dec 2014 09:40:28 -0000
Received: by mail-lb0-f173.google.com with SMTP id z12so11863642lbi.4
	for <xen-devel@lists.xensource.com>;
	Tue, 30 Dec 2014 01:40: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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=cGMfdx4HC+GHftJIkdH3x0KLdx8TVlNXJVIeHClH+gY=;
	b=gJQb2BDXX7FDhw55YrjwmVBBdqanh8mKuGgFG77fvCWa4s8tcxh/oyRl+d3Es/FGh2
	w59RvkeNaS/c27qB5O3jrXMglqvL6vcwv4X+mi9iE7s5+gKhA0aMXjXA5G24p1RPBBu4
	zKlIIPxwjLYeSe90Mu6qj86xouKCyH7Y7I8iSd7mEv5DNKehR6WHvioFG0wbJ5VCeLCR
	JRO/I9iPekYWq2EqHgajswd3qEiP+UiXdo3woq1lQUnNyYMtYSKuanVgYwzhYUTLbMTj
	ZLb7lg9w2yaMKopto+ZD2w5pvC40pySDlCipI2DV/BNCsSf++Wx5OEi/pxWrBa5UEbrE
	p3qQ==
X-Gm-Message-State: ALoCoQm/5POw26p63bdMPvpW2nHUcycD0fXcb01vtJn72Zx9Jy7Lify/4g6qjvvs3D1s8E032qyb
X-Received: by 10.152.6.67 with SMTP id y3mr60821345lay.90.1419932428122; Tue,
	30 Dec 2014 01:40:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.52.38 with HTTP; Tue, 30 Dec 2014 01:40:07 -0800 (PST)
In-Reply-To: <54A26B01.3000302@m2r.biz>
References: <E1Y5rbP-00039G-16@osstest.cam.xci-test.com>
	<54A26B01.3000302@m2r.biz>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Tue, 30 Dec 2014 09:40:07 +0000
Message-ID: <CAFEAcA9XMO-yRr6koV4ny3e9CjvHFk-QTFOOmdVhUxy5nzQN8g@mail.gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Cc: "xen-devel@lists.xensource.com Devel" <xen-devel@lists.xensource.com>,
	keir@xen.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Marcel Apfelbaum <marcel.a@redhat.com>,
	"xen.org" <Ian.Jackson@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [qemu-mainline bisection] complete
	test-amd64-amd64-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30 December 2014 at 09:06, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
> In the automatic test the qemu log contain:
>>
>> qemu-system-i386: util/qemu-option.c:387: qemu_opt_get_bool_helper:
>> Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed.
>
> Is there unexpected case in the qemu patch spotted by bisection or qemu
> parameters in libxl need improvements (probably machinearg cases in
> libxl_dm.c)?

Known issue (though we don't have a fix yet). See the qemu-devel thread
"'-usb' regressed by 49d2e648 ("machine: remove qemu_machine_opts
global list")".

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 Dec 30 10:07:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 10: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 1Y5tho-0004sL-H1; Tue, 30 Dec 2014 10:07:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y5thm-0004sG-KS
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 10:07:10 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	3B/9C-27623-D4972A45; Tue, 30 Dec 2014 10:07:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419934027!16416111!1
X-Originating-IP: [66.165.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 6193 invoked from network); 30 Dec 2014 10:07:08 -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;
	30 Dec 2014 10:07:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,665,1413244800"; d="scan'208";a="209221163"
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.210.2; Tue, 30 Dec 2014 05:07: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 1Y5thh-0005jJ-RK;
	Tue, 30 Dec 2014 10:07:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5thh-0001cw-M5;
	Tue, 30 Dec 2014 10:07:05 +0000
Date: Tue, 30 Dec 2014 10:07:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32830-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] 32830: 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 32830 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32830/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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

version targeted for testing:
 seabios              2c9870f9f55d9c1ecddf50eb26b777f0cea06313
baseline version:
 seabios              64b76149765341168b4c073211f7b17a0f54f444

------------------------------------------------------------
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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=2c9870f9f55d9c1ecddf50eb26b777f0cea06313
+ . 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 2c9870f9f55d9c1ecddf50eb26b777f0cea06313
+ branch=seabios
+ revision=2c9870f9f55d9c1ecddf50eb26b777f0cea06313
+ . 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 2c9870f9f55d9c1ecddf50eb26b777f0cea06313:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   64b7614..2c9870f  2c9870f9f55d9c1ecddf50eb26b777f0cea06313 -> 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 Dec 30 10:07:44 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 10: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 1Y5tho-0004sL-H1; Tue, 30 Dec 2014 10:07:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y5thm-0004sG-KS
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 10:07:10 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	3B/9C-27623-D4972A45; Tue, 30 Dec 2014 10:07:09 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419934027!16416111!1
X-Originating-IP: [66.165.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 6193 invoked from network); 30 Dec 2014 10:07:08 -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;
	30 Dec 2014 10:07:08 -0000
X-IronPort-AV: E=Sophos;i="5.07,665,1413244800"; d="scan'208";a="209221163"
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.210.2; Tue, 30 Dec 2014 05:07: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 1Y5thh-0005jJ-RK;
	Tue, 30 Dec 2014 10:07:05 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5thh-0001cw-M5;
	Tue, 30 Dec 2014 10:07:05 +0000
Date: Tue, 30 Dec 2014 10:07:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32830-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] 32830: 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 32830 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32830/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-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-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-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

version targeted for testing:
 seabios              2c9870f9f55d9c1ecddf50eb26b777f0cea06313
baseline version:
 seabios              64b76149765341168b4c073211f7b17a0f54f444

------------------------------------------------------------
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-amd64-xl-pvh-amd                                  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-amd64-xl-pvh-intel                                fail    
 test-amd64-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-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.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=2c9870f9f55d9c1ecddf50eb26b777f0cea06313
+ . 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 2c9870f9f55d9c1ecddf50eb26b777f0cea06313
+ branch=seabios
+ revision=2c9870f9f55d9c1ecddf50eb26b777f0cea06313
+ . 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 2c9870f9f55d9c1ecddf50eb26b777f0cea06313:refs/heads/xen-tested-master
To osstest@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
   64b7614..2c9870f  2c9870f9f55d9c1ecddf50eb26b777f0cea06313 -> 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 Dec 30 16:06:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 16:06:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5zJ1-0002SN-4n; Tue, 30 Dec 2014 16:05: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 1Y5zIz-0002SI-Dg
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 16:05:57 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	26/D5-25547-46DC2A45; Tue, 30 Dec 2014 16:05:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419955554!16483422!1
X-Originating-IP: [66.165.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 16651 invoked from network); 30 Dec 2014 16:05:55 -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;
	30 Dec 2014 16:05:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,666,1413244800"; d="scan'208";a="209313755"
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.210.2; Tue, 30 Dec 2014 11:05: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 1Y5zIZ-0007Ra-3F;
	Tue, 30 Dec 2014 16:05:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5zIY-0000Mj-TO;
	Tue, 30 Dec 2014 16:05:30 +0000
Date: Tue, 30 Dec 2014 16:05:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32834-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] 32834: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32834 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32834/

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  5 xen-boot    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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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 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-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 14 guest-stop                fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                    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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 30 16:06:35 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 16:06:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y5zJ1-0002SN-4n; Tue, 30 Dec 2014 16:05: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 1Y5zIz-0002SI-Dg
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 16:05:57 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	26/D5-25547-46DC2A45; Tue, 30 Dec 2014 16:05:56 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-5.tower-31.messagelabs.com!1419955554!16483422!1
X-Originating-IP: [66.165.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 16651 invoked from network); 30 Dec 2014 16:05:55 -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;
	30 Dec 2014 16:05:55 -0000
X-IronPort-AV: E=Sophos;i="5.07,666,1413244800"; d="scan'208";a="209313755"
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.210.2; Tue, 30 Dec 2014 11:05: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 1Y5zIZ-0007Ra-3F;
	Tue, 30 Dec 2014 16:05:31 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y5zIY-0000Mj-TO;
	Tue, 30 Dec 2014 16:05:30 +0000
Date: Tue, 30 Dec 2014 16:05:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32834-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] 32834: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32834 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32834/

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  5 xen-boot    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-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     fail   never pass
 test-amd64-i386-xl-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-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-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 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-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 14 guest-stop                fail never pass

version targeted for testing:
 linux                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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                    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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 30 17:19:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 17:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y60S7-0003cj-4T; Tue, 30 Dec 2014 17:19: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 1Y60S6-0003ce-E6
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 17:19:26 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B0/35-25276-D9ED2A45; Tue, 30 Dec 2014 17:19:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1419959963!18498191!1
X-Originating-IP: [66.165.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 1821 invoked from network); 30 Dec 2014 17:19: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;
	30 Dec 2014 17:19:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,666,1413244800"; d="scan'208";a="209907809"
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.210.2; Tue, 30 Dec 2014 12:19: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 1Y60S2-0007nT-76;
	Tue, 30 Dec 2014 17:19:22 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y60S2-0001Xl-0H;
	Tue, 30 Dec 2014 17:19:22 +0000
Date: Tue, 30 Dec 2014 17:19:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32844-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] 32844: 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 32844 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32844/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rumpuserxen-i386  3 host-install(3)       broken pass in 32806
 test-amd64-i386-xl-win7-amd64  5 xen-boot                   fail pass in 32806
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 32806
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail in 32806 pass in 32844

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32806
 test-armhf-armhf-xl          15 capture-logs(15)    broken in 32806 like 32758
 test-armhf-armhf-libvirt     10 capture-logs(10)    broken in 32806 like 32758

Tests which did not succeed, but are not blocking:
 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-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       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-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-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-qemut-winxpsp3 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-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 32806 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 32806 never pass

version targeted for testing:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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-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                             broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-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-rumpuserxen-i386 host-install(3)

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 Dec 30 17:19:58 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 17:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y60S7-0003cj-4T; Tue, 30 Dec 2014 17:19: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 1Y60S6-0003ce-E6
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 17:19:26 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B0/35-25276-D9ED2A45; Tue, 30 Dec 2014 17:19:25 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1419959963!18498191!1
X-Originating-IP: [66.165.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 1821 invoked from network); 30 Dec 2014 17:19: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;
	30 Dec 2014 17:19:25 -0000
X-IronPort-AV: E=Sophos;i="5.07,666,1413244800"; d="scan'208";a="209907809"
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.210.2; Tue, 30 Dec 2014 12:19: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 1Y60S2-0007nT-76;
	Tue, 30 Dec 2014 17:19:22 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y60S2-0001Xl-0H;
	Tue, 30 Dec 2014 17:19:22 +0000
Date: Tue, 30 Dec 2014 17:19:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32844-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] 32844: 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 32844 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32844/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rumpuserxen-i386  3 host-install(3)       broken pass in 32806
 test-amd64-i386-xl-win7-amd64  5 xen-boot                   fail pass in 32806
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 32806
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate/x10 fail in 32806 pass in 32844

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32806
 test-armhf-armhf-xl          15 capture-logs(15)    broken in 32806 like 32758
 test-armhf-armhf-libvirt     10 capture-logs(10)    broken in 32806 like 32758

Tests which did not succeed, but are not blocking:
 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-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       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-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-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-qemut-winxpsp3 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-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop           fail in 32806 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop    fail in 32806 never pass

version targeted for testing:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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-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                             broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-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-rumpuserxen-i386 host-install(3)

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 Dec 30 20:24:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 20:24:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y63KO-0006km-9K; Tue, 30 Dec 2014 20:23: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 1Y63KM-0006kh-0b
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 20:23:38 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	8E/CF-25727-9C903A45; Tue, 30 Dec 2014 20:23:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1419971014!14043298!1
X-Originating-IP: [66.165.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 4978 invoked from network); 30 Dec 2014 20:23:36 -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;
	30 Dec 2014 20:23:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,666,1413244800"; d="scan'208";a="209961628"
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.210.2; Tue, 30 Dec 2014 15:23: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 1Y63KH-0000EE-0p;
	Tue, 30 Dec 2014 20:23:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y63KG-0007cz-Qq;
	Tue, 30 Dec 2014 20:23:32 +0000
Date: Tue, 30 Dec 2014 20:23:32 +0000
Message-ID: <E1Y63KG-0007cz-Qq@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] [qemu-mainline bisection] complete
	test-amd64-i386-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-win7-amd64
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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-i386-xl-win7-amd64.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32689 fail [host=grain-weevil] / 32598 ok.
Failure / basis pass flights: 32689 / 32598
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#83a926f7a4e39fb6be0576024e67fe161593defa-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#7e58e2ac7778cca3234c33387e49577bb7732714-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 1005 nodes in revision graph
Searching for test results:
 32585 pass irrelevant
 32598 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32689 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32868 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32862 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 af7c9f34b1bacd329a479e79bd608580d0511596 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32860 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32865 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32864 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32861 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 12d027f132246826c4358f3734d738a3385bf75f 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32856 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32870 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32866 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32869 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32871 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 32598 (pass), for basis pass
 Result found: flight 32611 (fail), for basis failure
 Repro found: flight 32856 (pass), for basis pass
 Repro found: flight 32860 (fail), for basis failure
 0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32865 (pass), for last pass
 Result found: flight 32866 (fail), for first failure
 Repro found: flight 32868 (pass), for last pass
 Repro found: flight 32869 (fail), for first failure
 Repro found: flight 32870 (pass), for last pass
 Repro found: flight 32871 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-i386-xl-win7-amd64.windows-install.{dot,ps,png,html}.
----------------------------------------
32871: tolerable ALL FAIL

flight 32871 qemu-mainline real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32871/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-win7-amd64  7 windows-install        fail baseline untested


jobs:
 test-amd64-i386-xl-win7-amd64                                fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 30 20:24:15 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 20:24:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y63KO-0006km-9K; Tue, 30 Dec 2014 20:23: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 1Y63KM-0006kh-0b
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 20:23:38 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	8E/CF-25727-9C903A45; Tue, 30 Dec 2014 20:23:37 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1419971014!14043298!1
X-Originating-IP: [66.165.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 4978 invoked from network); 30 Dec 2014 20:23:36 -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;
	30 Dec 2014 20:23:36 -0000
X-IronPort-AV: E=Sophos;i="5.07,666,1413244800"; d="scan'208";a="209961628"
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.210.2; Tue, 30 Dec 2014 15:23: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 1Y63KH-0000EE-0p;
	Tue, 30 Dec 2014 20:23:33 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y63KG-0007cz-Qq;
	Tue, 30 Dec 2014 20:23:32 +0000
Date: Tue, 30 Dec 2014 20:23:32 +0000
Message-ID: <E1Y63KG-0007cz-Qq@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] [qemu-mainline bisection] complete
	test-amd64-i386-xl-win7-amd64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-win7-amd64
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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a


  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-i386-xl-win7-amd64.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 32689 fail [host=grain-weevil] / 32598 ok.
Failure / basis pass flights: 32689 / 32598
(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://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Basis pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#83a926f7a4e39fb6be0576024e67fe161593defa-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#7e58e2ac7778cca3234c33387e49577bb7732714-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-36174af3fbeb1b662c0eadbfa193e77f68cc955b
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 1005 nodes in revision graph
Searching for test results:
 32585 pass irrelevant
 32598 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32611 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32626 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32689 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32659 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32868 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32862 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 af7c9f34b1bacd329a479e79bd608580d0511596 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32860 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32865 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32864 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32861 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 12d027f132246826c4358f3734d738a3385bf75f 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32856 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 7e58e2ac7778cca3234c33387e49577bb7732714 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32870 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32866 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32869 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
 32871 fail 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Searching for interesting versions
 Result found: flight 32598 (pass), for basis pass
 Result found: flight 32611 (fail), for basis failure
 Repro found: flight 32856 (pass), for basis pass
 Repro found: flight 32860 (fail), for basis failure
 0 revisions at 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 60fb1a87b47b14e4ea67043aa56f353e77fbd70a 36174af3fbeb1b662c0eadbfa193e77f68cc955b
No revisions left to test, checking graph state.
 Result found: flight 32865 (pass), for last pass
 Result found: flight 32866 (fail), for first failure
 Repro found: flight 32868 (pass), for last pass
 Repro found: flight 32869 (fail), for first failure
 Repro found: flight 32870 (pass), for last pass
 Repro found: flight 32871 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
  Author: Marcel Apfelbaum <marcel.a@redhat.com>
  Date:   Tue Dec 16 16:58:05 2014 +0000
  
      machine: remove qemu_machine_opts global list
      
      QEMU has support for options per machine, keeping
      a global list of options is no longer necessary.
      
      Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
      Reviewed-by: Alexander Graf <agraf@suse.de>
      Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
      Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
      Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Revision graph left in /home/xc_osstest/results/bisect.qemu-mainline.test-amd64-i386-xl-win7-amd64.windows-install.{dot,ps,png,html}.
----------------------------------------
32871: tolerable ALL FAIL

flight 32871 qemu-mainline real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32871/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-win7-amd64  7 windows-install        fail baseline untested


jobs:
 test-amd64-i386-xl-win7-amd64                                fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Dec 30 23:56:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 23: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 1Y66dG-0001Nr-2y; Tue, 30 Dec 2014 23:55: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 1Y66dE-0001Nm-MP
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 23:55:20 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	AD/75-02743-76B33A45; Tue, 30 Dec 2014 23:55:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419983717!13150625!1
X-Originating-IP: [66.165.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 1847 invoked from network); 30 Dec 2014 23:55:18 -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;
	30 Dec 2014 23:55:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,668,1413244800"; d="scan'208";a="209443644"
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.210.2; Tue, 30 Dec 2014 18:55: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 1Y66d9-0001FL-Q1;
	Tue, 30 Dec 2014 23:55:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y66d9-0006jc-J3;
	Tue, 30 Dec 2014 23:55:15 +0000
Date: Tue, 30 Dec 2014 23:55:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32854-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] 32854: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32854 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32854/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                 fail pass in 32813
 test-armhf-armhf-xl          15 capture-logs(15) broken in 32813 pass in 32854
 test-armhf-armhf-libvirt     10 capture-logs(10) broken in 32813 pass in 32854
 test-amd64-amd64-libvirt      5 xen-boot           fail in 32813 pass in 32854

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-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-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 32813 never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 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 912 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 Dec 30 23:56:03 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Dec 2014 23: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 1Y66dG-0001Nr-2y; Tue, 30 Dec 2014 23:55: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 1Y66dE-0001Nm-MP
	for xen-devel@lists.xensource.com; Tue, 30 Dec 2014 23:55:20 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	AD/75-02743-76B33A45; Tue, 30 Dec 2014 23:55:19 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1419983717!13150625!1
X-Originating-IP: [66.165.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 1847 invoked from network); 30 Dec 2014 23:55:18 -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;
	30 Dec 2014 23:55:18 -0000
X-IronPort-AV: E=Sophos;i="5.07,668,1413244800"; d="scan'208";a="209443644"
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.210.2; Tue, 30 Dec 2014 18:55: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 1Y66d9-0001FL-Q1;
	Tue, 30 Dec 2014 23:55:15 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y66d9-0006jc-J3;
	Tue, 30 Dec 2014 23:55:15 +0000
Date: Tue, 30 Dec 2014 23:55:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32854-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] 32854: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32854 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32854/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                 fail pass in 32813
 test-armhf-armhf-xl          15 capture-logs(15) broken in 32813 pass in 32854
 test-armhf-armhf-libvirt     10 capture-logs(10) broken in 32813 pass in 32854
 test-amd64-amd64-libvirt      5 xen-boot           fail in 32813 pass in 32854

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-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-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-winxpsp3 14 guest-stop                fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 32813 never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 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 912 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 Dec 31 01:04:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 01:04:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y67i4-00073v-S5; Wed, 31 Dec 2014 01:04:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y67i3-00073l-4t
	for xen-devel@lists.xensource.com; Wed, 31 Dec 2014 01:04:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	CD/68-09842-69B43A45; Wed, 31 Dec 2014 01:04:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1419987860!18524633!1
X-Originating-IP: [66.165.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 14621 invoked from network); 31 Dec 2014 01:04:21 -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;
	31 Dec 2014 01:04:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,669,1413244800"; d="scan'208";a="210027300"
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.210.2; Tue, 30 Dec 2014 20:04: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 1Y67hy-0001b8-9o;
	Wed, 31 Dec 2014 01:04:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y67hw-0002Vp-Mz;
	Wed, 31 Dec 2014 01:04:17 +0000
Date: Wed, 31 Dec 2014 01:04:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32858-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] 32858: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32858 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32858/

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. 32674

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32674
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32674
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32674
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32674

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 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-pvh-amd   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-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-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-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-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                2fb8bdb2ca2808ce901fdfc1eda31bcb488156d0
baseline version:
 linux                08b022a9655bf925e6683422590306429b752ccd

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 31 01:04:50 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 01:04:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y67i4-00073v-S5; Wed, 31 Dec 2014 01:04:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y67i3-00073l-4t
	for xen-devel@lists.xensource.com; Wed, 31 Dec 2014 01:04:23 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	CD/68-09842-69B43A45; Wed, 31 Dec 2014 01:04:22 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1419987860!18524633!1
X-Originating-IP: [66.165.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 14621 invoked from network); 31 Dec 2014 01:04:21 -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;
	31 Dec 2014 01:04:21 -0000
X-IronPort-AV: E=Sophos;i="5.07,669,1413244800"; d="scan'208";a="210027300"
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.210.2; Tue, 30 Dec 2014 20:04: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 1Y67hy-0001b8-9o;
	Wed, 31 Dec 2014 01:04:18 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y67hw-0002Vp-Mz;
	Wed, 31 Dec 2014 01:04:17 +0000
Date: Wed, 31 Dec 2014 01:04:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32858-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] 32858: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32858 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32858/

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. 32674

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install             fail like 32674
 test-amd64-i386-freebsd10-i386  7 freebsd-install              fail like 32674
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32674
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail like 32674

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 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-pvh-amd   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-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-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-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-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                2fb8bdb2ca2808ce901fdfc1eda31bcb488156d0
baseline version:
 linux                08b022a9655bf925e6683422590306429b752ccd

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-amd64-xl-pvh-amd                                  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                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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


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 Dec 31 01:27:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 01:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y683a-0007cr-86; Wed, 31 Dec 2014 01:26:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y683X-0007cm-WF
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 01:26:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	45/DE-09842-BC053A45; Wed, 31 Dec 2014 01:26:35 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419989192!10527915!1
X-Originating-IP: [209.85.218.42]
X-SpamReason: No, hits=2.0 required=7.0 tests=BIZ_TLD,HTML_MESSAGE, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26167 invoked from network); 31 Dec 2014 01:26:32 -0000
Received: from mail-oi0-f42.google.com (HELO mail-oi0-f42.google.com)
	(209.85.218.42)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2014 01:26:32 -0000
Received: by mail-oi0-f42.google.com with SMTP id v63so34281595oia.1
	for <xen-devel@lists.xen.org>; Tue, 30 Dec 2014 17:26:31 -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/coHIrGtDvunwAscKcUJx2xHoWBEX/6g4ZIaZoMZlk=;
	b=bMOAwVixUXuyFCQR2JcUBgkvydwqySDNxDkkbE/dHSjHTNwwbfe1mtOJ1bNftuZ7X1
	T0e6r4NEE0ZsfBrBXjKHoSJwuXhcVUB2qjdDisQk/6wwWt+hdoCn5lwDFEhhgpogyZIk
	59E2YBegs5pKnkVxcdfM6q25VlQRLCBOCfoH88Wj2dYaxjKDg5vbtDQ3SRckTLvgnvT2
	D0spoem4wLpdsEHPfv7SwavfvQHMAnUhHe23zulC91KJyOaVQ10f9qkGWfDwbGGgqdLS
	zQ7/zxM0AEOn7i3ciT70xlK70pTzu8WlATnOlMIczO/DkS9cIgj7IGlANUrwqCHwHMWF
	5bcA==
MIME-Version: 1.0
X-Received: by 10.60.120.36 with SMTP id kz4mr22646194oeb.80.1419989191604;
	Tue, 30 Dec 2014 17:26:31 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Tue, 30 Dec 2014 17:26:31 -0800 (PST)
In-Reply-To: <54A15BFA.4050001@m2r.biz>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
	<549EBDCC.3090102@m2r.biz>
	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
	<CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>
	<CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>
	<CAE5x5YU8R9PibP-_xj+uYNc_rqOL0rnuHvVF5Ymz32RngDEgFw@mail.gmail.com>
	<CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com>
	<54A15BFA.4050001@m2r.biz>
Date: Wed, 31 Dec 2014 02:26:31 +0100
Message-ID: <CAE5x5YWRJaF1XZ0masWn0uotUQghW0irM=NmU9XB0Dc8_XUFJw@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Content-Type: multipart/mixed; boundary=047d7b33934159e146050b78ff5f
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--047d7b33934159e146050b78ff5f
Content-Type: multipart/alternative; boundary=047d7b33934159e141050b78ff5d

--047d7b33934159e141050b78ff5d
Content-Type: text/plain; charset=UTF-8

Ok Fabio, thanks to your configure, some bits of hacking the install part
and lots of advises/support/encouragements ;) from Mark Pryor I ended up
 installing 4.5RC4 with QXL support on Deb8 unstable.


So now what do you want me to test fabio?
I have win7 x64 / win 2k8R2 vms in test mode ready to install drvers.

the numerous troubles I went through are related in the IRCcopy attached.
I actually couldn't build rombios and used seabios provided by the system
-like you-
I should try to compile/find latest qxl now.

See you in 2K15.

greg B

2014-12-29 14:49 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:

>  Il 29/12/2014 14:13, Goonie Windy ha scritto:
>
>   ok, I'm trying to patch the files with yours,
>
>
>  I need to do it manually right?
>
> git apply is not working here.
>
>
> If the patch need a "refresh" the conflict should be solved manually.
> Taking the patch updated from here probably it can be applied to latest
> 4.5-rc:
> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>
>
>
>  regards
>
>  greg
>
> 2014-12-29 13:46 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>
>> There is an error in pageqs describing how to compile from sources as in
>> 4.5
>>
>> cat .config
>> PYTHON_PREFIX_ARG=--install-layout=deb
>>
>>
>> is in fact in .INSTALL
>>
>>
> If also you use debian you can use make debball that is better for
> install/remove easy and fast test build.
>
> And for example I use this configure options with xen 4.5:
> ./configure --prefix=/usr --disable-blktap1 --disable-qemu-traditional
> --disable-rombios --with-system-seabios=/usr/share/seabios/bios-256k.bin
> --with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir"
> --disable-blktap2
> I use wheezy building updated packages from sid: seabios 1.7.5-1, spice
> 0.12.5-1, spice-protocol 0.12.7-1 and usbredir 0.7-1.
> If you use jessie instead you have all packages updated.
>
> About python I'm using this workaround (before execute configure) even if
> probably is not the best:
> Config.mk
> -PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX)"
> +PYTHON_PREFIX_ARG ?=
>
>
>
>>
>> 2014-12-29 1:20 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>>
>>>  well figured out it is because you have to "enforce" locale:  export
>>> LC_ALL=en_US.utf-8 if keyboard mapping is else
>>>
>>> 2014-12-28 21:19 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>>>
>>>>  Trying to compile xen 4.5RC4 in order to test your patch I end up
>>>> with  these errors compiling the Seabios directories,
>>>>
>>>>  any idea?
>>>>
>>>>   Compiling to assembler out/src/asm-offsets.s
>>>>   Generating offset file out/asm-offsets.h
>>>>   Compiling (16bit) out/romlayout.o
>>>>   Building ld scripts
>>>> Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
>>>> Traceback (most recent call last):
>>>>   File "./scripts/layoutrom.py", line 709, in <module>
>>>>     main()
>>>>   File "./scripts/layoutrom.py", line 671, in main
>>>>     info16 = parseObjDump(infile16, '16')
>>>>   File "./scripts/layoutrom.py", line 586, in parseObjDump
>>>>     relocsection = sectionmap[sectionname]
>>>> KeyError:
>>>> '.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
>>>> Makefile:155: recipe for target 'out/romlayout16.lds' failed
>>>> make[6]: *** [out/romlayout16.lds] Error 1
>>>> make[6]: Leaving directory
>>>> '/home/goon/xen/tools/firmware/seabios-dir-remote'
>>>> /home/goon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for
>>>> target 'subdir-all-seabios-dir' failed
>>>>
>>>>
>>>>
>>>> 2014-12-27 17:35 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>>>>
>>>>>   Hello Fabio,
>>>>>
>>>>> Sure thing I will help debug the win7 and the win8 versions.
>>>>>  Where to start?
>>>>>
>>>>>  I'll try to see if I can patch with patch from
>>>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>>>> and if not will post result.
>>>>>
>>>>>
>>>>> best regards,
>>>>>
>>>>>
>>>>>  greg Bahde
>>>>>
>>>>> 2014-12-27 15:10 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:
>>>>>
>>>>>>
>>>>>> Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>>>>>
>>>>>>   I tried to install Qxl drivers under win7/win 2k8/win8.1
>>>>>> all       x64 versions, without any luck.
>>>>>>
>>>>>>
>>>>>> admin message is as follow:
>>>>>> Driver Management concluded the process to install driver
>>>>>> FileRepository\qxl.inf_amd64_
>>>>>> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
>>>>>> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
>>>>>> following status: 0xe000022d.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  Does
>>>>>> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>>>>>
>>>>>>  can it be installed on my xen stack?
>>>>>>
>>>>>>
>>>>>>  Yes but probably require a small refresh, I always posted the patch
>>>>>> based on updated xen-unstable.
>>>>>>
>>>>>> Here qxl patch refreshed for xen 4.5 if needed:
>>>>>>
>>>>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>>>>>
>>>>>> Here the latest spice guest tools for windows with qxl driver
>>>>>> included:
>>>>>>
>>>>>> http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>>>>>>
>>>>>> Windows >=8 and similar require a new qxl drivers, there are a beta
>>>>>> build but latest tried some months ago have serious bug and I not found
>>>>>> recent build full working on windows 8.
>>>>>>
>>>>>> On xen windows 7 domUs qxl works good except a problem after
>>>>>> save/restore and on linux domUs is not working, for now I not found exactly
>>>>>> cause and solution.
>>>>>> On mailing list up to 2 years ago you can find many my mails about.
>>>>>> Any help to test it is appreciated.
>>>>>>
>>>>>> Sorry for my bad english.
>>>>>>
>>>>>>
>>>>>> Also, can  I get invited at xendevel irc ?
>>>>>> regards
>>>>>>
>>>>>>  Greg
>>>>>>
>>>>>>
>>>>>>  _______________________________________________
>>>>>> Xen-devel mailing listXen-devel@lists.xen.orghttp://lists.xen.org/xen-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>

--047d7b33934159e141050b78ff5d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Ok Fabio, thanks to your configure, some bits of=
 hacking the install part and lots of advises/support/encouragements ;) fro=
m Mark Pryor I ended up<br></div>=C2=A0installing 4.5RC4 with QXL support o=
n Deb8 unstable.<br><br><br></div><div>So now what do you want me to test f=
abio?<br></div><div>I have win7 x64 / win 2k8R2 vms in test mode ready to i=
nstall drvers.<br></div><div><br></div><div>the numerous troubles I went th=
rough are related in the IRCcopy attached.<br></div><div>I actually couldn&=
#39;t build rombios and used seabios provided by the system -like you-<br><=
/div><div>I should try to compile/find latest qxl now.<br><br></div><div>Se=
e you in 2K15.<br><br></div><div>greg B<br></div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">2014-12-29 14:49 GMT+01:00 Fabio Fant=
oni <span dir=3D"ltr">&lt;<a href=3D"mailto:fabio.fantoni@m2r.biz" target=
=3D"_blank">fabio.fantoni@m2r.biz</a>&gt;</span>:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Il 29/12/2014 14:13, Goonie Windy ha
      scritto:<br>
    </div><span class=3D"">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>ok, I&#39;m trying to patch the files with yours,<br>
              <br>
              <br>
            </div>
            I need to do it manually right? <br>
            <br>
            git apply is not working here. <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    If the patch need a &quot;refresh&quot; the conflict should be solved
    manually.<br>
    Taking the patch updated from here probably it can be applied to
    latest 4.5-rc:<br>
    <a href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging" tar=
get=3D"_blank">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a><=
span class=3D""><br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div><br>
            <br>
          </div>
          regards<br>
          <br>
        </div>
        greg<br>
      </div>
      <div class=3D"gmail_extra"><br>
        <div class=3D"gmail_quote">2014-12-29 13:46 GMT+01:00 Goonie Windy
          <span dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.goonie@gmail.com=
" target=3D"_blank">monsieur.goonie@gmail.com</a>&gt;</span>:<br>
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
            <div dir=3D"ltr">There is an error in pageqs describing how to
              compile from sources as in 4.5 <br>
              <pre>cat .config
PYTHON_PREFIX_ARG=3D--install-layout=3Ddeb

</pre>
              <pre>is in fact in .INSTALL
</pre>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br></span>
    If also you use debian you can use make debball that is better for
    install/remove easy and fast test build.<br>
    <br>
    And for example I use this configure options with xen 4.5:<br>
    ./configure --prefix=3D/usr --disable-blktap1
    --disable-qemu-traditional --disable-rombios
    --with-system-seabios=3D/usr/share/seabios/bios-256k.bin
    --with-extra-qemuu-configure-args=3D&quot;--enable-spice
    --enable-usb-redir&quot; --disable-blktap2<br>
    I use wheezy building updated packages from sid: seabios 1.7.5-1,
    spice 0.12.5-1, spice-protocol 0.12.7-1 and usbredir 0.7-1.<br>
    If you use jessie instead you have all packages updated.<br>
    <br>
    About python I&#39;m using this workaround (before execute configure)
    even if probably is not the best:<br>
    <span title=3D"Config.mk">Config.mk</span><br>
    -<span>PYTHON_PREFIX_ARG</span> ?=3D<span> --prefix=3D&quot;</span><spa=
n><span>$(</span><span>PREFIX</span><span>)</span></span><span>&quot;</span=
><br>
    +<span>PYTHON_PREFIX_ARG</span> ?=3D<div><div class=3D"h5"><br>
    <br>
    <blockquote type=3D"cite">
      <div class=3D"gmail_extra">
        <div class=3D"gmail_quote">
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
            <div dir=3D"ltr"><br>
            </div>
            <div>
              <div>
                <div class=3D"gmail_extra"><br>
                  <div class=3D"gmail_quote">2014-12-29 1:20 GMT+01:00
                    Goonie Windy <span dir=3D"ltr">&lt;<a href=3D"mailto:mo=
nsieur.goonie@gmail.com" target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                        <div>well figured out it is because you have to
                          &quot;enforce&quot; locale:=C2=A0 export LC_ALL=
=3Den_US.utf-8
                          if keyboard mapping is else<br>
                        </div>
                      </div>
                      <div>
                        <div>
                          <div class=3D"gmail_extra"><br>
                            <div class=3D"gmail_quote">2014-12-28 21:19
                              GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;=
<a href=3D"mailto:monsieur.goonie@gmail.com" target=3D"_blank">monsieur.goo=
nie@gmail.com</a>&gt;</span>:<br>
                              <blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                                <div dir=3D"ltr">
                                  <div>Trying to compile xen 4.5RC4 in
                                    order to test your patch I end up
                                    with=C2=A0 these errors compiling the
                                    Seabios directories,<br>
                                    <br>
                                  </div>
                                  any idea?<br>
                                  <br>
                                  =C2=A0 Compiling to assembler
                                  out/src/asm-offsets.s<br>
                                  =C2=A0 Generating offset file
                                  out/asm-offsets.h<br>
                                  =C2=A0 Compiling (16bit) out/romlayout.o<=
br>
                                  =C2=A0 Building ld scripts<br>
                                  Version:
                                  rel-1.7.5-0-ge51488c-20141228_210340-E766=
<br>
                                  Traceback (most recent call last):<br>
                                  =C2=A0 File &quot;./scripts/layoutrom.py&=
quot;, line
                                  709, in &lt;module&gt;<br>
                                  =C2=A0=C2=A0=C2=A0 main()<br>
                                  =C2=A0 File &quot;./scripts/layoutrom.py&=
quot;, line
                                  671, in main<br>
                                  =C2=A0=C2=A0=C2=A0 info16 =3D parseObjDum=
p(infile16,
                                  &#39;16&#39;)<br>
                                  =C2=A0 File &quot;./scripts/layoutrom.py&=
quot;, line
                                  586, in parseObjDump<br>
                                  =C2=A0=C2=A0=C2=A0 relocsection =3D
                                  sectionmap[sectionname]<br>
                                  KeyError:
&#39;.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.=
c.79&#39;<br>
                                  Makefile:155: recipe for target
                                  &#39;out/romlayout16.lds&#39; failed<br>
                                  make[6]: *** [out/romlayout16.lds]
                                  Error 1<br>
                                  make[6]: Leaving directory
                                  &#39;/home/goon/xen/tools/firmware/seabio=
s-dir-remote&#39;<br>
                                  /home/goon/xen/tools/firmware/../../tools=
/Rules.mk:116:
                                  recipe for target
                                  &#39;subdir-all-seabios-dir&#39; failed<b=
r>
                                  <br>
                                  <br>
                                </div>
                                <div>
                                  <div>
                                    <div class=3D"gmail_extra"><br>
                                      <div class=3D"gmail_quote">2014-12-27
                                        17:35 GMT+01:00 Goonie Windy <span =
dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.goonie@gmail.com" target=3D"_bla=
nk">monsieur.goonie@gmail.com</a>&gt;</span>:<br>
                                        <blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                                          <div dir=3D"ltr">
                                            <div>
                                              <div>
                                                <div>Hello Fabio,<br>
                                                  <br>
                                                  Sure thing I will help
                                                  debug the win7 and the
                                                  win8 versions.<br>
                                                </div>
                                                Where to start?<br>
                                                <br>
                                              </div>
                                              I&#39;ll try to see if I can
                                              patch with patch from <a href=
=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e=
8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8=
c7e421fafba67aa11879e8b8fe</a>
                                              and if not will post
                                              result.<br>
                                              <br>
                                              <br>
                                              best regards,<br>
                                              <br>
                                              <br>
                                            </div>
                                            greg Bahde<br>
                                          </div>
                                          <div>
                                            <div>
                                              <div class=3D"gmail_extra"><b=
r>
                                                <div class=3D"gmail_quote">=
2014-12-27
                                                  15:10 GMT+01:00 Fabio
                                                  Fantoni <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">fabio.fanto=
ni@m2r.biz</a>&gt;</span>:<br>
                                                  <blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
                                                    <div bgcolor=3D"#FFFFFF=
" text=3D"#000000"> <br>
                                                      <div>Il 27/12/2014
                                                        02:15, Goonie
                                                        Windy ha
                                                        scritto:<br>
                                                      </div>
                                                      <span>
                                                        <blockquote type=3D=
"cite">
                                                          <div dir=3D"ltr">
                                                          <div>
                                                          <div>
                                                          <div>I tried
                                                          to install Qxl
                                                          drivers under
                                                          win7/win
                                                          2k8/win8.1=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          all=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 x64
                                                          versions,
                                                          without any
                                                          luck.<br>
                                                          <br>
                                                          <br>
                                                          admin message
                                                          is as follow:<br>
                                                          Driver
                                                          Management
                                                          concluded the
                                                          process to
                                                          install driver
                                                          FileRepository\qx=
l.inf_amd64_

                                                          <div dir=3D"ltr">=
neutral_f0c429882d5c81ed\qxl.inf
                                                          for Device
                                                          Instance ID
                                                          PCI\VEN_1013&amp;=
DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&amp;267A616A&amp;1&amp;28

                                                          with the
                                                          following
                                                          status:
                                                          0xe000022d.</div>
                                                          <br>
                                                          <br>
                                                          <br>
                                                          <br>
                                                          </div>
                                                          Does <br>
                                                          <a href=3D"http:/=
/lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html" target=3D"_bl=
ank">http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html</a>=
<br>
                                                          <br>
                                                          </div>
                                                          can it be
                                                          installed on
                                                          my xen stack?
                                                          <br>
                                                          </div>
                                                          </div>
                                                        </blockquote>
                                                        <br>
                                                      </span> Yes but
                                                      probably require a
                                                      small refresh, I
                                                      always posted the
                                                      patch based on
                                                      updated
                                                      xen-unstable. <br>
                                                      <br>
                                                      Here qxl patch
                                                      refreshed for xen
                                                      4.5 if needed:<br>
                                                      <a href=3D"https://gi=
thub.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe" target=
=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67=
aa11879e8b8fe</a><br>
                                                      <br>
                                                      Here the latest
                                                      spice guest tools
                                                      for windows with
                                                      qxl driver
                                                      included:<br>
                                                      <a href=3D"http://www=
.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74=
.exe" target=3D"_blank">http://www.spice-space.org/download/binaries/spice-=
guest-tools/spice-guest-tools-0.74.exe</a><br>
                                                      <br>
                                                      Windows &gt;=3D8 and
                                                      similar require a
                                                      new qxl drivers,
                                                      there are a beta
                                                      build but latest
                                                      tried some months
                                                      ago have serious
                                                      bug and I not
                                                      found recent build
                                                      full working on
                                                      windows 8.<br>
                                                      <br>
                                                      On xen windows 7
                                                      domUs qxl works
                                                      good except a
                                                      problem after
                                                      save/restore and
                                                      on linux domUs is
                                                      not working, for
                                                      now I not found
                                                      exactly cause and
                                                      solution.<br>
                                                      On mailing list up
                                                      to 2 years ago you
                                                      can find many my
                                                      mails about.<br>
                                                      Any help to test
                                                      it is appreciated.<br=
>
                                                      <br>
                                                      Sorry for my bad
                                                      english.<br>
                                                      <br>
                                                      <blockquote type=3D"c=
ite"><span>
                                                          <div dir=3D"ltr">
                                                          <div><br>
                                                          Also, can=C2=A0 I
                                                          get invited at
                                                          xendevel irc ?<br=
>
                                                          regards<br>
                                                          <br>
                                                          </div>
                                                          Greg <br>
                                                          </div>
                                                          <br>
                                                          <fieldset></field=
set>
                                                          <br>
                                                        </span>
                                                        <pre>______________=
_________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a>
</pre>
                                                      </blockquote>
                                                      <br>
                                                    </div>
                                                  </blockquote>
                                                </div>
                                                <br>
                                              </div>
                                            </div>
                                          </div>
                                        </blockquote>
                                      </div>
                                      <br>
                                    </div>
                                  </div>
                                </div>
                              </blockquote>
                            </div>
                            <br>
                          </div>
                        </div>
                      </div>
                    </blockquote>
                  </div>
                  <br>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div>

--047d7b33934159e141050b78ff5d--
--047d7b33934159e146050b78ff5f
Content-Type: application/octet-stream; name="xen4.5RC4"
Content-Disposition: attachment; filename="xen4.5RC4"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i4c0sywk0

KiBzdWJkcml2ZW4gKH5zdWJkcml2ZW5Ac2VjdXJhYml0L2xpc3RlbmVyL3N1YmRyaXZlbikgYSBy
ZWpvaW50ICN4ZW4KKiBvdmFuXyBlc3QgcGFydGkgKFF1aXQ6IExvc3QgdGVybWluYWwpCiogc2t5
bGl0ZSAofnNreWxpdGVANTQwMDBDMTMuZHNsLnBvb2wudGVsZWtvbS5odSkgYSByZWpvaW50ICN4
ZW4KKiBnZWFhcnUgZXN0IHBhcnRpIChRdWl0OiBMZWF2aW5nKQoqIGRhcmlvZiAofmRhcmlvZkBu
ZXQtMi0zOS03MC0xMDMuY3VzdC52b2RhZm9uZWRzbC5pdCkgYSBxdWl0dMOpICN4ZW4KKiBQcnlN
YXI1NiBlc3QgcGFydGkgKFF1aXQ6IExlYXZpbmcpCiogeG1lcmxpbiAofnhtZXJsaW5AMjEyLTEy
NC0xNjQtMTYxLnY0Lm5naS5pdCkgYSByZWpvaW50ICN4ZW4KKiBTZXJsZXheICh+c2VyY2FuQGNw
YzItZ2xmZDYtMi0wLWN1c3QyNTAuNi0yLmNhYmxlLnZpcmdpbm0ubmV0KSBhIHJlam9pbnQgI3hl
bgoqIFNlcmxleF4gZXN0IHBhcnRpIChDbGllbnQgUXVpdCkKKiBlbmdsaXNobV8gcydhcHBlbGxl
IG1haW50ZW5hbnQgZW5nbGlzaG0KKiBvbGFmXyBlc3QgcGFydGkgKFF1aXQ6IENsaWVudCBleGl0
aW5nKQoqIGVuZ2xpc2htIGVzdCBwYXJ0aSAoQ2hhbmdpbmcgaG9zdCkKKiBlbmdsaXNobSAofmVu
Z2xpc2htQHVuYWZmaWxpYXRlZC9lbmdsaXNobSkgYSByZWpvaW50ICN4ZW4KPEZyb3NoPiBJcyB0
aGVyZSBhIHdheSB0byByZXN0YXJ0IHhlbiBoeXBlcnZpc29yIGFmdGVyIGEgdXBncmFkZSBmcm9t
IDQuMyB0byA0LjQgb3IganVzdCByZWJvb3QgdGhlIGNvbXB1dGVyIGlzIHRoZSBvbmx5IHNvbHV0
aW9uLCBzb3J0YSBkb24ndCB3YW50IHRvIHJlc3RhcnQgYWxsIHRoZSBkb211CjxhbmR5aGhwPiBu
bwo8YW5keWhocD4gd2h5IHdvdWxkIHRoZXJlIGJlPwo8YW5keWhocD4gd291bGQgeW91IGV4cGVj
dCB0byBiZSBhYmxlIHRvIGRvIGEgbGludXgga2VybmVsIHVwZ3JhZGUgd2l0aG91dCByZWJvb3Rp
bmc/Cjxkd2ZyZWVkPiB0ZWNobmljYWxseSB5b3UgY2FuIGtleGVjIFhlbiwgYnV0IHlvdSdyZSBi
ZXR0ZXIgb2ZmIGp1c3QgcmVib290aW5nLCBiZWNhdXNlIHlvdSdkIHN0aWxsIGhhdmUgdG8gdGFr
ZSBkb3duIGFsbCBvZiB5b3VyIFZNcwoqIETDqWNvbm5lY3TDqSAoQ29ubmV4aW9uIHRlcm1pbsOp
ZSBwYXIgZXhwaXJhdGlvbiBkdSBkw6lsYWkgZCdhdHRlbnRlKS4KKiBWb3VzIHBhcmxleiBtYWlu
dGVuYW50IHN1ciAjeGVuCiogTGUgc3VqZXQgZGUgI3hlbiBlc3TCoDogWGVuIDQuNC4xIHJlbGVh
c2VkISBodHRwOi8vd3d3LnhlbnByb2plY3Qub3JnL2Rvd25sb2Fkcy5odG1sIHwgV2lraTogaHR0
cDovL3dpa2kueGVucHJvamVjdC5vcmcvIHwgRkFROiBodHRwOi8vd2lraS54ZW5wcm9qZWN0Lm9y
Zy93aWtpL1hlbl9Db21tb25fUHJvYmxlbXMKKiBTdWpldCBkZSAjeGVuIGTDqWZpbmkgcGFyIEtl
dmluYCBsZSBXZWQgU2VwICAzIDIzOjI3OjM3IDIwMTQKPFByeU1hcjU2PiBnb29uaWVCLCB0aGUg
cXhsIHBhdGNoc2V0IGlzIGZvciA0LjUgKEhFQUQpPyB3aGF0IGlzIGRhdGUgb24gcGF0Y2g/Cjxn
b29uXz4gUHJ5TWFyNTYsIGRvbid0IGdldCBpdCwgeWVzIGl0IGlzIDQuNSBJJ20gdHJ5aW5nIHRv
IGNvbXBpbGUgLWFuZCBmYWlsbGluZyB0byByZWdhcmRpbmcgdGhlIFNlYWJpb3MgcGFydC0gaW4g
b3JkZXIgdG8gaW5zdGFsbCB0aGlzIHF4bCBwYXRjaAo8Z29vbl8+IDQuNVJDNAo8UHJ5TWFyNTY+
IHJvbGwgYmFjayB0aGUgdGFnIC0+IGNoZWNrb3V0IHhlbi00LjUuMC1yYzEKKiBPc2VucGFpXyAo
fk9zZW5wYWlAMTc3LjgxLjkuNjYpIGEgcmVqb2ludCAjeGVuCjxQcnlNYXI1Nj4gbWlnaHQgbmVl
ZCB0byByb2xsIGJhY2sgc2VhYmlvcwoqIE9zZW5wYWkgZXN0IHBhcnRpIChQaW5nIHRpbWVvdXQ6
IDI1OCBzZWNvbmRzKQo8Z29vbl8+IFByeU1hcjU2LCBzZWFyY2hpbmcgaG93IHRvIGRvIHRoYXQs
IGlmIHlvdSBrbm93Li4uCjxQcnlNYXI1Nj4gaW4gc2Vjb25kcyB5b3UgY2FuIGNsb25lIHRoZSBz
ZWFiaW9zIGdpdCBhbmQgZG8gYGdpdCBicmFuY2ggLWFgCjxQcnlNYXI1Nj4gbG9vayBpbiBDb25m
aWcubWsgZm9yIHRoZSBVUkwKKiBhbmRlcnNvbmMwZDMgKH5hbmRlcnNvbmNAdW5hZmZpbGlhdGVk
L2FuZGVyc29uYzBkMykgYSByZWpvaW50ICN4ZW4KPGdvb25fPiBQcnlNYXI1NiwgdGhhbmsgeW91
CjxQcnlNYXI1Nj4gU0VBQklPU19VUFNUUkVBTV9VUkwKPFByeU1hcjU2PiBnb29uXywgeW91IHNl
ZW0gcHJldHR5IGRldGVybWluZWQgdG8gZml4IHRoaXMsIHNvIGNsb25pbmcgZ2l0IG1pZ2h0IGJl
IHdvcnRoIHRoZSB0cm91YmxlCjxnb29uXz4gU0VBQklPU19VUFNUUkVBTV9SRVZJU0lPTiA/PSBy
ZWwtMS43LjUKPGdvb25fPiBnaXQ6Ly94ZW5iaXRzLnhlbi5vcmcvc2VhYmlvcy5naXQKPGdvb25f
PiBzbyB5b3Ugc3VnZ2VzdCBJIHRyeSB0byBnaXQgdGhlIHNhbWUgcmVsIGFzIHRoZSBvbmUgaW5j
bHVkZWQgaW4gUkMxPwo8UHJ5TWFyNTY+IEZhbnRvbiB3cm90ZSB0aGUgcGF0Y2ggaW4gSnVseSAn
MTQ/CjxQcnlNYXI1Nj4gYXBvbG9neSBpZiBJIGJ1dGNoZXJlZCBoaXMgbmFtZQo8Z29vbl8+IFBy
eU1hcjU2LCB5ZXMgaW4ganVseQo8UHJ5TWFyNTY+IGZyb20geW91ciBwYXN0ZSwgaXQgZXJyb3Jl
ZCBpbiBmaXJtd2FyZS9TZWFiaW9zCjxQcnlNYXI1Nj4gdG9vbHMvZmlybXdhcmUvc2VhYmlvcwo8
UHJ5TWFyNTY+IGdpdCBzaG93IDFiMDY4YTViIDwtLSB0aGUgY29tbWl0IHRoYXQgYWRkZWQgdGhl
IHJjMSB0YWcKPFByeU1hcjU2PiBldmVuIHJjMSBpcyBub3Qgb2xkIGVub3VnaCAoT2N0IDI0ICcx
NCkKPGdvb25fPiB5ZXMsIHdoYXQgSSB0aG91Z2h0LCBidXQgbm90IHN1cmUgaG93IHRvIG1vdmUg
Zm9yd2FyZCwgbmVlZCBhIGdpdCBjcmFzaCBjb3Vyc2UgdG8gZG8gc28gOykKPGdvb25fPiBvbiBt
eSB3YXkgdGhvdWgKPFByeU1hcjU2PiBpbiB0aGUgc2VhYmlvcyB0cmVlOiBnaXQgbG9nICAgLXAg
PGludGVyZXN0aW5nIHBhdGg+CjxQcnlNYXI1Nj4gZ2l0IGxvZyAgLS1wcmV0dHk9b25lbGluZQo8
Z29vbl8+IFByeU1hcjU2LCBvaywgSSBzZWUgdGhlIGxpc3Qgb2YgY29tbWl0cwo8Z29vbl8+IFBy
eU1hcjU2LCAgdGhlIGNvbW1pdCBjYXVzaW5nIHRyb3VibGUgaXMgZTUxNDg4YzVmODgwMGE1MmFj
NWM4ZGE3YTMxYjg1Y2NhNWNjOTVkMiBweXRob24zIGZpeGVzIGZvciB2Z2FiaW9zIGFuZCBjc20g
YnVpbGRzLgo8Z29vbl8+IHNvIGhvdyB0byBnZXQgcHJldmlvdXMgdmVyc2lvbi4KPGdvb25fPiBz
byBnaXQgYnJhbmNoIC1hIGdpdmVzIG1lICAgcmVtb3Rlcy9vcmlnaW4vMS42LjMtc3RhYmxlLXhl
bgo8Z29vbl8+ICAgcmVtb3Rlcy9vcmlnaW4vMS43LjEtc3RhYmxlLXhlbgo8Z29vbl8+ICAgcmVt
b3Rlcy9vcmlnaW4vMS43LjMtc3RhYmxlCjxnb29uXz4gICByZW1vdGVzL29yaWdpbi9IRUFEIC0+
IG9yaWdpbi9tYXN0ZXIKPGdvb25fPiAgIHJlbW90ZXMvb3JpZ2luL21hc3Rlcgo8Z29vbl8+IGFu
ZCB0aGUgY3VycmVudCBpcyAxLjcuNSBzbyBtYXliZSBJIHNob3VsZCBtb3ZlIGJhY2sgdG8gMS43
LjMKPGdvb25fPiBnb3R0YSBsZWFybiBob3cgdG8gZG8gdGhhdCAKKiBHdWVzdDE1NzA5IGVzdCBw
YXJ0aSAoUmVtb3RlIGhvc3QgY2xvc2VkIHRoZSBjb25uZWN0aW9uKQo8UHJ5TWFyNTY+IGdyZXAg
dGhlIGBnaXQgbG9nICAtLXByZXR0eT1vbmVsaW5lYCBmb3IgdGFncwo8UHJ5TWFyNTY+IG5vdCBz
dXJlIGlmIHRoZXkgZnJlZXplIHdpdGggdGFncyB0aGUgd2F5IHhlbiBkb2VzCiogUGVyICh+cXVh
c3NlbEA3NC44MS0xNjYtMTcuY3VzdG9tZXIubHlzZS5uZXQpIGEgcmVqb2ludCAjeGVuCiogUGVy
IHMnYXBwZWxsZSBtYWludGVuYW50IEd1ZXN0MzQ0ODMKPFByeU1hcjU2PiBnaXQgY2hlY2tvdXQg
MS43LjMtc3RhYmxlCjxQcnlNYXI1Nj4gZ2l0IGNoZWNrb3V0IG1hc3RlciA8LS0tIHRvIHJlc3Rv
cmUgdG8gSEVBRAo8UHJ5TWFyNTY+IHlvdSBjYW4gdHJ5IHRvIHJldmVydCB0aGUgZTUxNDg4YzUK
PGdvb25fPiBQcnlNYXI1NiwgZ3JlYXQgb2ssIG5vdyBJJ2xsIGZvbGxvdyB0aGUgY29tcGlsZSBw
cm9jZWR1cmUgYmFjayBhZ2Fpbgo8UHJ5TWFyNTY+IGdpdCByZXZlcnQgLS1uby1jb21taXQgLS1u
by1lZGl0CjxQcnlNYXI1Nj4gZ2l0IHJldmVydCAtLW5vLWNvbW1pdCAtLW5vLWVkaXQgPHNoYSBw
cmVmaXg+Cjxnb29uXz4gdHJpZWQgd2l0aCAxLjcuMy1zdGFibGUgLCBzdGlsbCBhbiBlcnJvciwg
YnV0IGRpZmZlcmVudDoKPGdvb25fPiBodHRwOi8vcGFzdGViaW4uY29tL2tQd2dMVmZHCjxnb29u
Xz4gUHJ5TWFyNTYsIGd1ZXNzIEkgc2hvdWxkIHRyeSB3aXRoIG1hc3RlciwgcmV2ZXJ0aW5nIGxp
a2UgeW91IHNhaWQKKiBPbGdhYWEgZXN0IHBhcnRpICgpCjxQcnlNYXI1Nj4gYSByZXZlcnQgaXMg
YWdncmVzc2l2ZSBtb3ZlIGZvciBhIGRldiwgc28gdXNlIC0tbm8tY29tbWl0CjxQcnlNYXI1Nj4g
aWYgdGhlIHBhdGNoIGlzIHNob3J0LCB5b3UgY2FuIHJldmVyc2UgaXQgYnkgaGFuZAo8UHJ5TWFy
NTY+IGdpdCBzdGF0dXMgIDwtLSBoZWxwcyB0b28gYW5kIGZpbmFsbHkgYGdpdCBkaWZmYCB0byBk
dW1wIHlvdXIgY2hhbmdlcwo8UHJ5TWFyNTY+IGxldCBnaXQgbWFrZSB5b3VyIHBhdGNoZXMgZm9y
IHlvdQo8Z29vbl8+IHRyaWVkIDEuNy4xLXN0YWJsZS14ZW4gd2l0aG91dCBsdWNsIGVpdGhlcgo8
Z29vbl8+IFByeU1hcjU2LCBpZG4ndCBnbyBmYXIsIHN0aWxsIG5vdCB3b3JraW5nIDovCiogRnJv
c2ggZXN0IHBhcnRpIChRdWl0OiBDb25uZWN0aW9uIGNsb3NlZCBmb3IgaW5hY3Rpdml0eSkKPGdv
b25fPiBQcnlNYXI1NiwgdHJ5aW5nIHRvIGJ1aWxkIHRoZSBSQzMgaW5zdGVhZCwgZG9uJ3Qga25v
dyBpZiBpdCdzIGEgc3R1cGlkIG1vdmUgb3Igbm90LCAKPGdvb25fPiBidXQgZm9yIG5vdwo8Z29v
bl8+IFByeU1hcjU2LCBoYXZlIGV4YWN0bHkgc2FtZSBwcm9ibGVtcyB0cnlpbmcgdG8gY29tcGls
ZSA0LjUgUkMzCiogR3Vlc3QzNDQ4MyBlc3QgcGFydGkgKFJlbW90ZSBob3N0IGNsb3NlZCB0aGUg
Y29ubmVjdGlvbikKKiBQZXIgKH5xdWFzc2VsQDc0LjgxLTE2Ni0xNy5jdXN0b21lci5seXNlLm5l
dCkgYSByZWpvaW50ICN4ZW4KKiBQZXIgcydhcHBlbGxlIG1haW50ZW5hbnQgR3Vlc3QyODc1OAoq
IEZhbnR1IGVzdCBwYXJ0aSAoUXVpdDogQ2hhdFppbGxhIDAuOS45MS4xIFtGaXJlZm94IDM0LjAu
NS8yMDE0MTEyNjA0MTA0NV0pCjxQcnlNYXI1Nj4gZ29vbl8sIHJlbWVtYmVyIHRvIHJ1biBjb25m
aWd1cmUgZnJvbSB4ZW4gcm9vdCB3aXRoIHRoZSAtLXdpdGgtZXh0cmEtcWVtdVUtY29uZmlndXJl
LWFyZ3M9Ii0tZW5hYmxlLXNwaWNlIC0tZW5hYmxlLXVzYi1yZWRpciIKPFByeU1hcjU2PiBub3cg
dGhhdCBJIHN0YXJlIGF0IHRoZSBlcnJvciB5b3UgZ2V0LCBpdCBtZWFucyBjb25maWd1cmUgd2Fz
IG5vdCBydW4KPGdvb25fPiBQcnlNYXI1Niwgd2VsbCBpdCB3YXMsIGJ1dCBJJ2xsIGFkZCB0aGUg
cGFyYW1ldGVycyB5b3UgZ2F2ZSBtZQo8UHJ5TWFyNTY+IGFmdGVyIGNvbmZpZ3VyZSB0cnkgYG1h
a2UgZGlzdC10b29sc2AKPFByeU1hcjU2PiB0aGUgc2VhYmlvcyBnb2VzIGludG8gdGhlLi90b29s
cy9maXJtd2FyZS9zZWFiaW9zLWRpcgo8UHJ5TWFyNTY+IHdoZW4gYnVpbGRpbmcgdGhlIHJjWCB0
YXJiYWxscwoqIGNyeXB0b3p1bHUgKH5sb3JkX21vbmVAMTk2LTIxMC0xNzItMjIxLmR5bmFtaWMu
aXNhZHNsLmNvLnphKSBhIHJlam9pbnQgI3hlbgoqIGFuZGVyc29uYzBkMyBlc3QgcGFydGkgKFBp
bmcgdGltZW91dDogMjQwIHNlY29uZHMpCiogc2FyaWQgZXN0IHBhcnRpIChRdWl0OiBaTkMgLSBo
dHRwOi8vem5jLmluKQoqIHNhcmlkICh+c2FyaWRAMTc4LjYyLjE2MC4yMjcpIGEgcmVqb2ludCAj
eGVuCiogc2FyaWQgcydhcHBlbGxlIG1haW50ZW5hbnQgR3Vlc3Q4NDQ0NAo8Z29vbl8+IFByeU1h
cjU2LCBzbyBubyBsdWNrIGVpdGhlciB3aXRoIHBhcmFtcywgSSBub3RpY2VkIHRoYXQgb24gdGhl
IG1hcmttYWlsLCBzb21lb25lIGNvbXBpbGVkIG9uIGplc3NpZSB3aXRoIHRoZXNlIHBhcmFtcyAi
LS1lbmFibGUtZ2l0aHR0cCAtLWVuYWJsZS1zeXN0ZW1kIiwgYW5kIGl0IGZhaWxlZCBzdGlsbAo8
Z29vbl8+IFByeU1hcjU2LCB3aGF0IGRvZXMgc2VhYmlvcy1kaXItcmVtb3RlIGNvbnRhaW4gZXhh
Y3RseT8KKiBkYXJpb2YgKH5kYXJpb2ZAbmV0LTItMzktNzAtMTAzLmN1c3Qudm9kYWZvbmVkc2wu
aXQpIGEgcmVqb2ludCAjeGVuCiogY3J5cHRvenVsdSAofmxvcmRfbW9uZUAxOTYtMjEwLTE3Mi0y
MjEuZHluYW1pYy5pc2Fkc2wuY28uemEpIGEgcXVpdHTDqSAjeGVuICgiQmUgYmFjayBpbiBhIGJp
dCIpCjxnb29uXz4gbXkgZXJyb3Igc3RhbmRzIGluIEtleUVycm9yOiAnLnRleHQuYXNtLi9ob21l
L2dvb24veGVuL3Rvb2xzL2Zpcm13YXJlL3NlYWJpb3MtZGlyLXJlbW90ZS9zcmMvZncvc21wLmMu
NzknCjxnb29uXz4gUHJ5TWFyNTYsIG9rLCBpcyBpdCBub3JtYWwgdGhhdCBJIGdldCAyIGRpcmVj
dG9yaWVzPyBvbmUgY2FsbGVkIHNlYWJpb3MtZGlyIGFuZCB0aGUgb3RoZXIgb25lIGNhbGxlZCBz
ZWFiaW9zLWRpci1yZW1vdGUgd2l0aCBmaWxlcyBhbGlrZT8KPFByeU1hcjU2PiBJSVJDLCB0aGUg
Ki1yZW1vdGUgaXMgdGhlIHJlc3VsdCBvZiBhIHJlbW90ZSBnaXQgY2xvbmUuIERpZG4ndCB5b3Ug
aGF2ZSBhIGxvY2FsIGRpcj8KKiBkYXJpb2YgKH5kYXJpb2ZAbmV0LTItMzktNzAtMTAzLmN1c3Qu
dm9kYWZvbmVkc2wuaXQpIGEgcXVpdHTDqSAjeGVuCjxnb29uXz4gUHJ5TWFyNTYsIEkgaGF2ZSBh
IGxvY2FsIHNlYWJpb3MtZGlyLCBidXQgZHVyaW5nIG1ha2UgZGlzdCwgdGhlcmUgYXJlIGZpbGVz
IGRvd25sb2FkZWQgdG8gdGhhdCByZW1vdGUKPFByeU1hcjU2PiBvbmUgbWlnaHQgYmUgc3ltbGlu
a2VkIHRvIHRoZSBvdGhlciwgZG9uCjxQcnlNYXI1Nj4gZG9uJ3QgcmVtZW1iZXIKPGdvb25fPiB0
aGV5IGFyZSBub3Qgc28gc3ltbGlua2VkCiogb21hcnJyIGVzdCBwYXJ0aSAoUmVtb3RlIGhvc3Qg
Y2xvc2VkIHRoZSBjb25uZWN0aW9uKQo8UHJ5TWFyNTY+IG9rLCBpZiB5b3Ugd2FudCB0aGUgbG9j
YWwgc2VhYmlvcyBkaXIgaW4gdGhlIHJjWCBidWlsZCB0cmVlLCB0aGVuIHJlZXh0cmFjdCB0aGUg
dGFyLmd6IGFuZCBjb3B5IHlvdXIgc2VhYmlvcyB0byBzZWFiaW9zLWRpcgo8UHJ5TWFyNTY+IHRo
ZW4gdGhlIGJ1aWxkIHdpbGwgdXNlIHlvdXIgZGlyIGFuZCBmb3JnZXQgYWJvdXQgYSByZW1vdGUg
Y2xvbmUKPFByeU1hcjU2PiBJIGhhdmUgZG9uZSB0aGlzIG15c2VsZi4gSSBhbSBub3QgYmxvd2lu
ZyBzbW9rZQo8UHJ5TWFyNTY+IGJlZm9yZSB5b3UgYG1ha2UgZGlzdC10b29sc2AgeW91ciBzZWFi
aW9zIHNob3VsZCBiZSBpbiAuL3Rvb2xzL2Zpcm13YXJlL3NlYXJiaW9zLWRpcgo8Z29vbl8+IFBy
eU1hcjU2LCBvaywgZG93bmxvYWRpbmcgSSBzZWUgdGhhdCB0aGUgdGFyIHZlcnNpb24gaXMgMS43
LjUuMSB2cyAxLjcuNSBvbiBnaXRodWIKPGdvb25fPiB3aWxsIGRvIHRoYXQKPGdvb25fPiBQcnlN
YXI1Niwgc28gc2VhYmlvcy1kaXIgd2FzIHN5bWxpbmtlZCwgaSByZWFzc2lnbmVkIGl0IHRvIG15
IGV4dHJhY3RlZCBzZWFiaW9zIHRhciBhbmQgd2lsbCBzZWUgaG93IGl0IGdvZXMKPGdvb25fPiBQ
cnlNYXI1NiwgdGhlcmUgaXMgbm8gMTZiaXQgc3BlY2lmaWMgbGlicmFyaWVzIHRvIGluc3RhbGwg
aW4gb3JkZXIgdG8gY29tcGlsZSBzZWFiaW9zPwo8UHJ5TWFyNTY+IGh0dHA6Ly9wYXN0ZWJpbi5j
b20vbUMwZ2I3NWkKPFByeU1hcjU2PiBeXiBmcm9tIGEgYnVpbGQgeWVzdGVyZGF5IHdoZXJlIEkg
Y29waWVkIGluIGEgbG9jYWwgc2VhYmlvcy4gQnVpbGQgd2VudCBvZmYgYXQgMTc6MDAKPFByeU1h
cjU2PiBzZWFiaW9zIHdhcyB0YXJyZWQgdXAgb24gTm92OQo8UHJ5TWFyNTY+IGl0cyBvbiBDZW50
b3M3Cjxnb29uXz4gb2ssIGJ1dCBpdCBpcyBibG9ja2luZyBmb3IgbWUgb24gZGViaWFuIHdpbGwg
c2VuZCBtYWlsIHRvIHhlbiBkZXZlbAo8Z29vbl8+IDovCjxQcnlNYXI1Nj4gZGViaWFuIGhhcyB0
aWdodGVuZWQgdXAgdGhlIGJhc2ggc2VjdXJpdHkuLi4gL2Jpbi9zaCBpcyBub3QgYmFzaC4uLiBj
YXVzZWQgbWUgaGVhZGFjaGVzCjxnb29uXz4gOikgeWVhaCB3ZWxsIHNlbGludXggZG9lcyB0aGF0
IHRvIHNvbWUgaGFzIHdlbGwKPGdvb25fPiB3aWxsIHRyeSB3aXRoIHByZXZpb3VzIHRhciB2ZXJz
aW9uIChzdGFydGluZyB3aXRoIDEuNzQKPGdvb25fPiBQcnlNYXI1NiwgdGhlcmUgcmVhbGx5IG11
c3QgYmUgYSBzY3JpcHQgZXJyb3Igb3Igc210ZyBGaWxlICIuL3NjcmlwdHMvbGF5b3V0cm9tLnB5
IiwgbGluZSA3MDgsIGluIDxtb2R1bGU+Cjxnb29uXz4gICAgIG1haW4oKQo8Z29vbl8+ICAgRmls
ZSAiLi9zY3JpcHRzL2xheW91dHJvbS5weSIsIGxpbmUgNjcwLCBpbiBtYWluCjxnb29uXz4gICAg
IGluZm8xNiA9IHBhcnNlT2JqRHVtcChpbmZpbGUxNiwgJzE2JykKPGdvb25fPiAgIEZpbGUgIi4v
c2NyaXB0cy9sYXlvdXRyb20ucHkiLCBsaW5lIDU4NSwgaW4gcGFyc2VPYmpEdW1wCjxnb29uXz4g
ICAgIHJlbG9jc2VjdGlvbiA9IHNlY3Rpb25tYXBbc2VjdGlvbm5hbWVdCjxnb29uXz4gQ0FOIElU
IEJFIFBZVEhPTiBSRUxBVEVEPwo8Z29vbl8+IHNvcnJ5Cjxnb29uXz4gUHJ5TWFyNTYsIGNhbiBp
dCBiZSB0aHp0IEkgbmVlZCB0byBwb2ludCB0byBweXRob24gcmVnYXJkaW5nIHRoZSBTZWFiaW9z
IHBhcnQKPGdvb25fPiBQcnlNYXI1NiwgaXQncyB0aGUgbG9jYWxlIGJ1ZmcKPGdvb25fPiA6LyBy
ZXBvcnRlZCBmb3Igc2VhYmlvcyBhbmQgNC4yLCBJIGhhdmUgZnJlbmNoIGtleWJvYXJkCjxnb29u
Xz4gOigKPGdvb25fPiBQcnlNYXI1Niwgc3R1cGlkLCBhcyB1c3VhbAo8Z29vbl8+IFByeU1hcjU2
LCBJIG1lYW4gc3R1cGlkIGJ1Z3MsIGFuZCBtZQoqIEd1ZXN0ODQ0NDQgcydhcHBlbGxlIG1haW50
ZW5hbnQgc2FyaWQKKiBzYXJpZCBlc3QgcGFydGkgKENoYW5naW5nIGhvc3QpCiogc2FyaWQgKH5z
YXJpZEB1bmFmZmlsaWF0ZWQvc2FyaWQpIGEgcmVqb2ludCAjeGVuCiogc3BoZW54ZXMgZXN0IHBh
cnRpIChSZW1vdGUgaG9zdCBjbG9zZWQgdGhlIGNvbm5lY3Rpb24pCjxnb29uXz4gT2sgaXQgaXMg
YnVpbGRpbmcgYmV5b25kIHRoZSBmaXJtd2FyZSBwb2ludCBub3cKKiByeWFuLWF1ICh+cXVhc3Nl
bEAxNzIuYnJzMDEwOS5icnMuaXByaW11cy5uZXQuYXUpIGEgcmVqb2ludCAjeGVuCiogZmFuZGkg
ZXN0IHBhcnRpIChRdWl0OiBMZWF2aW5nKQoqIGdlYWFydSBlc3QgcGFydGkgKFF1aXQ6IExlYXZp
bmcpCiogZGFyaW9mICh+ZGFyaW9mQG5ldC0yLTM5LTcwLTEwMy5jdXN0LnZvZGFmb25lZHNsLml0
KSBhIHJlam9pbnQgI3hlbgoqIGRhcmlvZiAofmRhcmlvZkBuZXQtMi0zOS03MC0xMDMuY3VzdC52
b2RhZm9uZWRzbC5pdCkgYSBxdWl0dMOpICN4ZW4KKiBnb29uaWVCIGVzdCBwYXJ0aSAoUmVhZCBl
cnJvcjogQ29ubmVjdGlvbiByZXNldCBieSBwZWVyKQoqIETDqWNvbm5lY3TDqSAoQ29ubmV4aW9u
IHLDqS1pbml0aWFsaXPDqWUgcGFyIGxlIGNvcnJlc3BvbmRhbnQpLgoqIGdvb24gZXN0IGTDqWrD
oCB1dGlsaXPDqS4gUsOpZXNzYWkgYXZlYyBnb29uXy4uLgoqIGdvb25fIGFjdGl2ZSBsZSBtb2Rl
ICtpIGdvb25fCiogVm91cyBwYXJsZXogbWFpbnRlbmFudCBzdXIgI3hlbgoqIExlIHN1amV0IGRl
ICN4ZW4gZXN0wqA6IFhlbiA0LjQuMSByZWxlYXNlZCEgaHR0cDovL3d3dy54ZW5wcm9qZWN0Lm9y
Zy9kb3dubG9hZHMuaHRtbCB8IFdpa2k6IGh0dHA6Ly93aWtpLnhlbnByb2plY3Qub3JnLyB8IEZB
UTogaHR0cDovL3dpa2kueGVucHJvamVjdC5vcmcvd2lraS9YZW5fQ29tbW9uX1Byb2JsZW1zCiog
U3VqZXQgZGUgI3hlbiBkw6lmaW5pIHBhciBLZXZpbmAgbGUgV2VkIFNlcCAgMyAyMzoyNzozNyAy
MDE0CiogW05vQ2xhbl1Hb0F3YXkgKH5Db21lQWdhaW5ANS4xOTkuMTYyLjE0KSBhIHF1aXR0w6kg
I3hlbiAoIlZlcmxhc3NlbmQiKQoqIETDqWNvbm5lY3TDqSAoQ29ubmV4aW9uIHLDqS1pbml0aWFs
aXPDqWUgcGFyIGxlIGNvcnJlc3BvbmRhbnQpLgoqIFZvdXMgcGFybGV6IG1haW50ZW5hbnQgc3Vy
ICN4ZW4KKiBMZSBzdWpldCBkZSAjeGVuIGVzdMKgOiBYZW4gNC40LjEgcmVsZWFzZWQhIGh0dHA6
Ly93d3cueGVucHJvamVjdC5vcmcvZG93bmxvYWRzLmh0bWwgfCBXaWtpOiBodHRwOi8vd2lraS54
ZW5wcm9qZWN0Lm9yZy8gfCBGQVE6IGh0dHA6Ly93aWtpLnhlbnByb2plY3Qub3JnL3dpa2kvWGVu
X0NvbW1vbl9Qcm9ibGVtcwoqIFN1amV0IGRlICN4ZW4gZMOpZmluaSBwYXIgS2V2aW5gIGxlIFdl
ZCBTZXAgIDMgMjM6Mjc6MzcgMjAxNAoqIGRlbW9ua2VlcGVyIHMnYXBwZWxsZSBtYWludGVuYW50
IGRhZW1vbmtlZXBlcgoqIE9zZW5wYWkgKH5Pc2VucGFpQDE5MS4yNDkuNy4xNDMpIGEgcmVqb2lu
dCAjeGVuCiogcnRzcndyICh+c3J3ckAxOTIuMTYyLjEwMS4xNSkgYSByZWpvaW50ICN4ZW4KKiB0
b2Rkd2FyZHppbnNraSAofnRvZGR3YXJkekAxMzcuc3ViLTcwLTE5Mi0yMDYubXl2encuY29tKSBh
IHJlam9pbnQgI3hlbgoqIHBhamFtaWFuIHMnYXBwZWxsZSBtYWludGVuYW50IHBqCiogcnRzcndy
IGVzdCBwYXJ0aSAoUGluZyB0aW1lb3V0OiAyNTggc2Vjb25kcykKKiBydHNyd3IgKH5zcndyQDE3
OC44Ni4xMy4yMzQpIGEgcmVqb2ludCAjeGVuCiogZmFuZGkgZXN0IHBhcnRpIChQaW5nIHRpbWVv
dXQ6IDI0NSBzZWNvbmRzKQoqIGNvb2xkaGFybWEwNiBlc3QgcGFydGkgKFF1aXQ6IENoYXRaaWxs
YSAwLjkuOTEuMSBbSWNld2Vhc2VsIDIxLjAvMjAxMzA1MTUxNDAxMzZdKQoqIGZhbmRpICh+ZmFu
ZGlAMTAxLjI1NS4zNi42NikgYSByZWpvaW50ICN4ZW4KKiBmYW5kaSBlc3QgcGFydGkgKEV4Y2Vz
cyBGbG9vZCkKKiBmYW5kaSAofmZhbmRpQDEwMS4yNTUuMzYuNjYpIGEgcmVqb2ludCAjeGVuCiog
dG9kZHdhcmR6aW5za2lfICh+dG9kZHdhcmR6QHBvb2wtNzItODMtMTEtNTYud2FzaGRjLmZpb3Mu
dmVyaXpvbi5uZXQpIGEgcmVqb2ludCAjeGVuCiogdG9kZHdhcmR6aW5za2kgZXN0IHBhcnRpIChQ
aW5nIHRpbWVvdXQ6IDI0MCBzZWNvbmRzKQoqIHF1ZWVxIGVzdCBwYXJ0aSAoUGluZyB0aW1lb3V0
OiAyNTggc2Vjb25kcykKKiBmaXJlZ2xvdyAoZmlyZWdsb3dAdW5hZmZpbGlhdGVkL2ZpcmVnbG93
KSBhIHJlam9pbnQgI3hlbgoqIHF1ZWVxICh+cXVlZXFAODAuMjU1LjY0LjIxNSkgYSByZWpvaW50
ICN4ZW4KKiBxdWVlcSBlc3QgcGFydGkgKENoYW5naW5nIGhvc3QpCiogcXVlZXEgKH5xdWVlcUB1
bmFmZmlsaWF0ZWQvcXVlZXEpIGEgcmVqb2ludCAjeGVuCiogRMOpY29ubmVjdMOpIChDb25uZXhp
b24gcsOpLWluaXRpYWxpc8OpZSBwYXIgbGUgY29ycmVzcG9uZGFudCkuCiogVm91cyBwYXJsZXog
bWFpbnRlbmFudCBzdXIgI3hlbgoqIExlIHN1amV0IGRlICN4ZW4gZXN0wqA6IFhlbiA0LjQuMSBy
ZWxlYXNlZCEgaHR0cDovL3d3dy54ZW5wcm9qZWN0Lm9yZy9kb3dubG9hZHMuaHRtbCB8IFdpa2k6
IGh0dHA6Ly93aWtpLnhlbnByb2plY3Qub3JnLyB8IEZBUTogaHR0cDovL3dpa2kueGVucHJvamVj
dC5vcmcvd2lraS9YZW5fQ29tbW9uX1Byb2JsZW1zCiogU3VqZXQgZGUgI3hlbiBkw6lmaW5pIHBh
ciBLZXZpbmAgbGUgV2VkIFNlcCAgMyAyMzoyNzozNyAyMDE0CjxQcnlNYXI1Nj4gNC41IEhFQUQ6
IHBvc3QgcmM0IGJ1ZyBsaWJ4bDogZXJyb3I6IGxpYnhsX2RvbS5jOjM2OmxpYnhsX19kb21haW5f
dHlwZTogdW5hYmxlIHRvIGdldCBkb21haW4gdHlwZSBmb3IgZG9taWQ9Nwo8UHJ5TWFyNTY+IG5v
IFZtIGNhbiBzdGFydAoqIHNlYmEgZXN0IHBhcnRpIChFeGNlc3MgRmxvb2QpCjxwYXNpaz4gUHJ5
TWFyNTY6IHlvdSBzaG91bGQgcmVwb3J0IGJ1Z3MgdG8geGVuLWRldmVsIG1haWxpbmdsaXN0Li4K
PFByeU1hcjU2PiBwYXNpaywgY29tcG9zaW5nIG5vdwo8cGFzaWs+IGdvb2Q6KQo8cGFzaWs+IFBy
eU1hcjU2OiB5b3Ugc3VyZSB5b3UgcmVtb3ZlZCBhbGwgdGhlIHByZXZpb3VzIHhlbiBiaXRzIGJl
Zm9yZSB1cGdyYWRpbmcgdG8gcmM0KyB2ZXJzaW9uPwo8cGFzaWs+IFByeU1hcjU2OiBzbyBpdCdz
IG5vdCBidWlsZC9pbnN0YWxsYXRpb24gaXNzdWU/CiogR3JvcGlfXyBlc3QgcGFydGkgKFF1aXQ6
IFZlcmxhc3NlbmQpCiogc2ViYSAofnNlYmFAa3JhdHpiYXVtLnNvbWVzZXJ2ZXIuZGUpIGEgcmVq
b2ludCAjeGVuCjxQcnlNYXI1Nj4gZXZlcnl0aW1lIEkgdGVzdCBJIGRpc2FibGUgYWxsIHhlbnNl
cnZpY2VzLCBhbmQgeXVtIHVuaW5zdGFsbCB4ZW4qCjxQcnlNYXI1Nj4gYW5kIGluc3RhbGwgd2l0
aCB0aGUgbmV3IHJwbSBzZXQKKiBkd2ZyZWVkIHdvdWxkIGp1c3QgcmVkZXBsb3kgdGhlIGhvc3QK
KiBvbWFycnIgZXN0IHBhcnRpIChRdWl0OiBMZWF2aW5nKQo8YnJhbV8+IDIyCjxQcnlNYXI1Nj4g
dG8gbWFrZSBwb3N0IHJjNCBwYXRjaDogZ2l0IGRpZmYgeGVuLTQuNS4wLXJjNCA+IGhlYWQ0NS5w
YXRjaAo8UHJ5TWFyNTY+IHRoZW4gYXBwbHkgaXQgdG8gcmM0IHRhcmJhbGwKPFByeU1hcjU2PiBu
b3Qgc3VyZSB0aGF0IGlzIDEwMCUgcmlnaHQKKiBzZWJhIGVzdCBwYXJ0aSAoRXhjZXNzIEZsb29k
KQoqIHNlYmEgKH5zZWJhQGtyYXR6YmF1bS5zb21lc2VydmVyLmRlKSBhIHJlam9pbnQgI3hlbgo8
UHJ5TWFyNTY+IGl0cyB0aGUgc2FtZSBhcyBgZ2l0IGRpZmYgNjBjZTUxOGExYmAKKiBGYW50dSBl
c3QgcGFydGkgKFF1aXQ6IENoYXRaaWxsYSAwLjkuOTEuMSBbRmlyZWZveCAzNC4wLjUvMjAxNDEx
MjYwNDEwNDVdKQoqIENyb3RoZXJzICh+Y3JvdGhlcnNAdW5hZmZpbGlhdGVkL2Nyb3RoZXJzKSBh
IHJlam9pbnQgI3hlbgoqIGl2YW5cIGVzdCBwYXJ0aSAoUGluZyB0aW1lb3V0OiAyNDQgc2Vjb25k
cykKKiBpdmFuXCAofml2YW5AdW5hZmZpbGlhdGVkL2l2YW4veC0wMDAwMDEpIGEgcmVqb2ludCAj
eGVuCiogYW5kZXJzb25jMGQzIGVzdCBwYXJ0aSAoUGluZyB0aW1lb3V0OiAyNTggc2Vjb25kcykK
KiBLYWJha2EgKGthYmFrYUBlcXVpbmUudmFjYW50bWluZGVkLmNvbSkgYSByZWpvaW50ICN4ZW4K
KiBWb3VzIHBhcmxleiBtYWludGVuYW50IHN1ciAjeGVuCiogTGUgc3VqZXQgZGUgI3hlbiBlc3TC
oDogWGVuIDQuNC4xIHJlbGVhc2VkISBodHRwOi8vd3d3LnhlbnByb2plY3Qub3JnL2Rvd25sb2Fk
cy5odG1sIHwgV2lraTogaHR0cDovL3dpa2kueGVucHJvamVjdC5vcmcvIHwgRkFROiBodHRwOi8v
d2lraS54ZW5wcm9qZWN0Lm9yZy93aWtpL1hlbl9Db21tb25fUHJvYmxlbXMKKiBTdWpldCBkZSAj
eGVuIGTDqWZpbmkgcGFyIEtldmluYCBsZSBXZWQgU2VwICAzIDIzOjI3OjM3IDIwMTQKPFByeU1h
cjU2PiBwYXRjaGVkIHJjNCB3b3JrcyBpbiBkZWI4Li4gbXVzdCBiZSBhbiBlcnJvciBpbiBwYWNr
YWdpbmcgb24gQzcgdGhhdCBicm9rZSB4ZW4KPFByeU1hcjU2PiBhbmQgaXRzIG15IGVycm9yIGFu
ZCBvbmx5IG15IGVycm9yCjxnb29uXz4gaGVsbG8gdGhlcmUsIGNvbXBpbGVkIDQuNSB4bCB3ZW50
IG9rIGF0IGxhc3QsIEkgdHJ5ZWQgdG8gaW5zdGFsbCBpdCB2aWEgZGViYmFsbCBhbmQgZHBrZywg
aXQKPFByeU1hcjU2PiBoaQo8UHJ5TWFyNTY+IGdvb25fLCBzYXcgeW91ciBwb3N0IG9uIHhlbi1k
ZXZlbCBhbmQgdHJpZWQgdG8gZm9sbG93IGFsb25nCjxnb29uXz4gUHJ5TWFyNTYsIGhpLCBzbyB0
cnlpbmcgdG8gaW5zdGFsbCB3b3JrcyBidXQgSSBneXVlc3MgaSBoYXZlIGxpYnJhcnkgcHJvYmxl
bXM6bGlieGw6IGVycm9yOiBsaWJ4bC5jOjEwOTpsaWJ4bF9jdHhfYWxsb2M6IGNhbm5vdCBvcGVu
IGxpYnhjIGhhbmRsZTogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQo8Z29vbl8+IGNhbm5vdCBp
bml0IHhsIGNvbnRleHQKPFByeU1hcjU2PiBkZWJiYWxsID09IGBtYWtlIGRpc3RgICsgYGZha2Vy
b290ICQocHdkKSA0LjUuMC1yYzRgCjxnb29uXz4gUHJ5TWFyNTYsIHNvIHlvdSBwYXRjaGVkIGFz
IHdlbGwgYW5kPyAuLi4KPFByeU1hcjU2PiBnb29uXywgSSBhbSBwYXRjaGluZyBmcm9tIDQuNSBI
RUFEIG9uIHJjNCwgbm90IHRyeWluZyB0byBnZXQgcXhsIHVwLCBhbHRob3VnaCBJIGVuYWJsZSBz
cGljZQo8Z29vbl8+IFByeU1hcjU2LCB3aHkgbm90IGVuYWJsaW5nIGl0IGJ5IGRlZmF1bHQsIHRo
aXMgSSBkb24ndCBnZXQgaXQuLgo8UHJ5TWFyNTY+IGdvb25fLCB0cnkgdGhpczogZm9yIGkgaW4g
eGwgb3hlbnN0b3JlZCBxZW11LXN5c3RlbS1pMzg2O2RvIHN1ZG8gbGRkICQod2hpY2ggJGkpOyBk
b25lCjxQcnlNYXI1Nj4gXl4gdmVyaWZ5cyB5b3VyIHJvb3QgcGF0aCBhbmQgbGliIHBhdGgKPFBy
eU1hcjU2PiBkZWJiYWxsID09IGBtYWtlIGRpc3RgICsgYGZha2Vyb290IC4vdG9vbHMvbWlzYy9t
a2RlYiAkKHB3ZCkgNC41LjAtcmM0YAo8Z29vbl8+IFByeU1hcjU2LCBodHRwOi8vcGFzdGViaW4u
Y29tL1ZVOW5iSnlIIGlzIHRoZSByZXN1bHQgb2YgbGliIGNoZWNrcyB3aXRoIGZvciBpIGluIHhs
IG94ZW5zdG9yZWQgcWVtdS1zeXN0ZW0taTM4NjtkbyBzdWRvIGxkZCAkKHdoaWNoICRpKTsgZG9u
ZQo8Z29vbl8+IFByeU1hcjU2LCBJJ3ZlIHJlYWQgdGhlcmUgYXJlIHRoaW5ncyB0byBzZXR1cCBy
ZWdhcmRpbmcgbGlicy4uLgo8UHJ5TWFyNTY+IGdvb25fLCB0ZXN0IHBhc3NlcyBwZXJmZWN0Cjxn
b29uXz4gQnVpbGQgcGFzc2VzIHBlcmZlY3RseSBmb3IgbWUgeWVzCjxQcnlNYXI1Nj4geW91ciBy
b290IHBhdGggYW5kIGxpYiBwYXRoIGlzIHNldHVwIGdvb2QgZm9yIHhlbgo8UHJ5TWFyNTY+IEkg
Y2FuIHNlZSB0aGF0IGluIHlvdXIgcGFzdGViaW4KPGdvb25fPiBzbyB3aGF0J3MgdGhlIGlzc3Vl
IHdpdGggbGlieGMgaGFuZGxlCjxnb29uXz4gPwo8UHJ5TWFyNTY+IHlvdXIgZ2V0IGVycm9yIG9u
IHB2IGFuZCBodm0gdHlwZSBWTT8KPFByeU1hcjU2PiBxeGwgaXMgZm9yIGh2bSBkb21VLCBidXQg
dHJ5IHRlc3RpbmcgYSBwdiBkb21VIHRvbwo8Z29vbl8+IGEgc2ltcGxlIHhsIGxpc3QgZ2l2ZXMg
bWUgbGlieGw6IGVycm9yOiBsaWJ4bC5jOjEwOTpsaWJ4bF9jdHhfYWxsb2M6IGNhbm5vdCBvcGVu
IGxpYnhjIGhhbmRsZTogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQo8UHJ5TWFyNTY+IGRlYjgg
KGplc3NpZSkgb3IgaGlnaGVyPwo8Z29vbl8+IGRlYjggdW5zdGFibGUKPFByeU1hcjU2PiB0aGF0
IGxvb2tzIGxpa2Ugbm8gaHlwZXJ2aXNvcgo8UHJ5TWFyNTY+IGxzbW9kIHwgZ3JlcCB4ZW4gaXMg
ZW1wdHk/Cjxnb29uXz4gUHJ5TWFyNTYsIHllcwo8Z29vbl8+IHdoaWNoIHBhY2thZ2VzIHNob3Vs
ZCBJIHJlbW92ZSBmcm9tIHRoZSBzeXN0ZW0gYmVmb3JlIGluc3RhbGxpbmc/Cjxnb29uXz4gSSBy
ZW1vdmUgYSBidW5jaCBidSBsZWZ0IHRoZSBoeXBlcnZpc29yIGZyb20gNC40LjEKPFByeU1hcjU2
PiBnb29uXywgZ3JlcCB4ZW5mcyAvdXNyL2xpYi9tb2R1bGVzLWxvYWQuZC94ZW4uY29uZgo8Z29v
bl8+IHRoaW5raW5nIHRoZXknZCBjb2V4aXN0LCBzYW1lIHdheSBhcyBteSA0LjEgYW5kIDQuNC4x
IHRoYXQgSSBjYW4gcGljayBhdCBzdGFydHVwCjxnb29uXz4gUHJ5TWFyNTYsIG5vdGhpbmcgY29t
aW5nIG91dAo8UHJ5TWFyNTY+IGlmIHRoYXQgeGVuLmNvbmYgaXMgdGhlcmUsIHRoZW4gYXBwZW5k
IHhlbmZzCjxQcnlNYXI1Nj4gd2l0aG91dCBpdCwgeW91ciB4ZW4gc2VydmljZXMgd2lsbCBmYWls
IHRvIHN0YXJ0Cjxnb29uXz4gYnV0IHRoZSBmaWxlIGlzIG1pc3NpbmcsIHRvdWNoIGl0IGFuZCBh
ZGQgeGVuZnM/Ciogc3BoZW54ZXMgZXN0IHBhcnRpIChSZWFkIGVycm9yOiBDb25uZWN0aW9uIHJl
c2V0IGJ5IHBlZXIpCjxQcnlNYXI1Nj4gb2gsIGRvIG5vdGhpbmcgdW5sZXNzIHlvdSBhcmUgaW5z
dGFsbGluZyB0aGUgcmM0IGRlYiB3aXRoIHN5c3RlbWQKPGdvb25fPiBZZXMgSSBhZGRlZCBzeXN0
ZW1kLAo8UHJ5TWFyNTY+IGNoZWNrIHN1ZG8gZHBrZyAtTCB4ZW4tdXBzdHJlYW0gfCBncmVwIHhl
bi5jb25mCjxnb29uXz4gUHJ5TWFyNTYsIG5vdGhpbmcKPGdvb25fPiA6Lwo8UHJ5TWFyNTY+IGhv
dyBhYm91dDogZHBrZyAtbCB8IGdyZXAgeGVuCjxnb29uXz4gaHR0cDovL3Bhc3RlYmluLmNvbS9q
em4yTkhFYgo8UHJ5TWFyNTY+IHB1cmdlIGFsbCBhbmQgc3RhcnQgb3ZlciB3aXRoIDQuNQo8Z29v
bl8+IFByeU1hcjU2LCBhY3R1YWxseSB5b3Ugd3JvdGUgYSBMIGluc3RlYWQgb2YgYSBsCjxQcnlN
YXI1Nj4geW91IGhhdmUgdG9vIG11Y2ggZnJvbSA0LjQKKiBhcmVzY29ycGlvICh+YXJlc2NvcnBp
QDIxNy01Ny0yNDUtMTkwLmZpYmVydGVsLmNvbS5hcikgYSByZWpvaW50ICN4ZW4KPFByeU1hcjU2
PiBwdXJnZSBhbnl0aGluZyB4ZW4KPFByeU1hcjU2PiBzZXJpb3VzbHksIHlvdSBjYW4gZG8gYSBm
cmVzaCBpbnN0YWxsIHF1aWNrZXIgdGhhbiBiYWNraW5nIG91dCBhbGwgdGhlIG9sZCB4ZW4gKmRl
YnMKKiBza3lsaXRlIGVzdCBwYXJ0aSAoUXVpdDogVGV4dHVhbCBJUkMgQ2xpZW50OiB3d3cudGV4
dHVhbGFwcC5jb20pCjxnb29uXz4gb2ssIEkndmUgcHVyZ2VkLCBzbyBJIGp1c3QgZHBrZyAtaSB4
ZW4uLi4uLi47Cjxnb29uXz4gPwo8Z29vbl8+IFByeU1hcjU2LCAgdGhhbmsgeW91IEJUVwoqIE5v
dGlmeTogUHJ5TWFyNTYgZXN0IGVuIGxpZ25lIChGcmVlTm9kZSkuCjxnb29uXz4gUHJ5TWFyNTYs
IEkndmUgaW5zdGFsbGVkIHRoZSBwYWNrYWdlCjxnb29uXz4gc2hvdWxkIEkgcmVib290Pwo8UHJ5
TWFyNTY+IHRoYXQgdXBzdHJlYW0gZGViIHdpbGwgbm90IHNldHVwIGdydWIyLCBzbyBjaGVjayB0
aGF0IGZpcnN0Cjxnb29uXz4gaG93IGRvIEkgc2V0IGl0IHVwPwo8UHJ5TWFyNTY+IGdydWItbWs8
dGFiPiAgIDwtLSB3aWxkIGd1ZXNzCjxQcnlNYXI1Nj4gbHMgLWFsIC9ldGMvZ3J1Yi5kLwo8UHJ5
TWFyNTY+IGFueSAwOV8gPwo8Z29vbl8+IGdydWJfbWtjb25maWc/CjxQcnlNYXI1Nj4gZmlyc3Qg
Y2hlY2s6ICBscyAtYWwgL2V0Yy9ncnViLmQvCjxnb29uXz4gYWZ0ZXIgdGhhdCB0aGVyZSBpcyBv
bmUgKC1yd3hyLXhyLXggICAxIHJvb3Qgcm9vdCAxMDQxOCBkw6ljLiAgIDIgMjM6MDQgMDlfbGlu
dXhfeGVuCjxnb29uXz4gKQo8UHJ5TWFyNTY+IGluc2lkZSAwOV9saW51eF94ZW4gLi4uIGxvb2sg
Zm9yIHN5bWxpbmtzIGZvciB4ZW4uZ3oKPFByeU1hcjU2PiB5b3VyIGJvb3QgbWF5IHN0YXJ0IHhl
biBhcyB0aGluZyBhcmUsIGJ1dCBubyBndWFyYW50ZWUKPGdvb25fPiB3aWxsIGdpdmUgaXQgYSB0
cnksIGJlIGJhY2sgaW4gYSBtaW51dGUuLi5ob3BlZnVsbHkKKiBWb3VzIHBhcmxleiBtYWludGVu
YW50IHN1ciAjeGVuCiogTGUgc3VqZXQgZGUgI3hlbiBlc3TCoDogWGVuIDQuNC4xIHJlbGVhc2Vk
ISBodHRwOi8vd3d3LnhlbnByb2plY3Qub3JnL2Rvd25sb2Fkcy5odG1sIHwgV2lraTogaHR0cDov
L3dpa2kueGVucHJvamVjdC5vcmcvIHwgRkFROiBodHRwOi8vd2lraS54ZW5wcm9qZWN0Lm9yZy93
aWtpL1hlbl9Db21tb25fUHJvYmxlbXMKKiBTdWpldCBkZSAjeGVuIGTDqWZpbmkgcGFyIEtldmlu
YCBsZSBXZWQgU2VwICAzIDIzOjI3OjM3IDIwMTQKPGdvb25fPiB3ZWxsLCBpJ20gYmFjawo8UHJ5
TWFyNTY+IHRyeSB0aGlzIHNjcmlwdCB0byBlbmFibGUvZGlzYWJsZSB4ZW4gc2VydmljZXM6IGh0
dHA6Ly9wYXN0ZWJpbi5jb20vSEhoMGEyV2gKPFByeU1hcjU2PiBeXiBpdCBvbmx5IGFwcGxpZXMg
dG8gc3lzdGVtZCBzZXR1cCwgbm90IHN5c3YKPFByeU1hcjU2PiBhbHNvOiBjZCAvZXRjL2luaXQu
ZDsgbXYgeGVuZG9tYWlucyB4ZW5kb21haW5zLnN5c3YKPGdvb25fPiBQcnlNYXI1Niwgc2NyaXB0
IGdpdmVzIDQgRmFpbGVkIHRvIGV4ZWN1dGUgb3BlcmF0aW9uOiBObyBzdWNoIGZpbGUgb3IgZGly
ZWN0b3J5CjxQcnlNYXI1Nj4gZmluZCB5b3VyIHhlbi11cHN0cmVhbS4gZHBrZy1kZWIgLWMgeGVu
LXVwc3RyZWFtKiB8IGdyZXAgc3lzdGVtZAo8UHJ5TWFyNTY+IEkgZ2V0IDkgZW50cmllcwo8Z29v
bl8+IFByeU1hcjU2LCBzaG91bGQgdGhlIHNjcmlwdCBiZSBpbiAvZXRjL2luaXQuZCAgb3Igc29t
ZXRoaW5nPwo8Z29vbl8+IEkgaGF2ZSBub25lPwo8Z29vbl8+ICEKPFByeU1hcjU2PiBkcGtnIC1p
IHhlbi11cHN0cmVhbSoKPFByeU1hcjU2PiBkcGtnIC1sIHhlbi11cHN0cmVhbSB8IHdjIC1sICA8
LS0gYWJvdXQgODAwCjxQcnlNYXI1Nj4gICAtTAo8Z29vbl8+IDEwOAo8Z29vbl8+IDovCjxnb29u
Xz4gbm90IGZ1bGx5IGJ1aWx0IG9yIHNvPwo8UHJ5TWFyNTY+IG9oLCB5b3Ugb25seSBkaWQgbWFr
ZSBkaXN0LXRvb2xzCjxQcnlNYXI1Nj4geW91IHdhbnQgYG1ha2UgZGlzdGAKPFByeU1hcjU2PiBp
ZiB5b3UgYXJlIHRlc3RpbmcgdGhlIGZpcm13YXJlIGJ1aWxkLCBzdXJlLCBgbWFrZSBkaXN0LXRv
b2xzYCAgIDwtLSBpcyBlbm91Z2gKPGdvb25fPiBvdXBzLCBtYXliZSBJIHdhcyBkaXN0cmFjdGVk
LCBsZXQgbWUgc2VlCjxQcnlNYXI1Nj4gb24gbXkgNSB5ZWFycyBvbGQgaHcsIHhlbiBidWlsZHMg
aW4gMTcgbWludXRlcwo8UHJ5TWFyNTY+IGFuZCB0aGF0IGlzIG9uIERlYjgsIEM3IGlzIDIyIG1p
bnV0ZXMKPGdvb25fPiBJIGhhdmUgZG9uZSBhIG1ha2UgZGViYmFsbCAoIGlzbid0IHRoYXQgZW5v
dWdoPykKPGdvb25fPiBvayBzbyBtYWtlIGRpc3RjbGVhbiAvIC4vY29uZmlndXJlIGFuZCB0aGVu
IG1ha2UgZGlzdCBhbmQgdGhlbiBtYSxrZSBkZWJiYWxsPwo8UHJ5TWFyNTY+IHllcwo8UHJ5TWFy
NTY+IHlvdXIgY29uZmlndXJlIGlzIGNvbXBsaWNhdGVkIHBlciB3aGF0IEkgc2F3IG9uIHhlbi1k
ZXZlbCBNYWlsaW5nIGxpc3QKKiBpdmFuXCBlc3QgcGFydGkgKFBpbmcgdGltZW91dDogMjUyIHNl
Y29uZHMpCiogaXZhblwgKH5pdmFuQHVuYWZmaWxpYXRlZC9pdmFuL3gtMDAwMDAxKSBhIHJlam9p
bnQgI3hlbgo8Z29vbl8+IFByeU1hcjU2LCAgLS13aXRoLWV4dHJhLXFlbXVVLWNvbmZpZ3VyZS1h
cmdzICwgc2Vjb25kIFUgaW4gcWVtdSBpcyBub3QgYSB0eXBvLCByaWdodD8KPFByeU1hcjU2PiBy
aWdodAo8UHJ5TWFyNTY+IDJuZCBVIGlzIGZvciBxZW11IHVwc3RyZWFtCjxnb29uXz4gb2sgbWFr
aW5nIGRpc3QKPGdvb25fPiBJIHRoaW5rIEkgc2hvdWxkIGhhdmUgc2V0IGxvY2FsZSA6LwoqIGl2
YW5cIGVzdCBwYXJ0aSAoUGluZyB0aW1lb3V0OiAyNTggc2Vjb25kcykKKiBpdmFuXCAofml2YW5A
dW5hZmZpbGlhdGVkL2l2YW4veC0wMDAwMDEpIGEgcmVqb2ludCAjeGVuCjxnb29uXz4gZXhwb3J0
IExDX0FMTD1lbl9VUy5VVEYtOAo8Z29vbl8+IG91cHMgOykKPGdvb25fPiBhZ2Fpbi4udGhpcyB0
aW1lIEkgcmVtb3ZlIHN5c3RlbWQgYXMgd2VsbAoqIETDqWNvbm5lY3TDqSAoKS4KKiBnb29uXyBh
Y3RpdmUgbGUgbW9kZSAraSBnb29uXwoqIFZvdXMgcGFybGV6IG1haW50ZW5hbnQgc3VyICN4ZW4K
KiBMZSBzdWpldCBkZSAjeGVuIGVzdMKgOiBYZW4gNC40LjEgcmVsZWFzZWQhIGh0dHA6Ly93d3cu
eGVucHJvamVjdC5vcmcvZG93bmxvYWRzLmh0bWwgfCBXaWtpOiBodHRwOi8vd2lraS54ZW5wcm9q
ZWN0Lm9yZy8gfCBGQVE6IGh0dHA6Ly93aWtpLnhlbnByb2plY3Qub3JnL3dpa2kvWGVuX0NvbW1v
bl9Qcm9ibGVtcwoqIFN1amV0IGRlICN4ZW4gZMOpZmluaSBwYXIgS2V2aW5gIGxlIFdlZCBTZXAg
IDMgMjM6Mjc6MzcgMjAxNAo8Z29vbl8+IFByeU1hcjU2LCBTVElMTCBCVUlMRElORwoqIHBpZ2Vv
bl8gZXN0IHBhcnRpIChQaW5nIHRpbWVvdXQ6IDI2NSBzZWNvbmRzKQo8Z29vbl8+IFByeU1hcjU2
LCBvayBtYWtlIGRpc3QgaXMgZG9uZQoqIHBpZ2VvbiAofnBpZ2VvbkBldGg1Mjg0Lm5zdy5hZHNs
LmludGVybm9kZS5vbi5uZXQpIGEgcmVqb2ludCAjeGVuCjxQcnlNYXI1Nj4gZHUgLXMgLi9kaXN0
L2luc3RhbGwgIC0+IGFib3V0IDc0IE1CCjxQcnlNYXI1Nj4gIGBmYWtlcm9vdCAuL3Rvb2xzL21p
c2MvbWtkZWIgJChwd2QpIDQuNS4wLXJjNGAKPGdvb25fPiBQcnlNYXI1NiwgIDkwTWIgd2l0aCB0
aGUgZGVicwo8Z29vbl8+IGluc3RhbGxlZCBub3cKKiBWb3VzIHBhcmxleiBtYWludGVuYW50IHN1
ciAjeGVuCiogTGUgc3VqZXQgZGUgI3hlbiBlc3TCoDogWGVuIDQuNC4xIHJlbGVhc2VkISBodHRw
Oi8vd3d3LnhlbnByb2plY3Qub3JnL2Rvd25sb2Fkcy5odG1sIHwgV2lraTogaHR0cDovL3dpa2ku
eGVucHJvamVjdC5vcmcvIHwgRkFROiBodHRwOi8vd2lraS54ZW5wcm9qZWN0Lm9yZy93aWtpL1hl
bl9Db21tb25fUHJvYmxlbXMKKiBTdWpldCBkZSAjeGVuIGTDqWZpbmkgcGFyIEtldmluYCBsZSBX
ZWQgU2VwICAzIDIzOjI3OjM3IDIwMTQKPGdvb25fPiBQcnlNYXI1NiwgIGRwa2cgLWwgeGVuLXVw
c3RyZWFtIHwgd2MgLWwgc3RpbGwgZXF1YWxzIDEwOAo8Z29vbl8+IDovCjxnb29uXz4gIFByeU1h
cjU2ICwgc2VlbXMgbGlrZSB0aGUgbGlicyBkb24ndCBnZXQgY29tcGlsZWQsIG15IGFyY2hpdmUg
Y29udGFpbnMgbm90aGluZyBpbiAvdmFyL2xpYgo8Z29vbl8+IHRpcmVkIGZvciB0b2RheSwgd2ls
bCBnbyB0byBiZWQgKDMuMzAgQU0gaGVyZSkKPGdvb25fPiB0aGFuayB5b3UKPGdvb25fPiBpZiBh
bnkgaWRlYSwgeW91J3ZlIGdvdCBteSBtYWlsLgogUHl0aG9uIGludGVyZmFjZSB1bmxvYWRlZAog
VGNsIGludGVyZmFjZSB1bmxvYWRlZAoqIFZvdXMgcGFybGV6IG1haW50ZW5hbnQgc3VyICN4ZW4K
KiBMZSBzdWpldCBkZSAjeGVuIGVzdMKgOiBYZW4gNC40LjEgcmVsZWFzZWQhIGh0dHA6Ly93d3cu
eGVucHJvamVjdC5vcmcvZG93bmxvYWRzLmh0bWwgfCBXaWtpOiBodHRwOi8vd2lraS54ZW5wcm9q
ZWN0Lm9yZy8gfCBGQVE6IGh0dHA6Ly93aWtpLnhlbnByb2plY3Qub3JnL3dpa2kvWGVuX0NvbW1v
bl9Qcm9ibGVtcwoqIFN1amV0IGRlICN4ZW4gZMOpZmluaSBwYXIgS2V2aW5gIGxlIFdlZCBTZXAg
IDMgMjM6Mjc6MzcgMjAxNAo8Z29vbl8+IEhlbGxvIHRoZXJlLCB0cnlpZWQgcmVjb21waWxpbmcg
eGVuNC41IGZyb20gc2NyYXRjaCBmb2xsb3dpbmcgUkVBRE1FCjxnb29uXz4gdmFyIGRpcmVjdG9y
eSBpbnNpZGUgdGhlIGFyY2hpdmUgaXMgc3RpbGwgMCBvY3RlY3QKPGdvb25fPiBQcnlNYXI1Niwg
aSByZWRpcmVjdGVkIGVycm9ycyB0byBsb2cgZmlsZXMKPGdvb25fPiBJIGhhdmUgcGxlbnR5IG9m
IHRob3NlIHBlcmw6IHdhcm5pbmc6IEZhbGxpbmcgYmFjayB0byBhIGZhbGxiYWNrIGxvY2FsZSAo
ImZyX0ZSLlVURi04IikuCjxnb29uXz4gcGVybDogd2FybmluZzogU2V0dGluZyBsb2NhbGUgZmFp
bGVkLgo8Z29vbl8+IHBlcmw6IHdhcm5pbmc6IFBsZWFzZSBjaGVjayB0aGF0IHlvdXIgbG9jYWxl
IHNldHRpbmdzOgo8Z29vbl8+ICBMQU5HVUFHRSA9ICh1bnNldCksCjxnb29uXz4gIExDX0FMTCA9
ICJlbl9VUy51dGYtOCIsCjxnb29uXz4gIExBTkcgPSAiZnJfRlIuVVRGLTgiCjxnb29uXz4gICAg
IGFyZSBzdXBwb3J0ZWQgYW5kIGluc3RhbGxlZCBvbiB5b3VyIHN5c3RlbS4KPGdvb25fPiBidXQg
bm8gZXJyb3IKKiBhbmRlcnNvbmMwZDMgZXN0IHBhcnRpIChQaW5nIHRpbWVvdXQ6IDI3MiBzZWNv
bmRzKQo8am93cj4gbG9va3MgbGlrZSB5b3VyIGxvY2FsZSBpc24ndCBpbnRlcm5hbGx5IGNvbnNp
c3RlbnQKPHBhc2lrPiBQcnlNYXI1NjogaSBiZXQgbW9zdCBkZXZlbG9wZXJzIGFyZSBvbiBob2xp
ZGF5cyBiZXR3ZWVuIGNocmlzdG1hcyBhbmQgbmV3IHllYXJzCjxQcnlNYXI1Nj4gZ29vZCwgdGhl
eSBjYW4ndCBicmVhayA0LjUKPFByeU1hcjU2PiBpdCBidWlsZHMgYW5kIHdvcmtzIE9LCjxwYXNp
az4gaGVoCjxQcnlNYXI1Nj4gb24gZGViOCB0aGVyZSBpcyBhIG5ldyBmbGFnIHRvIHVzZTogLS13
aXRoLXN5c3RlbWQ9L2xpYi9zeXN0ZW1kL3N5c3RlbQo8UHJ5TWFyNTY+IG9uIC4vY29uZmlndXJl
Cjxnb29uXz4gUHJ5TWFyNTYsIGJ1dCBjYW4gc3VjaCBhIGZsYWcgY2F1c2Ugbm8gbGliIGluIHZh
ciBkaXIgb2YgZGViPz8KPGdvb25fPiBwYXNpaywgeWVzLCBJJ20gZnIuCjxQcnlNYXI1Nj4gZ29v
bl8sIGRwa2ctZGViIC4vZGlzdC94ZW4tdXBzdHJlYW0qLmRlYiB8IGdyZXAgdmFyICAgIDwtLSBl
bXB0eT8KPFByeU1hcjU2PiAgXl4gLWMKPGdvb25fPiBQcnlNYXI1NiwgeWVzCjxQcnlNYXI1Nj4g
ZHBrZy1kZWIgLWMKPFByeU1hcjU2PiB3aGF0IGlzIGxpbmUgY291bnQgb2YgcGFja2FnZSAqZGVi
Pwo8Z29vbl8+IFByeU1hcjU2LCBCVFcgbm8gZG91YnRzIGl0IGJ1aWxkcyBvaywgYnV0IG5vdCBv
biBteSBjcHUgOi8KPFByeU1hcjU2PiBnb29uXywgZHBrZy1kZWIgLWMgLi9kaXN0L3hlbi11cHN0
cmVhbSouZGViIHwgd2MgLWwKPGdvb25fPiA3NzYKPFByeU1hcjU2PiB0aGF0cyB2ZXJ5IGNsb3Nl
IHRvIG1pbmUsIGdyZXAgZm9yIHN5c3RlbWQKPFByeU1hcjU2PiBzaG91bGQgYmUgYWJvdXQgMTAK
PFByeU1hcjU2PiBnb29uXywgZG8geW91IG5lZWQgRUZJIGJvb3Qgc3VwcG9ydCBpbiBYZW4/Cjxn
b29uXz4gUHJ5TWFyNTYsIG5vdCByZWFsbHkgCjxnb29uXz4gUHJ5TWFyNTYsICBpcyB0aGVyZSBh
IGJ1aWxkIFhYWCB0byBidWlsZCBsaWJzPwo8Z29vbl8+IFByeU1hcjU2LCBvaywgbWF5YmUgaXQn
cyB0aGUgcGF0Y2ggZnJvbSBmYW50dSBJIHRyaWVkIHRvIGFkZCwKPFByeU1hcjU2PiBnb29uXywg
IG9uIERlYjggYWx3YXlzIHBhc3MgLS1saWJkaXI9L3Vzci9saWIKPFByeU1hcjU2PiBnb29uXywg
dG8gZml4IHRoZSBtaXNzaW5nIC92YXIgaXNzdWUgLCBkbyB0aGlzCjxnb29uXz4gb2ssIHNvIG15
IGNvbmZpZ3VyZSBsaW5lLCB3aGF0IGl0IHNob3VsZCBiZT8KPFByeU1hcjU2PiBJIGdhdmUgdG8g
ZmxhZ3MgYWxyZWFkeSB0aGF0IHlvdSBtaWdodCBoYXZlIG1pc3NlZAo8UHJ5TWFyNTY+IDIgZmxh
Z3MKPGdvb25fPiBQcnlNYXI1NiwgSSdsbCB0cnkgd2l0aCAuL2NvbmZpZ3VyZSAtLXdpdGgtZXh0
cmEtcWVtdXUtY29uZmlndXJlLWFyZ3M9Ii0tZW5hYmxlLXNwaWNlIC0tZW5hYmxlLXVzYi1yZWRp
ciIgIC0td2l0aC1zeXN0ZW1kPS9saWIvc3lzdGVtZC9zeXN0ZW0gLS1saWJkaXI9L3Vzci9saWIK
PFByeU1hcjU2PiAtLXByZWZpeD0vdXNyCjxnb29uXz4gUHJ5TWFyNTYsIG9rLCBJJ2xsIGNoZWNr
IHRoYXQKPFByeU1hcjU2PiBjZCAuL2Rpc3QvaW5zdGFsbDsgbWtkaXIgdmFyIDtta2RpciAtcCAv
dmFyL2xpYi94ZW4vcGFnaW5nOyBta2RpciAtcCAvdmFyL2xpYi94ZW5zb3RyZWQ7IG1rZGlyIC1w
IC92YXIvbG9nL3hlbjtta2RpciAtcCAvdmFyL3hlbi9kdW1wCjxnb29uXz4gUHJ5TWFyNTYsIGNh
biBJIHVzZSBjY2FjaGUgZm9yIGZhc3RlciBidWlsZD8KPFByeU1hcjU2PiB0aG9zZSBkaXIgYXJl
IGFsbCBlbXB0eQo8UHJ5TWFyNTY+IHhlbnN0b3JlZAo8UHJ5TWFyNTY+IGdvb25fLCBydW4gdGhv
c2UgY21kcyBhcyB1c2VyLCBNaWdodCBuZWVkIGEgcHJlZml4IC4KPFByeU1hcjU2PiB5ZWFoIHVz
ZSB0aGUgcHJlZml4CjxQcnlNYXI1Nj4gZ29vbl8sIG5ldmVyIHRyaWVkIHRoYXQgdG9vbCBjY2Fj
aGUuLiBidXQgdGhlIGJ1aWxkIHNob3VsZCB0YWtlIDEwLTE1IG1pbnV0ZXMgb3IgbGVzcwo8Z29v
bl8+IG1ha2Ugd29ybGQ/IG1ha2UgaW5zdGFsbD8gbWFrZSBkaXN0IG1ha2UgZGViYmFsbD8KPFBy
eU1hcjU2PiBnb29uXywgSSBkbyBgbWFrZSBkaXN0YCB0aGVuIG9uY2UgSSBzZWUgYSBnb29kIGJ1
aWxkLCBJIGVkaXQgdGhlIC4vZGlzdC9pbnN0YWxsIGEgYml0LCB0aGVuIGBmYWtlcm9vdCAuL3Rv
b2xzL21pc2MvbWtkZWIgJChwd2QpIDQuNS4wLXJjNGAKPFByeU1hcjU2PiBnb29uXywgaWYgYnVp
bGQgbG9va3MgT0ssIGJ1dCB0aGVyZSBhcmUgbWlub3IgcHJvYmxlbXMgaW4gL2Rpc3QvaW5zdGFs
bC8qLiBHbyBhaGVhZCBhbmQgZml4IHRoZW0sIHRoZW4gcnVuIHRoZSBta2RlYiBzY3JpcHQuIE5v
IG5lZWQgdG8ga2VlcCByZWJ1aWxkaW5nIHd0aCBtYWtlIGRlYmJhbGwKPFByeU1hcjU2PiBpdHMg
cGVyZmVjdGx5IE9LLCBjZCBpbnRvIHRoZSBidWlsZCBhbmQgdHJpbSBvciBjcmVhdGUgZGlyIGFz
IG5lZWRlZAo8UHJ5TWFyNTY+IEkgY3JlYXRlIDIgZGlyIGluIC4vZGlzdC9pbnN0YWxsIGJlZm9y
ZSBJIGJ1aWxkCjxQcnlNYXI1Nj4gb25lIGZvciBFRkkgYW5kIG9uZSBmb3Igc3R1YmxpYgo8UHJ5
TWFyNTY+IGlmIEkgZG9uJ3QgdGhleSBhcmUgbm90IHBvcHVsYXRlZCBhcyBuZWVkZWQKPGdvb25f
PiB3ZWxsIEkgbGF1bmNoZWQgYSBtYWtlIHdvcmxkLCBzbyB0aGVyZSBhcmUgYSBmZXcgdGhpbmdz
IHRvIGRvIG1hbnVhbGx5IG9uIGluc3RhbGwuLi4gVGhvc2UgcHJlY2lvdXMgYWR2aWNlcyBzaG91
bGQgYmUgc29tZXdoZXJlIG9uIHRoZSB3aWtpCjxQcnlNYXI1Nj4gdGhlcmUgYXJlIHBhcnRzIG9m
IHRoZSBidWlsZCB0aGF0IGNhbiBzaWxlbnRseSBmYWlsLCBsaWtlIEVGSS4gdGhlIGJ1aWxkIHN0
aWxsIGNvbnRpbnVlcwoqIGRhbHRlbyAofm1pY2hhZWxAY2FyMzQtMS04OC0xNjgtMTE3LTMwLmZi
eC5wcm94YWQubmV0KSBhIHF1aXR0w6kgI3hlbgo8UHJ5TWFyNTY+IG5vIHdhcm5pbmdzCjxQcnlN
YXI1Nj4gSWYgYSBwYXJ0IG9mIHRoZSBidWlsZCBmYWlscyBvciBnaXZlcyB3YXJuaW5ncywgZG9u
J3QgZ2V0IG1hZC4uIHRoYXQgaXMgZ29vZCBmb3IgdGhlIHVzZXIKPGdvb25fPiBQcnlNYXI1Niwg
eWVzIHRoYXQncyBpdCwgbm90IGV2ZW4gYSB3YXJuaW5nIGlzIGEgYml0IHJ1ZGUgZm9yIHRoZSB1
c2VyIG9uIHRoZSBvcHBvc2l0ZSA6Lwo8Z29vbl8+IDspCjxnb29uXz4gd2VsbCAsIG1ha2Ugd29y
bGQgZ2F2ZSBtZSBlcnJvcjogaHR0cDovL3Bhc3RlYmluLmNvbS9RbUpxTTFWVQoqIGtlcm1pdCBl
c3QgcGFydGkgKFF1aXQ6IExlYXZpbmcuKQo8UHJ5TWFyNTY+IGFueSBwYXRjaGVzIGFnYWluc3Qg
c2VhYmlvcz8KKiBrZXJtaXQgKHVua25vd25AcGRwYy9zdXBwb3J0ZXIvYnJvbnplL2tlcm1pdCkg
YSByZWpvaW50ICN4ZW4KPGdvb25fPiBQcnlNYXI1NiwgTWU/IG5vCjxQcnlNYXI1Nj4gZ29vbl8s
IHRyeSBhcHQtZ2V0IGJ1aWxkLWRlcCB4ZW4gIDwtLSBzZWUgaWYgYW55IHBhY2thZ2VzIGNvbWUg
dXAKPFByeU1hcjU2PiByZWZ1c2UgdGhlIHNlYWJpb3MKPFByeU1hcjU2PiAgJiBgYXB0LWdldCBi
dWlsZC1kZXAgc2VhYmlvc2AKPGdvb25fPiBxeGwgcGF0Y2ggZnJvbSBmYW50dT8KPGdvb25fPiBi
eSByZWZ1c2UgeW91IG1lYW4gdW5pbnN0YWxsCjxQcnlNYXI1Nj4gdGhlIGJ1aWxkLWRlcCBjbWQK
PGdvb25fPiBub3RoaW5nCjxQcnlNYXI1Nj4gcmVjb25maWd1cmUgYW5kIC0tZGlzYWJsZS1yb21i
aW9zCiogZ2FuZGFsaXRlciBlc3QgcGFydGkgKFBpbmcgdGltZW91dDogMjU1IHNlY29uZHMpCjxQ
cnlNYXI1Nj4gZ3JlcCAuL2NvbmZpZy8qLm1rIC0+IC4vY29uZmlnL1Rvb2xzLm1rOkNPTkZJR19S
T01CSU9TICAgICAgOj0geQoqIEZhbnR1IGVzdCBwYXJ0aSAoUXVpdDogQ2hhdFppbGxhIDAuOS45
MS4xIFtGaXJlZm94IDM0LjAuNS8yMDE0MTEyNjA0MTA0NV0pCjxnb29uXz4gRmFudHUncyBjb25m
IHBhcmFtOiAuL2NvbmZpZ3VyZSAtLXByZWZpeD0vdXNyIC0tZGlzYWJsZS1ibGt0YXAxIC0tZGlz
YWJsZS1xZW11LXRyYWRpdGlvbmFsCjxnb29uXz4gLS1kaXNhYmxlLXJvbWJpb3MgLS13aXRoLXN5
c3RlbS1zZWFiaW9zPS91c3Ivc2hhcmUvc2VhYmlvcy9iaW9zLTI1NmsuYmluCjxnb29uXz4gLS13
aXRoLWV4dHJhLXFlbXV1LWNvbmZpZ3VyZS1hcmdzPSItLWVuYWJsZS1zcGljZSAtLWVuYWJsZS11
c2ItcmVkaXIiCjxnb29uXz4gLS1kaXNhYmxlLWJsa3RhcDIKPFByeU1hcjU2PiBnb29uXywgSSBz
ZWUgaXRzIHRyeWluZyB0byBjcmVhdGUgYSAxNmJpdCByb21iaW9zPyBtaW5lIG9ubHkgaGFzIGEg
MzJiaXQKPGdvb25fPiBQcnlNYXI1NiwgeWVzLCB3aHkgaXMgdGhhdD8KPFByeU1hcjU2PiBJIGFt
IGdvb2QgZm9yIG9uZSBvciB0d28gKGF0IG1vc3QpIG15c3RlcmllcyBsaWtlIHRoYXQgcGVyIGRh
eS4KPFByeU1hcjU2PiByZXF1aXJlcyBxdWl0ZSBhIGJpdCBvZiBnb29nbGluZyBhbmQgY29kZSBy
ZWFkaW5nCjxnb29uXz4gSSBub3RpY2VkIHRoYXQsIGl0IHdhcyBhY3R1YWx5IHdoZXJlIEkgYWRk
IHRvIGVuZm9yZSBMQz1Vcy4KPFByeU1hcjU2PiBmb2xsb3cgRmFudHU6IGlmIHlvdSBjYW4gdXNl
IHRoZSBkaXN0cm8gc2VhYmlvcywgdGhlbiBnbyB0aGF0IHdheQo8UHJ5TWFyNTY+IGdvb25fLCB3
aGF0IENQVSBpcyBpdD8KPGdvb25fPiBQcnlNYXI1NiwgSTcgMzY4N1UKPGdvb25fPiBQcnlNYXI1
NiwgSSdsbCB0cnkgZmFudHUncyB3YXkKPGdvb25fPiBzZWUgaG93IGl0IGdvZXMKKiBvbWFycnIg
ZXN0IHBhcnRpIChSZW1vdGUgaG9zdCBjbG9zZWQgdGhlIGNvbm5lY3Rpb24pCjxnb29uXz4gUHJ5
TWFyNTYsIHNvcnJ5IGZvciBnaXZpbmcgeW91IGEgaGFyZCB0aW1lCjxQcnlNYXI1Nj4gZ29vbl8s
IEkgYW0gbWFraW5nIHByb2dyZXNzIG9uIGEgcHJvcGVyIGRlYjggYnVpbGQgYmVjYXVzZSBvZiB0
aGlzIGRpc2N1c3Npb24uIEkgaGFkIHNldmVyYWwgY29uZmlncyB3cm9uZywgb3Igbm90IE9LIHBl
ciBkZWJpYW4KPFByeU1hcjU2PiBvbiBkZWI4IG5vdGhpbmcgZ29lcyBpbiBsaWI2NCBhbmQgc3lz
dGVtZCBkb2VzIG5vdCB1c2UgL3Vzci9saWIvKgo8UHJ5TWFyNTY+IHN5c3RlbWQgLT4gL2xpYi9z
eXN0ZW1kL3N5c3RlbS8qLnNlcnZpY2VzCjxnb29uXz4gUHJ5TWFyNTYsIEkgc2VlLCBJIGNhbiBz
ZW5kIHlvdSBsb25nZXIgZHVtcHMgaWYgbmVlZGVkCiogYW5kZXJzb25jMGQzICh+YW5kZXJzb25j
QHVuYWZmaWxpYXRlZC9hbmRlcnNvbmMwZDMpIGEgcmVqb2ludCAjeGVuCiogU3R1YXJ0TUkgZXN0
IHBhcnRpIChSZWFkIGVycm9yOiBDb25uZWN0aW9uIHJlc2V0IGJ5IHBlZXIpCjxnb29uXz4gUHJ5
TWFyNTYsIHdlbGwgSSB0aGluayBpdCdzIGJ1aWxkaW5nIGZpbGVzIG5ldmVyIGJ1aWx0IGJlZm9y
ZQo8Z29vbl8+IFByeU1hcjU2LCBvaywgbWFrZSB3b3JsZCB3ZW50IHdpdGhvdXQgZXJyb3IKPGdv
b25fPiBQcnlNYXI1NiwgY2FuIG15IHZhciBkaXIgYmVpbmcgZW1wdHkgYmVpbmcgZHVlZCB0byBh
IHBlcm1pc3Npb24gcHJvYmxlbT8KPGdvb25fPiBQcnlNYXI1NiwgeW91IHRoZXJlPyBtYWtlIGRp
c3QgZW5kZWQgd2l0aG91dCBlcnJvciwgc210ZyB0byBjaGVjayBiZWZvcmUgZmFrZXJvb3Q/Ciog
Q3JvdGhlcnMgKH5jcm90aGVyc0B1bmFmZmlsaWF0ZWQvY3JvdGhlcnMpIGEgcmVqb2ludCAjeGVu
Cjxnb29uXz4gUHJ5TWFyNTYsIGZha2Vyb290IGNvbW1hbmQgKGZha2Vyb290IC4vdG9vbHMvbWlz
Yy9ta2RlYiAkKHB3ZCkgNC41LjAtcmM0IGdpdmVzIG1lICJwZXJtaXNzaW9uIG5vdCBncmFudGVk
IiBhcyBhIHJlc3VsdAo8Z29vbl8+IHJhbiBhcyByb290CjxQcnlNYXI1Nj4gY2htb2QgK3ggLi90
b29scy9taXNjL21rZGViCjxnb29uXz4gUHJ5TWFyNTYsIEludGVyZXN0aW5nLCBpdCB3b3JrZWQg
YnV0IG5vdyBJIGdldCBVbmtub3duIFhFTl9UQVJHRVRfQVJDSCAKPGdvb25fPiBjcW4ndCBidWls
ZCBsaWJzIGZvciBhbiBhcmNoIHlvdSdyZSBub3QgYXdhcmUgb2YKPGdvb25fPiB2YXIgZm9sZGVy
cyBhcmUgcHJlc2VudCBidXQgZW1wdHkgYW5kIHhlbnBhZ2luZyBpcyBkcnd4LS0tLS0tCjxnb29u
Xz4gd2VsbCBsYXVuY2hlZCBhIG1ha2UgZGViYmFsbCwgSSBmb3Jnb3QgdGhhdCBhY3R1YWxseSBs
aWJzIGFyZSBub3cgaW4gdXNyCiogYzRwdCBlc3QgcGFydGkgKFBpbmcgdGltZW91dDogMjY0IHNl
Y29uZHMpCjxnb29uXz4gUHJ5TWFyNTYsICBibGt0YXAgdXRpbHMgY29uZmxpY3QKPGdvb25fPiBQ
cnlNYXI1Niwgb2sgZHBrZyAtaSB3b3JrZWQgYWZ0ZXIgcmVtb3ZpbmcgbXkgcHJldmlvdXMgdmVy
c2lvbiBibGt0YXAtdXRpbHMKPGdvb25fPiB4bCBjb21tYW5kIGdpdmVzIG1lIC91c3IvbG9jYWwv
c2Jpbi94bDogbm8gZmlsZSBvciBmb2xkZXIuLi4KPGdvb25fPiBQcnlNYXI1NiwgaXQgaXMgbG9j
YXRlZCBpbiAvdXNyL3NiaW4vCjxnb29uXz4gUHJ5TWFyNTYsIGxuIC1zIGEgIHRlbXBvcmFyeSBm
aXgsIHN0aWxsIGd1ZXR0aW5nIHhjOiBlcnJvcjogQ291bGQgbm90IG9idGFpbiBoYW5kbGUgb24g
cHJpdmlsZWdlZCBjb21tYW5kIGludGVyZmFjZSAoMiA9IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv
cnkpOiBJbnRlcm5hbCBlcnJvcgo8Z29vbl8+IGxpYnhsOiBlcnJvcjogbGlieGwuYzoxMDk6bGli
eGxfY3R4X2FsbG9jOiBjYW5ub3Qgb3BlbiBsaWJ4YyBoYW5kbGU6IE5vIHN1Y2ggZmlsZSBvciBk
aXJlY3RvcnkKPGdvb25fPiBjYW5ub3QgaW5pdCB4bCBjb250ZXh0Cjxnb29uXz4gUHJ5TWFyNTYs
IHVwZGF0ZV9ncnViIGdpdmVzIG1lIGEgd3JvbmcgdmVyc2lvbiBudW1iZXIKIAoqIEhpc3Rvcmlx
dWUgY2hhcmfDqSBkZXB1aXMgV2VkIERlYyAzMSAwMTo1MToxMiAyMDE0CiAKKiBWb3VzIHBhcmxl
eiBtYWludGVuYW50IHN1ciAjeGVuCiogTGUgc3VqZXQgZGUgI3hlbiBlc3TCoDogWGVuIDQuNC4x
IHJlbGVhc2VkISBodHRwOi8vd3d3LnhlbnByb2plY3Qub3JnL2Rvd25sb2Fkcy5odG1sIHwgV2lr
aTogaHR0cDovL3dpa2kueGVucHJvamVjdC5vcmcvIHwgRkFROiBodHRwOi8vd2lraS54ZW5wcm9q
ZWN0Lm9yZy93aWtpL1hlbl9Db21tb25fUHJvYmxlbXMKKiBTdWpldCBkZSAjeGVuIGTDqWZpbmkg
cGFyIEtldmluYCBsZSBXZWQgU2VwICAzIDIzOjI3OjM3IDIwMTQKKiBnb29uXyBlc3QgcGFydGkg
KFJlYWQgZXJyb3I6IENvbm5lY3Rpb24gcmVzZXQgYnkgcGVlcikKPGdvb25fXz4gUHJ5TWFyNTYs
IG9rLCBEZWI4IGJvb3Rpbmcgd2l0aCBYZW4gNC41LjAtcmMKPGdvb25fXz4gYnV0IHN0aWxsIHhs
IHRocm93cyB4YzogZXJyb3I6IENvdWxkIG5vdCBvYnRhaW4gaGFuZGxlIG9uIHByaXZpbGVnZWQg
Y29tbWFuZCBpbnRlcmZhY2UgKDIgPSBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KTogSW50ZXJu
YWwgZXJyb3IKPGdvb25fXz4gbGlieGw6IGVycm9yOiBsaWJ4bC5jOjEwOTpsaWJ4bF9jdHhfYWxs
b2M6IGNhbm5vdCBvcGVuIGxpYnhjIGhhbmRsZTogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQo8
Z29vbl9fPiBjYW5ub3QgaW5pdCB4bCBjb250ZXh0Cjxnb29uX18+IFByeU1hcjU2LCBzZXJ2aWNl
IHhlbmNvbW1vbnMgc3RhcnQgZGlkIGl0Cjxnb29uX18+IFByeU1hcjU2LCB3ZWxsIGlzIHNlZW1z
IGxpa2UgaXQncyBnb2luZyB0byBiZSBhIGdyZWF0IDIwMTUKPGdvb25fXz4gVGhhbmsgeW91Cjxn
b29uX18+IFByeU1hcjU2LCBRWEwgU1VQUE9SVCBXT1JLSU5HLi4uLgoqIHJjcGF2bGljZWsgZXN0
IHBhcnRpIChQaW5nIHRpbWVvdXQ6IDI1OCBzZWNvbmRzKQoqIGh2eGdyIGVzdCBwYXJ0aSAoUXVp
dDogbGVhdmluZykKKiBodnhnciAofm5vdC11c2VyQHVxamF1Lm9yZykgYSByZWpvaW50ICN4ZW4K
KiB0cm95dCBlc3QgcGFydGkgKFBpbmcgdGltZW91dDogMjU4IHNlY29uZHMpCg==
--047d7b33934159e146050b78ff5f
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--047d7b33934159e146050b78ff5f--


From xen-devel-bounces@lists.xen.org Wed Dec 31 01:27:04 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 01:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y683a-0007cr-86; Wed, 31 Dec 2014 01:26:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <monsieur.goonie@gmail.com>) id 1Y683X-0007cm-WF
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 01:26:36 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	45/DE-09842-BC053A45; Wed, 31 Dec 2014 01:26:35 +0000
X-Env-Sender: monsieur.goonie@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419989192!10527915!1
X-Originating-IP: [209.85.218.42]
X-SpamReason: No, hits=2.0 required=7.0 tests=BIZ_TLD,HTML_MESSAGE, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26167 invoked from network); 31 Dec 2014 01:26:32 -0000
Received: from mail-oi0-f42.google.com (HELO mail-oi0-f42.google.com)
	(209.85.218.42)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2014 01:26:32 -0000
Received: by mail-oi0-f42.google.com with SMTP id v63so34281595oia.1
	for <xen-devel@lists.xen.org>; Tue, 30 Dec 2014 17:26:31 -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/coHIrGtDvunwAscKcUJx2xHoWBEX/6g4ZIaZoMZlk=;
	b=bMOAwVixUXuyFCQR2JcUBgkvydwqySDNxDkkbE/dHSjHTNwwbfe1mtOJ1bNftuZ7X1
	T0e6r4NEE0ZsfBrBXjKHoSJwuXhcVUB2qjdDisQk/6wwWt+hdoCn5lwDFEhhgpogyZIk
	59E2YBegs5pKnkVxcdfM6q25VlQRLCBOCfoH88Wj2dYaxjKDg5vbtDQ3SRckTLvgnvT2
	D0spoem4wLpdsEHPfv7SwavfvQHMAnUhHe23zulC91KJyOaVQ10f9qkGWfDwbGGgqdLS
	zQ7/zxM0AEOn7i3ciT70xlK70pTzu8WlATnOlMIczO/DkS9cIgj7IGlANUrwqCHwHMWF
	5bcA==
MIME-Version: 1.0
X-Received: by 10.60.120.36 with SMTP id kz4mr22646194oeb.80.1419989191604;
	Tue, 30 Dec 2014 17:26:31 -0800 (PST)
Received: by 10.182.26.72 with HTTP; Tue, 30 Dec 2014 17:26:31 -0800 (PST)
In-Reply-To: <54A15BFA.4050001@m2r.biz>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>
	<549EBDCC.3090102@m2r.biz>
	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>
	<CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>
	<CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>
	<CAE5x5YU8R9PibP-_xj+uYNc_rqOL0rnuHvVF5Ymz32RngDEgFw@mail.gmail.com>
	<CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com>
	<54A15BFA.4050001@m2r.biz>
Date: Wed, 31 Dec 2014 02:26:31 +0100
Message-ID: <CAE5x5YWRJaF1XZ0masWn0uotUQghW0irM=NmU9XB0Dc8_XUFJw@mail.gmail.com>
From: Goonie Windy <monsieur.goonie@gmail.com>
To: Fabio Fantoni <fabio.fantoni@m2r.biz>
Content-Type: multipart/mixed; boundary=047d7b33934159e146050b78ff5f
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--047d7b33934159e146050b78ff5f
Content-Type: multipart/alternative; boundary=047d7b33934159e141050b78ff5d

--047d7b33934159e141050b78ff5d
Content-Type: text/plain; charset=UTF-8

Ok Fabio, thanks to your configure, some bits of hacking the install part
and lots of advises/support/encouragements ;) from Mark Pryor I ended up
 installing 4.5RC4 with QXL support on Deb8 unstable.


So now what do you want me to test fabio?
I have win7 x64 / win 2k8R2 vms in test mode ready to install drvers.

the numerous troubles I went through are related in the IRCcopy attached.
I actually couldn't build rombios and used seabios provided by the system
-like you-
I should try to compile/find latest qxl now.

See you in 2K15.

greg B

2014-12-29 14:49 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:

>  Il 29/12/2014 14:13, Goonie Windy ha scritto:
>
>   ok, I'm trying to patch the files with yours,
>
>
>  I need to do it manually right?
>
> git apply is not working here.
>
>
> If the patch need a "refresh" the conflict should be solved manually.
> Taking the patch updated from here probably it can be applied to latest
> 4.5-rc:
> https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>
>
>
>  regards
>
>  greg
>
> 2014-12-29 13:46 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>
>> There is an error in pageqs describing how to compile from sources as in
>> 4.5
>>
>> cat .config
>> PYTHON_PREFIX_ARG=--install-layout=deb
>>
>>
>> is in fact in .INSTALL
>>
>>
> If also you use debian you can use make debball that is better for
> install/remove easy and fast test build.
>
> And for example I use this configure options with xen 4.5:
> ./configure --prefix=/usr --disable-blktap1 --disable-qemu-traditional
> --disable-rombios --with-system-seabios=/usr/share/seabios/bios-256k.bin
> --with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir"
> --disable-blktap2
> I use wheezy building updated packages from sid: seabios 1.7.5-1, spice
> 0.12.5-1, spice-protocol 0.12.7-1 and usbredir 0.7-1.
> If you use jessie instead you have all packages updated.
>
> About python I'm using this workaround (before execute configure) even if
> probably is not the best:
> Config.mk
> -PYTHON_PREFIX_ARG ?= --prefix="$(PREFIX)"
> +PYTHON_PREFIX_ARG ?=
>
>
>
>>
>> 2014-12-29 1:20 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>>
>>>  well figured out it is because you have to "enforce" locale:  export
>>> LC_ALL=en_US.utf-8 if keyboard mapping is else
>>>
>>> 2014-12-28 21:19 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>>>
>>>>  Trying to compile xen 4.5RC4 in order to test your patch I end up
>>>> with  these errors compiling the Seabios directories,
>>>>
>>>>  any idea?
>>>>
>>>>   Compiling to assembler out/src/asm-offsets.s
>>>>   Generating offset file out/asm-offsets.h
>>>>   Compiling (16bit) out/romlayout.o
>>>>   Building ld scripts
>>>> Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
>>>> Traceback (most recent call last):
>>>>   File "./scripts/layoutrom.py", line 709, in <module>
>>>>     main()
>>>>   File "./scripts/layoutrom.py", line 671, in main
>>>>     info16 = parseObjDump(infile16, '16')
>>>>   File "./scripts/layoutrom.py", line 586, in parseObjDump
>>>>     relocsection = sectionmap[sectionname]
>>>> KeyError:
>>>> '.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
>>>> Makefile:155: recipe for target 'out/romlayout16.lds' failed
>>>> make[6]: *** [out/romlayout16.lds] Error 1
>>>> make[6]: Leaving directory
>>>> '/home/goon/xen/tools/firmware/seabios-dir-remote'
>>>> /home/goon/xen/tools/firmware/../../tools/Rules.mk:116: recipe for
>>>> target 'subdir-all-seabios-dir' failed
>>>>
>>>>
>>>>
>>>> 2014-12-27 17:35 GMT+01:00 Goonie Windy <monsieur.goonie@gmail.com>:
>>>>
>>>>>   Hello Fabio,
>>>>>
>>>>> Sure thing I will help debug the win7 and the win8 versions.
>>>>>  Where to start?
>>>>>
>>>>>  I'll try to see if I can patch with patch from
>>>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>>>> and if not will post result.
>>>>>
>>>>>
>>>>> best regards,
>>>>>
>>>>>
>>>>>  greg Bahde
>>>>>
>>>>> 2014-12-27 15:10 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz>:
>>>>>
>>>>>>
>>>>>> Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>>>>>
>>>>>>   I tried to install Qxl drivers under win7/win 2k8/win8.1
>>>>>> all       x64 versions, without any luck.
>>>>>>
>>>>>>
>>>>>> admin message is as follow:
>>>>>> Driver Management concluded the process to install driver
>>>>>> FileRepository\qxl.inf_amd64_
>>>>>> neutral_f0c429882d5c81ed\qxl.inf for Device Instance ID
>>>>>> PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28 with the
>>>>>> following status: 0xe000022d.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  Does
>>>>>> http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>>>>>
>>>>>>  can it be installed on my xen stack?
>>>>>>
>>>>>>
>>>>>>  Yes but probably require a small refresh, I always posted the patch
>>>>>> based on updated xen-unstable.
>>>>>>
>>>>>> Here qxl patch refreshed for xen 4.5 if needed:
>>>>>>
>>>>>> https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>>>>>
>>>>>> Here the latest spice guest tools for windows with qxl driver
>>>>>> included:
>>>>>>
>>>>>> http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>>>>>>
>>>>>> Windows >=8 and similar require a new qxl drivers, there are a beta
>>>>>> build but latest tried some months ago have serious bug and I not found
>>>>>> recent build full working on windows 8.
>>>>>>
>>>>>> On xen windows 7 domUs qxl works good except a problem after
>>>>>> save/restore and on linux domUs is not working, for now I not found exactly
>>>>>> cause and solution.
>>>>>> On mailing list up to 2 years ago you can find many my mails about.
>>>>>> Any help to test it is appreciated.
>>>>>>
>>>>>> Sorry for my bad english.
>>>>>>
>>>>>>
>>>>>> Also, can  I get invited at xendevel irc ?
>>>>>> regards
>>>>>>
>>>>>>  Greg
>>>>>>
>>>>>>
>>>>>>  _______________________________________________
>>>>>> Xen-devel mailing listXen-devel@lists.xen.orghttp://lists.xen.org/xen-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>

--047d7b33934159e141050b78ff5d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Ok Fabio, thanks to your configure, some bits of=
 hacking the install part and lots of advises/support/encouragements ;) fro=
m Mark Pryor I ended up<br></div>=C2=A0installing 4.5RC4 with QXL support o=
n Deb8 unstable.<br><br><br></div><div>So now what do you want me to test f=
abio?<br></div><div>I have win7 x64 / win 2k8R2 vms in test mode ready to i=
nstall drvers.<br></div><div><br></div><div>the numerous troubles I went th=
rough are related in the IRCcopy attached.<br></div><div>I actually couldn&=
#39;t build rombios and used seabios provided by the system -like you-<br><=
/div><div>I should try to compile/find latest qxl now.<br><br></div><div>Se=
e you in 2K15.<br><br></div><div>greg B<br></div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">2014-12-29 14:49 GMT+01:00 Fabio Fant=
oni <span dir=3D"ltr">&lt;<a href=3D"mailto:fabio.fantoni@m2r.biz" target=
=3D"_blank">fabio.fantoni@m2r.biz</a>&gt;</span>:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Il 29/12/2014 14:13, Goonie Windy ha
      scritto:<br>
    </div><span class=3D"">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>ok, I&#39;m trying to patch the files with yours,<br>
              <br>
              <br>
            </div>
            I need to do it manually right? <br>
            <br>
            git apply is not working here. <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    If the patch need a &quot;refresh&quot; the conflict should be solved
    manually.<br>
    Taking the patch updated from here probably it can be applied to
    latest 4.5-rc:<br>
    <a href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging" tar=
get=3D"_blank">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a><=
span class=3D""><br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div><br>
            <br>
          </div>
          regards<br>
          <br>
        </div>
        greg<br>
      </div>
      <div class=3D"gmail_extra"><br>
        <div class=3D"gmail_quote">2014-12-29 13:46 GMT+01:00 Goonie Windy
          <span dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.goonie@gmail.com=
" target=3D"_blank">monsieur.goonie@gmail.com</a>&gt;</span>:<br>
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
            <div dir=3D"ltr">There is an error in pageqs describing how to
              compile from sources as in 4.5 <br>
              <pre>cat .config
PYTHON_PREFIX_ARG=3D--install-layout=3Ddeb

</pre>
              <pre>is in fact in .INSTALL
</pre>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br></span>
    If also you use debian you can use make debball that is better for
    install/remove easy and fast test build.<br>
    <br>
    And for example I use this configure options with xen 4.5:<br>
    ./configure --prefix=3D/usr --disable-blktap1
    --disable-qemu-traditional --disable-rombios
    --with-system-seabios=3D/usr/share/seabios/bios-256k.bin
    --with-extra-qemuu-configure-args=3D&quot;--enable-spice
    --enable-usb-redir&quot; --disable-blktap2<br>
    I use wheezy building updated packages from sid: seabios 1.7.5-1,
    spice 0.12.5-1, spice-protocol 0.12.7-1 and usbredir 0.7-1.<br>
    If you use jessie instead you have all packages updated.<br>
    <br>
    About python I&#39;m using this workaround (before execute configure)
    even if probably is not the best:<br>
    <span title=3D"Config.mk">Config.mk</span><br>
    -<span>PYTHON_PREFIX_ARG</span> ?=3D<span> --prefix=3D&quot;</span><spa=
n><span>$(</span><span>PREFIX</span><span>)</span></span><span>&quot;</span=
><br>
    +<span>PYTHON_PREFIX_ARG</span> ?=3D<div><div class=3D"h5"><br>
    <br>
    <blockquote type=3D"cite">
      <div class=3D"gmail_extra">
        <div class=3D"gmail_quote">
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
            <div dir=3D"ltr"><br>
            </div>
            <div>
              <div>
                <div class=3D"gmail_extra"><br>
                  <div class=3D"gmail_quote">2014-12-29 1:20 GMT+01:00
                    Goonie Windy <span dir=3D"ltr">&lt;<a href=3D"mailto:mo=
nsieur.goonie@gmail.com" target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                        <div>well figured out it is because you have to
                          &quot;enforce&quot; locale:=C2=A0 export LC_ALL=
=3Den_US.utf-8
                          if keyboard mapping is else<br>
                        </div>
                      </div>
                      <div>
                        <div>
                          <div class=3D"gmail_extra"><br>
                            <div class=3D"gmail_quote">2014-12-28 21:19
                              GMT+01:00 Goonie Windy <span dir=3D"ltr">&lt;=
<a href=3D"mailto:monsieur.goonie@gmail.com" target=3D"_blank">monsieur.goo=
nie@gmail.com</a>&gt;</span>:<br>
                              <blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                                <div dir=3D"ltr">
                                  <div>Trying to compile xen 4.5RC4 in
                                    order to test your patch I end up
                                    with=C2=A0 these errors compiling the
                                    Seabios directories,<br>
                                    <br>
                                  </div>
                                  any idea?<br>
                                  <br>
                                  =C2=A0 Compiling to assembler
                                  out/src/asm-offsets.s<br>
                                  =C2=A0 Generating offset file
                                  out/asm-offsets.h<br>
                                  =C2=A0 Compiling (16bit) out/romlayout.o<=
br>
                                  =C2=A0 Building ld scripts<br>
                                  Version:
                                  rel-1.7.5-0-ge51488c-20141228_210340-E766=
<br>
                                  Traceback (most recent call last):<br>
                                  =C2=A0 File &quot;./scripts/layoutrom.py&=
quot;, line
                                  709, in &lt;module&gt;<br>
                                  =C2=A0=C2=A0=C2=A0 main()<br>
                                  =C2=A0 File &quot;./scripts/layoutrom.py&=
quot;, line
                                  671, in main<br>
                                  =C2=A0=C2=A0=C2=A0 info16 =3D parseObjDum=
p(infile16,
                                  &#39;16&#39;)<br>
                                  =C2=A0 File &quot;./scripts/layoutrom.py&=
quot;, line
                                  586, in parseObjDump<br>
                                  =C2=A0=C2=A0=C2=A0 relocsection =3D
                                  sectionmap[sectionname]<br>
                                  KeyError:
&#39;.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.=
c.79&#39;<br>
                                  Makefile:155: recipe for target
                                  &#39;out/romlayout16.lds&#39; failed<br>
                                  make[6]: *** [out/romlayout16.lds]
                                  Error 1<br>
                                  make[6]: Leaving directory
                                  &#39;/home/goon/xen/tools/firmware/seabio=
s-dir-remote&#39;<br>
                                  /home/goon/xen/tools/firmware/../../tools=
/Rules.mk:116:
                                  recipe for target
                                  &#39;subdir-all-seabios-dir&#39; failed<b=
r>
                                  <br>
                                  <br>
                                </div>
                                <div>
                                  <div>
                                    <div class=3D"gmail_extra"><br>
                                      <div class=3D"gmail_quote">2014-12-27
                                        17:35 GMT+01:00 Goonie Windy <span =
dir=3D"ltr">&lt;<a href=3D"mailto:monsieur.goonie@gmail.com" target=3D"_bla=
nk">monsieur.goonie@gmail.com</a>&gt;</span>:<br>
                                        <blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                                          <div dir=3D"ltr">
                                            <div>
                                              <div>
                                                <div>Hello Fabio,<br>
                                                  <br>
                                                  Sure thing I will help
                                                  debug the win7 and the
                                                  win8 versions.<br>
                                                </div>
                                                Where to start?<br>
                                                <br>
                                              </div>
                                              I&#39;ll try to see if I can
                                              patch with patch from <a href=
=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e=
8b8fe" target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8=
c7e421fafba67aa11879e8b8fe</a>
                                              and if not will post
                                              result.<br>
                                              <br>
                                              <br>
                                              best regards,<br>
                                              <br>
                                              <br>
                                            </div>
                                            greg Bahde<br>
                                          </div>
                                          <div>
                                            <div>
                                              <div class=3D"gmail_extra"><b=
r>
                                                <div class=3D"gmail_quote">=
2014-12-27
                                                  15:10 GMT+01:00 Fabio
                                                  Fantoni <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">fabio.fanto=
ni@m2r.biz</a>&gt;</span>:<br>
                                                  <blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
                                                    <div bgcolor=3D"#FFFFFF=
" text=3D"#000000"> <br>
                                                      <div>Il 27/12/2014
                                                        02:15, Goonie
                                                        Windy ha
                                                        scritto:<br>
                                                      </div>
                                                      <span>
                                                        <blockquote type=3D=
"cite">
                                                          <div dir=3D"ltr">
                                                          <div>
                                                          <div>
                                                          <div>I tried
                                                          to install Qxl
                                                          drivers under
                                                          win7/win
                                                          2k8/win8.1=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          all=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 x64
                                                          versions,
                                                          without any
                                                          luck.<br>
                                                          <br>
                                                          <br>
                                                          admin message
                                                          is as follow:<br>
                                                          Driver
                                                          Management
                                                          concluded the
                                                          process to
                                                          install driver
                                                          FileRepository\qx=
l.inf_amd64_

                                                          <div dir=3D"ltr">=
neutral_f0c429882d5c81ed\qxl.inf
                                                          for Device
                                                          Instance ID
                                                          PCI\VEN_1013&amp;=
DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&amp;267A616A&amp;1&amp;28

                                                          with the
                                                          following
                                                          status:
                                                          0xe000022d.</div>
                                                          <br>
                                                          <br>
                                                          <br>
                                                          <br>
                                                          </div>
                                                          Does <br>
                                                          <a href=3D"http:/=
/lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html" target=3D"_bl=
ank">http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html</a>=
<br>
                                                          <br>
                                                          </div>
                                                          can it be
                                                          installed on
                                                          my xen stack?
                                                          <br>
                                                          </div>
                                                          </div>
                                                        </blockquote>
                                                        <br>
                                                      </span> Yes but
                                                      probably require a
                                                      small refresh, I
                                                      always posted the
                                                      patch based on
                                                      updated
                                                      xen-unstable. <br>
                                                      <br>
                                                      Here qxl patch
                                                      refreshed for xen
                                                      4.5 if needed:<br>
                                                      <a href=3D"https://gi=
thub.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe" target=
=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67=
aa11879e8b8fe</a><br>
                                                      <br>
                                                      Here the latest
                                                      spice guest tools
                                                      for windows with
                                                      qxl driver
                                                      included:<br>
                                                      <a href=3D"http://www=
.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74=
.exe" target=3D"_blank">http://www.spice-space.org/download/binaries/spice-=
guest-tools/spice-guest-tools-0.74.exe</a><br>
                                                      <br>
                                                      Windows &gt;=3D8 and
                                                      similar require a
                                                      new qxl drivers,
                                                      there are a beta
                                                      build but latest
                                                      tried some months
                                                      ago have serious
                                                      bug and I not
                                                      found recent build
                                                      full working on
                                                      windows 8.<br>
                                                      <br>
                                                      On xen windows 7
                                                      domUs qxl works
                                                      good except a
                                                      problem after
                                                      save/restore and
                                                      on linux domUs is
                                                      not working, for
                                                      now I not found
                                                      exactly cause and
                                                      solution.<br>
                                                      On mailing list up
                                                      to 2 years ago you
                                                      can find many my
                                                      mails about.<br>
                                                      Any help to test
                                                      it is appreciated.<br=
>
                                                      <br>
                                                      Sorry for my bad
                                                      english.<br>
                                                      <br>
                                                      <blockquote type=3D"c=
ite"><span>
                                                          <div dir=3D"ltr">
                                                          <div><br>
                                                          Also, can=C2=A0 I
                                                          get invited at
                                                          xendevel irc ?<br=
>
                                                          regards<br>
                                                          <br>
                                                          </div>
                                                          Greg <br>
                                                          </div>
                                                          <br>
                                                          <fieldset></field=
set>
                                                          <br>
                                                        </span>
                                                        <pre>______________=
_________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a>
</pre>
                                                      </blockquote>
                                                      <br>
                                                    </div>
                                                  </blockquote>
                                                </div>
                                                <br>
                                              </div>
                                            </div>
                                          </div>
                                        </blockquote>
                                      </div>
                                      <br>
                                    </div>
                                  </div>
                                </div>
                              </blockquote>
                            </div>
                            <br>
                          </div>
                        </div>
                      </div>
                    </blockquote>
                  </div>
                  <br>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div>

--047d7b33934159e141050b78ff5d--
--047d7b33934159e146050b78ff5f
Content-Type: application/octet-stream; name="xen4.5RC4"
Content-Disposition: attachment; filename="xen4.5RC4"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i4c0sywk0

KiBzdWJkcml2ZW4gKH5zdWJkcml2ZW5Ac2VjdXJhYml0L2xpc3RlbmVyL3N1YmRyaXZlbikgYSBy
ZWpvaW50ICN4ZW4KKiBvdmFuXyBlc3QgcGFydGkgKFF1aXQ6IExvc3QgdGVybWluYWwpCiogc2t5
bGl0ZSAofnNreWxpdGVANTQwMDBDMTMuZHNsLnBvb2wudGVsZWtvbS5odSkgYSByZWpvaW50ICN4
ZW4KKiBnZWFhcnUgZXN0IHBhcnRpIChRdWl0OiBMZWF2aW5nKQoqIGRhcmlvZiAofmRhcmlvZkBu
ZXQtMi0zOS03MC0xMDMuY3VzdC52b2RhZm9uZWRzbC5pdCkgYSBxdWl0dMOpICN4ZW4KKiBQcnlN
YXI1NiBlc3QgcGFydGkgKFF1aXQ6IExlYXZpbmcpCiogeG1lcmxpbiAofnhtZXJsaW5AMjEyLTEy
NC0xNjQtMTYxLnY0Lm5naS5pdCkgYSByZWpvaW50ICN4ZW4KKiBTZXJsZXheICh+c2VyY2FuQGNw
YzItZ2xmZDYtMi0wLWN1c3QyNTAuNi0yLmNhYmxlLnZpcmdpbm0ubmV0KSBhIHJlam9pbnQgI3hl
bgoqIFNlcmxleF4gZXN0IHBhcnRpIChDbGllbnQgUXVpdCkKKiBlbmdsaXNobV8gcydhcHBlbGxl
IG1haW50ZW5hbnQgZW5nbGlzaG0KKiBvbGFmXyBlc3QgcGFydGkgKFF1aXQ6IENsaWVudCBleGl0
aW5nKQoqIGVuZ2xpc2htIGVzdCBwYXJ0aSAoQ2hhbmdpbmcgaG9zdCkKKiBlbmdsaXNobSAofmVu
Z2xpc2htQHVuYWZmaWxpYXRlZC9lbmdsaXNobSkgYSByZWpvaW50ICN4ZW4KPEZyb3NoPiBJcyB0
aGVyZSBhIHdheSB0byByZXN0YXJ0IHhlbiBoeXBlcnZpc29yIGFmdGVyIGEgdXBncmFkZSBmcm9t
IDQuMyB0byA0LjQgb3IganVzdCByZWJvb3QgdGhlIGNvbXB1dGVyIGlzIHRoZSBvbmx5IHNvbHV0
aW9uLCBzb3J0YSBkb24ndCB3YW50IHRvIHJlc3RhcnQgYWxsIHRoZSBkb211CjxhbmR5aGhwPiBu
bwo8YW5keWhocD4gd2h5IHdvdWxkIHRoZXJlIGJlPwo8YW5keWhocD4gd291bGQgeW91IGV4cGVj
dCB0byBiZSBhYmxlIHRvIGRvIGEgbGludXgga2VybmVsIHVwZ3JhZGUgd2l0aG91dCByZWJvb3Rp
bmc/Cjxkd2ZyZWVkPiB0ZWNobmljYWxseSB5b3UgY2FuIGtleGVjIFhlbiwgYnV0IHlvdSdyZSBi
ZXR0ZXIgb2ZmIGp1c3QgcmVib290aW5nLCBiZWNhdXNlIHlvdSdkIHN0aWxsIGhhdmUgdG8gdGFr
ZSBkb3duIGFsbCBvZiB5b3VyIFZNcwoqIETDqWNvbm5lY3TDqSAoQ29ubmV4aW9uIHRlcm1pbsOp
ZSBwYXIgZXhwaXJhdGlvbiBkdSBkw6lsYWkgZCdhdHRlbnRlKS4KKiBWb3VzIHBhcmxleiBtYWlu
dGVuYW50IHN1ciAjeGVuCiogTGUgc3VqZXQgZGUgI3hlbiBlc3TCoDogWGVuIDQuNC4xIHJlbGVh
c2VkISBodHRwOi8vd3d3LnhlbnByb2plY3Qub3JnL2Rvd25sb2Fkcy5odG1sIHwgV2lraTogaHR0
cDovL3dpa2kueGVucHJvamVjdC5vcmcvIHwgRkFROiBodHRwOi8vd2lraS54ZW5wcm9qZWN0Lm9y
Zy93aWtpL1hlbl9Db21tb25fUHJvYmxlbXMKKiBTdWpldCBkZSAjeGVuIGTDqWZpbmkgcGFyIEtl
dmluYCBsZSBXZWQgU2VwICAzIDIzOjI3OjM3IDIwMTQKPFByeU1hcjU2PiBnb29uaWVCLCB0aGUg
cXhsIHBhdGNoc2V0IGlzIGZvciA0LjUgKEhFQUQpPyB3aGF0IGlzIGRhdGUgb24gcGF0Y2g/Cjxn
b29uXz4gUHJ5TWFyNTYsIGRvbid0IGdldCBpdCwgeWVzIGl0IGlzIDQuNSBJJ20gdHJ5aW5nIHRv
IGNvbXBpbGUgLWFuZCBmYWlsbGluZyB0byByZWdhcmRpbmcgdGhlIFNlYWJpb3MgcGFydC0gaW4g
b3JkZXIgdG8gaW5zdGFsbCB0aGlzIHF4bCBwYXRjaAo8Z29vbl8+IDQuNVJDNAo8UHJ5TWFyNTY+
IHJvbGwgYmFjayB0aGUgdGFnIC0+IGNoZWNrb3V0IHhlbi00LjUuMC1yYzEKKiBPc2VucGFpXyAo
fk9zZW5wYWlAMTc3LjgxLjkuNjYpIGEgcmVqb2ludCAjeGVuCjxQcnlNYXI1Nj4gbWlnaHQgbmVl
ZCB0byByb2xsIGJhY2sgc2VhYmlvcwoqIE9zZW5wYWkgZXN0IHBhcnRpIChQaW5nIHRpbWVvdXQ6
IDI1OCBzZWNvbmRzKQo8Z29vbl8+IFByeU1hcjU2LCBzZWFyY2hpbmcgaG93IHRvIGRvIHRoYXQs
IGlmIHlvdSBrbm93Li4uCjxQcnlNYXI1Nj4gaW4gc2Vjb25kcyB5b3UgY2FuIGNsb25lIHRoZSBz
ZWFiaW9zIGdpdCBhbmQgZG8gYGdpdCBicmFuY2ggLWFgCjxQcnlNYXI1Nj4gbG9vayBpbiBDb25m
aWcubWsgZm9yIHRoZSBVUkwKKiBhbmRlcnNvbmMwZDMgKH5hbmRlcnNvbmNAdW5hZmZpbGlhdGVk
L2FuZGVyc29uYzBkMykgYSByZWpvaW50ICN4ZW4KPGdvb25fPiBQcnlNYXI1NiwgdGhhbmsgeW91
CjxQcnlNYXI1Nj4gU0VBQklPU19VUFNUUkVBTV9VUkwKPFByeU1hcjU2PiBnb29uXywgeW91IHNl
ZW0gcHJldHR5IGRldGVybWluZWQgdG8gZml4IHRoaXMsIHNvIGNsb25pbmcgZ2l0IG1pZ2h0IGJl
IHdvcnRoIHRoZSB0cm91YmxlCjxnb29uXz4gU0VBQklPU19VUFNUUkVBTV9SRVZJU0lPTiA/PSBy
ZWwtMS43LjUKPGdvb25fPiBnaXQ6Ly94ZW5iaXRzLnhlbi5vcmcvc2VhYmlvcy5naXQKPGdvb25f
PiBzbyB5b3Ugc3VnZ2VzdCBJIHRyeSB0byBnaXQgdGhlIHNhbWUgcmVsIGFzIHRoZSBvbmUgaW5j
bHVkZWQgaW4gUkMxPwo8UHJ5TWFyNTY+IEZhbnRvbiB3cm90ZSB0aGUgcGF0Y2ggaW4gSnVseSAn
MTQ/CjxQcnlNYXI1Nj4gYXBvbG9neSBpZiBJIGJ1dGNoZXJlZCBoaXMgbmFtZQo8Z29vbl8+IFBy
eU1hcjU2LCB5ZXMgaW4ganVseQo8UHJ5TWFyNTY+IGZyb20geW91ciBwYXN0ZSwgaXQgZXJyb3Jl
ZCBpbiBmaXJtd2FyZS9TZWFiaW9zCjxQcnlNYXI1Nj4gdG9vbHMvZmlybXdhcmUvc2VhYmlvcwo8
UHJ5TWFyNTY+IGdpdCBzaG93IDFiMDY4YTViIDwtLSB0aGUgY29tbWl0IHRoYXQgYWRkZWQgdGhl
IHJjMSB0YWcKPFByeU1hcjU2PiBldmVuIHJjMSBpcyBub3Qgb2xkIGVub3VnaCAoT2N0IDI0ICcx
NCkKPGdvb25fPiB5ZXMsIHdoYXQgSSB0aG91Z2h0LCBidXQgbm90IHN1cmUgaG93IHRvIG1vdmUg
Zm9yd2FyZCwgbmVlZCBhIGdpdCBjcmFzaCBjb3Vyc2UgdG8gZG8gc28gOykKPGdvb25fPiBvbiBt
eSB3YXkgdGhvdWgKPFByeU1hcjU2PiBpbiB0aGUgc2VhYmlvcyB0cmVlOiBnaXQgbG9nICAgLXAg
PGludGVyZXN0aW5nIHBhdGg+CjxQcnlNYXI1Nj4gZ2l0IGxvZyAgLS1wcmV0dHk9b25lbGluZQo8
Z29vbl8+IFByeU1hcjU2LCBvaywgSSBzZWUgdGhlIGxpc3Qgb2YgY29tbWl0cwo8Z29vbl8+IFBy
eU1hcjU2LCAgdGhlIGNvbW1pdCBjYXVzaW5nIHRyb3VibGUgaXMgZTUxNDg4YzVmODgwMGE1MmFj
NWM4ZGE3YTMxYjg1Y2NhNWNjOTVkMiBweXRob24zIGZpeGVzIGZvciB2Z2FiaW9zIGFuZCBjc20g
YnVpbGRzLgo8Z29vbl8+IHNvIGhvdyB0byBnZXQgcHJldmlvdXMgdmVyc2lvbi4KPGdvb25fPiBz
byBnaXQgYnJhbmNoIC1hIGdpdmVzIG1lICAgcmVtb3Rlcy9vcmlnaW4vMS42LjMtc3RhYmxlLXhl
bgo8Z29vbl8+ICAgcmVtb3Rlcy9vcmlnaW4vMS43LjEtc3RhYmxlLXhlbgo8Z29vbl8+ICAgcmVt
b3Rlcy9vcmlnaW4vMS43LjMtc3RhYmxlCjxnb29uXz4gICByZW1vdGVzL29yaWdpbi9IRUFEIC0+
IG9yaWdpbi9tYXN0ZXIKPGdvb25fPiAgIHJlbW90ZXMvb3JpZ2luL21hc3Rlcgo8Z29vbl8+IGFu
ZCB0aGUgY3VycmVudCBpcyAxLjcuNSBzbyBtYXliZSBJIHNob3VsZCBtb3ZlIGJhY2sgdG8gMS43
LjMKPGdvb25fPiBnb3R0YSBsZWFybiBob3cgdG8gZG8gdGhhdCAKKiBHdWVzdDE1NzA5IGVzdCBw
YXJ0aSAoUmVtb3RlIGhvc3QgY2xvc2VkIHRoZSBjb25uZWN0aW9uKQo8UHJ5TWFyNTY+IGdyZXAg
dGhlIGBnaXQgbG9nICAtLXByZXR0eT1vbmVsaW5lYCBmb3IgdGFncwo8UHJ5TWFyNTY+IG5vdCBz
dXJlIGlmIHRoZXkgZnJlZXplIHdpdGggdGFncyB0aGUgd2F5IHhlbiBkb2VzCiogUGVyICh+cXVh
c3NlbEA3NC44MS0xNjYtMTcuY3VzdG9tZXIubHlzZS5uZXQpIGEgcmVqb2ludCAjeGVuCiogUGVy
IHMnYXBwZWxsZSBtYWludGVuYW50IEd1ZXN0MzQ0ODMKPFByeU1hcjU2PiBnaXQgY2hlY2tvdXQg
MS43LjMtc3RhYmxlCjxQcnlNYXI1Nj4gZ2l0IGNoZWNrb3V0IG1hc3RlciA8LS0tIHRvIHJlc3Rv
cmUgdG8gSEVBRAo8UHJ5TWFyNTY+IHlvdSBjYW4gdHJ5IHRvIHJldmVydCB0aGUgZTUxNDg4YzUK
PGdvb25fPiBQcnlNYXI1NiwgZ3JlYXQgb2ssIG5vdyBJJ2xsIGZvbGxvdyB0aGUgY29tcGlsZSBw
cm9jZWR1cmUgYmFjayBhZ2Fpbgo8UHJ5TWFyNTY+IGdpdCByZXZlcnQgLS1uby1jb21taXQgLS1u
by1lZGl0CjxQcnlNYXI1Nj4gZ2l0IHJldmVydCAtLW5vLWNvbW1pdCAtLW5vLWVkaXQgPHNoYSBw
cmVmaXg+Cjxnb29uXz4gdHJpZWQgd2l0aCAxLjcuMy1zdGFibGUgLCBzdGlsbCBhbiBlcnJvciwg
YnV0IGRpZmZlcmVudDoKPGdvb25fPiBodHRwOi8vcGFzdGViaW4uY29tL2tQd2dMVmZHCjxnb29u
Xz4gUHJ5TWFyNTYsIGd1ZXNzIEkgc2hvdWxkIHRyeSB3aXRoIG1hc3RlciwgcmV2ZXJ0aW5nIGxp
a2UgeW91IHNhaWQKKiBPbGdhYWEgZXN0IHBhcnRpICgpCjxQcnlNYXI1Nj4gYSByZXZlcnQgaXMg
YWdncmVzc2l2ZSBtb3ZlIGZvciBhIGRldiwgc28gdXNlIC0tbm8tY29tbWl0CjxQcnlNYXI1Nj4g
aWYgdGhlIHBhdGNoIGlzIHNob3J0LCB5b3UgY2FuIHJldmVyc2UgaXQgYnkgaGFuZAo8UHJ5TWFy
NTY+IGdpdCBzdGF0dXMgIDwtLSBoZWxwcyB0b28gYW5kIGZpbmFsbHkgYGdpdCBkaWZmYCB0byBk
dW1wIHlvdXIgY2hhbmdlcwo8UHJ5TWFyNTY+IGxldCBnaXQgbWFrZSB5b3VyIHBhdGNoZXMgZm9y
IHlvdQo8Z29vbl8+IHRyaWVkIDEuNy4xLXN0YWJsZS14ZW4gd2l0aG91dCBsdWNsIGVpdGhlcgo8
Z29vbl8+IFByeU1hcjU2LCBpZG4ndCBnbyBmYXIsIHN0aWxsIG5vdCB3b3JraW5nIDovCiogRnJv
c2ggZXN0IHBhcnRpIChRdWl0OiBDb25uZWN0aW9uIGNsb3NlZCBmb3IgaW5hY3Rpdml0eSkKPGdv
b25fPiBQcnlNYXI1NiwgdHJ5aW5nIHRvIGJ1aWxkIHRoZSBSQzMgaW5zdGVhZCwgZG9uJ3Qga25v
dyBpZiBpdCdzIGEgc3R1cGlkIG1vdmUgb3Igbm90LCAKPGdvb25fPiBidXQgZm9yIG5vdwo8Z29v
bl8+IFByeU1hcjU2LCBoYXZlIGV4YWN0bHkgc2FtZSBwcm9ibGVtcyB0cnlpbmcgdG8gY29tcGls
ZSA0LjUgUkMzCiogR3Vlc3QzNDQ4MyBlc3QgcGFydGkgKFJlbW90ZSBob3N0IGNsb3NlZCB0aGUg
Y29ubmVjdGlvbikKKiBQZXIgKH5xdWFzc2VsQDc0LjgxLTE2Ni0xNy5jdXN0b21lci5seXNlLm5l
dCkgYSByZWpvaW50ICN4ZW4KKiBQZXIgcydhcHBlbGxlIG1haW50ZW5hbnQgR3Vlc3QyODc1OAoq
IEZhbnR1IGVzdCBwYXJ0aSAoUXVpdDogQ2hhdFppbGxhIDAuOS45MS4xIFtGaXJlZm94IDM0LjAu
NS8yMDE0MTEyNjA0MTA0NV0pCjxQcnlNYXI1Nj4gZ29vbl8sIHJlbWVtYmVyIHRvIHJ1biBjb25m
aWd1cmUgZnJvbSB4ZW4gcm9vdCB3aXRoIHRoZSAtLXdpdGgtZXh0cmEtcWVtdVUtY29uZmlndXJl
LWFyZ3M9Ii0tZW5hYmxlLXNwaWNlIC0tZW5hYmxlLXVzYi1yZWRpciIKPFByeU1hcjU2PiBub3cg
dGhhdCBJIHN0YXJlIGF0IHRoZSBlcnJvciB5b3UgZ2V0LCBpdCBtZWFucyBjb25maWd1cmUgd2Fz
IG5vdCBydW4KPGdvb25fPiBQcnlNYXI1Niwgd2VsbCBpdCB3YXMsIGJ1dCBJJ2xsIGFkZCB0aGUg
cGFyYW1ldGVycyB5b3UgZ2F2ZSBtZQo8UHJ5TWFyNTY+IGFmdGVyIGNvbmZpZ3VyZSB0cnkgYG1h
a2UgZGlzdC10b29sc2AKPFByeU1hcjU2PiB0aGUgc2VhYmlvcyBnb2VzIGludG8gdGhlLi90b29s
cy9maXJtd2FyZS9zZWFiaW9zLWRpcgo8UHJ5TWFyNTY+IHdoZW4gYnVpbGRpbmcgdGhlIHJjWCB0
YXJiYWxscwoqIGNyeXB0b3p1bHUgKH5sb3JkX21vbmVAMTk2LTIxMC0xNzItMjIxLmR5bmFtaWMu
aXNhZHNsLmNvLnphKSBhIHJlam9pbnQgI3hlbgoqIGFuZGVyc29uYzBkMyBlc3QgcGFydGkgKFBp
bmcgdGltZW91dDogMjQwIHNlY29uZHMpCiogc2FyaWQgZXN0IHBhcnRpIChRdWl0OiBaTkMgLSBo
dHRwOi8vem5jLmluKQoqIHNhcmlkICh+c2FyaWRAMTc4LjYyLjE2MC4yMjcpIGEgcmVqb2ludCAj
eGVuCiogc2FyaWQgcydhcHBlbGxlIG1haW50ZW5hbnQgR3Vlc3Q4NDQ0NAo8Z29vbl8+IFByeU1h
cjU2LCBzbyBubyBsdWNrIGVpdGhlciB3aXRoIHBhcmFtcywgSSBub3RpY2VkIHRoYXQgb24gdGhl
IG1hcmttYWlsLCBzb21lb25lIGNvbXBpbGVkIG9uIGplc3NpZSB3aXRoIHRoZXNlIHBhcmFtcyAi
LS1lbmFibGUtZ2l0aHR0cCAtLWVuYWJsZS1zeXN0ZW1kIiwgYW5kIGl0IGZhaWxlZCBzdGlsbAo8
Z29vbl8+IFByeU1hcjU2LCB3aGF0IGRvZXMgc2VhYmlvcy1kaXItcmVtb3RlIGNvbnRhaW4gZXhh
Y3RseT8KKiBkYXJpb2YgKH5kYXJpb2ZAbmV0LTItMzktNzAtMTAzLmN1c3Qudm9kYWZvbmVkc2wu
aXQpIGEgcmVqb2ludCAjeGVuCiogY3J5cHRvenVsdSAofmxvcmRfbW9uZUAxOTYtMjEwLTE3Mi0y
MjEuZHluYW1pYy5pc2Fkc2wuY28uemEpIGEgcXVpdHTDqSAjeGVuICgiQmUgYmFjayBpbiBhIGJp
dCIpCjxnb29uXz4gbXkgZXJyb3Igc3RhbmRzIGluIEtleUVycm9yOiAnLnRleHQuYXNtLi9ob21l
L2dvb24veGVuL3Rvb2xzL2Zpcm13YXJlL3NlYWJpb3MtZGlyLXJlbW90ZS9zcmMvZncvc21wLmMu
NzknCjxnb29uXz4gUHJ5TWFyNTYsIG9rLCBpcyBpdCBub3JtYWwgdGhhdCBJIGdldCAyIGRpcmVj
dG9yaWVzPyBvbmUgY2FsbGVkIHNlYWJpb3MtZGlyIGFuZCB0aGUgb3RoZXIgb25lIGNhbGxlZCBz
ZWFiaW9zLWRpci1yZW1vdGUgd2l0aCBmaWxlcyBhbGlrZT8KPFByeU1hcjU2PiBJSVJDLCB0aGUg
Ki1yZW1vdGUgaXMgdGhlIHJlc3VsdCBvZiBhIHJlbW90ZSBnaXQgY2xvbmUuIERpZG4ndCB5b3Ug
aGF2ZSBhIGxvY2FsIGRpcj8KKiBkYXJpb2YgKH5kYXJpb2ZAbmV0LTItMzktNzAtMTAzLmN1c3Qu
dm9kYWZvbmVkc2wuaXQpIGEgcXVpdHTDqSAjeGVuCjxnb29uXz4gUHJ5TWFyNTYsIEkgaGF2ZSBh
IGxvY2FsIHNlYWJpb3MtZGlyLCBidXQgZHVyaW5nIG1ha2UgZGlzdCwgdGhlcmUgYXJlIGZpbGVz
IGRvd25sb2FkZWQgdG8gdGhhdCByZW1vdGUKPFByeU1hcjU2PiBvbmUgbWlnaHQgYmUgc3ltbGlu
a2VkIHRvIHRoZSBvdGhlciwgZG9uCjxQcnlNYXI1Nj4gZG9uJ3QgcmVtZW1iZXIKPGdvb25fPiB0
aGV5IGFyZSBub3Qgc28gc3ltbGlua2VkCiogb21hcnJyIGVzdCBwYXJ0aSAoUmVtb3RlIGhvc3Qg
Y2xvc2VkIHRoZSBjb25uZWN0aW9uKQo8UHJ5TWFyNTY+IG9rLCBpZiB5b3Ugd2FudCB0aGUgbG9j
YWwgc2VhYmlvcyBkaXIgaW4gdGhlIHJjWCBidWlsZCB0cmVlLCB0aGVuIHJlZXh0cmFjdCB0aGUg
dGFyLmd6IGFuZCBjb3B5IHlvdXIgc2VhYmlvcyB0byBzZWFiaW9zLWRpcgo8UHJ5TWFyNTY+IHRo
ZW4gdGhlIGJ1aWxkIHdpbGwgdXNlIHlvdXIgZGlyIGFuZCBmb3JnZXQgYWJvdXQgYSByZW1vdGUg
Y2xvbmUKPFByeU1hcjU2PiBJIGhhdmUgZG9uZSB0aGlzIG15c2VsZi4gSSBhbSBub3QgYmxvd2lu
ZyBzbW9rZQo8UHJ5TWFyNTY+IGJlZm9yZSB5b3UgYG1ha2UgZGlzdC10b29sc2AgeW91ciBzZWFi
aW9zIHNob3VsZCBiZSBpbiAuL3Rvb2xzL2Zpcm13YXJlL3NlYXJiaW9zLWRpcgo8Z29vbl8+IFBy
eU1hcjU2LCBvaywgZG93bmxvYWRpbmcgSSBzZWUgdGhhdCB0aGUgdGFyIHZlcnNpb24gaXMgMS43
LjUuMSB2cyAxLjcuNSBvbiBnaXRodWIKPGdvb25fPiB3aWxsIGRvIHRoYXQKPGdvb25fPiBQcnlN
YXI1Niwgc28gc2VhYmlvcy1kaXIgd2FzIHN5bWxpbmtlZCwgaSByZWFzc2lnbmVkIGl0IHRvIG15
IGV4dHJhY3RlZCBzZWFiaW9zIHRhciBhbmQgd2lsbCBzZWUgaG93IGl0IGdvZXMKPGdvb25fPiBQ
cnlNYXI1NiwgdGhlcmUgaXMgbm8gMTZiaXQgc3BlY2lmaWMgbGlicmFyaWVzIHRvIGluc3RhbGwg
aW4gb3JkZXIgdG8gY29tcGlsZSBzZWFiaW9zPwo8UHJ5TWFyNTY+IGh0dHA6Ly9wYXN0ZWJpbi5j
b20vbUMwZ2I3NWkKPFByeU1hcjU2PiBeXiBmcm9tIGEgYnVpbGQgeWVzdGVyZGF5IHdoZXJlIEkg
Y29waWVkIGluIGEgbG9jYWwgc2VhYmlvcy4gQnVpbGQgd2VudCBvZmYgYXQgMTc6MDAKPFByeU1h
cjU2PiBzZWFiaW9zIHdhcyB0YXJyZWQgdXAgb24gTm92OQo8UHJ5TWFyNTY+IGl0cyBvbiBDZW50
b3M3Cjxnb29uXz4gb2ssIGJ1dCBpdCBpcyBibG9ja2luZyBmb3IgbWUgb24gZGViaWFuIHdpbGwg
c2VuZCBtYWlsIHRvIHhlbiBkZXZlbAo8Z29vbl8+IDovCjxQcnlNYXI1Nj4gZGViaWFuIGhhcyB0
aWdodGVuZWQgdXAgdGhlIGJhc2ggc2VjdXJpdHkuLi4gL2Jpbi9zaCBpcyBub3QgYmFzaC4uLiBj
YXVzZWQgbWUgaGVhZGFjaGVzCjxnb29uXz4gOikgeWVhaCB3ZWxsIHNlbGludXggZG9lcyB0aGF0
IHRvIHNvbWUgaGFzIHdlbGwKPGdvb25fPiB3aWxsIHRyeSB3aXRoIHByZXZpb3VzIHRhciB2ZXJz
aW9uIChzdGFydGluZyB3aXRoIDEuNzQKPGdvb25fPiBQcnlNYXI1NiwgdGhlcmUgcmVhbGx5IG11
c3QgYmUgYSBzY3JpcHQgZXJyb3Igb3Igc210ZyBGaWxlICIuL3NjcmlwdHMvbGF5b3V0cm9tLnB5
IiwgbGluZSA3MDgsIGluIDxtb2R1bGU+Cjxnb29uXz4gICAgIG1haW4oKQo8Z29vbl8+ICAgRmls
ZSAiLi9zY3JpcHRzL2xheW91dHJvbS5weSIsIGxpbmUgNjcwLCBpbiBtYWluCjxnb29uXz4gICAg
IGluZm8xNiA9IHBhcnNlT2JqRHVtcChpbmZpbGUxNiwgJzE2JykKPGdvb25fPiAgIEZpbGUgIi4v
c2NyaXB0cy9sYXlvdXRyb20ucHkiLCBsaW5lIDU4NSwgaW4gcGFyc2VPYmpEdW1wCjxnb29uXz4g
ICAgIHJlbG9jc2VjdGlvbiA9IHNlY3Rpb25tYXBbc2VjdGlvbm5hbWVdCjxnb29uXz4gQ0FOIElU
IEJFIFBZVEhPTiBSRUxBVEVEPwo8Z29vbl8+IHNvcnJ5Cjxnb29uXz4gUHJ5TWFyNTYsIGNhbiBp
dCBiZSB0aHp0IEkgbmVlZCB0byBwb2ludCB0byBweXRob24gcmVnYXJkaW5nIHRoZSBTZWFiaW9z
IHBhcnQKPGdvb25fPiBQcnlNYXI1NiwgaXQncyB0aGUgbG9jYWxlIGJ1ZmcKPGdvb25fPiA6LyBy
ZXBvcnRlZCBmb3Igc2VhYmlvcyBhbmQgNC4yLCBJIGhhdmUgZnJlbmNoIGtleWJvYXJkCjxnb29u
Xz4gOigKPGdvb25fPiBQcnlNYXI1Niwgc3R1cGlkLCBhcyB1c3VhbAo8Z29vbl8+IFByeU1hcjU2
LCBJIG1lYW4gc3R1cGlkIGJ1Z3MsIGFuZCBtZQoqIEd1ZXN0ODQ0NDQgcydhcHBlbGxlIG1haW50
ZW5hbnQgc2FyaWQKKiBzYXJpZCBlc3QgcGFydGkgKENoYW5naW5nIGhvc3QpCiogc2FyaWQgKH5z
YXJpZEB1bmFmZmlsaWF0ZWQvc2FyaWQpIGEgcmVqb2ludCAjeGVuCiogc3BoZW54ZXMgZXN0IHBh
cnRpIChSZW1vdGUgaG9zdCBjbG9zZWQgdGhlIGNvbm5lY3Rpb24pCjxnb29uXz4gT2sgaXQgaXMg
YnVpbGRpbmcgYmV5b25kIHRoZSBmaXJtd2FyZSBwb2ludCBub3cKKiByeWFuLWF1ICh+cXVhc3Nl
bEAxNzIuYnJzMDEwOS5icnMuaXByaW11cy5uZXQuYXUpIGEgcmVqb2ludCAjeGVuCiogZmFuZGkg
ZXN0IHBhcnRpIChRdWl0OiBMZWF2aW5nKQoqIGdlYWFydSBlc3QgcGFydGkgKFF1aXQ6IExlYXZp
bmcpCiogZGFyaW9mICh+ZGFyaW9mQG5ldC0yLTM5LTcwLTEwMy5jdXN0LnZvZGFmb25lZHNsLml0
KSBhIHJlam9pbnQgI3hlbgoqIGRhcmlvZiAofmRhcmlvZkBuZXQtMi0zOS03MC0xMDMuY3VzdC52
b2RhZm9uZWRzbC5pdCkgYSBxdWl0dMOpICN4ZW4KKiBnb29uaWVCIGVzdCBwYXJ0aSAoUmVhZCBl
cnJvcjogQ29ubmVjdGlvbiByZXNldCBieSBwZWVyKQoqIETDqWNvbm5lY3TDqSAoQ29ubmV4aW9u
IHLDqS1pbml0aWFsaXPDqWUgcGFyIGxlIGNvcnJlc3BvbmRhbnQpLgoqIGdvb24gZXN0IGTDqWrD
oCB1dGlsaXPDqS4gUsOpZXNzYWkgYXZlYyBnb29uXy4uLgoqIGdvb25fIGFjdGl2ZSBsZSBtb2Rl
ICtpIGdvb25fCiogVm91cyBwYXJsZXogbWFpbnRlbmFudCBzdXIgI3hlbgoqIExlIHN1amV0IGRl
ICN4ZW4gZXN0wqA6IFhlbiA0LjQuMSByZWxlYXNlZCEgaHR0cDovL3d3dy54ZW5wcm9qZWN0Lm9y
Zy9kb3dubG9hZHMuaHRtbCB8IFdpa2k6IGh0dHA6Ly93aWtpLnhlbnByb2plY3Qub3JnLyB8IEZB
UTogaHR0cDovL3dpa2kueGVucHJvamVjdC5vcmcvd2lraS9YZW5fQ29tbW9uX1Byb2JsZW1zCiog
U3VqZXQgZGUgI3hlbiBkw6lmaW5pIHBhciBLZXZpbmAgbGUgV2VkIFNlcCAgMyAyMzoyNzozNyAy
MDE0CiogW05vQ2xhbl1Hb0F3YXkgKH5Db21lQWdhaW5ANS4xOTkuMTYyLjE0KSBhIHF1aXR0w6kg
I3hlbiAoIlZlcmxhc3NlbmQiKQoqIETDqWNvbm5lY3TDqSAoQ29ubmV4aW9uIHLDqS1pbml0aWFs
aXPDqWUgcGFyIGxlIGNvcnJlc3BvbmRhbnQpLgoqIFZvdXMgcGFybGV6IG1haW50ZW5hbnQgc3Vy
ICN4ZW4KKiBMZSBzdWpldCBkZSAjeGVuIGVzdMKgOiBYZW4gNC40LjEgcmVsZWFzZWQhIGh0dHA6
Ly93d3cueGVucHJvamVjdC5vcmcvZG93bmxvYWRzLmh0bWwgfCBXaWtpOiBodHRwOi8vd2lraS54
ZW5wcm9qZWN0Lm9yZy8gfCBGQVE6IGh0dHA6Ly93aWtpLnhlbnByb2plY3Qub3JnL3dpa2kvWGVu
X0NvbW1vbl9Qcm9ibGVtcwoqIFN1amV0IGRlICN4ZW4gZMOpZmluaSBwYXIgS2V2aW5gIGxlIFdl
ZCBTZXAgIDMgMjM6Mjc6MzcgMjAxNAoqIGRlbW9ua2VlcGVyIHMnYXBwZWxsZSBtYWludGVuYW50
IGRhZW1vbmtlZXBlcgoqIE9zZW5wYWkgKH5Pc2VucGFpQDE5MS4yNDkuNy4xNDMpIGEgcmVqb2lu
dCAjeGVuCiogcnRzcndyICh+c3J3ckAxOTIuMTYyLjEwMS4xNSkgYSByZWpvaW50ICN4ZW4KKiB0
b2Rkd2FyZHppbnNraSAofnRvZGR3YXJkekAxMzcuc3ViLTcwLTE5Mi0yMDYubXl2encuY29tKSBh
IHJlam9pbnQgI3hlbgoqIHBhamFtaWFuIHMnYXBwZWxsZSBtYWludGVuYW50IHBqCiogcnRzcndy
IGVzdCBwYXJ0aSAoUGluZyB0aW1lb3V0OiAyNTggc2Vjb25kcykKKiBydHNyd3IgKH5zcndyQDE3
OC44Ni4xMy4yMzQpIGEgcmVqb2ludCAjeGVuCiogZmFuZGkgZXN0IHBhcnRpIChQaW5nIHRpbWVv
dXQ6IDI0NSBzZWNvbmRzKQoqIGNvb2xkaGFybWEwNiBlc3QgcGFydGkgKFF1aXQ6IENoYXRaaWxs
YSAwLjkuOTEuMSBbSWNld2Vhc2VsIDIxLjAvMjAxMzA1MTUxNDAxMzZdKQoqIGZhbmRpICh+ZmFu
ZGlAMTAxLjI1NS4zNi42NikgYSByZWpvaW50ICN4ZW4KKiBmYW5kaSBlc3QgcGFydGkgKEV4Y2Vz
cyBGbG9vZCkKKiBmYW5kaSAofmZhbmRpQDEwMS4yNTUuMzYuNjYpIGEgcmVqb2ludCAjeGVuCiog
dG9kZHdhcmR6aW5za2lfICh+dG9kZHdhcmR6QHBvb2wtNzItODMtMTEtNTYud2FzaGRjLmZpb3Mu
dmVyaXpvbi5uZXQpIGEgcmVqb2ludCAjeGVuCiogdG9kZHdhcmR6aW5za2kgZXN0IHBhcnRpIChQ
aW5nIHRpbWVvdXQ6IDI0MCBzZWNvbmRzKQoqIHF1ZWVxIGVzdCBwYXJ0aSAoUGluZyB0aW1lb3V0
OiAyNTggc2Vjb25kcykKKiBmaXJlZ2xvdyAoZmlyZWdsb3dAdW5hZmZpbGlhdGVkL2ZpcmVnbG93
KSBhIHJlam9pbnQgI3hlbgoqIHF1ZWVxICh+cXVlZXFAODAuMjU1LjY0LjIxNSkgYSByZWpvaW50
ICN4ZW4KKiBxdWVlcSBlc3QgcGFydGkgKENoYW5naW5nIGhvc3QpCiogcXVlZXEgKH5xdWVlcUB1
bmFmZmlsaWF0ZWQvcXVlZXEpIGEgcmVqb2ludCAjeGVuCiogRMOpY29ubmVjdMOpIChDb25uZXhp
b24gcsOpLWluaXRpYWxpc8OpZSBwYXIgbGUgY29ycmVzcG9uZGFudCkuCiogVm91cyBwYXJsZXog
bWFpbnRlbmFudCBzdXIgI3hlbgoqIExlIHN1amV0IGRlICN4ZW4gZXN0wqA6IFhlbiA0LjQuMSBy
ZWxlYXNlZCEgaHR0cDovL3d3dy54ZW5wcm9qZWN0Lm9yZy9kb3dubG9hZHMuaHRtbCB8IFdpa2k6
IGh0dHA6Ly93aWtpLnhlbnByb2plY3Qub3JnLyB8IEZBUTogaHR0cDovL3dpa2kueGVucHJvamVj
dC5vcmcvd2lraS9YZW5fQ29tbW9uX1Byb2JsZW1zCiogU3VqZXQgZGUgI3hlbiBkw6lmaW5pIHBh
ciBLZXZpbmAgbGUgV2VkIFNlcCAgMyAyMzoyNzozNyAyMDE0CjxQcnlNYXI1Nj4gNC41IEhFQUQ6
IHBvc3QgcmM0IGJ1ZyBsaWJ4bDogZXJyb3I6IGxpYnhsX2RvbS5jOjM2OmxpYnhsX19kb21haW5f
dHlwZTogdW5hYmxlIHRvIGdldCBkb21haW4gdHlwZSBmb3IgZG9taWQ9Nwo8UHJ5TWFyNTY+IG5v
IFZtIGNhbiBzdGFydAoqIHNlYmEgZXN0IHBhcnRpIChFeGNlc3MgRmxvb2QpCjxwYXNpaz4gUHJ5
TWFyNTY6IHlvdSBzaG91bGQgcmVwb3J0IGJ1Z3MgdG8geGVuLWRldmVsIG1haWxpbmdsaXN0Li4K
PFByeU1hcjU2PiBwYXNpaywgY29tcG9zaW5nIG5vdwo8cGFzaWs+IGdvb2Q6KQo8cGFzaWs+IFBy
eU1hcjU2OiB5b3Ugc3VyZSB5b3UgcmVtb3ZlZCBhbGwgdGhlIHByZXZpb3VzIHhlbiBiaXRzIGJl
Zm9yZSB1cGdyYWRpbmcgdG8gcmM0KyB2ZXJzaW9uPwo8cGFzaWs+IFByeU1hcjU2OiBzbyBpdCdz
IG5vdCBidWlsZC9pbnN0YWxsYXRpb24gaXNzdWU/CiogR3JvcGlfXyBlc3QgcGFydGkgKFF1aXQ6
IFZlcmxhc3NlbmQpCiogc2ViYSAofnNlYmFAa3JhdHpiYXVtLnNvbWVzZXJ2ZXIuZGUpIGEgcmVq
b2ludCAjeGVuCjxQcnlNYXI1Nj4gZXZlcnl0aW1lIEkgdGVzdCBJIGRpc2FibGUgYWxsIHhlbnNl
cnZpY2VzLCBhbmQgeXVtIHVuaW5zdGFsbCB4ZW4qCjxQcnlNYXI1Nj4gYW5kIGluc3RhbGwgd2l0
aCB0aGUgbmV3IHJwbSBzZXQKKiBkd2ZyZWVkIHdvdWxkIGp1c3QgcmVkZXBsb3kgdGhlIGhvc3QK
KiBvbWFycnIgZXN0IHBhcnRpIChRdWl0OiBMZWF2aW5nKQo8YnJhbV8+IDIyCjxQcnlNYXI1Nj4g
dG8gbWFrZSBwb3N0IHJjNCBwYXRjaDogZ2l0IGRpZmYgeGVuLTQuNS4wLXJjNCA+IGhlYWQ0NS5w
YXRjaAo8UHJ5TWFyNTY+IHRoZW4gYXBwbHkgaXQgdG8gcmM0IHRhcmJhbGwKPFByeU1hcjU2PiBu
b3Qgc3VyZSB0aGF0IGlzIDEwMCUgcmlnaHQKKiBzZWJhIGVzdCBwYXJ0aSAoRXhjZXNzIEZsb29k
KQoqIHNlYmEgKH5zZWJhQGtyYXR6YmF1bS5zb21lc2VydmVyLmRlKSBhIHJlam9pbnQgI3hlbgo8
UHJ5TWFyNTY+IGl0cyB0aGUgc2FtZSBhcyBgZ2l0IGRpZmYgNjBjZTUxOGExYmAKKiBGYW50dSBl
c3QgcGFydGkgKFF1aXQ6IENoYXRaaWxsYSAwLjkuOTEuMSBbRmlyZWZveCAzNC4wLjUvMjAxNDEx
MjYwNDEwNDVdKQoqIENyb3RoZXJzICh+Y3JvdGhlcnNAdW5hZmZpbGlhdGVkL2Nyb3RoZXJzKSBh
IHJlam9pbnQgI3hlbgoqIGl2YW5cIGVzdCBwYXJ0aSAoUGluZyB0aW1lb3V0OiAyNDQgc2Vjb25k
cykKKiBpdmFuXCAofml2YW5AdW5hZmZpbGlhdGVkL2l2YW4veC0wMDAwMDEpIGEgcmVqb2ludCAj
eGVuCiogYW5kZXJzb25jMGQzIGVzdCBwYXJ0aSAoUGluZyB0aW1lb3V0OiAyNTggc2Vjb25kcykK
KiBLYWJha2EgKGthYmFrYUBlcXVpbmUudmFjYW50bWluZGVkLmNvbSkgYSByZWpvaW50ICN4ZW4K
KiBWb3VzIHBhcmxleiBtYWludGVuYW50IHN1ciAjeGVuCiogTGUgc3VqZXQgZGUgI3hlbiBlc3TC
oDogWGVuIDQuNC4xIHJlbGVhc2VkISBodHRwOi8vd3d3LnhlbnByb2plY3Qub3JnL2Rvd25sb2Fk
cy5odG1sIHwgV2lraTogaHR0cDovL3dpa2kueGVucHJvamVjdC5vcmcvIHwgRkFROiBodHRwOi8v
d2lraS54ZW5wcm9qZWN0Lm9yZy93aWtpL1hlbl9Db21tb25fUHJvYmxlbXMKKiBTdWpldCBkZSAj
eGVuIGTDqWZpbmkgcGFyIEtldmluYCBsZSBXZWQgU2VwICAzIDIzOjI3OjM3IDIwMTQKPFByeU1h
cjU2PiBwYXRjaGVkIHJjNCB3b3JrcyBpbiBkZWI4Li4gbXVzdCBiZSBhbiBlcnJvciBpbiBwYWNr
YWdpbmcgb24gQzcgdGhhdCBicm9rZSB4ZW4KPFByeU1hcjU2PiBhbmQgaXRzIG15IGVycm9yIGFu
ZCBvbmx5IG15IGVycm9yCjxnb29uXz4gaGVsbG8gdGhlcmUsIGNvbXBpbGVkIDQuNSB4bCB3ZW50
IG9rIGF0IGxhc3QsIEkgdHJ5ZWQgdG8gaW5zdGFsbCBpdCB2aWEgZGViYmFsbCBhbmQgZHBrZywg
aXQKPFByeU1hcjU2PiBoaQo8UHJ5TWFyNTY+IGdvb25fLCBzYXcgeW91ciBwb3N0IG9uIHhlbi1k
ZXZlbCBhbmQgdHJpZWQgdG8gZm9sbG93IGFsb25nCjxnb29uXz4gUHJ5TWFyNTYsIGhpLCBzbyB0
cnlpbmcgdG8gaW5zdGFsbCB3b3JrcyBidXQgSSBneXVlc3MgaSBoYXZlIGxpYnJhcnkgcHJvYmxl
bXM6bGlieGw6IGVycm9yOiBsaWJ4bC5jOjEwOTpsaWJ4bF9jdHhfYWxsb2M6IGNhbm5vdCBvcGVu
IGxpYnhjIGhhbmRsZTogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQo8Z29vbl8+IGNhbm5vdCBp
bml0IHhsIGNvbnRleHQKPFByeU1hcjU2PiBkZWJiYWxsID09IGBtYWtlIGRpc3RgICsgYGZha2Vy
b290ICQocHdkKSA0LjUuMC1yYzRgCjxnb29uXz4gUHJ5TWFyNTYsIHNvIHlvdSBwYXRjaGVkIGFz
IHdlbGwgYW5kPyAuLi4KPFByeU1hcjU2PiBnb29uXywgSSBhbSBwYXRjaGluZyBmcm9tIDQuNSBI
RUFEIG9uIHJjNCwgbm90IHRyeWluZyB0byBnZXQgcXhsIHVwLCBhbHRob3VnaCBJIGVuYWJsZSBz
cGljZQo8Z29vbl8+IFByeU1hcjU2LCB3aHkgbm90IGVuYWJsaW5nIGl0IGJ5IGRlZmF1bHQsIHRo
aXMgSSBkb24ndCBnZXQgaXQuLgo8UHJ5TWFyNTY+IGdvb25fLCB0cnkgdGhpczogZm9yIGkgaW4g
eGwgb3hlbnN0b3JlZCBxZW11LXN5c3RlbS1pMzg2O2RvIHN1ZG8gbGRkICQod2hpY2ggJGkpOyBk
b25lCjxQcnlNYXI1Nj4gXl4gdmVyaWZ5cyB5b3VyIHJvb3QgcGF0aCBhbmQgbGliIHBhdGgKPFBy
eU1hcjU2PiBkZWJiYWxsID09IGBtYWtlIGRpc3RgICsgYGZha2Vyb290IC4vdG9vbHMvbWlzYy9t
a2RlYiAkKHB3ZCkgNC41LjAtcmM0YAo8Z29vbl8+IFByeU1hcjU2LCBodHRwOi8vcGFzdGViaW4u
Y29tL1ZVOW5iSnlIIGlzIHRoZSByZXN1bHQgb2YgbGliIGNoZWNrcyB3aXRoIGZvciBpIGluIHhs
IG94ZW5zdG9yZWQgcWVtdS1zeXN0ZW0taTM4NjtkbyBzdWRvIGxkZCAkKHdoaWNoICRpKTsgZG9u
ZQo8Z29vbl8+IFByeU1hcjU2LCBJJ3ZlIHJlYWQgdGhlcmUgYXJlIHRoaW5ncyB0byBzZXR1cCBy
ZWdhcmRpbmcgbGlicy4uLgo8UHJ5TWFyNTY+IGdvb25fLCB0ZXN0IHBhc3NlcyBwZXJmZWN0Cjxn
b29uXz4gQnVpbGQgcGFzc2VzIHBlcmZlY3RseSBmb3IgbWUgeWVzCjxQcnlNYXI1Nj4geW91ciBy
b290IHBhdGggYW5kIGxpYiBwYXRoIGlzIHNldHVwIGdvb2QgZm9yIHhlbgo8UHJ5TWFyNTY+IEkg
Y2FuIHNlZSB0aGF0IGluIHlvdXIgcGFzdGViaW4KPGdvb25fPiBzbyB3aGF0J3MgdGhlIGlzc3Vl
IHdpdGggbGlieGMgaGFuZGxlCjxnb29uXz4gPwo8UHJ5TWFyNTY+IHlvdXIgZ2V0IGVycm9yIG9u
IHB2IGFuZCBodm0gdHlwZSBWTT8KPFByeU1hcjU2PiBxeGwgaXMgZm9yIGh2bSBkb21VLCBidXQg
dHJ5IHRlc3RpbmcgYSBwdiBkb21VIHRvbwo8Z29vbl8+IGEgc2ltcGxlIHhsIGxpc3QgZ2l2ZXMg
bWUgbGlieGw6IGVycm9yOiBsaWJ4bC5jOjEwOTpsaWJ4bF9jdHhfYWxsb2M6IGNhbm5vdCBvcGVu
IGxpYnhjIGhhbmRsZTogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQo8UHJ5TWFyNTY+IGRlYjgg
KGplc3NpZSkgb3IgaGlnaGVyPwo8Z29vbl8+IGRlYjggdW5zdGFibGUKPFByeU1hcjU2PiB0aGF0
IGxvb2tzIGxpa2Ugbm8gaHlwZXJ2aXNvcgo8UHJ5TWFyNTY+IGxzbW9kIHwgZ3JlcCB4ZW4gaXMg
ZW1wdHk/Cjxnb29uXz4gUHJ5TWFyNTYsIHllcwo8Z29vbl8+IHdoaWNoIHBhY2thZ2VzIHNob3Vs
ZCBJIHJlbW92ZSBmcm9tIHRoZSBzeXN0ZW0gYmVmb3JlIGluc3RhbGxpbmc/Cjxnb29uXz4gSSBy
ZW1vdmUgYSBidW5jaCBidSBsZWZ0IHRoZSBoeXBlcnZpc29yIGZyb20gNC40LjEKPFByeU1hcjU2
PiBnb29uXywgZ3JlcCB4ZW5mcyAvdXNyL2xpYi9tb2R1bGVzLWxvYWQuZC94ZW4uY29uZgo8Z29v
bl8+IHRoaW5raW5nIHRoZXknZCBjb2V4aXN0LCBzYW1lIHdheSBhcyBteSA0LjEgYW5kIDQuNC4x
IHRoYXQgSSBjYW4gcGljayBhdCBzdGFydHVwCjxnb29uXz4gUHJ5TWFyNTYsIG5vdGhpbmcgY29t
aW5nIG91dAo8UHJ5TWFyNTY+IGlmIHRoYXQgeGVuLmNvbmYgaXMgdGhlcmUsIHRoZW4gYXBwZW5k
IHhlbmZzCjxQcnlNYXI1Nj4gd2l0aG91dCBpdCwgeW91ciB4ZW4gc2VydmljZXMgd2lsbCBmYWls
IHRvIHN0YXJ0Cjxnb29uXz4gYnV0IHRoZSBmaWxlIGlzIG1pc3NpbmcsIHRvdWNoIGl0IGFuZCBh
ZGQgeGVuZnM/Ciogc3BoZW54ZXMgZXN0IHBhcnRpIChSZWFkIGVycm9yOiBDb25uZWN0aW9uIHJl
c2V0IGJ5IHBlZXIpCjxQcnlNYXI1Nj4gb2gsIGRvIG5vdGhpbmcgdW5sZXNzIHlvdSBhcmUgaW5z
dGFsbGluZyB0aGUgcmM0IGRlYiB3aXRoIHN5c3RlbWQKPGdvb25fPiBZZXMgSSBhZGRlZCBzeXN0
ZW1kLAo8UHJ5TWFyNTY+IGNoZWNrIHN1ZG8gZHBrZyAtTCB4ZW4tdXBzdHJlYW0gfCBncmVwIHhl
bi5jb25mCjxnb29uXz4gUHJ5TWFyNTYsIG5vdGhpbmcKPGdvb25fPiA6Lwo8UHJ5TWFyNTY+IGhv
dyBhYm91dDogZHBrZyAtbCB8IGdyZXAgeGVuCjxnb29uXz4gaHR0cDovL3Bhc3RlYmluLmNvbS9q
em4yTkhFYgo8UHJ5TWFyNTY+IHB1cmdlIGFsbCBhbmQgc3RhcnQgb3ZlciB3aXRoIDQuNQo8Z29v
bl8+IFByeU1hcjU2LCBhY3R1YWxseSB5b3Ugd3JvdGUgYSBMIGluc3RlYWQgb2YgYSBsCjxQcnlN
YXI1Nj4geW91IGhhdmUgdG9vIG11Y2ggZnJvbSA0LjQKKiBhcmVzY29ycGlvICh+YXJlc2NvcnBp
QDIxNy01Ny0yNDUtMTkwLmZpYmVydGVsLmNvbS5hcikgYSByZWpvaW50ICN4ZW4KPFByeU1hcjU2
PiBwdXJnZSBhbnl0aGluZyB4ZW4KPFByeU1hcjU2PiBzZXJpb3VzbHksIHlvdSBjYW4gZG8gYSBm
cmVzaCBpbnN0YWxsIHF1aWNrZXIgdGhhbiBiYWNraW5nIG91dCBhbGwgdGhlIG9sZCB4ZW4gKmRl
YnMKKiBza3lsaXRlIGVzdCBwYXJ0aSAoUXVpdDogVGV4dHVhbCBJUkMgQ2xpZW50OiB3d3cudGV4
dHVhbGFwcC5jb20pCjxnb29uXz4gb2ssIEkndmUgcHVyZ2VkLCBzbyBJIGp1c3QgZHBrZyAtaSB4
ZW4uLi4uLi47Cjxnb29uXz4gPwo8Z29vbl8+IFByeU1hcjU2LCAgdGhhbmsgeW91IEJUVwoqIE5v
dGlmeTogUHJ5TWFyNTYgZXN0IGVuIGxpZ25lIChGcmVlTm9kZSkuCjxnb29uXz4gUHJ5TWFyNTYs
IEkndmUgaW5zdGFsbGVkIHRoZSBwYWNrYWdlCjxnb29uXz4gc2hvdWxkIEkgcmVib290Pwo8UHJ5
TWFyNTY+IHRoYXQgdXBzdHJlYW0gZGViIHdpbGwgbm90IHNldHVwIGdydWIyLCBzbyBjaGVjayB0
aGF0IGZpcnN0Cjxnb29uXz4gaG93IGRvIEkgc2V0IGl0IHVwPwo8UHJ5TWFyNTY+IGdydWItbWs8
dGFiPiAgIDwtLSB3aWxkIGd1ZXNzCjxQcnlNYXI1Nj4gbHMgLWFsIC9ldGMvZ3J1Yi5kLwo8UHJ5
TWFyNTY+IGFueSAwOV8gPwo8Z29vbl8+IGdydWJfbWtjb25maWc/CjxQcnlNYXI1Nj4gZmlyc3Qg
Y2hlY2s6ICBscyAtYWwgL2V0Yy9ncnViLmQvCjxnb29uXz4gYWZ0ZXIgdGhhdCB0aGVyZSBpcyBv
bmUgKC1yd3hyLXhyLXggICAxIHJvb3Qgcm9vdCAxMDQxOCBkw6ljLiAgIDIgMjM6MDQgMDlfbGlu
dXhfeGVuCjxnb29uXz4gKQo8UHJ5TWFyNTY+IGluc2lkZSAwOV9saW51eF94ZW4gLi4uIGxvb2sg
Zm9yIHN5bWxpbmtzIGZvciB4ZW4uZ3oKPFByeU1hcjU2PiB5b3VyIGJvb3QgbWF5IHN0YXJ0IHhl
biBhcyB0aGluZyBhcmUsIGJ1dCBubyBndWFyYW50ZWUKPGdvb25fPiB3aWxsIGdpdmUgaXQgYSB0
cnksIGJlIGJhY2sgaW4gYSBtaW51dGUuLi5ob3BlZnVsbHkKKiBWb3VzIHBhcmxleiBtYWludGVu
YW50IHN1ciAjeGVuCiogTGUgc3VqZXQgZGUgI3hlbiBlc3TCoDogWGVuIDQuNC4xIHJlbGVhc2Vk
ISBodHRwOi8vd3d3LnhlbnByb2plY3Qub3JnL2Rvd25sb2Fkcy5odG1sIHwgV2lraTogaHR0cDov
L3dpa2kueGVucHJvamVjdC5vcmcvIHwgRkFROiBodHRwOi8vd2lraS54ZW5wcm9qZWN0Lm9yZy93
aWtpL1hlbl9Db21tb25fUHJvYmxlbXMKKiBTdWpldCBkZSAjeGVuIGTDqWZpbmkgcGFyIEtldmlu
YCBsZSBXZWQgU2VwICAzIDIzOjI3OjM3IDIwMTQKPGdvb25fPiB3ZWxsLCBpJ20gYmFjawo8UHJ5
TWFyNTY+IHRyeSB0aGlzIHNjcmlwdCB0byBlbmFibGUvZGlzYWJsZSB4ZW4gc2VydmljZXM6IGh0
dHA6Ly9wYXN0ZWJpbi5jb20vSEhoMGEyV2gKPFByeU1hcjU2PiBeXiBpdCBvbmx5IGFwcGxpZXMg
dG8gc3lzdGVtZCBzZXR1cCwgbm90IHN5c3YKPFByeU1hcjU2PiBhbHNvOiBjZCAvZXRjL2luaXQu
ZDsgbXYgeGVuZG9tYWlucyB4ZW5kb21haW5zLnN5c3YKPGdvb25fPiBQcnlNYXI1Niwgc2NyaXB0
IGdpdmVzIDQgRmFpbGVkIHRvIGV4ZWN1dGUgb3BlcmF0aW9uOiBObyBzdWNoIGZpbGUgb3IgZGly
ZWN0b3J5CjxQcnlNYXI1Nj4gZmluZCB5b3VyIHhlbi11cHN0cmVhbS4gZHBrZy1kZWIgLWMgeGVu
LXVwc3RyZWFtKiB8IGdyZXAgc3lzdGVtZAo8UHJ5TWFyNTY+IEkgZ2V0IDkgZW50cmllcwo8Z29v
bl8+IFByeU1hcjU2LCBzaG91bGQgdGhlIHNjcmlwdCBiZSBpbiAvZXRjL2luaXQuZCAgb3Igc29t
ZXRoaW5nPwo8Z29vbl8+IEkgaGF2ZSBub25lPwo8Z29vbl8+ICEKPFByeU1hcjU2PiBkcGtnIC1p
IHhlbi11cHN0cmVhbSoKPFByeU1hcjU2PiBkcGtnIC1sIHhlbi11cHN0cmVhbSB8IHdjIC1sICA8
LS0gYWJvdXQgODAwCjxQcnlNYXI1Nj4gICAtTAo8Z29vbl8+IDEwOAo8Z29vbl8+IDovCjxnb29u
Xz4gbm90IGZ1bGx5IGJ1aWx0IG9yIHNvPwo8UHJ5TWFyNTY+IG9oLCB5b3Ugb25seSBkaWQgbWFr
ZSBkaXN0LXRvb2xzCjxQcnlNYXI1Nj4geW91IHdhbnQgYG1ha2UgZGlzdGAKPFByeU1hcjU2PiBp
ZiB5b3UgYXJlIHRlc3RpbmcgdGhlIGZpcm13YXJlIGJ1aWxkLCBzdXJlLCBgbWFrZSBkaXN0LXRv
b2xzYCAgIDwtLSBpcyBlbm91Z2gKPGdvb25fPiBvdXBzLCBtYXliZSBJIHdhcyBkaXN0cmFjdGVk
LCBsZXQgbWUgc2VlCjxQcnlNYXI1Nj4gb24gbXkgNSB5ZWFycyBvbGQgaHcsIHhlbiBidWlsZHMg
aW4gMTcgbWludXRlcwo8UHJ5TWFyNTY+IGFuZCB0aGF0IGlzIG9uIERlYjgsIEM3IGlzIDIyIG1p
bnV0ZXMKPGdvb25fPiBJIGhhdmUgZG9uZSBhIG1ha2UgZGViYmFsbCAoIGlzbid0IHRoYXQgZW5v
dWdoPykKPGdvb25fPiBvayBzbyBtYWtlIGRpc3RjbGVhbiAvIC4vY29uZmlndXJlIGFuZCB0aGVu
IG1ha2UgZGlzdCBhbmQgdGhlbiBtYSxrZSBkZWJiYWxsPwo8UHJ5TWFyNTY+IHllcwo8UHJ5TWFy
NTY+IHlvdXIgY29uZmlndXJlIGlzIGNvbXBsaWNhdGVkIHBlciB3aGF0IEkgc2F3IG9uIHhlbi1k
ZXZlbCBNYWlsaW5nIGxpc3QKKiBpdmFuXCBlc3QgcGFydGkgKFBpbmcgdGltZW91dDogMjUyIHNl
Y29uZHMpCiogaXZhblwgKH5pdmFuQHVuYWZmaWxpYXRlZC9pdmFuL3gtMDAwMDAxKSBhIHJlam9p
bnQgI3hlbgo8Z29vbl8+IFByeU1hcjU2LCAgLS13aXRoLWV4dHJhLXFlbXVVLWNvbmZpZ3VyZS1h
cmdzICwgc2Vjb25kIFUgaW4gcWVtdSBpcyBub3QgYSB0eXBvLCByaWdodD8KPFByeU1hcjU2PiBy
aWdodAo8UHJ5TWFyNTY+IDJuZCBVIGlzIGZvciBxZW11IHVwc3RyZWFtCjxnb29uXz4gb2sgbWFr
aW5nIGRpc3QKPGdvb25fPiBJIHRoaW5rIEkgc2hvdWxkIGhhdmUgc2V0IGxvY2FsZSA6LwoqIGl2
YW5cIGVzdCBwYXJ0aSAoUGluZyB0aW1lb3V0OiAyNTggc2Vjb25kcykKKiBpdmFuXCAofml2YW5A
dW5hZmZpbGlhdGVkL2l2YW4veC0wMDAwMDEpIGEgcmVqb2ludCAjeGVuCjxnb29uXz4gZXhwb3J0
IExDX0FMTD1lbl9VUy5VVEYtOAo8Z29vbl8+IG91cHMgOykKPGdvb25fPiBhZ2Fpbi4udGhpcyB0
aW1lIEkgcmVtb3ZlIHN5c3RlbWQgYXMgd2VsbAoqIETDqWNvbm5lY3TDqSAoKS4KKiBnb29uXyBh
Y3RpdmUgbGUgbW9kZSAraSBnb29uXwoqIFZvdXMgcGFybGV6IG1haW50ZW5hbnQgc3VyICN4ZW4K
KiBMZSBzdWpldCBkZSAjeGVuIGVzdMKgOiBYZW4gNC40LjEgcmVsZWFzZWQhIGh0dHA6Ly93d3cu
eGVucHJvamVjdC5vcmcvZG93bmxvYWRzLmh0bWwgfCBXaWtpOiBodHRwOi8vd2lraS54ZW5wcm9q
ZWN0Lm9yZy8gfCBGQVE6IGh0dHA6Ly93aWtpLnhlbnByb2plY3Qub3JnL3dpa2kvWGVuX0NvbW1v
bl9Qcm9ibGVtcwoqIFN1amV0IGRlICN4ZW4gZMOpZmluaSBwYXIgS2V2aW5gIGxlIFdlZCBTZXAg
IDMgMjM6Mjc6MzcgMjAxNAo8Z29vbl8+IFByeU1hcjU2LCBTVElMTCBCVUlMRElORwoqIHBpZ2Vv
bl8gZXN0IHBhcnRpIChQaW5nIHRpbWVvdXQ6IDI2NSBzZWNvbmRzKQo8Z29vbl8+IFByeU1hcjU2
LCBvayBtYWtlIGRpc3QgaXMgZG9uZQoqIHBpZ2VvbiAofnBpZ2VvbkBldGg1Mjg0Lm5zdy5hZHNs
LmludGVybm9kZS5vbi5uZXQpIGEgcmVqb2ludCAjeGVuCjxQcnlNYXI1Nj4gZHUgLXMgLi9kaXN0
L2luc3RhbGwgIC0+IGFib3V0IDc0IE1CCjxQcnlNYXI1Nj4gIGBmYWtlcm9vdCAuL3Rvb2xzL21p
c2MvbWtkZWIgJChwd2QpIDQuNS4wLXJjNGAKPGdvb25fPiBQcnlNYXI1NiwgIDkwTWIgd2l0aCB0
aGUgZGVicwo8Z29vbl8+IGluc3RhbGxlZCBub3cKKiBWb3VzIHBhcmxleiBtYWludGVuYW50IHN1
ciAjeGVuCiogTGUgc3VqZXQgZGUgI3hlbiBlc3TCoDogWGVuIDQuNC4xIHJlbGVhc2VkISBodHRw
Oi8vd3d3LnhlbnByb2plY3Qub3JnL2Rvd25sb2Fkcy5odG1sIHwgV2lraTogaHR0cDovL3dpa2ku
eGVucHJvamVjdC5vcmcvIHwgRkFROiBodHRwOi8vd2lraS54ZW5wcm9qZWN0Lm9yZy93aWtpL1hl
bl9Db21tb25fUHJvYmxlbXMKKiBTdWpldCBkZSAjeGVuIGTDqWZpbmkgcGFyIEtldmluYCBsZSBX
ZWQgU2VwICAzIDIzOjI3OjM3IDIwMTQKPGdvb25fPiBQcnlNYXI1NiwgIGRwa2cgLWwgeGVuLXVw
c3RyZWFtIHwgd2MgLWwgc3RpbGwgZXF1YWxzIDEwOAo8Z29vbl8+IDovCjxnb29uXz4gIFByeU1h
cjU2ICwgc2VlbXMgbGlrZSB0aGUgbGlicyBkb24ndCBnZXQgY29tcGlsZWQsIG15IGFyY2hpdmUg
Y29udGFpbnMgbm90aGluZyBpbiAvdmFyL2xpYgo8Z29vbl8+IHRpcmVkIGZvciB0b2RheSwgd2ls
bCBnbyB0byBiZWQgKDMuMzAgQU0gaGVyZSkKPGdvb25fPiB0aGFuayB5b3UKPGdvb25fPiBpZiBh
bnkgaWRlYSwgeW91J3ZlIGdvdCBteSBtYWlsLgogUHl0aG9uIGludGVyZmFjZSB1bmxvYWRlZAog
VGNsIGludGVyZmFjZSB1bmxvYWRlZAoqIFZvdXMgcGFybGV6IG1haW50ZW5hbnQgc3VyICN4ZW4K
KiBMZSBzdWpldCBkZSAjeGVuIGVzdMKgOiBYZW4gNC40LjEgcmVsZWFzZWQhIGh0dHA6Ly93d3cu
eGVucHJvamVjdC5vcmcvZG93bmxvYWRzLmh0bWwgfCBXaWtpOiBodHRwOi8vd2lraS54ZW5wcm9q
ZWN0Lm9yZy8gfCBGQVE6IGh0dHA6Ly93aWtpLnhlbnByb2plY3Qub3JnL3dpa2kvWGVuX0NvbW1v
bl9Qcm9ibGVtcwoqIFN1amV0IGRlICN4ZW4gZMOpZmluaSBwYXIgS2V2aW5gIGxlIFdlZCBTZXAg
IDMgMjM6Mjc6MzcgMjAxNAo8Z29vbl8+IEhlbGxvIHRoZXJlLCB0cnlpZWQgcmVjb21waWxpbmcg
eGVuNC41IGZyb20gc2NyYXRjaCBmb2xsb3dpbmcgUkVBRE1FCjxnb29uXz4gdmFyIGRpcmVjdG9y
eSBpbnNpZGUgdGhlIGFyY2hpdmUgaXMgc3RpbGwgMCBvY3RlY3QKPGdvb25fPiBQcnlNYXI1Niwg
aSByZWRpcmVjdGVkIGVycm9ycyB0byBsb2cgZmlsZXMKPGdvb25fPiBJIGhhdmUgcGxlbnR5IG9m
IHRob3NlIHBlcmw6IHdhcm5pbmc6IEZhbGxpbmcgYmFjayB0byBhIGZhbGxiYWNrIGxvY2FsZSAo
ImZyX0ZSLlVURi04IikuCjxnb29uXz4gcGVybDogd2FybmluZzogU2V0dGluZyBsb2NhbGUgZmFp
bGVkLgo8Z29vbl8+IHBlcmw6IHdhcm5pbmc6IFBsZWFzZSBjaGVjayB0aGF0IHlvdXIgbG9jYWxl
IHNldHRpbmdzOgo8Z29vbl8+ICBMQU5HVUFHRSA9ICh1bnNldCksCjxnb29uXz4gIExDX0FMTCA9
ICJlbl9VUy51dGYtOCIsCjxnb29uXz4gIExBTkcgPSAiZnJfRlIuVVRGLTgiCjxnb29uXz4gICAg
IGFyZSBzdXBwb3J0ZWQgYW5kIGluc3RhbGxlZCBvbiB5b3VyIHN5c3RlbS4KPGdvb25fPiBidXQg
bm8gZXJyb3IKKiBhbmRlcnNvbmMwZDMgZXN0IHBhcnRpIChQaW5nIHRpbWVvdXQ6IDI3MiBzZWNv
bmRzKQo8am93cj4gbG9va3MgbGlrZSB5b3VyIGxvY2FsZSBpc24ndCBpbnRlcm5hbGx5IGNvbnNp
c3RlbnQKPHBhc2lrPiBQcnlNYXI1NjogaSBiZXQgbW9zdCBkZXZlbG9wZXJzIGFyZSBvbiBob2xp
ZGF5cyBiZXR3ZWVuIGNocmlzdG1hcyBhbmQgbmV3IHllYXJzCjxQcnlNYXI1Nj4gZ29vZCwgdGhl
eSBjYW4ndCBicmVhayA0LjUKPFByeU1hcjU2PiBpdCBidWlsZHMgYW5kIHdvcmtzIE9LCjxwYXNp
az4gaGVoCjxQcnlNYXI1Nj4gb24gZGViOCB0aGVyZSBpcyBhIG5ldyBmbGFnIHRvIHVzZTogLS13
aXRoLXN5c3RlbWQ9L2xpYi9zeXN0ZW1kL3N5c3RlbQo8UHJ5TWFyNTY+IG9uIC4vY29uZmlndXJl
Cjxnb29uXz4gUHJ5TWFyNTYsIGJ1dCBjYW4gc3VjaCBhIGZsYWcgY2F1c2Ugbm8gbGliIGluIHZh
ciBkaXIgb2YgZGViPz8KPGdvb25fPiBwYXNpaywgeWVzLCBJJ20gZnIuCjxQcnlNYXI1Nj4gZ29v
bl8sIGRwa2ctZGViIC4vZGlzdC94ZW4tdXBzdHJlYW0qLmRlYiB8IGdyZXAgdmFyICAgIDwtLSBl
bXB0eT8KPFByeU1hcjU2PiAgXl4gLWMKPGdvb25fPiBQcnlNYXI1NiwgeWVzCjxQcnlNYXI1Nj4g
ZHBrZy1kZWIgLWMKPFByeU1hcjU2PiB3aGF0IGlzIGxpbmUgY291bnQgb2YgcGFja2FnZSAqZGVi
Pwo8Z29vbl8+IFByeU1hcjU2LCBCVFcgbm8gZG91YnRzIGl0IGJ1aWxkcyBvaywgYnV0IG5vdCBv
biBteSBjcHUgOi8KPFByeU1hcjU2PiBnb29uXywgZHBrZy1kZWIgLWMgLi9kaXN0L3hlbi11cHN0
cmVhbSouZGViIHwgd2MgLWwKPGdvb25fPiA3NzYKPFByeU1hcjU2PiB0aGF0cyB2ZXJ5IGNsb3Nl
IHRvIG1pbmUsIGdyZXAgZm9yIHN5c3RlbWQKPFByeU1hcjU2PiBzaG91bGQgYmUgYWJvdXQgMTAK
PFByeU1hcjU2PiBnb29uXywgZG8geW91IG5lZWQgRUZJIGJvb3Qgc3VwcG9ydCBpbiBYZW4/Cjxn
b29uXz4gUHJ5TWFyNTYsIG5vdCByZWFsbHkgCjxnb29uXz4gUHJ5TWFyNTYsICBpcyB0aGVyZSBh
IGJ1aWxkIFhYWCB0byBidWlsZCBsaWJzPwo8Z29vbl8+IFByeU1hcjU2LCBvaywgbWF5YmUgaXQn
cyB0aGUgcGF0Y2ggZnJvbSBmYW50dSBJIHRyaWVkIHRvIGFkZCwKPFByeU1hcjU2PiBnb29uXywg
IG9uIERlYjggYWx3YXlzIHBhc3MgLS1saWJkaXI9L3Vzci9saWIKPFByeU1hcjU2PiBnb29uXywg
dG8gZml4IHRoZSBtaXNzaW5nIC92YXIgaXNzdWUgLCBkbyB0aGlzCjxnb29uXz4gb2ssIHNvIG15
IGNvbmZpZ3VyZSBsaW5lLCB3aGF0IGl0IHNob3VsZCBiZT8KPFByeU1hcjU2PiBJIGdhdmUgdG8g
ZmxhZ3MgYWxyZWFkeSB0aGF0IHlvdSBtaWdodCBoYXZlIG1pc3NlZAo8UHJ5TWFyNTY+IDIgZmxh
Z3MKPGdvb25fPiBQcnlNYXI1NiwgSSdsbCB0cnkgd2l0aCAuL2NvbmZpZ3VyZSAtLXdpdGgtZXh0
cmEtcWVtdXUtY29uZmlndXJlLWFyZ3M9Ii0tZW5hYmxlLXNwaWNlIC0tZW5hYmxlLXVzYi1yZWRp
ciIgIC0td2l0aC1zeXN0ZW1kPS9saWIvc3lzdGVtZC9zeXN0ZW0gLS1saWJkaXI9L3Vzci9saWIK
PFByeU1hcjU2PiAtLXByZWZpeD0vdXNyCjxnb29uXz4gUHJ5TWFyNTYsIG9rLCBJJ2xsIGNoZWNr
IHRoYXQKPFByeU1hcjU2PiBjZCAuL2Rpc3QvaW5zdGFsbDsgbWtkaXIgdmFyIDtta2RpciAtcCAv
dmFyL2xpYi94ZW4vcGFnaW5nOyBta2RpciAtcCAvdmFyL2xpYi94ZW5zb3RyZWQ7IG1rZGlyIC1w
IC92YXIvbG9nL3hlbjtta2RpciAtcCAvdmFyL3hlbi9kdW1wCjxnb29uXz4gUHJ5TWFyNTYsIGNh
biBJIHVzZSBjY2FjaGUgZm9yIGZhc3RlciBidWlsZD8KPFByeU1hcjU2PiB0aG9zZSBkaXIgYXJl
IGFsbCBlbXB0eQo8UHJ5TWFyNTY+IHhlbnN0b3JlZAo8UHJ5TWFyNTY+IGdvb25fLCBydW4gdGhv
c2UgY21kcyBhcyB1c2VyLCBNaWdodCBuZWVkIGEgcHJlZml4IC4KPFByeU1hcjU2PiB5ZWFoIHVz
ZSB0aGUgcHJlZml4CjxQcnlNYXI1Nj4gZ29vbl8sIG5ldmVyIHRyaWVkIHRoYXQgdG9vbCBjY2Fj
aGUuLiBidXQgdGhlIGJ1aWxkIHNob3VsZCB0YWtlIDEwLTE1IG1pbnV0ZXMgb3IgbGVzcwo8Z29v
bl8+IG1ha2Ugd29ybGQ/IG1ha2UgaW5zdGFsbD8gbWFrZSBkaXN0IG1ha2UgZGViYmFsbD8KPFBy
eU1hcjU2PiBnb29uXywgSSBkbyBgbWFrZSBkaXN0YCB0aGVuIG9uY2UgSSBzZWUgYSBnb29kIGJ1
aWxkLCBJIGVkaXQgdGhlIC4vZGlzdC9pbnN0YWxsIGEgYml0LCB0aGVuIGBmYWtlcm9vdCAuL3Rv
b2xzL21pc2MvbWtkZWIgJChwd2QpIDQuNS4wLXJjNGAKPFByeU1hcjU2PiBnb29uXywgaWYgYnVp
bGQgbG9va3MgT0ssIGJ1dCB0aGVyZSBhcmUgbWlub3IgcHJvYmxlbXMgaW4gL2Rpc3QvaW5zdGFs
bC8qLiBHbyBhaGVhZCBhbmQgZml4IHRoZW0sIHRoZW4gcnVuIHRoZSBta2RlYiBzY3JpcHQuIE5v
IG5lZWQgdG8ga2VlcCByZWJ1aWxkaW5nIHd0aCBtYWtlIGRlYmJhbGwKPFByeU1hcjU2PiBpdHMg
cGVyZmVjdGx5IE9LLCBjZCBpbnRvIHRoZSBidWlsZCBhbmQgdHJpbSBvciBjcmVhdGUgZGlyIGFz
IG5lZWRlZAo8UHJ5TWFyNTY+IEkgY3JlYXRlIDIgZGlyIGluIC4vZGlzdC9pbnN0YWxsIGJlZm9y
ZSBJIGJ1aWxkCjxQcnlNYXI1Nj4gb25lIGZvciBFRkkgYW5kIG9uZSBmb3Igc3R1YmxpYgo8UHJ5
TWFyNTY+IGlmIEkgZG9uJ3QgdGhleSBhcmUgbm90IHBvcHVsYXRlZCBhcyBuZWVkZWQKPGdvb25f
PiB3ZWxsIEkgbGF1bmNoZWQgYSBtYWtlIHdvcmxkLCBzbyB0aGVyZSBhcmUgYSBmZXcgdGhpbmdz
IHRvIGRvIG1hbnVhbGx5IG9uIGluc3RhbGwuLi4gVGhvc2UgcHJlY2lvdXMgYWR2aWNlcyBzaG91
bGQgYmUgc29tZXdoZXJlIG9uIHRoZSB3aWtpCjxQcnlNYXI1Nj4gdGhlcmUgYXJlIHBhcnRzIG9m
IHRoZSBidWlsZCB0aGF0IGNhbiBzaWxlbnRseSBmYWlsLCBsaWtlIEVGSS4gdGhlIGJ1aWxkIHN0
aWxsIGNvbnRpbnVlcwoqIGRhbHRlbyAofm1pY2hhZWxAY2FyMzQtMS04OC0xNjgtMTE3LTMwLmZi
eC5wcm94YWQubmV0KSBhIHF1aXR0w6kgI3hlbgo8UHJ5TWFyNTY+IG5vIHdhcm5pbmdzCjxQcnlN
YXI1Nj4gSWYgYSBwYXJ0IG9mIHRoZSBidWlsZCBmYWlscyBvciBnaXZlcyB3YXJuaW5ncywgZG9u
J3QgZ2V0IG1hZC4uIHRoYXQgaXMgZ29vZCBmb3IgdGhlIHVzZXIKPGdvb25fPiBQcnlNYXI1Niwg
eWVzIHRoYXQncyBpdCwgbm90IGV2ZW4gYSB3YXJuaW5nIGlzIGEgYml0IHJ1ZGUgZm9yIHRoZSB1
c2VyIG9uIHRoZSBvcHBvc2l0ZSA6Lwo8Z29vbl8+IDspCjxnb29uXz4gd2VsbCAsIG1ha2Ugd29y
bGQgZ2F2ZSBtZSBlcnJvcjogaHR0cDovL3Bhc3RlYmluLmNvbS9RbUpxTTFWVQoqIGtlcm1pdCBl
c3QgcGFydGkgKFF1aXQ6IExlYXZpbmcuKQo8UHJ5TWFyNTY+IGFueSBwYXRjaGVzIGFnYWluc3Qg
c2VhYmlvcz8KKiBrZXJtaXQgKHVua25vd25AcGRwYy9zdXBwb3J0ZXIvYnJvbnplL2tlcm1pdCkg
YSByZWpvaW50ICN4ZW4KPGdvb25fPiBQcnlNYXI1NiwgTWU/IG5vCjxQcnlNYXI1Nj4gZ29vbl8s
IHRyeSBhcHQtZ2V0IGJ1aWxkLWRlcCB4ZW4gIDwtLSBzZWUgaWYgYW55IHBhY2thZ2VzIGNvbWUg
dXAKPFByeU1hcjU2PiByZWZ1c2UgdGhlIHNlYWJpb3MKPFByeU1hcjU2PiAgJiBgYXB0LWdldCBi
dWlsZC1kZXAgc2VhYmlvc2AKPGdvb25fPiBxeGwgcGF0Y2ggZnJvbSBmYW50dT8KPGdvb25fPiBi
eSByZWZ1c2UgeW91IG1lYW4gdW5pbnN0YWxsCjxQcnlNYXI1Nj4gdGhlIGJ1aWxkLWRlcCBjbWQK
PGdvb25fPiBub3RoaW5nCjxQcnlNYXI1Nj4gcmVjb25maWd1cmUgYW5kIC0tZGlzYWJsZS1yb21i
aW9zCiogZ2FuZGFsaXRlciBlc3QgcGFydGkgKFBpbmcgdGltZW91dDogMjU1IHNlY29uZHMpCjxQ
cnlNYXI1Nj4gZ3JlcCAuL2NvbmZpZy8qLm1rIC0+IC4vY29uZmlnL1Rvb2xzLm1rOkNPTkZJR19S
T01CSU9TICAgICAgOj0geQoqIEZhbnR1IGVzdCBwYXJ0aSAoUXVpdDogQ2hhdFppbGxhIDAuOS45
MS4xIFtGaXJlZm94IDM0LjAuNS8yMDE0MTEyNjA0MTA0NV0pCjxnb29uXz4gRmFudHUncyBjb25m
IHBhcmFtOiAuL2NvbmZpZ3VyZSAtLXByZWZpeD0vdXNyIC0tZGlzYWJsZS1ibGt0YXAxIC0tZGlz
YWJsZS1xZW11LXRyYWRpdGlvbmFsCjxnb29uXz4gLS1kaXNhYmxlLXJvbWJpb3MgLS13aXRoLXN5
c3RlbS1zZWFiaW9zPS91c3Ivc2hhcmUvc2VhYmlvcy9iaW9zLTI1NmsuYmluCjxnb29uXz4gLS13
aXRoLWV4dHJhLXFlbXV1LWNvbmZpZ3VyZS1hcmdzPSItLWVuYWJsZS1zcGljZSAtLWVuYWJsZS11
c2ItcmVkaXIiCjxnb29uXz4gLS1kaXNhYmxlLWJsa3RhcDIKPFByeU1hcjU2PiBnb29uXywgSSBz
ZWUgaXRzIHRyeWluZyB0byBjcmVhdGUgYSAxNmJpdCByb21iaW9zPyBtaW5lIG9ubHkgaGFzIGEg
MzJiaXQKPGdvb25fPiBQcnlNYXI1NiwgeWVzLCB3aHkgaXMgdGhhdD8KPFByeU1hcjU2PiBJIGFt
IGdvb2QgZm9yIG9uZSBvciB0d28gKGF0IG1vc3QpIG15c3RlcmllcyBsaWtlIHRoYXQgcGVyIGRh
eS4KPFByeU1hcjU2PiByZXF1aXJlcyBxdWl0ZSBhIGJpdCBvZiBnb29nbGluZyBhbmQgY29kZSBy
ZWFkaW5nCjxnb29uXz4gSSBub3RpY2VkIHRoYXQsIGl0IHdhcyBhY3R1YWx5IHdoZXJlIEkgYWRk
IHRvIGVuZm9yZSBMQz1Vcy4KPFByeU1hcjU2PiBmb2xsb3cgRmFudHU6IGlmIHlvdSBjYW4gdXNl
IHRoZSBkaXN0cm8gc2VhYmlvcywgdGhlbiBnbyB0aGF0IHdheQo8UHJ5TWFyNTY+IGdvb25fLCB3
aGF0IENQVSBpcyBpdD8KPGdvb25fPiBQcnlNYXI1NiwgSTcgMzY4N1UKPGdvb25fPiBQcnlNYXI1
NiwgSSdsbCB0cnkgZmFudHUncyB3YXkKPGdvb25fPiBzZWUgaG93IGl0IGdvZXMKKiBvbWFycnIg
ZXN0IHBhcnRpIChSZW1vdGUgaG9zdCBjbG9zZWQgdGhlIGNvbm5lY3Rpb24pCjxnb29uXz4gUHJ5
TWFyNTYsIHNvcnJ5IGZvciBnaXZpbmcgeW91IGEgaGFyZCB0aW1lCjxQcnlNYXI1Nj4gZ29vbl8s
IEkgYW0gbWFraW5nIHByb2dyZXNzIG9uIGEgcHJvcGVyIGRlYjggYnVpbGQgYmVjYXVzZSBvZiB0
aGlzIGRpc2N1c3Npb24uIEkgaGFkIHNldmVyYWwgY29uZmlncyB3cm9uZywgb3Igbm90IE9LIHBl
ciBkZWJpYW4KPFByeU1hcjU2PiBvbiBkZWI4IG5vdGhpbmcgZ29lcyBpbiBsaWI2NCBhbmQgc3lz
dGVtZCBkb2VzIG5vdCB1c2UgL3Vzci9saWIvKgo8UHJ5TWFyNTY+IHN5c3RlbWQgLT4gL2xpYi9z
eXN0ZW1kL3N5c3RlbS8qLnNlcnZpY2VzCjxnb29uXz4gUHJ5TWFyNTYsIEkgc2VlLCBJIGNhbiBz
ZW5kIHlvdSBsb25nZXIgZHVtcHMgaWYgbmVlZGVkCiogYW5kZXJzb25jMGQzICh+YW5kZXJzb25j
QHVuYWZmaWxpYXRlZC9hbmRlcnNvbmMwZDMpIGEgcmVqb2ludCAjeGVuCiogU3R1YXJ0TUkgZXN0
IHBhcnRpIChSZWFkIGVycm9yOiBDb25uZWN0aW9uIHJlc2V0IGJ5IHBlZXIpCjxnb29uXz4gUHJ5
TWFyNTYsIHdlbGwgSSB0aGluayBpdCdzIGJ1aWxkaW5nIGZpbGVzIG5ldmVyIGJ1aWx0IGJlZm9y
ZQo8Z29vbl8+IFByeU1hcjU2LCBvaywgbWFrZSB3b3JsZCB3ZW50IHdpdGhvdXQgZXJyb3IKPGdv
b25fPiBQcnlNYXI1NiwgY2FuIG15IHZhciBkaXIgYmVpbmcgZW1wdHkgYmVpbmcgZHVlZCB0byBh
IHBlcm1pc3Npb24gcHJvYmxlbT8KPGdvb25fPiBQcnlNYXI1NiwgeW91IHRoZXJlPyBtYWtlIGRp
c3QgZW5kZWQgd2l0aG91dCBlcnJvciwgc210ZyB0byBjaGVjayBiZWZvcmUgZmFrZXJvb3Q/Ciog
Q3JvdGhlcnMgKH5jcm90aGVyc0B1bmFmZmlsaWF0ZWQvY3JvdGhlcnMpIGEgcmVqb2ludCAjeGVu
Cjxnb29uXz4gUHJ5TWFyNTYsIGZha2Vyb290IGNvbW1hbmQgKGZha2Vyb290IC4vdG9vbHMvbWlz
Yy9ta2RlYiAkKHB3ZCkgNC41LjAtcmM0IGdpdmVzIG1lICJwZXJtaXNzaW9uIG5vdCBncmFudGVk
IiBhcyBhIHJlc3VsdAo8Z29vbl8+IHJhbiBhcyByb290CjxQcnlNYXI1Nj4gY2htb2QgK3ggLi90
b29scy9taXNjL21rZGViCjxnb29uXz4gUHJ5TWFyNTYsIEludGVyZXN0aW5nLCBpdCB3b3JrZWQg
YnV0IG5vdyBJIGdldCBVbmtub3duIFhFTl9UQVJHRVRfQVJDSCAKPGdvb25fPiBjcW4ndCBidWls
ZCBsaWJzIGZvciBhbiBhcmNoIHlvdSdyZSBub3QgYXdhcmUgb2YKPGdvb25fPiB2YXIgZm9sZGVy
cyBhcmUgcHJlc2VudCBidXQgZW1wdHkgYW5kIHhlbnBhZ2luZyBpcyBkcnd4LS0tLS0tCjxnb29u
Xz4gd2VsbCBsYXVuY2hlZCBhIG1ha2UgZGViYmFsbCwgSSBmb3Jnb3QgdGhhdCBhY3R1YWxseSBs
aWJzIGFyZSBub3cgaW4gdXNyCiogYzRwdCBlc3QgcGFydGkgKFBpbmcgdGltZW91dDogMjY0IHNl
Y29uZHMpCjxnb29uXz4gUHJ5TWFyNTYsICBibGt0YXAgdXRpbHMgY29uZmxpY3QKPGdvb25fPiBQ
cnlNYXI1Niwgb2sgZHBrZyAtaSB3b3JrZWQgYWZ0ZXIgcmVtb3ZpbmcgbXkgcHJldmlvdXMgdmVy
c2lvbiBibGt0YXAtdXRpbHMKPGdvb25fPiB4bCBjb21tYW5kIGdpdmVzIG1lIC91c3IvbG9jYWwv
c2Jpbi94bDogbm8gZmlsZSBvciBmb2xkZXIuLi4KPGdvb25fPiBQcnlNYXI1NiwgaXQgaXMgbG9j
YXRlZCBpbiAvdXNyL3NiaW4vCjxnb29uXz4gUHJ5TWFyNTYsIGxuIC1zIGEgIHRlbXBvcmFyeSBm
aXgsIHN0aWxsIGd1ZXR0aW5nIHhjOiBlcnJvcjogQ291bGQgbm90IG9idGFpbiBoYW5kbGUgb24g
cHJpdmlsZWdlZCBjb21tYW5kIGludGVyZmFjZSAoMiA9IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv
cnkpOiBJbnRlcm5hbCBlcnJvcgo8Z29vbl8+IGxpYnhsOiBlcnJvcjogbGlieGwuYzoxMDk6bGli
eGxfY3R4X2FsbG9jOiBjYW5ub3Qgb3BlbiBsaWJ4YyBoYW5kbGU6IE5vIHN1Y2ggZmlsZSBvciBk
aXJlY3RvcnkKPGdvb25fPiBjYW5ub3QgaW5pdCB4bCBjb250ZXh0Cjxnb29uXz4gUHJ5TWFyNTYs
IHVwZGF0ZV9ncnViIGdpdmVzIG1lIGEgd3JvbmcgdmVyc2lvbiBudW1iZXIKIAoqIEhpc3Rvcmlx
dWUgY2hhcmfDqSBkZXB1aXMgV2VkIERlYyAzMSAwMTo1MToxMiAyMDE0CiAKKiBWb3VzIHBhcmxl
eiBtYWludGVuYW50IHN1ciAjeGVuCiogTGUgc3VqZXQgZGUgI3hlbiBlc3TCoDogWGVuIDQuNC4x
IHJlbGVhc2VkISBodHRwOi8vd3d3LnhlbnByb2plY3Qub3JnL2Rvd25sb2Fkcy5odG1sIHwgV2lr
aTogaHR0cDovL3dpa2kueGVucHJvamVjdC5vcmcvIHwgRkFROiBodHRwOi8vd2lraS54ZW5wcm9q
ZWN0Lm9yZy93aWtpL1hlbl9Db21tb25fUHJvYmxlbXMKKiBTdWpldCBkZSAjeGVuIGTDqWZpbmkg
cGFyIEtldmluYCBsZSBXZWQgU2VwICAzIDIzOjI3OjM3IDIwMTQKKiBnb29uXyBlc3QgcGFydGkg
KFJlYWQgZXJyb3I6IENvbm5lY3Rpb24gcmVzZXQgYnkgcGVlcikKPGdvb25fXz4gUHJ5TWFyNTYs
IG9rLCBEZWI4IGJvb3Rpbmcgd2l0aCBYZW4gNC41LjAtcmMKPGdvb25fXz4gYnV0IHN0aWxsIHhs
IHRocm93cyB4YzogZXJyb3I6IENvdWxkIG5vdCBvYnRhaW4gaGFuZGxlIG9uIHByaXZpbGVnZWQg
Y29tbWFuZCBpbnRlcmZhY2UgKDIgPSBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KTogSW50ZXJu
YWwgZXJyb3IKPGdvb25fXz4gbGlieGw6IGVycm9yOiBsaWJ4bC5jOjEwOTpsaWJ4bF9jdHhfYWxs
b2M6IGNhbm5vdCBvcGVuIGxpYnhjIGhhbmRsZTogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQo8
Z29vbl9fPiBjYW5ub3QgaW5pdCB4bCBjb250ZXh0Cjxnb29uX18+IFByeU1hcjU2LCBzZXJ2aWNl
IHhlbmNvbW1vbnMgc3RhcnQgZGlkIGl0Cjxnb29uX18+IFByeU1hcjU2LCB3ZWxsIGlzIHNlZW1z
IGxpa2UgaXQncyBnb2luZyB0byBiZSBhIGdyZWF0IDIwMTUKPGdvb25fXz4gVGhhbmsgeW91Cjxn
b29uX18+IFByeU1hcjU2LCBRWEwgU1VQUE9SVCBXT1JLSU5HLi4uLgoqIHJjcGF2bGljZWsgZXN0
IHBhcnRpIChQaW5nIHRpbWVvdXQ6IDI1OCBzZWNvbmRzKQoqIGh2eGdyIGVzdCBwYXJ0aSAoUXVp
dDogbGVhdmluZykKKiBodnhnciAofm5vdC11c2VyQHVxamF1Lm9yZykgYSByZWpvaW50ICN4ZW4K
KiB0cm95dCBlc3QgcGFydGkgKFBpbmcgdGltZW91dDogMjU4IHNlY29uZHMpCg==
--047d7b33934159e146050b78ff5f
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--047d7b33934159e146050b78ff5f--


From xen-devel-bounces@lists.xen.org Wed Dec 31 03:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y69cd-00013Z-EG; Wed, 31 Dec 2014 03:06:55 +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 1Y69cb-00013U-OJ
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 03:06:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C0/EB-09842-D4863A45; Wed, 31 Dec 2014 03:06:53 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419995210!10535607!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5189 invoked from network); 31 Dec 2014 03:06:51 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-2.tower-21.messagelabs.com with SMTP;
	31 Dec 2014 03:06:51 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 30 Dec 2014 19:02:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="435174683"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 30 Dec 2014 18:54:48 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Tue, 30 Dec 2014 18:02:58 -0500
Message-Id: <1419980578-18628-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] [v3 1/5] 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 | 19 ++++++++++++++++---
 qemu-options.hx  | 13 +++++++++++--
 tpm.c            |  7 ++++++-
 5 files changed, 54 insertions(+), 6 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..9745c2b 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2854,9 +2854,10 @@
 #
 # @passthrough: TPM passthrough type
 #
-# Since: 1.5
+# @xenstubdoms: TPM xenstubdoms type (since 2.3)## 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.3
+##
+{ '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 Wed Dec 31 03:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y69cn-00015e-TF; Wed, 31 Dec 2014 03:07:05 +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 1Y69cm-00015B-PF
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 03:07:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	53/71-15461-85863A45; Wed, 31 Dec 2014 03:07:04 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1419995222!18549456!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2994 invoked from network); 31 Dec 2014 03:07:03 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-5.tower-21.messagelabs.com with SMTP;
	31 Dec 2014 03:07:03 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 30 Dec 2014 19:07:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="435174719"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 30 Dec 2014 18:55:01 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Tue, 30 Dec 2014 18:03:12 -0500
Message-Id: <1419980592-18778-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] [v3 5/5] 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 Wed Dec 31 03:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y69cj-00014b-QG; Wed, 31 Dec 2014 03:07:01 +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 1Y69ch-000144-J7
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 03:06:59 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	F7/E1-02702-25863A45; Wed, 31 Dec 2014 03:06:58 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1419995216!17855737!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22350 invoked from network); 31 Dec 2014 03:06:57 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 03:06:57 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by orsmga101.jf.intel.com with ESMTP; 30 Dec 2014 19:06:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,669,1413270000"; d="scan'208";a="644799485"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 30 Dec 2014 19:06:54 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Tue, 30 Dec 2014 18:03:05 -0500
Message-Id: <1419980585-18704-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] [v3 3/5] 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. It is a glue for
the TPM xenstubdoms driver and Xen stubdom vTPM domain that provides
the actual TPM functionality.

(Xen) Xen backend driver should run before running this frontend, and
initialize XenStore as the following for communication.

[XenStore]
 ..
  FE.DOMAIN.ID
   device = ""
    vtpm = ""
     0 = ""
      backend = "/local/domain/{BE.DOMAIN.ID}/backend/vtpm/{FE.DOMAIN.ID}/0"
      backend-id = "BE.DOMAIN.ID"
      state = "1"
      handle = "0"
 ..

(QEMU) xen_vtpmdev_ops is initialized with the following process:
  xen_hvm_init()
    [...]
    -->xen_fe_register("vtpm", ...)
      -->xenstore_fe_scan()
        -->xen_fe_get_xendev()
          --> XenDevOps.alloc()
        -->xen_fe_check()
          --> XenDevOps.init()
          --> XenDevOps.initialise()
          --> XenDevOps.connected()
        -->xs_watch()
    [...]

--Changes in v3:
-Move xen_stubdom_vtpm.c to xen_vtpm_frontend.c
-Read Xen vTPM status via XenStore

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/tpm/Makefile.objs         |   1 +
 hw/tpm/xen_vtpm_frontend.c   | 264 +++++++++++++++++++++++++++++++++++++++++++
 hw/xen/xen_backend.c         |  34 ++++++
 include/hw/xen/xen_backend.h |   9 +-
 include/hw/xen/xen_common.h  |   6 +
 xen-hvm.c                    |  16 +++
 6 files changed, 328 insertions(+), 2 deletions(-)
 create mode 100644 hw/tpm/xen_vtpm_frontend.c

diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 99f5983..57919fa 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_vtpm_frontend.o
diff --git a/hw/tpm/xen_vtpm_frontend.c b/hw/tpm/xen_vtpm_frontend.c
new file mode 100644
index 0000000..00cc888
--- /dev/null
+++ b/hw/tpm/xen_vtpm_frontend.c
@@ -0,0 +1,264 @@
+/*
+ * 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 xen_vtpm_dev {
+    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 xen_vtpm_dev *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 bool vtpm_aio_wait(AioContext *ctx)
+{
+    return aio_poll(ctx, true);
+}
+
+static void sr_bh_handler(void *opaque)
+{
+}
+
+int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count)
+{
+    struct xen_vtpm_dev *vtpmdev = container_of(xendev, struct xen_vtpm_dev,
+                                                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;
+}
+
+int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count)
+{
+    struct xen_vtpm_dev *vtpmdev = container_of(xendev, struct xen_vtpm_dev,
+                                                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 xen_vtpm_dev *vtpmdev = container_of(xendev, struct xen_vtpm_dev,
+                                                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 int vtpm_free(struct XenDevice *xendev)
+{
+    struct xen_vtpm_dev *vtpmdev = container_of(xendev, struct xen_vtpm_dev,
+                                                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 xen_vtpm_dev *vtpmdev = container_of(xendev, struct xen_vtpm_dev,
+                                                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 xen_vtpm_dev *vtpmdev = container_of(xendev, struct xen_vtpm_dev,
+                                                xendev);
+
+    qemu_bh_schedule(vtpmdev->sr_bh);
+}
+
+struct XenDevOps xen_vtpmdev_ops = {
+    .size             = sizeof(struct xen_vtpm_dev),
+    .flags            = DEVOPS_FLAG_IGNORE_STATE |
+                        DEVOPS_FLAG_FE,
+    .event            = vtpm_event,
+    .free             = vtpm_free,
+    .alloc            = vtpm_alloc,
+    .initialise       = vtpm_initialise,
+    .backend_changed  = vtpm_backend_changed,
+};
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index ad6e324..377a9c8 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -741,6 +741,20 @@ 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) {
@@ -813,6 +827,26 @@ void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...
     qemu_log_flush();
 }
 
+void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
+{
+    int be_state;
+
+    if (strcmp(node, "state") == 0) {
+        xenstore_read_be_int(xendev, node, &be_state);
+        switch (be_state) {
+        case XenbusStateConnected:
+            /*TODO*/
+            break;
+        case XenbusStateClosing:
+        case XenbusStateClosed:
+            xenbus_switch_state(xendev, XenbusStateClosing);
+            break;
+        default:
+            break;
+        }
+    }
+}
+
 void xen_qtail_insert_xendev(struct XenDevice *xendev)
 {
     QTAILQ_INSERT_TAIL(&xendevs, xendev, next);
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 06e202f..d07ae36 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -102,8 +102,12 @@ char *xenstore_fe_read_be_str(const char *type, int dom, int dev);
 int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus);
 struct XenDevice *xen_fe_get_xendev(const char *type, int dom, int dev,
                                     struct XenDevOps *ops);
-void xenstore_fe_update(char *watch, char *type, int dom,
-                        struct XenDevOps *ops);
+void xenstore_fe_update(char *watch, char *type, int dom, struct XenDevOps *ops);
+
+/*Xen vtpm*/
+int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count);
+int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count);
+void vtpm_backend_changed(struct XenDevice *xendev, const char *node);
 
 /* actual backend drivers */
 extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
@@ -111,6 +115,7 @@ 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_vtpm_frontend.c*/
 
 void xen_init_display(int domid);
 
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 07731b9..2e9bb62 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 05e522c..5b93cd4 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -986,6 +986,12 @@ 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
+    char path[XEN_BUFSIZE];
+    unsigned int stubdom_vtpm = 0;
+#endif
+
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -1071,6 +1077,16 @@ 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
+    snprintf(path, sizeof(path), "/local/domain/%d/platform/acpi_stubdom_vtpm",
+             xen_domid);
+    xs_read(state->xenstore, 0, path, &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 Wed Dec 31 03:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y69cf-00013l-Vp; Wed, 31 Dec 2014 03:06:57 +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 1Y69ce-00013d-1V
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 03:06:56 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	2C/C0-02953-F4863A45; Wed, 31 Dec 2014 03:06:55 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419995213!12423130!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 29351 invoked from network); 31 Dec 2014 03:06:53 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-16.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 03:06:53 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga102.jf.intel.com with ESMTP; 30 Dec 2014 19:04:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="505972176"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 30 Dec 2014 19:01:39 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Tue, 30 Dec 2014 18:03:02 -0500
Message-Id: <1419980582-18665-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] [v3 2/5] Qemu-Xen-vTPM: Xen frontend driver
	infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds infrastructure for xen front drivers living in qemu,
so drivers don't need to implement common stuff on their own.  It's
mostly xenbus management stuff: some functions to access XenStore,
setting up XenStore watches, callbacks on device discovery and state
changes, and handle event channel between the virtual machines.

Call xen_fe_register() function to register XenDevOps, and make sure,
XenDevOps's flags is DEVOPS_FLAG_FE, which is flag bit to point out
the XenDevOps is Xen frontend.

--Changes in v3:
-New xen_frontend.c file
-Move xenbus_switch_state() to xen_frontend.c
-Move xen_stubdom_be() to xenstore_fe_read_be_str()
-Move *_stubdom_*() to *_fe_*()

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/xen/Makefile.objs         |   2 +-
 hw/xen/xen_backend.c         |  11 +-
 hw/xen/xen_frontend.c        | 323 +++++++++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  14 ++
 4 files changed, 348 insertions(+), 2 deletions(-)
 create mode 100644 hw/xen/xen_frontend.c

diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index a0ca0aa..b0bb065 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,5 @@
 # xen backend driver support
-common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
+common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o xen_frontend.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..ad6e324 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -275,7 +275,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
 /*
  * release xen backend device.
  */
-static struct XenDevice *xen_be_del_xendev(int dom, int dev)
+struct XenDevice *xen_be_del_xendev(int dom, int dev)
 {
     struct XenDevice *xendev, *xnext;
 
@@ -681,6 +681,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) {
+        xenstore_fe_update(vec[XS_WATCH_PATH], (void *)type, dom, (void *)ops);
+    }
 
 cleanup:
     free(vec);
@@ -808,3 +812,8 @@ void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...
     }
     qemu_log_flush();
 }
+
+void xen_qtail_insert_xendev(struct XenDevice *xendev)
+{
+    QTAILQ_INSERT_TAIL(&xendevs, xendev, next);
+}
diff --git a/hw/xen/xen_frontend.c b/hw/xen/xen_frontend.c
new file mode 100644
index 0000000..07ffc5c
--- /dev/null
+++ b/hw/xen/xen_frontend.c
@@ -0,0 +1,323 @@
+/*
+ * Xen frontend driver infrastructure
+ *
+ *  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 <fcntl.h>
+#include <inttypes.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+#include <sys/signal.h>
+
+#include "hw/hw.h"
+#include "sysemu/char.h"
+#include "qemu/log.h"
+#include "hw/xen/xen_backend.h"
+#include <xen/grant_table.h>
+
+/* private */
+static int debug;
+
+/* ------------------------------------------------------------- */
+/*Get backend with fe type|domid, try to write the backend-id when
+ *create virtual machine.
+ *
+ *[XenStore]
+ *
+ *Dom.ID = ""
+ *  device
+ *    vtpm = ""
+ *      0 = ""
+ *        backend-id = "ID"
+ *[..]
+ */
+
+char *xenstore_fe_read_be_str(const char *type, int dom, int dev)
+{
+    char *val, *domu;
+    char path[XEN_BUFSIZE];
+    unsigned int len, ival;
+
+    /*fe path*/
+    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);
+
+    /*be path*/
+    domu = xs_get_domain_path(xenstore, ival);
+
+    return domu;
+}
+
+/*make sure, initialize the 'xendev->fe' in xendev->ops->init() or
+ * xendev->ops->initialize()
+ */
+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;
+    if (xendev->fe == NULL) {
+        xen_be_printf(NULL, 0, "xendev->fe is NULL\n");
+        return -1;
+    }
+
+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;
+}
+
+void xenstore_fe_update(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_FE)) {
+        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_fe_get_xendev(type, dom, dev, ops);
+    if (xendev != NULL) {
+        bepath = xs_read(xenstore, 0, xendev->be, &len);
+        /*bepath is NULL, indicates that the backend is not running,
+         *delete it.
+         */
+        if (bepath == NULL) {
+            xen_be_del_xendev(dom, dev);
+        } else {
+            free(bepath);
+            if (xendev->ops->backend_changed) {
+                xendev->ops->backend_changed(xendev, path);
+            }
+        }
+    }
+}
+
+/*
+ * get xen fe device, allocate a new one if it doesn't exist.
+ */
+struct XenDevice *xen_fe_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;
+
+    /*return if the ops->flags is not DEVOPS_FLAG_FE*/
+    if (!(ops->flags & DEVOPS_FLAG_FE)) {
+        return NULL;
+    }
+
+    stub = xenstore_fe_read_be_str(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;
+    }
+
+    xen_qtail_insert_xendev(xendev);
+
+    if (xendev->ops->alloc) {
+        xendev->ops->alloc(xendev);
+    }
+
+    return xendev;
+}
+
+/* simplify QEMU side, a thread is running in Xen backend, which will
+ * connect frontend when the frontend is initialised. Call these initialised
+ * functions.
+ */
+
+static int xen_fe_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_fe_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;
+
+    /*Xen frontend : /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_fe_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 backend, which will
+         * connect frontend when the frontend is initialised.
+         */
+        if (xen_fe_check(xendev, domid, atoi(dev[j])) < 0) {
+            xen_be_printf(xendev, 0, "xendev fe_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_fe_scan(type, xen_domid, ops);
+}
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 3b4125e..06e202f 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 is frontend device*/
+#define DEVOPS_FLAG_FE            4
 
 struct XenDevOps {
     size_t    size;
@@ -80,6 +82,8 @@ int xenstore_read_fe_uint64(struct XenDevice *xendev, const char *node, uint64_t
 const char *xenbus_strstate(enum xenbus_state state);
 struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev);
 void xen_be_check_state(struct XenDevice *xendev);
+struct XenDevice *xen_be_del_xendev(int dom, int dev);
+void xen_qtail_insert_xendev(struct XenDevice *xendev);
 
 /* xen backend driver bits */
 int xen_be_init(void);
@@ -91,6 +95,16 @@ 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 frontend driver*/
+int xen_fe_register(const char *type, struct XenDevOps *ops);
+int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom);
+char *xenstore_fe_read_be_str(const char *type, int dom, int dev);
+int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus);
+struct XenDevice *xen_fe_get_xendev(const char *type, int dom, int dev,
+                                    struct XenDevOps *ops);
+void xenstore_fe_update(char *watch, char *type, int dom,
+                        struct XenDevOps *ops);
+
 /* actual backend drivers */
 extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
 extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.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 Wed Dec 31 03:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y69cm-00015D-GN; Wed, 31 Dec 2014 03:07:04 +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 1Y69cl-00014w-D0
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 03:07:03 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	BF/E8-02957-65863A45; Wed, 31 Dec 2014 03:07:02 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1419995220!17832322!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16552 invoked from network); 31 Dec 2014 03:07:01 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-9.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 03:07:01 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by fmsmga103.fm.intel.com with ESMTP; 30 Dec 2014 19:02:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,669,1413270000"; d="scan'208";a="631031696"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 30 Dec 2014 19:06:57 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Tue, 30 Dec 2014 18:03:09 -0500
Message-Id: <1419980589-18741-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] [v3 4/5] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms backen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 provides the glue for the TPM_TIS(Qemu frontend) to Xen
stubdom vTPM domain that provides the actual TPM functionality. It
sends data and TPM commends with xen_vtpm_frontend. It is similar as
another two vTPM backens:
  *vTPM passthrough backen Since QEMU 1.5.
  *vTPM libtpms-based backen.

Some details:
This part of the patch provides support for the spawning of a thread
that will interact with stubdom vTPM domain by the xen_vtpm_frontend.
It expects a signal from the frontend to wake and pick up the TPM
command that is supposed to be processed and delivers the response
packet using a callback function provided by the frontend.

The backend connects itself to the frontend by filling out an interface
structure with pointers to the function implementing support for various
operations.

(QEMU) vTPM XenStubdoms backen is initialized by Qemu command line options,
      "-tpmdev xenstubdoms,id=xenvtpm0 -device tpm-tis,tpmdev=xenvtpm0"

--Changes in v3:
-Call vtpm_send() and vtpm_recv() directly.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/tpm/Makefile.objs     |   2 +-
 hw/tpm/tpm_xenstubdoms.c | 245 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 246 insertions(+), 1 deletion(-)
 create mode 100644 hw/tpm/tpm_xenstubdoms.c

diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 57919fa..190e776 100644
--- a/hw/tpm/Makefile.objs
+++ b/hw/tpm/Makefile.objs
@@ -1,3 +1,3 @@
 common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
 common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
-common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_vtpm_frontend.o
+common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o xen_vtpm_frontend.o
diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c
new file mode 100644
index 0000000..98ea496
--- /dev/null
+++ b/hw/tpm/tpm_xenstubdoms.c
@@ -0,0 +1,245 @@
+/*
+ * 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;
+    struct XenDevice *xendev;
+
+    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;
+    }
+    vtpm_send(xendev, locty_data->w_buffer.buffer, locty_data->w_offset);
+    vtpm_recv(xendev, 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 Wed Dec 31 03:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y69cY-00013N-OA; Wed, 31 Dec 2014 03:06:50 +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 1Y69cX-00013I-8t
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 03:06:49 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	3C/C8-25727-84863A45; Wed, 31 Dec 2014 03:06:48 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1419995206!16548480!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 21839 invoked from network); 31 Dec 2014 03:06:47 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-8.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 03:06:47 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by fmsmga101.fm.intel.com with ESMTP; 30 Dec 2014 19:06:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,669,1413270000"; d="scan'208";a="662710522"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 30 Dec 2014 19:06:43 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Tue, 30 Dec 2014 18:02:50 -0500
Message-Id: <1419980570-18589-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, eblake@redhat.com
Subject: [Xen-devel] [PATCH v3 0/5] 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 v3:
    -New xen_frontend.c file
    -Adjust the format of command line options
    -Move xenbus_switch_state() to xen_frontend.c
    -Move xen_stubdom_be() to xenstore_fe_read_be_str()
    -Move *_stubdom_*() to *_fe_*()
    -Move xen_stubdom_vtpm.c to xen_vtpm_frontend.c
    -Read Xen vTPM status via XenStore
    -Call vtpm_send() and vtpm_recv() directly.

--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 (5):
  Qemu-Xen-vTPM: Support for Xen stubdom vTPM command line options
  Qemu-Xen-vTPM: Xen frontend driver infrastructure
  Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend driver
  Qemu-Xen-vTPM: Qemu vTPM xenstubdoms backen.
  Qemu-Xen-vTPM: QEMU machine class is initialized before tpm_init()

 configure                    |  14 ++
 hmp.c                        |   7 +
 hw/tpm/Makefile.objs         |   1 +
 hw/tpm/tpm_xenstubdoms.c     | 245 ++++++++++++++++++++++++++++++++
 hw/tpm/xen_vtpm_frontend.c   | 264 +++++++++++++++++++++++++++++++++++
 hw/xen/Makefile.objs         |   2 +-
 hw/xen/xen_backend.c         |  45 +++++-
 hw/xen/xen_frontend.c        | 323 +++++++++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  19 +++
 include/hw/xen/xen_common.h  |   6 +
 qapi-schema.json             |  19 ++-
 qemu-options.hx              |  13 +-
 tpm.c                        |   7 +-
 vl.c                         |  16 ++-
 xen-hvm.c                    |  16 +++
 15 files changed, 983 insertions(+), 14 deletions(-)
 create mode 100644 hw/tpm/tpm_xenstubdoms.c
 create mode 100644 hw/tpm/xen_vtpm_frontend.c
 create mode 100644 hw/xen/xen_frontend.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 Wed Dec 31 03:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y69cY-00013N-OA; Wed, 31 Dec 2014 03:06:50 +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 1Y69cX-00013I-8t
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 03:06:49 +0000
Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id
	3C/C8-25727-84863A45; Wed, 31 Dec 2014 03:06:48 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-8.tower-31.messagelabs.com!1419995206!16548480!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 21839 invoked from network); 31 Dec 2014 03:06:47 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-8.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 03:06:47 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by fmsmga101.fm.intel.com with ESMTP; 30 Dec 2014 19:06:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,669,1413270000"; d="scan'208";a="662710522"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 30 Dec 2014 19:06:43 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Tue, 30 Dec 2014 18:02:50 -0500
Message-Id: <1419980570-18589-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, eblake@redhat.com
Subject: [Xen-devel] [PATCH v3 0/5] 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 v3:
    -New xen_frontend.c file
    -Adjust the format of command line options
    -Move xenbus_switch_state() to xen_frontend.c
    -Move xen_stubdom_be() to xenstore_fe_read_be_str()
    -Move *_stubdom_*() to *_fe_*()
    -Move xen_stubdom_vtpm.c to xen_vtpm_frontend.c
    -Read Xen vTPM status via XenStore
    -Call vtpm_send() and vtpm_recv() directly.

--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 (5):
  Qemu-Xen-vTPM: Support for Xen stubdom vTPM command line options
  Qemu-Xen-vTPM: Xen frontend driver infrastructure
  Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend driver
  Qemu-Xen-vTPM: Qemu vTPM xenstubdoms backen.
  Qemu-Xen-vTPM: QEMU machine class is initialized before tpm_init()

 configure                    |  14 ++
 hmp.c                        |   7 +
 hw/tpm/Makefile.objs         |   1 +
 hw/tpm/tpm_xenstubdoms.c     | 245 ++++++++++++++++++++++++++++++++
 hw/tpm/xen_vtpm_frontend.c   | 264 +++++++++++++++++++++++++++++++++++
 hw/xen/Makefile.objs         |   2 +-
 hw/xen/xen_backend.c         |  45 +++++-
 hw/xen/xen_frontend.c        | 323 +++++++++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  19 +++
 include/hw/xen/xen_common.h  |   6 +
 qapi-schema.json             |  19 ++-
 qemu-options.hx              |  13 +-
 tpm.c                        |   7 +-
 vl.c                         |  16 ++-
 xen-hvm.c                    |  16 +++
 15 files changed, 983 insertions(+), 14 deletions(-)
 create mode 100644 hw/tpm/tpm_xenstubdoms.c
 create mode 100644 hw/tpm/xen_vtpm_frontend.c
 create mode 100644 hw/xen/xen_frontend.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 Wed Dec 31 03:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y69cd-00013Z-EG; Wed, 31 Dec 2014 03:06:55 +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 1Y69cb-00013U-OJ
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 03:06:53 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	C0/EB-09842-D4863A45; Wed, 31 Dec 2014 03:06:53 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1419995210!10535607!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5189 invoked from network); 31 Dec 2014 03:06:51 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-2.tower-21.messagelabs.com with SMTP;
	31 Dec 2014 03:06:51 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 30 Dec 2014 19:02:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="435174683"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 30 Dec 2014 18:54:48 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Tue, 30 Dec 2014 18:02:58 -0500
Message-Id: <1419980578-18628-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] [v3 1/5] 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 | 19 ++++++++++++++++---
 qemu-options.hx  | 13 +++++++++++--
 tpm.c            |  7 ++++++-
 5 files changed, 54 insertions(+), 6 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..9745c2b 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2854,9 +2854,10 @@
 #
 # @passthrough: TPM passthrough type
 #
-# Since: 1.5
+# @xenstubdoms: TPM xenstubdoms type (since 2.3)## 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.3
+##
+{ '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 Wed Dec 31 03:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y69cm-00015D-GN; Wed, 31 Dec 2014 03:07:04 +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 1Y69cl-00014w-D0
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 03:07:03 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	BF/E8-02957-65863A45; Wed, 31 Dec 2014 03:07:02 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1419995220!17832322!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16552 invoked from network); 31 Dec 2014 03:07:01 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-9.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 03:07:01 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by fmsmga103.fm.intel.com with ESMTP; 30 Dec 2014 19:02:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,669,1413270000"; d="scan'208";a="631031696"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 30 Dec 2014 19:06:57 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Tue, 30 Dec 2014 18:03:09 -0500
Message-Id: <1419980589-18741-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] [v3 4/5] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms backen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 provides the glue for the TPM_TIS(Qemu frontend) to Xen
stubdom vTPM domain that provides the actual TPM functionality. It
sends data and TPM commends with xen_vtpm_frontend. It is similar as
another two vTPM backens:
  *vTPM passthrough backen Since QEMU 1.5.
  *vTPM libtpms-based backen.

Some details:
This part of the patch provides support for the spawning of a thread
that will interact with stubdom vTPM domain by the xen_vtpm_frontend.
It expects a signal from the frontend to wake and pick up the TPM
command that is supposed to be processed and delivers the response
packet using a callback function provided by the frontend.

The backend connects itself to the frontend by filling out an interface
structure with pointers to the function implementing support for various
operations.

(QEMU) vTPM XenStubdoms backen is initialized by Qemu command line options,
      "-tpmdev xenstubdoms,id=xenvtpm0 -device tpm-tis,tpmdev=xenvtpm0"

--Changes in v3:
-Call vtpm_send() and vtpm_recv() directly.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/tpm/Makefile.objs     |   2 +-
 hw/tpm/tpm_xenstubdoms.c | 245 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 246 insertions(+), 1 deletion(-)
 create mode 100644 hw/tpm/tpm_xenstubdoms.c

diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 57919fa..190e776 100644
--- a/hw/tpm/Makefile.objs
+++ b/hw/tpm/Makefile.objs
@@ -1,3 +1,3 @@
 common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
 common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
-common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_vtpm_frontend.o
+common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o xen_vtpm_frontend.o
diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c
new file mode 100644
index 0000000..98ea496
--- /dev/null
+++ b/hw/tpm/tpm_xenstubdoms.c
@@ -0,0 +1,245 @@
+/*
+ * 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;
+    struct XenDevice *xendev;
+
+    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;
+    }
+    vtpm_send(xendev, locty_data->w_buffer.buffer, locty_data->w_offset);
+    vtpm_recv(xendev, 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 Wed Dec 31 03:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y69cn-00015e-TF; Wed, 31 Dec 2014 03:07:05 +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 1Y69cm-00015B-PF
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 03:07:04 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	53/71-15461-85863A45; Wed, 31 Dec 2014 03:07:04 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1419995222!18549456!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2994 invoked from network); 31 Dec 2014 03:07:03 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-5.tower-21.messagelabs.com with SMTP;
	31 Dec 2014 03:07:03 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga102.fm.intel.com with ESMTP; 30 Dec 2014 19:07:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="435174719"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 30 Dec 2014 18:55:01 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Tue, 30 Dec 2014 18:03:12 -0500
Message-Id: <1419980592-18778-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] [v3 5/5] 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 Wed Dec 31 03:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y69cf-00013l-Vp; Wed, 31 Dec 2014 03:06:57 +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 1Y69ce-00013d-1V
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 03:06:56 +0000
Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id
	2C/C0-02953-F4863A45; Wed, 31 Dec 2014 03:06:55 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1419995213!12423130!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 29351 invoked from network); 31 Dec 2014 03:06:53 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-16.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 03:06:53 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga102.jf.intel.com with ESMTP; 30 Dec 2014 19:04:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="505972176"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 30 Dec 2014 19:01:39 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Tue, 30 Dec 2014 18:03:02 -0500
Message-Id: <1419980582-18665-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] [v3 2/5] Qemu-Xen-vTPM: Xen frontend driver
	infrastructure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds infrastructure for xen front drivers living in qemu,
so drivers don't need to implement common stuff on their own.  It's
mostly xenbus management stuff: some functions to access XenStore,
setting up XenStore watches, callbacks on device discovery and state
changes, and handle event channel between the virtual machines.

Call xen_fe_register() function to register XenDevOps, and make sure,
XenDevOps's flags is DEVOPS_FLAG_FE, which is flag bit to point out
the XenDevOps is Xen frontend.

--Changes in v3:
-New xen_frontend.c file
-Move xenbus_switch_state() to xen_frontend.c
-Move xen_stubdom_be() to xenstore_fe_read_be_str()
-Move *_stubdom_*() to *_fe_*()

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/xen/Makefile.objs         |   2 +-
 hw/xen/xen_backend.c         |  11 +-
 hw/xen/xen_frontend.c        | 323 +++++++++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  14 ++
 4 files changed, 348 insertions(+), 2 deletions(-)
 create mode 100644 hw/xen/xen_frontend.c

diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index a0ca0aa..b0bb065 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,5 @@
 # xen backend driver support
-common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
+common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o xen_frontend.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..ad6e324 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -275,7 +275,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev,
 /*
  * release xen backend device.
  */
-static struct XenDevice *xen_be_del_xendev(int dom, int dev)
+struct XenDevice *xen_be_del_xendev(int dom, int dev)
 {
     struct XenDevice *xendev, *xnext;
 
@@ -681,6 +681,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) {
+        xenstore_fe_update(vec[XS_WATCH_PATH], (void *)type, dom, (void *)ops);
+    }
 
 cleanup:
     free(vec);
@@ -808,3 +812,8 @@ void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...
     }
     qemu_log_flush();
 }
+
+void xen_qtail_insert_xendev(struct XenDevice *xendev)
+{
+    QTAILQ_INSERT_TAIL(&xendevs, xendev, next);
+}
diff --git a/hw/xen/xen_frontend.c b/hw/xen/xen_frontend.c
new file mode 100644
index 0000000..07ffc5c
--- /dev/null
+++ b/hw/xen/xen_frontend.c
@@ -0,0 +1,323 @@
+/*
+ * Xen frontend driver infrastructure
+ *
+ *  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 <fcntl.h>
+#include <inttypes.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+#include <sys/signal.h>
+
+#include "hw/hw.h"
+#include "sysemu/char.h"
+#include "qemu/log.h"
+#include "hw/xen/xen_backend.h"
+#include <xen/grant_table.h>
+
+/* private */
+static int debug;
+
+/* ------------------------------------------------------------- */
+/*Get backend with fe type|domid, try to write the backend-id when
+ *create virtual machine.
+ *
+ *[XenStore]
+ *
+ *Dom.ID = ""
+ *  device
+ *    vtpm = ""
+ *      0 = ""
+ *        backend-id = "ID"
+ *[..]
+ */
+
+char *xenstore_fe_read_be_str(const char *type, int dom, int dev)
+{
+    char *val, *domu;
+    char path[XEN_BUFSIZE];
+    unsigned int len, ival;
+
+    /*fe path*/
+    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);
+
+    /*be path*/
+    domu = xs_get_domain_path(xenstore, ival);
+
+    return domu;
+}
+
+/*make sure, initialize the 'xendev->fe' in xendev->ops->init() or
+ * xendev->ops->initialize()
+ */
+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;
+    if (xendev->fe == NULL) {
+        xen_be_printf(NULL, 0, "xendev->fe is NULL\n");
+        return -1;
+    }
+
+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;
+}
+
+void xenstore_fe_update(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_FE)) {
+        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_fe_get_xendev(type, dom, dev, ops);
+    if (xendev != NULL) {
+        bepath = xs_read(xenstore, 0, xendev->be, &len);
+        /*bepath is NULL, indicates that the backend is not running,
+         *delete it.
+         */
+        if (bepath == NULL) {
+            xen_be_del_xendev(dom, dev);
+        } else {
+            free(bepath);
+            if (xendev->ops->backend_changed) {
+                xendev->ops->backend_changed(xendev, path);
+            }
+        }
+    }
+}
+
+/*
+ * get xen fe device, allocate a new one if it doesn't exist.
+ */
+struct XenDevice *xen_fe_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;
+
+    /*return if the ops->flags is not DEVOPS_FLAG_FE*/
+    if (!(ops->flags & DEVOPS_FLAG_FE)) {
+        return NULL;
+    }
+
+    stub = xenstore_fe_read_be_str(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;
+    }
+
+    xen_qtail_insert_xendev(xendev);
+
+    if (xendev->ops->alloc) {
+        xendev->ops->alloc(xendev);
+    }
+
+    return xendev;
+}
+
+/* simplify QEMU side, a thread is running in Xen backend, which will
+ * connect frontend when the frontend is initialised. Call these initialised
+ * functions.
+ */
+
+static int xen_fe_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_fe_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;
+
+    /*Xen frontend : /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_fe_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 backend, which will
+         * connect frontend when the frontend is initialised.
+         */
+        if (xen_fe_check(xendev, domid, atoi(dev[j])) < 0) {
+            xen_be_printf(xendev, 0, "xendev fe_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_fe_scan(type, xen_domid, ops);
+}
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 3b4125e..06e202f 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 is frontend device*/
+#define DEVOPS_FLAG_FE            4
 
 struct XenDevOps {
     size_t    size;
@@ -80,6 +82,8 @@ int xenstore_read_fe_uint64(struct XenDevice *xendev, const char *node, uint64_t
 const char *xenbus_strstate(enum xenbus_state state);
 struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev);
 void xen_be_check_state(struct XenDevice *xendev);
+struct XenDevice *xen_be_del_xendev(int dom, int dev);
+void xen_qtail_insert_xendev(struct XenDevice *xendev);
 
 /* xen backend driver bits */
 int xen_be_init(void);
@@ -91,6 +95,16 @@ 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 frontend driver*/
+int xen_fe_register(const char *type, struct XenDevOps *ops);
+int xen_be_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom);
+char *xenstore_fe_read_be_str(const char *type, int dom, int dev);
+int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus);
+struct XenDevice *xen_fe_get_xendev(const char *type, int dom, int dev,
+                                    struct XenDevOps *ops);
+void xenstore_fe_update(char *watch, char *type, int dom,
+                        struct XenDevOps *ops);
+
 /* actual backend drivers */
 extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
 extern struct XenDevOps xen_kbdmouse_ops;     /* xen_framebuffer.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 Wed Dec 31 03:07:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y69cj-00014b-QG; Wed, 31 Dec 2014 03:07:01 +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 1Y69ch-000144-J7
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 03:06:59 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	F7/E1-02702-25863A45; Wed, 31 Dec 2014 03:06:58 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1419995216!17855737!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22350 invoked from network); 31 Dec 2014 03:06:57 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 03:06:57 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by orsmga101.jf.intel.com with ESMTP; 30 Dec 2014 19:06:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,669,1413270000"; d="scan'208";a="644799485"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 30 Dec 2014 19:06:54 -0800
From: Quan Xu <quan.xu@intel.com>
To: qemu-devel@nongnu.org
Date: Tue, 30 Dec 2014 18:03:05 -0500
Message-Id: <1419980585-18704-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] [v3 3/5] 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. It is a glue for
the TPM xenstubdoms driver and Xen stubdom vTPM domain that provides
the actual TPM functionality.

(Xen) Xen backend driver should run before running this frontend, and
initialize XenStore as the following for communication.

[XenStore]
 ..
  FE.DOMAIN.ID
   device = ""
    vtpm = ""
     0 = ""
      backend = "/local/domain/{BE.DOMAIN.ID}/backend/vtpm/{FE.DOMAIN.ID}/0"
      backend-id = "BE.DOMAIN.ID"
      state = "1"
      handle = "0"
 ..

(QEMU) xen_vtpmdev_ops is initialized with the following process:
  xen_hvm_init()
    [...]
    -->xen_fe_register("vtpm", ...)
      -->xenstore_fe_scan()
        -->xen_fe_get_xendev()
          --> XenDevOps.alloc()
        -->xen_fe_check()
          --> XenDevOps.init()
          --> XenDevOps.initialise()
          --> XenDevOps.connected()
        -->xs_watch()
    [...]

--Changes in v3:
-Move xen_stubdom_vtpm.c to xen_vtpm_frontend.c
-Read Xen vTPM status via XenStore

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 hw/tpm/Makefile.objs         |   1 +
 hw/tpm/xen_vtpm_frontend.c   | 264 +++++++++++++++++++++++++++++++++++++++++++
 hw/xen/xen_backend.c         |  34 ++++++
 include/hw/xen/xen_backend.h |   9 +-
 include/hw/xen/xen_common.h  |   6 +
 xen-hvm.c                    |  16 +++
 6 files changed, 328 insertions(+), 2 deletions(-)
 create mode 100644 hw/tpm/xen_vtpm_frontend.c

diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 99f5983..57919fa 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_vtpm_frontend.o
diff --git a/hw/tpm/xen_vtpm_frontend.c b/hw/tpm/xen_vtpm_frontend.c
new file mode 100644
index 0000000..00cc888
--- /dev/null
+++ b/hw/tpm/xen_vtpm_frontend.c
@@ -0,0 +1,264 @@
+/*
+ * 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 xen_vtpm_dev {
+    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 xen_vtpm_dev *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 bool vtpm_aio_wait(AioContext *ctx)
+{
+    return aio_poll(ctx, true);
+}
+
+static void sr_bh_handler(void *opaque)
+{
+}
+
+int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count)
+{
+    struct xen_vtpm_dev *vtpmdev = container_of(xendev, struct xen_vtpm_dev,
+                                                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;
+}
+
+int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count)
+{
+    struct xen_vtpm_dev *vtpmdev = container_of(xendev, struct xen_vtpm_dev,
+                                                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 xen_vtpm_dev *vtpmdev = container_of(xendev, struct xen_vtpm_dev,
+                                                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 int vtpm_free(struct XenDevice *xendev)
+{
+    struct xen_vtpm_dev *vtpmdev = container_of(xendev, struct xen_vtpm_dev,
+                                                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 xen_vtpm_dev *vtpmdev = container_of(xendev, struct xen_vtpm_dev,
+                                                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 xen_vtpm_dev *vtpmdev = container_of(xendev, struct xen_vtpm_dev,
+                                                xendev);
+
+    qemu_bh_schedule(vtpmdev->sr_bh);
+}
+
+struct XenDevOps xen_vtpmdev_ops = {
+    .size             = sizeof(struct xen_vtpm_dev),
+    .flags            = DEVOPS_FLAG_IGNORE_STATE |
+                        DEVOPS_FLAG_FE,
+    .event            = vtpm_event,
+    .free             = vtpm_free,
+    .alloc            = vtpm_alloc,
+    .initialise       = vtpm_initialise,
+    .backend_changed  = vtpm_backend_changed,
+};
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index ad6e324..377a9c8 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -741,6 +741,20 @@ 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) {
@@ -813,6 +827,26 @@ void xen_be_printf(struct XenDevice *xendev, int msg_level, const char *fmt, ...
     qemu_log_flush();
 }
 
+void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
+{
+    int be_state;
+
+    if (strcmp(node, "state") == 0) {
+        xenstore_read_be_int(xendev, node, &be_state);
+        switch (be_state) {
+        case XenbusStateConnected:
+            /*TODO*/
+            break;
+        case XenbusStateClosing:
+        case XenbusStateClosed:
+            xenbus_switch_state(xendev, XenbusStateClosing);
+            break;
+        default:
+            break;
+        }
+    }
+}
+
 void xen_qtail_insert_xendev(struct XenDevice *xendev)
 {
     QTAILQ_INSERT_TAIL(&xendevs, xendev, next);
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 06e202f..d07ae36 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -102,8 +102,12 @@ char *xenstore_fe_read_be_str(const char *type, int dom, int dev);
 int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus);
 struct XenDevice *xen_fe_get_xendev(const char *type, int dom, int dev,
                                     struct XenDevOps *ops);
-void xenstore_fe_update(char *watch, char *type, int dom,
-                        struct XenDevOps *ops);
+void xenstore_fe_update(char *watch, char *type, int dom, struct XenDevOps *ops);
+
+/*Xen vtpm*/
+int vtpm_send(struct XenDevice *xendev, uint8_t* buf, size_t count);
+int vtpm_recv(struct XenDevice *xendev, uint8_t* buf, size_t *count);
+void vtpm_backend_changed(struct XenDevice *xendev, const char *node);
 
 /* actual backend drivers */
 extern struct XenDevOps xen_console_ops;      /* xen_console.c     */
@@ -111,6 +115,7 @@ 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_vtpm_frontend.c*/
 
 void xen_init_display(int domid);
 
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 07731b9..2e9bb62 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 05e522c..5b93cd4 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -986,6 +986,12 @@ 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
+    char path[XEN_BUFSIZE];
+    unsigned int stubdom_vtpm = 0;
+#endif
+
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -1071,6 +1077,16 @@ 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
+    snprintf(path, sizeof(path), "/local/domain/%d/platform/acpi_stubdom_vtpm",
+             xen_domid);
+    xs_read(state->xenstore, 0, path, &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 Wed Dec 31 07:39:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 07: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 1Y6Drv-0006EF-Vw; Wed, 31 Dec 2014 07:38:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.haoxudong@huawei.com>) id 1Y6Dru-0006EA-I5
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 07:38:58 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	47/F3-17958-118A3A45; Wed, 31 Dec 2014 07:38:57 +0000
X-Env-Sender: eric.haoxudong@huawei.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1420011531!12824446!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6189 invoked from network); 31 Dec 2014 07:38:55 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2014 07:38:55 -0000
Received: from 172.24.2.119 (EHLO szxeml448-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CGV33747; Wed, 31 Dec 2014 15:38:50 +0800 (CST)
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.153]) by
	szxeml448-hub.china.huawei.com ([10.82.67.191]) with mapi id
	14.03.0158.001; Wed, 31 Dec 2014 15:38:42 +0800
From: "haoxudong (A)" <eric.haoxudong@huawei.com>
To: "Xiaoding (B)" <xiaoding1@huawei.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: How can I get the real load of my program ?
Thread-Index: AdAjZbILVW2bpL9gTiONPMPlh1hlIQBZlCng
Date: Wed, 31 Dec 2014 07:38:42 +0000
Message-ID: <C8E35D6F81BE5548A08F460C062AA984D16741@szxeml557-mbs.china.huawei.com>
References: <89E0966AE9A1C3499DBCD33F337DA29B27922CFE@szxema505-mbs.china.huawei.com>
In-Reply-To: <89E0966AE9A1C3499DBCD33F337DA29B27922CFE@szxema505-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.238.126]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Zhangleiqiang \(Trump\)" <zhangleiqiang@huawei.com>,
	"ssdxiao@163.com" <ssdxiao@163.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: [Xen-devel] =?utf-8?b?562U5aSNOiBIb3cgY2FuIEkgZ2V0IHRoZSByZWFs?=
 =?utf-8?q?_load_of_my_program_=3F?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6610255154149978811=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6610255154149978811==
Content-Language: zh-CN
Content-Type: multipart/alternative;
	boundary="_000_C8E35D6F81BE5548A08F460C062AA984D16741szxeml557mbschina_"

--_000_C8E35D6F81BE5548A08F460C062AA984D16741szxeml557mbschina_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

WGVudG9wIHNob3cgdGhlIERvbVXigJlzIHRvdGFsIGNwdSB1dGlsJSwgeW91ciBEb21VIGlzIG11
bHRpLVZDUFUgZG9tYWluLCByaWdodD8NCklmIOKAnHRvcOKAnSwgeW91IGNhbiB1c2Ug4oCcMeKA
nSB0byBjaGVjayBlYWNoIGNwdeKAmXMgdXRpbCUuDQoNCkJlc3QgUmVnYXJkcywNClh1ZG9uZw0K
DQpGcm9tOiB4ZW4tZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW4ub3JnIFttYWlsdG86eGVuLWRldmVs
LWJvdW5jZXNAbGlzdHMueGVuLm9yZ10gT24gQmVoYWxmIE9mIFhpYW9kaW5nIChCKQ0KU2VudDog
TW9uZGF5LCBEZWNlbWJlciAyOSwgMjAxNCA4OjQ4IFBNDQpUbzogeGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcNCkNjOiBaaGFuZ2xlaXFpYW5nIChUcnVtcCk7IHNzZHhpYW9AMTYzLmNvbTsgTHVvaGFv
IChicmlhbik7IFpodWFuZ3l1eGluOyBZdXpob3UgKEMpDQpTdWJqZWN0OiBbWGVuLWRldmVsXSBI
b3cgY2FuIEkgZ2V0IHRoZSByZWFsIGxvYWQgb2YgbXkgcHJvZ3JhbSA/DQoNCkhp77yMQWxsDQoN
CldoZW4gbXkgcHJvZ3JhbSBydW4gbWVtY3B5IGluIERvbVXvvIwgSSB1c2UgdG9wIG1vbml0b3Ig
dGhlIGNwdSBvbmx5IHVzaW5nIDMwJQ0KQnV0IHdoZW4gSSB1c2UgeGVudG9w77yMSSBmaW5kIERv
bVUgdXNlIGNwdSAxMDAlDQoNCkhvdyBjYW4gSSBnZXQgdGhlIHJlYWwgbG9hZCBvZiBteSBwcm9n
cmFtID8NCg0KDQoNClhpYW9kaW5nDQpSZWdhcmRzDQoNCg0KDQoNCg==

--_000_C8E35D6F81BE5548A08F460C062AA984D16741szxeml557mbschina_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v
c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc
QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7
DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0K
c3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuag
vOW8jyI7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2
MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4
PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i
MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5
IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0idGV4dC1qdXN0
aWZ5LXRyaW06cHVuY3R1YXRpb24iPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp
YnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFG
NDk3RCI+WGVudG9wIHNob3cgdGhlIERvbVXigJlzIHRvdGFsIGNwdSB1dGlsJSwgeW91ciBEb21V
IGlzIG11bHRpLVZDUFUgZG9tYWluLCByaWdodD88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh
Y2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj
b2xvcjojMUY0OTdEIj5JZiDigJx0b3DigJ0sIHlvdSBjYW4gdXNlIOKAnDHigJ0gdG8gY2hlY2sg
ZWFjaCBjcHXigJlzIHV0aWwlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy
aSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE
Ij5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+
WHVkb25nPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0
Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0
REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PGZvbnQgc2l6ZT0iMiIg
ZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Zm9u
dC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNl
PSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogeGVu
LWRldmVsLWJvdW5jZXNAbGlzdHMueGVuLm9yZyBbbWFpbHRvOnhlbi1kZXZlbC1ib3VuY2VzQGxp
c3RzLnhlbi5vcmddIDxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5PbiBCZWhhbGYg
T2YNCjwvc3Bhbj48L2I+WGlhb2RpbmcgKEIpPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2Vp
Z2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gTW9uZGF5LCBEZWNlbWJlciAyOSwgMjAxNCA4OjQ4
IFBNPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+
IHhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0
OmJvbGQiPkNjOjwvc3Bhbj48L2I+IFpoYW5nbGVpcWlhbmcgKFRydW1wKTsgc3NkeGlhb0AxNjMu
Y29tOyBMdW9oYW8gKGJyaWFuKTsgWmh1YW5neXV4aW47IFl1emhvdSAoQyk8YnI+DQo8Yj48c3Bh
biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBbWGVuLWRldmVs
XSBIb3cgY2FuIEkgZ2V0IHRoZSByZWFsIGxvYWQgb2YgbXkgcHJvZ3JhbSA/PG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh
bGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i
Q2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv
bnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0Ij5IaTwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2T
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPu+8jDwv
c3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0Ij5BbGw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMzNDM0MzQiIGZhY2U9IkNhbGlicmki
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMzQzNDM0
O2JhY2tncm91bmQ6I0ZCRkNGRSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+V2hlbiBteSBwcm9ncmFtIHJ1
biBtZW1jcHkgaW4gRG9tVTwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2T
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPu+8jDwv
c3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0Ij4NCiBJIHVzZSB0b3AgbW9uaXRvciB0aGUgY3B1IG9ubHkgdXNpbmcgMzAl
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250
IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEyLjBwdCI+QnV0IHdoZW4gSSB1c2UgeGVudG9wPC9zcGFuPjwvZm9udD48Zm9udCBzaXpl
PSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt
aWx5OuWui+S9kyI+77yMPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIzIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkkNCiBmaW5kIERvbVUgdXNlIGNwdSAxMDAl
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250
IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SG93IGNhbiBJIGdldCB0aGUgcmVhbCBsb2Fk
IG9mIG15IHByb2dyYW0gPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJp
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl
PSIzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPlhpYW9kaW5nPG86cD48L286cD48L3NwYW4+PC9mb250
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+UmVnYXJkczxvOnA+
PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl
PSIzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzM0MzQzNCIgZmFjZT0iQXJpYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzNDM0MzQ7YmFja2dyb3Vu
ZDojRkJGQ0ZFIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzNDM0MzQiIGZhY2U9IkFyaWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzQzNDM0O2JhY2tn
cm91bmQ6I0ZCRkNGRSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzQzNDM0IiBmYWNlPSJBcmlh
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzM0MzQzNDti
YWNrZ3JvdW5kOiNGQkZDRkUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_C8E35D6F81BE5548A08F460C062AA984D16741szxeml557mbschina_--


--===============6610255154149978811==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6610255154149978811==--


From xen-devel-bounces@lists.xen.org Wed Dec 31 07:39:39 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 07: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 1Y6Drv-0006EF-Vw; Wed, 31 Dec 2014 07:38:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.haoxudong@huawei.com>) id 1Y6Dru-0006EA-I5
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 07:38:58 +0000
Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id
	47/F3-17958-118A3A45; Wed, 31 Dec 2014 07:38:57 +0000
X-Env-Sender: eric.haoxudong@huawei.com
X-Msg-Ref: server-9.tower-31.messagelabs.com!1420011531!12824446!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6189 invoked from network); 31 Dec 2014 07:38:55 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64)
	by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2014 07:38:55 -0000
Received: from 172.24.2.119 (EHLO szxeml448-hub.china.huawei.com)
	([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
	with ESMTP id CGV33747; Wed, 31 Dec 2014 15:38:50 +0800 (CST)
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.153]) by
	szxeml448-hub.china.huawei.com ([10.82.67.191]) with mapi id
	14.03.0158.001; Wed, 31 Dec 2014 15:38:42 +0800
From: "haoxudong (A)" <eric.haoxudong@huawei.com>
To: "Xiaoding (B)" <xiaoding1@huawei.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: How can I get the real load of my program ?
Thread-Index: AdAjZbILVW2bpL9gTiONPMPlh1hlIQBZlCng
Date: Wed, 31 Dec 2014 07:38:42 +0000
Message-ID: <C8E35D6F81BE5548A08F460C062AA984D16741@szxeml557-mbs.china.huawei.com>
References: <89E0966AE9A1C3499DBCD33F337DA29B27922CFE@szxema505-mbs.china.huawei.com>
In-Reply-To: <89E0966AE9A1C3499DBCD33F337DA29B27922CFE@szxema505-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.238.126]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "Zhangleiqiang \(Trump\)" <zhangleiqiang@huawei.com>,
	"ssdxiao@163.com" <ssdxiao@163.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>
Subject: [Xen-devel] =?utf-8?b?562U5aSNOiBIb3cgY2FuIEkgZ2V0IHRoZSByZWFs?=
 =?utf-8?q?_load_of_my_program_=3F?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6610255154149978811=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6610255154149978811==
Content-Language: zh-CN
Content-Type: multipart/alternative;
	boundary="_000_C8E35D6F81BE5548A08F460C062AA984D16741szxeml557mbschina_"

--_000_C8E35D6F81BE5548A08F460C062AA984D16741szxeml557mbschina_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

WGVudG9wIHNob3cgdGhlIERvbVXigJlzIHRvdGFsIGNwdSB1dGlsJSwgeW91ciBEb21VIGlzIG11
bHRpLVZDUFUgZG9tYWluLCByaWdodD8NCklmIOKAnHRvcOKAnSwgeW91IGNhbiB1c2Ug4oCcMeKA
nSB0byBjaGVjayBlYWNoIGNwdeKAmXMgdXRpbCUuDQoNCkJlc3QgUmVnYXJkcywNClh1ZG9uZw0K
DQpGcm9tOiB4ZW4tZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW4ub3JnIFttYWlsdG86eGVuLWRldmVs
LWJvdW5jZXNAbGlzdHMueGVuLm9yZ10gT24gQmVoYWxmIE9mIFhpYW9kaW5nIChCKQ0KU2VudDog
TW9uZGF5LCBEZWNlbWJlciAyOSwgMjAxNCA4OjQ4IFBNDQpUbzogeGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcNCkNjOiBaaGFuZ2xlaXFpYW5nIChUcnVtcCk7IHNzZHhpYW9AMTYzLmNvbTsgTHVvaGFv
IChicmlhbik7IFpodWFuZ3l1eGluOyBZdXpob3UgKEMpDQpTdWJqZWN0OiBbWGVuLWRldmVsXSBI
b3cgY2FuIEkgZ2V0IHRoZSByZWFsIGxvYWQgb2YgbXkgcHJvZ3JhbSA/DQoNCkhp77yMQWxsDQoN
CldoZW4gbXkgcHJvZ3JhbSBydW4gbWVtY3B5IGluIERvbVXvvIwgSSB1c2UgdG9wIG1vbml0b3Ig
dGhlIGNwdSBvbmx5IHVzaW5nIDMwJQ0KQnV0IHdoZW4gSSB1c2UgeGVudG9w77yMSSBmaW5kIERv
bVUgdXNlIGNwdSAxMDAlDQoNCkhvdyBjYW4gSSBnZXQgdGhlIHJlYWwgbG9hZCBvZiBteSBwcm9n
cmFtID8NCg0KDQoNClhpYW9kaW5nDQpSZWdhcmRzDQoNCg0KDQoNCg==

--_000_C8E35D6F81BE5548A08F460C062AA984D16741szxeml557mbschina_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v
c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc
QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7
DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0K
c3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuag
vOW8jyI7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2
MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4
PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i
MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5
IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0idGV4dC1qdXN0
aWZ5LXRyaW06cHVuY3R1YXRpb24iPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp
YnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFG
NDk3RCI+WGVudG9wIHNob3cgdGhlIERvbVXigJlzIHRvdGFsIGNwdSB1dGlsJSwgeW91ciBEb21V
IGlzIG11bHRpLVZDUFUgZG9tYWluLCByaWdodD88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh
Y2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj
b2xvcjojMUY0OTdEIj5JZiDigJx0b3DigJ0sIHlvdSBjYW4gdXNlIOKAnDHigJ0gdG8gY2hlY2sg
ZWFjaCBjcHXigJlzIHV0aWwlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy
aSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE
Ij5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+
WHVkb25nPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0
Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0
REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PGZvbnQgc2l6ZT0iMiIg
ZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Zm9u
dC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNl
PSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogeGVu
LWRldmVsLWJvdW5jZXNAbGlzdHMueGVuLm9yZyBbbWFpbHRvOnhlbi1kZXZlbC1ib3VuY2VzQGxp
c3RzLnhlbi5vcmddIDxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5PbiBCZWhhbGYg
T2YNCjwvc3Bhbj48L2I+WGlhb2RpbmcgKEIpPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2Vp
Z2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gTW9uZGF5LCBEZWNlbWJlciAyOSwgMjAxNCA4OjQ4
IFBNPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+
IHhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0
OmJvbGQiPkNjOjwvc3Bhbj48L2I+IFpoYW5nbGVpcWlhbmcgKFRydW1wKTsgc3NkeGlhb0AxNjMu
Y29tOyBMdW9oYW8gKGJyaWFuKTsgWmh1YW5neXV4aW47IFl1emhvdSAoQyk8YnI+DQo8Yj48c3Bh
biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBbWGVuLWRldmVs
XSBIb3cgY2FuIEkgZ2V0IHRoZSByZWFsIGxvYWQgb2YgbXkgcHJvZ3JhbSA/PG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh
bGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i
Q2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv
bnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0Ij5IaTwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2T
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPu+8jDwv
c3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0Ij5BbGw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMzNDM0MzQiIGZhY2U9IkNhbGlicmki
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMzQzNDM0
O2JhY2tncm91bmQ6I0ZCRkNGRSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+V2hlbiBteSBwcm9ncmFtIHJ1
biBtZW1jcHkgaW4gRG9tVTwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2T
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPu+8jDwv
c3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0Ij4NCiBJIHVzZSB0b3AgbW9uaXRvciB0aGUgY3B1IG9ubHkgdXNpbmcgMzAl
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250
IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEyLjBwdCI+QnV0IHdoZW4gSSB1c2UgeGVudG9wPC9zcGFuPjwvZm9udD48Zm9udCBzaXpl
PSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt
aWx5OuWui+S9kyI+77yMPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIzIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkkNCiBmaW5kIERvbVUgdXNlIGNwdSAxMDAl
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250
IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SG93IGNhbiBJIGdldCB0aGUgcmVhbCBsb2Fk
IG9mIG15IHByb2dyYW0gPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJDYWxpYnJp
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl
PSIzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPlhpYW9kaW5nPG86cD48L286cD48L3NwYW4+PC9mb250
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+UmVnYXJkczxvOnA+
PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl
PSIzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzM0MzQzNCIgZmFjZT0iQXJpYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzNDM0MzQ7YmFja2dyb3Vu
ZDojRkJGQ0ZFIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzNDM0MzQiIGZhY2U9IkFyaWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzQzNDM0O2JhY2tn
cm91bmQ6I0ZCRkNGRSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzQzNDM0IiBmYWNlPSJBcmlh
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzM0MzQzNDti
YWNrZ3JvdW5kOiNGQkZDRkUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_C8E35D6F81BE5548A08F460C062AA984D16741szxeml557mbschina_--


--===============6610255154149978811==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6610255154149978811==--


From xen-devel-bounces@lists.xen.org Wed Dec 31 08:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 08: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 1Y6Exa-0007mS-K6; Wed, 31 Dec 2014 08:48:54 +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 1Y6ExY-0007mN-US
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 08:48:53 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	73/CA-31453-478B3A45; Wed, 31 Dec 2014 08:48:52 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1420015730!15735991!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14629 invoked from network); 31 Dec 2014 08:48:51 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-206.messagelabs.com with SMTP;
	31 Dec 2014 08:48:51 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by fmsmga102.fm.intel.com with ESMTP; 31 Dec 2014 00:48:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="506056757"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 31 Dec 2014 00:43:34 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 30 Dec 2014 23:44:54 -0500
Message-Id: <1420001094-23966-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 1/5] 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 extras/mini-os/include/tpmback.h |  3 +++
 extras/mini-os/tpmback.c         | 20 +++++++++++++++++---
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h
index 4408986..2618098 100644
--- a/extras/mini-os/include/tpmback.h
+++ b/extras/mini-os/include/tpmback.h
@@ -41,6 +41,9 @@
 #ifndef TPMBACK_H
 #define TPMBACK_H
 
+#define T_DOMAIN_TYPE_HVM 1
+#define T_DOMAIN_TYPE_PV  2
+
 struct tpmcmd {
    domid_t domid;		/* Domid of the frontend */
    uint8_t locality;    /* Locality requested by the frontend */
diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
index 00b66e8..d76e05e 100644
--- a/extras/mini-os/tpmback.c
+++ b/extras/mini-os/tpmback.c
@@ -555,7 +555,7 @@ int connect_fe(tpmif_t* tpmif)
 {
    char path[512];
    char* err, *value;
-   uint32_t domid;
+   uint32_t domid, domtype;
    grant_ref_t ringref;
    evtchn_port_t evtchn;
 
@@ -608,14 +608,28 @@ int connect_fe(tpmif_t* tpmif)
    }
    free(value);
 
-   domid = tpmif->domid;
+   /* get the domain type*/
+   snprintf(path, 512, "%s/domain-type", tpmif->fe_path);
+   if ((err = xenbus_read(XBT_NIL, path, &value))) {
+       TPMBACK_ERR("xenbus_read(%s) Error = %s", path, err);
+       free(err);
+       return -1;
+   }
+   if (sscanf(value, "%d", &domtype) != 1) {
+       TPMBACK_ERR("Non integer value (%s) \n", value);
+       free(value);
+       return -1;
+   }
+
+   printk("domtype = %d \n",domtype);
+   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
    if((tpmif->page = gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0, &ringref, PROT_READ | PROT_WRITE)) == NULL) {
       TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
       return -1;
    }
 
    /*Bind the event channel */
-   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn)))
+   if((evtchn_bind_interdomain(domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn)))
    {
       TPMBACK_ERR("%u/%u Unable to bind to interdomain event channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
       goto error_post_map;
-- 
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 Dec 31 08:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 08: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 1Y6Exo-0007nQ-Bl; Wed, 31 Dec 2014 08:49:08 +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 1Y6Exm-0007n9-KR
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 08:49:06 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	49/E6-02957-188B3A45; Wed, 31 Dec 2014 08:49:05 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1420015744!17919421!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17797 invoked from network); 31 Dec 2014 08:49:05 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-12.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 08:49:05 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 31 Dec 2014 00:44:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="644889073"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 31 Dec 2014 00:49:00 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 30 Dec 2014 23:45:02 -0500
Message-Id: <1420001102-24005-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 2/5] vTPM: limit libxl__add_vtpms() function
	to para 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

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 tools/libxl/libxl_create.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..0a09925 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1358,8 +1358,9 @@ static void domcreate_attach_vtpms(libxl__egc *egc,
        goto error_out;
    }
 
-    /* Plug vtpm devices */
-   if (d_config->num_vtpms > 0) {
+   /* Plug vtpm devices for para virtual domain*/
+   if (d_config->num_vtpms > 0 &&
+       d_config->b_info.type == LIBXL_DOMAIN_TYPE_PV) {
        /* Attach vtpms */
        libxl__multidev_begin(ao, &dcs->multidev);
        dcs->multidev.callback = domcreate_attach_pci;
-- 
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 Dec 31 08:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 08: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 1Y6Ey2-0007q2-UT; Wed, 31 Dec 2014 08:49:22 +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 1Y6Ey1-0007pg-25
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 08:49:21 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	C7/6B-31453-098B3A45; Wed, 31 Dec 2014 08:49:20 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1420015758!12862082!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26550 invoked from network); 31 Dec 2014 08:49:19 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-16.tower-206.messagelabs.com with SMTP;
	31 Dec 2014 08:49:19 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by orsmga101.jf.intel.com with ESMTP; 31 Dec 2014 00:49:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="655274339"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 31 Dec 2014 00:49:17 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 30 Dec 2014 23:45:14 -0500
Message-Id: <1420001114-24044-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 3/5] vTPM: add TPM TCPA and SSDT for HVM
	virtual machine when vTPM is added
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 tools/firmware/hvmloader/acpi/build.c | 5 +++--
 tools/libxl/libxl_create.c            | 5 ++++-
 tools/libxl/libxl_types.idl           | 1 +
 tools/libxl/xl_cmdimpl.c              | 2 ++
 4 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 1431296..f2aa071 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -313,9 +313,10 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
 
     /* TPM TCPA and SSDT. */
     tis_hdr = (uint16_t *)0xFED40F00;
-    if ( (tis_hdr[0] == tis_signature[0]) &&
+    if ( ((tis_hdr[0] == tis_signature[0]) &&
          (tis_hdr[1] == tis_signature[1]) &&
-         (tis_hdr[2] == tis_signature[2]) )
+         (tis_hdr[2] == tis_signature[2])) ||
+         !strncmp(xenstore_read("platform/acpi_stubdom_vtpm", "1"), "1", 1) )
     {
         ssdt = mem_alloc(sizeof(ssdt_tpm), 16);
         if (!ssdt) return -1;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 0a09925..c6f68fe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -432,7 +432,7 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 9, sizeof(char *));
+        localents = libxl__calloc(gc, 11, sizeof(char *));
         i = 0;
         localents[i++] = "platform/acpi";
         localents[i++] = libxl_defbool_val(info->u.hvm.acpi) ? "1" : "0";
@@ -440,6 +440,9 @@ int libxl__domain_build(libxl__gc *gc,
         localents[i++] = libxl_defbool_val(info->u.hvm.acpi_s3) ? "1" : "0";
         localents[i++] = "platform/acpi_s4";
         localents[i++] = libxl_defbool_val(info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[i++] = "platform/acpi_stubdom_vtpm";
+        localents[i++] = (info->num_vtpms > 0) ? "1" : "0";
+
         if (info->u.hvm.mmio_hole_memkb) {
             uint64_t max_ram_below_4g =
                 (1ULL << 32) - (info->u.hvm.mmio_hole_memkb << 10);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ca3f724..b08b974 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -379,6 +379,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     # if you set device_model you must set device_model_version too
     ("device_model",     string),
     ("device_model_ssidref", uint32),
+    ("num_vtpms", integer),
     ("device_model_ssid_label", string),
 
     # extra parameters pass directly to qemu, NULL terminated
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..9c43e88 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1414,6 +1414,7 @@ static void parse_config_data(const char *config_source,
 
     if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
         d_config->num_vtpms = 0;
+        b_info->num_vtpms = 0;
         d_config->vtpms = NULL;
         while ((buf = xlu_cfg_get_listitem (vtpms, d_config->num_vtpms)) != NULL) {
             libxl_device_vtpm *vtpm;
@@ -1456,6 +1457,7 @@ static void parse_config_data(const char *config_source,
             }
             free(buf2);
             d_config->num_vtpms++;
+            b_info->num_vtpms++;
         }
     }
 
-- 
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 Dec 31 08:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 08: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 1Y6Exf-0007me-Vo; Wed, 31 Dec 2014 08:48:59 +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 1Y6Exf-0007mZ-55
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 08:48:59 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	6E/4C-27785-A78B3A45; Wed, 31 Dec 2014 08:48:58 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1420015736!14571521!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=1.2 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11701 invoked from network); 31 Dec 2014 08:48:56 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-11.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 08:48:56 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 31 Dec 2014 00:45:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="631115659"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 31 Dec 2014 00:48:39 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 30 Dec 2014 23:44:46 -0500
Message-Id: <1420001086-23929-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	Quan Xu <quan.xu@intel.com>, samuel.thibault@ens-lyon.org,
	dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH v2 0/5] 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>
MIME-Version: 1.0
Content-Type: text/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 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.

========================
    *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.

========================
    *BUILD & TEST*
========================
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 later. 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 
    '[PATCH v3 0/5] QEMU:Xen stubdom vTPM for HVM virtual machine'.
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 ?= 25694232b64104fd4fa2b8086f790b156a970e1e

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


--Changes in v2:
  -Delete HVM_PARAM_STUBDOM_VTPM parameter, QEMU Reads Xen vTPM status via XenStore.



Quan Xu (5):
  vTPM: event channel bind interdomain with para/hvm virtual machine
  vTPM: limit libxl__add_vtpms() function to para virtual machine
  vTPM: add TPM TCPA and SSDT for HVM virtual machine when vTPM is added
  vTPM: add vTPM device for HVM virtual machine
  vTPM: add QEMU_STUBDOM_VTPM compile option

 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_internal.h          |  3 ++
 tools/libxl/libxl_types.idl           |  1 +
 tools/libxl/xl_cmdimpl.c              |  2 ++
 11 files changed, 131 insertions(+), 8 deletions(-)

-- 
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 Dec 31 08:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 08: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 1Y6Exo-0007nQ-Bl; Wed, 31 Dec 2014 08:49:08 +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 1Y6Exm-0007n9-KR
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 08:49:06 +0000
Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id
	49/E6-02957-188B3A45; Wed, 31 Dec 2014 08:49:05 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1420015744!17919421!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17797 invoked from network); 31 Dec 2014 08:49:05 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-12.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 08:49:05 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 31 Dec 2014 00:44:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="644889073"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 31 Dec 2014 00:49:00 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 30 Dec 2014 23:45:02 -0500
Message-Id: <1420001102-24005-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 2/5] vTPM: limit libxl__add_vtpms() function
	to para 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

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 tools/libxl/libxl_create.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..0a09925 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1358,8 +1358,9 @@ static void domcreate_attach_vtpms(libxl__egc *egc,
        goto error_out;
    }
 
-    /* Plug vtpm devices */
-   if (d_config->num_vtpms > 0) {
+   /* Plug vtpm devices for para virtual domain*/
+   if (d_config->num_vtpms > 0 &&
+       d_config->b_info.type == LIBXL_DOMAIN_TYPE_PV) {
        /* Attach vtpms */
        libxl__multidev_begin(ao, &dcs->multidev);
        dcs->multidev.callback = domcreate_attach_pci;
-- 
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 Dec 31 08:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 08: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 1Y6Exf-0007me-Vo; Wed, 31 Dec 2014 08:48:59 +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 1Y6Exf-0007mZ-55
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 08:48:59 +0000
Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id
	6E/4C-27785-A78B3A45; Wed, 31 Dec 2014 08:48:58 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1420015736!14571521!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=1.2 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11701 invoked from network); 31 Dec 2014 08:48:56 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-11.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 08:48:56 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 31 Dec 2014 00:45:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="631115659"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 31 Dec 2014 00:48:39 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 30 Dec 2014 23:44:46 -0500
Message-Id: <1420001086-23929-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	Quan Xu <quan.xu@intel.com>, samuel.thibault@ens-lyon.org,
	dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH v2 0/5] 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>
MIME-Version: 1.0
Content-Type: text/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 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.

========================
    *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.

========================
    *BUILD & TEST*
========================
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 later. 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 
    '[PATCH v3 0/5] QEMU:Xen stubdom vTPM for HVM virtual machine'.
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 ?= 25694232b64104fd4fa2b8086f790b156a970e1e

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


--Changes in v2:
  -Delete HVM_PARAM_STUBDOM_VTPM parameter, QEMU Reads Xen vTPM status via XenStore.



Quan Xu (5):
  vTPM: event channel bind interdomain with para/hvm virtual machine
  vTPM: limit libxl__add_vtpms() function to para virtual machine
  vTPM: add TPM TCPA and SSDT for HVM virtual machine when vTPM is added
  vTPM: add vTPM device for HVM virtual machine
  vTPM: add QEMU_STUBDOM_VTPM compile option

 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_internal.h          |  3 ++
 tools/libxl/libxl_types.idl           |  1 +
 tools/libxl/xl_cmdimpl.c              |  2 ++
 11 files changed, 131 insertions(+), 8 deletions(-)

-- 
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 Dec 31 08:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 08: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 1Y6Ey2-0007q2-UT; Wed, 31 Dec 2014 08:49:22 +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 1Y6Ey1-0007pg-25
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 08:49:21 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	C7/6B-31453-098B3A45; Wed, 31 Dec 2014 08:49:20 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1420015758!12862082!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26550 invoked from network); 31 Dec 2014 08:49:19 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-16.tower-206.messagelabs.com with SMTP;
	31 Dec 2014 08:49:19 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by orsmga101.jf.intel.com with ESMTP; 31 Dec 2014 00:49:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="655274339"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 31 Dec 2014 00:49:17 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 30 Dec 2014 23:45:14 -0500
Message-Id: <1420001114-24044-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 3/5] vTPM: add TPM TCPA and SSDT for HVM
	virtual machine when vTPM is added
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 tools/firmware/hvmloader/acpi/build.c | 5 +++--
 tools/libxl/libxl_create.c            | 5 ++++-
 tools/libxl/libxl_types.idl           | 1 +
 tools/libxl/xl_cmdimpl.c              | 2 ++
 4 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 1431296..f2aa071 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -313,9 +313,10 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
 
     /* TPM TCPA and SSDT. */
     tis_hdr = (uint16_t *)0xFED40F00;
-    if ( (tis_hdr[0] == tis_signature[0]) &&
+    if ( ((tis_hdr[0] == tis_signature[0]) &&
          (tis_hdr[1] == tis_signature[1]) &&
-         (tis_hdr[2] == tis_signature[2]) )
+         (tis_hdr[2] == tis_signature[2])) ||
+         !strncmp(xenstore_read("platform/acpi_stubdom_vtpm", "1"), "1", 1) )
     {
         ssdt = mem_alloc(sizeof(ssdt_tpm), 16);
         if (!ssdt) return -1;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 0a09925..c6f68fe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -432,7 +432,7 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 9, sizeof(char *));
+        localents = libxl__calloc(gc, 11, sizeof(char *));
         i = 0;
         localents[i++] = "platform/acpi";
         localents[i++] = libxl_defbool_val(info->u.hvm.acpi) ? "1" : "0";
@@ -440,6 +440,9 @@ int libxl__domain_build(libxl__gc *gc,
         localents[i++] = libxl_defbool_val(info->u.hvm.acpi_s3) ? "1" : "0";
         localents[i++] = "platform/acpi_s4";
         localents[i++] = libxl_defbool_val(info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[i++] = "platform/acpi_stubdom_vtpm";
+        localents[i++] = (info->num_vtpms > 0) ? "1" : "0";
+
         if (info->u.hvm.mmio_hole_memkb) {
             uint64_t max_ram_below_4g =
                 (1ULL << 32) - (info->u.hvm.mmio_hole_memkb << 10);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ca3f724..b08b974 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -379,6 +379,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     # if you set device_model you must set device_model_version too
     ("device_model",     string),
     ("device_model_ssidref", uint32),
+    ("num_vtpms", integer),
     ("device_model_ssid_label", string),
 
     # extra parameters pass directly to qemu, NULL terminated
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..9c43e88 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1414,6 +1414,7 @@ static void parse_config_data(const char *config_source,
 
     if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
         d_config->num_vtpms = 0;
+        b_info->num_vtpms = 0;
         d_config->vtpms = NULL;
         while ((buf = xlu_cfg_get_listitem (vtpms, d_config->num_vtpms)) != NULL) {
             libxl_device_vtpm *vtpm;
@@ -1456,6 +1457,7 @@ static void parse_config_data(const char *config_source,
             }
             free(buf2);
             d_config->num_vtpms++;
+            b_info->num_vtpms++;
         }
     }
 
-- 
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 Dec 31 08:49:25 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 08: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 1Y6Exa-0007mS-K6; Wed, 31 Dec 2014 08:48:54 +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 1Y6ExY-0007mN-US
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 08:48:53 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	73/CA-31453-478B3A45; Wed, 31 Dec 2014 08:48:52 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1420015730!15735991!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14629 invoked from network); 31 Dec 2014 08:48:51 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-206.messagelabs.com with SMTP;
	31 Dec 2014 08:48:51 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by fmsmga102.fm.intel.com with ESMTP; 31 Dec 2014 00:48:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="506056757"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 31 Dec 2014 00:43:34 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 30 Dec 2014 23:44:54 -0500
Message-Id: <1420001094-23966-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 1/5] 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 extras/mini-os/include/tpmback.h |  3 +++
 extras/mini-os/tpmback.c         | 20 +++++++++++++++++---
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h
index 4408986..2618098 100644
--- a/extras/mini-os/include/tpmback.h
+++ b/extras/mini-os/include/tpmback.h
@@ -41,6 +41,9 @@
 #ifndef TPMBACK_H
 #define TPMBACK_H
 
+#define T_DOMAIN_TYPE_HVM 1
+#define T_DOMAIN_TYPE_PV  2
+
 struct tpmcmd {
    domid_t domid;		/* Domid of the frontend */
    uint8_t locality;    /* Locality requested by the frontend */
diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
index 00b66e8..d76e05e 100644
--- a/extras/mini-os/tpmback.c
+++ b/extras/mini-os/tpmback.c
@@ -555,7 +555,7 @@ int connect_fe(tpmif_t* tpmif)
 {
    char path[512];
    char* err, *value;
-   uint32_t domid;
+   uint32_t domid, domtype;
    grant_ref_t ringref;
    evtchn_port_t evtchn;
 
@@ -608,14 +608,28 @@ int connect_fe(tpmif_t* tpmif)
    }
    free(value);
 
-   domid = tpmif->domid;
+   /* get the domain type*/
+   snprintf(path, 512, "%s/domain-type", tpmif->fe_path);
+   if ((err = xenbus_read(XBT_NIL, path, &value))) {
+       TPMBACK_ERR("xenbus_read(%s) Error = %s", path, err);
+       free(err);
+       return -1;
+   }
+   if (sscanf(value, "%d", &domtype) != 1) {
+       TPMBACK_ERR("Non integer value (%s) \n", value);
+       free(value);
+       return -1;
+   }
+
+   printk("domtype = %d \n",domtype);
+   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
    if((tpmif->page = gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0, &ringref, PROT_READ | PROT_WRITE)) == NULL) {
       TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
       return -1;
    }
 
    /*Bind the event channel */
-   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn)))
+   if((evtchn_bind_interdomain(domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn)))
    {
       TPMBACK_ERR("%u/%u Unable to bind to interdomain event channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
       goto error_post_map;
-- 
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 Dec 31 08:49:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 08: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 1Y6EyA-0007sy-Be; Wed, 31 Dec 2014 08:49:30 +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 1Y6Ey9-0007sa-J2
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 08:49:29 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	B9/2D-02702-898B3A45; Wed, 31 Dec 2014 08:49:28 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1420015767!17919469!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 19500 invoked from network); 31 Dec 2014 08:49:27 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 08:49:27 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by orsmga102.jf.intel.com with ESMTP; 31 Dec 2014 00:47:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="435250373"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 31 Dec 2014 00:37:25 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 30 Dec 2014 23:45:31 -0500
Message-Id: <1420001131-24085-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 4/5] vTPM: add vTPM device 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

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 tools/libxl/libxl.c          | 62 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_create.c   |  6 +++++
 tools/libxl/libxl_dm.c       | 16 ++++++++++++
 tools/libxl/libxl_internal.h |  3 +++
 4 files changed, 87 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 18561fb..656d4b0 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2015,6 +2015,10 @@ void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
     flexarray_append(front, "handle");
     flexarray_append(front, GCSPRINTF("%d", vtpm->devid));
 
+    /*for para virtual machine*/
+    flexarray_append(front, "domain-type");
+    flexarray_append(front, GCSPRINTF("%d", LIBXL_DOMAIN_TYPE_PV));
+
     if (aodev->update_json) {
         lock = libxl__lock_domain_userdata(gc, domid);
         if (!lock) {
@@ -2073,6 +2077,64 @@ out:
     return;
 }
 
+void libxl__device_hvm_vtpm_add(libxl__gc *gc, uint32_t domid,
+                                libxl_device_vtpm *vtpm)
+{
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device *device;
+    unsigned int rc;
+
+    rc = libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
+
+    if (vtpm->devid == -1) {
+        if ((vtpm->devid = libxl__device_nextid(gc, domid, "vtpm")) < 0) {
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    GCNEW(device);
+    rc = libxl__device_from_vtpm(gc, domid, vtpm, device);
+    if ( rc != 0 ) goto out;
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, GCSPRINTF("%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, GCSPRINTF("%d", 1));
+    flexarray_append(back, "handle");
+    flexarray_append(back, GCSPRINTF("%d", vtpm->devid));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(vtpm->uuid)));
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, GCSPRINTF("%d", vtpm->backend_domid));
+    flexarray_append(front, "state");
+    flexarray_append(front, GCSPRINTF("%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, GCSPRINTF("%d", vtpm->devid));
+
+    flexarray_append(front, "domain-type");
+    flexarray_append(front, GCSPRINTF("%d", LIBXL_DOMAIN_TYPE_HVM));
+
+    libxl__device_generic_add(gc, XBT_NULL, device,
+                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                              libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                              NULL);
+
+    rc = 0;
+out:
+    return;
+}
+
 libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index c6f68fe..b2f61cb 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -901,6 +901,12 @@ static void initiate_domain_create(libxl__egc *egc,
             d_config->nics[i].devid = ++last_devid;
     }
 
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
+        d_config->num_vtpms > 0) {
+        ret = libxl__device_vtpm_setdefault(gc, d_config->vtpms);
+        if (ret) goto error_out;
+    }
+
     if (restore_fd >= 0) {
         LOG(DEBUG, "restoring, not running bootloader");
         domcreate_bootloader_done(egc, &dcs->bl, 0);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..337ac64 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -414,6 +414,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     const libxl_device_nic *nics = guest_config->nics;
     const int num_disks = guest_config->num_disks;
     const int num_nics = guest_config->num_nics;
+    const int num_vtpms = guest_config->num_vtpms;
     const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
     const libxl_sdl_info *sdl = dm_sdl(guest_config);
     const char *keymap = dm_keymap(guest_config);
@@ -747,6 +748,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
         abort();
     }
 
+    /*add vTPM parameters for HVM virtual machine*/
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        num_vtpms >0) {
+        flexarray_vappend(dm_args, "-tpmdev",
+                          "xenstubdoms,id=xenvtpm0", NULL);
+        flexarray_vappend(dm_args,"-device",
+                          "tpm-tis,tpmdev=xenvtpm0", NULL);
+    }
+
     ram_size = libxl__sizekb_to_mb(b_info->max_memkb - b_info->video_memkb);
     flexarray_append(dm_args, "-m");
     flexarray_append(dm_args, libxl__sprintf(gc, "%"PRId64, ram_size));
@@ -1412,6 +1422,12 @@ retry_transaction:
     spawn->failure_cb = device_model_startup_failed;
     spawn->detached_cb = device_model_detached;
 
+    /* Plug vtpm devices*/
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        guest_config->num_vtpms > 0){
+        libxl__device_hvm_vtpm_add(gc, domid, guest_config->vtpms);
+    }
+
     rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
         goto out_close;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..946b8cf 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2388,6 +2388,9 @@ _hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
                                    libxl_device_vtpm *vtpm,
                                    libxl__ao_device *aodev);
 
+void libxl__device_hvm_vtpm_add(libxl__gc *gc, uint32_t domid,
+                                libxl_device_vtpm *vtpm);
+
 /* Internal function to connect a vkb device */
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                                   libxl_device_vkb *vkb);
-- 
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 Dec 31 08:49:30 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 08: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 1Y6EyA-0007sy-Be; Wed, 31 Dec 2014 08:49:30 +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 1Y6Ey9-0007sa-J2
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 08:49:29 +0000
Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id
	B9/2D-02702-898B3A45; Wed, 31 Dec 2014 08:49:28 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1420015767!17919469!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 19500 invoked from network); 31 Dec 2014 08:49:27 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 08:49:27 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by orsmga102.jf.intel.com with ESMTP; 31 Dec 2014 00:47:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="435250373"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 31 Dec 2014 00:37:25 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 30 Dec 2014 23:45:31 -0500
Message-Id: <1420001131-24085-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 4/5] vTPM: add vTPM device 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

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 tools/libxl/libxl.c          | 62 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_create.c   |  6 +++++
 tools/libxl/libxl_dm.c       | 16 ++++++++++++
 tools/libxl/libxl_internal.h |  3 +++
 4 files changed, 87 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 18561fb..656d4b0 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2015,6 +2015,10 @@ void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
     flexarray_append(front, "handle");
     flexarray_append(front, GCSPRINTF("%d", vtpm->devid));
 
+    /*for para virtual machine*/
+    flexarray_append(front, "domain-type");
+    flexarray_append(front, GCSPRINTF("%d", LIBXL_DOMAIN_TYPE_PV));
+
     if (aodev->update_json) {
         lock = libxl__lock_domain_userdata(gc, domid);
         if (!lock) {
@@ -2073,6 +2077,64 @@ out:
     return;
 }
 
+void libxl__device_hvm_vtpm_add(libxl__gc *gc, uint32_t domid,
+                                libxl_device_vtpm *vtpm)
+{
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device *device;
+    unsigned int rc;
+
+    rc = libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
+
+    if (vtpm->devid == -1) {
+        if ((vtpm->devid = libxl__device_nextid(gc, domid, "vtpm")) < 0) {
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    GCNEW(device);
+    rc = libxl__device_from_vtpm(gc, domid, vtpm, device);
+    if ( rc != 0 ) goto out;
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, GCSPRINTF("%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, GCSPRINTF("%d", 1));
+    flexarray_append(back, "handle");
+    flexarray_append(back, GCSPRINTF("%d", vtpm->devid));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(vtpm->uuid)));
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, GCSPRINTF("%d", vtpm->backend_domid));
+    flexarray_append(front, "state");
+    flexarray_append(front, GCSPRINTF("%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, GCSPRINTF("%d", vtpm->devid));
+
+    flexarray_append(front, "domain-type");
+    flexarray_append(front, GCSPRINTF("%d", LIBXL_DOMAIN_TYPE_HVM));
+
+    libxl__device_generic_add(gc, XBT_NULL, device,
+                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                              libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                              NULL);
+
+    rc = 0;
+out:
+    return;
+}
+
 libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index c6f68fe..b2f61cb 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -901,6 +901,12 @@ static void initiate_domain_create(libxl__egc *egc,
             d_config->nics[i].devid = ++last_devid;
     }
 
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
+        d_config->num_vtpms > 0) {
+        ret = libxl__device_vtpm_setdefault(gc, d_config->vtpms);
+        if (ret) goto error_out;
+    }
+
     if (restore_fd >= 0) {
         LOG(DEBUG, "restoring, not running bootloader");
         domcreate_bootloader_done(egc, &dcs->bl, 0);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..337ac64 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -414,6 +414,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     const libxl_device_nic *nics = guest_config->nics;
     const int num_disks = guest_config->num_disks;
     const int num_nics = guest_config->num_nics;
+    const int num_vtpms = guest_config->num_vtpms;
     const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
     const libxl_sdl_info *sdl = dm_sdl(guest_config);
     const char *keymap = dm_keymap(guest_config);
@@ -747,6 +748,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
         abort();
     }
 
+    /*add vTPM parameters for HVM virtual machine*/
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        num_vtpms >0) {
+        flexarray_vappend(dm_args, "-tpmdev",
+                          "xenstubdoms,id=xenvtpm0", NULL);
+        flexarray_vappend(dm_args,"-device",
+                          "tpm-tis,tpmdev=xenvtpm0", NULL);
+    }
+
     ram_size = libxl__sizekb_to_mb(b_info->max_memkb - b_info->video_memkb);
     flexarray_append(dm_args, "-m");
     flexarray_append(dm_args, libxl__sprintf(gc, "%"PRId64, ram_size));
@@ -1412,6 +1422,12 @@ retry_transaction:
     spawn->failure_cb = device_model_startup_failed;
     spawn->detached_cb = device_model_detached;
 
+    /* Plug vtpm devices*/
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        guest_config->num_vtpms > 0){
+        libxl__device_hvm_vtpm_add(gc, domid, guest_config->vtpms);
+    }
+
     rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
         goto out_close;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..946b8cf 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2388,6 +2388,9 @@ _hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
                                    libxl_device_vtpm *vtpm,
                                    libxl__ao_device *aodev);
 
+void libxl__device_hvm_vtpm_add(libxl__gc *gc, uint32_t domid,
+                                libxl_device_vtpm *vtpm);
+
 /* Internal function to connect a vkb device */
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                                   libxl_device_vkb *vkb);
-- 
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 Dec 31 08:49:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 08:49:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6EyF-0007vN-PD; Wed, 31 Dec 2014 08:49: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 1Y6EyE-0007uj-Q9
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 08:49:34 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	C3/E7-02712-E98B3A45; Wed, 31 Dec 2014 08:49:34 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1420015767!17919469!2
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 19992 invoked from network); 31 Dec 2014 08:49:31 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 08:49:31 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 31 Dec 2014 00:47:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="631115849"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 31 Dec 2014 00:49:30 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 30 Dec 2014 23:45:39 -0500
Message-Id: <1420001139-24124-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: wei.liu2@citrix.com, Quan Xu <quan.xu@intel.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 5/5] vTPM: add QEMU_STUBDOM_VTPM compile
	option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 Config.mk      | 4 ++++
 tools/Makefile | 7 +++++++
 2 files changed, 11 insertions(+)

diff --git a/Config.mk b/Config.mk
index a5b6c41..5a5f413 100644
--- a/Config.mk
+++ b/Config.mk
@@ -254,6 +254,10 @@ endif
 OVMF_UPSTREAM_REVISION ?= 447d264115c476142f884af0be287622cd244423
 QEMU_UPSTREAM_REVISION ?= qemu-xen-4.5.0-rc1
 SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5
+
+# Qemu stubdom vtpm frontend.
+QEMU_STUBDOM_VTPM ?= n
+
 # Thu May 22 16:59:16 2014 -0400
 # python3 fixes for vgabios and csm builds.
 
diff --git a/tools/Makefile b/tools/Makefile
index af9798a..1044149 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -197,6 +197,12 @@ else
 QEMU_XEN_ENABLE_DEBUG :=
 endif
 
+ifeq ($(QEMU_STUBDOM_VTPM),y)
+QEMU_TPM_ARGS="--enable-tpm"
+else
+QEMU_TPM_ARGS="--disable-tpm"
+endif
+
 subdir-all-qemu-xen-dir: qemu-xen-dir-find
 	if test -d $(QEMU_UPSTREAM_LOC) ; then \
 		source=$(QEMU_UPSTREAM_LOC); \
@@ -222,6 +228,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
 		--datadir=$(SHAREDIR)/qemu-xen \
 		--localstatedir=$(localstatedir) \
 		--disable-kvm \
+                $(QEMU_TPM_ARGS) \
 		--disable-docs \
 		--disable-guest-agent \
 		--python=$(PYTHON) \
-- 
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 Dec 31 08:49:36 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 08:49:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6EyF-0007vN-PD; Wed, 31 Dec 2014 08:49: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 1Y6EyE-0007uj-Q9
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 08:49:34 +0000
Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id
	C3/E7-02712-E98B3A45; Wed, 31 Dec 2014 08:49:34 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1420015767!17919469!2
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 19992 invoked from network); 31 Dec 2014 08:49:31 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-27.messagelabs.com with SMTP;
	31 Dec 2014 08:49:31 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 31 Dec 2014 00:47:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="631115849"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 31 Dec 2014 00:49:30 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Tue, 30 Dec 2014 23:45:39 -0500
Message-Id: <1420001139-24124-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: wei.liu2@citrix.com, Quan Xu <quan.xu@intel.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2 5/5] vTPM: add QEMU_STUBDOM_VTPM compile
	option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 Config.mk      | 4 ++++
 tools/Makefile | 7 +++++++
 2 files changed, 11 insertions(+)

diff --git a/Config.mk b/Config.mk
index a5b6c41..5a5f413 100644
--- a/Config.mk
+++ b/Config.mk
@@ -254,6 +254,10 @@ endif
 OVMF_UPSTREAM_REVISION ?= 447d264115c476142f884af0be287622cd244423
 QEMU_UPSTREAM_REVISION ?= qemu-xen-4.5.0-rc1
 SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5
+
+# Qemu stubdom vtpm frontend.
+QEMU_STUBDOM_VTPM ?= n
+
 # Thu May 22 16:59:16 2014 -0400
 # python3 fixes for vgabios and csm builds.
 
diff --git a/tools/Makefile b/tools/Makefile
index af9798a..1044149 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -197,6 +197,12 @@ else
 QEMU_XEN_ENABLE_DEBUG :=
 endif
 
+ifeq ($(QEMU_STUBDOM_VTPM),y)
+QEMU_TPM_ARGS="--enable-tpm"
+else
+QEMU_TPM_ARGS="--disable-tpm"
+endif
+
 subdir-all-qemu-xen-dir: qemu-xen-dir-find
 	if test -d $(QEMU_UPSTREAM_LOC) ; then \
 		source=$(QEMU_UPSTREAM_LOC); \
@@ -222,6 +228,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
 		--datadir=$(SHAREDIR)/qemu-xen \
 		--localstatedir=$(localstatedir) \
 		--disable-kvm \
+                $(QEMU_TPM_ARGS) \
 		--disable-docs \
 		--disable-guest-agent \
 		--python=$(PYTHON) \
-- 
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 Dec 31 09:01:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:01:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6F9n-0000Iu-2O; Wed, 31 Dec 2014 09:01: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 1Y6F9l-0000Ip-0c
	for xen-devel@lists.xensource.com; Wed, 31 Dec 2014 09:01:29 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	1C/D0-20609-86BB3A45; Wed, 31 Dec 2014 09:01:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1420016486!17873051!1
X-Originating-IP: [66.165.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 28411 invoked from network); 31 Dec 2014 09:01:27 -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;
	31 Dec 2014 09:01:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,671,1413244800"; d="scan'208";a="209536208"
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.210.2; Wed, 31 Dec 2014 04:01: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 1Y6F9g-0003wK-QZ;
	Wed, 31 Dec 2014 09:01:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y6F9g-0008VR-Ig;
	Wed, 31 Dec 2014 09:01:24 +0000
Date: Wed, 31 Dec 2014 09:01:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32867-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] 32867: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32867 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32867/

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-sedf     11 guest-saverestore           fail pass in 32834

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-amd64-xl-qemuu-debianhvm-amd64 5 xen-boot fail in 32834 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     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-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-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 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-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                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 31 09:01:49 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:01:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6F9n-0000Iu-2O; Wed, 31 Dec 2014 09:01: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 1Y6F9l-0000Ip-0c
	for xen-devel@lists.xensource.com; Wed, 31 Dec 2014 09:01:29 +0000
Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id
	1C/D0-20609-86BB3A45; Wed, 31 Dec 2014 09:01:28 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1420016486!17873051!1
X-Originating-IP: [66.165.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 28411 invoked from network); 31 Dec 2014 09:01:27 -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;
	31 Dec 2014 09:01:27 -0000
X-IronPort-AV: E=Sophos;i="5.07,671,1413244800"; d="scan'208";a="209536208"
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.210.2; Wed, 31 Dec 2014 04:01: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 1Y6F9g-0003wK-QZ;
	Wed, 31 Dec 2014 09:01:24 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y6F9g-0008VR-Ig;
	Wed, 31 Dec 2014 09:01:24 +0000
Date: Wed, 31 Dec 2014 09:01:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32867-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] 32867: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32867 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32867/

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-sedf     11 guest-saverestore           fail pass in 32834

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-amd64-xl-qemuu-debianhvm-amd64 5 xen-boot fail in 32834 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     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-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-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 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-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                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 31 09:03:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09: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 1Y6FBZ-0000WA-Jj; Wed, 31 Dec 2014 09:03:21 +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 1Y6FBY-0000W3-B3
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:03:20 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	8A/F3-25547-7DBB3A45; Wed, 31 Dec 2014 09:03:19 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-12.tower-31.messagelabs.com!1420016597!16484658!1
X-Originating-IP: [74.125.82.177]
X-SpamReason: No, hits=1.7 required=7.0 tests=BIZ_TLD,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19327 invoked from network); 31 Dec 2014 09:03:17 -0000
Received: from mail-we0-f177.google.com (HELO mail-we0-f177.google.com)
	(74.125.82.177)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2014 09:03:17 -0000
Received: by mail-we0-f177.google.com with SMTP id q59so2089394wes.22
	for <xen-devel@lists.xen.org>; Wed, 31 Dec 2014 01:03: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=nwziZeEgaquaJv3ktCgDiQPN1e/M0vtMHEAoz6RcGEM=;
	b=ccsKlW8Is7tDOo0Q69LnoAKW/xTZXTZmZbT8AA+sH3F9fFEYVNX5pPQGiYroUGka5/
	yqA1qG1WDe4QlC62F4psDKhFx/FxjuHtYscWpQiAlstHpNk1rbqGVw1VwZ71fZgw98KM
	8+k3t/6BVUYULTMizBNgS84Yxbt4Oc052T8CNHMM105Bocdwelikl1LCgmM1e+S0a159
	gt6iTfGI18n03AgNrcFxJ7GfWj5fMdkYgsWAdbFryeZB4TXqZw6icB1RGlIEbDsLq7tp
	rZkWR+0dYRcFrOO6utp27lpNE0/cGm7UpTL/3MfeschqBKujdwE5LEjDtWMqs9d5RkfI
	uWDg==
X-Gm-Message-State: ALoCoQmgI3Xnl+0j5EWDk455Zbn2FQzRexAItYJ5stLeAD8mHpq/CJ1Aq7CivUmXww1lJXWLLDLT
X-Received: by 10.180.75.199 with SMTP id e7mr114804905wiw.21.1420016597498;
	Wed, 31 Dec 2014 01:03:17 -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 i3sm45627401wie.23.2014.12.31.01.03.15
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 31 Dec 2014 01:03:16 -0800 (PST)
Message-ID: <54A3BBD7.1050004@m2r.biz>
Date: Wed, 31 Dec 2014 10:03:19 +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.3.0
MIME-Version: 1.0
To: Goonie Windy <monsieur.goonie@gmail.com>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>	<549EBDCC.3090102@m2r.biz>	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>	<CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>	<CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>	<CAE5x5YU8R9PibP-_xj+uYNc_rqOL0rnuHvVF5Ymz32RngDEgFw@mail.gmail.com>	<CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com>	<54A15BFA.4050001@m2r.biz>
	<CAE5x5YWRJaF1XZ0masWn0uotUQghW0irM=NmU9XB0Dc8_XUFJw@mail.gmail.com>
In-Reply-To: <CAE5x5YWRJaF1XZ0masWn0uotUQghW0irM=NmU9XB0Dc8_XUFJw@mail.gmail.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8589351904436073324=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8589351904436073324==
Content-Type: multipart/alternative;
 boundary="------------080006000500080704020405"

This is a multi-part message in MIME format.
--------------080006000500080704020405
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Il 31/12/2014 02:26, Goonie Windy ha scritto:
> Ok Fabio, thanks to your configure, some bits of hacking the install 
> part and lots of advises/support/encouragements ;) from Mark Pryor I 
> ended up
>  installing 4.5RC4 with QXL support on Deb8 unstable.
>
>
> So now what do you want me to test fabio?
> I have win7 x64 / win 2k8R2 vms in test mode ready to install drvers.
>
> the numerous troubles I went through are related in the IRCcopy attached.
> I actually couldn't build rombios and used seabios provided by the 
> system -like you-
> I should try to compile/find latest qxl now.

rombios is used only by qemu traditional that is very old, without spice 
support and hvm domUs have lower performance with it.
qxl drivers in latest spice guest tools are signed and not require 
windows testsigning mode, same for james haper xen gplpv.
If you want test new winpv drivers instead you need it.

For me qxl is working good on w7 domUs except after save/restore when 
"freeze" 2-3 minutes on screen resolution change and I not found the 
exact problem for now.
I also not found how to have qxl working in linux domUs, on latest test 
xorg crash on start with qxl driver installed.
Probably other changes are needed in hvmloader and/or xen hypervisor 
and/or qxl driver.
Any help testing it is appreciated.

>
> See you in 2K15.
>
> greg B
>
> 2014-12-29 14:49 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz 
> <mailto:fabio.fantoni@m2r.biz>>:
>
>     Il 29/12/2014 14:13, Goonie Windy ha scritto:
>>     ok, I'm trying to patch the files with yours,
>>
>>
>>     I need to do it manually right?
>>
>>     git apply is not working here.
>
>     If the patch need a "refresh" the conflict should be solved manually.
>     Taking the patch updated from here probably it can be applied to
>     latest 4.5-rc:
>     https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>
>>
>>
>>     regards
>>
>>     greg
>>
>>     2014-12-29 13:46 GMT+01:00 Goonie Windy
>>     <monsieur.goonie@gmail.com <mailto:monsieur.goonie@gmail.com>>:
>>
>>         There is an error in pageqs describing how to compile from
>>         sources as in 4.5
>>
>>         cat .config
>>         PYTHON_PREFIX_ARG=--install-layout=deb
>>
>>         is in fact in .INSTALL
>>
>
>     If also you use debian you can use make debball that is better for
>     install/remove easy and fast test build.
>
>     And for example I use this configure options with xen 4.5:
>     ./configure --prefix=/usr --disable-blktap1
>     --disable-qemu-traditional --disable-rombios
>     --with-system-seabios=/usr/share/seabios/bios-256k.bin
>     --with-extra-qemuu-configure-args="--enable-spice
>     --enable-usb-redir" --disable-blktap2
>     I use wheezy building updated packages from sid: seabios 1.7.5-1,
>     spice 0.12.5-1, spice-protocol 0.12.7-1 and usbredir 0.7-1.
>     If you use jessie instead you have all packages updated.
>
>     About python I'm using this workaround (before execute configure)
>     even if probably is not the best:
>     Config.mk
>     -PYTHON_PREFIX_ARG ?=--prefix="$(PREFIX)"
>     +PYTHON_PREFIX_ARG ?=
>
>
>>
>>
>>         2014-12-29 1:20 GMT+01:00 Goonie Windy
>>         <monsieur.goonie@gmail.com <mailto:monsieur.goonie@gmail.com>>:
>>
>>             well figured out it is because you have to "enforce"
>>             locale:  export LC_ALL=en_US.utf-8 if keyboard mapping is
>>             else
>>
>>             2014-12-28 21:19 GMT+01:00 Goonie Windy
>>             <monsieur.goonie@gmail.com
>>             <mailto:monsieur.goonie@gmail.com>>:
>>
>>                 Trying to compile xen 4.5RC4 in order to test your
>>                 patch I end up with  these errors compiling the
>>                 Seabios directories,
>>
>>                 any idea?
>>
>>                   Compiling to assembler out/src/asm-offsets.s
>>                   Generating offset file out/asm-offsets.h
>>                   Compiling (16bit) out/romlayout.o
>>                   Building ld scripts
>>                 Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
>>                 Traceback (most recent call last):
>>                   File "./scripts/layoutrom.py", line 709, in <module>
>>                     main()
>>                   File "./scripts/layoutrom.py", line 671, in main
>>                     info16 = parseObjDump(infile16, '16')
>>                   File "./scripts/layoutrom.py", line 586, in
>>                 parseObjDump
>>                     relocsection = sectionmap[sectionname]
>>                 KeyError:
>>                 '.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
>>                 Makefile:155: recipe for target 'out/romlayout16.lds'
>>                 failed
>>                 make[6]: *** [out/romlayout16.lds] Error 1
>>                 make[6]: Leaving directory
>>                 '/home/goon/xen/tools/firmware/seabios-dir-remote'
>>                 /home/goon/xen/tools/firmware/../../tools/Rules.mk:116:
>>                 recipe for target 'subdir-all-seabios-dir' failed
>>
>>
>>
>>                 2014-12-27 17:35 GMT+01:00 Goonie Windy
>>                 <monsieur.goonie@gmail.com
>>                 <mailto:monsieur.goonie@gmail.com>>:
>>
>>                     Hello Fabio,
>>
>>                     Sure thing I will help debug the win7 and the
>>                     win8 versions.
>>                     Where to start?
>>
>>                     I'll try to see if I can patch with patch from
>>                     https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>                     and if not will post result.
>>
>>
>>                     best regards,
>>
>>
>>                     greg Bahde
>>
>>                     2014-12-27 15:10 GMT+01:00 Fabio Fantoni
>>                     <fabio.fantoni@m2r.biz
>>                     <mailto:fabio.fantoni@m2r.biz>>:
>>
>>
>>                         Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>>                         I tried to install Qxl drivers under
>>>                         win7/win 2k8/win8.1 all       x64 versions,
>>>                         without any luck.
>>>
>>>
>>>                         admin message is as follow:
>>>                         Driver Management concluded the process to
>>>                         install driver FileRepository\qxl.inf_amd64_
>>>                         neutral_f0c429882d5c81ed\qxl.inf for Device
>>>                         Instance ID
>>>                         PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28
>>>                         with the following status: 0xe000022d.
>>>
>>>
>>>
>>>
>>>                         Does
>>>                         http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>>
>>>                         can it be installed on my xen stack?
>>
>>                         Yes but probably require a small refresh, I
>>                         always posted the patch based on updated
>>                         xen-unstable.
>>
>>                         Here qxl patch refreshed for xen 4.5 if needed:
>>                         https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>
>>                         Here the latest spice guest tools for windows
>>                         with qxl driver included:
>>                         http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>>
>>                         Windows >=8 and similar require a new qxl
>>                         drivers, there are a beta build but latest
>>                         tried some months ago have serious bug and I
>>                         not found recent build full working on windows 8.
>>
>>                         On xen windows 7 domUs qxl works good except
>>                         a problem after save/restore and on linux
>>                         domUs is not working, for now I not found
>>                         exactly cause and solution.
>>                         On mailing list up to 2 years ago you can
>>                         find many my mails about.
>>                         Any help to test it is appreciated.
>>
>>                         Sorry for my bad english.
>>
>>>
>>>                         Also, can  I get invited at xendevel irc ?
>>>                         regards
>>>
>>>                         Greg
>>>
>>>
>>>                         _______________________________________________
>>>                         Xen-devel mailing list
>>>                         Xen-devel@lists.xen.org  <mailto:Xen-devel@lists.xen.org>
>>>                         http://lists.xen.org/xen-devel
>>
>>
>>
>>
>>
>>
>
>


--------------080006000500080704020405
Content-Type: text/html; charset=utf-8
Content-Length: 32279
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">Il 31/12/2014 02:26, Goonie Windy ha
      scritto:<br>
    </div>
    <blockquote
cite=3D"mid:CAE5x5YWRJaF1XZ0masWn0uotUQghW0irM=3DNmU9XB0Dc8_XUFJw@mail.gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>Ok Fabio, thanks to your configure, some bits of hacking
            the install part and lots of advises/support/encouragements
            ;) from Mark Pryor I ended up<br>
          </div>
          =C2=A0installing 4.5RC4 with QXL support on Deb8 unstable.<br>
          <br>
          <br>
        </div>
        <div>So now what do you want me to test fabio=3F<br>
        </div>
        <div>I have win7 x64 / win 2k8R2 vms in test mode ready to
          install drvers.<br>
        </div>
        <div><br>
        </div>
        <div>the numerous troubles I went through are related in the
          IRCcopy attached.<br>
        </div>
        <div>I actually couldn't build rombios and used seabios provided
          by the system -like you-<br>
        </div>
        <div>I should try to compile/find latest qxl now.<br>
        </div>
      </div>
    </blockquote>
    <br>
    rombios is used only by qemu traditional that is very old, without
    spice support and hvm domUs have lower performance with it.<br>
    qxl drivers in latest spice guest tools are signed and not require
    windows testsigning mode, same for james haper xen gplpv.<br>
    If you want test new winpv drivers instead you need it.<br>
    <br>
    For me qxl is working good on w7 domUs except after save/restore
    when "freeze" 2-3 minutes on screen resolution change and I not
    found the exact problem for now.<br>
    I also not found how to have qxl working in linux domUs, on latest
    test xorg crash on start with qxl driver installed.<br>
    Probably other changes are needed in hvmloader and/or xen hypervisor
    and/or qxl driver.<br>
    Any help testing it is appreciated.<br>
    <br>
    <blockquote
cite=3D"mid:CAE5x5YWRJaF1XZ0masWn0uotUQghW0irM=3DNmU9XB0Dc8_XUFJw@mail.gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>See you in 2K15.<br>
          <br>
        </div>
        <div>greg B<br>
        </div>
      </div>
      <div class=3D"gmail_extra"><br>
        <div class=3D"gmail_quote">2014-12-29 14:49 GMT+01:00 Fabio
          Fantoni <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
              href=3D"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">fabio.fantoni@m2r.biz</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">
              <div>Il 29/12/2014 14:13, Goonie Windy ha scritto:<br>
              </div>
              <span class=3D"">
                <blockquote type=3D"cite">
                  <div dir=3D"ltr">
                    <div>
                      <div>
                        <div>ok, I'm trying to patch the files with
                          yours,<br>
                          <br>
                          <br>
                        </div>
                        I need to do it manually right=3F <br>
                        <br>
                        git apply is not working here. <br>
                      </div>
                    </div>
                  </div>
                </blockquote>
                <br>
              </span> If the patch need a "refresh" the conflict should
              be solved manually.<br>
              Taking the patch updated from here probably it can be
              applied to latest 4.5-rc:<br>
              <a moz-do-not-send=3D"true"
                href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging"
                target=3D"_blank">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a><span
                class=3D""><br>
                <br>
                <blockquote type=3D"cite">
                  <div dir=3D"ltr">
                    <div>
                      <div><br>
                        <br>
                      </div>
                      regards<br>
                      <br>
                    </div>
                    greg<br>
                  </div>
                  <div class=3D"gmail_extra"><br>
                    <div class=3D"gmail_quote">2014-12-29 13:46 GMT+01:00
                      Goonie Windy <span dir=3D"ltr">&lt;<a
                          moz-do-not-send=3D"true"
                          href=3D"mailto:monsieur.goonie@gmail.com"
                          target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">There is an error in pageqs
                          describing how to compile from sources as in
                          4.5 <br>
                          <pre>cat .config
PYTHON_PREFIX_ARG=3D--install-layout=3Ddeb

</pre>
                          <pre>is in fact in .INSTALL
</pre>
                        </div>
                      </blockquote>
                    </div>
                  </div>
                </blockquote>
                <br>
              </span> If also you use debian you can use make debball
              that is better for install/remove easy and fast test
              build.<br>
              <br>
              And for example I use this configure options with xen 4.5:<br>
              ./configure --prefix=3D/usr --disable-blktap1
              --disable-qemu-traditional --disable-rombios
              --with-system-seabios=3D/usr/share/seabios/bios-256k.bin
              --with-extra-qemuu-configure-args=3D"--enable-spice
              --enable-usb-redir" --disable-blktap2<br>
              I use wheezy building updated packages from sid: seabios
              1.7.5-1, spice 0.12.5-1, spice-protocol 0.12.7-1 and
              usbredir 0.7-1.<br>
              If you use jessie instead you have all packages updated.<br>
              <br>
              About python I'm using this workaround (before execute
              configure) even if probably is not the best:<br>
              <span title=3D"Config.mk">Config.mk</span><br>
              -<span>PYTHON_PREFIX_ARG</span> =3F=3D<span> --prefix=3D"</span><span><span>$(</span><span>PREFIX</span><span>)</span></span><span>"</span><br>
              +<span>PYTHON_PREFIX_ARG</span> =3F=3D
              <div>
                <div class=3D"h5"><br>
                  <br>
                  <blockquote type=3D"cite">
                    <div class=3D"gmail_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">
                          <div dir=3D"ltr"><br>
                          </div>
                          <div>
                            <div>
                              <div class=3D"gmail_extra"><br>
                                <div class=3D"gmail_quote">2014-12-29 1:20
                                  GMT+01:00 Goonie Windy <span
                                    dir=3D"ltr">&lt;<a
                                      moz-do-not-send=3D"true"
                                      href=3D"mailto:monsieur.goonie@gmail.com"
                                      target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                                      <div>well figured out it is
                                        because you have to "enforce"
                                        locale:=C2=A0 export
                                        LC_ALL=3Den_US.utf-8 if keyboard
                                        mapping is else<br>
                                      </div>
                                    </div>
                                    <div>
                                      <div>
                                        <div class=3D"gmail_extra"><br>
                                          <div class=3D"gmail_quote">2014-12-28
                                            21:19 GMT+01:00 Goonie Windy
                                            <span dir=3D"ltr">&lt;<a
                                                moz-do-not-send=3D"true"
                                                href=3D"mailto:monsieur.goonie@gmail.com"
                                                target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                                                <div>Trying to compile
                                                  xen 4.5RC4 in order to
                                                  test your patch I end
                                                  up with=C2=A0 these errors
                                                  compiling the Seabios
                                                  directories,<br>
                                                  <br>
                                                </div>
                                                any idea=3F<br>
                                                <br>
                                                =C2=A0 Compiling to assembler
                                                out/src/asm-offsets.s<br>
                                                =C2=A0 Generating offset file
                                                out/asm-offsets.h<br>
                                                =C2=A0 Compiling (16bit)
                                                out/romlayout.o<br>
                                                =C2=A0 Building ld scripts<br>
                                                Version:
                                                rel-1.7.5-0-ge51488c-20141228_210340-E766<br>
                                                Traceback (most recent
                                                call last):<br>
                                                =C2=A0 File
                                                "./scripts/layoutrom.py",
                                                line 709, in
                                                &lt;module&gt;<br>
                                                =C2=A0=C2=A0=C2=A0 main()<br>
                                                =C2=A0 File
                                                "./scripts/layoutrom.py",
                                                line 671, in main<br>
                                                =C2=A0=C2=A0=C2=A0 info16 =3D
                                                parseObjDump(infile16,
                                                '16')<br>
                                                =C2=A0 File
                                                "./scripts/layoutrom.py",
                                                line 586, in
                                                parseObjDump<br>
                                                =C2=A0=C2=A0=C2=A0 relocsection =3D
                                                sectionmap[sectionname]<br>
                                                KeyError:
'.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'<br>
                                                Makefile:155: recipe for
                                                target
                                                'out/romlayout16.lds'
                                                failed<br>
                                                make[6]: ***
                                                [out/romlayout16.lds]
                                                Error 1<br>
                                                make[6]: Leaving
                                                directory
                                                '/home/goon/xen/tools/firmware/seabios-dir-remote'<br>
                                                /home/goon/xen/tools/firmware/../../tools/Rules.mk:116:

                                                recipe for target
                                                'subdir-all-seabios-dir'
                                                failed<br>
                                                <br>
                                                <br>
                                              </div>
                                              <div>
                                                <div>
                                                  <div
                                                    class=3D"gmail_extra"><br>
                                                    <div
                                                      class=3D"gmail_quote">2014-12-27

                                                      17:35 GMT+01:00
                                                      Goonie Windy <span
                                                        dir=3D"ltr">&lt;<a
moz-do-not-send=3D"true" href=3D"mailto:monsieur.goonie@gmail.com"
                                                          target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                                                          <div>
                                                          <div>
                                                          <div>Hello
                                                          Fabio,<br>
                                                          <br>
                                                          Sure thing I
                                                          will help
                                                          debug the win7
                                                          and the win8
                                                          versions.<br>
                                                          </div>
                                                          Where to
                                                          start=3F<br>
                                                          <br>
                                                          </div>
                                                          I'll try to
                                                          see if I can
                                                          patch with
                                                          patch from <a
moz-do-not-send=3D"true"
href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe"
target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a>
                                                          and if not
                                                          will post
                                                          result.<br>
                                                          <br>
                                                          <br>
                                                          best regards,<br>
                                                          <br>
                                                          <br>
                                                          </div>
                                                          greg Bahde<br>
                                                        </div>
                                                        <div>
                                                          <div>
                                                          <div
                                                          class=3D"gmail_extra"><br>
                                                          <div
                                                          class=3D"gmail_quote">2014-12-27

                                                          15:10
                                                          GMT+01:00
                                                          Fabio Fantoni
                                                          <span
                                                          dir=3D"ltr">&lt;<a
moz-do-not-send=3D"true" href=3D"mailto:fabio.fantoni@m2r.biz"
                                                          target=3D"_blank">fabio.fantoni@m2r.biz</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">
                                                          <br>
                                                          <div>Il
                                                          27/12/2014
                                                          02:15, Goonie
                                                          Windy ha
                                                          scritto:<br>
                                                          </div>
                                                          <span>
                                                          <blockquote
                                                          type=3D"cite">
                                                          <div dir=3D"ltr">
                                                          <div>
                                                          <div>
                                                          <div>I tried
                                                          to install Qxl
                                                          drivers under
                                                          win7/win
                                                          2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          all=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64
                                                          versions,
                                                          without any
                                                          luck.<br>
                                                          <br>
                                                          <br>
                                                          admin message
                                                          is as follow:<br>
                                                          Driver
                                                          Management
                                                          concluded the
                                                          process to
                                                          install driver
                                                          FileRepository\qxl.inf_amd64_


                                                          <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf

                                                          for Device
                                                          Instance ID
                                                          PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&amp;267A616A&amp;1&amp;28


                                                          with the
                                                          following
                                                          status:
                                                          0xe000022d.</div>
                                                          <br>
                                                          <br>
                                                          <br>
                                                          <br>
                                                          </div>
                                                          Does <br>
                                                          <a
                                                          moz-do-not-send=3D"true"
href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html"
target=3D"_blank">http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html</a><br>
                                                          <br>
                                                          </div>
                                                          can it be
                                                          installed on
                                                          my xen stack=3F
                                                          <br>
                                                          </div>
                                                          </div>
                                                          </blockquote>
                                                          <br>
                                                          </span> Yes
                                                          but probably
                                                          require a
                                                          small refresh,
                                                          I always
                                                          posted the
                                                          patch based on
                                                          updated
                                                          xen-unstable.
                                                          <br>
                                                          <br>
                                                          Here qxl patch
                                                          refreshed for
                                                          xen 4.5 if
                                                          needed:<br>
                                                          <a
                                                          moz-do-not-send=3D"true"
href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe"
target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
                                                          <br>
                                                          Here the
                                                          latest spice
                                                          guest tools
                                                          for windows
                                                          with qxl
                                                          driver
                                                          included:<br>
                                                          <a
                                                          moz-do-not-send=3D"true"
href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe"
target=3D"_blank">http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
                                                          <br>
                                                          Windows &gt;=3D8
                                                          and similar
                                                          require a new
                                                          qxl drivers,
                                                          there are a
                                                          beta build but
                                                          latest tried
                                                          some months
                                                          ago have
                                                          serious bug
                                                          and I not
                                                          found recent
                                                          build full
                                                          working on
                                                          windows 8.<br>
                                                          <br>
                                                          On xen windows
                                                          7 domUs qxl
                                                          works good
                                                          except a
                                                          problem after
                                                          save/restore
                                                          and on linux
                                                          domUs is not
                                                          working, for
                                                          now I not
                                                          found exactly
                                                          cause and
                                                          solution.<br>
                                                          On mailing
                                                          list up to 2
                                                          years ago you
                                                          can find many
                                                          my mails
                                                          about.<br>
                                                          Any help to
                                                          test it is
                                                          appreciated.<br>
                                                          <br>
                                                          Sorry for my
                                                          bad english.<br>
                                                          <br>
                                                          <blockquote
                                                          type=3D"cite"><span>
                                                          <div dir=3D"ltr">
                                                          <div><br>
                                                          Also, can=C2=A0 I
                                                          get invited at
                                                          xendevel irc =3F<br>
                                                          regards<br>
                                                          <br>
                                                          </div>
                                                          Greg <br>
                                                          </div>
                                                          <br>
                                                          <fieldset></fieldset>
                                                          <br>
                                                          </span>
                                                          <pre>_______________________________________________
Xen-devel mailing list
<a moz-do-not-send=3D"true" href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@lists.xen.org</a>
<a moz-do-not-send=3D"true" href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.xen.org/xen-devel</a>
</pre>
                                                          </blockquote>
                                                          <br>
                                                          </div>
                                                          </blockquote>
                                                          </div>
                                                          <br>
                                                          </div>
                                                          </div>
                                                        </div>
                                                      </blockquote>
                                                    </div>
                                                    <br>
                                                  </div>
                                                </div>
                                              </div>
                                            </blockquote>
                                          </div>
                                          <br>
                                        </div>
                                      </div>
                                    </div>
                                  </blockquote>
                                </div>
                                <br>
                              </div>
                            </div>
                          </div>
                        </blockquote>
                      </div>
                      <br>
                    </div>
                  </blockquote>
                  <br>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------080006000500080704020405--


--===============8589351904436073324==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8589351904436073324==--


From xen-devel-bounces@lists.xen.org Wed Dec 31 09:03:23 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09: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 1Y6FBZ-0000WA-Jj; Wed, 31 Dec 2014 09:03:21 +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 1Y6FBY-0000W3-B3
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:03:20 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	8A/F3-25547-7DBB3A45; Wed, 31 Dec 2014 09:03:19 +0000
X-Env-Sender: fabio.fantoni@m2r.biz
X-Msg-Ref: server-12.tower-31.messagelabs.com!1420016597!16484658!1
X-Originating-IP: [74.125.82.177]
X-SpamReason: No, hits=1.7 required=7.0 tests=BIZ_TLD,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19327 invoked from network); 31 Dec 2014 09:03:17 -0000
Received: from mail-we0-f177.google.com (HELO mail-we0-f177.google.com)
	(74.125.82.177)
	by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2014 09:03:17 -0000
Received: by mail-we0-f177.google.com with SMTP id q59so2089394wes.22
	for <xen-devel@lists.xen.org>; Wed, 31 Dec 2014 01:03: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=nwziZeEgaquaJv3ktCgDiQPN1e/M0vtMHEAoz6RcGEM=;
	b=ccsKlW8Is7tDOo0Q69LnoAKW/xTZXTZmZbT8AA+sH3F9fFEYVNX5pPQGiYroUGka5/
	yqA1qG1WDe4QlC62F4psDKhFx/FxjuHtYscWpQiAlstHpNk1rbqGVw1VwZ71fZgw98KM
	8+k3t/6BVUYULTMizBNgS84Yxbt4Oc052T8CNHMM105Bocdwelikl1LCgmM1e+S0a159
	gt6iTfGI18n03AgNrcFxJ7GfWj5fMdkYgsWAdbFryeZB4TXqZw6icB1RGlIEbDsLq7tp
	rZkWR+0dYRcFrOO6utp27lpNE0/cGm7UpTL/3MfeschqBKujdwE5LEjDtWMqs9d5RkfI
	uWDg==
X-Gm-Message-State: ALoCoQmgI3Xnl+0j5EWDk455Zbn2FQzRexAItYJ5stLeAD8mHpq/CJ1Aq7CivUmXww1lJXWLLDLT
X-Received: by 10.180.75.199 with SMTP id e7mr114804905wiw.21.1420016597498;
	Wed, 31 Dec 2014 01:03:17 -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 i3sm45627401wie.23.2014.12.31.01.03.15
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 31 Dec 2014 01:03:16 -0800 (PST)
Message-ID: <54A3BBD7.1050004@m2r.biz>
Date: Wed, 31 Dec 2014 10:03:19 +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.3.0
MIME-Version: 1.0
To: Goonie Windy <monsieur.goonie@gmail.com>
References: <CAE5x5YU4qBTxp+36FioAROdTOPgrU79MN3s+BkmPTWq+qsVt6w@mail.gmail.com>	<549EBDCC.3090102@m2r.biz>	<CAE5x5YWHej8X4u-ChWPP_8f-bs=7gETukwgKbpEWqv7nfyw2Wg@mail.gmail.com>	<CAE5x5YWjPz=REEb-nWFFsZpkvRQ=dbP7fuwST3=zgQk3hmprMQ@mail.gmail.com>	<CAE5x5YWoLpNnQYVDv_qRM0Hanbe5DRzLSuOQCHswznZE2EkeiA@mail.gmail.com>	<CAE5x5YU8R9PibP-_xj+uYNc_rqOL0rnuHvVF5Ymz32RngDEgFw@mail.gmail.com>	<CAE5x5YWpGjHd5ULwtsoerWhPf+W+iHUoDW9AyHNz_Ypzg2bckA@mail.gmail.com>	<54A15BFA.4050001@m2r.biz>
	<CAE5x5YWRJaF1XZ0masWn0uotUQghW0irM=NmU9XB0Dc8_XUFJw@mail.gmail.com>
In-Reply-To: <CAE5x5YWRJaF1XZ0masWn0uotUQghW0irM=NmU9XB0Dc8_XUFJw@mail.gmail.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DEBUGGING Xen 4.4.1/Qxl/Debian unstable] QXL
 drivers don't want to install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8589351904436073324=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8589351904436073324==
Content-Type: multipart/alternative;
 boundary="------------080006000500080704020405"

This is a multi-part message in MIME format.
--------------080006000500080704020405
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Il 31/12/2014 02:26, Goonie Windy ha scritto:
> Ok Fabio, thanks to your configure, some bits of hacking the install 
> part and lots of advises/support/encouragements ;) from Mark Pryor I 
> ended up
>  installing 4.5RC4 with QXL support on Deb8 unstable.
>
>
> So now what do you want me to test fabio?
> I have win7 x64 / win 2k8R2 vms in test mode ready to install drvers.
>
> the numerous troubles I went through are related in the IRCcopy attached.
> I actually couldn't build rombios and used seabios provided by the 
> system -like you-
> I should try to compile/find latest qxl now.

rombios is used only by qemu traditional that is very old, without spice 
support and hvm domUs have lower performance with it.
qxl drivers in latest spice guest tools are signed and not require 
windows testsigning mode, same for james haper xen gplpv.
If you want test new winpv drivers instead you need it.

For me qxl is working good on w7 domUs except after save/restore when 
"freeze" 2-3 minutes on screen resolution change and I not found the 
exact problem for now.
I also not found how to have qxl working in linux domUs, on latest test 
xorg crash on start with qxl driver installed.
Probably other changes are needed in hvmloader and/or xen hypervisor 
and/or qxl driver.
Any help testing it is appreciated.

>
> See you in 2K15.
>
> greg B
>
> 2014-12-29 14:49 GMT+01:00 Fabio Fantoni <fabio.fantoni@m2r.biz 
> <mailto:fabio.fantoni@m2r.biz>>:
>
>     Il 29/12/2014 14:13, Goonie Windy ha scritto:
>>     ok, I'm trying to patch the files with yours,
>>
>>
>>     I need to do it manually right?
>>
>>     git apply is not working here.
>
>     If the patch need a "refresh" the conflict should be solved manually.
>     Taking the patch updated from here probably it can be applied to
>     latest 4.5-rc:
>     https://github.com/Fantu/Xen/commits/rebase/m2r-staging
>
>>
>>
>>     regards
>>
>>     greg
>>
>>     2014-12-29 13:46 GMT+01:00 Goonie Windy
>>     <monsieur.goonie@gmail.com <mailto:monsieur.goonie@gmail.com>>:
>>
>>         There is an error in pageqs describing how to compile from
>>         sources as in 4.5
>>
>>         cat .config
>>         PYTHON_PREFIX_ARG=--install-layout=deb
>>
>>         is in fact in .INSTALL
>>
>
>     If also you use debian you can use make debball that is better for
>     install/remove easy and fast test build.
>
>     And for example I use this configure options with xen 4.5:
>     ./configure --prefix=/usr --disable-blktap1
>     --disable-qemu-traditional --disable-rombios
>     --with-system-seabios=/usr/share/seabios/bios-256k.bin
>     --with-extra-qemuu-configure-args="--enable-spice
>     --enable-usb-redir" --disable-blktap2
>     I use wheezy building updated packages from sid: seabios 1.7.5-1,
>     spice 0.12.5-1, spice-protocol 0.12.7-1 and usbredir 0.7-1.
>     If you use jessie instead you have all packages updated.
>
>     About python I'm using this workaround (before execute configure)
>     even if probably is not the best:
>     Config.mk
>     -PYTHON_PREFIX_ARG ?=--prefix="$(PREFIX)"
>     +PYTHON_PREFIX_ARG ?=
>
>
>>
>>
>>         2014-12-29 1:20 GMT+01:00 Goonie Windy
>>         <monsieur.goonie@gmail.com <mailto:monsieur.goonie@gmail.com>>:
>>
>>             well figured out it is because you have to "enforce"
>>             locale:  export LC_ALL=en_US.utf-8 if keyboard mapping is
>>             else
>>
>>             2014-12-28 21:19 GMT+01:00 Goonie Windy
>>             <monsieur.goonie@gmail.com
>>             <mailto:monsieur.goonie@gmail.com>>:
>>
>>                 Trying to compile xen 4.5RC4 in order to test your
>>                 patch I end up with  these errors compiling the
>>                 Seabios directories,
>>
>>                 any idea?
>>
>>                   Compiling to assembler out/src/asm-offsets.s
>>                   Generating offset file out/asm-offsets.h
>>                   Compiling (16bit) out/romlayout.o
>>                   Building ld scripts
>>                 Version: rel-1.7.5-0-ge51488c-20141228_210340-E766
>>                 Traceback (most recent call last):
>>                   File "./scripts/layoutrom.py", line 709, in <module>
>>                     main()
>>                   File "./scripts/layoutrom.py", line 671, in main
>>                     info16 = parseObjDump(infile16, '16')
>>                   File "./scripts/layoutrom.py", line 586, in
>>                 parseObjDump
>>                     relocsection = sectionmap[sectionname]
>>                 KeyError:
>>                 '.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
>>                 Makefile:155: recipe for target 'out/romlayout16.lds'
>>                 failed
>>                 make[6]: *** [out/romlayout16.lds] Error 1
>>                 make[6]: Leaving directory
>>                 '/home/goon/xen/tools/firmware/seabios-dir-remote'
>>                 /home/goon/xen/tools/firmware/../../tools/Rules.mk:116:
>>                 recipe for target 'subdir-all-seabios-dir' failed
>>
>>
>>
>>                 2014-12-27 17:35 GMT+01:00 Goonie Windy
>>                 <monsieur.goonie@gmail.com
>>                 <mailto:monsieur.goonie@gmail.com>>:
>>
>>                     Hello Fabio,
>>
>>                     Sure thing I will help debug the win7 and the
>>                     win8 versions.
>>                     Where to start?
>>
>>                     I'll try to see if I can patch with patch from
>>                     https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>                     and if not will post result.
>>
>>
>>                     best regards,
>>
>>
>>                     greg Bahde
>>
>>                     2014-12-27 15:10 GMT+01:00 Fabio Fantoni
>>                     <fabio.fantoni@m2r.biz
>>                     <mailto:fabio.fantoni@m2r.biz>>:
>>
>>
>>                         Il 27/12/2014 02:15, Goonie Windy ha scritto:
>>>                         I tried to install Qxl drivers under
>>>                         win7/win 2k8/win8.1 all       x64 versions,
>>>                         without any luck.
>>>
>>>
>>>                         admin message is as follow:
>>>                         Driver Management concluded the process to
>>>                         install driver FileRepository\qxl.inf_amd64_
>>>                         neutral_f0c429882d5c81ed\qxl.inf for Device
>>>                         Instance ID
>>>                         PCI\VEN_1013&DEV_00B8&SUBSYS_11001AF4&REV_00\3&267A616A&1&28
>>>                         with the following status: 0xe000022d.
>>>
>>>
>>>
>>>
>>>                         Does
>>>                         http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
>>>
>>>                         can it be installed on my xen stack?
>>
>>                         Yes but probably require a small refresh, I
>>                         always posted the patch based on updated
>>                         xen-unstable.
>>
>>                         Here qxl patch refreshed for xen 4.5 if needed:
>>                         https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe
>>
>>                         Here the latest spice guest tools for windows
>>                         with qxl driver included:
>>                         http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe
>>
>>                         Windows >=8 and similar require a new qxl
>>                         drivers, there are a beta build but latest
>>                         tried some months ago have serious bug and I
>>                         not found recent build full working on windows 8.
>>
>>                         On xen windows 7 domUs qxl works good except
>>                         a problem after save/restore and on linux
>>                         domUs is not working, for now I not found
>>                         exactly cause and solution.
>>                         On mailing list up to 2 years ago you can
>>                         find many my mails about.
>>                         Any help to test it is appreciated.
>>
>>                         Sorry for my bad english.
>>
>>>
>>>                         Also, can  I get invited at xendevel irc ?
>>>                         regards
>>>
>>>                         Greg
>>>
>>>
>>>                         _______________________________________________
>>>                         Xen-devel mailing list
>>>                         Xen-devel@lists.xen.org  <mailto:Xen-devel@lists.xen.org>
>>>                         http://lists.xen.org/xen-devel
>>
>>
>>
>>
>>
>>
>
>


--------------080006000500080704020405
Content-Type: text/html; charset=utf-8
Content-Length: 32279
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">Il 31/12/2014 02:26, Goonie Windy ha
      scritto:<br>
    </div>
    <blockquote
cite=3D"mid:CAE5x5YWRJaF1XZ0masWn0uotUQghW0irM=3DNmU9XB0Dc8_XUFJw@mail.gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>Ok Fabio, thanks to your configure, some bits of hacking
            the install part and lots of advises/support/encouragements
            ;) from Mark Pryor I ended up<br>
          </div>
          =C2=A0installing 4.5RC4 with QXL support on Deb8 unstable.<br>
          <br>
          <br>
        </div>
        <div>So now what do you want me to test fabio=3F<br>
        </div>
        <div>I have win7 x64 / win 2k8R2 vms in test mode ready to
          install drvers.<br>
        </div>
        <div><br>
        </div>
        <div>the numerous troubles I went through are related in the
          IRCcopy attached.<br>
        </div>
        <div>I actually couldn't build rombios and used seabios provided
          by the system -like you-<br>
        </div>
        <div>I should try to compile/find latest qxl now.<br>
        </div>
      </div>
    </blockquote>
    <br>
    rombios is used only by qemu traditional that is very old, without
    spice support and hvm domUs have lower performance with it.<br>
    qxl drivers in latest spice guest tools are signed and not require
    windows testsigning mode, same for james haper xen gplpv.<br>
    If you want test new winpv drivers instead you need it.<br>
    <br>
    For me qxl is working good on w7 domUs except after save/restore
    when "freeze" 2-3 minutes on screen resolution change and I not
    found the exact problem for now.<br>
    I also not found how to have qxl working in linux domUs, on latest
    test xorg crash on start with qxl driver installed.<br>
    Probably other changes are needed in hvmloader and/or xen hypervisor
    and/or qxl driver.<br>
    Any help testing it is appreciated.<br>
    <br>
    <blockquote
cite=3D"mid:CAE5x5YWRJaF1XZ0masWn0uotUQghW0irM=3DNmU9XB0Dc8_XUFJw@mail.gmail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>See you in 2K15.<br>
          <br>
        </div>
        <div>greg B<br>
        </div>
      </div>
      <div class=3D"gmail_extra"><br>
        <div class=3D"gmail_quote">2014-12-29 14:49 GMT+01:00 Fabio
          Fantoni <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
              href=3D"mailto:fabio.fantoni@m2r.biz" target=3D"_blank">fabio.fantoni@m2r.biz</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">
              <div>Il 29/12/2014 14:13, Goonie Windy ha scritto:<br>
              </div>
              <span class=3D"">
                <blockquote type=3D"cite">
                  <div dir=3D"ltr">
                    <div>
                      <div>
                        <div>ok, I'm trying to patch the files with
                          yours,<br>
                          <br>
                          <br>
                        </div>
                        I need to do it manually right=3F <br>
                        <br>
                        git apply is not working here. <br>
                      </div>
                    </div>
                  </div>
                </blockquote>
                <br>
              </span> If the patch need a "refresh" the conflict should
              be solved manually.<br>
              Taking the patch updated from here probably it can be
              applied to latest 4.5-rc:<br>
              <a moz-do-not-send=3D"true"
                href=3D"https://github.com/Fantu/Xen/commits/rebase/m2r-staging"
                target=3D"_blank">https://github.com/Fantu/Xen/commits/rebase/m2r-staging</a><span
                class=3D""><br>
                <br>
                <blockquote type=3D"cite">
                  <div dir=3D"ltr">
                    <div>
                      <div><br>
                        <br>
                      </div>
                      regards<br>
                      <br>
                    </div>
                    greg<br>
                  </div>
                  <div class=3D"gmail_extra"><br>
                    <div class=3D"gmail_quote">2014-12-29 13:46 GMT+01:00
                      Goonie Windy <span dir=3D"ltr">&lt;<a
                          moz-do-not-send=3D"true"
                          href=3D"mailto:monsieur.goonie@gmail.com"
                          target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">There is an error in pageqs
                          describing how to compile from sources as in
                          4.5 <br>
                          <pre>cat .config
PYTHON_PREFIX_ARG=3D--install-layout=3Ddeb

</pre>
                          <pre>is in fact in .INSTALL
</pre>
                        </div>
                      </blockquote>
                    </div>
                  </div>
                </blockquote>
                <br>
              </span> If also you use debian you can use make debball
              that is better for install/remove easy and fast test
              build.<br>
              <br>
              And for example I use this configure options with xen 4.5:<br>
              ./configure --prefix=3D/usr --disable-blktap1
              --disable-qemu-traditional --disable-rombios
              --with-system-seabios=3D/usr/share/seabios/bios-256k.bin
              --with-extra-qemuu-configure-args=3D"--enable-spice
              --enable-usb-redir" --disable-blktap2<br>
              I use wheezy building updated packages from sid: seabios
              1.7.5-1, spice 0.12.5-1, spice-protocol 0.12.7-1 and
              usbredir 0.7-1.<br>
              If you use jessie instead you have all packages updated.<br>
              <br>
              About python I'm using this workaround (before execute
              configure) even if probably is not the best:<br>
              <span title=3D"Config.mk">Config.mk</span><br>
              -<span>PYTHON_PREFIX_ARG</span> =3F=3D<span> --prefix=3D"</span><span><span>$(</span><span>PREFIX</span><span>)</span></span><span>"</span><br>
              +<span>PYTHON_PREFIX_ARG</span> =3F=3D
              <div>
                <div class=3D"h5"><br>
                  <br>
                  <blockquote type=3D"cite">
                    <div class=3D"gmail_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">
                          <div dir=3D"ltr"><br>
                          </div>
                          <div>
                            <div>
                              <div class=3D"gmail_extra"><br>
                                <div class=3D"gmail_quote">2014-12-29 1:20
                                  GMT+01:00 Goonie Windy <span
                                    dir=3D"ltr">&lt;<a
                                      moz-do-not-send=3D"true"
                                      href=3D"mailto:monsieur.goonie@gmail.com"
                                      target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                                      <div>well figured out it is
                                        because you have to "enforce"
                                        locale:=C2=A0 export
                                        LC_ALL=3Den_US.utf-8 if keyboard
                                        mapping is else<br>
                                      </div>
                                    </div>
                                    <div>
                                      <div>
                                        <div class=3D"gmail_extra"><br>
                                          <div class=3D"gmail_quote">2014-12-28
                                            21:19 GMT+01:00 Goonie Windy
                                            <span dir=3D"ltr">&lt;<a
                                                moz-do-not-send=3D"true"
                                                href=3D"mailto:monsieur.goonie@gmail.com"
                                                target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                                                <div>Trying to compile
                                                  xen 4.5RC4 in order to
                                                  test your patch I end
                                                  up with=C2=A0 these errors
                                                  compiling the Seabios
                                                  directories,<br>
                                                  <br>
                                                </div>
                                                any idea=3F<br>
                                                <br>
                                                =C2=A0 Compiling to assembler
                                                out/src/asm-offsets.s<br>
                                                =C2=A0 Generating offset file
                                                out/asm-offsets.h<br>
                                                =C2=A0 Compiling (16bit)
                                                out/romlayout.o<br>
                                                =C2=A0 Building ld scripts<br>
                                                Version:
                                                rel-1.7.5-0-ge51488c-20141228_210340-E766<br>
                                                Traceback (most recent
                                                call last):<br>
                                                =C2=A0 File
                                                "./scripts/layoutrom.py",
                                                line 709, in
                                                &lt;module&gt;<br>
                                                =C2=A0=C2=A0=C2=A0 main()<br>
                                                =C2=A0 File
                                                "./scripts/layoutrom.py",
                                                line 671, in main<br>
                                                =C2=A0=C2=A0=C2=A0 info16 =3D
                                                parseObjDump(infile16,
                                                '16')<br>
                                                =C2=A0 File
                                                "./scripts/layoutrom.py",
                                                line 586, in
                                                parseObjDump<br>
                                                =C2=A0=C2=A0=C2=A0 relocsection =3D
                                                sectionmap[sectionname]<br>
                                                KeyError:
'.text.asm./home/goon/xen/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'<br>
                                                Makefile:155: recipe for
                                                target
                                                'out/romlayout16.lds'
                                                failed<br>
                                                make[6]: ***
                                                [out/romlayout16.lds]
                                                Error 1<br>
                                                make[6]: Leaving
                                                directory
                                                '/home/goon/xen/tools/firmware/seabios-dir-remote'<br>
                                                /home/goon/xen/tools/firmware/../../tools/Rules.mk:116:

                                                recipe for target
                                                'subdir-all-seabios-dir'
                                                failed<br>
                                                <br>
                                                <br>
                                              </div>
                                              <div>
                                                <div>
                                                  <div
                                                    class=3D"gmail_extra"><br>
                                                    <div
                                                      class=3D"gmail_quote">2014-12-27

                                                      17:35 GMT+01:00
                                                      Goonie Windy <span
                                                        dir=3D"ltr">&lt;<a
moz-do-not-send=3D"true" href=3D"mailto:monsieur.goonie@gmail.com"
                                                          target=3D"_blank">monsieur.goonie@gmail.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 dir=3D"ltr">
                                                          <div>
                                                          <div>
                                                          <div>Hello
                                                          Fabio,<br>
                                                          <br>
                                                          Sure thing I
                                                          will help
                                                          debug the win7
                                                          and the win8
                                                          versions.<br>
                                                          </div>
                                                          Where to
                                                          start=3F<br>
                                                          <br>
                                                          </div>
                                                          I'll try to
                                                          see if I can
                                                          patch with
                                                          patch from <a
moz-do-not-send=3D"true"
href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe"
target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a>
                                                          and if not
                                                          will post
                                                          result.<br>
                                                          <br>
                                                          <br>
                                                          best regards,<br>
                                                          <br>
                                                          <br>
                                                          </div>
                                                          greg Bahde<br>
                                                        </div>
                                                        <div>
                                                          <div>
                                                          <div
                                                          class=3D"gmail_extra"><br>
                                                          <div
                                                          class=3D"gmail_quote">2014-12-27

                                                          15:10
                                                          GMT+01:00
                                                          Fabio Fantoni
                                                          <span
                                                          dir=3D"ltr">&lt;<a
moz-do-not-send=3D"true" href=3D"mailto:fabio.fantoni@m2r.biz"
                                                          target=3D"_blank">fabio.fantoni@m2r.biz</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">
                                                          <br>
                                                          <div>Il
                                                          27/12/2014
                                                          02:15, Goonie
                                                          Windy ha
                                                          scritto:<br>
                                                          </div>
                                                          <span>
                                                          <blockquote
                                                          type=3D"cite">
                                                          <div dir=3D"ltr">
                                                          <div>
                                                          <div>
                                                          <div>I tried
                                                          to install Qxl
                                                          drivers under
                                                          win7/win
                                                          2k8/win8.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          all=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x64
                                                          versions,
                                                          without any
                                                          luck.<br>
                                                          <br>
                                                          <br>
                                                          admin message
                                                          is as follow:<br>
                                                          Driver
                                                          Management
                                                          concluded the
                                                          process to
                                                          install driver
                                                          FileRepository\qxl.inf_amd64_


                                                          <div dir=3D"ltr">neutral_f0c429882d5c81ed\qxl.inf

                                                          for Device
                                                          Instance ID
                                                          PCI\VEN_1013&amp;DEV_00B8&amp;SUBSYS_11001AF4&amp;REV_00\3&amp;267A616A&amp;1&amp;28


                                                          with the
                                                          following
                                                          status:
                                                          0xe000022d.</div>
                                                          <br>
                                                          <br>
                                                          <br>
                                                          <br>
                                                          </div>
                                                          Does <br>
                                                          <a
                                                          moz-do-not-send=3D"true"
href=3D"http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html"
target=3D"_blank">http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html</a><br>
                                                          <br>
                                                          </div>
                                                          can it be
                                                          installed on
                                                          my xen stack=3F
                                                          <br>
                                                          </div>
                                                          </div>
                                                          </blockquote>
                                                          <br>
                                                          </span> Yes
                                                          but probably
                                                          require a
                                                          small refresh,
                                                          I always
                                                          posted the
                                                          patch based on
                                                          updated
                                                          xen-unstable.
                                                          <br>
                                                          <br>
                                                          Here qxl patch
                                                          refreshed for
                                                          xen 4.5 if
                                                          needed:<br>
                                                          <a
                                                          moz-do-not-send=3D"true"
href=3D"https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe"
target=3D"_blank">https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe</a><br>
                                                          <br>
                                                          Here the
                                                          latest spice
                                                          guest tools
                                                          for windows
                                                          with qxl
                                                          driver
                                                          included:<br>
                                                          <a
                                                          moz-do-not-send=3D"true"
href=3D"http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe"
target=3D"_blank">http://www.spice-space.org/download/binaries/spice-guest-tools/spice-guest-tools-0.74.exe</a><br>
                                                          <br>
                                                          Windows &gt;=3D8
                                                          and similar
                                                          require a new
                                                          qxl drivers,
                                                          there are a
                                                          beta build but
                                                          latest tried
                                                          some months
                                                          ago have
                                                          serious bug
                                                          and I not
                                                          found recent
                                                          build full
                                                          working on
                                                          windows 8.<br>
                                                          <br>
                                                          On xen windows
                                                          7 domUs qxl
                                                          works good
                                                          except a
                                                          problem after
                                                          save/restore
                                                          and on linux
                                                          domUs is not
                                                          working, for
                                                          now I not
                                                          found exactly
                                                          cause and
                                                          solution.<br>
                                                          On mailing
                                                          list up to 2
                                                          years ago you
                                                          can find many
                                                          my mails
                                                          about.<br>
                                                          Any help to
                                                          test it is
                                                          appreciated.<br>
                                                          <br>
                                                          Sorry for my
                                                          bad english.<br>
                                                          <br>
                                                          <blockquote
                                                          type=3D"cite"><span>
                                                          <div dir=3D"ltr">
                                                          <div><br>
                                                          Also, can=C2=A0 I
                                                          get invited at
                                                          xendevel irc =3F<br>
                                                          regards<br>
                                                          <br>
                                                          </div>
                                                          Greg <br>
                                                          </div>
                                                          <br>
                                                          <fieldset></fieldset>
                                                          <br>
                                                          </span>
                                                          <pre>_______________________________________________
Xen-devel mailing list
<a moz-do-not-send=3D"true" href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@lists.xen.org</a>
<a moz-do-not-send=3D"true" href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.xen.org/xen-devel</a>
</pre>
                                                          </blockquote>
                                                          <br>
                                                          </div>
                                                          </blockquote>
                                                          </div>
                                                          <br>
                                                          </div>
                                                          </div>
                                                        </div>
                                                      </blockquote>
                                                    </div>
                                                    <br>
                                                  </div>
                                                </div>
                                              </div>
                                            </blockquote>
                                          </div>
                                          <br>
                                        </div>
                                      </div>
                                    </div>
                                  </blockquote>
                                </div>
                                <br>
                              </div>
                            </div>
                          </div>
                        </blockquote>
                      </div>
                      <br>
                    </div>
                  </blockquote>
                  <br>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------080006000500080704020405--


--===============8589351904436073324==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8589351904436073324==--


From xen-devel-bounces@lists.xen.org Wed Dec 31 09:07:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09: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 1Y6FF1-0000iA-Fw; Wed, 31 Dec 2014 09:06:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1Y6FEz-0000i4-Pd
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:06:53 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	89/40-15461-DACB3A45; Wed, 31 Dec 2014 09:06:53 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1420016808!10571754!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11783 invoked from network); 31 Dec 2014 09:06:52 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2014 09:06:52 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AZK43206; Wed, 31 Dec 2014 17:06:47 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.62]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Wed, 31 Dec 2014 17:06:39 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Significant network performance difference when different NIC
	MQ handles the packet
Thread-Index: AdAk2RFSz9NbHJ3lQTKs2RazzkLerQ==
Date: Wed, 31 Dec 2014 09:06:40 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE23955DC4@SZXEMA512-MBX.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.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020206.54A3BCAF.0106, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.62,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: fb99184b3cf4b372209bd8b719306297
Cc: Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Liuji \(Jeremy\)" <jeremy.liu@huawei.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: [Xen-devel] Significant network performance difference when
 different NIC MQ handles the packet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

SGksIGFsbDoNCg0KCUkgaGF2ZSB1c2VkIHBrdC1nZW4gdG8gc2VuZCB1ZHAgcGFja2V0ICgxNDAw
IGJ5dGVzKSBmcm9tIG9uZSBEb20wIEEgdG8gYW5vdGhlciBEb20wIEIgZWFjaCBvZiB3aGljaCBp
cyBjb25uZWN0ZWQgYnkgMTBHRSBuZXR3b3JrLiBPbiB0aGUgcmVjZWl2ZSBzaWRlIChCKaOsZGlm
ZmVyZW50ICJrc29mdGlycWQveCIgcHJvY2Vzc2VzIHdpbGwgaGFuZGxlIHRoZSBwYWNrZXQgZHVy
aW5nIGVhY2ggdGVzdGluZyBiZWNhdXNlIHRoZSBuaWMgaGFzIG11bHRpcGxlIHF1ZXVlcy4gSSBm
aW5kIHRoYXQgaWYgImtzb2Z0aXJxZC8wIiBoYW5kbGVzIHRoZSBwYWNrZXQsIHRoZSB0aHJvdWdo
b3V0IGNhbiByZWFjaCB0byBhYm91dCA3R2Jwcy4gSG93ZXZlciwgd2hlbiAia3NvZnRpcnFkLzIi
IGhhbmRsZXMgdGhlIHBhY2tldCwgdGhlIHRocm91Z2hvdXQgY2FuIG9ubHkgcmVhY2ggdG8gYWJv
dXQgMkdicHMsIGFuZCBmb3IgImtzb2Z0aXJxZC8zIiwgdGhlIHRocm91Z2hvdXQgY2FuIGV2ZW4g
YXMgbG93IGFzIDFHYnBzLg0KDQoJSSBhbSB3b25kZXJpbmcgd2hhdCB0aGUgcmVhc29uIGl0IGlz
LiBDb3VsZCBhbnlvbmUgZ2l2ZSBtZSBzb21lIGhpbnQgYWJvdXQgaXQgPw0KDQotLS0tLS0tLS0t
DQp6aGFuZ2xlaXFpYW5nIChUcnVtcCkNCg0KQmVzdCBSZWdhcmRzDQoNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Dec 31 09:07:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09: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 1Y6FF1-0000iA-Fw; Wed, 31 Dec 2014 09:06:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangleiqiang@huawei.com>) id 1Y6FEz-0000i4-Pd
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:06:53 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	89/40-15461-DACB3A45; Wed, 31 Dec 2014 09:06:53 +0000
X-Env-Sender: zhangleiqiang@huawei.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1420016808!10571754!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11783 invoked from network); 31 Dec 2014 09:06:52 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Dec 2014 09:06:52 -0000
Received: from 172.24.2.119 (EHLO SZXEMA413-HUB.china.huawei.com)
	([172.24.2.119])
	by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued)
	with ESMTP id AZK43206; Wed, 31 Dec 2014 17:06:47 +0800 (CST)
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.62]) by
	SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id
	14.03.0158.001; Wed, 31 Dec 2014 17:06:39 +0800
From: "Zhangleiqiang (Trump)" <zhangleiqiang@huawei.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Significant network performance difference when different NIC
	MQ handles the packet
Thread-Index: AdAk2RFSz9NbHJ3lQTKs2RazzkLerQ==
Date: Wed, 31 Dec 2014 09:06:40 +0000
Message-ID: <3A6795EA1206904E94BEC8EF9DF109AE23955DC4@SZXEMA512-MBX.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.146.122.235]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020206.54A3BCAF.0106, ss=1, re=0.001, recu=0.000,
	reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.62,
	so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: fb99184b3cf4b372209bd8b719306297
Cc: Zhuangyuxin <zhuangyuxin@huawei.com>,
	"Liuji \(Jeremy\)" <jeremy.liu@huawei.com>,
	"Luohao \(brian\)" <brian.luohao@huawei.com>,
	"Yuzhou \(C\)" <vitas.yuzhou@huawei.com>,
	"Xiaoding \(B\)" <xiaoding1@huawei.com>
Subject: [Xen-devel] Significant network performance difference when
 different NIC MQ handles the packet
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

SGksIGFsbDoNCg0KCUkgaGF2ZSB1c2VkIHBrdC1nZW4gdG8gc2VuZCB1ZHAgcGFja2V0ICgxNDAw
IGJ5dGVzKSBmcm9tIG9uZSBEb20wIEEgdG8gYW5vdGhlciBEb20wIEIgZWFjaCBvZiB3aGljaCBp
cyBjb25uZWN0ZWQgYnkgMTBHRSBuZXR3b3JrLiBPbiB0aGUgcmVjZWl2ZSBzaWRlIChCKaOsZGlm
ZmVyZW50ICJrc29mdGlycWQveCIgcHJvY2Vzc2VzIHdpbGwgaGFuZGxlIHRoZSBwYWNrZXQgZHVy
aW5nIGVhY2ggdGVzdGluZyBiZWNhdXNlIHRoZSBuaWMgaGFzIG11bHRpcGxlIHF1ZXVlcy4gSSBm
aW5kIHRoYXQgaWYgImtzb2Z0aXJxZC8wIiBoYW5kbGVzIHRoZSBwYWNrZXQsIHRoZSB0aHJvdWdo
b3V0IGNhbiByZWFjaCB0byBhYm91dCA3R2Jwcy4gSG93ZXZlciwgd2hlbiAia3NvZnRpcnFkLzIi
IGhhbmRsZXMgdGhlIHBhY2tldCwgdGhlIHRocm91Z2hvdXQgY2FuIG9ubHkgcmVhY2ggdG8gYWJv
dXQgMkdicHMsIGFuZCBmb3IgImtzb2Z0aXJxZC8zIiwgdGhlIHRocm91Z2hvdXQgY2FuIGV2ZW4g
YXMgbG93IGFzIDFHYnBzLg0KDQoJSSBhbSB3b25kZXJpbmcgd2hhdCB0aGUgcmVhc29uIGl0IGlz
LiBDb3VsZCBhbnlvbmUgZ2l2ZSBtZSBzb21lIGhpbnQgYWJvdXQgaXQgPw0KDQotLS0tLS0tLS0t
DQp6aGFuZ2xlaXFpYW5nIChUcnVtcCkNCg0KQmVzdCBSZWdhcmRzDQoNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6Fz5-0001eP-Vp; Wed, 31 Dec 2014 09:54:31 +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 1Y6Fz5-0001eH-1N
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D4/6B-15461-6D7C3A45; Wed, 31 Dec 2014 09:54:30 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1420019667!18632753!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.9 required=7.0 tests=DATE_IN_PAST_03_06,
	UPPERCASE_50_75
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1754 invoked from network); 31 Dec 2014 09:54:27 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-9.tower-21.messagelabs.com with SMTP;
	31 Dec 2014 09:54:27 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 31 Dec 2014 01:51:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="506074451"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 31 Dec 2014 01:49:11 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:31 -0500
Message-Id: <1420005031-25514-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 01/14] vTPM/TPM2: Add TPM 2.0 data structures
	and commands 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

Add TPM 2.0 data structures on Trusted Platform Module Library Part 2:
Structures and Trust Platform Module Library Part 3: Commands.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/tpm2_types.h | 978 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 978 insertions(+)
 create mode 100644 stubdom/vtpmmgr/tpm2_types.h

diff --git a/stubdom/vtpmmgr/tpm2_types.h b/stubdom/vtpmmgr/tpm2_types.h
new file mode 100644
index 0000000..214335c
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2_types.h
@@ -0,0 +1,978 @@
+#ifndef __TPM2_TYPES_H__
+#define __TPM2_TYPES_H__
+
+#include <stdlib.h>
+#include <stdint.h>
+
+// "implementation.h"
+// Table 212 -- Logic Values
+#define    YES      1
+#define    NO       0
+#ifndef    TRUE
+#define    TRUE     1
+#endif
+#ifndef    FALSE
+#define    FALSE    0
+#endif
+#ifndef    true
+#define    true     1
+#endif
+#ifndef    false
+#define    false    0
+#endif
+#define    SET      1
+#define    CLEAR    0
+
+
+// Table 214 -- Implemented Algorithms
+#define    ALG_RSA               YES    // 1
+#define    ALG_DES               NO     // 0
+#define    ALG__3DES             NO     // 0
+#define    ALG_SHA1              YES    // 1
+#define    ALG_HMAC              YES    // 1
+#define    ALG_AES               YES    // 1
+#define    ALG_MGF1              YES    // 1
+#define    ALG_XOR               YES    // 1
+#define    ALG_KEYEDHASH         YES    // 1
+#define    ALG_SHA256            YES    // 1
+#define    ALG_SHA384            YES    // 0
+#define    ALG_SHA512            YES    // 0
+#define    ALG_WHIRLPOOL512      YES    // 0
+#define    ALG_SM3_256           YES    // 1
+#define    ALG_SM4               YES    // 1
+#define    ALG_RSASSA            YES    // 1
+#define    ALG_RSAES             YES    // 1
+#define    ALG_RSAPSS            YES    // 1
+#define    ALG_OAEP              YES    // 1
+#define    ALG_ECC               YES    // 1
+#define    ALG_CFB               YES    // 1
+#define    ALG_ECDH              YES    // 1
+#define    ALG_ECDSA             YES    // 1
+#define    ALG_ECDAA             YES    // 1
+#define    ALG_SM2               YES    // 1
+#define    ALG_ECSCHNORR         YES    // 1
+#define    ALG_SYMCIPHER         YES    // 1
+#define    ALG_KDF1_SP800_56a    YES    // 1
+#define    ALG_KDF2              NO     // 0
+#define    ALG_KDF1_SP800_108    YES    // 1
+#define    ALG_CTR               YES    // 1
+#define    ALG_OFB               YES    // 1
+#define    ALG_CBC               YES    // 1
+
+#define HASH_COUNT (ALG_SHA1+ALG_SHA256+ALG_SHA384+ALG_SHA512+ALG_WHIRLPOOL512+ALG_SM3_256)
+
+// Table 216 -- RSA Algorithm Constants
+#define    RSA_KEY_SIZES_BITS    2048    // {1024,2048}
+#define    MAX_RSA_KEY_BITS      2048
+#define    MAX_RSA_KEY_BYTES     ((MAX_RSA_KEY_BITS + 7) / 8)    // 256
+
+// Table 218 -- AES Algorithm Constants
+#define    AES_KEY_SIZES_BITS          128
+#define    MAX_AES_KEY_BITS            128
+#define    MAX_AES_BLOCK_SIZE_BYTES    16
+#define    MAX_AES_KEY_BYTES           ((MAX_AES_KEY_BITS + 7) / 8)    // 16
+
+
+// Table 220 -- Symmetric Algorithm Constants
+#define    MAX_SYM_KEY_BITS      MAX_AES_KEY_BITS    // 128
+#define    MAX_SYM_KEY_BYTES     MAX_AES_KEY_BYTES    // 16
+#define    MAX_SYM_BLOCK_SIZE    MAX_AES_BLOCK_SIZE_BYTES    // 16
+
+#define    MAX_SYM_DATA         128
+#define    MAX_ECC_KEY_BITS     256
+#define    MAX_ECC_KEY_BYTES    ((MAX_ECC_KEY_BITS + 7) / 8)
+
+
+typedef unsigned char BYTE;
+typedef unsigned char BOOL;
+typedef uint8_t       UINT8;
+typedef uint16_t      UINT16;
+typedef uint32_t      UINT32;
+typedef uint64_t      UINT64;
+
+// TPM2 command code
+
+typedef UINT32 TPM_CC;
+#define    TPM_CC_FIRST                         (TPM_CC)(0x0000011F)
+#define    TPM_CC_PP_FIRST                      (TPM_CC)(0x0000011F)
+#define    TPM_CC_NV_UndefineSpaceSpecial       (TPM_CC)(0x0000011F)
+#define    TPM_CC_EvictControl                  (TPM_CC)(0x00000120)
+#define    TPM_CC_HierarchyControl              (TPM_CC)(0x00000121)
+#define    TPM_CC_NV_UndefineSpace              (TPM_CC)(0x00000122)
+#define    TPM_CC_ChangeEPS                     (TPM_CC)(0x00000124)
+#define    TPM_CC_ChangePPS                     (TPM_CC)(0x00000125)
+#define    TPM_CC_Clear                         (TPM_CC)(0x00000126)
+#define    TPM_CC_ClearControl                  (TPM_CC)(0x00000127)
+#define    TPM_CC_ClockSet                      (TPM_CC)(0x00000128)
+#define    TPM_CC_HierarchyChangeAuth           (TPM_CC)(0x00000129)
+#define    TPM_CC_NV_DefineSpace                (TPM_CC)(0x0000012A)
+#define    TPM_CC_PCR_Allocate                  (TPM_CC)(0x0000012B)
+#define    TPM_CC_PCR_SetAuthPolicy             (TPM_CC)(0x0000012C)
+#define    TPM_CC_PP_Commands                   (TPM_CC)(0x0000012D)
+#define    TPM_CC_SetPrimaryPolicy              (TPM_CC)(0x0000012E)
+#define    TPM_CC_FieldUpgradeStart             (TPM_CC)(0x0000012F)
+#define    TPM_CC_ClockRateAdjust               (TPM_CC)(0x00000130)
+#define    TPM_CC_CreatePrimary                 (TPM_CC)(0x00000131)
+#define    TPM_CC_NV_GlobalWriteLock            (TPM_CC)(0x00000132)
+#define    TPM_CC_PP_LAST                       (TPM_CC)(0x00000132)
+#define    TPM_CC_GetCommandAuditDigest         (TPM_CC)(0x00000133)
+#define    TPM_CC_NV_Increment                  (TPM_CC)(0x00000134)
+#define    TPM_CC_NV_SetBits                    (TPM_CC)(0x00000135)
+#define    TPM_CC_NV_Extend                     (TPM_CC)(0x00000136)
+#define    TPM_CC_NV_Write                      (TPM_CC)(0x00000137)
+#define    TPM_CC_NV_WriteLock                  (TPM_CC)(0x00000138)
+#define    TPM_CC_DictionaryAttackLockReset     (TPM_CC)(0x00000139)
+#define    TPM_CC_DictionaryAttackParameters    (TPM_CC)(0x0000013A)
+#define    TPM_CC_NV_ChangeAuth                 (TPM_CC)(0x0000013B)
+#define    TPM_CC_PCR_Event                     (TPM_CC)(0x0000013C)
+#define    TPM_CC_PCR_Reset                     (TPM_CC)(0x0000013D)
+#define    TPM_CC_SequenceComplete              (TPM_CC)(0x0000013E)
+#define    TPM_CC_SetAlgorithmSet               (TPM_CC)(0x0000013F)
+#define    TPM_CC_SetCommandCodeAuditStatus     (TPM_CC)(0x00000140)
+#define    TPM_CC_FieldUpgradeData              (TPM_CC)(0x00000141)
+#define    TPM_CC_IncrementalSelfTest           (TPM_CC)(0x00000142)
+#define    TPM_CC_SelfTest                      (TPM_CC)(0x00000143)
+#define    TPM_CC_Startup                       (TPM_CC)(0x00000144)
+#define    TPM_CC_Shutdown                      (TPM_CC)(0x00000145)
+#define    TPM_CC_StirRandom                    (TPM_CC)(0x00000146)
+#define    TPM_CC_ActivateCredential            (TPM_CC)(0x00000147)
+#define    TPM_CC_Certify                       (TPM_CC)(0x00000148)
+#define    TPM_CC_PolicyNV                      (TPM_CC)(0x00000149)
+#define    TPM_CC_CertifyCreation               (TPM_CC)(0x0000014A)
+#define    TPM_CC_Duplicate                     (TPM_CC)(0x0000014B)
+#define    TPM_CC_GetTime                       (TPM_CC)(0x0000014C)
+#define    TPM_CC_GetSessionAuditDigest         (TPM_CC)(0x0000014D)
+#define    TPM_CC_NV_Read                       (TPM_CC)(0x0000014E)
+#define    TPM_CC_NV_ReadLock                   (TPM_CC)(0x0000014F)
+#define    TPM_CC_ObjectChangeAuth              (TPM_CC)(0x00000150)
+#define    TPM_CC_PolicySecret                  (TPM_CC)(0x00000151)
+#define    TPM_CC_Rewrap                        (TPM_CC)(0x00000152)
+#define    TPM_CC_Create                        (TPM_CC)(0x00000153)
+#define    TPM_CC_ECDH_ZGen                     (TPM_CC)(0x00000154)
+#define    TPM_CC_HMAC                          (TPM_CC)(0x00000155)
+#define    TPM_CC_Import                        (TPM_CC)(0x00000156)
+#define    TPM_CC_Load                          (TPM_CC)(0x00000157)
+#define    TPM_CC_Quote                         (TPM_CC)(0x00000158)
+#define    TPM_CC_RSA_Decrypt                   (TPM_CC)(0x00000159)
+#define    TPM_CC_HMAC_Start                    (TPM_CC)(0x0000015B)
+#define    TPM_CC_SequenceUpdate                (TPM_CC)(0x0000015C)
+#define    TPM_CC_Sign                          (TPM_CC)(0x0000015D)
+#define    TPM_CC_Unseal                        (TPM_CC)(0x0000015E)
+#define    TPM_CC_PolicySigned                  (TPM_CC)(0x00000160)
+#define    TPM_CC_ContextLoad                   (TPM_CC)(0x00000161)
+#define    TPM_CC_ContextSave                   (TPM_CC)(0x00000162)
+#define    TPM_CC_ECDH_KeyGen                   (TPM_CC)(0x00000163)
+#define    TPM_CC_EncryptDecrypt                (TPM_CC)(0x00000164)
+#define    TPM_CC_FlushContext                  (TPM_CC)(0x00000165)
+#define    TPM_CC_LoadExternal                  (TPM_CC)(0x00000167)
+#define    TPM_CC_MakeCredential                (TPM_CC)(0x00000168)
+#define    TPM_CC_NV_ReadPublic                 (TPM_CC)(0x00000169)
+#define    TPM_CC_PolicyAuthorize               (TPM_CC)(0x0000016A)
+#define    TPM_CC_PolicyAuthValue               (TPM_CC)(0x0000016B)
+#define    TPM_CC_PolicyCommandCode             (TPM_CC)(0x0000016C)
+#define    TPM_CC_PolicyCounterTimer            (TPM_CC)(0x0000016D)
+#define    TPM_CC_PolicyCpHash                  (TPM_CC)(0x0000016E)
+#define    TPM_CC_PolicyLocality                (TPM_CC)(0x0000016F)
+#define    TPM_CC_PolicyNameHash                (TPM_CC)(0x00000170)
+#define    TPM_CC_PolicyOR                      (TPM_CC)(0x00000171)
+#define    TPM_CC_PolicyTicket                  (TPM_CC)(0x00000172)
+#define    TPM_CC_ReadPublic                    (TPM_CC)(0x00000173)
+#define    TPM_CC_RSA_Encrypt                   (TPM_CC)(0x00000174)
+#define    TPM_CC_StartAuthSession              (TPM_CC)(0x00000176)
+#define    TPM_CC_VerifySignature               (TPM_CC)(0x00000177)
+#define    TPM_CC_ECC_Parameters                (TPM_CC)(0x00000178)
+#define    TPM_CC_FirmwareRead                  (TPM_CC)(0x00000179)
+#define    TPM_CC_GetCapability                 (TPM_CC)(0x0000017A)
+#define    TPM_CC_GetRandom                     (TPM_CC)(0x0000017B)
+#define    TPM_CC_GetTestResult                 (TPM_CC)(0x0000017C)
+#define    TPM_CC_Hash                          (TPM_CC)(0x0000017D)
+#define    TPM_CC_PCR_Read                      (TPM_CC)(0x0000017E)
+#define    TPM_CC_PolicyPCR                     (TPM_CC)(0x0000017F)
+#define    TPM_CC_PolicyRestart                 (TPM_CC)(0x00000180)
+#define    TPM_CC_ReadClock                     (TPM_CC)(0x00000181)
+#define    TPM_CC_PCR_Extend                    (TPM_CC)(0x00000182)
+#define    TPM_CC_PCR_SetAuthValue              (TPM_CC)(0x00000183)
+#define    TPM_CC_NV_Certify                    (TPM_CC)(0x00000184)
+#define    TPM_CC_EventSequenceComplete         (TPM_CC)(0x00000185)
+#define    TPM_CC_HashSequenceStart             (TPM_CC)(0x00000186)
+#define    TPM_CC_PolicyPhysicalPresence        (TPM_CC)(0x00000187)
+#define    TPM_CC_PolicyDuplicationSelect       (TPM_CC)(0x00000188)
+#define    TPM_CC_PolicyGetDigest               (TPM_CC)(0x00000189)
+#define    TPM_CC_TestParms                     (TPM_CC)(0x0000018A)
+#define    TPM_CC_Commit                        (TPM_CC)(0x0000018B)
+#define    TPM_CC_PolicyPassword                (TPM_CC)(0x0000018C)
+#define    TPM_CC_SM2_ZGen                      (TPM_CC)(0x0000018D)
+#define    TPM_CC_LAST                          (TPM_CC)(0x0000018D)
+
+
+//TPM_RC
+typedef UINT32 TPM_RC;
+
+// TPM_ST Constants
+typedef UINT16 TPM_ST;
+#define    TPM_ST_NULL                    (TPM_ST)(0X8000)
+#define    TPM_ST_NO_SESSIONS             (TPM_ST)(0x8001)
+#define    TPM_ST_SESSIONS                (TPM_ST)(0x8002)
+
+
+// TPM Handle types
+typedef UINT32 TPM_HANDLE;
+typedef UINT8 TPM_HT;
+
+
+// TPM_RH Constants
+typedef UINT32 TPM_RH;
+
+#define    TPM_RH_FIRST          (TPM_RH)(0x40000000)
+#define    TPM_RH_SRK            (TPM_RH)(0x40000000)
+#define    TPM_RH_OWNER          (TPM_RH)(0x40000001)
+#define    TPM_RS_PW             (TPM_RH)(0x40000009)
+#define    TPM_RH_LOCKOUT        (TPM_RH)(0x4000000A)
+#define    TPM_RH_ENDORSEMENT    (TPM_RH)(0x4000000B)
+#define    TPM_RH_PLATFORM       (TPM_RH)(0x4000000C)
+#define    TPM_RH_LAST           (TPM_RH)(0x4000000C)
+
+// Table 4 -- DocumentationClarity Types <I/O>
+typedef UINT32    TPM_ALGORITHM_ID;
+typedef UINT32    TPM_MODIFIER_INDICATOR;
+typedef UINT32    TPM_SESSION_OFFSET;
+typedef UINT16    TPM_KEY_SIZE;
+typedef UINT16    TPM_KEY_BITS;
+typedef UINT64    TPM_SYSTEM_ADDRESS;
+typedef UINT32    TPM_SPEC;
+
+// Table 29 -- TPMA_ALGORITHM Bits <I/O>
+typedef struct {
+    unsigned int asymmetric:1;
+    unsigned int symmetric:1;
+    unsigned int hash:1;
+    unsigned int object:1;
+    unsigned int reserved5:4;
+    unsigned int signing:1;
+    unsigned int encrypting:1;
+    unsigned int method:1;
+    unsigned int reserved9:21;
+} TPMA_ALGORITHM;
+
+typedef UINT32 TPMA_OBJECT;
+typedef BYTE TPMA_SESSION;
+typedef BYTE TPMA_LOCALITY;
+
+// Table 37 -- TPMI_YES_NO Type <I/O>
+typedef BYTE TPMI_YES_NO;
+
+typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
+
+// Table 38 -- TPMI_DH_OBJECT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_OBJECT;
+
+// Table 39 -- TPMI_DH_PERSISTENT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_PERSISTENT;
+
+// Table 42 -- TPMI_SH_AUTH_SESSION Type <I/O>
+typedef TPM_HANDLE TPMI_SH_AUTH_SESSION;
+
+// Table 40 -- TPMI_DH_ENTITY Type <I>
+typedef TPM_HANDLE TPMI_DH_ENTITY;
+
+// Table 45 -- TPMI_DH_CONTEXT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_CONTEXT;
+
+// Table 46 -- TPMI_RH_HIERARCHY Type <I/O>
+typedef TPM_HANDLE TPMI_RH_HIERARCHY;
+
+// Table 47 -- TPMI_RH_HIERARCHY_AUTH Type <I>
+typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
+
+// Table 48 -- TPMI_RH_PLATFORM Type <I>
+typedef TPM_HANDLE TPMI_RH_PLATFORM;
+
+// Table 49 -- TPMI_RH_OWNER Type <I>
+typedef TPM_HANDLE TPMI_RH_OWNER;
+
+// Table 50 -- TPMI_RH_ENDORSEMENT Type <I>
+typedef TPM_HANDLE TPMI_RH_ENDORSEMENT;
+
+// Table 51 -- TPMI_RH_PROVISION Type <I>
+typedef TPM_HANDLE TPMI_RH_PROVISION;
+
+// Table 52 -- TPMI_RH_CLEAR Type <I>
+typedef TPM_HANDLE TPMI_RH_CLEAR;
+
+// Table 54 -- TPMI_RH_LOCKOUT Type <I>
+typedef TPM_HANDLE TPMI_RH_LOCKOUT;
+
+// Table 7 -- TPM_ALG_ID
+typedef UINT16 TPM_ALG_ID;
+typedef UINT16 TPM_ALG_ID;
+
+#define    TPM2_ALG_ERROR             (TPM_ALG_ID)(0x0000) // a: ; D:
+#define    TPM2_ALG_FIRST             (TPM_ALG_ID)(0x0001) // a: ; D:
+#if ALG_RSA == YES || ALG_ALL == YES
+#define    TPM2_ALG_RSA               (TPM_ALG_ID)(0x0001) // a: A O; D:
+#endif
+#if ALG_DES == YES || ALG_ALL == YES
+#define    TPM2_ALG_DES               (TPM_ALG_ID)(0x0002) // a: S; D:
+#endif
+#define    TPM2_ALG_SHA1              (TPM_ALG_ID)(0x0004) // a: H; D:
+#if ALG_HMAC == YES || ALG_ALL == YES
+#define    TPM2_ALG_HMAC              (TPM_ALG_ID)(0x0005) // a: H X; D:
+#endif
+#if ALG_AES == YES || ALG_ALL == YES
+#define    TPM2_ALG_AES               (TPM_ALG_ID)(0x0006) // a: S; D:
+#endif
+#if ALG_XOR == YES || ALG_ALL == YES
+#define    TPM2_ALG_XOR               (TPM_ALG_ID)(0x000A) // a: H S; D:
+#endif
+#if ALG_MGF1 == YES || ALG_ALL == YES
+#define    TPM2_ALG_MGF1              (TPM_ALG_ID)(0x0007) // a: H M; D:
+#endif
+#if ALG_KEYEDHASH == YES || ALG_ALL == YES
+#define    TPM2_ALG_KEYEDHASH         (TPM_ALG_ID)(0x0008) // a: H E X O; D:
+#endif
+#if ALG_SHA256 == YES || ALG_ALL == YES
+#define    TPM2_ALG_SHA256            (TPM_ALG_ID)(0x000B) // a: H; D:
+#endif
+#define    TPM2_ALG_NULL              (TPM_ALG_ID)(0x0010) // a: ; D:
+#if ALG_OAEP == YES || ALG_ALL == YES
+#define    TPM2_ALG_OAEP              (TPM_ALG_ID)(0x0017) // a: A E; D: RSA
+#endif
+#if ALG_ECC == YES || ALG_ALL == YES
+#define    TPM2_ALG_ECC               (TPM_ALG_ID)(0x0023) // a: A O; D:
+#endif
+#if ALG_SM4 == YES || ALG_ALL == YES
+#define    TPM2_ALG_SM4               (TPM_ALG_ID)(0x0013) // a: S; D:
+#endif
+#if ALG_SYMCIPHER == YES || ALG_ALL == YES
+#define    TPM2_ALG_SYMCIPHER         (TPM_ALG_ID)(0x0025) // a: O; D:
+#endif
+#if ALG_CFB == YES || ALG_ALL == YES
+#define    TPM2_ALG_CFB               (TPM_ALG_ID)(0x0043) // a: S E; D:
+#endif
+#define    TPM2_ALG_LAST              (TPM_ALG_ID)(0x0044)
+
+#define    SHA1_DIGEST_SIZE      20
+#define    SHA1_BLOCK_SIZE       64
+#define    SHA256_DIGEST_SIZE    32
+#define    SHA256_BLOCK_SIZE     64
+
+// Table 57 -- TPMI_ALG_ASYM Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_ASYM;
+
+// Table 56 -- TPMI_ALG_HASH Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_HASH;
+
+// Table 58 -- TPMI_ALG_SYM Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM;
+
+// Table 59 -- TPMI_ALG_SYM_OBJECT Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM_OBJECT;
+
+// Table 60 -- TPMI_ALG_SYM_MODE Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM_MODE;
+
+// Table 61 -- TPMI_ALG_KDF Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_KDF;
+
+// Table 62 -- TPMI_ALG_SIG_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SIG_SCHEME;
+
+// Table 65 -- TPMU_HA Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_SHA1
+    BYTE  sha1[SHA1_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA256
+    BYTE  sha256[SHA256_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SM3_256
+    BYTE  sm3_256[SM3_256_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA384
+    BYTE  sha384[SHA384_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA512
+    BYTE  sha512[SHA512_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_WHIRLPOOL512
+    BYTE  whirlpool[WHIRLPOOL512_DIGEST_SIZE];
+#endif
+
+} TPMU_HA;
+
+// Table 67 -- TPM2B_DIGEST Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[sizeof(TPMU_HA)];
+} TPM2B_DIGEST;
+
+// Table 69 -- TPM2B_NONCE Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_NONCE;
+
+typedef TPM2B_DIGEST    TPM2B_DATA;
+
+// Table 70 -- TPM2B_AUTH Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_AUTH;
+
+// Table 71 -- TPM2B_OPERAND Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_OPERAND;
+
+// Table 66 -- TPMT_HA Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    TPMU_HA          digest;
+} TPMT_HA;
+
+//Table 80 -- TPM2B_NAME Structure
+typedef struct {
+    UINT16 size;
+    BYTE name[sizeof(TPMT_HA)];
+} TPM2B_NAME;
+
+#define    IMPLEMENTATION_PCR   24
+#define    PLATFORM_PCR         24
+#define    PCR_SELECT_MAX       ((IMPLEMENTATION_PCR+7)/8)
+
+//Table 79 -- TPMS_PCR_SELECT Structure <I/O>
+typedef struct {
+    UINT8    sizeofSelect;
+    BYTE     pcrSelect[PCR_SELECT_MAX];
+} TPMS_PCR_SELECT;
+
+// Table 80 -- TPMS_PCR_SELECTION Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hash;
+    UINT8            sizeofSelect;
+    BYTE             pcrSelect[PCR_SELECT_MAX];
+} TPMS_PCR_SELECTION;
+
+// Table 83 -- TPMT_TK_CREATION Structure <I/O>
+typedef struct {
+    TPM_ST               tag;
+    TPMI_RH_HIERARCHY    hierarchy;
+    TPM2B_DIGEST         digest;
+} TPMT_TK_CREATION;
+
+// Table 96 -- Definition of TPML_DIGEST Structure <I/O>
+typedef struct {
+    UINT32               count;
+    TPM2B_DIGEST         digests[8];
+}TPML_DIGEST;
+
+// Table 97 -- TPML_PCR_SELECTION Structure <I/O>
+typedef struct {
+    UINT32                count;
+    TPMS_PCR_SELECTION    pcrSelections[HASH_COUNT];
+} TPML_PCR_SELECTION;
+
+// Table 119 -- TPMI_AES_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_AES_KEY_BITS;
+
+// Table 120 -- TPMI_SM4_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_SM4_KEY_BITS;
+
+// Table 121 -- TPMU_SYM_KEY_BITS Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_AES
+    TPMI_AES_KEY_BITS  aes;
+#endif
+#ifdef TPM2_ALG_SM4
+    TPMI_SM4_KEY_BITS  SM4;
+#endif
+    TPM_KEY_BITS  sym;
+#ifdef TPM2_ALG_XOR
+    TPMI_ALG_HASH  xor;
+#endif
+
+} TPMU_SYM_KEY_BITS;
+
+// Table 122 -- TPMU_SYM_MODE Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_AES
+    TPMI_ALG_SYM_MODE  aes;
+#endif
+#ifdef TPM2_ALG_SM4
+    TPMI_ALG_SYM_MODE  SM4;
+#endif
+    TPMI_ALG_SYM_MODE  sym;
+} TPMU_SYM_MODE ;
+
+// Table 124 -- TPMT_SYM_DEF Structure <I/O>
+typedef struct {
+    TPMI_ALG_SYM         algorithm;
+    TPMU_SYM_KEY_BITS    keyBits;
+    TPMU_SYM_MODE        mode;
+} TPMT_SYM_DEF;
+
+// Table 125 -- TPMT_SYM_DEF_OBJECT Structure <I/O>
+typedef struct {
+    TPMI_ALG_SYM_OBJECT    algorithm;
+    TPMU_SYM_KEY_BITS      keyBits;
+    TPMU_SYM_MODE          mode;
+} TPMT_SYM_DEF_OBJECT;
+
+// Table 126 -- TPM2B_SYM_KEY Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_SYM_KEY_BYTES];
+} TPM2B_SYM_KEY;
+
+// Table 127 -- TPMS_SYMCIPHER_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    sym;
+} TPMS_SYMCIPHER_PARMS;
+
+// Table 128 -- TPM2B_SENSITIVE_DATA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_SYM_DATA];
+} TPM2B_SENSITIVE_DATA;
+
+// Table 129 -- TPMS_SENSITIVE_CREATE Structure <I>
+typedef struct {
+    TPM2B_AUTH              userAuth;
+    TPM2B_SENSITIVE_DATA    data;
+} TPMS_SENSITIVE_CREATE;
+
+// Table 130 -- TPM2B_SENSITIVE_CREATE Structure <I,S>
+typedef struct {
+    UINT16                   size;
+    TPMS_SENSITIVE_CREATE    sensitive;
+} TPM2B_SENSITIVE_CREATE;
+
+// Table 131 -- TPMS_SCHEME_SIGHASH Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_SIGHASH;
+
+// Table 132 -- TPMI_ALG_KEYEDHASH_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_KEYEDHASH_SCHEME;
+
+// Table 133 -- HMAC_SIG_SCHEME Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_HMAC;
+
+// Table 134 -- TPMS_SCHEME_XOR Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    TPMI_ALG_KDF     kdf;
+} TPMS_SCHEME_XOR;
+
+// Table 135 -- TPMU_SCHEME_KEYEDHASH Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_HMAC
+    TPMS_SCHEME_HMAC  hmac;
+#endif
+#ifdef TPM2_ALG_XOR
+    TPMS_SCHEME_XOR  xor;
+#endif
+
+} TPMU_SCHEME_KEYEDHASH ;
+
+// Table 136 -- TPMT_KEYEDHASH_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_KEYEDHASH_SCHEME    scheme;
+    TPMU_SCHEME_KEYEDHASH        details;
+} TPMT_KEYEDHASH_SCHEME;
+
+// Table 137 -- RSA_SIG_SCHEMES Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_RSASSA;
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_RSAPSS;
+
+// Table 138 -- ECC_SIG_SCHEMES Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_ECDSA;
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_SM2;
+
+// Table 139 -- TPMS_SCHEME_ECDAA Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    UINT16           count;
+} TPMS_SCHEME_ECDAA;
+
+// Table 140 -- TPMS_SCHEME_ECSCHNORR Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    UINT16           count;
+} TPMS_SCHEME_ECSCHNORR;
+
+// Table 141 -- TPMU_SIG_SCHEME Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_RSASSA
+    TPMS_SCHEME_RSASSA  rsassa;
+#endif
+#ifdef TPM2_ALG_RSAPSS
+    TPMS_SCHEME_RSAPSS  rsapss;
+#endif
+#ifdef TPM2_ALG_ECDSA
+    TPMS_SCHEME_ECDSA  ecdsa;
+#endif
+#ifdef TPM2_ALG_SM2
+    TPMS_SCHEME_SM2  sm2;
+#endif
+#ifdef TPM2_ALG_ECDAA
+    TPMS_SCHEME_ECDAA  ecdaa;
+#endif
+#ifdef TPM2_ALG_ECSCHNORR
+    TPMS_SCHEME_ECSCHNORR  ecSchnorr;
+#endif
+#ifdef TPM2_ALG_HMAC
+    TPMS_SCHEME_HMAC  hmac;
+#endif
+    TPMS_SCHEME_SIGHASH  any;
+} TPMU_SIG_SCHEME;
+
+// Table 142 -- TPMT_SIG_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_SIG_SCHEME    scheme;
+    TPMU_SIG_SCHEME        details;
+} TPMT_SIG_SCHEME;
+
+// Table 143 -- TPMS_SCHEME_OAEP Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_OAEP;
+
+// Table 144 -- TPMS_SCHEME_ECDH Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_ECDH;
+
+// Table 145 -- TPMS_SCHEME_MGF1 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_MGF1;
+
+// Table 146 -- TPMS_SCHEME_KDF1_SP800_56a Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF1_SP800_56a;
+
+// Table 147 -- TPMS_SCHEME_KDF2 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF2;
+
+// Table 148 -- TPMS_SCHEME_KDF1_SP800_108 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF1_SP800_108;
+
+// Table 149 -- TPMU_KDF_SCHEME Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_MGF1
+    TPMS_SCHEME_MGF1  mgf1;
+#endif
+#ifdef TPM2_ALG_KDF1_SP800_56a
+    TPMS_SCHEME_KDF1_SP800_56a  kdf1_SP800_56a;
+#endif
+#ifdef TPM2_ALG_KDF2
+    TPMS_SCHEME_KDF2  kdf2;
+#endif
+#ifdef TPM2_ALG_KDF1_SP800_108
+    TPMS_SCHEME_KDF1_SP800_108  kdf1_sp800_108;
+#endif
+
+} TPMU_KDF_SCHEME;
+
+// Table 150 -- TPMT_KDF_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_KDF       scheme;
+    TPMU_KDF_SCHEME    details;
+} TPMT_KDF_SCHEME;
+typedef TPM_ALG_ID TPMI_ALG_ASYM_SCHEME;
+
+// Table 152 -- TPMU_ASYM_SCHEME Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_RSASSA
+    TPMS_SCHEME_RSASSA  rsassa;
+#endif
+#ifdef TPM2_ALG_RSAPSS
+    TPMS_SCHEME_RSAPSS  rsapss;
+#endif
+#ifdef TPM2_ALG_OAEP
+    TPMS_SCHEME_OAEP  oaep;
+#endif
+#ifdef TPM2_ALG_ECDSA
+    TPMS_SCHEME_ECDSA  ecdsa;
+#endif
+#ifdef TPM2_ALG_SM2
+    TPMS_SCHEME_SM2  sm2;
+#endif
+#ifdef TPM2_ALG_ECDAA
+    TPMS_SCHEME_ECDAA  ecdaa;
+#endif
+#ifdef TPM2_ALG_ECSCHNORR
+    TPMS_SCHEME_ECSCHNORR  ecSchnorr;
+#endif
+    TPMS_SCHEME_SIGHASH  anySig;
+} TPMU_ASYM_SCHEME;
+
+typedef struct {
+    TPMI_ALG_ASYM_SCHEME    scheme;
+    TPMU_ASYM_SCHEME        details;
+} TPMT_ASYM_SCHEME;
+
+// Table 154 -- TPMI_ALG_RSA_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_RSA_SCHEME;
+
+// Table 155 -- TPMT_RSA_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_RSA_SCHEME    scheme;
+    TPMU_ASYM_SCHEME       details;
+} TPMT_RSA_SCHEME;
+
+// Table 156 -- TPMI_ALG_RSA_DECRYPT Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_RSA_DECRYPT;
+
+// Table 157 -- TPMT_RSA_DECRYPT Structure <I/O>
+typedef struct {
+    TPMI_ALG_RSA_DECRYPT    scheme;
+    TPMU_ASYM_SCHEME        details;
+} TPMT_RSA_DECRYPT;
+
+// Table 158 -- TPM2B_PUBLIC_KEY_RSA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_RSA_KEY_BYTES];
+} TPM2B_PUBLIC_KEY_RSA;
+
+// Table 159 -- TPMI_RSA_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_RSA_KEY_BITS;
+
+// Table 160 -- TPM2B_PRIVATE_KEY_RSA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_RSA_KEY_BYTES/2];
+} TPM2B_PRIVATE_KEY_RSA;
+
+// Table 162 -- TPM2B_ECC_PARAMETER
+typedef struct {
+    UINT16 size;
+    BYTE buffer[MAX_ECC_KEY_BYTES];
+} TPM2B_ECC_PARAMETER;
+
+// Table 163 -- TPMS_ECC_POINT Structure <I/O>
+typedef struct {
+    TPM2B_ECC_PARAMETER    x;
+    TPM2B_ECC_PARAMETER    y;
+} TPMS_ECC_POINT;
+
+// Table 164 -- TPMI_ALG_ECC_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_ECC_SCHEME;
+
+typedef UINT16 TPM_ECC_CURVE;
+
+// Table 165 -- TPMI_ECC_CURVE Type <I/O>
+typedef TPM_ECC_CURVE TPMI_ECC_CURVE;
+
+// Table 166 -- TPMT_ECC_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_ECC_SCHEME    scheme;
+    TPMU_SIG_SCHEME        details;
+} TPMT_ECC_SCHEME;
+
+// Table 175 -- TPMI_ALG_PUBLIC Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_PUBLIC;
+
+// Table 176 -- TPMU_PUBLIC_ID Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_KEYEDHASH
+    TPM2B_DIGEST  keyedHash;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPM2B_DIGEST  sym;
+#endif
+#ifdef TPM2_ALG_RSA
+    TPM2B_PUBLIC_KEY_RSA  rsa;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPMS_ECC_POINT  ecc;
+#endif
+} TPMU_PUBLIC_ID;
+
+// Table 177 -- TPMS_KEYEDHASH_PARMS Structure <I/O>
+typedef struct {
+    TPMT_KEYEDHASH_SCHEME    scheme;
+} TPMS_KEYEDHASH_PARMS;
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_ASYM_SCHEME       scheme;
+} TPMS_ASYM_PARMS;
+
+// Table 179 -- TPMS_RSA_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_RSA_SCHEME        scheme;
+    TPMI_RSA_KEY_BITS      keyBits;
+    UINT32                 exponent;
+} TPMS_RSA_PARMS;
+
+// Table 180 -- TPMS_ECC_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_ECC_SCHEME        scheme;
+    TPMI_ECC_CURVE         curveID;
+    TPMT_KDF_SCHEME        kdf;
+} TPMS_ECC_PARMS;
+
+// Table 181 -- TPMU_PUBLIC_PARMS Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_KEYEDHASH
+    TPMS_KEYEDHASH_PARMS  keyedHashDetail;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPMT_SYM_DEF_OBJECT  symDetail;
+#endif
+#ifdef TPM2_ALG_RSA
+    TPMS_RSA_PARMS  rsaDetail;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPMS_ECC_PARMS  eccDetail;
+#endif
+    TPMS_ASYM_PARMS  asymDetail;
+} TPMU_PUBLIC_PARMS;
+
+// Table 182 -- TPMT_PUBLIC_PARMS Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC      type;
+    TPMU_PUBLIC_PARMS    parameters;
+} TPMT_PUBLIC_PARMS;
+
+// Table 183 -- TPMT_PUBLIC Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC      type;
+    TPMI_ALG_HASH        nameAlg;
+    TPMA_OBJECT          objectAttributes;
+    TPM2B_DIGEST         authPolicy;
+    TPMU_PUBLIC_PARMS    parameters;
+    TPMU_PUBLIC_ID       unique;
+} TPMT_PUBLIC;
+
+// Table 184 -- TPM2B_PUBLIC
+typedef struct {
+    UINT16         size;
+    TPMT_PUBLIC    publicArea;
+} TPM2B_PUBLIC;
+
+// Table 185 -- TPMU_SENSITIVE_COMPOSITE Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_RSA
+    TPM2B_PRIVATE_KEY_RSA  rsa;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPM2B_ECC_PARAMETER  ecc;
+#endif
+#ifdef TPM2_ALG_KEYEDHASH
+    TPM2B_SENSITIVE_DATA  bits;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPM2B_SYM_KEY  sym;
+#endif
+    TPM2B_SENSITIVE_DATA  any;
+} TPMU_SENSITIVE_COMPOSITE;
+
+// Table 186 -- TPMT_SENSITIVE Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC             sensitiveType;
+    TPM2B_AUTH                  authValue;
+    TPM2B_DIGEST                seedValue;
+    TPMU_SENSITIVE_COMPOSITE    sensitive;
+} TPMT_SENSITIVE;
+
+// Table 187 -- TPM2B_SENSITIVE Structure <I/O>
+typedef struct {
+    UINT16            size;
+    TPMT_SENSITIVE    sensitiveArea;
+} TPM2B_SENSITIVE;
+
+typedef struct {
+    TPM2B_DIGEST      integrityOuter;
+    TPM2B_DIGEST      integrityInner;
+    TPMT_SENSITIVE    sensitive;
+} _PRIVATE;
+
+// Table 189 -- TPM2B_PRIVATE Structure <I/O,S>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[sizeof(_PRIVATE)];
+} TPM2B_PRIVATE;
+
+// Table 204 -- TPMS_CREATION_DATA <OUT>
+typedef struct {
+    TPML_PCR_SELECTION    pcrSelect;
+    TPM2B_DIGEST          pcrDigest;
+    TPMA_LOCALITY         locality;
+    TPM_ALG_ID            parentNameAlg;
+    TPM2B_NAME            parentName;
+    TPM2B_NAME            parentQualifiedName;
+    TPM2B_DATA            outsideInfo;
+} TPMS_CREATION_DATA;
+
+// Table 205 -- TPM2B_CREATION_DATA <OUT>
+typedef struct {
+    UINT16 size;
+    TPMS_CREATION_DATA creationData;
+} TPM2B_CREATION_DATA;
+
+/* the following structs is not part of standard struct defined in TPM2 spec */
+typedef struct {
+    UINT32            size;
+    TPM_RH            sessionHandle;
+    TPM2B_NONCE       nonce;
+    TPMA_SESSION      sessionAttributes;
+    TPM2B_AUTH        auth;
+} TPM_AuthArea;
+
+typedef struct {
+    TPM2B_SENSITIVE_CREATE  inSensitive;
+    TPM2B_PUBLIC            inPublic;
+    TPM2B_DATA              outsideInfo;
+    TPML_PCR_SELECTION      creationPCR;
+} TPM2_Create_Params_in;
+
+typedef TPM2_Create_Params_in    TPM2_CreatePrimary_Params_in;
+
+typedef struct {
+    TPM2B_PUBLIC        outPublic;
+    TPM2B_CREATION_DATA creationData;
+    TPM2B_DIGEST        creationHash;
+    TPMT_TK_CREATION    creationTicket;
+    TPM2B_NAME          name;
+} TPM2_CreatePrimary_Params_out;
+
+typedef struct {
+    TPM2B_PRIVATE       outPrivate;
+    TPM2B_PUBLIC        outPublic;
+    TPM2B_CREATION_DATA creationData;
+    TPM2B_DIGEST        creationHash;
+    TPMT_TK_CREATION    creationTicket;
+} TPM2_Create_Params_out;
+typedef struct {
+    TPM2B_PRIVATE    Private;
+    TPM2B_PUBLIC     Public;
+} TPM2_RSA_KEY;
+
+/*
+ * TPM 2.0 Objects
+ */
+
+#define TPM_HT_TRANSIENT        0x80
+#define HR_SHIFT                24
+#define HR_PERMANENT            (TPM_HT_TRANSIENT << HR_SHIFT)
+#define TRANSIENT_FIRST         (HR_PERMANENT)
+#define MAX_LOADED_OBJECTS      3
+#define TRANSIENT_LAST          (TRANSIENT_FIRST+MAX_LOADED_OBJECTS-1)
+/*
+ * TPMA_OBJECT Bits
+ */
+#define fixedTPM                ((1 << 1))
+#define stClear                 ((1 << 2))
+#define fixedParent             ((1 << 4))
+#define sensitiveDataOrigin     ((1 << 5))
+#define userWithAuth            ((1 << 6))
+#define adminWithPolicy         ((1 << 7))
+#define noDA                    ((1 << 10))
+#define encryptedDuplication    ((1 << 11))
+#define restricted              ((1 << 16))
+#define decrypt                 ((1 << 17))
+#define sign                    ((1 << 18))
+#endif
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzP-0001ly-Rv; Wed, 31 Dec 2014 09:54:51 +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 1Y6FzO-0001l3-5B
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:50 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	E8/A5-27623-9E7C3A45; Wed, 31 Dec 2014 09:54:49 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1420019687!16604833!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2788 invoked from network); 31 Dec 2014 09:54:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-3.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:48 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 31 Dec 2014 01:51:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="506074501"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 31 Dec 2014 01:49:31 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:54 -0500
Message-Id: <1420005054-25740-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 07/14] vTPM/TPM2: TPM2.0 TIS initialization
	and self test.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

call the TPM 2.0 various registers that allow communication between
the TPM 2.0 and platform hardware and software. TPM2_SelfTest causes
the TPM 2.0 to perform a test of its capabilities.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 extras/mini-os/include/tpm_tis.h |   1 +
 extras/mini-os/tpm_tis.c         | 156 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 157 insertions(+)

diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h
index 1faca0d..86e83f1 100644
--- a/extras/mini-os/include/tpm_tis.h
+++ b/extras/mini-os/include/tpm_tis.h
@@ -36,6 +36,7 @@
 struct tpm_chip;
 
 struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq);
+struct tpm_chip* init_tpm2_tis(unsigned long baseaddr, int localities, unsigned int irq);
 void shutdown_tpm_tis(struct tpm_chip* tpm);
 
 int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
index d78c465..debcc43 100644
--- a/extras/mini-os/tpm_tis.c
+++ b/extras/mini-os/tpm_tis.c
@@ -1363,5 +1363,161 @@ int tpm_tis_posix_fstat(int fd, struct stat* buf)
    return 0;
 }
 
+/* TPM 2.0 */
 
+/*TPM2.0 Selftest*/
+static void tpm2_selftest(struct tpm_chip* chip)
+{
+    uint8_t data[] = {
+        0x80, 0x1,
+        0x0, 0x0, 0x0, 0xb,
+        0x0, 0x0, 0x1, 0x43,
+        0x1,
+    };
+
+    tpm_transmit(chip, data, sizeof(data));
+}
+
+struct tpm_chip* init_tpm2_tis(unsigned long baseaddr, int localities, unsigned int irq)
+{
+    int i;
+    unsigned long addr;
+    struct tpm_chip* tpm = NULL;
+    uint32_t didvid;
+    uint32_t intfcaps;
+    uint32_t intmask;
+
+    printk("============= Init TPM2 TIS Driver ==============\n");
+
+    /*Sanity check the localities input */
+    if (localities & ~TPM_TIS_EN_LOCLALL) {
+        printk("init_tpm2_tis Invalid locality specification! %X\n", localities);
+        goto abort_egress;
+    }
+
+    printk("IOMEM Machine Base Address: %lX\n", baseaddr);
+
+    /* Create the tpm data structure */
+    tpm = malloc(sizeof(struct tpm_chip));
+    __init_tpm_chip(tpm);
+
+    /* Set the enabled localities - if 0 we leave default as all enabled */
+    if (localities != 0) {
+        tpm->enabled_localities = localities;
+    }
+    printk("Enabled Localities: ");
+    for (i = 0; i < 5; ++i) {
+        if (locality_enabled(tpm, i)) {
+            printk("%d ", i);
+        }
+    }
+    printk("\n");
+
+    /* Set the base machine address */
+    tpm->baseaddr = baseaddr;
+
+    /* Set default timeouts */
+    tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT);
+    tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT);
+    tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT);
+    tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT);
+
+    /*Map the mmio pages */
+    addr = tpm->baseaddr;
+    for (i = 0; i < 5; ++i) {
+        if (locality_enabled(tpm, i)) {
+
+            /* Map the page in now */
+            if ((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) {
+                printk("Unable to map iomem page a address %p\n", addr);
+                goto abort_egress;
+            }
+
+            /* Set default locality to the first enabled one */
+            if (tpm->locality < 0) {
+                if (tpm_tis_request_locality(tpm, i) < 0) {
+                    printk("Unable to request locality %d??\n", i);
+                    goto abort_egress;
+                }
+            }
+        }
+        addr += PAGE_SIZE;
+    }
+
+    /* Get the vendor and device ids */
+    didvid = ioread32(TPM_DID_VID(tpm, tpm->locality));
+    tpm->did = didvid >> 16;
+    tpm->vid = didvid & 0xFFFF;
+
+    /* Get the revision id */
+    tpm->rid = ioread8(TPM_RID(tpm, tpm->locality));
+    printk("2.0 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n",
+           tpm->did, tpm->vid, tpm->rid);
+
+    intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
+    printk("TPM interface capabilities (0x%x):\n", intfcaps);
+    if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
+        printk("\tBurst Count Static\n");
+    if (intfcaps & TPM_INTF_CMD_READY_INT)
+        printk("\tCommand Ready Int Support\n");
+    if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
+        printk("\tInterrupt Edge Falling\n");
+    if (intfcaps & TPM_INTF_INT_EDGE_RISING)
+        printk("\tInterrupt Edge Rising\n");
+    if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
+        printk("\tInterrupt Level Low\n");
+    if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
+        printk("\tInterrupt Level High\n");
+    if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
+        printk("\tLocality Change Int Support\n");
+    if (intfcaps & TPM_INTF_STS_VALID_INT)
+        printk("\tSts Valid Int Support\n");
+    if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
+        printk("\tData Avail Int Support\n");
+
+    /*Interupt setup */
+    intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
+
+    intmask |= TPM_INTF_CMD_READY_INT | TPM_INTF_LOCALITY_CHANGE_INT |
+               TPM_INTF_DATA_AVAIL_INT | TPM_INTF_STS_VALID_INT;
+
+    iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
+
+    /*If interupts are enabled, handle it */
+    if (irq) {
+        if (irq != TPM_PROBE_IRQ) {
+            tpm->irq = irq;
+        } else {
+        /*FIXME add irq probing feature later */
+        printk("IRQ probing not implemented\n");
+        }
+    }
+
+    if (tpm->irq) {
+        iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
+        if (bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) {
+            printk("Unabled to request irq: %u for use\n", tpm->irq);
+            printk("Will use polling mode\n");
+            tpm->irq = 0;
+        } else {
+
+            /* Clear all existing */
+            iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
+                                     ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
+
+            /* Turn on interrupts */
+            iowrite32(TPM_INT_ENABLE(tpm, tpm->locality),
+                                     intmask | TPM_GLOBAL_INT_ENABLE);
+        }
+    }
+
+    tpm2_selftest(tpm);
+    return tpm;
+
+abort_egress:
+    if (tpm != NULL) {
+        shutdown_tpm_tis(tpm);
+    }
+    return NULL;
+}
 #endif
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzT-0001nz-Lt; Wed, 31 Dec 2014 09:54:55 +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 1Y6FzS-0001n9-Im
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:54 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	15/D2-31453-DE7C3A45; Wed, 31 Dec 2014 09:54:53 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1420019692!8164647!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9921 invoked from network); 31 Dec 2014 09:54:53 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-206.messagelabs.com with SMTP;
	31 Dec 2014 09:54:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 31 Dec 2014 01:54:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="644906789"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 31 Dec 2014 01:54:49 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:51:01 -0500
Message-Id: <1420005061-25816-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 09/14] vTPM/TPM2: Support 'tpm2' extra
	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>
MIME-Version: 1.0
Content-Type: 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 vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
Add:
..
     extra="tpm2"
..
to launch vtpm-stubdom domain on TPM 2.0, ignore it on TPM 1.x. for
example,
vtpm-stubdom domain configuration on TPM 2.0:

  kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
  memory=16
  disk=["file:/var/scale/vdisk/vmgr,hda,w"]
  name="vtpmmgr"
  iomem=["fed40,5"]
  extra="tpm2"

vtpm-stubdom domain configuration on TPM 1.x:

  kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
  memory=16
  disk=["file:/var/scale/vdisk/vmgr,hda,w"]
  name="vtpmmgr"
  iomem=["fed40,5"]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/vtpmmgr.c | 46 ++++++++++++++++++++++++++++++++++++++++------
 stubdom/vtpmmgr/vtpmmgr.h | 14 ++++++++++++++
 2 files changed, 54 insertions(+), 6 deletions(-)

diff --git a/stubdom/vtpmmgr/vtpmmgr.c b/stubdom/vtpmmgr/vtpmmgr.c
index 270ca8a..f743ca6 100644
--- a/stubdom/vtpmmgr/vtpmmgr.c
+++ b/stubdom/vtpmmgr/vtpmmgr.c
@@ -45,6 +45,27 @@
 #include "vtpmmgr.h"
 #include "tcg.h"
 
+struct tpm_hardware_version hardware_version = {
+    .hw_version = TPM1_HARDWARE,
+};
+
+int parse_cmdline_hw(int argc, char** argv)
+{
+    int i;
+
+    for (i = 1; i < argc; ++i) {
+        if (!strncmp(argv[i], TPM2_EXTRA_OPT, 4)) {
+            hardware_version.hw_version = TPM2_HARDWARE;
+            break;
+        }
+    }
+    return 0;
+}
+
+int hw_is_tpm2(void)
+{
+    return (hardware_version.hw_version == TPM2_HARDWARE) ? 1 : 0;
+}
 
 void main_loop(void) {
    tpmcmd_t* tpmcmd;
@@ -74,12 +95,25 @@ int main(int argc, char** argv)
    sleep(2);
    vtpmloginfo(VTPM_LOG_VTPM, "Starting vTPM manager domain\n");
 
-   /* Initialize the vtpm manager */
-   if(vtpmmgr_init(argc, argv) != TPM_SUCCESS) {
-      vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
-      rc = -1;
-      goto exit;
-   }
+    /*Parse TPM hardware in extra command line*/
+    parse_cmdline_hw(argc, argv);
+
+    /* Initialize the vtpm manager */
+    if (hw_is_tpm2()) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Hardware : --- TPM 2.0 ---\n");
+        if (vtpmmgr2_init(argc, argv) != TPM_SUCCESS) {
+            vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
+            rc = -1;
+            goto exit;
+        }
+    }else{
+        vtpmloginfo(VTPM_LOG_VTPM, "Hardware : --- TPM 1.x ---\n");
+        if (vtpmmgr_init(argc, argv) != TPM_SUCCESS) {
+            vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
+            rc = -1;
+            goto exit;
+        }
+    }
 
    main_loop();
 
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index c479443..6a76af4 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -46,9 +46,21 @@
 #include "vtpm_manager.h"
 #include "tpm2_types.h"
 
+#define TPM2_EXTRA_OPT "tpm2"
 #define RSA_KEY_SIZE 0x0800
 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8)
 
+enum {
+    TPM1_HARDWARE = 1,
+    TPM2_HARDWARE,
+} tpm_version;
+
+struct tpm_hardware_version {
+    int hw_version;
+};
+
+extern struct tpm_hardware_version hardware_version;
+
 struct vtpm_globals {
    int tpm_fd;
    TPM_AUTH_SESSION    oiap;                // OIAP session for storageKey
@@ -97,5 +109,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 TPM_RC tpm2_take_ownership(void);
 TPM_RESULT vtpmmgr2_create(void);
 TPM_RESULT vtpmmgr2_init(int argc, char** argv);
+int parse_cmdline_hw(int argc, char** argv);
+int hw_is_tpm2(void);
 
 #endif
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzA-0001fY-0s; Wed, 31 Dec 2014 09:54:36 +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 1Y6Fz9-0001fB-89
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:35 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	3D/05-25547-AD7C3A45; Wed, 31 Dec 2014 09:54:34 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1420019672!16589176!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21824 invoked from network); 31 Dec 2014 09:54:32 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-7.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:32 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by orsmga101.jf.intel.com with ESMTP; 31 Dec 2014 01:54:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="655296142"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 31 Dec 2014 01:54:27 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:39 -0500
Message-Id: <1420005039-25553-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 02/14] vTPM/TPM2: TPM 2.0 data structures
	marshal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 TPM 2.0 data structure marshal for packing and unpacking TPM
2.0 data structures.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/tpm2_marshal.h | 673 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 673 insertions(+)
 create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h

diff --git a/stubdom/vtpmmgr/tpm2_marshal.h b/stubdom/vtpmmgr/tpm2_marshal.h
new file mode 100644
index 0000000..aaa4464
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2_marshal.h
@@ -0,0 +1,673 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef TPM2_MARSHAL_H
+#define TPM2_MARSHAL_H
+
+#include <stdlib.h>
+#include <mini-os/byteorder.h>
+#include <mini-os/endian.h>
+#include "tcg.h"
+#include "tpm2_types.h"
+#include <assert.h>
+
+#define pack_TPM_BUFFER(ptr, buf, size) pack_BUFFER(ptr, buf, size)
+#define unpack_TPM_BUFFER(ptr, buf, size) unpack_BUFFER(ptr, buf, size)
+
+inline BYTE* pack_BYTE_ARRAY(BYTE* ptr, const BYTE* array, UINT32 size)
+{
+    int i;
+    for (i = 0; i < size; i++)
+         ptr = pack_BYTE(ptr, array[i]);
+    return ptr;
+}
+
+inline BYTE* pack_TPMA_SESSION(BYTE* ptr, const TPMA_SESSION *attr)
+{
+    return pack_BYTE(ptr, (BYTE)(*attr));
+}
+
+inline BYTE* unpack_TPMA_SESSION(BYTE* ptr, TPMA_SESSION *attr)
+{
+    return unpack_BYTE(ptr, (BYTE *)attr);
+}
+
+inline BYTE* pack_TPMI_ALG_HASH(BYTE* ptr, const TPMI_ALG_HASH *hash)
+{
+    return pack_UINT16(ptr, *hash);
+}
+
+inline BYTE* unpack_TPMI_ALG_HASH(BYTE *ptr, TPMI_ALG_HASH *hash)
+{
+    return unpack_UINT16(ptr, hash);
+}
+
+#define pack_TPMA_OBJECT(ptr, t)                pack_UINT32(ptr, (UINT32)(*t))
+#define unpack_TPMA_OBJECT(ptr, t)              unpack_UINT32(ptr, (UINT32 *)(t))
+#define pack_TPM_RH(ptr, t)                     pack_UINT32(ptr, (UINT32)(*t))
+#define unpack_TPM_RH(ptr, t)                   unpack_UINT32(ptr, (UINT32 *)(t))
+#define pack_TPMA_LOCALITY(ptr, locality)       pack_BYTE(ptr, (BYTE)*locality)
+#define unpack_TPMA_LOCALITY(ptr, locality)     unpack_BYTE(ptr, (BYTE *)locality)
+#define pack_TPM_ST(ptr, tag)                   pack_UINT16(ptr, *tag)
+#define unpack_TPM_ST(ptr, tag)                 unpack_UINT16(ptr, tag)
+#define pack_TPM_KEY_BITS(ptr, t)               pack_UINT16(ptr, *t)
+#define unpack_TPM_KEY_BITS(ptr, t)             unpack_UINT16(ptr, t)
+#define pack_TPMI_AES_KEY_BITS(ptr, t)          pack_TPM_KEY_BITS(ptr, t)
+#define unpack_TPMI_AES_KEY_BITS(ptr, t)        unpack_TPM_KEY_BITS(ptr, t)
+#define pack_TPMI_RSA_KEY_BITS(ptr, t)          pack_TPM_KEY_BITS(ptr, t)
+#define unpack_TPMI_RSA_KEY_BITS(ptr, t)        unpack_TPM_KEY_BITS(ptr, t)
+#define pack_TPM_ALG_ID(ptr, id)                pack_UINT16(ptr, *id)
+#define unpack_TPM_ALG_ID(ptr, id)              unpack_UINT16(ptr, id)
+#define pack_TPM_ALG_SYM(ptr, t)                pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPM_ALG_SYM(ptr, t)              unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_ASYM(ptr, asym)           pack_TPM_ALG_ID(ptr, asym)
+#define unpack_TPMI_ALG_ASYM(ptr, asym)         unpack_TPM_ALG_ID(ptr, asym)
+#define pack_TPMI_ALG_SYM_OBJECT(ptr, t)        pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_SYM_OBJECT(ptr, t)      unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_SYM_MODE(ptr, t)          pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_SYM_MODE(ptr, t)        unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_KDF(ptr, t)               pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_KDF(ptr, t)             unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_PUBLIC(ptr, t)            pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_PUBLIC(ptr, t)          unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPM2_HANDLE(ptr, h)                pack_UINT32(ptr, *h)
+#define unpack_TPM2_HANDLE(ptr, h)              unpack_UINT32(ptr, h)
+#define pack_TPMI_ALG_RSA_SCHEME(ptr, t)        pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_RSA_SCHEME(ptr, t)      unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_DH_OBJECT(ptr, o)             pack_TPM2_HANDLE(ptr, o)
+#define unpack_TPMI_DH_OBJECT(PTR, O)           unpack_TPM2_HANDLE(ptr, o)
+#define pack_TPMI_RH_HIERACHY(ptr, h)           pack_TPM2_HANDLE(ptr, h)
+#define unpack_TPMI_RH_HIERACHY(ptr, h)         unpack_TPM2_HANDLE(ptr, h)
+#define pack_TPMI_RH_PLATFORM(ptr, p)           pack_TPM2_HANDLE(ptr, p)
+#define unpack_TPMI_RH_PLATFORM(ptr, p)         unpack_TPM2_HANDLE(ptr, p)
+#define pack_TPMI_RH_OWNER(ptr, o)              pack_TPM2_HANDLE(ptr, o)
+#define unpack_TPMI_RH_OWNER(ptr, o)            unpack_TPM2_HANDLE(ptr, o)
+#define pack_TPMI_RH_ENDORSEMENT(ptr, e)        pack_TPM2_HANDLE(ptr, e)
+#define unpack_TPMI_RH_ENDORSEMENT(ptr, e)      unpack_TPM2_HANDLE(ptr, e)
+#define pack_TPMI_RH_LOCKOUT(ptr, l)            pack_TPM2_HANDLE(ptr, l)
+#define unpack_TPMI_RH_LOCKOUT(ptr, l)          unpack_TPM2_HANDLE(ptr, l)
+
+inline BYTE* pack_TPM2B_DIGEST(BYTE* ptr, const TPM2B_DIGEST *digest)
+{
+    ptr = pack_UINT16(ptr, digest->size);
+    ptr = pack_BUFFER(ptr, digest->buffer, digest->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_DIGEST(BYTE* ptr, TPM2B_DIGEST *digest)
+{
+    ptr = unpack_UINT16(ptr, &digest->size);
+    ptr = unpack_BUFFER(ptr, digest->buffer, digest->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_TK_CREATION(BYTE* ptr,const TPMT_TK_CREATION *ticket )
+{
+    ptr = pack_TPM_ST(ptr , &ticket->tag);
+    ptr = pack_TPMI_RH_HIERACHY(ptr , &ticket->hierarchy);
+    ptr = pack_TPM2B_DIGEST(ptr, &ticket->digest);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_TK_CREATION(BYTE* ptr, TPMT_TK_CREATION *ticket )
+{
+    ptr = unpack_TPM_ST(ptr, &ticket->tag);
+    ptr = unpack_TPMI_RH_HIERACHY(ptr, &ticket->hierarchy);
+    ptr = unpack_TPM2B_DIGEST(ptr, &ticket->digest);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_NAME(BYTE* ptr,const TPM2B_NAME *name )
+{
+    ptr = pack_UINT16(ptr, name->size);
+    ptr = pack_TPM_BUFFER(ptr, name->name, name->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_NAME(BYTE* ptr, TPM2B_NAME *name)
+{
+    ptr = unpack_UINT16(ptr, &name->size);
+    ptr = unpack_TPM_BUFFER(ptr, name->name, name->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_NONCE(BYTE* ptr, const TPM2B_NONCE *nonce)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)nonce);
+}
+
+#define unpack_TPM2B_NONCE(ptr, nonce)  unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)nonce)
+
+inline BYTE* pack_TPM2B_AUTH(BYTE* ptr, const TPM2B_AUTH *auth)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)auth);
+}
+
+#define unpack_TPM2B_AUTH(ptr, auth)    unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)auth)
+
+inline BYTE* pack_TPM2B_DATA(BYTE* ptr, const TPM2B_DATA *data)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)data);
+}
+
+#define unpack_TPM2B_DATA(ptr, data)    unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)data)
+
+inline BYTE* pack_TPM2B_SENSITIVE_DATA(BYTE* ptr, const TPM2B_SENSITIVE_DATA *data)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)data);
+}
+
+#define unpack_TPM2B_SENSITIVE_DATA(ptr, data)  unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)data)
+
+inline BYTE* pack_TPM2B_PUBLIC_KEY_RSA(BYTE* ptr, const TPM2B_PUBLIC_KEY_RSA *rsa)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)rsa);
+}
+
+#define unpack_TPM2B_PUBLIC_KEY_RSA(ptr, rsa)   unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)rsa)
+
+inline BYTE* pack_TPM2B_PRIVATE(BYTE* ptr, const TPM2B_PRIVATE *Private)
+{
+    ptr = pack_UINT16(ptr, Private->size);
+    ptr = pack_TPM_BUFFER(ptr, Private->buffer, Private->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_PRIVATE(BYTE* ptr, TPM2B_PRIVATE *Private)
+{
+    ptr = unpack_UINT16(ptr, &Private->size);
+    ptr = unpack_BUFFER(ptr, Private->buffer, Private->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION_ARRAY(BYTE* ptr, const TPMS_PCR_SELECTION *sel, UINT32 count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+        ptr = pack_TPMI_ALG_HASH(ptr, &sel[i].hash);
+        ptr = pack_BYTE(ptr, sel[i].sizeofSelect);
+        ptr = pack_BUFFER(ptr, sel[i].pcrSelect, sel[i].sizeofSelect);
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_PCR_SELECTION_ARRAY(BYTE* ptr, TPMS_PCR_SELECTION *sel, UINT32 count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+        ptr = unpack_TPMI_ALG_HASH(ptr, &sel[i].hash);
+        ptr = unpack_BYTE(ptr, &sel[i].sizeofSelect);
+        ptr = unpack_BUFFER(ptr, sel[i].pcrSelect, sel[i].sizeofSelect);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPML_PCR_SELECTION(BYTE* ptr, const TPML_PCR_SELECTION *sel)
+{
+    ptr = pack_UINT32(ptr, sel->count);
+    ptr = pack_TPMS_PCR_SELECTION_ARRAY(ptr, sel->pcrSelections, sel->count);
+    return ptr;
+}
+
+inline BYTE* unpack_TPML_PCR_SELECTION(BYTE* ptr, TPML_PCR_SELECTION *sel)
+{
+    ptr = unpack_UINT32(ptr, &sel->count);
+    ptr = unpack_TPMS_PCR_SELECTION_ARRAY(ptr, sel->pcrSelections, sel->count);
+    return ptr;
+}
+
+inline BYTE* unpack_TPML_DIGEST(BYTE* ptr,TPML_DIGEST *digest)
+{
+    int i;
+    ptr = unpack_UINT32(ptr, &digest->count);
+    for (i=0;i<digest->count;i++)
+    {
+        ptr = unpack_TPM2B_DIGEST(ptr, &digest->digests[i]);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_CREATION_DATA(BYTE* ptr,const TPMS_CREATION_DATA *data)
+{
+    ptr = pack_TPML_PCR_SELECTION(ptr, &data->pcrSelect);
+    ptr = pack_TPM2B_DIGEST(ptr, &data->pcrDigest);
+    ptr = pack_TPMA_LOCALITY(ptr, &data->locality);
+    ptr = pack_TPM_ALG_ID(ptr, &data->parentNameAlg);
+    ptr = pack_TPM2B_NAME(ptr, &data->parentQualifiedName);
+    ptr = pack_TPM2B_DATA(ptr, &data->outsideInfo);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_CREATION_DATA(BYTE* ptr, TPMS_CREATION_DATA *data)
+{
+    ptr = unpack_TPML_PCR_SELECTION(ptr, &data->pcrSelect);
+    ptr = unpack_TPM2B_DIGEST(ptr, &data->pcrDigest);
+    ptr = unpack_TPMA_LOCALITY(ptr, &data->locality);
+    ptr = unpack_TPM_ALG_ID(ptr, &data->parentNameAlg);
+    ptr = unpack_TPM2B_NAME(ptr, &data->parentName);
+    ptr = unpack_TPM2B_NAME(ptr, &data->parentQualifiedName);
+    ptr = unpack_TPM2B_DATA(ptr, &data->outsideInfo);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_CREATION_DATA(BYTE* ptr, const TPM2B_CREATION_DATA *data )
+{
+    ptr = pack_UINT16(ptr, data->size);
+    ptr = pack_TPMS_CREATION_DATA(ptr, &data->creationData);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_CREATION_DATA(BYTE* ptr, TPM2B_CREATION_DATA * data)
+{
+    ptr = unpack_UINT16(ptr, &data->size);
+    ptr = unpack_TPMS_CREATION_DATA(ptr, &data->creationData);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_SENSITIVE_CREATE(BYTE* ptr, const TPMS_SENSITIVE_CREATE *create)
+{
+    ptr = pack_TPM2B_AUTH(ptr, &create->userAuth);
+    ptr = pack_TPM2B_SENSITIVE_DATA(ptr, &create->data);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_SENSITIVE_CREATE(BYTE* ptr, const TPM2B_SENSITIVE_CREATE *create)
+{
+    BYTE* sizePtr = ptr;
+    ptr += 2;
+    ptr = pack_TPMS_SENSITIVE_CREATE(ptr, &create->sensitive);
+    pack_UINT16(sizePtr, (UINT16)(ptr - sizePtr - 2));
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_SYM_MODE(BYTE* ptr, const TPMU_SYM_MODE *p,
+                                const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = pack_TPMI_ALG_SYM_MODE(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        case TPM2_ALG_XOR:
+        break;
+    default:
+        ptr = pack_TPMI_ALG_SYM_MODE(ptr, &p->sym);
+    }
+    return ptr;
+}
+inline BYTE* unpack_TPMU_SYM_MODE(BYTE* ptr, TPMU_SYM_MODE *p,
+                                  const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = unpack_TPMI_ALG_SYM_MODE(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+    case TPM2_ALG_XOR:
+        break;
+    default:
+        ptr = unpack_TPMI_ALG_SYM_MODE(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_SYM_KEY_BITS(BYTE* ptr, const TPMU_SYM_KEY_BITS *p,
+                                    const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = pack_TPMI_AES_KEY_BITS(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_XOR:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        ptr = pack_TPM_KEY_BITS(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMU_SYM_KEY_BITS(BYTE* ptr, TPMU_SYM_KEY_BITS *p,
+                                      const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = unpack_TPMI_AES_KEY_BITS(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_XOR:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        ptr = unpack_TPM_KEY_BITS(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_SYM_DEF_OBJECT(BYTE* ptr, const TPMT_SYM_DEF_OBJECT *p)
+{
+    ptr = pack_TPMI_ALG_SYM_OBJECT(ptr, &p->algorithm);
+    ptr = pack_TPMU_SYM_KEY_BITS(ptr, &p->keyBits, &p->algorithm);
+    ptr = pack_TPMU_SYM_MODE(ptr, &p->mode, &p->algorithm);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_SYM_DEF_OBJECT(BYTE *ptr, TPMT_SYM_DEF_OBJECT *p)
+{
+    ptr = unpack_TPMI_ALG_SYM_OBJECT(ptr, &p->algorithm);
+    ptr = unpack_TPMU_SYM_KEY_BITS(ptr, &p->keyBits, &p->algorithm);
+    ptr = unpack_TPMU_SYM_MODE(ptr, &p->mode, &p->algorithm);
+    return ptr;
+}
+
+#define pack_TPMS_SCHEME_OAEP(p, t)     pack_TPMI_ALG_HASH(p, &((t)->hashAlg))
+#define unpack_TPMS_SCHEME_OAEP(p, t)   unpack_TPMI_ALG_HASH(p, &((t)->hashAlg))
+
+inline BYTE* pack_TPMU_ASYM_SCHEME(BYTE *ptr, const TPMU_ASYM_SCHEME *p,
+                                   const TPMI_ALG_RSA_SCHEME *s)
+{
+    switch(*s) {
+#ifdef TPM2_ALG_RSASSA
+    case TPM2_ALG_RSASSA:
+        assert(false || "TPM2_ALG_RSASSA");
+        break;
+#endif
+#ifdef TPM2_ALG_OAEP
+    case TPM2_ALG_OAEP:
+        ptr = pack_TPMS_SCHEME_OAEP(ptr, &p->oaep);
+        break;
+#endif
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        assert(false || "DEFAULT");
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMU_ASYM_SCHEME(BYTE *ptr, TPMU_ASYM_SCHEME *p,
+                                     const TPMI_ALG_RSA_SCHEME *s)
+{
+    switch(*s) {
+    #ifdef TPM2_ALG_RSASSA
+    case TPM2_ALG_RSASSA:
+        printf("not support TPM_ALG_RSASSA\n");
+        assert(false);
+        break;
+    #endif
+    #ifdef TPM2_ALG_OAEP
+    case TPM2_ALG_OAEP:
+        ptr = unpack_TPMS_SCHEME_OAEP(ptr, &p->oaep);
+        break;
+    #endif
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        printf("default TPMI_ALG_RSA_SCHEME 0x%X\n", (UINT32)*s);
+        ptr = unpack_TPMI_ALG_HASH(ptr, &p->anySig.hashAlg);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_RSA_SCHEME(BYTE* ptr, const TPMT_RSA_SCHEME *p)
+{
+    ptr = pack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_RSA_SCHEME(BYTE* ptr, TPMT_RSA_SCHEME *p)
+{
+    ptr = unpack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = unpack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_RSA_DECRYPT(BYTE* ptr, const TPMT_RSA_DECRYPT *p)
+{
+    ptr = pack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_RSA_PARMS(BYTE* ptr, const TPMS_RSA_PARMS *p)
+{
+    ptr = pack_TPMT_SYM_DEF_OBJECT(ptr, &p->symmetric);
+    ptr = pack_TPMT_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMI_RSA_KEY_BITS(ptr, &p->keyBits);
+    ptr = pack_UINT32(ptr, p->exponent);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_RSA_PARMS(BYTE *ptr, TPMS_RSA_PARMS *p)
+{
+    ptr = unpack_TPMT_SYM_DEF_OBJECT(ptr, &p->symmetric);
+    ptr = unpack_TPMT_RSA_SCHEME(ptr, &p->scheme);
+    ptr = unpack_TPMI_RSA_KEY_BITS(ptr, &p->keyBits);
+    ptr = unpack_UINT32(ptr, &p->exponent);
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_PUBLIC_PARMS(BYTE* ptr, const TPMU_PUBLIC_PARMS *param,
+                                    const TPMI_ALG_PUBLIC *selector)
+{
+    switch(*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        assert(false);
+    case TPM2_ALG_SYMCIPHER:
+        assert(false);
+    case TPM2_ALG_RSA:
+        return pack_TPMS_RSA_PARMS(ptr, &param->rsaDetail);
+    case TPM2_ALG_ECC:
+        assert(false);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* unpack_TPMU_PUBLIC_PARMS(BYTE* ptr, TPMU_PUBLIC_PARMS *param,
+                                      const TPMI_ALG_PUBLIC *selector)
+{
+    switch(*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        assert(false);
+    case TPM2_ALG_SYMCIPHER:
+        assert(false);
+    case TPM2_ALG_RSA:
+        return unpack_TPMS_RSA_PARMS(ptr, &param->rsaDetail);
+    case TPM2_ALG_ECC:
+        assert(false);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* pack_TPMS_ECC_POINT(BYTE* ptr, const TPMS_ECC_POINT *point)
+{
+    assert(false);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_ECC_POINT(BYTE* ptr, TPMS_ECC_POINT *point)
+{
+    assert(false);
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_PUBLIC_ID(BYTE* ptr, const TPMU_PUBLIC_ID *id,
+                                 const TPMI_ALG_PUBLIC *selector)
+{
+    switch (*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        return pack_TPM2B_DIGEST(ptr, &id->keyedHash);
+    case TPM2_ALG_SYMCIPHER:
+        return pack_TPM2B_DIGEST(ptr, &id->sym);
+    case TPM2_ALG_RSA:
+        return pack_TPM2B_PUBLIC_KEY_RSA(ptr, &id->rsa);
+    case TPM2_ALG_ECC:
+        return pack_TPMS_ECC_POINT(ptr, &id->ecc);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* unpack_TPMU_PUBLIC_ID(BYTE* ptr, TPMU_PUBLIC_ID *id, TPMI_ALG_PUBLIC *selector)
+{
+    switch (*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        return unpack_TPM2B_DIGEST(ptr, &id->keyedHash);
+    case TPM2_ALG_SYMCIPHER:
+        return unpack_TPM2B_DIGEST(ptr, &id->sym);
+    case TPM2_ALG_RSA:
+        return unpack_TPM2B_PUBLIC_KEY_RSA(ptr, &id->rsa);
+    case TPM2_ALG_ECC:
+        return unpack_TPMS_ECC_POINT(ptr, &id->ecc);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* pack_TPMT_PUBLIC(BYTE* ptr, const TPMT_PUBLIC *public)
+{
+    ptr = pack_TPMI_ALG_PUBLIC(ptr, &public->type);
+    ptr = pack_TPMI_ALG_HASH(ptr, &public->nameAlg);
+    ptr = pack_TPMA_OBJECT(ptr, &public->objectAttributes);
+    ptr = pack_TPM2B_DIGEST(ptr, &public->authPolicy);
+    ptr = pack_TPMU_PUBLIC_PARMS(ptr, &public->parameters, &public->type);
+    ptr = pack_TPMU_PUBLIC_ID(ptr, &public->unique, &public->type);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_PUBLIC(BYTE* ptr, TPMT_PUBLIC *public)
+{
+    ptr = unpack_TPMI_ALG_PUBLIC(ptr, &public->type);
+    ptr = unpack_TPMI_ALG_HASH(ptr, &public->nameAlg);
+    ptr = unpack_TPMA_OBJECT(ptr, &public->objectAttributes);
+    ptr = unpack_TPM2B_DIGEST(ptr, &public->authPolicy);
+    ptr = unpack_TPMU_PUBLIC_PARMS(ptr, &public->parameters, &public->type);
+    ptr = unpack_TPMU_PUBLIC_ID(ptr, &public->unique, &public->type);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_PUBLIC(BYTE* ptr, const TPM2B_PUBLIC *public)
+{
+    BYTE *sizePtr = ptr;
+    ptr += 2;
+    ptr = pack_TPMT_PUBLIC(ptr, &public->publicArea);
+    pack_UINT16(sizePtr, (UINT16)(ptr - sizePtr - 2));
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_PUBLIC(BYTE* ptr, TPM2B_PUBLIC *public)
+{
+    ptr = unpack_UINT16(ptr, &public->size);
+    ptr = unpack_TPMT_PUBLIC(ptr, &public->publicArea);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION(BYTE* ptr, const TPMS_PCR_SELECTION *selection)
+{
+    ptr = pack_TPMI_ALG_HASH(ptr, &selection->hash);
+    ptr = pack_BYTE(ptr, selection->sizeofSelect);
+    ptr = pack_BYTE_ARRAY(ptr, selection->pcrSelect, selection->sizeofSelect);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION_Array(BYTE* ptr, const TPMS_PCR_SELECTION *selections,
+                                           const UINT32 cnt)
+{
+    int i;
+    for (i = 0; i < cnt; i++)
+        ptr = pack_TPMS_PCR_SELECTION(ptr, selections + i);
+    return ptr;
+}
+
+inline BYTE* pack_TPM_AuthArea(BYTE* ptr, const TPM_AuthArea *auth)
+{
+    BYTE* sizePtr = ptr;
+    ptr += sizeof(UINT32);
+    ptr = pack_TPM_RH(ptr, &auth->sessionHandle);
+    ptr = pack_TPM2B_NONCE(ptr, &auth->nonce);
+    ptr = pack_TPMA_SESSION(ptr, &auth->sessionAttributes);
+    ptr = pack_TPM2B_AUTH(ptr, &auth->auth);
+    pack_UINT32(sizePtr, ptr - sizePtr - sizeof(UINT32));
+    return ptr;
+}
+
+inline BYTE* unpack_TPM_AuthArea(BYTE* ptr, TPM_AuthArea *auth)
+{
+    ptr = unpack_UINT32(ptr, &auth->size);
+    ptr = unpack_TPM_RH(ptr, &auth->sessionHandle);
+    ptr = unpack_TPM2B_NONCE(ptr, &auth->nonce);
+    ptr = unpack_TPMA_SESSION(ptr, &auth->sessionAttributes);
+    ptr = unpack_TPM2B_AUTH(ptr, &auth->auth);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2_RSA_KEY(BYTE* ptr, const TPM2_RSA_KEY *key)
+{
+    ptr = pack_TPM2B_PRIVATE(ptr, &key->Private);
+    ptr = pack_TPM2B_PUBLIC(ptr, &key->Public);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2_RSA_KEY(BYTE* ptr, TPM2_RSA_KEY *key)
+{
+    ptr = unpack_TPM2B_PRIVATE(ptr, &key->Private);
+    ptr = unpack_TPM2B_PUBLIC(ptr, &key->Public);
+    return ptr;
+}
+#endif
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzR-0001mi-8D; Wed, 31 Dec 2014 09:54:53 +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 1Y6FzO-0001lR-Ty
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:51 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	B0/D7-05632-AE7C3A45; Wed, 31 Dec 2014 09:54:50 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1420019687!16604833!2
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2906 invoked from network); 31 Dec 2014 09:54:49 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-3.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:49 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by orsmga103.jf.intel.com with ESMTP; 31 Dec 2014 01:51:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="655296195"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 31 Dec 2014 01:54:47 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:58 -0500
Message-Id: <1420005058-25779-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 08/14] vTPM/TPM2: Add main entrance
	vtpmmgr2_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

Accept commands from the vtpm-stubdom domains via the mini-os TPM
backend driver. The vTPM manager communicates directly with hardware
TPM 2.0 using the mini-os tpm2_tis driver.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/init.c    | 109 ++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.h |   1 +
 2 files changed, 110 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 8244bb0..7e115a5 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -681,3 +681,112 @@ egress:
     vtpmloginfo(VTPM_LOG_VTPM, "Finished initialized new VTPM manager\n");
     return status;
 }
+
+static int tpm2_entropy_source(void* dummy, unsigned char* data,
+                               size_t len, size_t* olen)
+{
+    UINT32 sz = len;
+    TPM_RESULT rc = TPM2_GetRandom(&sz, data);
+    *olen = sz;
+    return rc == TPM_SUCCESS ? 0 : POLARSSL_ERR_ENTROPY_SOURCE_FAILED;
+}
+
+/*TPM 2.0 Objects flush */
+static TPM_RC flush_tpm2(void)
+{
+    int i;
+
+    for (i = TRANSIENT_FIRST; i < TRANSIENT_LAST; i++)
+         TPM2_FlushContext(i);
+
+    return TPM_SUCCESS;
+}
+
+TPM_RESULT vtpmmgr2_init(int argc, char** argv)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+
+    /* Default commandline options */
+    struct Opts opts = {
+        .tpmdriver = TPMDRV_TPM_TIS,
+        .tpmiomem = TPM_BASEADDR,
+        .tpmirq = 0,
+        .tpmlocality = 0,
+        .gen_owner_auth = 0,
+    };
+
+    if (parse_cmdline_opts(argc, argv, &opts) != 0) {
+        vtpmlogerror(VTPM_LOG_VTPM, "Command line parsing failed! exiting..\n");
+        status = TPM_BAD_PARAMETER;
+        goto abort_egress;
+    }
+
+    /*Setup storage system*/
+    if (vtpm_storage_init() != 0) {
+        vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize storage subsystem!\n");
+        status = TPM_IOERROR;
+        goto abort_egress;
+    }
+
+    /*Setup tpmback device*/
+    init_tpmback(set_opaque, free_opaque);
+
+    /*Setup tpm access*/
+    switch(opts.tpmdriver) {
+        case TPMDRV_TPM_TIS:
+        {
+            struct tpm_chip* tpm;
+            if ((tpm = init_tpm2_tis(opts.tpmiomem, TPM_TIS_LOCL_INT_TO_FLAG(opts.tpmlocality),
+                                     opts.tpmirq)) == NULL) {
+                vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize tpmfront device\n");
+                status = TPM_IOERROR;
+                goto abort_egress;
+            }
+            printk("init_tpm2_tis()       ...ok\n");
+            vtpm_globals.tpm_fd = tpm_tis_open(tpm);
+            tpm_tis_request_locality(tpm, opts.tpmlocality);
+        }
+        break;
+        case TPMDRV_TPMFRONT:
+        {
+            struct tpmfront_dev* tpmfront_dev;
+            if ((tpmfront_dev = init_tpmfront(NULL)) == NULL) {
+                vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize tpmfront device\n");
+                status = TPM_IOERROR;
+                goto abort_egress;
+            }
+            vtpm_globals.tpm_fd = tpmfront_open(tpmfront_dev);
+        }
+        break;
+    }
+    printk("TPM 2.0 access ...ok\n");
+    /* Blow away all stale handles left in the tpm*/
+    if (flush_tpm2() != TPM_SUCCESS) {
+        vtpmlogerror(VTPM_LOG_VTPM, "VTPM_FlushResources failed, continuing anyway..\n");
+    }
+
+    /* Initialize the rng */
+    entropy_init(&vtpm_globals.entropy);
+    entropy_add_source(&vtpm_globals.entropy, tpm2_entropy_source, NULL, 0);
+    entropy_gather(&vtpm_globals.entropy);
+    ctr_drbg_init(&vtpm_globals.ctr_drbg, entropy_func, &vtpm_globals.entropy, NULL, 0);
+    ctr_drbg_set_prediction_resistance( &vtpm_globals.ctr_drbg, CTR_DRBG_PR_OFF );
+
+    /* Generate Auth for Owner*/
+    if (opts.gen_owner_auth) {
+        vtpmmgr_rand(vtpm_globals.owner_auth, sizeof(TPM_AUTHDATA));
+    }
+
+    /* Load the Manager data, if it fails create a new manager */
+    if (vtpm_load_disk()) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Assuming first time initialization.\n");
+        TPMTRYRETURN(vtpmmgr2_create());
+    }
+
+    goto egress;
+
+abort_egress:
+    vtpmmgr_shutdown();
+egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 9889feb..c479443 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -96,5 +96,6 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 /* TPM 2.0 */
 TPM_RC tpm2_take_ownership(void);
 TPM_RESULT vtpmmgr2_create(void);
+TPM_RESULT vtpmmgr2_init(int argc, char** argv);
 
 #endif
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6Fz9-0001fI-JU; Wed, 31 Dec 2014 09:54:35 +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 1Y6Fz8-0001ez-8b
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:34 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	E7/05-25547-9D7C3A45; Wed, 31 Dec 2014 09:54:33 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1420019672!16589177!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21834 invoked from network); 31 Dec 2014 09:54:32 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-7.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:32 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 31 Dec 2014 01:50:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="644906740"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 31 Dec 2014 01:54:30 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:42 -0500
Message-Id: <1420005042-25590-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 03/14] vTPM/TPM2: Add global data in
	vtpm_globals{}
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 data is for the Mini-os to access TPM 2.0 hardware.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/vtpmmgr.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 2d9d153..0d0c604 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -44,6 +44,7 @@
 #include "uuid.h"
 #include "tcg.h"
 #include "vtpm_manager.h"
+#include "tpm2_types.h"
 
 #define RSA_KEY_SIZE 0x0800
 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8)
@@ -59,6 +60,14 @@ struct vtpm_globals {
    ctr_drbg_context    ctr_drbg;
 
    int hw_locality;
+
+    /* TPM 2.0 */
+    TPM_AuthArea       pw_auth;
+    TPM_AuthArea       srk_auth_area;
+    TPM_HANDLE         srk_handle;
+    TPM_HANDLE         sk_handle;
+    TPM2B_NAME         sk_name;
+    TPM2_RSA_KEY       tpm2_storage_key;
 };
 
 struct tpm_opaque {
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzD-0001gM-Dk; Wed, 31 Dec 2014 09:54:39 +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 1Y6FzC-0001g6-G5
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:38 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	EF/75-27623-DD7C3A45; Wed, 31 Dec 2014 09:54:37 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1420019675!16493359!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 15419 invoked from network); 31 Dec 2014 09:54:36 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:36 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by fmsmga101.fm.intel.com with ESMTP; 31 Dec 2014 01:54:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="662824605"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 31 Dec 2014 01:54:33 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:44 -0500
Message-Id: <1420005044-25627-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 04/14] vTPM/TPM2: Add TPM 2.0 Exposed APIs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 TPM 2.0 Exposed APIs for the Mini-os to access TPM 2.0
hardware.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/Makefile |   2 +-
 stubdom/vtpmmgr/tpm2.c   | 455 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2.h   | 104 +++++++++++
 3 files changed, 560 insertions(+), 1 deletion(-)
 create mode 100644 stubdom/vtpmmgr/tpm2.c
 create mode 100644 stubdom/vtpmmgr/tpm2.h

diff --git a/stubdom/vtpmmgr/Makefile b/stubdom/vtpmmgr/Makefile
index c5e17c5..6dae034 100644
--- a/stubdom/vtpmmgr/Makefile
+++ b/stubdom/vtpmmgr/Makefile
@@ -12,7 +12,7 @@
 XEN_ROOT=../..
 
 TARGET=vtpmmgr.a
-OBJS=vtpmmgr.o vtpm_cmd_handler.o init.o tpmrsa.o tpm.o log.o
+OBJS=vtpmmgr.o vtpm_cmd_handler.o init.o tpmrsa.o tpm.o tpm2.o log.o
 OBJS += vtpm_disk.o disk_tpm.o disk_io.o disk_crypto.o disk_read.o disk_write.o
 OBJS += mgmt_authority.o
 
diff --git a/stubdom/vtpmmgr/tpm2.c b/stubdom/vtpmmgr/tpm2.c
new file mode 100644
index 0000000..1903e27
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2.c
@@ -0,0 +1,455 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005/2006, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#include <stdio.h>
+#include <string.h>
+#include <malloc.h>
+#include <unistd.h>
+#include <errno.h>
+#include <polarssl/sha1.h>
+
+#include "tcg.h"
+#include "tpm.h"
+#include "tpm2.h"
+#include "log.h"
+#include "marshal.h"
+#include "tpm2_marshal.h"
+#include "tpmrsa.h"
+#include "vtpmmgr.h"
+
+#define TCPA_MAX_BUFFER_LENGTH 0x2000
+#define TPM_BEGIN(TAG, ORD) \
+    const TPM_TAG intag = TAG;\
+    TPM_TAG tag = intag;\
+    UINT32 paramSize;\
+    const TPM_COMMAND_CODE ordinal = ORD;\
+    TPM_RESULT status = TPM_SUCCESS;\
+    BYTE in_buf[TCPA_MAX_BUFFER_LENGTH];\
+    BYTE out_buf[TCPA_MAX_BUFFER_LENGTH];\
+    UINT32 out_len = sizeof(out_buf);\
+    BYTE* ptr = in_buf;\
+    /*Print a log message */\
+    vtpmloginfo(VTPM_LOG_TPM, "%s\n", __func__);\
+    /* Pack the header*/\
+    ptr = pack_TPM_TAG(ptr, tag);\
+    ptr += sizeof(UINT32);\
+    ptr = pack_TPM_COMMAND_CODE(ptr, ordinal)\
+
+#define TPM_AUTH_BEGIN() \
+    sha1_context sha1_ctx;\
+    BYTE* authbase = ptr - sizeof(TPM_COMMAND_CODE);\
+    TPM_DIGEST paramDigest;\
+    sha1_starts(&sha1_ctx)
+
+#define TPM_AUTH1_GEN(HMACkey, auth) do {\
+    sha1_finish(&sha1_ctx, paramDigest.digest);\
+    generateAuth(&paramDigest, HMACkey, auth);\
+    ptr = pack_TPM_AUTH_SESSION(ptr, auth);\
+} while(0)
+
+#define TPM_AUTH2_GEN(HMACkey, auth) do {\
+    generateAuth(&paramDigest, HMACkey, auth);\
+    ptr = pack_TPM_AUTH_SESSION(ptr, auth);\
+} while(0)
+
+#define TPM_TRANSMIT() do {\
+    /* Pack the command size */\
+    paramSize = ptr - in_buf;\
+    pack_UINT32(in_buf + sizeof(TPM_TAG), paramSize);\
+    if ((status = TPM_TransmitData(in_buf, paramSize, out_buf, &out_len)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH_VERIFY_BEGIN() do {\
+    UINT32 buf[2] = { cpu_to_be32(status), cpu_to_be32(ordinal) };\
+    sha1_starts(&sha1_ctx);\
+    sha1_update(&sha1_ctx, (unsigned char*)buf, sizeof(buf));\
+    authbase = ptr;\
+} while(0)
+
+#define TPM_AUTH1_VERIFY(HMACkey, auth) do {\
+    sha1_finish(&sha1_ctx, paramDigest.digest);\
+    ptr = unpack_TPM_AUTH_SESSION(ptr, auth);\
+    if ((status = verifyAuth(&paramDigest, HMACkey, auth)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH2_VERIFY(HMACkey, auth) do {\
+    ptr = unpack_TPM_AUTH_SESSION(ptr, auth);\
+    if ((status = verifyAuth(&paramDigest, HMACkey, auth)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_UNPACK_VERIFY() do { \
+    ptr = out_buf;\
+    ptr = unpack_TPM_RSP_HEADER(ptr, \
+          &(tag), &(paramSize), &(status));\
+    if ((status) != TPM_SUCCESS){ \
+        vtpmlogerror(VTPM_LOG_TPM, "Failed with return code %s\n", tpm_get_error_name(status));\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH_HASH() do {\
+    sha1_update(&sha1_ctx, authbase, ptr - authbase);\
+    authbase = ptr;\
+} while(0)
+
+#define TPM_AUTH_SKIP() do {\
+    authbase = ptr;\
+} while(0)
+
+TPM_RC TPM2_PCR_Read(TPML_PCR_SELECTION pcrSelectionIn,
+                     UINT32 *pcrUpdateCounter,
+                     TPML_PCR_SELECTION *pcrSelectionOut,
+                     TPML_DIGEST *pcrValues)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS,TPM_CC_PCR_Read);
+
+    /*pack in*/
+    ptr =  pack_TPML_PCR_SELECTION(ptr, &pcrSelectionIn);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    /*unpack out*/
+    ptr = unpack_UINT32(ptr, pcrUpdateCounter);
+    ptr = unpack_TPML_PCR_SELECTION(ptr, pcrSelectionOut);
+    ptr = unpack_TPML_DIGEST(ptr, pcrValues);
+
+    goto egress;
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_Load(TPMI_DH_OBJECT parentHandle,
+                 TPM2B_PRIVATE *inPrivate, /* in */
+                 TPM2B_PUBLIC *inPublic, /* in */
+                 TPM_HANDLE *objectHandle, /* out */
+                 TPM2B_NAME *name /* out */)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Load);
+
+    /* pack handle of parent for new object */
+    ptr =  pack_UINT32(ptr, parentHandle);
+
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+    ptr = pack_TPM2B_PRIVATE(ptr, inPrivate);
+    ptr = pack_TPM2B_PUBLIC(ptr, inPublic);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    if (objectHandle != NULL) {
+        ptr = unpack_TPM_HANDLE(ptr, objectHandle);
+    } else {
+        TPM_HANDLE tmp;
+        ptr = unpack_TPM_HANDLE(ptr, &tmp);
+    }
+
+    if (name != NULL)
+        ptr = unpack_TPM2B_NAME(ptr, name);
+    goto egress;
+
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_Create(TPMI_DH_OBJECT parentHandle,
+                   TPM2_Create_Params_in *in,
+                   TPM2_Create_Params_out *out)
+{
+    UINT32 param_size;
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Create);
+
+    /* pack handle of parent for new object */
+    ptr =  pack_UINT32(ptr, parentHandle);
+
+    /* pack Auth Area */
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+
+    /* pack inSensitive */
+    ptr = pack_TPM2B_SENSITIVE_CREATE(ptr, &in->inSensitive);
+
+    /* pack inPublic */
+    ptr = pack_TPM2B_PUBLIC(ptr, &in->inPublic);
+
+    /* pack outside Info */
+    ptr = pack_TPM2B_DATA(ptr, &in->outsideInfo);
+
+    /* pack createPCR */
+    ptr = pack_TPML_PCR_SELECTION(ptr, &in->creationPCR);
+
+    /* Send the command to the tpm */
+    TPM_TRANSMIT();
+
+    /* Unpack and validate the header */
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT32(ptr, &param_size);
+    if (out != NULL) {
+        ptr = unpack_TPM2B_PRIVATE(ptr, &vtpm_globals.tpm2_storage_key.Private);
+        ptr = unpack_TPM2B_PUBLIC(ptr, &vtpm_globals.tpm2_storage_key.Public);
+        ptr = unpack_TPM2B_CREATION_DATA(ptr, &out->creationData);
+        ptr = unpack_TPM2B_DIGEST(ptr, &out->creationHash);
+        ptr = unpack_TPMT_TK_CREATION(ptr, &out->creationTicket);
+    } else {
+           ptr += param_size;
+    }
+    goto egress;
+
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_CreatePrimary(TPMI_RH_HIERARCHY primaryHandle,
+                          TPM2_Create_Params_in *in,
+                          TPM_HANDLE *objHandle,
+                          TPM2_Create_Params_out *out)
+{
+    UINT32 param_size;
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_CreatePrimary);
+
+    /* pack primary handle */
+    ptr = pack_UINT32(ptr, primaryHandle);
+
+    /* pack Auth Area */
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+
+    /* pack inSenstive */
+    ptr = pack_TPM2B_SENSITIVE_CREATE(ptr, &in->inSensitive);
+
+    /* pack inPublic */
+    ptr = pack_TPM2B_PUBLIC(ptr, &in->inPublic);
+
+    /* pack outsideInfo */
+    ptr = pack_TPM2B_DATA(ptr, &in->outsideInfo);
+
+    /* pack creationPCR */
+    ptr = pack_TPML_PCR_SELECTION(ptr, &in->creationPCR);
+
+    /* Send the command to the tpm */
+    TPM_TRANSMIT();
+
+    /* Unpack and validate the header */
+    TPM_UNPACK_VERIFY();
+
+    if (objHandle != NULL)
+        ptr = unpack_TPM_HANDLE(ptr, objHandle);
+    else {
+        TPM_HANDLE handle;
+        ptr = unpack_TPM_HANDLE(ptr, &handle);
+    }
+    ptr = unpack_UINT32(ptr, &param_size);
+
+    if (out != NULL) {
+        ptr = unpack_TPM2B_PUBLIC(ptr, &out->outPublic);
+        ptr = unpack_TPM2B_CREATION_DATA(ptr, &out->creationData);
+        ptr = unpack_TPM2B_DIGEST(ptr, &out->creationHash);
+        ptr = unpack_TPMT_TK_CREATION(ptr, &out->creationTicket);
+    } else {
+        ptr += param_size;
+    }
+
+goto egress;
+
+abort_egress:
+egress:
+   return status;
+}
+
+TPM_RC TPM2_HierachyChangeAuth(TPMI_RH_HIERARCHY_AUTH authHandle, TPM2B_AUTH *newAuth)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_HierarchyChangeAuth);
+    ptr = pack_UINT32(ptr, authHandle);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+    ptr = pack_TPM2B_AUTH(ptr, newAuth);
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_RSA_ENCRYPT(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *message,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *outData)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_RSA_Encrypt);
+
+    ptr = pack_UINT32(ptr, keyHandle);
+    ptr = pack_TPM2B_PUBLIC_KEY_RSA(ptr, message);
+    ptr = pack_TPMT_RSA_DECRYPT(ptr, inScheme);
+    ptr = pack_TPM2B_DATA(ptr, label);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    if (outData != NULL)
+        unpack_TPM2B_PUBLIC_KEY_RSA(ptr, outData);
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_Bind(TPMI_DH_OBJECT keyHandle,
+                 void *buf,
+                 UINT32 len,
+                 void *out)
+{
+    TPM_RC status = TPM_SUCCESS;
+    TPM2B_PUBLIC_KEY_RSA message;
+    TPMT_RSA_DECRYPT inScheme;
+    TPM2B_DATA label;
+    TPM2B_PUBLIC_KEY_RSA outData;
+
+    message.size = len;
+    memcpy(message.buffer, buf, len);
+    inScheme.scheme = TPM2_ALG_NULL;
+    label.size = 0;
+    TPMTRYRETURN(TPM2_RSA_ENCRYPT(keyHandle, &message, &inScheme, &label, &outData));
+    memcpy(out, outData.buffer, outData.size);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_RSA_Decrypt(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *cipherText,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *message)
+{
+    UINT32 param_size;
+
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_RSA_Decrypt);
+    ptr = pack_UINT32(ptr, keyHandle);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+    ptr = pack_TPM2B_PUBLIC_KEY_RSA(ptr, cipherText);
+    ptr = pack_TPMT_RSA_DECRYPT(ptr, inScheme);
+    ptr = pack_TPM2B_DATA(ptr, label);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT32(ptr, &param_size);
+
+    if (message)
+        ptr = unpack_TPM2B_PUBLIC_KEY_RSA(ptr, message);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_UnBind(TPMI_DH_OBJECT keyHandle,
+                   UINT32 ilen,
+                   void *in,
+                   UINT32 *olen,
+                   void *out)
+{
+    UINT32 status;
+    TPM2B_PUBLIC_KEY_RSA cipher, message;
+    TPMT_RSA_DECRYPT inScheme;
+    TPM2B_DATA label;
+
+    cipher.size = ilen;
+    memcpy(cipher.buffer, in, ilen);
+    inScheme.scheme = TPM2_ALG_NULL;
+    label.size = 0;
+
+    TPMTRYRETURN(TPM2_RSA_Decrypt(keyHandle, &cipher, &inScheme, &label, &message));
+
+    *olen = message.size;
+    memcpy(out, message.buffer, *olen);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_CLEAR(void)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Clear);
+
+    ptr = pack_UINT32(ptr, TPM_RH_PLATFORM);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_GetRandom(UINT32 * bytesRequested, BYTE * randomBytes)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_GetRandom);
+
+    ptr = pack_UINT16(ptr, (UINT16)*bytesRequested);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT16(ptr, (UINT16 *)bytesRequested);
+    ptr = unpack_TPM_BUFFER(ptr, randomBytes, *bytesRequested);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_FlushContext(TPMI_DH_CONTEXT flushHandle)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_FlushContext);
+
+    ptr = pack_UINT32(ptr, flushHandle);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/tpm2.h b/stubdom/vtpmmgr/tpm2.h
new file mode 100644
index 0000000..9f597ee
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2.h
@@ -0,0 +1,104 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005/2006, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef __TPM2_H__
+#define __TPM2_H__
+
+#include "tcg.h"
+#include "tpm2_types.h"
+
+// ------------------------------------------------------------------
+// TPM 2.0 Exposed API
+// ------------------------------------------------------------------
+
+TPM_RC TPM2_PCR_Read(TPML_PCR_SELECTION pcrSelectionIn,
+                     UINT32 *pcrUpdateCounter,
+                     TPML_PCR_SELECTION *pcrSelectionOut,
+                     TPML_DIGEST *pcrValues);
+
+TPM_RC TPM2_Load(TPMI_DH_OBJECT parentHandle,
+                 TPM2B_PRIVATE *inPrivate,
+                 TPM2B_PUBLIC *inPublic,
+                 TPM_HANDLE *objectHandle,
+                 TPM2B_NAME *name);
+
+TPM_RC TPM2_Create(TPMI_DH_OBJECT parentHandle,
+                   TPM2_Create_Params_in *in,
+                   TPM2_Create_Params_out *out);
+
+TPM_RC TPM2_CreatePrimary(TPMI_RH_HIERARCHY primaryHandle,
+                          TPM2_Create_Params_in *objHandle,
+                          TPM_HANDLE *in,
+                          TPM2_Create_Params_out *out);
+
+TPM_RC TPM2_HierachyChangeAuth(TPMI_RH_HIERARCHY_AUTH authHandle,
+                               TPM2B_AUTH *newAuth);
+
+TPM_RC TPM2_RSA_ENCRYPT(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *message,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *outData);
+
+TPM_RC TPM2_Bind(TPMI_DH_OBJECT keyHandle,
+                 void *buf,
+                 UINT32 len,
+                 void *out);
+
+TPM_RC TPM2_RSA_Decrypt(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *cipherText,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *message);
+
+TPM_RC TPM2_UnBind(TPMI_DH_OBJECT keyHandle,
+                   UINT32 ilen,
+                   void *in,
+                   UINT32 *olen,
+                   void *out);
+
+TPM_RESULT TPM2_GetRandom(UINT32* bytesRequested,
+                          BYTE* randomBytes);
+
+TPM_RC TPM2_CLEAR(void);
+
+TPM_RC TPM2_FlushContext(TPMI_DH_CONTEXT);
+#endif //TPM2_H
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzJ-0001jS-El; Wed, 31 Dec 2014 09:54:45 +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 1Y6FzI-0001id-1o
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:44 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	D9/66-07724-3E7C3A45; Wed, 31 Dec 2014 09:54:43 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1420019682!16534971!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 13639 invoked from network); 31 Dec 2014 09:54:42 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-4.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:42 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by orsmga102.jf.intel.com with ESMTP; 31 Dec 2014 01:52:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="435269258"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 31 Dec 2014 01:42:40 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:51 -0500
Message-Id: <1420005051-25703-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
MIME-Version: 1.0
Content-Length: 6274
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 06/14] vTPM/TPM2: Create and load SK on TPM
	2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VFBNMl9DcmVhdGUgaXMgdXNlZCB0byBjcmVhdGUgYW4gb2JqZWN0IHRoYXQgY2FuIGJlIGxvYWRl
ZCBpbnRvIGEKVFBNIHVzaW5nIFRQTTJfTG9hZCgpLiBJZiB0aGUgY29tbWFuZCBjb21wbGV0ZXMg
c3VjY2Vzc2Z1bGx5LCB0aGUKVFBNIHdpbGwgY3JlYXRlIHRoZSBuZXcgb2JqZWN0IGFuZCByZXR1
cm4gdGhlIG9iamVjdOKAmXMgY3JlYXRpb24uCmRhdGEgKGNyZWF0aW9uRGF0YSksIGl0cyBwdWJs
aWMgYXJlYSAob3V0UHVibGljKSwgYW5kIGl0cyBlbmNyeXB0ZWQKc2Vuc2l0aXZlIGFyZWEgKG91
dFByaXZhdGUpLiBQcmVzZXJ2YXRpb24gb2YgdGhlIHJldHVybmVkIGRhdGEgaXMKdGhlIHJlc3Bv
bnNpYmlsaXR5IG9mIHRoZSBjYWxsZXIuIFRoZSBvYmplY3Qgd2lsbCBuZWVkIHRvIGJlIGxvYWRl
ZAooVFBNMl9Mb2FkKCkpLgpUUE0yX0xvYWQgaXMgdXNlZCB0byBsb2FkIG9iamVjdHMgaW50byB0
aGUgVFBNLiBUaGlzIGNvbW1hbmQgaXMgdXNlZAp3aGVuIGJvdGggYSBUUE0yQl9QVUJMSUMgYW5k
IFRQTTJCX1BSSVZBVEUgYXJlIHRvIGJlIGxvYWRlZC4gSWYgb25seQphIFRQTTJCX1BVQkxJQyBp
cyB0byBiZSBsb2FkZWQsIHRoZSBUUE0yX0xvYWRFeHRlcm5hbCBjb21tYW5kIGlzIHVzZWQuCgpT
aWduZWQtb2ZmLWJ5OiBRdWFuIFh1IDxxdWFuLnh1QGludGVsLmNvbT4KLS0tCiBzdHViZG9tL3Z0
cG1tZ3IvaW5pdC5jICAgIHwgMTAxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysKIHN0dWJkb20vdnRwbW1nci92dHBtbWdyLmggfCAgIDEgKwogMiBmaWxlcyBj
aGFuZ2VkLCAxMDIgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3N0dWJkb20vdnRwbW1nci9p
bml0LmMgYi9zdHViZG9tL3Z0cG1tZ3IvaW5pdC5jCmluZGV4IGM2NTQwNzEuLjgyNDRiYjAgMTAw
NjQ0Ci0tLSBhL3N0dWJkb20vdnRwbW1nci9pbml0LmMKKysrIGIvc3R1YmRvbS92dHBtbWdyL2lu
aXQuYwpAQCAtNTgwLDMgKzU4MCwxMDQgQEAgVFBNX1JDIHRwbTJfdGFrZV9vd25lcnNoaXAodm9p
ZCkKIGFib3J0X2VncmVzczoKICAgICByZXR1cm4gc3RhdHVzOwogfQorCitUUE1fUkVTVUxUIHZ0
cG1tZ3IyX2NyZWF0ZSh2b2lkKQoreworICAgIFRQTV9SRVNVTFQgc3RhdHVzID0gVFBNX1NVQ0NF
U1M7CisKKyAgICBUUE1UUllSRVRVUk4odHBtMl90YWtlX293bmVyc2hpcCgpKTsKKworICAgLyog
Y3JlYXRlIFNLICovCisgICAgVFBNMl9DcmVhdGVfUGFyYW1zX291dCBvdXQ7CisgICAgVFBNMl9D
cmVhdGVfUGFyYW1zX2luIGluID0geworICAgICAgICAuaW5TZW5zaXRpdmUgPSB7CisgICAgICAg
ICAgICAuc2l6ZSA9IDQgKyAyMCwKKyAgICAgICAgICAgIC5zZW5zaXRpdmUgPSB7CisgICAgICAg
ICAgICAgICAgLnVzZXJBdXRoLnNpemUgPSAyMCwKKyAgICAgICAgICAgICAgICAudXNlckF1dGgu
YnVmZmVyID0geyAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLFwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwIH0sCisg
ICAgICAgICAgICAgICAgLmRhdGEuc2l6ZSA9IDAsCisgICAgICAgICAgICB9LAorICAgICAgICB9
LAorICAgICAgICAuaW5QdWJsaWMgPSB7CisgICAgICAgICAgICAuc2l6ZSA9ICg2MCksCisgICAg
ICAgICAgICAucHVibGljQXJlYSA9IHsKKyAgICAgICAgICAgICAgICAgLnR5cGUgPSBUUE0yX0FM
R19SU0EsCisgICAgICAgICAgICAgICAgIC5uYW1lQWxnID0gVFBNMl9BTEdfU0hBMjU2LAorI2Rl
ZmluZSBTS19PQkpfQVRUUiAoZml4ZWRUUE0gfCBmaXhlZFBhcmVudCB8IHVzZXJXaXRoQXV0aCB8
XAorICAgICAgICAgICAgICAgICAgICAgc2Vuc2l0aXZlRGF0YU9yaWdpbiB8ZGVjcnlwdCkKKyAg
ICAgICAgICAgICAgICAgLm9iamVjdEF0dHJpYnV0ZXMgPSBTS19PQkpfQVRUUiwKKyAgICAgICAg
ICAgICAgICAgLmF1dGhQb2xpY3kuc2l6ZSA9IDAsCisgICAgICAgICAgICAgICAgIC5wYXJhbWV0
ZXJzLnJzYURldGFpbCA9IHsKKyAgICAgICAgICAgICAgICAgICAgIC5zeW1tZXRyaWMgPSB7Cisg
ICAgICAgICAgICAgICAgICAgICAgICAgLmFsZ29yaXRobSA9IFRQTTJfQUxHX05VTEwsCisgICAg
ICAgICAgICAgICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgICAgLnNjaGVtZSA9IHsKKyAg
ICAgICAgICAgICAgICAgICAgICAgICBUUE0yX0FMR19PQUVQLAorICAgICAgICAgICAgICAgICAg
ICAgICAgIC5kZXRhaWxzLm9hZXAuaGFzaEFsZyA9IFRQTTJfQUxHX1NIQTI1NiwKKyAgICAgICAg
ICAgICAgICAgICAgIH0sCisgICAgICAgICAgICAgICAgICAgICAua2V5Qml0cyA9IFJTQV9LRVlf
U0laRVNfQklUUywKKyAgICAgICAgICAgICAgICAgICAgIC5leHBvbmVudCA9IDAsCisgICAgICAg
ICAgICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgLnVuaXF1ZS5yc2Euc2l6ZSA9IDAsCisg
ICAgICAgICAgICB9LAorICAgICAgICB9LAorICAgICAgICAub3V0c2lkZUluZm8uc2l6ZSA9IDAs
CisgICAgICAgIC5jcmVhdGlvblBDUi5jb3VudCA9IDAsCisgICAgfTsvKmVuZCBpbiAqLworCisg
ICAgVFBNVFJZUkVUVVJOKFRQTTJfQ3JlYXRlKHZ0cG1fZ2xvYmFscy5zcmtfaGFuZGxlLCAmaW4s
ICZvdXQpKTsKKyAgICBUUE1UUllSRVRVUk4oVFBNMl9Mb2FkKHZ0cG1fZ2xvYmFscy5zcmtfaGFu
ZGxlLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZ0cG1fZ2xvYmFscy50cG0yX3N0b3Jh
Z2Vfa2V5LlByaXZhdGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAmdnRwbV9nbG9iYWxz
LnRwbTJfc3RvcmFnZV9rZXkuUHVibGljLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZ0
cG1fZ2xvYmFscy5za19oYW5kbGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAmdnRwbV9n
bG9iYWxzLnNrX25hbWUpKTsKKworICAgIHZ0cG1sb2dpbmZvKFZUUE1fTE9HX1ZUUE0sICJTSyBI
QU5ETEU6IDB4JVhcbiIsIHZ0cG1fZ2xvYmFscy5za19oYW5kbGUpOworICAgIC8qZW5kIGNyZWF0
ZSBTSyovCisKKyNpZiAwIC8qQmluZCAmIHVuQmluZCovCit7CisgICAgdW5zaWduZWQgY2hhciBy
YW5kWzIwXTsKKyAgICB1bnNpZ25lZCBjaGFyIGNpcGhlclsyNTZdLCBvdXRbMjU2XTsKKyAgICB2
dHBtbWdyX3JhbmQocmFuZCwgMjApOworICAgIGludCBpOworICAgIFVJTlQzMiBvbGVuOworCisg
ICAgcHJpbnRrKCJyYW5kOiAiKTsKKyAgICBmb3IgKGkgPSAwOyBpIDwgMjA7IGkrKykgeworICAg
ICAgICAgcHJpbnRrKCIgJXUgIiwgcmFuZFtpXSk7CisgICAgfQorICAgIHByaW50aygiXG4iKTsK
KyAgICBUUE1UUllSRVRVUk4oVFBNMl9CaW5kKHZ0cG1fZ2xvYmFscy5za19oYW5kbGUsCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICByYW5kLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg
MjAsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBjaXBoZXIpKTsKKyAgICBwcmludGsoImNp
cGhlciA6ICIpOworICAgIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykgeworICAgICAgICAgcHJp
bnRrKCIlMDJ4IiwgY2lwaGVyW2ldKTsKKyAgICB9CisgICAgcHJpbnRrKCJcbiIpOworICAgIFRQ
TVRSWVJFVFVSTihUUE0yX1VuQmluZCh2dHBtX2dsb2JhbHMuc2tfaGFuZGxlLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAyNTYsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNp
cGhlciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJm9sZW4sCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG91dCkpOworICAgIHByaW50aygib2xlbiA6ICVkIFxuIiwgb2xlbik7
CisgICAgcHJpbnRrKCJvdXQgOiAiKTsKKyAgICBmb3IgKGkgPSAwOyBpIDwgb2xlbjsgaSsrKQor
ICAgICAgICAgcHJpbnRrKCIgJXUgIiwgb3V0W2ldKTsKKyAgICBwcmludGsoIlxuIik7Cit9Cisj
ZW5kaWYKKworICAgIC8qQ3JlYXRlIG5ldyBkaXNrIGltYWdlKi8KKyAgICBUUE1UUllSRVRVUk4o
dnRwbV9uZXdfZGlzaygpKTsKKworICAgIGdvdG8gZWdyZXNzOworCithYm9ydF9lZ3Jlc3M6Citl
Z3Jlc3M6CisgICAgdnRwbWxvZ2luZm8oVlRQTV9MT0dfVlRQTSwgIkZpbmlzaGVkIGluaXRpYWxp
emVkIG5ldyBWVFBNIG1hbmFnZXJcbiIpOworICAgIHJldHVybiBzdGF0dXM7Cit9CmRpZmYgLS1n
aXQgYS9zdHViZG9tL3Z0cG1tZ3IvdnRwbW1nci5oIGIvc3R1YmRvbS92dHBtbWdyL3Z0cG1tZ3Iu
aAppbmRleCA5NTUxOWJhLi45ODg5ZmViIDEwMDY0NAotLS0gYS9zdHViZG9tL3Z0cG1tZ3IvdnRw
bW1nci5oCisrKyBiL3N0dWJkb20vdnRwbW1nci92dHBtbWdyLmgKQEAgLTk1LDUgKzk1LDYgQEAg
aW5saW5lIFRQTV9SRVNVTFQgdnRwbW1ncl9yYW5kKHVuc2lnbmVkIGNoYXIqIGJ5dGVzLCBzaXpl
X3QgbnVtX2J5dGVzKSB7CiAKIC8qIFRQTSAyLjAgKi8KIFRQTV9SQyB0cG0yX3Rha2Vfb3duZXJz
aGlwKHZvaWQpOworVFBNX1JFU1VMVCB2dHBtbWdyMl9jcmVhdGUodm9pZCk7CiAKICNlbmRpZgot
LSAKMS44LjMuMgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6Fyx-0001e8-Im; Wed, 31 Dec 2014 09:54:23 +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 1Y6Fyw-0001e3-CS
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:22 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	E1/3D-19763-DC7C3A45; Wed, 31 Dec 2014 09:54:21 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1420019659!15741069!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4259 invoked from network); 31 Dec 2014 09:54:20 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-9.tower-206.messagelabs.com with SMTP;
	31 Dec 2014 09:54:20 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by orsmga103.jf.intel.com with ESMTP; 31 Dec 2014 01:51:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="435269182"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 31 Dec 2014 01:42:16 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:20 -0500
Message-Id: <1420005020-25475-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
MIME-Version: 1.0
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	tim@xen.org, ian.jackson@eu.citrix.com, jbeulich@suse.com,
	Quan Xu <quan.xu@intel.com>, samuel.thibault@ens-lyon.org,
	dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH v3 00/14] Enable vTPM subsystem on TPM 2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

###################
# Happy New Year..#
###################

This series of patch enable the virtual Trusted Platform Module (vTPM)
subsystem for Xen on TPM 2.0.

Noted, functionality for a virtual guest operating system (a DomU) is still
TPM 1.2. The main modifcation is on vtpmmgr-stubdom. The challenge is that
TPM 2.0 is not backward compatible with TPM 1.2.

------------------------------
DESIGN OVERVIEW
------------------------------
The architecture of vTPM subsystem on TPM 2.0 is described below:

+------------------+
|    Linux DomU    | ...
|       |  ^       |
|       v  |       |
|   xen-tpmfront   |
+------------------+
        |  ^
        v  |
+------------------+
| mini-os/tpmback  |
|       |  ^       |
|       v  |       |
|  vtpm-stubdom    | ...
|       |  ^       |
|       v  |       |
| mini-os/tpmfront |
+------------------+
        |  ^
        v  |
+------------------+
| mini-os/tpmback  |
|       |  ^       |
|       v  |       |
| vtpmmgr-stubdom  |
|       |  ^       |
|       v  |       |
| mini-os/tpm2_tis |
+------------------+
        |  ^
        v  |
+------------------+
| Hardware TPM 2.0 |
+------------------+
 * Linux DomU: The Linux based guest that wants to use a vTPM. There many be
               more than one of these.

 * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver
                    provides vTPM access to a para-virtualized Linux based DomU.

 * 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.  This domain regulates
               access to the physical TPM on the system and secures the
               persistent state of each vTPM.

 * mini-os/tpm2_tis: Mini-os TPM version 2.0 TPM Interface Specification (TIS)
                    driver. This driver used by vtpmmgr-stubdom to talk directly
                    to the hardware TPM 2.0. Communication is facilitated by mapping
                    hardware memory pages into vtpmmgr-stubdom.

 * Hardware TPM 2.0: The physical TPM 2.0 that is soldered onto the motherboard.


------------------------------
Key Hierarchy
------------------------------

    +------------------+
    |  vTPM's secrets  | ...
    +------------------+
            |  ^
            |  |(Bind / Unbind)
- - - - -  -v  |- - - - - - - - TPM 2.0
    +------------------+
    |        SK        +
    +------------------+
            |  ^
            v  |
    +------------------+
    |       SRK        |
    +------------------+
            |  ^
            v  |
    +------------------+
    | TPM 2.0 Storage  |
    |   Primary Seed   |
    +------------------+
------------------------------
INSTALLATION
------------------------------

Prerequisites:
--------------
You must have an x86 machine with a TPM on the motherboard.  The only extra
software requirement for compiling vTPM is cmake.  You must use libxl to manage
domains with vTPMs; 'xm' is deprecated and does not support vTPMs.

Compiling the Xen tree:
-----------------------

Compile and install the Xen tree as usual; be sure that the vTPM domains are
enabled when you run configure.

Compiling the LINUX dom0 kernel:
--------------------------------

Because the TPM manager uses direct access to the physical TPM, it may interfere
with access to the TPM by dom0.  The simplest solution for this is to prevent
dom0 from accessing the physical TPM by compiling the kernel without a driver or
blacklisting the module.

Compiling the LINUX domU kernel:
--------------------------------

The domU kernel used by domains with vtpms must include the xen-tpmfront.ko
driver. It can be built directly into the kernel or as a module; however, some
features such as IMA require the TPM to be built in to the kernel.


CONFIG_TCG_TPM=y
CONFIG_TCG_XEN=y

------------------------------
VTPM MANAGER SETUP
------------------------------

Manager disk image setup:
-------------------------

The vTPM Manager requires a disk image to store its encrypted data. The image
does not require a filesystem and can live anywhere on the host disk. The image
is not large; the Xen 4.5 vtpmmgr is limited to using the first 2MB of the image
but can support more than 20,000 vTPMs.

 dd if=/dev/zero of=/home/vtpm2/vmgr bs=16M count=1

Manager config file:
--------------------

The vTPM Manager domain (vtpmmgr-stubdom) must be started like any other Xen
virtual machine and requires a config file.  The manager requires a disk image
for storage and permission to access the hardware memory pages for the TPM. The
disk must be presented as "hda", and the TPM memory pages are passed using the
iomem configuration parameter. The TPM TIS uses 5 pages of IO memory (one per
locality) that start at physical address 0xfed40000. By default, the TPM manager
uses locality 0 (so only the page at 0xfed40 is needed).

Add:
..
     extra="tpm2"
..
extra option to launch vtpmmgr-stubdom domain on TPM 2.0, and ignore it on TPM
1.x. for example:

    kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
    memory=128
    disk=["file:/home/vtpm2/vmgr,hda,w"]
    name="vtpmmgr"
    iomem=["fed40,5"]
    extra="tpm2"

------------------------------
VTPM AND LINUX PVM SETUP
------------------------------
vTPM disk image setup:
----------------------

The vTPM requires a disk image to store its persistent data (RSA keys, NVRAM,
etc). The image does not require a filesystem. The image does not need to be
large; 2 Mb should be sufficient.

    dd if=/dev/zero of=/home/vtpm2/vtpm0 bs=2M count=1

vTPM config file:
-----------------

The vTPM domain requires a configuration file like any other domain. The vTPM
requires a disk image for storage and a TPM frontend driver to communicate with
the manager.  You are required to generate a uuid for this vtpm, which is
specified on the "vtpm=" line that describes its connection to the vTPM Manager.
for example:

    kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
    memory=8
    disk=["file:/home/vtpm2/vtpm0,hda,w"]
    name="vtpm0"
    vtpm=["backend=vtpmmgr,uuid=914fe389-e2c5-44e6-993f-2189637cf1de"]

If you wish to clear the vTPM data you can either recreate the disk image or
change the uuid.

Linux Guest config file:
------------------------
The Linux guest config file needs to be modified to include the Linux tpmfront
driver. Add the following line:

vtpm=["backend=vtpm0"]

Currently only Linux guests are supported (PV or HVM with PV drivers). My series
of patch for HVM virtual mahcine are still being reviewed and modifcated.

Using the vTPM in the guest:
----------------------------

If xen-tpmfront was compiled as a module, it must be loaded it in the guest.

# modprobe xen-tpmfront

After the Linux domain boots and the xen-tpmfront driver is loaded, you should
see the following on the vtpm console:

Info: VTPM attached to Frontend X/Y

You can quickly test the vTPM by using the sysfs interface:
# cat /sys/devices/vtpm-0/pubek
# cat /sys/devices/vtpm-0/pcrs
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

You should also see the command being sent to the vtpm console as well as the
vtpm saving its state. You should see the vtpm key being encrypted and stored on
the vtpmmgr console.

You may wish to write a script to start your vtpm and guest together and to
destroy the vtpm when the guest shuts down.
------------------------------
INTEGRATION WITH PV-GRUB
------------------------------

The vTPM currently starts up with all PCRs set to their default values (all
zeros for the lower 16).  This means that any decisions about the
trustworthiness of the created domain must be made based on the environment that
created the vTPM and the domU; for example, a system that only constructs images
using a trusted configuration and guest kernel be able to provide guarantees
about the guests and any measurements done that kernel (such as the IMA TCB
log).  Guests wishing to use a custom kernel in such a secure environment are
often started using the pv-grub bootloader as the kernel, which then can load
the untrusted kernel without needing to parse an untrusted filesystem and kernel
in dom0.  If the pv-grub stub domain succeeds in connecting to a vTPM, it will
extend the hash of the kernel that it boots into PCR #4, and will extend the
command line and initrd into PCR #5 before booting so that a domU booted in this
way can attest to its early boot state.

------------------------------
REFERENCES
------------------------------

Berlios TPM Emulator:
http://tpm-emulator.berlios.de/
Xen docs/misc/vtpm.txt
Xen docs/misc/vtpm-platforms.txt
Xen docs/misc/vtpmmgr.txt

--Changes in V3:
  1. Add 'olen' parameter in 'stubdom/vtpmmgr/disk_read.c', which is lost in v2.

--Changes in V2:
  1. Record some infomation in docs/misc/vtpmmgr.txt.
  2. Add TPM 2.0 PCRs read.
  3. Bind/Unbind the measurements of the hypervisor and other
     TCB components.
  4. Change extra option from '--tpm2' to 'tpm2'

Quan Xu (14):
  vTPM/TPM2: Add TPM 2.0 data structures and commands definition
  vTPM/TPM2: TPM 2.0 data structures marshal
  vTPM/TPM2: Add global data in vtpm_globals{}
  vTPM/TPM2: Add TPM 2.0 Exposed APIs
  vTPM/TPM2: TPM 2.0 takes ownership and create SRK
  vTPM/TPM2: Create and load SK on TPM 2.0
  vTPM/TPM2: TPM2.0 TIS initialization and self test.
  vTPM/TPM2: Add main entrance vtpmmgr2_init()
  vTPM/TPM2: Support 'tpm2' extra command line.
  vTPM/TPM2: TPM 2.0 PCRs read
  vTPM/TPM2: Support TPM 2.0 bind and unbind data
  vTPM/TPM2: Bind group keys and sectors data on disk
  vTPM/TPM2: Unind group keys and sectors data on disk
  vTPM/TPM2: Record some infomation in docs/misc/vtpmmgr.txt about

 docs/misc/vtpmmgr.txt            | 150 +++++-
 extras/mini-os/include/tpm_tis.h |   1 +
 extras/mini-os/tpm_tis.c         | 156 +++++++
 stubdom/vtpmmgr/Makefile         |   2 +-
 stubdom/vtpmmgr/disk_read.c      |  17 +-
 stubdom/vtpmmgr/disk_tpm.c       |  42 +-
 stubdom/vtpmmgr/disk_tpm.h       |   4 +
 stubdom/vtpmmgr/disk_write.c     |  13 +-
 stubdom/vtpmmgr/init.c           | 315 +++++++++++++
 stubdom/vtpmmgr/tpm2.c           | 455 ++++++++++++++++++
 stubdom/vtpmmgr/tpm2.h           | 104 +++++
 stubdom/vtpmmgr/tpm2_marshal.h   | 673 +++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2_types.h     | 980 +++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.c        |  46 +-
 stubdom/vtpmmgr/vtpmmgr.h        |  29 ++
 15 files changed, 2973 insertions(+), 14 deletions(-)
 create mode 100644 stubdom/vtpmmgr/tpm2.c
 create mode 100644 stubdom/vtpmmgr/tpm2.h
 create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h
 create mode 100644 stubdom/vtpmmgr/tpm2_types.h

-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6Fz5-0001eP-Vp; Wed, 31 Dec 2014 09:54:31 +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 1Y6Fz5-0001eH-1N
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:31 +0000
Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id
	D4/6B-15461-6D7C3A45; Wed, 31 Dec 2014 09:54:30 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1420019667!18632753!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.9 required=7.0 tests=DATE_IN_PAST_03_06,
	UPPERCASE_50_75
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1754 invoked from network); 31 Dec 2014 09:54:27 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-9.tower-21.messagelabs.com with SMTP;
	31 Dec 2014 09:54:27 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 31 Dec 2014 01:51:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="506074451"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 31 Dec 2014 01:49:11 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:31 -0500
Message-Id: <1420005031-25514-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 01/14] vTPM/TPM2: Add TPM 2.0 data structures
	and commands 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

Add TPM 2.0 data structures on Trusted Platform Module Library Part 2:
Structures and Trust Platform Module Library Part 3: Commands.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/tpm2_types.h | 978 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 978 insertions(+)
 create mode 100644 stubdom/vtpmmgr/tpm2_types.h

diff --git a/stubdom/vtpmmgr/tpm2_types.h b/stubdom/vtpmmgr/tpm2_types.h
new file mode 100644
index 0000000..214335c
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2_types.h
@@ -0,0 +1,978 @@
+#ifndef __TPM2_TYPES_H__
+#define __TPM2_TYPES_H__
+
+#include <stdlib.h>
+#include <stdint.h>
+
+// "implementation.h"
+// Table 212 -- Logic Values
+#define    YES      1
+#define    NO       0
+#ifndef    TRUE
+#define    TRUE     1
+#endif
+#ifndef    FALSE
+#define    FALSE    0
+#endif
+#ifndef    true
+#define    true     1
+#endif
+#ifndef    false
+#define    false    0
+#endif
+#define    SET      1
+#define    CLEAR    0
+
+
+// Table 214 -- Implemented Algorithms
+#define    ALG_RSA               YES    // 1
+#define    ALG_DES               NO     // 0
+#define    ALG__3DES             NO     // 0
+#define    ALG_SHA1              YES    // 1
+#define    ALG_HMAC              YES    // 1
+#define    ALG_AES               YES    // 1
+#define    ALG_MGF1              YES    // 1
+#define    ALG_XOR               YES    // 1
+#define    ALG_KEYEDHASH         YES    // 1
+#define    ALG_SHA256            YES    // 1
+#define    ALG_SHA384            YES    // 0
+#define    ALG_SHA512            YES    // 0
+#define    ALG_WHIRLPOOL512      YES    // 0
+#define    ALG_SM3_256           YES    // 1
+#define    ALG_SM4               YES    // 1
+#define    ALG_RSASSA            YES    // 1
+#define    ALG_RSAES             YES    // 1
+#define    ALG_RSAPSS            YES    // 1
+#define    ALG_OAEP              YES    // 1
+#define    ALG_ECC               YES    // 1
+#define    ALG_CFB               YES    // 1
+#define    ALG_ECDH              YES    // 1
+#define    ALG_ECDSA             YES    // 1
+#define    ALG_ECDAA             YES    // 1
+#define    ALG_SM2               YES    // 1
+#define    ALG_ECSCHNORR         YES    // 1
+#define    ALG_SYMCIPHER         YES    // 1
+#define    ALG_KDF1_SP800_56a    YES    // 1
+#define    ALG_KDF2              NO     // 0
+#define    ALG_KDF1_SP800_108    YES    // 1
+#define    ALG_CTR               YES    // 1
+#define    ALG_OFB               YES    // 1
+#define    ALG_CBC               YES    // 1
+
+#define HASH_COUNT (ALG_SHA1+ALG_SHA256+ALG_SHA384+ALG_SHA512+ALG_WHIRLPOOL512+ALG_SM3_256)
+
+// Table 216 -- RSA Algorithm Constants
+#define    RSA_KEY_SIZES_BITS    2048    // {1024,2048}
+#define    MAX_RSA_KEY_BITS      2048
+#define    MAX_RSA_KEY_BYTES     ((MAX_RSA_KEY_BITS + 7) / 8)    // 256
+
+// Table 218 -- AES Algorithm Constants
+#define    AES_KEY_SIZES_BITS          128
+#define    MAX_AES_KEY_BITS            128
+#define    MAX_AES_BLOCK_SIZE_BYTES    16
+#define    MAX_AES_KEY_BYTES           ((MAX_AES_KEY_BITS + 7) / 8)    // 16
+
+
+// Table 220 -- Symmetric Algorithm Constants
+#define    MAX_SYM_KEY_BITS      MAX_AES_KEY_BITS    // 128
+#define    MAX_SYM_KEY_BYTES     MAX_AES_KEY_BYTES    // 16
+#define    MAX_SYM_BLOCK_SIZE    MAX_AES_BLOCK_SIZE_BYTES    // 16
+
+#define    MAX_SYM_DATA         128
+#define    MAX_ECC_KEY_BITS     256
+#define    MAX_ECC_KEY_BYTES    ((MAX_ECC_KEY_BITS + 7) / 8)
+
+
+typedef unsigned char BYTE;
+typedef unsigned char BOOL;
+typedef uint8_t       UINT8;
+typedef uint16_t      UINT16;
+typedef uint32_t      UINT32;
+typedef uint64_t      UINT64;
+
+// TPM2 command code
+
+typedef UINT32 TPM_CC;
+#define    TPM_CC_FIRST                         (TPM_CC)(0x0000011F)
+#define    TPM_CC_PP_FIRST                      (TPM_CC)(0x0000011F)
+#define    TPM_CC_NV_UndefineSpaceSpecial       (TPM_CC)(0x0000011F)
+#define    TPM_CC_EvictControl                  (TPM_CC)(0x00000120)
+#define    TPM_CC_HierarchyControl              (TPM_CC)(0x00000121)
+#define    TPM_CC_NV_UndefineSpace              (TPM_CC)(0x00000122)
+#define    TPM_CC_ChangeEPS                     (TPM_CC)(0x00000124)
+#define    TPM_CC_ChangePPS                     (TPM_CC)(0x00000125)
+#define    TPM_CC_Clear                         (TPM_CC)(0x00000126)
+#define    TPM_CC_ClearControl                  (TPM_CC)(0x00000127)
+#define    TPM_CC_ClockSet                      (TPM_CC)(0x00000128)
+#define    TPM_CC_HierarchyChangeAuth           (TPM_CC)(0x00000129)
+#define    TPM_CC_NV_DefineSpace                (TPM_CC)(0x0000012A)
+#define    TPM_CC_PCR_Allocate                  (TPM_CC)(0x0000012B)
+#define    TPM_CC_PCR_SetAuthPolicy             (TPM_CC)(0x0000012C)
+#define    TPM_CC_PP_Commands                   (TPM_CC)(0x0000012D)
+#define    TPM_CC_SetPrimaryPolicy              (TPM_CC)(0x0000012E)
+#define    TPM_CC_FieldUpgradeStart             (TPM_CC)(0x0000012F)
+#define    TPM_CC_ClockRateAdjust               (TPM_CC)(0x00000130)
+#define    TPM_CC_CreatePrimary                 (TPM_CC)(0x00000131)
+#define    TPM_CC_NV_GlobalWriteLock            (TPM_CC)(0x00000132)
+#define    TPM_CC_PP_LAST                       (TPM_CC)(0x00000132)
+#define    TPM_CC_GetCommandAuditDigest         (TPM_CC)(0x00000133)
+#define    TPM_CC_NV_Increment                  (TPM_CC)(0x00000134)
+#define    TPM_CC_NV_SetBits                    (TPM_CC)(0x00000135)
+#define    TPM_CC_NV_Extend                     (TPM_CC)(0x00000136)
+#define    TPM_CC_NV_Write                      (TPM_CC)(0x00000137)
+#define    TPM_CC_NV_WriteLock                  (TPM_CC)(0x00000138)
+#define    TPM_CC_DictionaryAttackLockReset     (TPM_CC)(0x00000139)
+#define    TPM_CC_DictionaryAttackParameters    (TPM_CC)(0x0000013A)
+#define    TPM_CC_NV_ChangeAuth                 (TPM_CC)(0x0000013B)
+#define    TPM_CC_PCR_Event                     (TPM_CC)(0x0000013C)
+#define    TPM_CC_PCR_Reset                     (TPM_CC)(0x0000013D)
+#define    TPM_CC_SequenceComplete              (TPM_CC)(0x0000013E)
+#define    TPM_CC_SetAlgorithmSet               (TPM_CC)(0x0000013F)
+#define    TPM_CC_SetCommandCodeAuditStatus     (TPM_CC)(0x00000140)
+#define    TPM_CC_FieldUpgradeData              (TPM_CC)(0x00000141)
+#define    TPM_CC_IncrementalSelfTest           (TPM_CC)(0x00000142)
+#define    TPM_CC_SelfTest                      (TPM_CC)(0x00000143)
+#define    TPM_CC_Startup                       (TPM_CC)(0x00000144)
+#define    TPM_CC_Shutdown                      (TPM_CC)(0x00000145)
+#define    TPM_CC_StirRandom                    (TPM_CC)(0x00000146)
+#define    TPM_CC_ActivateCredential            (TPM_CC)(0x00000147)
+#define    TPM_CC_Certify                       (TPM_CC)(0x00000148)
+#define    TPM_CC_PolicyNV                      (TPM_CC)(0x00000149)
+#define    TPM_CC_CertifyCreation               (TPM_CC)(0x0000014A)
+#define    TPM_CC_Duplicate                     (TPM_CC)(0x0000014B)
+#define    TPM_CC_GetTime                       (TPM_CC)(0x0000014C)
+#define    TPM_CC_GetSessionAuditDigest         (TPM_CC)(0x0000014D)
+#define    TPM_CC_NV_Read                       (TPM_CC)(0x0000014E)
+#define    TPM_CC_NV_ReadLock                   (TPM_CC)(0x0000014F)
+#define    TPM_CC_ObjectChangeAuth              (TPM_CC)(0x00000150)
+#define    TPM_CC_PolicySecret                  (TPM_CC)(0x00000151)
+#define    TPM_CC_Rewrap                        (TPM_CC)(0x00000152)
+#define    TPM_CC_Create                        (TPM_CC)(0x00000153)
+#define    TPM_CC_ECDH_ZGen                     (TPM_CC)(0x00000154)
+#define    TPM_CC_HMAC                          (TPM_CC)(0x00000155)
+#define    TPM_CC_Import                        (TPM_CC)(0x00000156)
+#define    TPM_CC_Load                          (TPM_CC)(0x00000157)
+#define    TPM_CC_Quote                         (TPM_CC)(0x00000158)
+#define    TPM_CC_RSA_Decrypt                   (TPM_CC)(0x00000159)
+#define    TPM_CC_HMAC_Start                    (TPM_CC)(0x0000015B)
+#define    TPM_CC_SequenceUpdate                (TPM_CC)(0x0000015C)
+#define    TPM_CC_Sign                          (TPM_CC)(0x0000015D)
+#define    TPM_CC_Unseal                        (TPM_CC)(0x0000015E)
+#define    TPM_CC_PolicySigned                  (TPM_CC)(0x00000160)
+#define    TPM_CC_ContextLoad                   (TPM_CC)(0x00000161)
+#define    TPM_CC_ContextSave                   (TPM_CC)(0x00000162)
+#define    TPM_CC_ECDH_KeyGen                   (TPM_CC)(0x00000163)
+#define    TPM_CC_EncryptDecrypt                (TPM_CC)(0x00000164)
+#define    TPM_CC_FlushContext                  (TPM_CC)(0x00000165)
+#define    TPM_CC_LoadExternal                  (TPM_CC)(0x00000167)
+#define    TPM_CC_MakeCredential                (TPM_CC)(0x00000168)
+#define    TPM_CC_NV_ReadPublic                 (TPM_CC)(0x00000169)
+#define    TPM_CC_PolicyAuthorize               (TPM_CC)(0x0000016A)
+#define    TPM_CC_PolicyAuthValue               (TPM_CC)(0x0000016B)
+#define    TPM_CC_PolicyCommandCode             (TPM_CC)(0x0000016C)
+#define    TPM_CC_PolicyCounterTimer            (TPM_CC)(0x0000016D)
+#define    TPM_CC_PolicyCpHash                  (TPM_CC)(0x0000016E)
+#define    TPM_CC_PolicyLocality                (TPM_CC)(0x0000016F)
+#define    TPM_CC_PolicyNameHash                (TPM_CC)(0x00000170)
+#define    TPM_CC_PolicyOR                      (TPM_CC)(0x00000171)
+#define    TPM_CC_PolicyTicket                  (TPM_CC)(0x00000172)
+#define    TPM_CC_ReadPublic                    (TPM_CC)(0x00000173)
+#define    TPM_CC_RSA_Encrypt                   (TPM_CC)(0x00000174)
+#define    TPM_CC_StartAuthSession              (TPM_CC)(0x00000176)
+#define    TPM_CC_VerifySignature               (TPM_CC)(0x00000177)
+#define    TPM_CC_ECC_Parameters                (TPM_CC)(0x00000178)
+#define    TPM_CC_FirmwareRead                  (TPM_CC)(0x00000179)
+#define    TPM_CC_GetCapability                 (TPM_CC)(0x0000017A)
+#define    TPM_CC_GetRandom                     (TPM_CC)(0x0000017B)
+#define    TPM_CC_GetTestResult                 (TPM_CC)(0x0000017C)
+#define    TPM_CC_Hash                          (TPM_CC)(0x0000017D)
+#define    TPM_CC_PCR_Read                      (TPM_CC)(0x0000017E)
+#define    TPM_CC_PolicyPCR                     (TPM_CC)(0x0000017F)
+#define    TPM_CC_PolicyRestart                 (TPM_CC)(0x00000180)
+#define    TPM_CC_ReadClock                     (TPM_CC)(0x00000181)
+#define    TPM_CC_PCR_Extend                    (TPM_CC)(0x00000182)
+#define    TPM_CC_PCR_SetAuthValue              (TPM_CC)(0x00000183)
+#define    TPM_CC_NV_Certify                    (TPM_CC)(0x00000184)
+#define    TPM_CC_EventSequenceComplete         (TPM_CC)(0x00000185)
+#define    TPM_CC_HashSequenceStart             (TPM_CC)(0x00000186)
+#define    TPM_CC_PolicyPhysicalPresence        (TPM_CC)(0x00000187)
+#define    TPM_CC_PolicyDuplicationSelect       (TPM_CC)(0x00000188)
+#define    TPM_CC_PolicyGetDigest               (TPM_CC)(0x00000189)
+#define    TPM_CC_TestParms                     (TPM_CC)(0x0000018A)
+#define    TPM_CC_Commit                        (TPM_CC)(0x0000018B)
+#define    TPM_CC_PolicyPassword                (TPM_CC)(0x0000018C)
+#define    TPM_CC_SM2_ZGen                      (TPM_CC)(0x0000018D)
+#define    TPM_CC_LAST                          (TPM_CC)(0x0000018D)
+
+
+//TPM_RC
+typedef UINT32 TPM_RC;
+
+// TPM_ST Constants
+typedef UINT16 TPM_ST;
+#define    TPM_ST_NULL                    (TPM_ST)(0X8000)
+#define    TPM_ST_NO_SESSIONS             (TPM_ST)(0x8001)
+#define    TPM_ST_SESSIONS                (TPM_ST)(0x8002)
+
+
+// TPM Handle types
+typedef UINT32 TPM_HANDLE;
+typedef UINT8 TPM_HT;
+
+
+// TPM_RH Constants
+typedef UINT32 TPM_RH;
+
+#define    TPM_RH_FIRST          (TPM_RH)(0x40000000)
+#define    TPM_RH_SRK            (TPM_RH)(0x40000000)
+#define    TPM_RH_OWNER          (TPM_RH)(0x40000001)
+#define    TPM_RS_PW             (TPM_RH)(0x40000009)
+#define    TPM_RH_LOCKOUT        (TPM_RH)(0x4000000A)
+#define    TPM_RH_ENDORSEMENT    (TPM_RH)(0x4000000B)
+#define    TPM_RH_PLATFORM       (TPM_RH)(0x4000000C)
+#define    TPM_RH_LAST           (TPM_RH)(0x4000000C)
+
+// Table 4 -- DocumentationClarity Types <I/O>
+typedef UINT32    TPM_ALGORITHM_ID;
+typedef UINT32    TPM_MODIFIER_INDICATOR;
+typedef UINT32    TPM_SESSION_OFFSET;
+typedef UINT16    TPM_KEY_SIZE;
+typedef UINT16    TPM_KEY_BITS;
+typedef UINT64    TPM_SYSTEM_ADDRESS;
+typedef UINT32    TPM_SPEC;
+
+// Table 29 -- TPMA_ALGORITHM Bits <I/O>
+typedef struct {
+    unsigned int asymmetric:1;
+    unsigned int symmetric:1;
+    unsigned int hash:1;
+    unsigned int object:1;
+    unsigned int reserved5:4;
+    unsigned int signing:1;
+    unsigned int encrypting:1;
+    unsigned int method:1;
+    unsigned int reserved9:21;
+} TPMA_ALGORITHM;
+
+typedef UINT32 TPMA_OBJECT;
+typedef BYTE TPMA_SESSION;
+typedef BYTE TPMA_LOCALITY;
+
+// Table 37 -- TPMI_YES_NO Type <I/O>
+typedef BYTE TPMI_YES_NO;
+
+typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
+
+// Table 38 -- TPMI_DH_OBJECT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_OBJECT;
+
+// Table 39 -- TPMI_DH_PERSISTENT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_PERSISTENT;
+
+// Table 42 -- TPMI_SH_AUTH_SESSION Type <I/O>
+typedef TPM_HANDLE TPMI_SH_AUTH_SESSION;
+
+// Table 40 -- TPMI_DH_ENTITY Type <I>
+typedef TPM_HANDLE TPMI_DH_ENTITY;
+
+// Table 45 -- TPMI_DH_CONTEXT Type <I/O>
+typedef TPM_HANDLE TPMI_DH_CONTEXT;
+
+// Table 46 -- TPMI_RH_HIERARCHY Type <I/O>
+typedef TPM_HANDLE TPMI_RH_HIERARCHY;
+
+// Table 47 -- TPMI_RH_HIERARCHY_AUTH Type <I>
+typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
+
+// Table 48 -- TPMI_RH_PLATFORM Type <I>
+typedef TPM_HANDLE TPMI_RH_PLATFORM;
+
+// Table 49 -- TPMI_RH_OWNER Type <I>
+typedef TPM_HANDLE TPMI_RH_OWNER;
+
+// Table 50 -- TPMI_RH_ENDORSEMENT Type <I>
+typedef TPM_HANDLE TPMI_RH_ENDORSEMENT;
+
+// Table 51 -- TPMI_RH_PROVISION Type <I>
+typedef TPM_HANDLE TPMI_RH_PROVISION;
+
+// Table 52 -- TPMI_RH_CLEAR Type <I>
+typedef TPM_HANDLE TPMI_RH_CLEAR;
+
+// Table 54 -- TPMI_RH_LOCKOUT Type <I>
+typedef TPM_HANDLE TPMI_RH_LOCKOUT;
+
+// Table 7 -- TPM_ALG_ID
+typedef UINT16 TPM_ALG_ID;
+typedef UINT16 TPM_ALG_ID;
+
+#define    TPM2_ALG_ERROR             (TPM_ALG_ID)(0x0000) // a: ; D:
+#define    TPM2_ALG_FIRST             (TPM_ALG_ID)(0x0001) // a: ; D:
+#if ALG_RSA == YES || ALG_ALL == YES
+#define    TPM2_ALG_RSA               (TPM_ALG_ID)(0x0001) // a: A O; D:
+#endif
+#if ALG_DES == YES || ALG_ALL == YES
+#define    TPM2_ALG_DES               (TPM_ALG_ID)(0x0002) // a: S; D:
+#endif
+#define    TPM2_ALG_SHA1              (TPM_ALG_ID)(0x0004) // a: H; D:
+#if ALG_HMAC == YES || ALG_ALL == YES
+#define    TPM2_ALG_HMAC              (TPM_ALG_ID)(0x0005) // a: H X; D:
+#endif
+#if ALG_AES == YES || ALG_ALL == YES
+#define    TPM2_ALG_AES               (TPM_ALG_ID)(0x0006) // a: S; D:
+#endif
+#if ALG_XOR == YES || ALG_ALL == YES
+#define    TPM2_ALG_XOR               (TPM_ALG_ID)(0x000A) // a: H S; D:
+#endif
+#if ALG_MGF1 == YES || ALG_ALL == YES
+#define    TPM2_ALG_MGF1              (TPM_ALG_ID)(0x0007) // a: H M; D:
+#endif
+#if ALG_KEYEDHASH == YES || ALG_ALL == YES
+#define    TPM2_ALG_KEYEDHASH         (TPM_ALG_ID)(0x0008) // a: H E X O; D:
+#endif
+#if ALG_SHA256 == YES || ALG_ALL == YES
+#define    TPM2_ALG_SHA256            (TPM_ALG_ID)(0x000B) // a: H; D:
+#endif
+#define    TPM2_ALG_NULL              (TPM_ALG_ID)(0x0010) // a: ; D:
+#if ALG_OAEP == YES || ALG_ALL == YES
+#define    TPM2_ALG_OAEP              (TPM_ALG_ID)(0x0017) // a: A E; D: RSA
+#endif
+#if ALG_ECC == YES || ALG_ALL == YES
+#define    TPM2_ALG_ECC               (TPM_ALG_ID)(0x0023) // a: A O; D:
+#endif
+#if ALG_SM4 == YES || ALG_ALL == YES
+#define    TPM2_ALG_SM4               (TPM_ALG_ID)(0x0013) // a: S; D:
+#endif
+#if ALG_SYMCIPHER == YES || ALG_ALL == YES
+#define    TPM2_ALG_SYMCIPHER         (TPM_ALG_ID)(0x0025) // a: O; D:
+#endif
+#if ALG_CFB == YES || ALG_ALL == YES
+#define    TPM2_ALG_CFB               (TPM_ALG_ID)(0x0043) // a: S E; D:
+#endif
+#define    TPM2_ALG_LAST              (TPM_ALG_ID)(0x0044)
+
+#define    SHA1_DIGEST_SIZE      20
+#define    SHA1_BLOCK_SIZE       64
+#define    SHA256_DIGEST_SIZE    32
+#define    SHA256_BLOCK_SIZE     64
+
+// Table 57 -- TPMI_ALG_ASYM Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_ASYM;
+
+// Table 56 -- TPMI_ALG_HASH Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_HASH;
+
+// Table 58 -- TPMI_ALG_SYM Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM;
+
+// Table 59 -- TPMI_ALG_SYM_OBJECT Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM_OBJECT;
+
+// Table 60 -- TPMI_ALG_SYM_MODE Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SYM_MODE;
+
+// Table 61 -- TPMI_ALG_KDF Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_KDF;
+
+// Table 62 -- TPMI_ALG_SIG_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_SIG_SCHEME;
+
+// Table 65 -- TPMU_HA Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_SHA1
+    BYTE  sha1[SHA1_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA256
+    BYTE  sha256[SHA256_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SM3_256
+    BYTE  sm3_256[SM3_256_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA384
+    BYTE  sha384[SHA384_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_SHA512
+    BYTE  sha512[SHA512_DIGEST_SIZE];
+#endif
+#ifdef TPM2_ALG_WHIRLPOOL512
+    BYTE  whirlpool[WHIRLPOOL512_DIGEST_SIZE];
+#endif
+
+} TPMU_HA;
+
+// Table 67 -- TPM2B_DIGEST Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[sizeof(TPMU_HA)];
+} TPM2B_DIGEST;
+
+// Table 69 -- TPM2B_NONCE Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_NONCE;
+
+typedef TPM2B_DIGEST    TPM2B_DATA;
+
+// Table 70 -- TPM2B_AUTH Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_AUTH;
+
+// Table 71 -- TPM2B_OPERAND Types <I/O>
+typedef TPM2B_DIGEST    TPM2B_OPERAND;
+
+// Table 66 -- TPMT_HA Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    TPMU_HA          digest;
+} TPMT_HA;
+
+//Table 80 -- TPM2B_NAME Structure
+typedef struct {
+    UINT16 size;
+    BYTE name[sizeof(TPMT_HA)];
+} TPM2B_NAME;
+
+#define    IMPLEMENTATION_PCR   24
+#define    PLATFORM_PCR         24
+#define    PCR_SELECT_MAX       ((IMPLEMENTATION_PCR+7)/8)
+
+//Table 79 -- TPMS_PCR_SELECT Structure <I/O>
+typedef struct {
+    UINT8    sizeofSelect;
+    BYTE     pcrSelect[PCR_SELECT_MAX];
+} TPMS_PCR_SELECT;
+
+// Table 80 -- TPMS_PCR_SELECTION Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hash;
+    UINT8            sizeofSelect;
+    BYTE             pcrSelect[PCR_SELECT_MAX];
+} TPMS_PCR_SELECTION;
+
+// Table 83 -- TPMT_TK_CREATION Structure <I/O>
+typedef struct {
+    TPM_ST               tag;
+    TPMI_RH_HIERARCHY    hierarchy;
+    TPM2B_DIGEST         digest;
+} TPMT_TK_CREATION;
+
+// Table 96 -- Definition of TPML_DIGEST Structure <I/O>
+typedef struct {
+    UINT32               count;
+    TPM2B_DIGEST         digests[8];
+}TPML_DIGEST;
+
+// Table 97 -- TPML_PCR_SELECTION Structure <I/O>
+typedef struct {
+    UINT32                count;
+    TPMS_PCR_SELECTION    pcrSelections[HASH_COUNT];
+} TPML_PCR_SELECTION;
+
+// Table 119 -- TPMI_AES_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_AES_KEY_BITS;
+
+// Table 120 -- TPMI_SM4_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_SM4_KEY_BITS;
+
+// Table 121 -- TPMU_SYM_KEY_BITS Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_AES
+    TPMI_AES_KEY_BITS  aes;
+#endif
+#ifdef TPM2_ALG_SM4
+    TPMI_SM4_KEY_BITS  SM4;
+#endif
+    TPM_KEY_BITS  sym;
+#ifdef TPM2_ALG_XOR
+    TPMI_ALG_HASH  xor;
+#endif
+
+} TPMU_SYM_KEY_BITS;
+
+// Table 122 -- TPMU_SYM_MODE Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_AES
+    TPMI_ALG_SYM_MODE  aes;
+#endif
+#ifdef TPM2_ALG_SM4
+    TPMI_ALG_SYM_MODE  SM4;
+#endif
+    TPMI_ALG_SYM_MODE  sym;
+} TPMU_SYM_MODE ;
+
+// Table 124 -- TPMT_SYM_DEF Structure <I/O>
+typedef struct {
+    TPMI_ALG_SYM         algorithm;
+    TPMU_SYM_KEY_BITS    keyBits;
+    TPMU_SYM_MODE        mode;
+} TPMT_SYM_DEF;
+
+// Table 125 -- TPMT_SYM_DEF_OBJECT Structure <I/O>
+typedef struct {
+    TPMI_ALG_SYM_OBJECT    algorithm;
+    TPMU_SYM_KEY_BITS      keyBits;
+    TPMU_SYM_MODE          mode;
+} TPMT_SYM_DEF_OBJECT;
+
+// Table 126 -- TPM2B_SYM_KEY Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_SYM_KEY_BYTES];
+} TPM2B_SYM_KEY;
+
+// Table 127 -- TPMS_SYMCIPHER_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    sym;
+} TPMS_SYMCIPHER_PARMS;
+
+// Table 128 -- TPM2B_SENSITIVE_DATA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_SYM_DATA];
+} TPM2B_SENSITIVE_DATA;
+
+// Table 129 -- TPMS_SENSITIVE_CREATE Structure <I>
+typedef struct {
+    TPM2B_AUTH              userAuth;
+    TPM2B_SENSITIVE_DATA    data;
+} TPMS_SENSITIVE_CREATE;
+
+// Table 130 -- TPM2B_SENSITIVE_CREATE Structure <I,S>
+typedef struct {
+    UINT16                   size;
+    TPMS_SENSITIVE_CREATE    sensitive;
+} TPM2B_SENSITIVE_CREATE;
+
+// Table 131 -- TPMS_SCHEME_SIGHASH Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_SIGHASH;
+
+// Table 132 -- TPMI_ALG_KEYEDHASH_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_KEYEDHASH_SCHEME;
+
+// Table 133 -- HMAC_SIG_SCHEME Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_HMAC;
+
+// Table 134 -- TPMS_SCHEME_XOR Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    TPMI_ALG_KDF     kdf;
+} TPMS_SCHEME_XOR;
+
+// Table 135 -- TPMU_SCHEME_KEYEDHASH Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_HMAC
+    TPMS_SCHEME_HMAC  hmac;
+#endif
+#ifdef TPM2_ALG_XOR
+    TPMS_SCHEME_XOR  xor;
+#endif
+
+} TPMU_SCHEME_KEYEDHASH ;
+
+// Table 136 -- TPMT_KEYEDHASH_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_KEYEDHASH_SCHEME    scheme;
+    TPMU_SCHEME_KEYEDHASH        details;
+} TPMT_KEYEDHASH_SCHEME;
+
+// Table 137 -- RSA_SIG_SCHEMES Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_RSASSA;
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_RSAPSS;
+
+// Table 138 -- ECC_SIG_SCHEMES Types <I/O>
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_ECDSA;
+typedef TPMS_SCHEME_SIGHASH    TPMS_SCHEME_SM2;
+
+// Table 139 -- TPMS_SCHEME_ECDAA Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    UINT16           count;
+} TPMS_SCHEME_ECDAA;
+
+// Table 140 -- TPMS_SCHEME_ECSCHNORR Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+    UINT16           count;
+} TPMS_SCHEME_ECSCHNORR;
+
+// Table 141 -- TPMU_SIG_SCHEME Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_RSASSA
+    TPMS_SCHEME_RSASSA  rsassa;
+#endif
+#ifdef TPM2_ALG_RSAPSS
+    TPMS_SCHEME_RSAPSS  rsapss;
+#endif
+#ifdef TPM2_ALG_ECDSA
+    TPMS_SCHEME_ECDSA  ecdsa;
+#endif
+#ifdef TPM2_ALG_SM2
+    TPMS_SCHEME_SM2  sm2;
+#endif
+#ifdef TPM2_ALG_ECDAA
+    TPMS_SCHEME_ECDAA  ecdaa;
+#endif
+#ifdef TPM2_ALG_ECSCHNORR
+    TPMS_SCHEME_ECSCHNORR  ecSchnorr;
+#endif
+#ifdef TPM2_ALG_HMAC
+    TPMS_SCHEME_HMAC  hmac;
+#endif
+    TPMS_SCHEME_SIGHASH  any;
+} TPMU_SIG_SCHEME;
+
+// Table 142 -- TPMT_SIG_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_SIG_SCHEME    scheme;
+    TPMU_SIG_SCHEME        details;
+} TPMT_SIG_SCHEME;
+
+// Table 143 -- TPMS_SCHEME_OAEP Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_OAEP;
+
+// Table 144 -- TPMS_SCHEME_ECDH Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_ECDH;
+
+// Table 145 -- TPMS_SCHEME_MGF1 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_MGF1;
+
+// Table 146 -- TPMS_SCHEME_KDF1_SP800_56a Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF1_SP800_56a;
+
+// Table 147 -- TPMS_SCHEME_KDF2 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF2;
+
+// Table 148 -- TPMS_SCHEME_KDF1_SP800_108 Structure <I/O>
+typedef struct {
+    TPMI_ALG_HASH    hashAlg;
+} TPMS_SCHEME_KDF1_SP800_108;
+
+// Table 149 -- TPMU_KDF_SCHEME Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_MGF1
+    TPMS_SCHEME_MGF1  mgf1;
+#endif
+#ifdef TPM2_ALG_KDF1_SP800_56a
+    TPMS_SCHEME_KDF1_SP800_56a  kdf1_SP800_56a;
+#endif
+#ifdef TPM2_ALG_KDF2
+    TPMS_SCHEME_KDF2  kdf2;
+#endif
+#ifdef TPM2_ALG_KDF1_SP800_108
+    TPMS_SCHEME_KDF1_SP800_108  kdf1_sp800_108;
+#endif
+
+} TPMU_KDF_SCHEME;
+
+// Table 150 -- TPMT_KDF_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_KDF       scheme;
+    TPMU_KDF_SCHEME    details;
+} TPMT_KDF_SCHEME;
+typedef TPM_ALG_ID TPMI_ALG_ASYM_SCHEME;
+
+// Table 152 -- TPMU_ASYM_SCHEME Union <I/O>
+typedef union {
+#ifdef TPM2_ALG_RSASSA
+    TPMS_SCHEME_RSASSA  rsassa;
+#endif
+#ifdef TPM2_ALG_RSAPSS
+    TPMS_SCHEME_RSAPSS  rsapss;
+#endif
+#ifdef TPM2_ALG_OAEP
+    TPMS_SCHEME_OAEP  oaep;
+#endif
+#ifdef TPM2_ALG_ECDSA
+    TPMS_SCHEME_ECDSA  ecdsa;
+#endif
+#ifdef TPM2_ALG_SM2
+    TPMS_SCHEME_SM2  sm2;
+#endif
+#ifdef TPM2_ALG_ECDAA
+    TPMS_SCHEME_ECDAA  ecdaa;
+#endif
+#ifdef TPM2_ALG_ECSCHNORR
+    TPMS_SCHEME_ECSCHNORR  ecSchnorr;
+#endif
+    TPMS_SCHEME_SIGHASH  anySig;
+} TPMU_ASYM_SCHEME;
+
+typedef struct {
+    TPMI_ALG_ASYM_SCHEME    scheme;
+    TPMU_ASYM_SCHEME        details;
+} TPMT_ASYM_SCHEME;
+
+// Table 154 -- TPMI_ALG_RSA_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_RSA_SCHEME;
+
+// Table 155 -- TPMT_RSA_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_RSA_SCHEME    scheme;
+    TPMU_ASYM_SCHEME       details;
+} TPMT_RSA_SCHEME;
+
+// Table 156 -- TPMI_ALG_RSA_DECRYPT Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_RSA_DECRYPT;
+
+// Table 157 -- TPMT_RSA_DECRYPT Structure <I/O>
+typedef struct {
+    TPMI_ALG_RSA_DECRYPT    scheme;
+    TPMU_ASYM_SCHEME        details;
+} TPMT_RSA_DECRYPT;
+
+// Table 158 -- TPM2B_PUBLIC_KEY_RSA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_RSA_KEY_BYTES];
+} TPM2B_PUBLIC_KEY_RSA;
+
+// Table 159 -- TPMI_RSA_KEY_BITS Type <I/O>
+typedef TPM_KEY_BITS TPMI_RSA_KEY_BITS;
+
+// Table 160 -- TPM2B_PRIVATE_KEY_RSA Structure <I/O>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[MAX_RSA_KEY_BYTES/2];
+} TPM2B_PRIVATE_KEY_RSA;
+
+// Table 162 -- TPM2B_ECC_PARAMETER
+typedef struct {
+    UINT16 size;
+    BYTE buffer[MAX_ECC_KEY_BYTES];
+} TPM2B_ECC_PARAMETER;
+
+// Table 163 -- TPMS_ECC_POINT Structure <I/O>
+typedef struct {
+    TPM2B_ECC_PARAMETER    x;
+    TPM2B_ECC_PARAMETER    y;
+} TPMS_ECC_POINT;
+
+// Table 164 -- TPMI_ALG_ECC_SCHEME Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_ECC_SCHEME;
+
+typedef UINT16 TPM_ECC_CURVE;
+
+// Table 165 -- TPMI_ECC_CURVE Type <I/O>
+typedef TPM_ECC_CURVE TPMI_ECC_CURVE;
+
+// Table 166 -- TPMT_ECC_SCHEME Structure <I/O>
+typedef struct {
+    TPMI_ALG_ECC_SCHEME    scheme;
+    TPMU_SIG_SCHEME        details;
+} TPMT_ECC_SCHEME;
+
+// Table 175 -- TPMI_ALG_PUBLIC Type <I/O>
+typedef TPM_ALG_ID TPMI_ALG_PUBLIC;
+
+// Table 176 -- TPMU_PUBLIC_ID Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_KEYEDHASH
+    TPM2B_DIGEST  keyedHash;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPM2B_DIGEST  sym;
+#endif
+#ifdef TPM2_ALG_RSA
+    TPM2B_PUBLIC_KEY_RSA  rsa;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPMS_ECC_POINT  ecc;
+#endif
+} TPMU_PUBLIC_ID;
+
+// Table 177 -- TPMS_KEYEDHASH_PARMS Structure <I/O>
+typedef struct {
+    TPMT_KEYEDHASH_SCHEME    scheme;
+} TPMS_KEYEDHASH_PARMS;
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_ASYM_SCHEME       scheme;
+} TPMS_ASYM_PARMS;
+
+// Table 179 -- TPMS_RSA_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_RSA_SCHEME        scheme;
+    TPMI_RSA_KEY_BITS      keyBits;
+    UINT32                 exponent;
+} TPMS_RSA_PARMS;
+
+// Table 180 -- TPMS_ECC_PARMS Structure <I/O>
+typedef struct {
+    TPMT_SYM_DEF_OBJECT    symmetric;
+    TPMT_ECC_SCHEME        scheme;
+    TPMI_ECC_CURVE         curveID;
+    TPMT_KDF_SCHEME        kdf;
+} TPMS_ECC_PARMS;
+
+// Table 181 -- TPMU_PUBLIC_PARMS Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_KEYEDHASH
+    TPMS_KEYEDHASH_PARMS  keyedHashDetail;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPMT_SYM_DEF_OBJECT  symDetail;
+#endif
+#ifdef TPM2_ALG_RSA
+    TPMS_RSA_PARMS  rsaDetail;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPMS_ECC_PARMS  eccDetail;
+#endif
+    TPMS_ASYM_PARMS  asymDetail;
+} TPMU_PUBLIC_PARMS;
+
+// Table 182 -- TPMT_PUBLIC_PARMS Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC      type;
+    TPMU_PUBLIC_PARMS    parameters;
+} TPMT_PUBLIC_PARMS;
+
+// Table 183 -- TPMT_PUBLIC Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC      type;
+    TPMI_ALG_HASH        nameAlg;
+    TPMA_OBJECT          objectAttributes;
+    TPM2B_DIGEST         authPolicy;
+    TPMU_PUBLIC_PARMS    parameters;
+    TPMU_PUBLIC_ID       unique;
+} TPMT_PUBLIC;
+
+// Table 184 -- TPM2B_PUBLIC
+typedef struct {
+    UINT16         size;
+    TPMT_PUBLIC    publicArea;
+} TPM2B_PUBLIC;
+
+// Table 185 -- TPMU_SENSITIVE_COMPOSITE Union <I/O,S>
+typedef union {
+#ifdef TPM2_ALG_RSA
+    TPM2B_PRIVATE_KEY_RSA  rsa;
+#endif
+#ifdef TPM2_ALG_ECC
+    TPM2B_ECC_PARAMETER  ecc;
+#endif
+#ifdef TPM2_ALG_KEYEDHASH
+    TPM2B_SENSITIVE_DATA  bits;
+#endif
+#ifdef TPM2_ALG_SYMCIPHER
+    TPM2B_SYM_KEY  sym;
+#endif
+    TPM2B_SENSITIVE_DATA  any;
+} TPMU_SENSITIVE_COMPOSITE;
+
+// Table 186 -- TPMT_SENSITIVE Structure <I/O>
+typedef struct {
+    TPMI_ALG_PUBLIC             sensitiveType;
+    TPM2B_AUTH                  authValue;
+    TPM2B_DIGEST                seedValue;
+    TPMU_SENSITIVE_COMPOSITE    sensitive;
+} TPMT_SENSITIVE;
+
+// Table 187 -- TPM2B_SENSITIVE Structure <I/O>
+typedef struct {
+    UINT16            size;
+    TPMT_SENSITIVE    sensitiveArea;
+} TPM2B_SENSITIVE;
+
+typedef struct {
+    TPM2B_DIGEST      integrityOuter;
+    TPM2B_DIGEST      integrityInner;
+    TPMT_SENSITIVE    sensitive;
+} _PRIVATE;
+
+// Table 189 -- TPM2B_PRIVATE Structure <I/O,S>
+typedef struct {
+    UINT16    size;
+    BYTE      buffer[sizeof(_PRIVATE)];
+} TPM2B_PRIVATE;
+
+// Table 204 -- TPMS_CREATION_DATA <OUT>
+typedef struct {
+    TPML_PCR_SELECTION    pcrSelect;
+    TPM2B_DIGEST          pcrDigest;
+    TPMA_LOCALITY         locality;
+    TPM_ALG_ID            parentNameAlg;
+    TPM2B_NAME            parentName;
+    TPM2B_NAME            parentQualifiedName;
+    TPM2B_DATA            outsideInfo;
+} TPMS_CREATION_DATA;
+
+// Table 205 -- TPM2B_CREATION_DATA <OUT>
+typedef struct {
+    UINT16 size;
+    TPMS_CREATION_DATA creationData;
+} TPM2B_CREATION_DATA;
+
+/* the following structs is not part of standard struct defined in TPM2 spec */
+typedef struct {
+    UINT32            size;
+    TPM_RH            sessionHandle;
+    TPM2B_NONCE       nonce;
+    TPMA_SESSION      sessionAttributes;
+    TPM2B_AUTH        auth;
+} TPM_AuthArea;
+
+typedef struct {
+    TPM2B_SENSITIVE_CREATE  inSensitive;
+    TPM2B_PUBLIC            inPublic;
+    TPM2B_DATA              outsideInfo;
+    TPML_PCR_SELECTION      creationPCR;
+} TPM2_Create_Params_in;
+
+typedef TPM2_Create_Params_in    TPM2_CreatePrimary_Params_in;
+
+typedef struct {
+    TPM2B_PUBLIC        outPublic;
+    TPM2B_CREATION_DATA creationData;
+    TPM2B_DIGEST        creationHash;
+    TPMT_TK_CREATION    creationTicket;
+    TPM2B_NAME          name;
+} TPM2_CreatePrimary_Params_out;
+
+typedef struct {
+    TPM2B_PRIVATE       outPrivate;
+    TPM2B_PUBLIC        outPublic;
+    TPM2B_CREATION_DATA creationData;
+    TPM2B_DIGEST        creationHash;
+    TPMT_TK_CREATION    creationTicket;
+} TPM2_Create_Params_out;
+typedef struct {
+    TPM2B_PRIVATE    Private;
+    TPM2B_PUBLIC     Public;
+} TPM2_RSA_KEY;
+
+/*
+ * TPM 2.0 Objects
+ */
+
+#define TPM_HT_TRANSIENT        0x80
+#define HR_SHIFT                24
+#define HR_PERMANENT            (TPM_HT_TRANSIENT << HR_SHIFT)
+#define TRANSIENT_FIRST         (HR_PERMANENT)
+#define MAX_LOADED_OBJECTS      3
+#define TRANSIENT_LAST          (TRANSIENT_FIRST+MAX_LOADED_OBJECTS-1)
+/*
+ * TPMA_OBJECT Bits
+ */
+#define fixedTPM                ((1 << 1))
+#define stClear                 ((1 << 2))
+#define fixedParent             ((1 << 4))
+#define sensitiveDataOrigin     ((1 << 5))
+#define userWithAuth            ((1 << 6))
+#define adminWithPolicy         ((1 << 7))
+#define noDA                    ((1 << 10))
+#define encryptedDuplication    ((1 << 11))
+#define restricted              ((1 << 16))
+#define decrypt                 ((1 << 17))
+#define sign                    ((1 << 18))
+#endif
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzP-0001ly-Rv; Wed, 31 Dec 2014 09:54:51 +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 1Y6FzO-0001l3-5B
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:50 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	E8/A5-27623-9E7C3A45; Wed, 31 Dec 2014 09:54:49 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1420019687!16604833!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2788 invoked from network); 31 Dec 2014 09:54:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-3.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:48 -0000
Received: from orsmga003.jf.intel.com ([10.7.209.27])
	by orsmga103.jf.intel.com with ESMTP; 31 Dec 2014 01:51:49 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="506074501"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga003.jf.intel.com with ESMTP; 31 Dec 2014 01:49:31 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:54 -0500
Message-Id: <1420005054-25740-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 07/14] vTPM/TPM2: TPM2.0 TIS initialization
	and self test.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

call the TPM 2.0 various registers that allow communication between
the TPM 2.0 and platform hardware and software. TPM2_SelfTest causes
the TPM 2.0 to perform a test of its capabilities.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 extras/mini-os/include/tpm_tis.h |   1 +
 extras/mini-os/tpm_tis.c         | 156 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 157 insertions(+)

diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h
index 1faca0d..86e83f1 100644
--- a/extras/mini-os/include/tpm_tis.h
+++ b/extras/mini-os/include/tpm_tis.h
@@ -36,6 +36,7 @@
 struct tpm_chip;
 
 struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq);
+struct tpm_chip* init_tpm2_tis(unsigned long baseaddr, int localities, unsigned int irq);
 void shutdown_tpm_tis(struct tpm_chip* tpm);
 
 int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
index d78c465..debcc43 100644
--- a/extras/mini-os/tpm_tis.c
+++ b/extras/mini-os/tpm_tis.c
@@ -1363,5 +1363,161 @@ int tpm_tis_posix_fstat(int fd, struct stat* buf)
    return 0;
 }
 
+/* TPM 2.0 */
 
+/*TPM2.0 Selftest*/
+static void tpm2_selftest(struct tpm_chip* chip)
+{
+    uint8_t data[] = {
+        0x80, 0x1,
+        0x0, 0x0, 0x0, 0xb,
+        0x0, 0x0, 0x1, 0x43,
+        0x1,
+    };
+
+    tpm_transmit(chip, data, sizeof(data));
+}
+
+struct tpm_chip* init_tpm2_tis(unsigned long baseaddr, int localities, unsigned int irq)
+{
+    int i;
+    unsigned long addr;
+    struct tpm_chip* tpm = NULL;
+    uint32_t didvid;
+    uint32_t intfcaps;
+    uint32_t intmask;
+
+    printk("============= Init TPM2 TIS Driver ==============\n");
+
+    /*Sanity check the localities input */
+    if (localities & ~TPM_TIS_EN_LOCLALL) {
+        printk("init_tpm2_tis Invalid locality specification! %X\n", localities);
+        goto abort_egress;
+    }
+
+    printk("IOMEM Machine Base Address: %lX\n", baseaddr);
+
+    /* Create the tpm data structure */
+    tpm = malloc(sizeof(struct tpm_chip));
+    __init_tpm_chip(tpm);
+
+    /* Set the enabled localities - if 0 we leave default as all enabled */
+    if (localities != 0) {
+        tpm->enabled_localities = localities;
+    }
+    printk("Enabled Localities: ");
+    for (i = 0; i < 5; ++i) {
+        if (locality_enabled(tpm, i)) {
+            printk("%d ", i);
+        }
+    }
+    printk("\n");
+
+    /* Set the base machine address */
+    tpm->baseaddr = baseaddr;
+
+    /* Set default timeouts */
+    tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT);
+    tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT);
+    tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT);
+    tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT);
+
+    /*Map the mmio pages */
+    addr = tpm->baseaddr;
+    for (i = 0; i < 5; ++i) {
+        if (locality_enabled(tpm, i)) {
+
+            /* Map the page in now */
+            if ((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) {
+                printk("Unable to map iomem page a address %p\n", addr);
+                goto abort_egress;
+            }
+
+            /* Set default locality to the first enabled one */
+            if (tpm->locality < 0) {
+                if (tpm_tis_request_locality(tpm, i) < 0) {
+                    printk("Unable to request locality %d??\n", i);
+                    goto abort_egress;
+                }
+            }
+        }
+        addr += PAGE_SIZE;
+    }
+
+    /* Get the vendor and device ids */
+    didvid = ioread32(TPM_DID_VID(tpm, tpm->locality));
+    tpm->did = didvid >> 16;
+    tpm->vid = didvid & 0xFFFF;
+
+    /* Get the revision id */
+    tpm->rid = ioread8(TPM_RID(tpm, tpm->locality));
+    printk("2.0 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n",
+           tpm->did, tpm->vid, tpm->rid);
+
+    intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
+    printk("TPM interface capabilities (0x%x):\n", intfcaps);
+    if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
+        printk("\tBurst Count Static\n");
+    if (intfcaps & TPM_INTF_CMD_READY_INT)
+        printk("\tCommand Ready Int Support\n");
+    if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
+        printk("\tInterrupt Edge Falling\n");
+    if (intfcaps & TPM_INTF_INT_EDGE_RISING)
+        printk("\tInterrupt Edge Rising\n");
+    if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
+        printk("\tInterrupt Level Low\n");
+    if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
+        printk("\tInterrupt Level High\n");
+    if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
+        printk("\tLocality Change Int Support\n");
+    if (intfcaps & TPM_INTF_STS_VALID_INT)
+        printk("\tSts Valid Int Support\n");
+    if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
+        printk("\tData Avail Int Support\n");
+
+    /*Interupt setup */
+    intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
+
+    intmask |= TPM_INTF_CMD_READY_INT | TPM_INTF_LOCALITY_CHANGE_INT |
+               TPM_INTF_DATA_AVAIL_INT | TPM_INTF_STS_VALID_INT;
+
+    iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
+
+    /*If interupts are enabled, handle it */
+    if (irq) {
+        if (irq != TPM_PROBE_IRQ) {
+            tpm->irq = irq;
+        } else {
+        /*FIXME add irq probing feature later */
+        printk("IRQ probing not implemented\n");
+        }
+    }
+
+    if (tpm->irq) {
+        iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
+        if (bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) {
+            printk("Unabled to request irq: %u for use\n", tpm->irq);
+            printk("Will use polling mode\n");
+            tpm->irq = 0;
+        } else {
+
+            /* Clear all existing */
+            iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
+                                     ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
+
+            /* Turn on interrupts */
+            iowrite32(TPM_INT_ENABLE(tpm, tpm->locality),
+                                     intmask | TPM_GLOBAL_INT_ENABLE);
+        }
+    }
+
+    tpm2_selftest(tpm);
+    return tpm;
+
+abort_egress:
+    if (tpm != NULL) {
+        shutdown_tpm_tis(tpm);
+    }
+    return NULL;
+}
 #endif
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6Fz9-0001fI-JU; Wed, 31 Dec 2014 09:54:35 +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 1Y6Fz8-0001ez-8b
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:34 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	E7/05-25547-9D7C3A45; Wed, 31 Dec 2014 09:54:33 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1420019672!16589177!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21834 invoked from network); 31 Dec 2014 09:54:32 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-7.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:32 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga103.fm.intel.com with ESMTP; 31 Dec 2014 01:50:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="644906740"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 31 Dec 2014 01:54:30 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:42 -0500
Message-Id: <1420005042-25590-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 03/14] vTPM/TPM2: Add global data in
	vtpm_globals{}
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 data is for the Mini-os to access TPM 2.0 hardware.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/vtpmmgr.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 2d9d153..0d0c604 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -44,6 +44,7 @@
 #include "uuid.h"
 #include "tcg.h"
 #include "vtpm_manager.h"
+#include "tpm2_types.h"
 
 #define RSA_KEY_SIZE 0x0800
 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8)
@@ -59,6 +60,14 @@ struct vtpm_globals {
    ctr_drbg_context    ctr_drbg;
 
    int hw_locality;
+
+    /* TPM 2.0 */
+    TPM_AuthArea       pw_auth;
+    TPM_AuthArea       srk_auth_area;
+    TPM_HANDLE         srk_handle;
+    TPM_HANDLE         sk_handle;
+    TPM2B_NAME         sk_name;
+    TPM2_RSA_KEY       tpm2_storage_key;
 };
 
 struct tpm_opaque {
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzD-0001gM-Dk; Wed, 31 Dec 2014 09:54:39 +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 1Y6FzC-0001g6-G5
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:38 +0000
Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id
	EF/75-27623-DD7C3A45; Wed, 31 Dec 2014 09:54:37 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1420019675!16493359!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 15419 invoked from network); 31 Dec 2014 09:54:36 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:36 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by fmsmga101.fm.intel.com with ESMTP; 31 Dec 2014 01:54:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="662824605"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 31 Dec 2014 01:54:33 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:44 -0500
Message-Id: <1420005044-25627-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 04/14] vTPM/TPM2: Add TPM 2.0 Exposed APIs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 TPM 2.0 Exposed APIs for the Mini-os to access TPM 2.0
hardware.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/Makefile |   2 +-
 stubdom/vtpmmgr/tpm2.c   | 455 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2.h   | 104 +++++++++++
 3 files changed, 560 insertions(+), 1 deletion(-)
 create mode 100644 stubdom/vtpmmgr/tpm2.c
 create mode 100644 stubdom/vtpmmgr/tpm2.h

diff --git a/stubdom/vtpmmgr/Makefile b/stubdom/vtpmmgr/Makefile
index c5e17c5..6dae034 100644
--- a/stubdom/vtpmmgr/Makefile
+++ b/stubdom/vtpmmgr/Makefile
@@ -12,7 +12,7 @@
 XEN_ROOT=../..
 
 TARGET=vtpmmgr.a
-OBJS=vtpmmgr.o vtpm_cmd_handler.o init.o tpmrsa.o tpm.o log.o
+OBJS=vtpmmgr.o vtpm_cmd_handler.o init.o tpmrsa.o tpm.o tpm2.o log.o
 OBJS += vtpm_disk.o disk_tpm.o disk_io.o disk_crypto.o disk_read.o disk_write.o
 OBJS += mgmt_authority.o
 
diff --git a/stubdom/vtpmmgr/tpm2.c b/stubdom/vtpmmgr/tpm2.c
new file mode 100644
index 0000000..1903e27
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2.c
@@ -0,0 +1,455 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005/2006, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#include <stdio.h>
+#include <string.h>
+#include <malloc.h>
+#include <unistd.h>
+#include <errno.h>
+#include <polarssl/sha1.h>
+
+#include "tcg.h"
+#include "tpm.h"
+#include "tpm2.h"
+#include "log.h"
+#include "marshal.h"
+#include "tpm2_marshal.h"
+#include "tpmrsa.h"
+#include "vtpmmgr.h"
+
+#define TCPA_MAX_BUFFER_LENGTH 0x2000
+#define TPM_BEGIN(TAG, ORD) \
+    const TPM_TAG intag = TAG;\
+    TPM_TAG tag = intag;\
+    UINT32 paramSize;\
+    const TPM_COMMAND_CODE ordinal = ORD;\
+    TPM_RESULT status = TPM_SUCCESS;\
+    BYTE in_buf[TCPA_MAX_BUFFER_LENGTH];\
+    BYTE out_buf[TCPA_MAX_BUFFER_LENGTH];\
+    UINT32 out_len = sizeof(out_buf);\
+    BYTE* ptr = in_buf;\
+    /*Print a log message */\
+    vtpmloginfo(VTPM_LOG_TPM, "%s\n", __func__);\
+    /* Pack the header*/\
+    ptr = pack_TPM_TAG(ptr, tag);\
+    ptr += sizeof(UINT32);\
+    ptr = pack_TPM_COMMAND_CODE(ptr, ordinal)\
+
+#define TPM_AUTH_BEGIN() \
+    sha1_context sha1_ctx;\
+    BYTE* authbase = ptr - sizeof(TPM_COMMAND_CODE);\
+    TPM_DIGEST paramDigest;\
+    sha1_starts(&sha1_ctx)
+
+#define TPM_AUTH1_GEN(HMACkey, auth) do {\
+    sha1_finish(&sha1_ctx, paramDigest.digest);\
+    generateAuth(&paramDigest, HMACkey, auth);\
+    ptr = pack_TPM_AUTH_SESSION(ptr, auth);\
+} while(0)
+
+#define TPM_AUTH2_GEN(HMACkey, auth) do {\
+    generateAuth(&paramDigest, HMACkey, auth);\
+    ptr = pack_TPM_AUTH_SESSION(ptr, auth);\
+} while(0)
+
+#define TPM_TRANSMIT() do {\
+    /* Pack the command size */\
+    paramSize = ptr - in_buf;\
+    pack_UINT32(in_buf + sizeof(TPM_TAG), paramSize);\
+    if ((status = TPM_TransmitData(in_buf, paramSize, out_buf, &out_len)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH_VERIFY_BEGIN() do {\
+    UINT32 buf[2] = { cpu_to_be32(status), cpu_to_be32(ordinal) };\
+    sha1_starts(&sha1_ctx);\
+    sha1_update(&sha1_ctx, (unsigned char*)buf, sizeof(buf));\
+    authbase = ptr;\
+} while(0)
+
+#define TPM_AUTH1_VERIFY(HMACkey, auth) do {\
+    sha1_finish(&sha1_ctx, paramDigest.digest);\
+    ptr = unpack_TPM_AUTH_SESSION(ptr, auth);\
+    if ((status = verifyAuth(&paramDigest, HMACkey, auth)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH2_VERIFY(HMACkey, auth) do {\
+    ptr = unpack_TPM_AUTH_SESSION(ptr, auth);\
+    if ((status = verifyAuth(&paramDigest, HMACkey, auth)) != TPM_SUCCESS) {\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_UNPACK_VERIFY() do { \
+    ptr = out_buf;\
+    ptr = unpack_TPM_RSP_HEADER(ptr, \
+          &(tag), &(paramSize), &(status));\
+    if ((status) != TPM_SUCCESS){ \
+        vtpmlogerror(VTPM_LOG_TPM, "Failed with return code %s\n", tpm_get_error_name(status));\
+        goto abort_egress;\
+    }\
+} while(0)
+
+#define TPM_AUTH_HASH() do {\
+    sha1_update(&sha1_ctx, authbase, ptr - authbase);\
+    authbase = ptr;\
+} while(0)
+
+#define TPM_AUTH_SKIP() do {\
+    authbase = ptr;\
+} while(0)
+
+TPM_RC TPM2_PCR_Read(TPML_PCR_SELECTION pcrSelectionIn,
+                     UINT32 *pcrUpdateCounter,
+                     TPML_PCR_SELECTION *pcrSelectionOut,
+                     TPML_DIGEST *pcrValues)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS,TPM_CC_PCR_Read);
+
+    /*pack in*/
+    ptr =  pack_TPML_PCR_SELECTION(ptr, &pcrSelectionIn);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    /*unpack out*/
+    ptr = unpack_UINT32(ptr, pcrUpdateCounter);
+    ptr = unpack_TPML_PCR_SELECTION(ptr, pcrSelectionOut);
+    ptr = unpack_TPML_DIGEST(ptr, pcrValues);
+
+    goto egress;
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_Load(TPMI_DH_OBJECT parentHandle,
+                 TPM2B_PRIVATE *inPrivate, /* in */
+                 TPM2B_PUBLIC *inPublic, /* in */
+                 TPM_HANDLE *objectHandle, /* out */
+                 TPM2B_NAME *name /* out */)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Load);
+
+    /* pack handle of parent for new object */
+    ptr =  pack_UINT32(ptr, parentHandle);
+
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+    ptr = pack_TPM2B_PRIVATE(ptr, inPrivate);
+    ptr = pack_TPM2B_PUBLIC(ptr, inPublic);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    if (objectHandle != NULL) {
+        ptr = unpack_TPM_HANDLE(ptr, objectHandle);
+    } else {
+        TPM_HANDLE tmp;
+        ptr = unpack_TPM_HANDLE(ptr, &tmp);
+    }
+
+    if (name != NULL)
+        ptr = unpack_TPM2B_NAME(ptr, name);
+    goto egress;
+
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_Create(TPMI_DH_OBJECT parentHandle,
+                   TPM2_Create_Params_in *in,
+                   TPM2_Create_Params_out *out)
+{
+    UINT32 param_size;
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Create);
+
+    /* pack handle of parent for new object */
+    ptr =  pack_UINT32(ptr, parentHandle);
+
+    /* pack Auth Area */
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+
+    /* pack inSensitive */
+    ptr = pack_TPM2B_SENSITIVE_CREATE(ptr, &in->inSensitive);
+
+    /* pack inPublic */
+    ptr = pack_TPM2B_PUBLIC(ptr, &in->inPublic);
+
+    /* pack outside Info */
+    ptr = pack_TPM2B_DATA(ptr, &in->outsideInfo);
+
+    /* pack createPCR */
+    ptr = pack_TPML_PCR_SELECTION(ptr, &in->creationPCR);
+
+    /* Send the command to the tpm */
+    TPM_TRANSMIT();
+
+    /* Unpack and validate the header */
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT32(ptr, &param_size);
+    if (out != NULL) {
+        ptr = unpack_TPM2B_PRIVATE(ptr, &vtpm_globals.tpm2_storage_key.Private);
+        ptr = unpack_TPM2B_PUBLIC(ptr, &vtpm_globals.tpm2_storage_key.Public);
+        ptr = unpack_TPM2B_CREATION_DATA(ptr, &out->creationData);
+        ptr = unpack_TPM2B_DIGEST(ptr, &out->creationHash);
+        ptr = unpack_TPMT_TK_CREATION(ptr, &out->creationTicket);
+    } else {
+           ptr += param_size;
+    }
+    goto egress;
+
+abort_egress:
+egress:
+    return status;
+}
+
+TPM_RC TPM2_CreatePrimary(TPMI_RH_HIERARCHY primaryHandle,
+                          TPM2_Create_Params_in *in,
+                          TPM_HANDLE *objHandle,
+                          TPM2_Create_Params_out *out)
+{
+    UINT32 param_size;
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_CreatePrimary);
+
+    /* pack primary handle */
+    ptr = pack_UINT32(ptr, primaryHandle);
+
+    /* pack Auth Area */
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+
+    /* pack inSenstive */
+    ptr = pack_TPM2B_SENSITIVE_CREATE(ptr, &in->inSensitive);
+
+    /* pack inPublic */
+    ptr = pack_TPM2B_PUBLIC(ptr, &in->inPublic);
+
+    /* pack outsideInfo */
+    ptr = pack_TPM2B_DATA(ptr, &in->outsideInfo);
+
+    /* pack creationPCR */
+    ptr = pack_TPML_PCR_SELECTION(ptr, &in->creationPCR);
+
+    /* Send the command to the tpm */
+    TPM_TRANSMIT();
+
+    /* Unpack and validate the header */
+    TPM_UNPACK_VERIFY();
+
+    if (objHandle != NULL)
+        ptr = unpack_TPM_HANDLE(ptr, objHandle);
+    else {
+        TPM_HANDLE handle;
+        ptr = unpack_TPM_HANDLE(ptr, &handle);
+    }
+    ptr = unpack_UINT32(ptr, &param_size);
+
+    if (out != NULL) {
+        ptr = unpack_TPM2B_PUBLIC(ptr, &out->outPublic);
+        ptr = unpack_TPM2B_CREATION_DATA(ptr, &out->creationData);
+        ptr = unpack_TPM2B_DIGEST(ptr, &out->creationHash);
+        ptr = unpack_TPMT_TK_CREATION(ptr, &out->creationTicket);
+    } else {
+        ptr += param_size;
+    }
+
+goto egress;
+
+abort_egress:
+egress:
+   return status;
+}
+
+TPM_RC TPM2_HierachyChangeAuth(TPMI_RH_HIERARCHY_AUTH authHandle, TPM2B_AUTH *newAuth)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_HierarchyChangeAuth);
+    ptr = pack_UINT32(ptr, authHandle);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+    ptr = pack_TPM2B_AUTH(ptr, newAuth);
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_RSA_ENCRYPT(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *message,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *outData)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_RSA_Encrypt);
+
+    ptr = pack_UINT32(ptr, keyHandle);
+    ptr = pack_TPM2B_PUBLIC_KEY_RSA(ptr, message);
+    ptr = pack_TPMT_RSA_DECRYPT(ptr, inScheme);
+    ptr = pack_TPM2B_DATA(ptr, label);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    if (outData != NULL)
+        unpack_TPM2B_PUBLIC_KEY_RSA(ptr, outData);
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_Bind(TPMI_DH_OBJECT keyHandle,
+                 void *buf,
+                 UINT32 len,
+                 void *out)
+{
+    TPM_RC status = TPM_SUCCESS;
+    TPM2B_PUBLIC_KEY_RSA message;
+    TPMT_RSA_DECRYPT inScheme;
+    TPM2B_DATA label;
+    TPM2B_PUBLIC_KEY_RSA outData;
+
+    message.size = len;
+    memcpy(message.buffer, buf, len);
+    inScheme.scheme = TPM2_ALG_NULL;
+    label.size = 0;
+    TPMTRYRETURN(TPM2_RSA_ENCRYPT(keyHandle, &message, &inScheme, &label, &outData));
+    memcpy(out, outData.buffer, outData.size);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_RSA_Decrypt(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *cipherText,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *message)
+{
+    UINT32 param_size;
+
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_RSA_Decrypt);
+    ptr = pack_UINT32(ptr, keyHandle);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.srk_auth_area);
+    ptr = pack_TPM2B_PUBLIC_KEY_RSA(ptr, cipherText);
+    ptr = pack_TPMT_RSA_DECRYPT(ptr, inScheme);
+    ptr = pack_TPM2B_DATA(ptr, label);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT32(ptr, &param_size);
+
+    if (message)
+        ptr = unpack_TPM2B_PUBLIC_KEY_RSA(ptr, message);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_UnBind(TPMI_DH_OBJECT keyHandle,
+                   UINT32 ilen,
+                   void *in,
+                   UINT32 *olen,
+                   void *out)
+{
+    UINT32 status;
+    TPM2B_PUBLIC_KEY_RSA cipher, message;
+    TPMT_RSA_DECRYPT inScheme;
+    TPM2B_DATA label;
+
+    cipher.size = ilen;
+    memcpy(cipher.buffer, in, ilen);
+    inScheme.scheme = TPM2_ALG_NULL;
+    label.size = 0;
+
+    TPMTRYRETURN(TPM2_RSA_Decrypt(keyHandle, &cipher, &inScheme, &label, &message));
+
+    *olen = message.size;
+    memcpy(out, message.buffer, *olen);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_CLEAR(void)
+{
+    TPM_BEGIN(TPM_ST_SESSIONS, TPM_CC_Clear);
+
+    ptr = pack_UINT32(ptr, TPM_RH_PLATFORM);
+    ptr = pack_TPM_AuthArea(ptr, &vtpm_globals.pw_auth);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_GetRandom(UINT32 * bytesRequested, BYTE * randomBytes)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_GetRandom);
+
+    ptr = pack_UINT16(ptr, (UINT16)*bytesRequested);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+    ptr = unpack_UINT16(ptr, (UINT16 *)bytesRequested);
+    ptr = unpack_TPM_BUFFER(ptr, randomBytes, *bytesRequested);
+
+abort_egress:
+    return status;
+}
+
+TPM_RC TPM2_FlushContext(TPMI_DH_CONTEXT flushHandle)
+{
+    TPM_BEGIN(TPM_ST_NO_SESSIONS, TPM_CC_FlushContext);
+
+    ptr = pack_UINT32(ptr, flushHandle);
+
+    TPM_TRANSMIT();
+    TPM_UNPACK_VERIFY();
+
+abort_egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/tpm2.h b/stubdom/vtpmmgr/tpm2.h
new file mode 100644
index 0000000..9f597ee
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2.h
@@ -0,0 +1,104 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005/2006, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef __TPM2_H__
+#define __TPM2_H__
+
+#include "tcg.h"
+#include "tpm2_types.h"
+
+// ------------------------------------------------------------------
+// TPM 2.0 Exposed API
+// ------------------------------------------------------------------
+
+TPM_RC TPM2_PCR_Read(TPML_PCR_SELECTION pcrSelectionIn,
+                     UINT32 *pcrUpdateCounter,
+                     TPML_PCR_SELECTION *pcrSelectionOut,
+                     TPML_DIGEST *pcrValues);
+
+TPM_RC TPM2_Load(TPMI_DH_OBJECT parentHandle,
+                 TPM2B_PRIVATE *inPrivate,
+                 TPM2B_PUBLIC *inPublic,
+                 TPM_HANDLE *objectHandle,
+                 TPM2B_NAME *name);
+
+TPM_RC TPM2_Create(TPMI_DH_OBJECT parentHandle,
+                   TPM2_Create_Params_in *in,
+                   TPM2_Create_Params_out *out);
+
+TPM_RC TPM2_CreatePrimary(TPMI_RH_HIERARCHY primaryHandle,
+                          TPM2_Create_Params_in *objHandle,
+                          TPM_HANDLE *in,
+                          TPM2_Create_Params_out *out);
+
+TPM_RC TPM2_HierachyChangeAuth(TPMI_RH_HIERARCHY_AUTH authHandle,
+                               TPM2B_AUTH *newAuth);
+
+TPM_RC TPM2_RSA_ENCRYPT(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *message,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *outData);
+
+TPM_RC TPM2_Bind(TPMI_DH_OBJECT keyHandle,
+                 void *buf,
+                 UINT32 len,
+                 void *out);
+
+TPM_RC TPM2_RSA_Decrypt(TPMI_DH_OBJECT keyHandle,
+                        TPM2B_PUBLIC_KEY_RSA *cipherText,
+                        TPMT_RSA_DECRYPT *inScheme,
+                        TPM2B_DATA *label,
+                        TPM2B_PUBLIC_KEY_RSA *message);
+
+TPM_RC TPM2_UnBind(TPMI_DH_OBJECT keyHandle,
+                   UINT32 ilen,
+                   void *in,
+                   UINT32 *olen,
+                   void *out);
+
+TPM_RESULT TPM2_GetRandom(UINT32* bytesRequested,
+                          BYTE* randomBytes);
+
+TPM_RC TPM2_CLEAR(void);
+
+TPM_RC TPM2_FlushContext(TPMI_DH_CONTEXT);
+#endif //TPM2_H
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzT-0001nz-Lt; Wed, 31 Dec 2014 09:54:55 +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 1Y6FzS-0001n9-Im
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:54 +0000
Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id
	15/D2-31453-DE7C3A45; Wed, 31 Dec 2014 09:54:53 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1420019692!8164647!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9921 invoked from network); 31 Dec 2014 09:54:53 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-206.messagelabs.com with SMTP;
	31 Dec 2014 09:54:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 31 Dec 2014 01:54:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="644906789"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga001.fm.intel.com with ESMTP; 31 Dec 2014 01:54:49 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:51:01 -0500
Message-Id: <1420005061-25816-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 09/14] vTPM/TPM2: Support 'tpm2' extra
	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>
MIME-Version: 1.0
Content-Type: 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 vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
Add:
..
     extra="tpm2"
..
to launch vtpm-stubdom domain on TPM 2.0, ignore it on TPM 1.x. for
example,
vtpm-stubdom domain configuration on TPM 2.0:

  kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
  memory=16
  disk=["file:/var/scale/vdisk/vmgr,hda,w"]
  name="vtpmmgr"
  iomem=["fed40,5"]
  extra="tpm2"

vtpm-stubdom domain configuration on TPM 1.x:

  kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
  memory=16
  disk=["file:/var/scale/vdisk/vmgr,hda,w"]
  name="vtpmmgr"
  iomem=["fed40,5"]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/vtpmmgr.c | 46 ++++++++++++++++++++++++++++++++++++++++------
 stubdom/vtpmmgr/vtpmmgr.h | 14 ++++++++++++++
 2 files changed, 54 insertions(+), 6 deletions(-)

diff --git a/stubdom/vtpmmgr/vtpmmgr.c b/stubdom/vtpmmgr/vtpmmgr.c
index 270ca8a..f743ca6 100644
--- a/stubdom/vtpmmgr/vtpmmgr.c
+++ b/stubdom/vtpmmgr/vtpmmgr.c
@@ -45,6 +45,27 @@
 #include "vtpmmgr.h"
 #include "tcg.h"
 
+struct tpm_hardware_version hardware_version = {
+    .hw_version = TPM1_HARDWARE,
+};
+
+int parse_cmdline_hw(int argc, char** argv)
+{
+    int i;
+
+    for (i = 1; i < argc; ++i) {
+        if (!strncmp(argv[i], TPM2_EXTRA_OPT, 4)) {
+            hardware_version.hw_version = TPM2_HARDWARE;
+            break;
+        }
+    }
+    return 0;
+}
+
+int hw_is_tpm2(void)
+{
+    return (hardware_version.hw_version == TPM2_HARDWARE) ? 1 : 0;
+}
 
 void main_loop(void) {
    tpmcmd_t* tpmcmd;
@@ -74,12 +95,25 @@ int main(int argc, char** argv)
    sleep(2);
    vtpmloginfo(VTPM_LOG_VTPM, "Starting vTPM manager domain\n");
 
-   /* Initialize the vtpm manager */
-   if(vtpmmgr_init(argc, argv) != TPM_SUCCESS) {
-      vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
-      rc = -1;
-      goto exit;
-   }
+    /*Parse TPM hardware in extra command line*/
+    parse_cmdline_hw(argc, argv);
+
+    /* Initialize the vtpm manager */
+    if (hw_is_tpm2()) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Hardware : --- TPM 2.0 ---\n");
+        if (vtpmmgr2_init(argc, argv) != TPM_SUCCESS) {
+            vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
+            rc = -1;
+            goto exit;
+        }
+    }else{
+        vtpmloginfo(VTPM_LOG_VTPM, "Hardware : --- TPM 1.x ---\n");
+        if (vtpmmgr_init(argc, argv) != TPM_SUCCESS) {
+            vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize vtpmmgr domain!\n");
+            rc = -1;
+            goto exit;
+        }
+    }
 
    main_loop();
 
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index c479443..6a76af4 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -46,9 +46,21 @@
 #include "vtpm_manager.h"
 #include "tpm2_types.h"
 
+#define TPM2_EXTRA_OPT "tpm2"
 #define RSA_KEY_SIZE 0x0800
 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8)
 
+enum {
+    TPM1_HARDWARE = 1,
+    TPM2_HARDWARE,
+} tpm_version;
+
+struct tpm_hardware_version {
+    int hw_version;
+};
+
+extern struct tpm_hardware_version hardware_version;
+
 struct vtpm_globals {
    int tpm_fd;
    TPM_AUTH_SESSION    oiap;                // OIAP session for storageKey
@@ -97,5 +109,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 TPM_RC tpm2_take_ownership(void);
 TPM_RESULT vtpmmgr2_create(void);
 TPM_RESULT vtpmmgr2_init(int argc, char** argv);
+int parse_cmdline_hw(int argc, char** argv);
+int hw_is_tpm2(void);
 
 #endif
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzG-0001hp-18; Wed, 31 Dec 2014 09:54:42 +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 1Y6FzE-0001go-Bc
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:40 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	D2/60-09284-FD7C3A45; Wed, 31 Dec 2014 09:54:39 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1420019675!16493359!2
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 15554 invoked from network); 31 Dec 2014 09:54:39 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:39 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by fmsmga101.fm.intel.com with ESMTP; 31 Dec 2014 01:54:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="631131292"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 31 Dec 2014 01:54:37 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:48 -0500
Message-Id: <1420005048-25666-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 05/14] vTPM/TPM2: TPM 2.0 takes ownership and
	create SRK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TPM2_CreatePrimary is used to create a Primary Object under one of
the Primary Seeds or a Temporary Object under TPM_RH_NULL. The command
uses a TPM2B_PUBLIC as a template for the object to be created. The
command will create and load a Primary Object. The sensitive area is
not returned. Any type of object and attributes combination that is
allowed by TPM2_Create() may be created by this command. The constraints
on templates and parameters are the same as TPM2_Create() except that a
Primary Storage Key and a Temporary Storage Key are not constrained to
use the algorithms of their parents.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/init.c    | 71 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.h |  3 ++
 2 files changed, 74 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index f3aa02f..c654071 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -51,6 +51,7 @@
 #include "vtpm_disk.h"
 #include "tpm.h"
 #include "marshal.h"
+#include "tpm2.h"
 
 struct Opts {
    enum {
@@ -509,3 +510,73 @@ void vtpmmgr_shutdown(void)
 
    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager stopped.\n");
 }
+
+/* TPM 2.0 */
+
+static void tpm2_AuthArea_ctor(const char *authValue, UINT32 authLen,
+                               TPM_AuthArea *auth)
+{
+    auth->sessionHandle = TPM_RS_PW;
+    auth->nonce.size = 0;
+    auth->sessionAttributes = 1;
+    auth->auth.size = authLen;
+    memcpy(auth->auth.buffer, authValue, authLen);
+    auth->size = 9 + authLen;
+}
+
+TPM_RC tpm2_take_ownership(void)
+{
+    TPM_RC status = TPM_SUCCESS;
+
+    tpm2_AuthArea_ctor(NULL, 0, &vtpm_globals.pw_auth);
+
+    /* create SRK */
+    TPM2_CreatePrimary_Params_in in = {
+        .inSensitive = {
+            .size = 4,
+            .sensitive = {
+                .userAuth.size = 0,
+                .userAuth.buffer = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\
+                                     0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+                .data.size = 0,
+            },
+        },
+        .inPublic = {
+            .size = 60,
+            .publicArea = {
+                .type = TPM2_ALG_RSA,
+                .nameAlg = TPM2_ALG_SHA256,
+#define SRK_OBJ_ATTR (fixedTPM | fixedParent  | userWithAuth | \
+                      sensitiveDataOrigin | restricted | decrypt)
+                .objectAttributes = SRK_OBJ_ATTR,
+                .authPolicy.size = 0,
+                .parameters.rsaDetail = {
+                    .symmetric = {
+                    .algorithm = TPM2_ALG_AES,
+                    .keyBits.aes = AES_KEY_SIZES_BITS,
+                    .mode.aes = TPM2_ALG_CFB,
+                    },
+                .scheme = { TPM2_ALG_NULL },
+                .keyBits = RSA_KEY_SIZES_BITS,
+                .exponent = 0,
+                },
+                .unique.rsa.size = 0,
+            },
+        },
+            .outsideInfo.size = 0,
+            .creationPCR.count = 0,
+    };
+
+    TPMTRYRETURN(TPM2_CreatePrimary(TPM_RH_OWNER,&in,
+                                    &vtpm_globals.srk_handle, NULL));
+    vtpmloginfo(VTPM_LOG_VTPM, "SRK handle: 0x%X\n", vtpm_globals.srk_handle);
+    {
+        const char data[20] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\
+                                0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+        tpm2_AuthArea_ctor(data, 20, &vtpm_globals.srk_auth_area);
+    }
+    /*end create SRK*/
+
+abort_egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 0d0c604..95519ba 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -93,4 +93,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
    return ctr_drbg_random(&vtpm_globals.ctr_drbg, bytes, num_bytes) == 0 ? 0 : TPM_FAIL;
 }
 
+/* TPM 2.0 */
+TPM_RC tpm2_take_ownership(void);
+
 #endif
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzJ-0001jS-El; Wed, 31 Dec 2014 09:54:45 +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 1Y6FzI-0001id-1o
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:44 +0000
Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id
	D9/66-07724-3E7C3A45; Wed, 31 Dec 2014 09:54:43 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-4.tower-31.messagelabs.com!1420019682!16534971!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 13639 invoked from network); 31 Dec 2014 09:54:42 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-4.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:42 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by orsmga102.jf.intel.com with ESMTP; 31 Dec 2014 01:52:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="435269258"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 31 Dec 2014 01:42:40 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:51 -0500
Message-Id: <1420005051-25703-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
MIME-Version: 1.0
Content-Length: 6274
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 06/14] vTPM/TPM2: Create and load SK on TPM
	2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VFBNMl9DcmVhdGUgaXMgdXNlZCB0byBjcmVhdGUgYW4gb2JqZWN0IHRoYXQgY2FuIGJlIGxvYWRl
ZCBpbnRvIGEKVFBNIHVzaW5nIFRQTTJfTG9hZCgpLiBJZiB0aGUgY29tbWFuZCBjb21wbGV0ZXMg
c3VjY2Vzc2Z1bGx5LCB0aGUKVFBNIHdpbGwgY3JlYXRlIHRoZSBuZXcgb2JqZWN0IGFuZCByZXR1
cm4gdGhlIG9iamVjdOKAmXMgY3JlYXRpb24uCmRhdGEgKGNyZWF0aW9uRGF0YSksIGl0cyBwdWJs
aWMgYXJlYSAob3V0UHVibGljKSwgYW5kIGl0cyBlbmNyeXB0ZWQKc2Vuc2l0aXZlIGFyZWEgKG91
dFByaXZhdGUpLiBQcmVzZXJ2YXRpb24gb2YgdGhlIHJldHVybmVkIGRhdGEgaXMKdGhlIHJlc3Bv
bnNpYmlsaXR5IG9mIHRoZSBjYWxsZXIuIFRoZSBvYmplY3Qgd2lsbCBuZWVkIHRvIGJlIGxvYWRl
ZAooVFBNMl9Mb2FkKCkpLgpUUE0yX0xvYWQgaXMgdXNlZCB0byBsb2FkIG9iamVjdHMgaW50byB0
aGUgVFBNLiBUaGlzIGNvbW1hbmQgaXMgdXNlZAp3aGVuIGJvdGggYSBUUE0yQl9QVUJMSUMgYW5k
IFRQTTJCX1BSSVZBVEUgYXJlIHRvIGJlIGxvYWRlZC4gSWYgb25seQphIFRQTTJCX1BVQkxJQyBp
cyB0byBiZSBsb2FkZWQsIHRoZSBUUE0yX0xvYWRFeHRlcm5hbCBjb21tYW5kIGlzIHVzZWQuCgpT
aWduZWQtb2ZmLWJ5OiBRdWFuIFh1IDxxdWFuLnh1QGludGVsLmNvbT4KLS0tCiBzdHViZG9tL3Z0
cG1tZ3IvaW5pdC5jICAgIHwgMTAxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysKIHN0dWJkb20vdnRwbW1nci92dHBtbWdyLmggfCAgIDEgKwogMiBmaWxlcyBj
aGFuZ2VkLCAxMDIgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3N0dWJkb20vdnRwbW1nci9p
bml0LmMgYi9zdHViZG9tL3Z0cG1tZ3IvaW5pdC5jCmluZGV4IGM2NTQwNzEuLjgyNDRiYjAgMTAw
NjQ0Ci0tLSBhL3N0dWJkb20vdnRwbW1nci9pbml0LmMKKysrIGIvc3R1YmRvbS92dHBtbWdyL2lu
aXQuYwpAQCAtNTgwLDMgKzU4MCwxMDQgQEAgVFBNX1JDIHRwbTJfdGFrZV9vd25lcnNoaXAodm9p
ZCkKIGFib3J0X2VncmVzczoKICAgICByZXR1cm4gc3RhdHVzOwogfQorCitUUE1fUkVTVUxUIHZ0
cG1tZ3IyX2NyZWF0ZSh2b2lkKQoreworICAgIFRQTV9SRVNVTFQgc3RhdHVzID0gVFBNX1NVQ0NF
U1M7CisKKyAgICBUUE1UUllSRVRVUk4odHBtMl90YWtlX293bmVyc2hpcCgpKTsKKworICAgLyog
Y3JlYXRlIFNLICovCisgICAgVFBNMl9DcmVhdGVfUGFyYW1zX291dCBvdXQ7CisgICAgVFBNMl9D
cmVhdGVfUGFyYW1zX2luIGluID0geworICAgICAgICAuaW5TZW5zaXRpdmUgPSB7CisgICAgICAg
ICAgICAuc2l6ZSA9IDQgKyAyMCwKKyAgICAgICAgICAgIC5zZW5zaXRpdmUgPSB7CisgICAgICAg
ICAgICAgICAgLnVzZXJBdXRoLnNpemUgPSAyMCwKKyAgICAgICAgICAgICAgICAudXNlckF1dGgu
YnVmZmVyID0geyAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLFwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAwIH0sCisg
ICAgICAgICAgICAgICAgLmRhdGEuc2l6ZSA9IDAsCisgICAgICAgICAgICB9LAorICAgICAgICB9
LAorICAgICAgICAuaW5QdWJsaWMgPSB7CisgICAgICAgICAgICAuc2l6ZSA9ICg2MCksCisgICAg
ICAgICAgICAucHVibGljQXJlYSA9IHsKKyAgICAgICAgICAgICAgICAgLnR5cGUgPSBUUE0yX0FM
R19SU0EsCisgICAgICAgICAgICAgICAgIC5uYW1lQWxnID0gVFBNMl9BTEdfU0hBMjU2LAorI2Rl
ZmluZSBTS19PQkpfQVRUUiAoZml4ZWRUUE0gfCBmaXhlZFBhcmVudCB8IHVzZXJXaXRoQXV0aCB8
XAorICAgICAgICAgICAgICAgICAgICAgc2Vuc2l0aXZlRGF0YU9yaWdpbiB8ZGVjcnlwdCkKKyAg
ICAgICAgICAgICAgICAgLm9iamVjdEF0dHJpYnV0ZXMgPSBTS19PQkpfQVRUUiwKKyAgICAgICAg
ICAgICAgICAgLmF1dGhQb2xpY3kuc2l6ZSA9IDAsCisgICAgICAgICAgICAgICAgIC5wYXJhbWV0
ZXJzLnJzYURldGFpbCA9IHsKKyAgICAgICAgICAgICAgICAgICAgIC5zeW1tZXRyaWMgPSB7Cisg
ICAgICAgICAgICAgICAgICAgICAgICAgLmFsZ29yaXRobSA9IFRQTTJfQUxHX05VTEwsCisgICAg
ICAgICAgICAgICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgICAgLnNjaGVtZSA9IHsKKyAg
ICAgICAgICAgICAgICAgICAgICAgICBUUE0yX0FMR19PQUVQLAorICAgICAgICAgICAgICAgICAg
ICAgICAgIC5kZXRhaWxzLm9hZXAuaGFzaEFsZyA9IFRQTTJfQUxHX1NIQTI1NiwKKyAgICAgICAg
ICAgICAgICAgICAgIH0sCisgICAgICAgICAgICAgICAgICAgICAua2V5Qml0cyA9IFJTQV9LRVlf
U0laRVNfQklUUywKKyAgICAgICAgICAgICAgICAgICAgIC5leHBvbmVudCA9IDAsCisgICAgICAg
ICAgICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgLnVuaXF1ZS5yc2Euc2l6ZSA9IDAsCisg
ICAgICAgICAgICB9LAorICAgICAgICB9LAorICAgICAgICAub3V0c2lkZUluZm8uc2l6ZSA9IDAs
CisgICAgICAgIC5jcmVhdGlvblBDUi5jb3VudCA9IDAsCisgICAgfTsvKmVuZCBpbiAqLworCisg
ICAgVFBNVFJZUkVUVVJOKFRQTTJfQ3JlYXRlKHZ0cG1fZ2xvYmFscy5zcmtfaGFuZGxlLCAmaW4s
ICZvdXQpKTsKKyAgICBUUE1UUllSRVRVUk4oVFBNMl9Mb2FkKHZ0cG1fZ2xvYmFscy5zcmtfaGFu
ZGxlLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZ0cG1fZ2xvYmFscy50cG0yX3N0b3Jh
Z2Vfa2V5LlByaXZhdGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAmdnRwbV9nbG9iYWxz
LnRwbTJfc3RvcmFnZV9rZXkuUHVibGljLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgJnZ0
cG1fZ2xvYmFscy5za19oYW5kbGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAmdnRwbV9n
bG9iYWxzLnNrX25hbWUpKTsKKworICAgIHZ0cG1sb2dpbmZvKFZUUE1fTE9HX1ZUUE0sICJTSyBI
QU5ETEU6IDB4JVhcbiIsIHZ0cG1fZ2xvYmFscy5za19oYW5kbGUpOworICAgIC8qZW5kIGNyZWF0
ZSBTSyovCisKKyNpZiAwIC8qQmluZCAmIHVuQmluZCovCit7CisgICAgdW5zaWduZWQgY2hhciBy
YW5kWzIwXTsKKyAgICB1bnNpZ25lZCBjaGFyIGNpcGhlclsyNTZdLCBvdXRbMjU2XTsKKyAgICB2
dHBtbWdyX3JhbmQocmFuZCwgMjApOworICAgIGludCBpOworICAgIFVJTlQzMiBvbGVuOworCisg
ICAgcHJpbnRrKCJyYW5kOiAiKTsKKyAgICBmb3IgKGkgPSAwOyBpIDwgMjA7IGkrKykgeworICAg
ICAgICAgcHJpbnRrKCIgJXUgIiwgcmFuZFtpXSk7CisgICAgfQorICAgIHByaW50aygiXG4iKTsK
KyAgICBUUE1UUllSRVRVUk4oVFBNMl9CaW5kKHZ0cG1fZ2xvYmFscy5za19oYW5kbGUsCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICByYW5kLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg
MjAsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBjaXBoZXIpKTsKKyAgICBwcmludGsoImNp
cGhlciA6ICIpOworICAgIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykgeworICAgICAgICAgcHJp
bnRrKCIlMDJ4IiwgY2lwaGVyW2ldKTsKKyAgICB9CisgICAgcHJpbnRrKCJcbiIpOworICAgIFRQ
TVRSWVJFVFVSTihUUE0yX1VuQmluZCh2dHBtX2dsb2JhbHMuc2tfaGFuZGxlLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAyNTYsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNp
cGhlciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJm9sZW4sCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG91dCkpOworICAgIHByaW50aygib2xlbiA6ICVkIFxuIiwgb2xlbik7
CisgICAgcHJpbnRrKCJvdXQgOiAiKTsKKyAgICBmb3IgKGkgPSAwOyBpIDwgb2xlbjsgaSsrKQor
ICAgICAgICAgcHJpbnRrKCIgJXUgIiwgb3V0W2ldKTsKKyAgICBwcmludGsoIlxuIik7Cit9Cisj
ZW5kaWYKKworICAgIC8qQ3JlYXRlIG5ldyBkaXNrIGltYWdlKi8KKyAgICBUUE1UUllSRVRVUk4o
dnRwbV9uZXdfZGlzaygpKTsKKworICAgIGdvdG8gZWdyZXNzOworCithYm9ydF9lZ3Jlc3M6Citl
Z3Jlc3M6CisgICAgdnRwbWxvZ2luZm8oVlRQTV9MT0dfVlRQTSwgIkZpbmlzaGVkIGluaXRpYWxp
emVkIG5ldyBWVFBNIG1hbmFnZXJcbiIpOworICAgIHJldHVybiBzdGF0dXM7Cit9CmRpZmYgLS1n
aXQgYS9zdHViZG9tL3Z0cG1tZ3IvdnRwbW1nci5oIGIvc3R1YmRvbS92dHBtbWdyL3Z0cG1tZ3Iu
aAppbmRleCA5NTUxOWJhLi45ODg5ZmViIDEwMDY0NAotLS0gYS9zdHViZG9tL3Z0cG1tZ3IvdnRw
bW1nci5oCisrKyBiL3N0dWJkb20vdnRwbW1nci92dHBtbWdyLmgKQEAgLTk1LDUgKzk1LDYgQEAg
aW5saW5lIFRQTV9SRVNVTFQgdnRwbW1ncl9yYW5kKHVuc2lnbmVkIGNoYXIqIGJ5dGVzLCBzaXpl
X3QgbnVtX2J5dGVzKSB7CiAKIC8qIFRQTSAyLjAgKi8KIFRQTV9SQyB0cG0yX3Rha2Vfb3duZXJz
aGlwKHZvaWQpOworVFBNX1JFU1VMVCB2dHBtbWdyMl9jcmVhdGUodm9pZCk7CiAKICNlbmRpZgot
LSAKMS44LjMuMgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzR-0001mi-8D; Wed, 31 Dec 2014 09:54:53 +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 1Y6FzO-0001lR-Ty
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:51 +0000
Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id
	B0/D7-05632-AE7C3A45; Wed, 31 Dec 2014 09:54:50 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-31.messagelabs.com!1420019687!16604833!2
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2906 invoked from network); 31 Dec 2014 09:54:49 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-3.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:49 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by orsmga103.jf.intel.com with ESMTP; 31 Dec 2014 01:51:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="655296195"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 31 Dec 2014 01:54:47 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:58 -0500
Message-Id: <1420005058-25779-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 08/14] vTPM/TPM2: Add main entrance
	vtpmmgr2_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

Accept commands from the vtpm-stubdom domains via the mini-os TPM
backend driver. The vTPM manager communicates directly with hardware
TPM 2.0 using the mini-os tpm2_tis driver.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/init.c    | 109 ++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.h |   1 +
 2 files changed, 110 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 8244bb0..7e115a5 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -681,3 +681,112 @@ egress:
     vtpmloginfo(VTPM_LOG_VTPM, "Finished initialized new VTPM manager\n");
     return status;
 }
+
+static int tpm2_entropy_source(void* dummy, unsigned char* data,
+                               size_t len, size_t* olen)
+{
+    UINT32 sz = len;
+    TPM_RESULT rc = TPM2_GetRandom(&sz, data);
+    *olen = sz;
+    return rc == TPM_SUCCESS ? 0 : POLARSSL_ERR_ENTROPY_SOURCE_FAILED;
+}
+
+/*TPM 2.0 Objects flush */
+static TPM_RC flush_tpm2(void)
+{
+    int i;
+
+    for (i = TRANSIENT_FIRST; i < TRANSIENT_LAST; i++)
+         TPM2_FlushContext(i);
+
+    return TPM_SUCCESS;
+}
+
+TPM_RESULT vtpmmgr2_init(int argc, char** argv)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+
+    /* Default commandline options */
+    struct Opts opts = {
+        .tpmdriver = TPMDRV_TPM_TIS,
+        .tpmiomem = TPM_BASEADDR,
+        .tpmirq = 0,
+        .tpmlocality = 0,
+        .gen_owner_auth = 0,
+    };
+
+    if (parse_cmdline_opts(argc, argv, &opts) != 0) {
+        vtpmlogerror(VTPM_LOG_VTPM, "Command line parsing failed! exiting..\n");
+        status = TPM_BAD_PARAMETER;
+        goto abort_egress;
+    }
+
+    /*Setup storage system*/
+    if (vtpm_storage_init() != 0) {
+        vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize storage subsystem!\n");
+        status = TPM_IOERROR;
+        goto abort_egress;
+    }
+
+    /*Setup tpmback device*/
+    init_tpmback(set_opaque, free_opaque);
+
+    /*Setup tpm access*/
+    switch(opts.tpmdriver) {
+        case TPMDRV_TPM_TIS:
+        {
+            struct tpm_chip* tpm;
+            if ((tpm = init_tpm2_tis(opts.tpmiomem, TPM_TIS_LOCL_INT_TO_FLAG(opts.tpmlocality),
+                                     opts.tpmirq)) == NULL) {
+                vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize tpmfront device\n");
+                status = TPM_IOERROR;
+                goto abort_egress;
+            }
+            printk("init_tpm2_tis()       ...ok\n");
+            vtpm_globals.tpm_fd = tpm_tis_open(tpm);
+            tpm_tis_request_locality(tpm, opts.tpmlocality);
+        }
+        break;
+        case TPMDRV_TPMFRONT:
+        {
+            struct tpmfront_dev* tpmfront_dev;
+            if ((tpmfront_dev = init_tpmfront(NULL)) == NULL) {
+                vtpmlogerror(VTPM_LOG_VTPM, "Unable to initialize tpmfront device\n");
+                status = TPM_IOERROR;
+                goto abort_egress;
+            }
+            vtpm_globals.tpm_fd = tpmfront_open(tpmfront_dev);
+        }
+        break;
+    }
+    printk("TPM 2.0 access ...ok\n");
+    /* Blow away all stale handles left in the tpm*/
+    if (flush_tpm2() != TPM_SUCCESS) {
+        vtpmlogerror(VTPM_LOG_VTPM, "VTPM_FlushResources failed, continuing anyway..\n");
+    }
+
+    /* Initialize the rng */
+    entropy_init(&vtpm_globals.entropy);
+    entropy_add_source(&vtpm_globals.entropy, tpm2_entropy_source, NULL, 0);
+    entropy_gather(&vtpm_globals.entropy);
+    ctr_drbg_init(&vtpm_globals.ctr_drbg, entropy_func, &vtpm_globals.entropy, NULL, 0);
+    ctr_drbg_set_prediction_resistance( &vtpm_globals.ctr_drbg, CTR_DRBG_PR_OFF );
+
+    /* Generate Auth for Owner*/
+    if (opts.gen_owner_auth) {
+        vtpmmgr_rand(vtpm_globals.owner_auth, sizeof(TPM_AUTHDATA));
+    }
+
+    /* Load the Manager data, if it fails create a new manager */
+    if (vtpm_load_disk()) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Assuming first time initialization.\n");
+        TPMTRYRETURN(vtpmmgr2_create());
+    }
+
+    goto egress;
+
+abort_egress:
+    vtpmmgr_shutdown();
+egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 9889feb..c479443 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -96,5 +96,6 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 /* TPM 2.0 */
 TPM_RC tpm2_take_ownership(void);
 TPM_RESULT vtpmmgr2_create(void);
+TPM_RESULT vtpmmgr2_init(int argc, char** argv);
 
 #endif
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6Fyx-0001e8-Im; Wed, 31 Dec 2014 09:54:23 +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 1Y6Fyw-0001e3-CS
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:22 +0000
Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id
	E1/3D-19763-DC7C3A45; Wed, 31 Dec 2014 09:54:21 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1420019659!15741069!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4259 invoked from network); 31 Dec 2014 09:54:20 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-9.tower-206.messagelabs.com with SMTP;
	31 Dec 2014 09:54:20 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by orsmga103.jf.intel.com with ESMTP; 31 Dec 2014 01:51:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="435269182"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 31 Dec 2014 01:42:16 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:20 -0500
Message-Id: <1420005020-25475-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
MIME-Version: 1.0
Cc: keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	tim@xen.org, ian.jackson@eu.citrix.com, jbeulich@suse.com,
	Quan Xu <quan.xu@intel.com>, samuel.thibault@ens-lyon.org,
	dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH v3 00/14] Enable vTPM subsystem on TPM 2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

###################
# Happy New Year..#
###################

This series of patch enable the virtual Trusted Platform Module (vTPM)
subsystem for Xen on TPM 2.0.

Noted, functionality for a virtual guest operating system (a DomU) is still
TPM 1.2. The main modifcation is on vtpmmgr-stubdom. The challenge is that
TPM 2.0 is not backward compatible with TPM 1.2.

------------------------------
DESIGN OVERVIEW
------------------------------
The architecture of vTPM subsystem on TPM 2.0 is described below:

+------------------+
|    Linux DomU    | ...
|       |  ^       |
|       v  |       |
|   xen-tpmfront   |
+------------------+
        |  ^
        v  |
+------------------+
| mini-os/tpmback  |
|       |  ^       |
|       v  |       |
|  vtpm-stubdom    | ...
|       |  ^       |
|       v  |       |
| mini-os/tpmfront |
+------------------+
        |  ^
        v  |
+------------------+
| mini-os/tpmback  |
|       |  ^       |
|       v  |       |
| vtpmmgr-stubdom  |
|       |  ^       |
|       v  |       |
| mini-os/tpm2_tis |
+------------------+
        |  ^
        v  |
+------------------+
| Hardware TPM 2.0 |
+------------------+
 * Linux DomU: The Linux based guest that wants to use a vTPM. There many be
               more than one of these.

 * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver
                    provides vTPM access to a para-virtualized Linux based DomU.

 * 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.  This domain regulates
               access to the physical TPM on the system and secures the
               persistent state of each vTPM.

 * mini-os/tpm2_tis: Mini-os TPM version 2.0 TPM Interface Specification (TIS)
                    driver. This driver used by vtpmmgr-stubdom to talk directly
                    to the hardware TPM 2.0. Communication is facilitated by mapping
                    hardware memory pages into vtpmmgr-stubdom.

 * Hardware TPM 2.0: The physical TPM 2.0 that is soldered onto the motherboard.


------------------------------
Key Hierarchy
------------------------------

    +------------------+
    |  vTPM's secrets  | ...
    +------------------+
            |  ^
            |  |(Bind / Unbind)
- - - - -  -v  |- - - - - - - - TPM 2.0
    +------------------+
    |        SK        +
    +------------------+
            |  ^
            v  |
    +------------------+
    |       SRK        |
    +------------------+
            |  ^
            v  |
    +------------------+
    | TPM 2.0 Storage  |
    |   Primary Seed   |
    +------------------+
------------------------------
INSTALLATION
------------------------------

Prerequisites:
--------------
You must have an x86 machine with a TPM on the motherboard.  The only extra
software requirement for compiling vTPM is cmake.  You must use libxl to manage
domains with vTPMs; 'xm' is deprecated and does not support vTPMs.

Compiling the Xen tree:
-----------------------

Compile and install the Xen tree as usual; be sure that the vTPM domains are
enabled when you run configure.

Compiling the LINUX dom0 kernel:
--------------------------------

Because the TPM manager uses direct access to the physical TPM, it may interfere
with access to the TPM by dom0.  The simplest solution for this is to prevent
dom0 from accessing the physical TPM by compiling the kernel without a driver or
blacklisting the module.

Compiling the LINUX domU kernel:
--------------------------------

The domU kernel used by domains with vtpms must include the xen-tpmfront.ko
driver. It can be built directly into the kernel or as a module; however, some
features such as IMA require the TPM to be built in to the kernel.


CONFIG_TCG_TPM=y
CONFIG_TCG_XEN=y

------------------------------
VTPM MANAGER SETUP
------------------------------

Manager disk image setup:
-------------------------

The vTPM Manager requires a disk image to store its encrypted data. The image
does not require a filesystem and can live anywhere on the host disk. The image
is not large; the Xen 4.5 vtpmmgr is limited to using the first 2MB of the image
but can support more than 20,000 vTPMs.

 dd if=/dev/zero of=/home/vtpm2/vmgr bs=16M count=1

Manager config file:
--------------------

The vTPM Manager domain (vtpmmgr-stubdom) must be started like any other Xen
virtual machine and requires a config file.  The manager requires a disk image
for storage and permission to access the hardware memory pages for the TPM. The
disk must be presented as "hda", and the TPM memory pages are passed using the
iomem configuration parameter. The TPM TIS uses 5 pages of IO memory (one per
locality) that start at physical address 0xfed40000. By default, the TPM manager
uses locality 0 (so only the page at 0xfed40 is needed).

Add:
..
     extra="tpm2"
..
extra option to launch vtpmmgr-stubdom domain on TPM 2.0, and ignore it on TPM
1.x. for example:

    kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
    memory=128
    disk=["file:/home/vtpm2/vmgr,hda,w"]
    name="vtpmmgr"
    iomem=["fed40,5"]
    extra="tpm2"

------------------------------
VTPM AND LINUX PVM SETUP
------------------------------
vTPM disk image setup:
----------------------

The vTPM requires a disk image to store its persistent data (RSA keys, NVRAM,
etc). The image does not require a filesystem. The image does not need to be
large; 2 Mb should be sufficient.

    dd if=/dev/zero of=/home/vtpm2/vtpm0 bs=2M count=1

vTPM config file:
-----------------

The vTPM domain requires a configuration file like any other domain. The vTPM
requires a disk image for storage and a TPM frontend driver to communicate with
the manager.  You are required to generate a uuid for this vtpm, which is
specified on the "vtpm=" line that describes its connection to the vTPM Manager.
for example:

    kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
    memory=8
    disk=["file:/home/vtpm2/vtpm0,hda,w"]
    name="vtpm0"
    vtpm=["backend=vtpmmgr,uuid=914fe389-e2c5-44e6-993f-2189637cf1de"]

If you wish to clear the vTPM data you can either recreate the disk image or
change the uuid.

Linux Guest config file:
------------------------
The Linux guest config file needs to be modified to include the Linux tpmfront
driver. Add the following line:

vtpm=["backend=vtpm0"]

Currently only Linux guests are supported (PV or HVM with PV drivers). My series
of patch for HVM virtual mahcine are still being reviewed and modifcated.

Using the vTPM in the guest:
----------------------------

If xen-tpmfront was compiled as a module, it must be loaded it in the guest.

# modprobe xen-tpmfront

After the Linux domain boots and the xen-tpmfront driver is loaded, you should
see the following on the vtpm console:

Info: VTPM attached to Frontend X/Y

You can quickly test the vTPM by using the sysfs interface:
# cat /sys/devices/vtpm-0/pubek
# cat /sys/devices/vtpm-0/pcrs
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

You should also see the command being sent to the vtpm console as well as the
vtpm saving its state. You should see the vtpm key being encrypted and stored on
the vtpmmgr console.

You may wish to write a script to start your vtpm and guest together and to
destroy the vtpm when the guest shuts down.
------------------------------
INTEGRATION WITH PV-GRUB
------------------------------

The vTPM currently starts up with all PCRs set to their default values (all
zeros for the lower 16).  This means that any decisions about the
trustworthiness of the created domain must be made based on the environment that
created the vTPM and the domU; for example, a system that only constructs images
using a trusted configuration and guest kernel be able to provide guarantees
about the guests and any measurements done that kernel (such as the IMA TCB
log).  Guests wishing to use a custom kernel in such a secure environment are
often started using the pv-grub bootloader as the kernel, which then can load
the untrusted kernel without needing to parse an untrusted filesystem and kernel
in dom0.  If the pv-grub stub domain succeeds in connecting to a vTPM, it will
extend the hash of the kernel that it boots into PCR #4, and will extend the
command line and initrd into PCR #5 before booting so that a domU booted in this
way can attest to its early boot state.

------------------------------
REFERENCES
------------------------------

Berlios TPM Emulator:
http://tpm-emulator.berlios.de/
Xen docs/misc/vtpm.txt
Xen docs/misc/vtpm-platforms.txt
Xen docs/misc/vtpmmgr.txt

--Changes in V3:
  1. Add 'olen' parameter in 'stubdom/vtpmmgr/disk_read.c', which is lost in v2.

--Changes in V2:
  1. Record some infomation in docs/misc/vtpmmgr.txt.
  2. Add TPM 2.0 PCRs read.
  3. Bind/Unbind the measurements of the hypervisor and other
     TCB components.
  4. Change extra option from '--tpm2' to 'tpm2'

Quan Xu (14):
  vTPM/TPM2: Add TPM 2.0 data structures and commands definition
  vTPM/TPM2: TPM 2.0 data structures marshal
  vTPM/TPM2: Add global data in vtpm_globals{}
  vTPM/TPM2: Add TPM 2.0 Exposed APIs
  vTPM/TPM2: TPM 2.0 takes ownership and create SRK
  vTPM/TPM2: Create and load SK on TPM 2.0
  vTPM/TPM2: TPM2.0 TIS initialization and self test.
  vTPM/TPM2: Add main entrance vtpmmgr2_init()
  vTPM/TPM2: Support 'tpm2' extra command line.
  vTPM/TPM2: TPM 2.0 PCRs read
  vTPM/TPM2: Support TPM 2.0 bind and unbind data
  vTPM/TPM2: Bind group keys and sectors data on disk
  vTPM/TPM2: Unind group keys and sectors data on disk
  vTPM/TPM2: Record some infomation in docs/misc/vtpmmgr.txt about

 docs/misc/vtpmmgr.txt            | 150 +++++-
 extras/mini-os/include/tpm_tis.h |   1 +
 extras/mini-os/tpm_tis.c         | 156 +++++++
 stubdom/vtpmmgr/Makefile         |   2 +-
 stubdom/vtpmmgr/disk_read.c      |  17 +-
 stubdom/vtpmmgr/disk_tpm.c       |  42 +-
 stubdom/vtpmmgr/disk_tpm.h       |   4 +
 stubdom/vtpmmgr/disk_write.c     |  13 +-
 stubdom/vtpmmgr/init.c           | 315 +++++++++++++
 stubdom/vtpmmgr/tpm2.c           | 455 ++++++++++++++++++
 stubdom/vtpmmgr/tpm2.h           | 104 +++++
 stubdom/vtpmmgr/tpm2_marshal.h   | 673 +++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2_types.h     | 980 +++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.c        |  46 +-
 stubdom/vtpmmgr/vtpmmgr.h        |  29 ++
 15 files changed, 2973 insertions(+), 14 deletions(-)
 create mode 100644 stubdom/vtpmmgr/tpm2.c
 create mode 100644 stubdom/vtpmmgr/tpm2.h
 create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h
 create mode 100644 stubdom/vtpmmgr/tpm2_types.h

-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzG-0001hp-18; Wed, 31 Dec 2014 09:54:42 +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 1Y6FzE-0001go-Bc
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:40 +0000
Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id
	D2/60-09284-FD7C3A45; Wed, 31 Dec 2014 09:54:39 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-12.tower-31.messagelabs.com!1420019675!16493359!2
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 15554 invoked from network); 31 Dec 2014 09:54:39 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-12.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:39 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by fmsmga101.fm.intel.com with ESMTP; 31 Dec 2014 01:54:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="631131292"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 31 Dec 2014 01:54:37 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:48 -0500
Message-Id: <1420005048-25666-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 05/14] vTPM/TPM2: TPM 2.0 takes ownership and
	create SRK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

TPM2_CreatePrimary is used to create a Primary Object under one of
the Primary Seeds or a Temporary Object under TPM_RH_NULL. The command
uses a TPM2B_PUBLIC as a template for the object to be created. The
command will create and load a Primary Object. The sensitive area is
not returned. Any type of object and attributes combination that is
allowed by TPM2_Create() may be created by this command. The constraints
on templates and parameters are the same as TPM2_Create() except that a
Primary Storage Key and a Temporary Storage Key are not constrained to
use the algorithms of their parents.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/init.c    | 71 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/vtpmmgr.h |  3 ++
 2 files changed, 74 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index f3aa02f..c654071 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -51,6 +51,7 @@
 #include "vtpm_disk.h"
 #include "tpm.h"
 #include "marshal.h"
+#include "tpm2.h"
 
 struct Opts {
    enum {
@@ -509,3 +510,73 @@ void vtpmmgr_shutdown(void)
 
    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager stopped.\n");
 }
+
+/* TPM 2.0 */
+
+static void tpm2_AuthArea_ctor(const char *authValue, UINT32 authLen,
+                               TPM_AuthArea *auth)
+{
+    auth->sessionHandle = TPM_RS_PW;
+    auth->nonce.size = 0;
+    auth->sessionAttributes = 1;
+    auth->auth.size = authLen;
+    memcpy(auth->auth.buffer, authValue, authLen);
+    auth->size = 9 + authLen;
+}
+
+TPM_RC tpm2_take_ownership(void)
+{
+    TPM_RC status = TPM_SUCCESS;
+
+    tpm2_AuthArea_ctor(NULL, 0, &vtpm_globals.pw_auth);
+
+    /* create SRK */
+    TPM2_CreatePrimary_Params_in in = {
+        .inSensitive = {
+            .size = 4,
+            .sensitive = {
+                .userAuth.size = 0,
+                .userAuth.buffer = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\
+                                     0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+                .data.size = 0,
+            },
+        },
+        .inPublic = {
+            .size = 60,
+            .publicArea = {
+                .type = TPM2_ALG_RSA,
+                .nameAlg = TPM2_ALG_SHA256,
+#define SRK_OBJ_ATTR (fixedTPM | fixedParent  | userWithAuth | \
+                      sensitiveDataOrigin | restricted | decrypt)
+                .objectAttributes = SRK_OBJ_ATTR,
+                .authPolicy.size = 0,
+                .parameters.rsaDetail = {
+                    .symmetric = {
+                    .algorithm = TPM2_ALG_AES,
+                    .keyBits.aes = AES_KEY_SIZES_BITS,
+                    .mode.aes = TPM2_ALG_CFB,
+                    },
+                .scheme = { TPM2_ALG_NULL },
+                .keyBits = RSA_KEY_SIZES_BITS,
+                .exponent = 0,
+                },
+                .unique.rsa.size = 0,
+            },
+        },
+            .outsideInfo.size = 0,
+            .creationPCR.count = 0,
+    };
+
+    TPMTRYRETURN(TPM2_CreatePrimary(TPM_RH_OWNER,&in,
+                                    &vtpm_globals.srk_handle, NULL));
+    vtpmloginfo(VTPM_LOG_VTPM, "SRK handle: 0x%X\n", vtpm_globals.srk_handle);
+    {
+        const char data[20] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\
+                                0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+        tpm2_AuthArea_ctor(data, 20, &vtpm_globals.srk_auth_area);
+    }
+    /*end create SRK*/
+
+abort_egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 0d0c604..95519ba 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -93,4 +93,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
    return ctr_drbg_random(&vtpm_globals.ctr_drbg, bytes, num_bytes) == 0 ? 0 : TPM_FAIL;
 }
 
+/* TPM 2.0 */
+TPM_RC tpm2_take_ownership(void);
+
 #endif
-- 
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 Dec 31 09:54:56 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzA-0001fY-0s; Wed, 31 Dec 2014 09:54:36 +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 1Y6Fz9-0001fB-89
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:35 +0000
Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id
	3D/05-25547-AD7C3A45; Wed, 31 Dec 2014 09:54:34 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-31.messagelabs.com!1420019672!16589176!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21824 invoked from network); 31 Dec 2014 09:54:32 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-7.tower-31.messagelabs.com with SMTP;
	31 Dec 2014 09:54:32 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by orsmga101.jf.intel.com with ESMTP; 31 Dec 2014 01:54:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="655296142"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 31 Dec 2014 01:54:27 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:50:39 -0500
Message-Id: <1420005039-25553-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 02/14] vTPM/TPM2: TPM 2.0 data structures
	marshal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 TPM 2.0 data structure marshal for packing and unpacking TPM
2.0 data structures.

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/tpm2_marshal.h | 673 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 673 insertions(+)
 create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h

diff --git a/stubdom/vtpmmgr/tpm2_marshal.h b/stubdom/vtpmmgr/tpm2_marshal.h
new file mode 100644
index 0000000..aaa4464
--- /dev/null
+++ b/stubdom/vtpmmgr/tpm2_marshal.h
@@ -0,0 +1,673 @@
+/*
+ * Copyright (c) 2014 Intel Corporation.
+ *
+ * Authors:
+ *   Quan Xu <quan.xu@intel.com>
+ *
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * based off of the original tools/vtpm_manager code base which is:
+ * Copyright (c) 2005, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above
+ *     copyright notice, this list of conditions and the following
+ *     disclaimer in the documentation and/or other materials provided
+ *     with the distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef TPM2_MARSHAL_H
+#define TPM2_MARSHAL_H
+
+#include <stdlib.h>
+#include <mini-os/byteorder.h>
+#include <mini-os/endian.h>
+#include "tcg.h"
+#include "tpm2_types.h"
+#include <assert.h>
+
+#define pack_TPM_BUFFER(ptr, buf, size) pack_BUFFER(ptr, buf, size)
+#define unpack_TPM_BUFFER(ptr, buf, size) unpack_BUFFER(ptr, buf, size)
+
+inline BYTE* pack_BYTE_ARRAY(BYTE* ptr, const BYTE* array, UINT32 size)
+{
+    int i;
+    for (i = 0; i < size; i++)
+         ptr = pack_BYTE(ptr, array[i]);
+    return ptr;
+}
+
+inline BYTE* pack_TPMA_SESSION(BYTE* ptr, const TPMA_SESSION *attr)
+{
+    return pack_BYTE(ptr, (BYTE)(*attr));
+}
+
+inline BYTE* unpack_TPMA_SESSION(BYTE* ptr, TPMA_SESSION *attr)
+{
+    return unpack_BYTE(ptr, (BYTE *)attr);
+}
+
+inline BYTE* pack_TPMI_ALG_HASH(BYTE* ptr, const TPMI_ALG_HASH *hash)
+{
+    return pack_UINT16(ptr, *hash);
+}
+
+inline BYTE* unpack_TPMI_ALG_HASH(BYTE *ptr, TPMI_ALG_HASH *hash)
+{
+    return unpack_UINT16(ptr, hash);
+}
+
+#define pack_TPMA_OBJECT(ptr, t)                pack_UINT32(ptr, (UINT32)(*t))
+#define unpack_TPMA_OBJECT(ptr, t)              unpack_UINT32(ptr, (UINT32 *)(t))
+#define pack_TPM_RH(ptr, t)                     pack_UINT32(ptr, (UINT32)(*t))
+#define unpack_TPM_RH(ptr, t)                   unpack_UINT32(ptr, (UINT32 *)(t))
+#define pack_TPMA_LOCALITY(ptr, locality)       pack_BYTE(ptr, (BYTE)*locality)
+#define unpack_TPMA_LOCALITY(ptr, locality)     unpack_BYTE(ptr, (BYTE *)locality)
+#define pack_TPM_ST(ptr, tag)                   pack_UINT16(ptr, *tag)
+#define unpack_TPM_ST(ptr, tag)                 unpack_UINT16(ptr, tag)
+#define pack_TPM_KEY_BITS(ptr, t)               pack_UINT16(ptr, *t)
+#define unpack_TPM_KEY_BITS(ptr, t)             unpack_UINT16(ptr, t)
+#define pack_TPMI_AES_KEY_BITS(ptr, t)          pack_TPM_KEY_BITS(ptr, t)
+#define unpack_TPMI_AES_KEY_BITS(ptr, t)        unpack_TPM_KEY_BITS(ptr, t)
+#define pack_TPMI_RSA_KEY_BITS(ptr, t)          pack_TPM_KEY_BITS(ptr, t)
+#define unpack_TPMI_RSA_KEY_BITS(ptr, t)        unpack_TPM_KEY_BITS(ptr, t)
+#define pack_TPM_ALG_ID(ptr, id)                pack_UINT16(ptr, *id)
+#define unpack_TPM_ALG_ID(ptr, id)              unpack_UINT16(ptr, id)
+#define pack_TPM_ALG_SYM(ptr, t)                pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPM_ALG_SYM(ptr, t)              unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_ASYM(ptr, asym)           pack_TPM_ALG_ID(ptr, asym)
+#define unpack_TPMI_ALG_ASYM(ptr, asym)         unpack_TPM_ALG_ID(ptr, asym)
+#define pack_TPMI_ALG_SYM_OBJECT(ptr, t)        pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_SYM_OBJECT(ptr, t)      unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_SYM_MODE(ptr, t)          pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_SYM_MODE(ptr, t)        unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_KDF(ptr, t)               pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_KDF(ptr, t)             unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_ALG_PUBLIC(ptr, t)            pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_PUBLIC(ptr, t)          unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPM2_HANDLE(ptr, h)                pack_UINT32(ptr, *h)
+#define unpack_TPM2_HANDLE(ptr, h)              unpack_UINT32(ptr, h)
+#define pack_TPMI_ALG_RSA_SCHEME(ptr, t)        pack_TPM_ALG_ID(ptr, t)
+#define unpack_TPMI_ALG_RSA_SCHEME(ptr, t)      unpack_TPM_ALG_ID(ptr, t)
+#define pack_TPMI_DH_OBJECT(ptr, o)             pack_TPM2_HANDLE(ptr, o)
+#define unpack_TPMI_DH_OBJECT(PTR, O)           unpack_TPM2_HANDLE(ptr, o)
+#define pack_TPMI_RH_HIERACHY(ptr, h)           pack_TPM2_HANDLE(ptr, h)
+#define unpack_TPMI_RH_HIERACHY(ptr, h)         unpack_TPM2_HANDLE(ptr, h)
+#define pack_TPMI_RH_PLATFORM(ptr, p)           pack_TPM2_HANDLE(ptr, p)
+#define unpack_TPMI_RH_PLATFORM(ptr, p)         unpack_TPM2_HANDLE(ptr, p)
+#define pack_TPMI_RH_OWNER(ptr, o)              pack_TPM2_HANDLE(ptr, o)
+#define unpack_TPMI_RH_OWNER(ptr, o)            unpack_TPM2_HANDLE(ptr, o)
+#define pack_TPMI_RH_ENDORSEMENT(ptr, e)        pack_TPM2_HANDLE(ptr, e)
+#define unpack_TPMI_RH_ENDORSEMENT(ptr, e)      unpack_TPM2_HANDLE(ptr, e)
+#define pack_TPMI_RH_LOCKOUT(ptr, l)            pack_TPM2_HANDLE(ptr, l)
+#define unpack_TPMI_RH_LOCKOUT(ptr, l)          unpack_TPM2_HANDLE(ptr, l)
+
+inline BYTE* pack_TPM2B_DIGEST(BYTE* ptr, const TPM2B_DIGEST *digest)
+{
+    ptr = pack_UINT16(ptr, digest->size);
+    ptr = pack_BUFFER(ptr, digest->buffer, digest->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_DIGEST(BYTE* ptr, TPM2B_DIGEST *digest)
+{
+    ptr = unpack_UINT16(ptr, &digest->size);
+    ptr = unpack_BUFFER(ptr, digest->buffer, digest->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_TK_CREATION(BYTE* ptr,const TPMT_TK_CREATION *ticket )
+{
+    ptr = pack_TPM_ST(ptr , &ticket->tag);
+    ptr = pack_TPMI_RH_HIERACHY(ptr , &ticket->hierarchy);
+    ptr = pack_TPM2B_DIGEST(ptr, &ticket->digest);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_TK_CREATION(BYTE* ptr, TPMT_TK_CREATION *ticket )
+{
+    ptr = unpack_TPM_ST(ptr, &ticket->tag);
+    ptr = unpack_TPMI_RH_HIERACHY(ptr, &ticket->hierarchy);
+    ptr = unpack_TPM2B_DIGEST(ptr, &ticket->digest);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_NAME(BYTE* ptr,const TPM2B_NAME *name )
+{
+    ptr = pack_UINT16(ptr, name->size);
+    ptr = pack_TPM_BUFFER(ptr, name->name, name->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_NAME(BYTE* ptr, TPM2B_NAME *name)
+{
+    ptr = unpack_UINT16(ptr, &name->size);
+    ptr = unpack_TPM_BUFFER(ptr, name->name, name->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_NONCE(BYTE* ptr, const TPM2B_NONCE *nonce)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)nonce);
+}
+
+#define unpack_TPM2B_NONCE(ptr, nonce)  unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)nonce)
+
+inline BYTE* pack_TPM2B_AUTH(BYTE* ptr, const TPM2B_AUTH *auth)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)auth);
+}
+
+#define unpack_TPM2B_AUTH(ptr, auth)    unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)auth)
+
+inline BYTE* pack_TPM2B_DATA(BYTE* ptr, const TPM2B_DATA *data)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)data);
+}
+
+#define unpack_TPM2B_DATA(ptr, data)    unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)data)
+
+inline BYTE* pack_TPM2B_SENSITIVE_DATA(BYTE* ptr, const TPM2B_SENSITIVE_DATA *data)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)data);
+}
+
+#define unpack_TPM2B_SENSITIVE_DATA(ptr, data)  unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)data)
+
+inline BYTE* pack_TPM2B_PUBLIC_KEY_RSA(BYTE* ptr, const TPM2B_PUBLIC_KEY_RSA *rsa)
+{
+    return pack_TPM2B_DIGEST(ptr, (const TPM2B_DIGEST*)rsa);
+}
+
+#define unpack_TPM2B_PUBLIC_KEY_RSA(ptr, rsa)   unpack_TPM2B_DIGEST(ptr, (TPM2B_DIGEST*)rsa)
+
+inline BYTE* pack_TPM2B_PRIVATE(BYTE* ptr, const TPM2B_PRIVATE *Private)
+{
+    ptr = pack_UINT16(ptr, Private->size);
+    ptr = pack_TPM_BUFFER(ptr, Private->buffer, Private->size);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_PRIVATE(BYTE* ptr, TPM2B_PRIVATE *Private)
+{
+    ptr = unpack_UINT16(ptr, &Private->size);
+    ptr = unpack_BUFFER(ptr, Private->buffer, Private->size);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION_ARRAY(BYTE* ptr, const TPMS_PCR_SELECTION *sel, UINT32 count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+        ptr = pack_TPMI_ALG_HASH(ptr, &sel[i].hash);
+        ptr = pack_BYTE(ptr, sel[i].sizeofSelect);
+        ptr = pack_BUFFER(ptr, sel[i].pcrSelect, sel[i].sizeofSelect);
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_PCR_SELECTION_ARRAY(BYTE* ptr, TPMS_PCR_SELECTION *sel, UINT32 count)
+{
+    int i;
+    for (i = 0; i < count; i++) {
+        ptr = unpack_TPMI_ALG_HASH(ptr, &sel[i].hash);
+        ptr = unpack_BYTE(ptr, &sel[i].sizeofSelect);
+        ptr = unpack_BUFFER(ptr, sel[i].pcrSelect, sel[i].sizeofSelect);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPML_PCR_SELECTION(BYTE* ptr, const TPML_PCR_SELECTION *sel)
+{
+    ptr = pack_UINT32(ptr, sel->count);
+    ptr = pack_TPMS_PCR_SELECTION_ARRAY(ptr, sel->pcrSelections, sel->count);
+    return ptr;
+}
+
+inline BYTE* unpack_TPML_PCR_SELECTION(BYTE* ptr, TPML_PCR_SELECTION *sel)
+{
+    ptr = unpack_UINT32(ptr, &sel->count);
+    ptr = unpack_TPMS_PCR_SELECTION_ARRAY(ptr, sel->pcrSelections, sel->count);
+    return ptr;
+}
+
+inline BYTE* unpack_TPML_DIGEST(BYTE* ptr,TPML_DIGEST *digest)
+{
+    int i;
+    ptr = unpack_UINT32(ptr, &digest->count);
+    for (i=0;i<digest->count;i++)
+    {
+        ptr = unpack_TPM2B_DIGEST(ptr, &digest->digests[i]);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_CREATION_DATA(BYTE* ptr,const TPMS_CREATION_DATA *data)
+{
+    ptr = pack_TPML_PCR_SELECTION(ptr, &data->pcrSelect);
+    ptr = pack_TPM2B_DIGEST(ptr, &data->pcrDigest);
+    ptr = pack_TPMA_LOCALITY(ptr, &data->locality);
+    ptr = pack_TPM_ALG_ID(ptr, &data->parentNameAlg);
+    ptr = pack_TPM2B_NAME(ptr, &data->parentQualifiedName);
+    ptr = pack_TPM2B_DATA(ptr, &data->outsideInfo);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_CREATION_DATA(BYTE* ptr, TPMS_CREATION_DATA *data)
+{
+    ptr = unpack_TPML_PCR_SELECTION(ptr, &data->pcrSelect);
+    ptr = unpack_TPM2B_DIGEST(ptr, &data->pcrDigest);
+    ptr = unpack_TPMA_LOCALITY(ptr, &data->locality);
+    ptr = unpack_TPM_ALG_ID(ptr, &data->parentNameAlg);
+    ptr = unpack_TPM2B_NAME(ptr, &data->parentName);
+    ptr = unpack_TPM2B_NAME(ptr, &data->parentQualifiedName);
+    ptr = unpack_TPM2B_DATA(ptr, &data->outsideInfo);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_CREATION_DATA(BYTE* ptr, const TPM2B_CREATION_DATA *data )
+{
+    ptr = pack_UINT16(ptr, data->size);
+    ptr = pack_TPMS_CREATION_DATA(ptr, &data->creationData);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_CREATION_DATA(BYTE* ptr, TPM2B_CREATION_DATA * data)
+{
+    ptr = unpack_UINT16(ptr, &data->size);
+    ptr = unpack_TPMS_CREATION_DATA(ptr, &data->creationData);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_SENSITIVE_CREATE(BYTE* ptr, const TPMS_SENSITIVE_CREATE *create)
+{
+    ptr = pack_TPM2B_AUTH(ptr, &create->userAuth);
+    ptr = pack_TPM2B_SENSITIVE_DATA(ptr, &create->data);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_SENSITIVE_CREATE(BYTE* ptr, const TPM2B_SENSITIVE_CREATE *create)
+{
+    BYTE* sizePtr = ptr;
+    ptr += 2;
+    ptr = pack_TPMS_SENSITIVE_CREATE(ptr, &create->sensitive);
+    pack_UINT16(sizePtr, (UINT16)(ptr - sizePtr - 2));
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_SYM_MODE(BYTE* ptr, const TPMU_SYM_MODE *p,
+                                const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = pack_TPMI_ALG_SYM_MODE(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        case TPM2_ALG_XOR:
+        break;
+    default:
+        ptr = pack_TPMI_ALG_SYM_MODE(ptr, &p->sym);
+    }
+    return ptr;
+}
+inline BYTE* unpack_TPMU_SYM_MODE(BYTE* ptr, TPMU_SYM_MODE *p,
+                                  const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = unpack_TPMI_ALG_SYM_MODE(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+    case TPM2_ALG_XOR:
+        break;
+    default:
+        ptr = unpack_TPMI_ALG_SYM_MODE(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_SYM_KEY_BITS(BYTE* ptr, const TPMU_SYM_KEY_BITS *p,
+                                    const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = pack_TPMI_AES_KEY_BITS(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_XOR:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        ptr = pack_TPM_KEY_BITS(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMU_SYM_KEY_BITS(BYTE* ptr, TPMU_SYM_KEY_BITS *p,
+                                      const TPMI_ALG_SYM_OBJECT *sel)
+{
+    switch(*sel) {
+    case TPM2_ALG_AES:
+        ptr = unpack_TPMI_AES_KEY_BITS(ptr, &p->aes);
+        break;
+    case TPM2_ALG_SM4:
+        assert(false);
+        break;
+    case TPM2_ALG_XOR:
+        assert(false);
+        break;
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        ptr = unpack_TPM_KEY_BITS(ptr, &p->sym);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_SYM_DEF_OBJECT(BYTE* ptr, const TPMT_SYM_DEF_OBJECT *p)
+{
+    ptr = pack_TPMI_ALG_SYM_OBJECT(ptr, &p->algorithm);
+    ptr = pack_TPMU_SYM_KEY_BITS(ptr, &p->keyBits, &p->algorithm);
+    ptr = pack_TPMU_SYM_MODE(ptr, &p->mode, &p->algorithm);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_SYM_DEF_OBJECT(BYTE *ptr, TPMT_SYM_DEF_OBJECT *p)
+{
+    ptr = unpack_TPMI_ALG_SYM_OBJECT(ptr, &p->algorithm);
+    ptr = unpack_TPMU_SYM_KEY_BITS(ptr, &p->keyBits, &p->algorithm);
+    ptr = unpack_TPMU_SYM_MODE(ptr, &p->mode, &p->algorithm);
+    return ptr;
+}
+
+#define pack_TPMS_SCHEME_OAEP(p, t)     pack_TPMI_ALG_HASH(p, &((t)->hashAlg))
+#define unpack_TPMS_SCHEME_OAEP(p, t)   unpack_TPMI_ALG_HASH(p, &((t)->hashAlg))
+
+inline BYTE* pack_TPMU_ASYM_SCHEME(BYTE *ptr, const TPMU_ASYM_SCHEME *p,
+                                   const TPMI_ALG_RSA_SCHEME *s)
+{
+    switch(*s) {
+#ifdef TPM2_ALG_RSASSA
+    case TPM2_ALG_RSASSA:
+        assert(false || "TPM2_ALG_RSASSA");
+        break;
+#endif
+#ifdef TPM2_ALG_OAEP
+    case TPM2_ALG_OAEP:
+        ptr = pack_TPMS_SCHEME_OAEP(ptr, &p->oaep);
+        break;
+#endif
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        assert(false || "DEFAULT");
+    }
+    return ptr;
+}
+
+inline BYTE* unpack_TPMU_ASYM_SCHEME(BYTE *ptr, TPMU_ASYM_SCHEME *p,
+                                     const TPMI_ALG_RSA_SCHEME *s)
+{
+    switch(*s) {
+    #ifdef TPM2_ALG_RSASSA
+    case TPM2_ALG_RSASSA:
+        printf("not support TPM_ALG_RSASSA\n");
+        assert(false);
+        break;
+    #endif
+    #ifdef TPM2_ALG_OAEP
+    case TPM2_ALG_OAEP:
+        ptr = unpack_TPMS_SCHEME_OAEP(ptr, &p->oaep);
+        break;
+    #endif
+    case TPM2_ALG_NULL:
+        break;
+    default:
+        printf("default TPMI_ALG_RSA_SCHEME 0x%X\n", (UINT32)*s);
+        ptr = unpack_TPMI_ALG_HASH(ptr, &p->anySig.hashAlg);
+    }
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_RSA_SCHEME(BYTE* ptr, const TPMT_RSA_SCHEME *p)
+{
+    ptr = pack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_RSA_SCHEME(BYTE* ptr, TPMT_RSA_SCHEME *p)
+{
+    ptr = unpack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = unpack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* pack_TPMT_RSA_DECRYPT(BYTE* ptr, const TPMT_RSA_DECRYPT *p)
+{
+    ptr = pack_TPMI_ALG_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMU_ASYM_SCHEME(ptr, &p->details, &p->scheme);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_RSA_PARMS(BYTE* ptr, const TPMS_RSA_PARMS *p)
+{
+    ptr = pack_TPMT_SYM_DEF_OBJECT(ptr, &p->symmetric);
+    ptr = pack_TPMT_RSA_SCHEME(ptr, &p->scheme);
+    ptr = pack_TPMI_RSA_KEY_BITS(ptr, &p->keyBits);
+    ptr = pack_UINT32(ptr, p->exponent);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_RSA_PARMS(BYTE *ptr, TPMS_RSA_PARMS *p)
+{
+    ptr = unpack_TPMT_SYM_DEF_OBJECT(ptr, &p->symmetric);
+    ptr = unpack_TPMT_RSA_SCHEME(ptr, &p->scheme);
+    ptr = unpack_TPMI_RSA_KEY_BITS(ptr, &p->keyBits);
+    ptr = unpack_UINT32(ptr, &p->exponent);
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_PUBLIC_PARMS(BYTE* ptr, const TPMU_PUBLIC_PARMS *param,
+                                    const TPMI_ALG_PUBLIC *selector)
+{
+    switch(*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        assert(false);
+    case TPM2_ALG_SYMCIPHER:
+        assert(false);
+    case TPM2_ALG_RSA:
+        return pack_TPMS_RSA_PARMS(ptr, &param->rsaDetail);
+    case TPM2_ALG_ECC:
+        assert(false);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* unpack_TPMU_PUBLIC_PARMS(BYTE* ptr, TPMU_PUBLIC_PARMS *param,
+                                      const TPMI_ALG_PUBLIC *selector)
+{
+    switch(*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        assert(false);
+    case TPM2_ALG_SYMCIPHER:
+        assert(false);
+    case TPM2_ALG_RSA:
+        return unpack_TPMS_RSA_PARMS(ptr, &param->rsaDetail);
+    case TPM2_ALG_ECC:
+        assert(false);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* pack_TPMS_ECC_POINT(BYTE* ptr, const TPMS_ECC_POINT *point)
+{
+    assert(false);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMS_ECC_POINT(BYTE* ptr, TPMS_ECC_POINT *point)
+{
+    assert(false);
+    return ptr;
+}
+
+inline BYTE* pack_TPMU_PUBLIC_ID(BYTE* ptr, const TPMU_PUBLIC_ID *id,
+                                 const TPMI_ALG_PUBLIC *selector)
+{
+    switch (*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        return pack_TPM2B_DIGEST(ptr, &id->keyedHash);
+    case TPM2_ALG_SYMCIPHER:
+        return pack_TPM2B_DIGEST(ptr, &id->sym);
+    case TPM2_ALG_RSA:
+        return pack_TPM2B_PUBLIC_KEY_RSA(ptr, &id->rsa);
+    case TPM2_ALG_ECC:
+        return pack_TPMS_ECC_POINT(ptr, &id->ecc);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* unpack_TPMU_PUBLIC_ID(BYTE* ptr, TPMU_PUBLIC_ID *id, TPMI_ALG_PUBLIC *selector)
+{
+    switch (*selector) {
+    case TPM2_ALG_KEYEDHASH:
+        return unpack_TPM2B_DIGEST(ptr, &id->keyedHash);
+    case TPM2_ALG_SYMCIPHER:
+        return unpack_TPM2B_DIGEST(ptr, &id->sym);
+    case TPM2_ALG_RSA:
+        return unpack_TPM2B_PUBLIC_KEY_RSA(ptr, &id->rsa);
+    case TPM2_ALG_ECC:
+        return unpack_TPMS_ECC_POINT(ptr, &id->ecc);
+    }
+    assert(false);
+    return NULL;
+}
+
+inline BYTE* pack_TPMT_PUBLIC(BYTE* ptr, const TPMT_PUBLIC *public)
+{
+    ptr = pack_TPMI_ALG_PUBLIC(ptr, &public->type);
+    ptr = pack_TPMI_ALG_HASH(ptr, &public->nameAlg);
+    ptr = pack_TPMA_OBJECT(ptr, &public->objectAttributes);
+    ptr = pack_TPM2B_DIGEST(ptr, &public->authPolicy);
+    ptr = pack_TPMU_PUBLIC_PARMS(ptr, &public->parameters, &public->type);
+    ptr = pack_TPMU_PUBLIC_ID(ptr, &public->unique, &public->type);
+    return ptr;
+}
+
+inline BYTE* unpack_TPMT_PUBLIC(BYTE* ptr, TPMT_PUBLIC *public)
+{
+    ptr = unpack_TPMI_ALG_PUBLIC(ptr, &public->type);
+    ptr = unpack_TPMI_ALG_HASH(ptr, &public->nameAlg);
+    ptr = unpack_TPMA_OBJECT(ptr, &public->objectAttributes);
+    ptr = unpack_TPM2B_DIGEST(ptr, &public->authPolicy);
+    ptr = unpack_TPMU_PUBLIC_PARMS(ptr, &public->parameters, &public->type);
+    ptr = unpack_TPMU_PUBLIC_ID(ptr, &public->unique, &public->type);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2B_PUBLIC(BYTE* ptr, const TPM2B_PUBLIC *public)
+{
+    BYTE *sizePtr = ptr;
+    ptr += 2;
+    ptr = pack_TPMT_PUBLIC(ptr, &public->publicArea);
+    pack_UINT16(sizePtr, (UINT16)(ptr - sizePtr - 2));
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2B_PUBLIC(BYTE* ptr, TPM2B_PUBLIC *public)
+{
+    ptr = unpack_UINT16(ptr, &public->size);
+    ptr = unpack_TPMT_PUBLIC(ptr, &public->publicArea);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION(BYTE* ptr, const TPMS_PCR_SELECTION *selection)
+{
+    ptr = pack_TPMI_ALG_HASH(ptr, &selection->hash);
+    ptr = pack_BYTE(ptr, selection->sizeofSelect);
+    ptr = pack_BYTE_ARRAY(ptr, selection->pcrSelect, selection->sizeofSelect);
+    return ptr;
+}
+
+inline BYTE* pack_TPMS_PCR_SELECTION_Array(BYTE* ptr, const TPMS_PCR_SELECTION *selections,
+                                           const UINT32 cnt)
+{
+    int i;
+    for (i = 0; i < cnt; i++)
+        ptr = pack_TPMS_PCR_SELECTION(ptr, selections + i);
+    return ptr;
+}
+
+inline BYTE* pack_TPM_AuthArea(BYTE* ptr, const TPM_AuthArea *auth)
+{
+    BYTE* sizePtr = ptr;
+    ptr += sizeof(UINT32);
+    ptr = pack_TPM_RH(ptr, &auth->sessionHandle);
+    ptr = pack_TPM2B_NONCE(ptr, &auth->nonce);
+    ptr = pack_TPMA_SESSION(ptr, &auth->sessionAttributes);
+    ptr = pack_TPM2B_AUTH(ptr, &auth->auth);
+    pack_UINT32(sizePtr, ptr - sizePtr - sizeof(UINT32));
+    return ptr;
+}
+
+inline BYTE* unpack_TPM_AuthArea(BYTE* ptr, TPM_AuthArea *auth)
+{
+    ptr = unpack_UINT32(ptr, &auth->size);
+    ptr = unpack_TPM_RH(ptr, &auth->sessionHandle);
+    ptr = unpack_TPM2B_NONCE(ptr, &auth->nonce);
+    ptr = unpack_TPMA_SESSION(ptr, &auth->sessionAttributes);
+    ptr = unpack_TPM2B_AUTH(ptr, &auth->auth);
+    return ptr;
+}
+
+inline BYTE* pack_TPM2_RSA_KEY(BYTE* ptr, const TPM2_RSA_KEY *key)
+{
+    ptr = pack_TPM2B_PRIVATE(ptr, &key->Private);
+    ptr = pack_TPM2B_PUBLIC(ptr, &key->Public);
+    return ptr;
+}
+
+inline BYTE* unpack_TPM2_RSA_KEY(BYTE* ptr, TPM2_RSA_KEY *key)
+{
+    ptr = unpack_TPM2B_PRIVATE(ptr, &key->Private);
+    ptr = unpack_TPM2B_PUBLIC(ptr, &key->Public);
+    return ptr;
+}
+#endif
-- 
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 Dec 31 09:54:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzV-0001rS-NA; Wed, 31 Dec 2014 09:54:57 +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 1Y6FzU-0001oU-Jn
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:56 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4C/FA-09842-0F7C3A45; Wed, 31 Dec 2014 09:54:56 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1420019694!18632813!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 2856 invoked from network); 31 Dec 2014 09:54:55 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-21.messagelabs.com with SMTP;
	31 Dec 2014 09:54:55 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by fmsmga101.fm.intel.com with ESMTP; 31 Dec 2014 01:54:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="662824690"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 31 Dec 2014 01:54:52 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:51:04 -0500
Message-Id: <1420005064-25853-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 10/14] vTPM/TPM2: TPM 2.0 PCRs 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/init.c       | 34 ++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2_types.h |  2 ++
 stubdom/vtpmmgr/vtpmmgr.h    |  1 +
 3 files changed, 37 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 7e115a5..8bab764 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -51,6 +51,7 @@
 #include "vtpm_disk.h"
 #include "tpm.h"
 #include "marshal.h"
+#include "tpm2_marshal.h"
 #include "tpm2.h"
 
 struct Opts {
@@ -790,3 +791,36 @@ abort_egress:
 egress:
     return status;
 }
+
+TPM_RC tpm2_pcr_read(int index, uint8_t *buf)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+    TPML_PCR_SELECTION pcrSelectionIn = {
+        .count = 1,};
+
+    TPMS_PCR_SELECTION tpms_pcr_selection = {
+        .hash = TPM2_ALG_SHA1,
+        .sizeofSelect = PCR_SELECT_MAX,};
+
+    UINT32 pcrUpdateCounter;
+    TPML_PCR_SELECTION pcrSelectionOut;
+    TPML_DIGEST pcrValues;
+    TPM2B_DIGEST tpm2b_digest;
+
+    tpms_pcr_selection.pcrSelect[PCR_SELECT_NUM(index)] = PCR_SELECT_VALUE(index);
+    memcpy(&pcrSelectionIn.pcrSelections[0], &tpms_pcr_selection,
+           sizeof(TPMS_PCR_SELECTION));
+
+    TPMTRYRETURN(TPM2_PCR_Read(pcrSelectionIn, &pcrUpdateCounter,
+                               &pcrSelectionOut, &pcrValues));
+
+    if (pcrValues.count < 1)
+        goto egress;
+
+    unpack_TPM2B_DIGEST((uint8_t *) &pcrValues, &tpm2b_digest);
+    memcpy(buf, tpm2b_digest.buffer, SHA1_DIGEST_SIZE);
+
+abort_egress:
+egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/tpm2_types.h b/stubdom/vtpmmgr/tpm2_types.h
index 214335c..ac2830d 100644
--- a/stubdom/vtpmmgr/tpm2_types.h
+++ b/stubdom/vtpmmgr/tpm2_types.h
@@ -432,6 +432,8 @@ typedef struct {
 #define    IMPLEMENTATION_PCR   24
 #define    PLATFORM_PCR         24
 #define    PCR_SELECT_MAX       ((IMPLEMENTATION_PCR+7)/8)
+#define    PCR_SELECT_NUM(x)    (uint8_t)(x/8)
+#define    PCR_SELECT_VALUE(x)  (uint8_t)(0x1)<<(x%8)
 
 //Table 79 -- TPMS_PCR_SELECT Structure <I/O>
 typedef struct {
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 6a76af4..12ca71d 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -107,6 +107,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 
 /* TPM 2.0 */
 TPM_RC tpm2_take_ownership(void);
+TPM_RC tpm2_pcr_read(int index, uint8_t *buf);
 TPM_RESULT vtpmmgr2_create(void);
 TPM_RESULT vtpmmgr2_init(int argc, char** argv);
 int parse_cmdline_hw(int argc, char** argv);
-- 
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 Dec 31 09:54:57 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:54:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6FzV-0001rS-NA; Wed, 31 Dec 2014 09:54:57 +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 1Y6FzU-0001oU-Jn
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:54:56 +0000
Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id
	4C/FA-09842-0F7C3A45; Wed, 31 Dec 2014 09:54:56 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1420019694!18632813!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 2856 invoked from network); 31 Dec 2014 09:54:55 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-21.messagelabs.com with SMTP;
	31 Dec 2014 09:54:55 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by fmsmga101.fm.intel.com with ESMTP; 31 Dec 2014 01:54:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="662824690"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga002.jf.intel.com with ESMTP; 31 Dec 2014 01:54:52 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:51:04 -0500
Message-Id: <1420005064-25853-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 10/14] vTPM/TPM2: TPM 2.0 PCRs 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/init.c       | 34 ++++++++++++++++++++++++++++++++++
 stubdom/vtpmmgr/tpm2_types.h |  2 ++
 stubdom/vtpmmgr/vtpmmgr.h    |  1 +
 3 files changed, 37 insertions(+)

diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 7e115a5..8bab764 100644
--- a/stubdom/vtpmmgr/init.c
+++ b/stubdom/vtpmmgr/init.c
@@ -51,6 +51,7 @@
 #include "vtpm_disk.h"
 #include "tpm.h"
 #include "marshal.h"
+#include "tpm2_marshal.h"
 #include "tpm2.h"
 
 struct Opts {
@@ -790,3 +791,36 @@ abort_egress:
 egress:
     return status;
 }
+
+TPM_RC tpm2_pcr_read(int index, uint8_t *buf)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+    TPML_PCR_SELECTION pcrSelectionIn = {
+        .count = 1,};
+
+    TPMS_PCR_SELECTION tpms_pcr_selection = {
+        .hash = TPM2_ALG_SHA1,
+        .sizeofSelect = PCR_SELECT_MAX,};
+
+    UINT32 pcrUpdateCounter;
+    TPML_PCR_SELECTION pcrSelectionOut;
+    TPML_DIGEST pcrValues;
+    TPM2B_DIGEST tpm2b_digest;
+
+    tpms_pcr_selection.pcrSelect[PCR_SELECT_NUM(index)] = PCR_SELECT_VALUE(index);
+    memcpy(&pcrSelectionIn.pcrSelections[0], &tpms_pcr_selection,
+           sizeof(TPMS_PCR_SELECTION));
+
+    TPMTRYRETURN(TPM2_PCR_Read(pcrSelectionIn, &pcrUpdateCounter,
+                               &pcrSelectionOut, &pcrValues));
+
+    if (pcrValues.count < 1)
+        goto egress;
+
+    unpack_TPM2B_DIGEST((uint8_t *) &pcrValues, &tpm2b_digest);
+    memcpy(buf, tpm2b_digest.buffer, SHA1_DIGEST_SIZE);
+
+abort_egress:
+egress:
+    return status;
+}
diff --git a/stubdom/vtpmmgr/tpm2_types.h b/stubdom/vtpmmgr/tpm2_types.h
index 214335c..ac2830d 100644
--- a/stubdom/vtpmmgr/tpm2_types.h
+++ b/stubdom/vtpmmgr/tpm2_types.h
@@ -432,6 +432,8 @@ typedef struct {
 #define    IMPLEMENTATION_PCR   24
 #define    PLATFORM_PCR         24
 #define    PCR_SELECT_MAX       ((IMPLEMENTATION_PCR+7)/8)
+#define    PCR_SELECT_NUM(x)    (uint8_t)(x/8)
+#define    PCR_SELECT_VALUE(x)  (uint8_t)(0x1)<<(x%8)
 
 //Table 79 -- TPMS_PCR_SELECT Structure <I/O>
 typedef struct {
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 6a76af4..12ca71d 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/stubdom/vtpmmgr/vtpmmgr.h
@@ -107,6 +107,7 @@ inline TPM_RESULT vtpmmgr_rand(unsigned char* bytes, size_t num_bytes) {
 
 /* TPM 2.0 */
 TPM_RC tpm2_take_ownership(void);
+TPM_RC tpm2_pcr_read(int index, uint8_t *buf);
 TPM_RESULT vtpmmgr2_create(void);
 TPM_RESULT vtpmmgr2_init(int argc, char** argv);
 int parse_cmdline_hw(int argc, char** argv);
-- 
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 Dec 31 09:55:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:55:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6Fzj-00022n-LL; Wed, 31 Dec 2014 09:55:11 +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 1Y6Fzh-00020p-2F
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:55:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BC/8E-25276-CF7C3A45; Wed, 31 Dec 2014 09:55:08 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1420019706!18263199!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18288 invoked from network); 31 Dec 2014 09:55:07 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-3.tower-21.messagelabs.com with SMTP;
	31 Dec 2014 09:55:07 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 31 Dec 2014 01:52:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="631131374"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 31 Dec 2014 01:55:04 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:51:16 -0500
Message-Id: <1420005076-26003-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, jbeulich@suse.com, Quan Xu <quan.xu@intel.com>
Subject: [Xen-devel] [PATCH v3 14/14] vTPM/TPM2: Record some infomation in
	docs/misc/vtpmmgr.txt about
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

'vtpmmgr on TPM 2.0'

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 docs/misc/vtpmmgr.txt | 150 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 149 insertions(+), 1 deletion(-)

diff --git a/docs/misc/vtpmmgr.txt b/docs/misc/vtpmmgr.txt
index 026c52b..1f1af4d 100644
--- a/docs/misc/vtpmmgr.txt
+++ b/docs/misc/vtpmmgr.txt
@@ -1,4 +1,8 @@
-Author: Daniel De Graaf <dgdegra@tycho.nsa.gov>
+================================================================================
+Authors:
+    Daniel De Graaf <dgdegra@tycho.nsa.gov>
+    Quan Xu <quan.xu@intel.com>
+================================================================================
 
 This document describes the operation and command line interface of
 vtpmmgr-stubdom. See docs/misc/vtpm.txt for details on the vTPM subsystem as a
@@ -163,3 +167,147 @@ would look like the following:
 This requires the migration domain to be added to the list of valid vTPM kernel
 hashes. In the current version of the vtpmmgr domain, this is the hash of the
 XSM label, not the kernel.
+
+================================================================================
+Appendix B: vtpmmgr on TPM 2.0
+================================================================================
+
+Manager disk image setup:
+-------------------------
+
+The vTPM Manager requires a disk image to store its encrypted data. The image
+does not require a filesystem and can live anywhere on the host disk. The image
+is not large; the Xen 4.5 vtpmmgr is limited to using the first 2MB of the image
+but can support more than 20,000 vTPMs.
+
+ dd if=/dev/zero of=/home/vtpm2/vmgr bs=16M count=1
+
+Manager config file:
+--------------------
+
+The vTPM Manager domain (vtpmmgr-stubdom) must be started like any other Xen
+virtual machine and requires a config file.  The manager requires a disk image
+for storage and permission to access the hardware memory pages for the TPM. The
+disk must be presented as "hda", and the TPM memory pages are passed using the
+iomem configuration parameter. The TPM TIS uses 5 pages of IO memory (one per
+locality) that start at physical address 0xfed40000. By default, the TPM manager
+uses locality 0 (so only the page at 0xfed40 is needed).
+
+Add:
+..
+     extra="tpm2"
+..
+extra option to launch vtpmmgr-stubdom domain on TPM 2.0, and ignore it on TPM
+1.x. for example:
+
+    kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
+    memory=128
+    disk=["file:/home/vtpm2/vmgr,hda,w"]
+    name="vtpmmgr"
+    iomem=["fed40,5"]
+    extra="tpm2"
+
+
+Key Hierarchy
+------------------------------
+
+    +------------------+
+    |  vTPM's secrets  | ...
+    +------------------+
+            |  ^
+            |  |(Bind / Unbind)
+- - - - -  -v  |- - - - - - - - TPM 2.0
+    +------------------+
+    |        SK        +
+    +------------------+
+            |  ^
+            v  |
+    +------------------+
+    |       SRK        |
+    +------------------+
+            |  ^
+            v  |
+    +------------------+
+    | TPM 2.0 Storage  |
+    |   Primary Seed   |
+    +------------------+
+
+
+DESIGN OVERVIEW
+------------------------------
+
+The architecture of vTPM subsystem on TPM 2.0 is described below:
+
++------------------+
+|    Linux DomU    | ...
+|       |  ^       |
+|       v  |       |
+|   xen-tpmfront   |
++------------------+
+        |  ^
+        v  |
++------------------+
+| mini-os/tpmback  |
+|       |  ^       |
+|       v  |       |
+|  vtpm-stubdom    | ...
+|       |  ^       |
+|       v  |       |
+| mini-os/tpmfront |
++------------------+
+        |  ^
+        v  |
++------------------+
+| mini-os/tpmback  |
+|       |  ^       |
+|       v  |       |
+| vtpmmgr-stubdom  |
+|       |  ^       |
+|       v  |       |
+| mini-os/tpm2_tis |
++------------------+
+        |  ^
+        v  |
++------------------+
+| Hardware TPM 2.0 |
++------------------+
+
+ * Linux DomU: The Linux based guest that wants to use a vTPM. There many be
+               more than one of these.
+
+ * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver
+                    provides vTPM access to a para-virtualized Linux based DomU.
+
+ * 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.  This domain regulates
+               access to the physical TPM on the system and secures the
+               persistent state of each vTPM.
+
+ * mini-os/tpm2_tis: Mini-os TPM version 2.0 TPM Interface Specification (TIS)
+                    driver. This driver used by vtpmmgr-stubdom to talk directly
+                    to the hardware TPM 2.0. Communication is facilitated by mapping
+                    hardware memory pages into vtpmmgr-stubdom.
+
+ * Hardware TPM 2.0: The physical TPM 2.0 that is soldered onto the motherboard.
+
+---------------------
+Noted:
+    functionality for a virtual guest operating system (a DomU) is still TPM 1.2.
-- 
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 Dec 31 09:55:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:55:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6Fzj-00022L-5Q; Wed, 31 Dec 2014 09:55:11 +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 1Y6Fzh-00020u-9I
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:55:09 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	E5/F6-29352-CF7C3A45; Wed, 31 Dec 2014 09:55:08 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1420019707!15792867!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32705 invoked from network); 31 Dec 2014 09:55:07 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-7.tower-206.messagelabs.com with SMTP;
	31 Dec 2014 09:55:07 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 31 Dec 2014 01:54:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="631131340"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 31 Dec 2014 01:54:55 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:51:07 -0500
Message-Id: <1420005067-25890-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 11/14] vTPM/TPM2: Support TPM 2.0 bind and
	unbind 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bind data with TPM2_RSA_Encrypt, which performs RSA encryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1). If the
scheme of keyHandle is TPM_ALG_NULL, then the caller may use inScheme
to specify the padding scheme.
Unbind data with TPM2_RSA_Decrypt, which performs RSA decryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1).

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/disk_tpm.c | 42 ++++++++++++++++++++++++++++++++++++++++--
 stubdom/vtpmmgr/disk_tpm.h |  4 ++++
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_tpm.c b/stubdom/vtpmmgr/disk_tpm.c
index d650fbc..45a326a 100644
--- a/stubdom/vtpmmgr/disk_tpm.c
+++ b/stubdom/vtpmmgr/disk_tpm.c
@@ -12,17 +12,20 @@
 #include <polarssl/sha1.h>
 
 #include "tpm.h"
+#include "tpm2.h"
 #include "tcg.h"
 
 #include "vtpmmgr.h"
 #include "vtpm_disk.h"
 #include "disk_tpm.h"
 
+#include "log.h"
 // Print out input/output of seal/unseal operations (includes keys)
 #undef DEBUG_SEAL_OPS
 
 #ifdef DEBUG_SEAL_OPS
 #include "marshal.h"
+#include "tpm2_marshal.h"
 #endif
 
 struct pcr_list {
@@ -31,11 +34,16 @@ struct pcr_list {
 
 static struct pcr_list hwtpm;
 
+/*Ignore PCR on TPM 2.0, read PCR values for TPM 1.x seal | unseal*/
 void TPM_read_pcrs(void)
 {
 	int i;
-	for(i=0; i < 24; i++)
-		TPM_PCR_Read(i, &hwtpm.pcrs[i]);
+	for (i=0; i < 24; i++) {
+        if (hw_is_tpm2())
+            tpm2_pcr_read(i, (uint8_t *)&hwtpm.pcrs[i]);
+        else
+		    TPM_PCR_Read(i, &hwtpm.pcrs[i]);
+    }
 }
 
 struct pcr_composite_3 {
@@ -138,6 +146,36 @@ int TPM_disk_seal(struct disk_seal_entry *dst, const void* src, size_t size)
 	return rc;
 }
 
+TPM_RC TPM2_disk_bind(struct disk_seal_entry *dst, void* src, unsigned int size)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+
+    TPMTRYRETURN(TPM2_Bind(vtpm_globals.sk_handle,
+                           src,
+                           size,
+                           dst->sealed_data));
+
+abort_egress:
+egress:
+   return status;
+}
+
+TPM_RC TPM2_disk_unbind(void *dst, unsigned int *size, const struct disk_seal_entry *src)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+    unsigned char buf[RSA_CIPHER_SIZE];
+
+    memcpy(buf, src->sealed_data, RSA_CIPHER_SIZE);
+    TPMTRYRETURN(TPM2_UnBind(vtpm_globals.sk_handle,
+                             RSA_CIPHER_SIZE,
+                             buf,
+                             size,
+                             dst));
+abort_egress:
+egress:
+   return status;
+}
+
 int TPM_disk_unseal(void *dst, size_t size, const struct disk_seal_entry *src)
 {
 	uint32_t rc;
diff --git a/stubdom/vtpmmgr/disk_tpm.h b/stubdom/vtpmmgr/disk_tpm.h
index b235895..57ae2a6 100644
--- a/stubdom/vtpmmgr/disk_tpm.h
+++ b/stubdom/vtpmmgr/disk_tpm.h
@@ -10,6 +10,10 @@ void TPM_pcr_digest(struct hash160 *buf, le32_t selection);
 int TPM_disk_seal(struct disk_seal_entry *dst, const void* src, size_t size);
 int TPM_disk_unseal(void *dst, size_t size, const struct disk_seal_entry *src);
 
+/*TPM 2.0 Bind and Unbind */
+TPM_RC TPM2_disk_bind(struct disk_seal_entry *dst, void* src, unsigned int size);
+TPM_RC TPM2_disk_unbind(void *dst, unsigned int *size, const struct disk_seal_entry *src);
+
 /* NVRAM to allow revocation of TM-KEY */
 int TPM_disk_nvalloc(be32_t *nvram_slot, struct tpm_authdata auth);
 int TPM_disk_nvread(void *buf, size_t bufsiz, be32_t nvram_slot, struct tpm_authdata auth);
-- 
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 Dec 31 09:55:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:55:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6Fzj-00022n-LL; Wed, 31 Dec 2014 09:55:11 +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 1Y6Fzh-00020p-2F
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:55:09 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	BC/8E-25276-CF7C3A45; Wed, 31 Dec 2014 09:55:08 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1420019706!18263199!1
X-Originating-IP: [134.134.136.65]
X-SpamReason: No, hits=0.7 required=7.0 tests=DATE_IN_PAST_03_06
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18288 invoked from network); 31 Dec 2014 09:55:07 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65)
	by server-3.tower-21.messagelabs.com with SMTP;
	31 Dec 2014 09:55:07 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga103.jf.intel.com with ESMTP; 31 Dec 2014 01:52:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="631131374"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 31 Dec 2014 01:55:04 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:51:16 -0500
Message-Id: <1420005076-26003-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org,
	ian.jackson@eu.citrix.com, jbeulich@suse.com, Quan Xu <quan.xu@intel.com>
Subject: [Xen-devel] [PATCH v3 14/14] vTPM/TPM2: Record some infomation in
	docs/misc/vtpmmgr.txt about
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

'vtpmmgr on TPM 2.0'

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 docs/misc/vtpmmgr.txt | 150 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 149 insertions(+), 1 deletion(-)

diff --git a/docs/misc/vtpmmgr.txt b/docs/misc/vtpmmgr.txt
index 026c52b..1f1af4d 100644
--- a/docs/misc/vtpmmgr.txt
+++ b/docs/misc/vtpmmgr.txt
@@ -1,4 +1,8 @@
-Author: Daniel De Graaf <dgdegra@tycho.nsa.gov>
+================================================================================
+Authors:
+    Daniel De Graaf <dgdegra@tycho.nsa.gov>
+    Quan Xu <quan.xu@intel.com>
+================================================================================
 
 This document describes the operation and command line interface of
 vtpmmgr-stubdom. See docs/misc/vtpm.txt for details on the vTPM subsystem as a
@@ -163,3 +167,147 @@ would look like the following:
 This requires the migration domain to be added to the list of valid vTPM kernel
 hashes. In the current version of the vtpmmgr domain, this is the hash of the
 XSM label, not the kernel.
+
+================================================================================
+Appendix B: vtpmmgr on TPM 2.0
+================================================================================
+
+Manager disk image setup:
+-------------------------
+
+The vTPM Manager requires a disk image to store its encrypted data. The image
+does not require a filesystem and can live anywhere on the host disk. The image
+is not large; the Xen 4.5 vtpmmgr is limited to using the first 2MB of the image
+but can support more than 20,000 vTPMs.
+
+ dd if=/dev/zero of=/home/vtpm2/vmgr bs=16M count=1
+
+Manager config file:
+--------------------
+
+The vTPM Manager domain (vtpmmgr-stubdom) must be started like any other Xen
+virtual machine and requires a config file.  The manager requires a disk image
+for storage and permission to access the hardware memory pages for the TPM. The
+disk must be presented as "hda", and the TPM memory pages are passed using the
+iomem configuration parameter. The TPM TIS uses 5 pages of IO memory (one per
+locality) that start at physical address 0xfed40000. By default, the TPM manager
+uses locality 0 (so only the page at 0xfed40 is needed).
+
+Add:
+..
+     extra="tpm2"
+..
+extra option to launch vtpmmgr-stubdom domain on TPM 2.0, and ignore it on TPM
+1.x. for example:
+
+    kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
+    memory=128
+    disk=["file:/home/vtpm2/vmgr,hda,w"]
+    name="vtpmmgr"
+    iomem=["fed40,5"]
+    extra="tpm2"
+
+
+Key Hierarchy
+------------------------------
+
+    +------------------+
+    |  vTPM's secrets  | ...
+    +------------------+
+            |  ^
+            |  |(Bind / Unbind)
+- - - - -  -v  |- - - - - - - - TPM 2.0
+    +------------------+
+    |        SK        +
+    +------------------+
+            |  ^
+            v  |
+    +------------------+
+    |       SRK        |
+    +------------------+
+            |  ^
+            v  |
+    +------------------+
+    | TPM 2.0 Storage  |
+    |   Primary Seed   |
+    +------------------+
+
+
+DESIGN OVERVIEW
+------------------------------
+
+The architecture of vTPM subsystem on TPM 2.0 is described below:
+
++------------------+
+|    Linux DomU    | ...
+|       |  ^       |
+|       v  |       |
+|   xen-tpmfront   |
++------------------+
+        |  ^
+        v  |
++------------------+
+| mini-os/tpmback  |
+|       |  ^       |
+|       v  |       |
+|  vtpm-stubdom    | ...
+|       |  ^       |
+|       v  |       |
+| mini-os/tpmfront |
++------------------+
+        |  ^
+        v  |
++------------------+
+| mini-os/tpmback  |
+|       |  ^       |
+|       v  |       |
+| vtpmmgr-stubdom  |
+|       |  ^       |
+|       v  |       |
+| mini-os/tpm2_tis |
++------------------+
+        |  ^
+        v  |
++------------------+
+| Hardware TPM 2.0 |
++------------------+
+
+ * Linux DomU: The Linux based guest that wants to use a vTPM. There many be
+               more than one of these.
+
+ * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver
+                    provides vTPM access to a para-virtualized Linux based DomU.
+
+ * 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.  This domain regulates
+               access to the physical TPM on the system and secures the
+               persistent state of each vTPM.
+
+ * mini-os/tpm2_tis: Mini-os TPM version 2.0 TPM Interface Specification (TIS)
+                    driver. This driver used by vtpmmgr-stubdom to talk directly
+                    to the hardware TPM 2.0. Communication is facilitated by mapping
+                    hardware memory pages into vtpmmgr-stubdom.
+
+ * Hardware TPM 2.0: The physical TPM 2.0 that is soldered onto the motherboard.
+
+---------------------
+Noted:
+    functionality for a virtual guest operating system (a DomU) is still TPM 1.2.
-- 
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 Dec 31 09:55:11 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09:55:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6Fzj-00022L-5Q; Wed, 31 Dec 2014 09:55:11 +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 1Y6Fzh-00020u-9I
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:55:09 +0000
Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id
	E5/F6-29352-CF7C3A45; Wed, 31 Dec 2014 09:55:08 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1420019707!15792867!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32705 invoked from network); 31 Dec 2014 09:55:07 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-7.tower-206.messagelabs.com with SMTP;
	31 Dec 2014 09:55:07 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 31 Dec 2014 01:54:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="631131340"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by orsmga001.jf.intel.com with ESMTP; 31 Dec 2014 01:54:55 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:51:07 -0500
Message-Id: <1420005067-25890-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 11/14] vTPM/TPM2: Support TPM 2.0 bind and
	unbind 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bind data with TPM2_RSA_Encrypt, which performs RSA encryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1). If the
scheme of keyHandle is TPM_ALG_NULL, then the caller may use inScheme
to specify the padding scheme.
Unbind data with TPM2_RSA_Decrypt, which performs RSA decryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1).

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 stubdom/vtpmmgr/disk_tpm.c | 42 ++++++++++++++++++++++++++++++++++++++++--
 stubdom/vtpmmgr/disk_tpm.h |  4 ++++
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_tpm.c b/stubdom/vtpmmgr/disk_tpm.c
index d650fbc..45a326a 100644
--- a/stubdom/vtpmmgr/disk_tpm.c
+++ b/stubdom/vtpmmgr/disk_tpm.c
@@ -12,17 +12,20 @@
 #include <polarssl/sha1.h>
 
 #include "tpm.h"
+#include "tpm2.h"
 #include "tcg.h"
 
 #include "vtpmmgr.h"
 #include "vtpm_disk.h"
 #include "disk_tpm.h"
 
+#include "log.h"
 // Print out input/output of seal/unseal operations (includes keys)
 #undef DEBUG_SEAL_OPS
 
 #ifdef DEBUG_SEAL_OPS
 #include "marshal.h"
+#include "tpm2_marshal.h"
 #endif
 
 struct pcr_list {
@@ -31,11 +34,16 @@ struct pcr_list {
 
 static struct pcr_list hwtpm;
 
+/*Ignore PCR on TPM 2.0, read PCR values for TPM 1.x seal | unseal*/
 void TPM_read_pcrs(void)
 {
 	int i;
-	for(i=0; i < 24; i++)
-		TPM_PCR_Read(i, &hwtpm.pcrs[i]);
+	for (i=0; i < 24; i++) {
+        if (hw_is_tpm2())
+            tpm2_pcr_read(i, (uint8_t *)&hwtpm.pcrs[i]);
+        else
+		    TPM_PCR_Read(i, &hwtpm.pcrs[i]);
+    }
 }
 
 struct pcr_composite_3 {
@@ -138,6 +146,36 @@ int TPM_disk_seal(struct disk_seal_entry *dst, const void* src, size_t size)
 	return rc;
 }
 
+TPM_RC TPM2_disk_bind(struct disk_seal_entry *dst, void* src, unsigned int size)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+
+    TPMTRYRETURN(TPM2_Bind(vtpm_globals.sk_handle,
+                           src,
+                           size,
+                           dst->sealed_data));
+
+abort_egress:
+egress:
+   return status;
+}
+
+TPM_RC TPM2_disk_unbind(void *dst, unsigned int *size, const struct disk_seal_entry *src)
+{
+    TPM_RESULT status = TPM_SUCCESS;
+    unsigned char buf[RSA_CIPHER_SIZE];
+
+    memcpy(buf, src->sealed_data, RSA_CIPHER_SIZE);
+    TPMTRYRETURN(TPM2_UnBind(vtpm_globals.sk_handle,
+                             RSA_CIPHER_SIZE,
+                             buf,
+                             size,
+                             dst));
+abort_egress:
+egress:
+   return status;
+}
+
 int TPM_disk_unseal(void *dst, size_t size, const struct disk_seal_entry *src)
 {
 	uint32_t rc;
diff --git a/stubdom/vtpmmgr/disk_tpm.h b/stubdom/vtpmmgr/disk_tpm.h
index b235895..57ae2a6 100644
--- a/stubdom/vtpmmgr/disk_tpm.h
+++ b/stubdom/vtpmmgr/disk_tpm.h
@@ -10,6 +10,10 @@ void TPM_pcr_digest(struct hash160 *buf, le32_t selection);
 int TPM_disk_seal(struct disk_seal_entry *dst, const void* src, size_t size);
 int TPM_disk_unseal(void *dst, size_t size, const struct disk_seal_entry *src);
 
+/*TPM 2.0 Bind and Unbind */
+TPM_RC TPM2_disk_bind(struct disk_seal_entry *dst, void* src, unsigned int size);
+TPM_RC TPM2_disk_unbind(void *dst, unsigned int *size, const struct disk_seal_entry *src);
+
 /* NVRAM to allow revocation of TM-KEY */
 int TPM_disk_nvalloc(be32_t *nvram_slot, struct tpm_authdata auth);
 int TPM_disk_nvread(void *buf, size_t bufsiz, be32_t nvram_slot, struct tpm_authdata auth);
-- 
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 Dec 31 09:55:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09: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 1Y6Fzk-000242-9C; Wed, 31 Dec 2014 09:55:12 +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 1Y6Fzj-00022D-8T
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:55:11 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B2/9E-25276-EF7C3A45; Wed, 31 Dec 2014 09:55:10 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1420019709!18578900!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18884 invoked from network); 31 Dec 2014 09:55:09 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-11.tower-21.messagelabs.com with SMTP;
	31 Dec 2014 09:55:09 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 31 Dec 2014 01:50:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="435269342"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 31 Dec 2014 01:42:59 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:51:10 -0500
Message-Id: <1420005070-25929-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 12/14] vTPM/TPM2: Bind group keys and sectors
	data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/disk_write.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_write.c b/stubdom/vtpmmgr/disk_write.c
index 4c825c5..ab15a9a 100644
--- a/stubdom/vtpmmgr/disk_write.c
+++ b/stubdom/vtpmmgr/disk_write.c
@@ -88,7 +88,12 @@ static void generate_group_seals(struct mem_group *src, const struct mem_tpm_mgr
 		dst->pcr_selection = src->seals[i].pcr_selection;
 		memcpy(&dst->digest_release, &src->seals[i].digest_release, 20);
 		TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
-		TPM_disk_seal(dst, &sblob, sizeof(sblob));
+
+        /*TPM 2.0 bind | TPM 1.x seal*/
+        if (hw_is_tpm2())
+            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+        else
+            TPM_disk_seal(dst, &sblob, sizeof(sblob));
 	}
 	src->seal_bits.nr_cfgs = native_be32(src->nr_seals);
 
@@ -250,7 +255,11 @@ static void disk_write_seal_list(struct mem_tpm_mgr *mgr, struct mem_group *grou
 		memcpy(&dst->digest_release, &src->digest_release, 20);
 		TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
 
-		TPM_disk_seal(dst, &sblob, sizeof(sblob));
+        /*TPM 2.0 bind / TPM 1.x seal*/
+        if (hw_is_tpm2())
+            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+        else
+            TPM_disk_seal(dst, &sblob, sizeof(sblob));
 	}
 
 	memcpy(seal->hdr.magic, TPM_MGR_MAGIC, 12);
-- 
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 Dec 31 09:55:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09: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 1Y6Fzk-000242-9C; Wed, 31 Dec 2014 09:55:12 +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 1Y6Fzj-00022D-8T
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:55:11 +0000
Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id
	B2/9E-25276-EF7C3A45; Wed, 31 Dec 2014 09:55:10 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1420019709!18578900!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18884 invoked from network); 31 Dec 2014 09:55:09 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115)
	by server-11.tower-21.messagelabs.com with SMTP;
	31 Dec 2014 09:55:09 -0000
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
	by fmsmga103.fm.intel.com with ESMTP; 31 Dec 2014 01:50:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="435269342"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by FMSMGA003.fm.intel.com with ESMTP; 31 Dec 2014 01:42:59 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:51:10 -0500
Message-Id: <1420005070-25929-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 12/14] vTPM/TPM2: Bind group keys and sectors
	data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/disk_write.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_write.c b/stubdom/vtpmmgr/disk_write.c
index 4c825c5..ab15a9a 100644
--- a/stubdom/vtpmmgr/disk_write.c
+++ b/stubdom/vtpmmgr/disk_write.c
@@ -88,7 +88,12 @@ static void generate_group_seals(struct mem_group *src, const struct mem_tpm_mgr
 		dst->pcr_selection = src->seals[i].pcr_selection;
 		memcpy(&dst->digest_release, &src->seals[i].digest_release, 20);
 		TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
-		TPM_disk_seal(dst, &sblob, sizeof(sblob));
+
+        /*TPM 2.0 bind | TPM 1.x seal*/
+        if (hw_is_tpm2())
+            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+        else
+            TPM_disk_seal(dst, &sblob, sizeof(sblob));
 	}
 	src->seal_bits.nr_cfgs = native_be32(src->nr_seals);
 
@@ -250,7 +255,11 @@ static void disk_write_seal_list(struct mem_tpm_mgr *mgr, struct mem_group *grou
 		memcpy(&dst->digest_release, &src->digest_release, 20);
 		TPM_pcr_digest(&dst->digest_at_seal, dst->pcr_selection);
 
-		TPM_disk_seal(dst, &sblob, sizeof(sblob));
+        /*TPM 2.0 bind / TPM 1.x seal*/
+        if (hw_is_tpm2())
+            TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+        else
+            TPM_disk_seal(dst, &sblob, sizeof(sblob));
 	}
 
 	memcpy(seal->hdr.magic, TPM_MGR_MAGIC, 12);
-- 
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 Dec 31 09:55:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09: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 1Y6Fzv-0002Ey-Qq; Wed, 31 Dec 2014 09:55:23 +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 1Y6Fzu-0002DG-EO
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:55:22 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	E6/62-22737-908C3A45; Wed, 31 Dec 2014 09:55:21 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1420019718!10457019!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6282 invoked from network); 31 Dec 2014 09:55:21 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-206.messagelabs.com with SMTP;
	31 Dec 2014 09:55:21 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 31 Dec 2014 01:55:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="655296272"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 31 Dec 2014 01:55:02 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:51:13 -0500
Message-Id: <1420005073-25966-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 13/14] vTPM/TPM2: Unind group keys and
	sectors data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/disk_read.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_read.c b/stubdom/vtpmmgr/disk_read.c
index 33aacdd..e9dc20f 100644
--- a/stubdom/vtpmmgr/disk_read.c
+++ b/stubdom/vtpmmgr/disk_read.c
@@ -67,6 +67,7 @@ static int find_group_key(struct mem_group *dst,
 		const struct mem_tpm_mgr *parent)
 {
 	int i, rc, rv = 1;
+    unsigned int olen;
 	struct hash160 buf;
 	struct disk_group_sealed_data sealed;
 
@@ -88,7 +89,13 @@ static int find_group_key(struct mem_group *dst,
 		TPM_pcr_digest(&buf, cfg->pcr_selection);
 		if (memcmp(&buf, &cfg->digest_release, 20))
 			continue;
-		rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
+
+        /*TPM 2.0 unbind | TPM 1.x unseal*/
+        if (hw_is_tpm2())
+            rc = TPM2_disk_unbind(&sealed, &olen, cfg);
+        else
+            rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
+
 		if (rc)
 			continue;
 		if (memcmp(&sealed.magic, DISK_GROUP_BOUND_MAGIC, 4))
@@ -112,9 +119,15 @@ static int find_group_key(struct mem_group *dst,
 static int parse_root_key(struct mem_tpm_mgr *dst, struct disk_seal_entry *src)
 {
 	int rc;
+    unsigned int olen;
 	struct disk_root_sealed_data sealed;
 
-	rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
+    /*TPM 2.0 unbind | TPM 1.x unseal*/
+    if (hw_is_tpm2())
+        rc = TPM2_disk_unbind(&sealed, &olen, src);
+    else
+        rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
+
 	if (rc)
 		return rc;
 
-- 
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 Dec 31 09:55:24 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 09: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 1Y6Fzv-0002Ey-Qq; Wed, 31 Dec 2014 09:55:23 +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 1Y6Fzu-0002DG-EO
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 09:55:22 +0000
Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id
	E6/62-22737-908C3A45; Wed, 31 Dec 2014 09:55:21 +0000
X-Env-Sender: quan.xu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1420019718!10457019!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.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6282 invoked from network); 31 Dec 2014 09:55:21 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-206.messagelabs.com with SMTP;
	31 Dec 2014 09:55:21 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 31 Dec 2014 01:55:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,671,1413270000"; d="scan'208";a="655296272"
Received: from xen-commits.sh.intel.com ([10.239.131.208])
	by fmsmga002.fm.intel.com with ESMTP; 31 Dec 2014 01:55:02 -0800
From: Quan Xu <quan.xu@intel.com>
To: xen-devel@lists.xen.org
Date: Wed, 31 Dec 2014 00:51:13 -0500
Message-Id: <1420005073-25966-1-git-send-email-quan.xu@intel.com>
X-Mailer: git-send-email 1.8.3.2
Cc: samuel.thibault@ens-lyon.org, dgdegra@tycho.nsa.gov,
	Quan Xu <quan.xu@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3 13/14] vTPM/TPM2: Unind group keys and
	sectors data on disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="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>
---
 stubdom/vtpmmgr/disk_read.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/stubdom/vtpmmgr/disk_read.c b/stubdom/vtpmmgr/disk_read.c
index 33aacdd..e9dc20f 100644
--- a/stubdom/vtpmmgr/disk_read.c
+++ b/stubdom/vtpmmgr/disk_read.c
@@ -67,6 +67,7 @@ static int find_group_key(struct mem_group *dst,
 		const struct mem_tpm_mgr *parent)
 {
 	int i, rc, rv = 1;
+    unsigned int olen;
 	struct hash160 buf;
 	struct disk_group_sealed_data sealed;
 
@@ -88,7 +89,13 @@ static int find_group_key(struct mem_group *dst,
 		TPM_pcr_digest(&buf, cfg->pcr_selection);
 		if (memcmp(&buf, &cfg->digest_release, 20))
 			continue;
-		rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
+
+        /*TPM 2.0 unbind | TPM 1.x unseal*/
+        if (hw_is_tpm2())
+            rc = TPM2_disk_unbind(&sealed, &olen, cfg);
+        else
+            rc = TPM_disk_unseal(&sealed, sizeof(sealed), cfg);
+
 		if (rc)
 			continue;
 		if (memcmp(&sealed.magic, DISK_GROUP_BOUND_MAGIC, 4))
@@ -112,9 +119,15 @@ static int find_group_key(struct mem_group *dst,
 static int parse_root_key(struct mem_tpm_mgr *dst, struct disk_seal_entry *src)
 {
 	int rc;
+    unsigned int olen;
 	struct disk_root_sealed_data sealed;
 
-	rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
+    /*TPM 2.0 unbind | TPM 1.x unseal*/
+    if (hw_is_tpm2())
+        rc = TPM2_disk_unbind(&sealed, &olen, src);
+    else
+        rc = TPM_disk_unseal(&sealed, sizeof(sealed), src);
+
 	if (rc)
 		return rc;
 
-- 
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 Dec 31 12:15:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6IAu-0006Jn-GL; Wed, 31 Dec 2014 12:14:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y6IAs-0006Ji-OV
	for xen-devel@lists.xensource.com; Wed, 31 Dec 2014 12:14:50 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	5D/F8-02697-AB8E3A45; Wed, 31 Dec 2014 12:14:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1420028087!15758642!1
X-Originating-IP: [66.165.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 29808 invoked from network); 31 Dec 2014 12:14:49 -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;
	31 Dec 2014 12:14:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,672,1413244800"; d="scan'208";a="210146111"
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.210.2; Wed, 31 Dec 2014 07:14: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 1Y6IAg-0004r9-TZ;
	Wed, 31 Dec 2014 12:14:38 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y6IAg-0002XJ-Nx;
	Wed, 31 Dec 2014 12:14:38 +0000
Date: Wed, 31 Dec 2014 12:14:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32876-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] 32876: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32876 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32876/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install fail in 32854 REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 32854
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot        fail in 32854 pass in 32876

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 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 912 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 Dec 31 12:15:28 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6IAu-0006Jn-GL; Wed, 31 Dec 2014 12:14:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y6IAs-0006Ji-OV
	for xen-devel@lists.xensource.com; Wed, 31 Dec 2014 12:14:50 +0000
Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id
	5D/F8-02697-AB8E3A45; Wed, 31 Dec 2014 12:14:50 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1420028087!15758642!1
X-Originating-IP: [66.165.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 29808 invoked from network); 31 Dec 2014 12:14:49 -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;
	31 Dec 2014 12:14:49 -0000
X-IronPort-AV: E=Sophos;i="5.07,672,1413244800"; d="scan'208";a="210146111"
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.210.2; Wed, 31 Dec 2014 07:14: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 1Y6IAg-0004r9-TZ;
	Wed, 31 Dec 2014 12:14:38 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y6IAg-0002XJ-Nx;
	Wed, 31 Dec 2014 12:14:38 +0000
Date: Wed, 31 Dec 2014 12:14:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32876-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] 32876: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32876 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32876/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start             fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install           fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install      fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install fail in 32854 REGR. vs. 32598

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 32854
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot        fail in 32854 pass in 32876

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair        17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  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-pvh-amd   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-libvirt       9 guest-start                  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-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-winxpsp3 14 guest-stop                fail never pass

version targeted for testing:
 qemuu                ab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu                7e58e2ac7778cca3234c33387e49577bb7732714

------------------------------------------------------------
People who touched revisions under test:
  Alex Williamson <alex.williamson@redhat.com>
  Eric Auger <eric.auger@linaro.org>
  Fabian Aggeler <aggelerf@ethz.ch>
  Frank Blaschka <blaschka@linux.vnet.ibm.com>
  Greg Bellows <greg.bellows@linaro.org>
  Kim Phillips <kim.phillips@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Marcel Apfelbaum <marcel.a@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-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 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                     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-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-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-amd64-xl-pcipt-intel                              fail    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 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 912 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 Dec 31 15:32:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 15: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 1Y6LFG-0001Rw-AC; Wed, 31 Dec 2014 15:31:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y6LFE-0001Rr-JQ
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 15:31:32 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	09/C3-02743-3D614A45; Wed, 31 Dec 2014 15:31:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1420039889!13245686!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11344 invoked from network); 31 Dec 2014 15:31:30 -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; 31 Dec 2014 15:31: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 sBVFVACI025690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 31 Dec 2014 15:31: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
	sBVFV8qW024598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Dec 2014 15:31:09 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
	sBVFV8W3024571; Wed, 31 Dec 2014 15:31:08 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 31 Dec 2014 07:31:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BB8EA126825; Wed, 31 Dec 2014 10:31:06 -0500 (EST)
Date: Wed, 31 Dec 2014 10:31:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141231153106.GA2928@laptop.dumpdata.com>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
	<20141219191032.GB9213@laptop.dumpdata.com>
	<20141222080639.GA6139@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141222080639.GA6139@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: m.a.young@durham.ac.uk, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes 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, Dec 22, 2014 at 09:06:40AM +0100, Olaf Hering wrote:
> On Fri, Dec 19, Konrad Rzeszutek Wilk wrote:
> 
> > On Fri, Dec 19, 2014 at 12:25:26PM +0100, Olaf Hering wrote:
> > > This is a resend of these two series:
> > > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00858.html
> > > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
> > > 
> > > New in v3 is a wrapper to run xenstored. See its patch description
> > > for details.
> > > 
> > > Patch 2-6 should be applied for 4.5.0.
> > > 
> > > The first and the last one still has issues with xenstored and
> > > SELinux. See below.  Up to now no solution is known to me.
> > > 
> > > 
> > > The first patch fixes Arch Linux and does not break anything.  As such
> > > it should be safe to be applied for 4.5.0.  SELinux users (who build
> > > from source) should put their special mount options into fstab. Distro
> > 
> > Could you elaborate what that is? As in what is that 'special mount options'?
> 
> The context= mount option, about which we argue since a few weeks?

You said 'special mount options into fstab' ? Is that the same as 'context='??
(checks the manpage) AHA, it is!


In which case would it just to say that this needs to be added as
a workaround:

xenstored /var/lib/xenstored xenstored context="system_u:object_r:xenstored_var_lib_t:s0" 1 1

> See patch #1.
> 
> > > packages will most likely include a proper .service file.
> > > 
> > > 
> > > The last patch addresses the XENSTORED_TRACE issue. But SELinux will
> > > most likely still not work.
> > > 
> > > Possible ways to handle launching xenstored and SELinux:
> > > 
> > > - do nothing
> > >   pro: - no Xen source changes required
> > >   con: - possible unhappy users who build from source and still have
> > >          SELinux enabled
> > 
> > At this stage I prefer this and just have in the release notes the
> > work-around documented.
> 
> Which workaround is that? No SELinux on Fedora?

That is not an option.

The workaround is to document what the 'context' is .. or whatever
else is needed to make this work.

> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 31 15:32:12 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 15: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 1Y6LFG-0001Rw-AC; Wed, 31 Dec 2014 15:31:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Y6LFE-0001Rr-JQ
	for xen-devel@lists.xen.org; Wed, 31 Dec 2014 15:31:32 +0000
Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id
	09/C3-02743-3D614A45; Wed, 31 Dec 2014 15:31:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1420039889!13245686!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11344 invoked from network); 31 Dec 2014 15:31:30 -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; 31 Dec 2014 15:31: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 sBVFVACI025690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 31 Dec 2014 15:31: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
	sBVFV8qW024598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Dec 2014 15:31:09 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
	sBVFV8W3024571; Wed, 31 Dec 2014 15:31:08 GMT
Received: from laptop.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 31 Dec 2014 07:31:08 -0800
Received: by laptop.dumpdata.com (Postfix, from userid 1000)
	id BB8EA126825; Wed, 31 Dec 2014 10:31:06 -0500 (EST)
Date: Wed, 31 Dec 2014 10:31:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20141231153106.GA2928@laptop.dumpdata.com>
References: <1418988333-5404-1-git-send-email-olaf@aepfle.de>
	<20141219191032.GB9213@laptop.dumpdata.com>
	<20141222080639.GA6139@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141222080639.GA6139@aepfle.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: m.a.young@durham.ac.uk, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes 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, Dec 22, 2014 at 09:06:40AM +0100, Olaf Hering wrote:
> On Fri, Dec 19, Konrad Rzeszutek Wilk wrote:
> 
> > On Fri, Dec 19, 2014 at 12:25:26PM +0100, Olaf Hering wrote:
> > > This is a resend of these two series:
> > > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00858.html
> > > http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
> > > 
> > > New in v3 is a wrapper to run xenstored. See its patch description
> > > for details.
> > > 
> > > Patch 2-6 should be applied for 4.5.0.
> > > 
> > > The first and the last one still has issues with xenstored and
> > > SELinux. See below.  Up to now no solution is known to me.
> > > 
> > > 
> > > The first patch fixes Arch Linux and does not break anything.  As such
> > > it should be safe to be applied for 4.5.0.  SELinux users (who build
> > > from source) should put their special mount options into fstab. Distro
> > 
> > Could you elaborate what that is? As in what is that 'special mount options'?
> 
> The context= mount option, about which we argue since a few weeks?

You said 'special mount options into fstab' ? Is that the same as 'context='??
(checks the manpage) AHA, it is!


In which case would it just to say that this needs to be added as
a workaround:

xenstored /var/lib/xenstored xenstored context="system_u:object_r:xenstored_var_lib_t:s0" 1 1

> See patch #1.
> 
> > > packages will most likely include a proper .service file.
> > > 
> > > 
> > > The last patch addresses the XENSTORED_TRACE issue. But SELinux will
> > > most likely still not work.
> > > 
> > > Possible ways to handle launching xenstored and SELinux:
> > > 
> > > - do nothing
> > >   pro: - no Xen source changes required
> > >   con: - possible unhappy users who build from source and still have
> > >          SELinux enabled
> > 
> > At this stage I prefer this and just have in the release notes the
> > work-around documented.
> 
> Which workaround is that? No SELinux on Fedora?

That is not an option.

The workaround is to document what the 'context' is .. or whatever
else is needed to make this work.

> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Dec 31 16:19:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 16: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 1Y6Lyn-0002hm-3x; Wed, 31 Dec 2014 16:18: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 1Y6Lyk-0002hh-Rf
	for xen-devel@lists.xensource.com; Wed, 31 Dec 2014 16:18:35 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	82/93-02699-AD124A45; Wed, 31 Dec 2014 16:18:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1420042712!17984054!1
X-Originating-IP: [66.165.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 22512 invoked from network); 31 Dec 2014 16:18:33 -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;
	31 Dec 2014 16:18:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,673,1413244800"; d="scan'208";a="209643466"
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.210.2; Wed, 31 Dec 2014 11:18: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 1Y6Lyf-000610-Dm;
	Wed, 31 Dec 2014 16:18:29 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y6Lyf-0000ns-6G;
	Wed, 31 Dec 2014 16:18:29 +0000
Date: Wed, 31 Dec 2014 16:18:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32877-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] 32877: 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 32877 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32877/

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 32844

Tests which did not succeed, but are not blocking:
 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-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       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-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-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-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-winxpsp3 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-amd64-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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 Dec 31 16:19:06 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 16: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 1Y6Lyn-0002hm-3x; Wed, 31 Dec 2014 16:18: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 1Y6Lyk-0002hh-Rf
	for xen-devel@lists.xensource.com; Wed, 31 Dec 2014 16:18:35 +0000
Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id
	82/93-02699-AD124A45; Wed, 31 Dec 2014 16:18:34 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1420042712!17984054!1
X-Originating-IP: [66.165.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 22512 invoked from network); 31 Dec 2014 16:18:33 -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;
	31 Dec 2014 16:18:33 -0000
X-IronPort-AV: E=Sophos;i="5.07,673,1413244800"; d="scan'208";a="209643466"
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.210.2; Wed, 31 Dec 2014 11:18: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 1Y6Lyf-000610-Dm;
	Wed, 31 Dec 2014 16:18:29 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y6Lyf-0000ns-6G;
	Wed, 31 Dec 2014 16:18:29 +0000
Date: Wed, 31 Dec 2014 16:18:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32877-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] 32877: 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 32877 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32877/

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 32844

Tests which did not succeed, but are not blocking:
 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-amd64-xl-pvh-amd   9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       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-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-amd64-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-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-winxpsp3 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-amd64-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                  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen                  36174af3fbeb1b662c0eadbfa193e77f68cc955b

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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 Dec 31 23:52:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 23:52:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6T3r-0001En-Oj; Wed, 31 Dec 2014 23:52:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y6T3q-0001Ei-K6
	for xen-devel@lists.xensource.com; Wed, 31 Dec 2014 23:52:18 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A2/0D-17735-13C84A45; Wed, 31 Dec 2014 23:52:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1420069935!14219103!1
X-Originating-IP: [66.165.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 7579 invoked from network); 31 Dec 2014 23:52:16 -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;
	31 Dec 2014 23:52:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,675,1413244800"; d="scan'208";a="210341839"
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.210.2; Wed, 31 Dec 2014 18:52: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 1Y6T3l-0008Ar-46;
	Wed, 31 Dec 2014 23:52:13 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y6T3k-0001Q6-Tr;
	Wed, 31 Dec 2014 23:52:12 +0000
Date: Wed, 31 Dec 2014 23:52:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32888-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] 32888: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32888 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32888/

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-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     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-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-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 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-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                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 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 Dec 31 23:52:47 2014
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Dec 2014 23:52:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Y6T3r-0001En-Oj; Wed, 31 Dec 2014 23:52:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@citrix.com>) id 1Y6T3q-0001Ei-K6
	for xen-devel@lists.xensource.com; Wed, 31 Dec 2014 23:52:18 +0000
Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id
	A2/0D-17735-13C84A45; Wed, 31 Dec 2014 23:52:17 +0000
X-Env-Sender: Ian.Jackson@citrix.com
X-Msg-Ref: server-14.tower-31.messagelabs.com!1420069935!14219103!1
X-Originating-IP: [66.165.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 7579 invoked from network); 31 Dec 2014 23:52:16 -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;
	31 Dec 2014 23:52:16 -0000
X-IronPort-AV: E=Sophos;i="5.07,675,1413244800"; d="scan'208";a="210341839"
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.210.2; Wed, 31 Dec 2014 18:52: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 1Y6T3l-0008Ar-46;
	Wed, 31 Dec 2014 23:52:13 +0000
Received: from osstest by osstest.cam.xci-test.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Y6T3k-0001Q6-Tr;
	Wed, 31 Dec 2014 23:52:12 +0000
Date: Wed, 31 Dec 2014 23:52:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-32888-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] 32888: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 32888 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32888/

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-amd64-xl-pvh-intel  9 guest-start                  fail  never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-amd   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-armhf-armhf-libvirt      5 xen-boot                     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-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-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 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-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                a472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linux                be67db109090b17b56eb8eb2190cd70700f107aa

------------------------------------------------------------
816 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-amd64-xl-pvh-amd                                  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-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-amd64-xl-pvh-intel                                fail    
 test-amd64-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 34929 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel